While I suspect the obvious outcome will be as you desire, there will however almost certainly be unintended consequences.
Customers need to form a transit AS internally to get routes to other locations within their organization. For example, pretend your customer has a public ASN 12345 on their internet edge routers. They learn (among other things) the default route from you, and need to propagate that to all the remote sites within their organization across their private MPLS L3VPN from a provider with ASN 65000. The remote site with ASN 65001, the MPLS VPN provider ASN65000, and so on will never learn routes you originate because of that community. The answer to this issue I have seen by other providers has usually been filtering by each respective ISP to prevent customers from accidentally becoming a transit AS. John -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Artyom Viklenko Sent: Monday, April 18, 2011 1:36 AM To: [email protected] Subject: [c-nsp] Non-transit customer AS and prefix leaks Hi, list! I had some problem last weekend. Lets say we - ISP-A, announce some prefixes to Customer. Due to some bug or misconfiguration these prefixes reached ISP-B (who provides another uplink to Customer). I'm was surprised that ISP-B received our prefixes from Customer (wrong filters?). And then, these prefixes was announced to Internet and some Exchange Points. This lead to incorrect routing of incoming thrafic towars our prefixes via slow Customer's links. This lead to near 100% packet loss. After several phone calls problem was fixed. But now, I'm trying to find some solution to prevent such problems in future. One solution I thinking of is to mark all announces to such non-transit Customers with no-export community. What do you guys think about this? Is it acceptable or not? Is it any other possible solutions to prevent such cases already in place? Thanks in advance! -- Sincerely yours, Artyom Viklenko. ------------------------------------------------------- [email protected] | http://www.aws-net.org.ua/~artem [email protected] | JID: [email protected] FreeBSD: The Power to Serve - http://www.freebsd.org _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
