OSPF-bure vorm nie oor ’n VPN nie? Gaan hierdie punte in volgorde na
Vyf kontroles, elk met sy eie simptoom: skakelmodel, protokol 89-filtering, buurparameters, aangrensingstatus, en dan wat werklik geadverteer word.
Die tonnel is op, die koppelvlakke sit in dieselfde subnet, en OSPF wys steeds niks. Meestal is die tonnel reg en een OSPF-vereiste word nie nagekom nie. Werk die vyf kontroles hieronder in volgorde deur en stop by die eerste een wat misluk.
Elke kontrole het ’n eiesoortige simptoom, en daarom is die volgorde belangriker as die lys.
Kontrole 1: is die skakelmodel reg
’n Punt-tot-punt-koppelvlak en ’n gedeelde multi-toegang-netwerk is verskillende OSPF-omgewings. Om ’n broadcast-LAN-konfigurasie op ’n tonnel te kopieer, is die algemeenste fout hier. Stel die netwerktipe wat die VPN-implementering ondersteun, gewoonlik punt-tot-punt vir ’n geroteerde tonnel. Bevestig dan dat die platform saamstem, want sommige implementerings ignoreer of oorskryf die instelling.
As die skakelmodel verkeerd is, sal niks later in die lys help nie.
Kontrole 2: word die pakkette deurgelaat
OSPFv2 is IP-protokol 89, nie ’n TCP- of UDP-poort nie, so ’n firewall-reël wat vir poorte geskryf is, laat dit stilweg val. Hallo's gaan ook na multicast-adresse, wat ’n beleid dalk nie toelaat nie. Laat protokol 89 tussen die tonnel-eindpunte toe en kyk dan of die platform eksplisiete buurstellings nodig het.
’n Tonnel wat pings en niks anders deurlaat, is ’n beleidsprobleem, nie ’n roeteringsprobleem nie.
Kontrole 3: stem die buurparameters ooreen
Area-ID, hallo- en dooie intervalle, verifikasiemethode en stub-vlae moet almal ooreenstem. ’n Wanverhouding laat die buur gewoonlik in ’n sigbare toestand vassteek eerder as om stilweg te misluk, wat nuttig is. Vergelyk die lopende konfigurasie aan beide kante, nie die beoogde een nie.
’n MTU-wanverhouding is die subtiele een. Dit blokkeer databasis-uitruiling by ExStart, so die buur bereik nooit Full nie.
Kontrole 4: wat sê die toestand
Die toestand noem die faling. Init beteken hallo's kom aan, maar hierdie roeteerder word nie daarin gelys nie, wat op ’n eenrigtingpad of ’n multicast-probleem dui. Two-Way is normaal op ’n broadcast-segment met ’n nie-DR-buur en abnormaal op ’n punt-tot-punt-skakel. ExStart of Exchange wat vashaak, beteken ’n MTU- of databasisbeskrywingsprobleem. Loading beteken daar word nie op link-state-versoeke geantwoord nie.
Lees die toestand voordat jy enigiets verander, want dit elimineer die meeste van die lys.
show ip ospf neighbor druk die toestand, die buuradres en die dooie tydhouer uit. Vergelyk daardie tydhouer met die hallo-interval aan beide kante: ’n dooie interval van vier keer die hallo is normaal, enigiets anders is ’n wanverhouding. Die toestandkolom is die vinnigste lees op die hele bladsy.
Kontrole 5: wat word werklik geadverteer
’n Full-aangrensing is nie ’n roete nie. Kyk watter netwerke oorsprong het, watter geleer word en watter in die roeteringstabel geïnstalleer is. ’n Ontbrekende netwerkstelling of ’n herverspreidingsbeleid wat die werfprefiks uitsluit, lewer ’n gesonde buur en ’n leë tabel.
Toets dan ’n toepassing op hostvlak en die terugpad, want ’n roeteringsprotokol maak nie ’n firewall oop nie.
Vir IPv6 het OSPFv3 sy eie vereistes en is dit nie ’n adresfamilie-skakelaar op elke OSPFv2-instelling nie. Gebruik die passende protokol- en platformdokumentasie. En as die verbinding een vaste skakel is, vergelyk statiese roetes voordat jy ’n beheervlak byvoeg wat jy moet bedryf.