Come è noto, OSPF determina il percorso ottimo per raggiungere una determinata rete IP, sulla base del costo complessivo. 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:

Quindi R1 vede due percorsi disponibili: il percorso intra-area R1-R3-R4 e il percorso inter-area R1-R2-R4. Per la regola citata sopra, OSPF sceglie il percorso intra-area, che ha costo complessivo 102, maggiore del costo del percorso inter-area che è invece 3. In soldoni, OSPF sceglie un percorso non ottimo.

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” del Maggio 2008, ha descritto le (poche) varianti da apportare a OSPF che consentono la realizzazione di adiacenze multi-area.

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

Sat Sep 19 15:32:25.312 UTC

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

Sat Sep 19 15:34:45.221 UTC

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

Sat Sep 19 15:36:12.547 UTC

* 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 è che è 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 che ha indirizzo 172.16.12.2.

Considerazioni finali

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 (ricordo che è disponibile solo per chi si registra sul nostro sito). 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, IPN264.