MPLS VPN

Wprowadzenie do BGP/MPLS VPN

Rozważmy korporację "Pol-Global S.A." z biurami w Warszawie i Gdańsku. Każde biuro ma własną sieć wewnętrzną, a pracownicy potrzebują dostępu do serwerów w drugim biurze. Połączenie jest realizowane przez współdzieloną infrastrukturę dostawcy usług. Pytanie dotyczy sposobu utrzymania odrębnych tablic routingu i poprawnego przekazywania ruchu wielu klientów przez ten sam rdzeń.

Wirtualna Sieć Prywatna (VPN) zapewnia logiczne połączenie oddziałów lub użytkowników przez współdzieloną sieć. Szyfrowanie zależy od zastosowanej technologii, na przykład IPsec. Sama usługa BGP/MPLS VPN zapewnia separację routingu i przekazywania, lecz nie definiuje szyfrowania payloadu. Z perspektywy użytkowników Pol-Global oba biura korzystają z jednej logicznej sieci, mimo że pakiety przechodzą przez wiele routerów dostawcy.

Dostawca może realizować VPN na wiele sposobów, w tym przez tunele IPsec. BGP/MPLS VPN warstwy 3 wykorzystuje wspólny rdzeń MPLS oraz logicznie odseparowane instancje routingu na routerach PE. Routery CE wymieniają trasy z PE, a routery P przenoszą pakiety przez rdzeń. Pozwala to obsługiwać wielu klientów przy zachowaniu osobnych tras, polityk importu i eksportu oraz etykiet używanych w płaszczyźnie danych.

Podstawowy problem: pokrywające się adresy IP

Jednym z podstawowych problemów dostawcy oferującego VPN jest nakładanie się przestrzeni adresowej. Wiele przedsiębiorstw korzysta z prywatnych zakresów opisanych w RFC 1918, między innymi $192.168.1.0/24$ i $10.0.0.0/8$. Trzeci zarezerwowany zakres to $172.16.0.0/12$. Te adresy mają znaczenie wewnątrz danej organizacji i mogą zostać użyte ponownie przez innego klienta.

Teraz rozważmy wyzwanie ISP.

• Jego klient, Pol-Global S.A., używa w swoich biurach sieci $192.168.1.0/24$.
• Jego inny klient, "Innowacyjne Rozwiązania sp. z o.o.", również używa w swoich biurach sieci $192.168.1.0/24$.

Obaj klienci korzystają z tej samej sieci ISP. Pakiet Pol-Global do $192.168.1.50$ i pakiet Innowacyjnych Rozwiązań do tego samego adresu wymagają różnych wyjść. Wspólna globalna tablica routingu nie opisuje kontekstu klienta, więc sam prefiks $192.168.1.0/24$ nie wystarcza do wyboru właściwej trasy. BGP/MPLS VPN rozwiązuje ten problem przez połączenie VRF, RD, RT i etykiet MPLS.

VRF: oddzielna instancja routingu dla klienta

Pierwszym elementem jest odizolowanie informacji routingowych klientów na routerze brzegowym dostawcy (Provider Edge, PE). Architektura BGP/MPLS VPN wykorzystuje do tego Virtual Routing and Forwarding (VRF), czyli osobną instancję routingu i przekazywania przypisaną do danego kontekstu klienta.

VRF przypisuje interfejsy, trasy i wpisy przekazywania do określonej instancji. Router PE może więc przechowywać kilka tras do tego samego prefiksu, pod warunkiem że należą one do różnych VRF. Kontekst VRF jest wybierany na podstawie interfejsu lub innego mechanizmu konfiguracji. Wpisy z VRF nie są automatycznie umieszczane w globalnej tablicy routingu.

VRF jest logiczną instancją routingu wewnątrz routera. Po dołączeniu klienta ISP tworzy dla niego dedykowany VRF na routerach PE, do których podłączone są jego lokalizacje.

• Każdy VRF ma swoją całkowicie niezależną tablicę routingu i tablicę przekazywania.
• Fizyczny interfejs łączący się z lokalizacją klienta (routerem CE) jest przypisany do VRF tego klienta.
• Aktualizacje routingowe otrzymywane od routera CE klienta są instalowane tylko w tablicy routingu tego konkretnego VRF.

VRF rozwiązuje problem pokrywających się adresów lokalnie. Router PE może posiadać trasę do $192.168.1.0/24$ w VRF_Pol-Global oraz oddzielną trasę do tego samego prefiksu w VRF_Innowacje. Każda trasa jest oceniana i używana w swoim kontekście.

RD: rozróżnianie tras VPN-IPv4

VRF-y rozwiązują problem na jednym routerze. Ale jak ten router ma ogłosić te pokrywające się trasy do innych routerów PE w rdzeniu sieci ISP? Podstawowy proces BGP wciąż nie potrafi obsłużyć dwóch identycznych prefiksów $192.168.1.0/24$.

Aby przenieść pokrywające się trasy przez BGP, PE dołącza do prefiksu 64-bitowy Rozróżniacz Tras (Route Distinguisher, RD). RD odróżnia wpisy VPN-IPv4 o takim samym prefiksie IPv4 w bazie BGP.

RD ma 64 bity i jest umieszczany przed prefiksem IPv4 w adresie VPN-IPv4. Dla pełnego adresu IPv4 część RD i adres mają łącznie 96 bitów. W zakodowanym NLRI prefiks składa się z RD umieszczonego przed prefiksem IPv4, a powiązana etykieta MPLS jest przenoszona razem z tą informacją. Wartość RD jest konfigurowana przez operatora, więc zapewnienie rozróżnialności zależy od poprawnej konfiguracji. RD jest częścią klucza trasy VPN-IPv4, lecz nie służy do podejmowania decyzji o przekazywaniu.

RT: wybór tras importowanych do VRF

Mamy już unikalne trasy ogłaszane w sieci dostawcy. Odbierający router PE musi jeszcze ustalić, do której sieci VPN i którego VRF należy dana trasa. Dostępność trasy dla klienta wynika z lokalnej polityki importu.

O tym decyduje atrybut BGP zwany Celem Trasy (Route Target, RT). RT jest rozszerzoną wspólnotą BGP dołączaną do trasy. Polityka eksportu dodaje RT do trasy, a polityka importu VRF określa, które takie trasy mogą zostać w nim zainstalowane. Zbiory RT eksportu i importu mogą być różne, co pozwala budować topologie typu hub-and-spoke.

Proces Eksportu i Importu

Proces eksportu i importu przebiega według konfiguracji RT:

1. Eksport RT: Kiedy router PE uczy się trasy od klienta CE i tworzy NLRI VPN-IPv4, dołącza do niej jeden lub więcej Celów Tras Eksportu przed ogłoszeniem do innych PE.
2. Import RT: Każdy VRF na routerze PE jest skonfigurowany z jednym lub większą liczbą Celów Tras Importu. Są to wartości używane przez politykę importu danego VRF.
3. Zasada dopasowania: Gdy PE otrzymuje trasę VPN-IPv4, porównuje RT dołączone do trasy z konfiguracją lokalnych VRF. Trasa kwalifikuje się do instalacji w tablicy routingu VRF wtedy, gdy co najmniej jeden RT trasy pasuje do Celu Trasy Importu tego VRF.

Płaszczyzna danych: typowy stos dwóch etykiet

Płaszczyzna sterowania obejmuje VRF-y, RD oraz RT. W typowym przekazywaniu BGP/MPLS VPN pakiet otrzymuje stos dwóch etykiet, choć sposób etykietowania zależy od topologii i implementacji. Etykietę VPN rozgłasza MP-BGP, a etykieta transportowa wynika z LSP prowadzącego do adresu PE.

1. Etykieta Wewnętrzna (VPN):

   Kiedy routery PE wymieniają trasy VPN-IPv4 przez BGP, przekazują również etykietę skojarzoną z trasą. Ta wewnętrzna etykieta jest nazywana etykietą VPN. Po dotarciu do Egress PE wskazuje kontekst klienta, na przykład VRF lub interfejs wyjściowy, zgodnie z instalacją etykiety. Jest to lokalna instrukcja dostawy.

2. Etykieta Zewnętrzna (Transportowa):

   To etykieta transportowa MPLS prowadząca z Ingress PE do Egress PE. Routery rdzeniowe P analizują tylko tę zewnętrzną etykietę. Zamieniają ją zgodnie z LSP transportowym i kierują pakiet do Egress PE wskazanego przez tablicę IGP, bez instalowania tras klientów w swojej płaszczyźnie routingu. PHP może usunąć tę etykietę na przedostatnim skoku, zanim pakiet dotrze do Egress PE.

Przebieg pakietu: podsumowanie

Przykład przebiegu pakietu z komputera Pol-Global w Warszawie do serwera w Gdańsku:

1. Pakiet IP przybywa do wejściowego routera PE w Warszawie. Router dokonuje wyszukiwania w VRF_Pol-Global.
2. Znajduje dopasowanie i określa wyjściowy router PE (w Gdańsku) oraz etykietę VPN, którą ten router ogłosił.
3. Nakłada (PUSH) wewnętrzną etykietę VPN na pakiet.
4. Następnie wyszukuje adres wyjściowego PE w swojej głównej tablicy i znajduje zewnętrzną etykietę transportową dla LSP prowadzącego do Gdańska.
5. Nakłada (PUSH) zewnętrzną etykietę transportową na pakiet.
6. Pakiet ma teraz dwie etykiety i jest wysyłany do rdzenia MPLS.
7. Routery w rdzeniu zamieniają (SWAP) tylko zewnętrzną etykietę na każdym przeskoku. Nigdy nie widzą etykiety wewnętrznej.
8. Router tuż przed wyjściowym PE (przedostatni przeskok) zdejmuje (POP) zewnętrzną etykietę.
9. W tym przykładzie wyjściowy PE w Gdańsku otrzymuje pakiet tylko z wewnętrzną etykietą VPN. Na jej podstawie wybiera VRF_Pol-Global oraz interfejs prowadzący do biura w Gdańsku.
10. Egress PE zdejmuje etykietę VPN, a oryginalny pakiet IP wysyła do routera CE w Gdańsku. Routery P w rdzeniu przetwarzały wyłącznie etykietę transportową i nie potrzebowały trasy do prywatnego prefiksu Pol-Global.