Ce trebuie să știi despre MPLS Inter-AS L3VPN

Aurel Bohm

Senior Cisco System Engineer Security

aurel.bohm@alef.com

Este Inter-AS MPLS VPN întâlnit frecvent?

Într-o rețea de producție, care sunt variantele alese și de ce?

Multă lume crede că interconectarea MPLS L3VPN nu este foarte comună. În realitate este întâlnită foarte des, datorită necesitățiilor din zilele noastre și a marilor companii care au acoperire globală.

Principalul motiv pentru care opțiunile de interconectare au fost introduse, este pentru că în L3VPN, dacă locațiile sunt răspândite geografic, de cele mai multe ori nu vor tranzita un sigur SP (Service Provider) care poate asigura traspotul LSP (Label Switch Path) end-to-end.

Să zicem că avem o locație în București și alta în New York. În această situație, este puțin probabil să avem un singur provider care să asigure L3VPN de la o locație la alta.

Un alt motiv se întâlnește în situația în care avem nevoie de redundanță între locații. Să zicem că avem mai multe routere CE (Customer Edge) conectate la provideri diferiți, însă se dorește ca această conectivitate să fie vazută ca un singur L3VPN. În această situație, providerii de internet trebuie să agreeze unele politici de interoperabilitate pentru asigurarea schimbului de informații de rutare internă.

Cum rezolvă această situație providerii de servicii?

Principalul considerent este cât de mult control vor să aibă asupra topologiei de rețea. Sunt luate în considerare posibilitățile de schimb de rute interne între provider, însă în general nu se dorește acest lucru.

O altă necunoscută este modul în care se va face schimbul de labeluri în MPLS.

Avem trei variante pentru asigurarea schimbului de labeluri:

  • LDP/TDP - nu este fezabil, întrucât necesită adiacență IGP între provideri
  • RSVP - nu este scalabil, întrucât necesită (n*(n-1)/2) tunele
  • BGP oferă cea mai bună alternativă

Întrucât providerii deja rulează BGP, trebuie doar să activăm o nouă adresă de familie (address family), câteva opțiuni și să schimbăm puțin arhitectura, astfel încât să putem asigura sincronizarea control-plane pentru inter-as MPLS.

În RFC 4364 avem definite 3 opțiuni de interconectare în MPLS:

https://tools.ietf.org/html/rfc4364#section-10

  • Opțiunea 1 / Option A

            – Spate-in-Spate (Back-to-Back VRF Exchange)

  • Opțiunea 2 / Option B

            – VPNv4 BGP Exchange

  • Opțiunea 3 / Option C

            – Multihop VPNv4 BGP Exchange

Opțiunea 1

În multe implementări, cu toate că opțiunea 1 are aspecte negative cu privire la scalabilitate, este varianta cel mai simplu de implementat și ceea ce mulți provideri vor alege pentru interconectare.

  • Back-to-Back VRF Exchange (Option 1)

            – SPs folosesc un link per VRF

            – SP1 consideră SP2 ca un alt client CE

            – Rutare PE-CE (în realitate rutare PE-PE)

            – Nu se face schimb de labeluri, doar pachete native IPv4/IPv6

  • Pro

     – SPs anunță doar tabelele de rutare ale clienților din VRF

     – SPs controlează politica de import & export a propriului VRF

            • Route distinguishers (RD) și route targets (RT) au semnificație locală

     – Simplitatea configurării

            • Tratat ca orice alt site VPN

  • Contra

     – Necesită adiacența IGP PE-PE

     – Routerele PE-PE trebuie să aibă toate VRF-urile configurate local

            • Trebuie menținută adiacența VPNv4 cu toate PE-urile interne

            • Trebuie menținute tabelele de rutare din VRF

 Necesitatea unei conectivități per client (VRF) face ca această opțiune să nu fie scalabilă. Spre exemplu, dacă avem 10 VRF-uri, vom aveam 10 subinterfețe de interconectivitate și 10 sesiuni de control-plane, ceea ce nu este scalabil la scară largă.

Cum funcționează?

În exemplul ilustrat în figura alăturată, AS1 și AS2 vor stabili Inter-AS Option-A. După cum am menționat, legătura de interconectare dintre PE1 (R01) și PE2 (XR1) este împărțită în mai multe subinterfețe, care sunt folosite pentru stabilirea adiacențelor per VRF.

Dacă analizăm un traseu al traficului end-to-end (spre exemplu ne uităm la VRF-C unde avem rutare PE-CE asigurată de RIP în interiorul AS1), prefixele primite prin RIP de la CE (R09) sunt redistribuite în iBGP VPNv4, unde are loc procesul normal de 

schimb de labeluri. În cele din urmă, prin schimbul de informații cu VPNv4 router-refector (R02), prefixele ajung la PE1 (R01), unde sunt importate pe baza RT-ului in VRF-C.

PE1 rulează RIP în VRF-C pe subinterfața către PE2 (XR1). După cum am precizat, această adiacență este de tip PE-CE, cu toate că în realitate este PE-PE. Acesta din urmă primește prefixele originate de R09 și le redistribuie în iBGP VPNv4.

Prefixele VPNv4 ajung de la RR (XR2) la PE (R05), care le importă în VRF-C și le redistribuie în RIP către CE (R12).

Opțiunea 2

Se realizează o adiacență eBGP VPNv4 între routerele providerilor, interfața dintre provideri fiind anunțată în tabela globală de rutare.

Avem o singură sesiune eBGP (control-plane), prin intermediul cîreia se face schimbul de labeluri și se realizează LSP (Label Switch Path) de la un capăt la altul.

Treuie să avem totuși în vedere considerentele legate de route-target (RT) și de procesarea next-hop, însă aceasta este considerată varianta de mijloc din punctul de vedere al gradului de dificultate în implementare și manevrare, dar și din perspectiva scalabiliății.

  • VPNv4 eBGP Exchange (Option 2)

            – Se stabilește o adiacență eBGP VPNv4 între routerele providerilor

            – Schimbul de labeluri MPLS este asigurat prin eBGP VPNv4

            – Pe baza acestui schimb de labeluri se stabilește LSP end-to-end

Considerente

     – Filtrarea Route-Target (RT) pe edge router este implicită în BGP. Trebuie să folosim una din variantele de configurare de mai jos, pentru a permite prefixe etichetate cu extcommunity rt, pe care nu le avem configurate local.

            •  no bgp default route-target filter (ios)

            •  retain route-target all (ios-xr)

     – LSP end-to-end

            • QoS end-to-end este posibil

  • Pro

     – Nu este necesară adiacența IGP între provideri

            • IPv4 BGP deja rulează între border routers

  • Contra

     – Routerele PE-PE trebuie să aibă toată tabela VPNv4

            • Trebuie menținută adiacența VPNv4 cu toate PE-urile interne

              (sau cu VPNv4 route-reflector intern)

Cum funcționează?

Haideți să analizăm un traseu al traficului end-to-end. Spre exemplu dacă ne uităm la VRF-A, unde avem rutarea PE-CE asigurată de OSPF în interiorul AS1.

Prefixele sunt redistribuite de PE(R4) din OSPF->iBGP VPNv4 și învățate de PE1(R01) de la VPNv4 RR(R02). Acesta este procesul normal intra-as MPLS.

PE1 a realizat adiacență eBGP VPNv4 cu PE2 prin legatura de interconectare pe care este asignat subnet 10.100.0.0/24. PE1

și PE2 sunt configurate să importe prefixele ale căror RT nu sunt configurate local, astfel încât PE2 anunță în iBGP VPNv4 prefixele învățate de la AS1. Pentru a asigura LSP end-to-end pe XR trebuie să adaugăm o rută statică /32 către next-hop. Această etapă nu este necesară pe IOS, întrucât există un macro care configurează automat mpls bgp forwarding pe interfața către vecinul eBGP, astfel încât LSP este asigurat end-to-end.

PE/RR (XR2) primește prefixele și le importa în VRF-A unde sunt redistribuite în OSPF și învățate de CE(R08).

Opțiunea 3

Marea limitare în opțiunea 3 este datorată faptului că BGP nu are propriul transport, ceea ce înseamnă că trebuie să avem IGP+LDP în CORE pentru a stabili LSP între routerele providerilor. Trebuie sincronizată tabela de rutare internă pentru asigurarea unui LSP end-to-end între provideri, fără de care nu putem avea  funcționalitatea L3VPN (control-plane & data-plane).

Aceasta este varianta cea mai scalabilă, însă, de cele mai multe ori nu o întâlnim în producție, având în vedere faptul că trebuie să existe o înțelegere și un nivel ridicat de încredere între provideri cu privire la politicile de rutare.

Putem întâlni Option-C în situația în care doi provideri fuzionează, astfel încât putem avea politici separate, însă cu o agreere asupra unor informații de rutare pe care le vor schimba.

  • Multihop VPNv4 eBGP Exchange (Option 3)

            – Se stabilește adiacență VPNv4 eBGP multi-hop (nu sunt direct conectați) între route-reflector SP, care au rol de PE

            – IPv4 eBGP asigură schimbul de labeluri între SP edge

            – SPs trebuie să facă schimb de tabela de rutare internă

Considerente

     – Routerele PE trebuie să aibă rute IGP către routerul vecin PE pentru:

            • Asigurarea transportului pentru sesiunea VPNv4

            • Asigurarea labelurile de transport prin IGP

     – Label switch path este end-to-end

            • Routerele PE-PE fac schimb de labeluri prin IPv4 BGP

     – Route reflection și procesarea next-hop

  • Pro

     – Schimbul de info VPNv4 se face doar pentru acel VRF

     – Routerele VPN PE nu trebuie să mai ruleze BGP cu altcineva

  • Contra

     – SPs trebuie să facă schimb de tabela de rutare internă

            • Planul de adresare internă nu este rutabil la nivel global

            • Posibilitatea de a expune routerele interne din CORE către internet

Cum funcționează?

Pe legatura dintre PE1(R01)-PE2(XR1) din figura alăturată, se stabilește o adiacență IPv4 BGP label unicast, prin intermediul căreia se anunță adresele de loopback /32 ale terminațiilor tunelelor LSP.

Prin redistribuirea IGPBGP la border și asignarea de labeluri prin BGP, se efectuează conectivitatea necesară pentru LSP end-to-end, folosită de sesiunea eBGP VPNv4 dintre router-reflector R02 <–>XR2. Cu alte cuvinte, sesiunea eBGP VPNv4 este stabilită între RR AS1 <–>RR AS2, în timp ce transportul

către adresele de loopback ale routerelor PE din AS1-AS2 este asigurat de sesiunea IPv4 BGP + Label dintre PE1 – PE2.

Dacă analizăm traficul end-to-end spre exemplu, ne uităm la VRF-B, unde avem rutarea PE(R02)CE(R07) asigurată de EIGRP în interiorul AS1. PE/RR (R02) redistribuie EIGRP BGP VPNv4. În interiorul AS2 route-reflector (XR2) primește aceste prefixe prin adiacență eBGP VPNv4 cu route-reflector (R02) din AS1, însă cu next-hop R02.

Acesta este comportamentul implicit într-o sesiune eBGP, routerul schimbând next-hop cu adresa proprie înainte de a avertiza ruta către vecinul extern. În MPLS L3VPN next-hop este considerat MPLS endpoint, puctul de terminare al LSP.

Dacă nu intervenim asupra acestui comportament implicit, nu vom avea rutare optimă în rețea. Pentru a rezolva această situație, pe route-reflector Cisco putem aplica comanda neighbor next-hop unchanged, astfel încât eliminăm RR-ul din data-plane și folosim ruta optimă direct către originator.

În cele din urma, XR2 avertizează ruta primită de la AS1 prin iBGP VPNv4, R05 primește acest update și pe baza extcommunity RT import ruta în VRF-B, unde este avertizată prin EIGRP în urma redistribuției din BGP.