OSPF czy EIGRP przez VTI na ASA: które z nich obsługuje twoje wydanie
OSPFv2 i EIGRP działają przez VTI na ASA dopiero od 9.19(1) i tylko z włączonym multicast. Porównaj oba na wydaniu, którego używasz, a następnie sprawdź sąsiadów.
Większość sporów OSPF kontra EIGRP zakłada, że tunel już potrafi przenosić protokół, a na ASA właśnie to założenie jest częścią, którą warto sprawdzić najpierw. Porównanie staje się ciekawe dopiero po potwierdzeniu obrazu, typu VTI i ścieżki multicast. Pomyl kolejność, a spędzisz popołudnie na strojeniu timerów na tunelu, który nigdy nie utworzy sąsiedztwa. Każdy z tych projektów zaczynam od informacji o wydaniu i bieżącej konfiguracji, a nie od preferencji protokołu.
Wydanie decyduje przed protokołem
Przewodnik Cisco po VTI dla ASA 9.24 to użyteczna podstawa dokumentacyjna: opisuje statyczne i dynamiczne VTI oraz wymienia routing statyczny, BGP, OSPF i EIGRP. Historia funkcji umieszcza obsługę OSPFv2 i EIGRP na VTI w wersji 9.19(1). Wszystko starsze to inna rozmowa.
Zatem dwa pierwsze pytania są nudne i rozstrzygające:
| Check | What decides it |
|---|---|
| Image and release | Whether the feature history lists OSPFv2 or EIGRP on VTI for the version you run |
| VTI type | Static or dynamic, and which routing context the platform permits |
| Multicast on the tunnel | Whether it is enabled, and whether the group limits are respected |
Twierdzenie, że ASA nie może używać VTI ani przenosić IGP, było prawdziwe dla niektórych starszych obrazów i nie jest obecną matrycą wsparcia. Podobnie przewodnik 9.24 nie jest poleceniem aktualizacji każdego urządzenia. Mówi, co obsługuje to wydanie, a twoje wdrożone wydanie musi odpowiedzieć samo za siebie.
Przechodzenie unicast nie oznacza, że IGP się utworzy
Ten sam przewodnik zauważa, że unicast przechodzi domyślnie, a multicast trzeba włączyć dla OSPFv2 lub EIGRP na VTI, z udokumentowanymi limitami grup multicast. To jedno zdanie wyjaśnia większość nieudanych sąsiedztw, jakie widziałem w tym projekcie. Działający ping przez tunel albo zielony status IPsec dowodzi tylko ścieżki unicast. Wykrywanie protokołu wymaga ścieżki multicast, a obie konfiguruje się osobno.
Sprawdź w konfiguracji interfejsu tunelu to ustawienie multicast, zanim dotkniesz timerów hello lub hold. Jeśli ustawienia nie ma, sąsiedztwo nie jest wolne, jest niemożliwe.
OSPF i EIGRP obok siebie na tym samym tunelu
Na samym tunelu oba protokoły wyglądają jak wszędzie indziej. OSPF potrzebuje pasującego typu sieci, obszaru, uwierzytelniania i parametrów sąsiada; EIGRP potrzebuje swojego numeru AS i związanych z nim ustawień na poziomie interfejsu.
Pułapką jest kopiowanie poleceń sąsiada z innego modelu tunelu. Porady o sąsiadach statycznych w projekcie bez VTI istniały, by uniknąć multicast, i nie przenoszą się na VTI, które ma przenosić protokół natywnie. Skonfiguruj obsługiwane zachowanie interfejsu, a potem pozwól protokołowi utworzyć własne sąsiedztwo.
Następnie porównuj na osiach, które naprawdę różnią się dla twojej topologii: współdziałanie z drugą stroną, testowalne zachowanie zbieżności i wiedza operacyjna twojego zespołu. Historyczna anegdota o tym, że jeden protokół jest szybszy lub lżejszy, nie jest pomiarem twojej sieci.
Sąsiedzi nie równają się zainstalowanym trasom
Gdy sąsiedztwo jest podniesione, oddziel to, co jest generowane, od tego, co jest akceptowane. Sprawdź, które prefiksy oddziałów ogłasza każda strona, które są odbierane, które wybierane i które faktycznie trafiają do tablicy routingu. Zakres importu, eksportu i redystrybucji powinien być zamierzony, a nie zbiorczym ogłoszeniem wszystkiego, co urządzenie wie.
show ospf neighbor i show eigrp neighbors mówią ci, że sesja żyje. show route mówi ci, czy prefiks oddziału dotarł, i to są różne pytania.
Ścieżka aplikacji to znowu trzecie pytanie. Relacja sąsiedzka rozprowadza osiągalność; nie daje pozwolenia przez zaporę i nie dowodzi, że selektory ruchu i reguły filtrowania są zgodne. Sprawdź dozwolony przepływ i jego ścieżkę powrotną zatwierdzonym testem, zamiast zakładać, że trasa implikuje politykę.
Co powinno zapisać ukończone porównanie
Zapisz interfejs tunelu, wydanie, które go obsługuje, sprawdzoną wymianę sterowania i ograniczoną politykę tras. Dodaj ustawienie multicast, bo to szczegół, który po cichu decyduje, czy reszta działa. Trzymaj ten zapis obok wdrożonego wydania, aby późniejszą zmianę funkcji można było przejrzeć bez zaczynania od założenia, które już wygasło.
Jeśli brakuje któregoś z tych czterech, masz preferencję, a nie projekt. Najpierw napraw brakujący fakt; wybór protokołu to łatwa część.