EIGRP Frame-Realy e Split Horizon

Category : Appunti & Laboratori

In questo breve intervento mi soffermerò sulle possibili problematiche riscontrabili in un design Frame-Realy point – to multipoint in abbinamento al protocollo EIGRP in ambiente Cisco IOS.

Prendiamo come esempio il seguente design :

Nella topologia possiamo osservare che i router 2 e 3 non risultano direttamente collegati da un PVC, l’unico router ad avere un rapporto di adiacenza diretta risulta R1 attraverso l’interfaccia fisica Serial 0/0. Notiamo inoltre che i tre router utilizzano per l’interfaccia WAN la stessa classe network 10.1.1.0 / 24.

In una situazione reale con una configurazione standard di EIGRP e Frame-Relay, noteremo che i router R2 ed R3 non riusciranno a scambiarsi il database topologia di EIGRP in quanto R1 non recapiterà correttamente i messagi EIGRP Update.

I messaggi EIGRP Update contengono :

  • Prefix
  • Prefix Lenght
  • Componenti di metrica : bandwith, delay, reliability e load
  • Componenti non di metrica : MTU e conteggio degli hop.

Ecco il comportamento che noterete in una situazione reale :

1 R2 ed R3 non instaureranno mai una rapporto di adiacenza diretta (EIGRP Neighbors) in quanto solo ed esclusivamente i router collegati direttamente a livello data link instaurano questo tipo di adiacenza. Nel nostro caso R2 ed R3 non hanno un PVC che li collega direttamaente.

Secondo comportamente apparentemente anomalo è imputabile all’algoritmo Split Horizon. Il comportamento di Spit Horizon fa sì che il router omette per ciascun vicino gli specifici percorsi appresi da quel router. Nel nostro caso R1 riceverà la tabella di routing da R2 attraverso l’interfaccia serial 0/0 per la network 10.1.1.0/24, così R1 non ridistribuirà di nuovo nei suoi update la network in 10.1.1.0/24 dall’interfaccia serial 0/0. Questo comportamento farà si che R2 ed R3 non potranno scambiarsi pacchetti.

L’algoritmo Split Horizon è attivo di default in Cisco IOS, possiamo disabilitarlo a livello interfaccia con il comando no ip split-horizon eigrp “asn”.

Lo show run dell’interfaccia seriale di R1 nel nostro caso sarà configurata nel seguente modo :

interface Serial0/0 multipoint

ip address 10.1.1.1 255.255.255.0

no ip split-horizon eigrp 1

frame-relay interface-dlci 103

frame-relay interface-dlci 104

Configurare l’autenticazione MD5 in EIGRP

Category : Appunti & Laboratori

L’autenticazione EIGRP per un corretto funzionamento comporta che ogni messaggio di protocollo (pacchetti Hello) abbiano lo stesso valore PSK (preshared key) al fine di instaurare una relazione di adiacenza sicura. Se un router configurato con autenticazione EIGRP riceve dal vicino un pacchetto EIGRP con valore MD5 non corretto, il router scarterà il pacchetto prevenendo la formazione della relazione di vicinanza (neighborships).

Configurando l’autenticazione in EIGRP possiamo prevenire attacchi di rete basati su tecniche DoS, ma non possiamo prevenire la cattura dei pacchetti da parte di un eventuale utente malintenzionato. L’eventuale hacker potrà comunque ricevere i pacchetti Hello di EIGRP, collegandosi fisicamente all’apparato o facendo il join al gruppo multcast 224.0.0.10 (indirizzo default utilizzato da EIGRP per inoltrare pacchetti Hello). L’hacker non potrà tuttavia formare un’adiacenza con il router in quanto l’autenticazione preverrà il formarsi della neighborship.

Vediamo ora i tre step necessari per una corretta configurazione di EIGRP Authentication :

  1. Creare un set di chiavi (key chain) : da configurazione globale (Configure Terminal) impostare il nome del valore key chain (key chain “name”). Creare una o più chiave usando il comando key “number” nella modalità configurazione key chain. Definire il valore della chiave usando il comando key-string “value” nella modalità key configuration. In via opzionale possiamo impostare il lifetime (Time Period) per sending e accepting di ogni key string.
  2. Abilitare l’autenticazione EIGRP MD5 per interfaccia (R(config-if)#) con il comando ip authentication mode eigrp “asn” md5
  3. Impostare la chiave corretta da utilizzare a livello interfaccia, con il comando ip authentication key-chain eigrp “asn” “name-of-chain” (impostato nel primo step).

Nel primo step possiamo definire un numero di chiavi che possono variare nel tempo. L’amministratore può migrare da una chiave all’altra durante un determinato lasso di tempo grazie alla possibilità di impostare più chiave, ognuna defnita da un numero. Se non viene definito un periodo temporale per chiave, esse vengono sempre riconosciute come valide.

Di seguito gli screen shot della CLI IOS :

I comandi riportati nello screen shot mostrano la configurazione del primo step, ovvero la definizione del “porta chiavi” (Key chain), la chiave e la key-string. In fine mostriamo anche la possibilità di impostare un valore temporale per accept e send. Se impostiamo una chiave con validità limitata nel tempo sarà necessario impostare un server NTP per sincronizzare l’orario dei router.

In basso la CLI relativa agli step 2 e 3 riferiti ai comandi di livello interfaccia :

Passiamo ora ai comandi necessari per verificare il corretto funzionamento dell’autenticazione EIGRP. Il primo sintomo di una probabile configurazione errata è il non formarsi di adiacenze tra i router vicini. Per verificare la configuraizone possiamo utilizzare i seguenti comandi :

  • Show ip eigrp neighbors : verifica la presenza di adiacenze
  • Show key chain : restituisce una lista del key chain configurati oltre che la lista delle chiave valide.
  • Debug eigrp packet : fornisce il dettaglio dei messaggi scambiati tra i router ed eventuali problemi di authentication mismatch e/o invalid authentication.

EIGRP : Configurazione EIGRP

Category : Appunti & Laboratori

Buon 2010 a tutti i lettori, oggi proseguiamo la nostra breve guida al protocollo EIGRP, dopo aver descritto le basi fondamentali nella prima parte, vediamo ora altri comportamenti del protocollo.

Di seguito i comandi base di configurazione nella command line interface di Cisco IOS :

  • Router(config)#router eigrp (AS)

Definiamo un processo EIGRP seguito dal numero del sistema autonomo. In questa fase EIGRP non trasmette e non partecipa ancora al routing EIGRP.

  • Router(config-router)#network (rete a.b.c.d.) (wildcard mask)

In questo passaggio definiamo la network che deve essere annunciata ai router vicini e partecipare al routing. Ad esempio se volessimo far conoscere la network 10.0.0.1/24 dovremmo configurare il comando network in questo modo :

Router(config-router)#network 10.0.0.0 0.0.0.255 | la wildcard viene scritta nel modo inverso rispetto ad una subnetmask. Il router fa il match dei primi tre ottetti della network essendo /24bit, lasciando “liberi” gli ultimi 8 bit destinati alla parte host.

Ora abbiamo la possibilità di disabilitare l’auto summary che EIGRP processa di default. Il protocollo di Cisco aggrega attraverso l’auto summary, più network contigue in una singola supernet, riducendo la tabella di routing ed il “peso” dei messaggi scambiati con i vicini e la frequenza delle query, avendo una sola supernet che aggrega tutte le altre, si limitano query dovute al flapping delle network. L’auto summary può tornare utile in diverse circostanze, consentendo di risparmiare in termini di CPU, memoria e soprattutto lo spazio della tabella di routing dell’apparato.

La chiave del successo nel mondo reale con le route summarization è che sia l’amministratore a decidere dove fare summary e non il router… Tuttavia il summarization è una pratica molto delicata e che va eseguita con cautela, i danni provocati da un non corretto calcolo binario delle network in ambiente produttivo, possono essere devastanti…

Vediamo uno screen shot della tabella di routing di EIGRP con default summarization :

Continue Reading

EIGRP : Fondamenti

Category : Appunti & Laboratori

Un saluto a tutti i lettori, di seguito iniziamo un breve viaggio nel protocollo di routing EIGRP, protocollo IGP sviluppato da Cisco che introduce diverse migliorie rispetto al predecessore IGRP.

Le migliorie introdotte da EIGRP includono :

  • Supporto per i protocolli livello 3 Apple Talk, IP ed IPX di Novell
  • Supporto per variable-lenght subnet mask (VLSM)
  • Discovery dinamico via multicast 224.0.0.10
  • Convergenza veloce in seguito a cambiamenti di topologia. Attualmente la convergenza di EIGRP è più rapida del protocollo standard OSPF.

EIGRP a differenza di altri protocolli, non inoltra pacchetti di update ad intervalli regolari, questa caratteristica gli consente di consumare meno banda rispetto a RIP o IGRP. Gli update EIGRP non contengono l’intera tabella di routing, ma riflettono solo le route che hanno sbuito un cambiamento.

L’algoritmo di routing Diffusing Update Algoritm (DUAL) non solo calcola le rotte e assicura una topologia logica priva di loop, ma calcola anche delle backup route. Le backup route denominate “feasible successors,” sono presenti nella topology table. Le route primarie, “the successors”, sono presenti sia nella tabella topologia che nella tabella di routing. La terza tabella utilizzata da EIGRP è la tabella che contiene i “vicini”, la neighbors. La neighbors table è l’equivalente della tabella LSA di OSPF.

EIGRP è un protocollo “classless”, esso supporta VLSM e come tale, include nei pacchetti di routing update anche il prefisso della subnet mask. Vediamo ora la terminologia utilizzata in EIGRP :

  • Successor route : sta ad indicare il router adiacente caratterizzato dal minor costo per il raggiungimento di una determinata network. Possono coesistere più successor route per la stessa destinazione (4 di default in load balancing che possono estendersi fino a 16).
  • Feasible Successor : come suggerisce il termine, indica il secondo path con con il minor costo (subito dopo il successor route). Possiamo intendere il FS come un back up in caso di failure del successor.
  • Advertised Distance : indica il costo del path tra due router adiacenti ad una determinata destinazione.
  • Feasible Distance : costo del path che connette un router al suo vicino sommato al link esistente tra il router adiacente, considerata la rete di destinazione.

Continue Reading

EIGRP K-Value mismatch

Category : Cisco IOS Tips & Tricks

In questo post andiamo ad analizzare un errore di K Value mismatch in EIGRP, iniziamo con un accenno alla formula che calcola la metrica di protocollo :
Metrica [K1 X Banda + (K2 x Banda)/(256 - Carico) + K3 x Ritardo] x [K5/(affidabilità + K4)] x 256
La formula fa riferimento a cinque costanti K che possono essere configurate per modificare il comportamento del protocollo. Ovviamente nella maggior parte dei casi, Cisco consiglia di non modificare i valori che, di default, sono impostati come K1=K3=1 e K2=K4=K5=0. Questa configurazione riduce la formula a Bandwidth+Dealy.
Detto questo passiamo all’analisi del seguente messaggio di errore :
*Nov 23 9:48:41.811: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is
down: K-value mismatch
Il mismatch della costante previene che venga instaurata una relazione tra router A e router B.
Ci sono due tipici scenari nei quali può verificarsi un errore simile:
- Il primo è che i due router connessi e che partecipano allo stesso processo EIGRP siano configurati con metriche differenti, questa la sh run del router al quale sono stati modificati i parametri di metria con il comando “metric weights”
hostname ROUTER-A!
interface serial 0
ip address 10.1.1.1 255.255.255.0
exit
router eigrp 100
network 10.1.1.0 0.0.0.255
“metric weights 0 2 0 1 0 0″
- il secondo caso può verificarsi nel momento in cui uno dei due router transmetta un messaggio “goodbye” all’altro, il quale non supporta tale messaggio. In questo caso il destinatario interpreterà il pacchetto come un K-Value mismatch.
Il messaggio goodbye è una caratteristica di EIGRP che migliora la convergenza del protocollo. Goodbye viene inoltrato in broadcast quando il processo EIGRP attivo va in shut, così da informare i router vicini. I vicini possono quindi ricalcolare le neighbor relationships in modo più efficente prima che gli “hold timers” scadano.
Il messaggio goodbye è supportato dalle seguenti IOS :
Cisco IOS Release 12.3(2), 12.3(3)B, and 12.3(2)T

In questo post andiamo ad analizzare un errore di K Value mismatch in EIGRP, iniziamo con un accenno alla formula che calcola la metrica di protocollo :

  • Metrica [K1 X Banda + (K2 x Banda)/(256 - Carico) + K3 x Ritardo] x [K5/(affidabilità + K4)] x 256

La formula fa riferimento a cinque costanti K che possono essere configurate per modificare il comportamento del protocollo. Ovviamente nella maggior parte dei casi, Cisco consiglia di non modificare i valori che, di default, sono impostati come K1=K3=1 e K2=K4=K5=0. Questa configurazione riduce la formula a Bandwidth+Dealy.

Detto questo passiamo all’analisi del seguente messaggio di errore :

  • *Nov 23 9:48:41.811: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down: K-value mismatch

Il mismatch della costante previene che venga instaurata una relazione tra router A e router B.

Ci sono due tipici scenari nei quali può verificarsi un errore simile:

  1. - Il primo è che i due router connessi e che partecipano allo stesso processo EIGRP siano configurati con metriche differenti, questa la sh run del router al quale sono stati modificati i parametri di metria con il comando “metric weights”

hostname ROUTER-A!
interface serial 0
ip address 10.1.1.1 255.255.255.0
exit
router eigrp 100
network 10.1.1.0 0.0.0.255
“metric weights 0 2 0 1 0 0″

  • - il secondo caso può verificarsi nel momento in cui uno dei due router transmetta un messaggio “goodbye” all’altro, il quale non supporta tale messaggio. In questo caso il destinatario interpreterà il pacchetto come un K-Value mismatch.

Il messaggio goodbye è una caratteristica di EIGRP che migliora la convergenza del protocollo. Goodbye viene inoltrato in broadcast quando il processo EIGRP attivo va in shut, così da informare i router vicini. I vicini possono quindi ricalcolare le neighbor relationships in modo più efficente prima che gli “hold timers” scadano.

Il messaggio goodbye è supportato dalle seguenti IOS :

  • Cisco IOS Release 12.3(2), 12.3(3)B, and 12.3(2)T