Re: interface renaming of an running interface
From: Harti Brandt (novo_at_cs.tu-berlin.de)
Date: 04/08/04
- Previous message: Harti Brandt: "Re: interface renaming of an running interface"
- In reply to: Robert Watson: "Re: interface renaming of an running interface"
- Next in thread: Brooks Davis: "Re: interface renaming of an running interface"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 8 Apr 2004 14:13:38 +0200 (CEST) To: Robert Watson <rwatson@FreeBSD.ORG>
On Wed, 7 Apr 2004, Robert Watson wrote:
> On Wed, 7 Apr 2004, 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.
> >
> > 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.
> >
> > Comments?
>
> I was actually worried about this issue also -- FWIW, the issue already
> exists even without generic interface renaming because some interfaces
> (specifically, if_sl) already support renumbering on demand using ioctl().
> I agree that what we need is a rename event -- the only real question is
> whether and how to handle compatibility for applications that don't know
> what to do with it. Presumably the only real question is for things like
> SNMP and routing daemons, although we've also talked about event
> monitoring for interfaces using devctl, in which case devd would need to
> learn about the "rename" primitive as well.
I don't know how to deal with devctl, but for the routing socket I'd
introduce a new IFAN_RENAME for the ifan_what field of the RTM_IFANNOUNCE
routing message. The interface name in the message would be the new one,
so by tracking these message the daemon will understand what happens.
I'll prepare a patch and try to get some testing on net@.
harti
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
- Previous message: Harti Brandt: "Re: interface renaming of an running interface"
- In reply to: Robert Watson: "Re: interface renaming of an running interface"
- Next in thread: Brooks Davis: "Re: interface renaming of an running interface"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
