Proiect de diploma TELECOMUNICATII - STUDIUL RETELELOR DE INTERCONECTARE VPDN CA SOLUTIE DE BACKUP PENTRU CLIENTII VPN referat






UNIVERSITATEA “POLITEHNICA” BUCURESTI

FACULTATEA DE ELECTRONICA, TELECOMUNICATII SI TEHNOLOGIA INFORMATIEI

CATEDRA TELECOMUNICATII









Proiect de diploma






STUDIUL RETELELOR DE INTERCONECTARE VPDN CA SOLUTIE DE BACKUP PENTRU CLIENTII VPN





UNIVERSITATEA “POLITEHNICA” BUCURESTI

FACULTATEA DE ELECTRONICA, TELECOMUNICATII SI TEHNOLOGIA INFORMATIEI




TEMA PROIECTULUI DE DIPLOMA AL ABSOLVENTULUI



1.Tema proiectului: Studiul retelelor de interconectare Virtual Private Dial-up Network ca solutie de backup pentru clientii VPN.

2. Datele proiectului:

- Conectarea la o retea privata, prin intermediul retelei clasice de telefonie (PSTN) sau ISDN folosita ca solu tie de backup;

3. Probleme care vor fi dezvoltate in proiect:

- Descrierea de baza a unei retele VPN si introducerea acesteia in reteua IP-MPLS;

- Arhitectura retelelor VPDN si modul de conectare a principalelor componente: LAC, LNS;

- Prezentarea principalelor protocoale de tunelare si autentificare folosite: L2TP, L2F, PPP (PAP/CHAP) si modul de functionare a acestora;

- Simularea unei conexiuni VPDN in cazul pierderii legaturii prin linkul principal ;

- Activarea linkului ISDN, verificarea activarii tunelului VPDN si a conectivitatii ip cu o locatie distanta;

4. Material grafic:

- Arhitectura retelei propuse cu echipamentele implicate in realizarea conexiunii prin VPDN, proiect in Microsoft VISIO.

5. Data elaborarii temei:

Capitolul 1.VPN



1.1 Retele private virtuale


1.1.1 Notiuni generale


In fiecare zi prin Internet se schimba modul in care comunicam, ne informam si modul in care se realizeaza afacerile.

Succesul Internetului a schimbat definitiv modul in care firmele construiesc si utilizeaza retelele de mare suprafata bazate pe IP. Aceste retele au evoluat in intraneturi, extraneturi, chiar retele particulare virtuale. Semnificatia acestor retele nu se reduce la simpla schimbare de nume. Ele permit proceselor de afaceri sa evolueze. O companie care poate gestiona evolutia cu succes a proceselor sale de afaceri are potentialul pentru imbunatatiri substantiale in ceea ce priveste postura sa competitionala. Cheia acestui succes este intelegerea posibilitatilor si limitarilor fiecarei tehnologii. Aceasta cunoastere ar trebui sa asigure contextul pentru aplicarea fiecarei tehnologii de retea. In mod ideal, tehnologiile de lucru in retea pot fi utilizate pentru a crea noi oportunitati, fara a expune compania la riscuri inutile.

Pe termen lung, diferentele dintre Internet, intraneturi si extraneturi vor fi probabil aproape elimi­nate prin avansul tehnologic. Imbunatatirile aduse autentificarii la nivel retea, certificarii si (intr-o mai mica masura) criptarii vor furniza probabil companiilor posibilitatea de a moderniza parafocurile si alte perimetre fizice de aparare din jurul WAN-urilor lor. In locul acestora vor fi intraneturi si extraneturi detaliate logic. Cand se va ajunge la acest lucru, ne vom intoarce de unde am plecat. Diversele retele vor fi reintegrate intr-o retea unica, omniprezenta, cu subdiviziuni logice nu fizice. Aceste structuri logice sunt cunoscute ca retele particulare virtuale (VPN - virtual private network).

Conectarea prin retea privata virtuala este o noua tehnica pentru retelele de mare suprafata. VPN constituie un nou tip de sistem de acces pentru utilizatorii care se conecteaza telefonic de la mare distanta. Sistemele tip VPN permit utilizatorilor aflati la distanta sa se conecteze la reteaua lor prin intermediul Internetului. Aceasta se face prin crearea unui circuit ,,virtual' de la calculator la reteaua firmei; adica legatura respectiva le apare privata celorlalti utilizatori, chiar daca trece prin sistemul public al Internetului. Toate datele si informatiile care circula prin conexiune sunt codificate - cifrate -,-astfel incat nimeni altcineva sa nu le poata citi.



1.1.2 Tehnologii VPN


Retelele private virtuale folosesc Internetul pentru a conecta mai multe retele LAN intre ele, printr-o conexiune sigura. Conexiunile VPN realizeaza acest lucru cu doua tehnologii importante: crearea de tunele si criptarea. Mai intai, o retea VPN creeaza un circuit ,,virtual' intre cele doua puncte conectate, prin intermediul Internetului. Apoi, foloseste metoda crearii de tunele pentru a infasura datele in protocolul (limbajul) Internetului - TCP/IP - astfel incat sa poata fi transportate cu usurinta. Prin criptare se codifica informatia trimisa, astfel incat numai destinatarul careia i se adreseaza s-o poata decodifica si citi.

Trecerea prin tunel (tunneling) este procesul prin care au loc comunicatiile in cadrul limitelor unei structuri logice stabilite de un alt protocol de comunicatii. Aceasta poate rezolva diferite probleme ale retelei, de la nevoia de asigurare a securitatii datelor in tranzit, la depasirea incompatibilitatilor cu oricare dintre protocoalele sau schemele de adresare externe. Indiferent ce protocol este utilizat sau care este rolul tunelului, tehnica de baza ramane relativ aceeasi. In mod obisnuit, este utilizat un protocol pentru stabilirea conectivitatii cu o destinatie aflata la distanta si altul pentru incapsularea datelor si instructiunilor pentru transmisia prin tunel.

Un exemplu de utilizare a unui tunel pentru depasirea incompatibilitatilor dintre protocoale dar si dintre schemele de adresare, se gaseste in suita de instrumente Simple Internet Transition (SIT), care acompaniaza versiunea IPv6. Un instrument furnizat de Internet Engineering Task Force (IETF) pentru a facilita migrarea de la versiunea Internet Protocol 4 (IPv4) la versiunea 6 (IPv6) este o tehnica de trecere prin tunel. Aceste versiuni sunt suficient de diferite pentru a face imposibila interoperabilitatea directa. Interoperabilitatea este simulata aplicand trecerea prin tunel a IPv4 prin IPv6 si invers.

De asemenea, trecerea prin tunel asigura securitatea datelor la traversarea domeniilor nesigure prin furnizarea unui invelis, sau ambalaj protector. Un protocol de trecere prin tunel proiectat exclusiv in acest scop este Point-to-Point Tunneling Protocol.



Elemente componente ale VPN


Structura unei retele virtuale private este cea prezentata in figura urmatoare:

 















Componenta Dial-in. In conditiile actuale accesul de la distanta a devenit o necesitate, angajatii care lucreaza acasa, cat si cei aflati in deplasare (utilizatori de la distanta) doresc acces dial-in sigur si convenabil la reteaua companiei lor, iar uneori trebuie chiar sa comunice cu alte host-uri din cadrul retelei altei companii. Aceasta componenta se extinde de la calculatorul utilizatorului de la distanta la un punct oferit de un ISP. Protocoalele folosite difera in functie de ISP; se observa o orientare din ce in ce mai puternica a acestora catre protocolul PPP (Point-to-Point Protocol).

Reteaua externa (Internet). Internet-ul a devenit un backbone folosit din ce in ce mai des pentru interconectarea intranet-urilor.

Reteaua interna (Intranet). Se afla sub controlul companiei.

Structura unei retele virtuale private include mai multe clase de sisteme ca host-uri la distanta (conectare de tip dial-in); host-uri locale (statii de lucru si servere); puncte de acces ISP; firewall-uri, router-e, sau gateway-uri.



1.2.1. Implementare VPN


Pentru implementarea unui VPN sunt necesare: un firewall, un router, un server proxy, hardware si software VPN sau toate, oricare dintre acestea pot asigura o comunicatie sigura, dar o combinatie a lor este solutia cea mai buna.

Implementarile VPN-urilor se grupeaza in trei categorii:

intranet – reteaua virtuala privata intre sediile si departamentele aceleiasi firme

remote-acces VPN – retea virtuala privata intre reteaua firmei si angajatii aflati la distanta sau in deplasare

extranet VPN – reteaua virtuala privata intre o firma si parteneri strategici, clienti furnizori.







Intranet



Intranet-ul este definit ca o legatura semi-permanenta peste o retea publica intre un WAN si o filiala a companiei. Aceste tipuri de conexiuni LAN-LAN se presupune ca au cel mai mic risc din punct de vedere al securitatii pentru ca firmele au incredere in filialele lor. In astfel de cazuri compania are control asupra retelei/nodurilor destinatie cat si asupra celei sursa. Administratorii de sistem trebuie sa decida daca aceasta situatie este intalnita si in propria firma.


Cazul general


In situatia in care ambele capete ale canalului de comunicatie sunt de incredere, compania poate adopta o solutie VPN care se axeaza mai degraba pe performanta decat pe securitate care este limitata la puterea metodelor de criptare si autentificare intre cele doua routere. Cantitati mari de date sunt schimbate frecvent intre LAN-uri intr-o retea privata, deci importanta este viteza de transmisie si interoperabilitatea. LAN-urile care sunt conectate prin intermediul unor baze de date centralizate sau prin alte resurse de calcul raspandite in reteaua firmei ar trebui sa fie considerate ca facand parte din aceeasi retea.

 



Intranet VPN tipic, unde tunele bidirectionale si criptate sunt stabilite intre LAN-uri de incredere peste Internet

Cazul de securitate maxima

Amenintarile la securitate vin adesea din interiorul firmei. Dintr-un studiu efectuat de FBI si Computer Security Institute reiese ca aproape jumatate din accesul neautorizat in reteaua firmei vine din interiorul acesteia. Daca firma este ingrijorata de posibilitatea scurgerii de informatii prin intermediul angajatilor, fie intentionat sau nu, sau daca aplica diferite niveluri de incredere in functie de departament sau chiar persoane, atunci ar trebui sa investeasca intr-o solutie VPN care ofera un control asupra traficului de informatie pe baza unui sistem de autentificare si a unei politici de securitate la nivel utilizator decat pe baza increderii acordate retelei in sine.

 








Intranet VPN de mare securitate unde numai anumiti utilizatori din filiale au acces la resursele firmei si fiecare are diferite drepturi. Toate datele transferate peste Internet sunt complet criptate si autentificate pana la punctul de destinatie, nu numai in cadrul retelei.


Remote acces



Companiile abia incep sa inteleaga avantajele pe care le ofera Internetul fata de traditionalul acces la distanta prin dial-up. Multe firme, obosite de efortul de a intretine multimea de modemuri si de costurile asociate liniilor inchiriate, descopera ca Internetul, ca mediu de comunicatie la distanta, este mult mai ieftin si mai simplu de implementat si intretinut decat solutiile obisnuite.

In oricare dintre scenariile de acces la distanta prin VPN, usurinta in utilizare este un criteriu important. Majoritatea breselor de securitate sunt atribuite erorilor de configurare, deci cu cat sistemul este mai usor de administrat, cu atat sansele de a scapa ceva din vedere sunt mai mici. Din punctul de vedere al clientului, simplitatea este critica, pentru ca multi angajati aflati in deplasari sau la distanta nu au cunostintele necesare sau accesul la resursele tehnice pentru a depista si rectifica cauzele unor eventuale disfunctionalitati. Clientii nu trebuie sa construiasca un tunel VPN manual, manual insemnand sa lanseze software-ul de VPN de fiecare data cand vor sa stabileasca un canal de comunicatie sigur. Software-ul de VPN ar trebui sa se lanseze automat, la start-up, si sa ruleze in background. Pe de alta parte, o administrare usoara si centralizata este esentiala pentru ca monitorizarea unui numar mare de utilizatori, adaugarea si excluderea utilizatorilor in mod regulat poate duce la un haos si la riscuri in privinta securitatii.


Cazul General


In cazul majoritatii VPN-urilor cu acces la distanta se presupune ca firma are incredere in persoana aflata in celalalt capat al legaturii, care in mod obisnuit este un agent de vanzari aflat in deplasare sau la distanta. Decat sa isi faca probleme ca angajatii ar putea sa strice reteaua in vreun fel sau sa sustraga informatii confidentiale, compania este mai degraba interesata sa nu apara probleme neidentificate intre punctele de comunicatie. Aceste companii vor adopta o politica de acces transparenta, de genul: 'Angajatii de la distanta trebuie sa aiba acces la toate resursele la care ar avea acces daca ar fi intr-un birou la sediul firmei.'

Din aceste motive, prioritatea este criptarea datelor transmise astfel incat numai cel caruia ii sunt adresate sa le poata decripta. Majoritatea VPN-urilor indeplinesc majoritatea cerintelor de securitate, asa ca cel care evalueaza diferitele oferte trebuie sa ia in considerare alte criterii, cum ar fi: 'taria' mecanismului de criptare si autentificare pentru o securitate suplimentara.

 

















VPN tipic cu acces la distanta, unde utilizatorul se logheaza la Internet prin intermediul unui ISP si stabileste un tunel criptat intre calculatorul lui si reteaua companiei; identitatea utilizatorului este necunoscuta, fiind accesibila doar adresa IP a calculatorului.


Cazul de securitate maxima


Domeniile care trebuie sa excluda orice risc de securitate, cum ar fi cele financiar, sanatate, sectoare guvernamentale, sunt paradoxal cele care au adoptat cel mai repede tehnologia VPN, care este perceputa ca fiind mai putin sigura decat metodele clasice de transmisie prin retea. In realitate, tehnologiile VPN sunt mult mai sigure decat liniile inchiriate sau accesul la distanta prin dial-up, deoarece VPN-urile de mare securitate cripteaza toate datele si ofera drepturi foarte specifice de acces.

Solutiile de acces in siguranta de la distanta sunt implementate de specialisti IT care inteleg pe deplin riscurile inerente ce apar in comunicatia prin retea. Politica adoptata este: 'Angajatii de la distanta trebuie sa aiba un acces foarte bine supravegheat/controlat, la anumite resurse, in concordanta cu cerintele functiei pe care o ocupa.'

Companiile implementeaza VPN-uri pentru a le oferi un acces la distanta in deplina siguranta peste reteaua publica. VPN-urile axate pe securitate autentifica utilizatorii, nu numai adresele IP, astfel incat firma sa stie exact ce angajat incearca sa acceseze reteaua. Aceasta poate fi realizata cu ajutorul parolelor, certificatelor digitale, token card-uri, smart card-uri, sau chiar amprente sau scanarea retinei. Odata autentificat pentru accesul la serverul VPN al firmei, angajatului i se garanteaza diferite niveluri de acces in functie de profile-ul asociat, profile ce este instalat de administratorul de retea pentru a fi in concordanta cu politica de securitate a companiei. Acest sistem este esential pentru companiile ce permit accesul la informatii critice, in special in cazul in care angajatilor nu li se acorda deplina incredere.



VPN de mare securitate cu acces la distanta unde utilizatorii sunt identificati printr-o metoda de autentificare dupa care le este permis sau respins accesul la resursele cerute sau la reteaua firmei. Toate datele sunt criptate intre capetele tunelului de comunicatie.

De fiecare data cand firma vrea sa acorde diferite niveluri de acces astfel incat diferite resurse sa fie disponibile diferitilor angajati cand este nevoie sau cand vrea sa previna accesul pe 'usa din dos' in retea, ceea ce se intampla in cazul unor sisteme, recomandata este solutia unui VPN cat mai robust. Un VPN de mare securitate trebuie sa poata intercepta traficul din retea destinat unui anume calculator, sa adauge criptarea necesara, sa identifice utilizatorul si sa aplice restrictiile si filtrarea continutului datelor in consecinta.




Extranet



Spre deosebire de Intranet, care este relativ izolat, Extranetul este destinat comunicarii cu partenerii, clientii, furnizorii si cu angajatii la distanta. Securizarea unei retele de dimensiuni mari necesita indrumari si instrumente adecvate. Un extranet VPN trebuie sa ofere o ierarhie a securitatii si accesarea datelor confidentiale sa se faca sub cel mai strict control. Trebuie sa protejeze toate aplicatiile, inclusiv cele ce folosesc TCP si UDP, cum ar fi RealAudio, FTP, etc.; aplicatii de firma, ca SAP, BAAN, PeopleSoft, Oracle, etc.; si aplicatii dezvoltate in cadrul firmei in Java, Active X, Visual Basic, etc. Deoarece majoritatea retelelor firmelor sunt eterogene si cu numeroase sisteme mai vechi, o solutie VPN trebuie sa fie cat mai versatila si sa interopereze cu multitudinea de platforme, protocoale si metode de autentificare si criptare, si sa fie una bazata pe standardele acceptate pentru a putea colabora cu solutiile VPN ale partenerilor.


Cazul General / Cazul de mare securitate


Principalul obiectiv al unui Extranet sau al VPN-ului intre companii este sa se asigure ca datele secrete ajung intacte si exact cui ii sunt adresate fara a exista riscul de a expune resursele protejate unor eventuale amenintari, asa ca firmele ar trebui sa ia in considerare cele mai avansate solutii de VPN.

Elementele de securitate dintr-un VPN pot fi ierarhizate in diferite moduri, dar in cazul unui Extranet VPN, toate aceste componente – criptare, autentificare si controlul accesului – trebuie sa fie strans integrate intr-un perimetru de securitate. Aceasta inseamna in mod uzual situarea unui server VPN in spatele unui Firewall impenetrabil care blocheaza tot traficul neautentificat. Orice trafic care este autorizat este transmis direct serverului VPN care face filtrarea continutului in conformitate cu politica de securitate a firmei. Este esential ca legatura intre firewall si VPN sa fie sigura si fiabila, iar software-ul client sa fie cat mai transparent posibil.

Afacerile online sau comertul electronic nu se rezuma numai la tranzactii cu carti de credit; presupune de asemenea negocieri complexe si colaborari la diferite proiecte. Cand informatii vitale si confidentiale sunt implicate, administratorii IS nu pot risca compromiterea nici unei parti din retea. Un Extranet VPN trebuie sa foloseasca cea mai buna criptare posibila, care acum este pe 128 de biti. In plus, VPN-ul trebuie sa suporte diferite metode de autentificare si criptare pentru a putea comunica cu partenerii, furnizorii sau clientii, care au foarte probabil diferite platforme si infrastructuri.

Un Extranet VPN sigur, in care o companie imparte informatii cu clientii, partenerii, furnizorii si angajatii aflati la distanta prin intermediul retelei publice stabilind legaturi unidirectionale de la un capat la altul printr-un server VPN. Acest tip de sistem permite unui administrator de retea sa defineasca drepturi specifice, cum ar fi cele ce ar permite unui membru din conducerea unei firme partenere sa acceseze diferite/anumite rapoarte de vanzari de pe un server protejat. Acest tip de acces nu este posibil cu orice tip de solutie VPN.

Intr-o situatie reala de interconectare intre parteneri de afaceri, administratorii trebuie sa caute o solutie de VPN care sa filtreze accesul la resurse in functie de cat mai multi parametrii posibili, inclusiv sursa, destinatia, utilizarea aplicatiei, tipul de criptare si autentificare folosit, si identitatile individuale si de grup. Managerii de sistem trebuie sa identifice utilizatorii individual, nu numai adresele IP, fie prin parole, token card, smart card, sau orice alta metode de autentificare. Parolele sunt de obicei suficiente pentru o aplicatie obisnuita de birou, dar nu sunt la fel de sigure precum token-urile sau smart card-urile. Angajatii sunt adesea neglijenti cu parolele lor, si rareori isi schimba codurile in timp ce token-ul si smart card-urile isi schimba parolele in mod regulat, adesea chiar si la 60 de secunde.




 
















Odata autentificat, administratorul trebuie sa poata ruta traficul autorizat la resursele protejate fara sa pericliteze securitatea retelei. Controlul accesului este cel care face diferenta intre diferitele solutii de VPN. Fara a avea un control asupra cui cere accesul la fiecare resursa din retea, VPN-ul este inutilizabil in afara perimetrului de securitate al retelei. Odata autentificat, un utilizator nu trebuie sa aiba acces total la retea. Trebuie adoptate drepturi speciale pentru fiecare utilizator astfel incat sa se obtina un control cat mai bun asupra tuturor resurselor.

Securitatea trebuie intarita, nu slabita pe masura ce utilizatorul primeste accesul la zone mai sensibile. Folosind o criptare, autentificare si metode de control al accesului cat mai bune, companiile isi pot proteja retelele de orice brese de securitate.




1.2.2 Echipamentul folosit pentru retelele de calculatoare




Ruterele se utilizeaza pentru retele WAN cu linii analogice, linii ISDN, linii inchiriate sau releu de cadre. Ruterele sunt importante pentru o retea de mare suprafata, fiindca utilizeaza adrese de retea si expediaza ,,pachete' de informatii pe baza locului de destinatie. Prin urmare, un router nu va trimite informatii in reteaua WAN decat atunci cand sunt destinate cuiva aflat in alta parte. Iata un atribut util, fiindca nu tot ce se afla in reteaua dumneavoastra LAN poate sa treaca prin acea conexiune WAN de capacitate mica, deci routerul limiteaza traficul doar la ceea ce este necesar.

Ruterele se conecteaza direct la reteaua dumneavoastra, iar la celalalt capat au conexiuni pentru tehnologia de comunicare pe care o utilizeaza. Daca utilizeaza tehnologie analogica sau ISDN, conexiunea este adesea incorporata. Daca se foloseste sistemul cu releu de cadre sau o linie inchiriata, se conecteaza in cealalta parte un dispozitiv DSU/CSU (vezi mai jos descrierea), ca sa faca legatura de la router la reteaua de mare suprafata. O alta varianta ar fi conectarea a doua servere care au echipamentul necesar si software de router instalat pe ele.

FRAD Un asamblor/dezasamblor de releu de cadre (Frame Relay Assembler/Disassembler - FRAD) este un dispozitiv care poate fi utilizat in locul unui router pentru conectare la un sistem cu releu de cadre, printr-un dispozitiv DSU/CSU. Dispozitivele FRAD iau datele care vin din segmentul local si le formateaza pentru a putea circula prin conexiunea in sistemul cu releu de cadre. Un dispozitiv FRAD cu mai multe porturi va conecta mai multe dispozitive la un DSU/CSU.

OSSl/CSU Acest dispozitiv detine primul loc in concursul pentru cel mai lung acronim. DSU/CSU e prescurtarea de la Digital Service Unit/Channel Service Unit -Unitate de serviciu digital/unitate de serviciu de canal. Deloc surprinzator, i se spune adesea si CSU/DSU. Un dispozitiv DSU/CSU conecteaza routerul sau FRAD-ul la linia WAN, aproape la fel ca un modem, cu exceptia faptului ca este un dispozitiv de tip digital.



Avantajul utilizarii sistemului VPN



1.3.1 Reducerea cheltuielilor



Principalul avantaj al utilizarii unui sistem VPN pentru accesul de la distanta este unul de cost: se economisesc bani cu apelurile telefonice de la mare distanta. Dar, precum se vede in figura urmatoare, prin utilizarea unei conexiuni VPN, cei trei reprezentanti de vanzari se pot conecta la reteaua firmei prin Internet, avand astfel o legatura sigura si dispensandu-se de tarifele interurbane. Daca au calculatoarele configurate corespunzator, nu trebuie decat sa se conecteze la Internet.

Conectarea cu acces de la distanta printr-un apel telefonic local, pentru a intra in reteaua companiei lor. Toate datele sunt apoi expediate, in conditii de securitate, intre calculatoarele lor si retea, prin intermediul Internetului.

Accesul de la distanta in sistem VPN impune ca reteaua firmei sa fie conectata direct la Internet. Pentru aceasta este nevoie de un router sau de un server, care sa se conecteze la Internet si sa ruleze software de VPN. De asemenea, este nevoie si de securitate suplimentara pentru retea, sub forma unui ,,parafoc' (,,firewall', bariera de protectie) intre retea si Internet, care sa impiedice patrunderea unor utilizatori nepoftiti de pe Internet. In plus, este nevoie ca fiecare calculator sa poata rula protocoale VPN, cum ar fi Point-to-Point Tunneling Protocol (PPTP) de la Microsoft. Fireste, fiecare utilizator de la distanta trebuie totodata sa aiba acces la Internet, indiferent unde s-ar afla. Accesul de la distanta in sistem VPN nu a depasit inca faza incipienta, dar in viitor va deveni o solutie foarte importanta, pentru intreprinderi de toate marimile.


Acces de la distanta in sistem VPN.

 















1.3.2 Posibilitatea conectarii la distanta



Accesul de la distanta ofera toate avantajele posibilitatii de a-i conecta la reteaua locala de calculatoare pe angajatii care lucreaza, in parte sau in totalitate, in afara firmei - adica imbunatatirea comunicatiilor, a productivitatii si a partajarii resurselor. Ceea ce nu pot sa deschida sau sa utilizeze in retea este, de obicei, o chestiune de limita de viteza a conexiunii lor telefonice cu reteaua. Este o solutie esentiala pentru a tine legatura cu angajatii care calatoresc.

Utilizarea accesului de la distanta pentru telecomutare poate de asemenea sa aduca beneficii suplimentare. Daca unii angajati lucreaza cea mai mare parte din timp In alt loc decat la birou, firma poate sa economiseasca bani pe seama costurilor de intretinere a unui birou pentru ei. Multe companii au constatat ca, permitand unor angajati sa lucreze acasa, isi imbunatatesc productivitatea. Acest fapt este adesea atribuit numarului mai mic de intreruperi, distrageri si sedinte sau intalniri. In plus telecomutistii lucreaza adesea pana mai tarziu decat ceilalti angajati, folosind timpul pe care nu-l mai consuma cu naveta ca sa realizeze mai multe. Dar rezultatele difera de la persoana la persoana si de la firma la firma, asa ca e mai bine sa incepeti cu o perioada de proba si sa judecati singuri rezultatele experimentului. In plus, telecomutarea poate fi un avantaj si atunci cand incercati sa angajati si sa pastrati niste angajati buni, care ar putea-o considera o facilitate oferita pe langa salariu.




Cheltuielile cu impulsurile telefonice



Daca aveti de gand sa utilizati accesul de la distanta pentru a-i mentine conectati pe angajatii care calatoresc, luati masurile necesare pentru a preveni cresterea exponentiala a cheltuielilor telefonice. Multi utilizatori de la distanta devin absorbiti de ceea ce fac sau de cititul e-mailurilor si uita de cata vreme stau conectati la o linie interurbana. Dat fiind ca majoritatea utilizatorilor mobili se vor conecta dintr-o camera de hotel conectarea pe aceasta cale poate deveni foarte costisitoare. Doua modalitati de ocolire a acestei probleme ar fi inregistrarea impulsurilor interurbane pe o cartela telefonica de firma sau obtinerea unui numar cu taxa inversa la sediul firmei dumneavoastra, la care sa sune cei in cauza. De asemenea, dat fiind ca citirea on-line (adica in timp ce sunteti conectat) a e-mailurilor reprezinta una dintre cele mai raspandite metode de omorat timpul, alegeti o aplicatie pentru e-mail care permite utilizatorilor sa se conecteze si sa descarce toate mesajele e-mail, iar apoi sa le citeasca dupa ce s-au deconectat. In fine, o solutie de acces de la distanta in sistem VPN poate si ea sa aduca economii in materie de costuri cu impulsurile telefonice prin aceea ca utilizeaza Internetul.



1.3.4 Reducerea costurilor cu echipamentul



Costurile cu echipamentul pot sa depaseasca nivelul la care v-ati astepta in mod normal. Spre exemplu, daca aveti angajati care lucreaza acasa, ce calculator utilizeaza: unul in proprietate personala sau unul cumparat de firma? Trebuie sa hotarati daca si ce echipament le veti pune la dispozitie pentru utilizare acasa, inclusiv mobilier de birou, aparate fax, imprimante si linii analogice in ISDN. Majoritatea firmelor mici constata ca este prea costisitor sa le asigure angajatilor toate dotarile necesare pentru organizarea unui birou la domiciliu, cu exceptia cazului in care angajatul isi petrece majoritatea timpului muncind acasa.







Securitatea



Chiar daca accesul de la distanta poate ajuta o firma sa-si extinda reteaua, sa sporeasca productivitatea angajatilor si sa amelioreze comunicatiile, exista unele probleme legate de instalarea unei solutii de acces de la distanta. Accesul de la distanta poate afecta multe dintre sectoarele companiei dumneavoastra, de la securitatea retelei si pana la cel de resurse umane si conducere.

Pe langa problemele de securitate existente in retelele traditionale ale corporatiei vin unele noi. Astfel, intre doua puncte ale unei retele virtuale private se pot afla:

- Calculatoare sau componente de comunicatie care nu sunt sub controlul companiei: puncte de acces ISP in componenta dial-in, router-ele din Internet;

- Un segment intern (Intranet), care contine host-uri si router-e, dintre care unele pot avea intentii rau voitoare.

- Un segment extern (Internet), prin care se transmit date nu numai intre retelele companiei, ci si intre alte surse.

In acest mediu eterogen exista multe posibilitati de a asculta traficul, de a schimba continutul mesajelor, de a modifica destinatia unui mesaj sau a intreprinde alte tipuri de atacuri pasive sau active. In segmentul dial-in se realizeaza traficul dintre utilizator si ISP. Daca nu sunt criptate este foarte usor pentru un atacator care are acces la legatura dial-in (de exemplu la liniile telefonice) sa examineze datele confidentiale. Criptarea la nivelul legaturii intre utilizator si ISP ofera protectie numai impotriva atacatorilor externi, nu si fata de ISP. Alte probleme asemanatoare care necesita masuri de protectie pot aparea in orice componenta a retelei virtuale private.

Una din solutiile viabile privind implementarea unei retele VPN este si folosirea protocoalelor IPSec, care ofera atat protectie end-to-end, cat si la nivel de segment VPN.


Interconectarea mai multor filiale (oficii) ale aceleiasi companii

 

















Daca intranet-urile companiei sunt considerate de incredere si sigure, calculatoarele client nu necesita suport IPSec, decat pentru firewall-urile care realizeaza comunicare intre intranet-uri, folosind tuneluri IP. De asemenea, nu este necesara nici un fel de modificare la nivelul router-elor Internet.

Firewall-urile VPN situate la perimetrul fiecarei filiale vor folosi IPSec atat pentru autentificarea, cat si pentru criptarea traficului. Orice trafic care soseste la firewall si nu este autentificat de firewall-ul VPN nu va fi livrat in interiorul Intranetului. Autentificarea se va face folosind ESP.

Mesajele de control al rutarii, schimbate intre firewall-urile VPN, vor fi, de asemenea, criptate si autentificate utilizand IPSec. Daca numarul de firewall-uri VPN este mic, managementul cheilor se poate face manual. O data cu cresterea marimii retelei virtuale, se impune adoptarea unui management automat (ISAKMP).

Adresele IP din Intranet pot fi folosite dependent sau independent de existenta corespondentului pe Internet (in segmentul extern). Numai subretelele unui firewall VPN care acceseaza Internet-ul necesita adrese IP unice global.


Interconectarea mai multor companii

 

















Acest tip de VPN foloseste Internet-ul pentru a conecta mai multe companii intre care exista trafic sporit, caruia trebuie sa i se asigure confidentialitatea. O asemenea abordare poate fi utila pentru a securiza, de exemplu, comunicatia dintre o companie si principalii ei parteneri de afaceri. Pentru a se putea implementa IPSec, trebuie avute in vedere urmatoarele:

Clientii trebuie sa suporte protocolul ESP atat pentru criptare, cat si pentru autentificare;

Creste numarul de sisteme de calcul care folosesc IPSec. Vor fi stabilite 'asociatii de securitate', atat pentru configuratii end-to-end, cat si firewall-to-firewall. Pentru configuratii mici, managementul cheilor se poate face manual, dar, o data cu cresterea configuratiei, trebuie adoptat managementul automat ISAKMP.



1.5 CONCLUZII



Un VPN este un concept, nu un produs. VPN-urile au fost utilizate extensiv multi ani, atat in retelele locale, cat si in cele de date, si ele continua sa se bucure de succes in ambele zone. Motivul este simplu: numeroase companii considera costurile construirii si operarii retelelor de comunicatii particulare ca fiind prohibitive. In loc sa construiasca astfel de retele sau sa isi refuze aceasta functionalitate, ele cauta un furnizor care le poate vinde serviciul respectiv. Interesul recent pentru VPN-uri este generat de Internet. Numeroase companii, in special furnizorii de servicii Internet (ISP - Internet Service Provider) si companiile care asigura coloa­na principala a Internetului, sunt nerabdatoare sa creasca cererea pentru conectivitatea si utilizarea Internetului. Oricat de curios ar suna, cererea exploziva de conectivitate Internet s-a stabilizat de fapt. Prin urmare, ISP-urile se vad blocate in competitia pentru o piata care considera serviciile lor un bun de larg consum.

Una dintre tacticile de a creste cererea este gasirea de noi modalitati de utilizare a Internetului. Amintindu-si ca adevaratii bani se afla in fondurile companiilor (nu ale utilizatorilor individuali, furnizorii incearca sa gaseasca mai multe cai de a creste cererea corporatiilor pentru conectarea la Internet. Utilizarea Internetului ca retea particulara virtuala este o solutie.

Internetul poate fi utilizat ca VPN intr-unul din doua moduri. Mai intai, lucratorii de la distanta pot accesa resursele intranetului corporatiei formand numarul ISP-ului local si calatorind prin Internet catre intranetul lor. Aceasta scuteste corporatia de a oferi suport unor rezerve de modemuri apelabile, dar creste numarul problemelor de securitate.

A doua abordare este eliminarea aproape integrala a intranetului in favoarea unei retele particulare virtuale in cadrul Internetului. Aceasta abordare ramane pana in momentul de fata o solutie mai mult teoretica decat practica.

Avantajele oricarei abordari este reducerea costurilor detinerii, operarii si intretinerii retelelor de comunicatii.

























Capitolul 2.Retele VPN bazate pe MPLS




2.1 Conceptul MPLS (MultiProtocol Label Switching)



Defineste o noua paradigma de comutare de nivel 2 (legatura de date) si nivel 3 (retea) denumita comutarea cu etichete (mecanism de incapsulare de “nivel 2.5”).MPLS aduce in retelele IP neorientate pe conexiune mecanismul de comutare orientat pe conexiune care sa constituie baza contractelor de garantare a serviciilor.

Etichetele MPLS sunt rezolvarea : spun unui echipament de retea (ruter, switch) unde sa trimita pachetul si cum sa trimita pachetul. Eticheta MPLS : identificator de dimensiune fixa (20 biti), are semnificatie locala (la nivelul unui nod de retea) ; un pachet poate fi marcat cu mai multe etichete (stiva etichetelor – stiva de tip last-in first out); deoarece in cazul retelelor de tip Ethernet nu exista un cimp liber unde sa poata fi introdus discret antetul MPLS, s-a gasit solutia introducerii antetului MPLS intre headerul de nivel legatura de date si headerul de nivel retea.

Clase de echivalenta : subset de pachete care sunt comutate in acceasi maniera ; cind un pachet intra intr-un domeniu de retea MPLS, nodul de intrare ii mapeaza o clasa de echivalenta in functie de prefixul adresei IP, identificatorul ruterului de iesire, flux (perechea adresa sursa- adresa destinatie)

O retea MPLS e alcatuita din noduri capabile de comutare pachete pe baza etichetelor asignate ; tipuri de noduri : ingress (de intrare) – pe unde intra traficul in retea, tranzit – in interiorul retelei (max 253), egress (de iesire) – pe unde iese traficul din retea.

Nodurile ingress si egress : rutere sau switchuri; ingress- analizeaza pachetele IP, stabilesc clasa de echivalenta si asigneaza o eticheta, egress – sterge eticheta, in cazul in care nu a fost stearsa de penultimul ruter din cale si ruteaza pachetul spre destinatie pe baza informatiei oferite de adresa IP destinatie din headerul IP.

Nodurile tranzit: rutere sau switchuri cu Tag Switch Controller; efectueaza operatii de interschimbare a etichetei si transmit pachetul urmatorului nod din cale.

LSP (Label Switched Path) : calea unidirectionala din retea pe care o urmeaza un pachet; poate sa nu fie calea cea mai scurta

Penultimate/ultimate hop pooping: eticheta este stearsa in penultimul/ultimul nod.

Operatii MPLS:

se utilizeaza un protocol de rutare (OSPF, EIGRP, IS-IS) pentru determinarea topologiei domeniului de retea

se utilizeaza un protocol de semnalizare (RSVP, LDP) pentru asignarea si distributia etichetelor

un pachet soseste la nodul ingress, este analizat si i se ataseaza o eticheta ;fiecare nod tranzit receptioneaza un pachet si efectueaza o cautare in tabela de comutare si o operatie de interschimbare a etichetelor. Penultimul nod din cale receptioneaza un pachet si efectueaza o cautare in tabela de comutare. Deoarece nodul egress a semnalizat eticheta 3, penultimul ruter sterge eticheta superioara si transmite pachetul. Daca nodul egress nu a semnalizat pachet cu eticheta 3 atunci nodul penultim transmite pachetul fara sa-i stearga eticheta. Nodul egress primeste un pachet IP nativ (in cazul penultimate hop popping) si executa : o cautare normala in tabela de rutare, transmisia catre ruterul care e indicat ca next hop.

Protocoale de semnalizare: RSPV (Resource Reservation Protocol), LDP (Label Distribution Protocol), CR-LDP (Constrained Routing LDP)



2.2 De ce VPN bazate pe tehnologia MPLS?



Retea virtuala privata : servicii private de retea utilizind o infrastructura publica

(infrastructura unui Service Provider).

retea virtuala : retelele par a fi separate la nivel fizic, dar de fapt nu sint deoarece se utilizeaza aceeasi infrastructura;

retea privata: fiecare retea VPN mentine tabele de rutare si adresare diferite.

Retelele VPN pot fi construite la nivel 2 (legatura de date) – model overlay, la nivel 3 (nivel retea) – model peer.

Tipuri de retele VPN :

traditionale : Frame Relay, ATM (nivel 2)

utilizator : L2TP si PPTP (nivel 2), IPSec (nivel 3)

provider : bazate pe MPLS (nivel 2), BGP/MPLS VPN (nivel 3)

Modelele de retele VPN :

overlay

peer

Modelul overlay (VPN de nivel 2)

construiesc trunchiuri private peste o infrastructura publica : linii inchiriate/ dial-up, circuite Frame Relay/ATM, tunele IP

o modalitate de realizare VPN prin utilizarea unui protocol de nivel legatura de date orientat pe conexiune (ATM, Frame Relay)

fiecare site e conectat la reteaua providerului prin unul sau mai multe circuite virtuale

circuitele virtuale sunt comutate in reteaua providerului pentru a oferi conectivitate cu celelalte site-uri utilizator

utilizatorul foloseste protocoale de rutare pentru a stabili adiacenta intre ruterele diverselor site-uri

topologia de rutare e invizibila pentru provider (deoarece reteaua comuta trafic de nivel 2 prin circuitele virtuale) 

inteligenta este la nivel utilizator, echipamentele din backbone (reteau utilizator) nu participa la procese de nivel 3

dezavantaje : problema scalabilitatii - adaugarea unui site nou implica construirea a (n-1)/2 conexiuni noi (n = numarul de site-uri conectate) ; construirea unui full-mesh

Modelul peer (VPN de nivel 3)

providerul si utilizatorul folosesc aceleasi protocoale de retea

ruterele utilizatorului mentin adiacenta de rutare cu ruterele de granita ale retelei providerului; ruterele utilizatorului au astfel un singur vecin direct de rutare

ruterele CE si PE utilizeaza protocoale OSPF (Open Shortest Path First), IS-IS sau BGP (Border Gateway Protocol) pentru schimbul informatiei de rutare intre ele

inteligenta la nivel utilizator si in backbone provider

dezavantaj : nu este permisa utilizarea adreselor private

Adevaratul model peer – MPLS VPN

Utilizatorii doresc sa cumpere retele nu conexiuni !

MPLS VPN defineste o noua paradigma: retele private la nivel retea, nu la nivel de conexiune, in care pastreaza paradigma de neorientare pe conexiune si pot dezvolta servicii IP (ex : multicast, QoS, suport pentru telefonie, servicii centralizate).


Avantaje

Servicii neorientate pe conexiune. Pentru a realiza componenta privata intr-o retea nebazata pe conexiune, cum este reteaua IP, retelele VPN actuale necesita un model overlay, cu conexiuni punct-la-punct. Chiar daca este dezvoltata peste o retea neorientata pe conexiune nu poate sa beneficieze de avantajele de conectivitate si servicii multiple oferite de aceasta. Daca se defineste un VPN neorientat pe conexiune nu mai am nevoie sa definesc tunele si sa utilizez encriptare pentru asigurarea calitatii de retea privata

Servicii centralizate : construind retele VPN de nivel 3 pot sa ofere servicii unui grup de utilizatori grupati intr-un VPN. Deoarece retelele VPN bazate pe MPLS sint vazute ca si intraneturi private, pot utiliza servicii IP : multicast, QoS, suport pentru telefonie in VPN, servicii centralizate.

Scalabilitate : cind se definesc retele VPN utilizind servicii orientate pe conexiune (model overlay punct-la-punct) adica circuite virtuale de tip Frame Relay/ATM apare problema scalabilitatii. Astfel, retelele VPN orientate pe conexiune fara un full mesh intre toate site-urile utilizatorilor, nu sint optime. MPLS VPN utilizeaza modelul peer si neorientarea pe conexiune.

Securitatea: acelasi nivel de securitate cu al retelelor VPN orientate pe conexiune. Pachetele dintr-un VPN nu sunt rutate in alt VPN. Securitatea se asigura la: intrarea in reteaua provider-ului (pachetele primite de la un utilizator sunt plasate in VPN corect); in reteaua providerului traficul VPN este separat.

Usor de creat: pentru a beneficia de avantajele VPN trebuie sa fie usor de configurat si creat. Deoarece MPLS VPN sint neorientate pe conexiune nu imi trebuie harti de conexiune punct-la-punct si topologii.

Adresare flexibila: utilizatorii pot sa-si creeze propriul plan de adrese. Majoritatea utilizatorilor folosesc spatiul de adrese private, definit in RFC 1918, si nu doresc sa converteasca aceste adrese in adrese publice pentru a permite conectivitatea intranet. MPLS VPN permite utilizatorilor sa foloseasca acelasi spatiu de nume fara NAT prin oferirea a doua viziuni: publica si privata asupra spatiului de adrese. NAT se utilizeaza doar daca doua VPN-uri cu acelasi spatiu de adrese doresc sa comunice.

Suport pentru Class of Service (CoS): important pentru predictibilitatea performantei si implementarea politicilor; suport pentru servicii multiple de retea.

Migrarea: MPLS VPN se pot defini pe arhitecturi multiple: IP, ATM, Frame Relay, arhitecturi hibrid.








2.3 Terminologie MPLS –VPN



In contextul MPLS VPN, prin VPN nu mai inteleg modalitatea de a lega un site la alt site printr-un circuit virtual permanent. Aici, prin VPN definesc o colectie de site-uri care impart aceeasi informatie de rutare.


Concepte :

Retea provider (P network): backbone sub controlul unui Service Provider; domeniu de retea MPLS.


Retea utilizator (C network): reteaua utilizatorului.


Ruter CE (Customer Edge Router): ruter din reteaua utilizatorului care are interfata spre ruter PE; stabileste adiancenta cu ruterele PE la care este conectat.


Ruter PE (Provider Edge Router) : ruter din reteaua providerului care are interfata spre un ruter CE.


Legatura CE-PE : link intre ruterele PE si CE, poate fi construit pe orice tehnologie (ATM, Frame Relay, Ethernet, PPP, tunele GRE).


Site: colectie de (sub)retele din reteaua utilizator aflate in acceasi locatie; un site este legat la backbone prin unul sau mai multe linkuri CE-PE.


Ruter P: ruter din interiorul retelei providerului; nu mentine informatii de rutare legate de VPN; nu are legatura directa cu un ruter CE; sint noduri tranzit din reteaua MPLS.


VRF (VPN Routing and Forwarding Instance):concept cheie , definit la nivel de ruter PE. Este tabela de rutare si forwardare.

VRF e privat : accesibila doar interfetelor care sint intr-o anumita retea VPN.Fiecare site legat de un ruter PE trebuie sa aiba un VRF asociat. Toata informatia de rutare legata de un VPN se afla in VRF.

Obs1 : VRF asociat unui site (de exemplu siteA), e populat cu rute ce duc spre site-uri care au cel putin un VPN in comun cu siteA

Obs 2: site-urile care au conectivitate IP trebuie sa fie in acelasi site

Avantajele aduse de definirea VRF : utilizarea aceluiasi spatiu de adresare de catre doua sau mai multe VPN-uri, deoarece nu vor avea in comun tabela de rutare (VRF-ul) => membri unui VPN pot utiliza adrese private (RFC 1918) in reteaua utilizator si sa schimbe rute private peste infrastructura providerului fara a interfera cu alti utilizatori care folosesc acelasi spatiu de adrese in reteaua lor

Obs3 : la nivel de ruter PE avem : tabela de rutare globala (rute care nu fac parte din VPN-uri) si VRF pentru fiecare site.

Obs4 : natura VRF determina imposibilitatea ca un pachet dintr-un VPN sa fie transmis in alt VPN deoarece nu am nici o ruta spre alt VPN in VRF propriu => creste securitatea.


Adresa VPN-Ipv4

rutele utilizator sint idependente si izolate pentru fiecare VPN

utilizatorii din VPN folosesc RFC 1918 pentru spatiul de adrese

daca nu se utilizeaza adrese unice => pot avea utilizatori cu aceeasi adresa => problema la nivel de protocol BGP deoarece se presupune ca fiecare adresa Ipv4 e unica (BGP va trata doua adrese identice la fel si va construi o singura ruta => unul din utilizatori nu va fi disponibil)

solutia : VPN-IPv4 = concatenare de RD si adresa IPv4 ; 96 biti

RD (Route Distinguisher) se configureaza la nivel de ruter PE pentru fiecare VRF ; este un atribut al unei rute care identifica in mod unic VPN-ul (64 biti) utilizat doar pentru realizarea unicitatii adresei; nu exista nici o relatie directa intre RD si VPN

adresa VPN-IPv4 este utilizata doar in ruterele PE si in backbone provider intre ruterele PE

utilizatorii nu cunosc adresa VPN-IPv4.

OBS: VPN-IPv4 e transportata de protocoalele de rutare din backbone nu e transportata de pachetele din traficul VPN.


Route Target

- 64 biti, identifica ruterele care trebuie sa primesca o ruta; identificator transportat in atributele Extended Community al mesajelor de actualizare BGP

- ruterele PE importa/exporta mesaje de actualizare; fiecare VRF de la nivelul unui ruter PE are asociata o politica de import/export

- actualizarea VPN-IPv4 distribuita de PE este marcata cu atributul RT de import/export. Rutele VPN-IPv4 primite de un ruter PE sint verificate, se verifica daca RT face matching pe RT import din VRF => exista matching => ruta e trecuta in VRF.



2.4 Modelul conexiunii



VPN = colectie de site-uri care impart aceeasi informatie de rutare. Un site poate sa apartina mai multor VPN-uri. Daca doua sau mai multe VPN-uri au un site in comun, spatiul de adrese trebuie sa fie unic intre aceste VPN-uri.

Reteaua providerului este o retea MPLS compusa din noduri MPLS, astfel: ruterele PE sint noduri ingress/egress, ruterele P sint noduri tranzit.

1. Ruterele PE si CE utilizeaza protocoale de rutare pentru schimbul informatie de rutare: RIPv2 (fata de RIP transporta si informatie de subnet), OSPF (cel mai utilizat), eBGP (cel mai utilizat cind backbone provider e alcatuit din mai multe sisteme autonome), rutare statica (utilizata daca numarul rutelor e mic si reteaua utilizator are un singur link PE-CE cu reteaua providerului).

Ruterele PE mentin tabele VRF separate. Cind configurez un ruter PE, asociez un VRF cu o subinterfata/interfata a ruterului PE care leaga ruterul PE de ruterul CE.

Obs: daca un site are hosturi care fac parte din mai multe VPN-uri, atunci VRF asociat site va contine rute catre toate VPN-urile in care hosturile respective sint membre.

Cind primeste informatie de rutare de la CE, ruterul PE se uita in tabela VRF asociata (aceasta e determinata de subinterfata pe care a venit informatia). Rutele pe care le primeste de la CE le trece in VRF, rutele pe care le primeste de la alt ruter PE le trece in tabela globala de rutare.


2. Ruterele PE si P utilizeaza acelasi protocol de rutare (OSPF, IS-IS) pentru stabilirea topologiei.

Ruterele PE utilizeaza sesiuni MP-iBGP (Multi Protocol Interior BGP) pentru a schimba informatie de rutare intre ele.

Ruterele PE primesc mesaje de update cu adrese IPv4 de la ruterele CE, translateaza aceasta adresa in adresa VPN-IPv4 (asigneaza RT, rescrie cimpul next-hop, asigneaza o eticheta pe baza VRF si/sau interfata – ex: asignez eticheta 1001 rutelor pe care le invat de la CE1 si astfel cind primesc din backbone un pachet cu eticheta 1001 stiu ca trebuie sa-l trimit la CE1 dupa ce am scos eticheta-, trimit mesaj de actualizare celorlalte rutere PE..

Inainte ca PE sa distribuie informatia de rutare la celalalte rutere PE, converteste adresa IPv4 in adresa VPN-IPv4 utilizind RD asociat pentru fiecare VRF. Mesajul pe care-l trimite celorlalte rutere PE contine:

adresa VPN-IPv4

BGP next hop (propria adresa de loopback codata ca adresa VPN-IPv4 cu RD=0, deoarece MP-BGP necesita ca adresa hopului urmator sa fie din aceeasi familie ca a rutei transmise)

eticheta MPLS asociata ruterului PE ingress cind invata o ruta de la CE

atributele Route Target din politicile de export PE.

Obs: eticheta MPLS asociata ruterului PE ingress adresei VPN-IPv4 va fi in headerul MPLS din pachetul transmis spre destinatie.

Cand un ruter PE primeste o ruta VPN-IPv4 de la un ruter PE peer, compara ruta cu politica import VRF pentru toate VPN-urile associate ruterului egress PE (compara RT-urile). Daca am matching, instalez ruta in VRF.


2.5 Mecanismul de forwarding


Ruterele PE si P utilizeaza protocoale de rutare pentru construirea topologiei. In cadrul backbone-ului providerului se utilizeaza tehnologia MPLS, pachetele sint commutate pe baza etichetelor asignate si distribuite de LDP (Label Distribution Protocol).

Pachetele vor utiliza stiva de etichete:

top label (interior label): eticheta MPLS pentru comutarea in interiorul backbone

bottom label (exterior label): eticheta MPLS pentru transmiterea pachetelor de la PE la CE

Nodurile MPLS comuta pachetele pe baza top label.

Obs: nodurile MPLS (ruterele P) nu au informatii despre VPN, informatii de rutare BGP.

Penultimul hop inainte de PE egress sterge eticheta top label expunand astfel eticheta bottom label si forwardeaza pachetul spre PE egress (penultimate hop popping).

PE egress forwardeaza pachetul la CE pe baza bottom label (identifica interfata/VPN-ul).



2.6 Etapele construirii MPLS VPN



Construirea tabelelor de rutare din ruterele arhitecturii.

Utilizare LDP pentru asignarea etichetelor.

Realizarea sesiunilor MB-iBGP intre ruterele PE

Invatarea adresei de la ruterele CE

Schimbul de informatii cu alte rutere PE

Decizia completarii tabelelor VRF

Comutare pachete in backbone utiliznd tehnologie MPLS.





Capitolul 3.VPDN



3.1 Introducere



VPDN-ul este o retea care extinde accesul la distanta(remote) la o retea privata utilizand o infrastructura comuna.VPDN utilizeaza tehnologii de tunelare de nivel 2(L2F,L2TP si PPTP) pentru a extinde nivelul 2 si partile superioare ale conexiunii retelei de la un utilizator indepartat de-a lungul unei retele ISP la o retea privata.Retelele VPDN sunt o metoda mai putin costisitoare de a realiza o conexiune la distanta,punct-la-punct intre utilizatorii la distanta si o retea privata.

In loc sa faca conexiuni direct la retea folosind o retea PSTN costisitoare , utilizatorii VPDN folosesc doar PSTN-ul pentru a se conecta la un ISP local POP.ISP-ul foloseste apoi internetul pentru a forwarda utilizatorii de la POP la client.A forwarda apelurile pe internet in locul apelurilor PSTN de lunga distanta produce o diminuare mare a costurilor pentru utilizator.





Vocabular



  • Client: PC sau ruter conectat la o retea cu acces la distanta, care este initiatorul apelului.
  • L2TP: Layer 2 Tunnel Protocol(Protocol de Tunelare de Nivel 2). PPP defineste un mecanism de incapsulare de transport a pachetelor multiprotocol peste conexiunea punct-la-punct de nivel 2(L2).In mod tipic, un utilizator obtine o conexiune L2 la un Network Access Server(NAS) utilizand o tehnica ca dial-up POTS(plain old telephone service), ISDN sau ADSL(Asymmetric Digital Subscriber Line).Utilizatorul apoi ruleaza PPP-ul pentru aceasta conexiune.Intr-o astfel de configurare, punctul terminus L2 si endpoint-ul sesiunii PPP tine de acelasi dispozitiv(NAS).L2TP extinde modelul PPP prin faptul ca permite endpoint-ului L2 si PPP sa apartina de diferite dispozitive interconectate la o retea.Impreuna cu L2TP, utilizatorul are o conexiune L2 la un access concentrator, si concentratorul apoi directioneaza cadrele PPP individuale catre NAS.Aceasta permite procesului actual al pachetelor PPP sa se separe de capatul circuitului L2.
  • L2F: Layer 2 Forwarding Protocol(Protocol de Forwardare de Nivel 2).L2F este un protocol de tunelare mai vechi decat L2TP.
  • LAC: L2TP Access Concentrator.Un nod care se comporta ca un endpoint tunnel al L2TP si care este un peer al LNS-ului.LAC-ul este legatura intre un LNS si un utilizator si forwardeaza pachete spre si de la fiecare.Pachetele trimise de la LAC catre LNS necesita o tunelare cu ajutorul protocolului L2TP.Conexiunea de la LAC catre client este de obicei prin ISDN sau analog.
  • LNS: L2TP Network Server. Un nod care se comporta ca un endpoint tunnel al L2TP si care este un peer al LNS-ului.LNS-ul este punctul terminus logic al unei sesiuni PPP care este tunelata de la utilizator de catre LAC.
  • Home Gateway: Aceeasi definitie ca si LNS in nomenclatura L2F.
  • NAS: Aceeasi definitie ca si LAC in nomenclatura L2F.
  • Tunnel: In nomenclatura L2TP un tunel este legatura intre perechea LAC-LNS.Tunelul se compune dintr-o conexiune de control si din niciuna sau mai multe sesiuni L2TP.Tunelul transporta datagrame PPP incapsulate si mesaje de control intre LAC si LNS.Procesul este asemanator pentru L2F.

Sesiune: L2TP este o conexiune-orientata.LNS si LAC mentin o stare pentru fiecare apel care este initiat sau receptionat de catre LAC.O sesiune L2TP este creata intre LAC si LNS cand o conexiune PPP end-to-end se stabileste intre utilizator si LNS.Datagramele referitoare la conexiunea PPP sunt trimise pe tunel intre LAC si LNS.Este o relatie unu-la-unu intre sesiunea L2TP stabilita si apelurile asociate lor. Procesul este asemanator pentru L2F.



























Prezentare generala a procesului de VPDN


In descrierea procesului de VPDN de mai jos, vom folosi nomenclatura L2TP(LAC si LNS)



vpdn_20980b.gif

1.Abonatul apeleaza LAC-ul(de obicei utilizand un modem sau un suport pe ISDN)

2.Abonatul si LAC-ul initiaza etapa PPP negociind optiunile LCP-metoda de autentificare PAP(Password Authentication Protocol) sau CHAP(Challenge Handshake Authentication Protocol), PPP multilink,compresie,etc.

3.Vom presupune ca CHAP-ul a fost negociat la pasul 2.LAC-ul trimite o chemare CHAP catre abonat.

4.LAC-ul primeste un raspuns(de exemplu numeutilizator@numedomeniu si o parola)

5.In functie de numele domeniului receptionat din raspunsul CHAP-ului sau DNIS-ul(Dialed Number Information Service) receptionat in structura mesajului ISDN, LAC-ul verifica daca abonatul este un utilizator de VPDN.El face asta utilizand configurarea VPDN locala sau contactand serverul AAA(Authentication, Authorization, and Accounting).

6.Din cauza faptului ca este un client utilizator de VPDN, LAC-ul primeste unele informatii(de la configuratia VPDN locala sau de la un server AAA) care sunt folosite pentru a conecta un tunel L2TP sau L2F cu LNS-ul.

7.LAC-ul se conecteaza printr-un tunel L2TP sau L2F cu LNS-ul.

8.In functie de numele receptionat din solicitarea catre LAC, LNS-ul verifica daca LAC-ul este indreptatit sa deschida o conexiune(LNS-ul verifica configuratia VPDN locala).Mai mult de atat, LAC-ul si LNS-ul se autentifica fiecare celuilalt(se folosesc de bazele de date locale sau contacteaza un server AAA).Tunelul este apoi functional intre ambele dispozitive.Pe acest tunel, mai multe sesiuni VPDN pot fi transportate.

9.Pentru numeutilizator@numedomeniu al clientului, o sesiune VPDN este initiata de la LAC catre LNS.Este o singura sesiune VPDN pentru fiecare client.

10.LAC-ul forwardeaza optiunile LCP negociate de LNS cu clientul odata cu numeutilizator@numedomeniu si parola receptionate de la client.

11.LNS-ul dubleaza un acces-virtual al unui model-virtual specificat in configurarea VPDN.LNS-ul ia optiunea LCP receptionata de la LAC si autentifica clientul local sau contactand serverul AAA.

12.LNS-ul trimite clientului un raspuns CHAP.

13.Etapa Protocolului de Control IP(IPCP) este executata si apoi ruta este instalata: sesiunea PPP este deschisa si ruleaza intre client si LNS.LAC-ul doar forwardeaza cadrele PPP.Cadrele PPP sunt tunelate intre LAC si LNS.

































3.3 Protocoale de tunelare



Un tunel VPDN poate fi construit fie utilizand L2F(Layer-2 Forwarding), fie L2TP(Layer-2 Tunneling Protocol)

L2F a fost introdus de catre Cisco RFC(Request For Comments) 2341 si este de asemenea folosit pentru a forwarda sesiunile PPP pentru Multichassis Multilink PPP.

L2TP,introdus in RFC 2661, inglobeaza ce este mai bun din protocolul L2F de la Cisco si PPTP(Point-to-Point Tunneling Protocol) de la Microsoft.Mai mult de atat, L2F suporta doar VPDN dial-in pe cand L2TP suporta atat VPDN dial-in cat si VPDN dial-out.


Ambele protocoale folosesc portul UDP 1701 pentru a construi un tunel de-a lungul unei retea IP pentru a forwarda cadrele link-layer.Pentru L2TP, setarile pentru a tunela o sesiune PPP constau in 2 pasi:


1.Stabilirea unui tunel intre LAC si LNS.Aeasta situatie are loc doar cand intre cele 2 dispozitive nu este nici un tunel active.

2.Stabilirea unei sesiuni intre LAC si LNS.


vpdn_20980c.gif


LAC-ul decide ca un tunel trebuie initiat de la LAC la LNS.


1.LAC-ul trimite un SCCRQ(Start-Control-Connection-Request).O apelare a CHAP-ului si perechile AV sunt de asemenea incluse in acest mesaj.

2.LNS-ul raspunde cu un SCCRP(Start-Control-Connection-Reply).O apelare a CHAP-ului, raspunsul la apelul LAC-ului si perechile AV sunt incluse in acest mesaj.

3.LAC-ul trimite un SCCCN(Start-Control-Connection-Connected).Raspunsul CHAP-ului este inclus in acest mesaj.

4.LNS-ul raspunde cu ZLB ACK(Zero-Length Body Acknowledgement).Confirmarea poate fi transportata de alt mesaj.Tunelul este functional.

5.LAC-ul trimite un ICRQ(Incoming-Call-Request) LNS-ului.

6.LNS-ul raspunde cu un mesaj ICRP(Incoming-Call-Reply).

7. LAC-ul trimite un ICCN(Incoming-Call-Connected).

8.LNS-ul raspunde inapoi cu un ZLB ACK. Confirmarea poate fi transportata de alt mesaj.

9.Sesiunea este deschisa.

Nota: Mesajele de mai sus folosite pentru deschiderea tunelului sau a sesiunii transporta AVP-uri(Attribute Value Pairs) definite in RFC 2661.Ele descriu proprietatile si informatii(ca de exemplu Bearercap, hostname, numele furnizorului sau marimea ferestrei).Unele perechi AV sunt obligatorii, altele sunt optionale.

Nota: Un ID de tunel este folosit pentru multiplexarea si demultiplexarea tunelelor intre LAC si LNS.Un ID de sesiune este folosit pentru a identifica o sesiune anume dintr-un tunel.

Pentru L2F, setarile pentru tunelarea unei sesiuni PPP este aceeasi ca si pentru L2TP.Ea implica:


1.Stabilirea unui tunel intre NAS si Home Gateway. Aeasta situatie are loc doar cand intre cele 2 dispozitive nu este nici un tunel active.

2. Stabilirea unei sesiuni intre NAS si Home Gateway.

vpdn_20980a.gif

NAS-ul decide ca un tunel trebuie stabilit intre NAS si Home Gateway.


1.NAS-ul trimite un L2F_Conf catre Home Gateway.O apelare a CHAP-ului este inclusa in acest mesaj.

2.Home Gateway-ul raspunde cu un L2F_Conf.O apelare a CHAP-ului este inclusa in acest mesaj.

3.NAS-ul trimite un L2F_Open.O apelare a CHAP-ului ce contine raspuns de la Home Gateway este inclusa in acest mesaj.

4.Home Gateway-ul raspunde cu un L2F_Open.O apelare a CHAP-ului ce contine raspuns de la NAS este inclusa in acest mesaj.Tunelul este functional.

5.NAS-ul trimite un L2F_Open catre Home Gateway.Pachetul contine numele de utilizator al clientului(client_name), apelarea CHAP-ului trimisa de catre NAS clientului(challenge_NAS) si si raspunsul clientului(response_client).

6.Home Gateway-ul, trimitand inapoi L2F_Open, accepta clientul.Traficul este acum functional in ambele sensuri intre client si Home Gateway.

Nota: Un tunel este identificat prin CLID(Client ID).MID-ul(Multiplex ID) identifica o conexiune particulara in interiorul tunelului.



3.4 Functionalitati de baza



VPN asigura un serviciu de transmisie de date bazat pe o tehnologie IP-MPLS.VPN ofera o retea securizata reala clientilor, mentinand securizarea in timpul utilizarii cu ajutorul protocoalelor de tunelare si procedurilor de securitate.

VPDN-retea virtuala securizata prin Dial-Up permite utilizatorilor de la distanta sa schimbe informatii cu o comunitate LAN cu ajutorul unei conexiuni securizate utilizand L2TP(Protocol de Tunelare de Nivel 2).

VPN-urile implica o forta de munca mobile pentru a se conecta la corporatia de intranet sau extranet oricand,oriunde, cu scopul de a mari productivitatea si flexibilitatea odata cu reducerea costurilor de acces.Securitatea comunicarii este asigurata de protocolul L2TP.L2TP este un protocol de tunelare care suporta tunelarea si autentificarea utilizatorilor.L2TP standard asigura interoperabilitatea intre operatori,marind flexibilitatea clientilor si utilizarea serviciilor.

O solutie de acces VPN in masa este L2TP, o extensie a protocolului Punct-la-Punct(PPP) si un modul fundamental pentru VPN.L2TP imbina cea mai buna caracteristica a altor doua protocoale de tunelare:L2F(Forwardare de Nivel 2) proprietate a Cisco Systems si PPTP(Tunelare Punct-la Punct) proprietate Microsoft.



3.4.1 Descriere



Figura 1 prezinta configuratia generala a unei solutii L2TP Dial-Up cu acces de la distanta a unei retele MPLS VPN


Figure 1-Remote access to MPLS VPN

L2TP asigura interoperabilitatea intre operatori,marind flexibilitatea clientilor si utilizarea serviciilor.In interiorul retelei IP MPLS a fost definita o retea MPLS asociata unui utilizator.Utilizatorul unei conexiuni de la distanta solicita de la PC acces la reteaua de comanda.Utilizatorul de la distanta initiaza o conexiune apeland numarul de acces.Apelul este transmis printr-o retea PSTN sau ISDN catre un server de acces care face parte din reteaua IP MPLS.Serverul de acces al retelei accepta conexiunea, si o conexiune PPP sau multiconexiune se stabileste intre utilizator si serverul de acces la retea.

Serverul de acces la retea partial autentifica utilizatorul cu protocolul CHAP(Challenge Handshake Authentication Protocol) sau protocolul PAP(Password Authentication Protocol).Numele domeniului sau DNIS(Dialed Number Identification Service) este folosit pentru a se stabili daca utilizatorul este sau nu un client de VPN.

Daca utilizaorul nu este un client de VPN atunci serverul AAA returneaza adresa unui ruter VHG .Daca nu exista un tunnel L2TP,serverul de acces la retea initiaza un tunnel catre VHG(Virtual Home Gateway).Serverul de acces la retea si VHG se autentifica fiecare inainte ca pe tunnel sa inceapa o sesiune.

Sunt 2 metode de acces prin apelare in functie de linia de apel folosita:


pentru liniile PSTN este folosit protocolul L2TP

pentru liniile ISDN poate fi folosit atat protocolul L2TP cat si accesul ISDN direct


In cazul utilizarii protocoului L2TP, odata ce tunelul este stabilit, o sesiune in cadrul tunelului este creata pentru utilizatorii de la distanta, si o conexiune PPP este extinsa pana la limita ruterului VHG.Serverul de acces la retea furnizeaza toate informatiile detinute ale conexiunii PPP ruterului VHG/PE.Ruterul VHG/PE asociaza utilizatorii de la distanta cu utilizatorii specifici de VPN.Cererea generata de VRF(virtual routing/forwarding) VPN-ului a fost deja initiata pe ruterul VHG/PE.Ruterul VHG/PE completeaza autentificarea utilizatorilor de la distanta.Ruterul VHG/PE obtine o adresa IP pentru utilizatorul de la distanta.Sesiunea utilizatorului de la distanta devine parte a VPN-ului specific.Transferul de date intre utilizatorul de la distanta si reteaua specificata este stabilita.

Figura 2 reprezinta configuratia la ceea ce s-a discutat mai sus

Figure 2 – The architecture of remote access - L2TP to MPLS VPN


In cazul utilizarii accesului ISDN direct, serverul de acces la retea are functie si de NAS(Network Access Server), cat si de ruter PE.In contrast cu o sesiune de logare L2TP, sesiunea de PPP este plasata in imediata apropiere a VRF-ului retelei de MPLS VPN.Utilizatorul de la distanta initiaza o conexiune PPP catre serverul de acces la retea folosind ISDN.Ruterul NAS/PE accepta conexiunea, si conexiunea PPP este stabilita.Ruterul NAS/PE autorizeaza apelul catre severul AAA al furnizorului, si autorizarea se face pe baza numelui domeniului sau a DNIS-ului.Serverul AAA al Romtelecomului asociaza utilizatorul la distanta cu un VPN specific si returneaza numele instantei VRF corespunzatoare la ruterul NAS/PE al serverului de acces la retea, impreuna cu o adresa IP.Utilizatorul la distanta este acum parte a VPN-ului respectiv, si conexiunea este acum activa.

Figura 3 reprezinta configuratia la ceea ce s-a prezentat mai sus

Figure 3 – The architecture of ISDN remote access direct to MPLS VPN



3.4.2 Functia de acces VPDN



Structura functiei de acces VPDN este urmatoarea:

Nume utilizator: nume@domeniu

Parola: in functie de sugestia consumatorului


Functionalitati suplimentare

Nu este nici o specificare anume in privinta functionalitatii suplimentare



3.4.3 Elementele componente ale serviciului(tipurile de CPE)



Componentele specifice unei configuratii logice ale serviciului de VPN sunt:

VHG/PE-Virtual Home Gateway/Provider Edge Router

NAS/PE-Network Access Server/Provider Edge Router

Server AAA-Authentication Authorization Accounting.

Echipamentul necesar utilizatorului este un calculator dotat cu un modem analog(acces pe baza PSTN) sau modem ISDN(acces pe baza de ISDN).



3.5 Configurarea VPDN






Aceasta tehnologie permite conectarea unui client la o retea privata, prin intermediul retelei clasice de telefonie (PSTN) sau ISDN.

In cazul Romtelecom, tehnologia VPDN este folosita ca solutie de backup pentru clientii VPN.


Cum functioneaza:


Clientul VPDN, in cazul solutiilor de backup oferite de Romtelecom, este un router Cisco care are un card BRI S/T conectat la o linie ISDN.

Mai jos este un exemplu de configurare al interfetei BRI:


description *** Backup Link ***

ip unnumbered Loopback0

encapsulation ppp

load-interval 30

dialer idle-timeout 5

dialer enable-timeout 30

dialer string 0870111111

dialer load-threshold 128 outbound

dialer watch-group 8

dialer-group 1

isdn switch-type basic-net3

isdn point-to-point-setup

no keepalive

no cdp enable

ppp authentication chap callin

ppp chap hostname username@domeniu.ro

ppp chap password test

ppp multilink


 



















In momentul cand locatia din VPN ramane fara linkul principal (modalitatea de comutare nu face obiectul acestei prezentari), clientul VPDN prin intermediul retelei ISDN, suna la un numar de acces special (0870111111) – acesta se configureaza in dialer string.

Apelul ajunge intr-un LAC - L2TP Access Concentrator (intalnit si sub denumirea de RAS - Router Access Server).

Dupa ce apelul ajunge in RAS, clientul VPDN (routerul Cisco) initiaza o sesiune PPP catre LAC.


Faza 1 - Link-establishment phase (negocierea LCP – se stabileste metoda de autentificare PAP/CHAP, PPP Multilink etc). In exemplul de mai sus avem configurat pe routerul Cisco CHAP, PPP Multilink.


Faza 2 - Authentication phase - LAC-ul trimite catre client un challenge, iar clientul raspunde cu username-ul configurat: username@domeniu.yyy si cu parola configurata.

LAC-ul verifica in configuratia sa daca are configurat acest domeniu (domeniu.ro) si daca exista, atunci decide ca Username@domeniu.ro este un user VPDN.


request-dialin

protocol l2tp

domain domeniu.ro

domain client_a.ro

domain client_b.ro

domain client_c.ro

initiate-to ip 193.231.x.x

source-ip 86.34.x.x

local name LAC


l2tp tunnel password 1234

 













Dupa aceasta LAC-ul va prelungi sesiunea PPP pana intr-un LNS (L2TP Network Server) peste un tunel VPDN.


Protocoalele folosite pentru realizarea unui tunel VPDN:

Layer 2 Forwarding (L2F)

Layer 2 Tunneling Protocol (L2TP)

In reteaua Romtelecom, protocolol folosit este L2TP.


LNS poate fi:

routerul din locatia HQ a clientului VPN, atunci cand aceasta locatie are o alta solutie de backup decat VPDN

routerul PE 7206vpdn – folosit in cazurile in care VPN-ul pentru care se asigura backup nu are o locatie HQ, sau routerul HQ are ca backup tot solutia VPDN, sau nu s-a dorit ca HQ-ul sa fie LNS


In cazul retelei Romtelecom, acest tunel nu se initiaza direct intre LAC si LNS, ci se face prin intermediul unui router PE (7206) - judetean.

Dupa ce LAC-ul determina ca apelul este de la un user VPDN, va initia tunelul L2TP catre IP-ul configurat la “initiate-to ip”, care reprezinta IP-ul PE-ului 7206 judetean.

Obs: Pentru majoritatea judetelor tunelul se deschide catre 7206 din fiecare judet, din POP-ul mare (daca sunt mai multe), iar in Bucuresti se deschide catre un alt 7206. Mai sunt si cateva exceptii, pentru care tunelul nu se deschide in 7206 din judetul respectiv ci in alt judet. La configurarea unui VPDN nou trebuie avut in vedere acest aspect.


Mai jos sunt prezentate configuratiile de pe un 7206.
























Pe langa configuratiile de mai sus mai trebuie configurat si VRF-ul acestui VPN pentru a putea avea in tabela de rutare ruta catre IP-ul configurat la “initiate-to ip” – acest IP este IP-ul LNS-ului. In acest IP se va termina tunelul VPDN si sesiunea PPP initiata de clientul VPDN.

Tunelul initiat din LAC ajunge in 7206 si se prelungeste pana in LNS si anume pana la IP-ul 192.168.100.1.

Exista un schimb de mesaje intre LAC si LNS pentru ridicarea tunelului (in special autentificarea tunelului L2TP – conform parolei configurate), iar dupa ce tunelul se ridica, se porneste stabilirea sesiunii PPP.

LAC-ul forwardeaza LNS-ului ce a primit de la routerul client username si parola si dupa fazele stabilirii sesiunii PPP, vom avea o sesiune PPP intre routerul Cisco client si LNS.

Mai jos este prezentata o configuratie a unui LNS, dar dupa cum specificam mai sus, LNS-ul poate fi:

routerul din locatia HQ a clientului VPN, atunci cand aceasta locatie are o alta solutie de backup decat VPDN

routerul PE 7206vpdn – folosit in cazurile in care VPN-ul pentru care se asigura backup nu are o locatie HQ, sau routerul HQ are ca backup tot solutia VPDN.



accept-dialin

protocol l2tp

virtual-template 1

terminate-from hostname PE

source-ip 192.168.100.1

local name CPE

l2tp tunnel password 1234


interface Virtual-Template1

ip unnumbered Loopback0

ip nat inside

ip virtual-reassembly

load-interval 30

no peer default ip address

ppp authentication chap

ppp multilink


interface Loopback0

ip address 192.168.100.1 255.255.255.255


 





Pe langa aceste configuratii, mai trebuiesc definiti local

userii si parolele pentru fiecare client VPDN in parte.

 











! Default L2TP VPDN group

description *** L2TP VRF tunnel between PE and CE ***

accept-dialin

protocol l2tp

vpn vrf Testare

source-ip 172.18.34.200

local name 7206vpdn

l2tp tunnel password 1234


interface Virtual-Template9

ip vrf forwarding Testare

ip unnumbered Loopback15

load-interval 30

ppp authentication chap pap parola

ppp multilink


interface Loopback15

description *** VPDN Testare ***

ip vrf forwarding Testare

ip address 172.18.34.200 255.255.255.255


 





















Pe langa configuratiile de mai sus, mai trebuie configurat si VRF-ul acestui client.

Tot la aceasta categorie, putem avea un VPN cu solutie de backup VPDN atipica fata de cea descrisa de mai sus cu doua diferente majore :

autentificarea clientului VPDN nu se face local pe LNS (7206vpdn) ci se face pe un server Radius. Astfel, cand apare o locatie noua, userul si parola trebuie definita in acest server

vpdn-grupul dupa care se ridica tunelul VPDN se numeste vpdn_dial.


server 80.97.x.x auth-port 1645 acct-port 1646


aaa authentication ppp TEST local group AUTHVPDN

aaa authorization network TEST local group AUTHVPDN


vpdn-group vpdn_dial

accept-dialin

protocol l2tp

virtual-template 1

terminate-from hostname vpdn_dial

lcp renegotiation on-mismatch


interface Virtual-Template1

ip unnumbered Loopback0

ip ospf network point-to-point

load-interval 30

no peer default ip address

no keepalive

ppp authentication chap pap TEST

ppp authorization TEST

ppp multilink


 





















Configuratia pentru 7206vpdn


In desenul de mai jos este o sintetizare grafica a celor de mai sus.



Tips&Tricks pentru troubleshooting


In mod normal, daca totul este in regula configurat, atunci pe clientul VPDN trebuie sa se ridice interfata BRI si interfata virtual-acces 1:

Dec 3 13:21:30.859 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state to up

Dec 3 13:21:30.863 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to up


Si bineinteles sa se ridice si sesiunea BGP:

Dec 3 13:21:33.903 UTC: %BGP-5-ADJCHANGE: neighbor 192.168.100.1 Up


Daca virtual-acces1 se ridica, dar sesiunea BGP nu se ridica, atunci trebuie verificata partea de configurare BGP care nu face scopul acestei prezentari.


Daca nu se ridica virtual-access1:

Se verifica daca interfata BRI0 este UP (sa nu fie in shutdown)

Daca este UP, se face un apel de test catre numarul configurat pe BRI la dialer string:

isdn test call interface BRIx 0870111111

Se porneste si un debug ppp authentification si se observa daca se conecteaza la RAS si se ridica virtual-acces1.

Daca nu se intampla nimic, se porneste un debug isdn error pentru a vedea daca este o problema de line (un layer 1 inactive de ex).

Daca se conecteaza la RAS si nu se ridica virtual-acces1, si din debugul pornit se primeste:

Dec 3 13:31:05.611 UTC: BR0:1 CHAP: I FAILURE id 241 len 25 msg is 'Authentication failed', atunci este o problema de autentificare a clientului VPDN, intr-unul din capete (client sau LNS) nu se potrivesc username sau parola. Se identifica problema si se rezolva. Acelasi lucru poate fi cauzat si de lipsa pe RAS a domeniului xxxx.yyy

Daca totusi nu se primeste mesajul de Authentication failed, dar nu se primeste mesajul “success” :

Dec 3 13:32:52.090 UTC: BR0:1 CHAP: I SUCCESS id 103 len 4

si virtual acces1 nu se ridica, e o problema pe partea de VPDN, intre RAS si 7206 sau intre 7206 si LNS. Posibile probleme:

parola folosita pentru autentificarea tunelului L2TP nu este aceeasi in ambele capete pe cele doua portiuni ale sale: LAC-7206 si 7206-LNS

pe 7206 nu avem ruta catre IP-ul LNS – catre care se initiaza tunelul L2TP (ori nu e creat VRF-ul pe 7206, ori nu e data redistribute connected in address-family pentru a se redistribui in vpn sursa tunelului – IP-ul de pe interfata loopback corespunzatoare acestui VPDN



In momd normal, daca se ridica virtual-acces1, pe 7206 vom avea asa ceva:

7206cal1#sh vpdn tunnel


L2TP Tunnel Information Total tunnels 2 sessions 2


LocID RemID Remote Name State Remote Address Port Sessions VPDN Group

62875 60592 LAC           est 86.34.x.x 1701 1 1

6992 11418 CPE est 192.168.100.1 1701 1 3


Primul este tunelul L2TP intre LAC si 7206, iar al doilea, este prelungirea acestui tunel intre 7206 si LNS. La state apare established.


Cand nu e OK, niciun tunel nu este UP:


7206cal1#sh vpdn tunnel


%No active L2TP tunnels


Pentru cunoscatori: exista niste debuguri utile pe 7206 care cateodata sunt utile:



call VPDN call

error VPDN protocol errors

event VPDN event

l2tp-sequencing L2TP sequencing

l2x-data L2F/L2TP data packets

l2x-errors L2F/L2TP protocol errors

l2x-events L2F/L2TP protocol events

l2x-packets L2F/L2TP control packets

message VPDN inter-process message

packet VPDN packet

pppoe-data PPPoE data packets (obs: use 'deb pppoe data')

pppoe-errors PPPoE protocol errors (obs: use 'deb pppoe err')

pppoe-events PPPoE protocol events (obs: use 'deb pppoe ev')

pppoe-packets PPPoE control packets (obs: use 'deb pppoe pac')

sss VPDN SSS SIP information

 


















Mai jos este prezentat un debug vpdn l2x-events si ce se intampla cand nu se reuseste autentificarea tunelului L2TP intre 7206 si LNS (am schimbat parola de pe vpdn-group-ul configurat pe 7206):

Incepe ridicarea tunelului (35951) intre LAC si 7206










Autentificare reusita



Se ridica tunelul


Incepe ridicarea tunelului (45604) intre 7206 si LNS














Autentificare esuata












Tunelul 45604 se pune in shutdown


Tunelul 35951 se pune in shutdown



 

Dec 3 16:02:23.565: Tnl 35951 L2TP: Got a challenge in SCCRQ, LAC

Dec 3 16:02:23.565: Tnl 35951 L2TP: New tunnel created for remote LAC, address 86.34.90.8

Dec 3 16:02:23.565: Tnl 35951 L2TP: O SCCRP to LAC tnlid 53262

Dec 3 16:02:23.565: Tnl 35951 L2TP: Control channel retransmit delay set to 1 seconds

Dec 3 16:02:23.565: Tnl 35951 L2TP: Tunnel state change from idle to wait-ctl-reply

Dec 3 16:02:23.569: Tnl 35951 L2TP: I SCCCN from LAC tnl 53262

Dec 3 16:02:23.569: Tnl 35951 L2TP: Got a Challenge Response in SCCCN from LAC

Dec 3 16:02:23.569: Tnl 35951 L2TP: Tunnel Authentication success

Dec 3 16:02:23.569: Tnl 35951 L2TP: Tunnel state change from wait-ctl-reply to established

Dec 3 16:02:23.569: Tnl 35951 L2TP: SM State established

Dec 3 16:02:23.569: Tnl 35951 L2TP: I ICRQ from LAC tnl 53262

Dec 3 16:02:23.573: Tnl/Sn 45604/50876 L2TP: Session FS enabled

Dec 3 16:02:23.573: Tnl/Sn 45604/50876 L2TP: Session state change from idle to wait-for-tunnel

Dec 3 16:02:23.573: uid:59 Tnl/Sn 45604/50876 L2TP: Create session

Dec 3 16:02:23.573: Tnl 45604 L2TP: SM State idle

Dec 3 16:02:23.573: Tnl 45604 L2TP: O SCCRQ

Dec 3 16:02:23.573: Tnl 45604 L2TP: Control channel retransmit delay set to 1 seconds

Dec 3 16:02:23.573: Tnl 45604 L2TP: Tunnel state change from idle to wait-ctl-reply

Dec 3 16:02:23.573: Tnl 45604 L2TP: SM State wait-ctl-reply

Dec 3 16:02:23.585: Tnl 45604 L2TP: I SCCRP from CPE

Dec 3 16:02:23.585: Tnl 45604 L2TP: Got a challenge from remote peer, CPE

Dec 3 16:02:23.585: Tnl 45604 L2TP: Got a response from remote peer, CPE

Dec 3 16:02:23.585: Tnl 45604 L2TP: Tunnel auth failed for CPE

Dec 3 16:02:23.585: Tnl 45604 L2TP: Expected

66 84 60 61 09 08 20 45 77 8E 6D 15 F8 82 3C 52

Dec 3 16:02:23.585: Tnl 45604 L2TP: Got

05 93 BA 8C 8A 64 BA 8E 52 C9 4D E6 82 D8 52 AB

Dec 3 16:02:23.585: Tnl 45604 L2TP: O StopCCN to CPE tnlid 36899

Dec 3 16:02:23.585: Tnl 45604 L2TP: Control channel retransmit delay set to 1 seconds

Dec 3 16:02:23.585: Tnl 45604 L2TP: Tunnel state change from wait-ctl-reply to shutting-

Dec 3 16:02:23.585: Tnl 35951 L2TP: Tunnel state change from established to no-sessions-left

Dec 3 16:02:28.585: Tnl 45604 L2TP: Shutdown tunnel

Dec 3 16:02:28.585: Tnl 45604 L2TP: Tunnel state change from shutting-down to idle

Dec 3 16:02:38.585: Tnl 35951 L2TP: Shutdown tunnel

 
Mai jos este prezentat un debug vpdn l2x-events si ce se intampla cand se reuseste autentificarea tunelului L2TP intre 7206 si LNS:


















Capitolul 4.Lucrarea practica



4.1 Modul de conectare



In arhitectura retelelor MPLS, CPE-ul este conectat la reteaua providerului(la routerul PE) folosind o solutie clasica de acces(Cu,FO,etc.).Se foloseste un protocol de rutare dinamica sau rutare statica conectandu-se la reteaua MPLS a ISP-ului, rutele fiind transportate mai departe folosindu-se protocolul BGP.In arhitectura VPDN pe care o studiem, CPE-ul e cel care initiaza un apel catre un numar de acces special dintr-un server de acces local(LAC), tehnica de acces folosita fiind PSTN sau ISDN.

LAC-ul trimite catre client un challenge, iar clientul raspunde cu username-ul configurat: username@domeniu.yyy si cu parola configurata.

LAC-ul verifica in configuratia sa daca are configurat acest domeniu (domeniu.ro) si daca exista, atunci decide ca Username@domeniu.ro este un user VPDN.

Dupa aceasta LAC-ul va prelungi sesiunea PPP pana intr-un LNS (L2TP Network Server) peste un tunel VPDN.

In cazul nostru, acest tunel nu se initiaza direct intre LAC si LNS, ci se face prin intermediul unui router PE (7206) - judetean.

Tunelul initiat din LAC ajunge in 7206 si se prelungeste pana in LNS si anume pana la IP-ul 192.168.100.1.

Exista un schimb de mesaje intre LAC si LNS pentru ridicarea tunelului (in special autentificarea tunelului L2TP – conform parolei configurate), iar dupa ce tunelul se ridica, se porneste stabilirea sesiunii PPP.

LAC-ul forwardeaza LNS-ului ce a primit de la routerul client username-ul si parola si dupa fazele stabilirii sesiunii PPP, vom avea o sesiune PPP intre routerul Cisco client si LNS.








Odata stabilita aceasta sesiune, Routerul CPE poate comunica cu LNS-ul si putem initia si o sesiune BGP intre cei 2 prin care CPE-ul isi anunta rutele sale si primeste rutele din alte locatii peste reteaua MPLS.Spre exemplu poate invata rutele din alta locatie din VPN in cazul in care VPN-ul este de tip any-to-any sau poate primi doar rutele din HQ in cazul in care VPN-ul este de tip hub&spoke.

In final am demonstrat ca avem stabilita o conexiune pe back-up prin VPDN folosind o solutie de acces prin ISDN catre o alta locatie din VPDN folosind reteaua MPLS a ISP-ului.




















4.2 Preliminariile lucrarii



Se va utiliza un CPE de tip Cisco 1803, versiunea de IOS 12.4(11)T2 cu interfata g.SHDSL conectata in reteaua IP/MPLS ca linie principala si backup prin ISDN.

Rutarea folosita pentru aceasta solutie este dinamica cu BGP, CPE-urile din fiecare locatie primesc rutele prin intermediul protocolului de routare BGP.

Dialer-Watch-ul de pe CPE va urmari o ruta unica reprezentata de un IP de loopback (CPE-ul va urmari doar IP-ul loopback-ului anuntat din 7206vpdn) .Atunci cand linkul principal se intrerupe, Dialer-Watch-ul nu mai vede in tabela de rutare aceasta ruta iar CPE-ul (sursa) va comuta pe BackUp, sunand la numarul 0870111111, in access serverul din regiune. Access Server-ul (LAC) va deschide un tunel pe PE-ul 7206 local, iar acesta va deschide un tunel pana in 7206vpdn Bucuresti, unde se va si inchide PPP-ul.7206vpdn va ruta apoi traficul de backup catre PE-ul la care este conectat CPE-ul de destinatie.

Userul alocat pentru conectare va fi unic pentru fiecare locatie. Username-ul va fi compus din judet_nume_locatie@client.ro. Parola va fi test , iar domeniul va fi client.ro.


Se va testa pierderea legaturii prin linkul principal si activarea liniei ISDN ca linie de backup.

Se intrerupe linkul principal si se va verifica activarea linkului de bkp pe ISDN in momentul pierderii legaturii cu ruta 1.1.1.1 255.255.255.255 (IP-ul loopback-ului anuntat din 7206vpdn).

Se verifica ridicarea tunelului VPDN initiat de LAC si inchis pe LNS, se vor porni in paralel debuguri pentru vizualizarea negocierii si ridicarii tunelului L2TP intre LAC si 7206 respectiv intre 7206 si LNS (7206vpdn)


7206local#show debugging


VPN:

L2X protocol events debugging is on

L2X data packets debugging is on

L2X control packets debugging is on

VPDN events debugging is on

VPDN packet debugging is on


7206vpdn# show debugging


VPN:

L2X protocol events debugging is on

L2X data packets debugging is on

L2X control packets debugging is on

VPDN events debugging is on

VPDN packet debugging is on


Se verifica conectivitatea CPE – LNS si apoi activarea sesiunii bgp pe CPE cu loopbackul din LNS.

In paralel cu aceste operatii se va porni pe CPE un ping catre HQ si se va observa intreruperea din momentul deconectarii linkului principal pana la activarea automata a linkului de backup.



Pasi:



- se simuleaza intreruperea linkului principal – se pune in showut sesiunea BGP prin link principal :


Locatie_test#

Jun 7 23:31:35.329 Buc: %BGP-5-ADJCHANGE: neighbor 192.168.53.37 Down Admin. showutdown

Jun 7 23:31:35.547 Buc: %BGP-5-ADJCHANGE: neighbor 192.168.53.38 vpn vrf Testare Down Peer closed the session


Locatie_test#show ip bgp summary

BGP router identifier 172.18.63.5, local AS number 65303

BGP table version is 1950, main routing table version 1950

1 network entries using 120 bytes of memory

1 path entries using 52 bytes of memory

5/2 BGP path/bestpath attribute entries using 620 bytes of memory

2 BGP AS-PATH entries using 48 bytes of memory

0 BGP route-map cache entries using 0 bytes of memory

0 BGP filter-list cache entries using 0 bytes of memory

Bitfield cache entries: current 1 (at peak 2) using 28 bytes of memory

BGP using 868 total bytes of memory

BGP activity 559/464 prefixes, 1193/1192 paths, scan interval 60 secs


Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd

4 9050 98 91 0 0 0 1d20h Idle

4 9050 224156 248177 0 0 0 00:00:03 Idle (Admin)



- pe CPE s-au pornit urmatoarele debuguri:


Locatie_test#show debugging

VPN:

VPDN events debugging is on


The following ISDN debugs are enabled on all DSLs:


debug isdn error is ON.

debug isdn event is ON.


-se observa cum se activeaza automat linkul secundar la simularea intreruperii linkului principal datorita dialer-watch:


Locatie_test#

Jun 7 23:31:35.329 Buc: %BGP-5-ADJCHANGE: neighbor 192.168.53.37 Down Admin. showutdown

Jun 7 23:31:35.547 Buc: %BGP-5-ADJCHANGE: neighbor 192.168.53.38 vpn vrf Testare Down Peer closed the session

Jun 7 23:31:45.333 Buc: ISDN BR0 EVENT: UserIdle: callid 0x8014 received ISDN_CALL (0x0)

Jun 7 23:31:45.333 Buc: ISDN BR0 EVENT: process_bri_call: call id 0x8014, called_number 0870111111, Guid 0D5E011C802A speed 64, call type DATA, bchan -1 clng_num none

Jun 7 23:31:45.333 Buc: ISDN BR0 **ERROR**: handle_l2d_srq_mail: Layer 1 inactive

Jun 7 23:31:45.333 Buc: ISDN BR0 EVENT: handle_l2d_srq_mail: Activating Layer 1

Jun 7 23:31:45.333 Buc: ISDN BR0 EVENT: isdn_sw_cstate: State = 4, Old State = 4

Jun 7 23:31:45.537 Buc: ISDN BR0 EVENT: service_queue_from_physical_layer: Recvd L1 prim ISDN_PH_ACT_IND state is IF_ACTIVATING

Jun 7 23:31:45.537 Buc: ISDN BR0 EVENT: isdn_sw_cstate: State = 4, Old State = 4

Jun 7 23:31:47.577 Buc: %ISDN-6-LAYER2UP: Layer 2 for Interface BR0, TEI 87 changed to up

Jun 7 23:31:47.853 Buc: ISDN BR0 EVENT: process_rxstate: ces/callid 1/0x8014 calltype 1 HOST_INFORMATION

Jun 7 23:31:47.941 Buc: ISDN BR0 EVENT: process_rxstate: ces/callid 1/0x8014 calltype 1 HOST_PROCEEDING

Jun 7 23:31:48.345 Buc: ISDN BR0 EVENT: process_rxstate: ces/callid 1/0x8014 calltype 1 HOST_CONNECT

Jun 7 23:31:48.345 Buc: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up

Jun 7 23:31:48.345 Buc: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 0870111111 N/A

Jun 7 23:31:48.469 Buc: %LINK-3-UPDOWN: Interface Virtual-Access2, changed state to up

Jun 7 23:31:48.565 Buc: %BGP-5-ADJCHANGE: neighbor 172.18.63.1 Up

Jun 7 23:31:49.465 Buc: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state to up

Jun 7 23:31:49.469 Buc: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access2, changed state to up

Locatie_test#

Locatie_test#

Locatie_test#show isdn active


ISDN ACTIVE CALLS


Call Calling Called Remote Seconds Seconds Seconds Charges

Type Number Number Name Used Left Idle Units/Currency


Out ---N/A--- 0870111111 5400ag 18 Unavail - 0



Observam ca s-a ridicat si sesiunea bgp prin backup si s-au invatat si prefixe:


Locatie_test#show ip bgp summary

BGP router identifier 172.18.63.5, local AS number 65303

BGP table version is 2626, main routing table version 2626

49 network entries using 5880 bytes of memory

50 path entries using 2600 bytes of memory

4/3 BGP path/bestpath attribute entries using 496 bytes of memory

2 BGP AS-PATH entries using 48 bytes of memory

0 BGP route-map cache entries using 0 bytes of memory

0 BGP filter-list cache entries using 0 bytes of memory

Bitfield cache entries: current 1 (at peak 2) using 32 bytes of memory

BGP using 9056 total bytes of memory

BGP activity 749/700 prefixes, 1625/1575 paths, scan interval 60 secs


Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd

4 9050 132 118 2626 0 0 00:09:07 49

192.168.53.37 4 9050 224224 248226 0 0 0 00:09:20 Idle (Admin)


se observa tunelul initiat de LAC si terminat in LNS:


Pe LAC:






5400ag#show vpdn tunnel


L2TP Tunnel Information Total tunnels 1 sessions 1

LocID RemID Remote Name State Remote Address Port Sessions VPDN Group

34587 8402 7206local est 193.231.103.x 1701 1 VPDN


%No active L2F tunnels


%No active PPTP tunnels


Pe 7206 local :


7206local#show vpdn tun


7206local#show vpdn tunnel


L2TP Tunnel Information Total tunnels 2 sessions 2


LocID RemID Remote Name State Remote Address Port Sessions VPDN Group

8402 34587 LAC est 86.34.90.7 1701 1 1

23899 36701 7206vpdn est 172.18.63.1 1701 1 9


%No active L2F tunnels


%No active PPTP tunnels


Pe LNS :


7206vpdn#show vpdn tunnel


L2TP Tunnel Information Total tunnels 1 sessions 1


LocID RemID Remote Name State Remote Address Port Sessions VPDN Group

36701 23899 PE6 est 172.18.63.4 1701 1 15


%No active L2F tunnels


%No active PPTP tunnels


Se observa pe CPE ca s-a pierdut conectivitatea timp de 30 de secunde (15 pachete x 2 secunde- intervalul timeout) – timpul enable-timeout, timp in care dialer-ul observa ca a disparut ruta generate de loopback-ul din LNS plus timpul de convergenta BGP.


Locatie_test#p 10.124.140.1 so vl 1 re 1000000


Type escape sequence to abort.

Sending 1000000, 100-byte ICMP Echos to 10.124.140.1, timeout is 2 seconds:

Packet sent with a source address of 10.124.169.1








Success rate is 96 percent (441/455), round-trip min/avg/max = 56/104/392 ms


Pe CPE s-a activat o interfata Virtual-Access2 pentru VPDN:

Locatie_test#show user

Line User Host(s) Idle Location

* 6 vty 0 generic idle 00:00:00 192.168.53.37


Interface User Mode Idle Peer Address

Vi2 MLP Bundle 00:00:02 172.18.63.1

BR0:1 Sync PPP - Bundle: Vi2


Locatie_test#show ip int brief

Interface            IP-Address OK? Method Status Protocol

FastEthernet0 unassigned YES NVRAM administratively down down

BRI0                       172.18.63.5 YES TFTP up up

BRI0:1 unassigned YES unset up up

BRI0:2                     unassigned YES unset down down

FastEthernet1 unassigned YES unset up up

FastEthernet2          unassigned YES unset up down

FastEthernet3 unassigned YES unset up down

FastEthernet4 unassigned YES unset up down

FastEthernet5 unassigned YES unset up down

FastEthernet6 unassigned YES unset up down

FastEthernet7 unassigned YES unset up down

FastEthernet8            unassigned YES unset up down

Vlan1                      10.124.169.1 YES NVRAM up up

ATM0                       unassigned YES NVRAM up up

ATM0.32                   192.168.53.38 YES NVRAM up up

Loopback0                  172.18.63.5 YES NVRAM up up

Virtual-Access1            unassigned YES unset down down

Loopback10 1.0.16.3 YES manual up up

Virtual-Access2            unassigned YES unset up up


Se studiaza si se interpreteaza debug-uri atasate


Se ridica linkul principal se observa cum se inchide automat backup-ul pe ISDN


Jun 8 00:01:52.523 Buc: %BGP-5-ADJCHANGE: neighbor 192.168.53.37 Up

Locatie_test#

Locatie_test#

Jun 8 00:01:52.544 Buc: %BGP-5-ADJCHANGE: neighbor 192.168.53.38 vpn vrf Testare Up

Locatie_test#

Jun 8 00:02:15.040 Buc: %LINK-3-UPDOWN: Interface Virtual-Access2, changed state to down

Jun 8 00:02:15.052 Buc: ISDN BR0 EVENT: UserIdle: callid 0x8014 received ISDN_HANGUP (0x1)

Jun 8 00:02:15.052 Buc: ISDN BR0 EVENT: isdn_hangup: Hangup call to call id 0x8014 ces = 1

Jun 8 00:02:15.052 Buc: %ISDN-6-DISCONNECT: Interface BRI0:1 disconnected from 0870111111 5400ag, call lasted 1826 seconds

Jun 8 00:02:15.668 Buc: ISDN BR0 EVENT: process_rxstate: ces/callid 1/0x8014 calltype 1 HOST_DISCONNECT_ACK

Jun 8 00:02:15.672 Buc: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down

Jun 8 00:02:16.036 Buc: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state to down

Jun 8 00:02:16.040 Buc: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access2, changed state to down

Jun 8 00:02:17.812 Buc: %ISDN-6-LAYER2DOWN: Layer 2 for Interface BR0, TEI 87 changed to down

Jun 8 00:02:21.380 Buc: ISDN BR0 EVENT: service_queue_from_physical_layer: Recvd L1 prim ISDN_MPH_EI1_IND state is IF_ACTIVE

Jun 8 00:02:21.880 Buc: ISDN BR0 EVENT: service_queue_from_physical_layer: Recvd L1 prim ISDN_PH_DEACT_IND state is IF_ACTIVE_EI1

Jun 8 00:02:21.880 Buc: ISDN BR0 EVENT: isdn_sw_cstate: State = 0, Old State = 4

Locatie_test#

Jun 8 00:04:52.774 Buc: %BGP-5-ADJCHANGE: neighbor 172.18.63.1 Down BGP Notification sent

Jun 8 00:04:52.774 Buc: %BGP-3-NOTIFICATION: sent to neighbor 172.18.63.1 4/0 (hold time expired) 0 bytes


Locatie_test#show ip bgp summary

BGP router identifier 172.18.63.5, local AS number 65303

BGP table version is 2727, main routing table version 2727

95 network entries using 11400 bytes of memory

95 path entries using 4940 bytes of memory

5/4 BGP path/bestpath attribute entries using 620 bytes of memory

2 BGP AS-PATH entries using 48 bytes of memory

0 BGP route-map cache entries using 0 bytes of memory

0 BGP filter-list cache entries using 0 bytes of memory

Bitfield cache entries: current 1 (at peak 2) using 32 bytes of memory

BGP using 17040 total bytes of memory

BGP activity 796/701 prefixes, 1721/1626 paths, scan interval 60 secs


Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd

172.18.63.1 4 9050 154 143 0 0 0 00:04:15 Idle











Exemplu de configuratie PE local


pentru vrf


ip vrf Testare

rd 9050:900

route-target export 9050:900

route-target import 9050:900


VPDN group


vpdn-group 1

description l2tp btw as_pit & 7206pit1

accept-dialin

protocol l2tp

virtual-template 1

terminate-from hostname LAC

source-ip 193.231.103.x

l2tp tunnel password parola


vpdn-group 9

description *** L2TP VRF tunnel between PE and CE ***

request-dialin

protocol l2tp

domain Porsche.ro

vpn vrf Testare

initiate-to ip 172.18.63.1

source-ip 172.18.63.4

local name PE6

l2tp tunnel password test


pentru interfata loopback


interface LoopbackX

description *** VPDN Locatie_test ***

ip vrf forwarding Testare

ip address 172.18.63.4 255.255.255.255



Exemplu de configuratie pe AS 5400


vpdn-group VPDN

request-dialin

protocol l2tp

domain client.ro

initiate-to ip 193.231.103.x

source-ip 86.34.90.x

local name LAC

l2tp tunnel password test



Exemplu de pe Cisco 7206 VPDN




Tunelele se vor deschide pe PE-urile locale si se vor

inchide in 7206vpdn.


aaa authentication ppp test local


ip vrf Testare

rd 9050:900

route-target export 9050:900

route-target import 9050:900



vpdn-group 15

accept-dialin

protocol l2tp

virtual-template 15

terminate-from hostname PE6

vpn vrf Testare

source-ip 172.18.63.1

local name 7206vpdn

l2tp tunnel password test


interface Virtual-Template9

ip vrf forwarding Testare

ip unnumbered Loopback19

load-interval 30

ppp authentication chap pap test

ppp multilink


username Locatie_test@client.ro password test


interface Loopback19

description *** VPDN Locatie_test ***

ip vrf forwarding Testare

ip address 172.18.63.1 255.255.255.255


interface Loopback16

description *** VPDN Locatie_test Dialer Watch ***

ip vrf forwarding Testare

ip address 1.1.1.1 255.255.255.255


router bgp 9050


address-family ipv4 vrf Testare

redistribute connected

neighbor 172.18.63.5 remote-as 65303

no auto-summary

no synchronization

exit-address-family



Exemplu de configuratie pe CPE (Cisco 1803)


interface Loopback0

ip address 172.18.63.5 255.255.255.255


interface BRI0

description *** Backup Link ***

ip unnumbered Loopback0

encapsulation ppp

load-interval 30

dialer idle-timeout 5

dialer enable-timeout 30

dialer string 0870111111

dialer load-threshowold 128 outbound

dialer watch-group 8

dialer-group 1

isdn switch-type basic-net3

isdn point-to-point-setup

no keepalive

no cdp enable

ppp authentication chap callin

ppp chap hostname Locatie_test@client.ro

ppp chap password test

ppp multilink


dialer watch-list 8 ip 1.1.1.1 255.255.255.255

dialer watch-list 8 delay connect 10

dialer watch-list 8 delay disconnect 20



Locatie_test#show version

Cisco IOS Software, C180X Software (C180X-ADVIPSERVICESK9-M), Version 12.4(11)T2, RELEASE SOFTWARE (fc4)

Technical Support: https://www.cisco.com/techsupport

Copyright (c) 1986-2007 by Cisco Systems, Inc.

Compiled Mon 30-Apr-07 14:24 by prod_rel_team


ROM: System Bootstrap, Version 12.3(8r)YH12, RELEASE SOFTWARE (fc1)


Locatie_test uptime is 24 weeks, 4 days, 7 hours, 48 minutes

System returned to ROM by Reload Command

System restarted at 13:59:04 Buc Wed Dec 17 2008

System image file is 'flashow:c180x-advipservicesk9-mz.124-11.T2.bin'



This product contains cryptographic features and is subject to United

States and local country laws governing import, export, transfer and

use. Delivery of Cisco cryptographic products does not imply

third-party authority to import, export, distribute or use encryption.

Importers, exporters, distributors and users are responsible for

compliance with U.S. and local country laws. By using this product you

agree to comply with applicable laws and regulations. If you are unable

to comply with U.S. and local laws, return this product immediately.


A summary of U.S. laws governing Cisco cryptographic products may be found at:

https://www.cisco.com/wwl/export/crypto/tool/stqrg.html


If you require further assistance please contact us by sending email to

export@cisco.com.


Cisco 1803 (MPC8500) processor (revision 0x400) with 118784K/12288K bytes of memory.

Processor board ID FCZ1202922K, with hardware revision 0000


1 DSL controller

9 FastEthernet interfaces

1 ISDN Basic Rate interface

1 ATM interface

31360K bytes of ATA CompactFlashow (Read/Write)

Configuration register is 0x2102










4.3 Analiza rezultatelor





4.3.1 Initializare tunel VPDN 7206 local



Pe 7206 local vom observa cum se va ridica tunelul initiat de lac si incheiat pe lns:


7206local#

Jun 7 23:31:48.395: VPDN CEF From tunnel: Received 170 byte pak

Jun 7 23:31:48.395: L2X: Punting to L2TP control message queue

Jun 7 23:31:48.395: VPDN CEF From tunnel: Pak consumed

Jun 7 23:31:48.395: L2X: Parse AVP 0, len 8, flag 0x8000 (M)

Jun 7 23:31:48.395: L2X: Parse SCCRQ

Jun 7 23:31:48.395: L2X: Parse AVP 2, len 8, flag 0x8000 (M)

Jun 7 23:31:48.395: L2X: Protocol Ver 256

Jun 7 23:31:48.395: L2X: Parse AVP 3, len 10, flag 0x8000 (M)

Jun 7 23:31:48.395: L2X: Framing Cap 0x0

Jun 7 23:31:48.395: L2X: Parse AVP 4, len 10, flag 0x8000 (M)

Jun 7 23:31:48.395: L2X: Bearer Cap 0x0

Jun 7 23:31:48.395: L2X: Parse AVP 6, len 8, flag 0x0

Jun 7 23:31:48.395: L2X: Firmware Ver 0x1130

Jun 7 23:31:48.395: L2X: Parse AVP 7, len 9, flag 0x8000 (M)

Jun 7 23:31:48.395: L2X: Hostname LAC

Jun 7 23:31:48.395: L2X: Parse AVP 8, len 25, flag 0x0

Jun 7 23:31:48.395: L2X: Vendor Name Cisco Systems, Inc.

Jun 7 23:31:48.395: L2X: Parse AVP 9, len 8, flag 0x8000 (M)

Jun 7 23:31:48.395: L2X: Assigned Tunnel ID 34587

Jun 7 23:31:48.395: L2X: Parse AVP 10, len 8, flag 0x8000 (M)

Jun 7 23:31:48.395: L2X: Rx Window Size 3000

Jun 7 23:31:48.395: L2X: Parse AVP 11, len 22, flag 0x8000 (M)

Jun 7 23:31:48.395: L2X: Chlng

1A F0 3F 4D DC F6 BD C8 3C AD A5 AC 4C C0 D0 48

Jun 7 23:31:48.395: L2X: No missing AVPs in SCCRQ


S-au transmis informatiile necesare pentru a se initia tunelul


Jun 7 23:31:48.395: L2X: I SCCRQ, flg TLS, ver 2, len 128, tnl 0, cl 0, ns 0, nr 0

contiguous pak, size 128

C8 02 00 80 00 00 00 00 00 00 00 00 80 08 00 00

00 00 00 01 80 08 00 00 00 02 01 00 80 0A 00 00

00 03 00 00 00 00 80 0A 00 00 00 04 00 00 00 00

00 08 00 00 00 06 11 30 80 09 00 00 00 07 4C 41


Jun 7 23:31:48.395: L2TP: I SCCRQ from LAC tnl 34587

Jun 7 23:31:48.395: Tnl 8402 L2TP: Got a challenge in SCCRQ, LAC

Jun 7 23:31:48.395: Tnl 8402 L2TP: New tunnel created for remote LAC, address 86.34.90.7

Jun 7 23:31:48.395: Tnl 8402 L2TP: O SCCRP to LAC tnlid 34587


S-a transmis raspuns la solicitare


Jun 7 23:31:48.395: Tnl 8402 L2TP: O SCCRP, flg TLS, ver 2, len 155, tnl 34587, cl 0, ns 0, nr 1

C8 02 00 9B 87 1B 00 00 00 00 00 01 80 08 00 00

00 00 00 02 80 08 00 00 00 02 01 00 80 0A 00 00

00 03 00 00 00 00 80 0A 00 00 00 04 00 00 00 00

00 08 00 00 00 06 11 20 80 0E 00 00 00 07 37 32


Jun 7 23:31:48.395: Tnl 8402 L2TP: Control channel retransmit delay set to 1 seconds

Jun 7 23:31:48.395: Tnl 8402 L2TP: Tunnel state change from idle to wait-ctl-reply

Jun 7 23:31:48.399: VPDN CEF From tunnel: Received 84 byte pak

Jun 7 23:31:48.399: L2X: Punting to L2TP control message queue

Jun 7 23:31:48.399: VPDN CEF From tunnel: Pak consumed

Jun 7 23:31:48.399: VPDN CEF From tunnel: Received 137 byte pak

Jun 7 23:31:48.399: L2X: Punting to L2TP control message queue

Jun 7 23:31:48.399: VPDN CEF From tunnel: Pak consumed

Jun 7 23:31:48.399: Tnl 8402 L2TP: Parse AVP 0, len 8, flag 0x8000 (M)

Jun 7 23:31:48.399: Tnl 8402 L2TP: Parse SCCCN

Jun 7 23:31:48.399: Tnl 8402 L2TP: Parse AVP 13, len 22, flag 0x8000 (M)

Jun 7 23:31:48.399: Tnl 8402 L2TP: Chlng Resp

FF 6A 07 50 3B B6 EF 31 FA 7B 0C 17 3C 5D AC C3

Jun 7 23:31:48.399: Tnl 8402 L2TP: No missing AVPs in SCCCN


S-a trimis solicitare de conectare.Toate informatiile necesare sunt incluse


Jun 7 23:31:48.399: Tnl 8402 L2TP: I SCCCN, flg TLS, ver 2, len 42, tnl 8402, cl 0, ns 1, nr 1

contiguous pak, size 42

C8 02 00 2A 20 D2 00 00 00 01 00 01 80 08 00 00

00 00 00 03 80 16 00 00 00 0D FF 6A 07 50 3B B6

EF 31 FA 7B 0C 17 3C 5D AC C3

Jun 7 23:31:48.399: Tnl 8402 L2TP: O ZLB ctrl ack, flg TLS, ver 2, len 12, tnl 34587, cl 0, ns 1, nr 3

C8 02 00 0C 87 1B 00 00 00 01 00 03

Jun 7 23:31:48.399: Tnl 8402 L2TP: I SCCCN from LAC tnl 34587

Jun 7 23:31:48.399: Tnl 8402 L2TP: Got a Challenge Response in SCCCN from LAC

Jun 7 23:31:48.399: Tnl 8402 L2TP: Tunnel Authentication success


S-a reusit autentificarea si tunelul este up


Jun 7 23:31:48.399: Tnl 8402 L2TP: Tunnel state change from wait-ctl-reply to established

Jun 7 23:31:48.399: Tnl 8402 L2TP: SM State established

Jun 7 23:31:48.399: Tnl 8402 L2TP: Parse AVP 0, len 8, flag 0x8000 (M)

Jun 7 23:31:48.399: Tnl 8402 L2TP: Parse ICRQ

Jun 7 23:31:48.399: Tnl 8402 L2TP: Parse AVP 14, len 8, flag 0x8000 (M)

Jun 7 23:31:48.399: Tnl 8402 L2TP: Assigned Call ID 20490

Jun 7 23:31:48.399: Tnl 8402 L2TP: Parse AVP 15, len 10, flag 0x8000 (M)

Jun 7 23:31:48.399: Tnl 8402 L2TP: Serial Number 1962420488

Jun 7 23:31:48.399: Tnl 8402 L2TP: Parse AVP 18, len 10, flag 0x8000 (M)

Jun 7 23:31:48.399: Tnl 8402 L2TP: Bearer Type 1

Jun 7 23:31:48.399: Tnl 8402 L2TP: Parse AVP 22, len 15, flag 0x8000 (M)

Jun 7 23:31:48.399: Tnl 8402 L2TP: Calling Number 248206677

Jun 7 23:31:48.399: Tnl 8402 L2TP: Parse AVP 21, len 15, flag 0x8000 (M)

Jun 7 23:31:48.399: Tnl 8402 L2TP: Called Number 870111111


Se face apel pentru initializarea sesiunii


Jun 7 23:31:48.399: Tnl 8402 L2TP: Parse Cisco AVP 100, len 17, flag 0x0

Jun 7 23:31:48.399: Tnl 8402 L2TP: Client NAS Port

53 65 72 69 61 6C 37 2F 30 3A 32

Jun 7 23:31:48.399: Tnl 8402 L2TP: No missing AVPs in ICRQ

Jun 7 23:31:48.399: Tnl 8402 L2TP: I ICRQ, flg TLS, ver 2, len 95, tnl 8402, cl 0, ns 2, nr 1

contiguous pak, size 95

C8 02 00 5F 20 D2 00 00 00 02 00 01 80 08 00 00

00 00 00 0A 80 08 00 00 00 0E 50 0A 80 0A 00 00

00 0F 74 F8 29 08 80 0A 00 00 00 12 00 00 00 01

80 0F 00 00 00 16 32 34 38 32 30 36 36 37 37 80

0F 00 00 00 15 38 37 30

Jun 7 23:31:48.399: Tnl 8402 L2TP: I ICRQ from LAC tnl 34587

Jun 7 23:31:48.399: Tnl/Sn 8402/45664 L2TP: Session FS enabled

Jun 7 23:31:48.399: Tnl/Sn 8402/45664 L2TP: Session state change from idle to wait-connect

Jun 7 23:31:48.399: Tnl/Sn 8402/45664 L2TP: New session created


S-a primit raspuns la apel


Jun 7 23:31:48.399: Tnl/Sn 8402/45664 L2TP: O ICRP to LAC 34587/20490

Jun 7 23:31:48.399: Tnl/Sn 8402/45664 L2TP: O ICRP, flg TLS, ver 2, len 28, tnl 34587, cl 20490, ns 1, nr 3

C8 02 00 1C 87 1B 50 0A 00 01 00 03 80 08 00 00

00 00 00 0B 80 08 00 00 00 0E B2 60

Jun 7 23:31:48.399: Tnl 8402 L2TP: Control channel retransmit delay set to 1 seconds

Jun 7 23:31:48.399: VPDN CEF From tunnel: Received 268 byte pak

Jun 7 23:31:48.399: L2X: Punting to L2TP control message queue

Jun 7 23:31:48.399: VPDN CEF From tunnel: Pak consumed

Jun 7 23:31:48.399: Tnl/Sn 8402/45664 L2TP: Parse AVP 0, len 8, flag 0x8000 (M)

Jun 7 23:31:48.399: Tnl/Sn 8402/45664 L2TP: Parse ICCN


Se analizeaza cererea de conexiune


Jun 7 23:31:48.399: Tnl/Sn 8402/45664 L2TP: Parse AVP 24, len 10, flag 0x8000 (M)

Jun 7 23:31:48.399: Tnl/Sn 8402/45664 L2TP: Connect Speed 64000

Jun 7 23:31:48.399: Tnl/Sn 8402/45664 L2TP: Parse AVP 38, len 10, flag 0x0

Jun 7 23:31:48.399: Tnl/Sn 8402/45664 L2TP: Rx Speed 64000

Jun 7 23:31:48.399: Tnl/Sn 8402/45664 L2TP: Parse AVP 19, len 10, flag 0x8000 (M)

Jun 7 23:31:48.399: Tnl/Sn 8402/45664 L2TP: Framing Type 1

Jun 7 23:31:48.399: Tnl/Sn 8402/45664 L2TP: Parse AVP 27, len 30, flag 0x0

Jun 7 23:31:48.399: Tnl/Sn 8402/45664 L2TP: Last Sent LCPREQ

03 05 C2 23 05 05 06 62 57 3C 86 11 04 05 F4 13


Jun 7 23:31:48.399: Tnl/Sn 8402/45664 L2TP: Parse AVP 28, len 39, flag 0x0

Jun 7 23:31:48.399: Tnl/Sn 8402/45664 L2TP: Last Rx LCPREQ

05 06 96 56 A1 2C 11 04 05 F4 13 17 01 41 47 5F

50 69 74 65 73 74 69 5F 42 64 5F 50 65 74 72 6F


Jun 7 23:31:48.399: Tnl/Sn 8402/45664 L2TP: Parse AVP 31, len 22, flag 0x0

Jun 7 23:31:48.399: Tnl/Sn 8402/45664 L2TP: Proxy Auth Chal

91 DB 33 B2 D2 94 19 08 97 F0 19 33 B6 FA 70 DF

Jun 7 23:31:48.399: Tnl/Sn 8402/45664 L2TP: Parse AVP 32, len 8, flag 0x0

Jun 7 23:31:48.399: Tnl/Sn 8402/45664 L2TP: Proxy Auth ID 107

Jun 7 23:31:48.399: Tnl/Sn 8402/45664 L2TP: Parse AVP 30, len 47, flag 0x0

Jun 7 23:31:48.399: Tnl/Sn 8402/45664 L2TP: Proxy Auth Name Locatie_test@client.ro

Jun 7 23:31:48.399: Tnl/Sn 8402/45664 L2TP: Parse AVP 33, len 22, flag 0x0

Jun 7 23:31:48.399: Tnl/Sn 8402/45664 L2TP: Proxy Auth Resp

C5 0E 48 1C 78 8D D2 AB 5E AB BB FC 94 CB 8E 9D

Jun 7 23:31:48.399: Tnl/Sn 8402/45664 L2TP: Parse AVP 29, len 8, flag 0x0

Jun 7 23:31:48.399: Tnl/Sn 8402/45664 L2TP: Proxy Auth Type 2

Jun 7 23:31:48.399: Tnl/Sn 8402/45664 L2TP: No missing AVPs in ICCN

Jun 7 23:31:48.399: Tnl/Sn 8402/45664 L2TP: I ICCN, flg TLS, ver 2, len 226, tnl 8402, cl 45664, ns 3, nr 2

contiguous pak, size 226

C8 02 00 E2 20 D2 B2 60 00 03 00 02 80 08 00 00

00 00 00 0C 80 0A 00 00 00 18 00 00 FA 00 00 0A

00 00 00 26 00 00 FA 00 80 0A 00 00 00 13 00 00

00 01 00 1E 00 00 00 1B 03 05 C2 23 05 05 06 62

57 3C 86 11 04 05 F4 13

Jun 7 23:31:48.399: Tnl/Sn 8402/45664 L2TP: O ZLB ctrl ack, flg TLS, ver 2, len 12, tnl 34587, cl 0, ns 2, nr 4

C8 02 00 0C 87 1B 00 00 00 02 00 04

Jun 7 23:31:48.399: Tnl/Sn 8402/45664 L2TP: I ICCN from LAC tnl 34587, cl 20490

Jun 7 23:31:48.399: Locatie_test Tnl/Sn 8402/45664 L2TP: Session state change from wait-connect to wait-for-service-selection

Jun 7 23:31:48.403: L2X: tunnel has tableid=11 and vrf=Testare

Jun 7 23:31:48.403: Tnl/Sn 23899/45665 L2TP: Session FS enabled


Sesiunea a fost creata


Jun 7 23:31:48.403: Tnl/Sn 23899/45665 L2TP: Session state change from idle to wait-for-tunnel

Jun 7 23:31:48.403: uid:376 Tnl/Sn 23899/45665 L2TP: Create session

Jun 7 23:31:48.403: Tnl 23899 L2TP: SM State idle

Jun 7 23:31:48.403: Tnl 23899 L2TP: O SCCRQ

Jun 7 23:31:48.403: Tnl 23899 L2TP: O SCCRQ, flg TLS, ver 2, len 128, tnl 0, cl 0, ns 0, nr 0

C8 02 00 80 00 00 00 00 00 00 00 00 80 08 00 00

00 00 00 01 80 08 00 00 00 02 01 00 80 0A 00 00

00 03 00 00 00 00 80 0A 00 00 00 04 00 00 00 00



Jun 7 23:31:48.403: Tnl 23899 L2TP: Control channel retransmit delay set to 1 seconds

Jun 7 23:31:48.403: Tnl 23899 L2TP: Tunnel state change from idle to wait-ctl-reply

Jun 7 23:31:48.403: Tnl 23899 L2TP: SM State wait-ctl-reply

Jun 7 23:31:48.423: VPDN CEF From tunnel: Received 201 byte pak

Jun 7 23:31:48.423: L2X: Punting to L2TP control message queue

Jun 7 23:31:48.423: VPDN CEF From tunnel: Pak consumed

Jun 7 23:31:48.423: Tnl 23899 L2TP: Parse AVP 0, len 8, flag 0x8000 (M)

Jun 7 23:31:48.423: Tnl 23899 L2TP: Parse SCCRP

Jun 7 23:31:48.423: Tnl 23899 L2TP: Parse AVP 2, len 8, flag 0x8000 (M)

Jun 7 23:31:48.423: Tnl 23899 L2TP: Protocol Ver 256

Jun 7 23:31:48.423: Tnl 23899 L2TP: Parse AVP 3, len 10, flag 0x8000 (M)

Jun 7 23:31:48.423: Tnl 23899 L2TP: Framing Cap 0x0

Jun 7 23:31:48.423: Tnl 23899 L2TP: Parse AVP 4, len 10, flag 0x8000 (M)

Jun 7 23:31:48.423: Tnl 23899 L2TP: Bearer Cap 0x0

Jun 7 23:31:48.423: Tnl 23899 L2TP: Parse AVP 6, len 8, flag 0x0

Jun 7 23:31:48.423: Tnl 23899 L2TP: Firmware Ver 0x1120

Jun 7 23:31:48.423: Tnl 23899 L2TP: Parse AVP 7, len 14, flag 0x8000 (M)

Jun 7 23:31:48.423: Tnl 23899 L2TP: Hostname 7206vpdn

Jun 7 23:31:48.423: Tnl 23899 L2TP: Parse AVP 8, len 25, flag 0x0

Jun 7 23:31:48.423: Tnl 23899 L2TP: Vendor Name Cisco Systems, Inc.

Jun 7 23:31:48.423: Tnl 23899 L2TP: Parse AVP 9, len 8, flag 0x8000 (M)

Jun 7 23:31:48.423: Tnl 23899 L

7206local#2TP: Assigned Tunnel ID 36701

Jun 7 23:31:48.423: Tnl 23899 L2TP: Parse AVP 10, len 8, flag 0x8000 (M)

Jun 7 23:31:48.423: Tnl 23899 L2TP: Rx Window Size 20050

Jun 7 23:31:48.423: Tnl 23899 L2TP: Parse AVP 11, len 22, flag 0x8000 (M)

Jun 7 23:31:48.423: Tnl 23899 L2TP: Chlng

E6 46 82 45 62 F9 0B F3 F8 F2 E0 9A 34 EB 8D CE

Jun 7 23:31:48.423: Tnl 23899 L2TP: Parse AVP 13, len 22, flag 0x8000 (M)

Jun 7 23:31:48.423: Tnl 23899 L2TP: Chlng Resp

B0 59 1B 60 18 A9 73 CC 02 18 2E AB 84 7E 5D 14

Jun 7 23:31:48.423: Tnl 23899 L2TP: No missing AVPs in SCCRP

Jun 7 23:31:48.423: Tnl 23899 L2TP: I SCCRP, flg TLS, ver 2, len 155, tnl 23899, cl 0, ns 0, nr 1

contiguous pak, size 155

C8 02 00 9B 5D 5B 00 00 00 00 00 01 80 08 00 00

00 00 00 02 80 08 00 00 00 02 01 00 80 0A 00 00

00 03 00 00 00 00 80 0A 00 00 00 04 00 00 00 00

00 08 00 00 00 06 11 20 80 0E 00 00 00 07 37 32

30 36 76 70 64 6E 00 19

Jun 7 23:31:48.423: Tnl 23899 L2TP: I SCCRP from 7206vpdn

Jun 7 23:31:48.423: Tnl 23899 L2TP: Got a challenge from remote peer, 7206vpdn

Jun 7 23:31:48.423: Tnl 23899 L2TP: Got a response from remote peer, 7206vpdn

Jun 7 23:31:48.423: Tnl 23899 L2TP: Tunnel Authentication success

Jun 7 23:31:48.423: Tnl 23899 L2TP: Tunnel state change from wait-ctl-reply to established

Jun 7 23:31:48.423: Tnl 23899 L2TP: O SCCCN to 7206vpdn tnlid 36701

Jun 7 23:31:48.427: Tnl 23899 L2TP: O SCCCN, flg TLS, ver 2, len 42, tnl 36701, cl 0, ns 1, nr 1

C8 02 00 2A 8F 5D 00 00 00 01 00 01 80 08 00 00

00 00 00 03 80 16 00 00 00 0D 8B 07 40 9B FA C2

74 A2 8E 72 FE 9C 99 0D 7B CC

Jun 7 23:31:48.427: Tnl 23899 L2TP: Control channel retransmit delay set to 1 seconds

Jun 7 23:31:48.427: Tnl 23899 L2TP: SM State established

Jun 7 23:31:48.427: uid:376 Tnl/Sn 23899/45665 L2TP: O ICRQ to 7206vpdn 36701/0

Jun 7 23:31:48.427: uid:376 Tnl/Sn 23899/45665 L2TP: O ICRQ, flg TLS, ver 2, len 113, tnl 36701, cl 0, ns 2, nr 1

C8 02 00 71 8F 5D 00 00 00 02 00 01 80 08 00 00

00 00 00 0A 80 08 00 00 00 0E B2 61 80 0A 00 00

00 0F F9 DF EE 37 80 0A 00 00 00 12 00 00 00 01

80 0F 00 00 00 16 32 34 38 32 30 36 36 37 37 80

0F 00 00 00 15 38 37

Jun 7 23:31:48.427: uid:376 Tnl/Sn 23899/45665 L2TP: Session state change from wait-for-tunnel to wait-reply

Jun 7 23:31:48.435: VPDN CEF From tunnel: Received 60 byte pak

Jun 7 23:31:48.435: L2X: Punting to L2TP control message queue

Jun 7 23:31:48.435: VPDN CEF From tunnel: Pak consumed

Jun 7 23:31:48.435: VPDN CEF From tunnel: Received 74 byte pak

Jun 7 23:31:48.435: L2X: Punting to L2TP control message queue

Jun 7 23:31:48.435: VPDN CEF From tunnel: Pak consumed

Jun 7 23:31:48.435: uid:376 Tnl/Sn 23899/45665 L2TP: Parse AVP 0, len 8, flag 0x8000 (M)

Jun 7 23:31:48.435: uid:376 Tnl/Sn 23899/45665 L2TP: Parse ICRP

Jun 7 23:31:48.435: uid:376 Tnl/Sn 23899/45665 L2TP: Parse AVP 14, len 8, flag 0x8000 (M)

Jun 7 23:31:48.435: uid:376 Tnl/Sn 23899/45665 L2TP: Assigned Call ID 30292

Jun 7 23:31:48.435: uid:376 Tnl/Sn 23899/45665 L2TP: No missing AVPs in ICRP

Jun 7 23:31:48.435: uid:376 Tnl/Sn 23899/45665 L2TP: I ICRP, flg TLS, ver 2, len 28, tnl 23899, cl 45665, ns 1, nr 3

contiguous pak, size 28

C8 02 00 1C 5D 5B B2 61 00 01 00 03 80 08 00 00

00 00 00 0B 80 08 00 00 00 0E 76 54

Jun 7 23:31:48.435: uid:376 Tnl/Sn 23899/45665 L2TP: O ICCN to 7206vpdn 36701/30292

Jun 7 23:31:48.435: uid:376 Tnl/Sn 23899/45665 L2TP: O ICCN, flg TLS, ver 2, len 226, tnl 36701, cl 30292, ns 3, nr 2

C8 02 00 E2 8F 5D 76 54 00 03 00 02 80 08 00 00

00 00 00 0C 80 0A 00 00 00 18 00 00 FA 00 00 0A

00 00 00 26 00 00 FA 00 80 0A 00 00 00 13 00 00

00 01 00 1E 00 00 00 1B 03 05 C2 23 05 05 06 62

57 3C 86 11 04 05 F4

Jun 7 23:31:48.435: Tnl 23899 L2TP: Control channel retransmit delay set to 1 seconds

Jun 7 23:31:48.435: uid:376 Tnl/Sn 23899/45665 L2TP: Session state change from wait-reply to established

Jun 7 23:31:48.435: uid:376 Tnl/Sn 23899/45665 L2TP: VPDN session up

Jun 7 23:31:48.435: Locatie_test Tnl/Sn 8402/45664 L2TP: Session state change from wait-for-service-selection to established

Jun 7 23:31:48.435: Locatie_test Tnl/Sn 8402/45664 L2TP: VPDN session up

Jun 7 23:31:48.447: VPDN CEF From tunnel: Received 60 byte pak

Jun 7 23:31:48.447: L2X: Punting to L2TP control message queue

Jun 7 23:31:48.447: VPDN CEF From tunnel: Pak consumed

Jun 7 23:31:48.459: VPDN CEF From tunnel: Received 62 byte pak

Jun 7 23:31:48.459: VPDN CEF Into tunnel (SSS): Sending pak

Jun 7 23:31:48.459: VPDN FS/CEF Into tunnel: Sending 44 byte pak

Jun 7 23:31:48.459: VPDN CEF Into tunnel (SSS): Pak send successful

Jun 7 23:31:48.459: uid:376 VPDN CEF From tunnel: Pak send successful

Jun 7 23:31:48.467: VPDN CEF From tunnel: Received 68 byte pak

Jun 7 23:31:48.467: VPDN CEF Into tunnel (SSS): Sending pak

Jun 7 23:31:48.467: VPDN FS/CEF Into tunnel: Sending 50 byte pak

Jun 7 23:31:48.467: VPDN CEF Into tunnel (SSS): Pak send successful

Jun 7 23:31:48.467: uid:376 VPDN CEF From tunnel: Pak send successful

Jun 7 23:31:48.475: VPDN CEF From tunnel: Received 64 byte pak

Jun 7 23:31:48.475: uid:376 VPDN CEF Into tunnel (SSS): Sending pak

Jun 7 23:31:48.475: uid:376 VPDN FS/CEF Into tunnel: Sending 50 byte pak

Jun 7 23:31:48.475: uid:376 VPDN FS/CEF Into tunnel: Sending packet to vrf with tableid=11

Jun 7 23:31:48.475: uid:376 VPDN CEF Into tunnel (SSS): Pak send successful

Jun 7 23:31:48.475: VPDN CEF From tunnel: Pak send successful

Jun 7 23:31:48.475: VPDN CEF From tunnel: Received 64 byte pak

Jun 7 23:31:48.475: uid:376 VPDN CEF Into tunnel (SSS): Sending pak

Jun 7 23:31:48.475: uid:376 VPDN FS/CEF Into tunnel: Sending 50 byte pak

Jun 7 23:31:48.475: uid:376 VPDN FS/CEF Into tunnel: Sending packet to vrf with tableid=11

Jun 7 23:31:48.475: uid:376 VPDN CEF Into tunnel (SSS): Pak send successful

Jun 7 23:31:48.475: VPDN CEF From tunnel: Pak send successful

Jun 7 23:31:48.479: VPDN CEF From tunnel: Received 68 byte pak

Jun 7 23:31:48.479: VPDN CEF Into tunnel (SSS): Sending pak

Jun 7 23:31:48.479: VPDN FS/CEF Into tunnel: Sending 50 byte pak

Jun 7 23:31:48.479: VPDN CEF Into tunnel (SSS): Pak send successful

Jun 7 23:31:48.479: uid:376 VPDN CEF From tunnel: Pak send successful

Jun 7 23:31:48.499: VPDN CEF From tunnel: Received 98 byte pak

Jun 7 23:31:48.499: uid:376 VPDN CEF Into tunnel (SSS): Sending pak

Jun 7 23:31:48.499: uid:376 VPDN FS/CEF Into tunnel: Sending 84 byte pak

Jun 7 23:31:48.499: uid:376 VPDN FS/CEF Into tunnel: Sending packet to vrf with tableid=11

Jun 7 23:31:48.499: uid:376 VPDN CEF Into tunnel (SSS): Pak send successful

Jun 7 23:31:48.499: VPDN CEF From tunnel: Pak send successful

Jun 7 23:31:48.507: VPDN CEF From tunnel: Received 102 byte pak

Jun 7 23:31:48.507: VPDN CEF Into tunnel (SSS): Sending pak

Jun 7 23:31:48.507: VPDN FS/CEF Into tunnel: Sending 84 byte pak

Jun 7 23:31:48.507: VPDN CEF Into tunnel (SSS): Pak send successful

Jun 7 23:31:48.507: uid:376 VPDN CEF From tunnel: Pak send successful

Jun 7 23:31:48.527: VPDN CEF From tunnel: Received 94 byte pak

Jun 7 23:31:48.527: uid:376 VPDN CEF Into tunnel (SSS): Sending pak

Jun 7 23:31:48.527: uid:376 VPDN FS/CEF Into tunnel: Sending 80 byte pak

Jun 7 23:31:48.527: uid:376 VPDN FS/CEF Into tunnel: Sending packet to vrf with tableid=11

Jun 7 23:31:48.527: uid:376 VPDN CEF Into tunnel (SSS): Pak send successful

Jun 7 23:31:48.527: VPDN CEF From tunnel: Pak send successful

Jun 7 23:31:48.539: VPDN CEF From tunnel: Received 139 byte pak

Jun 7 23:31:48.539: uid:376 VPDN CEF Into tunnel (SSS): Sending pak

Jun 7 23:31:48.539: uid:376 VPDN FS/CEF Into tunnel: Sending 125 byte pak

Jun 7 23:31:48.539: uid:376 VPDN FS/CEF Into tunnel: Sending packet to vrf with tableid=11

Jun 7 23:31:48.539: uid:376 VPDN CEF Into tunnel (SSS): Pak send successful

Jun 7 23:31:48.539: VPDN CEF From tunnel: Pak send successful

Jun 7 23:31:48.547: VPDN CEF From tunnel: Received 162 byte pak

Jun 7 23:31:48.547: VPDN CEF Into tunnel (SSS): Sending pak

Jun 7 23:31:48.547: VPDN FS/CEF Into tunnel: Sending 144 byte pak

Jun 7 23:31:48.547: VPDN CEF Into tunnel (SSS): Pak send successful

Jun 7 23:31:48.547: uid:376 VPDN CEF From tunnel: Pak send successful

Jun 7 23:31:48.575: VPDN CEF From tunnel: Received 113 byte pak

Jun 7 23:31:48.575: uid:376 VPDN CEF Into tunnel (SSS): Sending pak

Jun 7 23:31:48.575: uid:376 VPDN FS/CEF Into tunnel: Sending 99 byte pak

Jun 7 23:31:48.575: uid:376 VPDN FS/CEF Into tunnel: Sending packet to vrf with tableid=11

Jun 7 23:31:48.575: uid:376 VPDN CEF Into tunnel (SSS): Pak send successful

Jun 7 23:31:48.575: VPDN CEF From tunnel: Pak send successful

Jun 7 23:31:48.587: VPDN CEF From tunnel: Received 454 byte pak

Jun 7 23:31:48.587: VPDN CEF Into tunnel (SSS): Sending pak

Jun 7 23:31:48.587: VPDN FS/CEF Into tunnel: Sending 436 byte pak

Jun 7 23:31:48.587: VPDN CEF Into tunnel (SSS): Pak send successful

Jun 7 23:31:48.587: uid:376 VPDN CEF From tunnel: Pak send successful

Jun 7 23:31:48.591: VPDN CEF From tunnel: Received 146 byte pak

Jun 7 23:31:48.591: uid:376 VPDN CEF Into tunnel (SSS): Sending pak

Jun 7 23:31:48.591: uid:376 VPDN FS/CEF Into tunnel: Sending 132 byte pak

Jun 7 23:31:48.591: uid:376 VPDN FS/CEF Into tunnel: Sending packet to vrf with tableid=11

Jun 7 23:31:48.591: uid:376 VPDN CEF Into tunnel (SSS): Pak send successful

Jun 7 23:31:48.591: VPDN CEF From tunnel: Pak send successful

Jun 7 23:31:48.663: VPDN CEF From tunnel: Received 132 byte pak

Jun 7 23:31:48.663: uid:376 VPDN CEF Into tunnel (SSS): Sending pak

Jun 7 23:31:48.663: uid:376 VPDN FS/CEF Into tunnel: Sending 118 byte pak

Jun 7 23:31:48.663: uid:376 VPDN FS/CEF Into tunnel: Sending packet to vrf with tableid=11

Jun 7 23:31:48.663: uid:376 VPDN CEF Into tunnel (SSS): Pak send successful

Jun 7 23:31:48.663: VPDN CEF From tunnel: Pak send successful

Jun 7 23:31:48.795: VPDN CEF From tunnel: Received 98 byte pak

Jun 7 23:31:48.795: VPDN CEF Into tunnel (SSS): Sending pak

Jun 7 23:31:48.795: VPDN FS/CEF Into tunnel: Sending 80 byte pak

Jun 7 23:31:48.795: VPDN CEF Into tunnel (SSS): Pak send successful

Jun 7 23:31:48.795: uid:376 VPDN CEF From tunnel: Pak send successful

Jun 7 23:31:49.391: VPDN CEF From tunnel: Received 154 byte pak

Jun 7 23:31:49.391: uid:376 VPDN CEF Into tunnel (SSS): Sending pak

Jun 7 23:31:49.391: uid:376 VPDN FS/CEF Into tunnel: Sending 140 byte pak

Jun 7 23:31:49.391: uid:376 VPDN FS/CEF Into tunnel: Sending packet to vrf with tableid=11

Jun 7 23:31:49.391: uid:376 VPDN CEF Into tunnel (SSS): Pak send successful

Jun 7 23:31:49.391: VPDN CEF From tunnel: Pak send successful

Jun 7 23:31:49.435: Tnl 23899 L2TP: Control channel retransmit delay set to 1 seconds

Jun 7 23:31:49.463: VPDN CEF From tunnel: Received 70 byte pak

Jun 7 23:31:49.463: VPDN CEF Into tunnel (SSS): Sending pak

Jun 7 23:31:49.463: VPDN FS/CEF Into tunnel: Sending 52 byte pak

Jun 7 23:31:49.463: VPDN CEF Into tunnel (SSS): Pak send successful



Pachete ce se trimit pentru sustinerea tunelului sau trafic util(ping..) in vpn:


7206local#

Jun 7 23:58:37.169: VPDN CEF From tunnel: Received 70 byte pak

Jun 7 23:58:37.169: VPDN CEF Into tunnel (SSS): Sending pak

Jun 7 23:58:37.169: VPDN FS/CEF Into tunnel: Sending 52 byte pak

Jun 7 23:58:37.169: VPDN CEF Into tunnel (SSS): Pak send successful

Jun 7 23:58:37.169: uid:376 VPDN CEF From tunnel: Pak send successful

Jun 7 23:58:37.181: VPDN CEF From tunnel: Received 66 byte pak

Jun 7 23:58:37.181: uid:376 VPDN CEF Into tunnel (SSS): Sending pak

Jun 7 23:58:37.181: uid:376 VPDN FS/CEF Into tunnel: Sending 52 byte pak

Jun 7 23:58:37.181: uid:376 VPDN FS/CEF Into tunnel: Sending packet to vrf with tableid=11

7206local#

Jun 7 23:58:37.181: uid:376 VPDN CEF Into tunnel (SSS): Pak send successful

Jun 7 23:58:37.181: VPDN CEF From tunnel: Pak send successful

7206local#

Jun 7 23:58:44.989: VPDN CEF From tunnel: Received 118 byte pak

Jun 7 23:58:44.989: VPDN CEF Into tunnel (SSS): Sending pak

Jun 7 23:58:44.989: VPDN FS/CEF Into tunnel: Sending 100 byte pak

Jun 7 23:58:44.989: VPDN CEF Into tunnel (SSS): Pak send successful

Jun 7 23:58:44.989: uid:376 VPDN CEF From tunnel: Pak send successful

7206local#

Jun 7 23:58:47.409: VPDN CEF From tunnel: Received 70 byte pak

Jun 7 23:58:47.409: VPDN CEF Into tunnel (SSS): Sending pak

Jun 7 23:58:47.409: VPDN FS/CEF Into tunnel: Sending 52 byte pak

Jun 7 23:58:47.409: VPDN CEF Into tunnel (SSS): Pak send successful

Jun 7 23:58:47.409: uid:376 VPDN CEF From tunnel: Pak send successful

Jun 7 23:58:47.421: VPDN CEF From tunnel: Received 66 byte pak

Jun 7 23:58:47.421: uid:376 VPDN CEF Into tunnel (SSS): Sending pak

Jun 7 23:58:47.421: uid:376 VPDN FS/CEF Into tunnel: Sending 52 byte pak

Jun 7 23:58:47.421: uid:376 VPDN FS/CEF Into tunnel: Sending packet to vrf with tableid=11

7206local#

Jun 7 23:58:47.421: uid:376 VPDN CEF Into tunnel (SSS): Pak send successful

Jun 7 23:58:47.421: VPDN CEF From tunnel: Pak send successful

7206local#

Jun 7 23:58:49.361: VPDN CEF From tunnel: Received 113 byte pak

Jun 7 23:58:49.361: uid:376 VPDN CEF Into tunnel (SSS): Sending pak

Jun 7 23:58:49.361: uid:376 VPDN FS/CEF Into tunnel: Sending 99 byte pak

Jun 7 23:58:49.361: uid:376 VPDN FS/CEF Into tunnel: Sending packet to vrf with tableid=11

Jun 7 23:58:49.361: uid:376 VPDN CEF Into tunnel (SSS): Pak send successful

Jun 7 23:58:49.361: VPDN CEF From tunnel: Pak send successful

Jun 7 23:58:49.369: VPDN CEF From tunnel: Received 117 byte pak

Jun 7 23:58:49.369: VPDN CEF Into tunnel (SSS): Sending pak

Jun 7 23:58:49.369: VPDN FS/CEF Into tunnel: Sending 99 byte pak

7206local#

Jun 7 23:58:49.369: VPDN CEF Into tunnel (SSS): Pak send successful

Jun 7 23:58:49.369: uid:376 VPDN CEF From tunnel: Pak send successful

Jun 7 23:58:49.585: VPDN CEF From tunnel: Received 94 byte pak

Jun 7 23:58:49.585: uid:376 VPDN CEF Into tunnel (SSS): Sending pak

Jun 7 23:58:49.585: uid:376 VPDN FS/CEF Into tunnel: Sending 80 byte pak

Jun 7 23:58:49.585: uid:376 VPDN FS/CEF Into tunnel: Sending packet to vrf with tableid=11

Jun 7 23:58:49.585: uid:376 VPDN CEF Into tunnel (SSS): Pak send successful

Jun 7 23:58:49.585: VPDN CEF From tunnel: Pak send successful




Initializare tunel VPDN pe LNS



7206vpdn#

Jun 7 23:31:48.411 Buc: VPDN CEF From tunnel: Received 174 byte pak

Jun 7 23:31:48.411 Buc: L2X: Punting to L2TP control message queue

Jun 7 23:31:48.411 Buc: VPDN CEF From tunnel: Pak consumed

Jun 7 23:31:48.427 Buc: L2X: Parse AVP 0, len 8, flag 0x8000 (M)

Jun 7 23:31:48.427 Buc: L2X: Parse SCCRQ

Jun 7 23:31:48.427 Buc: L2X: Parse AVP 2, len 8, flag 0x8000 (M)

Jun 7 23:31:48.427 Buc: L2X: Protocol Ver 256

Jun 7 23:31:48.427 Buc: L2X: Parse AVP 3, len 10, flag 0x8000 (M)

Jun 7 23:31:48.427 Buc: L2X: Framing Cap 0x0

Jun 7 23:31:48.427 Buc: L2X: Parse AVP 4, len 10, flag 0x8000 (M)

Jun 7 23:31:48.427 Buc: L2X: Bearer Cap 0x0

Jun 7 23:31:48.427 Buc: L2X: Parse AVP 6, len 8, flag 0x0

Jun 7 23:31:48.427 Buc: L2X: Firmware Ver 0x1130

Jun 7 23:31:48.427 Buc: L2X: Parse AVP 7, len 9, flag 0x8000 (M)

Jun 7 23:31:48.427 Buc: L2X: Hostname PE6

Jun 7 23:31:48.427 Buc: L2X: Parse AVP 8, len 25, flag 0x0

Jun 7 23:31:48.427 Buc: L2X: Vendor Name Cisco Systems, Inc.

Jun 7 23:31:48.427 Buc: L2X: Parse AVP 9, len 8, flag 0x8000 (M)

Jun 7 23:31:48.427 Buc: L2X: Assigned Tunnel ID 23899

Jun 7 23:31:48.427 Buc: L2X: Parse AVP 10, len 8, flag 0x8000 (M)

Jun 7 23:31:48.427 Buc: L2X: Rx Window Size 20050

Jun 7 23:31:48.427 Buc: L2X: Parse AVP 11, len 22, flag 0x8000 (M)

Jun 7 23:31:48.427 Buc: L2X: Chlng

1F AE E6 61 C6 DD A4 75 D4 4A 87 38 C7 91 40 A0

Jun 7 23:31:48.427 Buc: L2X: No missing AVPs in SCCRQ

Jun 7 23:31:48.427 Buc: L2X: I SCCRQ, flg TLS, ver 2, len 128, tnl 0, cl 0, ns 0, nr 0

contiguous pak, size 128

C8 02 00 80 00 00 00 00 00 00 00 00 80 08 00 00

00 00 00 01 80 08 00 00 00 02 01 00 80 0A 00 00

00 03 00 00 00 00 80 0A 00 00 00 04 00 00 00 00



Jun 7 23:31:48.427 Buc: L2TP: I SCCRQ from PE6 tnl 23899

Jun 7 23:31:48.427 Buc: L2X: tunnel has tableid=16 and vrf=Testare

Jun 7 23:31:48.427 Buc: Tnl 36701 L2TP: Got a challenge in SCCRQ, PE6

Jun 7 23:31:48.427 Buc: Tnl 36701 L2TP: New tunnel created for remote PE6, address 172.18.63.4

Jun 7 23:31:48.427 Buc: Tnl 36701 L2TP: O SCCRP to PE6 tnlid 23899

Jun 7 23:31:48.427 Buc: Tnl 36701 L2TP: O SCCRP, flg TLS, ver 2, len 155, tnl 23899, cl 0, ns 0, nr 1

C8 02 00 9B 5D 5B 00 00 00 00 00 01 80 08 00 00

00 00 00 02 80 08 00 00 00 02 01 00 80 0A 00 00

00 03 00 00 00 00 80 0A 00 00 00 04 00 00 00 00

00 08 00 00 00 06 11 20 80 0E 00 00 00 07 37 32

30 36 76 70 64 6E 00

Jun 7 23:31:48.427 Buc: Tnl 36701 L2TP: Control channel retransmit delay set to 1 seconds

Jun 7 23:31:48.427 Buc: Tnl 36701 L2TP: Tunnel state change from idle to wait-ctl-reply

Jun 7 23:31:48.435 Buc: VPDN CEF From tunnel: Received 88 byte pak

Jun 7 23:31:48.435 Buc: L2X: Punting to L2TP control message queue

Jun 7 23:31:48.435 Buc: VPDN CEF From tunnel: Pak consumed

Jun 7 23:31:48.435 Buc: VPDN CEF From tunnel: Received 159 byte pak

Jun 7 23:31:48.435 Buc: L2X: Punting to L2TP control message queue

Jun 7 23:31:48.435 Buc: VPDN CEF From tunnel: Pak consumed

Jun 7 23:31:48.435 Buc: Tnl 36701 L2TP: Parse AVP 0, len 8, flag 0x8000 (M)

Jun 7 23:31:48.435 Buc: Tnl 36701 L2TP: Parse SCCCN

Jun 7 23:31:48.435 Buc: Tnl 36701 L2TP: Parse AVP 13, len 22, flag 0x8000 (M)

Jun 7 23:31:48.435 Buc: Tnl 36701 L2TP: Chlng Resp

8B 07 40 9B FA C2 74 A2 8E 72 FE 9C 99 0D 7B CC

Jun 7 23:31:48.435 Buc: Tnl 36701 L2TP: No missing AVPs in SCCCN

Jun 7 23:31:48.435 Buc: Tnl 36701 L2TP: I SCCCN, flg TLS, ver 2, len 42, tnl 36701, cl 0, ns 1, nr 1

contiguous pak, size 42

C8 02 00 2A 8F 5D 00 00 00 01 00 01 80 08 00 00

00 00 00 03 80 16 00 00 00 0D 8B 07 40 9B FA C2

74 A2 8E 72 FE 9C 99 0D 7B CC

Jun 7 23:31:48.435 Buc: Tnl 36701 L2TP: O ZLB ctrl ack, flg TLS, ver 2, len 12, tnl 23899, cl 0, ns 1, nr 3

C8 02 00 0C 5D 5B 00 00 00 01 00 03

Jun 7 23:31:48.435 Buc: Tnl 36701 L2TP: I SCCCN from PE6 tnl 23899

Jun 7 23:31:48.435 Buc: Tnl 36701 L2TP: Got a Challenge Response in SCCCN from PE6

Jun 7 23:31:48.435 Buc: Tnl 36701 L2TP: Tunnel Authentication success

Jun 7 23:31:48.435 Buc: Tnl 36701 L2TP: Tunnel state change from wait-ctl-reply to established

Jun 7 23:31:48.435 Buc: Tnl 36701 L2TP: SM State established

Jun 7 23:31:48.435 Buc: Tnl 36701 L2TP: Parse AVP 0, len 8, flag 0x8000 (M)

Jun 7 23:31:48.435 Buc: Tnl 36701 L2TP: Parse ICRQ

Jun 7 23:31:48.435 Buc: Tnl 36701 L2TP: Parse AVP 14, len 8, flag 0x8000 (M)

Jun 7 23:31:48.435 Buc: Tnl 36701 L2TP: Assigned Call ID 45665

Jun 7 23:31:48.435 Buc: Tnl 36701 L2TP: Parse AVP 15, len 10, flag 0x8000 (M)

Jun 7 23:31:48.435 Buc: Tnl 36701 L2TP: Serial Number -102765001

Jun 7 23:31:48.435 Buc: Tnl 36701 L2TP: Parse AVP 18, len 10, flag 0x8000 (M)

Jun 7 23:31:48.435 Buc: Tnl 36701 L2TP: Bearer Type 1

Jun 7 23:31:48.435 Buc: Tnl 36701 L2TP: Parse AVP 22, len 15, flag 0x8000 (M)

Jun 7 23:31:48.435 Buc: Tnl 36701 L2TP: Calling Number 248206677

Jun 7 23:31:48.435 Buc: Tnl 36701 L2TP: Parse AVP 21, len 15, flag 0x8000 (M)

Jun 7 23:31:48.435 Buc: Tnl 36701 L2TP: Called Number 870111111

Jun 7 23:31:48.435 Buc: Tnl 36701 L2TP: Parse Cisco AVP 100, len 17, flag 0x0

Jun 7 23:31:48.435 Buc: Tnl 36701 L2TP: Client NAS Port

53 65 72 69 61 6C 37 2F 30 3A 32

Jun 7 23:31:48.435 Buc: Tnl 36701 L2TP: Parse Cisco AVP 101, len 8, flag 0x0

Jun 7 23:31:48.435 Buc: Tnl 36701 L2TP: Hopcount 1

Jun 7 23:31:48.435 Buc: Tnl 36701 L2TP: Parse Cisco AVP 103, len 10, flag 0x0

Jun 7 23:31:48.435 Buc: Tnl 36701 L2TP: Original NAS IP Address 1445091847

Jun 7 23:31:48.435 Buc: Tnl 36701 L2TP: No missing AVPs in ICRQ

Jun 7 23:31:48.435 Buc: Tnl 36701 L2TP: I ICRQ, flg TLS, ver 2, len 113, tnl 36701, cl 0, ns 2, nr 1

contiguous pak, size 113

C8 02 00 71 8F 5D 00 00 00 02 00 01 80 08 00 00

00 00 00 0A 80 08 00 00 00 0E B2 61 80 0A 00 00

00 0F F9 DF EE 37 80 0A 00 00 00 12 00 00 00 01

80 0F 00 00 00 16 32 34 38 32 30 36 36 37 37 80

0F 00 00 00 15 38 37 30

Jun 7 23:31:48.439 Buc: Tnl 36701 L2TP: I ICRQ from PE6 tnl 23899

Jun 7 23:31:48.439 Buc: Tnl/Sn 36701/30292 L2TP: Session FS enabled

Jun 7 23:31:48.439 Buc: Tnl/Sn 36701/30292 L2TP: Session state change from idle to wait-connect

Jun 7 23:31:48.439 Buc: Tnl/Sn 36701/30292 L2TP: New session created

Jun 7 23:31:48.439 Buc: Tnl/Sn 36701/30292 L2TP: O ICRP to PE6 23899/45665

Jun 7 23:31:48.439 Buc: Tnl/Sn 36701/30292 L2TP: O ICRP, flg TLS, ver 2, len 28, tnl 23899, cl 45665, ns 1, nr 3

C8 02 00 1C 5D 5B B2 61 00 01 00 03 80 08 00 00

00 00 00 0B 80 08 00 00 00 0E 76 54

Jun 7 23:31:48.439 Buc: Tnl 36701 L2TP: Control channel retransmit delay set to 1 seconds

Jun 7 23:31:48.443 Buc: VPDN CEF From tunnel: Received 272 byte pak

Jun 7 23:31:48.443 Buc: L2X: Punting to L2TP control message queue

Jun 7 23:31:48.443 Buc: VPDN CEF From tunnel: Pak consumed

Jun 7 23:31:48.447 Buc: Tnl/Sn 36701/30292 L2TP: Parse AVP 0, len 8, flag 0x8000 (M)

Jun 7 23:31:48.447 Buc: Tnl/Sn 36701/30292 L2TP: Parse ICCN

Jun 7 23:31:48.447 Buc: Tnl/Sn 36701/30292 L2TP: Parse AVP 24, len 10, flag 0x8000 (M)

Jun 7 23:31:48.447 Buc: Tnl/Sn 36701/30292 L2TP: Connect Speed 64000

Jun 7 23:31:48.447 Buc: Tnl/Sn 36701/30292 L2TP: Parse AVP 38, len 10, flag 0x0

Jun 7 23:31:48.447 Buc: Tnl/Sn 36701/30292 L2TP: Rx Speed 64000

Jun 7 23:31:48.447 Buc: Tnl/Sn 36701/30292 L2TP: Parse AVP 19, len 10, flag 0x8000 (M)

Jun 7 23:31:48.447 Buc: Tnl/Sn 36701/30292 L2TP: Framing Type 1

Jun 7 23:31:48.447 Buc: Tnl/Sn 36701/30292 L2TP: Parse AVP 27, len 30, flag 0x0

Jun 7 23:31:48.447 Buc: Tnl/Sn 36701/30292 L2TP: Last Sent LCPREQ

03 05 C2 23 05 05 06 62 57 3C 86 11 04 05 F4 13


Jun 7 23:31:48.447 Buc: Tnl/Sn 36701/30292 L2TP: Parse AVP 28, len 39, flag 0x0

Jun 7 23:31:48.447 Buc: Tnl/Sn 36701/30292 L2TP: Last Rx LCPREQ

05 06 96 56 A1 2C 11 04 05 F4 13 17 01 41 47 5F

50 69 74 65 73 74 69 5F 42 64 5F 50 65 74 72 6F


Jun 7 23:31:48.447 Buc: Tnl/Sn 36701/30292 L2TP: Parse AVP 31, len 22, flag 0x0

Jun 7 23:31:48.447 Buc: Tnl/Sn 36701/30292 L2TP: Proxy Auth Chal

91 DB 33 B2 D2 94 19 08 97 F0 19 33 B6 FA 70 DF

Jun 7 23:31:48.447 Buc: Tnl/Sn 36701/30292 L2TP: Parse AVP 32, len 8, flag 0x0

Jun 7 23:31:48.447 Buc: Tnl/Sn 36701/30292 L2TP: Proxy Auth ID 107

Jun 7 23:31:48.451 Buc: Tnl/Sn 36701/30292 L2TP: Parse AVP 30, len 47, flag 0x0

Jun 7 23:31:48.451 Buc: Tnl/Sn 36701/30292 L2TP: Proxy Auth Name Locatie_test@client.ro

Jun 7 23:31:48.451 Buc: Tnl/Sn 36701/30292 L2TP: Parse AVP 33, len 22, flag 0x0

Jun 7 23:31:48.451 Buc: Tnl/Sn 36701/30292 L2TP: Proxy Auth Resp

C5 0E 48 1C 78 8D D2 AB 5E AB BB FC 94 CB 8E 9D

Jun 7 23:31:48.451 Buc: Tnl/Sn 36701/30292 L2TP: Parse AVP 29, len 8, flag 0x0

Jun 7 23:31:48.451 Buc: Tnl/Sn 36701/30292 L2TP: Proxy Auth Type 2

Jun 7 23:31:48.451 Buc: Tnl/Sn 36701/30292 L2TP: No missing AVPs in ICCN

Jun 7 23:31:48.451 Buc: Tnl/Sn 36701/30292 L2TP: I ICCN, flg TLS, ver 2, len 226, tnl 36701, cl 30292, ns 3, nr 2

contiguous pak, size 226

C8 02 00 E2 8F 5D 76 54 00 03 00 02 80 08 00 00

00 00 00 0C 80 0A 00 00 00 18 00 00 FA 00 00 0A

00 00 00 26 00 00 FA 00 80 0A 00 00 00 13 00 00

00 01 00 1E 00 00 00 1B 03 05 C2 23 05 05 06 62

57 3C 86 11 04 05 F4 13

Jun 7 23:31:48.451 Buc: Tnl/Sn 36701/30292 L2TP: O ZLB ctrl ack, flg TLS, ver 2, len 12, tnl 23899, cl 0, ns 2, nr 4

C8 02 00 0C 5D 5B 00 00 00 02 00 04

Jun 7 23:31:48.451 Buc: Tnl/Sn 36701/30292 L2TP: I ICCN from PE6 tnl 23899, cl 45665

Jun 7 23:31:48.451 Buc: AG_Pitesti_Bd_Petrochimistil Tnl/Sn 36701/30292 L2TP: Session state change from wait-connect to wait-for-service-selection

Jun 7 23:31:48.451 Buc: Vi12 Tnl/Sn 36701/30292 L2TP: Virtual interface created for Locatie_test@client.ro, bandwidth 64 Kbps

Jun 7 23:31:48.451 Buc: Vi12 Tnl/Sn 36701/30292 L2TP: VPDN session up

Jun 7 23:31:48.451 Buc: Vi12 Tnl/Sn 36701/30292 L2TP: Session state change from wait-for-service-selection to established

Jun 7 23:31:48.459 Buc: %LINK-3-UPDOWN: Interface Virtual-Access12, changed state to up

Jun 7 23:31:48.459 Buc: Vi12 VPDN FS Network to tunnel: Punted 44 byte pak to l2x process queue

Jun 7 23:31:48.463 Buc: Vi12 VPDN PROCESS Into tunnel: Sending 44 byte pak

Jun 7 23:31:48.463 Buc: L2X: UDP socket write 44 bytes, 172.18.63.1(1701) to 172.18.63.4(1701)

Jun 7 23:31:48.467 Buc: %LINK-3-UPDOWN: Interface Virtual-Access26, changed state to up

Jun 7 23:31:48.467 Buc: Vi12 VPDN FS/CEF Into tunnel: Sending 50 byte pak

Jun 7 23:31:48.467 Buc: Vi12 VPDN FS/CEF Into tunnel: Sending packet to vrf with tableid=16

Jun 7 23:31:48.467 Buc: Vi12 VPDN FS Network to tunnel: Pak send successful

Jun 7 23:31:48.483 Buc: VPDN CEF From tunnel: Received 68 byte pak

Jun 7 23:31:48.483 Buc: Vi12 VPDN FS Tunnel to network: Sending 14 byte pak

Jun 7 23:31:48.483 Buc: Vi12 VPDN CEF From tunnel: Pak send successful

Jun 7 23:31:48.483 Buc: Vi12 VPDN FS/CEF Into tunnel: Sending 50 byte pak

Jun

7206vpdn# 7 23:31:48.483 Buc: Vi12 VPDN FS/CEF Into tunnel: Sending packet to vrf with tableid=16

Jun 7 23:31:48.483 Buc: Vi12 VPDN FS Network to tunnel: Pak send successful

Jun 7 23:31:48.487 Buc: VPDN CEF From tunnel: Received 68 byte pak

Jun 7 23:31:48.487 Buc: Vi12 VPDN FS Tunnel to network: Sending 14 byte pak

Jun 7 23:31:48.487 Buc: Vi12 VPDN CEF From tunnel: Pak send successful

Jun 7 23:31:48.507 Buc: VPDN CEF From tunnel: Received 102 byte pak

Jun 7 23:31:48.507 Buc: Vi12 VPDN FS Tunnel to network: Sending 48 byte pak

Jun 7 23:31:48.507 Buc: Vi12 VPDN CEF From tunnel: Pak send successful

Jun 7 23:31:48.507 Buc: Vi12 VPDN FS/CEF Into tunnel: Sending 84 byte pak

Jun 7 23:31:48.507 Buc: Vi12 VPDN FS/CEF Into tunnel: Sending packet to vrf with tableid=16

Jun 7 23:31:48.507 Buc: Vi12 VPDN FS Network to tunnel: Pak send successful

Jun 7 23:31:48.535 Buc: VPDN CEF From tunnel: Received 98 byte pak

Jun 7 23:31:48.535 Buc: Vi12 VPDN FS Tunnel to network: Sending 44 byte pak

Jun 7 23:31:48.535 Buc: Vi12 VPDN CEF From tunnel: Pak send successful

Jun 7 23:31:48.547 Buc: VPDN CEF From tunnel: Received 143 byte pak

Jun 7 23:31:48.547 Buc: Vi12 VPDN FS Tunnel to network: Sending 89 byte pak

Jun 7 23:31:48.547 Buc: Vi12 VPDN CEF From tunnel: Pak send successful

Jun 7 23:31:48.547 Buc: Vi12 VPDN FS/CEF Into tunnel: Sending 144 byte pak

Jun 7 23:31:48.547 Buc: Vi12 VPDN FS/CEF Into tunnel: Sending packet to vrf with tableid=16

Jun 7 23:31:48.547 Buc: Vi12 VPDN FS Network to tunnel: Pak send successful

Jun 7 23:31:48.587 Buc: VPDN CEF From tunnel: Received 117 byte pak

Jun 7 23:31:48.587 Buc: Vi12 VPDN FS Tunnel to network: Sending 63 byte pak

Jun 7 23:31:48.587 Buc: Vi12 VPDN CEF From tunnel: Pak send successful

Jun 7 23:31:48.587 Buc: %BGP-5-ADJCHANGE: neighbor 172.18.63.5 vpn vrf Testare Up

Jun 7 23:31:48.587 Buc: Vi12 VPDN FS/CEF Into tunnel: Sending 436 byte pak

Jun 7 23:31:48.587 Buc: Vi12 VPDN FS/CEF Into tunnel: Sending packet to vrf with tableid=16

Jun 7 23:31:48.587 Buc: Vi12 VPDN FS Network to tunnel: Pak send successful

Jun 7 23:31:48.599 Buc: VPDN CEF From tunnel: Received 150 byte pak

Jun 7 23:31:48.599 Buc: Vi12 VPDN FS Tunnel to network: Sending 96 byte pak

Jun 7 23:31:48.599 Buc: Vi12 VPDN CEF From tunnel: Pak send successful

Jun 7 23:31:48.675 Buc: VPDN CEF From tunnel: Received 136 byte pak

Jun 7 23:31:48.675 Buc: Vi12 VPDN FS Tunnel to network: Sending 82 byte pak

Jun 7 23:31:48.675 Buc: Vi12 VPDN CEF From tunnel: Pak send successful

Jun 7 23:31:48.799 Buc: Vi12 VPDN FS/CEF Into tunnel: Sending 80 byte pak

Jun 7 23:31:48.799 Buc: Vi12 VPDN FS/CEF Into tunnel: Sending packet to vrf with tableid=16

Jun 7 23:31:48.799 Buc: Vi12 VPDN FS Network to tunnel: Pak send successful

Jun 7 23:31:49.399 Buc: VPDN CEF From tunnel: Received 158 byte pak

Jun 7 23:31:49.399 Buc: Vi12 VPDN FS Tunnel to network: Sending 104 byte pak

Jun 7 23:31:49.399 Buc: Vi12 VPDN CEF From tunnel: Pak send successful

Jun 7 23:31:49.459 Buc: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access12, changed state to up

Jun 7 23:31:49.467 Buc: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access26, changed state to up

7206vpdn#

Jun 7 23:31:49.467 Buc: Vi12 VPDN FS Network to tunnel: Punted 52 byte pak to l2x process queue

Jun 7 23:31:49.467 Buc: Vi12 VPDN PROCESS Into tunnel: Sending 52 byte pak

Jun 7 23:31:49.467 Buc: L2X: UDP socket write 52 bytes, 172.18.63.1(1701) to 172.18.63.4(1701)

Jun 7 23:31:49.483 Buc: VPDN CEF From tunnel: Received 70 byte pak

Jun 7 23:31:49.483 Buc: Vi12 VPDN FS Tunnel to network: Sending 16 byte pak

Jun 7 23:31:49.483 Buc: Vi12 VPDN CEF From tunnel: Pak send successful

7206vpdn#

Jun 7 23:31:51.399 Buc: VPDN CEF From tunnel: Received 158 byte pak

Jun 7 23:31:51.399 Buc: Vi12 VPDN FS Tunnel to network: Sending 104 byte pak

Jun 7 23:31:51.399 Buc: Vi12 VPDN CEF From tunnel: Pak send successful

7206vpdn#

Jun 7 23:31:53.399 Buc: VPDN CEF From tunnel: Received 158 byte pak

Jun 7 23:31:53.399 Buc: Vi12 VPDN FS Tunnel to network: Sending 104 byte pak

Jun 7 23:31:53.399 Buc: Vi12 VPDN CEF From tunnel: Pak send successful

7206vpdn#

Jun 7 23:31:55.399 Buc: VPDN CEF From tunnel: Received 158 byte pak

Jun 7 23:31:55.403 Buc: Vi12 VPDN FS Tunnel to network: Sending 104 byte pak

Jun 7 23:31:55.403 Buc: Vi12 VPDN CEF From tunnel: Pak send successful

7206vpdn#

Jun 7 23:31:57.399 Buc: VPDN CEF From tunnel: Received 158 byte pak

Jun 7 23:31:57.399 Buc: Vi12 VPDN FS Tunnel to network: Sending 104 byte pak

Jun 7 23:31:57.403 Buc: Vi12 VPDN CEF From tunnel: Pak send successful

7206vpdn#

Jun 7 23:31:59.399 Buc: VPDN CEF From tunnel: Received 158 byte pak

Jun 7 23:31:59.399 Buc: Vi12 VPDN FS Tunnel to network: Sending 104 byte pak

Jun 7 23:31:59.399 Buc: Vi12 VPDN CEF From tunnel: Pak send successful

Jun 7 23:31:59.707 Buc: Vi12 VPDN FS Network to tunnel: Punted 52 byte pak to l2x process queue

Jun 7 23:31:59.707 Buc: Vi12 VPDN PROCESS Into tunnel: Sending 52 byte pak

Jun 7 23:31:59.707 Buc: L2X: UDP socket write 52 bytes, 172.18.63.1(1701) to 172.18.63.4(1701)

Jun 7 23:31:59.723 Buc: VPDN CEF From tunnel: Received 70 byte pak

Jun 7 23:31:59.723 Buc: Vi12 VPDN FS Tunnel to network: Sending 16 byte pak

7206vpdn#

Jun 7 23:31:59.723 Buc: Vi12 VPDN CEF From tunnel: Pak send successful

7206vpdn#

Jun 7 23:32:00.847 Buc: VPDN CEF From tunnel: Received 117 byte pak

Jun 7 23:32:00.847 Buc: Vi12 VPDN FS Tunnel to network: Sending 63 byte pak

Jun 7 23:32:00.847 Buc: Vi12 VPDN CEF From tunnel: Pak send successful

Jun 7 23:32:00.847 Buc: Vi12 VPDN FS/CEF Into tunnel: Sending 80 byte pak

Jun 7 23:32:00.847 Buc: Vi12 VPDN FS/CEF Into tunnel: Sending packet to vrf with tableid=16

Jun 7 23:32:00.847 Buc: Vi12 VPDN FS Network to tunnel: Pak send successful

Jun 7 23:32:01.399 Buc: VPDN CEF From tunnel: Received 158 byte pak

Jun 7 23:32:01.399 Buc: Vi12 VPDN FS Tunnel to network: Sending 104 byte pak

Jun 7 23:32:01.399 Buc: Vi12 VPDN CEF From tunnel: Pak send successful

7206vpdn#

Jun 7 23:32:03.399 Buc: VPDN CEF From tunnel: Received 158 byte pak

Jun 7 23:32:03.399 Buc: Vi12 VPDN FS Tunnel to network: Sending 104 byte pak

Jun 7 23:32:03.399 Buc: Vi12 VPDN CEF From tunnel: Pak send successful

Jun 7 23:32:03.503 Buc: Vi12 VPDN FS/CEF Into tunnel: Sending 140 byte pak

Jun 7 23:32:03.503 Buc: Vi12 VPDN FS/CEF Into tunnel: Sending packet to vrf with tableid=16

Jun 7 23:32:03.503 Buc: Vi12 VPDN FS Network to tunnel: Pak send successful

Jun 7 23:32:03.543 Buc: VPDN CEF From tunnel: Received 158 byte pak

Jun 7 23:32:03.543 Buc: Vi12 VPDN FS Tunnel to network: Sending 104 byte pak

7206vpdn#

Jun 7 23:32:03.543 Buc: Vi12 VPDN CEF From tunnel: Pak send successful

Jun 7 23:32:03.579 Buc: Vi12 VPDN FS/CEF Into tunnel: Sending 140 byte pak

Jun 7 23:32:03.579 Buc: Vi12 VPDN FS/CEF Into tunnel: Sending packet to vrf with tableid=16

Jun 7 23:32:03.579 Buc: Vi12 VPDN FS Network to tunnel: Pak send successful

Jun 7 23:32:03.619 Buc: VPDN CEF From tunnel: Received 158 byte pak

Jun 7 23:32:03.619 Buc: Vi12 VPDN FS Tunnel to network: Sending 104 byte pak

Jun 7 23:32:03.619 Buc: Vi12 VPDN CEF From tunnel: Pak send successful

Jun 7 23:32:03.691 Buc: Vi12 VPDN FS/CEF Into tunnel: Sending 140 byte pak

Jun 7 23:32:03.691 Buc: Vi12 VPDN FS/CEF Into tunnel: Sending packet to vrf with tableid=16

Jun 7 23:32:03.691 Buc: Vi12 VPDN FS Network to tunnel: Pak send successful

Jun 7 23:32:03.731 Buc: VPDN CEF From tunnel: Received 158 byte pak

Jun 7 23:32:03.731 Buc: Vi12 VPDN FS Tunnel to network: Sending 104 byte pak

Jun 7 23:32:03.731 Buc: Vi12 VPDN CEF From tunnel: Pak send successful

Jun 7 23:32:03.803 Buc: Vi12 VPDN FS/CEF Into tunnel: Sending 140 byte pak

Jun 7 23:32:03.803 Buc: Vi12 VPDN FS/CEF Into tunnel: Sending packet to vrf with tableid=16

Jun 7 23:32:03.803 Buc: Vi12 VPDN FS Network to tunnel: Pak send successful

Jun 7 23:32:03.843 Buc: VPDN CEF From tunnel: Received 158 byte pak

Jun 7 23:32:03.843 Buc: Vi12 VPDN FS Tunnel to network: Sending 104 byte pak

Jun 7 23:32:03.843 Buc: Vi12 VPDN CEF From tunnel: Pak send successful

Jun 7 23:32:03.911 Buc: Vi12 VPDN FS/CEF Into tunnel: Sending 140 byte pak

Jun 7 23:32:03.911 Buc: Vi12 VPDN FS/CEF Into tunnel: Sending packet to vrf with tableid=16

Jun 7 23:32:03.911 Buc: Vi12 VPDN FS Network to tunnel: Pak send successful

Jun 7 23:32:03.955 Buc: VPDN CEF From tunnel: Received 158 byte pak

Jun 7 23:32:03.955 Buc: Vi12 VPDN FS Tunnel to network: Sending 104 byte pak

Jun 7 23:32:03.955 Buc: Vi12 VPDN CEF From tunnel: Pak send successful

Jun 7 23:32:04.023 Buc: Vi12 VPDN FS/CEF Into tunnel: Sending 140 byte pak

Jun 7 23:32:04.023 Buc: Vi12 VPDN FS/CEF Into tunnel: Sending packet to vrf with tableid=16

Jun 7 23:32:04.023 Buc: Vi12 VPDN FS Network to tunnel: Pak send successful

Jun 7 23:32:04.063 Buc: VPDN CEF From tunnel: Received 158 byte pak

Jun 7 23:32:04.063 Buc: Vi12 VPDN FS Tunnel to network: Sending 104 byte pak

Jun 7 23:32:04.063 Buc: Vi12 VPDN CEF From tunnel: Pak send successful

Jun 7 23:32:04.099 Buc: Vi12 VPDN FS/CEF Into tunnel: Sending 140 byte pak

Jun 7 23:32:04.099 Buc: Vi12 VPDN FS/CEF Into tunnel: Sending packet to vrf with tableid=16

Jun 7 23:32:04.099 Buc: Vi12 VPDN FS Network to tunnel: Pak send successful

Jun 7 23:32:04.143 Buc: VPDN CEF From tunnel: Received 158 byte pak

Jun 7 23:32:04.143 Buc: Vi12 VPDN FS Tunnel to network: Sending 104 byte pak

Jun 7 23:32:04.143 Buc: Vi12 VPDN CEF From tunnel: Pak send successful

Jun 7 23:32:04.183 Buc: Vi12 VPDN FS/CEF Into tunnel: Sending 140 byte pak

Jun 7 23:32:04.183 Buc: Vi12 VPDN FS/CEF Into tunnel: Sending packet to vrf with tableid=16

Jun 7 23:32:04.183 Buc: Vi12 VPDN FS Network to tunnel: Pak send successful

Jun 7 23:32:04.223 Buc: VPDN CEF From tunnel: Received 158 byte pak

Jun 7 23:32:04.223 Buc: Vi12 VPDN FS Tunnel to network: Sending 104 byte pak

Jun 7 23:32:04.223 Buc: Vi12 VPDN CEF From tunnel: Pak send successful

Jun 7 23:32:04.259 Buc: Vi12 VPDN FS/CEF Into tunnel: Sending 140 byte pak

Jun 7 23:32:04.259 Buc: Vi12 VPDN FS/CEF Into tunnel: Sending packet to vrf with tableid=16

Jun 7 23:32:04.259 Buc: Vi12 VPDN FS Network to tunnel: Pak send successful

Jun 7 23:32:04.303 Buc: VPDN CEF From tunnel: Received 158 byte pak

Jun 7 23:32:04.303 Buc: Vi12 VPDN FS Tunnel to network: Sending 104 byte pak

Jun 7 23:32:04.303 Buc: Vi12 VPDN CEF From tunnel: Pak send successful

Jun 7 23:32:04.339 Buc: Vi12 VPDN FS/CEF Into tunnel: Sending 140 byte pak

Jun 7 23:32:04.339 Buc: Vi12 VPDN FS/CEF Into tunnel: Sending packet to vrf with tableid=16

Jun 7 23:32:04.339 Buc: Vi12 VPDN FS Network to tunnel: Pak send successful

Jun 7 23:32:04.383 Buc: VPDN CEF From tunnel: Received 158 byte pak

Jun 7 23:32:04.383 Buc: Vi12 VPDN FS Tunnel to network: Sending 104 byte pak

Jun 7 23:32:04.383 Buc: Vi12 VPDN CEF From tunnel: Pak send successful

Jun 7 23:32:04.419 Buc: Vi12 VPDN FS/CEF Into tunnel: Sending 140 byte pak

Jun 7 23:32:04.419 Buc: Vi12 VPDN FS/CEF Into tunnel: Sending packet to vrf with tableid=16

Jun 7 23:32:04.419 Buc: Vi12 VPDN FS Network to tunnel: Pak send successful

Jun 7 23:32:04.463 Buc: VPDN CEF From tunnel: Received 158 byte pak

Jun 7 23:32:04.463 Buc: Vi12 VPDN FS Tunnel to network: Sending 104 byte pak

Jun 7 23:32:04.463 Buc: Vi12 VPDN CEF From tunnel: Pak send successful

Jun 7 23:32:04.527 Buc: Vi12 VPDN FS/CEF Into tunnel: Sending 140 byte pak

Jun 7 23:32:04.527 Buc: Vi12 VPDN FS/CEF Into tunnel: Sending packet to vrf with tableid=16

Jun 7 23:32:04.527 Buc: Vi12 VPDN FS Network to tunnel: Pak send successful



4.3.3 Terminarea sesiunii VPDN pe ruterul 7206 local



Jun 8 00:02:15.231: VPDN CEF From tunnel: Pak consumed

Jun 8 00:02:15.231: Locatie_test Tnl/Sn 8402/45664 L2TP: Parse AVP 0, len 8, flag 0x8000 (M)

Jun 8 00:02:15.231: Locatie_test Tnl/Sn 8402/45664 L2TP: Parse CDN


Se analizeaza solicitarea de incheiere apel


Jun 8 00:02:15.231: Locatie_test Tnl/Sn 8402/45664 L2TP: Parse AVP 14, len 8, flag 0x8000 (M)

Jun 8 00:02:15.231: Locatie_test Tnl/Sn 8402/45664 L2TP: Assigned Call ID 20490

Jun 8 00:02:15.231: Locatie_test Tnl/Sn 8402/45664 L2TP: Parse AVP 1, len 10, flag 0x8000 (M)

Jun 8 00:02:15.231: Locatie_test Tnl/Sn 8402/45664 L2TP: Result code(2): 2: Call disconnected, refer to error msg

Jun 8 00:02:15.231: Error code(6): Vendor specific

Jun 8 00:02:15.231: Locatie_test Tnl/Sn 8402/45664 L2TP: Parse AVP 46, len 11, flag 0x0

Jun 8 00:02:15.231: Locatie_test Tnl/Sn 8402/45664 L2TP: disconnected, code 3, direction local for CP 0x0


S-a facut deconectarea locala


Jun 8 00:02:15.231: Locatie_test Tnl/Sn 8402/45664 L2TP: Parse Cisco AVP 104, len 11, flag 0x0

Jun 8 00:02:15.231: Locatie_test Tnl/Sn 8402/45664 L2TP: PPP Disconnect Cause Code (Cisco) Already rcvd IETF version, ignoring

Jun 8 00:02:15.231: Locatie_test Tnl/Sn 8402/45664 L2TP: No missing AVPs in CDN

Jun 8 00:02:15.231: Locatie_test Tnl/Sn 8402/45664 L2TP: I CDN, flg TLS, ver 2, len 60, tnl 8402, cl 45664, ns 4, nr 2

contiguous pak, size 60

C8 02 00 3C 20 D2 B2 60 00 04 00 02 80 08 00 00

00 00 00 0E 80 08 00 00 00 0E 50 0A 80 0A 00 00

00 01 00 02 00 06 00 0B 00 00 00 2E 00 03 00 00

02 00 0B 00 09 00 68 00 03 00 00 02

Jun 8 00:02:15.231: Locatie_test Tnl/Sn 8402/45664 L2TP: O ZLB ctrl ack, flg TLS, ver 2, len 12, tnl 34587, cl 0, ns 2, nr 5

C8 02 00 0C 87 1B 00 00 00 02 00 05

Jun 8 00:02:15.231: Locatie_test Tnl/Sn 8402/45664 L2TP: I CDN from LAC tnl 34587, cl 20490

Jun 8 00:02:15.231: Locatie_test Tnl/Sn 8402/45664 L2TP: disconnect (L2X) IETF: 18/host-request Ascend: 66/VPDN Local PPP Disconnect

Jun 8 00:02:15.231: Locatie_test Tnl/Sn 8402/45664 L2TP: Destroying session

Jun 8 00:02:15.231: Locatie_test Tnl/Sn 8402/45664 L2TP: Session state change from established to idle

Jun 8 00:02:15.231: Locatie_test Tnl/Sn 8402/45664 L2TP: Accounting stop sent

Jun 8 00:02:15.231: Tnl 8402 L2TP: Tunnel state change from established to no-sessions-left

Jun 8 00:02:15.231: Tnl 8402 L2TP: No more sessions in tunnel, shutdown (likely) in 10 seconds


Se inchid toate sesiunile pe tunel(timp max 10 sec)


Jun 8 00:02:15.231: uid:376 Tnl/Sn 23899/45665 L2TP: O CDN to 7206vpdn 36701/30292

Jun 8 00:02:15.231: uid:376 Tnl/Sn 23899/45665 L2TP: O CDN, flg TLS, ver 2, len 60, tnl 36701, cl 30292, ns 4, nr 2

C8 02 00 3C 8F 5D 76 54 00 04 00 02 80 08 00 00

00 00 00 0E 80 08 00 00 00 0E B2 61 80 0A 00 00

00 01 00 02 00 06 00 0B 00 00 00 2E 00 03 00 00

02 00 0B 00 09 00 68 00 03 00 00 02

Jun 8 00:02:15.231: Tnl 23899 L2TP: Control channel retransmit delay set to 1 seconds

Jun 8 00:02:15.231: uid:376 Tnl/Sn 23899/45665 L2TP: Destroying session

Jun 8 00:02:15.231: uid:376 Tnl/Sn 23899/45665 L2TP: Session state change from established to idle

Jun 8 00:02:15.231: Tnl 23899 L2TP: Tunnel state change from established to no-sessions-left

Jun 8 00:02:15.231: Tnl 23899 L2TP: No more sessions in tunnel, shutdown (likely) in 15 seconds

7206local#

Jun 8 00:02:15.239: VPDN CEF From tunnel: Received 60 byte pak

Jun 8 00:02:15.239: L2X: Punting to L2TP control message queue

Jun 8 00:02:15.239: VPDN CEF From tunnel: Pak consumed

Jun 8 00:02:16.231: Tnl 23899 L2TP: Control channel retransmit delay set to 1 seconds

7206local#

Jun 8 00:02:25.231: Tnl 8402 L2TP: O StopCCN to LAC tnlid 34587

Jun 8 00:02:25.231: Tnl 8402 L2TP: O StopCCN, flg TLS, ver 2, len 38, tnl 34587, cl 0, ns 2, nr 5

C8 02 00 26 87 1B 00 00 00 02 00 05 80 08 00 00

00 00 00 04 80 08 00 00 00 09 20 D2 80 0A 00 00


Jun 8 00:02:25.231: Tnl 8402 L2TP: Control channel retransmit delay set to 1 seconds

Jun 8 00:02:25.231: Tnl 8402 L2TP: Tunnel state change from no-sessions-left to shutting-down

Jun 8 00:02:25.231: VPDN CEF From tunnel: Received 60 byte pak

Jun 8 00:02:25.231: L2X: Punting to L2TP control message queue

Jun 8 00:02:25.231: VPDN CEF From tunnel: Pak consumed

Jun 8 00:02:25.239: VPDN CEF From tunnel: Received 84 byte pak

Jun 8 00:02:25.239: L2X: Punting to L2TP control message queue

Jun 8 00:02:25.239: VPDN CEF From tunnel: Pak consumed

Jun 8 00:02:25.239: Tnl 23899 L2TP: Parse AVP 0, len 8, flag 0x8000 (M)

Jun 8 00:02:25.239: Tnl 23899 L2TP: Parse StopCCN

Jun 8 00:02:25.239: Tnl 23899 L2TP: Parse AVP 9, len 8, flag 0x8000 (M)

Jun 8 00:02:25.239: Tnl 23899 L2TP: Assigned Tunnel ID 36701

Jun 8 00:02:25.239: Tnl 23899 L2TP: Parse AVP 1, len 10, flag 0x8000 (M)

Jun 8 00:02:25.239: L2X: Result code(1): 1: Request to clear control connection

Jun 8 00:02:25.239: Error code(0): No error

Jun 8 00:02:25.239: Tnl 23899 L2TP: No missing AVPs in StopCCN

Jun 8 00:02:25.239: Tnl 23899 L2TP: I StopCCN, flg TLS, ver 2, len 38, tnl 23899, cl 0, ns 2, nr 5

contiguous pak, size 38

C8 02 00 26 5D 5B 00 00 00 02 00 05 80 08 00 00

00 00 00 04 80 08 00 00 00 09 8F 5D 80 0A 00 00


Jun 8 00:02:25.239: Tnl 23899 L2TP: O ZLB ctrl ack, flg TLS, ver 2, len 12, tnl 36701, cl 0, ns 5, nr 3

C8 02 00 0C 8F 5D 00 00 00 05 00 03

Jun 8 00:02:25.239: Tnl 23899 L2TP: I StopCCN from 7206vpdn tnl 36701

Jun 8 00:02:25.239: Tnl 23899 L2TP: Tunnel state change from no-sessions-left to shutting-down

Jun 8 00:02:25.239: Tnl 23899 L2TP: Shutdown tunnel

7206local#

Jun 8 00:02:25.239: Tnl 23899 L2TP: Tunnel state change from shutting-down to idle

Jun 8 00:02:26.231: Tnl 8402 L2TP: Control channel retransmit delay set to 1 seconds

7206local#

Jun 8 00:02:30.231: Tnl 8402 L2TP: Shutdown tunnel

Jun 8 00:02:30.231: Tnl 8402 L2TP: Tunnel state change from shutting-down to idle



4.4 Concluzii


In aceasta lucrare s-a incercat prezentarea unei retele VPDN si modul de functionare al acesteia ca o solutie de back-up pentru clientii de VPN.

Pentru lucrarea practica s-a utilizat un CPE de tip Cisco 1803, versiunea de IOS 12.4(11)T2 cu interfata g.SHDSL conectata in reteaua IP/MPLS ca linie principala si backup prin ISDN. Rutarea folosita pentru aceasta solutie este dinamica cu BGP,deoarece CPE-urile din fiecare locatie isi primesc rutele cu ajutorul protocolului de rutare BGP.Pentru a observa cum intra in functiune reteaua de VPDN vom simula o intrerupere a conexiunii principale.

Dialer Watch-ul de pe CPE este setat la 30 secunde.Acesta va urmari o ruta unica reprezentata de un IP de loopback (CPE-ul va urmari doar IP-ul loopback-ului anuntat din 7206vpdn) .Atunci cand linkul principal se intrerupe, Dialer-Watch-ul nu mai vede in tabela de rutare aceasta ruta iar CPE-ul (sursa) va comuta pe BackUp, sunand la numarul 0870111111, in access serverul din regiune. Access Server-ul (LAC) va deschide un tunel pe PE-ul 7206 local, iar acesta va deschide un tunel pana in 7206vpdn Bucuresti, unde se va si inchide PPP-ul.7206vpdn va ruta apoi traficul de backup catre PE-ul la care este conectat CPE-ul de destinatie. Userul de conectare este unic pentru fiecare locatie.

Se va testa pierderea legaturii prin linkul principal si activarea liniei ISDN ca linie de backup.

Se intrerupe linkul principal si se va verifica activarea linkului de bkp pe ISDN in momentul pierderii legaturii cu ruta 1.1.1.1 255.255.255.255 (IP-ul loopback-ului anuntat din 7206vpdn).

Se verifica ridicarea tunelului VPDN initiat de LAC si inchis pe LNS, se vor porni in paralel debuguri pentru vizualizarea negocierii si ridicarii tunelului L2TP intre LAC si 7206 respectiv intre 7206 si LNS (7206vpdn).


Se verifica conectivitatea CPE – LNS si apoi activarea sesiunii bgp pe CPE cu loopbackul din LNS.

In paralel cu aceste operatii se va porni pe CPE un ping catre HQ si se va observa intreruperea din momentul deconectarii linkului principal pana la activarea automata a linkului de backup.

Am observat apoi cum se activeaza automat linkul secundar la simularea intreruperii linkului principal datorita dialer-watch-ului.Apoi s-a ridicat si sesiunea bgp prin backup si s-au invatat si prefixe de locatii.

O retea VPDN este foarte utila in masura in care este un back-up pentru o retea VPN de mare securitate si este intotdeauna prezenta sa inlocuiasca reteaua VPN cand aceasta nu mai este functionala si este nevoie ca sa se asigure o continuitate a retelei.


BIBLIOGRAFIE



Retele de calculatoare si Internet pentru oamenii de afaceri, William Kilmer, Ed. Teora 2002, pag 82-83, 117-118;

Internet & Intranet. Concepte si aplicatii, Ion Gh. Rosca, Nicolae Tapus, Ed. Economica, 2002, pag 222, 255, 259-261;

Retele de calculatoare, Peter Norton, pag. 321-333;


CCIE Practical Studies: Security(CCIE Self-Study), Dmitry Bokotey,


Andrew G. Mason, Raymond Morrow, pag. 749-771












Copyright © Contact | Trimite referat


Ultimele referate adaugate
Mihai Beniuc
   - Mihai beniuc - „poezii"
Mihai Eminescu Mihai Eminescu
   - Mihai eminescu - student la berlin
Mircea Eliade Mircea Eliade
   - Mircea Eliade - Mioara Nazdravana (mioriţa)
Vasile Alecsandri Vasile Alecsandri
   - Chirita in provintie de Vasile Alecsandri -expunerea subiectului
Emil Girlenu Emil Girlenu
   - Dragoste de viata de Jack London
Ion Luca Caragiale Ion Luca Caragiale
   - Triumful talentului… (reproducere) de Ion Luca Caragiale
Mircea Eliade Mircea Eliade
   - Fantasticul in proza lui Mircea Eliade - La tiganci
Mihai Eminescu Mihai Eminescu
   - „Personalitate creatoare” si „figura a spiritului creator” eminescian
George Calinescu George Calinescu
   - Enigma Otiliei de George Calinescu - geneza, subiectul si tema romanului
Liviu Rebreanu Liviu Rebreanu
   - Arta literara in romanul Ion, - Liviu Rebreanu

















Scriitori romani