Re: kern/87506 : [PATCH] Fix alias support on vr interfaces

On Fri, Oct 28, 2005 at 01:57:04PM -0400, John Baldwin wrote:
> On Thursday 27 October 2005 04:14 pm, Brooks Davis wrote:
> > On Thu, Oct 27, 2005 at 04:02:26PM -0400, Anish Mistry wrote:
> > > On Thursday 20 October 2005 05:29 pm, Brooks Davis wrote:
> > > > On Thu, Oct 20, 2005 at 04:51:21PM -0400, John Baldwin wrote:
> > > > > On Thursday 20 October 2005 02:27 pm, Anish Mistry wrote:
> > > > > > On Thursday 20 October 2005 11:15 am, John Baldwin wrote:
> > > > > > > On Thursday 20 October 2005 10:23 am, Tom McLaughlin wrote:
> > > > > > > > Hi, would someone be available to look at kern PR 87506?  I
> > > > > > > > found the problem while building a jail on my 6.0-RC1 box.
> > > > > > > > When setting an alias on a vr device with ifconfig the
> > > > > > > > alias address replaces the initial address of the device.
> > > > > > > > marcus_at_ took a look at the problem for me and provided the
> > > > > > > > patch for the vr interface which I tested and it resolved
> > > > > > > > the problem. Without the patch I can't create a jail that
> > > > > > > > is network accessible.
> > > > > > > >
> > > > > > > > Marcus also notes in the PR that the rl, sis, ti, and tl
> > > > > > > > may also be affected by this bug.  If anyone has any other
> > > > > > > > questions or needs someone to test any changes to the patch
> > > > > > > > just let me know. I only have vr interfaces on my FreeBSD
> > > > > > > > machines though.  Thanks.
> > > > > > > >
> > > > > > > > Tom
> > > > > > >
> > > > > > > I'm not sure that fix is really the right fix.  The patch
> > > > > > > just makes vr(4) ignore changes to if_flags while the driver
> > > > > > > is up. Probably there is a bug in vr(4)'s handling of alias
> > > > > > > addresses.  I did just reproduce this on my laptop's rl(4)
> > > > > > > interface though. I'll see if I can't figure out what is
> > > > > > > happening.
> > > > > >
> > > > > > I'm also seeing this too along with the following.
> > > > > >
> > > > > > I'm not sure if this is related, but I'm seeing the following
> > > > > > on RELENG_6 and CURRENT, but and older RELENG_5 as of ~2 months
> > > > > > ago doesn't show this problem.
> > > > > > I'm trying to setup my workstation with a normal DHCP'd address
> > > > > > and an alias IP for a jail running on the system, but the alias
> > > > > > setting wipes out all the other addresses on the interface.
> > > > > > in /etc/rc.conf:
> > > > > > ifconfig_rl0="DHCP"
> > > > > > ifconfig_rl0_alias0="inet 192.168.1.10 netmask 255.255.255.255"
> > > > > >
> > > > > > I've checked the rc boot order (on RELENG_6 and CURRENT) and it
> > > > > > seems correct:
> > > > > > netif
> > > > > > dhclient
> > > > > > netif
> > > > > >
> > > > > > I narrowed it down to:
> > > > > > dhclient rl0
> > > > > > ifconfig rl0 inet 192.168.1.11 netmask 0xffffffff alias
> > > > > > [dhclient prints a message here saying connection closed and
> > > > > > exiting]
> > > > > >
> > > > > > All of the other addresses on the card are removed.
> > > > > > I'm also seeing this on dc.  So thinking it to be a problem in
> > > > > > ifconfig I copied over the version from my RELENG_5 box, and
> > > > > > that did the same thing...so this seems to be present several
> > > > > > of the network drivers in RELENG_6/CURRENT.
> > > > >
> > > > > Yes, it seems to be an issue with dhclient.  If I turn dhclient
> > > > > off and manually configure my NIC then the alias works fine:
> > > > > rl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> > > > >         options=8<VLAN_MTU>
> > > > >         inet6 fe80::290:f5ff:fe0e:c8e5%rl0 prefixlen 64 scopeid
> > > > > 0x2 inet 10.50.41.234 netmask 0xfffffe00 broadcast 10.50.41.255
> > > > > inet 10.50.41.101 netmask 0xffffffff broadcast 10.50.41.101 ether
> > > > > 00:90:f5:0e:c8:e5
> > > > >         media: Ethernet autoselect (100baseTX <full-duplex>)
> > > > >         status: active
> > > >
> > > > I believe the problem is that adding an address to a NIC causes a
> > > > call to ifp->if_init() which resets the media and triggers a
> > > > LINK_DOWN event in all too many cases.  Using if_init here is
> > > > rather like driving finishing nails with a sledge hammer.
> > >
> > > Has there been any resolution of this issue? Since 6.0 is just around
> > > the corner.
> >
> > No.  It's going to require non-trivial changes to the design of drivers
> > and eventually some changes to the driver API to really fix this so it's
> > really too late in the game.
> >
> > I think we need to document the lack of support for this configuration
> > and move on.  Frankly, it's a configuration I see no compelling reason
> > to support.  If you are setting alises, you should know what your
> > address is so you don't need dhcp.  I'm aware there are other reasons to
> > want dhcp, but I personally put this sort of thing in the "that would be
> > nice" category.  We should try to fix it, but it's no where near the top
> > of my list.
> 
> Actually, I think the best fix would be to add some de-bounce logic to 
> dhclient so that when it gets a link down state, it waits a second before 
> acting on it, and if it gets a link up event before the second expires it 
> just cancels the pending link down action.  That change would probably go a 
> long way to fixing several people's problems with spurious link state 
> changes.

True.  Dhclient should however complain loudly if it happens with any
kind of frequency.  Note that one second probably won't cut it with many
gigabit nics. :(

-- 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