(Ts) Troubleshooting protokołu RIP**

Troubleshooting brakujących tras routingu

Wstęp do zagadnienia

  • Protokół RIP nie nawiązuje relacji sąsiedztwa pomiędzy sąsiednimi ruterami, związku z tym proces troubleshooting-u nie będzie dotyczył rozwiązywania problemów związanych z relacjami sąsiedztwa a procesem wymiany informacji o trasach routingu.
  • Podstawową komendą używaną w celu weryfikacji tras pozyskanych za pomocą protokołu RIP jest komenda [show ip rip database].
  • komendą używaną w celu weryfikacji konfiguracji protokołu RIP, jest komenda [show ip protocols].

Przyczyny Troubleshooting

Interface is shut down

  • Interfejs uczestniczący w procesie protokołu RIP musi być aktywny up/up. Status interfejsu można zweryfikować za pomocą komendy [show ip interface brief] bądź komendy [show interface interfejs].

Wrong subnet

  • Aby rutery mogły między sobą wymieniać aktualizacje protokołu RIP, muszą znajdować się w tej samej sieci, w przeciwnym wypadku zignorują nadchodzące aktualizacje.
  • W przypadku wykrycia problemu ze źle skonfigurowaną siecią, komenda [debug ip rip] wyświetli następujący komunikat: [RIP: ignored v2 update from bad source 10.1.12.2 on  gigabitethernet 1/0].

Bad or missing network statements

  • Aktywacja protokołu RIP względem określonego interfejsu sieciowego, następuje za pomocą komendy [network adres-IP] wydanej w trybie konfiguracji protokołu RIP.
  • Aby zweryfikować czy wszystkie interfejsy sieciowe należą do procesu RIP, należy wykorzystać komendę [show ip protocols] bądź komendę [show running-config | section router rip].

Passive interface

  • Funkcja pasywnego interfejsu „Passive Interface”, blokuje wysyłanie aktualizacji protokołu RIP na wskazanym interfejsie sieciowym, jednocześnie zezwalając na odbierania aktualizacji od innych urządzeń. Ma to na celu zarówno względy bezpieczeństwa związane z blokowanie poufnych informacji, na temat topologii sieciowej jak i ogranicza zbędny ruch.
  • Konfigurację funkcji pasywnego interfejsu można zweryfikować za pomocą komendy [show ip protocols].

Wrong version

  • Podstawowa konfiguracja protokółu RIP, domyślnie działa w starszej, pierwszej wersji protokołu (RIPv1). Należy przy tym pamiętać że rutery skonfigurowane w wersji drugiej, wysyłają aktualizacji w wersji niekompatybilnej z wersją pierwszą, związku z tym nie są wstanie wymieniać pomiędzy sobą tras routingu dynamicznego.
  • Obecnie wykorzystywaną wersję protokołu RIP można określić za pomocą komendy [show ip protocols] a zmienić za pomocą komendy [version {1 / 2}] wydanej w trybie konfiguracji protokołu RIP.
  • W przypadku wykrycia problemu z wersją protokołu RIP, komenda [debug ip rip] wyświetli następujący komunikat: [RIP: ignored v2 packet from 10.1.12.1 (inlegal vesrion)] bądź [RIP: ignored v1 packet from 10.1.12.1 (inlegal vesrion)].

Max hop count exceeded

  • Protokół RIP wspiera maksymalnie 15 przeskoków z czego przeskok 16 określany jest jako nieosiągalny. Trasa posiadająca wartość 16, zostanie zapisana w tablicy topologii lecz nie zostanie przekazana do tablicy routingu.
  • Trasa routingu może osiągnąć wartość 16 przeskoków z powodu:
    • Zbyt dużej topologii fizycznej.
    • Zbyt dużej wartości metryki podczas redystrybucji.
    • Zbyt dużej wartości „offset”.
  • Informacje na temat funkcji „offset”, względem protokołu RIP można wyświetlić za pomocą komendy [show ip protocols].
  • W przypadku otrzymania trasy z wartością metryki równą 15, komenda [debug ip rip] wyświetli następujący komunikat debug: [RIP: recived v2 update from 10.1.12.2 on gigabitethernet 1/0 10.1.3.0/24 via 0.0.0.0 in 16 hops (inaccessible)].

Authentication

  • Protokół RIP umożliwia uwierzytelnianie nadchodzących aktualizacji za pomocą funkcji key-chain, czystego teksu bądź klucza md5. Konfigurację funkcji uwierzytelniania można wyświetlić za pomocą komendy [show ip protocols].
  • W przypadku wykrycia problemu z uwierzytelnianiem, komenda [debug ip rip] wyświetli następujący komunikat: [RIP: ignored v2 packet from 10.1.12.1 (Invalid authentication)].

Route filtering

  • Protokół RIP umożliwia filtrację tras routingu na postawie listy ACL, prefix listy oraz router map-y.
  • Aby zweryfikować konfigurację funkcji filtrowania tras routingu dynamicznego, należy sprawdzić czy Lista dystrybucyjna (Distribute List):
    • Ma właściwy kierunek.
    • Jest przypisane do właściwego interfejsu.
    • Wykorzystuje właściwą listę ACL.
    • Wykorzystuje właściwą prefix listę.
    • Wykorzystuje właściwą router mapę.
  • Obecną konfigurację list dystrybucyjnych (Distribute List) można zweryfikować za pomocą komendy [show ip protocols], [show ip prefix-list] bądź komendy [show route-map].

Split horizon

  • Funkcja Split Horizon zapobiega powstawaniu pętli sieciowych, uniemożliwiając ruterowi wysyłanie wiadomości aktualizacyjnych na temat sieci, poprzez interfejs, z którego sieci te otrzymał. Problem w tym przypadku stanowi topologia wielodostęp-owa w której rutery z włączoną opcją podzielonego horyzontu nie będą w stanie przekazać aktualizacji otrzymanych z jednego rutera do drugiego, podłączonego do tego samego interfejsu.
  • Konfiguracje funkcji Split Horizon można zweryfikować za pomocą komendy [show ip interface interfejs].

Autosummarization

  • Autosumaryzacja protokołu RIP jest możliwa, jeżeli topologia sieci wykorzystuje podział klasowy.
    • Contiguous Network – Topologia, w której sieć klasowa nie jest podzielona ani odseparowana poprzez inną podsieć.
    • Discontiguous Network – Topologia, w której sieć klasowa jest podzielona oraz odseparowana przez inną podsieć.
Przykładowa topologia obrazująca problem związany z autosumaryzacją

Better source of information

  • Protokół RIP w systemie Cisco IOS posiada wartość Dystansu Administracyjnego AD równą 120, jeżeli inny protokół routingu z mniejszą wartością AD bądź wpis statyczny, również rozgłasza daną trasę to może ona znaleźć się w tablicy routingu za pomocą innego źródła prowadząc przez inny adres następnego przeskoku.

ACLs

  • Listy ACL mogą blokować aktualizacje protokołu RIP za pomocą ostatniego wpisu końcowego „deny ip any any”. Aby do tego nie dopuścić należy odblokować adres multicast 224.0.0.9 na porcie 520 protokołu UDP.

Load balancing

  • Protokół RIP wspiera funkcję równoważenia ruchu sieciowego pomiędzy trasami z równą wartością metryki. Jeżeli jednak wartość połączeń równoważonych wynosi 1, funkcja nie zadziała prawidłowo. Aby zweryfikować konfiguracje funkcji Load Balance należy wykorzystać komendę [show ip protocols].

Problemy związane z protokołem RIP, RIPng

Brakująca trasa domyślna

  • Protokół RIP może rozgłaszać trasę domyślną nawet jeśli nie jest one skonfigurowana na lokalnym urządzeniu, co wiąże się z ryzykiem że adres następnego przeskoku dla takiej trasy będzie nieosiągalny, a tym samym cały przychodzący ruch sieciowy zostanie porzucony.

Podstawowa weryfikacja konfiguracji RIPng

  • Protokół RIPng wykorzystuje adresację protokołu IPv6, związku z tym wymaga aktywacji funkcji routingu względem tego protokołu. Funkcje routingu można aktywować za pomocą komendy [ipv6 unicast-routing] wydanej w trybie konfiguracji globalnej a sprawdzić za pomocą komendy [show running-configuration | include ipv6 unicast-routing].

Pozostałe tematy związane z protokołem RIP

PDFPRINT

Robert T Kucharski

Cisco Network Engineer in GPW.

Dodaj komentarz