Some leaks in China/Hongkong

[Thomas Schmid]

Hi Gert,

Gert Doering wrote:
> Hi,
> 
> On Tue, Oct 28, 2008 at 05:11:29PM +0100, Thomas Schmid wrote:
>>> It's much worse.  At least DFN *has* a full view, but they prefer Geant2
>>> routes, because "NREN stuff needs to go there".
>> that's right and this is badly needed today and in the future. We don't want
>> to send any NREN traffic via unknown peering paths alone because this
>> affects mutltiple Gigs of traffic and might flood quite some links.
> 
> So you're sending *non*-NREN traffic over scenic paths round the world?
> 

we're not talking about normal traffic here, but about a leak that took
place via a university in Hong Kong. So no, we're not sending traffic
intentionally via the scenic path.

Additionally, the topic GBLX IPv6 upstream was discussed here before -
and we had to shut the BGP session more than once because of problems there -
The other IPv6 upstream is under way, but initial implementation failed with
technical problems. My feeling is that Geant v6-upstream
is not causing more trouble than the other ones. This is a general problem
with IPv6 routing worldwide.

> Some time in the last century, we did local-pref our DECIX-peers, because
> "peering is cool, upstream is expensive".  Shortly afterwards, we were
> seeing a path with some 10 AS hops over peering, while transit would 
> have been 3 AS hops, and much better bandwidth.  Guess where our packets
> went...
> 
> Since then we've stuck to "AS-Path lenght is a useful metric, MED will
> be taken into account, and local-pref will only be used in well-defined(!)
> exceptions".
> 

we're as NRN in a different situation as mentioned. Look at the
GN2+NRN cloud as some sort of loose corporate network.

> Just local-prefing anything that comes via a NREN link does not sound
> very well-defined, so this is guaranteed to cause issues again and again.
> 

this is based on BGP communities that in this case did not match the actual
policy that was announced in these prefixes. The community set was 20965:11537
and translates into 'Routes received from Abilene'. I somehow have to rely
on the fact that the tagging reflects the nature of the routes.

> [..]
>> I don't see an easy solution for the time being. So manual reaction on people
>> complaining is currently the only way to deal with the problem.
> 
> You're currently using the reactive approach "local-pref everything, 
> maintain (negative) exception lists".  Our experience has been that 
> "local-pref nothing, maintain (positive) exception lists" is usually 
> causing much less pain to our customers.
> 

the exception list is generated by presence or absence of certain BGP communities.

> But then, our definition of "happy packets" is "fast delivery" - other
> people might consider a scenic world tour a nice way to make happy
> packets...
> 

I assume you forgot a smiley here?

> 
> To be a bit more constructive: you could maintain a list of AS numbers
> that belong to known research networks and should be reached via Geant2,
> and local-pref these.  Anything else coming in via Geant2 should not be 
> local-prefed (don't necessarily *drop*, even if that might be prudent given
> some of the crap I2 is leaking, but at least do not *force*) - which would 
> avoid routing Google traffic to Hongkong, instead of Amsterdam.
>

again, the current tool used for this is BGP communties. The list is very
dynamic with the constant world wide extension of the Geant2-interconnections.
We must rely on the correct tagging of the routes. You can not prevent
leaks with this, but a static list is *not* a scalable solution. Is RADB
a solution? In theory yes, in praxis no.

> 
> We're trying to convince content providers that they should publish
> AAAA records - and e.g. google rightly says "as long as people's routing 
> is so f****ed up, publishing AAAA records is going to hurt our users".
> 

tell this to the people in Hong Kong. Again - the routing is f****d up
not because some local pref was used somewhere, but because people in the world
don't care about routing-policies in IPv6 as much as they do in IPv4.

But to settle the issue: we took the pragmatic approach and removed the local pref
setting for some IPv6 paths. This contradicts the approach of
treating v4 and v6 the same, but pays tribute to the fact that the v6
routing is still not ripe for equal treatment as v4. Also, this will only stay
in place until v6 traffic reaches Gbit level or people start complaining
about suboptimal (i.e. non-GN2) v6-routing to asian NRNs.

Best regards,

   Thomas