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

From: Brooks Davis (brooks_at_one-eyed-alien.net)
Date: 10/28/05

  • Next message: John Baldwin: "Re: kern/87506 : [PATCH] Fix alias support on vr interfaces"
    Date: Fri, 28 Oct 2005 11:04:20 -0700
    To: John Baldwin <jhb@freebsd.org>
    
    
    

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



  • Next message: John Baldwin: "Re: kern/87506 : [PATCH] Fix alias support on vr interfaces"