Hey there.. I'd imagine this works fine, but doesn't it leave you w/ inconsistent-as, where you've got a prefix being advertised from the private ASN, stripped & replaced w/ each upstream ASN? I mean, it should work, but is it a very good idea? The inconsistent-as list isn't _too_ big right now, which is good, as each one effectively breaks a number of common path filters. But if that starts to becomes common practice, the list gets bigger and bigger & more filters get broken. ..Dylan
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Jesper Skriver Sent: Friday, April 07, 2000 2:21 PM To: Daniel L. Golding Cc: David Harrison; nanog@merit.edu Subject: Re: Policies: Routing a subset of another ISP's address block
Actually I've helped quite a few such customers, my recommendation usually is to get PI space from RIPE, and get both providers to announce it from their ASN, this works quite well, and also save a ASN - if the customer really want to run BGP, we have arrangements with other ISP's here, that we find a private ASN (that none of us use currently), and assign this ASN to the customer, and we then strip the private ASN on the edges of our network.
this is interesting (since it overwrites the rule that multihoming to two isps requires a public asn assignment) and i've tested exactly this scenario (again, a customer uses some private asn and is peering with two isps; both of them strip this asn at their boundaries (remove-private-as)) in my lab before and it worked fine. it results in propagating routes to the same networks with two distinct as path attributes, though. i've been looking for any operational experience with this setup. so, do you claim that you couldn't detect *any* problems with this setup? -- dima.
it does generate inconsistent origin as'es and it does break path filters, but not only. it breaks all the tools/methods based on the uniqueness of the route->origin-as mapping. i'm looking for a more or less complete list of these tools/methods. it seems, though, that the inconsistent-as list is growing and this doesn't produce too much panic. and if you examine this list more closely, you'll notice that it looks like the major part of it is generated by the isps doing the aforementioned trick. -- dima.
-----Original Message----- From: Greene, Dylan [mailto:DGreene@NaviSite.com] Sent: Friday, April 07, 2000 6:06 PM To: 'Dmitri Krioukov'; Jesper Skriver Cc: nanog@merit.edu Subject: RE: Policies: Routing a subset of another ISP's address block
Hey there..
I'd imagine this works fine, but doesn't it leave you w/ inconsistent-as, where you've got a prefix being advertised from the private ASN, stripped & replaced w/ each upstream ASN?
I mean, it should work, but is it a very good idea? The inconsistent-as list isn't _too_ big right now, which is good, as each one effectively breaks a number of common path filters. But if that starts to becomes common practice, the list gets bigger and bigger & more filters get broken.
..Dylan
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Jesper Skriver Sent: Friday, April 07, 2000 2:21 PM To: Daniel L. Golding Cc: David Harrison; nanog@merit.edu Subject: Re: Policies: Routing a subset of another ISP's address block
Actually I've helped quite a few such customers, my recommendation usually is to get PI space from RIPE, and get both providers to announce it from their ASN, this works quite well, and also save a ASN - if the customer really want to run BGP, we have arrangements with other ISP's here, that we find a private ASN (that none of us use currently), and assign this ASN to the customer, and we then strip the private ASN on the edges of our network.
this is interesting (since it overwrites the rule that multihoming to two isps requires a public asn assignment) and i've tested exactly this scenario (again, a customer uses some private asn and is peering with two isps; both of them strip this asn at their boundaries (remove-private-as)) in my lab before and it worked fine. it results in propagating routes to the same networks with two distinct as path attributes, though. i've been looking for any operational experience with this setup. so, do you claim that you couldn't detect *any* problems with this setup? -- dima.
This was a relatively attractive option several years ago, when bgp-capable routers were expensive enough to limit their practical availability to large-ish companies. Considering the current pricing on proven BGP-capable routers (i.e., with careful prefix filtering, even a 26xx can take full routes from a few peers/upstreams), what's the point of this method now? Actually, there's no reason one couldn't do this with a 2501 advertising one's own routes, and using dual defaults. : it does generate inconsistent origin as'es and it does break : path filters, but not only. it breaks all the tools/methods : based on the uniqueness of the route->origin-as mapping. i'm : looking for a more or less complete list of these tools/methods. : : it seems, though, that the inconsistent-as list is growing and : this doesn't produce too much panic. : : and if you examine this list more closely, you'll notice that it : looks like the major part of it is generated by the isps doing : the aforementioned trick. : : > I'd imagine this works fine, but doesn't it leave you w/ inconsistent-as, : > where you've got a prefix being advertised from the private ASN, : > stripped & : > replaced w/ each upstream ASN? : > : > I mean, it should work, but is it a very good idea? The : > inconsistent-as list : > isn't _too_ big right now, which is good, as each one effectively breaks a : > number of common path filters. But if that starts to becomes common : > practice, the list gets bigger and bigger & more filters get broken. : > : > > : > > Actually I've helped quite a few such customers, my recommendation : > > usually is to get PI space from RIPE, and get both providers to announce : > > it from their ASN, this works quite well, and also save a ASN - if the : > > customer really want to run BGP, we have arrangements with other ISP's : > > here, that we find a private ASN (that none of us use currently), and : > > assign this ASN to the customer, and we then strip the private ASN on : > > the edges of our network. : > : > this is interesting (since it overwrites the rule that multihoming to two : > isps requires a public asn assignment) and i've tested exactly : > this scenario : > (again, a customer uses some private asn and is peering with two isps; : > both of them strip this asn at their boundaries (remove-private-as)) : > in my lab before and it worked fine. it results in propagating routes to : > the same networks with two distinct as path attributes, though. i've been : > looking for any operational experience with this setup. so, do you claim : > that you couldn't detect *any* problems with this setup?
On Fri, Apr 07, 2000 at 10:18:22PM -0400, Brian Wallingford wrote:
This was a relatively attractive option several years ago, when bgp-capable routers were expensive enough to limit their practical availability to large-ish companies.
Considering the current pricing on proven BGP-capable routers (i.e., with careful prefix filtering, even a 26xx can take full routes from a few peers/upstreams), what's the point of this method now?
Conservation of AS numbers. However, looking at the CIDR report, there seem to be plenty of those left for now. IP addresses don't seem to be a problem for now either. So that leaves the real issue as routing table explosion - if a large number of enterprises decide they need to multihome to different AS's.
On Sat, Apr 08, 2000 at 11:46:40PM +0100, Brian Candler wrote:
On Fri, Apr 07, 2000 at 10:18:22PM -0400, Brian Wallingford wrote:
This was a relatively attractive option several years ago, when bgp-capable routers were expensive enough to limit their practical availability to large-ish companies.
Considering the current pricing on proven BGP-capable routers (i.e., with careful prefix filtering, even a 26xx can take full routes from a few peers/upstreams), what's the point of this method now?
Conservation of AS numbers. However, looking at the CIDR report, there seem to be plenty of those left for now. IP addresses don't seem to be a problem for now either.
But how does this apply if 20% of all (large or medium sized) companies start to multihome, which is what we see here ... /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work: Network manager @ AS3292 (Tele Danmark DataNetworks) Private: Geek @ AS2109 (A much smaller network ;-) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them.
At 21:04 07/04/00 -0400, Dmitri Krioukov wrote: The route object described in http://www.ripe.net/ripe/docs/ripe-189.html states that origin AS is a single occurence. RIPE-189 should then be updated to allow multiple occurences of the origin tag. -Hank
it does generate inconsistent origin as'es and it does break path filters, but not only. it breaks all the tools/methods based on the uniqueness of the route->origin-as mapping. i'm looking for a more or less complete list of these tools/methods.
it seems, though, that the inconsistent-as list is growing and this doesn't produce too much panic.
and if you examine this list more closely, you'll notice that it looks like the major part of it is generated by the isps doing the aforementioned trick. -- dima.
-----Original Message----- From: Greene, Dylan [mailto:DGreene@NaviSite.com] Sent: Friday, April 07, 2000 6:06 PM To: 'Dmitri Krioukov'; Jesper Skriver Cc: nanog@merit.edu Subject: RE: Policies: Routing a subset of another ISP's address block
Hey there..
I'd imagine this works fine, but doesn't it leave you w/ inconsistent-as, where you've got a prefix being advertised from the private ASN, stripped & replaced w/ each upstream ASN?
I mean, it should work, but is it a very good idea? The inconsistent-as list isn't _too_ big right now, which is good, as each one effectively breaks a number of common path filters. But if that starts to becomes common practice, the list gets bigger and bigger & more filters get broken.
..Dylan
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Jesper Skriver Sent: Friday, April 07, 2000 2:21 PM To: Daniel L. Golding Cc: David Harrison; nanog@merit.edu Subject: Re: Policies: Routing a subset of another ISP's address block
Actually I've helped quite a few such customers, my recommendation usually is to get PI space from RIPE, and get both providers to announce it from their ASN, this works quite well, and also save a ASN - if the customer really want to run BGP, we have arrangements with other ISP's here, that we find a private ASN (that none of us use currently), and assign this ASN to the customer, and we then strip the private ASN on the edges of our network.
this is interesting (since it overwrites the rule that multihoming to two isps requires a public asn assignment) and i've tested exactly this scenario (again, a customer uses some private asn and is peering with two isps; both of them strip this asn at their boundaries (remove-private-as)) in my lab before and it worked fine. it results in propagating routes to the same networks with two distinct as path attributes, though. i've been looking for any operational experience with this setup. so, do you claim that you couldn't detect *any* problems with this setup? -- dima.
On Sat, Apr 08, 2000 at 07:59:26PM +0200, Hank Nussbacher wrote:
At 21:04 07/04/00 -0400, Dmitri Krioukov wrote:
The route object described in http://www.ripe.net/ripe/docs/ripe-189.html states that origin AS is a single occurence. RIPE-189 should then be updated to allow multiple occurences of the origin tag.
Actually, some additions to that effect has allready been made: http://www.ripe.net/ripe/docs/ripe-189.html#sec:crossnot It doesn't specifically allow originating routes from more than one AS, but it does mention that this can be done in multihoming scenarions.
-Hank
/Niels Chr.
it does generate inconsistent origin as'es and it does break path filters, but not only. it breaks all the tools/methods based on the uniqueness of the route->origin-as mapping. i'm looking for a more or less complete list of these tools/methods.
it seems, though, that the inconsistent-as list is growing and this doesn't produce too much panic.
and if you examine this list more closely, you'll notice that it looks like the major part of it is generated by the isps doing the aforementioned trick. -- dima.
[...] -- Niels Christian Bank-Pedersen, NCB1-RIPE. Network Manager, Tele Danmark NET, IP-section. "Hey, are any of you guys out there actually *using* RFC 2549?"
Yes, but time when AS and AS path filters was widely used is (almost) over, so it does not produce a lot of headache (now the communities and prefix lists are used more and more to control routing, not AS-es). This routing broke some policies (because such specific prefixes can be rejected by some ISP and so the packet pathes are very sofisticated sometimes), but it's not too bad. The address space is much more important resource, than bandwidth, so any way to keep this space can be done in real (not theoretical) Internet. Btw, I know a few big ISP who does not use AS-path in their filters at all. And everything work. Yiu forget to mention possible routig loops (caused by such specific announces in rare cases), but I never saw it in practice. ----- Original Message ----- From: "Dmitri Krioukov" <dima@dimension.net> To: "Greene, Dylan" <DGreene@NaviSite.com>; "Jesper Skriver" <jesper@skriver.dk> Cc: <nanog@merit.edu> Sent: Friday, April 07, 2000 6:04 PM Subject: RE: Policies: Routing a subset of another ISP's address block
it does generate inconsistent origin as'es and it does break path filters, but not only. it breaks all the tools/methods based on the uniqueness of the route->origin-as mapping. i'm looking for a more or less complete list of these tools/methods.
it seems, though, that the inconsistent-as list is growing and this doesn't produce too much panic.
and if you examine this list more closely, you'll notice that it looks like the major part of it is generated by the isps doing the aforementioned trick. -- dima.
-----Original Message----- From: Greene, Dylan [mailto:DGreene@NaviSite.com] Sent: Friday, April 07, 2000 6:06 PM To: 'Dmitri Krioukov'; Jesper Skriver Cc: nanog@merit.edu Subject: RE: Policies: Routing a subset of another ISP's address block
Hey there..
I'd imagine this works fine, but doesn't it leave you w/ inconsistent-as, where you've got a prefix being advertised from the private ASN, stripped & replaced w/ each upstream ASN?
I mean, it should work, but is it a very good idea? The inconsistent-as list isn't _too_ big right now, which is good, as each one effectively breaks a number of common path filters. But if that starts to becomes common practice, the list gets bigger and bigger & more filters get broken.
..Dylan
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Jesper Skriver Sent: Friday, April 07, 2000 2:21 PM To: Daniel L. Golding Cc: David Harrison; nanog@merit.edu Subject: Re: Policies: Routing a subset of another ISP's address block
Actually I've helped quite a few such customers, my recommendation usually is to get PI space from RIPE, and get both providers to announce it from their ASN, this works quite well, and also save a ASN - if the customer really want to run BGP, we have arrangements with other ISP's here, that we find a private ASN (that none of us use currently), and assign this ASN to the customer, and we then strip the private ASN on the edges of our network.
this is interesting (since it overwrites the rule that multihoming to two isps requires a public asn assignment) and i've tested exactly this scenario (again, a customer uses some private asn and is peering with two isps; both of them strip this asn at their boundaries (remove-private-as)) in my lab before and it worked fine. it results in propagating routes to the same networks with two distinct as path attributes, though. i've been looking for any operational experience with this setup. so, do you claim that you couldn't detect *any* problems with this setup? -- dima.
participants (8)
-
Alexei Roudnev -
Brian Candler -
Brian Wallingford -
Dmitri Krioukov -
Greene, Dylan -
Hank Nussbacher -
Jesper Skriver -
Niels Chr. Bank-Pedersen