03-12-2018 05:00 AM - edited 03-05-2019 10:05 AM
Hi,
I have the following route-map setup for two internet curcuits:
Extended IP access list LAN
5 deny ip 10.10.50.0 0.0.0.255 10.0.0.0 0.255.255.255
10 permit ip 10.10.50.0 0.0.0.255 any
route-map INTERNET_FAILOVER permit 10
match ip address LAN
set ip next-hop verify-availability 192.168.10.1 1 track 1
set ip next-hop verify-availability 192.168.20.1 2 track 2
and the following static routes:
ip route 1.1.1.1 255.255.255.255 192.168.20.1
ip route 2.2.2.2 255.255.255.255 192.168.20.1
The problem is when is when i implement 'ip policy route-map INTERNET_FAILOVER' on my Lan interface i cannot ping 1.1.1.1 or 2.2.2.2
Can anyone help as to why i cannt ping these addresses (Everything works if i remove the policy from the interface)?
03-12-2018 05:52 AM
Is the route map configured inbound on the 10.10.50.x interface (just checking)?
The static routes should have no bearing as the first instance of the route map would take over and all packets would be forwarded to the 192.168.10.1 next hop.
Do you have tracking configured?
Can you provide the configs of the three interfaces and the policy map and tracking? It may prove helpful.
Thanks
03-12-2018 06:14 AM
03-12-2018 06:31 AM
I agree with your configuration, but just a thought, could you try to add another instance to your route-map:
!
route-map INTERNET_FAILOVER permit 10
match ip address LAN
set ip next-hop verify-availability 192.168.10.1 1 track 1
set ip next-hop verify-availability 192.168.20.1 2 track 2
!
route-map INTERNET_FAILOVER permit 20
!
Although the access to the 10.x.x.x network is excluded in the first instance, the additional instance may allow for traffic that is not policy routed to be forwarded.
03-12-2018 06:34 AM
Hi,
did you try to add a new route map as:
route-map INTERNET_FAILOVER permit 20
Any of traffic which is denied in the first statement must route through the 2nd route map.
Regards,
Deepak Kumar
03-12-2018 11:54 AM
The suggestion by Chris to configure another instance in the route map with no match and no set is an approach that frequently is needed when the route map is being used to control what is advertised in a routing protocol. But in PBR there is no need for this kind of null instance. Whatever was denied in the first instance will not be policy routed and will be routing using normal routing logic. No need for the null instance.
HTH
Rick
03-12-2018 12:08 PM
If I am understanding correctly the ability to ping 1.1.1.1 and 2.2..2 is impacted depending on whether the ACL includes this line
5 deny ip 10.10.50.0 0.0.0.255 10.0.0.0 0.255.255.255
ping to those addresses is broken when the line is in the ACL and ping to those addresses works when the line is removed.
I am quite puzzled about how denying traffic with destination of 10.0.0.0 has any impact on ping to 1.1.1.1 or 2.2.2.2.
I could understand PBR having an impact on reachability of 1.1.1.1 and 2.2.2.2 if the next hop used in PBR was a device with no reachability to those addresses. But that ought to be a problem whether or not you did PBR if the destination was 10.0.0.0
Perhaps if we saw a more complete configuration we might see what is causing this.
HTH
Rick
08-20-2018 06:53 AM
Hi
Apologies but just cutting in the discussion.
I am unable to apply route-map policy in CLI(packet Tracer). Basically i am trying to configure a NAT failover using dual ISPs.
Can you help me on this?
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