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. [EMAIL PROTECTED] -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
