Нагрузочное тестирование EVPN-MPLS на маршрутизаторах MR-381 от B4COM. Методика, результаты и выводы

В конце 2023 года отечественный вендор B4com Tech анонсировал выпуск маршрутизаторов для провайдерского сегмента IP/MPLS. Среди новых моделей наше внимание привлекли те, которые поддерживают интерфейсы 100G, поскольку они стали стандартом подключения в современных центрах обработки данных (ЦОД).

В модельный ряд входят устройства MR-381 и MR-382, различающиеся интерфейсами, но построенные на одном чипе — Broadcom Qumran2C. Этот чип активно используется в таких маршрутизаторах, как Cisco NCS 5500/5700, Juniper ACX7000 и Edge-Core AGR400.

Программное обеспечение

На текущий момент используется B4comOS. Это операционная система, построенная изначально на OcNOS от IP Infusion, но с 2022 года полностью отделившаяся и развивающаяся самостоятельно.

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

За время, пока я работаю с оборудованием этого вендора, не раз возникала потребность в подобной картинке. Например, периодически приходится обращаться к модулю HSL, который занимается программированием ASIC’а и, соответственно, может показывать информацию о FIB. Ещё интерес представляет модуль NSM, который отвечает за control-plane. Бывает так, что нужно и в него заглянуть. Поэтому хочется всё-таки не просто вводить какие-то команды и смотреть результаты вывода, а ещё и понимать, что происходит.

Первое наше знакомство с MR

С чипом мы уже знакомы и знаем его возможности. Но вопрос в том, как вендор смог адаптировать ASIC и насколько софт, скажем так, «сырой». В общем, в конце 2023 года мы взяли 2 коробки на тесты. Провели достаточно ограниченное тестирование на предмет использования этих маршрутизаторов в сети одного из наших заказчиков. Смотрели на базовый функционал: IS-IS, LDP, L3VPN (средствами MP-BGP VPNv4). Нагружали до 90 Gbps. Нашли мелкие нюансы, о которых знали заранее по работе с коммутаторами, и быстро их сами поправили. В целом, всё было нормально и без каких-либо подводных камней.

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

Речь идёт про EVPN-MPLS с Active-Active IRB и Anycast Gateway. Для тех, кто не знаком с этой темой, вот две полезные статьи: Статья 1 и Статья 2.

Тесты EVPN-MPLS

Топология

Наша тестовая среда включает два сегмента: EVPN-VXLAN и EVPN-MPLS.

Включения между сегментами выполнены для «проброса» двух сервисов: L3 и L2.

Для L3 используется стандартный Option-A, который с обоих сторон передаётся как type-5 EVPN, но на «стыке» разрывается и передаётся как чистый IPv4.

L2 включает более сложные сценарии. Оба сегмента используют EVPN-MH (EVPN Multi-Homing), можно назвать back-to-back evpn-mh (аналогично back-to-back vpc). Объединение выполнено в один общий LAG на 4 физических интерфейсах с разными ESI на парах.

В стенде у нас 2500 таких растянутых L2-сетей, соответственно, такое же количество IRB-интерфейсов на обоих PE, всё это в режиме Active-Active с Anycast Gateway.

На BL настройка чуть проще, так как не требуется использовать IRB и L2-subinterface, растягиваем чистый L2 по EVPN-VXLAN домену.

Методика тестирования

Для генерации трафика использовался TRex.

В тесте запускались 2500 потоков, каждый с уникальным source IP и dot1q тегом, но общим destination IP. Это обеспечивает достаточную энтропию для балансировки и тестирует все 2500 IRB-интерфейсов, через которые маршрутизируется трафик.

from trex_stl_lib.api import * import argparse import os  class STLS1(object):     def __init__(self):         self.mac_counter = 0  # Initialize a counter for generating MAC addresses      def generate_mac(self):         base_mac = [0x10, 0x70, 0x00, 0x00, 0x00, 0x00]         mac_suffix = self.mac_counter * 4096  # Increment by 4096 for each new MAC         for i in range(5, 1, -1):             base_mac[i] = mac_suffix & 0xFF             mac_suffix >>= 8         self.mac_counter += 1         return ':'.join('{:02x}'.format(b) for b in base_mac)      def create_stream(self, vlan_id, src_ip, src_mac, pkt_size=1400):         # Calculate the payload size needed to reach the desired packet size         header_size = len(Ether() / Dot1Q() / IP() / UDP())         payload_size = pkt_size - header_size         payload = 'x' * payload_size          return STLStream(             packet=STLPktBuilder(pkt=Ether(src=src_mac, dst="00:11:22:33:44:55") /                                   Dot1Q(prio=1, vlan=vlan_id) /                                   IP(src=src_ip, dst="10.200.0.5") /                                   UDP(dport=12, sport=1025) / payload),             mode=STLTXCont(pps=10),             # mac_dst_override_mode=STLStreamDstMAC_PKT # another way to explicitly take it         )      def get_streams(self, direction, tunables, **kwargs):         parser = argparse.ArgumentParser(description='Argparser for {}'.format(os.path.basename(__file__)),                                          formatter_class=argparse.ArgumentDefaultsHelpFormatter)          args = parser.parse_args(tunables)         streams = []         # Loop to generate streams for varying VLAN IDs and source IP addresses         vlan_id = 1000         for i in range(0, 10):  # second octet range             for j in range(0, 256):  # third octet range                 src_ip = f"30.{i}.{j}.10"                 src_mac = self.generate_mac()                 streams.append(self.create_stream(vlan_id, src_ip, src_mac))                 vlan_id += 1  # Increment VLAN ID for each stream                 if vlan_id > 1010:                     break             if vlan_id > 1010:                 break         return streams  # dynamic load - used for trex console or simulator def register():     return STLS1()

Сервис L2 растянут до хоста, а на PE (Provider Edge) этот сервис терминируется через IRB-интерфейсы. Конфигурации этих интерфейсов были описаны ранее.

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

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

Мы отслеживаем состояние как control plane, так и data plane. С контрольной плоскостью все понятно: достаточно включить логи и наблюдать за активностью используемых протоколов. Они должны быть стабильными и не должны флапать или перестраиваться. В отношении data plane сначала анализируем счетчики на дашборде TRex, и если необходимо, смотрим аналогичную информацию на самих узлах.

Результат тестов

При базовой нагрузке (1 Gbps) проблем не возникает.

DF/Non-DF выбираются корректно. Принцип выбора соответствует RFC7432 и подробно разобран в статьях, которые я приложил выше.

PE1-MR381#sh evpn mpls  EVPN-MPLS Information  =================     Codes: NW - Network Port            AC - Access Port           (u) - Untagged   VPN-ID   EVI-Name     EVI-Type Type Interface ESI                           VLAN      DF-Status Src-Addr         Dst-Addr         _______________________________________________________________________________________________________________________________ 1000     ----         L2       NW   ----      ----                          ----      ----      20.0.0.1         20.0.0.3         1000     ----         --       AC   po1.1000  00:00:00:11:11:aa:aa:00:00:00 ----      DF        ----             ----             1001     ----         L2       NW   ----      ----                          ----      ----      20.0.0.1         20.0.0.3         1001     ----         --       AC   po1.1001  00:00:00:11:11:aa:aa:00:00:00 ----      NON-DF    ----             ----             1002     ----         L2       NW   ----      ----                          ----      ----      20.0.0.1         20.0.0.3         1002     ----         --       AC   po1.1002  00:00:00:11:11:aa:aa:00:00:00 ----      DF        ----             ----              .....  3497     ----         L2       NW   ----      ----                          ----      ----      20.0.0.1         20.0.0.3         3497     ----         --       AC   po1.3497  00:00:00:11:11:aa:aa:00:00:00 ----      NON-DF    ----             ----             3498     ----         L2       NW   ----      ----                          ----      ----      20.0.0.1         20.0.0.3         3498     ----         --       AC   po1.3498  00:00:00:11:11:aa:aa:00:00:00 ----      DF        ----             ----             3499     ----         L2       NW   ----      ----                          ----      ----      20.0.0.1         20.0.0.3         3499     ----         --       AC   po1.3499  00:00:00:11:11:aa:aa:00:00:00 ----      NON-DF    ----             ----     

Аналогичная история с Aliasing и ESI label.

PE1-MR381#sh evpn mpls label alias  S - Self R - Remote ESI                            PE-IP-ADDRESS        TENANT               ALIAS-LABEL          ============================================================================================= 00:00:00:11:11:aa:aa:00:00:00  20.0.0.1(S)          1000                   30 00:00:00:11:11:aa:aa:00:00:00  20.0.0.1(S)          1001                   29 00:00:00:11:11:aa:aa:00:00:00  20.0.0.1(S)          1002                   28  ....  00:00:00:11:11:aa:aa:00:00:00  20.0.0.3(R)          3497                31959 00:00:00:11:11:aa:aa:00:00:00  20.0.0.3(R)          3498                31958 00:00:00:11:11:aa:aa:00:00:00  20.0.0.3(R)          3499                31961

PE1-MR381#sh evpn mpls label esi  S - Self R - Remote ESI                            PE-IP-ADDRESS        ESI-LABEL            ================================================================ 00:00:00:11:11:aa:aa:00:00:00  20.0.0.1(S)            18 00:00:00:11:11:aa:aa:00:00:00  20.0.0.3(R)            18

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

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

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

Также счетчики на очередях показывают корректные значения.

Выводы

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

Подписывайтесь на мой канал: https://t.me/like_a_bus_channel. Пишу о тестах, своем опыте и прочем, с чем сталкиваюсь на работе и не только!