Předně je vhodné si uvědomit, jak traceroute pracuje. Je to jednoduché, pošle packet na neexistující socket (některé implementace tak činí protokolem udp, jiné protokolem icmp, existují ovšem i verze využívající k tomu protokol tcp) a čeká doručení odpovědi o nedoručitelnosti takového packetu, přičemž měří také čas, za jak dlouho taková odpověď dorazí. Podle TTL se pak zjistí, kolikátý hop v cestě nám zprávu o nedoručitelnosti odeslal. Uvedeme si příklad takového traceroute, cestu záměrně vybírám nějakou kratší, například tuto:

 traceroute to f.root-servers.net (192.5.5.241), 64 hops max, 52 byte packets  1  88.208.65.1 (88.208.65.1)  0 ms  0 ms  0 ms  2  212.24.132.169 (212.24.132.169)  1 ms  1 ms  1 ms  3  cz-prg-cr1-kkk-ge1-1.dialtelecom.cz (82.119.245.81)  1 ms  1 ms  1 ms  4  f-root1-nix.nic.cz (194.50.100.181)  1 ms  1 ms  1 ms  5  f.root-servers.net (192.5.5.241)  1 ms  1 ms  1 ms 

Vpravo vedle každého hopu vidíte tři časy, protože traceroute to zkusí třikrát (implicitně, tuto hodnotu je možné změnit), aby si uživatel mohl udělat představu o tom, jak moc se mohou časy u jednotlivých packetů rozcházet. Pro jednoduchost třikrát uvádím packet jdoucí pouze na první hop a jeho odpověď:

10:01:47.548115 IP (tos 0x0, ttl   1, id 62450, offset 0, flags [none], proto: UDP (17), length: 52) 88.208.65.67.33975 > 192.5.5.241.33435: [no cksum] UDP, length 24 > 10:01:47.548203 IP (tos 0xc0, ttl  64, id 3252, offset 0, flags [none], proto: ICMP (1), length: 80) 88.208.65.1 > 88.208.65.67: ICMP time exceeded in-transit, length 60 > IP (tos 0x0, ttl   1, id 62450, offset 0, flags [none], proto: UDP (17), length: 52) 88.208.65.67.33975 > 192.5.5.241.33435: [no cksum] UDP, length 24 > 10:01:47.549548 IP (tos 0x0, ttl   1, id 62451, offset 0, flags [none], proto: UDP (17), length: 52) 88.208.65.67.33975 > 192.5.5.241.33436: [no cksum] UDP, length 24 > 10:01:47.549631 IP (tos 0xc0, ttl  64, id 3253, offset 0, flags [none], proto: ICMP (1), length: 80) 88.208.65.1 > 88.208.65.67: ICMP time exceeded in-transit, length 60 > IP (tos 0x0, ttl   1, id 62451, offset 0, flags [none], proto: UDP (17), length: 52) 88.208.65.67.33975 > 192.5.5.241.33436: [no cksum] UDP, length 24 > 10:01:47.549735 IP (tos 0x0, ttl   1, id 62452, offset 0, flags [none], proto: UDP (17), length: 52) 88.208.65.67.33975 > 192.5.5.241.33437: [no cksum] UDP, length 24 > 10:01:47.549884 IP (tos 0xc0, ttl  64, id 3254, offset 0, flags [none], proto: ICMP (1), length: 80) 88.208.65.1 > 88.208.65.67: ICMP time exceeded in-transit, length 60 > IP (tos 0x0, ttl   1, id 62452, offset 0, flags [none], proto: UDP (17), length: 52) 88.208.65.67.33975 > 192.5.5.241.33437: [no cksum] UDP, length 24 

Pro další hopy každý request a odpověď na něj již jen jednou:

 10:01:47.550045 IP (tos 0x0, ttl   2, id 62453, offset 0, flags [none], proto: UDP (17), length: 52) 88.208.65.67.33975 > 192.5.5.241.33438: [no cksum] UDP, length 24  10:01:47.551165 IP (tos 0xc0, ttl 254, id 1812, offset 0, flags [none], proto: ICMP (1), length: 56) 212.24.132.169 > 88.208.65.67: ICMP time exceeded in-transit, length 36  IP (tos 0x0, ttl   1, id 62453, offset 0, flags [none], proto: UDP (17), length: 52) 88.208.65.67.33975 > 192.5.5.241.33438: [no cksum] UDP, length 24  10:01:47.553826 IP (tos 0x0, ttl   3, id 62456, offset 0, flags [none], proto: UDP (17), length: 52) 88.208.65.67.33975 > 192.5.5.241.33441: [no cksum] UDP, length 24  10:01:47.554281 IP (tos 0xc0, ttl 253, id 38785, offset 0, flags [none], proto: ICMP (1), length: 56) 82.119.245.81 > 88.208.65.67: ICMP time exceeded in-transit, length 36  IP (tos 0x0, ttl   1, id 62456, offset 0, flags [none], proto: UDP (17), length: 52) 88.208.65.67.33975 > 192.5.5.241.33441: [no cksum] UDP, length 24  10:01:47.556951 IP (tos 0x0, ttl   4, id 62459, offset 0, flags [none], proto: UDP (17), length: 52) 88.208.65.67.33975 > 192.5.5.241.33444: [no cksum] UDP, length 24  10:01:47.557538 IP (tos 0xc0, ttl 252, id 54443, offset 0, flags [none], proto: ICMP (1), length: 56) 194.50.100.181 > 88.208.65.67: ICMP time exceeded in-transit, length 36  IP (tos 0x0, ttl   1, id 62459, offset 0, flags [none], proto: UDP (17), length: 52) 88.208.65.67.33975 > 192.5.5.241.33444: [no cksum] UDP, length 24  10:01:47.560581 IP (tos 0x0, ttl   5, id 62462, offset 0, flags [none], proto: UDP (17), length: 52) 88.208.65.67.33975 > 192.5.5.241.33447: [no cksum] UDP, length 24  10:01:47.561281 IP (tos 0x0, ttl  60, id 36181, offset 0, flags [none], proto: ICMP (1), length: 56) 192.5.5.241 > 88.208.65.67: ICMP 192.5.5.241 udp port 33447 unreachable, length 36  IP (tos 0x0, ttl   1, id 62462, offset 0, flags [none], proto: UDP (17), length: 52) 88.208.65.67.33975 > 192.5.5.241.33447: [no cksum] UDP, length 24 

Výpisy traceroute jsou lidsky poměrně snadno čitelné a tak si na základě toho, co z traceroute vypadne, dokáže udělat představu i naprostý laik. Často však značně nepřesnou či dokonce mylnou. Pomiňme filtrování či negenerování ICMP zpráv o nedoručitelnosti, projevující se ve výpisech jako řádky plné hvězdiček. S jakými nejčastějšími „špeky“ se tedy můžeme setkat?

1. tzv. „Cisco bug“

Projevuje se tak, že dorazí jen jedna či dvě odpovědi ze tří (či více, pokud použijeme některou z implementací tohoto příkazu, která umožňuje dané hodnoty měnit), případně je jedna z odpovědí výrazně opožděna. Jak už název napovídá, projevují se tak zejména směrovače Cisco Systems téměř všech řad od 8×x do 75×x, chyba se projevuje jak u IPv4, tak u IPv6. Jiná data, než právě dotyčné odpovědi pro traceroute, nejsou afektována.

2. hybridní platformy

Hybridní platformou jsou téměř všechny moderní boxy, zvládající „přehazovat“ desítky gigabitů a desítky megapacketů za sekundu bez vlivu na latence atp. Termín „přehazovat“ je použit jako asi nejvýstižnější český ekvivalent anglického „forwarding“ a je použit záměrně, protože se vztahuje na všechny typy přenášení dat přes box, tedy na přepínání na druhé vrstvě (switching), směrování na třetí vrstvě (routing), případně též přepínání podle MPLS tagu (MPLS forwarding). Zde je problém od předchozí varianty lehce odlišný, ačkoli se projevuje podobně, zejména tedy dlouhou dobou mezi přijetím nedoručitelného packetu a odesláním odpovědi. Toto je způsobeno tím, že odpovídání na provozně nedůležité věci (jimiž jsou také odpovědi na ping nebo na traceroute) řeší procesor těchto zařízení, kdežto „přehazování“ packetů a rámců řeší obvody na jednotlivých rozhraních. Pokud se tedy trefíte do okamžiku, kdy má procesor na práci něco jiného (například přepočítávání směrovacích tabulek), uvidíte poměrně dlouhou odezvu, která se však opět neafektuje data boxem procházející. Takové chování je společné pro všechny takto fungující boxy, ať už je jejich výrobcem Cisco, Force10, Foundry nebo Juniper a obvykle se po zopakování takového pokusu po několika sekundách nebo desítkách sekund neopakuje. Uvědomme si, že samotný koncept je starý jako sama rodina protokolů TCP/IP a tehdy nikdo nemohl tušit, že někdy budou existovat jiné, než softwarové routery (v počátcích Internetu se k routování používaly stroje kategorie „minipočítač“, čímž se v 80. letech označoval počítač zabírající celý nebo téměř celý rack, například DEC PDP-11).

3. equal cost multipath

Stalo se vám, že jste u jednoho hopu viděli více než jednu IP adresu? Tak se projevuje funkce zvaná equal cost multipath, kdy jsou data posílána střídavě různými rozhraními, obvykle podle pořadí, v jakém přišly (pozor, takto se neprojevují technologie, spojující více rozhraní do jednoho logického celku, tedy například etherchannel). Jednotlivé cesty mohou mít často též různý průběh a někdy dokonce rozdílný počet hopů (!). To se projeví tím, že další výpis vypadá tak, jako by za daným hopem už byly jen samé equal cost multipath cesty. Také to nemusí být vždy chyba a nepříjemnosti s tím spojené jsou způsobeny také už samotným principem fungování traceroute. Příklad takové cesty rozhozené equal-cost multipath uvádím zde:

 1  cz-prg-cr1-kkk-ge1-3.dialtelecom.cz (82.119.245.101) [AS29208]  (0.7 ms/1.1 ms(+-0.5 ms)/1.5 ms) 5/5 (100.00%)  2  cz-prg-cr1-pan-10ge2-1.dialtelecom.cz (82.119.245.73) [AS29208]  (0.9 ms/7.3 ms(+-6.4 ms)/31.7 ms) 5/5 (100.00%)  3  ge-1-1-0-21.prg11.ip.tiscali.net (213.200.74.93) [AS3257]  (1.0 ms/1.5 ms(+-0.7 ms)/2.8 ms) 5/5 (100.00%)  4  so-5-1-0.fra40.ip.tiscali.net (89.149.186.149) [AS3257]  (9.0 ms/9.6 ms(+-4.3 ms)/10.6 ms) 5/5 (100.00%)  5  xe-10-2-0.edge5.frankfurt1.level3.net (4.68.63.57) [AS3356] *  (9.1 ms/13.8 ms(+-7.9 ms)/27.3 ms) 4/5 (80.00%)  6  ae-31-55.ebr1.Frankfurt1.Level3.net (4.68.118.158) [AS3356] ae-32-56.ebr2.Frankfurt1.Level3.net (4.68.118.190) [AS3356] ae-32-52.ebr2.Frankfurt1.Level3.net (4.68.118.62) [AS3356]  (19.6 ms/23.8 ms(+-10.9 ms)/31.9 ms) 5/5 (100.00%)  7  ae-2.ebr1.Dusseldorf1.Level3.net (4.69.132.137) [AS3356] ae-1-100.ebr2.Frankfurt1.Level3.net (4.69.132.126) [AS3356]  (20.2 ms/26.1 ms(+-11.8 ms)/30.0 ms) 5/5 (100.00%)  8  ae-1-100.ebr2.Dusseldorf1.Level3.net (4.69.132.130) [AS3356] ae-2.ebr1.Dusseldorf1.Level3.net (4.69.132.137) [AS3356]  (26.1 ms/31.7 ms(+-14.3 ms)/36.5 ms) 5/5 (100.00%)  9  ae-1-100.ebr2.Dusseldorf1.Level3.net (4.69.132.130) [AS3356] ae-2.ebr1.Amsterdam1.Level3.net (4.69.133.89) [AS3356]  (20.0 ms/31.3 ms(+-14.3 ms)/36.7 ms) 5/5 (100.00%)  10  ae-2.ebr1.Amsterdam1.Level3.net (4.69.133.89) [AS3356] ae-1-100.ebr2.Amsterdam1.Level3.net (4.69.133.86) [AS3356] ae-2.ebr1.Amsterdam1.Level3.net (4.69.133.89) [AS3356]  (19.1 ms/26.3 ms(+-11.9 ms)/30.2 ms) 5/5 (100.00%)  11  ae-2.ebr2.London1.Level3.net (4.69.132.133) [AS3356] ae-1-100.ebr2.Amsterdam1.Level3.net (4.69.133.86) [AS3356]  (19.1 ms/26.6 ms(+-12.2 ms)/36.2 ms) 5/5 (100.00%)  12  ae-25-52.car5.London1.Level3.net (4.68.116.51) [AS3356] ae-2.ebr2.London1.Level3.net (4.69.132.133) [AS3356] ae-25-52.car5.London1.Level3.net (4.68.116.51) [AS3356] ae-2.ebr2.London1.Level3.net (4.69.132.133) [AS3356]  (27.1 ms/30.7 ms(+-13.9 ms)/38.9 ms) 5/5 (100.00%)  13  217.163.44.54 (217.163.44.54) [AS9057/AS3356] ae-25-54.car5.London1.Level3.net (4.68.116.115) [AS3356] 217.163.44.54 (217.163.44.54) [AS9057/AS3356] ae-25-54.car5.London1.Level3.net (4.68.116.115) [AS3356]  (27.2 ms/27.9 ms(+-12.5 ms)/28.8 ms) 5/5 (100.00%)  14  * * * 217.163.44.54 (217.163.44.54) [AS9057/AS3356] *  (33.5 ms/33.5 ms(+-33.5 ms)/33.5 ms) 1/5 (20.00%)  15  * * * * * 

4. Dlouhé odezvy na druhý konec světa

Klasickým případem veselé reklamace jsou dlouhé odezvy do vzdálených lokací. Je vhodné si uvědomit, že šíření signálu v optických kabelech podléhá, jako cokoli jiného v tomto nepříliš povedeném vesmíru, fyzikálním zákonům, a tedy že se šíří pouze rychlostí světla. Rychlost světla ve vakuu je poměrně známá hodnota, cca 300000 km/s, ve skle se světlo šíří rychlostí kolem 220000 km/s, rychlost šíření světla v optickém kabelu je pak rychlostí šíření světla ve skle dělené indexem lomu. Dále je vhodné si uvědomit, že odezva na traceroute či ping musí odpovídat nejméně dvojnásobku této hodnoty, neboť se počítá čas nezbytný k cestě packetu tam i zpátky a packet bývá ještě mířně zpožděn aktivními prvky na trase (tyto časy jsou však obvykle víceméně zanedbatelné) a dále různými optickými kompenzátory, zejména pak kompenzátory chromatické a polarizační vidové disperze (což je často pár kilometrů speciálního kabelu na cívce v zesilovací stanici). V praxi se tak dá považovat na optických linkách za odpovídající odezvu zhruba 1 milisekunda na každých 50 – 70 km vzdálenosti. Tato hodnota je zcela postačující pro drtivou většinu aplikací, pochopitelně kupříkladu online hry či dálkové ovládání různých zařízení může vyžadovat odezvy výřazně nižší, které však na současných optických kabelech se současným indexem lomu nelze dosáhnout. Paradoxně tak jsou rádiové spoje, byť s výrazně nižšími přenosovými kapacitami a výrazně náchylnější k nejrůznějším druhům rušení, v tomto ohledu rychlejší.

To byly nejčastější omyly způsobené nevhodným čtením výpisů z traceroute. Výpis může pomoci dohledat chybu, je však nutné jej považovat pouze za informativní, rozhodně nikoli za jednoznačný zdroj infromací (mimo důvodů uvedených v článku například také proto, že řadu činností dnes mohou vykonávat L2 zařízení, proto, že pomocí manipulace s TTL lze některé hopy zcela skrýt atd.) a informace, které nám poskytne, mohou být sice nedocenitelné, ale pro jednoznačnou diagnostiku problému je nezbytné je ještě několikanásobně ověřovat.

Zbyněk Pospíchal

Autor působí ve společnosti Dial Telecom a.s., kde se zabývá rozvojem páteřních sítí a návrhem a implementací nových síťových služeb.