Sunteți pe pagina 1din 29

Cisco Networking Academy

www.infoacademy.net

OSPF (Open Shortest Path First) – v 1.0.3

1. Generalitati
2. Router-ID-ul OSPF
3. Mesajele OSPF
4. Conditiile de a deveni vecini
5. Starile vecinilor OSPF
6. Router-ul Designate in retelele OSPF multiaccess (LAN si NBMA)
7. Tipuri de retele OSPF. OSPF in WAN
8. Algoritmul SPF. Metrica OSPF
9. Tipuri de LSA-uri
10. Troubleshooting OSPF
11. Multiarea OSPF
12. OSPF Virtual-link
13. Sumarizarea in OSPF
14. Autentificarea OSPF
15. Generarea de ruta default in OSPF
16. Filtrarea in OSPF
17. Optimizarea timpului de convergeta in OSPF (to do)
18. Miscelanee
19. Referinte

1. Generalitati:
- Este un protocol de routare standardizat ajuns la versiunea 3 (RFC 2740). Aceasta schimba informatii de rutare pentru IPv6.
La o data ulterioara se vor introduce specificatiile pentru a se permite schimbul de informatii si pentru IPv4. OSPF versiunea
2, redat in (RFC 2328), este subiectul acestui material.
- Este un protocol IGP clasless (trimite NM), de tip link-state, adica trimite in (unele din) mesaje sale informatii despre link-
uri (interfete direct conectate) impreuna cu „descrierea‟ lor (tip link, IP, NM, cost sa). Aceste informatii, obtinute de la toate
routerele din aceeasi arie, alcatuiesc LSDB-ul (Link State DataBase). Alte protocoale link-state sunt IS-IS (pentru CLNS si
IPv4/v6), DNA Phave IV (pentru DECNET), NLSP (pentru IPX).
- OSPF foloseste algoritmul Dijkstra (autor Edsger Dijkstra), numit si algoritmul SPF (Shortest Path First) pentru alegerea
cailor optime, acelasi ca si pentru protocolul ISO IS-IS.
- Utilizeaza arii pentru optimizarea folosirii resurselor hardware necesare functionarii sale, fapt dezirabil intr-o interetea de
dimensiuni mari. Resursele optimizate sunt:
o RAM – prin reducerea dimensiunii LSDB si a RIB-ului,
o CPU - timp si resurse procesor necesare gasirii cailor optime prin analiza unui LSDB mai redus,
o BW/RAM/CPU - reducerea numarului de mesaje OSPF trimise dintr-o arie in alta prin posibile sumarizari sau/si
filtrari pe routerele ce separa ariile OSPF,
o BW/RAM/CPU – prin reprezentarea informatiilor „dense‟ de routare dintr-o arie (LSA 1 si 2) in alta arie prin LSA-
uri de tip 3 – informatii tip distance vector, ce necesita mai putine resurse CPU pentru analiza.
- Foloseste in update-urile proprii structuri numite LSA-uri (Link State Advertisments) pentru schimbul de informatie de
routare. Sunt 11 tipuri de LSA-uri utilizate in diferite contexte, in functie, in principal, de design-ul retelei OSPF (a se vedea
punctul 9,‟Tipuri de LSA-uri‟)
- Trimite mesaje cu IP destinatie multicast (224.0.0.5 sau 224.0.0.6) sau unicast, TTL din headerul IP este 1 (in afara
tunelarii, a bridgeing-ului sau a virtual-link-urilor, nu este posibila forwardarea acestor mesaje de echip de L3+) , IP sursa
este IP-ul principal al interfetei de iesire, Protocol Number este 89.
- Fiecare mesaje OSPF contine un header OSPF alcatuit din campurile:
o Version – valoarea va fi 2 pentru OSPF versiunea 2 . Versiunea 2 este incompatibila cu versiunea 1 OSPF.
o Type – tipul mesajului. Are valoarea 1 - Hello, 2 – DBD, 3 – LSR, 4 – LSU, 5 – LSAck

Infoacademy – Romeo Lungu Page 1


Cisco Networking Academy
www.infoacademy.net

o Length – dimensiunea in bytes a packet-ului OSPF, inclusiv a headerului OSPF


o Router ID –ul unic al routerului (vezi mai jos pentru detalii/algoritmul de alegere)
o Area ID este area number asociat prin configuratie de
administrator unei interfete. O interfata poate fi asociata
unei singure arii. Poate lua forma unei adrese IP sau a
unui numar zecimal pe 32 de biti. Se configureaza cu:
 Router(config-router)# network <IP> <NM> area
<area-id> sau
 Router(config-if)# ip ospf <PID> area <area-id>

o Checksum – verifica integritatea packet-ului OSPF, mai


putin a campurilor folosite in autentificare.
o Authentification Type si Data – se reda tipul autentificarii: null, text sau md5 si detalii legate de aceasta. (a se
vedea discutia despre Autentificarea OSPF)

2. Router-ID-ul OSPF:
Imediat dupa pornirea procesului OSPF aceasta va alege Router ID-ul necesar identificarii unice a routerului nostru in domeniul
de routare OSPF. Acesta este un numar pe 32 de biti si are forma unei adrese IPv4 (NU este o adresa IP; poate avea valori intre
0.0.0.1 si 255.255.255.255). Pasii urmati de routerele Cisco sunt: (se va trece la pasul urmator doar daca cel anterior nu produce RID-
ul)
1. Se foloseste Router-ID-ul configurat manual de operator:
 Router(config-router)# router-id <RID>
2. Se foloseste adresa IP cea mai mare a oricarei interfete loopback active („up si up‟ configurate cu adresa IPv4) de pe router
in momentul pornirii/repornirii procesului OSPF. Se tine cont si de interfetele ce nu sunt configurate „de interes‟ pentru
OSPF.
3. Se foloseste adresa IP cea mai mare a oricarei interfete fizice sau logice active („up si up‟ configurate cu adresa IPv4) de pe
router in momentul pornirii/repornirii procesului OSPF. Se tine cont si de interfetele ce nu sunt configurate „de interes‟
pentru OSPF.

Nu este necesar ca respectivul IP sa fie publicat in interretea (separat sau ca parte a unui prefix) de catre OSPF/alt protocol de
rutare, desi aceasta ajuta in troubleshooting ulterior.
Pasii 2 si 3 pot produce un alt rezultat daca inaintea repornirii procesului OSPF se ridica/configureaza noi interfete sau se
opreste/deconfigureaza pentru IP interfata utilizata initial pentru alegerea RID-ului. Acest lucru este indezirabil in cazul in care
utilizam virtual-link-uri. Mentionam ca daca se pornesc doua (sau mai multe) procese OSPF pe acelasi router, fiecare dintre acestea
va trebui sa detina un RID propriu, diferit de al celorlalte procese OSPF.
In urma configurarii manuale se schimba imediat RID-ul, fara a fi necesara repornirea procesului OSPF, daca OSPF nu are inca
nici-o relatie de vecinatate. In caz contrar trebuie repornit procesul OSPF prin comanda Router# clear ip ospf [<pid>] process. Ca
urmare, se vor genera noi LSA-uri ce vor duce la noi calcule SPF pe routerele din process-domain-ul OSPF.
Pentru usurinta troubleshooting-ului se va alege adesea drept RID o adresa IP (de regula a unei interfete de loopback), se va
publica in update-urile de retea, se va configura intr-un server de DNS accesibil echipamentelor de retea rezolutia inversa de nume
necesara maparii RID-ului la un nume DNS „prietenos‟si se va configura pe router manual RID-ul pentru a ne asigura ca o interfata
de loopback ulterioara nu va modifica RID-ul OSPF.
In unele din output-urile OSPF se poate cere routerului afisarea numelor DNS in locul RID-ului prin comanda:
 Router(config)# ip ospf name-lookup
RID-ul se poate vizualiza cu:
 Router# show ip protocols
 Router# show ip ospf

3. Mesajele OSPF:

Infoacademy – Romeo Lungu Page 2


Cisco Networking Academy
www.infoacademy.net

- Hello: [Type1], este folosit pentru descoperirea si intretinerea relatiilor de vecinatate. Se utilizeaza si in procesul de alegere
(pe interfetele conectate in retele multiacces) a routerelor cu rol de DR si BDR. Sunt trimise la adresa IP multicast 224.0.0.5
(in retele OSPF de tip broadcast, point-to-point, point-to-multipoint broadcast) sau unicast (in retele OSPF de tip non-
broadcast multiacces, point-to-multipoint non-broadcast si virtual-link). Se trimit unreliable.

Mesajele Hello, pentru fiecare interfata in parte, contin, pe langa headerul comun OSPF si:
o Network Mask-ul IP-ului principal al interfetei de iesire.
o Hello si Dead interval – default-uri: pe interfetele cu BW =< T1 si incapsulare NBMA (FR, ATM, SMDS), hello-
time este 30 sec, dead-time 120 sec. Pe toate celelalte (ex: interfete cu incapsularea Ethernet, HDLC), hello-time
este 10 sec si dead-time 40 sec. Raportul de multiplicare x 4 nu este obligatoriu.
Se configureaza cu:
 Router(config-if)# ip ospf hello-interval <nr>
 Router(config-if)# ip ospf dead-interval { <nr> | minimal hello-multiplier <nr> }
o Neighbor IDs este o lista cu Router ID-urile (RID) routerelor vecine cu noi (ce pot fi zero, unul sau mai multe)
descoperite pana in acest moment pe acea interfata (le-am primit Hello-ul) si cu care avem parametri comuni de
configurare.
o Router Priority este un numar pe 8 biti [0-255] folosit la alegerea DR/BDR-ului (pentru algoritmul de alegere vezi
mai jos) in retelele OSPF multiacces (de exemplu, by-default: Ethernet, Frame Relay fizic sau subinterfata
multipoint). In retelele OSPF point-to-point valoarea primita de la vecin este ignorata, considerandu-se egala cu 0.
By default, valoarea prioritatii este de 1 in IOS-ul Cisco. In sistemul de operare JunOS (Juniper) prioritatea are, by-
default, valoarea 128.
Se configureaza cu:
 Router(config-if)# ip ospf priority <nr>
o DR si BDR IP address: daca se pot alege si s-au ales, vor fi redate in header sub forma IP-ului principal al acestor
routere din respectivul segment de retea.
o Options: flag pe 8 biti regasit in mesajul Hello, DBD si in LSA-uri ce contine capabilitati (configurate sau nu) ale
routerului sursa sau LSA-ului, relevante pentru stabilirea relatiei de vecinatate/acceptarea sau nu a LSA-
ului/tratarea speciala a LSA-ului. De interes este bitul E si bitul P. Se va reveni ulterior.

- Database Description (DD or DBD): [Type 2], este folosit pentru informarea partenerului de flooding a LSA-urilor (in
format sumarizat – sunt prezente doar headerele LSA) din propriul LSDB.
Se trimit reliable (cu confirmare de primire) prin trimiterea inapoi a unei copii a DBD-ului anterior primit.
DBD este utilizat si pentru negocierea rolului de master si slave folosit pentru a stabilii cine va initia descrierea
propriului LSDB (slave) si cine stabileste si incrementeza DD Sequence number-ul (un numar pe 32 de biti, pseudo-aleator
ales) asociat fiecarui mesaj DBD schimbat - master-ul incrementeaza DD Sequence number. Devine master router-ul cu
RID-ul cel mai mare.

In mesaj se trimite IP MTU al interfetei – acesta trebuie sa fie identic cu cel de pe interfata celuilalt router sau se va
ramane in starea de EXCHANGE. In cazul comunicarii de informatii de routare printr-un virtual link acest camp va avea
valoarea 0. Se poate configura in IOS ignorarea valorii IP MTU (util doar in cazuri speciale!):
 Router(config-if)# ip ospf mtu-ignore  trebuie configurata pe interfata cu MTU mic
 Router# debug ip ospf adj  “OSPF: Nbr 10.0.0.2 has smaller | bigger interface MTU”

 Router(config-if)# ip mtu <nr>  schimbi IPv4 MTU pe acea interfata


 Router(config-if)# mtu <nr>  schimbi MTU pentru orice protocol de L3 pe acea intf.
Nu toate interfetele suporta schimbarea parametrului MTU/IPv4 MTU. De exemplu, interfetele seriale permit in
general modificarea MTU.

 Router# show ip int <intf> | include MTU  vezi MTU pentru IPv4 pentru intf fa0/0
 Router# show int <intf> | include MTU  vezi MTU pentru orice protocol de L3 pe acea intf.
Odata configurat MTU pe o interfata se va modifica si IP MTU al acelei interfete. Ulterior insa putem schimba
acest parametru (IP MTU) la o valoare disitincta de MTU.

Mesajele DBD se trimit unicast la L3, mai putin in retelele OSPF de tip point-to-point unde se trimit multicast.
Infoacademy – Romeo Lungu Page 3
Cisco Networking Academy
www.infoacademy.net

- Link-State Request (LSR): [Type 3], se trimit pentru a cere routerului vecin, in detaliu, acele LSA-uri primite sumarizat
mai devreme si pe care noi nu le aveam in LSDB sau le avem cu un Sequence number mai mic (informatii vechi). Se trimit
unicast (in retele OSPF de tip broadcast) sau multicast (in retele OSPF de tip point-to-point).
- Link-State Update (LSU): [Type 4], se trimit in amanunt LSA-urile cerute anterior de vecin. Schimbul este reliable –
pentru confirmare se folosesc mesaje LSAck. Se trimit atat unicast (in retele OSPF de tip broadcast si non-broadcast) cat si
multicast (in retele OSPF de tip point-to-point sau broadcast)
- Link-State Acknowledgement (LSAck): [Type 5], sunt trimise pentru confirmarea primirii mesajului LSU. Se trimit
unreliable, multicast catre 224.0.0.5 / 224.0.0.6 (in retele OSPF de tip broadcast, point-to-point, point-to-multipoint) sau
unicast (in retele OSPF de tip non-broadcast, point-to-multipoint non-broadcast).

Captura pe o interfata fizica point-to-point (incapsulare HDLC) – o retea point-to-point dpdv al OSPF:

4. Conditiile de a deveni vecini:


Facem distinctie intre relatia de vecinatate – ne oprim la starea de „2WAY‟ cu routerul vecin si starea de adiacenta,
unde ajungem sa schimbam mesaje LSU in scopul sincronizarii LSDB-urilor (acestea devenind identice). Aceasta ultima
stare o regasim si cu numele de „FULL adjacency‟.

Rolul de stabilirea a relatiei de vecinatate o au mesajele Hello. Ele permit, pentru fiecare vecin in parte:
- Descoperirea routerelor OSPF din acelasi subnet logic (data-link fizic, tunel logic (GRE, IPIP), virtual-link OSPF)
- Monitorizeaza functionarea procesului OSPF de pe routerul vecin: este acesta inca pornit/configurat corect?
- Verifica identitatea/corespunderea anumitor parametri trimisi in mesajele Hello, fara de care nu devenim
vecini/pierdem relatia de vecinatate. Acestia sunt:
1. Acelasi numar al ariei (intre 0 si 232-1)
2. Acelasi NM al IP-ului principal de pe interfata. Conditia eate ignorata in cazul retelelor OSPF point-to-point si a
virtual link-urilor. In cazul configurarii ip unnumbered pe link-urile point-to-point, NM-ul trimis in Hello-uri va fi
0.0.0.0
3. Acelasi tip si configuratii particulare (key number si parola) de autentificare.
4. Acelasi Hello si Dead interval.

Infoacademy – Romeo Lungu Page 4


Cisco Networking Academy
www.infoacademy.net

5. Acelasi tip de arie (normal, stub, NSSA).


6. Router-ID-uri diferite. Unicitatea RID-ului este necesar a fi respectata in raport cu oricare alt router din arie.
Pentru detalii a se vedea sectiunea de troubleshooting.
7. IP-ul sursa al mesajelor OSPF primite trebuie sa se regaseasca in acelasi spatiu de adrese cu IP-ul principal al
interfetei routerului local. IP-ul sursa cu care se trimit mesajele OSPF este IP-ul principal al interfetei.
Conditia aceasta nu este obligatoriu a fi indeplinita daca cele doua routere se gasesc conectate la o retea OSPF de
tip point-to-point si ambele routere folosesc pentru adresarea IP metoda ip unnumbered.

Configuratii ce NU este necesar sa fie identice pentru a deveni vecini sunt:


a. Process-ID-ul (PID) OSPF – el are rol in a ne permite diferentierea intre mai multe procese OSPF pornite local, pe
acelasi router. Desi este posibila pornirea mai multor procese OSPF pe acelasi router lucrul acesta este realizat
arareori in practica:
 Router(config)# router ospf <PID>  intre 1 si 65535 (fara vreo legatura cu o arie!)

b. MTU-ul interfetelor vecine (vezi discutia de la mesajul DBD)

- Atentie! Desi nu este o conditie pentru a deveni vecini, este important pentru a obtine full reacheability ca toate routerele sa
cada de comun acord asupra alegerii sau nu a unui DR pentru fiecare segment de retea, cat si sa cada de comun acord asupra
identitatii acestuia.

5. Starile vecinilor OSPF:


- Down: inca nu s-au primit Hello-uri de la nici-un vecin pe acea interfata. Este prima faza. Se pot trimite Hello-uri in aceasta
etapa. Routerul se intoarce la acesta stare daca vecinul nu ne trimite Hello-uri timp de Dead-interval sau daca il
deconfiguram din comanda neighbor. Aceasta stare apare si daca interfata se duce in down la L1 sau L2.
- Attempt: nu am primit Hello-uri timp de Dead-interval de la vecinul configurat manual, insa noi trimitem acestuia mesaje
Hello unicast la Poll-interval (default 120 sec). Aceasta stare este disponibila doar in retele OSPF non-broadcast.
- Init: Am primit cel putin un Hello de la vecin, insa acesta nu cuprinde in lista de Neighbor-ID propriul nostru Router ID.
- 2way: In Hello-ul primit am gasit propriul RID. In aceasta etapa, in retelele OSPF multiacces, se poate trece la alegerea DR
si a BDR. 2WAY este o stare permanenta pentru doua routere DROther.
- ExStart: Se negociaza rolul de Master/Slave si se alege DD sequence number.
- Exchange: Se schimba mesaje DBD prin care se descriu sumarizat, prin headere LSA, propriile LSDB-uri.
- Loading: Se trimit mesaje LSR si LSU prin care se cer/schimba LSA-urile de interes.
- Full adjaceny: routerele au LSDB-uri identice ce descriu aria lor comuna (LSDB-urile sunt sincronizate). Incepe calculul
SPF pentru extragerea de prefixe in scopul instalarii lor in RIB.

Tranzitia de la o stare la alta se poate monitoriza in sistemul de logging prin introducerea comenzii (by-default pornita):
 Router(config-router)# log-adjacency-changes [detail] <-- parametrul detail nu este default

6. Routerul Designate in retelele OSPF multiaccess (LAN si NBMA):


OSPF A fost proiectat sa permita alegerea in retelele OSPF unde pot exista 2 sau mai multe routere (retele OSPF multiacces) a
doua routere cu roluri specializate, numite Designate Router (DR) si Backup Designate Router (BDR).
Rolurile DR-ului sunt de a:
- Optimiza flooding-ului initial (schimbul de mesaje OSPF) intre routerele conectate la acea retea multiacces, fara de care,
schimbul de mesaje OSPF local ar presupune multe transferuri inutile (redundante) cu consum de BW si CPU – adica, in
absenta DR, fiecare router ar deveni adiacent cu fiecare dintre celelalte routere din data-link, comunicand ulterior cu fiecare
dintre acestea, ori de cate ori ar primi un LSA de interes. Numarul de adiacente rezultate ar fi x(x-1)/2, unde x = nr de
routere. Numarul de mesaje OSPF introduse in retea in acest caz va fi de y, unde y > x. Folosirea DR-ului reduce numarul
de adiacente la (2x-3).

- Celalalt rol este de creare a LSA-urilor de tipul 2 ce reprezinta aceasta retea multiacces in LSDB-ul tuturor routerelor din
aceiasi arie, LSA ce reda NM asociat acestui subnet, numarul cat si RID-ul routerelor conectate la aceasta retea multiacces

Infoacademy – Romeo Lungu Page 5


Cisco Networking Academy
www.infoacademy.net

(DR-ul incluzandu-se si pe sine in lista). LSA de tipul 2 se spune ca reprezinta reteaua multiacces sub forma unui
pseudonode (pseudorouter) direct conectat la toate routerele din acel segment.

In alegerea DR si BDR-ului se urmeaza pasii:


1. este ales DR in acea retea OSPF multiacces routerul cu prioritatea cea mai mare pe interfata catre respectiva retea.
Prioritatea 0 ne asigura ca acest router nu va deveni nici-o data DR sau BDR; prioritatea 255 insa nu garanteaza ca routerul
nostru va fi ales DR, el putand ajunge BDR (sau chiar DROther) in cazul existentei unui alt router in respectivul data-link cu
aceeasi prioritate 255 dar un RID mai mare.
Prioritatea OSPF se configureaza prin:
 Router(config-if)# ip ospf priority <priority>
se vizualizeza prin:
 Router# show ip ospf interface [<intf>] brief

2. In conditii de prioritati egale devine DR routerul cu RID-ul cel mai mare.


3. Routerul cu prioritatea imediat mai mica (sau, in conditii de prioritate egala, cu RID-ul imediat mai mic) va fi ales BDR.

In retelele OSPF multiacces:


- Unde exista doar un singur router OSPF acesta va ajunge “formal” DR, insa nu va indeplinii rolurile acestuia, adica nu va
genera un LSA de tip 2 si nici nu va optimiza flooding-ul in acel data-link.
- Unde exista doua routere, by-default, unul va deveni DR si altul BDR.
- Unde exista mai mult de doua routere, un router va deveni DR, unul va deveni BDR si toate celalalte vor deveni DROther.
Doar routerele DR si BDR stabilesc relatii de adiacenta cu toate celelalte routere din reteaua multiacces (inclusiv intre ele
doua). Routerele DROther se opresc la starea de 2WAY intre ele.
In interiorul data-link-ului multiacces se actualizeaza/propaga informatiile de routare prin intermediul routerului DR.
- Daca DR este inchis, scos din retea, nu raspunde cu mesaje OSPF corespunzatoare timp de Wait time, BDR va prelua rolul
de DR in acea retea (indiferent de prioritatea/RID-ul routerelor DROther), moment urmat de alegerea dintre DROther a unui
nou BDR.
- Daca este dezactivat routerul cu rol de BDR in acel data-link se alege din randul routerelor ramase un nou BDR.
- Daca DR-ul anterior ales are manual schimbata prioritatea la valoarea 0, acesta pierde imediat statutul de DR, vechiul BDR
fiind promovat la rolul de DR.
- Un router nou, pornit in reteaua multiacces, nu va putea prelua rolul de DR sau BDR daca acestea au fost deja alese,
indiferent de prioritatea si RID-ul sau (nu exista preemption in OSPF asa cum se intampla in protocolul de routare IS-IS).
- Routerele DR si BDR primesc mesajele trimise la adresa 224.0.0.6 de routerele DROther din respectiva retea multiacces.
Doar DR trimite inapoi in aceeasi retea un LSU propriu cu adresa destinatie 224.0.0.5 ce contine noile LSA-uri menit sa
informeze routerele DROther locale despre informatia de routare.
- La pornirea unui router nou intr-o retea multiacces, daca Hello-urile pe care le primeste mentioneaza deja un DR si BDR,
acestea vor fi acceptate ca atare (nu vor avea loc noi alegeri). In absenta mesajelor Hello, sau in cazul neprecizarii acestuia
(IP-urile DR/BDR au valoarea 0.0.0.0) acest router va astepta Wait-time (egal cu Dead-interval pentru acel link), pentru
alegerea DR si BDR. Ordinea in care routerele boot-eaza in retea (devine operational OSPF pentru acel data-link) este
importanta, pentru ca daca se intarzie suficient de mult pornirea procesului OSPF, un router, menit de administrator sa
devina DR ar putea ajunge BDR sau chiar DROther. Prin urmare, pentru a ne asigura de caracterul determinist al alegerilor,
o recomandare este configurarea cu prioritatea 0 a tuturor routerelor ce NU trebuie sa devina DR:
 Router(config-if)# ip ospf priority 0

Important:
In retelele OSPF point-to-point si point-to-multipoint (broadcast sau non-broadcast) nu se aleg niciodata routere cu rol de
DR si BDR.
In retelele OSPF broadcast si non-broadcast se aleg, by-default, routere cu rol de DR si BDR

Output al Router# show ip ospf neighbors (Pe coloana de „State‟ apare starea router-ului meu in raport cu acel vecin cat si
rolul acelui vecin in data-link-ul comun):

Infoacademy – Romeo Lungu Page 6


Cisco Networking Academy
www.infoacademy.net

7. Tipuri de retele OSPF. OSPF in WAN:


Din punct de vedere OSPF retelele se impart in:
1. Broadcast multiacces (ex, by-default: Ethernet, Token Ring, FDDI, sa)
2. Non-Broadcast MultiAcces - NBMA (ex, by-default: interfata fizica / subinterfata multipoint Frame Relay/ATM,
X.25, SMDS sa)
3. Point-to-point (ex, by-default: PPP, HDLC, subinterfata point-to-point Frame Relay/ATM)
4. Demand circuits (configurare manuala sau automat invatata de la vecin)

Circuitele on Demand (DC) sunt configurate manual sau automat pe una sau mai multe interfete ale router-ului nostru in
scopul anularii trimiterii mesajelor Hello periodice cat si a LSA-urilor cu rol de Refresh generate la aproximativ 1800
secunde. Motivul pentru care ne-am dori aceste efecte este acela ca, uneori, schimbul de mesaje intre doua sau mai multe
routere OSPF se realizeaza prin canale cu latime mica de banda sau prin canale de comunicatie de tip on-demand (ex: dial-
up, ISDN sau SVC-uri X.25), unde nu dorim pastrarea in stare activa a sesiunii de comunicatie (pentru trimiterea Hello-
urilor) datorita costurilor recurente asociate.

Configurarea on-demand se poate realiza pe orice interfata de interes pentru OSPF, insa numai pe interfetele configurate in
retele OSPF de tip point-to-point sau point-to-multipoint se anuleaza trimiterea periodica a Hello-urilor. In cazul tuturor
celorlate tipuri de retele OSPF se anuleaza doar Refresh-ul periodic al LSA-urilor (vezi mai jos), nu insa si trimiterea
mesajelor Hello. Schimbul de informatii de routare are loc doar la descoperirea initiala a vecinului cat si ulterior, la
detectarea unei modificari de topologie. In rest, in absenta mesajelor Hello si chiar si in cazul unui link L2 down (interfete
seriale), se pastreaza relatia de adiacenta cu routerul/routerele vecin(e).
Atentie! Toate routerele din aria unde se regaseste link-ul configurat cu DC trebuie sa fie capabile sa inteleaga DC.

Datorita faptului ca nu se face refresh LSA-urilor proprii cat si a celor generate de alte routere (se trimit totusi noi LSA-uri
in urma modificarilor de topologie) este important ca acestea sa nu faca Age-out in LSDB-ul nici-unuia din routerele din
process-domain-ul OSPF ce contine acele LSA-uri. Corespunzator, toate routerele din process-domain-ul OSPF (cu cateva
exceptii ce le vom reda imediat) trebuie sa fie capabile de DC. Aceasta capabilitatea este comunicata in interiorul mesajelor
OSPF (Hello, DBD, LSA-uri din LSU) prin campul options. LSA-urile ce nu trebuie sa faca Age-out sunt transmise la
randul lor avand bitul cel mai semnificativ al campului Age setat la valoarea 1 – apar in show-urile IOS-ului Cisco cu DNA
(Do Not Age). Daca in process-domain-ul OSPF nu toate routerele sunt capabile de DC atunci acele routere configurate sa
functioneze cu DC vor continua sa faca Refresh al LSA-urilor pentru a evita Age-out-ul acestora in LSDB-ul routerelor
incapabile de DC – efect indezirabil.
Doua solutii la aceasta problema sunt:
1. Conform RFC-ului 1793, aria ce contine routerele incapabile de DC sa fie configurata drept o arie stubby, totally
stuby, NSSA sau totally NSSA.
2. Aria ce contine link-ul on-demand sa fie ea insasi configurata de tip stubby, totally stuby, NSSA sau totally NSSA,
deci sa fie o arie non-backbone. Drept urmare aceasta arie nu va primi Indication LSA generat de ABR-urile ariilor
unde se gasesc routere incapabile de DC. (Indication LSA este un LSA de tip 4 al carui Link State ID este identic cu
Advertising Router, adica contine Router ID-ul respectivului ABR, si are o metrica infinita egala cu 224-1). Acest
LSA nu este flood-at in ariile de tip stub.

Configurarea DC:
 Router(config-if) # ip ospf demand-circuit
Este suficienta configurarea doar pe interfata unuia dintre cele doua routere, celalalt auto-configurandu-se cu aceasta
functionalitate (daca o recunoaste); in caz alternativ o ignora - in cazul topologiilor fizice de tip hub and spoke este
suficienta configurarea DC pe routerul hub.

Infoacademy – Romeo Lungu Page 7


Cisco Networking Academy
www.infoacademy.net

O functionalitate similara este oferita de OSPF Flood Reduction – aceasta asigura anularea trimiterii la aproximativ 1800
de secunde a LSA-urilor cu rol de Refresh. Ea nu anuleaza schimbul de mesaje Hello.
Configurarea Flood Reduction:
 Router(config-if) # ip ospf flood-reduction
Se configureaza manual pe ambele interfete ale celor doua routere.

Retele OSPF (OSPF network types):


OSPF poate fi configurat sa functioneze in 5 tipuri de retele OSPF, indiferent de tipul de interfata si protocol de L2. Un al
6-lea tip, loopback, este neconfigurabil si se aplica doar in cazul interfetelor de loopback. Diferentele dintre aceste tipuri se
reflecta prin:
2. Alegerea DR / BDR (caderea sau nu de comun accord a alegerii acestor routere este o incompatibilitate posibila
intre vecini. Ea duce la stabilirea relatiei de vecinatate dar nu si la schimbul de informatii de routare)
3. Folosirea mesajelor de tip multicast sau unicast (potentiala problema in retele non-broadcast)
4. Alegerea NEXT-HOP-ului catre prefixele instalate in RIB (potentiala problema in retele partial mesh)
5. Diferenta dintre Hello si Dead time-ului ales (aceasta deosebire impiedica stabilirea vecinatatii)

Caracterisiticile celor 6 tipuri de retele OSPF apar in tabelul de mai jos:


Tabel 1:
Necesita Necesita Se trimite Hello / Mai mult Se publica Standard Compa- NEXT-
Nume tip
(se alege) comanda Hello m-cast Dead de 2 un host IETF? tibile? HOP?
retea OSPF
DR/BDR? neighbor? sau u-cast? interval routere? route?(6) (3) (4) (5)

Broadcast Da Nu Multicast 10 / 40 Da Nu Nu X Spoke


Point-to-point
(1) Nu Nu Multicast 10 / 40 Nu Nu Nu O Hub
(2)
NBMA Da Da Unicast 30 / 120 Da Nu Da X Spoke
Point-to-
multipoint Nu Nu Multicast 30 / 120 Da Da Da O Hub
[broadcast] (7)
Point-to-
multipoint Nu Da Unicast 30 / 120 Da Da Nu O Hub
non-broadcast
Loopback Nu - - - Nu Da - - -

Nume tip
Spatiu de adrese? Tpopologia logica?
retea OSPF
Broadcast 1 singur subnet Full mesh, partial mesh
Point-to-point 1 singur subnet pe Partial mesh, hub &
(1)
subintf p-t-p/VC spoke
NBMA (2) 1 singur subnet Full mesh, partial mesh
Point-to-
Partial mesh, hub &
multipoint 1 singur subnet
spoke
[broadcast] (7)
Point-to-
Partial mesh, hub &
multipoint 1 singur subnet
spoke
non-broadcast
Loopback - -

(1)
– tip de retea OSPF default pentru interfetele fizice cu incapsulare HDLC, PPP, subinterfete point-to-point Frame-Relay. In
cazul acestui tip de retea, OSPF trimite toate mesajele cu IP destinatie multicast 224.0.0.5
(2)
– tip de retea OSPF default pentru interfetele fizice cu incapsulare Frame-Relay (inclusiv subinterfete multipoint), ATM,
SMDS, X.25
(3)
– „Nu‟: extensie Cisco OSPF in retele WAN; „Da‟: standard redat in RFC 2328

Infoacademy – Romeo Lungu Page 8


Cisco Networking Academy
www.infoacademy.net

(4)
– trebuie modificat Hello/Dead time pentru a obtine relatia de vecinatate si adiacenta
(5)
– Intrebare: intr-o retea hub & spoke (partial mesh), situati fiind pe un spoke, al cui IP NEXT-HOP apare in RIB pentru
routele altui spoke?
(6)
– in RIB, conform LSDB, nu va apare NM-ul corespunzator configurat pe interfata, ci un NM egal cu 32. Celelalte tipuri de
retele OSPF au drept efect instalarea in RIB a NM-ului efectiv configurat.
(7)
– Subtipul „broadcast‟ este default-ul pentru tipul de retea OSPF point-to-multipoint.

Daca un router are configurata comanda neighbor, aceasta nu este necesar a fi configurata pe routerul vecin (acesta va afla
IP-ul routerului noastru din IP-ul sursa al Hello-ului unicast primit). Similar, daca vecinul trimite Hello-uri multicast, iar noi am
fost configurati sa nu trimitem Hello-uri multicast si nu avem (inca) configurata adresa unicast a vecinului, este suficient sa
primim primul Hello de la vecin pentru a-i afla adresa si a-i trimite de acum inainte Hello-uri unicast.

Retelele NBMA (Non Broadcast MultiAcces) se caracterizeaza prin, fie imposibilitatea trimiterii de mesaje la L2 de tip
broadcast/multicast, fie prin posibilitatea trimiterii acestora insa sub forma unor unicasturi replicate (numite pseudo-broadcast).
In retelele de acest tip (by-default pe interfetele fizice sau pe subinterfetele multipoint ce incapsuleaza Frame Relay, ATM sau
SMDS) trebuie, fie configurate in OSPF comenzi de tip neighbor, fie schimbat „tipul retelei OSPF‟ cu ajutorul comenzii ip ospf
network. Odata schimbat acest tip (din NBMA) cu unul ce suporta broadcast (de ex: broadcast, sau point-to-multipoint
broadcast) trebuie avut grija in a configura pseudo-broadcast-ul prin adaugarea parametrului broadcast la comenzile de mapare
manuala L3 –> L2 Frame Relay, sau de a folosi Invers ARP pentru acele VC-uri (in acest caz se configureaza automat pseudo-
broadcast-ul pentru respectivele VC-uri).
Spre deosebire, in retelele OSPF broadcast si in retelele OSPF point-to-point se permite trimiterea de mesaje cu adresa de
L3 destinatie multicast sau unicast, mesaje ce au drept adresa destinatie de L2 adresa multicast sau unicast a vecinului de interes.

In retelele NBMA, unde se alege DR si BDR, tinem cont de urmatoarele considerente:


In topologiile full-mesh fizice si logice alegerea (acestea sunt similare topologiilor multiaccess LAN) DR si BDR
este mai putin importanta; se poate influenta administrativ (prin modificarea priority si RID) dupa criterii hardware (putere
CPU, memorie RAM, BW contractat)
In topologiile partial mesh, mai ales hub (simplu ori dublu) and spoke, trebuie avut grija ca hub-ul sa devina DR (si
daca exista un al 2-lea hub acesta sa devina BDR; in absenta acestui al 2-lea hub sa nu existe BDR) pentru ca este
obligatoriu pentru diseminarea informatiei de routare ca DR-ul sa poata comunica direct cu toate routerele (spoke-urile) din
reteaua multiacces. In reteaua FR aceasta se realizeaza prin intermediul VC-urilor (Circuitelor Virtuale).

Comanda neighbor are, by-default, asociata prioritatea 0. Routerul cu aceasta comanda va folosi cea mai mare
prioritate dintre cea primita prin mesajul Hello de la respectivul vecin (dependenta de comanda ip ospf priority configurata
pe interfata respectivului vecin) si prioritatea configurata local ca parametru al comenzii neighbor. Prin urmare, in retelele
hub and spoke, trebuie configurat pe toate routerele spoke o prioritate egala cu 0. Comanda neighbor nu este necesar a fi
configurata pe ambele routere, DR-ul (hub-ul) fiind cel mai potrivit pentru aceasta.

Configurarea de subinterfete point-to-point pe routerul Hub si Spoke-uri, asociate fiecare cu propriul spatiu de
adrese IPv4, anuleaza problema alegerii DR/BDR, insa introduce o potentiala irosire de adrese IPv4, o cresterea a numarului
de rute din RIB-ul celorlalte routere din arie, cat si o crestere a memoriei necesare pentru LSDB.

O solutie convenabila (ce nu necesita alegerea DR/BDR si ce foloseste un singur spatiu de adrese IPv4) este
configurarea tuturor interfetelor/subinterfetelor cu comanda ip ospf network point-to-multipoint prin care cerem OSPF sa
trateze reteaua ca o topologie de link-uri point-to-point, ceea ce inseamna ca spoke-urile vor avea next-hop pentru routele
invatate de la hub (si primite de acesta de la alte spoke-uri) IP-ul hub-ului si ca nu se vor realiza alegeri DR/BDR. Aceasta
rezolva la L3 potentiale probleme legate de „next-hop unreachable‟. In acest caz, in RIB-ul fiecarui router din acea arie va
apare sub forma de host routes IP-ul tuturor routerelor direct conectate in reteaua point-to-multipoint. In aceasta retea OSPF
fiecare router va deveni adiacent cu fiecare din routerele vecine cu care poate comunica la L3/L2 OSI. In LSA-ul 1 routerul
va descrie relatia de adiacenta de o maniera similara cu retelele OSPF point-to-point, anume printr-un link ce descrie RID
vecin si IP-ul propriu si apoi printr-un al doilea link ce descrie IP-ul propriu si NM-ul /32. Alte routere din arie nu vor
cunoaste NM-ul efectiv utilizat in acel data-link ci vor cunoaste doar IP-urile routerelor conectate in acel segment de retea,
impreuna cu NM-ul 255.255.255.255.

Infoacademy – Romeo Lungu Page 9


Cisco Networking Academy
www.infoacademy.net

8. Algoritmul Shortest Path First:


Algoritmul Dijkstra sau SPF este responsabil pentru crearea dintr-un graf (o topologie redundanta in care routerele sunt
noduri ale topologiei iar link-urile dintre routere sunt „frunze‟) a unui arbore – un graf lipsit de redundanta. Link-urile, cat si
„frunzele‟ au asociate lor un cost, ce este folosit pentru calculul metricii catre fiecare nod (router) in parte. Calculul presupune,
avand drept sistem de referinta routerul meu, adunarea costurilor de pe interfetele de iesire catre acel nod.
Pe routerele Cisco costul se calculeaza folosind formula BW_referinta (bps) /BW (bps). BW folosit este BW administrativ
stabilit de comanda bandwidth pentru acea interfata. BW_referinta are by default valoarea 100 Mb (sau 100.000.000 biti), si va
trebui schimbat daca in inter-reteaua noastra BW link-urilor este mai mare de 100 Mbps:
 Router(config-router)# auto-cost [reference bandwidth <Mbps>]  Mbps intre 1 si 4294967
Costul OSPF al unei interfete poate fi schimbat, respectiv vizualizat cu comenzile:
 Router(config-if)# bandwidth <kbps>  modificare indirecta a costului
 Router(config-if)# ip ospf cost <nr>  modificare directa a costului. Nr intre 1 si 65535
 Router# show ip ospf interface [brief]

Pe o interfata, costul configurat manual este cel utilizat de OSPF, chiar daca s-a modificat BW administrativ. In absenta
acestei comenzi se tine cont de BW default sau de cel configurat administrativ. Daca in urma calculului de cost rezultatul
obtinut este fractionar se va rotunji in jos. Daca costul calculat va fi mai mic decat 1 se va considera egal cu 1.
Metrica maxima este de 65535 (216-1) in cazul LSA-ului de tip 1 si de 16,777,215 (224-1) in cazul LSA-ului de tip 3, 4, 5 si
7.
Algoritmul cere ca toate routerele din aceeasi arie sa aiba aceleasi LSA de tip 1 si 2 ce descriu aria comuna in LSDB, fapt ce
are repercursiuni asupra filtrarii LSA-urilor ce intra/ies din LSDB – mai exact, este interzisa filtrarea LSA-urilor de tip 1 si 2 in
interiorul ariei de origine.

La primirea unui LSU cu LSA-uri „de interes‟ acestea vor fi flood-ate pe toate celelalte interfete configurate pentru OSPF
din aceeasi arie, si abia apoi va fi analizat LSDB-ul actualizat, urmand apoi, daca este necesara, actualizarea RIB-ului.
Trimiterea informatiei de routare, urmata ulterior de analiza sa in scopul popularii RIB este un avantaj al protocoalelor link state
tradus intr-o viteza de convergenta mai mica fata de protocoalele distance vector ce intai analizeaza continutul update-ului daca
este „de interes‟, instaleaza prefixul primit in RIB si doar apoi trimit informatia de routare pe (alte) interfete.
Un alt avantaj fata de protocoalele distance vector este ca, atunci cand un link devine „down‟ nu sunt trimise in retea de
router-ul respectiv update-uri cu potential multe prefixe devenite acum inaccesibile – ceea ce poate insemna un volum
considerabil de informatie de control in retelele mari si foarte mari. Protocoale link-state vor trimite un singur LSU ce contine un
router LSA actualizat ce va nu va descrie conexiunea acum pierduta a acestui router la link-ul down. Este posibil ca si celalalt
capat al data-link-ului down sa poata comunica cu restul retelei OSPF, caz in care va trimite si el un LSU propriu.

Pentru evitarea pastrarii in LSDB a unor informatii ce nu (mai) corespund realitatii, fiecarui Links State Advertisment
(unitate de distribuire a informatiilor de routare in OSPF), ii este asociat un LS Age. Se va incrementa in fiecare secunda age-ul
fiecarui LSA propriu sau primit din LSDB. Routerul ce a generat acel LSA (si l-a propagat printr-un LSU) i-a asociat initial un
LS Age de 1, ce este incrementat in LSDB-ul propriu, al routerelor vecine, cat si la trimiterea LSA-ului pe alta interfata, catre alt
vecin. Incrementarea se face cu, by-default, 1 secunda (InfTransDelay). Se configureaza:
 Router(config-if)# ip ospf transmit-delay <sec> intre 1 si 65535

Metoda aleasa pentru garantarea corectitudinii informatiilor de routare este aceea de a ne asiguram ca daca routerul ce a
generat initial acel LSA nu-l retransmite mai tarziu, peste LSRefreshTime (by-default 30 minute), la implinirea MaxAge (by-
default 60 minute), acel LSA va fi aruncat de catre toate routerele, nu inainte de a trimite la randul lor un LSA cu MaxAge (3600
secunde) routerelor vecine pentru a le cere si acestora sa renunte la informatia „invechita'. Informatia de routare trimisa la fiecare
LSRefreshTime contine descrierea detaliata a LSA-urilor. Acestea vor avea sequence number incrementat cu unu.

Infoacademy – Romeo Lungu Page 10


Cisco Networking Academy
www.infoacademy.net

Pentru evitatarea buclelor de routare, in conditiile schimbului de informatie de routare intre arii sub forma distance vector
(prefix, prefix-length, cost), este introdusa regula ca schimbul informatiei de routare sa nu fie permis intre arii decat prin
intermediul ariei 0, numita aria backbone. Cu alte cuvinte, ariile non-zero vor trebui sa fie conectate la aria zero pentru a putea
trimite/primii informatii de routare catre/de la celalalte arii.
In conditiile imposibilitatii configurarii unei noi arii tangenta la aria zero sau/si ca urmare a paritionarii ariei zero (ce nu ar
permite repectarea regulii identitatii LSDB-ului tuturor routerelor din arie) se pot folosii linkuri-virtuale (a se vedea discutia de
la punctul 12).

In urma descoperiri routerului vecin prin intermediul mesajelor Hello parvenite de la acesta, routerul nostru ii va trimite un
Hello unicast in care va trece toti vecinii cunoscuti pana in prezent cat si DR-ul si BDR-ul din data-link-ul local (daca s-au ales
deja). Drept rezultat, routerul vecin va „avansa‟ la two-way relatia cu routerul nostru.

Intr-o retea multiacces, daca un DROther are de trimis un LSU cu unul sau mai multe LSA de interes, acesta il va trimite
catre 224.0.0.6 (ALLOSPFDR). DR-ul va trimite un LSU la randul sau catre 224.0.0.5 (ALLOSPFRouters) inapoi in acelasi
data-link pentru a informa restul routerelor DROTHER de informatiile noi de routare.

Functionarea OSFP odata incheiat procesul de flooding initial:


In aceasta etapa toate routerele au aceleasi LSA-uri in LSDB in aria lor comuna.
- Fiecare router trimite Hello-uri in mod regulat
- Fiecare router asteapta mesaje de tip Hello de la vecini. Neprimirea lor in intervalul Dead va duce la pierderea
relatiei de vecinatate
- Fiecare router reflood-eaza la aproximativ LSRefresh interval (1800 secunde + 240 LSA-group Pacing) unul sau
mai multe LSU ce contin LSA-urile proprii, nu inainte insa de a incrementa cu 1 Sequence Nr-ul fiecarui LSA.
- Fiecare router se asteapta sa primeasca un LSA nou (seq number mai mare) pentru fiecare LSA non-propriu din
LSDB in intervalul MaxAge (3600 secunde) al acelui LSA. Alternativ, va renunta la acesta.

Modificarile OSPF care produc calcule SPF sunt:


- S-a modificat campul option
- LS Age este setata la MaxAge
- Lungimea campului length din header-ul LSA este diferita de cea veche
- Continutul LSA-ului (exceptand headerul) difera ce cel cunoscut

Regula alegerii caii optime in OSPF cere ca, in conditiile unor cai OSPF de tipuri diferite catre acelasi prefix, sa fie
preferate, in ordine:
1. Routele intra-area  simbol O
2. Routele inter-area  simbol O IA
3. Routele externe de tip 1 (E1)  simbol O E1
4. Routele externe de tip 2 (E2)  simbol O E2
5. La cost egal pentru rutele de tip E2 si FORWARDING ADDRESS nesetat (egal cu 0.0.0.0), se alege calea cu
costul OSPF cumulat (intra si inter-area) cel mai mic catre ASBR.
6. La cost egal pentru rutele de tip E2 si FORWARDING ADDRESS setat de ASBR (diferit de 0.0.0.0), se alege
calea cu costul OSPF cumulat (intra si inter-area) cel mai mic catre FORWARDING ADDRESS.

In cazul alegerii intre rute de acelasi tip, se utilizeaza drept criteriu metrica cea mai mica. In conditii de metrica egala, se pot
instala, by-default, pana la 4 cai de cost egal in RIB. Numarul maxim este de 32 cai de cost egal in IOS-uri recente (ex. vers
15.0).
In cazul IOS-ului Cisco, daca exista deja o ruta in RIB pentru care s-au primit acum informatii de routare noi, acea ruta se
foloseste pentru comutarea de pachete atat timp cat aceasta nu este inca actualizata.

Setarea de ASBR a unui FORWARDING ADDRESS diferit de 0.0.0.0 depinde de indeplinirea tuturor conditiilor
urmatoare:
1. OSPF este activat pe interfata ASBR catre NEXT HOP,
2. Respectiva interfata NU este pasivizata pentru OSPF,
Infoacademy – Romeo Lungu Page 11
Cisco Networking Academy
www.infoacademy.net

3. Respectiva interfata NU este conectata intr-o retea OSPF de tip point-to-point sau point-to-multipoint.

Routele OSPF intr-area, inter-area si externe (E1/N1 sau E2/N2) au asociate, fiecare o distanta administrativa, by default
egala, pentru toate trei tipurile de rute, cu 110. Se configureaza cu comanda:
 Router(config-router)# distance ospf { intra-area <AD> | inter-area <AD> | external <AD> }
 AD este un numar intreg intre 1 si 255
O alta comanda ce are drept efect modificarea distantei aministrative pentru toate cele trei tipuri de rute la o singura valoare
este:
 Router(config-router)# distance <AD> [<RID> <WM> [<ACL>]]
 AD este un numar intreg intre 1 si 255
unde RID este Router ID-ul routerului ce introduce in domeniul OSPF acel(e) LSA(-uri), WM este un
wildcard mask (similar ACL), iar ACL poate fi numeric sau denominat, standard sau extins.
Vizualizarea AD-ului schimbat prin comanda distance se poate face prin:
 Router# show ip protocols

Daca se folosesc ambele comenzi, comanda distance ospf ... are precedenta in stabilirea valorii AD pentru fiecare tip de
prefix OSPF (intra-area, inter-area...) pentru care aceasta comanda are parametrul corespunzator setat de operator.

Scopul schimbarii AD este fie cel de a impiedica introducerea in RIB a unor prefixe OSPF, fie cel de a prefera instalarea in
RIB a prefixelor unui alt protocol de routare in detrimentul OSPF.

Primirea in LSU-uri a LSA-urilor de tip 3 (informatie de routare sub forma esentialmente de tip distance-vector) nu necesita
functionarea algoritmului full-SPF, ci doar a formei partiale a SPF ce utilizeaza mai putine resurse CPU.

Vizualizarea OSPF LSDB-ului se face prin comanda: Router# show ip ospf database ce reda informatii sumarizate (doar
headerele LSA), sau printr-una din formele sale mai detaliate, precum Router# show ip ospf database network sau Router#
show ip ospf database router, pentru un tip particular de LSA sau altul.

9. Tipuri de LSA-uri:
- LSA 1 Router:

unul per router per arie. Reda


numarul de link-uri in acea arie,
cat si rolul routerului: daca este
ABR, ASBR sau un capat al
unui Virtual Link (B, E si,
respectiv, V flags).

Contine, in plus, costul, Link


Type (point-to-point [1], tranzit,
stub, virtual link), Link ID cat si
Link Data (adresa IP, NM, RID
vecin - nu toate tipurile de link-
uri sunt descrise cu toti acesti
parametrii).

De asemenea, contine un camp


de 1 byte numit options.

Infoacademy – Romeo Lungu Page 12


Cisco Networking Academy
www.infoacademy.net

- LSA 2 Network: unul per retea multiaccess tip tranzit (cel putin 2 routere). Generat de DR-ul retelei, reda RID-ul routerelor
vecine cu virtual nod-ul pe care il reprezinta DR-ul (acesta se include si pe sine), cat si NM retelei. Link State ID: IP-ul DR

- LSA 3 Net Summary: creat de ABR pentru a reda prefixul (Link State ID) si prefix-length (campul de NM) ce descriu retele
din afara ariei in care se injecteaza aceste informatii de routare. Ele sunt generate de ABR-uri astfel:
a. Dinspre o arie non-backbone catre area backbone:
i. Retelele direct conectate in aria non-backbone (se genereaza LSA-ul 3)
ii. Retelele intra-area din aria non-backbone (se genereaza LSA-ul 3)
b. Dinspre aria backbone catre o arie non-backbone:
i. Retele direct conectate in aria backbone (se genereaza LSA-ul 3)
ii. Retele intra-area din aria backbone (se genereaza LSA-ul 3)
iii. Retele inter-area din alte arii non-backbone (se regenereaza LSAul 3 generat de alt BR)

In cazul configurarii unei arii non backbone ca fiind de tip stub, ABR-ul va genera un LSA de tipul 3 cu Link State ID-ul,
cat si NM egale cu 0.0.0.0. LSA-ul este de tip inter-area si nu de tip intr-area pentru ca se doreste ca aceasta sa nu fie
introdus in area backbone.

- LSA 4 ASBR Summary: creat de ABR (daca are cel putin o interfata functionala L1/L2 si configurata pentru IP in area 0) si
injectat intr-o arie pentru a indica costul sau catre fiecare ASBR existent intr-una din celelalte arii la care este direct
conectat. Link State ID-ul din LSA contine RID-ul ASBR-ului, NM va avea mereu valoarea 0.0.0.0 iar metrica va indica
costul ABR-ului catre ASBR. Structural, LSA-ul 4 este identic cu LSA-ul 3.
LSA-ul de tip 4 poate fi nu doar generat (caz redat mai sus) ci si regenerat – cazul in care LSA-ul de tip 4 a fost generat
anterior de alt ABR conectat el la aria in care se gaseste ASBR-ul descris in LSA.

- LSA 5 AS External: Create de ASBR pentru rutele injectate in OSPF prin redistributie. Link State ID: Prefix

- LSA 6 Group Membership: Se folosesc in MOSPF (Multicast OSPF) – nu este utilizat de IOS-ul Cisco.

- LSA 7 NSSA External: Create de ASBR-uri in interiorul ariilor NSSA in locul LSA-urilor de tip 5. Link State ID: Prefix

- LSA 8 External Attributes: Nu este implementat in IOS-ul Cisco peste OSPF. Este utilizat de BGP.

- LSA 9–11 Opaque: LSA-uri generice, folosite drept extensii viitoare; se utilizeaza uneori pentru MPLS traffic engineering.
[1]
– pentru linku-rile point-to-point numbered, Link Data este IP-ul interfetei noastre. Pentru link-urile point-to-point
unnumbered, Link Data este indexul MIB II al interfetei (adesea, are forma 0.0.0.x).
– Interfetele OSPF point-to-point sunt descrise in router LSA printr-un link type point-to-point si printr-un link de tip stub,
ce reda NM asociat acelui link in campul Link Data.
– Interfetele OSPF point-to-multipoint sunt descrise in router LSA, pe langa „x‟ link type point-to-point si printr-un link type
stub, ce reda networkmask-ul acelei interfete ca fiind 255.255.255.255.

10. Troubleshooting OSPF


Conditiile necesare descoperiri si mentinerii relatiilor de vecinatate, conditii redate la punctual 4, sunt verificate, in cazul
banuirii ca nu ar fi respectate intre 2 routere OSPF, cu ajutorul urmatoarelor comenzilor (se observa utilitatea in depanare a
comenzii debug ip ospf events):

Problema Comanda Observatii


Hello sau Dead time diferit Router# debug ip ospf hello Outputul comenzii evidentiaza eroarea sub
Router# debug ip ospf events forma de “C” – configured si “R” - received
Network Mask diferit Router# debug ip ospf hello Outputul comenzii evidentiaza eroarea sub

Infoacademy – Romeo Lungu Page 13


Cisco Networking Academy
www.infoacademy.net

Router# debug ip ospf events forma de “C” – configured si “R” – received


Tip (normal/stub/NSSA) diferit de arie Router# debug ip ospf hello Se va cauta in mesajul de logging:
Router# debug ip ospf events “..with mismatched Stub/Transit area option bit”
Numar de arie diferit Router# debug ip ospf adj
“.. mismatch area x.x.x.x in the header”
Router# debug ip ospf events
Tip/configurare de autentificare diferita Router# debug ip ospf adj Se va cauta in mesajul de logging:
Router# debug ip ospf events “Mismatch Authentication type. Input packet…”
Acelasi Router ID cu un vecin direct Eroarea este redata automat prin sistemul de
conectat - logging la aproximativ 1 minut:
“%OSPF-4-DUP_RTRID_NBR …”
Acelasi Router ID cu un vecin indirect Router# debug ip ospf flood Se va cauta in mesajul de logging:
conectat, din aceeasi arie “OSPF: we received our own old rtr lsa”

In plus, eroarea este redata automat prin sistemul


de logging la aproximativ 2 minute:
“%OSPF-4-DUP_RTRID_AREA …”
IP-ul sursa al mesajului OSPF nu se Router# debug ip ospf adj Se va cauta in mesajul de logging:
regaseste in spatiul propriu de adrese IP Router# debug ip ospf events “... src not on the same network”

Exemplu de output al comenzii debug ip ospf hello in cazul nepotrivirii parametrilor Hello si Dead interval:

Comanda debug ip ospf packet are drept efect afisarea doar a tipurilor de mesaje OSPF primite. In cazul existentei unei
relatii de vecinatate, comanda afiseaza versiunea OSPF, tipul mesajului, lungime hdr + „date‟ OSPF, Router ID, Area ID, tipul
de autentificare, numarul cheii sa:

*Mar 1 00:31:43.027: OSPF: rcv. v:2 t:1 l:48 rid:10.0.0.1


aid:0.0.0.0 chk:C494 aut:0 auk: from FastEthernet0/0

In cazul in care o parte din parametrii comuni necesari formarii relatiei de vecinatate nu sunt indepliniti aceasta debug nu
afiseaza nimic; de exemplu, in cazul nepotrivirii tipului de autentificare, a numarului de arie, sa. In aceste cazuri se folosesc
comenzile de tip debug de mai sus.

Generarea de LSA-uri de tip 5 se poate depana cu ajutorul comenzii debug ip ospf spf external [ACL_standard_numeric]
pe un router diferit de ASBR, cat si prin comanda debug ip ospf lsa-generation [ACL_numeric] pe router-ul ASBR.

O comanda de tip debug ce afiseaza functionarea procesului SPF, in special a timerilor acestuia si a tipului de SPF executat
(partial sau full) este debug ip ospf monitor. Ne reda de asemenea LSA-ul primit de router, responsabil pentru initierea unui
nou proces SPF fiind astfel utila pentru detectarea unui link ce face flapping. Este o comanda ascunsa in versiuni de IOS mai
vechi.

Vizualizarea numarului de ori in care s-a executat algoritmul SPF cat si a tipului de LSA ce a „justificat‟ acea executie, se
realizeaza prin comanda: Router# show ip ospf statistics [detail].

Alte conditii ce trebuie indeplinite de OPSF si a caror nerespectare impiedica formarea unei conectivitati globale in
interretea:
 Imposibilitatea comunicarii la L2 sau/si L3 cu mesaje de tip unicast si multicast. Se va folosii debug ip packet
sau/si debug frame-relay packet, in functie de protocolul de L2 utilizat.

Infoacademy – Romeo Lungu Page 14


Cisco Networking Academy
www.infoacademy.net

 Pasivizarea interfetelor catre routere vecine: Se va folosii debug ip ospf hello pentru a urmarii
trimiterea/primirea de mesaje Hello.
 Filtrarea de pachete (de ex. destinate protocolului 89). Se va folosii debug ip packet pentru a urmarii filtrarea
de mesaje OSPF de catre o lista de acces.
 IP MTU mismatch: Se va folosi debug ip ospf adj sau debug ip ospf events. Relatia dintre vecini va oscila
incontinuu intre ExStart si Down.

Se poate cere IOS-ului afisarea mesajelor primite si trimise doar pe o interfata/un set de interfete cu ajutorul comenzii
debug interface <intf>. Aceasta comanda introduce conditii de depanare.

Router ID-ul unui router trebuie sa fie unic in aria de apartenenta (pentru un ABR acest lucru este valabil pentru toate ariile
din care face parte). Cerinta unicitatii RID-ului se extinde si pentru routerele aflate in arii diferite atat timp cat cel putin unul din
cele doua routere este ASBR.
Feedback-ul primit in sistemul de logging in cazul nerespectarii acestei conditii este:
- in cazul in care duplicarea RID-ului are loc intre doua routere direct conectate din aceeasi arie:
%OSPF-4-DUP_RTRID_NBR: OSPF detected duplicate router-id 1.1.1.1 from 10.0.0.4 on interface FastEthernet0/0

- in cazul duplicarea RID-ului are loc intre doua routere din aceeasi arie ce nu sunt direct conectate:
%OSPF-4-DUP_RTRID_AREA: Detected router with duplicate router ID 2.2.2.2 in area 0 sau
%OSPF-4-DUP_RTRID1: Detected router with duplicate router ID 100.0.0.2 in area 0

- sau, in cazul nerespectarii aceleasi reguli intre doua routere aflate in arii diferite (unul dintre ele este ASBR):
%OSPF-4-FLOOD_WAR: Process 1 flushes LSA ID 0.0.0.0 type-5 adv-rtr 3.3.3.3 in area 0 (sau)
%OSPF-4-FLOOD_WAR: Process 1 re-originates LSA ID 0.0.0.0 type-5 adv-rtr 3.3.3.3 in area 0 (sau)
%OSPF-4-DUP_RTRID2: Detected router with duplicate router ID 3.3.3.3 in Type-4 LSA advertised by 4.4.4.4

Un alt motiv pentru generarea de OSPF a unui mesaj de tip FLOOD_WAR este existenta in aceeasi arie a doua sau mai
multe routere DR, conectate la acelasi spatiu de adrese IP:
%OSPF-4-FLOOD_WAR: Process 1 re-originates LSA ID 10.0.0.1 type-2 adv-rtr 4.4.4.4 in area 0

In anumite cazuri OSPF detine in LSDB informatia de rutare necesara dar nu o instaleaza in RIB. In output-ul show ip ospf
database router de exemplu, va apare Adv Router is not-reachable. Motivatiile posibile sunt redate in documentul din sectiunea
„Referinte‟ numit “Why Are Some OSPF Routes in the Database but Not in the Routing Table?”. Un posibil motiv este redat in
continuare:
Instalarea in RIB a rutelor externe domeniului OSPF (injectate de un ASBR) se realizeaza doar daca:
1. Routerul ce realizeaza acest calcul are o ruta OSPF in RIB intra-area sau inter-area catre respectivul ASBR, si
2. FORWARDING ADDRESS (daca este diferit de 0.0.0.0) este cunoscuta prin OSPF in RIB printr-o ruta intra-area
sau inter-area.

11. Multiarea OSPF


Intr-o retea OSPF multiarea, routerele se impart in:
 ABR (Area Border Router) - au interfete conectare in doua sau mai multe arii. Pentru a schimba informatii
de routare dintr-o arie in alta, ABR-ul trebuie sa detina cel putin o interfata conectata in area 0 - aceasta
interfata trebuie sa fie Up si Up si configurata cu adresa IP. Poate fi chiar si o interfata de loopback. Daca
nu se stabileste nici-o relatie de vecinatate OSPF in interiorul ariei 0 aceasta va apare drept (Inactive) in
output-ul lui show ip ospf | begin BACKBONE fara a impiedica obtinerea de full reacheability.
Daca insa aceasta unica interfata este in down sau shutdown, ABR-ul nostru nu va propaga informatia de
routare dintr-o arie in alta, impiedicand de aceasta data obtinerea full reacheability.
 ASBR (Autonomous System Boundary Router) – s-a configurat redistributia routelor din afara process
domeniului OSPF (connected, static, RIP, BGP, sa), sau/si a fost configurat sa genereze o ruta default,
 Backbone – are toate interfetele configurate in area 0 (area backbone),

Infoacademy – Romeo Lungu Page 15


Cisco Networking Academy
www.infoacademy.net

 Intern – are toate interfetele configurate intr-o singura arie, alta decat area 0.

Genereaza Standard sau


Injecteaza Injecteaza Accepta crearea Compatibile?
Tip de arie automat o proprietar
LSA 4 si 5? LSA 3? LSA 7? (1)
ruta default? Cisco?
Stub Nu Da Nu Da X standard
Totally stubby Nu Nu Nu Da X Cisco
Not-so-stubby
Nu Da Da Nu O standard
(NSSA)
Totally NSSA Nu Nu Da Da O Cisco

(1) - Tipurile de arii compatibile sunt stub si totally stubby (bitul E in Option field are valoarea 0), cat si NSSA si totally
NSSA (bitul N in Option field area valoarea 1).

O arie de tip normal este capabila sa primeasca LSA-uri de tip 1, 2, 3, 4 si 5 (cele de interes). Se accepta redistributia de
informatie de routare din alte surse de routare, adica existenta ASBR-urilor.
Area 0 este obligatoriu sa fie o arie de tip normal. Area 0 este obligatoriu o arie continua (alte arii pot fi partitionate
(accidental) fara pierdera conectivitatii, atat timp cat sunt conectate la area 0). Partitionarea ariei 0 poate fi reparata/evitata cu
link-uri virtuale.

Ariile de tip stub nu permit introducerea informatiilor de rutare externe (LSA 5) process-domain-ului OSPF. In locul lor,
ABR-ul/ABR-urile injecteaza automat o ruta default de tip inter-area (O IA) cu cost, by default, de 1. Ariile de tip stub, prin
aceasta “sumarizare” a retelelor externe printr-o ruta 0.0.0.0/0, contribuie la scalabilitatea OSPF. Nu este acceptata redistributia
din alte surse de informatie de routare in process-domain-ul OSPF in ariile stub (adica nu se accepta routere tip ASBR decat daca
sunt in acelasi timp si ABR pentru aceasta arie).
O potentiala problema cu toate ariile de tip stub (stub, totally stuby, NSSA si totally NSSA) este pierderea informatiilor de
routare de detaliu, ce poate duce, in conditiile unor multiple ABR-uri intre aria stub si area 0, la rutare suboptima (pachetul va fi
„scos‟ din aria stub catre prefixul destinatie nu prin ABR-ul cel mai optim in raport cu costul inter-area, ci prin ABR-ul cel mai
apropiat, in raport cu costului intra-area).
Comanda pentru a configura o arie de tip stubby este:
 Router(config-router)# area <area-id> stub

Aria de tip totally stubby nu accepta in LSDB LSA-uri de tip 5, 4 si 3, adica nu se trimit de catre ABR-uri in acest tip de
arie informatii de routare de tip inter-area (LSA 3) si de tip extern (LSA 5). Informatiile despre costul ABR-urilor catre ASBR-
uri (LSA de tip 4) nu sunt, la randul lor, trimise in interiorul ariei. In locul acelor informatii de rutare se genereaza automat de
catre ASB-uri o ruta default de tip inter-area, cu cost, by-default de 1.
Comanda pentru a configura o arie de tip totally stubby este:
 Router(config-router)# area <area-id> stub no-summary

Aria de tip NSSA (Not So Stubby Area) nu accepta in LSDB LSA-uri de tip 5 si 4, similar ariilor stub, dar permit
redistributia locala (pe un router non-ABR) a prefixelor altei surse de informatie de routare in interiorul ariei NSSA sub forma
LSA-urilor de tip 7. In acest tip de arie se accepta LSA-uri de tip 3 (inter-area). Un singur ABR (chiar daca sunt mai multe) ce
separa aria NSSA de aria backbone va translata automat LSA-urile de tip 7 din aria NSSA in LSA-uri de tip 5 inainte de a le
flooda in aria backbone. Daca sunt mai multe ABR-uri, functia mentionata o va indeplini routerul cu RID-ul cel mai mare.
Nu se genereaza automat o ruta default in aria NSSA!
Comanda pentru a configura o arie de tip NSSA este:
 Router(config-router)# area <area-id> nssa

By-default, un ABR ce separa o arie NSSA de area 0 va translata LSA-urile de tip 7 originate in NSSA in LSA-uri de tip 5,
pastrand tipul rutei si metrica (primita), cat si FORWARD ADDRESS. In cazul in care aceasta FORWARD ADDRESS nu este
insa cunoscuta altor routere din ariile non-stub din proces domeniul OSPF (datorita filtrarii spatiului IP ce contine acel/acele IP-
uri pe ABR-uri), aceste prefixe vor ajunge sa se regasesca in LSDB dar nu vor fi marcate de IOS ca avand „Routing Bit Set on

Infoacademy – Romeo Lungu Page 16


Cisco Networking Academy
www.infoacademy.net

this LSA‟, adica nu vor fi introduse in RIB, efectiv neobtinandu-se full reacheability. Pentru remedierea acestei situatii, pe ABR-
ul dintre area NSSA si area 0 se va configura:
 Router(config-router)# area <AID_NSSA> nssa translate type7 suppress-fa
ce are drept efect modificarea FORWARD ADDRESS la 0.0.0.0. Atentie, se pierde in acest moment compatibilitatea cu
RFC 1587.

Un router NSSA ASBR va seta FORWARD ADDRESS la o valoarea de 0.0.0.0 daca bitul P (propagate) este 0. In plus,
NSSA ABR-ul nu va propaga acest LSA 7 in area 0.
In cazul in care bitul P este 1, FORWARD ADDRESS va fi ales pe NSSA ASBR conform urmatoarei liste, in ordine:
1. IP-ul NEXT HOP al rutei redistribuite, atata timp cat acesta este accesibil printr-o interfata activa in OSPF,
parte a ariei NSSA.
Daca tipul interfetei este dpdv OSPF point-to-point sau point-to-multipoint, sau interfata este pasivizata OSPF,
IP-ul NEXT HOP va fi cel al interfetei insasi.
2. IP-ul cel mai mare al oricarei interfete loopback active OSPF, parte a ariei NSSA
3. IP-ul cel mai mare al oricarei interfete active OSPF, parte a ariei NSSA
NSSA ABR-ul va propaga acest LSA 7 printr-un LSA de tip 5 in area 0, daca P este 1. Se va pastra tipul rutei (din N1 se
obtine E1, din N2 se obtine E2). Daca exista mai multe NSSA ABR-uri ce conecteaza area NSSA la area 0, doar unul din acele
ABR-uri va produce translatarea LSA 7 in LSA 5, si anume cel cu cel mai mare RID – acesta va avea cunoscute acele prefixe in
RIB sub forma N1 sau N2, in timp ce celelalte ABR-uri conectate la area NSSA vor avea cunoscute prefixele in RIB sub forma
de E1 sau E2.

Aria de tip totally NSSA nu accepta nici LSA-uri de tip 5 si 4 si nici cele de tip 3 (este similar ariei de tip totally stuby). Se
genereaza in schimb in mod automat o ruta default de catre ABR-uri, cu un cost de 1, de ip inter-area.
Comanda pentru a configura o arie de tip totally NSSA este:
 Router(config-router)# area <area-id> nssa no-summary

Tipul ariilor la care este conectat routerul nostru se poate vizualiza prin mai multe comenzi specifice OSPF sau generice, din
care cea care ofera cea mai mare cantitate de informatie este:
 Router# show ip ospf

12. OSPF virtual-link


Designul retelelor OSPF cere ca:
– ariile non-backbone sa fie conectate la area backbone (in mod direct sau indirect, adica prin intermediul altei/altor
arii)
– sa existe continuitate intre routerele din aria backbone, adica aria backbone sa fie contigua, nefragmentata.

Cum acest design nu este mereu posibil, eventual drept masura temporara pana la refacerea ulterioara a topologiei, se poate
folosi virtual-link-ul. Acesta permite:
– crearea unei „legaturii virtuale‟ intre aria non-backbone si area 0 prin intermediul unei singure arii non-backbone cu
rol de tranzit. Routerul ce va conecta ariile non-backbone va deveni un router ABR; el va contine toate LSA-urile
ariei 0 obtinute prin virtual-link.
– conectarea ariei backbone accidental/”prin design” partitionate (de exemplu, integrarea a doua retele OSPF pana
acum separate).

Nota: existenta unei/unor arii discontinue non-backbone conectate la aria zero nu atrage dupa sine vreo problema in
schimbul informatiei de routare si ulterior al datelor utilizator, deci nu necesita o atentie speciala.
Exemplu: aria_10 <--> aria_0 <--> aria_10.

Infoacademy – Romeo Lungu Page 17


Cisco Networking Academy
www.infoacademy.net

Aria/ariile de tranzit NU pot fi arii de tip stub - exceptie este cazul in care, pentru a traversa o arie de tranzit de tip stub, se vor
folosii tunele (GRE, IP/IP, etc). Atentie, in acest caz, interfetele de tunel vor trebui sa apartina ariei 0.
Diferentele intre virtual-links (VL) si tunele sunt:
- VL – nu am nevoie de adrese; TUNELE - folosesc un nou spatiu de adresare (sau utilizam ip unnumbered)
- VL – se trimite doar informatia de rutare intre cele 2 capete al VL sub forma de trafic unicast; TUNELE – se trimite atat
informatia de rutare cat si traficul tip date incapsulate suplimentar (tunel)  overhead crescut
- VL – fac parte by-default din area 0; TUNELE – trebuie configurate manual in area 0
- VL – sunt configurate by-default de tip demand circuit (DC) , adica nu se trimit Hello-uri ulterior stabilirii adiacentei;
TUNELE – se trimit Hello-uri (optional pot fi configurate DC)
- VL – area de transit nu poate fi de tip stub; TUNELE – area de transit poate fi si de tip stub.

In scenariul ABR-ului neconectat la area 0, ca urmare a trimiterii de cele 2 ABR-uri in LSA-ul de tip 1 a link-ului de tip
virtual in interiorul ariei de tranzit, se va forma linkul virtual, urmat de floodingul LSA-urilor din area 0 catre ABR-ul neconectat
la area 0. Schimbul de mesaje intre cele 2 routere ce participa in linkul virtual se face cu IP destinatie unicast, TTL initial egal cu
255. Network Mask-ul din headerul mesajului Hello este 0.0.0.0.

Link-urile virtuale NU sunt folosite pentru forwarding-ul de pachete, ci pentru stabilirea de adiacenta. Prin ele se schimba
mesaje OSPF intre cele doua ABR-uri, mesaje ce sunt forwardate (precum datele utilizator) de routerele intermediare.

Costul link-ului virtual este costul OSPF al rutei intre ABR-uri. Functionarea virtual-link-ului necesita ca costul total pe
calea intre routerele ABR configurate drept „capete‟ sa fie mai mic decat 65535. Tipul retelei OSPF de pe interfata virtuala este
point-to-point. Timpul de Hello si Dead este de 10, respectiv 40 secunde.

Pe ambele routere ce vor participa in crearea de virtual-link se va configura:


 Router(config-router)# area <area-id-de-tranzit> virtual-link <RID-vecin-de-virtual-link> [hello-
interval <sec>] [dead-interval <sec>]  sec intre 1 si 8192, default 10 si 40
Se vizualizeaza cu:
 Router# show ip ospf virtual-links

In cazul in care se doreste conectarea unei arii non-backbone la o alta doua arie non-backbone ce este si ea conectata la o
treia arie non-backbone, prima dintre acestea necesita un virtual-link cu urmatoarea (cea de a doua), aceasta din urma necesita un
virtual-link cu urmatoarea (cea de a treia), iar aceasta necesita un virtual-link cu area backbone. Aceasta situatie este foarte rar
intalnita in practica.

La configurarea autentificarii, de retinut ca virtual-link-urile apartin ariei 0 (AID in headerul OSPF este 0.0.0.0). In urma
schimbarii in procesul OSPF a autentificarii pentru area 0, se schimba corespunzator tipul de autentificare pentru toate link-urile
virtuale din area 0. Configurarea manuala insa a autentificarii pentru un virtual link sau altul va determina configuratia de
autentificare pentru acel virtual link.

Virtual-link-urile apar in outputul lui show ip ospf int sub forma VLx, iar in outputul lui show ip ospf virtual-links sub
forma OSPF_VLx. Configurarea virtual-link-ului poate fi observata si in output-ul comenzii show ip ospf in sectiunea ce descrie
aria OSPF de tranzitie pentru VL, cat si in output-ul comenzii show ip ospf database router <RID>, unde RID este al unuia din
cele doua routere ce alcatuiesc „link-ul virtual‟.

Atentie la interpretarea output-ului comenzii show ip ospf virtual-links: faptul ca link-ul virtual apare Up nu indica decat ca
exista o ruta in RIB-ul routerului nostru catre celalalt capat al conexiunii virtuale, nu si ca aceasta este functionala. Pentru a ne
asigura de acest din urma fapt se va cauta in output mentiunea: Adjacency State FULL.

13. Sumarizarea in OSPF


In OSPF sumarizarea se poate realiza pe routerele ABR, la propagarea informatiei de routare dintr-o arie in alta, si pe
routerele ASBR, la propagarea informatiei de routare dintr-un domeniu de routare intr-altul (non-OSPF  OSPF).

Infoacademy – Romeo Lungu Page 18


Cisco Networking Academy
www.infoacademy.net

Sumarizarea are drept beneficii reducerea dimensiunii tabelei topologice, de routare, reducerea necesarului de procesor
pentru extragerea rutelor, reducerea BW necesar schimbului de LSA-uri, reducerea efectului linkurilor ce flapeaza intr-o arie
asupra resurselor HW din alte arii.
Sumarizarea are drept dezavantaje, potentialul de a introduce rutare neoptima, „black-holes‟ in retea si bucle de routare.

OSPF nu foloseste conceptul de auto-sumarizare (in acest sens se asemana cu iIS-IS) utilizat de RIP, EIGRP si BGP.
Nu exista comanda auto-summary. Pentru ca sumarizarea sa aiba loc ea trebuie configurata manual si, adesea (adica atunci
cand nu folosim ruta default), presupune existenta unui design IP ierarhic (sumarizabil).

1. La nivelul ABR (sumarizare inter-area)


Sumarizarea poate fi configurata in ambele directii (catre/de la backbone). Practic, cel mai adesea vom sumariza catre
area backbone si vom folosi pentru ariile non-backbone configuratii de tip stub.
Se aplica doar rutelor intra-area (invatate de ABR prin LSA-uri de tipul 1 si 2), NU si rutelor externe (invatate de ABR
prin LSA-uri 5 sau 7) sau rutelor inter-area (invatate de ABR prin LSA-uri de tip 3). Este obligatoriu sa existe prefixe de
interes OSPF suport ale sumarizarii in aria de origine (area-id de mai jos). In caz contrar, ABR-ul nu va genera prefixe
inter-area (publicate prin LSA-uri de tip 3.
Un LSA de tip 3 descrie un singur prefix IPv4. Se pot configura mai multe comenzi area range in acelasi proces OSPF.

Comanda de configurare a sumarizarii este:


 Router (config-router)# area <area-id> range <prefix> <pfx-length> [advertise | not-advertise] [cost]
- area-id este aria de origine a rutelor sumarizate,
- parametrul advertise este default si cere publicarea rutei sumarizate si a suprimarii rutelor suport ale
sumarizarii,
- cost permite precizarea costului cu care va fi injectat acest prefix in LSA-ul de tip 3. By-default se
foloseste costul cel mai mic al rutelor suport,
- no-advertise cere sa nu se publice atat rutele suport ale sumarizarii cat si insasi sumarizarea.

Automat va fi generata o ruta de discard de tip intra-area (O) corespunzatoare sumarizarii configurate, cu distanta
administrativa 110 si fie metrica 0, fie cu metrica sumarizarii (default egala cu 1), menita sa ajute in evitarea buclelor de
routare. Valoarea metricii depinde de versiunea de IOS. Aceasta ruta poate fi scoasa din RIB cu ajutorul comenzii:
 Router (config-router)# no discard-route internal
In versiuni recente de IOS, distanta administrativa a rutei de discard poate fi modificata cu ajutorul comenzii:
 Router (config-router)# discard-route internal <AD> , AD ia valori intre 1 si 255

In urma sumarizarii manuale la ABR, prefixul/prefixele obtinute vor avea, by-default, metrica cea mai mica a prefixelor
suport pentru acea sumarizare (conform RFC 1583). Daca insa se doreste ca metrica sumarizarii sa fie metrica cea mai mare
a prefixelor suport, trebuie configurat:
 Router(config-router)# no compatible rfc1583

Prefixele sumarizate prin comanda area range vor fi trimise in celelalte arii (stub sau normale), nu si in aria sursa a
prefixelor suport pentru sumarizare, adica area-id mentionata mai sus. Aceste prefixe sumarizate (nu si rutele lor suport!) se
observa in output-ul comenzii show ip ospf database, in sectiunile ce descriu LSA-urile de tip 3 ce apartin acelor alte arii.
In cazul utilizarii parametrului not-advertise nu vom regasi in sectiunile mentionate din LSDB nici prefixele sumarizate si
nici prefixele suport pentru sumarizare. Prefixul sumarizat nu va apare nici sub forma rutei de discard in RIB-ul ABR-ului.

OSPF nu permite sumarizarea la limita de 0.0.0.0/0 prin intermediul comenzii area <area-id> range ... . Se genereaza
eroarea: “OSPF: Cannot add this range as 0.0.0.0/0 represents default”

Se poate vizualiza caracterul activ (functional/se propaga) sau pasiv (nefunctional/nu se propaga) al sumarizarii, metrica
asociata acelui prefix cat si tipul sumarizarii (Advertise versus DoNotAdvertise) cu ajutorul comenzii:
 Router# show ip ospf | begin Area <AID> sau
 Router# show ip ospf | include <pfx>

Exemple de output:
Infoacademy – Romeo Lungu Page 19
Cisco Networking Academy
www.infoacademy.net

13.0.0.0/10 Active(2) Advertise <--- prefixul este publicat, cost de 2 calculat automat
13.0.0.0/10 Active(11 - configured) Advertise <--- prefixul este publicat cu un cost de 11 stabilit manual
13.0.0.0/10 Passive Advertise <--- prefixul nu este publicat din lipsa de prefixe suport
13.0.0.0/10 Passive DoNotAdvertise <--- prefixul nu este publicat in mod explicit

2. La nivelul ASBR (sumarizare a rutelor externe)


Se aplica doar rutelor redistribuite in OSPF de un ASBR. In OSPF routerele pot indeplini rolul de ASBR doar daca sunt
direct conectate cel putin intr-o arie de tip normal, NSSA sau/si totally NSSA.
Comanda summary-address poate fi folosita atat pe un ASBR conectat la o arie normala cat si pe un ASBR conectat la
o arie NSSA. Comanda nu are nici-un efect pe un router ce nu are rol de ASBR sau pe un router ASBR ce nu redistribuie el
insusi prefixele externe suport ale sumarizarii manuale.
Rutele redistribuite in OSPF sau sumarizate manual (comanda summary-address) se propaga sub forma unor LSA-uri
de tip 5 in interiorul ariilor normale, si sub forma LSA-urilor de tip 7 in interiorul ariilor NSSA sau totally NSSA.
Un LSA de tip 5 sau 7 descrie un singur prefix IPv4. Se pot configura mai multe comenzi summary-address in acelasi
proces OSPF.

Comanda de configurare a sumarizarii este:


 Router(config-router)# summary-address <prefix> <prefix-length> [not-advertise] | [tag <32bit_tag>]
– tag, by-default, are valoarea 0. Poate lua valori intre 0 si 232-1,
– folosirea parametrului not-advertise are drept efect filtrarea atat a prefixelor suport cat si a
prefixului sumarizat.

Automat va fi generata o ruta de discard de tip intra-area (O) corespunzatoare sumarizarii configurate, cu distanta
administrativa fie 110, fie 254 si metrica egala fie cu 0, fie cu metrica sumarizarii (de regula egala cu 20), in functie de
versiunea de IOS. Aceasta ruta este menita sa ajute in evitarea buclelor de routare. Ea poate fi scoasa din RIB cu ajutorul
comenzii:
 Router (config-router)# no discard-route external
In versiuni recente de IOS, distanta administrativa a rutei de discard poate fi modificata cu ajutorul comenzii:
 Router (config-router)# discard-route external <AD> , AD ia valori intre 1 si 255

In urma sumarizarii manuale la ASBR, prefixul/prefixele obtinute vor avea metrica cea mai mica a prefixelor suport
pentru acea sumarizare. Aceste prefixe externe au fost deja importate in OSPF cu o anumita metrica. Metrica sumarizarii
rutelor externe nu este influentata de comanda no compatible rfc1583.

Folosirea parametrului not-advertise are drept efect neinstalarea in RIB a rutei de discard, neintroducerea in LSDB a
prefixelor externe suport ale sumarizarii, cat si neintroducerea in LSDB a insusi prefixului sumarizat.

OSPF nu permite sumarizarea la limita de 0.0.0.0/0 prin intermediul comenzii summary-address. Mai exact, imediat
ce este configurata aceasta comanda IOS-ul ii adauga parametrul not-advertise si inceteaza publicarea in OSPF a prefixelor
externe injectate in OSPF ce nu sunt, in plus, publicate in OSPF mod explicit de catre acelasi router prin alte comenzi
summary-address.

Se pot vizualiza pe routerul ASBR prefixele sumarizate configurate, metrica lor (daca se filtreaza prefixele suport ale
sumarizarii sau daca nu exista rute suport metrica sumarizarii va fi maxima, de 16777215), tipul metricii (E1 sau E2) si
valoarea tag-ului, cu ajutorul comenzii:
 Router# show ip ospf summary-address

Exemple de output:
30.0.0.0/255.0.0.0 Metric 20, Type 2, Tag 0 <--- prefixul este publicat cu un cost de 20, tip 2 (valori default)
30.0.0.0/255.0.0.0 Metric -1, Type 0, Tag 0 <--- prefixul nu este publicat din lipsa de prefixe suport (sau)
30.0.0.0/255.0.0.0 Metric 16777215, Type 0, Tag 0 <--- prefixul nu este publicat din lipsa de prefixe suport
30.0.0.0/255.0.0.0 Metric 16777215, Type 0, Tag 0 <--- prefixul nu este publicat in mod explicit

Infoacademy – Romeo Lungu Page 20


Cisco Networking Academy
www.infoacademy.net

Vizualizarea pe routerul ASBR a rolului acestuia se poate face prin comenzile:


 Router# show ip ospf
 Router# show ip protocols
Vizualizarea routerelor ASBR pe celelalte routere din process domain-ul OSPF configurate in arii normale (NU de tip
stub!) se face prin comanda:
 Router# show ip ospf border-routers

14. Autentificarea in OSPF


Exista 3 tipuri de autentificari in OSPFv2: tipul 0 (null), tipul 1 (text) si tipul 2 (Cisco a ales MD5)
Autentificarea OSPF, traditional in IOS, se configura in promptul protocolului de rutare (config-router). Aici operatorul
preciza dorinta de a configura uniform, dpdv al autentificarii, toate interfetele din aceeasi arie. Acest tip de configurare nu
presupune insa a fi necesar ca toate routerele din acea arie sa fie configurate cu acelasi tip de autentificare (unele materiale scrise
si din Internet lasa aceasta impresie).
By-default autentificarea este de tip null. Intodeauna configurarea parolei, cat si a cheii in cazul autentificarii MD5, se
realizeaza la nivel de interfata. Exceptia o reprezinta virtual-link-ul, unde configurarea trebuie realizata la nivelul protocolului de
routare.
Comenzile traditionale pentru configurarea autentificarii la nivelul tuturor interfatelor locale dintr-o arie sunt:
pentru autentificarea text:
 Router(config-router)# area <area-id> authentication  text (1)
 Router(config-if)# ip ospf authentication-key <parola>  text

pentru autentificarea MD5:


 Router(config-router)# area <area-id> authentication message-digest  md5 (2)
 Router(config-if)# ip ospf message-digest-key <key-nr> md5 <parola>  md5

Modern (IOS > 12.0), avem flexibilitatea configurarii tipului de autentificare pe interfata (in paralel sau in locul configurarii
autentificarii pe arie), adica se permite precizarea tipului de autentificare (0, 1 sau 2) la nivel data-link, si nu doar global, la nivel
de arie.
 Router(config-if)# ip ospf authentication null null (0)
 Router(config-if)# ip ospf authentication text
 Router(config-if)# ip ospf message-digest md5
Daca tipul de autentificare este precizat atat la nivel „config-router‟ cat si la nivel „config-if‟, configuratia de la nivelul
interfetei va decide tipul de autentificare pentru respectiva interfata.

Parola se configureaza pe interfata; este necesar a fi identic setata la routerele vecine pentru un data-link comun si poate
diferi de parola folosita pe un alt data-link al aceluiasi router.
Numarul maxim de caractere din care poate fi alcatuita o parola pentru autentificarea de tip text este de 8, iar pentru o parola
de tip MD5 este de 16. Parolele sunt case sensitive.
Nu se pot folosi multiple parole per interfata pentru tipul de autentificare text – se utilizeaza (si pastreaza in running-config)
doar ultima parola.
In cazul autentificarii MD5 multiple chei si parole sunt permise per interfata – se trimit mesaje OSPF cu fiecare pereche
cheie/parola in parte daca au fost descoperiti vecini pe acel data link cu care avem cel putin o pereche cheie/parola comuna. In
cazul in care nu au fost (inca) descoperite routere OSPF vecine se trimit Hello-uri cu configuratia de autentificare specifica
ultimei perechi cheie/parola introduse.
Numarul cheii (intre 1 si 255, si valabil doar pentru MD5), cat si parola, trebuie sa fie identice cu cele ale vecinului/vecinilor
de link.
Comenzile moderne pentru configurarea autentificarii pe interfata sunt:
 Router(config-if)# ip ospf authentication-key [0|7] <parola> text
 Router(config-if)# ip ospf message-digest-key <key-nr> md5 [0|7] <parola> md5

Infoacademy – Romeo Lungu Page 21


Cisco Networking Academy
www.infoacademy.net

In cazul in care s-a configurat doar tipul de autentificare MD5, nu insa si o cheie/chei, se vor trimite mesaje OSPF
indicandu-se cheia default (cheia 0), fara a se trimite si vreun hash MD5 (se poate crea/mentine in acest caz relatia de
vecinatate).
Daca pe aceeasi interfata se folosesc chei multiple (impreuna cu autentificarea MD5) ele pot fi utilizate pentru a obtine o
autentificare cu o pereche cheie/parola diferita per vecin (ex: pe aceeasi interfata, cu vecinul X folosesc cheia 1 (si parola
tastatura), iar cu vecinul Y folosesc cheia 15 (si parola acadea), etc).

In cazul virtual-link trebuie configurat acelasi tip de autentificare pe cele doua routere, comenzi care se introduc la nivelul
„config-router‟. Autentificarea configurata la nivelul ariei 0 este cea preluata (aplicata), by-default, la nivelul interfetelor logice
virtual-link. Ea poate fi anulata (suprascrisa) prin configurarea unui alt tip de autentificare per virtual-link cu ajutorul
comenzilor:
 Router(config-router)# area <area-id> virtual-link authentication null null
 Router(config-router)# area <area-id> virtual-link authentication-key <parola> text
 Router(config-router)# area <area-id> virtual-link authentication message-digest message-digest-key
<key-nr> md5 <parola> md5

Nu este necesara autentificarea link-uri-lor virtuale doar pentru ca link-ul/link-urile fizice de tranzit folosesc autentificare.

Vizualizarea configuratiei de autentificare a unei interfete se poate vedea cu:


 Router# show ip ospf interface
 Router# show ip ospf virtual-link
iar comenzile ce ajuta in depanare (detectarea nepotrivirii configuratiilor de autentificare) sunt:
 Router# debug ip ospf adj
 Router# debug ip ospf events

15. Generarea de ruta default in OSPF:


OSPF poate folosi doar 0.0.0.0/0 drept ruta default.
OSPF NU accepta redistribuirea rutei default dintr-un alt protocol de rutare, ci permite doar generarea (conditionata sau
nu) a propriei rute default, astfel:

1. Un router ABR va genera automat o ruta default de tip inter-area „O IA‟ in interiorul unei arii daca aceasta este
configurata de tip stub, totally stuby sau totally NSSA (nu si NSSA!). Costul acesteia, by-default, este de 1. Comanda
pentru modificarea acestui cost:
 Router(config-router)# area <area-id> default-cost <nr>  nr intre 0 si 224-1

2. Generarea unei rute default intr-o arie normala (backbone sau non-backbone) se face cu ajutorul comenzii:
 Router(config-router)# default-information originate [always] [metric <nr>] [metric-type <1|2>]
[route-map <RM>]  nr intre 1 si 224-1

Cuvantul cheie always cere generarea rutei default indiferent de prezenta 0.0.0.0/0 (prin OSPF sau nu) in RIB.
Daca cuvantul cheie always este configurat iar noi aveam anterior in RIB doar o ruta default prin OSPF, aceasta va
dispare din RIB, nu insa si din LSDB. Routerul nostru va genera un LSA de tip 5 ce va descrie propria ruta 0.0.0.0/0.

In absenta parametrului always, doar prezenta unei rute default instalate in RIB de alt protocol de routare (nu si de catre
OSPF!), precum static, RIP, EIGRP, BGP sa, va duce la generarea 0.0.0.0/0 de catre routerul nostru prin OSPF.

Route map-ul permite generarea unei rute default conditionata de prezenta uneia sau mai multor rute in RIB (0.0.0.0/0
ori non 0.0.0.0/0) identificate prin ACL-uri (se face match doar pe prefixe classfull) sau identificate prin ip prefix-lits (se
poate face match si pe subretele). A se vedea in sectiunea de referinte link-ul catre “Conditional OSPF default route
origination based on classless IP prefixes”.
Router-ul nostru, daca nu indeplinea deja acest rol, va deveni acum automat un router ASBR, adica un router conectat la
„restul lumii‟, probabil Internet.

Infoacademy – Romeo Lungu Page 22


Cisco Networking Academy
www.infoacademy.net

Comanda de mai sus, by default, genereaza o ruta externa de tip E2, cu metrica 1 si Tag egal cu process-ID-ul OSPF
local. Ea este publicata in proces-domain-ul OSPF printr LSA de tip 5.

3. Pentru generarea unei rute default intr-o arie NSSA este necesara comanda:
 Router(config-router)# area <area-id> nssa default-information-originate [metric <nr>]
[metric-type <1|2>]  metrica intre 1 si 224-1. Tipul, by-default, este N2, iar metrica este 1

Generarea rutei default in aria NSSA este intodeauna conditionata:


– Daca router-ul (ce nu este nu ABR) are o ruta default instalata in RIB de un alt protocol de rutare, comanda de mai
sus va genera un LSA de tip 7 in aria NSSA ce va contine 0.0.0.0/0, cu bitul P (propagate) setat. ABR-ul ce separa
aceasta arie de area 0 va transforma acest LSA de tip 7 intr-un LSA de tip 5, propagat in intreg process-domain-ul
OSPF (ce accepta acest tip de LSA).
– Daca routerul este un ABR (are cel putin o interfata in aria backbone), se va genera o ruta default sub forma unui
LSA de tip 7 indiferent daca avem sau nu o ruta default in RIB, aceasta insa va avea bitul P setat pe 0 – nu va fi
transformata intr-un LSA de tip 5 si deci nu va fi propagata in restul process-domain-ului OSPF.

16. Filtrarea in OSPF


In OSPF se poate cere filtrarea atat a prefixelor (prefixele nu sunt instalate in RIB dar se regasesc in LSDB) cat si a
LSA-urilor (se suprima trimiterea anumitor tipuri de LSA-uri; prin urmare, in RIB nu se vor regasi respectivele prefixe).

A). Filtrarea prefixelor:


1). Daca se configureaza comenzi Router(config-router)# distribute-list pentru directia in , prefixele identificate prin
deny intr-o lista de acces, prefix-list sau route-map NU vor fi introduse in RIB, dar se vor pastra in LSDB si vor fi propaga
in LSU-uri in process-domain-ul OSPF.
Utilizarea route-maps in acest context permite identificarea flexibila a unor atribute ale LSA-urilor OSPF in raport cu
care sa fie luata apoi decizia daca se va instala sau nu acel prefix in RIB: match interface, match ip address [prefix], match
ip next-hop, match ip route-source (RID-ul routerului de origine pentru acel LSA), match metric, match route-type (external
sau nssa type 1 si 2, sau internal) sau match tag. A se vedea materialul din referinte „Filtrarea rutelor OSPF prin route-
maps‟.
Se poate vizualiza configuratia de filtrare prin:
 Router# show ip protocols

2). Daca se doreste ca anumite prefixe intra-area, inter-area sau externe sa nu fie instalate in RIB se poate utiliza
comanda distance prin care se vor manipula una sau mai multe din cele trei distante administrative ale OSPF-ului:
 Router(config-router)# distance ospf { intra-area <AD> | inter-area <AD> | external <AD> }
Pentru modificarea tuturor celor trei distante administrative la aceeasi valoare utilizam comanda:
 Router(config-router)# distance <AD> [<RID><NM>] [<stdACL>]
Daca se utilizeaza ambele comenzi, comanda distance ospf ... are precedenta. Pentru mai multe detalii legate de aceste
comenzi a se vedea capitolul „Algoritmul Shortest-path First‟ din acest material.

Drept un caz particular al modificarii distantei administrative, putem cere OSPF ca rutele de discard create in urma
sumarizarilor configurate pe ABR sau/si ASBR sa detina o distanta administrativa diferita de cea default (110), eventual
egala cu valoarea maxima (255). Aceasta configuratie permite uneori evitarea buclelor de routare.
 Router(config-router)# discard-route { internal | external } [<AD>]

3). In scopul reducerii timpului necesar convergentei prin reducerea numarului de prefixe transportate in LSA-urile
generate, se poate cere procesului OSPF sa nu trimita in router-LSA si network-LSA prefixele direct conectate la routerul
nostru. Exista exceptii de la aceasta regula, si anume:

Infoacademy – Romeo Lungu Page 23


Cisco Networking Academy
www.infoacademy.net

– daca se configureaza comanda in procesul de routare OSPF se vor trimite totusi in router LSA prefixele
direct conectate la interfete pasivizate, la interfete de loopback si prefixele secundare asociate oricarei interfete:
 Router(config-router)# prefix-suppression
– daca se configureaza comanda la nivel de interfata, se vor trimite totusi in router LSA prefixele secundare asociate
acelei interfete:
 Router(config-if)# ip ospf ip ospf prefix-suppression [disable]
– daca se configureaza ambele comenzi efectul rezultat va tine cont doar de comanda configurata la nivel de interfata
– daca se foloseste la nivel de interfata parametrul disable, se va anula efectul comenzii globale pentru interfata
curenta.
Functionalitatea descrisa este disponibila in versiuni recente de IOS.
Vizualizarea configuratiei de suprimare a prefixelor se realizeaza prin comenzile:
 Router# show ip ospf
 Router# show ip ospf interface [<intf>]
Depanarea filtrarii de prefixe utilizeaza comanda:
 Router# debug ip ospf lsa-generation

B). Filtrarea LSA-urilor:


1). Pentru a reduce numarul de cai alternative disponibile OSPF intr-o retea full mesh, cat si pentru a reduce
dimensiunea LSDB a vecinului (stub si ce detine, eventual, o ruta statica default prin noi), putem configura ip ospf
database-filter all out pe interfata noastra catre el. Aceasta comanda functioneaza similar cu passive interface in cazul
protocoalelor distance-vector. Drept rezultat, se stabilesc relatii de vecinatate fara a se trimite LSA-uri prin acea interfata. Se
accepta in schimb LSA-urile vecinilor:
 Router(config-if)# ip ospf database-filter all out
O comanda cu efect simial este neighbor <IP_vecin> database-filter all out la nivel de configurare a procesului
OSPF, ce are acelasi efect insa pentru un singur vecin OSPF. Comanda este disponibila doar in cazul retelelor OSPF point-
to-multipoint broadcast si non-broadcast:
 Router(config-router)# neighbor <IP_vecin> database-filter all out

2). Pentru filtrarea LSA-urilor de tip 3 originate de un router ABR (fie este routerul curent ABR-ul ce a generat initial
acest prefix in aria backbone, fie un alt router ABR din aria backbone a generat acel LSA), putem folosi comanda filter-list
prefix. Aceasta permite propagarea doar a anumitor prefixe in interiorul unei arii (directia in) sau/si dinspre o arie (directia
out).
Comanda cu parametrul in:
 Router(config-router)# area <AID_destinatie> filter-list prefix <pfx> in
filtreaza toate prefixele marcate prin deny in prefix-list-ul pfx, permitandu-le pe cele marcate prin permit, spre a fi trimise in
aria AID_destinatie.
Comanda cu parametrul out:
 Router(config-router)# area <AID_sursa> filter-list prefix <pfx> out
filtreaza toate prefixele marcate prin deny in prefix-list-ul pfx, permitandu-le pe cele marcate prin permit, spre a fi trimise
din aria sursa AID_sursa in orice alta arie adiacenta.
Pentru vizualizarea configuratiilor de filtrare se va folosi comanda:
 Router# show ip ospf | begin Area

3). Se poate configura in OSPF cerinta ca prefixele suport sumarizate de un ABR (prefixe inter-area, publicate prin
LSA-uri de tip 3), impreuna cu insusi prefixul sumarizat, sa nu fie introduse in domeniul de routare OSPF. Mai multe detalii
despre sumarizare gasim in capitolul „Sumarizarea in OSPF‟.
Comanda cu parametrul not-advertise:

Infoacademy – Romeo Lungu Page 24


Cisco Networking Academy
www.infoacademy.net

 Router(config-router)# area <AID_sursa> range <pfx> <NM> not-advertise


filtreaza trimiterea atat a prefixelor „suport‟ pentru pfx, cat si a prefixului pfx. Acestea nu vor fi publicate in OSPF.

4). Se poate configura in OSPF ca prefixele suport sumarizate de un ASBR (prefixe externe, publicate prin LSA-uri de
tip 5 ori 7), impreuna cu insusi prefixul sumarizat, sa nu fie introduse in domeniul de routare OSPF.
Comanda cu parametrul not-advertise:
 Router(config-router)# summary-address <pfx> <NM> not-advertise
filtreaza trimiterea atat a prefixelor „suport‟ pentru pfx, cat si a prefixului pfx. Acestea nu vor fi publicate in OSPF.
Se vizualizeaza pe ASBR prefixele filtrate prin:
 Router# show ip ospf summary-address

5). Daca se configureaza comenzi Router(config-router)# distribute-list pentru directia out, prefixele externe (si numai
ele) redistribuite de un router ASBR in domeniul OSPF si identificate prin deny printr-o lista de acces, prefix-list sau route-
map nu vor fi trimise in LSU-uri in INTERIORUL process-domain-ul OSPF. Se opreste astfel generearea de LSA-uri de tip
5.
Utilizarea route-maps in acest context permite identificarea flexibila a unor atribute ale LSA-urilor OSPF in raport cu
care sa fie luata apoi decizia daca se va instala sau nu acel prefix in RIB: match interface, match ip address [prefix], match
ip next-hop, match ip route-source, match metric, match route-type sau match tag.
Se poate vizualiza configuratia de filtrare prin:
 Router# show ip protocols

17. Optimizarea timpului de convergenta in OSPF (To Do)


Versiuni recente de IOS permit asocierea OSPF la BFD (Bidirectional Forwarding Detection), ceea ce permite un timp
de convergenta extrem de mic (sute de ms) in conditiile pierderii canalului fizic sau/si logic de comunicare de L1, L2 sau/si
L3 intre doua routere OSPF vecine.
Configuratie OSPF minimala:
 Router(config-router)# bfd all-interfaces

In conditiile schimbarii pe o interfata a parametrilor de interes OSPF dupa momentul realizarii relatiei de vecinatate
intre doua routere (de exemplu se modifica IP-ul principal, NM-ul, Hello-time, Aria sa), cele doua routere isi pastreaza
relatia de vecinatate pana la trecerea intervalului de timp Dead-time, fapt ce nu contribuie la un timp de convergenta mic.

18. Miscelanee:
- Nu se realizeaza vecinatatea daca IP principal al unui router se gaseste in alt spatiu de adrese IP decat IP-ul pricipal al
celuilalt router (chiar daca se gaseste in spatiul de adrese al IP-ului secundar).

- Se realizeaza relatia de vecinatate daca avem configurate la ambele capete ip unnumbered (doar pentru interfete seriale si
chiar daca IP-urile se gasesc in spatii de adrese IP diferite). In outputul comenzilor de tip “show ip ospf...” va apare indexul
corespunzator din MIB II al interfetei, si nu adresa IP.

- PRC (Partial Route Calculation) se poate realiza doar pentru LSA de tip 3, 4, 5 si 7, adica pentru modificarile de topologie
din alte arii sau din afara process-domain-ului OSPF.

- Pentru a publica prin OSPF o interfata logica de tip loopback sau o interfata fizica (configurata logic sau manipulata fizic in
a fi looped-back) cu un NM diferit de /32 avem variantele:
2. configuram interfata ca avand tipul de retea OSPF point-to-point:
 Router(config-if)# ip ospf network point-to-point
3. redistributia “conected” (ce corespunde interfetei de loopback) in OSPF:

Infoacademy – Romeo Lungu Page 25


Cisco Networking Academy
www.infoacademy.net

 Router(config-router)# redistribute connected subnets route-map <RM>


4. configurarea interfetei de loopback intr-o arie diferita de cea unde se doreste propagarea sa cu NM diferit de
/32, urmat de sumarizare cu ajutorul comenzii area <AID> range <pfx> <pfx-lgth> la lungimea de NM dorita.

- Daca la redistribuirea in OSPF dorim preluarea de subretele (subnets) din protocolul de routare sursa, este necesar sa
adaugam comenzii redistribute parametrul subnets. In caz contrar, nu se vor redistribui decat retele classfull in OSPF.
Subnets este un parametru unic pentru OSPF in cadrul comenzii redistribute. Exemplu:
 Router(config-router)# redistribute eigrp 100 metric 10 subnets

- In urma redistributiei, by-default, tipul rutei externe va fi 2 (E2), iar metrica, cu exceptia rutelor redistribuite din BGP ce vor
avea metrica de 1, va fi de 20. Atat tipul (E1/E2 sau N1/N2 intr-o arie NSSA) cat si metrica pot fi configurate in procesul de
redistributie. Daca acesti parametri se precizeaza atat in comanda redistribute cat si in route-map-ul optional, se va tine
cont de configuratia din route-map.
In urma redistributiei din OSPF in OSPF se pastreaza metrica prefixelor intra-area, inter-area si external. Prefixul
redistribuit va fi propagat in OSPF sub forma unui LSA de tip 5 (sau 7) cu metric-type by default de tip 2.

O metrica de tip E2 nu isi schimba valoarea caluclata de SPF pe masura ce ne „indepartam‟ de routerul de origine a acelui
LSA 5. Am putea sa o folosim in cazul in care dorim utilizarea unei cai de backup de acces in Internet/o interretea externa
(avem o cale cu o metrica E2 mare (are rol de backup) si o cale cu o metrica E2 mica (va fi conexiunea principala)).

O metrica de tip E1 va avea la valoarea sa adaugat costul intra-area (si eventual, inter-area), prin urmare valoarea sa
calculata de SPF creste pe masura ce ne „indepartam‟ de routerul de origine al acelui LSA 5. Am putea sa o folosim in cazul
avem cai multiple de acces catre acelasi prefix extern, si dorim preferarea caii cu metrica cumulata cea mai mica, evitand
rutarea suboptima.

- OSPF permite limitarea numarului de prefixe redistribuite in interiorul OSPF din alte surse de informatie de routare (precum
BGP) prin comanda:
 Router(config-router)# redistribute maximum-prefix <pfx> [<warn_percent> [warning-only]] |
[warning-only] unde,
- warn_percent are valoarea default de 75 (%) si variaza intre 1 si 100 (%).
- pfx reda numarul de prefixe maxim acceptat a fi redistribuite in OSPF. Are valori posibile intre 1 si 232-1.
- daca se foloseste warning-only nu se limiteaza numarul de prefixe redistribuite, dar se vor genera in schimb
doua mesaje de warning, la atingerea warn_percent si la atingerea a 100%.
- daca NU se foloseste warning-only se va limita numarul prefixelor redistribuite la pfx si se vor genera doua
mesaje de warning, la atingerea warn_percent si la atingerea a 100%.

- Atentie la filtrarea configurata cu ACL-uri pe interfata unui router, switch, firewall sa. Daca se doreste primirea mesajelor
OSPF trebuie permis in ACL-ul static extins protocol number 89 (sau se poate folosi cuvantul cheie ospf).

- Comanda network, in versiunile recente de IOS, va lua in considerare gradul de precizie a perechii IP/invers_network_mask
configurate in config-router (ex: 10.0.1.0 0.0.0.255 este mai precis decat 10.0.0.0 0.255.255.255, iar 10.0.1.1 0.0.0.0 este
mai precis decat amandoua), considerand o interfata in aria corespunzatoare comenzii mai precise, indiferent de ordinea
introducerii comenzilor network in running-config. In trecut, ordinea introducerii comenzilor network conta, ultima
(indiferent de gradul de precizie) dictand aria de apartenenta. In plus, in prezent, IOS-ul automat reordoneaza comenzile
network de la cea mai precisa la cea mai putin precisa.

- Comanda network in OSPF nu indica ce prefixe vor fi trimise in mesajele OSPF ci pe ce interfete vom initia procesul (prin
mesaje Hello) de descoperire a vecinilor OSPF.

- Toate interfetele up si up configurate cu IP ale routerului vor fi mentionate in router-LSA, doar daca sunt „acoperite‟ de
comanda network, in caz contrar nu vor apare in router LSA.

- Parametrul comenzii network poate fi atat un invers de network mask (nu un wildcard mask ACL!), cat si un network mask,
IOS-ul transformandu-l pe acesta din urma in invers de network mask in running-config. Ambele variante sunt acceptate:
Infoacademy – Romeo Lungu Page 26
Cisco Networking Academy
www.infoacademy.net

 Router(config-router)# network 10.0.1.0 255.255.255.0


 Router(config-router)# network 10.0.1.0 0.0.0.255  asa vor apare amandoua in running-config

- Schimbarea tipului de retea OSPF la nivelul unei interfete/subinterfete atrage dupa sine potentiala schimbare automata a
Hello si Dead time-ului la valori noi, corespunzatoare noului tipului de retea (vezi Tabel 1).

- Schimbarea Hello time-ului OSPF pe o interfata/subinterfata, automat atrage dupa sime schimbarea Dead time-ului la 4x
valoarea configurata pentru Hello. Desigur, putem stabili manual orice alta valoare acceptata pentru Dead time.
Invers, schimbarea Dead-time-ului, nu atrage dupa sine modificarea automata a Hello-time-ului.
Valorile minime atat pentru dead-time cat si hello-time sunt de 1 secunda!

Exceptie de la mentiunea de mai sus: folosind comanda Router(config-if)# ip ospf dead-interval minimal hello-multiplier
<nr> se cere IOS-ului sa configureze dead-interval la 1 secunda si hello-time la 1/<nr> sec. Nr poate lua valori intre 3 si
20.

- BW de referinta (by default 100 Mbps), prin configurare manuala, poate diferii de la un router la altul. Se recomanda, pentru
a pastra semnificatia unitara a metricii, ca schimbarea acestuia, daca se doreste, sa fie replicata pe toate echipamentele ce
participa in process-domain-ul OSPF.

- Schimbarea BW administrativ la nivelul unei interfete loopback nu va schimba costul OSPF asociat acelei interfete. Daca se
doreste schimbarea acestui cost trebuie folosita comanda ip ospf cost.

- Comanda neighbor nu functioneaza decat in cazul vecinilor la care suntem conectati prin retele OSPF de tip non-broadcast
sau point-to-multipoint (broadcast sau non-broadcast).

In cazul retelei OSPF point-to-multipoint broadcast este obligatorie precizarea parametrului de cost sau a parametrului
databse-filter all out (deoarece, tehnic, nu este necesara comanda neighbor in acest caz decat pentru a preciza acesti
parametri speciali).
In cazul retelei OSPF point-to-multipoint non-broadcast se pot preciza drept parametrii cost si database-filter all out, dar, la
fel de bine, se poate omite utilizarea acestora - comanda neighbor are acum o utilitate intrinseca.
Ambele tipuri de retea point-to-multipoint nu permit utilizarea parametrilor poll-interval si priority. Acestia sunt rezervati
exclusiv pentru tipul de retea OSPF non-broadcast.

Tipul de retea OSPF point-to-multipoint (non-broadcast sau broadcast) permite asocierea unor costuri locale (insumate cu
cele primite) diferite per vecin, prin comanda neighbor <IP_vecin> cost <nr>. Aceasta permite alegerea vecinului preferat
pentru comutarea de pachete catre un prefix pentru care avem redundata in comunicatie prin aceeasi interfata/subinterfata.
Daca nu precizam costul per vecin se va folosi costul OSPF al interfetei fizice/logice.
Exemplu:
 Router(config-router)# neighbor 1.2.3.4 cost 100  costul variaza intre 1 si 65535

Pentru retelele OSPF de tip non-broadcast se permite folosirea doar a parametrilor poll-interval si priority pentru comanda
neighbor - se permite, de asemenea, si absenta acestor parametri din comanda mentionata. In acest ultim caz IOS-ul
automat adauga parametrul priority egal cu 0 si parametrul poll-interval egal cu 120 de secunde. Acestia nu apar in running-
config, fiind valori default.

Configurarea comenzii neighbor este suficienta doar la unul din capetele conexiunii point-to-point fizice/logice. Prioritatea,
by-default asociata de routerul ce contine comanda neighbor pentru celalalt router este de 0; ea este configurabila intre 0 si
255. Daca se doreste ca unul din cele 2 routere sa devina DR iar celalalt sa indeplineasca mereu rolul de DROTHER (cazul
retelelor partial mesh) va trebui ca acesta din urma sa fie explicit configurat cu prioritatea 0 (by default este 1) si asta pentru
ca in aprecierea prioritatii unui router se tine cont de valoarea maxima intre prioritatea configurata local pentru acel router
(comanda neighbor) si cea primita de la acel vecin, prin mesaje Hello (comanda ip ospf priority).

- Exista o diferenta intre Router(config-if)# ip ospf <PID> area <AID> [secondaries none] si comanda Router(config-
router)# network ... in “prinderea” interfetelor de interes pentru OSPF. Comanda ip ospf <pid> area <AID> are drept efect
Infoacademy – Romeo Lungu Page 27
Cisco Networking Academy
www.infoacademy.net

trimiterea in LSA 1 (router-LSA) atat a informatiei despre IP-ul principal cat si despre IP-urile secundar (posibile)
configurate pe acea interfata prin redarea acestora din urma sub forma unor linkuri de tip stub in LSA-ul 1. “Prinderea”
spatiilor de adrese secundare nu mai are insa loc daca se foloseste parametrul optional secondaries none.
Comanda network nu trimite informatii despre IP-urile secundare decat daca acestea sunt “prinse”, la randul lor, de o (noua)
comanda network.
Daca se folosesc amandoua, comanda de la nivelul interfetei are prioritate in stabilirea ariei de apartenenta.

- Spatiul de adrese IP corespunzator unei retele OSPF point-to-multipoint va fi cunoscut in RIB-ul altor routere din aceeasi
arie sub forma unor host-route corespunzatoare IP-ului routerelor conectate la reteaua point-to-multipoint (si nu cu NM
efectiv alocat acelui spatiu).

- Comanda Router(config-router)# passive interface {default | <intf>} are drept efect incetarea trimiterii mesajelor de tip
Hello cat si incetarea acceptarii lor – drept urmare, nu se vor forma relatii de vecinatate si adiacenta pe acea interfata. Se
vor trimite insa, sub forma de link stub, informatii despre respectiva interfata (spatiul de adrese IP, cost, sa) in LSA-ul de tip
router (LSA 1). Daca reteaua, dpdv OSPF, la care se conecteaza interfata este broadcast sau NBMA, router-ul nostru se va
alege pe sine “informal” drept DR al acelui data-link.
Interfata pasivizata va apare (spre deosebire de EIGRP intr-un scenariu similar) in output-ul lui show ip ospf int brief, iar in
output-ul lui show ip ospf int <intf> se va mentiona “No Hellos (Passive interface)”.
Interfata pasivizata va apare si intr-o sectiune proprie in output-ului comenzii Router# show ip protocols.

- O interfata seriala point-to-point configurata de tip unnumbered ce refera pentru adresa sa de L3 o alta interfata, se va gasii
in aceeasi arie OSPF cu acea interfata daca comanda de specificare a „interesului‟ OSPF in acea alta interfata este de tip
network.
In cazul in care comanda de specificare a „interesului‟ OSPF in acea alta interfata este insa de tip ip ospf <PID> area
<AID>, interfata seriala unnumbered nu va fi considerata de interes pentru OSPF.

- Versiunile recente de IOS dispun de comanda Router(config-router)# shutdown , utila daca se doreste oprirea procesului
OSPF fara insa a se cere deconfigurarea sa.

- Redistribuirea unei rute direct conectate sau invatate din alt protocol de rutare dinamic atrage dupa sine, pana la vers de IOS
12.1(3), crearea de LSA-uri de tip 5 pentru rutele direct conectate respective (preluate din connected sau „prinse‟ de alt RP)
indiferent daca acele prefixe direct conectate erau deja „de interes‟ OSPF si propagate prin LSA-uri de tip 1, 2 sau 3. IOS-uri
ulterioare nu genereaza LSA-uri de tip 5 pentru respectivele prefixe direct conectate, ci doar pentru prefixele „noi‟
redistribuite in OSPF.

- Configurarea unei interfete ca fiind de interes OSPF atat prin comanda ip ospf <PID> area <AID> cat si prin comanda
network va duce la asocierea acelei interfete la aria precizata in comanda ip ospf <PID> area <AID>. Altfel spus, in acest
caz se va ignora comanda network.

- In running-config se pastreaza distinct formatul Area Number ales in configurarea in „config-router‟ a comenzii network, ex:
network …. area 0 dar si network … area 0.0.0.0

- Adresele IP secundare configurate pe o interfata trebuie sa fie publicate in domeniul de routare OSPF ca apartinand aceleiasi
arii cu cea in care se gaseste adresa IP principala a acelei interfete. In caz contrar, acele adrese IP secundare nu vor fi
publicate/mentionate in LSA-ul de tip router.
Daca se voar publica totusi aceste adrese IP secundare, ele vor fi mentionate in LSA-ul de tip router sub forma unor link-uri
de tip stub.

- Nu se pot configura in IOS pe acelasi router doua sau mai multe procese OSPFv2 ce folosesc acelasi RID.
Nu se pot configura in IOS pe acelasi router doua sau mai multe procese OSPFv2 ce folosesc aceeasi interfata.
Nu se poate configura in IOS pe acelasi router ca un process OSPF sa asocieze o interfata la doua sau mai multe arii.
Se poate configura in IOS ca un proces OSPFv2 si un proces OSPFv3 sa utilizeze acelasi RID.

Infoacademy – Romeo Lungu Page 28


Cisco Networking Academy
www.infoacademy.net

Se poate configura in IOS ca un proces OSPFv2 si un proces OSPFv3 sa utilizeze aceeasi interfata.
Se poate configura in IOS ca un proces OSPFv2 si un proces OSPFv3 sa utilizeze acelasi process ID (PID).

- Putem proteja procesul OSPF de un numar excesiv deLSA-uri ce ar afecta performanta routerului (CP si RAM) prin feature-
ul OSPF Link State Database Overload Protection. Acesta permite limitarea numarului de LSA-uri primite (non-proprii).
 Router(config-router)# max-lsa <maximum-number> [<threshold-percentage>] [warning-only]
[ignore-time <minutes>] [ignore-count <count-number>] [reset-time <minutes>]

unde: - maximum-number are valori intre 1 si 232-1 si reprezinta numarul maxim de LSA-uri non-proprii acceptat.
- threshold-percentage reprezinta un procent intre 1 si 100 la care se va genera un mesaj de warning. By default
egal cu 75.
- warning-only: se va genera doar un mesaj de warning la 100% de LSA-uri primite. Nu este default.
- ignore-time <minutes>: numarul de minute in care se vor ignora toti vecinii OSPF (se renunta la relatia de
vecinatate). By-default 5 minute.
- ignore-count <count-number>: numarul de ori in care se va putea intra in starea de ignore fara a fi necesara
interventia manuala pentru a iesi din aceasta stare. By-default 5.
- reset-time <minutes>: numarul de minute in care, daca procesul OSPF nu se gaseste in starea de ignore se va
reseta la zero ignore-count. By-default 10 minute.

Odata (re)configurat max-lsa procesul OSPF se va reseta.


Vizualizarea configuratiei se face prin: Router# show ip ospf ;apare numarul de minute cat se mai gaseste procesul OSPF in
ignore state, cate minute mai dureaza pana la resetarea automata a contorului ignore-count, cat si configuratiile
introduse/default.
Resetarea contorului ignore-counter se face prin Router# clear ip ospf [<pid>] process .

- Chiar daca se configureaza Router(config)# no ip classless se vor folosi rutele ultimate de tip superretea (deci si ruta default
0.0.0.0/0) pentru comutarea de pachete pe acel router atata timp cat respectivele superretele au fost introduse in RIB de catre
OSPF sau de catre iIS-IS. Altfel spus, routarea classfull nu functioneaza in cazul in care protocoale de routare link-state au
instalat in RIB superretele.

18. Referinte:
- Cisco OSPF FAQ
- Cisco OSPF Design Guide
- Optimizare OSPF (Bring your network closer to five nines with Graceful Shutdown)
- OSPF network types si Frame Relay
- Alegerea caii optime dintre rutele externe E2
- Cisco OSPF troubleshooting 1 (Why Are Some OSPF Routes in the Database but Not in the Routing Table?)
- Cisco OSPF troubleshooting 2 (Duplicate Router ID)
- Cisco Shortest Path Throttling
- OSPF Point-to-Multipoint Networks with Neighbors
- Why Are Some OSPF Routes in the Database but Not in the Routing Table?
- Filtrarea routelor OSPF prin distribute-lists cu route-maps
- Conditional OSPF default route origination based on classless IP prefixes

Infoacademy – Romeo Lungu Page 29