Electronica Si Telecomunicatii Retele Si Software de Telecomunicatii

Prezentată ca cerință parțială pentru obținerea titlului de

Inginer în domeniul Electronică și Telecomunicații

programul de studii Rețele și Software de Telecomunicații

Cuprins

1. Introducere

1.1 Internet-ul: istoric și evolutie

1.2 Clasificare rețelelor

1.3 Protocolul IP. Modelul TCP/IP și modelul OSI

1.4 Adresarea IP

1.5 Rutarea statică și rutarea dinamică

1.5.1 Bazele rutării statice

1.5.2 Bazele rutării dinamice

1.6 Protocoale de rutare

1.6.1 Protocoale cu rutare internă (Interior Gateway Protocols – IGP )

1.6.2 Protocoale cu rutare externă (Exterior Gateway Protocols – EGP )

2. Protocoale de rutare internă

2.1 Routing Information Protocol (RIP)

2.1.1 Caracteristicile RIP

2.1.2 Pachetele RIP

2.1.3 Modurile de operare RIP

2.1.4 Continutul tabelei de vectori distanta

2.1.5 Algoritmul de calcul al vectorilor distanta

2.1.6 Convergența algoritmului RIP

2.1.7 Limitarile RIP

2.1.8 Versiunea 2 a protocolului RIP (RIP-2)

2.2 Open Shortest Path First (OSPF)

2.2.1 Principalele caracteristicile ale OSPF

2.2.2 Terminologia OSPF

2.2.3 Tipuri de pachete OSPF

2.2.4 Descoperirea vecinilor: Protocolul Hello-OSPF

2.2.5 Redistribuirea rutelor OSPF

2.2.6 Sumarizarea rutelor OSPF

2.2.7 Autentificarea

2.3 Enhanced Interior Gateway Routing Protocol – (EIGRP)

2.3.1 Pachetele EIGRP

2.3.2 Caracteristici EIGRP

2.3.3 Metrica și distanța administrativă

2.3.4 Concepte EIGRP

3. Protocoale de rutare externă

3.1 eBGP si iBGP

3.2 Tipuri de mesaje BGP

3.3 Caracteristici BGP

3.4 Atributele BGP

3.4.1 Atributul Origin

3.4.2 Atributul Next-hop

3.4.3 Atributul AS-path

3.4.4 Atributul Local-Preference

3.4.5 Atributul Weight

3.4.6 Atributul Community

3.4.7 Atributul multi-exit discriminator (MED)

3.5 Criterii de selecție

3.6 Optimizarea traficului

4. Aplicații de utilizare a protocoalelor de rutare – topologia rețelei

5. Aplicații folosind simulatorul GNS3

5.1 Introducere în GNS3

5.2 Configurare generală a routerelor în simulatorul GNS3

5.3 Interconectarea între echipamente fizice și o rețea simulată în GNS3

5.4 Configurarea specifică a routerelor din topologia prezentată

6. Rezultate și discuții

Concluzii

Bibliografie

Anexe

Abrevieri

ACL – Access Control List

ACK – Acknowledge

AFI – Address Family Identifier

AS – Autonomous System

ASBR – Autonomous System Boundary Route

BDR – Backup Designated Router

BGP – Border Gateway Protocol

CIDR – Classless Inter-Domain Routing

CLI – Command Line Interface

CSMA/CD – Carrier Sense Multiple Access / Collision Detection

DB – Database

DCE – Data Communications Equipment

DHCP – Dynamic Host Configuration Protocol

DTE – Data Terminal Equipment

DNS – Domain Name

DR – Designated Router

EBGP – External Border Gateway Protocol

EGP – Exterior Gateway Protocol

EIGRP – Enhanced Interior Gateway Routing Protocol

FTP – File Transfer Protocol

GNS – Graphical Network Simulator

GPS – Global Positioning System

IBGP – Internal Border Gateway Protocol

ICMP – Internet Control Message Protocol

IETF – Internet Engineering Task Force

IGP – Interior Gateway Protocol

IGRP – Interior Gateway Routing Protocol

IOS – Internetwork Operating System

IP – Internet Protocol

IPX – Internetwork Packet Exchange Protocol

IS-IS – Intermediate System To Intermediate System

ISDN – Integrated Services Digital Network

ISP – Internet Service Provider

LAN – Local Area Network

LLC – Logical Link Control

LSA – Link-State Advertisement

NLRI – Network Layer Reachability Information

MAC – Medium Access Control

MAN – Metropolitan Area Network

MED – Multi-Exit Discriminators

OSI – Open System Interconnected

OSPF – Open Shortest Path First

PAN – Personal Area Network

PSTN – Public Switched Telephone Network

RAM – Random-Access Memory

RIP – Routing Information Protocol

RTP – Real-time Transport Protocol

SSH – Secure Shell

TCP/IP – Transmission Control Protocol/Internet Protocol

TCP – Transmission Control Protocol

UDP – User Datagram Protocol

USB – Universal Serial Bus

UTP – Unshielded Twisted Pair

VLSM – Variable-Length Subnet Masking

WAN – Wide area network

WWW – World Wide Web

1

Introducere

Internet-ul: istoric și evoluție

Poștă electronică, știri, biblioteci, muzică și multe altele. Pe net găsești de toate. Este unul din motivele pentru care cei din branșă au ajuns să fie numiți netocrați după o evoluție care a durat vreo 40 de ani. Câți dintre noi mai pot trăi astăzi fără porția zilnică de Internet? Toate lucrurile rele au și o parte bună. De ce avem curajul să afirmăm așa ceva?

Pentru că dacă în 1957 URSS nu ar fi plasat pe orbita Pamântului primul satelit artificial

(Sputnik) astăzi nu am fi avut probabil Internet. Ca răspuns la această palmă primită, în cadrul Departamentului de Apărare al SUA (DoD) ia ființă Advanced Research Projects Agency (ARPA). Americanii doreau să recupereze handicapul și să devină lideri mondiali în domeniul științelor și tehnologiilor cu aplicații militare. Cinci ani mai târziu (1962), Paul Baran de la Rand Corporation a pornit un proiect de cercetare pentru construirea unei rețele strategice pentru transmisiunea datelor între calculatoarele Pentagonului. Rețeaua trebuia să satisfacă doua cerinte: să lege între ele scumpele calculatoare ale agenției și eventual ale altor centre de cercetari și să reziste cu succes în fata unui atac nuclear. Internet-ul s-a expandat în afara Statelor Unite, cuprinzând instituții de pe toate continentele. Termenul Internet provine din împreunarea artificială și parțială a două cuvinte englezești: interconnected = interconectat și network = rețea. Dezvoltarea rapidă a Internetului s-a datorat faptului că accesul la documentația protocoalelor obligatorii a fost și este liber și gratuit. Enorma creștere a web-ului a început aproape dintr-o dată: în iunie 1993 erau înregistrate 130 servere web, iar în 1994 erau deja peste 11.500 de servere. În zilele noastre, gradul de răspândire a Internetului pe glob este uriaș: în 30 iunie 2009 aveau acces la Internet circa 1,67 miliarde de locuitori ai globului pământesc. Potrivit studiului privind utilizarea internetului în România și a comportamentului internautic al românilor, 35,5% din populația României utilizează internetul. Viteza medie pentru conexiunea la internet la nivel global este de 1,7 megabiți pe secundă (Mbps), în SUA este de 4,7 Mbps, iar în România este de 6,3 Mbps. [1]

În ziua de astăzi Internetul este susținut și întreținut de o mulțime de firme comerciale. El se bazează pe specificații tehnice foarte detaliate, ca de exemplu pe așa-numitele "protocoale de comunicație", care descriu toate regulile și protocoalele de transmitere a datelor în această rețea. În termeni foarte simpli, o rețea reprezintă un sistem de oameni și obiecte conectate între ele. Rețelele de comunicații sunt proiectate astfel încât două calculatoare, localizate oriunde în lume, să fie capabile să comunice între ele, indiferent de tipul acestora (PC, Mac, maincadru etc). Acest lucru este posibil prin intermediul unei limbi comune, numită protocol. Protocolul este definit ca un set formal de reguli și convenții cu ajutorul cărora este guvernat schimbul de informații între echipamentele unei rețele. [1]

Clasificare rețelelor

Rețeaua de calculatoare leagă între ele o mulțime mai mică sau mai mare de calculatoare, astfel încât un calculator poate accesa datele, programele și facilitățile unui alt calculator din aceeași rețea. De obicei este nevoie desigur și de măsuri de restricție/siguranță a accesului.

Metodele de conectare sunt în continuă dezvoltare și deja foarte diverse, începând cu tot felul de cabluri metalice și de fibră optică, chiar submarine, și terminând cu legături prin unde radio cum ar fi WLAN, Wi-Fi, WiMAX sau Bluetooth, prin raze infraroșii ca de ex. IrDA sau prin intermediul sateliților.

Rețelele de calculatoare pot fi clasificate după tehnlogia care este folosită pentru a conecta dispozitive individuale din rețea, cum ar fi fibră optică, Ethernet, Wireless LAN (din engleză și înseamnă "fără fir"), HomePNA sau Power line. [2]

Metodele de conectare sunt în continuă dezvoltare și deja foarte diverse, începând cu tot felul de cabluri metalice și de fibră optică, cabluri submarine, și terminând cu legături prin radio cum ar fi Wi-Fi sau Bluetooth, prin raze infraroșii (IrDA) sau chiar prin intermediul sateliților.

Foarte răspândită este metoda Ethernet, termen care se referă la natura fizică a cablului folosit și la tensiunile electrice ale semnalului. Cel mai răspândit protocol de comunicare în rețelele Ethernet se numește CSMA/CD (Carrier Sense Multiple Access / Collision Detection). Dacă sunt utilizate undele radio, atunci rețeaua se numește rețea fără fir (wireless).

Rețelele de calculatoare se împart după extinderea lor în următoarele tipuri: LAN, MAN, WAN și, ceva mai nou, PAN. [2]

Rețelele relativ mici, de exemplu cu cel mult câteva sute de calculatoare în aceeași clădire legate între ele direct, se numesc Local Area Network (LAN). O rețea de tip LAN dar fără fir (prin unde radio) se numește WLAN (Wireless LAN). Toate calculatoarele din LAN sunt conectate prin fir de rețea de categoria 5, numit UTP CAT5 cable, rulează protocolul IEEE 802.3 (Ethernet) printr-un sistem de dispozitive interconectate care eventual se conectează și la Internet.[1]

Rețelele metropolitane (MAN) sunt rețele de mare extindere care de obicei împînzesc orașe întregi. Aceste rețele folosesc pentru legături cel mai des tehnologii fără fir (wireless) sau fibră optică.

Rețele de mare întindere geografică, de exemplu între 2 orașe, pe o țară, un continent sau chiar pe întreaga lume, se numesc Wide Area Network (WAN). Rețelele de tip WAN au fost inițial foarte costisitoare. Numai companiile mari își puteau permite un WAN particular. La ora actuală însă, cele mai multe conexiuni de tip WAN folosesc ca mijloc de comunicație Internetul – acesta este universal și public, deci nu foarte controlabil de către un utilizator, în schimb însă foarte convenabil ca preț. [3]

În sfârșit, PAN înseamnă Personal Area Network – o rețea de foarte mică întindere, de cel mult câțiva metri, constând din aparatele interconectabile din apropierea unei persoane, cum ar fi o imprimantă sau un scanner, sau chiar aparatele pe care o persoană le poartă cu sine, ca de exemplu un telefon mobil sau un smartphone, un player MP3 sau un aparat de navigație GPS portabil. Raza de acțiune a rețelelor PAN este aproximativ de la 6-9 metri. Rețelele PAN pot fi conectate cu magistrale USB și FireWire.

Protocolul IP. Modelul TCP/IP și modelul OSI

Protocolul care efectuează mecanismul de livrare nefiabilă, fără conexiuni, a pachetelor se numește Protocolul Internet [Internet Protocol (IP)]. IP se bazează pe trei definiții importante. Mai întâi, protocolul IP definește unitatea de bază pentru transferul de date utilizată în internet cu TCP/IP – deci precizează formatul exact al tuturor datelor vehiculate într-o internet. În al doilea rând, programul IP efectuează funcția de rutare, selectând traseul pe care vor fi trimise datele. În al treilea rând, IP include și un set de reguli care întruchipează ideea de livrare nefiabilă de pachete; aceste reguli caracterizează modul în care calculatoarele și ruterele trebuie să proceseze pachetele, cum și când trebuie generate mesaje de eroare, precum și condițiile în care pot fi eliminate pachetele. Protocolul IP constituie o parte atât de importantă a proiectării, încât se vorbește de o tehnologie pe bază de IP pentru internet.

Protocolul IP este un protocol folosit pentru transmiterea datelor în interiorul unei rețele cu comutație de pachete folosind stiva de protocoale TCP/IP. Stiva TCP/IP este împărtită în 4 mari categorii:

Nivelul Aplicație

Nivelul Transport

Nivelul Internet(Rețea)

Nivelul Fizic

Modelul TCP/IP (Transmission Control Protocol/Internet Protocol) a fost creat de US DoD (US Department of Defence – Ministerul Apărării Naționale al Statelor Unite) din necesitatn schimb însă foarte convenabil ca preț. [3]

În sfârșit, PAN înseamnă Personal Area Network – o rețea de foarte mică întindere, de cel mult câțiva metri, constând din aparatele interconectabile din apropierea unei persoane, cum ar fi o imprimantă sau un scanner, sau chiar aparatele pe care o persoană le poartă cu sine, ca de exemplu un telefon mobil sau un smartphone, un player MP3 sau un aparat de navigație GPS portabil. Raza de acțiune a rețelelor PAN este aproximativ de la 6-9 metri. Rețelele PAN pot fi conectate cu magistrale USB și FireWire.

Protocolul IP. Modelul TCP/IP și modelul OSI

Protocolul care efectuează mecanismul de livrare nefiabilă, fără conexiuni, a pachetelor se numește Protocolul Internet [Internet Protocol (IP)]. IP se bazează pe trei definiții importante. Mai întâi, protocolul IP definește unitatea de bază pentru transferul de date utilizată în internet cu TCP/IP – deci precizează formatul exact al tuturor datelor vehiculate într-o internet. În al doilea rând, programul IP efectuează funcția de rutare, selectând traseul pe care vor fi trimise datele. În al treilea rând, IP include și un set de reguli care întruchipează ideea de livrare nefiabilă de pachete; aceste reguli caracterizează modul în care calculatoarele și ruterele trebuie să proceseze pachetele, cum și când trebuie generate mesaje de eroare, precum și condițiile în care pot fi eliminate pachetele. Protocolul IP constituie o parte atât de importantă a proiectării, încât se vorbește de o tehnologie pe bază de IP pentru internet.

Protocolul IP este un protocol folosit pentru transmiterea datelor în interiorul unei rețele cu comutație de pachete folosind stiva de protocoale TCP/IP. Stiva TCP/IP este împărtită în 4 mari categorii:

Nivelul Aplicație

Nivelul Transport

Nivelul Internet(Rețea)

Nivelul Fizic

Modelul TCP/IP (Transmission Control Protocol/Internet Protocol) a fost creat de US DoD (US Department of Defence – Ministerul Apărării Naționale al Statelor Unite) din necesitatea unei rețele care ar putea supraviețui în orice conditii. DoD dorea ca, atâta timp cât funcționau mașina sursa și mașina destinație, conexiunile să ramână intacte, chiar dacă o parte din mașini sau din liniile de transmisie erau brusc scoase din funcțiune. Era nevoie de o arhitectură flexibila, deoarece se aveau în vedere aplicații cu cerințe divergente, mergând de la transferul de fișiere pană la transmiterea vorbirii în timp real.

Similar cu stiva de protocoale TCP/IP este modelul OSI (Open Systems Interconnection) care definește într-un mod abstract nivelele în care se realizează comunicarea între 2 calculatoare sau stații. [1] În forma lui de bază modelul împarte arhitectura rețelei în 7 straturi sau niveluri care de sus în jos sunt următoarele:

Nivelul aplicație

Nivelul prezentare

Nivelul sesiune

Nivelul transport

Nivelul rețea

Nivelul legăturii de date

Subnivelul LLC (Logical Link Control)

Subnivelul MAC (Media Access Control)

Nivelul fizic

Proiectanții au folosit două căi de abordare pentru a rezolva problema ascunderii detaliilor rețelelor interconectate: utilizarea programelor de aplicații pentru a face față heterogenității și ascunderea detaliilor în sistemul de operare.

Primele interconectări de rețele eterogene asigurau uniformitatea prin intermediul programelor de la nivelul de aplicație. În astfel de sisteme, un program de la nivelul de aplicație, executat pe fiecare mașină din rețea, înțelegea detaliile conexiunilor rețelei pentru acea mașină și interopera cu programele de aplicații prin acele conexiuni. De exemplu, un sistem de poștă electronică constă din programe de poștă care fac să avanseze [forward] un mesaj, succesiv, de la o mașină la alta. Traseul de la sursă până la destinație poate trece prin mai multe rețele diferite, dar acest fapt nu contează atâta timp cât sistemul de poștă de pe toate mașinile cooperează în vederea trimiterii mai departe a fiecărui mesaj.

Utilizarea programelor de aplicații în vederea ascunderii detaliilor rețelelor pare naturală la prima vedere, dar o astfel de soluție conduce la o comunicație limitată și greoaie. Adăgarea de noi funcții sistemului înseamnă conceperea unui nou program de aplicație pentru fiecare mașină, iar adăugarea de noi dispozitive în rețea înseamnă modificarea sau crearea de noi programe pentru fiecare aplicație posibilă. Pe o mașină dată, fiecare program de aplicație trebuie să înțeleagă conexiunile rețelei pentru acea mașină, ceea ce duce la multiplicarea instrucțiunilor programului.

Utilizatorii familiarizați cu problemele rețelelor de calculatoare înțeleg că odată cu extinderea interconectării la sute și mii de rețele, nimeni nu mai poate concepe toate programele de aplicații necesare. Mai mult, succesul schemei de comunicație pas-cu-pas impune corectitudinea tuturor programelor de aplicație executate de-a lungul traiectoriei. Dacă un program de pe o mașină intermediară funcționează eronat, sursa și destinația nu mai pot detecta sau remedia disfuncționalitatea. Prin urmare, sistemele care utilizează programe intermediare nu pot garanta o comunicație fiabilă.

Alternativa la interconectarea pe bază de programe la nivelul de aplicație o constituie interconectarea la nivel de rețea. O interconectare la nivel de rețea oferă un mecanism ce livrează pachetele de la sursa originară la destinația finală în timp real. Comutarea unor mici unități de informație în locul unor fișiere sau mesaje lungi prezintă o serie de avantaje. Mai intâi, o astfel de schemă se potrivește direct cu soluția hardware a rețelei aferente, făcând-o extrem de eficientă. În al doilea rând, interconectarea la nivel de rețea separă activitățile orientate pe comunicația de date față de programele de aplicații, permițând calculatoarelor intermediare să facă față traficului din rețea fără a necesita înțelegerea aplicației din care provine. În al treilea rând, utilizarea conexiunilor de rețea menține flexibilitatea întregului sistem, făcând posibilă realizarea de programe utilitare de comunicație de uz general. În al patrulea rând, o astfel de soluție permite administratorilor de rețele să adauge noi tehnologii de rețea prin modificarea sau adăugarea unui singur nou program la nivelul de rețea, lăsând nemodificate programele de aplicații.

Cheia proiectării unei interconexiuni universale la nivelul de rețea poate fi găsită în conceptul unui sitem abstract de comunicație cunoscut sub denumirea de interconectare de rețele. Conceptul de inter-rețea (internet) este deosebit de puternic. El desparte noțiunea de comunicație de detaliile tehnologice ale rețelelor și ascunde detaliile de la nivelurile inferioare pentru utilizator. Și, ceea ce este și mai important, dirijează toate deciziile de proiectare de programe și explică modul cum trebuie tratate adresele fizice și traseele. [3]

Vom semnala de la început două condiții fundamentale care trebuie sa stea la baza proiectării sistemelor de comunicație:

nici un hardware de rețea nu poate satisface toate restricțiile;

utilizatorii doresc o interconectare universală.

Prima condiție este de ordin tehnic. Rețelele locale (LAN) care oferă cele mai mari viteze de comunicație sunt limitate ca întindere geografică, iar rețelele mari (WAN) acoperă distanțe mari dar nu pot oferi conexiuni de mare viteză. Nu există o tehnologie unică de rețea care să satisfacă toate necesitățile, așa încât suntem obligați să luăm în considerație mai multe tehnologii hardware de rețele.

Cea de a doua condiție este evidentă. Suprema doleanță este aceea de a putea să asigurăm o comunicație între oricare două locuri. În particular, dorim un sistem de comunicație care să nu fie restrâns la granițele rețelelor fizice.

Scopul este acela de a construi o interconectare de rețele unificată, cooperantă, care să suporte un serviciu universal de comunicație. În fiecare dintre rețele, calculatoarele vor utiliza facilitățile de comunicație aferente, dependente de tehnologia de realizare a rețelei. Noile programe, inserate între mecanismele de comunicație dependente de tehnologie și programele de aplicație, vor masca detaliile de la nivelurile inferioare și vor face ca mulțimea de rețele să apară ca o unică rețea mare. Doar o astfel de soluție de interconectare de rețele de calculatoare va fi desemnată prin termenul de inter-rețea (sau internet).

Concepția realizării unei internet urmărește tiparul standard de proiectare a sistemelor: cercetătorii schițează facilitățile de calcul de la nivelul superior și apoi folosesc tehnologiile de calcul disponibile, adăugând dedesubt niveluri de programe până când obțin un sistem care să implementeze eficient facilitățile imaginate la nivelul superior.

O problemă esențială este cea privind modul de interconectare al unor rețele pentru a forma o inter-rețea. Soluția are două parți. Din punct de vedre fizic, două rețele pot fi interconectate doar printr-un calculator atașat la amândouă rețelele. Dar o atașare fizică nu asigură efectiv interconexiunea, căci o asemena conexiune nu ne garantează că acel calculator va coopera cu alte mașini care vor să comunice. Pentru a obține o internet viabilă este nevoie de calculatoare care să fie capabile să transporte pachetele dintr-o rețea în cealaltă. Calculatoarele care interconectează două rețele și fac să treacă pachetele dintr-o rețea în cealaltă se numesc rutere.[2]

Pe măsură ce conexiunile din internet au devenit mai complexe, ruterele au necesitat cunoașterea topologiei internet dincolo de rețelele cu care ele se conectau. Astfel, de exemplu (vezi figura 1), pentru trei rețele interconectate prin intermediul a două rutere, ruterul R1 trebuie să transfere din rețeaua 1 în rețeaua 2 toate pachetele destinate mașinilor atât din rețeaua 2 cât și din rețeaua 3. Pentru o mare internet, compusă din multe rețele, sarcina ruterelor de a lua decizii unde să trimită pachetele devine și mai complexă.

Figura 1

Ideea unui ruter pare simplă, dar ea este importantă întrucât ea oferă o modalitate de interconectare a rețelelor, nu doar a mașinilor. Principiul interconectării într-o internet este următorul: calculatoarele având rol de rutere asigură toate interconexiunile dintre rețelele fizice.

În pofida a ceea ce ne-am aștepta, ruterele – care trebuie să știe cum să dirijeze pachetele către destinația lor – nu sunt mașini mari, cu o suficientă memorie primară sau secundară pentru a memora infrmația despre fiecare mașină din internet cu care este atașat. Ruterele care utilizează tehnica TCP/IP sunt, de regulă, mașini mici, cu hard-disc de mici dimensiuni sau fără și cu o memorie principală limitată. Motivația rezidă în următorul concept: ruterele folosesc rețeaua destinație, nu mașina destinație, când dirijează un pachet. Așadar, cantitatea de informație pe care un ruter trebuie să o dețină este proporțională cu numărul de rețele din internet, nu cu numărul de mașini.

Întrucât, după cum am menționat, TCP/IP este conceput să ofere o interconexiune universală între mașini, indiferent de particularitățile rețelelor la care sunt atașate, utilizatorul vede o internet ca pe o unică rețea virtuală la care sunt conectate toate mașinile, indiferent de conexiunile lor fizice. Figura 2a ce urmează ilustrează ceea ce percepe utilizatorul iar figura 2b exemplifică structura rețelelor fizice și a ruterelor ce asigură interconectarea. Această viziune a utilizatorului simplifică detaliile și face ușoară conceptualizarea comunicației. Firește, în plus față de ruterele ce interconectează rețelele fizice, este necesar un program, pe fiece calculator, care să permită programelor de aplicații să utilizeze inter-rețeaua ca și cum ar fi o unică rețea fizică, reală. [2]

Figura 2

Avantajul asigurării interconectării la nivelul de rețea devine acum evident. Întrucât programele de aplicații ce comunică prin intermediul internet nu cunosc detaliile conexiunilor aferente, ele pot fi rulate, fără a fi modificate, pe orice mașină. Deoarece detaliile conexiunilor cu diverse rețele fizice ale fiecărei mașini sunt ascunse în programele pentru internet, doar aceste programe trebuie schimbate când apar noi conexiuni sau dispar unele conexiuni mai vechi. Într-adevăr, este posibil să se optimizeze structura internă a internet prin modificarea conexiunilor fizice fără ca măcar să se recompileze programele de aplicații.

Un al doilea avantaj al asigurării comunicării la nivelul de rețea este ceva mai subtil: utilizatorii nu trebuie să înțeleagă sau să-și amintească cum se conectează rețelele sau ce trafic poartă ele. Programele de aplicații pot fi scrise astfel încât să comunice indiferent de conectivitatea fizică corespunzătoare. Într-adevăr, administratorii de rețele sunt liberi să modifice părți interioare ale arhitecturii internet aferente fără a fi nevoiți să modifice programele de aplicații în majoritatea calculatoarelor atașate la internet (firește, programul de rețea trebuie reconfigurat când un calculator se mută într-o altă rețea).

După cum se vede în figura 2b de mai sus, ruterele nu asigură conexiuni directe între toate perechile de rețele. Este posibil ca traficul circulând de la o mașină la alta să traverseze mai multe rețele intermediare. Așadar, fiecare rețea este de acord să manipuleze traficul în tranzit în schimbul dreptului de a trimite trafic în internet. De regulă, utilizatorii nu sunt afectați și nici măcar nu au cunoștință de traficul suplimentar prin rețeaua lor locală.

Adresarea IP

Adresarea IP se refera la modul in care echipamentele de retea obtin o adresa IP cu care se identifica unic in lume si felul in care adresele ip se impart in general.

O adresa IP este un identificator numeric sau o adresa logica care se atribuie unui echipament ce participa la alcatuirea unei retele ce foloseste protocolul IP pentru comunicarea dintre echipamente si noduri. [1]

Desi o adresa IP este stocata si folosita de echipamente in forma sa binara, ele sunt de obicei afisate intr-o forma mai “umana” de genul 185.37.11.22 pentru protocolul IP versiunea 4 si 2001:db8:0:1234:0:567:1:1 pentru protocolul IP versiunea 6.

Rolul adresei IP a fost caracterizat folosind urmatoarea expresie:

“Un nume indica ceea ce cautam.O adresa indica locul unde se afla. O ruta indica traseul pe care ajungem acolo” (RFC 760)

Design-ul original al stivei TCP/IP definea adresa IP ca un numar binar pe 32 de biti, sistem care s-a numit si se numeste si astazi Ipv4.

Protocolul IP are deasemenea rolul de a ruta pachetele de date intre retele iar adresa Ip are rolul de a preciza lcoatia sursei si nodul destinatie al respectivului pachet in topologia sistemului de rutare.In acest sens o portiune a adresei IP este folosita pentru a desemna o subretea bine stabilita.O adresa Ip poate fi privata (pentru a fi folosita intr-un LAN – Local Area Network = retea locala) sau poate fi publica pentru utilizarea ei in internet sau intr-un WAN(Wide Area Network – retea metropolitana).

Specificatiile initiale presupuneau ca fiecare echipament din lume trebuie sa aiba o adresa IP unica. S-a constatat ulterior ca lucrul acesta nu mai era obligatoriu si necesar deoarece retelele private incepusera sa se dezvolte si aparuse problema conservarii adreselor IPv4. S-au definit in acest sens prin RFC 1918 mai multe spatii private de adresare IP care nu pot fi rutate prin internet si care pot fi folosite de oricine atata timp cat nu ies din incidenta unuei retele locate sau private. Acest tip de adrese IP private comunica cu celelalte host-uri din internet cu ajutorul NAT-ului(Network Address Translation).

Totusi, datorita cresterii enorme a numarului de echipamente conectate la internet numarul de adrese IPv4 unice scade rapid si de aici nevoia de o noua schema de adresare numita IPv6 ce foloseste adrese binare pe 128 de biti.

Adresele IPv4, denumite in general si adrese IP folosesc 32 de biti (4 byte sau 4 octeti) ceea ce limiteaza numarul lor la 232 adica 4,294,967,296 de posibile adrese IP unice .Totusi, un numar din acest total este rezervat pentru retelele private (aprox 18 mil de adrese) sau pentru adresele de tip multicast (aprox. 270 mil adrese).

IPv6 este un protocol dezvoltat pentru a înlocui IPv4 în Internet. Adresele au o lungime de 128 biți (16 octeți), ceea ce este considerat suficient pentru o perioadă îndelungată. Teoretic există 2128, sau aproximativ 3,403 × 1038 adrese unice. Lungimea mare a adresei permite împărțirea în blocuri de dimensiuni mari și implicit devine posibilă introducerea unor informații suplimentare de rutare în adresă. [4]

Adresele IPv6 sunt scrise de cele mai multe ori sub forma a 8 grupuri de câte 4 cifre hexazecimale, fiecare grup fiind separat de două puncte (:). De exemplu, 2001:0db8:85a3:08d3:1319:8a2e:0370:7334 este o adresă IPv6 corectă. Dacă unul sau mai multe din grupurile de 4 cifre este 0000, zerourile pot fi omise și înlocuite cu două semne două puncte(::). De exemplu, 2001:0db8:0000:0000:0000:0000:1428:57ab se prescurtează 2001:0db8::1428:57ab. Această prescurtare poate fi făcută o singură dată, altfel ar putea apărea confuzii cu privire la numărul de câmpuri omise. Plecând de la adresa 2001:0000:0000:ffd3:0000:0000:0000:57ab, prescurtarea 2001::ffd3::57ab ar putea să însemne 2001:0000:0000:0000:0000:ffd3:0000:57ab, 2001:0000:ffd3:0000:0000:0000:0000:57ab, sau altă combinație similară. Zerourile de la începutul unui grup pot fi de asemenea omise, ca de exemplu în adresa localhost ::1.

Rutarea statică și rutarea dinamică

Exista doua mari tipuri de rutare care stau la baza tuturor celorlalte tipuri de rutare:

rutarea static

rutarea dinamică

Bazele rutării statice

Un router care este programat pentru rutare statică expediază pachetele prin porturi predeterminate. După ce routerele statice sunt configurate, ele nu mai trebuie să incerce descoperirea rutelor, nici măcar să comunice informații despre rute. Rolul lor este redus la simpla expediere a pachetelor. Rutarea statică este bună doar pentru rețele foarte mici, care au o singură cale către orice destinație dată. În astfel de cazuri, rutarea statică poate fi cel mai eficient mecanism de rutare, pentru că nu consumă lărgime de bandă, încercând să descopere rute și să comunice cu alte routere. Pe măsură ce rețelele cresc și apar căi redundante către destinații, rutarea statică devine o sarcină care necesită prea 3 mult efort. Orice modificări în disponibilitatea routerelor sau a echipamentelor de transmisie din WAN trebuie să fie descoperite si programate manual. WAN-urile caracterizate prin tipologii mai complexe, care pot oferi mai multe căi posibile, necesită categoric rutare dinamică. Încercările de a utiliza rutarea statică în WAN-uri complexe, cu mai multe căi, anulează rolul rutelor redundante. [2]

Bazele rutării dinamice

Ruterele utilizează protocoale cu rutare dinamică pentru a realiza trei funcții elementare: descoperirea de noi rute, comunicarea informațiilor despre noua rută descoperită altor rutere și expedierea pachetelor utilizând acele rute. Protocoalele cu rutare dinamică se împart în trei mari categorii: cu vectori distanță, cu starea legăturilor și hibride. Principalele diferențe dintre ele constau în modul în care realizeză primele două dintre cele trei funcții amintite anterior. Singura variantă la rutarea dinamică este rutarea statică.

Rutarea cu vectori-distanță

Rutarea se poate baza pe algoritmi cu vectori-distanță (numiți și algoritmi Bellman-Ford), care face ca ruterele să paseze periodic copii ale tabelelor de rutare vecinilor cei mai apropiați din rețea. Fiecare destinatar adaugă la tabelă un vector-distanță (propria "valoare" distanță) și o expediază vecionilor săi cei mai apropiați. Acest proces se desfășoară în toate direcțiile între routerele aflate în imediată vecinătate. Acest proces pas-cu-pas face ca fiecare router sa afle informații despre celelalte routere și să-și dezvolte o perspectivă cumulativă asupra "distațelor" rețelei. De exemplu, un protocol timpuriu de rutare este Routing Information Protocol (protocol de rutare a informațiilor) sau RIP . Acesta utilizează două unități de măsură pentru 2 distanțe ca să determine cea mai bună cale următoare pentru orice pachet. Aceste unități de măsură pentru distanță, tacturile și hopurile, sunt dependente de timp. Tabela cumulativă este apoi utilizată pentru actualizarea tabelelor de rutare ale fiecărui router. La finalul procesului, fiecare router a aflat niste informații vagi despre distanțele până la resursele din rețea. El nu a aflat nimic specific despre alte routere sau despre topologia reală a rețelei. Această abordare poate, în anumite circumstanțe, să creeze probleme de rutare pentru protocoalele bazate pe vectori-distanță. De exemplu, în urma unei căderi în rețea eset necesar ceva timp pentru ca routerele să conveargă spre o nouă înțelegere a topologiei rețelei. În timpul acestui proces, rețeaua ar putea fi vulnerabilă la rutări contradictorii și chiar la bucle infinite. Anumite măsuri de siguranță ar putea să micșoreze aceste riscuri, dar rămâne faptul că performanța rețelei este expusă riscurilor în timpul procesului de convergență. Prin urmare, este posibil ca protocoalele mai vechi care converg lent să nu fie potrivite pentru WAN-urile extinse, complexe.

Rutarea cu starea legăturilor

Algoritmii de rutare folosind starea legăturilor (link-state routing algorithm), cunoscuți colectiv ca protocoale cu preferarea drumului minim (SPF), mențin o bază de date complexă a topologiei rețelei. Spre deosebire de protocoalele cu vectori-distanță, cele folosind starea legăturilor dezvoltă și întrețin o cunoaștere completă a routerelor de rețea, ca și a felului cum sunt interconectate acestea. Această cunoștere este realizată prin schimbarea de pachete cu starea legăturilor (LSP) cu alte routere conectate direct. Fiecare router care a schimbat LSP-uri construiește apoi o bază de date logică utilizănd toate LSP-urile primite. Este utilizat apoi un algoritm "cu preferarea drumului liber", pentru a calcula cât de accesibile sunt destinațiile legate de rețea. Această informație este utilizată pentru a actualiza tabela de rutare. Acest proces este capabil să descopere modificările topologiei rețelei, care ar putea fi cauzate de căderea unei componente sau de mărirea rețelei. De fapt, schimbul de LSP-uri este declanșat de un eveniment din rețea, nu este realizat periodic. Rutarea cu starea legăturilor are două zone parțiale de risc. Mai întâi, în timpul procesului inițial de descoperire, rutarea cu starea legăturilor poate acapara mediile de transmisie ale rețelei, reducând astfel în mod semnificativ capacitatea rețelei de a transporta date. Această degradare a performanței este temporară, dar foarte evidentă. A doua problemă potențială este că rutarea cu starea legăturilor solicită intens memoria și procesorul. Din această cauză, routerele configurate pentru rutare cu starea legătulilor sunt în general mai scumpe.

Rutarea hibridă

Ultima formă de rutare dinamică este hibridizarea. Deși există protocoale hibride deshise, echilibrate, această formă este asociată aproape exclusiv creației brevetate a unei singure companii, Cisco Systems Inc. Acest protocol, EIGRP, a fost proiectat combinând cele mai bune aspecte ale protocoalelor cu vectori-distanță și cu starea legăturilor, fără limitările de performanță sau dezavantajele lor. Protocoalele de rutare hibride echilibrate utilizează unități de măsură vectori-distanță, dar realizează măsurători mult mai precise decât protocoalele cu vectori-distanță convenționale. De asemenea, ele converg mult mai rapid decât acestea din urmă, dar evită suprasarcinile și actualizările cu starea legăturilor. Hibrizii echilibrați nu sunt periodici, ci conduși de evenimente, conservând astfel lărgimea de bandă pentru aplicații reale. [5]

Protocoale de rutare

Există mai multe clase de protocoale de rutare: protocoalele de rutare pentru rețele ad-hoc care apar in rețele cu puțină sau chiar fără infrastructură, protocoale de rutare internă utilizate în interiorul sistemelor autonome și protocoale de rutare externă, acestea din urmă utilzându-se între sistemele autonome. [1]

Protocoale cu rutare internă (Interior Gateway Protocols – IGP )

RIP (Routing Information Protocol) este un protocol mai vechi de rutare cu vectori-distanță

IGRP (Interior Gateway Routing Protocol) este un protocol de rutare cu starea legăturilor, utilizat pe scară largă, dezvoltat de Cisco Systems. Este brevetat și acceptat doar pe routere Cisco.

EIGRP (Enhanced Interior Gateway Routing Protocol) este un protocol de rutare bazat pe protocolul IGRP, predecesorul său. Este proprietate Cisco.

OSPF (Open Shortest Path First) este un protocol cu starea legăturilor, cu un standard deschis.

IS-IS (Intermediate System to Intermediate System) este un protocol bazat pe OSI.

Protocoale cu rutare externă (Exterior Gateway Protocols – EGP )

EGP (Exterior Gateway Protocol)

BGP (Border Gateway Protocol) : în versiunea curentă, BGPv4, dateaza din anii 1995 este un protocol de rutare modern, utilizat între sisteme autonome.

Un protocol extern transportă informațiile de rutare între entități administrative independente, cum ar fi două corporații sau două universități. Fiecare dintre aceste entități menține o infrastructură de rețea independentă și folosește EGP pentru a putea comunica cu cealaltă entitate. Astăzi, cel mai popular protocol extern este BGP . Este protocolul extern primar folosit între rețelele conectate la Internet și a fost proiectat special pentru acest lucru.

Un protocol intern este folosit în interiorul unui singur domeniu administrativ, sau între grupuri apropiate care cooperează. Spre deosebire de protocoalele externe, IGP tinde să fie mai simple si rezolvă suprasolicitările venite din partea unui ruter. Aceste protocoale nu pot fi utilizate în rețelele mari.

Algoritmii de routare pot fi diferențiați după obiectivul particular dorit, impactul asupra rețelei și resurselor routerului, metricile folosite.

Tipuri de obiective: [2]

Optimalitate (alegerea rutei optime în funcție de metricile utilizate)

Simplitate și overhead scăzut(este importantă mai ales în cazul sistemelor cu resurse limitate)

Robustețe și stabilitate (comportarea corectă în condiții deosebite: probleme hardware, suprasolicitare, etc.)

Convergență rapidă (răspândirea rapidă a informațiilor legate de schimbarea stării rutelor)

Flexibilitate (adaptarea rapidă și corectă la schimbările din rețea: căderea unei legături, crearea unei noi legături, etc.)

Compararea algoritmilor în funcție de tip:

Static versus dynamic

Routarea statică este făcută de administrator, rutele nu sunt schimbate decât de administrator, designul este simplu și funcționează bine în rețele mici cu trafic predictibil. Routarea dinamică este folsită în rețele mari în care rutele se ajustează în funcție de schimbările din rețea. Routările statice și dinamice se pot combina: într-un algoritm dinamic se poate alege o rută statică, unică de fiecare dată, ca ultimă opțiune pentru pachetele care au o destinație necunoscută.

Single-path versus multipath

Unele protocoale sofisticate de routare suportă drumuri multiple la aceiași destinație. Spre deosebire de algoritmii cu un drum unic, se oferă posibilitatea multiplexării traficului pe linii multiple. Aceste multiplexări oferă rezultate mai bune și siguranță mai mare.

Plat versus ierarhic

Routarea plată consideră toate routerele egale, în schimb în routarea ierarhică sunt unele grupuri de routere aranjate ierarhic. Pachetele trimise la o grupare de acest fel vor coborî în ierarhie până la un router frunză din acest arbore ierarhic. Avantajul acestor routării ierarhice este că simulează organizarea din cele mai multe companii și deci suportă bine modelul lor de trafic.[5]

Host inteligent versus router intelligent

Unii algoritmi de routare presupun că hostul ce le trimite pachetul determină și ruta pachetului. Termenul folosit pentru a caracteriza această routare este source routing. În acest caz, routerele doar preiau și trimit mai departe pachetul. Alți algoritmi presupun că hostul nu știe nimic despre rute. În acești algoritmi, routerele determină drumul pe care va fi trimis pachetul.

Intradomeniu versus interdomeniu

Unii algoritmi de routare funcționează doar într-un domeniu, alți algoritmi funcționează în și între domenii.

Statutul legăturii versus vector distanță

Algoritmii care se bazează pe statutul legăturii se numesc algoritmi link-state (cunoscuți și ca algoritmi open shortest path first). Acești algortimi trimit informațiile de routare legate de statutul legăturilor proprii la toate nodurile din rețea. Astfel fiecare router își crează în tabela de routare proprie o imagine a întregii rețele. Algoritmii bazați pe vectori de distanță (algoritmi distance vector, cunoscuți și ca algoritmi Bellman-Ford) trimit informațiile de routare ale propriilor legături numai la vecini. În esență algoritmii link-state trimit informații mai puține peste tot, în timp ce algoritmii distance-vector trimit mai multe informații numai la vecini.
Pentru că algoritmii link-state converg mai repede, e mai puțin probabil să routeze în circuite (routing loops) decât algoritmii distance-vector. Pe de altă parte, algoritmii link-state necesită mai multă putere CPU și memorie decât algoritmii distance-vector. Deci implementările și suportul pentru algoritmii link-state sunt mai costisitoare.

Un sistem autonom (AS) este o rețea sau un grup de rețele sub o administrare unică cu aceleași reguli de routare în toată rețeaua. Fiecare AS are un număr unic de înregistrare care îi este asignat de către un Internet Assigned Numbers Authority (IANA). Acest număr se alege între 1 și 65,535. Numerele aflate între 64,512 și 65,535 sunt rezervate pentru utilizare privată. Deoarece posibilitatea de asignare a numerelor pentru sistemele autonome este finită (existând un număr fix de AS-uri) o organizație care solicită un număr trebuie să prezinte documentație care să dovedească necesitatea asignării.

Pentru a gestiona mai bine rutarea într-un astfel de mediu, ruterele sunt grupate în sisteme autonome. Fiecare AS constă dintr-un grup de rutere gestionat independent de o entitate sau o organizație particulară.

Rețelele client, ca de exemplu în universități sau companii, de obicei folosesc un protocol de routare Interior Gateway Protocol (IGP) ca RIP sau OSPF. Rețelele client sunt conectate la ISPs și ISPs folosesc BGP pentru a routa rute client și ISP. BGP este folosit pentru a comunica informații despre rute pentru Internet și este protocolul folosit între Internet Service Providers (ISPs). Când BGP este folosit între AS, protocolul este referit ca External BGP (EBGP). Dacă un ISP folosește BGP pentru routarea în AS, atunci protocolul este referit ca Interior BGP (IBGP). Distincția este ilustrată în figura de mai jos:

Figura 3: Sisteme autonome

Protocoalele de rutare interioare sunt utilizate pentru a partaja informații de rutare în interiorul unui AS. Fiecare AS poate utiliza protocoale de rutare interioare diferite deoarece sunt autonome. Protocoalele de rutare exterioare partajează informații între AS-uri. Fiecare AS trebuie să utilizeze același protocol de rutare exterior pentru a asigura comunicarea.

Deoarece sistemele autonome sunt numai un set de rutere, aceasta înseamnă că AS-urile sunt conectate prin legarea unui ruter dintr-un AS cu un ruter din alt AS. Din punct de vedere arhitectural, un AS constă dintr-un set de rutere cu două tipuri diferite de conectivitate:

rutere interne, care conectează alte rutere din același AS, rulând protocoalele de rutare interioare

rutere de graniță (border routers) care conectează atât rutere din același AS, cât și rutere din unul sau mai multe AS-uri. Aceste dispozitive răspund de asigurarea traficului între AS-uri și restul inter-rețelei. Ele rulează atât protocoale de rutare interioare, cât și exterioare.

Datorită avantajelor sale, arhitectura bazată pe sisteme autonome a devenit standard pentru rețelele TCP/IP, în speță Internetul. Împărțirea în protocoale de rutare interioare și exterioare a devenit, de asemeni, standard și astăzi prima clasificare a protocoalelor de rutare se face în interioare și exterioare.

2

Protocoale de rutare internă

Cele mai utilizate protocoale de rutare utilizate în interiorul sistemelor autonome sunt RIP (Routing Information Protocol), OSPF (Open Shortest Path First) și EIGRP (Enhanced Interior Gateway Routing Protocol).

Routing Information Protocol este protocolul intern cel mai des folosit in sistemele UNIX. RIP este integrat în cele mai utilizate sisteme UNIX. Însa, în multe rețele, RIP nu ar fi alegerea potrivită pentru rutare, deoarece timpul său de convergența și sclabilitatea sunt mai slabe în comparație cu EIGRP sau OSPF și limita de hopuri reduce sever dimensiunea rețelei. În mod clar, OSPF dispune de multă flexibilitate pentru a subdiviza un sistem autonom. Dar este oare necesar? O problemă a protocolului cu legare de stare este cantitatea mare de date care poate fi colectată în baza de date cu și de timpul prea lung care este necesar pentru a calcula rutele pentru acele date. Capacități cheie care disting EIGRP de alte protocoale de rutare include convergența rapidă, support pentru mască de subrețea variable-length, suport pentru update și support pentru multiple network layer protocols. EIGRP are toate avantajele flexibilității și ale configurării simple în timp ce îmbunătățește viteza și consumarea resurselor. Dealtfel, este capabil a fi un protocol unic atît pentru IP cît și pentru protocoale non- IP, eliminînd nevoia de a folosi multiple protocoale de rutare într-o rețea multi-protocol. [6]

Spre deosebire de alte protocoale de rutare bazate pe vectori-distanta, EIGRP nu mandatează o revizuire periodică al tabelelor de rutare între rutere vecine. În schimb, folosește un mecanism de descoperire/recuperare pentru a asigura că vecinii sunt conștienți de accesibilatea fiecaruia in parte.

Figura 4: Comparație intre diverse protocoale de rutare

Routing Information Protocol (RIP)

Protocolul RIP este unul dintre cele mai vechi și mai durabile protocoale. Sunt o mare varietate de protocoale asemănătoare sau bazate pe RIP. Protocolul folosește vectori de distanță pentru a calcula rutele și a alege ruta optimă. Algoritmii folosiți în implementare au fost descoperiți prin cercetare academică ce datează din 1957. [4]

Este importantă înțelegerea RIP-ului din două motive:

RIP este încă folosit în ziua de azi. Se pot întâlni implementări de rețele care sunt destul de mari pentru a necesita un protocol de rutare, însă simple pentru a folosi RIP efectiv.

Familiaritatea cu multe concepte fundamentale ale RIP-ului vor ajuta să se compare RIP-ul cu alte protocoale. Înțelegând cum operează RIP-ul și implementarea sa, învățarea altor protocoale de rutare se va face mult mai ușor.

RIP este cel mai vechi protocol de rutare distance-vector. Deși RIP-ului îi lipsește complexitatea altor protocoale de rutare mai avansate, simplitatea și utilizarea răspândită asigură longevitatea sa. RIP-ul nu este un protocol “pe cale de dispariție”; de fapt, o formă a RIP-ului pentru IPv6 numită RIPng (noua generație) este acum valabilă.

Figura 5: Evoluție RIP

RIP s-a dezvoltat dintr-un protocol realizat la Xerox, numit Gateway Information Protocol (GWINFO). Mai târziu a devenit popular datorită implementării în distribuția Berkley Software (BSD) ca daemon numit routed. Recunoscând necesitatea standardizării protocolului, Charles Hedrick a scris RFC 1058 în 1988, în care a documentat protocolul existent și a specificat câteva îmbunătățiri. De atunci, RIP a fost îmbunătățit cu RIPv2 în 1994 și cu RIPng în 1997. Prima versiune a RIP-ului este deseori numită RIPv1 pentru a face distincția cu RIPv2. Oricum, ambele versiuni împart aceleași trăsături. Când se discută trăsături comune, se folosește denumirea RIP. Când se discută trăsături distincte, se folosesc denumirile RIPv1 sau RIPv2. [7]

Caracteristicile RIP

Protocolul RIP (Routing Information Protocol) este un exemplu de protocol de rutare în interiorul unui SA de dimensiuni mici. RIP este inspirat din protocolul de rutare Xerox XNS.El are următoarele caracteristici de bază:

RIP este un protocol al vectorului de distanță

RIP folosește hop count ca unica metrică pentru selectarea căii

Routerele cunoscute cu hop count mai mare de 15 inaccesibile

Mesajele trimise prin broadcast la fiecare 30 de secunde.

Pachetele RIP

Protocolul RIP specifica doua tipuri de pachete. Aceste pachete pot fi transmise de catre orice nod în care ruleaza protocolul RIP:

pachete cerere: un pachet de cerere solicita nodurilor RIP vecine sa transmita tabela lor de vectori distanta. În cerere se specifica daca nodul vecin trebuie sa transmita numai un subset de vectori sau sa transmita întregul continut al tabelei;

pachete raspuns: un pachet de raspuns este transmis de catre un nod pentru a anunta informatia mentinuta în tabela locala de vectori distanta. Tabela este transmisa în urmatoarele situatii:

in mod automat, la fiecare 30 de secunde;

ca raspuns la un pachet de cerere generat de un alt nod RIP;

daca este disponibila functia de actualizare declansata (triggered update), tabela este transmisa atunci când apare o modificare a tabelei de vectori distanta;

atunci când se receptioneaza un pachet de raspuns la un nod, informatia continuta în acesta este comparata cu cea din tabela locala de vectori distanta. Daca pachetul de raspuns anunta o ruta catre o destinatie cu un cost mai mic, atunci tabela este actualizata cu noua cale.

Pachetele RIP sunt transmise în cadrul datagramelor UDP (protocolul RIP lucreaza peste nivelul transport!). RIP transmite si receptioneaza datagrame folosind portul UDP cu numarul 520.

Datagramele RIP contin maxim 512 octeti. Informatiile de actualizare mai mari decât aceasta dimensiune maxima sunt transmise în mai multe datagrame succesive. În retelele LAN, datagramele RIP sunt transmise folosind adresa de difuzare MAC si adresa de difuzare IP (MAC broadcast and IP broadcast). În cazul unei conexiuni punct la punct sau în retele fara difuzare, datagramele sunt adresate unei anumite destinatii. [1]

Pachetul RIP contine câmpurile cu urmatoarele semnificatii:

Comanda – acest câmp specifica rolul acestui pachet. Valoarea acestui câmp determina rolul pachetului RIP, dupa cum urmeaza:

Comanda = 1 – cerere catre nodul vecin de a trimite tabela de rutare, partial sau total.

Comanda = 2 – raspuns la cererea unui nod vecin sau un mesaj de actualizare generat la initiativa routerului sursa; acest pachet contine tabela de rutare, partial sau total.

Versiune – Întotdeauna cu valoarea 1, în cazul versiunii RIP-1.

AFI (Address Family Identifier) – Identificatorul modului de adresare si implicit, al protocolului rutat. RIP a fost proiectat pentru a ruta pachete pentru orice tip de protocol de nivel 3. În retelele Internet (protocolul IP) se utilizeaza valoarea 2 pentru acest câmp.

Pentru fiecare informatie de rutare definind ruta catre o anumita tinta se specifica perechea:

Adresa IP – adresa IP a retelei sau a unui statii de lucru (host) de destinatie.

Metrica – Metrica (de obicei, in numar de hop-uri) pâna la destinatia specificata în câmpul anterior. Valorile uzuale sunt între 1 si 15 (inclusiv), dar exista si valoarea 16 care specifica o destinatie inaccesibila.

Rezervat – aceste câmpuri sunt scrise cu valoarea 0.

Informatia de anuntare a unei rute începe cu câmpul AFI si se încheie cu câmpul de metrica (20 octeti pentru fiecare ruta). Un pachet de 512 octeti permite transmiterea a unui numar maxim de 25 de informatii de rutare în cadrul unui singur pachet RIP.

Modurile de operare RIP

Nodurile RIP au doua moduri de operare:

Modul activ: Nodurile care lucreaza în modul activ transmit tabelele lor de vectori distanta si receptioneaza actualizari de rutare de la nodurile RIP vecine. De obicei, router-ele sunt configurate sa functioneze implicit în modul activ.

Modul pasiv (silentios): Echipamentelele care lucreaza în acest mod, doar receptioneaza actualizari de rutare de la nodurile RIP vecine. Aceste echipamente nu transmit tabela de vectori distanta. De obicei, statiile de capat sunt configurate sa lucreze în modul pasiv.

Continutul tabelei de vectori distanta

Tabela de vectori distanta descrie fiecare retea de destinatie. Fiecare intrare din tabela contine urmatoarele informatii:

Adresa retelei/sistemului destinatie (vectorul) descrisa de aceasta intrare din tabela;

Costul asociat (distanta) caii preferate pentru a ajunge la aceasta destinatie. Aceasta determina capacitatea de a diferentia caile multiple catre o destinatie. În acest context, termenii de distanta si cost pot fi ambigui. Acestia nu au nici o legatura directa cu distanta fizica exprimata în metri sau cu costul exprimat într-o moneda.

Adresa IP a urmatorului ruter (next-hop) care trebuie utilizat pentru a ajunge la reteaua de destinatie.

Algoritmul de calcul al vectorilor distanta

De fiecare data când un nod primeste un mesaj de anuntare a unei tabele de rutare, acesta proceseaza informatiile din mesaj pentru a identifica existenta unei cai de cost mai mic catre fiecare destinatie cunoscuta. Aceasta functie este realizata cu ajutorul algoritmului vector distanta RIP.

Algoritmul este prezentat pe scurt în continuare:

La initializare, fiecare ruter contine o tabela de vectori distanta care specifica fiecare retea conectata direct si costul configurat. În mod uzual, fiecarei retele i se asociaza costul cu valoarea 1. Acest cost reprezinta o cale cu un singur nod intermediar pâna la destinatie. Numarul total de noduri intermediare (hop) dintr-o ruta este egal cu costul total al rutei. Totuși, costul poate fi modificat pentru a reflecta si alte masuri, cum ar fi: utilizarea, viteza sau fiabilitatea.

Fiecare ruter transmite periodic (uzual, la fiecare 30 de secunde) catre ruterii vecini tabela proprie de vectori distanța. Un ruter poate transmite tabela si atunci când se produce o modificare a topologiei. Fiecare ruter utilizeaza aceste informatii pentru a actualiza propria tabela de vectori distanta:

Costul total al căii pentru o anumita destinatie este calculat prin adunarea costului raportat în tabela transmisa de nodul vecin la costul legaturii cu acel nod. Calea cu costul minim este salvată în tabela de vectori distantă.

În tabela de vectori distanta toate informatiile de actualizare înlocuiesc informatiile anterioare. Aceasta functie permite ca RIP sa mentina integritatea rutelor din tabela de rutare.

Tabela de rutare IP este actualizata pentru a contine calea de cost minim catre fiecare destinatie.

Figura ce urmeaza ilustreaza tabelele de vectori distanta pentru trei ruteri dintr-o retea simplă:

Figura 6

Convergența algoritmului RIP

Dupa un interval de timp suficient de mare, algoritmul va calcula corect tabela de vectori distanta pentru fiecare nod. Totusi, pe durata acestui timp de convergenta, informatii despre rute eronate se pot propaga prin retea. Aceasta problema este prezentată grafic în figura de mai jos:

Figura 7

Limitarile RIP

S-au observat mai multe limitari în mediile cu RIP: [8]

Valorile limita ale costurilor rutelor: O solutie la problema numararii la infinit impune specificarea unui cost maxim pentru o ruta. Aceasta determina o limita superioara a diametrului retelei. Retelele care solicita rute cu mai mult de 15 noduri intermediare trebuie sa utilizeze un alt protocol de rutare.

Încarcarea retelei datorita actualizarii tabelelor: Difuzarea periodica a tabelelor de vectori distanta poate determina utilizarea excesiva a resurselor retelei. Aceasta poate crea problem pe anumite segmente de retea de capacitate redusa.

Convergenta relativ lenta: ca si alte protocoale de tip vector distanta, RIP converge relative lent. Acesti algoritmi depind de temporizatoare pentru a initia transmiterea mesajelor de actualizare a tabelelor de rutare.

Nu suporta subretele de dimensiune variabila (VLSM): mesajele de anuntare a rutelor nu includ masca subretelelor. Prin urmare, în retelele RIP este imposibila utilizarea VLSM.

Versiunea 2 a protocolului RIP (RIP-2)

Organizatia IETF (Internet Engineering Task Force) recunoaste doua versiuni ale protocolului RIP:

Versiunea 1 RIP (RIP-1): Acest protocol este descris în RFC (Request for Comments) 1058.

Versiunea 2 RIP (RIP-2): RIP-2 este tot un protocol de tip vector distanta proiectat pentru rutarea în interiorul unui SA. RIP-2 este descris în RFC 2453 si vizeaza rezolvarea problemelor observate în cazul RIP-1. [7]

RIP-2 este similar cu RIP-1, dar prezinta în plus urmatoarele avantaje:

Suporta CIDR si VLSM: RIP-2 suporta super-retelele (CIDR) si subretelele de dimensiuni variabile (VLSM). Acesta este motivul principal pentru dezvoltarea acestui nou standard.

Transmisiunile multicast: RIP-2 transmite mesajele de anuntare a rutelor sub forma de multicast în locul difuzarii. Aceasta reduce încarcarea statiilor de lucru, care nu mai interpreteaza mesajele RIP-2.

Autentificare: RIP-2 suporta autentificarea fiecarui nod care transmite mesajele de anuntare a rutelor. Aceasta previne ca surse neautorizate sa modifice tabelele de rutare. [9]

Compatibilitate cu RIP-1.

Asa cum s-a prezentat in subcapitolele anterioare, un dezavantaj al protocolului RIP-1 este definirea unui câmp de metrica, cu valori între 1 si 16.Pentru a se asigura compatibilitatea cu RIP-1, în RIP-2 se pastreaza aceeasi notare a metricii. Astfel, în ambele variante de RIP, rutele cu mai mult de 15 noduri intermediare sunt interpretate ca fiind inaccesibile.

Open Shortest Path First (OSPF)

Open Shortest Path First (OSPF) este un protocol cu starea legăturilor dezvoltat pentru TCP/IP . Se folosește in rețele foarte mari și dispune de de cîteva avantaje față de RIP . Similar cu Interior Gateway Routing Protocol (IGRP), OSPF a fost creat deoarece la mijlocul anilor ‘80, Routing Information Protocol (RIP) a devenit incapabil să servească inter-rețele mari, eterogene. OSPF are două mari caracteristici. Prima este ca protocolul este deschis, ceea ce înseamnă ca specificațiile sale sunt de domeniu public. A doua caracteristică principală este că se bazează pe algoritmul SPF (Shortest Path First). [2]

Ideea principală: în loc de a schimba informații despre distanțele pana la destinații (ca în cazul protocolului RIP ) toate nodurile vor menține hărți specifice ale rețelei care sunt revizuite după fiecare schimbare din topologie; aceste hărți sunt mai apoi folosite pentru a determina rute care sunt mai fiabile decat cele în cazul protocoalelor cu vectori-distanță; rutele determinate de OSPF par a fi la fel de precise ca și cele determinate central, totuși această determinare fiind distribuită. Astfel, spre deosebire de RIP, OSPF împarte informații despre vecinii săi cu întreaga rețea (cel mult un singur sistem autonom). RIP nu încearcă să învețe despre întreaga rețea Internet, iar OSPF nu încearcă să se promoveze in intregul Internet. Nu aceasta este menirea lor. Ele sunt protocoale de rutare interne; astfel, slujba lor este de a construi rutarea in cadrul unui sistem autonom. [6]

Cele mai importante avantajeale protocolului OSPF sunt facilitățile de securitate, facilități de căi multiple, facilități in ceea ce privește utilzarea metricilor de costuri diferite, suport integrat atît pentru rutarea unicast, cît și pentru cea multicast, convergență rapidă.

Ca si RIP, OSPF este un protocol bazat pe un standard (open) astfel încît este posibila interoperarea între mai multi producatori de rutere. Algoritmul pentru determinarea distanței minime între oricare 2 noduri (shortest path) este algoritmul Dijkstra.

În mod clar, OSPF dispune de multă flexibilitate pentru a subdiviza un sistem autonom. Dar este oare necesar? O problemă a protocolului cu legare de stare este cantitatea mare de date care poate fi colectată în baza de date cu și de timpul prea lung care este necesar pentru a calcula rutele pentru acele date.

OSPF este probabil cel mai folosit protocol IGP în retele de dimensiuni mari. În contrast cu RIP sau BGP, OSPF nu folosește TCP sau UDP dar folosește direct protocolul IP 89. OSPF domină protocoalele de rutare IGP, mai ales în rețele Enterprise.

Protocoalele de rutare care utilizează starea legăturii mențin la nivelul fiecărui router o

bază de date complexă, cu informații despre toate routerele din rețea, nu numai despre cele învecinate.

Pe baza grafului rețelei, se aplică algoritmul de deducere a căii minime și se stabilește ruta optimă pentru fiecare rețea de destinație. În cazul schimbării topologiei rețelei, actualizarea tabelelor de rutare se face relativ rapid.

Protocolul de rutare dinamică OSPF (Open Shortest Path First) se aplică în rețelele mari ca număr de noduri, inclusiv pe subrețele, cu autentificarea datelor, iar rutarea și rerutarea pachetelor se face mai rapid decât prin RIP, definindu-se arii de acoperire pentru fiecare router.

Acest protocol este de tip IGRP și a fost special proiectat pentru rutare în rețelele care utilizează TCP/IP. Fiecare router intern din sistemul autonom (AS – Autonomous System) deține o bază de date proprie în care sunt incluse informații privind starea interfețelor routerului, routerele vecine și altele. Routerele vecine se informează reciproc prin flooding numai dacă apar modificări în tabelele proprii de rutare, în care se precizează pentru fiecare rută, suplimentar față de RIP, costul și lățimea de bandă disponibilă. Interconectarea ariilor de acoperire din sistemele autonome, se face prin intermediul unor routere AS desemnate (boundary router) iar între AS-uri se utilizează routere externe (external router) care permit transferul unor pachete la distanțe mari în WAN. Deducerea rutei optime se face pe baza unor arbori de acoperire a AS, în care nu apar bucle iar routerele externe sunt noduri terminale în 'arbore'.

Calea spre destinație poate fi de tip:

INTRA – în interiorul unei singure arii din AS;

INTER – traversează mai multe arii din același AS fără a traversa un router de la granița AS;

EXT1 – calea trece printr-un router din AS și rămâne în interiorul AS. Se utilizează două metrici, metrica OSPF internă și cea a routerului AS, pentru a deduce ruta optimă.

EXT2 – calea trece dintr-un AS în altul printr-un router extern, deci se combină metrica OSPF internă cu cea a routerului EGP (External Gateway Protocol) pentru găsirea rutei optime.

Protocoalele RIP sunt orientate pe vectori de distanță și utilizează numai informațiile furnizate de routerele adiacente, în timp ce OSPF este orientat pe starea legăturii dintre noduri (LST – Link State Technology) și permite optimizarea transferului pe baza informațiilor deținute de toate routerele din WAN. Routerele OSPF admit importul și exportul de informații din și spre un router RIP.

Principalele caracteristicile ale OSPF

OSPF implementeaza un numar de functii pe care protocoalele de tip vector distanta nu le prezinta. Astfel, OSPF a devenit cel mai utilizat protocol de rutare în retelele de dimensiuni mari. Functiile care au contribuit la succesul standardului OSPF:

Echilibrarea încarcarii retelei pentru cai de cost egal (Equal cost load balancing): Utilizarea simultana a cailor multiple permite utilizarea mai eficienta a resurselor retelei.

Divizarea logica a retelei (Logical partitioning of the network): Aceasta functie reduce propagarea informatiilor neactualizate în cazul unor conditii defavorabile (modificari de topologie). De asemenea, permite cumularea anunturilor de rutare (aggregate routing announcements) care limiteaza anuntarea informatiilor inutile.

Mecanisme de autentificare: OSPF permite autentificarea fiecarui nod care transmite mesaje de anuntare a rutelor. Aceasta previne ca surse frauduloase (ruteri neautorizati) sa modifice continutul tabelelor de rutare.

Timp de convergenta mai mic: OSPF permite propagarea instantanee a informatiilor despre modificarea rutelor. Astfel, actualizarea informatiilor de topologie se realizeaza mult mai rapid.

Suporta CIDR si VLSM: Aceste functii permit o alocare eficienta a adreselor IP.

OSPF este un protocol de tip stare a legaturii (link state). Fiecare ruter OSPF executa algoritmul SPF (Shortest-Path First), pentru a procesa informatiile salvate în baza de date a starilor legaturilor (link state database). Algoritmul genereaza arborele de cai minime (shortest-path tree) care prezinta rutele optime catre toate retelele de destinatie.

Terminologia OSPF

OSPF utilizeaza o terminologie specifica pentru a descrie functionarea protocolului.

Figura 8

Ariile OSPF

Retelele OSPF sunt divizate în mai multe arii. O arie reprezinta o grupare logica de retele si routere. O arie poate coincide cu o zona geografica sau administrativa. Fiecare arie este identificata unic prin intermediul unui identificator de 32 de biti, denumit ID arie. Aceasta divizare a retelei în arii logice determina urmatoarele avantaje: [10]

Într-o arie, fiecare router mentine o baza de date a topologiei (topology database) care descrie ruterii si legaturile din aceasta arie. Acesti ruteri nu detin informatii despre topologii aflate în exteriorul ariei, ci detin numai rutele catre aceste destinatii externe. Astfel, se reduc considerabil dimensiunile bazei de date a topologiei, detinute de fiecare ruter.

Divizarea în arii reduce posibila crestere a numarului de actualizari de stare a legaturilor. Astfel, cele mai multe LSA sunt distribuite numai în interiorul unei arii.

Se reduce timpul de procesare CPU necesar pentru a mentine baza de date a topologiei. Algoritmul SPF se limiteaza la a administra modificarile numai dintr-o arie.

Aria coloana vertebrala (Backbone) si aria 0

Toate retelele OSPF contin cel putin o singura arie. Aceasta arie este aria 0 sau aria coloana vertebrala (backbone). Se pot adauga si alte arii, în functie de topologia reala a retelei sau de alte cerinte de proiectare.

În retelele care contin mai multe arii, aria backbone se conecteaza fizic cu toate celelalte arii. Toate ariile vor anunta informatiile de rutare, direct în backbone. Apoi, din backbone se vor transmite aceste informatii catre celelalte arii.

Baza de date a starilor legaturilor

Baza de date a starilor legaturilor mai este denumita si baza de date a topologiei (topology database). Aceasta contine setul de anunturi de stare a legaturii care descrie reteaua OSPF si fiecare conexiune externa. Fiecare ruter dintr-o arie mentine o copie identica a bazei de date a starilor legaturilor.

Anunturile de stare a legaturii (LSA) și inundarea

Continutul unui mesaj LSA (Link-State Advertisement) descrie o componenta a retelei, care poate fi: un ruter, un segment sau o destinatie externa. Mesajele LSA sunt schimbate de catre ruterii OSPF adiacenti pentru a sincroniza între ele bazele de date ale starilor legaturilor. [11]

Atunci când un ruter genereaza sau modifica un mesaj LSA, acesta trebuie sa comunice aceasta modificare în cadrul retelei. Mai întâi, routerul transmite mesajul LSA fiecarui sistem adiacent. La receptionarea LSA-ului, acesti vecini salveaza informatia în propriile baze de date a starilor legaturilor si la rândul lor, comunica LSA-ul vecinilor lor. Aceasta activitate de tipul “salveaza si trimite mai departe” (store and forward) continua pâna când toate sistemele primesc acest LSA. Acest proces poarta numele de inundare eficienta (reliable flooding), deoarece se parcurg urmatorii doi pasi pentru a asigura transmiterea LSA în toata reteaua fara a supraîncarca cu trafic de volum mare:

Fiecare ruter salveaza mesajul LSA pentru un interval de timp înainte de a propaga informatia catre vecinii sai. Daca pe durata acestui interval de timp, routerul primeste o noua versiune a LSA, acesta înlocuieste versiunea salvata. Totusi, noua LSA este ignorata daca este mai veche decât prima.

Pentru a creste fiabilitatea, fiecare LSA este confirmata. De asemenea, se pot grupa mai multe confirmari într-un singur pachet de confirmare. Daca nu se primeste confirmarea pentru un LSA, atunci se retransmite acel LSA.

În functie de rolul acestora, mesajele LSA sunt de cinci tipuri, iar toate aceste tipuri împreuna furnizeaza toate informatiile necesare pentru a descrie întreaga retea OSPF si toate mediile externe:

LSA-uri de ruteri: Aceste mesaje descriu starea interfetelor ruterilor (si implicit a legaturilor acestora) dintr-o arie. Aceste LSA sunt generate de catre fiecare ruter prin inundarea ariei respective.

LSA-uri de retea: Acest tip de mesaj descrie ruterii conectati la o retea de acces multiplu. Aceste mesaje sunt generate de DR într-un segment de acces multiplu si cu aceste mesaje se inunda toata aria.

LSA-uri concentrate (Summary LSA) – Tipul 3 si 4. Aceste LSA sunt generate de un ABR si sunt de doua tipuri:

LSA-uri concentrate – Tipul 3 descriu rute catre destinatii aflate în alte arii din cadrul retelei OSPF (destinatii inter-arii).

LSA-uri concentrate – Tipul 4 descriu rute catre ruteri ASBR. [1]

LSA-urile concentrate sunt utilizate pentru a schimba informatiile despre accesibilitate între arii diferite. De obicei, aceasta informatie este transmisa în aria backbone, iar backbone-ul transmite informatia catre alte arii.

LSA-uri pentru SA externe: Acest tip de mesaj descrie rute catre destinatii aflate în exteriorul retele OSPF si sunt generate de un ASBR. Mesajele sunt transmise prin inundarea tuturor ariilor din reteaua OSPF. Figura 8 ce urmeaza ilustreaza tipurile de mesaje LSA:

Figura 9

Tipuri de pachete OSPF

Pachetele OSPF sunt transmise în datagramele IP si nu sunt incaptulate în pachetele TCP sau UDP. Antetul IP contine în câmpul de identificare a protocolului valoarea 89. De asemenea, valoarea câmpului care defineste tipul serviciului (type of service) are valoarea 0. Acest mechanism este utilizat pentru a impune o procesare speciala a pachetelor. Atunci când este posibil, un ruter OSPF utilizeaza transmisia multipla (multicast) pentru a comunica cu ruterii vecini.

În retelele cu difuzare si în configuratiile punct-la-punct, pachetele transmise au adresa de destinatie de tip multicast 224.0.0.5. În mediile fara difuzare pachetele sunt transmise cu adresa IP de destinatie a routerului vecin (unicast). [3]

Toate pachetele OSPF au acelasi antet, care este ilustrat în figura 10. Antetul contine informatii generale, cum ar fi: identificatorul ariei, RID, suma de verificare si informatia de autentificare.

Figura 10

Câmpul “Tip pachet” identifica pachetul OSPF, dintre cele cinci posibile tipuri diferite:

Hello – Acest tip de pachet este utilizat pentru descoperirea si mentinerea relatiilor dintre vecini

Descrierea bazei de date (Database description) – Acest tip de pachet descrie setul de LSAuri continute în baza de date a starilor legaturilor, a routerului;

Cerere stare legatura (Link state request) – Acest tip de pachet solicita o varianta mai noua a unei LSA de la un vecin;

Actualizare stare legatura (Link state update) – Acest tip de pachet ofera o varianta noua a unei LSA catre un vecin (eventual, care a efectuat o cerere);

Confirmare stare legatura (Link state acknowledgement) – Acest tip de pachet confirma receptionarea unei noi LSA.

Descoperirea vecinilor: Protocolul Hello-OSPF

Protocolul Hello are ca functii descoperirea si mentinerea relatiilor dintre nodurile vecine. Pachetele Hello sunt transmise periodic pe fiecare interfata a routerului. Pachetele contin identificatorii RID ai altor ruteri, ale caror pachete Hello au fost deja receptionate pe interfata respective. [10]

Atunci când un ruter descopera propriul RID în pachetul generat de un alt ruter, aceste doua noduri stabilesc relatia de învecinare.

Pachetul Hello contine si prioritatea routerului, identificatorii DR si BDR. Acesti parametri sunt utilizati pentru a alege routerul DR în reteaua de acces multiplu.

Redistribuirea rutelor OSPF

Redistribuirea rutelor este procesul prin care se introduc rutele externe într-o retea OSPF. Aceste rute pot fi rute statice sau rute învatate prin intermediul altui protocol de rutare. Aceste rute sunt anuntate într-o retea OSPF de catre un ruter ASBR si devin rute OSPF externe. Routerul ASBR anunta aceste rute prin inundarea întregii retele OSPF cu LSA-uri pentru SA externe. [12]

Rutele descriu o cale capat-la-capat care este formata din doua parti:

Portiunea externa: Aceasta defineste portiunea de cale din afara retelei OSPF. Atunci când aceste rute sunt distribuite în reteaua OSPF, routerul ASBR le asociaza un cost initial. Acest cost reprezinta costul extern asociat parcurgerii portiunii externe a caii.

Portiunea interna: Aceasta defineste portiunea de cale din interiorul retelei OSPF. Costurile acestei portiuni sunt calculate folosind algoritmii OSPF standard.

Protocolul OSPF diferentiaza doua tipuri de rute externe. Acestea difera prin modul în care se calculeaza costul rutei. Routerul ASBR este configurat sa redistribuie rute, dupa cum urmeaza:

Tipul 1 de ruta externa (E1): Costul total al rutei este suma dintre costul extern si orice cost intern OSPF.

Tipul 2 de ruta externa (E2): Costul total al rutei reprezinta întotdeauna numai costul extern. Astfel, este ignorat orice cost intern OSPF, de acces din interior pâna la routerul ASBR.

Sumarizarea rutelor OSPF

Sumarizarea rutelor reprezinta procesul prin care mai multe informatii consecutive (în tabela de rutare) de rutare sunt combinate si transmise împreuna într-un singur anunt. Acest proces permite reducerea dimensiunilor bazei de date a starilor legaturilor si a tabelei de rutare IP. Într-o retea OSPF, sumarizarea este efectuata de catre un ruter de granita. Astfel, exista doua tipuri de sumarizari:

Sumarizarea rutelor dintre arii diferite (Inter-area route summarization): Sumarizarea aceasta este efectuata de routerul ABR al acelei arii. Sumarizarea se aplica anunturilor informatiilor de rutare generate din interiorul ariei. Ruta sumarizata este anuntata în reteaua coloana vertebrala, care la rândul ei, transmite anuntul sumarizat în celelalte arii.

Sumarizarea rutelor externe (External route summarization): Sumarizarea aceasta se aplica numai rutelor, injectate în reteaua OSPF. Aceasta sumarizare este realizata de routerul ASBR care distribuie rutele în reteaua OSPF.

În figura 11 este ilustrat un exemplu de sumarizare a rutelor OSPF.

Figura 11

Autentificarea

Este de preferat autentificarea informațiilor de rutare. RIPv2, EIGRP, OSPF, IS-IS și BGP pot fi configurate să cripteze și să autentifice informațiile de rutare. Se poate preveni astfel primirea de informații de rutare frauduloase. Routerul autentifică sursa și dacă acest proces este realizat, atunci routerul poate folosi cu incredere informațiile primite.

OSPF-ul suportă doua tipuri de autentificare:

cu parola simplă

autentificare de tip MD5 (Message Digest 5) [9]

Enhanced Interior Gateway Routing Protocol – (EIGRP)

EIGRP a fost dezvoltat de către Cisco (eliberat la începutul anilor ‘90) cu scopul de a îmbunătăți protocolul RIP pe vremea cînd IETF (Internet Engineering Task Force) încă lucra la dezvoltarea OSPF-ului. EIGRP este un protocol brevetat. Acest protocol elimină unele dintre defectele protocolului RIP, și are îmbunătățiri ca folorirea de metrici compuse, rutarea pe căi multiple, și mânuirea rutelor implicite. [4]

Evoluția protocolului EIGRP furnizează compatibilitate și operații precise cu rutere EIGRP. Capacități cheie care disting EIGRP de alte protocoale de rutare includ convergența rapidă, support pentru mască de subrețea variable-length, support pentru update, și support pentru multiple protocoale de la nivelul rețea. EIGRP are toate avantajele flexibilității și ale configurării simple în timp ce îmbunătățește viteza și consumarea resurselor. De altfel, este capabil a fi un protocol unic atît pentru IP cît și pentru protocoale non- IP, eliminînd nevoia de a folosi multiple protocoale de rutare într-o rețea multi-protocol. Acest protocol de rutare este unul dintre cele mai diversificate și robuste protocoale de rutare. Combinația sa unica de caracteristici îmbină cele mai bune atribute ale protocoalelor de vector-distanță cu cele mai bune atribute ale protocoalelor cu starea legăturilor.

Rezulatul este un protocol de rutare hibrid care sfidează împărțirea pe categorii a protocoalelor convenționale.

Poate fi folosit împreunpă cu IPv4, AppleTalk, și IPX. Mai important, arhitectura sa modulara va permite ca Cisco să adauge suport pentru alte protocoale de rutare importante care vor apărea în viitor. Spre deosebire de alte protocoale de rutare bazate pe vectori-distanta, EIGRP nu mandatează o revizuire periodică al tabelelor de rutare între rutere vecine. În schimb, folosește un mecanism de descoperire/recuperare pentru a asigura că vecinii sunt conștienți de accesibilatea fiecaruia in parte.

Ca și alte protocoale de rutare, EIGRP poate fi setat pentru autentificare. RIPv2, EIGRP, OSPF, IS-IS și BGP toate pot fi setate pentru a cripta și autentifica informația rutată. A autentifica informația rutată este o practică bună. Această practică asigură faptul că routerele vor accepta informație doar de la alte routere care au fost configurate cu aceeași semnătură sau informație autentificată. De notat faptul ca autentificarea nu criptează și tabela de rutare a ruterului.

Pachetele EIGRP

Pachetele transmise prin protocolul EIGRP sunt: [13]

Pachetul Update

Pachetul Query

Pachetul Reply

Pachetul Hello

Pachetele Update sunt utilizate de EIGRP pentu a propaga informația de rutare. EIGRP nu trimite reactualizări regulate, ele se trimit doar când apare o modificare de topologie. Aceste reactualizări sunt trimise doar routerelor care au nevoie de ele(muticast sau unicast). Aceste pachete folosesc primirea unei confirmări (ACK). Pachetele ACK sunt pachete trimise atunci când se folosește opțiunea de primire a unei confirmări pentru pachetele de tip Update, EIGRP, Query și Reply.

Pachetele Query și Reply (Interogare și răspuns) sunt utilizate de algoritmul DUAL. Pachetele Query pot fi trimise Unicast (către un singur host) și Multicast (către mai multe hosturi din rețele precizate), în timp ce pachetele Reply sunt trimise mereu Unicast. Când un router pierde o cale, atunci el trimite pachete de tip Query către vecini, prin care cere o altă cale prin altă rețea. Routerele care au primit pachet de tip Query trimit o confirmare (ACK). EIGRP-ul accesează routerele, trimite câte un Reply chiar dacă au sau nu o rută către rețeaua care a căzut. Pentru că Reply utilizează primirea cu confirmare, routerul va trebui să trimită înapoi o confirmare (ACK).

Pachetele Hello sunt utilizate pentru a descoperi vecinii și sunt pachete MULTICAST, fără confirmare.

Caracteristici EIGRP

EIGRP include câteva caracteristici care nu se regăsesc în alte protocoale de tip ”distance vector” precum RIP și IGRP.

Aceste caracteristici includ:

Protocol de transport sigur – Reliable Transport Protocol(RTP)

Reactualizari legate – Bounded Updates

Algoritmul DUAL

Stabilirea adiacențelor

Tabele privind topologia și vecinii

RTP (Reliable Transport Protocol) este un protocol folosit de EIGRP pentru trimiterea și primirea pachetelor care cer confirmare(reliable) sau celor care nu cer confirmare (unreliable). Protocoul RTP cere confirmări de la receptor la transmițător. RTP poate trimite pachete unicast sau multicast. [2]

Reactualizarea parțială conține informații doar despre ruta care s-a schimbat astfel consumându-se mai putina largime de bandă (Bandwidth). Reactualizările legate se referă la propagarea unei reactualizări parțiale doar către acele routere care sunt afectate de schimbările produse.

Algoritmul DUAL previne crearea de bucle în rețea și, de asemenea, permite tuturor routerelor implicate în schimbarea de topologie, să se sincronizeze în același timp rezultând o convergența (apare la momentul cand toate routerele dintr-o rețea și-au „învățat” toți vecinii existenți la acel moment) rapidă.

Înainte ca orice pachet EIGRP să fie schimbat între routere, EIGRP trebuie mai întâi să își cunoască toți vecinii.Vecinii EIGRP sunt alte routere direct conectate la rețea. Routerele EIGRP descoperă vecinii și stabilesc routerele vecine cu ajutorul pachetului Hello. In majoritatea rețelelor EIGRP, pachetele Hello sunt trimise la fiecare 5 secunde. Un router cu EIGRP consideră că atâta timp cât primește pachete Hello de la un alt router, vecinul și rutele lui rămân valide. HOLDTIME-este timpul maxim așteptat de un router până să primeasca următorul pachet Hello. [4]

Metrica și distanța administrativă

EIGRP are o distanță administrativă implicită, 90 pentru surse interne și 170 pentru rute importate de la o sursă externă. Distanța administrativă este un număr natural atribuit unei rute si indică cat de „sigură” este acesta. În practică,distanța administrativă este folosita atunci când doua rute catre aceeași detinație au aceeași metrică si este astfel dificil de a alege una dintre ele în îndrumarea pachetelor.Astfel, pachetele vor fi trimise pe ruta care are cea mai mică distanță administrativă.

Prin comparație cu alte protocoale IGP(Interior Gateway Protocol), EIGRP este cel preferat de Cisco IOS (Internetwork Operating System) pentru că are cea mai mică distanță administrativă.

EIGRP face parte din clasa protocoalelor de tip “distance vector” și a fost emis în anul 1992. EIGRP este o îmbunătățire a protocolului IGRP, ambele fiind proprietare CISCO și pot opera doar pe ruterele CISCO. Deși EIGRP se comportă ca un protocol de rutare „link state”, el este un protocol de rutare „distance vector”. Metricile folosite de EIGRP sunt calculate în functie de următorii parametrii: [1]

bandwidth = (10000000/bandwidth(i)) * 256 ( unde bandwidth(i) este valoarea (în kbps) cea mai mică a lărgimii de bandă pentru interfețele către rețeaua destinație pentru care se calculează metrica )

delay = delay(i) * 256 ( unde delay(i) este suma întârzierilor pentru interfețe pe calea către rețeaua destinație pentru care se calculează metrica)

load (1-255) (gradul de folosire a interfeței către rețeaua destinație)

reliability (255-1) (gradul de siguranță a interfeței către rețeaua destinație)

Formula de calcul pentru metrica este: [1]

unde valorile K1 – K5 pot fi modificate de un administrator de retea. Termenul care-l contine pe K5 nu va fi luat in considerare deoarece este egal cu 1. In configuratia sa initiala EIGRP are valorile K1 si K3 egale cu 1 si K2 si K4 egale cu 0 ceea ce face ca formula initiala sa se reduca la (latimea de banda + delay-ul) x 256 . Este evident ca toate router-ele pe care este pornit EIGRP-ul trebuie sa aiba aceleasi valori ale K1-K5 pnetru a forma o adiacenta.

Latimea de banda si delay-ul se calculeaza pentru router-ele Cisco folosind formulele:

Latimea de banda in EIGRP = 107 / latimea de banda a interfetei

Delay-ul in EIGRP = Delay-ul interfetei / 10

Atat delay-ul cat si latimea de band ape o interfata Cisco se pot configure de un administrator de retea pentru ca folosind formulele de mai sus sa se ajunga la valori ale metricii dorite pentrubalansarea si controlul traficului intr-o retea cu EIGRP.

EIGRP-ul mentine deasemenea si informatia privind numarul de hop-uri la care se afla o retea departata dar aceasta valoare nu este folosita la calcularea metricii. Este totusi folosita in cazul in care numarul de hop-uri depaseste un maxim definit de EIGRP (care standard este 100 si poate fi configurat pana la 255) si atunci ruta este trimisa catre vecini ca fiind indisponibila.

Concepte EIGRP

EIGRP se bazeaza pe patru concepte fundamentale: tabele de vecini (neighbor tables), tabele de topologie (topology tables), statutul rutelor (route states) si etichetarea rutelor (route tagging). [14]

Neighbor tables (tabela vecinilor)

Când un router descopera un nou vecin, inregistreaza adresa si interfata vecinului in neighbor table. Câte o tabela neighbor exista pentru fiecare modul dependent de protocol. Tabela neighbor mai contine si informatii necesare protocolului RTP.

Topology tables (tabela de topologie)

Aceasta tabela contine toate destinatiile publicate de routerele vecine. Modulele dependente de protocol populeaza tabela si ea este folosita de DUAL finite-state machine. Fiecare inregistrare din tabela include adresa destinatiei si o lista de vecini care au publicat destinatia. Pentru fiecare vecin este inregistrata si metrica publicata de acesta. O regula importanta pentru protocoalele distance-vector este ca daca vecinul publica aceasta destinatie, atunci inseamna ca el foloseste ruta publicata pentru trimiterea pachetelor la acea destinatie.Metrica pe care routerele o folosesc ca sa ajunga la o destinatie este asociata cu acea destinatie. Metrica pe care routerul o foloseste in tabela de routare (si pe care o publica altor routere) este suma dintre cea mai buna metrica dintre metricile publicate de vecini si costul legaturii la acel cel mai bun vecin.

Route states (Starile rutelor)

O inregistrare in topology-table pentru o destinatie poate fi in una din starile: activa (active) sau pasiva (passive). O destinatie este in starea pasiva (passive state), cand routerul nu efectueaza recalculari (recomputations) si este in starea activa (active state), cand routerul face o recalculare. Daca feasible successors sunt mereu disponibili, o destinatie nu este nevoita sa intre in starea activa, deci evita o recalculare. O recalculare se declanseaza cand o destinatie nu are feasible successors. Routerul initiaza recalcularea prin trimiterea unor cereri (queries) la toti vecinii sai. Routerele vecine pot trimite pachete raspuns (reply pachets), indicand un feasible successor pentru destinatie sau pot trimite la randul lor pachete queries, indicand participarea in recalculare. In timp ce o destinatie este in starea activa, un router nu poate schimba informatiile din tabela de routare ale acelei destinatii. Dupa ce un router a primit un reply de la fiecare vecin, inregistrarea din topology-table pentru destinatie revine la starea pasiva si routerul poate alege un succesor.

Route tagging (Marcarea rutelor)

EIGRP suporta rute interne si externe. Rutele interne sunt continute intr-un sistem autonom EIGRP. Deci, o retea atasata direct, configurata sa foloseasca EIGRP este considerata o ruta interna si se propaga aceasta informatie in tot sistemul autonom EIGRP. Rutele externe sunt invatate prin intermediul unui protocol extern sau exista in tabelele de routare ca rute statice. Aceste rute sunt etichetate individual cu identitatea originii lor. Rutele externe sunt marcate cu urmatoarele informatii: [15]

ID-ul router-ului care face redistributia rutelor prin EIGRP

Numarul AS al destinatiei

O notatie configurabila de administrator

ID protocolului extern din care se redistribuie ruta

Metrica rutei primita din protocolul extern

Marcarea sau tagg-uirea rutelor permite administratorului de retea sa customizeze rutarea si sa implementeze politici flexibile de rutare.

3

Protocoale de rutare externă

BGP (Border Gateway Protocol) este protocolul de rutare folosit in nucleul Internetului. El menține o tabela cu rețele IP (sau "prefixe") care arata calea folosita pentru a ajunge la rețeaua respectiva prin diferitele sisteme autonome (AS). BGP este considerat din acest motiv un protocol de rutare vector-cale (spre deosebire de protocoalele vector-distanța, care nu pastreaza toata calea). BGP nu folosește aceleași metrici ca protocoalele de rutare folosite in interiorul AS-urilor, ci ia decizii bazându-se pe cale și pe politicile de rutare ale sistemului autonom din care face parte.

Cei mai mulți utilizatori de Internet nu folosesc in mod direct acest protocol. Totuși, deoarece majoritatea Internet Service Provider-ilor il folosesc pentru a stabili rute intre rețelele respective, BGP este unul din cele mai importante protocoale de pe Internet. Importanța sa este comparabila cu a protocolului SS7 pentru stabilirea apelurilor telefonice intre operatorii PSTN. Rețelele IP de mari dimensiuni folosesc BGP inclusiv in interiorul rețelei, de exemplu pentru a lega mai multe subrețele suficient de mari pentru ca protocolul de rutare OSPF sa-și atinga limitele. Alt caz de utilizare il reprezinta conectarea mai multor puncte de prezența ale unui singur furnizor de acces Internet. [1]

Internetul este o colecție de sisteme autonome care sunt interconectate pentru a permite comunicația prin ele. BGP-ul ofera rutarea prin aceste sisteme autonome.

Figura 12: Sisteme autonome

eBGP si iBGP

Cand BGP este rulat in interioriul unui sistem autonom, este folosit termenul iBGP (Internal Border Gateway Protocol). Cand este rulat intre AS-uri, este numit eBGP (External Border gateway Protocol). In majoritatea ruterelor actuale, distanța administrativa (DA) pentru iBGP este mai mare (deci prioritatea este mai mica) decat cea pentru alte protocoale de rutare intra-AS, care la randul lor au DA mai mare decat eBGP.

Vecinii eBGP trebuie sa fie direct conectați pentru a fi realizata conexiunea BGP, dar exista și excepții. De exemplu, impementarile Cisco au opțiunea "multihop", care permite realizarea de conexiuni eBGP catre rutere nelegate direct. Aceasta limitare nu exista pentru iBGP. Pentru a asigura rutarea intre toate nodurile din rețea care ruleaza BGP poate fi folosit un protocol de rutare IOP (OSPF, RIP etc.). [4]

In mod normal, un ruter iBGP menține sesiuni cu toate celelalte rutere iBGP din AS, formand o topologie logica full-mesh (fiecare cu fiecare). Acest lucru este necesar deoarece, pentru a preveni formarea de cicluri de rutare, iBGP nu transmite rute invațate prin iBGP altor vecini care ruleaza iBGP[16]. Daca se dorește ca ruterele iBGP să schimbe rute BGP intre ele, este necesara configurarea de reflectori de rute (route reflector) sau confederații. [17]

Cand un router afla despre o ruta noua prin protocolul eBGP, va seta adresa urmatorului hop la adresa ruterului vecin eBGP de la care a aflat ruta respectiva. Cand se primesc rute din interiorul AS-ului, adresa urmatorului hop ramane neschimbata.

Figura 13: eBGP și iBGP

Tipuri de mesaje BGP

Protocolul BGP folosește patru tipuri de mesaje pentru a menține sesiunile in mod corespunzator: [18]

Open: mesajele inițiale, folosite pentru stabilirea conexiunii intre rutere; daca un ruter primește un mesaj 0pen și este de acord cu conținutul, trebuie sa raspunda cu un mesaj Keepalive.

Keepalive: mesaje de 19 octeți trimise periodic (implicit la 60 de secunde -o treime din timpul de hold-down) pentru menținerea conexiunii deschise; aceste mesaje sunt trimise fara confirmare, iar daca intervalul de trimitere este setat la 0, nu se trimit.

Update (Actualizare): conțin cai catre diversele rețele (accesibile, invalide sau retrase), impreuna cu atributele corespunzatoare; inițial, ruterele BGP iși trimit reciproc intreaga tabela de rutare; dupa actualizarea inițiala, se transmit actualizari incrementale, pe masura ce topologia rețelei se schimba.

Notification (Notificari): raporteaza eventualele erori aparute in comunicație

Din momentul in care sesiunea BGP funcționeaza, routerele schimba mesaje de tip UPDATE cu privire la destinațiile catre care expeditorul ofera conectivitate. In protocolul BGP, descrierea unei rute este numita Informație de cale de nivel rețea (Network Layer Reachability Information -NLRI). NLRI include mai multe atribute: prefixul destinație, lungimea prefixului, calea de sisteme autonome catre destinație și urmatorul hop, pecum și multe alte informații care afecteaza felul cum trateaza destinatarul rețeaua respectiva. Routerele BGP anunță apoi, prin actualizari ulterioare,noile rețele catre care ofera conectivitate, dar și "retragerile" (rețelele care nu mai sunt accesibile).

Caracteristici BGP

Conectivitate si invatarea rutelor

In cea mai simpla metoda de configurare, toate ruterele dintr-un AS care ruleaza BGP sunt conectate fiecare cu fiecare. Acest lucru provoaca grave probleme de scalabilitate, deoarece numarul de conexiuni crește cu patratul numarului de rutere conectate. Pentru a evita aceasta problema au fost oferite 2 soluții: reflectorii de rute [19] și confederațiile [17].

Tabela de rutare

Implementarea de BGP de pe ruterele Cisco, dar nu numai, pastreaza o tabela de cai BGP separata de tabela de rutare și numita Loc-RIB (Local Routing Information Base). Unele implementari pastreaza tabele per vecin, conținand NLRI-urile trimise/primite de la acel vecin. Structura interna a acestor tabele nu este vizibila vecinilor BGP, ci doar pe ruterul local.

In tabela de rutare a ruterului sunt ținute doar rutele optime catre o destinație. In schimb, tabela BGP va conține toate rutele primite prin BGP. Trecerea unei rute din tabela BGP in tabela de rutare se face astfel:

pentru eBGP, rutele sunt puse automat in tabela de rutare (daca nu este direct conectata)

pentru iBGP, ruta este pusa in tabela de rutare daca sunt indeplinite mai multe condiții:

exista o inregistrare in tabela de rutare catre urmatorul hop din calea BGP

ruta este aflata și prin intermediul unui IOP sau sincronizarea este dezactivată

Un anumit ruter BGP poate accepta cai BGP de la mai mulți vecini și poate trimite actualizari acelora și vecini sau altora.

O greșeala frecventa in ceea ce prive te BGP-ul este sa se spuna ca "BGP transmite politici". De fapt, BGP transmite doar informații pe care procesele BGP le aplica unor reguli pentru a lua decizii de rutare. Unele din aceste informații sunt destinate explicit folosirii in decizia de rutare: comunitațiile și multi-exit discriminators (MED).

Selectia rutelor

Standardul specifica mai mulți factori de selecție a rutelor decat pentru orice alt protocol de rutare. Primul factor este ca next-hopul este accesibil (exista in tabela de rutare).

Apoi, pentru fiecare vecin, procesul BGP aplica diferite criterii (standardizate sau specifice implementarii) pentru a decide care rute vor ajunge in Adj-RIB-In. Doar o ruta catre fiecare destinație va ajunge in tabela, indiferent de cate sunt trimise de vecin. De asemenea, procesul va șterge din AdjRIB-In, toate rutele retrase de vecin.

Cand tabela Adj-RIB-In se schimba, procesul analizeaza noile rute pentru a vedea daca sunt mai bune decat cele aflate deja in Loc-RIB și le inlocuie te daca este cazul. Daca o ruta este retrasa de vecin și nu exista o alta ruta catre destinație, ea este ștearsa și din Loc-RIB și din tabela de rutare (cu excepția cazului in care un alt protocol de rutare are și el acesta ruta). [20]

Atributele BGP

Rutele invatate prin BGP au asociate proprietati care sunt folosite pentru a determina ruta optima catre o destinatie cand exista mai multe drumuri la acea destinatie. Aceste proprietati sunt atributele BGP si intelegerea modului in care ele influenteaza alegerea rutelor este necesara pentru proiectarea de retele robuste.

Atributele BGP sunt urmatoarele: [1]

origin

next hop

AS_path

local preference

weight

community

multi-exit discriminator

Atributul Origin

Indică cum BGP a învățat despre o anumită rută. Atributul origin poate avea valorile: IGP – ruta este interioară AS, EGP – ruta este învățată prin Exterior Border Gateway Protocol (EBGP), Incomplete – originea acestei rute este necunoscută sau a fost învățată prin alte mijloace.

Atributul Next-hop

Acest atribut indica adresa IP a urmatorului router, care este utilizat pentru a ajunge la destinație. Rutele BGP sunt de la sistem autonom la sistem autonom, nu de la router la router. Atributul Next-hop defineste adresa IP a routerului de la granița urmatorului sistem autonom, care trebuie folosita ca urmatorul hop catre destinație.

Pentru eBGP, urmatorul hop este adresa IP a vecinului de care a primit update-ul. In figura ce urmează, routerul A avertizeaza re!eaua 172.16.0.0 routerului B, cu next-hop 10.10.10.3, iar routerul B avertizeaza 172.20.0.0 routerului A, cu next-hop 10.10.10.1.

Pentru iBGP, se pastreaza nexthop-ul transmis de eBGP.

Figura 14: Atributul Next-hop

Atributul AS-path

De fiecare data cand un update pentru o ruta trece printr-un sistem autonom, numarul sistemului autonom este adaugat la respectivul update cand este transmis urmatorului vecin eBGP.

Atributul AS-path este o lista de numere ale sistemelor autonome care trebuiesc traversate pentru a ajunge la destinatie, numarul sistemului autonom care origineaza ruta aflandu-se la sfarsitul listei.

Figura 15: Atributul AS-path

In figura de mai sus, routerul A din AS-ul 64520 avertizeaza rețeaua 192.168.1.0. Cand ruta traverseaza AS-ul 65500, routerul C adauga numarul sistemului autonom propriu la ea. Cand ruta atinge routerul B, are doua sisteme autonome atașate. Din perspectiva routerului B, calea pentru a atinge rețeaua 192.168.1.0 este 65500, 64520.

Un proces similar se aplica pentru caile catre rețelele 192.168.2.0 și 192.168.3.0. Calea de la routerul A catre 192.168.2.0 este 65500, 65000, ceea ce inseamna ca traverseaza AS-ul 65500 și apoi AS-ul 65000. Routerul C trebuie sa traverseze calea 65000 pentru a atinge 192.168.2.0 și calea 64520 pentru a atinge 192.168.1.0.

Atributul Local-Preference

Acest atribut ofera o indicație catre routerele din sistemul autonom despre care cale este selectată pentru a ieși din sistemul autonom, atunci cand exista mai multe variante. Este aleasă calea cu atributul Local Preference mai mare.

Atributul Local Preference se configureaza pe router și este cunoscut doar intre routerele din același sistem autonom. Valoarea default a acestui atribut pe routerele Cisco este 100. [18]

Figura 16: Atributul Local-preference

In figura de mai sus daca se doreste comunicatia cu AS-ul 65350 ar fi 2 cai. Insa pentru ca este setat atrubitul local-preference pe routerul A cu valoarea 200, iar pe routerul B acest atribut are valoarea 150 se va alege ca ruta de iesire din AS-ul 64520 routerul A deoarece este selectata calea cu local-preference mai mare.

Atributul Weight

Acest atribut este proprietar Cisco și folosit pentru selecția cailor. Este configurat local pe router și nu este propagat catre niciun alt router. Iși are utilitatea atunci cand este utilizat un router cu ieșiri multiple catre destinații in Internet spre exemplu. Atributul Weight poate avea valori intre 0 si 65535. Default, caile pe care le origineaza un router au Weight-ul 32768, iar alte cai au weight-ul 0. Sunt preferate rutele cu Weight-ul cel mai mare, cand exista multiple rute catre aceea și destinație. [21]

Figura 17: Atributul Weight

In figura 15 , routerele B si C invața despre rețeaua 172.20.0.0 de la AS-ul 65250 și propaga update-ul catre routerul A. Routerul A va avea doua cai pentru a atinge rețeaua 172.20.0.0 și va trebui sa decida care dintre cai o va alege.

In acest exemplu, routerul A seteaza Weight-ul la 200 pentru update-urile care vin de la routerul B, respectiv la 150 pentru update-urile care vin de la routerul C. Pentru ca Weight-ul pentru routerul B este mai mare decat cel pentru routerul C, routerul A va utiliza routerul B ca next-hop pentru a atinge rețeaua 172.20.0.0.

Atributul Community

Acest atribut asigura o metoda de grupare a destinatiilor, numite comunitati (communities), spre care deciziile de routare pot fi aplicate. Sunt folosite harti de routare pentru a defini atributul community. [22]

Valorile predefinite sunt:

no-export – sa nu publici aceasta ruta catre noduri EBGP

no-advertise – sa nu publici acesta ruta catre niciun nod

internet – publica ruta catre toata comunitatea Internet, adica la toate routerele din retea.

Atributul multi-exit discriminator (MED)

Atributul multi-exit discriminator (MED) sau atributul metrica este folosit ca o sugestie pentru un AS extern privind ruta preferata in AS-ul care publica metrica. Este folosit termenul "sugestie" pentru ca AS-ul extern care primeste MED poate folosi alte atribute BGP pentru selectia rutelor. Atributul MED este o modalitate dinamica de a influența alt sistem autonom despre ce cale sa aleaga pentru a atinge o destinație cand exista mai multe variante. Este preferat MED-ul cel mai mic. [22]

Atributul MED este schimbat intre sisteme autonome, comparativ cu atributul Local Preference care nu este propagat in afara sistemului autonom. MED-ul este trimis catre vecinii eBGP.

Criterii de selecție

BGP ar putea primi mai multe mesaje update de la mai multe surse despre aceiași rută. BGP alege o singură rută ca fiind cea mai bună. După alegere, BGP introduce ruta în tabela de routare IP și propagă ruta către vecinii săi.

BGP folosește umătoarele criterii, în ordinea prezentată mai jos, pentru a alege ruta către o destinație: [1]

Dacă nu există decât o singură rută către o anumită destinație, va fi folosită această rută

Se preferă ruta cu cea mai mare valoare a atributului weight.

Dacă valorile atributului weight sunt egale, se preferată ruta cu cea mai mare valoare a atributului local preference.

Dacă local references sunt egale, se preferă ruta care a fost inițiată de BGP de pe acest router.

Dacă nicio rută nu a fost inițiată de pe acest router, se preferă ruta care are cea mai scurtă listă AS_path.

Dacă toate rutele au AS_path egale, se preferă ruta cu cea mai mică valoare origin (unde IGP este mai mic decât EGP, și EGP este mai mic decât Incomplete).

Dacă toate codurile origin sunt egale, se preferă ruta cu valoarea MED cea mai mică.

Dacă rutele au același MED, se preferă rutele externe înaintea rutelor interne.

Dacă rutele sunt tot egale, se preferă ruta care trece prin cel mai apropiat vecin IGP.

Ca ultima opțiune, se preferă ruta cu cea mai mică adresă IP.

Optimizarea traficului

Rutarea poate fi optimizata intr-o rețea prin controlul update-urilor de rutare, cosmetizarea cailor de acces, filtrarea traficului și a diverselor elemente de interes. În aceasta lucrare ne vom focaliza pe listele de control a accesului (ACL-access control list), route-map-uri și prioritizarea traficului dupa tipul și importanța lui.

Listele de acces (ACL) sunt de 2 tipuri:

Standard ACLs au numere între 1-99, și nu permit specificarea decât a adresei sursa a pachetului IP. De aceea, ele se plaseaza în rețea cât mai aproape de destinația afectata de ACL, în ideea ca pachetele pot ajunge la acea destinație pe mai multe căi.

Extended ACLs au numere între 100-199 sau 2000-2699. Ele permit specificarea adresei sursa, adresei destinație, protocolului si portului ceea ce le face mult mai versatile. Asadar ele se pot plasa cît mai aproape de sursa pachetelor afectate de ACL, pentru a reduce traficul inutil: din moment ce e cunoscuta destinația, nu are sens sa lasam pachetele sa circule prin toate nodurile intermediare, ci sa le eliminam chiar de la începutul drumului lor.

Configurarea (parțiala) a unui ACL extins se face astfel:

Router(config)# access-list numar deny|permit [remark comentariu] protocol sursa wildcard destinatia wildcard [port] [established] [log]

În plus fața de varianta standard, aici se specifica ambele adrese (sursa si destinație), protocolul (poate fi ip, icmp, tcp, udp si altele; ip le include pe toate), portul însoțit de un modificator: eq pentru egal, neq pentru non-egal, gt pentru “greater than”, lt pentru “less than” sau un domeniu de porturi specificat cu range x y; op_iunea established selecteaza numai acele pachete dintr-o conexiune TCP deja stabilita (nu si pachetele de stabilire a conexiunii care au flagul SYN), deci configurînd o regula cu allow numai pentru pachetele established putem sa permitem traficul catre un host, fara a permite ca altcineva sa încerce sa se conecteze pe acel host.

Ca si în cazul ACL standard, un ACL extins trebuie plasat pe o interfața a ruterului, folosind comanda:

Router(config)# ip access-group numar_ACL in|out.

Datorita existenței a doua perechi adresa/ wildcard mask, fața de o pereche la standard, la ACL extinse regula implicita care exista la sfârsit este deny ip any any (în loc de deny any), iar pentru ca comportamentul impilicit sa fie de a permite tot traficul nespecificat, regula care trebuie scrisă ultima este permit ip any any.

Trebuie specificat că listele de acces sunt folosite in configurarea protocolului BGP cu rolul de a pune o etichete pe traficul ce provine dintr-un AS. Dupa ce s-a etichetat traficul corespunzator sistemului autonom se vor seta diverse atribute care vor ajuta la respectarea politicilor de rutare stabilite inca de la inceput.

Atunci când exista mai multe rute catre o destinație, procesul de selecție este algoritmic si consta în verificarea, pe rând, a mai multor condiții (vezi subcapitolul anterior Criterii de selecție). Daca toate condițiile sunt la egalitate, va fi preferata ruta prin ruterul avînd ID mai mic. ID-ul unui ruter este dat de adresa IP de pe care vine un update BGP. [23]

Route-map-urile sunt similare ACL-urilor dar sunt mult mai puternice. Deasemenea sunt mult mai flexibile i pot fi fi folositoare in situații in care ACL-urile nu sunt de ajuns.

Route-map-urile pot fi utilizate intr-o varietate de scopuri. De cele mai multe ori, route-map-urile sunt foloste pentru:

Filtrarea rutelor la redistribuție: De cele mai multe ori redistribuția necesita filtrarea rutelor. Ele sunt utilizate și dau rezultate mult mai bune ca listele de distribuție (distribute-lists).

Rutarea prin politici (Policy-based routing PBR): Route-map-urile pot fi folosite sa faca potrivirea adreselor sursa și destinație, tipuri de protocoale și aplicatii end-user.

BGP: În protocolul BGP route-map-urile sunt principalele instrumente pentru implementarea politicilor de rutare. Astfel se controlează care rute sunt acceptate la intrarea sau ieșirea unui system autonomy.

Un exemplu de folosire a route-map-urilor este folosirea acestuia alături de atributul Weight al BGP-ului. Atributul weight este local pentru un ruter și nu este propagat în update-urile BGP. Pentru a schimba weight-ul unei rute catre o destinație, învațate de la alt ruter, se pot folosi mai multe metode. Una consta în folosirea route-maps; o route-map permite stabilirea unuia sau mai multor atribute cu set atunci cînd se indeplineste condiția dupa cuvintul cheie match.

Se defineste pe R0 un route-map numit abc care sa aloce un weight de 33000 (mai mare

decît 32768 care este implicit) tuturor rutelor care au atributul AS_PATH corespunzator sistemului autonom unde dorim sa facem filtrarea (filosim pentru a exemplica mai clar AS 100). Pentru a specifica exact numarul AS-ului si nu orice numar se folosesc caracterele speciale ^ (marcheaza începutul) și $ (marcheaza sfîrsitul). Asadar ^100$ înseamna un numar care începe cu numar-AS si nu mai are altceva la sfârsit. [19]

R0(config)# ip as-path access-list 1 permit ^100$

Apoi se defineste un route-map care are ca efect atribuirea noului weight (folosind cuvîntul-cheie set) atunci cînd se se îndeplineste condiția din ACL-ul declarant anterior (folosind cuvîntul-cheie match); un route-map, ca si un ACL, poate avea mai multe reguli, dar spre deosebire de acesta din urma, regulile sînt numerotate pentru a putea fi modificate independent si inserate în poziția dorita, nu doar la sfîrsit (în acest caz exista o singura regula cu numarul 10):

R0(config)# route-map abc permit 10

R0(config-route-map)# match as-path 1

R0(config-route-map)# set weight 33000

Și se introduce aceasta regula în protocolul de rutare, care in acest exemplu este bgp:

R0(config)# router bgp 200

R0(config-router)# neighbor 172.16.1.2 route-map abc in

Se observa ca sensul este “in” deoarece se aplica pentru rutele învațate de ruter, deci cele care “intra”.

Dupa ce se configureaza BGP astfel, se sterge tabela cu clear ip bgp * și, dupa convergență, se examineaza din nou cu sh ip bgp.

4

Aplicații de utilizare a protocoalelor de rutare – topologia rețelei

În capitolele următoare ne vom focaliza pe un exemplu de rețea, pe baza căreia vom face analize și discuții asupra tehnologiilor utilizate. Exemplul ce urmează are la bază cazuri reale, iar politicile folosite au aplicabilitate in rețelele metropolitane existente.

Prezentarea topologiei rețelei

Se consideră o companie care deține o retea internă ce este conectată la doi furnizori sau provideri de internet (IPS – Internet Service Provider) și se urmarește cum funcționează aceasta rețea, care sunt politicile de rutare aplicate și cum sunt configurate echipamentele pentru limitarea accesului la diverse servicii a departamentelor. Toate valorile AS-urilor, ale adreselor IP și denumirile au fost alese aleator, în scop exemplificativ și experimental.

Figura 18: Topologia rețelei studiate

După cum se poate observă in figura 18, rețeaua internă are doi furnizori de Internet: Provider1 și Provider2. Cei doi furnizori de Internet sunt substituiți de câte un router prin care sunt preluate funcțiile unui provider. Aceștia sunt conectați la un router pe care il vom considera experimental, rețeaua globala de Internet.

De asemenea, cei doi furnizori de Internet sunt interconectați de o rețea metropolitană, numita InterProviders in exemplul nostru, dintr-un motiv ce v-a fi exemplificat ulterior.

Fiecare din cele 5 rețele are AS-ul propriu, rutarea inter-AS-uri realizându-se bineințeles cu ajutorul BGP-ului.

Se analizează fiecare parte a topologiei prezentate anterior pentru a se evidenția particularițile fiecareia. Cele cele cinci rețele sunt reprezentate de urmatoarele:

Rețeaua internă

Provider1

Provider2

InterProviders

Internet

Figura 19: Topologia generală a rețelei

Rețeaua internă reprezintă modul in care o societate virutală iși gestionează și configurează echipamentele pentru o bună funcționare internă și accesibilitate atât la datele proprii, cât și la cele oferite de rețeaua globală de Internet, rețea special destinată funcționalitații eficiente a societații. În rețeaua curentă, simulare s-a făcut utilizându-se legaturile Ethernet in vederea comunicarii între routere. Această rețeaua internă ipotetică este exemplificată grafic in figura de mai jos (figura 20):

Figura 20: Rețeaua internă (AS 8754)

Rețeaua internă are opt routere, dintre acestea trei reprezentând comunicările principale cu furnizorii de Internet și mai departe cu rețeaua gloabală de Internet. Restul de cinci routere exemplifică modul intern de administrare a rețelei și sugerează modalitatea de comunicare a diferitelor protocoale de rutare internă.

Cele trei routere principale sunt:

Primay

Secundary

Distribution

Figura 21: Routerele rețelei interne

Routerul Primary:

responsabil de comunicația cu exteriorul și de tranzitul traficului in rețeaua proprie;

are direct conectat un server de WEB, care poate fi accesat din exterior.

are doua conexiuni de Internet, către Provider1 și Provider2. În cazul în care Provider1 pică, comunicarea cu Internetul se va face pe linia auxiliara prin Provider2;

are o linie dublă, redundantă cu routerul Secundary; în cazul în care o interfața fizică are probleme, traficul să nu fie afectat;

direct conectat la routerul de distribuție, care face legatura cu LAN-urile din rețea.

Routerul Secundary:

reprezintă al doilea punct de intrare pentru Provider1; în cazul în care legatura principală între Provider1 și routerul Primary pică, să existe alternative pentru comunicații tot prin Provider1;

preia sarcinile routerului Primary, în cazul în care acesta pică;

are atașate doua servere: unul de FTP și unul pentru baze de date; aceste servere sunt folosite intern și nu pot fi accesate din exterior;

are implementată o politica de acces pentru cele două servere, astfel încat serverul FTP să nu poată fi accesat decat din Engineering LAN, iar serverul de baze de date să nu poată fi accesat decât din Management LAN.

Routerul Distribution:

este routerul de distribuție, de care sunt atașate rețelele locale (în practica se pot folosi switchuri și vlan-uri pentru separarea logica in rețele virtuale, dar din considerente experimentale am ales această formă);

are conectate trei LAN-uri: Voice LAN (rețeaua de telefonie și voce), Engineering LAN (rețeaua departamentului tehnic) și Management LAN (rețeaua departamentului de management).

este, de asemenea, conectat cu trei dintre cele cinci routere comunicării interne prin prisma protocoalelor de rutare.

În aceasta rețea (Rețeaua internă), sunt implementate urmatoarele protocoale de rutare:

OSPF folosit pentru comunicațiile IPv4 în interiorul sistemului autonom; rețelele care comunică prin protocolul intern de rutare OSPF sunt divizate in trei arii: Area 0, Area 1 și Area 10;

RIP utilizat pentru traficul intern; plus pe ce routere e pus

EIGRP destinat rutării pachetelor prin interiorul sistemului autonom AS 8754;

BGP necesar pentru stabilirea legăturii dintre rețeaua internă proprie (AS 8754) și celelalte sisteme autonome; comunicarea dintre routerele Primary, respectiv Secunday și Provider1, Provider2 se face prin eBGP;

Figura 22: Protocoalele de rutare folosite pe routerele rețelei interne

Politici de rutare:

Prefixele invațate de la AS-ul 6800 (Provider1) nu se distribuie în AS-ul 5700 (Provider2) și invers, deci AS-ul 8754 nu este AS de tranzit între cei doi furnizori de internet.

Se primesc de la cei doi provideri tabelele globale de rutare și rutele default.

Pentru traficul de date se prefera ieșirea din AS-ul 8754 prin legătura dintre routerul Primary și Provider1. Dacă această legatură pică, se trece automat pe legătura dintre routerul Secundary și Provider1, in acest fel preferându-se Provider1. Acest lucru se realizează prin configurarea atributului Local Preference pentru prefixele care intră în AS-ul 8754 de la cele două AS-uri.

Daca Provider1 pică (nu mai poate livra servicii pe niciuna din liniile de comunicație), se trece pe legatura de siguranță dintre routerul Primary și Provider2.

Provider1 intră în AS-ul 8754 prin routerul Primary. Dacă această legatură nu este disponibilă, traficul va intra prin routerul Secundary. În acest fel se evita rutarea asimetrică între AS-ul 8754 și AS-ul 6800. Acest lucru se realizează prin configurarea atributului BGP MED pentru prefixele pe care le trimit routerele Primary, respectiv Secundary în AS-ul 6800.

În interiorul rețelei, se prefera ieșirea în Internet prin routerul Primary, acest lucru realizându-se prin configurarea atributului BGP Local Preference cu valori diferite pentru prefixele primite pe link-uri diferite.

Serverele atașate routerului Secundary sunt accesate doar din rețelele departamentelor autorizate, dupa politica de acces prezentată anterior.

Unele sesiuni BGP vor fi stabilite între routere cu ajutorul interfețelor de loopback și nu a celor direct conectate, deoarece in cazul în care interfețele direct conectate pică, să existe alternative pentru pastrarea adiacențelor.

Spre deosebire de rețeaua internă unde s-au folosit legături de tip Ethernet între routere, comunicarea între sistemele autonome în cadrul protopitului ales de această lucrare se realizează utilizând legaturi de tip Serial.

Am ales pentru designul IPv4 prefixe /30 pentru liniile de comunicație point-to-point și /24 pentru rețele de tip LAN. Figura de mai jos prezintă adresele IP alocate fiecarei legături între routere și interfețelor de loopback definite.

Figura 23: Structura completă a rețelei interne

Provider1 este unul din cei doi furnizori de Internet ai societații virtuale prezente mai sus. În mod exemplificativ, vom folosi un singur router care va avea responsabilitatea de a livra servicii furnizate de un provider de internet. Deseori furnizorii de internet sunt numiți "ISP", inițialele denumirii din limba engleză Internet Service Provider. Accesul fizic la Internet poate fi prin linie de telefon comutată (dial-up), access prin linie închiriată, linie de telefon ISDN, linie de telefon ADSL, cablu (de TV), radio, sistemul de telefonie mobilă GSM, sistemul de telefonie mobilă UMTS, satelit ș.a. Legăturile între diverșii ISP sau între punctele de prezență ale unui ISP sunt făcute de obicei printr-o rețea de tip „backbone“, capabilă să transmită un volum imens de informații, folosind deseori fibră optică.

Provider-ul 1 este conectat direct la o rețea (Local LAN) , a cărei adresă va trebui propagată în Internet, în rețeaua metropolitană InterProviders (ce urmează a fi prezentată in cele ce urmează) prin care comunică cu celalalt furnizor de Internet și catre rețeaua internă.

Figura 24: Provider1 (AS 6800)

Politici de rutare:

Primește din Internet tabela globală de rutare și ruta default

Primește de la Peernig prefixele metropolitane (rețeaua metropolitană este formată din AS-urile 8754, 6800, 9500 și 5700), acestea incluzând și prefixele pe care le ofera Provider2 pentru rețeaua metropolitană InterProviders.

Primește de la Rețeaua Internă prefixele din AS-ul 8754

Nu avertizează în Internet prefixele primite de la InterProviders și nu avertizează rețeaua metropolitan InterProviders de prefixele primite din Internet (nu este AS de tranzit între InterProviders și Internet)

Avertizeaza catre Rețeaua Internă tabela globala de rutare și ruta default. Acest lucru este valabil pentru ambele conexiuni către AS-ul 8754. Datorită politicii proactive pe care o are AS-ul 8754, nu este necesară modificarea atributelor BGP pentru rutare simetrică/asimetrică între cele două AS-uri.

Provider2 este celălalt furnizor de Internet al rețelei interne. El are o structura similară cu Provider1. Ca și în cazul precedent, este utilizat un singur router care va avea responsabilitatea de a livra servicii societatii în cazul in care rețeau interna a pierdut legătura cu Provider1.

S-a considerat o rețea direct conectată (Local LAN), a cărei adresă va trebui propagată în Internet, în peeringul metropolitan InterProviders și catre Rețeaua internă.

Figura 25: Provider2 (AS 5700)

Politici de rutare:

Primește din Internet tabela globală de rutare și ruta default;

Primește de la Peernig prefixele metropolitane, acestea incluzînd și prefixele pe care le ofera Provider1 pentru peeringul metropolitan InterProviders;

Primește de la Rețeaua internă prefixele din AS-ul 8754;

Nu avertizează în Internet prefixele primite de la InterProviders și nu avertizează această rețea dintre furnizorii de Internet de prefixele primite din Internet (nu este AS de tranzit între InterProvider și Internet);

Avertizează catre Rețeau internă tabela globală de rutare și ruta default.

InterProviders este zona care ii unește pe cei doi provideri de Internet. Are un rol deosebit de important în topologia prezentată. Având conexiuni de viteză mare și fiind un AS de tranzit între Provider1 și Provider2, traficul făcut între AS-urile 5700 (Provider2) și 6800 (Provider1) nu va fi rutat prin Internet la viteze de Internet, ci prin InterProviders la viteze metropolitane, fapt care va îmbunatăți considerabil vitezele pentru comunicațiile între furnizori.

Avem o rețea direct conectată (Local LAN), a cărei adresă va trebui propagată către cele două AS-uri (5700 și 6800), dar datorită politicii metropolitane de peering, ea nu va ajunge in Internet. Scopul InterProviders este de a fluidiza traficul metropolitan, nu de a accesa Internetul.

Figura 26: InterProviders (AS 9500)

Este o rețea extinsă, o rețea metropolitană, mai precis o rețea care acoperă o suprafată mare. În standardul IEEE 802-2001, rețelele metropolitane (MAN) sunt definite ca rețele optimizate pentru o arie geografică mai mare decât rețelele locale, începând de la cartiere rezidențiale, zone economice și mergând până la orașe întregi. De asemenea, rețelele metropolitane implică în general un canal de comunicație cu o frecvență a datelor medie spre înaltă. Rețeaua MAN este de multe ori proprietatea unui singur operator. Există și rețele metropolitane care funcționează ca regii de stat. În comparație cu o rețea locală (LAN), o arhitectura de dimensiuni metropolitane foloseste o altă tehnologie pentru menținerea conectivitații la Internet (ex: ATM, FDDI și SMDS). Legăturile metropolitante între rețelele locale sunt fără fir, funcționând pe baza microundelor, undelor radio sau a razelor infraroșii.

Politici de rutare:

Anunță prefixele din AS-ul local către vecinii eBGP;

Tranzitează prefixele de la AS-ul 5700 la AS-ul 6800 și invers.

Face parte din AS-ul 9500 care nu poate comunica cu Internetul, fiind un AS de tranzit între AS-urile înrolate în procesul de peering.

Internet

Figura 27: Internet (AS 4550)

Vom considera rețeaua globală Internet ca find AS-ul 4550. Prefixele din Internet vor fi de fapt rețelele direct conectate de routerul din AS-ul 4550. În mod exemplificativ am considerat o rețea direct conectata, a carei adresa va fi avertizata tuturor vecinilor eBGP. Această rețea va fi o rețea fizică și va fi prezentată mai pe larg în capitolul ce urmează, rolul ei in lucrarea de fața este de studia interconectarea unei topologii create in simulatorul GNS3 cu echipamente reale.

Va avertiza tabela globală de rutare către vecinii săi, totodată originând ruta defaut pentru fiecare în parte. Am ales o politica de preferința pentru accesul în rețaua metropolitană prin AS-ul 6800 (AS-ul furnizorului Provider1).

5

Aplicații folosind simulatorul GNS3

Introducere în GNS3

GNS3 (Graphical Network Simulator) este un simulator de rețea gratuit, care permite emularea rețelelor complexe. Mediile aplicative de simulare precum VMWare, VirtualBox sau Virtual PC, permit rularea Microsoft Windows XP sau altor sisteme de operare de tip Unix/Linux într-un mediu simulat. În mod similar, GNS3 permite simularea funcționării unei rețele bazate pe emularea CISCO IOS (Internetwork Operating Systems). GNS3 este o interfață grafică care integrează două suite de simulatoare: Dynagen și Dynamips. Dynagen este un produs software care permite generarea configurațiilor de rețea pentru Dynamips, iar Dynamips este programul de bază care permite emularea CISCO IOS. Dynagen operează la nivel superior Dynamips, iar GNS3 integrează cele două componente oferind o interfață grafică pentru acestea.

GNS3 poate fi instalat și rulează atât pe platforme hardware ce utilizează sisteme de operare Microsoft Windows cât și siteme de operare bazate pe kernel Unix/Linux. Ca și particularitate a acestui mediu de simulare trebuie precizat faptul că, deși se bazează pe funcționalitatea CISCO IOS, produsul software nu înglobează nici un sistem de operare CISCO. GNS3 oferă doar suportul și interfața pentru simularea funcționalității topologiilor de rețea cu echipamente CISCO.

GNS3 este un simulator gratuit (www.gns3.net), folosit pentru a simula funcționarea și configurarea routerelor CISCO. Ideea de bază a programului este de a încarcă IOS-urile corespunzatoare unui numar limitat de serii de routere CISCO (1700, 2600, 3600, 3700 și 7200) în memoria RAM a calculatorului, transformându-l pe acesta intr-o reîea de routere veritabilă.

În cele ce urmează vor fi prezentate interfața GNS3 (figura 28) și principalele instrumente de configurare și utilizare a simulatorului.

Figura 28: Simulatorul GNS3

În partea superioară a interfeței simulatorului se regăsesc bara cu meniuri și bara cu instrumente rapide destinate lucrului cu GNS3. Ecranul principal al intefeței aplicației este separată în patru zone funcționale cu instrumente pentru dezvoltarea și simularea topologiilor de rețea. În zona stângă a ecranului se regăsește lista cu echipamentele disponibile pentru construirea topologiei de rețea. Panoul din partea dreaptă a ecranului oferă un sumar al topologiei construite cu informații despre echipamentele care au fost configurate pentru simulare. Zona centrală a ecranului este este împărțită în două panouri: cel din partea superioară reprezintă zona de lucru, unde sunt aduse dispozitivele pentru construirea topologiei, iar cel din partea inferioară reprezintă consola pentru Dynamips.

Figura 29: Bara cu meniuri și instrumente rapide

Bara cu meniuri conține meniurile File, Edit, View, Control, Annotate și Help.

Bara cu instrumente rapide conține butoane pentru deschiderea unui nou proiect (New project), editarea unui proiect (Edit project), deschiderea unui fisier .net salvat anterior (Open project or topology file), salvarea unei topologii (Save project or topology file), salvarea unei topologii cu altă extensie (Save topology file as), salvarea proiectului (Save project as), afișarea numelor interfețelor în zona de lucru (Show interfaces name), afișarea numelui echipamentelor (Show hostnames), interconectarea echipamentelor(Add a link), salvarea stării curente a simulării (Take snapshot), salvarea sau aducerea configurațiilor de start (Export/Import all start-up configs), consola de configurare pentru sistemele de operare IOS (Telnet to all IOS), pornirea dispozitivelor (Start/Resume all devices), suspendarea dispozitivelor (Suspend all devices), oprirea dispozitivelor (Stop all devices), restartarea dispozitivelor (Reload all devices), inserarea unei note în topologie (Add a note), inserarea unei imagini (Insert a picture), desenarea unui dreptunghi sau a unei elipse.

În cadrul meniului Edit (figura 30) se regăsesc trei instrumente importante pentru rularea unei simulări : IOS images and hypervisors, Symbol Manager și Preferences. Opțiunea IOS images and hypervisors permite asignarea unor imagini CISCO IOS dispozitivelor de rețea din panoul cu echipamente astfel încât să se poată include în topogia de simulat. În cazul în care nu sunt asociate imagini IOS echipamentelor configurarea acestora și rularea simulării nu este posibilă. În cadrul acestui ecran se pot specifica platforma hardware, modelul și calea către imaginea IOS.

Figurile 30: Meniul Edit

Figura 31: Opțiunea IOS images and hypervisors

Opțiunea Symbol manager permite adăugarea în lista de dispozitive a noi module și comnponente ce pot participa la simularea topologiei, cu funcționalități diferite.

Ecranul opțiunii Preferences permite relizare de setări detaliate atât de ordin general pentru GNS3 cât și pentru Dynamips, interfațarea cu programare de analiză de rețea și pentru suportul de simulare.

Acestea sunt cele mai importante instrumente ale aplicației de simulare a unei topologii de rețea GNS3, cunoștințe care trebuie însușite de către studenți, sau orice altă persoană care dorește să înceapă lucrul cu acest simulator de rețea. Detalii suplimentare la setări și funcții particulare vor fi prezentate pe parcursul următoarelor lucrări în măsura în care acestea vor fi utilizate.

Configurare generală a routerelor în simulatorul GNS3

Routerele CISCO pot fi configurate în două feluri, folosind doua interfețe diferite cu utilizatorul: prin linia de comanda (CLI -Command Line Interface) sau in modul grafic (GUI -Graphical User Interface). Deși configurarea prin OUI este mai simplă, majoritatea celor care efectuaza aplicații practice pe routerele Cisco folosește CLI, deoarece aceasta modalitate ofera o gama mult mai mare de opțiuni de configurare și permite un mod de lucru mult mai meticulos. În cazul de fața vom folosi CLI, singura opțiune valabila prin intermediul simulatorului GNS-3.

Dupa pornirea routerului, acesta efectueaza un set de teste numit POST (Power-On Self Test) prin care verifică din punct de vedere electronic starea fiecarui bloc component. Dupa POST, se încarcă sistemul de operare (IOS-ul) în memoria RAM, apoi incepe un dialog cu utilizatorul. În simulator, aceste teste sunt inițiate odata cu lansarea comenzii de Console. Comanda Console va avea rezultatul corespunzator doar dacă routerul a fost pornit în prealabil prin intermediul comenzii Start.

Interfețele folosite în lucrarea de față vor fi Ethernet, Serial și Loopback. Implicit o interfață poate fi dezactivată, de aceea trebuie activată cu comanda no shutdown.

Interfețele Ethernet sunt similare cu cele de la PC. Interfața seriala însă este diferită este o interfața seriala sincronă, de viteză mai mare decît interfața seriala asincrona de la PC și cu alt tip de conector (60 sau 26 pini). Interfețele seriale sunt punct-la-punct, adică au numai 2 capete. Particularitatea interfețelor sincrone față de cele asincrone este ca trebuie generat un semnal de ceas (clock) la unul din capete. Capătul respectiv se numeste DCE (Data Communications Equipment), în timp ce capătul opus se numeste DTE (Data Terminal Equipment). La capătul DCE trebuie data în modul de configurare a interfețelor comanda adițională: clock rate NNNN. Interfețele de tip Loopback sînt asemănătoare cu interfața loopback 127.0.0.1 de pe PC dar sunt mai generale, în sensul că se pot configura cu orice adresă, orice netmask și pot fi în orice număr. Utilitatea unei interfețe Loopback este că, odată configurată, o astfel de interfață va fi tot timpul “up”, așadar indiferent de starea cablului și a ruterelor vecine, ruterul poate avea interfețe functionale pentru diverse teste, pentru ținerea în functiune a unui protocol de rutare, etc.

Interconectarea între echipamente fizice și o rețea simulată în GNS3

Un aspect interesant, pe care îl vom folosi în simularea noastră, este acela ca GNS3 poate comunica cu rețelele reale. Traficul dintr-un router, poate fi scos prin placa de rețea a calculatorului pe care se face simularea. Astfel se poate folosi topologia creată în simulator pentru a se evidenția funcționarea corespunzătoare și respectare tuturor politicilor de rutare ale unei rețele.

Interconectarea se face în următorul mod:

Figura 32: Interconectarea cu mediul real

În Cloud se poate alege placa de rețea pe care sa fie trimis traficul. Cloud-ul realizează de fapt interfațarea între rețeaua virtuală și cea reală. Traficul care intră prin link-ul de la routerul virtual, iși continuă fluxul prin placa de rețea către care direcționează Cloud-ul. În modelul prezentat interconectarea s-a realizat prin două locuri, pentru a se putea obseva și receptiona traficul transmis de pe un echipament real tot pe un echipament care există fizic.

Configurarea specifică a routerelor din topologia prezentată

În continuare va fi detaliată rețeaua anterior descrisă, alături de care vor fi prezentate protocoalele de rutare utilizate pe fiecare router și modul de configurare specific fiecărui echipament datorită cărora a fost obținut un model ipotetic, dar în același timp aplicabil în realitate, care respectă îndeaproape regulile generale de funcționare ale rețelei.

Dacă în capitolul anterior a fost prezentată pe larg rețeaua create în această lucrare, în cele ce urmează vor fi detaliate configurările aplicate pe fiecare router în parte. Rețeaua obținută în simulatorul GNS3 este descrisă de imaginea ce urmează:

Figura 33: Modelul rețelei obtinut în simulatorul GNS3

Modelul prezentat cuprinde în structura sa un numar de 12 routere, grupate în 5 sisteme autonome, 6 dintre ele alcătuind rețeaua internă. Acestea sunt:

Internet

Provider1

Provider2

InterProviders

Primary

Secundary

Distribution

OO

OR

OE

E

R

Interfețele de Loopback sunt interfețe virtuale create pe routere în scopuri experimentale. Avantajul acestor interfețe este că rămân up pe toata perioada funcționării routerului. Pentru aceasta nu au nevoie de comanda no shut. Am simulat rețelele din spate, atașate routerului cu ajutorul acestor interfețe.

Routerul R

Acest router este conectat doar cu routerul OR și a fost folosit pentru a se putea exemplifica felul în care protocolul intern de rutare RIP comunică cu celelalte protocoale interne și anume cu OSPF și EIGRP. Are configurate 2 interfețe:

interface Loopback1

ip address 11.11.11.11 255.255.255.255

!

interface Ethernet0/0

ip address 86.107.18.2 255.255.255.252

half-duplex

S-a implementat protocolul RIP versiunea 2 fără sumarizare. Va fi transmisă și interfață de Loopback către restul routerelor cu care va comunica. Se observă singurele rețele pe care le are in tabela de routare sunt cele primite de la routerul OR:

Codes: C – connected, S – static, R – RIP, M – mobile, B – BGP

D – EIGRP, EX – EIGRP external, O – OSPF, IA – OSPF inter area

N1 – OSPF NSSA external type 1, N2 – OSPF NSSA external type 2

E1 – OSPF external type 1, E2 – OSPF external type 2

i – IS-IS, su – IS-IS summary, L1 – IS-IS level-1, L2 – IS-IS level-2

ia – IS-IS inter area, * – candidate default, U – per-user static route

o – ODR, P – periodic downloaded static route

Gateway of last resort is not set

86.0.0.0/30 is subnetted, 2 subnets

C 86.107.18.0 is directly connected, Ethernet0/0

R 86.107.15.0 [120/1] via 86.107.18.1, 00:00:15, Ethernet0/0

11.0.0.0/32 is subnetted, 1 subnets

C 11.11.11.11 is directly connected, Loopback1

Nu sunt recunoscute celelalte rețele din interiorul Rețelei interne, care formează un sistem autonom deoarece nu poate cominica inca cu alte routere care au implementate alte protocoale interne de rutare, de exemplu OSPF.

Routerul OR

Este conectat cu routerul Distribution și routerul R. Pe el sunt implementate protocoalele de rutare RIP și OSPF. În ceea ce privește protocolul OSPF mai trebuie adăugat că am folosit instanța 1 pentru definire și că R face parte din aria 0.

router ospf 1

log-adjacency-changes

network 86.107.15.2 0.0.0.0 area 0

!

router rip

version 2

network 86.0.0.0

default-metric 10

no auto-summary

Routerul R, direct conectat cu OR, nu avea in tabela de rutare retelele pe care le are OR deoarece nu se distribuiesc rutele intre diferite protocoale de rutare. Pentru ca R sa cunoasca si celelalte routere pe care ruleaza protocolul OSPF a trebuit sa introducem comanda de redistribuire a rutelor pe routerul pe care functioneaza ambele protocoale de rutare:

in configurarea protocolului RIP e necesara redistribuirea rutelor invatate prin OSPF (comanda necesara este redistribute ospf 1)

in configurarea protocolului OSPF e necesara redistribuirea rutelor ce provin din RIP comanda necesara este redistribute rip subnets)

Ca urmare a configurarii se observa ca routerul R are in tabela sa de rutare si celelalte retele pe care nu functioneaza tot protocolul RIP.

Gateway of last resort is 86.107.18.1 to network 0.0.0.0

1.0.0.0/32 is subnetted, 1 subnets

R 1.1.1.1 [120/10] via 86.107.18.1, 00:00:19, Ethernet0/0

2.0.0.0/32 is subnetted, 1 subnets

R 2.2.2.2 [120/10] via 86.107.18.1, 00:00:19, Ethernet0/0

3.0.0.0/32 is subnetted, 1 subnets

R 3.3.3.3 [120/10] via 86.107.18.1, 00:00:19, Ethernet0/0

86.0.0.0/8 is variably subnetted, 15 subnets, 2 masks

R 86.107.17.0/30 [120/10] via 86.107.18.1, 00:00:19, Ethernet0/0

R 86.107.16.0/30 [120/10] via 86.107.18.1, 00:00:21, Ethernet0/0

R 86.107.19.0/30 [120/10] via 86.107.18.1, 00:00:21, Ethernet0/0

C 86.107.18.0/30 is directly connected, Ethernet0/0

R 86.107.15.0/30 [120/1] via 86.107.18.1, 00:00:21, Ethernet0/0

R 86.107.8.1/32 [120/10] via 86.107.18.1, 00:00:21, Ethernet0/0

R 86.107.9.1/32 [120/10] via 86.107.18.1, 00:00:23, Ethernet0/0

R 86.107.10.1/32 [120/10] via 86.107.18.1, 00:00:23, Ethernet0/0

R 86.107.5.0/30 [120/10] via 86.107.18.1, 00:00:23, Ethernet0/0

R 86.107.4.0/30 [120/10] via 86.107.18.1, 00:00:23, Ethernet0/0

R 86.107.6.1/32 [120/10] via 86.107.18.1, 00:00:23, Ethernet0/0

R 86.107.7.1/32 [120/10] via 86.107.18.1, 00:00:23, Ethernet0/0

R 86.107.1.1/32 [120/10] via 86.107.18.1, 00:00:23, Ethernet0/0

R 86.107.3.0/30 [120/10] via 86.107.18.1, 00:00:23, Ethernet0/0

R 86.107.2.0/30 [120/10] via 86.107.18.1, 00:00:23, Ethernet0/0

9.0.0.0/30 is subnetted, 1 subnets

R 9.9.9.8 [120/10] via 86.107.18.1, 00:00:23, Ethernet0/0

10.0.0.0/32 is subnetted, 1 subnets

R 10.10.10.10 [120/10] via 86.107.18.1, 00:00:23, Ethernet0/0

11.0.0.0/32 is subnetted, 1 subnets

C 11.11.11.11 is directly connected, Loopback1

R* 0.0.0.0/0 [120/10] via 86.107.18.1, 00:00:23, Ethernet0/0

In mod asemanator se va proceda si pe routerele E si OE, singura diferenta este ca pe ele ruleaza protocolul de rutere EIGRP si nu RIP. Pentru cunoasterea tuturor vecinilor din interiorul Rețelei interne a fost nevoie sa se distribuie routele invatate prin OSPF in protocolul EIGRP si rutele invatate prin EIGRP in OSPF. Astfel s-a ajuns ca toate routerele din AS 8754 sa afle de toate retelele din interiorul Retelei interne.

Tabela de rutare pe routerul E ca arata astfel:

Gateway of last resort is 86.107.19.1 to network 0.0.0.0

1.0.0.0/32 is subnetted, 1 subnets

D EX 1.1.1.1 [170/2588160] via 86.107.19.1, 00:05:43, Ethernet0/0

2.0.0.0/32 is subnetted, 1 subnets

D EX 2.2.2.2 [170/2588160] via 86.107.19.1, 00:05:43, Ethernet0/0

3.0.0.0/32 is subnetted, 1 subnets

D EX 3.3.3.3 [170/2588160] via 86.107.19.1, 00:05:43, Ethernet0/0

86.0.0.0/8 is variably subnetted, 15 subnets, 2 masks

D EX 86.107.17.0/30 [170/2588160] via 86.107.19.1, 00:05:43, Ethernet0/0

D EX 86.107.16.0/30 [170/2588160] via 86.107.19.1, 00:06:39, Ethernet0/0

C 86.107.19.0/30 is directly connected, Ethernet0/0

D EX 86.107.18.0/30 [170/2588160] via 86.107.19.1, 00:05:45, Ethernet0/0

D EX 86.107.15.0/30 [170/2588160] via 86.107.19.1, 00:05:45, Ethernet0/0

D EX 86.107.8.1/32 [170/2588160] via 86.107.19.1, 00:05:45, Ethernet0/0

D EX 86.107.9.1/32 [170/2588160] via 86.107.19.1, 00:05:47, Ethernet0/0

D EX 86.107.10.1/32 [170/2588160] via 86.107.19.1, 00:05:47, Ethernet0/0

D EX 86.107.5.0/30 [170/2588160] via 86.107.19.1, 00:05:47, Ethernet0/0

D EX 86.107.4.0/30 [170/2588160] via 86.107.19.1, 00:05:47, Ethernet0/0

D EX 86.107.6.1/32 [170/2588160] via 86.107.19.1, 00:05:47, Ethernet0/0

D EX 86.107.7.1/32 [170/2588160] via 86.107.19.1, 00:05:47, Ethernet0/0

D EX 86.107.1.1/32 [170/2588160] via 86.107.19.1, 00:05:47, Ethernet0/0

D EX 86.107.3.0/30 [170/2588160] via 86.107.19.1, 00:05:47, Ethernet0/0

D EX 86.107.2.0/30 [170/2588160] via 86.107.19.1, 00:05:47, Ethernet0/0

9.0.0.0/30 is subnetted, 1 subnets

D EX 9.9.9.8 [170/2588160] via 86.107.19.1, 00:05:47, Ethernet0/0

10.0.0.0/32 is subnetted, 1 subnets

C 10.10.10.10 is directly connected, Loopback1

11.0.0.0/32 is subnetted, 1 subnets

D EX 11.11.11.11 [170/2588160] via 86.107.19.1, 00:05:47, Ethernet0/0

D*EX 0.0.0.0/0 [170/2588160] via 86.107.19.1, 00:05:49, Ethernet0/0

Redistribuirea rutelor EIGRP in protocolul OSPF se face introducand comanda redistribute eigrp 1 subnets, iar pentru cunoasterea tuturor retelelor de care routerul pe care ruleaza protocolul EIGRP e necesara o comanda mai complexa si anume:

OE(config-router)#redistribute ospf 1 metric 1000 10 255 1 65535, fiecare dintre parametrii introdusi se pot intelege din help-ul IOS-ului.

<1-4294967295> Bandwidth metric in Kbits per second

<0-4294967295> EIGRP delay metric, in 10 microsecond units

<0-255> EIGRP reliability metric where 255 is 100% reliable

<1-255> EIGRP Effective bandwidth metric (Loading) where 255 is 100% loaded

<1-65535> EIGRP MTU of the path

Routerul OO

Pe acest echipament a fost configurat protocolul de rutare OSPF, interfata care face conexiunea cu routerul Distribution a fost declarata in aria 0, iar interfata de Loopback, care s-a inlocuit ulterior cu o interfata conectata la un calculator real, s-a declarat in aria 10. Dupa redistribuirea rutelor intre protocoalele de rutare interne tabela de rutate arata astfel:

Codes: C – connected, S – static, R – RIP, M – mobile, B – BGP

D – EIGRP, EX – EIGRP external, O – OSPF, IA – OSPF inter area

N1 – OSPF NSSA external type 1, N2 – OSPF NSSA external type 2

E1 – OSPF external type 1, E2 – OSPF external type 2

i – IS-IS, su – IS-IS summary, L1 – IS-IS level-1, L2 – IS-IS level-2

ia – IS-IS inter area, * – candidate default, U – per-user static route

o – ODR, P – periodic downloaded static route

Gateway of last resort is 86.107.17.1 to network 0.0.0.0

1.0.0.0/32 is subnetted, 1 subnets

O 1.1.1.1 [110/11] via 86.107.17.1, 00:05:10, Ethernet0/0

2.0.0.0/32 is subnetted, 1 subnets

O IA 2.2.2.2 [110/21] via 86.107.17.1, 00:05:10, Ethernet0/0

3.0.0.0/32 is subnetted, 1 subnets

O IA 3.3.3.3 [110/21] via 86.107.17.1, 00:05:10, Ethernet0/0

86.0.0.0/8 is variably subnetted, 15 subnets, 2 masks

C 86.107.17.0/30 is directly connected, Ethernet0/0

O 86.107.16.0/30 [110/20] via 86.107.17.1, 00:05:12, Ethernet0/0

O E2 86.107.19.0/30 [110/20] via 86.107.17.1, 00:05:12, Ethernet0/0

O E2 86.107.18.0/30 [110/20] via 86.107.17.1, 00:05:12, Ethernet0/0

O 86.107.15.0/30 [110/20] via 86.107.17.1, 00:05:12, Ethernet0/0

O 86.107.8.1/32 [110/11] via 86.107.17.1, 00:05:12, Ethernet0/0

O 86.107.9.1/32 [110/11] via 86.107.17.1, 00:05:13, Ethernet0/0

O 86.107.10.1/32 [110/11] via 86.107.17.1, 00:05:13, Ethernet0/0

O IA 86.107.5.0/30 [110/20] via 86.107.17.1, 00:05:13, Ethernet0/0

O IA 86.107.4.0/30 [110/20] via 86.107.17.1, 00:05:13, Ethernet0/0

O IA 86.107.6.1/32 [110/21] via 86.107.17.1, 00:05:13, Ethernet0/0

O IA 86.107.7.1/32 [110/21] via 86.107.17.1, 00:05:13, Ethernet0/0

O IA 86.107.1.1/32 [110/21] via 86.107.17.1, 00:05:13, Ethernet0/0

O IA 86.107.3.0/30 [110/30] via 86.107.17.1, 00:05:13, Ethernet0/0

O IA 86.107.2.0/30 [110/30] via 86.107.17.1, 00:05:13, Ethernet0/0

9.0.0.0/30 is subnetted, 1 subnets

C 9.9.9.8 is directly connected, Ethernet0/1

10.0.0.0/32 is subnetted, 1 subnets

O E2 10.10.10.10 [110/20] via 86.107.17.1, 00:05:13, Ethernet0/0

11.0.0.0/32 is subnetted, 1 subnets

O E2 11.11.11.11 [110/20] via 86.107.17.1, 00:05:13, Ethernet0/0

O*E2 0.0.0.0/0 [110/10] via 86.107.17.1, 00:05:13, Ethernet0/0

Routerul Distribution

Pe routerul Distribution functioneaza instanta 1 protocolului OSPF. Dupa stabilirea adiacentelor si configurarea routerelor vecine OR si OE sa distribuie retelele invatate prin protocolele RIP si EIGRP, Distribution a ajuns sa cunoasca intreaga retea a companiei. Pentru comunicare cu exteriorul s-au definit doua rute default, una dintre ele fiind conexiuna cu routerul Primary, iar cea de-a doua cu routerul Secundary, in cazul in care se defecteaza routerul principal. Pentru a se alege intai conexiunea cu routerul Primary s-a pus o metrica mai mica decat pentru cea de-a doua ruta default care este intrefata ce il conecteaza cu routerul Secundary.

ip route 0.0.0.0 0.0.0.0 86.107.4.2 10

ip route 0.0.0.0 0.0.0.0 86.107.5.2 20

Deoarece intreaga retea interna trebuie sa aibe acces la Internet prin routerul Primary sau Secundary (ca legatura de rezerva) s-au redistribuit aceste rute default cu ajutorul comenzii:

Distribution(config-router)#default-infornation originate always

Routerul Primary

Protocolul OSPF se configureaza in mod similar ca pe celelalte routere pe care mai ruleaza (OR, OO, OE, Distribution si Secundary), vom insista aici doar pe politicile de rutare BGP.

router bgp 8754

no synchronization

bgp log-neighbor-changes

aggregate-address 86.107.0.0 255.255.224.0 summary-only

redistribute connected

redistribute ospf 1 match internal external 1 external 2

neighbor 1.1.1.1 remote-as 8754

neighbor 1.1.1.1 update-source Loopback0

neighbor 2.2.2.2 remote-as 8754

neighbor 2.2.2.2 update-source Loopback0

neighbor 100.200.1.1 remote-as 5700

neighbor 100.200.1.1 route-map SET_LOCALPREF_Provider2 in

neighbor 100.200.1.1 route-map Link_to_Provider2 out

neighbor 100.200.2.1 remote-as 6800

neighbor 100.200.2.1 route-map SET_LOCALPREF_Provider1 in

neighbor 100.200.2.1 route-map Link_to_Provider1 out

no auto-summary

Dupa cum se poate observa, avem 3 adiacente BGP: una iBOP cu 2.2.2.2 si doua eBOP cu 100.200.1.1 respectiv 100.200.2.1 (adica Provider2 si Provider1) .

Dupa cum a fost prezentata politica de rutare BGP in capitolul anterior, ne dorim ca Provider1 sa fie preferat intotdeauna fața de Provider2. Pentru aceasta vom marca prefixele primite de la cele doua ISP-uri cu atribute local-preference corespunzatoare:

ip as-path access-list 30 permit ^6800_

ip as-path access-list 40 permit ^5700_

Listele de acces de tip ip as-path marcheaza traficul primit din AS-urile 6800 si 5700.

Acestor marcari le sunt setate atributele local-preference de 2500 si 500 pentru prefixele primite din AS-urile 6800 respectiv 5700 (Provider1 și Provider2), conform route-map-urilor de mai jos.

route-map SET_LOCALPREF_ISP1 permit 10

match as-path 30

set local-preference 2500

!

route-map SET_LOCALPREF_ISP2 permit 10

match as-path 40

set local-preference 500

Aceste route-map-uri sunt setate pe direcția in in configurația vecinilor din AS-urile respective:

neighbor 100.200.1.1 route-map SET_LOCALPREF_ISP2 in

neighbor 100.200.2.1 route-map SET_LOCALPREF_ISP1 in

De asemenea, nu dorim ca AS 8754 sa fie AS de tranzit. In acest sens vom filtra prefixele invațate de la AS-ul 6800 catre AS-ul 5700 și invers.

ip as-path access-list 10 deny ^5700_

ip as-path access-list 10 permit .*

ip as-path access-list 20 deny ^6800_

ip as-path access-list 20 permit .*

Listele de acces de mai sus au rolul de a permite toate prefixele, mai puțin cele primite de la AS-urile 5700 respectiv 6800.

route-map Link_to_IPS1 permit 10

match as-path 10

set metric 150

!

route-map Link_to_IPS2 permit 10

match as-path 20

set metric 250

Aceste route-map-uri configurate pe direcțiile de ieșire catre vecini, au rolul de a injecta prefixelor filtrate de listele de acces as-path, atributele MED pentru a controla modalitatea de intrare a traficului din AS-ul 6800 in AS-ul 8754 . In cazul AS-ului 6800, routerul HQ injecteaza prefixe cu MED-ul 150, și routerul Backup cu MED-ul 200. Astfel traficul venit din AS-ul 6800 va prefera intrarea prin HQ.

Totodata aplicarea acestor route-map-uri permite AS-ului 8754 sa nu fie AS de tranzit intre AS-urile vecine.

Se pot observa in tabela BGP de mai jos atributele pentru cateva prefixe:

Figura 34: Tabela de rutate a routerului Primary

Figura 35: Tabela de rutate a routerului Primary – continuare

Routerul Secundary

router bgp 8754

no synchronization

bgp log-neighbor-changes

aggregate-address 86.107.0.0 255.255.224.0 summary-only

redistribute connected

redistribute ospf 1 match internal external 1 external 2

neighbor 1.1.1.1 remote-as 8754

neighbor 1.1.1.1 update-source Loopback0

neighbor 1.1.1.1 distribute-list 1 out

neighbor 3.3.3.3 remote-as 8754

neighbor 3.3.3.3 update-source Loopback0

neighbor 3.3.3.3 distribute-list 1 out

neighbor 100.200.3.1 remote-as 6800

neighbor 100.200.3.1 distribute-list 1 out

neighbor 100.200.3.1 route-map SET_LOCALPREF_Provider1 in

neighbor 100.200.3.1 route-map Link_to_Provider1 out

no auto-summary

Pentru adiacența cu ISP1, avem o lista de distribuție ce filtreaza prefixele și nu avertizeaza adresele celor doua servere (FTP si DB):

access-list 1 deny 86.107.6.1

access-list 1 deny 86.107.7.1

access-list 1 permit any

Aceasta lista de acces permite orice mai putin adresele celor doua servere.

neighbor 100.200.3.1 distribute-list 1 out

Dupa cum se observa, este aplicata pe directia out catre ISP1.

neighbor 100.200.3.1 route-map Link_to_Provider1 out

!

route-map Link_to_Provider1 permit 10

match as-path 10

set metric 200

!

ip as-path access-list 10 deny ^5700_

ip as-path access-list 10 permit .*

De asemenea sunt filtrate prefixele catre Provider1, nefiind incluse cele primite din AS-ul 5700, iar cele trimise sunt injectate cu MED-ul 200.

Este filtrata comunicația in rețeaua locala pentru serverele FTP și DB a a cum a fost prezentata in capitolul anterior:

access-list 110 deny ip 86.107.9.0 0.0.0.255 host 86.107.7.1

access-list 110 deny ip 86.107.10.0 0.0.0.255 host 86.107.6.1

access-list 110 permit ip any any

Departamentul Engeneering (86.107.9.0/24) nu are acces la serverul DB (86.107.7.1) și departamentul Management (86.107.10.0/24) nu are acces la serverul FTP (86.107.6.1) (figura 35).

Figura 36: Restricții la serverele DB și FTP

Prefixele invațate de la ISP1 vor fi avertizate cu atributul localpref 2000:

route-map SET_LOCALPREF_IPS1 permit 10

match as-path 20

set local-preference 2000

!

ip as-path access-list 20 permit ^6800_

!

neighbor 100.200.3.1 route-map SET_LOCALPREF_Provider1 in

Routerul Provider1

Adiacențele cu Internetul și InterProviders se stabilesc cu ajutorul interfețelor de Loopback:

neighbor 6.6.6.6 remote-as 9500

neighbor 6.6.6.6 ebgp-multihop 2

neighbor 6.6.6.6 update-source Loopback0

neighbor 7.7.7.7 remote-as 4550

neighbor 7.7.7.7 ebgp-multihop 2

neighbor 7.7.7.7 update-source Loopback0

ebgp-multihop se folosește atunci cand adiacența nu se stabileste cu adrese IP din același subnet sau routerele nu sunt direct conectate.

Se stabilesc prioritațile pentru traficul catre vecini folosind atributul Weight:

neighbor 6.6.6.6 route-map Weight_to_InterProvider in

neighbor 6.6.6.6 route-map Restrict_to_InterProviders out

!

neighbor 7.7.7.7 route-map Weight_to_Internet in

neighbor 7.7.7.7 route-map Restrict_to_Internet out

!

route-map Weight_to_Internet permit 10

match as-path 10

set weight 200

!

route-map Restrict_to_Internet permit 10

match as-path 40

!

route-map Restrict_to_InterProviders permit 10

match as-path 30

!

route-map Weight_to_InterProviders permit 10

match as-path 20

set weight 2000

!

ip as-path access-list 10 permit ^4550_

ip as-path access-list 20 permit ^9500_

ip as-path access-list 30 deny ^4550_

ip as-path access-list 30 permit .*

ip as-path access-list 40 deny ^9500_

ip as-path access-list 40 permit .*

Routerul Internet

Un aspect foarte important care se aplica in rețeaua globala a Internetului este sumarizarea. Routerele care se află la marginea unui AS sumarizează rețelele din interiorul sistemului autonom din care fac parte și transmit vecinilor din AS-urile alaturate doar informatiile necesare pentru a se putea putea ajunge la o anumita rețea atunci cand aceasta este solicitata. În cazul de fața s-a facut sumarizarea pe routerele Primary și Secundary introducându-se pe fiecare comenzile:

Primary(config-router)# redistribute ospf 1 match internal external 1 external 2

Primary(config-router)#aggregate-address 86.107.0.0 255.255.224.0 summary-only

Secundary(config-router)# redistribute ospf 1 match internal external 1 external 2

Secundary(config-router)#aggregate-address 86.107.0.0 255.255.224.0 summary-only

Astfel se reduce foarte mult dimensiunea tabelei de rutare. Acest aspect poate fi observat in tabela de rutare a routerului Internet:

………………………………………………………

86.0.0.0/19 is subnetted, 1 subnets

B 86.107.0.0 [20/0] via 4.4.4.4, 00:01:40

……………………………………………………….

În concluzie, folosindu-se sumarizarea, va aparea o singura intrare in tabela de rutare a routerului Internet in cazul de fața, in loc de 15 intrari.

Interfața Ethernet0/0 a acestui router care reprezintă un sistem autonom este direct conectată cu un PC real care va fi folosit drept utilizator ce va accesa rețeaua internă a companiei ipotetice.

Routerelor ramase neprezentate au configurații simulare celor detaliate mai sus. În cadrul Anexelor se pot vizualiza fisierele de configurare ale tuturor echipamentelor folosite in aceasta lucrare.

6

Rezultate și discuții

În cele ce urmează am interconectat reteaua creată în simulatorul GNS3 cu doua PC fizice pentru a se putea observa si studia mai in detaliu daca politicile de rutare respecta cerintele impuse.

Calculatorul pe care a fost facuta simularea are doua placi de retea si astfel s-a putut conecta rețeaua din GNS3 cu alte doua echipamente fizice. Primul dintre ele a fost legat la routerul OO, iar cel de-al doilea fost legat la routerul Internet.

Figura 37: Interconectarea rețelei simulate în GNS3 cu doi utilizatori reali

In prima faza s-a urmarit calea pe care o urmeaza un pachet care pleaca de la Utilizator real 2 spre Utilizator real 1, a cărui adresa IP este 150.200.1.2.

UtilizatorReal2#traceroute 150.200.1.2

Type escape sequence to abort.

Tracing the route to 150.200.1.2

1 86.107.17.1 36 msec 36 msec 24 msec – legătura dintre OO și Distribution

2 86.107.4.2 56 msec 60 msec 64 msec – legătura dintre Distribution și Primary

3 100.200.2.1 92 msec 124 msec 92 msec – legătura dintre Primary și Provider1

4 20.150.1.1 88 msec 152 msec * – legătura dintre Provider1 și Internet

Traceroute este un program care permite vizualizarea modului în care informațiile circulă în mediul Internet, prin urmărirea unui pachet de date trimis de pe computerul personal către un destinatar oarecare.

Se observă că sunt respectate toate politicile de rutare configurate pe reteaua din GNS3.

Dacă se pierde conexiuna cu Provider1, conform regulilor impuse comunicarea Rețelei interne cu exteriorul ar trebui sa se faca prin cel de-al doilea furnizor de internet, Provider2. Se observa ca pachetele de la PC-ul fizic conectat la routerul OO catre PC-ul legat la Internet vor fi trimise catre Provider2.

UtilizatorReal2#traceroute 150.200.1.2

Type escape sequence to abort.

Tracing the route to 150.200.1.2

1 86.107.17.1 32 msec 44 msec 40 msec – legătura dintre OO și Distribution

2 86.107.4.2 60 msec 76 msec 40 msec – legătura dintre Distribution și Primary

3 100.200.1.1 80 msec 144 msec 56 msec – legătura dintre Primary și Provider2

4 20.150.2.1 104 msec 144 msec * – legătura dintre Provider2 și Internet

Pentru a se intelege mai bine functionarea protocolului de rutare BGP s-a folosit un analizor de pachete de rețea, Wireshark mai exact. Wireshark este un program de tip open source, util multor administratori de rețea. Wireshark este un analizor de pachete de rețea (network protocol analyzer) gratuit folosit pentru analiza traficului dintr-o rețea, identificarea și depanarea eventualelor probleme, dar și în scopuri educative. Utilitarul Wireshark este scris în limbajul C și are la bază aplicația de consolă tcpdump, iar până în anul 2006 a fost cunoscut sub numele de Ethereal.

Wireshark permite utilizatorului să vadă tot traficul dintr-o rețea Ethernet prin trecerea interfeței de rețea (sau plăcii de rețea) în modul promiscuu. În această configurație, interfața de rețea transmite procesorului tot traficul primit nu doar pe cel adresat stației pe care rulează aplicația. În multe domenii ale industriei și instituții educaționale Wireshark este standardul de facto pentru captura și analiza traficului de date.

Se observa ca dupa ce a picat legatura dintre routerului Primary și Provider1 s-a trimis un mesaj BGP de Update in care se spune ca legatura nu mai este valabilă. Captura mesajelor a fost facută pe legatura dintre routerul Primary și Provider2. În figura ce urmează se poate vizualiza mesajul pe care il primeste routerul Provider2 (100.200.1.1) de la Primary (100.200.1.2).

Figura 38: Mesaj BGP Update de la Primary către Provider2 capturat cu Wireshark

Routerul Provider2 va trimite ca raspuns tot un mesaj de Update in care routerul Primary este informat depre modificarile ca au intervenit in retea, mai precis ce ruta este valabila pentru a se putea comunica din nou cu Provider1. Acest lucru se realieaza prin atributul AS_PATH care specific ace AS-uri trebuie traversate pentru a se ajunge la destinatie, adica Provider1. De asemenea, se comunica si NEXT_HOP-ul catre AS 6800 din care face parte celalalt furnizor de servicii de internet.

Figura 39: Mesaj BGP Update primit de Primary de la Provider2 capturat cu Wireshark

Presupunem ca routerul Primary pierde conexiunea cu Provider2. El va comunica cu routerul Secundary, care este legatura de back-up (rezervă) in cazul in care Primary nu mai are acces la Internet. Toate sarcinile sale vor fi preluate de catre rezerva sa. S-a capturat comunicarea protocolului BGP dintre cele doua echipamente. Primary, reprezentat prin Loopback-ul sau 3.3.3.3, va trimite un mesaj de Update catre Loopback-ul 2.2.2.2 al routerului Secundary in care il informeaza ca Provider2 nu mai este disponibil.

Figura 40: BGP Update de la Primary către Secundary capturat cu Wireshark

Primary va primi un raspuns de la Secundary prin care i se spune ca conexiunea cu Internetul va fi preluata de el si pachetele vor merge prin legatura sa cu routerul Provider1 care inca mai este valabila. Mesajul BGP Update primit este prezintat in figura ce urmeaza:

Figura 41: BGP Update de la Primary către Secundary capturat cu Wireshark

Situatia imaginata este similara cu defectarea routerului Primary, caz in care rutarea pachetelor se va face prin Secundary si Provider1. Noua cale pe care o va avea comunicarea dintre cei doi utilizatori reali este prezentata mai jos:

UtilizatorReal2#traceroute 150.200.1.2

Type escape sequence to abort.

Tracing the route to 150.200.1.2

1 86.107.17.1 32 msec 44 msec 40 msec – legătura dintre OO și Distribution

2 86.107.5.2 64 msec 24 msec 24 msec – legătura dintre Distribution și Secundary

3 100.200.3.1 116 msec 128 msec 56 msec – legătura dintre Secundary și Provider1

4 20.150.1.1 104 msec 144 msec * – legătura dintre Provider1 și Internet

Un alt aspect ce a fost analizat pe rețeaua creata in GNS3 este reprezentat de performantele acesteia, si anume rata de transfer. Unul dintre utilizatori a devenit un server TFTP, iar celalalt client. TFTP este un protocol de transfer de fisiere foarte simplu, de aici și numele său –Protocol pentru Transferul Trivial al Fișierelor –Trivial File Transfer Protocol, pe scurt TFTP. Fiecare pachet nonterminal este confirmat separate. TFTP a fost implementat utilizand protocolul de transport UDP Internet User Datagram Protocol (UDP sau Datagram) pentru a putea fi folosit la transferal fișierelor intre mașini aflate pe rețele diferite ce implementeaza UDP. Este proiectat pentru a putea fi ușor de implementat. Singurul lucru pe care il face este sa scrie si sa citeasca fisierele (sau mesaje) de la/spre server de la distanta.

Figura 42: Analiza performantelor rețelei din GNS3

Rezultatul a fost ca s-a reusit descarcarea unui fișier de pe serverul FTP, cum este reprezentat in figurile urmatoare:

Figura 43: Transfer fisier de pe serverul TFTP

Figura 44: Vizualizare pachetelor primite de client de la server cu Wireshark

Figura 45: Structura unui pachet pimit de la server cu Wireshark

În cazul în care rețeaua creată ar fi fost reală, viteza de transfer a datelor ar fi fost de aproximativ 1.5 Mb/s, deoarece viteza finală este in concordanță cu viteza cea mai mica de transfer din toate legaturile prin care trece fluxul de date și anume legatura serială.

Având în vedere ca rețeaua creată este obtinuta in urma unei simulari in programul GNS3, luând in calcul si limitarile pe care le impune aplicatia folosita pentru realizare transferului (serverul TFTP folosit) și, de asemenea, luând in considerare interconectarea simulatorului cu echipamente reale, rata de transfer obținută scade dramatic, ajungând la o valoare de 3.5 Kb/s. În reprezentarea grafică a vitezei se observă o creștere continua a traficului, urmată de o staționare în jurul valorii de 3.3 Kb/s, viteza care scade rapid odata cu oprirea sau definitivarea transferului. Trebuie specificat ca viteza obtinuta se face prin medierea toturor valorilor instantanee de la inceputul trasferului si pana in momentul in care se face masuratoarea si ca aceasta viteza nu reprezinta viteza instantanee de transfer a datelor.

Figura 46: Reprezentarea grafică a vitezei de transfer

Rezultatele au fost obtinute cu ajutorul analizorului de rețea OmniPeek. Acest analizor de rețea permite o analiză complexă a performanțelor in mai multe segmente pe rețeaua studiată.

Figura 47: Reprezentarea grafică a vitezei de transfer și utilizării rețelei

Toate rezultatele obținute cu analizorul de retea OmniPeek au fost măsurate pe calculatorul cu rolul de Client.

S-a observat o creștere a ratei de transfer dacă fișierul a fost descărcat pe un echipament din rețeaua simulată în GNS3, și anume in flash-ul routerului Internet.

Internet#copy tftp flash:

Address or name of remote host [9.9.9.10]?

Source filename [fisier.pdf]?

Destination filename [fisier.pdf]?

Accessing tftp://9.9.9.10/fisier.pdf…

Erase flash: before copying? [confirm]n

Loading fisier.pdf from 9.9.9.10 (via Serial2/1): !!!!!!!

Internet#sh flash:

System flash directory:

File Length Name/status

1 2555904 fisier.pdf

[3687898 bytes used, 4700706 available, 8388604 total]

8192K bytes of processor board System flash (Read/Write)

Figura 48: Viteza de descarcare pe flash-ul routerului Internet

Trebuie specificat faptul ca s-au inversat rolurile serverului si al clientului TFTP si s-a obtinut aceeasi rata de transfer a fisierului.

Folosind aceeasi aplicatie s-au obtinut o viteza mult mai mare daca serverul si clientul ar fi interconectate printr-o rețea create din 5 routere reale.Trebuie specificat nu nu s-a mai pastrat configurarea IP-urilor pe intrefetele routerelor deoarece acest test a fost facut numai pentru a evidentia cum se comporta echipamentele reale la transferal unui fisier de pe server. Valoarea obtinuta este mult mai mare (de aproximativ 40 de ori) decat ratele de transfer cu care s-a descarcat fisierul cand serverul TFTP si clientul erau interconectati la reteaua simulate cu GNS3. Rezultatul obtinut este prezentat in figura ce urmeaza:

Figura 49: Viteza de descarcare pe un un calculator conectat printr-o

rețea fizică formată din 5 routere la serverul TFTP

Pentru a evidenția limitarea de viteză pe care o introduce GNS3 s-a mai testat rețeaua cu o altă aplicație.

Jperf este un program gratuit de generare și monitorizare a traficului din rețele IP, care poate fi obținut de la adresa WEB http://code.google.com/p/xjperf/ (varianta cu interfață grafică realizată în Java). El poate fi utilizat pentru a genera și măsura traficul de date prin rețeaua IP (TCP/UDP) pentru a evalua performanțele legăturii. Programul Jperf are o componentă server și alta client.

Rezultatele obtinute cu Jperf sunt prezentate în figurile ce urmează:

Figura 50: Viteza de transfer pe clientul Jperf obtinută prin interconectarea

echipamentelor reale cu rețeaua simulate in GNS3

S-a facut acelasi test pentru a evidentia ce limitari introduce simulatorul GNS3 si anume s-a inlocuit rețeaua simulata si s-au conectat doua PC-uri printr-o rețea create din 5 routere reale. S-a dorit sa se observe care este valoarea cu care se transmit pachete daca conectam calculatoarele printr-o rețea formată din echipamente fizice. Legaturile dintre routere si PC-uri au fost facute cu cabluri torsadate neecranate UTP categoria 5 (Unshielded Twisted Pair) numite adesea cabluri 100BASE-TX Ethernet, după Ethernet, standardul cel mai răspândit (dar nu și cel mai fiabil).

Trebuie remarcat faptul ca viteza a crescut extreme de mult, si anume a ajuns la valoarea de aproximativ 46.5 MBits/secundă. Comparând cu viteza de transfer a datelor (Bandwidth) obtinuta cand reteaua era simulata se observa o valoare de 100 de ori mai mare in acest test efectuat. Rezultatele facute prin conexiune TCP sunt prezentate in figurile de urmează:

Figura 51: Viteza de transfer a datelor pe clientul Jperf

Figura 52: Viteza de transfer a datelor de pe serverul Jperf

Figura 53: Valori exacte ale vitezei de transfer luate de pe

serverul Jperf în cazul testului cu rețeaua reală

Trebuie specificat faptul că masurătorile anterioare au fost facute alegând ca protocol de transport de nivel 4 OSI (Transport) TCP. S-a efectuat o serie de teste și cu protocolul neorientat pe conexiune UDP, însă trebuie studiate mai în detaliu optiunile pe care le oferă programul Jperf pentru configurare (dimensiunea bufferului UDP, dimensiunea unui pachet UDP și rata de transfer a datelor de pe client) deoarece valorile nu sunt deloc concludente. Un astfel de test este prezentat în figura ce urmează:

Figura 54:Viteza de transfer a datelor prin UDP masurată pe serverul Jperf

Rămâne de determinat, într-o lucrare viitoare, care sunt factorii ce reduc viteza de transfer și dacă aceasta situație se poate evita. De asemenea, trebuie avută în vedere și aplicația folosită prentru determinarea acestor factori, deoarece rezultatele pot varia foarte mult. Este necesar un studiu amănunțit al funcționarii simulatorului și, poate, folosirea/descoperirea unor programe cu performanțe superioare sau creșterea ratei de transfer între simulatorul GNS3 actual și rețelele fizice.

O altă problemă ce trebuie avută in vedere este eventualitatea în care în timpul unui transfer ne confruntăm cu indisponibilitatea unui router (defectare, pană de curent), caz in care transferal nu se mai poate incheia. Reluarea traficului ar trebui restabilită in scurt timp prin stabilirea unui nou traseu și preluarea acestuia de celelalte routere functionale.

O altă temă de abordat pe viitor este reprezentată de studierea convergenței unei rețele care folosește protocolului de rutare BGP, timpul până la stabilirea unui nou traseu pentru transferal de data, precum si factorii care influentează funcționalitatea si performanțele unei rețele.

Concluzii

Routarea implică două activități de bază: determinrea căilor optime de routare și transportarea grupurilor de informații (numite pachete) prin rețea. Protocoalele de routare folosesc diferite metrici pentru a evalua ce drum este optim pentru transportul unui pachet.

Protocolul RIP este unul dintre cele mai vechi și mai durabile protocoale. Sunt o mare varietate de protocoale asemănătoare sau bazate pe RIP. Protocolul folosește vectori de distanță pentru a calcula rutele și a alege ruta optimă.

OSPF este un protocol de routare link-state si publică către toate routerele din aceeași arie ierarhică. OSPF are două caracteristici primare: este deschis, adică specificațiile sunt în domeniul public și este bazat pe algoritmul SPF (algoritmul lui Dijkstra). Spre deosebire de RIP, OSPF poate opera într-o ierarhi, ce sunt reprezentate de un număr de arii, care sunt grupuri de rețele contigue.

EIGRP a fost dezvoltat de către Cisco (eliberat la începutul anilor ‘90) cu scopul de a îmbunătăți protocolul RIP. Tehnologiile cheie care se combină în EIGRP sunt neighbor discovery/recovery, reliable transport protocol (RTP), DUAL finite-state machine și module dependente de protocol.

BGP este un protocol de routare între sisteme autonome. Un sistem autonom (AS) este o rețea sau un grup de rețele sub o administrare unică cu aceleași reguli de routare în toată rețeaua. BGP este folosit pentru a comunica informații despre rute pentru Internet și este protocolul folosit între ISP. BGP este un protocol de routare foarte robust și scalabil (funcționează corect indiferent de mărimea rețelei), dovedit de faptul că BGP este protocolul de routare folosit în Internet.

In lucrarea de față s-a realizat o retea ipotetica conectata ulterior cu lumea reala, scopul principal fiind exemplificarea functionalitatii protocoalelor de rutare. In interiorul retelei au fost implementate atat protocoale de rutare interna, cat si protocoale de rutare externa. Accentul a fost pus pe modalitatile de rutare dinamica si controlul traficului, folosind protocolul BGP pentru rutarea inter-AS si atributele acestuia pentru control si politici de tranzitare. Reteaua construita a devenit functionala folosind simulatorul GNS3 ce permite emularea rețelelor complexe.

Rezultatul acestei lucrari a fost faptul ca s-a obtinut o retea cu aplicabilitate in lumea reala. Reteaua a fost interconectata cu doua PC-uri reale obtinandu-se, folosind diverse configurari si scenarii, un transfer al unui flux de date de la un PC la celalalt, fapt ce demonstreaza functionalitatea retelei. Principala problema întâmpinata a fost de rata de transfer cu care au receptionate pachetele, viteza ce a putut fi crescuta odata cu eliminarea unui PC fizic din scenariul stabilit. Astfel transferul de date este mai rapid realizat in cazul interconectarii unui singur PC pe post de server cu reteaua create in simulator, datele fiind descarcate in flash-ul routerului.

Rămâne de determinat, într-o lucrare viitoare, care sunt factorii ce reduc viteza de transfer și dacă aceasta situație se poate evita. Este necesar un studiu amănunțit al funcționarii simulatorului, aplicația folosită pentru determinare acestor factori și a ratei de transfer și, poate, folosirea/descoperirea unor programe cu performanțe superioare sau creșterea ratei de transfer între simulatorul GNS3 actual și rețelele fizice.

Bibliografie

Wikipedia: http://www.wikipedia.org/

Peter Norton, Dave Kearns, Retele de Calculatoare, Editura Teora, 1999

Andrew S. Tanenbaum,Retele de Calculatoare, ediția a 4-a, editura Byblos ,2009

Cisco Systems: http://www.cisco.com/

Ion Banica, Retele de comunicatii intre calculatoare, Editura Teora, 1998

RFC 1058, Routing Information Protocol, C. Hendrik, The Internet Society (June 1988)

RFC 1388, RIP Version 2 – Carrying Additional Information, G. Malkin, The Internet Society (January 1993)

RFC 2453, RIP Version 2, G. Malkin, The Internet Society (November 1998)

RFC 2082, RIP-2 MD5 Authentication, F. Baker, R. Atkinson, The Internet Society (January 1997)

RFC 3630 Traffic Engineering (TE) Extensions to OSPF Version 2. The Internet Society. OSPF TEextensions. Retrieved 2007-09-28

Berkowitz, Howard,OSPF Goodies for ISPs, North American Network Operators Group NANOG 17, Montreal, 1999

http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/index.htm

Cisco Systems (2005-08-10), Introduction to EIGRP, Document ID 13669, retrieved 2008-04-27

Cisco Systems (2005-09-09), Enhanced Interior Gateway Routing Protocol, Document ID 16406, retrieved 2008-04-27

Cisco Systems (n.d.), Internetworking Technology Handbook: Enhanced Interior Gateway Routing Protocol (EIGRP), retrieved 2008-04-27

RFC 2858, Multiprotocol Extensions for BGP-4, T. Bates et al.,June 2000

RFC 5065, Autonomous System Confederations for BGP, P. Traina et al., February 2001

RFC 2842, Publicarea capabilităților în BGP-4, R. Chandra & J. Scudder, mai 2000

RFC 4456 – Reflecția rutelor BGP: O alternativă la Internal BGP (iBGP) fiecare cu fiecare, T. Bates et al, aprilie 2006

Quoitin, Bruno; Steve Uhlig (November 2005). "Modeling the Routing of an Autonomous System with C-BGP". IEEE Network Magazine 19 (6)

David Kotfila, Joshua Moorhouse, Ross Wolfson, CCNP Building Scalable Internetworks (BSCI 642-901) , Edit. Cisco Press, Dec 2007

CCNP ROUTE 642.902, Official Certification Guide, Edit. Cisco Press, Feb 2010

CCIE -Troubleshooting IP Routing Protocols, Edit. Cisco Press, Feb 2010

Anexe

Routerul E

!

version 12.4

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname E

!

boot-start-marker

boot-end-marker

!

no aaa new-model

memory-size iomem 5

!

ip cef

!

interface Loopback1

ip address 10.10.10.10 255.255.255.255

!

interface Ethernet0/0

ip address 86.107.19.2 255.255.255.252

half-duplex

!

router eigrp 1

network 10.0.0.0

network 86.107.19.2 0.0.0.0

no auto-summary

!

ip http server

no ip http secure-server

!

control-plane

!

line con 0

exec-timeout 0 0

line aux 0

line vty 0 4

login

!

end

––––––––––––––––––––––

Routerul R

!

version 12.4

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname R

!

boot-start-marker

boot-end-marker

!

no aaa new-model

memory-size iomem 5

!

ip cef

!

interface Loopback1

ip address 11.11.11.11 255.255.255.255

!

interface Ethernet0/0

ip address 86.107.18.2 255.255.255.252

half-duplex

!

router rip

version 2

network 11.0.0.0

network 86.0.0.0

no auto-summary

!

ip http server

no ip http secure-server

!

control-plane

!

line con 0

line aux 0

line vty 0 4

login

!

end

––––––––––––––––––––––

Routerul OO

!

version 12.4

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname OO

!

boot-start-marker

boot-end-marker

!

no aaa new-model

memory-size iomem 5

!

ip cef

!

interface Loopback1

ip address 9.9.9.9 255.255.255.255

shutdown

!

interface Ethernet0/0

ip address 86.107.17.2 255.255.255.252

half-duplex

!

interface Ethernet0/1

ip address 9.9.9.9 255.255.255.252

half-duplex

!

router ospf 1

log-adjacency-changes

network 9.9.9.9 0.0.0.0 area 10

network 86.107.17.2 0.0.0.0 area 0

!

ip http server

no ip http secure-server

!

control-plane

!

line con 0

exec-timeout 0 0

line aux 0

line vty 0 4

login

!

end

––––––––––––––––––––––

Routerul OR

!

version 12.4

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname OR

!

boot-start-marker

boot-end-marker

!

no aaa new-model

memory-size iomem 5

!

ip cef

!

interface Ethernet0/0

ip address 86.107.15.2 255.255.255.252

half-duplex

!

interface Ethernet0/1

ip address 86.107.18.1 255.255.255.252

half-duplex

!

router ospf 1

log-adjacency-changes

redistribute rip subnets

network 86.107.15.2 0.0.0.0 area 0

!

router rip

version 2

redistribute ospf 1

network 86.0.0.0

default-metric 10

no auto-summary

!

ip http server

no ip http secure-server

!

control-plane

!

line con 0

line aux 0

line vty 0 4

login

!

end

––––––––––––––––––––––

Routerul OE

!

version 12.4

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname OE

!

boot-start-marker

boot-end-marker

!

no aaa new-model

memory-size iomem 5

!

ip cef

!

interface Ethernet0/0

ip address 86.107.16.2 255.255.255.252

half-duplex

!

interface Ethernet0/1

ip address 86.107.19.1 255.255.255.252

half-duplex

!

router eigrp 1

redistribute ospf 1 metric 1000 10 255 1 65535

network 86.107.19.1 0.0.0.0

no auto-summary

!

router ospf 1

log-adjacency-changes

redistribute eigrp 1 subnets

network 86.107.16.2 0.0.0.0 area 0

!

ip http server

no ip http secure-server

!

control-plane

!

line con 0

exec-timeout 0 0

line aux 0

line vty 0 4

login

!

end

––––––––––––––––––––––

Routerul Distribution

!

version 12.4

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname Distribution

!

boot-start-marker

boot-end-marker

!

no aaa new-model

memory-size iomem 5

!

ip cef

no ip domain lookup

!

interface Loopback0

ip address 1.1.1.1 255.255.255.255

!

interface Loopback2

ip address 86.107.8.1 255.255.255.255

!

interface Loopback3

ip address 86.107.9.1 255.255.255.255

!

interface Loopback4

ip address 86.107.10.1 255.255.255.255

!

interface Ethernet0/0

ip address 86.107.4.1 255.255.255.252

half-duplex

!

interface Ethernet0/1

ip address 86.107.5.1 255.255.255.252

half-duplex

!

interface Ethernet0/2

ip address 86.107.15.1 255.255.255.252

half-duplex

!

interface Ethernet0/3

ip address 86.107.16.1 255.255.255.252

half-duplex

!

interface Ethernet1/0

ip address 86.107.17.1 255.255.255.252

half-duplex

!

router ospf 1

log-adjacency-changes

redistribute static subnets

network 1.1.1.1 0.0.0.0 area 0

network 86.107.4.0 0.0.0.3 area 1

network 86.107.5.0 0.0.0.3 area 1

network 86.107.8.1 0.0.0.0 area 0

network 86.107.9.1 0.0.0.0 area 0

network 86.107.10.1 0.0.0.0 area 0

network 86.107.15.1 0.0.0.0 area 0

network 86.107.16.1 0.0.0.0 area 0

network 86.107.17.1 0.0.0.0 area 0

default-information originate always

!

no ip http server

no ip http secure-server

ip route 0.0.0.0 0.0.0.0 86.107.4.2 10

ip route 0.0.0.0 0.0.0.0 86.107.5.2 20

!

control-plane

!

line con 0

exec-timeout 0 0

logging synchronous

line aux 0

line vty 0 4

login

!

end

––––––––––––––––––––––

Routerul Primary

!

version 12.4

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname Primary

!

boot-start-marker

boot-end-marker

!

no aaa new-model

memory-size iomem 5

!

ip cef

no ip domain lookup

!

interface Loopback0

ip address 3.3.3.3 255.255.255.255

!

interface Loopback1

ip address 86.107.1.1 255.255.255.255

!

interface Ethernet0/0

ip address 86.107.2.1 255.255.255.252

half-duplex

!

interface Ethernet0/1

ip address 86.107.3.1 255.255.255.252

half-duplex

!

interface Ethernet1/0

ip address 86.107.4.2 255.255.255.252

half-duplex

!

interface Serial2/0

ip address 100.200.2.2 255.255.255.252

serial restart-delay 0

clock rate 2016000

!

interface Serial2/1

ip address 100.200.1.2 255.255.255.252

serial restart-delay 0

clock rate 2016000

!

router ospf 1

log-adjacency-changes

network 3.3.3.3 0.0.0.0 area 1

network 86.107.1.1 0.0.0.0 area 1

network 86.107.2.0 0.0.0.3 area 1

network 86.107.3.0 0.0.0.3 area 1

network 86.107.4.0 0.0.0.3 area 1

!

router bgp 8754

no synchronization

bgp log-neighbor-changes

aggregate-address 86.107.0.0 255.255.224.0 summary-only

redistribute connected

redistribute ospf 1 match internal external 1 external 2

neighbor 1.1.1.1 remote-as 8754

neighbor 1.1.1.1 update-source Loopback0

neighbor 2.2.2.2 remote-as 8754

neighbor 2.2.2.2 update-source Loopback0

neighbor 100.200.1.1 remote-as 5700

neighbor 100.200.1.1 route-map SET_LOCALPREF_PROVIDER2 in

neighbor 100.200.1.1 route-map Link_to_Provider2 out

neighbor 100.200.2.1 remote-as 6800

neighbor 100.200.2.1 route-map SET_LOCALPREF_PROVIDER1 in

neighbor 100.200.2.1 route-map Link_to_ISP1 out

no auto-summary

!

no ip http server

no ip http secure-server

!

ip as-path access-list 10 deny ^5700_

ip as-path access-list 10 permit .*

ip as-path access-list 20 deny ^6800_

ip as-path access-list 20 permit .*

ip as-path access-list 30 permit ^6800_

ip as-path access-list 40 permit ^5700_

!

route-map Link_to_Provider1 permit 10

match as-path 10

set metric 150

!

route-map Link_to_Provider2 permit 10

match as-path 20

set metric 250

!

route-map SET_LOCALPREF_PROVIDER1 permit 10

match as-path 30

set local-preference 2500

!

route-map SET_LOCALPREF_PROVIDER2 permit 10

match as-path 40

set local-preference 500

!

control-plane

!

line con 0

exec-timeout 0 0

logging synchronous

line aux 0

line vty 0 4

login

!

end

––––––––––––––––––––––

Routerul Secundary

!

version 12.4

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname Secundary

!

boot-start-marker

boot-end-marker

!

no aaa new-model

memory-size iomem 5

!

ip cef

no ip domain lookup

!

interface Loopback0

ip address 2.2.2.2 255.255.255.255

!

interface Loopback1

ip address 86.107.6.1 255.255.255.255

!

interface Loopback2

ip address 86.107.7.1 255.255.255.255

!

interface Ethernet0/0

ip address 86.107.2.2 255.255.255.252

half-duplex

!

interface Ethernet0/1

ip address 86.107.3.2 255.255.255.252

half-duplex

!

interface Ethernet1/0

ip address 86.107.5.2 255.255.255.252

half-duplex

!

interface Serial2/0

ip address 100.200.3.2 255.255.255.252

serial restart-delay 0

clock rate 2016000

!

router ospf 1

log-adjacency-changes

network 2.2.2.2 0.0.0.0 area 1

network 86.107.2.0 0.0.0.3 area 1

network 86.107.3.0 0.0.0.3 area 1

network 86.107.5.0 0.0.0.3 area 1

network 86.107.6.1 0.0.0.0 area 1

network 86.107.7.1 0.0.0.0 area 1

!

router bgp 8754

no synchronization

bgp log-neighbor-changes

aggregate-address 86.107.0.0 255.255.224.0 summary-only

redistribute connected

redistribute ospf 1 match internal external 1 external 2

neighbor 1.1.1.1 remote-as 8754

neighbor 1.1.1.1 update-source Loopback0

neighbor 1.1.1.1 distribute-list 1 out

neighbor 3.3.3.3 remote-as 8754

neighbor 3.3.3.3 update-source Loopback0

neighbor 3.3.3.3 distribute-list 1 out

neighbor 100.200.3.1 remote-as 6800

neighbor 100.200.3.1 distribute-list 1 out

neighbor 100.200.3.1 route-map SET_LOCALPREF_Provider1 in

neighbor 100.200.3.1 route-map Link_to_Provider1 out

no auto-summary

!

no ip http server

no ip http secure-server

!

ip as-path access-list 10 deny ^5700_

ip as-path access-list 10 permit .*

ip as-path access-list 20 permit ^6800_

!

access-list 1 deny 86.107.6.1

access-list 1 deny 86.107.7.1

access-list 1 permit any

access-list 110 deny ip 86.107.9.0 0.0.0.255 host 86.107.7.1

access-list 110 deny ip 86.107.10.0 0.0.0.255 host 86.107.6.1

access-list 110 permit ip any any

!

route-map Link_to_Provider1 permit 10

match as-path 10

set metric 200

!

route-map SET_LOCALPREF_Provider1 permit 10

match as-path 20

set local-preference 2000

!

control-plane

!

line con 0

exec-timeout 0 0

logging synchronous

line aux 0

line vty 0 4

login

!

end

––––––––––––––––––––––

Routerul Provider1

!

version 12.4

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname Provider1

!

boot-start-marker

boot-end-marker

!

no aaa new-model

memory-size iomem 5

!

ip cef

no ip domain lookup

!

interface Loopback0

ip address 4.4.4.4 255.255.255.255

!

interface Loopback1

ip address 93.120.1.1 255.255.255.255

!

interface Serial2/0

ip address 100.200.2.1 255.255.255.252

serial restart-delay 0

clock rate 2016000

!

interface Serial2/1

ip address 100.200.3.1 255.255.255.252

serial restart-delay 0

clock rate 2016000

!

interface Serial2/2

ip address 50.100.2.2 255.255.255.252

serial restart-delay 0

clock rate 2016000

!

interface Serial2/3

ip address 20.150.1.2 255.255.255.252

serial restart-delay 0

clock rate 2016000

!

router bgp 6800

no synchronization

bgp log-neighbor-changes

redistribute connected

neighbor 6.6.6.6 remote-as 9500

neighbor 6.6.6.6 ebgp-multihop 2

neighbor 6.6.6.6 update-source Loopback0

neighbor 6.6.6.6 route-map Weight_to_InterProviders in

neighbor 6.6.6.6 route-map Restrict_to_InterProviders out

neighbor 7.7.7.7 remote-as 4550

neighbor 7.7.7.7 ebgp-multihop 2

neighbor 7.7.7.7 update-source Loopback0

neighbor 7.7.7.7 route-map Weight_to_Internet in

neighbor 7.7.7.7 route-map Restrict_to_Internet out

neighbor 100.200.2.2 remote-as 8754

neighbor 100.200.2.2 default-originate

neighbor 100.200.2.2 route-map Weight_to_client in

neighbor 100.200.3.2 remote-as 8754

neighbor 100.200.3.2 default-originate

neighbor 100.200.3.2 route-map Weight_to_client in

no auto-summary

!

no ip http server

no ip http secure-server

ip route 2.2.2.2 255.255.255.255 Serial2/1

ip route 3.3.3.3 255.255.255.255 Serial2/0

ip route 6.6.6.6 255.255.255.255 Serial2/2

ip route 7.7.7.7 255.255.255.255 Serial2/3

!

ip as-path access-list 10 permit ^4550_

ip as-path access-list 20 permit ^9500_

ip as-path access-list 30 deny ^4550_

ip as-path access-list 30 permit .*

ip as-path access-list 40 deny ^9500_

ip as-path access-list 40 permit .*

ip as-path access-list 50 permit ^8754_

!

route-map Weight_to_Internet permit 10

match as-path 10

set weight 200

!

route-map Restrict_to_Internet permit 10

match as-path 40

!

route-map Weight_to_client permit 10

match as-path 50

set weight 3000

!

route-map Restrict_to_InterProviders permit 10

match as-path 30

!

route-map Weight_to_InterProviders permit 10

match as-path 20

set weight 2000

!

control-plane

!

line con 0

exec-timeout 0 0

logging synchronous

line aux 0

line vty 0 4

login

!

end

––––––––––––––––––––––

Routerul Provider2

!

version 12.4

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname Provider2

!

boot-start-marker

boot-end-marker

!

no aaa new-model

memory-size iomem 5

!

ip cef

no ip domain lookup

!

interface Loopback0

ip address 5.5.5.5 255.255.255.255

!

interface Loopback1

ip address 91.120.1.1 255.255.255.255

!

interface Serial2/0

ip address 100.200.1.1 255.255.255.252

serial restart-delay 0

clock rate 2016000

!

interface Serial2/1

ip address 50.100.1.2 255.255.255.252

serial restart-delay 0

clock rate 2016000

!

interface Serial2/2

ip address 20.150.2.2 255.255.255.252

serial restart-delay 0

clock rate 2016000

!

router bgp 5700

no synchronization

bgp log-neighbor-changes

redistribute connected

neighbor 6.6.6.6 remote-as 9500

neighbor 6.6.6.6 ebgp-multihop 2

neighbor 6.6.6.6 update-source Loopback0

neighbor 6.6.6.6 route-map Weight_to_InterProviders in

neighbor 6.6.6.6 route-map Restrict_to_InterProviders out

neighbor 7.7.7.7 remote-as 4550

neighbor 7.7.7.7 ebgp-multihop 2

neighbor 7.7.7.7 update-source Loopback0

neighbor 7.7.7.7 route-map Weight_to_Internet in

neighbor 7.7.7.7 route-map Restrict_to_Internet out

neighbor 100.200.1.2 remote-as 8754

neighbor 100.200.1.2 default-originate

neighbor 100.200.1.2 route-map Weight_to_client in

no auto-summary

!

no ip http server

no ip http secure-server

ip route 3.3.3.3 255.255.255.255 Serial2/0

ip route 6.6.6.6 255.255.255.255 Serial2/1

ip route 7.7.7.7 255.255.255.255 Serial2/2

!

ip as-path access-list 10 permit ^4550_

ip as-path access-list 20 permit ^9500_

ip as-path access-list 30 deny ^9500_

ip as-path access-list 30 permit .*

ip as-path access-list 40 deny ^4550_

ip as-path access-list 40 permit .*

ip as-path access-list 50 permit ^8754_

!

route-map Weight_to_Internet permit 10

match as-path 10

set weight 200

!

route-map Restrict_to_Internet permit 10

match as-path 30

!

route-map Weight_to_client permit 10

match as-path 50

set weight 3000

!

route-map Restrict_to_InterProviders permit 10

match as-path 40

!

route-map Weight_to_InterProviders permit 10

match as-path 20

set weight 2000

!

control-plane

!

line con 0

exec-timeout 0 0

logging synchronous

line aux 0

line vty 0 4

login

!

end

––––––––––––––––––––––

Routerul InterProviders

!

version 12.4

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname InterProviders

!

boot-start-marker

boot-end-marker

!

no aaa new-model

memory-size iomem 5

!

ip cef

no ip domain lookup

!

interface Loopback0

ip address 6.6.6.6 255.255.255.255

!

interface Loopback1

ip address 92.120.1.1 255.255.255.255

!

interface Serial2/0

ip address 50.100.1.1 255.255.255.252

serial restart-delay 0

clock rate 2016000

!

interface Serial2/1

ip address 50.100.2.1 255.255.255.252

serial restart-delay 0

clock rate 2016000

!

router bgp 9500

no synchronization

bgp log-neighbor-changes

redistribute connected

neighbor 4.4.4.4 remote-as 6800

neighbor 4.4.4.4 ebgp-multihop 2

neighbor 4.4.4.4 update-source Loopback0

neighbor 5.5.5.5 remote-as 5700

neighbor 5.5.5.5 ebgp-multihop 2

neighbor 5.5.5.5 update-source Loopback0

no auto-summary

!

no ip http server

no ip http secure-server

ip route 4.4.4.4 255.255.255.255 Serial2/0

ip route 4.4.4.4 255.255.255.255 Serial2/1

ip route 5.5.5.5 255.255.255.255 Serial2/0

!

control-plane

!

line con 0

exec-timeout 0 0

logging synchronous

line aux 0

line vty 0 4

login

!

end

––––––––––––––––––––––

Routerul Internet

!

version 12.4

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname Internet

!

boot-start-marker

boot-end-marker

!

no aaa new-model

memory-size iomem 5

!

ip cef

no ip domain lookup

!

interface Loopback0

ip address 7.7.7.7 255.255.255.255

!

interface Loopback1

ip address 94.120.1.1 255.255.255.255

!

interface Ethernet0/0

ip address 150.200.1.1 255.255.255.252

full-duplex

!

interface Serial2/0

ip address 20.150.2.1 255.255.255.252

serial restart-delay 0

clock rate 2016000

!

interface Serial2/1

ip address 20.150.1.1 255.255.255.252

serial restart-delay 0

clock rate 2016000

!

router bgp 4550

no synchronization

bgp log-neighbor-changes

redistribute connected

neighbor 4.4.4.4 remote-as 6800

neighbor 4.4.4.4 ebgp-multihop 2

neighbor 4.4.4.4 update-source Loopback0

neighbor 4.4.4.4 default-originate

neighbor 4.4.4.4 route-map Weight_to_Provider1 in

neighbor 5.5.5.5 remote-as 5700

neighbor 5.5.5.5 ebgp-multihop 2

neighbor 5.5.5.5 update-source Loopback0

neighbor 5.5.5.5 default-originate

neighbor 5.5.5.5 route-map Weight_to_Provider2 in

neighbor 8.8.8.8 remote-as 7350

neighbor 8.8.8.8 ebgp-multihop 2

neighbor 8.8.8.8 update-source Loopback0

neighbor 8.8.8.8 default-originate

no auto-summary

!

no ip http server

no ip http secure-server

ip route 4.4.4.4 255.255.255.255 Serial2/1

ip route 5.5.5.5 255.255.255.255 Serial2/0

ip route 8.8.8.8 255.255.255.255 Ethernet0/0

!

ip as-path access-list 10 permit ^5700_

ip as-path access-list 20 permit ^6800_

!

route-map Weight_to_Provider1 permit 10

match as-path 20

set weight 2000

!

route-map Weight_to_Provider2 permit 10

match as-path 10

set weight 200

!

control-plane

line con 0

exec-timeout 0 0

logging synchronous

line aux 0

line vty 0 4

login

!

end

––––––––––––––––––––––

Bibliografie

Wikipedia: http://www.wikipedia.org/

Peter Norton, Dave Kearns, Retele de Calculatoare, Editura Teora, 1999

Andrew S. Tanenbaum,Retele de Calculatoare, ediția a 4-a, editura Byblos ,2009

Cisco Systems: http://www.cisco.com/

Ion Banica, Retele de comunicatii intre calculatoare, Editura Teora, 1998

RFC 1058, Routing Information Protocol, C. Hendrik, The Internet Society (June 1988)

RFC 1388, RIP Version 2 – Carrying Additional Information, G. Malkin, The Internet Society (January 1993)

RFC 2453, RIP Version 2, G. Malkin, The Internet Society (November 1998)

RFC 2082, RIP-2 MD5 Authentication, F. Baker, R. Atkinson, The Internet Society (January 1997)

RFC 3630 Traffic Engineering (TE) Extensions to OSPF Version 2. The Internet Society. OSPF TEextensions. Retrieved 2007-09-28

Berkowitz, Howard,OSPF Goodies for ISPs, North American Network Operators Group NANOG 17, Montreal, 1999

http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/index.htm

Cisco Systems (2005-08-10), Introduction to EIGRP, Document ID 13669, retrieved 2008-04-27

Cisco Systems (2005-09-09), Enhanced Interior Gateway Routing Protocol, Document ID 16406, retrieved 2008-04-27

Cisco Systems (n.d.), Internetworking Technology Handbook: Enhanced Interior Gateway Routing Protocol (EIGRP), retrieved 2008-04-27

RFC 2858, Multiprotocol Extensions for BGP-4, T. Bates et al.,June 2000

RFC 5065, Autonomous System Confederations for BGP, P. Traina et al., February 2001

RFC 2842, Publicarea capabilităților în BGP-4, R. Chandra & J. Scudder, mai 2000

RFC 4456 – Reflecția rutelor BGP: O alternativă la Internal BGP (iBGP) fiecare cu fiecare, T. Bates et al, aprilie 2006

Quoitin, Bruno; Steve Uhlig (November 2005). "Modeling the Routing of an Autonomous System with C-BGP". IEEE Network Magazine 19 (6)

David Kotfila, Joshua Moorhouse, Ross Wolfson, CCNP Building Scalable Internetworks (BSCI 642-901) , Edit. Cisco Press, Dec 2007

CCNP ROUTE 642.902, Official Certification Guide, Edit. Cisco Press, Feb 2010

CCIE -Troubleshooting IP Routing Protocols, Edit. Cisco Press, Feb 2010

Anexe

Routerul E

!

version 12.4

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname E

!

boot-start-marker

boot-end-marker

!

no aaa new-model

memory-size iomem 5

!

ip cef

!

interface Loopback1

ip address 10.10.10.10 255.255.255.255

!

interface Ethernet0/0

ip address 86.107.19.2 255.255.255.252

half-duplex

!

router eigrp 1

network 10.0.0.0

network 86.107.19.2 0.0.0.0

no auto-summary

!

ip http server

no ip http secure-server

!

control-plane

!

line con 0

exec-timeout 0 0

line aux 0

line vty 0 4

login

!

end

––––––––––––––––––––––

Routerul R

!

version 12.4

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname R

!

boot-start-marker

boot-end-marker

!

no aaa new-model

memory-size iomem 5

!

ip cef

!

interface Loopback1

ip address 11.11.11.11 255.255.255.255

!

interface Ethernet0/0

ip address 86.107.18.2 255.255.255.252

half-duplex

!

router rip

version 2

network 11.0.0.0

network 86.0.0.0

no auto-summary

!

ip http server

no ip http secure-server

!

control-plane

!

line con 0

line aux 0

line vty 0 4

login

!

end

––––––––––––––––––––––

Routerul OO

!

version 12.4

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname OO

!

boot-start-marker

boot-end-marker

!

no aaa new-model

memory-size iomem 5

!

ip cef

!

interface Loopback1

ip address 9.9.9.9 255.255.255.255

shutdown

!

interface Ethernet0/0

ip address 86.107.17.2 255.255.255.252

half-duplex

!

interface Ethernet0/1

ip address 9.9.9.9 255.255.255.252

half-duplex

!

router ospf 1

log-adjacency-changes

network 9.9.9.9 0.0.0.0 area 10

network 86.107.17.2 0.0.0.0 area 0

!

ip http server

no ip http secure-server

!

control-plane

!

line con 0

exec-timeout 0 0

line aux 0

line vty 0 4

login

!

end

––––––––––––––––––––––

Routerul OR

!

version 12.4

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname OR

!

boot-start-marker

boot-end-marker

!

no aaa new-model

memory-size iomem 5

!

ip cef

!

interface Ethernet0/0

ip address 86.107.15.2 255.255.255.252

half-duplex

!

interface Ethernet0/1

ip address 86.107.18.1 255.255.255.252

half-duplex

!

router ospf 1

log-adjacency-changes

redistribute rip subnets

network 86.107.15.2 0.0.0.0 area 0

!

router rip

version 2

redistribute ospf 1

network 86.0.0.0

default-metric 10

no auto-summary

!

ip http server

no ip http secure-server

!

control-plane

!

line con 0

line aux 0

line vty 0 4

login

!

end

––––––––––––––––––––––

Routerul OE

!

version 12.4

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname OE

!

boot-start-marker

boot-end-marker

!

no aaa new-model

memory-size iomem 5

!

ip cef

!

interface Ethernet0/0

ip address 86.107.16.2 255.255.255.252

half-duplex

!

interface Ethernet0/1

ip address 86.107.19.1 255.255.255.252

half-duplex

!

router eigrp 1

redistribute ospf 1 metric 1000 10 255 1 65535

network 86.107.19.1 0.0.0.0

no auto-summary

!

router ospf 1

log-adjacency-changes

redistribute eigrp 1 subnets

network 86.107.16.2 0.0.0.0 area 0

!

ip http server

no ip http secure-server

!

control-plane

!

line con 0

exec-timeout 0 0

line aux 0

line vty 0 4

login

!

end

––––––––––––––––––––––

Routerul Distribution

!

version 12.4

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname Distribution

!

boot-start-marker

boot-end-marker

!

no aaa new-model

memory-size iomem 5

!

ip cef

no ip domain lookup

!

interface Loopback0

ip address 1.1.1.1 255.255.255.255

!

interface Loopback2

ip address 86.107.8.1 255.255.255.255

!

interface Loopback3

ip address 86.107.9.1 255.255.255.255

!

interface Loopback4

ip address 86.107.10.1 255.255.255.255

!

interface Ethernet0/0

ip address 86.107.4.1 255.255.255.252

half-duplex

!

interface Ethernet0/1

ip address 86.107.5.1 255.255.255.252

half-duplex

!

interface Ethernet0/2

ip address 86.107.15.1 255.255.255.252

half-duplex

!

interface Ethernet0/3

ip address 86.107.16.1 255.255.255.252

half-duplex

!

interface Ethernet1/0

ip address 86.107.17.1 255.255.255.252

half-duplex

!

router ospf 1

log-adjacency-changes

redistribute static subnets

network 1.1.1.1 0.0.0.0 area 0

network 86.107.4.0 0.0.0.3 area 1

network 86.107.5.0 0.0.0.3 area 1

network 86.107.8.1 0.0.0.0 area 0

network 86.107.9.1 0.0.0.0 area 0

network 86.107.10.1 0.0.0.0 area 0

network 86.107.15.1 0.0.0.0 area 0

network 86.107.16.1 0.0.0.0 area 0

network 86.107.17.1 0.0.0.0 area 0

default-information originate always

!

no ip http server

no ip http secure-server

ip route 0.0.0.0 0.0.0.0 86.107.4.2 10

ip route 0.0.0.0 0.0.0.0 86.107.5.2 20

!

control-plane

!

line con 0

exec-timeout 0 0

logging synchronous

line aux 0

line vty 0 4

login

!

end

––––––––––––––––––––––

Routerul Primary

!

version 12.4

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname Primary

!

boot-start-marker

boot-end-marker

!

no aaa new-model

memory-size iomem 5

!

ip cef

no ip domain lookup

!

interface Loopback0

ip address 3.3.3.3 255.255.255.255

!

interface Loopback1

ip address 86.107.1.1 255.255.255.255

!

interface Ethernet0/0

ip address 86.107.2.1 255.255.255.252

half-duplex

!

interface Ethernet0/1

ip address 86.107.3.1 255.255.255.252

half-duplex

!

interface Ethernet1/0

ip address 86.107.4.2 255.255.255.252

half-duplex

!

interface Serial2/0

ip address 100.200.2.2 255.255.255.252

serial restart-delay 0

clock rate 2016000

!

interface Serial2/1

ip address 100.200.1.2 255.255.255.252

serial restart-delay 0

clock rate 2016000

!

router ospf 1

log-adjacency-changes

network 3.3.3.3 0.0.0.0 area 1

network 86.107.1.1 0.0.0.0 area 1

network 86.107.2.0 0.0.0.3 area 1

network 86.107.3.0 0.0.0.3 area 1

network 86.107.4.0 0.0.0.3 area 1

!

router bgp 8754

no synchronization

bgp log-neighbor-changes

aggregate-address 86.107.0.0 255.255.224.0 summary-only

redistribute connected

redistribute ospf 1 match internal external 1 external 2

neighbor 1.1.1.1 remote-as 8754

neighbor 1.1.1.1 update-source Loopback0

neighbor 2.2.2.2 remote-as 8754

neighbor 2.2.2.2 update-source Loopback0

neighbor 100.200.1.1 remote-as 5700

neighbor 100.200.1.1 route-map SET_LOCALPREF_PROVIDER2 in

neighbor 100.200.1.1 route-map Link_to_Provider2 out

neighbor 100.200.2.1 remote-as 6800

neighbor 100.200.2.1 route-map SET_LOCALPREF_PROVIDER1 in

neighbor 100.200.2.1 route-map Link_to_ISP1 out

no auto-summary

!

no ip http server

no ip http secure-server

!

ip as-path access-list 10 deny ^5700_

ip as-path access-list 10 permit .*

ip as-path access-list 20 deny ^6800_

ip as-path access-list 20 permit .*

ip as-path access-list 30 permit ^6800_

ip as-path access-list 40 permit ^5700_

!

route-map Link_to_Provider1 permit 10

match as-path 10

set metric 150

!

route-map Link_to_Provider2 permit 10

match as-path 20

set metric 250

!

route-map SET_LOCALPREF_PROVIDER1 permit 10

match as-path 30

set local-preference 2500

!

route-map SET_LOCALPREF_PROVIDER2 permit 10

match as-path 40

set local-preference 500

!

control-plane

!

line con 0

exec-timeout 0 0

logging synchronous

line aux 0

line vty 0 4

login

!

end

––––––––––––––––––––––

Routerul Secundary

!

version 12.4

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname Secundary

!

boot-start-marker

boot-end-marker

!

no aaa new-model

memory-size iomem 5

!

ip cef

no ip domain lookup

!

interface Loopback0

ip address 2.2.2.2 255.255.255.255

!

interface Loopback1

ip address 86.107.6.1 255.255.255.255

!

interface Loopback2

ip address 86.107.7.1 255.255.255.255

!

interface Ethernet0/0

ip address 86.107.2.2 255.255.255.252

half-duplex

!

interface Ethernet0/1

ip address 86.107.3.2 255.255.255.252

half-duplex

!

interface Ethernet1/0

ip address 86.107.5.2 255.255.255.252

half-duplex

!

interface Serial2/0

ip address 100.200.3.2 255.255.255.252

serial restart-delay 0

clock rate 2016000

!

router ospf 1

log-adjacency-changes

network 2.2.2.2 0.0.0.0 area 1

network 86.107.2.0 0.0.0.3 area 1

network 86.107.3.0 0.0.0.3 area 1

network 86.107.5.0 0.0.0.3 area 1

network 86.107.6.1 0.0.0.0 area 1

network 86.107.7.1 0.0.0.0 area 1

!

router bgp 8754

no synchronization

bgp log-neighbor-changes

aggregate-address 86.107.0.0 255.255.224.0 summary-only

redistribute connected

redistribute ospf 1 match internal external 1 external 2

neighbor 1.1.1.1 remote-as 8754

neighbor 1.1.1.1 update-source Loopback0

neighbor 1.1.1.1 distribute-list 1 out

neighbor 3.3.3.3 remote-as 8754

neighbor 3.3.3.3 update-source Loopback0

neighbor 3.3.3.3 distribute-list 1 out

neighbor 100.200.3.1 remote-as 6800

neighbor 100.200.3.1 distribute-list 1 out

neighbor 100.200.3.1 route-map SET_LOCALPREF_Provider1 in

neighbor 100.200.3.1 route-map Link_to_Provider1 out

no auto-summary

!

no ip http server

no ip http secure-server

!

ip as-path access-list 10 deny ^5700_

ip as-path access-list 10 permit .*

ip as-path access-list 20 permit ^6800_

!

access-list 1 deny 86.107.6.1

access-list 1 deny 86.107.7.1

access-list 1 permit any

access-list 110 deny ip 86.107.9.0 0.0.0.255 host 86.107.7.1

access-list 110 deny ip 86.107.10.0 0.0.0.255 host 86.107.6.1

access-list 110 permit ip any any

!

route-map Link_to_Provider1 permit 10

match as-path 10

set metric 200

!

route-map SET_LOCALPREF_Provider1 permit 10

match as-path 20

set local-preference 2000

!

control-plane

!

line con 0

exec-timeout 0 0

logging synchronous

line aux 0

line vty 0 4

login

!

end

––––––––––––––––––––––

Routerul Provider1

!

version 12.4

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname Provider1

!

boot-start-marker

boot-end-marker

!

no aaa new-model

memory-size iomem 5

!

ip cef

no ip domain lookup

!

interface Loopback0

ip address 4.4.4.4 255.255.255.255

!

interface Loopback1

ip address 93.120.1.1 255.255.255.255

!

interface Serial2/0

ip address 100.200.2.1 255.255.255.252

serial restart-delay 0

clock rate 2016000

!

interface Serial2/1

ip address 100.200.3.1 255.255.255.252

serial restart-delay 0

clock rate 2016000

!

interface Serial2/2

ip address 50.100.2.2 255.255.255.252

serial restart-delay 0

clock rate 2016000

!

interface Serial2/3

ip address 20.150.1.2 255.255.255.252

serial restart-delay 0

clock rate 2016000

!

router bgp 6800

no synchronization

bgp log-neighbor-changes

redistribute connected

neighbor 6.6.6.6 remote-as 9500

neighbor 6.6.6.6 ebgp-multihop 2

neighbor 6.6.6.6 update-source Loopback0

neighbor 6.6.6.6 route-map Weight_to_InterProviders in

neighbor 6.6.6.6 route-map Restrict_to_InterProviders out

neighbor 7.7.7.7 remote-as 4550

neighbor 7.7.7.7 ebgp-multihop 2

neighbor 7.7.7.7 update-source Loopback0

neighbor 7.7.7.7 route-map Weight_to_Internet in

neighbor 7.7.7.7 route-map Restrict_to_Internet out

neighbor 100.200.2.2 remote-as 8754

neighbor 100.200.2.2 default-originate

neighbor 100.200.2.2 route-map Weight_to_client in

neighbor 100.200.3.2 remote-as 8754

neighbor 100.200.3.2 default-originate

neighbor 100.200.3.2 route-map Weight_to_client in

no auto-summary

!

no ip http server

no ip http secure-server

ip route 2.2.2.2 255.255.255.255 Serial2/1

ip route 3.3.3.3 255.255.255.255 Serial2/0

ip route 6.6.6.6 255.255.255.255 Serial2/2

ip route 7.7.7.7 255.255.255.255 Serial2/3

!

ip as-path access-list 10 permit ^4550_

ip as-path access-list 20 permit ^9500_

ip as-path access-list 30 deny ^4550_

ip as-path access-list 30 permit .*

ip as-path access-list 40 deny ^9500_

ip as-path access-list 40 permit .*

ip as-path access-list 50 permit ^8754_

!

route-map Weight_to_Internet permit 10

match as-path 10

set weight 200

!

route-map Restrict_to_Internet permit 10

match as-path 40

!

route-map Weight_to_client permit 10

match as-path 50

set weight 3000

!

route-map Restrict_to_InterProviders permit 10

match as-path 30

!

route-map Weight_to_InterProviders permit 10

match as-path 20

set weight 2000

!

control-plane

!

line con 0

exec-timeout 0 0

logging synchronous

line aux 0

line vty 0 4

login

!

end

––––––––––––––––––––––

Routerul Provider2

!

version 12.4

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname Provider2

!

boot-start-marker

boot-end-marker

!

no aaa new-model

memory-size iomem 5

!

ip cef

no ip domain lookup

!

interface Loopback0

ip address 5.5.5.5 255.255.255.255

!

interface Loopback1

ip address 91.120.1.1 255.255.255.255

!

interface Serial2/0

ip address 100.200.1.1 255.255.255.252

serial restart-delay 0

clock rate 2016000

!

interface Serial2/1

ip address 50.100.1.2 255.255.255.252

serial restart-delay 0

clock rate 2016000

!

interface Serial2/2

ip address 20.150.2.2 255.255.255.252

serial restart-delay 0

clock rate 2016000

!

router bgp 5700

no synchronization

bgp log-neighbor-changes

redistribute connected

neighbor 6.6.6.6 remote-as 9500

neighbor 6.6.6.6 ebgp-multihop 2

neighbor 6.6.6.6 update-source Loopback0

neighbor 6.6.6.6 route-map Weight_to_InterProviders in

neighbor 6.6.6.6 route-map Restrict_to_InterProviders out

neighbor 7.7.7.7 remote-as 4550

neighbor 7.7.7.7 ebgp-multihop 2

neighbor 7.7.7.7 update-source Loopback0

neighbor 7.7.7.7 route-map Weight_to_Internet in

neighbor 7.7.7.7 route-map Restrict_to_Internet out

neighbor 100.200.1.2 remote-as 8754

neighbor 100.200.1.2 default-originate

neighbor 100.200.1.2 route-map Weight_to_client in

no auto-summary

!

no ip http server

no ip http secure-server

ip route 3.3.3.3 255.255.255.255 Serial2/0

ip route 6.6.6.6 255.255.255.255 Serial2/1

ip route 7.7.7.7 255.255.255.255 Serial2/2

!

ip as-path access-list 10 permit ^4550_

ip as-path access-list 20 permit ^9500_

ip as-path access-list 30 deny ^9500_

ip as-path access-list 30 permit .*

ip as-path access-list 40 deny ^4550_

ip as-path access-list 40 permit .*

ip as-path access-list 50 permit ^8754_

!

route-map Weight_to_Internet permit 10

match as-path 10

set weight 200

!

route-map Restrict_to_Internet permit 10

match as-path 30

!

route-map Weight_to_client permit 10

match as-path 50

set weight 3000

!

route-map Restrict_to_InterProviders permit 10

match as-path 40

!

route-map Weight_to_InterProviders permit 10

match as-path 20

set weight 2000

!

control-plane

!

line con 0

exec-timeout 0 0

logging synchronous

line aux 0

line vty 0 4

login

!

end

––––––––––––––––––––––

Routerul InterProviders

!

version 12.4

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname InterProviders

!

boot-start-marker

boot-end-marker

!

no aaa new-model

memory-size iomem 5

!

ip cef

no ip domain lookup

!

interface Loopback0

ip address 6.6.6.6 255.255.255.255

!

interface Loopback1

ip address 92.120.1.1 255.255.255.255

!

interface Serial2/0

ip address 50.100.1.1 255.255.255.252

serial restart-delay 0

clock rate 2016000

!

interface Serial2/1

ip address 50.100.2.1 255.255.255.252

serial restart-delay 0

clock rate 2016000

!

router bgp 9500

no synchronization

bgp log-neighbor-changes

redistribute connected

neighbor 4.4.4.4 remote-as 6800

neighbor 4.4.4.4 ebgp-multihop 2

neighbor 4.4.4.4 update-source Loopback0

neighbor 5.5.5.5 remote-as 5700

neighbor 5.5.5.5 ebgp-multihop 2

neighbor 5.5.5.5 update-source Loopback0

no auto-summary

!

no ip http server

no ip http secure-server

ip route 4.4.4.4 255.255.255.255 Serial2/0

ip route 4.4.4.4 255.255.255.255 Serial2/1

ip route 5.5.5.5 255.255.255.255 Serial2/0

!

control-plane

!

line con 0

exec-timeout 0 0

logging synchronous

line aux 0

line vty 0 4

login

!

end

––––––––––––––––––––––

Routerul Internet

!

version 12.4

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname Internet

!

boot-start-marker

boot-end-marker

!

no aaa new-model

memory-size iomem 5

!

ip cef

no ip domain lookup

!

interface Loopback0

ip address 7.7.7.7 255.255.255.255

!

interface Loopback1

ip address 94.120.1.1 255.255.255.255

!

interface Ethernet0/0

ip address 150.200.1.1 255.255.255.252

full-duplex

!

interface Serial2/0

ip address 20.150.2.1 255.255.255.252

serial restart-delay 0

clock rate 2016000

!

interface Serial2/1

ip address 20.150.1.1 255.255.255.252

serial restart-delay 0

clock rate 2016000

!

router bgp 4550

no synchronization

bgp log-neighbor-changes

redistribute connected

neighbor 4.4.4.4 remote-as 6800

neighbor 4.4.4.4 ebgp-multihop 2

neighbor 4.4.4.4 update-source Loopback0

neighbor 4.4.4.4 default-originate

neighbor 4.4.4.4 route-map Weight_to_Provider1 in

neighbor 5.5.5.5 remote-as 5700

neighbor 5.5.5.5 ebgp-multihop 2

neighbor 5.5.5.5 update-source Loopback0

neighbor 5.5.5.5 default-originate

neighbor 5.5.5.5 route-map Weight_to_Provider2 in

neighbor 8.8.8.8 remote-as 7350

neighbor 8.8.8.8 ebgp-multihop 2

neighbor 8.8.8.8 update-source Loopback0

neighbor 8.8.8.8 default-originate

no auto-summary

!

no ip http server

no ip http secure-server

ip route 4.4.4.4 255.255.255.255 Serial2/1

ip route 5.5.5.5 255.255.255.255 Serial2/0

ip route 8.8.8.8 255.255.255.255 Ethernet0/0

!

ip as-path access-list 10 permit ^5700_

ip as-path access-list 20 permit ^6800_

!

route-map Weight_to_Provider1 permit 10

match as-path 20

set weight 2000

!

route-map Weight_to_Provider2 permit 10

match as-path 10

set weight 200

!

control-plane

line con 0

exec-timeout 0 0

logging synchronous

line aux 0

line vty 0 4

login

!

end

––––––––––––––––––––––