On 4 November 2015 at 16:23, Paul Thornton <[email protected]> wrote: > Your reasoning seems to be something like this: "I use AS 65530 internally, > therefore I never want to see 65530 in the AS path". Whilst I can see where > you're coming from, it doesn't [or more accurately, it shouldn't] hurt you > if I (say) announce some routes to you with 65530 in the path; it just gives > you a false view of things if you do a show ip bgp reg _65530_ - but > otherwise shouldn't break anything.
To clarify, there are multiple egress/ingress points to filter. Transit is just one of them and although I see what you are saying, I disagree. Actually if I have multiple upstreams and Upstream1 sends me a prefix with 65530 in the path and Upstream2 sends me the same prefix but they have a different route to that prefix without 65530 in the path, I want to prefer the path via Upstream2. It is less likely that I can guarantee the path via Upstream1 will work and be reliable. To be honest most operators aren't sending prefixes with private ASNs or reserved ASNs in the path so we are talking about a minority of the global table, when it comes to a transit feed. When someone does though, that often ends in them "fixing it" so the private ASN is removed eventually. It could be a minor error at the time of announcement, it could be a transient issue and the prefix was being announced without a private ASN in the path, then something went pop in transit ASN along the path and actually their internal backup path is looping traffic inserting extra hops and ASN path entries, then the pop'ed box is replaced the prefix goes back to "normal" (without a private AS in the path). It could be that somewhere a multihomed customer with a private ASN is taking a full table from two different upstreams rather than two default routes for better routing optimisation but they aren't announcing any IPs instead the upstreams are (from say an ISP built up from mergers, like say, the one I work for!). Then lets suppose that knob head customer or the knob head engineer that set up that knob head customer hasn't put proper prefix or AS filters in place and the knob head customer leaks the full table between upstreams. Whilst one might be happy for prefix N to be advertised between ASN1 and ASN2, not with CustomerASN in the path. Frame it how you like, we have scenarios when receiving a prefix even in the global table, not just from peers or customers or inter ASN links, can be less preferable when they have a private ASN in the path. I'm not the only PSN network operator on this list but just a couple of months ago a large UK telco were sending routes into the PSN originating from AS 65000, and they claimed they didn’t know who was doing it, even though it was tin fact hem, which caused a stir up to say the least. Just wanted someone to improve my regex and answer my question on the IANA reserved ASN ranges. Your business drivers, customer requirements and engineering prerogatives are not mine. Cheers, James.
