iddqda, если Вы предлагаете использовать iperf в качестве только генератора трафика, то он на эту роль, думаю, подходит точно также, как и используемый мной udpblast — тут кому что больше по душе, либо кому что быстрее подвернется/подвернулось под руку. Для меня главное, чтобы у iperf была опция по генерации трафика с определенной полосой. Я такую опцию после беглого изучения документации по iperf не нашел, да и в Вашем примере она не указана. Подскажите её, если кто знает.
Без неё канал загрузится под самую полку. Моя же цель была — выявить проблемные каналы на рабочей сети, при этом полного простоя сервисов быть не должно. Для достижения этой цели скрипт загружает каналы не на 100%.
А озвученный Вами способ отслеживания загрузки интерфейса для штучных целей я также применял ранее с некоторыми отличиями по используемому ПО, пока не появилась задача проверить на деградацию более 400-от каналов связи.
Могу поделиться своей статистикой. При ежемесячном запуске ещё не было случая, чтобы скрипт выявил менее 3-4 проблемных каналов.
Chosen_One, не соглашусь с Вашей позицией относительно ICMP и control plane policy (CPP).
Аргументы: CPP у той же Cisco ограничивают любой не транзитный трафик, адресованный данному конкретному оборудованию. Это может быть не только ICMP. В описанной вами ситуации имеет смысл сконцентрироваться на том, чтобы CPP удаленных роутеров были правильно настоены и не дропали ICMP трафик, который мы отправдяем из скрипта. К тому же объем ICMP трафика от скрипта не большой — периодичность отправки пингов задана всего лишь 1 пакет в секунду. Я не сталкивался ни разу с проблемами отсутствия отклика на ICMP request'ы с такой периодичностью ни у одного из вендоров: Cisco, Juniper, Huawei, Mikrotik.
По поводу iperf за меня очень правильно ответил DmitriyPanteleev.
Для тестирования с помощью iperf нужна ответная часть, которую запустить на имеющемся активном оборудовании не представляется возможным. А вот поддержка SNMP имеется у всех увожающих себя вендоров.
Что касается кроссплатформенности, то существуют генераторы трафика и под Windows, которые запускаются в том числе и из командной строки. Могу поделиться.
Без неё канал загрузится под самую полку. Моя же цель была — выявить проблемные каналы на рабочей сети, при этом полного простоя сервисов быть не должно. Для достижения этой цели скрипт загружает каналы не на 100%.
А озвученный Вами способ отслеживания загрузки интерфейса для штучных целей я также применял ранее с некоторыми отличиями по используемому ПО, пока не появилась задача проверить на деградацию более 400-от каналов связи.
Могу поделиться своей статистикой. При ежемесячном запуске ещё не было случая, чтобы скрипт выявил менее 3-4 проблемных каналов.
Аргументы: CPP у той же Cisco ограничивают любой не транзитный трафик, адресованный данному конкретному оборудованию. Это может быть не только ICMP. В описанной вами ситуации имеет смысл сконцентрироваться на том, чтобы CPP удаленных роутеров были правильно настоены и не дропали ICMP трафик, который мы отправдяем из скрипта. К тому же объем ICMP трафика от скрипта не большой — периодичность отправки пингов задана всего лишь 1 пакет в секунду. Я не сталкивался ни разу с проблемами отсутствия отклика на ICMP request'ы с такой периодичностью ни у одного из вендоров: Cisco, Juniper, Huawei, Mikrotik.
Для тестирования с помощью iperf нужна ответная часть, которую запустить на имеющемся активном оборудовании не представляется возможным. А вот поддержка SNMP имеется у всех увожающих себя вендоров.
Что касается кроссплатформенности, то существуют генераторы трафика и под Windows, которые запускаются в том числе и из командной строки. Могу поделиться.