Методика RFC 2544

Материал из b4wiki
Перейти к: навигация, поиск

Методика тестирования устройств межсетевых соединений по RFC2544


Комментарии к RFC2544

Содержание

Abstract

RFC2544 [1] описывает и определяет набор тестов для определения характеристик устройств межсетевых соединений. Кроме тестов в документе описываются форматы представления результатов тестирования.

(1) Introduction

В документе используется терминология, описанная в [2].

(3) Tests to be run

Описанные в документе тесты не всегда все подходят для конкретного тестируемого устройства (DUT -- device under test). В этом случае необходимо проводить все те тесты, которые подходят.

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

(6) Test set up

В идеальном (общем) случае для проведения тестов требуется тестер с двумя портами - передающим и приемным. При наличии такого тестера все описываемые схемы в [1] реализуемы. Например, тестер посылает пакеты на передающий порт. Пакеты попадают на тестируемое устройство, которое отправляет их дальше, то есть на приемный порт тестера.

(7) DUT set up

Для проведения теста, DUT должен быть правильно настроен. Подразумевается, что:

  • на нем должны быть разрешены протоколы, которые описаны в Appendix.A
  • в ходе тестирования конфигурация DUT меняться не будет
  • DUT имеет правильно настроенный параметры: routing frequency и keep alive frequency

Допускаются изменения конфигурации DUT между тестами с целью настроек фильтров (эти настройки необходимы для ряда тестов). Точная конфигурация DUT должна содержаться в отчете.

(8) Frame formats

Для тестов TCP/IP over ethernet должны использоваться форматы кадров, описанные в Appendix.C Форматы кадров, использованные в тесте, должны быть приведены в отчете.

(9) Frame sizes

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

(9.1) Frame sizes to be used on Ethernet

При тестировании Ethernet должны использоваться следующие размеры:

64, 128, 256, 512, 1024, 1280, 1518

Эти размеры определены стандартом.

(9.4) Frame sizes in the presence of disparate MTUs

Если DUT поддерживает соединение с различными MTU (Maximum Transmission Unit),следует использовать размеры кадров для наибольшего MTU. Если DUT не поддерживает фрагментацию (и она необходима для дальнейшей передачи), то скорость(уровень) на принимающей стороне для такого размера кадров должна быть описана в отчёте как нулевая.

(10) Verifying received frames

Тестер должен отвергать все пакеты, не являющиеся тестовыми пакетами, посланными тестером. Например, пакеты "keep-alive" & "routing update" не должны включаться в статистику теста.

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

Следующее считается предпочтительным. Тестер должен вставлять в передаваемые пакеты последовательный счетчик и проверять на его приемной стороне. В результате в отчете должны появиться:

  • число отвергнутых пакетов
  • число пакетов, принятых не по порядку (последовательность приема пакетов отличается от последовательности счета счетчика)
  • число пакетов, принятых больше одного раза (несколько пакетов с одним и тем же значением счетчика)
  • число пропусков счета счетчика

Подобная функциональность требуется в ряде тестов.

(11) Modifiers

Может быть полезным узнать характеристики DUT при определенных условиях; некоторые приведены ниже. Отчёт должен содержать столько условий, сколько способно сгенерировать тестирующее оборудование. Сначала надо провести тесты без каких-либо изменяющих условий, а потом повторить с каждым из них по отдельности. Чтоб иметь возможность сравнить результаты, каждый кадр, требующийся для генерации модифицирующих условий, должен быть включен в тот же поток данных, что и обычные тестовые кадры, вместо одного из кадров, а не доставлен на отдельный порт DUT.

(11.1) Broadcast frames

В реализации большинства роутеров (и в мостах) требуется специальная обработка аппаратных широковещательных кадров.

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

Цель теста: проверить наличие эффекта на скорость. Использованные особые кадры должны быть включены в документацию. Широковещательные кадры следует ровно распределить по потоку данных, например, каждый 100-й кадр.

(11.2) Management frames

В сети используются управляющие протоколы (напр., SNMP). Бывает, что одновременно на один и тот же DUT отправляются несколько управляющих запросов.

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

(11.3) Routing update frames

Обработка dynamic routing protocol updates может оказать существенное влияние на способность роутера передавать кадры. К тестовому потоку сдедует добавить один routing update frame. отправляемый как первый кадр в тестовом испытании. Routing update frame следует отправлять на определенной скорости, указанной в Appendix C.

В тесте следует проверить, что routing update был обрадотан DUT.


(12) Protocol Addresses

Описываемые тесты проще применять, используя единый логический поток данных, с одним "исходящим" адресом и одним адресом - получателем. А для некоторых случаев это условие является необходимым требованием для успешного проведения теста(см. пункт 11). В реальных же сетях потоки данных направляются по разным адресам.

В этой связи тесты нужно разделить на 2 типа: для роутера и бриджа. В случае с роутером речь идет об адресах, определяемых протоколом, в случае с бриджем - о физических адресах.

Для ethernet'a тест роутера выполняется с использованием IP-адресации, а тест бриджа - с использованием MAC-адресации.

Сначала тест должен проводится с одной парой адресов отправитель-получатель, а затем:

  1. Со случайным распределением адресоов получателя
  2. С равномерным перебором адресов получателя в рамках, определенных в Appendix.C

(13) Route set up

Настройка маршрута.

При тесте маршрутизаторов информацию о маршруте, по которому направляется тестовый поток, настраивать в ручную не разумно. Особенно в случае с перебором адресов получателя.

В начале каждой попытки при тестировании _необходимо_ посылать "routing update" DUT'у. В "routing update" должны содержаться все адреса, используемые в данной попытке. Все используемые адреса быть переадресованы на один адрес, который является адресом приемника тестера. "routing update" должен повторно отсылаться в соответвии с Appendix.C.

(14) Bidirectorial traffic

Двунаправленный трафик.

В реальных сетях обмен происходит в обоих направлениях - и на прием и на передачу. Для того, чтобы протестировать DUT в двунаправленном режиме, необходимо запускать тесты в обоих направлениях. Оба направления должны использовать одинаковые скорости. Очевидно, сумма скоростей не должна превышать теоретического предела тестируемого тракта.

(15) Single stream path

В случае если тестируется сложное DUT, где количество выходов превышает 1, необходимо тестировать раздельно все возможные комбинации вход-выход.

(16) Multi-port

Если тестируется сложное DUT с большим количеством входных/выходных портов, половина портов настраивается на выход, половина - на вход. Адреса пакетов, поступающих на входной порт, должны быть настроены таким образом, чтобы на все выходные порты было направлено одинаковое количество пакетов.

В RFC приведен пример с 6-ти портовым DUT, где все порты разделяются на 3 входа и 3 выхода.

(17) Multiple protocols

В данным RFC не предусмотрено тестирование смешанных протоколов. Однако, если такие тесты требуются, то пакеты должны быть распределены "между протоколами". Распределение может усреднять состояния сети, в которой используется DUT.

Имеется ввиду, видимо, что в тесте должны присутствовать пакеты всех протоколов в режиме multiple protocols.

(18) Multiple frame sizes

Идея та же, что и в #17. Multiple protocols . RFC не предусматривает использование тестовых потоков с разными размерами кадров. Однако, если это нужно, что в потоке должны быть распределены пакеты разных размеров. Авторы RFC не знают как интерпретировать результаты такого теста, кроме как сравнивать результаты теста для разных DUT в некоей очень специфической сети.

(19) Testing performance beyond a single DUT

Тестирование одиночного DUT сводится к подключению ко входу DUT и мониторингу выхода DUT. Результат мониторинга может использоваться для определения базовых характеристик этого устройства при данной конфигурации теста.

Такая модель применима, когда:

  • тестовый вход и выход DUT имеют одинаковую "природу". То есть, например, они соответствуют 802.3 (Ethernet) и используют 64 байтные пакеты.
  • тестовый вход и выход DUT имеют разную "природу". Например на входе Ethernet + 1518 байтовый пакет, на выходе X.25, 576 байтовый пакет, фрагментированный IP.

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

  1. 802.3(Ethernet) -> DUT1 -> X.25 @ 64kbps -> DUT2 -> 802.3 (Ethernet)
  2. 802.3(Ethernet) -> DUT1 -> FDDI ->DUT2 -> FDDI -> DUT3 -> 802.3 (Ethernet)

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

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

(20) Maximum frame rate

Максимальная скорость следования пакетов, используемая при тестировании соединений LAN(WAN), должна быть равной (больше) теоретическому максимуму для данного соединения и для данного размера кадра.

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

Значения максимумов для LAN - в Appendix B.

(21) Bursty traffic

Наиболее часто встречающийся трафик в современных сетях - лавинообразен (burst traffic). То есть время от времени передаются большие объемы пакетов, а в остальное время передача пакетов более умеренна. Некоторые тесты, описанные ниже, должны выполняться и при неизменном состоянии трафика, и при периодически повторяющихся burst-последовательностях. Между передачами проходит фиксированное время T, а между пакетами внутри передачи должно проходить минимально возможное для данного соеднения время (inter-frame gap).

Цель теста - определить минимальное T, такое, чтобы DUT успел обрабатывать пакеты с нулевыми потерями (no frame loss). В ходе теста количество пакетов в посылке всегда одинаково, а время между посылками варьируется. Тест должен проводиться для размеров посылки 16, 64, 256, 1024 кадров.

(22) Frames per token

Видимо, относится к сетям Token Ring, FDDI. Суть в том, что во время тестов на каждый маркер(token) должен передаваться только один пакет.

Если передача нескольких пакетов на 1 маркер - это свойство тестируемой системы, то такие системы нужно тестировать, используя соотношения 1, 4, 8, 16 кадров на маркер.

(23) Trial description

Тест содержит несколько попыток (trial). Результатом выполнения каждой попытки становится некоторое количество информации о результатах измерений (например, частоту потери кадров для нескольких скоростей передачи кадров). Каждая попытка содержит несколько фаз:

  1. если DUT - роутер, ему необходимо послать "routing update" на входной порт. Затем подождать 2 секунды, чтобы быть уверенным, что роутинг настроен.
  2. послать "learning frames" на выходной порт DUT. Подождать 2 секунды. "learning frame" для bridge - это кадры, в которых адрес назначения равен адресу источника, используемому в тесте. "learning frame" для других протоколов используются для "натаскивания" таблиц адресов DUT. Формат "learning frame" - Appendix.C
  3. запустить тест
  4. ждать 2 секунды, чтобы дождаться (возможно) прихода остаточных пакетов
  5. ждать минимум 5 секунд, чтобы дать DUT'у прийти в себя ;)

(24) Trial duration

Цель тестов - определить скорость, непрерывно поддерживаемую тестируемым устройством DUT. Длительность попытки должна быть компромиссом между этой целью и длительностью всего набора тестов. Длительность тестовой фазы в каждой попытке должна быть минимум 60 секунд.

Тесты, которые включают в себя "бинарный поиск" (в любом виде), например, throughput тест, для определения точного результата могут использовать более короткое время попытки с целью минимизировать время поиска. Но при финальном определении попытка должна укладываться в указанные требования.

(25) Address resolution

DUT должен отвечать на запросы "address resolution"(запросы ARP), посланные DUT'ом, независимо от того, требует ли этого протокол.

(26) Benchmarking tests

Note: нотация "type of data stream" (тип потока данных) относится к модификации потока кадров с постоянным межкадровым интервалом.

(26.1) Throughput

Задача: определить пропускную способность DUT в соответствии с RFC1242 [2]

Процедура: послать некоторое количество пакетов Ntp на определенной скорости Rp на входной порт DUT. Посчитать пакеты, пришедшие с выходного порта DUT - Nrp. Если Nrp < Ntp, скорость Rp уменьшается и тест запускается снова.

Throughput - это максимальное Rpm=Rp, при котором выполняется равенство Nrp=Ntp.

Формат отчета: результаты рекомендуется представлять в виде графика. По оси Х - размер пакета Sp, по оси У - Rpm. На графике должно быть как минимум 2 линии: одна представляет собой теоритечскую кривую, другая - экспериментальную. Экспериментальных линий может быть несколько - для разных типов потоков данных. График должен содержать пояснения в текстовом виде: протокол, тип соединения, формат потока данных.

(26.2) Latency

Задача: определить задержку в соответствии с RFC1242 [2].

Процедура: сначала определяется Rpm #26.1 Throughput для кажого размера пакета. Для каждого размера пакета Sp на соответствующей ему максимальной скорости Rpm посылается поток пакетов по определенному адресу. Поток должен иметь длительность минимум 120 секунд. В 1 пакет по прошествии 60 секунд вставляется метка. Формат метки - implementation dependent. На передающей стороне записывается время Ta - время, к которому пакет с меткой был полностью отправлен. На приемной стороне определяется метка и записывается время Tb - время полного приема пакета с меткой. Задержка (latency) - это разница Tb - Ta. В [2] есть 2 определения latency - необходимо выбрать для данного DUT, какое нам подходит.

Этот тест должен повторяться минимум 20 раз. По результатам 20 измерений вычисляется средняя задержка.

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

Формат отчета: отчет должен включать одно из двух определений latency по [2], которое использовалось в тесте. Представление отчета - таблица. В строке должен быть размер кадра. В столбце - значения latency для каждого размера кадра. Например, в устройствах sunset в столбце представлены минимальные/максимальные/средние значения задержек.

(26.3) Frame loss rate

Задача: определить частоту потери кадров в соответсвии с RFC1242 [2].

Процедура: на входной порт DUT посылается определенное количество кадров Ntp на определенной скорости Rp и подсчитывается количество пакетов Nrp, принимаемых от выходного порта DUT. Частота потери кадров LRp рассчитывается следующим образом:

LRp = ((Ntp - Nrp) * 100) / Ntp;

Первая попытка должна проходить на максимальной скорости для данного соединения. Следующая попытка должна проходить на 90% от максимальной скорости, а затем - на 80%. Повторение попыток с уменьшением скорости тестового потока на 10% должно продолжаться до тех пор, пока 2 попытки подряд не будут полностью безошибочными (LRp = 0). Максимальный шаг уменьшения скорости - 10%. Меньший шаг - приветствуется.

Формат отчета: график. X - обязательно скорость потока на входном порте DUT в виде процентного отношения к максимальной пропускной способности соединения. Y - обязательно LRp для данной скорости. График может содержать несколько кривых - для каждого размера пакета (протокола и т.п.) своя кривая.

(26.4) Back-to-back frames

Задача: оценить способность тестируемого DUT обрабатывать back-to-back кадры [2] (имеется ввиду способность DUT обрабатывать кадр за кадром - "спиной к спине").

Процедура: тест сводится к отсылке некого количества кадров Ntp с минимальной межкадровой задержкой на вход DUT и подсчету пакетов с выхода DUT - Nrp. Если Nrp = Ntp, то Ntp увеличивается и тест повторяется. Иначе (Nrp < Ntp) - Ntp уменьшается и тест повторяется.

Значение back-to-back - Nbb - это максимальное Ntp, которое DUT обработало без потерь кадров. Длительность одной попытки _обязательно_ должна быть не менее 2 секунд. Минимальное количество попыток - 50 раз. Результаты попыток усредняются и получается среднее значение Nbb.

Формат отчета: таблица. В строке - размер кадра. В столбце - Nbb для данного размера кадра. Наверное, по аналогии с latency, имеет смысл в таблице отображать минимальное/максимальное/среднее Nbb.

(26.5) System recovery

Задача: измерить время, за которое DUT восстановится после перегрузки.

Процедура: Сначала необходимо провести полный тест throughput.

На вход DUT в течение минимум 60 секунд отсылается поток кадров со скоростью 110% относительно измеренной тестом throughput. Если тест throughput показал идеальные результаты, то скорость отсылки кадров выбирается равной максимуму для данного соеднинения. В момент времени А Ta скорость потока уменьшается в два раза и засекается время Tb, в которое был потерян последний кадр. Время восстановления DUT (system recovery time) Tsr = Tb - Ta. Тест должен повторяться несколько раз, а результаты - усредняться.

Формат отчета: таблица. В строке - размер кадра. В столбце - время восстановления, скорость, на которой проводился тест.

(26.6) Reset

Задача: измерить время, которое проходит с момента аппаратного или программного сброса DUT до момента полной работоспособности.

Процедура: сначала необходимо пройти тест throughput для минимального размера кадра.

Посылается непрерывный поток кадров на скорости, определенной в результате теста throughput. Устройство DUT сбрасывается. Аппаратный сброс требует, чтобы питание DUT отсутствовало как минимум 10 секунд. Программный сброс - не требует. Время Та - время приема последнего пакета до сброса. Время Тb - время приема первого пакета после сброса. Время восстановления после сброса Trr = Tb - Ta.

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

Формат отчета: простой. для каждого типа сброса - свое значение времени восстановления.

Литература, ссылки

  1. RFC2544 Benchmarking Methodology for Network Interconnect Devices, http://www.faqs.org/rfcs/rfc2544.html
  2. RFC1242 Benchmarking Terminology for Network Interconnect Devices, http://www.faqs.org/rfcs/rfc1242.html
  3. RFC791 Internet Protocol, http://www.faqs.org/rfcs/rfc791.html
Личные инструменты
Пространства имён

Варианты
Действия
разработки
технологии
разное
Инструменты