cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1175
Views
1
Helpful
7
Replies

Firepower 2140 with Policy-Based Routing

ABaker94985
Spotlight
Spotlight

We've had PBR configured for some time on 7.0.2, and it was working fine. We upgraded a couple months ago from 7.0.2 to 7.0.4, and since then, we can't make any deployments. What happens is that deployments fail, the configuration rolls back, and suddenly ALL traffic is policy routed. We've discovered that we can attempt to remove the PBR flexconfig and deploy, which fails, followed by replacing the PBR flexconfig, which fails, but everything comes back up. We've tried the predeploy script to remove policy-based routing, but it fails (see logs below); however, as far as I can tell, there actually were no changes made to the FTD for this. 

 

This firewall is running OSPF, which appears to be the culprit: "FPR-01 >> error : ERROR: route-map PBR_Route_Map-Inside is attached to routing protocols." Something must have changed in the code regarding PBR flexconfig when we upgraded to 7.0.4. We've had multiple open TAC cases, but no resolution, and there are a stack of changes we need to deploy. We have several VPNs that terminate to this FTD (actually, an HA pair if it matters), so we need to be able to redistribute these routes into OSPF. It's not feasible to remove OSPF from the configuration.

 

I'm not sure if anyone else has experienced this, and I'm not sure if upgrading to 7.0.5 will help. Any thoughts as to what we might try? The deployment logs are below. Thanks

 

=============================

 

Refer to the following troubleshooting information when contacting Cisco TAC.

Lina messages
FMC >> clear configuration session OBJECT
FPR-01 >> info : Session OBJECT does not exist.

FMC >> clear configuration session FMC_SESSION_1
FPR-01 >> info : Session FMC_SESSION_1 does not exist.

FMC >> clear configuration session FMC_SESSION_2
FPR-01 >> info : Session FMC_SESSION_2 does not exist.

FPR-01 >> info : WARNING: If access-list PBR_ACL_inside having destination "any\any4\any6" is used as match criteria for a route map, and applied to any routing protocol it will not have any effect. Instead use standard ACL or extended ACL without any\any4\any6 in destination.

FPR-01 >> info : WARNING: Other committed configuration sessions currently exist (use 'show configuration session' command to view them). Overlapping changes between these sessions might lead to inconsistent/unexpected changes to the running configuration when reverted in the wrong order.

FMC >> no route-map PBR_Route_Map-Inside permit 10
FPR-01 >> error : ERROR: route-map PBR_Route_Map-Inside 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-Inside permit 10

Other logs

Lina config ROLLBACK failure log
Lina configuration application failure. Error in lina apply phase due to Config Error response from LINA

Rollback skipped as Lina and SNORT are in sync
Write mem executed as Lina and SNORT are in sync

Lina write mem operation successful

1 Accepted Solution

Accepted Solutions

Flex-config is awful and it's a shame for Cisco that after so many years we still don't have feature parity between ASA CLI and FTD (although PBR is a native feature as of FTD 7.2). There was a discussion in the past about this issue, not sure if it can help though. Few workarounds were suggested, e.g. remove PBR Flexconfig with the prepend flexconfig and add a new one with the append flexconfig on each deployment. Personally I didn't try them.

https://community.cisco.com/t5/cisco-bug-discussions/cscve66879-fmc-6-2-unassigning-flexconfig-that-uses-a-route-map/td-p/3398292

 

View solution in original post

7 Replies 7

check any routing protocol you run like OSPF BGP EIGRP 
check if you config any route-map to filter prefix 

There is only one route-map for the entire system, and it's for policy-based routing.

Flex-config is awful and it's a shame for Cisco that after so many years we still don't have feature parity between ASA CLI and FTD (although PBR is a native feature as of FTD 7.2). There was a discussion in the past about this issue, not sure if it can help though. Few workarounds were suggested, e.g. remove PBR Flexconfig with the prepend flexconfig and add a new one with the append flexconfig on each deployment. Personally I didn't try them.

https://community.cisco.com/t5/cisco-bug-discussions/cscve66879-fmc-6-2-unassigning-flexconfig-that-uses-a-route-map/td-p/3398292

 

Thanks for the reply, tvotna. Yes, we've tried that, and unfortunately, all traffic is policy-routed until we try to remove/redeploy (failure) and readd/redeploy (also failure) but things work after the last attempt. 

I didn't realize PBR is native in 7.2, so I'll have to check that out. We may decide to go that route, so I'll let you know.

ABaker94985
Spotlight
Spotlight

tvotna, I believe your suggestion was valid, so a big thanks! The preconfigured "Policy_Based_Routing_Clear" script includes "clear configure policy-route", which I suspects does not include removing policy-route configuration under the interface. I believe the key part of the error message is "or used in policy based routing," which I'm now interpreting as configuration remaining under the interface. I also don't believe the actual error has anything to do with a dynamic routing protocol - in our case, it's just extraneous information. Flexconfig configuration is now added to the prepend section to remove the route-map configuration from the interace before everything else.

but you run 7.0.2 I already notice bug 
https://community.cisco.com/t5/cisco-bug-discussions/cscve66879-fmc-6-2-unassigning-flexconfig-that-uses-a-route-map/td-p/3398292/page/2

but I think it effect 6.2.x not 7.0.x, 
anyway 
glad your issue solved
heve a nice day . 

ABaker94985
Spotlight
Spotlight

I looked at the bug earlier and noticed it was for 6.2. However, no known fixed version is listed. Either way, we didn't have the problem with 7.0.2 and do with 7.0.4. Regarding bugs, you have to take them with a bag of salt. We had chronic issues with SNMP bugs that were never resolvable with TAC's assistance and were still broken when using fixed releases. We just need it working. 

Review Cisco Networking for a $25 gift card