Сетевая рабочая группа Y. Mu
 Интернет-проект ЦАИКТ
 Предполагаемый статус: информационный 10 октября 2022 г.
 Истекает: 10 октября 2022 г.
 Рекомендации по тестированию сетевых операционных систем
 черновик-mu-nos-тестирование-01
 Статус этого меморандума
 Настоящий Интернет-проект представлен в полном соответствии с
 положения BCP 78 и BCP 79.
 Интернет-Черновики являются рабочими документами Интернет Инженерной Задачи.
 Force (IETF), его направления и рабочие группы. Обратите внимание, что другие
 группы также могут распространять рабочие документы в виде Интернет-проектов.
 Список текущих интернет-драфтов можно найти по адресу
 https://www.ietf.org/1id-abstracts.html
 Интернет-проекты – это проекты документов, действительные не более шести месяцев.
 и могут быть обновлены, заменены или устаревшими другими документами в любое время.
 время. Неуместно использовать Internet-Drafts в качестве справочного материала.
 материал или цитировать их, кроме как «в процессе».
 Список теневых каталогов Internet-Draft доступен по адресу https://www.ietf.org/shadow.html.
 В этом меморандуме содержится информация для интернет-сообщества. Оно делает
 не указывать какой-либо стандарт Интернета. Распространение этого
 Памятка не ограничена.
 Уведомление об авторских правах
 Авторское право (с) 2009IETF Trust и лица, указанные в качестве
 авторы документа. Все права защищены.
 Этот документ регулируется BCP 78 и юридическими документами IETF Trust.
 Положения, касающиеся документов IETF (https://trustee.ietf.org/
 лицензия-информация), действующая на дату публикации этого документа.
 Пожалуйста, внимательно ознакомьтесь с этими документами, так как они описывают ваши права.
 и ограничения в отношении этого документа. Компоненты кода
 извлеченные из этого документа должны включать текст упрощенной лицензии BSD
 как описано в Разделе 4.e Правовых положений о трастах, и
 предоставляется без гарантии, как описано в упрощенной лицензии BSD.
 Абстрактный
 В этом документе представлен список тестов для разработчиков Network
 Процессы, совместимые с операционной системой (NOS). В этом документе указывается
 руководящие принципы для серии тестов, которые могут быть проведены для проверки соответствия
 и надежность реализации NOS. Эти тесты охватывают несколько
 важные функции, чтобы получить уровень доверия к NOS
 реализация.
 Оглавление
 1. Введение  ............................................... ................................2
 1.1. Объем документа ................................................................ .............2
 2. Условные обозначения и определения..................................................... 2
 2.1. Условные обозначения, используемые в этом документе................................2
 2.2. Определения................................................... .................3
 3. Спецификации испытаний................................................... ...................... 3
 3.1. Тест агента DHCP-ретрансляции.......................................... ...........3
 3.2. Шкала FIB.................. ................................. ...................4
 3.3. Тест декапсуляции IPv4..................................................... ......5
 3.4. LAG Feature Test ............................................... ...... 7
 3.5. Тестирование функций VLAN................................................... ......8
 4. Вопросы безопасности................................................... .......9Благодарности ................................................................ ....9
 Использованная литература................................................. ....9
 Адрес автора ................................................................ .....10
 Mu Истекает 14 апреля 2022 г. [Страница 1]
 Интернет-проект руководства по тестированию NOS, март 2022 г.
 1. Введение
 В этом меморандуме описывается возможное руководство по тестированию для NOS.
 реализации. Тесты призваны помочь продемонстрировать
 соответствие и надежность реализации NOS, а также
 чтобы проиллюстрировать распространенные ошибки реализации. Они не
 предназначен для исчерпывающего набора тестов и прохождения этих тестов
 не обязательно подразумевает полное соответствие NOS
 Технические характеристики.
 Следует соблюдать осторожность в отношении нескольких тестовых случаев, поскольку они
 может повлиять на другие системы в сети. Мы рекомендуем это
 эти конкретные тесты должны выполняться только в тестовой среде.
 Тесты могут быть выполнены в физической среде испытательного стенда или
 в среде виртуального испытательного стенда. Виртуализированный тестовый стенд NOS, который может
 имитировать работающее устройство NOS и сопутствующую топологию сети
 поддерживается использование KVM и Docker. Эта тестовая установка не требует
 любое физическое коммутационное оборудование или SAI любого поставщика.
 1.1. Объем документа
 В этом документе перечислены тесты, предназначенные для выполнения на
 реализация НОС. Для некоторых тестов несколько экземпляров каждого
 из этих компонентов участвуют. Тестирование этих разных
 Компоненты NOS усложняют тестирование, так как обычно тестируют его
 программного обеспечения по сравнению с существующей реализацией, которая, как доказано,
 совместимый. Тесты для NOS варьируются от агента ретрансляции DHCP до FIB.
 масштабирование, декапсуляция IPv4, функция LAG и функция VLAN. Этот
 документ не предназначен для замены формального тестирования
 программные процедуры, а как передовой подход к
 неформальное тестирование реализации NOS разработчика.
 2. Условные обозначения и определения
 2.1. Условные обозначения, используемые в этом документе
 Ключевые слова «ДОЛЖЕН», «НЕ ДОЛЖЕН», «ТРЕБУЕТСЯ», «ДОЛЖЕН», «ДОЛЖЕН
 НЕТ», «СЛЕДУЕТ», «НЕ СЛЕДУЕТ», «РЕКОМЕНДУЕТСЯ», «НЕ
 РЕКОМЕНДУЕМЫЕ", "МОЖЕТ" и "ДОПОЛНИТЕЛЬНО" в этом документе означают
 интерпретироваться, как описано в BCP 14 [RFC2119] [RFC8174] когда и
 только когда они появляются во всех столицах, как показано здесь.
 2.2. Определения
 NOS -- сетевая операционная система
 DHCP -- протокол динамической конфигурации хоста
 FIB -- База данных форвардной информации
 IPv4 -- Интернет-протокол версии 4
 LAG -- Группа агрегации ссылок
 VLAN -- Группа агрегации каналов
 Mu Истекает 14 апреля 2022 г. [Страница 2]
 Интернет-проект руководства по тестированию NOS, март 2022 г.
 3. Спецификации испытаний
 Тесты, описанные в этом разделе, МОГУТ выполняться с использованием физического
 тестовой среде или в виртуальной тестовой среде.
 конфигурация DHCP, FIB, IPv4, LAG и VLAN ДОЛЖНА
 записывается для каждого теста вместе с результатами теста.
 Успешное выполнение всех тестов, описанных в этом разделе,
 дать тестировщику высокую уверенность в том, что тестируемая реализация
 соответствует архитектуре и протоколу NOS. Однако это
 не предоставлять 100% всестороннее покрытие или официальное подтверждение
 соответствие.
 3.1. Тест агента DHCP-ретрансляции
 В этом разделе перечислены тесты, направленные на подтверждение правильной работы определенных
 особенности реализации isc-dhcp-relay. Мы должны обеспечить
 основная цель агента ретрансляции DHCP выполнена. Это включает в себя подтверждение того, что
 Пакеты обнаружения, предложения, запроса и подтверждения DHCP успешно ретранслируются
 от клиента к серверу(ам). Мы также должны убедиться, что такие функции, как
 правильное вложение поля Option 82 поддерживается этим агентом.
 Тест имитирует получение DHCP-клиентом аренды. Мы моделируем DHCP
 клиент (сервер по ТЗ) загружается путем ручного создания DHCP
 пакеты и отправка их на интерфейс, который является частью ТЗ
 ВЛАН.
 1. Создайте пакет DHCPDISCOVER и отправьте его в ТЗ по
 интерфейс, который является частью VLAN ToR. Ретранслятор DHCP должен получить
 этот пакет, добавьте заголовок Option 82 и перешлите пакет всем
 известные DHCP-серверы через восходящие каналы.
 2. Прослушайте все пакеты на восходящих каналах ToR и подсчитайте количество
 пересылать пакеты DHCPDISCOVER, чтобы гарантировать, что они будут отправлены каждому
 известный DHCP-сервер.
 3. Создайте пакет DHCPOFFER и отправьте его в ТЗ через один из его
 аплинки. Ретранслятор DHCP должен переслать этот пакет «клиенту» на
 его VLAN.
 4. Прослушайте DHCPOFFER на «клиентском» интерфейсе, чтобы убедиться, что
 будет получено.
 5. Создайте пакет DHCPREQUEST и отправьте его в ТЗ на интерфейсе.
 это часть VLAN ToR. Ретранслятор DHCP должен получить это
 пакет, добавьте заголовок Option 82 и перешлите пакет всем известным
 DHCP-серверы через восходящие каналы.
 6. Прослушайте все пакеты на восходящих каналах ToR и подсчитайте количество
 пересылал пакеты DHCPREQUEST, чтобы убедиться, что они отправлены каждому известному
 DHCP-сервер.
 Mu Истекает 14 апреля 2022 г. [Страница 3]
 Интернет-проект руководства по тестированию NOS, март 2022 г.
 7. Создайте пакет DHCPACK и отправьте его в ТЗ через один из его
 аплинки. Ретранслятор DHCP должен переслать этот пакет «клиенту» на
 его VLAN.
 8. Прослушайте DHCPACK на «клиентском» интерфейсе, чтобы убедиться, что он
 быть полученным.
 DHCP-серверы должны быть определены в файле minigraph устройства как
 подобъект каждого интерфейса VLAN. Количество серверов DHCP, которые вы
 define зависит от вас и ваших требований к тестированию.
 3.2. Тест шкалы FIB
 Целью этого теста является проверка добавления маршрутов IPV4 и IPV6 в
 количество, требуемое NOS, и убедитесь, что каждый маршрут работает
 правильно, пересылая пакеты по каждому маршруту. Тест
 предполагается, что все маршруты предварительно заданы BGP, поэтому настройка не требуется.
 должно быть выполнено самим тестом. Тест получает конфигурацию маршрута
 через текстовый файл, который будет проанализирован тестом. Проверка маршрутов
 осуществляется путем отправки трафика по каждому из созданных маршрутов.
 Настройка будет настроена на маршруты 6K IPV4/26 и 6K IPV6/64.
 Для каждого маршрута будет выдан простой класс трафика с использованием команды ping.
 функциональность.
 Для проверки ECMP мы будем использовать пакет TCP, затем для каждого маршрута ECMP
 мы отправляем n пакетов, затем проверяем их получение на любом из портов в
 только группа ECMP.
 Поскольку маршруты ECMP должны быть установлены, мы должны запустить несколько пакетов ping для каждого
 route. Кроме того, каждый маршрут может быть проверен независимо, таким образом, проверьте
 может потребоваться больше нескольких минут, чтобы преодолеть весь маршрут 12 000 000 000 000 000 000
 последовательные пинг-запросы.
 На каждом маршруте будет 1 или 2 группы следующих переходов.
 Тест нацелен на работающую систему NOS с полностью функционирующим
 конфигурация. Целью теста является не проверка конкретного SAI API,
 но функциональное тестирование маршрутов, убедившись, что маршруты предварительно настроены
 при запуске NOS работает правильно.
 В тестах настройки предполагается, что к коммутатору подключена одна NOS.
 подключен к серверу с 32 виртуальными машинами Arista.
 К коммутатору будет подключено 32 одноранговых узла BGP. У каждого сверстника будет
 На коммутаторе открыты 2 сеанса BGP: одиночное соединение IPV4 и одиночное
 ИПВ6 соединение. Одноранговые узлы будут объявлять маршруты, необходимые коммутатору.
 узнать.
 Mu Истекает 14 апреля 2022 г. [Страница 4]
 Интернет-проект руководства по тестированию NOS, март 2022 г.
 К коммутатору будет подключено 32 одноранговых узла BGP. У каждого сверстника будет
 На коммутаторе открыты 2 сеанса BGP: одиночное соединение IPV4 и одиночное
 ИПВ6 соединение. Одноранговые узлы будут объявлять маршруты, необходимые коммутатору.
 узнать.
 Хост PTF должен быть подключен к порту, через который он будет отправлять
 пакеты к коммутатору, и должен иметь подключение через порты через
 который коммутатор отправит полученный пакет обратно на хост для
 Проверка.
 Пиры и NOS будут развернуты скриптом Ansible. Как часть
 развертывание скрипт будет генерировать маршруты. Для подготовки к тесту
 тот же скрипт создаст текстовый файл route_info.txt, который
 содержать строки следующего формата: dst_prefix,port:port...
 Эта информация будет использоваться для: 1. Создания пакета с правильным
 префикс назначения; 2. При валидации ожидать пакет из списка
 порты.
 Цель теста — проверить, что каждый маршрут был добавлен в
 переключается и работает нормально.
 Описание теста:
 1. Считайте информацию из route_info.txt для каждого маршрута.
 2. Для каждого маршрута в пакете route_info.textConstruct с правильным
 адрес назначения.
 o Отправить 10 запросов ping на коммутатор.
 o Убедитесь, что на порт, указанный в
 route_info.txt для заданного адреса назначения.
 o Если пришли не все пакеты, извлечение отладочной информации из коммутатора будет
 печатается в журнале испытаний. Отсутствие сообщения.
 3. Сводка тестового примера, которая будет напечатана в журнале тестирования: количество маршрутов, которые необходимо
 отправлено, количество проверенных и признанных маршрутов в порядке.
 3.3. Тест декапсуляции IPv4
 Этот тестовый пример предназначен для проверки способности выполнять декапсуляцию
 IP-инкапсулированные пакеты и убедитесь, что каждый декапсулированный пакет
 имеет правильные свойства в каждом поле и вперед с
 соответствующий IP-адрес назначения подложки на правильный маршрут. Тест
 предполагает, что все маршруты и декапсуляция установлены до проверки, поэтому нет
 конфигурация должна быть выполнена самим тестом, и тест будет
 соответствуют только правильным IP-адресам, настроенным в тесте.
 Mu Истекает 14 апреля 2022 г. [Страница 5]
 Интернет-проект руководства по тестированию NOS, март 2022 г.
 Проверка маршрутов и декапсуляция выполняются путем отправки
 пакеты с соответствующими IP-адресами как в оверлее, так и в подложке.
 В объем этого плана тестирования входит только тест Ansible, включая тест PTF.
 и необходимую конфигурацию.
 Тесты установки предполагают наличие одной NOS, подключенной к
 коммутатор, подключенный к серверу с 32 виртуальными машинами Arista.
 К коммутатору будет подключено 32 одноранговых узла BGP. Сверстники будут
 объявите маршрут по умолчанию и обновите коммутатор.
 Хост PTF должен быть подключен к порту, через который он будет отправлять
 пакеты к коммутатору и должен иметь соединение через порты через
 который коммутатор отправит полученный пакет обратно на хост для
 Проверка.
 Пиры и NOS будут развернуты скриптом Ansible. В рамках
 развертывание, скрипт сгенерирует маршруты и декапсуляцию
 команды. Правило декапсуляции будет сгенерировано скриптом J2, который
 выведет файл JSON с IP-адресом Decap, который будет настроен через
 Инструмент настройки SWSS.
 Целью теста является проверка способности декапсуляции, и каждый маршрут имеет
 был добавлен к коммутатору и правильно работает с
 декапсулированный пакет.
 Тестовые конфигурации:
 o IP decap IPv4, который будет взят из loopback IP: _Decap IP
 o Маршруты IPv4 по умолчанию, которые будут настроены через сеанс BGP как
 ECMP-маршруты.
 o Маршруты IPv4 в индивидуальном регистре, которые будут настраиваться через сеанс BGP как
 маршруты ТОР.
 Описание теста:
 1. Тест будет использовать IP-адрес хоста, попадающий в маршрут по умолчанию, и для
 маршруты ТОР.
 2. Тест будет использовать разные комбинации внешних и внутренних значений TTL для
 различные режимы ТТЛ.
 3. Из докера ПТФ скрафтить и отправить через все порты дубль
 инкапсулированные IP-пакеты.
 Mu Истекает 14 апреля 2022 г. [Страница 6]
 Интернет-проект руководства по тестированию NOS, март 2022 г.
 4. Убедитесь, что Sonic не видит инкапсулированный пакет. IP-в-IP
 пакет не должен идти к ЦП, пакет не должен быть виден на
 Н. У.К.
 5. Убедитесь, что пакет, который возвращается в PTF Docker, декапсулирован.
 из одного из ожидаемых портов.
 6. повторите шаги 1-4 32 раза, чтобы каждый порт отправил 2 пакета по одному для
 одноадресный маршрут и один маршрут ecmp.
 3.4. Тест функции LAG
 Этот набор тестов функций LAG предназначен для тестирования базовой функции LAG.
 функции на NOS. Этот набор тестов включает в себя несколько основных тестов - FIB
 тест, тест минимальной связи и тест LACP. Каждый тест охватывает базовую функциональность
 функции LAG и гарантирует, что коммутатор работает должным образом при
 производственные сценарии.
 Тест нацелен на работающую систему NOS с полностью функционирующим
 конфигурация. Целью теста является не проверка конкретного SAI API,
 но функциональное тестирование LAG на NOS, чтобы убедиться, что трафик
 правильно, в соответствии с маршрутами BGP, объявленными узлами BGP NOS
 коммутатор и конфигурация LAG. Тест будет работать только в
 испытательный стенд, специально созданный для LAG.
 Тестовая конфигурация:
 1. 8 LAG на коммутатор от DUT до 8 устройств EOS.
 2. Каждая из задержек содержит 2 элемента, а минимальное количество ссылок установлено на 2.
 3. Сеансы BGP:
 o 16 портов на передней панели с выходом на север к устройствам на позвоночнике
 o 16 портов на передней панели объединяют по два, чтобы иметь 8 групп LAG, связанных с югом.
 по направлению к шипам.
 4. Все TOR объявляют 6 маршрутов, а все маршрутизаторы позвоночника объявляют 6402 маршрута.
 Это похоже на тестовую среду, настроенную для конечных устройств без задержек.
 Тестовый пример — проверка TCP-трафика
 Убедитесь, что трафик между ногами распределен равномерно. Трафик направляется через
 Н.У.Т.
 o Хост PTF будет отправлять пакеты в соответствии с route_info.txt - создаст
 пакеты с dst_ip в соответствии с префиксами маршрутов.
 o Когда пакет достигает SONIC DUT, он направляет пакет в соответствии с
 BGP-маршруты и отправьте их одному из партнеров vEOS BGP.
 Mu Истекает 14 апреля 2022 г. [Страница 7]
 Интернет-проект руководства по тестированию NOS, март 2022 г.
 o Тест PTF получит копию пакета и выполнит проверки.
 описано в разделе Проверка трафика
 Мы не нацелены на тестирование трафика, поступающего в DUT от BGP.
 сверстники.
 Тестовый пример — проверка LACP
 Цель этого теста — убедиться, что скорость LACP установлена ​​правильно.
 согласованы и установлены на обоих концах LAG.
 Ниже приведены предварительные условия для тестового примера:
 o Переключатель DUT всегда запускается с установленной скоростью LACP на «медленную».
 o Виртуальные машины всегда устанавливаются с высокой скоростью при запуске.
 o После запуска все виртуальные машины будут согласовывать скорость LACP с тестируемым устройством и устанавливать свои
 собственная скорость «медленно».
 Проверка будет реализована в виде инструкций Ansible в lag.yml,
 без вызова ПТФ:
 1. Ansible playbook подключается к каждой виртуальной машине.
 2. Ansible playbook проверяет, что для каждой виртуальной машины скорость LACP установлена ​​на «медленную».
 3. Ansible подключается к тестируемому устройству и проверяет, что скорость LACP установлена ​​на «медленную».
 3.5. Тест функций VLAN
 Целью функционального теста VLAN является тестирование функций VLAN на
 Переключатель NOS. Этот набор тестов включает в себя несколько основных тестов - тест FIB, VLAN
 тест трафика, тест перекрытия канала и тест обучения ARP. Каждый тест охватывает базовый
 функциональность функции VLAN и гарантирует, что коммутатор работает должным образом
 по производственным сценариям.
 Испытания будут включать:
 1. Функции портов VLAN.
 2. Маршрутизация интерфейсов VLAN.
 3. Трафик IP2me на интерфейсах VLAN.
 Mu Истекает 14 апреля 2022 г. [Страница 8]
 Интернет-проект руководства по тестированию NOS, март 2022 г.
 Тест будет пытаться охватить все функции портов VLAN, включая
 Порты Ethernet и LAG. И убедитесь, что IP-трафик и IP2me
 трафик работает хорошо.
 Порт VLAN будет включать три атрибута:
 o PVID: входящие нетегированные пакеты будут помечены PVID и PVID.
 всегда будет в разрешении идентификаторов VLAN.
 o Разрешить идентификаторы VLAN: какой идентификатор VLAN для входящих и исходящих пакетов
 разрешено в порту.
 o помеченные идентификаторы VLAN: определите, какие исходящие пакеты идентификаторов VLAN будут
 помечен.
 Для функции магистрали VLAN количество помеченных идентификаторов VLAN ограничено значением Разрешить.
 Идентификаторы VLAN помимо PVID, например, если PVID равен 100, разрешенные идентификаторы VLAN равны 100,
 200, 300, тегированные идентификаторы VLAN равны 200 300, другими словами, нетегированные VLAN.
 ИД 100.
 Описание теста:
 o Тесты предполагают, что коммутатор разветвления поддерживает QinQ (стековая VLAN), так что
 стекированные пакеты VLAN могут проходить через коммутатор разветвления и могут быть
 проверено на тестируемом устройстве с внутренней VLAN.
 o Тесты будут основаны на типе испытательного стенда *t0*. IP-адрес каждой LAG
 на DUT будет сброшен, чтобы все LAG работали как порты L2. Новый тест
 IP-адреса будут настроены на интерфейсах VLAN.
 o виртуальные машины используются только для согласования LACP для LAG; ПТФ используется для
 отправить пакет и проверить функциональность VLAN.
 4. Вопросы безопасности
 Этот меморандум не вызывает вопросов безопасности.
 Благодарности
 Авторы благодарят xxxx.
 использованная литература
 [RFC2119] Брэднер, С., «Ключевые слова для использования в RFC для указания
 Уровни требований», BCP 14, RFC 2119, DOI 10.17487/RFC2119,
 март 1997 г., .
 [RFC8174] Лейба, Б., «Неоднозначность прописных и строчных букв в RFC».
 2119 ключевых слов», BCP 14, RFC 8174, DOI 10.17487/RFC8174,
 Май 2017 г., .
Mu Истекает 14 апреля 2022 г. [Страница 9]
 Интернет-проект руководства по тестированию NOS, март 2022 г.
 Адреса авторов
 Юбо Му
 Китайская академия информационных и коммуникационных технологий
 № 52, Хуа Юань Бэй Роуд
 Район Хайдянь, Пекин
 Китай
 Телефон: 010-62300556
 Электронная почта: muyubo@caict.