[c-nsp] Non-transit customer AS and prefix leaks

cisconsp at SecureObscure.com cisconsp at SecureObscure.com
Mon Apr 18 03:53:41 EDT 2011


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: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Artyom Viklenko
Sent: Monday, April 18, 2011 1:36 AM
To: cisco-nsp at puck.nether.net
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.
-------------------------------------------------------
artem at aws-net.org.ua | http://www.aws-net.org.ua/~artem
artem at viklenko.net   | JID: artem at jabber.aws-net.org.ua
FreeBSD: The Power to Serve   -  http://www.freebsd.org
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/



More information about the cisco-nsp mailing list