On 21-apr-04, at 9:56, Michel Py wrote:
For pure: "Don't blow me up with prefixes" just limit the maximum-prefix to some # over your expected peer's list.
Please allow me to try to make my point again: you store the expected peer maximum-prefix somewhere in your management system. I do understand the added complexity, but in the big scheme of things would it be _that_ more difficult to store a comma-delimited string or something that contains the prefixes that could be announced by that peer instead of the maximum-prefix? Yes, it generates more work to update the database, but OTOH it provides the LIII engineer with a lot more to troubleshoot issues. Is it simply not worth the work at your scale?
Until recently, I had always worked with maximum prefixes only, but last month I suggested something along the lines of the above to a customer. However, after spending an hour trying to come up with a prefix filter for just one peer I changed my mind. This just doesn't work unless your peers are all tiny, announcing a couple of prefixes or so, or you generate the filters from a routing registry. However, the latter is very problematic as well. Just installing RAtoolset requires a PhD in Unix system administration, and few networks register their information correctly. With max prefixes you can just set the limit at 10k and never look back. Obviously this still allows your peer to do lots of very bad things, but announcing the full table to you isn't one of them. Or you can keep the limit to 150% of what is actually announced but this requires more work and incurs occasional session drops because many peers don't announce an increase in the number of prefixes in advance.
use a route-map to add/remove metric or localpref? or any other settable thing on your side? or prepend or ....
Based on what criteria? Both the peer and the transit announce the same prefix with the same AS-PATH length. I agree that in many cases, favoring the route coming from the transit provider would work,
Huh? You don't pay for peering traffic by the megabit, so the idea is to always prefer routes from peers.
- In theory, I could add a "route-map blah deny 1" that matches everything, then manipulate the subsequent seqs at will, then remove the "route-map blah deny 1"; in this situation though, I do not see a clear advantage over clearing the session. What am I missing?
Traditional way: have both prefix and AS path filters. Only update one at a time. You should be ok even if one filter lets something through during an update. More advanced way: have route maps that tag routes with communities on ingress, allow only routes with the right communities on egress. Any problems with either set of route maps hits the implicit deny so the route won't be propagated so if something goes wrong, no harm, no foul. And a nice round of "clear ip bgp * in" and "clear ip bgp * out" afterwards never hurts. :-) (CPUs can't feel pain, right?)