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 is an end-customer stub AS, multi-homed to upstreams AS200 and AS300.
AS200 also buys transit from AS300, amongst others.
AS100 does not want AS300 to learn its routes from AS200, since that can
cause redundancy issues (2 supposedly diverse upstreams effectively become
1).
AS100 still wants to receive a full table from AS200 (but not routes that
transit AS300).
AS200 might have BGP communities you can use to tell them not to share
routes with AS300. If not, there's always as-path poisoning.
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?
Short of AS200 doing some pretty serious router separation games (i.e. not
going to happen just for one customer requesting it), they can't. A BGP
router can only share its best path for each route. If AS200's best paths
to certain prefixes are via AS300, and you don't want those routes from
AS200, you can't have AS200 send you their "second best" routes. Even if
that were an option, once you used those routes, how would you expect
AS200's router to "know" that you wanted them to use the 2nd best path
rather than their best path (via AS300)? This isn't really an issue,
since if you learn a route from AS200 and from AS300, and AS200's path is
via AS300, that will likely be your secondary path automatically due to
the longer as-path...unless you've applied other policy that forces a
different best path selection.
----------------------------------------------------------------------
Jon Lewis, MCP :) | I route
| therefore you are
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
