On 4 November 2015 at 11:16, Mark Tinka <mark.ti...@seacom.mu> wrote:
>
>
> On 4/Nov/15 10:42, James Bensley wrote:
>
>
> Are you suggesting that people shouldn't filter as-paths? Presumably you
> wouldn't be that stupid so I'll assume not,...
>
>
> Well, the end goal is filtering of prefixes.

No, prefix filters are the end goal if you want to filter certain
prefixes from certain peers. AS_PATH filters are for filtering between
multiple paths to the same prefix.

> AS_PATH filters, like BGP communities, are just a way to identify those
> prefixes in the first place.
>
> We, for example, use standard prefix lists for peering and transit sessions.
> That cuts out a lot of junk. If we use AS_PATH filters, is to do traffic
> engineering mostly, and not to drop routes.
>
> On the other hand, we do use both prefix + AS_PATH filters when activating
> downstream customers as a standard rule. This avoids Pakistan/PCCW/Youtube
> issues, as you know.

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).

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.

> In your peering and transit prefix lists, include your own prefixes as a
> reject. Don't need an AS_PATH filter for that...

Yes this goes without saying and as per Will's comment, you next-hop
ranges and peering/IXP ranges for example.

"Edge" fltering happens all the way up and down the stack, on your
transit links you might filter incoming prefixes, set the BGP
community to 0/erase any values, as_path filters, you probably set
DSCP to 0 and/or cos to 0, 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.

Cheers,
James.

Reply via email to