Dlaczego jeden dzierżawca EVPN może pokazywać kilka route distinguisher
Dwa RD u jednego dzierżawcy to nie konflikt. Przejdź od wyjścia CLI do MAC-VRF lub IP-VRF, który utworzył trasę, a następnie sprawdź import RT i VNI.
Filtrujesz tablicę EVPN dla jednego dzierżawcy, a trasy niosą dwa różne route distinguisher. Pierwszy odruch to konflikt konfiguracji i ten odruch zwykle jest błędny. Nazwa dzierżawcy to etykieta biznesowa, a nie pojedynczy obiekt płaszczyzny sterowania, więc kontekst mostkowania i kontekst routingu w jej wnętrzu mogą legalnie ogłaszać się pod osobnymi identyfikatorami. Przejdź trasę po trasie od wyjścia z powrotem do lokalnego obiektu usługi, który ją utworzył, a drugi RD przestanie wyglądać jak błąd.
Zacznij od wyjścia, które cię zdezorientowało
Wybierz jedną trasę zamiast całej tablicy. Zanotuj jej typ trasy, RD, wyeksportowane route targety i następny skok. Te cztery pola wystarczą, aby ustalić, który lokalny obiekt ją ogłosił i która polityka zdalna powinna ją zaimportować.
Na urządzeniu w stylu NX-OS widok szczegółowy uzyskuje się poleceniem show bgp l2vpn evpn route-type 2 detail lub show bgp l2vpn evpn route-type 5 detail. W Junos te same informacje znajdują się w show route table bgp.evpn.0 detail. Inna składnia, te same pola.
Nie zaczynaj od zrównywania każdej wyświetlanej liczby. Zrównanie RD to zmiana, która psuje politykę importu na działającym fabric.
Nadaj każdemu identyfikatorowi jego zadanie
| Identifier | Question it answers | Where it is used |
|---|---|---|
| Route distinguisher | Which distinct route context contributed this advertisement? | Makes otherwise identical prefixes unique in BGP |
| Route target | Which importing service policy should receive the route? | Extended community matched by import policy |
| VNI | Which VXLAN service context carries the traffic? | Data plane encapsulation and mapping |
MAC-VRF przechowuje informacje o przekazywaniu MAC dla usługi mostkowania. IP-VRF dostarcza kontekst routingu IP dla usługi routowanej. Dzierżawca może zawierać oba, dlatego jeden dzierżawca może wytworzyć więcej niż jeden RD bez żadnego błędu konfiguracji.
RFC 7432 przypisuje RD ogłaszającego MAC-VRF do jego EVPN NLRI i wymaga różnych RD między MAC-VRF na tym samym PE. Procedury route-target są osobne: pozwalają na jeden lub więcej atrybutów RT i polegają na polityce importu w kwestii członkostwa. Równość RD nie jest tym, co tworzy wspólne członkostwo, a takie podejście jest źródłem tego zamieszania.
Przejdź jedną trasę od ogłoszenia do importu
Śledź trasę w jednym kierunku. Potwierdź typ trasy, usługę, która ją utworzyła, RD, wyeksportowane RT, a następnie politykę importu na odbierającym PE. Każdy krok odpowiada na inne pytanie, a awaria na którymkolwiek kroku wygląda jak ten sam brakujący prefiks po drugiej stronie.
Gdy trasa już istnieje, sprawdź zainstalowany kontekst przekazywania i mapowanie VNI. Zgodność VNI na obu końcach dowodzi, że płaszczyzna danych się zgadza; nie dowodzi, że płaszczyzna sterowania zaimportowała trasę przez zamierzoną politykę.
Jeśli trasa pojawia się na zdalnym PE, ale ruch nie płynie, problem wyszedł poza EVPN. Sprawdź powiązanie VNI z VLAN lub VNI z VRF oraz ścieżkę underlay, zanim ponownie edytujesz route targety. Zacznij od mapowania, potem underlay, a dopiero potem płaszczyzna sterowania. Wycofywanie zmiany route-target w pogoni za usterką płaszczyzny danych to pewny sposób zepsucia działającego importu.
Prefiksy warstwy 3 nadal są trasami EVPN
Prefiks IP w tablicy EVPN nie jest zwykłym IPv4-unicast BGP. trasa EVPN IP Prefix to odrębny typ trasy, a ogłoszenia MAC/IP i prefiksu IP podróżują w rodzinie adresów EVPN, którą RFC 7432 określa jako AFI 25 i SAFI 70.
To rozróżnienie ma znaczenie, gdy porównujesz trasę z tablicy EVPN z trasą z tablicy unicast. Mogą opisywać ten sam cel i nadal być tworzone, filtrowane i importowane przez różne polityki. Czytanie jednej jako dowodu o drugiej sprawia, że poprawny fabric wygląda na zepsuty podczas migracji.
Sprawdź wyprowadzenie producenta, zanim porównasz liczby
RFC 9136 rozszerza EVPN o trasy IP Prefix i określa, czy mający zastosowanie RD pochodzi z kontekstu MAC-VRF czy IP-VRF. Dlatego etykietę usługi L2 i etykietę usługi routowanej w tym samym wyjściu należy czytać wobec obiektów, do których należą, a nie redukować do jednego RD na dzierżawcę.
Automatyczne wyprowadzanie RD i RT zależy od producenta. Przeczytaj dokumentację wdrożonego producenta dla używanej formuły; wartość wygenerowana automatycznie widziana na jednym przełączniku nie jest uniwersalnym kodowaniem, a porównywanie liczb dwóch producentów rzadko cokolwiek dowodzi.
Zakończ pisemnym śladem dla trasy, od której zacząłeś: typ, obiekt źródłowy, RD, wyeksportowany RT, polityka importu, zainstalowany VNI. Sześć pól wyjaśnia ogłoszenie każdemu, kto przeczyta zgłoszenie następny, i żadne z nich nie wymaga, aby liczby dzierżawcy się zgadzały.