Greetings everyone,

This post may become rather lengthy, but if you are interested in Cisco module issues and port numbering vs. interface names, please bear with me. I would really appreciate some feedback from our users, as the changes we are implementing will affect everyone.

Removing the "submodule hack" -----------------------------

This summer I worked on fixing some of the problems with module detection on Cisco equipment. There were several problems related to the fact that gDD attempts to map Cisco's submodule paradigm in to NAV's data model by assigning module number 10 to submodule 1/0, number 11 to submodule 1/1 and so forth.

Apparently, there isn't much equipment that actually employs submodules, and oftentimes these modules will not be self-sustainable devices, as in the case of the 3750 Metro. The basic metro reports two submodules, the first (1/0) contains 24 Fa ports and two Gi ports, while the second (1/1) contains two Gi ports.

Basically, the Metro is just one physical device, and with the code changes I've made, the Metro will appear in NAV as one single module with 28 ports. Meaning that submodules are largely ignored by NAV, which now attaches the ports of all submodules to the top module itself.

Port numbering --------------

As you may know, NAV assigns port numbers to switch interfaces. I'm told this is an old convention stemming from the old CatOS CLI implementation, where interfaces only had port numbers and not names. In many parts of the user interface, NAV refers to switch interfaces only by their module and assigned port numbers. In the Cisco case, NAV assigns (or rather, used to assign) port numbers by interpreting interface names and/or descriptions. This means that Fa1/5 would become port 5 on module 1, and Fa2/0/3 would become port 3 on module 20 (!).

On devices with both Fa and Gi interfaces, Cisco reuses these numbers. A module would have both an Fa1/1 and a Gi1/1 interface. NAV would assign the port number 1 to the Fa1/1 interface, and when it found the Gi1/1 interface, it would see a port numbering conflict and assign the ifindex value of the Gi1/1 interface as its port number (typically resulting in something like 10101 as its port number).

With the submodule changes described above, the code will rely more on the the portIfIndex table from the CISCO-STACK-MIB [1]. This table enumerates the interfaces of a Cisco stack into modules and port numbers. For a Metro 3750, this table will actually enumerate all 28 interfaces as port 1 through 28 on module 1.

I've received some criticism for this from people running NAV from the latest trunk revisions, though. Apparently, many Cisco devices will enumerate Gi interfaces before Fa interfaces, meaning that Gi1/1, Gi1/2 and Fa1/1 will become ports 1, 2 and 3 in that order. This represents a change in the port number assignments that NAV has made earlier. Previously, it would have started assigning port numbers to the Fa interfaces first (either because their ifindex values are lower, or because they sort first alphabetically).

Consequently, if you upgrade your NAV installation to the trunk (or the upcoming 3.1.1 version), any switch you have that has both GigabitEthernet and FastEthernet interfaces will have its ports renumbered in NAV. The complaints I've received about this largely revolve around the fact that some users have implemented external systems that relate to NAV by referring to module and port numbers, and that this reference breaks when NAV suddenly decides to assign new port numbers.

A typical example of this would be that when searching for a MAC address in the Machine Tracker before the change, you might be told a machine is connected to foo-sw, module 1, port *5*. Then you upgrade NAV, perform the same search in the Machine Tracker, and now you are told the machine in question is connected to foo-sw, module 1, port *7*. The interface name in these two cases will remain the same, e.g. "FastEthernet1/0/5" or "Fa1/0/5", but this string is not available in the Machine Tracker (yet).

Numbering vs. names -------------------

Now, other feedback we've received (both internal and external) tells us that today, port numbers are largely irrelevant in real world situations. Several network engineers have told us that they care about interface names (the ones they see on the CLI, such as Fa1/5), rather than arbitrary port numbers.

Their viewpoint is that NAV should place more importance on interface names than on port numbers, meaning we should put interface names in all parts of the user interface that has port numbers today, including the Machine Tracker.

The NAV dev-team is leaning towards the latter solution, but this is too big a change for the 3.1.1 bug release, and we might not even have time to do it for version 3.2, which is scheduled for late October.

The question is, what do you, the users, think about this? The situation, as it stands, is that a new port number assignment scheme will turn up in the 3.1.1 bug release, because of the submodule bugfix. This may confuse some people, as interface names are not readily available in many parts of the user interface.

Should we try to stay with a numbering scheme compatible with the old one for the 3.1.1 release, and wait for interface names in the UI before we change the port numbers? This might delay the 3.1.1 release even further, as we need to make changes to the standing bugfix before the release.

Is it okay to renumber ports in the 3.1.1 release, as long as interface names become more prominent in the UI in the 3.2 or 3.3 release? Should we prioritize more prominent interface names in the 3.2 release, or is it okay to wait until the 3.3 release?

Now's your chance to influence these decisions, before further implementation takes place.

[1] http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?objectInput=1.3.6.1.4.1....