Portál AbcLinuxu, 5. května 2025 13:11
ip -s -s link show dev eth1 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc htb qlen 1000 link/ether 00:1d:92:23:6b:fe brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped overrun mcast 747473035 103966270 9 0 0 0 RX errors: length crc frame fifo missed 0 0 0 9 13326 TX: bytes packets errors dropped carrier collsns 4222548359 108744074 0 0 0 0 TX errors: aborted fifo window heartbeat 0 0 0 0Google toho moc neví, někde jsem našel vysvětlení, že se obě strany linky nedokáží domluvit na rychlosti. Tohle jsem vyloučil postupnout výměnou: Routeru (HW i OS), kabelu, switche. Vše je jiné. Jediný problém může být v softu. Proběhla změna OS z Fedora4 na CentOS 5.0. Routování (staticky cca 100 cest), nastavení rozhranní, shaping (htb) zůstalo stejné. Na daný packet loss nemá vliv: vypnuté shapování (tc qdisc del root), vypnutý fw (iptables -F), ani trafic. Začínám mít pocit, že mi tam straší
Kudy ten kabel vedeš? Neni tam nějaký rušení? Píšeš že si vyměnil OS, zkoušel si jiné jádro resp. jinou verzi ovladače?
136k 118k 136k 139k 136k 139k 142k 22k 200k 20k 172k 136k 118k 136k ...Průměr tedy odpovídá. Ale když v jedné sekundě dojde k výpadku, tak v další přijde dvojnásobek dat. Tedy i data z toho výpadku a klient jede rychlostí vyšší než má v HTB. Kolega paří WOW a říkal, že vše co se "během" výpadku stane mu přijde (a od něj odejde) o tu sekundu později. Pak to jede opět normálně. Tomu bych u TCP rozumněl, ale proč přijde naráz dvojnásobek dat je mi také záhadou.
ethtool eth1 Settings for eth1: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Advertised auto-negotiation: Yes Speed: 100Mb/s Duplex: Full Port: MII PHYAD: 1 Transceiver: internal Auto-negotiation: on Supports Wake-on: pumbg Wake-on: d Current message level: 0x00000001 (1) Link detected: yes
Zkoušel jsi ten switch restartovat ?
Je vyměněn . Byl tam zcela jiný. Byly tam VLANy, teď je default. Proč si myslíš, že to bude v tom switchi?
Tak Ti mě napadá,jaký trafic jde přes ten router?
cca 10Mb/s. Nadměrná zátěž tu nikde není, vše je měřeno. Ten router se fláká (doufám, že by to load, htop atd ukázal). Počet konektů hluboko pod maximem. Po snížení TCP timetoutu to ještě více kleslo. Ještě doplním, že přímo na tento router není připojeno žádné domácí PC. Jsou na něm servery (nulový trafic, navíc omezeno v HTB) a další routery a až za nimi obyč PC lidí.
A teď mě napadá, co takle odpojit switch od routeru a připojit jen jedno pecko k routeru a zkusit přez něj komunikovat ven ? Víš bez dalších stanic ...
Ano, tohle bude asi jediná možnost. Jenže, po jednom restartu routeru to vydrží třeba dva dny bez jediného vypadlého packetu. Po dalším restartu je loss okamžitý. Odpojit celou síť na dva dny si nemuho dovolit.
Ano, tohle bude asi jediná možnost. Jenže, po jednom restartu routeru to vydrží třeba dva dny bez jediného vypadlého packetu. Po dalším restartu je loss okamžitý. Odpojit celou síť na dva dny si nemuho dovolit.Co by se stalo, kdybys nic nerestartoval, a rovnou místo toho switche bouchnul PCčko o kterém víš, že je vpořádku a pak začal komunikovat přes ten router ven ? Bylo by to s chybama, které uvádíš ? Tím nechci říct, že by switch, ba ani router nebyly OK, ale pokusil bych se alespoň odstranit doměnku, že si ti dva "nepadly" do oka. Já vím, je to taková šamanština , ale co když ... Jinak , já nevím, mě nic jiného momentálně nenapadá ... Dobrou noc :o)
A nějakej debug to neosvětlí, logování s nejvyšší úrovní?
eth1 Link encap:Ethernet HWaddr 00:10:4B:1C:52:0F inet addr:80.188.227.18 Bcast:80.188.227.23 Mask:255.255.255.248 inet6 addr: fe80::210:4bff:fe1c:520f/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:10884428 errors:0 dropped:0 overruns:0 frame:0 TX packets:9087140 errors:0 dropped:0 overruns:0 carrier:129 collisions:2632 txqueuelen:1000 RX bytes:1079902235 (1.0 GiB) TX bytes:1594204219 (1.4 GiB) Interrupt:18 Base address:0xe000pomohlo nastaveni na 10Mbit:
root@nat:~# ethtool eth1 Settings for eth1: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Full Advertised auto-negotiation: Yes Speed: 10Mb/s Duplex: Full Port: MII PHYAD: 24 Transceiver: internal Auto-negotiation: on Current message level: 0x00000001 (1) Link detected: yespak prestali v ciscu a na eth1 ty kolize ... chybu z dmesg si nepamatuju a pravdepodobne se jednalo o jiny problem, jen stejna sitovka ... Ja nevim, s 3comama, mam vzdy nejakou chybu, zatim co s realtekama za 90 korun ne ...
root@nat:~# lspci 00:0a.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 78) 00:0c.0 Ethernet controller: 3Com Corporation 3c900B-TPO Etherlink XL [Cyclone] (rev 04) 00:13.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
Procházel jsem i zdrojáky jádra, abych zjistil co to vlastně znamená a nikde nic.Je to deklarované v linux/netdevice.h, resp. linux/if_link.h. Např. ovladač 8139too (drivers/net/8139too.c) mění tento čítač na třech místech. Váš případ bude asi funkce rtl8139_weird_interrupt(), která je volána při přerušení z důvodu chyby (na PCI sběrnici, příjmu poškozeného rámce, přetečení fronty v síťovce). Počítadlu je přičtena hodnota, která se bere přímo z registru na kartě. Takže bych chybu viděl mezi síťovou kartou a switchem. Ujistit se můžete zapnutím ladění v modulu předefinováním symbolu RTL8139_DEBUG na nenulovou hodnotu (linux-2.6.24.3/drivers/net/8139too.c:129).
na PCI sběrnici, příjmu poškozeného rámce, přetečení fronty v síťovce
Díky. Ano, tohle by tomu odpovídalo, zejména chyba v rámci. To stále více to ukazuje na problém switche. Dám tam ještě lepší a uvidím. Zatím pomáhá restart toho switche (pomůže tak na jeden den) a nastavení 100base TX-HD. Vypadá to, že v něm něco přetéká.
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.