Rutare dinamică în Linux. Protocolul de rutare dinamică RIP

Rețeaua Lift mi Up, împreună cu personalul său, crește în departe. Întreținerea infrastructurii IT a fost transferată unei organizații separate special create „Link Me Up”.
Chiar zilele trecute, încă patru sucursale au fost achiziționate în diferite orașe, iar investitorii au descoperit noi dimensiuni ale mișcării lifturilor. Și rețeaua a crescut de la patru routere la zece simultan. În același timp, numărul de subrețele a crescut acum de la 9 la 20, fără a lua în calcul legăturile punct la punct între routere. Și aici se pune problema administrării întregii economii. De acord, adăugarea manuală a rutelor la toate rețelele de la fiecare nod nu este foarte distractiv.
Situația este complicată de faptul că rețeaua din Kaliningrad are deja propria sa adresare, iar pe ea rulează protocolul de rutare dinamică EIGRP.
Așadar, astăzi:

• Să înțelegem teoria protocoalelor de rutare dinamică.
• Introducem „Lift mi Up” în rețea protocol OSPF
• Configurarea transferului (redistribuirii) rutelor între OSPF și EIGRP
• În această versiune, adăugăm o secțiune „Sarcini”. Următoarele pictograme vă vor ajuta să le identificați pe parcursul articolului:

Nivelul de dificultate va varia. Toate problemele vor avea răspunsuri care pot fi vizualizate la. În unele dintre ele va trebui să vă gândiți, în altele va trebui să citiți documentația, în altele va trebui să înțelegeți topologia și poate chiar să vă uitați la informațiile de depanare. Dacă o sarcină nu poate fi implementată în RT, vom face o notă specială despre aceasta.

Teoria protocoalelor de rutare dinamică

În primul rând, să înțelegem conceptul de „routare dinamică”. Până acum, am folosit așa-numita rutare statică, adică am scris manual un tabel de rutare pe fiecare router. Folosirea protocoalelor de rutare ne permite să evităm acest proces obositor, monoton și erorile asociate factorul uman. După cum sugerează și numele, aceste protocoale sunt concepute pentru a construi singure tabele de rutare, automat, pe baza configurației actuale a rețelei. În general, acesta este un lucru necesar, mai ales când rețeaua ta nu este de 3 routere, ci de 30, de exemplu.
Există și alte aspecte în afară de comoditate. De exemplu, toleranta la greseli. Având o rețea cu rutare statică, îți va fi extrem de dificil să organizezi canale de rezervă - nu există nimeni care să monitorizeze disponibilitatea unui anumit segment.

De exemplu, dacă într-o astfel de rețea legătura dintre R2 și R3 este întreruptă, atunci pachetele de la R1 vor continua să meargă la R2, unde vor fi distruse, deoarece nu există unde să le trimită.

Protocoalele de rutare dinamică în câteva secunde (sau chiar milisecunde) învață despre problemele din rețea și își reconstruiesc tabelele de rutare, iar în cazul descris mai sus, pachetele vor fi trimise de-a lungul rutei curente

O alta punct important - echilibrarea traficului. Protocoalele de rutare dinamică acceptă această caracteristică aproape imediat și nu trebuie să adăugați manual rute redundante calculându-le.

Ei bine, implementarea de rutare dinamică face mult mai ușor scalarea rețelei. Când adăugați un element nou la o rețea sau o subrețea de pe un router existent, trebuie să efectuați doar câțiva pași pentru ca totul să funcționeze, cu șanse minime de eroare, iar informațiile despre modificări sunt partajate instantaneu pe toate dispozitivele. Exact același lucru se poate spune despre modificările topologiei globale.

Toate protocoalele de rutare pot fi împărțite în două grupuri mari: externe ( E.G.P.- Protocol Gateway exterior) și intern ( IGP- Interior Gateway Protocol). Pentru a explica diferențele dintre ele, avem nevoie de termenul „sistem autonom”. Într-un sens general, un sistem autonom (domeniu de rutare) este un grup de routere aflate sub management comun.
În cazul rețelei noastre AS actualizate, va fi astfel:

Deci, protocoalele interne de rutare sunt folosite în cadrul unui sistem autonom, iar cele externe sunt folosite pentru a conecta sisteme autonome între ele. La randul lui, protocoale interne rutarea este împărțită în Distanță-Vector(RIP, EIGRP) și Starea legăturii(OSPF, IS-IS). În acest articol, nu vom lovi cadavrele, nu vom atinge protocoalele RIP și IGRP datorită vârstei lor venerabile, precum și IS-IS datorită absenței sale în PT.

Diferențele fundamentale dintre aceste două tipuri sunt următoarele:
1) tipul de informații pe care routerele le schimbă: tabele de rutare pentru vectorul distanță și tabele de topologie pentru starea legăturii,
2) procesul de alegere a celei mai bune rute,
3) cantitatea de informații despre rețea pe care fiecare router o „ține în cap”: Distance-Vector își cunoaște doar vecinii, Link State are o idee despre întreaga rețea.

După cum putem vedea, numărul de protocoale de rutare este mic, dar încă nu unul sau două. Ce se întâmplă dacă rulați mai multe protocoale pe router în același timp? Este posibil ca fiecare protocol să aibă propria sa opinie despre cum să ajungă cel mai bine la o anumită rețea. Și dacă avem și noi rute statice esti pus la punct? Cui îi va da preferință routerul și a cui rută îl va adăuga la tabelul de rutare? Răspunsul la această întrebare este asociat cu un nou termen: distanță administrativă (pentru gustul nostru, o copie destul de mediocră a distanței administrative engleze, dar nu au putut găsi una mai bună). Distanța administrativă este un număr întreg de la 0 la 255, exprimând „măsura de încredere” a routerului pe această rută. Cu cât AD este mai mic, cu atât mai multă încredere. Iată un semn de astfel de încredere din punctul de vedere al Cisco:

Protocol	Distanta administrativa
Interfață conectată	0
Rută statică	1
Traseu rezumat al EIGRP (Enhanced Interior Gateway Routing Protocol).	5
Protocolul de gateway de frontieră externă (BGP)	20
EIGRP intern	90
IGRP	100
OSPF	110
Sistem intermediar la sistem intermediar (IS-IS)	115
Protocolul de informații de rutare (RIP)	120
Protocolul exterior Gateway (EGP)	140
Rutare la cerere (ODR)	160
EIGRP extern	170
BGP intern	200
Necunoscut	255

În articolul de astăzi ne vom uita la OSPF și EIGRP. Primul îl vei vedea peste tot și tot timpul, iar al doilea este foarte bun în rețelele în care sunt prezente doar echipamente Cisco.
Fiecare dintre ele are propriile sale avantaje și dezavantaje. Putem spune că EIGRP este superior OSPF, dar toate avantajele sunt compensate de natura sa proprietară. EIGRP este un protocol proprietar Cisco și nimeni altcineva nu îl acceptă.
De fapt, EIGRP are multe dezavantaje, dar acest lucru nu este discutat în mod deosebit în articolele populare. Iată doar una dintre probleme: SIA

Asadar, haideti sa începem.

OSPF

Articole și videoclipuri despre cum să configurați munții OSPF. Mult mai puține descrieri ale principiilor de funcționare. În general, lucrul aici este că OSPF poate fi configurat pur și simplu conform manualelor, fără să știi măcar despre algoritmi SPF și LSA-uri de neînțeles. Și totul va funcționa și chiar, cel mai probabil, va funcționa perfect - pentru asta a fost conceput. Adică, nu este ca în cazul vlan-urilor, unde trebuia să cunoști teoria până la formatul antetului.
Dar ceea ce distinge un inginer de un tip IT este că înțelege de ce rețeaua lui funcționează așa cum o face și știe, nu mai rău decât OSPF însuși, care rută va fi aleasă de protocol.
În cadrul articolului, care în acest moment are deja 8.000 de caractere, nu ne vom putea scufunda în profunzimea teoriei, dar vom lua în considerare punctele fundamentale.
Este foarte simplu și clar, apropo, este scris despre OSPF pe xgu.ru sau în Wikipedia în engleză.
Deci, OSPFv2 funcționează pe deasupra IP și, în special, este proiectat numai pentru IPv4 (OSPFv3 nu depinde de protocoalele de nivel 3 și, prin urmare, poate funcționa cu IPv6).

Să ne uităm la cum funcționează folosind exemplul acestei rețele simplificate:

Pentru început, trebuie spus că pentru ca o relație de prietenie (relație de adiacență) să se dezvolte între routere, trebuie îndeplinite următoarele condiții:

1) aceleași setări trebuie configurate în OSPF Salut Interval pe acele routere care sunt conectate între ele. În mod implicit, este de 10 secunde în rețelele de difuzare, cum ar fi Ethernet. Acesta este un fel de mesaj KeepAlive. Adică, la fiecare 10 secunde, fiecare router trimite un pachet Hello vecinului său pentru a spune: „Hei, sunt în viață”.
2) Trebuie să fie la fel Interval mort pe ei. De obicei, acestea sunt 4 intervale Hello - 40 de secunde. Dacă nu se primește niciun salut de la vecin în acest timp, atunci acesta este considerat inaccesibil și PANIC începe procesul de reconstruire a bazei de date locale și de trimitere a actualizărilor tuturor vecinilor.
3) Interfețele conectate între ele trebuie să fie în o subrețea,
4) OSPF vă permite să reduceți sarcina CPU-ului routerelor prin împărțirea sistemului autonom în zone. Deci aici este numerele zonei trebuie de asemenea să se potrivească
5) Fiecare router care participă la procesul OSPF are propriul său unic identificator - ID router. Dacă nu aveți grijă de el, routerul îl va selecta automat pe baza informațiilor despre interfețele conectate (cea mai mare adresă este selectată dintre interfețele active la momentul începerii procesului OSPF). Dar, din nou, un inginer bun are totul sub control, așa că de obicei este creată o interfață Loopback, căreia i se atribuie o adresă cu o mască /32 și aceasta este ceea ce este atribuit ID-ului routerului. Acest lucru poate fi convenabil pentru întreținere și depanare.
6) Trebuie să se potrivească Dimensiunea MTU

1) Calm. Stare OSPF - JOS
În acest scurt moment, nu se întâmplă nimic în rețea - toată lumea tace.

2) Vântul se ridică: routerul trimite pachete Hello la adresa multicast 224.0.0.5 de la toate interfețele pe care rulează OSPF. TTL-ul unor astfel de mesaje este unul, deci doar routerele situate în același segment de rețea le vor primi. R1 intră în stare INIT.

Pachetele conțin următoarele informații:

• ID router
• Salut Interval
• Interval mort
• Vecini
• Mască de rețea
• ID zona
• Prioritate router
• Adresele routerelor DR și BDR
• Parola de autentificare

Momentan suntem interesați de primele patru, sau mai precis, doar Router ID și Neighbours.
Mesajul Salut de la routerul R1 poartă ID-ul său de router și nu conține vecini, deoarece nu îi are încă.
După primirea acestui mesaj multicast, routerul R2 adaugă R1 la tabelul său vecin (dacă toți parametrii necesari se potrivesc).

Și trimite un nou mesaj Salut către R1 ca unicast, care conține ID-ul routerului acestui router, iar lista Neigbors listează toți vecinii săi. Printre alți vecini din această listă există Router ID R1, adică R2 îl consideră deja un vecin.

3) Prietenia. Când R1 primește acest mesaj Salut de la R2, derulează prin lista de vecini și își găsește propriul ID Router în ea, adaugă R2 la lista de vecini.

Acum R1 și R2 sunt vecini reciproci unul cu celălalt - asta înseamnă că a fost stabilită o relație de adiacență între ei și routerul R1 intră în stare DOUĂ SENSE.

Sfaturi generale pentru toate sarcinile:

Chiar dacă nu știți imediat răspunsul și soluția, încercați să vă gândiți la ce se referă starea problemei:
- Ce caracteristici și setări de protocol?
- Aceste setări sunt globale sau legate de o anumită interfață?
Dacă nu cunoașteți sau ați uitat comanda, astfel de reflecții vă vor conduce cel mai probabil către contextul corect, unde puteți pur și simplu, cu ajutorul unui indiciu în Linie de comanda, vă puteți ghici sau vă puteți aminti cum să configurați ceea ce este necesar în sarcină.
Încercați să gândiți în acest fel înainte de a merge pe Google sau pe un site care caută comenzi.

Într-o rețea reală, atunci când alegeți gama de subrețele promovate, trebuie să vă ghidați după reglementări și nevoi imediate.

Înainte de a trece la testarea legăturilor de rezervă și a vitezei, haideți să facem încă un lucru util.
Dacă am avea ocazia să captăm trafic pe interfața FE0/0.2 msk-arbat-gw1, care se confruntă cu serverele, atunci am vedea că mesajele Hello zboară în necunoscut la fiecare 10 secunde. Nu există nimeni cu care să răspundă Bună ziua, nu există cu cine să stabilească relații de vecinătate, așa că nu are rost să încerci să trimiți mesaje de aici.
Dezactivarea este foarte simplă:
msk-arbat-gw1(config)#router OSPF 1
msk-arbat-gw1(config-router)#interfață-pasivă fastEthernet 0/0.2

Această comandă trebuie dată pentru toate interfețele care cu siguranță nu au vecini OSPF (inclusiv cele către Internet).
Drept urmare, veți avea o imagine ca aceasta:

*Nu-mi pot imagina cum nu te-ai încurcat încă*

În plus, această comandă crește securitatea - nimeni din această rețea nu se va preface a fi un router și nu va încerca să ne spargă complet.

Acum să trecem la partea cea mai interesantă - testarea.
Nu este nimic complicat în configurarea OSPF pe toate routerele din Siberian Ring - o puteți face singur.
Și după aceea, imaginea ar trebui să fie după cum urmează:
msk-arbat-gw1#sh ip OSPF vecin

172.16.255.32 1 FULL/DR 00:00:31 172.16.2.2 FastEthernet0/1.4
172.16.255.48 1 FULL/DR 00:00:31 172.16.2.18 FastEthernet0/1.5
172.16.255.80 1 FULL/BDR 00:00:36 172.16.2.130 FastEthernet0/1.8
172.16.255.112 1 FULL/BDR 00:00:37 172.16.2.197 FastEthernet1/0.911

Sankt Petersburg, Kemerovo, Krasnoyarsk și Vladivostok sunt conectate direct.

msk-arbat-gw1#show ip route

172.16.0.0/16 este subrețea variabil, 25 de subrețele, 6 măști



S 172.16.2.4/30 prin 172.16.2.2



O 172.16.2.160/30 prin 172.16.2.130, 00:05:53, FastEthernet0/1.8
O 172.16.2.192/30 prin 172.16.2.197, 00:04:18, FastEthernet1/0.911





S 172.16.16.0/21 prin 172.16.2.2
S 172.16.24.0/22 ​​prin 172.16.2.18
O 172.16.24.0/24 prin 172.16.2.18, 00:24:03, FastEthernet0/1.5
O 172.16.128.0/24 prin 172.16.2.130, 00:07:18, FastEthernet0/1.8
O 172.16.129.0/26 prin 172.16.2.130, 00:07:18, FastEthernet0/1.8

O 172.16.255.32/32 prin 172.16.2.2, 00:24:03, FastEthernet0/1.4
O 172.16.255.48/32 prin 172.16.2.18, 00:24:03, FastEthernet0/1.5
O 172.16.255.80/32 prin 172.16.2.130, 00:07:18, FastEthernet0/1.8
O 172.16.255.96/32 prin 172.16.2.130, 00:04:18, FastEthernet0/1.8
prin 172.16.2.197, 00:04:18, FastEthernet1/0.911
O 172.16.255.112/32 prin 172.16.2.197, 00:04:28, FastEthernet1/0.911

Toată lumea știe totul despre toată lumea.
Ce rută este transportat de la Moscova la Krasnoyarsk? Tabelul arată că krs-stolbi-gw1 este conectat direct și același lucru poate fi văzut din urmă:

msk-arbat-gw1#traceroute 172.16.128.1

1 172.16.2.130 35 msec 8 msec 5 ms

Acum distrugem interfața dintre Moscova și Krasnoyarsk și vedem cât timp durează restabilirea conexiunii.
Nu trec nici măcar 5 secunde până când toți ruterele au aflat despre incident și și-au recalculat tabelele de rutare:
msk-arbat-gw1(config-subif)#do sh ip ro 172.16.128.0

Cunoscut prin „OSPF 1”, distanta 110, metrica 4, tip intra zona
Ultima actualizare de la 172.16.2.197 pe FastEthernet1/0.911, acum 00:00:53
Blocuri descriptori de rutare:
* 172.16.2.197, de la 172.16.255.80, 00:00:53 în urmă, prin FastEthernet1/0.911
Valoarea rutei este 4, numărul de cotă de trafic este 1

Vld-gw1#sh ip ruta 172.16.128.0
Intrare de rutare pentru 172.16.128.0/24
Cunoscut prin „OSPF 1”, distanta 110, metrica 3, tip intra zona
Ultima actualizare de la 172.16.2.193 pe FastEthernet1/0, acum 00:01:57
Blocuri descriptori de rutare:
* 172.16.2.193, de la 172.16.255.80, 00:01:57 în urmă, prin FastEthernet1/0
Valoarea rutei este 3, numărul de cotă de trafic este 1

Msk-arbat-gw1#traceroute 172.16.128.1
Tastați secvența de evacuare la avort.
Urmărirea traseului la 172.16.128.1

1 172.16.2.197 4 msec 10 msec 10 msec
2 172.16.2.193 8 msec 11 msec 15 ms
3 172.16.2.161 15 msec 13 msec 6 ms

Adică, acum traficul ajunge la Krasnoyarsk în acest fel:

De îndată ce ridicați legătura, routerele comunică din nou, își schimbă bazele de date, recalculează cele mai scurte căi și le introduc în tabelul de rutare.
Videoclipul face totul mai clar. Vă recomand familiariza.

După configurarea OSPF pe routerele din inelul siberian, toate rețelele care se află în spatele routerului în biroul central din Moscova (msk-arbat-gw1) sunt accesibile către Khabarovsk prin două rute (prin Krasnoyarsk și prin Vladivostok). Dar, deoarece canalul prin Krasnoyarsk este mai bun, trebuie să modificați setările implicite, astfel încât Khabarovsk să folosească canalul prin Krasnoyarsk atunci când este disponibil. Și a trecut la Vladivostok numai dacă s-a întâmplat ceva cu canalul către Krasnoyarsk.

Ca orice protocol bun, OSPF acceptă autentificare - doi vecini pot verifica autenticitatea mesajelor OSPF primite înainte de a stabili relații de adiacență. Vă lăsăm să studiați pe cont propriu - este destul de simplu.

EIGRP

Acum să trecem la un alt protocol foarte important.

Deci, ce este bun la EIGRP?
- usor de configurat
- comutare rapidă pe calculate dinainte traseu alternativ
- necesită mai puține resurse de router (comparativ cu OSPF)
- rezumarea rutelor pe orice router (în OSPF doar pe ABR\ASBR)
- echilibrarea traficului pe rute inegale (OSPF doar pe rute egale)

Am decis să traducem una dintre intrările de blog ale lui Ivan Pepelnyak, care abordează o serie de mituri populare despre EIGRP:
- „EIGRP este un protocol de rutare hibrid.” Dacă îmi amintesc bine, acest lucru a început cu prima prezentare a EIGRP cu mulți ani în urmă și este de obicei înțeles ca „EIGRP a luat cele mai bune dintre protocoalele de stare de legătură și de vector de distanță”. Acest lucru nu este absolut adevărat. EIGRP nu are caracteristici distinctive ale stării legăturii. Ar fi corect să spunem „EIGRP este un protocol avansat de rutare cu vector de distanță”.
- „EIGRP este un protocol de vector de distanță.” Nu e rău, dar nici în întregime adevărat. EIGRP diferă de alte DV-uri prin modul în care gestionează rutele orfane (sau rutele cu valori crescătoare). Toate celelalte protocoale așteaptă pasiv actualizările de la un vecin (unele, cum ar fi RIP, chiar blochează ruta pentru a preveni buclele de rutare), în timp ce EIGRP este mai activ și solicită informații în sine.
- „EIGRP este dificil de implementat și întreținut.” Neadevarat. La un moment dat, EIGRP în rețelele mari cu legături de viteză redusă era dificil de implementat corect, dar numai până când au fost introduse routerele stub. Cu ele (precum și câteva corecții ale algoritmului DUAL), este aproape mai rău decât OSPF.
- „La fel ca protocoalele LS, EIGRP menține un tabel cu topologia rutelor care sunt schimbate.” Este uimitor cât de greșit este asta. EIGRP habar nu are deloc ce se află dincolo de vecinii săi imediati, în timp ce protocoalele LS cunosc exact topologia întregii zone la care sunt conectate.
- „EIGRP este un protocol DV care acționează ca LS.” Bună încercare, dar totuși complet greșită. Protocoalele LS construiesc o tabelă de rutare prin trecere pasii urmatori:
- fiecare router descrie rețeaua pe baza informațiilor disponibile pe plan local (legăturile sale, subrețelele în care se află, vecinii pe care îi vede) printr-un pachet (sau mai multe) numit LSA (în OSPF) sau LSP (IS-IS)
- LSA-urile sunt propagate în întreaga rețea. Fiecare router trebuie să primească fiecare LSA creat în rețeaua sa. Informațiile primite de la LSA sunt introduse în tabelul de topologie.
- Fiecare router își analizează în mod independent tabelul de topologie și rulează algoritmul SPF pentru a calcula cele mai bune rute către fiecare dintre celelalte routere
Comportamentul EIGRP nici măcar nu se apropie de acești pași, așa că de ce naiba „acţionează ca LS” nu este clar.

Singurul lucru pe care EIGRP îl face este să stocheze informațiile primite de la un vecin (RIP uită imediat ce nu poate fi folosit în acest moment). În acest sens, este similar cu BGP, care stochează tot într-un tabel BGP și alege de acolo cea mai bună rută. Tabelul de topologie (conținând toate informațiile primite de la vecini) oferă EIGRP un avantaj față de RIP - poate conține informații despre o rută de rezervă (neutilizată în prezent).

Acum puțin mai aproape de teoria muncii:

Fiecare proces EIGRP menține 3 tabele:
- Un tabel de vecini, care conține informații despre „vecini”, adică alte routere conectate direct la cel actual și care participă la schimbul de rute. Îl puteți vizualiza folosind comanda arata vecinii ip eigrp
- Tabel de topologie de rețea, care conține informații de rutare primite de la vecini. Să privim ca o echipă arată topologia ip eigrp
- Tabelul de rutare, pe baza căruia routerul ia decizii cu privire la redirecționarea pachetelor. Vizualizare prin arata ruta ip

Metrici.
Pentru a evalua calitatea unei anumite rute, protocoalele de rutare folosesc un anumit număr care reflectă diferitele sale caracteristici sau un set de caracteristici - o metrică. Caracteristicile luate în considerare pot fi diferite - de la numărul de routere de pe o rută dată până la media aritmetică a sarcinii pe toate interfețele de-a lungul rutei. În ceea ce privește metrica EIGRP, pentru a-l cita pe Jeremy Cioara: „Am avut impresia că creatorii EIGRP, aruncând o privire critică asupra creației lor, au decis că totul a fost prea simplu și a funcționat bine. Și apoi au venit cu o formulă metrică, astfel încât toată lumea să spună „WOW, asta este cu adevărat complicat și arată profesional”. Consultați formula completă pentru calcularea metricii EIGRP: (K1 * bw + (K2 * bw) / (256 - sarcină) + K3 * întârziere) * (K5 / (fiabilitate + K4)), în care:
- bw nu este doar lățime de bandă, ci (10000000/cea mai mică lățime de bandă de-a lungul traseului în kilobiți) * 256
- întârzierea nu este doar o întârziere, ci suma tuturor întârzierilor pe drum spre zeci de microsecunde* 256 (întârzierea în comenzile arată interfața, show ip eigrp topology și altele este afișată în microsecunde!)
- K1-K5 sunt coeficienți care servesc pentru a se asigura că unul sau altul parametru este „inclus” în formulă.

Infricosator? ar fi dacă totul ar funcționa așa cum este scris. De fapt, din toți cei 4 termeni posibili ai formulei, doar doi sunt utilizați implicit: bw și întârziere (coeficienții K1 și K3 = 1, restul sunt zero), ceea ce o simplifică foarte mult - pur și simplu adunăm aceste două numere (în timp ce nu uitând că sunt încă calculate după formule proprii). Este important să rețineți următoarele: metrica se calculează în funcție de cel mai prost indicator lățime de bandă pe toată lungimea traseului.
Dacă K5=0, atunci se utilizează următoarea formulă: Metric = (K1 * bw + (K2 * bw) / (256 - sarcină) + (K3 * întârziere)

Un lucru interesant s-a întâmplat cu MTU: destul de des puteți găsi informații că MTU are legătură cu metrica EIGRP. Într-adevăr, valorile MTU sunt transmise la schimbul de rute. Dar, după cum putem vedea din formula completă, nu se menționează MTU. Cert este că acest indicator este luat în considerare în cazuri destul de specifice: de exemplu, dacă un router trebuie să renunțe la una dintre rutele care sunt echivalente în alte caracteristici, o va alege pe cea cu un MTU mai mic. Deși, nu totul este atât de simplu (vezi comentarii).

Să definim termenii folosiți în EIGRP. Fiecare rută din EIGRP este caracterizată de două numere: Distanța fezabilă și Distanța Anunțată (în loc de Distanța Anunțată, uneori puteți vedea Distanța raportată, acesta este același lucru). Fiecare dintre aceste numere reprezintă o metrică sau un cost (cu atât mai mult, cu atât mai rău) al unei anumite rute din diferite puncte de măsurare: FD este „de la mine la destinație”, iar AD este „de la vecinul care mi-a spus despre această rută până la numirile de la loc”. Răspunsul la întrebarea logică „De ce trebuie să știm costul de la un vecin dacă acesta este deja inclus în FD” este puțin mai mic (deocamdată poți să te oprești și să-ți faci creierul singur, dacă vrei).

Pentru fiecare subrețea de care cunoaște EIGRP, pe fiecare router există un router Succesor din rândul vecinilor, prin care trece cea mai bună (cu o metrică mai mică), conform protocolului, ruta către această subrețea. În plus, o subrețea poate avea și una sau mai multe rute de rezervă (routerul vecin prin care trece o astfel de rută se numește succesor fezabil). EIGRP este singurul protocol de rutare care își amintește rutele de rezervă (OSPF le are, dar sunt conținute, ca să spunem așa, în „forma brută” în tabelul de topologie; ele trebuie încă procesate de algoritmul SPF), ceea ce îi conferă un avantaj de performanță: de îndată ce protocolul stabilește că ruta principală (prin succesor) este indisponibilă, trece imediat la ruta de rezervă. Pentru ca un router să devină un succesor fezabil pentru o rută, AD sa trebuie să fie mai mic decât succesorul FD al acestei rute (de aceea trebuie să cunoaștem AD). Această regulă este folosită pentru a evita buclele de rutare.

Te-a suflat paragraful anterior? Materialul este dificil, așa că voi folosi din nou un exemplu. Avem aceasta retea:

Din punctul de vedere al lui R1, R2 este Succesorul pentru subrețeaua 192.168.2.0/24. Pentru a deveni un FS pentru această subrețea, R4 necesită ca AD să fie mai mic decât FD pentru această rută. Avem FD ((10000000/1544)*256)+(2100*256) =2195456, R4 are AD (din punctul lui de vedere este FD, adică cât îl costă să ajungă în această rețea) = (( 10000000/100000 )*256)+(100*256)=51200. Totul converge, AD-ul R4 este mai mic decât FD-ul rutei, devine FS. *apoi creierul spune: „BDASH”*. Acum ne uităm la R3 - el își anunță rețeaua 192.168.1.0/24 vecinului său R1, care, la rândul său, le spune vecinilor săi R2 și R4 despre asta. R4 nu știe că R2 știe despre această subrețea și decide să-i spună. R2 transmite informația că are acces prin R4 către subrețeaua 192.168.1.0/24 în continuare către R1. R1 se uită cu strictețe la FD-ul rutei și AD, cu care se laudă R2 (care, după cum este ușor de înțeles din diagramă, va fi în mod clar mai mare decât FD, deoarece îl include și pe el) și îl alungă pentru a nu interferează cu tot felul de prostii. Această situație este destul de puțin probabilă, dar poate apărea în anumite circumstanțe, de exemplu, atunci când mecanismul cu orizontul împărțit este dezactivat. Și acum la o situație mai probabilă: imaginați-vă că R4 este conectat la rețeaua 192.168.2.0/24 nu prin FastEthernet, ci printr-un modem de 56k (întârzierea pentru dialup este de 20.000 usec), în consecință, îl costă ((10000000/56) )*256 )+(2000*256)= 46226176. Acesta este mai mult decât FD pentru această rută, deci R4 nu va deveni un succesor fezabil. Dar asta nu înseamnă că EIGRP nu va folosi deloc această rută. Va dura mai mult pentru a trece la el (mai multe despre asta mai târziu).

Cartier

Routerele nu vorbesc despre rute oricui - trebuie să stabilească relații de adiacență înainte de a putea începe să schimbe informații. După pornirea procesului cu comanda router eigrp, indicând numărul sistemului autonom, noi, cu comanda de rețea, spunem ce interfețe vor participa și, în același timp, informații despre ce rețele dorim să distribuim. Imediat, pachetele hello încep să fie trimise prin aceste interfețe la adresa multicast 224.0.0.10 (în mod implicit la fiecare 5 secunde pentru ethernet). Toate routerele cu EIGRP activat primesc aceste pachete, apoi fiecare router care primește face următoarele:
- verifică adresa expeditorului pachetului hello cu adresa interfeței de la care a fost primit pachetul și se asigură că sunt din aceeași subrețea
- compară valorile coeficienților K obținuți din pachet (cu alte cuvinte, care variabile sunt utilizate în calcularea metricii) cu propriile sale. Este clar că dacă acestea diferă, atunci metricile pentru trasee vor fi calculate în funcție de reguli diferite ceea ce este inacceptabil
- verifică numărul sistemului autonom
- opțional: dacă autentificarea este configurată, verifică consistența tipului și a cheilor acestuia.

Dacă destinatarul este mulțumit de toate, îl adaugă pe expeditor pe lista vecinilor săi și îi trimite (deja în Unicast) un pachet de actualizare, care conține o listă cu toate rutele cunoscute de el (aka full-update). Expeditorul, după ce a primit un astfel de pachet, face la rândul său același lucru. Pentru schimbul de rute, EIGRP folosește Reliable Transport Protocol (RTP, care nu trebuie confundat cu Real-time Transport Protocol, care este utilizat în telefonia IP), care implică confirmarea livrării, astfel încât fiecare dintre routere, după ce a primit un pachet de actualizare, răspunde cu un pachet de confirmare (abreviere de la confirmare - confirmare). Deci, relația de vecinătate a fost stabilită, routerele au învățat unul de la celălalt informații complete despre rute, ce urmează? Apoi, ei vor continua să trimită pachete de salut multicast pentru a confirma că sunt conectate și, dacă topologia se modifică, vor actualiza pachetele care conțin doar informații despre modificări (actualizare parțială).

Acum să revenim la schema anterioară cu modemul.

R2 din anumite motive a pierdut contactul cu 192.168.2.0/24. Nu are rute de rezervă către această subrețea (adică, fără FS). La fel ca orice router responsabil EIGRP, vrea să restabilească conectivitatea. Pentru a face acest lucru, el începe să trimită mesaje speciale (pachete de interogare) tuturor vecinilor săi, care, la rândul lor, negăsind ruta dorită în ei înșiși, întreabă toți vecinii lor și așa mai departe. Când valul de solicitări ajunge la R4, el spune „stai puțin, am o rută către această subrețea! Rău, dar măcar ceva. Toți au uitat de el, dar îmi amintesc.” El împachetează toate acestea într-un pachet de răspuns și îl trimite vecinului de la care a primit cererea (interogare) și mai departe de-a lungul lanțului. Desigur, toate acestea necesită mai mult timp decât trecerea la Feasible Successor, dar în cele din urmă obținem comunicare cu subrețeaua.

Și acum este un moment periculos: poate ați observat deja și ați devenit precaut după ce ați citit despre acest e-mailing de la fani. Eșecul unei interfețe provoacă ceva similar cu o furtună de difuzare în rețea (nu la o asemenea scară, desigur, dar totuși), și cu cât sunt mai multe routere, cu atât mai multe resurse vor fi cheltuite pentru toate aceste solicitări și răspunsuri. Dar asta nu e chiar atât de rău. O situație mai gravă este posibilă: imaginați-vă că routerele prezentate în imagine sunt doar o parte dintr-un mare și retea distribuita, adică unele pot fi situate la multe mii de kilometri de R2, pe canale proasteȘi așa mai departe. Deci, problema este că, după ce a trimis o interogare unui vecin, routerul trebuie să aștepte un răspuns de la acesta. Nu contează care este răspunsul, dar trebuie să vină. Chiar dacă routerul deja a primit un răspuns pozitiv, ca și în cazul nostru, nu poate pune în funcțiune această rută până nu așteaptă un răspuns la toate solicitările sale. Și poate că mai sunt cereri undeva în Alaska. Această stare de rută se numește blocat-în-activ. Aici trebuie să ne familiarizăm cu termenii care reflectă starea rutei în EIGRP: rută activ\pasivă. De obicei sunt înșelătoare. Bunul simț dictează că activ înseamnă că traseul este „activ”, activat, rulant. Totuși, aici totul este invers: pasiv înseamnă „totul este în regulă”, iar starea activă înseamnă că această subrețea este indisponibilă și routerul este în căutare activă altă rută, trimițând o interogare și așteptând un răspuns. Deci, starea blocată în activ poate dura până la 3 minute! După expirarea acestei perioade, routerul întrerupe relația de vecin cu vecinul de la care nu poate aștepta un răspuns și poate folosi o nouă rută prin R4.

O poveste care îngheață sângele unui inginer de rețea. 3 minute de pauză nu este o glumă. Cum putem evita atacul de cord din această situație? Există două căi de ieșire: însumarea rutelor și așa-numita configurație stub.

În general, există o altă cale de ieșire și se numește filtrarea rutei. Dar acesta este un subiect atât de voluminos încât ar fi mai bine să scriem un articol separat despre el, dar avem deja o jumătate de carte de data aceasta. Deci depinde de tine.

După cum am menționat deja, în EIGRP rezumarea rutei poate fi efectuată pe orice router. Pentru a exemplifica, să ne imaginăm că subrețelele de la 192.168.0.0/24 la 192.168.7.0/24 sunt conectate la îndelungul nostru R2, care însumează foarte convenabil până la 192.168.0.0/21 (amintiți-vă matematica binară). Routerul face publicitate acestei rute rezumative și toți ceilalți știu: dacă adresa de destinație începe cu 192.168.0-7, atunci este pentru el. Ce se întâmplă dacă una dintre subrețele dispare? Routerul va trimite pachete de interogare cu adresa acestei rețele (specifică, de exemplu, 192.168.5.0/24), dar vecinii, în loc să continue trimiterea vicioasă în numele lor, vor răspunde imediat cu reluări serioase, spunând că aceasta este subrețeaua dvs., vă dați seama.

A doua opțiune este configurația stub. Figurat vorbind, stub înseamnă „sfârșitul drumului”, „fundătură” în EIGRP, adică a intra într-o subrețea care nu este conectată. direct la un astfel de router, va trebui să te întorci. Un router configurat ca stub nu va redirecționa traficul între subrețelele pe care le cunoaște din EIGRP (cu alte cuvinte, care sunt marcate cu litera D în show ip route). În plus, vecinii săi nu îi vor trimite pachete de interogare. Cea mai comună aplicație sunt topologiile hub-and-spoke, în special cu legături redundante. Să luăm această rețea: în stânga sunt ramuri, în dreapta este site-ul principal, Biroul principalși așa mai departe. Pentru toleranță la erori, legături redundante. EIGRP rulează cu setările implicite.

Și acum „atenție, întrebare”: ce se va întâmpla dacă R1 pierde conexiunea cu R4, iar R5 pierde LAN? Traficul de la subrețeaua R1 către subrețeaua biroului principal va urma traseul R1->R5->R2 (sau R3)->R4. Va fi eficient? Nu. Nu doar subrețeaua din spatele R1 va avea de suferit, ci și subrețeaua din spatele R2 (sau R3), din cauza creșterii volumelor de trafic și a consecințelor acesteia. Pentru astfel de situații a fost inventat stub. În spatele routerelor din ramuri nu există alte routere care să conducă la alte subrețele, acesta este „sfârșitul drumului”, apoi doar înapoi. Prin urmare, cu o inimă ușoară, le putem configura ca stub-uri, ceea ce, în primul rând, ne va salva de problema cu „ruta strâmbă” conturată chiar mai sus și, în al doilea rând, de inundația de pachete de interogare în cazul pierderii rutei. .

Există diferite moduri de funcționare a unui router stub, acestea sunt setate cu comanda eigrp stub:

R1(config)#router eigrp 1
R1(config-router)#eigrp stub?
conectat Faceți publicitate rutelor conectate
leak-map Permite prefixe dinamice bazate pe leak-map
numai recepție Setați IP-EIGRP ca vecin numai recepție
redistribuit Faceți publicitate rutelor redistribuite
static Faceți publicitate rutelor statice
rezumat Faceți publicitate rute rezumate

În mod implicit, dacă lansați pur și simplu comanda eigrp stub, modurile conectat și rezumat sunt activate. Interesant este modul de recepție, în care routerul nu face reclamă la nicio rețea, ci doar ascultă ceea ce îi spun vecinii (în RIP există o comandă de interfață pasivă care face același lucru, dar în EIGRP dezactivează complet protocolul pe interfața selectată, care nu permite stabilirea unei vecinătăți).

Puncte importante din teoria EIGRP care nu au fost incluse în articol:

• Autentificarea vecinului poate fi configurată în EIGRP
• Concept de oprire grațioasă

Practica EIGRP

Lift mi Up a cumpărat o fabrică în Kaliningrad. Acolo se produc creierul lifturilor: microcircuite, software. Fabrica este foarte mare - trei puncte în jurul orașului - trei routere conectate într-un inel.

Dar ghinion - au deja EIGRP care rulează ca protocol de rutare dinamică. Mai mult, adresarea nodurilor terminale este dintr-o subrețea complet diferită - 10.0.0.0/8. Am schimbat toți ceilalți parametri (adrese de link, adrese de interfață loopback), dar câteva mii de adrese de rețea locală cu servere, imprimante, puncte de acces - nu o lucrare pentru câteva ore - au fost amânate pentru mai târziu, iar în planul IP am rezervat 172.16 subrețea pentru viitor pentru Kaliningrad .32.0/20.

În prezent folosim următoarele rețele:

Cum este configurat acest miracol? Necomplicat la prima vedere:
router eigrp 1
reţea 172.16.0.0 0.0.255.255
rețeaua 10.0.0.0

În EIGRP, masca inversă poate fi specificată, indicând astfel un domeniu mai restrâns sau nespecificat, apoi va fi selectată masca standard pentru această clasă (16 pentru clasa B - 172.16.0.0 și 8 pentru clasa A - 10.0.0.0)

Astfel de comenzi sunt date pe toate routerele Sistem autonom. AC este determinat de numărul din comanda router eigrp, adică în cazul nostru avem AC Nr. 1. Această cifră ar trebui să fie aceeași pe toate routerele (spre deosebire de OSPF).

Dar există o captură serioasă în EIGRP: în mod implicit, rezumarea automată a rutelor în formă de clasă este activată (în versiunile IOS până la 15).
Să comparăm tabelele de rutare pe trei routere Kaliningrad:

Rețeaua 10.0.0.1/24 este conectată la klgr-center-gw1 și el știe despre asta:
klgr-center-gw1:
10.0.0.0/8 este subrețele variabil, 2 subrețele, 2 măști
D 10.0.0.0/8 este un rezumat, 00:35:23, Null0
C 10.0.0.0/24 este conectat direct, FastEthernet1/0

Dar nu știe despre 10.0.1.0/24 și 10.0.2.0/24/

Klgr-balt-gw1 știe despre cele două rețele ale sale 10.0.1.0/24 și 10.0.2.0/24, dar a ascuns rețeaua 10.0.0.0/24 undeva.
10.0.0.0/8 este subrețele variabil, 3 subrețele, 2 măști
D 10.0.0.0/8 este un rezumat, 00:42:05, Null0
C 10.0.1.0/24 este conectat direct, FastEthernet1/1.2
C 10.0.2.0/24 este conectat direct, FastEthernet1/1.3

Amândoi au creat ruta 10.0.0.0/8 cu următoarea adresă de hop Null0.

Dar klgr-center-gw2 știe că subrețelele 10.0.0.0/8 se află în spatele ambelor interfețe WAN.
D 10.0.0.0/8 prin 172.16.2.41, 00:42:49, FastEthernet0/1
prin 172.16.2.45, 00:38:05, FastEthernet0/0

Se întâmplă ceva foarte ciudat.
Dar, dacă verificați configurația acestui router, probabil veți observa:
router eigrp 1
rețeaua 172.16.0.0
rețeaua 10.0.0.0
auto-rezumat

Însumarea automată este de vină pentru tot. Acesta este cel mai mare rău al EIGRP. Să aruncăm o privire mai atentă la ceea ce se întâmplă. klgr-center-gw1 și klgr-balt-gw1 au subrețele din 10.0.0.0/8, le însumează implicit atunci când le transmit vecinilor.
Adică, de exemplu, klgr-balt-gw1 transmite nu două rețele 10.0.1.0/24 și 10.0.2.0/24, ci una generalizată: 10.0.0.0/8. Adică vecinul său va crede că în spatele klgr-balt-gw1 se află toată această rețea.
Dar ce se întâmplă dacă brusc balt-gw1 primește un pachet cu destinația 10.0.50.243, despre care nu știe nimic? Pentru acest caz, este creată așa-numita rută Blackhole:
10.0.0.0/8 este un rezumat, 00:42:05, Null0
Pachetul rezultat va fi aruncat în această gaură neagră. Acest lucru se face pentru a evita buclele de rutare.
Așadar, ambele routere și-au creat propriile rute negre și au ignorat anunțurile altora. În realitate, pe o astfel de rețea, aceste trei dispozitive nu vor putea să-și pună ping unul pe celălalt până când... până când nu dezactivați rezumatul automat.

Primul lucru pe care ar trebui să-l faceți când configurați EIGRP este:
router eigrp 1
fara auto-rezumat

Pe toate dispozitivele. Și toată lumea va fi bine:

Klgr-center-gw1:
C 10.0.0.0 este conectat direct, FastEthernet1/0
D 10.0.1.0 prin 172.16.2.37, 00:03:11, FastEthernet0/0
D 10.0.2.0 prin 172.16.2.37, 00:03:11, FastEthernet0/0

klgr-balt-gw1
10.0.0.0/24 este subrețele, 3 subrețele
D 10.0.0.0 prin 172.16.2.38, 00:08:16, FastEthernet0/1
C 10.0.1.0 este conectat direct, FastEthernet1/1.2
C 10.0.2.0 este conectat direct, FastEthernet1/1.3

klgr-center-gw2:
10.0.0.0/24 este subrețele, 3 subrețele
D 10.0.0.0 prin 172.16.2.45, 00:11:50, FastEthernet0/0
D 10.0.1.0 prin 172.16.2.41, 00:11:48, FastEthernet0/1
D 10.0.2.0 prin 172.16.2.41, 00:11:48, FastEthernet0/1

Configurarea transferului rutei între diferite protocoale

Sarcina noastră este să organizăm transferul de rute între aceste protocoale: de la OSPF la EIGRP și invers, astfel încât toată lumea să cunoască ruta către orice subrețea.
Aceasta se numește redistribuire a rutei.

Pentru a-l implementa, avem nevoie de cel puțin un punct de joncțiune unde două protocoale vor fi lansate simultan. Acesta ar putea fi msk-arbat-gw1 sau klgr-balt-gw1. Să-l alegem pe al doilea.

De la la EIGRP d OSPF:
klgr-gw1(config)#router ospf 1
klgr-gw1(config-router)#redistribuiți subrețele eigrp 1

Ne uităm la rutele pe msk-arbat-gw1:

msk-arbat-gw1#sh traseu ip
Coduri: C - conectat, S - static, I - IGRP, R - RIP, M - mobil, B - BGP
D - EIGRP, EX - EIGRP extern, O - OSPF, IA - OSPF inter zona
N1 - OSPF NSSA extern tip 1, N2 - OSPF NSSA extern tip 2
E1 - OSPF extern tip 1, E2 - OSPF extern tip 2, E - EGP
i - IS-IS, L1 - IS-IS nivelul 1, L2 - IS-IS nivelul 2, ia - IS-IS interzona
* - implicit candidat, U - rută statică per utilizator, o - ODR
P - rută statică descărcată periodic

Gateway-ul de ultimă instanță este 198.51.100.1 către rețeaua 0.0.0.0

10.0.0.0/8 este subrețele variabil, 3 subrețele, 2 măști
O E2 10.0.0.0/8 prin 172.16.2.34, 00:25:11, FastEthernet0/1.7
O E2 10.0.1.0/24 prin 172.16.2.34, 00:25:11, FastEthernet0/1.7
O E2 10.0.2.0/24 prin 172.16.2.34, 00:24:50, FastEthernet0/1.7
172.16.0.0/16 este subrețea variabil, 30 de subrețele, 5 măști
O E2 172.16.0.0/16 prin 172.16.2.34, 00:25:11, FastEthernet0/1.7
C 172.16.0.0/24 este conectat direct, FastEthernet0/0.3
C 172.16.1.0/24 este conectat direct, FastEthernet0/0.2
C 172.16.2.0/30 este conectat direct, FastEthernet0/1.4
C 172.16.2.16/30 este conectat direct, FastEthernet0/1.5
C 172.16.2.32/30 este conectat direct, FastEthernet0/1.7
O E2 172.16.2.36/30 prin 172.16.2.34, 01:00:55, FastEthernet0/1.7
O E2 172.16.2.40/30 prin 172.16.2.34, 01:00:55, FastEthernet0/1.7
O E2 172.16.2.44/30 prin 172.16.2.34, 01:00:55, FastEthernet0/1.7
C 172.16.2.128/30 este conectat direct, FastEthernet0/1.8
O 172.16.2.160/30 prin 172.16.2.130, 01:00:55, FastEthernet0/1.8
O 172.16.2.192/30 prin 172.16.2.197, 00:13:21, FastEthernet1/0.911
C 172.16.2.196/30 este conectat direct, FastEthernet1/0.911
C 172.16.3.0/24 este conectat direct, FastEthernet0/0.101
C 172.16.4.0/24 este conectat direct, FastEthernet0/0.102
C 172.16.5.0/24 este conectat direct, FastEthernet0/0.103
C 172.16.6.0/24 este conectat direct, FastEthernet0/0.104
O 172.16.24.0/24 prin 172.16.2.18, 01:00:55, FastEthernet0/1.5
O 172.16.128.0/24 prin 172.16.2.130, 01:00:55, FastEthernet0/1.8
O 172.16.129.0/26 prin 172.16.2.130, 01:00:55, FastEthernet0/1.8
O 172.16.144.0/24 prin 172.16.2.130, 00:13:21, FastEthernet0/1.8

O 172.16.160.0/24 prin 172.16.2.197, 00:13:31, FastEthernet1/0.911
C 172.16.255.1/32 este conectat direct, Loopback0
O 172.16.255.48/32 prin 172.16.2.18, 01:00:55, FastEthernet0/1.5
O E2 172.16.255.64/32 prin 172.16.2.34, 01:00:55, FastEthernet0/1.7
O E2 172.16.255.65/32 prin 172.16.2.34, 01:00:55, FastEthernet0/1.7
O E2 172.16.255.66/32 prin 172.16.2.34, 01:00:55, FastEthernet0/1.7
O 172.16.255.80/32 prin 172.16.2.130, 01:00:55, FastEthernet0/1.8
O 172.16.255.96/32 prin 172.16.2.130, 00:13:21, FastEthernet0/1.8
prin 172.16.2.197, 00:13:21, FastEthernet1/0.911
O 172.16.255.112/32 prin 172.16.2.197, 00:13:31, FastEthernet1/0.911
198.51.100.0/28 este subrețea, 1 subrețea
C 198.51.100.0 este conectat direct, FastEthernet0/1.6
S* 0.0.0.0/0 prin 198.51.100.1

Iată-le pe cele cu eticheta E2 - rute noi importate. E2 - înseamnă că acestea sunt rute externe de al 2-lea tip (Extern), adică au fost introduse în procesul OSPF din exterior

Acum de la OSPF la EIGRP. Acesta este un pic mai complicat:
klgr-gw1(config)#router eigrp 1
klgr-gw1(config-router)#redistribuire ospf 1 metric 100000 20 255 1 1500

Fără a specifica metrica (acest set lung de numere), comanda va fi executată, dar redistribuirea nu va avea loc.

Rutele importate primesc o etichetă EX în tabelul de rutare și o distanță administrativă de 170, în loc de 90 pentru cele interne:

klgr-gw2#sh traseu ip

Poarta de ultimă instanță nu este setată

172.16.0.0/16 este subrețea variabil, 30 de subrețele, 4 măști
D EX 172.16.0.0/24 [170 /33280] prin 172.16.2.37, 00:00:07, FastEthernet0/0
D EX 172.16.1.0/24 prin 172.16.2.37, 00:00:07, FastEthernet0/0
D EX 172.16.2.0/30 prin 172.16.2.37, 00:00:07, FastEthernet0/0
D EX 172.16.2.4/30 prin 172.16.2.37, 00:00:07, FastEthernet0/0
D EX 172.16.2.16/30 prin 172.16.2.37, 00:00:07, FastEthernet0/0
D 172.16.2.32/30 [ 90 /30720] prin 172.16.2.37, 00:38:59, FastEthernet0/0
C 172.16.2.36/30 este conectat direct, FastEthernet0/0
D 172.16.2.40/30 prin 172.16.2.37, 00:38:59, FastEthernet0/0
prin 172.16.2.46, 00:38:59, FastEthernet0/1
….

Așa se face, s-ar părea simplu, dar simplitatea este superficială – redistribuirea este plină de multe momente subtile și neplăcute când se adaugă cel puțin o legătură redundantă între două domenii diferite.
Sfat general - încercați să evitați redistribuirea dacă este posibil. Principala regulă a vieții funcționează aici - cu cât mai simplu, cu atât mai bine.

Ruta implicită

Acum este momentul să vă verificați accesul la internet. Funcționează bine din Moscova, dar dacă verificați, de exemplu, din Sankt Petersburg (rețineți că am șters toate rutele statice):
PC>ping

Ping 192.0.2.2 cu 32 de octeți de date:

Răspuns de la 172.16.2.5: Gazda destinație inaccesibilă.
Răspuns de la 172.16.2.5: Gazda destinație inaccesibilă.
Răspuns de la 172.16.2.5: Gazda destinație inaccesibilă.

Statistici ping pentru 192.0.2.2:
Pachete: trimise = 4, primite = 0, pierdute = 4 (100% pierdere),

Acest lucru se datorează faptului că nici spb-ozerki-gw1, nici spb-vsl-gw1, nici nimeni altcineva din rețeaua noastră nu știe despre ruta implicită, cu excepția msk-arbat-gw1, pe care este configurată static.
Pentru a corecta această situație, trebuie doar să dăm o comandă la Moscova:
msk-arbat-gw1(config)#router ospf 1
msk-arbat-gw1(config-router)#default-information provin

După aceasta, informații despre locul unde se află poarta de ultimă instanță avalanșă în rețea.

Internetul este acum disponibil:
PC>tracert

Urmărirea rutei către 192.0.2.2 pe maximum 30 de hop:

1 3 ms 3 ms 3 ms 172.16.17.1
2 4 ms 5 ms 12 ms 172.16.2.5
3 14 ms 20 ms 9 ms 172.16.2.1
4 17 ms 17 ms 19 ms 198.51.100.1
5 22 ms 23 ms 19 ms 192.0.2.2

Comenzi utile pentru depanare

1) Lista vecinilor si starea comunicarii cu acestia se apeleaza prin comanda arata ip ospf vecin
msk-arbat-gw1:

Neighbor ID Pri State Dead Time Address Interfață
172.16.255.32 1 FULL/DROTHER 00:00:33 172.16.2.2 FastEthernet0/1.4
172.16.255.48 1 FULL/DR 00:00:34 172.16.2.18 FastEthernet0/1.5
172.16.255.64 1 FULL/DR 00:00:33 172.16.2.34 FastEthernet0/1.7
172.16.255.80 1 FULL/DR 00:00:33 172.16.2.130 FastEthernet0/1.8
172.16.255.112 1 FULL/DR 00:00:33 172.16.2.197 FastEthernet1/0.911

2) Sau pentru EIGRP: arata vecinii ip eigrp
IP-EIGRP vecini pentru procesul 1
H Adresă Interfață Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 172.16.2.38 Fa0/1 12 00:04:51 40 1000 0 54
1 172.16.2.42 Fa0/0 13 00:04:51 40 1000 0 58

3) Folosind comanda arata protocoale ip Puteți vizualiza informații despre rularea protocoalelor de rutare dinamică și relațiile acestora.

Klgr-balt-gw1:
Protocolul de rutare este „EIGRP 1”

Rețelele implicite semnalate în actualizările trimise
Rețelele implicite acceptate de la actualizările primite
Greutatea metrică EIGRP K1=1, K2=0, K3=1, K4=0, K5=0
Număr maxim de salturi EIGRP 100
Varianta maximă a metricii EIGRP 1
Redistribuire: EIGRP 1, OSPF 1
Rezumatul automat al rețelei este în vigoare
Rezumare automată a adreselor:
Calea maximă: 4
Rutare pentru rețele:
172.16.0.0

172.16.2.42 90 4
172.16.2.38 90 4
Distanta: interior 90 extern 170

Protocolul de rutare este „OSPF 1”
Lista de filtre de actualizare de ieșire pentru toate interfețele nu este setată
Lista de filtre de actualizare primită pentru toate interfețele nu este setată
ID router 172.16.255.64
Este un router de limită de sistem autonom
Redistribuirea rutelor externe din,
EIGRP 1
Numărul de zone din acest router este 1. 1 normal 0 stub 0 nssa
Calea maximă: 4
Rutare pentru rețele:
172.16.2.32 0.0.0.3 zona 0
Surse de informații despre rutare:
Distanța gateway Ultima actualizare
172.16.255.64 110 00:00:23
Distanță: (implicit este 110)

4) Pentru a depana și înțelege funcționarea protocoalelor, va fi util să folosiți următoarele comenzi:
depanați evenimentele IP OSPF
depanare ip OSPF adj
depanați pachetele EIGRP

Încercați să încercați diferite interfețe și vedeți ce se întâmplă în depanare, ce mesaje zboară.

Autorii

Marat eucariot
Maxim alias gluck

Aș dori să-mi exprim recunoștința lui Dmitry JDima pentru editări și comentarii neprețuite și irezistibilei Natasha Samoilenko pentru sarcinile oferite. Anton Avtushko pentru programarea site-ului blogului. Și fetei cu numele glorios Nina pentru logo-ul site-ului.

P.S.
Viitorul nostru podcast LinkMiAp are nevoie de un jingle și muzică de fundal. Vom fi bucuroși să vă ajutăm, iar numele compozitorului va fi glorificat timp de secole.

P.P.S.
Nu mai avem suficient de capabilitățile lui Packet Tracer. Următorul pas este trecerea la ceva mai serios. Orice sugestii? Propun sa organizez un holivar in comentariile la subiectul IOU vs GNS.

Rutarea poate fi statică sau dinamică. Pentru s Rutare statica sunt necesare tabele de rutare, care sunt create de administratorul de rețea; ele specifică rute fixe (statice) între oricare două routere. Administratorul introduce aceste informații în tabele manual. Administratorul de rețea este, de asemenea, responsabil pentru actualizarea manuală a tabelelor dacă orice dispozitiv de rețea eșuează. Un router care rulează tabele statice poate detecta dacă o legătură de rețea este întreruptă, dar nu poate schimba automat căile pachetelor fără intervenția administratorului.

Dirijare dinamică executat indiferent administrator de retea.

Protocoalele de rutare dinamică permit routerelor să funcționeze automat urmatoarele operatii:

· găsiți alte routere disponibile în alte segmente de rețea;

· utilizați metrice pentru a determina cele mai scurte rute către alte rețele;

· stabiliți când calea de rețea către un anumit router este indisponibilă sau nu poate fi utilizată;

· aplica metrici pentru restructurare cele mai bune rute când o anumită cale de rețea devine indisponibilă;

· regăsiți routerul și calea de rețea după depanare problemă de rețea pe acest drum.

Routere pod

Router bridge (brouter) este un dispozitiv de rețea care în unele cazuri acționează ca o punte, iar în alte cazuri ca un router.

Orez. 3 Router pod

De exemplu, un astfel de dispozitiv poate acționa ca o punte pentru anumite protocoale, cum ar fi NetBEUI (deoarece nu este rutabil) și ca un router pentru alte protocoale, cum ar fi TCP/IP.

Un router bridge poate îndeplini următoarele funcții:

· gestionați eficient pachetele într-o rețea cu multe protocoale, inclusiv protocoale care sunt direcționate și protocoale care nu pot fi rutate;

· reduce încărcarea pe canale prin izolarea și redirecționarea traficului de rețea;

· conectarea rețelelor;

· asigurarea securității anumitor părți ale rețelei prin controlul accesului la acestea.

Routerele bridge sunt utilizate în rețele multi-protocol precum NetBEUI, IPX/SPX și TCP/IP și, prin urmare, sunt numite și routere multi-protocol.

Funcțiile (rutare sau redirecționare) pe care le îndeplinesc în raport cu un protocol depind de două motive:

· din directivele administratorului de rețea specificate pentru acest protocol;

· dacă cadrul de intrare conține informații de rutare (dacă nu conține, atunci pachetele acestui protocol sunt de obicei trimise către toate rețelele).

Dacă un router bridge este configurat să redirecționeze protocolul, mai degrabă decât rutarea, acesta redirecționează fiecare cadru utilizând informațiile despre adresa sub-stratului MAC de la stratul de legătură la fel ca o punte.

Aceasta este o capacitate semnificativă pentru o rețea ale cărei protocoale includ NetBEUI (deoarece acest protocol nu poate fi rutat). Pentru protocoalele rutate, cum ar fi TCP/IP, routerul bridge redirecționează pachetele în funcție de informațiile de adresare și rutare conținute la nivelul rețelei.

Comutatoare

Comutatoare oferă funcții bridge și, de asemenea, vă permit să creșteți debitul rețelelor existente.

Orez. 4 Comutator

Switch-urile utilizate în rețelele locale sunt similare cu podurile prin faptul că funcționează la substratul MAC al stratului de legătură și analizează adresele dispozitivului în toate cadrele primite.

La fel ca podurile, comutatoarele mențin un tabel de adrese și folosesc aceste informații pentru a decide cum să filtreze și să redirecționeze traficul LAN. Spre deosebire de poduri, pentru a crește viteza de transfer de date și lățimea de bandă mediu de rețea Comutatoarele folosesc tehnici de comutare.

Comutatoarele LAN folosesc de obicei una dintre cele două metode:

· Când comutați fără buffering de pachete (comutație cut-through), cadrele sunt trimise în părți până când este primit întregul cadru. Transmisia cadrelor începe imediat ce adresa MAC de destinație este citită și portul de destinație este determinat din tabelul de comutare. Această abordare oferă relativ de mare viteză transmitere (parțial din cauza refuzului de a verifica erorile).

· În comutarea stocare și redirecționare (numită și comutare tamponată), transmiterea unui cadru nu începe până când acesta a fost recepționat complet. Odată ce comutatorul primește un cadru, își verifică suma de control (CRC) înainte de a-l redirecționa către nodul țintă. Cadrul este apoi stocat (bufferizat) până când portul și canalul de comunicație corespunzător sunt libere (pot fi ocupate de alte date).

Ultimele modele Comutatoarele (uneori numite comutatoare de rutare) care utilizează comutarea stocare și redirecționare pot combina funcțiile routerelor și comutatoarelor și, prin urmare, funcționează la nivelul de rețea pentru a determina calea cea mai scurtă către un nod destinație. Unul dintre avantajele unor astfel de comutatoare este că oferă capacități mai mari de segmentare a traficului de rețea, permițându-vă să evitați traficul de difuzare care are loc pe rețelele Ethernet.

Comutarea stocare și redirecționare este mai comună decât comutarea fără tampon, iar unele comutatoare stocare și redirecționare folosesc comutarea încorporată pentru a îmbunătăți performanța. CPU. În principiu, comutatoarele cu propriul procesor sunt mult mai rapide decât comutatoarele „simple”. Cu toate acestea, în unele cazuri, astfel de comutatoare pot fi supraîncărcate cu traficul de intrare, utilizarea procesorului ajungând la 100% și comutatorul rulând de fapt mai lent decât un comutator fără procesor intern.

Prin urmare, dacă utilizați un comutator cu propriul procesor, este important să determinați puterea procesorului respectiv și dacă se potrivește cu sarcina așteptată a rețelei.

Switch-urile LAN acceptă următoarele standarde:

· Fast Ethernet;

· Gigabit Ethernet;

· 10 Gigabit Ethernet;

· Token Ring rapid;

Una dintre cele mai frecvente probleme rezolvate cu ajutorul mecanismelor de comutare este reducerea probabilității de conflicte și creșterea debitului rețelelor locale Ethernet. Switch-urile Ethernet folosesc tabelele de adrese MAC pentru a determina ce porturi ar trebui să primească date specifice.

Deoarece fiecare port este conectat la un segment care conține un singur nod, acest nod și acest segment au la dispoziție toată lățimea de bandă (10 sau 100 Mbps, 1 sau 10 Gbps), deoarece nu există alte noduri; În același timp, probabilitatea conflictelor scade.

O altă aplicație comună pentru comutatoare sunt rețelele token ring. Un comutator Token Ring poate îndeplini funcții numai de punte la nivelul Legăturii de date sau poate funcționa ca punte de rutare sursă la nivelul Rețea.

Trecând direct la segmentul care trebuie să primească date, comutatoarele pot crește semnificativ debitul rețelei fără a actualiza mediul de transmisie existent. Ca exemplu, luați în considerare un hub Ethernet fără comutator care are opt segmente de 10 Mbps conectate la el. Viteza acestui hub nu va depăși niciodată 10 Mbps, deoarece poate transfera date doar către un segment la un moment dat. Dacă hub-ul este înlocuit cu un comutator Ethernet, debitul general al rețelei va crește de opt ori până la 80 Mbps, deoarece comutatorul poate trimite pachete către fiecare segment aproape simultan. În prezent, switch-urile nu sunt cu mult mai scumpe decât hub-urile, așa că sunt cea mai simplă modalitate de a crește viteza unei rețele cu trafic intens.

Sunt disponibile comutatoare gestionate care, la fel ca hub-urile gestionate, au capabilități „inteligente”. Pentru multe rețele, este logic să cheltuiți bani suplimentari pentru achiziție comutatoare gestionate, care acceptă protocolul SNMP, care va crește gradul de gestionare și monitorizare a rețelei. Unele switch-uri pot suporta, de asemenea, tehnologia rețelei locale virtuale (Virtual LAN, VLAN).

Această tehnologie, descrisă de standardele IEEE 802.1q, este o metodă software de împărțire a unei rețele în subrețele care sunt independente de topologia sa fizică și conțin grupuri logice. Membrii unui grup de lucru VLAN pot fi localizați pe segmente de rețea la distanță fizică, dar pot fi combinați într-un singur segment logic utilizând software și comutatoare VLAN, routere și alte dispozitive de rețea. Cel mai bine este să utilizați comutatoare de rutare pentru a implementa VLAN-uri, deoarece acestea reduc costurile de gestionare a rețelei datorită capacității lor de a ruta pachete între subrețele. Comutatoare de nivel 2 VLAN-uri necesită ca porturile de comutare să fie asociate cu adrese MAC, ceea ce complică gestionarea VLAN-ului.

Gateway-uri

Termenul gateway folosit în multe contexte, dar cel mai adesea se referă la o interfață software sau hardware care permite interacțiunea între două tipuri diferite de sisteme sau programe de rețea.

Orez. 5 Gateway

De exemplu, puteți utiliza gateway-ul pentru a efectua următoarele operații:

· converti protocoalele utilizate pe scară largă (de exemplu, TCP/IP) în unele specializate (de exemplu, SNA);

Convertiți mesajele dintr-un format în altul;

Convertiți diferite scheme de adresare;

· conectați computerele gazdă la o rețea locală;

· furnizarea de emulare a terminalului pentru conexiunile la computerul gazdă;

· redirecționare e-mail la rețeaua dorită;

· conectați rețele cu arhitecturi diferite.

Gateway-urile au multe scopuri, astfel încât pot funcționa la orice Layer OSI.

Gateway-urile de rețea funcționează pe toate cele cunoscute sisteme de operare Oh. Sarcina principală a unui gateway de rețea este de a converti protocolul între rețele.

Routerul însuși primește, direcționează și trimite pachete numai între rețelele care folosesc aceleași protocoale.

Un gateway de rețea poate, pe de o parte, să accepte un pachet formatat pentru un protocol (de exemplu, Apple Talk) și să-l transforme într-un pachet pentru un alt protocol (de exemplu, TCP/IP) înainte de a-l trimite către alt segment de rețea. Gateway-urile de rețea pot fi hardware, software sau ambele, dar sunt de obicei software instalat pe un router sau computer. Gateway-ul de rețea trebuie să înțeleagă toate protocoalele utilizate de router. De obicei, gateway-urile de rețea sunt mai lente decât poduri de rețea, comutatoare și routere obișnuite.

Un gateway de rețea este un punct dintr-o rețea care servește drept ieșire către o altă rețea. Pe Internet, un nod sau un punct final poate fi fie un gateway de rețea, fie o gazdă. Utilizatorii de internet și computerele care livrează pagini web utilizatorilor sunt gazde și nodurile dintre acestea diverse rețele- Acestea sunt gateway-uri de rețea. De exemplu, un server care controlează traficul dintre rețeaua locală a unei companii și Internet este o poartă de rețea.

ÎN rețele mari un server care acționează ca o poartă de rețea, de obicei integrat cu un server proxy și firewall. Un gateway de rețea este adesea combinat cu un router, care gestionează distribuția și conversia pachetelor în rețea.

Un gateway de rețea poate fi un router hardware special sau un software instalat pe un server obișnuit sau pe un computer personal. Majoritatea sistemelor de operare pentru computere folosesc termenii descriși mai sus.

Calculatoarele Windows folosesc de obicei un expert de conexiune la rețea încorporat, care parametri specificati stabilește o conexiune la o rețea locală sau globală. Astfel de sisteme pot utiliza, de asemenea, protocolul DHCP.

Echipamentele de transmisie ale rețelelor globale sunt proiectate să funcționeze în rețelele telefonice obișnuite, precum și pe liniile închiriate, cum ar fi liniile T și liniile ISDN. Acestea pot avea componente analogice (cum ar fi modemurile) sau pot fi complet digitale (ca pentru comunicațiile ISDN). Cel mai adesea, acest echipament fie convertește semnalul pentru transmisie în distante lungi sau creează mai multe canale într-un singur mediu de comunicare, oferind astfel un randament mai mare.

Principalele tipuri de echipamente de transmisie ale rețelelor globale:

multiplexoare;

· grupuri de canale;

· privat retelele telefonice;

· modemuri telefonice;

· adaptoare ISDN;

· modemuri prin cablu;

· Modemuri și routere DSL;

· servere de acces;

· routere.

Multiplexoarele

Multiplexoare (multiplexor, MUX) sunt dispozitive de rețea care pot primi semnale de la mai multe intrări și le pot transmite într-un mediu de rețea comun.

Fig.1 Multiplexor

Multiplexoarele sunt în esență comutatoare și sunt utilizate în tehnologiile vechi și noi, inclusiv:

· în telefonie pentru comutarea liniilor fizice;

· la comutarea circuitelor virtuale de telecomunicații pentru a crea mai multe canale într-o linie (de exemplu, în linii T);

· în canale seriale pentru conectarea mai multor terminale la o singură linie (în rețele locale sau globale), pentru care această linie este împărțită în mai multe canale;

· în Fast Ethernet, X.25, ISDN, frame relay, tehnologii ATM și altele (pentru a crea o varietate de canale de comunicatieîntr-un singur mediu de transmisie prin cablu).

Multiplexoarele funcționează fizic Nivelul OSI, comutarea între canale. Aceasta utilizează una dintre cele trei metode de comutare electrică sau o singură metodă de transmisie pe un mediu optic.

Metode de comutare electrică: acces multiplu multiplexarea canalelor (TDMA), accesul multiplu prin diviziune de frecvență (FDMA) și accesul multiplu statistic.

La transmiterea pe un mediu optic, se utilizează multiplexarea prin diviziune în lungime de undă (WDM). O undă luminoasă poate fi gândită ca un spectru format din unde de lungimi de undă diferite, măsurate în angstromi. Un angstrom este egal cu 10-10 m, iar o undă luminoasă este formată din unde individuale cu o lungime de 4000 până la 7000 angstrom. Folosind diviziunea spectrală, conexiunile multiple de intrare sunt convertite într-un set de lungimi de undă diferite în spectrul luminii transmise de-a lungul cablului de fibră optică.

Grupuri de canale

Când au fost introduse pentru prima dată, băncile de canale, sau băncile de canale, erau dispozitive care permiteau mai multor semnale vocale de intrare să treacă peste o singură linie, iar multiplexoarele transformau mai multe semnale de date pentru transmisie pe o singură linie.

Orez. 2 grupuri de canale

Necesitatea de a transmite voce, date și video a dus la dezvoltarea rapidă a grupurilor de canale de telecomunicații, iar astăzi acestea pot fi folosite atât pentru a transmite semnale vocale, cât și pentru a efectua multiplexarea datelor, voce și video.

Astfel, un grup de canale este un multiplexor mare care combină canalele de telecomunicații într-un singur loc, numit punct de prezență (POP). Aceste circuite pot fi linii private T-1, linii complete T-1 și T-3, circuite ISDN sau circuite releu cadru. Primele grupuri de canale de tip D-1 au constat din multiplexoare T-1.

Îmbunătățirile în grupurile de canale au condus la introducerea D-4 și a mai puțin costisitoare sisteme de acces și comutare digitală (DACS). Acolo unde liniile închiriate sunt utilizate intens, există și grupuri de circuite T-3, ISDN și releu cadru.

În cadrul unui punct de prezență (POP), mai multe grupuri de circuite comunică între ele, astfel încât traficul de intrare de la un grup de circuite să poată fi comutat la un alt grup de circuite și trimis la punctul de destinație. Toate canalele de pe o linie de intrare (de exemplu, o linie T-1) sunt combinate și pot fi redirecționate către un alt grup de canale. De asemenea, puteți redirecționa doar unul dintre canalele primite către alt grup. Există două metode de rutare pentru conectarea grupurilor de legături, care sunt în esență similare cu rutarea dinamică și statică în rețele. Astfel, grupurile de canale moderne au tabele de rutare care sunt fie întreținute automat, fie configurate de administratori.

Depinzând de arhitectura de retea punctele de prezență, informațiile de rutare pot fi stocate fie central într-unul dintre grupurile de canale, fie distribuite între grupurile stabilite.

Rețele telefonice private

Pentru a reduce numărul de linii conectate la compania de telefonie regională, unele organizații își implementează propriile servicii de telefonie. De exemplu, o companie poate avea 100 de birouri cu propriile telefoane, dar nu mai mult de 50 de angajați pot suna simultan în afara acestor birouri. Această companie poate economisi bani prin instalarea unui sistem telefonic propriu, care are 100 de linii de comunicație cu birouri conectate la o centrală centrală (centrală telefonică automată) sau la un centru de comutație, care este conectată cu 50 de linii la compania regională de telefonie.

Inițial, cele mai comune sisteme private au fost schimburile de birou cu comunicații de ieșire și de intrare (centrală de sucursală privată, PBX). Erau comutatoare manuale care solicitau unui operator să realizeze conexiuni în cadrul organizației sau atunci când accesa o rețea telefonică externă.

Ca urmare a îmbunătățirilor, au apărut sistemele automate de telefonie corporativă, numite PBX-uri private fără acces la Internet. rețea partajată(centrală automată privată, PAX) și centrale telefonice automate private cu comunicații de ieșire și de intrare (centrală de sucursală automată privată, PABX).

Orez. 3 Centrală automată privată, PABX

Stațiile PAX folosesc în continuare un comutator, iar comutarea se realizează atât manual, cât și automat. Stațiile PAX nu au comutator. Ambele tipuri de schimburi includ linii telefonice trunk (asemănătoare cu o coloană vertebrală a rețelei), linii telefonice obișnuite, linii regionale ale companiilor de telefonie, telefoane și un sistem de comutare bazat pe procesor sau un computer care are memorie, HDDși software. Aceste posturi pot transmite video și date în plus față de vorbire.

Centralizat sistem informatic oferă adesea capabilități de mesagerie vocală, redirecționare și așteptare a apelurilor, funcții de urmărire a timpului și alte servicii. Cel mai adesea, astfel de sisteme au o consolă pentru un operator care îndeplinește funcții speciale (de exemplu, procesare numerele de extensie, conturi și alte informații). Uneori există linii de modem pentru angajații care se conectează la o rețea de computere de acasă printr-o linie dial-up.

Modemuri telefonice

Modemurile au jucat mult timp un rol important în dezvoltarea rețelelor globale. Termenul modem este o abreviere pentru termenul modulator/demodulator.
Modemul convertește semnalul de ieșire al computerului (digital) într-un semnal analogic care poate fi transmis printr-o linie telefonică. În plus, modemul transformă semnalul analogic de intrare într-un semnal digital pe care computerul îl poate înțelege.

Orez. 4 Modem telefonic

Modemurile pentru computere pot fi interne sau externe. Modemul intern este introdus în slotul de expansiune al computerului de pe placa de bază.

Un modem extern este un dispozitiv de sine stătător care este conectat la portul serial al computerului folosind un cablu special de modem care se potrivește cu conectorul portului serial.

Există trei tipuri principale de conectori: conectorul moștenit cu 25 de pini DB-25, similar cu un conector de port paralel al imprimantei (dar nu este potrivit pentru funcționarea cu port paralel); un conector DB-9 cu 9 pini și un conector rotund PS/2 pentru comunicații seriale (cum ar fi pe computerul IBM).

De asemenea, pentru conexiunile seriale se folosește Universal Serial Bus USB. Standardul USB permite conectarea oricărui tip de dispozitive periferice (de exemplu, imprimante, modemuri și unități de bandă) și în multe cazuri înlocuiește paralele și convenționale. porturi seriale. Atât modemurile interne cât și cele externe se conectează la priza de telefon folosind un cablu telefonic obișnuit cu conectori RJ-11 la ambele capete.

Viteza de transfer a datelor modemului este măsurată prin două unități similare, dar nu identice: rata de transmisie și numărul de biți transmiși pe secundă (bps). Rata baud reprezintă numărul de modificări pe secundă pentru o formă de undă care transportă date. Această viteză a determinat în mod fiabil viteza modemurilor atunci când au apărut (când puteau transmite doar un bit de date pentru fiecare schimbare de semnal).

Principala influență asupra tehnologiei modemului a fost Microcom, care a fost primul care a dezvoltat protocolul Microcom Protocol de rețea(MNP). Acest standard descrie clase de servicii de comunicații (clasele MNP 2 până la 6, precum și clasa 10 pentru transmisie folosind celulare) și asigură o funcționare eficientă folosind tehnici de corectare a erorilor și comprimare a datelor.

ITU a dezvoltat, de asemenea, standarde pentru comunicațiile prin modem, inclusiv multe clase MNP în standardul său V.42.

Modemurile funcționează fie în modul sincron, fie în modul asincron. În comunicațiile sincrone, pachetele de date repetate sunt controlate de un semnal de ceas care începe fiecare pachet. În modul asincron, datele sunt transmise în blocuri separate separate prin biți de pornire și de oprire.

adaptoare ISDN

Pentru a conecta un computer la o linie ISDN, aveți nevoie de un dispozitiv asemănător unui modem digital numit adaptor terminal (TA).

Orez. 5 adaptor ISDN

Adaptoarele de terminale existente costă aproape la fel ca modemurile asincrone sau sincrone de înaltă calitate, dar performanța lor este mai mare (de exemplu, de la 128 la 512 Kbps).

Adaptoarele terminale convertesc semnal digitalîntr-un protocol care este potrivit pentru transmisie printr-o linie telefonică digitală. De obicei, au o mufă analogică pentru telefon care vă permite să conectați un telefon sau un modem obișnuit și să îl utilizați pe o linie digitală.

Cel mai adesea, echipamentele ISDN vă permit să vă conectați la o singură linie telefonică sau pereche de cupru (același fir care conectează telefonul de acasă sau de la birou la schimb de telefoane), cu toate acestea, oferă canale separate pentru date computerizate și comunicații vocale analogice normale. Puteți utiliza fie o linie analogică și una digitală, fie două linii digitale sau două linii analogice în același timp.

Modemuri și routere DSL

Un alt serviciu de date digitale de mare viteză care concurează cu ISDN și modemurile prin cablu este Digital Subscriber Line, tehnologia DSL (Digital Subscriber Line).

Este o metodă de transmitere a datelor digitale prin firul de cupru deja instalat în majoritatea birourilor de servicii telefonice (cel mai nou Tehnologii DSL poate fi utilizat cu linii telefonice cu fibră optică). Pentru a utiliza DSL, puteți instala un adaptor inteligent pe computerul dvs. care este conectat la rețeaua DSL

Fig.1 Adaptor inteligent conectat la o rețea DSL

Un adaptor inteligent poate arăta ca un modem, dar adaptorul este complet digital, adică nu convertește semnalul digital DTE (computer sau dispozitiv de rețea) în analog, ci îl trimite direct la linia telefonică. Două perechi de conductori conectează adaptorul și priza de telefon.

Comunicațiile din cupru sunt simplex (unidirecționale), adică o pereche este folosită pentru a transmite date de ieșire, iar cealaltă este folosită pentru a primi semnale de intrare, rezultând o legătură în sus către compania de telecomunicații și o legătură în jos către utilizator.

Viteza maximă de uplink este de 1 Mbit/s, iar viteza de downlink poate ajunge la 60 Mbit/s. Distanța maximă fără repetitor (amplificarea semnalului) de la utilizator la compania de telecomunicații este de 5,5 km (ceea ce coincide cu cerințele ISDN).

O linie DSL este conectată la rețele folosind un adaptor și un router DSL combinate. Ca rezultat, acest dispozitiv poate fi folosit pentru a distribui traficul de rețea și ca firewall pentru a oferi acces dispozitive de rețea numai abonaților autorizați.

Cu această conexiune, mulți utilizatori pot accesa o linie DSL prin intermediul reteaua existenta, iar rețeaua va fi protejată împotriva intruziunilor prin această linie. De obicei, pentru o astfel de conexiune există un software de control care vă permite să monitorizați linia și să o diagnosticați.

Acces la servere

Un server de acces combină funcțiile mai multor dispozitive utilizate pentru comunicații globale.

De exemplu, un server de acces poate efectua transmisia de date folosind comunicații prin modem, linii X.25, T-1, T-3 și ISDN, precum și frame relay. Unele servere de acces sunt proiectate pentru rețelele mici și mijlocii.

Astfel de servere au un adaptor Ethernet sau Token Ring pentru a se conecta la rețea. De asemenea, au mai multe porturi sincrone și asincrone pentru conectarea terminalelor, modemurilor, telefoanelor cu plată, liniilor ISDN și X.25. U servere mici accesul variază de obicei între 8 și 16 porturi asincrone și unul sau două porturi sincrone.

Serverele de acces puternice au un design modular cu sloturi (de la 10 la 20) pentru conectarea plăcilor de comunicație, așa cum se arată în Fig. 4.14. O placă, de exemplu, poate avea 8 porturi asincrone și una sincronă. O altă placă poate fi proiectată pentru a se conecta la o linie T-1, iar alta poate fi proiectată să funcționeze cu o linie ISDN.

Orez. 2 Accesați serverele

Pot exista și plăci modulare cu modemuri încorporate, de exemplu, cu 4 modemuri pe o singură placă. Unele servere de acces modulare sunt capabile să suporte aproape 70 de modemuri. Pentru a asigura toleranța la erori, serverele sunt echipate și cu surse de alimentare suplimentare.

Routere

Folosind un router de la distanță, rețelele situate la distanțe mari unele de altele (de exemplu, în orașe diferite) pot fi combinate în retea globala. Un router situat într-un oraș poate conecta o anumită companie la un router la distanță situat într-o altă companie situată în orice alt oraș.

Orez. 3 Router

Routerele de la distanță conectează rețelele folosind ATM, ISDN, frame relay și tehnologii de transmisie de date în serie de mare viteză, precum și X.25. Un router la distanță, ca unul local, poate accepta mai multe protocoale, permițându-vă să vă conectați rețelele de la distanță tipuri variate. De asemenea, un router la distanță poate acționa ca un firewall, limitând accesul la anumite resurse de rețea.

Unele routere de la distanță au un design modular care permite ca diferite interfețe (de exemplu, o interfață de linie ISDN și o interfață de releu cadru) să fie introduse în sloturile de expansiune.

Avantajul unui astfel de router este că poate fi extins treptat pe măsură ce sarcinile de comunicare devin mai complexe, o problemă cu care se confruntă multe organizații.

Asadar, haideti sa începem.

Articole și videoclipuri despre cum să configurați munții OSPF. Mult mai puține descrieri ale principiilor de funcționare. În general, lucrul aici este că OSPF poate fi configurat pur și simplu conform manualelor, fără să știi măcar despre algoritmi SPF și LSA-uri de neînțeles. Și totul va funcționa și chiar, cel mai probabil, va funcționa perfect - pentru asta a fost conceput. Adică, nu este ca în cazul vlan-urilor, unde trebuia să cunoști teoria până la formatul antetului.
Dar ceea ce distinge un inginer de un tip IT este că înțelege de ce rețeaua lui funcționează așa cum o face și știe, nu mai rău decât OSPF însuși, care rută va fi aleasă de protocol.
În cadrul articolului, care în acest moment are deja 8.000 de caractere, nu ne vom putea scufunda în profunzimea teoriei, dar vom lua în considerare punctele fundamentale.
Este foarte simplu și clar, apropo, este scris despre OSPF pe xgu.ru sau în Wikipedia în engleză.
Deci, OSPFv2 funcționează pe deasupra IP și, în special, este proiectat numai pentru IPv4 (OSPFv3 nu depinde de protocoalele de nivel 3 și, prin urmare, poate funcționa cu IPv6).

Să ne uităm la cum funcționează folosind exemplul acestei rețele simplificate:

Pentru început, trebuie spus că pentru ca o relație de prietenie (relație de adiacență) să se dezvolte între routere, trebuie îndeplinite următoarele condiții:

1) aceleași setări trebuie configurate în OSPF Salut Interval pe acele routere care sunt conectate între ele. În mod implicit, este de 10 secunde în rețelele de difuzare, cum ar fi Ethernet. Acesta este un fel de mesaj KeepAlive. Adică, la fiecare 10 secunde, fiecare router trimite un pachet Hello vecinului său pentru a spune: „Hei, sunt în viață”.
2) Trebuie să fie la fel Interval mort pe ei. De obicei, acestea sunt 4 intervale Hello - 40 de secunde. Dacă nu se primește niciun salut de la vecin în acest timp, atunci acesta este considerat inaccesibil și PANIC începe procesul de reconstruire a bazei de date locale și de trimitere a actualizărilor tuturor vecinilor.
3) Interfețele conectate între ele trebuie să fie în o subrețea,
4) OSPF vă permite să reduceți sarcina CPU-ului routerelor prin împărțirea sistemului autonom în zone. Deci aici este numerele zonei trebuie de asemenea să se potrivească
5) Fiecare router care participă la procesul OSPF are propriul său unic identificator - ID router. Dacă nu aveți grijă de el, routerul îl va selecta automat pe baza informațiilor despre interfețele conectate (cea mai mare adresă este selectată dintre interfețele active la momentul începerii procesului OSPF). Dar, din nou, un inginer bun are totul sub control, așa că de obicei este creată o interfață Loopback, căreia i se atribuie o adresă cu o mască /32 și aceasta este ceea ce este atribuit ID-ului routerului. Acest lucru poate fi convenabil pentru întreținere și depanare.
6) Dimensiunea MTU trebuie să se potrivească

1) Calm. Stare OSPF - JOS
În acest scurt moment, nu se întâmplă nimic în rețea - toată lumea tace.

2) Vântul se ridică: routerul trimite pachete Hello la adresa multicast 224.0.0.5 de la toate interfețele pe care rulează OSPF. TTL-ul unor astfel de mesaje este unul, deci doar routerele situate în același segment de rețea le vor primi. R1 intră în stare INIT.

Pachetele conțin următoarele informații:

• ID router
• Salut Interval
• Interval mort
• Vecini
• Mască de rețea
• ID zona
• Prioritate router
• Adresele routerelor DR și BDR
• Parola de autentificare

Momentan suntem interesați de primele patru, sau mai precis, doar Router ID și Neighbours.
Mesajul Salut de la routerul R1 poartă ID-ul său de router și nu conține vecini, deoarece nu îi are încă.
După primirea acestui mesaj multicast, routerul R2 adaugă R1 la tabelul său vecin (dacă toți parametrii necesari se potrivesc).

Și trimite un nou mesaj Salut către R1 ca unicast, care conține ID-ul routerului acestui router, iar lista Neigbors listează toți vecinii săi. Printre alți vecini din această listă există Router ID R1, adică R2 îl consideră deja un vecin.

3) Prietenia. Când R1 primește acest mesaj Salut de la R2, derulează prin lista de vecini și își găsește propriul ID Router în ea, adaugă R2 la lista de vecini.

Acum R1 și R2 sunt vecini reciproci unul cu celălalt - asta înseamnă că a fost stabilită o relație de adiacență între ei și routerul R1 intră în stare DOUĂ SENSE.

Sfaturi generale pentru toate sarcinile:

Chiar dacă nu știți imediat răspunsul și soluția, încercați să vă gândiți la ce se referă starea problemei:
- Ce caracteristici și setări de protocol?
- Aceste setări sunt globale sau legate de o anumită interfață?
Dacă nu cunoașteți sau ați uitat comanda, astfel de reflecții vă vor conduce cel mai probabil către contextul corect, unde puteți pur și simplu să ghiciți sau să vă amintiți cum să configurați ceea ce este necesar în sarcină folosind un indiciu pe linia de comandă.
Încercați să gândiți în acest fel înainte de a merge pe Google sau pe un site care caută comenzi.

Într-o rețea reală, atunci când alegeți gama de subrețele promovate, trebuie să vă ghidați după reglementări și nevoi imediate.

Înainte de a trece la testarea legăturilor de rezervă și a vitezei, haideți să facem încă un lucru util.
Dacă am avea ocazia să captăm trafic pe interfața FE0/0.2 msk-arbat-gw1, care se confruntă cu serverele, atunci am vedea că mesajele Hello zboară în necunoscut la fiecare 10 secunde. Nu există nimeni cu care să răspundă Bună ziua, nu există cu cine să stabilească relații de vecinătate, așa că nu are rost să încerci să trimiți mesaje de aici.
Dezactivarea este foarte simplă:

msk-arbat-gw1(config)#router OSPF 1
msk-arbat-gw1(config-router)#interfață-pasivă fastEthernet 0/0.2

Această comandă trebuie dată pentru toate interfețele care cu siguranță nu au vecini OSPF (inclusiv cele către Internet).
Drept urmare, veți avea o imagine ca aceasta:

*Nu-mi pot imagina cum nu te-ai încurcat încă*

În plus, această comandă crește securitatea - nimeni din această rețea nu se va preface a fi un router și nu va încerca să ne spargă complet.

Acum să trecem la partea cea mai interesantă - testarea.
Nu este nimic complicat în configurarea OSPF pe toate routerele din Siberian Ring - o puteți face singur.
Și după aceea, imaginea ar trebui să fie după cum urmează:

msk-arbat-gw1#sh ip OSPF vecin

172.16.255.32 1 FULL/DR 00:00:31 172.16.2.2 FastEthernet0/1.4
172.16.255.48 1 FULL/DR 00:00:31 172.16.2.18 FastEthernet0/1.5
172.16.255.80 1 FULL/BDR 00:00:36 172.16.2.130 FastEthernet0/1.8
172.16.255.112 1 FULL/BDR 00:00:37 172.16.2.197 FastEthernet1/0.911

Sankt Petersburg, Kemerovo, Krasnoyarsk și Vladivostok sunt conectate direct.

msk-arbat-gw1#sh traseu ip

172.16.0.0/16 este subrețea variabil, 25 de subrețele, 6 măști



S 172.16.2.4/30 prin 172.16.2.2



O 172.16.2.160/30 prin 172.16.2.130, 00:05:53, FastEthernet0/1.8
O 172.16.2.192/30 prin 172.16.2.197, 00:04:18, FastEthernet1/0.911





S 172.16.16.0/21 prin 172.16.2.2
S 172.16.24.0/22 ​​prin 172.16.2.18
O 172.16.24.0/24 prin 172.16.2.18, 00:24:03, FastEthernet0/1.5
O 172.16.128.0/24 prin 172.16.2.130, 00:07:18, FastEthernet0/1.8
O 172.16.129.0/26 prin 172.16.2.130, 00:07:18, FastEthernet0/1.8

O 172.16.255.32/32 prin 172.16.2.2, 00:24:03, FastEthernet0/1.4
O 172.16.255.48/32 prin 172.16.2.18, 00:24:03, FastEthernet0/1.5
O 172.16.255.80/32 prin 172.16.2.130, 00:07:18, FastEthernet0/1.8
O 172.16.255.96/32 prin 172.16.2.130, 00:04:18, FastEthernet0/1.8
prin 172.16.2.197, 00:04:18, FastEthernet1/0.911
O 172.16.255.112/32 prin 172.16.2.197, 00:04:28, FastEthernet1/0.911

Toată lumea știe totul despre toată lumea.
Ce rută este transportat de la Moscova la Krasnoyarsk? Tabelul arată că krs-stolbi-gw1 este conectat direct și același lucru poate fi văzut din urmă:

1 172.16.2.130 35 msec 8 msec 5 ms

Acum distrugem interfața dintre Moscova și Krasnoyarsk și vedem cât timp durează restabilirea conexiunii.
Nu trec nici măcar 5 secunde până când toți ruterele au aflat despre incident și și-au recalculat tabelele de rutare:

msk-arbat-gw1(config-subif)#do sh ip ro 172.16.128.0

Cunoscut prin „OSPF 1”, distanta 110, metrica 4, tip intra zona
Ultima actualizare de la 172.16.2.197 pe FastEthernet1/0.911, acum 00:00:53
Blocuri descriptori de rutare:
* 172.16.2.197, de la 172.16.255.80, 00:00:53 în urmă, prin FastEthernet1/0.911
Valoarea rutei este 4, numărul de cotă de trafic este 1

Vld-gw1#sh ip ruta 172.16.128.0
Intrare de rutare pentru 172.16.128.0/24
Cunoscut prin „OSPF 1”, distanta 110, metrica 3, tip intra zona
Ultima actualizare de la 172.16.2.193 pe FastEthernet1/0, acum 00:01:57
Blocuri descriptori de rutare:
* 172.16.2.193, de la 172.16.255.80, 00:01:57 în urmă, prin FastEthernet1/0
Valoarea rutei este 3, numărul de cotă de trafic este 1

Msk-arbat-gw1#traceroute 172.16.128.1
Tastați secvența de evacuare la avort.
Urmărirea traseului la 172.16.128.1

1 172.16.2.197 4 msec 10 msec 10 msec
2 172.16.2.193 8 msec 11 msec 15 ms
3 172.16.2.161 15 msec 13 msec 6 ms

Adică, acum traficul ajunge la Krasnoyarsk în acest fel:

De îndată ce ridicați legătura, routerele comunică din nou, își schimbă bazele de date, recalculează cele mai scurte căi și le introduc în tabelul de rutare.
Videoclipul face totul mai clar. Vă recomand familiariza.

Ca orice protocol bun, OSPF acceptă autentificare - doi vecini pot verifica autenticitatea mesajelor OSPF primite înainte de a stabili relații de adiacență. Vă lăsăm să studiați pe cont propriu - este destul de simplu.

EIGRP

Acum să trecem la un alt protocol foarte important.

Deci, ce este bun la EIGRP?
- usor de configurat
- trecere rapidă la calculate dinainte traseu alternativ
- necesită mai puține resurse de router (comparativ cu OSPF)
- rezumarea rutelor pe orice router (în OSPF doar pe ABR\ASBR)
- echilibrarea traficului pe rute inegale (OSPF doar pe rute egale)

Am decis să traducem una dintre intrările de blog ale lui Ivan Pepelnyak, care abordează o serie de mituri populare despre EIGRP:
- „EIGRP este un protocol de rutare hibrid.” Dacă îmi amintesc bine, acest lucru a început cu prima prezentare a EIGRP cu mulți ani în urmă și este de obicei înțeles ca „EIGRP a luat cele mai bune dintre protocoalele de stare de legătură și de vector de distanță”. Acest lucru nu este absolut adevărat. EIGRP nu are caracteristici distinctive ale stării legăturii. Ar fi corect să spunem „EIGRP este un protocol avansat de rutare cu vector de distanță”.

- „EIGRP este un protocol de vector de distanță.” Nu e rău, dar nici în întregime adevărat. EIGRP diferă de alte DV-uri prin modul în care gestionează rutele orfane (sau rutele cu valori crescătoare). Toate celelalte protocoale așteaptă pasiv actualizările de la un vecin (unele, cum ar fi RIP, chiar blochează ruta pentru a preveni buclele de rutare), în timp ce EIGRP este mai activ și solicită informații în sine.

- „EIGRP este dificil de implementat și întreținut.” Neadevarat. La un moment dat, EIGRP în rețelele mari cu legături de viteză redusă era dificil de implementat corect, dar numai până când au fost introduse routerele stub. Cu ele (precum și câteva corecții ale algoritmului DUAL), este aproape mai rău decât OSPF.

- „La fel ca protocoalele LS, EIGRP menține un tabel cu topologia rutelor care sunt schimbate.” Este uimitor cât de greșit este asta. EIGRP habar nu are deloc ce se află dincolo de vecinii săi imediati, în timp ce protocoalele LS cunosc exact topologia întregii zone la care sunt conectate.

- „EIGRP este un protocol DV care acționează ca LS.” Bună încercare, dar totuși complet greșită. Protocoalele LS construiesc un tabel de rutare parcurgând următorii pași:
- fiecare router descrie rețeaua pe baza informațiilor disponibile pe plan local (legăturile sale, subrețelele în care se află, vecinii pe care îi vede) printr-un pachet (sau mai multe) numit LSA (în OSPF) sau LSP (IS-IS)
- LSA-urile sunt propagate în întreaga rețea. Fiecare router trebuie să primească fiecare LSA creat în rețeaua sa. Informațiile primite de la LSA sunt introduse în tabelul de topologie.
- Fiecare router își analizează în mod independent tabelul de topologie și rulează algoritmul SPF pentru a calcula cele mai bune rute către fiecare dintre celelalte routere
Comportamentul EIGRP nici măcar nu se apropie de acești pași, așa că de ce naiba „acţionează ca LS” nu este clar.

Singurul lucru pe care EIGRP îl face este să stocheze informațiile primite de la un vecin (RIP uită imediat ce nu poate fi folosit în acest moment). În acest sens, este similar cu BGP, care stochează tot într-un tabel BGP și alege de acolo cea mai bună rută. Tabelul de topologie (conținând toate informațiile primite de la vecini) oferă EIGRP un avantaj față de RIP - poate conține informații despre o rută de rezervă (neutilizată în prezent).

Acum puțin mai aproape de teoria muncii:

Fiecare proces EIGRP menține 3 tabele:
- Un tabel de vecini, care conține informații despre „vecini”, adică alte routere conectate direct la cel actual și care participă la schimbul de rute. Îl puteți vizualiza folosind comanda arata vecinii ip eigrp
- Tabel de topologie de rețea, care conține informații de rutare primite de la vecini. Să privim ca o echipă arată topologia ip eigrp
- Tabelul de rutare, pe baza căruia routerul ia decizii cu privire la redirecționarea pachetelor. Vizualizare prin arata ruta ip

Metrici.
Pentru a evalua calitatea unei anumite rute, protocoalele de rutare folosesc un anumit număr care reflectă diferitele sale caracteristici sau un set de caracteristici - o metrică. Caracteristicile luate în considerare pot fi diferite - de la numărul de routere de pe o rută dată până la media aritmetică a sarcinii pe toate interfețele de-a lungul rutei. În ceea ce privește metrica EIGRP, pentru a-l cita pe Jeremy Cioara: „Am avut impresia că creatorii EIGRP, aruncând o privire critică asupra creației lor, au decis că totul a fost prea simplu și a funcționat bine. Și apoi au venit cu o formulă metrică, astfel încât toată lumea să spună „WOW, asta este cu adevărat complicat și arată profesional”. Consultați formula completă pentru calcularea metricii EIGRP: (K1 * bw + (K2 * bw) / (256 - sarcină) + K3 * întârziere) * (K5 / (fiabilitate + K4)), în care:
- bw nu este doar lățime de bandă, ci (10000000/cea mai mică lățime de bandă de-a lungul traseului în kilobiți) * 256
- întârzierea nu este doar o întârziere, ci suma tuturor întârzierilor pe drum spre zeci de microsecunde* 256 (întârzierea în comenzile arată interfața, show ip eigrp topology și altele este afișată în microsecunde!)
- K1-K5 sunt coeficienți care servesc pentru a se asigura că unul sau altul parametru este „inclus” în formulă.

Infricosator? ar fi dacă totul ar funcționa așa cum este scris. De fapt, din toți cei 4 termeni posibili ai formulei, doar doi sunt utilizați implicit: bw și întârziere (coeficienții K1 și K3 = 1, restul sunt zero), ceea ce o simplifică foarte mult - pur și simplu adunăm aceste două numere (în timp ce nu uitând că sunt încă calculate după formule proprii). Este important să rețineți următoarele: metrica se calculează în funcție de cel mai slab indicator de debit de-a lungul întregii lungimi a rutei.

Un lucru interesant s-a întâmplat cu MTU: destul de des puteți găsi informații că MTU are legătură cu metrica EIGRP. Într-adevăr, valorile MTU sunt transmise la schimbul de rute. Dar, după cum putem vedea din formula completă, nu se menționează MTU. Cert este că acest indicator este luat în considerare în cazuri destul de specifice: de exemplu, dacă un router trebuie să renunțe la una dintre rutele care sunt echivalente în alte caracteristici, o va alege pe cea cu un MTU mai mic. Deși, nu totul este atât de simplu (vezi comentarii).

Să definim termenii folosiți în EIGRP. Fiecare rută din EIGRP este caracterizată de două numere: Distanța fezabilă și Distanța Anunțată (în loc de Distanța Anunțată, uneori puteți vedea Distanța raportată, acesta este același lucru). Fiecare dintre aceste numere reprezintă o metrică sau un cost (cu atât mai mult, cu atât mai rău) al unei anumite rute din diferite puncte de măsurare: FD este „de la mine la destinație”, iar AD este „de la vecinul care mi-a spus despre această rută până la numirile de la loc”. Răspunsul la întrebarea logică „De ce trebuie să știm costul de la un vecin dacă acesta este deja inclus în FD” este puțin mai mic (deocamdată poți să te oprești și să-ți faci creierul singur, dacă vrei).

Pentru fiecare subrețea de care cunoaște EIGRP, pe fiecare router există un router Succesor din rândul vecinilor, prin care trece cea mai bună (cu o metrică mai mică), conform protocolului, ruta către această subrețea. În plus, o subrețea poate avea și una sau mai multe rute de rezervă (routerul vecin prin care trece o astfel de rută se numește succesor fezabil). EIGRP este singurul protocol de rutare care își amintește rutele de rezervă (OSPF le are, dar sunt conținute, ca să spunem așa, în „forma brută” în tabelul de topologie; ele trebuie încă procesate de algoritmul SPF), ceea ce îi conferă un avantaj de performanță: de îndată ce protocolul stabilește că ruta principală (prin succesor) este indisponibilă, trece imediat la ruta de rezervă. Pentru ca un router să devină un succesor fezabil pentru o rută, AD sa trebuie să fie mai mic decât succesorul FD al acestei rute (de aceea trebuie să cunoaștem AD). Această regulă este folosită pentru a evita buclele de rutare.

Te-a suflat paragraful anterior? Materialul este dificil, așa că voi folosi din nou un exemplu. Avem aceasta retea:

Din punctul de vedere al lui R1, R2 este Succesorul pentru subrețeaua 192.168.2.0/24. Pentru a deveni un FS pentru această subrețea, R4 necesită ca AD să fie mai mic decât FD pentru această rută. Avem FD ((10000000/1544)*256)+(2100*256) =2195456, R4 are AD (din punctul lui de vedere este FD, adică cât îl costă să ajungă în această rețea) = (( 10000000/100000 )*256)+(100*256)=51200. Totul converge, AD-ul R4 este mai mic decât FD-ul rutei, devine FS. *apoi creierul spune: „BDASH”*. Acum ne uităm la R3 - el își anunță rețeaua 192.168.1.0/24 vecinului său R1, care, la rândul său, le spune vecinilor săi R2 și R4 despre asta. R4 nu știe că R2 știe despre această subrețea și decide să-i spună. R2 transmite informația că are acces prin R4 către subrețeaua 192.168.1.0/24 în continuare către R1. R1 se uită cu strictețe la FD-ul rutei și AD, cu care se laudă R2 (care, după cum este ușor de înțeles din diagramă, va fi în mod clar mai mare decât FD, deoarece îl include și pe el) și îl alungă pentru a nu interferează cu tot felul de prostii. Această situație este destul de puțin probabilă, dar poate apărea în anumite circumstanțe, de exemplu, atunci când mecanismul cu orizontul împărțit este dezactivat. Și acum la o situație mai probabilă: imaginați-vă că R4 este conectat la rețeaua 192.168.2.0/24 nu prin FastEthernet, ci printr-un modem de 56k (întârzierea pentru dialup este de 20.000 usec), în consecință, îl costă ((10000000/56) )*256 )+(2000*256)= 46226176. Acesta este mai mult decât FD pentru această rută, deci R4 nu va deveni un succesor fezabil. Dar asta nu înseamnă că EIGRP nu va folosi deloc această rută. Va dura mai mult pentru a trece la el (mai multe despre asta mai târziu).

Cartier

Routerele nu vorbesc despre rute oricui - trebuie să stabilească relații de adiacență înainte de a putea începe să schimbe informații. După pornirea procesului cu comanda router eigrp, indicând numărul sistemului autonom, noi, cu comanda de rețea, spunem ce interfețe vor participa și, în același timp, informații despre ce rețele dorim să distribuim. Imediat, pachetele hello încep să fie trimise prin aceste interfețe la adresa multicast 224.0.0.10 (în mod implicit la fiecare 5 secunde pentru ethernet). Toate routerele cu EIGRP activat primesc aceste pachete, apoi fiecare router care primește face următoarele:
- verifică adresa expeditorului pachetului hello cu adresa interfeței de la care a fost primit pachetul și se asigură că sunt din aceeași subrețea
- compară valorile coeficienților K obținuți din pachet (cu alte cuvinte, care variabile sunt utilizate în calcularea metricii) cu propriile sale. Este clar că, dacă diferă, atunci valorile pentru rute vor fi calculate în funcție de reguli diferite, ceea ce este inacceptabil
- verifică numărul sistemului autonom
- opțional: dacă autentificarea este configurată, verifică consistența tipului și a cheilor acestuia.

Dacă destinatarul este mulțumit de toate, îl adaugă pe expeditor pe lista vecinilor săi și îi trimite (deja în Unicast) un pachet de actualizare, care conține o listă cu toate rutele cunoscute de el (aka full-update). Expeditorul, după ce a primit un astfel de pachet, face la rândul său același lucru. Pentru schimbul de rute, EIGRP folosește Reliable Transport Protocol (RTP, care nu trebuie confundat cu Real-time Transport Protocol, care este utilizat în telefonia IP), care implică confirmarea livrării, astfel încât fiecare dintre routere, după ce a primit un pachet de actualizare, răspunde cu un pachet de confirmare (abreviere de la confirmare - confirmare). Deci, relația de vecinătate a fost stabilită, routerele au învățat unul de la celălalt informații complete despre rute, ce urmează? Apoi, ei vor continua să trimită pachete de salut multicast pentru a confirma că sunt conectate și, dacă topologia se modifică, vor actualiza pachetele care conțin doar informații despre modificări (actualizare parțială).

Acum să revenim la schema anterioară cu modemul.

R2 din anumite motive a pierdut contactul cu 192.168.2.0/24. Nu are rute de rezervă către această subrețea (adică, fără FS). La fel ca orice router responsabil EIGRP, vrea să restabilească conectivitatea. Pentru a face acest lucru, el începe să trimită mesaje speciale (pachete de interogare) tuturor vecinilor săi, care, la rândul lor, negăsind ruta dorită în ei înșiși, întreabă toți vecinii lor și așa mai departe. Când valul de solicitări ajunge la R4, el spune „stai puțin, am o rută către această subrețea! Rău, dar măcar ceva. Toți au uitat de el, dar îmi amintesc.” El împachetează toate acestea într-un pachet de răspuns și îl trimite vecinului de la care a primit cererea (interogare) și mai departe de-a lungul lanțului. Desigur, toate acestea necesită mai mult timp decât trecerea la Feasible Successor, dar în cele din urmă obținem comunicare cu subrețeaua.

Și acum este un moment periculos: poate ați observat deja și ați devenit precaut după ce ați citit despre acest e-mailing de la fani. Eșecul unei interfețe provoacă ceva similar cu o furtună de difuzare în rețea (nu la o asemenea scară, desigur, dar totuși), și cu cât sunt mai multe routere, cu atât mai multe resurse vor fi cheltuite pentru toate aceste solicitări și răspunsuri. Dar asta nu e chiar atât de rău. O situație mai gravă este posibilă: imaginați-vă că routerele prezentate în imagine sunt doar o parte dintr-o rețea mare și distribuită, de exemplu. unele pot fi situate la multe mii de kilometri de R2-ul nostru, pe canale proaste etc. Deci, problema este că, după ce a trimis o interogare unui vecin, routerul trebuie să aștepte un răspuns de la acesta. Nu contează care este răspunsul, dar trebuie să vină. Chiar dacă routerul deja a primit un răspuns pozitiv, ca și în cazul nostru, nu poate pune în funcțiune această rută până nu așteaptă un răspuns la toate solicitările sale. Și poate că mai sunt cereri undeva în Alaska. Această stare de rută se numește blocat-în-activ. Aici trebuie să ne familiarizăm cu termenii care reflectă starea rutei în EIGRP: rută activ\pasivă. De obicei sunt înșelătoare. Bunul simț dictează că activ înseamnă că traseul este „activ”, activat, rulant. Totuși, aici totul este invers: pasiv înseamnă „totul este în regulă”, iar starea activă înseamnă că această subrețea este indisponibilă, iar routerul caută în mod activ o altă rută, trimite o interogare și așteaptă un răspuns. Deci, starea blocată în activ poate dura până la 3 minute! După expirarea acestei perioade, routerul întrerupe relația de vecin cu vecinul de la care nu poate aștepta un răspuns și poate folosi o nouă rută prin R4.

O poveste care îngheață sângele unui inginer de rețea. 3 minute de pauză nu este o glumă. Cum putem evita atacul de cord din această situație? Există două căi de ieșire: însumarea rutelor și așa-numita configurație stub.

În general, există o altă cale de ieșire și se numește filtrarea rutei. Dar acesta este un subiect atât de voluminos încât ar fi mai bine să scriem un articol separat despre el, dar avem deja o jumătate de carte de data aceasta. Deci depinde de tine.

După cum am menționat deja, în EIGRP rezumarea rutei poate fi efectuată pe orice router. Pentru a exemplifica, să ne imaginăm că subrețelele de la 192.168.0.0/24 la 192.168.7.0/24 sunt conectate la îndelungul nostru R2, care însumează foarte convenabil până la 192.168.0.0/21 (amintiți-vă matematica binară). Routerul face publicitate acestei rute rezumative și toți ceilalți știu: dacă adresa de destinație începe cu 192.168.0-7, atunci este pentru el. Ce se întâmplă dacă una dintre subrețele dispare? Routerul va trimite pachete de interogare cu adresa acestei rețele (specifică, de exemplu, 192.168.5.0/24), dar vecinii, în loc să continue trimiterea vicioasă în numele lor, vor răspunde imediat cu reluări serioase, spunând că aceasta este subrețeaua dvs., vă dați seama.

A doua opțiune este configurația stub. Figurat vorbind, stub înseamnă „sfârșitul drumului”, „fundătură” în EIGRP, adică a intra într-o subrețea care nu este conectată. direct la un astfel de router, va trebui să te întorci. Un router configurat ca stub nu va redirecționa traficul între subrețelele pe care le cunoaște din EIGRP (cu alte cuvinte, care sunt marcate cu litera D în show ip route). În plus, vecinii săi nu îi vor trimite pachete de interogare. Cea mai comună aplicație sunt topologiile hub-and-spoke, în special cu legături redundante. Să luăm această rețea: în stânga sunt filiale, în dreapta este site-ul principal, sediul principal etc. Pentru toleranță la erori, legături redundante. EIGRP rulează cu setările implicite.

Și acum „atenție, întrebare”: ce se va întâmpla dacă R1 pierde conexiunea cu R4, iar R5 pierde LAN? Traficul de la subrețeaua R1 către subrețeaua biroului principal va urma traseul R1->R5->R2 (sau R3)->R4. Va fi eficient? Nu. Nu doar subrețeaua din spatele R1 va avea de suferit, ci și subrețeaua din spatele R2 (sau R3), din cauza creșterii volumelor de trafic și a consecințelor acesteia. Pentru astfel de situații a fost inventat stub. În spatele routerelor din ramuri nu există alte routere care să conducă la alte subrețele, acesta este „sfârșitul drumului”, apoi doar înapoi. Prin urmare, cu o inimă ușoară, le putem configura ca stub-uri, ceea ce, în primul rând, ne va salva de problema cu „ruta strâmbă” conturată chiar mai sus și, în al doilea rând, de inundația de pachete de interogare în cazul pierderii rutei. .

Există diferite moduri de funcționare a unui router stub, acestea sunt setate cu comanda eigrp stub:

R1(config)#router eigrp 1
R1(config-router)#eigrp stub?
conectat Faceți publicitate rutelor conectate
leak-map Permite prefixe dinamice bazate pe leak-map
numai recepție Setați IP-EIGRP ca vecin numai recepție
redistribuit Faceți publicitate rutelor redistribuite
static Faceți publicitate rutelor statice
rezumat Faceți publicitate rute rezumate

În mod implicit, dacă lansați pur și simplu comanda eigrp stub, modurile conectat și rezumat sunt activate. Interesant este modul de recepție, în care routerul nu face reclamă la nicio rețea, ci doar ascultă ceea ce îi spun vecinii (în RIP există o comandă de interfață pasivă care face același lucru, dar în EIGRP dezactivează complet protocolul pe interfața selectată, care nu permite stabilirea unei vecinătăți).

Puncte importante din teoria EIGRP care nu au fost incluse în articol:

• Autentificarea vecinului poate fi configurată în EIGRP
• Concept de oprire grațioasă

Practica EIGRP

Lift mi Up a cumpărat o fabrică în Kaliningrad. Acolo se produc creierul lifturilor: microcircuite, software. Fabrica este foarte mare - trei puncte în jurul orașului - trei routere conectate într-un inel.

Dar ghinion - au deja EIGRP care rulează ca protocol de rutare dinamică. Mai mult, adresarea nodurilor terminale este dintr-o subrețea complet diferită - 10.0.0.0/8. Am schimbat toți ceilalți parametri (adrese de link, adrese de interfață loopback), dar câteva mii de adrese de rețea locală cu servere, imprimante, puncte de acces - nu o lucrare pentru câteva ore - au fost amânate pentru mai târziu, iar în planul IP am rezervat 172.16 subrețea pentru viitor pentru Kaliningrad .32.0/20.

În prezent folosim următoarele rețele:

Cum este configurat acest miracol? Necomplicat la prima vedere:

router eigrp 1
reţea 172.16.0.0 0.0.255.255
rețeaua 10.0.0.0

În EIGRP, masca inversă poate fi specificată, indicând astfel un domeniu mai restrâns sau nespecificat, apoi va fi selectată masca standard pentru această clasă (16 pentru clasa B - 172.16.0.0 și 8 pentru clasa 8 - 10.0.0.0)

Astfel de comenzi sunt emise pe toate routerele Autonomous System. AC este determinat de numărul din comanda router eigrp, adică în cazul nostru avem AC Nr. 1. Această cifră ar trebui să fie aceeași pe toate routerele (spre deosebire de OSPF).

Dar există o captură serioasă în EIGRP: în mod implicit, rezumarea automată a rutelor în formă de clasă este activată (în versiunile IOS până la 15).
Să comparăm tabelele de rutare pe trei routere Kaliningrad:

Rețeaua 10.0.0.1/24 este conectată la klgr-center-gw1 și el știe despre asta:

klgr-center-gw1:
10.0.0.0/8 este subrețele variabil, 2 subrețele, 2 măști
D 10.0.0.0/8 este un rezumat, 00:35:23, Null0
C 10.0.0.0/24 este conectat direct, FastEthernet1/0

Dar nu știe despre 10.0.1.0/24 și 10.0.2.0/24/

Klgr-balt-gw1 știe despre cele două rețele ale sale 10.0.1.0/24 și 10.0.2.0/24, dar a ascuns rețeaua 10.0.0.0/24 undeva.

10.0.0.0/8 este subrețele variabil, 3 subrețele, 2 măști
D 10.0.0.0/8 este un rezumat, 00:42:05, Null0
C 10.0.1.0/24 este conectat direct, FastEthernet1/1.2
C 10.0.2.0/24 este conectat direct, FastEthernet1/1.3

Amândoi au creat ruta 10.0.0.0/8 cu următoarea adresă de hop Null0.

Dar klgr-center-gw2 știe că subrețelele 10.0.0.0/8 se află în spatele ambelor interfețe WAN.

D 10.0.0.0/8 prin 172.16.2.41, 00:42:49, FastEthernet0/1
prin 172.16.2.45, 00:38:05, FastEthernet0/0

Se întâmplă ceva foarte ciudat.
Dar, dacă verificați configurația acestui router, probabil veți observa:

router eigrp 1
rețeaua 172.16.0.0
rețeaua 10.0.0.0
auto-rezumat

Însumarea automată este de vină pentru tot. Acesta este cel mai mare rău al EIGRP. Să aruncăm o privire mai atentă la ceea ce se întâmplă. klgr-center-gw1 și klgr-balt-gw1 au subrețele din 10.0.0.0/8, le însumează implicit atunci când le transmit vecinilor.
Adică, de exemplu, msk-balt-gw1 transmite nu două rețele 10.0.1.0/24 și 10.0.2.0/24, ci una generalizată: 10.0.0.0/8. Adică vecinul său va crede că în spatele msk-balt-gw1 se află toată această rețea.
Dar ce se întâmplă dacă brusc balt-gw1 primește un pachet cu destinația 10.0.50.243, despre care nu știe nimic? Pentru acest caz, este creată așa-numita rută Blackhole:
10.0.0.0/8 este un rezumat, 00:42:05, Null0
Pachetul rezultat va fi aruncat în această gaură neagră. Acest lucru se face pentru a evita buclele de rutare.
Așadar, ambele routere și-au creat propriile rute negre și au ignorat anunțurile altora. În realitate, pe o astfel de rețea, aceste trei dispozitive nu vor putea să-și pună ping unul pe celălalt până când... până când nu dezactivați rezumatul automat.

Primul lucru pe care ar trebui să-l faceți când configurați EIGRP este:

router eigrp 1
fara auto-rezumat

Pe toate dispozitivele. Și toată lumea va fi bine:

Klgr-center-gw1:

C 10.0.0.0 este conectat direct, FastEthernet1/0
D 10.0.1.0 prin 172.16.2.37, 00:03:11, FastEthernet0/0
D 10.0.2.0 prin 172.16.2.37, 00:03:11, FastEthernet0/0

klgr-balt-gw1

10.0.0.0/24 este subrețele, 3 subrețele
D 10.0.0.0 prin 172.16.2.38, 00:08:16, FastEthernet0/1
C 10.0.1.0 este conectat direct, FastEthernet1/1.2
C 10.0.2.0 este conectat direct, FastEthernet1/1.3

klgr-center-gw2:

10.0.0.0/24 este subrețele, 3 subrețele
D 10.0.0.0 prin 172.16.2.45, 00:11:50, FastEthernet0/0
D 10.0.1.0 prin 172.16.2.41, 00:11:48, FastEthernet0/1
D 10.0.2.0 prin 172.16.2.41, 00:11:48, FastEthernet0/1

Configurarea transferului rutei între diferite protocoale

Sarcina noastră este să organizăm transferul de rute între aceste protocoale: de la OSPF la EIGRP și invers, astfel încât toată lumea să cunoască ruta către orice subrețea.
Aceasta se numește redistribuire a rutei.

Pentru a-l implementa, avem nevoie de cel puțin un punct de joncțiune unde două protocoale vor fi lansate simultan. Acesta ar putea fi msk-arbat-gw1 sau klgr-balt-gw1. Să-l alegem pe al doilea.

De la EIGRP la OSPF:

klgr-gw1(config)#router ospf 1
klgr-gw1(config-router)#redistribuiți subrețele eigrp 1

Ne uităm la rutele pe msk-arbat-gw1:

msk-arbat-gw1#sh traseu ip
Coduri: C - conectat, S - static, I - IGRP, R - RIP, M - mobil, B - BGP
D - EIGRP, EX - EIGRP extern, O - OSPF, IA - OSPF inter zona
N1 - OSPF NSSA extern tip 1, N2 - OSPF NSSA extern tip 2
E1 - OSPF extern tip 1, E2 - OSPF extern tip 2, E - EGP
i - IS-IS, L1 - IS-IS nivelul 1, L2 - IS-IS nivelul 2, ia - IS-IS interzona
* - implicit candidat, U - rută statică per utilizator, o - ODR
P - rută statică descărcată periodic

Gateway-ul de ultimă instanță este 198.51.100.1 către rețeaua 0.0.0.0

10.0.0.0/8 este subrețele variabil, 3 subrețele, 2 măști
O E2 10.0.0.0/8 prin 172.16.2.34, 00:25:11, FastEthernet0/1.7
O E2 10.0.1.0/24 prin 172.16.2.34, 00:25:11, FastEthernet0/1.7
O E2 10.0.2.0/24 prin 172.16.2.34, 00:24:50, FastEthernet0/1.7
172.16.0.0/16 este subrețea variabil, 30 de subrețele, 5 măști
O E2 172.16.0.0/16 prin 172.16.2.34, 00:25:11, FastEthernet0/1.7
C 172.16.0.0/24 este conectat direct, FastEthernet0/0.3
C 172.16.1.0/24 este conectat direct, FastEthernet0/0.2
C 172.16.2.0/30 este conectat direct, FastEthernet0/1.4
C 172.16.2.16/30 este conectat direct, FastEthernet0/1.5
C 172.16.2.32/30 este conectat direct, FastEthernet0/1.7
O E2 172.16.2.36/30 prin 172.16.2.34, 01:00:55, FastEthernet0/1.7
O E2 172.16.2.40/30 prin 172.16.2.34, 01:00:55, FastEthernet0/1.7
O E2 172.16.2.44/30 prin 172.16.2.34, 01:00:55, FastEthernet0/1.7
C 172.16.2.128/30 este conectat direct, FastEthernet0/1.8
O 172.16.2.160/30 prin 172.16.2.130, 01:00:55, FastEthernet0/1.8
O 172.16.2.192/30 prin 172.16.2.197, 00:13:21, FastEthernet1/0.911
C 172.16.2.196/30 este conectat direct, FastEthernet1/0.911
C 172.16.3.0/24 este conectat direct, FastEthernet0/0.101
C 172.16.4.0/24 este conectat direct, FastEthernet0/0.102
C 172.16.5.0/24 este conectat direct, FastEthernet0/0.103
C 172.16.6.0/24 este conectat direct, FastEthernet0/0.104
O 172.16.24.0/24 prin 172.16.2.18, 01:00:55, FastEthernet0/1.5
O 172.16.128.0/24 prin 172.16.2.130, 01:00:55, FastEthernet0/1.8
O 172.16.129.0/26 prin 172.16.2.130, 01:00:55, FastEthernet0/1.8
O 172.16.144.0/24 prin 172.16.2.130, 00:13:21, FastEthernet0/1.8

O 172.16.160.0/24 prin 172.16.2.197, 00:13:31, FastEthernet1/0.911
C 172.16.255.1/32 este conectat direct, Loopback0
O 172.16.255.48/32 prin 172.16.2.18, 01:00:55, FastEthernet0/1.5
O E2 172.16.255.64/32 prin 172.16.2.34, 01:00:55, FastEthernet0/1.7
O E2 172.16.255.65/32 prin 172.16.2.34, 01:00:55, FastEthernet0/1.7
O E2 172.16.255.66/32 prin 172.16.2.34, 01:00:55, FastEthernet0/1.7
O 172.16.255.80/32 prin 172.16.2.130, 01:00:55, FastEthernet0/1.8
O 172.16.255.96/32 prin 172.16.2.130, 00:13:21, FastEthernet0/1.8
prin 172.16.2.197, 00:13:21, FastEthernet1/0.911
O 172.16.255.112/32 prin 172.16.2.197, 00:13:31, FastEthernet1/0.911
198.51.100.0/28 este subrețea, 1 subrețea
C 198.51.100.0 este conectat direct, FastEthernet0/1.6
S* 0.0.0.0/0 prin 198.51.100.1

Iată-le pe cele cu eticheta E2 - rute noi importate. E2 - înseamnă că acestea sunt rute externe de al 2-lea tip (Extern), adică au fost introduse în procesul OSPF din exterior

Acum de la OSPF la EIGRP. Acesta este un pic mai complicat:

klgr-gw1(config)#router eigrp 1
klgr-gw1(config-router)#redistribuire ospf 1 metric 100000 20 255 1 1500

Fără a specifica metrica (acest set lung de numere), comanda va fi executată, dar redistribuirea nu va avea loc.

Rutele importate primesc o etichetă EX în tabelul de rutare și o distanță administrativă de 170, în loc de 90 pentru cele interne:

klgr-gw2#sh traseu ip

Poarta de ultimă instanță nu este setată

172.16.0.0/16 este subrețea variabil, 30 de subrețele, 4 măști
D EX 172.16.0.0/24 [170 /33280] prin 172.16.2.37, 00:00:07, FastEthernet0/0
D EX 172.16.1.0/24 prin 172.16.2.37, 00:00:07, FastEthernet0/0
D EX 172.16.2.0/30 prin 172.16.2.37, 00:00:07, FastEthernet0/0
D EX 172.16.2.4/30 prin 172.16.2.37, 00:00:07, FastEthernet0/0
D EX 172.16.2.16/30 prin 172.16.2.37, 00:00:07, FastEthernet0/0
D 172.16.2.32/30 [ 90 /30720] prin 172.16.2.37, 00:38:59, FastEthernet0/0
C 172.16.2.36/30 este conectat direct, FastEthernet0/0
D 172.16.2.40/30 prin 172.16.2.37, 00:38:59, FastEthernet0/0
prin 172.16.2.46, 00:38:59, FastEthernet0/1
….

Așa se face, s-ar părea simplu, dar simplitatea este superficială – redistribuirea este plină de multe momente subtile și neplăcute când se adaugă cel puțin o legătură redundantă între două domenii diferite.
Sfat general - încercați să evitați redistribuirea dacă este posibil. Principala regulă a vieții funcționează aici - cu cât mai simplu, cu atât mai bine.

Ruta implicită

Acum este momentul să vă verificați accesul la internet. Funcționează bine din Moscova, dar dacă verificați, de exemplu, din Sankt Petersburg (rețineți că am șters toate rutele statice):

PC>ping linkmeup.ru

Ping 192.0.2.2 cu 32 de octeți de date:

Răspuns de la 172.16.2.5: Gazda destinație inaccesibilă.
Răspuns de la 172.16.2.5: Gazda destinație inaccesibilă.
Răspuns de la 172.16.2.5: Gazda destinație inaccesibilă.

Statistici ping pentru 192.0.2.2:
Pachete: trimise = 4, primite = 0, pierdute = 4 (100% pierdere),

Acest lucru se datorează faptului că nici spb-ozerki-gw1, nici spb-vsl-gw1, nici nimeni altcineva din rețeaua noastră nu știe despre ruta implicită, cu excepția msk-arbat-gw1, pe care este configurată static.
Pentru a corecta această situație, trebuie doar să dăm o comandă la Moscova:

msk-arbat-gw1(config)#router ospf 1
msk-arbat-gw1(config-router)#default-information provin

După aceasta, informații despre locul unde se află poarta de ultimă instanță avalanșă în rețea.

Internetul este acum disponibil:

PC>tracert linkmeup.ru

Urmărirea rutei către 192.0.2.2 pe maximum 30 de hop:

1 3 ms 3 ms 3 ms 172.16.17.1
2 4 ms 5 ms 12 ms 172.16.2.5
3 14 ms 20 ms 9 ms 172.16.2.1
4 17 ms 17 ms 19 ms 198.51.100.1
5 22 ms 23 ms 19 ms 192.0.2.2

Comenzi utile pentru depanare

1) Lista vecinilor si starea comunicarii cu acestia se apeleaza prin comanda arata ip ospf vecin

msk-arbat-gw1:

Neighbor ID Pri State Dead Time Address Interfață
172.16.255.32 1 FULL/DROTHER 00:00:33 172.16.2.2 FastEthernet0/1.4
172.16.255.48 1 FULL/DR 00:00:34 172.16.2.18 FastEthernet0/1.5
172.16.255.64 1 FULL/DR 00:00:33 172.16.2.34 FastEthernet0/1.7
172.16.255.80 1 FULL/DR 00:00:33 172.16.2.130 FastEthernet0/1.8
172.16.255.112 1 FULL/DR 00:00:33 172.16.2.197 FastEthernet1/0.911

2) Sau pentru EIGRP: arata vecinii ip eigrp

IP-EIGRP vecini pentru procesul 1
H Adresă Interfață Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 172.16.2.38 Fa0/1 12 00:04:51 40 1000 0 54
1 172.16.2.42 Fa0/0 13 00:04:51 40 1000 0 58

3) Folosind comanda arata protocoale ip Puteți vizualiza informații despre rularea protocoalelor de rutare dinamică și relațiile acestora.

Klgr-balt-gw1:

Protocolul de rutare este „EIGRP 1”

Rețelele implicite semnalate în actualizările trimise
Rețelele implicite acceptate de la actualizările primite
Greutatea metrică EIGRP K1=1, K2=0, K3=1, K4=0, K5=0
Număr maxim de salturi EIGRP 100
Varianta maximă a metricii EIGRP 1
Redistribuire: EIGRP 1, OSPF 1
Rezumatul automat al rețelei este în vigoare
Rezumare automată a adreselor:
Calea maximă: 4
Rutare pentru rețele:
172.16.0.0

172.16.2.42 90 4
172.16.2.38 90 4
Distanta: interior 90 extern 170

Protocolul de rutare este „OSPF 1”
Lista de filtre de actualizare de ieșire pentru toate interfețele nu este setată
Lista de filtre de actualizare primită pentru toate interfețele nu este setată
ID router 172.16.255.64
Este un router de limită de sistem autonom
Redistribuirea rutelor externe din,
EIGRP 1
Numărul de zone din acest router este 1. 1 normal 0 stub 0 nssa
Calea maximă: 4
Rutare pentru rețele:
172.16.2.32 0.0.0.3 zona 0
Surse de informații despre rutare:
Distanța gateway Ultima actualizare
172.16.255.64 110 00:00:23
Distanță: (implicit este 110)

4) Pentru a depana și înțelege funcționarea protocoalelor, va fi util să folosiți următoarele comenzi:
depanați evenimentele IP OSPF
depanare ip OSPF adj
depanați pachetele EIGRP

Încercați să încercați diferite interfețe și vedeți ce se întâmplă în depanare, ce mesaje zboară.

Problema nr. 7
În sfârșit, o problemă complexă.
La ultima întâlnire a Lift mi Up, s-a decis ca și rețeaua Kaliningrad să fie transferată la OSPF.
Tranziția trebuie finalizată fără întreruperea conexiunii. S-a decis că cea mai bună opțiune ar fi să ridicați OSPF pe trei routere Kaliningrad în paralel cu EIGRP și, după ce a verificat că toate informațiile despre rutele Kaliningrad s-au răspândit în restul rețelei și invers, să dezactivați EIGRP. pentru logo-ul site-ului. Adaugă etichete

Protocoalele de rutare dinamică sunt concepute pentru a automatiza procesul de construire a tabelelor de rutare pentru routere. Principiul utilizării lor este destul de simplu: routerele, folosind ordinea stabilită de protocol, trimit anumite informații din tabelul lor de rutare către alții și își ajustează tabelul pe baza datelor primite de la alții.

Această metodă de construire și întreținere a tabelelor de rutare simplifică foarte mult sarcina de administrare a rețelelor care pot suferi modificări (de exemplu, extindere) sau în situațiile în care orice routere și/sau subrețele eșuează.

Trebuie remarcat faptul că utilizarea protocoalelor de rutare dinamică nu elimină posibilitatea introducerii „manuale” a datelor în tabelele de ruter. Intrările realizate în acest fel se numesc statice, iar intrările obținute ca urmare a schimbului de informații între routere se numesc dinamice. Orice tabel de rutare are întotdeauna cel puțin o intrare statică - ruta implicită.

Protocoalele moderne de rutare sunt împărțite în două grupuri: protocoale vector-distanță și protocoale link-state.

În protocoalele vector-distanță, fiecare router trimite o listă de adrese ale rețelelor disponibile pentru el („vectori”), fiecare dintre acestea fiind asociată cu un parametru „distanță” (de exemplu, numărul de routere către această rețea, o valoare pe baza performanței legăturilor etc.). Principalul reprezentant al protocoalelor din acest grup este protocolul RIP (Routing Information Protocol).

Protocoalele de stare de legătură se bazează pe un principiu diferit. Routerele fac schimb de informații topologice între ele despre conexiunile în rețea: ce routere sunt conectate la ce rețele. Ca rezultat, fiecare router are o imagine completă a structurii rețelei (și această vedere va fi aceeași pentru toată lumea), pe baza căreia își calculează propriul tabel de rutare optimă. Protocolul pentru acest grup este OSPF (Open Shortest Path First).

protocol RIP.

Protocolul RIP (Routing Information Protocol) este cel mai important protocol simplu rutare dinamică. Aparține protocoalelor vector-distanță.

Sub un vector, RIP definește adresele IP ale rețelelor, iar distanța este măsurată în hopuri („hops”) – numărul de routere prin care trebuie să treacă un pachet pentru a ajunge la o rețea specificată. Trebuie remarcat faptul că valoarea distanței maxime pentru protocolul RIP este 15, valoarea 16 este interpretată într-un mod special „rețea inaccesabilă”. Acest lucru a determinat principalul dezavantaj al protocolului - se dovedește a fi inaplicabil în rețelele mari unde sunt posibile rute care depășesc 15 hop.

RIP versiunea 1 are o serie de dezavantaje semnificative pentru utilizare practică. Problemele importante includ următoarele:

• Estimatăka distanțeținând cont doar de numărul de tranziții. Protocolul RIP nu ține cont de performanța reală a canalelor de comunicație, care pot fi ineficiente în rețelele eterogene, de ex. rețele care combină canale de comunicație diferite dispozitive,performanță care utilizează diferite tehnologii de rețea.
• Problema convergenței lente. Routere care utilizează protocolul RIP. Ei trimit informații de rutare la fiecare 30 de secunde, iar munca lor nu este sincronizată. Într-o situație în care un anumit router detectează că o rețea a devenit indisponibilă, atunci în cel mai rău caz (dacă problema a fost identificată imediat după următoarea difuzare) își va anunța vecinii despre acest lucru după 30 de secunde. Pentru routerele vecine totul se va întâmpla la fel. Aceasta înseamnă că informațiile despre indisponibilitatea unei rețele pot dura mult timp să se răspândească la routere, evident, rețeaua va fi într-o stare instabilă.
• Tabelele de rutare de difuzare. Protocolul RIP presupunea inițial că routerele trimit informații în modul de difuzare. Aceasta înseamnă că pachetul trimis este forțat să fie primit și analizat la nivel de legătură, rețea și transport de către toate computerele din rețeaua către care este trimis.

Aceste probleme sunt parțial rezolvate în versiunea 2 (RIP2).

protocol OSPF

OSPF (Routing (Open Shortest Path First)) este un protocol de rutare dinamic mai nou și este un protocol de stare de legătură.

Funcționarea protocolului OSPF se bazează pe utilizarea unei singure baze de date de către toate routerele, care descrie cum și cu ce rețele este conectat fiecare router. Descrierea fiecărei conexiuni, routere de comunicație
Ei îi adaugă o metrică - o valoare care caracterizează „calitatea” canalului. De exemplu, rețelele Ethernet de 100 Mbps folosesc o valoare de 1, iar conexiunile dial-up de 56 Kbps folosesc o valoare de 1785. Acest lucru permite routerelor OSPF (spre deosebire de RIP, unde toate canalele sunt egale) să ia în considerare lățimea de bandă reală și să identifice rute eficiente. O caracteristică importantă a protocolului OSPF este că folosește multicast mai degrabă decât broadcast.

Aceste caracteristici, cum ar fi multicast în loc de difuzare, fără restricții privind lungimea rutei, schimbul periodic de mesaje de stare scurte și luarea în considerare a „calității” canalelor de comunicație permit utilizarea OSPF în rețele mari. Cu toate acestea, o astfel de utilizare poate crea o problemă serioasă - o cantitate mare de informații de rutare care circulă în rețea și o creștere a tabelelor de rutare. Și întrucât algoritmul pentru găsirea rutelor eficiente este destul de complex în ceea ce privește volumul de calcul, rețelele mari pot necesita routere de înaltă performanță și, prin urmare, costisitoare. Prin urmare, capacitatea de a construi tabele de rutare eficiente poate fi considerată atât un avantaj, cât și un dezavantaj al protocolului OSPF.

Asadar, haideti sa începem.

Articole și videoclipuri despre cum să configurați munții OSPF. Mult mai puține descrieri ale principiilor de funcționare. În general, lucrul aici este că OSPF poate fi configurat pur și simplu conform manualelor, fără să știi măcar despre algoritmi SPF și LSA-uri de neînțeles. Și totul va funcționa și chiar, cel mai probabil, va funcționa perfect - pentru asta a fost conceput. Adică, nu este ca în cazul vlan-urilor, unde trebuia să cunoști teoria până la formatul antetului.
Dar ceea ce distinge un inginer de un tip IT este că înțelege de ce rețeaua lui funcționează așa cum o face și știe, nu mai rău decât OSPF însuși, care rută va fi aleasă de protocol.
În cadrul articolului, care în acest moment are deja 8.000 de caractere, nu ne vom putea scufunda în profunzimea teoriei, dar vom lua în considerare punctele fundamentale.
Este foarte simplu și clar, apropo, este scris despre OSPF pe xgu.ru sau în Wikipedia în engleză.
Deci, OSPFv2 funcționează pe deasupra IP și, în special, este proiectat numai pentru IPv4 (OSPFv3 nu depinde de protocoalele de nivel 3 și, prin urmare, poate funcționa cu IPv6).

Să ne uităm la cum funcționează folosind exemplul acestei rețele simplificate:

Pentru început, trebuie spus că pentru ca o relație de prietenie (relație de adiacență) să se dezvolte între routere, trebuie îndeplinite următoarele condiții:

1) aceleași setări trebuie configurate în OSPF Salut Interval pe acele routere care sunt conectate între ele. În mod implicit, este de 10 secunde în rețelele de difuzare, cum ar fi Ethernet. Acesta este un fel de mesaj KeepAlive. Adică, la fiecare 10 secunde, fiecare router trimite un pachet Hello vecinului său pentru a spune: „Hei, sunt în viață”.
2) Trebuie să fie la fel Interval mort pe ei. De obicei, acestea sunt 4 intervale Hello - 40 de secunde. Dacă nu se primește niciun salut de la vecin în acest timp, atunci acesta este considerat inaccesibil și PANIC începe procesul de reconstruire a bazei de date locale și de trimitere a actualizărilor tuturor vecinilor.
3) Interfețele conectate între ele trebuie să fie în o subrețea,
4) OSPF vă permite să reduceți sarcina CPU-ului routerelor prin împărțirea sistemului autonom în zone. Deci aici este numerele zonei trebuie de asemenea să se potrivească
5) Fiecare router care participă la procesul OSPF are propriul său unic identificator - ID router. Dacă nu aveți grijă de el, routerul îl va selecta automat pe baza informațiilor despre interfețele conectate (cea mai mare adresă este selectată dintre interfețele active la momentul începerii procesului OSPF). Dar, din nou, un inginer bun are totul sub control, așa că de obicei este creată o interfață Loopback, căreia i se atribuie o adresă cu o mască /32 și aceasta este ceea ce este atribuit ID-ului routerului. Acest lucru poate fi convenabil pentru întreținere și depanare.
6) Dimensiunea MTU trebuie să se potrivească

1) Calm. Stare OSPF - JOS
În acest scurt moment, nu se întâmplă nimic în rețea - toată lumea tace.

2) Vântul se ridică: routerul trimite pachete Hello la adresa multicast 224.0.0.5 de la toate interfețele pe care rulează OSPF. TTL-ul unor astfel de mesaje este unul, deci doar routerele situate în același segment de rețea le vor primi. R1 intră în stare INIT.

Pachetele conțin următoarele informații:

• ID router
• Salut Interval
• Interval mort
• Vecini
• Mască de rețea
• ID zona
• Prioritate router
• Adresele routerelor DR și BDR
• Parola de autentificare

Momentan suntem interesați de primele patru, sau mai precis, doar Router ID și Neighbours.
Mesajul Salut de la routerul R1 poartă ID-ul său de router și nu conține vecini, deoarece nu îi are încă.
După primirea acestui mesaj multicast, routerul R2 adaugă R1 la tabelul său vecin (dacă toți parametrii necesari se potrivesc).

Și trimite un nou mesaj Salut către R1 ca unicast, care conține ID-ul routerului acestui router, iar lista Neigbors listează toți vecinii săi. Printre alți vecini din această listă există Router ID R1, adică R2 îl consideră deja un vecin.

3) Prietenia. Când R1 primește acest mesaj Salut de la R2, derulează prin lista de vecini și își găsește propriul ID Router în ea, adaugă R2 la lista de vecini.

Acum R1 și R2 sunt vecini reciproci unul cu celălalt - asta înseamnă că a fost stabilită o relație de adiacență între ei și routerul R1 intră în stare DOUĂ SENSE.

Sfaturi generale pentru toate sarcinile:

Chiar dacă nu știți imediat răspunsul și soluția, încercați să vă gândiți la ce se referă starea problemei:
- Ce caracteristici și setări de protocol?
- Aceste setări sunt globale sau legate de o anumită interfață?
Dacă nu cunoașteți sau ați uitat comanda, astfel de reflecții vă vor conduce cel mai probabil către contextul corect, unde puteți pur și simplu să ghiciți sau să vă amintiți cum să configurați ceea ce este necesar în sarcină folosind un indiciu pe linia de comandă.
Încercați să gândiți în acest fel înainte de a merge pe Google sau pe un site care caută comenzi.

Într-o rețea reală, atunci când alegeți gama de subrețele promovate, trebuie să vă ghidați după reglementări și nevoi imediate.

Înainte de a trece la testarea legăturilor de rezervă și a vitezei, haideți să facem încă un lucru util.
Dacă am avea ocazia să captăm trafic pe interfața FE0/0.2 msk-arbat-gw1, care se confruntă cu serverele, atunci am vedea că mesajele Hello zboară în necunoscut la fiecare 10 secunde. Nu există nimeni cu care să răspundă Bună ziua, nu există cu cine să stabilească relații de vecinătate, așa că nu are rost să încerci să trimiți mesaje de aici.
Dezactivarea este foarte simplă:

msk-arbat-gw1(config)#router OSPF 1
msk-arbat-gw1(config-router)#interfață-pasivă fastEthernet 0/0.2

Această comandă trebuie dată pentru toate interfețele care cu siguranță nu au vecini OSPF (inclusiv cele către Internet).
Drept urmare, veți avea o imagine ca aceasta:

*Nu-mi pot imagina cum nu te-ai încurcat încă*

În plus, această comandă crește securitatea - nimeni din această rețea nu se va preface a fi un router și nu va încerca să ne spargă complet.

Acum să trecem la partea cea mai interesantă - testarea.
Nu este nimic complicat în configurarea OSPF pe toate routerele din Siberian Ring - o puteți face singur.
Și după aceea, imaginea ar trebui să fie după cum urmează:

msk-arbat-gw1#sh ip OSPF vecin

172.16.255.32 1 FULL/DR 00:00:31 172.16.2.2 FastEthernet0/1.4
172.16.255.48 1 FULL/DR 00:00:31 172.16.2.18 FastEthernet0/1.5
172.16.255.80 1 FULL/BDR 00:00:36 172.16.2.130 FastEthernet0/1.8
172.16.255.112 1 FULL/BDR 00:00:37 172.16.2.197 FastEthernet1/0.911

Sankt Petersburg, Kemerovo, Krasnoyarsk și Vladivostok sunt conectate direct.

msk-arbat-gw1#sh traseu ip

172.16.0.0/16 este subrețea variabil, 25 de subrețele, 6 măști



S 172.16.2.4/30 prin 172.16.2.2



O 172.16.2.160/30 prin 172.16.2.130, 00:05:53, FastEthernet0/1.8
O 172.16.2.192/30 prin 172.16.2.197, 00:04:18, FastEthernet1/0.911





S 172.16.16.0/21 prin 172.16.2.2
S 172.16.24.0/22 ​​prin 172.16.2.18
O 172.16.24.0/24 prin 172.16.2.18, 00:24:03, FastEthernet0/1.5
O 172.16.128.0/24 prin 172.16.2.130, 00:07:18, FastEthernet0/1.8
O 172.16.129.0/26 prin 172.16.2.130, 00:07:18, FastEthernet0/1.8

O 172.16.255.32/32 prin 172.16.2.2, 00:24:03, FastEthernet0/1.4
O 172.16.255.48/32 prin 172.16.2.18, 00:24:03, FastEthernet0/1.5
O 172.16.255.80/32 prin 172.16.2.130, 00:07:18, FastEthernet0/1.8
O 172.16.255.96/32 prin 172.16.2.130, 00:04:18, FastEthernet0/1.8
prin 172.16.2.197, 00:04:18, FastEthernet1/0.911
O 172.16.255.112/32 prin 172.16.2.197, 00:04:28, FastEthernet1/0.911

Toată lumea știe totul despre toată lumea.
Ce rută este transportat de la Moscova la Krasnoyarsk? Tabelul arată că krs-stolbi-gw1 este conectat direct și același lucru poate fi văzut din urmă:

1 172.16.2.130 35 msec 8 msec 5 ms

Acum distrugem interfața dintre Moscova și Krasnoyarsk și vedem cât timp durează restabilirea conexiunii.
Nu trec nici măcar 5 secunde până când toți ruterele au aflat despre incident și și-au recalculat tabelele de rutare:

msk-arbat-gw1(config-subif)#do sh ip ro 172.16.128.0

Cunoscut prin „OSPF 1”, distanta 110, metrica 4, tip intra zona
Ultima actualizare de la 172.16.2.197 pe FastEthernet1/0.911, acum 00:00:53
Blocuri descriptori de rutare:
* 172.16.2.197, de la 172.16.255.80, 00:00:53 în urmă, prin FastEthernet1/0.911
Valoarea rutei este 4, numărul de cotă de trafic este 1

Vld-gw1#sh ip ruta 172.16.128.0
Intrare de rutare pentru 172.16.128.0/24
Cunoscut prin „OSPF 1”, distanta 110, metrica 3, tip intra zona
Ultima actualizare de la 172.16.2.193 pe FastEthernet1/0, acum 00:01:57
Blocuri descriptori de rutare:
* 172.16.2.193, de la 172.16.255.80, 00:01:57 în urmă, prin FastEthernet1/0
Valoarea rutei este 3, numărul de cotă de trafic este 1

Msk-arbat-gw1#traceroute 172.16.128.1
Tastați secvența de evacuare la avort.
Urmărirea traseului la 172.16.128.1

1 172.16.2.197 4 msec 10 msec 10 msec
2 172.16.2.193 8 msec 11 msec 15 ms
3 172.16.2.161 15 msec 13 msec 6 ms

Adică, acum traficul ajunge la Krasnoyarsk în acest fel:

De îndată ce ridicați legătura, routerele comunică din nou, își schimbă bazele de date, recalculează cele mai scurte căi și le introduc în tabelul de rutare.
Videoclipul face totul mai clar. Vă recomand familiariza.

Ca orice protocol bun, OSPF acceptă autentificare - doi vecini pot verifica autenticitatea mesajelor OSPF primite înainte de a stabili relații de adiacență. Vă lăsăm să studiați pe cont propriu - este destul de simplu.

EIGRP

Acum să trecem la un alt protocol foarte important.

Deci, ce este bun la EIGRP?
- usor de configurat
- trecere rapidă la calculate dinainte traseu alternativ
- necesită mai puține resurse de router (comparativ cu OSPF)
- rezumarea rutelor pe orice router (în OSPF doar pe ABR\ASBR)
- echilibrarea traficului pe rute inegale (OSPF doar pe rute egale)

Am decis să traducem una dintre intrările de blog ale lui Ivan Pepelnyak, care abordează o serie de mituri populare despre EIGRP:
- „EIGRP este un protocol de rutare hibrid.” Dacă îmi amintesc bine, acest lucru a început cu prima prezentare a EIGRP cu mulți ani în urmă și este de obicei înțeles ca „EIGRP a luat cele mai bune dintre protocoalele de stare de legătură și de vector de distanță”. Acest lucru nu este absolut adevărat. EIGRP nu are caracteristici distinctive ale stării legăturii. Ar fi corect să spunem „EIGRP este un protocol avansat de rutare cu vector de distanță”.

- „EIGRP este un protocol de vector de distanță.” Nu e rău, dar nici în întregime adevărat. EIGRP diferă de alte DV-uri prin modul în care gestionează rutele orfane (sau rutele cu valori crescătoare). Toate celelalte protocoale așteaptă pasiv actualizările de la un vecin (unele, cum ar fi RIP, chiar blochează ruta pentru a preveni buclele de rutare), în timp ce EIGRP este mai activ și solicită informații în sine.

- „EIGRP este dificil de implementat și întreținut.” Neadevarat. La un moment dat, EIGRP în rețelele mari cu legături de viteză redusă era dificil de implementat corect, dar numai până când au fost introduse routerele stub. Cu ele (precum și câteva corecții ale algoritmului DUAL), este aproape mai rău decât OSPF.

- „La fel ca protocoalele LS, EIGRP menține un tabel cu topologia rutelor care sunt schimbate.” Este uimitor cât de greșit este asta. EIGRP habar nu are deloc ce se află dincolo de vecinii săi imediati, în timp ce protocoalele LS cunosc exact topologia întregii zone la care sunt conectate.

- „EIGRP este un protocol DV care acționează ca LS.” Bună încercare, dar totuși complet greșită. Protocoalele LS construiesc un tabel de rutare parcurgând următorii pași:
- fiecare router descrie rețeaua pe baza informațiilor disponibile pe plan local (legăturile sale, subrețelele în care se află, vecinii pe care îi vede) printr-un pachet (sau mai multe) numit LSA (în OSPF) sau LSP (IS-IS)
- LSA-urile sunt propagate în întreaga rețea. Fiecare router trebuie să primească fiecare LSA creat în rețeaua sa. Informațiile primite de la LSA sunt introduse în tabelul de topologie.
- Fiecare router își analizează în mod independent tabelul de topologie și rulează algoritmul SPF pentru a calcula cele mai bune rute către fiecare dintre celelalte routere
Comportamentul EIGRP nici măcar nu se apropie de acești pași, așa că de ce naiba „acţionează ca LS” nu este clar.

Singurul lucru pe care EIGRP îl face este să stocheze informațiile primite de la un vecin (RIP uită imediat ce nu poate fi folosit în acest moment). În acest sens, este similar cu BGP, care stochează tot într-un tabel BGP și alege de acolo cea mai bună rută. Tabelul de topologie (conținând toate informațiile primite de la vecini) oferă EIGRP un avantaj față de RIP - poate conține informații despre o rută de rezervă (neutilizată în prezent).

Acum puțin mai aproape de teoria muncii:

Fiecare proces EIGRP menține 3 tabele:
- Un tabel de vecini, care conține informații despre „vecini”, adică alte routere conectate direct la cel actual și care participă la schimbul de rute. Îl puteți vizualiza folosind comanda arata vecinii ip eigrp
- Tabel de topologie de rețea, care conține informații de rutare primite de la vecini. Să privim ca o echipă arată topologia ip eigrp
- Tabelul de rutare, pe baza căruia routerul ia decizii cu privire la redirecționarea pachetelor. Vizualizare prin arata ruta ip

Metrici.
Pentru a evalua calitatea unei anumite rute, protocoalele de rutare folosesc un anumit număr care reflectă diferitele sale caracteristici sau un set de caracteristici - o metrică. Caracteristicile luate în considerare pot fi diferite - de la numărul de routere de pe o rută dată până la media aritmetică a sarcinii pe toate interfețele de-a lungul rutei. În ceea ce privește metrica EIGRP, pentru a-l cita pe Jeremy Cioara: „Am avut impresia că creatorii EIGRP, aruncând o privire critică asupra creației lor, au decis că totul a fost prea simplu și a funcționat bine. Și apoi au venit cu o formulă metrică, astfel încât toată lumea să spună „WOW, asta este cu adevărat complicat și arată profesional”. Consultați formula completă pentru calcularea metricii EIGRP: (K1 * bw + (K2 * bw) / (256 - sarcină) + K3 * întârziere) * (K5 / (fiabilitate + K4)), în care:
- bw nu este doar lățime de bandă, ci (10000000/cea mai mică lățime de bandă de-a lungul traseului în kilobiți) * 256
- întârzierea nu este doar o întârziere, ci suma tuturor întârzierilor pe drum spre zeci de microsecunde* 256 (întârzierea în comenzile arată interfața, show ip eigrp topology și altele este afișată în microsecunde!)
- K1-K5 sunt coeficienți care servesc pentru a se asigura că unul sau altul parametru este „inclus” în formulă.

Infricosator? ar fi dacă totul ar funcționa așa cum este scris. De fapt, din toți cei 4 termeni posibili ai formulei, doar doi sunt utilizați implicit: bw și întârziere (coeficienții K1 și K3 = 1, restul sunt zero), ceea ce o simplifică foarte mult - pur și simplu adunăm aceste două numere (în timp ce nu uitând că sunt încă calculate după formule proprii). Este important să rețineți următoarele: metrica se calculează în funcție de cel mai slab indicator de debit de-a lungul întregii lungimi a rutei.

Un lucru interesant s-a întâmplat cu MTU: destul de des puteți găsi informații că MTU are legătură cu metrica EIGRP. Într-adevăr, valorile MTU sunt transmise la schimbul de rute. Dar, după cum putem vedea din formula completă, nu se menționează MTU. Cert este că acest indicator este luat în considerare în cazuri destul de specifice: de exemplu, dacă un router trebuie să renunțe la una dintre rutele care sunt echivalente în alte caracteristici, o va alege pe cea cu un MTU mai mic. Deși, nu totul este atât de simplu (vezi comentarii).

Să definim termenii folosiți în EIGRP. Fiecare rută din EIGRP este caracterizată de două numere: Distanța fezabilă și Distanța Anunțată (în loc de Distanța Anunțată, uneori puteți vedea Distanța raportată, acesta este același lucru). Fiecare dintre aceste numere reprezintă o metrică sau un cost (cu atât mai mult, cu atât mai rău) al unei anumite rute din diferite puncte de măsurare: FD este „de la mine la destinație”, iar AD este „de la vecinul care mi-a spus despre această rută până la numirile de la loc”. Răspunsul la întrebarea logică „De ce trebuie să știm costul de la un vecin dacă acesta este deja inclus în FD” este puțin mai mic (deocamdată poți să te oprești și să-ți faci creierul singur, dacă vrei).

Pentru fiecare subrețea de care cunoaște EIGRP, pe fiecare router există un router Succesor din rândul vecinilor, prin care trece cea mai bună (cu o metrică mai mică), conform protocolului, ruta către această subrețea. În plus, o subrețea poate avea și una sau mai multe rute de rezervă (routerul vecin prin care trece o astfel de rută se numește succesor fezabil). EIGRP este singurul protocol de rutare care își amintește rutele de rezervă (OSPF le are, dar sunt conținute, ca să spunem așa, în „forma brută” în tabelul de topologie; ele trebuie încă procesate de algoritmul SPF), ceea ce îi conferă un avantaj de performanță: de îndată ce protocolul stabilește că ruta principală (prin succesor) este indisponibilă, trece imediat la ruta de rezervă. Pentru ca un router să devină un succesor fezabil pentru o rută, AD sa trebuie să fie mai mic decât succesorul FD al acestei rute (de aceea trebuie să cunoaștem AD). Această regulă este folosită pentru a evita buclele de rutare.

Te-a suflat paragraful anterior? Materialul este dificil, așa că voi folosi din nou un exemplu. Avem aceasta retea:

Din punctul de vedere al lui R1, R2 este Succesorul pentru subrețeaua 192.168.2.0/24. Pentru a deveni un FS pentru această subrețea, R4 necesită ca AD să fie mai mic decât FD pentru această rută. Avem FD ((10000000/1544)*256)+(2100*256) =2195456, R4 are AD (din punctul lui de vedere este FD, adică cât îl costă să ajungă în această rețea) = (( 10000000/100000 )*256)+(100*256)=51200. Totul converge, AD-ul R4 este mai mic decât FD-ul rutei, devine FS. *apoi creierul spune: „BDASH”*. Acum ne uităm la R3 - el își anunță rețeaua 192.168.1.0/24 vecinului său R1, care, la rândul său, le spune vecinilor săi R2 și R4 despre asta. R4 nu știe că R2 știe despre această subrețea și decide să-i spună. R2 transmite informația că are acces prin R4 către subrețeaua 192.168.1.0/24 în continuare către R1. R1 se uită cu strictețe la FD-ul rutei și AD, cu care se laudă R2 (care, după cum este ușor de înțeles din diagramă, va fi în mod clar mai mare decât FD, deoarece îl include și pe el) și îl alungă pentru a nu interferează cu tot felul de prostii. Această situație este destul de puțin probabilă, dar poate apărea în anumite circumstanțe, de exemplu, atunci când mecanismul cu orizontul împărțit este dezactivat. Și acum la o situație mai probabilă: imaginați-vă că R4 este conectat la rețeaua 192.168.2.0/24 nu prin FastEthernet, ci printr-un modem de 56k (întârzierea pentru dialup este de 20.000 usec), în consecință, îl costă ((10000000/56) )*256 )+(2000*256)= 46226176. Acesta este mai mult decât FD pentru această rută, deci R4 nu va deveni un succesor fezabil. Dar asta nu înseamnă că EIGRP nu va folosi deloc această rută. Va dura mai mult pentru a trece la el (mai multe despre asta mai târziu).

Cartier

Routerele nu vorbesc despre rute oricui - trebuie să stabilească relații de adiacență înainte de a putea începe să schimbe informații. După pornirea procesului cu comanda router eigrp, indicând numărul sistemului autonom, noi, cu comanda de rețea, spunem ce interfețe vor participa și, în același timp, informații despre ce rețele dorim să distribuim. Imediat, pachetele hello încep să fie trimise prin aceste interfețe la adresa multicast 224.0.0.10 (în mod implicit la fiecare 5 secunde pentru ethernet). Toate routerele cu EIGRP activat primesc aceste pachete, apoi fiecare router care primește face următoarele:
- verifică adresa expeditorului pachetului hello cu adresa interfeței de la care a fost primit pachetul și se asigură că sunt din aceeași subrețea
- compară valorile coeficienților K obținuți din pachet (cu alte cuvinte, care variabile sunt utilizate în calcularea metricii) cu propriile sale. Este clar că, dacă diferă, atunci valorile pentru rute vor fi calculate în funcție de reguli diferite, ceea ce este inacceptabil
- verifică numărul sistemului autonom
- opțional: dacă autentificarea este configurată, verifică consistența tipului și a cheilor acestuia.

Dacă destinatarul este mulțumit de toate, îl adaugă pe expeditor pe lista vecinilor săi și îi trimite (deja în Unicast) un pachet de actualizare, care conține o listă cu toate rutele cunoscute de el (aka full-update). Expeditorul, după ce a primit un astfel de pachet, face la rândul său același lucru. Pentru schimbul de rute, EIGRP folosește Reliable Transport Protocol (RTP, care nu trebuie confundat cu Real-time Transport Protocol, care este utilizat în telefonia IP), care implică confirmarea livrării, astfel încât fiecare dintre routere, după ce a primit un pachet de actualizare, răspunde cu un pachet de confirmare (abreviere de la confirmare - confirmare). Deci, relația de vecinătate a fost stabilită, routerele au învățat unul de la celălalt informații complete despre rute, ce urmează? Apoi, ei vor continua să trimită pachete de salut multicast pentru a confirma că sunt conectate și, dacă topologia se modifică, vor actualiza pachetele care conțin doar informații despre modificări (actualizare parțială).

Acum să revenim la schema anterioară cu modemul.

R2 din anumite motive a pierdut contactul cu 192.168.2.0/24. Nu are rute de rezervă către această subrețea (adică, fără FS). La fel ca orice router responsabil EIGRP, vrea să restabilească conectivitatea. Pentru a face acest lucru, el începe să trimită mesaje speciale (pachete de interogare) tuturor vecinilor săi, care, la rândul lor, negăsind ruta dorită în ei înșiși, întreabă toți vecinii lor și așa mai departe. Când valul de solicitări ajunge la R4, el spune „stai puțin, am o rută către această subrețea! Rău, dar măcar ceva. Toți au uitat de el, dar îmi amintesc.” El împachetează toate acestea într-un pachet de răspuns și îl trimite vecinului de la care a primit cererea (interogare) și mai departe de-a lungul lanțului. Desigur, toate acestea necesită mai mult timp decât trecerea la Feasible Successor, dar în cele din urmă obținem comunicare cu subrețeaua.

Și acum este un moment periculos: poate ați observat deja și ați devenit precaut după ce ați citit despre acest e-mailing de la fani. Eșecul unei interfețe provoacă ceva similar cu o furtună de difuzare în rețea (nu la o asemenea scară, desigur, dar totuși), și cu cât sunt mai multe routere, cu atât mai multe resurse vor fi cheltuite pentru toate aceste solicitări și răspunsuri. Dar asta nu e chiar atât de rău. O situație mai gravă este posibilă: imaginați-vă că routerele prezentate în imagine sunt doar o parte dintr-o rețea mare și distribuită, de exemplu. unele pot fi situate la multe mii de kilometri de R2-ul nostru, pe canale proaste etc. Deci, problema este că, după ce a trimis o interogare unui vecin, routerul trebuie să aștepte un răspuns de la acesta. Nu contează care este răspunsul, dar trebuie să vină. Chiar dacă routerul deja a primit un răspuns pozitiv, ca și în cazul nostru, nu poate pune în funcțiune această rută până nu așteaptă un răspuns la toate solicitările sale. Și poate că mai sunt cereri undeva în Alaska. Această stare de rută se numește blocat-în-activ. Aici trebuie să ne familiarizăm cu termenii care reflectă starea rutei în EIGRP: rută activ\pasivă. De obicei sunt înșelătoare. Bunul simț dictează că activ înseamnă că traseul este „activ”, activat, rulant. Totuși, aici totul este invers: pasiv înseamnă „totul este în regulă”, iar starea activă înseamnă că această subrețea este indisponibilă, iar routerul caută în mod activ o altă rută, trimite o interogare și așteaptă un răspuns. Deci, starea blocată în activ poate dura până la 3 minute! După expirarea acestei perioade, routerul întrerupe relația de vecin cu vecinul de la care nu poate aștepta un răspuns și poate folosi o nouă rută prin R4.

O poveste care îngheață sângele unui inginer de rețea. 3 minute de pauză nu este o glumă. Cum putem evita atacul de cord din această situație? Există două căi de ieșire: însumarea rutelor și așa-numita configurație stub.

În general, există o altă cale de ieșire și se numește filtrarea rutei. Dar acesta este un subiect atât de voluminos încât ar fi mai bine să scriem un articol separat despre el, dar avem deja o jumătate de carte de data aceasta. Deci depinde de tine.

După cum am menționat deja, în EIGRP rezumarea rutei poate fi efectuată pe orice router. Pentru a exemplifica, să ne imaginăm că subrețelele de la 192.168.0.0/24 la 192.168.7.0/24 sunt conectate la îndelungul nostru R2, care însumează foarte convenabil până la 192.168.0.0/21 (amintiți-vă matematica binară). Routerul face publicitate acestei rute rezumative și toți ceilalți știu: dacă adresa de destinație începe cu 192.168.0-7, atunci este pentru el. Ce se întâmplă dacă una dintre subrețele dispare? Routerul va trimite pachete de interogare cu adresa acestei rețele (specifică, de exemplu, 192.168.5.0/24), dar vecinii, în loc să continue trimiterea vicioasă în numele lor, vor răspunde imediat cu reluări serioase, spunând că aceasta este subrețeaua dvs., vă dați seama.

A doua opțiune este configurația stub. Figurat vorbind, stub înseamnă „sfârșitul drumului”, „fundătură” în EIGRP, adică a intra într-o subrețea care nu este conectată. direct la un astfel de router, va trebui să te întorci. Un router configurat ca stub nu va redirecționa traficul între subrețelele pe care le cunoaște din EIGRP (cu alte cuvinte, care sunt marcate cu litera D în show ip route). În plus, vecinii săi nu îi vor trimite pachete de interogare. Cea mai comună aplicație sunt topologiile hub-and-spoke, în special cu legături redundante. Să luăm această rețea: în stânga sunt filiale, în dreapta este site-ul principal, sediul principal etc. Pentru toleranță la erori, legături redundante. EIGRP rulează cu setările implicite.

Și acum „atenție, întrebare”: ce se va întâmpla dacă R1 pierde conexiunea cu R4, iar R5 pierde LAN? Traficul de la subrețeaua R1 către subrețeaua biroului principal va urma traseul R1->R5->R2 (sau R3)->R4. Va fi eficient? Nu. Nu doar subrețeaua din spatele R1 va avea de suferit, ci și subrețeaua din spatele R2 (sau R3), din cauza creșterii volumelor de trafic și a consecințelor acesteia. Pentru astfel de situații a fost inventat stub. În spatele routerelor din ramuri nu există alte routere care să conducă la alte subrețele, acesta este „sfârșitul drumului”, apoi doar înapoi. Prin urmare, cu o inimă ușoară, le putem configura ca stub-uri, ceea ce, în primul rând, ne va salva de problema cu „ruta strâmbă” conturată chiar mai sus și, în al doilea rând, de inundația de pachete de interogare în cazul pierderii rutei. .

Există diferite moduri de funcționare a unui router stub, acestea sunt setate cu comanda eigrp stub:

R1(config)#router eigrp 1
R1(config-router)#eigrp stub?
conectat Faceți publicitate rutelor conectate
leak-map Permite prefixe dinamice bazate pe leak-map
numai recepție Setați IP-EIGRP ca vecin numai recepție
redistribuit Faceți publicitate rutelor redistribuite
static Faceți publicitate rutelor statice
rezumat Faceți publicitate rute rezumate

În mod implicit, dacă lansați pur și simplu comanda eigrp stub, modurile conectat și rezumat sunt activate. Interesant este modul de recepție, în care routerul nu face reclamă la nicio rețea, ci doar ascultă ceea ce îi spun vecinii (în RIP există o comandă de interfață pasivă care face același lucru, dar în EIGRP dezactivează complet protocolul pe interfața selectată, care nu permite stabilirea unei vecinătăți).

Puncte importante din teoria EIGRP care nu au fost incluse în articol:

• Autentificarea vecinului poate fi configurată în EIGRP
• Concept de oprire grațioasă

Practica EIGRP

Lift mi Up a cumpărat o fabrică în Kaliningrad. Acolo se produc creierul lifturilor: microcircuite, software. Fabrica este foarte mare - trei puncte în jurul orașului - trei routere conectate într-un inel.

Dar ghinion - au deja EIGRP care rulează ca protocol de rutare dinamică. Mai mult, adresarea nodurilor terminale este dintr-o subrețea complet diferită - 10.0.0.0/8. Am schimbat toți ceilalți parametri (adrese de link, adrese de interfață loopback), dar câteva mii de adrese de rețea locală cu servere, imprimante, puncte de acces - nu o lucrare pentru câteva ore - au fost amânate pentru mai târziu, iar în planul IP am rezervat 172.16 subrețea pentru viitor pentru Kaliningrad .32.0/20.

În prezent folosim următoarele rețele:

Cum este configurat acest miracol? Necomplicat la prima vedere:

router eigrp 1
reţea 172.16.0.0 0.0.255.255
rețeaua 10.0.0.0

În EIGRP, masca inversă poate fi specificată, indicând astfel un domeniu mai restrâns sau nespecificat, apoi va fi selectată masca standard pentru această clasă (16 pentru clasa B - 172.16.0.0 și 8 pentru clasa 8 - 10.0.0.0)

Astfel de comenzi sunt emise pe toate routerele Autonomous System. AC este determinat de numărul din comanda router eigrp, adică în cazul nostru avem AC Nr. 1. Această cifră ar trebui să fie aceeași pe toate routerele (spre deosebire de OSPF).

Dar există o captură serioasă în EIGRP: în mod implicit, rezumarea automată a rutelor în formă de clasă este activată (în versiunile IOS până la 15).
Să comparăm tabelele de rutare pe trei routere Kaliningrad:

Rețeaua 10.0.0.1/24 este conectată la klgr-center-gw1 și el știe despre asta:

klgr-center-gw1:
10.0.0.0/8 este subrețele variabil, 2 subrețele, 2 măști
D 10.0.0.0/8 este un rezumat, 00:35:23, Null0
C 10.0.0.0/24 este conectat direct, FastEthernet1/0

Dar nu știe despre 10.0.1.0/24 și 10.0.2.0/24/

Klgr-balt-gw1 știe despre cele două rețele ale sale 10.0.1.0/24 și 10.0.2.0/24, dar a ascuns rețeaua 10.0.0.0/24 undeva.

10.0.0.0/8 este subrețele variabil, 3 subrețele, 2 măști
D 10.0.0.0/8 este un rezumat, 00:42:05, Null0
C 10.0.1.0/24 este conectat direct, FastEthernet1/1.2
C 10.0.2.0/24 este conectat direct, FastEthernet1/1.3

Amândoi au creat ruta 10.0.0.0/8 cu următoarea adresă de hop Null0.

Dar klgr-center-gw2 știe că subrețelele 10.0.0.0/8 se află în spatele ambelor interfețe WAN.

D 10.0.0.0/8 prin 172.16.2.41, 00:42:49, FastEthernet0/1
prin 172.16.2.45, 00:38:05, FastEthernet0/0

Se întâmplă ceva foarte ciudat.
Dar, dacă verificați configurația acestui router, probabil veți observa:

router eigrp 1
rețeaua 172.16.0.0
rețeaua 10.0.0.0
auto-rezumat

Însumarea automată este de vină pentru tot. Acesta este cel mai mare rău al EIGRP. Să aruncăm o privire mai atentă la ceea ce se întâmplă. klgr-center-gw1 și klgr-balt-gw1 au subrețele din 10.0.0.0/8, le însumează implicit atunci când le transmit vecinilor.
Adică, de exemplu, msk-balt-gw1 transmite nu două rețele 10.0.1.0/24 și 10.0.2.0/24, ci una generalizată: 10.0.0.0/8. Adică vecinul său va crede că în spatele msk-balt-gw1 se află toată această rețea.
Dar ce se întâmplă dacă brusc balt-gw1 primește un pachet cu destinația 10.0.50.243, despre care nu știe nimic? Pentru acest caz, este creată așa-numita rută Blackhole:
10.0.0.0/8 este un rezumat, 00:42:05, Null0
Pachetul rezultat va fi aruncat în această gaură neagră. Acest lucru se face pentru a evita buclele de rutare.
Așadar, ambele routere și-au creat propriile rute negre și au ignorat anunțurile altora. În realitate, pe o astfel de rețea, aceste trei dispozitive nu vor putea să-și pună ping unul pe celălalt până când... până când nu dezactivați rezumatul automat.

Primul lucru pe care ar trebui să-l faceți când configurați EIGRP este:

router eigrp 1
fara auto-rezumat

Pe toate dispozitivele. Și toată lumea va fi bine:

Klgr-center-gw1:

C 10.0.0.0 este conectat direct, FastEthernet1/0
D 10.0.1.0 prin 172.16.2.37, 00:03:11, FastEthernet0/0
D 10.0.2.0 prin 172.16.2.37, 00:03:11, FastEthernet0/0

klgr-balt-gw1

10.0.0.0/24 este subrețele, 3 subrețele
D 10.0.0.0 prin 172.16.2.38, 00:08:16, FastEthernet0/1
C 10.0.1.0 este conectat direct, FastEthernet1/1.2
C 10.0.2.0 este conectat direct, FastEthernet1/1.3

klgr-center-gw2:

10.0.0.0/24 este subrețele, 3 subrețele
D 10.0.0.0 prin 172.16.2.45, 00:11:50, FastEthernet0/0
D 10.0.1.0 prin 172.16.2.41, 00:11:48, FastEthernet0/1
D 10.0.2.0 prin 172.16.2.41, 00:11:48, FastEthernet0/1

Configurarea transferului rutei între diferite protocoale

Sarcina noastră este să organizăm transferul de rute între aceste protocoale: de la OSPF la EIGRP și invers, astfel încât toată lumea să cunoască ruta către orice subrețea.
Aceasta se numește redistribuire a rutei.

Pentru a-l implementa, avem nevoie de cel puțin un punct de joncțiune unde două protocoale vor fi lansate simultan. Acesta ar putea fi msk-arbat-gw1 sau klgr-balt-gw1. Să-l alegem pe al doilea.

De la EIGRP la OSPF:

klgr-gw1(config)#router ospf 1
klgr-gw1(config-router)#redistribuiți subrețele eigrp 1

Ne uităm la rutele pe msk-arbat-gw1:

msk-arbat-gw1#sh traseu ip
Coduri: C - conectat, S - static, I - IGRP, R - RIP, M - mobil, B - BGP
D - EIGRP, EX - EIGRP extern, O - OSPF, IA - OSPF inter zona
N1 - OSPF NSSA extern tip 1, N2 - OSPF NSSA extern tip 2
E1 - OSPF extern tip 1, E2 - OSPF extern tip 2, E - EGP
i - IS-IS, L1 - IS-IS nivelul 1, L2 - IS-IS nivelul 2, ia - IS-IS interzona
* - implicit candidat, U - rută statică per utilizator, o - ODR
P - rută statică descărcată periodic

Gateway-ul de ultimă instanță este 198.51.100.1 către rețeaua 0.0.0.0

10.0.0.0/8 este subrețele variabil, 3 subrețele, 2 măști
O E2 10.0.0.0/8 prin 172.16.2.34, 00:25:11, FastEthernet0/1.7
O E2 10.0.1.0/24 prin 172.16.2.34, 00:25:11, FastEthernet0/1.7
O E2 10.0.2.0/24 prin 172.16.2.34, 00:24:50, FastEthernet0/1.7
172.16.0.0/16 este subrețea variabil, 30 de subrețele, 5 măști
O E2 172.16.0.0/16 prin 172.16.2.34, 00:25:11, FastEthernet0/1.7
C 172.16.0.0/24 este conectat direct, FastEthernet0/0.3
C 172.16.1.0/24 este conectat direct, FastEthernet0/0.2
C 172.16.2.0/30 este conectat direct, FastEthernet0/1.4
C 172.16.2.16/30 este conectat direct, FastEthernet0/1.5
C 172.16.2.32/30 este conectat direct, FastEthernet0/1.7
O E2 172.16.2.36/30 prin 172.16.2.34, 01:00:55, FastEthernet0/1.7
O E2 172.16.2.40/30 prin 172.16.2.34, 01:00:55, FastEthernet0/1.7
O E2 172.16.2.44/30 prin 172.16.2.34, 01:00:55, FastEthernet0/1.7
C 172.16.2.128/30 este conectat direct, FastEthernet0/1.8
O 172.16.2.160/30 prin 172.16.2.130, 01:00:55, FastEthernet0/1.8
O 172.16.2.192/30 prin 172.16.2.197, 00:13:21, FastEthernet1/0.911
C 172.16.2.196/30 este conectat direct, FastEthernet1/0.911
C 172.16.3.0/24 este conectat direct, FastEthernet0/0.101
C 172.16.4.0/24 este conectat direct, FastEthernet0/0.102
C 172.16.5.0/24 este conectat direct, FastEthernet0/0.103
C 172.16.6.0/24 este conectat direct, FastEthernet0/0.104
O 172.16.24.0/24 prin 172.16.2.18, 01:00:55, FastEthernet0/1.5
O 172.16.128.0/24 prin 172.16.2.130, 01:00:55, FastEthernet0/1.8
O 172.16.129.0/26 prin 172.16.2.130, 01:00:55, FastEthernet0/1.8
O 172.16.144.0/24 prin 172.16.2.130, 00:13:21, FastEthernet0/1.8

O 172.16.160.0/24 prin 172.16.2.197, 00:13:31, FastEthernet1/0.911
C 172.16.255.1/32 este conectat direct, Loopback0
O 172.16.255.48/32 prin 172.16.2.18, 01:00:55, FastEthernet0/1.5
O E2 172.16.255.64/32 prin 172.16.2.34, 01:00:55, FastEthernet0/1.7
O E2 172.16.255.65/32 prin 172.16.2.34, 01:00:55, FastEthernet0/1.7
O E2 172.16.255.66/32 prin 172.16.2.34, 01:00:55, FastEthernet0/1.7
O 172.16.255.80/32 prin 172.16.2.130, 01:00:55, FastEthernet0/1.8
O 172.16.255.96/32 prin 172.16.2.130, 00:13:21, FastEthernet0/1.8
prin 172.16.2.197, 00:13:21, FastEthernet1/0.911
O 172.16.255.112/32 prin 172.16.2.197, 00:13:31, FastEthernet1/0.911
198.51.100.0/28 este subrețea, 1 subrețea
C 198.51.100.0 este conectat direct, FastEthernet0/1.6
S* 0.0.0.0/0 prin 198.51.100.1

Iată-le pe cele cu eticheta E2 - rute noi importate. E2 - înseamnă că acestea sunt rute externe de al 2-lea tip (), adică au fost introduse în procesul OSPF din exterior

Acum de la OSPF la EIGRP. Acesta este un pic mai complicat:

klgr-gw1(config)#router eigrp 1
klgr-gw1(config-router)#redistribuire ospf 1 metric 100000 20 255 1 1500

Fără a specifica metrica (acest set lung de numere), comanda va fi executată, dar redistribuirea nu va avea loc.

Rutele importate primesc o etichetă EX în tabelul de rutare și o distanță administrativă de 170, în loc de 90 pentru cele interne:

klgr-gw2#sh traseu ip

Poarta de ultimă instanță nu este setată

172.16.0.0/16 este subrețea variabil, 30 de subrețele, 4 măști
D EX 172.16.0.0/24 [170 /33280] prin 172.16.2.37, 00:00:07, FastEthernet0/0
D EX 172.16.1.0/24 prin 172.16.2.37, 00:00:07, FastEthernet0/0
D EX 172.16.2.0/30 prin 172.16.2.37, 00:00:07, FastEthernet0/0
D EX 172.16.2.4/30 prin 172.16.2.37, 00:00:07, FastEthernet0/0
D EX 172.16.2.16/30 prin 172.16.2.37, 00:00:07, FastEthernet0/0
D 172.16.2.32/30 [ 90 /30720] prin 172.16.2.37, 00:38:59, FastEthernet0/0
C 172.16.2.36/30 este conectat direct, FastEthernet0/0
D 172.16.2.40/30 prin 172.16.2.37, 00:38:59, FastEthernet0/0
prin 172.16.2.46, 00:38:59, FastEthernet0/1
….

Așa pare să se facă într-un mod simplu, dar simplitatea este superficială - redistribuirea este plină de multe probleme subtile și neplăcute atunci când se adaugă cel puțin o legătură redundantă între două domenii diferite.
Sfat general - încercați să evitați redistribuirea dacă este posibil. Principala regulă a vieții funcționează aici - cu cât mai simplu, cu atât mai bine.

Ruta implicită

Acum este momentul să vă verificați accesul la internet. Funcționează bine din Moscova, dar dacă verificați, de exemplu, din Sankt Petersburg (rețineți că am șters toate rutele statice):

PC>ping linkmeup.ru

Ping 192.0.2.2 cu 32 de octeți de date:

Răspuns de la 172.16.2.5: Gazda destinație inaccesibilă.
Răspuns de la 172.16.2.5: Gazda destinație inaccesibilă.
Răspuns de la 172.16.2.5: Gazda destinație inaccesibilă.

Statistici ping pentru 192.0.2.2:
Pachete: trimise = 4, primite = 0, pierdute = 4 (100% pierdere),

Acest lucru se datorează faptului că nici spb-ozerki-gw1, nici spb-vsl-gw1, nici nimeni altcineva din rețeaua noastră nu știe despre ruta implicită, cu excepția msk-arbat-gw1, pe care este configurată static.
Pentru a corecta această situație, trebuie doar să dăm o comandă la Moscova:

msk-arbat-gw1(config)#router ospf 1
msk-arbat-gw1(config-router)#default-information provin

După aceasta, informații despre locul unde se află poarta de ultimă instanță avalanșă în rețea.

Internetul este acum disponibil:

PC>tracert linkmeup.ru

Urmărirea rutei către 192.0.2.2 pe maximum 30 de hop:

1 3 ms 3 ms 3 ms 172.16.17.1
2 4 ms 5 ms 12 ms 172.16.2.5
3 14 ms 20 ms 9 ms 172.16.2.1
4 17 ms 17 ms 19 ms 198.51.100.1
5 22 ms 23 ms 19 ms 192.0.2.2

Comenzi utile pentru depanare

1) Lista vecinilor si starea comunicarii cu acestia se apeleaza prin comanda arata ip ospf vecin

msk-arbat-gw1:

Neighbor ID Pri State Dead Time Address Interfață
172.16.255.32 1 FULL/DROTHER 00:00:33 172.16.2.2 FastEthernet0/1.4
172.16.255.48 1 FULL/DR 00:00:34 172.16.2.18 FastEthernet0/1.5
172.16.255.64 1 FULL/DR 00:00:33 172.16.2.34 FastEthernet0/1.7
172.16.255.80 1 FULL/DR 00:00:33 172.16.2.130 FastEthernet0/1.8
172.16.255.112 1 FULL/DR 00:00:33 172.16.2.197 FastEthernet1/0.911

2) Sau pentru EIGRP: arata vecinii ip eigrp

IP-EIGRP vecini pentru procesul 1
H Adresă Interfață Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 172.16.2.38 Fa0/1 12 00:04:51 40 1000 0 54
1 172.16.2.42 Fa0/0 13 00:04:51 40 1000 0 58

3) Folosind comanda arata protocoale ip Puteți vizualiza informații despre rularea protocoalelor de rutare dinamică și relațiile acestora.

Klgr-balt-gw1:

Protocolul de rutare este „EIGRP 1”

Rețelele implicite semnalate în actualizările trimise
Rețelele implicite acceptate de la actualizările primite
Greutatea metrică EIGRP K1=1, K2=0, K3=1, K4=0, K5=0
Număr maxim de salturi EIGRP 100
Varianta maximă a metricii EIGRP 1
Redistribuire: EIGRP 1, OSPF 1
Rezumatul automat al rețelei este în vigoare
Rezumare automată a adreselor:
Calea maximă: 4
Rutare pentru rețele:
172.16.0.0

172.16.2.42 90 4
172.16.2.38 90 4
Distanta: interior 90 extern 170

Protocolul de rutare este „OSPF 1”
Lista de filtre de actualizare de ieșire pentru toate interfețele nu este setată
Lista de filtre de actualizare primită pentru toate interfețele nu este setată
ID router 172.16.255.64
Este un router de limită de sistem autonom
Redistribuirea rutelor externe din,
EIGRP 1
Numărul de zone din acest router este 1. 1 normal 0 stub 0 nssa
Calea maximă: 4
Rutare pentru rețele:
172.16.2.32 0.0.0.3 zona 0
Surse de informații despre rutare:
Distanța gateway Ultima actualizare
172.16.255.64 110 00:00:23
Distanță: (implicit este 110)

4) Pentru a depana și înțelege funcționarea protocoalelor, va fi util să folosiți următoarele comenzi:
depanați evenimentele IP OSPF
depanare ip OSPF adj
depanați pachetele EIGRP

Încercați să încercați diferite interfețe și vedeți ce se întâmplă în depanare, ce mesaje zboară.

Problema nr. 7
În sfârșit, o problemă complexă.
La ultima întâlnire a Lift mi Up, s-a decis ca și rețeaua Kaliningrad să fie transferată la OSPF.
Tranziția trebuie finalizată fără întreruperea conexiunii. S-a decis că cea mai bună opțiune ar fi să ridicați OSPF pe trei routere Kaliningrad în paralel cu EIGRP și, după ce a verificat că toate informațiile despre rutele Kaliningrad s-au răspândit în restul rețelei și invers, să dezactivați EIGRP. pentru logo-ul site-ului.

OSPF

EIGRP

redistribuirea rutelor

urmăritor de pachete

rețele pentru cei mici

Adaugă etichete