Re: BGP Question - how do work around pigheaded ISPs
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.
Be careful with that answer if you haven't worked in or run a network for a global enterprise that has multiple Internet access locations. Global enterprises pay ISP's to deliver Internet traffic LOCALLY; they don't run Internet backbones, and they have no intention to. Therefore, they want to assign different addressing to different areas in order to have the ISP's bring traffic to the region with that addressing. This differs from the ISP model where traffic arrives at the closest possible entrypoint into the network, then follows a backbone to its destination.
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. Why do people forget you can aggregate blocks at points other than the edge of the network. If UNISYS had IBM aggregate 129.227/16, there is no reason why all those /24's need to appear in the global route table outside of IBM's network. UNISYS can pay IBM to get local trafic locally, but there is no reason why the rest of the global Internet needs to see those more specific paths. As you might have figured out, announcing more specifics is a nifty way to get around ISP peering handoffs, which is why some ISPs don't like listening to more specific announcements for the same organization. If I can dump the traffic onto Sony's california network block, why do I want to listen to a more specific announcement from Sony's european offices and carry the traffic on my backbone to europe.
But is there a good reason that a block size of /19 shouldn't be accepted in this space? Is it not reasonable for an older global enterprise to want more Internet access locations for their enterprise, and therefore divide their address space up a bit more?
Except that is not what happens, and not really even good reason for dividing up their space. Access location has nothing to do with it. You divide up the space to announce different inter-provider path attributes, e.g. different AS Path, different MED, etc. 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. Yes, in the past there were networks who wanted to announce a seperate network for each dialup POP. Yes, there seems to be a constant influx of new people everyday who believe you must announce a seperate route for each access location in the global route table.
Some ISP's believe that when the registries allocated address space in the B space prior to CIDR times, that they intended for those companies only to announce that space as /16's. Okay, I can accept that, given the landscape at the time. However, the flaw that these ISP's are making in policy is the belief that all the organizations who received this space in the past won't use VLSM, and can't be responsible with addressing.
Unfortunately, history has shown this is true. 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.
From what I read of the current big attempt, I haven't heard a good story yet. There are several alternatives, which given my limited knowledge, all seem to work for this situation.
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 point * 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 network? ==>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 neighbors. /cah
On Sun, Feb 11, 2001 at 07:28:23PM -0800, Craig A. Huegen wrote:
* 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 network?
In the case of exactly the same global path... announce the less specific to the ISP along with the more specifics with the no-export community. How many large ISPs are *not* honouring communities like that from their customers? -- John Payne http://www.sackheads.org/jpayne/ john@sackheads.org http://www.sackheads.org/uce/ Fax: +44 870 0547954 To send me mail, use the address in the From: header
In the referenced message, Craig A. Huegen said: <snip>
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".
These companies, conversely, don't care about the costs that _every other BGP speaker in the default-free zone_ has to incur as a direct result of their actions. Who is expected to bear the cost, the one or the many? <snip>
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).
That ISP is less likely to have any successful litigation against it through sticking to their policy. Converse to your argument, ISP helpdesks could point their customers to call the company's helpdesk for failure to properly announce their address space. As the routing table size continues to increase, the number of entities who filter will increase, especially those who could better spend the upgrade costs on direct revenue generation. While it may never happen in my lifetime, full-scale IPv6 deployment will undoubtedly make filtering an absolute requirement.
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 neighbors.
Now we've moved from the hypothetical to the nasty. I think the community is better served with an open and frank discussion on prefix filters, what is reasonable, and technical solutions to the issues or non-issues cited. nb. I am fairly certain that I am in no way connected to the entity referenced above, I just don't want to denigrate into an argument about how filtering/deaggreagating is bad because so-and-so is stupid, smells funny, and is a Nazi*.
/cah
*Godwin's Law does not apply when a Nazi reference is intentionally chosen.
Thus spake "Stephen Griffin" <stephen.griffin@rcn.com>
These companies, conversely, don't care about the costs that _every other BGP speaker in the default-free zone_ has to incur as a direct result of their actions. Who is expected to bear the cost, the one or the many?
There is a cost associated with each AS connecting to the Net; if you want your customers to have access to every AS, you will accept all _reasonable_ advertisements. One prefix per AS is certainly more reasonable than common practice -- just look at The Cidr Report.
That ISP is less likely to have any successful litigation against it through sticking to their policy. Converse to your argument, ISP helpdesks could point their customers to call the company's helpdesk for failure to properly announce their address space.
Define "properly." The companies in question are different legal entities, operating in different countries, with no common ISPs, and no direction connection to each other. By definition, they are two different AS's with two different prefixes and two different routing policies. There is no valid way for these two companies to collectively announce a single route.
As the routing table size continues to increase, the number of entities who filter will increase, especially those who could better spend the upgrade costs on direct revenue generation.
History has shown the reverse to be true.
While it may never happen in my lifetime, full-scale IPv6 deployment will undoubtedly make filtering an absolute requirement.
Anyone who doesn't already filter extensively is an AS7007 waiting to happen.
Now we've moved from the hypothetical to the nasty. I think the community is better served with an open and frank discussion on prefix filters, what is reasonable, and technical solutions to the issues or non-issues cited.
Citing "technical reasons" for excessive filtering but allowing exceptions for your own customers is clearly hypocritical. It's either a technical problem or it's not. Consistency is the issue, not the theoretical limits of the routing system. S
In the referenced message, Stephen Sprunk said:
Thus spake "Stephen Griffin" <stephen.griffin@rcn.com>
These companies, conversely, don't care about the costs that _every other BGP speaker in the default-free zone_ has to incur as a direct result of their actions. Who is expected to bear the cost, the one or the many?
There is a cost associated with each AS connecting to the Net; if you want your customers to have access to every AS, you will accept all _reasonable_ advertisements. One prefix per AS is certainly more reasonable than common practice -- just look at The Cidr Report.
Again, what is reasonable? What makes a /32 less reasonable than a /24? Upon what basis do you define what is reasonable. I've shown my basis: when an entity announces the prefix they have been assigned, and filters are constructed based on registry allocation boundaries, there is no loss of visibility. It is only when an entity does not announce their allocated block, that there is a loss of visibility.
That ISP is less likely to have any successful litigation against it through sticking to their policy. Converse to your argument, ISP helpdesks could point their customers to call the company's helpdesk for failure to properly announce their address space.
Define "properly."
Announced as the allocated block.
The companies in question are different legal entities, operating in different countries, with no common ISPs, and no direction connection to each other. By definition, they are two different AS's with two different prefixes and two different routing policies. There is no valid way for these two companies to collectively announce a single route.
This is contrary to my interpetation of Dani's statement. The companies were sub-divisions of a single entity. They are only different because the single entity has chosen to make them different. There have been several means by which people have suggested. I, myself, suggested the use of GRE (or some other basis for a tunnel) to logically connect the networks together. If the two entities are entirely unconnected, then showing legal proof of same should be sufficient for receiving an allocation from ARIN (pending adherence to their allocation guidelines).
As the routing table size continues to increase, the number of entities who filter will increase, especially those who could better spend the upgrade costs on direct revenue generation.
History has shown the reverse to be true.
Who that filters is no longer doing so now? Who in here would rather spend money on a new router to hold the routing table rather than a new router to increase customer capacity? If everyone had a limitless supply of capital, and router vendors could scale their implementations infinitely, I, personally, wouldn't care if everyone deaggregated down to the /32 level.
While it may never happen in my lifetime, full-scale IPv6 deployment will undoubtedly make filtering an absolute requirement.
Anyone who doesn't already filter extensively is an AS7007 waiting to happen.
Ok, so you obviously agree with the premise of filtering, so what is "reasonable" in your eyes? More importantly, on what basis have you made the determination?
Now we've moved from the hypothetical to the nasty. I think the community is better served with an open and frank discussion on prefix filters, what is reasonable, and technical solutions to the issues or non-issues cited.
Citing "technical reasons" for excessive filtering but allowing exceptions for your own customers is clearly hypocritical. It's either a technical problem or it's not. Consistency is the issue, not the theoretical limits of the routing system.
Perhaps it is the issue for you. Consistency is also the issue for me, as well, but what I seek is consistency as to what announcement size is considered reasonable. If we all agreed on that, and filtered on it, then it doesn't matter who is hypocritical... which is the beauty of it all.
S
-----BEGIN PGP SIGNED MESSAGE----- The question seems (in my opinion) to be whether registries are delegating netblocks that can be further subdivided, or not. That is, some ISPs hold that if a registry has allocated /16s in some space, those allocations should not be subdivided by the allocatees. If a registry is allocating /19s minimum in some other space, then the allocatees cannot and should not split that space and advertise longer prefixes. In practice, how have corporate divestitures been handled by the registries? Have organizations with portable netblocks been able to split them up and get new allocations from the registries, following the corporate reorganizations? Surely someone on this list has worked through such an event. How did it go? === Bill Nickless http://www.mcs.anl.gov/people/nickless +1 630 252 7390 PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7 nickless@mcs.anl.gov -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com> iQCVAwUBOoiIcKwgm7ipJDXBAQGe6gQAhPs5CCeDOv/y39vHe5Kw2xYJGFK830US pCAjLPC3sUD7essYNAdHdIuTCuETx8L7YQVn2il5Nr6ShPVIhY9Mf8/VftE4AKfb FCbCDrcWfscHseKwjFuzmVUbTuT/6ek8P9bBhwtu/CD/0Gbpt98sY7LM8SXYAq2h or8WgdE86HY= =3ocO -----END PGP SIGNATURE-----
Never mind corporate changes, why should an allocatee not subdivide their space among their operating units or sites? To answer your specific question, all of the ones I have seen, the space has been divided on ARIN allocation boundaries. Roy Engehausen Bill Nickless wrote:
-----BEGIN PGP SIGNED MESSAGE-----
The question seems (in my opinion) to be whether registries are delegating netblocks that can be further subdivided, or not.
That is, some ISPs hold that if a registry has allocated /16s in some space, those allocations should not be subdivided by the allocatees. If a registry is allocating /19s minimum in some other space, then the allocatees cannot and should not split that space and advertise longer prefixes.
In practice, how have corporate divestitures been handled by the registries? Have organizations with portable netblocks been able to split them up and get new allocations from the registries, following the corporate reorganizations?
Surely someone on this list has worked through such an event. How did it go? === Bill Nickless http://www.mcs.anl.gov/people/nickless +1 630 252 7390 PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7 nickless@mcs.anl.gov
-----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>
iQCVAwUBOoiIcKwgm7ipJDXBAQGe6gQAhPs5CCeDOv/y39vHe5Kw2xYJGFK830US pCAjLPC3sUD7essYNAdHdIuTCuETx8L7YQVn2il5Nr6ShPVIhY9Mf8/VftE4AKfb FCbCDrcWfscHseKwjFuzmVUbTuT/6ek8P9bBhwtu/CD/0Gbpt98sY7LM8SXYAq2h or8WgdE86HY= =3ocO -----END PGP SIGNATURE-----
On Mon, 12 Feb 2001, Bill Nickless wrote:
The question seems (in my opinion) to be whether registries are delegating netblocks that can be further subdivided, or not.
That is, some ISPs hold that if a registry has allocated /16s in some space, those allocations should not be subdivided by the allocatees. If a registry is allocating /19s minimum in some other space, then the allocatees cannot and should not split that space and advertise longer prefixes.
All of this talk has me wondering about our network. It's much smaller than most of yours and according to the CIDR report, the only thing it says we should aggregate is a single /24 out of the /19. It is being announced for testing purposes and by the end of the week, the testing will be over and it will no longer be announced. My question however is along the lines of splitting the /19 up by swipping it out to BGP speaking customers who are announcing /24's, /23's, /22's, etc. The announcement needs to be made by them (from my understanding -- which may be wrong) for their multi-homing diversity to work. If I add an aggregate statement to our config, is it going to aggregate those /24's, etc that our BGP speaking clients are announcing to us into our main /19 announcement? This is something that I've been thinking about for a while and want to sure we're doing the technically sound thing.
In practice, how have corporate divestitures been handled by the registries? Have organizations with portable netblocks been able to split them up and get new allocations from the registries, following the corporate reorganizations?
It is my understanding (again, perhaps flawed) that legacy allocations were settlement-free but, if an organization has say a legacy B, is only using a /18 of it and wants to do the right thing and return the B in exchange for an /18 in CIDR space, they now get to pay for the /18 just because they wanted to do the right thing. I know if we had legacy space we'd hang on to it for financial reasons if none other. Someone correct me if I'm wrong on this. --- John Fraizer EnterZone, Inc
On Mon, 12 Feb 2001, John Fraizer wrote:
On Mon, 12 Feb 2001, Bill Nickless wrote:
The question seems (in my opinion) to be whether registries are delegating netblocks that can be further subdivided, or not.
That is, some ISPs hold that if a registry has allocated /16s in some space, those allocations should not be subdivided by the allocatees. If a registry is allocating /19s minimum in some other space, then the allocatees cannot and should not split that space and advertise longer prefixes.
All of this talk has me wondering about our network. It's much smaller than most of yours and according to the CIDR report, the only thing it says we should aggregate is a single /24 out of the /19. It is being announced for testing purposes and by the end of the week, the testing will be over and it will no longer be announced.
My question however is along the lines of splitting the /19 up by swipping it out to BGP speaking customers who are announcing /24's, /23's, /22's, etc. The announcement needs to be made by them (from my understanding -- which may be wrong) for their multi-homing diversity to work.
If I add an aggregate statement to our config, is it going to aggregate those /24's, etc that our BGP speaking clients are announcing to us into our main /19 announcement?
This is something that I've been thinking about for a while and want to sure we're doing the technically sound thing.
There are two kinds of aggregates. Regular, normal aggregates, and summary aggregates. Normal aggregates are announced in addition to any smaller blocks that make up the aggregate. At least one smaller block inside the aggregate is required to be present for the announcing router to announce the aggregate (i.e. an activating route). Summary aggregates work in a similar manner, but they surpress all advertisement of routes that are included within the aggregate - they are subsumed. Both types of aggregates should flag routes with the Atomic Aggregate attribute, to indicate that there is the possibility of some routing information having been lost. Be VERY careful with summary aggregates - if a customer is sending prepends, you will lose that information at your border to your peers and upstreams. Customers don't like that. It is possibly to selective surpress subordinate routes belonging to an aggregate on some router platforms.
In practice, how have corporate divestitures been handled by the registries? Have organizations with portable netblocks been able to split them up and get new allocations from the registries, following the corporate reorganizations?
It is my understanding (again, perhaps flawed) that legacy allocations were settlement-free but, if an organization has say a legacy B, is only using a /18 of it and wants to do the right thing and return the B in exchange for an /18 in CIDR space, they now get to pay for the /18 just because they wanted to do the right thing. I know if we had legacy space we'd hang on to it for financial reasons if none other.
If this were a just and sensible world, we would allow IP addresses to be treated like property. Folks with big, wasted, /8s could sell them to those who could or would use them. Because it would cost money to sit on unused space, no one would. We would get much better utilization. Considering the relativly large number of IPv4 addresses in play, the price would be reasonable, especially once folks sold their legacy space off.
Someone correct me if I'm wrong on this.
--- John Fraizer EnterZone, Inc
Daniel Golding NetRail,Inc. "Better to light a candle than to curse the darkness"
participants (9)
-
Bill Nickless -
Craig A. Huegen -
Daniel L. Golding -
John Fraizer -
John Payne -
Roy -
Sean Donelan -
Stephen Griffin -
Stephen Sprunk