L3 Услуга IPVPN: частная сеть клиента

Финал пути. Здесь всё, что мы учили по отдельности — VRF, BGP, RD/RT — собирается в одну реальную услугу. IPVPN (он же L3VPN) — это когда у клиента много офисов в разных городах, и оператор объединяет их в одну защищённую сеть, маршрутизируя трафик между ними по IP. Это самая «инженерная» услуга оператора — и самая частая строчка в вакансиях инженера СПД.

Заявка из очереди

«Заявка #51907. Клиент „Ромашка“ (услуга IPVPN, 2 действующих офиса) открывает филиал в Казани. Подключить третий офис к существующему VPN: порт Gig0/2 на PE3-Kazan, подсеть офиса 10.3.0.0/24, маршрутизация с CE — eBGP, AS клиента 64512. После включения все три офиса должны видеть друг друга».

К концу урока ты закроешь эту заявку сам: заведёшь VRF на новом PE, поднимешь eBGP с CE, проверишь, что маршруты Казани доехали до Москвы и Питера, — и будешь понимать, почему каждая строчка конфига именно такая.

Что узнаешь — после урока ты сможешь
Вспомни из прошлых уроков — здесь пригодится всё

Урок 3: VRF — отдельная таблица маршрутов на клиента; RD делает адреса уникальными, RT раздаёт их «своим»; все команды — с vrf ИМЯ. Урок 4: eBGP на стыке PE–CE приносит сети клиента в его VRF; iBGP разносит маршруты между роутерами оператора; диагностика начинается с show ip bgp … summary. Урок 6: у EPL оператор не трогал IP клиента вообще — держи этот контраст в голове, сегодня всё будет наоборот. Если что-то звучит смутно — вернись, этот урок стоит на них целиком.

1. Что такое IPVPN

IPVPN (IP Virtual Private Network, он же L3VPN или MPLS L3VPN) — услуга, в которой оператор объединяет несколько площадок клиента в единую частную IP-сеть и маршрутизирует трафик между ними. В отличие от EPL, здесь оператор активно участвует в L3: он держит маршруты клиента, знает его сети и решает, куда какой пакет отправить.

Три ключевых отличия от EPL сразу, чтобы уложилось:

EPL (прошлый урок)IPVPN (этот урок)
УровеньL2 — возит кадрыL3 — маршрутизирует пакеты
Топологияточка-точка (2 офиса)любая, много офисов (3, 10, 100…)
Подсети офисоводна общаяразные, оператор их знает и связывает
Оператор участвует в IP?нетда — держит VRF и BGP клиента
Что видит клиент«один большой свитч»«один большой роутер» между офисами
Аналогия

IPVPN = корпоративная курьерская служба только для одной компании

У компании офисы по всей стране. IPVPN — как частная курьерская служба, которая возит документы только между офисами этой компании, знает адреса всех филиалов и строит маршруты. Чужие письма туда не попадают, а письма компании не утекают наружу. При этом одна и та же курьерская служба (оператор) обслуживает много компаний — но у каждой своя изолированная «сеть доставки» (VRF).

А почему не просто VPN через интернет?

Резонный вопрос: офисы можно соединить и IPsec-туннелями через обычный интернет — дёшево и без оператора. Почему компании платят за IPVPN? Этот вопрос звучит и от клиентов, и на собеседованиях:

IPsec через интернетIPVPN оператора
Задержка и её стабильностьКак повезёт: путь через десятки чужих сетейПредсказуема: трафик не покидает сеть оператора, есть SLA
Качество для голоса/видеоНикаких гарантийQoS-классы: голос едет в приоритете (раздел 8)
Кто чинит при аварииСам клиент между двумя провайдерамиОператор отвечает за всю связность целиком
Настройка новых офисовТуннели N×N, растут квадратичноПодключил офис к VPN — он видит всех автоматически
ЦенаДёшевоДороже — платишь за гарантии

Типовой рисунок рынка: банки, ритейл-сети с сотнями магазинов, госсектор — на IPVPN (голос, кассы, претензии по SLA); стартапы и малый бизнес — на IPsec/SD-WAN через интернет. А современный тренд — гибрид: основной канал IPVPN + резерв через интернет.

2. Из чего собран IPVPN — три знакомых компонента

Хорошая новость: ничего нового. IPVPN — это три уже изученных механизма, работающих в связке:

VRF — изоляция клиента на каждом PE
На каждом роутере оператора, куда подключён офис клиента, заводится его VRF. Маршруты клиента живут только там (урок 3).
BGP — перенос маршрутов между офисами
eBGP на стыке PE–CE принимает сети клиента, а MP-BGP (VPNv4) внутри сети оператора разносит их между всеми PE клиента (урок 4).
MPLS — транспорт через магистраль
Пакет клиента едет через сеть оператора «в конверте из меток» — быстро и не мешаясь с трафиком других клиентов. Как именно — следующий раздел.
IPVPN: три офиса клиента в разных подсетях, объединённые оператором
Сеть оператора MPLS + MP-BGP (VPNv4) VRF «Ромашка» на каждом PE Офис A · Москва 10.1.0.0/24 CE → PE1 Офис B · Питер 10.2.0.0/24 CE → PE2 Офис C · Казань 10.3.0.0/24 · CE → PE3
Три офиса — три РАЗНЫЕ подсети (10.1 / 10.2 / 10.3). Оператор знает их все (в VRF клиента) и маршрутизирует трафик между ними. Другие клиенты этих маршрутов не видят.

3. MPLS изнутри: метки, P-роутеры и стек из двух меток

До сих пор мы говорили «MPLS доставляет пакет через магистраль» как про чёрный ящик. Откроем его — без этого не понять ни путь пакета, ни половину аварий.

MPLS (Multiprotocol Label Switching) — способ пересылки, при котором роутеры магистрали смотрят не в IP-адрес пакета, а на короткую метку (label) — число, приклеенное перед IP-заголовком. Логика роутера магистрали примитивна: «пришла метка 1021 — заменить на 1044, выкинуть в порт 3». Всё. Никаких таблиц маршрутизации клиентов, никаких VRF.

Роутеры в сети оператора делятся на два сорта — и это важнейшее деление:

PE (provider edge)P (provider)
Где стоитНа краю: к нему подключены клиентыВнутри магистрали: только операторские линки
Знает клиентов?Да: держит VRF, BGP с CEНет. Вообще. Только метки и адреса других роутеров оператора
Что делает с пакетомКладёт в VRF, вешает/снимает меткиМеняет транспортную метку и передаёт дальше

Почему это гениально: у оператора могут быть тысячи клиентов с миллионами маршрутов — а P-роутеры магистрали держат в голове только пару сотен внутренних маршрутов и меток. Вся «клиентская» сложность вынесена на края, ядро остаётся лёгким и быстрым. Метки раздаёт соседям служебный протокол LDP (Label Distribution Protocol) — автоматически, инженер их руками не назначает. Цепочка меток от входного PE до выходного называется LSP (label switched path) — «туннель из меток».

Стек из двух меток

На пакете клиента в магистрали две метки, и у каждой своя работа:

Ethernet-заголовок
MAC линка
Метка 1: транспортная
«довези до PE2» · меняется на каждом P
Метка 2: VPN-метка
«это VRF Ромашка» · не меняется
IP-пакет клиента
10.1.0.5 → 10.2.0.9
Аналогия

Две метки = два стикера на посылке

Внешний стикер — «сортировочный центр Казань» (транспортная метка): его переклеивают на каждом складе по пути. Внутренний стикер — «квартира 14» (VPN-метка): его наклеили при отправке и читает только курьер в Казани. Складам по пути номер квартиры не нужен — и они его не видят.

4. Путь пакета от офиса A к офису B — теперь целиком

Проследим с метками в руках, что происходит, когда ПК в офисе A (10.1.0.5) шлёт пакет в офис B (10.2.0.9):

Офис A → CE → PE1
Пакет уходит на CE клиента, тот по маршруту (узнанному по eBGP от PE1 или статике) отдаёт его на PE1. Пакет прилетает в интерфейс, привязанный к VRF «Ромашка», — и с этого мгновения живёт в мире этой VRF.
PE1 ищет маршрут в VRF
В таблице VRF: 10.2.0.0/24 via 10.255.0.2 (PE2), VPN-метка 2043. Это ему заранее рассказал PE2 по MP-BGP: «сеть 10.2.0.0/24 Ромашки — за мной, вешай метку 2043».
PE1 собирает стек и отправляет
Вешает VPN-метку 2043 (внутреннюю), сверху — транспортную метку до PE2 (например, 1021, узнана по LDP) и отдаёт пакет в магистраль.
P-роутеры: только транспортная метка
Каждый P меняет внешнюю метку (1021 → 1044 → …) и передаёт дальше. В IP-заголовок клиента и VPN-метку не заглядывает. Предпоследний P снимает транспортную метку совсем (PHP).
PE2 → CE → офис B
PE2 видит VPN-метку 2043: «это VRF Ромашка». Снимает её, ищет 10.2.0.9 в таблице VRF, отдаёт пакет на CE офиса B, тот — получателю. Ответ проделает тот же путь в обратную сторону — со своими метками.
Вопрос с собеседования

«Почему P-роутеры не знают маршрутов клиентов и что это даёт?» Ответ: клиентские маршруты переносятся MP-BGP только между PE, а P-роутеры коммутируют по транспортным меткам. Даёт масштабируемость (ядро не пухнет от чужих маршрутов) и изоляцию (пересечение адресов клиентов ядру безразлично). Бонусный балл — упомянуть PHP и то, что iBGP-сессии между PE обычно ходят через route reflector, а не full mesh.

5. Где здесь RD и RT — теперь на практике

Помнишь «страшные» RD и RT из урока про VRF? Вот их момент славы:

Одна фраза, чтобы запомнить навсегда

VRF — изолирует клиента на роутере. RD — не даёт слипнуться одинаковым адресам в транспорте. RT — определяет, какие офисы клиента видят друг друга. MP-BGP — везёт всё это между PE. MPLS — физически доставляет пакет через магистраль. Вот и весь IPVPN.

Игра RT: hub-and-spoke и другие топологии

Пока у всех офисов одинаковые import/export RT — получается full mesh: все видят всех. Но RT — это конструктор. Классическая задача: служба безопасности клиента требует, чтобы филиалы общались только через центральный офис (там файрвол и контроль). Решение — два разных RT:

ПлощадкаExport RTImport RTРезультат
Центр (hub)65000:100 (hub)65000:101 (spoke)Видит все филиалы
Филиал 1 (spoke)65000:10165000:100Видит только центр
Филиал 2 (spoke)65000:10165000:100Видит только центр — филиал 1 для него не существует

Филиалы экспортируют маршруты «для центра» и импортируют только «от центра» — друг друга они не импортируют, значит, и пути друг к другу не знают. Трафик филиал→филиал идёт через hub (если центр анонсирует default в VPN). Тем же приёмом строят extranet — общий сегмент для двух разных компаний (например, клиент и его аутсорсер видят один общий сервер, но не сети друг друга).

6. Разбор руками: закрываем заявку #51907 — третий офис в VPN

Всё готово, чтобы подключить Казань. VRF «Ромашка» уже живёт на PE1 и PE2 (RD 65000:1, RT 65000:100). На PE3-Kazan её ещё нет — создаём с нуля:

! 1. VRF клиента на новом PE — ТЕ ЖЕ RT, что на PE1/PE2 (RD может отличаться) PE3-Kazan(config)# vrf definition ROMASHKA PE3-Kazan(config-vrf)# rd 65000:1 PE3-Kazan(config-vrf)# address-family ipv4 PE3-Kazan(config-vrf-af)# route-target export 65000:100 PE3-Kazan(config-vrf-af)# route-target import 65000:100 ! 2. Порт к CE — сначала vrf forwarding, ПОТОМ адрес (помни ловушку из урока 3!) PE3-Kazan(config)# interface Gig0/2 PE3-Kazan(config-if)# description CUST:Romashka:51907:IPVPN PE3-Kazan(config-if)# vrf forwarding ROMASHKA PE3-Kazan(config-if)# ip address 10.255.13.1 255.255.255.252 PE3-Kazan(config-if)# no shutdown ! 3. eBGP с CE клиента ВНУТРИ VRF PE3-Kazan(config)# router bgp 65000 PE3-Kazan(config-router)# address-family ipv4 vrf ROMASHKA PE3-Kazan(config-router-af)# neighbor 10.255.13.2 remote-as 64512 PE3-Kazan(config-router-af)# neighbor 10.255.13.2 activate PE3-Kazan(config-router-af)# neighbor 10.255.13.2 maximum-prefix 100

Со стороны CE клиента в Казани — обычный eBGP: сосед 10.255.13.1, remote-as 65000, анонс своей сети network 10.3.0.0 mask 255.255.255.0. И теперь — проверка, что заявка закрыта:

! Сессия с CE поднялась? Префикс пришёл? PE3-Kazan# show ip bgp vpnv4 vrf ROMASHKA summary Neighbor V AS ... State/PfxRcd 10.255.13.2 4 64512 ... 1 ← Established, 1 префикс (10.3.0.0/24) ! Дальние офисы появились в VRF на новом PE? PE3-Kazan# show ip route vrf ROMASHKA B 10.1.0.0/24 [200/0] via 10.255.0.1 ← Москва, по MP-BGP от PE1 B 10.2.0.0/24 [200/0] via 10.255.0.2 ← Питер, от PE2 B 10.3.0.0/24 [20/0] via 10.255.13.2 ← Казань, по eBGP от местного CE ! А Казань доехала до Москвы? (проверка с ДАЛЬНЕГО конца — обязательна) PE1-Moscow# show ip route vrf ROMASHKA 10.3.0.0 B 10.3.0.0/24 [200/0] via 10.255.0.3 ← есть: MP-BGP разнёс, RT совпал ! Финал — сквозной пинг между офисами от имени клиентской сети PE1-Moscow# ping vrf ROMASHKA 10.3.0.10 source Gig0/1 !!!!! Success rate is 100 percent ← можно закрывать заявку
Частая ошибка джуна

Скопировать конфиг VRF со старого PE и опечатать RT (65000:10 вместо 65000:100). Всё выглядит идеально: сессия с CE Established, локальный маршрут в VRF есть… а дальние офисы не появляются, и Казань никто не видит. RT — это «клей» всей услуги: при любом «маршруты не доехали» первым делом сравнивай route-target на обоих концах, символ в символ.

7. Что ещё продаётся вместе с IPVPN

Голый «офисы видят друг друга» — это база. Реальные договоры IPVPN обрастают опциями, и заявки по ним будут падать на тебя же:

Интернет из VPN (central breakout)
Филиалам не дают собственный интернет: в центральном офисе стоит файрвол, центр анонсирует в VPN маршрут 0.0.0.0/0, и весь интернет-трафик филиалов идёт через него. Безопасники счастливы: одна точка контроля. Симптом при аварии: «интернет пропал во всех филиалах сразу» — значит, смотри центр, а не филиалы.
QoS-классы
Внутри канала IPVPN трафик делится на классы: «голос» (жёсткий приоритет, малая задержка), «бизнес» (1С, кассы), «всё остальное». Оператор продаёт проценты полосы под классы и honors-маркировку DSCP. Заявка «голос заикается» = смотри, не переполнен ли голосовой класс: show policy-map interface — счётчики drop по классам.
Резервный канал
Второй стык на офис: второй порт, LTE-модем или IPsec через интернет (гибрид). Переключение — BGP-приоритетами (local preference) или floating static. При заявке «офис работает медленно» проверь, не уехал ли он на резерв: show ip route vrf — через какой next-hop идёт трафик?
SLA и мониторинг
По договору оператор обещает доступность (например, 99,9%) и следит за каналом сам: IP SLA-пробы (пинги с PE до CE каждые N секунд) рисуют графики задержки и потерь. Когда клиент говорит «у нас лагало вчера в 15:00» — эти графики твой первый свидетель.

MTU в MPLS: +8 байт, о которых все забывают

Каждая MPLS-метка — 4 байта, стек из двух — 8 байт. Если клиент шлёт полный пакет 1500 байт, в магистрали кадр весит 1508+ байт. Поэтому на операторских линках MTU всегда повышен (1512…9216 — jumbo). Но если где-то в цепочке затесался линк с MTU 1500 (типично: EPL-плечо от другого оператора в середине, урок 6!), большие пакеты начнут молча умирать. Симптом в IPVPN тот же, что в уроке 5: пинг маленькими ходит, RDP/шары/большие страницы виснут. Диагноз изнутри VPN:

PE1# ping vrf ROMASHKA 10.3.0.10 size 1500 df-bit ..... ← полный размер не проходит: ищи узкий MTU на пути LSP PE1# ping vrf ROMASHKA 10.3.0.10 size 1400 df-bit !!!!! ← 1400 ходит. Дальше — двоичный поиск и show interface | include MTU по цепочке

8. Как читать состояние услуги — сводка команд

! маршруты клиента на этом PE (сети всех его офисов) PE1# show ip route vrf ROMASHKA C 10.1.0.0/24 is directly connected, Gig0/1 ← локальный офис A B 10.2.0.0/24 [200/0] via 10.255.0.2 ← офис B, узнан по MP-BGP от PE2 B 10.3.0.0/24 [200/0] via 10.255.0.3 ← офис C, от PE3 ! VPNv4-маршруты (с RD и RT) — «внутренняя кухня» IPVPN PE1# show bgp vpnv4 unicast vrf ROMASHKA Route Distinguisher: 65000:1 (VRF ROMASHKA) *>i 10.2.0.0/24 10.255.0.2 RT:65000:100 ← сеть офиса B, метка «свой клиент» ! Каким LSP и с какими метками поедет трафик до PE2 PE1# show mpls forwarding-table 10.255.0.2 Local Outgoing Prefix Outgoing interface Next Hop 1021 1044 10.255.0.2/32 Gig1/0 172.16.0.2 ← транспортная метка живёт ! Сквозная проверка связности внутри VPN клиента PE1# ping vrf ROMASHKA 10.2.0.9 !!!!! Success rate is 100 percent ! Трассировка в VRF: видно и хопы, и MPLS-метки по пути PE1# traceroute vrf ROMASHKA 10.2.0.9 1 172.16.0.2 [MPLS: Labels 1044/2043] 1 ms ← стек: транспортная/VPN 2 10.255.0.2 1 ms ← вышли на PE2 3 10.2.0.9 2 ms

9. Плейбук: «офис A не видит офис B» — полная цепочка

Это самая частая заявка по IPVPN, и теперь у тебя есть знания для полного разбора. Пройди цепочку в этом порядке — она покрывает практически все случаи:

Стык с ближним офисом жив?
На PE1: ping vrf ROMASHKA 10.1.0.1 (CE офиса A). Нет — плейбуки уроков 1–2: порт, ARP, адреса. Дальше не иди, пока не оживёт.
Маршрут дальнего офиса есть в VRF?
show ip route vrf ROMASHKA 10.2.0.0. Есть (буква B, via loopback PE2) — иди к шагу 5. Нет — дальше.
А объявляет ли его дальняя сторона?
На PE2: show ip bgp vpnv4 vrf ROMASHKA summary — сессия с CE офиса B Established? PfxRcd > 0? Если нет — плейбуки урока 4 (сессия/объявления) на дальнем стыке.
Объявляет, но маршрут не доехал до PE1? Проверь RT и iBGP
Сравни на обоих PE: show run vrf ROMASHKA — RT export на PE2 должен совпадать с RT import на PE1 символ в символ. Разные RT — классическая причина «всё настроено, а маршрутов нет». Заодно проверь, жив ли MP-BGP между PE: show bgp vpnv4 unicast all summary (сессии с route reflector Established?).
Маршрут есть, а трафик не ходит? Транспорт: LSP и обратный путь
ping vrf ROMASHKA 10.2.0.9 source Gig0/1 — от имени ближнего офиса. Не проходит при живых маршрутах — два подозреваемых: LSP (show mpls forwarding-table до loopback PE2 — есть ли метка? «No Label» = беда с LDP, эскалируй на магистральную команду) и обратный маршрут: до 10.1.0.0/24 с PE2 тоже должен быть маршрут — связь всегда двусторонняя.
Ходит, но «виснет» и «тормозит»? MTU и QoS
Маленький пинг ходит, приложения виснут — ping vrf … size 1500 df-bit (раздел 7, MTU). Голос заикается, файлы качаются — show policy-map interface: drops в голосовом классе или полка полосы.
Всё проходит? Тогда проблема внутри офиса клиента
Отвечай фактами: стык жив, маршруты обоих офисов на месте, сквозной пинг через нашу сеть проходит, потерь и превышений класса нет — проверьте локальные файрволы/маршруты на своих площадках. Факты в тикете = быстрые закрытия без пинг-понга.

10. Мини-лаба: потрогай MPLS и спроектируй VPN сам

Найди MPLS в живой трассировке
Открой Looking Glass любого крупного оператора (ищи «looking glass» + имя оператора; у многих есть публичные, например lg.he.net) и запусти traceroute до любого далёкого адреса. В выводе многих хопов увидишь [MPLS: Label 24015 Exp 0] — это те самые транспортные метки магистрали, через которую едет твоя трассировка. Windows tracert метки не показывает, а Linux traceroute и роутерные — да.
Спроектируй IPVPN на бумаге (10 минут, как на собеседовании)
Дано: клиент «Кактус», 4 офиса (Москва — центр, 3 филиала), требование СБ: филиалы общаются только через Москву. Напиши: подсети офисов (без пересечений!), RD, пары import/export RT для hub и spoke (раздел 5), и какой офис анонсирует default. Сверь себя с таблицей hub-and-spoke выше — совпала логика?
Прочитай чужой разбор аварии
Загугли «MPLS VPN route-target mismatch troubleshooting» и пролистай любой разбор с выводами команд. Проверь себя: ты теперь понимаешь каждую команду в таких статьях — show ip route vrf, show bgp vpnv4, show mpls forwarding-table. Это и есть рабочий уровень.

11. Словарик урока

ТерминПо-английскиСмысл в одну строку
IPVPN / L3VPNIP VPN, MPLS L3VPNчастная маршрутизируемая сеть офисов клиента поверх сети оператора
MP-BGP / VPNv4Multiprotocol BGP«расширенный» BGP, который возит клиентские маршруты с RD/RT и VPN-метками между PE
MPLSMPLSпересылка по меткам вместо IP-адресов — быстро и изолированно
Метка / стек метокlabel / label stackярлыки на пакете: транспортная («до какого PE») + VPN («в какую VRF»)
LDPLabel Distribution Protocolслужебный протокол: роутеры сами раздают друг другу транспортные метки
LSPlabel switched pathцепочка меток от входного PE до выходного — «туннель» через магистраль
PHPpenultimate hop poppingпредпоследний роутер снимает транспортную метку, разгружая выходной PE
P-роутерprovider routerвнутренний роутер магистрали — двигает метки, клиентов не знает
Route reflectorRR«разносчик» iBGP: PE держат сессию с ним, а не каждый с каждым
Full mesh / hub-and-spoke—топологии VPN: «все видят всех» / «все через центр» (строится игрой RT)
Extranetextranet VPNобщий сегмент двух разных клиентов через перекрёстный импорт RT
Central breakout—интернет для всех офисов через центральную площадку (default в VPN из центра)
QoS-классыclass of service, CoSделение полосы VPN на приоритеты: голос / бизнес / остальное
IP SLAIP SLA probesавтопинги оператора для контроля задержки/потерь по договору SLA

12. Итог всего пути

Ты прошёл дорогу от «что такое IP-адрес» до реальных услуг оператора. Собери картинку целиком:

🔌 EPL — L2

  • Возит кадры по MAC
  • У оператора нет IP
  • Два офиса, одна подсеть
  • «Один длинный патч-корд»

🏢 IPVPN — L3

  • Маршрутизирует пакеты по IP
  • Оператор держит VRF+BGP клиента
  • Много офисов, разные подсети
  • «Один большой частный роутер»

🌍 IP access — L3

  • Выход в Интернет
  • Белые адреса, стык /30
  • Статика или BGP
  • «Съезд на общую трассу»
IPVPN (L3VPN) объединяет много офисов клиента в одну частную сеть и маршрутизирует трафик между ними. Он собран из знакомых кубиков: VRF изолирует клиента на PE, MP-BGP разносит его маршруты между PE (вместе с RD, RT и VPN-меткой), MPLS доставляет пакеты через магистраль стеком из двух меток — P-роутеры видят только транспортную и клиентов не знают. Игрой RT строятся full mesh, hub-and-spoke и extranet. Диагностика — show ip route vrf, show bgp vpnv4, show mpls forwarding-table, ping/traceroute vrf; вечная классика аварий — несовпавший RT и зажатый MTU на пути LSP.
Задача 1. Подключил новый офис: eBGP с CE Established, PfxRcd 1, локальный маршрут в VRF есть. Дальние офисы новый офис не видят, и их маршрутов на новом PE нет. Куда смотреть?

Классика: RT не совпал (опечатка при создании VRF на новом PE) либо не работает MP-BGP до остальных PE. Проверь show run vrf на новом и старом PE — import/export RT символ в символ; затем show bgp vpnv4 unicast all summary — сессия с route reflector Established?

Задача 2. Маршруты в VRF на обоих PE идеальны, а ping vrf между офисами не ходит. Назови два подозреваемых и команды.

1) Транспорт (LSP): show mpls forwarding-table <loopback дальнего PE> — если «No Label», сломан LDP на пути, эскалация на магистраль. 2) Обратный маршрут: на дальнем PE show ip route vrf … <ближняя сеть> — связь двусторонняя, ответным пакетам тоже нужна дорога.

Задача 3. Заявка: «RDP между офисами виснет, пинг ходит». VPN живой, маршруты на месте. Диагноз одной командой?

ping vrf ROMASHKA <дальний адрес> size 1500 df-bit. Не проходит — MTU-блэкхол на пути LSP (где-то линк без запаса под 8 байт меток — часто арендованное L2-плечо). Двоичным поиском найди потолок, затем ищи узкий линк по цепочке или включай adjust-mss на CE.

Задача 4. СБ клиента требует: филиалы не должны видеть друг друга, только центр. Что настроишь?

Hub-and-spoke игрой RT: центр export RT-hub / import RT-spoke; филиалы export RT-spoke / import RT-hub. Филиалы не импортируют RT друг друга — и путей друг к другу не имеют. Трафик филиал→филиал возможен только через центр, если тот отдаёт default в VPN.

Задача 5. «Интернет пропал во всех 40 филиалах одновременно», IPVPN между офисами работает. Где авария?

У клиента central breakout: интернет для филиалов раздаёт центральная площадка (default из центра в VPN). Сорок одновременных аварий в филиалах не бывает — смотри центр: жив ли его стык, анонсируется ли default в VPN (show ip route vrf … 0.0.0.0 на PE филиала), жив ли файрвол центра.

Задача 6. Голос между офисами заикается в часы пик, файлы качаются нормально. Что проверить у оператора?

QoS-класс голоса: show policy-map interface на стыках — есть ли drops в приоритетном классе. Типовые причины: голосовой класс переполнен (клиент шлёт больше, чем купил под голос) или маркировка DSCP теряется по пути. Файлам хорошо, потому что их класс не приоритетный, но широкий.

Главное отличие IPVPN от EPL в одном предложении?

EPL — это L2 (оператор возит кадры, офисы в одной подсети, у оператора нет IP), а IPVPN — это L3 (оператор маршрутизирует пакеты по IP, офисы в разных подсетях, оператор держит VRF и BGP клиента).

Какие три технологии собирают IPVPN вместе?

VRF (изоляция клиента), MP-BGP/VPNv4 (перенос маршрутов между PE) и MPLS (транспорт через магистраль). Плюс RD/RT как «ярлыки» на маршрутах и VPN-метка для выходной VRF.

Зачем на пакете ДВЕ метки и кто какую читает?

Транспортная (внешняя) — «до какого PE», её меняет каждый P-роутер; VPN-метка (внутренняя) — «в какую VRF на выходе», её назначил выходной PE через MP-BGP, и читает только он. P-роутеры внутреннюю метку и IP клиента не смотрят вообще.

Офис A не видит офис B, хотя оба настроены. Что часто виновато?

Несовпадение RT импорта/экспорта на разных PE, либо не поднялся eBGP с CE второго офиса. Проверяй маршрут в VRF, состояние BGP на дальней стороне и совпадение RT.

Клиент хочет соединить 15 офисов в разных городах в одну сеть с маршрутизацией. Какая услуга?

IPVPN (L3VPN). EPL тут не подойдёт — он точка-точка и L2; для 15 маршрутизируемых площадок нужен именно L3VPN.

Чем IPVPN лучше IPsec-туннелей через интернет — три аргумента для клиента?

Предсказуемая задержка (трафик не покидает сеть оператора, SLA), QoS для голоса и видео (в интернете гарантий нет), один ответственный за связность (оператор чинит всё, а не «два провайдера кивают друг на друга»). Плюс новые офисы подключаются без перестройки туннелей.

13. Чек-лист выпускника пути

Пройдись по списку честно. Каждый пункт — то, что реально спрашивают на работе и собеседовании:

Могу объяснить соседу-гуманитарию, что такое IP, маска и шлюз

Урок 1. Адрес устройства; граница «улица/квартира»; выход в другие сети. Плюс: /30 и /31 на стыках, loopback /32, серые и белые адреса, «сосед или чужой».

Знаю, что происходит между «ping 8.8.8.8» и первым ответом

Урок 2. Определение «чужая сеть» → ARP-запрос на шлюз → кадр шлюзу с IP получателя внутри → подмена MAC на каждом хопе. И умею читать show ip arp со всеми состояниями.

Не забываю «vrf ИМЯ» ни в одной команде при работе с клиентом

Урок 3. show ip route vrf, ping vrf, show ip arp vrf. Помню ловушку: vrf forwarding стирает IP с интерфейса. Могу объяснить RD и RT одной фразой каждый.

По show ip bgp summary за 10 секунд говорю, что с сессией

Урок 4. Число = ОК; Idle/Active — чини связность; OpenSent — сверяй AS; 0 префиксов — фильтры или network; флап — думай про MTU. И всегда: сначала ping, потом BGP.

Отличаю три услуги и знаю, что у каждой проверять

Уроки 5–7. IP access — L3-доступ в мир (порт → пинг → маршруты → обратный путь → сквозной трафик). EPL — L2-провод (PW UP? MAC ходят? MTU?). IPVPN — VRF+BGP+MPLS (маршрут в VRF → BGP на дальней стороне → RT → LSP → сквозной пинг).

Могу спроектировать hub-and-spoke и объяснить, почему филиалы не видят друг друга

Урок 7. Разные export/import RT у hub и spoke: филиалы не импортируют маршруты друг друга. Default из центра — и весь межфилиальный трафик идёт через файрвол СБ.

Что дальше

Этот путь дал прикладной срез для работы. Следующий уровень глубины — трек «Сети передачи данных — для инженера»: там OSPF, STP, полный BGP с атрибутами выбора пути, MPLS изнутри, packet capture и troubleshooting уровня CCNA→CCNP. А если тянет в сторону Linux и автоматизации — начни параллельно Linux-трек: связка «сеть + Linux» — самый короткий путь в DevOps.

14. Источники

IPVPN — это три стандарта, собранные в одну услугу. Ниже — какой из них отвечает за какую часть картинки, чтобы любое утверждение урока можно было проверить за один клик.