Rutare dinamică

1Recapitulare4 min

Astăzi umplem tabela altfel. Sursele noi de rute - RIP, OSPF, EIGRP - au fiecare propria distanță administrativă și propria metrică, iar ruterul trebuie să le compare pe toate. Ordinea comparării este exact cea din cursul 6, și e bine să fie proaspătă în minte.

Rezultate ale învățării

• Să explicați de ce rutele statice nu scalează și ce anume rezolvă un protocol dinamic
• Să distingeți între distance-vector, link-state și path-vector
• Să descrieți problema buclelor la distance-vector și mecanismele care o atenuează
• Să enumerați cei patru pași ai unui protocol link-state
• Să aplicați Dijkstra pe o topologie mică și să obțineți arborele drumurilor minime
• Să calculați costul OSPF al unei legături și să știți când formula dă rezultate greșite
• Să explicați de ce se aleg DR și BDR și cum decurge alegerea
• Să configurați OSPF single-area și să depanați o adiacență care nu se formează

2De ce nu ne ajung rutele statice7 min

Cele două nu se exclud. Chiar și într-o rețea complet OSPF, ruta implicită spre furnizor este aproape întotdeauna statică - pentru că nu are cu cine să fie negociată.

3Familiile de protocoale8 min

Prima împărțire ține de unde se folosesc: în interiorul unei organizații, sau între organizații.

A doua împărțire, cea care ne interesează astăzi, ține de ce știe fiecare ruter:

4Distance-vector și problema buclelor10 min

Un protocol distance-vector, precum RIP, funcționează pe un principiu simplu: fiecare ruter trimite periodic vecinilor întreaga sa tabelă de rutare, iar aceștia adaugă costul legăturii și decid. Nimeni nu vede topologia; fiecare crede ce i se spune. De aici și porecla care i s-a lipit definitiv: routing by rumour - rutare din zvonuri.

Numărătoarea spre infinit

5Cum lucrează un protocol link-state10 min

Ideea centrală este că fiecare ruter nu află rutele de la vecini, ci află starea legăturilor din întreaga rețea, își construiește harta completă și calculează singur drumurile. Patru elemente fac asta posibil.

Adiacențele și protocolul Hello

Doi vecini direct conectați formează o adiacență. Relația se stabilește și se întreține prin mesaje Hello periodice, care au dublu rol: keep-alive - dacă mesajele încetează, vecinul e considerat căzut - și sincronizarea parametrilor. Vecinii cunoscuți se păstrează într-o tabelă de vecini.

ID_R2 - Fa0/1 - 00:13 - FULL
ID_R3 - Fa0/2 - 00:00 - LOADING
!       interfata  timp de la ultimul hello  starea adiacentei

LSP: unitatea de informație

Un LSP (Link State Packet) descrie legăturile unui ruter: pentru fiecare interfață, rețeaua atașată, tipul legăturii, costul, starea ei și vecinul de la celălalt capăt. LSP-urile se trimit:

• la inițializarea procesului de rutare;
• imediat ce apare o schimbare în topologie - mecanismul de triggered update, sursa convergenței rapide;
• periodic, la interval mare (în OSPF, o dată la 30 de minute), ca reîmprospătare.

Imediat ce un ruter primește un LSP nou, îl retransmite tuturor celorlalți vecini. Procesul se numește flooding și asigură că, în câteva zecimi de secundă, toată rețeaua are aceeași informație.

Cei patru pași

1. Adiacențe și rețele conectate. Ruterul își descoperă vecinii și rețelele direct conectate.
2. Flooding de LSP-uri. Fiecare ruter anunță ce știe și retransmite ce primește.
3. Popularea tabelei de topologie. Toate rețelele primite se păstrează, cu costurile lor - nu doar cele mai bune. Aceasta este harta.
4. Dijkstra. Se rulează algoritmul drumurilor minime, cu ruterul curent în vârf. Doar rezultatele ajung în tabela de rutare.

6Algoritmul lui Dijkstra11 min

Alegeți ruterul care calculează și observați că arborele obținut este diferit pentru fiecare: fiecare ruter se pune pe sine în vârf. Harta e aceeași; arborele nu.

Apoi modificați costul unei legături din arbore și urmăriți cum traficul se mută pe altă cale - exact ce se întâmplă într-o rețea reală când un administrator ajustează banda declarată a unei interfețe. Este principalul instrument de inginerie a traficului în OSPF: nu se schimbă cablurile, se schimbă costurile.

7OSPF: caracteristici de bază9 min

OSPF (Open Shortest Path First) a fost dezvoltat de IETF începând cu 1988, ca alternativă deschisă la protocoalele proprietare ale vremii. OSPFv2 (RFC 2328) este varianta pentru IPv4, OSPFv3 (RFC 5340) cea pentru IPv6.

8Mesajele și stările adiacenței9 min

9DR și BDR pe rețele multiacces10 min

Pe o legătură punct-la-punct există o singură adiacență posibilă și nicio problemă. Pe un segment Ethernet cu n rutere, dacă fiecare ar forma adiacență cu fiecare, ar rezulta n(n−1)/2 relații - 45 pentru zece rutere, fiecare cu propriile mesaje Hello, propriile sincronizări și propriile retransmiteri.

Soluția este centralizarea: se alege un DR (Designated Router), care primește și redistribuie actualizările, și un BDR (Backup DR), care preia dacă DR cade. Toate celelalte rutere (DROTHER) formează adiacență doar cu DR și BDR. Numărul de adiacențe scade la 2(n−1).

Criteriile de alegere

1. Prioritatea cea mai mare de pe interfață (implicit 1). Valoarea 0 exclude ruterul din alegere.
2. La egalitate, Router ID-ul cel mai mare.

Router ID-ul se determină, la rândul lui, în trei pași, în ordine strictă:

1. valoarea configurată manual cu router-id;
2. cea mai mare adresă IP de pe o interfață de loopback;
3. cea mai mare adresă IP de pe o interfață fizică activă.

! ruterul care trebuie sa fie DR
R1(config)# interface gigabitEthernet 0/0
R1(config-if)# ip ospf priority 100

! ruterul care nu trebuie sa fie niciodata DR sau BDR
R3(config)# interface gigabitEthernet 0/0
R3(config-if)# ip ospf priority 0

! Router ID stabil, printr-o interfata care nu cade
R1(config)# interface loopback 0
R1(config-if)# ip address 1.1.1.1 255.255.255.255
R1(config)# router ospf 1
R1(config-router)# router-id 1.1.1.1

! alegerea nu e preemptiva - trebuie fortata
R1# clear ip ospf process

10OSPF pe mai multe arii10 min

Dijkstra rulează cu atât mai lent cu cât graful e mai mare, iar orice schimbare într-un colț al rețelei obligă toate ruterele să recalculeze totul. Soluția de scalare este împărțirea domeniului OSPF în arii: fiecare arie rulează Dijkstra pe propriul graf, iar pentru destinațiile din afara ei doar adună distanța până la ruterul de frontieră.

Tipurile de LSA

Codurile din tabela de rutare

Când există atât o rută E1, cât și una E2 spre aceeași destinație, se preferă E1: fiind cumulativă, reflectă mai fidel costul real al drumului. E2 este implicit tocmai pentru că e mai simplu - dar e și mai puțin exact.

11Configurare și verificare9 min

R1(config)# router ospf 1
R1(config-router)# router-id 1.1.1.1

! ce interfete participa - masca este WILDCARD, ca la ACL-uri
R1(config-router)# network 192.168.10.0 0.0.0.255 area 0
R1(config-router)# network 10.0.0.0 0.0.0.3 area 0

! interfata spre statii: anunta reteaua, dar nu trimite Hello
R1(config-router)# passive-interface gigabitEthernet 0/0

! ajustarea referintei - ACEEASI valoare pe toate ruterele
R1(config-router)# auto-cost reference-bandwidth 10000

! ruta implicita spre furnizor, anuntata in tot domeniul OSPF
R1(config)# ip route 0.0.0.0 0.0.0.0 203.0.113.1
R1(config-router)# default-information originate

Priviți prima comandă: a treia linie arată 2WAY/DROTHER cu prioritate 0. Nu este o eroare - este exact ce trebuie să se întâmple între două rutere obișnuite pe un segment multiacces. Doar adiacențele cu DR și BDR ajung la FULL.

Iar în tabela de rutare se citesc, dintr-o privire, cele trei origini: O din aceeași arie cu cost 2, O IA din altă arie cu cost 12, și O E2 externă, cu costul fix 20 care nu se schimbă oricât ar fi drumul intern.

12Erori frecvente4 min

• „Adiacența e blocată în Exchange" Cele două capete au MTU diferit și refuză să sincronizeze bazele de date. show ip ospf interface pe ambele, comparați MTU-ul. Sau ip ospf mtu-ignore, ca soluție de avarie.
• „Vecinii sunt în Two-Way și nu trec mai departe" Dacă sunt două DROTHER-e pe un segment multiacces, este comportamentul corect. Verificați cine e DR. Adiacențele complete există doar cu DR și BDR.
• „Am pus reference-bandwidth doar pe un ruter" Costurile devin incoerente: același drum are valori diferite văzut din capete diferite. Aceeași valoare pe toate ruterele din domeniu. Fără excepție.
• „Am folosit masca de rețea în comanda network" OSPF cere wildcard, exact ca ACL-urile. network 10.0.0.0 0.0.0.3 area 0, nu 255.255.255.252.
• „Am uitat passive-interface pe segmentele cu stații" Ruterul trimite Hello-uri spre utilizatori: bandă irosită și o ușă de atac deschisă - oricine poate porni un proces OSPF fals. passive-interface default, apoi no passive-interface doar unde chiar există vecini.
• „Ruterul nou nu devine DR, deși are prioritate 200" Alegerea nu este preemptivă. Nu e o defecțiune. clear ip ospf process, dacă chiar aveți nevoie de realegere.
• „Am configurat OSPF, dar ruta implicită nu ajunge la ceilalți" O rută statică nu intră singură în OSPF. default-information originate pe ruterul de margine.

13Rezumat și glosar4 min

14Întrebări de verificare6 min

15Direcții de aprofundare2 min

Cursul următor părăsește firul și trece în aer: rețele wireless, cu problemele lor specifice de acces la mediu - nu se poate asculta și transmite simultan, deci CSMA/CD nu funcționează - și cu o problemă de securitate pe care rețeaua cablată nu o are: mediul este public prin definiție.

Laboratorul 5 configurează OSPF single-area pe exact aceeași topologie pe care ați scris, mai devreme, rute statice. Comparația dintre cele două configurații, ca număr de linii și ca reacție la un cablu scos, este scopul lucrării.

• RFC 2328 - OSPF versiunea 2
• RFC 5340 - OSPF pentru IPv6
• RFC 3630 - extensii de inginerie a traficului pentru OSPF
• RFC 2453 - RIP versiunea 2, pentru comparație
• John Moy, OSPF: Anatomy of an Internet Routing Protocol