BGP in ambienti multihoming

Posted by admin | Posted on 12-04-2010

Category : Appunti & Laboratori

Tags: , ,

In questo breve articolo analizzeremo i vantaggi e gli svantaggi dell’implementazione del protocollo BGP (Border Gatway Protocol) in contesti aziendali dotati di connettività ISP multihoming.

La connettività Internet a livello aziendale è caratterizzata sostanzialmente da due differenti tipi di implementazione :

  1. Dual-Homed : azienda dotata di due o più connessioni allo stesso ISP, configurabile in load balacing o fail over.
  2. Multihoming : almeno due connessioni verso due differenti ISP utilizzate contemporaneamente. Soluzione ideale in termini di ridondanza, in questo caso possiamo sfruttare due o più router in base alle connessioni e beneficiare di due differenti ISP.

ALCUNI CENNI DI BGP

  • Autonomous system (AS) : gruppo di networks che fanno parte di un singolo dominio amministrativo. Responsabile dell’instradamento all’interno di un AS è il protocollo di classe IGP (Interior Gatway Protocol, esempio RIP, OSPF, IS-IS o EIGRP). Ogni azienda è composta da un sistema di routing ed una lan gestita da una singola amministrazione.
  • Numerazione AS : ogni sistema autonomi è identificato con un numero a 16 bit (dal Gennaio 2009 sono disponibili le assegnazioni a 32bit) dalla IANA (Internet Assigned Numbers Authority). Le numerazioni a 16 bit prevedono un range da 1 a 65535, con un ulteriore range interno compreso tra 64512 e 65535 riservato per uso privato. Nel nostro articolo utilizzeremo il range privato per evitare di pubblicare numerazioni utilizzate da ISP.
  • Exterior Gatway Protocol (EGP) : protocollo incaricato di gestire lo scambio di informazioni tra sistemi autonomi. L’unico protocollo disponibile è BGP (Border Gatway Protocol) versione 4 (RFC 4271). I router che partecipano allo scambio di informazioni tra due sistemi autonomi sono detti border router.
  • Internal BGP (IBGP) : parte di BGP utilizzato all’interno del sistema autonomo
  • External BGP (EBGP) : parte di BGP utilizzata per lo scambio di informazioni tra sistemi autonomi.

BGP è un advanced distance vector protocol, che permette al sistema autonomo di controllare il traffico attraverso determinati attributi. BGP scambia le proprie informazioni di routing attraverso il path vector che consiste in un messaggio contenente il full path hop-by-hop necessario a raggiungere una determinata destinazione.

Path Vector tra AS

Path Vector tra AS

Altri attributi includono l’ip address del prossimo sistema autonomo (next-hop attribute) ed un’indicazione di quali network alla fine del path verranno introdotte in BGP (origin code attribute).

BGP è l’unico protocollo di routing ad utilizzare una finestra di trasporto TCP per lo scambio di update, in particolare BGP utilizza la porta TCP 179. Grazie ad un protocollo di livello 4 di tipo “affidabile e connection oriented” come TCP, BGP non prevede e non necessita di alcun tipo di meccanismo per la ritrasmissione degli update, al contrario di quanto previsto nei protocolli IGP (tipo OSPF ed EIGRP i quali scambiano espliciti messaggi  Ack per confermare la ricezione). Sempre grazie al protocollo TCP, BGP non effettua update periodici della tabella di routing ma invia esclusivamente update incrementali o triggered in caso di cambi improvvisi di topologia. BGP verifica lo stato della connessione TCP con gli altri router vicini ogni 60 secondi attraverso un keepalive.

Per le principali operazioni di scambio messaggi, BGP utilizza quattro tipi di pacchetto : Open, keepalive, update e notification.

In seguito alla corretta apertura di una connessione TCP tra due peers BGP, il primo messaggio inviato dai due router è un open message. Se il messaggio di apertura viene accettato dal peer, i due routers potranno iniziare a scambiarsi l’intera tabella di routing, il protocollo TCP provvederà al corretto trasporto dei dati e all’eventuale ritrasmissione di pacchetti persi regolando dinamicamente la finestra di protocollo.

Tutti i messaggi di BGP :

Open message :

  • Version number : indica la versione del protocollo (comunemente la 4)
  • AS Number : numero di AS del router locale
  • Hold time : numero massimo di secondi che possono intercorrere tra un keepalive ed update dal sender.
  • BGP router ID : questo è un campo di 32 bit che indica l’ID del BGP sender. Il BGP ID è un ip address assegnato al router, l’ID di un router BGP viene scelto al medesimo modo del router ID di OSPF.
  • Optimal parameters : questi parametri sono type, lenght e value (TLV) encoded.

Keep Alive :

  • BGP keepalive sono messaggi scambiati tra i peers BGP per controllare gli hold timers e, conseguentemente, la connessione TCP.

Update message :

  • Un update contiene informazioni relative ad un singolo path, variazioni di path multipli richiederanno l’invio di più update. L’update contiene nel dettaglio informazioni per raggiungere una determinato router e le network contenute.

Notification message :

  • Questo campo contiene una lista di prefissi di ip address che sono potenzialmente raggiungibili attraverso il path in questione.

In definitiva BGP consente ad ogni AS di trasmettere le proprie network al resto di internet e comunicare la propria esistenza. Allo stesso tempo BGP calcola il miglior path per interconnettere i vari sistemi autonomi sulla base della raggiungibilità e delle policy dell’as, in una topologia priva di loop.


Torniamo al multihoming analizzando il seguente scenario tipico :

Design multihoming Azienda A vs. 2 ISP

In questo design abbiamo due connessioni verso due differenti ISP, effettuate mediante due apparati. In questo caso abbiamo ridondanza sia a livello ISP che di router, che andrebbe replicata anche a livello distribuzione. L’organizzazione può decidere di implementare BGP tenendo a mente tre differenti scenari :

  1. Default route : Ogni ISP distribuisce al router aziendale esclusivamente la default route
  2. Default Route e partial routing table : I router ISP passeranno la default-route e parte della tabella di routing. In particolare includeranno solamente alcune specifiche rotte di proprietà dell’ISP
  3. Full internet routing table : Ogni ISP fornirà l’intera tabella di routing al sistema autonomi aziendale.

1 DEFAULT ROUTE

In questa particolare implementazione ha il vantaggio di non richiedere caratteristiche hardware di primo livello al router aziendale, non dovendo gestire il routing all’esterno dell’AS. Il border router avrà a disposizione due default route, sarà il protocollo di routing interno (IGP) a scegliere quale utilizzare in base al costo di metrica. Nella topologia in alto avrete notato che i due ISP sono direttamente connessi, questo può portare a fenomeni di suboptimal routing, ovvero la possibilità di raggiungere una destinazione effettuando un percorso più lungo.

Prendendo come esempio la topologia in alto, ipotizziamo che l’azienda A debba raggiungere un indirizzo compreso nella classe di ISP 2 e che la default route installata in tabella di routing sia quella di ISP 1, noteremo che il path selezionato non sarà R2—>ISP2 ma R1—->ISP1—->ISP2. In configurazione multihoming non è particolarmente consigliato affidarsi esclusivamente alle default route.

2 DEFAULT ROUTE  E PARTIAL ROUTING TABLE

Nel secondo design per multihoming gli ISP passeranno la default route insieme ad una parziale tabella di routing, contenente gli indirizzi di proprietà dell’ISP. Un’azienda che utilizza BGP può scegliere che rotte ricevere nell’update parziale dell’ISP. L’azienda può inoltre ricevere rotte specifiche di altri sistemi autonomi.

In questa particolare implementazione, l’azienda utilizzerà le redistribution da EGP a IGP sul border router per installare nella tabella di routing IGP le rotte apprese da BGP. Il routing interno di conseguenza baserà le proprie scelte non più basandosi esclusivamente sulla default route, ma anche sulla metrica/costo di alcune rotte apprese da BGP, selezionando il miglior percorso possibile. Possiamo quindi affermare che, rispetto al primo caso, una tabella di routing BGP parziale ci consente di effettuare un routing maggiormente prevedibile e gestibile.

In casi nei quali la destinazione non è presente in tabella di routing, il protocollo si affiderà alla default route che, in configuraizone multihoming, può portare anche in questo caso al fenomeno del suboptimal routing.

3 FULL INTERNET ROUTING TABLE

Nel terzo modello di design gli ISP trasmetteranno ai border routers aziendali tutta la tabella di routing, questo comporta necessariamente l’impiego di router di fascia alta dotati di molta memoria, devendo gestine centinaia di migliaia di rotte in blocchi CIDR. In questo caso non ci sarà suboptimal routing dato che l’azienda motrà gestire in modo completo e dettagliato tutto il routing verso i vari service provider.

Per eventuali chiarimenti o correzioni vi rimando ai commenti.

Configurazione CISCO IOS IP SLA

Posted by admin | Posted on 26-03-2010

Category : Appunti & Laboratori

Tags:

Salve a tutti, nel post di oggi parleremo della funzionalità IP SLA offerta dal software Cisco IOS e della sua configurazione in uno scenario tipico di utilizzo. La funzionalità IP SLA di Cisco IOS consente ad un router o switch di simulare uno specifico tipo di traffico verso un determinato indirizzo IP o ricevitore, chiamato “responder”.  IP SLA può simulare svariati tipi di traffico IP ad esempio : HTTP, FTP, DHCP, UDP jitter, UDP echo, TCP connect, ICMP echo, ICMP patch echo, ICMP path jitter e DNS.

La linea di comando di IP SLA offre la possibilità di effettuare una configurazione altamente granulare. Entriamo ora nel dettaglio, analizzando uno scenario tipico di utilizzo di IP SLA di IOS.

Nella topologia che potete osservare nell’immagine in basso, vediamo un border router di un’azienda (Customer) con due link verso differenti service provider.

Lo scopo di questa topologia e garantire un link di back up in caso di mancanza di connettività causato dal link primario. IOS IP SLA ci può aiutare a mantenere sotto controllo la raggiungibilità del link di back up, inviando ad intervalli regolari dei pacchetti ICMP. In questo modo possiamo costantemente monitorare il livello 3 del link back up.

Vediamo ora la configurazione da CLI. Step 1:

  • Router0(config)#ip sla monitor 1
  • Router0(config-ip-sla)#type echo protocol ipIcmpEcho 10.1.1.2 source-ip 10.1.1.2
  • Router0(config-ip-sla-echo)#frequency 10
  • !
  • Router0(config)#ip sla monitor 2
  • Router0(config-ip-sla)#type echo protocol ipIcmpEcho 11.1.1.2 source-ip 11.1.1.1
  • Router0(config-ip-sla-echo)#frequency 10

In questa prima parte della configurazione abbiamo definito le due SLA per i due differenti IP, impostando il pacchetto ICMP e la frequenza di 10 secondi.

Passiamo ora secondo Step :

  • Router0(config)#ip sla schedule 1 life forever start-time now
  • Router0(config)#ip sla schedule 2 life forever start-time now

In questa fase abbiamo schedulato l’operazione che nel nostro caso partirà da subito e sarà in esecuzione a tempo indeterminato.

Terzo step :

  • Router0(config)#track 1 ip sla 1 rechability
  • Router0(config)#track 2 ip sla 2 rechability

Ora abbiamo tracciato le policy SLA che andremo a collegare alle rotte statiche nel quarto ed ultimo passaggio :

  • Router0(config)#ip route 0.0.0.0 0.0.0.0 10.1.1.2 2 track 1
  • Router0(config)#ip route 0.0.0.0 0.0.0.0 11.1.1.2 3 track 2

Configuriamo le rotte statiche verso i due provider, assegnando una distanza amministrativa di 2 alla rotta che rimanda al primary ISP e 3 verso il back up. Le due sono collegate alle policy IP SLA, attraverso il comando “track”.

Per eventuali dubbi o correzioni vi rimando ai commenti, buon proseguimento!

EIGRP Frame-Realy e Split Horizon

Posted by admin | Posted on 08-03-2010

Category : Appunti & Laboratori

Tags: ,

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

Posted by admin | Posted on 04-03-2010

Category : Appunti & Laboratori

Tags: , , , , ,

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.

Configurazione OSPF Authentication

Posted by admin | Posted on 17-01-2010

Category : Appunti & Laboratori

Tags: , ,

Salve a tutti, in questo intervento vedremo le metodologie supportate da OSPF per rendere sicuro lo scambio di pacchetti LSA (Link State Advertise) attraverso la configurazione dell’autenticazione. L’autenticazione in OSPF prevede che i router si riconoscano attraverso una password, per poter scambiare i messaggi di protocollo. I metodi di autenticazione sono due :

  1. Plaintext Password
  2. Message Digest (MD5) hash

Il primo metodo prevede che la password sia scambiata in chiaro, quindi risulta poco efficiente soprattutto in contesti particolarmente critici dal punto di vista della sicurezza. Qualsiasi attacker con possibilità di accesso, può facilmente cattuare dei pacchetti di protocollo e carpirne la password. L’autenticazione plaintext è attivabile con la seguente linea di comando :

Router(config-if)#ip ospf authentication-key password

Notate che il comando viene scritto a livello di configurazione interfaccia (config-if). Gli altri router connessi all’interfaccia appena configurata dovranno essere configurati con il comando :

Router(config-if)#ip ospf authentication

In precedenza con le versione antecedenti ad IOS 12.0, l’autenticazione veniva impostata per area, questo metodo risultava meno flessibile di quello attuale.

L’autenticazione MD5 Hash fornisce una buona sicurezza, questo metodo utilizza l’algoritmo di MD5 per calcolare il valore hash del contenuto del pacchetto scambiato con una password. Il valore hash viene trasmetto nel pacchetto in aggiunta all’ID della chiave ed una sequenza numerica non decrescente. Il destinatario che conosce la stessa password del mittente, calcola il valore hash. Se non ci sono incongruenze nella chiave, il valore hash calcolato sarà il medesimo tra mittente e destinatario. Il numero non decrescente di sequenza previene attacchi di tipo reply, evitando la cattura dei pacchetti OSPF con relativa ritrasmissione.

Vediamo la configurazione :

Router(config-if)#ip ospf message-digest-key md5 password

Nel secondo passaggio configuriamo la password :

Router(config-if)#ip ospf authentication message-digest

Concludiamo questa breve guida con i comandi IOS necessari per la verifica e per il troubleshooting :

  • show ip ospf neighbor : verifichiamo che lo scambio di messaggi sia corretto e vengano instaurate le adiacenze
  • show ip ospf interface : fornisce altre informazioni sulle interfacce coinvolte in OSPF
  • debug ip ospf adjacency : il comando mostralo stato dell’autenticazione

Laboratorio Packet Tracer OSPF

Posted by admin | Posted on 12-01-2010

Category : Appunti & Laboratori

Tags: , , , ,

Salve a tutti oggi vi propongo un semplice esercizio di laboratorio realizzato con il software Cisco Packet Tracer, valido per la comprensione della tipologia dei pacchetti LSA ed il concetto di aree in OSPF. Il lab simulato prevede la configurazione di aree stub e totaly stub di OSPF.

La topologia è la seguente :

Sono presenti tre router (0, 1 e 2), tutti partecipano allo stesso processo OSPF (1). Ci sono tre aree, la 0 di backbone, l’area 1 e la loopback di Router 2 in area 2. Lo scopo è quello di isolare area 1 e verificare lo scambio di pacchetti LSA 1, 3 e 4. Per maggiori dettagli su OSPF vi rimando a questo intervento.

Attualmente la tabella di routing di Router0 si presenta nel seguente modo :

L’obiettivo del laboratorio è quello di eliminare l’entry O IA (generata dai pacchetti OSPF LSA Type 3 che porta il summary delle aree all’interno dello stesso processo OSPF).

Nella tabella di routing di Router0 (quindi area1) dovrà essere presente esclusivamente la default route 0*IA. Il download del laboratorio Packet Tracer è disponibile a questo indirizzo.

Configurazione OSPF Virtual Link

Posted by admin | Posted on 06-01-2010

Category : Appunti & Laboratori

Salve a tutti, oggi continuiamo l’analisi di OSPF (prima parte e seconda parte), trattando i virtual link. Per chi non avesse sufficienti basi di OSPF è vivamente consigliata la lettura della prima e seconda parte dell’introduzione a OSPF.

Tutte le aree di un sistema autonomo di OSPF devono essere connesse fisicamente all’area zero (backbone) per comunicare correttamente. In alcuni casi la connessione fisica al backbone non è possibile, e qui ci viene in aiuto il collegamento virtuale di OSPF, noto anche come transit area. La transit area deve avere tutte le informazioni di routing, quindi non può essere configurata come stub.

Come esempio prendiamo la seguente topologia :

Il backbone si trova dietro il router 1.1.1.1, noi vogliamo far comunicare l’area 2 dietro il router 3.3.3.3 con il backbone. Per fare questo, ci occorre far diventare l’area 1 un’area di transito, e configurare il virtual link che consenta la comunicazione tra router 1.1.1.1 e router 3.3.3.3.

In questo scenario non mostreremo di nuovo tutti i comandi necessari alla corretta configurazione delle aree e delle network in ospf ma ci limiteremo alla parte del virtual link.

Configuriamo R1 ed R3 come segue :

  • R1(config-router)area 1 virtual-link 3.3.3.3
  • R3(config-router)area 1 virtual-link 1.1.1.1

In questo modo creiamo un tunnel tra i due router e colleghiamo l’area 2 al backbone, transitando attraverso area 1. Possiamo verificare lo stato del virtual link con il comando sh ip ospf virtual-link. Ricordate inoltre che le aree stub, nssa, e totaly stub non possono essere attraversate dal virtual link.

OSPF : Design Multi-Area e Redistribution

Posted by admin | Posted on 04-01-2010

Category : Appunti & Laboratori

Tags: , , , , , , ,

Continuiamo la nostra guida ad OSPF, dopo le basi fondamentali del protocollo introdotte in questo intervento, vediamo oggi le regole guida per un design scalare multi area, le zone stub e la reditribuzione delle route.

Prima di iniziare un qualsiasi design OSPF è bene tenere a mente le seguenti linee guida consigliate da Cisco :

  • Un router non deve essere presente in più di tree aree.
  • Ogni area non deve contenere più di 50 router
  • Un router non deve avere più di 60 vicini direttamente connessi
  • Un router può essere sia Designated Router e Backup Designated Router per più di un segmento di rete.
  • Non attivare più di un processo OSPF per Area Border Router (ABR router di backbone)

Quando disegniamo un network OSPF teniamo presente che ogni area deve essere connessa all’area zero di backbone e tutto il traffico inter-area deve viaggiare attraverso essa.

Quali sono i vantaggi derivati da una corretta segmentazione in aree multiple di OSPF ?

Ecco alcuni buoni motivi :

  • Attraverso un approccio multi area e gerarchico possiamo effettuare in modo più pulito la summarization delle route
  • Creando aree multiple il flooding LSA diminuisce ed è localizzato. Per esempio i pacchetti LSA type 1 e 2 non lasceranno l’area di provenienza.
  • L’approccio layered multi area porta ad un minor ricalcolo dei protocollo Shortest Path Firft (SPF)

Area Stub e Total Stub.

In OSPF l’area 0 (zero) è la backbone area, ovvero l’area di transito che collega tutti i router di frontiera. Quando creiamo un network OSPF multi area, ogni router non backbone deve essere collegato fisicamente o logicamente all’area backbone. Tutto il traffico inter-area transiterà sul backbone (area zero), per questo ragione l’area di backbone si trova generalmente in una posizione centrale del network.

Passiamo ora agli esempi pratici di configurazione multi area. Partiamo da una configurazione di tre router interconnessi via frame relay :

Continue Reading

OSPF : Fondamenti e Single Area

Posted by admin | Posted on 03-01-2010

Category : Appunti & Laboratori

Tags: , , , , ,

OSPF (Open Shortest Path First) è un protocollo standard RFC 2328, si tratta di un protocollo “link state” di tipo IGP (Interior Routing Protocol). OSPF costruisce la propria topologia loop-free che converge velocemente in caso di failure, ma richiede molte risorse di processore e memoria in caso di ricalcolo dell’algoritmo SPF, rispetto ai protocolli distance vector.

OSPF può risultare inizialmente abbastanza complicato data la sua flessibilità in termini di design ed essendo uno standard aperto, può essere implementato da tutti i vendor del mercato e coesistere in ambienti eterogenei. In questa prima analisi, descriveremo la caratteristiche generali di OSPF e ci soffermeremo sulla configurazione single area.

OSPF è un sofisticato protocollo di routing basato sull’algoritmo di Dijkstra, lo Shortest Path First (SFP) :

“Edsger Wybe Dijkstra, formulò l’algoritmo SPF da da lui prese il nome. Questo algoritmo considera una rete come un insieme di nodi connessi da link punto-punto. Ciascun link presenta un determinato costo e ciascun nodo ha un nome univoco. Ogni nodo dispone di un database completo di tutti i link e, di conseguenza, di tutte le informazioni che riguardano la topologia fisica della rete. I database link state di tutti i router di una determinata area sono identici tra loro

STP colloca ciascun router alla base di una struttura ad albero calcolando il percorso più breve che consente di raggiungere ogni destinazione in funzione del costo cumulativo. Nell’area si esegue il flooding dei pacchetti LSA ( E’ il database topologia, ovvero il messaggio di protocollo che contiene la visione della rete a livello logico. Ogni router scambia con il proprio vicino di area i pacchetti LSA per determinare i migliori percorsi) utilizzando un algoritmo affidabile, che garantisca che tutti i router dell’area possano ricavare lo stesso database topologia. Ogni router ha un proprio punto di vista dell’area, condividendo con gli altri tutti i percorsi di rete dell’area. Quindi possiamo affermare che tutti i router di una determinata area dispongono delle stesse informazioni a livello topologia, ma ogni router ha una visione di insieme differente e ciascun router calcola il percorso considerando se stesso come il punto di partenza dell’abero logico.

Il costo (o metrica) di ogni interfaccia indica l’overhead richiesto per inviare i pacchetti da una determinata interfaccia. Il costo in OSPF è inversamente proporzionale alla larghezza di banda del link, quindi una maggiore ampiezza di banda corrisponde a un costo inferiore.”

  • OSPF è un protocollo classless e consente la summarization
  • OSPF è uno standard RFC, ed è supportato in ambienti caratterizzati da router di N vendor.
  • OSPF preserva la bandwith nello scambio dei propri messaggi
  • OSPF usa multicast per comunicare invece di broadcast
  • Inoltra messaggi incrementali basati sul cambiamento di rotte “change-based”
  • OSPF usa metrica inversamente proporzionale all’ampiezza di banda del link.

Continue Reading

EIGRP : Configurazione EIGRP

Posted by admin | Posted on 01-01-2010

Category : Appunti & Laboratori

Tags: , , , ,

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

Previous