Tx/Rx Errors a Tx/Rx Drops

Může toho být víc...špatný port, flow controll, kabel, nějaká nekompatibilita chipsetů. Zkus na tom fixnout rychlost na plný gigo (na obouch koncích), pokud nepomůže, vraz mezi to na test další switch a budeš chytřejší.

Co způsobuje tyto chyby? Na jednom routeru cca půl roku starém se toto docela hojně oběvuje na ethernetu který je propojen do gigabitového switche.

Errors - obecne nejake poskozene packety apod. Podrobnejsi informace by mely prinest dalsi countery (FCS,...)

Drops - vetsinou packety zahozene kvuli nedostatku pameti pro dalsi zpracovani (treba i prekroceni rycvhlosti shaperu) . CIli TX Drop = nebylo uz mistov odchozi fronte, RX drop router uz zpracovava moc vstupnich packetu apod.

Pred par dny jsem resil uplne to stejne. V routeru Intel PCI-E 1 Gbit sitovka, switch preply port na 100 Mbit. Po propojeni errory a dropy. Jakmile se port ve sw prepl na 1 Gbit, vsechno v poradku.

Ted se mi tohle deje na prepojeni 2011 s 911.

Puvodne misto 911 byla 411 a rozpadal se link na ETH. Tak jsem myslel ze je na 411 vadnej port, protoze ani natazeni noveho kabelu nepomohlo. Tak jsem tam dal 911 ale problem se objevuje stale. Narusta RX FCS errors ale link uz je stabilni. Ve finale se to projevuje packetlostem. Switch jsem tam mel predtim u ty 411 a nepomohlo to. Ted uz me napada jedine vadnej port na 2011, nebo nejaka zavada na portu v PoE panelu.

Ted se mi tohle deje na prepojeni 2011 s 911.

Puvodne misto 911 byla 411 a rozpadal se link na ETH. Tak jsem myslel ze je na 411 vadnej port, protoze ani natazeni noveho kabelu nepomohlo. Tak jsem tam dal 911 ale problem se objevuje stale. Narusta RX FCS errors ale link uz je stabilni. Ve finale se to projevuje packetlostem. Switch jsem tam mel predtim u ty 411 a nepomohlo to. Ted uz me napada jedine vadnej port na 2011, nebo nejaka zavada na portu v PoE panelu.

A jak vypadá trasa toho kabelu? Není tam někde delší souběh a NN,VN, nejakym měničem apod?

Nám se tohle dělo na halách pri delším souběhu se silařinou.

Soubeh tam neni, je to cca 8 kabelu natazenych na vytahove budce venku v liste. Ale problem je jen na tom jednom a i kdyz jsem tam natahl jinej provizorni tak byl vysledek stejnej.

Zkusil bych FTP kabel a na jedne strane prizemnit na PEN

tedy nevím jak je to moc normální ale mám vůči dialovskému switchy a naší bráně cca 1473 dropů na 4540 GB je to normální? errory žádné, kabel je stíněný z výroby.

tedy nevím jak je to moc normální ale mám vůči dialovskému switchy a naší bráně cca 1473 dropů na 4540 GB je to normální? errory žádné, kabel je stíněný z výroby.

máme tak, ale jen na RX. 29427 drops / 150573GB

mám také jen na Rx ale asi to je tím že ta druhá strana neumí počítat?

nastává otázka čím to je že ty dropy v znikají...

RX drops by mělo znamenat, že síťovka do svého hardwarového bafru přijala paket OK, ale nestihla ho dostat do paměti počítače pro přetečení toho kruhového bafru, takže nějaký krátký burst, kdy to DMA nestihlo dostat ven ze síťovky do RAM.

TX drops to počítat umí, je to podobné, že se sestavil komplet paket na odeslání a nestihl se odeslat síťovkou ven na dráty (takže ne, že to jsou chyby oznámené od protitrany na jejim přijmu). Uvidíš je třeba na VLANě, sestavují se pakety na VLAN rozhranní, pak se cpou do síťovky, pokud síťovce odpadne link, tak ty pakety se zahodí a naskočí jako TX drops. Podobně i na dalších místech.

no nastává otázka jeslti to nemá dopad na kvalitu konektivity, ale nikdo si nestěžuje, nicméně lidi na vesnici si pomalu nestěžují na nic, právě proto zde stále všude kvetou 2,4GHz a činské krabičky :)

no nastává otázka jeslti to nemá dopad na kvalitu konektivity, ale nikdo si nestěžuje, nicméně lidi na vesnici si pomalu nestěžují na nic, právě proto zde stále všude kvetou 2,4GHz a činské krabičky :)

tak si spocitej kolik % packetu se to vlastne ztraci. Mne vyslo, ze cca 3 desetitisiciny promile. Takze to je hluboko pod urovni pozorovatelneho vlivu. Subjektivne to poznas IMHO az od urovne jednotek procent ...

Tyhle dropy muzou nastavat casto i v pripadech, kdy na zarizeni jsou spousteny nejake na CPU/OS narocne ulohy (na linuxu trebe reload iptables, tc). Je dobre mit tyhle veci vsechny v grafech (ted hura vsichni psat na support MT, ze to nejde vycitat pomoci SNMP at je tim neotravuju stale jen ja :-) ), aby se dalo urcit kdy k chybam dochazi - pripadne, kdy to zacalo atd.

no tak mi vyšlo podobné procento, tak to tedy asi nebud enic vážného :)

Jak je to s TX drops na VLAN?

Na GW která dělá shaping se nám na každé VLAN se objevují TX dropy. Co to může způsobovat, na co se zaměřit?

GW x86 i5, síťovka SGP-i2, proti CISCO SG300. Skrz jedou VLANy do dalších zařízení po 1Gb linkách na APčka. Něco optikou, něco 80G atd. Na konci zase switch a na něm odtagováno a jede to buď 100Mb nebo 1Gb ethernetem dál.

pokud ty shapery sedi v tech VLANkach, pak by to mohly byt packety zahozene shaperem (plna fronta). Staci porovnat statistiku VLANu se statistikou shaperu. POkud je to treba resit, melo by pomoci prodlouzit fronty

Otázkou je, jestli má smysl ty mizivá promile dropů řešit ...

Jak je to s TX drops na VLAN?

Na GW která dělá shaping se nám na každé VLAN se objevují TX dropy. Co to může způsobovat, na co se zaměřit?

GW x86 i5, síťovka SGP-i2, proti CISCO SG300. Skrz jedou VLANy do dalších zařízení po 1Gb linkách na APčka. Něco optikou, něco 80G atd. Na konci zase switch a na něm odtagováno a jede to buď 100Mb nebo 1Gb ethernetem dál.

mám velmi podobné řešení a drop na vlaně ani jeden, zvláštní...