Përshëndetje, Habr. Po përfundoj ciklin e artikujve, të dedikuar për lançimin e kursit nga OTUS, mbi teknologjinë VxLAN EVPN për ruterin brenda fabrikës dhe përdorimin e Firewall për kufizimin e aksesit midis shërbimeve të brendshme
Pjesët e mëparshme të ciklit mund të gjenden në lidhjet:
Sot do të vazhdojmë të studiojmë logjikën e ruterimit brenda fabrikës VxLAN. Në pjesën e mëparshme shqyrtuam ruterimin brenda fabrikës në kuadër të një VRF. Megjithatë, në rrjet mund të ketë një numër të madh shërbimesh-klient dhe të gjitha duhet të shpërndahen në VRF të ndryshme, për të kufizuar aksesin midis tyre. Shtesë në ndarjen rrjetore, biznesi mund t'i nevojitet të lidhë Firewall, për të kufizuar aksesin midis këtyre shërbimeve. Po, nuk është e drejtë ta quajmë këtë zgjidhjen më të mirë, megjithatë realitetet moderne kërkojnë "zgjidhje moderne".
Le të shqyrtojmë dy variante ruterimi midis VRF:
- Ruterimi, pa dalë nga fabrika VxLAN;
- Ruterimi në pajisjet e jashtme.
Le të fillojmë me logjikën e ruterimit midis VRF. Ka një numër të caktuar VRF. Për të ruteruar midis VRF, është e nevojshme të ndahen pajisje në rrjet, të cilat do të dinë për të gjitha VRF (ose për një pjesë, midis të cilave nevojitet ruterimi). Një pajisje e tillë mund të jetë, për shembull, një nga switch-at Leaf (ose të gjitha menjëherë). Kjo topologji do të duket si më poshtë:
Cilat janë disavantazhet në një topologji të tillë?
Saktë, çdo Leaf duhet të dijë për të gjitha VRF (dhe të gjitha informacionet që ka në to) në rrjet, që çon në humbjen e memories dhe rritjen e ngarkesës në rrjet. Sepse shpesh çdo switch Leaf nuk ka nevojë të dijë për gjithçka që ekziston në rrjet.
Megjithatë, le të shqyrtojmë këtë mënyrë më në detaje, pasi për rrjete të vogla, ky variant është plotësisht i përshtatshëm (nëse nuk ka ndonjë kërkesë specifike nga biznesi)
Në këtë pikë, mund të keni një pyetje, si të transmetoni informacionin nga VRF në VRF, sepse kuptimi i kësaj teknologjie është që shpërndarja e informacionit duhet të jetë e kufizuar.
Dhe përgjigjja është e fshehur në funksionet e tilla si eksport dhe import i informacionit të ruterit (konfigurimi i kësaj teknologjie është shqyrtuar në pjesën e ciklit). Shkurtimisht, do ta përsëris:
Kur caktohet VRF në AF, duhet të tregohet route-target për import dhe eksport të informacionit të rrugëve. Mund të caktosh atë në mënyrë automatike. Atëherë në vlerë do të përfshihet ASN BGP dhe L3 VNI, të lidhur me VRF. Kjo është praktike kur në fabrikën tuaj përdoret vetëm një ASN:
vrf konteksti PROD20
address-family ipv4 unicast
route-target eksport auto ! Në mënyrë automatike eksporton RT-65001:99000
route-target import autoMegjithatĂ«, nĂ«se keni mĂ« shumĂ« se njĂ« ASN dhe Ă«shtĂ« e nevojshme tĂ« kaloni rrugĂ«t midis tyre, atĂ«herĂ« njĂ« opsion mĂ« i pĂ«rshtatshĂ«m dhe i shkallĂ«zueshĂ«m do tĂ« ishte konfigurimi manual. route-target. Rekomandimi pĂ«r konfigurimin manual â numri i parĂ«, pĂ«rdoreni atĂ« qĂ« ju pĂ«rshtatet, pĂ«r shembull, 9999.
Numri i dytë duhet të bëhet i barabartë me VNI për këtë VRF.
Do ta konfigurojmë si më poshtë:
vrf konteksti PROD10
address-family ipv4 unicast
route-target eksport 9999:99000
route-target import 9999:99000
route-target import 9999:77000 ! Shembulli 1 import nga një VRF tjetër
route-target import 9999:88000 ! Shembulli 2 import nga një VRF tjetërSi duket në tabelën e rrugëve:
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, internal, tag 65001
(evpn) segid: 99000 tunnelid: 0xaff0114 encap: VXLAN ! prefiksi Ă«shtĂ« e disponueshme pĂ«rmes L3VNI 99000Le tĂ« shqyrtojmĂ« variantin e dytĂ« tĂ« rrugĂ«timit midis VRF â pĂ«rmes pajisjeve tĂ« jashtme, pĂ«r shembull Firewall.
Mund të supozojmë disa variante funksionimi përmes një pajisjeje të jashtme:
- Pajisja e di se çfarë është VxLAN dhe ne mund ta shtojmë atë në pjesën e fabrikës;
- Pajisja nuk di absolutisht asgjë për VxLAN.
TĂ« ndalemi nĂ« variantin e parĂ«, sepse logjika do tĂ« jetĂ« praktikisht e njĂ«jtĂ«, siç u tregua mĂ« sipĂ«r â ne pĂ«rfundojmĂ« tĂ« gjitha VRF te Firewall dhe atje e rregullojmĂ« rrugĂ«timin midis VRF.
Le të shqyrtojmë variantin e dytë, kur Firewall-i ynë nuk di asgjë për VxLAN (sot, natyrisht, po dalin pajisje me mbështetje për VxLAN. Për shembull, Checkpoint njoftoi mbështetje për të në versionin R81. Mund ta lexoni për këtë , megjithatë, kjo është ende në fazën e testimit dhe nuk ka siguri për stabilitetin e funksionimit).
Kur lidhet një pajisje e jashtme, ne kemi një skemë si më poshtë:
Siç duket nga skema â shfaqet njĂ« ngushticĂ« nĂ« lidhjen me Firewall. ĂshtĂ« e nevojshme ta merrni kĂ«tĂ« parasysh nĂ« vazhdimĂ«si gjatĂ« planifikimit tĂ« rrjetit dhe optimizimit tĂ« trafikut tĂ« rrjetit.
Megjithatë, le të kthehemi te detyra fillestare e rrugëtimit midis VRF. Si rezultat i bashkimit të Firewall, arrijmë në përfundimin se Firewall duhet të dijë për të gjithë VRF-të. Për këtë qëllim, në Leaf-in përfundimtar gjithashtu duhet të jenë konfiguruar të gjithë VRF-të, dhe Firewall-i lidhet në çdo VRF me një lidhje të veçantë.
Si rezultat, skema me Firewall:
Pra, duhet të konfiguroni një ndërfaqe në Firewalle për çdo VRF që ndodhet në rrjet. Në përgjithësi, logjika duket jo e komplikuar dhe e vetmja gjë që mund të mos pëlqehet është numri i madh i ndërfaqeve në Firewall, por këtu është e nevojshme të mendojmë për automatizimin.
Mirë. E bashkuam Firewall-in, e shtuam në të gjitha VRF-të. Po si tani ta detyrojmë trafikun nga çdo Leaf të kalojë përmes këtij Firewall-i?
Në Leaf-in e lidhur me Firewall-in, nuk do të ketë ndonjë problem, pasi të gjitha rrugët janë lokale:
0.0.0.0/0, ubest/mbest: 1/0
*nga 10.254.13.55, [1/0], 6w5d, statike ! rruga e parazgjedhur përmes Firewall-itMegjithatë, çfarë duhet të bëjmë me Leaf-at e largët? Si t'ua dërgojmë atyre rrugën e jashtme për parazgjedhjen?
E saktë, përmes EVPN route-type 5, ashtu si çdo prefiks tjetër në fabrikën VxLAN. Megjithatë, me këtë nuk është kaq e thjeshtë (nëse flasim për cisco, si te shpërndarësit e tjerë nuk e kam verifikuar)
Duhet të anonsohet rruga e parazgjedhur nga Leaf-i, me të cilin lidhet Firewall-i. Megjithatë, për të transmetuar rrugën, Leaf-i duhet ta njohë atë vetë. Dhe këtu krijohet një problem i vogël (ndoshta vetëm për mua), rruga duhet të shkruhet statikisht në atë VRF ku dëshironi të anonsioni një rrugë të tillë:
vrf konteksti PROD10
ip rruga 0.0.0.0/0 10.254.13.55Më pas në konfigurimin e BGP për të caktuar këtë rrugë në AF IPv4:
router bgp 65001
vrf prod
adresa-familja ipv4 unicast
rrjeti 0.0.0.0/0Megjithatë, kjo nuk është gjithçka. Kështu, rruga e parazgjedhur nuk do të kalojë në familjen l2vpn evpn. Përveç kësaj, duhet të konfiguroni ri-distribuimin:
router bgp 65001
vrf prod
adresa-familja ipv4 unicast
rrjeti 0.0.0.0/0
ri-distribuoni statike rrugë-mape KOMUN_OUTSpecifikojmë se cilat prefiks do të kalojnë në BGP përmes ri-distribuimit
rrugë-mape KOMUN_OUT lejo 10
ndesh ip adresë prefix-list KOMUN_OUT
ip prefix-list KOMUN_OUT seq 10 lejo 0.0.0.0/0Tani prefiksi 0.0.0.0/0 kalon në EVPN route-type 5 dhe i dërgohet Leaf-ve të tjerë:
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 Virtuale Leaf (pasi Leaf vepron si çift VPХ), të cilës i është lidhur FirewallNë tabelën BGP gjithashtu mund të shohim marrëveshjen route-type 5 me rrugën e parazgjedhur përmes 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 iMbyl kjo cikli i artikujve të dedikuar për EVPN. Në të ardhmen, do të përpiqem të shqyrtoj funksionimin e VxLAN në lidhje me Multicast, pasi ky mënyrë konsiderohet më e shkallëzueshme (në këtë moment është një pretendim i diskutueshëm).
Nëse keni pyetje ose sugjerime për të shqyrtuar ndonjë funksionalitet të EVPN-it, ju lutem, na shkruani, do ta shqyrtojmë më tej.
Burimi: habr.com
