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
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
