From owner-freebsd-questions@freebsd.org Wed Feb 19 14:32:37 2020 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8FB3023BFF3 for ; Wed, 19 Feb 2020 14:32:37 +0000 (UTC) (envelope-from galtsev@kicp.uchicago.edu) Received: from kicp.uchicago.edu (kicp.uchicago.edu [128.135.20.70]) by mx1.freebsd.org (Postfix) with ESMTP id 48N0Yb57GJz4HSp for ; Wed, 19 Feb 2020 14:32:35 +0000 (UTC) (envelope-from galtsev@kicp.uchicago.edu) Received: from [IPv6:2607:fb90:17ca:898e:e9f4:b239:49fb:8d23] (unknown [172.58.139.203]) (Authenticated sender: galtsev) by kicp.uchicago.edu (Postfix) with ESMTPSA id ACCC74E6B9; Wed, 19 Feb 2020 08:32:34 -0600 (CST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Subject: Re: Switching to backup Network From: Valeri Galtsev In-Reply-To: Date: Wed, 19 Feb 2020 08:32:33 -0600 Cc: FreeBSD Content-Transfer-Encoding: quoted-printable Message-Id: References: <64F39D12-E061-4726-B58E-943D61963944@mail.sermon-archive.info> <50d6c0e2-8e70-0743-1e9c-f4c36847a015@kicp.uchicago.edu> To: Doug Hardie X-Mailer: Apple Mail (2.3608.60.0.2.5) X-Rspamd-Queue-Id: 48N0Yb57GJz4HSp X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=uchicago.edu (policy=none); spf=none (mx1.freebsd.org: domain of galtsev@kicp.uchicago.edu has no SPF policy when checking 128.135.20.70) smtp.mailfrom=galtsev@kicp.uchicago.edu X-Spamd-Result: default: False [-1.03 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[uchicago.edu : No valid SPF, No valid DKIM,none]; RECEIVED_SPAMHAUS_PBL(0.00)[203.139.58.172.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-0.99)[-0.990,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.12)[ip: (0.34), ipnet: 128.135.0.0/16(0.17), asn: 160(0.13), country: US(-0.05)]; NEURAL_HAM_MEDIUM(-0.75)[-0.754,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[70.20.135.128.list.dnswl.org : 127.0.10.0]; R_SPF_NA(0.00)[]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:160, ipnet:128.135.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2020 14:32:37 -0000 > On Feb 18, 2020, at 7:29 PM, Doug Hardie wrote: >=20 >> On 18 February 2020, at 12:25, Valeri Galtsev = wrote: >>=20 >>=20 >>=20 >> On 2020-02-18 14:19, Doug Hardie wrote: >>> One of my clients has a machine running 12.1 that is connected via = two different NICs to two different WANs. He has drops from 2 different = ISPs to provide redundancy. I have configured each of the DNS names with = both IP addresses so that web access will switch over to the backup when = the primary is down. Setfib and pf are used to make that work. That = works fine (although there is a DNS timeout involved). The problem is = that all the servers on the machine talk out via the primary IP address. = While web access continues, the server initiated functions fail because = the next hop is down. Is there a way to switch everything over to the = backup network in this case? I don't find anything that enables = automatic changes to the default network. >>> Also, when the backup network goes down, the default network entry = for setfib 1 route is deleted. I have to manually enter that when it = comes backup. I am initially setting that in /etc/rc.local. Is there a = way to make it either remain, or be restored? >>>=20 >>=20 >> I would look into link aggregation (lagg): >>=20 >> = https://www.freebsd.org/doc/en/books/handbook/network-aggregation.html >>=20 >> I used that to make my FreeBSD laptop switch over from WiFi to = ethernet interface when the last link is available. Worked neat for me. >>=20 >> Valeri >>=20 >=20 > Lagg looks neat, but my first setup didn't work. I suspect the issue = is the IP addresses. Each of the two networks have quite different IPs. = Both are fixed IP addresses but from different allocations. It appears = that lagg requires the use of one IP for both networks. All the = examples use just one IP address for both networks. >=20 I did not look into setting lagg for two ethernet interfaces, mine was = for ethernet + WiFi. But they were definitely on different networks. = Additional simplicity of my case was: both interfaces were DHCP clients = (that took care of routing auto-magically). There was one =E2=80=9Chack=E2= =80=9D I did in my case: I have a vague recollection I made both = adapters under lagg have the same MAC address (by changing one of them), = but that likely was due to my insufficient knowledge or laziness when I = was setting it up. Expert probably will do it without that hack. I still = have a feeling, one can do it for static IPs (my laptop configuration = does work for interfaces on different networks), that=E2=80=99s why I = suggested to look into that. Hopefully, some lagg expert will offer you help. It may make sense to = ask on freebsd-net list. Valeri > -- Doug >=20 >=20 > _______________________________________________ > freebsd-questions@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to = "freebsd-questions-unsubscribe@freebsd.org" ++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++