Il problema da risolvere e’ il seguente: dati N routers su una rete locale, e’ possibile stabilire che esistono N*(N-1)/2 adiacenze, tali che ogni router deve quindi inviare N-1 messaggi verso gli altri routers vicini piu’ uno verso la rete (stub network) per un totale di N*N messaggi.

OSPF prova a ridurre a solo N adiacenze designando uno dei router (Designed Router o DR) in modo tale che i rimanenti routers stabiliscano adiacenze solo con il router designato.

Il primo passo e’ eleggere il router designato. Questa elezione e’ incorporata nella procedura “Hello”. Dopo l’elezione, gli altri routers porteranno le proprie adiacenze verso il router designato o sincronizzeranno il proprio database.

La presenza del router designato serve inoltre per :

Ridurre il numero dei record di link state nel database, in quanto la rete broadcast potra’ essere rappresentata da un set di links tra i routers ed un nodo virtuale.

Semplificare la procedura di flooding, quando un router deve inviare una LSA (Link State Advertisment), la trasmette solo al router designato, utilizzando l’indirizzo multicast 224.0.0.6. Se si tratta di una nuova LSA, il router designato diffondera’ il link state a tutte le proprie interfacce e alla rete utilizzando l’indirizzo multicast 224.0.0.5.

Tuttavia, se il DR cade, tutti i routers apparirebbero disconnessi dalla rete, sebbene questa sia, a tutti gli effetti, ancora operativa. Risulta quindi indispensabile eleggere al piu’ presto un nuovo DR. OSPF ovvia questo problema, con l’elezione di un “Backup Designed Router o BPR”, contemporaneamente all’elezione del DR.

Tutti i routers creeranno quindi le proprie adiacenze con entrambi i routers DR e BDR; se il DR cade, l’anomalia verra’ immediatamente rilevata dal protocollo Hello, il BDR diventera’ immediatamente DR ed un nuovo BDR verra’ eletto. Tutti i routers stabiliranno un adiacenza con il nuovo BDR.

Per poter utilizzare il protocollo ospf su server linux e’ possibile installare il pacchetto Quagga.

Quagga e’ un demone multiprotocollo di routing che supporta molti protocolli dinamici, e’ modulare e scalabile.

La sua architettura e’ organizata per gestire ogni protocollo di routing con un demone ad hoc e con un demone “manager” che scrive le rotte verso la tabella di routing del  kernel di linux

Obiettivi di Ospf

24 Giu
2009
Superare i limiti del RIP
 Avere metriche più efficienti (migliori possibilità di
descrivere la rete)
 Introdurre delle gerarchie (per maggior scalabilità)
 Separazione informazioni interne ed esterne (all’AS)
 Supporto subnetting variabile (CIDR)
 Sicurezza
 Routing dipendente anche dal TOS (In effetti il TOS è
inutilizzato su IPv4 perché gli host non ne fanno uso e i router non li
gestiscono …)
  • Superare i limiti del RIP
  • Avere metriche più efficienti (migliori possibilità di descrivere la rete)
  •  Introdurre delle gerarchie (per maggior scalabilità)
  •  Separazione informazioni interne ed esterne (all’AS)
  •  Supporto subnetting variabile (CIDR)
  •  Sicurezza
  •  Routing dipendente anche dal TOS (il TOS è inutilizzato su IPv4 perché gli host non ne fanno uso e i router non li gestiscono …)

Una rete OSPF è divisa in aree. Esse sono gruppi logici non sovrapposti di router le cui informazioni posso essere sommarizzate rispetto al resto della rete. Diversi tipi di aree “speciali” sono definite:

Area Backbone

L’area backbone (conosciuta anche come area zero) rappresenta il cuore di una rete OSPF. Tutte le altre aree sono collegate ad essa e il routing inter-area passa tramite un router di questa rete.

Stub area

Per Stub Area si intendono quei tipi di area che non ricevono route esterne. Le route esterne saranno poi definite e distribuite da un altro protocollo di Routing. Quindi, le stub area necessitano di relegare ad una route di default lo scambio per il traffico con quelle esterne al dominio di appartenenza

Totally stubby area

Una totally stubby area è simile ad una stub area, tuttavia quest’area non permette route riassuntive oltre che le route esterne. L’unico modo in cui il traffico esce dall’area è una route di default che è l’unica di Tipo-3 LSA pubblicata nell’area. Quando c’è solo una route per uscire dall’area, devono essere effettuate meno decisioni di routing dal processore di route, con minore utilizzo di risorse di sistema. Questa è la versione Cisco della NSSA.

Not-so-stubby area

Identificata anche come NSSA, una not-so-stubby area è un tipo di stub area che può importare route esterne di  AS e mandarle al backbone, ma non può ricevere tali route esterne di AS dal backbone o da altre aree. Cisco implementa anche una versione proprietaria di NSSA chiamata NSSA Totally Stubby area. Si prende la responsabilità di una Totally Stubby area, col significato che route riassuntive di tipo 3 e 4 non vanno ad inondare questo tipo di area.

da Wikipedia

Hello Message

23 Giu
2009

top