CSCve66879 - FMC 6.2 - Unassigning flexconfig that uses a route-map submits a change to remove the route-map

[dcpolgar1]

I have been dealing with this error for the last 2 weeks. The policy will update just fine  with the PBR flexconfig and then the next time a deployment takes place I get this error even if I didn't touch the flexconfig option. I have spent close to 20 hours with TAC regarding this and I hope they get this issue resolved soon. Very frustrating !

[longlong_liu]

In view of this problem, I would like to ask how you finally solved it. Could you please tell me the details? Upgrade (which version will fix the bug) or something else? Thank you very much.

I also currently add 'policy-based-routing-clear' . but I also need deploy2 times to use it properly.

[n-kirillov]

Hi guys!

Thats problems is stayed in version 6.6.1 (bug the same https://quickview.cloudapps.cisco.com/quickview/bug/CSCve66879)

In session FTD transcript 

"FTD_DEVICE >> [error] : ERROR: route-map PBR_Route_MAP_TO_Old_GW is attached to routing protocols (EIGRP/RIP/OSPF/BGP/ISIS) or used in policy based routing. Please remove the relevant configuration before removing the route_map Config Error -- no route-map PBR_Route_MAP_TO_Old_GW permit 10 "

Spent 5 hours, god!

Manually writting no route-map under interface config, there is no results.

Just solved the problem adding "Policy_Base_Routing_Clear" in prepend

[n-kirillov]

I've got it - in Flex Config (in Objects menu), I must use prepend, not append, for manually unconfigure route-map usage in interface config.

Good luck

Sincerely from Nik

CCIE, Irkutsk, Russia

[gmccollu]

Hello Everyone,

One reason we may be seeing this issue is because we have our FlexConfig object improperly configured.  Prior to 6.2 there was no option to "set ip next-hop x.x.x.x" under the route-map and needed to be manually configured under the route-map in the FlexConfig policy.  However, if running 6.2+ the "set clause" option was introduced under the route-map object from which is where we would want to configure the "set ip next-hop" variable.  If we still have the "set ip next-hop x.x.x.x" configured under the route-map inside of the FlexConfig object, then FMC detects this as unsupported configuration and removes.  Please follow the below doc regarding the configuration of PBR on 6.2+:

https://www.cisco.com/c/en/us/td/docs/security/firepower/670/configuration/guide/fpmc-config-guide-v67/flexconfig_policies.html#Cisco_Task_in_List_GUI.dita_bc40fbd4-5a79-48ae-bf3e-34b7f8a1ec9f

Another reason we may be seeing this issue is whenever FMC leverages natively supported configuration (route-map in this case) in the FlexConfig and the FlexConfig object is removed from the FlexConfig Policy, FMC in turn will remove the native supported configuration from FTD (which is what we see when we remove the PBR FlexConfig Object from the FlexConfig policy).  

In a nutshell, once the FlexConfig object is attached to the policy, do not remove if operating properly.  If we need to make a change, remove the PBR FlexConfig object from the FlexConfig policy while prepending the"Policy_Base_Routing_Clear".  This will remove all PBR configuration (including route-map).

[ASUHIT3834770]

i have found a solution which worked  with me and saved my life

you should first see the active PBR on your ftd in cli using command : " show policy-route "

then go to that flex config and edit it , then add " no " before command " route-map *** permit ** " and add " no " before " policy-route route-map ***** " which is in the interface 

and assign that flex config to the device and deploy 

see the flexconfig edit required in the attached image

eng. mohamed osama

ain shams university hospitals

moh_usama50@yahoo.com

[grinchcostumes]

Gratitude for the data. In the wake of working with TAC on this we truly do have a current workaround until this issue sorts out. I simply need to go into the Flexconfig choice and erase the PBR out of the chose annex Flexconfig and save it. I then re-add it and save it and afterward select view to ensure the order will be re-added and convey it. This has worked up to this point. I simply need to ensure I do this whenever there is a sending. It is an aggravation yet essentially we can work with it until this issue sorts out. I surmise the issue should be settled in the 6.3.0 delivery at whatever point that emerges. Cisco had no estimated time of arrival last time I conversed with them.archie the axolotl squishmallow

[ASUHIT3834770]

try the solution i discussed , it worked for me very fine

[squishmallowcow]

The re-adding it the PBR adds the following jump back in light of the fact that that gets blown away.The organization highlight is another I genuinely want to believe that they fix trusting that the sending will complete to roll out one minor improvement is crazy. Ideally that will be another issue they address pushing ahead too. cow squishmallows

[gadwm068]

I have it - in Flex Config (in Articles menu), I should utilize prepend, not affix, for physically unconfigure course map utilization in interface config.

Best of luck

Earnestly from Nik

CCIE, Irkutsk, Russia

Is anyone here to reply me here