Date: Thu, 17 Dec 2015 22:16:30 +0300 From: Gleb Smirnoff <glebius@FreeBSD.org> To: Steven Hartland <steven@multiplay.co.uk> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r292379 - in head/sys: netinet netinet6 Message-ID: <20151217191630.GL42340@FreeBSD.org> In-Reply-To: <5672C6AE.7070407@freebsd.org> References: <201512162226.tBGMQSvs098886@repo.freebsd.org> <20151217003824.GG42340@FreeBSD.org> <5672C6AE.7070407@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Steven, On Thu, Dec 17, 2015 at 02:29:02PM +0000, Steven Hartland wrote: S> I would definitely like to understand more about your concerns and learn S> from S> your knowledge in this area, so thanks for that offer, and while it does S> sound S> unforgiving I totally understand where you're coming from. S> S> Hopefully together we can bring this to a satisfactory conclusion as I S> would hate S> for both carp and lagg to stay as broken, 2 years is long enough :D Ok, let's get technical. CARP and LAGG were not broken for 2 years. They were working very well in the way they were designed to work. The setup in the bug 156226 was broken initially. The "link aggregation" itself refers to an aggregation of links between two logical devices. If you build lagg(4) interface on top of two ports that are plugged into different switches, you are calling for trouble. All comments in the 156226 from Eugene Grosbein are valid. I would not repeat them, but ask you to reread them in bugzilla. There was a good reason why for 2 years committers stayed away from this "bug" and related patch. Nevertheless, someone wants to give a kick to this initially broken network design and run it somehow. And this "somehow" implies Layer2 upcalling into upper layers to do something, since there is no established standard layer2 heartbeat packet. I have chatted with networking gurus at my job, and they said, that they don't know any decent network equipment that supports such setup. However, they noticed that Windows is capable for such failover. I haven't yet learned on how Windows solves the problem. Actually, those who pushed committing 156226 should have done these investigations. Probably Windows does exactly the same, sends gratutious ARP or its IPv6 analog. Or may be does something better like sending useless L2 datagram, but with a proper source hardware address. Okay, what if we want same in FreeBSD as in Windows? Should we do the following list of evil things: - put DELAY in context of callout(or in context of any network processing) - introduce new notions of a link state, or new KPI for link handling Note that link handling KPI was stable for iver 10 years and satisfied all the different types of interfaces we support - create new interface methods - call into address families supplying an ifnet that doesn't have this AF instantiated, and then to fix immediate panic putting there a kludge of "if (foo == NULL) return;" - etc... Sorry, I'm putting "etc" here, because tires on details. You would agree that the whole process of fixing the "bug" was overcoming the problems that the network stack is not designed for the things that you are willing to do. Won't you agree? Or should we just write a tiny program, that would observe state of networking ports, and if a port changes state then send a tiny packet as a bpf(4) write? -- Totus tuus, Glebius.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20151217191630.GL42340>