Скрипт нагрузочного тестирования для проверки соответствия текущих параметров каналов связи заявленным

[saboteur_kiev]

А почему бы не юзать стандартный iperf, который умеет
1. передавать указанное количество данных в нужную сторону
2. Делать это с указанным количеством потоков
3. Не требовать место под сами файлы, то есть задействовать только те ресурсы, которые мы тестируем — сеть
4. Есть также iperf под windows, то есть это кроссплатформенно

[alexk038]

По поводу iperf за меня очень правильно ответил DmitriyPanteleev.
Для тестирования с помощью iperf нужна ответная часть, которую запустить на имеющемся активном оборудовании не представляется возможным. А вот поддержка SNMP имеется у всех увожающих себя вендоров.
Что касается кроссплатформенности, то существуют генераторы трафика и под Windows, которые запускаются в том числе и из командной строки. Могу поделиться.

[iddqda]

Ну не знаю
Для цели ткнуть носом провайдера в несоответствие bandwidth я поступаю следующим образом:

1. iperf -c -u wan-ip-addr-of-remote-device -t600
   2a. Захожу на observium (cacti, prtg, etc) и смотрю realtime загрузку интерфейса
   2b. Захожу на удаленное устройство ( как правило это джунипер) и смотрю monitor interface

А параметры канала в это время меряются вечными тестами cisco ip sla или juniper rpm с сигнализацией в zabbix

Так как задачу «ткнуть носом провайдера» приходится делать нечасто, то автоматизация мне пока не требуется. Но смысл в том, что iperf на udp никакой ответки не требует. Да без ответной части он не посчитает количество принятых пакетов, но и ваш скрипт эту информацтю не из генератора тянет.

[alexk038]

iddqda, если Вы предлагаете использовать iperf в качестве только генератора трафика, то он на эту роль, думаю, подходит точно также, как и используемый мной udpblast — тут кому что больше по душе, либо кому что быстрее подвернется/подвернулось под руку. Для меня главное, чтобы у iperf была опция по генерации трафика с определенной полосой. Я такую опцию после беглого изучения документации по iperf не нашел, да и в Вашем примере она не указана. Подскажите её, если кто знает.
Без неё канал загрузится под самую полку. Моя же цель была — выявить проблемные каналы на рабочей сети, при этом полного простоя сервисов быть не должно. Для достижения этой цели скрипт загружает каналы не на 100%.
А озвученный Вами способ отслеживания загрузки интерфейса для штучных целей я также применял ранее с некоторыми отличиями по используемому ПО, пока не появилась задача проверить на деградацию более 400-от каналов связи.
Могу поделиться своей статистикой. При ежемесячном запуске ещё не было случая, чтобы скрипт выявил менее 3-4 проблемных каналов.

[iddqda]

Извиняюсь самую главну опцию то и забыл

iddqd@hostname:~$ iperf --help
--
  -b, --bandwidth #[KM]    for UDP, bandwidth to send at in bits/sec
                           (default 1 Mbit/sec, implies -u)

ну т.е. моя команда часто выглядит так:

iddqd@hostname:~$  sudo iperf -u -c $remote-if-addr -b8M -t600

И я не знаю может udpblast и вправду ничем не хуже
просто встал на защиту любимого iperf :)

[alexk038]

В таком случае скрипт будет замечательно работать и в связке с iperf.

[DmitriyPanteleev]

saboteur — в Вашем случае нужна «ответка» с айперфом на той стороне, у автора «ответки» не нужно! Это очень большой и жирный плюс! К тому же он вендоро-независимый, пойдет для тестирования как цисок, так прочих длинков/микротиков. У меня есть скрипт/метод тестирования для цисок на tlc, ему и сервер не нужен, достаточно и маршрутизатора в центре. Но он как уже сказал циско онли. Ещё для мониторинга пропускной способности можно использовать джиттеры, но это опять-таки циско онли:(… Вообщем автору респект и уважуха, а скрипт забрал в «коробочку»:). З.Ы.: Отдельное спасибо что не забыли udp, а то у операторов, часто бывает, что с тсп все норм., а удп зажали под самый ноль:)…

[e1t1]

Джиттер и udp есть респондер для Linux, поддерживает в качестве сервера не только циску но и джун.

[Chosen_One]

Например для Cisco я бы не полагался на пинг. Намеки здесь http://blog.ipspace.net/2009/05/ping-priority-on-cisco-ios.html можно найти. Если вкратце, то роутер по разному обрабатывает обычные пакеты и ICMP.

[alexk038]

Chosen_One, не соглашусь с Вашей позицией относительно ICMP и control plane policy (CPP).
Аргументы: CPP у той же Cisco ограничивают любой не транзитный трафик, адресованный данному конкретному оборудованию. Это может быть не только ICMP. В описанной вами ситуации имеет смысл сконцентрироваться на том, чтобы CPP удаленных роутеров были правильно настоены и не дропали ICMP трафик, который мы отправдяем из скрипта. К тому же объем ICMP трафика от скрипта не большой — периодичность отправки пингов задана всего лишь 1 пакет в секунду. Я не сталкивался ни разу с проблемами отсутствия отклика на ICMP request'ы с такой периодичностью ни у одного из вендоров: Cisco, Juniper, Huawei, Mikrotik.