Etykieta na VRF czy na prefiks? Prawdziwy rachunek pojemności
Jedna etykieta na VRF wygląda taniej niż jedna na prefiks, ale liczba etykiet to najmniejsza pozycja w budżecie. Oto co naprawdę kończy się pierwsze.
Dwa projekty reklamują ten sam prefiks klienta w tym samym rdzeniu dostawcy. Jeden przydziela etykietę na prefiks, drugi przydziela jedną etykietę dla całego VRF, a drugi wygląda taniej na każdym slajdzie. Liczba etykiet jest realna, ale to nie jest budżet, który zwykle kończy się pierwszy. Wybór między nimi oznacza liczenie czterech zasobów, a nie jednego, i etykiety są najmniejszym z nich.
Wybór zależy też od tego, co router wyjściowy musi zrobić z pakietem po zdjęciu etykiety. To różnica funkcjonalna, a nie arytmetyka etykiet, powinna kierować decyzją.
Co naprawdę oszczędza każdy przydział
Przydział na prefiks przenosi informację o przekazywaniu w etykiecie. Router wyjściowy może wysłać pakiet prosto do właściwego sąsiedztwa bez wyszukiwania celu, dlatego dobrze skaluje się dla dużych zbiorów tras VRF i dlatego zużywa jedną etykietę na każdy reklamowany prefiks w każdym VRF. Przydział na VRF, taki jak Junos vrf-table-label, reklamuje jedną etykietę na instancję routingu i używa tej etykiety do wyboru tabeli VRF; następnie router wykonuje wyszukiwanie IP w tabeli.
To prawdziwa różnica architektoniczna, a nie pokrętło strojenia. Etykietowanie na VRF daje mniejszą przestrzeń etykiet i prostszą reklamę etykiet, kosztem jednego wyszukiwania i etykiety, która nic nie mówi o celu. Etykietowanie na prefiks daje karcie liniowej wyjścia więcej informacji z góry i kosztuje etykiety proporcjonalnie do przenoszonych tras.
Księga etykiet jest ta mała
Etykiety MPLS są skończone, ale przestrzeń etykiet jest dość duża, by zwykli dostawcy usług nie wyczerpali jej kilkoma tysiącami prefiksów. Tam, gdzie etykietowanie na VRF naprawdę pomaga, są platformy z małymi sprzętowymi tablicami etykiet albo projekty, w których jeden VRF przenosi pełny kanał internetowy, a etykiety na prefiks pomnożyłyby zapotrzebowanie na etykiety przez liczbę tras. To realne ograniczenia i one są powodem istnienia tej funkcji. Żadne z nich nie dotyczy liczby prefiksów w tabeli.
Policz etykiety zarówno dla usługi, jak i dla transportu, zanim wybierzesz. Projekt na VRF nadal potrzebuje etykiet transportowych dla loopbacków i dla każdego przeskoku na ścieżce, i nadal potrzebuje stanu sąsiedztwa. Jeśli brief projektowy liczy tylko etykiety usługi, oszczędność jest mierzona w niewłaściwej księdze.
Kanały tras kosztują pamięć przed etykietami
Każda odebrana ścieżka zużywa pamięć płaszczyzny sterowania, przetwarzanie aktualizacji i czas zbieżności, niezależnie od tego, czy VRF używa jednej etykiety, czy dziesięciu tysięcy. Pełny kanał internetowy wewnątrz VRF jest drogi z powodu ścieżek BGP, RIB, wpisów FIB i zamieszania za nimi, a nie z powodu etykiety przed tabelą. Ten sam kanał zwiększa też promień wpływu wycieku tras lub błędu polityki wewnątrz tego dzierżawcy.
Zapytaj więc, czego klient naprawdę wymaga. Jeśli umowa obejmuje prywatne lokalizacje plus domyślne wyjście, pełna tabela dodaje koszt bez dodawania wymagania. To pytanie handlowe i zasługuje na pisemną odpowiedź, a nie na założenie odziedziczone z poprzedniego projektu. Jeśli usługa naprawdę potrzebuje kanału dla polityki lub lokalnego wyboru wyjścia, zrób z tego jawną pozycję z własną rezerwacją pojemności i własnym zachowaniem przy awarii.
Kiedy etykietowanie na VRF jest właściwym ustawieniem domyślnym
To dobre ustawienie domyślne, gdy platforma dokumentuje ją jako obsługiwaną, gdy liczba tras VRF jest duża i gdy koszt wyszukiwania na wyjściu jest akceptowalny dla profilu ruchu. To także naturalny wybór, gdy prostota operacyjna liczy się bardziej niż wyciśnięcie ostatniej mikrosekundy z przekazywania, ponieważ jedna etykieta na dzierżawcę jest łatwiejsza do wyjaśnienia i audytu niż jedna etykieta na prefiks.
To niewłaściwe ustawienie domyślne, gdy dokumentacja platformy wiąże funkcję z konkretnymi ograniczeniami sprzętowymi lub wydania, albo gdy projekt zależy od decyzji przekazywania na prefiks na wyjściu. Przeczytaj własne odniesienie statement platformy, zanim założysz zachowanie; polecenie Junos jest udokumentowane, ale to ograniczenia sprzętowe i wydania wokół niego naprawdę decydują o wdrożeniu.
Budżet, którego możesz bronić
Zbuduj uzasadnienie pojemności jako pięć oddzielnych liczb: odebrane ścieżki, wybrane trasy, zainstalowane wpisy przekazywania, etykiety usługi i etykiety transportu. Dodaj stan next-hop i sąsiedztwa, liczbę dzierżawców i model nadmiarowości. Migawka szczęśliwej ścieżki jednego VRF nie jest liczbą skali, a nominalny rozmiar przestrzeni etykiet nie jest dostępną tablicą sprzętową.
Następnie uzgodnij także tryb awarii, a nie tylko stan ustalony. Co się dzieje, gdy kanał rośnie o połowę, gdy dzierżawca dodaje drugi VRF albo gdy platforma potrzebuje restartu, aby zmienić rozmiar tabeli? Budżet, który przetrwa te pytania, jest wart więcej niż liczba etykiet, która działa tylko na papierze.
Wybierz przydział na podstawie działania na wyjściu i ograniczeń platformy, a następnie uczyń kanał tras jawną decyzją usługową. Etykieta to widoczna część projektu; trasy to część, za którą trzeba płacić każdego dnia.