Date: Tue, 12 Feb 2013 11:28:04 -0700 From: Scott Long <scott4long@yahoo.com> To: Ivan Voras <ivoras@FreeBSD.org> Cc: freebsd-net@freebsd.org Subject: Re: Problems with two interfaces on the same subnet? Message-ID: <F467A7C5-1820-4503-A7A8-26DE7D284FAE@yahoo.com> In-Reply-To: <kfe0ac$fjh$1@ger.gmane.org> References: <kfduar$qrh$1@ger.gmane.org> <D4D47BCFFE5A004F95D707546AC0D7E91F70995D@SACEXCMBX01-PRD.hq.netapp.com> <kfdvck$6ak$1@ger.gmane.org> <CAOjFWZ75GZwYwxuuXotqsfothz2cShbaD9yZQ9Gs5p%2BYbvA7Mw@mail.gmail.com> <kfdvph$92n$1@ger.gmane.org> <kfe0ac$fjh$1@ger.gmane.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Feb 12, 2013, at 11:06 AM, Ivan Voras <ivoras@FreeBSD.org> wrote: > On 12/02/2013 18:57, Ivan Voras wrote: >> On 12/02/2013 18:52, Freddie Cash wrote: >>> Any reason you can't just use lagg(4) in one of the non-LACP modes? That's >>> bascially designed to do exactly what you want. >> >> No particular reason, I'm just not familiar enough with it. Will e.g. >> the "loadbalance" mode "just work" ? Should I expect any problems? > > Actually, I know next to nothing about link aggregation. How do ARP > requests get solved? Would an attached L3-aware switch see the same IP > address on two ports? Since "loadbalance" chooses ports based on a hash, > it will probably start dropping 50% of the outgoing traffic if one of > the two links dies? > > If you use simple load balancing, either via round-robin or hashed flows, then yes, your switch will see 2 MAC addresses and a single IP. I believe that in this scheme only one interface will respond to ARP requests, so peer hosts won't get too confused, and if your switch is only capable of L2, everything will work ok for transmit. I'm less clear on receive; maybe some L2 switches are smart enough to detect this situation and balance incoming traffic, otherwise I can't see how RX traffic to a single MAC could be split to other MACs. If your switch is L3 aware, then yes, the simple load balancing will confuse it. However, if it's L3 aware then it's likely going to implement standardize channel bonding, either in the form of legacy Etherchannel/FEC or more modern LACP/802.3ad. LACP isn't perfect, and it's quite easy for links to physically be up but logically be down, resulting in blackholed traffic, but it's better than FEC. I have patched to made the FreeBSD LAGG/LACP code a little more reliable in this area, and I'll be posting those patching in the coming few days. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F467A7C5-1820-4503-A7A8-26DE7D284FAE>