OSPF-grannar bildas inte över ett VPN? Kontrollera dessa i ordning
Fem kontroller, var och en med sitt eget symptom: länkmodell, filtrering av protokoll 89, grannparametrar, grannskapsstatus och till sist vad som faktiskt annonseras.
Tunneln är uppe, gränssnitten ligger i samma subnät och OSPF visar fortfarande ingenting. Oftast är tunneln i ordning och ett OSPF-krav är inte uppfyllt. Arbeta igenom de fem kontrollerna nedan i ordning och stanna vid den första som misslyckas.
Varje kontroll har ett eget symptom, därför är ordningen viktigare än listan.
Kontroll 1: är länkmodellen rätt
Ett punkt-till-punkt-gränssnitt och ett delat nät med flera åtkomster är olika OSPF-miljöer. Att kopiera en broadcast-LAN-konfiguration till en tunnel är det vanligaste misstaget här. Ange den nätverkstyp som VPN-implementeringen stöder, vanligtvis punkt-till-punkt för en routad tunnel. Bekräfta sedan att plattformen håller med, eftersom vissa implementeringar ignorerar eller skriver över inställningen.
Om länkmodellen är fel hjälper ingenting senare i listan.
Kontroll 2: släpps paketen igenom
OSPFv2 är IP-protokoll 89, inte en TCP- eller UDP-port, så en brandväggsregel skriven för portar droppar den tyst. Hello går också till multicast-adresser, vilket en policy kanske inte tillåter. Tillåt protokoll 89 mellan tunnelns ändpunkter och kontrollera sedan om plattformen behöver explicita grannpåståenden.
En tunnel som bara släpper igenom ping är ett policyproblem, inte ett routingproblem.
Kontroll 3: stämmer grannparametrarna
Områdes-ID, hello- och dead-intervall, autentisering och stub-flaggor måste alla stämma. En avvikelse lämnar oftast grannen i ett synligt tillstånd i stället för att misslyckas tyst, vilket är användbart. Jämför den körande konfigurationen i båda ändar, inte den avsedda.
MTU-avvikelsen är den subtila. Den blockerar databasutbytet vid ExStart, så grannen når aldrig Full.
Kontroll 4: vad säger tillståndet
Tillståndet namnger felet. Init betyder att hello kommer in men den här routern finns inte med i dem, vilket pekar på en enkelriktad väg eller ett multicast-problem. Two-Way är normalt på ett broadcast-segment med en granne som inte är DR och onormalt på en punkt-till-punkt-länk. Fastlåst ExStart eller Exchange betyder ett MTU- eller databasbeskrivningsproblem. Loading betyder att link-state-förfrågningar inte besvaras.
Läs tillståndet innan du ändrar något, eftersom det eliminerar större delen av listan.
show ip ospf neighbor skriver ut tillståndet, grannens adress och dead-timern. Jämför den timern med hello-intervallet på båda sidor: ett dead-intervall på fyra gånger hello är normalt, allt annat är en avvikelse. Tillståndskolumnen är den snabbaste läsningen på hela sidan.
Kontroll 5: vad annonseras egentligen
En Full-grannskap är inte en rutt. Kontrollera vilka nätverk som skapas, vilka som lärs in och vilka som installeras i routingtabellen. En saknad nätverksdeklaration eller en redistributionspolicy som utesluter platsens prefix ger en frisk granne och en tom tabell.
Testa sedan en applikation på värdnivå och returvägen, eftersom ett routingprotokoll inte öppnar en brandvägg.
För IPv6 har OSPFv3 egna krav och är ingen adressfamiljsomkopplare på varje OSPFv2-inställning. Använd motsvarande protokoll och plattformens dokumentation. Och om anslutningen är en enda fast länk, jämför statiska rutter innan du lägger till ett kontrollplan som du måste driva.