Greg A. Woods wrote:
Well if these "anti-routes" really do have to be manually configured then it's still not really scalable. If their advertisement in the routing protocols could somehow be automated and hard to disable then maybe they'd obviously be of some use.
Perhaps "redistribute null" or "redistribute blackhole" (or insert your vendor's equivalent here) could be used to redistribute static null routes as anti-routes. Provided that the violators are being filtered by null routes as opposed to access lists, this could be made to work.
Clearly a "hidden" null route (or even a real packet filter dropping packets for some subnet) does violate the advertisement of the larger aggregate route, and from what I've seen there are lots of people who are "surprised" (to say the least) to learn that they can't get packets to these null-routed networks via an encompassing route advertised by one of their upstreams. Packets is packets boyz and goilz, and if you're advertising transit across your borders but not actually providing it then you're most definitely not a very good network neighbour. I.e. policy based routing should be either outlawed for transit providers, or required to be clearly advertised in such a way that network peers can automate their routing decisions based on real-time policy changes within their peer's networks (but perhaps that's another non-operational discussion! :-).
Trying to keep the politics aside as much as possible, it's conceivable that "not advertising anti-routes for traffic you plan to drop while continuing to advertise routes for the parent network" could in the future come to be seen as bad as "blackholing by advertising (potentially more specific) routes you aren't entitled to advertise" is today. In other words, if an accepted anti-route capability existed, there would no longer be any excuse for effective (as opposed to explicit) blackholing. Mark