Label na VRF, nebo na prefix? Skutečný účet kapacity

Dva návrhy inzerují stejný zákaznický prefix přes stejné jádro poskytovatele. Jeden přiděluje label na prefix, druhý přiděluje jediný label pro celý VRF, a ten druhý vypadá na každém slidu levněji. Počet labelů je reálný, ale obvykle to není rozpočet, který dojde první. Rozhodnutí mezi nimi znamená počítat čtyři zdroje, ne jeden, a labely jsou nejmenší z nich.

Volba také závisí na tom, co musí výstupní router udělat s paketem poté, co label odebere. Rozhodnutí by měla řídit tato funkční odlišnost, ne aritmetika labelů.

Co každé přidělení skutečně ušetří

Přidělení na prefix nese v labelu informaci o předávání. Výstupní router může poslat paket přímo do správného sousedství bez vyhledání cíle, proto se dobře škáluje pro velké sady tras ve VRF a proto spotřebuje jeden label za každý inzerovaný prefix v každém VRF. Přidělení na VRF, například Junos vrf-table-label, inzeruje jeden label na instanci směrování a používá tento label k výběru tabulky VRF; router pak provede vyhledání IP uvnitř tabulky.

To je skutečný architektonický rozdíl, ne nastavovací knoflík. Labelování na VRF dává menší prostor labelů a jednodušší inzerci, za cenu jednoho vyhledání a labelu, který o cíli nic neříká. Labelování na prefix dává výstupní lince více informací předem a stojí labely úměrně trasám, které nesete.

Účet labelů je ten menší

Labely MPLS jsou konečné, ale prostor labelů je dost velký na to, aby ho běžní poskytovatelé nevyčerpali několika tisíci prefixy. Labelování na VRF skutečně pomáhá na platformách s malými hardwarovými tabulkami labelů nebo v návrzích, kde jeden VRF nese plný internetový feed a labely na prefix násobí poptávku po labelech počtem tras. To jsou reálná omezení a právě kvůli nim funkce existuje. Žádné z nich se netýká počtu prefixů v tabulce.

Před volbou spočítejte labely pro službu i transport. Návrh na VRF stále potřebuje transportní labely pro loopbacky a pro každý hop na cestě a stále potřebuje stav sousedství. Pokud zadání počítá jen servisní labely, úspora se měří na špatném účtu.

Feedy tras stojí paměť dřív než labely

Každá přijatá cesta spotřebovává paměť řídicí roviny, zpracování aktualizací a čas konvergence, ať VRF používá jeden label nebo deset tisíc. Plný internetový feed uvnitř VRF je drahý kvůli trasám BGP, RIB, položkám FIB a změnám za nimi, ne kvůli labelu, který stojí před tabulkou. Stejný feed také zvyšuje rozsah škod při úniku tras nebo chybě politiky uvnitř tohoto zákazníka.

Proto se ptejte, co zákazník skutečně potřebuje. Pokud je smlouva o privátních lokalitách plus výchozím výstupu, plná tabulka přidává náklady, aniž by přidala požadavek. To je obchodní otázka a zaslouží si písemnou odpověď, ne předpoklad zděděný z předchozího návrhu. Pokud služba feed opravdu potřebuje pro politiku nebo pro výběr lokálního výstupu, udělejte z toho výslovnou položku s vlastní rezervací kapacity a vlastním chováním při selhání.

Kdy je labelování na VRF správný výchozí stav

Je to dobrý výchozí stav, když platforma tuto funkci dokumentuje jako podporovanou, když je počet tras ve VRF velký a když je cena výstupního vyhledávání pro daný profil provozu přijatelná. Je to také přirozená volba, když je provozní jednoduchost důležitější než vymačkat z předávání poslední mikrosekundu, protože jeden label na zákazníka se vysvětluje a audituje snáz než label na prefix.

Je to špatný výchozí stav, když dokumentace platformy váže funkci na konkrétní hardware nebo omezení verze, nebo když návrh závisí na rozhodování o předávání podle prefixu na výstupu. Přečtěte si vlastní referenci platformy k tvrzení, než budete chování předpokládat; příkaz Junos je zdokumentovaný, ale o nasazení rozhodují právě hardwarové a verzové limity kolem něj.

Rozpočet, který obhájíte

Postavte případ kapacity jako pět samostatných čísel: přijaté cesty, vybrané trasy, nainstalované položky předávání, servisní labely a transportní labely. Přidejte stav dalšího skoku a sousedství, počet zákazníků a model redundance. Snímek šťastné cesty jednoho VRF není číslo pro škálu a nominální velikost prostoru labelů není dostupná hardwarová tabulka.

Potom se dohodněte na režimu selhání i na ustáleném stavu. Co se stane, když feed vzroste o polovinu, když zákazník přidá druhý VRF nebo když platforma potřebuje restart kvůli změně velikosti tabulky? Rozpočet, který tyto otázky přežije, má větší cenu než počet labelů, který funguje jen na papíře.

Vyberte přidělení podle akce na výstupu a limitů platformy, a pak udělejte z feedu tras výslovné servisní rozhodnutí. Label je viditelná část návrhu; trasy jsou část, za kterou se platí každý den.