OSPF-naboer dannes ikke over en VPN? Tjek disse i rækkefølge
Fem kontroller, hver med sit eget symptom: linkmodel, filtrering af protokol 89, nabo-parametre, adjacency-tilstand og til sidst, hvad der faktisk annonceres.
Tunnelen er oppe, interfaceene ligger i samme subnet, og OSPF viser stadig intet. Det meste af tiden er tunnelen fin, og ét OSPF-krav er ikke opfyldt. Gå gennem de fem kontroller nedenfor i rækkefølge, og stop ved den første, der fejler.
Hver kontrol har et særskilt symptom, og derfor er rækkefølgen vigtigere end listen.
Kontrol 1: er linkmodellen rigtig
Et punkt-til-punkt-interface og et delt multi-access-netværk er forskellige OSPF-miljøer. At kopiere en broadcast-LAN-konfiguration over på en tunnel er den mest almindelige fejl her. Sæt den netværkstype, som VPN-implementeringen understøtter, normalt punkt-til-punkt for en routet tunnel. Bekræft derefter, at platformen er enig, fordi nogle implementeringer ignorerer eller overskriver indstillingen.
Hvis linkmodellen er forkert, hjælper intet senere på listen.
Kontrol 2: slippes pakkerne igennem
OSPFv2 er IP-protokol 89, ikke en TCP- eller UDP-port, så en firewallregel skrevet til portmapper dropper den lydløst. Hello går også til multicast-adresser, som en politik måske ikke tillader. Tillad protokol 89 mellem tunnelendepunkterne, og tjek derefter, om platformen kræver eksplicitte naboerklæringer.
En tunnel, der kun slipper ping igennem, er et politikproblem, ikke et routingproblem.
Kontrol 3: matcher nabo-parametrene
Område-ID, hello- og dead-intervaller, godkendelse og stub-flag skal alle stemme. En uoverensstemmelse efterlader normalt naboen i en synlig tilstand i stedet for at fejle lydløst, hvilket er nyttigt. Sammenlign den kørende konfiguration i begge ender, ikke den tilsigtede.
MTU-uoverensstemmelse er den subtile. Den blokerer databaseudveksling ved ExStart, så naboen når aldrig Full.
Kontrol 4: hvad siger tilstanden
Tilstanden navngiver fejlen. Init betyder, at hello ankommer, men denne router er ikke nævnt i dem, hvilket peger på en envejsvej eller et multicast-problem. Two-Way er normalt på et broadcast-segment med en nabo, der ikke er DR, og unormalt på et punkt-til-punkt-link. Fastlåst ExStart eller Exchange betyder et MTU- eller databasebeskrivelsesproblem. Loading betyder, at link-state-anmodninger ikke besvares.
Læs tilstanden, før du ændrer noget, fordi den udelukker det meste af listen.
show ip ospf neighbor udskriver tilstanden, naboens adresse og dead-timeren. Sammenlign den timer med hello-intervallet i begge sider: et dead-interval på fire gange hello er normalt, alt andet er en uoverensstemmelse. Tilstandskolonnen er det hurtigste læs på hele siden.
Kontrol 5: hvad annonceres der faktisk
Et Full-adjacency er ikke en rute. Tjek, hvilke netværk der oprettes, hvilke der læres, og hvilke der installeres i routingtabellen. En manglende netværkserklæring eller en redistributionspolitik, der udelukker stedets prefix, giver en sund nabo og en tom tabel.
Test derefter en applikation på hostniveau og returvejen, fordi en routingprotokol ikke åbner en firewall.
For IPv6 har OSPFv3 sine egne krav og er ikke en adressefamilie-kontakt på hver OSPFv2-indstilling. Brug den matchende protokol og platformsdokumentationen. Og hvis forbindelsen er ét fast link, så sammenlign statiske ruter, før du tilføjer et kontrolplan, du skal drive.