Bc. Radek Krejca napsal/wrote, On 03/08/08 19:39:
> Dam-li ping z jakehokoliv pocitace na tento router, je ping
> ztratovy, pri zatizenem routeru az 15 %. Navic rychlost kolisa v
> radu desitek ms.
>
> Dam-li z tohoto routeru ping na ten pocitac, ze ktereho pingal ze
> ztratou, jede ping bez problemu. Provedl jsem jiz vymenu sitove
> karty, vysledek vice mene stejny.
To je rozhodne VELMI zajimave, protoze na uspesny 'ping' je treba aby
prosel paket tam i zpatky. Ty dva pripady se tak vlastne vubec nelisi -
v obou prijde paket obema smery, jen se lisi v tom, kterym smerem projde
jako prvni. I kdyby byl jeden smer problematicky, kdezto druhy nikoliv,
ztratovost pingu by mela byt v obou pripadech stejna. A nenapada me
zadna pricina, ktera by komplikovala pruchod "podle poradi".
Nemuze jit ani o problem souvisejici s velikosti paketu - request a
reply od ICMP jsou typicky stejne velike.
Muzes zkusit zjistit, kterych z tech dvou paketu se v jednom pripade
15% ztraci. To znamena pustit na obou koncich tcpdump (v nepromiscuitnim
modu jinak chovani systemu zasadne ovlivnis). spustit ping, ktery posle
dany znamy pocet pozadavku (option -c) a pak vyhodnotit vystupy tcpdumpu
- a tim zjistit, jestli se ztraci jeden nebo druhy smer.
Mozna se touhle informaci nekam odpichneme, ale popravde receno, ted me
nenapada kam at ti vyjde cokoliv ;-)
Jedine nejaka obskurdni chyba v topologii site na druhe vrstve, kdy by
switch pred routerem rychle ztracel informaci o tom, na kterem portu
router ma - pak by ping z routeru switch "naucil" a rychle se vracejici
odpoved by se tedy vratila kam ma - kdezto v opacnem smeru, kdyz by
switch mel prislusnou MAC naucenou na jinem portu by se ping-request
"ztratil" - sice by dorazila jinemu pocitaci, ale protoze by nesedela IP
tak ten by neodpovedel.
Jo - pocitac se stejnou MAC jako router (ale jinou IP, protoze jinak by
to rvalo) by MOHL vest k popsanemu efektu. Musel by to byt nejaky
takovy, ktery nekomunikuje moc, jinak by se ti toho ztracelo daleko vic.
Dan
> em0: <Intel(R) PRO/1000 Network Connection Version - 3.2.18> port
> 0x5000-0x503f mem 0xfdfe0000-0xfdffffff,0xfdf80000-0xfdfbffff irq 72 at
> device 1.0 on pci10
> em0: Ethernet address: 00:1b:21:09:9b:c0
> em1: <Intel(R) PRO/1000 Network Connection Version - 3.2.18> port
> 0x5040-0x507f mem 0xfdf60000-0xfdf7ffff,0xfdf00000-0xfdf3ffff irq 73 at
> device 1.1 on pci10
> em1: Ethernet address: 00:1b:21:09:9b:c1
> bge0: <Broadcom BCM5704C Dual Gigabit Ethernet, ASIC rev. 0x2100> mem
> 0xfde70000-0xfde7ffff irq 25 at device 2.0 on pci2
> miibus0: <MII bus> on bge0
> brgphy0: <BCM5704 10/100/1000baseTX PHY> on miibus0
> brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX,
> 1000baseTX-FDX, auto
> bge0: Ethernet address: 00:16:35:5b:89:b4
> bge1: <Broadcom BCM5704C Dual Gigabit Ethernet, ASIC rev. 0x2100> mem
> 0xfde60000-0xfde6ffff irq 26 at device 2.1 on pci2
> miibus1: <MII bus> on bge1
> brgphy1: <BCM5704 10/100/1000baseTX PHY> on miibus1
> brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX,
> 1000baseTX-FDX, auto
> bge1: Ethernet address: 00:16:35:5b:89:b3
--
FreeBSD mailing list (users-l@freebsd.cz)
http://www.freebsd.cz/listserv/listinfo/users-l
