Маршрутизация филиалов 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 является ориентиром для модели, стоящей за всем этим.

Похожие статьи