Evo, vec je 3 meseca proslo, a rezultat isti ... Zamalo da se i ja prevarim da pomislim da nesto nije u redu, ali onda zapazih jednu cudnu pravilnost: recimo ovaj poslednji traceroute sa Hetznera - da li ste primetili da je RTT pocev od hopa #6 do kraja identican, iako se ruter #6 nalazi u Frankfurtu, a ruter #14 u Denveru?! Od Frankfurta do Beograda RTT ne bi smeo da predje 20 ms, do Washingtona bi trebalo da bude max 100 ms (20 ms do Frankfurta + nekih 10 ms do obale Atlantika + 70 ms transatlantski RTT), a do Denvera je 150 ms vec normalna stvar (dodajte jos 50 ms od US East Coast do Denvera).
A onda videh i ovaj odgovor:
http://www.elitesecurity.org/p3399212
Zapravo, problema uopste nema! Rec je o pogresnom rezultatu koji daje traceroute u mrezama gde se koristi MPLS, a Level3 ga (ocigledno) koristi. Prica je malo duza, ali ukratko stvar izgleda ovako:
Cim paket udje u MPLS mrezu, ulazni (ingress) PE ruter mu dodaje labelu i prosledjuje preko nekoliko P rutera do odredista, koje je najcesce povezano na neki izlazni (egress) PE ruter. U opstem slucaju to izgleda ovako:
Telekom/SBB --- Telia/Tinet --- iPE (L3) - P1 - P2 - ... Pn - ePE (L3) - Destination
Posto P ruteri (P1 ... Pn) na putu od ulaznog do izlaznog PE rutera po definiciji ne vide IP routing tabelu, vec manipulisu iskljucivo MPLS labelama, oni ne mogu da posalju ICMP Time Exceeded poruku direktno nazad ka izvoristu (Telekom ili SBB) jer ne znaju kako da to urade. Sve sto mogu je da proslede taj ICMP paket po MPLS LSP-u (sa MPLS labelom) ka odredisnom PE ruteru i puste njega da odluci sta da uradi s njim. Posledica toga je da traceroute uvek daje RTT egress PE rutera, a ne svakog P rutera ponaosob.
Punu pricu o tome imate
ovde.
Pravilno tumacenje traceroute outputa nije nimalo jednostavna stvar, ali ima lep tutorijal (uz pratecu prezentaciju) na tu temU:
Tekst:
http://cluepon.net/ras/traceroute.pdf
Prezetnacija:
https://www.nanog.org/meetings.../Sunday/RAS_traceroute_N45.pdf