Perché la scalabilità di EIGRP è una questione di “query”

EIGRP è un protocollo a vettore di distanza avanzato basato sull’algoritmo DUAL. La sua velocità di convergenza dipende da un fatto chiave: quando un router perde la rotta migliore verso una destinazione e non dispone di un percorso di backup pre-calcolato, mette la rotta in stato Active e invia dei query ai neighbor. La scalabilità di un dominio EIGRP si misura quindi da quanto lontano si propagano questi query. Tutte le tecniche di ottimizzazione che seguono servono a un unico scopo: limitare l’ambito dei query (query scope).

Feasible successor e convergenza rapida

Per ogni destinazione DUAL calcola due valori:

  • Feasible Distance (FD): la metrica migliore locale verso la destinazione.
  • Reported Distance (RD): la metrica annunciata dal neighbor.

Un neighbor diventa feasible successor (percorso di backup) se soddisfa la Feasibility Condition: RD del neighbor < FD del successor attuale. Questa condizione garantisce l’assenza di loop.

Il punto d’esame è netto: se esiste un feasible successor, alla caduta del successor la convergenza è immediata e locale — nessun query, nessun passaggio in Active. Se non esiste un feasible successor, la rotta va Active e partono i query. Progettare l’indirizzamento e la topologia in modo da avere sempre un FS è il primo strumento di ottimizzazione.

Summarization manuale ai confini

La summarization non serve solo a ridurre la routing table: agisce come barriera per i query. Si configura sull’interfaccia in uscita:

interface GigabitEthernet0/1
 ip summary-address eigrp 100 10.10.0.0 255.255.0.0

Il router che origina la summary installa automaticamente una rotta verso Null0 (default AD 5) come protezione anti-loop. Effetto sulla convergenza: quando un router a valle riceve un query per una subnet specifica (es. 10.10.7.0/24) ma conosce solo la summary 10.10.0.0/16, risponde subito con “unreachable” perché non ha la rotta specifica. Il query si ferma al confine di summarization e non propaga oltre. Posizionare i confini di summary in punti gerarchici (tipicamente distribution → core) è la tecnica cardine per contenere il query domain.

EIGRP stub: limitare i query nell’hub-and-spoke

Uno stub router annuncia ai neighbor di essere terminale: i vicini non gli inviano query. È lo strumento decisivo nelle topologie hub-and-spoke.

router eigrp 100
 eigrp stub connected summary

Le opzioni principali: connected, summary, static, redistributed, receive-only. Il default di eigrp stub (senza parametri) equivale a connected summary.

In un design con un hub e decine di spoke, senza stub la perdita di una rotta obbliga l’hub a interrogare tutti gli spoke, moltiplicando i query. Configurando gli spoke come stub, l’hub li salta completamente: il query scope collassa e la convergenza resta rapida anche con centinaia di spoke (scenario tipico DMVPN).

Stuck-In-Active (SIA)

Un router in Active attende le reply entro l’active timer (default 180 secondi). Il meccanismo SIA-Query / SIA-Reply verifica periodicamente se il neighbor è ancora vivo prima di dichiarare il problema. Se una reply non arriva, la rotta è Stuck-In-Active e l’adiacenza EIGRP viene resettata (log DUAL-3-SIA).

Cause tipiche: query scope troppo ampio, link lenti/instabili, router sovraccarichi, unicast persi. Le contromisure di design sono summarization e stub, che riducono a monte il numero e la portata dei query.

EIGRP vs OSPF: query bounding contro gerarchia ad aree

Aspetto EIGRP OSPF
Contenimento eventi Query bounding (summary + stub) Confini d’area / ABR + tipi di area (stub, totally stubby)
Vincolo di summarization Ovunque, su qualsiasi interfaccia Solo su ABR/ASBR
Requisiti topologici Flessibile, nessun vincolo d’area Backbone Area 0 contigua obbligatoria
Hub-and-spoke Nativamente idoneo con eigrp stub Richiede design d’area attento (spesso spoke in area stub)

Quando preferire EIGRP: topologie hub-and-spoke / DMVPN con molti spoke, dove eigrp stub elimina i query verso i rami e la summarization sull’hub nasconde le subnet interne. Il vincolo OSPF dell’Area 0 contigua e la necessità di ABR per la summarization rendono EIGRP più snello in questi scenari.

Trappole tipiche d’esame

  • Query che propagano troppo / SIA ricorrenti in hub-and-spoke → configurare eigrp stub sugli spoke: l’hub smette di interrogarli e il query scope si riduce.
  • Convergenza lenta con passaggi in Active nonostante link ridondati → manca il feasible successor; rivedere indirizzamento e metriche perché la Feasibility Condition sia soddisfatta (backup pre-calcolato = niente query).
  • Serve contenere i query al confine distribution → ip summary-address eigrp sull’interfaccia: la summary blocca i query per le subnet specifiche a valle.
  • Traffico verso subnet aggregata scartato / loop dopo summarization → è il comportamento atteso della rotta verso Null0 (AD 5) sul router che origina la summary; non è un errore.
  • Spoke che deve comunque annunciare reti ridistribuite → il default connected summary non basta; aggiungere l’opzione redistributed (o static) al comando eigrp stub.