Etiketë për çdo VRF apo për çdo prefiks? Fatura reale e kapacitetit

Dy dizajne njoftojnë të njëjtin prefiks klienti në të njëjtën bërthamë të ofruesit. Njëri cakton një etiketë për çdo prefiks, tjetri cakton një etiketë të vetme për të gjithë VRF-në, dhe i dyti duket më i lirë në çdo sllajd. Numri i etiketave është real, por nuk është buxheti që zakonisht mbaron i pari. Të zgjedhësh mes tyre do të thotë të numërosh katër burime, jo një, dhe etiketat janë më të voglat prej tyre.

Zgjedhja varet edhe nga ajo që ruteri i daljes duhet të bëjë me paketën pasi të heqë etiketën. Është ai ndryshim funksional, jo aritmetika e etiketave, që duhet të udhëheqë vendimin.

Çfarë kursen në të vërtetë çdo caktim

Një caktim për prefiks mbart informacionin e përcjelljes në etiketë. Ruteri i daljes mund ta dërgojë paketën drejt e në fqinjësinë e duhur pa një kërkim destinacioni, prandaj shkallëzohet mirë për grupe të mëdha rutash VRF dhe prandaj konsumon një etiketë për çdo prefiks të njoftuar në çdo VRF. Një caktim për VRF, si Junos vrf-table-label, njofton një etiketë për çdo instancë rutimi dhe e përdor atë etiketë për të zgjedhur tabelën VRF; më pas ruteri kryen një kërkim IP brenda tabelës.

Ky është një ndryshim i vërtetë arkitekturor dhe jo një çelës akordimi. Etiketimi për VRF jep një hapësirë etiketash më të vogël dhe një njoftim etiketash më të thjeshtë, me koston e një kërkimi dhe të një etikete që nuk thotë asgjë për destinacionin. Etiketimi për prefiks i jep kartës së linjës së daljes më shumë informacion paraprak dhe kushton etiketa në përpjesëtim me rrugët që transporton.

Regjistri i etiketave është ai i vogël

Etiketat MPLS janë të fundme, por hapësira e etiketave është mjaft e madhe që ofruesit e zakonshëm të shërbimit të mos e shterojnë me disa mijëra prefikse. Aty ku etiketimi për VRF ndihmon vërtet është në platforma me tabela të vogla etiketash harduerike, ose në dizajne ku një VRF i vetëm mbart një ushqim të plotë interneti dhe etiketat për prefiks do ta shumëfishonin kërkesën për etiketa me numrin e rrugëve. Këto janë kufizime reale, dhe ato janë arsyeja pse ekziston ky funksion. Asnjë prej tyre nuk ka të bëjë me numrin e prefikseve në tabelë.

Numëro etiketat për shërbimin dhe për transportin përpara se të zgjedhësh. Një dizajn për VRF ende ka nevojë për etiketa transporti për loopback-ët dhe për çdo hop në rrugë, dhe ende ka nevojë për gjendjen e fqinjësisë. Nëse përmbledhja e dizajnit numëron vetëm etiketat e shërbimit, kursimi matet në regjistrin e gabuar.

Ushqimet e rrugëve kushtojnë memorie përpara etiketave

Çdo shteg i marrë konsumon memorie të planit të kontrollit, përpunim përditësimesh dhe kohë konvergjence, pavarësisht nëse VRF-i përdor një etiketë apo dhjetë mijë. Një ushqim i plotë interneti brenda një VRF është i kushtueshëm për shkak të shtigjeve BGP, RIB-it, hyrjeve FIB dhe trazimit pas tyre, jo për shkak të etiketës përpara tabelës. I njëjti ushqim rrit edhe rrezen e ndikimit të një rrjedhjeje rrugësh ose të një gabimi politike brenda atij qiramarrësi.

Prandaj pyet çfarë kërkon vërtet klienti. Nëse kontrata është faqe private plus një dalje të paracaktuar, një tabelë e plotë shton kosto pa shtuar një kërkesë. Është një pyetje komerciale, dhe meriton një përgjigje me shkrim në vend të një supozimi të trashëguar nga dizajni i mëparshëm. Nëse shërbimi ka vërtet nevojë për ushqimin për politikë ose për zgjedhjen e daljes lokale, bëje atë një zë të qartë me rezervimin e vet të kapacitetit dhe sjelljen e vet në rast dështimi.

Kur etiketimi për VRF është parazgjedhja e saktë

Është një parazgjedhje e mirë kur platforma e dokumenton si të mbështetur, kur numri i rrugëve VRF është i madh dhe kur kostoja e kërkimit në dalje është e pranueshme për profilin e trafikut. Është gjithashtu zgjedhja e natyrshme kur thjeshtësia operative ka më shumë rëndësi sesa nxjerrja e mikrosekondës së fundit nga përcjellja, sepse një etiketë për qiramarrës është më e lehtë për t'u shpjeguar dhe audituar sesa një etiketë për prefiks.

Është parazgjedhja e gabuar kur dokumentacioni i platformës e lidh funksionin me kufizime specifike harduerike ose versioni, ose kur dizajni varet nga vendime përcjelljeje për prefiks në dalje. Lexo referencën e vetë platformës për statement përpara se të supozosh sjelljen; komanda Junos është e dokumentuar, por janë kufijtë harduerikë dhe të versionit rreth saj ata që vendosin në të vërtetë vendosjen.

Një buxhet që mund ta mbrosh

Ndërto çështjen e kapacitetit si pesë numra të veçantë: shtigje të marra, rrugë të zgjedhura, hyrje përcjelljeje të instaluara, etiketa shërbimi dhe etiketa transporti. Shto gjendjen e next-hop dhe të fqinjësisë, numrin e qiramarrësve dhe modelin e tepricës. Një fotografi e shtegut të lumtur të një VRF të vetëm nuk është shifër shkalle, dhe një madhësi nominale e hapësirës së etiketave nuk është tabelë harduerike e disponueshme.

Më pas bi në ujdi edhe për modalitetin e dështimit, jo vetëm për gjendjen e qëndrueshme. Çfarë ndodh kur ushqimi rritet përgjysmë, kur një qiramarrës shton një VRF të dytë ose kur platforma ka nevojë për një rindezje për të ndryshuar madhësinë e një tabele? Një buxhet që u bën ballë këtyre pyetjeve vlen më shumë se një numërim etiketash që funksionon vetëm në letër.

Zgjidh caktimin nga veprimi në dalje dhe kufijtë e platformës, pastaj bëje ushqimin e rrugëve një vendim shërbimi të qartë. Etiketa është pjesa e dukshme e dizajnit; rrugët janë pjesa për të cilën duhet paguar çdo ditë.