Route-map <name> has unsupported options for Policy-Based Routing

[thanhdinh0109@gmail.com]

Hi everyone,

I recently encountered this log statement while trying to apply a route-map to an interface:

%FMANRP_PBR-3-UNSUPPORTED_RMAP: Route-map <name> has unsupported options for Policy-Based Routing. It has been removed from the interface, if applied.

Here the configuration I use in the switch:

#Object tracking configuration:

IP sla 17
  icmp-echo 10.200.0.10

ip sla schedule 17 life forever start-time now

track 17 ip sla 17 reachability

#Route-map configuration:

config ter
route-map PBR_Servers_to_Branches permit 17
match ip address PRB_Servers_to_Branch_TranKhatChan_10.32.67.0/24
set ip next-hop verify-availability 10.32.3.114 17 track 17
end

#Applying to interface

config ter
interface TwentyFiveGigE1/2/0/40
ip policy route-map PBR_Servers_to_Branches
end

OS version:

Cisco IOS XE Software, Version 17.03.02a
Cisco IOS Software [Amsterdam], Catalyst L3 Switch Software (CAT9K_IOSXE), Version 17.3.2a, RELEASE SOFTWARE (fc5)

Product:

cisco C9606R (X86) processor (revision V01)

I have tried with version 16.12.4 but still facing the same problem.

Did anyone have the same issue and have a solution?

[thanhdinh0109@gmail.com]

this bug I have found relating to the log statement: CSCvr79637

Link:

Bug Search (cisco.com)

[Georg Pauwen]

Hello,

the bug you found is probably spot on. There is no known fixed release, so in all likelihood, the bug still exists in the Amsterdam release...

[balaji.bandi]

also what kind of License you have on this device ?

[thanhdinh0109@gmail.com]

Hi Balaji bandi,

I have the DNA Advantage license for the switch

License Usage:
License Entitlement Tag Count Status
-----------------------------------------------------------------------------
network-advantage (C9600-NW-A) 4 IN USE
dna-advantage (C9600-DNA-A) 2 IN USE

[paul driver]

Hello
As a workaround you could specify mutiple next-hops in the PBR route-map, It acts just like the verify-availability however only if the first next-hop becomes unavailble through a physcal interface failure as such the second next hop will then be used

route-map PBR_Servers_to_Branches permit 17
no set ip next-hop verify-availability 10.32.3.114 17 track 17
set ip next-hop 10.32.3.114 10.x.x.x.

[thanhdinh0109@gmail.com]

Hi,

Thank you for replying. I appreciate that but it will not help me as much.

I use PBR route-map to redirect several traffics to reliable WAN connectivity, while the other traffics go to the other wan connectivity.

Please refer attachments below as a simplified diagram to understand the reason I need Object tracking.

[paul driver]

Hello

The suggestion to use multiple next- hops was a interim solution as it seems the current software has a bug that is negating you to use the pbr with verification so as we now understand you require object tracking you could also make this happen as an interim solution using eem scripting with ipsla object tracking so if/when failure of a tracked next-hop fails the eem script will initiate and remove or amend the route map so you have resilience.

Would that be applicable?

[thanhdinh0109@gmail.com]

Thank you for the idea!

I think it would be a temporary solution alternative for object tracking (IP SLA) in route-map if you don't have many objects for tracking.

In my case, the EEM script will probably be so massive because I have more than 200 tracks for 200 route-map sequences.

One more thing, go with this solution, I still have to use object tracking and EEM script simultaneously. That would double, maybe triple my works.

It's a nightmare for me. I'm sure it's hard to be applicable.

[paul driver]

Hello

Unless i have mis-understood even if next-hop verification was available you was going track so the only added difference here would be the eem script?