OSPF-naboar vert ikkje oppretta over ein VPN? Sjekk desse i rekkjefølgje

Tunnelen er oppe, grensesnitta ligg i same subnett, og OSPF viser framleis ingenting. Som oftast er tunnelen i orden, og eitt OSPF-krav er ikkje oppfylt. Gå gjennom dei fem kontrollane nedanfor i rekkjefølgje og stopp ved den første som feilar.

Kvar kontroll har eit eige symptom, difor er rekkjefølgja viktigare enn lista.

Kontroll 1: er leddmodellen riktig

Eit punkt-til-punkt-grensesnitt og eit delt nettverk med fleire tilgangar er ulike OSPF-miljø. Å kopiere ein broadcast-LAN-konfigurasjon over på ein tunnel er den vanlegaste feilen her. Set nettverkstypen som VPN-implementasjonen støttar, vanlegvis punkt-til-punkt for ein ruta tunnel. Stadfest deretter at plattforma er samd, fordi nokre implementasjonar ignorerer eller overstyrer innstillinga.

Viss leddmodellen er feil, hjelper ingenting seinare på lista.

Kontroll 2: slepp pakkane gjennom

OSPFv2 er IP-protokoll 89, ikkje ein TCP- eller UDP-port, så ein brannmurregel skriven for portar droppar han lydlaust. Hello går også til multicast-adresser, som ein policy kanskje ikkje tillét. Tillat protokoll 89 mellom tunnelendepunkta, og sjekk deretter om plattforma treng eksplisitte naboerklæringar.

Ein tunnel som berre slepp ping gjennom, er eit policyproblem, ikkje eit ruteproblem.

Kontroll 3: stemmer naboparametrane

Område-ID, hello- og dead-intervall, autentisering og stub-flagg må alle stemme. Eit avvik lèt vanlegvis naboen henge i ein synleg tilstand i staden for å feile lydlaust, noko som er nyttig. Samanlikn den køyrande konfigurasjonen i begge endar, ikkje den tiltenkte.

MTU-avviket er det subtile. Det blokkerer databaseutveksling ved ExStart, så naboen når aldri Full.

Kontroll 4: kva seier tilstanden

Tilstanden namngjev feilen. Init tyder at hello kjem inn, men denne rutaren er ikkje ført opp i dei, noko som peikar på ein einvegsveg eller eit multicast-problem. Two-Way er normalt på eit broadcast-segment med ein nabo som ikkje er DR, og unormalt på ein punkt-til-punkt-lenke. Fastlåst ExStart eller Exchange tyder eit MTU- eller databasebeskrivingsproblem. Loading tyder at link-state-førespurnader ikkje vert svara på.

Les tilstanden før du endrar noko, fordi han eliminerer det meste av lista.

show ip ospf neighbor skriv ut tilstanden, naboadressa og dead-timeren. Samanlikn den timeren med hello-intervallet i begge sider: eit dead-intervall på fire gonger hello er normalt, alt anna er eit avvik. Tilstandskolonnen er det raskaste lesestoffet på heile sida.

Kontroll 5: kva vert det faktisk annonsert

Ein Full-nabo er ikkje ei rute. Sjekk kva nettverk som vert oppretta, kva som vert lærde og kva som vert installerte i rutetabellen. Ei manglande nettverkserklæring eller ein redistribusjonspolicy som utelukkar prefikset til nettstaden gjev ein sunn nabo og ein tom tabell.

Test deretter ein applikasjon på vertsnivå og returvegen, fordi ein ruteprotokoll ikkje opnar ein brannmur.

For IPv6 har OSPFv3 eigne krav og er ikkje ein adressefamiliebrytar på kvar OSPFv2-innstilling. Bruk den samsvarande protokollen og plattformdokumentasjonen. Og viss sambandet er éin fast lenke, samanlikn statiske ruter før du legg til eit kontrollplan du må drifte.