Добрый день

Существует ли прошивки для L3 коммутаторов 34хх и 36хх серий, в которых:
- была бы возможность выполнения flood ping с гораздо большим фиксированным числом пакетов, нежели стандартно предлагаемые 255
- была бы возможность регулирования интервала следования пакетов с интервалом менее 1с;
- выполнялся более компактный вывод результатов работы

Т.е., реализация ping-а, подобного реализации в Cisco

А какое обоснование данного запроса?

_________________
С уважением,
Бигаров Руслан.

Тест должен воссоздавать условия для тестового трафика, максимально приближенные к реальному. В конкретном случае, этого нет, поскольку сложно себе представить порт 1Гбит/с (не говоря уже о 10Гбит/с порту), на котором бы средняя скорость пакетов составляла 1пакет/с. Текущая реализация теста может использоваться для выявления полного отсутствия связи, либо большого процента потерь, однако бесполезна для выявления никих процентов потерь, либо тестирования нагруженных каналов

Тестирование использованием всего 255 пакетов позволит выявить постоянные и высокие потери. Если же говорить о потерях до 1% (либо 1-2%, которые при этом не являются постоянными), вероятность того, что потеря будет выявлена в той реализации пинга, которая есть (всего 255 пакетов и здержка 1 секунда) крайне низка (ибо может либо не попасть в этот интервал, либо "пройти" между двумя пингами).

Тестирование же с задержкой менее 1с, как вытекает из написанного выше, как раз и позволяет выполнять тестирование канала более интенсивно

Более компактный вывод результатов работы необходим для того, чтобы вывести те же 1000 или более пакетов таким образом, чтобы получить представление не только о проценте потерь, а и о характере потерь (я так понимаю, не стоит объяснять, что только по характеру потерь (их распределение в общей посылке пакетов) и времени откликов можно отличить реальную потерю от срабатывания полисеров/шейпов)

На практике, выявление низких и непостоянных процентов потерь может требовать запуска последовательности пингов до 10,000 шт при задержке между пакетами от 1мс

Совсем неслучайно подобный функционал реализован в Cisco и подобного уровня оборудовании и ещё более неслучайно его "перетягивают" к себе ближайшие конкуренты Dlink

Уважаемый _AndreyS_
похожий функционал есть на серии DGS-3610.

Можно поподробней про


На каких моделях cisco и каким образом это настраивается?
Имеется ввиду задержка между отправляемыми пакетами...
если можно пример...

Спасибо, Максим. То, что надо (правда, 10G портов на 3610 маловато)
Планируется ли внедрение данного функционала и для DGS-3627, например? (либо, возможно, это уже есть в новых прошивках)




У Cisco задержка между пакетами не настраивается - используется ping без задержки, но, если данный функционал проблематичен (а, вероятно, он как минимум ресурсоемок), - устраивает с задержкой, но никак не с 1с

Андрей.

На основании чего вы решили, что в оборудовании d-link есть какая-то задержка?
Как только пакет сформирован, он тут же и отправляется, а если сказать точней, то посылаются его дупликаты в нужном количестве, для минимизации этой самой задержки т.е. время при отправлении пакетов в пределах 1 миллисекунды и менее...если конечно cpu не занят чем-то более важным...
Данный функционал на оборудовании любого вендора существует для тестовых целей...если оборудование под нагрузкой, то использовать этот функционал не рекомендуется по вполне понятным причинам, проще воспользоваться спецально выделенным для этого оборудованием типа PC или трафик генератором.

Например, берем DGS-3612G... (это чтобы не отходить от того оборудования, что было обозначено изначально - только 34хх и 36хх серии. Хотя, подобное поведение наблюдается и на другом оборудовании)
Коммутатор в принципе ничем не нагружен - стоит на столе на тестах с единственным линком для тестов пинга. Пингуем ip адрес на тестовом компьютере, который подключен к коммутатору. Коммутатор отправляет пакеты со скоростью 1 пакет/с, при том, что ответы получаем, как заявляет коммутатор с задержкой "<10мс"
Предположил, что оборудованию просто нечем заниматься при отсутствии трафика, - отсюда и сообщение о задержке. Ошибался и оборудование умудряется себе найти занятие при отсутствии трафика?


Максим, а вы уверены в написанном? Посмотрите в tcpdump трафика при пинге (это уж если опустить тот момент, что дубликат пакета в сетях, как правило, свидетельствует о проблеме в сети и как-то ну совсем не верится, чтобы у кого-то из разработчиком Dlink появилась хотя бы мысль решать задачу подобным образом). Обратите внимание на sequence number в "дубликатах" ICMP пакетов

Уважаемый Андрей.

Проверил...
для серий 34xx и 36xx действительно есть данное ограничение, т.е. задержка в 1с между пакетами,
для серии 3610 такого ограничения нет....т.к. отвечаю только за старшую линейку, то не знал что оно есть.
тут был не прав...
но не считаю этот функционал на коммутаторе мега-необходимым...для генерации тестового трафика есть PC и другие специализированные устройства



Ну а что по вашему мешает получить ему ответ за это время???


Андрей, я в подавляющем большинстве случаев уверен в том, что пишу... если вам не понравилось слово дупликаты (вы его посчитали неточным), скажу по-другому, если вы тоже внимательно смотрели на tcpdump то инкрементятся только 2 поля и только на единицу при каждом последующем пакете, так зачем формировать пакет заново если можно в сформированном в буфере памяти пакете сделать инкремент счетчиком на единицу этих 2х полей и отослать, конечно же лучше сформировать пакет заново и потом отправить, отличная идея, процессор мощный он все выдержит.


мысль появлятся как раз потому, что инкремент на единицу

подобный ответ уже был получен, однако в отношении L2, L2+ устройств. Но это было хоть как-то не могу сказать, что понято, но принято. Но когда речь идет о L3... Прошу прощения, но в таком случае польза от L3 вообще непонятна: берем L2 коммутатор (даже не L2+), в пару к нему PC и не нужна нам L3 линейка Dlink оборудования вообще. И эффективнее и, что главное, - дешевле.

Опять же: вы сами говорите о том, что этот функционал предназначен для тестирования, но в нем вы не видите необходимости в 34хх и 36хх сериях. Странно всё это... странно и непонятно, поскольку, если говорить об оборудовании 34хх и 36хх серий, то это уже не SOHO оборудование и, соответственно, тешить себя надеждами, что "офис маленький, требования небольшие, поработают и так" вряд ли стоит (тем более, что речь не идео о позиционировании данного оборудования для офиса). При том, что Dlink в L3 оборудовании совсем не радует ценами, если и функционал не будет развиваться - можно лишь поблагодарить за информацию и плодотворное сотрудничество Dlink, как производителем используемого ранее оборудования


В какое время (990мс оборудование "думало", прежде чем отправить новый пакет) и вообще о чем речь, если отправка пакетов раз в секунду для оборудования 36-й серии (кроме 3610) вами признана?


да без проблем - только это уже не дубликат

Андрей вы знаете как работает ping?

Очень подробно по шагам:

1) Я отправляю первый пакет с коммутатора до какого-либо устройтства (после этого секунда молчания)
2) Устройство мне отвечает с задержкой 10 мс...
3) Через секунду молчания я отправляю 2 пакет с коммутатора до того-же устройства
4) Устройство мне отвечает опять с задержкой 10 мс
5) ......

т.е. время между отправлением пакета и получением эха 10 мс
это время никак не связано с временем 1 с

так понятней?

Что кассается замечаний, ваш выбор - ваше право.

НО.

Во 1х этот функционал, который вы упомянули есть в оборудовании старших серий 3610.
Во 2х судя по тому что вы писали выше, вы хотите чтобы оборудование было трафик-генератор+коммутатор 2 в одном "флаконе".
В 3х функционал можно попробовать обсудить...
В 4х ценами мы как раз всегда всех радовали, а уж что касается быстроты реакции на реализацию обоснованно востребованного функционала у нас оно на порядки быстрей нежели у конкурентов, люди не дадут мне соврать...

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

увеличить число пакетов и уменьшить задержку между пакетами не должно составить большого труда, но гораздо приятнее получать результат с точностью до сотых долей процента за десять секунд, чем иметь текущий "плюс-минус процент" (слегка преувеличено ) за 4 минуты

_________________
Это текст, который можно добавлять к размещаемым вами сообщениям. Длина его ограничена 255 символами.