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. Issues arise if AS100 is routing inconsistently, and/or if AS300 has a dodgy 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? > 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? Mark.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
