Date: Mon, 6 Jan 2020 22:46:17 +0700 From: Eugene Grosbein <eugen@grosbein.net> To: Daniel Morandini <danielmorandini@me.com>, freebsd-net@freebsd.org Subject: Re: lagg interface Message-ID: <a58529b2-25b0-3e38-9daf-10b901f157f1@grosbein.net> In-Reply-To: <19FC0FD7-A2C4-442A-BCB2-0CF8D0726EA1@me.com> References: <19FC0FD7-A2C4-442A-BCB2-0CF8D0726EA1@me.com>
next in thread | previous in thread | raw e-mail | index | archive | help
06.01.2020 17:56, Daniel Morandini via freebsd-net wrote: > Dear FreeBSD community, > I am building a prototype router which provides a network access point to its client through a wireless interface > (rtwn0: Realtek 802.11n WLAN Adapter, class 0/0, rev 2.00/2.00, addr 4). > Currently the packets received from the wlan0 interface are NATed through my phone attached via usb cable, > tethering mode enabled (ipheth1: <Apple Inc. iPhone, class 0/0, rev 2.00/8.01, addr 6>). > > What I would to do is to improve the network throughput by exploiting two phones instead of one. > For that I was testing the lagg(4) interface, but I have troubles debugging why the link does not get up > (I never managed to have at least a laggport <ACTIVE>). > >>From what I got from the docs, I cannot expect to be able to use “ acp” as distribution algo, > as it requires the other side of the links (the phones in this case), to implement the proto too, Correct. > and it is not the case. I would expect to see “failover”, “loadbalance” and “roundrobin” to work though. Lagg cannot be used in your case at all, because lagg deals with traffic at layer2 but your setup involves NAT (layer3) that prevents usage of lagg. Also, you better distribute traffic so that all traffic of same client (internal IP) is translated to same external IP address or else clients could have difficulties with some internet services (sites). At very least, traffic from single client to distinct service must be translated to same external IP address. So, you need L3 traffic sharing. One example is using ipfw tables. For N external links (phones) you'd need (N-1) tables, one table for a link excluding first one. With two links, you need only one table listing clients using second link: lan="10.0.0.0/8,192.168.0.0/16" ipfw disable one_pass ipfw table 1 add 10.0.10.200 # a client using second link ipfw table 1 add 192.168.0.5 # another client for second link # translate incoming traffic ipfw delete 50 ipfw add 50 nat 123 ip from any to any in recv ipheth0 ipfw add 50 nat 123 ip from any to any in recv ipheth1 # insert your filtering rules between 50 and 50000 # translate and forward outgoing traffic # clients of second link processed later with rules 50110 etc. ipfw add 50000 skipto 50110 ip from not 'table(1)' to not $lan out # other clients not mentioned in the table are NAT-ed and forwarded here ipfw add 50010 nat 123 ip from $lan to not $lan out ipfw add 50020 fwd $gw1 ip from $nat123_extip to any out # clients using second link are NAT-ed and forwarded here ipfw add 50110 nat 124 ip from $lan to not $lan out ipfw add 50120 fwd $gw2 ip from $nat124_extip to any out
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a58529b2-25b0-3e38-9daf-10b901f157f1>