Typ trasy OSPF przez VPN: nie zawsze zewnętrzny

Prefiks klienta przechodzi przez chmurę dostawcy jako trasa BGP VPN i dociera do zdalnej lokalizacji wyglądając jak zewnętrzna trasa OSPF, czego wielu inżynierów oczekuje i co nie jest jedynym możliwym wynikiem. To, co widzi zdalny CE, zależy od domeny OSPF, z której pochodzi prefiks, oraz od jego pierwotnego typu trasy, a oba podróżują z trasą VPN. Założenie, że każdy redystrybuowany prefiks staje się typem 5, prowadzi do zmian preferencji, które nie mogą działać. Najpierw porównaj identyfikator domeny, a nie odległość administracyjną.

Model PE-CE niesie dość kontekstu, aby odbierający PE mógł odtworzyć ogłoszenie OSPF, zamiast je wymyślać.

Co podróżuje z trasą

RFC 4577 definiuje atrybuty OSPF towarzyszące trasie VPN: identyfikator domeny, metrykę i typ trasy z lokalizacji źródłowej. Odbierający PE używa ich, aby zdecydować, jak kwalifikujący się prefiks powinien wyglądać dla jego lokalnego procesu OSPF. Bez tych atrybutów zdalny PE nie miałby podstawy do niczego poza zewnętrzną redystrybucją. Dlatego trasa może dotrzeć jako LSA międzystrefowa, mimo że BGP ją między nimi przeniósł.

Typ obszaru też ma znaczenie. Obszar stub lub NSSA ogranicza, które LSA mogą wejść, więc ta sama trasa VPN może być prezentowana inaczej w zależności od tego, gdzie znajduje się odbierająca instancja OSPF. Skonfigurowana polityka eksportu może też nadpisać domyślną prezentację, co jest świadomym wyborem, a nie efektem ubocznym.

Ta sama domena, inna prezentacja

Trasa wewnątrzstrefowa lub międzystrefowa z tej samej domeny zwykle dociera do zdalnej lokalizacji jako trasa międzystrefowa, czyli LSA typu 3. Prefiks z innej domeny, źródło, które nigdy nie mówiło OSPF, albo początkowo zewnętrzne ogłoszenie OSPF zamiast tego stosują reguły zewnętrzne, i właśnie tam pojawiają się typ 5 i jego odpowiednik NSSA. Oba zachowania są poprawne; dane wejściowe się różnią. Porównaj identyfikatory domen i ogłoszone atrybuty, zanim dotkniesz wartości preferencji.

Odległość administracyjna wybiera między źródłami na jednym routerze. Nie przepisuje typu LSA ani nie tworzy brakującej relacji domeny.

Kiedy sham link jest właściwą odpowiedzią

Wyobraź sobie dwie lokalizacje w tym samym obszarze połączone bezpośrednim łączem zapasowym. OSPF zachowuje tę ścieżkę wewnątrzstrefową zamiast ścieżki międzystrefowej oferowanej przez dostawcę, nawet gdy skonfigurowane koszty czyniłyby ścieżkę dostawcy atrakcyjną. Sham link reprezentuje relację wewnątrzstrefową przez VPN, aby koszty mogły brać udział w decyzji. Istnieje dla tego konkretnego problemu wyboru ścieżki, a nie po to, by każda trasa z tej samej domeny wyglądała na wewnętrzną.

Sham link wymaga osiągalnych punktów końcowych i wzajemnej konfiguracji na obu PE. Skonfigurowanie go tylko po jednej stronie tworzy relację, która nigdy nie powstaje, a tablica routingu zachowuje starą preferencję, co wygląda tak, jakby funkcja nic nie zrobiła.

Nie łam ochrony przed pętlami

Model PE-CE ustawia bit DN na trasach, które rozdziela, aby prefiks nie mógł wrócić przez inny CE i zostać zredystrybuowany po raz drugi. Ta ochrona powstrzymuje prefiks przed zapętleniem między lokalizacjami współdzielącymi domenę OSPF. Usunięcie jej lub zignorowanie, aby trasa wyglądała na wewnętrzną, może stworzyć dokładnie tę pętlę, której miała zapobiegać. Gdy prefiks wygląda źle, traktuj bit DN jako informację, a nie przeszkodę.

Ta sama ostrożność dotyczy filtrów redystrybucji i map tras, które usuwają społeczności. Każdy z nich usuwa kontekst potrzebny drugiej stronie, a wynikowe ogłoszenie może wyglądać wiarygodnie, choć jest błędne. Zmieniaj jeden atrybut naraz i sprawdzaj, co zdalny CE faktycznie instaluje.

Następnie zweryfikuj ze zdalnej lokalizacji: typ LSA, router ogłaszający i wybraną ścieżkę. Te dowody odpowiadają na pytanie postawione w zgłoszeniu.