Ztratovost na sitovem rozhrani routeru

[Dan Lukes]

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