Documente Academic
Documente Profesional
Documente Cultură
Proiect de diploma
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;
- 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.
Capitolul 1.VPN
1.1 Retele private virtuale
In fiecare zi prin Internet se schimba modul in care comunicam, ne informam si modul in care
se realizeaza afacerile.
Pe termen lung, diferentele dintre Internet, intraneturi si extraneturi vor fi probabil aproape
eliminate 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.
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 relat i v 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.
Reteaua externa (Internet). Internet-ul a devenit un backbone folosit din ce in ce mai des pentru
interconectarea intranet-urilor.
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.
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
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.
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.
1.2.1.3 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.
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.
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.
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.
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.
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.
1.4 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.
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.
- 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 rec ent pentru
VPN-uri este generat de Internet. Numeroase companii, in special furnizorii de servicii Internet (ISP -
Internet Service Provider) si companiile care asigura coloana 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.
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
Operatii MPLS:
1. retea virtuala : retelele par a fi separate la nivel fizic, dar de fapt nu sint deoarece se utilizeaza
aceeasi infrastructura;
2. 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.
- overlay
- peer
- 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
- 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
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 :
1. 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
2. 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.
3. 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.
5. 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.
6. 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.
8. Migrarea: MPLS VPN se pot defini pe arhitecturi multiple: IP, ATM, Frame Relay, arhitecturi
hibrid.
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 :
1. Retea provider (P network): backbone sub controlul unui Service Provider; domeniu de
retea MPLS.
3. Ruter CE (Customer Edge Router): ruter din reteaua utilizatorului care are interfata spre
ruter PE; stabileste adiancenta cu ruterele PE la care este conectat.
4. Ruter PE (Provider Edge Router) : ruter din reteaua providerului care are interfata spre un
ruter CE.
5. Legatura CE-PE : link intre ruterele PE si CE, poate fi construit pe orice tehnologie (ATM,
Frame Relay, Ethernet, PPP, tunele GRE).
6. 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.
7. 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.
8. 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
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.
9. Adresa VPN-Ipv4
- 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)
- 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
- ruterele PE importa/exporta mesaje de actualizare; fiecare VRF de la nivelul unui ruter PE are
asociata o politica de import/export
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.
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
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.
1. top label (interior label): eticheta MPLS pentru comutarea in interiorul backbone
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).
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.
In descrierea procesului de VPDN de mai jos, vom folosi nomenclatura L2TP(LAC si LNS)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
Functionalitati suplimentare
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.
interface BRI0
ip unnumbered Loopback0
encapsulation ppp
load-interval 30
dialer idle-timeout 5
dialer enable-timeout 30
dialer watch-group 8
dialer-group 1
isdn point-to-point-setup
no keepalive
no cdp enable
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 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.
vpdn-group 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
Dupa aceasta LAC-ul va prelungi sesiunea PPP pana intr-un LNS (L2TP Network Server) peste un
tunel VPDN.
- 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.
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:
1) routerul din locatia HQ a clientului VPN, atunci cand aceasta locatie are o alta solutie de backup
decat VPDN
2) 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.
vpdn-group 1
accept-dialin
protocol l2tp
virtual-template 1
terminate-from hostname PE
source-ip 192.168.100.1
interface Virtual-Template1
ip unnumbered Loopback0
ip nat inside
ip virtual-reassembly
load-interval 30
ppp multilink
interface Loopback0
1)
accept-dialin
protocol l2tp
source-ip 172.18.34.200
interface Virtual-Template9
ip unnumbered Loopback15
load-interval 30
ppp multilink
interface Loopback15
2)
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 :
1) 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
2) vpdn-grupul dupa care se ridica tunelul VPDN se numeste vpdn_dial.
vpdn-group vpdn_dial
accept-dialin
protocol l2tp
virtual-template 1
interface Virtual-Template1
ip unnumbered Loopback0
load-interval 30
no keepalive
ppp multilink
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
Daca virtual-acces1 se ridica, dar sesiunea BGP nu se ridica, atunci trebuie verificata partea de
configurare BGP care nu face scopul acestei prezentari.
2) Daca este UP, se face un apel de test catre numarul configurat pe BRI la dialer string:
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).
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:
LocID RemID Remote Name State Remote Address Port Sessions VPDN Group
Primul este tunelul L2TP intre LAC si 7206, iar al doilea, este prelungirea acestui tunel intre 7206
si LNS. La state apare established.
Pentru cunoscatori: exista niste debuguri utile pe 7206 care cateodata sunt utile:
7206cal1#debug vpdn ?
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
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: I ICRQ from LAC tnl 53262
Dec 3 16:02:23.573: Tnl 45604 L2TP: Tunnel state change from idle
to wait-ctl-reply
Dec 3 16:02:23.585: Tnl 45604 L2TP: Tunnel auth failed for CPE
66 84 60 61 09 08 20 45 77 8E 6D 15 F8 82 3C 52
05 93 BA 8C 8A 64 BA 8E 52 C9 4D E6 82 D8 52 AB
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 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.
Rutarea folosita pentru aceasta solutie este dinamica cu BGP, CPE-urile din fiecare locatie
primesc rutele prin intermediul protocolului de routare BGP.
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.
7206local#show debugging
VPN:
VPN:
Se verifica conectivitatea CPE – LNS si apoi activarea sesiunii bgp pe CPE cu loopbackul din LNS.
Pasi:
- se simuleaza intreruperea linkului principal – se pune in showut sesiunea BGP prin link principal :
Locatie_test#
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 debugging
VPN:
-se observa cum se activeaza automat linkul secundar la simularea intreruperii linkului principal datorita
dialer-watch:
Locatie_test#
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 EVENT: isdn_sw_cstate: State = 4, Old State = 4
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
Locatie_test#
Locatie_test#
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
Observam ca s-a ridicat si sesiunea bgp prin backup si s-au invatat si prefixe:
LocID RemID Remote Name State Remote Address Port Sessions VPDN Group
Pe 7206 local :
LocID RemID Remote Name State Remote Address Port Sessions VPDN Group
Pe LNS :
LocID RemID Remote Name State Remote Address Port Sessions VPDN Group
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.
.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Locatie_test#show user
Locatie_test#
Locatie_test#
Locatie_test#
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.668 Buc: ISDN BR0 EVENT: process_rxstate: ces/callid 1/0x8014 calltype 1
HOST_DISCONNECT_ACK
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.880 Buc: ISDN BR0 EVENT: isdn_sw_cstate: State = 0, Old State = 4
Locatie_test#
Jun 8 00:04:52.774 Buc: %BGP-3-NOTIFICATION: sent to neighbor 172.18.63.1 4/0 (hold time
expired) 0 bytes
pentru vrf
ip vrf Testare
rd 9050:900
VPDN group
vpdn-group 1
accept-dialin
protocol l2tp
virtual-template 1
source-ip 193.231.103.x
vpdn-group 9
description *** L2TP VRF tunnel between PE and CE ***
request-dialin
protocol l2tp
domain Porsche.ro
initiate-to ip 172.18.63.1
source-ip 172.18.63.4
interface LoopbackX
vpdn-group VPDN
request-dialin
protocol l2tp
domain client.ro
initiate-to ip 193.231.103.x
source-ip 86.34.90.x
inchide in 7206vpdn.
ip vrf Testare
rd 9050:900
vpdn-group 15
accept-dialin
protocol l2tp
virtual-template 15
source-ip 172.18.63.1
!
interface Virtual-Template9
ip unnumbered Loopback19
load-interval 30
ppp multilink
interface Loopback19
interface Loopback16
redistribute connected
no auto-summary
no synchronization
exit-address-family
interface Loopback0
interface BRI0
ip unnumbered Loopback0
encapsulation ppp
load-interval 30
dialer idle-timeout 5
dialer enable-timeout 30
dialer watch-group 8
dialer-group 1
isdn point-to-point-setup
no keepalive
no cdp enable
Locatie_test#show version
States and local country laws governing import, export, transfer and
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:
http://www.cisco.com/wwl/export/crypto/tool/stqrg.html
export@cisco.com.
Cisco 1803 (MPC8500) processor (revision 0x400) with 118784K/12288K bytes of memory.
1 DSL controller
9 FastEthernet interfaces
1 ATM interface
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: Parse AVP 3, len 10, flag 0x8000 (M)
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 10, len 8, flag 0x8000 (M)
Jun 7 23:31:48.395: L2X: Parse AVP 11, len 22, flag 0x8000 (M)
1A F0 3F 4D DC F6 BD C8 3C AD A5 AC 4C C0 D0 48
Jun 7 23:31:48.395: L2X: I 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
00 08 00 00 00 06 11 30 80 09 00 00 00 07 4C 41
43 00 19 00 00 00 08 43
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
30 36 70 69 74 31 00
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 137 byte pak
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 AVP 13, len 22, flag 0x8000 (M)
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: I SCCCN, flg TLS, ver 2, len 42, tnl 8402, cl 0, ns 1,
nr 1
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 state change from wait-ctl-reply to 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 AVP 14, len 8, flag 0x8000 (M)
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: Parse AVP 18, len 10, flag 0x8000 (M)
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: Parse Cisco AVP 100, len 17, flag 0x0
53 65 72 69 61 6C 37 2F 30 3A 32
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
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 state change from idle to wait-
connect
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: 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 AVP 24, len 10, flag 0x8000 (M)
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: Parse AVP 19, len 10, flag 0x8000 (M)
Jun 7 23:31:48.399: Tnl/Sn 8402/45664 L2TP: Parse AVP 27, len 30, flag 0x0
03 05 C2 23 05 05 06 62 57 3C 86 11 04 05 F4 13
09 01 35 34 30 30 61 67
Jun 7 23:31:48.399: Tnl/Sn 8402/45664 L2TP: Parse AVP 28, len 39, flag 0x0
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
63
Jun 7 23:31:48.399: Tnl/Sn 8402/45664 L2TP: Parse AVP 31, len 22, flag 0x0
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: Parse AVP 33, len 22, flag 0x0
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: I ICCN, flg TLS, ver 2, len 226, tnl 8402, cl
45664, ns 3, nr 2
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: 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
00 08 00 00 00 06 11 30 80 09 00 00 00 07 50 45
36 00 19 00 00 00 08
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.423: VPDN CEF From tunnel: Received 201 byte pak
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 AVP 2, len 8, flag 0x8000 (M)
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: Parse AVP 4, len 10, flag 0x8000 (M)
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: 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 L2TP: Parse AVP 10, len 8, flag 0x8000 (M)
Jun 7 23:31:48.423: Tnl 23899 L2TP: Parse AVP 11, len 22, flag 0x8000 (M)
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)
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: I 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 19
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 state change from wait-ctl-reply to
established
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: 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: 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 AVP 14, len 8, flag 0x8000
(M)
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
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, 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.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 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: 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: 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.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: 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.507: VPDN CEF From tunnel: Received 102 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: 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.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.547: VPDN CEF From tunnel: Received 162 byte 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.587: VPDN CEF From tunnel: Received 454 byte 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.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.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.435: Tnl 23899 L2TP: Control channel retransmit delay set to 1 seconds
Jun 7 23:31:49.463: VPDN CEF Into tunnel (SSS): Pak send successful
7206local#
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: 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
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): 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 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: 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
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.369: VPDN CEF From tunnel: Received 117 byte pak
Jun 7 23:58:49.369: VPDN CEF Into tunnel (SSS): Sending 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: 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
7206vpdn#
Jun 7 23:31:48.411 Buc: VPDN CEF From tunnel: Received 174 byte pak
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 AVP 2, len 8, flag 0x8000 (M)
Jun 7 23:31:48.427 Buc: L2X: Parse AVP 3, len 10, flag 0x8000 (M)
Jun 7 23:31:48.427 Buc: L2X: Parse AVP 4, len 10, flag 0x8000 (M)
Jun 7 23:31:48.427 Buc: L2X: Parse AVP 7, len 9, flag 0x8000 (M)
Jun 7 23:31:48.427 Buc: L2X: Parse AVP 8, len 25, flag 0x0
Jun 7 23:31:48.427 Buc: L2X: Parse AVP 9, len 8, flag 0x8000 (M)
Jun 7 23:31:48.427 Buc: L2X: Parse AVP 10, len 8, flag 0x8000 (M)
Jun 7 23:31:48.427 Buc: L2X: Parse AVP 11, len 22, flag 0x8000 (M)
1F AE E6 61 C6 DD A4 75 D4 4A 87 38 C7 91 40 A0
Jun 7 23:31:48.427 Buc: L2X: I 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
00 08 00 00 00 06 11 30 80 09 00 00 00 07 50 45
36 00 19 00 00 00 08 43
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: VPDN CEF From tunnel: Received 159 byte pak
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 AVP 13, len 22, flag 0x8000 (M)
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: 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 state change from wait-ctl-reply to
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 AVP 14, len 8, flag 0x8000 (M)
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: Parse AVP 18, len 10, flag 0x8000 (M)
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: Parse AVP 21, len 15, flag 0x8000 (M)
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: 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: I 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 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 state change from idle to
wait-connect
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.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 AVP 24, len 10, flag 0x8000
(M)
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: Parse AVP 19, len 10, flag 0x8000
(M)
Jun 7 23:31:48.447 Buc: Tnl/Sn 36701/30292 L2TP: Parse AVP 27, len 30, flag 0x0
03 05 C2 23 05 05 06 62 57 3C 86 11 04 05 F4 13
09 01 35 34 30 30 61 67
Jun 7 23:31:48.447 Buc: Tnl/Sn 36701/30292 L2TP: Parse AVP 28, len 39, flag 0x0
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
63
Jun 7 23:31:48.447 Buc: Tnl/Sn 36701/30292 L2TP: Parse AVP 31, len 22, flag 0x0
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: Parse AVP 33, len 22, flag 0x0
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: I 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 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: Vi12 Tnl/Sn 36701/30292 L2TP: Virtual interface created for
Locatie_test@client.ro, bandwidth 64 Kbps
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.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: 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
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.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.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
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 AVP 14, len 8, flag
0x8000 (M)
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: 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: 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: I CDN, flg TLS, ver 2, len 60, tnl
8402, cl 45664, ns 4, nr 2
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: Session state change from
established to idle
Jun 8 00:02:15.231: Tnl 8402 L2TP: No more sessions in tunnel, shutdown (likely) in 10
seconds
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: 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: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, 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
00 01 00 01 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.239: Tnl 23899 L2TP: Parse AVP 0, len 8, flag 0x8000 (M)
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: Parse AVP 1, len 10, flag 0x8000 (M)
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
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
00 01 00 01 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
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: 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.
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