I vicini OSPF non si formano su una VPN? Controllate questi punti in ordine
Cinque controlli, ciascuno con il proprio sintomo: modello del collegamento, filtro del protocollo 89, parametri del vicino, stato di adiacenza e infine ciò che viene realmente annunciato.
Il tunnel è attivo, le interfacce sono nella stessa sottorete e OSPF continua a non mostrare nulla. Il più delle volte il tunnel è a posto e un requisito OSPF non è soddisfatto. Eseguite i cinque controlli seguenti in ordine e fermatevi al primo che fallisce.
Ogni controllo ha un sintomo distinto, per questo l’ordine conta più dell’elenco.
Controllo 1: il modello del collegamento è corretto
Un’interfaccia punto-punto e una rete condivisa a accesso multiplo sono ambienti OSPF diversi. Copiare una configurazione LAN broadcast su un tunnel è l’errore più comune qui. Impostate il tipo di rete supportato dall’implementazione VPN, di solito punto-punto per un tunnel instradato. Poi verificate che la piattaforma sia d’accordo, perché alcune implementazioni ignorano o sovrascrivono l’impostazione.
Se il modello del collegamento è sbagliato, nulla di ciò che segue nell’elenco aiuterà.
Controllo 2: i pacchetti sono lasciati passare
OSPFv2 è il protocollo IP 89, non una porta TCP o UDP, quindi una regola firewall scritta per le porte lo scarta in silenzio. Gli hello vanno anche a indirizzi multicast, che una policy potrebbe non consentire. Consentite il protocollo 89 tra gli estremi del tunnel, poi verificate se la piattaforma richiede dichiarazioni di vicino esplicite.
Un tunnel che lascia passare solo ping è un problema di policy, non di routing.
Controllo 3: i parametri del vicino coincidono
L’ID di area, gli intervalli hello e dead, l’autenticazione e i flag stub devono coincidere. Una discrepanza di solito lascia il vicino in uno stato visibile invece di fallire in silenzio, il che è utile. Confrontate la configurazione in esecuzione su entrambi i lati, non quella prevista.
La discrepanza MTU è quella sottile. Blocca lo scambio del database a ExStart, quindi il vicino non raggiunge mai Full.
Controllo 4: cosa dice lo stato
Lo stato nomina il guasto. Init significa che gli hello arrivano ma questo router non è elencato, il che indica un percorso unidirezionale o un problema di multicast. Two-Way è normale su un segmento broadcast con un vicino non DR e anomalo su un collegamento punto-punto. Un ExStart o Exchange bloccato indica un problema di MTU o di descrizione del database. Loading significa che le richieste di stato del collegamento non ricevono risposta.
Leggete lo stato prima di cambiare qualsiasi cosa, perché elimina la maggior parte dell’elenco.
show ip ospf neighbor stampa lo stato, l’indirizzo del vicino e il timer dead. Confrontate quel timer con l’intervallo hello su entrambi i lati: un intervallo dead quattro volte l’hello è normale, qualsiasi altra cosa è una discrepanza. La colonna dello stato è la lettura più rapida dell’intera pagina.
Controllo 5: cosa viene realmente annunciato
Un’adiacenza Full non è una rotta. Verificate quali reti vengono originate, quali apprese e quali installate nella tabella di routing. Una dichiarazione di rete mancante o una policy di redistribuzione che esclude il prefisso del sito producono un vicino sano e una tabella vuota.
Poi provate un’applicazione a livello di host e il percorso di ritorno, perché un protocollo di routing non apre un firewall.
Per IPv6, OSPFv3 ha i propri requisiti e non è un interruttore di famiglia di indirizzi su ogni impostazione OSPFv2. Usate il protocollo corrispondente e la documentazione della piattaforma. E se la connessione è un unico collegamento fisso, confrontate le rotte statiche prima di aggiungere un piano di controllo che dovrete gestire.