Добрый день, дорогие друзья. Несколько лет работала сисадмином в некотором количестве корпоративных и домашних провайдеров Санкт-Петербурга и по сей день часто сталкиваюсь с тем, что покупая оборудование операторы смотрят больше на цену и описание функций, чем на реальные показатели, о них поставщики обычно ничего не пишут, в следствии чего вместо одного коммутатора приходится устанавливать еще и еще, а качество связи лучше может и не станет. Про существования понятия SLA(Service Level Agreement) тоже не все операторы в курсе, по этой причине собрала достоверную информацию по тестированию сетей и оборудования, и готова предоставить её вашему вниманию.
Ethernet нужно тестировать!
Есть ли точное определение и рецепты того, как проводить тесты пропускной способности канала и качества предоставляемой связи? Я нашла несколько статей, из которых стало понятно только одно, сегодня в России сети тестируют методами, предназначенными для других целей, и это не может не удивлять, ведь услуги связи в крупных городах нашей страны достаточно развиты, скоростной канал есть буквально в каждой квартире, а некоторые операторы уже предоставляют гигабитные каналы домашним клиентам, но о методиках тестирования качества предоставляемых телематических услуг знают далеко не все.
Что конкретно и почему нужно тестировать?
Задумайтесь, как часто сегодня покупают кота в мешке:
- Арендованные вами или сданные в аренду каналы связи;
- Сдача-приемка каналов связи, построенных вами или для вас;
- Предоставляемые услуги связи, особенно при наличии неустойки в договоре;
- Оборудование, которое вы хотите купить, а вам его хотят продать и рассказывают о том, что оно супер-крутое и недорого стоит.
Это крохотная горстка примеров того, чем рискуют на сегодняшний день клиенты и операторы связи.
Софтовые утилиты для тестирование «Интернета»
Полноценным тестированием канала не могут являться echo запросы, ping и mtr никогда не расскажут какая у канала пропускная способность. Об этом не сможет рассказать iperf и прочие софтовые утилиты, так как при одновременном использовании сети и тестировании софтовым утилитам не известен объем пользовательских данных, находящихся в канале в текущий момент, так же при софтовом тестировании возможен ряд неточностей, обусловленных наличием заголовков пакетов, в зависимости от размера кадра заголовки остаются стандартной длины, а тело с данными увеличивается или уменьшается, софтовые утилиты определяют пропускную способность канала без учета размера заголовков, что на разных размерах пакетов вносит в подобное тестирование определенную неразбериху.
Вы не сможете оценить качество арендованного vlan, глядя на график загрузки канала или скачивая объемные файлы из интернета. Почему speedtest.net не является доказательством скорости предоставляемого канала наверное не стоит уточнять? Ведь сразу понятно что - неизвестно какие каналы и через какие сети они идут до серверов speedtest, как и неизвестно насколько загружен канал во время теста, и многие другие параметры теста, а если в тесте столько неизвестных - то его результаты никак не могут быть точными. Результатом speedtest - является скорее некая дельта от неких показателей, а не реальные цифры.
Качество предоставляемых услуг связи - это совокупность многих параметров, и используя правильные инструменты можно быстро и эффективно получить точные данные о предоставляемой услуге. Важно не только получить точные данные, но и иметь уверенность в том, что данные можно будет использовать для доказательства своей правоты, например в суде.
Методики и анализаторы Ethernet
На сегодняшний день есть две основные методики тестирования пропускной способности: старая - RFC-2544 и немного помладше: Y.1564 . Методика ITU-T Y.1564 - более актуальная на сегодняшний день, имеет описания для тестирования современных, высокоскоростных каналов связи с современными понятиями о SLA(Service Layer Agreement).
Так как качество ethernet-канала это совокупность многих факторов, следовательно, правильное тестирование должно максимально охватывать все эти совокупности. При тестировании необходимо учесть многие аспекты и было бы полезно иметь расширенные возможности, такие как BER Test , пакетный джиттер, поддержку MPLS, QoS, тестирование нагрузкой протоколов прикладного уровня (http, ftp, etc...).
Для тестирования каналов от 1G до 10G и выше достаточно сложно делать нагрузочные тесты при помощи неспециализированного железа, зачастую процессоры не способны генерировать достаточный объем трафика, в отличие от специализированных тестеров-анализаторов. Такие приборы можно положить в стойку, шкаф, даже в ящик на чердаке и запускать тесты удаленно, а можно делать автоматические замеры в разные временные интервалы. Любые портативные приборы-анализаторы не испортятся в суровых условиях канализации, так как проходят жестокие испытания на прочность.
Сдача-приемка каналов связи.
Для сдачи или приемки построенных линий и магистралей, для работы по высоким стандартам лучше всего иметь в штатном арсенале тестер-анализатор, хотя в интернете можно найти фирмы, специализирующиеся на выездном тестировании. Почему-то считается что покупать тестер-анализатор это очень дорого.
Подробнее о методике тестирования RFC-2544 и том, как это работает.
Методика предлагает набор из 6 тестов, я опишу более подробно, каким образом проходит тестирование, для наглядности восприятия:
Определение пропускной способности тестируемого устройства(Throughput)
Описание теста: посылается небольшой объем, специально сформированных тестером, пакетов, на определенной скорости, на входной порт устройства, на выходном порту количество подсчитывается, если передано больше, чем получено - скорость уменьшается и тест запускается снова.
Определение время задержки кадра(Latency)
Описание теста: после определения пропускной способности(Throughput), для каждого размера кадра, на соответствующей ему максимальной скорости, посылается поток пакетов по определенному адресу. Поток должен иметь минимальную длительность в 120 секунд. В 1 пакет по прошествии 60 секунд вставляется метка. Формат метки определяется производителем оборудования. На передающей стороне записывается время, к которому пакет с меткой был полностью отправлен. На приемной стороне определяется метка и записывается время полного приема пакета с меткой. Задержка (latency) - это разница между временем отправки и временем получения. Данный тест, согласно методике необходимо повторять минимум 20 раз. По результатам 20 измерений вычисляется средняя задержка. Тест следует проводить отправляя весь тестовый поток на один адрес и отправляя каждый кадр по новому адресу.
Определение частоты потери кадров(Frame loss rate)
Описание теста: на входной порт устройства посылается определенное количество кадров на определенной скорости и подсчитывается количество пакетов, принимаемых от выходного порта устройства. Частота потери кадров рассчитывается следующим образом:
((количество переданных кадров - количество полученных кадров) * 100) / количество переданных кадров
Первая отправка происходит на максимально-возможной скорости, затем скорость отправки понижается с максимальным шагом в 10%, согласно методике уменьшение % шага даст наиболее точные результаты. Уменьшение скорости необходимо продолжать до тех пор, пока две последних отправки будут без ошибок, а именно мы узнаем максимальную скорость передачи данных, на которой frame loss rate становится равен 0.
Тестирование способности обрабатывать back-to-back кадры(Back-to-back frames)
Описание теста: тест сводится к отсылке некого количества кадров с минимальной межкадровой задержкой на входной порт тестируемого устройства и подсчету кадров с выходного порта устройства. Если количество отправленных кадров и полученных равно, то увеличивается объем отправляемых кадров и тест повторяется, если принятых пакетов меньше, чем отправленных объем отправляемых кадров уменьшается и тест повторяется. В итоге мы должны получить максимальное количество пакетов отправленных и полученных без потерь для каждого размера пакета, это и будет значение back-to-back теста. Согласно методике длительность посылок кадров на порт устройства не должна быть менее двух секунд, а минимальное количество - не менее 50 раз. Конечная цифра - это усредненный результат 50 тестов.
Восстановление после перегрузки(System recovery), применимо только для тестирование устройств
Описание теста: на вход устройства в течение минимум 60 секунд отсылается поток кадров со скоростью 110% относительно измеренной тестом throughput. Если тест throughput показал идеальные результаты, то выбирается максимальная скорость данного соединения. В момент перегрузки скорость потока уменьшается в два раза и засекается разница между временем снижения скорости потока, и временем когда был потерян последний кадр.
Время восстановления тестируемого устройства после перезапуска(Reset), применимо только для тестирование устройств
Описание теста: на вход устройства отсылается непрерывный поток кадров на скорости, определенной в результате теста throughput с минимальным размером кадра. Устройство сбрасывается. Время восстановления после сброса это разница между временем приема последнего пакета до сброса и временем приема первого пакета после сброса. Тестируется и аппаратный и программный типы сброса устройства.
Что изменилось со свежей методикой Y.1564?
Новые рекомендации были рассмотрены и одобрены в 2011 году ITU . К уже изложенным рекомендациям в RFC 2544 добавляется пакетный джиттер(дрожание), а именно возможность вычисления разницы времени при получении ряда последовательных пакетов данных, относящихся к одному и тому же потоку, в идеальном мире ее не должно существовать, но в проблемных сетях последовательность может быть нарушена, что может сказаться на скорости обработки данных. RFC2544 позволяет делать проверки исключительно на максимальной скорости канала, на которой не будет потери пакетов, а это обычно выше чем скорость CIR (Committed Information Rate - гарантированная полоса пропускания) . Y.1564 создан именно для SLA , оценки скорости и качества предоставляемого канала согласно ключевым показателям производительности(KPI) и позволяет проверить предоставляемый канал в соответствие с договором.
Y.1564 позволяет проверить гарантированную полосу пропускания, максимально-допустимую, а так же дать нагрузку сверх полосы, к примеру для проверки настроек шейпера.
Есть еще несколько различий между методиками, RFC2544 не производит верификации корректности настройки сервиса (соответствие KPI заданным, и ограничение скорости выше EIR(Excess Information Rate - максимальная негарантированная полоса пропускания), во избежание перегрузки сети). В оригинальной версии RFC2544 джиттер не измеряется. Согласно RFC2544 каждый тест запускается отдельным потоком, что не позволяет измерить качество предоставляемых услуг в совокупности и увеличивает время тестирования, еще один минус RFC2544 в том, что отсутствует возможность профилирования для проверки разных типов трафика в одном канале, к примеру, если в сети используется QoS, в Y.1564 учтены недочеты и немного расширен функционал.
Тестировать можно только новые каналы или уже рабочие тоже?
Тестировать нужно и новые каналы, и тем более старые. Вы можете заранее узнать о назревающих проблемах, не доводя клиентов до звонка в поддержку. Современными тестерами-анализаторами можно проводить проверки в работающей сети, проверять каналы как со скоростью 10/100/1000Mbit, так и 10/40/100G. Есть одно НО, очень важно понимать что и как вы делаете, важно нечаянно не положить тестируемый канал.
Режимы тестирования - In/Out of service.
На сегодняшний день тестирование сетей стремится к полной систематизации и постоянному контролю каналов, более ранние версии методики RFC2544 были созданы для тестирования каналов/оборудования в режиме OutOfService, и использовались в основном для теста оборудования, но на сегодняшний день все производители тестовых приборов переходят на более новые стандарты тестирования, позволяющие проводить постоянный мониторинг сети в режиме InService. Такое тестирование позволяет проверять скорость полосы пропускания без отключения клиентов, что важно для операторов услуг связи.
Эпилог
Товарищи, как говорит один мой друг, давайте вместе бороться с «коекакерами», и начнем тестировать то, что строим и то, что эксплуатируем.
Используемая литература:
* Мнение компании может не совпадать с мнением автора;-)
Только зарегистрированные пользователи могут участвовать в опросе. , пожалуйста.
Заявленная скорость соединения с интернетом, которую обещают провайдеры, иногда не соответствует реальной пропускной способности соединения. Скорость соединения может быть несколько ниже гарантированной, а кроме этого, может быть нестабильной. При простом просмотре страниц в браузере пользователь может даже не обратить внимания на подобное несоответствие, однако при воспроизведении онлайнового видео, передаче файлов и других действиях в сети, когда необходима высокая пропускная способность, недостаток скорости будет заметен. Если обратиться напрямую к провайдеру, служба поддержки вряд ли признает данный факт, и в качестве оправдания может быть названо множество причин - плохое состояние телефонной линии, наличие в данном районе устройств, вызывающих помехи, и так далее. Еще одна популярная отговорка - скорость соединения зависит от возможностей удаленного сервера. Можно самостоятельно измерить скорость, например, скачать большой файл и отметить, сколько ушло времени на его загрузку. Аналогичным образом можно попытаться измерить и скорость исходящего соединения - отправить файл самому себе по электронной почте или другим способом. Но все эти "замеры" выполнять очень неудобно, да и за достоверность таких "кустарных" измерений ручаться не приходится. Чтобы не "гадать на кофейной гуще" и точно определить, какая именно скорость подключения используется на данном компьютере, можно использовать онлайновый сервисSpeedtest.net. Принцип измерения скорости передачи данных, который использует данный сервис, состоит в следующем. На схематической карте мира обозначены наиболее быстрые серверы различных интернет-провайдеров. Пользователь может выбрать любой из них и проверить скорость своего соединения с интернетом. В процессе проверки тестируемый компьютер обменивается пакетами с удаленным сервером.
Зафиксированные показатели могут отличаться - для определяемой скорости большое значение имеет то, насколько велико расстояние между тестируемым компьютером и удаленным сервером. Кроме того, на результат влияет и скорость подключения удаленного компьютера. Если пользователь использует высокоскоростной интернет, не исключено, что удаленный компьютер использует менее скоростной канал, и конечные цифры будут ниже действительных. Однако преимущество сервиса Speedtest.net состоит в том, что пользователь может собственноручно изменять серверы, чтобы определить максимальную скорость. Помимо данных о скорости сетевого соединения, сервис предоставляет много интересной статистики, например, составляет рейтинг стран мира с наиболее быстрым интернетом, составляет такой же рейтинг в выбранном регионе (например, только в Европе), дает возможность выставлять оценку своему провайдеру, показывает расстояние до выбранного сервера и многое другое. Любой работающий сервер может принять участие в проекте Speedtest.net в качестве тестируемого удаленного компьютера.
Iperf – консольная утилита с открытым исходным кодом, предназначенная для тестирования пропускной способности сети. С ее помощью довольно просто измерить максимальную пропускную способность сети между сервером и клиентом, провести нагрузочное тестирование канала связи или маршрутизатора
Утилита Iperf является кроссплатформенной и не требует установки, достаточно просто скопировать ее на два компьютера, пропускную способность сети между которыми нужно оценить.
Работает утилита Iperf в режиме клиент-сервер. На первом компьютере утилита Iperf запускается в режиме сервера (ожидает трафик от клиента), а на втором, на котором Iperf запускается в режиме клиента, осуществляется генерация TCP и UDP трафика и проводится измерение скорости передачи данных.
Чтобы оценить пропускную способность сети между двумя узами сети, запустим сначала утилиту iperf в серверном режиме:
Iperf.exe -s -w 32768
Важно . Аргументы утилиты iperf регистрозависимы.
-s
–утилита запускается в серверном режиме (получающая сторона)
-w 32768
– зададим размер окна TCP в 32 KB (по умолчанию около 8 Кб)
По умолчанию утилита слушает TCP порт 5001 .В зависимости от настроек файерволов между клиентом и сервером, порт можно изменить с помощью аргумента -p [номер_порта].
На стороне клиента запустим iperf со следующими опциями:
Iperf.exe -c 10.0.0.44 -P 8 -t 30 -w 32768
-c 10.0.0.44
– IP адрес сервера iperf
-w 32768
— увеличиваем размер TCP окна
-t 30
– время в секундах, в течении которого выполняется тестирование (по умолчанию 10 секунд)
-P 8
— число альтернативных потоков для увеличения пропускной способности
В нашем примере тестирование длилось 30 секунд. В итоговом отчете нас интересует значения столбца Bandwidth последней строки . В нашем случае средняя пропускная способность сети между двумя системами – 2,85 Гбит/с. С помощью аргумента –f можно изменить формат скорости (биты, килобиты, мегабайты). При продолжительных тестах, когда нужно оценивать производительность в течении нескольких минут, с помощью опции –i можно указать интервал через который нужно отображать промежуточные результаты.
По-умолчанию утилита генерирует TCP трафик, если требуется осуществить тестирование для протокола UDP, необходимо использовать ключ -u.
Во время выполнения теста график загрузки сети в Task Manager выглядит так:
Важно отметить, что при тестировании Iperf используем всю доступную пропускную способность канала связи между клиентом и сервером, что может негативно повлиять на продуктивные приложения и пользователей. Поэтому такое тестирование нужно проводить обдуманно.
Если необходима оценка пропускной способности сети в обоих направлениях (в дуплексом режиме), дополнительно на клиенте нужно указать опцию –d :
Iperf.exe -c IP -P 8 -t 30 -w 32768 -d
Полный список опций утилиты можно получить так:
Iperf –help
Скачать версию iperf для Windows можно на softpedia.com (iperf-2.0.5-2-win32.zip) или .
Для тех, кто предпочитает графический интерфейс управления, имеется и графический аналог iperf — утилита jperf , написания на Java (для работы на компьютере должна быть установлена Java-машина). Помимо графических рюшечек к CLI интерфейсу, Jperf умеет в реальном времени строить графики пропускной способности канала связи.
Итак, резюмируя, Iperf – простая и удобная сетевая утилита, которая может измерить производительность и качество соединения между двумя системами. И не смотря на то, что развитие программы давно прекращено, ее функционала вполне хватает для поставленной задачи.
Iperf – консольная утилита с открытым исходным кодом, предназначенная для тестирования пропускной способности сети. С ее помощью довольно просто измерить максимальную пропускную способность сети между сервером и клиентом или провести нагрузочное тестирование канала связи.
Скачать эту утилиту можно с нашего сервера или с сайта проекта. Нам потребуется iperf 3-й версии (iperf 3.0). Для удобства файлы из архива можно скопировать в папку Windows на системном диске, это позволит упростить вызов программы.
Все следующие команды выполняются в командной строке Windows (cmd). Вызвать командную строку можно следующими способами: Пуск -> Все программы -> Стандартные -> Командная строка или Пуск -> Выполнить и ввести имя программы cmd
Для запуска сервера нужно запустить программу iperf3
с параметром -s
: iperf3 -s
Для запуска клиента и начала тестирования нужно запустить iperf3
с параметром -c
Параметр
Вы можете запустить сервер на одном компьютере, а клиент на втором, указав в параметрах сервера ip-адрес первого компьютера, и протестировать пропускную способность Вашей локальной сети.
Наш сервер уже запущен и доступен по адресу iperf.donapex.net
Для запуска простого теста, достаточно ввести в командной строке следующую команду: iperf3 -c iperf.donapex.net
Эта команда запустит тестирование исходящей скорости.
Для тестирования входящей скорости необходимо в команду добавить ключ -R
(reverse mode): iperf3 -c iperf.donapex.net -R
Расширенные параметры тестирования.
Что-бы указать длительность тестирования используется ключ -t <сек>
: iperf3 -c iperf.donapex.net -R -t 60
В данном примере устанавливается длительность тестирования — 1 минута.
По умолчанию скорость тестирования не ограничивается. Для ограничения максимальной скорости теста используется ключ -b <бит/сек> . Можно использовать модификаторы: K — Килобит, M — Мегабит, G — Гигабит, например -b 20M — соответствует ограничению 20 Мегабит/сек.
iperf3 -c iperf.donapex.net -R -t 60 -b 20M
В диспетчере задач можно видеть степень загрузки сети, для сети 100 Мегабит загрузка будет около 20%.
Тест входящей скорости с ограничением 50 Мегабит/сек: iperf3 -c iperf.donapex.net -R -t 60 -b 50M
В диспетчере задач можно видеть степень загрузки сети, для сети 100 Мегабит загрузка будет около 50%.
Иногда, по ряду причин, невозможно добиться полной скорости в один поток. Поэтому в iperf
предусмотрен многопоточный режим работы. Чтоб указать количество потоков используется параметр -P
Можно указывать один и более потоков, например запуск тестирования в 2 потока будет выглядеть так: iperf3 -c iperf.donapex.net -R -t 60 -P 2
Тестирование UDP трафиком.
По умолчанию программа iperf3 использует TCP протокол. Протокол UDP, в отличии от TCP, не использует алгоритмы контроля доставки пакетов и контроля скорости передачи, и имеет немного другое поведение в сети, чем TCP траффик.
Т.к. UDP не контролирует скорость передачи — это должна делать программа, передающая трафик. Поэтому в UDP тесте по умолчанию устанавливается ограничение максимальной скорости 1 Мегабит/сек. Изменить это ограничение можно при помощи ключа -b
Не следует указывать слишком большую максимальную скорость, это может привести к перегрузке сети. В данном типе теста лучше держать этот параметр в пределах до 100 Мегабит.
Указать iperf3, что следует использовать UDP протокол можно при помощи параметра -u
Тест исходящей скорости с ограничением 30 Мегабит/сек: iperf3 -c iperf.donapex.net -t 60 -b 30M -u
В диспетчере задач можно видеть степень загрузки сети, для сети 100 Мегабит загрузка будет около 30%.
Тест входящей скорости с ограничением 20 Мегабит/сек: iperf3 -c iperf.donapex.net -R -t 60 -b 15M -u
В диспетчере задач можно видеть степень загрузки сети, для сети 100 Мегабит загрузка будет около 20%.
Сервер может принимать соединения одновременно только от одного клиента. Если сервер занят другим клиентом, при попытке тестирования будет выдана ошибка. В таком случае следует подождать освобождения сервера.
Для более полного тестирования желательно провести несколько тестов: с ограничением скорости меньшей тарифной, с ограничением скорости равной тарифной, без ограничения скорости.
