v6 routing pessimism

[Daniel Roesen]

On Wed, May 18, 2005 at 04:31:29PM +0100, Nick Hilliard wrote:
> And before anyone starts pointing the finger at the immediate upstream
> (AS2110), this goes well beyond any misconfiguration they might have.

What you see is the result of multiple problems. 2110 is NOT to blame
here.

> The AS path is a hilarious "2110 3549 11537 17579 1237 17832 24136 109
> 109 6939 3257 3333" - ouch!

Problem 1 is, that www.ripe.net is inside route 2001:610:240::/42
which is being filtered in many places. As such, your AS_PATHs do
become worse-than-ideal automatically. GBLX seems to have only(?)
Abilene as source for this /42 (they could peer with RIPE directly
at AMSIX though). Looking at the GRH looking glass at
http://www.sixxs.net/tools/grh/lg/?prefix=2001:610:240::/42, it shows
nicely that the propagation of the /42 is quite limited due to
filtering, but most that DO have a route to the /42, have a "good"
path. The exception is the "leak" via 3257=>6939=>109=>24136 which I
describe later...

Then you're seeing the problem that Abilene is... hm.. confused.
Policy of all those NREN networks is that they don't transit traffic
from ISPs to other ISPs thru them (which makes sense). Unfortunately,
both "up"streams of Abilene (KREONET2 [17579] and APAN) don't tag
their routes, thus Abilene can't easily distinguish "commercial"
from "noncommercial" routes. So, for Abilene, all routes received
from KREONET2 and APAN are "noncommercial" routes, as they are
received from NRENs - and thus get reannounced to GBLX.

Third problem is, that Abilene seems to only provide FULL table to
peers @ PAIX-PA and then leave it up to the peers to filter away
what they don't want. So effectively, there is little policy enforcement
going on.

Fourth problem (not seen here) is that Abilene also reannounces all
routes received from commercial ISP peers @ PAIX-PA to everbuddy else.
So we have the ISP<->Abilene<->ISP transit problem in both directions.

Now, even if Abilene and KREONET[2] would sort out their routing policy,
things would still be bad.

Take a look at the AS_PATH in reverse order:

3333 3257 6939 109 24136 17832 1237 17579 ...

RIPE peers with Tiscali (3257), and Tiscali engages in some kind of
route swap with 6939 (HE.net), so provides full/partial transit to HE.
HE.net seems to swap full table with 109 (Cisco), and those with 24136
(SIXNGIX - probably some kind of L3 IXP in Korea).

End result is, that the RIPE route could only take such a path due to
multiple problems with multiple operators having a questionable
routing policy.

Cisco stopping to play tunnel transit left-and-right around the world
would be a first good step to help preventing those kind of things to
happen. :-)

Another good idea would be for Abilene to stop sending routes received
from commercial peers to APAN/KREONET2. When they're at it, they can
also stop reannouncing routes received from ISPs at PAIX-PA back to
ISP peers @ PAIX-PA. :-) And finally, Abilene should send only their
own routes (Abilene's /32 and the connected universities, GigaPOPs,
research/defense networks etc.) to ISP peers instead of sending a full
table and relying on the ISP to sort it out with inbound filters.
The ISPs have a hard time manually filtering that and Abilene's
communities don't really help there too much last time I checked.


Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0