Привет Хабр!
В данной статье хочу поделиться настройкой VXLAN фабрики на оборудовании Huawei. На Хабре, да и на других ресурсах довольно подробна описана технология, как работает control plan, data plane, архитектура и т.д., поэтому в этой статье будет приведена настройка коммутатора с некоторыми пояснениями. Любая критика приветствуется. Для тестирования конфигурации появилась возможность добавить в EVE-NG коммутатор Huawei CE12800. За подробностями сюда и сюда. Data plane к сожалению там работает плохо, но control plane хорошо и не поддерживается часть функционала (m-lag, L3VXLAN например).
Общее описание схемы и подготовка underlay
В фабрике будет использоваться 2 Spine и 4 Leaf (2 из которых объединены в m-lag пару). Между Spine и Leaf коммутаторами используются point to point подсети с 31 маской и увеличен MTU. Используется симметричный IRB. Spine коммутаторы так же будут выполнять роль BGP route reflector. Инкапсуляция и деинкапсуляция будет производиться на Leaf коммутаторах.
Начну с настройки m-lag пары leaf коммутаторов, для правильной работы нужен keepalive линк и peer линк. По peer линку может идти полезная нагрузка поэтому необходимо учитывать полосу пропускания этого линка. Так же следует учитывать, что m-lag в исполнении Huawei накладывает некоторые ограничения, например нельзя построить ospf соседство через агрегированный интерфейс (или можно но с костылями):
dfs-group 1 priority 150 source ip 192.168.1.1 # IP адрес keepalive линка#stp bridge-address 0039-0039-0039 #для правильной работы STP задаем одинаковый bridge id#lacp m-lag system-id 0010-0011-0012 #задаем system id для LACP#interface Eth-Trunk0 #создаем peer линк trunkport INTERFACE #добавляем интерфейс в LAG stp disable mode lacp-static peer-link 1#interface Eth-Trunk1 #пример агрегированного интерфейса в сторону сервера например mode lacp-static dfs-group 1 m-lag 1
Проверяем, что m-lag пара собралась:
<Leaf11>disp dfs-group 1 m-lag* : Local nodeHeart beat state : OKNode 1 * Dfs-Group ID : 1 Priority : 150 Address : ip address 192.168.1.1 State : Master Causation : - System ID : fa1b-d35c-a834 SysName : Leaf11 Version : V200R005C10SPC800 Device Type : CE8861EINode 2 Dfs-Group ID : 1 Priority : 120 Address : ip address 192.168.1.2 State : Backup Causation : - System ID : fa1b-d35c-a235 SysName : Leaf12 Version : V200R005C10SPC800 Device Type : CE8861EI <Leaf11>disp dfs-group 1 node 1 m-lag brief* - Local nodeM-Lag ID Interface Port State Status Consistency-check 1 Eth-Trunk 1 Up active(*)-active --
Пример настройки интерфейса внутри фабрики:
interface GE1/0/0undo portswitch #переводим интерфейс в режим L3undo shutdown #административно включаем интерфейсip address 192.168.0.1 31ospf network-type p2p #меняем тип OSPF интерфейса на point-to-point mtu 9200 #увеличиваем MTU интерфейса
В качестве underlay протокола маршрутизации используется OSPF:
ospf 1 router-id 10.1.1.11area 0.0.0.0 network 10.1.1.1 0.0.0.0 #анонсируем anycast lo только с m-lag пары network 10.1.1.11 0.0.0.0 network 192.168.0.0 0.0.255.255
Так же в качестве протокола маршрутизации можно использовать два BGP процесса, один для underlay маршрутизации и второй для overlay маршрутизации.
bgp AS_UNDERLAY #процесс для underlay маршрутизации <settings>bgp AS_OVERLAY instance EVPN_NAME #процесс для overlay маршрутизации <settings>
С базовыми настройками закончили, проверим, что OSPF собрался и маршруты балансируются между Spine коммутаторами.
<Leaf11>disp ospf peer briefOSPF Process 1 with Router ID 10.1.1.11 Peer Statistic InformationTotal number of peer(s): 2 Peer(s) in full state: 2----------------------------------------------------------------------------- Area Id Interface Neighbor id State 0.0.0.0 GE1/0/0 10.1.1.100 Full 0.0.0.0 GE1/0/1 10.1.1.101 Full-----------------------------------------------------------------------------
Соседство собралось, проверим маршрутную информацию:
<Leaf11>disp ip routing-table protocol ospfProto: Protocol Pre: PreferenceRoute Flags: R - relay, D - download to fib, T - to vpn-instance, B - black hole route------------------------------------------------------------------------------_public_ Routing Table : OSPF Destinations : 11 Routes : 13OSPF routing table status : <Active> Destinations : 8 Routes : 10Destination/Mask Proto Pre Cost Flags NextHop Interface 10.1.1.2/32 OSPF 10 2 D 192.168.0.8 GE1/0/1 OSPF 10 2 D 192.168.0.0 GE1/0/0 10.1.1.3/32 OSPF 10 2 D 192.168.0.8 GE1/0/1 OSPF 10 2 D 192.168.0.0 GE1/0/0 10.1.1.12/32 OSPF 10 2 D 192.168.0.8 GE1/0/1 OSPF 10 2 D 192.168.0.0 GE1/0/0 10.1.1.100/32 OSPF 10 1 D 192.168.0.0 GE1/0/0 10.1.1.101/32 OSPF 10 1 D 192.168.0.8 GE1/0/1
Подготовка overlay
Для начала необходимо глобально включить поддержку EVPN на коммутаторе:
evpn-overlay enable
Spine коммутаторы выполняют роль Route-reflector. Плюс нужно добавить строку undo policy vpn-target в соответствующей address family, чтобы Spine смог принять все маршруты и переслать их клиентам. Соседство строим на loopback адресах.
bgp 65000 group leafs internal peer leafs connect-interface LoopBack0 peer 10.1.1.11 as-number 65000 peer 10.1.1.11 group leafs peer 10.1.1.12 as-number 65000 peer 10.1.1.12 group leafs peer 10.1.1.2 as-number 65000 peer 10.1.1.2 group leafs peer 10.1.1.3 as-number 65000 peer 10.1.1.3 group leafs # ipv4-family unicast undo peer leafs enable undo peer 10.1.1.11 enable undo peer 10.1.1.12 enable undo peer 10.1.1.2 enable undo peer 10.1.1.3 enable # l2vpn-family evpn undo policy vpn-target peer leafs enable peer leafs reflect-client peer 10.1.1.11 enable peer 10.1.1.11 group leafs peer 10.1.1.12 enable peer 10.1.1.12 group leafs peer 10.1.1.2 enable peer 10.1.1.2 group leafs peer 10.1.1.3 enable peer 10.1.1.3 group leafs
На Leaf коммутаторах настраиваем нужный address family. Для m-lag пары хочется сделать политику подменяющую next-hop на anycast loopback ip адрес, но без такой политики все работает. Huawei подменяет next-hop адрес на адрес который указан в качестве source ip адреса интерфейса NVE. Но если вдруг возникнут проблемы с автоматической подменой всегда можно навесить политику руками:
bgp 65000 group rr internal peer rr connect-interface LoopBack0 peer 10.1.1.100 as-number 65000 peer 10.1.1.100 group rr peer 10.1.1.101 as-number 65000 peer 10.1.1.101 group rr # ipv4-family unicast undo peer rr enable undo peer 10.1.1.100 enable undo peer 10.1.1.101 enable # l2vpn-family evpn policy vpn-target peer rr enable peer 10.1.1.100 enable peer 10.1.1.100 group rr peer 10.1.1.101 enable peer 10.1.1.101 group rr
Проверяем, что overlay control plane собрался:
<Leaf11>disp bgp evpn peer BGP local router ID : 10.1.1.11 Local AS number : 65000 Total number of peers : 2 Peers in established state : 2 Peer V AS MsgRcvd MsgSent OutQ Up/Down State PrefRcv 10.1.1.100 4 65000 12829 12811 0 0186h15m Established 0 10.1.1.101 4 65000 12844 12822 0 0186h15m Established 0 <Leaf11>disp bgp evpn peer 10.1.1.100 verbose #лишние строки удалены для сокращения вывода BGP Peer is 10.1.1.100, remote AS 65000 Type: IBGP link Update-group ID: 2 Peer optional capabilities: Peer supports bgp multi-protocol extension Peer supports bgp route refresh capability Peer supports bgp 4-byte-as capability Address family L2VPN EVPN: advertised and received
Подготовка L2 VXLAN
Сперва создадим NVE интерфейс отвечающий за инкапсуляцию/деинкапсуляцию пакетиков:
interface Nve1 #создаем NVE интерфейс source 10.1.1.1 #для m-lag пары используем anycast ip адрес mac-address 0000-5e00-0199 #обязательно для m-lag пары на обоих коммутаторах настраиваем одинаковый MAC адрес, это необходимо для работы L3 VXLAN
Для организации L2 VXLAN необходимо создать bridge-domain и примапить к нему vlan, l2 подинтефейс или интерфейс целиком. К одному bridge-domain могут быть примаплены разные VLANs.
bridge-domain 150 #создаем bridge-domainvlan 150 access-port interface Eth-Trunk12 #можно мапить vlan в конфигурации bridge-domain, а можно в создавать l2 подинтерфейс vxlan vni 22150 #определяем vni evpn #создаем evpn instance route-distinguisher 10.1.1.11:22150 vpn-target 65000:22150 export-extcommunity vpn-target 65000:23500 export-extcommunity #этот rt нужен в будущем для L3 VXLAN vpn-target 65000:22150 import-extcommunity#interface GE1/0/9.150 mode l2 #создаем подинтерфейс encapsulation [default,dot1q,untag,qinq] #выбираем тип инкапсуляции bridge-domain 150 #мапим к нужному bridge-domain#interface Nve1 vni 22150 head-end peer-list protocol bgp #определяем, что для BUM трафика будет использоваться ingress replication list с автообнаружением по BGP
Проделываем такую же работу на остальных коммутаторах и проверяем работу. На коммутаторах должны появиться EVPN маршруты типа 3:
<Leaf11>disp evpn vpn-instance name 150 verbose VPN-Instance Name and ID : 150, 1 Address family evpn Route Distinguisher : 10.1.1.11:22150 Label Policy : label per instance Per-Instance Label : 16,17 Export VPN Targets : 65000:22150 65000:23500 Import VPN Targets : 65000:22150#<Leaf11>disp bgp evpn vpn-instance 150 routing-table inclusive-route BGP Local router ID is 10.1.1.11 Status codes: * - valid, > - best, d - damped, x - best external, a - add path, h - history, i - internal, s - suppressed, S - Stale Origin : i - IGP, e - EGP, ? - incomplete EVPN-Instance 150: Number of Inclusive Multicast Routes: 3 Network(EthTagId/IpAddrLen/OriginalIp) NextHop *> 0:32:10.1.1.1 0.0.0.0 *>i 0:32:10.1.1.2 10.1.1.2 * i 10.1.1.2
Посмотрим попристальнее на анонс полученный от соседа:
<Leaf11>disp bgp evpn vpn-instance 150 routing-table inclusive-route 0:32:10.1.1.2 BGP local router ID : 10.1.1.11 Local AS number : 65000 EVPN-Instance 150: Number of Inclusive Multicast Routes: 2 BGP routing table entry information of 0:32:10.1.1.2: Route Distinguisher: 10.1.1.2:22150 Remote-Cross route Label information (Received/Applied): 22150/NULL #видим нужный нам vni From: 10.1.1.100 (10.1.1.100) Route Duration: 7d19h17m35s Relay Tunnel Out-Interface: VXLAN Original nexthop: 10.1.1.2 Qos information : 0x0 Ext-Community: RT <65000 : 22150>, RT <65000 : 23500>, Tunnel Type <VxLan> AS-path Nil, origin incomplete, localpref 100, pref-val 0, valid, internal, best, select, pre 255 Originator: 10.1.1.2 PMSI: Flags 0, Ingress Replication, Label 0:0:0(22150), Tunnel Identifier:10.1.1.2 Cluster list: 10.1.1.100 Route Type: 3 (Inclusive Multicast Route) Ethernet Tag ID: 0, Originator IP:10.1.1.2/32 Not advertised to any peer yet
BUM трафик должен ходить, можно приступать к проверке связности между хостами. Для этого с хоста VM1 пропингуем хост VM2:
ubuntu@test-vxlan-01:~$ ping 192.168.50.3PING 192.168.50.3 (192.168.50.3) 56(84) bytes of data.64 bytes from 192.168.50.3: icmp_seq=1 ttl=64 time=0.291 ms--- 192.168.50.3 ping statistics ---1 packets transmitted, 1 received, 0% packet loss, time 0msrtt min/avg/max/mdev = 0.291/0.291/0.291/0.000 ms#ubuntu@test-vxlan-01:~$ ip neigh192.168.50.3 dev eth0 lladdr 00:15:5d:65:87:26 REACHABLE
В это время на сети должны появиться анонсы 2 типа. Проверим:
<Leaf11>disp bgp evpn vpn-instance 150 routing-table mac-route BGP Local router ID is 10.1.1.11 Status codes: * - valid, > - best, d - damped, x - best external, a - add path, h - history, i - internal, s - suppressed, S - Stale Origin : i - IGP, e - EGP, ? - incomplete EVN-Instance 150: Number of Mac Routes: 3 Network(EthTagId/MacAddrLen/MacAddr/IpAddrLen/IpAddr) NextHop*>i 0:48:0015-5d65-8726:0:0.0.0.0 10.1.1.2 * i 10.1.1.2 *> 0:48:0015-5df0-ed07:0:0.0.0.0 0.0.0.0
Посмотрим анонс пристальнее:
<Leaf11>disp bgp evpn vpn-instance 150 routing-table mac-route 0:48:0015-5d65-8726:0:0.0.0.0 BGP local router ID : 10.1.1.11 Local AS number : 65000 EVN-Instance 150: Number of Mac Routes: 2 #два маршрута, потому что приходит от двух RR BGP routing table entry information of 0:48:0015-5d65-8726:0:0.0.0.0: Route Distinguisher: 10.1.1.2:22150 Remote-Cross route Label information (Received/Applied): 22150/NULL From: 10.1.1.100 (10.1.1.100) Route Duration: 0d00h07m19s Relay Tunnel Out-Interface: VXLAN Original nexthop: 10.1.1.2 Qos information : 0x0 Ext-Community: RT <65000 : 22150>, RT <65000 : 23500>, Tunnel Type <VxLan> AS-path Nil, origin incomplete, localpref 100, pref-val 0, valid, internal, best, select, pre 255 Route Type: 2 (MAC Advertisement Route) Ethernet Tag ID: 0, MAC Address/Len: 0015-5d65-8726/48, IP Address/Len: 0.0.0.0/0, ESI:0000.0000.0000.0000.0000 Not advertised to any peer yet
Проверяем CAM таблицу коммутатора:
<Leaf11>disp mac-add bridge-domain 150Flags: * - Backup # - forwarding logical interface, operations cannot be performed based on the interface.BD : bridge-domain Age : dynamic MAC learned time in seconds-------------------------------------------------------------------------------MAC Address VLAN/VSI/BD Learned-From Type Age-------------------------------------------------------------------------------0015-5d65-8726 -/-/150 10.1.1.2 evn -0015-5df0-ed07 -/-/150 Eth-Trunk1.150 dynamic 450-------------------------------------------------------------------------------Total items: 2
Подготовка L3 VXLAN
Настало время выпустить хосты за пределы своей подсети, для этого будем использовать distributed gateway.
Для начала создадим нужный VRF:
ip vpn-instance EVPN ipv4-family route-distinguisher 10.1.1.11:23500 vpn-target 65000: 23500 export-extcommunity evpn vpn-target 65000: 23500 import-extcommunity evpn vxlan vni 23500
В конфигурацию BGP Leaf коммутаторов добавляем анонс IRB:
bgp 65000l2vpn-family evpn peer rr advertise irb
Создаем L3 интерфейс для маршрутизации в нужном VRF:
interface Vbdif150 #номер должен совпадать с номером bridge-domain ip binding vpn-instance EVPN ip address 192.168.50.254 24 mac-address 0000-5e00-0101 vxlan anycast-gateway enable arp collect host enable #генерация маршрута второго типа на основании arp записи
Повторяем конфигурации на других Leaf коммутаторах и проверяем:
<Leaf11>disp ip vpn-instance SDC-EVPN VPN-Instance Name RD Address-family EVPN 10.1.1.11:23500 IPv4<Leaf11>disp evpn vpn-instance name __RD_1_10.1.1.11_23500__ verbose VPN-Instance Name and ID : __RD_1_10.1.1.11_23500__, 2 Address family evpn Route Distinguisher : 10.1.1.11:23500 Label Policy : label per instance Per-Instance Label : 17,18 Export VPN Targets : 65000 : 23500 Import VPN Targets : 65000 : 23500
На некоторых моделях коммутаторов (лучше свериться с официальной документацией) необходимо создание специального сервисного интерфейса для продвижения L3 VXLAN трафика. Полоса этого интерфейса должна быть в два раза больше пиковой полосы для L3 VXLAN трафика. При наличии большого количества Vbdif интерфейсов (более 2 тысяч) требуется создание дополнительных сервисных интерфейсов.
interface Eth-TrunkXXX service type tunnel trunkport 40GE1/1/1
На этом настройка L3 VXLAN завершена. Проверим доступность между хостами из разных подсетей:
ubuntu@test-vxlan-01:~$ ping 192.168.51.1PING 192.168.51.1 (192.168.51.1) 56(84) bytes of data.64 bytes from 192.168.51.1: icmp_seq=1 ttl=63 time=0.508 ms--- 192.168.51.1 ping statistics ---1 packets transmitted, 1 received, 0% packet loss, time 0msrtt min/avg/max/mdev = 0.508/0.508/0.508/0.000 ms
Связность есть, теперь проверим маршрутную информацию:
<Leaf11>disp arp interface Vbdif 150ARP timeout:1200sARP Entry Types: D - Dynamic, S - Static, I - Interface, O - OpenFlowEXP: Expire-time src: Source ip dst: Destination ipIP ADDRESS MAC ADDRESS EXP(M) TYPE/VLAN/CEVLAN INTERFACE----------------------------------------------------------------------------------------192.168.50.254 0000-5e00-0101 I Vbdif150192.168.50.1 0015-5df0-ed07 15 D/150/- Eth-Trunk1.150----------------------------------------------------------------------------------------Total:2 Dynamic:1 Static:0 Interface:1 OpenFlow:0Redirect:0#<Leaf1>disp bgp evpn vpn-instance 150 routing-table mac-route BGP Local router ID is 10.1.1.11 Status codes: * - valid, > - best, d - damped, x - best external, a - add path, h - history, i - internal, s - suppressed, S - Stale Origin : i - IGP, e - EGP, ? - incomplete EVN-Instance 150: Number of Mac Routes: 7 Network(EthTagId/MacAddrLen/MacAddr/IpAddrLen/IpAddr) NextHop *> 0:48:0000-5e00-0101:0:0.0.0.0 0.0.0.0 * i 10.1.1.2 * i 10.1.1.2 *>i 0:48:0015-5d65-8726:32:192.168.50.3 10.1.1.2 * i 10.1.1.2 *> 0:48:0015-5df0-ed07:0:0.0.0.0 0.0.0.0 *> 0:48:0015-5df0-ed07:32:192.168.50.1 0.0.0.0
Появились маршруты второго типа включающие в себя IP адреса. Теперь проверим перетекли ли маршруты в нужный VRF:
<Leaf11>disp bgp evpn vpn-instance __RD_1_10.1.1.11_23500__ routing-table mac-route BGP Local router ID is 10.1.1.11 Status codes: * - valid, > - best, d - damped, x - best external, a - add path, h - history, i - internal, s - suppressed, S - Stale Origin : i - IGP, e - EGP, ? - incomplete EVN-Instance __RD_1_10.1.1.11_23500__: Number of Mac Routes: Network(EthTagId/MacAddrLen/MacAddr/IpAddrLen/IpAddr) NextHop*>i 0:48:0015-5d65-8726:32:192.168.50.3 10.1.1.2 * i 10.1.1.2*>i 0:48:0015-5df0-ed08:32:192.168.51.2 10.1.1.3 * i 10.1.1.3#<leaf11>disp bgp evpn vpn-instance __RD_1_10.1.1.11_23500__ routing-table mac-route 0:48:0015-5d65-8726:32:192.168.50.3 BGP local router ID : 10.1.1.11 Local AS number : 65000 EVN-Instance __RD_1_10.1.1.11_23500__: Number of Mac Routes: 2 BGP routing table entry information of 0:48:0015-5d65-8726:32:192.168.50.3: Route Distinguisher: 10.1.1.2:23500 Remote-Cross route Label information (Received/Applied): 22150 23500/NULL #добавился L3 VNI From: From: 10.1.1.100 (10.1.1.100) Route Duration: 7d08h48m44s Relay Tunnel Out-Interface: VXLAN Original nexthop: 10.1.1.2 Qos information : 0x0 Ext-Community: RT <65000 : 22150>, RT <65000 : 23500>Tunnel Type <VxLan>, Router's MAC <3864-0111-1200> #в качестве MAC адреса используется MAC адрес NVE интерфейса VTEPа AS-path Nil, origin incomplete, localpref 100, pref-val 0, valid, internal, best, select, pre 255 Route Type: 2 (MAC Advertisement Route) Ethernet Tag ID: 0, MAC Address/Len: 0015-5d65-8726/48, IP Address/Len: 192.168.50.3/32, ESI:0000.0000.0000.0000.0000 Not advertised to any peer yet
Заключение
В данной статье я попытался описать процесс настройки EVPN VXLAN фабрики на базе оборудования Huawei и привести некоторые команды необходимые в процессе отладки.
Спасибо за внимание!
