Как стать автором
Обновить

Huawei: настройка VXLAN фабрики

Время на прочтение11 мин
Количество просмотров16K

Привет Хабр!

В данной статье хочу поделиться настройкой VXLAN фабрики на оборудовании Huawei. На Хабре, да и на других ресурсах довольно подробно описана технология, как работает control plane, 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 node
Heart beat state : OK
Node 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    : CE8861EI
Node 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 node

M-Lag ID     Interface      Port State    Status                Consistency-check
       1     Eth-Trunk 1    Up            active(*)-active      --

Пример настройки интерфейса внутри фабрики:

interface GE1/0/0
 undo portswitch  #переводим интерфейс в режим L3
 undo shutdown  #административно включаем интерфейс
 ip address 192.168.0.1 31
 ospf network-type p2p #меняем тип OSPF интерфейса на point-to-point
 mtu 9200 #увеличиваем MTU интерфейса

В качестве underlay протокола маршрутизации используется OSPF:

ospf 1 router-id 10.1.1.11
 area 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 brief
OSPF Process 1 with Router ID 10.1.1.11
                   Peer Statistic Information
Total 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 ospf
Proto: Protocol        Pre: Preference
Route Flags: R - relay, D - download to fib, T - to vpn-instance, B - black hole route
------------------------------------------------------------------------------
_public_ Routing Table : OSPF
         Destinations : 11       Routes : 13

OSPF routing table status : <Active>
         Destinations : 8        Routes : 10

Destination/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-domain
vlan 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.3
PING 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 0ms
rtt min/avg/max/mdev = 0.291/0.291/0.291/0.000 ms
#
ubuntu@test-vxlan-01:~$ ip neigh
192.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 150
Flags: * - 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 65000
l2vpn-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.1
PING 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 0ms
rtt min/avg/max/mdev = 0.508/0.508/0.508/0.000 ms

Связность есть, теперь проверим маршрутную информацию:

<Leaf11>disp arp interface Vbdif 150
ARP timeout:1200s
ARP Entry Types: D - Dynamic, S - Static, I - Interface, O - OpenFlow
EXP: Expire-time  src: Source ip   dst: Destination ip

IP ADDRESS      MAC ADDRESS    EXP(M) TYPE/VLAN/CEVLAN   INTERFACE
----------------------------------------------------------------------------------------
192.168.50.254  0000-5e00-0101        I                  Vbdif150
192.168.50.1    0015-5df0-ed07   15   D/150/-            Eth-Trunk1.150
----------------------------------------------------------------------------------------
Total:2         Dynamic:1       Static:0    Interface:1    OpenFlow:0
Redirect: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 и привести некоторые команды необходимые в процессе отладки.

Спасибо за внимание!

Теги:
Хабы:
Всего голосов 11: ↑11 и ↓0+11
Комментарии2

Публикации

Истории

Ближайшие события