🥇VxLAN фабрика. Част 1

Здравей, Хабър. В момента съм ръководител на курса "Мрежов инженер" в OTUS.
В навечерието на старта на нова серия от курса "Мрежови инженер", подготвил съм цикъл статии по технологията VxLAN EVPN.

Съществуват огромно количество материали за работа с VxLAN EVPN, затова искам да събера различни задачи и практики за решаване на проблеми в съвременен ЦОД.

В първата част от цикъла по технологията VxLAN EVPN ще разгледам начина на организиране на L2 свързаност между хостовете над мрежовата фабрика.

Всички примери ще изпълним на Cisco Nexus 9000v, свързани в топология Spine-Leaf. Няма да спираме на настройката на Underlay мрежата в рамките на тази статия.

Underlay мрежа
BGP пиринг за address-family l2vpn evpn
Настройка на NVE
Supress-arp

Underlay мрежа

Използваната топология изглежда по следния начин:

Нека зададем адресацията на всички устройства:

Spine-1 - 10.255.1.101
Spine-2 - 10.255.1.102

Leaf-11 - 10.255.1.11
Leaf-12 - 10.255.1.12
Leaf-21 - 10.255.1.21

Host-1 - 192.168.10.10
Host-2 - 192.168.10.20

Да проверим дали има IP свързаност между всички устройства:

Leaf21# sh ip route

10.255.1.11/32, ubest/mbest: 2/0                      ! Leaf-11 достъпен чрез два Spine
    *via 10.255.1.101, Eth1/4, [110/81], 00:00:03, ospf-UNDERLAY, intra
    *via 10.255.1.102, Eth1/3, [110/81], 00:00:03, ospf-UNDERLAY, intra
10.255.1.12/32, ubest/mbest: 2/0                      ! Leaf-12 достъпен чрез два Spine
    *via 10.255.1.101, Eth1/4, [110/81], 00:00:03, ospf-UNDERLAY, intra
    *via 10.255.1.102, Eth1/3, [110/81], 00:00:03, ospf-UNDERLAY, intra
10.255.1.21/32, ubest/mbest: 2/0, attached
    *via 10.255.1.22, Lo0, [0/0], 00:02:20, local
    *via 10.255.1.22, Lo0, [0/0], 00:02:20, direct
10.255.1.101/32, ubest/mbest: 1/0
    *via 10.255.1.101, Eth1/4, [110/41], 00:00:06, ospf-UNDERLAY, intra
10.255.1.102/32, ubest/mbest: 1/0
    *via 10.255.1.102, Eth1/3, [110/41], 00:00:03, ospf-UNDERLAY, intra

Нека проверим дали VPC домейн е създаден и двата комутатора са преминали проверката за консистентност, като настройките на двете ноди са идентични:

Leaf11# show vpc 

vPC domain id                     : 1
Peer status                       : peer adjacency formed ok
vPC keep-alive status             : peer is alive
Configuration consistency status  : success
Per-vlan consistency status       : success
Type-2 consistency status         : success
vPC role                          : primary
Number of vPCs configured         : 0
Peer Gateway                      : Disabled
Dual-active excluded VLANs        : -
Graceful Consistency Check        : Enabled
Auto-recovery status              : Disabled
Delay-restore status              : Timer is off.(timeout = 30s)
Delay-restore SVI status          : Timer is off.(timeout = 10s)
Operational Layer3 Peer-router    : Disabled

vPC status
----------------------------------------------------------------------------
Id    Port          Status Consistency Reason                Active vlans
--    ------------  ------ ----------- ------                ---------------
5     Po5           up     success     success               1

BGP пиринг

Накрая можем да преминем към настройката на Overlay мрежата.

В рамките на статията е необходимо да се организира мрежа между хостовете, както е показано на схемата по-долу:

За да настроим Overlay мрежата, е необходимо да активираме BGP с поддръжка на семейство l2vpn evpn на комутаторите Spine и Leaf:

feature bgp
nv overlay evpn

Следващата стъпка е да настроим BGP пиране между Leaf и Spine. За да опростим конфигурацията и оптимизираме разпространението на маршрутната информация, задаваме Spine като Route-Reflector server. Всички Leaf ще бъдат дефинирани в конфигурацията чрез шаблони за оптимизация на настройката.

Така настройките на Spine изглеждат така:

router bgp 65001
  template peer LEAF 
    remote-as 65001
    update-source loopback0
    address-family l2vpn evpn
      send-community
      send-community extended
      route-reflector-client
  neighbor 10.255.1.11
    inherit peer LEAF
  neighbor 10.255.1.12
    inherit peer LEAF
  neighbor 10.255.1.21
    inherit peer LEAF

Настройките на Leaf комутатора изглеждат по подобен начин:

router bgp 65001
  template peer SPINE
    remote-as 65001
    update-source loopback0
    address-family l2vpn evpn
      send-community
      send-community extended
  neighbor 10.255.1.101
    inherit peer SPINE
  neighbor 10.255.1.102
    inherit peer SPINE

На Spine ще проверим пирането с всички Leaf комутатори:

Spine1# sh bgp l2vpn evpn summary

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.255.1.11     4 65001       7       8        6    0    0 00:01:45 0
10.255.1.12     4 65001       7       7        6    0    0 00:01:16 0
10.255.1.21     4 65001       7       7        6    0    0 00:01:01 0

Както виждаме, с BGP няма проблеми. Преминаваме към настройката на VxLAN. По-нататъшната настройка ще се извършва само от страна на Leaf комутаторите. Spine служи само като ядро на мрежата и извършва единствено предаване на трафик. Цялата работа по инкапсулация и определяне на маршрут се извършва само на Leaf комутаторите.

Настройка на NVE

NVE — виртуален интерфейс на мрежата

Преди да започнем с настройката, нека въведем малко терминология:

VTEP — Vitual Tunnel End Point, устройство, на което започва или завършва VxLAN тунел. VTEP не е задължително да бъде мрежово устройство. Също така може да бъде и сървър с поддръжка на технологията VxLAN. В нашата топология всички Leaf комутатори са VTEP.

VNI — Virtual Network Index — идентификатор на мрежата в рамките на VxLAN. Може да се направи аналогия с VLAN. Въпреки това, има някои разлики. При използване на фабрика, VLAN стават уникални само в рамките на един Leaf комутатор и не се предават през мрежата. Но с всеки VLAN може да бъде асоцииран номер VNI, който вече се предава през мрежата. Как изглежда това и как може да бъде използвано ще бъде разгледано по-нататък.

Активираме функцията за работа на технологията VxLAN и възможността за асоцииране на номера VLAN с номера VNI:

feature nv overlay
feature vn-segment-vlan-based

Настройваме интерфейса NVE, който отговаря за работата на VxLAN. Този интерфейс е отговорен за инкапсулацията на кадрите в заглавията на VxLAN. Може да се направи аналогия с интерфейса Tunnel за работа с GRE:

interface nve1
  no shutdown
  host-reachability protocol bgp ! използваме BGP за предаване на маршрутна информация
  source-interface loopback0    ! интерфейс, от който изпращаме пакети loopback0

На Leaf-21 комутаторът всичко се създава без проблеми. Въпреки това, ако проверим изхода на командата show nve peers, той ще се окаже празен. Тук е необходимо да се върнем към настройката на VPC. Виждаме, че Leaf-11 и Leaf-12 работят в пар и са обединени в VPC домейн. Оттук получаваме следната ситуация:

Host-2 изпраща един кадър към Leaf-21, за да го предаде по мрежата към Host-1. Въпреки това, Leaf-21 вижда, че MAC адресът на Host-1 е достъпен веднага чрез два VTEP. Какво да направи Leaf-21 в този случай? Все пак, това означава, че в мрежата може да се е появила цикличност.

За да разрешим тази ситуация, е необходимо Leaf-11 и Leaf-12 в рамките на фабриката да действат като едно устройство. Това се решава доста просто. На интерфейса Loopback, от който изграждаме тунел, добавяме вторичен адрес. Вторичният адрес трябва да бъде един и същи на двата VTEP.

interface loopback0
 ip add 10.255.1.10/32 secondary

По този начин, от гледна точка на другите VTEP, получаваме следната топология:

Тоест, сега тунелът ще се изгражда между IP адреса на Leaf-21 и виртуалния IP между двата Leaf-11 и Leaf-12. Сега проблеми с изучаването на MAC адреса от две устройства вече няма да възникват и трафикът може да преминава от един VTEP на друг. Кой от двата VTEP ще обработи трафика се решава с помощта на таблицата за маршрутизиране на Spine:

Spine1# sh ip route

10.255.1.10/32, ubest/mbest: 2/0
    *via 10.255.1.11, Eth1/1, [110/41], 1d01h, ospf-UNDERLAY, intra
    *via 10.255.1.12, Eth1/2, [110/41], 1d01h, ospf-UNDERLAY, intra
10.255.1.11/32, ubest/mbest: 1/0
    *via 10.255.1.11, Eth1/1, [110/41], 1d22h, ospf-UNDERLAY, intra
10.255.1.12/32, ubest/mbest: 1/0
    *via 10.255.1.12, Eth1/2, [110/41], 1d01h, ospf-UNDERLAY, intra

Както е видно по-горе, адресът 10.255.1.10 е достъпен веднага чрез два Next-hop.

На този етап разгледахме основната свързаност. Преминаваме към настройката на интерфейса NVE:
Незабавно активираме Vlan 10 и го асоциираме с VNI 10000 на всеки Leaf за хостовете. Настройваме L2 тунел между хостовете

vlan 10                 ! Включваме VLAN на всички VTEP, свързани с необходимите хостове
  vn-segment 10000      ! Свързваме VLAN с номер VNI 

interface nve1
  member vni 10000      ! Добавяме VNI 10000 за работа през интерфейс NVE. за инкапацификация в VxLAN
    ingress-replication protocol bgp    ! указваме, че за разпространение на информацията за хостовете използваме BGP

Сега да проверим nve peers и таблицата за BGP EVPN:

Leaf21# sh nve peers
Interface Peer-IP          State LearnType Uptime   Router-Mac
--------- ---------------  ----- --------- -------- -----------------
nve1      10.255.1.10      Up    CP        00:00:41 n/a                 ! Виждаме, че peer е достъпен с вторичен адрес

Leaf11# sh bgp l2vpn evpn

   Network            Next Hop            Metric     LocPrf     Weight Path
Route Distinguisher: 10.255.1.11:32777    (L2VNI 10000)        ! От кого точно е дошъл този l2VNI
*>l[3]:[0]:[32]:[10.255.1.10]\/88                                   ! EVPN route-type 3 - показва нашия съсед, който също знае за l2VNI10000
                      10.255.1.10                       100      32768 i
*>i[3]:[0]:[32]:[10.255.1.20]\/88
                      10.255.1.20                       100          0 i
* i                   10.255.1.20                       100          0 i

Route Distinguisher: 10.255.1.21:32777
* i[3]:[0]:[32]:[10.255.1.20]\/88
                      10.255.1.20                       100          0 i
*>i                   10.255.1.20                       100          0 i

По-горе виждаме маршрути само EVPN route-type 3. Този тип маршрути предоставя информация за peer(Leaf), но къде са нашите хостове?
Истината е, че информацията за MAC адресите на хостовете се предава чрез EVPN route-type 2

За да видим нашите хостове, е необходимо да настроим EVPN route-type 2:

evpn
  vni 10000 l2
    route-target import auto   ! в рамките на тази статия използваме автоматичен номер за route-target
    route-target export auto

Нека направим ping от Host-2 към Host-1:

Firewall2# ping 192.168.10.1
PING 192.168.10.1 (192.168.10.1): 56 data bytes
36 bytes from 192.168.10.2: Destination Host Unreachable
Request 0 timed out
64 bytes from 192.168.10.1: icmp_seq=1 ttl=254 time=215.555 ms
64 bytes from 192.168.10.1: icmp_seq=2 ttl=254 time=38.756 ms
64 bytes from 192.168.10.1: icmp_seq=3 ttl=254 time=42.484 ms
64 bytes from 192.168.10.1: icmp_seq=4 ttl=254 time=40.983 ms

И по-долу можем да видим, че в таблицата BGP се появиха route-type 2 с MAC адресите на хостовете — 5001.0007.0007 и 5001.0008.0007

Leaf11# sh bgp l2vpn evpn


   Мрежа            Следващ хоп            Метрика     LocPrf     Тегло Път
Маркер на маршрута: 10.255.1.11:32777    (L2VNI 10000)
*>l[2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]\/216                      !  evpn тип маршрут 2 и mac адрес на хост 1
                      10.255.1.10                       100      32768 i
*>i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]\/216                      ! evpn тип маршрут 2 и mac адрес на хост 2
* i                   10.255.1.20                       100          0 i
*>l[3]:[0]:[32]:[10.255.1.10]\/88
                      10.255.1.10                       100      32768 i
Маркер на маршрута: 10.255.1.21:32777
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]\/216
                      10.255.1.20                       100          0 i
*>i                   10.255.1.20                       100          0 i

Следващата стъпка е да прегледате подробната информация за Update, в който получихме данни за MAC хоста. По-долу е представен непълен изход от командата.

Leaf21# sh bgp l2vpn evpn 5001.0007.0007

Информация за BGP маршрутизираща таблица за VRF по подразбиране, адресно семейство L2VPN EVPN
Маркер на маршрута: 10.255.1.11:32777        !  изпратен Update с MAC хост. Не виртуален адрес VPC, а адрес на Leaf
Запис в BGP маршрутизиращата таблица за [2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]\/216,
 версия 1507
Пътища: (2 налични, най-добър #2)
Флагове: (0x000202) (high32 00000000) в xmit-list, не е в l2rib\/evpn, не е в HW

  Тип на пътя: вътрешен, пътят е валиден, не най-добър причина: Адрес на съседа, няма етикиран следващ хоп
  AS-Path: НЯМА, пътят идва от вътрешния AS
    10.255.1.10 (метрика 81) от 10.255.1.102 (10.255.1.102)    ! с кого точно изграждаме VxLAN тунел
      Произход IGP, MED не е зададен, локално предпочитание 100, тегло 0
      Получена етикетка 10000         ! Номер на VNI, който се свързва с VLAN, в който се намира хост
      Extcommunity: RT:65001:10000 SOO:10.255.1.10:0 ENCAP:8        ! Тук се вижда, че RT е образуван автоматично на базата на номера на AS и VNI
      Произходител: 10.255.1.11 Списък на клъстера: 10.255.1.102

Нека видим как изглеждат кадрите, когато се предават през фабриката:

Suppress-ARP

Отлично, L2 свързаност между хостовете вече имаме и тук можеше да приключим. Обаче не всичко е толкова просто. Докато имаме малко хостове, проблеми няма да възникнат. Но нека си представим ситуации, в които имаме стотици или хиляди хостове. С какъв проблем можем да се сблъскаме?

Този проблем е BUM (Broadcast, Unknown Unicast, Multicast) трафик. В рамките на тази статия ще разгледаме вариант за справяне с broadcast трафика.
Основният генератор на Broadcast в Ethernet мрежи са самите хостове чрез протокола ARP.

На Nexus е реализиран следният механизъм за справяне с ARP запитвания — suppress-arp.
Работата на тази функция изглежда по следния начин:

Host-1 изпраща APR запитване на Broadcast адреса на своята мрежа.
Запитването достига до Leaf комутатора и вместо да предаде това запитване нататък във фабриката към Host-2 — Leaf отговаря сам и указва нужния IP и MAC.

Така Broadcast заявката не достигна до фабриката. Но как може това да работи, ако Leaf знае само MAC адреса?

Всичко е доста просто, EVPN route-type 2 освен MAC адреса може да предава връзка MAC/IP. За целта на Leaf е необходимо да се настрои IP адрес в VLAN. Изниква въпросът, какъв IP да зададем? На Nexus има възможност да се създаде разпределен (еднакъв) адрес на всички превключватели:

feature interface-vlan

fabric forwarding anycast-gateway-mac 0001.0001.0001    ! задаваме виртуален mac за създаване на разпределен шлюз между всички превключватели

interface Vlan10
  no shutdown
  ip address 192.168.10.254/24          ! на всички Leaf задаваме еднакъв IP
  fabric forwarding mode anycast-gateway    ! казваме да използва виртуален mac

Така от гледна точка на хостовете мрежата ще изглежда по следния начин:

Нека проверим BGP l2route evpn

Leaf11# sh bgp l2vpn evpn


   Network            Next Hop            Metric     LocPrf     Weight Path
Route Distinguisher: 10.255.1.11:32777    (L2VNI 10000)
* >l[2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]/216
                      10.255.1.21                       100      32768 i
* >i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]/216
                      10.255.1.10                       100          0 i
* i                   10.255.1.10                       100          0 i
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.10.20]/248
                      10.255.1.10                       100          0 i
* >i                   10.255.1.10                       100          0 i



Route Distinguisher: 10.255.1.21:32777
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]/216
                      10.255.1.20                       100          0 i
* >i                   10.255.1.20                       100          0 i
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.10.20]/248
* >i                   10.255.1.20                       100          0 i

От изхода на командата е видно, че в EVPN route-type 2 освен MAC вече виждаме и IP адреса на хоста.

Връщаме се към настройката suppress-arp. Тази настройка се включва за всяко VNI поотделно:

interface nve1
  member vni 10000   
    suppress-arp

Следва да възникне известна сложност:

За работата на тази функция е необходимо място в TCAM паметта. Ще дам пример за настройка на suppress-arp:

hardware access-list tcam region arp-ether 256

За тази настройка е необходим double-wide. Тоест, ако зададете 256, в TCAM трябва да освободите 512. Настройката на TCAM надвишава рамките на тази статия, тъй като настройките на TCAM зависят само от задачата, поставена пред вас, и могат да се различават от една мрежа до друга.

Инсталирането на suppress-arp трябва да се извърши на всички Leaf комутатори. Въпреки това, усложнения могат да възникнат при настройката на двойки Leaf, намиращи се в VPC домейн. При промяна на TCAM, консистентността между двойките ще бъде нарушена и една нода може да бъде изключена. Освен това, за прилагане на настройката за промяна на TCAM може да се наложи рестартиране на устройството.

В резултат на това трябва добре да помислите дали в вашата ситуация е уместно да внедрите тази настройка на работеща фабрика.

С това приключваме първата част на цикъла. В следващата част ще разгледаме маршрутизацията през VxLAN фабрика с разделение на мрежите на различни VRF.

А сега каня всички на безплатен уебинар, в рамките на който ще разкажа подробно за курса. Първите 20 участници, регистрирали се за този уебинар, ще получат Сертификат за отстъпка на електронната си поща в рамките на 1-2 дни след предаването.

Източник: habr.com