STATIC NAT FAIL-OVER OVER TWO DIFFERENT ISPs

[okoroji80]

Hi Community Members.,

Am wondering if anyone has the above solution:

A static NAT fail-over  on two ISP link with Active-Active mode of operation>

The solution is for the server with internal IP:192.168.20.200 to still be reachable over the internet when any of the ISP links fails ( i.e to be able to fail-over each time any of the ISPs  fails)

Below is my config:

route-map ISP1_P2P_NAT permit 10
match interface Vlan10
!

route-map ISP2_LAYER2_NAT permit 10
match interface Vlan1
!

interface GigabitEthernet8
description LINK_TO_WAN
ip address 20.18.172.46 255.255.255.252
ip nat outside

!

interface Vlan2019
description BROADBAND_LTE
ip address 153.30.69.67 255.255.255.248
ip nat outside

!

interface Vlan10
description P2P_INSIDE_LAN
ip address 192.168.10.1 255.255.255.0
ip nat inside

!

interface Vlan1
description CONNECTION_TO_LAN
ip address 192.168.20.1 255.255.255.0
ip nbar protocol-discovery
ip nat inside

!

ip nat inside source static tcp 192.168.20.200 443 20.18.172.46 50006 route-map ISP1_P2P_NAT extendable
ip nat inside source static tcp 192.168.20.200 443 153.30.69.66 50006 route-map ISP1_LAYER2_NAT extendable

!

ip route 0.0.0.0 0.0.0.0 20.18.172.45 name P2P_RADIO track 3
ip route 0.0.0.0 0.0.0.0 153.30.69.65 name BROADBAND_LTE track 4

!

!
ip sla 3
icmp-echo 20.18.172.45
frequency 10
ip sla schedule 3 life forever start-time now
ip sla 4
icmp-echo 153.30.69.65
frequency 10
ip sla schedule 4 life forever start-time now

!
track 3 ip sla 3 reachability
delay down 1 up 1
!
track 4 ip sla 4 reachability
delay down 1 up 1

[Georg Pauwen]

Hello,

since you already have the IP SLAs configured, you could use them and add the EEM scripts below. Basically, only one static NAT entry would exist at any time, based on the availability of the ISPs:

event manager applet ISP_1_DOWN
event track 3 state down
action 1.0 cli command "enable"
action 2.0 cli command "conf t"
action 3.0 cli command "no ip nat inside source static tcp 192.168.20.200 443 20.18.172.46 50006 route-map ISP1_P2P_NAT extendable"
action 4.0 cli command "ip nat inside source static tcp 192.168.20.200 443 153.30.69.66 50006 route-map ISP1_LAYER2_NAT extendable
action 5.0 cli command "end"
action 6.0 cli command "clear ip nat translation *"
!
event manager applet ISP_1_UP
event track 3 state up
action 1.0 cli command "enable"
action 2.0 cli command "conf t"
action 3.0 cli command "ip nat inside source static tcp 192.168.20.200 443 20.18.172.46 50006 route-map ISP1_P2P_NAT extendable"
action 4.0 cli command "no ip nat inside source static tcp 192.168.20.200 443 153.30.69.66 50006 route-map ISP1_LAYER2_NAT extendable
action 5.0 cli command "end"
action 6.0 cli command "clear ip nat translation *"
!
event manager applet ISP_2_DOWN
event track 4 state down
action 1.0 cli command "enable"
action 2.0 cli command "conf t"
action 3.0 cli command "ip nat inside source static tcp 192.168.20.200 443 20.18.172.46 50006 route-map ISP1_P2P_NAT extendable"
action 4.0 cli command "no ip nat inside source static tcp 192.168.20.200 443 153.30.69.66 50006 route-map ISP1_LAYER2_NAT extendable
action 5.0 cli command "end"
action 6.0 cli command "clear ip nat translation *"
!
event manager applet ISP_2_UP
event track 4 state up
action 1.0 cli command "enable"
action 2.0 cli command "conf t"
action 3.0 cli command "no ip nat inside source static tcp 192.168.20.200 443 20.18.172.46 50006 route-map ISP1_P2P_NAT extendable"
action 4.0 cli command "ip nat inside source static tcp 192.168.20.200 443 153.30.69.66 50006 route-map ISP1_LAYER2_NAT extendable
action 5.0 cli command "end"
action 6.0 cli command "clear ip nat translation *"

[paul driver · Accepted solution]

Hello

---

@Georg Pauwen wrote:

Hello,

since you already have the IP SLAs configured, you could use them and add the EEM scripts below. Basically, only one static NAT entry would exist at any time, based on the availability of the ISPs:

---

As those are static nat entires wouldnt the nat table have static entries already installed for them?
If so there would be no requirement to clear the nat table, as such I would say no requiement for any EEM scirpting?

[jagannath.cmcltd]

Dear Sir,

             i have one cisco 4300 router. router interface details: GE 0/0/0 , GE 0/0/1 , GE 0/0/2.

SP1:117.197.102.219 255.255.255.248 172.24.159.241 

ISP2:202.142.74.74 255.255.255.248 202.142.74.73

My current configuration with one ISP only (i want STATIC NAT FAIL-OVER OVER TWO DIFFERENT ISP. )

I
Router#
Building configuration...

Current configuration : 1904 bytes
!
! Last configuration change at 10:38:59 UTC Wed Apr 27 2022
!
version 16.6
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
no service dhcp
platform qfp utilization monitor load 80
no platform punt-keepalive disable-kernel-core
!
hostname Router
!
boot-start-marker
boot-end-marker
!
!
vrf definition Mgmt-intf
!
address-family ipv4
exit-address-family
!
address-family ipv6
exit-address-family
!

!
no aaa new-model
!
!
!
!
!
!
!
!
!
!
!
subscriber templating
!
!
multilink bundle-name authenticated
!
!
!
!
!
!
license udi pid ISR4331/K9 sn FDO2444109U
diagnostic bootup level minimal
spanning-tree extend system-id
!
!
!
!
redundancy
mode none
!
!
!
!
!
!
!
!
interface Loopback0
ip address 117.197.102.219 255.255.255.248
ip nat inside
!
interface GigabitEthernet0/0/0
ip address 192.168.14.1 255.255.255.0
ip nat inside
negotiation auto
!
interface GigabitEthernet0/0/1
ip address 172.24.159.241 255.255.255.252
ip nat outside
negotiation auto
!
interface GigabitEthernet0/0/2
no ip address
shutdown
negotiation auto
!
interface GigabitEthernet0
vrf forwarding Mgmt-intf
no ip address
shutdown
negotiation auto
!
ip nat inside source list 99 interface Loopback0 overload
ip nat inside source list 102 interface Loopback0 overload
ip forward-protocol nd
no ip http server
ip http authentication local
no ip http secure-server
ip tftp source-interface GigabitEthernet0
ip route 0.0.0.0 0.0.0.0 172.24.159.242
ip route 192.168.14.0 255.255.255.0 172.24.159.242
!
!
access-list 99 permit 192.168.14.0 0.0.0.255
!
!
!
!
control-plane
!
!
line con 0
transport input none
stopbits 1
line aux 0
stopbits 1
line vty 0 4
login
transport input none
line vty 5 15
login
transport input none
!
wsma agent exec
!
wsma agent config
!
wsma agent filesys
!
wsma agent notify
!
!
end

Router#

please send the correct configurations

[paul driver]

Hello
Looks like you will only need to amend a couple of things as you nat config looks fine, Tracking on your isps next hop address is fine but if they have an issue further upstream then your existing track wouldn't the be aware of it, If you could track an ip that you know is reachable from that isp then its better to use that instead, in the example below i have just used a google dns ip but any ip more local to that ISP would be best.

You only require the one sla and you should be okay.

Example:

no ip sla 3
no ip sla 4
no ip route 0.0.0.0 0.0.0.0 153.30.69.65 name BROADBAND_LTE track 4

ip sla 3
icmp-echo 8.8.8.8
frequency 10

ip sla schedule 3 life forever start-time now

ip route 8.8.8.8 255.255.255.255 GigabitEthernet8 20.18.172.45
ip route 0.0.0.0 0.0.0.0 153.30.69.65 name BROADBAND_LTE 2
ip route 8.8.8.8 255.255.255.255 null0 2

[okoroji80]

Hi Paul.,

Please can you give more clarification on the suggested solution.

you opined that only one IP SLA is fine for the setup that's understood.

Are you also saying the solution requires just on default route even when i have two different ISPs ?

ip route 0.0.0.0 0.0.0.0 153.30.69.65 name BROADBAND_LTE track 3

ip sla 3
icmp-echo 8.8.8.8
frequency 10

ip sla schedule 3 life forever start-time now

====

In addition to the above can you also shade more light on the following:

What would be the function of these routes on the solution:

ip route 8.8.8.8 255.255.255.255 GigabitEthernet8 20.18.172.45

ip route 8.8.8.8 255.255.255.255 null0 2

Thanks.

[paul driver]

Hello @okoroji80

Yes you would only require just the one sla track as that would track your priamry isp link and if/when that fails the primary default route will be removed from the routing table and install the secondary default route which in the example provided has a routing adminstrative value of 2

ip route 0.0.0.0 0.0.0.0 20.18.172.45 name P2P_RADIO track 3 <default admin value of 1 also a track/ip sla of  3
ip route 0.0.0.0 0.0.0.0 153.30.69.65 name BROADBAND_LTE 2 <.admin value of 2

As for the specific routes they are for the ip sla monitoring of the primary ISP upstream ip.
ip route 8.8.8.8 255.255.255.255 GigabitEthernet8 20.18.172.45
ip route 8.8.8.8 255.255.255.255 null0 2

The router will install the above specific routes as/when the ip sla tracking fails and the primary default route is removed from the routing table, So then the router won’t try to reach the monitored ISP ip address via its now installed secondary default route, but it will now have a more specific route pointing towards the primary ISP so to continue polling that primary ISPs upstream IP.

As/when connectivity restored to the upstream ip then the secondary default route will be removed and the primary default route will again be restored in the routing table and these two specific routes will also be removed from it.

The result of this configuration would be that you have resiliency to your static nat translation via both ISPs

[okoroji80]

Thanks For the Support . I have one more issue to clarify.

Do we still need administrative distance for the static routes now that the solution demands that both ISPs  will be in ACTIVE-ACTIVE mode.

Thanks.

[okoroji80]

Hello George .,

Thanks for the input with respect to your suggested solution am thing aloud on the following:

route-map ISP1_P2P_NAT permit 10
match interface Vlan10

Without  a''  next-hop verify-availability ''  configured on the route-map how would the traffic know the ISP to use Per time ?

What if i have the route-map configured as follows:

       route-map ISP1_P2P_NAT permit 10
      match interface Vlan10

      set ip next-hop verify-availability 20.18.172.45 1 track 3
      set ip next-hop verify-availability 153.30.69.65 2 track 4

what would be the effect of the above  route-map config. on the solution ?

Thanks

[Georg Pauwen · Accepted solution]

Hello,

the next hop verify availability feature is certainly a good idea. The script I suggested is independent of how the tracking is configured, it just kicks in when the status is down or up.