Dual PAT for Active/Active ISP Network not working

[rbantok7795]

Hi All,

We're implementing an Active/Active ISP link with failover for a client. A ISR4331 will provide policy routes for both ISP links, while a FG100F will handle the SLA for failover. Unfortunately, we are encountering a problem. It seems that when we put two PAT statements on the router, the interface of the other ISP will be unpingable, even if the ISP link is directly connected to the router.

Here is our configuration (100.1.1.1/2 and 200.1.1.1/2 are the dummy ISP links, changed for security purposes)

interface GigabitEthernet0/0
ip address 10.1.1.2 255.255.255.252
ip nat inside
ip virtual-reassembly in
ip policy route-map PBR1
duplex auto
speed auto
media-type rj45
!
interface GigabitEthernet0/1
ip address 10.2.2.2 255.255.255.252
ip nat inside
ip virtual-reassembly in
ip policy route-map PBR2
duplex auto
speed auto
media-type rj45
!
interface GigabitEthernet0/2
ip address 100.1.1.2 255.255.255.248
ip nat outside
ip virtual-reassembly in
duplex auto
speed auto
media-type rj45
!
interface GigabitEthernet0/3
ip address 200.1.1.2 255.255.255.248
ip nat outside
ip virtual-reassembly in
duplex auto
speed auto
media-type rj45

ip nat inside source route-map PBR1 interface GigabitEthernet0/2 overload
ip nat inside source route-map PBR2 interface GigabitEthernet0/3 overload
ip route 0.0.0.0 0.0.0.0 100.1.1.1
ip route 0.0.0.0 0.0.0.0 200.1.1.1

ip access-list standard TO_ISP1
permit any
ip access-list standard TO_ISP2
permit any

route-map PBR1 permit 10
match ip address TO_ISP1
set ip next-hop 100.1.1.1
!
route-map PBR2 permit 10
match ip address TO_ISP2
set ip next-hop 200.1.1.1

For example, from the current configuration I've provided, the ISP2 interface (200.1.1.1) is unpingable. But if we remove the nat statement for ISP1 (ip nat inside source route-map PBR1 interface GigabitEthernet0/2 overload), the ISP2 interface becomes pingable. 

Does Cisco ISRs support more than one active PAT statements? If yes, how can we implement it properly?

[paul driver]

Hello

You don't require to specify two default static routes as the policy base routing will work without it and at present those two defaults looks like are causing the connection problem

However you do need to have resilient static routes so I suggest you apply a tracking via ip sla tracking on the primary default static route in case of failure and then on the secondary default route give that a high admin distance so it takes precedence when the primary fails and is removed from the route table.

Lastly Cisco recommends not to use "any any" in NAT access-lists, so be as specific as possible.  

Example:

ip sla 10
icmp-echo 8.8.8.8
ip sla schedule 10 life forever start-time now
track 10 ip sla 10 reachability

ip access-list standard TO_ISP1
no 10
permit ip 10.1.1.0 0.0.0.3 any

ip access-list standard TO_ISP2
no 10
permit ip 10.2.2.0 0.0.0.3 any

no ip route 0.0.0.0 0.0.0.0 100.1.1.1
no ip route 0.0.0.0 0.0.0.0 200.1.1.1

ip route 8.8.8.8 255.255.255.255 100.1.1.1
ip route 8.8.8.8 255.255.255.255 null 0 10
ip route 0.0.0.0 0.0.0.0 100.1.1.1
ip route 0.0.0.0 0.0.0.0 200.1.1.1 2 track 10