AW: Traffic engineering and peering for CDNs

Mon Jun 6 17:56:07 UTC 2016

Hi Graham!

In addition to the other two comments, I´d like to add some topics:

> Lately I have been putting in some effort to maximize our IX connections
by 
> trying to work with the top 5-ish list of ASNs that still send us traffic
via a paid 
> transit connection despite the fact that we are both present on the same
IX(s). 
> In one case I missed the fact that one ASN wasn't using the IXs
route-servers, 
> that's on me for not spotting that one.

This brings up some ideas ... see here:

1) Check if the CDN is on the routeserver
2) Check if the CDN has maybe tagged his prefixes with a "do-not-announce"
tag (verify at looking glass) (relevant of course only for outbound traffic)
3) Try to establish a direct peering session with the CDN over the IXP so
that you are known to the CDN 
   ... some CDN´s could maybe also prefer or have higher priority on direct
sessions than via only routeserver...
   ... quite some networks give you a larger set of prefixes on a direct
session...
4) Talk with the CDN and check his geolocation tagging's for your prefixes
and maybe let correct them after you have found out what they are doing
5) Think on the fact, that CDN´s could take their routing decision on the
geo-location of the used dns resolver server and not on the users ip address
6) Check, that your network or your customers are not referring to public
dns resolvers
7) Think on the fact, that ipv6 could maybe be in place and active too ...
so don´t forget your ipv6 path and ipv6 dns resolvers...
8) Check your RADB/RIPE/AFRINIC/... routing db entries - if you did
something wrong, maybe you are filtered... (check:
http://irrexplorer.nlnog.net/ and looking glasses)
9) Check that you have your set of IP prefixes in good order and do not
implement strange magic with asymmetric more specifics ... reduce everything
to supernetworks on all edges!
10) Check if you are not handing over bgp tagging's which could cause some
prevention automatics and check if 
   you do not send high metric values which are maybe causing negative
routing decisions on the other side
11) Think on the fact, that CDN´s have the geographic distance as one of
their parameters - if the CDN node is too 
   far away from your network - maybe a closer located content box via
transit is rated higher than maybe the long 
   distance via peering (if there is no node or no node with the right
content next to you) ... typically CDN are very close to larger IXP´s...
12) Think on the fact, that your ip-transit upstream could be a peering for
the CDN ... This neutralizes the peering or transit rating
   from the point of view of the CDN, but of course not for you ... so: talk
with the CDN ... therefore you must be known ... 
   therefore, you should have done a peering session ...
13) Talk with your IXP ... maybe he can help ...

Anything missing here? Anything wrong with my ideas?

(disclaimer: yes, I do work for an IXP ... but this is my personal opinion)

happy peering...
Bernd

Bernd Spiess (Manager Peering Service / DE-CIX Management GmbH)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5411 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20160606/54b4344f/attachment.bin>