Cisco 300-410: Progettazione, Metriche e Convergenza EIGRP — Guida allo studio

By Laurynas Brazys · 16 August 2026 · #cisco #300-410 #certification #exam-prep #study-guide

Fa parte della Cisco CCNP Enterprise 300-410 ENARSI — Guida allo studio. Esercitati con risposte verificate nel centro esami Cisco, oppure fai test cronometrati su ExamRoll.io.

Panoramica

L’Enhanced Interior Gateway Routing Protocol (EIGRP) è un protocollo di routing distance-vector a rapida convergenza e senza loop che utilizza il Diffusing Update Algorithm (DUAL) per calcolare percorsi di backup ed evitare loop transitori. Le scelte progettuali relative a metriche, selezione del percorso, contenimento delle query, summarization, formazione delle adiacenze, autenticazione e redistribuzione influenzano direttamente la stabilità e il tempo di convergenza. Questa sezione descrive come progettare, configurare e risolvere i problemi di EIGRP per un comportamento deterministico in implementazioni IPv4 e IPv6.

Funzionamento di DUAL e Selezione del Percorso

EIGRP utilizza DUAL per mantenere una topologia senza loop e accelerare la convergenza.

• Successor: Il next hop primario per una destinazione. Installato nella tabella di routing.
• Feasible Distance (FD): La migliore metrica conosciuta dal router locale verso una destinazione (attraverso il successor).
• Reported Distance (RD): La metrica verso la destinazione riportata da un neighbor (chiamata anche advertised distance).
• Feasible Successor (FS): Un next hop di backup garantito senza loop dalla Feasibility Condition (FC).

Feasibility Condition: Un neighbor si qualifica come feasible successor se la sua RD verso la destinazione è strettamente inferiore alla FD locale verso quella destinazione tramite il successor corrente: RDneighbor < FDlocal. Questo garantisce che il neighbor sia più vicino alla destinazione rispetto al router locale, prevenendo i loop senza richiedere un calcolo SPF completo.

Risultati comportamentali:

• Se una destinazione perde il suo successor e esiste almeno un FS, il router esegue uno switchover locale immediato senza inviare query, ottenendo una convergenza inferiore al secondo su link a velocità LAN.
• Se non esiste alcun FS, la destinazione passa allo stato Active e il router invia query ai neighbor per trovare un sostituto. La progettazione dello scoping delle query diventa critica per evitare ritardi.

Load balancing a costo diseguale con variance:

• EIGRP installa percorsi multipli quando è configurata la variance e tali percorsi sono FS. Un percorso è idoneo se la sua FD ≤ (variance × FD del miglior successor). Solo gli FS possono essere installati per la condivisione del traffico; i percorsi non-FS a costo uguale non vengono utilizzati per evitare loop.
• La condivisione del traffico può essere bilanciata (impostazione predefinita, proporzionale alle metriche inverse) o minimizzata con traffic-share min across-interfaces.

Esempio: router eigrp 100 variance 2 traffic-share balanced

Nota di progettazione: Se esistono link multipli ma non soddisfano la FC, considerare di modificare il delay dell’interfaccia (non la bandwidth) per influenzare le relazioni FD/RD. Non modificare i valori K per questo scopo.

Modelli di Configurazione, Formazione delle Adiacenze e Autenticazione

EIGRP supporta i modelli di configurazione classic e named.

EIGRP Classic (IPv4): router eigrp 100 network 10.0.0.0 0.0.255.255 passive-interface GigabitEthernet0/2

• La summarization e l’autenticazione per interfaccia sono configurate a livello di interfaccia.

EIGRP Named (consolida IPv4/IPv6 e centralizza le policy): router eigrp FABRIC address-family ipv4 unicast autonomous-system 100 af-interface default passive-interface network 10.0.0.0 0.0.255.255 address-family ipv6 unicast autonomous-system 100 af-interface GigabitEthernet0/1 no shutdown

Scoperta dei neighbor:

• Timer Hello/hold: predefiniti 5/15 secondi su link ad alta velocità, 60/180 su link a bassa velocità. I timer non devono necessariamente corrispondere; il tempo di hold accettato è quello pubblicizzato dal neighbor.
• Destinazioni multicast: 224.0.0.10 (IPv4) e FF02::A (IPv6).
• passive-interface sopprime i pacchetti hello; da usare su porte rivolte all’accesso o dove non si deve formare alcuna adiacenza.

Autenticazione:

• Autenticazione MD5/HMAC-SHA per interfaccia in modalità Classic: interface GigabitEthernet0/0 ip authentication mode eigrp 100 md5 ip authentication key-chain eigrp 100 EIGRP-KEYS

• In modalità named, applicare l’autenticazione sotto af-interface. Tutti i neighbor su un segmento devono condividere l’algoritmo e le chiavi; discrepanze impediscono la formazione dell’adiacenza.

Routing Stub:

• Configurare solo sullo stub stesso; i neighbor apprendono la capacità di stub e sopprimono le query non essenziali. router eigrp 100 eigrp stub connected summary

Le opzioni stub predefinite pubblicizzano le rotte connesse (connected) e di riepilogo (summary). Aggiungere rotte statiche o redistribuite secondo necessità.

EIGRP per IPv6:

• Richiede un router ID a 32 bit e l’attivazione per interfaccia. ipv6 unicast-routing ipv6 router eigrp 100 eigrp router-id 1.1.1.1 ! interface GigabitEthernet0/1 ipv6 address 2001:db8:1::1/64 ipv6 eigrp 100

Metriche: Composite e Wide, Valori K e Compatibilità

Metrica composita (classic):

• Valori K predefiniti: K1=1 (bandwidth), K3=1 (delay), K2=K4=K5=0. Metrica effettiva = 256 × (inverso della minima bandwidth del link + delay cumulativo). Carico (load) e affidabilità (reliability) sono ignorati per impostazione predefinita.
• Non modificare i valori K in progetti di produzione; tutti i neighbor devono avere valori K esattamente corrispondenti, altrimenti le adiacenze non si formano.

Metriche Wide:

• Le metriche Wide estendono la scala e la precisione della metrica (in particolare per link a banda molto alta/basso delay) e aggiungono margine per le funzionalità di TE. Tutti i neighbor devono supportare e negoziare la stessa versione della metrica EIGRP. Versioni della metrica o valori K non corrispondenti impediscono la formazione dell’adiacenza.
• Best practice per la manipolazione della metrica:
  • Preferire la modifica del delay dell’interfaccia per influenzare la preferenza del percorso; è un valore additivo e deterministico.
  • Evitare di impostare una bandwidth non realistica; ciò influisce anche sul QoS e su altri sottosistemi.
  • Utilizzare default-metric o metriche esplicite per la redistribuzione per garantire una selezione del percorso prevedibile.

Metriche di redistribuzione: router eigrp 100 default-metric 100000 10 255 1 1500 redistribute ospf 1 route-map TAG-OSPF

Convergenza, query, summarizzazione e confini delle query

Query e Stuck-in-Active (SIA):

• Quando non esiste un FS, le rotte passano allo stato Active e il router invia query a tutti i vicini, ad eccezione di quelli che sono stub o che hanno confini di summarizzazione. Ogni vicino interrogato (queried) deve rispondere prima della scadenza dell’active-time (predefinito 3 minuti). La mancata ricezione di tutte le risposte causa lo stato SIA; il vicino può essere resettato e la rotta eliminata (purged).
• I miglioramenti EIGRP SIA-Query/SIA-Reply rilevano più precocemente i vicini che rispondono lentamente (slow responders), ma la progettazione della rete è la mitigazione principale.

Strategie di contenimento delle query:

• Summarizzazione: Creare aggregati a livello di distribution o su confini simili agli ABR per impedire che le query li attraversino. EIGRP installa una rotta di scarto (discard route) locale verso Null0 per il sommario (distanza amministrativa 5) con una metrica uguale alla migliore rotta componente. Questo riduce sia il raggio d’azione (scope) delle query sia protegge dal blackholing quando mancano rotte specifiche.
• Routing stub: Configurare sui siti spoke o leaf per bloccare le query di transito attraverso dispositivi con risorse limitate.
• Filtraggio: Limitare la propagazione di rotte non necessarie e ridurre l’impronta (footprint) della topologia.

Summarizzazione IPv4 con leak-map:

undefined

undefined

undefined

undefined

undefined

Le leak-map consentono di annunciare rotte più specifiche selezionate insieme al sommario, ad esempio per indirizzare il traffico di subnet critiche tramite policy o per mantenere percorsi ottimali, contenendo al contempo le query per il resto della rete.

Compromessi di progettazione:

• Sommari ampi (coarse) massimizzano la stabilità ma possono nascondere percorsi non ottimali, facendo sì che il traffico segua rotte più lunghe. Annunciare (leak) solo ciò che è necessario.
• Una varianza eccessiva può aumentare i percorsi di bilanciamento del carico (load balancing), ma solo tra i FS; assicurare il contenimento delle query in modo che esistano FS per le destinazioni critiche.

Policy, Ridistribuzione, Verifica e Risoluzione dei Problemi

Ridistribuzione da/verso EIGRP:

• Le route ridistribuite in EIGRP diventano esterne (distanza amministrativa 170). Impostare sempre una metrica deterministica e applicare il tagging per prevenire loop in caso di ridistribuzione reciproca.

undefined

!

undefined

!

undefined

!

undefined

Verifiche essenziali:

• Neighbor:

undefined

,

undefined

• Topologia:

undefined

,

undefined

e gli equivalenti in named-mode sotto

undefined

• Routing:

undefined

,

undefined

• Stato del protocollo:

undefined

,

undefined

• Traffico e query:

undefined

Flusso di lavoro per la risoluzione dei problemi di convergenza:

1. Confermare i prerequisiti per l’adiacenza: corrispondenza di AS, valori K/versione della metrica, autenticazione e assenza di passive-interface sui link di transito.
2. Ispezionare i timer e lo stato dell’interfaccia; i flap causano stati “active” frequenti. Regolare hello/hold solo quando necessario; preferire la risoluzione dei problemi del mezzo trasmissivo sottostante.
3. Verificare la presenza di indicazioni di SIA e “query storm”. Aggiungere o perfezionare le sumarizzazioni e configurare lo stub sui router foglia (leaf) per limitare le query.
4. Valutare la disponibilità di FS nella topologia. Se mancante, verificare che la condizione di fattibilità (feasible condition) possa essere soddisfatta; regolare i delay per creare backup validi se il design lo richiede.
5. Validare le metriche di ridistribuzione e i tag. L’assenza di valori predefiniti produce metriche infinite, scartando le route; l’assenza di tag può creare loop.
6. Per IPv6, assicurarsi che il router ID sia impostato e che l’attivazione per interfaccia sia presente; EIGRP per IPv6 non utilizza i comandi network di IPv4.

Scenario Pratico

Northwind Logistics gestisce una rete EIGRP dual-hub con decine di magazzini spoke. Flap occasionali sui circuiti di accesso nelle sedi remote scatenano “query storm”, causando SIA intermittenti sugli hub e failover ritardati. L’azienda prevede inoltre di abilitare IPv6 accanto a IPv4 e deve prevenire loop di ridistribuzione reciproca tra EIGRP e OSPF nei data center regionali.

Approccio:

1. Limitare le query con la sumarizzazione a livello di distribution.

• Su ogni interfaccia di distribution verso gli spoke, configurare sumarizzazioni IPv4 per interfaccia e consentire il “leak” delle sottoreti critiche che richiedono un routing ottimale. Ciò riduce il raggio d’azione delle query (query scope) quando uno spoke perde una route più specifica, preservando al contempo le prestazioni per i prefissi chiave.

undefined

!

undefined

undefined

Razionale: Le sumarizzazioni creano una route di scarto verso Null0 per i sottoprefissi non corrispondenti (AD 5) e impediscono agli stati Active di propagarsi oltre il confine, riducendo drasticamente il rischio di SIA.

2. Dichiarare gli spoke come stub, consentendo solo route connesse e sumarizzate.

undefined

Razionale: Gli hub non invieranno query ad ampio raggio agli spoke; gli spoke non dovranno rispondere per route che non possono migliorare, accorciando la convergenza e risparmiando CPU/memoria sui CPE di fascia bassa.

3. Abilitare il load sharing a costo diseguale (unequal-cost) tra i dual hub dove la FC è soddisfatta.

undefined

Razionale: La variance consente di utilizzare percorsi FS multipli verso gli hub, migliorando il throughput e la resilienza senza violare le garanzie anti-loop, a condizione che la FC sia rispettata.

4. Standardizzare le metriche ed evitare modifiche ai valori K.

• Non alterare i valori K. Impostare esplicitamente le metriche di ridistribuzione nei data center.

undefined

undefined

Razionale: Metriche coerenti producono una selezione del percorso prevedibile; i tag marcano le route esterne per prevenire loop di rientro.

5. Bloccare i loop di ridistribuzione da EIGRP di nuovo verso OSPF.

undefined

undefined

Razionale: I tag impediscono alle stesse route di oscillare tra i protocolli, evitando instabilità (churn) e confusione nelle metriche.

6. Rafforzare la formazione delle adiacenze con l’autenticazione sui segmenti LAN degli hub.

undefined

Razionale: Previene adiacenze non autorizzate e discrepanze accidentali di metrica/valori K da parte di dispositivi di terze parti.

7. Implementare EIGRP per IPv6 per interfaccia e impostare un router ID.

undefined

!

undefined

Razionale: EIGRP per IPv6 richiede l’abilitazione esplicita per interfaccia e un router ID a 32 bit; questo rispecchia il comportamento di IPv4 con adiacenze separate su FF02::A.

8. Validare e monitorare.

• Usare show ip eigrp topology all-links per verificare la presenza di FS; show ip eigrp neighbors detail per confermare timer/autenticazione; show ip eigrp traffic per assicurarsi che il numero di query diminuisca dopo la modifica. Razionale: Conferma che le modifiche al design riducono gli stati active/SIA e che sono disponibili FS multipli per uno switchover rapido.

← Progettazione · Tutti i domini · Policy →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →