I'm trying to understand what all the implications of running BGP4 on a network with a prefix longer than 19 bits. Here are some of the points I am thinking about. <flameshields> If I go ahead and announce a /20 via two backbones, one of which is the provider of the address space, then there will be redundant routes for this space as the backbone provider will be announcing the /19 (or shorter) block themselves. If I do this, it adds to the routing table glut, among other things. The advantage gained is questionable. If my link to the provider that the space comes from goes down, they are still announcing and I'll only be able to reach where my path via the alternate provider is shorter than the path to the down provider itself. OTOH If the provider were to be convinced to stop announcing for my /20, then I'm going to get filtered at Sprint and AGIS and whoever else is doing this and there won't be any /19 announcement that I can use a default path on. But the real catch here is that for the provider to stop announcing my /20 they have to split their /19 into two /20's. And if that was really a /18 that means they will be announcing a /19 and a /20 where before only a /18. This gets worse the larger their block was. Even worse than that, by doing this, they now have a /20 (the other half of the /19 my /20 is in) with other customers who will now also be filtered out at Sprint and AGIS and whoever else. While it can be OK to me if I want to give up that reachability, this is also imposing this on the other customer(s) in the other /20. So that provider is not even likely to do that. So, should I add to the glut of routes or should I add to the glut of routes? This needs to be simpler. </flameshields> -- Phil Howard +-------------------------------------------------------------+ KA9WGN | House committee changes freedom bill to privacy invasion !! | phil at | more info: http://www.news.com/News/Item/0,4,14180,00.html | milepost.com +-------------------------------------------------------------+
Why should you concern yourself with the problems of a multi-billion dollar company like Sprint? Marcus R. Williams, Jr. security@tomco.net ISP Programmer / Engineer On Thu, 18 Sep 1997, Phil Howard wrote:
Date: Thu, 18 Sep 1997 18:22:19 -0500 From: Phil Howard <phil@charon.milepost.com> To: nanog@merit.edu Subject: BGP4 on a /20
I'm trying to understand what all the implications of running BGP4 on a network with a prefix longer than 19 bits. Here are some of the points I am thinking about.
<flameshields>
If I go ahead and announce a /20 via two backbones, one of which is the provider of the address space, then there will be redundant routes for this space as the backbone provider will be announcing the /19 (or shorter) block themselves.
If I do this, it adds to the routing table glut, among other things. The advantage gained is questionable. If my link to the provider that the space comes from goes down, they are still announcing and I'll only be able to reach where my path via the alternate provider is shorter than the path to the down provider itself.
OTOH
If the provider were to be convinced to stop announcing for my /20, then I'm going to get filtered at Sprint and AGIS and whoever else is doing this and there won't be any /19 announcement that I can use a default path on.
But the real catch here is that for the provider to stop announcing my /20 they have to split their /19 into two /20's. And if that was really a /18 that means they will be announcing a /19 and a /20 where before only a /18. This gets worse the larger their block was.
Even worse than that, by doing this, they now have a /20 (the other half of the /19 my /20 is in) with other customers who will now also be filtered out at Sprint and AGIS and whoever else. While it can be OK to me if I want to give up that reachability, this is also imposing this on the other customer(s) in the other /20. So that provider is not even likely to do that.
So, should I add to the glut of routes or should I add to the glut of routes?
This needs to be simpler.
</flameshields>
-- Phil Howard +-------------------------------------------------------------+ KA9WGN | House committee changes freedom bill to privacy invasion !! | phil at | more info: http://www.news.com/News/Item/0,4,14180,00.html | milepost.com +-------------------------------------------------------------+
On Thu, 18 Sep 1997, Phil Howard wrote:
The advantage gained is questionable. If my link to the provider that the space comes from goes down, they are still announcing and I'll only be able to reach where my path via the alternate provider is shorter than the path to the down provider itself.
Ummm...why would your provider be announcing your routes if your link to them is down? Sure, they will still be announcing the aggregate that contains your prefix, but the most specific route always wins (barring policy that prevents it from winning).
If the provider were to be convinced to stop announcing for my /20,
Generally a good way to convince your provider to stop announcing your routes is to stop announcing your routes to them.
then I'm going to get filtered at Sprint and AGIS and whoever else is doing this and there won't be any /19 announcement that I can use a default path on.
Providers ALWAYS announce their aggregates. If your provider is flapping their aggregates based on the state of downstream customers, you need to identify your provider here so they can be beat on in public.
But the real catch here is that for the provider to stop announcing my /20 they have to split their /19 into two /20's. And if that was really a /18 that means they will be announcing a /19 and a /20 where before only a /18. This gets worse the larger their block was.
This doesn't make any sense. I think you are forgetting that the most specific always wins.
This needs to be simpler.
It is not as complicated as you think. Announce the space that you have been allocated to all of your providers. Ensure your providers let your announcements out of their networks. The only time you may have a problem is if your link to the provider that allocated you the space goes down. Then you have to hope that that provider will allow more specifics of their aggregates to be announced to them by peers. If they don't allow this, pressure them to. You also have to hope that the path between the provider that allocated your addresses and your other provider does not cross a provider that filters at /19. Ideally the two are peering with each other. pbd -- "Seems she thought of me as some mystic, fatalistic, mystical guru Me, I haven't got a clue." -- Tears for Fears, "Cold"
The advantage gained is questionable. If my link to the provider that the space comes from goes down, they are still announcing and I'll only be able to reach where my path via the alternate provider is shorter than the path to the down provider itself.
Ummm...why would your provider be announcing your routes if your link to them is down? Sure, they will still be announcing the aggregate that contains your prefix, but the most specific route always wins (barring policy that prevents it from winning).
Statically coded route? They have a /19 (or shorter) and it is all chopped up (and perhaps filled up) with customers using small networks (/20 or longer prefixes). They do the announcing. What would change if I want to do my own and I am a /20 in there?
If the provider were to be convinced to stop announcing for my /20,
Generally a good way to convince your provider to stop announcing your routes is to stop announcing your routes to them.
But that isn't just automatic, surely. Don't they have to remove the statements from the configuration of the router that originates the announcements?
then I'm going to get filtered at Sprint and AGIS and whoever else is doing this and there won't be any /19 announcement that I can use a default path on.
Providers ALWAYS announce their aggregates. If your provider is flapping their aggregates based on the state of downstream customers, you need to identify your provider here so they can be beat on in public.
I'm not expecting their routes to flap based on downstream. I am trying to figure out if they will announce their /19 regardless. But I have determined this is not an issue as long as more specific routes take precendence over fewer hops. Next concern is making sure my more specific route really gets through the provider that also announces the aggregate. That could depend on provider policy.
But the real catch here is that for the provider to stop announcing my /20 they have to split their /19 into two /20's. And if that was really a /18 that means they will be announcing a /19 and a /20 where before only a /18. This gets worse the larger their block was.
This doesn't make any sense. I think you are forgetting that the most specific always wins.
Someone said always. Someone else said usually. Does the RFC say always?
This needs to be simpler.
It is not as complicated as you think. Announce the space that you have been allocated to all of your providers. Ensure your providers let your announcements out of their networks.
There is a list of providers (perhaps incomplete) that block longer networks. Is there a list of providers that block from their customers or is it safe to assume every provider has no problem with this? I did mention before in another posting that these are extra routes that would not have to be here were it not for some provider filtering out long networks. Funny how trying to reduce routes on their own networks gives them less of the advantage expected and imposes more burden on everyone else.
The only time you may have a problem is if your link to the provider that allocated you the space goes down. Then you have to hope that that provider will allow more specifics of their aggregates to be announced to them by peers. If they don't allow this, pressure them to. You also have to hope that the path between the provider that allocated your addresses and your other provider does not cross a provider that filters at /19. Ideally the two are peering with each other.
Suppose my link to them is down. Suppose they do allow the more specific routes to come in via peers. Now also suppose that some branch of their network has to go through the origin of the block I am in, such as others in the same locality whose links have not gone down (e.g. my circuit got backhoed or something). Will the routes even go through the originating router? -- Phil Howard +-------------------------------------------------------------+ KA9WGN | House committee changes freedom bill to privacy invasion !! | phil at | more info: http://www.news.com/News/Item/0,4,14180,00.html | milepost.com +-------------------------------------------------------------+
On Fri, 19 Sep 1997, Phil Howard wrote:
Statically coded route? They have a /19 (or shorter) and it is all chopped up (and perhaps filled up) with customers using small networks (/20 or longer prefixes). They do the announcing. What would change if I want to do my own and I am a /20 in there?
They setup a BGP session with you. Then they ensure your routes are allowed to be announced to their peers/providers. After the BGP session is stable it is generally a good idea to have them delete the static routes they have for your prefixes. They only announce your more specific prefixes when they hear about them via BGP.
But that isn't just automatic, surely. Don't they have to remove the statements from the configuration of the router that originates the announcements?
If you setup BGP with them YOUR router originates the announcements.
I'm not expecting their routes to flap based on downstream. I am trying to figure out if they will announce their /19 regardless. But I have determined this is not an issue as long as more specific routes take precendence over fewer hops. Next concern is making sure my more specific route really gets through the provider that also announces the aggregate. That could depend on provider policy.
Isn't the provider announcing the aggregate one of your upstreams?
Someone said always. Someone else said usually. Does the RFC say always?
The latest BGP draft says: When overlapping routes are present in the same Adj-RIB-In, the more specific route shall take precedence, in order from more specific to least specific. See section 9.1.4 of ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-bgp4-06.txt
There is a list of providers (perhaps incomplete) that block longer networks. Is there a list of providers that block from their customers or is it safe to assume every provider has no problem with this?
I haven't heard of providers not accepting routes from their customers, provided the routes are aggregated as much as possible and the customer is authorized to announce them.
I did mention before in another posting that these are extra routes that would not have to be here were it not for some provider filtering out long networks. Funny how trying to reduce routes on their own networks gives them less of the advantage expected and imposes more burden on everyone else.
I don't follow. You would have to announce routes covering your address space regardless of other providers' policy, no?
Suppose my link to them is down. Suppose they do allow the more specific routes to come in via peers. Now also suppose that some branch of their network has to go through the origin of the block I am in, such as others in the same locality whose links have not gone down (e.g. my circuit got backhoed or something). Will the routes even go through the originating router?
If your provider is letting the routes in from peers, then the routes should be present on all of their transit routers. If the routes are not, then their iBGP isn't meshed properly. pbd -- "Seems she thought of me as some mystic, fatalistic, mystical guru Me, I haven't got a clue." -- Tears for Fears, "Cold"
participants (3)
-
Bradley Dunn -
Phil Howard -
Security Administrator