Sei sulla pagina 1di 189

Dopo la seconda edizione del libro "Teoria, laboratori ed esercizi per

Mikrotik RouterOS" qualche lettore ha chiesto di estendere il lavoro


anche ad altri argomenti chiave del sistema RouterOS di Mikrotik.
Da questa richiesta e mettendo in ordine i miei appunti sul routing
avanzato è nato questo librettino che vuole approfondire i temi
principali del routing attraverso la lente dell’esplorazione del sistema
RouterOS utilizzato nei prodotti Mikrotik. Al tempo stesso questo
libro vuole essere una concreta preparazione per l'esame Mikrotik
Certified Routing Engineer (MTCRE) anche attraverso l’analisi di
casi reali in cui il routing avanzato è uno strumento fondante e
risolutivo. Se volete potete fare un tweet mettendo in copia @vittore.
Per la complessità degli argomenti ho dovuto tralasciare alcune linee
guida che mi avevano aiutato nel primo libro: in quasi tutti i laboratori
di questo libro c'è bisogno di più di un router e i laboratori non si
trovano alla fine di ogni capitolo ma sono stati spostati in modo da
affrontarli in punti utili per rafforzare la conoscenza appena acquisita.
Questo testo è un work-in-progress. Tutti i suggerimenti sono ben
accetti. Se avete indicazioni scrivete a vittore@zen.pn.it . Un grazie
particolare va ai miei colleghi che si sono sacrificati nel provare tutti
gli esercizi e all'amico Andrea R. che fa da cavia didattica.
Routing di base
«Seconda stella a destra, questo è il cammino.. e poi dritto fino al
mattino!» Edoardo Bennato

L’instradamento (routing) è alla base della funzionalità di rete


implementata dalle entità di livello 3 (OSI) e consente a due nodi A e
B, non collegati direttamente, di comunicare tra di loro mediante la
collaborazione di altri nodi posti su un cammino nella rete che
connette A e B.

Routing.
Il compito del livello di rete è quindi la trasmissione di pacchetti tra
due host arbitrari, che in generale non sono direttamente connessi,
ovvero non hanno un collegamento diretto tra di loro. Nel modello
ISO/OSI, il software del livello di rete è presente in tutti i nodi della
rete, mentre quello dei livelli superiori è presente solo nei nodi
terminali. In dettaglio, le funzioni del livello di rete sono:

Inoltro , ovvero ricevere un pacchetto su una porta,


immagazzinarlo e ritrasmetterlo su
un'altra. Questa funzione è presente in tutti i nodi della rete e
può comportare l'utilizzo di protocolli di livello di collegamento
differenti.
Frammentazione : se un pacchetto ricevuto ha una
dimensione eccessiva per la rete su cui deve
essere trasmesso, il livello di rete lo divide in frammenti e si
occupa di riassemblare i frammenti ricevuti al momento della
consegna.
Instradamento (routing) : ovvero determinare il percorso
per la trasmissione dei dati attraverso
la rete. Nella maggior parte dei casi questa funzione viene
svolta dinamicamente tramite appositi algoritmi, che analizzano
le condizioni della rete, le tabelle di instradamento, la priorità del
servizio e altri elementi secondari.
Controllo della congestione : avere la possibilità di dare
una priorità maggiore ai dati più critici.

Scopo del routing: connettere reti.


Il routing è necessario quando la rete inizia a diventare complessa;
se vogliamo:

poter monitorare e gestire in modo migliore la rete;


rendere più sicura la rete in quanto i filtri del firewall diventano
più semplici e completi;
migliorare le prestazioni concentrando il traffico di broadcast
solo in ciascuna sottorete/rete;
connettere tra di loro reti IP pubbliche;
connettere Wide Area Netwok diverse (azienda, provider,...).

Il principio su cui si basa il routing IP è molto semplice: inviare i


pacchetti sul cammino minimo verso la destinazione. Il calcolo viene
eseguito in modo distribuito dai router mediante uno scambio di
informazioni con gli altri router; nella tabella che ogni router possiede
e che indica quale direzione deve prendere il pacchetto viene
indicato solo il prossimo router sul cammino (next hop ), non l'intero
percorso. Questo approccio sfrutta la proprietà dei grafi secondo la
quale anche i sotto-cammini di un cammino minimo sono minimi.

Classificazione del routing


Il routing cioè il processo per l'inoltro dei pacchetti da una rete ad
altre reti può avvenire utilizzando:

Instradamento statico - In questo caso gli amministratori


eseguono il routing manualmente definendo ogni rete e il
relativo gateway di destinazione e ripetendo questa operazione
per ogni router presente in tutte le reti connesse.
Instradamento dinamico - In questo caso gli amministratori
fanno solo una semplice configurazione in cui si abilita la
funzione di routing dinamico su ciascuno router ed i router
cercano automaticamente i percorsi e il miglior gateway da tutte
le reti connesse.
Classificazione dei protocolli di routing dinamico
routing-protocols

I componenti del routing in RouterOS


Il router mantiene le informazioni di routing in due spazi separati:

RIB (Routing Information Base) - è la tabella di routing


FIB (Forwarding Information Base) - è la tabella di inoltro

Router Information Base (RIB)

rib La tabella di routing è una tabella di dati che in uno specifico


router elenca tutti i percorsi conosciuti verso determinate reti (rotte).
Per ogni rotta viene indicata la metrica che rappresenta il costo che
si spende percorrendo tale percorso. La tabella di routing è formata
da:

tutte le rotte raccolte dai protocolli di routing dinamico;


tutti i percorsi per le reti connesse, cioè per le interfacce
direttamente collegate al router;
ogni percorso aggiuntivo manualmente (rotte statiche).

In RouterOS la tabella di routing è visualizzabile usando il menù IP


> Route > List .
Tabella di routing (RIB)
La tabella di routing è usata per:

filtrare le informazioni di routing di tutti i tipi protocollo di routing;


calcolare e sceglire il percorso migliore per una certa rete;
creare e aggiornare la tabella di inoltro (vedi sezione fib );
distribuire le informazioni di routing utilizzando i protocolli di
routing dinamico.

Per ogni voce presente nella tabella di routing sono presenti delle
lettere che indicano lo stato della rotta secondo le abbreviazioni
riportate nella tabella table:route-flag :
Etichett
Proprietà Descrizione
a
disabilitata X La rotta è disabilitata cioè non è usata.
attiva A La rotta è usata per inoltrare i pacchetti.
La rotta è stata creata dal software in modo
dinamica D
automatico.
Non verrà esportata e non può essere
modificata direttamente.
connessa C Rotta connessa.
statica S Rotta statica.
rip r Creata attraverso il protocollo RIP.
bgp b Creata attraverso il protocollo BGP.
ospf o Creata attraverso il protocollo OSPF.
mme m Creata attraverso il protocollo MME.
Non considerare i pacchetti indirizzati verso
blackhole B
questa rotta e
non notificare a nessuno l'azione.
non Non considerare i pacchetti indirizzati verso
U
raggiungibile questa rotta ma
notifica la situazione con un messaggio
ICMP.
Non considerare i pacchetti indirizzati verso
proibita P
questa rotta ma
notifica la situazione con un messaggio
ICMP.
Etichette associabili ad una rotta
table:route-fla g

Forwarding Information Base (FIB)

fib Le tabelle di routing (RIB) non sono generalmente utilizzate


direttamente per l'inoltro dei pacchetti; i dati presenti nel RIB
vengono utilizzati per generare delle tabelle più piccole e specifiche
chiamate tabelle di inoltro: Forwarding Information Base (FIB). Una
tabella di inoltro contiene solo il percorso selezionato dall'algoritmo
di routing per continuare l'instradamento del pacchetto verso la sua
destinazione. Questo percorso è spesso sotto forma di cache in
formato compresso o precompilato, in formato ottimizzato per
l'archiviazione e la ricerca per lo specifico hardware del router. Nei
dispositivi Cisco questo componente è denominato Cisco Express
Forwarding (CEF). Quindi la tabella di inoltro:

è il prodotto della tabella di routing dopo che è stata filtrata;


è una copia cache;
tutti i percorsi attivi si trovano nella tabella principale;
se non sono utilizzate le marchiature del routing tutte le default
route saranno in main (vedi dopo per capire questo passaggio)
vi è una sola regola implicita nascosta (regola "catch all") che
utilizza la tabella principale per tutte le ricerche di destinazione.

Come vengono usate le tabelle RIB e FIB

FIB usa le seguenti informazioni del pacchetto per determinarne la


destinazione:

indirizzo di partenza,
indirizzo di destinazione,
interfaccia sorgente,
eventuale marchiatura del routing,
ToS (tipo di servizio) - campo attualmente non utilizzato dal
protocollo IPv4 - non utilizzato da RouterOS nelle regole di
routing, ma fa parte della chiave di ricerca nella cache di
routing.

Le possibili decisioni di routing sono:

ricevere pacchetti localmente


scartare il pacchetto (silenziosamente o inviando un messaggio
ICMP al mittente del pacchetto)
inviare il pacchetto a un indirizzo IP specifico su un'interfaccia
specifica

I risultati della decisione di routing sono ricordati nella cache di


routing (FIB) per migliorare le prestazioni di inoltro. Quando viene
instradato un altro pacchetto con lo stesso indirizzo di origine,
indirizzo di destinazione, interfaccia di origine, marchiatura di routing
e ToS, vengono utilizzati i risultati memorizzati nella cache. Ciò
consente anche di implementare il bilanciamento del carico per
connessione (per-connection load balancing ) tramite rotte ECMP,
poiché i valori utilizzati per cercare la voce nella cache di routing
sono gli stessi per tutti i pacchetti che appartengono alla stessa
connessione e vanno nella stessa direzione.
Forwarding Information Base (FIB)
Se non esiste alcuna voce di routing nella cache per un pacchetto
allora viene creata eseguendo una decisione di routing secondo il
seguente processo:

viene controllato se il pacchetto debba essere consegnato


localmente (l'indirizzo di destinazione è l'indirizzo del router),
vengono elaborate le regole di routing implicite,
vengono elaborate le regole di routing aggiunte dall'utente,
viene elaborata la regola catch-all implicita che cerca la
destinazione nella tabella di routing principale,
se tutti i passi precedenti falliscono allora risultato di ritorno è
"rete irraggiungibile".

Le regole che non corrispondono al pacchetto corrente vengono


ignorate. Se la regola ha una azione drop o unreachable allora
questo viene restituito come risultato del processo decisionale di
instradamento. Se l'azione è la ricerca, l'indirizzo di destinazione del
pacchetto viene cercato nella tabella di routing specificata nella
regola. Se la ricerca fallisce (non esiste alcuna rotta che corrisponda
all'indirizzo di destinazione del pacchetto), allora la FIB procede alla
regola successiva. Altrimenti:

se il tipo di percorso è blackhole, vietato o irraggiungibile, allora


restituisce questa azione come risultato della decisione di
routing;
se si tratta di una rotta connessa o di una rotta che ha indicata
un'interfaccia come valore di gateway, allora restituisce questa
interfaccia e l'indirizzo di destinazione del pacchetto come
risultato della decisione di instradamento;
se questa rotta ha l'indirizzo IP come valore del gateway, allora
restituisce questo indirizzo e l'interfaccia associata come
risultato della decisione di instradamento;
se questa rotta ha più di un valore di nexthop, allora restituisce
uno di loro in modalità round robin.

Il risultato di questa decisione di routing viene memorizzato nella


nuova voce della cache di routing. Si noti come dal processo
indicato viene ritornata una decisione di routing che può essere:

Indirizzo IP dell'interfaccia nextho p


interfaccia point-to-point
consegna locale
scartare
ICMP proibito
Host ICMP irraggiungibile
Rete ICMP non raggiungibile
Interoperabilità tra RIB e FIB

Rotta predefinita
La rotta con indirizzo di destinazione 0.0.0.0/0 si applica a tutti gli
indirizzi di destinazione. Tale percorso è chiamato rotta predefinita
(default route ) e il router indicato è chiamato default gateway . Se la
tabella di routing contiene una rotta predefinita attiva allora la ricerca
nella tabella di routing avrà sempre successo. Per usare una
analogia è come viaggiare in una città e trovare un cartello stradale
con l'indicazione "tutte le direzioni".

Rotte connesse
Le rotte connesse vengono create automaticamente per ogni rete IP
che ha almeno un'interfaccia abilitata ad essa collegata (come
specificato nella configurazione dell'indirizzo IP). RIB tiene traccia
dello stato delle rotte collegate ma non le modifica. Per ogni rotta
connessa esiste un indirizzo ip in modo tale che:

la rete dst-address della rotta connessa sia uguale alla rete


dell'indirizzo ip
la netmask del dst-address della rotta connessa sia uguale alla
netmask dell'indirizzo ip
il pref-src della rotta connessa sia uguale all'indirizzo ip
l'interfaccia della rotta connessa sia uguale all'interfaccia
Corrispondenza tra indirizzi e rotte connesse.
Abbiamo visto che ogni volta che aggiungiamo un indirizzo IP su
un'interfaccia valida (interfaccia attiva) viene creata
automaticamente una rotta connessa. E' da notare che se ci sono
due indirizzi IP che provengono dalla stessa sottorete e dalla stessa
interfaccia ci sarà un solo percorso collegato. Per questo è
importante non posizionare due indirizzi IP della stessa sottorete su
due interfacce diverse, perché confonderà il RIB. Per lo stesso
motivo è suggerito che nel caso una interfaccia abbia più indirizzi ip
della stessa sottorete solo il primo indirizzo sia indicato con la
netmask completa mentre gli altri saranno indicati con la netmask
/32.
Come descritto all'inzio del capitolo in MikroTik RouterOS sono
possibili rotte dinache e rotte statiche. Le prime sono create
automaticamente quando si aggiunge un indirizzo IP ad una
interfaccia oppure attraverso informazioni di routing ottenute da
protocolli specifici come RIP, OSPF e BGP. Le rotte statiche sono
informazioni di routing inserite manualmente dall'utente
(amministratore della rete) per definire uno specifico percorso. La
rotta predefinita è un esempio di rotta statica.
Routing statico
Le rotte statiche vengono aggiunte creando una entry nella RIB e
definiscono un percorso statico dove instradare i pacchetti. Viene
indicata la rete di destinazione e il router (gateway ) da utilizzare per
tale destinazione. Il gateway può essere:

indirizzo IP,
l'interfaccia.

Si ricorda che se in Dst-address si indica 0.0.0.0/0 si includono tutti


gli IP su internet e si crea una rotta di default.

Aggiunta di una rotta statica


Durante l'aggiunta di una rotta statica abbiamo a disposizione i
seguenti parametri:

destinazione;
l'indirizzo di destinazione e maschera di rete;
0.0.0.0/0 se si tratta di una rotta di default.
gateway:
l'indirizzo IP del gateway, deve essere l'indirizzo IP di una
sottorete con IP installato su una delle interfacce del router;
il gateway sotto forma di interfaccia: viene utilizzato quando
il gateway IP è sconosciuto oppure è dinamico ad esempio
nel caso di una connessione punto-punto o seriale.
pref source:
l'indirizzo IP di origine del pacchetto che lascerà il router,
di solito è l'indirizzo IP installato sull'interfaccia su cui si
trova il gateway.
distanza:
viene utilizzata per il calcolo del percorso e per la selezione
della rotta;
il valore varia da 0 a 255
per impostazione predefinita il valore è deciso in base al
protocollo di routing utilizzato:
percorsi connessi: 0
percorsi statici: 1
eBGP: 20
OSPF: 110
RIP: 120
MME: 130
iBGP: 200
si noti che una distanza pari a 255 significa “rejected”.
scope e target scope (letteralmente "ambito e ambito di
applicazione"):
utilizzato per nexthop lookup ricorsivo (vedi più avanti la
sezione scope a pagina scope ) .

Laboratori
Prima di eseguire i laboratori che seguono assicurarsi di aver
risposto correttamente alle domande di riepilogo a pagina
domande-1 .

Routing statico - guidato

Routing statico semplice


Questo laboratorio permette di ricreare l'infrastruttura di rete della
figura routing-statico-semplice e di constatare la correttezza delle
proprie risposte.

1. ripristina la configurazione router (senza impostazione


predefinita);
2. collegare i laptop tra i partecipanti in base alla topologia sopra ;
3. inserire nel router R1 la seguente configurazione:
{R1}
/ip address
add address=10.10.20.1/24 interface=ether1
network=10.10.20.0
add address=10.10.10.1/24 interface=ether2
network=10.10.10.0
add address=11.11.11.2/24 interface=ether3
network=11.11.11.0
/ip route add distance=1 dst-address=0.0.0.0/0
gateway=11.11.11.1
/system identity set name=R1

4. inserire nel router R2 la seguente configurazione:


{R2}
/ip address
add address=11.11.11.1/24 interface=ether1
network=11.11.11.0
add address=22.22.22.2/24 interface=ether2
network=22.22.22.0
/ip route
add distance=1 dst-address=0.0.0.0/0 gateway=22.22.22.2
add distance=1 dst-address=10.10.10.0/24 gateway=11.11.11.2
add distance=1 dst-address=10.10.20.0/24 gateway=11.11.11.2
/system identity set name=R2

Il laboratorio è eseguito correttamente se è possibile eseguire il ping


tra i due laptop ed entrambi riescono a raggiungere con il comando
ping l'interfaccia 22.22.22.2.

Routing statico - in autonomia

Routing statico semplice


Questo laboratorio permette di ricreare l'infrastruttura di rete della
figura routing-statico-semplice-2 in autonomia.

Rete con routing statico


routing-statico-semplice-2
Esegui in autonomia le seguenti operazioni:

1. ripristina la configurazione router (senza impostazione


predefinita);
2. collegare i laptop tra i partecipanti in base alla topologia sopra;
3. effettua il routing statico su ogni router come indicato nello
schema.

Il laboratorio è eseguito correttamente se è possibile eseguire il ping


tra i tre laptop.

Soluzioni al laboratorio

{R1}

/system identity set name=R1


/ip address
add address=192.168.1.1/24 interface=ether1 network=192.168.1.0
add address=12.12.12.1/24 interface=ether2 network=12.12.12.0
/ip route
add distance=1 dst-address=23.23.23.0/24 gateway=12.12.12.2
add distance=1 dst-address=192.168.2.0/24 gateway=12.12.12.2
add distance=1 dst-address=192.168.3.0/24 gateway=12.12.12.2

{R2}

/system identity set name=R2


/ip address
add address=192.168.2.1/24 interface=ether1 network=192.168.2.0
add address=12.12.12.2/24 interface=ether2 network=12.12.12.0
add address=23.23.23.2/24 interface=ether3 network=23.23.23.0
/ip route
add distance=1 dst-address=192.168.1.0/24 gateway=12.12.12.1
add distance=1 dst-address=192.168.3.0/24 gateway=23.23.23.3

{R3}
/system identity set name=R3
/ip address
add address=192.168.3.1/24 interface=ether1 network=192.168.3.0
add address=23.23.23.3/24 interface=ether2 network=23.23.23.0
/ip route
add distance=1 dst-address=192.168.1.0/24 gateway=23.23.23.2
add distance=1 dst-address=192.168.2.0/24 gateway=23.23.23.2

Domande di riepilogo
domande-1

1. Il valore predefinito della distanza per una rotta statica è:


1. 255
2. 1
3. 10
4. 0
2. Nella tabella di routing sono presenti le seguenti rotte:

0 dst=192.168.1.0/24 gateway=192.168.1.1
1 dst=192.168.1.0/25 gateway=192.168.1.2
Quale gateway sarà usato per raggiungere l'ip 192.168.1.5?
1. Entrambi, metà del traffico attraverso 192.168.1.1 e l'altra
metà attraverso 192.168.1.1
2. Attraverso 192.168.1.1
3. Attraverso 192.168.1.2
4. La rotta necessaria non è presente nella tabella di routing
3. Il valore predefinito della distanza per una rotta connessa è:
1. 255
2. 1
3. 10
4. 0
4. Una rotta può avere contemporaneamente il flag D e S?
1. Sì
2. No
5. Una rotta può avere contemporaneamente il flag A,DC e S?
1. Sì
2. No
6. Nella tabella di routing sono presenti le seguenti rotte:

0 dst=192.168.1.0/24 gateway=192.168.1.1 distance=10


1 dst=192.168.1.0/25 gateway=192.168.1.2 distance=20

Quale gateway sarà usato per raggiungere l'ip 192.168.1.5?


1. Entrambi, metà del traffico attraverso 192.168.1.1 e l'altra
metà attraverso 192.168.1.1
2. Attraverso 192.168.1.1
3. Attraverso 192.168.1.2
4. Nessuna perchè la distanza è >=10
7. Ricordando che i router gateway devono essere sempre nella
sotto rete di una interfaccia IP del router rispondere alle
seguenti domande in riferimento alla figura routing-statico-
semplice :
Rete con routing statico
routing-statico-semplice
1. Sul laptop A, qual è il gateway IP sulla rete 11.11.11.0/24?
2. Sul laptop A, qual è il gateway IP per la rete è
22.22.22.0/24?
3. Sul laptop A, qual è l'IP del gateway predefinito?
4. In R1, qual è il gateway IP sulla rete 22.22.22.0/24?
5. In R1, qual è l'IP del gateway predefinito?
6. Su R2, quali gateway IP bisogna impostare per raggiungere
le reti dei laptop?

Soluzioni

1. b, 1
2. c, attraverso 192.168.1.2 in quanto si tratta della sotto rete più
specifica .
3. d, 0
4. No, D=dinamic, S=static, si escludo a vicenda.
5. Sì, si tratta di una rotta (A)ttiva, (C)onnessa ed inserita
(S)taticamente.
6. c, attraverso 192.168.1.2 in quanto si tratta della sotto rete più
specifica; la distanza viene valutata in seguito.
1. 10.10.20.1
2. 10.10.20.1
3. 10.10.20.1
4. 11.11.11.1
5. 11.11.11.1
6. Per la rete 10.10.10.0/24 bisogna impostare il gateway
11.11.11.2; per la rete 10.10.20.0/24 bisogna impostare il
gateway 11.11.11.2 .
Routing statico avanzato
«Di qua di là prima o poi da qualche parte amico si arriverà» Jovanotti

Una delle peculiarità del protocollo TCP/IP e nello specifico del


routing ip è la capacità di instradare i pacchetti su percorsi diversi al
fine di suddividere il carico e di rendere la struttura tollerante ai
guasti. Si parla di load balancing (bilanciamento del carico)
quando si distribuiscono i carichi di lavoro su due o più collegamenti
di rete per massimizzare il throughput, ridurre al minimo il tempo di
risposta ed evitare il sovraccarico. Si parla di fail over quando si
aggiunge ridondanza ai percorsi per mantenere la connessione
anche quando il collegamento principale viene interrotto: ad esempio
nel caso il primo link venga interrotto verrà automaticamente abilitato
il percorso di backup sul secondo o terzo link.

Tipi di bilanciamento del carico


RouterOS mette a disposizione diversi metodi per il bilanciamento
del carico:
bilanciamento del carico per pacchetto:
divisione del carico in base al pacchetto (pacchetto 1
attraverso il gateway
a, pacchetto 2 attraverso il gateway b);
utilizzo della funzione Mikrotik denominata interface
bonding ;
bilanciamento del carico per connessione:
distribuzione del carico in base alla connessione come ad
esempio la connessione 1 tramite gateway a,
e la connessione 2 tramite gateway b;
utilizzo della funzione Mikrotik denominata NTH (si veda
http://bit.ly/2VGGx9t );
bilanciamento del carico per coppia di indirizzi sulla singola
connessione:
funzioni ECMP e PCC (Peer Connection Classified) ;
selezione del traffico basata su connessione e indirizzo IP
di origine e destinazione
dalla connessione stessa;
bilanciamento del carico personalizzato.

Equal Cost Multi Path (ECMP)


La tecnica Equal Cost Multi Path, letteralmente "percorsi multipli di
ugual costo", consente al router di avere più di un gateway per la
stessa rete di destinazione. Ogni gateway inserito in questo contesto
sarà selezionato secondo un algoritmo round-robin in base alla
coppia degli indirizzi sorgente e di destinazione. Si noti che lo stesso
gateway può essere ripetuto più volte. Per configurare correttamente
il bilanciamento del carico ECMP bisogna inserire le rotte come in
figura ecmp-add-routes ed inoltre se il router utilizza un src-NAT
masquerade verso l'esterno è importante ricordarsi di impostare il
masquerade su tutte le interfacce interessate al routing bilanciato
come in figura ecmp-add-masquerade . Con ECMP tutti i gateway
nexthop raggiungibili vengono copiati nella FIB e utilizzati per l'inoltro
dei pacchetti.
ECMP - passo 1
ecmp-add-routes

ECMP - passo 2
ecmp-add-masquerade

Laboratorio

ecmp
Per questo laboratorio sono necessari tre router e due pc.
ECMP
Obiettivo di questo laboratorio è comprendere come aggiungere
rotte statiche che abbiano la stessa destinazione ma gateway
differenti in modo da realizzare un semplice bilanciamento del
carico in uscita di tipo ECMP. L'obiettivo è realizzare la
configurazione della figura ecmp-lab1 . Nello specifico i due pc
devono riuscire a navigare in internet utilizzando i due router R2 e
R3, situazione verificabile mediante il comando trace eseguito dai
due pc.

ECMP - laboratorio
ecmp-lab1

1. Una volta collegati i router e i pc come in figura ecmp-lab1 si


proceda
con il caricamento delle seguenti configurazioni; si ponga
particolare attenzione alla configurazione del router R1. Le
configurazioni sono riportate nell'ordine con cui vanno eseguite.
{R2}

/system identity set name=R2


/ip address
add address=192.168.12.2/24 interface=ether2
network=192.168.12.0
/ip dhcp-client add disabled=no interface=ether1
/ip firewall nat
add action=masquerade chain=srcnat out-interface=ether1

{R3}
/system identity set name=R3
/ip address
add address=192.168.13.3/24 interface=ether3
network=192.168.13.0
/ip dhcp-client add disabled=no interface=ether1
/ip firewall nat
add action=masquerade chain=srcnat out-interface=ether1

{R1}
/system identity set name=R1
/interface bridge add fast-forward=no name=bridge-lan
/interface bridge port
add bridge=bridge-lan interface=ether1
add bridge=bridge-lan interface=ether5
/ip address
add address=192.168.12.1/24 interface=ether2
network=192.168.12.0
add address=192.168.13.1/24 interface=ether3
network=192.168.13.0
add address=192.168.1.1/24 interface=bridge-lan
network=192.168.1.0
/ip pool add name=lan ranges=192.168.1.100-192.168.1.200
/ip dhcp-server
add address-pool=lan disabled=no interface=bridge-lan
name=lan
/ip dhcp-server network
add address=192.168.1.0/24 dns-server=8.8.8.8
gateway=192.168.1.1 \
netmask=24
#
# Parte rilevante ai fini del laboratorio
#
/ip firewall nat
add action=masquerade chain=srcnat out-interface=ether2
add action=masquerade chain=srcnat out-interface=ether3
/ip route add distance=1 gateway=192.168.13.3,192.168.12.2

2. Dal primo pc si esegua il comando ping 8.8.8.8 e


successivamente si analizzi il risultato del comando
trace 8.8.8.8 (o tracert, o traceroute a seconda della
piattaforma usata). Si noti l'indirizzo del secondo router passato
per raggiungere il server 8.8.8.8.
PC-1> ip dhcp
IP 192.168.1.199/24 GW 192.168.1.1
PC-1> ping 8.8.8.8
84 bytes from 8.8.8.8 icmp_seq=1 ttl=57 time=29.995
ms
84 bytes from 8.8.8.8 icmp_seq=2 ttl=57 time=22.312
ms
84 bytes from 8.8.8.8 icmp_seq=2 ttl=57 time=22.312
ms
84 bytes from 8.8.8.8 icmp_seq=2 ttl=57 time=22.312
ms
PC-1> trace 8.8.8.8
trace to 8.8.8.8, 8 hops max, press Ctrl+C to stop
1 192.168.1.1 7.092 ms 1.321 ms 0.351 ms
2 192.168.12.2 12.790 ms 1.035 ms 1.095 ms

3. Dal secondo PC si esegua il comando ping 8.8.8.8 e


successivamente si analizzi il risultato del comando
trace 8.8.8.8 (o tracert, o traceroute a seconda della
piattaforma usata). Si noti l'indirizzo del secondo router passato
per raggiungere il server 8.8.8.8.
PC-2> ip dhcp
IP 192.168.1.198/24 GW 192.168.1.1
PC-2> ping 8.8.8.8
84 bytes from 8.8.8.8 icmp_seq=1 ttl=57 time=24.320
ms
84 bytes from 8.8.8.8 icmp_seq=2 ttl=57 time=24.227
ms
84 bytes from 8.8.8.8 icmp_seq=3 ttl=57 time=22.744
ms
84 bytes from 8.8.8.8 icmp_seq=4 ttl=57 time=23.995
ms
PC-2> trace 8.8.8.8
trace to 8.8.8.8, 8 hops max, press Ctrl+C to stop
1 192.168.1.1 0.513 ms 0.215 ms 0.298 ms
2 192.168.13.3 1.923 ms 0.655 ms 0.556 ms
ecmp-domanda Domanda di approfondimento. \\ Si sarebbe
potuto semplificare il laboratorio, cioé se avessimo utilizzato un solo
PC si sarebbe potuto notare l'uso delle due rotte in bilanciamento?
Risposta. \\ No. Poiché i risultati della decisione di routing
vengono memorizzati nella cache, i pacchetti con lo stesso indirizzo
di origine, indirizzo di destinazione, interfaccia di origine, marcatura
di routing e ToS vengono inviati sempre allo stesso gateway. Ciò
significa che una connessione utilizzerà un solo collegamento in
ciascuna direzione in quanto le rotte ECMP implementano il
bilanciamento del carico per connessione. Nel caso sia necessario
raggiungere il bilanciamento del carico per pacchetto e non per
connessione si veda la tecnica denominata interface bonding .
Quindi per notare l'effetto di questo tipo di bilanciamento bisogna
avere delle connessioni che si distinguano per indirizzo di origine
oppure indirizzo di destinazione oppure interfaccia di origine oppure
marcatura di routing oppure ToS.

Domanda di approfondimento. \\ Cosa succede se uno dei


gateway smette di funzionare? La connessione dei PC ad internet
funziona ancora?
Nel caso in cui i gateway abbiano capacità di traffico diverse è
possibile impostare più volte lo stesso gateway per la stessa
destinazione. Ad esempio se ci sono due gateway e il link A ha una
capacità di 64k e il Link B ha una capacità di 32k possiamo
procedere con il seguente calcolo: Calcoliamo le proporzioni dei
canali di comunicazione: 64k:32k=2:1 Calcoliamo il totale del canale
di comunicazione: A+B=3 Saranno indicati tre gateway, 2 volte sarà
indicato il gateway del link A e una volta il gateway del link B.

Distanza amministrativa (distance)


La distanza amministrativa (distance ) viene utilizzata per scegliere il
percorso migliore quando ci sono due o più percorsi diversi oppure ci
sono protocolli di routing diversi verso la stessa destinazione. Il
valore dalla distanza è un valore impostabile da 0 a 255. Se il valore
della distanza non è impostato allora viene determinato in base al
protocollo di routing:
Distanz
Tipo di rotta
a
Rotte connesse 0
Rotte statiche 1
eBGP 20
OSPF 110
RIP 120
MME 130
iBGP 200
Le distanze più piccole saranno prioritarie nella selezione delle
tabelle instradamento.

Laboratorio

distance
Per questo laboratorio sono necessari tre router e due pc.
Distanz a
Obiettivo di questo laboratorio è comprendere come influisce il
valore della distanza nella selezione della rotta attiva.

1. Si parta dallo schema e dalle configurazioni del laboratorio


ecmp .
2. Dal router R1 si rimuova la rotta ECMP
{R1}
/ip route add distance=1 gateway=192.168.13.3,192.168.12.2

3. Sul router R1 si aggiungano le rotte:


{R1}
/ip route add distance=1 gateway=192.168.12.2
/ip route add distance=2 gateway=192.168.13.3

4. Dai due pc si analizzino i percorsi di uscita con il comando trace


o equivalente.
5. Si scolleghi il cavo che collega il router R1 con il router R2.
6. Dai due pc si analizzino i percorsi di uscita con il comando trace
o equivalente.

Opzione "Check-gateway"
check-gateway RouterOS mette a disposizione un meccanismo di
controllo dei gateway che viene eseguito in background.
Periodicamente (ogni 10 secondi) viene controllato il gateway
inviando una richiesta echo ICMP (ping) o una richiesta ARP (arp);
se non viene ricevuta alcuna risposta dal gateway entro 10 secondi,
la richiesta scade (timeout). Dopo due timeout il gateway è
considerato irraggiungibile. Viceversa per un gateway considerato
irraggiungibile, dopo aver ricevuto di nuovo una risposta, il gateway
è considerato raggiungibile e il contatore del timeout viene
ripristinato.
E' importante notare che se si attiva la funzione Check-Gateway per
una rotta allora tutte le rotte con lo stesso gateway sottostarranno
allo stesso controllo.

Laboratorio

check-gateway
Per questo laboratorio sono necessari tre router e due pc.
Check-gateway
Obiettivo di questo laboratorio è comprendere come influisce il
meccanismo di controllo della vitalità di un router (check-gateway)
nella selezione della rotta attiva.

1. Si parta dallo schema e dalle configurazioni del laboratorio


distance .
2. Dal router R1 si modifichi la rotta aggiungendo il metodo Check-
Gateway indicato come in figura :
Check-Gateway
3. Si controlli che le rotte siano corrette:

Rotta attiva con entrambi i router raggiungibili.


4. Dai due pc si analizzino i percorsi di uscita con il comando trace
o equivalente.
5. Si scolleghi il cavo che collega il router R1 con il router R2.
6. Si attendano almeno 20 secondi.
7. Dai due pc si analizzino i percorsi di uscita con il comando trace
o equivalente.
8. Si controlli che le rotte siano corrette su R1:
Rotta attiva con il router R1 non raggiungibile.
9. Si compari la rotta attiva prima e dopo la rimozione del cavo di
collegamento.

Politiche di routing
Quando la decisione per l'inoltro del pacchetto usa informazioni
addizionali, come ad esempio l'indirizzo sorgente del pacchetto, si
parla di "politica di routing". La politica di routing è realizzata
attraverso delle liste da cui vengono selezionate le diverse tabelle di
routing basandosi sull'indirizzo di destinazione, l'indirizzo sorgente,
l'interfaccia sorgente ed una eventuale marcatura del routing stesso.
Per fare questo è necessario marcare il traffico per poi assegnarlo
ad una specifica tabella di routing. La marcatura del pacchetto per
una specifica tabella di routing viene gestita dal firewall (IP >
Firewall > Mangle ) e può riguardare il singolo pacchetto oppure
l'intera connessione. Per questioni di performance si preferisce
marcare il primo pacchetto di una connessione e poi marcare
conseguentemente tutta la connessione: in questo modo il firewall
utilizzerà una minore quantità di CPU per la gestione. Il secondo
passo per una politica di routing è la creazione di tabelle di routing
specifiche per il traffico marcato. Per impostazione predefinita, il
router utilizza la tabella di routing main (principale) ma si possono
creare tabelle di routing aggiuntive e configurare il router affinché
utilizzi una tabella specifica. Per fare questo si può agire su due
versanti:

1. IP > Route > Rules


2. IP > Firewall > Mangle > Route-mark

Usando IP > Route > Rules si può specificare l'uso di una tabella
di routing in base ad alcuni parametri (si veda la figura policy-
routing-rule ) come ad esempio:

indirizzo di destinazione,
marcatura della rotta presente nel pacchetto,
interfaccia di arrivo.

Aggiunta di una regola nella politica di routing


policy-routing-rule
Le rotte possono essere assegnate ad una specifica tabella di
routing impostando la proprietà routing-mark della singola rotta con il
nome della tabella di routing. Si noti che le tabelle di routing hanno
come riferimento per l'uso il loro nome e sono create
automaticamente quando c'è un qualche riferimento a loro nella
configurazione: ad esempio se si crea una regola di marcatura (IP >
Firewall > Mangle ) che fa riferimento alla marcatura della rotta
"ISP3" allora nelle rotte (IP > Route s) si troverà il riferimento alla
tabella di routing ISP3.

Marcatura del routing (routing mark)

La marcatura del routing avviene utilizzando quanto messo a


disposizione nella finestra raggiungibile mediante il menù IP >
Firewall > Mangle . Per indirizzare il traffico che è più specifico
attraverso un percorso, il traffico deve essere identificato prima che
attraversi il processo di routing. Nell'appendice, alla pagina packet-
flow , è schematizzato come i pacchetti transitano in RouterOS. Per
ottenere questo bisogna agire in diversi punti a seconda del tipo di
traffico che si vuole intercettare e marcare:

per il traffico che attraversa il router si utilizza la catena di


prerouting ;
per il traffico proveniente dal router e in uscita dal router si
utilizza la catena di output ;

Bisogna essere molto accorti in questa fase in quanto ogni pacchetto


può avere solo un segno di routing. Inoltre se c'è almeno una rotta
che usa il routing mark per uno specifico traffico allora la tabella di
routing principale verrà ignorata.

Laboratorio

Per questo laboratorio sono necessari tre router e due pc.


Marcatura del routing
Obiettivo di questo laboratorio è comprendere come agisce il
meccanismo di marcatura del routing: il traffico ICMP dovrà usare il
router R3 mentre il restante traffico dovrà transitare attraverso il
router R2.
Routing mark - laboratorio
ecmp-lab-routing-mark
Per analizzare meglio l'effetto di queta configurazione dobbiamo
ricorrere ad un piccolo stratagemma che in seguito useremo anche
per altri laboratori di questo testo. Verranno utilizzati due router
collegati ad internet ma con code che riducano la banda a
disposizione a dei valori molto bassi (1k) in modo da rilevare con
immediatezza l'effetto voluto. E' possibile che sia necessario
modificare il valore 1k con un valore superiore (32k o 64k) in caso in
cui sui pc da cui si esegue il test sia presente del traffico di
background (aggiornamenti di windows, Dropbox,...).

1. Una volta collegati i router e i pc come in figura ecmp-lab-


routing-mark si proceda con il caricamento delle seguenti
configurazioni di partenza.
Per semplicità logica ed operativa si carichino prima le
configurazioni dei due router R2 ed R3 usati come controllo del
laboratorio. {R2}
/system identity set name=R2
/ip address
add address=192.168.12.2/24 interface=ether2
network=192.168.12.0
/ip dhcp-client add disabled=no interface=ether1
/ip firewall nat
add action=masquerade chain=srcnat out-interface=ether1
#
# Impostazione della coda con limitazione a 1k/1k
#
/queue simple add target=0.0.0.0/0 max-limit=1k/1k
{R3}
/system identity set name=R3
/ip address
add address=192.168.13.3/24 interface=ether3
network=192.168.13.0
/ip dhcp-client add disabled=no interface=ether1
/ip firewall nat
add action=masquerade chain=srcnat out-interface=ether1
#
# Impostazione della coda con limitazione a 1k/1k
#
/queue simple add target=0.0.0.0/0 max-limit=1k/1k

{R1}
/system identity set name=R1
/interface bridge add fast-forward=no name=bridge-lan
/interface bridge port
add bridge=bridge-lan interface=ether1
add bridge=bridge-lan interface=ether5
/ip address
add address=192.168.12.1/24 interface=ether2
network=192.168.12.0
add address=192.168.13.1/24 interface=ether3
network=192.168.13.0
add address=192.168.1.1/24 interface=bridge-lan
network=192.168.1.0
/ip pool add name=lan ranges=192.168.1.100-192.168.1.200
/ip dhcp-server
add address-pool=lan disabled=no interface=bridge-lan
name=lan
/ip dhcp-server network
add address=192.168.1.0/24 dns-server=8.8.8.8
gateway=192.168.1.1 \
netmask=24
/ip firewall nat
add action=masquerade chain=srcnat out-interface=ether2
add action=masquerade chain=srcnat out-interface=ether3

2. Prima di procedere si controlli il corretto funzionamento delle


code impostate. Per questo da uno dei due pc generare del
traffico internet (http, https, ftp,...) e verificare che in Queue >
Simple la coda del router R2 passi da verde a rossa.
Coda limitata ad 1k/1k senza traffico che attraversa il router R2

Coda limitata ad 1k/1k con traffico che attraversa il router R2


3. Ora andremo ad agire solo sul router R1, le indicazioni che
seguono si riferiscono a questo router se non specificato
esplicitamente.
In IP > Firewall > Mangle aggiungiamo la marcatura del
routing per i pacchetti ICMP:

Marcatura del routing per pacchetti ICMP


4. Aggiungiamo le due rotte:
Rotte da aggiungere su R1
Risultato finale del routing
5. Su uno dei due pc generare del traffico ICMP mediante il
comando ping 8.8.8.8 .
Si suggerisce di generare traffico usando entrambi i pc oppure
usare le opzioni del comando per generare un flusso superiore
a 1kbps, ad esempio con ping 8.8.8.8 -l 1000 -t .
6. Si noti come il traffico ICMP fluisce attraverso router R3 (si veda
lo stato della coda) mentre il restante traffico, ad esempio http,
fluisce attraverso il router R2.

Caso reale

Bill ha un router Mikrotik con una linea ADSL fornita dal provider
ISP1 che collega i client della sua rete ad internet. Bill aggiunge una
seconda linea ADSL con il provider ISP2 e vuole che questa sia solo
per alcuni utenti specifici, VIP che stanno pagando un po' di soldi
extra per una migliore velocità, in quanto l'attuale collegamento con
ISP1 è intasata dal traffico degli altri utenti.

Soluzione

La soluzione segue la seguente logica:

1. Si creano due liste di indirizzi ip e si aggiungono gli ip degli


utenti VIP o NORMAL
2. Si aggiungono due regole di marchiatura del traffico (mangle)
per marcare i pacchetti generati dagli utenti VIP e NORMAL.
3. Si specificano due rotte di default con gli appropriati routing
mark e gateway.
4. Si aggiungano le regole di NAT.

# Aggiunta degli indirizzi IP sulle interfacce


#
/ip address
add address=192.168.2.1/24 disabled=no interface=LAN
network=192.168.2.0
add address=192.168.5.1/24 disabled=no interface=WAN1
network=192.168.5.0
add address=192.168.6.1/24 disabled=no interface=WAN2
network=192.168.6.0
# Creazione di due liste di indirizzi
# In questo caso aggiungiamo solo
# un indirizzo per ogni lista
#
/ip firewall address-list
add address=192.168.2.6 disabled=no list=VIP_USERS_LIST
add address=192.168.2.7 disabled=no list=NORMAL_USERS_LIST
# Marcatura del traffico che proviene da specifici indirizzi
#
/ip firewall mangle
add action=mark-routing chain=prerouting new-routing-
mark=wan1_user \
passthrough=no src-address-list=VIP_USERS_LIST
add action=mark-routing chain=prerouting new-routing-
mark=wan2_user \
passthrough=no src-address-list=NORMAL_USERS_LIST
# Creazione delle rotte per il traffico marcato
#
/ip route
add disabled=no distance=1 dst-address=0.0.0.0/0 \
gateway=192.168.5.2 routing-mark=wan1_user scope=30 target-
scope=10
add disabled=no distance=2 dst-address=0.0.0.0/0 \
gateway=192.168.6.2 routing-mark=wan2_user scope=30 target-
scope=10
# NAT per l'uscita in Internet
#
/ip firewall nat
add action=masquerade chain=srcnat disabled=no src-
address=192.168.2.0/24

Per maggiori dettagli si veda l'articolo https://goo.gl/uDx2Dy .


Tempo di vita (time to live - TTL)
TTL è un campo dell'intestazione IP del pacchetto di dati che
stabilisce per quanto tempo il pacchetto può circolare sulla rete. Il
valore di questo campo avviserà il router se il pacchetto deve essere
inoltrato al router successivo (router nexthop) o scartato. Il valore
TTL predefinito è 64 (8 bit) e viene ridotto di uno ad ogni
attraversamento di un router, poco prima della decisione di inoltrare
il pacchetto. Il router non farà avanzare il pacchetto se il TTL che
riceve vale 1 (si veda figura ttl ).

Utilizzo del TTL nel protocollo ICMP


ttl
L'utilità di questa funzione diventa evidente se si immagina una
situazione in cui per errore o guasto si viene a creare un loop in una
catena di router. Il TTL può anche essere utilizzato per determinare il
numero di router attraversati da un pacchetto. Ad esempio il
comando traceroute, presente in molti sistemi operativi, sfrutta il TTL
per determinare approssimativamente il percorso tra due host.
Dapprima viene mandato verso l'host di destinazione un pacchetto
con TTL=1: questo pacchetto viene ovviamente scartato dal primo
router, che segnala al mittente con il messaggio ICMP le sue
coordinate. Successivamente viene inviato un pacchetto con TTL=2,
che viene scartato dal secondo router che così si identifica.
L'operazione è reiterata fino al raggiungimento dell'host di
destinazione.

Ambito (scope)
scope Il meccanismo del check gateway, descritto nella sezione
check-gateway a pagina check-gateway , può rilevare problemi di
connessione solo nel router più vicino. Se il problema si verifica
dopo il gateway più vicino, il controllo del gateway non può rilevalo.
Per ovviare a questo inconveniente e per selezionare
efficientemente il prossimo router a cui inoltrare il traffico si possono
utilizzate tecniche che definiscono l'ambito (scope ) del routing
stesso. La ricerca del nexthop fa parte del processo di selezione del
percorso: le rotte installate nella FIB devono avere un'interfaccia
associata a ciascun indirizzo gateway, in questo modo l'indirizzo del
gateway è direttamente raggiungibile tramite questa interfaccia. Con
l'espressione ricerca ricorsiva del nexthop si intende la ricerca del
gateway e dell'interfaccia da usare per dar seguito alla rotta anche
se è presente un gateway non direttamente collegato al router.
Questo è dovuto al fatto che alcune rotte (ad es. IBGP) possono
avere un indirizzo gateway che si trova a diversi hop da questo
router. Per installare tali percorsi nella FIB è necessario trovare
l'indirizzo del gateway direttamente raggiungibile (un nexthop
immediato), che sarà utilizzato per raggiungere l'indirizzo gateway di
questa rotta.
La ricerca del nexthop viene eseguita solo nella tabella di routing
principale anche per le rotte con una marcatura diversa di routing.
Durante questa ricerca è necessario limitare la serie di percorsi che
possono essere utilizzati per cercare nexthops immediati; questo
risultato è ottenuto utilizzando le proprietà scope e target-scope.

Le rotte che hanno il nome dell'interfaccia come valore del


gateway non vengono utilizzate per la ricerca nexthop.
Se la rotta ha come nexthop sia una interfaccia che un indirizzo
IP attivo allora il nexthop con l'interfaccia viene ignorato.
Le rotte con scope superiori al valore massimo accettato non
vengono utilizzate per la ricerca nexthop:
infatti ogni rotta specifica il massimo valore di scope accettato
per i suoi nexthops nella proprietà target-scope . Il valore
predefinito di questa proprietà consente la ricerca di nexthop
solo attraverso percorsi connessi, ad eccezione delle rotte iBGP
che hanno un valore predefinito più ampio e che quindi possono
cercare nexthop anche tramite iBGP e rotte statiche. Per i valori
predefiniti di scope e target-scope si veda la figura default-
scope-target-scope .
Valori predefiniti di scope e target scope
default-scope-target-scope
In sintesi l'interfaccia e il nexthop immediato sono selezionati in base
al risultato della ricerca nexthop con la seguente logica:

Se il percorso attivo più specifico rilevato trova una rotta


connessa,
allora l'interfaccia di questa rotta connessa viene utilizzata come
interfaccia nexthop e questo gateway è contrassegnato come
raggiungibile. Poiché il gateway è direttamente raggiungibile
attraverso questa interfaccia (che è esattamente ciò che
significa rotta connessa) allora l'indirizzo gateway viene
utilizzato come indirizzo immediato di nexthop.
Se il percorso attivo più specifico individuato trova che nexthop
è già stato risolto,
l'indirizzo e l'interfaccia nexthop immediati vengono copiati da
quel nexthop e questo gateway viene contrassegnato come
ricorsivo.
Se la rotta attiva più specifica rilevata trova una rotta ECMP
allora
si utilizza il primo gateway di quella rotta che non è
irraggiungibile.
Se la ricerca non trova alcuna rotta allora questo gateway è
contrassegnato come irraggiungibile.

Esempio

Semplice risoluzione di nexthop ricorsiva - passo 1


simple-nexthop-lookup-step-1

Semplice risoluzione di nexthop ricorsiva - passo 2


simple-nexthop-lookup-step-2

Nexthop 10.2.0.1 viene risolto tramite una rotta connessa, lo


stato è raggiungibile (figura simple-nexthop-lookup-step-1 );
nexthop 10.3.0.1 viene risolto in modo ricorsivo attraverso una
route 10.3.0.0/16 (figura simple-nexthop-lookup-step-2 );
lo stato è ricorsivo e utilizza 10.2.0.1 come valore immediato
nexthop installato nel FIB.
Analizzando attentamente la figura default-scope-target-scope si
vede come il percorso può rispondere a nexthop solo attraverso
un'altra rotta che ha una portata inferiore o uguale al target-scope,
cioè il massimo valore di scope accettato. Questo meccanismo si
può utilizzare:

per monitorare, attraverso il comando ping, un gateway che non


è direttamente connesso al router;
combinato con iBGP (su questo ritorneremo più avanti parlando
del protocollo BGP e delle sue due varianti iBGP ed eBGP).

Caso reale

Supponiamo di avere diversi collegamenti WAN e vogliamo


monitorare se internet è accessibile attraverso ciascuno di essi. Il
problema può essere ovunque. Se il modem ADSL non funziona,
check-gateway con ping è chiaramente la soluzione e nessun
problema; ma cosa succede se il modem è attivo e la linea telefonica
non funziona? Oppure se uno dei ISP ha un problema al suo interno,
quindi traceroute mostra solo alcuni hop - e poi si ferma ... Alcune
persone usano lo strumento NetWatch per monitorare le posizioni
remote; altri usano gli script per eseguire periodicamente il ping degli
host remoti e conseguentemente disabilitare le rotte o in qualche
altro modo modificare il comportamento del routing. Ma le
funzionalità di RouterOS ci permettono di avere una soluzione a
questi problemi solo usando \ip routes , niente scripting e netwatch.

Esempio

Supponiamo di avere due uplink GW1 e GW2 . Questi possono


essere l'indirizzo di modem ADSL (come 192.168.1.1 e 192.168.2.1)
oppure indirizzi di interfacce PPP (come pppoe-out1 e pptp-out1).
Poi abbiamo alcune regole di routing che ad esempio specificano
che tutto il traffico in uscita è contrassegnato con i marchi ISP1 (che
va a GW1) e ISP2 (che va a GW2). Ciò che ci interessa è monitorare
host1 tramite GW1 e host2 tramite GW2; dove host1 e host2
possono essere alcuni siti Internet popolari, come Google, Yahoo,
ecc. Prima di tutto si creano le rotte per questi host tramite il
gateway GW1 corrispondenti usando uno scope=10:
/ip route
add dst-address=Host1 gateway=GW1 scope=10
add dst-address=Host2 gateway=GW2 scope=10

Tali percorsi verranno risolti in modo ricorsivo e saranno attivi solo se


host N è raggiungibile mediante ping. Similmente si creano le rotte
per questi host tramite il gateway GW2 corrispondenti usando uno
scope=10:
/ip route
add dst-address=Host1 gateway=GW2 scope=10
add dst-address=Host2 gateway=GW2 scope=10

Per maggiori dettagli su questa tecnica si veda l'articolo


https://goo.gl/mYofKP . Possiamo semplificare affermando che lo
scope e il target-scope possono essere usati per cambiare il risultato
nella risoluzione del nexthop; ricordiamo infatti che normalmente i
nexthops possono essere risolti solo attraverso le rotte che sono sul
link. La possibilità di impostare sia lo scope che il target-scope dei
nexthops è una funzione potente e come tale può essere facilmente
abusata. È possibile creare loop nella risoluzione del nexthop. Se si
verifica un ciclo logico nella tabella di instradamento, RouterOS non
si bloccherà, ma semplicemente si fermerà per, eventualmente,
risolvere il problema successivamente. Ecco l'esempio di un
semplice loop con tre rotte non connesse che si risolvono una con
l'altra:
/ip route add
dst-address=1.1.1.0/24 gateway=2.2.2.2 scope=10 target-
scope=10
dst-address=2.2.2.0/24 gateway=3.3.3.3 scope=10 target-
scope=10
dst-address=3.3.3.0/24 gateway=1.1.1.1 scope=10 target-
scope=10

che produce la seguente situazione:


[admin@R3] > /ip route print
Flags: X - disabled, A - active, D - dynamic,
C - connect, S - static, r - rip, b - bgp, o - ospf,
B - blackhole, U - unreachable, P - prohibit
# DST-ADDRESS PREF-SRC G
GATEWAY DISTANCE
INT
ERFACE
0 S 1.1.1.0/24 2.2.2.2 1
1 S 2.2.2.0/24 3.3.3.3 1
2 S 3.3.3.0/24 1.1.1.1 1

Tipi di rotte
Ci sono dei tipi di rotte che vengono usate per bloccare la rete o un
indirizzo dst di destinazione con comportamenti diversi:

Blackhole: blocca e non informa nessuno dell'operazione.


Proibisci: blocca e invia un messaggio di errore amministrativo
ICMP proibito (tipo 3 codice 13).
Irraggiungibile: blocca e invia messaggi di errore dell'host ICMP
irraggiungibile (tipo 3 codice 1).

Laboratorio

Per questo laboratorio sono necessari tre router e due pc.


Tipi di rotte
Obiettivo di questo laboratorio è comprendere l'uso dei diversi tipi di
rotte.
Tipi di rotte - laboratorio
route-type-lab

1. Una volta collegati i router e i pc come in figura route-type-lab si


proceda con il caricamento delle seguenti configurazioni:
{R1}
/system identity set name=R1
/ip address add address=192.168.1.1/24 interface=ether1
/ip address add address=12.12.12.1/24 interface=ether2
/ip route
add dst-address=192.168.3.0/24 gateway=12.12.12.2

{R2}
/system identity set name=R2
/ip address add address=12.12.12.2/24 interface=ether1
/ip address add address=23.23.23.2/24 interface=ether2
/ip route
add distance=1 dst-address=192.168.1.0/24
gateway=12.12.12.1
add distance=1 dst-address=192.168.3.0/24
gateway=23.23.23.3

{R3}
/system identity set name=R3
/ip address add address=23.23.23.3/24 interface=ether1
/ip address add address=192.168.3.1/24 interface=ether2
/ip route
add distance=1 dst-address=192.168.1.0/24
gateway=23.23.23.2
2. Si assegnino ai due pc i rispettivi indirizzi ip statici indicati in
figura route-type-lab .
3. Dal primo pc si esegua il comando ping 192.168.3.2 e
successivamente si analizzi il risultato del comando.
4. Nel router R2 si cambi il tipo di rotta come di seguito e dopo
ogni cambiamento si ripeta il ping precedente analizzato il
risultato del comando:
{R2}
/ip route add
# Secondo test
dst-address=192.168.3.0/24 gateway=23.23.23.3
type=blackhole
# Terzo test
dst-address=192.168.3.0/24 gateway=23.23.23.3 route-
type=prohibit
# Primo test
dst-address=192.168.3.0/24 gateway=23.23.23.3 route-
type=unreachable

Con la rotta:
{R2}
/ip route add dst-address=192.168.3.0/24
gateway=23.23.23.3

Si ottiene:
PC-1> ping 192.168.3.2
84 bytes from 192.168.3.2 icmp_seq=1 ttl=61 time=6.317
ms
84 bytes from 192.168.3.2 icmp_seq=2 ttl=61 time=1.753
ms
84 bytes from 192.168.3.2 icmp_seq=3 ttl=61 time=1.607
ms
84 bytes from 192.168.3.2 icmp_seq=4 ttl=61 time=2.905
ms
84 bytes from 192.168.3.2 icmp_seq=5 ttl=61 time=3.034
ms

Con la rotta:
{R2}
/ip route add dst-address=192.168.3.0/24 type=blackhole
Si ottiene:
PC-1> ping 192.168.3.2
192.168.3.2 icmp_seq=1 timeout
192.168.3.2 icmp_seq=2 timeout
192.168.3.2 icmp_seq=3 timeout
192.168.3.2 icmp_seq=4 timeout
192.168.3.2 icmp_seq=5 timeout

Con la rotta:
{R2}
/ip route add dst-address=192.168.3.0/24 type=prohibit

Si ottiene:
PC-1> ping 192.168.3.2
*12.12.12.2 icmp_seq=1 Communication administratively
prohibited
*12.12.12.2 icmp_seq=2 Communication administratively
prohibited
*12.12.12.2 icmp_seq=3 Communication administratively
prohibited
*12.12.12.2 icmp_seq=4 Communication administratively
prohibited
*12.12.12.2 icmp_seq=5 Communication administratively
prohibited

Con la rotta:
{R2}
/ip route add dst-address=192.168.3.0/24
type=unreachable

Si ottiene:
PC-1> ping 192.168.3.2
*12.12.12.2 icmp_seq=1 Destination host unreachable
*12.12.12.2 icmp_seq=2 Destination host unreachable
*12.12.12.2 icmp_seq=3 Destination host unreachable
*12.12.12.2 icmp_seq=4 Destination host unreachable
*12.12.12.2 icmp_seq=5 Destination host unreachable

Sorgente preferita
pref-src La proprietà pref-src, utilizzabile durante la scrittura di una
rotta statica, indica quale degli indirizzi IP locali è da utilizzare per i
pacchetti originati localmente ed inviati tramite questa rotta. E'
importante considerare che:

il valore di questa proprietà non ha effetto sui pacchetti inoltrati;


se il valore di questa proprietà è impostato su indirizzo IP che
non è l'indirizzo locale di questo router, il percorso sarà inattivo;
se il valore pref-src non è impostato, per i pacchetti originati
localmente che vengono inviati utilizzando questo rotta verrà
scelto uno degli indirizzi locali collegati all'interfaccia di output
che corrispondono al prefisso di destinazione del percorso.

In genere questa proprietà viene utilizzata quando vogliamo gestire il


traffico di un uplink e di un downlink. Si consideri il seguente
esempio:
[admin@MikroTik] > /ip address print
# ADDRESS NETWORK BROADCAST INTERFAC
E
0 10.1.0.3/16 10.0.0.0 10.1.255.255 ether1
1 10.2.0.3/16 10.0.0.0 10.2.255.255 ether2
[admin@MikroTik] > /ip route print
# DST-ADDRESS PREF-
SRC GATEWAY DISTANCE INTERFACE
0 A S
0.0.0.0/0 10.1.0.1 1 eth
er1
10.2.0.1
ether2
1 ADC
10.1.0.0/16 10.1.0.3 0 eth
er1
2 ADC
10.2.0.0/16 10.2.0.3 0 eth
er2

I pacchetti con indirizzo di destinazione 10.1.1.1 saranno


inoltrati usando la rotta connessa (numero 1) attraverso
l'interfaccia ether1 verso l'host con indirizzo 10.1.1.1 .
I pacchetti con indirizzo di destinazione 10.50.0.1 saranno
inoltrati usando la rotta statica (numero 0) attraverso l'interfaccia
ether2 verso il gateway 10.1.0.1 oppure attraverso l'interfaccia
ether2 verso il gateway 10.2.0.1.
I pacchetti originati localmente con indirizzo di destinazione
10.100.0.1 saranno inoltrati usando la rotta statica (numero 0)
attraverso l'interfaccia ether1 verso il gateway 10.1.0.1 oppure
attraverso l'interfaccia ether2 verso il gateway 10.2.0.1.
I pacchetti originati localmente con indirizzo di destinazione
10.2.1.1 saranno inoltrati usando la rotta connessa (numero 2)
attraverso l'interfaccia ether2 verso l'host con indirizzo 10.2.1.1
usando l'indirizzo sorgente 10.2.0.3.

Come detto in precedenza se la rotta non ha impostata la proprietà


pref-src allora l'indirizzo sorgente di un pacchetto originato
localmente è selezionato dagli indirizzi locali del router:

questo indirizzo locale è assegnato all'interfaccia di output;


il gateway è corrispondente a questo indirizzo locale.

Quindi, in questo esempio, se un pacchetto originato localmente


viene inviato al gateway 10.1.0.1 allora sarà scelto l'indirizzo locale
10.1.0.3 perché:

l'indirizzo 10.1.0.3 è assegnato all'interfaccia di output di questa


rotta (ether1);
il gateway 10.1.0.1 è dentro la rete 10.1.0.0/16.

Domande di riepilogo
domande-2

1. Il valore predefinito per una rotta statica del 'target-scope' è:


1. 255
2. 1
3. 10
4. 0
2. Se si attiva la funzione Check-gateway per una rotta allora tutte
le rotte
con lo stesso gateway sottostarranno allo stesso controllo?
1. Sì
2. No
3. Per indirizzare il traffico che è più specifico attraverso un
percorso con il routing-mark, il traffico deve essere identificato
prima o dopo il processo di routing?
1. Prima
2. Dopo
4. La proprietà pref-src indica quale degli indirizzi IP sono preferire
come destinazione per un gateway?
1. Sì
2. No
5. Nella configurazione del protocollo ECMP lo stesso gateway
può essere ripetuto più volte per la stessa destinazione?
1. Sì
2. No
6. Con ECMP solo il gateway nexthop con IP più basso viene
copiato nella FIB?
1. Sì
2. No
7. Con ECMP se il router utilizza un src-NAT masquerade verso
l'esterno non è necessario indicare un masquerade per ogni
indirizzo.
1. Sì
2. No
8. ECMP realizza il bilanciamento del carico:
1. Per connessione.
2. Per indirizzo sorgente.
3. Per indirizzo di destinazione.

Soluzioni

1. 10.
2. Sì.
3. Prima (si veda lo schema a pagina packet-flow ).
4. No, la a proprietà pref-src indica quale degli indirizzi IP locali è
da utilizzare per i pacchetti originati localmente ed inviati tramite
una specifica rotta.
5. Sì.
6. No, vengono copiati nella FIB ECMP tutti i gateway nexthop
raggiungibili.
7. No, bisogna indicare tutti gli indirizzi verso cui il masquerade
agisce.
8. a, per connessione. Si vedano le domande di approfondimento
a pagina ecmp-domanda .

OSPF: Open Shortest Path First


«E a questa folle velocità forse soltanto un girotondo ci salverà...»
Edoardo Bennato

Routing dinamico
Il routing avanzato si avvale di protocolli di routing statici e dinamici
(vedi figura routing-protocols a pagina routing-protocols ); i router
che usano protocolli di tipo statico gestiscono una tabella di
instradamento realizzata ed aggiornata manualmente
dall’amministratore di rete, mentre i router che usano protocolli
dinamici provvedono da se a creare ed aggiornare tale tabella
trovando informazioni presso altri router dinamici e su tutti i loro
segmenti. I router dinamici contengono informazioni costantemente
aggiornate sui possibili percorsi attraverso la rete, nonché
informazioni sui colli di bottiglia e sulle interruzioni del collegamento.
Tali informazioni permettono loro di individuare la strada più
efficiente, disponibile in un determinato momento, per inoltrare un
pacchetto dati alla sua destinazione. Le reti sono raggruppate in
Autonomous system (AS), cioè in gruppi di router e di reti controllate
e gestiti da un'unica entità. Gli AS sono identificati tramite un numero
intero, univoco a livello mondiale, assegnato dalla stessa autorità
che rilascia gli indirizzi internet. I router che instradano i messaggi
all'interno dello stesso AS sono detti interior router o anche internal
router , mentre quelli che instradano i messaggi tra AS diversi sono
detti exterior router .

Definizioni per il routing di reti estese


Nel caso di intradomain routing, i router interni devono conoscere
solo i segmenti di rete appartenenti allo stesso AS, non è quindi
necessario che mantengano informazioni sulle reti esterne; essi si
limitano a mandare ai router di confine quei pacchetti destinati fuori.
Questa organizzazione ha dei notevoli vantaggi, poiché riduce
notevolmente le dimensioni delle tabelle di routing in quanto le reti
esterne non sono presenti direttamente in queste tabelle se non
attraverso il border router, il quale penserà come raggiungere le
destinazioni richieste. Inoltre un altro beneficio riguarda appunto il
router stesso, che dovrà sostenere un carico di lavoro inferiore,
rendendo la rete più efficiente. Nel caso di intradomain routing , il
border router dovrà necessariamente tenere traccia sia delle reti
interne che appartengono al proprio AS, sia degli altri border ruoter.
In aggiunta questi router di frontiera sono responsabili anche della
traduzione dei protocolli nel caso in cui i vari AS usino protocolli di
routing diversi. Nell'arco del tempo i protocolli di routing dinamico
hanno scelto diversi approcci matematici; tra i più diffusi ricordiamo:

protocolli di routing basati su distance vector;


protocolli di routing basati su link state.

Protocolli di routing basati su distance vector

Questo tipo di approccio si basa sul fatto che ciascun router tiene
traccia della distanza e della direzione (vector ) di tutte le possibili
destinazioni nell'ambito dell'internetwork. Il modo in cui possono
essere calcolate le distanze presenti nelle tabelle di routing
dipendono da diverse caratteristiche della comunicazione come ad
esempio:

Ritardo. Si riferisce al tempo che viene impiegato affinché un


pacchetto venga inviato lungo una connessione. Questo
parametro può dipendere sia dalla velocità trasmissiva del
mezzo fisico utilizzato, sia dalla congestione presente sul
collegamento.
Banda. Maggiore è la banda assegnata ad un certo
collegamento, minore sarà il valore attribuito alla distanza.
Hop count. Questa variabile considera il numero di router che
un pacchetto deve attraversare per arrivare alla destinazione
desiderata.
Carico. Si riferisce all'utilizzo delle risorse hardware di una rete,
infatti se un router non è in grado di processare in maniera
corretta le informazioni a causa di sue limitate capacità di
calcolo, verrà scelta una rotta alternativa.

In prima istanza, il router stesso, rileverà quali sono le reti ad esso


direttamente connesse, assegnandovi una distanza pari a zero nella
propria routing table. Successivamente passerà la sua tabella ai
router vicini, cioè quelli ad esso connessi. Ciascuna tabella verrà poi
replicata a tutti i router adiacenti ad intervalli di 60 secondi. Da ciò
consegue che tale protocollo non permette di avere una conoscenza
della rete nella sua globalità, ma soltanto dei salti successivi (next
hop) che permetteranno di inoltrare i pacchetti verso la destinazione
finale.

Protocolli di routing basati su link state

I protocolli basati su link state hanno un approccio diverso rispetto ai


protocolli basati su distance vector per raccogliere le informazioni
necessarie ad effettuare il routing dinamico e per calcolare le rotte
da aggiungere nelle tabelle di routing. Una caratteristica importante
di questi protocolli è quella di mantenere una visione completa della
topologia di rete, cioè ciascun router è a conoscenza dell'esistenza
di qualsiasi altro router della rete e di come sono connessi fra loro, si
costruisce infatti una mappa della rete. I protocolli di tipo link state
sono infatti basati sul concetto di "mappa distribuita": tutti i nodi
posseggono una copia della mappa della rete, che viene
regolarmente aggiornata. Il protocollo link state mantiene un
database complesso per immagazzinare le informazioni sulla
topologia, le quali vengono usate per calcolare i percorsi verso le
possibili destinazioni. In questo database ciascun record
rappresenta un link nella rete. Con queste informazioni ogni nodo
può facilmente calcolare il percorso più breve da se stesso a tutti gli
altri nodi. Poiché tutti i nodi contengono lo stesso database ed
eseguono lo stesso algoritmo di route-generation, i percorsi sono
coerenti e non si verificano loops. Per effettuare ciò ciascun router
utilizza un algoritmo del tipo SPF (shortest path first); viene scelto
cioè il percorso più breve fra i possibili per una determinata
destinazione. Tale algoritmo è conosciuto anche come algoritmo di
Dijkstra. Questo permette a ciascun router di individuare le rotte
mediante la creazione di una struttura ad albero rappresentante la
rete ed avente come radice il router stesso.

OSPF
OSPF è l'acronimo di Open Shortest Path First. Questo protocollo di
routing si basa sulla tecnologia link state, a differenza di RIP che è
invece basato sull'algoritmo distance vector. In OSPF esistono un
database distribuito, una procedura di flooding e una definizione di
adjacency. OSPF appartiene alla classe IGP e pertanto opera
internamente a ciascun Autonomous System (AS). Il protocollo
scambia i messaggi LSA (Link State Advertisement), letteralmente
"annuncio sullo stato del link", con tutti quei router che appartengono
al medesimo AS, ed essendo di tipo link state, utilizza l'algoritmo
SPF per calcolare il percorso più breve verso ciascuna rotta. Inoltre
essendo Internet costituita da molti AS, talvolta abbastanza grandi e
non facilmente gestibili, OSPF offre la possibilità di suddividere gli
AS in Aree numerate, (denominate aree OSPF e identificate da un
numero di 32 bit detto area-id) ciascuna delle quali è formata da una
o più reti. Ciò comporta che la topologia ed i dettagli interni ad una
certa area, non siano visibili all'esterno di essa. Ciascun AS ha un
area backbone (spina dorsale) chiamata Area 0, la quale ha lo scopo
di far comunicare le diverse aree appartenenti al medesimo AS.
All'interno di ogni area, ciascun router, mantiene lo stesso database
realizzato con lo scambio di messaggi LSA, calcola il cammino
minimo da sé, verso ogni altro router appartenete alla medesima
area, incluso il router che è connesso alla backbone ("area-border
routers" ABR). Come descritto in figura ospf-definizioni ci deve
essere perlomeno un ABR in ciascun area, per connetterla al
backbone. Gli ABR mantengono numerosi database, uno per
ciascuna area alla quale appartengono ed ogni area include un set
di sottoreti IP. Oltre agli ABR, possiamo distinguere ancora 2
tipologie di router:
Internal router : sono i router che gestiscono il traffico
all'interno della stessa area
Autonomous System Boundary Router (ASBR) : sono
gateway per il traffico esterno e convertono i percorsi nel
dominio OSPF appresi da altri protocolli come BGP e EIGRP.

Possiamo inoltre suddividere i percorsi in tre tipologie:

Intra-area : in questo caso il router sorgente conosce il


percorso minimo verso il router di destinazione, grazie al
database che si è costruito;
Inter-Area : il percorso totale può essere suddiviso in tre stadi,
il primo verte alla ricerca di una route dalla sorgente verso la
backbone, il secondo dalla backbone verso l'area di
destinazione, e il terzo verso il router di destinazione all'interno
dell'area precedentemente individuata.
Inter-Autonomous system : in questo caso saranno
designati dei router di confine Border router, i quali permettono
di realizzare connessioni fra AS diversi, usando un protocollo di
tipo EGP.

Ciascuna area si comporta come una rete indipendente; il database


include solo lo stato dei link dell'area, il protocollo di flooding si ferma
ai confini dell'area ed i routers calcolano solo le rotte all'interno
dell'area. Il costo del protocollo di routing è cosi proporzionale al
formato dell'area e non a quello della rete. Grazie alla suddivisione
gerarchica è possibile sia ridurre il traffico di routing scambiato fra i
nodi della rete OSPF, sia ridurre le dimensioni delle tabelle
d’instradamento dei router all’interno di ogni singola area. Inoltre, si
riduce il tempo di convergenza del protocollo OSPF dato che i router
dovranno applicare l’algoritmo di Dijkstra su un grafo più piccolo e
quindi con un impiego di CPU minore e, di conseguenza, in minor
tempo. I router dell’ AS inviano periodicamente ai propri vicini (ogni
10 secondi nel caso di reti locali), o in corrispondenza a variazioni
topologiche nella rete, dei pacchetti di "Hello", che hanno il compito
di verificare quale, fra i router direttamente connessi, sia attivo. In
questa fase, ciascun router acquisirà una conoscenza dei propri
vicini e si costruirà una mappa "parziale" della rete contenente le
informazioni topologiche. I routers OSPF comunicano tramite il
protocollo OSPF, che viene direttamente incapsulato in IP (protocol
type = 89) ed è, a sua volta, composto da 3 sotto-protocolli:

Hello : viene utilizzato per verificare l'operatività' dei link. I


router degli AS che comunicano con il protocollo di routing
OSPF inviano periodicamente ai propri vicini (ogni 10 secondi
nel caso di reti locali), o in corrispondenza di variazioni
topologiche nella rete, dei pacchetti di "Hello", che hanno il
compito di verificare quale, fra i router direttamente connessi,
sia attivo. Infatti i pacchetti "Hello" vengono trasmessi solo tra
nodi vicini e mai propagati.
Exchange : quando due routers OSPF stabiliscono la
connessione su di un link punto-punto, devono sincronizzare i
propri database. La sincronizzazione iniziale avviene tramite il
protocollo "exchange" mentre di seguito sarà il protocollo
flooding ad occuparsi di mantenere sincronizzati i database. Il
protocollo Exchange è asimmetrico; il primo step del protocollo
consiste nel selezionare un "master" e uno "slave" e solo di
seguito i due routers si scambieranno la descrizione dei propri
database .
Flooding : viene utilizzato per diffondere (processo di
forwarding) a tutta la rete il nuovo stato di un link.
Questi aggiornamenti vengono inviati, attraverso il pacchetto di
"Link State Update", nel caso di un cambiamento di stato del
link allo scadere di un timer (normalmente 60 min).

IGP, EGP e OSPF

Come introdotto all'inizio del capitolo nel caso di intradomain routing,


i router interni devono conoscere solo i segmenti di rete appartenenti
allo stesso AS, non è quindi necessario che mantengano
informazioni su reti esterne; essi si limitano a mandare ai router di
confine i pacchetti destinati all'esterno. Questa organizzazione ha
dei notevoli vantaggi poiché riduce notevolmente le dimensioni delle
routing table in quanto le network esterne non sono presenti
direttamente in tale tabella se non attraverso il border router, il quale
penserà come raggiungere le destinazioni richieste. Inoltre un altro
beneficio: riguarda appunto il router stesso, che dovrà sostenere un
carico di lavoro inferiore, rendendo la rete più efficiente. Nel caso di
intradomain routing, il border router dovrà necessariamente tenete
traccia sia delle reti interne che appartengono al proprio AS, sia degli
altri border ruoter. In aggiunta sono anche responsabili della
"traduzione dei protocolli" nel caso in cui i vari AS usino protocolli di
routing diversi.

Definizioni per il routing di reti estese


ospf-definizioni
A causa delle diverse responsabilità che competono sia
all'intradomain routing, sia all'interdomain routing, possiamo
classificare i protocolli di routing in:

Interior Gateway Protocol (IGP) usato per intradomain routing.


All'interno di questa categoria esiste una ulteriore suddivisione
basata sulla logica matematica scelta:
Distance Vector: RIP, IGRP
Link state: OSPF
Hybrid: EIGRP
Exterior Gateway Protocol (EGP) usato per interdomain routing:
BGP.

Come funziona OSPF


Ora siamo pronti per affrontare il protocollo OSPF. Ricapitoliamo
quanto descritto finora:

Open Shortest Path First (OSPF) è un prototocollo di routing


dinamico incluso nella categoria dei protocolli IGP
(Interior Gateway Protocol) per il fatto di operare all’interno di
uno stesso AS.
OSPF ha la capacità di link-state (rilevamento dello stato di ogni
collegamento) ed usa l'algoritmo di Dijkstra per la ricerca del
percorso di routing ottimale.
OSPF è in grado di mantenere, gestire e
distribuire le informazioni di routing tra le reti anche se la
topologia della rete cambia in modo dinamico.
Utilizzo del protocollo IP (layer3) numero 89.

Area

Aree OSFP
aree
Il protocollo OSPF consente di raggruppare i router in insiemi
chiamati area . Ogni area esegue una copia separata dell'algoritmo
di routing, ciò significa che ogni area ha il proprio database di link-
state e l'albero del percorso più breve corrispondente. La struttura di
un'area è invisibile alle altre aree, questo isolamento della
conoscenza rende il protocollo più scalabile in quanto il calcolo della
tabella di routing richiede meno risorse della CPU e il traffico di
routing è ridotto. Tuttavia, le impostazioni multi-area creano ulteriore
complessità e per questo non è consigliabile separare le aree con
meno di 50 router anche se il numero massimo di router in un'area
dipende principalmente dalla potenza della CPU che si ha a
disposizione per il calcolo della tabella di routing. Ogni area è
identificata da un area-id univoco all'interno di un AS. In ogni AS
deve sempre essere presente un'area con area-id = 0.0.0.0 (il
backbone). Questa area speciale, il backbone letteralmente "spina
dorsale", contiene sempre tutti i router di confine dell'area ed è
responsabile della distribuzione delle informazioni di routing tra aree
non backbone. Considerato questo particolare ruolo l'area di
backbone deve essere contigua, cioè non devono esserci segmenti
sconnessi; tuttavia, non è necessario che i router di confine dell'area
siano fisicamente collegati alla dorsale: la connessione ad essa può
essere simulata utilizzando un collegamento virtuale. L'argomento
verrà trattato nella sezione virtual-link a pagina virtual-link attraverso
un laboratorio specifico. Quindi una rete con protocollo OSPF attivo
viene inizialmente identificata come Area 0. Nel caso di espansione
della rete, possono essere create altre aree adiacenti all’area 0, con
valori compresi nell'intervallo 0-4294967295. Un gruppo di aree
genera un sistema autonomo OSPF (OSPF Autonomous System).
Alcune sigle utilizzate dal protocollo:

IR (Internal Router) - sono i router incorporati all'interno di


un'area.
ABR (Area Border Router) - è un router che collega
un'area con un'altra area.
ASBR (Autonomous System Boundary Router) - è un
router situato sul confine di un AS (router più esterno dell'AS)
con il compito di essere il ponte tra i router degli AS di altre reti.
ASBR può anche essere un router membro del protocollo OSPF
che fa da bridge routing OSPF con altri protocolli di routing
come RIP, BGP ecc...

I router OSPF stabiliscono e mantengono un rapporto di relazione


con i vicini, tecnicamente detto adjacency (adiacenza o contiguità).
Dopo l’inizializzazione o a seguito di qualche cambiamento nel
routing, un router con OSPF attivo genera degli annunci, detti LSA
(Link State Advertisement ), contenenti informazioni topologiche
sulla rete. Tramite un processo detto di flooding, gli annunci vengono
scambiati con tutti i router della rete. Non appena un router riceve gli
LSA, crea un Link-State Database su cui applica l'algoritmo SPF
(Shortest Path First) di Dijkstra per creare un albero della topologia
di rete, o più semplicemente una mappa della rete. Ogni router crea
un Link-State Database e costruisce il proprio albero SPF a partire
dalle stesse informazioni link-state; tuttavia ognuno genera una
propria vista della topologia di rete, diversa da quella creata sugli
altri router. Inizialmente, ogni router identifica se stesso come radice
dell’albero; poi, a partire da questa root, l’algoritmo identifica il
percorso più breve per ogni destinazione, con il relativo costo.
Schematizzando, ciascun router con OSPF deve:

scoprire l'indirizzo di ogni router vicino;


misurare il costo necessario per raggiungere ciascun router
vicino;
inviare un messaggio a tutti i router diffondendo le informazioni
acquisite;
calcolare, in locale, il cammino minimo verso ogni altro router
utilizzando l’algoritmo SPF sviluppato da Dijkstra.

Scoperta dei vicini

Per conoscere l'intera topologia di una rete, ogni router invia un


pacchetto Hello su tutte le connessioni point-to-point disponibili e
riceve come risposta, dai router direttamente connessi, il loro
identificativo, detto Router ID. Il tempo che trascorre tra l'invio di due
pacchetti Hello è regolato dal campo Hello Interval, di default 10" su
reti Ethernet e sui link seriali punto-punto, 30" sulle reti Multiaccess
come Frame Relay. Il tempo massimo in cui un router attende l'Hello
Packet è regolato dal campo Dead Interval, di default 40" su reti
Ethernet e sui link seriali punto-punto, 120" sulle reti Multiaccess
come Frame Relay, quindi valori quadrupli rispetto all'Hello Interval.
Per calcolare il costo di connessione con i router vicini, è utilizzato
un pacchetto Echo con cui si misura il tempo necessario ad ottenere
risposta. Prima di raggiungere la “perfetta” conoscenza dei vicini,
detta neighbor adjacency , il router passa attraverso vari
cambiamenti di stato. Lo stato di full, e quindi la neighbor adjacency
tra due router, è possibile solo se si verificano tutte le condizioni
seguenti:

I router hanno ID diversi;


l'Hello Interval è lo stesso (di default 10" su reti Ethernet e sui
link seriali punto-punto, 30" sulle reti Multiaccess come Frame
Relay);
il Dead Interval è lo stesso (tempo massimo in secondi in cui si
attende l'Hello Packet, valore quadruplo rispetto all'Hello
Interval)
l'Area di appartenenza è la stessa (tipicamente Area 0);
la rete è la stessa (ossia i router comunicano a livello IP e
concordano sulla subnet mask)

Per approfondire la conoscenza del protocollo OSPF si vedano


anche i documenti:

Cisco OSPF Design Guide: http://bit.ly/2VC7kUn


Simulazione di una rete con Routing OSPF in Cisco Packet
Tracer: http://bit.ly/2VyUiHs

Elezione dei Designated Router

elezione-dr Nei collegamenti punto-punto, a parte le condizioni


elencate, non vi sono problemi per stabilire adiacenze, poiché per
definizione sul link possono essere presenti solo due router. Al
contrario, in una rete multiaccess, ovvero in un segmento di rete
dove sono collegati più router, un router può raggiungere lo stato di
full solo con un router designato (DR, Designated Router ) o un
router di backup designato (BDR, Backup Designated Router ). Lo
scopo di avere un router designato DR ed un router di backup BDR
è quello di ridurre il numero di aggiornamenti trasmessi, il flusso di
traffico non necessario ed il sovraccarico di elaborazione; i router
possono accettare aggiornamenti solo dal DR. In ogni segmento di
rete vi possono essere un solo DR ed un solo BDR. Tutti gli altri
router assumono il ruolo di DROther (altro dal DR) e devono avere
una connessione con il DR e il BDR. Quando un link non funziona, il
router con tale informazione invia l’aggiornamento al DR utilizzando
l’indirizzo multicast 224.0.0.6; a sua volta il DR è incaricato di
distribuire il cambiamento a tutti gli altri router OSPF, sempre in
multicast, ma all’indirizzo 224.0.0.5. Oltre a ridurre il numero di
aggiornamenti inviati attraverso la rete, questo processo assicura
che tutti i router ricevano le stesse informazioni nello stesso
momento e da una singola fonte. Il DR mantiene il suo ruolo sino ad
un eventuale fallimento: se il DR fallisce, il BDR prende il suo posto,
e verrà eletto un nuovo BDR. Il DR può fallire perché il processo
OSPF si arresta o riparte, o perché la sua interfaccia LAN diventa
“down”. All'interno della rete, il router con l'ID più alto viene eletto
DR, il secondo più alto viene eletto BDR. Il router ID non è altro che
un indirizzo IP, scelto in questo modo:

impostandolo tramite comando (router-ID command) sul router;


se nessun valore è impostato manualmente dall’amministratore,
viene utilizzato il più alto indirizzo IP configurato sulle interfacce
di loopback;
se nessuna interfaccia di loopback è configurata, viene utilizzato
il più alto indirizzo IP sulle interfacce fisiche attive.

{Esercizio} Si consideri la rete di figura dr .

Per ogni router si determi il rispettivo router id.


Per ogni sottorete si determinino i designated router (DR).
Esempio di calcolo dei router id e dei designated router.
dr
{Soluzione}
Router id
Router Router ID
R1 192.168.10.5
R2 209.165.201.1
R3 10.1.10.1
R4 192.168.10.3
R5 192.168.10.5
R6 209.165.201.2
Designated router
Network Router
10.1.10.0 R2
10.1.13.0 R4
10.1.16.0 Nessuno
10.1.19.0 R1
209.165.201.0 Nessuno
{Soluzione con Mikrotik} La soluzione del paragrafo precedente è
corretta in teoria e se si utilizzano router Cisco, nel caso di router
Mikrotik il risultato cambia:
/system identity set name=R1
/ip address add address=10.1.19.1/24 interface=ether1
/interface bridge add name=loopback
/ip address add address=192.168.10.5 interface=loopback
/ip address add address=10.1.10.4/24 interface=ether2
/ip address add address=10.1.16.2/30 interface=ether3
/routing ospf instance set redistribute-connected=as-type-1
numbers=0
/routing ospf network add network=10.1.10.0/24 area=backbone
/routing ospf network add network=10.1.16.0/30 area=backbone
[admin@R1] > /routing ospf neighbor print
0 instance=default router-id=10.1.13.2 address=10.1.16.1
interface=ether3
priority=1 dr-address=10.1.16.2 backup-dr-address=10.1.16.1
state="Full"
state-changes=5 ls-retransmits=0 ls-requests=0 db-summaries=0
adjacency=2m51s
1 instance=default router-id=10.1.10.3 address=10.1.10.3
interface=ether2
priority=1 dr-address=10.1.10.4 backup-dr-address=10.1.10.2
state="Full"
state-changes=4 ls-retransmits=0 ls-requests=0 db-summaries=0
adjacency=3m4s
2 instance=default router-id=10.1.10.1 address=10.1.10.1
interface=ether2
priority=1 dr-address=10.1.10.4 backup-dr-address=10.1.10.2
state="Full"
state-changes=4 ls-retransmits=0 ls-requests=0 db-summaries=0
adjacency=3m24s
3 instance=default router-id=10.1.10.2 address=10.1.10.2
interface=ether2
priority=1 dr-address=10.1.10.4 backup-dr-address=10.1.10.2
state="Full"
state-changes=4 ls-retransmits=0 ls-requests=0 db-summaries=0
adjacency=3m36s

/system identity set name=R2


/ip address add address=209.165.201.1/27 interface=ether1
/ip address add address=10.1.10.2/24 interface=ether2
/routing ospf instance set redistribute-connected=as-type-1
numbers=0
/routing ospf network add network=10.1.10.0/24 area=backbone
/routing ospf network add network=209.165.201.0/27
area=backbone

[admin@R2] /routing ospf> neighbor print


0 instance=default router-id=209.165.201.2
address=209.165.201.2
interface=ether1 priority=1 dr-address=209.165.201.2
backup-dr-address=209.165.201.1 state="Full" state-changes=6
ls-retransmits=0 ls-requests=0 db-summaries=0 adjacency=2m36s
1 instance=default router-id=10.1.10.3 address=10.1.10.3
interface=ether2
priority=1 dr-address=10.1.10.4 backup-dr-address=10.1.10.2
state="Full"
state-changes=5 ls-retransmits=0 ls-requests=0 db-summaries=0
adjacency=4m53s
2 instance=default router-id=10.1.10.1 address=10.1.10.1
interface=ether2
priority=1 dr-address=10.1.10.4 backup-dr-address=10.1.10.2
state="Full"
state-changes=4 ls-retransmits=0 ls-requests=0 db-summaries=0
adjacency=5m13s
3 instance=default router-id=10.1.10.4 address=10.1.10.4
interface=ether2
priority=1 dr-address=10.1.10.4 backup-dr-address=10.1.10.2
state="Full"
state-changes=6 ls-retransmits=0 ls-requests=0 db-summaries=0
adjacency=5m26s

/system identity set name=R3


/ip address add address=10.1.10.1/24 interface=ether1
/routing ospf instance set redistribute-connected=as-type-1
numbers=0
/routing ospf network add network=10.1.10.0/24 area=backbone

[admin@R3] > /routing ospf neighbor print


0 instance=default router-id=10.1.10.3 address=10.1.10.3
interface=ether1
priority=1 dr-address=10.1.10.4 backup-dr-address=10.1.10.2
state="2-Way"
state-changes=2 ls-retransmits=0 ls-requests=0 db-summaries=0
1 instance=default router-id=10.1.10.2 address=10.1.10.2
interface=ether1
priority=1 dr-address=10.1.10.4 backup-dr-address=10.1.10.2
state="Full"
state-changes=6 ls-retransmits=0 ls-requests=0 db-summaries=0
adjacency=5m32s
2 instance=default router-id=10.1.10.4 address=10.1.10.4
interface=ether1
priority=1 dr-address=10.1.10.4 backup-dr-address=10.1.10.2
state="Full"
state-changes=6 ls-retransmits=0 ls-requests=0 db-summaries=0
adjacency=5m32s

/system identity set name=R4


/ip address add address=10.1.10.3/24 interface=ether1
/ip address add address=10.1.13.1/24 interface=ether2
/interface bridge add name=loopback
/ip address add address=192.168.10.1 interface=loopback
/routing ospf instance set redistribute-connected=as-type-1
numbers=0
/routing ospf network add network=10.1.10.0/24 area=backbone
/routing ospf network add network=10.1.16.0/30 area=backbone

[admin@R4] > /routing ospf neighbor print


0 instance=default router-id=10.1.10.1 address=10.1.10.1
interface=ether1
priority=1 dr-address=10.1.10.4 backup-dr-address=10.1.10.2
state="2-Way"
state-changes=2 ls-retransmits=0 ls-requests=0 db-summaries=0
1 instance=default router-id=10.1.10.2 address=10.1.10.2
interface=ether1
priority=1 dr-address=10.1.10.4 backup-dr-address=10.1.10.2
state="Full"
state-changes=5 ls-retransmits=0 ls-requests=0 db-summaries=0
adjacency=5m32s
2 instance=default router-id=10.1.10.4 address=10.1.10.4
interface=ether1
priority=1 dr-address=10.1.10.4 backup-dr-address=10.1.10.2
state="Full"
state-changes=6 ls-retransmits=0 ls-requests=0 db-summaries=0
adjacency=5m32s

/system identity set name=R5


/ip address add address=10.1.16.1/30 interface=ether1
/ip address add address=10.1.13.2/24 interface=ether2
/interface bridge add name=loopback
/ip address add address=192.168.10.1 interface=loopback
/routing ospf instance set redistribute-connected=as-type-1
numbers=0
/routing ospf network add network=10.1.13.0/24 area=backbone
/routing ospf network add network=10.1.16.0/30 area=backbone
[admin@R5] > /routing ospf neighbor print
0 instance=default router-id=10.1.10.4 address=10.1.16.2
interface=ether1
priority=1 dr-address=10.1.16.2 backup-dr-address=10.1.16.1
state="Full"
state-changes=5 ls-retransmits=0 ls-requests=0 db-summaries=0
adjacency=5m33s

/system identity set name=R6


/ip address add address=209.165.201.2/27 interface=ether1
/routing ospf instance set redistribute-connected=as-type-1
numbers=0
/routing ospf network add network=209.165.201.0/27
area=backbone

[admin@R6] /routing ospf neighbor> print


0 instance=default router-id=10.1.10.2 address=209.165.201.1
interface=ether1
priority=1 dr-address=209.165.201.2 backup-dr-
address=209.165.201.1
state="Full" state-changes=4 ls-retransmits=0 ls-requests=0
db-summaries=0
adjacency=3m39s

Metrica

OSPF calcola il costo della metrica basandosi sulla larghezza di


banda e la velocità di un collegamento specifico. L'equazione
utilizzata per calcolare il costo di un collegamento OSPF è: Costo =
100.000.000 / larghezza di banda del link in bps I risultati di questa
equazione, applicata ad alcuni tipi di collegamento, sono mostrati
nella tabella table:metrica .
Larghezza di banda del link in Cost
Tipo di interfaccia
bps o
Fast ethernet e
100.000.000 1
oltre
Ethernet 10.000.000 10
E1 2.048.000 48
Metrica
table:metrica

OSPF su RouterOS
In questa e nelle sezioni successive si declineranno i concetti finora
esposti relativi ad OSPF secondo la terminologia e la logica di
RouterOS. La configurazione generale di OSPF si trova nella voce
Routing > OSPF > Instance e mette a disposizione i seguenti
parametri (si veda la figura istanza ):

router-id: (Default: 0.0.0.0) l'ID del router OSPF. Se non


specificato, OSPF utilizza l'indirizzo IP più basso configurato su
un'interfaccia attiva.
Redistribute Default Route: distribuisci la rotta predefinita.
Questa opzione è utilizzata o attivata solo sul router ASBR
Redistribute Connected Routes: ridistribuire i percorsi connessi,
ovvero percorsi verso reti direttamente raggiungibili.
Redistribute Static Routes: ridistribuire le rotte statiche.
Redistribute RIP Routes: ridistribuire le rotte derivanti da RIP.
Redistribute BGP Routes: ridistribuire le rotte derivanti da BGP.

Sulla redistribuzione delle rotte si veda anche il paragrafo


redistribute-type a pagina redistribute-type .
Parametri dell'istanza OSPF.
istanza
Il passaggio successivo, dopo aver impostato i parametri dell'istanza
OSPF, è quello definire eventuali aree indicando per ognuna un
identificativo denominato area-id. Per l'aggiunta di un'area si utilizza
la voce Routing > OSPF > Areas (figura add-area ). L'area 0 o
area di backbone è l'area in cui uno o più ABR sono riuniti per
scambiare informazioni di routing che provengono da altre aree (vedi
figura ospf-definizioni). Ogni Area non backbone deve essere
collegata direttamente con l'area di backbone. L'area di backbone è
anche un'area di transito per il traffico in uscita o in entrata negli AS.
Un'area che non è direttamente collegata all'area di backbone può
essere collegata all'area di backbone utilizzando Virtual Link. Le reti
che compongono un'area vengono dichiarate usando la voce
Routing > OSPF > Network (figura add-network ). OSPF sarà
abilitato su tutte le interfacce che hanno almeno un indirizzo che
rientra in questo intervallo. Si noti che per questo controllo si indica
la sottorete mentre per le interfacce point-to-point si indica l'indirizzo
dell'endpoint remoto.
Impostazioni iniziali
Aggiunta di un'area.

add-area
Aggiunta di una rete connessa all'area.
add-network

Laboratorio

Per questo laboratorio sono necessari tre router e due pc.


Aree e network OSPF
Obiettivo di questo laboratorio è realizzare una semplice
configurazione OSPF divisa su tre aree.

OSPF - gestione delle aree


area-lab

1. Colleghiamo i router come in figura area-lab .


2. Configuriamo gli indirizzi ip sui due PC e sulle interfacce dei tre
router:
{R1}
/ip address add interface=ether1 address=192.168.1.1/24
/ip address add interface=ether2 address=12.12.12.1/24

{R2}
/ip address add interface=ether1 address=12.12.12.2/24
/ip address add interface=ether2 address=23.23.23.2/24

{R3}
/ip address add interface=ether2 address=23.23.23.3/24
/ip address add interface=ether1 address=192.168.3.1/24

3. Controlliamo gli indirizzi dei PC facendo tre diversi ping:


Dal PC-1:
PC-1> ping 192.168.1.1
84 bytes from 192.168.1.1 icmp_seq=1 ttl=64 time=2.634 ms
84 bytes from 192.168.1.1 icmp_seq=2 ttl=64 time=0.732 ms
PC-1> ping 12.12.12.1
84 bytes from 12.12.12.1 icmp_seq=1 ttl=64 time=0.858 ms
84 bytes from 12.12.12.1 icmp_seq=2 ttl=64 time=0.786 ms
PC-1> ping 12.12.12.2
12.12.12.2 icmp_seq=1 timeout
12.12.12.2 icmp_seq=1 timeout

Dal PC-2:
PC-2> ping 192.168.3.1
84 bytes from 192.168.3.1 icmp_seq=1 ttl=64 time=2.903 ms
84 bytes from 192.168.3.1 icmp_seq=2 ttl=64 time=0.484 ms
PC-2> ping 23.23.23.3
84 bytes from 23.23.23.3 icmp_seq=1 ttl=64 time=0.569 ms
84 bytes from 23.23.23.3 icmp_seq=2 ttl=64 time=0.330 ms
PC-2> ping 23.23.23.2
23.23.23.2 icmp_seq=1 timeout
23.23.23.2 icmp_seq=2 timeout

4. Si noti come l'ultimo ping fallisce in quanto mancano le rotte


necessarie per il transito dei pacchetti.
5. Per questo controlliamo le tabelle di routing su R1, R2 ed R3:
R1:
[admin@R1] > /ip route print
Flags: X - disabled, A - active, D - dynamic, C - connect,
o - ospf
# DST-ADDRESS PREF-
SRC GATEWAY DISTANCE
0 ADC
12.12.12.0/24 12.12.12.1 ether2
0
1 ADC
192.168.1.0/24 192.168.1.1 ether1
0

R2:
[admin@R2] > /ip route print
Flags: X - disabled, A - active, D - dynamic, C - connect,
o - ospf
# DST-ADDRESS PREF-
SRC GATEWAY DISTANCE
0 ADC
12.12.12.0/24 12.12.12.2 ether1
0
1 ADC
23.23.23.0/24 23.23.23.2 ether2
0

R3:
[admin@R3] > /ip route print
Flags: X - disabled, A - active, D - dynamic, C - connect,
o - ospf
# DST-ADDRESS PREF-
SRC GATEWAY DISTANCE
0 ADC
23.23.22.0/24 23.23.23.3 ether2
0
1 ADC
192.168.2.0/24 192.168.3.1 ether1
0

6. Configuriamo le istanze ospf per ridistribuire le rotte connesse


su R1, R2 ed R3 (il comando seguente va dato su tutti i router) :
{R1, R2, R3}
/routing ospf instance set redistribute-connected=as-type-1
numbers=0

7. Per ogni router definiamo le aree ospf di cui il router fa parte;


l'area di backbone è già presente di default su tutti i router:
{R1}
/routing ospf area add name=area-1 area-id=0.0.0.1

{R2}
/routing ospf area add name=area-1 area-id=0.0.0.1
/routing ospf area add name=area-2 area-id=0.0.0.2

{R3}
/routing ospf area add name=area-2 area-id=0.0.0.2

8. Per ogni router aggiungiamo le reti su cui OSPF andrà ad


operare e le associamo alla rispettiva area:
{R1}
/routing ospf network add network=192.168.1.0/24 area=area-
1
/routing ospf network add network=12.12.12.0/24
area=backbone

{R2}
/routing ospf network add network=12.12.12.0/24
area=backbone
/routing ospf network add network=23.23.23.0/24
area=backbone

{R3}
/routing ospf network add network=192.168.3.0/24 area=area-
2
/routing ospf network add network=23.23.23.0/24
area=backbone

9. Si noti come sono cambiate le tabelle di routing:


R1:
[admin@R1] > /ip route print
Flags: X - disabled, A - active, D - dynamic, C - connect,
o - ospf
# DST-ADDRESS PREF-
SRC GATEWAY DISTANCE
0 ADC
12.12.12.0/24 12.12.12.1 ether2
0
1 ADo
23.23.23.0/24 12.12.12.2
110
2 ADC
192.168.1.0/24 192.168.1.1 ether1
0
3 ADo
192.168.3.0/24 12.12.12.2
110

R2:
[admin@R2] > /ip route print
Flags: X - disabled, A - active, D - dynamic, C - connect,
o - ospf
# DST-ADDRESS PREF-
SRC GATEWAY DISTANCE
0 ADC
12.12.12.0/24 12.12.12.2 ether1
0
1 ADC
23.23.23.0/24 23.23.23.2 ether2
0
2 ADo
192.168.1.0/24 12.12.12.1
110
3 ADo
192.168.3.0/24 23.23.23.3
110

R3:
[admin@R3] > /ip route print
Flags: X - disabled, A - active, D - dynamic, C - connect,
o - ospf
# DST-ADDRESS PREF-
SRC GATEWAY DISTANCE
0 ADo
12.12.12.0/24 23.23.23.2
110
1 ADC
23.23.23.0/24 23.23.23.3 ether2
0
2 ADo
192.168.1.0/24 23.23.23.2
110
3 ADC
192.168.3.0/24 192.168.3.1 ether1
0

10. A conferma del funzionamento della nostra rete possiamo


provare i due ping che prima fallivano oppure il ping tra i due
PC:

PC-1> ping 12.12.12.2


84 bytes from 12.12.12.2 icmp_seq=1 ttl=63 time=6.154 ms
84 bytes from 12.12.12.2 icmp_seq=2 ttl=63 time=1.477 ms
PC-1> ping 192.168.3.2
84 bytes from 192.168.3.2 icmp_seq=1 ttl=61 time=5.643 ms
84 bytes from 192.168.3.2 icmp_seq=2 ttl=61 time=1.409 ms

Come riepilogo riportiamo le configurazioni finali dei router. {R1 -


configurazione finale.}
/system identity set name=R1
/ip address
add address=192.168.1.1/24 interface=ether1
add address=12.12.12.1/24 interface=ether2
/routing ospf
add area area-id=1.1.1.1 name=area-1
/routing ospf instance
set redistribute-connected=as-type-1 numbers=0
/routing ospf network
add area=area-1 network=192.168.1.0/24
add area=backbone network=12.12.12.0/24

{R2 - configurazione finale.}


/system identity set name=R2
/ip address
add address=12.12.12.2/24 interface=ether1
add address=23.23.23.2/24 interface=ether2
/routing ospf area
add area-id=1.1.1.1 name=area-1
add area-id=2.2.2.2 name=area-2
/routing ospf instance
set redistribute-connected=as-type-1 numbers=0
/routing ospf network
add area=backbone network=12.12.12.0/24
add area=backbone network=23.23.23.0/24

{R3 - configurazione finale.}


/system identity set name=R3
/ip address
add address=23.23.23.3/24 interface=ether2
add address=192.168.3.1/24 interface=ether1
/routing ospf area
add area-id=2.2.2.2 name=area-2
/routing ospf instance
set redistribute-connected=as-type-1 numbers=0
/routing ospf network
add area=backbone network=23.23.23.0/24
add area=area-2 network=192.168.3.0/24

Interfaccia di loopback

loopback Come abbiamo analizzato precedentemente se il router-id


è 0.0.0.0 allora il router utilizzerà uno degli indirizzi IP del router
come router-id. Una buona pratica è di impostare una interfaccia di
rete virtuale loopback ed utilizzare tale indirizzo ip come router-id;
infatti se il router-id OSPF vive su un'interfaccia fisica e questa viene
scollegata allora questo IP non è più annunciato dal protocollo
OSPF. Per creare una interfaccia di loopback in RouterOS si
procede creando un bridge con nessuna porta associata e poi si
assegna l'indirizzo IP al bridge. Ad esempio facendo riferimento al
router R1 della figura area-lab si può procedere in questo modo:
{R1}
/interface bridge add name=loopback
/ip address add address=1.1.1.1 interface=loopback
/routing ospf instance set 0 router-id=1.1.1.1

Virtual link

virtual-link Come indicato nel documento RFC 2338 che descrive il


protocollo OSPF, l'area di backbone deve essere contigua con tutte
le aree. Tuttavia, può essere necessario definire le aree in modo tale
che il backbone non sia più contiguo. In questo caso,
l'amministratore di sistema deve ripristinare la connettività del
backbone configurando dei collegamenti virtuali. Il collegamento
virtuale può essere configurato tra due router attraverso un'area
comune denominata area di transito, uno dei quali deve essere
connesso con il backbone. I collegamenti virtuali appartengono alla
backbone e il protocollo tratta due router collegati da un
collegamento virtuale come se fossero collegati da una rete point-to-
point non numerata. Va ricordato che il collegamento virtuale deve
essere impostato su entrambi i router.

Laboratorio

lab-virtual-link
Per questo laboratorio sono necessari tre router e due pc.
Virtual link tra aree
Obiettivo di questo laboratorio è collegare attraverso un virtual link
aree non adiacenti all'area di backbone.

OSPF - Virtual link


area-virtual-link

1. Colleghiamo i router come in figura area-virtual-link e


come consueto configuriamo gli indirizzi ip sui due PC e sulle
interfacce dei tre router.
2. Durante la configurazione aggiungiamo per ogni router anche
l'interfaccia di loopback.
3. Come per il laboratorio precedente attiviamo l'istanza OSPF,
definiamo le aree e le reti associate .
{R1 - configurazione iniziale.}

/system identity set name=R1


/interface bridge add name=loopback
/ip address
add address=192.168.1.1/24 interface=ether1
network=192.168.1.0
add address=12.12.12.1/24 interface=ether2
network=12.12.12.0
add address=1.1.1.1 interface=loopback network=1.1.1.1
/routing ospf area add area-id=1.1.1.1 name=area-1
/routing ospf instance
set numbers=0 redistribute-connected=as-type-1 router-
id=1.1.1.1
/routing ospf network
add area=area-1 network=192.168.1.0/24
add area=backbone network=12.12.12.0/24

{R2 - configurazione iniziale.}


/system identity set name=R2
/interface bridge add name=loopback
/ip address
add address=12.12.12.2/24 interface=ether1
network=12.12.12.0
add address=23.23.23.2/24 interface=ether2
network=23.23.23.0
add address=2.2.2.2 interface=loopback network=2.2.2.2
/routing ospf area
add area-id=1.1.1.1 name=area-1
add area-id=2.2.2.2 name=area-2
/routing ospf instance
set numbers=0 redistribute-connected=as-type-1 router-
id=2.2.2.2
/routing ospf network
add area=backbone network=12.12.12.0/24
add area=area-2 network=23.23.23.0/24

{R3 - configurazione iniziale.}


/system identity set name=R3
/interface bridge add name=loopback
/ip address
add address=23.23.23.3/24 interface=ether2
network=23.23.23.0
add address=192.168.3.1/24 interface=ether1
network=192.168.3.0
add address=3.3.3.3 interface=loopback network=3.3.3.3
/routing ospf area
add area-id=2.2.2.2 name=area-2
add area-id=3.3.3.3 name=area-3
/routing ospf instance
set numbers=0 redistribute-connected=as-type-1 router-
id=3.3.3.3
/routing ospf network
add area=area-2 network=23.23.23.0/24
add area=area-3 network=192.168.3.0/24

4. Come si può notare, sul router R2, OSPF non ha raccolto le


rotte dell'area area-3 in quanto non connessa con l'area di
backbone:

[admin@R2] > /ip route print


Flags: X - disabled, A - active, D - dynamic,
C - connect, S - static, r - rip, b - bgp, o - ospf, m -
mme,
B - blackhole, U - unreachable, P - prohibit
# DST-ADDRESS PREF-
SRC GATEWAY DISTANCE
0 ADo
1.1.1.1/32 12.12.12.1
110
1 ADC
2.2.2.2/32 2.2.2.2 loopback
0
2 ADC
12.12.12.0/24 12.12.12.2 ether1
0
3 ADC
23.23.23.0/24 23.23.23.2 ether2
0
4 ADo
192.168.1.0/24 12.12.12.1
110

5. Creiamo un virtual link come in figura area-virtual-link-add :


OSPF - Virtual link
area-virtual-link-add
6. Ricontrolliamo le rotte presenti sul router R2:

[admin@R2] /routing ospf> /ip route print


Flags: X - disabled, A - active, D - dynamic,
C - connect, S - static, r - rip, b - bgp, o - ospf, m -
mme,
B - blackhole, U - unreachable, P - prohibit
# DST-ADDRESS PREF-
SRC GATEWAY DISTANCE
0 ADo
1.1.1.1/32 12.12.12.1
110
1 ADC
2.2.2.2/32 2.2.2.2 loopback
0
2 ADC
12.12.12.0/24 12.12.12.2 ether1
0
3 ADC
23.23.23.0/24 23.23.23.2 ether2
0
4 ADo
192.168.1.0/24 12.12.12.1
110
5 ADo
192.168.3.0/24 23.23.23.3
110
7. Come si può notare ora l'area-3 è connessa e il backbone sta
ricevendo correttamente le rotte dall'area.

Per altri interessanti esempi sulle funzionalità base di OSPF si veda


il link http://bit.ly/2VIISRA .

DR e BDR

Come introdotto nella sezione elezione-dr in ogni area verranno


scelti automaticamente un Designated Router (DR) e un Backup
Designated Router (BDR) con lo scopo di raccogliere e divulgare gli
LSA riducendo così il traffico e i tempi di elaborazione. Inoltre il BDR,
sostituirà DR se si verifica un errore. Come si vede in figura dr-bdr-
routeros in RouterOS la scheda Routing > OSPF > Interfaces
fornisce l'informazione su quale siano i DR e i BDR.

DR e BDR in RouterOS
dr-bdr-routeros

Neighbors State

Usando il menù Routing > OSPF > Neighbors si possono


visualizzare gli stati dei router vicini (figura neighbors-state ).
Neighbors State
neighbors-state
Gli stati possibili sono:

Down : nessun pacchetto Hello è stato ricevuto dal vicino.


Attempt : si applica solo alle zone NBMA. Lo stato indica che
nessuna informazione recente è stata ricevuta dal vicino.
Init : pacchetto Hello ricevuto dal vicino ma la comunicazione
bidirezionale non è stabilita (il suo Router ID non è elencato nel
pacchetto Hello).
2-way : è stata stabilita una comunicazione bidirezionale. Le
elezioni DR e BDR si verificano durante questo stato, i router
creano le adiacenze basate sul fatto che il router sia DR o BDR,
il collegamento sia point-to-point o un virtual link.
ExStart : i router tentano di stabilire il numero di sequenza
iniziale utilizzato per lo scambio di informazioni sui pacchetti. Il
router con ID superiore diventa il master e avvia lo scambio.
Exchange : i router scambiano i pacchetti di descrizione del
database.
Loading : in questo stato vengono scambiate le informazioni
sullo stato del collegamento effettivo. I pacchetti di richiesta link-
state vengono inviati ai vicini per richiedere eventuali nuovi LSA
trovati durante lo stato di Exchange.
Full : l'adiacenza è completa, i router vicini sono
completamente adiacenti. Le informazioni LSA sono
sincronizzate tra router adiacenti. I router raggiungono lo stato
completo solo con DR e BDR ad eccezione dei collegamenti
point-to-point .

Link State Advertisement

Nei protocolli di tipo link state i pacchetti inviati da un router e che,


ricevuti dai vari router della rete, permettono la costruzione della
mappa della rete, sono detti Link State Packet (LSP): pacchetto dello
stato dei collegamenti. Ogni LSP può contenere più Link State
Advertisement (LSA), messaggio sullo stato dei collegamenti, che
diffondono informazioni sullo stato dei link come i tradizionali LSP
ma non sono pacchetti. Gli LSA vengono generati da ciascun router
dell'AS a seconda delle competenze ad esso assegnate. Ci sono
cinque tipi di LSA:

1. Type 1 - Router LSA : informazioni sui router adiacenti a chi


genera il LSA
2. Type 2 - Network LSA : generato dai designated router per
descrivere la LAN cui il designated è collegato
3. Type 3 - Summary LSA : generati dagli area border router
per comunicare la raggiungibilità delle altre aree ai router interni
4. Type 4 - AS boundary router LSA : generati dagli area
border router per annunciare la raggiungibilità di un AS
boundary router
5. Type 5 - AS external LSA : generati da un AS boundary
router per annunciare destinazioni esterne al dominio di routing.

Gli LSA sono propagati tramite un pacchetto Link State Update che
può contenere più di un annuncio, ognuno però propagato un solo
hop in avanti. Viceversa per garantire la affidabilità del processo di
propagazione è bene che gli acknowledgment siano ritrasmessi uno
alla volta (sebbene possano essere parimenti raggruppati) in un
pacchetto di tipo Link State Acknowledgement. Uno degli elementi
tipici del processo di propagazione è anche la Retrasmission List
che, in ogni router, tiene conto dei LSA ricevuti che ancora non
abbiano avuto acknowledgement. Ogni interfaccia avrà quindi una
determinata lista di ritrasmissione opportunamente settata tenendo
conto della velocità di tale interfaccia. Queste informazioni sono
visibili usando il menù Routing > OSPF > LSA (vedi figura lsa ).

Link State Advertisement


lsa
Per un approfondimento del tema si consulti il link
http://bit.ly/2VzOIo9 .

Tipi di reti

Se finora avete lavorato quasi esclusivamente con reti ethernet ci


vorrà un po' di tempo per capire i concetti delle reti non broadcast. I
protocolli di routing dinamico, in particolare OSPF, richiedono
familiarità con tutti i tipi di topologie L2. Questo parametro della
configurazione OSPF è disponibile in Routing > OSPF >
Instance . OSPF si rivolge a tre classi di rete (come elencato nella
sezione 1.2 della RFC 2328): point-to-point, broadcast e non
broadcast.

Point-to-Point
Questo è di gran lunga il tipo di rete più semplice ed il punto di
partenza più semplice per comprendere le altre topologie. Una rete
point-to-point è un collegamento tra esattamente due punti (o
router). Un pacchetto inviato da uno dei router avrà sempre
esattamente un destinatario sul collegamento locale.

Point-to-Point

Broadcast

I collegamenti point-to-point non si adattano bene a tutte le


situazioni, un modo molto più efficiente di connettere un gran
numero di dispositivi è implementare un segmento multiaccess;
ovvero, un segmento a cui è possibile accedere da più punti finali.
Un segmento Ethernet è un esempio di tale rete.

Broadcast
broadcast
Nelle reti Ethernet un singolo pacchetto trasmesso da un dispositivo
può essere moltiplicato dal mezzo (in questo caso un swith Ethernet)
in modo che ogni altro punto finale riceva una copia. Ciò è
vantaggioso non solo per il risparmio di larghezza di banda che ne
consegue ma anche perché questo facilità la scoperta automatica
dei vicini. Nell'esempio riportato in figura broadcast , R1 può
eseguire il multicast (una trasmissione destinata solo a determinati
destinatari) di un messaggio di Hello OSPF su tutto il segmento,
sapendo che tutti gli altri router OSPF collegati al segmento lo
riceveranno e risponderanno con il proprio messaggio multicast. Di
conseguenza, i vicini possono identificarsi rapidamente e formare le
adiacenze senza conoscere prima gli indirizzi. I router OSPF su un
segmento multiaccess eleggeranno un router designato (DR) e un
router designato di backup (BDR) con cui tutti i router non designati
formeranno un'adiacenza. Questo per garantire che il numero di
adiacenze mantenute non cresca troppo; un segmento contenente
dieci router richiederebbe 45 connessioni per formare una mesh, ma
solo 17 quando sono presenti un DR e un BDR.

Non-Broadcast

Sfortunatamente, non tutte le tecnologie multiaccess supportano


trasmissioni broadcast. Frame relay e ATM sono probabilmente gli
esempi più comuni di trasporto non broadcast, che richiedono la
configurazione di singoli circuiti virtuali permanenti (PVC) tra i punti
finali.

Non-Broadcast
non-broadcast
Si noti che nella topologia del frame relay visibile in figura non-
broadcast , R1 deve predisporre e trasmettere un singolo pacchetto
per ogni destinazione che desidera raggiungere. Oltre a essere
inefficiente per quanto riguarda la larghezza di banda, questa
limitazione richiede che il router conosca gli indirizzi dei suoi vicini
prima che possa comunicare con loro. OSPF può operare su una
rete non broadcast nelle due modalità multi-accesso non broadcast
(NBMA) o point-to-multipoint. Ciascuna di queste topologie affronta
l'assenza di capacità di trasmissione da una prospettiva diversa.
{Non-Broadcast Multi-Access (NBMA)} Un segmento NBMA emula
la funzione tipica di una rete broadcast. Ogni router sul segmento
deve essere configurato con l'indirizzo IP di ciascuno dei suoi vicini. I
pacchetti OSPF Hello vengono poi trasmessi singolarmente come
pacchetti unicast a ciascun vicino adiacente. Come in una vera rete
broadcast, un DR e BDR sono eletti per limitare il numero di
adiacenze formate. E' importante ricordare che in una rete NBMA è
necessario specificare i vicini manualmente (vedi figura add-nbma ).

Aggiungta di un vicino NBMA


add-nbma
{Point-to-Multipoint} Una configurazione point-to-multipoint cerca la
soluzione alla limitazione delle reti non broadcast cercando di
emulare la capacità di trasmissione di una rete broadcast infatti
cerca di organizzare i PVC in una raccolta di reti punto-punto. I
pacchetti Hello devono ancora essere replicati e trasmessi
singolarmente a ciascun vicino, ma l'approccio multipoint offre due
vantaggi distinti: non è necessaria la presenza di DR e di BDR ed i
collegamenti point-to-point emulati possono occupare una sottorete
comune. Va notato che tutti i router collegati a una rete non
broadcast devono essere configurati manualmente affinché
riconoscato tale sottorete comune.
{l c c c c}
Richiede Permette
Tempo
un più
Usa predefinit comando
di due host
DR o per
e nella
Tipo di interfaccia di Hello i neighbor
BDR? sottorete?
Broadcast Sì 10 No Sì
Point-to-point No 10 No No
Non-broadcast (NBMA) Sì 30 Sì Sì
Point-to-multipoint No 30 No Sì
Point-to-multipoint non
No 30 Sì Sì
broadcast
Loopback No - - No
Schema ripielogativo dei tipi di rete.

OSPF Redistribute Type

redistribute-type Quando OSPF esporta le informazioni di


instradamento da sistemi autonomi esterni (AS), include un costo o
external metric nella rotta. OSPF supporta due tipi di metriche
esterne: tipo 1 (type-1 oppure E1) e tipo 2 (type-2 oppure E2). La
differenza tra le due metriche è come OSPF calcola il costo del
percorso. Le metriche esterne di tipo 1 sono equivalenti alla metrica
link-state, in cui il costo è uguale alla somma dei costi interni più il
costo esterno. Ciò significa che le metriche esterne di tipo 1
includono il costo esterno per la destinazione e il costo per
raggiungere il router di confine AS. Le metriche esterne di tipo 2
utilizzano solo il costo esterno per la destinazione e ignorano il costo
per raggiungere il router di confine AS. Per impostazione predefinita,
OSPF utilizza la metrica esterna di tipo 2. Entrambe le metriche
esterne di tipo 1 e di tipo 2 possono essere presenti nell'AS allo
stesso tempo. In tal caso, le metriche esterne di tipo 1 hanno
sempre la precedenza. I percorsi esterni di tipo 1 sono sempre
preferiti rispetto ai percorsi esterni di tipo 2. Quando tutti i percorsi
sono percorsi esterni di tipo 2, i percorsi con la metrica di tipo 2 più
piccola annunciati sono sempre preferiti. Possiamo dire che le rotte
OSPF di tipo 1 sono progettate per riflettere il costo effettivo lungo il
percorso dal punto di ridistribuzione alla destinazione. In generale
(ad eccezione di alcuni casi molto speciali), le rotte di tipo 1 sono
preferite rispetto al tipo 2 che non riflettono direttamente il costo end-
to-end dal punto di ridistribuzione alla destinazione.

Laboratorio

type-1-2 Si parta dalla configurazione finale prodotta dal precedente


laboratorio a pagina lab-virtual-link . Nella prima fase si aggiungerà
una rotta statica sul router R1 e si configurerà la redistribuzione con
Type-1. Si avrà modo di notare come la metrica si propaga fino al
router R3. Successivamente si cambierà la metrica di distribuzione
con Type-2 per verificare il cambio di costo.
Per questo laboratorio sono necessari tre router e due pc.
Type-1 e Type-2
Obiettivo di questo laboratorio è capire l'influenza del tipo di
redistribuzione nel calcolo finale della metrica.
OSPF - Virtual link
area-virtual-link

1. Colleghiamo i router come in figura area-virtual-link e


riprendiamo la configurazione lasciata alla fine del laboratorio
precedente.
2. Creiamo sul router R1 una rotta statica:
{R1}
/ip route add dst-address=10.10.10.0/24 gateway=192.168.1.2

3. Si imposti l'istanza OSPF del router R1 per ridistribuire la rotta


statica con metrica Type-1:
{R1}
/routing ospf instance set redistribute-static=as-type-1
numbers=0

4. Sul router R3 si veda la metrica della rotta propagata (Routing


> OSPF > Routes ):

Type-1
type-1
5. Si imposti l'istanza OSPF del router R1 per ridistribuire la rotta
statica con metrica Type-2:
{R1}
/routing ospf instance set redistribute-static=as-type-2
numbers=0
6. Sul router R3 si veda la metrica della rotta propagata (Routing
> OSPF > Routes ):

Type-2
type-2
7. Si noti il cambio del costo associato alla rotta.

Tipi di aree

Una rete OSPF è divisa in aree. Esse sono gruppi logici non
sovrapposti di router le cui informazioni possono essere riassunte
rispetto al resto della rete. Sono definite diversi tipi di aree "speciali":

Backbone - Area 0 (default 0.0.0.0) : Responsabile della


distribuzione delle informazioni di routing tra aree non
backbone. Tutte le altre aree devono essere collegate all'area 0.
Area standard : È una sottozona dell'Area 0. Quest'area
accetta l'LSA intraarea e l'LSA interarea di ogni ABR collegato
all'area 0.
Area stub : Questa zona non accetta LSA da percorsi esterni
sia che si tratti di un'altra area attraverso ABR o ASBR.
Area not-so-stubby (NSSA) : Stub Area che ha un
percorso esterno che viene assegnato da un'altra area.

Area standard
Area standard
Vengono propagati i seguenti LSA:

1. Type 1 - Router LSA : informazioni sui router adiacenti a chi


genera il LSA
2. Type 2 - Network LSA : generato dai designated router per
descrivere la LAN cui il designated è collegato
3. Type 3 - Summary LSA : generati dagli area border router
per comunicare la raggiungibilità delle altre aree ai router interni
4. Type 4 - AS boundary router LSA : generati dagli area
border router per annunciare la raggiungibilità di un AS
boundary router
5. Type 5 - AS external LSA : generati da un AS boundary
router per annunciare destinazioni esterne al dominio di routing .

Area stub

Area stub
Per Stub Area si intendono quei tipi di area che non ricevono rotte
esterne. Le rotte esterne saranno poi definite e distribuite da un altro
protocollo di routing. Quindi, le stub area necessitano di relegare ad
una rotta di default il traffico di scamdio con le rotte esterne al
dominio di appartenenza. Vengono propagati i seguenti LSA:

1. Type 1 - Router LSA : informazioni sui router adiacenti a chi


genera il LSA
2. Type 2 - Network LSA : generato dai designated router per
descrivere la LAN cui il designated è collegato
3. Type 3 - Summary LSA : generati dagli area border router
per comunicare la raggiungibilità delle altre aree ai router interni

Area totally stub

Area totally stub


Una totally stubby area è simile ad una stub area, tuttavia quest'area
non permette rotte riassuntive oltre che le rotte esterne. L'unico
modo con cui il traffico esce dall'area è una rotta di default che è
l'unica di Tipo-3 LSA annunciata nell'area. Quando c'è solo una rotta
per uscire dall'area, devono essere effettuate meno decisioni di
routing dal processore delle rotte, con minore utilizzo di risorse di
sistema.
Questa è la versione Cisco della NSSA. Per maggiori dettagli si
veda il link http://bit.ly/2VucxxA .
Vengono propagati i seguenti LSA:

1. Type 1 - Router LSA : informazioni sui router adiacenti a chi


genera il LSA
2. Type 2 - Network LSA : generato dai designated router per
descrivere la LAN cui il designated è collegato

Area Not-So-Stubby
Area Not-So-Stubby
Identificata anche come NSSA, una not-so-stubby area è un tipo di
stub area che può importare rotte esterne di AS e mandarle al
backbone, ma non può ricevere tali rotte esterne di AS dal backbone
o da altre aree. Vengono propagati i seguenti LSA:

1. Type 1 - Router LSA : informazioni sui router adiacenti a chi


genera il LSA
2. Type 2 - Network LSA : generato dai designated router per
descrivere la LAN cui il designated è collegato
3. Type 4 - AS boundary router LSA : generati dagli area
border router per annunciare la raggiungibilità di un AS
boundary router
4. Type 5 - AS external LSA : generati da un AS boundary
router per annunciare destinazioni esterne al dominio di routing.
5. Type 7 – NSSA external link : è l'informazione data dal
ASBR di trovarsi su una NSSA

Interfaccie passive

Quando si utilizza OSPF, si verificheranno due cose: Tutte le


interfacce che hanno indirizzi IP dentro una network invieranno
annunci LSA. I pacchetti OSPF Hello vengono inviati su queste
interfacce. Nei grandi ISP e nelle reti aziendali, alcuni router a livello
di distribuzione dispongono spesso di un gran numero di interfacce,
ad esempio sul bordo della WAN. Una pratica comune su tali router
è quella di abilitare i processi di routing su un intervallo di rete
corrispondente a diverse interfacce. Mentre questa tecnica facilita la
configurazione del protocollo di routing, abilitare il routing
indiscriminatamente su più o tutte le interfacce può aumentare le
possibilità di inserimento di peer di routing non autorizzati. Inoltre, gli
scambi di protocolli di routing non necessari aumentano il
sovraccarico della CPU sul router. Per questo a volte non è
desiderabile inviare pacchetti Hello OSPF su determinate interfacce.
Questa funzionalità è ottenuta mettendo la specifica interfaccia in
modalità passiva (figura interface-passive ).

Interfaccia passiva
interface-passive

Costo

Tutte le interfacce OSPF hanno un costo, che è una metrica di


routing utilizzata nel calcolo dello stato di collegamento. I percorsi
con metriche totali inferiori sono preferiti a quelli con metriche di
percorso più elevate. Per impostazione predefinita, OSPF assegna
una metrica di costo predefinita di 1 a qualsiasi collegamento più
veloce di 100 Mbps. Ciò significa che tutte le interfacce più veloci di
100 Mbps hanno la stessa metrica di costo predefinita pari ad 1.
Avere la stessa metrica di default potrebbe non essere un problema
se tutte le interfacce sono in esecuzione alla stessa velocità ma se le
interfacce operano a velocità diverse, è possibile notare che il
traffico non viene instradato sull'interfaccia più veloce poiché OSPF
indirizza ugualmente i pacchetti attraverso le diverse interfacce. Ad
esempio, se il dispositivo di routing ha interfacce Fast Ethernet e
Gigabit Ethernet con OSPF, ciascuna di queste interfacce ha una
metrica di costo predefinita pari a 1. C'è un interessante thread nei
forum Mikrotik dove mediante uno script si suggerisce di impostare il
costo di ogni interfaccia in base alla velocità dell'interfaccia:
http://bit.ly/2VxVDOG .

Ridondanza

Quando si aggiunge un collegamento OSPF lo rileverà e verrà


aggiunto alle rotte a disposizione. Se è presente una rete con più
gateway sulla stessa interfaccia e con lo stesso costo allora sarà
usato il bilanciamento del carico. Se una delle interfacce ha un costo
più alto uno dei link sarà il principale mentre gli altri diventeranno link
di failover.

Problemi comuni di una installazione OSPF e


comparazioni
Chiudiamo il capitolo su OSFP suggerendo l'ottima presentazione di
Kevin Myers al MUM USA 2018 che pone l'accento sui problemi più
comuni in una installazione OSPF e le loro relative soluzioni:
http://bit.ly/2VAwOlh Inoltre per alcuni casi di studio su OSPF si veda
il link http://bit.ly/2Qq0v4J . In appendice dalla pagina cisco-routeros-
ospf sono presenti una serie di tabelle che confrontano comandi e
configurazioni tra l'implentazione OSPF di Cisco IOS e
l'implementazione di Mikrotik RouterOS.
Domande di riepilogo
domande-3

1. In una infrastruttura con OSPF le rotter esterne sono importate


come Type-2.
In questo caso la politica di routing è realizzata tenendo conto
della somma delle metriche esterne ed interne?
1. Sì
2. No
2. In un'area sono sempre presenti due designated router e
almeno un backup designated router?
1. Sì
2. No
3. L'area di backbone (area 0) è necessaria solo se ci sono
almeno due aree adiacenti.
1. Sì
2. No
4. In una rete basata sui protocolli di routing link-state ogni nodo
contiene lo stesso database?
1. Sì
2. No

Soluzioni

1. No. Solo le rotte Type-1 sono comprensive delle metriche


interne. Le metriche esterne di tipo 2 utilizzano solo il costo
esterno per la destinazione e ignorano il costo (metrica) per
raggiungere il router di confine AS.
Su questo si vedano le due figure a pagina type-1 che riassumo
il risultato del laboratorio type-1-2 .
2. No, solo un DR e un BDR.
3. No. L'area di backbone esiste sempre.
4. Sì. E' proprio questa caratteristica unita al fatto di eseguire lo
stesso algoritmo di routing generation che assicura che i
percorsi siano coerenti e non si verifichino loop .
BGP: Border Gateway Protocol
{«Dammi speranza in un tempo migliore \\ con gli occhi aperti ma
senza frontiere ...»} Pooh

Come funziona BGP


Border Gateway Protocol (BGP) è un protocollo di routing di tipo
EGP (si veda la classificazione del routing nella figura routing-
protocols a pagina routing-protocols ) usato per connettere tra loro
più router che appartengono a sistemi autonomi distinti. È quindi un
protocollo di routing inter-AS, nonostante possa essere utilizzato
anche tra router appartenenti allo stesso AS (nel qual caso è
indicato con il nome di iBGP, Interior Border Gateway Protocol), o tra
router connessi tramite un ulteriore AS che li separa (eBGP, External
Border Gateway Protocol). BGP è il protocollo di routing principale
che attualmente connette Internet in modo decentrato, non
dipendente da uno solo nodo. Questo protocollo scambia solo le
informazioni di routing, non mostra la topologia della rete ed è
utilizzato per scambiare informazioni di routing tra reti di grandi
dimensioni (AS) come descritto in figura bgp-network .

Una rete BGP.


bgp-network
La scelta del routing si basa sul prefisso più specifico e sulla più
breve distanza (percorso AS). RouterOS supporta BGPv4 così come
definito nella RFC 1771. Possiamo dire che il protocollo BGP è il
"linguaggio" con gli AS si parlato tra di loro scambiato le informazioni
di routing e rendendo tutte le destinazioni raggiungibili. Esso
funziona attraverso la gestione di una tabella di prefissi (reti IP), che
forniscono informazioni sulla raggiungibilità delle diverse reti tra più
sistemi autonomi. Si tratta di un protocollo a indicazione di percorso
(path vector) che non usa metriche di carattere tecnico (ad esempio
non considera le ampiezze di banda) ma prende le decisioni di
instradamento basandosi su specifiche politiche. La motivazione che
spinge un'organizzazione all'utilizzo del protocollo BGP per
scambiare le proprie rotte in internet è la necessità di avere una rete
multihomed. Per rete multihomed si intende una rete che acquista il
transito verso internet da più provider di livello superiore (o anche
più link con lo stesso provider) e che deve garantire la raggiungibilità
dall'esterno dei propri servizi, tramite un set di indirizzi IP pubblici.
Infatti, in una situazione standard senza l'uso del protocollo BGP,
ogni link verso internet sarà dotato della sua classe di indirizzamento
IP, non condivisibile con altri link (vedi figura multihomed-network-
wo-bgp ). Risulta evidente quindi che pubblicando un servizio, ad
esempio un server che ospita un sito web, sull'indirizzo IP
raggiungibile direttamente dallo specifico link, alla caduta del link
stesso quel servizio risulterà irraggiungibile dalle altre reti.
Una rete multihomed senza BGP.
multihomed-network-wo-bgp
Invece, utilizzando il protocollo BGP per propagare in internet la
propria classe di indirizzi IP, gli indirizzi stessi saranno raggiungibili
tramite qualsiasi link verso il quale siano state propagate le rotte
(vedi figura multihomed-network-w-bgp ).

Una rete multihomed con BGP.


multihomed-network-w-bgp
Nel protocollo BGP gli AS adiacenti, detti peer, stabiliscono delle
sessioni di scambio delle rotte tramite una appropriata
configurazione dei router. Le sessioni utilizzano il protocollo TCP per
lo scambio di informazioni. È importante notare che tutti i router
all'interno di un AS che partecipano all'instradamento via BGP
devono essere collegati secondo una topologia a maglie
completamente connesse (full-mesh); cioè ogni router deve essere
peer di tutti gli altri. La cosa pone problematiche relative alla
scabilità, per questo sono implementabili soluzioni quali route-
reflections e confederations. L'argomeno non verrà qui trattato, in
quanto necessario solo in AS di grandi dimensioni. Come detto
prima, BGP è un protocollo basato su path-vector, il che significa che
il miglior percorso per raggiungere una determinata destinazione si
basa principalmente sul numero di AS tra sorgente e destinazione.
Ad esempio, nella scelta tra i seguenti due percorsi, verrà scelto il
primo anche se con minore ampiezza di banda prepend:

AS100 → AS 200 → AS 300 → AS 400


AS100 → AS 105 → AS 106 → AS 107 → AS 400

E' tuttavia possibile utilizzare alcuni stratagemmi per determinare il


percorso preferito. Un esempio è il cosiddetto “AS prepending”, che
consiste sostanzialmente nell'iniettare nel percorso AS più volte il
proprio numero AS. Tornando ai percorsi di prima, se il link numero 2
ha maggior capienza trasmissiva, posso “forzare” il transito
attraverso di esso annunciando più volte il mio AS (400). Si noti
quindi che il link 1 è più lungo del 2, quindi verrà utilizzato come
seconda scelta.

AS100 → AS 200 → AS 300 → AS 400 → AS 400 → AS 400


AS100 → AS 105 → AS 106 → AS 107 → AS 400

Questo "trucco" verrà utilizzato nel laboratorio bgp-lab2 a pagina


bgp-lab2 . È importante notare che proprio il fatto che il protocollo
non badi ai canali trasimissivi imponga l'uso di canali quanto più
simili tra loro. Si aggiunge che il protocollo BGP è valido sia per il
routing IPv4 che per il routing IPv6.

Cosa si può fare con BGP

Si va dalla semplice rete multihomed verso due provider alle reti che
fanno peering con altri parter o reti di clienti, tramite un peering
privato o tramite un peering pubblico presso un IXP (Internet
Exchange Point) (es: MIX-IT). Ovviamente, proprio grazie alla
selezione dei path link vector, ogni cliente che deve raggiungere i
servizi erogati utilizzerà il percorso con lunghezza minore. Un
esempio:

il provider A fornisce servizi internet e acquista transito internet


da B e C;
il provider A acquisisce il cliente Z, che si collega ad internet
tramite D e ha bisogno di
tempi di latenza bassissimi verso il servizio di A. È evidente in
questo caso che un peering diretto con D accorcerebbe
notevolmente il percorso dei pacchetti tra A e Z.

Cosa non si può fare con BGP

Proprio per il fatto che il protocollo è link-vector, non si possono in


alcun modo considerare i media fisici su cui transiteranno i pacchetti.

Criticità e requisiti

Per propagare in internet le proprie rotte via BGP è necessario


essere Autonomous System riconosciuto (dal RIPE nel caso
europeo) e avere una propria classe di indirizzi IP pubblici.
L'allocazione minore acquistabile è di una /24, ovvero 256 indirizzi
IP, detta PI (Provider Indipendent) Tuttavia è molto difficile ottenere
l'allocazione di una classe di questo tipo, in quanto bisogna
rispondere a determinati requisiti difficili da completare. È molto più
facile ottenere allocazione di reti più grosse, come ad esempio una
/22 (4 reti /24), dette PA (Provider Allocatable). Questo perchè nei
vari router in internet si preferisce evitare di propagare route che
hanno prefisso maggiore o uguale di 24, in quanto
frammenterebbero troppo la tabella di routing dei vari router. È poi
estremamente facile ottenere l'allocazione di una classe /32 di
indirizzi IPv6 (che è lungo 128 bit: si avrebbero quindi un numero
enorme di sottoreti allocabili). Da notare che è possibile propagare
rotte Ipv6 solo se i transit provider supportano Ipv6 stesso.

BGP con Mikrotik RouterOS


Al MUM 2013 a Zagabria, Wardner Maia, ha tenuto un talk dal titolo
"BGP Filtering with RouterOS", le cui slide sono reperibili al link
http://bit.ly/2VpYf14 . Nella prima parte del suo intervento ha fatto
una valida introduzione al protocollo BGP utile per chi volesse
approfondire ulteriormente il protocollo. Nelle pagine che seguono
affronteremo attraverso i laboratori solo due semplici configurazioni
base.

Laboratorio

Per questo laboratorio sono necessari due router e due pc.


Semplice comunicazione BGP tra due AS.
Obiettivo di questo laboratorio è realizzare una semplice
configurazione in cui due router appartenenti a diversi AS
comunicano le rotte di loro conoscenza reciprocamente.

Semplice comunicazione BGP tra due AS.


bgp-lab1

1. Colleghiamo i router come in figura bgp-lab1 .


2. Configuriamo il router R1:

[admin@MikroTik] > /system identity set name=R1


[admin@R1] > /ip address add interface=ether1
address=192.168.1.1/29
[admin@R1] > ip dhcp-server setup
Select interface to run DHCP server on
dhcp server interface: ether1 Select network for DHCP
addresses dhcp address space: 192.168.1.0/29 Select gateway
for given network gateway for dhcp network: 192.168.1.1 Select
pool of ip addresses given out by DHCP server addresses to
give out: 192.168.1.2-192.168.1.6 Select DNS servers dns
servers: Select lease time lease time: 10m
3. Controlliamo che il PC-1 abbia ottenuto un indirizzo ip valido e
riesca a comunicare con R1:

PC-1> ping 192.168.1.1


84 bytes from 192.168.1.1 icmp_seq=1 ttl=64 time=2.637 ms
84 bytes from 192.168.1.1 icmp_seq=2 ttl=64 time=0.503 ms
84 bytes from 192.168.1.1 icmp_seq=3 ttl=64 time=0.418 ms
84 bytes from 192.168.1.1 icmp_seq=4 ttl=64 time=0.360 ms
84 bytes from 192.168.1.1 icmp_seq=5 ttl=64 time=0.401 ms

4. Procediamo anche con la configurazione di R2:

[admin@MikroTik] > /system identity set name=R2


[admin@R2] > /ip address add interface=ether1
address=192.168.2.1/29
[admin@R2] > ip dhcp-server setup
Select interface to run DHCP server on

dhcp server interface: ether1


Select network for DHCP addresses
dhcp address space: 192.168.2.0/29
Select gateway for given network
gateway for dhcp network: 192.168.2.1
Select pool of ip addresses given out by DHCP server
addresses to give out: 192.168.2.2-192.168.2.6
Select DNS servers
dns servers:
Select lease time
lease time: 10m

5. Anche in questo caso controlliamo la corretta assegnazione


dell'indirizzo ip a PC-2 e la comunicazione con R2:

PC-2> ping 192.168.2.1


84 bytes from 192.168.2.1 icmp_seq=1 ttl=64 time=2.416 ms
84 bytes from 192.168.2.1 icmp_seq=2 ttl=64 time=0.417 ms
84 bytes from 192.168.2.1 icmp_seq=3 ttl=64 time=2.128 ms
84 bytes from 192.168.2.1 icmp_seq=4 ttl=64 time=0.401 ms
84 bytes from 192.168.2.1 icmp_seq=5 ttl=64 time=0.354 ms

6. Configuriamo ora la connessione che permette ai due router di


comunicare tra di loro:

[admin@R1] > /ip address add interface=ether2


address=192.168.100.1/30
[admin@R2] > /ip address add interface=ether2
address=192.168.100.2/30

7. Sempre da R2 controlliamo l'accessibilità di R1:

[admin@R2] > /ping 192.168.100.1


SEQ HOST SIZE TTL TIME
STATUS
0 192.168.100.1 56 64 10ms
1 192.168.100.1 56 64 2ms
2 192.168.100.1 56 64 0ms
3 192.168.100.1 56 64 1ms
4 192.168.100.1 56 64 0ms
5 192.168.100.1 56 64 0ms
6 192.168.100.1 56 64 0ms
7 192.168.100.1 56 64 1ms
8 192.168.100.1 56 64 0ms

8. Ora abbiamo connesso tutta l'infrastruttura ma chiaramente PC-


1 non riesce a raggiungere la sottorete 192.168.2.0/30:

PC-1> ping 192.168.2.6


*192.168.1.1 (ICMP type:3, code:0, Destination network
unreachable)
*192.168.1.1 ( ICMP type:3, code:0, Destination network
unreachable)
*192.168.1.1 (ICMP type:3, code:0, Destination network
unreachable)
*192.168.1.1 (ICMP type:3, code:0, Destination network
unreachable)

9. Passiamo a configurare BGP su R1:

[admin@R1] > routing bgp instance set 0 router-id=1.1.1.1


as=111
[admin@R1] > routing bgp peer add remote-
address=192.168.100.2 \
remote-as=222

10. Esponiamo la rete conosciuta e verifichiamo la tabella di routing:

[admin@R1] > routing bgp network add network=192.168.1.0/29


[admin@R1] > ip route print
Flags: X - disabled, A - active, D - dynamic,
C - connect, S - static, r - rip, b - bgp, o - ospf, m -
mme,
B - blackhole, U - unreachable, P - prohibit
# DST-ADDRESS PREF-
SRC GATEWAY DISTANCE
0 ADC
192.168.1.0/29 192.168.1.1 ether1
0
1 ADC
192.168.100.0/30 192.168.100.1 ether2
0

11. Passiamo a configurare BGP su R1:

[admin@R2] > routing bgp instance set 0 router-id=2.2.2.2


as=222
[admin@R2] > routing bgp peer add remote-
address=192.168.100.1 \
remote-as=111
[admin@R2] > routing bgp network add network=192.168.2.0/29

12. Esponiamo la rete conosciuta e verifichiamo la tabella di routing:

[admin@R1] > ip route print interval=1s


Flags: X - disabled, A - active, D - dynamic,
C - connect, S - static, r - rip, b - bgp, o - ospf, m -
mme,
B - blackhole, U - unreachable, P - prohibit
# DST-ADDRESS PREF-
SRC GATEWAY DISTANCE
0 ADC
192.168.1.0/29 192.168.1.1 ether1
0
2 ADb
192.168.2.0/29 192.168.100.2
20
1 ADC
192.168.100.0/30 192.168.100.1 ether2
0

13. Come si può notare è stata trasferita attraverso BGP la rotta


conosciuta dall'AS111.
14. Similmente l'AS111 ha ricevuto le rotte conosciute ed esposte
dall'AS222:

[admin@R2] > ip route print


Flags: X - disabled, A - active, D - dynamic,
C - connect, S - static, r - rip, b - bgp, o - ospf, m -
mme,
B - blackhole, U - unreachable, P - prohibit
# DST-ADDRESS PREF-
SRC GATEWAY DISTANCE
0 ADb
192.168.1.0/29 192.168.100.1
20
1 ADC
192.168.2.0/29 192.168.2.1 ether1
0
2 ADC
192.168.100.0/30 192.168.100.2 ether2
0

15. Ora i router sono a conoscenza dell'intera infrastruttura e


il ping dal PC-1, che precedentemente aveva fallito al passo 8.,
ora raggiunge l'obiettivo:
PC-1> ping 192.168.2.6
84 bytes from 192.168.2.6 icmp_seq=1 ttl=62 time=6.653 ms
84 bytes from 192.168.2.6 icmp_seq=2 ttl=62 time=1.085 ms
84 bytes from 192.168.2.6 icmp_seq=3 ttl=62 time=0.947 ms
84 bytes from 192.168.2.6 icmp_seq=5 ttl=62 time=1.078 ms

Laboratorio

bgp-lab2
Per questo laboratorio sono necessari tre router e un pc.
Semplice infrastruttura BGP multihomed.
Obiettivo di questo laboratorio è realizzare questa
configurazione che può essere utilizzata per la condivisione del
carico tra ISP o un ISP come principale e altri ISP come link di
backup.

Semplice infrastruttura BGP multihomed.


bgp-lab2
Supponiamo che il registro Internet locale ci abbia due reti /24:
10.1.1.0/24 e 10.1.2.0/24 e il nostro AS sia 30. La prima rete
sarà stata utilizzata per le workstation della nostra rete
aziendale. Parte dell'altra rete sarà utilizzata anche per le
workstation e un'altra parte verrà riservata ai server. Allo stato
attuale la nostra azienda dispone di un solo server con indirizzo
10.1.2.130 L'obiettivo è annunciare le nostre reti assegnate ai
peer BGP e utilizzare solo un provider come collegamento
principale, il collegamento ISP2 è solo per il backup.
1. Colleghiamo i router come in figura bgp-lab2 .
2. Carichiamo nei router R1, R2 ed R3 la configurazione di
base priva dell'operatività BGP:
{R1}
/system identity set name=R1
/ip address
add address=192.168.1.1/24 interface=ether1
network=192.168.1.0
{R2}
/system identity set name=R2
/ip address
add address=192.168.2.1/24 interface=ether1
network=192.168.2.0

{R3}
/system identity set name=R3
/ip pool
add name=dhcp_pool0 ranges=10.1.1.2-10.1.1.254
add name=dhcp_pool1 ranges=10.1.2.2-10.1.2.126
add name=dhcp_pool2 ranges=10.1.2.130-10.1.2.254
/ip dhcp-server
add address-pool=dhcp_pool0 disabled=no
interface=ether3 name=dhcp1
add address-pool=dhcp_pool1 disabled=no
interface=ether4 name=dhcp2
add address-pool=dhcp_pool2 disabled=no
interface=ether5 name=dhcp3
/ip address
add address=192.168.1.2/24 interface=ether1
network=192.168.1.0
add address=192.168.2.2/24 interface=ether2
network=192.168.2.0
add address=10.1.1.1/24 interface=ether3
network=10.1.1.0
add address=10.1.2.1/25 interface=ether4
network=10.1.2.0
add address=10.1.2.129/25 interface=ether5
network=10.1.2.128
/ip dhcp-server network
add address=10.1.1.0/24 gateway=10.1.1.1
add address=10.1.2.0/25 gateway=10.1.2.1
add address=10.1.2.128/25 gateway=10.1.2.129

3. Passiamo a configurare BGP su R1:

[admin@R1] > routing bgp instance set 0 as=10


[admin@R1] > routing bgp peer add remote-
address=192.168.1.2 remote-as=30

4. Passiamo a configurare BGP su R2 :


[admin@R2] > routing bgp instance set 0 as=20
[admin@R2] > routing bgp peer add remote-
address=192.168.2.2 remote-as=30

5. Passiamo a configurare BGP su R3:

[admin@R3] > routing bgp instance set 0 as=30


[admin@R3] > routing bgp peer add remote-
address=192.168.1.1 \
remote-as=10 name=isp1
[admin@R3] > routing bgp peer add remote-
address=192.168.2.1 \
remote-as=20 name=isp2

6. Esponiamo le reti conosciute:

[admin@R3] > routing bgp network add


network=10.1.1.0/24 synchronize=no
[admin@R3] > routing bgp network add
network=10.1.2.0/24 synchronize=no

7. Verifichiamo la tabella di routing su R1 ed R2:

[admin@R1] > ip route print


Flags: X - disabled, A - active, D - dynamic,
C - connect, S - static, r - rip, b - bgp, o - ospf, m
- mme,
B - blackhole, U - unreachable, P - prohibit
# DST-ADDRESS PREF-
SRC GATEWAY DISTANCE
0 ADb
10.1.1.0/24 192.168.1.2
20
4 ADb
10.1.2.0/24 192.168.1.2
20
1 ADC
192.168.1.0/24 192.168.1.1 ether1
0
[admin@R2] > /ip route print
Flags: X - disabled, A - active, D - dynamic,
C - connect, S - static, r - rip, b - bgp, o - ospf, m
- mme,
B - blackhole, U - unreachable, P - prohibit
# DST-ADDRESS PREF-
SRC GATEWAY DISTANCE
0 ADb
10.1.1.0/24 192.168.2.2
20
4 ADb
10.1.2.0/24 192.168.2.2
20
1 ADC
192.168.2.0/24 192.168.2.1 ether1
0

8. Ora andremo ad agire sempre su router R3. Il passo


successivo è specificare quali catene di filtri di routing
verranno utilizzate, infatti vogliamo escludere tutte le rotte
non comprese nei nostri AS:

/routing bgp peer


set isp1 in-filter=isp1-in out-filter=isp1-out
set isp2 in-filter=isp2-in out-filter=isp2-out

in-filter è per i prefissi in ingresso (ricezione) mentre out-


filter è per i prefissi pubblicizzati.
9. Dopo che le catene sono state specificate, accettiamo le
reti e buttiamo tutto il resto perché non siamo fornitori di
transito.
Come noto, uno degli attributi BGP che influenzano la
migliore selezione del percorso è la lunghezza del percorso
AS, più breve è il percorso AS più preferito. Quindi
vogliamo che l'ISP2 sia solo di backup, useremo BGP per
aumentare la lunghezza del percorso AS per forzare il
traffico in entrata attraverso l'ISP1. Filtri in uscita verso
ISP1:
/routing filter
# Accettiamo le notre reti
add chain=isp1-out prefix=10.1.1.0/24 action=accept
add chain=isp1-out prefix=10.1.2.0/24 action=accept
# Buttiamo tutto il resto
add chain=isp1-out action=discard

Filtri in uscita verso ISP2 (si noti l'aumento del path come
descritto a pagina prepend ):
/routing filter
# Accettiamo le nostre reti e anteponiamo il percorso
AS tre volte
add chain=isp2-out prefix=10.1.1.0/24 action=accept
set-bgp-prepend=3
add chain=isp2-out prefix=10.1.2.0/24 action=accept
set-bgp-prepend=3
# Buttiamo tutto il resto
add chain=isp2-out action=discard

10. Inoltre, non abbiamo bisogno di rotte dagli ISP, perché la


rotta predefinita è utilizzare il traffico in uscita tramite ISP1
e lasciare ISP2 come backup:

/routing filter
add chain=isp1-in action=discard
add chain=isp2-in action=discard
/ip route
add gateway=192.168.1.1 check-gateway=ping
add gateway=192.168.2.1 distance=30 check-gateway=ping

Link utili

Per ultiori laboratori sul protocollo BGP si possono


consultare i seguenti link:
http://bit.ly/2QlkMbJ
http://bit.ly/2VlMEzY
http://bit.ly/2Ql9rIC
http://bit.ly/2Qlc50J
802.1q
vlan

{«Oh, when the saints go marching in \\ Oh, when the saints


go marching in \\ Lord, how I want to be in that number»}
Gospel tradizionale statunitense

IEEE 802.1Q è uno standard che permette a più reti virtuali


VLAN di condividere lo stesso collegamento fisico senza
perdita di informazioni tra un apparato e un altro. La
tecnologia della Virtual LAN permette di segmentare il
dominio di broadcast di una LAN, suddividendola in più reti
LAN Virtuali, isolate tra loro, ma che condividono la stessa
infrastruttura fisica. Ci sono due modi per realizzare una
Virtual LAN:
port tagged VLAN: lo switch assegna una VLAN a
delle porte;
IP/MAC tagged VLAN: lo switch associa una VLAN
ad un indirizzo IP/MAC.
Quest'ultimo metodo garantisce una maggiore sicurezza,
perchè si è certi dell'appartenenza di uno specifico host ad
una Virtual LAN; mentre nel primo metodo, semplicemente
cambiando interfaccia fisica, l'host è assegnato ad un'altra
VLAN. In questo capitolo analizzeremo le VLAN realizzate
con il metodo che etichetta le porte del dispositivo di
connessione (port tagged VLAN). Le VLAN possono essere
utili anche allo scopo di restringere l’accesso a delle risorse
senza bisogno di modificare la topologia fisica della rete. Le
VLAN operano al livello 2 (il Data Link Layer) dello Stack
ISO/OSI. Le VLAN si definiscono all'interno dello switch,
attraverso un nome e un ID (VID: VLAN Identificator),
quest'ultimo con range 0-4095. Per gestire più VLAN sulla
stessa struttura fisica, lo switch deve essere in grado di
svolgere funzioni di:
Ingress : capire la VLAN di provenienza del frame ;
Forwarding : capire la porta di destinazione del
frame, in base alla VLAN di destinazione;
Egress : trasmettere il frame in modo che la sua
appartenenza alla VLAN venga correttamente
interpretata da altri eventuali switch.
A questo punto è utile porre l'attenzione sui termini usati,
infatti diversi produttori di switch e di router usano termini
diversi per indicare la stessa tipologia di porte. Nella tabella
table:terms a pagina table:terms sono riportate le più
comuni corrispondenze. Nel contesto delle VLAN, il termine
trunk o core denota un collegamento della rete che
trasposta VLAN multiple, identificate tramite etichette (dette
tag ) inserite nei loro pacchetti. I trunk devono essere
collegati a porte che analizzino i tag, le tagged-port , di una
device abilitata alle VLAN: spesso si tratta collegamenti
switch-switch o switch-router.

Lo standard 802.1q
802.1q è il nome del protocollo di incapsulamento utilizzato
nel processo di trunking nelle reti Ethernet. Il protocollo
802.1q non segue la logica dell'incapsulamento ma viene
implementato aggiungendo 4 bytes (32 bit) nell'header
Ethernet (figura frame ).

Un pacchetto con campo 802.1q


frame
Nei 4 bytes aggiunti troviamo:
I primi 2 byte modificati riguardano il tag protocol
identifier (TPID) .
Questo contiene il tag EtherType che viene cambiato in
0x8100, numero che evidenzia il nuovo formato del
frame.
I successivi 2 byte riguardano il tag control
information (TCI) (detto anche VLAN Tag) così
suddiviso:
user_priority : Questo campo a 3 bit può essere
utilizzato per indicare un livello di priorità per il
frame.
L'utilizzo di questo campo è definito dallo standard
IEEE 802.1p.
CFI : Campo di 1 bit che indica se i MAC address
nel frame sono in forma canonica.
VID : campo di 12 bit che indica l'ID delle VLAN,
che possono così essere fino a 4096 (ossia
2^{12}).
Delle 4096 VLAN possibili, le VLAN 0, 1 e 4095
sono riservate.
L'802.1q introduce fra l'altro due nuovi protocolli:
GVRP: Generic VLAN Registration Protocol –
consente agli switch di negoziare dinamicamente quali
VLAN gestire su
un trunk;
MSTP: Multiple Spanning Tree Protocol –
evoluzione dello Spanning Tree Protocol
adattata al contesto 802.1q.

Tipi di porte

Le porte di uno switch possono essere di accesso, usate


per collegare gli host, o di trunk, usate per gli uplink tra
switch o tra switch e router. Il trunk è quindi un link che
permette il trasporto di frame appartenenti a VLAN diverse.
Bisogna qui evidenziare un concetto molto importante: le
trame girano in formato 802.1q solo sulle porte di trunk.
Quando vengono inoltrate agli host o dagli host sulle porte
di accesso, il tag VLAN viene eliminato e il formato della
trama ritorna ad essere quello dello standard Ethernet.
Riassumendo quanto fin qui esposto, in uno switch
troviamo due tipi di porte:
1. Porte Edge, (Terminologia Cisco: access; Terminologia
HP: untagged)
- i pacchetti che attraversano una porta edge (o
access) sono privi del tag VLAN. Infatti su queste sono
collegati PC e dispositivi che nulla sanno delle VLAN.
Queste sono le porte che inseriscono il tag VLAN al
traffico in ingresso sulla porta e tolgono il tag VLAN al
traffico in uscita, diretto verso gli host.
2. Porte Core (Terminologia Cisco: Trunk; Terminologia
HP: tagged)
- una porta core è in grado di ricevere pacchetti
"taggati", e su queste porte possono essere collegati
solo dispositivi in grado di interpretare i VLAN tag,
come switch, router e firewall compatibili con il
protocollo 802.1q. Sono le porte dove il traffico viaggia
con il tag VLAN, che quindi viene lasciato inalterato.
Edge Core
Cos
Termine generico Cisco HP
a fa
Access Untagge Inseriscono il tag
d VLAN (quindi
taggano) al traffico in
ingresso sulla porta e
tolgono il tag VLAN
al traffico in uscita
(diretto verso gli
host).
Sono le porte dove il
Trunk Tagged traffico viaggia con il
tag
VLAN, che quindi
viene lasciato
inalterato.
Confronto fra i termini VLAN usati dai vari produttori
table:terms

VLAN su RouterOS
vlan-simple Per comprendere come RouterOS gestisce le
VLAN si consideri lo schema di figura lab-vlan1 .

Il più semplice uso delle VLAN.


lab-vlan1
Sul router R1, la scheda di rete ether1 si comporta come un
collegamento (trunk) che trasporta le due vlan fino al router
R2. Per questo verranno create due nuove interfacce di tipo
vlan. Su ognuna di queste saranno attivi due dhcp server
che rilasciano gli indirizzi IP relativi ad ognuna delle tre
VLAN. Il router R2 si comporta come uno switch con VLAN:
prenderà le vlan attraverso l'interfaccia di trunk ether1 e le
smisterà alle interfacce ether2 per la vlan10 ed ether3 per
la vlan20. In RouterOS la gestione delle VLAN passa
attraverso i menù di gestione del bridge e delle interfacce.
Si noti che la configurazione del router R2 non contiene
nessun indirizzo IP: il router si comporterà come uno switch
operando solo a livello L2. Di seguito le configurazioni finali
dei due router: {R1}
/system identity set name=R1
#
# Definizione delle vlan e del link core (trunk)
#
/interface vlan
add interface=ether1 name=vlan10 vlan-id=10
add interface=ether1 name=vlan20 vlan-id=20
/ ip pool
add name=vlan10 ranges=10.10.10.100-10.10.10.200
add name=vlan20 ranges=10.20.20.100-10.20.20.200
/ip dhcp-server
add address-pool=vlan10 disabled=no interface=vlan10
name=vlan10
add address-pool=vlan20 disabled=no interface=vlan20
name=vlan20
/ip address
add address=10.10.10.1/24 interface=vlan10
network=10.10.10.0
add address=10.20.20.1/24 interface=vlan20
network=10.20.20.0
/ip dhcp-server network
add address=10.10.10.0/24 netmask=24
add address=10.20.20.0/24 netmask=24

{R2}
/system identity set name=R2
#
# Definizione della porta di core (trunk)
#
/interface vlan
add interface=ether1 name=vlan10 vlan-id=10
add interface=ether1 name=vlan20 vlan-id=20
#
# Definizione dei bridge per le porte edge
#
/interface bridge
add fast-forward=no name=bridgevlan10
add fast-forward=no name=bridgevlan20
#
# Estrazione delle vlan dai bridge
#
/interface bridge port
add bridge=bridgevlan10 interface=vlan10
add bridge=bridgevlan20 interface=vlan20
add bridge=bridgevlan20 interface=ether3
add bridge=bridgevlan10 interface=ether2

Laboratorio con trunk propagato tra switch

trunk-lab
Per questo laboratorio sono necessari tre router ed almeno
un pc.
VLAN
Obiettivo di questo laboratorio è l'apprendimento di come
propagare un trunk tra diversi switch.

VLAN - laboratorio con trunk propagato tra switch


lab-vlan3
L'infrastruttura di rete da configurare è quella di figura lab-
vlan3 . La particolarità del laboratorio è la propagazione del
trunk dal router R2 al router R3. Si veda in particolare la
configurazione del router R2 e l'utilizzo del bridge
bridgevlan1030 e delle sue porte. {R1}
/system identity set name=R1
/interface vlan
add interface=ether3 name=vlan10 vlan-id=10
add interface=ether3 name=vlan20 vlan-id=20
add interface=ether3 name=vlan30 vlan-id=30
/ip pool
add name=vlan10 ranges=10.10.10.100-10.10.10.200
add name=vlan20 ranges=10.20.20.100-10.20.20.200
add name=vlan30 ranges=10.30.30.100-10.30.30.200
/ip dhcp-server
add address-pool=vlan10 disabled=no interface=vlan10
name=vlan10
add address-pool=vlan20 disabled=no interface=vlan20
name=vlan20
add address-pool=vlan30 disabled=no interface=vlan30
name=vlan30
/ip address
add address=10.10.10.1/24 interface=vlan10
network=10.10.10.0
add address=10.20.20.1/24 interface=vlan20
network=10.20.20.0
add address=10.30.30.1/24 interface=vlan30
network=10.30.30.0
/ip dhcp-server network
add address=10.10.10.0/24 netmask=24
add address=10.20.20.0/24 netmask=24
add address=10.30.30.0/24 netmask=24

{R2}
/system identity set name=R2
/interface bridge
add fast-forward=no name=bridgevlan10
add fast-forward=no name=bridgevlan20
add name=bridgevlan1030
/interface vlan
add interface=bridgevlan1030 name=vlan10 vlan-id=10
add interface=bridgevlan1030 name=vlan20 vlan-id=20
add interface=bridgevlan1030 name=vlan30 vlan-id=30
/interface bridge port
add bridge=bridgevlan10 interface=vlan10
add bridge=bridgevlan20 interface=vlan20
add bridge=bridgevlan10 interface=ether1
add bridge=bridgevlan20 interface=ether2
add bridge=bridgevlan1030 interface=ether4
add bridge=bridgevlan1030 interface=ether3
/interface bridge vlan
add bridge=bridgevlan1030 tagged=ether3,ether4 vlan-
ids=10,30

{R3}
/system identity set name=R3
/interface bridge
add fast-forward=no name=bridgevlan10
add fast-forward=no name=bridgevlan30
/interface vlan
add interface=ether4 name=vlan10 vlan-id=10
add interface=ether4 name=vlan30 vlan-id=30
/interface bridge port
add bridge=bridgevlan10 interface=vlan10
add bridge=bridgevlan30 interface=vlan30
add bridge=bridgevlan10 interface=ether1
add bridge=bridgevlan30 interface=ether3

Laboratorio

Per questo laboratorio sono necessari due router ed


almeno un pc.
VLAN
Obiettivo di questo laboratorio è iniziare a maneggiare le
VLAN in RouterOS utilizzando l'interfaccia di WinBox.

VLAN - laboratorio
lab-vlan2
L'infrastruttura di rete da configurare è quella di figura lab-
vlan2 . Sul router R1, nelle schede di rete ether1, ether2 ed
ether3 sono attivi tre dhcp server che rilasciano gli indirizzi
IP relativi ad ognuna delle tre VLAN. Il router R2 si
comporta come uno switch con VLAN.
1. Prima di tutto si creano delle nuove interfacce
indicando il VLAN ID. Ogni interfaccia VLAN fa
riferimento ad una interfaccia fisica che determina il
trunk.

2. Il processo viene ripetuto per ogni VLAN:


3. Successivamente si creano delle interfacce di tipo
bridge che saranno utili alla configurazione delle porte
access/untagged.
4. Tra le porte di ogni switch sarà presente sempre la vlan
interessata e la scheda ethernet:

5. A questo punto non resta che configurare i tre server


dhcp con i relativi pool.
Si ricordi che indirizzi ip e server dhcp dovranno essere
ancorati alle rispettive interfacce bridge.
6. Di seguito le configurazioni finali dei due router:
{R1}
/system identity set name=R1
/interface vlan
add interface=ether4 name=vlan10 vlan-id=10
add interface=ether4 name=vlan20 vlan-id=20
add interface=ether4 name=vlan30 vlan-id=30
/interface bridge
add fast-forward=no name=bridgevlan10
add fast-forward=no name=bridgevlan20
add fast-forward=no name=bridgevlan30
/interface bridge port
add bridge=bridgevlan10 interface=ether1
add bridge=bridgevlan10 interface=vlan10
add bridge=bridgevlan20 interface=ether2
add bridge=bridgevlan20 interface=vlan20
add bridge=bridgevlan30 interface=vlan30
add bridge=bridgevlan30 interface=ether3
/ip address
add address=10.10.10.1/24 interface=bridgevlan10
network=10.10.10.0
add address=10.20.20.1/24 interface=bridgevlan20
network=10.20.20.0
add address=10.30.30.1/24 interface=bridgevlan30
network=10.30.30.0
/ip pool
add name=vlan10 ranges=10.10.10.100-10.10.10.200
add name=vlan20 ranges=10.20.20.100-10.20.20.200
add name=vlan30 ranges=10.30.30.100-10.30.30.200
/ip dhcp-server
add address-pool=vlan10 disabled=no
interface=bridgevlan10 name=vlan10
add address-pool=vlan20 disabled=no
interface=bridgevlan20 name=vlan20
add address-pool=vlan30 disabled=no
interface=bridgevlan30 name=vlan30
/ip dhcp-server network
add address=10.10.10.0/24 netmask=24
add address=10.20.20.0/24 netmask=24
add address=10.30.30.0/24 netmask=24

7. Si noti che la configurazione del router R2 non


contiene nessun indirizzo IP:
il router si comporterà come uno switch operando solo
a livello L2. {R2}
/system identity set name=R2
/interface bridge
add fast-forward=no name=bridgevlan10
add fast-forward=no name=bridgevlan20
add fast-forward=no name=bridgevlan30
/interface vlan
add interface=ether4 name=vlan10 vlan-id=10
add interface=ether4 name=vlan20 vlan-id=20
add interface=ether4 name=vlan30 vlan-id=30
/interface bridge port
add bridge=bridgevlan10 interface=ether1
add bridge=bridgevlan10 interface=vlan10
add bridge=bridgevlan20 interface=ether2
add bridge=bridgevlan20 interface=vlan20
add bridge=bridgevlan30 interface=vlan30
add bridge=bridgevlan30 interface=ether3

8. Per verificare il corretto funzionamento


dell'infrastruttura di rete creata basta verificare
l'indirizzo ip che ogni pc ottiene a seconda della porta a
cui è collegato.
Per ulteriori esempi si veda il link http://bit.ly/2Fje2dp che
comprede anche una dettagliata spiegazione.

Comparazione delle configurazioni

In questo capitolo abbiamo citato più volte brand come


Cisco ed HP, per completezza nelle prossime due pagine
riportiamo in sinossi le configurazioni di R2 del laboratorio
di figura lab-vlan1 a pagina lab-vlan1 e le configurazioni di
R2 del laboratorio di figura lab-vlan3 a pagina lab-vlan3
confrontanto quanto avviene in Mikrotik RouterOS, in HP e
in Cisco IOS.

Mikrotik RouterOS

/system identity set name=R2


/interface vlan
add interface=ether1 name=vlan10 \
vlan-id=10
add interface=ether1 name=vlan20 \
vlan-id=20
/interface bridge
add fast-forward=no \
name=bridgevlan10
add fast-forward=no \
name=bridgevlan20
/interface bridge port
add bridge=bridgevlan10 \
interface=vlan10
add bridge=bridgevlan20 \
interface=vlan20
add bridge=bridgevlan20 \
interface=ether3
add bridge=bridgevlan10 \
interface=ether2

HP
vlan 10
name "vlan10"
untagged 1
tagged 3
exit
vlan 20
name "vlan20"
untagged 2
tagged 3
exit

Cisco IOS
vlan database
vlan 10
vlan 20
exit
configure terminal
interface FastEthernet1/2
switchport mode access
switchport access vlan 10
!
interface FastEthernet1/3
switchport mode access
switchport access vlan 20
!
interface FastEthernet1/1
switchport mode trunk
switchport trunk allowed vlan all
!
Mikrotik RouterOS

/system identity set name=R2


/interface bridge
add fast-forward=no \
name=bridgevlan10
add fast-forward=no \
name=bridgevlan20
add name=bridgevlan1030
/interface vlan
add interface=bridgevlan1030 \
name=vlan10 vlan-id=10
add interface=bridgevlan1030 \
name=vlan20 vlan-id=20
add interface=bridgevlan1030 \
name=vlan30 vlan-id=30
/interface bridge port
add bridge=bridgevlan10 \
interface=vlan10
add bridge=bridgevlan20 \
interface=vlan20
add bridge=bridgevlan10 \
interface=ether1
add bridge=bridgevlan20 \
interface=ether2
add bridge=bridgevlan1030 \
interface=ether4
add bridge=bridgevlan1030 \
interface=ether3
/interface bridge vlan
add bridge=bridgevlan1030 \
tagged=ether3,ether4 \
vlan-ids=10,30

HP
vlan 10
name "vlan10"
untagged 1
tagged 3-4
exit
vlan 20
name "vlan20"
untagged 2
tagged 3
exit
vlan 30
name "vlan30"
tagged 3-4
exit

Cisco IOS
vlan database
vlan 10
vlan 20
vlan 30
exit
configure terminal
interface FastEthernet1/1
switchport mode access
switchport access vlan 10
!
interface FastEthernet1/2
switchport mode access
switchport access vlan 20
!
interface FastEthernet1/3
switchport mode trunk
switchport trunk allowed vlan all
!
interface FastEthernet1/4
switchport mode trunk
switchport trunk allowed vlan all
!

Nota importante sulla performance

Molti dispositivi MikroTik sono dotati di chip switch integrati


che in genere hanno la possibilità di effettuare lo switching
VLAN a livello hardware, ciò significa che è possibile
ottenere prestazioni wire-speed utilizzando le VLAN se
viene utilizzato un metodo di configurazione appropriato. Il
metodo di configurazione cambia tra diversi modelli. Per
degli esempi di configurazione che seguono le specifiche
hardware si veda il link http://bit.ly/2Fg8jVu .
RouterOS /32 e gli indirizzi IP
unnumbered
Leggendo la letteratura sulle VLAN spesso si incontra
l'espressione IP unnumbered . Si tratta di un indirizzo IP /32
che consente di abilitare l'elaborazione IP su un'interfaccia
senza assegnargli un indirizzo IP esplicito. Possiamo
approssimare affermando che una interfaccia con un IP
unnumbered "prende in prestito" l'indirizzo IP di un'altra
interfaccia già configurata sul router, che conserva la rete e
lo spazio degli indirizzi. Per approfondire l'argomento si può
fare riferimento all'articolo disponibile al link
http://bit.ly/2FhTT6y . La domanda che sorge è: perché
usare un indirizzo /32 e non limitarsi a configurare un
indirizzo IP sull'interfaccia? Per rispondere a questa
domanda dobbiamo immergerci nel passato. Agli inizi di
internet non erano disponibili le maschere di sottorete con
lunghezza variabile, cioè la numerazione VLSM (Variable
Length Subnet Mask) e questo era particolarmente
fastidioso quando si usavano protocolli di routing classful
come RIP v1 e IGRP, il predecessore di EIGRP. Con la
numerazione VLSM la sottorete più piccola che si poteva
usare era /24. Immaginate che spreco quando si usano gli
indirizzi IP pubblici. IP unnumbered fu creato per risolvere
questo problema in modo da non dover sprecare intere
sottoreti /24 sulle interfacce point-to-point: il meccanismo IP
unnumbered prende in prestito un indirizzo IP da un'altra
interfaccia in modo da non doverne configurare uno
sull'interfaccia point-to-point. Ai giorni nostri abbiamo
molteplici alternative: possiamo usare VLSM e creare
sottoreti /30 senza sprecare molti indirizzi IP; oppure
possiamo utilizzare gli indirizzi IP privati, se la nostra rete lo
consente. Ne consegue che non abbiamo più bisogno di IP
unnumbered come in passato. Tuttavia può essere utile se
si desidera impostare rapidamente un collegamento point-
to-point senza preoccuparsi degli indirizzi IP e trovare una
sottorete adatta. RouterOS offre la possibilità di utilizzare
l'indirizzo con una maschera di rete di /32 per esempio in
un tunnel point-to-point con gli indirizzi e questo offre le
stesse funzionalità degli IP unnumbered di altri produttori.

Unnumbered IP
unnumbered
Nell'infrastruttura di figura unnumbered sono presenti due
router R1 e R2, ciascuno dei quali è parte delle reti
10.22.0.0/24 e 10.23.0.0/24 rispettivamente. Per connettere
questi router usando le VLAN come carrier sono utilizzate
la seguenti configurazioni che fanno uso di IP unnumbered:
{R1}
/system identity set name=R1
/ip address add address=10.22.0.1/24 interface=ether1
/interface vlan add interface=ether2 vlan-id=10
name=vlan10
/ip address add address=10.22.0.1/32 interface=vlan10
network=10.23.0.1
/ip route add gateway=10.23.0.1 dst-
address=10.23.0.0/24

{R2}
/system identity set name=R2
/ip address add address=10.23.0.1/24 interface=ether1
/ interface vlan add interface=ether2 vlan-id=10
name=vlan10
/ip address add address=10.23.0.1/32 interface=vlan10
network=10.22.0.1
/ip route add gateway=10.22.0.1 dst-
address=10.22.0.0/24

Domande di riepilogo
domande-4
1. E' possibile creare una configurazione dove VLAN e
interfacce PPTP convivono in un bridge?
1. Sì
2. No
2. E' possibile creare una rete punto-punto wireless dove
la connessione tra le due antenne si comporti come un
trunk VAN?
1. Sì
2. No

Soluzioni

1. Sì. Su questo si veda l'interessante intervento "VLAN


in MikroTik" di Mohammed Khomeini Bin ABU al MUM
2013,
in particolare dalla slide 13 (http://bit.ly/2Qz3Xdg)
2. Sì. Su questo si veda http://bit.ly/2QvImTb che riporta
la completa configurazione di un caso tipico d'uso .

Tunnel
{«Vieni a fare un giro giù con me, ragazza \\ nel tunnel
dell'amore»} Dire Straits

Virtual Private Network


Il termine VPN (Virtual Private Network) identifica una Rete
Virtuale Privata (Virtual Private Network). Permettono lo
scambio dei dati tra sedi aziendali distribuite sul territorio e
rappresenta un servizio di maggiore interesse per i clienti
Business. Si dice che la rete è privata in quanto permette le
comunicazioni private tra i siti aziendali, alla stessa stregua
di una rete privata fisica (es. sono mantenuti gli schemi di
routing e indirizzamento) Si dice che la rete è virtuale in
quanto i collegamenti sono virtuali e non fisisci. La rete
fisica di supporto è pubblica e non privata, ma la gestione
delle risorse e le tecniche di sicurezza sono tali da
"virtualizzarla" come e fosse privata. A titolo esemplificativo,
un istituto universitario può attivare una VPN per consentire
ai propri studenti la consultazione da casa di pubblicazioni
per le quali ha sottoscritto degli abbonamenti; finché
l'utente ha il servizio VPN attivato, tutte le sue richieste
transitano dai server dell'istituto, come se la connessione
fosse effettuata in locale, ottenendo pertanto l'accesso ai
servizi di abbonamento riservati; nel contempo l'utente è
anche soggetto alle politiche del gestore che può ad
esempio crittografare o meno la connessione server-utente
o inibire alcuni protocolli come il P2P o l'accesso ai siti
internet inseriti in una black list.

Virtual Private Network.


vpn
C'è una condizione necessaria all'interno di una stessa
VPN l'indirizzamento deve essere unico. Una VPN può
essere realizzata ad uno qualsiasi dei livelli ISO/OSI, ad
esempio:
1. Livello 1. VPN fisica, ad esempio con un CDN (Circuito
Diretto Numerico), le "vecchie" linee dedicate .
2. Livello 2. VPN data link, ad esempio ATM PVC oppure
le VLAN descritte nel capitolo precedente.
3. Livello 3. VPN network come IPsec, tunneling,...
4. Livello 4. VPN a livello di trasporto come TLS.
Allo stato attuale, il termine VPN è generalmente riferito ad
una infrastruttura di rete di livello 3. Possiamo individuare
due modalità di trasporto dei dati:
1. Overlay: la rete pubblica offerta dall'ISP offre solo
funzionalità di trasporto
e le informazioni di routing sono scambiate solo fra i siti
aziendali. In questo caso la topologia (logica e fisica) è
composta da collegamenti punto-punto definiti dal
customer (cliente). Se consideriamo questi
collegamenti punto-punto possiamo individuare una
rete "sovrapposta" (lett. overlay) alla rete fisica.
2. Peer-to-peer: la rete pubblica offerta dall'ISP scambia
con i siti aziendali anche informazioni di routing.
In questo caso la topologia logica è definita dal
customer, la topologia fisica che realizza la topologia
logica è decisa dal provider secondo specifici criteri di
traffic engineering nella sua rete.
Sulle Peer-to-Peer VPN, dove il routing avviene su un layer
composto sia da entità che risiedono in azienda che da
entità che risiedono nell'ISP, ritorneremo più avanti
parlando di MPLS (si veda la sezione mpls a partire da
pagina mpls ). In questa prima parte ci dedicheremo alle
VPN overlay che generalmente sono realizzate su rete
pubblica internet. In questo caso la sicurezza delle
comunicazioni deve essere realizzata ent-to-end, in quanto
non ci si può fidare di una rete sicura di trasporto; per
questo il modello di riferimento prevede la creazione di
tunnel sicuri fra gli end-points della VPN.

Tunnel
Il termine tunneling si riferisce a un insieme di tecniche per
cui un protocollo viene incapsulato in un protocollo dello
stesso livello o di livello superiore per realizzare
configurazioni particolari. La sicurezza della comunicazione
è ottenuta attraverso la cifratura dei dati che sono inseriti
all'interno del tunnel e l'autenticazione degli end-point. I
pacchetti dei dati sono modificati all'invio mediante
l'aggiunta di un'intestazione che permetterà di attraversare
il tunnel; successivamente, quando saranno arrivati alla
destinazione, alla fine del tunnel, l'intestazione verrà
rimossa restituendo il pacchetto originario. Spesso i termini
"tunnel" e "VPN" vengono usati come sinonimi, ma non è
un approccio corretto. Protocolli che definiscono tunnel:
IPIP – IP Tunnel
EoIP – Ethernet Over IP
VLAN – Virtual Lan
MPLS – Multi Protocol Label Switching
Gre Tunnel
Protocolli che definiscono VPN:
PPPoE – PointToPointProtocol Over Ethernet
PPTP – PointToPoint Tunnel Protocol
L2TP – Layer 2 Tunnel Protocol
OpenVPN – Open Virtual Private Network
IPSec – IP Security
SFTP – Secure Socket Tunnel Protocol
In questo testo affronteremo:
IPIP – IP Tunnel - pagina ipip
EoIP – Ethernet Over IP - pagina eoip
VLAN – Virtual Lan - pagina vlan
MPLS – Multi Protocol Label Switching - pagina mpls
IPSec – IP Security - pagina ipsec
RouterOS mette a disposizione diversi tipi di tunnel e VPN:
PPTP, L2TP, PPPoE, EoIP, SSTP, OpenVPN, ecc. Le
tipologie che si possono utilizzare sono visibili nella lista
delle interfacce virtuali (vedi figura vpn-list ).

Lista delle interfacce virtuali a disposizione.


vpn-list
Sui principali protocolli per le VPN è dedicato il capitolo 8
del libro "Teoria, laboratori ed esercizi per Mikrotik
RouterOS" (vedi https://amzn.to/2Qm4S0L ) per questo
nelle sezioni che seguono si tralasceranno i protocolli
comuni come PPTP e PPPoE per approfondire protocolli
più complessi come IPsec ed MPLS. Per una analisi su
quale VPN utilizzare nella propria infrastruttura di rete si
consiglia di fare riferimento all'intervento di Andis Arins al
MUM Europe di Ljubljana del 25 marzo 2016:
http://bit.ly/2Qjloi1 .
Indirizzi IP sulle reti punto-punto

In generale, per connettere 2 dispositivi utilizzeremo IP con


un minimo di subnet /30, dove ci saranno 2 host utilizzabili,
ad esempio:
Indirizzo di Indirizzo di
Indirizzi utilizzabili
rete broadcast
172.16.1.1-
172.16.1.0/30 172.16.1.3
172.16.1.2
In Mikrotik, queste esigenze possono essere soddisfatte
utilizzando la subnet IP /32 o il singolo IP: è un sistema di
indirizzamento di indirizzi IP per due dispositivi collegati
direttamente. Poiché utilizza solo 2 indirizzi IP, non esiste
un indirizzo di trasmissione, ma l'IP di rete deve essere
impostato manualmente con un indirizzo IP remoto.
L'esempio più ovvio è l'implementazione di una VPN PPTP.
Nella scheda Secret del server PPTP i parametri di indirizzo
locale e remoto utilizzano IP /32:

Dopo la creazione del tunnel PPTP, verrà visualizzato un


nuovo indirizzo IP su entrambi i lati del router con subnet
/32. Confrontando il lato server e il lato client della VPN si
nota la differente posizione dell'indirizzo IP:
Oltre al servizio VPN, l'indirizzamento punto-punto può
essere applicato manualmente all'installazione di 2
dispositivi collegati direttamente. Questo metodo è
ampiamente utilizzato dai provider (ISP) con l'obiettivo di un
uso efficiente dell'IP pubblico. Ad esempio, un ISP potrebbe
assegnare al client l'indirizzo IP 222.152.211.0/30. L'ISP
userà un IP preso dall'intervallo subnet /30 come gateway,
in questo modo il client avrà un solo indirizzo che potrà
essere installato sul dispositivo. Tuttavia, con il concetto di
indirizzamento point-to-point, l'IP 222.152.211.0/30 sarà
completamente a disposizione del client e questo mette a
disposizione del client due indirizzi IP. Come potrebbe fare
l'ISP per non "sprecare" indirizzi IP? Ecco la soluzione.

Topologia punto-punto con indirizzamento /32.


Indirizzi da impostare nei due router in IP > Addresses :

Indirizzamento punto a punto.


Rotta statica da impostare su R1 verso il router R2. Questa
rotta ha come gateway l'indirizzo punto-punto:
Per il router R2 usiamo quanto descritto a pagina loopback
circa l'interfaccia di loopback: In questo caso l'indirizzo IP è
installato sull'interfaccia del bridge fittizio, cioè il bridge è
stato creato senza nessuna porta bridge assegnata. A
questo punto si procede nella configurazione come
consueto, le uniche modifiche riguardano le impostazioni
del NAT e il default gateway che devono tenere conto
dell'indirizzo di uscita dal router:

Configurazione NAT del router R2


Le impostazioni NAT sono fatte in modo che il client possa
accedere ad internet. Secondo quanto detto
precedentemente, l'accesso a internet è fatto attraverso l'IP
pubblico, non attraverso l'IP punto-punto, quindi l'indirizzo
deve essere forzato, cioè deve essere 222.152.211.1,
quando il pacchetto client esce dal router:
R2 Configurazione gateway predefinita
Per ottenere questa "forzatura" si utilizza la proprietà Pref-
Source, studiata a pagina pref-src , in modo che quando il
pacchetto esce dal router utilizzi come IP 222.152.211.1.

IP-in-IP
ipip L'implementazione del tunneling IP-in-IP, anche detto
brevemente IPIP, su MikroTik RouterOS è conforme a RFC
2003; molti router, tra cui Cisco e Linux, supportano questo
protocollo. Il tunnel IPIP è un protocollo semplice che
incapsula i pacchetti IP in un tunnel tra due router.
L'interfaccia del tunnel IPIP appare come un'interfaccia
sotto l'elenco delle interfacce ma non è possibile inserire
l'interfaccia IPIP come porta in un bridge. Il protocollo
aggiunge le seguenti possibilità ad una infrastruttura di rete:
può essere usato per trasportare le reti intranet
attraverso internet;
può essere usato al posto del source routing .
Incapsulamento IP-in-IP.
IP_in_IP_Encapsulation
Per incapsulare un pacchetto IP in un altro pacchetto IP
(vedi figura IP_in_IP_Encapsulation ), una intestazione
esterna viene aggiunta con il SourceIP, il punto di ingresso
del tunnel e della destinazione, il punto di uscita del tunnel.
Mentre fa questo, il pacchetto interno non è modificato
(eccetto il campo TTL, che è decrementato). I campi Do not
Fragment e Type Of Service sono copiati nel pacchetto
esterno. Se la dimensione del pacchetto è maggiore della
MTU del percorso allora il pacchetto viene frammentato
durante l'incapsulamento in quanto l'intestazione esterna
deve essere inclusa. All'arrivo a destinazione il pacchetto
verrà riassemblato.

GRE vs IPIP

L'incapsulamento di routing generico (GRE) e IP-in-IP


(IPIP) sono due meccanismi di tunneling piuttosto simili che
sono spesso confusi. L'incapsulamento IP-in-IP è
esattamente ciò che sembra: un pacchetto IP incapsulato
all'interno di un altro (vedi figura ipip_encapsulation ). Il
campo del protocollo dell'intestazione esterna è impostato
su 4 per IPv4 o 41 per IPv6.

Incapsulamento IPIP.
ipip_encapsulation
Il GRE (definito in RFC 2784 e aggiornato da RFC 2890) fa
un passo in più rispetto a IP-in-IP, aggiungendo
un'intestazione aggiuntiva all'interno e all'esterno delle
intestazioni IP (vedi figura gre_encapsulation ).

Incapsulamento GRE.
gre_encapsulation
Questa aggiunta permette al protocollo GRE di:
incapsulare qualsiasi protocollo di livello tre (rispetto a
solo IP);
aggiunge un checksum aggiuntivo (che non è utile per
TCP/IPv4);
specificare una chiave per il tunnel;
applicare il sequenziamento dei pacchetti.
Di contro queste funzionalità hanno un costo aggiuntivo di
overhead; nei casi in cui le funzionalità GRE non siano
necessarie, IPIP è una ottima scelta.

Laboratorio

Per questo laboratorio sono necessari tre router e due pc.


Tunnel IPIP
L'obiettivo di questo laboratorio è realizzare l'infrastruttura
di figura ipip2 partendo da quella di figura ipip .

Tunnel IPIP.
ipip
1. Colleghiamo i router come in figura ipip .
2. Configuriamo i router R1, R2 e R3 per la connettività di
base:
{R1}
/system identity set name=R1
/ip address
add address=10.10.10.30/24 interface=ether1

{R2}
/system identity set name=R2
/interface bridge add name=bridge1
/interface bridge port add interface=ether1
bridge=bridge1
/interface bridge port add interface=ether2
bridge=bridge1
/ip address
add address=10.10.10.30/24 interface=bridge1

{R3}
/system identity set name=R3
/ip address
add address=10.10.10.31/24 interface=ether1

3. Controlliamo la connessione dal router R1 verso R3:

[admin@R1] > /ping 10.10.10.31


SEQ HOST SIZE
TTL TIME STATUS
0 10.10.10.31 56
64 18ms
1 10.10.10.31 56
64 2ms
2 10.10.10.31 56
64 2ms
3 10.10.10.31 56
64 6ms
4 10.10.10.31 56
64 2ms
sent=5 received=5 packet-loss=0

4. Creiamo il tunnel agendo sui router R1 ed R3:


{R1}
/interface ipip add name=ipip local-
address=10.10.10.30 \
remote-address=10.10.10.31
/ip address add address=192.168.200.1/30
interface=ipip

{R3}
/interface ipip add name=ipip local-
address=10.10.10.31 \
remote-address=10.10.10.30
/ip address add address=192.168.200.2/30
interface=ipip

5. Controlliamo la connessione dal router R3 verso R1


ma usando gli indirizzi ip del tunnel :

[admin@R3] > /ping 192.168.200.1


SEQ HOST SIZE
TTL TIME STATUS
0 192.168.200.1 56
64 9ms
1 192.168.200.1 56
64 3ms
2 192.168.200.1 56
64 4ms
sent=3 received=3 packet-loss=0

6. Modifichiamo l'infrastruttura collegendo i due PC come


in figura ipip2 .

Tunnel IPIP con routing.


ipip2
7. Modifichiamo la configurazione dei R1 ed R3 per la
connettività di base:
{R1}
/ip address
add address=192.168.1.1/24 interface=ether2
/ip pool
add name=dhcp_pool0 ranges=192.168.1.2-
192.168.1.254
/ip dhcp-server
add address-pool=dhcp_pool0 disabled=no
interface=ether2 name=dhcp1
/ip dhcp-server network
add address=192.168.1.0/24 gateway=192.168.1.1

{R3}
/ip address
add address=192.168.2.1/24 interface=ether2
/ip pool
add name=dhcp_pool0 ranges=192.168.2.2-
192.168.2.254
/ip dhcp-server
add address-pool=dhcp_pool0 disabled=no
interface=ether2 name=dhcp1
/ip dhcp-server network
add address=192.168.2.0/24 gateway=192.168.2.1

8. Controlliamo che il PC-1 abbia ottenuto un indirizzo ip


valido e riesca a comunicare con R1:

PC-1> ping 192.168.1.1


84 bytes from 192.168.1.1 icmp_seq=1 ttl=64
time=2.637 ms
84 bytes from 192.168.1.1 icmp_seq=2 ttl=64
time=0.503 ms
84 bytes from 192.168.1.1 icmp_seq=3 ttl=64
time=0.418 ms
84 bytes from 192.168.1.1 icmp_seq=4 ttl=64
time=0.360 ms
84 bytes from 192.168.1.1 icmp_seq=5 ttl=64
time=0.401 ms

9. Controlliamo che il PC-2 abbia ottenuto un indirizzo ip


valido e riesca a comunicare con R3:

PC-2> ping 192.168.2.1


84 bytes from 192.168.2.1 icmp_seq=1 ttl=64
time=2.416 ms
84 bytes from 192.168.2.1 icmp_seq=2 ttl=64
time=0.417 ms
84 bytes from 192.168.2.1 icmp_seq=3 ttl=64
time=2.128 ms
84 bytes from 192.168.2.1 icmp_seq=4 ttl=64
time=0.401 ms
84 bytes from 192.168.2.1 icmp_seq=5 ttl=64
time=0.354 ms

10. Controlliamo se il PC-1 riesce a raggiugere PC-2:

PC-1> ping 192.168.2.1


*192.168.1.1 (ICMP type:3, code:0, Destination
network unreachable)
*192.168.1.1 (ICMP type:3, code:0, Destination
network unreachable)
*192.168.1.1 (ICMP type:3, code:0, Destination
network unreachable)
*192.168.1.1 (ICMP type:3, code:0, Destination
network unreachable)
*192.168.1.1 (ICMP type:3, code:0, Destination
network unreachable)

11. Come atteso PC-1 non raggiunge PC-2.


12. Aggiungiamo su R1 ed R3 le rotte statiche necessarie
che sfruttano il tunnel IPIP:
{R1}
/ip route add dst-address=192.168.2.0/24
gateway=192.168.200.2

{R3}
/ip route add dst-address=192.168.1.0/24
gateway=192.168.200.1

13. Controlliamo se il PC-1 riesce a raggiugere PC-2:

PC-1> ping 192.168.2.1


84 bytes from 192.168.2.1 icmp_seq=1 ttl=63
time=5.415 ms
84 bytes from 192.168.2.1 icmp_seq=2 ttl=63
time=1.472 ms
84 bytes from 192.168.2.1 icmp_seq=3 ttl=63
time=0.936 ms
84 bytes from 192.168.2.1 icmp_seq=4 ttl=63
time=2.320 ms
84 bytes from 192.168.2.1 icmp_seq=5 ttl=63
time=1.165 ms
14. Come previsto la comunicazione ora avviene con
successo .
15. Si noti che la connessione avviene attraverso il tunnel
IPIP e PC-1 non ha nessuna conoscenza
dell'infrastruttura interna,
ad esempio di R2:
PC-1> ping 10.10.10.100
10.10.10.100 icmp_seq=1 timeout
10.10.10.100 icmp_seq=2 timeout
10.10.10.100 icmp_seq=3 timeout
10.10.10.100 icmp_seq=5 timeout

EoIP
eoip

Come funziona il protocollo

Ethernet over IP (EoIP) è un protocollo MikroTik RouterOS


che crea un tunnel ethernet tra due router su una
connessione IP. Il tunnel EoIP può essere creato su tunnel
IPIP, tunnel PPTP o qualsiasi altra connessione in grado ti
trasportare il protocollo IP. Quando la funzione di bridging è
abilitata, tutto il traffico ethernet è parte di un bridge allo
stesso modo di un'interfaccia Ethernet fisica e un cavo tra i
due router (con bridging abilitato). Di fatto il protocollo EoIP
incapsula i frame ethernet in pacchetti GRE (numero
protocollo IP 47) e li invia al lato remoto del tunnel EoIP.

Laboratorio

Per questo laboratorio sono necessari tre router e due pc.


Tunnel EoIP
L'obiettivo di questo laboratorio è realizzare l'infrastruttura
di figura eoip-lab con un server dhcp tra i due router
esterni.
Tunnel EoIP.
eoip-lab
1. Colleghiamo i router come in figura eoip-lab .
2. Configuriamo i router R1, R2 e R3 per la connettività di
base :
{R1}

/system identity set name=R1


/ip address
add address=10.10.10.30/24 interface=ether1

{R2}
/system identity set name=R2
/interface bridge add name=bridge1
/interface bridge port add interface=ether1
bridge=bridge1
/interface bridge port add interface=ether2
bridge=bridge1
/ip address
add address=10.10.10.30/24 interface=bridge1

{R3}
/system identity set name=R3
/ip address
add address=10.10.10.31/24 interface=ether1

3. Controlliamo la connessione dal router R1 verso R3:

[admin@R1] > /ping 10.10.10.31


SEQ HOST SIZE
TTL TIME STATUS
0 10.10.10.31 56
64 18ms
1 10.10.10.31 56
64 2ms
2 10.10.10.31 56
64 2ms
3 10.10.10.31 56
64 6ms
4 10.10.10.31 56
64 2ms
sent=5 received=5 packet-loss=0

4. Creiamo il tunnel agendo sui router R1 ed R3:


{R1}
/interface eoip add name=eoip local-
address=10.10.10.30 \
remote-address=10.10.10.31 tunnel-id=0

{R3}

/interface eoip add name=eoip local-


address=10.10.10.31 \
remote-address=10.10.10.30 tunnel-id=0

5. Sempre su R1 ed R3 creaimo un bridge e inseriamo


ether2 e l'endpoint del tunnel EoIP tra le porte:
{R1}
/interface bridge add name=bridge1
/interface bridge port add interface=ether2
bridge=bridge1
/interface bridge port add interface=eoip
bridge=bridge1
/ip address
add address=192.168.200.1/24 interface=bridge1

{R3}
/interface bridge add name=bridge1
/interface bridge port add interface=ether2
bridge=bridge1
/interface bridge port add interface=eoip
bridge=bridge1
/ip address
add address=192.168.200.2/24 interface=bridge1

6. Sul router R1 creaimo un DHCP server che fornisca gli


indirizzi ip alle nostre due LAN:
{R1}
/ip pool
add name=dhcp_pool0 ranges=192.168.200.100-
192.168.200.200
/ip dhcp-server
add address-pool=dhcp_pool0 disabled=no
interface=bridge1 name=dhcp1
/ip dhcp-server network
add address=192.168.200.0/24 gateway=192.168.200.1

7. Controlliamo che i PC-1 e PC-2 abbiano ottenuto un


indirizzo ip valido e riescano a comunicare tra di loro:

PC-1> show ip
NAME : PC-1
IP/MASK : 192.168.200.198/24
PC-2> show ip
NAME : PC-2
IP/MASK : 192.168.200.197/24
PC-1> ping 192.168.200.197
84 bytes from 192.168.200.197 icmp_seq=1 ttl=64
time=2.266 ms
84 bytes from 192.168.200.197 icmp_seq=2 ttl=64
time=4.836 ms
84 bytes from 192.168.200.197 icmp_seq=3 ttl=64
time=1.444 ms
84 bytes from 192.168.200.197 icmp_seq=4 ttl=64
time=1.636 ms
84 bytes from 192.168.200.197 icmp_seq=5 ttl=64
time=1.546 ms

IPsec
ipsec

Come funziona il protocollo

IPsec (IP SECurity) è una famiglia di protocolli dell'IETF che


ha lo scopo di rendere più sicure le comunicazioni che
utilizzano il protocollo IP. Poggia direttamente sul protocollo
IP al livello ISO/OSI 3; può essere implementato
direttamente attraverso hardware specifico, oppure via
software: nel caso di implementazioni hardware, sarà
completamente trasparente alla macchina, alle applicazioni
e al sistema operativo, mentre nel caso di implementazione
software, si deve modificare il sistema operativo. IPsec è
stato sviluppato prima all'interno dello standard IPv6 ed in
seguito inserito in IPv4. I protocolli principali he
compongono IPsec sono descritti nei seguenti RFC:
RFC 2401 : Security Architecture for the Internet
Protocol
RFC 2402 : IP Authentication Header
RFC 2406 : IP Encapsulating Security Payload (ESP)
RFC 2409 : The Internet Key Exchange (IKE)
Le problematiche che affliggono IPv4 e che IPsec tenta di
superare sono:
Integrità : sebbene ogni pacchetto IP abbia un
controllo di
integrità tramite una checksum (CRC), gli algoritmi
utilizzati sono molto deboli e non sufficienti a garantire
l'integrità dei pacchetti; pertanto il ricevente non può
essere sicuro che il pacchetto che riceve sia identico a
quello spedito e che non sia stato modificato,
volontariamente o meno, durante il percorso.
Autenticità : chiunque può inviare un pacchetto
ponendo come
mittente (sorgente) il numero IP di un altro host (questo
è di solito chiamato spoofing) pertanto il ricevente
(destinatario), utilizzando solo i dati presenti negli
header IP, non può essere sicuro di chi sia il mittente
del pacchetto.
Confidenzialità : tutto il pacchetto, ed i dati
(payload) in esso
trasportati, sono in chiaro, pertanto chiunque possa
intercettare (detto anche sniffing) il pacchetto può
leggerne il contenuto.
IPsec usa le seguenti strategie di comunicazione:
Mutua autenticazione prima e durante le
comunicazioni.
Confidenzialità tramite la cifratura del traffico IP.
Integrità del traffico IP in quanto viene rifiutato il traffico
modificato.
Per ottenere questi tre risultati adotta i seguenti protocolli:
AH (Authentication Header): fornisce integrità,
autenticazione, protezione da
attacchi di tipo “replay”.
ESP (Encapsulating Security Payload): fornisce, in più
rispetto ad AH, la confidenzialità.
IKE (Internet Key Exchange): protocollo per scambio
sicuroo delle chiavi di crittografia.
IPsec non definisce l’algoritmo di sicurezza (cifratura, ...)
specifico da utilizzare ma fornisce un modo per indicare
qual è l’algoritmo prescelto, consentendo l’utilizzo degli
algoritmi più consoni alle esigenze del momento. Ad
esempio l’integrità viene normalmente controllata facendo
uso degli algoritmo MD5 o SHA, mentre la crittografia è
spesso fatta mediante DES.
Bisogna distinguere due modi di funzionamento di IPsec:
1. il caso in cui IPsec è utilizzato fra due host che sono i
punti estremi del traffico, detto
modo di trasporto (Transport mode). In questo caso
vengono incapsulati datagrammi L4.
2. tutti gli altri casi (router-router, elaboratore-router ecc.)
dove almeno uno dei due estremi non è il
destinatario finale del traffico (Gateway), detto modo
tunnel (Tunnel mode); in questo caso il gateway invia e
riceve il traffico da e verso il destinatario finale
utilizzando il protocollo IP usuale. In questo caso viene
incapsulato l'intero pacchetto L3.
La differenza logica più significativa tra i due modi è che nel
secondo caso nel pacchetto trasportato da IPsec ci deve
essere sia l'indicazione del gateway che del destinatario
finale non IPsec, mentre nel primo caso quest'ultimo non è
necessario. Tutte le comunicazioni fra i due host connessi
da un tunnel IPsec ed identificati dal loro indirizzo IPv4,
devono passare via IPsec: pertanto se un host riceve un
pacchetto IPv4 non-IPsec con indirizzo IP sorgente di un
partner IPsec, lo deve scartare. Va notato che ogni tunnel è
unidirezionale, perciò per comunicare i due host devono
stabilire due tunnel, uno per ogni direzione. La procedura di
inizializzazione di IPsec è detta IKE (Internet Key
Exchange), di cui discuteremo alcuni dettagli più avanti.
Una volta terminata la procedura positivamente, sono
create due Security Association (SA), che sono la raccolta
di tutti i parametri che caratterizzano i due tunnel IPsec che
collegano i due host; in pratica le SA identificano
univocamente i tunnel. A questo punto finalmente l'host A,
utilizzando l'opportuna SA, trasforma il pacchetto originario
in un pacchetto IPsec e lo invia a B. B, avendo anch'esso le
due SA, può trasformare al contrario il pacchetto IPsec nel
pacchetto originale. Poi, in modo simile B può rispondere
ad A. Terminata la fase iniziale della creazione dei tunnel
(IKE), finalmente IPsec incomincia a scambiare i dati fra i
due host. Per questa operazione ha a disposizione due
protocolli: Authentication Header (AH) e Encapsulating
Security Payload (ESP). Va notato che AH non offre la
confidenzialità, ovvero i dati, cioè il payload, non sono
cifrati, mentre ESP permette di cifrare i dati. D'altro canto
AH garantisce l'integrità anche degli Header IP del
pacchetto (con l'eccezione di alcune parti mutabili come
discusso più avanti), mentre ESP garantisce l'integrità solo
del payload del pacchetto IP. Mettendo insieme i due modi
di trasmissione (Tunnel e Transport) con i due Protocolli di
IPsec (AH e ESP), si ottengono i quattro principali tipi di
pacchetti di dati creati e trasportati da IPsec. Poiché la fase
di inizializzazione è lenta e complicata, abbiamo quindi che
un tunnel IPsec viene creato e rimane attivo per un certo
periodo di tempo, sia che vi sia traffico che non vi sia. Allo
scadere del tempo, se non vi è traffico il tunnel viene chiuso
altrimenti le SA vengono rigenerate. Abbiamo detto che ad
ogni SA sono associabili caratteristiche di sicurezza
differenti e che occorrono due SA per avere la protezione
completa di un canale bidirezionale, per gestire questo si
utilizzano due database locali IPsec che memorizzano le
informazioni necessarie:
SAD (SA Database): elenca le SA attive e per ciascuna
SA ne specifica
le caratteristiche:
Sequence number counter (32 bit)
AH information (algoritmi, chiavi, tempo di
validità,...)
ESP information (algoritmi, chiavi, tempo di
validità,...)
Lifetime of SA: tempo/num byte dopo il quale la
SA
deve essere sostituita o terminata
Modalità di IPsec: trasporto o tunnel
SPD (Security Policy Database): contiene le security
policy da applicare ai diversi
tipi di comunicazione cioè specifica quali servizi
devono essere offerti ai diversi tipi di traffico IP come
ad esempio:
Tutto il traffico verso 192.168.2.1 deve protetto da
ESP in modalità trasporto usando DES
Tutto il traffico FTP (TCP, porta 20) verso
192.168.2.2 deve essere protetto da ESP in
modalità tunnel usando 3DES
Tutto il traffico verso 192.168.2.3 non deve essere
protetto.
Quindi SPD è costituito da policy entry composte ad
esempio di uno o piú selettori che specificano il traffico
IP gestito da questa entry, dall'indicazione se il
matching traffic deve essere scartato, bypassare IPsec
o essere soggetto a IPsec processing.
Come funziona IPsec - spedizione
ipsec-send

Come funziona IPsec - ricezione con AH


ipsec-receive-ah

IPsec con RouterOS

Prima di tutto va notato che in RouterOS affinchè si attivi il


processo IPsec è necessario che ci sia del traffico che
corrisponde ad un criterio IPsec. Cosa è necessario
configurare?
Configurare la fase 1: è la fase che genera gli SA che
saranno usati più tardi per cifrare tutto il traffico:
usando la voce IP > IPsec > Peers è necessario
aggiungere un nuovo peer indicando l'indirizzo
dell'altro punto IPsec, la password condivisa per
iniziare la generazione dei certificati e se i
pacchetti devono essere incapsulati dentro un
pacchetto UDP per attraversare dei NAT;
indicare gli algoritmi di cifratura ed autenticazione
che verranno usati;
indicare i valori di DPD (Dead Peer Detection) per
individuare automaticamente eventuali timeout.
Configurare la fase 2: questa fase indica al router cosa
cifrare e quale SA utilizzare:
usando la voce IP > IPsec > Policies si
definisce il traffico da cifrare, ad esempio
indicando l'indirizzo sorgente o il destinatario,...
usando la voce IP > IPsec > Policies
Proposals si indica al router quale algoritmo
usare per la cifratura e la funzione di hash da
usare per la fase 2.
Facendo riferimento alle fasi della comunicazione IPsec
possiamo riassumere i comandi di RouterOS nei seguenti
gruppi:
/ip ipsec peer - definisce le impostazioni per la fase 1
per i peer IPsec;
/ip ipsec policy - definisce quale traffico processare
e come processarlo;
/ip ipsec proposal - definisce la crittografia e gli
algoritmi da usare.
Suggerimento. Per abilitare il log specifico per IPsec usare
il comando: \\ /system logging add topics=ipsec
Ora siamo pronti per la configurazione di una semplice VPN
IPsec site-to-site. Per le due configurazioni che seguono si
faccia riferimento all'infrastruttura di figura ipsec-site-to-site
.

Semplice VPN IPsec site-to-site


ipsec-site-to-site

In tunnel mode

/system identity set name=R1


# Creazione peer (Phase 1)
/ip ipsec peer
add address=2.2.2.2/32
dh-group=modp2048
dpd-interval=10s
dpd-maximum-failures=3
encalgorithm=aes-256
hash-algorithm=sha512
secret=superSecret
# Creazione policy (Phase 2)
/ip ipsec policy
add dst-address=10.2.2.0/24
sa-dst-address=2.2.2.2
sa-src-address=1.1.1.1
src-address=10.1.1.0/24
tunnel=yes
# Il traffico nel tunner IPsec
# non deve essere in NAT
/ip firewall nat
add action=accept chain=srcnat
dst-address=10.2.2.0/24

/system identity set name=R2


# Creazione peer (Phase 1)
/ip ipsec peer
add address=1.1.1.1/32
dh-group=modp2048
dpdinterval=10s
dpd-maximum-failures=3
encalgorithm=aes-256
hash-algorithm=sha512
secret=superSecret
# Creazione policy (Phase 2)
/ip ipsec policy
add dst-address=10.1.1.0/24
sa-dst-address=1.1.1.1
sa-src-address=2.2.2.2 s
rc-address=10.2.2.0/24
tunnel=yes
# Il traffico nel tunner IPsec
# non deve essere in NAT
/ip firewall nat
add action=accept chain=srcnat
dst-address=10.1.1.0/24

In transport mode

/system identity set name=R1


# Configurazione IPsec
/ip ipsec peer
add address=2.2.2.2/32
dh-group=modp2048
dpdinterval=10s
dpd-maximum-failures=3
enc-algorithm=aes256
hash-algorithm=sha512
secret=superSecret
/ip ipsec policy
add dst-address=2.2.2.2/32
protocol=gre
src-address=1.1.1.1/32
# Tunnel GRE per il traffico
/interface gre
add clamp-tcp-mss=no
dont-fragment=inherit
keepalive=10s,3 mtu=1400
name=gre-tunnel1
remote-address=2.2.2.2
# routing
/ip address
add address=10.255.0.1/24
interface=gre-tunnel1
/ip route
add distance=1
dst-address=10.2.2.0/24
gateway=10.255.0.2

/system identity set name=R2


# Configurazione IPsec
/ip ipsec peer
add address=1.1.1.1/32
dh-group=modp2048
dpdinterval=10s
dpd-maximum-failures=3
enc-algorithm=aes256
hash-algorithm=sha512
secret=superSecret
/ip ipsec policy
add dst-address=1.1.1.1/32
protocol=gre
src-address=2.2.2.2/32
# Tunnel GRE per il traffico
/interface gre
add clamp-tcp-mss=no
dont-fragment=inherit
keepalive=10s,3 mtu=1400
name=gre-tunnel1
remote-address=1.1.1.1
# routing
/ip address
add address=10.255.0.2/24
interface=gre-tunnel1
/ip route
add distance=1
dst-address=10.1.1.0/24
gateway=10.255.0.1

IPsec/XAuth
Al MUM 2018 di Berlino, Tomas Kirnak ha tenuto un
interessante talk sul protocollo IPsec/XAuth spesso
chiamato "Cisco IPsec". Le slide del talk sono disponibili al
link http://bit.ly/2RlSeEg mentre una descrizione dettagliata
del protocollo è disponibile al link http://bit.ly/2RmuWOD .
Spesso le VPN vengono utilizzate da parte degli
amministratori di rete per gestire da remoto le reti dei
clienti, altre volte ci sono richieste da qualche utente che
deve lavorare da postazioni remote oppure da aziende che
devono accedere per gestire qualche apparato. In sintesi
possiamo dire che spesso la configurazione richiesta è
client-to-site con il client che si trova dietro una rete NAT. Ci
sono molte opzioni utilizzabili per offrire al cliente queste
opportunità:
PPTP (molto insicura )
SSTP
OpenVPN
L2TP / IPSec
IPSec Xauth mode-config
IKEv2
La scelta di IPsec/Xauth mode-config è molto interessante
in quanto:
è supportata da quasi tutti i sistemi operativi anche
mobile,
non è TCP-based,
supporta chiavi, certificati e password condivisa,
il router invia in automatico al client la configurazione
delle rotte (in questo modo si può limitare cosa il client
vede della rete di destinazione), dei dns (così il client
può risolvere nomi locali),...
ci sono software free per semplificare ulteriormente la
configurazione dei client.
Come primo passo è necessario preparare la
configurazione che successivamente sarà inviata ai client.
Gran parte della configurazione viene dedotta
automaticamente da quanto impostato nel peer e nel suo
profilo. Impostando nella configurazione del peer generate-
policy=port-strict le policy IPsec vengono generate
automaticamente.
IPsec/XAuth - configurazione da inviare ai client

IPsec/XAuth - Peer profile


IPsec/XAuth - Peer - General

IPsec/XAuth - Peer - Advanced


Definiamo come cifrare il traffico:

IPsec/XAuth - Policy proposal


Aggiungiamo un utente:

IPsec/XAuth - aggiunta di un utente


Di seguito riportiamo la configurazione finale risultante per il
router che accetterà la connessione e fornirà la
configurazione ai client:
/system identity set name=R1
# Impostazione XAuth con mode-config
/ip pool
add name=vpn-admins ranges=10.10.10.10-10.10.10.20
/ ip ipsec mode-config
add address-pool=vpn-admins name=vpn-admins
split-include=10.4.11.0/24,192.168.0.0/24 static-
dns=1.2.3.4
system-dns=no
# Configurazione dei peer
/ip ipsec peer profile
add dpd-interval=10s dpd-maximum-failures=3
enc-algorithm=aes-256,3des
hash-algorithm=sha512 name=vpn-admins
/ip ipsec peer
add address=0.0.0.0/0 auth-method=pre-shared-key-
xauth
generate-policy=port-strict mode-config=vpn-admins
passive=yes
secret=thisIsSuperSecret
# Aggiunta degli utenti
/ip ipsec user
add name=username password=password
# Definizione di come cifrare il traffico
/ip ipsec proposal
set [ find default=yes ] auth-algorithms=sha256
enc-algorithms=aes-128-cbc pfs-group=modp2048

Ora non resta che configurare il client. In questo caso


mostriamo la configurazione del client per OSX, per altri
client come Microsoft Windows o Android si veda il
documento http://bit.ly/2C9S2xn . Per la configurazione del
client VPN di Apple OSX:
1. Andare in Preferenze di sistema > Rete
2. Premere sul simbolo + in basso a sinistra
3. Creare una VPN di tipo Cisco IPsec e assegnare il
nome che si preferisce
4. Inserire i seguenti parametri
1. indirizzo: (indicare l'ip del server VPN IPsec)
2. user: username
3. pass: password
5. Premere su avanzate e come chiave
precondivisa utilizzare thisIsSuperSecret.
MPLS
Come funziona il protocollo

mpls L'idea alla base del protogollo MPLS (Multi Protocol


Label Switching ) è quella di inoltrare i pacchetti in base ad
un’etichetta (label) invece dell’indirizzo IP di destinazione.
Questo approccio produce ricerche più veloci nella tabella
di inoltro in quanto l'etichettà può essere usata come indice
anzichè il longest prefix matching ed inoltre permette un
controllo più raffinato del traffico. Il protocollo MPLS nasce
in risposta ai problemi che la rete stava incontrando nel suo
sviluppo agli inizi degli anni ’90. Tra questi abbiamo la
complessità del routing, l'utilizzo di tecnologie diverse
difficilmente integrabili come IP e ATM e i problemi di
scalabilità. MPLS risolve questi problemi in modo semplice
ed efficace: si pone infatti tra i dati del protocollo di secondo
livello e quelli del protocollo di terzo livello, aggiungendo il
proprio header, che contiene una label in cui sono definite
tutte le informazioni necessarie per l’instradamento del
pacchetto. In questo modo i dati del protocollo di terzo
livello sono trasparenti ai router della rete; grazie a MPLS
posso quindi utilizzare lo stesso router per far transitare
pacchetti di protocolli diversi, anche se tipicamente si usa
con pacchetti di tipo IP. MPLS separa completamente la
componente di controllo (comunicazione tra nodi e
aggiornamento tabelle di routing) e la componente che
realizza l’effettivo instradamento dei pacchetti basandosi
sulle tabelle di routing, detta componente di forwarding. Il
cuore di una rete MPLS è formato da un insieme di router
capaci di instradare i pacchetti unicamente tramite il
contenuto delle label MPLS. Tali router sono detti LSR
(Label Switch Router ), che insieme formano un’area
definita backbone MPLS come esemplificato in figura mpls-
dominio .
Dominio Multi Protocol Label Switching (MPLS).
mpls-dominio
I pacchetti però partono dai router degli utenti senza
intestazione MPLS, ma solo con i dati del protocollo del
terzo livello. Avremo degli appositi router situati alla
frontiera della backbone MPLS che aggiungono l’etichetta
MPLS in base ai dati del terzo livello ed instradano il
pacchetto nella backbone. I normali LSR invece solitamente
non fanno uso dell’header del protocollo di terzo livello. Il
percorso seguito da un pacchetto attraverso più LSR è
detto LSP (Label Switched Path ).

Pacchetto MPLS.
mpls-label
Ora un po' di teoria del routing: in una rete senza
connessione, come la rete IP, il cammino seguito da un
pacchetto tra la sorgente e la destinazione viene
determinato mediante la composizione di operazioni di
instradamento elementari ed indipendenti eseguite dai
router che sono attraversati dal pacchetto. Ogni router
sceglie il router successivo verso cui rilanciare il pacchetto.
Tale scelta è eseguita esaminando l’header del pacchetto e
accedendo ad una tabella di instradamento che è
aggiornata mediante l’utilizzazione di un protocollo di
instradamento. Si tratta della tabella Router Information
Base (RIB) introdotta a pagina rib . La scelta del next-hop
operata da un router può essere modellata come la
concatenazione di due funzioni distinte:
1. la suddivisione dell’insieme dei
pacchetti da rilanciare in una serie di sottoinsiemi
distinti, denominati FEC (Forwarding Equivalent Class
);
2. l’associazione di una FEC ad uno
specifico next-hop.
Secondo questo modello, i pacchetti appartenenti ad una
stessa FEC saranno rilanciati da un router verso lo stesso
nexthop. In particolare, in una rete IP, un router
classificherà due pacchetti, che recano due indirizzi di
destinazione diversi A e B, come appartenenti alla stessa
FEC se nella tabella di instradamento del router esiste un
prefisso X per cui tale prefisso rappresenta la
corrispondenza di lunghezza maggiore (longest match ) per
entrambi gli indirizzi A e B. In questa visione, ogni router
esegue, indipendentemente dagli altri, la propria
classificazione dei pacchetti in FEC e quindi due pacchetti
che sono classificati come appartenenti alla stessa FEC in
un router possono appartenere a FEC diverse in un altro
router. Il protocollo MPLS agisce in modo diverso: così
come definito nel RFC 3031 il protocollo MPLS assegna
una FEC ad un pacchetto una volta per tutte, al momento in
cui il pacchetto entra in una rete MPLS. La FEC assegnata
al pacchetto è codificata in un’etichetta (label ), di
lunghezza breve e fissa, trasportata nell’header del 6
pacchetto stesso. Quando il router attraverso cui il
pacchetto è entrato in una rete MPLS rilancia il pacchetto,
questi assegna al pacchetto il valore della label che sarà
utilizzata dal router successivo per effettuare la
commutazione. Quando un pacchetto entra in un router, la
label è utilizzata infatti come indice per l’accesso diretto ad
una tabella che conterrà il valore del next-hop e il valore
della nuova etichetta. La vecchia etichetta è sostituita con
la nuova e il pacchetto è rilanciato verso il router
successivo. E’ il caso di sottolineare che una volta che ad
un pacchetto sia stata assegnata una label, la
commutazione del pacchetto stesso è effettuata
esaminando esclusivamente la label senza tenere conto del
valore degli altri campi dell’header IP.

Label Switching Router (LSR) e modalità di definizione


delle label

Nella sezione precedente è stato definito il concetto di FEC


come un insieme di pacchetti IP che devono essere trattati
da un router nello stesso modo, ad esempio che devono
essere rilanciati verso lo stesso next-hop e appartenenti
alla stessa classe di servizio. In MPLS ad ogni FEC è
assegnata una label che sarà utilizzata dai router per
eseguire la funzione di commutazione dei pacchetti. Un
router che supporta la tecnica MPLS è denominato Label
Switching Router (LSR) e la tipologia di commutazione è
denominata in generale come label switching. Un dominio
di rete MPLS è formato quindi da un insieme di LSR
direttamente connessi tra loro. Il traffico entrante ad un
dominio MPLS può provenire sia da reti esterne al dominio,
quali ad esempio le reti locali d’utente, sia da router IP
tradizionali appartenenti a sezioni di rete IP che non
supportano la tecnologia MPLS come esemplificato in
figura mpls-dominio . Un LSR che connette un dominio
MPLS con altri nodi che sono all’esterno del dominio è
detto Edge LSR, mentre un LSR che è connesso solo ad
altri LSR è detto Core LSR. Una label è quindi un
identificatore di lunghezza fissa che è utilizzato per
identificare una FEC. Una label ha validità locale, ciò
significa che l’associazione tra FEC e uno specifico valore
di una label è valida solo su una tratta di rete, la stessa
FEC può essere quindi identificata da label diverse su tratte
di rete diverse.

LSP tunnel

Un Label Switched Path può essere utilizzato per la


creazione di tunnel all’interno di reti IP. Se un tunnel IP è
realizzato mediante un LSP MPLS allora l’LSP è detto LSP
Tunnel. Si distinguono due tipi di LSP tunnel:
1. hop-by-hop routed LSP tunnel sono realizzati mediante
hop by hop routed LSP, tali tunnel seguono all’interno
del dominio MPLS i cammini indicati dai protocolli di
instradamento e sono indicati con il termine Uniform
Model LSP;
2. explicit routed LSP tunnel sono realizzati mediante
explicitly routed LSP, di
conseguenza, i percorsi seguiti da tali LSP nel dominio
MPLS possono essere diversi rispetto a quelli indicati
dal protocollo di instradamento e decisi in base a
considerazioni e strategie alternative, tali tunnel sono
indicati con il termine Pipe Model LSP.
Ai fini di questo testo la nostra introduzione al protocollo
MPLS si ferma qui. Per chi volesse approfondire il tema
consigliamo l'ottima dispensa prodotta da Marco Listanti del
Dipartimento INFOCOM dell'università "La Sapienza" di
Roma disponibile al link http://bit.ly/2F0SrFl . Al MUM 2009
a Praga è stato presentato un interessante talk dal titolo
"MikroTik RouterOS Introduction to MPLS" che declinava il
protocollo MPLS con i prodotti Mikrotik. Le slide sono
disponibili al link http://bit.ly/2GRW1Eq .

VPLS (Virtual Private LAN Service)


Chi è familiare con i servizi che i Service Provider offrono
sulle loro reti IP+MPLS, saprà che tra questi uno dei più
interessanti è il servizio VPLS (Virtual Private LAN Service),
che è un servizio di tipo Multipoint-to-Multipoint che
consente l’emulazione di LAN Ethernet su una rete IP +
MPLS. Da un punto di vista logico, il servizio VPLS può
essere visto come un servizio che consente di emulare
switch Ethernet. Ad esempio, collegare N router dispersi
geograficamente con un servizio VPLS equivale a collegare
i router localmente a un switch Ethernet con cavi straight-
through. I CE (Customer Edge), ossia i dispositivi del
cliente che si interfacciano alla rete del Service Provider,
possono essere un qualsiasi dispositivo che genera trame
Ethernet tagged e/o untagged (router o switch Ethernet o
Host), e il collegamento tra CE e i router della rete dell’ISP
(router PE) può essere in qualsiasi tecnologia (es. Ethernet
back-to-back, Ethernet over SONET/SDH utilizzando
l’incapsulamento GFP, Ethernet over ATM utilizzando AAL5
(RFC 2684), ecc. ). Il modello di servizio assomiglia molto
al classico servizio L3VPN su reti IP + MPLS, con la
sostanziale differenza che tra i siti L3VPN vengono
trasportati pacchetti IP e la rete dell’ISP partecipa al routing
inter-sito, mentre tra siti VPLS vengono scambiate trame
Ethernet (tagged o untagged). Ciò consente in teoria di
scambiare anche pacchetti di Livello 3 che non siano IP,
anche se questo in realtà non è considerato più un
vantaggio importante delle VPLS, poiché ormai tutte le
applicazioni si poggiano sull’architettura TCP/IP. Dal punto
di vista fisico, il modello di funzionamento è simile a quello
delle L3VPN, con alcune differenze sostanziali. Per ciascun
cliente, vengono create sui PE dove sono attestati i siti,
delle istanze L2 Ethernet virtuali dette VSI (Virtual Switch
Interface). Ciascuna VSI può essere vista come un insieme
di due elementi: una MAC table (di solito indicata come VFI,
Virtual Forwarding Instance), e un insieme di interfacce
Ethernet fisiche o logiche che formano un dominio
broadcast (di solito indicato come Bridge Domain). Le
interfacce di accesso dei CE sui PE (attachment circuit)
vengono associate alla VSI appropriata via configurazione.
Le VSI devono emulare tutte le funzioni degli switch
ethernet:
Flooding: inviare a tutte le altre VSI della stessa VPLS
le
trame con indirizzi MAC destinazione Broadcast, o
Multicast o Unicast ma sconosciuti (il cosiddetto traffico
BUM, Broadcast-Unknown-Unicast-Multicast).
MAC address learning: creare automaticamente le
associazioni .
MAC address limiting: porre un limite al numero delle
associazioni
presenti in una VFI.
MAC Address aging: assegnare un tempo di vita a
ciascun
entry nella VFI.
Loop prevention: evitare il fenomeno dei Broadcast
Storm.
Ricordiamo che nelle reti switched ethernet, questa
funzione è svolta dal protocollo Spanning Tree.
Forwarding: utilizzo degli entry creati per inoltrare
traffico LAN/VLAN.
Per ciascuna VPLS, viene realizzata una maglia completa
di pseudowire tra i PE dove sono attestati i siti della VPLS;
uno pseudowire emula un collegamento punto-punto
all’interno del quale è possibile trasportare trame di Livello
2 qualsiasi, in questo caso trame Ethernet. Il perché vi sia
bisogno di una maglia completa di pseudowire è legato al
trasporto del traffico BUM, cioè al traffico Broadcast,
Unknown-Unicast e Multicast.
Architettura per il test delle performance.
vpn-test
Ma MPLS e VPLS sono interessanti anche per piccole
architetture in quanto sono molto efficienti. Se si considera
l'architettura di figura vpn-test utilizzando come hardware
delle RouterBoard RB1000 allora la tabella table:tunnel-
performance che raccoglie i test di performance evidenzia i
protocolli vincenti.
64 byte 512 byte
pps pps
Bridge 414.000 359.000
MPLS 410.000 358.000
VPLS 332.500 301.000
Routing 236.000 229.700
EoIP 190.000 183.900
Test di performance.
table:tunnel-performance

MPLS e VPLS con Mikrotik RouterOS

Si ricorda che affinché sia presente il menù MPLS deve


essere installato ed attivo il package MPLS come in figura
mpls-package .
Pacchetto MPLS.
mpls-package

Laboratorio

Per questo laboratorio sono necessari due router dotati di


interfaccia wireless e due pc.
Tunnel VPLS
L'obiettivo di questo laboratorio è realizzare l'infrastruttura
di figura mpls-tunnel utilizzando MPLS. Questo approccio
ha i seguenti vantaggi:
il tunnel VPLS è circa il 60\% più veloce e con meno
sovraccarico di un tunnel EoIP,
nei bridge WDS con protocollo 802.11n la velocità è
limitata dal protocollo ma non nel caso MPLS.

Tunnel VPLS in un ponte radio.


mpls-tunnel
Per comodità didattica questo laboratorio è disponibile in
due versioni: attraverso l'interfaccia grafica di WinBox
oppure attraverso i comandi del terminale.
{Versione con WinBox}
1. Si imposti il ponte radio come consueto con un bridge
WDS.
2. Come primo passo si abiliti LDP (Label Distribution
Protocols) su entrambi i router mediante il menù
MPLS > MPLS > LDP Interface > LDP Setting :
3. Usando il menu MPLS > MPLS > LDP Interfaces
si aggiunga l'interfaccia da utilizzare
per le connessioni VPLS. Il transport address può
essere vuoto.

4. Dopo qualche secondo si controlli lo stato della


connettività LDP in MPLS > MPLS > LDP Neighbor
:
D=Dinamica, O=Operativa
5. Si aggiunga una nuova interfaccia VPLS usando il
menù MPLS > VPLS > VPLS .
L'indirizzo da indicare nel campo remote peer è
l'indirizzo ip dell'altro estremo del ponte radio

6. Dopo qualche secondo si controlli come si è modificato


lo stato della connettività LDP in MPLS > MPLS >
LDP Neighbor :
D=Dynamic, O=Operational, T = Transport, V=VPLS
Active
7. Si crei una interfaccia bridge e si aggiungia l'interfaccia
vpls e ether1 alle porte.

8. Si controlli il corretto funzionamento attraverso il ping


tra i client .
{Versione con terminale}
1. Carichiamo le configurazioni sul router AP e
successivamente sul router station:
{AP}
/system identity set name=AP
# Configurazione dell'access point wireless (AP)
/interface wireless
set wlan1 disabled=no ssid=MPLS frequency=5180
band=5ghz mode=bridge
# Configurazione dell'indirizzo IP
/ip address
add address=172.16.0.1/30 interface=wlan1
# Abilitazione LDP
/mpls ldp
set enabled=yes lsr-id=172.16.0.1 transport-
address=172.16.0.1
/mpls ldp interface
add interface=wlan1
# Configurazione del tunnel VPLS
/interface vpls
add name=vpls1 remote-peer=172.16.0.2 vpls-id=1:1
disabled=no
# Aggiunta del bridge e delle porte
/interface bridge add name=bridge1
/interface bridge port
add bridge=bridge1 interface=ether1
add bridge=bridge1 interface=vpls1

{station}
/system identity set name=station
# Configurazione dell'access point wireless
(station)
/interface wireless
set wlan1 disabled=no ssid=MPLS band=5ghz
mode=station
# Configurazione dell'indirizzo IP
/ip address
add address=172.16.0.2/30 interface=wlan1
# Abilitazione LDP
/mpls ldp
set enabled=yes lsr-id=172.16.0.2 transport-
address=172.16.0.2
/mpls ldp interface
add interface=wlan1
# Configurazione del tunnel VPLS
/interface vpls
add name=vpls1 remote-peer=172.16.0.1 vpls-id=1:1
disabled=no
# Aggiunta del bridge e delle porte
/interface bridge add name=bridge1
/interface bridge port
add bridge=bridge1 interface=ether1
add bridge=bridge1 interface=vpls1

2. Si controlli il corretto funzionamento:

[admin@AP] /mpls ldp neighbor> print


Flags: X - disabled, D - dynamic, O - operational,
T - sending-targeted-hello, V - vpls
# TRANSPORT LOCAL-TRANSPORT
PEER ADDRESSES
0 DOTV
172.16.0.2 172.16.0.1 172.16.0.2:0 172.16.
0.2
[admin@AP] /mpls forwarding-table print
Flags: L - ldp, V - vpls, T - traffic-eng
# IN-LABEL OUT-
LABELS DESTINATION INTERFACE
0 expl-null
1 V 18 vpls1

3. Si verifichi che il tunnel VPLS è correttamente stabilito:

[admin@AP] /interface vpls> monitor vpls1 once


remote-label: 17
local-label: 18
remote-status:
transport-nexthop: 172.16.0.2
imposed-labels: 17

4. Si controlli il corretto funzionamento attraverso il ping


tra i client.
Se si desidera approfondire l'argomento sempre l'ottimo
Tomas Kirnak al MUM 2013 ha tenuto un talk dal titolo
"MPLS for ISPs – PPPoE over VPLS MPLS, VPLS,
PPPoE" le cui slide sono disponibili al link
http://bit.ly/2VrgCCB .

Schemi e tabelle utili


«...con le stesse scarpe camminare per diverse strade o
con diverse scarpe su una strada sola.» Fiorella Mannoi a

Schema a blocchi del flusso dei


pacchetti
packet-flow

Differenze tra Cisco IOS e Mikrotik


RouterOS
Routing generico

Cisco IOS Mikrotik RouterOS


Per coppia di
Per coppia di
FIB load indirizzo src. e dst.
indirizzo src. e dst.
Balancing (flush ogni 10
oppure per pacchetto
minuti)
Equal CostMulti Aggiungere rotte Aggiungere una
Path (ECMP) multiple con la stessa sola rotta indicando
destinazione, la più gateway.
stessa distanza ma
con diversi gateway.
Disabilitata per
Ricerca default, può essere
ricorsiva del Abilitata. abilitata usando il
nexthop parametro Target
Scope della rotta.
Implicitamente
Implicitamente
negato alla fine di
Comportament permesso alla fine
ogni componente
o nel filtraggio del modulo di
(access-list,prefix-list,
delle rotte filtraggio (Routing
filter-list, route-
Filters).
map,...).

OSPF

cisco-routeros-ospf
Cisco IOS Mikrotik RouterOS
L'indirizzo IP più alto
dell'interfaccia di L'IP più basso di
Router ID loopback attiva, in qualsiasi interfaccia
alternativa l'IP più alto attiva.
dell'interfaccia attiva.
Costo fisso pari a 10
Costo di
per ogni link ma
default Dipendono dal tipo di
modificabile nella
per link.
configurazione di
interfaccia
OSPF.
Hello ad intervalli fissi di
10 secondi, Dead ad
Tempi di Dipendono dal tipo di
intervalli fissi di 40,
OSPF rete.
modificabili nella
configurazione di OSP.
Stub Area Type 3 LSA per default Per le Totally Stubby
sono annunciate nelle Area stesso
Stub Area by default, se comportamento di IOS.
non configurate come Se si abilita l'opzione
Totally Stubby Area LSA “Inject Summary
LSAs” allora vengono
annunciati le LSA Type
3 nelle Stub Area
Si usa “Routing Filters”
Si usa il comando
per permettere/negare
"distribute-list" per
Filtraggio che delle rotte siano
permettere/negare
delle rotte installate nella RIB, ma
l'installazione di rotte
possono essere filtrate
dentro la RIB
solo LSA di Tipo 5.
Per default la subnet
mask dell'interfaccia di
rounting è forza ad Senza fare nulla è
Interfacci
essere /32; se si vuole annunciata qualsiasi
a di
una diversa subnet sottorete si indichi per
loopback
mask bisogna l'interfaccia di loopback.
impostare l'interfaccia
come "point-to-point"
Commando Cisco IOS Commando Mikrotik RouterOS
show ip ospf neighbor routing ospf neighbor print
show ip ospf interface routing ospf interface print
show ip ospf1 routing ospf instance print detail
show ip ospf database routing ospf lsa print
show ip route ospf ip route print where ospf=yes
show ip ospf rib routing ospf route print
show ip ospf border- routing ospf area-border-router
routers print
show ip ospf border- routing ospf as-border-router
routers print
Cisco(config)#router ospf1 routing ospf instance
Cisco(config-
/routing ospf instance set 0
router)#router-id
router-id=203.0.113.2
203.0.113.1
Cisco(config- /routing ospf network add
router)#network area=backbone
203.0.113.1 0.0.0.0 area 0 network=203.0.113.2/32
Cisco(config-
/routing ospf network add
router)#network
area=backbone
203.0.113.128 0.0.0.7
network=203.0.113.128/29
area 0
Cisco(config-
/routing ospf interface add
router)#interface
dead-interval=4s
GigabitEthernet0/0
Cisco(config-if)# ip ospf hello-interval=1s
network point-to-point interface=ether1
Cisco(config-if)# ip ospf
network-type=point-to-point
dead-interval 4
Cisco(config-if)# ip ospf
hello-interval 1

MPLS

Cisco IOS Mikrotik RouterOS


Multi Path
con Label No, solo il primo gateway
Distribution Sì viene usato nella tabella
Protocol di forwarding (MFIB)
(LDP)
Link Protection
MPLS Fast
(~50ms) Node Non supportato
Reroute
Protection
6PE, 6VPE,
L3VPN
MPLS
(Unicastand L3VPN (Unicast), VPLS
Applications
Multicast), AToM,
VPLS
Possibile l'uso nei Possibile solo nei router
MPLS
router P e PE se si PE. Infatti i router P non
QoSwith
utilizza Modular applicano nessuna
EXP bit
QoSCLI (MQC) politica ai pacchetti MPLS

Potrebbero piacerti anche