[c-nsp] BGP route filtering question about upstreams

[Andrew (Andy) Ashley]

On 2014/10/07, 15:47, "Mark Tinka" <mark.tinka at seacom.mu> 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.