Showing results for 
Search instead for 
Did you mean: 

changes to PBR slow to converge

Level 1
Level 1

I am using PBR to direct traffic as I migrate my network to new firewalls. PBR works, but changes that I make to the ACL used to make matches in the route-map take a while to take effect. It feels like it's being cached somewhere. The change eventually takes place within I would say 15 minutes, which if way too long for a production network. I need to coordinate PBR changes with changes to my firewalls.

I am using IOS 15.1 on Cat 4948 switches.

I have tried to modify the SVI by

  • no ip route-cache
  • no ip route-cache cef
  • ip route-cache policy
  • shut and no shut the ingress interface

No setting seems to reliably work.

I did try removing the route-map from the ingress interface and quickly re-applying it. That seemed to work, but is a mighty big hammer that will cause lots of collateral damage to everything else in the route-map.

I am running out of hair to pull out. :-(

Any suggestions?



2 Replies 2

Level 7
Level 7

Note The scale of hardware-based PBR is determined by TCAM size and the time required for the CPU to flatten the ACL before programming into hardware. The latter will noticeably increase if a PBR policy requires a considerable number of class-maps. For example, a PBR policy of 1,200 class-maps may require 60-90 minutes of "flatten" time before programming into hardware. This process may repeat if an adjacency change requires PBR reprogramming.

Thank you. I read the entire article. I have one match statement, and the total length of my ACL is less than 10 lines. I could probably manually calculate the TCAM entries faster than how long it takes for the change to take effect.

Review Cisco Networking for a $25 gift card