|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical The ol' upstream workaround [WAS:Policies: Routing a subset...]
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?
|