<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>
<div>Hi All,</div>
<div><br>
</div>
<div>(Apologies if this come through twice, I believe I accidentally posted from an unsubscribed address earlier)</div>
<div><br>
</div>
<div>I’m in a little bit of a rant mode in this post and openly admit it, but I’m getting REALLY frustrated and hoping someone here might have some advise on how to convince providers to actually do what is sane rather than what hurts them and hurts everyone
 else in the industry.</div>
<div><br>
</div>
<div>So, to describe the problem.</div>
<div><br>
</div>
<div>Certain providers in East Africa are announcing aggregate routes to exchange fabrics and then announcing de-aggregate routes to their transit providers who are not on the exchanges, do not peer, and have all their traffic going internationally.  </div>
<div><br>
</div>
<div>What happens in this scenario, the traffic never stays local, flows out internationally, switches through Europe and comes back on international links, increasing latency from what could be 3 or 4 milliseconds to an effective 300+ milliseconds. </div>
<div><br>
</div>
<div>In an even worse scenario, providers do this at exchanges where content engines such as GGC caches are hosted.  Those who are hosting the GGC caches and feeding the content to exchanges, then have the following happen:</div>
<div><br>
</div>
<div>The aggregates arrive via the exchange, get mapped onto the GGC’s, and the GGC’s attempt to send traffic back to the person announcing the aggregates.  Because the GGC host is carrying a full table on their routers, the routers then ignore the aggregates
 and use the de-aggregates and send the traffic out internationally and it comes back via Europe.  This <span style="font-weight: bold;">entirely</span> defeats the point of having localised content, drives up the costs and actually encourages the entity hosting
 the caches to stop feeding the content to the IXP in question. </div>
<div><br>
</div>
<div>Despite explaining the situation to the relevant providers, over and over again, and concretely demonstrating the negative effects of what they are doing, the only answer you get is “We aren’t changing, we do traffic control like that”</div>
<div><br>
</div>
<div>Now, that there is a solution, drop the entire AS number from the global table on the European transit ingress which will force the aggregates coming via the exchange to be used, but that seems to be a horrible solution, since an outage at the exchange
 then causes a complete blackhole to that ASN and drastically reduces redundancy.  But it seems also to be the only solution left when providers choose not to take the sensible option.</div>
<div><br>
</div>
<div>I’ve stood at many many AfriNIC and AFNOG events and heard us talk about keeping content on the continent local, its a song being sung constantly since 2005.  Now, we either want local content, or we want to continue to play routing games like the ones
 discussed above, but it cannot work both ways, the fundamentals of networking ensure this.  So as a last point, if anyone reading this is sending aggregates to an exchange and de-aggregates to their transit providers, please, this is one network engineer that
 is begging you to behaviour like a good net citizen and fix your routing!!!</div>
<div><br>
</div>
<div>Thanks</div>
<div><br>
</div>
<div>Andrew</div>
</div>
<div><br>
</div>
<br>
<hr>
<font face="Arial" color="Black" size="2">DISCLAIMER: This email contains proprietary information some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this email, please
 notify the author by replying to this email. If you are not the intended recipient, you must not use, disclose, copy, print, or rely on this email. We cannot accept liability for any statements made which are clearly the sender's own and not expressly made
 on behalf of this company or one of its agents.<br>
<br>
</font>
</body>
</html>