Prawidłową odpowiedzią jest OSPF, ponieważ właśnie ten protokół należy do rodziny protokołów stanu łącza (link-state) i wykorzystuje algorytm Dijkstry do wyznaczania najkrótszych ścieżek. Każdy router OSPF buduje pełny obraz topologii swojej domeny routingu (tzw. area) na podstawie wymiany informacji o stanie łączy, czyli LSAs (Link-State Advertisements). Na tej podstawie tworzy własną bazę LSDB, a potem samodzielnie przelicza tablicę routingu, uruchamiając SPF (Shortest Path First), czyli właśnie algorytm Dijkstry. Moim zdaniem to jest jeden z kluczowych powodów, dla których OSPF jest tak popularny w sieciach korporacyjnych i operatorskich – daje dużą przewidywalność i kontrolę nad ruchem. W praktyce OSPF stosuje się w średnich i dużych sieciach LAN/WAN, w sieciach kampusowych, w sieciach dostępowych operatorów, a także w środowiskach data center, jeśli nie używamy nowszych rozwiązań typu BGP w spine-leaf. OSPF pozwala dzielić sieć na obszary (area 0 – backbone i obszary podrzędne), co ogranicza rozmiar bazy LSDB i przyspiesza przeliczanie SPF. To jest zgodne z dobrymi praktykami Cisco, Juniper i ogólnie rekomendacjami branżowymi: dla większych środowisk zaleca się protokół link-state zamiast prostego distance-vector. W przeciwieństwie do RIPv2 czy IGRP, OSPF nie rozgłasza całych tablic routingu co określony czas, tylko wysyła aktualizacje przy zmianie stanu łącza, co zmniejsza obciążenie sieci i przyspiesza konwergencję. Dodatkowo można w OSPF precyzyjnie sterować metryką (kosztem) na podstawie przepustowości łącza, co pozwala lepiej wykorzystać szybkie linki. W nowoczesnych projektach sieciowych OSPF jest traktowany jako podstawowy protokół IGP w sieciach IPv4 i IPv6 (OSPFv2 i OSPFv3), jeśli zależy nam na stabilności, skalowalności i deterministycznym działaniu algorytmu wyznaczania tras.
W tym pytaniu kluczowe jest zrozumienie różnicy między protokołami distance-vector a protokołami stanu łącza (link-state). Warunek z treści mówi wyraźnie o znajomości całej topologii sieci i o samodzielnym przeliczaniu tras według algorytmu Dijkstry. To od razu kieruje nas w stronę protokołów link-state, bo tylko one budują pełną mapę sieci w każdym routerze i używają SPF do wyliczania ścieżek. Częsty błąd polega na automatycznym kojarzeniu każdego protokołu dynamicznego routingu z zaawansowanym algorytmem, a to nie jest prawda. RIPv2 jest protokołem typu distance-vector, opartym na bardzo prostym mechanizmie: routery wymieniają między sobą całe tablice routingu w określonych odstępach czasu, a metryką jest liczba przeskoków (hop count). Nie ma tu znajomości pełnej topologii ani algorytmu Dijkstry, jest za to klasyczny Bellmana-Forda i sporo ograniczeń skalowalności. Z mojego doświadczenia RIPv2 używa się dziś głównie w małych, prostych środowiskach albo w labach, żeby pokazać podstawy routingu, a nie w poważnych sieciach produkcyjnych. IGRP z kolei to stary, już dawno wycofany, protokół Cisco, też typu distance-vector. On co prawda używa bardziej rozbudowanej metryki (przepustowość, opóźnienie itd.), ale dalej nie buduje pełnej mapy topologii i nie korzysta z Dijkstry. W praktyce został zastąpiony przez EIGRP, który jest hybrydą, ale i tak nie jest klasycznym protokołem link-state. Czasem uczniowie mylą się, bo widzą „zaawansowane” funkcje IGRP/EIGRP i zakładają, że to musi być Dijkstra, a to po prostu inny model działania. IS-IS jest ciekawym przypadkiem, bo to też protokół stanu łącza i on również korzysta z algorytmu SPF (czyli odmiany Dijkstry). Tu pułapka polega na tym, że pytanie jest często zadawane w kontekście typowych rozwiązań korporacyjnych i kursów opartych na standardach Cisco, gdzie domyślnym wyborem i omawianym szczegółowo protokołem link-state jest OSPF. IS-IS jest bardziej popularny w dużych sieciach operatorskich (ISP), działa trochę inaczej, operuje w warstwie 2 modelu OSI, ma inny sposób podziału na poziomy (level 1/2), ale spełnia tę samą ogólną ideę. W typowych egzaminach technicznych, jeśli nie jest wyraźnie zaznaczone środowisko operatorskie, odpowiedzią oczekiwaną dla algorytmu Dijkstry i znajomości topologii jest właśnie OSPF. Dobrym nawykiem jest więc czytanie słów kluczowych: „link-state”, „SPF”, „LSA”, „LSDB” – to praktycznie zawsze prowadzi do OSPF, a nie do klasycznych protokołów distance-vector.