Konfigurowanie i testowanie interfejsu bridge w Sophos Firewall

Interfejs bridge łączy co najmniej dwa interfejsy w warstwie 2. Pozwala to włączyć Sophos Firewall w istniejącą ścieżkę sieciową bez zmiany podsieci ani bramy domyślnej klientów. Bridge może działać transparentnie, bez adresu IP, albo otrzymać własny adres IP i routować ruch.

W przykładzie opisanym w tym artykule zapora zostaje umieszczona między istniejącym routerem a przełącznikiem rdzeniowym. Port4 jest połączony z routerem i należy do strefy WAN, a Port3 — z przełącznikiem wewnętrznym i do strefy LAN. Sam bridge nie otrzymuje adresu IP. Dostęp do WebAdmin pozostaje możliwy przez osobny port administracyjny.

⚠️ Podczas zapisywania konfiguracji bridge przejmuje swoje interfejsy składowe. Niewłaściwa strefa, brak odrębnej ścieżki administracyjnej lub nadmiarowa ścieżka warstwy 2 mogą odciąć dostęp albo utworzyć pętlę. Wcześniej wykonaj kopię zapasową, udokumentuj okablowanie i przetestuj niezależny dostęp administracyjny. Drugą ścieżkę fizyczną podłącz dopiero po ustaleniu konfiguracji STP i ewentualnej architektury HA.

Który sposób działania bridge wybrać?

Transparentny bridge bez adresu IP

Transparentny bridge przekazuje ramki Ethernet między interfejsami składowymi, ale nie pełni funkcji bramy. Adresy IP, podsieć i brama domyślna urządzeń końcowych pozostają bez zmian. Takie rozwiązanie sprawdza się podczas kontrolowanej migracji lub jako dodatkowa warstwa zabezpieczeń między istniejącym routerem a siecią wewnętrzną. Zależnie od reguły i licencji SFOS może stosować w tej ścieżce DPI, IPS, skanowanie pod kątem złośliwego oprogramowania i kontrolę poczty elektronicznej, mimo że bramą nadal jest dotychczasowy router.

Transparentność nie oznacza braku filtrowania. Strefy interfejsów składowych decydują o tym, która reguła zapory może zostać zastosowana. Dla przykładowej ścieżki z Port3 w strefie LAN do Port4 w strefie WAN potrzebna jest odpowiednia reguła LAN-to-WAN. Jeśli oba interfejsy składowe znajdują się w strefie LAN, wymagana jest zamiast tego reguła LAN-to-LAN.

Sposób doboru obszarów zaufania, tworzenia własnych stref i przypisywania interfejsów opisano w artykule Planowanie stref i interfejsów w Sophos Firewall. Wszystkie decyzje dotyczące samego bridge omówiono na tej stronie; artykuł podstawowy pomaga natomiast przy tworzeniu nowego lub porządkowaniu niespójnego modelu stref.

Jeśli bridge nie ma adresu IP, do administrowania należy używać innego interfejsu. W tym przykładzie Port2 obsługuje osobną sieć administracyjną. Dzięki temu WebAdmin pozostaje dostępny również wtedy, gdy bridge, jego reguły lub okablowanie nie działają jeszcze prawidłowo.

Routowany bridge z adresem IP

Po włączeniu Enable routing on this bridge pair bridge otrzymuje adres IP i może pełnić funkcję bramy lub lokalnego punktu końcowego zapory. Zasadniczo zmienia to jego rolę: oprócz przekazywania w warstwie 2 pojawia się ruch routowany, usługi lokalne oraz ewentualne zależności od bram.

Filtrowanie VLAN na bridge nadal obejmuje wyłącznie ramki przekazywane w warstwie 2. Nie filtruje ruchu routowanego przez bridge. Jeśli bridge pełni funkcję bramy, trzeba więc dodatkowo sprawdzić routing, Device Access, reguły zapory i NAT.

Dokumentacja SFOS 22 nie jest jednoznaczna w kwestii DHCP. W ustawieniach adresu IP routowanego bridge wymienia opcje Static i DHCP, ale w tym samym dokumencie zalicza klientów DHCP do nieobsługiwanych funkcji bridge. Dlatego w przewidywalnym środowisku produkcyjnym należy użyć adresu statycznego. DHCP na bridge można zastosować dopiero po zweryfikowaniu konkretnej wersji SFOS i uzyskaniu potwierdzenia od Sophos.

Bridge Mode w kreatorze konfiguracji

Opcja Bridge Mode w kreatorze pierwszej konfiguracji oraz interfejs bridge utworzony później w Network > Interfaces działają według tej samej zasady warstwy 2, ale są odrębnymi procedurami.

W nowym urządzeniu Port A ma domyślnie adres 172.16.16.16/24, a Port B pobiera adres przez DHCP. Na potrzeby pierwszej konfiguracji można na przykład ustawić na komputerze adres 172.16.16.2/24 i podłączyć go do Port A. WebAdmin jest wówczas dostępny pod adresem https://172.16.16.16:4444. W kreatorze należy wybrać Internet gateway (Bridge Mode). Po rejestracji oraz skonfigurowaniu zabezpieczeń i powiadomień SFOS zastosuje ustawienia i uruchomi się ponownie.

Ten tryb służy do pełnego, początkowego wdrożenia urządzenia. Istniejącej zapory nie należy ponownie przeprowadzać przez kreator tylko po to, aby dodać jedną parę bridge. Uruchomienie kreatora po wcześniejszym skonfigurowaniu HA powoduje wyłączenie HA.

Bridge Mode obsługuje HA. Jednocześnie, dopóki HA jest włączone, funkcji STP systemu SFOS nie można aktywować na żadnym interfejsie bridge. Nie należy mylić tego z przekazywaniem pakietów STP, RSTP i routingu multicast. Przezroczysty bridge może przepuszczać takie ramki, samemu nie uczestnicząc w zapobieganiu pętlom za pomocą opcji SFOS Turn on Spanning Tree Protocol (STP).

Planowanie przykładu przed konfiguracją

Topologia i przykładowe wartości

Dotychczasowy router pozostaje bramą domyślną sieci 10.20.0.0/24. Zapora zostaje transparentnie włączona w jego ścieżkę LAN:

Internet
   |
Dotychczasowy router: 10.20.0.1
   |
Port4, strefa WAN
[ Bridge_Inline / brinline / bez adresu IP ]
Port3, strefa LAN
   |
Przełącznik rdzeniowy i klienci: 10.20.0.0/24

Osobna ścieżka administracyjna:
Port2, strefa LAN, 10.99.0.1/24

Po włączeniu zapory w ścieżkę klient o adresie 10.20.0.50/24 nadal używa 10.20.0.1 jako bramy. Bridge nie otrzymuje ani adresu z sieci 10.20.0.0/24, ani trasy domyślnej. Numery portów, strefy, sieć administracyjną i reguły trzeba dostosować. Przykładowej adresacji nie wolno bezrefleksyjnie przenosić do środowiska produkcyjnego.

Przed przebudową należy udokumentować dwa stany: które połączenia działają przed włączeniem zapory w ścieżkę oraz jak administrować zaporą w razie awarii produkcyjnej ścieżki danych. Trzeba uwzględnić co najmniej DNS, bramę, typową aplikację, oczekiwaną przepustowość i dostęp do WebAdmin.

Sprawdzanie interfejsów składowych, stref i zależności

Bridge może zawierać maksymalnie 64 interfejsy składowe. Mogą nimi być:

• interfejsy fizyczne;
• interfejsy RED;
• interfejsy LAG;
• interfejsy VLAN utworzone na interfejsie fizycznym, RED lub LAG.

Większa liczba interfejsów składowych nie świadczy o jakości rozwiązania. Każde dodatkowe połączenie powiększa domenę warstwy 2 i tablicę MAC oraz zwiększa liczbę możliwych pętli. W ścieżce inline zwykle wystarczają dwa interfejsy składowe.

Przed dodaniem każdego interfejsu należy sprawdzić jego dotychczasowe adresy IP, sieci VLAN, DHCP, bramy, NAT, reguły zapory, routing, Device Access i Object Usage. Dodanie portu do bridge nie usuwa automatycznie jego wcześniejszej funkcji ze wszystkich zależnych obiektów.

Według Sophos interfejsy bridge nie obsługują Dynamic DNS, PPPoE ani IPsec VPN. Jak opisano wyżej, informacje dotyczące DHCP również są niespójne. Bridge nie jest więc uniwersalnym zamiennikiem interfejsu WAN lub VPN. W nowych, jednoznacznie segmentowanych sieciach łatwiejsze w utrzymaniu są często sieci VLAN i routing.

LAN Bypass jest odrębną funkcją sprzętową, a nie typowym sposobem działania dowolnego bridge. Informacje o obsługujących ją modelach i parach portów oraz zachowaniu w razie awarii zawiera artykuł Konfigurowanie i kontrolowane testowanie LAN Bypass.

Tworzenie bridge w WebAdmin

Nazwa, nazwa sprzętowa i interfejsy składowe

1. Otwórz Network > Interfaces > Add interface > Add bridge.
2. W polu Name wpisz na przykład Bridge_Inline. Nazwa wyświetlana może mieć do 58 znaków i można ją później zmienić.
3. W polu Hardware name wpisz na przykład brinline. Wartość może mieć najwyżej 10 znaków i składać się wyłącznie z liter, cyfr oraz znaku _. Po zapisaniu nie można jej zmienić.
4. W przykładowej konfiguracji transparentnej pozostaw opcję Enable routing on this bridge pair wyłączoną.
5. Dodaj Port3 ze strefą LAN i Port4 ze strefą WAN jako Member interfaces.
6. Sprawdź ustawienia VLAN, ARP, STP, MAC, MTU, MSS i EtherType.
7. Wybierz Save dopiero wtedy, gdy działa osobny dostęp administracyjny, a oba przewody są jednoznacznie oznaczone.

SFOS blokuje zastrzeżone nazwy sprzętowe. Pełna lista z dokumentacji SFOS 22 wygląda następująco:

all, gre, oct, mv-pcimux0, mvmgmt0, pport_, lo, ipsec0, tun, ppp,
imq, ifb, mast, sit, WWAN1, _ppp, vxlan, xfrm, USB, erspan0, Port,
MGMT, eth, GE, gretap0, ip6tnl0, host, reds, wlnet, WLAN, Sophos,
GuestAP, spq, Halink

W routowanym bridge należy dodatkowo skonfigurować IPv4 lub IPv6. Jeśli bridge zawiera interfejsy składowe WAN, pojawią się także pola bramy. Wartości te muszą odpowiadać rzeczywistej architekturze routingu. W przykładowym transparentnym bridge pozostają puste.

Filtry VLAN i EtherType

Opcja Filter VLANs ogranicza ruch tagowany do identyfikatorów wpisanych w polu Permitted VLAN ID or ID range. Można podawać pojedyncze wartości i zakresy, takie jak 20-35. Jeśli filtr jest włączony, ale lista pozostaje pusta, SFOS odrzuca cały tagowany ruch VLAN. Ruch nietagowany nadal jest przekazywany. Taka kombinacja może utrudniać diagnostykę.

Filtr VLAN dotyczy tylko ramek przekazywanych przez bridge. Nie zastępuje reguł zapory ani kontroli ruchu routowanego. Historyczne tagi VLAN skonfigurowane w CLI wymagają osobnej weryfikacji w SFOS 22. Procedurę dla tego szczególnego przypadku wraz z informacjami o wersjach opisano w artykule Weryfikowanie sieci VLAN bridge po przejściu na SFOS 22.

Opcja Filter Ethernet frames pozwala ograniczyć dozwolone wartości EtherType. Bez filtra bridge przepuszcza wszystkie ramki Ethernet. Jeśli filtr jest włączony, ale nie wskazano żadnych dozwolonych typów, nadal dozwolone są tylko ARP, IPv4, IPv6, 8021Q i EXTE. Inne protokoły wpisuje się jako czterocyfrowy identyfikator szesnastkowy, na przykład 809B dla AppleTalk, 8138 dla Novell oraz 8863 i 8864 dla PPPoE.

Nie należy zezwalać na EtherType „na wszelki wypadek”. Najpierw w Packet Capture trzeba ustalić, którego protokołu faktycznie brakuje. W przeciwnym razie powstanie nieczytelna lista wyjątków, których przeznaczenia nie będzie można później jednoznacznie ustalić.

ARP, STP i starzenie wpisów MAC

Opcja Permit ARP broadcast jest domyślnie włączona. Bridge potrzebuje ARP, aby poznawać odwzorowania adresów IP na MAC i budować tablicę przekazywania. Wyłączenie tej opcji nie jest uniwersalną ochroną przed ruchem rozgłoszeniowym. Ma uzasadnienie tylko w przypadku potwierdzonej burzy ARP i wymaga statycznych powiązań w Network > Neighbors (ARP–NDP).

Opcja Turn on Spanning Tree Protocol (STP) chroni przed pętlami, jeśli między tymi samymi obszarami istnieje więcej niż jedna ścieżka warstwy 2. STP może zablokować ścieżkę nadmiarową, a po awarii ścieżki aktywnej przełączyć ruch. Opcja ta nie jest dostępna na interfejsach bridge, gdy działa HA. Klaster HA z redundantnym okablowaniem wymaga zatem architektury, w której przełączniki, ścieżki przez porty i mechanizmy zapobiegania pętlom zaplanowano łącznie.

Domyślna wartość STP max age wynosi 20 sekund. SFOS używa jednostek BPDU do wymiany informacji o topologii między mostami. Wartości tej nie należy optymalizować wyłącznie na zaporze — musi być dopasowana do całej domeny STP.

Opcja MAC aging domyślnie usuwa nieaktywne adresy MAC po 300 sekundach. Niższa wartość może przyspieszyć reakcję na zmiany urządzeń w bardzo dynamicznej sieci gościnnej lub testowej. W stabilnej sieci centrum danych wyższa wartość ogranicza zbędne ponowne uczenie. Wartość należy zmienić tylko wtedy, gdy uzasadniają to flapping adresów MAC, częste zmiany lokalizacji urządzeń lub konkretne wymaganie operacyjne.

MTU i MSS

Jeśli wartości MTU bridge i jego interfejsów składowych są różne, bridge przyjmuje niższą z nich. Bridge o MTU 9000 będzie faktycznie używać 1500, jeśli jeden z interfejsów składowych obsługuje tylko 1500. Przejęta wartość jest widoczna w tabeli interfejsów.

Opcja Override MSS dotyczy protokołu TCP. Wartość ogranicza ilość danych użytkowych w segmencie TCP, aby dodatkowe nagłówki lub enkapsulacja tunelu nie spowodowały przekroczenia efektywnego MTU. Pomaga przy potwierdzonym problemie z MTU lub fragmentacją, lecz nie naprawi błędnej sieci VLAN, brakującej reguły ani uszkodzonej ścieżki powrotnej. Mechanizm MSS clamping nie zmniejsza pakietów UDP. Szczegółową procedurę diagnostyczną opisano w artykule Sprawdzanie MTU i MSS przy problemach z VPN.

Reguły zapory, NAT i Web Proxy

Bridge nie omija zapory stanowej. W tym przykładzie ruch klientów wymaga reguły ze strefy LAN do WAN. Jako Source Network należy wskazać 10.20.0.0/24 lub węższy obiekt, a jako Destination i Service — wyłącznie rzeczywiście potrzebny zakres. Na czas testów odbiorczych rejestrowanie zdarzeń pozostaje włączone.

Pełną podstawową procedurę doboru kolejności reguł, dopasowania stref i funkcji ochronnych opisano w artykule Konfigurowanie reguł zapory w Sophos Firewall. W przypadku bridge rozstrzygające pozostają strefy interfejsów składowych, przez które dana ramka wchodzi i wychodzi.

Pakiety odpowiedzi należące do dozwolonego połączenia zainicjowanego od wewnątrz wracają zgodnie z istniejącym stanem połączenia. Nie jest do tego potrzebna szeroka reguła WAN-to-LAN. Nowe połączenia przychodzące wymagają natomiast osobnej, świadomie ograniczonej reguły.

Bridge bez adresu IP wiąże się z nietypową klasą błędów. Jeśli ruch zostanie dopasowany do reguły zapory z Web Proxy Filtering albo do reguły NAT, SFOS może odrzucić pakiety bez wpisu w Log Viewer. Pusty dziennik nie dowodzi w takim przypadku, że żadna reguła nie miała udziału w przetwarzaniu ruchu.

Jeśli reguła NAT jest potrzebna, należy włączyć w niej opcję Override source translation for specific outbound interfaces. Jako Outbound interface trzeba wskazać bridge, a Translated source (SNAT) ustawić na Original. Dzięki temu adres źródłowy pozostanie niezmieniony dla tego interfejsu wyjściowego. Globalna zmiana NAT byłaby niewłaściwym testem, ponieważ wpływałaby na inne ścieżki danych i przesłaniała faktyczną przyczynę błędu.

Web Proxy Filtering na transparentnym bridge bez adresu IP należy stosować wyłącznie wtedy, gdy wyraźnie przewidują to architektura rozwiązania i używana wersja SFOS. W typowej inspekcji inline bardziej przejrzystym punktem wyjścia są reguły oparte na DPI.

Testy odbiorcze ścieżki danych i diagnostyka

Testy odbiorcze po zapisaniu konfiguracji

Po zapisaniu należy osobno sprawdzić konfigurację, ruch użytkowy i scenariusz awarii:

1. W Network > Interfaces porównaj z projektem nazwę bridge, nazwę sprzętową, interfejsy składowe, strefy, tryb IP, przejęte MTU i stan łącza.
2. Z klienta testowego nawiąż połączenie z potrzebną usługą i potwierdź w Log Viewer oczekiwany identyfikator Firewall Rule ID.
3. Porównaj ruch wejściowy i wyjściowy w Packet Capture. Źródłowy i docelowy adres MAC, tag VLAN, EtherType oraz interfejs muszą odpowiadać topologii.
4. Przetestuj dozwoloną usługę w obu kierunkach. Następnie uruchom celowo niedozwoloną usługę i potwierdź oczekiwane odrzucenie ruchu.
5. Sprawdź DNS, bramę domyślną i typową aplikację biznesową. Pojedynczy ping nie wystarczy.
6. Ponownie sprawdź dostęp administracyjny przez niezależny port.
7. Jeśli używasz STP, dołącz ścieżkę nadmiarową wyłącznie w oknie serwisowym, a następnie zmierz czas przełączenia i utratę pakietów.
8. W środowisku HA po kontrolowanej zmianie ról ponownie przetestuj bridge, interfejsy składowe, uczenie adresów MAC i aplikacje.

Brak ruchu i brak wpisu w dzienniku

Jeśli w Log Viewer nie pojawia się ani Allow, ani Drop, najpierw należy sprawdzić przypadki szczególne dotyczące bridge:

• Czy bridge nie ma adresu IP?
• Czy przepływ jest dopasowywany do reguły NAT?
• Czy reguła zapory korzysta z Web Proxy Filtering?
• Czy nadpisanie SNAT dla tego bridge ustawiono na Original?
• Czy Packet Capture pokazuje ramkę na wejściowym interfejsie składowym, ale nie na wyjściowym?

Dopiero później warto analizować typowe problemy z kolejnością reguł lub ścieżką powrotną. Pozwala to uniknąć reagowania na nierejestrowane odrzucenie przez bridge za pomocą coraz szerszych reguł Allow.

Odrzucanie VLAN lub EtherType

W System services > Log settings > Firewall należy włączyć komponent Bridge ACLs. Następnie w Log Viewer można filtrować wpisy według Log component > Bridge ACLs, a dodatkowo według podtypów ARP broadcasts, EtherType filtering lub VLAN filtering.

Przy problemach z VLAN trzeba łącznie sprawdzić, czy ruch jest tagowany czy nietagowany, listę dozwolonych sieci VLAN oraz profil portu przełącznika. Przy problemach z EtherType Packet Capture pokaże rzeczywiście występujący czterocyfrowy identyfikator. Filtr i konfiguracja urządzenia po drugiej stronie muszą odpowiadać tej samej ścieżce danych.

Ruch działa tylko w jednym kierunku

Ruch działający tylko w jednym kierunku zwykle wskazuje na niewłaściwą strefę, brakującą regułę, routing asymetryczny albo brak nauczonego wpisu MAC. W Packet Capture należy porównać drogę do celu i drogę powrotną na obu interfejsach składowych. Następnie trzeba sprawdzić Rule ID, Source NAT, bramę i tablicę MAC.

Pętla lub flapping adresów MAC

Duża liczba ramek rozgłoszeniowych, zmieniające się odwzorowania MAC i niestabilne łącza wskazują na pętlę lub nieprawidłowo okablowaną redundancję. Przed zmianą kolejnych filtrów należy odłączyć drugą ścieżkę. Następnie trzeba sprawdzić jako całość STP przełączników, STP systemu SFOS, okablowanie HA oraz rzeczywiste interfejsy składowe bridge.

Architektura HA nie może zakładać, że zapora będzie równocześnie korzystać z własnej opcji STP. Jeśli za zapobieganie pętlom odpowiadają przełączniki, test przełączenia awaryjnego musi wykazać, że nie powstaje ani pętla, ani trwale zablokowana produkcyjna ścieżka danych.

Do szczegółowego przyporządkowania interfejsu, Rule ID, Status i Reason można dodatkowo użyć procedury opisanej w artykule Packet Capture w Sophos Firewall. Pełna procedura odbioru bridge pozostaje jednak opisana na tej stronie.

Zaawansowane opcje w Device Console

Standardową konfigurację należy wykonywać w WebAdmin. Polecenie system bridge udostępnia trzy dodatkowe mechanizmy kontroli. Polecenia te nie zastąpią brakującej reguły zapory ani nie rozwiążą nieprzemyślanej architektury warstwy 2. Przed wprowadzeniem zmian należy zapisać nazwę bridge, nazwę sprzętową, interfejsy składowe, identyfikatory portów, tablicę MAC, ścieżkę administracyjną i bieżący stan w CLI.

Obsługa nieznanego ruchu nieroutowalnego

Opcja bypass-firewall-policy dotyczy nieroutowalnego ruchu bridge, do którego nie zastosowano Security Policy. SFOS rozróżnia wartości dynamic i static. Bieżący stan pokazują polecenia:

system bridge bypass-firewall-policy unknown-network-traffic show dynamic
system bridge bypass-firewall-policy unknown-network-traffic show static

Dostępne działania to allow i drop. Ustawienie allow jawnie przekazuje dany ruch bez zastosowania polityki zapory. Dokumentacja SFOS 22 nie podaje ani wartości domyślnej, ani dokładnego rozróżnienia między dynamic i static. Zmianę należy więc wprowadzać wyłącznie w konkretnym przypadku prowadzonym z pomocą Sophos Support. Następnie trzeba sprawdzić stan w CLI, Packet Capture oraz po jednym dozwolonym i zablokowanym przepływie testowym.

Ten przełącznik nie jest ani funkcją LAN Bypass, ani regułą Stateful Firewall Bypass. Nie aktywuje ścieżki fail-to-wire i nie wyłącza znanego połączenia z inspekcji stanowej.

Precyzyjne konfigurowanie statycznych wpisów MAC

Bridge Forwarding Table zwykle uczy się adresów MAC dynamicznie. Opcja static-entry przypisuje adres MAC na stałe do bridge, interfejsu i portu. Oficjalny wzorzec polecenia wygląda następująco:

system bridge static-entry [add | delete | show] [interface] {interface ID} [bridge name] [Port] {PortID} [macaddr] {MAC Address} [priority] [dynamic | static]

Nawiasy opisują składnię i nie należy kopiować ich do polecenia. Przed użyciem add trzeba sprawdzić rzeczywiste identyfikatory za pomocą show i porównać je z przypisaniami w WebAdmin. Błędny lub nieaktualny wpis może kierować ramki do niewłaściwego portu. Aby wycofać zmianę, należy usunąć za pomocą delete dokładnie ten udokumentowany wpis. Następnie trzeba ponownie przetestować uczenie adresów MAC, ruch w obu kierunkach i dostęp administracyjny.

Limit interfejsów składowych nie jest celem skalowania

Bieżący limit wewnętrzny pokazuje polecenie:

system bridge max_bridge_members show

Device Console przyjmuje dla max_bridge_members wartości od 2 do 256 i udostępnia polecenie reset:

system bridge max_bridge_members set limit <2-256>
system bridge max_bridge_members reset

Dwie oficjalne wartości graniczne nie są ze sobą zgodne, a dokumentacja tego nie wyjaśnia. Pomoc WebAdmin podaje maksymalnie 64 interfejsy składowe, natomiast pomoc Device Console dokumentuje wartości od 2 do 256. Nie opisuje jednak zależności między tymi informacjami. Dlatego na podstawie samego zakresu CLI nie należy uznawać wartości powyżej 64 za dopuszczalną architekturę produkcyjną.

Przed zmianą należy zapisać bieżący stan za pomocą show. Jeśli wcześniej obowiązywała wartość domyślna, powrót do niej wymaga użycia reset. Jeśli ustawiony był własny limit, należy przywrócić dokładnie tę wartość poleceniem set limit <poprzednia wartość>. Na koniec ponowne wykonanie show powinno potwierdzić oczekiwany stan.

Bezpieczne wycofywanie bridge

Przed usunięciem należy udokumentować Object Usage, reguły, NAT, sieci VLAN, DHCP, trasy, hosty, strefy interfejsów składowych i dostęp administracyjny. Najpierw trzeba utworzyć ścieżkę zastępczą i przetestować ją przy użyciu rzeczywistego ruchu. Dopiero potem można usunąć zależności produkcyjne, skasować bridge i w kontrolowany sposób ponownie przypisać interfejsy składowe.

Po wycofaniu bridge trzeba ponownie sprawdzić bramę, DNS, dostęp administracyjny, aplikacje produkcyjne, Firewall Rule ID oraz ścieżkę powrotną. Zmianę można uznać za zakończoną dopiero wtedy, gdy wyniki tych testów odpowiadają udokumentowanemu stanowi początkowemu.

Często zadawane pytania