Hi,
I work for an ISP and we use inter-VRF PBR to route forward and route leaking via BGP to route back.
We add/remove route-map sequences into/from our PBR, and related ACLs, daily and, sometimes, we suffer traffic blackholes due to route-map sequences not matching any existing ACL.
In most cases (if not all), it's because someone has added a new route-map sequence into the PBR matching an ACL that doesn't exist (if misspelt in the RM sequence's matching clause for example), or because someone has removed an ACL before removing any route-map matching it in the PBR first...
Logic would say that if a RM sequence is not matching any existing ACL it shouldn't match any traffic, be ignored basically, or, the opposite, deny it all, which means it would then have to use normal routing to go forward (which would cause the same issue though, i.e a traffic blackhole, as the source VRF, where PBR is applied, doesn't have routing to the required destinations in other VRFs), but no!
The RM sequence matches ALL traffic then... which causes it to be sent to the VRF associated to that specific faulty RM sequence (as we use inter-VRF as a reminder), preventing all RM sequences after the faulty one from being hit at all and, therefore, stopping VRFs associated (as in in their "set clauses") to those RM sequences further down the PBR order from receiving any traffic at the same time...
Some kind of "match-all" hidden implicit rule basically.
So my question is simple, is there any safeguard, or way-around, preventing that "match-all" implicit rule?
In the meantime, on top of internal deployment processes such as cfg peer-review before implementations, which greatly help in reducing the frequence of occurrence of those traffic blackholes, in order to quickly fix them when they happen, we have implemented a detection "mechanism", which is just an IP SLA constantly pinging something that is exclusively reachable via the very last RM sequence in the PBR, and that is monitored via SNMP, so if a PBR blackhole happens and the IP SLA can therefore not ping its destination anymore, our monitoring system will alert us about that IP SLA timing out...
We have also tried to match a second dummy ACL in a RM sequence hoping that if at least 1 of the 2 ACLs exist, the "match-all" implicit rule will not trigger but it doesn't work sadly. Both ACLs must exist...
