ifnet renaming interacts badly with vlans

[John Baldwin]

On Monday 21 December 2009 4:44:31 pm John Baldwin wrote:
> On Friday 13 November 2009 12:44:58 pm John Baldwin wrote:
> > 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.
> 
> So I took a more conservative approach so that the change was easier to MFC.
> My current patch adds a new flag to the ifnet if_flags IFF_RENAMING that is
> set during a rename operation.  ifnet attach/detach handlers can then use
> this flag to handle renames differently from other events.  This means that
> no other bits of code have to change to handle renames.  I then changed the
> vlan(4) driver to do what I felt was most intuitive in that it renames the
> child vlan interfaces if their existing name was tied to the parent
> interface.
> 
> However, it turns out that this does not work well with our rc.d scripts.
> Specifically, ifnet_rename() in /etc/network.subr fetches the list of devices
> before any renames happen, so with the auto-renaming feature the vlan gets
> renamed before the vlan interface can have its name changed.  If I remove
> the auto-renaming feature then the example I gave above to rename em0.112
> to foo.bar would work fine.  This is also a smaller and simpler diff to go
> with this approach.  What do other folks thing?
> 
> (Current patch is http://www.FreeBSD.org/~jhb/patches/vlan_rename.patch )

I think I've mostly convinced myself (with the aid of a few other folks) that
the auto-renaming feature should go.  An alternate (and much simpler) patch
that just changes vlan interfaces to ignore detach events that are really
renames is available at vlan_simple.patch.  I have also verified that it
works with our existing rc.d scripts so that you can do the following:

cloned_interfaces="em0.112"
ifconfig_em0_name="foo"
ifconfig_em0_112_name="foo.bar"
ifconfig_foo="inet 192.168.1.1/24"
ifconfig_foo_bar="inet 192.168.2.1/24"

-- 
John Baldwin