cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Join Customer Connection to register!
8290
Views
40
Helpful
6
Replies
Boris Simunko
Beginner

PBR and verify-availability

Hello!

 

We are working on a new "feature" in our network, so I just wanted to ask if my concept and (future) implementation is correct.

 

The idea is to redirect the web traffic (HTTP/HTTPS) from our users to an inside firewall for filtering. The problem is that the FW is a single unit, and its failure could halt all web-surfing. Looking around a bit, I found the verify-availability command, but I am unsure about a few things...

 

route-map entry:

route-map REDIRECT permit 20
match ip address WEB
set ip next-hop verify-availability 192.168.30.10 20 track 1
set ip next-hop 10.8.12.20

 

The "WEB" ACL defines the traffic to be redirected, all is good.

SLA 1 is up and running, all is good.

There is a route-map REDIRECT permit 10 entry that is already in production (not related to this), all is good.

 

Firstly, I am not sure about the "20" in the "set ip next-hop verify-availability 192.168.30.10 20 track 1" statement, what does it really mean? 

 

sw-C3750st-r1-003(config-route-map)#set ip next-hop verify-availability 192.168.30.10 ?
<1-65535> Sequence to insert into next-hop list

 

Second, if the SLA fails, will the switch then use the IP from the "set ip next-hop 10.8.12.20" statement? BTW, the default route points to 10.8.12.20

 

sw-C3750st-r1-003#show ver
Cisco IOS Software, C3750E Software (C3750E-UNIVERSALK9NPE-M), Version 12.2(55)SE1, RELEASE SOFTWARE (fc1)

 

License Level                   : ipservices

 

 

Also, there is a secondary core switch with a different image that does not support the verify-availability feature, but the idea is the same, just a different config:

 

route-map REDIRECT permit 20
match ip address WEB
set ip next-hop 192.168.30.10
set ip next-hop recursive 10.8.12.20

 

sw-C3750-r5-016#show ver
Cisco IOS Software, C3750E Software (C3750E-UNIVERSALK9-M), Version 15.0(2)SE, RELEASE SOFTWARE (fc1)

License Level: ipservices

 

 

Will my configs work as intended?

 

Thanks in advance!

1 ACCEPTED SOLUTION

Accepted Solutions
Richard Burts
Hall of Fame Guru

Here is a link that has information about PBR and about verify-availability that I hope you will find useful

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_pi/command/iri-cr-book/iri-cr-s1.html#wp8093935770

 

There are several interesting parts to this question. Let me take the easy one first. The basic behavior of PBR with set ip next-hop is that as long as the router believes that the next hop is reachable (as long as there is an entry in the route table for a path to the next hop) then it will attempt to route the identified traffic to the specified next hop. Based on that we can answer the last part of the question. With this

route-map REDIRECT permit 20
match ip address WEB
set ip next-hop 192.168.30.10
set ip next-hop recursive 10.8.12.20

 

as long as there is a route to 192.168.30.10 then PBR will attempt to route traffic to that address. What if the router at 192.168.30.10 goes down? Would the route to it be removed from the routing table? Especially if the interface connecting to that next hop is Ethernet then probably that entry remains in the routing table and PBR will use the first entry and not use the second. So you have an issue trying to use PBR on that secondary core.

 

Cisco recognized that issue and the solution to it was the introduction of verify-availability. With this feature the router checks to be sure that the next hop address is reachable before setting the next hop. If PBR recognizes that the specified next hop is not available then it does not set the next hop to that value. If another next hop is specified then PBR will use that one. So your alternative here

set ip next-hop verify-availability 192.168.30.10 20 track 1
set ip next-hop 10.8.12.20

would pretty much work. It would be better if the last line also used a sequence number

set ip next-hop 10.8.12.20 30

and since the original poster tells us that 10.8.12.20 is the default route we can say that this line will work but is not needed. With verify-availability in the first line then if that address is not reachable then PBR will not use the specified next hop and normal routing would be used.

 

Indirectly we have answered the question about the sequence number. But let us be direct about it. The sequence number allows PBR to specify more than one next hop and to specify the order in which they will be used.

 

HTH

 

Rick 

HTH

Rick

View solution in original post

6 REPLIES 6
Richard Burts
Hall of Fame Guru

Here is a link that has information about PBR and about verify-availability that I hope you will find useful

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_pi/command/iri-cr-book/iri-cr-s1.html#wp8093935770

 

There are several interesting parts to this question. Let me take the easy one first. The basic behavior of PBR with set ip next-hop is that as long as the router believes that the next hop is reachable (as long as there is an entry in the route table for a path to the next hop) then it will attempt to route the identified traffic to the specified next hop. Based on that we can answer the last part of the question. With this

route-map REDIRECT permit 20
match ip address WEB
set ip next-hop 192.168.30.10
set ip next-hop recursive 10.8.12.20

 

as long as there is a route to 192.168.30.10 then PBR will attempt to route traffic to that address. What if the router at 192.168.30.10 goes down? Would the route to it be removed from the routing table? Especially if the interface connecting to that next hop is Ethernet then probably that entry remains in the routing table and PBR will use the first entry and not use the second. So you have an issue trying to use PBR on that secondary core.

 

Cisco recognized that issue and the solution to it was the introduction of verify-availability. With this feature the router checks to be sure that the next hop address is reachable before setting the next hop. If PBR recognizes that the specified next hop is not available then it does not set the next hop to that value. If another next hop is specified then PBR will use that one. So your alternative here

set ip next-hop verify-availability 192.168.30.10 20 track 1
set ip next-hop 10.8.12.20

would pretty much work. It would be better if the last line also used a sequence number

set ip next-hop 10.8.12.20 30

and since the original poster tells us that 10.8.12.20 is the default route we can say that this line will work but is not needed. With verify-availability in the first line then if that address is not reachable then PBR will not use the specified next hop and normal routing would be used.

 

Indirectly we have answered the question about the sequence number. But let us be direct about it. The sequence number allows PBR to specify more than one next hop and to specify the order in which they will be used.

 

HTH

 

Rick 

HTH

Rick

View solution in original post

Hello

Just like to add to ricks excellent post, That its my understanding that even though the recursive next hop address  is specified in the route-map, The rtr may not select to use it if there is a shorter route available in the rib for the destination route

 

res

Paul



kind regards
Paul

Please rate and mark posts accordingly if you have found any of the information provided useful.
It will hopefully assist others with similar issues in the future

wow that's an excellent reply! i have not had the time to test it, but i will try today and report back!

 

now, just one more thing i didn't mention in my original post: i did try a similar config, and at first everything was ok, the redirect worked fine, and when we killed the connection to 192.168.30.10, the SLAs and the route-map did their job and traffic started to flow the "normal" path. when 192.168.30.10 came back we realized that the policy was gone from the interfaces, and of course the permit 10 statement was also gone, which caused slight issues (testing on production network :) ). i am not sure at which moment the policy dissapeared - when 192.168.30.10 went down or came back up...

I am glad that you found our explanations helpful.

 

Am I correct in understanding that the ip policy was no longer on the interface and that the route map was no longer in the config? Was the IP SLA still in the config? Is it possible that the router reloaded and that your config changes had not been saved? It is hard for me to think of much other reason why those config changes would be removed. Certainly experiencing the failure and the recover should not have changed the config.

 

HTH

 

Rick

HTH

Rick

the switch did not reload, and all of the configs (route-map, SLA) were still there, only the policy disappeared from the interface. here are the logs

 

Jan 30 11:55:21: %TRACKING-5-STATE: 1 ip sla 1 reachability Up->Down
Jan 30 11:55:51: %PLATFORM_PBR-3-UNSUPPORTED_RMAP: Route-map REDIRECT not supported for Policy-Based Routing
Jan 30 11:55:51: %PLATFORM_PBR-3-UNSUPPORTED_RMAP: Route-map REDIRECT not supported for Policy-Based Routing
Jan 30 12:02:42: %TRACKING-5-STATE: 1 ip sla 1 reachability Down->Up
Jan 30 12:05:55: %PLATFORM_PBR-3-UNSUPPORTED_RMAP: Route-map REDIRECT not supported for Policy-Based Routing
Jan 30 12:06:09: %PLATFORM_PBR-3-UNSUPPORTED_RMAP: Route-map REDIRECT not supported for Policy-Based Routing

 

this is really weird because the route-map was there and working

Based on the further information you have posted I am puzzled about this statement

 of course the permit 10 statement was also gone

 

The log messages saying the route map was not supported for Policy Based Routing are very odd, if PBR was in fact happening. I do not know what to say about that. I hope you will not have that kind of issue this time.

 

HTH

 

Rick

HTH

Rick