Как проверить скорость канала связи при наличии сервера на FreeBSD и роутеров cisco?
Добрый день!
Есть у меня по области около 2000 роутеров. Основная масса - производителя cisco. У всех соединение "точка-точка" с головным управлением (не совсем верно, но примем для упрощения задачи). Для их мониторинга в центральной точке (головное управление) стоит сервер FreeBSD со стандартным набором: apache, php, mysql, zabbix и на нем крутится рукописный софт, который умеет то, что заббикс не умеет. Опрос идет средствами PHP по SNMP, заносится в базу. Появилась потребность раз в неделю или месяц тестировать канал связи в обе стороны на предмет соответствия реальной скорости канала и установленной провайдером. Устройства за роутером сервер уже не видит, поэтому может следующее:
1. общаться с удаленными роутерами по SNMP, FTP/TFTP, Telnet-у
2. инициировать любые процессы на центральных роутерах на этом конце посредством SNMP или Telnet.
Предполагается по очереди запускать тестирование в нерабочее время для оценки входящего и исходящего канала до точек.
Какие то варианты, позволяющие довольно точно протестить скорость канала, существуют для моей ситуации?
На циске есть недокументированная утиля ttcp. Во фре есть в портах аналогичная утиля: /usr/ports/benchmarks/ttcp. По идее, должны работать вместе :-) Но оно там по дефолту всего 16 Мб для теста перегоняет, канал может не успеть раскачаться на полную. Есть сведения, что можно с параметром rcvwndsize поиграться, чтобы трафика больше прокачивало, но я с этим не работал, поэтому подтвердить не могу.
1. У нас еще хватает старого и слабого железа типа 837, 871, 2611. Там этой команды я не нашел. Перешивать по сети - очень плохая идея, проверено. Порт был fe0, в новой прошивке стал fe0/0, настройки идут лесом, роутер стал недоступен.
2. Пробовал поиграться там, где команда есть - показывает скорее погоду на Юпитере, чем реальные значения. На пустом 100Мбит/с может показать 512к или 15Мбит/с. Классический iperf бы как-нибудь прикрутить...
sergey_privacy: Ну, вы спросили -- я ответил. Это единственная возможность прокачивать трафик напрямую между циской и фрёй. iperf -- идея гораздо лучше, но для этого нужно что-то размещать за роутерами и гонять трафик между фрёй и этим устройством/сервером.
В роутерах Cisco есть ip sla тесты, но там только jitter-ы. Они качество канала покажут, но не покажут пропускную способность.
Существует. Пишите по SSH в /dev/null какой-нибудь объем данных. Точный объем определите сами, исходя из эталонной пропускной способности и необходимой глубины проверки. Только качайте одним файлом, иначе скорость будет ниже.
Можно так:
Этап 1. Копируете с сервера файл в NVRAM устройства.
Этап 2. Копируете его обратно на сервер, в /dev/null.
Этап 3. Смотрите показания в заббикс.
Василий: Я заметил, что при работе с сервером по SMB и по FTP скорости сильно (в разы) различаются. Насколько реальные показания загрузки будут при работе по tftp?
Не могу судить строго, но если судить по спецификации протокола, то должны быть максимально приближены к реальным. Но конечно, чем более низкоуровневый протокол для передачи данных используется, тем лучше. И понятно, что SMB должен работать несколько медленнее. В идеале конечно генерировать тупой icmp трафик огромного объема и разрешить на него оборудованию отвечать. для FreeBSD для этого сгодится nmap. Но главное, это заставить железки хавать подобное. А nmap не имеет ограничения на размер пакета и вы сможете кидать по одному пингу на каждую железку, где каждый icmp пакет будет размером, допустим, 50МБ. Но тогда пинг займет очень много времени, ведь трафик будет весьма приоритетным и все железки должны пинговаться строго по очереди. А сколько времени будет отправляться подобный кусок бесполезныых данных... А 10МБ проверять особого смысла наверное нет. Хотя можно каждую ночь устраивать проверки для определенной группы железок.
Косяк данного метода в том, что ответ будет приходить не того-же объема, а как обычно.. Т.е. вы замерите только исходящую для Фри и входящую для Цисок, но наоборот не получится. Тут уже потребуется tftp
Василий: Самое смешное, что по SMB данные с сервера качаются намного БЫСТРЕЕ, чем по FTP. Про передачу тестового файла туда-сюда по ftp/tftp я задумывался, но FTP не показывает реальную скорость канала и зачастую показания намного меньше. Единственный вариант - в несколько параллельных потоков забивать, но не для такого железа и не для этой задачи.
sergey_privacy: Вы знаете, сейчас почитал спецификации и понял, что таки да, я ошибся. Действительно SMB должен работать быстрее в силу того, что сам по себе не требует никакой безопасности, не несет шифрований и т.д. Только аутентификационные и авторизационные данные. FTP несёт гораздо больше левой информации. В общем, звиняйте.
tftp должен работать резвее, ибо работает по telnet, где отродясь никакой безопасности, шифрования не было. Только аутентификация. Даже авторизационной инфы нет. В общем попробуйте его для начала в кабинете у себя, на гарантированной скорости. Посмотрите, как будет работать. Если вас устроит, то можно будет тестить более глобально. И в любом случае, отпишите здесь пожалуйста. Мне самому интересно, как в итоге вы решите проблему.
