Тип маршруту OSPF через VPN: не завжди зовнішній

Префікс клієнта перетинає хмару провайдера як маршрут BGP VPN і прибуває на віддалений сайт, виглядаючи як зовнішній маршрут OSPF, чого очікують багато інженерів і що не є єдиним можливим результатом. Те, що бачить віддалений CE, залежить від домену OSPF, з якого прийшов префікс, і від його початкового типу маршруту, і обидва подорожують разом із VPN-маршрутом. Припущення, що кожен перерозподілений префікс стає типом 5, веде до змін переваги, які не можуть працювати. Спочатку порівняйте ідентифікатор домену, а не адміністративну відстань.

Модель PE-CE несе достатньо контексту, щоб приймальний PE міг відновити оголошення OSPF, а не вигадати його.

Що подорожує разом із маршрутом

RFC 4577 визначає атрибути OSPF, які супроводжують VPN-маршрут: ідентифікатор домену, метрику та тип маршруту з початкового сайту. Приймальний PE використовує їх, щоб вирішити, як придатний префікс має виглядати для його локального процесу OSPF. Без цих атрибутів віддалений PE не мав би підстав ні для чого, крім зовнішнього перерозподілу. Тому маршрут може прийти як міжзонна LSA, навіть якщо BGP перевозив його між ними.

Тип зони також важливий. Зона stub або NSSA обмежує, які LSA можуть увійти, тому той самий VPN-маршрут може подаватися по-різному залежно від того, де розташований приймальний екземпляр OSPF. Налаштована політика експорту також може перекрити типове подання, і це свідомий вибір, а не побічний ефект.

Той самий домен, інше подання

Маршрут усередині зони або між зонами з того самого домену зазвичай прибуває на віддалений сайт як міжзонний маршрут, тобто LSA типу 3. Префікс з іншого домену, джерело, яке ніколи не говорило OSPF, або початково зовнішнє оголошення OSPF натомість дотримуються зовнішніх правил, і саме там з'являються тип 5 та його еквівалент NSSA. Обидві поведінки правильні; вхідні дані різняться. Порівняйте ідентифікатори домену та оголошені атрибути, перш ніж чіпати значення переваги.

Адміністративна відстань вибирає між джерелами на одному маршрутизаторі. Вона не переписує тип LSA і не створює відсутній зв'язок домену.

Коли sham link є правильною відповіддю

Уявіть два сайти в одній зоні, з'єднані прямим каналом задніх дверей. OSPF зберігає цей внутрішньозонний шлях замість міжзонного, який пропонує провайдер, навіть коли налаштовані витрати зробили б шлях провайдера привабливим. Sham link представляє внутрішньозонні відносини через VPN, щоб витрати могли брати участь у рішенні. Він існує для цієї конкретної проблеми вибору шляху, а не для того, щоб кожен маршрут того самого домену виглядав внутрішнім.

Sham link потребує доступних кінцевих точок і взаємного налаштування на обох PE. Налаштування лише з одного боку створює зв'язок, який ніколи не формується, і таблиця маршрутизації зберігає стару перевагу, що виглядає так, ніби функція нічого не зробила.

Не ламайте захист від петель

Модель PE-CE встановлює біт DN на маршрутах, які розповсюджує, щоб префікс не міг повернутися через інший CE і бути перерозподіленим удруге. Саме цей захист не дає префіксу зациклитися між сайтами, що поділяють домен OSPF. Видалення або ігнорування його, щоб маршрут виглядав внутрішнім, може створити саме ту петлю, для запобігання якій його призначено. Коли префікс виглядає неправильно, ставтеся до біта DN як до інформації, а не як до перешкоди.

Та сама обережність стосується фільтрів перерозподілу та карт маршрутів, які видаляють спільноти. Кожен із них видаляє контекст, потрібний віддаленій стороні, і отримане оголошення може виглядати правдоподібно, будучи хибним. Змінюйте по одному атрибуту за раз і перевіряйте, що віддалений CE насправді встановлює.

Потім перевірте з віддаленого сайту: тип LSA, маршрутизатор, що оголошує, і обраний шлях. Ці докази відповідають на питання, поставлене в заявці.