🥇VxLAN fabrika. 3. zatia

Kaixo, Habr. Artikulu sorta bat bukatzen ari naiz, ikastaroaren hasierari eskainia "Sare ingeniaria" OTUSetik, VxLAN EVPN teknologia erabiliz ehunaren barruan bideratzeko eta Firewall erabiliz barne zerbitzuen arteko sarbidea mugatzeko

Seriearen aurreko atalak honako esteka hauetan aurki daitezke:

Gaur VxLAN ehunaren barruan bideratze-logika aztertzen jarraituko dugu. Aurreko zatian, ehunen barneko bideratzea VRF bakar baten barruan aztertu genuen. Hala ere, sarean bezero-zerbitzu ugari egon daitezke, eta horiek guztiak VRF ezberdinetan banatu behar dira haien artean sarbidea bereizteko. Sarea bereizteaz gain, baliteke negozio batek Firewall bat konektatu behar izatea zerbitzu horien arteko sarbidea mugatzeko. Bai, horri ezin zaio irtenbiderik onena deitu, baina errealitate modernoek “irtenbide modernoak” eskatzen dituzte.

Azter ditzagun bi aukera VRFen artean bideratzeko:

Bideratzea VxLAN ehunetik irten gabe;
Kanpoko ekipoetan bideratzea.

Has gaitezen VRFen arteko bideratze-logikan. VRF kopuru jakin bat dago. VRFen artean bideratzeko, sarean VRF guztiak ezagutuko dituen gailu bat aukeratu behar duzu (edo bideraketa behar duten zatiak). Gailu hori izan daiteke, adibidez, Leaf etengailuetako bat (edo guztiak aldi berean). . Topologia honek itxura hau izango du:

Zeintzuk dira topologia honen desabantailak?

Hori bai, Leaf bakoitzak sareko VRF guztiak (eta horietan dagoen informazio guztia) ezagutu behar ditu, eta horrek memoria galtzea eta sarearen karga areagotzea dakar. Azken finean, sarritan Leaf etengailu bakoitzak ez du sarean dagoen guztia ezagutu beharrik.

Hala ere, aztertu dezagun metodo hau zehatzago, sare txikietarako aukera hau nahiko egokia baita (negozio-baldintza zehatzik ez badago)

Une honetan, baliteke VRF-tik VRF-ra informazioa nola transferitzeari buruzko galdera bat edukitzea, teknologia honen helburua, hain zuzen, informazioaren hedapena mugatu behar izatea delako.

Eta erantzuna bideratze-informazioaren esportazioa eta inportazioa bezalako funtzioetan dago (teknologia hau konfiguratzea kontuan hartu zen bigarren zikloaren zatiak). Errepikatu dezadan laburki:

VRF AF-n ezartzean, zehaztu behar duzu route-target inportatzeko eta esportatzeko bideratze-informazioa egiteko. Automatikoki zehaztu dezakezu. Ondoren, balioak VRFarekin lotutako ASN BGP eta L3 VNI sartuko ditu. Hau komenigarria da zure fabrikan ASN bakarra duzunean:

vrf context PROD20
  address-family ipv4 unicast
    route-target export auto      ! В автоматическом режиме экспортируется RT-65001:99000
    route-target import auto

Hala ere, ASN bat baino gehiago badituzu eta haien artean ibilbideak transferitu behar badituzu, eskuzko konfigurazioa aukera erosoagoa eta eskalagarriagoa izango da. route-target. Eskuzko konfiguraziorako gomendioa lehen zenbakia da, erabili zuretzat komeni zaizun bat, adibidez, 9999.
Bigarrena VRF horretarako VNI berdina izan behar da.

Konfigura dezagun honela:

vrf context PROD10
  address-family ipv4 unicast
    route-target export 9999:99000          
    route-target import 9999:99000
    route-target import 9999:77000         ! Пример 1 import из другого VRF
    route-target import 9999:88000         ! Пример 2 import из другого VRF

Bideratze-taulan nolakoa den:

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

Kontuan izan dezagun VRFen arteko bideraketa egiteko bigarren aukera - kanpoko ekipoen bidez, adibidez Firewall.

Kanpoko gailu baten bidez lan egiteko hainbat aukera daude:

Gailuak badaki zer den VxLAN eta ehunaren zati batean gehi dezakegu;
Gailuak ez daki ezer VxLANi buruz.

Ez dugu lehen aukeran geldituko, logika goian erakusten den ia bera izango baita - VRF guztiak Suebakira eramaten ditugu eta bertan VRFen arteko bideratzea konfiguratzen dugu.

Azter dezagun bigarren aukera, gure Firewall-ak VxLAN-i buruz ezer ez dakienean (orain, noski, VxLAN euskarria duten ekipoak agertzen ari dira. Adibidez, Checkpoint-ek bere laguntza iragarri zuen R81 bertsioan. Horri buruz irakur dezakezu. Hemen, hala ere, hau guztia proba fasean dago eta ez dago funtzionamenduaren egonkortasunean konfiantzarik).

Kanpoko gailu bat konektatzean, diagrama hau lortuko dugu:

Diagraman ikus dezakezun bezala, Firewall-eko interfazean botila-lepo bat agertzen da. Hori kontuan izan behar da etorkizunean sarea planifikatzerakoan eta sareko trafikoa optimizatzerakoan.

Hala ere, itzul gaitezen VRFen arteko bideratzearen jatorrizko arazora. Firewall gehitzearen ondorioz, Suebakiak VRF guztiak ezagutu behar dituela ondorioztatu dugu. Horretarako, VRF guztiak Leafs-en mugan ere konfiguratu behar dira, eta Firewall-a VRF bakoitzari lotura bereizi batekin konektatu behar da.

Ondorioz, Firewall-ekin eskema:

Hau da, Firewall-en sarean kokatutako VRF bakoitzerako interfaze bat konfiguratu behar duzu. Orokorrean, logikak ez du itxura konplikatua eta hemen gustatzen ez zaidan gauza bakarra Firewall-eko interfaze kopuru handia da, baina hemen automatizazioan pentsatzeko garaia da.

Ederki. Firewall-a konektatu dugu eta VRF guztietara gehitu dugu. Baina nola behartu dezakegu orain Leaf bakoitzeko trafikoa Firewall honetatik pasatzera?

Leaf suebakira konektatuta, ez da arazorik sortuko, ibilbide guztiak tokikoak baitira:

0.0.0.0/0, ubest/mbest: 1/0
    *via 10.254.13.55, [1/0], 6w5d, static       ! маршрут по-умолчанию через Firewall

Hala ere, zer gertatzen da urruneko Leafs-ekin? Nola pasatu kanpoko bide lehenetsia?

Hori bai, EVPN ibilbide mota 5 bidez, VxLAN ehunaren gaineko beste edozein aurrizki bezala. Hala ere, hau ez da hain erraza (Cisco-ri buruz ari bagara, ez baitut beste saltzaile batzuekin egiaztatu)

Ibilbide lehenetsia Firewall konektatuta dagoen Leafetik iragarri behar da. Hala ere, ibilbidea transmititzeko, Leafek berak ezagutu behar du. Eta hemen arazo jakin bat sortzen da (agian niretzat bakarrik), ibilbidea modu estatikoan erregistratu behar da ibilbide hori iragartzeko nahi duzun VRFan:

vrf context PROD10
    ip route 0.0.0.0/0 10.254.13.55

Ondoren, BGP konfigurazioan, ezarri ibilbide hau AF IPv4-n:

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

Hala ere, hori ez da guztia. Horrela lehenetsitako ibilbidea ez da familian sartuko l2vpn evpn. Honetaz gain, birbanaketa konfiguratu behar duzu:

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

Birbanaketaren bidez BGPra zein aurrizki sartuko diren adierazten dugu

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

Orain aurrizkia 0.0.0.0/0 EVPN 5. ibilbide motan sartzen da eta Leaf-en gainerakoetara transmititzen da:

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

BGP taulan 5 bidezko ibilbide lehenetsiarekin lortutako 10.255.1.5. ibilbide mota ere ikus dezakegu:

* 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

Honela amaitzen da EVPNri eskainitako artikulu sorta. Etorkizunean, Multicast-ekin batera VxLAN-en funtzionamendua aztertzen saiatuko naiz, metodo hau eskalagarriagoa denez (momentuz adierazpen polemikoa da)

Oraindik gaiari buruzko galdera/iradokizunak badituzu, kontuan hartu EVPNren edozein funtzionalitate - idatzi, gehiago aztertuko dugu.

Iturria: www.habr.com

VxLAN fabrika. 3. zatia

Gehitu iruzkin berria Idatzi