Теоретические основы и архитектура
Лабораторная работа: реализация сложных топологий L3VPN — Hub-and-Spoke, Extranet и Shared Services. По умолчанию L3VPN строит топологию Full Mesh (любой филиал общается с любым филиалом напрямую). Однако во многих корпоративных сценариях требуется топология Hub-and-Spoke: филиалы (Spokes) не должны связываться напрямую, а весь их трафик обязан проходить через центральный офис (Hub) для фильтрации на центральном фаерволе. Это достигается разделением Route Targets: Hub имеет два RT (например, Hub-In 65000:10 и Hub-Out 65000:20). Филиалы экспортируют свои маршруты с тегом Hub-In и импортируют только маршруты с тегом Hub-Out (по умолчанию — дефолтный маршрут 0.0.0.0/0 от центрального фаервола). Таким образом филиалы не знают маршрутов друг друга напрямую. Также в лабораторной реализуется Extranet — предоставление доступа к изолированному серверному сегменту (Shared Service VRF) из нескольких различных клиентских VRF через выборочный импорт Route Target.
RT как конструктор топологий
Топология L3VPN определяется не протоколами, а таблицей "кто какой RT экспортирует и импортирует". MP-BGP одинаково переносит все маршруты, а VRF решает по RT, какие из них принять. Три базовых шаблона:
| Топология | Export RT | Import RT | Результат |
|---|---|---|---|
| Full mesh | 65000:100 на всех | 65000:100 на всех | любой сайт видит любой |
| Hub-and-spoke | Spoke: 65000:10; Hub: 65000:20 | Spoke: 65000:20; Hub: 65000:10 | spoke видит только hub |
| Extranet / shared services | клиент: свой RT + RT сервиса | клиент: свой RT + RT сервиса | клиент видит общие серверы, но не соседей |
Hub-and-spoke: зачем две VRF на hub-PE
Цель - принудительно провести весь межсайтовый трафик через межсетевой экран hub-сайта. Если на hub-PE сделать одну VRF с import 65000:10 и export 65000:20, то пакет из spoke 1 к spoke 2 прилетит на hub-PE с VPN-меткой этой VRF и PE, найдя маршрут на spoke 2 (он импортирован), перешлёт его напрямую, минуя firewall. Поэтому hub-PE разделяют на две VRF с двумя PE-CE линками к одному CE (firewall):
- HUB-IN (импорт RT 65000:10): в ней лежат маршруты всех spoke; PE отдаёт их firewall по линку 1, а firewall возвращает проинспектированный трафик в этот же линк, и PE пересылает его к нужному spoke. VRF ничего не экспортирует.
- HUB-OUT (экспорт RT 65000:20): в ней лежат маршруты, полученные от firewall по линку 2 (default и LAN hub-сайта 192.168.10.0/24), их RT 65000:20 импортируют spoke. Трафик от spoke приходит с меткой HUB-OUT и уходит в линк 2 на firewall - другого пути в этой VRF нет.
Следствие: spoke-to-spoke проходит spoke 1 -> PE2 -> PE1 (HUB-OUT) -> firewall -> PE1 (HUB-IN) -> PE2 -> spoke 2; на PE1 пакет в плоскости данных дважды пересекает VRF.
Особенности PE-CE протокола на hub
При eBGP между hub-PE и firewall у всех spoke обычно один AS: hub-CE и spoke-CE в одном AS 65101 не примут маршруты друг друга из-за loop prevention. На PE используют as-override, либо allowas-in на CE. При статике (как в лабораторной) проблемы нет, но firewall должен иметь маршруты на spoke LAN через PE (линк 1) и default через PE (линк 2). Без маршрута возврата в сторону spoke трафик теряется на firewall.
Extranet и shared services
Общие сервисы (DNS, мониторинг, SaaS-шлюз) размещают в отдельной VRF SS с RT 65000:900. Клиентские VRF дополнительно импортируют 65000:900, а SS импортирует клиентские RT, чтобы был обратный маршрут. Принципы:
- Видимость односторонняя на уровне маршрутов, но двусторонняя на уровне пакетов: маршруты клиента в SS нужны для ответа, потому что в SS нет default.
- Адреса клиентов, попадающие в SS, должны быть уникальными: два клиента с перекрывающимися LAN, импортированные в SS, конфликтуют (для таких клиентов используют NAT на стыке или не импортируют LAN, а только нужные /32).
- Клиенты A и B не импортируют RT друг друга: даже при общем SS они остаются изолированными, пока SS не включает транзитный default между VRF.
- Ограничивайте утечку явными политиками (
import-map/vrf-import), чтобы SS получала не всю таблицу, а только нужные префиксы.
Cisco/Huawei/Junos: где задаётся RT
Cisco и Huawei - декларативно в VRF (route-target/vpn-target), Junos - vrf-target либо vrf-import/vrf-export политики с communities. Политики нужны, когда логика сложнее "один RT": несколько RT на импорт (spoke: 20 и 900), RT только для части маршрутов, ограничение по префиксам.
Сходимость и масштаб
Каждая смена RT приводит к повторному выбору маршрутов в VRF: на больших таблицах clear лишь для затронутых VRF. Количество RT на VRF ограничено (Huawei - до 8 в одной команде, Cisco - десятки). Чем сложнее схема RT, тем тяжелее аудит: храните RT-матрицу (кто экспортирует, кто импортирует) как данные в Git.
Проверка топологии
Правильная проверка - не пинг, а таблица маршрутов: в VRF spoke нет префиксов других spoke (только default hub, LAN hub-сайта и сервисы), в HUB-IN есть все spoke, в SS есть spoke и нет hub. Трассировка spoke-to-spoke должна показать firewall, а запрос к SS идёт напрямую к PE1. Любое другое поведение - утечка RT.
Схема архитектуры и топология
[Hub CE / Firewall]
^
| (Hub PE: VRF Hub-In imports RT 65000:10, VRF Hub-Out exports RT 65000:20)
v
[Provider Core]
/ \
v v
[Spoke-1 CE] [Spoke-2 CE]
(Imports RT 65000:20 only) (Imports RT 65000:20 only)
(Exports RT 65000:10) (Exports RT 65000:10)Схема прохождения трафика и стек меток
Hub-and-Spoke Routing Policy Enforcement:
1. Spoke-1 advertises 10.1.0.0/24 with Export RT 65000:10.
2. Spoke-2 imports only RT 65000:20, so it does not learn the Spoke-1 route directly.
3. Hub PE imports RT 65000:10 into VRF Hub-In and passes the spoke routes to the firewall.
4. VRF Hub-Out exports a default/summary route with RT 65000:20; the spokes import it.
5. Spoke-to-spoke traffic therefore follows the default route to the hub and is inspected by the firewall.Таблица состояний и параметров
| Топология VPN | Политика Export RT | Политика Import RT | Поведение трафика |
|---|---|---|---|
| Full Mesh (Любой с любым) | RT 65000:100 | RT 65000:100 | Прямая связь между всеми филиалами без посредников |
| Hub-and-Spoke (Spoke) | RT 65000:10 (Spoke) | RT 65000:20 (Hub) | Филиалы видят только Hub, прямой связи между филиалами нет |
| Hub-and-Spoke (Hub) | RT 65000:20 (Hub) | RT 65000:10 (Spoke) | Центральный узел видит все филиалы и инспектирует весь трафик |
| Extranet (Shared Services) | RT_Customer + RT_Shared | RT_Customer + RT_Shared | Безопасный доступ к общим серверам без объединения клиентов |
Архитектурная модель и принцип работы
В реальных сетях оператора MPLS объединяет оборудование различных производителей. Ниже представлены практические примеры конфигурации и вывода команд Data Plane / Control Plane для четырёх платформ: Cisco IOS-XE/XR, Huawei VRP, Juniper Junos и MikroTik RouterOS v7. Обратите внимание на различия в синтаксисе и механизмах распределения меток.
