Load balancing and automatic fail over of traffic

[collinks2]

Hello Guys, We want to accomplish this using Cisco 2911 router. We have the following networks: 172.16.2.0,172.16.3.0 - 172.16.7.0.

Our goal is to allow all these network to use the two isp links. If one isp link goes down, those network will be redirected to another isp link. All the lan networks must make use of the two links.

Access list is nat-add

Isp1 pool is mtn and isp2 pool is airtel

Route map for  isp1is route-mtn

The route map statement matches the access-list nat-add with the next valid hop set to the gateway pointing to isp1

route-map for isp2 is route-airtel.

What access - list statement do we use for the isp2 since the route-map for isp1 is matching all the networks in the access-list, nat-add?

How do we define the ip sla monitor using track command in the default router? I know we will have two default routes, one pointing to isp1 and the other pointing to isp2?which default route will use the track command?

Any suggestions will be appreciated

[casanavep]

sorry, just noticed my IP SLA scripts have source-ip, use source interface instead. 

[collinks2]

Hello Casa,

Thanks for the quick response. However ,i really want to understand this

icmp-echo 8.8.8.8

in the scripts,i made use of the isp ip address which is my gateway to reach the internet. y 8.8.8.8 ? I asked Paul driver who hinted me that he used it as an example. Please make me understand the significance of using 8.8.8.8 instead of the isp address.

Are the access-list ,route-map and nat statements correct ? Also,I didnt enable policy based routing on the interface since i have two different route-map :PBR1 and PBRR2

hope to read from you soon

[collinks2]

Hello Guys,

I trust all are doing great. I modified the scripts which you guys helped with to suite my new objective.Now, i wan to allow only the http and https traffic to go through the slower link while other traffic should go through the faster link,

The slower link is ISP2 (USPF_isp)

The faster link is ISP1 (MTN_ISP)

In the event, either of the isp goes down, all traffic should go through the Active link. Here is my script.

track 1 ip sla 1 reachability
delay down 15 up 60
!
track 2 ip sla 2 reachability
delay down 15 up 60

track 3 list boolean or
object 1
object 2

!

ip sla 1
icmp-echo 8.8.8.8 source-ip 197.210.105.x
threshold 1000
timeout 1000
frequency 5
ip sla schedule 1 life forever start-time now
ip sla 2
icmp-echo 4.2.2.2 source-ip 169.101.69.x
threshold 1000
timeout 1000
frequency 5
ip sla schedule 2 life forever start-time now

track 5 ip sla 5 reachability
delay down 15 up 60
!
track 6 ip sla 6 reachability
delay down 15 up 60

track 7 list boolean or
object 5
object 6

!

ip sla 5
icmp-echo 8.8.8.8 source-ip 197.210.105.230
threshold 1000
timeout 1000
frequency 5
ip sla schedule 5 life forever start-time now
ip sla 6
icmp-echo 4.2.2.2 source-ip 169.101.69.83
threshold 1000
timeout 1000
frequency 5
ip sla schedule 6 life forever start-time now

!

!

ip route 0.0.0.0 0.0.0.0 197.210.105.x 100 track 3

ip route 0.0.0.0 0.0.0.0 169.101.69.x 100 track 7

!

failover route, just in case you IP SLA fails to function as desired and you need a back door

ip route 0.0.0.0 0.0.0.0 197.210.105.x 200

!
interface GigabitEthernet0/1.137
description CONNECTION_TO_MTN_ISP
encapsulation dot1Q 137
ip address 197.210.105.230 255.255.255.252
ip nat outside
ip virtual-reassembly in
!
interface GigabitEthernet0/1.136
description CONNECTION_TO_ISP2
encapsulation dot1Q 136
ip address 169.101.69.83 255.255.255.248
ip nat outside

interface GigabitEthernet0/2.14
encapsulation dot1Q 136
ip address 192.168.x.x 255.255.255.0
ip nat inside * won't PBR be enabled on this internal interface ?*

ip nat inside source route-map NAT_MTNISP2 interface GigabitEthernet0/1.137 overload
ip nat inside source route-map NAT_USPFISP interface GigabitEthernet0/1.136 overload

ip access-list ext extended web_traffic
permit tcp 172.16.0.0 0.0.255.255 any eq 80
permit tcp 10.108.0.0 0.0.255.255 any eq 80
permit tcp 192.168.0.0 0.0.255.255 any eq 80
permit tcp 172.17.0.0 0.0.255.255 any eq 80
permit tcp 172.16.0.0 0.0.255.255 any eq 443
permit tcp 10.108.0.0 0.0.255.255 any eq 443
permit tcp 192.168.0.0 0.0.255.255 any eq 443
permit tcp 172.17.0.0 0.0.255.255 any eq 443

ip access-list ext other_traffic
permit ip 172.16.0.0 0.0.255.255 any any
permit ip 10.108.0.0 0.0.255.255 any any
permit ip 192.168.0.0 0.0.255.255 any any
permit ip 172.17.0.0 0.0.255.255 any any

ip sla auto discovery

!
route-map NAT_USPFISP permit 10
match ip address web_traffic
set ip next-hop 169.101.69.x 197.210.105.x
set ip next-hop verify-availability 169.101.69.x 1 track 3
set ip next-hop verify-availability 197.210.105.x 2 track 7

route-map NAT_MTNISP2 permit 10
match ip address other_traffic
set ip next-hop 197.210.105.x 169.101.69.x
set ip next-hop verify-availability 197.210.105.x 1 track 7
set ip next-hop verify-availability 169.101.69.x 2 track 3

!
event manager applet ISP1_DOWN
event track 1 state down
action 1.0 cli command "enable"
action 2.0 cli command "clear ip nat translation forced"
!
event manager applet ISP2_DOWN
event track 2 state down
action 1.0 cli command "enable"
action 2.0 cli command "clear ip nat translation forced"

[Francesco Molino]

I don't understand your tracking.

On track 3 associated with your ISP1, your validating ip sla 1 and 2 which are sourced by different source interfaces (ISP 1 and ISP 2). Same for track 7.

I believe you wanted to do 2 pings from ISP1 and 2 from ISP2 and then associate these IP SLAs to a group track that'll be associated to default route of ISP 1 and 2. Am I right?

Maybe you have another explanation but reading it doesn't make sense for me right now.

On your route-maps, you have a set ip next-hop to 2 IPs and right below a set next-hop verify availability to same next hops.

route-map NAT_USPFISP permit 10
match ip address web_traffic
set ip next-hop 169.101.69.x 197.210.105.x
set ip next-hop verify-availability 169.101.69.x 1 track 3
set ip next-hop verify-availability 197.210.105.x 2 track 7

route-map NAT_MTNISP2 permit 10
match ip address other_traffic
set ip next-hop 197.210.105.x 169.101.69.x
set ip next-hop verify-availability 197.210.105.x 1 track 7
set ip next-hop verify-availability 169.101.69.x 2 track 3

You want to use only verify-availability with your tracking.

You need to have a route-map for PBR with the same name but 2 sequences at least (1 to route to ISP1 and the other to ISP2) and a you can have 2 route-maps or re-use the 2 ACL for nat.

But don't forget to have a workaround when ISP2 goes down because right now you're matching only http/https to be natted on ISP1 (which means if ISP2 goes down no nat will occur for other traffic).

You will need to apply the PBR to the inside interface or globally to route the traffic to ISP1 and/or ISP2. Without this, PBR won't work.

Here a link that explains everything and matching your use-case: https://community.cisco.com/t5/networking-documents/dual-internet-links-nating-with-pbr-and-ip-sla/ta-p/3126275

Have a look on it, and if you have any issues or questions, feel free to reach out to us.

[collinks2]

Hello Francesco,

"I believe you wanted to do 2 pings from ISP1 and 2 from ISP2 and then associate these IP SLAs to a group track that'll be associated to default route of ISP 1 and 2. Am I right?" You are right.

"

route-map NAT_USPFISP permit 10
match ip address web_traffic
set ip next-hop 169.101.69.x 197.210.105.x
set ip next-hop verify-availability 169.101.69.x 1 track 3
set ip next-hop verify-availability 197.210.105.x 2 track 7

route-map NAT_MTNISP2 permit 10
match ip address other_traffic
set ip next-hop 197.210.105.x 169.101.69.x
set ip next-hop verify-availability 197.210.105.x 1 track 7
set ip next-hop verify-availability 169.101.69.x 2 track 3

You want to use only verify-availability with your tracking."

No i want to combine with the IP sla monitor. The idea is to eliminate that workaround if the ISP2 goes down since only the web traffic will be natted to ISP1, In the route-map statement of isp2, two next hops are specified. So if the next hop verifies that isp2 (197.210.105.x) is down,it should be able to forward it to the next  hop 169.101.69.x (ISP1)

I will look at the link and get back to you. I appreciate your swift  response

Addendum

I have read the article. I am kind of confused on the route statements that match the ACL 10. (permit 10.1.1.0 0.0.255 ) Could you explain further while that command is necessary? In the event where isp 1 goes down , what is the fate of other traffic as ACL 100 matches only the telnet traffic and web traffic to isp2? Is this why the ACL 10 comes in

[Francesco Molino]

The goal of acl 10 is to be able to nat all traffic no matter which isp links it goes through.
The pbr will force the traffic to take one party or another depending on their availabilities but at the end the nat will allow any traffic from inside to go outside. That's why it's important to separate acls for pbr vs nat if you want to manage the redundancy in case 1 link goes down.

[collinks2]

Ok. But in case the two isp links are active. Will all the http/https
traffic go through isp1 (the slower link) leaving all other traffic to go
through isp2?

[Francesco Molino]

If both ISPs are active then your PBR will forward the traffic http/https right to the correct link based on your route-map if you based the config on the link I gave. You can post back the updated config if you want me to validate just in case.

[collinks2]

Ok. I would love you to validate my config. I was not able to enter this
command "track 10 rtr 1 reachability ".I was able to enter this : track 1
ip sla 1 ...'
I can't find "rtr" .

[Francesco Molino]

Which router and which ios version?

It's the same.

[collinks2]

Router is 2911, ios version is 15.6

[Francesco Molino]

Don't remember the command exact on your router and can't test because i don't have any of them.
If you replace rtr by ip sla, does it work? Have you tried it?. Normally it should work the same way

[collinks2]

The command ip sla is working. I searched via google but it seems the rtr
command is no longer supported. I post my commands so that you can validate
them for me

[Francesco Molino]

Yes sure it's working this is the same as rtr as said previously. It's just a matter of which ios version and which platform.