Fabrika VxLAN. Pjesa 3

Përshëndetje, Habr. Po përfundoj ciklin e artikujve, të dedikuar për lansimin e kursit "Inxhinieri i rrjetit" nga OTUS, mbi teknologjinë VxLAN EVPN për routing 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 përmes lidhjeve:

• Pjesa 1 e ciklit — L2 lidhshmëria midis serverëve
• Pjesa 2 e ciklit - Routing midis VNI
• Pjesa 2.5 e ciklit - Shkëputje teorike

Sot do të vazhdojmë të studiojmë logjikën e routing-ut brenda fabrikës VxLAN. Në pjesën e mëparshme shqyrtuam routing-un 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ë gjithë duhet të ndahen në VRF të ndryshme, për të kufizuar aksesin midis tyre. Përveç ndarjes rrjet, bizneset mund të kenë nevojë të lidhin Firewall, për të kufizuar aksesin midis këtyre shërbimeve. Po, nuk mund të quhet si zgjidhja më e mirë, por realitetet moderne kërkojnë "zgjidhje moderne".

Do të shqyrtojmë dy opsione për routing midis VRF:

1. Routing, pa dalë nga fabrika VxLAN;
2. Routing në pajisje të jashtme.

Le të fillojmë me logjikën e routing-ut midis VRF. Ka një numër të caktuar VRF. Për të bërë routing midis VRF, është e nevojshme të caktohet një pajisje në rrjet që do të dijë për të gjithë VRF (ose disa, midis të cilave nevojitet routing). Një nga komutatoret Leaf mund të bëhet një pajisje e tillë (ose të gjithë njëherazi). Kjo topologji do të duket si më poshtë:

Cilat janë disavantazhet e një topologjie të tillë?

E saktë, çdo Leaf duhet të dijë për të gjithë VRF (dhe të gjithë informacionin që ka në to) në rrjet, çka çon në humbje memorjeje dhe rritje të ngarkesës në rrjet. Sepse, shpesh komutatorëve Leaf nuk u nevojitet të dinë për gjithçka që është në rrjet.

Megjithatë, le ta shqyrtojmë këtë metodë më në detaje, sepse për rrjete të vogla kjo mund të jetë një variant 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ë kaloni informacionin nga VRF në VRF, sepse pikë e kësaj teknologjie është që shpërndarja e informacionit duhet të jetë e kufizuar.

Dhe përgjigjja është në funksionet si export dhe import të informacionit të routing (konfigurimin e kësaj teknologjie e kemi shqyrtuar në pjesën e dytë pjesën e ciklit). Do ta përsëris shkurtimisht:

Kur caktoni VRF në AF, është e nevojshme të tregoni route-target për import dhe eksportin e informacionit të routing. Këtë mund ta tregoni në mënyrë automatike. Atëherë do të hyjë ASN BGP dhe L3 VNI, i lidhur me VRF. Kjo është e dobishme kur keni vetëm një ASN në fabrikë:

vrf context PROD20
  address-family ipv4 unicast
    route-target export auto      ! Në mënyrë automatike eksporton RT-65001:99000
    route-target import auto

Megjithatë, nëse keni më shumë se një ASN dhe duhet të kaloni rrugët midis tyre, atëherë një opsion më i përshtatshëm dhe i shkallëzuar është konfigurimi manual route-target. Rekomandimi për konfigurimin manual është që numri i parë, ta përdorni një që ju përshtatet, për shembull, 9999.
Numri i dytë duhet të jetë i barabartë me VNI për këtë VRF.

Do ta konfigurojmë si më poshtë:

vrf context PROD10
  address-family ipv4 unicast
    route-target export 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ër

Si duket në tabelën e routing-ut:

Leaf11# sh ip route vrf prod
<.....>
192.168.20.0/24, ubest/mbest: 1/0
    *via 10.255.1.20%default, [200/0], 00:24:45, bgp-65001, internal, tag 65001
(evpn) segid: 99000 tunnelid: 0xaff0114 encap: VXLAN          ! префикс доступен через L3VNI 99000

Tani le të shqyrtojmë opsionin e dytë për routing midis VRF - përmes pajisjeve të jashtme, për shembull, Firewall.

Mund të supozojmë disa variante funksionimi përmes pajisjes së jashtme:

1. Pajisja di se çfarë është VxLAN dhe ne mund ta shtojmë në pjesën e fabrikës;
2. Pajisja nuk di asgjë për VxLAN.

Nuk do të ndalemi në opsionin e parë, sepse logjika do të jetë praktisht e njëjtë me atë të treguar më sipër - e çojmë të gjithë VRF deri te Firewall dhe atje konfigurimi i routing-ut midis VRF.

Le të shqyrtojmë opsionin e dytë, kur Firewall ynë nuk di asgjë për VxLAN (aktualisht, sigurisht, po dalin pajisje që mbështesin VxLAN. Për shembull, Checkpoint e ka njoftuar mbështetje në versionin R81. Mund të lexoni për këtë këtu, por kjo është gjithçka në fazën e testimit dhe nuk ka siguri për stabilitetin e funksionimit).

Me lidhjen e pajisjes së jashtme kemi arritur në skemën e mëposhtme:

Siç shihet nga skema - ka një vend të ngushtë në nyjën me Firewall. Kjo duhet të merret parasysh në vazhdim për planifikimin e rrjetit dhe optimizimin e trafikut të rrjetit.

Megjithatë, le të kthehemi te detyra fillestare e routing-ut midis VRF. Si rezultat i shtimit të Firewall ne arrijmë në përfundimin se Firewall duhet të dijë për të gjithë VRF. Për këtë, të gjithë VRF duhet të jenë gjithashtu të konfiguruar në Leaf-in kufitar, dhe Firewall do të lidhet në çdo VRF me një lidhje të veçantë.

Si rezultat, skema me Firewall:

Pra të thotë, në Firewall duhet të konfigurohet një ndërfaqe për çdo VRF që ndodhet në rrjet. Në thelb, logjika nuk duket shumë e komplikuar dhe e vetmja gjë që mund të ketë dyshim është numri i madh i ndërfaqeve në Firewall, por tani anagji in automatikisht.

Mirë. Kemi lidhur Firewall-in, e kemi shtuar në të gjitha VRF-të. Por si ta bëjmë që trafiku nga çdo Leaf të kalojë përmes këtij Firewall?

Për Leaf-in e lidhur me Firewall-in, nuk do të ketë probleme, pasi të gjitha rrugët janë lokale:

0.0.0.0/0, ubest/mbest: 1/0
    *via 10.254.13.55, [1/0], 6w5d, static       ! rruge e paracaktuar përmes Firewall

Megjithatë, si të veprohet me Leaf-in e largët? Si t'i kalojmë atij rrugën e jashtme të paracaktuar?

Saktë, përmes EVPN route-type 5, ashtu si çdo prefiks tjetër në fabrikën VxLAN. Megjithatë, kjo nuk është aq e thjeshtë (nëse flasim për cisco, nuk kam kontrolluar si është me ofruesit e tjerë)

Duhet të njoftoni rrugën e paracaktuar nga Leaf-i, me të cilin është lidhur Firewall-i. Megjithatë, për ta kaluar rrugën, Leaf-i duhet ta dijë atë vetë. Dhe këtu ndodhin disa probleme (ndoshta vetëm për mua), rruga duhet të shkruhet statikisht në atë VRF ku dëshironi ta njoftoni atë:

vrf context PROD10
    ip route 0.0.0.0/0 10.254.13.55

Më pas në konfigurimin e BGP, përcaktoni këtë rrugë në AF IPv4:

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

Megjithatë, kjo nuk është gjithçka. Kështu, rruga e paracaktuar nuk do të kalojë në familjen l2vpn evpn. Shtesë, duhet të konfigurohet redistreibucioni:

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

Përcaktojmë se cilat prefikse do të kalojnë në BGP përmes redistreibucionit

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

Tani prefiksi 0.0.0.0/0 kalon në EVPN route-type 5 dhe transferohet te Leaf-të e tjerë:

0.0.0.0/0, ubest/mbest: 1/0
    *via 10.255.1.5%default, [200/0], 5w6d, bgp-65001, internal, tag 65001, segid: 99000 tunnelid: 0xaff0105 encap: VXLAN
    ! 10.255.1.5 - Виртуальный адрес Leaf(так как Leaf выступают в качестве VPС пары), к которому подключен Firewall

Në tabelën BGP gjithashtu mund të shohim marzhin e marrë route-type 5 me rrugën e paracaktuar 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 i

Me këtë përfundojmë ciklin e artikujve lidhur me EVPN. Në të ardhmen do të mundohem të shqyrtoj funksionimin e VxLAN në lidhje me Multicast, pasi ky method konsiderohet më i shkallëzueshëm (në këtë moment një pohim controvers)

Nëse keni pyetje ose propozime për të shqyrtuar ndonjë funksionalitet të EVPN - shkruani, do të shqyrtojmë më tej.

Burimi: habr.com