BGP filtering of supernets out of classful space
In attempting to help someone with regards to BGP announcement filtering from the IRR we've found the following situation: A provider in China has been assigned addresses in the traditional class C space. APNIC's assignment is a /16 for this allocation. Said provider, trying to be good Internet citizens are announcing only aggregates of /16. However, they're running into several providers that are filtering the announcements because they aren't /24. Experimentation has proven that announcing /24's will solve this problem. This obviously clutters up the global routing tables. The primary justification I can see for such filtering is to prevent "sink routing" - or catching everything else where more specific routes don't exist. (This would probably be a Bad Thing for the provider foolishly making such announcements - a very effective self DoS attack.) What methodology are providers using for these types of route filtering issues now? (I'll save the IRR pulpit for later.) And yes, I have directed the provider having the routing issues to contact each ISP doing the filtering separately. -- Jeffrey Haas - Merit RSng project - jeffhaas@merit.edu
Jeff Haas wrote: [much discussion excised]
And yes, I have directed the provider having the routing issues to contact each ISP doing the filtering separately.
Jeff, Just how is the ISP in question going to contact each ISP doing this filtering? To be more specific, how will they know which ISPs ARE doing the filtering? Sure, they'll know about the ones they specifically have observed issues with, but beyond that, there's just no way to know. I continue to be concerned that some ISPs who do filtering do not provide ANY means to look at the routes they ARE accepting, nor necessarily post their filtering policy, thus providing very little useful mechanism other than complaints from end users for figuring out where problems exist. As a community, I think we can and should be working toward a much more robust mechanism. The routing registries are only part of the solution. Even when the proper data is there, cases have existed where providers use that data plus or minus additional data to decide what to accept. I'd like to see sites which filter provide a looking glass or similar so that other providers can quickly and efficiently debug routing issues, and also some known place where those providers doing filtering can be listed, along with test hosts which can be traced to for testing whether there are routing problems or not. Several folks will tell me I'm dreaming (or smoking something), no doubt. Dan -- ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com
On Fri, May 19, 2000 at 12:31:20PM -0400, Daniel Senie wrote:
Just how is the ISP in question going to contact each ISP doing this filtering? To be more specific, how will they know which ISPs ARE doing the filtering? Sure, they'll know about the ones they specifically have observed issues with, but beyond that, there's just no way to know.
No, there is no way to know. For similar reasons, one can never know if one's routes are going to be accepted by anyone. One of my favorite examples, which I'm certain many providers here run into while training individuals new to Internet routing, is the transfer of Lore. One can't just buy "Internet Core Routing, for Dummies" and learn all of the tips and tricks which many NANOG participants are aware of. You wouldn't know that several providers filter at /19 or /20, or may accept only classful announcements for the old classful space, except except except.... All providers are welcome to provide links to their filtering policies to the NANOG filter policies page at http://www.nanog.org/filter.html However, I'd argue the right place to put it would be in the IRR.
I continue to be concerned that some ISPs who do filtering do not provide ANY means to look at the routes they ARE accepting, nor necessarily post their filtering policy, thus providing very little useful mechanism other than complaints from end users for figuring out where problems exist. As a community, I think we can and should be working toward a much more robust mechanism.
For policy diagnostic purposes, the IRR is a fine place to put the data. A web page would suit as well but is hard to generate filters from automatically. Additionally, if its in a portable format one doesn't have to translate it from provider A's router-config du jour to your router-config du jour. I can sympathize with ISPs that don't wish to provide looking glasses into their networks. The looking glass provides data that several people in competing marketing departments would love - who they are peering with privately, internal topology views, etc. Admittedly some of this can be filtered on the looking glass, but why take the chance. (And I'd like to thank those providers who do make looking glasses available. They make the Internet much more pleasant to troubleshoot.)
The routing registries are only part of the solution. Even when the proper data is there, cases have existed where providers use that data plus or minus additional data to decide what to accept.
Similarly, one can't necessarily trust a given looking glass completely. A failure in a full mesh, AS confederations or route reflectors can result in an incomplete view. But it gets you over that first hump for the clueful when you need to call some network's routing engineers to solve routing issues.
Dan
-- Jeffrey Haas - Merit RSng project - jeffhaas@merit.edu
On Fri, 19 May 2000, Daniel Senie wrote:
I'd like to see sites which filter provide a looking glass or similar so that other providers can quickly and efficiently debug routing issues, and also some known place where those providers doing filtering can be listed, along with test hosts which can be traced to for testing whether there are routing problems or not.
Several folks will tell me I'm dreaming (or smoking something), no doubt.
Dan
Some providers are VERY paranoid about people seeing what their routing table looks like. I requested that one of our upstreams provide a looking-glass and their reply was "The LG code requires that we open up RSH on the routers. No Way!" So... I wrote looking-glass code that uses telnet. I provided it to the provider in question. Still no looking-glass nearly a year later. Oh well. John Fraizer EnterZone, Inc.
John Fraizer: Friday, May 19, 2000 1:24 PM
On Fri, 19 May 2000, Daniel Senie wrote:
I'd like to see sites which filter provide a looking glass or similar so
Some providers are VERY paranoid about people seeing what their routing table looks like. I requested that one of our upstreams provide a looking-glass and their reply was "The LG code requires that we open up RSH on the routers. No Way!"
I wrote looking-glass code that uses telnet. I provided it to
This I can understand ... the
provider in question. Still no looking-glass nearly a year later.
Maybe, if you'd based it on ssh, it might have flown better? I don't allow either telnet or FTP anywhere on my systems. For critical stuff (anything requireing passwds), allowed protocols are SSH, SMB (Samba forwarded over SSH), and HTTPS. We also use SSL POP3 and SSL SMTP and remote admin is VNC through SSH. The only unsecured port is standard SMTP and that's in the process of being AUTH'd (as soon as I free-up resources to do that). Many other shops I know are the same way, or they don't allow external connections at all (bastion hosts). That they don't allow external telnet sessions is no surprise.
John Fraizer wrote:
On Fri, 19 May 2000, Daniel Senie wrote:
I'd like to see sites which filter provide a looking glass or similar so that other providers can quickly and efficiently debug routing issues, and also some known place where those providers doing filtering can be listed, along with test hosts which can be traced to for testing whether there are routing problems or not.
Several folks will tell me I'm dreaming (or smoking something), no doubt.
Dan
Some providers are VERY paranoid about people seeing what their routing table looks like. I requested that one of our upstreams provide a looking-glass and their reply was "The LG code requires that we open up RSH on the routers. No Way!"
So...
I wrote looking-glass code that uses telnet. I provided it to the provider in question. Still no looking-glass nearly a year later.
Depending on vendor, you may provide lookingglass functionality over SSH. I feel it's pretty good to be reluctant on openening up rsh/telnet. Wether or not the provider in question want's to publish the information... ... is probably another another question, though a lot of it isn't hidden only by non-providing a lg. mh
Oh well.
John Fraizer EnterZone, Inc.
-- Michael Hallgren, http://m.hallgren.free.fr "If you want truly to understand something, try to change it" - Kurt Lewin (1890-1947)
I'd like to see sites which filter provide a looking glass or similar so that other providers can quickly and efficiently debug routing issues
try route-views.oregon-ix.net this week at ripe there was new discussion of my suggestion of the other year that registries publish their allocation length / address range in a machine readable fashion so we can automate our filtering. this may give a more homogenous and thus less surprising result. it does imply serious trust in the rirs' publishing consistency and correctness. randy
Happily, this goes directly in line with RFC2725 and RFC2754. On Fri, May 19, 2000 at 04:30:02PM -0700, Randy Bush wrote:
this week at ripe there was new discussion of my suggestion of the other year that registries publish their allocation length / address range in a machine readable fashion so we can automate our filtering. this may give a more homogenous and thus less surprising result. it does imply serious trust in the rirs' publishing consistency and correctness.
randy
-- Jeffrey Haas - Merit RSng project - jeffhaas@merit.edu
A provider in China has been assigned addresses in the traditional class C space. APNIC's assignment is a /16 for this allocation. Said provider, trying to be good Internet citizens are announcing only aggregates of /16.
However, they're running into several providers that are filtering the announcements because they aren't /24.
i can only imagine that these providers are confused by one vendor's (recently fixed) rather baroque filter rule syntax. randy
participants (6)
-
Daniel Senie -
Jeff Haas -
John Fraizer -
Michael Hallgren -
Randy Bush -
Roeland Meyer (E-mail)