Od trasy CE RIP do zdalnego VRF: gdzie odbywa się eksport
Prefiks CE RIPv2 dociera do zdalnego VRF dopiero po trzech osobnych decyzjach: nauczeniu się go, wybraniu go w VRF i wyeksportowaniu go w ramach pasującej polityki.
Aktualizacja RIPv2 dociera na krawędź dostawcy, trafia do tabeli routingu VRF i tam się zatrzymuje, chyba że coś ją jawnie wyeksportuje. Trzy decyzje następują po sobie i każda może odrzucić prefiks z własnego powodu. Czytanie ich jako jednego zdarzenia jest przyczyną, dla której ludzie szukają niewłaściwego urządzenia, gdy zdalna lokalizacja nie może dotrzeć do sieci, którą CE wyraźnie rozgłasza. Prześledź trasę przez PE, a kolejność stanie się oczywista.
Co PE robi z aktualizacją RIP
PE odbiera aktualizację na interfejsie VRF, sprawdza, że źródło jest dozwolonym sąsiadem, i instaluje prefiks w tabeli routingu VRF z liczbą skoków wyprowadzoną z ogłoszenia. Ta tabela to zwykła tabela routingu z własnymi odległościami administracyjnymi i własnym wyborem najlepszej ścieżki. Jeśli CE ogłasza ten sam prefiks dwukrotnie z różnymi metrykami, w tabeli przetrwa tylko lepszy. Nic w tym kroku nie dotyczy szkieletu dostawcy.
Prefiks istnieje teraz w kontekście routingu jednego klienta, co jest dalekie od osiągalności gdziekolwiek indziej.
Eksport jest aktem polityki, nie konsekwencją protokołu
Aby opuścić VRF, trasa musi zostać redystrybuowana do procesu MP-BGP przenoszącego trasy VPN i potrzebuje rozszerzonej społeczności celu trasy, która wskazuje, które zdalne VRF mogą ją importować. Architektura w RFC 4364 trzyma te wymiany oddzielnie od protokołu CE-do-PE właśnie z tego powodu. Używanie RIP na krawędzi nic nie mówi o tym, co ma przekroczyć sieć dostawcy.
Zapisz kontrakt eksportu, zanim cokolwiek skonfigurujesz: prefiksy klienta, które muszą być osiągalne zdalnie, trasy, które muszą pozostać lokalne, oraz wszelkie domyślne, bardziej szczegółowe lub wyjątki usług współdzielonych. Porównaj ten kontrakt z rzeczywistym VRF, a nie z podobnie nazwanym należącym do innego klienta.
Strona importu to druga polityka z własnymi celami tras, a pasujący eksport z niepasującym importem daje prefiks, który istnieje w szkielecie i nie pojawia się w żadnej zdalnej tabeli.
Redystrybucja i jawne generowanie zachowują się różnie
Redystrybucja bierze trasy już istniejące w tabeli VRF i kopiuje je do BGP, filtrując mapą tras. Mapa decyduje, które prefiksy kwalifikują się i jakie atrybuty niosą, a metrykę trzeba ustawić jawnie, ponieważ liczba skoków RIP nie ma znaczenia jako metryka BGP. Wszystko, co zostawisz nieustawione, jest dziedziczone w sposób, który zwykle zaskakuje osobę czytającą konfigurację pół roku później.
Wzajemna redystrybucja to miejsce, w którym dzieje się cicha szkoda. Prefiks wyeksportowany do BGP może wrócić przez drugi punkt redystrybucji, a bez tagów lub filtrów trasa oscyluje, podczas gdy obie tabele w każdej chwili wyglądają wiarygodnie. Filtruj po tagach nakładanych na krawędzi, zamiast ufać, że topologia zapobiegnie drodze powrotnej.
Jawne generowanie wygląda schludniej i nie jest bezwarunkowe. Instrukcja network zwykle wymaga pasującej trasy w tabeli routingu, zanim prefiks zostanie wygenerowany, więc ogłoszenie znika w momencie, gdy CE przestaje je rozgłaszać. To często pożądane zachowanie i nie jest tym samym co trasa statyczna, która pozostaje skonfigurowana na zawsze. Sprawdź rzeczywistą regułę platformy, zamiast zakładać jedno z zachowań.
Tak czy inaczej, pytanie o każdy prefiks brzmi: które aktywne źródło czyni go kwalifikującym się i co się stanie, gdy to źródło zniknie.
Sprawdź łańcuch w czterech miejscach
Spójrz na ogłoszenie CE, tabelę routingu VRF, tabelę tras VPN z jej celem trasy i import do zdalnego VRF, w tej kolejności. W IOS oznacza to wyjście sąsiada CE, show ip route vrf CUSTOMER, show ip bgp vpnv4 vrf CUSTOMER, i to samo polecenie na zdalnym PE. W IOS-XR równoważne wyjście znajduje się pod show bgp vrf CUSTOMER ipv4 unicast. Nazwy poleceń się różnią, cztery punkty kontrolne nie.
Sprawdź prefiks, który powinien zostać odrzucony, równie starannie jak ten, który powinien przejść, ponieważ polityka zezwalająca na wszystko wygląda identycznie jak poprawna, dopóki nie pojawi się pierwszy wyjątek. Następnie obserwuj wycofanie: wyłącz interfejs CE i potwierdź, że zdalny wpis znika w oczekiwanym czasie, zamiast pozostawać.
Zapisz, kto jest właścicielem każdej polityki. Gdy dostawca zarządza CE, dostarczane zachowanie należy do umowy o poziomie usług, a inny protokół lub polityka wycofywania na zarządzanym urządzeniu jest problemem dokumentacyjnym, zanim stanie się problemem routingu.