On 30 Oct 2015 18:27, "Nick Hilliard" <n...@foobar.org> wrote: > TBH, I'd question the value of filtering weird asns. What matters is > filtering out weird prefixes. If you filter out weird ASNs, all you're > doing is chewing up the CPU on your RP. > > Nick
ASNs that shouldn't be in the global table and prefixes that shouldn't be in the global table are two different things. Its a small step like BCP38 or bogon filtering that all providers can easily deploy (usually), inbound and outbound and it makes the global table just that little bit more of a better place. Just like prefix filtering some customer might get cut off, everyone makes mistakes, an operator somewhere might be announcing a customer via link IP as th next hope which might be an RFC1918 address. People do strange things, that's not my fault and in such scenarios the operator needs to fix that, it's not my responsibility. An effected customer can usually apply the relevant commercial pressure to get that sorted. On 31 Oct 2015 16:10, "Nick Hilliard" <n...@foobar.org> wrote: > > On 31/10/2015 08:19, James Bensley wrote: > > Six of one, half a dozen of the other > > wait now, step back a sec. > > On the internet, we care about reachability. Reachability is determined by > prefixes. So by inference we care about whether prefixes are legit or not, > for some definition of "legit". Read the rest of the sentence Nick, that statement was in relation to CPU resource availability. > The AS path is not much more than the distance vector metric for eBGP. The > only thing you're using the AS path for is to compare the network distance > across multiple upstreams/peers. > > If there's junk in the as path of one form or another - e.g. weird confed > stuff, private intermediate ASNs, upstream monopoly providers doing strange > things with customer ASNs, asn typos, as23456, etc - does this make a > meaningful statement about the legitimacy of the prefix? Yes. AS path filters are not just applied on the BGP sessions with my upstreams, but also our downstream customers. In addition we have private peers, we also planning to turn up some public peering in the near future. Rather more importantly though we currently operate 5 public ASNs and LIRs which are slowly being consolidated, with downstreams multi-homed across the multi-AS core. Internally we don't want any old ASN just flying around anywhere. > I'd say that > nuking reachability because an AS path is displeasing was a pretty > arbitrary approach to handling reachability hygiene because you have no way > of knowing why the AS path is like that and whether that actually means > anything. Right, I wasn't disputing the difference between a prefix and the AS-path of a prefix. I have tried to start a discussion around the filtering out of ASNs that I think should never be seen in the global routing table. I'm away with only my mobile so I'm not going to sift through the RFCs right now to check exactly to what extent the visibility of the exact ASNs I have specified in my original post should be, so at this moment in time I'm assuming "none".... Unless anyone can give a compelling reason as to why I should see those private and reserved ASNs in the global table, please let me know. > Bear in mind that the leaf ASN loses control of the as path the moment they > announce their prefix to their peers / upstreams. Their upstream has full > control to update / insert / delete anything in there that they please. > > I've been at the receiving end of monopoly upstreams doing crazybad dumb > stuff with as paths and it's not pretty. It doesn't reflect badly on the > legitimacy of the prefix in any way - it's merely a statement that the > intermediate network is clueless, but was in the circumstances the only > thing which stopped the leaf network from going completely dark for days at > a time. > > If you're going to do this, I'd suggest you measure what prefixes you're > cutting out first and try to make some judgement about whether they are > legitimate from some other point of view. Agreed, I'm not the kind of person to (essentially) just cut off part of my customer's view of the Internet which they are paying for without being sure it's a reasonable action. > Maybe it's not going to matter a > whole lot, but I'd suspect that you're fixing the wrong problem in terms of > tackling prefix origination legitimacy, and in some - perhaps many - cases, > you're going to end up punishing leaf networks for third party stupidity > which they cannot control. > > This is apart from ruining your convergence completion time. > > Nick No I'm very sure of what I want: I don't want any prefixes coming in to my network with the ASNs I specified in my origin email from outside of my network, because those ASNs are inuse internally. It's as simple as that. The same reason you filter 10.0.0.0/8, the fact it's in RFC1918 doesn't bother me, if I wasn't using it internally and only gave customers a default route I wouldn't give a shit about receiving it to be honest, it wouldn't impact me or my customers then. Right now I am like any ISP using many ASNs internally and my customers are taking full table views, so thanks for the side track on some upstream somewhere being a cunt and ruining some poor sod's access for a few days, I've got customers I need to please, I don't need them banging on at me because they receive prefixes with a private ASN in the path. James.
