Cisco and Juniper both provide an option to easily strip private autonomous system numbers from outbound advertisements.
This article was started because I thought this aproach was flat out wrong; however during the research I managed to convince myself that it is the almost the right thing to do; just needs a couple of knobs to tweak to make it flexible enough to always do the right thing.
Public AS numbers are generally only available to organisations with public IP addresses and connectivity to the Internet via multiple providers. In an ISP network the only reason to carry routes with a private origin in the global routing table would be where a customer has some provider independent addresses and is multi-homed only to your network.
Ok, so we have our reason for the network eatering the table. What will happen if we just pass the network unchanged? Depending on the policies of your peers they will either drop the route at their boundary, causing lack of global reach for your customer, or they will pass it on, and it'll eventually be spotted, your network will be ridiculed, your peers will lose respect, your wife will run off with the circus and you'll be left broken and alone with nothing for company but a broken toaster. Don't do it. Burnt toast is bad.
We have a prefix originating from a private AS. It would be bad to pass that on to other peers. So what do we do?
A quick look at the documentation provides us with a contender: remove-private-as on cisco, remove private on Juniper. Both statements have the same effect: they strip private autonomous system numbers from outbound advertisements.
Brief interlude from RFC4271
5.1.2 AS_PATH
- When a given BGP speaker advertises the route to an internal peer, the advertising speaker SHALL NOT modify the AS_PATH attribute associated with the route.
- When a given BGP speaker advertises the route to an external peer, the advertising speaker updates the AS_PATH … [by] prepend[ing] its own AS number…
RFC4271 section 5.1.2 as I read it explicitly disallows modifying the as path when advertising to an ibgp peer; however there is nothing I could find in the standard that explicitly disallows such modifications when advertising to external peers. This gives the vendors the loophole they need.
The problem is that in order to set up a private as peer you need to configure all other peers to remove private as numbers. While this works, and seems to be the generally accepted RightThing™ to do, it just doesn't quite sit right with me; I like policy to be applied once at the entry to the network, not at every exit point.
Another problem comes when you have multiple private as peers.
The whole reason for storing the as path in BGP is to prevent loops (not as a distance vector, even if that is how implementations use it). The reason we are considering the implications of removing part of the as path in the first place is because the customer is multi-homed. Turning off a safeguard when you have exactly the topology it was designed to protect is a bad idea.
What about other private as peers? Remove-private doesn't allow fine tuning. If you allow one private as you allow them all, so if you have multiple customers connected and you advertise their private as numbers to each other you are violating the principals of keeping the numbers private. If one of the customers is using private as numbers internally then routes may get dropped due to non existant loops, and the support desk get calls due to connectivity problems. I admit it isn't likely, but its possible so will probably happen.
A route-map/policy would help:
router bgp 1234 neighbor 1.2.3.4 remote-as 65534 neighbor 1.2.3.4 remove-private-as route-map as65534-out ! ip as-path access-list 1 permit ^(6553[234])_ ! route-map as65534-out deny 10 match as-path 1 route-map as65534-out permit 20
Conclusions.
Peering with customers using private as numbers is a useful tool and has a number of valid applications, but starting it is like opening pandoras box. Be aware that you are operating in a grey area outside the standards. Here be dragons.