Does Anyone Still Care About the Basics?

Cisco's software has always been challenging. Much of those challenges, to put it bluntly, come from the company's neglect.

Here is a simple example: Click this link, select the "Cisco 4500" from the "Cisco Access Products" list, and click the "Go" button, instead of another page seemingly from the year of 1996, you get a 550 error.



How pathetic is that?

SNMP MIB Version Control

I work with Cisco devices a lot, especially in network management. So I naturally have to work with SNMP. Cisco does a pretty good job when it comes to publishing their MIBs. But often I find much inconsistencies in their MIB file distributed from different sources. From minor issues of file-naming differences (you may find the same MIB in files with .mib, .my or .txt extensions), to major changes inside the MIB without a version update. This is probably not a problem that happens in Cisco alone.

It occurred to me that these files are just text, so source code version control tools are perfect for managing them. Digging around a little bit on Google Code and github, I found out some one had already done it.

The SnmpMibs project on github is just what I was thinking about. I hope that the project gets more widely recognized. Especially, I think network device vendors should adopt this model in publishing their MIBs, that would make this whole world a slightly better place.

PoE Control via SNMP

A simple way to toggle the power on a power-over-Ethernet (PoE) switch port using the IETF POWER-EHTERNET-MIB (RFC 3621) object pethPsePortAdminEnable.

Here is an excerpt from POWER-EHTERNET-MIB:

  pethPsePortAdminEnable OBJECT-TYPE
    SYNTAX TruthValue
    MAX-ACCESS read-write
    STATUS current
    DESCRIPTION
        "true (1) An interface which can provide the PSE functions.
         false(2) The interface will act as it would if it had no PSE
         function."

Setting the object to false (2) on a port turns off the power; Setting it to true (1) turns the power on.

Simple enough. The next thing is to convert an interface name (e.g., Fa0/10) to the port index (e.g., 12) -- That is different on different switches.

To DNS or not to DNS: That is a question!

Here at UMHS, some of our network devices, i.e., switches and routers are named in some sub-domains in the DNS system, which provides an easy way for people to access them on the command line. For example, it is much easier to remember some-clinic.switch.med.umich.edu than 192.168.129.18.

To name our devices in a consistent way across the board, we have to decide on a device naming convention -- That is likely a common practice for all IT teams out there managing a network of any size larger than one single building. However, that presented me with this issue: Do we continue with naming the devices in DNS or not?

There are multiple ways a device in the IP networking world may be identified, DNS name is one of them, IP address(es) is another. Yet another is the SNMP MIB object SNMPv2-MIB::sysName. They each serves a different purpose: a DNS name serves humans and an IP address serves machines. The sysName object, on the other hand, serves network management systems that talk to devices using the SNMP protocol.

To minimize conflict of interests in naming a device, it is probably the easiest to make a DNS name identical to the sysName on the device. However, I have seen in more than one organizations where device naming conventions factor location and IP address information into the sysName, which in Cisco IOS is configured using the hostname command. Adopting such a naming convention effectively renders the human readability of a DNS name close to that of IP addresses. Also, synchronizing the sysName values defined in devices and their DNS names take a lot of work to do right. Some times it is a task crossing team boundaries, which is not to say it is impossible but difficult to say the least. So many a time the DNS names are out of sync with the IP addresses of devices after they are upgraded or a network is renumbered. The Combination of those two factors probably explains why I have seen many of my colleagues access devices using their IP addresses directly rather than using their DNS names.

My thoughts are that, a device should be named just for human access. Therefore embedding location and IP address in device name may seem to be a good idea but defeats the purpose of a name. After all, there is a sysLocation object in the SNMPv2-MIB and DNS exists to translate a name to an IP address. What we really need is probably a simple utility which, when given a DNS name or an IP address of a device, produces the other information such as location or whether the device really is a router or a switch.