Hej Habr. Jeg fortsætter serien af artikler om VxLAN EVPN-teknologi, som blev skrevet specielt til lanceringen af kurset af OTUS. Og i dag vil vi overveje en interessant del af opgaverne - routing. Uanset hvor banalt det kan lyde, er alt måske ikke så simpelt som en del af arbejdet på en netværksfabrik.
I den sidste del opnåede vi ét broadcast-domæne bygget oven på et netværksstof på en Nexus 9000v. Det er dog ikke hele rækken af opgaver, der skal løses inden for rammerne af datacenternetværket. Og i dag vil vi overveje følgende opgave - routing mellem netværk eller mellem VNI'er.
Lad mig minde dig om, at Spine-Leaf topologien bruges:
Til at begynde med vil vi analysere, hvordan routing opstår, og hvilke funktioner den har.
For forståelse, lad os forenkle det logiske diagram og tilføje endnu en VNI 20000 til Host-2. Resultatet er:
Hvordan kan du i dette tilfælde overføre trafik fra én vært til en anden?
Der er to muligheder:
- Hold information om alle VNI'er på alle Leaf-switche, så vil al routing ske på den første Leaf i netværket;
- Brug dedikeret - L3 VNI
Den første måde er enkel og bekvem. Da du kun behøver at starte alle VNI'er på alle Leaf switches. Men at køre et par hundrede eller tusinder af VNI'er på hele Leaf virker ikke længere som en let opgave. Derfor bruges det i arbejdet ret sjældent.
Vi vil analysere metode 2, som mere interessant og lidt mere kompliceret, men giver mere fleksibilitet i opsætningen af fabrikken.
Lad os tilføje "PROD" til VRF-topologien. Lad os tilføje interface vlan 10 til det på Leaf-11/12-parret og interface VLAN 20 på Leaf-21. VLAN 20 er forbundet 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 at bruge L3VNI skal du oprette et nyt VLAN, knytte det til det nye VNI. Den nye VNI skal være den samme på alle Leafs, der er interesseret i VLAN 10 og 20 information.
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 således ud:
Det er tilbage at afslutte lidt - tilføje et interface mere - interface vlan 99 i VRF PROD
interface Vlan99
no shutdown
vrf member PROD
ip forward ! На интерфейсе не должно быть IP. Используется только для пересылки пакетов между LeafSom et resultat er logikken i at overføre rammen fra Host-1 til Host-2 som følger:
- En ramme sendt af Host-1 ankommer på et blad i VLAN 10, som er forbundet med 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 i en header med den nødvendige L3VNI 99000 - og sender den mod den anden Leaf;
- Den anden Leaf-switch modtager data fra L3VNI 99000. Henter den originale ramme og overfører den til den nødvendige L2VNI 20000 og derefter til VLAN 20.
Som et resultat af dette arbejde fjerner L3VNI behovet for at opbevare information om alle VNI'er, der er på netværket på alle Leaf-switches.
Som et resultat, når vi sender trafik fra Host-1 til Host-2, pakkes pakken inde i VxLAN med den nye VNI - 99000:
Det er stadig at se, hvordan Leaf-1 lærer om MAC-adressen fra en anden VNI. Dette sker også ved hjælp af EVPN rute-type 2 (MAC / IP).
Det følgende viser processen med at udbrede en rute om et præfiks placeret i en anden VNI:
Det vil sige, at adresser modtaget fra VNI 20000 har to RT'er.
Lad mig minde dig om, at ruterne modtaget fra Update falder ind i BGP-tabellen med rutemålet angivet i VRF-indstillingerne (processen er noget mere kompliceret, men vi vil ikke gå ind i denne artikel).
Selve RT er dannet af formlen: AS:VNI (hvis automatisk tilstand bruges).
Et eksempel på RT-dannelse i automatisk og manuel tilstand:
vrf context PROD
address-family ipv4 unicast
route-target import auto - автоматический режим работы
route-target export 65001:20000 - ручной режим формирования RTSom et resultat kan du se ovenfor, at præfikser fra en anden VNI har to RT-værdier.
En af dem 65001:99000 er en ekstra L3 VNI. Da denne VNI er den samme på alle Leafs og falder ind under vores importregler i VRF-indstillingerne, kommer præfikset ind i BGP-tabellen, som kan ses fra outputtet:
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 modtagne opdatering, kan vi se, at dette præfiks 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 præfikset 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 99000Bemærk det manglende primære præfiks 192.168.20.0/24 i routingtabellen?
Det er rigtigt, han er der ikke. Det vil sige, at remote Leafs kun modtager information om de værter, der er på dit netværk. Og dette er den korrekte adfærd. Ovenfor kan du i alle opdateringer se, at information kommer med indholdet af MAC/IP. Der er ingen præfikser at tale om.
Dette er Host Mobility Manager (HMM)-protokollen, som udfylder ARP-tabellen, hvorfra BGP-tabellen udfyldes yderligere (vi vil udelade denne proces inden for rammerne af denne artikel). Baseret på informationen modtaget fra HMM, dannes rutetype 2 EVPN'er (transmitteret af MAC / IP).
Men hvad hvis der er behov for at videregive oplysninger om et præfiks?
Til denne type information er der EVPN rute-type 5 - det giver dig mulighed for at sende præfikser via adressefamilie l2vpn evpn (denne type rute på tidspunktet for dette skrives er kun i udkastet version , på grund af dette kan forskellige producenter have forskellig adfærd af denne type rute)
For at overføre præfikser er det nødvendigt at tilføje præfikser i BGP-processen for VRF, som vil blive annonceret:
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 opdateringen være:
Lad os se på BGP-tabellen. Ud over EVPN-rutetype 2,3 er der dukket ruter af type 5 op, der indeholder oplysninger 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 с номером префикса
10.255.1.10 0 100 0 ?
* i
<.......> Præfikset dukkede også op i routingtabellen:
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 afslutter anden del af en serie artikler om VxLAN EVPN. I den næste del vil vi overveje forskellige muligheder for routing mellem VRF'er.
Kilde: www.habr.com