Two internet uplinks on one enterprise router, configured two different ways — equal-preference static routes with source-IP hashing for load sharing, or a preference gap between routes for primary/backup failover — with NAT outbound on each link and the commands that show which uplink is actually carrying traffic right now.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
Redundancy and bandwidth are two different problems, and they call for two different route setups on the same pair of links.
An enterprise router with a single internet uplink has exactly one failure mode: that link goes down, and the office goes offline with it. Adding a second uplink to a second ISP fixes that — but only if the router is told what to do with the second link. Left to route selection alone, two default routes of equal weight will simply load-share, which is great for bandwidth but means a single link failure still drops roughly half of all sessions instead of failing over cleanly.
Below are the two configurations this note is based on: static-route load sharing across two links using source-IP hashing, and a primary/backup setup using route priority — both with NAT outbound configured on each uplink, and the commands that confirm which link is actually carrying traffic. If your office is still on a single public IP address and hasn't configured basic outbound NAT yet, our Easy IP NAT configuration guide covers that first step.
One router, two independent static-IP uplinks to two ISPs, and one internal segment — the same physical layout serves both configurations below.
Diagram labels are kept in English for engineering clarity.
Addressing
| Item | Value (this example) |
|---|---|
| Link 1 interface — GigabitEthernet0/0/1 | 172.16.1.1/24 |
| ISP1 gateway (link 1 peer) | 172.16.1.2/24 |
| Link 2 interface — GigabitEthernet0/0/2 | 10.1.1.1/24 |
| ISP2 gateway (link 2 peer) | 10.1.1.2/24 |
| Internal (LAN) interface — GigabitEthernet0/0/3 | 192.168.1.1/24 |
| Internal LAN segment | 192.168.1.0/24 |
Two equal-preference default routes plus source-IP hashing — both uplinks carry traffic at the same time.
#
sysname Router
#
ip load-balance hash src-ip
#
acl number 3002
rule 5 permit ip source 192.168.1.0 0.0.0.255
#
interface GigabitEthernet0/0/1
undo portswitch
ip address 172.16.1.1 255.255.255.0
nat outbound 3002
#
interface GigabitEthernet0/0/2
undo portswitch
ip address 10.1.1.1 255.255.255.0
nat outbound 3002
#
interface GigabitEthernet0/0/3
undo portswitch
ip address 192.168.1.1 255.255.255.0
#
ip route-static 0.0.0.0 0.0.0.0 172.16.1.2
ip route-static 0.0.0.0 0.0.0.0 10.1.1.2
#
returnSame physical topology, one different number — give the backup route a higher preference value, and it stays out of the routing table until the primary genuinely fails.
#
sysname Router
#
acl number 3002
rule 5 permit ip source 192.168.1.0 0.0.0.255
#
interface GigabitEthernet0/0/1
undo portswitch
ip address 172.16.1.1 255.255.255.0
nat outbound 3002
#
interface GigabitEthernet0/0/2
undo portswitch
ip address 10.1.1.1 255.255.255.0
nat outbound 3002
#
interface GigabitEthernet0/0/3
undo portswitch
ip address 192.168.1.1 255.255.255.0
#
ip route-static 0.0.0.0 0.0.0.0 172.16.1.2
ip route-static 0.0.0.0 0.0.0.0 10.1.1.2 preference 100
#
returnThe ones that make a dual-WAN setup silently do the opposite of what was intended.
SYMPTOMThe backup link was configured with preference 100 expecting it to be prioritized, but the primary link keeps carrying all the traffic while both are up — which, it turns out, is correct.
CAUSEFor static routes, a larger preference number means a lower priority, not a higher one. The default is 60; setting the backup to 100 makes it numerically larger and therefore less preferred, exactly as intended for a backup route.
FIXLeave the primary route at the default preference (60) and only raise the number on the route meant to be the backup — never lower the primary's number thinking that makes it “more primary”.
SYMPTOMTwo equal-preference default routes are configured, one via each ISP, but all outbound traffic still leaves through a single link.
CAUSETwo static routes with the same preference sit in the routing table together, but the router still needs to be told explicitly how to spread traffic across them — the two-route configuration by itself doesn't select a hashing method.
FIXAdd ip load-balance hash src-ip. Without it, having two equal-preference routes is necessary for load sharing but isn't sufficient on its own.
ip load-balance hash src-ipSYMPTOMTraffic sent out through link 2 reaches nowhere, even though its route and interface are both configured and up.
CAUSEnat outbound is configured per interface. Applying it only to GigabitEthernet0/0/1 and forgetting GigabitEthernet0/0/2 means any session routed out the second link never gets translated — it leaves with a private source address the ISP will simply drop.
FIXApply nat outbound with the same ACL on every uplink interface individually — in this example, both GigabitEthernet0/0/1 and GigabitEthernet0/0/2.
interface GigabitEthernet0/0/1
nat outbound 3002
interface GigabitEthernet0/0/2
nat outbound 3002SYMPTOMOn a PPPoE-based uplink, nat outbound applied to the physical Ethernet interface underneath the dial-up session doesn't translate anything.
CAUSEWhen an uplink dials out over PPPoE, the IP address actually belongs to the Dialer interface, not the physical port carrying the PPPoE session — the source material's own configuration comments flag this explicitly for exactly this reason.
FIXConfigure nat outbound on the Dialer interface itself, matching the pattern used for a static-IP uplink but pointed at the Dialer instead of the physical GigabitEthernet port.
interface Dialer1
nat outbound 3002The routing table tells you which route is Active right now — that's different from which routes simply exist.
<Router> display ip routing-table protocol static
Route Flags: R - relay, D - download to fib, T - to vpn-instance
------------------------------------------------------------------------------
Public routing table : Static
Destinations : 1 Routes : 2 Configured Routes : 2
Static routing table status : <Active>
Destinations : 0 Routes : 0
Static routing table status : <Inactive>
Destinations : 1 Routes : 2
Destination/Mask Proto Pre Cost Flags NextHop Interface
0.0.0.0/0 Static 60 0 172.16.1.2 Unknown
0.0.0.0/0 Static 60 0 10.1.1.2 UnknownLoad-sharing configuration: both default routes carry the same preference (60) — that equal weight is what makes source-IP hashing split traffic between them.
<Router> display ip routing-table protocol static
Route Flags: R - relay, D - download to fib, T - to vpn-instance
------------------------------------------------------------------------------
Public routing table : Static
Destinations : 1 Routes : 2 Configured Routes : 2
Static routing table status : <Active>
Destinations : 0 Routes : 0
Static routing table status : <Inactive>
Destinations : 1 Routes : 2
Destination/Mask Proto Pre Cost Flags NextHop Interface
0.0.0.0/0 Static 60 0 172.16.1.2 Unknown
0.0.0.0/0 Static 100 0 10.1.1.2 UnknownPrimary/backup configuration: the backup route's preference (100) is the numerically larger, lower-priority value. Both routes in the source documentation's own lab capture show under the Inactive section rather than Active — that reflects the next-hop reachability of that particular lab run; in a live deployment, the route matching a genuinely reachable gateway shows Active instead.
This note is based on two worked configurations from the same source material: static-IP uplinks in load-sharing mode and in primary/backup mode, both using route preference and, for load sharing, source-IP hashing. It doesn't cover NQA-linked static routes — which actively probe a remote address and pull a route out of the table the moment that probe fails, catching an ISP-side outage even while the local interface itself stays up, something plain preference-based failover here cannot detect. It also doesn't cover dynamic routing protocols for multi-uplink selection, or three or more uplinks at once. If either uplink is a single public IP address you're just now configuring for basic internet access, start with our Easy IP NAT configuration guide.
Pulled from the same configuration cases this note is built on.
Load sharing keeps both links carrying traffic at the same time, split by a hash of the source address — good for aggregate bandwidth, but a single link failure still drops whatever traffic was hashed onto it. Primary/backup keeps one link idle in the routing table until the primary's route is no longer valid, so failover is clean but the backup link's bandwidth sits unused day to day.
Yes, for the life of that hash assignment — ip load-balance hash src-ip distributes different source addresses across the two equal-preference routes, but a single source address's sessions stay pinned to whichever link its hash lands on rather than being split packet by packet across both.
Yes — the source material this note is based on includes exactly that combination. The static-IP link is configured as shown here; the PPPoE link's route points at its Dialer interface instead of a gateway address, and its NAT outbound rule lives on that same Dialer interface rather than the physical port underneath it.
Run display ip routing-table protocol static again after taking the primary link down. The backup route (preference 100 in this example) should now be the one showing as Active, and pinging the ISP2 gateway address should succeed while the ISP1 gateway no longer responds.
Not until the second uplink is actually in place. A single-uplink office should start with basic Easy IP outbound NAT — see our Easy IP NAT configuration guide — and revisit this note once a second ISP connection is being added.
Tell us whether you need load sharing, clean failover, or both, and whether either link is PPPoE — we'll help you get the route priorities and NAT outbound placement right the first time.