Jump to content
Калькуляторы

Источник потерь пакетов мистика на участке из трех коммутаторов :-)

Есть участок сети с такой схемой:

DSCN0354_cr.jpg

 

Обратили внимание на потери пакетов во влане управления, условно говоря, между маршрутизатором и коммутаторами 40.6 - 40.11. Начал проверять с разных мест. Обнаружилось...

 

Тестовый ноутбук подключаем к 40.6:

до 40.6 - 40.11 потерь нет,

до 40.2 потерь нет,

до 40.1 потери 5-7 пакетов из тысячи.

 

Казалось бы, проблемы на физике между 40.2 и ядром (у 9924Т нет IP в этом влане).

Однако! Тестовый ноутбук подключаем к 9924T:

до 40.2 потерь нет!

до 40.1 потерь нет!

до 40.6 - 40.11 потери 5-7 пакетов из тысячи.

 

Проверяем одним и тем же ноутом, одним и тем же патчкордом, одними и теми же пакетами по 1000 байт. Например, fping 192.168.40.2 -f -p -t 20 -s 1000 -n 5000. С меньшим размером пакета (например, 56 байт) еще хуже всё, около 1% потерь во влане управления.

На 40.2 настроены только вланы и изоляция (протектед портс в терминологии АТ), никаких функций L3, классификаторов, QoS итп. Суммарный трафик до 40.2 во время проверки не более 60 Мбит.

При этом с 40.2 есть еще несколько веток, до которых потерь нет, и еще несколько веток, до которых такая же картина.

Что интересно, в абонентских вланах на тех же узлах потерь меньше, 1-3 пакета из тысячи, и вроде бы даже почти не ощущается деградация сервиса. Но спать спокойно с такой хренью в сети уже не получается.

 

Any idea?)

Edited by Барагоз

Share this post


Link to post
Share on other sites

Не знаю, как fping, но обычный пинг, если его заставлять кидать пакеты пачками (-f) будет терять ответы, полученые в конце, т.к. завершается после посылки последнего пакета, а не его приема. Чтобы иметь более правильный результат, вы должны указать опции [-w deadline] и [-W timeout] для таких тестов.

 

А вот и еще одно: управящий интерфейс свича (особенно такого дохлого, как 2108 или 8012/8024) вообще-то не обязан отвечать на пакеты без потерь.

У меня нередкая картина, когда des3550, например, теряет до 3% пингов по мониторингу, но клиенты за ним пингуются всегда с 0% потерь.

Share this post


Link to post
Share on other sites

[anp/hsw]

Это всё понятно. На других участках с аналогичным оборудованием и тем же методом проверки потери не наблюдаются.

AT-8012 в норме не теряет пакеты по 1000 байт, просто задержка большая.

2108 - тоже под сотню их в разных частях сети, я знаю их поведение в норме.

 

Тестовый ноутбук подключаем к 40.6:

до 40.6 - 40.11 потерь нет,

Вот этот факт опровергает ваше предположение.

Edited by Барагоз

Share this post


Link to post
Share on other sites

at-9424 имеет гигантский пакетный буфер в 1 мбит (!). т.е. 128кб.

 

и при переходе с сотки на гиг на нем элементарно могут теряться пакеты, при наличии другого трафика. лучше всего проверять пакетами максимального размера (т.е. -s 65000) - потери будут прекрасно видны.

 

ну и да, как уже писали, пинги на пенеджмент ип свича - глупая затея, нужно пинговать девайсы за свичом.

Share this post


Link to post
Share on other sites

 

Any idea?)

 

проверяйте не пингом, а IPERFом каждый отрезок. IPERF, кстати, по TCP вроде заваливал Core2Duo при трафике 600+ Mbps, прям как D-Link на на пинги при 50 запросов в секунду умирал

Share this post


Link to post
Share on other sites

и при переходе с сотки на гиг на нем элементарно могут теряться пакеты, при наличии другого трафика.

Кстати да, до 9924 линк гиговый (SFP-SFP), а к 8012 сотка.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.