Много странен LAN проблем

От няколко дни имаме оплакване от клиент, че има около 2% загуба на пакети в едно кабелно трасе. Когато го тестваме от нашата страна, всичко изглежда перфектно. Когато го тестваме от него, наистина има загуба. Ето каква е схемата:

Клиент ---- Междинна Точка (МТ) ---- Сървър

Междинната точка е суич, в който включваме компютър, за да можем да го пингваме. При клиента слагаме наш компютър, за да няма съмнение в хардуера или софтуера. Сървърът е с най-бърз процесор, после е МТ, най-бавен е компютърът при клиента. ОС е Linux 2.4.20 навсякъде, а платките са Intel PRO100 (т.е. всичко е еднакво). Резултатите от ping flood с малки и големи пакети (минимум 5000 пакета) са следните:

Сървър - Клиент = 0% загуба
Сървър - МТ = 0%
МТ - Клиент = 0%
MT - Сървър = 0%
Клиент - MT = 0%
Клиент - Сървър = 2%

Няма грешка - всичко е повторено поне 10 пъти. Трасето изглежда перфектно, с изключение на случая, когато ping-а се пуска от клиента директно към сървъра. Ако клиентът беше по-бърз от сървъра щеше да има логика, но е обратното.

Някой има ли предположение на какво може да се дължи такава асиметричност? Дори да има асиметричен маршрут (а такъв няма), то броят на ECHO_REQUEST и ECHO_REPLY винаги е еднакъв и винаги еднакво количество пакети ще минат през всеки маршрут, независимо кой е инициатора. Аз честно казано не виждам от какво може да се породи подобен (де)фект и ако накрая не го бях изследвал лично, щях да кажа, че няма такова животно.

Единственото обяснение е, че времето между ECHO_REQ i ECHO_REP e по-малко, отколкото между ECHO_REP и следващия ECHO_REQ. Възможно е някой суич да работи в действителност на half-duplex и времето му за превключване предаване-приемане да е по-голямо, отколкото приемане-предаване. Някой сблъсквал ли се е с нещо подобно?

Митко

parvoto neshto koeto bih opital e da smenia switcha..


Pozdravi,
Pepi

nie imahme drug stranen problem. edin klient ima6e MREJA samo ve4er ot razli4ni 4asove do sutrinta pak v razli4no vreme.. nikoi nqma6e dostup do switch-a. smenihme switch-a i se opravi... dosta stranno. probvaite da smenite switch-a(ovete)

The Real Net - The Real Internet Provider
[линк]

имаш ли възможност вместо суич да сложиш комп с 2 лан карти и да прекараш трафика през него? така ще можеш да събереш още малко инфо...

TANSTAAFL! There AiNt Such Thing As A Free Lunch

Според мен, това може да стане когато трасето клиент-МТ работи на full duplex , а МТ-сървър на half duplex.
Със сигурност става когато клиент-МТ е на 100М , а МТ-сървър на 10М.

Това е когато switch-a e със store and forward, просто не успява в едната посока и дропва пакети , в другата посока няма проблеми.

Сложи на междинната точка един хъб и ако проблема изчезне това означава, че проблема е бил в дуплекса на суича към сървъра. Предполагам вече си пробвал да смениш суича и проблема е останал за това ще е най добре да погледнеш ако постановката е такава каквато си я нарисувал, а не е просто участък от по-дълга мрежа драйвера на интелската карта за сървъра.
Ако е участък от по-дълга мрежа проблема може да идва от неразбирателство между сучове например суич с реалтек чипсет примерно QUBS не се разбира с 3сом. И не на последно място дължината на кабелите над 120м суичовете почват да правят каквото си поискат.

Добрия Интернет струва пари!!!

Сървър - Клиент = 0% загуба
Сървър - МТ = 0%
МТ - Клиент = 0%
MT - Сървър = 0%
Клиент - MT = 0%
Клиент - Сървър = 2%

Ето в тия тестове мисля, че се вижда проблемът... Локализира се в едната посока при преминаване през суича. Предполагам, че сте опитали различни портове, а друг суич?

Резултатите от тия тестове противоречат на логиката, така че нищо не може да се види.
Аз имам подобен проблем, но ситуацията е по-проста (PC<-->switch<-->PC), затова успях да установя, че проблемът идва от невъзможността за правилно договаряне на half/full duplex между едната лан карта и switch-а.
Затова мисля, че идеята на Netwlan за проба с hub е най-добра. Предполагам обаче, че в посочената ситуация има още устройства (switch-ове, PC-та), така че едва ли е толкова лесно да се направи нормален тест.

И аз щях да си го помисля, ако връзката МТ-Сървър беше по-бавна от Клиент-МТ. Но е точно обратното. Клиент-МТ е 100, а МТ-Сървър е 1000 (1GB). Логично е загубата да се появява при преход от по-бърза към по-бавна среда, а не обратното. И точно затова съм толкова озадачен.

Тук чух съвети да сменя суича. Ако беше само един - да съм го сменил. Общо по това трасе има десетина суича. Ако от междинната точка до който и да е край даваше загуби, щяхме да намерим проблемния суич по метода на двоиното търсене. Но и в двете посоки връзката от МТ е перфектна ...

Митко

Ама там е работата, че посока всъщност няма. Ping е двупосочен и симетричен - изпраща пакет (REQ) и после (не) го получава (ACK). Това, че се губят пакети при пинг от Клиент към Сървър по никакъв начин не означава, че те се губят точно в тази посока. Може да се губят отговорите, които сървърът изпраща в отговор на запитванията. И възниква въпросът защо при смяна на инициатора няма загуба в нито една от посоките.

Това, което не мога да си обясня е каква всъщност е разликата в потока данни когато А праща пинг към Б и когато Б праща към А. На теория не трябва да има никаква разлика, но очевидно има. Ако беше тривиално, нямаше да питам. Това е все едно крокодилът да е 2 метра от опашката до главата, а от главата до опашката да е 2.20.

Митко

Да де, това е ясно, казах го чисто фигуративно за яснота. Мисълта ми беше, направихте ли простата проба със смяна на портовете и евентуално на суича?
Също - увеличават ли се загубите при по-големи пакети или са пак толкова?

Размера на пакетите е без значение. Суичовете са много, така че априори не е ясно кой трябва да бъде сменен.

Митко

Mitko probva li da izkluchish traseto sled klienta demek klienta da ostane sam na tozi swich. Imali sme sluchai edin swich da ebava cialoto trase .
A i kakto kazaha kolegi dyljinata na kabela igrae goliama rolia ako e natovareno traseto i kabela e dylyg stava kofti . Probvali sme 130m kabel ftp markov sys ured na Fluke i toi ne pokazva che ima kabel (a kabela se vryzva mejdu swichove uj na 100 mb).Kakvo li ochakvame posle da mine po kabela ?

Няма дълга стъпка. Освен това трасето работи перфектно, когато тестовете се правят от другаде. Т.е. проблемът 1000% не е кабелен.

Митко

Do kolkoto vidqah ot dopulnitelnata informaciqa koqato dade traseto e dulgo tova me navejda na misulta che imash i razklonenie nqakude predi klienta i nai veroqatno problema e tam swicha na razklonenieto e nai veroqatniqa prichinitel na anomaliqata...
Eto ti i otgovor zashto ima razlika mejdu echo request i echo replay:
Natovarvaneto v posoka server --> klient e mnogo po golqamo ot tova v obratnata posoka poradi estestvoto na interneta vsichki downloadvat malko uploadvat..
Tochno za tova se gubi ne echo request, a echo replay pri ping klient-->server..
Ako ima razklonenie tursi problema v tozi swich ako nqama takova e prosto nesuvmestimost na dva swicha tozi pri klienta i tozi predi nego...

Добрия Интернет струва пари!!!

Независимо в коя посока е натоварването, винаги ще се губи пакет. В единия случай ще се губи echo request, а в другия - echo reply. И в двата случая ping ще покаже загуба. Така че разликата не може да е в посоката на трансфер на данните - при пинг трансферът е ЕДНАКЪВ в двете посоки. Има някакво разминаване във времената / времезакъсненията, но не мога още да го усетя какво и защо.

Митко

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

Добрия Интернет струва пари!!!

Mitko kakvo imashe predvid kato kaza che Klient->Switch e 100Mbit a
Switch->Server e 1000Mbit cqloto trase mejdu switchovete li e 1000Mbit ???
Zashtoto ako e taka ne mojah da razbera zashto tuka vidqh idei da se sloji HUB...

I pri mene sa se sluchvali mnogo takiva problemi (tochno kato tozi ne) no vinagi sam se opravql sus smqna na ustroistva i portove :)

Kolkoto Poveche - Tolkova Po-Veche

Както и да е. Явно не ми се отдава да обясня, че независимо дали клиентът праща въпроси (когато той пингва) или праща отговори (когато него го пингват), маршрутът е абсолютно еднакъв. Каквото и да му е сбъркано на посоката, суичът не може да разбере дали пакетът е REQ или REP, за да го третира различно.

Да предположим, че трасето е сбъркано в посока Клиент->Сървър и троши 2% от пакетите, минаваши в тази посока. Да допуснем също така, че в другата посока няма загуби. Да разгледаме двата възможни случая:

1. Пускаме пинг със 100 пакета от К към С. Тази посока е скапана и някой суич или кабел счупва 2 от въпросите (REQ). В резултат на това С връща към К само 98 отговора (на 98 получени въпроса им се полагат ни повече ни по-малко от 98 отговора) и понеже посоката С->К е здрава, всичките 98 отговора стигат до К. Пингът, обаче, отчита 2% загуба, защото е пратил 100, а е получил 98.

2. Пускаме пинг със 100 пакета от С към К. Трасето в тази посока е перфектно и всички REQ стигат до К. Той изпраща своите 100 отговора, които вървят в посока от К към С. А в тази посока, както сме допуснали, някой скапан суич или кабел счупва 2 от тях. Сървъра получава само 98 отговора на своите 100 въпроса и пингът отново отчита 2% загуба.

Следователно проблем в ЕДНАТА посока на кабела се отразява на пинга и в ДВЕТЕ. А моят пинг в едната поска е перфектен - 20 хиляди пакета ОТИВАТ И СЕ ВРЪЩАТ без нито един загубен. А в другата се трошат. Тук се получава едно терминилогично объркване - когато говоря за "посока" на пинга имам предвид не посоката на данните (защото такова понятие при пинг няма - данните се движат и в двете посоки еднакво), а имам предвид кой изпраща REQUEST и кой изпраща REPLY.

Явно ситуацията е толкова странна, че ми е трудно не само да я разбера, ами дори да я обясня. Явно е някаква изключително рядка несъвместимост между две (или повече) устройства, която се проявява чрез нещо, което мога да нарека "цифрова интерференция". Т.е. един процес оказва странично влияние на друг процес. Май трябва да се откажа да се опитвам да разбера какво се случва и просто да започнем подмяна на всички устройства.

Митко

P.S. Никакъв кабелен проблем или проблем сус суич не може да обясни защо от
междинната точка всичко е перфектно и към двата края, без значение от посоката на тестовете. В крайна сметка нали точно така се търси къде е проблемът - тръгваш наред по суичовете и тестваш двете посоки - към клиента и към сървъра. И ако установиш, че и двете посоки са наред, а въпреки това цялото трасе не е, не ти остава нищо друго освен да запалиш свещ, да се помолиш, или да идеш на врачка - така или иначе логично обяснение май няма да се намери.

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

Митко