Difference between revisions of "IfTable indexing"

Revision as of 18:59, 5 August 2008

This page is to document ifIndex issues in net-snmp

inconsistent ifIndex

before the MFD re-writes, different places in the code (different modules) used different methods to determine the ifIndex. This could result in tables that did not agree on the ifIndex for the same interface!

bouncy interfaces

After the MFD re-writes, bouncy interfaces (i.e. ones that go up and down) can cause issues. For example, on linux, pppoe interfaces cause problems.

AFAICT, pppoe interface names remain contstant, even though the connection may be to a different user each time it comes up. In this case, does it really make sense to keep counters?

Also, I believe the kernel assigns a new ifIndex each time the interface comes up. That means that the ifIndex in the ifTable will increase for the same name. For people wanting to monitor a ppp connection to a single place, this is annoying, because most monitoring applications work on ifIndex, and not ifName. For people with lots of ppp connections to different places, this is the correct behaviour (though I wonder how long it will take for the ifIndex to wrap!).

list discussion

see http://sourceforge.net/mailarchive/message.php?msg_id=20051123222939.GA12173%40rigacci.org

possible patches

• There is a patch (here) which deletes old interfaces as new ones show up. This should probably be made configurable. Replacement is solely based on interface name.
• Another alternative that might work would be to identify some tuple (e.g. name an mac addr) to uniquely identify an interface, and try and maintain the original ifIndex in net-snmp code. I think that I cleaned up all code which uses ifIndex to use a common function during the ifTable re-writes, so this might be fairly easy. Some open issues:
  • what to do with counters?
  • interactions with virtual interfaces (xen, vmware, etc)