Adding an address to a downed LAGG interface breaks it?

Newpol, Richard rnewpol at panasas.com
Mon Aug 5 11:20:44 UTC 2013


By "inconsistent state" i just mean that the driver is not actually up, but the IFF_UP flag is set. The problem is that when the interface is brought up by the user after that (ifconfig lagg0 up), the part of the code that adds the default subnet broadcast routes checks IFF_UP and sees it is set, so it skips the route adds. Normally, the route adds (and a few other things) are done before the IFF_UP flag is set.

Rich Newpol
Panasas
________________________________________
From: Rui Paulo [rpaulo at FreeBSD.org]
Sent: Sunday, August 04, 2013 3:05 PM
To: Newpol, Richard
Cc: freebsd-net at freebsd.org
Subject: Re: Adding an address to a downed LAGG interface breaks it?

On 1 Aug 2013, at 09:22, "Newpol, Richard" <rnewpol at 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.
>
> 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.
>
> 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).
>
> So my first question - is this a known problem, or has it been addressed in some other way?
>
> 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



More information about the freebsd-net mailing list