Come è noto, OSPF determina i cammini sulla base del costo complessivo per raggiungere una determinata rete IP. In particolare, tra tutti i percorsi disponibili, viene scelto quello a costo minimo, dove il costo è determinato come somma delle metriche associate a ciascuna interfaccia attraversata per raggiungere la destinazione.
Ma a volte l’apparenza inganna. La regola del percorso ottimo a costo minimo, non è sempre rispettata. Si consideri ad esempio la topologia OSPF descritta nella seguente figura:
Per ciascun collegamento la figura riporta la velocità e tra parentesi la metrica delle interfacce agli estremi (per ipotesi simmetrica). Il percorso a costo minimo dal router R1 verso la rete identificata dal prefisso Px, direttamente connessa al router R4, sembrerebbe essere R1-R2-R4, che ha costo totale 3, piuttosto che R1-R3-R4, che ha invece costo complessivo 102.
Ma la realtà è diversa. Il percorso ottimo è invece proprio il secondo, riportato tratteggiato nella figura. Perché accade questo ? Tutto è legato a una regola basilare di OSPF, il quale preferisce sempre percorsi intra-area piuttosto che percorsi inter-area, e questo indipendentemente dai costi complessivi.
Vediamo più da vicino cosa accade su R1. R1 riceve due annunci della rete Px:
- Il primo da R3, che propaga (via selective flooding) il LSA di tipo 1 (Router Link LSA) generato da R4. Su questo LSA la rete Px viene annunciata come Stub Network (link type = 3), quindi la rete Px viene vista da R1 come intra-area.
- Il secondo da R2, che genera un LSA di tipo 3 (Summary Link LSA) per annunciare nell’area 0 (backbone) la rete esterna all’area (inter-area) Px. Quindi la rete Px viene vista da R1 anche come inter-area.
Per porre rimedio a questo problema, è stata creata in OSPF la possibilità di creare delle adiacenze multi-area. Si pensi per un momento di poter creare sul collegamento R1-R2 due adiacenze, una appartenente all’area 0 e l’altra appartenente all’area 1, ossia adiacenze multi-area sullo stesso collegamento. Il problema del percorso non ottimo verrebbe immediatamente risolto poiché in questo caso R1 vedrebbe la rete Px annunciata da un LSA di tipo 1 anche tramite R2 (che propaga via selective flooding a R1, il LSA di tipo 1 generato da R4); quindi il percorso ottimo diverrebbe il percorso intra-area R1-R2-R4, che è quello desiderato.
Ma le versioni originali 2 e 3 di OSPF non consentono la realizzazione di adiacenze multi-area. Questo aspetto è stato però ripreso da IETF, che attraverso la RFC 5185 - OSPF Multi-Area Adjacency, Maggio 2008, ha descritto le (poche) varianti da apportare a OSPF, che consentono la realizzazione di adiacenze multi-area.
ASPETTI DI CONFIGURAZIONE
La RFC 5185 è supportata dai maggiori vendor. Cisco ha implementato la RFC 5185 sia per OSPFv2 che per OSPFv3 dapprima nell’IOS XR, a partire dalla versione 3.4.1, e quindi recentemente nell’IOS 15.4(2)T e nell’IOS XE 3.11S. Il JUNOS ha invece introdotto il supporto della RFC 5185 a partire dalla versione 9.2 per OSPFv2 e dalla versione 9.4 per OSPFv3.
Vediamo ad esempio come configurare nell’IOS XR l’adiacenza multi-area tra i router R1 e R2 che consente di ottimizzare il percorso verso il prefisso Px.
Router R1
RP/0/0/CPU0:R1# show run router ospf
. . .
router ospf 1
router-id 192.168.1.1
area 0
interface Loopback0
passive
!
interface GigabitEthernet0/0/0/0
network point-to-point
!
!
area 1
multi-area-interface GigabitEthernet0/0/0/0
!
interface GigabitEthernet0/0/0/1
cost 100
network point-to-point
!
!
!
Router R2
RP/0/0/CPU0:R2# show run router ospf
. . .
router ospf 1
router-id 192.168.1.2
area 0
interface Loopback0
passive
!
interface GigabitEthernet0/0/0/0
network point-to-point
!
!
area 1
multi-area-interface GigabitEthernet0/0/0/0
!
interface GigabitEthernet0/0/0/1
network point-to-point
!
!
!
Ora, controllando l’adiacenza tra R1 e R2 si può notare la realizzazione dell’adiacenza multi-area:
RP/0/0/CPU0:XR1# show ospf neighbor
. . .
* Indicates MADJ interface
Neighbors for OSPF 1
Neighbor ID Pri State Dead Time Address Interface
192.168.1.2 1 FULL/ - 00:00:34 172.16.12.2 GigabitEthernet0/0/0/0
Neighbor is up for 8:36:46
192.168.1.2 1 FULL/ - 00:00:36 172.16.12.2 GigabitEthernet0/0/0/0*
Neighbor is up for 00:01:06
192.168.1.3 1 FULL/ - 00:00:31 172.16.13.3 GigabitEthernet0/0/0/1
Neighbor is up for 8:36:47
Total neighbor count: 3
Un aspetto interessante, affinché le adiacenze multi-area vengano realizzate è necessario il comando “network point-to-point”.
La stessa configurazione nell’IOS e IOS XE, è la seguente:
Router R1
interface GigabitEthernet0/0/0/0
ip address 172.16.12.1
ip ospf 1 area 0
ip ospf 1 multi-area 1
ip ospf network point-to-point
Router R2
interface GigabitEthernet0/0/0/0
ip address 172.16.12.2
ip ospf 1 area 0
ip ospf 1 multi-area 1
ip ospf network point-to-point
Infine, vediamo la configurazione nel JUNOS, e i dettagli di funzionamento con l’esempio della figura:
Router R1
tt@R1> show configuration protocols ospf
area 0.0.0.0 {
interface ge-0/0/0;
}
area 0.0.0.1 {
interface fe-0/0/1 {
metric 100;
}
interface ge-0/0/0 {
secondary;
}
}
Router R2
tt@R2> show configuration protocols ospf
area 0.0.0.0 {
interface ge-0/0/0;
}
area 0.0.0.1 {
interface ge-0/0/1 {
}
interface ge-0/0/0 {
secondary;
}
}
Anche qui, con il classico comando “show ospf neighbor” si può verificare l’esistenza delle due adiacenze tra R1 e R2 in area 0 e 1:
tt@R1> show ospf neighbor
Address Interface State ID Pri Dead
172.16.12.2 ge-0/0/0.0 Full 192.168.1.2 128 36
Area 0.0.0.0
172.16.12.2 ge-0/0/0.0 Full 192.168.1.2 128 33
Area 0.0.0.1
172.16.13.3 fe-0/0/1.0 Full 192.168.1.3 128 33
Area 0.0.0.1
Infine, per chiudere questo esempio di applicazione della funzionalità di OSPF multi-adjacency, verifichiamo con un traceroute che il percorso seguito dal traffico verso un indirizzo del prefisso Px sia quello desiderato. Supponendo per ipotesi che l’interfaccia della LAN con prefisso Px sul router R4 abbia indirizzo 10.1.1.1, questo è quello che si ottiene:
tt@R1> traceroute 10.1.1.1
traceroute to 10.1.1.1 (10.1.1.1), 30 hops max, 40 byte packets
1 172.16.12.2 (10.0.26.2) 0.324 ms 0.270 ms 0.205 ms
2 10.1.1.1 (10.1.1.1) 0.499 ms 0.395 ms 0.489 ms
Il percorso seguito è proprio quello che fa transito su R2, che ha l’interfaccia lato R1 con indirizzo 172.16.12.2.
CONCLUSIONI
La funzionalità OSPF multi-adjacency può essere utile in topologie molto particolari. Io personalmente non ne consiglio l’utilizzo, a meno che non sia temporaneo. Un po’ come i virtual link, utili in certe situazioni ma pur sempre “una pezza a colori”. Piuttosto, è meglio riprogettare la rete !
Esiste una funzionalità simile in IS-IS ? La risposta è no, per il semplice fatto che IS-IS non ne ha bisogno. Per risolvere il problema dell’instradamento non ottimo visto sopra per OSPF, la soluzione è di creare adiacenze sia di Livello 1 che Livello 2 sullo stesso link, cosa che in IS-IS è nativa. Quindi non è necessaria alcuna estensione ! Fra circa un mese sarà disponibile per il download gratuito il Capitolo 3 del mio libro su IS-IS. Nella sezione 3.3.1 troverete ulteriori dettagli.
Per chi volesse approfondire gli aspetti avanzati di OSPF, iscrivetevi a uno o entrambi dei seguenti nostri corsi: IPN232 e IPN264.
Salve Ammiraglio,contrariamente a quanto riportato in questo suo post mi è recentemente accaduto, che sia su macchine virtuali che chassis fisici, un abr preferisca lsa3 piuttosto che lsa1. Lo scenario testato rispecchia il caso riportato nel blog. Leggendo rfc2328 si nota che " The inter-area routes are calculated by examining summary-LSAs. If the router has active attachments to multiple areas, only
RispondiEliminabackbone summary-LSAs are examined." Le torna? Risoluzione: creare adiacenza tra abr anche in area 1.
Caro Anonimo,
RispondiEliminamagari ho capito male io ....ma come è possibile che "un abr preferisca lsa3 piuttosto che lsa1" ? Riguardo all'estratto dell'RFC citato, riguarda il meccanismo di loop prevention dell'OSPF per quanto riguarda la raggiungibilità di rotte inter-area e scondo il quale se un router è su piu aree allora esamina solo LSA3 che riceve dall'area 0 mentre se è su una singola area allora esamina le LSA3 di quell'area.
Qui di fatto con una adiacenza multiarea tra R1 ed R2 si consente ad R1 di avere anche il link R1-R2 nella topologia dell'area1 per cosi poter raggiungere R4 e quindi Px. Non c'entra nulla il processamento della LSA3.
La cosa che mi domando è piuttosto quale sia il grosso vantaggio del multiarea rispetto al trunkare come .1Q il link R1-R2 e farci una adiacenza/area per vlan subinterface.
Ciao
Andrea Di Donato