Az OSPF-szomszédok nem jönnek létre VPN felett? Ellenőrizze ezeket sorrendben

Az alagút él, az interfészek ugyanabban az alhálózatban vannak, és az OSPF mégsem mutat semmit. Az esetek többségében az alagút rendben van, és egy OSPF-követelmény nem teljesül. Végezze el az alábbi öt ellenőrzést sorrendben, és álljon meg az elsőnél, amelyik elbukik.

Minden ellenőrzésnek külön tünete van, ezért a sorrend fontosabb, mint a lista.

1. ellenőrzés: megfelelő-e a kapcsolatmodell

A pont-pont interfész és a megosztott többes hozzáférésű hálózat különböző OSPF-környezetek. A broadcast-LAN konfiguráció alagútra másolása a leggyakoribb hiba itt. Állítsa be a VPN-implementáció által támogatott hálózattípust, útvonalválasztott alagútnál általában pont-pont. Ezután erősítse meg, hogy a platform egyetért, mert egyes implementációk figyelmen kívül hagyják vagy felülírják a beállítást.

Ha a kapcsolatmodell hibás, a lista további része nem segít.

2. ellenőrzés: átengedik-e a csomagokat

Az OSPFv2 a 89-es IP-protokoll, nem TCP- vagy UDP-port, ezért a portokra írt tűzfalszabály csendben eldobja. A hello üzenetek multicast címekre is mennek, amelyeket egy házirend nem biztos, hogy engedélyez. Engedélyezze a 89-es protokollt az alagút végpontjai között, majd ellenőrizze, igényel-e a platform kifejezett szomszédnyilatkozatokat.

Az az alagút, amely csak pinget enged át, házirend-probléma, nem útválasztási.

3. ellenőrzés: egyeznek-e a szomszédparaméterek

A területazonosítónak, a hello- és dead-intervallumoknak, a hitelesítésnek és a stub jelzőknek mind egyezniük kell. Az eltérés általában látható állapotban hagyja a szomszédot a csendes hiba helyett, ami hasznos. Hasonlítsa össze a futó konfigurációt mindkét végén, nem a tervezettet.

Az MTU-eltérés a finom eset. Az ExStartnál blokkolja az adatbázis-cserét, így a szomszéd soha nem éri el a Full állapotot.

4. ellenőrzés: mit mond az állapot

Az állapot megnevezi a hibát. Az Init azt jelenti, hogy hello érkezik, de ez az útválasztó nem szerepel bennük, ami egyirányú útra vagy multicast-problémára utal. A Two-Way normális broadcast szegmensen egy nem DR szomszéddal, és rendellenes pont-pont kapcsolaton. A beragadt ExStart vagy Exchange MTU- vagy adatbázis-leírási problémát jelent. A Loading azt jelenti, hogy a kapcsolatállapot-kérésekre nem válaszolnak.

Olvassa el az állapotot, mielőtt bármit módosít, mert kizárja a lista nagy részét.

show ip ospf neighbor kiírja az állapotot, a szomszéd címét és a dead időzítőt. Hasonlítsa össze ezt az időzítőt a hello-intervallummal mindkét oldalon: a hello négyszeresének megfelelő dead intervallum normális, bármi más eltérés. Az állapotoszlop a leggyorsabb olvasnivaló az egész oldalon.

5. ellenőrzés: mi hirdetődik valójában

A teljes szomszédság nem útvonal. Ellenőrizze, mely hálózatok keletkeznek, melyek tanulhatók és melyek települnek az útválasztási táblába. A hiányzó hálózati nyilatkozat vagy a telephely-prefixet kizáró újraelosztási házirend egészséges szomszédot és üres táblát eredményez.

Ezután teszteljen egy hosztszintű alkalmazást és a visszautat, mert az útválasztási protokoll nem nyit tűzfalat.

Az IPv6 esetében az OSPFv3-nak saját követelményei vannak, és nem címcsalád-kapcsoló minden OSPFv2-beállításon. Használja a megfelelő protokollt és a platform dokumentációját. És ha a kapcsolat egyetlen fix link, hasonlítsa össze a statikus útvonalakat, mielőtt olyan vezérlősíkot ad hozzá, amelyet üzemeltetnie kell.