EVPN ugunsmūra politika: centralizēta vārteja un sadalītais IRB

Divi EVPN risinājumi novieto nomnieka vārteju dažādās vietās, un ugunsmūris katrā redz atšķirīgu datplūsmu. Ar centralizētu vārteju datplūsma starp apakštīkliem nonāk ugunsmūrī, jo tieši tur notiek maršrutēšana. Ar sadalīto IRB leaf komutatori maršrutē lokāli, un ugunsmūris neko neredz, ja vien jūs to tur neievietojat apzināti. Neviens modelis nav nepareizs. Nepareizi ir pievienot ugunsmūri pie robežas un pieņemt, ka fabric nogādās tam datplūsmu.

Divi modeļi, divi atšķirīgi pārbaudes punkti

Vispirms nosauciet plūsmas, kurām nepieciešama pārbaude, jo abi modeļi tās apstrādā atšķirīgi.

Datplūsma vienā apakštīklā ir rinda, ko cilvēki aizmirst. Divi resursdatori vienā VLAN sazinās caur tiltu, un šajā ceļā nav maršrutējoša ugunsmūra, ja vien to nepārtver atsevišķs 2. slāņa pārbaudes risinājums. Tas attiecas uz abiem modeļiem, tāpēc tā ir projektēšanas nepilnība, nevis to salīdzinājums.

Pārējās trīs rindas ir vieta, kur modeļi patiešām atšķiras.

Centralizēta vārteja: vienkārša pārbaude, reālas tranzīta izmaksas

Saglabājiet nomnieka VLAN kā 2. slāņa pakalpojumus un novietojiet to maršrutēšanas vārtejas uz ugunsmūra. Datplūsma starp apakštīkliem tad dodas uz šo vārteju un atpakaļ, iespējams, pat tad, kad abi resursdatori atrodas uz viena leaf. Pārbaudes punkts ir viennozīmīgs, un tas ir viss šī risinājuma arguments. Izmaksas ir tranzīta slodze uz ugunsmūra plus centrāla atkarība no jaudas un pieejamības, kas tagad jāprojektē.

Ierobežojiet izmaiņas ar paredzētajām nomnieka vārtējām. Noņemt katru VLAN adresi ir pārāk plaši, ja pārvaldībai, underlay un platformas saskarnēm ir atsevišķi uzdevumi. Pārbaudiet arī otru aktīvo vārteju, jo tā, kas joprojām maršrutē ap ugunsmūri, klusi iznīcina risinājumu.

Šo modeli ir vieglāk izskaidrot auditoram. Tas nav automātiski lētāks ekspluatācijā.

Sadalītais IRB: ātrais ceļš, pēc noklusējuma bez pārbaudes

Ar sadalītām anycast vārtējām katrs leaf maršrutē nomnieka datplūsmu lokāli, un RFC 9135 apraksta, kāpēc tas izvairās no atgriešanas caur centralizētu vārteju. Ieguvums ir reāls, un tam ir tiešas sekas: pārbaudi nevar secināt no tā, kur ugunsmūris ir pievienots. Ugunsmūris, kas pievienots robežas leaf, redz ārējo datplūsmu un visu, ko tam skaidri novirzāt.

Ievietojiet pakalpojumu ar mehānismu, ko platforma patiešām atbalsta: uz politiku balstītu novirzīšanu, pakalpojuma mezglu vai kontrolētu maršrutēšanu starp VRF caur ugunsmūri. Saskaņojiet paredzēto datplūsmu tās faktiskajā ieejas punktā. Politika, kas rakstīta uz resursdatoriem vērstā saskarnē, neaptver paketi, kas nāk no overlay.

Lasiet instalētos maršrutus, nevis paredzēto noklusējumu. Konkrētāks nomnieka prefikss, kas importēts tieši, var apiet noklusēto maršrutu, kas norāda uz ugunsmūri, un konfigurācijā nekas neizskatīsies nepareizi.

Simetrija ir maršrutēšanas īpašība, nevis pārbaudes garantija

Simetriskais IRB apraksta, kā ienākošie un izejošie provider edge mezgli apstrādā plūsmas maršrutēšanu un tiltu. Tas neko nepasaka par to, vai abi virzieni sasniedz vienu un to pašu stāvokļa ierīci. ECMP, anycast un augsta ugunsmūra pieejamība visi ietekmē to, kurš mezgls redz atgriešanās datplūsmu, un klastera atbalstītais stāvokļa modelis izlemj, vai tas ir pieņemami.

Skaidri sekojiet atgriešanās ceļam katrai plūsmai, kas jums svarīga. NAT nav universāls šī darba aizstājējs, un risinājumi, kas uz to paļaujas, parasti atrod nepilnību failover laikā, nevis būvniecības laikā.

Pirms apstiprināt risinājumu, izstaigājiet vienu obligātu un vienu apzināti izslēgtu plūsmu abos virzienos.

Kā izvēlēties un ko pārbaudīt jebkurā gadījumā

Izvēlieties centralizēto vārteju, kad pārbaudes pārklājums ir svarīgāks par tranzīta jaudu un varat atļauties centrālo atkarību. Izvēlieties sadalīto IRB, kad lokālā maršrutēšana ir galvenais, un budžetā paredziet skaidru pakalpojuma ievietošanu, nevis pieņemiet to.

Pēc tam pārbaudiet maršrutēšanu, ko patiešām instalējāt, jo tieši tur abi risinājumi atšķiras visvairāk:

show ip route vrf TENANT 10.20.0.0/16
show bgp l2vpn evpn route-type prefix

Iekļaujiet testā pakalpojuma mezgla kļūmi un atjaunošanos. Rezerves maršruts, kas klusi apiet pārbaudi, ir citāds lēmums nekā plānota fail-open politika, un parasti ir paredzēts tikai viens no tiem. Pabeigtais risinājums nosauc, kur maršrutējas katra datplūsmas klase, kur tā tiek pārbaudīta un kas notiek, kad šis pārbaudes ceļš nav pieejams.