Čau Habr. Pokračuji v sérii článků o technologii VxLAN EVPN, která byly napsány speciálně pro zahájení kurzu od OTUS. A dnes zvážíme zajímavou část úkolů - směrování. Bez ohledu na to, jak banálně to může znít, ale v rámci práce síťové továrny nemusí být všechno tak jednoduché.
V minulém díle jsme dosáhli jedné vysílací domény postavené na síťové látce na Nexus 9000v. To však není celá řada úkolů, které je nutné v rámci sítě datových center řešit. A dnes budeme zvažovat následující úkol - směrování mezi sítěmi nebo mezi VNI.
Dovolte mi připomenout, že se používá topologie Spine-Leaf:
Nejprve analyzujeme, jak dochází ke směrování a jaké funkce má.
Pro pochopení zjednodušíme logické schéma a přidáme další VNI 20000 pro Host-2. Výsledek je:
Jak v tomto případě můžete přenést provoz z jednoho hostitele na druhého?
Existují dvě možnosti:
- Uchovávejte informace o všech VNI na všech přepínačích Leaf, pak veškeré směrování proběhne na prvním Leaf v síti;
- Použijte vyhrazené - L3 VNI
První způsob je jednoduchý a pohodlný. Protože stačí spustit všechny VNI na všech přepínačích Leaf. Provozování několika stovek nebo tisíců VNI na celém Leaf se však již nezdá jako snadný úkol. Proto se v práci používá poměrně zřídka.
Metodu 2 budeme analyzovat jako zajímavější a mírně komplikovanější, ale poskytující větší flexibilitu při zakládání továrny.
K topologii VRF přidáme "PROD". Přidejme k tomu rozhraní vlan 10 na páru Leaf-11/12 a rozhraní VLAN 20 na Leaf-21. VLAN 20 je spojena s 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-gatewayAbyste mohli používat L3VNI, musíte vytvořit novou VLAN a přidružit ji k nové VNI. Nové VNI musí být stejné na všech listech, které mají zájem o informace VLAN 10 a 20.
vlan 99
vn-segment 99000
interface nve1
member vni 99000 associate-vrf ! Создаем L3 VNI
vrf context PROD
vni 99000 ! Привязываем L3 VNI к определенному VRFV důsledku toho bude diagram vypadat takto:
Zbývá trochu dokončit - přidat další rozhraní - rozhraní vlan 99 ve VRF PROD
interface Vlan99
no shutdown
vrf member PROD
ip forward ! На интерфейсе не должно быть IP. Используется только для пересылки пакетов между LeafV důsledku toho je logika předávání rámce z hostitele-1 do hostitele-2 následující:
- Rámec odeslaný hostitelem-1 dorazí na list ve VLAN 10, který je spojen s VNI 10000;
- Leaf zkontroluje, kde je cílová adresa, a najde ji přes L3 VNI na druhém přepínači Leaf;
- Jakmile je nalezena cesta k cílové adrese, Leaf zabalí rámec do hlavičky s nezbytným L3VNI 99000 - a odešle jej směrem k druhému listu;
- Druhý přepínač Leaf přijímá data z L3VNI 99000. Získá originální rámec a přenese jej do požadovaného L2VNI 20000 a následně do VLAN 20.
V důsledku této práce L3VNI odstraňuje potřebu uchovávat informace o všech VNI, které jsou v síti, na všech přepínačích Leaf.
Výsledkem je, že když odesíláme provoz z hostitele-1 do hostitele-2, paket je zabalen do VxLAN s novým VNI - 99000:
Zbývá zjistit, jak přesně se Leaf-1 dozví o MAC adrese z jiného VNI. To se také děje pomocí EVPN trasy typu 2 (MAC / IP).
Následující text ukazuje proces šíření trasy kolem prefixu umístěného v jiném VNI:
To znamená, že adresy přijaté z VNI 20000 mají dva RT.
Připomínám, že routy přijaté z Update spadají do BGP tabulky s Route-target zadaným v nastavení VRF (proces je poněkud složitější, ale do tohoto článku se nebudeme pouštět).
Vlastní RT je tvořena vzorcem: AS:VNI (pokud je použit automatický režim).
Příklad tvorby RT v automatickém a manuálním režimu:
vrf context PROD
address-family ipv4 unicast
route-target import auto - автоматический режим работы
route-target export 65001:20000 - ручной режим формирования RTVýsledkem je, že výše vidíte, že předpony z jiného VNI mají dvě hodnoty RT.
Jeden z nich 65001:99000 je další L3 VNI. Vzhledem k tomu, že toto VNI je na všech listech stejné a spadá pod naše pravidla importu v nastavení VRF, dostane se prefix do tabulky BGP, což je vidět z výstupu:
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 iPokud se blíže podíváme na přijatou aktualizaci, můžeme vidět, že tato předpona má dvě 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
<......>Ve směrovací tabulce na Leaf-1 můžete také vidět prefix 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 99000Všimli jste si chybějícího primárního prefixu 192.168.20.0/24 ve směrovací tabulce?
Přesně tak, není tam. To znamená, že vzdálené listy přijímají informace pouze o hostitelích, kteří jsou ve vaší síti. A toto je správné chování. Výše ve všech aktualizacích můžete vidět, že informace přicházejí s obsahem MAC / IP. O žádných předponách se nedá mluvit.
Jedná se o protokol Host Mobility Manager (HMM), který plní ARP tabulku, ze které se dále plní tabulka BGP (tento proces v rámci tohoto článku vynecháme). Na základě informací přijatých z HMM se vytvoří EVPN typu 2 (vysílané MAC / IP).
Co když je však potřeba předat informace o prefixu?
Pro tento typ informací existuje EVPN route-type 5 - umožňuje posílat prefixy přes address-family l2vpn evpn (tento typ trasy je v době psaní tohoto článku pouze v pracovní verzi , z tohoto důvodu mohou mít různí výrobci odlišné chování tohoto typu trasy)
Pro přenos prefixů je nutné přidat prefixy v procesu BGP pro VRF, které budou inzerovány:
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 5V důsledku toho bude aktualizace:
Podívejme se na tabulku BGP. Kromě trasy EVPN typu 2,3 se objevily trasy typu 5, které obsahují informace o čísle sítě:
<......>
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
<.......> Předpona se také objevila ve směrovací tabulce:
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, hmmTímto končí druhá část série článků o VxLAN EVPN. V příštím díle se budeme zabývat různými možnostmi směrování mezi VRF.
Zdroj: www.habr.com