North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: BGP Question - how do work around pigheaded ISPs
- From: Craig A. Huegen
- Date: Sun Feb 11 22:32:03 2001
On Sun, Feb 11, 2001 at 04:43:41PM -0800, Sean Donelan wrote:
==>On Sun, 11 February 2001, "Craig A. Huegen" wrote:
==>> The original poster didn't entirely make it clear whether the other
==>> remaining /18's would be used by other sections of the parent company,
==>> but that's not the point. If the space had been allocated from
==>> 206+ or 62/63/64, his announcements would have been accepted.
==>> Just because their parent company has been around for a while means that
==>> some ISP's penalize them. One could guess from his e-mail address that
==>> the parent company is one of the larger global enterprises in the world.
==>Big doesn't mean right. Old doesn't mean wise.
==>The net is full of "big" doing really dumb things, which the rest
==>of us are stuck working around. Net 24 is a "big" example, or
==>Net 12 in Class A space.
==>Look at UNISYS's net 129.227/16 or any of the other examples in
==>traditional Class B space.
Conversely, big doesn't mean wrong, and old doesn't mean stupid.
I won't defend bad uses of address space. I can find many, many
examples, from large enterprises in old, classical space, to very large
service providers in new, classless space. As I said previously, I
certainly don't support the announcement of a /16 as /24's as a
misconfiguration. I don't support the announcement of a /16 as /17's,
18's, 19's, 20's, etc. if they *can* be aggregated.
At the same time, I'm defending responsible use.
These companies who have had classful address space are now being forced
to go back to their registry, rejustify address space, and assuming they
can do it, spend tens of thousands of dollars to renumber their networks
into these new blocks so that they can responsibly use address space.
These ISP's causing them to do it have no care for those costs -- but I
can bet you those tens of thousands of dollars they'd care if they had
to renumber every time they wanted to add a pop to their network. They
will happily offer alternatives -- "you buy service from me and we'll
throw those technical reasons why we won't accept those announcements
right out the window for you".
==>In general, if you look at most global enterprises who don't run Internet
==>backbones, you'll also find they rarely have divergent routing policies.
==>The AS Path is identical for all the locations because global enterprises
==>have global purchase agreements. If you want to divide your /16 up
==>within UUNET, fine. Just pay UUNET to aggregate your block before passing
==>the announcement outside UUNET's network.
I've seen more examples of divergent routing policies in global companies
than congruency with providers.
==>Why do people forget you can aggregate blocks at points other than the
==>edge of the network.
A few reasons why it's not offered by providers in the first place:
* It represents risk of blackholing traffic for a particular location,
unless conditional advertisements are used, which plays into my next
* How many of the very large providers have developed the capabilities to,
or even want to, manage a large amount of addressing manipulation at
the massive amount of peer/transit borders across their entire
==>If you use the same upstreams for all your locations, there is no reason
==>why the rest of the global routing table needs to see your seperate
==>access locations. Whether it is a /32 or a /16, if the global path
==>is identical, then there is no reason for a more specific announcement.
==>We don't need to know you have a 3000 access locations in your network.
I'm not disputing this, as long as the provider is willing to use
conditional summary advertisements to avoid blackholes and is actually
willing to configure this address manipulation at every interprovider edge.
I'm covering the case where different providers are used in different
locations, where the global path is NOT identical.
==>As you point out, most ISPs will listen to longer announcements *IF* you
==>can give a good story. The reality is there are few good stories in
==>comparison to the number of flawed attempts.
There is one particular ISP who is dead-set in refusing to allow exceptions.
I suppose it's just going to come to a head at some point, with an enterprise
telling the customers of said ISP "sorry, call your ISP's help desk" (as
some already do today).
I've been made aware of at least 10 customers who have left said ISP after
said customers were unable to reach certain networks.
...of course, that ISP will happily perform hypocritcal acts such as
announcing their customers' blocks that violate this policy. I can
see how some business people can't blame them, but it casts very serious
shadows on any technical excuses as to why they won't accept them from