Oznaka po VRF-u ili po prefiksu? Pravi račun kapaciteta

Dva dizajna oglašavaju isti korisnički prefiks kroz isto provajdersko jezgro. Jedan dodjeljuje oznaku po prefiksu, drugi dodjeljuje jednu oznaku za cijeli VRF, a drugi na svakom slajdu izgleda jeftinije. Broj oznaka je stvaran, ali to obično nije budžet koji prvi ponestane. Odluka između njih znači brojanje četiri resursa, a ne jednog, a oznake su najmanji od njih.

Izbor takođe zavisi od toga šta izlazni ruter mora da uradi s paketom nakon što skine oznaku. Odluku treba da vodi ta funkcionalna razlika, a ne aritmetika oznaka.

Šta svaka dodjela zapravo štedi

Dodjela po prefiksu nosi informaciju o prosljeđivanju u oznaci. Izlazni ruter može poslati paket pravo na ispravno susjedstvo bez pretrage odredišta, zato se dobro skalira za velike skupove ruta u VRF-u i zato troši jednu oznaku za svaki oglašeni prefiks u svakom VRF-u. Dodjela po VRF-u, kao Junos vrf-table-label, oglašava jednu oznaku po instanci rutiranja i koristi tu oznaku za izbor tabele VRF-a; ruter zatim obavlja IP pretragu unutar tabele.

To je stvarna arhitektonska razlika, a ne dugme za podešavanje. Označavanje po VRF-u daje manji prostor oznaka i jednostavnije oglašavanje, po cijeni jedne pretrage i oznake koja ništa ne govori o odredištu. Označavanje po prefiksu daje izlaznoj linijskoj kartici više informacija unaprijed i košta oznake srazmjerno rutama koje nosite.

Knjiga oznaka je ona manja

MPLS oznake su konačne, ali prostor oznaka je dovoljno velik da ga obični provajderi usluga ne iscrpe s nekoliko hiljada prefiksa. Označavanje po VRF-u zaista pomaže na platformama s malim hardverskim tabelama oznaka ili u dizajnima u kojima jedan VRF nosi pun internet feed i oznake po prefiksu umnožavaju potražnju za oznakama brojem ruta. To su stvarna ograničenja i ona su razlog zašto funkcija postoji. Nijedno se ne tiče broja prefiksa u tabeli.

Izbrojte oznake i za uslugu i za transport prije nego što izaberete. Dizajn po VRF-u još uvijek treba transportne oznake za loopback adrese i za svaki hop na putu, i još uvijek treba stanje susjedstva. Ako projektni zadatak broji samo servisne oznake, ušteda se mjeri na pogrešnoj knjizi.

Feedovi ruta troše memoriju prije oznaka

Svaka primljena ruta troši memoriju kontrolne ravni, obradu ažuriranja i vrijeme konvergencije, bez obzira na to koristi li VRF jednu oznaku ili deset hiljada. Pun internet feed unutar VRF-a je skup zbog BGP ruta, RIB-a, FIB unosa i promjena iza njih, a ne zbog oznake koja stoji ispred tabele. Isti feed podiže i obim štete od curenja ruta ili greške u politici unutar tog zakupca.

Zato pitajte šta korisnik zaista zahtijeva. Ako je ugovor privatne lokacije plus podrazumijevani izlaz, puna tabela dodaje trošak bez dodavanja zahtjeva. To je komercijalno pitanje i zaslužuje pisani odgovor, a ne pretpostavku naslijeđenu iz prethodnog dizajna. Ako usluzi feed zaista treba za politiku ili za izbor lokalnog izlaza, napravite od toga izričitu stavku s vlastitom rezervacijom kapaciteta i vlastitim ponašanjem pri kvaru.

Kada je označavanje po VRF-u pravi podrazumijevani izbor

To je dobar podrazumijevani izbor kada ga platforma dokumentuje kao podržano, kada je broj ruta u VRF-u velik i kada je cijena izlazne pretrage prihvatljiva za profil saobraćaja. To je i prirodno rješenje kada je operativna jednostavnost važnija od istiskivanja posljednje mikrosekunde iz prosljeđivanja, jer je jednu oznaku po zakupcu lakše objasniti i revidirati od oznake po prefiksu.

To je pogrešan podrazumijevani izbor kada dokumentacija platforme veže funkciju za konkretan hardver ili ograničenja izdanja, ili kada dizajn zavisi od odluka o prosljeđivanju po prefiksu na izlazu. Pročitajte vlastiti referentni dokument platforme o tvrdnji prije nego što pretpostavite ponašanje; Junos komanda je dokumentovana, ali upravo hardverski i izdavački limiti oko nje odlučuju o postavljanju.

Budžet koji možete odbraniti

Izgradite slučaj kapaciteta kao pet odvojenih brojeva: primljene rute, odabrane rute, instalirani unosi prosljeđivanja, servisne oznake i transportne oznake. Dodajte stanje sljedećeg skoka i susjedstva, broj zakupaca i model redundantnosti. Snimak sretne staze jednog VRF-a nije brojka za skalu, a nominalna veličina prostora oznaka nije dostupna hardverska tabela.

Zatim se dogovorite i o načinu kvara, kao i o stabilnom stanju. Šta se dešava kada feed poraste za pola, kada zakupac doda drugi VRF ili kada platforma treba restart da bi promijenila veličinu tabele? Budžet koji izdrži ta pitanja vrijedi više od broja oznaka koji radi samo na papiru.

Izaberite dodjelu prema izlaznoj radnji i ograničenjima platforme, a zatim pretvorite feed ruta u izričitu servisnu odluku. Oznaka je vidljivi dio dizajna; rute su dio koji se mora plaćati svakog dana.