Send backup replication over the second WAN link with PBR

Cisco IOSWorking

Nightly replication from the backup servers in 10.10.20.0/24 to the DR site 10.200.0.0/16 saturates the primary WAN link and hurts voice. Send only that traffic over the second link (WAN-B) while WAN-B works, fall back to normal routing if it fails, and leave all other traffic on the primary (WAN-A).

R1 interface	Address	Notes
Gi0/0/0	10.0.1.1/30	WAN-A to DR1 10.0.1.2, OSPF cost 1
Gi0/0/1	10.0.2.1/30	WAN-B to DR1 10.0.2.2, `ip ospf cost 100`
Gi0/0/2.10	10.10.10.1/24	users
Gi0/0/2.20	10.10.20.1/24	backup servers

OSPF already runs on both WAN links, so 10.200.0.0/16 is routed over WAN-A. DR1's router ID is 10.255.0.20.

Tasks

Match traffic from 10.10.20.0/24 to 10.200.0.0/16.
Track reachability of DR1's WAN-B address with IP SLA.
Send matched traffic to 10.0.2.2 only while the track is up.
Apply the policy where the backup traffic enters R1.
Prove that replication uses WAN-B and user traffic still uses WAN-A, then fail WAN-B and check the fallback.

Solution

1Match the replication trafficR1

R1 on Cisco IOS

ip access-list extended REPLICATION-TO-DR
 permit ip 10.10.20.0 0.0.0.255 10.200.0.0 0.0.255.255

2Track the WAN-B next hopR1

R1 on Cisco IOS

ip sla 2
 icmp-echo 10.0.2.2 source-interface GigabitEthernet0/0/1
 frequency 5
ip sla schedule 2 life forever start-time now
!
track 2 ip sla 2 reachability
 delay down 10 up 30

3Route-map with a verified next hopR1
R1 on Cisco IOS
```
route-map REPLICATION permit 10
 match ip address REPLICATION-TO-DR
 set ip next-hop verify-availability 10.0.2.2 1 track 2
```
The 1 is a sequence number among possible next hops. When track 2 is down, the next hop is skipped and the packet is routed normally over WAN-A, so a WAN-B outage never black-holes replication.
4Apply inbound on the servers' subinterfaceR1
R1 on Cisco IOS
```
interface GigabitEthernet0/0/2.20
 ip policy route-map REPLICATION
```
PBR is applied where traffic enters the router. The users' subinterface Gi0/0/2.10 has no policy, so user traffic is untouched.

Verify

R1 output

R1# show ip route 10.200.5.10
Routing entry for 10.200.0.0/16
  Known via "ospf 1", distance 110, metric 2, type intra area
  Last update from 10.0.1.2 on GigabitEthernet0/0/0, 03:12:40 ago
  Routing Descriptor Blocks:
  * 10.0.1.2, from 10.255.0.20, 03:12:40 ago, via GigabitEthernet0/0/0
      Route metric is 2, traffic share count is 1

The routing table still says WAN-A. PBR does not change the routing table; it overrides it for matched packets.

SRV1 output

SRV1# traceroute -n 10.200.5.10
traceroute to 10.200.5.10 (10.200.5.10), 30 hops max, 60 byte packets
 1  10.10.20.1  0.412 ms  0.388 ms  0.371 ms
 2  10.0.2.2  1.904 ms  1.887 ms  1.872 ms
 3  10.200.5.10  2.311 ms  2.298 ms  2.290 ms

Hop 2 is DR1's WAN-B address, so replication takes WAN-B.

PC1 output

PC1# tracert -d 10.200.5.10
Tracing route to 10.200.5.10 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  10.10.10.1
  2     1 ms     1 ms     1 ms  10.0.1.2
  3     1 ms     1 ms     1 ms  10.200.5.10

Trace complete.

Users still go over WAN-A (hop 2 is 10.0.1.2).

R1 output

R1# show route-map REPLICATION
route-map REPLICATION, permit, sequence 10
  Match clauses:
    ip address (access-lists): REPLICATION-TO-DR
  Set clauses:
    ip next-hop verify-availability 10.0.2.2 1 track 2  [up]
  Policy routing matches: 18342 packets, 25677218 bytes

The match counter grows while replication runs, and the next hop shows its track state.

R1 output

R1# show track 2 | include Reachability
Reachability is Down

After shutting DR1's WAN-B interface, the track goes down 10 to 15 seconds later (probe timeout plus the 10-second delay), the route-map shows [down], and a new traceroute from SRV1 shows 10.0.1.2 at hop 2: replication falls back to WAN-A.

Mistakes people make

Testing with a ping or traceroute from R1 itself. Router-generated traffic is not policy routed unless you add ip local policy route-map.
Applying the policy on the WAN interface. It must be on the interface where the traffic arrives.
Using set ip next-hop without tracking. If WAN-B fails beyond R1's Ethernet port, replication is black-holed.
Forgetting the return path. DR1 still sends replies over WAN-A unless it has a mirror policy; harmless for routers, fatal through a stateful firewall that only sees one direction.
Using a deny line in the ACL to "exclude" traffic and expecting it to be dropped. A deny only means "not policy routed".

On other platforms

Filter-based forwarding. A forwarding instance holds the alternative route, a firewall filter sends matched traffic into it, and a RIB group copies interface routes so 10.0.2.2 resolves inside the instance.

Junos

set routing-options interface-routes rib-group inet FBF-RIB
set routing-options rib-groups FBF-RIB import-rib [ inet.0 WAN-B.inet.0 ]
set routing-instances WAN-B instance-type forwarding
set routing-instances WAN-B routing-options static route 10.200.0.0/16 next-hop 10.0.2.2
set firewall family inet filter PBR-REPL term repl from source-address 10.10.20.0/24
set firewall family inet filter PBR-REPL term repl from destination-address 10.200.0.0/16
set firewall family inet filter PBR-REPL term repl then routing-instance WAN-B
set firewall family inet filter PBR-REPL term rest then accept
set interfaces ge-0/0/2 unit 20 family inet filter input PBR-REPL

Policy routing with a second table and a rule that selects it.

Linux

ip route add 10.200.0.0/16 via 10.0.2.2 dev eth1 table 100
ip rule add from 10.10.20.0/24 to 10.200.0.0/16 table 100 priority 100

Say it in the interview

"PBR matches the replication flows with an ACL, sets the WAN-B next hop with verify-availability tied to an IP SLA track, and is applied inbound on the servers' subinterface. Everything else follows OSPF over WAN-A. If WAN-B dies, the track drops the next hop and replication falls back to normal routing. I verify from a server, not from the router, because the router's own traffic is not policy routed."

Book 3.4 Routing