Risoluzione dei problemi OSPF: diagnosticare adiacenze, LSAs e problemi di convergenza

Il troubleshooting OSPF in esercizio diventa critico soprattutto quando un errore non si manifesta come un guasto completo, ma come un „a volte funziona, a volte no“: le adiacenze rimangono in uno stato intermedio, mancano singoli prefissi o la convergenza (tempo fino a una situazione di routing stabile dopo una modifica) è significativamente più lunga del previsto. OSPF (Open Shortest Path First) è un protocollo di routing link-state: i Router scambiano informazioni di stato (LSAs, Link-State Advertisements) e calcolano localmente il percorso più breve. Proprio questa meccanica fornisce eccellenti segnali diagnostici — a condizione di procedere in modo strutturato.

Questo contributo è pensato come Runbook: prima le protezioni di sicurezza (Impact, Rückfall), poi una sequenza di controllo chiara per adiacenze, LSAs/LSDB e problemi di convergenza. Dove sono mostrati comandi, sono volutamente tenuti generici: la sintassi varia a seconda della piattaforma (Cisco IOS/IOS-XE, NX-OS, Juniper Junos, FRRouting, MikroTik e altre), ma gli stati, i contatori e i pattern di causa sono in OSPF sostanzialmente identici.

OSPF-Troubleshooting: 1) Vor dem Eingriff: Scope, Risiko und Rückfallstrategie

Prima di modificare „qualsiasi cosa“ in OSPF, chiarite tre punti: cosa è interessato (Scope), quale è il potenziale Impact e come tornare indietro (Rollback). OSPF reagisce spesso immediatamente alle modifiche; un parametro impostato in modo errato può resettare un’adiacenza, rifluire LSAs e quindi sovraccaricare CPU/Control-Plane — particolarmente sui nodi centrali.

Scope schnell eingrenzen

• Nur ein Link / ein Nachbar? Allora spesso è legato all’interfaccia, alla MTU, all’Auth o ai timer.
• Mehrere Nachbarn in einer Area? Allora sono sospetti il tipo di area, i filtri, i link virtuali, il tipo di rete o il consenso DR/BDR.
• „Routen fehlen“ ohne Nachbarproblem? Allora piuttosto tipi di LSA, summarisazione, filtraggio, Max-LSA, logica stub/NSSA o redistribution.
• Convergence langsam con adiacenze altrimenti corrette: SPF/LSA-throttling, LSA-flapping, errori di interfaccia, CPU o LSDB troppo grande.

Rückfallstrategie (praktisch)

Nella gestione OSPF è consolidato pianificare ogni modifica in modo che possa essere annullata senza grandi operazioni OSPF:

• Konfig-Backup (versionierung, change reference, timestamp).
• Ein Parameter pro Change (non Hello, Auth e tipo di rete contemporaneamente).
• Wartungsfenster per potenziali Neighbor-Resets (Auth/MTU/tipo di rete/cambio area).
• Plan B: route statiche temporanee, adeguamento temporaneo dei costi (OSPF cost), o shutdown/No-Shutdown controllato di singoli link — ma come intervento consapevole, non come „Try & Error“.

2) OSPF-Nachbarbeziehungen: Zustände verstehen und gezielt testen

Gli OSPF Neighbor States sono la vostra prima bussola. Importante: a seconda del tipo di rete non tutte le adiacenze sono „FULL“. Su reti Broadcast e NBMA spesso è FULL solo l’adiacenza verso il DR/BDR (Designated Router / Backup Designated Router); le altre rimangono in 2-WAY, il che può essere corretto. Su Point-to-Point è normale che sia FULL tra i due router.

Gli stati e cosa significano in esercizio

• DOWN: nessun Hello visto. Cause frequenti: L2/L3/ACL/multicast/interfaccia down.
• INIT: Hello ricevuti, ma la propria Router-ID non viene riportata nell’Hello. Tipico per traffico unidirezionale o filtri/ACL.
• 2-WAY: bidirezionale, ma (su Broadcast/NBMA) non adiacente al DR/BDR. Può essere corretto.
• EXSTART/EXCHANGE: sincronizzazione della LSDB (DBD). Spesso MTU mismatch o frammentazione pacchetti/filtri difettosi.
• LOADING: LSR/LSU (Link State Request/Update) in corso ma non completati. Spesso filtri LSA, perdita di pacchetti, MTU/frammentazione o control-plane sovraccaricato.
• FULL: LSDB sincronizzata (per l’adiacenza).

Sequenza di verifica per „Neighbor non diventa FULL“

Procedete dall’esterno verso l’interno: prima connettività e interfaccia, poi parametri OSPF, infine LSDB/Exchange.

Passo A: la connettività L3 per OSPF è possibile?

OSPF usa il protocollo IP 89 (non TCP/UDP). Su reti Broadcast gli Hello vengono inviati a 224.0.0.5 (AllSPFRouters) e 224.0.0.6 (AllDRouters). Su Point-to-Point può essere comunque multicast, a seconda di piattaforma/tipo di rete. Firewall, ACL, security-group o CoPP (Control Plane Policing) devono permetterlo.

Approccio minimo di capture (Linux-host come analisi Tap/Span; sui router spesso ci sono funzionalità integrate di packet-capture):

# Auf einem Mirror-Port oder Capture-Host:
# OSPF-Protokoll 89 und Multicast-Ziele prüfen
sudo tcpdump -ni eth0 'ip proto 89 or (ip multicast and (host 224.0.0.5 or host 224.0.0.6))'

Cosa cercare: Hello periodici (default 10s su Broadcast, 30s su NBMA – può variare). Se si vede solo una direzione, corrisponde a INIT (unidirezionale). Se non si vede nulla: problemi L2/VLAN, interfaccia o filtri.

Passo B: i parametri „must-match“ coincidono?

Per un’adiacenza OSPF devono coincidere parametri centrali. Quali nello specifico dipende dal tipo di rete e dal set di funzionalità, ma questi sono i classici:

• Area-ID: entrambe le parti devono trovarsi nello stesso contesto Area OSPF (es. Area 0 come backbone).
• Hello/Dead-Interval: devono corrispondere, altrimenti il neighbor ignorerà gli Hello.
• Tipo di rete (Broadcast, Point-to-Point, NBMA): influenza l’elezione DR/BDR e le aspettative sulle adiacenze.
• Autenticazione: il tipo (es. Simple/MD5/HMAC a seconda della piattaforma) e la chiave devono corrispondere. Importante: l’autenticazione è spesso „silenziosa“ — chiavi errate portano a Down/Init.
• Flag Stub/Tipo Area: in aree Stub/NSSA i tipi di area devono essere coerenti, altrimenti l’adiacenza fallisce.

Trappole pratiche: modifiche al tipo di area o all’autenticazione spesso causano reset immediati dei neighbor. Pianificate ciò come evento operativo (monitoraggio, finestra di manutenzione).

Passo C: verificare accuratamente MTU mismatch

MTU-Mismatch è una delle cause più frequenti di EXSTART/EXCHANGE. OSPF negozia durante la sincronizzazione del database le dimensioni dei pacchetti; se un lato invia pacchetti più grandi di quanto l’altro accetti, si osservano ritrasmissioni, exchange-loop o stati bloccati. Succede spesso dopo modifiche a VLAN-/MPLS-/tunnel, quando la L2-MTU è stata regolata solo da un lato.

• Indiz: Il neighbor oscilla tra EXSTART e EXCHANGE o rimane bloccato in quello stato.
• Warum: i pacchetti DBD/LSU vengono scartati o frammentati/bloccati.
• Risiko: il „Schnellfix“ tramite MTU-Ignore può mascherare i sintomi, ma i reali problemi di frammentazione/Path-MTU permangono.

Operational sinnvoll: impostare la MTU in modo coerente su entrambe le estremità e, se necessario, verificare la Path-MTU lungo il percorso (z. B. bei L3-Portchannels, QinQ, GRE/IPsec, VXLAN-Underlay).

Schritt D: DR/BDR und Netztyp als Fehlerquelle

Su segmenti Broadcast o NBMA viene eletto un DR/BDR. Questo influisce verso chi viene stabilita un’adjacenza completa. Se vi aspettate che „alle zu allen FULL sind“, ma siete su Broadcast con DR/BDR, è normale vedere 2-WAY verso neighbor non-DR. Diventa problematico quando DR/BDR cambia continuamente (Flapping) o il DR non è raggiungibile.

• Typische Ursachen: dominio L2 instabile, perdita di pacchetti, priorità differenti o riavvii dei gateway.
• Auswirkung: ripetuta sincronizzazione della LSDB, aumento del flusso di LSA, problemi di convergenza.

3) LSAs und LSDB: Wenn Routen fehlen oder „inkonsistent“ wirken

Se i neighbor sono FULL, ma mancano rotte o sono pesate in modo errato, le LSA e la Link-State Database (LSDB, il database topologico interno OSPF) sono il passo successivo. OSPF non calcola „aus dem Nichts“: se un’informazione non è presente come LSA nella LSDB, non può comparire nella tabella di routing.

LSA-Typen in der Praxis (kurz und betriebsnah)

• Type 1 (Router-LSA): descrive i link di un router all’interno di un’area. Base per SPF.
• Type 2 (Network-LSA): viene generata dal DR su segmenti Broadcast/NBMA e descrive il segmento di rete condiviso.
• Type 3 (Summary-LSA): dai ABR (Area Border Router) per reti aggregate o reindirizzate tra aree.
• Type 4 (ASBR-Summary): indica il percorso verso un ASBR (Autonomous System Boundary Router) che inietta rotte esterne.
• Type 5 (External-LSA): rotte esterne (redistribuzione), non consentite nelle stub-area.
• Type 7 (NSSA-External): rotte esterne in aree NSSA; vengono tradotte in Type 5 sull’ABR.

Perché è importante: se, ad esempio, in una stub-area vi aspettate improvvisamente Type-5-External, non è che „OSPF sia rotto“, ma il design o la definizione dell’area non corrisponde all’aspettativa.

Diagnosepfad: „Route fehlt“ in fünf Schritten

1. Il prefisso è presente nella LSDB? Se no: verificare origine/redistribuzione/ABR/filtri.
2. È presente nel tipo LSA corretto? Esterno (Type 5/7) vs. interno (Type 1/3).
3. Proviene dall’area prevista? Verificare il design dell’area e i percorsi ABR.
4. Viene installato? Administrative Distance, RIB-Failure, Route-Preference o Policy possono impedire l’installazione.
5. Viene ulteriormente annunciato? Filtri, summarizzazione, traduzione NSSA o problemi Max-LSA/LSA-Refresh.

Per la raccolta dei dati è utile predisporre una raccolta standardizzata di comandi “Show” per piattaforma. A titolo esemplificativo (come Platzhalter-Runbook, adattare i comandi al vostro OS):

# Runbook: Daten sammeln (als Vorlage, Kommandos je nach Plattform ersetzen)
# 1) OSPF Nachbarn + Zustände
# 2) OSPF Interface-Details (Timer, Netztyp, MTU, Auth)
# 3) LSDB-Auszug: relevante LSA-Typen und betroffene Präfixe
# 4) Routingtabelle: Präfix vorhanden? über welchen Next-Hop?
# 5) Logs: Neighbor-Resets, Auth-Fehler, MTU/DBD-Hinweise

Cause tipiche di LSA mancanti o „anomale“

• Incoerenza di area / tipo di area errato: Stub/NSSA incoerenti, violazione del design del backbone, link virtuali instabili.
• Filtri OSPF o route policy: filtraggio in ingresso o in uscita di Summary-/External-LSAs (dipende dalla piattaforma).
• Summarizzazione: l’ABR effettua la sintesi; i singoli prefissi non vengono più mostrati con granularità. Questo è voluto, ma può complicare la risoluzione dei problemi.
• Problemi di redistribuzione: rotte esterne non vengono iniettate (es. assenza di regole di matching) o distribuite con tipo errato (E1/E2).
• Max-LSA / limiti LSDB: alcune piattaforme possono, in caso di overflow della LSDB, interrompere le adiacenze o rifiutare LSAs – rilevante in domini di grandi dimensioni.

4) Problemi di convergenza: quando OSPF „troppo“ impiega o appare instabile

La convergenza non è solo „il routing torna a funzionare prima o poi“. In esercizio conta se le vostre applicazioni (VoIP, ERP, VDI, Storage, API-Gateways) sono stabili entro secondi definiti. La convergenza OSPF è costituita da più tempi: rilevamento dell’evento (Dead-Timer o BFD), flooding delle LSAs, calcolo SPF, installazione nella tabella di routing e, se necessario, programmazione della FIB in hardware.

Prima distinguere: lento vs. instabile

• Lento: dopo un evento sul link impiega riproducibilmente „troppo“ tempo, ma poi si stabilizza.
• Instabile: le adiacenze vanno in flap, le LSA vengono continuamente rifloodate, le rotte cambiano frequentemente.

Cause comuni di convergenza lenta

• Dead-interval troppo alto: il rilevamento dell’evento richiede troppo tempo (classico 40s). Rimedi: tuning dei timer o BFD (Bidirectional Forwarding Detection; controllo di liveness più rapido a un livello inferiore rispetto a OSPF).
• Control-Plane sovraccaricata: l’elaborazione SPF e LSA compete con altri task; visibile come CPU elevata o accodamento.
• LSDB ampia: molti LSA significano più flooding e tempi di calcolo SPF più lunghi.
• SPF/LSA-Throttling: i meccanismi di protezione limitano i calcoli durante sovraccarichi di eventi; utili contro l’instabilità, ma svantaggiosi per il comportamento „immediato“.
• Problemi L2: perdita di pacchetti/jitter sul link; OSPF deve ritrasmettere, l’adjacency si risincronizza.

Cause comuni di convergenza instabile (Flapping)

• Fattori fisici: errori CRC, mismatch duplex/velocità, ottiche instabili, tratte wireless/WAN variabili.
• ECMP/Asimmetria: il traffico prende percorsi differenti, i ritorni possono essere filtrati (sintomo INIT).
• Cambio DR/BDR su segmenti broadcast causato da instabilità L2 o conflitti di priorità.
• Errata configurazione: timer diversi, rotazione della chiave di autenticazione solo su un lato, MTU non aggiornata ovunque dopo una modifica.

Strategia di misura e osservazione (adatta al monitoring)

Per „Monitoraggio“ conta che non vi limitiate a eseguire il debug della convergenza una sola volta, ma che la rendiate misurabile in modo continuativo:

• Neighbor-Uptime e Flap-Rate: numero di transizioni di stato per ora/giorno.
• LSA-Churn: quante LSA vengono generate/refresh/ritrasmesse per unità di tempo.
• SPF-Runs: frequenza e durata delle esecuzioni SPF (se la piattaforma fornisce metriche).
• Tassi di errore delle interfacce: CRC, input drops, queue drops, potenza ottica (su fibra).
• Correlazione eventi: Link-Down/Up, variazioni dei neighbor OSPF, picchi di CPU, e successivi allarmi applicativi.

Se misurate solo ‚Ping è di nuovo attivo‘, rischiate di non rilevare micro-interruzioni che, per esempio, provocano tempeste di reset TCP o perdite di pacchetti.

5) Liste di controllo pratiche: verificare rapidamente di non aver trascurato nulla

Lista di controllo A: il neighbor non si porta UP

• Interfaccia up/up, VLAN/Tagging/Trunking corretti
• Indirizzamento IP / maschera di sottorete corretti, nessun IP duplicato
• OSPF attivato sull’interfaccia corretta (verificare passive-interface)
• I timer Hello/Dead coincidono
• ID area e tipo area corrispondono (Stub/NSSA)
• Autenticazione: metodo + Key/Key-ID coerenti
• MTU coerente su entrambe le direzioni; frammentazione/PMTUD non bloccata
• Tipo di rete coerente (p2p vs broadcast); comportamento DR/BDR compreso
• ACL/Firewall/CoPP consentono il protocollo IP 89 e il multicast

Lista di controllo B: neighbor in FULL ma route mancanti

• Prefisso presente nella LSDB? Se no: fonte/redistribuzione/ABR/filter
• Tipo LSA plausibile (interno vs esterno; traduzione NSSA)
• Summarization attiva sull’ABR? Verificare l’aspettativa sulle rotte dettagliate
• Routing table/RIB installata? Administrative distance/policy/next-hop ricorsivo
• Forwarding/FIB corretto? (programmazione hardware, contesto VRF)

Lista di controllo C: convergenza troppo lenta

• Rilevamento eventi: Dead-Interval vs. BFD
• LSA-Flooding: perdita di pacchetti, ritrasmissioni, errori di interfaccia
• SPF: CPU/memoria, parametri di throttling SPF, dimensione LSDB
• Design: aree troppo grandi, troppi ABR/ASBR, redistribuzioni non necessarie
• Origine dei cambi: link instabili, portchannel che flappano, ottiche difettose

6) Implementazione: fix tipici — e quando falliscono

Nella risoluzione dei problemi è allettante applicare workaround ‚rapidi‘. Meglio: isolare la causa, poi applicare una correzione con analisi chiara degli effetti collaterali.

Ottimizzazione dei timer e BFD

La messa a punto dei timer (riduzione di Hello/Dead) può accelerare la convergenza, ma aumenta la sensibilità a jitter e brevi perdite di pacchetti. BFD è spesso la variante più pulita: fornisce un rilevamento rapido di link/percorso, mentre OSPF mantiene la logica di topologia. BFD può fallire su percorsi asimmetrici, a causa di bug di hardware-offload o per intervalli troppo aggressivi nel WAN.

Risolvere problemi MTU e Path-MTU

La soluzione sostenibile è la consistenza: stessa MTU, stesso incapsulamento e nessun blocco di ICMP, se viene utilizzato PMTUD (Path MTU Discovery). «MTU Ignore» può aiutare temporaneamente, ma è rischioso: grandi LSU o il traffico applicativo possono comunque frammentare o venire scartati.

Semplificare il design delle Area

Molti problemi di convergenza e relativi alle LSA sono conseguenza del design: domini di flooding troppo grandi, Externals non necessari o confini di Area poco chiari. Una pianificazione accurata di Area-0, una redistribuzione limitata e una summarization sensata riducono l’LSA‑Churn. Questo può fallire per motivi organizzativi (sforzo di change) o per dipendenze quando le applicazioni si aspettano percorsi IP «rigidi».

Stabilizzare DR/BDR

Se il flapping di DR/BDR è un problema, aiutano priorità chiare e segmenti L2 stabili. In alcuni design Point-to-Point (dove possibile) è più semplice da gestire rispetto a grandi domini broadcast. Questo può fallire se il design L2 (es. Campus‑VLANs) non è facilmente modificabile.

7) Documentazione e routine operative: dalla risoluzione dei problemi alla stabilità

I problemi OSPF si ripresentano se la conoscenza operativa non viene inserita «nel processo». Due componenti semplici si sono dimostrate efficaci:

• Pacchetto diagnostico standardizzato: quali output raccogliete in caso di eventi di Neighbor/LSA/Convergence? Dove vengono archiviati? Chi li analizza?
• Guardrail per le modifiche: per rotazione delle chiavi di autenticazione, modifiche MTU, cambi di Area e redistribuzione esiste un breve runbook con controlli prima/dopo e rollback.

Pianificate inoltre i limiti di capacità: se la LSDB cresce (sedi, VRF, nuove Externals), aumenta non solo il fabbisogno di memoria ma anche il carico di calcolo e di flooding. Trend precoci valgono più di un singolo «dopo l’espansione tutto è diventato lento».

Conclusione: con una sequenza di controllo fissa i problemi OSPF diventano gestibili

La risoluzione dei problemi OSPF diventa chiaramente più semplice se si separa la diagnosi in modo coerente su tre livelli: relazioni di neighborship (stati e parametri che devono corrispondere), LSAs/LSDB (l’informazione è presente e del tipo corretto?), e convergenza (rilevazione eventi, flooding, SPF, installazione). Con un runbook chiaro, capture riproducibili e monitoraggio di flaps, LSA‑Churn e errori di interfaccia individuate le cause più rapidamente — ed evitate fix che spostano solo i sintomi.

Per questo tema sono importanti anche le relazioni di neighborship OSPF e le LSA OSPF. L’articolo inquadra questi aspetti in modo chiaro e mostra cosa conta nella pratica.