Фабрики для ЦОД в текущих реалиях

Привет, Хабр! Начнем традиционно – с обзора непростой текущей ситуации. В связи с уходом западных вендоров, которые предлагали решения по построению сетей ЦОД, возник вопрос с дальнейшей поддержкой и развитием сетевой инфраструктуры. Отсутствие техподдержки вендора создает риски для компаний, которые успели развернуть у себя в ЦОД такие проприетарные решения, как Cisco ACI, т.к. остается вероятность появления кейсов, которые не решить без участия разработчиков вендора. При этом, если продолжать докупать оборудование западных вендоров для расширения текущей сетевой инфраструктуры, построенной на базе того же Cisco ACI, то никуда не исчезают риски, связанные и с заменой таких компонент как контроллеры Cisco APIC при выходе их из строя. Да и вопрос безопасности волнует многих. Так пришло время посмотреть в сторону альтернативных поставщиков сетевых решений для ЦОД.

Фабрики

Но давайте сначала вспомним, чем же заслужили к себе повышенное внимание сетевые фабрики и почему в последние годы они являются по сути стандартом для построения сетей ЦОД. Ведь с приходом в нашу жизнь таких понятий, как VXLAN, MP-BGP EVPN, топология Клоса и других подход к построению сетей ЦОД кардинально изменился. Эти технологии позволили нам строить маршрутизируемые фабрики с неблокируемой архитектурой высокой доступности, обеспечивая связность и изоляцию трафика на 2 и 3 уровнях для сервисов и приложений вне зависимости от их местоположения.

При этом появление MP-BGP EVPN изменило парадигму оверлейной сети VXLAN и представляет собой важный шаг в эволюции VXLAN как сетевой технологии ЦОД. Устранение поведения «flood-and-learn» делает эту технологию более интересной для расширения взаимодействий на 2 и 3 уровнях за пределы одного ЦОД. Так VXLAN с control plane MP-BGP EVPN может рассматриваться в качестве достойной альтернативы таким проверенным решениям для организации Layer 2 DCI как OTV и VPLS. Когда VXLAN внедряется внутри ЦОД, то его использование для взаимодействия между ЦОД может упростить общий дизайн сети и снизить эксплуатационную сложность, предоставляя унифицированное сетевое оверлейное решение.

Для расширения Layer 2 домена и Layer 3 сегментации между географически разнесенными фабриками VXLAN-EVPN существуют 3 основные архитектуры: Multi-Pod, Multi-Fabric и Multi-Site.

Архитектура Multi-Pod

Архитектура Multi-Pod, реализованная с использованием технологий MP-BGP EVPN VXLAN, призвана обеспечить взаимное подключение географически разнесенных обычно на незначительные расстояния ЦОД в единую VXLAN фабрику под единым административным управлением. Обычно речь идет о расширении текущей фабрики и размещении дополнительных коммутаторов Spine/leaf в соседнем машзале или другом ЦОД в качестве дополнительного Pod-а. В связи с этим встает вопрос о целесообразном подходе к организации физических подключений между такими Pod-ми.

Существуют 2 основных подхода к организации физических подключений между Pod. Первый подход предполагает организацию подключений на уровне Spine как Back-to-Back или через дополнительный уровень Super-Spine, что является более масштабируемым вариантом, т.к. позволяет избежать в т.ч. Full-Mesh подключений между Pod-ми.

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

Логически типичная архитектура Multi-Pod предполагает в каждом Pod свою собственную автономную систему, работающую под управлением MP-iBGP EVPN с Route Reflector-ми на коммутаторах уровня Spine для простоты и масштабируемости, а также Multihop MP-eBGP EVPN между Pod. Underlay внутри каждого Pod обычно строится с использованием таких IGP протоколов как IS-IS и OSPF. Для underlay между Pod могут использоваться как IGP протоколы, так и eBGP для лучшей изоляции. Для передачи BUM трафика используется Multicast или Ingress репликация.

При этом Pod-ы объединяются в единый домен маршрутизации MP-BGP EVPN с единым data plane на основе VXLAN, т.е. Multi-Pod представляет собой логически единую растянутую VXLAN-EVPN фабрику, где VXLAN туннели всегда терминируются на уровне Leaf любого Pod.

В итоге архитектура Multi-Pod обеспечивает высокоэффективную передачу данных, простоту в администрировании и добавлении новых Pod, но имеет и ряд существенных недостатков, таких как единый домен сбоя и Layer 2 флудинга, единый механизм репликации BUM трафика, потребность в одинаковой конфигурации Layer 2 и 3 сервисов и т.д.

Архитектура Multi-Fabric

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

На данный момент существует 2 основных подхода к организации DCI в архитектуре Multi-Fabric с использованием VXLAN-EVPN.

Первый называет VLAN Hand-off и обеспечивает L2 связность между фабриками. Реализуется через построение VXLAN-EVPN туннелей между Border Leaf устройствами каждой фабрики, которые в свою очередь подключаются к локальным коммутаторам Leaf для обмена Layer 2 трафиком в интересующих VLAN. За счет этого реализуется разграничение между фабриками, т.к. разрывается домен маршрутизации MP-BGP EVPN с единым data plane на основе VXLAN. Дополнительно возможна организация L3 связности между фабриками через VRF-Lite Hand-Off.

Второй подход называет Segment VXLAN и обеспечивает L2/L3 связность между ЦОД через VXLAN туннели непосредственно между Border Leaf каждой фабрик.

Архитектура Multi-Site

Архитектура Multi-Site также обеспечивает построение независимых VXLAN-EVPN фабрик и описана в драфте RFC «draft-sharma-bess-multi-site-evpn», предполагая дополнительную роль Border Gateway для организации межсайтового взаимодействия. Но, к сожалению, вендоры о которых пойдет дальше речь, на текущий момент не поддерживают данную архитектуру, поэтому отложим рассмотрение данной технологии до лучших времен.

Альтернативные вендоры для сетей ЦОД

На текущий момент доступны следующие вендоры для построения сетей ЦОД, на которых стоит обратить внимание. Это конечно же Huawei и H3C, которые имеют наиболее полный функционал по построению фабрик и разнообразие линеек оборудования, но на данный момент это будет параллельный импорт и без официальной технической поддержки вендора. Далее идут такие китайские вендоры как Maipu и DCN, которые официально поставляются в Россию и оказывают техническую поддержку. Также имеются отечественные производители, такие как Eltex и Q-Tech, в продуктовых линейках которых присутствуют решения для сетей ЦОД. Сосредоточим ваше внимание в этой статье на «новых» китайских и хорошо знакомых отечественных производителях.

Maipu  

Китайская компания Maipu Communication Technology Co., Ltd. занимается исследованиями и разработками в области оборудования для передачи данных уже 30 лет. Линейки сетевых продуктов вендора включают решения корпоративного уровня по маршрутизации, коммутации, построению распределенных сетей WAN с поддержкой 4G/5G, беспроводные решения Wi-Fi, решения для высокопроизводительной границы операторов связи и доступа в Интернет, программно-управляемые решения.

Вендор Maipu единственный из четверки имеет шассийные коммутаторы ЦОД и это серия NSS18500 с моделями на 4 и 8 слотов. Имеются карты с поддержкой 1G/10G/40G/100G портов в различной конфигурации. Некоторые из них представлены на рисунке 1.

Вендор также имеет серии коммутаторов ЦОД с фиксированными портами актуальных скоростей 10G/25G/100G и поддержкой технологий для построения фабрик. 

Коммутаторы поддерживают протоколы OpenFlow и NETCONF, а также сбор телеметрии с использованием фреймворка gRPC. Контроллер SDN для сетей ЦОД находится в стадии разработки и появится на рынке в ближайшее время. Оборудование вендора поддерживает реализацию архитектур Multi-Pod и Multi-Fabric.

DCN   

DCN (Yunke China Information Technology Limited) – китайский вендор, отделившийся от Lenovo в 1997 году. Решения компании сфокусированы на области передачи данных. Продуктовый портфель состоит из решений корпоративного уровня по маршрутизации, коммутации, построению распределенных сетей WAN, беспроводных решений Wi-Fi, сетевой безопасности, решений для промышленности. DCN является ведущим поставщиком решений IPv6 и первой китайской компанией, которая получила золотой сертификат IPv6 Ready и сертификат OpenFlow v1.3.

На текущий момент у вендора в продуктовой линейке только 2 модели коммутаторов ЦОД с фиксированными портами актуальных скоростей 10G/25G/100G и поддержкой технологий для построения фабрик. Оборудование вендора поддерживает реализацию архитектур Multi-Pod и Multi-Fabric.

Q-Tech

Q-Tech — российский разработчик телекоммуникационных решений. В линейку корпоративных сетевых решений вендора входят Ethernet-коммутаторы, VOIP-оборудование, решения для организации безопасного сетевого доступа, беспроводное и пассивное оборудование. В числе клиентов компании крупнейшие телекоммуникационные компании России.

У вендора в продуктовой линейке 3 модели коммутаторов ЦОД с фиксированными портами актуальных скоростей 10G/25G/100G и поддержкой технологий для построения фабрик. Оборудование вендора поддерживает реализацию пока только архитектуры Multi-Pod.

Eltex

Eltex — российский разработчик и производитель телекоммуникационного оборудования из Новосибирска. В ассортимент входит широкая линейка решений для комплексных проектов, в том числе Ethernet-коммутаторы доступа и агрегации, сервисные маршрутизаторы, Wi-Fi- и VoIP-оборудование и др. CTI в статусе официального авторизованного партнера осуществляет продажу, монтаж и сервисное обслуживание оборудования компании.

На текущий момент у Eltex в разработке находятся сразу 4 модели коммутаторов ЦОД с фиксированными портами актуальных скоростей 10G/25G/100G и поддержкой технологий для построения фабрик. Ожидаем доступность к заказу данных моделей уже к концу первого квартала следующего года. Также заявляется поддержка данных коммутаторов со стороны системы управления Eltex ECCM, что позволит отслеживать их работу, быстро реагировать на возникающие неполадки, конфигурировать пользовательские сети фабрики. Оборудование вендора также поддерживает реализацию пока только архитектуры Multi-Pod.

Тестирование фабрики Maipu

В нашей демо-лаборатории есть несколько коммутаторов Maipu модели NSS5830-56XQFP с версией MyPower OS 9.8.100.1, мы собрали стенд с архитектурой Multi-Pod, где интерконнект между Pod сделан на уровне Border Leaf и реализован с помощью L3.

Между коммутаторами Leaf в Pod-1 настроили MC-LAG. EVPN Multihoming на текущий момент еще не поддерживается. В качестве серверов/хостов с условным обозначением «DC1-SRV1» и «DC2-SRV1» использовали коммутаторы с настроенными SVI в отдельных VRF в качестве «VM».

DC1-LEAF1

mlag domain 1  node id 1  node role-priority 90  role preempt   system-mac 0001.7a95.000b  keepalive ip destination 172.16.100.5 source 172.16.100.4  link-aggregation 256 mode lacp   interface link-aggregation256  switchport mode trunk  switchport trunk allowed vlan add 1,100,200  switchport trunk pvid vlan 1  mlag peer-link  interface tengigabitethernet0/10  description MC-LAG_PEER-LINK  link-aggregation 256 active  interface tengigabitethernet0/20  description MC-LAG_PEER-LINK  link-aggregation 256 active

 Проверяем корректность настроек MC-LAG.

DC1-LEAF1# sh mlag brief  MLAG domain id        : 1 Role FSM status       : MASTER Peering FSM status    : ESTABLISHED Keepalive FSM status  : ALIVE PTS Service           : ON Up-delay              : 90sec Graceful-restart      : Disabled Number of mlags configured : 0  ----------------------------------------------------- Peer-Link            Link-status Data-status Active-vlans -------------------- ----------- ----------- -------- link-aggregation256  UP          UP          1,100,200  ----------------------------------------------------- Node    ID   Role    System-MAC      System-Priority ------- ---- ------- --------------- ---------------- Self    1    MASTER  0001.7a95.000b  32768           Remote  2    SLAVE   0001.7a95.000b  32768

Underlay построили на OSPF с сегментацией по area для масштабируемости, но можно разбить и на процессы. И здесь привычные многим команды.

DC1-BR-LEAF1

router ospf 1  router-id 172.16.1.10  bfd all-interfaces  passive-interface default  no passive-interface loopback1  no passive-interface tengigabitethernet0/1  no passive-interface tengigabitethernet0/3  no passive-interface tengigabitethernet0/4  network 172.16.1.10 0.0.0.0 area 1  network 192.168.51.0 0.0.0.1 area 1  network 192.168.52.0 0.0.0.1 area 1  network 192.168.60.0 0.0.0.1 area 0

Overlay в каждом Pod реализовали на MP-iBGP EVPN с Route Reflector-ми на уровне Spine, а между Pod настроили Multihop MP-eBGP EVPN.

DC1-SPINE1

router bgp 65001  no auto-summary  no synchronization  bgp router-id 172.16.1.1  neighbor DC2-SPINE peer-group  neighbor DC2-SPINE remote-as 65002  neighbor DC2-SPINE ebgp-multihop 10  neighbor DC2-SPINE update-source loopback1  neighbor LEAF peer-group  neighbor LEAF remote-as 65001  neighbor LEAF update-source loopback1  neighbor 172.16.1.3 peer-group LEAF  neighbor 172.16.1.4 peer-group LEAF  neighbor 172.16.1.10 peer-group LEAF  neighbor 172.16.2.1 peer-group DC2-SPINE  neighbor 172.16.2.2 peer-group DC2-SPINE  address-family l2vpn evpn   neighbor DC2-SPINE activate   neighbor DC2-SPINE send-community both   neighbor DC2-SPINE attribute-unchanged   neighbor LEAF activate   neighbor LEAF route-reflector-client   neighbor LEAF send-community both   neighbor 172.16.1.3 peer-group LEAF   neighbor 172.16.1.4 peer-group LEAF   neighbor 172.16.1.10 peer-group LEAF   neighbor 172.16.2.1 peer-group DC2-SPINE   neighbor 172.16.2.2 peer-group DC2-SPINE   exit-address-family

Настроили Loopback интерфейсы с Secondary IP под Anycast VTEP для MC-LAG. L2VNI со своими RD/RT для каждого VXLAN Instance. Для передачи BUM трафика использовали Ingress репликацию, т.к. BUM Multicast репликация на коммутаторах Maipu еще не поддерживается.

DC1-LEAF1

interface loopback2  description VTEP  ip address 192.168.1.3 255.255.255.255  ip address 192.168.1.254 255.255.255.255 secondary  interface nve1  source 192.168.1.254  mac-address 0001.0001.0001  vxlan 1000,2000 ingress-replication protocol bgp  vxlan 1000  vxlan vnid 1000  address-family evpn   rd 22:1   route-target import 1000:1000   route-target export 1000:1000  vxlan 2000  vxlan vnid 2000  address-family evpn   rd 22:2   route-target import 2000:2000   route-target export 2000:2000

Настроили VRF с L3VNI и IRB интерфейсы с Distributed (Anycast) Gateway.

DC1-LEAF1

ip vrf TENANT1  rd 33:1  l3vnid 1  address-family evpn   route-target import 1:1 ipv4   route-target export 1:1 ipv4  interface vxlan1000  description TENANT1_VLAN100  ip vrf forwarding TENANT1  vxlan distribute-gateway  ip address 10.0.1.1 255.255.255.0  mac-address 0001.0001.1000  interface vxlan2000  description TENANT1_VLAN200  ip vrf forwarding TENANT1  vxlan distribute-gateway  ip address 10.0.2.1 255.255.255.0  mac-address 0001.0001.2000  router bgp 65001  no auto-summary  no synchronization  bgp router-id 172.16.1.3  neighbor SPINE peer-group  neighbor SPINE remote-as 65001  neighbor SPINE update-source loopback1  neighbor 172.16.1.1 peer-group SPINE  neighbor 172.16.1.2 peer-group SPINE  maximum-paths ibgp 8  address-family l2vpn evpn   neighbor SPINE activate   neighbor SPINE send-community both   neighbor 172.16.1.1 peer-group SPINE   neighbor 172.16.1.2 peer-group SPINE   exit-address-family  address-family ipv4 vrf TENANT1   advertise-l2vpn-evpn   network 10.0.1.0 255.255.255.0   network 10.0.2.0 255.255.255.0   exit-address-family

Проверяем BGP пиринг и таблицу маршрутизации на предмет наличия маршрутов EVPN Type 2, 3 и 5.

DC1-LEAF1

DC1-LEAF1#sh bgp l2vpn evpn summary  BGP router identifier 172.16.1.3, local AS number 65001  Neighbor        V          AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd 172.16.1.1      4       65001     955     792       54    0    0 10:36:38       11 172.16.1.2      4       65001     941     789       54    0    0 10:36:55       11 DC1-LEAF1#sh bgp l2vpn evpn all type 2 BGP local router ID is 172.16.1.3 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,               S Stale Origin codes: i - IGP, e - EGP, ? - incomplete EVPN Information for Route Distinguisher:22:1000  MAC/IP Advertisement Routes:       Network(ETID:MAC:IP)                                  Next Hop            Metric     LocPrf Weight Path [B]*> 0:48:0001.0001.1000:0:0.0.0.0/96                      0.0.0.0                  0             32768 i [B]*> 0:48:0001.0100.0110:0:0.0.0.0/96                      0.0.0.0                  0             32768 i [B]* i0:48:0001.0100.0120:0:0.0.0.0/96                      192.168.2.3              0        100      0 65002 i [B]*>i                                                      192.168.2.3              0        100      0 65002 i [B]*> 0:48:0001.0001.1000:32:10.0.1.1/128                   0.0.0.0                  0             32768 i [B]*> 0:48:0001.0100.0110:32:10.0.1.10/128                  0.0.0.0                  0             32768 i [B]* i0:48:0001.0100.0120:32:10.0.1.20/128                  192.168.2.3              0        100      0 65002 i [B]*>i                                                      192.168.2.3              0        100      0 65002 i EVPN Information for Route Distinguisher:22:2000  MAC/IP Advertisement Routes:       Network(ETID:MAC:IP)                                  Next Hop            Metric     LocPrf Weight Path [B]*> 0:48:0001.0001.2000:0:0.0.0.0/96                      0.0.0.0                  0             32768 i [B]*> 0:48:0001.0200.0210:0:0.0.0.0/96                      0.0.0.0                  0             32768 i [B]* i0:48:0001.0222.0220:0:0.0.0.0/96                      192.168.2.3              0        100      0 65002 i [B]*>i                                                      192.168.2.3              0        100      0 65002 i [B]*> 0:48:0001.0001.2000:32:10.0.2.1/128                   0.0.0.0                  0             32768 i [B]*> 0:48:0001.0200.0210:32:10.0.2.10/128                  0.0.0.0                  0             32768 i [B]* i0:48:0001.0222.0220:32:10.0.2.20/128                  192.168.2.3              0        100      0 65002 i [B]*>i                                                      192.168.2.3              0        100      0 65002 i EVPN Information for Route Distinguisher:33:1  MAC/IP Advertisement Routes:       Network(ETID:MAC:IP)                                  Next Hop            Metric     LocPrf Weight Path [B]*> 0:48:0001.0001.1000:32:10.0.1.1/128                   0.0.0.0                  0             32768 i [B]*> 0:48:0001.0100.0110:32:10.0.1.10/128                  0.0.0.0                  0             32768 i [B]*>i0:48:0001.0100.0120:32:10.0.1.20/128                  192.168.2.3              0        100      0 65002 i [B]*> 0:48:0001.0001.2000:32:10.0.2.1/128                   0.0.0.0                  0             32768 i [B]*> 0:48:0001.0200.0210:32:10.0.2.10/128                  0.0.0.0                  0             32768 i [B]*>i0:48:0001.0222.0220:32:10.0.2.20/128                  192.168.2.3              0        100      0 65002 i  DC1-LEAF1#sh bgp l2vpn evpn all type 3 BGP local router ID is 172.16.1.3 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,               S Stale Origin codes: i - IGP, e - EGP, ? - incomplete EVPN Information for Route Distinguisher:22:1000  Inclusive Multicast Ethernet Tag Routes:       Network(Originating IP Addr)                          Next Hop            Metric     LocPrf Weight Path [B]*> 0:32:192.168.1.254/72                                 0.0.0.0                  0             32768 i [B]* i0:32:192.168.2.3/72                                   192.168.2.3              0        100      0 65002 i [B]*>i                                                      192.168.2.3              0        100      0 65002 i EVPN Information for Route Distinguisher:22:2000  Inclusive Multicast Ethernet Tag Routes:       Network(Originating IP Addr)                          Next Hop            Metric     LocPrf Weight Path [B]*> 0:32:192.168.1.254/72                                 0.0.0.0                  0             32768 i [B]*>i0:32:192.168.2.3/72                                   192.168.2.3              0        100      0 65002 i [B]* i                                                      192.168.2.3              0        100      0 65002 i DC1-LEAF1#sh bgp l2vpn evpn all type 5 BGP local router ID is 172.16.1.3 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,               S Stale Origin codes: i - IGP, e - EGP, ? - incomplete EVPN Information for Route Distinguisher:33:1 IP Prefix Routes:             Network(ETID:IP)                                         Next Hop                    Metric LocPrf Weight Path [B]*> 0:24:10.0.1.0/72                                       0.0.0.0                        0         32768 i [B]*> 0:24:10.0.2.0/72                                       0.0.0.0                        0         32768 i

Проверяем наличие VXLAN туннеля и связности между «VM» каждого Pod.

DC1-LEAF1

DC1-LEAF1#sh vxlan tunnel  Number of vxlan tunnel: 1 --------  ------------------------------------------------  ------------------------------------------------  -------- TunnelID  Source                                            Destination                                       State    --------  ------------------------------------------------  ------------------------------------------------  -------- 32768     192.168.1.254                                     192.168.2.3                                       up     DC1-LEAF1#sh vxlan session  Number of vxlan session: 2 ---------- ---------- ---------- --------------------------------------  --------------------------------------  ----------  VXLAN-ID   SessionID  TunnelID   Source                                  Destination                             State       ---------- ---------- ---------- --------------------------------------  --------------------------------------  ----------  1000       32768      32768      192.168.1.254                           192.168.2.3                             up          2000       32768      32768      192.168.1.254                           192.168.2.3                             up           DC1-SRV1#ping vrf TN1-VM1 10.0.1.20 -s 10.0.1.10  Press key (ctrl + shift + 6) interrupt it. Reply from  10.0.1.20: bytes = 76  time = 2 ms Reply from  10.0.1.20: bytes = 76  time = 2 ms Reply from  10.0.1.20: bytes = 76  time = 2 ms Reply from  10.0.1.20: bytes = 76  time = 2 ms Reply from  10.0.1.20: bytes = 76  time = 2 ms Success rate is 100% (5/5). Round-trip min/avg/max = 2/2/2 ms.  DC1-SRV1#ping vrf TN1-VM1 10.0.2.20 -s 10.0.1.10  Press key (ctrl + shift + 6) interrupt it. Reply from  10.0.2.20: bytes = 76  time = 2 ms Reply from  10.0.2.20: bytes = 76  time = 2 ms Reply from  10.0.2.20: bytes = 76  time = 2 ms Reply from  10.0.2.20: bytes = 76  time = 2 ms Reply from  10.0.2.20: bytes = 76  time = 2 ms Success rate is 100% (5/5). Round-trip min/avg/max = 2/2/2 ms.  DC1-SRV1#ping vrf TN1-VM2 10.0.2.20 -s 10.0.2.10  Press key (ctrl + shift + 6) interrupt it. Reply from  10.0.2.20: bytes = 76  time = 2 ms Reply from  10.0.2.20: bytes = 76  time = 2 ms Reply from  10.0.2.20: bytes = 76  time = 2 ms Reply from  10.0.2.20: bytes = 76  time = 2 ms Reply from  10.0.2.20: bytes = 76  time = 2 ms Success rate is 100% (5/5). Round-trip min/avg/max = 2/2/2 ms.  DC1-SRV1#ping vrf TN1-VM2 10.0.1.20 -s 10.0.2.10  Press key (ctrl + shift + 6) interrupt it. Reply from  10.0.1.20: bytes = 76  time = 2 ms Reply from  10.0.1.20: bytes = 76  time = 2 ms Reply from  10.0.1.20: bytes = 76  time = 2 ms Reply from  10.0.1.20: bytes = 76  time = 2 ms Reply from  10.0.1.20: bytes = 76  time = 2 ms Success rate is 100% (5/5). Round-trip min/avg/max = 2/2/2 ms.  DC1-LEAF1#sh arp host vxlan  VXLAN-ID    MAC-Address           IP-Address            INTERFACE             SVLAN/CVLAN     2000        0001.0200.0210        10.0.2.10             link-agg48            200/-           1000        0001.0100.0110        10.0.1.10             link-agg48            100/-          

Как итог, тестирование базового функционала показало, что коммутаторы Maipu позволяют разворачивать VXLAN-EVPN фабрики с архитектурой Multi-Pod.

В следующих статьях посмотрим в деталях на архитектуру Multi-Fabric, а также на такой дополнительный функционал, как ARP Suppression, VM Mobility и т.д. в реализации Maipu.

Итоги

На текущий момент не весь функционал VXLAN-EVPN западных производителей поддерживается 4-кой рассмотренных вендоров, и для кого-то это может стать причиной сделать выбор в пользу Huawei и H3C. Но вендоры не стоят на месте и готовы расширять функционал в обозримом будущем.

В дальнейших статьях по тематике ЦОД планируем более глубоко раскрыть технические аспекты реализации VXLAN-EVPN фабрик и поддерживаемых архитектур у данных вендоров.

Продолжение следует.