Címke VRF-enként vagy előtagként? Az igazi kapacitásszámla

Két terv hirdeti ugyanazt az ügyfél-előtagot ugyanabban a szolgáltatói magban. Az egyik előtagonként oszt ki címkét, a másik egyetlen címkét oszt ki az egész VRF-hez, és a második minden dián olcsóbbnak tűnik. A címkék száma valós, de nem ez a költségvetés, amely általában először elfogy. A kettő közötti választás négy erőforrás megszámlálását jelenti, nem egyét, és ezek közül a címkék a legkisebbek.

A választás attól is függ, mit kell a kilépő útválasztónak tennie a csomaggal, miután leveszi a címkét. Ezt a funkcionális különbséget kell a döntésnek vezérelnie, nem a címke-aritmetikát.

Mit takarít meg valójában az egyes kiosztás

Az előtagonkénti kiosztás a továbbítási információt a címkében hordozza. A kilépő útválasztó célkeresés nélkül küldheti a csomagot közvetlenül a megfelelő szomszédságra, ezért skálázódik jól nagy VRF-útvonalhalmazokhoz, és ezért fogyaszt egy címkét minden hirdetett előtaghoz minden VRF-ben. A VRF-enkénti kiosztás, például a Junos vrf-table-label, egy címkét hirdet útválasztási példányonként, és ezt a címkét használja a VRF-tábla kiválasztására; az útválasztó ezután IP-keresést végez a táblán belül.

Ez valódi architekturális különbség, nem hangoló gomb. A VRF-enkénti címkézés kisebb címketartományt és egyszerűbb címkehirdetést ad, egyetlen keresés és egy olyan címke árán, amely semmit sem mond a célról. Az előtagonkénti címkézés több információt ad a kilépő vonalkártyának előre, és a hordozott útvonalak arányában költ címkéket.

A címkenyilvántartás a kicsi

Az MPLS-címkék végesek, de a címketartomány elég nagy ahhoz, hogy a hétköznapi szolgáltatók néhány ezer előtaggal ne merítsék ki. A VRF-enkénti címkézés valóban kis hardveres címtáblákkal rendelkező platformokon segít, vagy olyan tervekben, ahol egyetlen VRF teljes internetes hírcsatornát hordoz, és az előtagonkénti címkék az útvonalak számával szoroznák a címkeigényt. Ezek valódi korlátok, és ezért létezik a funkció. Egyik sem a táblában lévő előtagok számáról szól.

A választás előtt számolja meg a címkéket a szolgáltatáshoz és a szállításhoz is. A VRF-enkénti tervnek továbbra is szüksége van szállítási címkékre a loopbackekhez és az útvonal minden ugrásához, és továbbra is szüksége van szomszédsági állapotra. Ha a tervezési összefoglaló csak a szolgáltatási címkéket számolja, a megtakarítást rossz nyilvántartáson mérik.

Az útvonalhírcsatornák a címkék előtt memóriába kerülnek

Minden fogadott útvonal vezérsík-memóriát, frissítésfeldolgozást és konvergenciaidőt fogyaszt, akár egy címkét használ a VRF, akár tízezret. A VRF-en belüli teljes internetes hírcsatorna a BGP-útvonalak, a RIB, a FIB-bejegyzések és a mögöttük lévő mozgás miatt drága, nem a tábla előtti címke miatt. Ugyanez a hírcsatorna növeli az útvonalszivárgás vagy a szabályzati hiba hatókörét is azon a bérlőn belül.

Kérdezze meg tehát, mire van valóban szüksége az ügyfélnek. Ha a szerződés privát telephelyek plusz alapértelmezett kijárat, a teljes tábla költséget ad hozzá követelmény nélkül. Ez kereskedelmi kérdés, és írásos választ érdemel, nem az előző tervből örökölt feltételezést. Ha a szolgáltatásnak valóban kell a hírcsatorna szabályzat vagy helyi kijáratválasztás miatt, tegye azt kifejezett tétellé saját kapacitásfoglalással és saját hibaeset-viselkedéssel.

Mikor a VRF-enkénti címkézés a helyes alapértelmezés

Akkor jó alapértelmezés, ha a platform támogatottként dokumentálja, ha a VRF-útvonalak száma nagy, és ha a kilépő keresés költsége elfogadható a forgalmi profilhoz. Akkor is természetes választás, ha az üzemeltetési egyszerűség fontosabb, mint az utolsó mikroszekundum kicsikarása a továbbításból, mert egy címke bérlőnként könnyebben elmagyarázható és auditálható, mint egy címke előtagonként.

Akkor rossz alapértelmezés, ha a platform dokumentációja a funkciót meghatározott hardver- vagy kiadási korlátokhoz köti, vagy ha a terv a kilépésnél előtagonkénti továbbítási döntésektől függ. Olvassa el a platform saját statement-hivatkozását, mielőtt feltételezi a viselkedést; a Junos-parancs dokumentált, de a körülötte lévő hardver- és kiadási korlátok döntik el valójában a bevezetést.

Költségvetés, amelyet meg tud védeni

Öt külön számmal építse fel a kapacitásigazolást: fogadott útvonalak, kiválasztott útvonalak, telepített továbbítási bejegyzések, szolgáltatási címkék és szállítási címkék. Adja hozzá a next-hop és szomszédsági állapotot, a bérlők számát és a redundanciamodellt. Egyetlen VRF boldog útvonalának pillanatképe nem méretarányos adat, és egy névleges címketartomány-méret nem rendelkezésre álló hardvertábla.

Ezután a hibaesetben is állapodjon meg, nem csak az állandó állapotban. Mi történik, ha a hírcsatorna másfélszeresére nő, ha egy bérlő második VRF-et ad hozzá, vagy ha a platformnak újraindításra van szüksége a tábla átméretezéséhez? Az a költségvetés, amely kiállja ezeket a kérdéseket, többet ér egy olyan címkeszámnál, amely csak papíron működik.

A kilépési művelet és a platformkorlátok alapján válassza ki a kiosztást, majd tegye az útvonalhírcsatornát kifejezett szolgáltatási döntéssé. A címke a terv látható része; az útvonalak az a rész, amelyért minden nap fizetni kell.