10-30-2017 11:44 PM - edited 03-08-2019 12:34 PM
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
11-02-2017 04:45 AM
sorry, just noticed my IP SLA scripts have source-ip, use source interface instead.
11-02-2017 05:10 AM
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
06-15-2019 12:23 PM
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"
06-15-2019 04:33 PM
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.
06-15-2019 11:41 PM - edited 06-16-2019 12:12 AM
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
06-16-2019 06:59 PM
06-17-2019 06:48 AM
06-17-2019 05:47 PM
06-17-2019 10:09 PM
06-20-2019 01:47 PM
06-20-2019 11:02 PM
06-22-2019 09:26 PM
06-23-2019 12:05 AM
06-23-2019 09:03 PM
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