Co musi się zgadzać, zanim MX zakończy IPsec
Commit, który akceptuje konfigurację, dowodzi tylko parsera, nie ścieżki. Pięć części krotki platformy decyduje, czy usługa naprawdę działa.
Konfiguracja zatwierdza się czysto, interfejsy wstają, a tunel nadal odmawia zestawienia. Nic w logu nie mówi, że platforma nie potrafi tego zrobić; ona po prostu tego nie robi. W Junos IPsec jest usługą, którą może realizować tylko określona kombinacja obudowy, sprzętu usługowego lub ścieżki programowej i wydania, a strona funkcji opisuje możliwości oprogramowania, a nie twojego urządzenia. Krotkę trzeba sprawdzać część po części, bo wynik commita dowodzi wyłącznie parsera.
Dokąd faktycznie trafia pakiet
Ruch wybrany dla IPsec musi dotrzeć do komponentu, który go szyfruje. Na platformach z modułem usług wybrany przepływ jest kierowany do tego modułu, a następnie wraca na ścieżkę przekazywania. Jeśli moduł nie istnieje, ma zbyt małą wydajność lub nie jest powiązany z interfejsem, konfiguracja istnieje, a żaden pakiet nigdy nie jest przetwarzany. Nic w wyniku commita nie odróżnia tego przypadku od stanu zdrowego.
Implementacje hostowane w oprogramowaniu zostawiają pracę na silniku routingu lub w sprzęcie inline, z bardzo różnymi limitami zasobów. Tunel widoczny w konfiguracji nie mówi, która z tych ścieżek faktycznie go przenosi.
Pięć części krotki
Zapisz kombinację, zanim przeczytasz jakiekolwiek zalecenie, bo jedna część może unieważnić pozostałe. Numer części, który trzy lata temu obsługiwał usługę, nic nie mówi o karcie i wydaniu w tej obudowie. Przeczytaj poniższe wiersze jako listę kontrolną, a potem uzupełnij wartości, których konfiguracja nie może ci pokazać.
| Part | What to record | Where it fails quietly |
|---|---|---|
| Chassis and service hardware | Model plus the installed PIC, MPC or MIC | Card absent or not bound to the interface |
| Implementation | Services card, inline or software path | Configuration accepted, no processing |
| Release | Exact Junos version | The feature arrives in a later build |
| Address families and mode | Outer and inner family, tunnel mode, peer authentication | Half the traffic silently unprotected |
| Entitlement and capacity | Licence state and the workload profile | Ceiling reached only under load |
Rodziny adresów i obciążenie to dwa wiersze, które ludzie pomijają, a oba są tanie do sprawdzenia i drogie do odkrycia później. Czytaj krotkę z urządzenia, a nie z arkusza kalkulacyjnego, bo konfiguracja raportuje to, o co prosiłeś, a nie to, co jest zainstalowane. Dwie komendy niosą większość: show chassis hardware wskazuje kartę faktycznie osadzoną, a show version podaje dokładne wydanie. Żadna z nich nie zależy od tego, czy konfiguracja jest poprawna, i właśnie o to chodzi.
show chassis hardware
show versionProgi wydania to prawdziwe progi
Szczegół wydania nie jest formalnością. Przegląd IPsec firmy Juniper datuje obsługę AES-GCM dla kart wielousługowych na Junos 17.3R1, a tryb FIPS zaczyna się od 17.4R1. Ta sama funkcja ma więc dwa progi w zależności od sposobu eksploatacji platformy, a tryb, w którym działasz, decyduje, który obowiązuje. Sprawdź tryb, zanim sprawdzisz listę funkcji.
Czytaj informacje o wydaniu dla dokładnie zainstalowanej wersji, a nie dla najnowszej udokumentowanej. Możliwości, która pojawiła się w późniejszym buildzie, nie można zakładać we wcześniejszym, a stwierdzenie napisane dla jednej karty nie przenosi się na inną. Skopiuj wiersz z informacji o wydaniu do dokumentu projektowego, aby twierdzenie niosło własne źródło, bo oświadczenie o wsparciu napisane dla rodziny platform nie jest oświadczeniem o trybie, w którym działasz, ani o karcie, którą masz.
Wydajność to obciążenie, nie nagłówek
Liczba przepustowości z nagłówka bez warunków pomiaru to liczba marketingowa. Małe pakiety kosztują znacznie więcej na bit niż duże, równoczesne asocjacje zużywają pamięć, a każda inna usługa dzieląca kartę zmniejsza to, co zostaje.
Szacuj na podstawie ruchu, którego oczekujesz: typowych i najgorszych rozmiarów pakietów, liczby peerów oraz tego, czy karta kończy także NAT lub inną usługę. Potem zostaw zapas na dzień, w którym jedna ścieżka przeniesie większe obciążenie, niż zakładał projekt. Plan wydajności zakładający bezczynny sprzęt jest życzeniem, a nie planem. Jeśli liczba ma znaczenie dla uzasadnienia biznesowego, zmierz ją raz na urządzeniu przy reprezentatywnym obciążeniu i zachowaj ten pomiar razem z projektem.
Najpierw zapis, potem projekt
Dla każdej możliwości, której potrzebuje projekt, trzymaj referencję platformy, dokumentację dopasowaną do wydania i wszelkie nierozwiązane ograniczenia w jednym miejscu. Gdy któryś wiersz krotki zawodzi, porównaj osobną zatwierdzoną bramę zamiast przebudowywać projekt wokół nieaktualnej listy zakupów. Zapis powinien mówić, który dokładnie system wykonuje zadanie i w jakich granicach.
Dopiero potem sprawdź peera, bo zgodność protokołu z drugim końcem to następne pytanie i nigdy nie zastępuje wsparcia lokalnego. Peer, który zgadza się co do propozycji, nadal nie pomoże obudowie, która nigdy nie szyfruje pakietu.