On Mon, Apr 19, 2004 at 12:28:23PM -0700, Julian Elischer wrote: > It's completely un-needed except that some standards want to access > interfaces by index for statitics purposes.
they're "un-needed" in much the same way that statically assigning disk numbers is "un-needed". sure, the disks don't light on fire without it, but some consistancy and persistance does make things nice. for comparison: vendor C has a default-to-off option for this (''snmp ifindex persist'') which pre-allocates numbers loosely based on max_modules * max_ports_in_modules and dumps this mapping into the filesystem. vendor J allocates dynamically and won't reuse ifIndex numbers over the life of a router. a way of keeping indexes consistant for a given named interface (even across creation/destruction via cloning, kld, etc) is most certainly a desirable feature. the more persistant this can be made (life of the module all the way up to life of device) the better. i disagree that this logic belongs outside the kernel in the snmp agent. an inconsistant if_index makes it difficult and error prone for using the index in multiple utilities whose data may be combined/joined/scaled with information from the snmp agent's IF-MIB/ifXTable tables. -- - bill fumerola / [EMAIL PROTECTED] / [EMAIL PROTECTED] _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"