Pentru PinePhone a fost pregătită o construcție universală cu 13 distribuții

Salut, Habr. Închei ciclul de articole, dedicat lansării cursului "Inginer de rețea" de la OTUS, pe tehnologia VxLAN EVPN pentru rutare în cadrul unei fabrici și utilizarea Firewall-ului pentru restricționarea accesului între serviciile interne

Părțile anterioare ale ciclului pot fi găsite la linkurile:

• Partea 1 a ciclului — Conectivitatea L2 între servere
• Partea 2 a ciclului — Rutarea între VNI
• Partea 2.5 a ciclului — Abordare teoretică

Astăzi vom continua să analizăm logica rutării în cadrul fabricii VxLAN. În partea anterioară, am studiat rutarea în cadrul fabricii în cadrul unui singur VRF. Totuși, în rețea pot exista o cantitate uriașă de servicii-clienți și toate trebuie distribuite în diferite VRF pentru a restricționa accesul între ele. În plus față de delimitarea rețelei, afacerea poate avea nevoie să conecteze un Firewall pentru a restricționa accesul între aceste servicii. Da, nu poate fi numit cea mai bună soluție, dar realitatea modernă necesită "soluții moderne".

Să examinăm două variante de rutare între VRF:

1. Rutare, fără a ieși din fabrica VxLAN;
2. Rutare pe echipamente externe.

Să începem cu logica rutării între VRF. Există un număr specific de VRF. Pentru a rura între VRF, este necesar să dedicăm un dispozitiv în rețea care să știe despre toate VRF-urile (sau părți din ele, între care este necesară rutarea). Un astfel de dispozitiv poate fi, de exemplu, unul dintre comutatoarele Leaf (sau toate deodată). Această topologie va arăta astfel:

Ce dezavantaje există în această topologie?

Corect, fiecare Leaf trebuie să știe despre toate VRF-urile (și toate informațiile din acestea) din rețea, ceea ce duce la pierderi de memorie și creșterea încărcării pe rețea. Căci, destul de des, fiecare comutator Leaf nu trebuie să știe despre tot ce există în rețea.

Totuși, să examinăm această modalitate mai detaliat, deoarece pentru rețele mici, această variantă este destul de potrivită (dacă nu există cerințe specifice ale afacerii)

În acest moment, s-ar putea să aveți întrebarea cum să transmită informații din VRF în VRF, deoarece sensul acestei tehnologii este exact acela de a limita distribuția informațiilor.

Iar răspunsul se află în funcțiile de export și import al informațiilor de rutare (setarea acestei tehnologii a fost discutată în al doilea partea ciclului). Voi repeta pe scurt:

Atunci când se definește VRF în AF, trebuie specificat route-target pentru import și export de informații de rutare. Acesta poate fi specificat în mod automat. Atunci, în valoare va fi inclus ASN BGP și L3 VNI, legat de VRF. Este convenabil atunci când în fabrică se utilizează doar un singur ASN:

vrf context PROD20
  address-family ipv4 unicast
    route-target export auto      ! În mod automat, RT-65001:99000 este exportat
    route-target import auto

Cu toate acestea, dacă aveți mai mult de un ASN și este necesar să transmiteți rute între acestea, o configurație manuală va fi o variantă mai convenabilă și scalabilă. route-target. Recomandarea în configurarea manuală — alegeți un număr convenabil pentru dumneavoastră, de exemplu, 9999.
Al doilea ar trebui să fie egal cu VNI pentru acest VRF.

Să configurăm astfel:

vrf context PROD10
  address-family ipv4 unicast
    route-target export 9999:99000          
    route-target import 9999:99000
    route-target import 9999:77000         ! Exemplu 1 import din alt VRF
    route-target import 9999:88000         ! Exemplu 2 import din alt VRF

Cum arată în tabela de rutare:

Leaf11# sh ip route vrf prod

192.168.20.0/24, ubest/mbest: 1/0
 *via 10.255.1.20fault, [200/0], 00:24:45, bgp-65001, intern, tag 65001
(evpn) segid: 99000 tunnelid: 0xaff0114 encap: VXLAN ! prefixul este disponibil prin L3VNI 99000

Să analizăm a doua variantă de rutare între VRF — prin echipamente externe, cum ar fi un Firewall.

Se pot presupune mai multe variante de funcționare printr-un dispozitiv extern:

1. Dispozitivul știe ce este VxLAN și putem să-l adăugăm în parte a fabricii;
2. Dispozitivul nu știe nimic despre VxLAN.

Nu ne vom opri la prima variantă, deoarece logica va fi practic aceeași ca cea prezentată mai sus — ducem toate VRF-urile la Firewall și acolo configurăm rutarea între VRF.

Să luăm în considerare a doua variantă, când firewall-ul nostru nu știe nimic despre VxLAN (acum, desigur, apar echipamente cu suport pentru VxLAN. De exemplu, Checkpoint a anunțat suportul în versiunea R81. Puteți citi despre aceasta aici, totuși, acestea sunt încă în faza de testare și nu există certitudini privind stabilitatea funcționării).

La conectarea echipamentului extern, obținem următoarea diagramă:

După cum se vede în diagramă — apare un punct slab la interfața cu Firewall-ul. Este necesar să se considere acest lucru la planificarea rețelei și optimizarea traficului de rețea.

Cu toate acestea, să ne întoarcem la sarcina inițială de rutare între VRF. Ca rezultat al adăugării firewall-ului, ajungem la concluzia că firewall-ul trebuie să cunoască toate VRF-urile. Pentru aceasta, la switch-urile de frontieră trebuie să fie configurate toate VRF-urile, iar firewall-ul se conectează la fiecare VRF printr-o legătură separată.

Ca urmare, schema cu Firewall:

Adică, pe Firewall trebuie să configurăm interfața în fiecare VRF din rețea. În general, logica nu este complicată, iar singurul lucru care ar putea deranja este numărul uriaș de interfețe de pe Firewall, dar aici este momentul să ne gândim la automatizare.

Bine. Am conectat Firewall-ul, l-am adăugat în toate VRF-urile. Dar cum putem acum să facem ca traficul de pe fiecare Leaf să treacă prin acest Firewall?

Pe Leaf-ul conectat la Firewall, nu vor fi probleme, deoarece toate rutele sunt locale:

0.0.0.0/0, ubest/mbest: 1/0
    *via 10.254.13.55, [1/0], 6w5d, static       ! ruta implicită prin Firewall

Dar ce să facem cu Leaf-urile îndepărtate? Cum putem să le transmitem ruta externă implicită?

Corect, prin EVPN route-type 5, ca orice alt prefix în fabrica VxLAN. Totuși, acest lucru nu este atât de simplu (dacă vorbim de Cisco, nu am verificat la alți furnizori).

Trebuie să anunți ruta implicită de la Leaf-ul conectat la Firewall. Dar pentru a transmite ruta, Leaf-ul trebuie să o cunoască. Și aici apare o problemă (poate doar pentru mine), ruta trebuie să fie configurată static în acel VRF în care dorești să anunți o astfel de rută:

vrf context PROD10
    ip route 0.0.0.0/0 10.254.13.55

Apoi, în configurația BGP, trebuie să specifici această rută în AF IPv4:

router bgp 65001
    vrf prod
        address-family ipv4 unicast
            network 0.0.0.0/0

Dar aceasta nu este tot. Astfel, ruta implicită nu va ajunge în familia l2vpn evpn. În plus, trebuie să configurezi redistribuția:

router bgp 65001
    vrf prod
        address-family ipv4 unicast
            network 0.0.0.0/0
            redistribute static route-map COMMON_OUT

Specificăm ce prefixe vor ajunge în BGP prin redistribuție

route-map COMMON_OUT permit 10
  match ip address prefix-list COMMON_OUT

ip prefix-list COMMON_OUT seq 10 permit 0.0.0.0/0

Acum prefixul 0.0.0.0/0 ajunge în EVPN route-type 5 și este transmis celorlalte Leaf-uri:

0.0.0.0/0, ubest/mbest: 1/0
 *via 10.255.1.5fault, [200/0], 5w6d, bgp-65001, internal, tag 65001, segid: 99000 tunnelid: 0xaff0105 encap: VXLAN
 ! 10.255.1.5 - Adresa virtuală a Leaf-ului (deoarece Leaf-urile acționează ca o pereche VPS), la care este conectat Firewall-ul

În tabela BGP, putem observa de asemenea primit ruta route-type 5 cu ruta implicită prin 10.255.1.5:

* i[5]:[0]:[0]:[0]:[0.0.0.0]/224
                      10.255.1.5                        100          0 i
*>i                   10.255.1.5                        100          0 i

Aceasta este ultima parte a seriei de articole dedicate EVPN. În continuare, voi încerca să discut despre funcționarea VxLAN în combinație cu Multicast, deoarece această metodă este considerată mai scalabilă (deocamdată, o afirmație controversată).

Dacă aveți întrebări sau sugestii cu privire la subiectul legat de funcționalitatea EVPN, vă rugăm să ne scrieți, le vom analiza suplimentar.

Sursa: habr.com