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

Хей Хабр. Продължавам поредицата от статии за технологията VxLAN EVPN, която са написани специално за стартирането на курса "Системен инженер" от OTUS. И днес ще разгледаме една интересна част от задачите - маршрутизирането. Колкото и банално да звучи обаче, като част от работата на мрежова фабрика, всичко може да не е толкова просто.

1 част от цикъла - L2 свързаност между сървъри

В последната част постигнахме един излъчван домейн, изграден върху мрежова тъкан на Nexus 9000v. Това обаче не е целият набор от задачи, които трябва да бъдат решени в рамките на мрежата от центрове за данни. И днес ще разгледаме следната задача - маршрутизиране между мрежи или между VNI.

Нека ви напомня, че се използва топологията Spine-Leaf:

Като начало ще анализираме как се извършва маршрутизирането и какви функции има.

За разбиране, нека опростим логическата диаграма и да добавим още един VNI 20000 за Host-2. Резултатът е:

Как в този случай можете да прехвърлите трафик от един хост към друг?

Има две възможности:

Съхранявайте информация за всички VNI на всички Leaf комутатори, след което цялото маршрутизиране ще се извърши на първия Leaf в мрежата;
Използвайте специално - L3 VNI

Първият начин е прост и удобен. Тъй като трябва само да стартирате всички VNI на всички Leaf суичове. Изпълнението на няколкостотин или хиляди VNI на целия Leaf обаче вече не изглежда лесна задача. Следователно в работата се използва доста рядко.

Ще анализираме метод 2, като по-интересен и малко по-сложен, но даващ повече гъвкавост при настройката на фабриката.

Нека добавим "PROD" към VRF топологията. Нека добавим интерфейс vlan 10 към него на двойката Leaf-11/12 и интерфейс VLAN 20 на Leaf-21. VLAN 20 е свързан с VNI 20000

vrf context PROD
  rd auto       ! Route Distinguisher не принципиален и можем использовать сформированный автоматически
  address-family ipv4 unicast
    route-target both auto      ! указываем Route-target с которым будут импортироваться и экспортироваться префиксы в/из VRF
vlan 20
  vn-segment 20000

interface nve 1
  member vni 20000
    ingress-replication protocol bgp

interface Vlan10
  no shutdown
  vrf member PROD
  ip address 192.168.20.1/24
  fabric forwarding mode anycast-gateway

За да използвате L3VNI, трябва да създадете нов VLAN, да го свържете с новия VNI. Новият VNI трябва да е един и същ на всички листове, които се интересуват от информация за VLAN 10 и 20.

vlan 99
  vn-segment 99000

interface nve1
  member vni 99000 associate-vrf        ! Создаем L3 VNI

vrf context PROD
  vni 99000                             ! Привязываем L3 VNI к определенному VRF

В резултат на това диаграмата ще изглежда така:

Остава да довършим малко - добавете още един интерфейс - интерфейс vlan 99 във VRF PROD

interface Vlan99
  no shutdown
  vrf member PROD
  ip forward  ! На интерфейсе не должно быть IP. Используется только для пересылки пакетов между Leaf

В резултат на това логиката на предаване на рамката от Host-1 към Host-2 е следната:

Кадър, изпратен от Host-1, пристига на лист във VLAN 10, който е свързан с VNI 10000;
Leaf проверява къде е целевият адрес и го намира чрез L3 VNI на втория Leaf превключвател;
Веднага щом бъде намерен маршрутът до адреса на местоназначението, Leaf пакетира рамката в заглавка с необходимия L3VNI 99000 - и го изпраща към втория Leaf;
Вторият превключвател Leaf получава данни от L3VNI 99000. Получава оригиналния кадър и го прехвърля към необходимия L2VNI 20000 и след това към VLAN 20.

В резултат на тази работа L3VNI премахва необходимостта да се съхранява информация за всички VNI, които са в мрежата, на всички Leaf комутатори.

В резултат на това, когато изпращаме трафик от Host-1 към Host-2, пакетът се пакетира във VxLAN с новия VNI - 99000:

Остава да видим как точно Leaf-1 научава за MAC адреса от друг VNI. Това се случва и с помощта на EVPN route-type 2 (MAC/IP).

Следното показва процеса на разпространение на маршрут относно префикс, разположен в друг VNI:

Тоест адресите, получени от VNI 20000, имат два RT.
Позволете ми да ви напомня, че маршрутите, получени от Update, попадат в BGP таблицата с Route-target, посочен в настройките на VRF (процесът е малко по-сложен, но няма да навлизаме в тази статия).
Самият RT се формира по формулата: AS:VNI (ако се използва автоматичен режим).

Пример за формиране на RT в автоматичен и ръчен режим:

vrf context PROD
  address-family ipv4 unicast
    route-target import auto - автоматический режим работы
    route-target export 65001:20000 - ручной режим формирования RT

В резултат на това можете да видите по-горе, че префиксите от друг VNI имат две RT стойности.
Един от тях 65001:99000 е допълнителен L3 VNI. Тъй като този VNI е един и същ на всички листове и попада под нашите правила за импортиране в настройките на VRF, префиксът влиза в BGP таблицата, което може да се види от изхода:

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.10                       100      32768 i
*>l[2]:[0]:[0]:[48]:[5001.0007.0007]:[32]:[192.168.10.10]/272
                      10.255.1.10                       100      32768 i
*>l[3]:[0]:[32]:[10.255.1.10]/88
                      10.255.1.10                       100      32768 i

Route Distinguisher: 10.255.1.21:32787
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.20.20]/272    ! Префикс полученный из VNI 20000
                      10.255.1.20                       100          0 i
*>i                   10.255.1.20                       100          0 i

Ако разгледаме по-отблизо получената актуализация, можем да видим, че този префикс има два RT:

Leaf11# sh bgp l2vpn evpn 5001.0008.0007
BGP routing table information for VRF default, address family L2VPN EVPN
Route Distinguisher: 10.255.1.21:32787
BGP routing table entry for [2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.20.2
0]/272, version 5164
Paths: (2 available, best #2)
Flags: (0x000202) (high32 00000000) on xmit-list, is not in l2rib/evpn, is not i
n HW

  Path type: internal, path is valid, not best reason: Neighbor Address, no labeled nexthop
  AS-Path: NONE, path sourced internal to AS
    10.255.1.20 (metric 81) from 10.255.1.102 (10.255.1.102)
      Origin IGP, MED not set, localpref 100, weight 0
      Received label 20000 99000                                 ! Два label для работы VxLAN
      Extcommunity: RT:65001:20000 RT:65001:99000 SOO:10.255.1.20:0 ENCAP:8     ! Два значения Route-target, на основе, которых добавили данный префикс
          Router MAC:5001.0005.0007
      Originator: 10.255.1.21 Cluster list: 10.255.1.102
<......>

В таблицата за маршрутизиране на Leaf-1 можете също да видите префикса 192.168.20.20/32:

Leaf11# sh ip route vrf PROD
192.168.10.0/24, ubest/mbest: 1/0, attached
    *via 192.168.10.1, Vlan10, [0/0], 01:29:28, direct
192.168.10.1/32, ubest/mbest: 1/0, attached
    *via 192.168.10.1, Vlan10, [0/0], 01:29:28, local
192.168.10.10/32, ubest/mbest: 1/0, attached
    *via 192.168.10.10, Vlan10, [190/0], 01:27:22, hmm
192.168.20.20/32, ubest/mbest: 1/0                                        ! Адрес Host-2
    *via 10.255.1.20%default, [200/0], 01:20:20, bgp-65001, internal, tag 65001     ! Доступный через Leaf-2
(evpn) segid: 99000 tunnelid: 0xaff0114 encap: VXLAN                                ! Через VNI 99000

Забелязвате липсващия първичен префикс 192.168.20.0/24 в таблицата за маршрутизиране?
Точно така, него го няма. Тоест отдалечените Leafs получават информация само за хостовете, които са във вашата мрежа. И това е правилното поведение. По-горе във всички актуализации можете да видите, че информацията идва със съдържанието на MAC / IP. Няма префикси, за които да говорим.

Това е протоколът Host Mobility Manager (HMM), който попълва ARP таблицата, от която допълнително се попълва BGP таблицата (ще пропуснем този процес в рамките на тази статия). Въз основа на информацията, получена от HMM, се формират EVPN от тип 2 (предавани от MAC / IP).

Но какво ще стане, ако има нужда да се предаде информация за префикс?

За този тип информация има EVPN route-type 5 - той ви позволява да изпращате префикси чрез адресна фамилия l2vpn evpn (този тип маршрут към момента на писане е само в чернова версия RFC, поради това различните производители може да имат различно поведение на този тип маршрут)

За да прехвърлите префикси, е необходимо да добавите префикси в BGP процеса за VRF, който ще бъде обявен:

router bgp 65001
  vrf PROD
    address-family ipv4 unicast
      redistribute direct route-map VNI20000        ! В данном случае анонсируем префиксы подключение непосредственно к Leaf в VNI 20000
route-map VNI20000 permit 10
  match ip address prefix-list VNI20000_OUT    ! Указываем какой использовать prefix-list

ip prefix-list VNI20000_OUT seq 5 permit 192.168.20.0/24   ! Указываем какие сети будут попадать в EVPN route-type 5

В резултат на това актуализацията ще бъде:

Нека да разгледаме BGP таблицата. В допълнение към EVPN маршрут от тип 2,3 се появиха маршрути от тип 5, които съдържат информация за номера на мрежата:

<......>
   Network            Next Hop            Metric     LocPrf     Weight Path
Route Distinguisher: 10.255.1.11:3
* i[5]:[0]:[0]:[24]:[192.168.10.0]/224
                      10.255.1.10              0        100          0 ?
*>i                   10.255.1.10              0        100          0 ?

Route Distinguisher: 10.255.1.11:32777
* i[2]:[0]:[0]:[48]:[5001.0007.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.0007.0007]:[32]:[192.168.10.10]/272
                      10.255.1.10                       100          0 i
*>i                   10.255.1.10                       100          0 i
* i[3]:[0]:[32]:[10.255.1.10]/88
                      10.255.1.10                       100          0 i
*>i                   10.255.1.10                       100          0 i

Route Distinguisher: 10.255.1.12:3
*>i[5]:[0]:[0]:[24]:[192.168.10.0]/224      ! EVPN route-type 5 с номером префикса
                      10.255.1.10              0        100          0 ?
* i
<.......>

Префиксът също се появи в таблицата за маршрутизиране:

Leaf21# sh ip ro vrf PROD
192.168.10.0/24, ubest/mbest: 1/0
    *via 10.255.1.10%default, [200/0], 00:14:32, bgp-65001, internal, tag 65001  ! Удаленный префикс, доступный через Leaf1/2(адрес Next-hop = virtual IP между парой VPC)
(evpn) segid: 99000 tunnelid: 0xaff010a encap: VXLAN      ! Префикс доступен через L3VNI 99000

192.168.10.10/32, ubest/mbest: 1/0
    *via 10.255.1.10%default, [200/0], 02:33:40, bgp-65001, internal, tag 65001
(evpn) segid: 99000 tunnelid: 0xaff010a encap: VXLAN

192.168.20.0/24, ubest/mbest: 1/0, attached
    *via 192.168.20.1, Vlan20, [0/0], 02:39:44, direct
192.168.20.1/32, ubest/mbest: 1/0, attached
    *via 192.168.20.1, Vlan20, [0/0], 02:39:44, local
192.168.20.20/32, ubest/mbest: 1/0, attached
    *via 192.168.20.20, Vlan20, [190/0], 02:35:46, hmm

Това завършва втората част от поредицата статии за VxLAN EVPN. В следващата част ще разгледаме различни опции за маршрутизиране между VRF.

Основи на IPv6 и как се различава от IPv4

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

VxLAN фабрика. Част 2

Добавяне на нов коментар Отказване на отговора

Добавяне на нов коментар