IfTable indexing - Revision history

Jsafranek at 15:03, 28 July 2011

2011-07-28T15:03:40Z

Jsafranek: update the link

2011-05-05T11:34:54Z

update the link

Rstory: /* bouncy interfaces */

2008-08-05T18:59:34Z

‎bouncy interfaces

Rstory at 16:18, 3 November 2006

2006-11-03T16:18:32Z

New page

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!).

← Older revision		Revision as of 15:03, 28 July 2011
Line 20:		Line 20:
	** what to do with counters?		** what to do with counters?
	** interactions with virtual interfaces (xen, vmware, etc)		** interactions with virtual interfaces (xen, vmware, etc)
		+
		+	==actual status==
		+	* by default, interfaces which disappear from system are automatically removed from ifTable in 5 minutes (use interface_fadeout config option to adjust this interval)
		+	* if interface_replace_old is set, it will remove all old ifTable entries with the same ifName as newly appeared interface (with different ifIndex)

@@ Line 12: / Line 12: @@
 ==list discussion==
-see http://sourceforge.net/mailarchive/message.php?msg_id=20051123222939.GA12173%40rigacci.org
+see https://sourceforge.net/mailarchive/forum.php?thread_name=20051123222939.GA12173%40rigacci.org&forum_name=net-snmp-coders
 ==possible patches==

← Older revision		Revision as of 18:59, 5 August 2008
Line 10:		Line 10:

	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!).		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 ([http://sourceforge.net/tracker/index.php?func=detail&aid=1513191&group_id=12694&atid=312694 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)