Dual WAN Egress: Policy Routing and Active/Standby Failover in Practice

My boss bought a second ISP line. His words: "I don't want to hear that a single line going down for maintenance takes the whole company offline." It sounds like he's expecting automatic load-balancing magic, but the real work comes down to three questions: which line wins as the active/standby default route, which services get pinned to a specific line, and what happens to TCP sessions when we switch.

Topology

[内网核心] --- [出口防火墙/路由器]
                    |            |
                 WAN1 电信     WAN2 联通

One default gateway on the inside, and all the dual-egress convergence happens on the firewall. That's far less confusing than juggling a pile of PBR rules on the core switch — unless you already run a mature L3 core team.

The active/standby default route

WAN1 has the better metric (active)
WAN2 is backup; probe it with link detection or target-IP reachability (mind the ISP's ICMP rate limiting)
Write the failover trigger down explicitly: latency? packet loss? or interface down?

Interface down is the easiest thing to judge. Don't auto-failover on "web pages feel slow" — otherwise you'll flap back and forth while both lines are half-broken.

Policy routing: who must stay pinned

Traffic	Policy
Regular internet	Active line; fail over to standby when it dies
Bank/government IP whitelists	Pinned to the exact public egress you declared to them
Site VPN / leased-line backup	Independent tunnel, doesn't fight the public internet for jitter
Guests	Can ride the standby line, freeing the main line for employees

Whitelisted services are the worst trap: you think you're building high availability, but the counterparty only recognizes the NAT address you registered with them. A switchover is an outage. Mark this class in red on the diagram: "must not auto-drift".

NAT and sessions

Each WAN gets its own source NAT pool
After a switchover, most old sessions will need to reconnect — tell the business up front that "second-fast failover ≠ zero disconnects"
Symmetrical routing: the return path has to come back out the correct WAN, or you'll get sporadic "can send, can't receive"

One failed "load balancing"

Early on I enabled session-based load spreading. Half a morning later, finance reported online-banking dropouts and video meetings where audio and video desynced. Root cause: multiple sessions of the same workload spread across two lines of different quality. I switched to default active/standby plus a few pinned policies, and stability came right back. Load balancing is a capability, not an obligation.

The drill checklist (actually pull the cable)

In a weekday-evening maintenance window, physically unplug WAN1
Watch the switchover time, whether DNS still resolves, AD/email/business VPN
Restore WAN1; does it fail back, and does it flap a second time?
Record the felt RTO and put it in the ops runbook

# 检查表示意
show ip route
show session table  # 名称随设备
ping 探测目标 source 对应 WAN

Who is the documentation for?

For the boss: one number — how long before the internet comes back when the active line dies.
For yourself: probe IPs, the policy table, the whitelisted-service list, and the ISP repair hotline numbers.

The value of dual egress isn't the phrase "smart path selection" in the spec sheet. It's that when something fails, you don't have to explain why everyone is offline. A failover you've actually drilled belongs on your resume; buying two lines and never pulling one is just paying rent twice.

Blog