In cele mai multe situatii, cand o firma de dimensiuni mici incheie un contract pentru acces la internet cu un ISP, aceasta va achizitiona sau va primi in custodie un echipament (CPE, customer-premises equipment) care se va conecta la un router din reteaua providerului (PE, provider edge router).
De obicei intr-un astfel de scenariu, intre CPE si PE se folosesc foarte rar protocoale de rutare de tip interior gateway, fiind preferata configurarea de rute statice. Cel mai frecvent pe CPE vom regasi o ruta default care sa impinga tot traficul dinspre client spre ISP, iar pe ISP vom gasi rute statice care sa indrepte traficul din internet catre client.
Avantajele folosirii rutelor statice sunt date de usurinta configurarii si lipsa unui overhead suplimentar pe mediu. Viabilitatea solutiei e data de faptul ca de cele mai multe ori topologia nu sufera modificari pe intreaga perioada contractuala.
In articolul de azi voi prezenta problemele care pot sa apara la configurarea rutelor statice intr-o retea de tip broadcast multi-access (incapsulare L2, frame Ethernet).
Cand configuram o ruta statica, putem indica o cale catre o retea de destinatie folosind adresa next-hop a routerului vecin, sau putem specifica interfata de iesire in cazul legaturilor point-to-point, cand traficul care intra printr-un capat are o singura cale de iesire prin celalalt capat.
Cand folosim pentru o ruta de destinatie adresa IP a vecinului, routerul nostru va cauta in tabela de rutare proprie o retea direct conectata din care sa faca parte adresa next-hop pentru a determina interfata de iesire prin care va trimite pachetul. Acest proces se numeste recursive lookup, deoarece dupa ce un pachet a facut match pe o intrare din tabela de rutare, este necesara o consultare suplimentara pentru stabilirea interfetei de iesire.
Configurarea rutelor statice folosind interfata de iesire este recomandata in cazul legaturilor point-to-point (seriale), dar in cazul legaturilor de tip broadcast multi-access (Ethernet) putem intampina o serie de probleme.
Aceste probleme apar din modul in care este realizata adresarea la L2 folosind incapsularea in frame-uri Ethernet. Pentru a trimite un pachet, routerul trebuie sa il incapsuleze intr-un frame Ethernet pentru a-l pune pe mediu, iar frame-ul trebuie sa contina MAC destinatie si MAC sursa (in ordinea aceasta). Cand este folosita interfata de iesire, routerul nu stie ce MAC destinatie sa foloseasca pentru incapsulare si trimite catre vecin un ARP request pentru a rezolva adresa IP destinatie din pachet pe o adresa MAC. Problema e ca vecinul primeste acest ARP request pe un link pe care are deja conectata o alta retea si sfarseste prin aruncarea ARP requestului. Aceasta este o eroare de configurare.
Pentru realizarea conectivitatii cand avem configurata o ruta statica ce foloseste interfata de iesire, avem la dispozitie doua solutii, una mai grozava decat cealalta ;) .O solutie ar fi maparea manuala a adreselor ip destinatie pe adresa MAC a interfetei prin care vecinul se leaga la noi. Aceasta solutie nu scaleaza deoarece este practic imposibil de aplicat in viata reala.
O a doua solutie ar fi folosirea proxy-arp, pentru a realiza maparea in mod dinamic.
Problema atat in cazul maparii manuale cat si in cazul maparii dinamice este utilizarea ridicata a resurselor hardware, deoarece fiecare adresa IP destinatie este introdusa in tabela ARP cu MAC-ul destinatie al interfetei prin care vecinul este legat la noi.
PE-ul a fost configurat.
Acestea fiind zise, sa ne distram ! :)
Topologie (dati click pe imagine pentru a mari)
Scenariul 1
Pe CPE configuram o ruta default folosind interfata de iesire Gigabit 0/0, iar in modul privileged exec (a.k.a. enable sau diez) folosim comanda #debug ip packet si initiem un ping din Lo1 catre 2.2.2.2/32.
Observam ca routerul nu reuseste sa incapsuleze pachetul deoarece nu stie cu ce adresa sa populeze campul MAC destinatie din frame-ul Ethernet. Mai jos am atasat o captura din WireShark in care protocolul ARP incearca sa rezolve adresa MAC pentru adresa IP destinatie.
Acest scenariu reprezinta o eroare de configurare, iar conectivitatea nu se realizeaza.
Scenariul 2
Facem mapari statice ale adreselor IP destinatie pe adresa MAC a interfetei Gigabit 0/0 de pe PE.
Observam ca pingul reuseste doar pentru adresele pentru care am facut mapari. Pentru orice alta destinatie, chiar daca PE-ul are o cale catre ea, pingul nu va reusi.
Scenariul 3
Spre deosebire de maparea statica unde configurarea se face pe CPE, in cazul folosirii proxy-arp este necesara configurarea PE-ului, mai exact a interfetei prin care se conecteaza la CPE (Gigabit 0/0).
Inainte de a configura PE-ul, stergem intrarile manuale configurate pe CPE.
Observam ca pingul reuseste catre toate destinatiile dar avem o problema. Daca folosim comanda de vizualizare a tabelei ARP, observam ca fiecare adresa destinatie este rezolvata individual pe adresa MAC a interfetei Gi 0/0 de pe PE.
In viata reala o astfel de implementare ar duce la popularea tabelei ARP cu sute, chiar mii de intrari. Acest lucru inseamna consum de resurse.
Atat scenariul 2 cat si scenariul 3 nu sunt utilizabile in practica.
Scenariul 4
In practica, in retele de tip broadcast multi-access, cand configuram o adresa statica folosim adresa next-hop a routerului prin care stim ca ajungem la adresa de destinatie.
Pentru a evita recursive lookup, se foloseste o ruta statica fully specified in care specificam atat interfata de iesire cat si adresa next-hop a vecinului.
Inainte de a configura o ruta statica fully specified pe CPE, stergem ruta default configurata anterior si oprim proxy-arp pe PE.
Ceea ce se intampla acum este urmatorul lucru, cand CPE-ul vrea sa trimita un pachet, trimite un ARP request catre PE in care “intreaba” pe ce adresa MAC este mapat IP-ul next-hop. PE-ul raspunde cu un ARP reply in care trimite adresa MAC, iar CPE-ul va utiliza aceasta informatie pentru a realiza incapsularea pachetului intr-un frame Ethernet.
Cam asta e tot pentru laboratorul acesta. Pentru eventuale intrebari sau observatii va rog sa folositi sectiunea de comentarii din josul paginii. Sper ca ati gasit util si interesant acest articol.
In perioada urmatoare urmeaza sa postez mai rar deoarece ma voi pregati pentru sustinerea examenului de modul CCNA4 si a examenului final pentru obtinerea certificarii CCNA R&S. De asemenea se apropie si examenul periodic de certificare interna in cadrul companiei pentru care lucrez, iar ca bonus m-am inscris in competitia NetRiders, sectiunea CCNA.
Daca nu imi bubuie capul, sper sa ma prezint onorabil si sa revin cu vesti bune.
Pana data viitoare, sa avem spor! :)
Niciun comentariu :
Trimiteți un comentariu