AAA

RFC 2544 — Методология тестирования устройств для соединения сетей

Статус документа

Этот документ содержит информацию для сообщества Internet. Документ не задает каких-либо стандартов Internet. Допускается свободное распространение документа.

Примечание IESG

Этот документ является воспроизведением RFC 1944 с корректировкой значений IP-адресов, которые были выделены для использования по умолчанию оборудованием для тестирования сетей (см. параграф C.2.2 ). Данный документ заменяет собой утративший силу RFC 1944.

Тезисы

В этом документе содержатся определения и обсуждение множества тестов, которые могут служить для определения параметров производительности устройств, используемых для соединения сетей. Кроме того, в документе описаны специфические форматы представления результатов тестирования. В Приложении A перечислены тесты и условия, которые в понимании авторов следует использовать в особых случаях, а также приведена дополнительная информация о практике тестирования. В Приложении B приведены справочные сведения о максимальных скоростях передачи кадров для различных технологий и размеров кадра. В Приложении C приведены примеры формата кадров, которые могут использоваться для тестирования.

1. Введение

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

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

Предшествующий документ "Benchmarking Terminology for Network Interconnect Devices" (RFC 1242) содержит определения множества терминов, используемых в этом документе. Рекомендуется прочесть документ, содержащий определения используемых терминов.

2. Реальный мир

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

3. Тесты для выполнения

В этом документе рассматривается множество текстов. Не каждый из рассмотренных тестов применим ко всем типам тестируемых устройств (DUT, device under test). Производителям следует проводить все тесты, которые могут поддерживаться конкретным типом продукции. Авторы понимают, что выполнение всех тестов во всех рекомендуемых условиях потребует достаточно продолжительного времени. Мы надеемся, что результаты этих тестов послужат оправданием затраченных сил. В Приложении A перечислены некоторые тесты и условия, которые по мнению авторов следует включать в конкретных случаях.

4. Оценка результатов

Выполнение всех рекомендуемых тестов будут давать значительный объем данных. Значительная часть этих данных применима в ограниченном контексте работы устройств. Например, скорость пересылки маршрутизатором пакетов IPX не имеет существенного значения при выборе маршрутизатора для сети, в которой не поддерживается (и не будет поддерживаться) этот протокол. Выбор данных, которые имеют отношение к конкретной инсталляции, требует определенного опыта, который на практике может отсутствовать. Более того, выбор тестов и оценка результатов тестирования должны осуществляться с пониманием общих принципов тестирования в части повторяемости результатов, их погрешности и статистической значимости небольшого числа попыток.

5. Требования

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

Должно (MUST) — это слово, а также слова требуется (REQUIRED) и нужно (SHALL) означает, что элемент является безусловно необходимым; Следует (SHOULD) — это слово, а также глагол рекомендуется (RECOMMENDED) используются в тех случаях, когда в определенных обстоятельствах требования допускается игнорировать, но делать это следует с пониманием и учетом всех обстоятельств; Возможно (MAY) — это слово, а также слово необязательно (OPTIONAL) используется для обозначения требований, выполнение которых отдается на усмотрение тестирующего; одни производители будут включать такие требования в связи с запросами рынка или по той причине, что это подчеркнет сильные стороны их продукции, а другой производитель может игнорировать такие требования.

Реализация, в которой не выполняется одно или несколько обязательных требований (должно — MUST), считается «не соответствующей» требованиям. Реализация, в которой выполняются все обязательные требования и рекомендации, считается «полностью соответствующей» требованиям, а реализация, в которой выполнены все обязательные требования, но не выполняется часть рекомендаций, считается «условно соответствующей».

6. Организация теста

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

>             +------------+
             |            |
+------------|  tester    |<-------------+
|            |            |              |
|            +------------+              |
|                                        |
|            +------------+              |
|            |            |              |
+----------->|    DUT     |--------------+
             |            |
             +------------+

Рисунок 1
+--------+         +------------+          +----------+
|        |         |            |          |          |
| sender |-------->|    DUT     |--------->| receiver |
|        |         |            |          |          |
+--------+         +------------+          +----------+

Рисунок 2

6.1. Организация теста для разнотипных сред

При тестировании DUT, которые используются в реальных сетях для подключения к разнотипным средам (например, ЛВС Ethernet к магистрали FDDI), могут использоваться два варианта конфигурации. Тестер может поддерживать оба типа сред и в этом случае может использоваться конфигурация, показанная на рисунке 1.

В другом варианте используется два идентичных DUT (Рисунок 3). Во многих случаях такая конфигурация может более точно имитировать реальные ситуации. Примером может служить соединение двух ЛВС по каналу WAN или высокоскоростной магистрали. Однако такая конфигурация не будет в должной мере соответствовать случаям, когда клиенты из ЛВС Ethernet взаимодействуют с сервером на магистрали FDDI.

                      +-----------+
                      |           |
+---------------------|  tester   |<---------------------+
|                     |           |                      |
|                     +-----------+                      |
|                                                        |
|        +----------+               +----------+         |
|        |          |               |          |         |
+------->|  DUT 1   |-------------->|   DUT 2  |---------+
         |          |               |          |
         +----------+               +----------+

Рисунок 3

7. Настройка DUT

До начала тестирования устройство DUT должно быть настроено в соответствии с инструкциями для пользователей. В частности, предполагается, что все поддерживаемые протоколы настроены и включены перед организацией теста (см. Приложение A). Предполагается, что все тесты будут выполняться без изменения настроек DUT за исключением выполнения требований соответствующих тестов. Например, недопустимо изменение размера буферов, обслуживающих кадры, в интервале между тестами, определяющими скорости обработки кадров, или запрет всех прочих транспортных протоколов во время тестирования одного протокола. Конфигурацию требуется менять при определении влияния фильтров на пропускную способность, но единственным изменением должно быть включение соответствующего фильтра. При настройке DUT следует задавать рекомендуемое значение интервала обновления маршрутных данных и частоты передачи сообщений keep alive. Номера версий используемых программ и точная конфигурация DUT (включая запрет тех или иных функций) в процессе тестирования должны быть включены в отчет о результатах тестирования.

8. Форматы кадров

Форматы тестовых кадров Ethernet для тестирования TCP/IP показаны в Приложении C. Такой формат кадров следует использовать в описанных здесь тестах для данной комбинации протокол-среда и применять в качестве шаблонов при тестировании в других комбинациях протоколов и сред. Специфические форматы, используемые в конкретном наборе тестов, должны включаться в отчет о результатах тестирования.

9. Размеры кадров

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

Теоретически минимальный кадр запроса UDP Echo будет содержать заголовок IP (не менее 20 октетов), заголовок UDP (8 октетов) и заголовок уровня MAC в соответствии с требованиями среды. Теоретический максимум для размера кадра определяется размером поля длины в заголовке IP. Почти во всех случаях значения минимального и максимального размера кадров задаются ограничениями среды.

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

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

9.1. Размеры кадров Ethernet

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

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

9.2. Размеры кадров Token Ring 4/16 Мбит/с

54, 64, 128, 256, 1024, 1518, 2048, 4472

Рекомендации по размерам кадров Token Ring предполагают отсутствие поля RIF в кадрах маршрутизируемых протоколов. Поле RIF будет присутствовать во всех тестах производительности мостов source route. Минимальный размер кадра для UDP в сети Token Ring составляет 54 октета. Для Token Ring 16 Мбит/с рекомендуется максимальный размер в 4472 октета вместо теоретического максимума 17,9 кбайт, поскольку многие интерфейсы Token Ring вносят такое ограничение. Остальные рекомендуемые значения выбраны для обеспечения возможности прямого сравнения между двумя разными типами сред. В дополнение могут использоваться кадры IP (т. е., не UDP), если желательно обеспечить наиболее высокую скорость передачи кадров, требующую снижения размера кадров до 46 октетов.

9.3. Размеры кадров FDDI

54, 64, 128, 256, 1024, 1518, 2048, 4472

Минимальный размер кадра для UDP в среде FDDI составляет 53 октета, но рекомендуется использовать минимальный размер 54, обеспечивающий возможность прямого сравнения с Token Ring. В качестве максимального размера рекомендуется использовать 4472 октета взамен рекомендуемого значения 4500, чтобы обеспечить возможность прямого сравнения с Token Ring. При необходимости обеспечить наиболее высокую скорость передачи кадров, можно использовать пакеты IP (т. е., не UDP), позволяющие сократить размер кадра до 45 октетов.

9.4. Размеры кадров в присутствии несоразмерных MTU

Когда соединенные между собой DUT поддерживают соединительные каналы с несовпадающими значениями MTU, следует использовать размер кадра для канала с «большим» MTU, вплоть до значения. Ограничиваемого протоколом. Если соединенные между собой DUT не поддерживают фрагментации кадров в случае несовпадения MTU, для соответствующего размера кадров в отчете следует указывать нулевую скорость пересылки.

Например, тестирование пересылки IP мостом или маршрутизатором, связывающим сети FDDI и Ethernet, следует использовать размеры кадров FDDI при передаче из сети FDDI в канал Ethernet. Если мост не поддерживает фрагментации IP, скорость пересылки кадров, которые слишком велики для Ethernet, следует указывать в отчете с нулевым значением.

10. Проверка полученных кадров

Тестовому оборудованию следует отбрасывать все полученные во время теста кадры, которые не относятся к тестированию. Например, кадры keep-alive и кадры маршрутных обновлений не следует включать в число принятых кадров. Во всех случаях тестовому оборудованию следует проверять размер принятых кадров на предмет соответствия ожидаемому значению.

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

11. Изменение условий тестирования

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

11.1. Широковещательные кадры

В большинстве маршрутизаторов требуется специальная обработка при получении кадров в аппаратным широковещательным адресом. В мостах (или маршрутизаторах, работающих в режиме моста) такие широковещательные кадры должны рассылаться во множество портов. В поток тестовых кадров следует добавлять 1% кадров с аппаратными широковещательными адресами. По широковещательному адресу следует слать кадры такого типа, который не требуется обрабатывать с помощью маршрутизатора. Целью включения таких кадров является определение наличия любого воздействия этих кадров на скорость пересылки других данных в потоке. Конкретные кадры, которые следует использовать, включены в описание форматов тестовых кадров. Широковещательные кадры следует равномерно размещать в потоке данных (например, каждый 100-й кадр является широковещательным).

Такой же тест следует выполнять на подобных мостам DUT, но в этом случае широковещательные пакеты будут обрабатываться и пересылаться во все выходные порты.

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

11.2. Кадры управления

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

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

11.3. Кадры маршрутных обновлений

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

Кадры маршрутных обновлений следует передавать с частотой, указанной в Приложении C для конкретного протокола, который будет использоваться при тестировании. В Приложении C приведены два примера кадров маршрутных обновлений для использования TCP/IP в среде Ethernet. Кадры обновлений предназначены для обновления маршрутизации во множество сетей, которые не участвуют в пересылке тестовых данных. Первый кадр устанавливает таблицу маршрутизации в состояние A, а второй переводит ее в состояние B. Кадры должны чередоваться в течение испытания.

В процессе тестирования следует удостовериться, что маршрутные обновления были обработаны устройством DUT.

11.4. Фильтры

Фильтры используются в маршрутизаторах и мостах для селективного запрета пересылки пакетов. Обычно фильтрация служит для реализации мер защиты на границе между областями (сетями). Возможности фильтрации существенно различаются в разной продукции.

Устройство DUT следует сначала настроить с заданием одного фильтра, разрешающего пересылку тестовых данных и после этого выполнить тест. Для маршрутизаторов следует использовать фильтры вида:

forward input_protocol_address to output_protocol_address

Для мостов следует использовать фильтры вида:

forward destination_hardware_address

После этого для DUT следует задать 25 фильтров. Для первых 24 фильтров следует использовать форму:

block input_protocol_address to output_protocol_address

Для 24 входных и выходных протокольных адресов не следует использовать какие-либо адреса, присутствующие в тестовом потоке данных. В последнем фильтре следует разрешить пересылку тестового потока данных. Порядок включения фильтров выбран таким, чтобы выполнялось 25 проверок до принятия решения о пересылке кадра. Если DUT меняет порядок фильтров или не использует линейного просмотра правил, упорядочение фильтров при вводе будет утрачено.

Точную конфигурацию фильтров следует включать в отчет о результатах тестирования.

11.4.1 Адреса в фильтрах

Для фильтров требуется два набора адресов — один для случая с одним фильтром и другой для 25 фильтров.

Одиночному фильтру следует разрешать трафик с IP-адреса 198.18.1.2 на адрес 198.19.65.2 и отвергать весь остальной трафик.

В случае с 25 следует использовать приведенный набор фильтров.

deny aa.ba.1.1 to aa.ba.100.1
deny aa.ba.2.2 to aa.ba.101.2
deny aa.ba.3.3 to aa.ba.103.3
  ...
deny aa.ba.12.12 to aa.ba.112.12
allow aa.bc.1.2 to aa.bc.65.1
deny aa.ba.13.13 to aa.ba.113.13
deny aa.ba.14.14 to aa.ba.114.14
  ...
deny aa.ba.24.24 to aa.ba.124.24
deny all else

Перед вводом фильтров следует удалить из маршрутизатора все ранее заданные фильтры. Выбранная последовательность позволяет понять, сортирует маршрутизатор правила фильтрации или принимает их в порядке ввода. Обе эти процедуры будут оказывать большее влияние на производительность, нежели та или иная форма хэширования.

12. Протокольные адреса

Реализация тестов упрощается при использовании одного логического потока данных с одним протокольным адресом отправителя и одним протокольным адресом получателя, а также некоторых условий типа описанных выше фильтров. Реальные сети не ограничиваются единственным потоком данных. Набор тестов следует выполнять сначала для одной пары протокольных (аппаратных для моста) адресов отправителя и получателя. После этого следует повторить тесты с использованием случайных адресов получателей. При тестировании маршрутизаторов адреса следует случайно или равномерно распределять в диапазоне 256 сетей, а при тестировании мостов случайно или однородно распределять по полному диапазону значения MAC для моста. Конкретные диапазоны адресов при тестировании IP даны в Приложении C.

13. Организация маршрутов

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

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

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

15. Один путь для потока

Следует выполнять полный набор тестов во всех подходящих условиях с использованием одного входного и выходного порта DUT. Если в устройстве DUT имеется множество разных путей (например, множество интерфейсных плат с множеством сетевых портов на каждой), следует тестировать каждый путь по отдельности.

16. Множество портов

Многие современные мосты и маршрутизаторы поддерживают множество сетевых портов на одном модуле. При тестировании первая половина портов назначается входными, а вторая — выходными портами. Порты следует распределить равномерно с учетом архитектуры DUT. Например, для DUT с двумя сетевыми платами, каждая из которых имеет по четыре порта, два порта каждой платы назначаются входными, а два других порта — выходными. Заданные тесты выполняются с использованием одинаковой скорости для каждого из входных портов. Адреса во входящем потоке данных следует устанавливать так, чтобы кадры поочередно направлялись в каждый из выходных портов с примерно равным распределением между ними. Такая же конфигурация может использоваться для двунаправленного многопотокового теста. В этом случае все порты рассматриваются как входные и выходные и каждый поток данных должен включать кадры, адресованные во все порты.

Рассмотрим 6-портовое устройство DUT, показанное на рисунке.

         --------------
---------| in A  out X|--------
---------| in B  out Y|--------
---------| in C  out Z|--------
         --------------

Для потоков данных следует задавать показанную ниже адресацию:

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

17. Множество протоколов

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

18. Множество размеров кадров

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

19. Тестирование более одного DUT

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

Эта модель полезна в тех случаях, когда кадры на входе и выходе однотипны (например, 64-байтовые пакеты IP в кадрах 802.3 на входе и выходе DUT) или метод тестирования может различать разнотипные входы и выходы (например, 1518-байтовые пакеты IP в кадрах 802.3 на входе и 576-байтовые фрагменты IP в кадрах X.25 на выходе).

При расширении теста для случая нескольких DUT могут собираться результаты, относящиеся ко множеству DUT или гетерогенным средам. В таком расширенном тесте одно устройство DUT заменяется системой соединенных через сеть DUT. Такая методология позволяет тестировать множество комбинаций из устройств/сред/протоколов/служб. Например, конфигурация теста ЛВС-WAN-ЛВС может иметь вид:

(1) 802.3-> DUT 1 -> X.25 @ 64кбит/с -> DUT 2 -> 802.3

Или может тестироваться смешанная конфигурация ЛВС:

(2) 802.3 -> DUT 1 -> FDDI -> DUT 2 -> FDDI -> DUT 3 -> 802.3

В обоих примерах (1 и 2) можно эмпирически оценить сквозные параметры каждой системы. , end-to-end benchmarks of each system could be empirically ascertained. Для оценки других параметров могут служить промежуточные устройства. В примере 2 можно оценить возможности передачи данных между сетями FDDI через DUT 2.

Поскольку множество DUT трактуется как единая система, у такой методологии имеются ограничения. Например, можно получить агрегированные параметры для тестируемой системы в целом, однако результаты теста могут не отражать асимметрию поведения устройств DUT, задержки, вносимые другими устройствами (например, CSU/DSU, коммутаторами) и т. п.

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

20. Максимальная скорость передачи кадров

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

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

Список максимальных скоростей передачи кадров для соединений ЛВС приведен в Приложении B.

21. Пиковый трафик

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

Задачей такого теста является определение минимального интервала между пиками, при котором DUT еще сможет обрабатывать трафик без потери пакетов. В процессе тестирования число пакетов в каждом пике сохраняется постоянным, а варьируется интервал между пиками. Тесты следует выполнять для пиков, содержащих 16, 64, 256 и 1024 кадра.

22. Число кадров на маркер

Несмотря на возможность настройки некоторых интерфейсов Token Ring и FDDI для передачи более одного кадра на каждый принятый маркер, большинство доступных в настоящее время устройств передают по одному кадру на маркер. При тестировании следует сначала выполнить проверку в таком режиме (один кадр на маркер).

Некоторые современные высокопроизводительные серверы передают более одного кадра на маркер для повышения производительности сетей FDDI. Поскольку в будущем такое поведение может стать общепринятым для рабочих станций и серверов, сетевые устройства с интерфейсом FDDI следует тестировать в режимах передачи с 1, 4, 8 и 16 кадрами на маркер. В отчете следует указывать среднюю скорость передачи кадров за все время тестирования.

23. Описание испытания

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

24. Продолжительность испытания

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

25. Преобразование адресов

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

26. Тестирование производительности

Примечание: Слова «тип потока данных» говорят об описанных выше модификациях потока кадров с постоянным межкадровым интервалом (например, добавление фильтров трафика в конфигурацию DUT.

26.1. Пропускная способность

Мы предполагаем, что если для рекламных целей требуется одно значение производительности, производитель будет выбирать минимальный размер кадров для среды. В таких случаях результат должен выражаться числом кадров в секунду. Скорость также может указываться в битах (или байтах) в секунду. Заявленная производительность должна включать: a) измеренное значение максимальной скорости передачи кадров, b) размер использованных кадров, c) теоретический предел скорости для данной среду при использованном размере кадров и d) протокол, использованный для тестирования. Даже в тех случаях, когда для рекламных целей используется одно значение в описание продукции следует включать всю таблицу результатов тестирования пропускной способности.

26.2. Задержка

Задержка составляет разницу значений B и A в соответствии с определением RFC 1242 (а именно, задержка для устройств пересылки или пересылки с промежуточным сохранением).

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

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

26.3. Частота потери кадров

Примечание: В разделе 18 рассмотрены максимальные значения скорости передачи кадров, которые следует использовать.

26.4. Кадры, передаваемые с минимальными интервалами

26.5. Восстановление системы

26.6. Перезагрузка

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

Время перезагрузки определяется как разность между моментами B и A.

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

27. Вопросы безопасности

Вопросы безопасности не рассматриваются в этом документе.

Адреса редакторов

Scott Bradner
Harvard University
1350 Mass. Ave, room 813
Cambridge, MA 02138
Phone: +1 617 495-3864
Fax: +1 617 496-8500
EMail: ude.dravrah@bos

Jim McQuaid
NetScout Systems
4 Westford Tech Park Drive
Westford, MA 01886
Phone: +1 978 614-4116
Fax: +1 978 614-4004
EMail: moc.tuocsten@jdiauqcm

Приложение A: Рассмотрение тестов

A.1. Роль этого приложения

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

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

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

  3. Нужно принимать во внимание вопросы архитектуры. Примером может служить выполнение теста с потоком трафика между портами одной интерфейсной платы и повторение тестов с портами разных интерфейсных плат. Почти во всех случаях эти две конфигурации относятся к лучшему и худшему варианту конфигурации теста для данной архитектуры DUT.

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

  5. Производительность сетей WAN может тестироваться путем установки двух идентичных устройств, соединенных с помощью модемов для имитации каналов WAN. Производительность измеряется между интерфейсами ЛВС двух устройств DUT.

Максимальная скорость передачи кадров в конфигурации ЛВС-WAN-ЛВС определяется оценкой, которая может быть основана на известных характеристиках системы в целом, включая эффекты компрессии, фрагментацию и скорость канала. На практике для скорости следует устанавливать значение не менее 110% от скорости самого медленного канала. Отдельное тестирование системы компрессии выходит за пределы данного документа.

Приложение B: Максимальные скорости передачи кадров

(Предоставил Roger Beeman, Cisco Systems)

 Size       Ethernet    16Mb Token Ring      FDDI
(bytes)       (pps)           (pps)         (pps)

 64          14880           24691         152439
 128          8445           13793          85616
 256          4528            7326          45620
 512          2349            3780          23585
 768          1586            2547          15903
 1024         1197            1921          11996
 1280          961            1542           9630
 1518          812            1302           8138

Размер кадров Ethernet
   Preamble 64 bits
   Frame 8 x N bits
   Gap  96 bits

Размер кадров Token Ring 16 Мбит/с
   SD               8 bits
   AC               8 bits
   FC               8 bits
   DA              48 bits
   SA              48 bits
   RI              48 bits ( 06 30 00 12 00 30 )
   SNAP
     DSAP           8 bits
     SSAP           8 bits
     Control        8 bits
     Vendor        24 bits
     Type          16 bits
   Data 8 x ( N - 18) bits
   FCS             32 bits
   ED               8 bits
   FS               8 bits

Маркеры и кадры бездействия (idle) между пакетами не указаны.

Размер кадров FDDI
   Preamble        64 bits
   SD               8 bits
   FC               8 bits
   DA              48 bits
   SA              48 bits
   SNAP
     DSAP           8 bits
     SSAP           8 bits
     Control        8 bits
     Vendor        24 bits
     Type          16 bits
   Data 8 x ( N - 18) bits
   FCS             32 bits
   ED               4 bits
   FS              12 bits

Приложение C: Форматы тестовых кадров

В этом приложении описаны форматы кадров, которые могут использоваться для тестирования. Кроме того, здесь приведены параметры TCP/IP в сетях Ethernet при использовании для тестирования.

C.1. Введение

Общая логика выбора параметров и форматов кадров для каждого случая рассматривается в разделе TCP/IP. Такая же логика используется и в других разделах. Комментарии приводятся лишь в тех случаях, когда нужно разъяснить специфику конкретного протокола. Параметры и форматы кадров для других протоколов пользователь может по аналогии определить самостоятельно.

C.2. Информация TCP/IP

В последующих параграфах приведена информация, связанная со стеком протоколов TCP/IP.

C.2.1. Тип кадров

Для протоколов, поддерживающих эхо-запросы прикладного уровня, при тестировании используются кадры с дейтаграммами таких запросов. Протокол передачи дейтаграмм используется для того, чтобы маршрутизатор не ожидал получения соответствующих инициализационных последовательностей, как в случаях использования потоковых протоколов с гарантированной доставкой данных. Конкретный протокол задается по той причине, что некоторые маршрутизаторы минимизации проверяют поле протокола в заголовке и могут отбрасывать пакеты неизвестных протоколов.

Для TCP/IP используются UDP-дейтаграммы Echo Request.

C.2.2. Протокольные адреса

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

Для этой цели агентством IANA были выделены сетевые адреса с 192.18.0.0 по 198.19.255.255, закрепленные за BMWG. Такое выделение адресов было предпринято для минимизации вероятности возникновения конфликтов при случайном подключении тестовой зоны к сети Internet. Специфика использования адресов рассмотрена ниже.

C.2.2.1. Протокольные адреса портов маршрутизаторов

Половину портов многопортового маршрутизатора мы называем «входными», а остальные — «выходными», даже в тех случаях, когда отдельные тесты используют все порты в качестве входных или выходных. Для «входных» портов резервируется непрерывный блок адресов в сетях класса C от 198.18.1.0 до 198.18.64.0. Второй блок (от 198.19.1.0 до 198.19.64.0) выделяется для «выходных» потов. Во всей случаях порт маршрутизатора является узлом 1 соответствующей сети. Например, 2-портовое устройство DUT будет иметь IP-адрес 198.18.1.1 на одном порту и 198.19.1.1 — на другом.

Некоторые из описанных тестов используют управляющее соединение с DUT по протоколу SNMP. Предполагается что для интерфейса управления DUT выделяется первый адрес из числа «входных» (198.18.1.1).

C.2.2.2. Адреса в кадрах

Некоторые из описанных тестов (например, проверка времени перезагрузки) предполагают маршрутизацию смежных сетей. IP-адрес в используемых для такого теста кадрах относится к узлу 2 соответствующей сети класса C (например, 198.19.1.2).

Если тест включает маршрутизацию несмежных сетей, фантомный маршрутизатор задается как узел 10 в соответствующей сети класса C. Группа сетей класса C от 198.18.65.0 до 198.18.254.0 используется для адресации устройств в сетях, доступных через фантомные маршрутизаторы на «входной» стороне DUT. Сети класса C от 198.19.65.0 до 198.19.254.0 выделены для адресации устройств, видимых через фантомные маршрутизаторы на «выходной» стороне DUT.

C.2.3. Частота маршрутных обновлений

Интервал обновления для каждого протокола маршрутизации может определяться спецификациями соответствующего протокола. Для IP RIP, Cisco IGRP и OSPF кадр или кадры маршрутных обновлений следует передавать за 5 секунд до каждого тестового потока. Такой частоты передачи обновлений достаточно для испытаний, продолжительностью до 60 секунд. При более длительных испытаниях кадры маршрутных обновлений следует включать в поток тестовых кадров. Периодичность передачи обновлений показана ниже.

IP-RIP30 секунд
IGRP90 секунд
OSPF90 секунд

C.2.4. Детальное обсуждение форматов кадров

C.2.4.1. Кадры обучения

В большинстве протоколов используется процедура отображения протокольных адресов на адреса MAC. В стеке TCP/IP для этого служит протокол преобразования адресов ARP. Для XNS и IPX такая процедура не требуется, поскольку MAC-адрес используется в качестве протокольного адреса узла.

В идеальном случае тестер будет способен отвечать на запросы ARP от DUT. В тех случаях, когда это невозможно, запросы ARP следует передавать в «выходной» порт маршрутизатора. Такой запрос следует рассматривать, как исходящий от конечного адресата тестового потока (т. е., фантомного маршрутизатора, как показано на рисунке 4 или конечного узла, если используется маршрутизация в смежную сеть). Предполагается, что маршрутизатор будет кэшировать MAC-адреса запрашивающих узлов. Запрос ARP следует передавать за 5 до начала передачи тестового потока в каждом испытании. Испытания продолжительностью более 50 могут потребовать увеличения тайм-аута ARP на маршрутизаторе.

          +--------+            +------------+
          |        |            |  phantom   |------ P LAN A
IN A------|   DUT  |------------|            |------ P LAN B
          |        |   OUT A    |  router    |------ P LAN C
          +--------+            +------------+

Рисунок 4: Случай использования полной маршрутизации

C.2.4.2. Кадры маршрутных обновлений

Если тест включает маршрутизации в сети, не являющиеся смежными, тестер должен обеспечить корректную маршрутную информацию с помощью маршрутных обновлений. Перед каждым испытанием для каждого порта «назначения» (см. параграф C.2.6.2) используется одно обновление маршрутных данных. Это обновление включает сетевые адреса, которые доступны через фантомный маршрутизатор в сети, подключенной к порту. При полносвязном тесте в маршрутном обновлении присутствует один адрес получателя для каждого из «входных» портов. Тестовый поток на каждом «входном» порту состоит из повторяющейся последовательности кадров (по одному на каждый «выходной» порт).

C.2.4.3. Кадры запросов управления

Тестирование издержек на управление использует протокол SNMP для запроса набора переменных, которые должны присутствовать во всех DUT, поддерживающих SNMP. Эти переменные для каждого интерфейса отдельно считываются NMS через заданные интервалы. Список переменных показан ниже:

sysUpTime
ifInOctets
ifOutOctets
ifInUcastPkts
ifOutUcastPkts

C.2.4.4. Тестовые кадры

Тестовые кадры представляют собой запросы UDP Echo Request с достаточным объемом данных для создания требуемого размера кадров. Данные не должны представлять собой набор только единиц или только нулей, поскольку такие последовательности могут приводить к активизации процессов добавления битов для обеспечения синхронизации каналов WAN, что, в свою очередь, ведет к увеличению размера кадров.

C.2.4.5. Форматы кадров — TCP/IP в сети Ethernet

Каждый из рассмотренных ниже кадров описывается для первой пары портов DUT («входного» порта 1 и «выходного» порта 1). Если кадры используются для других портов, адреса должны быть соответственно изменены.

C.2.6.1. Кадр «обучения»

Запрос ARP в сети Ethernet

 -- Заголовок дейтаграммы
 offset data (hex)            описание
 00     FF FF FF FF FF FF     широковещательный MAC-адрес для получателя
broadcast address
 06     xx xx xx xx xx xx     указывается MAC-адрес отправителя
 12     08 06                 тип ARP
 14     00 01                 тип оборудования (Ethernet = 1)
 16     08 00                 протокол (IP = 800)
 18     06                    размер аппаратного адреса (48 битов для Ethernet)
on Ethernet
 19     04                    размер протокольного адреса (4 октета для IP)
for IP
 20     00 01                 код операции для запроса = 1
 22     xx xx xx xx xx xx     MAC-адрес отправителя
 28     xx xx xx xx           MAC-адрес запрашивающего устройства DUT
 38     xx xx xx xx           IP-адрес запрашивающего устройства DUT

C.2.6.2. Кадр маршрутных обновлений

 -- Заголовок дейтаграммы
 offset data (hex)            описание
 00     FF FF FF FF FF FF     широковещательный MAC-адрес для получателя
 06     xx xx xx xx xx xx     аппаратный адрес отправителя
 12     08 00                 тип

 -- Заголовок IP
 14     45                    версия IP - 4,
                              размер заголовка (в 4-байтовых словах) - 5
 15     00                    поле сервиса
 16     00 EE                 общий размер
 18     00 00                 идентификатор (ID)
 20     40 00                 флаги (3 бита) 4 (не фрагментировать),
                              смещение фрагм. - 0
 22     0A                    время жизни (TTL)
 23     11                    протокол - 17 (UDP)
 24     C4 8D                 контрольная сумма заголовка
 26     xx xx xx xx           IP-адрес отправителя
 30     xx xx xx              IP-адрес получателя
 33     FF                    номер хоста = FF для широковещания

 -- UDP HEADER
 34     02 08                 порт отправителя 208 = RIP
 36     02 08                 порт получателя 208 = RIP
 38     00 DA                 размер сообщения UDP
 40     00 00                 контрольная сумма UDP

 -- Пакет RIP
 42     02                  команда/отклик (команда = 2)
 43     01                  версия = 1
 44     00 00               0

 -- сеть 1
 46     00 02               family = IP
 48     00 00               0
 50     xx xx xx            IP-адрес сети 1
 53     00                  сеть, а не узел
 54     00 00 00 00         0
 58     00 00 00 00         0
 62     00 00 00 07         метрика 7

 -- сеть 2
 66     00 02               семейство = IP
 68     00 00               0
 70     xx xx xx            IP-адрес сети 2
 73     00                  сеть, а не узел
 74     00 00 00 00         0
 78     00 00 00 00         0
 82     00 00 00 07         метрика 7

 -- сеть 3
 86     00 02               семейство = IP
 88     00 00               0
 90     xx xx xx            IP-адрес сети 3
 93     00                  сеть, а не узел
 94     00 00 00 00         0
 98     00 00 00 00         0
 102    00 00 00 07         метрика 7

 -- сеть 4
 106    00 02               семейство = IP
 108    00 00               0
 110    xx xx xx            IP-адрес сети 4
 113    00                  сеть, а не узел
 114    00 00 00 00         0
 118    00 00 00 00         0
 122    00 00 00 07         метрика 7

 -- сеть 5
 126    00 02               семейство = IP
 128    00 00               0
 130    00                  IP-адрес сети 5
 133    00                  сеть, а не узел
 134    00 00 00 00         0
 138    00 00 00 00         0
 142    00 00 00 07         метрика 7

 -- сеть 6
 146    00 02               семейство = IP
 148    00 00               0
 150    xx xx xx            IP-адрес сети 6
 153    00                  сеть, а не узел
 154    00 00 00 00         0
 158    00 00 00 00         0
 162    00 00 00 07         метрика 7

C.2.4.6. Кадр управляющего запроса

Будет определен.

C.2.6.4. Тестовые кадры

Запрос UDP echo в среде Ethernet

 -- Заголовок дейтаграммы
 offset data (hex)            Описание
 00     xx xx xx xx xx xx     MAC-адрес получателя
 06     xx xx xx xx xx xx     MAC-адрес отправителя
 12     08 00                 тип

 -- IP HEADER
 14     45                    версия IP - 4,
                              размер заголовка (в 4-байтовых словах) - 5
 15     00                    TOS (тип обслуживания)
 16     00 2E                 общий размер *
 18     00 00                 ID (идентификатор)
 20     00 00                 флаги (3 бита) 4 (не фрагментировать),
                              смещение фрагм. - 0
 22     0A                    TTL (время жизни)
 23     11                    протокол - 17 (UDP)
 24     C4 8D                 контрольная сумма заголовка *
 26     xx xx xx xx           IP-адрес отправителя **
 30     xx xx xx xx           IP-адрес получателя **

 -- UDP HEADER
 34     C0 20                 порт отправителя
 36     00 07                 порт получателя - 07 = Echo
 38     00 1A                 размер сообщения UDP *
 40     00 00                 контрольная сумма UDP

 -- UDP DATA
 42     00 01 02 03 04 05 06 07    произвольные данные ***
 50     08 09 0A 0B 0C 0D 0E 0F

  * - значение поля меняется в разных кадрах

 ** - меняется для разных логических потоков.

*** - Заполняют оставшуюся часть кадра нарастающими значениями с повторением,
      если требуется по размеру кадра.

Значения, используемые с полях общего размера и размера сообщений UDP:

frame size   total length  UDP message length
   64            00 2E          00 1A
   128           00 6E          00 5A
   256           00 EE          00 9A
   512           01 EE          01 9A
   768           02 EE          02 9A
   1024          03 EE          03 9A
   1280          04 EE          04 9A
   1518          05 DC          05 C8

Перевод на русский язык

Николай Малых, moc.milib@hkylamn