

	OSPF
OSPF OSPF e’ un protocollo di routing in cui ogni router della rete mantiene il grafo topologico dell’intera rete. Pertanto ogni router della rete ha visibilita’ su tutta la struttura di rete. In RIP, EIGRP, IGRP un router non ha idea dell’intera struttura topologica della rete in cui si trova ma soltanto di quella relativa ad esso e ai suoi suoi vicini. Per questa ragione OSPF si chiama protocollo “link-state”. La presenza del grafo dell’intera rete consente ad ogni router, applicando l’algoritmo di Dijkstra (shortest-path), di estrarre un albero dal grafo cosi’ da determinare il percorso ottimale per raggiungere ogni destinazione evitando loop e senza fare uso di hold-down timer che sono causa della lenta la convergenza in RIP e IGRP. Ogni router estrae un albero di cui lui stesso e’ la radice. Se due percorsi hanno lo stesso costo OSPF distribuisce il carico tra i due. Nella configurazione di OSPF non si fa uso di AS number ma di process-id che e' cosa differente in quanto si puo' avere differente process-id in router differenti. OSPF ha pieno supporto della netmask, invia solo aggiornamenti e non l’intera tabella di routing ai suoi vicini, e’ piu’ CPU intensive di RIP, IGRP ed EIGRP, ed e’ scalabile. Poiche’ ogni router ha un grafo dell’intera rete col crescere della stessa il ricalcolo con Dijstra puo' impiegare eccessive risorse di CPU e memoria. Per questa ragione sono state introdotte le AREE. Ogni router ha in realta' consapevolezza della struttura dell’area a cui appartiene. Alcuni router, gli ABR, hanno interfacce su aree diverse. L’area 0 e’ speciale ed e’ sempre presente in una rete OSPF. Gli ASBR sono invece quei router che ridistribuiscono in OSPF informazioni provenienti da statiche o da altri algoritmi di routing. Tutte le informazioni di routing vengono scambiate tramite messaggi chiamati LSA. RFC1247definisce gli LSA ‘link-state advertisements’ e vengono inviati all'indirizzo multicast 224.0.0.5. Vi sono 5 tipi di LSA: type 1 Propaga informazioni relative a tutte le reti collegate ad un router e appartenenti alla sua stessa area. Gli LSA type 1 vengono inviati ai router di un'area e non ne superano i confini; type 2 Quando piu' router hanno un'interfaccia sullo stesso segmento di LAN ne viene eletto uno, chiamato DR (Designated Router), che ha il compito di inviare informazioni per conto di tutti i router connessi al segmento. Gli LSA type 2 vengono inviati ai router di un'area e non ne superano i confini; type 3,4 Questi messaggi passano da un'area ad un'altra adiacente. Sono originati dagli ABR (Area Border Router). ABR invia ad un’area informazioni relative ad un’altra area, sempre di cui fa parte. I type 3 contengono informazioni relative a route verso reti presenti nelle aree. I type 4 contengono informazioni di routing in direzione degli ASBR, ovvero router che inseriscono in OSPF route di altri protocolli come BGP; type 5 Originati dagli ASBR e contenti informazioni per route relative a destinazioni su AS esterni. Sono di due tipi: E1 e E2. Di default E2. Le route esterne (external routes) vengono propagate dagli ASBR tramite gli LSA Type 5. Le route esterne si classificano a loro volta in: · external type 1 (E1) · external type 2 (E2) La tipologia E1 propaga la route nella nuvola OSPF aggiornandone il costo con la propagazione. La tipologia E2 propaga la route nella nuvola OSPF lasciandone inalterato il costo. Per default gli LSA sono propagati attraverso tutte le interfacce su una stessa area con esclusione dell’interfacce da cui sono arrivati. Due neighbor, anche adiacenti, si scambiano pacchetti Hello ogni 10 secondi (Hello interval). Se dopo quattro volte questo tempo (Dead interval) non arrivano Hello la vicinanza col neighbor passa dallo stato “FULL” allo stato “DOWN”. Hello e’ 30 secondi per NBMA (Non Broadcast Multi Access come ATM e Frame Relay). Col comando "show ip ospf neighbor" e' possibile individuare i router OSPF vicini con i quali si ha una sessione attiva: RTA#sh ip ospf nei Neighbor ID Pri State Dead Time Address Interface 172.121.139.253 1 FULL/ - 00:00:36 172.121.139.90 Serial2/0 Gli LSA hanno un aging time di 1h oltre la quale sono cancellati. In ogni caso i router inviano ogni 30 minuti dei refresh indipendentemente da eventuali cambiamenti di topologia. C’e’ da considerare che nelle versioni di OSPF meno recenti si inviano refresh indiscriminatamente per tutti gli LSA generati. In seguito si e' adottato un TIMER per ogni LSA. Cio’ consente di inviare solo gli LSA effettivamente vecchi. Comunque questi ultimi vengono raggruppati per intervalli di 4 minuti di default (pacing timer) per generare 1 solo pacchetto di aggiornamento per piu’ LSA e meno spreco di banda e CPU. OSPF funziona in modalita' diverse a seconda della rete su cui opera. Si distingue: point-to-point E’ il caso dei collegamenti punto-punto tra router come un seriale con PPP o HDLC o un ISDN. L’interfaccia puo’ essere unnumbered. Se c’e’ l’ip il link e’ trattato come una stub network; broadcast networks E’ il caso in cui il router e’ collegato ad esempio ad una rete ethernet. Se nella ethernet vi e’ un solo router con OSPF questa e’ trattata come stub network altrimenti si procede con l’elezione di un DR e la rete e trattata come transit network; point-to-multipoint non-broadcast Si tratta delle reti Non Broadcast Multi Access come ATM e Frame Relay. Col point-to-multipoint la rete e vista come un insieme di collegamenti point-to-point. E’ il meno efficiente per l'elevata bandwidth utilizzata per gli aggiornamenti. Con il non-broadcast invece la rete viene vista come una rete ethernet. Si elegge un DR. In questo caso pero’ ogni router nella NBMA deve vedere gli altri cioe’ ci vuole una configurazione full-mesh; Esempi Questo esempio mostra una tipica configurazione OSPF nel caso di un router lato customer di una rete: router ospf 4 log-adjacency-changes network 192.168.65.12 0.0.0.3 area 0.0.5.0 <--- le interfacce che cadono in questa network avranno OSPF attivo distribute-list 82 out distribute-list 81 in access-list 81 permit 172.16.20.50 access-list 81 deny any access-list 82 deny any Per resettare il processo OSPF e rigenerare la tabella di routing si usa "clear ip ospf process". Ecco l'invio di un comando clear ad un router con OSPF. La sequenza mostra tutto il processo di avvio di una sessione OSPF e scambio di LSA: prova-ct# clear ip ospf process Reset ALL OSPF processes? [no]: yes prova-ct# Mar 10 16:07:06.810: OSPF: Flushing External Links Mar 10 16:07:06.814: OSPF: Inc retrans unit nbr count index 1 (0/1) to 1/1 # # 10.121.139.253 e' il nostro unico Neighbor ID # Mar 10 16:07:06.814: OSPF: Set Nbr 10.121.139.253 1 first flood info from 0 (0) to 62D48788 (792) Mar 10 16:07:06.814: OSPF: Init Nbr 10.121.139.253 1 next flood info to 62D48788 # # 192.13.19.80 sono gli ip per la navigazione internet assegnati, definiti # mediante statica e sono type 5 in quanto provengono da rete esterna # # Quando si manda un LSA questo viene conservato in attesa dell'ACK # Se questo non arriva entro il "retransmit-interval", di default 5 sec., # e selezionabile tra 1 a 65535 con "ip ospf retransmit-interval T" # Gli LSA sono in una retransmission-list finche' non arriva ACK Mar 10 16:07:06.814: OSPF: Add Type 5 LSA ID 192.13.19.80 Adv rtr 10.121.139.89 Seq 80000023 to Serial2/0 10.121.139.253 retransmission list Mar 10 16:07:06.814: OSPF: Start Serial2/0 10.121.139.253 retrans timer Mar 10 16:07:06.814: OSPF: Set idb next flood info from 0 (0) to 62D48788 (792) Mar 10 16:07:06.814: OSPF: Add Type 5 LSA ID 192.13.19.80 Adv rtr 10.121.139.89 Seq 80000023 to Serial2/0 flood list Mar 10 16:07:06.814: OSPF: Start Serial2/0 pacing timer for 33 msecs Mar 10 16:07:06.814: OSPF: Flushing Opaque AS Links # Si trasmette LSA type 5 (si noti che siamo nello stesso istante di prima) Mar 10 16:07:06.814: OSPF: Flooding update on Serial2/0 to 224.0.0.5 Area 0 Mar 10 16:07:06.814: OSPF: Send Type 5, LSID 192.13.19.80, Adv rtr 10.121.139.8 9, age 3600, seq 0x80000023 (0) Mar 10 16:07:06.814: OSPF: Create retrans unit 0x62D47E14/0x62D46CD4 1 (0/1) 1 Mar 10 16:07:06.814: OSPF: Set nbr 1 (0/1) retrans to 4968 count to 1 Mar 10 16:07:06.814: OSPF: Set idb next flood info from 62D48788 (792) to 0 (0) Mar 10 16:07:06.814: OSPF: Remove Type 5 LSA ID 192.13.19.80 Adv rtr 10.121.139 .89 Seq 80000023 from Serial2/0 flood list Mar 10 16:07:06.814: OSPF: Stop Serial2/0 flood timer # # LSA type 5 per la rete 192.13.90.80 e' stato inviato # # Finiti gli LSA type 5 adesso manda quello della seriale in questo caso 10.121.139.89 # che e' LSA type 1 # Mar 10 16:07:06.854: OSPF: Flushing Link states in area 0 Mar 10 16:07:06.854: OSPF: Inc retrans unit nbr count index 1 (0/1) to 1/1 Mar 10 16:07:06.854: OSPF: Set Nbr 10.121.139.253 1 first flood info from 0 (0) to 62D49024 (1000) Mar 10 16:07:06.854: OSPF: Init Nbr 10.121.139.253 1 next flood info to 62D49024 Mar 10 16:07:06.854: OSPF: Add Type 1 LSA ID 10.121.139.89 Adv rtr 10.121.139.89 Seq 80000036 to Serial2/0 10.121.139.253 retransmission list Mar 10 16:07:06.854: OSPF: Set idb next flood info from 0 (0) to 62D49024 (1000) Mar 10 16:07:06.854: OSPF: Add Type 1 LSA ID 10.121.139.89 Adv rtr 10.121.139.89 Seq 80000036 to Serial2/0 flood list Mar 10 16:07:06.854: OSPF: Start Serial2/0 pacing timer for 33 msecs Mar 10 16:07:06.854: OSPF: Flooding update on Serial2/0 to 224.0.0.5 Area 0 Mar 10 16:07:06.854: OSPF: Send Type 1, LSID 10.121.139.89, Adv rtr 10.121.139.89, age 3600, seq 0x80000036 (0) Mar 10 16:07:06.854: OSPF: Create retrans unit 0x62D47E44/0x62D46B94 1 (0/1) 1 Mar 10 16:07:06.854: OSPF: Set nbr 1 (0/1) retrans to 4736 count to 1 Mar 10 16:07:06.854: OSPF: Set idb next flood info from 62D49024 (1000) to 0 (0) Mar 10 16:07:06.854: OSPF: Remove Type 1 LSA ID 10.121.139.89 Adv rtr 10.121.139.89 Seq 80000036 from Serial2/0 flood list # Mar 10 16:07:06.854: OSPF: Stop Serial2/0 flood timer Mar 10 16:07:06.894: OSPF: Interface Serial2/0 going Down Mar 10 16:07:06.894: %OSPF-5-ADJCHG: Process 10, Nbr 10.121.139.253 on Serial2/0 from FULL to DOWN, Neighbor Down: Interface down or detached Mar 10 16:07:06.894: OSPF: Dec retrans unit nbr count index 1 (0/1) to 0/0 Mar 10 16:07:06.894: OSPF: Free nbr retrans unit 0x62D47E44/0x62D46B94 0 total 0. Also Free nbr retrans block Mar 10 16:07:06.894: OSPF: Set Nbr 10.121.139.253 1 first flood info from 62D49024 (1000) to 0 (0) Mar 10 16:07:06.894: OSPF: Adjust Nbr 10.121.139.253 1 next flood info to 0 Mar 10 16:07:06.894: OSPF: Remove Type 1 LSA ID 10.121.139.89 Adv rtr 10.121.139.89 Seq 80000036 from 10.121.139.253 retransmission list Mar 10 16:07:06.894: OSPF: Dec retrans unit nbr count index 1 (0/1) to 0/0 Mar 10 16:07:06.894: OSPF: Free nbr retrans unit 0x62D47E14/0x62D46CD4 0 total0. Also Free nbr retrans block Mar 10 16:07:06.894: OSPF: Set Nbr 10.121.139.253 1 first flood info from 62D48788 (792) to 0 (0) Mar 10 16:07:06.894: OSPF: Adjust Nbr 10.121.139.253 1 next flood info to 0 Mar 10 16:07:06.894: OSPF: Remove Type 5 LSA ID 192.13.19.80 Adv rtr 10.121.139.89 Seq 80000023 from 10.121.139.253 retransmission list Mar 10 16:07:06.894: OSPF: Stop nbr 10.121.139.253 retransmission timer Mar 10 16:07:06.894: OSPF: Interface Loopback1 going Down Mar 10 16:07:06.962: OSPF: Interface Serial2/0 going Up Mar 10 16:07:06.966: OSPF: Interface Loopback1 going Up Mar 10 16:07:07.394: OSPF: Build router LSA for area 0, router ID 10.121.139.89, seq 0x80000001 # # Si passa allo stato 2WAY dopo che arriva hello dal vicino # # Si passa allo stato EXSTART quando si stabilisce chi e' master e chi slave # Il router con il piu' alto IP address diviene il master # E si manda un numero di sequenza che consente di determinare i vecchi LSA # # DBD sta per DataBaseDescriptor # EXCHANGE: In questo stato il router scambia pacchetti DBD, che # descrivono l'intero link-state database Mar 10 16:07:08.274: OSPF: Rcv hello from 10.121.139.253 area 0 from Serial2/0 10.121.139.90 Mar 10 16:07:08.274: OSPF: 2 Way Communication to 10.121.139.253 on Serial2/0,state 2WAY Mar 10 16:07:08.274: OSPF: Send DBD to 10.121.139.253 on Serial2/0 seq 0x2573 opt 0x42 flag 0x7 len 32 Mar 10 16:07:08.278: OSPF: End of hello processing Mar 10 16:07:08.294: OSPF: Rcv DBD from 10.121.139.253 on Serial2/0 seq 0x14AF opt 0x42 flag 0x7 len 32 mtu 1500 state EXSTART Mar 10 16:07:08.294: OSPF: NBR Negotiation Done. We are the SLAVE Mar 10 16:07:08.294: OSPF: Send DBD to 10.121.139.253 on Serial2/0 seq 0x14AF opt 0x42 flag 0x2 len 72 Mar 10 16:07:08.334: OSPF: Rcv DBD from 10.121.139.253 on Serial2/0 seq 0x14B0 opt 0x42 flag 0x3 len 1472 mtu 1500 state EXCHANGE Mar 10 16:07:08.334: OSPF: Send DBD to 10.121.139.253 on Serial2/0 seq 0x14B0 opt 0x42 flag 0x0 len 32 Mar 10 16:07:08.338: OSPF: Database request to 10.121.139.253 Mar 10 16:07:08.338: OSPF: sent LS REQ packet to 10.121.139.90, length 864 # #NOTARE L'INVIO DELLA MTU: #Note:Cisco IOS ^® Software Release 12.0(3) introduced interface MTU mismatch detection. This detection involves OSPF advertising the interface #MTU in the #DBD packets, which is in accordance with the OSPF RFC 2178 , appendix G.9. When a router receives a DBD packet advertising #a MTU larger than the router can receive, the router ignores the DBD packet and the neighbor state remains in exstart. This prevents an adjacency #from forming. To fix this problem, make sure the MTU are the same on both ends of a link. # # Mar 10 16:07:08.370: OSPF: Rcv DBD from 10.121.139.253 on Serial2/0 seq 0x14B1 opt 0x42 flag 0x3 len 1472 mtu 1500 state EXCHANGE Mar 10 16:07:08.374: OSPF: Send DBD to 10.121.139.253 on Serial2/0 seq 0x14B1 opt 0x42 flag 0x0 len 32 Mar 10 16:07:08.390: OSPF: received update from 10.121.139.253, Serial2/0 Mar 10 16:07:08.390: OSPF: Rcv Update Type 1, LSID 192.13.21.241, Adv rtr 192.13.21.241, age 1656, seq 0x80000879 Mar 10 16:07:08.390: OSPF: Rcv Update Type 1, LSID 192.13.21.209, Adv rtr 192.13.21.209, age 958, seq 0x80001220 Mar 10 16:07:08.390: OSPF: Rcv Update Type 1, LSID 192.13.21.197, Adv rtr 192.13.21.197, age 497, seq 0x80000FE3 Mar 10 16:07:08.394: OSPF: Rcv Update Type 1, LSID 192.13.21.194, Adv rtr 192.13.21.194, age 1133, seq 0x8000017E Mar 10 16:07:08.394: OSPF: Rcv Update Type 1, LSID 192.13.21.189, Adv rtr 192.13.21.189, age 304, seq 0x80000E57 ... Mar 10 16:07:08.546: OSPF: Received same lsa Mar 10 16:07:08.546: OSPF: Sending direct ACK on Serial2/0 to 10.121.139.253 Mar 10 16:07:08.546: OSPF: Ack Type 1, LSID 192.13.21.209, Adv rtr 192.13.21.209, age 959, seq 0x80001220 ... Mar 10 16:07:08.558: OSPF: Rcv Update Type 1, LSID 192.13.2.166, Adv rtr 192.13.2.166, age 1801, seq 0x800034BC Mar 10 16:07:08.558: OSPF: Received same lsa Mar 10 16:07:08.558: OSPF: Rcv Update Type 1, LSID 192.13.2.100, Adv rtr 192.13.2.100, age 237, seq 0x800060DA Mar 10 16:07:08.558: OSPF: Received same lsa Mar 10 16:07:08.558: OSPF: Rcv Update Type 1, LSID 192.13.2.15, Adv rtr 192.13.2.15, age 350, seq 0x800003DA # # router che formano un loop si inviano LSA tra loro finche' non c'e' un # "Received same lsa" # Mar 10 16:07:08.562: OSPF: Received same lsa Mar 10 16:07:08.562: OSPF: Rcv Update Type 1, LSID 192.13.2.8, Adv rtr 192.13.2.8, age 1076, seq 0x80001805 ... Mar 10 16:08:01.894: OSPF: Rcv Update Type 3, LSID 10.121.131.4, Adv rtr 10.121.131.2, age 7, seq 0x80000679 Mar 10 16:08:01.894: Mask /30 Mar 10 16:08:01.894: OSPF: Rcv Update Type 3, LSID 10.121.131.8, Adv rtr 10.121.131.2, age 7, seq 0x80000EDC Mar 10 16:08:01.894: Mask /30 Mar 10 16:08:01.894: OSPF: Rcv Update Type 3, LSID 10.121.131.12, Adv rtr 10.221.131.2, age 7, seq 0x800002F8 ... Mar 10 16:08:04.410: OSPF: Ack Type 3, LSID 192.13.21.237, Adv rtr 10.121.131.2, age 7, seq 0x80000B01 Mar 10 16:08:04.410: OSPF: Ack Type 4, LSID 192.13.21.237, Adv rtr 10.121.131.2, age 7, seq 0x80000B83 Mar 10 16:08:04.410: OSPF: Ack Type 5, LSID 10.121.156.39, Adv rtr 10.121.136.252, age 5, seq 0x80000080 Mar 10 16:08:07.238: OSPF: received update from 10.121.139.253, Serial2/0 Mar 10 16:08:07.238: OSPF: Rcv Update Type 1, LSID 192.13.29.94, Adv rtr 192.13.29.94, age 6, seq 0x80000623 Mar 10 16:08:08.274: OSPF: Rcv hello from 10.121.139.253 area 0 from Serial2/0 10.121.139.90 Mar 10 16:08:08.274: OSPF: End of hello processing Mar 10 16:08:09.738: OSPF: Sending delayed ACK on Serial2/0 Mar 10 16:08:09.738: OSPF: Ack Type 1, LSID 192.13.29.94, Adv rtr 192.13.29.94, age 6, seq 0x80000623 prova-ct#undebug all Articolo versione beta 0.9 - ultima revisione 16/3/03 Altre letture Consiglio di consultare l’enorme documentazione disponibile on-line nel sito della cisco http://www.cisco.com/ . E’ possibile trovare sempre tutto cio’ che si cerca. *Copyright 2002-2004 Gianrico Fichera – ITESYS srl –* Il materiale di questa pagina non e’ sponsorizzato o sottoscritto da Cisco Systems, Inc. Ciscoâ e’ un trademark di Cisco Systems, Inc. negli Stati Uniti e in altri stati. L’autore di questa pagina non si assume nessuna responsabilita’ e non da nessuna garanzia riguardante l’accuratezza e la completezza delle informazioni presenti nonche’ da conseguenze sull’uso delle informazioni presenti in questa pagina. Il sito web ufficiale della Cisco e’ http://www.cisco.com. Nel caso si volesse utilizzare il contenuto di questa pagina nella forma in cui e’ presentato rivolgersi all’autore scrivendo a gianrico.fichera itesys.it.

OSPF

OSPF

OSPF e’ un protocollo di routing in cui ogni router della rete mantiene il grafo topologico dell’intera rete. Pertanto ogni router della rete ha visibilita’ su tutta la struttura di rete. In RIP, EIGRP, IGRP un router non ha idea dell’intera struttura topologica della rete in cui si trova ma soltanto di quella relativa ad esso e ai suoi suoi vicini. Per questa ragione OSPF si chiama protocollo “link-state”. La presenza del grafo dell’intera rete consente ad ogni router, applicando l’algoritmo di Dijkstra (shortest-path), di estrarre un albero dal grafo cosi’ da determinare il percorso ottimale per raggiungere ogni destinazione evitando loop e senza fare uso di hold-down timer che sono causa della lenta la convergenza in RIP e IGRP. Ogni router estrae un albero di cui lui stesso e’ la radice. Se due percorsi hanno lo stesso costo OSPF distribuisce il carico tra i due. Nella configurazione di OSPF non si fa uso di AS number ma di process-id che e' cosa differente in quanto si puo' avere differente process-id in router differenti. OSPF ha pieno supporto della netmask, invia solo aggiornamenti e non l’intera tabella di routing ai suoi vicini, e’ piu’ CPU intensive di RIP, IGRP ed EIGRP, ed e’ scalabile.

Poiche’ ogni router ha un grafo dell’intera rete col crescere della stessa il ricalcolo con Dijstra puo' impiegare eccessive risorse di CPU e memoria. Per questa ragione sono state introdotte le AREE. Ogni router ha in realta' consapevolezza della struttura dell’area a cui appartiene. Alcuni router, gli ABR, hanno interfacce su aree diverse. L’area 0 e’ speciale ed e’ sempre presente in una rete OSPF. Gli ASBR sono invece quei router che ridistribuiscono in OSPF informazioni provenienti da statiche o da altri algoritmi di routing.

Tutte le informazioni di routing vengono scambiate tramite messaggi chiamati LSA. RFC1247definisce gli LSA ‘link-state advertisements’ e vengono inviati all'indirizzo multicast 224.0.0.5. Vi sono 5 tipi di LSA:

type 1

Propaga informazioni relative a tutte le reti collegate ad un router e appartenenti alla sua stessa area. Gli LSA type 1 vengono inviati ai router di un'area e non ne superano i confini;

type 2

Quando piu' router hanno un'interfaccia sullo stesso segmento di LAN ne viene eletto uno, chiamato DR (Designated Router), che ha il compito di inviare informazioni per conto di tutti i router connessi al segmento. Gli LSA type 2 vengono inviati ai router di un'area e non ne superano i confini;

type 3,4

Questi messaggi passano da un'area ad un'altra adiacente. Sono originati dagli ABR (Area Border Router). ABR invia ad un’area informazioni relative ad un’altra area, sempre di cui fa parte. I type 3 contengono informazioni relative a route verso reti presenti nelle aree. I type 4 contengono informazioni di routing in direzione degli ASBR, ovvero router che inseriscono in OSPF route di altri protocolli come BGP;

type 5

Originati dagli ASBR e contenti informazioni per route relative a destinazioni su AS esterni. Sono di due tipi: E1 e E2. Di default E2. Le route esterne (external routes) vengono propagate dagli ASBR tramite gli LSA Type 5. Le route esterne si classificano a loro volta in:

   ·        external type 1 (E1)
   ·        external type 2 (E2)

La tipologia E1 propaga la route nella nuvola OSPF aggiornandone il costo con la propagazione. La tipologia E2 propaga la route nella nuvola OSPF lasciandone inalterato il costo.
    Per default gli LSA sono propagati attraverso tutte le interfacce su una stessa area con esclusione dell’interfacce da cui sono arrivati.    Due neighbor, anche adiacenti, si scambiano pacchetti Hello ogni 10 secondi (Hello interval). Se dopo quattro volte questo tempo (Dead interval) non arrivano Hello la vicinanza col neighbor passa dallo stato “FULL” allo stato “DOWN”. Hello e’ 30 secondi per NBMA (Non Broadcast Multi Access come ATM e Frame Relay). Col comando "show ip ospf neighbor" e' possibile individuare i router OSPF vicini con i quali si ha una sessione attiva:

RTA#sh ip ospf nei
Neighbor ID      Pri   State         Dead Time    Address         Interface
172.121.139.253    1   FULL/ -      00:00:36    172.121.139.90 Serial2/0

Gli LSA hanno un aging time di 1h oltre la quale sono cancellati. In ogni caso i router inviano ogni 30 minuti dei refresh indipendentemente da eventuali cambiamenti di topologia.

   C’e’ da considerare che nelle versioni di OSPF meno recenti si inviano refresh indiscriminatamente per tutti gli LSA generati. In seguito si e' adottato un TIMER per ogni LSA. Cio’ consente di inviare solo gli LSA effettivamente vecchi. Comunque questi ultimi vengono raggruppati per intervalli di 4 minuti di default (pacing timer) per generare 1 solo pacchetto di aggiornamento per piu’ LSA e meno spreco di banda e CPU.

OSPF funziona in modalita' diverse a seconda della rete su cui opera. Si distingue:

point-to-point

   E’ il caso dei collegamenti punto-punto tra router come un seriale con PPP o HDLC o un ISDN. L’interfaccia puo’ essere unnumbered. Se c’e’ l’ip il link e’ trattato come una stub network;

broadcast networks

   E’ il caso in cui il router e’ collegato ad esempio ad una rete ethernet. Se nella ethernet vi e’ un solo router con OSPF questa e’ trattata come stub network altrimenti si procede con l’elezione di un DR e la rete e trattata come transit network;

point-to-multipoint non-broadcast

   Si tratta delle reti Non Broadcast Multi Access come ATM e Frame Relay. Col point-to-multipoint la rete e vista come un insieme di collegamenti point-to-point. E’ il meno efficiente per l'elevata bandwidth utilizzata per gli aggiornamenti. Con il non-broadcast invece la rete viene vista come una rete ethernet. Si elegge un DR. In questo caso pero’ ogni router nella NBMA deve vedere gli altri cioe’ ci vuole una configurazione full-mesh;

Esempi

Questo esempio mostra una tipica configurazione OSPF nel caso di un router lato customer di una rete:

router ospf 4
log-adjacency-changes
network 192.168.65.12 0.0.0.3 area 0.0.5.0 <--- le interfacce che cadono in questa network avranno OSPF attivo
distribute-list 82 out
distribute-list 81 in

access-list 81 permit 172.16.20.50
access-list 81 deny any
access-list 82 deny any

Per resettare il processo OSPF e rigenerare la tabella di routing si usa "clear ip ospf process". Ecco l'invio di un comando clear ad un router con OSPF. La sequenza mostra tutto il processo
di avvio di una sessione OSPF e scambio di LSA:

prova-ct# clear ip ospf process
Reset ALL OSPF processes? [no]: yes

prova-ct#

*Mar 10 16:07:06.810: OSPF: Flushing External Links
*Mar 10 16:07:06.814: OSPF: Inc retrans unit nbr count index 1 (0/1) to 1/1

#
# 10.121.139.253 e' il nostro unico Neighbor ID
#

*Mar 10 16:07:06.814: OSPF: Set Nbr 10.121.139.253 1 first flood info from 0 (0)
to 62D48788 (792)
*Mar 10 16:07:06.814: OSPF: Init Nbr 10.121.139.253 1 next flood info to 62D48788

#
# 192.13.19.80 sono gli ip per la navigazione internet assegnati, definiti
# mediante statica e sono type 5 in quanto provengono da rete esterna
#

    # Quando si manda un LSA questo viene conservato in attesa dell'ACK
    # Se questo non arriva entro il "retransmit-interval", di default 5 sec.,
    # e selezionabile tra 1 a 65535 con "ip ospf retransmit-interval T"
    # Gli LSA sono in una retransmission-list finche' non arriva ACK

*Mar 10 16:07:06.814: OSPF: Add Type 5 LSA ID 192.13.19.80 Adv rtr 10.121.139.89
Seq 80000023 to Serial2/0 10.121.139.253 retransmission list
*Mar 10 16:07:06.814: OSPF: Start Serial2/0 10.121.139.253 retrans timer
*Mar 10 16:07:06.814: OSPF: Set idb next flood info from 0 (0) to 62D48788 (792)
*Mar 10 16:07:06.814: OSPF: Add Type 5 LSA ID 192.13.19.80 Adv rtr 10.121.139.89
Seq 80000023 to Serial2/0 flood list
*Mar 10 16:07:06.814: OSPF: Start Serial2/0 pacing timer for 33 msecs
*Mar 10 16:07:06.814: OSPF: Flushing Opaque AS Links

# Si trasmette LSA type 5 (si noti che siamo nello stesso istante di prima)

*Mar 10 16:07:06.814: OSPF: Flooding update on Serial2/0 to 224.0.0.5 Area 0
*Mar 10 16:07:06.814: OSPF: Send Type 5, LSID 192.13.19.80, Adv rtr 10.121.139.8
9, age 3600, seq 0x80000023 (0)
*Mar 10 16:07:06.814: OSPF: Create retrans unit 0x62D47E14/0x62D46CD4 1 (0/1) 1
*Mar 10 16:07:06.814: OSPF: Set nbr 1 (0/1) retrans to 4968 count to 1
*Mar 10 16:07:06.814: OSPF: Set idb next flood info from 62D48788 (792) to 0 (0)
*Mar 10 16:07:06.814: OSPF: Remove Type 5 LSA ID 192.13.19.80 Adv rtr 10.121.139
.89 Seq 80000023 from Serial2/0 flood list
*Mar 10 16:07:06.814: OSPF: Stop Serial2/0 flood timer

#
# LSA type 5 per la rete 192.13.90.80 e' stato inviato
#
# Finiti gli LSA type 5 adesso manda quello della seriale in questo caso 10.121.139.89
# che e' LSA type 1
#

*Mar 10 16:07:06.854: OSPF: Flushing Link states in area 0
*Mar 10 16:07:06.854: OSPF: Inc retrans unit nbr count index 1 (0/1) to 1/1
*Mar 10 16:07:06.854: OSPF: Set Nbr 10.121.139.253 1 first flood info from 0 (0)
to 62D49024 (1000)
*Mar 10 16:07:06.854: OSPF: Init Nbr 10.121.139.253 1 next flood info to 62D49024
*Mar 10 16:07:06.854: OSPF: Add Type 1 LSA ID 10.121.139.89 Adv rtr 10.121.139.89 Seq 80000036 to Serial2/0 10.121.139.253 retransmission list
*Mar 10 16:07:06.854: OSPF: Set idb next flood info from 0 (0) to 62D49024 (1000)
*Mar 10 16:07:06.854: OSPF: Add Type 1 LSA ID 10.121.139.89 Adv rtr 10.121.139.89 Seq 80000036 to Serial2/0 flood list
*Mar 10 16:07:06.854: OSPF: Start Serial2/0 pacing timer for 33 msecs
*Mar 10 16:07:06.854: OSPF: Flooding update on Serial2/0 to 224.0.0.5 Area 0
*Mar 10 16:07:06.854: OSPF: Send Type 1, LSID 10.121.139.89, Adv rtr 10.121.139.89, age 3600, seq 0x80000036 (0)
*Mar 10 16:07:06.854: OSPF: Create retrans unit 0x62D47E44/0x62D46B94 1 (0/1) 1
*Mar 10 16:07:06.854: OSPF: Set nbr 1 (0/1) retrans to 4736 count to 1
*Mar 10 16:07:06.854: OSPF: Set idb next flood info from 62D49024 (1000) to 0 (0)
*Mar 10 16:07:06.854: OSPF: Remove Type 1 LSA ID
10.121.139.89 Adv rtr 10.121.139.89 Seq 80000036 from Serial2/0 flood list

*Mar 10 16:07:06.854: OSPF: Stop Serial2/0 flood timer
*Mar 10 16:07:06.894: OSPF: Interface Serial2/0 going Down
*Mar 10 16:07:06.894: %OSPF-5-ADJCHG: Process 10, Nbr 10.121.139.253 on Serial2/0 from FULL to DOWN, Neighbor Down: Interface down or detached
*Mar 10 16:07:06.894: OSPF: Dec retrans unit nbr count index 1 (0/1) to 0/0
*Mar 10 16:07:06.894: OSPF: Free nbr retrans unit 0x62D47E44/0x62D46B94 0 total
0. Also Free nbr retrans block
*Mar 10 16:07:06.894: OSPF: Set Nbr 10.121.139.253 1 first flood info from 62D49024 (1000) to 0 (0)
*Mar 10 16:07:06.894: OSPF: Adjust Nbr 10.121.139.253 1 next flood info to 0
*Mar 10 16:07:06.894: OSPF: Remove Type 1 LSA ID 10.121.139.89 Adv rtr 10.121.139.89 Seq 80000036 from 10.121.139.253 retransmission list
*Mar 10 16:07:06.894: OSPF: Dec retrans unit nbr count index 1 (0/1) to 0/0
*Mar 10 16:07:06.894: OSPF: Free nbr retrans unit 0x62D47E14/0x62D46CD4 0 total0. Also Free nbr retrans block
*Mar 10 16:07:06.894: OSPF: Set Nbr 10.121.139.253 1 first flood info from 62D48788 (792) to 0 (0)
*Mar 10 16:07:06.894: OSPF: Adjust Nbr 10.121.139.253 1 next flood info to 0
*Mar 10 16:07:06.894: OSPF: Remove Type 5 LSA ID 192.13.19.80 Adv rtr 10.121.139.89 Seq 80000023 from 10.121.139.253 retransmission list
*Mar 10 16:07:06.894: OSPF: Stop nbr 10.121.139.253 retransmission timer
*Mar 10 16:07:06.894: OSPF: Interface Loopback1 going Down
*Mar 10 16:07:06.962: OSPF: Interface Serial2/0 going Up
*Mar 10 16:07:06.966: OSPF: Interface Loopback1 going Up
*Mar 10 16:07:07.394: OSPF: Build router LSA for area 0, router ID 10.121.139.89, seq 0x80000001

#
# Si passa allo stato 2WAY dopo che arriva hello dal vicino
#
# Si passa allo stato EXSTART quando si stabilisce chi e' master e chi slave
# Il router con il piu' alto IP address diviene il master
# E si manda un numero di sequenza che consente di determinare i vecchi LSA
#
# DBD sta per DataBaseDescriptor

# EXCHANGE: In questo stato il router scambia pacchetti DBD, che
# descrivono l'intero link-state database

*Mar 10 16:07:08.274: OSPF: Rcv hello from 10.121.139.253 area 0 from Serial2/0
10.121.139.90
*Mar 10 16:07:08.274: OSPF: 2 Way Communication to 10.121.139.253 on Serial2/0,state 2WAY
*Mar 10 16:07:08.274: OSPF: Send DBD to 10.121.139.253 on Serial2/0 seq 0x2573 opt 0x42 flag 0x7 len 32
*Mar 10 16:07:08.278: OSPF: End of hello processing
*Mar 10 16:07:08.294: OSPF: Rcv DBD from 10.121.139.253 on Serial2/0 seq 0x14AF opt 0x42 flag 0x7 len 32 mtu 1500 state EXSTART
*Mar 10 16:07:08.294: OSPF: NBR Negotiation Done. We are the SLAVE
*Mar 10 16:07:08.294: OSPF: Send DBD to 10.121.139.253 on Serial2/0 seq 0x14AF opt 0x42 flag 0x2 len 72
*Mar 10 16:07:08.334: OSPF: Rcv DBD from 10.121.139.253 on Serial2/0 seq 0x14B0 opt 0x42 flag 0x3 len 1472 mtu 1500 state EXCHANGE
*Mar 10 16:07:08.334: OSPF: Send DBD to 10.121.139.253 on Serial2/0 seq 0x14B0 opt 0x42 flag 0x0 len 32
*Mar 10 16:07:08.338: OSPF: Database request to 10.121.139.253
*Mar 10 16:07:08.338: OSPF: sent LS REQ packet to 10.121.139.90, length 864

#
#NOTARE L'INVIO DELLA MTU:
#Note:Cisco IOS ^® Software Release 12.0(3) introduced interface MTU mismatch detection. This detection involves OSPF advertising the interface
#MTU in the #DBD packets, which is in accordance with the OSPF RFC 2178 , appendix G.9. When a router receives a DBD packet advertising
#a MTU larger than the router can receive, the router ignores the DBD packet and the neighbor state remains in exstart. This prevents an adjacency
#from forming. To fix this problem, make sure the MTU are the same on both ends of a link.
#
#

*Mar 10 16:07:08.370: OSPF: Rcv DBD from 10.121.139.253 on Serial2/0 seq 0x14B1 opt 0x42 flag 0x3 len 1472 mtu 1500 state EXCHANGE
*Mar 10 16:07:08.374: OSPF: Send DBD to 10.121.139.253 on Serial2/0 seq 0x14B1 opt 0x42 flag 0x0 len 32
*Mar 10 16:07:08.390: OSPF: received update from 10.121.139.253, Serial2/0
*Mar 10 16:07:08.390: OSPF: Rcv Update Type 1, LSID 192.13.21.241, Adv rtr 192.13.21.241, age 1656, seq 0x80000879
*Mar 10 16:07:08.390: OSPF: Rcv Update Type 1, LSID 192.13.21.209, Adv rtr 192.13.21.209, age 958, seq 0x80001220
*Mar 10 16:07:08.390: OSPF: Rcv Update Type 1, LSID 192.13.21.197, Adv rtr 192.13.21.197, age 497, seq 0x80000FE3
*Mar 10 16:07:08.394: OSPF: Rcv Update Type 1, LSID 192.13.21.194, Adv rtr 192.13.21.194, age 1133, seq 0x8000017E
*Mar 10 16:07:08.394: OSPF: Rcv Update Type 1, LSID 192.13.21.189, Adv rtr 192.13.21.189, age 304, seq 0x80000E57

...

*Mar 10 16:07:08.546: OSPF: Received same lsa
*Mar 10 16:07:08.546: OSPF: Sending direct ACK on Serial2/0 to 10.121.139.253
*Mar 10 16:07:08.546: OSPF: Ack Type 1, LSID 192.13.21.209, Adv rtr 192.13.21.209, age 959, seq 0x80001220

...

*Mar 10 16:07:08.558: OSPF: Rcv Update Type 1, LSID 192.13.2.166, Adv rtr 192.13.2.166, age 1801, seq 0x800034BC
*Mar 10 16:07:08.558: OSPF: Received same lsa
*Mar 10 16:07:08.558: OSPF: Rcv Update Type 1, LSID 192.13.2.100, Adv rtr 192.13.2.100, age 237, seq 0x800060DA
*Mar 10 16:07:08.558: OSPF: Received same lsa
*Mar 10 16:07:08.558: OSPF: Rcv Update Type 1, LSID 192.13.2.15, Adv rtr 192.13.2.15, age 350, seq 0x800003DA

#
# router che formano un loop si inviano LSA tra loro finche' non c'e' un
# "Received same lsa"
#

*Mar 10 16:07:08.562: OSPF: Received same lsa
*Mar 10 16:07:08.562: OSPF: Rcv Update Type 1, LSID 192.13.2.8, Adv rtr 192.13.2.8, age 1076, seq 0x80001805

...

*Mar 10 16:08:01.894: OSPF: Rcv Update Type 3, LSID 10.121.131.4, Adv rtr 10.121.131.2, age 7, seq 0x80000679
*Mar 10 16:08:01.894: Mask /30
*Mar 10 16:08:01.894: OSPF: Rcv Update Type 3, LSID 10.121.131.8, Adv rtr 10.121.131.2, age 7, seq 0x80000EDC
*Mar 10 16:08:01.894: Mask /30
*Mar 10 16:08:01.894: OSPF: Rcv Update Type 3, LSID 10.121.131.12, Adv rtr 10.221.131.2, age 7, seq 0x800002F8

...

*Mar 10 16:08:04.410: OSPF: Ack Type 3, LSID 192.13.21.237, Adv rtr 10.121.131.2, age 7, seq 0x80000B01
*Mar 10 16:08:04.410: OSPF: Ack Type 4, LSID 192.13.21.237, Adv rtr 10.121.131.2, age 7, seq 0x80000B83
*Mar 10 16:08:04.410: OSPF: Ack Type 5, LSID 10.121.156.39, Adv rtr 10.121.136.252, age 5, seq 0x80000080
*Mar 10 16:08:07.238: OSPF: received update from 10.121.139.253, Serial2/0
*Mar 10 16:08:07.238: OSPF: Rcv Update Type 1, LSID 192.13.29.94, Adv rtr 192.13.29.94, age 6, seq 0x80000623
*Mar 10 16:08:08.274: OSPF: Rcv hello from 10.121.139.253 area 0 from Serial2/0 10.121.139.90
*Mar 10 16:08:08.274: OSPF: End of hello processing
*Mar 10 16:08:09.738: OSPF: Sending delayed ACK on Serial2/0
*Mar 10 16:08:09.738: OSPF: Ack Type 1, LSID 192.13.29.94, Adv rtr 192.13.29.94, age 6, seq 0x80000623

prova-ct#undebug all

Articolo versione beta 0.9 - ultima revisione 16/3/03

Altre letture

Consiglio di consultare l’enorme documentazione disponibile on-line nel sito della cisco http://www.cisco.com/ . E’ possibile trovare sempre tutto cio’ che si cerca.

Il materiale di questa pagina non e’ sponsorizzato o sottoscritto da Cisco Systems, Inc. Ciscoâ e’ un trademark di Cisco Systems, Inc. negli Stati Uniti e in altri stati. L’autore di questa pagina non si assume nessuna responsabilita’ e non da nessuna garanzia riguardante l’accuratezza e la completezza delle informazioni presenti nonche’ da conseguenze sull’uso delle informazioni presenti in questa pagina.
Il sito web ufficiale della Cisco e’ http://www.cisco.com. Nel caso si volesse utilizzare il contenuto di questa pagina nella forma in cui e’ presentato rivolgersi all’autore scrivendo a gianrico.fichera itesys.it.