TTR Networks

Intermediate · Two internet connections on VyOS · section 3 of 7

Health checks that test the right thing

✓ Lab-tested 21 October 2026 on VyOS 2026.10.16-0024-rolling, Debian 12 hosts

VyOS's WAN load balancing (load-balancing wan) adds health checks. It tests each ISP regularly, and steers the LAN's traffic accordingly. In failover mode, the interface with the highest weight is used while it's healthy, and the next one takes over when it isn't.

  • interface-health: per ISP, the next hop, and one or more tests (here, ping).
  • failure-count and success-count: how many tests in a row must fail before the ISP is marked failed, and succeed before it's used again.
  • rule 10: traffic arriving from the LAN (eth2) uses ISP1 (weight 10), failing over to ISP2 (weight 1).
  • disable-source-nat: WAN load balancing would add its own source NAT; the lab keeps the explicit NAT rules from before instead.

Test beyond the next hop

The first version tested each ISP by pinging its own router, the next hop. With ISP1's upstream still broken, both ISPs showed active, and the office stayed offline: the next hop was fine, so the check passed.

The second version pings a target out on the internet through each ISP. It needs two details:

  • A target per ISP, with a host route through that ISP. VyOS sends the test with ping -I eth1, and that needs a route out of eth1. Without the host routes, R1 only has a default route through ISP1, so ISP2's test failed too, even though ISP2 was working. In the lab the targets are two addresses on the internet server; in real life, use two reliable public hosts, preferably ones you or your ISPs don't depend on for anything else.
  • Something that really is beyond the ISP, not its own router or DNS server.

Now ISP1 is failed, ISP2 is active, and the LAN's traffic reaches the server from ISP2's address, 198.51.100.2.

WAN load balancing, checking only the next hop
set load-balancing wan disable-source-nat
set load-balancing wan interface-health eth0 failure-count '2'
set load-balancing wan interface-health eth0 success-count '1'
set load-balancing wan interface-health eth0 nexthop '203.0.113.1'
set load-balancing wan interface-health eth0 test 10 type 'ping'
set load-balancing wan interface-health eth0 test 10 target '203.0.113.1'
set load-balancing wan interface-health eth1 failure-count '2'
set load-balancing wan interface-health eth1 success-count '1'
set load-balancing wan interface-health eth1 nexthop '198.51.100.1'
set load-balancing wan interface-health eth1 test 10 type 'ping'
set load-balancing wan interface-health eth1 test 10 target '198.51.100.1'
set load-balancing wan rule 10 description 'LAN: ISP1, failing over to ISP2'
set load-balancing wan rule 10 inbound-interface 'eth2'
set load-balancing wan rule 10 failover
set load-balancing wan rule 10 interface eth0 weight '10'
set load-balancing wan rule 10 interface eth1 weight '1'
  • Line 1: Keep the explicit NAT rules instead of WAN load balancing's own.
  • Lines 2–6: ISP1: failed after 2 bad tests, back after 1 good one; the test pings ISP1's own router.
  • Lines 7–11: The same for ISP2.
  • Lines 12–16: LAN traffic: ISP1 first, ISP2 if ISP1 fails.
With ISP1's upstream still broken (real output)
vyos@R1:~$ show wan-load-balance
Interface: eth0
Status: active
Last Status Change: 2026-10-21 09:21:42
Last Interface Success: 0:00:29.470445
Last Interface Failure: N/A
Interface Failures: 0

Interface: eth1
Status: active
Last Status Change: 2026-10-21 09:21:42
Last Interface Success: 0:00:29.289067
Last Interface Failure: N/A
Interface Failures: 0
  • Lines 2–14: Both healthy, according to the next-hop check.
…while the office stays offline (real output)
root@lanhost:~# curl -s -m 5 http://192.0.2.10/ || echo "no answer"
no answer
Test beyond each ISP instead
set protocols static route 192.0.2.101/32 next-hop 203.0.113.1
set protocols static route 192.0.2.102/32 next-hop 198.51.100.1
set load-balancing wan interface-health eth0 test 10 target '192.0.2.101'
set load-balancing wan interface-health eth1 test 10 target '192.0.2.102'
  • Lines 1–2: A host route to each target through its own ISP, so ping -I eth1 has a way out.
  • Lines 3–4: Targets on the internet, one per ISP.
Now ISP1 is failed (real output)
vyos@R1:~$ show wan-load-balance
Interface: eth0
Status: failed
Last Status Change: 2026-10-21 09:24:22
Last Interface Success: N/A
Last Interface Failure: 0:00:23.997456
Interface Failures: 2

Interface: eth1
Status: active
Last Status Change: 2026-10-21 09:24:22
Last Interface Success: 0:00:23.841882
Last Interface Failure: N/A
Interface Failures: 0
  • Lines 2–7: ISP1's test target is unreachable: failed after two tests.
  • Lines 9–14: ISP2 is fine.
…and the office is back online (real output)
root@lanhost:~# curl -s -m 5 http://192.0.2.10/ || echo "no answer"
hello from server

root@server:~# tail -1 /tmp/http.log
198.51.100.2 - - [21/Oct/2026 09:24:46] "GET / HTTP/1.1" 200 -
  • Lines 4–5: Through ISP2, with ISP2's address.

Check your understanding

Why does each health-check target need a host route through its own ISP?

  • The check pings with -I for that interface, and without a route out of it, the test fails however healthy the ISP is.
  • So the LAN's traffic to the target uses that ISP.
  • Because VyOS refuses to commit without them.
  • To make the pings faster.