Пиринг поднят уже недели, число префиксов выглядит правильным, и всё же трафик одного клиента идёт длинным путём или вообще не доходит. Один и тот же индикатор оценивает две разные вещи. Сессия BGP сообщает, что два пира могут обмениваться сообщениями по TCP-соединению; о том, способен ли оверлей нести помеченный пакет именно для этого клиента, она не говорит ничего.

Этот разрыв проще всего увидеть в схеме MPLS поверх DMVPN, где путь через хаб и прямой путь через spoke могут вести себя по-разному по причинам, не связанным с пирингом.

Что сессия действительно доказывает

BGP работает поверх TCP, поэтому каждому пиру сначала нужен маршрут к адресу другого конца. Если выбрать loopback в качестве такого конца, вы создали требование достижимости, а не гарантию пересылки. После этого сессия может оставаться поднятой через интерфейс, который трафик клиента никогда не использовал бы.

Прежде чем делать выводы, зафиксируйте четыре факта на обоих концах: адрес источника сессии, адрес назначения, контекст маршрутизации, в котором она находится, и интерфейс, который ядро или маршрутизатор выбрали бы для этой пары. Эти факты описывают плоскость управления. Пакеты клиента добавляют поверх VRF, стек меток и сопоставление оверлея.

Четыре механизма, а не один

Документация Cisco по MPLS поверх DMVPN чётко разделяет части. MP-BGP распространяет метки оверлея клиента между устройствами на краю провайдера. MPLS использует эти метки для выбора контекста пересылки пакета. NHRP сопоставляет адрес оверлея с транспортным концом, который нужен динамическому туннелю. IPsec защищает путь между пирами там, где это применимо.

Любой из четырёх может быть правильным, а другой — ошибочным, и трафик несёт именно сочетание. Обмен маршрутами может завершиться, когда привязка метки для одного VRF отсутствует, когда сопоставление NHRP указывает на устаревший транспортный адрес или когда туннель есть, но ни одна политика не пропускает внутренний пакет. Ни одно из этих условий не роняет сессию.

Сравните путь через хаб с коротким путём, по одной переменной

Зафиксируйте хост-источник, хост-назначение и VRF, затем дважды проследите один и тот же поток. На пути через хаб отметьте следующий хоп, сервисную метку, определяющую контекст удалённого клиента, и используемое сопоставление оверлея с транспортом. На предполагаемом прямом пути отметьте те же три вещи. Разница между двумя списками и есть неисправность или её отсутствие.

Держите поток неизменным во время сравнения. Смена хоста-источника, VRF или назначения между наблюдениями даёт две несвязанные истории, и это самый частый способ испортить упражнение.

Держите тесты loopback в отдельном отсеке

Ping с loopback маршрутизатора — полезный тест, и он проверяет иной случай, чем поток с хоста. Адрес источника принадлежит маршрутизатору, контекст маршрутизации может быть глобальным, а не VRF, а обратный путь может отличаться от того, которым пошёл бы префикс клиента. Поэтому отвечающий loopback и приложение, работающее через короткий путь, — разные результаты, и только второй описывает клиента.

Проверьте оба, затем отметьте их отдельно в своих записях. Когда они расходятся, вы узнали нечто конкретное о том, где схема отклоняется, и это больше, чем когда-либо скажет одна зелёная галочка.

Утверждения о версии и о дефекте требуют собственных доказательств

Полевые отчёты иногда рекомендуют сменить маску хоста или адрес источника BGP, и такие отчёты стоит читать только вместе с дефектом, о котором они написаны, и затронутыми выпусками. Обходное решение из одного выпуска не является утверждением, что архитектура не поддерживает ни один префикс /32.

Используйте документацию, соответствующую вашей фазе DMVPN, платформе и выпуску, и помните, что одна глава может охватывать несколько схем, включая FlexVPN. Пример из одной схемы не переносится молча на другую. Выберите концы сессии под ту схему плоскости управления, которая вам действительно нужна, а затем отдельно проверьте путь пересылки клиента, потому что переписывание каждой маски loopback не заменяет выяснение того, какая задача не сработала.

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