changes to PBR slow to converge

[kevinhsieh]

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?

Thanks,

Kevin

[a.alekseev]

http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4500/12-2/54sg/configuration/guide/config/pbroute.html

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.

---

[kevinhsieh]

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.