Router podejmuje decyzję o przekazaniu pakietu na podstawie analizy nagłówka IP – odczytuje adres docelowy i porównuje go z wpisami w tablicy routingu. Proces ten nazywany jest przeszukiwaniem tablicy routingu i jest wykonywany dla każdego pakietu osobno, chyba że wykorzystywana jest sprzętowa pamięć podręczna FIB. W nowoczesnych routerach lookup jest realizowany przez dedykowane układy ASIC z wbudowanymi pamięciami TCAM, które umożliwiają przeszukiwanie tablicy w czasie stałym. RIB przechowuje wszystkie trasy poznane przez router, podczas gdy FIB zawiera tylko te najlepsze, aktywne wpisy gotowe do użycia przez warstwę przekazywania pakietów.

Routing statyczny daje administratorowi pełną kontrolę nad ścieżkami, ale wymaga ręcznego zarządzania przy każdej zmianie topologii. W przeciwieństwie do protokołów dynamicznych, trasy statyczne nie generują żadnego ruchu sieciowego ani narzutu obliczeniowego. Ich przewidywalność sprawia, że są idealne dla sieci o stabilnej topologii i małej liczbie routerów. W większych sieciach routing statyczny jest zwykle stosowany tylko do definiowania tras domyślnych i specjalnych tras zarządczych, podczas gdy główny routing odbywa się z wykorzystaniem protokołów dynamicznych, takich jak OSPF czy BGP.

Struktura prezentacji została zaprojektowana tak, aby stopniowo budować wiedzę od podstaw tablicy routingu przez źródła tras aż po praktyczną konfigurację. Każdy blok tematyczny opiera się na poprzednim – znajomość budowy wpisu trasy jest niezbędna do zrozumienia mechanizmu wyboru najlepszej ścieżki. Odległość administracyjna i metryki to kluczowe pojęcia, które decydują o tym, która trasa trafia do FIB i jest używana do przekazywania pakietów.

Routing statyczny został omówiony jako pierwszy z typów routingu, ponieważ stanowi najprostszy i najbardziej intuicyjny mechanizm definiowania ścieżek. Zrozumienie go jest warunkiem koniecznym przed przejściem do protokołów dynamicznych, które automatyzują proces wymiany informacji o sieciach. W dalszej części prezentacji znajdują się praktyczne przykłady konfiguracji na platformach Cisco i RouterOS wraz z procedurami weryfikacji i diagnozowania problemów. Całość wieńczy podsumowanie najważniejszych zasad i dobrych praktyk projektowania sieci z użyciem routingu statycznego.

Router bez tablicy routingu jest w stanie przekazywać pakiety wyłącznie do sieci bezpośrednio podłączonych, ponieważ tylko dla nich posiada wpisy connected. Każdy pakiet adresowany do sieci zdalnej musi zostać odrzucony z komunikatem ICMP Destination Unreachable, co w praktyce oznacza brak łączności między segmentami sieci. Tablica routingu jest przechowywana w pamięci RAM i może zawierać od kilku do kilkuset tysięcy wpisów w zależności od klasy urządzenia i złożoności sieci.

Proces wyszukiwania najdłuższego pasującego prefiksu wymaga odpowiednio zaprojektowanej struktury danych, aby był wykonywany w czasie akceptowalnym dla wydajnej pracy routera. W nowoczesnych routerach warstwa sprzętowa wykorzystuje pamięć TCAM, która pozwala na równoległe porównywanie wszystkich wpisów w jednym cyklu zegara. W przypadku małych routerów programowych lookup jest realizowany przez procesor główny z wykorzystaniem struktur drzewiastych (trie). Niezależnie od implementacji, podstawowa zasada pozostaje niezmienna – bez dopasowania w tablicy routingu pakiet nie może zostać przekazany dalej.

RIB pełni funkcję centralnego repozytorium wszystkich tras, które router kiedykolwiek poznał – zarówno tych aktywnych, jak i nieaktywnych. Gdy protokół routingu dynamicznego, taki jak OSPF, odkryje nową trasę, zapisuje ją w RIB wraz z metadanymi, takimi jak znacznik czasu poznania i identyfikator procesu. RIB może zawierać wiele tras do tej samej sieci docelowej, pochodzących z różnych źródeł – tylko jedna z nich po przejściu procesu selekcji trafi do FIB.

W routerach Cisco RIB jest zarządzana przez proces routingu Cisco IOS, który agreguje trasy z wszystkich aktywnych protokołów routingu. Proces selekcji rozpoczyna się od porównania długości prefiksu, następnie AD, a na końcu metryki. Trasy, które nie wygrały rywalizacji, pozostają w RIB jako nieaktywne i mogą zostać użyte natychmiast po awarii trasy głównej. Zapewnia to szybkie przełączanie bez konieczności ponownego poznawania trasy przez protokół routingu. Mechanizm ten jest szczególnie istotny w sieciach wymagających wysokiej dostępności i krótkiego czasu konwergencji.

FIB jest strukturą danych zoptymalizowaną pod kątem szybkiego przekazywania pakietów – zawiera wyłącznie najlepsze trasy wybrane z RIB. W routerach Cisco mechanizm CEF tworzy dwie struktury: FIB (Forwarding Information Base) i Adjacency Table. FIB zawiera informacje o sieciach docelowych i next-hopach, natomiast Adjacency Table przechowuje gotowe nagłówki warstwy łącza danych dla każdego sąsiedniego urządzenia. Dzięki temu router nie musi wykonywać zapytania ARP ani obliczać nagłówka ramki dla każdego pakietu.

W platformach MikroTik mechanizmem odpowiadającym CEF jest fast-path, który po pierwszym pakiecie w strumieniu przełącza dalsze pakiety do szybkiej ścieżki w jądrze systemu. W RouterOS w wersji 7 wprowadzono dodatkowe optymalizacje dla wielordzeniowych procesorów, co znacząco poprawiło wydajność routingu na urządzeniach z wieloma interfejsami. FIB jest aktualizowany dynamicznie za każdym razem, gdy zmienia się stan tras w RIB – zmiana jest propagowana w czasie rzeczywistym bez konieczności restartowania procesów. W praktyce oznacza to, że awaria łącza i przełączenie na trasę zapasową są obsługiwane w milisekundach, o ile mechanizm CEF jest włączony i poprawnie skonfigurowany.

Każdy element wpisu trasy pełni określoną funkcję w procesie podejmowania decyzji o przekazaniu pakietu. Adres sieci docelowej wraz z maską definiuje zakres adresów IP, do których wpis ma zastosowanie – im dłuższa maska, tym bardziej specyficzny wpis. Next-hop to adres IP następnego routera, który wie, jak dalej przekazać pakiet w kierunku celu. Interfejs wyjściowy określa fizyczny lub logiczny port, przez który pakiet opuści router.

Odległość administracyjna (AD) jest przypisana do źródła trasy, a nie do samej trasy – na przykład wszystkie trasy statyczne mają domyślnie AD równe 1. Metryka natomiast jest specyficzna dla protokołu routingu: OSPF używa kosztu obliczanego na podstawie przepustowości łącza, RIP stosuje liczbę skoków (hop count), a EIGRP wykorzystuje złożoną metrykę uwzględniającą przepustowość, opóźnienie, obciążenie i niezawodność. Źródło trasy (connected, static, OSPF, RIP, BGP) determinuje wartość AD oraz sposób, w jaki trasa jest utrzymywana i odświeżana w tablicy.

Każde źródło tras ma swoje unikalne cechy, które wpływają na sposób zarządzania siecią. Trasy connected są generowane automatycznie i nie wymagają żadnej interwencji administratora – pojawiają się w tablicy natychmiast po skonfigurowaniu adresu IP i włączeniu interfejsu. Trasy statyczne dają administratorowi pełną kontrolę, ale obciążają go obowiązkiem aktualizacji przy każdej zmianie topologii. Protokoły dynamiczne automatyzują wykrywanie zmian, ale wprowadzają narzut komunikacyjny i obliczeniowy.

W praktyce sieciowej rzadko stosuje się tylko jeden typ źródła tras – najczęściej są one łączone. Na przykład router dostępowy może mieć trasę domyślną statyczną do ISP, trasy connected dla sieci lokalnych oraz trasy OSPF dla sieci wewnętrznych w organizacji. Kluczową umiejętnością administratora jest poprawne skonfigurowanie wartości AD tak, aby żądane źródło tras miało zawsze pierwszeństwo. W przypadku remisu AD (dwie trasy z tego samego źródła) o wyborze decyduje metryka, a jeśli i ta jest równa, router może równoważyć obciążenie między nimi (load balancing).

Trasy connected są generowane automatycznie w momencie dodania adresu IP do interfejsu i wysłania komendy no shutdown. Router tworzy dwa wpisy: jeden dla samej sieci (oznaczony kodem C) i drugi dla adresu lokalnego interfejsu (oznaczony kodem L – local). Wpis local ma maskę /32 i służy do kierowania pakietów adresowanych bezpośrednio do interfejsu routera. Oba wpisy mają AD równe 0, co oznacza absolutny priorytet nad wszystkimi innymi źródłami.

Nie można ręcznie usunąć trasy connected – zniknie ona automatycznie dopiero po usunięciu konfiguracji IP z interfejsu lub wyłączeniu interfejsu komendą shutdown. W RouterOS trasy connected są oznaczane flagą C i również mają distance 0. Warto zauważyć, że trasy connected nie są propagowane przez protokoły routingu dynamicznego – aby poinformować innych routerów o sieci podłączonej, należy użyć odpowiedniej komendy w kontekście protokołu (np. network w OSPF lub redystrybucji tras connected).

Trasy statyczne są podstawowym narzędziem każdego administratora sieci, używanym zarówno w małych, jak i dużych środowiskach. Nawet w rozbudowanych sieciach korporacyjnych, gdzie główny routing odbywa się dynamicznie, trasy statyczne są niezbędne do definiowania tras domyślnych do ISP, tras do sieci zarządczych (management) oraz tras do pętli zwrotnych (loopback). W Cisco komenda ip route pozwala również na określenie dodatkowych parametrów, takich jak permanent (trasa pozostaje w tablicy nawet gdy interfejs jest down) czy tag (używany do filtrowania tras podczas redystrybucji).

Administrator powinien zawsze weryfikować, czy next-hop trasy statycznej jest osiągalny – jeśli nie, trasa nie pojawi się w tablicy routingu jako aktywna. W RouterOS mechanizm gateway-status pozwala na monitorowanie stanu bramy i automatyczne wyłączenie trasy, gdy brama przestaje być dostępna. W przypadku tras statycznych z interfejsem point-to-point (Serial, PPP) next-hop można pominąć, ponieważ router wie, że jedynym możliwym celem jest drugi koniec łącza. Trasy statyczne są również wykorzystywane w scenariuszach blackhole, gdzie ruch do określonej sieci jest celowo odrzucany na routerze bez generowania komunikatu ICMP.

Protokoły routingu dynamicznego różnią się nie tylko mechanizmem wymiany informacji, ale także szybkością konwergencji, skalowalnością i obszarem zastosowania. OSPF jest protokołem link-state, który po ustabilizowaniu się sieci utrzymuje pełną bazę danych stanu łączy (LSDB) i na jej podstawie oblicza najkrótsze ścieżki algorytmem Dijkstry. RIP to klasyczny protokół distance vector, który domyślnie wysyła pełną tablicę routingu do sąsiadów co 30 sekund, ale obsługuje również wymuszone aktualizacje (triggered updates) – jest prosty, ale nieefektywny w dużych sieciach ze względu na ograniczenie do 15 skoków.

BGP jest protokołem ścieżkowym (path vector) używanym w rdzeniu Internetu do wymiany tras między autonomicznymi systemami (AS). W przeciwieństwie do OSPF i RIP, BGP nie używa prostej metryki, lecz zestawu atrybutów (AS_PATH, LOCAL_PREF, MED, WEIGHT) do wyboru najlepszej ścieżki. EIGRP jest protokołem hybrydowym opracowanym przez Cisco, łączącym cechy distance vector i link-state – używa złożonej metryki i zapewnia bardzo szybką konwergencję dzięki mechanizmowi Diffusing Update Algorithm (DUAL). Wybór odpowiedniego protokołu zależy od wielkości sieci, wymagań dotyczących konwergencji i używanej platformy sprzętowej.

Odległość administracyjna jest mechanizmem charakterystycznym dla routerów – w czystych przełącznikach warstwy 2 nie występuje. Każdy producent sprzętu sieciowego ustala własne domyślne wartości AD, które mogą się różnić od standardowych wartości Cisco. Na przykład w routerach Juniper trasy statyczne mają domyślnie AD równe 5, a w systemach Linux wartość metric w tablicy routingu pełni funkcję zbliżoną do AD. W Cisco wartości AD można modyfikować dla poszczególnych protokołów za pomocą komendy distance w trybie konfiguracji procesu routingu.

Możliwość zmiany domyślnych wartości AD daje administratorowi ogromną elastyczność w projektowaniu polityk routingu. Na przykład można skonfigurować trasę statyczną z AD 150, aby była używana tylko wtedy, gdy trasa OSPF (AD 110) nie jest dostępna – odwrotność standardowego zachowania. W RouterOS modyfikacja distance jest jeszcze prostsza, ponieważ każda trasa statyczna może mieć indywidualnie ustawioną wartość distance. Należy jednak pamiętać, że zmiana domyślnych wartości AD może prowadzić do nieoczekiwanego zachowania routingu, jeśli nie jest dokładnie przemyślana i udokumentowana. W sieciach z redystrybucją tras między protokołami należy zachować szczególną ostrożność przy modyfikacji AD, aby uniknąć pętli routingu.

W RouterOS odległość administracyjna nazywana jest distance i jest atrybutem każdej trasy, który może być ustawiony niezależnie dla poszczególnych wpisów. Domyślne wartości distance w RouterOS są zgodne ze standardem Cisco: connected – 0, static – 1, OSPF – 110, RIP – 120, BGP – 20 dla eBGP i 200 dla iBGP. Dodatkowo RouterOS wprowadza distance 1 dla tras pochodzących z DHCP, co jest istotną różnicą w porównaniu z Cisco, gdzie interfejs DHCP nie generuje automatycznie trasy statycznej.

Elastyczność RouterOS w zakresie distance pozwala na implementację zaawansowanych scenariuszy bez użycia protokołów dynamicznych. Na przykład można skonfigurować trzy trasy domyślne z distance 1, 5 i 10 do różnych dostawców ISP, tworząc hierarchię failover. RouterOS obsługuje również mechanizm recursive next-hop, który umożliwia wskazanie jako bramy adresu, który nie jest bezpośrednio podłączony – router samodzielnie znajdzie trasę do tego adresu. W WinBox i WebFig administrator ma wgląd w pełną tablicę routingu z kolorowym oznaczeniem aktywnych i nieaktywnych tras, co ułatwia diagnozowanie problemów z łącznością.

Trójstopniowy algorytm wyboru najlepszej trasy jest fundamentalną zasadą routingu IP, która obowiązuje niezależnie od platformy sprzętowej. Pierwszym i najważniejszym krokiem jest znalezienie wszystkich wpisów w tablicy, których zakres adresowy zawiera adres docelowy pakietu. Spośród tych wpisów router wybiera ten z najdłuższym prefiksem, czyli najbardziej specyficznym dopasowaniem. Dopiero gdy dwa wpisy mają identyczną długość prefiksu, router porównuje ich odległość administracyjną – wygrywa wpis z niższym AD.

Jeśli po porównaniu AD nadal istnieje remis (dwie trasy z tego samego źródła o tej samej długości prefiksu), router analizuje metrykę. W przypadku równej metryki router może zastosować równoważenie obciążenia (ECMP – Equal Cost Multi-Path), rozdzielając ruch między wszystkie dostępne ścieżki. W Cisco maksymalna liczba ścieżek ECMP zależy od platformy – zwykle 4 lub 8, a w RouterOS domyślnie 16. Algorytm ten jest wykonywany dla każdego pakietu w przypadku routingu procesorowego (process switching), ale przy użyciu CEF wyniki są przechowywane w pamięci podręcznej i używane dla całego strumienia pakietów.

Longest Prefix Match (LPM) jest algorytmem, który zapewnia, że najbardziej precyzyjna trasa jest zawsze wykorzystywana do przekazywania pakietu. W przykładzie z trasami 10.0.0.0/8 i 10.1.0.0/16 dla adresu 10.1.1.5, pierwsze 8 bitów pasuje do obu tras, ale trasa /16 wymaga dopasowania 16 bitów, podczas gdy /8 tylko 8. Ponieważ trasa /16 jest bardziej restrykcyjna, zostaje wybrana przez router. Mechanizm ten działa niezależnie od wartości AD i metryki – najdłuższy prefiks ma zawsze absolutne pierwszeństwo.

W praktyce oznacza to, że można tworzyć bardzo specyficzne trasy (np. /32 dla pojedynczego hosta), które będą nadpisywać bardziej ogólne wpisy. Jest to często wykorzystywane w scenariuszach traffic engineering, gdzie ruch do konkretnego serwera ma być kierowany inną ścieżką niż ogólny ruch do całej podsieci. W routerach Cisco i RouterOS najdłuższy prefiks jest obliczany automatycznie na podstawie maski sieci podanej przy konfiguracji trasy. Administrator musi jedynie pamiętać, że zbyt ogólna maska może spowodować kierowanie ruchu niewłaściwą ścieżką, a zbyt specyficzna może niepotrzebnie zwiększać rozmiar tablicy routingu.

Polecenie show ip route jest podstawowym narzędziem diagnostycznym każdego administratora sieci Cisco. Wynik tego polecenia można filtrować na wiele sposobów – show ip route static wyświetla tylko trasy statyczne, show ip route ospf tylko trasy OSPF, a show ip route connected tylko trasy bezpośrednio podłączone. Istnieje również możliwość wyświetlenia podsumowania liczby tras według protokołów za pomocą show ip route summary, co jest przydatne przy diagnozowaniu problemów z nadmierną liczbą tras.

W przypadku podejrzenia problemów z routingiem warto użyć show ip route <adres>, który pokazuje nie tylko pasującą trasę, ale także informacje o tym, jak długo trasa jest znana routerowi i przez jaki protokół została poznana. Polecenie debug ip routing włącza szczegółowe logowanie zdarzeń związanych z tablicą routingu, takie jak dodawanie, usuwanie i modyfikacja tras. Należy jednak używać go ostrożnie w środowisku produkcyjnym, ponieważ może generować dużą ilość komunikatów i obciążać procesor routera. W RouterOS odpowiednikiem jest /ip route print detail oraz /log print dla zdarzeń routingu.

Szczegółowa analiza wpisu w tablicy routingu pozwala na szybkie zlokalizowanie wielu problemów sieciowych. Znacznik czasu w trasach OSPF wskazuje, kiedy trasa została ostatnio poznana lub zaktualizowana – jeśli zmienia się on często (co kilka sekund), jest to typowy objaw fluktuacji trasy (route flapping). Fluktuacja może być spowodowana niestabilnym łączem, błędną konfiguracją interfejsu lub problemami z synchronizacją bazy danych OSPF.

Aby zdiagnozować route flapping na routerze Cisco, można użyć polecenia show ip ospf neighbor do sprawdzenia stanu sąsiedztwa oraz show interfaces do weryfikacji błędów na interfejsie. W RouterOS pomocne będą /ip route print detail i /log print where topics~"route". W przypadku wykrycia fluktuacji należy sprawdzić fizyczne łącze, skorygować ewentualne błędy konfiguracji oraz rozważyć zastosowanie mechanizmów stabilizujących, takich jak timery OSPF (hello/dead interval) czy route dampening w BGP. Długotrwała fluktuacja może prowadzić do niestabilności całej sieci i zwiększonego obciążenia procesorów routerów.

Trasa domyślna o adresie 0.0.0.0/0 jest fundamentem łączności z Internetem dla każdej sieci lokalnej. Gdy router otrzymuje pakiet adresowany do sieci, której nie ma w swojej tablicy routingu, sprawdza, czy istnieje trasa domyślna – jeśli tak, pakiet jest przekazywany zgodnie z jej next-hopem. Jeśli trasa domyślna nie istnieje, pakiet jest odrzucany, a nadawca otrzymuje komunikat ICMP Destination Unreachable. W sieciach korporacyjnych często stosuje się wiele tras domyślnych do różnych dostawców ISP w celu zapewnienia redundancji.

Konfiguracja trasy domyślnej różni się w zależności od platformy, ale zasada jest zawsze taka sama. W Cisco komenda ip route 0.0.0.0 0.0.0.0 next-hop tworzy trasę domyślną o AD 1. W RouterOS można użyć /ip route add gateway=next-hop z pominięciem dst-address, co automatycznie ustawi trasę domyślną. W systemach Linux trasa domyślna jest dodawana komendą ip route add default via next-hop. Niezależnie od platformy, trasa domyślna powinna wskazywać na adres IP routera dostawcy usług internetowych (ISP), który wie, jak kierować ruchem w Internecie.

Polecenie /ip route print w RouterOS wyświetla tablicę routingu w formie tabeli, gdzie każdy wiersz reprezentuje jedną trasę z zestawem flag określających jej stan. Flagi tras w RouterOS to kombinacje liter: A (active – trasa używana), C (connect – trasa bezpośrednio podłączona), S (static – trasa statyczna), D (dynamic – trasa dodana automatycznie, np. przez DHCP). Dodatkowe flagi to r (rip – trasa poznana przez RIP) i b (bgp – trasa poznana przez BGP).

Wynik /ip route print można filtrować na wiele sposobów, co czyni to polecenie bardzo elastycznym narzędziem diagnostycznym. Na przykład /ip route print where static and active wyświetli tylko aktywne trasy statyczne, a /ip route print where distance=1 pokaże trasy z distance równym 1. RouterOS oferuje opcję /ip route print terse wyświetlającą tablicę w zwięzłym formacie, co ułatwia szybkie diagnozowanie. Dla administratorów przyzwyczajonych do Cisco RouterOS oferuje również widok szczegółowy /ip route print detail, który dodaje kolumny z parametrami scope, target-scope, routing-mark i komentarzami.

Porównanie Cisco i RouterOS pokazuje, że mimo różnic w interfejsie użytkownika i składni poleceń, obie platformy realizują te same funkcje routingu w oparciu o identyczne zasady. Cisco IOS stosuje hierarchiczny system konfiguracji z trybami (tryb uprzywilejowany, tryb konfiguracji globalnej, tryb konfiguracji interfejsu), podczas gdy RouterOS używa płaskiego systemu poleceń z hierarchią menu. Różnica ta wpływa na sposób, w jaki administratorzy uczą się i stosują obie platformy – Cisco wymaga zrozumienia struktury trybów, RouterOS znajomości ścieżek menu.

W praktyce administracyjnej często spotyka się środowiska mieszane, gdzie routery Cisco są używane w rdzeniu sieci, a urządzenia MikroTik na obrzeżach lub w małych oddziałach. Umiejętność konfiguracji obu platform jest cenną kompetencją na rynku pracy. Narzędzia takie jak WinBox dla RouterOS i Packet Tracer dla Cisco znacznie ułatwiają naukę i konfigurację, oferując graficzne interfejsy z podglądem konfiguracji w czasie rzeczywistym. Niezależnie od platformy, podstawowe pojęcia – RIB, FIB, AD, metryka, najdłuższy prefiks – pozostają takie same, co ułatwia przejście między różnymi systemami operacyjnymi routerów.

Scenariusz z dwiema trasami do tej samej sieci jest codziennością w sieciach korporacyjnych i operatorskich. Mechanizm wyboru na podstawie AD pozwala na stworzenie hierarchii tras bez konieczności stosowania zaawansowanych protokołów dynamicznych. W przykładzie z trasą statyczną (AD 1) i OSPF (AD 110) do 10.2.0.0/16, router zawsze będzie preferował trasę statyczną. Gdy interfejs, przez który prowadzi trasa statyczna, ulegnie awarii, trasa zostanie usunięta z FIB, a OSPF automatycznie przejmie ruch.

Warto zauważyć, że router nie sprawdza okresowo, czy trasa statyczna jest nadal użyteczna – zakłada, że administrator skonfigurował ją prawidłowo. Jeśli next-hop trasy statycznej stanie się nieosiągalny z powodu awarii gdzieś dalej w sieci (nie na bezpośrednim łączu), router nie przełączy się automatycznie na trasę OSPF. W takich przypadkach pomocne są mechanizmy takie jak IP SLA w Cisco lub netwatch w RouterOS, które monitorują osiągalność zdalnych celów i mogą wpływać na aktywność tras statycznych. Projektując sieć z routingu statycznym, należy zawsze uwzględnić te ograniczenia i przewidzieć odpowiednie mechanizmy monitorujące.

Zasada pierwszeństwa najdłuższego prefiksu przed AD i metryką jest kluczowa dla zrozumienia, jak router podejmuje decyzje. W przykładzie z trasą A (10.0.0.0/8, AD 110) i trasą B (10.1.1.0/24, AD 1) dla pakietu do 10.1.1.5, obie trasy pasują do adresu docelowego. Trasa A pasuje w 8 bitach, trasa B w 24 bitach – ponieważ 24 > 8, router wybiera trasę B, nawet gdyby trasa B miała dużo wyższe AD. Gdyby obie trasy miały tę samą długość prefiksu, wtedy AD zdecydowałoby o wyborze.

Zasada ta ma istotne implikacje praktyczne. Administrator może tworzyć bardzo specyficzne trasy statyczne o wysokim AD, które będą używane tylko dla konkretnych podsieci, podczas gdy ogólny ruch będzie kierowany trasami dynamicznymi o niższym AD. Jest to często wykorzystywane w scenariuszach traffic steering, gdzie ruch do określonej aplikacji lub serwisu ma być kierowany dedykowaną ścieżką. W RouterOS można dodatkowo użyć mechanizmu routing-mark do tworzenia zaawansowanych polityk routingu, gdzie wybór trasy zależy nie tylko od adresu docelowego, ale także od innych kryteriów, takich jak adres źródłowy czy interfejs wejściowy.

Decyzja o zastosowaniu routingu statycznego zależy od wielu czynników, które administrator musi przeanalizować przed wyborem strategii routingu. Podstawowym kryterium jest rozmiar sieci – dla sieci złożonych z 2–5 routerów routing statyczny jest w pełni wystarczający i często bardziej efektywny niż wdrażanie protokołu dynamicznego. Kolejnym czynnikiem jest stabilność topologii – jeśli sieć nie zmienia się często, routing statyczny eliminuje narzut związany z konwergencją i aktualizacją tras.

Routing statyczny sprawdza się również doskonale w scenariuszach, gdzie wymagana jest pełna kontrola nad ścieżką ruchu, takich jak sieci zarządcze (OOB management), pętle zwrotne (loopback) do identyfikacji routera, czy trasy blackhole do celowego odrzucania ruchu. W sieciach operatorskich i dużych korporacjach routing statyczny jest stosowany uzupełniająco do protokołów dynamicznych – na przykład do definiowania tras domyślnych z Internetu do sieci wewnętrznej. W takich przypadkach trasa statyczna jest redystrybuowana do protokołu dynamicznego (np. OSPF), aby poinformować inne routery wewnętrzne o istnieniu wyjścia do Internetu.

Analiza zalet i wad routingu statycznego pozwala administratorowi świadomie wybrać odpowiednią strategię routingu dla swojej sieci. Główną zaletą routingu statycznego jest prostota – każda trasa jest jawnie zdefiniowana, co ułatwia diagnozowanie problemów i przewidywanie zachowania sieci. Brak narzutu komunikacyjnego oznacza, że trasy statyczne nie zużywają pasma ani mocy obliczeniowej procesora, co jest istotne w przypadku starszych lub mniej wydajnych routerów. Przewidywalność routingu statycznego sprawia, że jest on często wymagany w sieciach o ścisłych wymaganiach dotyczących ścieżek ruchu.

Wady routingu statycznego ujawniają się w większych sieciach lub przy częstych zmianach topologii. Każda modyfikacja wymaga ręcznej zmiany konfiguracji na wszystkich dotkniętych routerach, co jest podatne na błędy i czasochłonne. Routing statyczny nie adaptuje się do awarii – jeśli łącze ulegnie przerwaniu, ruch nie zostanie automatycznie przekierowany, chyba że skonfigurowano backup distance z alternatywną ścieżką. Ryzyko błędów konfiguracji, takich jak brak trasy powrotnej czy zły next-hop, jest wyższe niż w przypadku protokołów dynamicznych, które same wykrywają i korygują niektóre problemy. Te ograniczenia sprawiają, że routing statyczny jest zwykle rezerwowany do konkretnych, stabilnych zastosowań.

Komenda ip route w Cisco IOS ma kilka opcjonalnych parametrów, które rozszerzają jej funkcjonalność. Oprócz standardowej składni z siecią docelową, maską i next-hopem, można dodać parametr distance do zmiany domyślnej wartości AD dla konkretnej trasy. Parametr permanent sprawia, że trasa pozostaje w tablicy routingu nawet wtedy, gdy interfejs powiązany z next-hopem jest wyłączony – zapobiega to usunięciu trasy, ale może prowadzić do blackholingu ruchu, jeśli nie jest używany ostrożnie.

Parametr tag pozwala na przypisanie znacznika numerycznego do trasy, który może być później wykorzystany do filtrowania podczas redystrybucji między protokołami routingu. W zaawansowanych konfiguracjach można również użyć parametru name do nadania trasie opisowej nazwy, co ułatwia identyfikację tras w rozbudowanych konfiguracjach. Cisco IOS obsługuje również trasy statyczne z next-hopem określonym jako adres IP interfejsu pętli zwrotnej (loopback), co jest przydatne w scenariuszach z wieloma ścieżkami (multihoming). Wszystkie te opcje sprawiają, że routing statyczny w Cisco jest znacznie bardziej elastyczny, niż mogłoby się wydawać na pierwszy rzut oka.

Wybór między podaniem next-hopu a samego interfejsu w trasie statycznej ma istotne konsekwencje dla działania sieci. Na interfejsach typu Ethernet (broadcast) zawsze należy podawać adres IP next-hopu, ponieważ router musi znać adres MAC następnego skoku do poprawnego skonstruowania ramki warstwy 2. Jeśli podany zostanie tylko interfejs, router będzie wysyłał zapytania ARP dla każdego adresu docelowego, co jest nieefektywne i może prowadzić do problemów z wydajnością przy dużej liczbie kierowanych sieci.

Na łączach point-to-point (Serial, PPP, HDLC) podanie samego interfejsu jest wystarczające, ponieważ istnieje tylko jeden drugi koniec łącza i router nie musi wykonywać rozpoznawania adresów warstwy 2. W przypadku interfejsów tunelowych (GRE, IPsec) również często wystarczy podanie interfejsu, ponieważ tunel ma zdefiniowany punkt końcowy. Warto pamiętać, że w Cisco IOS można podać zarówno interfejs, jak i next-hop w jednej komendzie: ip route 192.168.3.0 255.255.255.0 GigabitEthernet0/1 10.0.12.2. Taka składnia jest zalecana w przypadku interfejsów Ethernet, ponieważ daje routerowi pełną informację o tym, przez który interfejs i do jakiego adresu MAC należy wysłać pakiet.

RouterOS oferuje kilka zaawansowanych opcji w komendzie /ip route add, które wykraczają poza podstawową konfigurację trasy statycznej. Parametr routing-mark pozwala na przypisanie trasy do konkretnej tabeli routingu, co umożliwia implementację polityki routingu (policy routing) – różne strumienie ruchu mogą korzystać z różnych tablic routingu w zależności od reguł zdefiniowanych w firewall. Parametr scope i target-scope kontrolują sposób, w jaki router weryfikuje osiągalność bramy (gateway) – domyślnie brama musi być osiągalna przez trasę o scope mniejszym lub równym target-scope.

RouterOS pozwala również na dodawanie tras z użyciem interfejsu jako celu (gateway=interface), co jest przydatne w przypadku łączy point-to-point oraz interfejsów bridge. W przeciwieństwie do Cisco IOS, RouterOS automatycznie zapisuje zmiany konfiguracji w pliku konfiguracyjnym – nie jest wymagane jawne zapisywanie komendą typu copy run start. Konfigurację można wyeksportować do pliku tekstowego komendą /export, co ułatwia tworzenie kopii zapasowych i przenoszenie konfiguracji między urządzeniami. Administrator może również użyć komendy /ip route print file=trasy do zapisania tablicy routingu do pliku w celu późniejszej analizy.

Konfiguracja trasy domyślnej na Cisco i RouterOS różni się szczegółami składniowymi, ale realizuje ten sam cel – zapewnienie łączności z sieciami spoza lokalnej tablicy routingu. W Cisco domyślną trasę definiuje się komendą ip route 0.0.0.0 0.0.0.0 next-hop, gdzie podwójne zero oznacza dowolną sieć z dowolną maską. W RouterOS równoważna komenda to /ip route add dst-address=0.0.0.0/0 gateway=next-hop lub w skróconej formie /ip route add gateway=next-hop.

Istotną różnicą między platformami jest sposób traktowania interfejsu, przez który trasa domyślna jest dostępna. W Cisco, jeśli interfejs prowadzący do next-hopu trasy domyślnej ulegnie awarii, trasa jest automatycznie usuwana z tablicy routingu, co może spowodować całkowitą utratę łączności z Internetem. RouterOS zachowuje się podobnie, ale oferuje dodatkowy mechanizm – można skonfigurować trasę domyślną z parametrem check-gateway=ping, który okresowo weryfikuje osiągalność bramy za pomocą ICMP echo request. Jeśli brama nie odpowiada, RouterOS oznacza trasę jako nieaktywną i może przełączyć się na zapasową, nawet jeśli interfejs fizycznie działa. W Cisco podobną funkcjonalność zapewnia mechanizm IP SLA z trackingiem.

Backup distance na routerach Cisco jest prostym, ale skutecznym mechanizmem zapewniania odporności sieci bez użycia protokołów dynamicznych. W przykładzie z głównym łączem światłowodowym (203.0.113.1, distance 1) i zapasowym LTE (192.168.100.1, distance 10), router na bieżąco monitoruje stan interfejsów. Gdy interfejs prowadzący do 203.0.113.1 ulegnie awarii, trasa z distance 1 znika z FIB, a router natychmiast aktywuje trasę z distance 10. Cały proces przełączenia zachodzi automatycznie, bez interwencji administratora.

Po przywróceniu głównego łącza router zachowuje się zgodnie z zasadą niższej distance – trasa z distance 1 ponownie staje się aktywna i przejmuje ruch. W Cisco IOS można dodatkowo użyć mechanizmu ip sla do okresowego testowania osiągalności zdalnych celów za pomocą ICMP lub TCP. W połączeniu z obiektami track IP SLA pozwala na wpływanie na aktywność tras statycznych nie tylko w oparciu o stan interfejsu, ale także o rzeczywistą osiągalność zdalnych zasobów. Na przykład można skonfigurować monitorowanie docelowego adresu po drugiej stronie łącza i przełączyć się na trasę zapasową, gdy cel przestaje być osiągalny – nawet jeśli lokalny interfejs fizycznie działa.

RouterOS implementuje backup distance w sposób bardzo zbliżony do Cisco, co ułatwia administratorom pracę na obu platformach. Różnica polega na tym, że w RouterOS każda trasa ma indywidualnie ustawiany atrybut distance, podczas gdy w Cisco distance jest domyślnie przypisane do źródła trasy. W WinBox kolory tras ułatwiają szybką ocenę stanu: trasy aktywne są oznaczone na niebiesko, nieaktywne na szaro, a trasy z błędami na czerwono.

RouterOS oferuje dodatkowe mechanizmy zwiększające niezawodność backupu. Parametr check-gateway=ping w trasie statycznej powoduje okresowe wysyłanie pakietów ICMP do bramy i oznaczenie trasy jako nieaktywnej, jeśli brama nie odpowiada. Jest to szczególnie przydatne w scenariuszach, gdzie interfejs fizycznie działa, ale łączność z bramą jest przerwana (np. awaria na dalszym odcinku). W połączeniu ze skryptami RouterOS i narzędziem /tool netwatch można tworzyć zaawansowane scenariusze failover z własną logiką przełączania, wykraczające poza prostą hierarchię distance. Mechanizmy te sprawiają, że RouterOS jest często wybierany w scenariuszach wymagających elastycznego zarządzania łączami WAN.

Weryfikacja tras statycznych na routerze Cisco wymaga znajomości kilku kluczowych poleceń diagnostycznych. Polecenie show ip route static wyświetla wyłącznie trasy statyczne, co jest przydatne przy konfiguracji zawierającej setki tras. show ip route 192.168.3.0 pokazuje szczegółowe informacje o konkretnej trasie, w tym jej źródło, czas od poznania, metrykę oraz interfejs wyjściowy. Jeśli trasa nie istnieje, polecenie zwróci informację "% Network not in table".

Polecenia ping i traceroute są podstawowymi narzędziami do testowania łączności. Ping wysyła pakiety ICMP Echo Request i oczekuje na ICMP Echo Reply – udana odpowiedź potwierdza łączność dwukierunkową. Traceroute pokazuje ścieżkę pakietu z adresami IP kolejnych routerów pośrednich. Jeśli ping działa, ale traceroute pokazuje gwiazdki po pewnym routerze, oznacza to, że router nie odpowiada na pakiety ICMP TTL exceeded (często celowe filtrowanie), ale niekoniecznie oznacza problem z routingiem. W przypadku diagnostyki problemów z routingiem warto również sprawdzić tablicę ARP poleceniem show ip arp oraz stan interfejsów poleceniem show interfaces.

RouterOS oferuje zaawansowane możliwości filtrowania i formatowania wyników polecenia /ip route print. Operator where pozwala na tworzenie złożonych zapytań, na przykład /ip route print where static and active and distance=1 wyświetli tylko aktywne trasy statyczne z distance równym 1. Warunki można łączyć operatorami logicznymi and, or oraz negacją. Do filtrowania po adresie sieci można użyć /ip route print where dst-address="192.168.1.0/24".

RouterOS oferuje również możliwość eksportowania wyników w różnych formatach. Polecenie /ip route print terse wyświetla tablicę w zwięzłym formacie, idealnym do przetwarzania w skryptach. /ip route print detail dodaje pełne informacje o każdej trasie, włączając w to parametry scope, target-scope, routing-mark, pref-src oraz komentarze. Wynik można przekierować do pliku (/ip route print file=trasy.txt) lub wyeksportować za pomocą polecenia /ip route export. Te możliwości czynią RouterOS potężnym narzędziem nie tylko do konfiguracji, ale także do monitorowania i automatyzacji zarządzania siecią.

Błędy w konfiguracji routingu statycznego można podzielić na trzy kategorie: błędy logiczne, błędy adresacji i błędy topologiczne. Najczęstszym błędem logicznym jest brak trasy powrotnej – administrator konfiguruje trasę na routerze A do sieci za routerem B, ale zapomina skonfigurować trasę powrotną na routerze B do sieci za routerem A. Taki błąd objawia się działającym pingiem w jedną stronę (jeśli testujemy z poziomu routera), ale brakiem odpowiedzi przy teście z hostów końcowych.

Błędy adresacji obejmują podanie złego adresu next-hop (np. adresu spoza bezpośrednio podłączonej sieci) lub użycie niewłaściwej maski sieci. Router zaakceptuje komendę ip route 192.168.3.0 255.255.255.0 10.99.99.99, ale trasa nie stanie się aktywna, jeśli 10.99.99.99 nie jest bezpośrednio podłączony. Błędy topologiczne polegają na skonfigurowaniu tras, które tworzą pętle routingu – na przykład router A wskazuje na router B, router B na router C, a router C z powrotem na router A. Pętle routingu prowadzą do utraty pakietów (TTL wyczerpuje się) i nadmiernego obciążenia łączy. Do wykrywania pętli routingu służy polecenie traceroute, które pokazuje adresy IP kolejnych routerów – jeśli adresy się powtarzają, mamy do czynienia z pętlą.

Zasada obukierunkowości routingu statycznego jest jedną z najważniejszych reguł, którą każdy administrator musi zapamiętać. W praktyce oznacza to, że dla każdej skonfigurowanej trasy w jedną stronę należy skonfigurować odpowiadającą jej trasę powrotną po drugiej stronie. Wyjątkiem od tej reguły jest routing asymetryczny, gdzie ruch w jedną stronę płynie inną ścieżką niż w drugą – jest to zjawisko naturalne w Internecie, ale w sieciach z routingu statycznym rzadko stosowane celowo.

Aby uniknąć problemów z trasami powrotnymi, warto stosować systematyczne podejście do konfiguracji. Po dodaniu trasy na routerze A należy natychmiast dodać odpowiadającą trasę na routerze B. Weryfikację należy przeprowadzać sekwencyjnie: najpierw sprawdzić, czy trasa pojawiła się w tablicy routingu (show ip route), następnie przetestować łączność pingiem między routerami, a na końcu między hostami końcowymi. W przypadku bardziej złożonych topologii warto narysować schemat sieci z zaznaczonymi trasami w obie strony – pomaga to wizualnie wychwycić brakujące trasy. Metodyczne podejście i dokumentowanie konfiguracji znacząco redukuje ryzyko błędów.

Blok routingu statycznego stanowi fundament wiedzy o routingu IP, na którym opierają się wszystkie bardziej zaawansowane zagadnienia. Kluczowe wnioski z tego bloku to przede wszystkim zrozumienie, że trasa statyczna to ręczna definicja ścieżki, która jest przewidywalna i niegenerująca narzutu, ale wymaga ręcznego zarządzania. Umiejętność poprawnego definiowania tras statycznych, w tym trasy domyślnej, jest absolutnie niezbędna przed przejściem do protokołów dynamicznych.

Routing statyczny znajduje zastosowanie w każdej sieci, nawet w dużych środowiskach korporacyjnych, gdzie główny routing odbywa się dynamicznie. Trasy domyślne do ISP, trasy do sieci zarządczych, pętle zwrotne do identyfikacji routerów – to wszystko są przykłady zastosowań, w których routing statyczny pozostaje standardem. Backup distance pozwala na dodanie elementu odporności do tras statycznych bez użycia protokołów dynamicznych. Zrozumienie mechanizmu wyboru trasy (najdłuższy prefiks, AD, metryka) oraz zasad takich jak obukierunkowość tras stanowi solidną podstawę do dalszej nauki routingu dynamicznego, który zostanie omówiony w kolejnych prezentacjach.

Topologia liniowa z trzema routerami (R1-R2-R3) jest standardowym przykładem dydaktycznym używanym w kursach CCNA i innych szkoleniach sieciowych. Łącza między routerami wykorzystują prefiks /30, który jest standardem dla łączy punkt-punkt – zapewnia tylko dwa użyteczne adresy IP, co minimalizuje marnotrawstwo przestrzeni adresowej. Sieci końcowe po obu stronach (192.168.1.0/24 i 192.168.3.0/24) reprezentują sieci LAN, w których znajdują się hosty końcowe.

Router R2 pełni w tej topologii rolę routera tranzytowego – nie ma własnych sieci LAN, a jedynie przekazuje pakiety między R1 a R3. W rzeczywistych sieciach routery tranzytowe są powszechne w rdzeniu sieci (core layer), gdzie ich zadaniem jest szybkie przekazywanie pakietów między dystrybutorami. Adresacja 10.0.12.0/30 i 10.0.23.0/30 pochodzi z zakresu prywatnego 10.0.0.0/8 zarezerwowanego dla sieci wewnętrznych. Wybór adresacji z puli prywatnej jest standardem w laboratoriach sieciowych i sieciach wewnętrznych firm. W przypadku łączenia z Internetem adresy na interfejsach WAN są zwykle publiczne i przydzielane przez dostawcę usług internetowych.

Przed skonfigurowaniem tras statycznych żaden z routerów nie ma pełnej wiedzy o topologii sieci. R1 zna jedynie sieć 192.168.1.0/24 (bezpośrednio podłączona) oraz 10.0.12.0/30 (łącze do R2). R2 zna 10.0.12.0/30 i 10.0.23.0/30, ale nie ma żadnej sieci LAN. R3 zna 10.0.23.0/30 oraz 192.168.3.0/24. Oznacza to, że PC1 nie może pingować PC3, ponieważ R1 nie ma trasy do 192.168.3.0/24.

Aby umożliwić komunikację, każdy router musi otrzymać trasy do sieci, które nie są bezpośrednio podłączone. R1 potrzebuje trasy do 192.168.3.0/24 przez R2, R2 potrzebuje tras do obu sieci końcowych (192.168.1.0/24 i 192.168.3.0/24), a R3 potrzebuje trasy do 192.168.1.0/24 przez R2. Dodatkowo R1 i R3 potrzebują tras domyślnych do kierowania ruchu do Internetu. W praktyce, jeśli celem jest tylko komunikacja między PC1 a PC3, trasy domyślne nie są konieczne – wystarczą konkretne trasy do sieci końcowych. Trasy domyślne są potrzebne, gdy routery mają mieć dostęp do Internetu przez R2 lub innego dostawcę.

Router R1 jako pierwszy w topologii wymaga konfiguracji tras statycznych. Interfejs G0/0 routera R1 ma adres 192.168.1.1/24 i obsługuje sieć LAN, natomiast interfejs G0/1 ma adres 10.0.12.1/30 i łączy się z routerem R2. Trasa do sieci 192.168.3.0/24 jest dodawana komendą ip route 192.168.3.0 255.255.255.0 10.0.12.2, gdzie 10.0.12.2 to adres interfejsu G0/0 routera R2 znajdujący się w tej samej podsieci 10.0.12.0/30.

Trasa domyślna na R1 (ip route 0.0.0.0 0.0.0.0 10.0.12.2) kieruje cały pozostały ruch (np. do Internetu) również przez R2. W tej konkretnej topologii nie jest ona niezbędna do komunikacji PC1 z PC3 – wystarczy trasa do konkretnej sieci 192.168.3.0/24. Jednak w praktyce routery brzegowe zawsze mają trasę domyślną, aby zapewnić łączność z sieciami spoza znanych tras. Warto zauważyć, że obie trasy (konkretna i domyślna) mają ten sam next-hop (10.0.12.2) – R1 będzie kierował cały ruch do R2, a R2 na podstawie swojej tablicy routingu zdecyduje, czy pakiet ma trafić do R1, R3, czy gdzie indziej.

Router R2 pełni kluczową rolę routera tranzytowego w topologii liniowej. Jego konfiguracja wymaga dodania dwóch tras statycznych: do sieci 192.168.1.0/24 przez interfejs 10.0.12.1 (R1) oraz do sieci 192.168.3.0/24 przez interfejs 10.0.23.2 (R3). R2 nie potrzebuje trasy domyślnej, ponieważ w tej zamkniętej topologii wszystkie możliwe sieci docelowe są znane – ruch do 192.168.1.0/24 idzie do R1, a do 192.168.3.0/24 do R3.

W rzeczywistych sieciach routery tranzytowe w rdzeniu (core) rzadko mają trasy domyślne – zamiast tego mają konkretne trasy do wszystkich sieci w organizacji lub trasę domyślną wskazującą na router brzegowy łączący z Internetem. R2 w naszej topologii jest przykładem routera dystrybucyjnego (distribution layer), który agreguje ruch z dwóch sieci końcowych. Gdyby topologia zawierała więcej sieci, R2 wymagałby tras do każdej z nich lub trasy domyślnej. W protokołach dynamicznych, takich jak OSPF, routery tranzytowe automatycznie poznają wszystkie sieci bez ręcznego definiowania tras, co jest główną zaletą routingu dynamicznego w większych sieciach.

Router R3 jest konfigurowany symetrycznie do R1 – potrzebuje trasy do drugiej sieci końcowej (192.168.1.0/24) oraz trasy domyślnej dla ruchu do Internetu. Next-hopem dla obu tras jest 10.0.23.1, czyli adres interfejsu G0/1 routera R2 w sieci 10.0.23.0/30. Trasa do 192.168.1.0/24 jest niezbędna, aby ICMP Echo Reply z PC3 mógł wrócić do PC1 – bez niej ping z PC1 do PC3 zakończy się timeoutem.

Weryfikacja poprawności konfiguracji R3 polega na sprawdzeniu show ip route – w tablicy powinny pojawić się wpisy: S 192.168.1.0/24 [1/0] via 10.0.23.1 oraz S* 0.0.0.0/0 [1/0] via 10.0.23.1. Należy również sprawdzić, czy interfejs G0/0 z adresem 192.168.3.1/24 jest włączony (no shutdown) i czy ma poprawną maskę. Wszystkie trzy routery (R1, R2, R3) tworzą spójną całość – każdy z nich ma skonfigurowane trasy zapewniające komunikację w obie strony między sieciami 192.168.1.0/24 a 192.168.3.0/24. Po poprawnej konfiguracji wszystkich routerów PC1 (192.168.1.10) powinien bezproblemowo pingować PC3 (192.168.3.10).

Systematyczna weryfikacja łączności jest kluczowym elementem procesu konfiguracji sieci. Po skonfigurowaniu wszystkich tras na routerach R1, R2 i R3 należy przeprowadzić testy w logicznej kolejności. Pierwszym krokiem jest sprawdzenie tablicy routingu na każdym routerze (show ip route) – upewnij się, że wszystkie trasy są aktywne i mają poprawny next-hop. Następnie wykonaj ping z PC1 do swojej bramy (192.168.1.1) – to potwierdza, że host ma poprawną konfigurację IP.

Kolejne kroki to ping z PC1 do adresu 10.0.12.2 (R2), potem do 10.0.23.2 (R3), a na końcu do 192.168.3.10 (PC3). Jeśli ping do R2 działa, ale do R3 nie, problem leży po stronie R2 (brak trasy do 192.168.3.0/24). Jeśli ping do PC3 nie działa, ale do R3 tak, problem leży po stronie R3 (brak trasy powrotnej do 192.168.1.0/24). Tę samą sekwencję testów można wykonać za pomocą traceroute, który pokaże dokładnie, na którym routerze pakiet jest zatrzymywany. W RouterOS podobną weryfikację przeprowadza się komendami /ip route print, /ping i /tool traceroute.

Scenariusz awaryjny z backup distance pokazuje, jak routing statyczny może zapewnić odporność sieci bez użycia protokołów dynamicznych. W tym przykładzie R1 ma dwie trasy do sieci 192.168.3.0/24: główną przez R2 (10.0.12.2) z distance 1 i zapasową przez alternatywny router R4 (10.0.42.2) z distance 10. W normalnych warunkach R1 używa trasy przez R2. Gdy interfejs łączący R1 z R2 ulegnie awarii, trasa z distance 1 znika z FIB, a router automatycznie aktywuje trasę zapasową przez R4.

Po przywróceniu łącza między R1 a R2 trasa główna wraca do FIB i R1 ponownie kieruje ruch przez R2. W praktyce należy pamiętać, że backup distance nie ochroni przed awarią, która nie wpływa na lokalny interfejs – na przykład, jeśli łącze między R2 a R3 ulegnie przerwaniu, R1 nadal będzie uważać trasę przez R2 za aktywną, ponieważ jego lokalny interfejs działa. W takich przypadkach konieczne jest użycie zewnętrznych mechanizmów monitorujących, takich jak IP SLA w Cisco lub netwatch w RouterOS. Te narzędzia mogą okresowo testować osiągalność zdalnych celów i dezaktywować trasę statyczną, gdy cel przestaje być osiągalny, wymuszając przełączenie na trasę zapasową.

Konfiguracja tras statycznych na RouterOS jest syntaktycznie zbliżona do Cisco IOS, co ułatwia administratorom pracę na obu platformach. W RouterOS składnia /ip route add dst-address=192.168.3.0/24 gateway=10.0.12.2 distance=1 jest równoważna komendzie Cisco ip route 192.168.3.0 255.255.255.0 10.0.12.2. Podstawowa różnica polega na sposobie przekazywania parametrów – RouterOS używa nazwanych parametrów (np. dst-address=, gateway=), podczas gdy Cisco przyjmuje argumenty pozycyjne.

Backup distance na RouterOS konfiguruje się przez dodanie dwóch tras do tej samej sieci z różnymi wartościami distance, podobnie jak w Cisco. Dodatkowo, RouterOS oferuje możliwość dodania parametru comment do każdej trasy, co ułatwia identyfikację tras w rozbudowanych konfiguracjach. Na przykład /ip route add dst-address=0.0.0.0/0 gateway=10.0.12.2 distance=1 comment="Główna_trasa_ISP". RouterOS pozwala również na grupowanie tras w routing tables, co umożliwia implementację zaawansowanych polityk routingu. W przypadku migracji z Cisco na RouterOS warto skorzystać z narzędzia do konwersji składni lub przeanalizować dokumentację MikroTik, która zawiera liczne przykłady konfiguracji odpowiadające typowym scenariuszom z Cisco IOS.

Prezentacja czwarta stanowiła kompleksowe wprowadzenie do tematyki tablicy routingu i routingu statycznego, kładąc podwaliny pod dalszą naukę protokołów dynamicznych. Słuchacz poznał różnicę między RIB (pełna baza wszystkich tras) a FIB (optymalizowana tabela tras aktywnych) oraz zrozumiał, jak te dwie struktury współpracują w procesie przekazywania pakietów. Przeanalizowano budowę wpisu trasy z uwzględnieniem takich pól jak sieć docelowa, next-hop, interfejs wyjściowy, AD i metryka.

Routing statyczny został przedstawiony jako fundamentalne narzędzie administratora, które mimo prostoty znajduje zastosowanie nawet w dużych sieciach korporacyjnych. Omówiono mechanizm wyboru najlepszej trasy (Longest Prefix Match, AD, metryka), zasady konfiguracji na platformach Cisco i RouterOS oraz scenariusze backupu z wykorzystaniem różnych wartości distance. Przedstawiono również najczęstsze błędy konfiguracyjne i metody ich unikania. Zdobyta wiedza stanowi solidną podstawę do zgłębienia protokołów routingu dynamicznego, takich jak OSPF, które będą tematem kolejnych prezentacji. Zachęcamy do samodzielnego eksperymentowania w symulatorach sieciowych, takich jak Cisco Packet Tracer czy GNS3, oraz na rzeczywistych urządzeniach MikroTik i Cisco.