Теоретические основы и архитектура

План внедрения (Implementation & Build Plan) превращает проект из sp-design в последовательность фаз: у каждой есть вход, действие, гейт (команды и пороги Pass/Fail) и откат, выбранный до начала работ. 0. Страховка: бэкап конфигураций, NTP, syslog, OOB-доступ. 1. Линки и MTU: адреса /30 и MTU 1600 на всех линках ядра, проверка ping 1600 с DF. 2. IS-IS и BFD: Loopback0, IS-IS Level-2 с wide-метриками, BFD 100 мс x 3. 3. SR-MPLS и TI-LFA: SRGB 16000-23999, индексы SID, проверка покрытия TI-LFA и меток в LFIB (LDP не используется). 4. BGP RR: сессии PE-RR1/RR2 с семействами vpnv4 и evpn. 5. Сервисы: пилотный VRF A, затем B и EVI 300. 6. QoS: политики и очереди. 7. BNG, OAM и автоматизация: BNG на PE3, телеметрия, Ansible. Порядок не случаен: каждая фаза использует результат предыдущей (MTU до IS-IS, SR после IGP, BGP после SR, BNG последним). Гейты выражены командами и числами, а откат проверяется в лаборатории (тест T12 из sp-acceptance).

Фаза как единица изменения

План внедрения превращает проект из sp-design в последовательность изменений, каждое из которых можно проверить и откатить независимо. Фаза состоит из четырёх частей: вход (что должно быть исправно до начала), действие (конфигурация), гейт (команды и пороги Pass/Fail) и откат (как вернуться за минуты, а не часов). Если у фазы нет гейта, следующая фаза строится на непроверенном основании; если нет отката, ошибка в окне работ превращается в аварию.

ФазаЧто вводимГейт (Pass)Откат
0. Страховкабэкап конфигурации, NTP, syslog на 10.255.0.60, OOB-доступбэкап читается, часы синхронны, доступ по OOB без ядране нужен (только добавление)
1. Линки и MTUадреса /30, MTU 1600 на всех линках ядраping 1600 DF через каждый линк без потерьвернуть MTU и адрес на интерфейсе
2. IS-IS и BFDLoopback0, IS-IS L2, wide-метрики, BFD 100x38 loopback в таблице, соседи UP, BFD Upубрать IS-IS с интерфейсов
3. SR-MPLS и TI-LFASRGB 16000-23999, индексы SID, TI-LFAв LFIB метки 16001-16101, покрытие TI-LFA 100%no segment-routing / отключить SR в IS-IS
4. BGP RRсессии PE-RR1/RR2, vpnv4 и evpnEstablished, обе сессии, PfxRcd как ожидаетсяотключить neighbor/peer
5. Сервисы (пилот)VRF A, затем B и EVI 300, PE-CE eBGPping CE-CE, нет утечек, 1500 DF проходитудалить VRF/EVI с интерфейса
6. QoSполитики ingress/egress и очередисчётчики классов растут, EF без потерь в тестеснять service-policy
7. BNG, OAM, автоматизацияPE3 BNG, телеметрия, Ansible check-modeсессия PPPoE, поток IPFIX, пустой diff Ansibleотключить сервис-политику, остановить экспорт

Порядок и зависимости

Порядок не случаен: каждая фаза использует результат предыдущей. MTU вводится первым, потому что IS-IS дополняет hello-пакеты до размера интерфейса, и несовпадение MTU проявляется именно на этапе смежности; если заранее отключить hello padding (экономия полосы), смежность поднимется, а проблема всплывёт позже на больших пакетах. SR вводится после IGP, потому что Prefix-SID анонсируются в LSDB IS-IS; BGP после SR, потому что next-hop PE должен резолвиться в метку; сервисы после BGP; QoS перед тем, как пускать боевой трафик, а BNG последним, потому что он создаёт нагрузку и требует работающих VRF, RADIUS и NAT. Новый узел вводится с установленным overload-битом IS-IS (Cisco set-overload-bit on-startup, Junos overload timeout), чтобы трафик не пошёл через него до завершения синхронизации.

Откат: что и когда использовать

Откат выбирается до начала работ, а не после ошибки.

ПлатформаСтраховка до измененияОткат
Cisco IOS-XEcopy running-config flash:pre-sp.cfg, configure terminal revert timer 10configure confirm фиксирует изменения; без подтверждения за 10 минут конфигурация вернётся; ручной откат - configure replace flash:pre-sp.cfg force
Juniper Junosrequest system configuration rescue savecommit confirmed 10: без второго commit изменения откатятся; rollback 1 + commit для ручного отката
Huawei VRPsave pre-sp.zip до начала фазыsave выполняется только после прохождения гейта; до этого перезагрузка возвращает сохранённую конфигурацию
MikroTik RouterOS v7/system/backup/save, /export file=Safe Mode в CLI (Ctrl+X): при потере связи изменения откатываются; /import экспортированной конфигурации

Правило окна работ: общее время 4 часа, каждая фаза имеет бюджет; если фаза использовала более половины бюджета без прохождения гейта, выполняется откат и фаза переносится. Откат, который не проверялся, считается несуществующим: в тесте T12 из sp-acceptance он выполняется в лаборатории.

Гейты: числа вместо «вроде работает»

Гейт - это команда и ожидаемое значение. Фаза 2: в show isis neighbors ровно столько соседей, сколько линков в таблице плана (на PE2 - два, на P1 - шесть). Фаза 3: для каждого из восьми SID есть запись в LFIB, а show isis backup coverage или show isis fast-reroute ti-lfa показывает полное покрытие. Фаза 4: две сессии на каждый PE и ожидаемое число принятых префиксов (при пустом пилоте PfxRcd = 0 на PE, на RR - число PE-клиентов). Фаза 5: ping с 1500 DF между CE и подтверждение, что в VRF A нет префиксов клиента B. Любой гейт можно выразить как утверждение для автоматической проверки, и это соединяет план с уроками по Ansible и Python: после каждой фазы CI-задача выполняет те же show и сравнивает числа.

Пилот и перевод клиентов

Первым сервисом вводится пилотный VRF A с одним префиксом на каждом PE; до подключения боевых клиентов собирается эталон: вывод show до и после фазы, счётчики, результаты ping размером 1500. Клиенты B и C включаются по одному, с интервалом наблюдения не менее суток для B (Inter-AS: стык с чужой AS, ограничение по maximum-prefix). Абоненты BNG вводятся партиями по 500, потому что RADIUS и NAT-пул масштабируются нелинейно. Эталоны сохраняются как evidence для защиты в sp-defense-lab.

Схема архитектуры и топология

text
Implementation Phasing Workflow:
+-------------+   +-------------+   +-------------+   +-------------+
| 0. Safety   |-->| 1. Links    |-->| 2. IS-IS    |-->| 3. SR-MPLS  |
| backup, NTP |   | /30, MTU    |   | + BFD       |   | + TI-LFA    |
| syslog, OOB |   | 1600        |   | 100 ms x 3  |   | 16000-23999 |
+-------------+   +-------------+   +-------------+   +-------------+
                                                             |
      +------------------------------------------------------+
      v
+-------------+   +-------------+   +-------------+   +-------------+
| 4. BGP RR   |-->| 5. Services |-->| 6. QoS      |-->| 7. BNG, OAM |
| vpnv4, evpn |   | pilot A,    |   | classes,    |   | telemetry,  |
| 2 sessions  |   | then B, C   |   | queues      |   | Ansible     |
+-------------+   +-------------+   +-------------+   +-------------+

Схема прохождения трафика и стек меток