Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 19 Apr 2004 15:43:30 -0700
From:      Bill Fumerola <billf@FreeBSD.org>
To:        Julian Elischer <julian@elischer.org>
Cc:        net@freebsd.org
Subject:   Re: what is the story on if_index allocation ?
Message-ID:  <20040419224330.GN17862@elvis.mu.org>
In-Reply-To: <Pine.BSF.4.21.0404191227150.64627-100000@InterJet.elischer.org>
References:  <20040419110912.A71274@xorpc.icir.org> <Pine.BSF.4.21.0404191227150.64627-100000@InterJet.elischer.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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 / fumerola@yahoo-inc.com / billf@FreeBSD.org




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040419224330.GN17862>