Sveiki, Habr. Turpinām rakstu ciklu par VxLAN EVPN tehnoloģiju, kas tika rakstīti īpaši kursa palaišanai no OTUS. Šodien aplūkosim interesantu uzdevumu daļu — maršrutēšanu. Cik visu laiku tas var izklausīties banāli, taču tīkla fabrikas darbā viss var būt ne tik vienkārši.
Iepriekšējā daļā mēs sasniedzām vienu plašu apraides domēnu, kas tika uzbūvēts virs tīkla fabrikas uz Nexus 9000v. Tomēr tas ir tālu no visa uzdevumu spektra, kas jāatrisina datu centra tīklā. Šodien mēs aplūkosim nākamo uzdevumu — maršrutēšanu starp tīklām vai starp VNI.
Atgādinu, ka tiek izmantota Spine-Leaf topoloģija:
Sāksim ar to, kā notiek maršrutēšana un kādas ir iezīmes.
Lai saprastu, vienkāršosim loģisko shēmu un pievienosim vēl vienu VNI 20000 Host-2. Rezultātā iegūstam:
Kā šādā gadījumā var pārsūtīt trafiku no viena hosta uz otru?
Ir divas iespējas:
- Visos Leaf slēgumos saglabāt informāciju par visiem VNI, tad visa maršrutēšana notiks pirmajā Leaf tīklā;
- Izmantot īpaši noteiktu — L3 VNI
Pirmais veids ir vienkāršs un ērts. Jo jāievieš tikai visi VNI visos Leaf slēgumos. Tomēr ieviest vairākus simtus vai tūkstošus VNI visos Leaf vairs neizskatās kā vienkāršs uzdevums. Tādēļ praksē to pielieto diezgan reti.
Apskatīsim otro veidu, kas ir interesantāks un nedaudz sarežģītāks, bet sniedz lielāku elastību fabriku iestatīšanā.
Pievienosim topoloģijai VRF "PROD". Tajā pievienosim interface vlan 10 uz pāra Leaf-11/12 un interface VLAN 20 uz Leaf-21. VLAN 20 saistām ar VNI 20000
vrf context PROD
rd auto ! Maršruta diferencētājs nav būtisks un to varam izmantot automātiski izveidotu
address-family ipv4 unicast
route-target both auto ! norādām maršruta mērķi, ar kuru tiks importēti un eksportēti prefiksi 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-gatewayLai izmantotu L3 VNI, nepieciešams izveidot jaunu VLAN, saistīt to ar jaunu VNI. Jaunam VNI jābūt identiskam visos Leaf, kuri ir ieinteresēti informācijā par VLAN 10 un 20.
vlan 99
vn-segment 99000
interface nve1
member vni 99000 associate-vrf ! Izveidojam L3 VNI
vrf context PROD
vni 99000 ! Saistām L3 VNI ar noteiktu VRFKā rezultātā shēma izskatīsies šādi:
Vēl tikai nedaudz jāpabeidz — jāpievieno vēl viens interfeiss — interface vlan 99 VRF PROD
interface Vlan99
no shutdown
vrf member PROD
ip forward ! Interfeisā nedrīkst būt IP adrese. Tiek izmantots tikai pakotņu pārsūtīšanai starp LeafRezultātā rāmja pārejai no Host-1 uz Host-2 ir sekojoša loģika:
- Rāmis, ko nosūta Host-1, nonāk Leaf VLAN 10, kas asociēts ar VNI 10000;
- Leaf pārbauda, kur atrodas galamērķa adrese, un atrod to caur L3 VNI otrajā Leaf slēdzī;
- Tiklīdz atrasts maršruts uz galamērķa adresi, Leaf iepako rāmju nepieciešamajā L3VNI 99000 un nosūta uz otro Leaf;
- Otrais Leaf slēdzis saņem datus no L3VNI 99000. Tas izņem sākotnējo rāmi un pārvieto to vajadzīgajā L2VNI 20000 un tālāk VLAN 20.
Šādas L3VNI darbības rezultāts novērš nepieciešamību uz visiem Leaf slēdžiem turēt informāciju par visiem VNI, kas atrodas tīklā.
Rezultātā, kad nosūtām trafiku no Host-1 uz Host-2, pakete tiek iepakota VxLAN iekšienē ar jauno VNI — 99000:
Joprojām jāizprot, kā tieši Leaf-1 uzzina par MAC adresi no cita VNI. Tas notiek arī ar EVPN route-type 2 (MAC/IP) palīdzību.
Zemāk parādīts maršruta izplatīšanas process par prefiksu, kas atrodas citā VNI:
Proti, adreses, kas iegūtas no VNI 20000, ir divi RT.
Atgādināšu, ka maršruti, kas iegūti no Update, nonāk BGP tabulā ar Route-target, kas norādīts VRF iestatījumos (process ir nedaudz sarežģītāks, taču šajā rakstā par to neiedziļināsimies).
Pašas RT veidošana notiek pēc formulas: AS:VNI (ja tiek izmantota automātiskā režīma).
Piemērs RT veidošanai automātiskajā un maniskajā režīmā:
vrf context PROD
address-family ipv4 unicast
route-target import auto - automātiskā darba režīms
route-target export 65001:20000 - manuālā RT veidošanas režīmsTādējādi augstāk redzams, ka prefiksi no cita VNI ir divi RT vērtībās.
Viens no tiem ir 65001:99000 — papildu L3 VNI. Tā kā šis VNI ir vienāds visiem Leaf un nonāk mūsu importēšanas noteikumos VRF iestatījumos — prefikss nonāk BGP tabulā, ko var redzēt izvadē:
sh bgp l2vpn evpn
Tīkls Nākamais spertājums Metrika LocPrf Svars Ceļš
Maršruta atšķirētājs: 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
Maršruta atšķirētājs: 10.255.1.21:32787
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.20.20]\/272 ! Prefikss, kas saņemts no VNI 20000
10.255.1.20 100 0 i
*>i 10.255.1.20 100 0 iJa paskatāmies uzmanīgāk uz saņemto atjauninājumu, tad ir redzams, ka šim prefiksam ir divi RT:
Leaf11# sh bgp l2vpn evpn 5001.0008.0007
BGP maršrutēšanas tabulas informācija VRF noklusējuma, adreses ģimene L2VPN EVPN
Maršruta atšķirētājs: 10.255.1.21:32787
BGP maršrutēšanas tabulas ieraksts par [2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.20.20]\/272, versija 5164
Ceļi: (2 pieejami, labākais #2)
Aizzīmes: (0x000202) (high32 00000000) uz xmit-list, nav l2rib\/evpn, nav HW
Ceļa veids: iekšējais, ceļš ir derīgs, nav labākais iemesls: Kaimiņa adrese, nav norādīts nākamais spertājs
AS-Paths: NAV, ceļš avots iekšēji AS
10.255.1.20 (metrika 81) no 10.255.1.102 (10.255.1.102)
Avots IGP, MED nav iestatīts, vietējā preferece 100, svars 0
Saņemts marķējums 20000 99000 ! Divi marķējumi VxLAN darbībai
Extcommunity: RT:65001:20000 RT:65001:99000 SOO:10.255.1.20:0 ENCAP:8 ! Divas Route-target vērtības, uz kuru pamata tika pievienots šis prefikss
Maršrutētāja MAC:5001.0005.0007
Avots: 10.255.1.21 Klastera saraksts: 10.255.1.102Maršrutēšanas tabulā uz Leaf-1 var novērot prefiksu 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 ! Adrese Host-2
*via 10.255.1.20fault, [200/0], 01:20:20, bgp-65001, internal, tag 65001 ! Pieejams caur Leaf-2
(evpn) segid: 99000 tunnelid: 0xaff0114 encap: VXLAN ! Caur VNI 99000Pamanījāt galvenā prefiksa trūkumu 192.168.20.0\/24 maršrutēšanas tabulā?
Tieši tā, tā tur nav. Tas nozīmē, ka attālinātie Leaf saņem informāciju tikai par hostiem, kas ir jūsu tīklā. Un tas ir pareizs uzvedība. Augstāk visos atjauninājumos ir redzams, ka ierodas informācija ar MAC\/IP saturu. Par prefiksiem nav runas.
Tas darbojas protokols Host Mobility Manager(HMM), kas piepilda ARP tabulu, no kuras tālāk tiek piepildīta BGP tabula (šajā rakstā šo procesu izlaidīsim). Pamatojoties uz HMM saņemtajiem datiem, tiek veidoti EVPN route-type 2 (pārraidīti MAC\/IP).
Tomēr, ko darīt, ja ir nepieciešams nodot informāciju par kādu prefiksu?
Šāda veida informācijai pastāv EVPN maršruta veids 5 — ļauj pārsūtīt prefiksus caur address-family l2vpn evpn (šis maršruta veids rakstīšanas brīdī ir tikai koncepta versijā) , tādēļ dažādiem ražotājiem var atšķirties šī maršruta veida darbība
Lai pārsūtītu prefiksus, ir nepieciešams procesā BGP pie VRF pievienot prefiksus, kurus tiks paziņoti:
router bgp 65001
vrf PROD
address-family ipv4 unicast
redistribute direct route-map VNI20000 ! Šajā gadījumā paziņojam prefiksus, kas ir tieši savienoti ar Leaf VNI 20000
route-map VNI20000 permit 10
match ip address prefix-list VNI20000_OUT ! Norādām, kuru izmantot prefix-list
ip prefix-list VNI20000_OUT seq 5 permit 192.168.20.0/24 ! Norādām, kuri tīkli iekļausies EVPN maršruta veidā 5Rezultātā Update būs:
APSkatīsim BGP tabulu. Papildus EVPN maršruta veidiem 2,3 parādījās maršruti 5. tipa, kas satur informāciju par tīkla numuru:
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 maršruta veids 5 ar prefiksu numuru
10.255.1.10 0 100 0 ?
* i
<.......> Maršrutu tabulā prefikss arī parādījās:
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 ! Attālināts prefikss, pieejams caur Leaf1/2 (Next-hop adrese = virtuālā IP starp VPC pāriem)
(evpn) segid: 99000 tunnelid: 0xaff010a encap: VXLAN ! Prefikss pieejams caur 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, hmmAr to mēs noslēdzam otro rakstu ciklu par VxLAN EVPN. Nākamajā daļā apskatīsim dažādus maršrutēšanas variantus starp VRF.
Avots: habr.com
Russian
Italian
German
Polish
Estonian
Albanian
Bulgarian
Croatian
Czech
Danish
Dutch
English
French
Hungarian
Latvian
Portuguese
Romanian
Slovak
Slovenian
Spanish
Swedish