🥇VxLAN tehas. Osa 3

Tere, Habr. Lõpetan artiklite tsüklit, mis käsitlevad kursuse käivitamist "Võrgutehnik" OTUSelt, VxLAN EVPN tehnoloogia raames, mille eesmärk on marsruutimine tehase sees ja tulemüüri kasutamine juurdepääsu piiramiseks siseteenuste vahel.

Tsükli eelmised osad leiate linkidelt:

Täna jätkame VxLAN tehase siseste marsruutimise loogika uurimist. Eelmises osas käsitlesime marsruutimist tehase sees ühe VRF raames. Siiski võib ressursside sagedusena teenuseid ja kliente olla tohutult ning neid tuleb jaotada erinevatesse VRF-idesse, et piirata juurdepääsu nende vahel. Lisaks võtab äri vajadusel kasutusele tulemüüri, et piirata juurdepääsu nende teenuste vahel. Jah, seda ei saa nimetada parimaks lahenduseks, kuid kaasaegsetes tingimustes on „kaasaegsed lahendused” vajalikud.

Vaatame kahte marsruutimise varianti VRF-ide vahel:

Marsruutimine, jäädes VxLAN tehase piiridesse;
Marsruutimine välistes seadmetes.

Alustame VRF-ide vahelise marsruutimise loogikaga. On olemas kindel arv VRF-e. Et marsruutida VRF-ide vahel, on vaja võrgus seadet, mis teab kõikidest VRF-idest (või osa neist, mille vahel on vajalik marsruutimine). Selliseks seadmesse võib olla näiteks üks Leaf lülititest (või kõik korraga). Sellise topoloogia välimus on järgmine:

Millised on sellise topoloogia puudused?

Õige, iga Leaf peab teadma kõigist VRF-idest (ja kogu teabest, mis nende sees on) võrgus, mis viib mälu kahanemise ja koormuse suurenemiseni võrgus. Lõppude lõpuks ei pea iga Leaf lülit ära tundma kõike, mis on võrgus.

Kuid vaatame seda lähemalt, kuna väikeste võrkude puhul sobib see võimalus hästi (kui pole mingeid spetsiifilisi ärinõudeid).

Sellel hetkel võib teil tekkida küsimus, kuidas edastada teavet VRF-ide vahel, kuna selle tehnoloogia mõte on just see, et teabe levikut tuleks piirata.

Ja vastus on sellistes funktsioonides nagu marsruutimise teabe eksport ja import (selle tehnoloogia seadistust käsitleti teises tsükli osas). Lühidalt kordame:

VRF-i määramisel AF-is tuleb näidata marsruudi sihtmärki importi ja eksporti marsruudi informatsiooni jaoks. Seda saab määrata automaatrežiimis. Siis jõuab väärtuseni ASN BGP ja L3 VNI, mis on seotud VRF-iga. See on mugav, kui tehas kasutab ainult ühte ASN-i:

vrf kontekst PROD20
  aadressiperiood ipv4 unicast
    marsruudiv target export auto      ! Automaatrežiimis eksporditakse RT-65001:99000
    marsruudiv target import auto

Kuid kui teil on rohkem kui üks ASN ja on vaja marsruute nende vahel edastada, siis on mugavam ja skaleeritavam valik käsitsi seadistamine marsruudi sihtmärki. Käsitsi seadistamise soovitus — esimene number, kasutage endale mugavat, näiteks: 9999.
Teine tuleks seada VNI-ks sellele VRF-ile.

Seadistame järgmiselt:

vrf kontekst PROD10
  aadressiperiood ipv4 unicast
    marsruudiv target export 9999:99000          
    marsruudiv target import 9999:99000
    marsruudiv target import 9999:77000         ! Näide 1 import teisest VRF-ist
    marsruudiv target import 9999:88000         ! Näide 2 import teisest VRF-ist

Kuidas see välja näeb marsruuditabelis:

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 ! prefiks on kättesaadav L3VNI 99000 kaudu

Vaadakem teist varianti marsrutimiseks VRF-ide vahel — läbi välise seadme, näiteks tulemüüri.

Saame eeldada mitmeid töövõimalusi läbi välise seadme:

Seade teab, mis on VxLAN ja me saame selle lisada tehase ossa;
Seade ei tea midagi VxLAN-ist.

Esimese variandi juures ei peatuda, kuna loogika oleks praktiliselt sama nagu ülaltoodud — viime kõik VRF-id tulemüüri juurde ja seadistame seal marsrutimise VRF-ide vahel.

Vaadakem teist varianti, kui meie tulemüür ei tea midagi VxLAN-ist (praegu ilmub muidugi seadmeid, mis toetavad VxLAN-i. Näiteks on Checkpoint kuulutanud selle toe versioonis R81. Selle kohta saab lugeda, siit, kuid see on kõik veel testimise staadiumis ja ei ole kindlust Töö stabiilsuses).

Välist seadme ühendamisel tuleb meil järgmine skeem:

Nagu skeemist näha, tekib kitsaskoht tulemüüriga ühenduses. Seda tuleb arvesse võtta edasistes võrgu planeerimisel ja võrgu liikluse optimeerimisel.

Kuid naaseme algse VRF-ide vahelise marsruutimise ülesande juurde. Tulemüüri lisamise tulemusena jõuame järeldusele, et tulemüür peab teadma kõigist VRF-idest. Selleks peaksid ka piiri-Leaf-id olema seadistatud kõik VRF-id, ning tulemüür peaks olema ühendatud igasse VRF-i eraldi lingiga.

Firewall'i skeem on järgmine:

See tähendab, et Firewall'is tuleb seadistada iga VRFi jaoks eraldi liides, mis asub võrgus. Üldiselt näeb loogika üsna lihtne välja ja ainus asi, mis siin võib veidi häirida, on tohutu hulk liideseid Firewall'is, kuid nüüd on aeg automateerimisele mõelda.

Hästi. Firewall on ühendatud, lisatud kõikidesse VRFidesse. Kuid kuidas nüüd veenda iga Leaf'i liikuma läbi selle Firewall'i?

Firewall'iga ühendatud Leaf'il ei teki probleeme, kuna kõik marsruudid on kohalikud:

0.0.0.0/0, ubest/mbest: 1/0
    *via 10.254.13.55, [1/0], 6w5d, staatiline       ! vaikimisi marsruut läbi Firewall'i

Kuid kuidas on remote Leaf'idega? Kuidas edastada neile välist vaikimisi marsruuti?

Õige, EVPN route-type 5 kaudu, nagu iga muu eelloot pealist VxLAN tehases. Siiski, see pole nii lihtne (kui räägime cisco'st, teiste tootjate kohta ei ole kontrollinud).

Marsruut, mille kaudu edastatakse vaikimisi marsruut, tuleb kuulutada Leaf'i kaudu, mis on ühendatud Firewall'iga. Siiski, et marsruuti edastada, peab Leaf selle ise teadma. Siin tekib teatud probleem (võib-olla ainult minul), marsruut tuleb määrata staatiliselt sellesse VRF'i, kus soovite selle marsruudi kuulutada:

vrf kontekst PROD10
    ip marsruut 0.0.0.0/0 10.254.13.55

Seejärel BGP seadistuses määrake see marsruut IPv4 AF'is:

router bgp 65001
    vrf prod
        aadressipere ipv4 unicast
            võrk 0.0.0.0/0

Kuid see pole veel kõik. Seega ei satu vaikimisi marsruut perekonda l2vpn evpn. Lisaks sellele tuleb seadistada ümberjaotamine:

router bgp 65001
    vrf prod
        aadressipere ipv4 unicast
            võrk 0.0.0.0/0
            redistribuuti staatiline marsruut-kaart COMMON_OUT

Määrame, millised eellood koos BGP-de läbi ümberjaotuse pääsevad

marsruut-kaart COMMON_OUT luba 10
  match ip address prefix-list COMMON_OUT

ip prefix-list COMMON_OUT seq 10 luba 0.0.0.0/0

Nüüd eelloode 0.0.0.0/0 sattub EVPN route-type 5 ja edastatakse teistele Leaf'idele:

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 - Virtuaalne aadress Leaf (kuna Leaf toimivad VPС paarina), millega on ühendatud tulemüür

BGP tabelis saame samuti jälgida saadud route-type 5 koos vaikimisi marsruudiga läbi 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

Selle lõpetame EVPN-ile pühendatud artiklite seeria. Edaspidi püüan arutada VxLAN-i toimimist Multicastiga, kuna see lähenemine loetakse praegu skaleeritavamaks (kuigi see on vaieldav väide).

Kui teil on küsimusi/ettepanekuid EVPN-i funktsionaalsuse arutamiseks, kirjutage meile, arutame neid lisaks.

Allikas: habr.com

VxLAN fabric. Part 3