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. >>=20 >> No particular reason, I'm just not familiar enough with it. Will e.g. >> the "loadbalance" mode "just work" ? Should I expect any problems? >=20 > 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? >=20 >=20 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>