Date: Sun, 4 Aug 2013 12:05:11 -0700 From: Rui Paulo <rpaulo@FreeBSD.org> To: "Newpol, Richard" <rnewpol@panasas.com> Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> Subject: Re: Adding an address to a downed LAGG interface breaks it? Message-ID: <CB641B15-652F-40AF-80D0-8586BB0594F2@FreeBSD.org> In-Reply-To: <1A778AD3F807B340B7EB1BD1B9C196773D655FE6@zenyatta.int.panasas.com> References: <1A778AD3F807B340B7EB1BD1B9C196773D655FE6@zenyatta.int.panasas.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 1 Aug 2013, at 09:22, "Newpol, Richard" <rnewpol@panasas.com> wrote: > All, > We seem to have discovered a problem that occurs when adding an = address (or alias) to a DOWNed lagg interface. After adding an address, = when you try to bring the interface UP it can't reach the desired = networks. >=20 > Turns out that the problem occurs because the lagg driver silently = passes the SIOCSIFADDR ioctl to the "ether_ioctl" handler, which in turn = always sets the IFF_UP flag. >=20 > While this is usually ok (since ifconfig <if> <address> implies UP = with the first assigned address anyway), the lagg driver does not have = the proper handling to actually change state to UP on the first address, = so it ends up in an inconsistent state. Then, when the user eventually = does an "ifconfig lagg up" the default subnet routes are not added = (because the "interface up" code sees that IFF_UP is already set). >=20 > So my first question - is this a known problem, or has it been = addressed in some other way? >=20 > Secondly, I can think of two ways to fix this, and was wondering what = are the implications. The first way would be for the lagg driver to = correctly bring itself up when the first address is added to it. The = second way would be for the lagg driver to preserve the state of = IFF_FLAG when handling SIOCSIFADDR. I like the second way because it is = less of an overall behaviour change from the current, but the first way = seems more correct. After you add the first address, you said it comes to an inconsistent = state. Can you clarify? The first approach seems like the right fix but I don't know much about = the problem. The second way breaks the POLA because you're special = casing lagg just to work around a bug. -- Rui Paulo
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CB641B15-652F-40AF-80D0-8586BB0594F2>