Frame Relay over IP (L2TPv3 / xConnect)

Curiozitatea m-a făcut să caut cum ar fi posibil de tunelat un circuit virtual PVC Frame Relay peste o simpla rețea pe IP. Ceea ce am gasit se bazează pe mecanismul de tunelare prin L2TP a cadrelor la diverse protocoale L2 cum ar fi PPP, HDLC, Frame Relay. Interesant e că prin L2TP poți tunela și frame-uri Ethernet fapt prin care poți construi simple rețele Ethernet private, un fel de VPLS (Virtual Private Lan Service) – vezi de exemplu configurația descrisă în articolul pe blog.ine.com (click aici). Sigur, astăzi, tehnologii utilizate pentru crearea de servicii de rețele suprapuse VPN sunt altele decât cea prin L2TP, in prim plan sare tehnologia MPLS cu capabilitatea AToM (Any Transport over MPLS) ce oferă aceeași idee de serviciu de transport de cadre L2 peste un backbone pe IP.

Mai jos voi descrie o configurație pe rutere Cisco în GNS pentru un PVC Frame Relay tunelat peste o rețea pe IP utilizând mecanismul bazat pe protocolul L2TPv3 (printre altele diferența dintre versiunea v3 față de v2 e că ultimul știa să tuneleze doar frame-uri PPP). Voi merge pe o descriere sumară fără a intra in detalii, pentru cei interesați de detalii recomand capitolul cu L2TP din Troubleshooting VPNs (more info).

Conexiune Frame Relay de la un router la altul (HQ to Branch) va fi configurată peste un grup de rutere interconectate prin IP. Grupul de rutere (două la număr) vor reprezenta backbone-ul pe IP a unui ISP fictiv. In general nu contează tehnologia prin care se vor interconecta routerele in interiorul ISP-ului, până la urmă cadrele FR vor fi încapsulate in pachete IP (peste L2TP) care la rândul lor pot fi transportate cu orice tehnologie L2 disponibila. Voi face ca circuitul intre rutere ISP să treacă prin Ethernet (mai jos in desen in spatele cloudului se află un circuit ethernet punct la punct între interfețele F1/0). Tunelul FR over IP prin L2TP va fi setat în configurație DLCI-to-DLCI pseudowire, cu sesiuni de control stabilite dinamic și autentificare între capete. 

FR_over_IP_via_L2TP_GNS_network_diagram

Să analizăm pe rând configurația specifică L2TP pe routerele de tunel endpoint (CE1, CE2). Descrierea o fac în raport cu liniile din configurația ilustrată mai jos.

  • Activăm CEF-ul (Cisco Express Forwarding) – linia 3
  • Configuram interfețe Loopback cu IP-ul cărora vor porni pachetele in tunelul creat prin L2TP – liniile 16,17. Fără interfețe loopback-uri se zice că pot fi probleme.
  • Configurăm un l2tp-class în cadrul căreia vom specifica parametri specifici pentru autentificare intre peer-uri. Opțional, e posibilă și o configurație fără l2tp-class sau invers de specificat și alți parametri pe lângă cei legați de autentificare.
  • Configurăm pseudowire-class – liniile 11-14, in modul de configurare a căruia specificăm: (a) încapsulare L2TP versiune 3 – linie 12 (b) asociem clasa L2TP-class creată anterior – linie 13 și (c) interfață Loopback local ca sursă de tunel – linie 14.
  • Pseudowire-ul de Frame Relay poate fi configurat fie prin DLCI-to-DLCI switching fie ca FR trunk. În primul caz routerele din capetele de tunel realizează ele însuși switching-ul Frame Relay și participă în conversații LMI (local management interface) iar in cazul cu FR trunk cadrele sunt comutate transparent peste pseudowire-ul L2TP. In exemplu vom folosi cazul cu DLCI-to-DLCI switching, pentru care: (a) activăm switching-ul Frame Relay – linie 9, (b) configurăm interfața serial cu încapsulare Frame Relay: IETF/LMI tip Cisco/intf type DCE – liniile 19-25.
  • Asociem circuitul PVC FR cu o sesiune nouă L2TPv3 session – liniile 27-28. In exemplu DLCI 371 pe interfața serial 0/0 este asociat cu o sesiune nouă L2TPv3 VCID 371 (virtual circuit ID) pentru pseudowire-ul definit anterior și care ajunge până la peer-ul (IP loopback) de la capătul opus al tunelului. 371 in linia 27 reprezintă DLCI-ul și 371 in linia 28 reprezintă VCID-ul sesiunii, nu e neapărat să coincidă, cred că pentru claritate trebuia să iau numere diferite.
  • Routing-ul in interiorul ISP-ului e configurat cu OSPF – linii 35-37. Pentru exemplu OSPF, poate fi orice alt protocol de rutare..

FR_over_IP_via_L2TP_GNS_configuration_details

Routerele HQ/BRANCH sunt configurate standard pentru transport peste circuite PVC Frame Relay (în exemplu: encapsulation Frame Relay IETTF / LMI type Cisco / static mapping): 

FR_over_IP_via_L2TP_GNS_br_hq_configuration

Odată finalizată configurația încercăm un ping de pe router-ul BRANCH pe HQ, care iată că funcționează din prima:

FR_over_IP_via_L2TP_GNS_success_ping

Imediat după, verificăm sesiunea L2TP pe unul din routere capete de tunnel. Flosim comanda show l2tun session:  

FR_over_IP_via_L2TP_GNS_show_tunnel_sessions

din care observăm singura sesiune L2TPv3 cu VCID 37.

Pe final rămâne interesant de urmărit o captură Wireshark pentru circuitul Ethernet între routerele CE1, CE2. 

FR_over_IP_via_L2TP_GNS_wireshark_capture_ethernet

din care se observă clar cum cadre FR prezentate ca HDLC (payload-ul ping-ului conține in HEX secvența ab cd .. ) sunt reîncapsulare prin L2TP în pachete noi IP – Ethernet. Wireshark-ul ne arată header HDLC în loc de Frame Relay relativ corect, header-ul FR fiind o variație la cel de HDLC.

Fișierele de configurație pe routere din topologie le puteți descărca (de aici).