Маршрутизація філій MPLS: що дізнається CE і від кого

Хост в одній філії відкриває з'єднання із сервером в іншій, і обидва майданчики стоять за однією керованою мережею MPLS VPN рівня 3. Хост знає лише свій шлюз за замовчуванням і більше нічого, що правильно. Важливо те, що локальний клієнтський край передає пакет своєму краю провайдера, а стан маршрутизації VPN у провайдера доставляє його до філії, якій належить префікс призначення.

Простежити один пакет по всьому шляху — найшвидший спосіб побачити, яка частина є відповідальністю клієнта, а яка належить послузі.

10.20.0.0/24 → CE-A → PE → provider core → PE → CE-B → 10.30.0.0/24

Де закінчується робота кожного хопа

CE-A потрібен маршрут до віддаленої LAN, що вказує на його локальне підключення до провайдера, а не на WAN-адресу віддаленої філії. Далі провайдер несе пакет через власне ядро, використовуючи стан маршрутизації VPN, а CE-B доставляє його в цільову LAN. Ні в який момент хосту не потрібно розуміти мітки, VRF або інтернет-канал протилежного боку.

Помилка, яка постійно трапляється в заявках, — налаштування WAN-адреси філії B як наступного хопа у філії A. Обидві філії купили ту саму послугу, тому здається, що вони мають бути сусідами. Але це не так: наступний хоп має бути досяжним через ту схему маршрутизації, яка у вас справді є, а віддалений CE зазвичай розташований за багато хопів, за обладнанням, яким ви не керуєте. Статичний маршрут, побудований на цьому припущенні, відображається як активний і ні в що не розв'язується, що гірше за відсутній маршрут, бо в таблиці він виглядає правильним.

RFC 4364 відокремлює обмін між краєм клієнта та краєм провайдера від поширення VPN-маршрутів провайдером, і це саме та межа, про яку йдеться в цьому посібнику. Завдання клієнта — повідомити своєму краю, що він може доставити, і прийняти досяжність, яку послуга пропонує у відповідь.

Про що має домовитися передача

Обирайте механізм разом із провайдером, а не в обхід нього. Статичні маршрути, BGP або угода про протокол маршрутизації між CE і PE — усе це законно, і OSPF має визначену модель MPLS VPN для такої передачі. Ніщо з цього не є причиною будувати сусідство OSPF між двома віддаленими краями клієнта через неозначене ядро провайдера, бо це схема, з якою провайдер не погодився і яку не може підтримувати.

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

Потім простежте відповідь. Філії B потрібен маршрут назад до вихідної LAN, а хосту на приймальному боці потрібні власний шлюз і власні дозволи на послугу. Маршрут, що з'явився на CE-A, встановлює половину кругового шляху, і саме половина шляху є причиною того, що один напрямок тесту ping виглядає здоровим, поки застосунок усе ще не працює.

Перевірте обидві передачі до приймання

Зберіть стан маршрутизації на обох краях клієнта, підтвердьте у провайдера, що потрібні префікси LAN прийняті в VPN, а потім перевірте один дозволений застосунок у кожному напрямку. Самі таблиці маршрутів не доводять, що застосунок працює, а один тест застосунку не каже, яка площина керування відмовила, коли він не працює.

show ip route vrf BRANCH 10.30.0.0
show ip bgp vpnv4 vrf BRANCH
show ip cef vrf BRANCH 10.30.0.10

Читайте три виводи разом. Перший каже, у що вірить край, другий — що він дізнався і від якого партнера, третій — що він насправді передаватиме. Розбіжність між ними зазвичай є проблемою політики або рекурсії, а не відсутнім анонсом, і її варто усунути до того, як просити провайдера провести розслідування. Принесіть ці три виводи на розмову з оператором, бо вони відповідають на більшість питань, які інженер підтримки інакше поставив би вам.

Знайте, чого послуга не надає

Це маршрутизований доступ рівня 3. Це не канал рівня 2, який розширює широкомовлення між офісами, тому протоколи виявлення, застосунки, що залежать від широкомовлення, і припущення про спільний сегмент із ним не подорожують. Друк, перегляд імен і все, що залежить від локального сегмента, потребує власної схеми.

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

Нарешті, тримайте модель послуги записаною поруч із конфігурацією маршрутизації майданчика. Наступний інженер, який додасть підмережу, має побачити, які префікси анонсуються, хто їх приймає і яким є очікуваний зворотний шлях: специфікація BGP/MPLS IP VPN є орієнтиром для моделі, що стоїть за всім цим.