OSPF-facts-CCNP

Cisco Networking Academy

www.infoacademy.net

Infoacademy – Romeo Lungu

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

http://www.faqs.org/rfcs/rfc2740.html



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:


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.


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.


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


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):


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.


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:

Nume tip

retea OSPF

Necesita

(se alege)

DR/BDR?

Necesita

comanda

neighbor?

Se trimite

Hello m-cast

sau u-cast?

Hello /

Dead

interval

Mai mult

de 2

routere?

Se publica

un host

route?(6)

Standard

IETF? (3)

Compa-

tibile? (4)

NEXT-

HOP? (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

NBMA (2)

Da Da Unicast 30 / 120 Da Nu Da X Spoke

Point-to-

multipoint

[broadcast] (7)

Nu Nu Multicast 30 / 120 Da Da Da O Hub

Point-to-

multipoint

non-broadcast

Nu Da Unicast 30 / 120 Da Da Nu O Hub

Loopback Nu - - - Nu Da - - -

Nume tip

retea OSPF Spatiu de adrese? Tpopologia logica?

Broadcast 1 singur subnet Full mesh, partial mesh

Point-to-point (1)

1 singur subnet pe subintf p-t-p/VC

Partial mesh, hub & spoke

NBMA (2)

1 singur subnet Full mesh, partial mesh

Point-to-

multipoint

[broadcast] (7)

1 singur subnet Partial mesh, hub &

spoke

Point-to-

multipoint

non-broadcast

1 singur subnet Partial mesh, hub &

spoke

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


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.


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.


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,


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:


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.


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

Router# debug ip ospf events

Outputul comenzii evidentiaza eroarea sub

forma de “C” – configured si “R” - received

Network Mask diferit Router# debug ip ospf hello Outputul comenzii evidentiaza eroarea sub


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:

“..with mismatched Stub/Transit area option bit”

Numar de arie diferit Router# debug ip ospf adj

Router# debug ip ospf events “.. mismatch area x.x.x.x in the header”

Tip/configurare de autentificare diferita Router# debug ip ospf adj



“Mismatch Authentication type. Input packet…”

Acelasi Router ID cu un vecin direct conectat -

Eroarea este redata automat prin sistemul de logging la aproximativ 1 minut:

“%OSPF-4-DUP_RTRID_NBR …”

Acelasi Router ID cu un vecin indirect

conectat, din aceeasi arie Router# debug ip ospf flood Se va cauta in mesajul de logging:

“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

regaseste in spatiul propriu de adrese IP Router# debug ip ospf adj



“... 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.


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),


www.infoacademy.net


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

Tip de arie Injecteaza

LSA 4 si 5? Injecteaza

LSA 3? Accepta crearea

LSA 7?

Genereaza automat o

ruta default?

Compatibile? (1)

Standard sau proprietar

Cisco? Stub Nu Da Nu Da X standard

Totally stubby Nu Nu Nu Da X Cisco Not-so-stubby

(NSSA) Nu Da Da Nu O standard

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


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:


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.



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).


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:


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


www.infoacademy.net


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


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


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


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.


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:


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:


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 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:


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:


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:


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:


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


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.


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

http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/ospfopro.html

http://www.cisco.com/en/US/tech/tk365/technologies_q_and_a_item09186a0080094704.shtml

http://www.cisco.com/en/US/tech/tk365/technologies_white_paper09186a0080094e9e.shtml

http://www.nil.si/ipcorner/OSPFGracefulShutdown/

http://ardenpackeer.com/routing-protocols/tutorial-ospf-network-types-and-frame-relay-part-1/

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080124c7d.shtml

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a008009481a.shtml

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080117102.shtml

http://www.cisco.com/en/US/docs/ios/12_2s/feature/guide/fs_spftrl.html

http://www.cisco.com/en/US/docs/ios/11_3/feature/guide/ospfpmp.html

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a008009481a.shtml#r1

http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/routmap.html

http://wiki.nil.com/Conditional_OSPF_default_route_origination_based_on_classless_IP_prefixes

OSPF-facts-CCNP

Documents

Transcript of OSPF-facts-CCNP