Какой автоматизированный тест выполняет приложение rfc 2544

Обновлено: 08.01.2025

Интернет-технологии нас окружают везде. Мы ими пользуемся постоянно: дома, на работе, когда едем в автобусе или метро. Современный мир очень сложно сейчас представить себе без беспроводных технологий, таких как Wi-Fi. В этой статье описываются приборы для тестирования сетей на этапах развертывания и во время эксплуатации. Какие тесты применяются и их методика проведения. Также рассматривается тестирование роутеров (маршрутизаторов) и коммутаторов во время их разработки и для проверки их функционирования.

Зачем нужно проводить тестирование

Тестирование сетей и роутеров проводится в следующих случаях:

Для проверки выполнения провайдером условий договора об оказании услуг связи.
После того как сеть развернута, перед вводом ее в эксплуатацию. Например, построено новое здание, разработан новый автобус, в котором раздается Wi-Fi, а также установлены IP-видеокамеры. Тут можно выделить долгосрочные измерения и краткосрочные. Если была разработана новая сеть, то она должна пройти долгосрочные испытания. Если аналогичные сети уже разворачивались ранее, то проводят краткосрочные испытания.
Для проверки характеристик маршрутизаторов и коммутаторов. Эти проверки следует проводить при их разработке, а так же при тестировании готовой продукции.
При создании оборудования связи. Например, для проверки нового Wi-Fi приемника.

Качество связи, которое предоставляет провайдер, можно померить самостоятельно, но желательно, чтобы этим занималась независимая организация. Можно осуществлять контроль над качеством предоставляемого канала постоянно. Для этого используются «зонды». Их устанавливает организация, осуществляющая мониторинг, на узлах сети. Система управления настраивает зонды и периодически проводит тестирование. В случае обнаружения неисправностей, формируется отчет и уведомляется провайдер, чтобы он ее устранил.

При изготовлении роутеров. Если у роутера порт, поддерживающий скорость передачи 1 Гбит в секунду, то он должен передавать эти данные без потерь. Это следует контролировать с помощью тестов. Но, допустим, если у роутера несколько таких портов, и если через два порта без потерь идет передача со скоростью 1 Гбит в секунду, то, при запуске аналогичного теста одновременно на других портах, не факт, что роутер успеет обработать всю информацию. По крайней мере, недорогие роутеры не могут поддерживать максимальную скорость обмена информацией на всех портах одновременно.

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

Проверка с помощью утилит

Можно проверять пропускную способность канала с помощью стандартных утилит. Этот метод хорошо подойдет, если Вам надо примерно оценить качество связи между двумя компьютерами.

Для этого подойдет кросс-платформенная утилита iperf. На одном компьютере запускается сервер с помощью команды «iperf –s», после этого, на другом компьютере запускается клиент «iperf –c server_ip». Утилита проводит тестирование и выводит результаты: время в секундах с момента начала тестирования, количество переданных байт, скорость передачи.

Сейчас актуальна 3-я версия. Если Вы пользователь Windows, то скачиваем утилиту и запускаем из командной строки. На одном компьютере сервер «iperf3.exe –s». На втором клиент. Вот так выглядит лог вывода, если не задавать дополнительных опций:

С помощью ключей можно настроить протокол передачи (TCP/UDP, а в 3-ей версии и SCTP). Можно провести тестирование не только передачи данных от клиента к серверу, но и в обоих направлениях. Есть возможность выбора портов, на которых будет запускаться сервер.

Недостаток такого тестирования – это в первую очередь то, что тестирование проводится на 4 уровне модели OSI, то есть фиксируются только данные, переданные по TCP/UDP, без учета ip заголовков и управляющих пакетов. Оператор связи, в свою очередь, обычно гарантирует пропускную способность канала связи, включая IP заголовки.

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

Проверка с помощью интернет ресурсов

Проверить его скорость можно с помощью «Speedtest» от Ookla. Есть другие, но это самый популярный. Вначале проводится ping-тестирование для определения скорости отклика сервера. После этого измеряется, с какой скоростью Ваш компьютер может передавать файлы в интернет и загружать файлы из интернета.

При проведении нескольких тестов результаты тестирования будут изменяться. Это зависит от загруженности сервера, с которым производится обмен файлов. Не известны маршруты пакетов до серверов.

Конечно же, такой Speedtest не будет точным. Но по его результатам можно позвонить провайдеру и поинтересоваться о причинах плохого интернета, и когда их поправят.

Приборы для тестирования Ethernet сетей

После того как сеть была развернута, необходимо проверить, правильно ли все было сделано, правильно ли были настроены маршрутизаторы, нет ли где плохого контакта или обрыва. Могут не работать какие-то видеокамеры в автобусе. Вот тут для проверки и необходимы приборы. Зачастую случается так, что все не работает и непонятно почему. С помощью приборов можно быстро выявить причину и место неисправности.

На аэродромах, в портах, важных административных зданиях системы связи должны работать без сбоев. Обеспечение этого должно контролироваться с помощью приборов, внесенных в государственный реестр средств измерений.

Можно выделить следующие группы устройств, используемых для проведения измерений:

Самостоятельный прибор, обычно с двумя измерительными портами. Удобно передавать пакеты тестовых данных с одного измерительного порта, и анализировать их на другом. В этом случае анализируются односторонние измерения. Так же можно включить режим «Шлейф» на одном из портов. Пакет, пришедший на порт, будет пересылаться обратно отправителю. Таким образом, можно проводить двусторонние измерения.
«Шлейф». Это устройство «заворота» трафика, самостоятельно его нельзя использовать для проведения измерений. У него один измерительный порт. Все пакеты, пришедшие на него, он пересылает обратно отправителю. Его используют в случае проведения измерений на больших расстояниях. На одном участке сети ставится шлейф, на другом участке подключается прибор. С прибора отправляются тестовые данные на шлейф, тот их разворачивает обратно. Так проводятся двухсторонние измерения.
«Зонд». Это самостоятельный прибор, у которого один или два измерительных порта. Контролируется работа зондами с помощью системы управления, которая задает зондам необходимые настройки и запускает тестирование. Обычно зонды изготавливаются с учетом возможной их установки в стойку.

Тестовый трафик формируется и обрабатывается на ПЛИС (программируемой логической интегральной схеме). Прибор не передает во время тестирования никакого лишнего трафика с измерительного порта, который мог бы повлиять на результаты проведения теста. Отправляемые пакеты снабжаются временными метками в области данных. Благодаря этому можно, при получении тестового пакета, определить задержку пакета, пакетный джиттер с точностью до 8 наносекунд.

По результатам проведенных измерений, формируют отчеты.

Примеры оборудования для тестирования сетей:

Двухпортовый прибор HST-3000C, работает от аккумулятора. Поддерживает много тестов.

Двухпортовый прибор MTS-5800, есть аккумулятор, работает от сети 220 В. Это настольный прибор, к которому можно подключить компьютерную мышь. Так же можно подключить флешку и на нее скинуть отчеты о проведенных тестах.

Однопортовый зонд МАКС-ЕМК С1, возможна установка в стойку, работает от сети 220 В.

Топология

Измерения могут быть:

Двухсторонние измерения – это когда генерируемые пакеты отправляются на «Шлейф». Шлейф получает пакеты и пересылает их назад отправителю. Таким образом, канал тестируется в обе стороны сразу. В качестве устройства заворота трафика может служить как второй порт двухпортового прибора, так и удаленно расположенное устройство заворота трафика.

Для односторонних измерений используется двухпортовый прибор. Трафик генерируется с одного порта прибора, а на втором порте анализируется. Есть варианты асимметричного теста трафика, который проводится с одного прибора на другой и вычисляет потери кадров в одном направлении.

Очень сложно проводить односторонние измерения временных характеристик при тестировании с удаленным прибором. Это такие параметры как задержка пакетов, джиттер. Для проведения таких тестов необходимо очень точно синхронизировать внутренние часы приборов. Этот функционал используется в зондах. Один из примеров такой синхронизации – это использование сигнала 1PPS, рассчитанного по информации со спутников ГНСС.

Тест трафика

В любом случае, чтобы быстро проверить работоспособность, этот тест незаменим.

Наиболее сложными считаются тесты с размером кадров 64 байта. Такая настройка позволяет загрузить тестируемое устройство максимальным количеством кадров в секунду. Помимо проверки на обычные Ethernet кадры, следует провести проверку и на джамбо фреймы. Например, нагрузить канал пакетами размером 9600 байт.

Допустим, у роутера заявленная скорость 1 Гбит в секунду. Выбираем два порта, поддерживающие эту скорость передачи, на одном из портов устанавливаем «Шлейф», на другом прибор, который генерирует трафик с загрузкой канала на 100 процентов.

Если потерь нет, то роутер считается исправным.

Можно попытаться провести тестирование одновременно на нескольких портах. Не дорогие роутеры, вполне вероятно, не смогут выдержать такую нагрузку, и будут потери.

Тест RFC-2544

Проверяет все основные характеристики сети:

Потери кадров
Задержка пакетов
Пропускная способность
Предельная нагрузка

У него не рассчитывается разве что пакетный джиттер, который есть в Y-1564.

Тест Y-1564

Гораздо быстрее проводится, чем RFC-2544. Это обусловлено тем, что все измерения проводятся одновременно:

Скорость передачи данных
Потери кадров
Задержка (FTD)
Джиттер (FDV)

Дополнительно проводится измерение производительности, один из параметров которого – доступность канала.

При проведении Y-1564 задаются следующие настройки:

CIR – гарантированная пропускная способность
EIR – превышение CIR, при котором иногда возможны потери кадров
Policy – недопустимое превышение EIR. Такое превышение, при котором должна фиксироваться ошибка

Возможно проведение измерений сразу в несколько потоков.

Тест Y-1564 хорошо подойдет для проверки характеристик канала связи, предоставленного провайдером.

Также его можно использовать на существующей сети, для проверки: выдержит ли она дополнительный трафик. Например, требуется проводить видеоконференции и необходимо принять решение, возможно ли это на существующей сети. Можно прикинуть, как все будет работать, если нагрузить сеть дополнительным трафиком, поэкспериментировать с приоритетами пакетов. И в итоге принять решение, что да – существующая сеть позволяет проводить видеоконференции с таким-то качеством.

Как RFC 2544 помогает в тестировании оборудования Ethernet для операторов связи

Что такое RFC 2544
Операторы связи всё активнее и активнее применяют оборудование Ethernet в борьбе за клиентов, традиционно использующих надежные каналы E1. При этом производители оборудования Ethernet зачастую приукрашивают свою продукцию для ее продвижения, иной раз вводя в заблуждение потенциальных пользователей своей продукции.
Стандарт RFC 2544, установленный Инженерным советом Интернет (Internet Engineering Task Force, IETF), является, де факто, методологией тестирования устройств для операторских сетей Ethernet. Стандарт описывает методологию, которая позволяет оценить производительность сетевого устройства, включающую в себя такие параметры как пропускная способность, уровень потерь кадров и задержка. Методология устанавливает размеры кадров, длительность тестов и количество итераций. Результаты таких тестов обеспечивают оператора сравнимыми данными о продукции разных производителей, которые можно использовать для оценки и выбора устройств. Кроме того, измеряемые параметры обычно указываются в соглашении об уровне предоставляемых услуг (SLA), заключаемом операторами с клиентами. В таких случаях контроль выполнение рекомендаций RFC 2544 осуществляется для участка сети, а не для конкретного оборудования.

Тесты RFC 2544
Для того, чтобы проверить способность оборудования Ethernet работать в сети с различными типами предоставляемых сервисов, таких как VoIP, IP TV, FTP и т. п., стандарт RFC 2544 задает семь разных размеров кадров - 64, 128, 256, 512, 1024, 1280 и 1518 байт, используемых в тестах, с целью эмуляции различного типа трафика. Чем меньше размер кадра, тем больше их количество, т.е. выше нагрузка на сетевое устройство.

Тестирование пропускной способности
В ходе данного теста определяется максимальное количество кадров в секунду, которое может передать устройство без ошибок. Это тест выполняется, чтобы определить реальную максимальную скорость передачи данных, которую может обеспечить оборудование, а не скорость работы интерфейса.
Проведение тестирование начинается на максимальной скорости (скорости интерфейса). В ходе тестирования измеряется количество переданных тестером кадров и количество принятых кадров. Если хотя бы один кадр потерялся, скорость передачи кадров уменьшается в два раза. Если в ходе очередной попытки ни один кадр не потерялся, скорость удваивается по сравнению с предыдущей попыткой. Таким образом, ищется максимальная скорость, на которой устройство может передавать данные без ошибок.
Тестирование пропускной способности должно быть проведено для кадров каждого из семи заданных размеров. Для принятия решения о достижении максимальной скорости время безошибочной передачи данных для каждого размера кадров должно быть не менее 60 секунд.
Хотя RFC 2544 не регламентирует, но всё же рекомендуется дополнительно проводить тестирование кадрами переменной длины, чтобы выявить возможные проблемы при передачи трафика, максимально приближенного к реальному. Кроме того, иногда оказывается, что оборудование отлично справляется с кадрами заданных размеров, а кадр определенной длины передать не может из-за программной или аппаратной ошибки.

Тестирование устойчивости к всплескам трафика
Тестирование устойчивости к всплескам трафика оценивает ёмкость буфера оборудования. В ходе тестирования кадры передаются на скорости интерфейса (с минимальными межкадровыми интервалами) и измеряется максимальное количество кадров, полученных до того как потеряется первый кадр. Продолжительность испытания должна быть не менее 2 секунд. Если в течение этого времени число переданных кадров совпадает с числом пересланных устройством на протяжении всего пика, пакет кадров увеличивается и испытание повторяется. Если число пересланных устройством кадром меньше числа переданных, размер пакета уменьшается и испытание повторяется. Испытания следует повторять не менее 50 раз с усреднением значений.

Тестирование частоты потери кадров
Измерение частоты потери кадров необходимо для оценки способности оборудования работать в условиях перегрузки, что является критическим показателем возможности поддерживать приложения реального времени, в которых большое количество потерь резко снижает качество.
Первое испытание проводят на максимальной скорости. При следующих испытаниях скорость снижается сначала до 90% от максимальной скорости, а затем до 80% и т.д. Снижение скорости на 10% повторяют до тех пор, пока не будет зафиксировано последовательно три результата без потери кадров. Шаг снижения скорости должен быть не более 10% от максимальной скорости, приветствуется снижение скорости с меньшим шагом. Тестирование опять проводят для всех семи размеров кадров. Результатом является график зависимости частоты потери кадров от скорости.

Тестирование задержки
В ходе тестирования измеряется время прохождения через устройство (или туда и обратно). Если время задержки значительно меняется от кадра к кадру, то это может стать проблемой для работы таких сервисов, как VoIP, IPTV и TDMoIP через данное оборудование. Например, вариация задержки может выразиться в ухудшение качества голоса, передаваемого с помощью технологии VoIP или в значительном джиттере псевдо-проводного потока Е1, образованного с помощью технологии TDMoIP. Большое время задержки также может ухудшить качество работы приложений.
Процедура тестирования начинается с измерения максимальной пропускной способности для кадров каждого размера, при которой кадры не теряются, т.е. аналогично тесту пропускной способности. Это позволит заполнить все буферы устройства, обеспечив измерение задержки в наихудших условиях. На втором этапе запускается тестовый поток с определенной максимальной скоростью продолжительность 120 секунд. Через 60 секунд в поток вставляется кадр с временной меткой. Когда этот кадр возвращается, тестер вычисляет задержку. Передача данных продолжается весь оставшийся промежуток времени. Тест повторяется не менее 20 раз, итоговое значение задержки усредняется по всем попыткам. Тестирование опять же проводят для кадров всех размеров.

Хотя в RFC 2544 это не предусмотрено, рекомендуется еще проводить измерения вариации задержки, потому что, как отмечалось выше, данный параметр критичен для работы приложений реального времени, например, потокового видео.
Измерения вариации задержки проводится путем отправки кадров с одинаковым межкадровым интервалом, а затем сравнения с интервалами, с которыми кадры возвращаются обратно. Измерения проводятся на максимальной возможной для испытуемого устройства скорости, потому что вариация задержки при этом максимальна.

Тестирование скорости восстановления
Данное тестирование подразумевает два вида восстановления оборудования: после перегрузки и после перезагрузки. Данные параметры напрямую влияет на время отсутствия связи в сети при возникновении нештатной ситуации.
Для определения времени восстановления после перегрузки сначала определяется пропускная способность устройства для каждого из размеров кадра. Затем передается поток кадров со скоростью 110% от пропускной способности или с максимальной скоростью интерфейса (выбирается меньшее из 2 значений) в течение, по крайней мере, 60 секунд. После этого интенсивность трафика снижается вдвое и засекается время, пока устройство не перестало терять кадры. Время восстановления устройства определяется как разность времени после снижения интенсивности трафика и времени начала передачи данных без потерь. Тест повторяют многократно, значение времени восстановления усредняют.
Для определения времени восстановления после перезагрузки сначала определяется пропускная способность устройства для кадров минимального размера. Затем передается непрерывный поток кадров с определенной пропускной способностью для минимального размера кадров и выполняется сброс устройства с записью времени передачи последнего кадра перед сбросом и первого кадра после сброса. Время восстановления после перезагрузки определяется как разность между этими моментами.
При тестировании следует выполнять как программную перезагрузку, так и по отключению питания. При измерении времени восстановления после пропадания напряжения питания отключение питания устройства производят на 10 секунд.

Заключение
Тестирование оборудование Ethernet, согласно рекомендации RFC 2544, сегодня является базовым способом проверки производительности устройств, также как BER-тест является базовым способом проверки для оборудования TDM. Тем не менее, проведение тестирования согласному этому стандарту не гарантирует работу вашего оборудования в необходимых условиях. Зачастую требуется более тщательное тестирование, особенно встроенного программного обеспечения, чтобы быть уверенным в способности выбранного оборудования обслуживать предоставляемые сервисы. В проведение такого тестирования вам всегда готовы помочь специалисты компании Tetslog.

Всем привет!

В этот раз подошло время рассмотреть стандартный тест RFC2544: для чего используется, как проводится, его достоинства и недостатки.

Со времени прошлой статьи ко мне поступили отзывы коллег с предложением писать ближе к делу: меньше воды — больше специфики. Так что предлагаю эту статью считать экспериментальной. В конце материала небольшой опрос.

Введение

Рекомендация RFC2544 была разработана в 1999 году и принята IETF . Существует перевод на русский язык. Сейчас эта рекомендация практически стандарт де-факто, благодаря широкому распространению и свободному доступу. Рекомендация “описывает и определяет набор тестов для определения характеристик устройств межсетевых соединений”, описывает форматы представления результатов тестирования.

Структура методики

Тестирование по методике RFC2544 сводится к выполнению набора тестов, четыре из которых присутствуют у большинства производителей измерительного оборудования, а два встречаются довольно редко (последние в списке).

Throughput
- определяет пропускную способность DUT , по рекомендации RFC1242
- определяет нагрузку, при которой нет потерь пакетов
- определяет задержку, по рекомендации RFC1242
- измеряет задержку по кадрам выборочно
- определяет частоту потери кадров, по рекомендации RFC1242, во всем диапазоне скоростей данных и размеров кадра
- определяет зависимость потерь от нагрузки
- определяет возможность DUT по обработке кадров back-to-back, по рекомендации RFC1242
- измеряет длительность работы при заданной нагрузке
- определяет скорость восстановления DUT после перегрузки трафиком
- определяет скорость восстановления DUT после программного или аппаратного сброса
Пропускная способность

Определяется максимальное количество кадров в секунду, которое может передать устройство без ошибок. Скорость определяется методом бисекции. Тест начинается на максимальной скорости. В случае потерь, скорость уменьшается в два раза. Если потерь нет, то скорость увеличивается в два раза, по сравнению с предыдущей. И так далее. Максимальная скорость определяется по стабильности работы (нет потерь) на протяжении 60 секунд. Тестирование проводится для каждого размера кадра. Размеры задаются в параметрах теста RFC2544 перед запуском.

Задержка

Тест опирается на предыдущее измерение пропускной способности. Для каждого размера пакета с соответствующей ему максимальной скоростью генерируется поток данных. Поток должен иметь длительность минимум 120 секунд. В 1 пакет по прошествии 60 секунд вставляется метка времени. На передающей стороне записывается время отправки пакета. На приемной стороне определяется метка отправителя и записывается время приема пакета. Задержка — это разница времени получения и времени отправки. Тест должен повторяться минимум 20 раз. По результатам измерений вычисляется средняя задержка.

Потеря пакетов

Подсчитывается процент потери пакетов (отношение потерянных к отправленным). Измерение начинается на максимальной скорости и с каждой следующей попыткой уменьшается на 10% (или меньше). Скорость понижается до тех пор, пока два измерения подряд не пройдут без потерь.

Back-to-back

Тест заключается в проверке оборудования обработать кадры, идущие с минимальным межкадровым интервалом, т.е. спиной к спине (back-to-back). Начинается с установленного в параметрах теста RFC2544 количества кадров. Если потери не наблюдаются (на протяжении не менее 2 секунд), то количество кадров увеличивается, если присутствуют, то уменьшается. По итогам не менее 50 измерений вычисляется среднее значение.

Недостатки методики

Методика тестирования стара (разработана в 1999 году) и сегодня уже не соответствует требованиям рынка. Из недостатков выделяются:
невозможно постоянно измерять задержку (Frame Transfer Delay, FTD)
отсутствует измерение вариации задержки (Frame Delay Variation, FDV)
нет многопоточности, все выполняется по очереди
тест долгий (исходя из предыдущего пункта)

Дополнения к методике

Jitter

Пакетный джиттер — это абсолютная разность задержек распространения двух последовательно принятых пакетов, принадлежащих одному потоку данных.
Идеальный вариант — полное отсутствие дрожания:

Возможный вариант — различная задержка между соседними пакетами:

Complex traffic

Тест позволяет генерировать и принимать несколько потоков тестового трафика.
Измеряет пропускную способность и величину потерь кадров (Frame Loss Rate, FLR), но не позволяет измерять постоянно задержку (FTD) и вариацию задержки (FDV).

Заключение

Методика RFC2544 сейчас присутствует в оборудовании большинства производителей, в первую очередь исторически, и можно сказать что сегодня она — такой же базовый тест для пакетных сетей Ethernet, как BERT для сетей TDM. Но стоит помнить, что RFC2544 не проводит всестороннее тестирование и даже при успешном прохождении всех тестов может возникнуть ситуация, что сеть не будет функционировать как ожидалось.
На смену методике RFC2544 приходит Y1564, которой собираюсь посвятить следующую статью.

В этот раз подошло время рассмотреть стандартный тест RFC2544: для чего используется, как проводится, его достоинства и недостатки.

Введение

Структура методики
- определяет пропускную способность DUT , по рекомендации RFC1242
- определяет нагрузку, при которой нет потерь пакетов
- определяет задержку, по рекомендации RFC1242
- измеряет задержку по кадрам выборочно
- определяет частоту потери кадров, по рекомендации RFC1242, во всем диапазоне скоростей данных и размеров кадра
- определяет зависимость потерь от нагрузки
- определяет возможность DUT по обработке кадров back-to-back, по рекомендации RFC1242
- измеряет длительность работы при заданной нагрузке
- определяет скорость восстановления DUT после перегрузки трафиком
- определяет скорость восстановления DUT после программного или аппаратного сброса
Пропускная способность

Определяется максимальное количество кадров в секунду, которое может передать устройство без ошибок. Скорость определяется методом бисекции. Тест начинается на максимальной скорости. В случае потерь, скорость уменьшается в два раза. Если потерь нет, то скорость увеличивается в два раза, по сравнению с предыдущей. И так далее. Максимальная скорость определяется по стабильности работы (нет потерь) на протяжении 60 секунд. Тестирование проводится для каждого размера кадра. Размеры задаются в параметрах теста RFC2544 перед запуском.

Задержка

Потеря пакетов

Подсчитывается процент потери пакетов (отношение потерянных к отправленным). Измерение начинается на максимальной скорости и с каждой следующей попыткой уменьшается на 10% (или меньше). Скорость понижается до тех пор, пока два измерения подряд не пройдут без потерь.

Back-to-back

Тест заключается в проверке оборудования обработать кадры, идущие с минимальным межкадровым интервалом, т.е. спиной к спине (back-to-back). Начинается с установленного в параметрах теста RFC2544 количества кадров. Если потери не наблюдаются (на протяжении не менее 2 секунд), то количество кадров увеличивается, если присутствуют, то уменьшается. По итогам не менее 50 измерений вычисляется среднее значение.

Недостатки методики

Методика тестирования стара (разработана в 1999 году) и сегодня уже не соответствует требованиям рынка. Из недостатков выделяются:

невозможно постоянно измерять задержку (Frame Transfer Delay, FTD)

отсутствует измерение вариации задержки (Frame Delay Variation, FDV)

нет многопоточности, все выполняется по очереди

тест долгий (исходя из предыдущего пункта)

Дополнения к методике

Чтобы расширить функциональность и компенсировать недостатки разработаны дополнения:

Jitter

Complex traffic

Тест позволяет генерировать и принимать несколько потоков тестового трафика.

Измеряет пропускную способность и величину потерь кадров (Frame Loss Rate, FLR), но не позволяет измерять постоянно задержку (FTD) и вариацию задержки (FDV).

Заключение

На смену методике RFC2544 приходит Y1564, которой собираюсь посвятить следующую статью.

Другие мои статьи

Продолжая просмотр сайта и(или) нажимая X , я соглашаюсь с использованием файлов cookie владельцем сайта в соответствии с Политикой в отношении файлов cookie в том числе на передачу данных, указанных в Политике, третьим лицам (статистическим службам сети Интернет), в соответствии с Пользовательским соглашением >X

Your browser version is too early. Some functions of the website may be unavailable. To obtain better user experience, upgrade the browser to the latest version.

Продукты, решения и услуги для организаций
NE40E-M2 V800R010C10SPC500 Feature Description - System Monitor 01
This is NE40E-M2 V800R010C10SPC500 Feature Description - System Monitor
Чтобы помочь вам лучше понять содержимое этого документа, компания Huawei перевела его на разные языки, используя машинный перевод, отредактированный людьми. Примечание: даже самые передовые программы машинного перевода не могут обеспечить качество на уровне перевода, выполненного профессиональным переводчиком. Компания Huawei не несет ответственность за точность перевода и рекомендует ознакомиться с документом на английском языке (по ссылке, которая была предоставлена ранее).
RFC 2544 Generalflow Test

Overview

An NQA general flow test is a standard traffic testing method for evaluating network performance and is in compliance with RFC 2544. This test can be used in various networking scenarios that have different packet formats. NQA general flow tests are conducted using UDP packets with source UDP port 49184 and destination UDP port 7.

Enables a device to send simulated service packets to itself before services are deployed on the device.

Existing methods include Y.1731 on Layer 2 networks and IP Flow Performance Management (IP FPM) on Layer 3 networks. These methods, unlike general flow tests, can only be used when services have been deployed on networks. If no services are deployed, testers must be used to send and receive test packets.

Uses standard methods and procedures that comply with RFC 2544 so that NQA general flow tests can be conducted on a network on which both Huawei and non-Huawei devices are deployed.

Test Procedure

A general flow test is an NQA test tool using UDP packets. An initiator (NQA client) initiates a general flow test and sends test packets to a reflector. After the test packets arrive at the reflector, the reflector interchanges the source and destination addresses in the packets and loops the packets to the initiator. The initiator counts the number of sent and received packets and calculates indicators based on timestamps carried in the packets.

A general flow test measures the following counters:
Packet loss rate: percentage of discarded packets to all sent packets.

Latency: consists of the bidirectional delay time and jitter calculated based on the transmission and receipt timestamps carried in test packets. The transmission time in each direction includes the time the forwarding devices process the test packet.

These counters are calculated in separate tests. A counter must be specified before a test is conducted.

On the network shown in Figure 4-21, UNI-A is an initiator, and UNI-B is a reflector. UNI-A and UNI-B conduct tests on the throughput, delay time, and packet loss rate.

Figure 4-21 General flow test networking

Throughput tests

Throughput tests are conducted to test throughput values by sending test packets at rates of the specified upper and lower rate thresholds or at rates in between. The difference between the test result and actual throughput must be less than a specified precision value. The test procedure is as follows:
1. The initiator sends test packets at a rate equal to the upper threshold. The network bandwidth is acceptable if no packet is dropped within a specified period or the packet loss rate is less than the configured test failure percentage. Then the test continues.
2. An initiator sends test packets at a rate equal to the lower threshold. The network bandwidth is acceptable if no packet is dropped within a specified period or the packet loss rate is less than the configured packet loss rate. Then the test continues.
If the packet loss rate tested based on the upper limit does not meet the customer expectation, conduct another test with a test rate obtained using the following formula: Upper limit test rate x (1 – Packet loss rate).

Latency tests

Latency tests can only be conducted when background traffic is being transmitted. An initiator sends background traffic at a specific rate and test packets at a specific interval to a reflector. The initiator then calculates the bidirectional delay time and jitter based on the transmission and receipt time.

Packet loss rate tests

An initiator sends test packets at a specific rate and interval to a reflector. Software collects statistics about the sent and received packets every second. The initiator stops sending test packets and counts the number of sent and received packets. The initiator then calculates the packet loss rate based on the statistics.
During a general flow test, modifying the system time of the testing device may affect the test duration and accuracy of the test result. Therefore, modifying the system time of a testing device is not recommended.
Applications

A general flow test can be used in the following scenarios:

Layer 2: native Ethernet, L2VPN (VLL and P2P VPLS) , EVPN

At present, EVPN supports only the EVPN MPLS scenario, not the EVPN VXLAN scenario.

Layer 3: native IP scenario and Layer 3 Virtual Private Network (L3VPN) scenario

IP gateway scenario

L2VPN accessing L3VPN scenario

Figure 4-22 General flow test networking

In both the Layer 2 and Layer 3 scenarios, a general flow test is performed between two UNIs on the network shown in Figure 4-22. The initiator sends test packets to the reflector. The reflector returns all test packets received by a reflector interface or only returns packets matching a specific filter condition. After the initiator receives the test packets, it collects statistics and yields test results based on the statistics.

Figure 4-23 General flow test in the IP Gateway scenario

On the network shown in Figure 4-23, a reflector functions as a switch. Layer 3 services on a user-side CE are sent to an IP gateway (initiator) through a Layer 2 network. A general flow test can be conducted in this scenario. The procedure is similar to that in the Layer 3 scenario.

Unlike the initiator in the Layer 3 scenario, the IP gateway cannot learn the MAC address of the reflector or CE. In this situation, you must configure static ARP entries on both the originator and reflector.

Figure 4-24 General flow test in an L2VPN accessing L3VPN scenario

If the initiator and reflector reside in locations 1 and 5 (or 5 and 1), respectively, or the initiator and reflector reside in locations 4 and 6 (or 6 and 4), respectively, it is a native Ethernet scenario.

If the initiator and reflector reside in locations 2 and 3 (or 3 and 2), respectively, it is a native IP scenario.

If the initiator resides in location 3 and the reflector in location 1, or the initiator resides in location 2 and the reflector in location 4, it is similar to an IP gateway scenario, and the simulated IP address must be configured on the L2VPN device.

If the initiator and reflector reside in locations 1 and 2 (or 2 and 1), respectively, or the initiator and reflector reside in locations 3 and 4 (or 4 and 3), respectively, it is an IP gateway scenario.

If the initiator resides in location 1 and the reflector in location 4, the initiator resides in location 1 and the reflector in location 3, or the initiator resides in location 4 and the reflector in location 2, it is an L2VPN accessing L3VPN scenario. In this scenario, the destination IP and MAC addresses and the source IP address must be specified on the initiator, and the destination IP address for receiving test flows must be specified on the reflector. If the initiator resides on the L2VPN, the simulated IP address must be specified as the source IP address.

Читайте также: