[c-nsp] BGP route filtering question about upstreams
Andrew (Andy) Ashley
andrew.a at aware.co.th
Tue Oct 7 09:27:39 EDT 2014
Thanks for the reply Mark.
Answers below:
On 2014/10/07, 14:40, "Mark Tinka" <mark.tinka at seacom.mu> wrote:
>On Tuesday, October 07, 2014 01:47:42 PM Andrew (Andy)
>Ashley wrote:
>
>> AS100 does not want AS300 to learn its routes from AS200,
>> since that can cause redundancy issues (2 supposedly
>> diverse upstreams effectively become 1).
>
>Well, if AS100 is announcing consistently to both AS200 and
>AS300, and AS300 has a proper routing policy, this should
>not be an issue.
What would a ³proper² routing policy with relation to this scenario.
Providing communities, etc?
>
>Issues arise if AS100 is routing inconsistently, and/or if
>AS300 has a dodgy routing policy.
Assume that AS100 announces the same prefixes to both AS200 and AS300 and
that AS300 does not have a best practice routing policy.
>
>> AS100 still wants to receive a full table from AS200 (but
>> not routes that transit AS300).
>
>Routes that transit AS300 to/from where? AS100? AS300? The
>rest of the Internet?
Apologies, I should have clarified here:
AS200 operates both a domestic and an international BGP routing table.
AS300 operates a combined BGP routing table.
The scenario is concerned with international routing only.
AS200 should still provide routes to AS300 and its customers via the
domestic table.
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).
>
>> AS100 asks AS200 to filter its announcements to AS300.
>
>This is outbound routing toward AS300.
>
>> AS100 now still receives routes that are learned from
>> AS300 via AS200.
>
>This is inbound routing toward AS100.
>
>> 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?
>
>That's why I asked above - what routes does AS100 not want
>to see that transit AS300? AS100's own routes (own-AS-in
>would fix that anyway), AS300's own routes, or the rest of
>the Internet?
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.
Hope this clarifies things?
>
>Mark.
More information about the cisco-nsp
mailing list