Date: Fri, 13 Nov 2009 12:44:58 -0500 From: John Baldwin <jhb@freebsd.org> To: net@freebsd.org Cc: Brooks Davis <brooks@FreeBSD.org> Subject: ifnet renaming interacts badly with vlans Message-ID: <200911131244.58819.jhb@freebsd.org>
next in thread | raw e-mail | index | archive | help
So first the problem I am trying to solve. I would like to give meaningful
aliases to interfaces and vlans on interfaces. For example, suppose I would
I have em0 with a vlan of 112, but I would like to call em0, "foo" and
em0.112, "foo.bar". One can do this if you do things in this order:
ifconfig em0 name foo
ifconfig foo.112 create
ifconfig foo.112 name foo.bar
However, our rc.d scripts want to create all cloned interfaces before applying
renames, so to attempt to do this in /etc/rc.conf you would use something
like:
cloned_interfaces="em0.112"
ifconfig_em0_name="foo"
ifconfig_em0_112_name="foo.bar"
However, this ends up doing a sequence more like:
ifconfig em0.112 create
ifconfig em0 name foo
ifconfig em0.112 name foo.bar
Unfortuantely, this sequence breaks em0.112 at the second step. The reason is
that when em0 is renamed, the kernel actaully fires off event handlers
claiming that the em0 ifnet has been detached and that a new foo ifnet has
been attached. When this happens, the em0.112 vlan ifnet is orphaned.
I think this is a bug in how renames are handled. Specifically, I don't think
renaming an interface should always have the same semantics as if I had
physically removed an interface and then later added it back. One
alternative would be to instead broadcast a single "rename" event when an
interface is renamed and things that cared about interface names (such as
firewall rules) could still honor those events, but other subsystems might
choose to ignore said events (e.g. vlan devices). Another alternative might
be to use two different events ('ifnet_removed_name' and 'ifnet_added_name').
Subsystems that care about the name changing could reuse their existing
detached/attached handlers for those two events without needing to change the
event handlers themselves. A separate issue if the eventhandlers were
changed is if we should use a different routing socket message when an
interface is renamed or if it we should still claim that an interface has
gone away and then come back. Given that we don't flush addresses from an
interface when the name changes or even the ifindex it seems a bit
disingenous to claim that the interface has detached and then reattached.
--
John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200911131244.58819.jhb>