[sdnog] Quad9 node in Sudan :-)

Mon Sep 10 20:01:30 SAST 2018

Hi all,

On 10/09/2018 15:20, Reham Abdalla Ahmed wrote:
> 
> 
> Hello all,
> 
> As I know every ISP must have direct link with SIXP to route their
> traffic to other ISPs, in this case Sudren should have direct link
> with SIXP, Sudatel will not route other ISPs traffic to SIXP, only
> Sudatel traffic will be routed to SIXP , but other ISPs traffic
> through Sudatel will be routed directly to upstream provider.

Sudren may have a connection to SIXP. Traffic might be going over that 
connection. nice. But maybe tomorrow that connection might fail...

Sudren also has Sudatel to get traffic from _everywhere_, the whole 
internet to Sudren. Sudatel provides IP Transit to Sudren. Sudatel 
should try to get the traffic to Sudren as efficiently as possible.
Today, while Sudnre's connection to SIXP is working, traffic from MTN 
goes -> SIXP -> Sudren, and that is very good.
[Sudatel can not make that better]

Tomorrow when Sudren's link to SIXP fails, the traffic should still stay 
in Sudan or maybe even within Khartoum; traffic should cross as few 
networks as possible and travel as short a distance as possible.
If Sudatel advertises not just their own IP blocks, but also all of the 
ones it gets advertised from "customers", to SIXP, this can happen easily.

If a customer uses Sudaltel IPs or their own IPs (and advertises using 
BGP to Sudatel) does not matter very much. Sudatel should be thinking: 
"that's a customer, they want me to get packets from all over the world 
as efficiently as possible to the customer, let's advertise all of these 
IP blocks to all peerings, so that others (like MTN) can send the 
traffic the shortest way". [1]

For this Sudatel doesn't need to know whether Sudren is connected to the 
IXP. In any case it's best to advertise the reachability to SIXP.
However, if Sudatel know that Sudren have their own connecion to SIXP, 
then they would normally not expect any traffic from other SIXP peers to 
travel via Sudatel to Sudren -- because there's a better way: from SIXP 
directly to Sudren.

But Sudatel can and should be prepared for the day when Sudren's link 
fails (tomorrow).
And by just advertising Sudren's IPs to SIXP all the time (as long as 
Sudren is customer and the prefixes are learned dynamically via BGP), 
this is what Sudren and Sudatel engineers have to do when the Sudren 
link to SIXP fails:
- turn around
- continue sleeping

And indeed, I have heard that before from IXP peers. "we don't know and 
don't think that this customer wants us to advertise them at the IXP"
By default the customers want good service. That includes low latencies. 
And these get achieved when traffic is routed locally.

[1] to make it short, I often say:
everything you advertise to upstreams or any of your upstreams, you 
should advertise to your peerings (IXP connetion) as well. You're 
telling others to send you traffic for these destinations. Tell also the 
ones that can send traffic to you over your cheapest and fastest connection.

Greetings,
Frank

>> -----Original Message-----
> 
>> From: sdnog [mailto:sdnog-bounces at sdnog.sd] On Behalf Of Nishal
>> Goburdhan
> 
>> Sent: Monday, September 10, 2018 11:48 AM
> 
>> To: Sudan NOG
> 
>> Subject: Re: [sdnog] Quad9 node in Sudan :-)
> 
>> 
> 
>> 
> 
>> someone sent me this offlist.  the source asn in this case, is what
>> used to be the
> 
>> nren - sudren.  it looks like :
> 
>> # sudren aren't peering properly at the SIXP # the transit ISP (in
>> this case
> 
>> sudatel) aren't announcing these prefixes at the SIXP either
> 
>> 
> 
>> i'd be interested in knowing why this is happening in each case.
>> is there anyone
> 
>> with routing clue at sudren (and also sudatel) that can look into
>> this?  happy to
> 
>> talk (and help) off-list.
> 
>> 
> 
>> traceroute to 9.9.9.9 (9.9.9.9), 30 hops max, 60 byte packets
> 
>> 1  x.y (x.y) [AS37197]  1.544 ms  1.778 ms  1.697 ms
> 
>> 2  196.1.x.y (196.1.x.y) [AS15706]  1.884 ms  1.825 ms  2.032 ms
> 
>> 3  212.0.131.109 (212.0.131.109) [AS15706]  1.927 ms  1.911 ms
>> 2.030 ms
> 
>> 4  212.0.131.110 (212.0.131.110) [AS15706]  90.407 ms  89.754 ms
> 
>> 90.669 ms
> 
>> 5  host-81.10.87.65.tedata.net<http://tedata.net> (81.10.87.65)
>> [AS8452]  84.650 ms
> 
>> 84.795 ms  84.740 ms
> 
>> 6
>> pos0-8-2-0.palermo17.pal.seabone.net<http://pos0-8-2-0.palermo17.pal.seabone.net>
>> (195.22.197.68) [AS6762]
> 
>> 88.829 ms  88.991 ms  86.255 ms
> 
>> 7
>> ae23.franco31.fra.seabone.net<http://ae23.franco31.fra.seabone.net>
>> (195.22.211.48) [AS6762]  85.305 ms
> 
>> 88.182 ms  85.229 ms
> 
>> 8  de-cix.woodynet.net<http://de-cix.woodynet.net> (80.81.194.42)
>> [*]  147.322 ms  147.227 ms
> 
>> 147.921 ms
> 
>> 9  dns.quad9.net<http://dns.quad9.net> (9.9.9.9) [AS19281]  85.164
>> ms !X  85.051 ms !X
> 
>> 85.850 ms !X
> 
>> 
> 
>> -n.
> 
>> _______________________________________________
> 
>> sdnog mailing list
> 
>> sdnog at sdnog.sd<mailto:sdnog at sdnog.sd>
> 
>> https://lists.sdnog.sd/mailman/listinfo/sdnog
> _______________________________________________ sdnog mailing list 
> sdnog at sdnog.sd https://lists.sdnog.sd/mailman/listinfo/sdnog
> 