🥇VxLAN fabrika. 3. daļa

Sveiki, Habr. Noslēdzu rakstu ciklu, kas veltīts kursa uzsākšanai "Tīkla inženieris" no OTUS, izmantojot VxLAN EVPN tehnoloģiju maršrutēšanā iekšējā fabrikā un ugunsmura izmantošanu piekļuves ierobežošanai starp iekšējiem pakalpojumiem.

Iepriekšējās cikla daļas var atrast, izmantojot šo saiti:

Šodien turpināsim pētīt maršrutēšanas loģiku VxLAN fabrikā. Iepriekšējā daļā mēs apskatījām maršrutēšanu fabrikā viena VRF ietvaros. Tomēr tīklā var būt milzīgs skaits klientu pakalpojumu, un visus ir jāizvieto dažādās VRF, lai ierobežotu piekļuvi starp tiem. Papildus tīkla ierobežošanai uzņēmumam var būt nepieciešamība pieslēgt ugunsmuru, lai ierobežotu piekļuvi starp šiem pakalpojumiem. Jā, to nevar uzskatīt par labāko risinājumu, taču mūsdienu realitāte prasa "mūsdienīgus risinājumus".

Apskatīsim divus maršrutēšanas variantus starp VRF:

Maršrutēšana, neiznākot no VxLAN fabrikas;
Maršrutēšana uz ārējiem aprīkojumiem.

Sāksim ar VRF maršrutēšanas loģiku. Ir noteikts skaits VRF. Lai maršrutētu starp VRF, ir nepieciešams izdalīt ierīci tīklā, kas zinās par visiem VRF (vai vismaz daļu, starp kuriem nepieciešama maršrutēšana). Šāda ierīce var būt, piemēram, viens no Leaf slēdžiem (vai visi vienlaikus). Šāda topoloģija izskatīsies šādi:

Kādi ir šīs topoloģijas trūkumi?

Pareizi, katram Leaf jāzina par visiem VRF (un visu informāciju, kas tajos ir), kas noved pie atmiņas zuduma un paaugstina slodzi uz tīklu. Galu galā, diezgan bieži katram Leaf slēdzim nevajag zināt par visu, kas ir tīklā.

Tomēr apskatīsim šo paņēmienu sīkāk, jo mazām tīkla struktūrām šis variants ir pilnīgi piemērots (ja nav kādu specifisku uzņēmuma prasību).

Šajā momentā jums var rasties jautājums, kā nodot informāciju no VRF uz VRF, jo šīs tehnoloģijas jēga ir tieši tāda, ka informācijas izplatīšana ir jāierobežo.

Un atbilde slēpjas tādās funkcijās kā maršrutu informācijas eksportēšana un importēšana (šīs tehnoloģijas konfigurāciju apskatījām otrais iepriekšējā cikla daļā). Īsāk sakot,

Iestatot VRF AF, nepieciešams norādīt route-target maršruta informācijas importēšanai un eksportēšanai. To var norādīt automātiskajā režīmā. Tādā gadījumā tiks iekļauta ASN BGP un L3 VNI, kas piesaistīts VRF. Tas ir ērti, ja jūsu fabrikā tiek izmantota tikai viena ASN:

vrf konteksts PROD20
  adreses ģimene ipv4 unicast
    maršruta mērķis eksportam auto      ! Automātiskajā režīmā tiek eksportēts RT-65001:99000
    maršruta mērķis importam auto

Tomēr, ja jums ir vairāk nekā viena ASN un ir nepieciešams nodot maršrutus starp tām, tad ērtāka un mērogotāka iespēja būs manuālā iestatīšana route-target. Ieteikums manuālajā iestatīšanā — pirmo skaitli izvēlieties sev ērtu, piemēram, 9999.
Otram jābūt vienādam ar VNI šim VRF.

Iestatīsim šādi:

vrf konteksts PROD10
  adreses ģimene ipv4 unicast
    maršruta mērķis eksportam 9999:99000          
    maršruta mērķis importam 9999:99000
    maršruta mērķis importam 9999:77000         ! Piemērs 1 importam no cita VRF
    maršruta mērķis importam 9999:88000         ! Piemērs 2 importam no cita VRF

Kā tas izskatās maršrutu tabulā:

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 ! prefikss pieejams caur L3VNI 99000

Apskatīsim otro maršrutēšanas variantu starp VRF — caur ārējām ierīcēm, piemēram, ugunsmūri.

Var pieņemt vairākas iespējas darbam caur ārēju ierīci:

Ierīce zina, kas ir VxLAN, un mēs varam to pievienot fabrikas daļai;
Ierīce neko nezina par VxLAN.

Pirmajam variantam paliksim pie tā, ka loģika būs gandrīz tāda pati kā iepriekš — vedam visus VRF līdz ugunsmūrim un tur iestatām maršrutēšanu starp VRF.

Apskatīsim otro variantu, kad mūsu ugunsmūris neko nezina par VxLAN (šobrīd, protams, parādās iekārtas ar atbalstu VxLAN. Piemēram, Checkpoint ir paziņojusi par tās atbalstu versijā R81. Par to var izlasīt šeit, tomēr tas viss ir testēšanas posmā un nav pārliecības par stabilitāti).

Savienojot ārējo ierīci, mums iznāk šāda shēma:

Kā redzams shēmā — parādās šaura vieta pie muguras ar ugunsmūri. To nepieciešams ņemt vērā turpmākajā tīkla plānošanā un tīkla datu plūsmas optimizācijā.

Tomēr atgriezīsimies pie sākotnējā uzdevuma maršrutēšanas starp VRF. Pēc ugunsmūra pievienošanas mēs nonākam pie secinājuma, ka ugunsmūrim jāzina par visiem VRF. Lai to izdarītu, uz robežas esošajiem Leaf arī jābūt iestatītiem visiem VRF, un ugunsmūri savienojam katrā VRF, izmantojot atsevišķu līniju.

Tādējādi shēma ar ugunsmūri:

Tas nozīmē, ka ugunsmūrī nepieciešams iestatīt interfeisu katram VRF, kas atrodas tīklā. Kopumā loģika izskatās vienkārša, un vienīgais, kas var nepatikt, ir milzīgais interfeisu skaits uz ugunsmūra, bet šeit ir laiks domāt par automatizāciju.

Labi. Pievienojām ugunsmūri, pievienojām to visiem VRF. Bet kā tagad panākt, lai satiksme no katra Leaf dotos caur šo ugunsmūri?

Uz Leaf, kas pieslēgts ugunsmūrim, nekādus traucējumus neradīs, jo visi maršruti ir lokāli:

0.0.0.0/0, ubest/mbest: 1/0
    *via 10.254.13.55, [1/0], 6w5d, statiskais       ! maršruts pēc noklusējuma caur ugunsmūri

Tomēr kā rīkoties ar attālinātiem Leaf? Kā nodot tiem ārējo maršrutu pēc noklusējuma?

Pareizi, caur EVPN route-type 5, kā jebkuru citu prefiksu VxLAN fabrikā. Tomēr ar to viss nav tik vienkārši (ja runājam par Cisco, citus ražotājus neesmu pārbaudījis)

Maršrutu pēc noklusējuma nepieciešams paziņot no Leaf, kuram pieslēgts ugunsmūris. Tomēr, lai nodotu maršrutu, Leaf tam pašam jāzina. Un šeit rodas neliela problēma (iespējams, tikai man), maršruts jāieraksta statiski tajā VRF, kurā vēlaties paziņot šādu maršrutu:

vrf konteksts PROD10
    ip maršruts 0.0.0.0/0 10.254.13.55

Tālāk BGP konfigurācijā jānorāda šis maršruts AF IPv4:

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

Tomēr tas nav viss. Tādējādi maršruts pēc noklusējuma nenonāks ģimenē l2vpn evpn. Papildus tam nepieciešams iestatīt redistribūciju:

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

Norādām, kuri tieši prefiksi nonāks BGP caur redistribūciju

route-map COMMON_OUT permit 10
  match ip address prefix-list COMMON_OUT

ip prefix-list COMMON_OUT sec 10 atļaut 0.0.0.0/0

Tagad prefiks 0.0.0.0/0 nonāk EVPN route-type 5 un tiek nodots citiem Leaf:

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 - Virtuālais adrese Leaf(jo Leaf darbojas kā VPС pāra), pie kura ir pieslēgts Firewall

BGP tabulā arī varam novērot saņemto route-type 5 ar maršrutu pēc noklusējuma caur 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

Noslēdzam rakstu ciklu par EVPN. Nākotnē mēģināšu apskatīt VxLAN darbību kopā ar Multicast, jo šāda pieeja tiek uzskatīta par skalējamāku (šobrīd apstrīdēts apgalvojums).

Ja jums ir jautājumi/piedāvājumi par EVPN funkcionalitātes apskati — rakstiet, mēs to izskatīsim papildus.

Avots: habr.com