Defining second hop in route map

[sridhar ch]

Hi,

For some reason the below conf is not working. As you can see from the conf below, i have defined the backup GW (second hop) in case the primary fails. is the below conf correct? if not what should be done to make it work? FYI, i am not using any tracking.

R1 Configuration:

route-map abc permit 10
 match ip address 100
 set ip next-hop 192.168.12.2 172.16.12.2 
 set ip next-hop verify-availability
!
route-map abc permit 20
 match ip address 200
 set ip next-hop 172.16.12.2 192.168.12.2
 set ip next-hop verify-availability

access-list 100 permit ip host 1.1.1.10 host 2.2.2.10
access-list 100 permit ip host 1.1.1.20 host 2.2.2.20

access-list 200 permit ip 1.1.1.0  0.0.0.255 2.2.2.0 0.0.0.255

R2 Configuration:

route-map abc permit 10

 match ip address 100
 set ip next-hop 192.168.12.1 172.16.12.1
 set ip next-hop verify-availability
!
route-map abc permit 20
 match ip address 200
 set ip next-hop 172.16.12.1 192.168.12.1
 set ip next-hop verify-availability

access-list 100 permit ip host 2.2.2.10 host 1.1.1.10
access-list 100 permit ip host 2.2.2.20 host 1.1.1.20

access-list 200 permit ip  2.2.2.0 0.0.0.255 1.1.1.0  0.0.0.255

1.1.1.10/20 & 2.2.2.10/20 are SAN IP's - so we are using one of the two links and the other link for the rest of the traffic.

we want both the links to be fail over to each other.

Thanks,

Sridhar

[mfurnival]

In what way does it not work? Does all traffic use one link? I assume that you have applied the route-map to the LAN facing interfaces of each router?

[sridhar ch]

yes, i applied the route map to the LAN interface on both the routers for the incoming packets.

when 192.168.12.2 or  172.16.12.2 (from R1 prespective) is not available i.e when circuit is down, traffic is not falling over the other circuit.

[paul driver]

Hello

The acl 200 seems incorrect ( 100-199 is extended acl range not 200)

also you need to track your first next hop to when verifying.- something like below:

access-list 100 permit ip host 1.1.1.10 host 2.2.2.10
access-list 100 permit ip host 1.1.1.20 host 2.2.2.20
access-list 199 permit ip 1.1.1.0  0.0.0.255 2.2.2.0 0.0.0.255
 

track 3 list boolean and
 object 1
 object 2

ip sla 1
icmp-echo (primary wan ip source-ip (Primary wan interface of router)
frequency 5

ip sla 2
icmp-echo (seconday wan ip source-ip (secondary primary wan interface of router)
frequency 5

ip sla schedule 1 start-time now  life forever
ip sla schedule 2 start-time now  life forever
 

track 1 ip sla 1 reach
track 2 ip sla 2 reach

route-map PBR permit 10
match ip address 100
set ip next-hop 192.168.12.1 172.16.12.1
set ip next-hop verify-availability 192.168.12.1)1 track 1
set ip next-hop verify-availability 172.16.12.1 2 track 2

route-map PBR permit 20
match ip address 199
set ip next-hop 172.16.12.1 192.168.12.1
set ip next-hop verify-availability 172.16.12.1 1 track 2
set ip next-hop verify-availability 192.168.12.1 2 track 1

ip route 0.0.0.0 0.0.0.0  192.168.12.1  200 track 3
ip route 0.0.0.0 0.0.0.0  172.16.12.1 250

int xx ( lan interace)
ip policy route-map PBR

res

Paul

[Richard Burts]

Paul picks up on the detail that I missed that access list 200 would not be an IP extended access list. Other than that he is going down the thought process where I started in assuming that using the track option might work more quickly or more reliably than using the CDP checking in the command as you have configured it. I believe that the command as you configured it should work and hope that we can resolve whether the issue is just timing of how long it takes to be effective or whether there is something that prevents it from working as expected.

HTH

Rick

[Richard Burts]

I agree that a better description of what is not working would be helpful.

I am also puzzled about a couple of things. Sridhar tells us that he is not doing any tracking. But he is using the verify availability parameter in the route map. How does he expect verify availability to work if he is not doing any tracking. Also I believe that the application of verify availability is flawed. He is applying it on a seperate command line from the line where he is setting the next hop. I believe that it only works when it is applied on the command line that is setting the next hop.

HTH

Rick

[sridhar ch]

hi Richard,

set ip next-hop verify-availability will do a CDP to check the availability of next hop before routing the next hop. yes, the same command can be used in conjuction with object tracking also.

is it recommended to define 2 IP's in the set next hop command? the above is not working, when the 192.168.12.2 is down, the traffic is not taking the next available hop i.e 172.168.12.2. so what should be done to make it work? should i configure one more instance with a higher sequence number and use the same ACL but with a differnet next hop?

something like this (from R1 prespective):

route-map abc permit 10
 match ip address 100
 set ip next-hop 192.168.12.2 
 set ip next-hop verify-availability

route-map abc permit 11
 match ip address 100
 set ip next-hop 172.16.12.2 
 set ip next-hop verify-availability

route-map abc permit 20
 match ip address 200
 set ip next-hop 172.16.12.2 
 set ip next-hop verify-availability

route-map abc permit 21
 match ip address 200
 set ip next-hop 192.168.12.2
 set ip next-hop verify-availability

else please advise how to over come the issue.

[Richard Burts]

In my experience I have not used the form of the command on a line by itself. But having checked the command reference I find that  set ip next-hop verify-availability on a line by itself is valid. I wonder if the issue you are experiencing has to do with the amount of time that an entry remains in the CDP neighbor table after the neighbor stops being reachable. When you have encountered this issue have you issued the show cdp neighbor command and looked to see if the entry for that neighbor is still in the neighbor table? If you wait until the neighbor entry is removed from the CDP neighbor table, does the second next hop take effect?

It is a tempting thought to create a second instance within the route map and specify the second  next hop in the second instance of the route map. But it will not work as you want it to. The main issue is that if you use access-list 100 in both instances then the traffic will always match the first instance and will never get to the second instance.

I suggest that you do some more testing to determine if the issue might be timing of when the CDP neighbor entry is removed from the table. If that is the case then perhaps you can tune the CDP timers to improve the operation of your PBR. If that is not the issue then I suggest that you look into using the tracking option. I have implemented this several times and it has worked well for me.

HTH

Rick