ProHoster > Blogs > Administrācija > VxLAN rūpnīca. 3. daļa

VxLAN rūpnīca. 3. daļa

Sveiki, Habr. Es pabeidzu rakstu sēriju, veltīta kursu uzsākšanai "Tīkla inženieris" autors OTUS, izmantojot VxLAN EVPN tehnoloģiju maršrutēšanai audumā un izmantojot ugunsmūri, lai ierobežotu piekļuvi starp iekšējiem pakalpojumiem

VxLAN rūpnīca. 3. daļa

Iepriekšējās sērijas daļas var atrast šajās saitēs:

Šodien mēs turpināsim pētīt maršrutēšanas loģiku VxLAN audumā. Iepriekšējā daļā mēs apskatījām auduma iekšējo maršrutēšanu vienā VRF. Tomēr tīklā var būt ļoti daudz klientu pakalpojumu, un tie visi ir jāsadala dažādos VRF, lai atšķirtu piekļuvi tiem. Papildus tīkla atdalīšanai uzņēmumam, iespējams, būs jāpievieno ugunsmūris, lai ierobežotu piekļuvi starp šiem pakalpojumiem. Jā, to nevar saukt par labāko risinājumu, taču mūsdienu realitātē ir nepieciešami “moderni risinājumi”.

Apsvērsim divas iespējas maršrutēšanai starp VRF:

  1. Maršrutēšana, neatstājot VxLAN audumu;
  2. Maršrutēšana ārējā iekārtā.

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

VxLAN rūpnīca. 3. daļa

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

Tieši tā, katrai lapai ir jāzina par visiem tīklā esošajiem VRF (un visu tajos esošo informāciju), kas izraisa atmiņas zudumu un palielinātu tīkla slodzi. Galu galā diezgan bieži katram Leaf slēdzim nav jāzina par visu, kas ir tīklā.

Tomēr apsvērsim šo metodi sīkāk, jo maziem tīkliem šī opcija ir diezgan piemērota (ja nav īpašu biznesa prasību)

Šajā brīdī jums var rasties jautājums par to, kā pārsūtīt informāciju no VRF uz VRF, jo šīs tehnoloģijas būtība 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šrutēšanas informācijas eksportēšana un importēšana (šīs tehnoloģijas iestatīšana tika apsvērta otrais cikla daļas). Ļaujiet man īsi atkārtot:

Iestatot VRF AF, ir jānorāda route-target importa un eksporta maršruta informācijai. Varat to norādīt automātiski. Tad vērtība ietvers ar VRF saistīto ASN BGP un L3 VNI. Tas ir ērti, ja jūsu rūpnīcā ir tikai viens ASN: 

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

Tomēr, ja jums ir vairāk nekā viens ASN un ir jāpārsūta maršruti starp tiem, manuālā konfigurācija būs ērtāka un mērogojamāka iespēja route-target. Manuālas iestatīšanas ieteikums ir pirmais numurs, izmantojiet to, kas jums ir ērts, piemēram, 9999.
Otrais ir jāiestata tā, lai tas būtu vienāds ar šī VRF VNI.

Konfigurēsim to šādi:

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

Kā tas izskatās maršrutēšanas tabulā:

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

Apsvērsim otro iespēju maršrutēšanai starp VRF - izmantojot ārēju aprīkojumu, piemēram, ugunsmūri.

Ir vairākas iespējas darbam ar ārēju ierīci:

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

Mēs nekavēsimies pie pirmās opcijas, jo loģika būs gandrīz tāda pati, kā parādīts iepriekš - mēs visus VRF ievietojam ugunsmūrī un tajā konfigurējam maršrutēšanu starp VRF.

Apskatīsim otro variantu, kad mūsu Firewall neko nezina par VxLAN (tagad, protams, parādās aprīkojums ar VxLAN atbalstu. Piemēram, Checkpoint paziņoja par atbalstu versijā R81. Par to var palasīt šeittomēr tas viss ir testēšanas stadijā un nav pārliecības par darbības stabilitāti).

Pievienojot ārējo ierīci, mēs iegūstam šādu diagrammu:

VxLAN rūpnīca. 3. daļa

Kā redzams diagrammā, saskarnē ar ugunsmūri parādās sašaurinājums. Tas ir jāņem vērā nākotnē, plānojot tīklu un optimizējot tīkla trafiku.

Tomēr atgriezīsimies pie sākotnējās maršrutēšanas problēmas starp VRF. Ugunsmūra pievienošanas rezultātā mēs nonākam pie secinājuma, ka ugunsmūrim ir jāzina par visiem VRF. Lai to izdarītu, visi VRF ir jākonfigurē arī apmales lapās, un ugunsmūrim ir jābūt savienotam ar katru VRF ar atsevišķu saiti.

Rezultātā shēma ar ugunsmūri:

VxLAN rūpnīca. 3. daļa

Tas nozīmē, ka ugunsmūrī ir jākonfigurē saskarne katram VRF, kas atrodas tīklā. Kopumā loģika nešķiet sarežģīta, un vienīgais, kas man šeit nepatīk, ir milzīgais ugunsmūra saskarņu skaits, taču ir pienācis laiks padomāt par automatizāciju.

Labi. Mēs savienojām ugunsmūri un pievienojām to visiem VRF. Bet kā mēs tagad varam piespiest satiksmi no katras lapas iet caur šo ugunsmūri?

Lapā, kas savienots ar ugunsmūri, problēmas neradīsies, jo visi maršruti ir vietējie:

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

Tomēr kā ir ar attālajām lapām? Kā nodot viņiem noklusējuma ārējo maršrutu?

Tieši tā, izmantojot EVPN maršruta veidu 5, tāpat kā jebkuru citu VxLAN auduma prefiksu. Tomēr tas nav tik vienkārši (ja mēs runājam par Cisco, jo es neesmu pārbaudījis ar citiem pārdevējiem)

Noklusētais maršruts ir jāreklamē no lapas, kurai ir pievienots ugunsmūris. Tomēr, lai pārraidītu maršrutu, Leaf tas jāzina pašam. Un te rodas zināma problēma (varbūt tikai man), maršruts ir jāreģistrē statiski VRF, kur vēlaties reklamēt šādu maršrutu:

vrf context PROD10
    ip route 0.0.0.0/0 10.254.13.55

Pēc tam BGP konfigurācijā iestatiet šo maršrutu AF IPv4:

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

Tomēr tas vēl nav viss. Tādā veidā noklusējuma maršruts netiks iekļauts ģimenē l2vpn evpn. Papildus tam jums ir jākonfigurē pārdalīšana:

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

Mēs norādām, kuri prefiksi nonāks BGP, veicot pārdali

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

Tagad prefikss 0.0.0.0/0 ietilpst EVPN maršruta 5. tipā un tiek pārraidīts uz pārējo 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 tabulā varam novērot arī iegūto maršruta veidu 5 ar noklusējuma maršrutu 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

Ar to noslēdzas EVPN veltītā rakstu sērija. Nākotnē es mēģināšu apsvērt VxLAN darbību kopā ar Multicast, jo šī metode tiek uzskatīta par mērogojamāku (šobrīd strīdīgs paziņojums)

Ja jums joprojām ir jautājumi/ieteikumi par tēmu, apsveriet jebkuru EVPN funkcionalitāti - rakstiet, mēs to izskatīsim tālāk.

VxLAN rūpnīca. 3. daļa

Avots: www.habr.com

Pievieno komentāru