On 10/Nov/15 15:55, James Bensley wrote:
> No, prefix filters are the end goal... Not always. In some cases, using other methods to identify prefixes for filtering - other than prefix lists - can be desirable. > if you want to filter certain > prefixes from certain peers. AS_PATH filters are for filtering between > multiple paths to the same prefix. There are no hard and fast rules, in my experience. Different situations that are unique to your own operation will determine what you choose go with. For me, ultimately, identifying the prefixes is the end game. How you do that (prefix lists, AS_PATH filters or communities, or a combination) is a very specific choice that we cannot easily generalize. > > Bingo! > > We have multiple paths to the same destinations. The AS path regex I > originally posted was for ASNs in RFCs and reserved by IANA that we > are "allowed" to use internally and wondered if anyone could improve > on that (thanks go to Leo & Job, the only people that actually offered > any input on the orginal questions I posed). You probably did not get feedback from most because many networks just filter reserved prefixes directly. Personally, we don't filter reserved ASN's per se, on inbound. We do, however, drop private ASN's on all eBGP sessions as a standard rule. > > However additionally we have mutliple public ASNs and with multiple > paths between them, many downstream ASNs, private peers and soon > public peering, and thousands of private ASNs in use. And again, lots > of resiliant paths, lots of places CustomerA who is multiomed across > different ASNs can nicely bugger their router configs, I don't want to > learn any prefixes in ASN1 from CustomerAS1 over the linkes between > ASN1 and ASN2 only from the direct CustomerAS1 link to ASN1. Blah blah > blah. You know your network better than I do, so I'd trust you to employ the strategy that best meets your needs. > > Yes this goes without saying and as per Will's comment, you next-hop > ranges and peering/IXP ranges for example. We don't use external IP addresses as next-hop destinations internally. NEXT_HOP=self is used in my network. > > "Edge" fltering happens all the way up and down the stack, on your > transit links you might filter incoming prefixes,... Yes, but mostly throwing the "bad" stuff + our own prefixes away. On peering links, a combination of this + max-prefix, and as AS+PATH list for a very special internal reason that might be unique to us. > set the BGP > community to 0/erase any values,... Yes, set communities to a non-zero value. This implicitly overwrites what is arriving with the route. At the edge, though, we may not necessarily overwrite what is arriving with the route, as long as it is not an internally-used community. > as_path filters,... Not really on transit links. Yes on peering links, but for a very special purpose that may not be commonly practised. > you probably set > DSCP to 0 and/or cos to 0, Yes - but I've also noticed it is useful to set this on outbound traffic leaving your AS. > you might have edge filters to drop TCP & > UDP traffic to your infrastructure IP ranges blah blah blah - just > trying to improve this one item at the moment though. Everything small bit helps. Mark.
