RFC 2544 Benchmarking Methodology for Network Interconnect Devices

Опубликовано 21.03.1999 автором Nikolai Malykh 
Network Working Group                                     S. Bradner
Request for Comments: 2544                        Harvard University
Obsoletes: 1944                                           J. McQuaid
Category: Informational                             NetScout Systems
                                                          March 1999

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

Benchmarking Methodology for Network Interconnect Devices

PDF

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

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

Авторские права

Copyright (C) The Internet Society (1999). All Rights Reserved.

Примечание IESG

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

Аннотация

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

1. Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

                            +------------+
                            |            |
               +------------|   тестер   |<-------------+
               |            |            |              |
               |            +------------+              |
               |                                        |
               |            +------------+              |
               |            |            |              |
               +----------->|    DUT     |--------------+
                            |            |
                            +------------+

Рисунок 1 

      +-----------+         +------------+          +----------+
      |           |         |            |          |          |
      |отправитель|-------->|    DUT     |--------->|получатель|
      |           |         |            |          |          |
      +-----------+         +------------+          +----------+

Рисунок 2

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

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

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

                               +-----------+
                               |           |
         +---------------------|  тестер   |<---------------------+
         |                     |           |                      |
         |                     +-----------+                      |
         |                                                        |
         |        +----------+               +----------+         |
         |        |          |               |          |         |
         +------->|  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-й кадр является широковещательным).

Такой же тест следует выполнять на подобных мостам4 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 должно передаваться обновление маршрутных данных. Это обновление должно включать все сетевые адреса, которые потребуются при тестировании. Все эти адреса следует преобразовывать в один следующий интервал маршрутизации5. Обычно это адрес приемной части тестового оборудования. Обновление маршрутных данных следует повторять через интервалы, определяемые используемым протоколом маршрутизации. Пример формата кадров обновлений и сведения об интервалах обновления приведены в Приложении C.

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

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

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

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

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

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

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

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

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

поток, передаваемый на вход A:

пакеты в выходные интерфейсы X, Y, Z

поток, передаваемый на вход B:

пакеты в выходные интерфейсы X, Y, Z

поток, передаваемый на вход C

пакеты в выходные интерфейсы X, Y, 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) можно эмпирически оценить сквозные параметры каждой системы. Для оценки других параметров могут служить промежуточные устройства. В примере 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. Описание испытания

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

  1. Если DUT представляет собой маршрутизатор, сначала передается обновление маршрутных данных на «входной» порт и задается пауза в две секунды для пересчета маршрутов.
  2. Передаются «кадры обучения» в «выходной порт» и устанавливается пауза в две секунды для завершения самообучения моста. Обучающие кадры для моста представляют собой кадры, в которых адрес отправителя совпадает с адресом получателя, используемым в тестовых кадрах. Кадры обучения для других протоколов служат для заполнения таблицы преобразования адресов в DUT. Для эти кадров следует использовать форматы, указанные в документе Test Frame Formats6.
  3. Выполняется испытание.
  4. Устанавливается пауза в две секунды для получения всех остающихся в сети кадров.
  5. Устанавливается пауза не менее пяти секунд для стабилизации DUT.

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

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

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

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

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

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

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

Цель: Определение пропускной способности DUT в соответствии с RFC 1242.

Процедура: Через DUT передается заданное число кадров с указанной скоростью и определяется число кадров, переданных DUT. Если счетчик переданных DUT кадров совпадает с числом принятых, скорость увеличивается и испытание повторяется. Если число переданных кадров меньше числа пропущенных, испытание повторяется после снижения скорости.

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

Описание результатов: Результаты теста пропускной способности следует представлять в виде графика. В этом случае по оси x следует указывать размер кадров, а по оси y — скорость передачи кадров. На графике следует указывать по крайней мере две линии, одна из которых показывает теоретическое значение скорости передачи кадров разного размера для данного типа среды. С помощью второй линии следует показывать реальные результаты теста. Можно также выводить дополнительные графики, показывающие результаты теста для разных типов потока данных. В сопровождающем график тексте следует указывать протокол, тип потока данных и тип среды, использованные при тестировании.

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

26.2 Задержка

Цель: Определение задержки в соответствии с RFC 1242.

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

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

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

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

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

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

Цель: Определение частоты потери кадров в соответствии с RFC 1242 во всем диапазоне скоростей данных на входе и размеров кадра.

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

((input_count - output_count) * 100) / input_count

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

Описание результатов: Результаты определения частоты потери кадров следует представлять в форме графика. В этом случае по оси X должна указываться скорость передачи кадров на входе в процентах от теоретического максимума для данной среду при конкретном размере кадров. По оси Y должны указываться потери кадров в процентах. Начальные точки обеих осей должны соответствовать нулевым значениям, а конечные – 100 %. На графике могут выводиться несколько линий, соответствующих потерям кадров различного размера, разных протоколов и типов потока данных.

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

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

Цель: Определение возможностей DUT по обработке кадров back-to-back7 в соответствии с определением RFC 1242.

Процедура: Устройству DUT передаётся импульс (блок) кадров с минимальными межкадровыми интервалами и подсчитывается число кадров, пересланных устройством DUT. Если число переданных кадров совпадает с числом пересланных устройством на протяжении всего импульса, блок кадров увеличивается и испытание повторяется. Если число пересланных устройством кадром меньше числа переданных, размер блока уменьшается и испытание повторяется.

Значение back-to-back определяется числом кадров в максимальном блоке, который устройство DUT смогло обработать без потери кадров. Продолжительность испытания должна быть не менее 2 секунд, а испытания следует повторять не менее 50 раз с усреднением значений.

Описание результатов: Результаты теста back-to-back следует представлять в форме таблицы со строкой для каждого размера кадров, использованного при тестировании. В таблицу следует включать колонки размера кадров и среднего числа кадров в блоке для каждого типа потока данных. Можно также указывать в отчете величину стандартного отклонения для каждого измерения.

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

Цель: Определение скорости восстановления DUT после перегрузки.

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

Передается поток кадров со скоростью 110% от пропускной способности или максимальной скоростью среды (выбирается меньшее из 2 значений) в течение по крайней мере 60 секунд. В момент A интенсивность трафика снижается вдвое и записывается момент последней потери кадра (момент B). Время восстановления системы определяется как разность времен B и A. Тест следует повторить многократно и включить в отчет среднее время восстановления.

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

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

Цель: Определение скорости восстановления DUT после программного или аппаратного сброса (перезагрузки).

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

Передается непрерывный поток кадров с определенной пропускной способностью для минимального размера кадров. Выполняется сброс DUT с мониторингом выходного порта с записью времени последнего кадра перед сбросом (момент A) и первого кадра после сброса (момент B). При тестировании сброса по прерыванию питания выполняются такие же операции, но перезагрузка заменяется отключением питания DUT на 10 секунд.

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

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

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

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

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

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

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

Scott Bradner

Harvard University

1350 Mass. Ave, room 813

Cambridge, MA 02138

Phone: +1 617 495-3864

Fax: +1 617 496-8500

EMail: sob@harvard.edu

 

Jim McQuaid

NetScout Systems

4 Westford Tech Park Drive

Westford, MA 01886

Phone: +1 978 614-4116

Fax: +1 978 614-4004

EMail: mcquaidj@netscout.com

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

Николай Малых

nmalykh@protokols.ru

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

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

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

  1. Обычной практикой при тестировании является разрешение всех протоколов, которые будут тестироваться, и выполнение всех тестов без дополнительной настройки протоколов даже в тех случаях, когда для конкретного испытания нужен единственный протокол. Такой подход позволяет минимизировать работы при настройке DUT для каждого протокола.
  2. Следует использовать наиболее распространенные функции фильтрации для обеспечения возможности сравнения тестов продукции разных производителей. В силу различий между продукцией, выполнение таких тестов и оценка их результатов могут зависеть от конкретного мнения по этому вопросу.
  3. Нужно принимать во внимание вопросы архитектуры. Примером может служить выполнение теста с потоком трафика между портами одной интерфейсной платы и повторение тестов с портами разных интерфейсных плат. Почти во всех случаях эти две конфигурации относятся к лучшему и худшему варианту конфигурации теста для данной архитектуры DUT.
  4. Тестирование с использованием потоков трафика, содержащего множество протоколов, не показывает существенных отличий от тестирования с применением монопротокольного трафика. Т. е., если результаты тестирования производительности для протоколов A и B различаются, тестирование при использовании смешанного трафика будет давать промежуточный результат.
  5. Производительность сетей WAN может тестироваться путем установки двух идентичных устройств, соединенных с помощью модемов для имитации каналов WAN. Производительность измеряется между интерфейсами ЛВС двух устройств DUT.

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

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

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

Размер (байт)

Скорость передачи (кадр/сек)

Ethernet

Token Ring 16 Мбит/с

FDDI

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

Преамбула 64 бита

Кадр 8 x N битов

Интервал 96 битов

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

SD 8 битов

AC 8 битов

FC 8 битов

DA 48 битов

SA 48 битов

RI 48 битов (06 30 00 12 00 30)

SNAP

DSAP 8 битов

SSAP 8 битов

Control 8 битов

Vendor 24 бита

Type 16 битов

Данные 8 x ( N – 18) битов

FCS 32 бита

ED 8 битов

FS 8 битов

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

Размер кадров FDDI

Преамбула 64 бита

SD 8 битов

FC 8 битов

DA 48 битов

SA 48 битов

SNAP

DSAP 8 битов

SSAP 8 битов

Control 8 битов

Vendor 24 битов

Type 16 битов

Данные 8 x ( N – 18) битов

FCS 32 битов

ED 4 бита

FS 12 битов

Приложение 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-RIP 30 секунд

IGRP 90 секунд

OSPF 90 секунд

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

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

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

                 +--------+            +-------------+
                 |        |            |   фантомный |------ P LAN A
       IN A------|   DUT  |------------|             |------ P LAN B
                 |        |   OUT A    |маршрутизатор|------ P LAN C
                 +--------+            +-------------+

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

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

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 с достаточным объемом данных для создания требуемого размера кадров. Данные не должны представлять собой набор только единиц или только нулей, поскольку такие последовательности могут приводить к активизации процессов добавления битов9 для обеспечения синхронизации каналов WAN, что, в свою очередь, ведет к увеличению размера кадров.

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

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

C.2.6.1 Кадр “обучения”

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

   -- Заголовок дейтаграммы
Смещение  Данные (hex)       описание
   00     FF FF FF FF FF FF  широковещательный MAC-адрес для получателя
   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)
   19     04                 размер протокольного адреса (4 октета для IP)
   20     00 01              код операции для запроса = 1
   22     xx xx xx xx xx xx  MAC-адрес отправителя
   28     xx xx xx xx        IP-адрес отправителя
   32     FF FF FF FF FF FF  MAC-адрес запрашивающего устройства DUT
   38     xx xx xx xx        IP-адрес запрашивающего устройства DUT
C.2.6.2 Кадр маршрутных обновлений
   -- Заголовок дейтаграммы
Смещение  Данные (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
  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              семейство = 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

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

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

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

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

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

размер кадра общий размер размер сообщения UDP
   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

Полное заявление авторских прав

Copyright (C) The Internet Society (1999). Все права защищены.

Этот документ и его переводы могут копироваться и предоставляться другим лицам, а производные работы, комментирующие или иначе разъясняющие документ или помогающие в его реализации, могут подготавливаться, копироваться, публиковаться и распространяться целиком или частично без каких-либо ограничений при условии сохранения указанного выше уведомления об авторских правах и этого параграфа в копии или производной работе. Однако сам документ не может быть изменён каким-либо способом, таким как удаление уведомления об авторских правах или ссылок на Internet Society или иные организации Internet, за исключением случаев, когда это необходимо для разработки стандартов Internet (в этом случае нужно следовать процедурам для авторских прав, заданных процессом Internet Standards), а также при переводе документа на другие языки.

Предоставленные выше ограниченные права являются бессрочными и не могут быть отозваны Internet Society или правопреемниками.

Этот документ и содержащаяся в нем информация представлены “как есть” и автор, организация, которую он/она представляет или которая выступает спонсором (если таковой имеется), Internet Society и IETF отказываются от каких-либо гарантий (явных или подразумеваемых), включая (но не ограничиваясь) любые гарантии того, что использование представленной здесь информации не будет нарушать чьих-либо прав, и любые предполагаемые гарантии коммерческого использования или применимости для тех или иных задач.

1Device under test — тестируемое устройство.

2Исходный документ распространяется в текстовом формате, поэтому уровни требования выделяются заглавными буквами. Прим. перев.

3В оригинале это предложение содержит опечатку, отмеченную в RFC Errata (http://rfc-editor.org/errata_search.php?rfc=2544). Прим. перев.

4В оригинале «bridge-like». Прим. перев.

5Next-hop.

6Форматы тестовых кадров.

7Кадры, передаваемые с минимальным для данной среды интервалом.

8Address Resolution Protocol.

9bit stuffing

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

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

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

Запись опубликована в рубрике RFC, Измерения и тестирование. Добавьте в закладки постоянную ссылку.