Linux за българи: Форуми

eth0 Link encap:Ethernet  HWaddr 00:30:48:5B:98:3C
       inet addr:XX.XX.XX.XX  Bcast:0.0.0.0  Mask:255.255.255.240
         UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
         RX packets:443806629 errors:0 dropped:9975 overruns:0 frame:0
         TX packets:479485346 errors:0 dropped:0 overruns:0 carrier:0
         collisions:0 txqueuelen:1000
         RX bytes:230740115152 (214.8 GiB)  TX bytes:119473454693 (111.2 GiB)
         Base address:0x4000 Memory:ed200000-ed220000

eth2  Link encap:Ethernet  HWaddr 00:30:48:5B:98:3E
    inet addr:XX.XX.XX.XX  Bcast:0.0.0.0  Mask:255.255.255.224
    UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
    RX packets:671654582 errors:666560 dropped:284781 overruns:0 frame:571079
    TX packets:568788467 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:1000
    RX bytes:270159624112 (251.6 GiB)  TX bytes:376146392033 (350.3 GiB)
    Base address:0x6000 Memory:ed400000-ed420000


Та проблема ми е като ми се дигат dropped: пакетите , не мога да разбера каде е причината за да дропва толкова много пакети , Машината се държи странно дига авеража си и пинга се дига към 20 30 мс понякога губи пакети ...
Някой може ли да ме насочи към някакво решение на този странен проблем ..
Благодаря ви предварително!

Dropped по принцип означава че ядрото няма свободна памет за sk_buff структури. Това се променя лесно ако вдигнеш стойността на /proc/sys/net/core/netdev_max_backlog. Дори ако няма особено интензивен трафик, може да се случи така че заради шейпингът да се случат мизерии. Когато този буфер се препълни, ядрото почва да дропи пакети докато не се изпразни.

Errors обаче е нещо по-интересно. Ако пейстнеш и съдържанието на /sys/class/net/eth2/statistics/rx_* може да се каже повече. Според мен в мрежата на която е закачен този интерфейс (eth2) има някакъв хмм хардуерен проблем, но без да видя какви точно са грешките нямам мнение по въпроса.

Frame errors обикновено иде реч за етернет фреймове със "счупен" хедър или прекалено малки (по-малки отколкото самият хедър) и обикновено говорят за разни много неприятни проблеми в мрежата - или проблеми с кабелите или проблеми с някоя станция дето праща прекалено глупости.

Аааа, това 64-битова машина ли е? Защото броячите за статистики на интерфейсите гледам че вадят стойности над 4 ГБ ?

Да 64 битова е
cat /proc/sys/net/core/netdev_max_back 1000

/sys/class/net/eth2/statistics/cat
multicast 3773
rx_bytes 616931531120
rx_crc_errors 571292
rx_errors 666807
rx_missed_errors 425190
rx_packets 1426991373
tx_bytes 797861425464
tx_packets 1190770525

Другите са с нулеви стойности а по принцип нямам шейп на тази машина бих казал че проблема не е хардуерен понеже съм подменял всичко наред машини сучове карти .. по скоро ме съмнява че имам проблем с вирусите и паразитният трафик.. По принцип се получава вечер когато има доста народ из мрежата и когато dropped и frame стойностите на етх2 започнат да скачат , когато всичко е нормално пак вечер dropped и frame изобщо не мърдат ..

Все пак вдигни netdev_max_backlog - спокойно ако имаш памет може да бъде да речем 20-30000, не е казано че трябва да идва от шейпингът (а и там е частен случай) - ако просто се форуард-ваш голям трафик, не е изключено да се случи. На практика няколко човека отзад да почнат да дърпат един повече сийднат торънт и това може да се случи.

Другите грешки - щом не идват постояно може да се заключи че проблемът със сигурност не е в окабеляването или картата/драйвера на етернета на конкретната машина. Аз бих предположил че някой от клиентите ти има проблеми с мрежовата карта или кабела си и бих тръгнал един по един да ги вадя и пускам от суич-а докато стане ясно кой е виновния. Естествено, възможно е да идва и от самият суич, чиито порт прави мизерии, въпреки че е много трудно със "store&forward" суичовете (а и особено ако е клиентски проблем).

Ако трафикът не е наистина много голям, можеш да пробваш следното: обикновен 5-портов store-and-forward switch не струва кой знае колко пари. Тези суичове не форуард-ват голяма част от грешните етернет фреймове. Вземаш един такъв и го връзваш между eth2 и суич-а, в който е вързан - грешките трябва да намалеят драстично, както и "напрежението" върху ядрото идващо от дропене на грешните пакети. За жалост ако суич-а е прекалено прост и си няма достатъчно памет, а трафикът е обемист, може суич-а да почне да забива.

Такива неща се случват и за жалост в една по-голяма мрежа изключително трудно се намира източника им.

От вирусен/паразитен трафик е почти невъзможно да се случи това, 99.9999% от вирусите работят на ниво layer3, надали има вирус който да се опитва сам да си сглобява етернет фреймове (изземвайки тази функция от мрежовият драйвер)...най-малкото защото ще е ефективен в рамките само на конкретния етернет сегмент, както и защото ще му се наложи да подържа голям набор мрежови карти. Такъв вирус ще е жив уникат

Възможно е и проблемът да идва от бъг-нат драйвер за мрежова карта на някой от клиентите ти навързани отзад.

Проблем може да стане ако имаш някъде бридж-нат 802.11 аксес пойнт или карта. Тяхното дефолт-ско MTU е над 1500 и ако не се смъкне, това води до проблемни комуникации и много сгрешени фреймове.

Ако някой потребител по някакъв начин е успял да си вдигне MTU на мрежовият интерфейс над 1500 резултатът ще е подобен предполагам.

Щом такива сгрешени фреймове пристигат при теб значи поне този суич, на който е навързана машината ти е с cut-through. На такива суич-ове проблемът им е че препращат всички сбъркани фреймове.

Аз имам на един рутер високи стойности на rx_missed_errors. Дали при увеличаване на буферите ще се оправи?

Не. Може да пробваш да увеличиш RX ring size, който има отношение към проблема (ethtool -G ethX rx <rxring_size>). Ако позволява.

Шибаното в случея е че имам едни 1500 човека и трудно се ровят в случея , но всички са наврени в 2 суча Linksys SRW тъпото е че като почна да вадя определени точки от около 50 100 абоната 1 по едно , не се оправя ,.. А възможно ли е да се получава от късо кабелче , м-у единия и другия имам 5 санта кабелче което малко ме съмнява , подмених го с метър ще видя дали ще има промяна

Никога не съм виждал такива суичове, из гугъл изпаднаха някакви managed layer3 дивни (!!!, можеш ли да ми пейстнеш конкретният модел моля?

Linksys SRW2024 може и да съм объркал някаде

Да само такива ползвам и всичко в тази машина влиза и излиза през linksys и те .. Колкото до машината е нова някаде на 1 месец Supermicro  - PDSMi-LN4 4x Intel® 82573V/L PCI-e Gigabit LAN Ports
Но на предната имах мисля същият проблем .. за сега няма дерт вече 3 ти ден , кофти че го прави рядко и не мога да разбера дали е ок или не ..

Тази вечер се получи отново , вадих кабели на поразия сменях суичове , сменях мрежовата карта с друга , нищо чак след ребоот тръгва напълно нормално без изобщо да има някакъв проблем
Лошото е че каквото и да правя то просто си остава в същото положение докато не ребоотна машината ..

Остава вариантът драйвера за тази карта да прави мизерий, не е рядкост, още повече че си на x86_64, а тази архитектура не е толкова тествана като x86. Въпреки че е странно след като на предишната ти машина е ставало същото..Там същата ли беше мрежовата карта?

БТВ с коя версия на ядрото си и с кой драйвер подкарваш тази интелска джаджа? e1000 ? Може да се разтърся за разни проблеми с тази карта ако имам време. Имам опит предимно с broadcom и такива с marvell-ски чипсет гбици, нямам с интелски, та знам ли дали няма да се натреса на нещо такова и аз...

Бтв имаш ли в dmesg съобщения от сорта на "eth2: too much work at interrupt..." ?!?

Ами предната машина беше на x86 и мисля че пак беше интелска карта с #lsmod | grep e100
e1000                 121784  0
2.6.17-2-amd64

Цитат

Бтв имаш ли в dmesg съобщения от сорта на "eth2: too much work at interrupt..." ?!?

Мне нямам , никакви грешки нямам ..
Не знам , то се намен ми се случват странни работи , направо голям карък съм

Май проблема ми е че нямам хардуерен рутер някакъв лейър3 суич ако си взема мисля че ще ми реши проблема , понеже машината се води гейт и само рутирва и нищо друго не прави , аз на това и се чудя какво пък толкова се товари в крайна сметка ... авеража по принцип е 0,1 0,3 не повече , но почне ли с дропед пакетите се качва до към 1 1,5 .. ето в момента е най натоварено и няма никакви проблеми а преди 3 ,4 часа трябваше да ребоотна ..

Силно много вярвам че линукс е една достатъчно добра платформа за такива цели, да не говорим че хардуерът ти е доста силен. Не казвам че цицковските решения нямат много предимства дори от архитектурна гледна точка, но според мен не си заслужава. Да не говорим че ако в крайна сметка проблемът се окаже все пак в суича или пък от тривиална причина от сорта на "две устройства ползват един и същ IRQ" или пък оттам че драйверът за контролера в тази версия на ядрото бил бъглив...купуването на някакъв catalyst с гбитови портове или някакво друго подобно дзверище ще се окаже един грозен разход.

Никога няма да тръгна да адвокатствам на цицко, за мене лично те са доста по-противни от Майкрософт, от друга страна няма да отрека че имат доволни предимства (нямат ядро дето да се занимава с 5000 юзърспейски глупости, зад всеки порт стои един приятен чип дето прави и суичинг и фрагментация и дори филтъринг на фреймове/пакети, и влан сметки, имат бърза шина до процесора - съмнително колко по-бърза от pcix всъшност), но....това са разходи, които в този случай не е много ясно доколко са оправдани.

Да не говорим че тази гадост трябва да се конфигурира, нещо доста досадно за човек дето не им е свикнал на странностите.

Да ма логика в цялата халва но в случея направо не знам какво да правя и този факт ме дразни

А има ли начин по който да изчистя тези статисттики

Цитат

RX packets:340013797 errors:1 dropped:52253 overruns:0 frame:1

Или да flush по някакъв начин , понеже колкото и да събарям интерфейсите си остава така , флашвам иптаблес ипроуте ип а махам всичко и като го дигна на ново все си стоят ..

Ахъм, rmmod module;modprobe module

Ако не са на модули, а в ядрото...друг вариант освен reboot няма.

Съвсем случайно попаднах на един пич с друго супермикро
ето линк я погледни , дали в случея може да помогне ?

Аз преди писах за един проблем с е1000, но не си спомням дали имаше дропнати пакети:

http://www.linux-bg.org/cgi-bin....ethtool

Ти имаш ли такива ARP пакети?

Доколкото разбирам не са арп-та, а pause frames. В http://standards.ieee.org/regauth/ethertype/eth.txt ги няма (?!?), следователно това вероятно е някакво странно интелско решение Служат за реализиране на някакъв flow control (т.е като се напълнят буферите на картата за RX се изпраща един такъв фрейм който информира останалите да спрат да пращат, блабла). Не мисля че са проблемни.

Абе като чета и други хора се оплакват от подобни проблеми с такава карта по разни мейлинг листове. Там понякога ги съветват да си включили rx/rx pause. Не става ясно дали това решава проблема обаче де...бахти странната работа

Така, де - прав си, имах предвид, че са до този MAC адрес.
Иначе ги има в този списък:

Цитат

8807 - 880A  IEEE 802.3                                                    Protocol unavailable.              Bay Networks              PO Box 58185, M/S SC01-05              4401 Great America Pkwy, Santa Cla CA 95052-8185              UNITED STATES

А за този адрес дават:

Цитат

01-80-C2-00-00-01   -802-   802.1 alternate Spanning multicast

в http://standards.ieee.org/regauth/ethertype/eth.txt

Сега ползвам Broadcom и нямам много проблеми с тях.

Добро обяснение за PAUSE FRAMES намерих в http://www.techfest.com/networking/lan/ethernet3.htm
макар, че на пракитка не ми помогна много.

В конкретният случай обаче...не виждам как flow control-а ще помогне, а и все пак трябва да се подържа от двете страни. Ако никой от другата страна не се сети да спре да предава когато го получи файдата е никаква.

Абе..и щом процесорната утилизация му скача много, предполагам процесора зацикля в обработването на прекъсвания. Когато на един процесор му дойдат прекалено много, дори да се буферират получените пакети, с тази скорост на получаване се стига до момента в който се дропят пакети, поради невъзможност процесора да ги обработи и поради огромния натиск от нови такива върху интерфейса.

Дали NAPI не е крайното решение? Едно е да обработваш хиляди прекъсвания в секунда, съвсем друго е да обработваш не повече от стотина...

Благодаря ви за отделеното внимание и съжелявам че ви занимавам с глупости общо взето
За сега всичко върви нормално добавил съм в sysctl.conf
net.core.rmem_default = 524287
net.core.rmem_max = 1048575
net.core.wmem_default = 524287
net.core.wmem_max = 1048575
net.ipv4.tcp_wmem = "4096 16384 524288"

echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter

Но като цяло мисля че някой по скоро е правил някакви мизерии , не може 3 дена да работи на 6 на най голямо натоварване и 2 дена след това да го прави ден след ден при положение че натоварването на мрежата е по малко от предните дни. Ако разбера какво точно е пак ще пиша
Пак ви благодаря !