Dwa PE, jeden prefiks: dlaczego RD decyduje o widoczności
Dwa routery brzegowe ogłaszające ten sam prefiks dzielą jeden cel, o ile ich route distinguisher się nie różnią. Przydzielaj świadomie, a potem sprawdź VRF.
Dwa routery brzegowe ogłaszające ten sam prefiks klienta opisują jeden cel VPNv4, dopóki coś ich nie rozdzieli, a tym rozdzielaczem jest route distinguisher. Kwalifikuje prefiks; nie decyduje, kto importuje wynik, to zadanie route target. Przydzielaj RD ze zbioru tras, które muszą pozostać rozróżnialne w każdej domenie, gdzie te ogłoszenia mogą się spotkać, a nie z układu plików jednego urządzenia. Wybrany numer to tożsamość, od której będą zależeć późniejsze przeglądy, więc powinien trafić do inwentarza, zanim trafi do konfiguracji.
RD i prefiks to jeden cel
RD plus prefiks IPv4 tworzą cel VPNv4, który porównuje płaszczyzna sterowania. Daj dwóm PE ten sam prefiks dla różnych klientów, a bez różnych RD ogłaszają trasy do jednego celu. Nic na ekranie nie mówi, że takie grupowanie jest błędne, bo platforma robi dokładnie to, co mówi tożsamość. Zmień RD na jednym z nich, a stare ogłoszenie zostanie wycofane, podczas gdy pod inną tożsamością pojawi się nowe. Wszystko w dół, co opierało się na starej tożsamości, od wyboru trasy po zapisany filtr operatora, teraz odnosi się do czegoś, czego już nie ma.
Wiele tras na cel to normalne zachowanie BGP, nie objaw. Speaker może trzymać wiele odebranych tras, wybierając jedną najlepszą do przekazywania, a różnica między odebraną a wybraną to miejsce, w którym żyją pytania o widoczność. Gdy trasa wydaje się zniknęła, potwierdź, czy tożsamość, do której należała, nadal istnieje, zanim spojrzysz na sesję.
To samo RD, ten sam cel, inne trasy
Wyślij jedno RD i jeden prefiks z dwóch routerów w imieniu tej samej usługi, a oba oferują trasy do jednego celu, zwykle z różnymi następnymi skokami. To, którą z nich route reflector przekaże, jest decyzją o reflectorze: jego wyborem trasy, zdolnością ogłaszania i każdą polityką nałożoną na to. Żaden z routerów brzegowych nie kontroluje tego wyboru. Daj obu ogłoszeniom różne RD, a każde staje się własnym celem, więc oba mogą przetrwać płaszczyznę sterowania, która inaczej niesie tylko wybraną trasę dla jednej tożsamości.
Widoczność i multipath spotykają się w odbierającym VRF, ale nie są tą samą decyzją, a reflector niosący dwie tożsamości nie skonfigurował drugiej zainstalowanej trasy. VRF instaluje to, co dopuszcza jego polityka importu, i to, na co pozwala jego własne ustawienie maksymalnej liczby tras. Sprawdź to ustawienie osobno, gdy chcesz, aby druga trasa była używana, a nie tylko widoczna.
Lokalna zasada unikalności nie jest polityką
Dawanie każdemu PE i każdej instancji routingu własnego RD to zdrowa konwencja: nazywa pochodzenie, nie pozwala niezwiązanym usługom zderzyć się na jednej tożsamości i daje inwentarzowi stabilny klucz. Niektóre platformy wymagają unikalności tylko wewnątrz urządzenia i wyraźnie pozwalają routerom dzielić RD dla tej samej instancji VPN. To pozwolenie jest ograniczeniem implementacji, a nie regułą między sieciami, którą można delegować dostawcy. Jeśli domena obejmuje zespoły, napisz politykę przydziału samodzielnie.
Członkostwo nigdy nie wynika z cyfr. Wzorzec taki jak 65000:12 dla jednego PE i 65000:13 dla innego to nawyk, natomiast pasujące cele eksportu i importu, takie jak 65000:112, są tym, co umieszcza trasę w VRF. Traktuj RD jako tożsamość trasy, a route target jako pozwolenie, które niesie ją do VRF.
Udowodnij zmianę na VRF, nie na ekranie
Zanim dotkniesz RD, zapisz cztery rzeczy: co PE ogłasza dziś, co odzwierciedla reflector, co importuje odbierający VRF i którą trasę wybiera. Nowe RD wycofuje jedno ogłoszenie i wprowadza inne, więc zmiana jest widoczna po obu stronach sesji i łatwo ją źle odczytać, jeśli śledzisz tylko stronę ogłaszającą. Akceptacja powinna opierać się na zamierzonej osiągalności, a nie na dodatkowym wierszu w liście prefiksów. Tabela poniżej nie pozwala trzem identyfikatorom zlać się podczas tego przeglądu.
| Identifier | Question it answers | What breaks when it is confused with another |
|---|---|---|
| Route distinguisher | Which route identity is this? | Two services collapse into one destination, so one advertisement withdraws the other |
| Route target | Who is allowed to import it? | Routes arrive in a VRF that should not have them, or never arrive at all |
| VRF import policy | What does this instance accept and install? | The route is visible on the PE but never selected in the VRF |
Zacznij od ogłaszającego PE i porównaj obie tożsamości dla tego samego prefiksu, zanim cokolwiek usuniesz. Zamieszczone niżej polecenia IOS odpowiadają po kolei na trzy pytania: czy stare ogłoszenie nadal tam jest, czy nowa tożsamość jest widoczna dla reflektora i czy VRF wybiera ten prefiks.
show bgp vpnv4 unicast rd 65000:12 203.0.113.0/24 show bgp vpnv4 unicast rd 65000:13 203.0.113.0/24 show ip route vrf CUSTOMER-A 203.0.113.0/24
Inne platformy drukują te same informacje w innej składni, a pytania przetrwają tę zmianę. Jeśli nowej tożsamości brakuje u reflektora, a PE wymienia ją jako ogłoszoną, pierwszym podejrzanym jest polityka lub zdolność ogłaszania reflektora, nie numeracja.
Zapisz PE, instancję, RD, cele eksportu i importu oraz właściciela prefiksu w jednym miejscu, bo kolejny przydział jest wyszukaniem, a nie domysłem tylko wtedy, gdy ten zapis istnieje. Trzymaj stare RD, dopóki nowa tożsamość nie będzie widoczna w odbierającym VRF, a potem wycofaj je w drugim kroku, aby każdy etap pozostał odwracalny.