Hej, Habr. Jeg fortsætter cyklussen af artikler om VxLAN EVPN-teknologi, som blev skrevet specielt til lanceringen af kurset fra OTUS. I dag vil vi se på en interessant del af opgaverne – routing. Selvom det måske lyder banalt, kan det i forbindelse med et netværksfabrik arbejde være mere kompliceret.
I den forrige del opnåede vi et enkelt broadcast-domæne opbygget over netværksfabrikken på Nexus 9000v. Men dette er langt fra det fulde spektrum af opgaver, der skal løses i et datacenter-netværk. I dag vil vi fokusere på den næste opgave – routing mellem netværk eller mellem VNI.
Jeg minder om, at vi bruger Spine-Leaf topologi:
Lad os først se på, hvordan routing foregår, og hvilke særtræk der er.
For at forstå det bedre, lad os forenkle den logiske skitse og tilføje en VNI 20000 for Host-2. Det ser derfor ud som følger:
Hvordan kan vi i så fald overføre trafik fra en Host til en anden?
Der er to muligheder:
- At opbevare oplysninger om alle VNI på alle Leaf-switchen, i så fald vil al routing finde sted på den første Leaf i netværket;
- At bruge en dedikeret - L3 VNI
Den første metode er simpel og bekvem. Da det kræver, at alle VNI kun skal indføres på alle Leaf-switchen. Men det at indføre flere hundrede eller tusinde VNI på alle Leaf virker ikke mere som en simpel opgave. Derfor anvendes den i praksis sjældent.
Lad os se nærmere på den anden metode, som er mere interessant og lidt mere kompleks, men giver større fleksibilitet ved opsætningen af fabrikken.
Vi tilføjer VRF "PROD" til topologien. Vi tilføjer interface vlan 10 på parret Leaf-11/12 og interface VLAN 20 på Leaf-21. VLAN 20 associeres med VNI 20000.
vrf context PROD
rd auto ! Route Distinguisher er ikke kritisk, og vi kan bruge det automatisk genererede
address-family ipv4 unicast
route-target both auto ! vi angiver Route-target, som prefiksene vil blive importeret til/eksporteret 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 at bruge L3 VNI skal der oprettes en ny VLAN, som associeres med den nye VNI. Den nye VNI skal være den samme på alle Leaf, der er interesseret i oplysninger om VLAN 10 og 20.
vlan 99
vn-segment 99000
interface nve1
member vni 99000 associate-vrf ! Opretter L3 VNI
vrf context PROD
vni 99000 ! Binder L3 VNI til et bestemt VRFSom resultat vil skemaet se sådan ud:
Der er bare lidt tilbage at udføre — tilføje endnu et interface — interface vlan 99 i VRF PROD
interface Vlan99
no shutdown
vrf member PROD
ip forward ! Der må ikke være IP på interfacet. Det bruges kun til at videresende pakker mellem LeafLogikken for, hvordan en ramme passerer fra Host-1 til Host-2, er som følger:
- Rammen sendt fra Host-1 ankommer til Leaf i VLAN 10, som er tilknyttet VNI 10000;
- Leaf kontrollerer, hvor destinationsadressen er, og finder den via L3 VNI på den anden Leaf-switch;
- Så snart ruten til destinationsadressen er fundet, pakker Leaf rammen med den nødvendige L3VNI 99000 — og sender den mod den anden Leaf;
- Den anden Leaf-switch modtager data fra L3VNI 99000. Den tager den oprindelige ramme og flytter den til den nødvendige L2VNI 20000 og videre til VLAN 20.
Resultatet af dette arbejde er, at L3VNI fjerner behovet for at opbevare information om alle VNI'er, der findes i netværket, på alle Leaf-switcher.
Så når vi sender trafik fra Host-1 til Host-2, bliver pakken pakket ind i VxLAN med et nyt VNI — 99000:
Det er nødvendigt at forstå, hvordan Leaf-1 kender MAC-adressen fra en anden VNI. Dette sker også ved hjælp af EVPN route-type 2 (MAC/IP).
Nedenfor vises processen for spredning af ruten om præfikset, der findes i en anden VNI:
Det vil sige, at adresserne modtaget fra VNI 20000 har to RT.
Husk, at ruter modtaget fra update går ind i BGP-tabellen med route-target angivet i VRF-indstillingerne (processen er noget mere kompleks, men vi vil ikke gå i dybden med det i denne artikel).
Den faktiske RT dannes efter formlen: AS:VNI (hvis automatisk tilstand bruges).
Eksempel på dannelse af RT i automatisk og manuel tilstand:
vrf context PROD
address-family ipv4 unicast
route-target import auto - automatisk driftsmode
route-target export 65001:20000 - manuel RT-dannelseSom det ses ovenfor, har præfikser fra en anden VNI to RT-værdier.
En af dem er 65001:99000 — en ekstra L3 VNI. Da denne VNI er den samme på alle Leaf og falder ind under vores import-regler i VRF-indstillingerne — præfikset går ind i BGP-tabellen, hvilket kan ses af uddataene:
sh bgp l2vpn evpn
Netværk Næste Hop Metrik LocPrf Vægt 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 ! Præfiks modtaget fra VNI 20000
10.255.1.20 100 0 i
*>i 10.255.1.20 100 0 iHvis vi ser nærmere på den modtagne opdatering, kan vi se, at dette præfiks har to RT:
Leaf11# sh bgp l2vpn evpn 5001.0008.0007
BGP rutetabelinformation for VRF default, adressefamilie L2VPN EVPN
Rute Distinguisher: 10.255.1.21:32787
BGP rutetabellenindgang for [2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.20.20]\/272, version 5164
Stier: (2 tilgængelige, bedste #2)
Flag: (0x000202) (high32 00000000) på xmit-liste, er ikke i l2rib\/evpn, er ikke i HW
Stitype: intern, sti er gyldig, ikke bedste grund: Naboadresse, ingen mærket næste hop
AS-Sti: INGEN, sti er kildet intern til AS
10.255.1.20 (metrik 81) fra 10.255.1.102 (10.255.1.102)
Oprindelse IGP, MED ikke indstillet, lokalpref 100, vægt 0
Modtaget mærke 20000 99000 ! To mærker til VxLAN arbejdet
Extcommunity: RT:65001:20000 RT:65001:99000 SOO:10.255.1.20:0 ENCAP:8 ! To værdier Route-target, baseret på, hvilke vi har tilføjet dette præfiks
Router MAC:5001.0005.0007
Oprinderen: 10.255.1.21 Clusterliste: 10.255.1.102I rutetabel på Leaf-1 kan man også se præfiks 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 ! Tilgængelig via Leaf-2
(evpn) segid: 99000 tunnelid: 0xaff0114 encap: VXLAN ! Gennem VNI 99000Har du bemærket manglen på hovedpræfiks 192.168.20.0\/24 i rutetabellen?
Præcis, det er ikke der. Det vil sige, at de fjernede Leaf kun får information om værter, som er i dit netværk. Og det er den rigtige adfærd. Ovenfor i alle opdateringerne ses det, at der kommer information med indhold MAC\/IP. Der tales ikke om nogen præfiks.
Dette fungerer protokollen Host Mobility Manager (HMM), som udfylder ARP-tabellen, som derefter fylder BGP-tabellen (i denne artikel lader vi denne proces ligge). Baseret på informationen modtaget fra HMM dannes EVPN route-type 2 (MAC\/IP sendes).
Men hvad skal man gøre, hvis der er behov for at sende information om et eller andet præfiks?
Til denne type information findes der EVPN route-type 5 — den muliggør transmission af præfikser gennem address-family l2vpn evpn (denne rutetype er ved skrivningen kun i draft-version) , hvilket betyder, at adfærd af denne rutetype kan variere mellem producenter)
For at overføre præfikser er det nødvendigt at tilføje præfikser, der skal annonceres, i BGP for VRF:
router bgp 65001
vrf PROD
address-family ipv4 unicast
redistribute direct route-map VNI20000 ! I dette tilfælde annoncerer vi præfikser fra forbindelsen direkte til Leaf i VNI 20000
route-map VNI20000 permit 10
match ip address prefix-list VNI20000_OUT ! Angiver hvilken prefix-list der skal anvendes
ip prefix-list VNI20000_OUT seq 5 permit 192.168.20.0/24 ! Angiver hvilke netværk der vil blive inkluderet i EVPN route-type 5Resultatet vil være i Update:
Lad os se på BGP-tabellen. Udover EVPN route-type 2 og 3 er der også dukket ruter af type 5 op, som indeholder information om netværksnummeret:
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 med præfiksnummer
10.255.1.10 0 100 0 ?
* i
<.......> I routingtabellen er præfikset også dukket op:
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 ! Fjernpræfiks tilgængelig via Leaf1/2 (Next-hop adresse = virtual IP mellem par VPC)
(evpn) segid: 99000 tunnelid: 0xaff010a encap: VXLAN ! Præfiks tilgængelig gennem 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, hmmVi slutter den anden del af artikelcirklen om VxLAN EVPN her. I den næste del vil vi se på forskellige ruteringsmuligheder mellem VRF.
Kilde: habr.com
Russian
Italian
German
Polish
Estonian
Albanian
Bulgarian
Croatian
Czech
Danish
Dutch
English
French
Hungarian
Latvian
Norwegian
Portuguese
Romanian
Slovak
Slovenian
Spanish
Swedish