Date: Wed, 19 Feb 2020 11:34:56 -0800 From: Doug Hardie <bc979@lafn.org> To: Valeri Galtsev <galtsev@kicp.uchicago.edu> Cc: FreeBSD <freebsd-questions@freebsd.org> Subject: Re: Switching to backup Network Message-ID: <F4A178DC-4BFB-49DA-A0BE-5C77476E1098@mail.sermon-archive.info> In-Reply-To: <FE259796-0D7E-478A-862A-EF9D6B913425@kicp.uchicago.edu> References: <64F39D12-E061-4726-B58E-943D61963944@mail.sermon-archive.info> <50d6c0e2-8e70-0743-1e9c-f4c36847a015@kicp.uchicago.edu> <F81D7D30-444B-4982-85BB-B2E3AED5C6BE@mail.sermon-archive.info> <FE259796-0D7E-478A-862A-EF9D6B913425@kicp.uchicago.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 19 February 2020, at 06:32, Valeri Galtsev = <galtsev@kicp.uchicago.edu> wrote: >=20 >=20 >=20 >> On Feb 18, 2020, at 7:29 PM, Doug Hardie <bc979@lafn.org> wrote: >>=20 >>> On 18 February 2020, at 12:25, Valeri Galtsev = <galtsev@kicp.uchicago.edu> 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 >=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. >=20 > Hopefully, some lagg expert will offer you help. It may make sense to = ask on freebsd-net list. >=20 > Valeri >=20 I discovered there are three things you lose when you get older. The = first is your memory. I've forgotten the other two. Apparently I had started a development earlier and actually got a = solution working, but never included it in my client's system. I = encountered it, by accident, last night and included it. This only = applies to the code I developed for the client, but I replaced the = connect and tcp_connect calls with new modules that test the returns = from those and then use setfib to try the backup if the primary is not = available. This solves the big issue for my client as his faxes now are = being delivered using the backup network when the primary is down. It = doesn't solve the problem for things like email, but the client usually = uses his PCs for that. I just lose things like the periodic emails = (they aren't lost, but significantly delayed as postfix is being used). The primary benefit of this is my client's customers are not affected by = the down time. My client now reports that he thinks the problem is = caused by the cable from the NIC to the router being too short and = having too much stress. This is a remote location so I have no idea = what it looks like. However, it is interesting to note that my client = did the physical setup and is a Microsoft Certified Network Engineer ;-) -- Doug
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F4A178DC-4BFB-49DA-A0BE-5C77476E1098>