[c-nsp] BGP route filtering question about upstreams

[Justin M. Streiner]

On Tue, 7 Oct 2014, Andrew (Andy) Ashley wrote:

> I¹m hoping someone can provide a bit of insight here with a BGP route
> filtering scenario:
>
> AS100 does not want AS300 to learn its routes from AS200, since that can
> cause redundancy issues (2 supposedly diverse upstreams effectively become
> 1).

It's really not necessary to do this, and trying to force providers to 
not learn routes for AS100 from each other can make outages more 
difficult and recovery more painful.  Better to let BGP do what it does 
in a relatively unfettered way.  Some providers might offer BGP 
communities that customers can set on their outbound announcements, to do 
something like "AS300, prepend what I announce to you, when you announce 
it to AS200".  The capabilities of these offerings will vary widely from 
provider to provider.

> AS100 still wants to receive a full table from AS200 (but not routes that
> transit AS300).

Better to receive a full feed and the customer can drop or de-prefer 
routes that have [ 200 300 ] (or however make occurrences you want to look 
for) in the AS path from their own routing table, rather than trying to 
get the providers to do it.  Note that the mechanics of looking for said 
routes will vary significantly from vendor to vendor.

> It should be possible for AS200 to tag prefixes learned from AS300 at
> ingress, then implement a policy to filter these tagged prefixes on outbound
> announcements to AS100.
> But, how can AS100 still receive a full table from AS200 with such filtering
> in place?

Don't make the routing policies any more complicated than they need to be, 
especially if someone who is less familiar with them will be expected to 
troubleshoot connectivity issues at 3 AM.

jms