North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: Winstar says there is no TCP/BGP vulnerability
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 expectedUntil 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 ....
Huh? You don't pay for peering traffic by the megabit, so the idea is to always prefer routes from peers.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,
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.- 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?
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?)