interface renaming of an running interface

Brooks Davis brooks at one-eyed-alien.net
Wed Apr 7 11:02:50 PDT 2004


On Wed, Apr 07, 2004 at 11:38:45AM +0200, Harti Brandt wrote:
> 
> I'm currently trying to teach bsnmp to correctly handle interface
> renaming. One problem that I encounter is that a process listening on
> the routing socket sees an interface departure and an interface arrival
> message. This cause interfaces that run stateful protocols like SNMP on
> ATM interfaces to drop all connections which isn't really all that nice.
> The SNMP daemon would also loose all interface state and would report
> the renamed interface as a new interface with a new ifindex. This directly
> violates the IF-MIB RFC, because the daemon is required to understand that
> this is the same interface (the ifindex doesn't really help here, because
> unloading/loading the driver gives the same behaviour). I would like to do
> one of the following two things:
> 
> 1) disallow renaming an interface while it is up, or
> 2) instead of emiting a departure/arrival pair of routing messages,
> generate a rename message.

For the record, I wouldn't object to 1, but I prefer 2.  My view is that
the name is an ephemeral property of an interface intended to the
convenience of the administrator, nothing more.

I random though just hit me as I thought about this message.  For a
variety of good reasons, if_index's are densly packed so if you destroy
an interface and create a new one, you will almost certaintly get the
index of a recently used one.  This leads to the problem that you can't
tell the rename and create-destory operations apart with the current set
of routing messages.  One solution to this problem might be to add a
generation number to the interface either using a global counter or just
a timestamp.

> Additionally I would like to create new sysctls:
> 
> net.link.generic.ifdata.<ifindex>.dname
> net.link.generic.ifdata.<ifindex>.dunit
> 
> to access the driver's name of an interface.

Fine with me.

-- Brooks

-- 
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20040407/5459b3a7/attachment.bin


More information about the freebsd-arch mailing list