OSPF

Come funziona un protocollo Link State

Ogni router nella rete:

●​ Invia/riceve Hello messages in ogni suo link locale per scoprire i routers
vicini
●​ Invia un annuncio identificando se stesso, i suoi link direttamente
connessi, e i router vicini direttamente connessi
●​ Ogni router che riceve un annuncio salva una copia nel proprio database,
e lo inoltra ai downstream
●​ Quando un router riceve un annuncio calcola le rotte

Le informazioni vengono salvate nel Link State database (LSDB)

Un prerequisito alle operazione del link state protocol è che i router siano
identificati univocamente nella rete da un router id (dal valore di 32 bit), di
seguito le opzioni usate per assegnare questo router id

1.​ Se configurato manualmente, utilizza questo valore1

2.​ Se non configurato manualmente, viene assegnato l’ip più basso
configurato nella loopback
3.​ Se non c’è nessun indirizzo nella loopback, viene assegnato l’indirizzo più
basso configurato nelle interfacce
4.​ Se nessun ip è configurato, allora OSPF non può partire

Per identificarsi e scoprire i vicini, un link state protocol utilizza gli Hello Message
che utilizzando IP protocol 89 e sono inviati all’indirizzo [Link]. Gli Hello
message includono:

●​ Router ID di chi genera il messaggio

●​ Informazioni come timer setting, parametri interfacce ed informazioni
delle autenticazioni

Una volta instaurata l’adiacenza gli hello message vengono utilizzati come
keepalive, e vengono trasmessi ad intervalli regolar (Hello interval)i, se un
router non riceve gli hello, dopo un determinato periodo mette down l’adiacenza
(dead interval). Per essere sicuri che gli hello non vengano inoltrati dal vicino,
viene posto il TTL ad 1.

1
Per configurarlo si utilizza set routing-option router-id

1
I parametri Hello Interval e dead interval possono essere configurati con i
comandi:

set protocols ospf area [Link] interface fe-0/0/1 hello-interval 2

set protocols ospf area [Link] interface fe-0/0/1 dead-interval 8

NB: Se non configurati hanno i seguenti default Hello Time 10sec (per broadcast
e p2p) 30sec (per reti non broadcast multiple access (NBMA), il dead interval ha
come default 40sec (per broadcast e p2p) 120sec (per reti non broadcast
multiple access (NBMA)

Tipi di Messaggi
I Messaggi OSPF condividono un header di 24 ottetti. Questo header server al
router destinatario a valutare se un pacchetto è valido o no:

Questo header contiene

●​ Version (1 ottetto) indica la versione ospf utilizzata (di default 2)
●​ Type (1 ottetto) indica il tipo di pacchetto ed ha questi possibili valori:
○​ 1 Hello Packet
○​ 2 Database descriptor
○​ 3 Link state request
○​ 4 Link state update
○​ 5 Link state acknowledgment
●​ Packet length (2 ottetti) indica la lunghezza dell’intero pacchetto OSPF
●​ Router ID (4 ottetti) Il router ID del router che sta inviando il pacchetto
●​ Area ID (4 ottetti) Contiene il 32-bit area ID
●​ Checksum (2 ottetti) contiene il checksum dell’intero pacchetto ad esclusione dei
64-bit del campo authentication
●​ Authentication type indica il tipo di autenticazione, e può contenere i seguenti
valori:
○​ 0 Nessuna autenticazione
○​ 1 password

2
 ○​ 2 MD5
●​ Authentication (2 ottetti) contiene la i dati di autenticazione

Gli OSPF messages e gli LSA sono di 32 bit, OSPF utilizza 5 tipi di messaggi:

●​ Hello
●​ Database Description (DD)
●​ Link state Request
●​ Link state Acknowledgement
●​ Link state update

Hello Messages
L’Hello packet viene utilizzato per stabilire e mantenere l’adiacenza, è inviato a tutti tramite
l’indirizzo mulicast [Link] sia per connessione broadcast che point-to-point.

Database Description Packet

Dopo aver scoperto i propri vicini, il router forma l’adiacenza, questa adiacenza richiede che
ogni router invia le informazioni del proprio local database. Per far ciò il router utilizza il
Database Description (DD). In questo pacchetto il router sommarizza il local database
inviando degli LSA (Link-State Advertisement) Header. Il router che riceve questo pacchetto
analizza questa header per capire se deve aggiornare il database

3
Link-State Request Packet
Durante il processo di sincronizzazione del database, il router potrebbe capire che il proprio
database non è aggiornato. Quindi utilizzato il pacchetto Link-State Request per richiedere
uno o più LSA (NB nello stesso pacchetto possono essere richiesti più LSA)

Link-State Update Packet

Le informazioni del Link-State Database sono popolate attraverso i Link State
Advertisement (LSA). Ogni LSA contiene routing, metric ed informazioni sulla topologia di
una porzione di network OSPF. Questo pacchetto viene floodato su tutto il network finchè
ogni router riceva una copia, o può essere utilizzato in risposta ad un Link-state request.

4
Link-State Acknowledgment Packet
L’affidabilità del protocollo OSPF prevede che ad ogni Link-State Update packet si risponda
con un Link-State Acknowledgment packet

Adiacenza OSPF
Durante il processo di formazione dell’adiacenza, due router attraversano diversi stati prima
di diventare neighbors.
DOWN Down è lo stato iniziale, può essere in questo stato quando si configura per la prima
volta OSPF e non ha ricevuto ancora nessun hello packet, oppure non ha ricevuto un hello
packet durante il dead interval e metto down l’adiacenza
Init Questo avviene quando un router riceve un hello packet, ma il proprio Router ID non è
contenuto nel pacchetto (guarda header Hello packet). Questo significa che non c’è ancora
comunicazione bidirezionale.
Attempt stato valido solo per il Non-Broadcast Multi-Access (NBMA) Network. Significa che
un hello packet non è stato ricevuto da un neighbor ed il local router invia un unicast hello
packet al neighbor entro l’hello interval.
2-way indica che il local local router riceve un hello packet con all’interno il proprio router-id.
Significa che la comunicazione bidirezionale è attiva quindi i due router sono OSPF
neighbors
EXStart in questo stato si stabilisce chi sarà il router incaricato del processo di
sincronizzazione del database. Il router con il più alto router ID sarà il master
Exchange in questo stato si scambiano i Database description (DD) packet

5
Loading Se un router ha bisogno di aggiornare la propria tabella allora passa allo stato di
loading ed invia un link-state request packet.
Full i due router hanno completato il processo di sincronizzazione del link-state database

AREA
Le aree OSPF sono state definite per limitare il flood LSA, ogni area ha un univoco ID di
32 bit rappressato in ottetti (esempio di area ID [Link]), molti preferiscono
utilizzare un numero intero (es. area 0), le aree possono essere di tipo2:

●​ BACKBONE (area 0) è l’area che forma il core del network, collega a

tutte le aree non backbone e redistribuisce le informazioni di router tra
queste
●​ STUB i router dell’area contengono tutte le rotte tranne le external, per
queste ultime viene creata una default
●​ TOTALLY STUBBY i router dell’area contengono solo le rotte della propria
area ed una default.
●​ NOT SO STUBBY (NSSA)3 è un’area stubby che permette alcune solo
alcune rotte external.
●​ TOTALLY NOT SO STUBBY:

OSPF classifica le rotte in:

●​ Inet-area o internal: rotte che sono generate nell’area e destinate nella

stessa area.
●​ Inter-area o summary routes: rotte generate da altre area
●​ External router: Rotte apprese da altri protocolli ed importati in OSPF

I router di una Stub area nel loro Link-State database contengono gli LSA di tipo 1 (router
lsa) che contengono le informazioni della propria area, e gli LSA di tipo 3 (Network summary

2
Se si crea una una rete OSPF con una singola o con due aree OSPF non è necessaria
un’area [Link], anche se è best practice crearla
3
Non si può configurare un’area come NSSA e STUB contemporaneamente

6
LSA) che contengono le informazioni di tutte le rotte internal del dominio OSPF, l’abr non
invia gli lsa type 4(rotte per gli ASBR) e type 5 (rotte esterne) per queste rotte viene creata la
default4

In una totally stubby area i router dell’area contengono solo le rotte della propria area
(Type 1 e type 2) ed una default (importata con LSA di tipo3) .

Un Not so Stubby area (NSSA) è un’area stubby che permette le rotte interne (type 1 o
type 2), le rotte inter-area vengono trasportate con LSA di tipo 3, permette rotte esterne
(LSA di tipo 7), e può avere anche una default che viene importata con LSA di tipo 7.

Una Totally Not So Stubby Area è un’area stubby che permette le rotte interne (type 1 o
type 2), permette rotte esterne (LSA di tipo 7), e può avere anche una default che viene
importata con LSA di tipo 3 (anche se possiamo importarla con lsa di tipo 7. La differenza
con NSSA è che la totally NSSA ha solo la default.

4
in juniper la creazione della default non è automatica

7
In una rete NSSA due router formano un’adiacenza se i bits N/P matchano

Ruoli Router
I ruoli e le responsabilità di un router dipendono dalla loro posizione, i router di
dividono in:

●​ Internal sono router che hanno tutte le interfacce all’interno di una sola
area
●​ Backbone router sono router che hanno almeno un’interfaccia in area 0
●​ Area Border Router (ABR) sono router connessi a più area con almeno
un’interfaccia nell’area 0.
●​ Autonomous System Boundary Router (ASBR) inietta rotte apprese
da protocolli esterni all’interno dell’OSPF

Nei segmenti Broadcast esistono due funzioni Designed Router (DR) e Backup
Designed Router (BDR), queste due funzioni nascono per ridurre il numero di
LSA floodati, ma vediamoli più in dettaglio.

Supponiamo invece che 5 router condividano lo stesso segmento network, ogni

router del segmento vede l’hello packet, perchè inviato all’indirizzo [Link]
(ALLSFPRouter), quindi all'interno del link si formeranno 10 adiacenze.

Questa configurazione però ha un duplice problema: primo ogni router del link
invia le stesse informazioni al resto della rete OSPF, secondo ogni router flooda
LSA agli altri router del link.

Per evitare questi problemi si utilizza il Designed Router (DR), ogni segmento
network elegge un DR, ogni DR stabilisce l’adiacenza con il resto dei router, i
router del segmento invieranno le informazioni al DR utilizzando l’indirizzo
[Link] (AllDRRouter). Il DR flooda dei LSA TYPE 2 (Network LSA) al resto

8
della rete. Oltre al DR viene eletto anche Backup Designed Router (BDR). Il
BDR resta in ascolto sulla [Link], forma adiacenze con tutti i router del
segmento network e monitora il DR.

L’elezione del DR avviene quando nessun DR è stato eletto, questo si capisce

perchè nell’hello packet non viene indicato nessun DR address. L’elezione del DR
si basa su Router Priority e Router ID. Inizialmente si sceglie il router con
Priorità più alta, a parità di priorità viene scelto quello con ID più alto. Di solito
quando si forma un segmento network, ed ancora non è stato eletto alcun DR, il
tempo di attesa (detto WaitTimer) è settato allo stesso tempo del dead
interval per essere certi che tutti i router del segmento ricevano l’hello packet5.

NB: Una volta eletti DR e BDR non sono più cambiati a meno che uno dei due
esca dalla rete. Anche se un router con priorità più alta viene inserito nel
segmento, non diventa DR finchè non cadono DR e BDR, in pratica se cade il DR,
il BDR diventa DR ed il nuovo router diventa BDR per diventare DR deve
attendere che il BDR cada. Di default la priorità è 128. In un DRother le sessioni
ospf sono full solo verso DR e BDR, mentre tra i DRother restano in 2 way

LSA
Gli LSA vengono utilizzati per creare LSDB, ne esistono di vari tipi ed hanno
funzioni diverse:

●​ ROUTER LSA (TYPE 1) contengono le informazioni locali dei router,

come link connessi al router, metriche dell’interfacce e la capacità del
router. Questi LSA vengono scambiati all’interno dell’area, se un router ha
diverse aree avrà diversi router LSA
●​ NETWORK LSA (TYPE 2) questi LSA vengono floodati nella rete dal DR e
contengono le informazioni del segmento di broadcast
●​ NETWORK SUMMARY LSA (TYPE 3)sono gli LSA scambiati tra le aree
●​ ASBR SUMMARY LSA (TYPE 4) vengono floodati dagli ABR nella propria
area per comunicare le network degli ABRS
●​ AS EXTERNAL LSA (TYPE 5) servono a trasportare rotte non ospf
(esempio le statiche o bgp), vengono floodati dagli ABR in sostituzione agli
LSA TYPE7

5
Quindi prima di eleggersi DR il router attenderà un tempo pari al dead interval

9
 ●​ NSSA EXTERNAL LSA (TYPE 7) vengono floodati dall’ASBR nella propria
area, per trasportare le rotte esterne. Questi LSA vengono riannunciati
nelle altre aree dagli ABR con degli LSA TYPE7

Applicazioni pratiche aree e lsa

LSA type 1 sono scambiati con tutti i router che fanno parte della stessa area, se un router
fa parte di aree diverse avrà un LSA type 1 per ogni area.
Quando colleghiamo due router ognuno di essi genera a LSA type 1 e l’aggiunge al proprio
database. Dopo che i due router diventano adiacenti allora floodano LSA a tutti i vicini.
Questi LSA descrivono tutte le network connesse incluse le interfacce di loopback.

10
Supponiamo invece che 5 router condividano lo stesso segmento network, ogni router del
segmento vede l’hello packet, perchè inviato all’indirizzo [Link] (ALLSFPRouter), quindi
all'interno del link si formeranno 10 adiacenze.

Questa configurazione però ha un duplice problema, primo ogni router del link invia le stesse
informazioni al resto della rete OSPF, secondo ogni router flooda LSA agli altri router del
link.
Per evitare questi problemi si utilizza il Designed Router (DR),Il DR flooda dei LSA TYPE 2
(Network LSA) al resto della rete.
Tra le aree le informazioni di routing vengono scambiate attraverso i network summary
LSA (LSA Type 3) .

11
Per trasportare rotte non ospf (esempio delle statiche) si utilizzano gli AS External LSA
(type code 5) . Oltre alle rotte esterne deve essere anche conosciuto anche l’indirizzo
dell’ASBR.

Nell’esempio in figura Carbenet è L’ASBR è genera LSA type 5 per annunciare le net della
server farm. Ma L’area 10 e l’area 22 non conosco l’indirizzo di Carbenet, quindi Sangria e
Chardonnay utilizzano degli ASBR summary LSA (type 4), per comunicare le net ASBR
nella propria area.

External Metric
In OSPF la metrica assegnabile ad un prefisso esterno può essere di due tipi:

●​ Type 1 External (E1), in questo caso la metrica tiene in considerazione il

costo per arrivare all’ASBR che annuncia il prefisso, più il costo che ha
l’ASBR ha per raggiungere il prefisso.
●​ Type 2 External (E2), in questo caso la metrica tiene in considerazione
solo costo per arrivare all’ASBR.

Di default OSPF utilizza metriche di tipo 2, entrambe le metriche possono

convivere, in questo caso Type 1 è preferito, mentre nel caso in cui venga
utilizzata la stessa metrica viene scelto il percorso con la metrica minore

Per configurare il tipo di metrica (operazione effettuabile sono su aree nssa6) si

utilizza il comando

6
le NSSA sono le uniche aree che permettono di avere prefissi acquisiti fuori OSPF

12
set protocol ospf area area_id nssa default-lsa metric-type {1 o 2}

Virtual Link
OSPF offre un tool chiamato VIRTUAL LINK che permette una connessione
logica di un ABR con l’area backbone anche quando non esiste una connessione
fisica. Virtual link ha due applicazioni:

●​ Connettere l’area backbone ad un’area che non è direttamente connessa

al backbone
●​ Evitare o riparare partizioni dell’area backbone

Per utilizzare il virtual link bisogna ricordare che:

●​ Il virtual link deve essere configurato attraverso una sola area, L’ABR ed il
router di terminazione del link devono far parte della stessa area
●​ Il costo del virtual link non può essere configurato. Il costo è dato dal
costo intra-area dei due ABR
●​ Virtual link non può essere configurato un’area stub

Supponiamo che vogliamo collegare l’area 3 alla backbone (guarda immagine

sotto)

utilizziamo il comando
set protocols ospf area [Link] virtual-link neighbor-id [Link] transit-area
[Link]

in questo comando specifichiamo il neighbor-id (che è il router id), e l’area che si collega
attraverso il link.
Facendo uno show ospf interface o show ospf neighbor

13
Compare l’interfaccia vl-neighbor-id
Il virtual link può essere utilizzando anche durante la fusione di due reti OSPF per creare
l’adiacenza tra le due aree backbone

Configurazione
Per configurare OSPF in un router bisogna inserire l’interfaccia logica all’interno del menù
protocol ospf area (dove area può essere un numero decimale, che poi viene tradotto in 4
ottetti, o direttamente i 4 ottetti)
Esempio di configurazione multiarea
[edit protocols ospf]
root@R2# show
area [Link] {
interface ge-0/0/0.07;
interface lo0.0 {
passive;
}
}
area [Link] {
interface ge-0/0/2.0 {
priority 20;
}
}

Opzionale di può configurare il numero di rotte da annunciare con il comando

prefix-export-limit (di default nessun limite ) da configurare nel menù OSPF set
protocols ospf prefix-export-limit 100000, il graceful restart in modo che il local
router avverte il peer prima di riavviare la sessione ed il BFD.
Può capitare di voler instaurare un’adiacenza multiarea, ad esempio si vuole condividere un
link a grande capacità fra 2 ABR8

7
Se sull’interfaccia sono configurati 2 ip vengono annunciati in OSPF entrambi gli ip, un
altro modo per configurare OSPF è inserire l’ip invece che l’interfaccia
8
Di Default un’interfaccia appartiene ad una sola area

14
Esempio di configurazione dei due ABR
ABR1
set interfaces so-0/0/0 unit 0 family inet address [Link]/24
set routing-options router-id [Link]
set protocols ospf area [Link] interface so-0/0/0
set protocols ospf area [Link] interface so-0/0/0 secondary

ABR2
set interfaces so-1/0/0 unit 0 family inet address [Link]/24
set routing-options router-id [Link]
set protocols ospf area [Link] interface so-1/0/0
set protocols ospf area [Link] interface so-1/0/0 secondary

Un altro esempio perchè utile configurare una multi-area-adjacency è:

Prendiamo in considerazione la rete sotto

15
Quando tutti i link sono up il traffico tra R1 ed R3 fa 1 solo hop, ma se cade il link tra R1 ed
R3 allora siccome OSPF preferisce i percorsi intra-area rispetto inter-area il percorso
sarà R1→R4→R2→R3, ma configurando il link tra R1 ed R2 anche in area 100 con una
multi-area adjacency allora il percorso sarà R1→R2→R3.

NB: Quando definiamo un link in multi-adjacency il link segnato come secondary sarà
di default point to point

Nell’immagine prima vediamo che l’interfaccia ge-0/0/1.0 configurata in multi-adjacency

viene vista in Broadcast nell’area 0 (infatti nella conf non ‘ specificato p2p), ma p2p in area
100 (anche se non segnata in p2p nella conf)
Per configurare il router-id (che ha effetto su tutti i protocolli) si utilizza il comando
set routing-option router-id IP

Per configurare un’area come stub utilizziamo i seguenti comandi

16
set protocol ospf area 0.0.0.X (x diverso da 0) stub
Con questo comando indichiamo che l’area x è stub
Solo negli ABR configuriamo set protocol ospf area 0.0.0.X (x diverso da 0) stub
default-metric 10 con questo comando ai router viene annunciata la default con metrica y
ed opzionalmente possiamo utilizzare l’opzione no-summarization (da configurare sugli
ABR) per far si che ai router dell’area stub non vengono annunciati gli LSA di tipo 3 (network
summary LSA), in pratica così creiamo una totally stubby.
Il comando stub dice che nell’area non vengono annunciati LSA type 5
Ci sono alcune limitazioni:
●​ Non si può creare un virtual-link tra stub area
●​ una stub area non può contenere un AS boundary router (router di collegamento tra
as)
●​ l’area backbone ([Link]) non può essere stub
●​ non si può configurare un’area stub e not-so-stubby area (NSSA)

Nell’esempio precedente l’area 9 deve essere configurata come Not So Stubby

Area (NSSA) in quanto abbiamo delle rotte esterne (Customer Network).

per configurare un’area nssa si utilizza il comando

set protocol ospf area [Link] nssa

a cui possiamo aggiungere altre opzioni quali

●​ no-summaries che non fa annunciare dall’ABR gli LSA type 3 all’interno

dell’area NSSA. Se combinato con l’opzione default-metric solo le rotte
interne e la default vengono annunciate nell’area. Solo l’abr ha necessità
di questa opzione perchè è l’unico a creare lsa type 3
●​ default-lsa Serve a configurare L’ABR per generare la default dentro la
NSSA, puoi configurarlo con le opzioni
○​ default-metric Serve a specificare la metrica utilizzata per la
default.
○​ metric-type (opzionale) Specifica il tipo di metrica utilizzata per
le rotte esterne. Se Type 1 il costo equivale al costo interno + il
costo esterno. Se type 2 il costo assegnato alla rotta equivale al

17
 costo esterno. Di default junos utilizza type 2 e questo costo viene
assegnato all’AS boundary router (router di collegamento tra AS).
○​ type-7 (opzionale) permette gli LSA type 7 all’interno dell’area
NSSA., questa opzione è per l’interoperabilità copn router con
versioni di junos precedenti alla 5.0, dopo la 5 la default viene
inviata con LSA di tipo 3

18
Se un ABR è collegato a 2 NSSA differenti per default esporta gli LSA type 7 tra
le reti NSSA, se vogliamo evitare che l’ABR esporti gli LSA type 7 utilizziamo ilc

Di seguito il flooding degli LSA senza e con il comando no-nssa-abr

19
Per impostare l’autenticazione tra 2 router si utilizza il seguente comando

set protocols ospf area [Link] interface interfaccia authentication md5 key-id
(key-id è opzionale) key password
dove key-id è un numero da 0 a 255 se non specificato di default viene utilizzato
0.

Si possono configurare anche diverse chiavi che cambiano nel tempo

Per vedere se abbiamo configurato l’autenticazione possiamo utilizzare cil

comando show ospf interface detail

20
Se non è configurata alcuna autenticazione comparirà none, se utilizziamo
l’autenticazione simple comparirà password, mentre se utilizziamo MD5
(quella consigliata) comparirà MD5 e se configurato un time comparirà anche
da quando è attiva

Un altro comando opzionale (se non impostato di default è 100 Mbps) è il

comando reference-bandwidth che serve al calcolare il costo di un’interfaccia con
la formula

cost = ref-bandwidth/bandwidth

si setta con set protocol ospf reference-bandwidth banda

Di default la Lo0 ha metrica zero non viene associata nessuna banda, mentre
un’interfaccia qualsiasi può avere metrica che va da 1 a 65535

Per sommarizzare l’annuncio di alcune rotte di un’area non backbone si utilizza il

comando

set protocols ospf area area area-range network

Da configurare sugli ABR, esempio:

Supponiamo che tutte le loopback dell’area non backbone ([Link]) siano nella
[Link]/24, invece di annunciare tutti i singoli /32 possiamo annunciare l’intera
subnet configurando sugli ABR il comando

set protocols ospf area [Link] area-range [Link]/24

Se aggiungiamo l’opzione restrict invece blocchiamo LSA del prefisso9

9
Restrioct non fa override su area-range, se ad esempio mettiamo un restrict per un
prefisso che fa parte di un'area-range questo sarà comunque annunciato come
aggregato più grande

21
Se vogliamo, invece, importare in area 0 delle rotte external sommarizzare sugli
ABR collegati alle aree NSSA digitiamo il comando set protocols ospf area area-id
nssa area-range network

Anche in questo caso possiamo utilizzare l’opzione restrict per evitare di

annunciare LSA

Di Default OSPF non importa rotte apprese da altri protocolli, per importare o
esportare rotte non OSPF (esempio le statiche) in OSPF possiamo utilizzare il
comando

set protocol ospf import/export nome_policy

Esempio di export delle statiche in OSPF

user@host# show policy-options

policy-statement exportstatic1 {

term exportstatic1 {

from protocol static;

then accept;

NB: Se non specifichiamo nulla di default la rotta sarà importata come external
di tipo 2, possiamo digitare l’opzione external type 1 pe cambiare il tipo. Sia
per il tipo 1 che per il tipo 2 verrano creati degli LSA di type 5

22
user@host# show protocols ospf

export exportstatic1;

Possiamo limitare il numero di rotte redistribuite in OSPF con il comando

prefix-export-limit

In questo caso importiamo attraverso la policy redistribuite-isis un numero

massimo di 6 prefissi, se per errore viene superato questo limite allora non viene
esportato nessun prefisso

23
Di default le routing policy OSPF importa tutto e non esporta nulla,
inoltre le policy di import filtra solo le rotte esterne, le rotte internet non
vengono filtrate

Si possono cambiare anche le preference con il comando

set protocols ospf preference valore external-preference valore

esempio set protocols ospf preference 168 external-preference 169

Possiamo settare anche un solo valore

24
Comandi utili per il troubleshooting
show ospf interface
root@R2> show ospf interface
Interface State Area DR ID BDR ID Nbrs
ge-0/0/0.0 DR [Link] [Link] [Link] 1
lo0.0 DRother [Link] [Link] [Link] 0
ge-0/0/2.0 DRother [Link] [Link] [Link] 2

Dove
●​ Interface indica l'interfaccia configurata sul router
●​ State indica lo stato corrente che può essere
○​ BDR il local router è Backup Designated router
○​ DOWN l’interfaccia non è attiva
○​ DR il router è il Designed Router
○​ DRother il router non ne ne backup ne disegned
○​ PtToPt l’interfaccia è ptp
●​ Area indica l’id dell’area
●​ DR ID Indica il router ID del DR. Nel caso di PtP c’è scritto [Link]
●​ BDR ID Indica il router ID del BDR. Nel caso di PtP c’è scritto [Link]
●​ NBR Indica il numero di neighbors trovati
Con l’opzione detail vediamo anche alcune informazioni di configurazione

Show ospf neighbor

root@R2> show ospf neighbor
Address Interface State ID Pri Dead
[Link] ge-0/0/0.0 Full [Link] 128 38
[Link] ge-0/0/2.0 Full [Link] 128 33
[Link] ge-0/0/2.0 Full [Link] 30 32

Dove
●​ Address Indirizzo dell’interfaccia del neighbor
●​ Interface L’interfaccia dove ha trovato il neighbor
●​ State lo stato dell’adiacenza OSPF
●​ ID Router ID del neighbor
●​ PRI Priorità del neighbor
●​ Dead il tempo che rimane prima che il neighbor venga dichiarato non raggiungibile.
Ogni volta che si riceve un hello packet allora il tempo viene settato al valore di dead
interval

25
Con il comando clear ospf neighbor [neighboor-address] si cancellano le adiacenze
nel caso in cui specifichiamo il neighboor cancelliamo solo l’adiacenza con il vicino se non
specifichiamo l’indirizzo cancelliamo tutte le adiacenze.
Se non compare l’adiacenza allora possiamo avere 10 errori:
1.​ Interface type mismatch
2.​ Network mask (solo nelle multiaccess)
3.​ Hello interval
4.​ Dead interval
5.​ area type
6.​ area numbers
7.​ autenticazione
8.​ i router hanno lo stesso router ID
9.​ problemi di firewall
10.​o entrambi i router sono configurati come passive

Se lo stato si ferma in ex-start allora entrambi i router potrebbero avere lo stesso ip in

entrambi i lati.
Se si ferma in exchange allora potrebbe essere un problema di mtu

Con il comando show ospf database visualizziamo la link-state dabase, cioè vediamo tutti
gli LSA suddivisi per area.

ser@Shiraz> show ospf database

OSPF link state database, area [Link]
Type ID Adv Rtr Seq Age Opt Cksum Len
Router *[Link] [Link] 0x80000004 2965 0x2 0x3407 60
Router [Link] [Link] 0x80000004 2971 0x2 0xb58a 60
Router [Link] [Link] 0x80000008 2800 0x2 0x2f12 60
Router [Link] [Link] 0x8000000c 1328 0x2 0x6d4 108
Summary [Link] [Link] 0x80000005 728 0x2 0x3525 28
ASBRSum [Link] [Link] 0x80000006 128 0x2 0xf976 28
OSPF external link state database
Type ID Adv Rtr Seq Age Opt Cksum Len
Extern [Link] [Link] 0x80000034 306 0x2 0xe5da 36

26
Extern [Link] [Link] 0x80000034 5 0x2 0xdae4 36
Extern [Link] [Link] 0x80000033 1206 0x2 0xd1ed 36
Extern [Link] [Link] 0x80000033 907 0x2 0xc6f7 36

I campi sono:
●​ Type che indica il tipo di LSA, e può essere:
○​ Router Type 1 LSA
○​ Network Type 2 LSA
○​ Summary Type 3 LSA
○​ ASBRSum Type 4 LSA
○​ Extern type 5 LSA
○​ NSSA Type 7 LSA
●​ ID Indica L’ID dell’LSA è univoco e definisce LSA. Se c’è un * significa che è
ganerato dal router
●​ ADV RTR il router ID che genera LSA
●​ SEQ è il sequence number che determina LSA più recente
●​ AGE indica l’età dell’LSA, comincia da zero e cresce fino a 3600. Quando arriva a
3600 deve essere aggiornato
●​ OPT viene indicato il valore del campo option field del pacchetto Hello
●​ Cksum è il valore di checksum
●​ Len lunghezza dell’lsa

Digitando l’opzione extended (show ospf database extended) riusciamo a vedere anche il
bits (VEB) che rappresenta come acquisiamo il prefisso V sta per virtual (0x4) E sta per
external (0x2) B sta per border (0x1) possiamo trovare anche valori composti esempio 0x5
che indica border e virtual

Gli LSA OSPF vengono ricevuti e archiviati nel database dello stato dei collegamenti.
Questi dati sullo stato del collegamento possono essere visualizzati utilizzando il
comando show ospf database. L'algoritmo SPF viene eseguito su questo database e i
risultati vengono archiviati nel database dell'albero. Questo file può essere
visualizzato utilizzando il comando show ospf route. Il prefisso risultante e le

27
mappature del percorso vengono copiati nella tabella inet.0. Questi percorsi OSPF
possono essere visualizzati utilizzando il comando show route protocol ospf.

con il comando clear ospf database purge poniamo tutti gli age degli LSA a
3600 quindi devono essere tutti aggiornati.
Un altro comando utile è show ospf route, Digitando questo comando troviamo
anche l’indirizzo del neighboor, utilizzato come router-id, con next-hop l’indirizzo della
ptp dove viene instaurata l’adiacenza OSPF. Se ad esempio come router-ID il vicino
utilizza l’indirizzo di loopback (ma non setta la loopback in ospf) avremmo l’indirizzo di
loopback digitando show ospf route, ma non in show route ospf. Questo prefisso viene
segnato come type route e non ha notazione CIDR (/32)

possiamo aggiungere delle opzioni per filtrare i tipi di rotte

28
show ospf log mostra i log dei calcoli SPF (Shortest-path-first), questo comando viene
utilizzato per vedere se la rete è stabile infatti quando vengono effettuati diversi calcoli in
poco tempo significa che c’è qualche link che flappa

show ospf statistics mostra le statistiche dei pacchetti ricevuti ed inviati

29
Filtrando per error vediamo tutti gli errori

●​ Un area mismatches avviene quando due ruoter non hanno con la stessa area
configurata
●​ Un netmask mismatches si verifica quando un pacchetto di hello ricevuto su
un'interfaccia mostra una netmask diversa rispetto a quella configurata
localmente.
●​ stub ed NSSA mismatches si verificano quando un controllo sui bit di capacità
di un pacchetto hello mostra che i router remoti e locali non sono d'accordo
sul fatto che un'area sia NSSA o stub.
●​ MTU mismatches è un errore autoesplicativo. Indica un'errata configurazione
dell'interfaccia.
●​ L'errore “Hello received with our router ID” è un sintomo di un ID router
duplicato.
●​ L'errore "The Hellos received on point-to-point LAN with DR/BDR elected" si
verifica quando una parte ha configurato il collegamento come punto a punto e
l'altro come LAN.

Possiamo anche proteggere LSDB limitando il numero di LSA questo di fa con il comando
database-protection numero di lsa, quando vengono superati il numero di lsa allora la
sessione va down, possiamo anche aggiungere delle opzioni (vedi immagine sotto)

30
Un ultimo comando è il traceoptions per configurarlo bisogna:
●​ Creare il file ed indicare il numero di file che verranno creati a rotazione e la
dimensione
set protocols ospf traceoptions file ospf-log
set protocols ospf traceoptions file files 5 size 10k
●​ Specificare i vari flag

i flag possono essere

●​ database-description—All database description packets, which are used in

synchronizing the OSPF topological database
●​ error—OSPF error packets
●​ event—OSPF state transitions
●​ flooding—Link-state flooding packets
●​ graceful-restart—Graceful-restart events
●​ hello—Hello packets, which are used to establish neighbor adjacencies and to
determine whether neighbors are reachable
●​ ldp-synchronization—Synchronization events between OSPF and LDP
●​ lsa-ack—Link-state acknowledgment packets, which are used in synchronizing the
OSPF topological database
●​ lsa-analysis—Link-state analysis. Specific to the Juniper Networks implementation of
OSPF, Junos OS performs LSA analysis before running the shortest-path-first (SPF)
algorithm. LSA analysis helps to speed the calculations performed by the SPF
algorithm.
●​ lsa-request—Link-state request packets, which are used in synchronizing the OSPF
topological database
●​ lsa-update—Link-state updates packets, which are used in synchronizing the OSPF
topological database
●​ nsr-synchronization—Nonstop routing synchronization events
●​ on-demand—Trace demand circuit extensions

31
 ●​ packet-dump—Dump the contents of selected packet types
●​ packets—All OSPF packets
●​ restart-signaling—(OSPFv2 only) Restart-signaling graceful restart events
●​ spf—Shortest path first (SPF) calculations

Ed opzionale si può specificare

●​ detail—Detailed trace information

●​ receive—Packets being received
●​ send—Packets being transmitte

32
OSPFv3
OSPFv3 è una nuova versione di OSPF sviluppata per IPv6, riprende concetti di
base OSPF ma con molti miglioramenti (prende molti spunti da IS-IS), utilizza
pacchetti IPv6 per trasportare i messaggi e può coesistere con OSPFv2.

OSPFv3 utilizza gli stessi tipi di messaggi di OSPFv2. Il trasporto avviene

direttamente imbustando i messaggi OSPFv3 direttamente in pacchetti IPv6. La
presenza dei messaggi OSPFv3 è determinata dal valore di Next Header pari a
89 (stesso valore utilizzato da OSPFv2). Tutti i messaggi OSPFv3 sono inviati con
Hop Limit = 1, ossia sono diretti solo ed esclusivamente ai router adiacenti.
Inoltre il campo Traffic Class viene posto al valore binario 11000000b, ciò indica
che devono avere un trattamento preferenziale rispetto ai pacchetti dati che
circolano sulla rete.

Confronto OSPFv2 con OSPFv3

Aspetti comuni:

●​ Stessi tipi di sotto-reti

●​ Stessi messaggi
●​ Stessi sotto-protocolli
●​ Stesso meccanismo di scoperta dei neighbor e formazione delle adiacenze
●​ Stessi criteri per l’elezione di DR e BDR
●​ Stessi meccanismi per la costruzione del LSDB
●​ Stesso algoritmo di ricerca del percorso ottimo (Dijkstra)
●​ Stessa struttura gerarchica a due livelli
●​ Supporto dello stesso tipo di aree
●​ Stessa tipologia di percorsi

Differenze

●​ OSPFv3 esegue l’algoritmo SPF per link, non per subnet come in OSPFv2.
Ciò significa che un’interfaccia connette il router ad un link, non ad una
subnet. Su uno stesso link possono essere configurate più subnet, e si
stabilisce l’adiacenza tra due router su uno stesso link anche se non hanno
subnet in comune. In realtà una adiacenza viene stabilita anche in
assenza di indirizzi Global (o Unique Local). OSPFv3 utilizza indirizzi
Link-Local per stabilire le adiacenze.
●​ È possibile definire più istanze OSPFv3 sullo stesso link.
●​ OSPFv3 utilizza indirizzi IPv6 Link-Local e well-known IPv6 multicast
(FF02::5 = AllSPFRouters e FF02::6 =AllDRouters).
●​ In OSPFv3 sono state eliminate le procedure di autenticazione dei
messaggi. Sono utilizzate direttamente le funzionalità di sicurezza di IPv6
(Extension Header AH + ESP).
●​ I router OSPFv3 sono sempre identificati dal Router-ID (RID), che rimane
di lunghezza 32 bit.

33
 ●​ I Router Link e Network Link LSA trasportano solo informazioni
topologiche e non anche informazioni sui prefissi direttamente connessi
come in OSPFv2. Anche questa è una idea simile a IS-IS, ossia il
disaccoppiamento tra le informazioni topologiche e i prefissi IP
direttamente connessi.

Una novità di OSPFv3, non presente in OSPFv2, è la possibilità di associare un

valore numerico (Instance ID) a una interfaccia abilitata OSPFv3. Questo valore
condiziona la formazione delle adiacenze, poiché OSPFv3 utilizza la regola che le
adiacenze possono essere stabilite solo tra router che hanno l’interfaccia sul link
con identico Instance ID.

Il valore di Instance ID è utile sui segmenti broadcast, quando si vogliono

formare adiacenze solo tra determinati router. Ad esempio, nella figura, a causa
dei valori di Instance ID, vengono stabilite adiacenze solo tra i router R1 e R3,
che hanno entrambi Instance ID = 1, e tra i router R2 e R4, che hanno entrambi
Instance ID = 2.

Si noti che anche l’elezione di DR e BDR è condizionata dai valori di Instance ID.
Infatti, sempre con riferimento alla figura della diapositiva, nel caso di Instance
ID identici si avrebbero un DR e BDR, come è usuale in OSPF. Con i valori di
Instance ID riportati nella figura, vengono eletti un DR e BDR per i due router
che hanno Instance ID = 1 e un DR e BDR per i due router che hanno Instance
ID = 2. In un certo senso, il segmento broadcast viene partizionato in due
segmenti broadcast logici, ciascuno con il proprio DR e BDR.

34
LSA in OSPFv3

La tabella della diapositiva riassume i LSA presenti in OSPFv3. La tabella illustra

inoltre quali sono i nuovi LSA (Link-LSA e Intra-area-prefix-LSA), quali
quelli eliminati (Group-Membership-LSA) e infine quelli presenti anche in OSPFv2
(alcuni dei quali hanno mantenuto lo stesso nome mentre altri lo hanno
cambiato). La colonna centrale della tabella indica, per ciascun LSA, il valore del
campo LS Type, espresso in notazione esadecimale.

Si noti che quando il primo valore coincide con 2, l’ambito di propagazione è

l’area, quando è 0 l’ambito di propagazione è Link-local e infine, quando è 4,
l’ambito di propagazione è l’intero dominio OSPFv3.

I valori del campo LSA Function Code per i primi 6 LSA (escludendo quello
eliminato) coincidono con i valori di tipo di LSA in OSPFv2.

Router-LSA (LS TYPE 0x2001)

I Router-LSA (LS TYPE 0x2001) trasportano le informazioni topologiche locale
di ciascun router, vengono propagati all’interno dell’area (valore 2 del primo
numero esadecimale). Gli ABR generano un Router-LSA per ogni area a cui
appartengono. Contengono informazioni su:

●​ Con quali router è stata stabilita una adiacenza, inclusi eventuali

pseudo-nodi.
●​ Metriche associate alle interfacce da dove sono acquisite le adiacenze.

A differenza degli analoghi Router Link LSA di OSPFv2, i Router-LSA non

trasportano informazioni sulle Stub network, ossia sui prefissi IP direttamente
connessi. Queste, come vedremo, in OSPFv3 sono trasportate dai nuovi
Intra-area-prefix-LSA.

35
Si noti che questo è un aspetto molto importante che caratterizza OSPFv3
rispetto a OSPFv2, e ne migliora l’efficienza complessiva. Infatti, in OSPFv2, ogni
variazione di una Stub network (inserimento/perdita/variazione di indirizzo)
comporta la generazione di un nuovo Router Link LSA e quindi il ricalcolo
dell’albero dei percorsi ottimi, anche se non necessario. Questo perché le
informazioni sulle Stub network sono inserite nei Router Link LSA insieme alle
informazioni topologiche.

Ogni tipo di informazione trasportata viene descritta da un Link Type, che può
assumere 3 valori:

●​ Link Type 1: identifica le adiacenze punto-punto stabilite con un altro

router. Tra le informazioni comprese nel Link Type 1 vi è anche la metrica
dell’interfaccia di collegamento con il router adiacente.
●​ Link Type 2: identifica una adiacenza con uno pseudo-nodo. Tra le
informazioni comprese nel Link Type 2 vi è anche la metrica dell’interfaccia
sul segmento broadcast.
●​ Link Type 4: identifica una connessione a un Virtual Link.

Inoltre per ogni link, oltre il link type contiene i campi:

●​ Metric: Metrica associata all’interfaccia da cui si acquisisce l’adiacenza.

●​ Local Interface ID: identificativo dell’interfaccia locale 10
●​ Neighbor Interface ID: identificativo dell’interfaccia all’altro estremo
dell’adiacenza.
●​ Neighbor Router ID: RID del router adiacente.

Network-LSA (LS-TYPE 0x2002)

I Network-LSA sono generati solo dai DR e propagati solo all’interno dell’area
nella quale vengono generati:

●​ Se un router è DR per più segmenti LAN, genera un diverso Network-LSA

per ciascun segmento LAN
●​ I DR generano comunque Router-LSA per descrivere il collegamento verso
lo pseudo-nodo e al di fuori dei segmenti LAN di cui è DR

Contengono, come unica informazione, i RID dei router connessi al segmento

broadcast

10
OSPFv3 assegna localmente a ciascuna interfaccia abilitata, un identificativo numerico
arbitrario di 32 bit che è associato univocamente all’interfaccia (Interface ID). Questo
valore viene comunicato ai router adiacenti attraverso i messaggi HELLO.

36
Inter-Area-Prefix (LSA-TYPE 0x2003
Gli Inter-Area-Prefix-LSA sono generati dagli ABR per annunciare i prefissi
inter-area (aggregati o no) Gli Inter-Area-Prefix-LSA sono rigenerati dagli ABR su
tutte le aree a cui l’ABR è collegato

NOTA: non annuncia gli indirizzi Link-local

Contiene prefisso/lunghezza-maschera del prefisso IPv6 annunciato e il costo

minimo tra l’ABR e il prefisso Ogni Inter-Area-Prefix-LSA contiene solo le
informazioni di un singolo prefisso IPv6

In particolare, un ABR genera un Inter-Area-Prefix-LSA per annunciare i prefissi:

●​ Presenti in un’area, ricevuti come vedremo via Intra-Area-Prefix-LSA,

verso l’area backbone.
●​ Di altre aree appresi attraverso Inter-Area-Prefix-LSA dall’area backbone.
Un ABR, alla ricezione di un

Inter-Area-Prefix-LSA , provvede a rigenerarlo e a inviarlo a tutte le aree a cui è

connesso. La propagazione dei Inter-Area-Prefix-LSA, segue 2 regole
fondamentali:

1.​ Gli Inter-Area-Prefix-LSA generati da un ABR, sono propagati (via

flooding) solo sull’area dove vengono inoltrati.

37
 2.​ Gli Inter-Area-Prefix-LSA provenienti dall’area backbone vengono
rigenerati in tutte le aree non backbone.

Inter-Area-Router-LSA (LS-TYPE 0x2004)

Gli Inter-Area-Router-LSA sono generati dagli ABR per annunciare la
raggiungibilità degli ASBR, le regole di propagazione sono identiche a quelle degli
Inter-Area-Prefix-LSA Ogni Inter-Area-Router-LSA annuncia un singolo ASBR

Un Inter-Area-Router-LSA contiene il RID dell’ASBR annunciato e il costo minimo

tra l’ABR e l’ASBR

AS-External-LSA (LS-TYPE 0x4005)

Gli AS-External-LSA sono generati dagli ASBR per annunciare prefissi IPv6
esterni al dominio di routing OSPF

●​ Gli AS-External-LSA sono gli unici ad essere propagati (via protocollo di

flooding) in tutto il dominio OSPF
●​ Ogni AS-External-LSA contiene solo le informazioni di un singolo prefisso
IP
●​ Può annunciare anche una default route

Contiene prefisso/lunghezza-maschera, tipo di metrica (1 o 2) e costo del

prefisso IPv6 annunciato

38
NSSA-External-LSA (LS-TYPE 0x2007)
Sono generati dagli ASBR per annunciare in una area NSSA prefissi esterni al
dominio di routing (AS)

●​ Gli NSSA-External-LSA non vengono propagati al di fuori dell’area NSSA

●​ Ogni NSSA-External-LSA contiene solo le informazioni di un singolo
prefisso

Il formato è identico a quello di un AS-External-LSA

Link-LSA (LS-TYPE 0x0008)

Un router genera un Link-LSA per ogni link fisico che partecipa al processo
OSPFv3 Sono propagati solo sul link descritto nel Link-LSA (ambito di
propagazione Link-local)

I Link-LSA hanno due scopi fondamentali (e altri di minore importanza):

1.​ Forniscono a tutti gli altri router connessi al link l’indirizzo Link-Local
dell’interfaccia del router connessa al link
2.​ Forniscono a tutti gli altri router connessi al link la lista dei prefissi IPv6
associati all’interfaccia del router connessa al link

39
Intra-Area-Prefix-LSA (LS-TYPE 0x2009)
Gli Intra-Area-Prefix-LSA (LSA Function Code = 0x2009) sono generati da un
router per annunciare i prefissi direttamente connessi (stub networks, prefissi di
link broadcast) Sono propagati solo all’interno dell’area nella quale vengono
generati. Ogni prefisso annunciato via Intra-Area-Prefix-LSA è associato o a un
Router-LSA o a un Network-LSA

La configurazione del protocollo OSPFv3 (ospf per ipv6) è simile alla configurazione OSPF,
anche il router ID utilizza un indirizzo a 32bit (ipv4) che può essere configurato sotto
ruoting-options

anche i comandi di troubleshooting sono uguali cambia solo OSPF con OSPF3

40
é possibile configurare OPSv3 per utilizzare anche IPv4 per far ciò dobbiamo
utilizzare set protocol ospf3 realm ipv4-unicast

41
42