Как мы тестируем совместимость вендоров: один RFC, два прочтения

Два роутера от двух вендоров, и в обоих даташитах один и тот же список RFC. Оба не врут. RFC оставляет варианты, каждый вендор выбирает свои умолчания, и два устройства, совместимых со стандартом, поднимают BGP, показывают Established на обеих консолях и при этом обмениваются половиной маршрутов. Мы тестируем пару: ваше устройство против тех реализаций, с которыми оно встретится, с вашей конфигурацией на обоих концах и трафиком через стык.

Стенд

Ваше устройство ставится на стенд CloudLAB или запускается как виртуальный appliance на наших хостах. Рядом, на тех же портах от 1G до 100G, стоит второй вендор: реальная коробка из лаборатории, коробка, которую пришлете вы, или ее виртуальная версия. Генераторы стенда добавляют эмулированных пиров нескольких реализаций, так что одна роль устройства встречает до 4 соседей в одном проекте по совместимости.

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

Что проверяем

• Согласование capability: семейства адресов, 4-байтовый AS, add-path, graceful restart; что предложила каждая сторона, о чем договорились, сколько маршрутов отправлено и принято по каждому семейству
• Политика через стык: community, local preference и MED, которые выставляет один вендор и читает другой; каждый атрибут проверяется на входе
• Разные умолчания: таймеры hello, hold и BFD, MTU на линке и внутри overlay; один прогон со значениями из ваших шаблонов, второй с заводскими значениями каждого вендора
• EVPN между вендорами: типы маршрутов 2, 3 и 5, модель type 5 у каждой стороны, обработка ESI и привязка VNI к VRF
• MPLS и segment routing: обмен метками, диапазоны меток и конфликты SID, глубина стека, fast reroute от одной реализации к другой
• OAM: MEP двух вендоров на одной MEG по Y.1731, интервал CCM и уровень, RDI и AIS через границу в обе стороны, задержка и потери в сверке с генератором
• Отказ: выдернутый линк между вендорами, перезагрузка узла, graceful restart в режиме helper; разрыв форвардинга по каждому потоку и направлению в миллисекундах
• Негативные случаи: неизвестная capability, неожиданный атрибут, несовпадение MTU или аутентификации; сбрасывает ли соседняя сторона сессию, игнорирует опцию или молча теряет маршруты

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

Что обычно ломается

Маршруты, которые не доходят. Типичная миграция ядра: новая модель роутера заменяет половину ядра. BGP поднимается, 1M маршрутов загружается, а community, которое выставляет старая сторона, новая молча отбрасывает. Политика дальше по сети завязана на него и отправляет трафик не туда. Стенд ловит это на проходе по политикам, одна строка конфигурации исправляет проблему до переключения.

Одно число, два смысла. Один вендор пишет MTU 1500 и имеет в виду IP-пакет, другой пишет 1514 и имеет в виду кадр Ethernet. OSPF застревает в ExStart, или соседство поднимается, а первый полноразмерный пакет через overlay VXLAN теряется. С таймерами та же история: CCM с интервалом 3,3 мс на одном конце против 10 мс на другом дает аларм unexpected period на здоровом линке.

Отказ, который не принадлежит ни одной стороне. Линк между вендорами выдергивается. Одна сторона держит BFD на 50 мс, другая не принимает меньше 300 мс, и сессия садится на более медленное значение: в типичном проекте около 900 мс на обнаружение против 150 мс по дизайну. Разрыв в миллисекундах зависит от пары, поэтому мы меряем его по каждой паре.

Что в отчете

На первой странице матрица совместимости: пары по вертикали, реализации по горизонтали, в каждой ячейке «пройдено», «провал» или «пройдено с замечанием». За каждой ячейкой запись: обе конфигурации в том виде, в каком они работали, захват с каждого конца по провалу, принятые маршруты, поднятые сессии и разрыв при сходимости по каждому прогону. Список исправлений говорит, что поменять, на какой стороне и в каком релизе вендор сообщает об исправлении. Когда два вендора кивают друг на друга, захваты показывают, кто что отправил; по запросу мы разбираем их с обоими на одном звонке.

С чего начать

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