Подробный обзор маршрутизации Виртуальной глобальной сети

Azure Виртуальная глобальная сеть — это сетевое решение, которое позволяет легко создавать сложные топологии сети: она включает маршрутизацию между виртуальными сетями Azure и локальными расположениями через VPN типа "точка — сеть", VPN типа "сеть — сеть", ExpressRoute и интегрированные устройства SDWAN, включая возможность защиты трафика. В большинстве сценариев вам не требуется глубокое знание того, как работает внутренняя маршрутизация Виртуальная глобальная сеть, но в определенных ситуациях это может быть полезно для понимания концепций маршрутизации Виртуальная глобальная сеть.

В этом документе рассматриваются примеры сценариев Виртуальной WAN, которые объясняют некоторые особенности поведения, с которыми могут столкнуться организации при подключении виртуальных сетей и филиалов в сложных сетях. Сценарии, показанные в этой статье, не являются рекомендациями по проектированию, они просто примеры топологий, предназначенных для демонстрации определенных функций Виртуальная глобальная сеть.

Сценарий 1. Топология с предпочтительной маршрутизацией по умолчанию

Первый сценарий в этой статье анализирует топологию с двумя узлами виртуальной сети WAN, подключением ExpressRoute, VPN и SDWAN. В каждом концентраторе есть виртуальные сети, подключенные напрямую (виртуальные сети 11 и 21) и косвенно через NVA (виртуальные сети 121, 122, 221 и 222). Виртуальная сеть 12 обменивается данными маршрутизации с концентратором 1 через BGP (см . пиринг BGP с виртуальным концентратором), а виртуальная сеть 22 имеет статические маршруты, чтобы можно было отображать различия между обоими параметрами.

В каждом концентраторе устройства VPN и SDWAN служат двойной целью: на одной стороне они объявляют свои собственные отдельные префиксы (через VPN в концентраторе 1 и по SDWAN в концентраторе 2), а в других они объявляют те же префиксы, что и каналы ExpressRoute в одном регионе (10.4.1.0/2410.5.3.0/24в концентраторе 1 и 10.4.2.0/2410.5.2.0/24 в концентраторе 2). Это различие будет использоваться для демонстрации того, как работает предпочтение маршрутизации концентратора Виртуальной глобальной сети.

Все подключения виртуальных сетей и ветвей связаны и фиксируются в заданной по умолчанию таблице маршрутизации. Хотя центры защищены (в каждом концентраторе развернуты Брандмауэр Azure), они не настроены для защиты частного или интернет-трафика. Это приведет к тому, что все подключения попадут в None таблицу маршрутов, тем самым удалив все нестатические маршруты из Default таблицы маршрутов, и это нарушит цель этой статьи, так как эффективный маршрутный лист на портале будет почти пуст (за исключением статических маршрутов для передачи трафика в Брандмауэр Azure).

Внимание

На предыдущей схеме показаны два защищенных виртуальных концентратора. Эта топология поддерживается целями маршрутизации. Дополнительные сведения см. в разделе "Настройка намерений маршрутизации и политик маршрутизации центра Виртуальная WAN".

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

Затем эти действенные маршруты будут объявлены виртуальной глобальной сетью филиалам и будут внедрены в виртуальные сети, подключенные к виртуальным концентраторам, что делает использование маршрутов, определяемых пользователем, ненужным. При проверке действующих маршрутов в виртуальном концентраторе поля "Тип следующей точки маршрутизации" и "Источник" указывают источник маршрутов. Например, тип следующего прыжка "Подключение к виртуальной сети" указывает, что префикс определен в виртуальной сети, напрямую подключенной к Виртуальной глобальной сети (виртуальные сети 11 и 12 на предыдущем снимке экрана).

NVA в виртуальной сети 12 внедряет маршрут 10.1.20.0/22 по протоколу BGP, поскольку тип следующего прыжка "HubBgpConnection" подразумевает (см. BGP-пиринг с виртуальным концентратором). Этот сводный маршрут охватывает как косвенные спицы виртуальной сети 121 (10.1.21.0/24), так и виртуальной сети 122 (10.1.22.0/24). Виртуальные сети и ветви в удаленном концентраторе отображаются с помощью следующего прыжка hub2. Как можно заметить в пути AS, номер 65520 автономной системы был дважды добавлен к этим маршрутам между концентраторами.

В концентраторе 2 есть интегрированный виртуальный сетевой модуль SDWAN. Дополнительные сведения о поддерживаемых NVAs для этой интеграции см. в разделе О NVAs в виртуальном узле WAN. Обратите внимание, что следующий прыжок для маршрута 10.5.3.0/24 к ветви SDWAN — VPN_S2S_Gateway. В настоящее время этот тип следующего прыжка может указывать на маршруты от шлюза виртуальной сети Azure или от NVA, интегрированных с концентратором.

В концентраторе 2 маршрут от 10.2.20.0/22 к непрямым периферийным сегментам виртуальной сети VNet 221 (10.2.21.0/24) и VNet 222 (10.2.22.0/24) устанавливается как статический маршрут, согласно источнику defaultRouteTable. Если вы проверите действующие маршруты для концентратора 1, этого маршрута там нет. Причина заключается в том, что статические маршруты не распространяются через BGP, но необходимо настроить в каждом концентраторе. Таким образом, статический маршрут необходим в концентраторе 1, чтобы обеспечить подключение между виртуальными сетями и филиалами в концентраторе 1 и опосредованными сетями в концентраторе 2 (виртуальные сети 221 и 222).

После добавления статического маршрута концентратор 1 будет содержать маршрут 10.2.20.0/22:

Сценарий 2. Глобальное охват и предпочтительная маршрутизация концентратора

Даже если концентратор 1 знает префикс ExpressRoute из канала 2 (10.5.2.0/24) и концентратор 2 знает префикс ExpressRoute из канала 1 (10.4.2.0/24), маршруты ExpressRoute из удаленных регионов не объявляются обратно к локальным ссылкам ExpressRoute. Следовательно, ExpressRoute Global Reach требуется для связи между расположениями ExpressRoute:

Внимание

На предыдущей схеме показаны два защищенных виртуальных концентратора, эта топология поддерживается с намерением маршрутизации. Дополнительные сведения см. в статье Как настроить намерения маршрутизации и политики маршрутизации в центре Виртуальной глобальной сети.

Как описано в предпочтениях маршрутизации виртуального концентратора, Виртуальная глобальная сеть предпочитает маршруты, поступающие из ExpressRoute по умолчанию. Так как маршруты объявляются из концентратора 1 в канал ExpressRoute 1, из канала ExpressRoute 1 в канал 2, а также из канала ExpressRoute 2 в концентратор 2 (и наоборот), виртуальные концентраторы теперь предпочитают этот путь вместо более прямой связи между концентраторами. Действующие маршруты в узле 1 выглядят следующим образом:

Как вы видите на маршрутах, ExpressRoute Global Reach предварительно добавляет номер автономной системы ExpressRoute (12076) несколько раз, прежде чем отправлять маршруты обратно в Azure, чтобы сделать эти маршруты менее предпочтительнее. Однако заданная по умолчанию в концентраторе Виртуальной глобальной сети предпочтительная маршрутизация с использованием ExpressRoute игнорирует длину пути AS при принятии решения о маршрутизации.

Эффективные маршруты в узле 2 будут аналогичными.

Параметры маршрутизации можно изменить на VPN или AS-Path, как описано в параметрах маршрутизации виртуального концентратора. Например, можно установить предпочтение на VPN.

При предпочтении маршрутизации концентратора VPN действующие маршруты в концентраторе 1 выглядят следующим образом:

Предыдущее изображение показывает, что теперь следующим узлом маршрута к 10.4.2.0/24 является VPN_S2S_Gateway, тогда как с использованием маршрутизации по умолчанию в ExpressRoute это был ExpressRouteGateway. Однако в концентраторе 2 следующим узлом на пути к 10.5.2.0/24 по-прежнему будет ExpressRoute, так как в этом случае альтернативный маршрут происходит не из VPN-шлюза, а из NVA, интегрированного в концентратор.

Однако трафик между узлами по-прежнему осуществляется предпочтительно через маршруты ExpressRoute. Чтобы использовать более эффективное прямое подключение между виртуальными узлами, на обоих узлах можно задать значение маршрута "AS Path".

Теперь маршруты для удаленных спутников и филиалов в концентраторе 1 будут иметь следующий узел Remote Hub, как и предполагалось.

Вы можете увидеть, что префикс IP-адреса для концентратора 2 (192.168.2.0/23) по-прежнему доступен по ссылке Global Reach, но это не должно влиять на трафик, так как не должно быть никакого трафика, адресованного устройствам в концентраторе 2. Эта маршрутная конфигурация может оказаться проблематичной, если в обоих центрах присутствуют NVA, которые устанавливают SDWAN-туннели друг с другом.

Однако обратите внимание, что теперь 10.4.2.0/24 предпочтительнее, чем VPN-шлюз. Это может произойти, если у маршрутов, объявленных через VPN, путь AS короче, чем у маршрутов, объявленных через ExpressRoute. После настройки локального VPN-устройства, которое будет добавлять свой номер автономной системы (65501) к маршрутам VPN, чтобы сделать их менее предпочтительными, концентратор 1 теперь выбирает ExpressRoute в качестве следующего прыжка для 10.4.2.0/24.

В концентраторе 2 будет представлена аналогичная таблица для эффективных маршрутов, где виртуальные сети и ветви в другом концентраторе теперь отображаются с Remote Hub в качестве следующего узла.

Сценарий 3. Перекрестное подключение каналов ExpressRoute к обоим концентраторам

Чтобы добавить прямые связи между регионами Azure и локальными расположениями, подключенными через ExpressRoute, часто желательно подключить один канал ExpressRoute к нескольким концентраторам виртуальной сети WAN в топологии, иногда называемой "бабочка", как это показано в следующей топологии.

Внимание

На предыдущей схеме показаны два защищенных виртуальных концентратора, эта топология поддерживается с намерением маршрутизации. Дополнительные сведения см. в разделе "Настройка намерений маршрутизации и политик маршрутизации центра Виртуальная WAN".

Виртуальная глобальная сеть показывает, что оба канала подключены к обоим концентраторам:

При возвращении к заданной по умолчанию предпочтительной маршрутизации концентратора через ExpressRoute маршруты к удаленным ветвям и виртуальным сетям в концентраторе 1 снова будут отображать ExpressRoute в качестве следующего прыжка. Хотя на этот раз причиной не является Global Reach, а то, что каналы ExpressRoute возвращают объявления маршрутов, которые они получают от одного концентратора к другому. Например, действующие маршруты концентратора 1 с предпочтениями маршрутизации концентратора ExpressRoute приведены следующим образом:

Повторное изменение предпочтения маршрутизации концентратора на AS Path возвращает маршруты между концентраторами в оптимальный путь с помощью прямого подключения между концентраторами 1 и 2:

Следующие шаги

Дополнительные сведения о Виртуальной глобальной сети см. в следующей статье:

• Вопросы и ответы по Виртуальной глобальной сети