OSPF-naboer dannes ikke over en VPN? Sjekk disse i rekkefølge
Fem kontroller, hver med sitt eget symptom: leddmodell, filtrering av protokoll 89, naboleddsparametere, nabohetsstatus og til slutt det som faktisk annonseres.
Tunnelen er oppe, grensesnittene ligger i samme subnett, og OSPF viser fortsatt ingenting. Som oftest er tunnelen i orden, og ett OSPF-krav er ikke oppfylt. Gå gjennom de fem kontrollene nedenfor i rekkefølge og stopp ved den første som feiler.
Hver kontroll har et eget symptom, derfor er rekkefølgen viktigere enn listen.
Kontroll 1: er leddmodellen riktig
Et punkt-til-punkt-grensesnitt og et delt nettverk med flere tilganger er forskjellige OSPF-miljøer. Å kopiere en broadcast-LAN-konfigurasjon over på en tunnel er den vanligste feilen her. Sett nettverkstypen som VPN-implementasjonen støtter, vanligvis punkt-til-punkt for en rutet tunnel. Bekreft deretter at plattformen er enig, fordi noen implementasjoner ignorerer eller overstyrer innstillingen.
Hvis leddmodellen er feil, hjelper ingenting senere på listen.
Kontroll 2: slipper pakkene gjennom
OSPFv2 er IP-protokoll 89, ikke en TCP- eller UDP-port, så en brannmurregel skrevet for porter dropper den lydløst. Hello går også til multicast-adresser, som en policy kanskje ikke tillater. Tillat protokoll 89 mellom tunnelendepunktene, og sjekk deretter om plattformen trenger eksplisitte naboerklæringer.
En tunnel som bare slipper ping gjennom, er et policyproblem, ikke et ruteproblem.
Kontroll 3: stemmer naboleddsparameterne
Område-ID, hello- og dead-intervaller, autentisering og stub-flagg må alle stemme. En avvikelse lar vanligvis naboen henge i en synlig tilstand i stedet for å feile lydløst, noe som er nyttig. Sammenlign den kjørende konfigurasjonen i begge ender, ikke den tiltenkte.
MTU-avviket er det subtile. Det blokkerer databaseutveksling ved ExStart, så naboen når aldri Full.
Kontroll 4: hva sier tilstanden
Tilstanden navngir feilen. Init betyr at hello kommer inn, men denne ruteren er ikke oppført i dem, noe som peker på en enveisvei eller et multicast-problem. Two-Way er normalt på et broadcast-segment med en nabo som ikke er DR, og unormalt på en punkt-til-punkt-lenke. Fastlåst ExStart eller Exchange betyr et MTU- eller databasebeskrivelsesproblem. Loading betyr at link-state-forespørsler ikke besvares.
Les tilstanden før du endrer noe, fordi den eliminerer det meste av listen.
show ip ospf neighbor skriver ut tilstanden, naboens adresse og dead-timeren. Sammenlign den timeren med hello-intervallet i begge sider: et dead-intervall på fire ganger hello er normalt, alt annet er et avvik. Tilstandskolonnen er det raskeste lesestoffet på hele siden.
Kontroll 5: hva annonseres det faktisk
En Full-nabohet er ikke en rute. Sjekk hvilke nettverk som opprettes, hvilke som læres og hvilke som installeres i rutetabellen. En manglende nettverkserklæring eller en redistribusjonspolicy som utelukker stedets prefiks gir en sunn nabo og en tom tabell.
Test deretter en applikasjon på vertsnivå og returveien, fordi en ruteprotokoll ikke åpner en brannmur.
For IPv6 har OSPFv3 sine egne krav og er ikke en adressefamiliebryter på hver OSPFv2-innstilling. Bruk den samsvarende protokollen og plattformdokumentasjonen. Og hvis forbindelsen er én fast lenke, sammenlign statiske ruter før du legger til et kontrollplan du må drifte.