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