BGP Question - how do work around pigheaded ISPs
Hey there. Due to the pigheadedness of a specific ISP (which I wil *not* allude to in any way, shape, or form, so don't bother asking), and in the interest of conserving IP addresses, I've been faced with quite a challenge. - The Premis: A parent organization has an unused /16 of address space, for arguments sake, let's say it's 172.16.0.0/16. It's out of the old "class B" address range. Two groups within the organization want to bring up independant Internet datacenters, and need /18 of address space, each. Since the parent organization owns an unsed /16, the IP registry refuses to give the child organizations any address space - they insist all address blocks assigned to the parent organization be used, first. ISPph (ph=pigheaded) has a BGP policy that filters out all routes in 128.0.0.0/2 longer than /16. - The network: One group has Internet connectivity to 2 Tier1 ISPs (ISPa and ISPb) in North America. They announce out 172.16.0.0/18 to both ISPs from AS65001. The other group gets Internet connectivity to ISPc and ISPc in South America. They announce 172.16.64.0/18 to their ISPs from AS65002. There is no private network connectivity or backbones between the 2 companies. - The result: ISPph blocks out the /18s at the peering connections to ISPa, ISPb, ISPc, and ISPd. So, customers of ISPph cannot see servers on AS65001 or AS65002. - The workaround: We announce 172.16.0.0/16 as well as 172.16.0.0/18 from AS65001 to ISPa and ISPb. In our preliminary testing, we've found that what happens is that ISPph would route traffic to 172.16.64.0/18 to ISPa (or ISPb, but we'll assume ISPa has a better connection to ISPph), because it learned the 172.16.0.0/16 route from there. ISPa is hearing the *more specific* /18 from ISPc and ISPd, so it transits the traffic over to ISPc, which then delivers it to the South American site. - Questions: 1) is there a reason to announce the /16 from both ASs? Is that "legal?" 2) under normal situations (assume no link failures) would this cause any problem? 3) Is there a link failure scenario that would cause the /16 to create a blackhole for the 172.16.64.0/18 network? 4) Would you recommend this as a fix? Of course, it would make ISPa transit for ISPph, but they're pigheaded enough to make the Internet suck that way. Thanks for your time! ---- Dani Roisman droisman@station.sony.com
On Fri, Feb 09, 2001 at 07:35:31PM -0800, Roisman, Dani wrote: ==>- The Premis: ==>A parent organization has an unused /16 of address space, for arguments ==>sake, let's say it's 172.16.0.0/16. It's out of the old "class B" address ==>range. Two groups within the organization want to bring up independant ==>Internet datacenters, and need /18 of address space, each. Since the parent ==>organization owns an unsed /16, the IP registry refuses to give the child ==>organizations any address space - they insist all address blocks assigned to ==>the parent organization be used, first. This is a frequent problem for those who have had address space from some of the older blocks and are trying to go back and better handle. You don't have to allude to who these ISP's are, they publically state their policies. Typically, for these ISP's, one premise is that filtering based on the minimum prefix size that the registry allocated in that particular /8 shields them from legal challenges related to having any sort of filtering policies in the first place. IMO, it just makes the liability greater. After all, what's the difference between 171.16.0.0/19, 171.16.32.0/19 and 64.255.0.0/19, 64.255.32.0/19, as long as the companies who are announcing the blocks are doing so responsibly and for good reason? Why should the first set be filtered but the second not? The next answer that you'll receive are "some of the older companies don't know how to responsibly announce their address space", because some do announce them as /24's. I think that a responsible policy which limits the announcements in the old B space to the minimum allocation ARIN is currently utilizing, or even /19, is perfectly sufficient. It keeps routing tables under control and protects against the infamous UUnet de-aggregation disaster or bad announcements with lengths longer than, say, /20. Yet another off-the-wall answer you'll get is that some ISP's have taken it into their own hands to stop announcements longer than /16's because some old companies might want to sell portions of their /16's to make money. With all the dot-coms closing, I think I'd be more worried about 209+ and 62/63/64... =) And finally, there's always the "there might be a chance someone will pay us to amend our filters for their slot" argument. /cah
On Fri, Feb 09, 2001 at 09:33:12PM -0800, Craig A. Huegen wrote:
This is a frequent problem for those who have had address space from some of the older blocks and are trying to go back and better handle. [snip]
One point you missed: without good/accurate registry data, there is no difference between "broken announcments" and "hijacked network". That is a strong operational reason to strictly follow the registry allocations, rather than the weak concern about people selling off chunks of legacy address space. I have been aware of several times when squatted, stolen, or misconfigured-into-others'-space has been caught by registry-minded filters. Specifically regarding slices of classical B-space and not yet allocated A-space. Cheers, Joe -- Joe Provo Voice 508.486.7471 Director, Internet Planning & Design Fax 508.229.2375 Network Deployment & Management, RCN <joe.provo@rcn.com>
On Mon, 12 Feb 2001, Joe Provo wrote:
I have been aware of several times when squatted, stolen, or misconfigured-into-others'-space has been caught by registry-minded filters. Specifically regarding slices of classical B-space and not yet allocated A-space.
Cheers,
Joe
Any time a network is caught announcing non-allocated address space, the registry should bill them accordingly. If they refuse to pay, the registry should yank their ASN. That would be strong encouragement to do the right thing. --- John Fraizer EnterZone, Inc
Information on stolen or squatted address space should be published, to ensure maximum shame for those involved. Daniel Golding NetRail,Inc. "Better to light a candle than to curse the darkness" On Mon, 12 Feb 2001, John Fraizer wrote:
On Mon, 12 Feb 2001, Joe Provo wrote:
I have been aware of several times when squatted, stolen, or misconfigured-into-others'-space has been caught by registry-minded filters. Specifically regarding slices of classical B-space and not yet allocated A-space.
Cheers,
Joe
Any time a network is caught announcing non-allocated address space, the registry should bill them accordingly. If they refuse to pay, the registry should yank their ASN. That would be strong encouragement to do the right thing.
--- John Fraizer EnterZone, Inc
A really quick inspection shows: 91.16.23.0/24 AS11770, although is is a history entry only at the moment: route-views.oregon-ix.net>sh ip bgp 91.16.23.0 BGP routing table entry for 91.16.23.0/24, version 6427742 Paths: (23 available, no best path) Not advertised to any peer 8517 9000 2548 1239 11770 (history entry) ... 103.22.7.0/24 AS9768 route-views.oregon-ix.net>sh ip bgp 103.22.7.0 BGP routing table entry for 103.22.7.0/24, version 6099648 Paths: (25 available, best #10) Not advertised to any peer 2551 1239 3608 3608 3608 9768 163.179.232.37 from 163.179.232.37 (163.179.232.37) Origin incomplete, localpref 100, valid, external ... Stolen is a lot harder to find. In the referenced message, Daniel L. Golding said:
Information on stolen or squatted address space should be published, to ensure maximum shame for those involved.
Daniel Golding NetRail,Inc. "Better to light a candle than to curse the darkness"
On Mon, 12 Feb 2001, John Fraizer wrote:
On Mon, 12 Feb 2001, Joe Provo wrote:
I have been aware of several times when squatted, stolen, or misconfigured-into-others'-space has been caught by registry-minded filters. Specifically regarding slices of classical B-space and not yet allocated A-space.
Cheers,
Joe
Any time a network is caught announcing non-allocated address space, the registry should bill them accordingly. If they refuse to pay, the registry should yank their ASN. That would be strong encouragement to do the right thing.
--- John Fraizer EnterZone, Inc
On Tue, 13 Feb 2001, Stephen Griffin wrote:
Stolen is a lot harder to find.
And then you have junk like: BGP routing table entry for 64.0.0.0/8, version 6739580 Paths: (27 available, best #27) Not advertised to any peer 8297 6453 1239 5696 15331 195.219.96.239 from 195.219.96.239 (195.219.96.239) Origin incomplete, localpref 100, valid, external which has been around for a long time. And which is obviously not being filtered by a lot of backbones. This could be a tricky way for someone to just use whatever otherwise unannounced space in 64/8, or it could just be a lame router configuration somewhere that the parties involved don't care to fix. But either way, it isn't very pretty going through the list of all the backbones that are not filtering this sort of stuff out and seeing just how long it is... it is truly amazing that there aren't more widespread and frequent screwups caused by bogus announcements.
"ms" == Marc Slemko <marcs@znep.com> writes: [...] This could be a tricky way for someone to just use whatever otherwise unannounced space in 64/8, or it could just be a lame router configuration somewhere that the parties involved don't care to fix.
Certainly the latter (never attribute to malice what can be explained with stupidity). It's just too easy to forget "no auto-summary", and too difficult to notice its effects - you'll attract traffic from unused addresses under the classful prefix (64.0.0.0/8 in this case), but there shouldn't be that much of it. Of course once in a while when a network using a more-specific prefix goes offline for a while, you may receive quite a bit of unexpected traffic. But I bet that most ISPs don't have good tools to detect this either. So we have to wait until a nice person signals the problem to the offender. For 64.0.0.0/8 this seems to have happened in the meantime... but now there's a route for 62.0.0.0/8 (the RIPE equivalent of 64.0.0.0/8), sigh. -- Simon.
On 27 Feb 2001, Simon Leinen wrote:
For 64.0.0.0/8 this seems to have happened in the meantime... but now there's a route for 62.0.0.0/8 (the RIPE equivalent of 64.0.0.0/8), sigh.
i dont know why you even allow 64/8 and/or 62/8 into your network. Filter them... Christian
On Tue, Feb 27, 2001 at 08:01:46AM -0800, Christian Nielsen wrote:
On 27 Feb 2001, Simon Leinen wrote:
For 64.0.0.0/8 this seems to have happened in the meantime... but now there's a route for 62.0.0.0/8 (the RIPE equivalent of 64.0.0.0/8), sigh.
i dont know why you even allow 64/8 and/or 62/8 into your network. Filter them...
Amen to that. While we have and can go on for days about filtering on the 'low end' of sizes in the modern allocation ranges, I sincerely hope no one in their right mind would attempt to argue that there's any purpose to accepting 24.0.0.0/8, 61.0.0.0/8 - 66.0.0.0/8. I'm certain folks will kvetch about being able to filter large aggregates in these spaces, but there is simply a lot of clueless classful configuration that goes on Out There. Unsuprisingly, the recent-allocation spaces get more hits on the filters than, say, net-24. Regardless on your stance of allocation-boundary filtering, this is just sane defense of your network against bogons. Cheers, Joe -- Joe Provo Voice 508.486.7471 Director, Internet Planning & Design Fax 508.229.2375 Network Deployment & Management, RCN <joe.provo@rcn.com>
On Tue, Feb 27, 2001 at 08:01:46AM -0800, Christian Nielsen wrote:
For 64.0.0.0/8 this seems to have happened in the meantime... but now there's a route for 62.0.0.0/8 (the RIPE equivalent of 64.0.0.0/8), sigh.
i dont know why you even allow 64/8 and/or 62/8 into your network. Filter them...
Aren't many Earthlink dialups in 64/8? Filtering that would mean his employees couldn't get Sprint DSL, and prevent millions of potential customers from reaching his web servers. That's not smart business. It's called "cutting off your nose to spite your face."
There are plenty of folks who have space in 64/8. However, no one should be classfully advertising 64.0.0.0/8, as it has not been assigned to any single entity. Therefore, anyone who is advertising this block is doing so in error, and it's permissible to filter the EXACT 64.0.0.0/8 route announcement. (as opposed to filtering "64.0.0.0/8 or longer", which would blackhole many folks) - Daniel Golding -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Shawn McMahon Sent: Tuesday, February 27, 2001 6:25 PM To: nanog@merit.edu Subject: Re: 64.0.0.0/8 etc. [was: Re: BGP Question - how do work around...] On Tue, Feb 27, 2001 at 08:01:46AM -0800, Christian Nielsen wrote:
For 64.0.0.0/8 this seems to have happened in the meantime... but now there's a route for 62.0.0.0/8 (the RIPE equivalent of 64.0.0.0/8),
sigh.
i dont know why you even allow 64/8 and/or 62/8 into your network. Filter them...
Aren't many Earthlink dialups in 64/8? Filtering that would mean his employees couldn't get Sprint DSL, and prevent millions of potential customers from reaching his web servers. That's not smart business. It's called "cutting off your nose to spite your face."
On Tue, Feb 27, 2001 at 06:33:05PM -0500, Daniel Golding wrote:
There are plenty of folks who have space in 64/8. However, no one should be classfully advertising 64.0.0.0/8, as it has not been assigned to any single entity.
Ever have one of those days where you bang your head against recalcitrant users who don't understand why a Fortune 100 corporation would need security policies all day, then come home and say something stupid on a (inter)national mailing list where hundreds of people you might find the desire to work for some day will read it? :-/
participants (11)
-
Christian Nielsen -
Craig A. Huegen -
Daniel Golding -
Daniel L. Golding
-
Joe Provo -
John Fraizer -
Marc Slemko -
Roisman, Dani -
Shawn McMahon -
Simon Leinen -
Stephen Griffin