От няколко дни имаме оплакване от клиент, че има около 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м суичовете почват да правят каквото си поискат.

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

Редактирано от Netwlan на 22.08.03 03:24.

Сървър - Клиент = 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.

Митко