08-04-2015 09:55 PM - edited 03-05-2019 02:00 AM
Hi Friends,
I´m with the follow problem with NAT using IPSLA + PBR:
By default for all destiantion traffic goes to link 1( IP: 177.x.x.x) , only traffic to destination 200.200.200.200 have to go by link 2 (IP:189.x.x.x.x);
But when link 1 is down, all destination traffic have to go by link 2;
And when link 2 is down, the destination to traffic to 200.200.200.200 have to go by link 1.
The route table is ok, but the nat table always keep with link 1( IP: 177.x.x.x), so the traffic to destination 200.200.200.200 never work by Link2, even if set command "clear ip nat translation forced"
Could you help me??
Follow config:
interface GigabitEthernet0/0
ip address 1.1.1.1 255.255.255.0
ip nat inside
ip virtual-reassembly in
ip policy route-map PBR
duplex auto
speed auto
!
interface GigabitEthernet0/1
ip address 189.x.x.x 255.255.255.248
ip nat outside
ip virtual-reassembly in
duplex auto
speed auto
!
interface GigabitEthernet0/2
ip address 177.x.x.x 255.255.255.240
ip nat outside
ip virtual-reassembly in
duplex auto
speed auto
ip nat inside source route-map link1 interface GigabitEthernet0/2 overload
ip nat inside source route-map link2 interface GigabitEthernet0/1 overload
ip access-list extended link1
permit ip any any
ip access-list extended link2
permit ip any any
route-map link1 permit 10
match ip address link1
match interface GigabitEthernet0/2
!
route-map link2 permit 10
match ip address link2
match interface GigabitEthernet0/2
!
ip access-list extended pbr1
permit ip any any
ip sla 1
icmp-echo 8.8.8.8 source-interface GigabitEthernet0/2
frequency 30
timeout 30000
threshold 30000
ip sla schedule 1 life forever start-time now
route-map PBR permit 1
match ip address pbr1
set ip next-hop verify-availability 177.x.x.x 100 track 1
!
!
!
!
ip access-list extended pbr2
permit ip any any
ip sla 2
icmp-echo 8.8.4.4 source-interface GigabitEthernet0/1
frequency 20
timeout 20000
threshold 20000
ip sla schedule 2 life forever start-time now
route-map PBR permit 2
match ip address pbr2
set ip next-hop verify-availability 189.x.x.x 200 track 2
!
!
!
!
ip access-list extended pbr3
permit ip any host 200.200.200.200
ip sla 3
icmp-echo 8.8.8.8 source-interface GigabitEthernet0/2
frequency 30
timeout 30000
threshold 30000
ip sla schedule 3 life forever start-time now
route-map PBR permit 3
match ip address alogv-pbr3
set ip next-hop verify-availability 177.x.x.x 20 track 3
!
!
!
!
ip access-list extended pbr4
permit ip any host 200.200.200.200
ip sla 4
icmp-echo 8.8.4.4 source-interface GigabitEthernet0/1
frequency 20
timeout 20000
threshold 20000
ip sla schedule 4 life forever start-time now
route-map PBR permit 4
match ip address pbr4
set ip next-hop verify-availability 189.x.x.x 10 track 4
!
!
!
!
ip route 8.8.4.4 255.255.255.255 189.x.x.x
ip route 8.8.8.8 255.255.255.255 177.x.x.x
ip route 200.200.200.200 255.255.255.255 177.x.x.x 20 track 3
ip route 200.200.200.200 255.255.255.255 189.x.x.x 10 track 4
ip route 0.0.0.0 0.0.0.0 177.x.x.x 100 track 1
ip route 0.0.0.0 0.0.0.0 189.x.x.x 200 track 2
===================================================================================
Follow nat table:
Router#show ip nat translations | inc 200.200.200.200
icmp 177.x.x.x:1 192.168.1.86:1 200.200.200.200:1 200.200.200.200:1
tcp 177.x.x.x:49825 192.168.1.86:49825 200.200.200.200:80 200.200.200.200:80
tcp 177.x.x.x:49826 192.168.1.86:49826 200.200.200.200:80 200.200.200.200:80
tcp 177.x.x.x:49827 192.168.1.86:49827 200.200.200.200:80 200.200.200.200:80
Follow route table :
Gateway of last resort is 177.154.150.225 to network 0.0.0.0
S* 0.0.0.0/0 [100/0] via 177.x.x.x
S 8.8.4.4 [1/0] via 189.x.x.x
S 8.8.8.8 [1/0] via 177.x.x.x
S 200.200.200.200 [10/0] via 189.x.x.x
Solved! Go to Solution.
08-06-2015 12:59 AM
Hello,
I think the problem is in your PBR setup. Your first two rules match all traffic, so it seems that your traffic destined for 200.200.200.200 never gets match in rules 3 and 4. I suspect if you re-order your PBR route-map to the following it might work:
ip access-list extended pbr4
permit ip any host 200.200.200.200
!
route-map PBR permit 1
match ip address pbr4
set ip next-hop verify-availability 189.x.x.x 10 track 4
!
ip access-list extended pbr3
permit ip any host 200.200.200.200
!
route-map PBR permit 2
match ip address alogv-pbr3
set ip next-hop verify-availability 177.x.x.x 20 track 3
!
!
ip access-list extended pbr2
permit ip any any
!
route-map PBR permit 3
match ip address pbr2
set ip next-hop verify-availability 189.x.x.x 200 track 2
!
ip access-list extended pbr1
permit ip any any
!
route-map PBR permit 4
match ip address pbr1
set ip next-hop verify-availability 177.x.x.x 100 track 1
I don't think the routing tables matters that much beyond the routes for 8.8.8.8 and 8.8.4.4 since PBR is in play.
HTH,
tim
08-04-2015 10:39 PM
Hello,
It seems that you have a typo in your route-map link2: It says match interface GigabitEthernet0/2 but because it is used to control the NAT/PAT to the address of Gi0/1, it should say match interface GigabitEthernet0/1 instead.
In addition, route-maps link1 and link2 refer to identically named ACLs link1 and link2 which are simply permit any. Cisco officially does not support the use of permit any ACLs in a NAT. I strongly suggest you rewrite both ACLs to specifically match the internal network you are NATting (probably 192.168.1.0/24 according to the output from the NAT table). You do not actually need two separate ACLs if they are both identical. This is a suggestion how your configuration could be optimized in this sense:
ip access-list standard InternalNet permit 192.168.1.0 0.0.0.255 ! route-map link1 permit 10 match ip address InternalNet match interface GigabitEthernet0/2 ! route-map link2 permit 10 match ip address InternalNet match interface GigabitEthernet0/1
Best regards,
Peter
08-05-2015 05:08 PM
Hi Peter,
Unfortunately did not work.
The route table and NAT still the same.
08-05-2015 05:15 PM
Hi,
The routing table should not change - I have not suggested any configuration change so far that would affect the routing table contents.
Let's focus at one issue at time, and because the routing table is more important than NAT as it influences the egress interface selection, let's try to deal with that first. Are you saying that the routing table contents are not entirely right? How do you expect them to behave, and what is there now? Please try to be as detailed as possible.
Best regards,
Peter
08-05-2015 06:15 PM
Hi,
I suspect the problem is the NAT table, because from my understood, the route table is OK, if we look to route table , any soruce address from Local Lan , can access the destination 200.200.200.200 by Link 2 (189.x.x.x) , for any another destination the Local Lan can access by Link 1 (177.x.x.x).
See:
Gateway of last resort is 177.154.150.225 to network 0.0.0.0
S* 0.0.0.0/0 [100/0] via 177.x.x.x
S 8.8.4.4 [1/0] via 189.x.x.x
S 8.8.8.8 [1/0] via 177.x.x.x
S 200.200.200.200 [10/0] via 189.x.x.x
But the NAT table show the follow :
Router#show ip nat translations | inc 200.200.200.200
Pro Inside global Inside local Outside local Outside global
icmp 177.x.x.x:1 192.168.1.86:1 200.200.200.200:1 200.200.200.200:1
tcp 177.x.x.x:49825 192.168.1.86:49825 200.200.200.200:80 200.200.200.200:80
tcp 177.x.x.x:49826 192.168.1.86:49826 200.200.200.200:80 200.200.200.200:80
tcp 177.x.x.x:49827 192.168.1.86:49827 200.200.200.200:80 200.200.200.200:80
I think the correct NAT table would be appers this way:
Pro Inside global Inside local Outside local Outside global
icmp 189.x.x.x:1 192.168.1.86:1 200.200.200.200:1 200.200.200.200:1
tcp 189.x.x.x:49825 192.168.1.86:49825 200.200.200.200:80 200.200.200.200:80
tcp 189.x.x.x:49826 192.168.1.86:49826 200.200.200.200:80 200.200.200.200:80
tcp 189.x.x.x:49827 192.168.1.86:49827 200.200.200.200:80 200.200.200.200:80
If i didnt clear, sorry for my english.
08-06-2015 12:59 AM
Hello,
I think the problem is in your PBR setup. Your first two rules match all traffic, so it seems that your traffic destined for 200.200.200.200 never gets match in rules 3 and 4. I suspect if you re-order your PBR route-map to the following it might work:
ip access-list extended pbr4
permit ip any host 200.200.200.200
!
route-map PBR permit 1
match ip address pbr4
set ip next-hop verify-availability 189.x.x.x 10 track 4
!
ip access-list extended pbr3
permit ip any host 200.200.200.200
!
route-map PBR permit 2
match ip address alogv-pbr3
set ip next-hop verify-availability 177.x.x.x 20 track 3
!
!
ip access-list extended pbr2
permit ip any any
!
route-map PBR permit 3
match ip address pbr2
set ip next-hop verify-availability 189.x.x.x 200 track 2
!
ip access-list extended pbr1
permit ip any any
!
route-map PBR permit 4
match ip address pbr1
set ip next-hop verify-availability 177.x.x.x 100 track 1
I don't think the routing tables matters that much beyond the routes for 8.8.8.8 and 8.8.4.4 since PBR is in play.
HTH,
tim
08-06-2015 04:23 PM
Hi trfinkenstadt ,
you are right, when I did the re-order of polic-maps worked perfectly! Tks!
Tks Peter Paluch for your attention.
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