To jak opravdu funguje traceroute už tu uvedli ostatní. Jen bych ještě poznamenal, že tímto způsobem zjistíme cestu, kterou jdou pakety od uživatele, který traceroute spustil k cílovému uzlu. Cesta zpět, která uživatele často zajímá (kudy to z toho web serveru k mě, sakra, teče? ;), ale může být jiná.
Když už tu byla zmínka o MPLS sítích, tak tam lehce může dojít k tomu (a také dochází), že celá MPLS infrastruktura je pro traceroute skrytá ...
"Cesta zpět, která uživatele často zajímá (kudy to z toho web serveru k mě, sakra, teče? ;), ale může být jiná."
To je opravdu zajímavý postřeh, který mě nenapadl :). Vždy jdou pakety přibližně nejlepší cesta. Už z principu začátek od tebe a konec u serveru moc jiný být nemůže, protože od tebe nemůžou jít pakety jinudy než do nějakého centra tvého ISP a stejně je tomu u serveru, otázka je, jak to bude v prostřed cesty.
Myslíš, že se prostředek cesty bude opravdu hodně lišit mezi odchozím a příchozím provozem? A jestli ano, jak hodně, spíše náhodně, občas a nebo to typicky půjde jinudy?
Má s tím někdo zkušenosti, protože tohle je opravdu zajímavé :).
Napr. v zacatcich Czfree k tomu dochazelo celkem casto jen proto, ze si kazda strana spoje dala jiny cost vycucany z palce. Pak ty trasy dotazu a odpovedi byly obcas velice zajimave.
Dovedu si ale predstavit, ze nekde je to takto nastavene umyslne z duvodu rozdilnych sirek pasma spoje mezi obema smery. Pak se muze router nebo nejaka load balance ficura rozhodnout, ze odpoved pujde uplne jinudy.
Zjednodusene asi takto, uzivatel zada cestu k serveru a traceroute mu tu cestu ukaze, nicmene mame ucpanou jednu linku na download, ale upload je ok.
Takze vypis tracertu jde po tom uploadu a to vidi uzivatel.
Download zpatky k uzivateli jde pres cestu delsi o dva hopy
a on nic nepozna. V principu ty linky jsou jako trouhelnik,
pro pochopeni.
Ano, ta cesta se lisit muze. Nekdy tak, ze to ani nerozeznate (pokud pouzivate na linkach spojovaky /30, tak vidite vzdy jinou cestu a sparovani ktery box je ktery se vam podle reversu povest muze, ale nemusi), to muze byt treba priklad ISP, ktery ma dve linky do NIXu a provoz tam jde jednou a zpet druhou...
No a jindy to poznate, protoze se to muze lisit i v cislech AS, pres ktere to tece. Typicky priklad je, kdyz nekdo (vy, vas upstream, upstream site, s niz komunikujete, samotna sit, s niz komunikujete nebo nekdo dalsi na nektere z existujicich cest) meni local preference. ISP ovlivni cestu od sebe, ale moznosti jak ovlivnit cestu k sobe, ma mnohem omezenejsi (prepend, BGP community a ve velmi omezene mire metrika a tim jsme asi tak skoncili).
No a posledni pripad jsou dve velke site (rekneme upstream vas a upstream toho, s kym komunikujete) peerujici na vice ruznych mistech. Obvykle takova sit ma smerovaci politiku oznacovanou jako "horky brambor" (hot potato), coz znamena, ze se snazi zbavit provozu co nejdrive to jde (to je celkem logicke). Takze tam jdete vetsi cast cesty siti, placenou tim, s kym komunikujete a zpet vetsi cast cesty siti, za jejiz sluzby platite vy. Kazdopadne existuje i opacny "cold potato" pristup, jen se nevidi tak casto.
Asi bych toho o tom routingu mel nekdy napsat trochu vic, prijde to zajimave jeste nekomu dalsimu?
:) a ty si zas projdi první stupeň základní školy, protože jsem ti napsal, že mi to připomíná masku.
Když už jsi tak chytrý, co mi vysvětlit tuto větu
"pokud pouzivate na linkach spojovaky /30, tak vidite vzdy jinou cestu a sparovani ktery box je ktery se vam podle reversu povest muze, ale nemusi)"
Jestli teda na to máš, protože já přiznávám, to nechápu, a znovupřečtení Peterkových sítí mi rozhodně v porozumění této věty nepomůže, protože tyhle důležité věci (maska, TTL,... si ještě pamatuji) a stejně nechápu co tím pisatel myslel.
Mimochodem Peterkovy sítě taky nejsou moc dobře vysvětleny, ty jeho slajdy jsou fajn, ale praxe trochu uniká. Sice se člověk naučí v kterém bajtu hlavičky je co, ale jak to ve skutečnosti funguje, to už se nedozví, naopak historie je tam tuna. Možná by stálo za to je vypíchnot stávající TCP/IP a udělat materiál jen o něm a nemíchat ho v minulostí a budoucností, jak to dělá Peterka, je v tom pak děsný guláš.
Mluvi se tady o spojovacim rozsahu, coz je cas site, ktera se pouziva pro spojeni dvou ci vice aktivnich prvku a neni v ni pripojeny zadny koncovy bod.
Nejmensi spojovaci rozsah muze mit velikost 4 IP adres, protoze jedna padne na adresu site, jedna na broadcast a dve jsou potom pridelitelne realnym zarizenim. Tak velka sit se potom zapisuje symbolicky jako /30, coz je pocet bitu v netmasce nastavenych na 1.
Teoreticky je mozne mit spojovaci rozsah /31, tedy se dvema IP adresami, ale neni to podporovano vsemi zarizenimi a pokud si to tak treba na linuxu nastavite, budete mit problem po prechodu na jinou technologii.
Aha, díky za vysvětlení, proč se vlastně spojují zařízení, k čemu je to dobré? Můžeš mě odkázat na nějaký tutorial, či aspoň, jak se tomu anglicky říká, ať si to můžu najít?
No ja obvykle lidem tvrdim, ze spojovanim zarizeni vznika Internet ;-)
Pod zarizenimi si lze predstavit napr. router v Praze a router v Brne.
S tim anglickym terminem jste me dostal. To totiz netusim, podle me na to zadne hezke slovo nemaji. Pise se vetsinou /30 network nebo connecting network, transport network, proste zadne uderne malebne slovo me nenapada.
Kazdy router, kdyz dostane paket, musi rozhodnout, jak s paketem nalozi. To udela podle routovaci tabulky, ve ktere vyhleda, pres jakou dalsi IP adresu vede cesta, kterou je treba paket poslat.
Proto musi mit kazdy dalsi router IP adresu, prave tu, na jakou se paket posila. A pokud jsou dva routery spojeny linkou bod-bod (PtP), tak na spojeni potrebujete sit ve ktere ma kazdy router jednu vlastni IP adresu, cili dve adresy dohromady a ty dve spolu s adresou site a brodcast adresou tvori 4 IP adresy = nejmensi mozna sit. Teto nejmensi mozne siti se rika spojovaci rozsah, /30, spojovacka nebo spojovak.
Rekneme priklad, kde se s tim potka i bezny zakaznik. Pozadate providera o pripojeni a chcete mit vlastni firewall. Takze provider vam prideli dva rozsahy, jeden treba se 16 IP adresami pro koncove pocitace a jeden spojovaci. Vy potom na vnejsim rozhranni firewallu nastavite IP adresu ze spojovaciho rozsahu, druhou nastavi provider u sebe na routeru. Na vnitrni strane firewallu date prvni (nebo dle chuti) IP adresu z toho 16 IP adresniho rozsahu a ostatni date na sve pocitace. Pocitacum nastavite jako vychozi branu tu IP adresu, kterou jste dal na vnitrni stranu firewallu. Takze kdyz pocitace maji paket, ktery neni urcen pro jiny vas pocitac, tak paket poslou na IP adresu vychozi brany, tedy firewallu. Firewall zjisti, ze paket patri do Internetu a posle jej na svou vychozi branu, tedy na IP adresu providera ze spojovaciho rozsahu.
A ted se paket vraci, resp. prichazi nam odpoved na nas paket. Provider vi, ze patri do nasi site, takze jej u sebe na routeru posle na nasi IP adresu ze spojovaciho rozsahu a firewall jej doruci na konkretni pocitac, protoze uz vi, ze se jedna o paket pro lokalni stroj, ze se nebude dale routovat.
A tady nastava ten efekt, ze IP je pro kazdy smer jina. V tom spojovacim rozsahu sel paket od nas ven pres IP providera a ze sveta k nam pres nasi IP ve spojovacim rozsahu. Prestoze je to jeden fyzicky spoj, v kazdem smeru ma jinou IP a tak to opticky muze vypadat, ze paket jde jinudy.
Ale upozornuji, ze jsem to cele zkusil zjednodusit, nez nez nekdo prijde s tim, ze MPLS a podobni to dela jinak. Take jsou pripady, treba NIX, ze je spojeno vice zarizeni tak, ze spojovaci rozsah ma mnohem sirsi netmasku a vice IP adres.
Pisatel tím dle mého názoru myslel fakt, že pokud používáte spojovací sítě /30, tak ve výpisu traceroute vidíte vždy jiné adresy. Podle reverního záznamu sice občas můžete zjistit, komu patří konkrétní aktivní prvek, ale také nemusíte.
Peterkovy sítě si nejen přečtěte, ale pokuste se je pochopit. Základy pochopily i studentnky druhého ročníhu knihovnictví na FF UK. Věřím, že se Vám to také může podařit.
Asymetrické routování je opravdu ve světě docela běžné (někdy úmyslně, jindy chybou v konfiguraci). Někdy ale traceroute umí alespoň napovědět, že se něco takového děje: pozná to podle TTL přijatých ICMP packetů. Neví sice, s jakým přesně TTL byly odeslány, ale zná několik běžných hodnot a když mu ani u jedné z nich nevychází stejný počet skoků jako u cesty tam, zmíní se o tom.