Від маршруту RIP на CE до віддаленого VRF: де відбувається export

Оновлення RIPv2 надходить на provider edge, потрапляє до таблиці маршрутизації VRF і там зупиняється, якщо щось явно його не export-ує. Три рішення відбуваються послідовно, і кожне може відхилити префікс зі своєї причини. Сприймання їх як однієї події — це причина, чому люди шукають несправність не в тому пристрої, коли віддалений майданчик не може дістатися мережі, яку CE явно анонсує. Прослідкуйте маршрут через PE, і послідовність стане очевидною.

Що PE робить з оновленням RIP

PE отримує оновлення на інтерфейсі VRF, перевіряє, що джерело є дозволеним сусідом, і встановлює префікс у таблицю маршрутизації VRF з кількістю хопів, похідною від анонсу. Ця таблиця — звичайна таблиця маршрутизації з власними адміністративними дистанціями та власним вибором найкращого шляху. Якщо CE анонсує той самий префікс двічі з різними метриками, до таблиці потрапляє лише кращий. Ніщо на цьому кроці не стосується магістралі провайдера.

Тепер префікс існує в межах контексту маршрутизації одного клієнта, що далеко від доступності будь-де інде.

Export — це акт політики, а не наслідок протоколу

Щоб залишити VRF, маршрут потрібно перерозподілити в процес MP-BGP, який переносить VPN-маршрути, і йому потрібен route target extended community, що визначає, які віддалені VRF можуть його import-увати. Архітектура в RFC 4364 тримає ці обміни окремо від протоколу CE-PE саме з цієї причини. Використання RIP на межі нічого не говорить про те, що має перетинати мережу провайдера.

Запишіть контракт export, перш ніж щось налаштовувати: префікси клієнта, які мають бути доступними віддалено, маршрути, які мають залишитися локальними, а також будь-які маршрути за замовчуванням, конкретніші маршрути чи винятки для спільних сервісів. Порівнюйте цей контракт із фактичним VRF, а не з одноіменним VRF іншого клієнта.

Сторона import — це друга політика з власними route target, і відповідний export із невідповідним import дає префікс, який існує в магістралі та не з'являється в жодній віддаленій таблиці.

Перерозподіл і явне створення поводяться по-різному

Перерозподіл бере маршрути, які вже є в таблиці VRF, і копіює їх у BGP, фільтруючи через route map. Map вирішує, які префікси придатні та які атрибути вони несуть, а метрику треба задати явно, бо кількість хопів RIP не має сенсу як метрика BGP. Усе, що ви залишите незаданим, успадковується так, що це зазвичай дивує людину, яка читає конфігурацію пів року потому.

Взаємний перерозподіл — це місце, де трапляється тиха шкода. Префікс, export-ований у BGP, може повернутися через другу точку перерозподілу, і без тегів чи фільтрів маршрут коливається, поки обидві таблиці в кожен момент виглядають правдоподібно. Фільтруйте за тегами, застосованими на межі, замість того щоб покладатися на топологію в запобіганні зворотному шляху.

Явне створення виглядає охайніше й не є безумовним. Network statement зазвичай потребує відповідного маршруту в таблиці маршрутизації до того, як префікс буде створено, тому анонс зникає в момент, коли CE припиняє його анонсувати. Часто це саме та поведінка, яку ви хочете, і вона не тотожна статичному маршруту, що залишається налаштованим назавжди. Перевіряйте фактичне правило платформи, а не припускайте одну з поведінок.

У будь-якому разі питання щодо кожного префікса — яке активне джерело робить його придатним і що станеться, коли це джерело зникне.

Перевірте ланцюг у чотирьох місцях

Подивіться на анонс CE, таблицю маршрутизації VRF, таблицю VPN-маршрутів з її route target і import у віддаленому VRF — саме в цьому порядку. В IOS це означає вивід сусідів CE, show ip route vrf CUSTOMER, show ip bgp vpnv4 vrf CUSTOMER, і та сама команда на дальньому PE. В IOS-XR еквівалентний вивід міститься під show bgp vrf CUSTOMER ipv4 unicast. Назви команд різняться, чотири контрольні точки — ні.

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

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