Budovani AnycastDNS – 2. cast

Minule jsem se rozepsal co to vubec AnycastDNS je, a ze bohuzel idealni laboratorni svet BGP routingu v realnem svete nefunguje. Je tedy nutne se venovat optimalizaci BGP tras. V tomhle clanku sepisu nastroje, ktere me pomahaji spatne trasy vyhledavat a monitorovat.

Vlastni data

Nejdulezitejsi a nejlevnejsi zjisteni problemu je analyza vlastnich dat. My v nasem DNS software generujeme CSV logy, ktere nasledne konvertujem do ElasticSearch (jde o desitky milionu dat denne). Z ES pak jednoduse muzem generovat ruzne statistiky, grafy, atd.

Obrazek 1: Priklad node v Izraeli ktery obsluhuje pouze IL a PS (US je spatne GEO urceni jine Anycast sluzby – vetsinou Google CDN). 

Obrazek 2: Priklad node v Tanzanii ktery obsluhuje TZ a idealni okoli. Nestahuje zbytecne daleky trafik. Idealni node

Obrazek 3: Priklad node v Chile u ISP ktery ma velmi silny peering. Takovy node pak stahuje provoz z velkych dalek. Zde je to napriklad Spanelsko, Francie, Novy Zealand, a to je opravdu nezadouci.

Z vlastnich statistik z jednotlivych nodu tedy muzeme urcit ktere nody nam stahuji provoz odjinud, a podle toho se pokusit udelat nejaky upravy v nastaveni. Bohuzel je to casto ale jen otazka do pranice, nebot na cilovem node netusime pres jakou cestu se zakaznik dostal na nas server. Traceroute od nas k nemu totiz povede na 99,9% zcela jinou cestou 🙁

Sluzby tretich stran – RIPE Atlas

RIPE Atlas je naprosto bozi nastroj. Nachazi se na adrese https://atlas.ripe.net a pochazi od RIPE, coz je organizace ktera ma mimo jine na starosti rozdelovani IP rozsahu pro Evropu.

RIPE Atlas je nastroj urceny pro LIRy (tedy spravce nejakych sitovych bloku) a laicky popsano umoznuje poslat ruzne prikazy: traceroute, dig, bgp, .. na tkzv. proby, kterych ma vice nez 10 tisic po celem svete a ziskat tak odpoved. Idealne lze tedy pak napriklad vybrat proby napriklad z Mexika, poslat jim prikaz na provedeni DNS dotazu na nasi diagnostickou domenu a z vysledku ktery obsahuje odpoved DNS serveru a cas potrebny pro ziskani odpovedi lze provest diagnozu, kde takovy provoz konci a jak dlouho trva. Pote u tech co jsou spatne lze na ty same proby zaslat dotaz na traceroute, ktery ukaze kudy packet presne tece abychom mohli udelat nejaky upravy v konfiguraci.

RIPE Atlas je a neni zdarma. Za kazdy dotaz/odpoved na sondu (probe) se plati kreditem. Kazdy LIR ma k dispozici 1.000.000 kreditu mesicne na vyuzivani. Bohuzel pro nejakou komplexni dlouhodobou world-wide statistiku tento pocet nestaci, a vyssi pocet lze ziskat bud hostovanim sondy ve vlastni siti, nebo sponzorskym prispevkem, coz oboji sluzbu znacne prodrazuje.

Sluzby tretich stran – PerfOps

Kdysi jsem domluvil zalistovani na verejne sluzbe monitoringu Anycast DNS a CDN poskytovatelu – https://dnsperf.com Tahle sluzba je produktem vetsi sluzby a to perfops.net, kde lze detailne monitorovat jednotlive sluzby a vyuzit nastroje pro poslani ping/traceroute/DNS/curl na jejich jednotlive merici nody kterych je pres 200 a ziskat pozadovany vysledek. A to cele s podporou REST API. Sluzba je nicmene placena a ne zrovna nejlevnejsi (stovky USD mesicne).

Nicmene jejich graf realtime latence Anycast DNS z ruznych zemi sveta nema chybu:

Na grafu vidim ze napriklad velky problem dela latence v Paname. Nicmene nevim proc. Diky jejich Net Utils si mohu vygenerovat nas diagnosticky dig vuci jejich nodum v Dansku:

Nas diagnosticky prikaz je: dig @185.28.194.194 txt hostname.anycastdns.cz (nebot nase DNS servery jsou nakonfigurovane tak aby pro hostname.anycastdns.cz vratili TXT zaznam s lokalitou)

Z vysledku vidime ze jeden jejich nod konci v Nemecku a dva v Jihoafricke Republice, coz je samozrejme spatne.

Diky nastroji Traceroute mohu ziskat detaily:

Jeden node se dostal pres svyho ISP do Frankfurtu kde mame bod DE3. Zbyle dva nody se dostali do AMS-IXu kde ma ISP zrejme peering se Seabone ktery nam to poslal natvrdo do Afriky. Takze opet neco spatne, kdyz mame pritom nejblizsi bod primo v Amsterdamu.

Sluzby tretich stran – RING NLNOG

Sluzba RING od NLNOGu (https://ring.nlnog.net) je uplne jina jak ty dve predchozi. Sluzba je zcela zdarma a jeji podstata vychazi ze vzajemneho sdileni. Pokud jste sitovi spravci s BGP, mate vlastni ASN a prostory kde muzete pripravit VPS ktere nasdilite ostatnim, muzete se stat clenem/participantem a vyuzivat sluzby komunity. V praxi to pak znamena, ze muzete vyuzit pristup na vice nez 500 VPS napric svetem u vsemoznych ISP s moznosti poustet diagnosticke nastroje jako je ping, telnet, dig, traceroute, curl, atd … Skupina lidi kolem RINGu pripravila i aplikace pro hromadne volani prikazu z vlastniho serveru, aby se clovek nemusel rucne logovat vsude.

Seznam zapojenych ISP je zde: https://ring.nlnog.net/participants/

Pro hromadnou praci s takovym mnozstvim VPS se mi vyplatilo vytvorit si vlastni GO aplikaci, ktera se mi paralelne pripoji na vsechny VPS a posle pozadovany diagnosticky prikaz (dig viz vyse). Pote mi rovnou vyhodi result, se kterym dale pracuji.

Nezpracovany vystup vypada takhle nejak podobne:

cloudvps02|nl2.anycastdns.cz|2
gransy01|cz2.anycastdns.cz|5
web2objects01|ru1.anycastdns.cz|39
intermax01|nl2.anycastdns.cz|2
cyso01|nl2.anycastdns.cz|1
bit01|bg1.anycastdns.cz|32
ripe01|nl2.anycastdns.cz|6
duocast01|nl2.anycastdns.cz|4
syseleven02|bg1.anycastdns.cz|33
belwue01|bg1.anycastdns.cz|28
vmhaus01|uk1.anycastdns.cz|0
plusline01|bg1.anycastdns.cz|34
cesnet01|cz2.anycastdns.cz|6
celya01|fr1.anycastdns.cz|5
sernet01|bg1.anycastdns.cz|33
denic01|cz1.anycastdns.cz|8
simplytransit01|uk1.anycastdns.cz|2
noris01|bg1.anycastdns.cz|27
tdc01|de3.anycastdns.cz|18
fusix01|cz2.anycastdns.cz|26
syseleven01|bg1.anycastdns.cz|37
cloudbear01|nl2.anycastdns.cz|2
amazon14|uk1.anycastdns.cz|1
rootnl01|nl2.anycastdns.cz|4
nynex01|bg1.anycastdns.cz|34
kudelski01|ae1.anycastdns.cz|123
boxed-it01|bg1.anycastdns.cz|38
kit01|bg1.anycastdns.cz|37
amazon09|bg1.anycastdns.cz|33
dreamhack01|ru1.anycastdns.cz|11

Po zpracovani pak vidim, ze napriklad bod kudelski01 ktery je fyzicky umisten ve Svycarsku (Zurich) ma latenci na ns1.anycastdns.cz nejakych 123ms a to protoze se dotazuje serveru v Arabskych Emiratech … boze proc ? Jednoduchym poslanim dotazu na traceroute hned zjistime odpoved:

traceroute to 185.28.194.194 (185.28.194.194), 30 hops max, 60 byte packets
1 185.35.62.1 (185.35.62.1) 0.601 ms 0.589 ms 0.576 ms
2 v1244.core1.zrh3.he.net (216.66.93.149) 6.014 ms 6.017 ms 0.825 ms
3 100ge8-1.core1.zrh2.he.net (72.52.92.129) 0.719 ms 0.622 ms 0.607 ms
4 100ge15-1.core1.fra1.he.net (184.105.65.30) 6.188 ms 6.201 ms 6.185 ms
5 peer1.fra1.flagtel.com (80.81.192.64) 6.809 ms 6.731 ms 6.711 ms
6 xe-8-3-0.0.cjr04.prs001.flagtel.com (85.95.27.34) 21.673 ms xe-2-1-1.0.cjr04.prs001.flagtel.com (62.216.128.13) 22.570 ms 22.557 ms
7 xe-11-1-1.0.pjr04.dxb001.flagtel.com (85.95.25.162) 126.706 ms xe-0-0-1.0.pjr04.dxb001.flagtel.com (85.95.25.94) 126.572 ms 126.575 ms
8 62.216.144.122 (62.216.144.122) 127.577 ms 127.607 ms 128.122 ms
9 * * *
10 * * *
11 94.205.255.29 (94.205.255.29) 134.672 ms 134.690 ms 134.628 ms
12 po7-179.bg1.dx1.datamena.ae (94.207.32.73) 145.540 ms 145.492 ms 145.582 ms
13 oobfw1-dxb1-dx.uae-ix.net (94.207.34.34) 125.633 ms 125.574 ms 125.588 ms
14 188.172.255.32 (188.172.255.32) 122.049 ms 122.070 ms 122.062 ms
15 194.194.28.185.gransy.com (185.28.194.194) 122.095 ms 122.116 ms 122.044 ms

Z vypisu vidime ze packet ze Svycarska se odtoulal do HE.NET, ktery jej poslal do Nemecka. To by nevadilo, kdyby inteligentni HE.NET neprioritizoval trasy svych placenych partneru/zakazniku aby na ceste maximalne profitoval, a neposlal nam tedy packet dal do Flagnetu, ktery neudela nic lepsiho nez si ho po vlastni siti posle do Dubaje, kde skoncime u nas 🙁

A toto jsou presne ty problemy, ktere idealni BGP svet nema, a realny je tim propleteny skrz na skrz 🙁 Jak to vyresime ? Priste 🙂

Napsat komentář

Vaše emailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *

Tato stránka používá Akismet k omezení spamu. Podívejte se, jak vaše data z komentářů zpracováváme..