North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
The ol' upstream workaround [WAS:Policies: Routing a subset...]
- From: Brian Wallingford
- Date: Fri Apr 07 22:22:02 2000
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?