Konfiguracja i weryfikacja RIP na Sophos Firewall

RIP automatycznie rozgłasza trasy IPv4 między routerami. Na Sophos Firewall protokół ten sprawdza się przede wszystkim w małych lub istniejących domenach routingu, w których kilka routerów wymienia informacje o sieciach bez złożonego wyboru ścieżek.

Bezpieczna skrócona procedura wygląda następująco:

Udokumentować sieć tranzytową, lokalne sieci LAN, peera, oczekiwane prefiksy i trasę powrotną.
Przygotować kopię zapasową konfiguracji i niezależny dostęp administracyjny.
Sprawdzić bezpośrednią osiągalność adresów IP w sieci tranzytowej.
W Administration > Device access zezwolić na Dynamic Routing tylko dla strefy peera lub za pomocą ściśle ograniczonego wyjątku.
W Routing > RIP wybrać RIPv2 i początkowo pozostawić globalne timery bez zmian.
Dodać sieć tranzytową i lokalne sieci LAN w RIP Networks.
Ustawić interfejsy LAN w tryb Passive mode za pomocą Override interface configuration.
Uzgodnić z peerem wersję i uwierzytelnianie na interfejsie tranzytowym.
W Routing > Information > RIP sprawdzić stan i poznane trasy.
Przetestować Route Lookup, Firewall Rule ID i rzeczywistą usługę dwukierunkową.

⚠️ Default information originate oraz redystrybucja Connected, Static, OSPF lub BGP powinny pozostać wyłączone, dopóki nie będą znane wszystkie rozgłaszane prefiksy i ich trasy powrotne. Szeroka redystrybucja może nieumyślnie rozpropagować trasy Connected lub Static w całej domenie routingu RIP.

Ta procedura dotyczy RIPv2 dla IPv4 w Gateway Mode. RIPv1 uwzględniono wyłącznie na potrzeby połączenia ze starszymi urządzeniami. Sophos Firewall nie obsługuje RIP w Transparent Mode.

Kiedy RIP jest odpowiedni, a kiedy nie

RIP jest protokołem wektora odległości. Ocenia ścieżkę na podstawie liczby przeskoków przez routery. Preferowana jest trasa z niższą metryką. Osiągalnych jest maksymalnie 15 przeskoków; metryka 16 oznacza brak osiągalności.

Routery okresowo wymieniają aktualizacje routingu. Router odbierający uwzględnia zmiany w swojej tablicy routingu, zwiększa metrykę ścieżki o 1 i używa nadawcy jako Next Hop.

Ten prosty model jest zaletą, gdy:

uczestniczy tylko kilka routerów,
topologia jest mała i w dużej mierze stabilna,
istniejący peer obsługuje tylko RIP,
automatyczne utrzymanie tras jest ważniejsze niż szybka konwergencja i złożone zasady.

Dla jednej stałej ścieżki trasa statyczna jest często prostsza. Przy wielu redundantnych ścieżkach, wymaganej szybkiej konwergencji lub większych sieciach wewnętrznych zazwyczaj lepiej sprawdza się OSPF. BGP jest przeznaczony do architektur z systemami autonomicznymi, operatorami lub precyzyjnie sterowanym wyborem tras.

RIP nie zastępuje reguły zapory i nie monitoruje jakości aplikacji. Jeśli ścieżka ma być wybierana na podstawie źródła, usługi, aplikacji, opóźnienia, jittera lub utraty pakietów, potrzebna jest trasa SD-WAN.

Rozróżnienie RIPv1 i RIPv2

W nowych konfiguracjach należy używać RIPv2. Przenosi on maski podsieci i obsługuje uwierzytelnianie. RIPv1 jest protokołem classful, nie przenosi masek podsieci i nie obsługuje uwierzytelniania na Sophos Firewall.

W sekcji RIP version SFOS udostępnia trzy ustawienia:

Send V2 and receive both: wysyłanie RIPv2 oraz odbieranie RIPv1 i RIPv2
V1: wysyłanie i odbieranie RIPv1
V2: wysyłanie i odbieranie RIPv2

W przykładzie oba peery używają RIPv2. Send V2 and receive both może być przydatne podczas kontrolowanego przejścia, ale nadal pozwala odbierać aktualizacje RIPv1. Gdy wszystkie peery korzystają już z RIPv2, wersję wysyłania i odbierania należy ustawić na V2.

Jak działają RIP Networks i Passive Mode

RIP Network nie jest zdalną siecią docelową. Wpis aktywuje RIP na lokalnych interfejsach, których adres IP należy do wskazanej sieci. Bezpośrednio podłączona sieć zostaje w ten sposób uwzględniona w procesie RIP i może być rozgłaszana.

W przykładzie na Firewall A wprowadza się zarówno sieć tranzytową 198.51.100.0/30, jak i lokalną sieć LAN 10.10.10.0/24:

Sieć tranzytowa aktywuje RIP na interfejsie skierowanym do peera.
Sieć LAN jest rozgłaszana jako osiągalna sieć lokalna.
Passive mode na interfejsie LAN zapobiega wysyłaniu przez zaporę aktualizacji RIP za pośrednictwem tego interfejsu.

Passive Mode nie usuwa sieci LAN z procesu routingu. Zapobiega jedynie wysyłaniu ogłoszeń RIP przez ten interfejs. Ponadto Dynamic Routing pozostaje wyłączony w strefie klientów, aby klienci nie mogli wysyłać aktualizacji routingu do zapory.

Planowanie przykładowej topologii

Przykład używany w całym artykule łączy dwie sieci LAN:

Firewall A: adres tranzytowy 198.51.100.1/30, lokalna sieć LAN 10.10.10.0/24
Firewall B: adres tranzytowy 198.51.100.2/30, lokalna sieć LAN 10.20.20.0/24
Sieć tranzytowa: 198.51.100.0/30
Klient testowy A: 10.10.10.10
Serwer testowy B: 10.20.20.10

198.51.100.0/24 jest przeznaczony do celów dokumentacyjnych. Sieć tranzytową, adresy tranzytowe, prefiksy LAN i hosty testowe należy konsekwentnie zastąpić wartościami z własnego środowiska. Adresów dokumentacyjnych nie wolno używać bez zmian w konfiguracji produkcyjnej. Oba adresy tranzytowe muszą być bezpośrednio osiągalne.

Firewall A ma poznać 10.20.20.0/24 przez 198.51.100.2. Peer ma poznać 10.10.10.0/24 przez 198.51.100.1. Dopiero istnienie trasy w obu kierunkach umożliwia routing ruchu bez Source NAT.

Przed zmianą należy udokumentować interfejs, strefę, istniejące trasy, Route Precedence, oczekiwaną metrykę i osiągalny host testowy. Aktualna kopia zapasowa konfiguracji oraz ścieżka dostępu administracyjnego niezależna od nowego routingu umożliwiają kontrolowane wycofanie zmiany.

Ograniczone zezwolenie na Dynamic Routing

W Administration > Device access należy najpierw sprawdzić, w których strefach Dynamic Routing jest obecnie dozwolony. W przykładzie Dynamic Routing jest dozwolony wyłącznie w dedykowanej strefie tranzytowej albo za pomocą wyjątku ACL ograniczonego do peera.

Macierz Device Access dotyczy całej strefy. W dedykowanej, zaufanej strefie tranzytowej można włączyć Dynamic Routing. Jeżeli dostęp ma być możliwy wyłącznie z określonego peera lub sieci tranzytowej, pole wyboru strefy powinno pozostać niezaznaczone. Zamiast tego w Local service ACL exception rule należy utworzyć ściśle ograniczony wyjątek Allow dla danego źródła i usługi. Jednoczesne zezwolenie dla całej strefy zniosłoby to ograniczenie. Różnicę wyjaśnia artykuł Device Access i Local Service ACL.

To zezwolenie dotyczy pakietów RIP do zapory i nie można go zastąpić zwykłą regułą zapory. Ruch danych między 10.10.10.0/24 a 10.20.20.0/24 nadal wymaga natomiast standardowych reguł zapory. Dynamic Routing nie powinien być włączany w strefie LAN tylko dlatego, że sieć LAN jest rozgłaszana jako RIP Network. Przed zmianą należy udokumentować rzeczywisty stan Device Access; nie wolno zakładać ogólnego stanu domyślnego.

Jeśli obie zapory wysyłają aktualizacje RIP przez interfejs tranzytowy, ale tylko Firewall A zezwala na aktualizacje przychodzące, trasy są poznawane tylko po jednej stronie: A odbiera aktualizacje od B i poznaje 10.20.20.0/24 przez 198.51.100.2. B nadal wysyła swoje aktualizacje, lecz odrzuca aktualizacje przychodzące od A, ponieważ na B brakuje zezwolenia na Dynamic Routing. B nie poznaje więc przez RIP trasy do 10.10.10.0/24 rozgłaszanej przez A.

Jest to asymetria wymiany informacji o routingu (płaszczyzna sterowania), a nie dowód konkretnego problemu z ruchem danych. Należy sprawdzić obie strony w Routing > Information > RIP > Routes i zweryfikować rzeczywiste zezwolenie na odbiór aktualizacji na zaporze, która nie poznaje tras. Ewentualna korekta musi być ograniczona do faktycznej strefy peera lub ściśle ograniczonego wyjątku ACL; nie należy zezwalać ogólnie na dostęp ze strefy WAN. Następnie należy osobno sprawdzić Route Lookup, reguły zapory, NAT oraz rzeczywiste ścieżki w obu kierunkach.

Konfiguracja RIPv2 w WebAdmin

W przykładzie po stronie B działa druga Sophos Firewall. W przypadku dwóch urządzeń Sophos Firewall konfigurację należy odtworzyć na peerze; różnią się tylko adres tranzytowy i lokalna sieć LAN. Na routerze innego producenta RIPv2, sieć tranzytową, lokalną sieć LAN, Passive Mode i ewentualne uwierzytelnianie należy skonfigurować za pomocą odpowiednich funkcji tego urządzenia.

1. Ustawienie wartości globalnych

Otworzyć ustawienia globalne w Routing > RIP:

Ustawić RIP version na V2.
Pozostawić Default metric z istniejącą wartością domyślną 1.
Pozostawić Administrative distance z istniejącą wartością domyślną 120.
Początkowo pozostawić Update, Timeout i Garbage na 30, 180 i 120 sekund.
Pozostawić Default information originate wyłączone.
Nie włączać redystrybucji.
Zapisać ustawienia przyciskiem Apply.

Default information originate generuje i rozgłasza trasę domyślną w domenie routingu RIP i jest domyślnie wyłączone. Ma to sens tylko wtedy, gdy zapora ma świadomie pełnić funkcję wyjścia dla wszystkich nieznanych miejsc docelowych, a trasa powrotna i zachowanie w razie awarii zostały zaplanowane.

Domyślna wartość Default metric dla tras redystrybuowanych wynosi 1; dozwolony zakres to od 1 do 16. Domyślna wartość Administrative distance wynosi 120, a dozwolony zakres to od 1 do 255. Bez udokumentowanego projektu routingu obie wartości powinny pozostać bez zmian.

Administrative distance pomaga routerowi wybrać lepszą trasę spośród konkurujących źródeł routingu; metryka RIP porównuje natomiast ścieżki w obrębie RIP.

Domyślne wartości Update, Timeout i Garbage wynoszą odpowiednio 30, 180 i 120 sekund. Update określa odstęp między dwiema okresowymi aktualizacjami routingu. Oficjalna dokumentacja SFOS 22.0 podaje dla każdego z tych trzech timerów zakres od 5 do 2147483647 sekund; dokumentacja SFOS 23.0 podaje dla każdego zakres od 1 do 32767 sekund i nazywa Timeout Time-out. Są to dane z dokumentacji poszczególnych wersji, a nie gwarancja walidacji danych wejściowych w przetestowanej kompilacji. W przykładzie zachowano wartości domyślne; inne wartości należy wybrać tylko w ramach wspólnego dla obu peerów planu dotyczącego timerów i awarii.

Jeżeli redystrybucja jest świadomie potrzebna, w Routing > RIP należy włączyć tylko zaplanowane źródła: Redistribute connected dla tras bezpośrednio podłączonych, Redistribute static dla tras statycznych, Redistribute OSPF dla tras OSPF i Redistribute BGP dla tras BGP. Dla każdego włączonego źródła należy ustawić odpowiednią metrykę tras redystrybuowanych; wszystkie cztery pola dopuszczają od 0 do 16, inaczej niż globalne Default metric. Wartości należy dobierać według udokumentowanego projektu routingu, a nie kopiować jedną ogólną wartość. Zapisać za pomocą Apply, a następnie sprawdzić oczekiwane i nieoczekiwane prefiksy oraz trasę powrotną zgodnie z opisem poniżej. W przykładzie wszystkie cztery źródła pozostają wyłączone.

2. Dodanie RIP Networks

W Routing > RIP > RIP Networks > Add wprowadzić na Firewall A następujące sieci lokalne:

198.51.100.0 z maską podsieci 255.255.255.252
10.10.10.0 z maską podsieci 255.255.255.0

Na peerze B wprowadzić tę samą sieć tranzytową oraz 10.20.20.0/24.

Przed zapisaniem należy sprawdzić, który lokalny interfejs jest obejmowany przez każdy wpis Network. Zbyt szeroki wpis Network może aktywować RIP na dodatkowych interfejsach i włączyć do procesu kolejne bezpośrednio podłączone sieci.

3. Ustawienie Interface Overrides

W Routing > RIP > Override interface configuration wybrać odpowiedni interfejs za pomocą Select interface.

Send i Receive niezależnie dopuszczają V1, V2 lub obie wersje. Wybór dla danego interfejsu zastępuje globalne ustawienie RIP version. Domyślną wartością Send jest V2; wybrana poniżej wersja odbioru V2 jest świadomą konfiguracją przykładową, a nie stwierdzeniem o wartości domyślnej Receive. Passive mode jest domyślnie wyłączone i zostaje celowo włączone dla LAN.

Dla świadomie uwierzytelnianego połączenia RIPv2 włączyć Authentication i wprowadzić hasło; konfiguracja musi być zgodna na obu peerach. Jeżeli uwierzytelnianie zostanie wybrane dla interfejsu RIPv1, wysyła on aktualizacje routingu, ale nie przyjmuje tras. Przy wyborze obu wersji RIPv2 nadal działa z uwierzytelnianiem. Sophos zaleca konfigurację RIPv1 na innym interfejsie niż uwierzytelniane RIPv2.

Dla interfejsu tranzytowego:

Send version: V2
Receive version: V2
Passive mode: wyłączone
Split horizon: zachować udokumentowany stan początkowy; SFOS domyślnie wyłącza tę opcję
Poisoned reverse: dostępne tylko przy włączonym Split Horizon i domyślnie wyłączone
Authentication: sprawdzić rzeczywisty stan początkowy i świadomie ustawić identyczną konfigurację po obu stronach

Dla interfejsu LAN:

Send version: V2
Receive version: V2
Passive mode: włączone

Zapisać wybór za pomocą Save. RIPv2 obsługuje uwierzytelnianie tekstem jawnym i MD5. Tekst jawny nie chroni hasła. MD5 uwierzytelnia aktualizacje routingu, ale nie szyfruje prefiksów ani metryk. Segmenty tranzytowe powinny zatem pozostać ograniczone do przewidzianych routerów. Publiczna pomoc CLI dla SFOS 22 i pomoc WebAdmin podają sprzeczne informacje o domyślnym stanie uwierzytelniania. Dlatego w tym artykule nie przyjęto żadnego stanu domyślnego: należy sprawdzić oba interfejsy tranzytowe, a następnie świadomie skonfigurować je identycznie.

Split horizon zwykle zapobiega ponownemu rozgłaszaniu przez ten sam interfejs trasy poznanej za jego pośrednictwem. Poisoned reverse może jawnie rozgłosić ją przez ten interfejs jako nieosiągalną z metryką 16. Opcje te należy zmieniać tylko wtedy, gdy wymaga tego topologia hub, spoke lub multi-access, a zmianę należy przetestować wspólnie z peerem.

4. Odtworzenie konfiguracji na peerze

Na Firewall B należy ustawić identyczną wersję, timery i uwierzytelnianie. Jako Networks należy dodać 198.51.100.0/30 i 10.20.20.0/24, a interfejs do lokalnej sieci LAN ustawić jako pasywny.

Konfiguracja jednostronna nie wystarcza. Bez ogłoszenia sieci powrotnej Firewall A może poznać zdalną sieć LAN, lecz odpowiedzi nie znajdą drogi powrotnej.

Dlaczego zmiany w tym przewodniku wykonuje się w WebAdmin

Udokumentowany sposób wejścia do CLI zależy od wersji: pomoc dla SFOS 22.0 wskazuje 3. Route Configuration > 1. Configure Unicast Routing > 1. Configure RIP, znak zachęty rip>, a następnie enable. Pomoc dla SFOS 23.0 wskazuje natomiast 3. Route Configuration > 1. Configure Unicast Routing, znak zachęty router#, a następnie router#configure terminal. Wpis router rip w tabeli jest poleceniem CLI, a nie dodatkową opcją menu. Jest to porównanie udokumentowanych sposobów wejścia, a nie wykonywalna sekwencja konfiguracji.

Publiczna pomoc CLI dla SFOS 22 zawiera nieprawidłowo połączone polecenia uwierzytelniania i nie dokumentuje wszystkich poleceń wymaganych do zapisania i zweryfikowania konfiguracji. Pomoc dla SFOS 23.0 również pozostaje niejednoznaczna co do kontekstów CLI dla uwierzytelniania i przykładu MD5. Poprawienie przykładów uwierzytelniania tekstem jawnym nie sprawia automatycznie, że pozostałe polecenia tworzą wiarygodną sekwencję. Na podstawie tego materiału nie tworzy się niepotwierdzonej składni ani kroków zmiany kontekstu czy zapisywania.

Dlatego konfigurację i wycofanie zmian wykonuje się za pomocą udokumentowanych pól WebAdmin. CLI należy używać wyłącznie do diagnostyki pomocy technicznej w trybie odczytu, udokumentowanej dla zainstalowanej wersji SFOS.

Reguły zapory, NAT i Route Precedence

Do testu obie zapory potrzebują ściśle ograniczonych, rejestrowanych reguł dla usług rzeczywiście wymaganych między 10.10.10.0/24 i 10.20.20.0/24. Mechanizm reguł wyjaśnia artykuł Prawidłowe tworzenie reguł zapory.

W normalnie routowanej sieci oddziałów Source NAT pozostaje wyłączony. Obie strony powinny widzieć rzeczywisty adres źródłowy i znać trasę powrotną przez RIP. SNAT może ukrywać brakujące trasy powrotne oraz utrudniać późniejszą analizę i kontrolę dostępu.

W ramach RIP SFOS zachowuje dla danego celu trasę o najniższej metryce liczby przeskoków. Nie dowodzi to jednak, że jest ona również aktywną trasą w całym systemie. Gdy konkuruje z nią trasa statyczna, SD-WAN lub VPN, rzeczywiście wybraną ścieżkę należy sprawdzić w Diagnostics > Tools > Route lookup. Nie należy globalnie zmieniać Route Precedence na potrzeby pojedynczego testu RIP.

Weryfikacja RIP i rzeczywistej ścieżki danych

Podczas weryfikacji należy oddzielnie odpowiedzieć na trzy pytania: czy trasy są wymieniane, czy wybrano właściwą trasę i czy działa ruch danych?

Sprawdzenie Routes i Status

W Routing > Information > RIP > Routes Firewall A musi wyświetlać sieć 10.20.20.0/24 z Next Hop 198.51.100.2 i wiarygodną metryką. Peer B musi znać 10.10.10.0/24 przez 198.51.100.1.

W Routing > Information > RIP > Status należy porównać na obu zaporach:

uczestniczące interfejsy
wysyłane i odbierane wersje RIP
timery Update, Timeout i Garbage
źródła routingu i redystrybucję
pola From, Tag i Time trasy
filtry aktualizacji przychodzących i wychodzących, jeśli zostały ustawione
nazwę Key Chain, jeśli została skonfigurowana
Bad Packets i Bad Routes

Widoczna trasa RIP potwierdza wymianę tras, ale nie potwierdza, że SFOS ją wybiera ani że przesyła nią ruch danych. Widok stanu nie stanowi dowodu na użycie określonego sekretu; sekret musi być zarządzany i sprawdzany w kontrolowany sposób na obu peerach.

Test Route Lookup i ruchu

Na Firewall A sprawdzić cel 10.20.20.10 w Diagnostics > Tools > Route lookup. Next Hop i interfejs muszą odpowiadać ścieżce tranzytowej.
Na peerze B sprawdzić cel 10.10.10.10.
Z klienta 10.10.10.10 uruchomić rzeczywiste dozwolone połączenie z serwerem 10.20.20.10.
W Log viewer sprawdzić źródło, cel, usługę, Firewall Rule ID, Action i ewentualny NAT Rule ID.
W Diagnostics > Packet capture potwierdzić, że żądanie i odpowiedź przechodzą przez oczekiwane interfejsy.

Pełną procedurę opisuje artykuł Testowanie reguły zapory za pomocą Log Viewer i Packet Capture.

Systematyczne zawężanie przyczyn błędów

Nie pojawia się żadna trasa RIP

Najpierw należy sprawdzić bezpośrednią osiągalność adresów tranzytowych. Następnie Dynamic Routing musi być dozwolony we właściwej strefie peera, RIP Network musi pasować do lokalnego interfejsu, a wersje wysyłania i odbierania muszą być zgodne. Przy uwierzytelnianiu metoda i sekret muszą być zgodne.

Jeśli liczniki Bad Packets lub Bad Routes rosną w Status, należy porównać wersję, uwierzytelnianie, podsieć i konfigurację peera. Jeżeli liczniki pozostają bez zmian, a widoki diagnostyczne nie pokazują ruchu RIP od peera, należy najpierw sprawdzić przypisanie interfejsu i Local Service ACL. Dopiero potem należy zmieniać globalne wartości RIP.

Trasa jest widoczna w RIP, ale nie jest używana

W takim przypadku wymiana protokołu działa. Route Lookup pokazuje, która ścieżka jest rzeczywiście aktywna. Metryka RIP porównuje ścieżki RIP; sama nie rozstrzyga między wszystkimi źródłami routingu.

Nie należy usuwać globalnej Route Precedence ani istniejącej trasy produkcyjnej przed udokumentowaniem jej wpływu na inne sieci.

Ruch działa tylko w jednym kierunku

Peer potrzebuje trasy powrotnej, a obie zapory odpowiednich reguł. Należy również sprawdzić NAT, ścieżki asymetryczne i bramę domyślną hosta. Istnienie ścieżki w jednym kierunku nie potwierdza ścieżki powrotnej.

Trasa znika i pojawia się ponownie

Jeśli przed upływem skonfigurowanej wartości Timeout nie nadejdą żadne aktualizacje, trasa stanie się nieważna. W okresie Garbage SFOS rozgłasza ją jako nieosiągalną z metryką 16, a następnie usuwa. Dlatego przed zmianą timerów należy porównać osiągalność, stan peera oraz wartości Update, Timeout i Garbage po obu stronach.

Rozgłaszane są nieoczekiwane sieci

Należy osobno sprawdzić RIP Networks, Default information originate i każdą opcję redystrybucji. Redystrybucja może obejmować więcej tras Connected lub Static niż sieci LAN przewidziane w tym przykładzie. Funkcja powinna pozostać wyłączona, dopóki nie będą znane wszystkie prefiksy, które rzeczywiście mają być dystrybuowane.

Bezpieczne wycofanie zmiany

Przed usunięciem RIP dla każdej poznanej sieci docelowej musi istnieć ścieżka alternatywna lub zaplanowane okno serwisowe.

Wycofanie rozpoczyna się od ścieżki zastępczej, a nie od usunięcia aktywnych tras RIP:

Włączyć alternatywną trasę statyczną lub dynamiczną i zweryfikować ją za pomocą Route Lookup, dostępu administracyjnego i rzeczywistego ruchu dwukierunkowego.
Wyłączyć nowo aktywowaną redystrybucję i Default information originate, jeśli celowo stanowiły część testu; następnie ponownie sprawdzić oczekiwane prefiksy.
Usuwać lokalne RIP Networks pojedynczo, sprawdzając po każdym kroku trasę w obu kierunkach.
Przywrócić Interface Overrides i globalne ustawienia RIP do udokumentowanego stanu początkowego.
Usunąć Dynamic Routing ze strefy tranzytowej lub wyjątek ACL na samym końcu i tylko wtedy, gdy zezwolenie nie jest również potrzebne żadnemu sąsiadowi OSPF, BGP ani PIM.
Na koniec ponownie sprawdzić Route Lookup, reguły, dostęp administracyjny i rzeczywisty ruch.

Nie należy usuwać jednocześnie RIP i ścieżki zastępczej. Istniejącą sesję administratora należy pozostawić otwartą do czasu potwierdzenia trasy powrotnej.

Kontrola przed zatwierdzeniem

Obie zapory pokazują oczekiwane trasy RIP z poprawnym Next Hop i wiarygodną metryką.
Route Lookup potwierdza zamierzone trasy w obu kierunkach.
Nie pojawiają się nieoczekiwane prefiksy ani niezamierzona redystrybucja.
Działają ściśle ograniczone, rejestrowane reguły zapory bez niezamierzonego SNAT.
Rzeczywista usługa działa dwukierunkowo.
Ścieżka zastępcza i procedura wycofania są udokumentowane i wykonalne.