Il blog sull'informatica

Poichè i protocolli di routing dinamici solitamente consumano parecchia banda, si è pensato di sviluppare un metodo alternativo per la propagazione delle rotte, attraverso il quale è possibile ridurre l'overhead. Tale metodo prende il nome di ODR (On-Demand Routing) e rappresenta una tecnologia proprietaria Cisco.

Nella fattispecie, l'ODR prevede l'uso del protocollo CDP (Cisco Discovery Protocol) per lo scambio delle informazioni tra i router appartenenti ad una topologia Hub-n-Spoke. Nella figura sottostante è possibile visualizzare la topologia in questione:

E' bene notare che l'uso dell'ODR è previsto solo per questo genere di topologia, e proprio grazie ad esso l'Hub (ovvero il router a cui sono connessi tutti gli Spoke) riesce a propagare la default route, attraverso la quale sarà possibile raggiungerlo. Viceversa, gli spoke inviano all'Hub le informazioni relative alle loro reti (direttamente connesse). Tutte le rotte propagate mediante ODR avranno metrica pari a 1 e distanza amministrativa pari a 160. Inoltre, gli update verranno inviati in multicast ogni 60 secondi (per default).

Per una configurazione base dell'ODR occorre usare i seguenti comandi:

Router(config)# router odr (abilita l'ODR);

Router(config)# cdp timer <secondi> (per modificare l'intervallo di tempo relativo all'invio degli update);

Router# sh cdp int (mostra su quale interfaccia è in esecuzione il CDP);

Router# sh ip route (per visualizzare le rotte imparate attraverso l'ODR, identificate dalle lettera "o" scritta in minuscolo).

NB: L'On-Demand Rounting supporta il VLSM, ergo nell'ambito degli update vengono inviate anche informazioni relative alle subnet.

A presto.

L'acronimo RIP sta per Routing Information Protocol e rappresenta uno dei primi protocolli di routing (è stato sviluppato nel 1969 come parte integrante di ARPANET, l'antenata di Internet).

Esso è un protocollo distance-vector e prevede l'invio dell'intera tabella di routing ogni 30 secondi (solo tra i router vicini). La sua distanza amministrativa è 120 e la metrica utilizzata per identificare il costo dei cammini viene calcolata in base al numero di hop, ovvero il numero di salti che un pacchetto compie prima di raggiungere la destinazione.

Il numero massimo di hop supportato dal protocollo in questione è pari a 15. Una rotta avente metrica superiore a 15, di conseguenza, viene marcata come irraggiungibile.

Esistono, inoltre, diversi metodi attraverso i quali è possibile limitare la formazione dei famigerati routing loop. Uno di questi è lo split-horizon, ovvero un router che ha ricevuto l'aupdate di una rotta attraverso una determinata porta (ad esemprio Ethernet0), non potrà rimandare indietro l'update lungo quella stessa porta. Un altro metodo è rappresentato dal route poisoning, letteralmente "avvelenamento di rotta". Nella fattispecie, per fare in modo che non si formino loop, un router assegna ad una determinata rotta una metrica fittizia pari a 16 (in questo modo la rotta viene "avvelenata"), costringendo i router che hanno ricevuto l'update a scegliere percorsi alternativi. Il RIP fa anche uso dei cosiddetti hold-down timers: quando una rotta è irraggiungibile il router scarterà tutti gli update relativi a quella stessa rotta fino allo scadere del timer (solitamente 180 secondi).

Uno dei maggiori limiti del protocollo in questione è rappresentato dal fatto che ha tempi di convergenza abbastanza elevati, oltre a prevedere l'inoltro degli update mediante broadcast, congestionando pesantemente la linea trasmissiva, soprattutto se la banda dispobile è piuttosto limitata. Inoltre, il RIP è un protocollo classfull, ovvero nell'ambito degli update non invia le subnet mask (impedendo l'uso del VLSM). Tale scelta si è rivelata necessaria in quanto, durante i primi anni di vita del protocollo di routing in questione, le velocità di trasmissione erano piuttosto ridotte e quindi si voleva fare in modo che i RIP-update non appesantissero ulteriormente il collegamento.

Altra pecca relativa al RIP riguarda l'assenza di un meccanismo di autenticazione.

Proprio a causa di queste limitazioni è stata realizzata una versione migliorata del RIP, ovvero RIP version 2 (RIPv2). Tale protocollo, per mantenere la retrocompatibilità con il suo predecessore, usa una matrica basata sugli hop (max 15) ed una distanza amministrativa pari a 120. Nell'ambito degli update, però, invia informazioni relative alle subnet (classless) e prevede un meccanismo di autenticazione basato su password in chiaro (piuttosto vulnerabile) oppure sul digest generato mediante algoritmo MD5. Inoltre, a differenza della versione 1, RIPv2 invia gli update in multicast, più precisamente all'indirizzo 224.0.0.9.

Per completezza, riporto qui di seguito alcuni comandi utili per la configurazione e la gestione del RIP (versione 1 e 2) nell'ambito dei router Cisco.

Per abilitare il rip basta digitare:

Router(config)# router rip

Successivamente, se si vuole utilizzare la versione 2, basta scrivere:

Router(config-router)# version 2

Una volta fatto ciò possiamo dichiarare le reti direttamente connesse al router, le quali verranno propagate mediante gli update:

Router(config-router)# network 10.0.0.0

Router(config-router)# network 172.16.0.0

supponendo che al router siano connesse le reti 10.1.2.0/24 (indirizzo di classe A adattato a classe C) e 172.16.2.0/16 (classe B adattato a classe C). Come potete notare ho utilizzato gli indirizzi 10.0.0.0 e 172.16.0.0, ovvero le majornet, in quanto il RIPv1 non riconosce gli indirizzi "adattati" (ad esempio da classe A a classe C), trattandoli come se fossero appartenenti alla classe originaria (classe A).

Se invece utilizziamo RIPv2, possiamo scrivere:

Router(config-router)# network 10.1.2.0

Router(config-router)# network 172.16.2.0

Nel caso in cui avessimo a che fare con molte subnet simili tra loro, per evitare eventuali errori bisogna disabilitare l'auto summarization mediante il comando:

Router(config-router)# no auto-summary (vale solo per il RIPv2).

Per abilitare l'autenticazione su una determinata interfaccia occorre digitare:

Router(config-if)# ip rip authentication mode text (per la password in chiaro)

oppure

Router(config-if)# ip rip authentication mode md5 (per utilizzare md5).

Per ottonere informazioni di diagnostica sullo scambio degli update e sull'autenticazione occorre usare il comando:

Router# debug ip rip

mentre per verificare che una determinata rotta sia stata imparata grazie a tale protocollo di routing basta digitare:

Router# sh ip route (le rotte marcate con R sono quelle identificate mediante RIP)

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route

Gateway of last resort is not set

R    10.1.2.0 [120/12] via 192.16.64.2, 00:03:28, Serial0

C    192.16.64.0/24 is directly connected, Serial0

Nei prossimi post ci soffermeremo sull'EIGRP. A presto.

Il Frame Relay rappresenta la naturale evoluzione del protocollo X.25. A differenza di quest'ultimo, infatti, prevede meccanismi di correzione degli errori, funzionalità non supportata dall'X.25.

Inoltre, è bene notare che il protocollo Frame Relay fa parte del livello 2 della pila ISO/OSI ed in particolare utilizza il DLCI per identificare il percorso tra la sorgente e la destinazione. Ogni DLCI ha significato solo localmente (ovvero solo sul dispositivo in cui è stato settato) e ad ogni DLCI corrisponde generalmente un undirizzo IP (quello del router di destinazione), quindi è come se effettuassimo una vera e propria mappatura tra livello 2 e livello 3. Nella fattispecie, il collegamento che si viene a creare tra sorgente e destinazione viene chiamato circuto virtuale e può essere di tipo statico (PVC - tipico dei collegamenti router-to-router) o dinamico (SVC - tipico dei collegamenti router-to-switch frame relay).

La banda disponibile può essere definita dall'utente, ma solitamente è compresa tra i 64 Kbps e i 2 Mbps, mentre le topologie di rete maggiormente utilizzate nell'ambito di questa tecnologia sono la full mesh, la partial mesh e la cosiddetta hub-n-spoke. Nel primo caso, come si può facilmente intuire, abbiamo una rete completamente magliata, in cui ogni nodo è direttamente collegato a tutti gli altri (per identificare il numero di collegamenti necessari nell'ambito di tale topologia occorre applicare la formula N*(N-1)/2, dove N rappresenta il numero di nodi). Nel secondo caso, invece, abbiamo una magliatura parziale, mentre nel terzo, ad un router sono collegati più router contemporaneamente. Ciò viene realizzato configurando delle interfacce virtuali, ciascuna con il proprio DLCI, in modo da consentire la creazione di più circuiti virtuali sfruttando un unico collegamento fisico, rappresentato dal classico cavo seriale.

Nell'ambito dei dispositivi Cisco, la creazione di un Virtual Circuit può essere effettuata manualmente, ovvero creando una mappatura statica tra DLCI ed indirizzo IP, oppure in modo dinamico. Quest'ultima opzione prevede l'uso della cosiddetta LMI (Local Management Interface), la quale, sfruttando gli Inverse ARP, riesce a ricavare automaticamente l'indirizzo IP dei router direttamente connessi ed associarli ad uno dei DLCI disponibili. Le tipologie di LMI supportate dalle apparecchiature Cisco sono le seguenti:

- Cisco (proprietario);

- ANSI (detto anche AnnexD);

- Q933a;

Ovviemente, affinchè due router possano comunicare tra loro, devono utilizzare necessariamente lo stesso tipo di LMI. Inoltre, una volta creato il VC, esso viene mantenuto attivo grazie all'invio di keepalive effettuato proprio tramite LMI.

Sempre per ciò che concerne i dispositivi Cisco, è possibile utilizzare due tipologie di encapsulation Frame Relay, ovvero Cisco (proprietaria) oppure IETF. Nella fattispecie, per configurare un PVC occorre digitare i seguenti comandi:

Router(config-if)# encapsulation frame-relay ietf (oppure cisco)

Router(config-if)# ip address 192.168.1.1 255.255.255.252 (dove 192.168.1.1 rappresenta l'indirizzo IP dell'interfaccia locale)

Router(config-if)# bandwidth 64 (dove 64 sono i Kbps)

Per la mappatura statica abbiamo:

Router(config-if)# frame-relay map ip 192.168.1.2 100

oppure, per settare il DLCI localmente posso usare il seguente comando:

Router(config-if)# frame-relay interface-dlci 100

Per la mappatura dinamica, invece, occorre digitare:

Router(config-if)# frame-relay lmi-type ansi (oppure cisco o q933a - quest'ultimo rappresenta il tipo di lmi impostato di default nell'ambito delle IOS superiori alla 11.2)

Come già accennato in precedenza, spesso il Frame Relay fa uso di interfacce virtuali. Prima di definire una o più interfacce di questo tipo occorre andare ad abilitare l'interfaccia seriale di riferimento mediante il comando no shutdown, rimuovere eventuali indirizzi IP ad essa precedentemente assegnati e creare successivamente l'interfaccia virtuale vera e propria. Ad esempio:

Router(config-if)# no shutdown

Router(config-if)# interface serial 0/0.1 point-to-point (oppure multipoint)

Router(config-subif)# ip address 192.168.1.1 255.255.255.0

Router(config-if)# interface serial 0/0.2 point-to-point

Router(config-subif)# ip address 192.168.2.1 255.255.255.0

e così via. Ovviamente, per creare VC diversi per ogni sottointerfaccia, occorre utilizzare indirizzi IP appartenenti a reti diverse (come riportato nell'esempio).

E' possibile, inoltre, consentire il traffico broadcast (come i RIP update) lungo i circuiti virtuali, digitando il comando:

Router(config-if)# frame-relay map ip 192.168.1.2 100 broadcast

Un problema tipico delle reti frame-relay è quello relativo all'uso errato dello split horizon. Nella fattispecie, tale tecnica ha come scopo quello di prevenire i routing loop non consentendo l'invio di routing update mediante la stessa interfaccia che li ha ricevuti. Ovviemente, se si utilizzasse lo split horizon nell'ambito di una topologia point-to-multipoint, i routing update ricevuti da un dato router non potrebbero essere inoltrati verso gli altri router della rete. Ecco allora che si può procedere con il disabilitare lo split horizon in modo manuale oppure attraverso la creazione di più sottointerfacce virtuali a sè stanti.

Vediamo adesso alcuni comandi utili alla diagnostica della rete Frame Relay:

Router# show frame-relay map (mostra le mappature layer 2-to-layer 3)

Router# show frame-relay pvc <numero pvc> (consente di vedere il numero di BECN e FECN, campi del frame che segnalano rispettivamente alla sorgente ed alla destinazione uno stato di congestione della rete)

Router# show frame-relay lmi

Router# clear frane-relay-inarp (pulisce le mappature dinamiche).

NB: affinchè tale protocollo possa funzionare correttamente è necessario che vi sia un clockrate, solitamente fornito dagli switch Frame-Relay. Nel caso in cui il collegamento viene realizzato tra due router, nell'ambito della seriale relativa al DCE occorre digitare:

Router(config-if)# frame-relay intf-type dce (comando non supportato da Packet Tracer 5.1).

Inoltre, per disabilitare la mappatura dinamica ed utilizzare solo quella statica si può scrivere:

Router(config-if)# no frame-relay inverse-arp (anche questo comando non è supportato da Packet Tracer 5.1).

Nei prossimi post esamineremo le caratteristiche di un altro protocollo di livello 2 ampiamente utilizzato, ovvero il PPP. A presto.

Il dump di un database non è altro che un file di testo in cui sono contenute delle istruzioni SQL. Tali istruzioni hanno come scopo quello di riprodurre fedelmente il database esportato, in modo che possa essere caricato su un altra macchina continuando a funzionare correttamente.

Per effettuare il dump del database MySQL direttamente da linea di comando occorre digitare (da shell):

mysqldump nome_del_database -u root -p > nome_del_file_dump.pl

dove la flag -u indica l'utente (ovvero root), la flag -p richiede l'inserimento della password di root ed il simbolo > indica che il risultato del comando dovrà essere salvato all'interno del file di destinazione (nome_del_file.pl).

Successivamente, per importare sulla macchina di destinazione il file appena creato è necessario usare i seguenti comandi (sempre da shell):

mysqladmin drop nome_del_database -u root -p

mysqladmin create nome_del_database -u root -p

mysql nome_del_database -u root -p < nome_del_file_dump.pl

Il primo comando ci consente di eliminare eventuali database già presenti nella macchina di destinazione e che possiedono lo stesso nome di quello che stiamo per importare; il secondo comando, invece, ci permette di creare un database vuoto. Infine, l'ultimo comando serve all'importazione vera e propria delle informazioni.

Il post termina qui, a presto.

Abbiamo già visto qual è la logica su cui si basa il funzionamento di alcuni protocolli utilizzati nell'ambito delle WAN, quali Frame Relay e PPP. Oggi, invece, inizieremo a parlare dei protocolli di routing. Sostanzialmente, essi si dividono in 2 categorie, ovvero protocolli distance vector (ad esempio RIP, RIPv2) e protocolli link-state (come OSPF). Esistono comunque dei protocolli ibridi, il cui funzionamento si basa in parte sull'approccio distance vector ed in parte sulla logica link-state (vedi IGRP ed EIGRP, entrambi proprietari Cisco).

Come avrete già intuito, in questo post mi concentrerò esclusivamente sui protocolli IGP (Interior Gateway Protocol), ovvero quelli utilizzati nell'ambito di uno stesso sistema autonomo (AS), tralasciando quindi (almeno per il momento) i protocolli EGP (Exterior Gateway Protocol), come BGP, MPLS e compaglia bella.

Ma qual è la differenza tra i protocolli distance vector e link-state? Beh, in effetti ce ne sono molte. Una tra tutte riguarda l'update delle tabelle di routing: se infatti i protocolli distance vector prevedono lo scambio delle tabelle in questione (per intero) tra i router adiacenti (altrimenti conosciuti come neighbors) ad intervalli di tempro predefiniti, i protocolli link-state fanno in modo che gli aggiornamenti della topologia memorizzata nei router avvenga se e soltato se nella rete si è manifestato un qualche tipo di cambiamento (ad esempio una rotta viene dichiarata irrangiungibile).

Dopo questa breve introduzione, focalizziamo la nostra attenzione sull'OSPF. Tipico esempio di protocollo link-state, esso presenta numerosi vantaggi, tra cui:

1) supporta le VLSM (Variable Lenght Subnet Mask), ovvero le subnet possono essere suddivise in net più piccole in base alle necessità, garantendo un massiccio risparmio di indirizzi IP;

2) prevede un'approccio di tipo gerarchico, in modo tale da limitare ad una sola zona della rete eventuali instabilità o malfunzionamenti, consentendo anche di ridurre l'overhead associato alle operazioni di routing;

3) garantisce tempi di convergenza relativamente bassi (grazie all'architettura gerarchica), anche se esistono dei protocolli migliori da questo punto di vista, come EIGRP;

4) non è un protocollo proprietario, ergo può essere utilizzato nell'ambito di network che utilizzano dispositivi multivendor;

5) supporta il bilanciamento di carico (load balancing), instradando un maggior quantitativo di informazioni lungo i link con banda maggiore;

6) prevede un meccanismo di autenticazione dei messaggi basato su MD5, aumentando notevolmente il livello di sicurezza della rete.

L'architettura gerarchica viene realizzata attraverso l'uso delle cosiddette aree. Tra tutte, quella di maggior importanza è certamente l'area 0, altrimenti conosciuta come backbone area, alla quale devono essere collegate tutte le altre aree presenti nell'ambito della topologia.

Durante la fase di convergenza della rete, l'OSPF si occupa di eleggere il cosiddetto DR (Designated Router) ed il BDR (Backup Designated Router), oltre, ovviamente, a fare in modo che tra i router vicini si vengano a creare le cosiddette adiacenze. A tal proposito, è bene sottolineare il fatto che affinchè due router possano creare l'adiacenza senza problemi, è necessario che i loro hello-interval e dead-interval coincidano. In particolare, l'hello-interval identifica l'intervallo di tempo che deve trascorrere tra l'invio di 2 pacchetti hello consecutivi, in modo che entrambi i router sappiano che il rispettivo vicino sta funzionando correttamente. Il dead-interval, invece, definisce il limite di tempo (in cui non è stato ricevuto alcun hello) oltre il quale il vicino viene dichiarato irragiungibile.

Come si articola, invece, l'elezione del DR e del BDR? Il primo fattore che viene preso in considerazione è il RouterID (RID). Esso è rappresentanto dall'indirizzo di loopback più alto, oppure, in assenza di interfacce virtuali, dall'indirizzo più elevato associato alle interfacce fisiche. Ma perchè dare maggiore priorità alle interfacce virtuali piuttosto che a quelle fisiche? Semplicemente perchè anche nel caso in cui le interfacce fisiche subiscano un guasto o non siano più utilizzabili, il processo di routing OSPF continuerà a funzionare senza problemi, evitando di procedere quindi con l'elezione di un nuovo DR e di un nuovo BDR. Modificando, inoltre, l'indirizzo di loopback è possibile fare in modo che un determinato router divenga DR o BDR.

Altro fattore che influenza l'elezione del DR e del BDR è la priorità della porta. Essa può assumere valori compresi tra 0 e 255, dove lo 0 viene utilizzato per impedire l'elezione a DR o BDR di uno o più router (detti DROTHER), mentre valori più elevati rappresentano una maggiore probabilità di elezione.

Ma perchè eleggere un DR ed un BDR? Semplicemente perchè in questo modo viene ridotto il numero di link all'interno della topologia, ottimizzando il funzionamento dell'algoritmo Dijkstra su cui si basa il protocollo in questione. L'immagine seguente può certamente essere esplicativa:

Da notare che a differenza dell'algoritmo Bellmann-Ford, anch'esso utilizzato per l'individuazione dei cammini minimi, l'algoritmo di Dijkstra non prevede l'uso di pesi negativi per gli archi (sostanzialmente una rete viene vista come un grafo in cui i router rappresentano i nodi mentre i link rappresentano gli archi). A tal proposito è bene sottolineare che il peso di un arco può essere calcolato mediante la seguente operazione aritmetica:

100000000/banda.

Inoltre, proprio grazie al DR viene semplificata notevolmente la procedura di foolding: tutti i router inviano al DR i propri LSA (link state advertisement, ovvero informazioni sullo stato dei collegamenti e dei router vicini, in modo da tenere sempre aggiornato il database che rappresenta la topologia della rete) mediante l'indirizzo multicast 224.0.0.6. Se un determinato LSA indica un'eventuale variazione della topologia (ovvero differisce dai precedenti record del database), il DR provvederà ad inoltrarla a tutti i router della rete utilizzando l'indirizzo multicast 224.0.0.5.

Da quanto detto fin'ora è facile capire perchè è necessaria l'elezione di un BDR. Infatti, nel caso in cui il DR andasse giù, la rete OSPF, pur essendo nominalmente ancora operativa, smetterebbe di funzionare. Ciò può essere evitato proprio grazie all'elezione del Backup Designated Router.

Da notare, inoltre, che nel caso in cui venisse aggiunto un router con ID maggiore ripetto a quello del DR, non verrebbe eletto router designato fino a quando DR e BDR attuali continueranno a funzionare correttamente.

Ma DR e BDR sono le uniche tipologie di router presenti nell'albito delle reti OSPF? La risposta è no. Ad esempio, vi sono gli ABR (Area Border Router), impiegati per coleggare una o più aree alla backbone; gli IR (Internal Router) che formano adiacenze solo con router appartenenti alla loro stessa area; i BR (Backbone Router), ovvero router con un'interfaccia conessa alla backbone area. Da ciò si evince che un ABR è anche un BR ma non sempre vale il viceversa.

Però, non in tutte le tipologie di reti è necessaria l'individuazione del DR e del BDR. Infatti, DR e BDR sono indispensabili nelle rete BMA (Broadcast Multi-Access) e NBMA (Non-Broadcast Multi-Access) mentre sono del tutto superflui nell'ambito dei collegamenti Point-To-Point.

Occorre precisare il fatto che oltre alla backbone area esistono anche altre tipologie di aree, tra cui ricordiamo:

1) stub area, la quale non prevede la ricezione di rotte esterne, ovvero di rotte appartenenti ad altri AS;

2) totally stubby area, la quale oltre a non accettare rotte esterne, non consente la route summarization, ovvero riunire più reti in un'unica supernet;

3) not-so-stubby area, che consente la ricezione e l'inoltro delle rotte esterne solo tra i router ad essa appartenenti.

Vediamo adesso alcuni comandi indispensabili per l'implementazione del protocollo OSPF nell'ambito dei dispositivi Cisco. Per prima cosa bisogna specificare l'istanza ospf, la quale ha significato per il router solo localmente:

Router(confing)# router ospf 1

Da notare che il valore minimo che può essere associato all'instanza OSPF è 1 e non 0.

Dichiaro la banda dei collegamenti:

Router(config-router)# bandwidth 64

dove 64 indica 64 Kbps.

Digitando inoltre:

Router(confing)# default-information originate

consentirò la dichiarazione delle rotte statiche nell'ambito dell'OSPF.

Ora definiamo le reti appertenenti ad una determinata area (nell'esempio useremo la backbone area):

Router(confing-router)# network <indirizzo della net> <wildcard mask> area 0

Ovviamente per ogni router basta definire esclusivamente le reti ad esso direttamente collegate.

Per definire gli hello-interval ed i dead-interval occorre digitare:

Router(confing-if)# ip ospf hello-interval <intervallo in secondi>

Router(confing-if)# ip ospf dead-interval <intervallo in secondi>

Per implementare l'autenticazione è possibile seguire due strade. Una prevede l'uso di una password in chiaro, la quale risulta molto vulnerabile ad attacchi di tipo passivo (sniffing), l'altra invece fa uso dell'algoritmo di cifratura MD5, il quale rende molto più complessa l'eventuale individuazione della password da parte di utenti malevoli.

Nel primo caso è necessario utilizzare il comando:

Router(config-router)# area area 0 authentication

Router(config-if)# ip ospf authentication-key <key>

Per ciò che concerne l'MD5, avremo:

Router(config-router)# area area 0 authentication message-digest

Router(config-if)# ip ospf message-digest-key <keyid> <key>

dove <keyid> rappresenta un valore numerico compreso tra 0 e 7 e deve essere uguale per tutti i router in cui è implementata l'autenticazione mediante algoritmo MD5 (altrimenti non si potrà creare l'adiacenza).

Il comando per impostare la priorità dell'interfaccia è il seguente:

Router(config-if)# ip ospf priority <priorità>

Per ciò che concerne la diagnostica, alcuni comandi utili sono i seguenti:

Router# sh ip ospf interface <interfaccia>

che produrrà un output simile a questo (fornendo informazioni relative al DR ed al BDR se la topologia ne prevede l'utilizzo):

Serial0 is up, line protocol is up
Internet Address 192.16.64.1/24, Area 0
Process ID 10, Router ID 172.16.10.36, Network Type POINT_TO_POINT, Cost: 64
Transmit Delay is 1 sec, State POINT_TO_POINT,
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:04
Index 2/2, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 1, maximum is 1
Last flood scan time is 0 msec, maximum is 4 msec
Neighbor Count is 0, Adjacent neighbor count is 0
Suppress hello for 0 neighbor(s)
Simple password authentication enabled

Router# sh ip ospf neighbor

il quale mostra informazioni associate ai router adiacenti,
ad esempio:

Neighbor ID     Pri   State           Dead Time   Address     Interface
70.70.70.70       1   FULL/  -        00:00:31    192.16.64.2 Serial0

Router# sh ip route

che mostra le rotte conosciute dal router

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route

Gateway of last resort is not set

70.0.0.0/32 is subnetted, 1 subnets
O       70.70.70.70 [110/65] via 192.16.64.2, 00:03:28, Serial0

C   172.16.10.32 is directly connected, Loopback0
C    192.16.64.0/24 is directly connected, Serial0

dove la O indica che quella rotta è stata imparata mediante OSPF, 110 indica la distanza amministrativa di tale protocollo e 65 il costo (metrica) del collegamento.

Router# debug ip ospf adjacency

00:50:57: %LINK-3-UPDOWN: Interface Serial0, changed state to down
00:50:57: OSPF: Interface Serial0 going Down
state DOWN
00:50:57: OSPF: 70.70.70.70 address 192.16.64.2 on Serial0 is dead,
state DOWN
00:50:57: %OSPF-5-ADJCHG: Process 10, Nbr 70.70.70.70 on Serial0 from FULL to DOWN,
Neighbor Down: Interface down or detached
00:50:58: OSPF: Build router LSA for area 0, router ID 172.16.10.36,
seq 0x80000009
00:50:58: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0,
changed state to down
00:51:03: %LINK-3-UPDOWN: Interface Serial0, changed state to up
00:51:03: OSPF: Interface Serial0 going Up
00:51:04: OSPF: Build router LSA for area 0, router ID 172.16.10.36,
seq 0x8000000A
00:51:04: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0,
changed state to up
00:51:13: OSPF: 2 Way Communication to 70.70.70.70 on Serial0,
state 2WAY

dove

00:51:13: %OSPF-5-ADJCHG: Process 10, Nbr 70.70.70.70 on Serial0 from LOADING
to FULL, Loading Done
00:51:14: OSPF: Build router LSA for area 0, router ID 172.16.10.36,
seq 0x8000000B

indica che l'adiacenza è stata creata correttamente.

Ovviamente questa guida rappresenta un piccolo sunto delle potenzialità relative al protocollo OSPF, se volete ulteriori informazioni potrete trovarne a migliaia su Internet.

Il post termina qui, bye.

In questo post abbiamo visto cosa si intende per MAC (Message Authentication Code) e come esso venga realizzato mediante alcune tecniche HASH. Adesso ci soffermeremo sul progetto HMAC, il cui scopo è quello di consentire l'uso di un qualunque algoritmo di cifratura one-way per l'autenticazione dei messaggi.

Ma perchè utilizzare algoritmi HASH con scopi di autenticazione di messaggio? Perchè sono ottimizzati per la loro esecuzione a livello software e sono facilmente reperibili su Internet sottoforma di librerie. Nonostante ciò, essi presentano una limitazione, ovvero non utilizzano una chiave segreta e quindi non possono essere direttamente utilizzati nell'ambito del MAC.

Ecco allora che proprio per sopperire a tale limitazione viene realizzato il progetto HMAC. Esso, in sintesi, si prefigge 5 obiettivi, ovvero:

1) utilizzare, senza procedere con la loro modifica, le funzioni HASH già esistenti (soprattutto quelle caratterizzate da buone prestazioni software);

2) sostituire facilmente, in caso di necessità, la funzione HASH utilizzata con un'altra che prevede migliori prestazioni ed una maggiore robustezza;

3) preservare le prestazioni originarie HASH ;

4) gestire facilmente le chiavi segrete;

5) garantire un elevato livello di sicurezza, anche grazie alle caratteristiche intrinseche dell'algoritmo di cifratura one-way utilizzato.

I primi due punti sono garantiti dall'HMAC, poichè esso vede la funzione HASH come una scatola nera. In questo modo, anche nel caso in cui la sicurezza della funzione di cifratura fosse compromessa, la si potrebbe sostituire facilmente.

Inoltre, il meccanismo HMAC può considerarsi sicuro nel momento in cui l'algoritmo di cifratura one-way è sicuro.

Vediamo adesso qual è il funzionamento complessivo di HMAC:

dove:

1) il blocco "hash" rappresenta la funzione hash contenuta (ad esempio MD5);

2) M rappresenta il messaggio in ingresso ad HMAC;

3) L rappresenta il numero di blocchi in cui è stato suddiviso il messaggio M;

4) Yi rappresenta l'i-esimo blocco di M, con 0 <= i <= (L-1)

5) b è il numero di bit di un blocco;

6) n è la lunghezza del codice HASH prodotto dalla funzione di cifratura one-way contenuta;

7) K è la chiave segreta: se la lunghezza della chiave è maggiore di b, allora essa verrà data in pasto alla funzione HASH per generare il digest di n bit; la lunghezza consigliata è >= n.

8) K+ è la chiave completata con una serie di zeri a sinistra (padding) in modo da raggiungere la lunghezza minima indispensabile, ovvero b bit;

9) ipad è pari a 00110110 (36 in hex) ripetuto b/8 volte (se ad esempio b=16 avrò 0011011000110110, ovvero 00110110 ripetuto due volte);

10) opad è pari a 01011100 (5C in hex) ripetuto b/8 volte;

Il byte che identifica opad ed ipad viene ripetuto b/8 volte poichè non è possibile "xorare" sequenze di bit di lunghezza diversa.

Ecco, nello specifico, le operazioni effettuate nell'ambito dell'HMAC:

1) aggiungo una serie di 0 a sinistra della chiave K per ottenere la lunghezza minima di b bit, in questo modo otterrò K+;

2) effettuo lo XOR tra K+ e l'ipad;

3) accodo al risultato dello XOR, ovvero Si, il messaggio M suddiviso in L blocchi dalla lunghezza di b bit;

4) applico la funzione HASH ad (Si || M), sfruttando un opportuno vettore di inizializzazione IV;

5) se l'HASH generato ha dimensione inferiore a b bit effettuo uno zero-padding portando la sua lunghezza a b bit;

6) calcolo lo XOR tra K+ e l'opad, generando S0;

7) accodo ad S0 l'hash precedentemente generato e il risultato di tale operazione lo do in pasto alla funzione HASH, inizializzata mediante il cosiddetto IV;

8) ottengo HMAC(K,M) (costituito da n bit).

Queste operazioni possono essere riassunte nella formula:

HMAC(K, M)= H[(K+ XOR opad) || H[(K+ XOR ipad || M]]

Da notare che i tempi di esecuzione di HMAC sono approssimativamente uguali a quelli della funzione HASH utilizzata.

A presto.