VxLAN verksmiðju. 3. hluti

Halló, Habr. Ég er að klára röð greina, tileinkað setningu námskeiðsins "Netverkfræðingur" eftir OTUS, með því að nota VxLAN EVPN tækni fyrir leiðsögn innan efnisins og nota Firewall til að takmarka aðgang á milli innri þjónustu

Fyrri hluta seríunnar má finna á eftirfarandi hlekkjum:

• 1 hluti af hringrásinni - L2 tenging milli netþjóna
• Hluti 2 í röðinni - Leiðin milli VNIs
• Hluti 2.5 í röðinni - Fræðileg útrás

Í dag munum við halda áfram að rannsaka leiðarrökfræðina inni í VxLAN efninu. Í fyrri hlutanum skoðuðum við leið innan efnis innan eins VRF. Hins vegar getur verið gríðarlegur fjöldi viðskiptavinaþjónustu á netinu og öllum þeirra verður að dreifa í mismunandi VRF til að greina á milli þeirra. Auk netaðskilnaðar gæti fyrirtæki þurft að tengja eldvegg til að takmarka aðgang á milli þessara þjónustu. Já, þetta er ekki hægt að kalla besta lausnin, en nútíma veruleiki krefst „nútímalausna“.

Við skulum íhuga tvo valkosti til að beina milli VRF:

1. Beining án þess að yfirgefa VxLAN efni;
2. Leiðsögn á ytri búnaði.

Við skulum byrja á leiðarrökfræðinni milli VRFs. Það er ákveðinn fjöldi VRF. Til að leiða á milli VRFs þarftu að velja tæki á netinu sem veit um alla VRF (eða hluta sem beina þarf á milli). Slíkt tæki gæti til dæmis verið einn af Leaf rofunum (eða allir í einu). . Þessi staðfræði mun líta svona út:

Hverjir eru ókostirnir við þessa staðfræði?

Það er rétt, hvert Leaf þarf að vita um öll VRF (og allar upplýsingar sem eru í þeim) á netinu, sem leiðir til minnistaps og aukins netálags. Þegar öllu er á botninn hvolft þarf oft hver Leaf rofi ekki að vita um allt sem er á netinu.

Hins vegar skulum við íhuga þessa aðferð nánar, þar sem fyrir lítil net er þessi valkostur mjög hentugur (ef engar sérstakar viðskiptakröfur eru fyrir hendi)

Á þessum tímapunkti gætirðu verið með spurningu um hvernig eigi að flytja upplýsingar frá VRF til VRF, því tilgangurinn með þessari tækni er einmitt sá að miðlun upplýsinga á að takmarka.

Og svarið liggur í aðgerðum eins og útflutningi og innflutningi á leiðarupplýsingum (uppsetning þessarar tækni var talin í annað hluta hringrásarinnar). Leyfðu mér að endurtaka stuttlega:

Þegar VRF er stillt í AF verður þú að tilgreina route-target fyrir inn- og útflutningsleiðarupplýsingar. Þú getur tilgreint það sjálfkrafa. Þá mun gildið innihalda ASN BGP og L3 VNI sem tengjast VRF. Þetta er gagnlegt þegar þú ert með aðeins eitt ASN í verksmiðjunni:

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

Hins vegar, ef þú ert með fleiri en eitt ASN og þarft að flytja leiðir á milli þeirra, þá verður handvirk stilling þægilegri og skalanlegri valkostur route-target. Ráðleggingar um handvirka uppsetningu er fyrsta númerið, notaðu það sem hentar þér, til dæmis, 9999.
Annað ætti að vera stillt til að jafna VNI fyrir það VRF.

Við skulum stilla það sem hér segir:

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

Hvernig það lítur út í leiðartöflunni:

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

Við skulum íhuga seinni möguleikann til að beina milli VRFs - í gegnum ytri búnað, til dæmis Firewall.

Það eru nokkrir möguleikar til að vinna í gegnum ytra tæki:

1. Tækið veit hvað VxLAN er og við getum bætt því við hluta af efninu;
2. Tækið veit ekkert um VxLAN.

Við munum ekki dvelja við fyrsta valmöguleikann, þar sem rökfræðin verður næstum sú sama og sýnt er hér að ofan - við komum öllum VRFs í eldvegginn og stillum leið milli VRFs á honum.

Við skulum íhuga seinni valmöguleikann, þegar eldveggurinn okkar veit ekkert um VxLAN (nú kemur auðvitað búnaður með VxLAN stuðningi. Til dæmis tilkynnti Checkpoint stuðning sinn í útgáfu R81. Þú getur lesið um það hérHins vegar er þetta allt á prófunarstigi og það er ekkert traust á stöðugleika í rekstri).

Þegar ytra tæki er tengt fáum við eftirfarandi skýringarmynd:

Eins og þú sérð á skýringarmyndinni birtist flöskuháls við viðmótið við eldvegginn. Þetta verður að hafa í huga í framtíðinni við skipulagningu netkerfisins og hagræðingu netumferðar.

Hins vegar skulum við snúa aftur að upprunalega vandamálinu við að beina milli VRFs. Sem afleiðing af því að bæta við eldveggnum komumst við að þeirri niðurstöðu að eldveggurinn verður að vita um alla VRF. Til að gera þetta verða öll VRF einnig að vera stillt á landamærablöðunum og eldveggurinn verður að vera tengdur við hvern VRF með sérstökum hlekk.

Fyrir vikið, kerfið með Firewall:

Það er, á eldveggnum þarftu að stilla viðmót við hvert VRF sem er staðsett á netinu. Almennt séð lítur rökfræðin ekki flókin út og það eina sem mér líkar ekki við hér er gríðarlegur fjöldi viðmóta á eldveggnum, en hér er kominn tími til að hugsa um sjálfvirkni.

Fínt. Við tengdum eldvegginn og bættum honum við alla VRF. En hvernig getum við nú þvingað umferð frá hverju blaði til að fara í gegnum þennan eldvegg?

Á Leaf tengt eldveggnum munu engin vandamál koma upp þar sem allar leiðir eru staðbundnar:

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

Hins vegar, hvað með ytri Leafs? Hvernig á að fara framhjá þeim sjálfgefna ytri leið?

Það er rétt, í gegnum EVPN leið-gerð 5, eins og hvert annað forskeyti yfir VxLAN efninu. Hins vegar er þetta ekki svo einfalt (ef við erum að tala um Cisco, þar sem ég hef ekki athugað með öðrum söluaðilum)

Auglýsa þarf sjálfgefna leið úr blaðinu sem eldveggurinn er tengdur við. Hins vegar, til að senda leiðina, verður Leaf að þekkja hana sjálft. Og hér kemur upp ákveðinn vandi (kannski bara fyrir mig), leiðin verður að vera skráð statískt í VRF þar sem þú vilt auglýsa slíka leið:

vrf context PROD10
    ip route 0.0.0.0/0 10.254.13.55

Næst, í BGP stillingunum, stilltu þessa leið í AF IPv4:

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

Það er þó ekki allt. Þannig verður sjálfgefin leið ekki með í fjölskyldunni l2vpn evpn. Í viðbót við þetta þarftu að stilla endurdreifingu:

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

Við tilgreinum hvaða forskeyti munu komast inn í BGP með endurdreifingu

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ú forskeytið 0.0.0.0/0 fellur í EVPN leiðargerð 5 og er send til restarinnar af Leaf:

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 töflunni getum við líka fylgst með leiðargerð 5 sem myndast með sjálfgefna leiðinni um 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

Þetta lýkur röð greina sem helgaðar eru EVPN. Í framtíðinni mun ég reyna að íhuga rekstur VxLAN í tengslum við Multicast, þar sem þessi aðferð er talin skalanlegri (í augnablikinu umdeild yfirlýsing)

Ef þú hefur enn spurningar/tillögur um efnið skaltu íhuga hvaða EVPN virkni sem er - skrifaðu, við munum íhuga það frekar.

Heimild: www.habr.com