🥇VxLAN fabrik. Osa 3

Tere, Habr. Lõpetan artiklite seeriat, mis keskenduvad kursuse käivitamisele "Võrgutehnik" OTUSelt, kasutades VxLAN EVPN tehnoloogiat marsruutimise jaoks tehases ja tulemüüride kasutamist sisehaldusteenuste vahelise juurdepääsu piiramiseks.

Eelnevad osad seeriast leiate linkidelt:

Täna jätkame VxLAN tehase marsruutimise loogika uurimist. Eelmises osas vaatasime marsruutimist ühes VRF-is. Siiski võib võrgus olla tohutult palju teenuseid-klienditeenuseid, mida tuleb jaotada erinevatesse VRF-idesse, et piirata juurdepääsu nende vahel. Lisaks võrgupiirangule võib ettevõttel olla vajadus ühendamiseks tulemüür, et piirata juurdepääsu nende teenuste vahel. Jah, seda ei saa nimetada parimaks lahenduseks, kuid kaasaegsed reaalsused nõuavad „kaasaegseid lahendusi“.

Vaadake kahe VRF-i vahelise marsruudistuse varianti:

Marsruuditus, ilma VxLAN tehast lahkumata;
Marsruuditus välisseadmetel.

Alustame VRF-ide vahemaa juhtimise loogikast. On kindel arv VRF-e. VRF-ide vahelise suunamise korral on vajalik määrata seadmed võrgus, mis tunneksid kõiki VRF-e (või osade vahel, kus on vajalik suunamine). Selliseks seadmiseks võib näiteks olla üks Leaf lülititest (või kõik korraga). Selle topoloogia välimus oleks järgmine:

Millised on selle topoloogia puudused?

Tõsi, iga Leaf peab teadma kõigist VRF-idest (ja kogu teabest, mis nendes on) võrgus, mis viib mälu kaotamiseni ja suurendab koormust võrgus. Lõppude lõpuks ei pea iga Leaf lülitit sageli teadma kogu võrgus olevast infost.

Siiski vaatame seda meetodit lähemalt, kuna väikeste võrkude jaoks sobib see variant päris hästi (kui ei ole mingeid spetsiifilisi ärinõudeid).

Selles etapis võib teil tekkida küsimus, kuidas edastada teavet VRF-ist VRF-i, sest selle tehnoloogia mõte on just selles, et teabe levikut tuleb piirata.

Ja vastus peitub sellistes funktsioonides nagu marsruutimise teabe eksport ja import (selle tehnoloogia seadistust arutati teine tsükli osas). Lühidalt korrates:

VRF määramisel AF-is tuleb märkida route-target marsruuditeabe importimiseks ja eksportimiseks. Selle määramine on võimalik automaatrežiimis. Siis sisestatakse väärtuseks ASN BGP ja L3 VNI, mis on seotud VRF-iga. See on mugav, kui teie tehases kasutatakse ainult ühte ASN:

vrf context PROD20
  address-family ipv4 unicast
    route-target export auto      ! Automaatrežiimis eksporditakse RT-65001:99000
    route-target import auto

Kuid kui teil on rohkem kui üks ASN ja on vajalik marsruutide edastamine nende vahel, siis on mugavam ja skaleeritavam variandiks manuaalne seadistamine route-target. Manuaalse seadistuse soovitus — esimene number, kasutage teile sobivat, näiteks 9999.
Teine peaks olema sama, mis VNI selle VRF-i jaoks.

Seadistame järgmiselt:

vrf context PROD10
  address-family ipv4 unicast
    route-target export 9999:99000          
    route-target import 9999:99000
    route-target import 9999:77000         ! Näide 1 import teisest VRF-ist
    route-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 ! prefix available through L3VNI 99000

Vaatame teist marsruutimisvarianti VRF vahel - läbi välise seadme, näiteks tulemüüri.

Võime eeldada mitmeid tööviise läbi välisseadmest:

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

Esimese variandi kallale ei jää, kuna loogika on praktiliselt sama nagu eespool näidatud - viime kõik VRF-id tulemüüri ja seadistame seal marsruutimise VRF-ide vahel.

Vaatame teist varianti, kui meie tulemüür ei tea VxLAN-ist midagi (jah, praegu tuleb turule seadmeid, mis toetavad VxLAN-i. Näiteks on Checkpoint kuulutanud selle toe R81 versioonis. Selle kohta saab lugeda siin, kuid kõik see on praegu testimise etapis ja töö stabiilsuse osas ei saa olla kindel).

Kui ühendame välise seadme, saame järgmise skeemi:

Nagu skeemist näha - tekib kitsaskoht tulemüüriga ühenduse kohas. Seda tuleb arvesse võtta edasises võrgukavandamises ja võrgu liikluse optimeerimisel.

Kuid naaseme algse VRF-i marsruutimise ülesande juurde. Firewalli lisamise tõttu peame tagama, et Firewall teaks kõikide VRF-ide kohta. Selleks peavad kõik VRF-id olema konfigureeritud ka piiriäärsetes Leaf-seadmetes, ning Firewall tuleb iga VRF-i jaoks ühendada eraldi lingiga.

Seega on Firewalli skeem järgmine:

See tähendab, et Firewallil on vaja seadistada liides igas VRF-is, mis asub võrgus. Üldiselt pole loogika keeruline ja ainus asi, mis võib häirida, on Firewalli arvukad liidesed, kuid sel juhul peaksime mõtlema automaatikale.

Hästi. Oleme Firewalli ühendatud ja lisanud selle kõikidesse VRF-idesse. Kuidas sundida nüüd igas Leafis liiklust selle Firewalli kaudu liikuma?

Firewalliga ühendatud Leaf-is ei teki probleeme, kuna kõik marsruudid on lokaalsed:

0.0.0.0/0, ubest/mbest: 1/0
    *via 10.254.13.55, [1/0], 6w5d, static       ! vaike marsruut Firewalli kaudu

Kuid kuidas on asjadega kaugel olevate Leaf-idega? Kuidas edastada neile väline vaike marsruut?

Õige, EVPN route-type 5 kaudu, nagu iga teine prefix VxLAN-i tehases. Kuid sellega pole kõik nii lihtne (kui räägime Cisco'ist, muude tootjate puhul ei ole ma kontrollinud).

Vaikimisi peab marsruuti kuulutama Leafis, mis on ühendatud Firewalliga. Kuid marsruudi edastamiseks peab Leaf ise selle teadma. Siin tekib teatav probleem (võib-olla ainult minul), marsruut tuleb määrata staatiliselt selles VRF-is, kus soovite sellist marsruuti kuulutada:

vrf context PROD10
    ip route 0.0.0.0/0 10.254.13.55

Seejärel tuleb BGP seadistamisel määrata see marsruut AF IPv4-s:

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

Kuid see ei ole veel kõik. Seega ei jõua vaikimisi marsruut peresse l2vpn evpn. Lisaks sellele tuleb seadistada redistributsioon:

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

Määrame, millised täpselt prefiksid jõuavad BGP kaudu redistributsiooni

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

Nüüd prefiks 0.0.0.0/0 jõuab EVPN route-type 5 ja edastatakse teistele Leafidele:

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), millele Firewalle on ühendatud

BGP tabelis näeme samuti saadud route-type 5 vaike marsruudiga 10.255.1.5 kaudu:

* 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

Käesolevaga lõpetame EVPN-i pühendatud artiklite seeria. Edasi püüan uurida VxLANi tööd Multicastiga koos, kuna seda meetodit peetakse hetkel ulatuslikumaks (kuigi see on vaieldav väide).

Kui teil on mingeid küsimusi / ettepanekuid EVPNi funktsionaalsuse arutamiseks — kirjutage, vaatame lisaks.

Allikas: habr.com

VxLAN tehas. Osa 3