RD kontra RT w MPLS VPN: unikalność kontra polityka importu
Dystynktor trasy czyni pokrywające się prefiksy unikalnymi, a cel trasy decyduje, które trasy VRF może importować. Prześledź jedną trasę MPLS w obu rolach.
Dwie witryny klienta mogą ogłaszać 10.20.0.0/24 i obie pozostają ważne w jednej sieci dostawcy. Dystynktor trasy utrzymuje te ogłoszenia osobno; cel trasy decyduje, która VRF klienta może pobrać kopię. W konfiguracji stoją obok siebie i wykonują zupełnie różne zadania. Pomylenie ich prowadzi do zmian, które wyglądają rozsądnie i niczego nie naprawiają.
Prześledź jedną trasę od krawędzi klienta do odległej VRF a podział staje się konkretny: tożsamość jest dołączana, zanim trasa wejdzie do BGP, a polityka dystrybucji jest oceniana, gdy trasa dotrze do odbierającej krawędzi dostawcy.
Trasa VPN-IPv4 to RD plus prefiks IPv4
RFC 4364 definiuje rodzinę adresów VPN-IPv4 jako ośmiobajtowy dystynktor trasy, po którym następuje czterobajtowy adres IPv4. RD jest dodawany przed prefiksem klienta, więc dwa identyczne prefiksy z różnych witryn stają się dwiema różnymi trasami BGP.
Ta konstrukcja to cały mechanizm unikalności. Dostawca nie potrzebuje zgody klientów co do niepokrywającej się przestrzeni adresowej, a trasa z jednej witryny nie może po cichu zastąpić identycznego prefiksu z innej witryny.
Sam format RD to wartość wybierana przez administratora, zwykle numer systemu autonomicznego i numer lokalny. Jego postać liczbowa jest konwencją, a nie sygnałem, że oba pola dzielą znaczenie z celem trasy, który przypadkiem używa tych samych cyfr.
RD czyni pokrywające się prefiksy rozróżnialnymi
Rozważ dwa ogłoszenia tego samego prefiksu. Witryna A ma RD 65000:101, a witryna B ma RD 65000:202, oba dla 10.20.0.0/24. BGP ma teraz dwie trasy VPN-IPv4, które można niezależnie porównywać, filtrować i wybierać.
RD nie mówi, która VRF ma otrzymać którąkolwiek z tych tras, ani nie identyfikuje klienta czy usługi. To pole tożsamości trasy, nie lista członkostwa. Własny RD danej VRF nie musi odpowiadać RD trasy, którą ona importuje.
Dlatego zmiana RD tak, by odpowiadał numerowi innej witryny, niczego nie naprawia. Jeśli trasy brakuje po drugiej stronie, dopasowanie cyfr tworzy inny problem tożsamości zamiast naprawić decyzję importową.
RT to atrybut BGP, a nie znacznik w pakiecie
Polityka eksportu dołącza jeden lub więcej celów trasy do trasy jako rozszerzone atrybuty społeczności BGP. Odbierająca krawędź dostawcy porównuje te atrybuty z polityką importu każdej VRF. RT podróżuje z trasą przez płaszczyznę sterowania. Porównanie odbywa się w całości w polityce routingu, zanim zostanie przesłany jakikolwiek pakiet klienta.
Pakiety danych klienta nie przenoszą RT. Po zainstalowaniu trasy w VRF przekazywanie korzysta z tabeli tej VRF i stosu etykiet MPLS, który przydziela architektura. Krawędź dostawcy nie odczytuje celu trasy z każdego pakietu klienta.
Trasa może przenosić kilka RT, a VRF może zaimportować kilka. Konfiguracja często wygląda jak krótki blok:
vrf definition CUST-A
rd 65000:101
address-family ipv4
route-target export 65000:500
route-target import 65000:500
Czytaj ten blok jako dwa odrębne stwierdzenia. Wiersz eksportu kontroluje, co jest dołączane do tras opuszczających tę VRF; wiersz importu kontroluje, co ta VRF jest gotowa rozważyć. Zgodne numery są wygodne, ale nie obowiązkowe.
Uprawnienie do importu to nie instalacja
Trasa może być dopuszczalna dla VRF i mimo to nie pojawić się w jej tabeli przekazywania. Dopuszczalność to filtr; następnie zwykły proces decyzyjny BGP porównuje dopuszczalne trasy i wybiera jedną. Starsza lub mniej preferowana trasa może przegrać z inną dopuszczalną ścieżką.
Sprawdź wybraną trasę, nie tylko politykę importu. VRF, która importuje RT 65000:500 i nie pokazuje żadnej trasy dla 10.20.0.0/24, mogła otrzymać trasę i odrzucić ją podczas wyboru albo nigdy jej nie otrzymała.
To rozróżnienie ma znaczenie także wtedy, gdy pojawi się nieoczekiwany prefiks. Zbyt szeroka polityka importu może przyciągnąć trasy, których witryna nie zamierzała używać, a unikalność RD wcale temu nie zapobiega. Zakres dystrybucji to kwestia polityki RT.
Prześledź brakującą trasę w kolejności płaszczyzny sterowania
Zacznij od ogłoszenia: czy źródłowa VRF eksportuje zamierzony RT i czy trasa istnieje jako trasa VPN-IPv4 na reflektorze tras lub na odbierającym PE? Następnie sprawdź atrybut tak, jak został odebrany, a nie jak jest skonfigurowany u nadawcy.
Następnie porównaj listę importu odbierającej VRF z rzeczywistymi wartościami RT trasy. Na końcu obejrzyj wybraną trasę w tej VRF oraz powiązanie etykiety. Każdy krok odpowiada na inne pytanie, a skok do RD zwykle pomija właśnie ten błędny.
Zapisz RD, wyeksportowany RT, zaimportowany RT i wybrany następny skok dla witryny działającej i tej, która zawodzi. Cztery wartości obok siebie zamieniają mgliste „VPN nie przepuszcza tras” w dokładny krok płaszczyzny sterowania, który się różni.