EIGRP – Parte Terza

In questo post vedremo come configurare correttamente L’EIGRP.

Per prima cosa occorre inizializzare il protocollo definendo l’AS all’interno del quale deve operare:

Router(config)# router eigrp <AS>

Successivamente è necessario definire le reti che tale protocollo deve pubblicare:

Router(config-router)# network <rete> [wildcard mask]

Nella fattispecie, la wildcard mask è facoltativa e rappresenta la classe della rete appena dichiarata. Ad esempio:

Router(config-router)# network 10.1.1.0 0.0.0.255

indica una rete di classe C, mentre:

Router(config-router)# network 192.168.1.0 0.0.255.255

indica una rete di classe B.

L’uso della wildcard mask consente di fornire al protocollo di routing in questione informazioni più dettagliate sulle reti che deve pubblicare, oltre a tenere sotto controllo gli effetti dell’auto summarization delle rotte.

Per configurare la default route che verrà utilizzata nell’ambito dell’EIGRP basta scivere:

Router(config)# ip default-network <rete>

(quest’ultima deve essere presente tra le network dichiarate all’EIGRP)

mentre per rimuoverla occorre usare il comando:

Router(config)# no ip route <rotta>

La default route così definita verrà redistribuita a tutti i router vicini. Ciò non accadrebbe se la default route venisse dichiarata con il comando:

Router(config)# ip route 0.0.0.0 0.0.0.0 <IP del router connesso direttamente>

Occorre notare, però, che nel caso in cui avessi dichiarato una rotta del tipo:

Router(config)# ip route 0.0.0.0 0.0.0.0 <interfaccia>

avrei potuto ottenere la ridistribuzione della stessa, previa dichiarazione della rete 0.0.0.0 all’EIGRP mediante il comando network, ovvero:

Router(config-router)# network 0.0.0.0

Summarization delle rotte

La summarization delle rotte consente di ridurre notevolmente le dimensioni delle tabelle di routing (con conseguente risparmio in termini di banda). In particolare, mediante questa caratteristica (abilitata per default nell’ambito dell’EIGRP), possono essere rappresentate più reti contemporaneamente mediante un unico indirizzo IP che le ingloba.

Per calcolare il numero di reti che possono essere aggregate nell’ambito di un unico indirizzo basta applicare la formula:

n = <numero di bit della subnet mask> – <numero di bit della summary mask>. 2^n mi darà il numero esatto delle reti che possono essere aggregate grazie alla summarization.

Facciamo un esempio. Supponiamo che si voglia aggregare le rotte 192.168.1.0/24, 192.168.2.0/24 e 192.168.3.0/24 mediante l’indirizzo 192.168.0.0/22. Apllico la formula sopra citata per individuare quante sono le subnet che posso rappresentare mediante questo indirizzo:

n = 24 – 22 = 2. Inoltre 2^2 = 4. Posso quindi rappresentare 4 subnet in tutto (le tre citate in precedenza e la 192.168.0.0/24).

Per disabilitare l’auto summarization basta digitare:

Router(config-router)# no auto-summary

mentre per impostare manualmente l’indirizzo di summarization occorre scrivere:

Router(config)# ip summary-address eigrp <AS> <indirizzo di summarization> <subnet mask relativa all'indirizzo di summarization> [distanza amministrativa]

In particolare, l’ultimo parametro ci consente di definire la distanza amministrativa per la rotta aggregata. Nel caso in cui non venisse definita dall’utente, EIGRP assegnerà alla rotta aggregata una distanza amministrativa pari a 5.

NB: affinchè il router che fa uso delle rotte aggregate non vada alla ricerca di rotte più specifiche (creando potenzialmente dei loop), le summarizated route punteranno ad un interfaccia software fittizia, ovvero Null0.

Load balancing

Una funzione molto interessante relativa all’EIGRP è il cosiddetto load balancing, ovvero il bilanciamento del carico. Tale caratteristica permette di instradare il traffico lungo più cammini aventi la stessa metrica (costo). Per default il bilanciamento del carico viene effettuato utilizzando un massimo di 4 cammini. Posso comunque definire manualmente il numero di cammini da utilizzare (fino ad un massimo di 16) attraverso il comando:

Router(config-router)# maximum-paths <numero di cammini>

NB: ponendo il parametro <numero di cammini> pari a 1 disabilito il load balancing. Inoltre, il load balancing viene applicato solo al traffico che passa attraverso il router e non a quello che viene generato dal router stesso.

E’ bene notare che il load balancing può essere applicato anche su cammini che non hanno la stessa metrica. In questo caso parliamo di unequal-cost load balancing. Posso implementarlo attraverso il comando:

Router(config-router)# variance <valore>

dove <valore> è un intero compreso tra 1 e 128 (1 indica l’equal-cost load balancing).

Per capire lungo quali rotte verrà bilanciato il traffico basta operare come segue:

1) considero la rotta avente metrica più bassa (ovvero la FD della successor route);

2) moltiplico la metrica (FD) per <valore>;

3) Una volta calcolato il prodotto, userò tutte le rotte aventi FD <= al prodotto stesso. Ad esempio:

RouterA FD 1100

RouterB FD 1100

RouterC FD 2000

RouterD FD 3000

Supponendo che il valore della varianza sia 2, otterrò:

1100 x 2 = 2200

Per il bilanciamento userò quindi le rotte che coinvolgono il router A, il router B ed il router C, ma non il router D. Tali rotte verrano salvate nell’ambito della tabella di routing.

Per controllare il bilanciamento del carico su rotte aventi metrica (FD) differente, occorre digitare:

Router(config-router)# traffic-share [balanced | min across-interfaces]

Con la keyword balanced distribuisco il carico proporzionalmente alla metrica (FD) dei cammini. Invece, mediante la keyword min across-interfaces effetto il bilanciamento solo lungo i cammini aventi metrica (FD) più bassa.

EIGRP e WAN

L’EIGRP lavora efficientemente nell’ambito delle WAN, sia per ciò che concerne i collegamenti point-to-point che per quanto riguarda le reti NBMA (point-to-point e multipoint).

Per default, l’EIGRP usa il 50% della banda dichiarata (mediante il comando bandwidth) su un’interfaccia fisica o su una sottointerfaccia virtuale, ma tale valore può essere modificato digitando:

Router(config-if)# ip bandwidth-percent eigrp 1 <percentuale>

dove <percentuale> può essere superiore al 100%, soprattutto se la banda dichiarata è inferiore all’effettiva capacità del canale.

Inoltre, per le reti Frame Relay, nel caso in cui la banda non venisse impostata in modo esplicito mediante l’apposito comando, essa verrà considerata uguale a quella tipica delle reti T1 (1544 Kbps).

Per quanto riguarda le topologie multipoint, la banda dichiarata deve essere suddivisa per il numero di vicini affinchè si possa calcolare la banda presente su ogni collegamento. Nel caso in cui vengano utilizzati link con capacità differente (CIR diversi tra loro), la banda da settare dovrà essere calcolata moltiplicando il CIR più basso per il numero di circuiti virtuali (VC).

NB: il CIR (Committed Information Rate) è un parametro usato nelle reti Frame Relay, il quale indica la banda minima garantita dal provider.

Autenticazione EIGRP

L’autenticazione EIGRP è disabilitata per default. Esistono, inoltre, due tipi di autenticazione:

Simple password authentication (detta anche plain text authentication);

– MD5 authentication.

L’MD5 calcola il digest della password (key) concatenata al suo ID, ovvero H(key || key ID). Mediante l’autenticazione sarà possibile riconoscere la sorgente dei messaggi ed il digest verrà inserito all’interno di tutti i pacchetti inviati nell’ambito del protocollo di routing in questione.

E’ possibile definire la durata (lifetime) relativa all’uso della password. Ciò conviene quando sono definite delle key-chains, le quali prevedono l’uso a rotazione delle password stesse. A tal proposito è necessario fare attenzione che non vi siano dei lassi di tempo in cui nessuna password risulta attiva (in questo caso i routing update falliranno sistematicamente). Inoltre, le password verranno utilizzate a partire da quella recante key ID più basso (a parità di lifetime).

NB: i router devono essere sincronizzati (mediante NTP – Network Time Protocol) affinchè usino la stessa password della key-chain per lo stesso lasso di tempo.

Per configurare l’autenticazione MD5 occorre digitare:

Router(config-if)# ip authentication mode eigrp <AS> md5

Creo dunque la key-chain:

Router(config-if)# ip authentication key-chain eigrp <as> <nome della chain>

Entro nella modalità di configurazione della chain:

Router(config)# key chain <nome della chain>

Router(config-key-chain)# key <key ID>

Setto la password vera a propria:

Router(config-key-chain)# key key-string <password>

(il primo carattere della password non deve essere un numero).

Posso definire opzionalmente il lasso di tempo durante il quale tale password viene accettata per gli update in ingresso:

Router(config-key-chain)# accept-lifetime <inizio> {infinite | <fine> | duration <secondi>}

Il formato di <inizio> e <fine> è il seguente:

hh:mm:ss giorno (1-31) mese (prime 3 lettere del mese in inglese) anno (4 cifre)

Per l’invio dei pacchetti contenenti il digest occorre digitare:

Router(config-key-chain)# send-lifetime <inizio> {infinite | <fine> | duration <secondi>}

NB: la key-string (password) viene salvata in chiaro se non viene digitato il comando service password-encryption.

Inoltre, se sia la key1 che la key2 per l’accept-lifetime hanno durata infinita, il router accetterà sempre sia i pacchetti contenenti il digest della key1 che quelli contenenti il digest della key2.

Viceversa, se il send-lifetime di una key è infinito (e tale chiave possiede l’ID più basso), verrà usata solo quella key durante l’invio dei pacchetti EIGRP.

Toubleshooting dell’autenticazione MD5

Il comando da utilizzare è il seguente:

Router# debug eigrp packets

l’output mostrerà il key ID e nel caso in cui le chiavi settate sui due router non coincidono, verrà visualizzata la dicitura “authentication mismatch”. In tal caso l’adiacenza verrà formata solo per un lasso di tempo molto breve. (“retry limit exceeded” e ” new-adjacency” come output).

Query EIGRP e stuck-in-active (SIA)

Se un router si accorge che la sua successor è down e che non esiste FSR, esso unvierà una query ai router vicini per individuare un percorso alternativo verso quella specifica destinazione. Se i router vicini non conoscono la risposta, propagheranno la query ai loro adiacenti e così via. Durante questo lasso di tempo la rotta rimarrà nello stato ACTIVE e non tornerà allo stato PASSIVE finchè alla query non seguirà una risposta (reply). Se tale risposta non viene ricevuta entro 3 minuti dall’invio della query, la rotta entra nello stato stuck-in-active (SIA).

NB: si può modificare il tempo limite oltre il quale viene dichiarato lo stuck-in-active della rotta digitando:

Router(config-router)# timers active-time <limite in minuti> oppure disabled

Appena il router identificherà lo stuck-in-active resetterà tutte le adiacenze con i vicini che non hanno risposto alla query.

Contromisure allo stuck-in-active

Esistono diverse contromisure allo stuck-in-active. Una di queste prende il nome di Active Process Enhancement. Per capire il funzionamento di tale meccanismo facciamo un esempio: il router A invia al router B una query che a sua volta verrà instradata verso il router C. Poichè vi è un problema relativo al collegamento tra il router B ed il router C, quest’ultimo non risponderà alla query, e di conseguenza B tarderà nell’invio della risposta ad A. Il router A crederà quindi che è il router B a presentare dei problemi e quindi rimuoverà l’adiacenza con lo stesso. Proprio per evitare una situazione del genere, a partire dalla IOS 12.1(5), è stato introdotto l’Active Process Enhancement. Grazie a tale meccanismo, il router B prima di inoltrare la query a C risponderà ad A attraverso un pacchetto SIA-reply, proprio per indicare il suo corretto funzionamento.

Un’altra contromisura allo stuck-in-active è rappresentata dal query range, detto anche query scoping. Esso limita la propagazione della query nell’ambito della rete, attraverso una route summarization oppure mediante l’uso di uno stub. Ad esempio, nel primo caso il router A invierà al router B una query richiedendo la rotta verso una specifica rete. Il router B, però, conosce la summarization di alcune rotte in cui è presente la rete cercata da A, ma non possiede nella propria tabella di routing l’indirizzo vero e proprio di quel network. Perciò, B risponderà ad A affermando che non conosce la rotta verso la rete che gli è stata richiesta.

Pe quanto riguarda lo stub, esso rappresenta un router che non può nè ricevere nè inviare le query EIGRP. Inoltre, a seconda dei casi, esso non può inviare alcuna rotta ai vicini, oppure può inoltrare solo le rotte direttamente connesse, le rotte statiche o le rotte aggregate. Per configurarlo occorre digitare:

Router(config-router)# eigrp stub [receive only | connected | static | summary]

Se invece viene specificato il comando:

Router(config-router)# eigrp stub

senza alcun parametro opzionale, lo stub inoltrerà solo le rotte direttamente connesse (previa loro esplicita dichiarazione mediante il comando network) e le summary route. Un altro modo per redistribuire le rotte direttamente connesse è quello di digitare il comando:

Router(config-router)# redistribuite connected

In questo modo, però, le rotte redistribuite verranno marcate come esterne dai router vicini che le hanno ricevute (flag EX) e quindi la loro distanza amministrativa non sarà 90 bensì 170.

Infine, è bene notare che uno stub deve essere necessariamente un router remoto ed in particolare, nelle topologie hub-n-spoke, uno stub è necessariamente uno spoke (per questo motivo può avere come vicini solo uno o più hub).

Graceful shutdown

Mediante il graceful shutdown un messaggio di disconnessione viene inviato dal router su cui non è più attivo il processo EIGRP. In questo modo si evita che l’adiacenza con i router vicini venga rimossa solo allo scadere dell’hold-timer, con conseguente spreco di banda.

Alcuni comandi utili

Di seguito riporto alcuni comandi utili per verificare il corretto funzionamento dell’EIGRP:

Router# sh eigrp neighbors

Router# sh ip route

Router# sh ip route eigrp

Router# sh ip protocols

Quest’ultimo mostra alcune informazioni riguardanti l’EIGRP quali il numero di AS, le summarization, l’hold-timer, il valore di K, la varianza, la distanza amministrativa, l’hop count e le filter list per il traffico in ingresso ed in uscita.

Abbiamo inoltre i seguenti comandi:

Router# sh ip eigrp int

che mostra le interfacce utilizzate dall’EIGRP

Router# sh ip eigrp topology

Router# sh ip eigrp topolgy all-links

Router# sh ip eigrp traffic

quest’ultimo mostra il numero di pacchetti EIGRP inviati e ricevuti. Inoltre, permette di visualizzare le statistiche relative a tutte e 5 le tipologie di pacchetti usati nell’ambito del protocollo in questione.

Router# debug ip eigrp

il cui output contiene informazioni sul calcolo della metrica

Router# debug ip eigrp summary

il quale mostra informazioni meno dispersive rispetto al comando debug ip eigrp

Router# debug eigrp neighbors

che permette di visualizzare il processo di individuazione dei vicini ed il contenuto dei pacchetti hello.

Router# debug ip eigrp packets

dove la dicitura nbr indica il vicino (neighbor), rely 1/0 indica che il pacchetto rappresenta la risposta ad un altro pacchetto che prevedeva la ricezione di un ACK (ad esempio un update), serno numero intero – numero intero indica il numero di cambiamenti che i due vicini hanno subito nell’ambito della loro tabella di routing, Seq 5/4 indica che il il vicino ha trasmesso un pacchetto con numero di sequenza pari a 5 e a tale pacchetto il router locale ha assegnato numero di sequenza pari a 4. La risposta al vicino dovrà contenere numero di sequenza pari a 5 (altrimenti il pacchetto verrà scartato). Inoltre, gli ACK avranno il primo valore del numero di sequenza uguale a 0 (ad esempio Seq 0/5), a testimonianza del fatto che essi non prevedono l’invio di un ulteriore ACK come conferma di avvenuta ricezione.

EIGRP – Parte Terzaultima modifica: 2010-11-13T09:24:33+01:00da nazarenolatella
Reposta per primo quest’articolo

6 pensieri su “EIGRP – Parte Terza

  1. Buongiorno, nel farle i complimenti per le pagine presentate sono a chiedere che cosa intende per ” – Simple password authentication (detta anche plain text authentication); ” nell’ambito dell’autenticazione EIGRP. Se non erro, in EIGRP, vi è la sola possibilità di utilizzare l’MD5 authentication.

    Grazie per l’attenzione.

    Cordiali Saluti
    Christian Biasibetti

  2. Caio Christian, grazie per i complimenti. Per plain text authentication intendo che la key viene salvata come stringa in chiaro e non come digest (come avviene per l’MD5). A presto.

  3. Ciao Nazareno, ti ringrazio per la risposta.

    Se accetti una critica costruttiva mi permetto di dire che la tua esposizione in merito all’autenticazione EIGRP può essere mal interpretata, o meglio sembra che via siano due possibilità di configurazione, quando invece cosi non è.

    In EIGRP l’autenticazione è configurabile sull’interfaccia, ma solo ed esclusivamente con mode MD5, infatti non è supportata la modalità “PLAIN TEXT AUTENTICATION”.

    Differente invece la possibilità che si verifica la condizione in cui le key string siano salvate in “plain text” (quindi visibili in chiaro nello show della configurazione) in quanto a livello globale la “service password-encryption” non è stata abilitata. Ma questo aspetto non c’entra nulla con la metodologia di autenticazione che rimane di un solo tipo, ossia MD5.

    Detto ciò, rinnovo i miei apprezzamenti per il lavoro che offri al servizio di tutti.

    Grazie per l’attenzione.

    Cordiali saluti
    Christian Biasibetti

  4. Ciao Christian. Ti posto questo intervento tratto da http://digitaltut.com/bsci-eigrp-questions:

    EIGRP use to support plain text and MD5. but plain text was later dropped as a security risk (not sure which IOS version).

    As BSCI exam is based upon current IOS at the time of the exam was made, you will lose marks for picking plain text.

    Mi pare evidente che il testo da cui ho studiato è “deprecated” 😀 Grazie comunque per le informazioni e per gli aggiornamenti. A presto.

  5. Dal testo: CCNA ICND2 Official Exam Certification Guide Second Edition pag 397:

    EIGRP supports one type of authentication: MD5

    Inoltre la definizione di CIR è errata, sempre dallo stesso testo a pagina 465:

    Each VC has a CIR, which is a guarantee by the provider that a particular VC gets AT LEAST that much bandwidth.

    Il mio inglese è pessimo, ma capisco che è la minima garantita, tant’è vero che se viene superato il limite e non ci sono problemi di congestione il traffico è permesso, altrimenti viene impostato il flag DE nell’ header frame-relay il quale dice che quel traffico PUO’ essere scartato.

    Per il resto ottima guida.

    Ciao Simone

  6. Ciao Simone,
    come hai potuto notare dai commenti precedenti, il malinteso relativo al tipo di autenticazione EIGRP era dovuto all’uso di una guida alquanto obsoleta. Ho comunque provveduto a correggere il post per evitare eventuali fraintendimenti futuri 😀
    Per ciò che concerne il CIR, invece, ho notato che effettivamente si trattava di un refuso. Grazie per le preziose informazioni. A presto.

I commenti sono chiusi.