Ztratovost na sitovem rozhrani routeru

[Bc. Radek Krejca]

Ahoj,

DL>         To je rozhodne VELMI zajimave, protoze na uspesny 'ping' je treba aby
DL> prosel paket tam i zpatky. Ty dva pripady se tak vlastne vubec nelisi -
DL> v obou prijde paket obema smery, jen se lisi v tom, kterym smerem projde
DL> jako prvni. I kdyby byl jeden smer problematicky, kdezto druhy nikoliv,
DL> ztratovost pingu by mela byt v obou pripadech stejna. A nenapada me 
DL> zadna pricina, ktera by komplikovala pruchod "podle poradi".

Tak tak, nicmene je to tak. Bylo mi divne, ze to z jedne strany jde,
z druhe ne.

DL>         Muzes zkusit zjistit, kterych z tech dvou paketu se v jednom pripade
DL> 15% ztraci. To znamena pustit na obou koncich tcpdump (v nepromiscuitnim
DL> modu jinak chovani systemu zasadne ovlivnis). spustit ping, ktery posle
DL> dany znamy pocet pozadavku (option -c) a pak vyhodnotit vystupy tcpdumpu
DL> - a tim zjistit, jestli se ztraci jeden nebo druhy smer.

Je to prastenejsi jeste o to vic, ze to dela pouze v pripade, kdy
traffic preleze urcity limit (zatim jsem ovsem nezjistil, jaky to
presne je). Takze toto zkusit mohu az zitra :-(.

DL>         Jedine nejaka obskurdni chyba v topologii site na druhe vrstve, kdy by
DL> switch pred routerem rychle ztracel informaci o tom, na kterem portu 
DL> router ma - pak by ping z routeru switch "naucil" a rychle se vracejici
DL> odpoved by se tedy vratila kam ma - kdezto v opacnem smeru, kdyz by 
DL> switch mel prislusnou MAC naucenou na jinem portu by se ping-request 
DL> "ztratil" - sice by dorazila jinemu pocitaci, ale protoze by nesedela IP
DL> tak ten by neodpovedel.

Toto je zajimava moznost, vyzkousim dat jiny switch.

Zatim diky
Radek

-- 
S pozdravem,
 Bc. Radek Krejca
 STARNET, s. r. o.
 radek at ceskedomeny.cz