problematyczna sesja w OSPFv3

Co jest więc dodatkowo potrzebne, aby zestawić sesję między R1, a R2?

Nic nie jest potrzebne. Sesja OSPFv3 zestawi się pomimo tego, że bezpośrednio połączone interfejsy nie należą do tej samej podsieci. Dlaczego? Otóż informacja o masce nie jest przesyłana w pakiecie Hello. RFC5340 wyraża to następująco:

The Hello packet no longer contains an IP network mask since OSPF for IPv6 runs per-link instead of per-subnet.

OSPFv3 upodabnia się tym samym do protokołu ISIS, gdzie topologia budowana jest niezależnie od adresacji IP. W dalszym ciągu w OSPFv3 sesja musi być zestawiona po IP, gdyż jest to protokół IP. Nie ma wyjścia. Jednak do tego celu wykorzystuje się symboliczną reprezentację linku, czyli adresy IPv6 link-local, które nie posiadają maski. Prefiksy globalne w OSPFv3 oraz ISIS są dołączone do topologii, niczym liście do drzewa. Prefiksy nie są odpowiedzialne za zestawianie połączeń tranzytowych. Zatem zmiany w adresacji globalnej nie powodują przebudowy topologii, co w pewnych sytuacjach przyspiesza konwergencję. Nie można również dokonać ataku multi-hop na topologię sieci, gdyż adresy link-local nie są ani widoczne, ani rutowalne z zewnątrz.

Warto też pamiętać, że OSPFv3 jest multiprotocol. Oznacza to, że można pod jednym procesem uruchomić stos IPv4, jak i IPv6. Zestawione zostaną po dwie sesje na każdym łączu. Dla sesji IPv4 wciąż potrzebna jest adresacja IPv4. Powracamy tym samym do wad i zalet stosu IPv4 w OSPF.

Ciekawą uwagę przekazał kiedyś Damian Kuczyński z zaprzyjaźnionej firmy na temat masek w OSPFv3. Otóż wyraził on opinię, że brak uwzględnienia masek przy zestawianiu sesji może prowadzić do nierozpoznanych pomyłek w topologii. Może się to zdarzyć w sytuacji, gdy podczas okna serwisowego technicy przypadkiem zamienią dwa światłowody miejscami w danym urządzeniu. Wówczas router będzie miał sesje OSPFv3 z sąsiadami nie na tych interfejsach co trzeba. Wydaje się, że to nic wielkiego, o ile konfiguracja routingu, QoS, ACL itp. jest symetryczna. Gorzej, gdy symetryczna nie jest. Dodałbym też przypadek z VRF, który może prowadzić do niezamierzonego leakingu. Standardowo w OSPFv2 sesje pozostaną nieaktywne i będzie można łatwo zidentyfikować pomyłkę łączy. Sytuację może ratować zastosowanie uwierzytelniania dla każdego VRF lub grupy funkcjonalnej. Nie zawsze jest to opcja do użycia. Zatem odpowiedni monitoring z rozpoznawaniem zmiany sąsiadów byłby na plus, o czym warto pamiętać wdrażając OSPFv3.

Facebooktwittergoogle_plusredditpinterestlinkedinmail
This entry was posted in Uncategorized. Bookmark the permalink.