📬 ISN 250: Dlaczego BGP Flapi przy Wielkich UPDATE? Plus FortiNAC i Multivendor SRv6!

Dlaczego BGP flapi przy dużych UPDATE?

BGP nie flapi bez powodu. Gdy sesja pada regularnie zaraz po przejściu do stanu Established, zanim zaczniesz dzwonić do vendora, sprawdź MTU na ścieżce tranzytowej.

BGP deleguje niezawodny transport do TCP. Podczas handshake'a obie strony negocjują MSS (Maximum Segment Size) na podstawie lokalnego MTU interfejsu:

MSS = MTU interfejsu - 20B (IP) - 20B (TCP)

Problem? MSS jest negocjowany na podstawie lokalnych interfejsów, a nie rzeczywistego MTU całej ścieżki. Małe pakiety – OPEN, KEEPALIVE – przechodzą bez problemu, bo mieszczą się w każdym limicie. Sesja wchodzi w stan Established i wszystko wygląda dobrze.

Kłopoty zaczynają się przy wymianie tablic routingu. BGP pakuje prefiksy z identycznymi atrybutami w jeden UPDATE o wielkości nawet 4096 bajtów. TCP segmentuje ten strumień do wynegocjowanego MSS i wysyła z ustawionym bitem DF. Jeśli którykolwiek węzeł na ścieżce ma niższe MTU i blokuje ICMP Type 3 Code 4 ("Fragmentation Needed"), pakiety są cicho gubione. Router nigdy nie dostaje ACK, UPDATE nie docierają, Hold Timer wygasa.

Efekt: sesja pada dokładnie wtedy, gdy zaczyna się wymiana tras.

Weryfikacja jest prosta – ping z bitem DF i różnymi rozmiarami pakietów:

R1# ping 192.168.10.2 df-bit size 900
Success rate is 0 percent (0/5)

R1# ping 192.168.10.2 df-bit size 800
Success rate is 100 percent (5/5)

Negocjowany MSS możesz sprawdzić bez Wiresharka, bezpośrednio z CLI:

R1# sh ip bgp neighbors 192.168.10.2 | i Data
Datagrams (max data segment is 860 bytes)

Jeśli wartość MSS przekracza rzeczywisty limit ścieżki – masz przyczynę problemu.

Natychmiastowe obejście to wymuszenie niższego MSS dla sesji BGP:

R1(config)# ip tcp mss 760

Wartość dobierasz tak, żeby TCP segment + nagłówki IP/TCP zmieściły się w rzeczywistym MTU ścieżki. Po zmianie sesja stabilizuje się natychmiast.

Pamiętaj jednak: to jest workaround dla control plane, nie rozwiązanie systemowe. Ruch data plane nadal może być cicho gubiony, jeśli klienci wysyłają duże pakiety z DF=1. Docelowo musisz wyrównać MTU na całej ścieżce lub wdrożyć PMTUD.

Ten problem jest szczególnie podstępny w środowiskach Multisite VXLAN EVPN – Underlay eBGP (wymiana adresów loopback) działa stabilnie, bo pakiety są małe. EVPN BGP synchronizujący MAC/IP routes pada natychmiast po Established z powodu identycznego mechanizmu.

FortiNAC w praktyce

Większość materiałów szkoleniowych tłumaczy czym jest NAC. Niemal żaden nie pokazuje, jak przejść od zera do działającego środowiska — bez pomijania niewygodnych szczegółów.

FortiNAC nie operuje na VLAN-ach bezpośrednio. Operuje na logical networks — nazwanych abstrakcjach, które dopiero na poziomie konkretnego urządzenia mapujesz do VLAN ID. Praktyczna konsekwencja: masz 20 lokalizacji z różnymi numerami VLAN-ów dla sieci klienckiej? Jedna polityka w FortiNAC, dwadzieścia różnych mapowań. Brak duplikacji logiki, brak ryzyka rozbieżności.

Mechanizm działa przez trzy warstwy: rola → user host profile → network access policy. Rola jest przypisana do urządzenia (ręcznie lub przez device profiling). Profil definiuje warunki dopasowania. Polityka łączy profil z konfiguracją sieciową. Jeśli ta hierarchia jest jasna, reszta konfiguracji jest już tylko klikaniem.

Device profiling zamiast ręcznej rejestracji

Headless devices to klasyczny problem w środowiskach NAC. FortiNAC rozwiązuje go przez reguły profilowania — urządzenie podłącza się, system identyfikuje je na podstawie vendor OUI, nazwy hosta, odpowiedzi SSH lub innych atrybutów, automatycznie przypisuje rolę i rejestruje w bazie hostów.

Kilka rzeczy wartych zapamiętania przy konfiguracji:

Vendor OUI daje precyzję, której nie zapewni sama nazwa producenta (Samsung Electronics to za szeroka kategoria)
Opcja "confirm rule on connect" wystarczy w większości przypadków — polling interwałowy to overhead dla stabilnych środowisk
Testowanie reguł działa na już podłączonych urządzeniach przez "test device profiling rule" na adapterze, zanim wdrożysz to produkcyjnie

RADIUS i 802.1X — szczegóły, które kosztują godziny

FortiNAC jako RADIUS server wymaga certyfikatu dla EAP. Generujesz CSR bezpośrednio z GUI (System → Certificate Management), podpisujesz w CA, importujesz z prywatnym kluczem z ostatniego wygenerowanego CSR. Standardowe kroki — ale łatwo przeoczyć, że trusted certificate root CA musi być osobno zaimportowany do sekcji "Trusted Certificates", inaczej walidacja łańcucha certyfikatów się nie powiedzie.

Dla autoryzacji 802.1X kluczowy jest atrybut TLS client issuer — nie zgadujesz go, tylko czytasz z logów serwisowych. Włącz "service debug log" w sekcji RADIUS, spróbuj połączyć klienta, skopiuj string z logu i zbuduj na nim user host profile. Szybsze niż przeglądanie dokumentacji PKI.

Na FortiGate nie zapomnij o COA (Change of Authorization) w konfiguracji serwera RADIUS — bez tego dynamiczne zmiany VLAN nie zadziałają. Przy 802.1X na switchach FortiLink: polityka portów wymaga jawnie zaznaczonego "authentication bypass" i "EAP pass-through", bo inaczej urządzenia bez 802.1X (drukarki, telefony) będą odcinane, zamiast przechodzić do MAC auth fallback.

Multivendor lab SRv6

Zestaw praktycznych laboratoriów SRv6 dla Containerlab, obejmujący podstawy SRv6 oraz migrację SR-MPLS do SRv6 L3VPN na urządzeniach Nokia, Cisco i Juniper. Repozytorium zawiera topologie Containerlab i konfiguracje urządzeń, które po dodaniu własnych obrazów i licencji vendorów uruchamiają się bez dodatkowych zmian. Laboratoria pokazują kompletne rozwiązania: podkład IS-IS SRv6 z locatorami i End SID-ami, SRv6 L3VPN (End.DT4 / End.DT6) działający w rdzeniu IPv6-only oraz migrację L3VPN ze SR-MPLS do SRv6 bez przerw w działaniu usługi.

Monotring homelab-a

NetAlertX to platforma do monitoringu sieci i inteligencji zasobów, przeznaczona dla homelabów, zespołów IT, MSP oraz rozproszonych środowisk. Umożliwia centralny podgląd urządzeń i ciągłe wykrywanie zasobów w wielu lokalizacjach, VLANach i segmentach sieci z poziomu jednego interfejsu. Pomaga wykryć nieautoryzowany sprzęt i tzw. shadow IT, wspiera zgodność z regulacjami oraz automatyzuje procesy operacyjne dzięki integracjom, powiadomieniom i workflowom. Dzięki obsłudze wielu metod skanowania i synchronizacji między lokalizacjami jest dobrym wyborem dla MSP oraz zespołów zarządzających złożonymi sieciami rozproszonymi.

Prompt engineering dla sieciowców

Przeczytaj całą historię

Zarejestruj się teraz, aby przeczytać całą historię i uzyskać dostęp do wszystkich postów za tylko dla płacących subskrybentów.

Subskrybuj

Masz już konto? Zaloguj się