On 2014/10/07, 15:47, "Mark Tinka" <[email protected]> wrote:
>On Tuesday, October 07, 2014 03:27:39 PM Andrew (Andy) >Ashley wrote: > >> What would a ³proper² routing policy with relation to >> this scenario. Providing communities, etc? > >AS300 is filtering appropriately among peers. > >> The idea is to avoid international paths over AS200 >> ending up on the AS300 international backbone (since >> AS200 is also a transit customer of AS300). > >Well, typically, customers should not announce a full table >to their upstreams (nor should their upstreams be in a >position to accept them). Perhaps I phrased that incorrectly. AS200 is not announcing a full table to AS300. > >> AS100 does not want to see any international traffic via >> AS200 that transits AS300. >> Perhaps AS300 provides cheaper international transit to >> AS200 than the other upstreams, >> so AS200 preferences international traffic over AS300, >> which is not good for AS100¹s redundancy when AS300 has >> problems. AS100 has alternate domestic routes to AS300 >> via a domestic-only BGP session to AS200. > >Have both AS200 and AS300 mark "local" and "international" >routes with specific communities. Pass those communities on >to AS100 and ask them to perform inbound filtering >accordingly. Could be an option but I’m guessing that AS100 will then only have a partial table from AS200? > >For the reverse, AS200 and AS300 should provide AS100 with >communities that AS100 can use to control whether their >routes are announced to. That would be nice, but neither offers communities.. > >Mark. _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
