02-12-2020 10:36 AM
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?
02-12-2020 11:08 AM - edited 02-12-2020 01:26 PM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide