PBR and verify-availability

[Boris Simunko]

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!

[Richard Burts · Accepted solution]

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 

[paul driver]

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

[Boris Simunko]

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...

[Richard Burts]

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

[Boris Simunko]

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

[Richard Burts]

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