Привет, Хабр! Начнем традиционно – с обзора непростой текущей ситуации. В связи с уходом западных вендоров, которые предлагали решения по построению сетей ЦОД, возник вопрос с дальнейшей поддержкой и развитием сетевой инфраструктуры. Отсутствие техподдержки вендора создает риски для компаний, которые успели развернуть у себя в ЦОД такие проприетарные решения, как 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 фабрик и поддерживаемых архитектур у данных вендоров.
Продолжение следует.
