Re: Peer Filtering
That was one of our biggest worries people make mistakes and route leaks happen. They do. And it's not just mom+pop providers who occasionally leak an entire table. Big operators do it too. The unfortunate part we're faced with now is that we have several downstream customers who are multihomed. Because we're filtering out some of the prefixes that are not in an IRR, those routes are not nearly as attractive downstream giving the other carrier involved an advantage. I can see this is where convenience/economics start to kick in ;( One way or another, if you're providing transit, you absolutely need some means of filtering your downstreams using prefix filtering, and also preferable ASN filtering. Otherwise, your downstreams can inject any sort of crap into your table and you're opening yourself up to I-can't-believe-it's-not-youtube-hijacking-again situations. This is really bad and harmful for the internet. Max-prefixes are fine for peering exchanges, where you can just depeer if there's a problem, but they will not protect you against customers doing stupid stuff. The only issue for customers is not whether you do prefix filtering but whether you use IRR information or maintain your own internal database. The latter is re-inventing the wheel, imo. But lots of companies do it anyway. If your peering exchange doesn't provide multilateral peering, ask them to do so. This provides a natural platform for using route server client IRR prefix filtering, and route servers (despite a lot of well known and understood problems associated with them) can be very useful in this regard. Nick
Peer Filtering
Hi folks... I would like to know whether folks are limiting their peering sessions (BGP peering at public exchanges) only by max-prefix typically? Are we the only folks trying to filter all peers using IRR information? We've run across several peers now with 10,000+ prefixes who do not register barely half their prefixes in an IRR ... meaning that we deny the rest by default. I like to think that filtering on IRR is much better (not perfect by any means) as a practice but it's probably more *practical* to just limit max-prefix peers? We can't force our peers to register at a IRR and the only party that pays the price is us in that sense.. Am I thinking right on this? ;) Cheers, Paul The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you.
Re: Peer Filtering
$quoted_author = Paul Stewart ; I would like to know whether folks are limiting their peering sessions (BGP peering at public exchanges) only by max-prefix typically? Are we the only folks trying to filter all peers using IRR information? No, you're not the only ones. We've run across several peers now with 10,000+ prefixes who do not register barely half their prefixes in an IRR ... meaning that we deny the rest by default. Most peering agreements I have read require either registration of routes in an appropriate place or notification to the other party of an appropriate filter for their routes and/or AS path. In Au we have multi-lateral peering exchanges and at least the one $work is on requires registration of routes with the exchange provider who generates the appropriate filters. cheers marty -- supine: From the Latin for lying on one's back, to be supine has come to mean inactive. But as Damien Hirst suggests with his maxim Minimum effort for maximum effect, there's nothing wrong with being inactive. An Idler's Glossary - http://www.hermenaut.com/a158.shtml
Re: Peer Filtering
$quoted_author = John van Oppen ; Here in the US we don't bother, max-prefix covers it... It seems that US originated prefixes are rather sporadically entered into the routing DBs. ...and you are not worried about someone leaking a subset of routes? I understand that most failure cases would trigger a max-prefix but a typo could allow just enough leakage to not hit max-prefix and yet still make something important unreachable. cheers marty -- with usenet gone, we just don't teach our kids entertainment-level hyperbole any more. --Paul Vixie http://www.merit.edu/mail.archives/nanog/2006-01/msg00593.html
RE: Peer Filtering
Yep agreed...We balance that by keeping the max-prefix no more than about 40% over the current prefix limit on each peer. For us it is a trade-off, accept the routes or don't send the traffic to peering. The couple of times I have seen route leaks that involved one or two routes they were paths that worked, they were just wrong and we ended up just throwing a prefix-list on that peer. The thing is, one basically has to trust one's transit providers which don't always filter well. Given this trusting one's peers at least some-what does not seem too out there. John van Oppen Spectrum Networks LLC Direct: 206.973.8302 Main: 206.973.8300 Website: http://spectrumnetworks.us -Original Message- From: Martin Barry [mailto:ma...@supine.com] Sent: Monday, February 02, 2009 7:22 PM To: nanog@nanog.org Subject: Re: Peer Filtering $quoted_author = John van Oppen ; Here in the US we don't bother, max-prefix covers it... It seems that US originated prefixes are rather sporadically entered into the routing DBs. ...and you are not worried about someone leaking a subset of routes? I understand that most failure cases would trigger a max-prefix but a typo could allow just enough leakage to not hit max-prefix and yet still make something important unreachable. cheers marty -- with usenet gone, we just don't teach our kids entertainment-level hyperbole any more. --Paul Vixie http://www.merit.edu/mail.archives/nanog/2006-01/msg00593.html
