bad routing

[Robert J. Rockell]

Forewarning: if you are going to be offended by seeing your own AS in this
mail, do not read any further.


I will use my own example, so as to not affend anyone, but I did want to
mention something more regarding Ivano's mail about poorly aggregated
prefixes.  Please consider the following excerpt from yesterday's report:

 SPRINT (3ffe:2900::/24) had 10 route(s)
    3ffe:2900:1::18/126 path 1225 1849 5539 4556 ( -- 100%)
    3ffe:2900:c:8::/64 path 2839 1103 786 1849 1225 4556 ( -- 100%)
    3ffe:29a1::/64 path 1225 1103 786 1849 3251 1930 1251 4270 11008
    3ffe:2900:1::/64 path 2839 1103 786 1849 1225 4556 ( -- 100%)
    3ffe:2900:ffe3::/48 path 1225 1103 1200 8251 8731 8319 6175 7838 (USAA
    3ffe:2900:5::/48 path 1225 1312 (LORE/VT -- 100%)
    3ffe:29a1:c::/48 path 1225 1103 786 1849 3251 1930 1251 4270 11008
    3ffe:2900:c005::/48 path 1225 1103 1200 8251 8731 8319 6175 11017 ( --
    3ffe:2900:9::/48 path 1225 1103 1200 8251 8731 8319 6175 71 (HP -- 93%)
    3ffe:29a2::/32 path 1225 1103 1200 8251 8731 8319 6175 11261 (ASCI --

Looking at these, one may think "wow, Sprint sure is bad at aggregating it's
prefixes".  However, if you look at this, one can see that SPrint's ASN
(6175) is only in four of these BAD routes' AS path.
 
3ffe:29a2::/32
3ffe:2900:9::/48
3ffe:2900:c005::/48
3ffe:2900:ffe3::/48 


Now, as these do have Sprint in the AS path, we can see that the next AS in
the path is both accepting these routes, and propogating them back up. AS
8319 is a peer of Sprint, and Sprint is sending more specifics, and breaking
aggregation rules.

This has been fixed. However one may argue that AS8319 could filter more
specifics from sprint, and help to alleviate this problem. I have adjusted
my outbound filters to compensate.  SPRINT is at fault, but the upstream who
allowed them shares blame (AS8319).

The theory that filtering is bad because it does not show bugs in your
system is no longer valid. If your IPv6 node is a single router, then you
shoudl not be a pTLA, but a leaf node. One's internal network should suffice
to test implementations. This way, it does not affect the rest of us.

Every other route in this case does not even have Sprint in the AS path,
which means someone else (usually the Sprint downstream) is leaking the route
back up to their other upstreams.

We have been trying to curtail this since orlando IETF.   

It is the fault of the upstream provider to allow these announcements out,a
nd the fault of EVERY PTLA in the AS path to allow these prefixes to be
transitted. If you cannot filter, then give back your pTLA please.  This is a
testbed, but this is not a lab.   You affect others when you break
aggregation.  I will be glad to give you a transit connection, and some IPv6
space to play.


I will be contacting each of my downstreams who are leaking bad routes, and
helping to get this fixed. If you have a lot of customers, please do the
same. People who are on the bad rotuing report more than usually are not to
blaim for most of the  bad rotues. It is their downstream customers other
providers who have the problem. 

MERIT: Woudl it be possible to jog this report to start blaiming the AS who
is at fault, rather than the pTLA who cannot fix it?


The worst offenders:

AS 4555
AS 7680
AS 11008
AS 2852

IF you have these customers as direct downsteams, please filter them, for
the sake of the rest of us.  

Bob, perhaps we need to start actively policing this. I can see people on
the bad routing report who have been there since I first heard of IPv6, and
still refuse to filter. I will begin to take action on my pTLA. I encourage
the rest of you to do so as well. Write to me personally if you do not nkow
how/what to filter, and I can point you somewhere to learn.












Thanks
Rob Rockell
Sprintlink Internet Service Center
Operations Engineering
703-689-6322
1-800-724-3329, PIN 385-8833
Ines|e gnyne qh vagr bz s|e Ino ngg una {e hgr bpu plxyne?