Hei, Habr. Jeg fortsetter serien med artikler om VxLAN EVPN-teknologi, som ble skrevet spesielt for lanseringen av kurset av OTUS. Og i dag skal vi se på en interessant del av oppgaven - ruting. Uansett hvor trivielt det kan høres ut, innenfor rammen av arbeidet til en nettverksfabrikk, er kanskje ikke alt så enkelt.
I den siste delen oppnådde vi ett kringkastingsdomene bygget på toppen av nettverksstrukturen på Nexus 9000v. Dette er imidlertid ikke hele spekteret av oppgaver som må løses innenfor datasenternettverket. Og i dag skal vi se på neste oppgave - ruting mellom nettverk eller mellom VNI-er.
La meg minne deg på at Spine-Leaf-topologien brukes:
La oss først se på hvordan ruting oppstår og hvilke funksjoner den har.
For å forstå, la oss forenkle det logiske diagrammet og legge til en annen VNI 20000 for Host-2. Resultatet er:
Hvordan kan du i dette tilfellet overføre trafikk fra en vert til en annen?
Det er to alternativer:
- Hold informasjon om alle VNI-er på alle Leaf-svitsjer, så vil all ruting skje på den første Leaf i nettverket;
- Bruk en dedikert L3 VNI
Den første metoden er enkel og praktisk. Siden du bare trenger å installere alle VNI på alle Leaf-svitsjer. Å sette opp flere hundre eller tusen VNI-er for alle Leafs virker imidlertid ikke lenger som en enkel oppgave. Derfor brukes den ganske sjelden i arbeid.
La oss se på metode 2, som er mer interessant og litt mer kompleks, men gir mer fleksibilitet i å sette opp fabrikken.
La oss legge til "PROD" til VRF-topologien. Til den vil vi legge til grensesnitt vlan 10 på Leaf-11/12-paret og grensesnitt VLAN 20 på Leaf-21. VLAN 20 er assosiert med 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-gatewayFor å bruke L3VNI, må du opprette et nytt VLAN og knytte det til det nye VNI. Den nye VNI-en må være den samme på alle Leafs som er interessert i VLAN 10- og 20-informasjon
vlan 99
vn-segment 99000
interface nve1
member vni 99000 associate-vrf ! Создаем L3 VNI
vrf context PROD
vni 99000 ! Привязываем L3 VNI к определенному VRFSom et resultat vil diagrammet se slik ut:
Det gjenstår å gjøre litt - legg til et grensesnitt til - grensesnitt vlan 99 i VRF PROD
interface Vlan99
no shutdown
vrf member PROD
ip forward ! На интерфейсе не должно быть IP. Используется только для пересылки пакетов между LeafSom et resultat er logikken for å sende en ramme fra Host-1 til Host-2 som følger:
- Rammen sendt av Host-1 ankommer Leaf i VLAN 10, som er assosiert med VNI 10000;
- Leaf sjekker hvor destinasjonsadressen er og finner den gjennom L3 VNI på den andre Leaf-bryteren;
- Så snart en rute til destinasjonsadressen er funnet, pakker Leaf rammen inn i en header med den nødvendige L3VNI 99000 - og sender den mot den andre Leaf;
- Den andre Leaf-svitsjen mottar data fra L3VNI 99000. Den tar den originale rammen og overfører den til den nødvendige L2VNI 20000 og deretter til VLAN 20.
Som et resultat av dette arbeidet eliminerer L3VNI behovet for å holde informasjon om alle VNI-er som er på nettverket på alle Leaf-svitsjer.
Som et resultat, når vi sender trafikk fra Host-1 til Host-2, blir pakken pakket inne i VxLAN med en ny VNI - 99000:
Det gjenstår å se hvordan nøyaktig Leaf-1 lærer om MAC-adressen fra en annen VNI. Dette skjer også ved bruk av EVPN-rutetype 2 (MAC/IP).
Følgende viser prosessen med å spre en rute om et prefiks som ligger i en annen VNI:
Det vil si at adresser mottatt fra VNI 20000 har to RT-er.
La meg minne deg på at ruter mottatt fra Update havner i BGP-tabellen med rutemålet spesifisert i VRF-innstillingene (prosessen er noe mer komplisert, men vi skal ikke gå nærmere inn på denne artikkelen).
RT selv er dannet i henhold til formelen: AS:VNI (hvis automatisk modus brukes).
Eksempel på RT-formasjon i automatisk og manuell modus:
vrf context PROD
address-family ipv4 unicast
route-target import auto - автоматический режим работы
route-target export 65001:20000 - ручной режим формирования RTResultatet ovenfor viser at prefikser fra en annen VNI har to RT-verdier.
En av dem er 65001:99000 - en ekstra L3 VNI. Siden denne VNI er den samme på alle Leafs og faller inn under våre importregler i VRF-innstillingene, havner prefikset i BGP-tabellen, som kan sees fra utdata:
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 iHvis vi ser nærmere på den mottatte oppdateringen, kan vi se at dette prefikset har to RT-er:
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
<......>I rutetabellen på Leaf-1 kan du også se prefikset 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 99000Har du lagt merke til fraværet av hovedprefikset 192.168.20.0/24 i rutetabellen?
Det stemmer, han er ikke der. Det vil si at eksterne Leafs mottar kun informasjon om vertene som er på nettverket ditt. Og dette er riktig oppførsel. Ovenfor i alle oppdateringer kan du se at informasjon kommer med MAC/IP-innhold. Det er ikke snakk om noen prefikser.
Dette er hvordan Host Mobility Manager (HMM)-protokollen fungerer, som fyller ARP-tabellen som BGP-tabellen deretter fylles fra (vi vil utelate denne prosessen i denne artikkelens formål). Basert på informasjonen mottatt fra HMM, dannes EVPN rutetype 2 (overført av MAC/IP).
Men hva om det er behov for å overføre informasjon om et prefiks?
For denne typen informasjon er det EVPN-rutetype 5 - den lar deg overføre prefikser via adressefamilien l2vpn evpn (denne typen ruter er i skrivende stund bare i utkastversjonen , på grunn av dette kan oppførselen til denne rutetypen variere mellom forskjellige produsenter)
For å overføre prefikser, er det nødvendig å legge til prefikser som vil bli annonsert i BGP-prosessen for 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 5Som et resultat vil oppdateringen ha:
La oss se på BGP-tabellen. I tillegg til EVPN-rutetype 2,3, har det dukket opp ruter av type 5, som inneholder informasjon om nettverksnummeret:
<......>
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
<.......> Prefikset dukket også opp i rutetabellen:
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, hmmDette avslutter den andre delen av serien med artikler om VxLAN EVPN. I neste del skal vi se på ulike alternativer for ruting mellom VRF-er.
Kilde: www.habr.com