Hei, Habr. Jeg fortsetter serien av artikler om VxLAN EVPN-teknologi, som ble skrevet spesielt til lanseringen av kurset fra OTUS. I dag skal vi se pĂ„ en interessant del av oppgavene â ruting. Selv om det hĂžres banalt ut, kan det i arbeidet med nettverksfabrikken vĂŠre mer komplisert enn som sĂ„.

I forrige del oppnĂ„dde vi et enkelt domenenettverk, bygget over nettverksfabrikken pĂ„ Nexus 9000v. Men dette er langt fra hele spekteret av oppgaver som mĂ„ lĂžses innenfor datasenterets nettverk. I dag skal vi se pĂ„ den neste oppgaven â ruting mellom nettverk eller mellom VNI.
Jeg minner om at Spine-Leaf-topologien brukes:

La oss fÞrst se pÄ hvordan ruting skjer og hvilke spesielle funksjoner som finnes.
For Ä forenkle forstÄelsen, la oss forenkle det logiske diagrammet og legge til en til VNI 20000 for Host-2. Resultatet blir:

Hvordan kan trafikken overfĂžres fra en Host til en annen i dette tilfellet?
Det finnes to alternativer:
- à ha informasjon om alle VNI pÄ alle Leaf-svitsjer, slik at all ruting skjer pÄ den fÞrste Leaf i nettverket;
- Ă bruke en spesialdedikert â L3 VNI
Den fÞrste metoden er enkel og praktisk. Det kreves bare Ä opprette alle VNI pÄ alle Leaf-svitsjer. Men Ä opprette flere hundre eller tusen VNI pÄ alle Leaf virker ikke lenger som en enkel oppgave. Derfor brukes den i praksis ganske sjelden.
La oss se pÄ den andre metoden, som er mer interessant og litt mer komplisert, men gir stÞrre fleksibilitet i oppsettet av fabrikken.
Vi legger til VRF "PROD" i topologien. Vi tilsvarer VLAN 10 med Leaf-11/12 og VLAN 20 med Leaf-21. VLAN 20 assosieres med VNI 20000
vrf context PROD
rd auto ! Rute Distinguisher er ikke kritisk og vi kan bruke det som er generert automatisk
address-family ipv4 unicast
route-target both auto ! Angir Route-target som prefikser blir importert til og eksportert fra 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 L3 VNI mÄ det opprettes en ny VLAN, assosieres med en ny VNI. Den nye VNI mÄ vÊre lik pÄ alle Leaf som er interessert i informasjon om VLAN 10 og 20
vlan 99
vn-segment 99000
interface nve1
member vni 99000 associate-vrf ! Vi oppretter L3 VNI
vrf context PROD
vni 99000 ! Knytter L3 VNI til en spesifikk VRFSom et resultat vil diagrammet se slik ut:

Det er bare litt igjen Ă„ gjĂžre â legge til en ny grensesnitt â interface vlan 99 i VRF PROD
interface Vlan99
no shutdown
vrf member PROD
ip forward ! Det skal ikke vÊre IP pÄ grensesnittet. Brukes kun til Ä videresende pakker mellom LeafLogikken for pakkeoverfÞring fra Host-1 til Host-2 er som fÞlger:
- Pakke sendt fra Host-1 ankommer Leaf i VLAN 10, som er assosiert med VNI 10000;
- Leaf sjekker hvor destinasjonsadressen befinner seg og finner den via L3 VNI pÄ den andre Leaf-svitsjen;
- SĂ„ snart ruten til destinasjonsadressen er funnet, pakker Leaf inn pakken i en hode med nĂždvendig L3VNI 99000 â og sender til den andre Leaf;
- Den andre Leaf-svitsjen mottar data fra L3VNI 99000. Den henter den opprinnelige pakken og flytter den til nĂždvendig L2VNI 20000 og videre til VLAN 20.
Resultatet av arbeidet med L3VNI fjerner behovet for Ä ha informasjon om alle VNIene i nettverket pÄ alle Leaf-svitsjer.
Dermed, nĂ„r vi sender trafikk fra Host-1 til Host-2, pakkes pakken inn i VxLAN med ny VNI â 99000:

Det gjenstÄr Ä forstÄ hvordan Leaf-1 fÄr vite om MAC-adressen fra en annen VNI. Dette skjer ogsÄ ved hjelp av EVPN route-type 2 (MAC/IP).
Nedenfor vises prosessen med Ă„ spre ruten om prefikset i en annen VNI:

Det vil si at adressene som er mottatt fra VNI 20000 har to RT.
Husk at rutene mottatt fra oppdateringen havner i BGP-tabellen med Route-target angitt i VRF-innstillingene (prosessen er litt mer komplisert, men vi vil ikke gÄ dypere inn i dette i denne artikkelen).
Selve RT dannes etter formelen: AS:VNI (hvis automatisk modus brukes).
Eksempel pÄ dannelse av RT i automatisk og manuell modus:
vrf context PROD
address-family ipv4 unicast
route-target import auto - automatisk drift
route-target export 65001:20000 - manuell dannelse av RTSom nevnt over, ser vi at prefikser fra en annen VNI har to RT-verdier.
Ăn av dem er 65001:99000 â et ekstra L3 VNI. Siden denne VNIen er lik pĂ„ alle Leaf og faller inn under vĂ„re importregler i VRF-innstillingene â havner prefikset i BGP-tabellen, noe som kan ses fra utskriften:
sh bgp l2vpn evpn
Nettverk Neste Hopp Meter LocPrf Vekt Sti
Rute-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
Rute-distinguisher: 10.255.1.21:32787
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.20.20]\/272 ! Prefikset mottatt fra VNI 20000
10.255.1.20 100 0 i
*>i 10.255.1.20 100 0 iSer vi nÊrmere pÄ den mottatte oppdateringen, kan vi se at dette prefikset har to RT:
Leaf11# sh bgp l2vpn evpn 5001.0008.0007
BGP-rutetable-informasjon for VRF standard, adressefamilie L2VPN EVPN
Rute-distinguisher: 10.255.1.21:32787
BGP-ruteoppfĂžring for [2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.20.20]\/272, versjon 5164
Stier: (2 tilgjengelige, best #2)
Flagg: (0x000202) (high32 00000000) pÄ xmit-liste, er ikke i l2rib\/evpn, er ikke i HW
Stitype: intern, sti er gyldig, ikke beste grunn: Nabladresse, ingen merket neste hopp
AS-Sti: INGEN, sti kildet intern til AS
10.255.1.20 (meter 81) fra 10.255.1.102 (10.255.1.102)
Opprinnelse IGP, MED ikke satt, lokalpref 100, vekt 0
Mottatt etikett 20000 99000 ! To etiketter for drift VxLAN
Extcommunity: RT:65001:20000 RT:65001:99000 SOO:10.255.1.20:0 ENCAP:8 ! To verdier for Route-target, som ligger til grunn for Ă„ legge til dette prefikset
Router MAC:5001.0005.0007
Opprinner: 10.255.1.21 Klynge-liste: 10.255.1.102I rutetabellen pÄ Leaf-1 kan vi ogsÄ observere 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 ! Adresse Host-2
*via 10.255.1.20fault, [200/0], 01:20:20, bgp-65001, internal, tag 65001 ! Tilgjengelig via Leaf-2
(evpn) segid: 99000 tunnelid: 0xaff0114 encap: VXLAN ! Gjennom VNI 99000Lagt merke til at det hovedprefikset 192.168.20.0\/24 mangler i rutetabellen?
Riktig, det er ikke der. Det vil si at de fjerne Leaf fÄr informasjon kun om vertene som finnes i nettverket ditt. Og det er riktig oppfÞrsel. Ovenfor i alle oppdateringer er det synlig at informasjon kommer med MAC\/IP-informasjon. Det er ingen snakk om prefikser.
Dette er arbeidet til protokollen Host Mobility Manager (HMM), som fyller ARP-tabellen, som deretter fyller BGP-tabellen (i denne artikkelen vil vi hoppe over denne prosessen). Basert pÄ informasjonen mottatt fra HMM dannes EVPN rute-type 2 (MAC\/IP overfÞres).
Men hva skal man gjĂžre hvis det er behov for Ă„ overfĂžre informasjon om et eller annet prefiks?
For this type of information, there is an EVPN route-type 5 â it allows prefixes to be transmitted via address-family l2vpn evpn (this type of route is currently only in draft version at the time of writing the article. , due to this, the behavior of this type of route may differ among various manufacturers)
To transmit prefixes, it is necessary to add the prefixes that will be announced during BGP for the VRF:
router bgp 65001
vrf PROD
address-family ipv4 unicast
redistribute direct route-map VNI20000 ! In this case, we announce prefixes connecting directly to the Leaf in VNI 20000
route-map VNI20000 permit 10
match ip address prefix-list VNI20000_OUT ! Specify which prefix-list to use
ip prefix-list VNI20000_OUT seq 5 permit 192.168.20.0/24 ! Specify which networks will be included in the EVPN route-type 5As a result, the Update will be:

Let's look at the BGP table. In addition to EVPN route-types 2 and 3, there are now type 5 routes that contain information about the network number:
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 with prefix number
10.255.1.10 0 100 0 ?
* i In the routing table, the prefix has also appeared:
Leaf21# sh ip ro vrf PROD
192.168.10.0/24, ubest/mbest: 1/0
*via 10.255.1.10fault, [200/0], 00:14:32, bgp-65001, internal, tag 65001 ! Fjernprefiks, tilgjengelig via Leaf1/2 (Next-hop adresse = virtuell IP mellom VPC-par)
(evpn) segid: 99000 tunnelid: 0xaff010a encap: VXLAN ! Prefikset er tilgjengelig via L3VNI 99000
192.168.10.10/32, ubest/mbest: 1/0
*via 10.255.1.10fault, [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, hmmWe will conclude the second part of the series of articles on VxLAN EVPN here. In the next part, we will discuss various routing options between VRF.
Kilde: habr.com
