ProHoster > Blogi > Haldamine > VxLAN tehas. 3. osa

VxLAN tehas. 3. osa

Tere, Habr. Lõpetan artiklite sarja, pühendatud kursuse käivitamisele "Võrguinsener" poolt OTUS, kasutades kanga sees marsruutimiseks VxLAN EVPN-tehnoloogiat ja siseteenuste vahelise juurdepääsu piiramiseks tulemüüri

VxLAN tehas. 3. osa

Sarja varasemad osad leiate järgmistelt linkidelt:

Täna jätkame VxLAN-i kanga sees marsruutimisloogika uurimist. Eelmises osas vaatlesime kangasisest marsruutimist ühes VRF-is. Samas võib võrgus olla tohutult palju klienditeenuseid ja need kõik tuleb jaotada erinevatesse VRF-idesse, et nende vahel ligipääsu eristada. Lisaks võrgu eraldamisele võib ettevõttel tekkida vajadus nende teenuste vahelise juurdepääsu piiramiseks ühendada tulemüür. Jah, seda ei saa nimetada parimaks lahenduseks, kuid kaasaegne reaalsus nõuab “kaasaegseid lahendusi”.

Vaatleme kahte võimalust VRF-ide vaheliseks marsruutimiseks:

  1. Marsruutimine VxLAN kangast lahkumata;
  2. Marsruutimine välisseadmetel.

Alustame VRF-ide vahelisest marsruutimisloogikast. VRF-e on teatud arv. VRF-ide vahel marsruutimiseks peate võrgus valima seadme, mis teab kõigist VRF-idest (või osadest, mille vahel on vaja marsruutimist). Selline seade võib olla näiteks üks Leaf-lülititest (või kõik korraga) . See topoloogia näeb välja selline:

VxLAN tehas. 3. osa

Millised on selle topoloogia puudused?

See on õige, iga Leaf peab teadma kõigist võrgus olevatest VRF-idest (ja kogu neis olevast teabest), mis toob kaasa mälukaotuse ja võrgu koormuse suurenemise. Lõppude lõpuks ei pea iga Leafi lüliti üsna sageli teadma kõike, mis võrgus on.

Mõelgem siiski sellele meetodile üksikasjalikumalt, kuna väikeste võrkude jaoks on see valik üsna sobiv (kui konkreetseid ärinõudeid pole)

Siinkohal võib tekkida küsimus, kuidas infot VRF-ist VRF-i üle kanda, sest selle tehnoloogia mõte on just selles, et info levitamist tuleks piirata.

Ja vastus peitub sellistes funktsioonides nagu marsruutimisteabe eksport ja import (selle tehnoloogia seadistamist kaaluti teine tsükli osad). Lubage mul lühidalt korrata:

VRF-i määramisel AF-is peate täpsustama route-target impordi ja ekspordi marsruudi teabe jaoks. Saate selle automaatselt määrata. Seejärel sisaldab väärtus VRF-iga seotud ASN BGP-d ja L3 VNI-d. See on mugav, kui teie tehases on ainult üks ASN: 

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

Kui teil on aga rohkem kui üks ASN ja teil on vaja marsruute nende vahel üle kanda, on käsitsi seadistamine mugavam ja skaleeritavam valik route-target. Käsitsi seadistamise soovitus on esimene number, kasutage seda, mis on teile mugav, näiteks 9999.
Teine peaks olema võrdne selle VRF-i VNI-ga.

Seadistame selle järgmiselt:

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

Kuidas see marsruutimistabelis välja näeb:

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

Vaatleme teist võimalust VRF-ide vaheliseks marsruutimiseks - väliste seadmete, näiteks tulemüüri kaudu.

Välise seadme kaudu töötamiseks on mitu võimalust:

  1. Seade teab, mis on VxLAN ja me saame selle kangale lisada;
  2. Seade ei tea VxLANist midagi.

Esimesel valikul me ei peatu, kuna loogika on peaaegu sama, mis ülalpool näidatud - toome kõik VRF-id tulemüüri ja konfigureerime sellel VRF-ide vahelise marsruutimise.

Vaatleme teist varianti, kui meie tulemüür ei tea VxLAN-ist midagi (nüüd ilmuvad muidugi VxLAN-i toega seadmed. Näiteks Checkpoint teatas oma toetusest versioonis R81. Selle kohta saate lugeda siinKuid see kõik on testimise staadiumis ja töö stabiilsuses puudub kindlus).

Välise seadme ühendamisel saame järgmise diagrammi:

VxLAN tehas. 3. osa

Nagu diagrammil näha, ilmub tulemüüri liidesesse kitsaskoht. Seda tuleb edaspidi võrgu planeerimisel ja võrguliikluse optimeerimisel arvestada.

Pöördugem siiski tagasi VRF-ide vahelise marsruutimise algse probleemi juurde. Tulemüüri lisamise tulemusena jõuame järeldusele, et tulemüür peab teadma kõigist VRF-idest. Selleks peavad kõik VRF-id olema seadistatud ka äärislehtedel ning Firewall peab olema ühendatud iga VRF-iga eraldi lingiga.

Selle tulemusena on tulemüüriga skeem:

VxLAN tehas. 3. osa

See tähendab, et tulemüüris peate konfigureerima liidese iga võrgus asuva VRF-i jaoks. Üldiselt ei tundu loogika keeruline ja ainus asi, mis mulle siin ei meeldi, on tulemüüri liideste tohutu arv, kuid siin on aeg mõelda automatiseerimisele.

Hästi. Ühendasime tulemüüri ja lisasime selle kõigile VRF-idele. Aga kuidas me saame nüüd sundida liiklust igast lehest läbi selle tulemüüri?

Tulemüüriga ühendatud Leafi puhul probleeme ei teki, kuna kõik marsruudid on kohalikud:

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

Kuidas on aga kaugete lehtedega? Kuidas edastada neile vaikimisi välist marsruuti?

See on õige, EVPN-i marsruudi tüüp 5 kaudu, nagu mis tahes muu VxLAN-kanga eesliide. Kuid see pole nii lihtne (kui me räägime Ciscost, kuna ma pole teiste müüjatega kontrollinud)

Vaikemarsruuti tuleb reklaamida sellelt Leafilt, millega tulemüür on ühendatud. Marsruudi edastamiseks peab Leaf seda aga ise teadma. Ja siin tekib teatud probleem (võib-olla ainult minu jaoks), marsruut peab olema staatiliselt registreeritud VRF-is, kus soovite sellist marsruuti reklaamida:

vrf context PROD10
    ip route 0.0.0.0/0 10.254.13.55

Järgmisena määrake BGP konfiguratsioonis AF IPv4-s see marsruut:

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

See pole aga veel kõik. Nii ei kaasata vaikemarsruuti perekonda l2vpn evpn. Lisaks peate konfigureerima ümberjaotamise:

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

Näitame, millised prefiksid saavad ümberjaotamise kaudu BGP-sse

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 eesliide 0.0.0.0/0 kuulub EVPN-i marsruuditüüpi 5 ja edastatakse ülejäänud Leafile:

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 tabelis saame jälgida ka saadud marsruuditüüpi 5 vaikemarsruudiga 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

Sellega on EVPN-ile pühendatud artiklite seeria lõpetatud. Tulevikus proovin kaaluda VxLAN-i toimimist koos Multicastiga, kuna seda meetodit peetakse skaleeritavamaks (praegu vastuoluline väide)

Kui teil on teemal veel küsimusi/ettepanekuid, kaaluge EVPN-i mis tahes funktsionaalsust – kirjutage, me kaalume seda edasi.

VxLAN tehas. 3. osa

Allikas: www.habr.com

Lisa kommentaar