Поделиться через

Интеграция SDWAN с топологиями сети с концентраторами и периферийными сетями Azure

Azure ExpressRoute
VPN-шлюз Azure
Виртуальная сеть Azure

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

Применимые сценарии

Рекомендации, приведенные в этой статье, не зависят от поставщика и применимы к любой технологии, отличной от Microsoft SD-WAN, которая соответствует двум основным предварительным требованиям:

  • Зависимость от протоколов туннелирования, использующих протокол TCP или протокол пользовательской диаграммы данных (UDP) в качестве базового транспорта, например протокол IPsec IPsec ESP с NAT-Traversal.
  • Поддержка протокола BGP версии 4 для обмена маршрутами с внешними сущностями. Никаких предположений о протоколе маршрутизации, используемом устройствами, не относящихся к Microsoft SD-WAN, для обмена данными о маршрутизации между собой.

Клиенты, которые соответствуют этим рекомендациям, могут использовать свою технологию SD-WAN для достижения следующих целей:

  • Интеграция продуктов SD-WAN в существующей сети Центра Azure и периферийной сети путем автоматизации обмена маршрутами между устройствами Azure виртуальная сеть и SD-WAN.
  • Оптимизируйте подключение (как к Azure, так и к локальным центрам обработки данных) для ветвей с помощью локальных подключений к Интернету. Охват магистральной системы Майкрософт, в сочетании с ее емкостью, устойчивостью и "холодной картошки" политики маршрутизации предполагает, что она может использоваться в качестве высокопроизводительной подложки для глобальных SD-WAN.
  • Используйте магистраль Майкрософт для всего трафика Azure в Azure (между регионами и географическими областями).
  • Используйте существующие сети многоуровневого переключения меток (MPLS) в качестве высокопроизводительных наложения. Его также можно использовать для замены существующей сети MPLS в поэтапном подходе, который сводит к минимуму влияние на бизнес.

В следующих разделах предполагается, что читатель знаком с основамиSD-WAN парадигмы и архитектурой магистрали Майкрософт. Магистральная сеть Майкрософт соединяет регионы Azure друг с другом и с общедоступным Интернетом.

Архитектура

Организации с глобальным присутствием и несколькими регионами Azure, как правило, используют сочетание служб подключения для реализации своих корпоративных сетей и подключения к магистрали Майкрософт:

  • Выделенные службы подключения, такие как MPLS Internet-Protocol-Virtual-Private-Networks (IPVPNs), могут использоваться на крупнейших сайтах, таких как центры обработки данных или штаб-квартиры.
  • Крупные сайты могут включать выделенное подключение к магистрали Майкрософт через каналы ExpressRoute, используя одну из поддерживаемых моделей подключения. В частности, сайт может использовать выделенные каналы типа "точка — точка" для подключения к ближайшему расположению пиринга ExpressRoute. Кроме того, он может применить IPVPN MPLS для доступа к каналам ExpressRoute, предоставляемым оператором MPLS.
  • Филиалы, имеющие только подключение к Интернету, могут использовать виртуальные сети IPsec для подключения к ближайшему локальному центру обработки данных и использовать подключение ExpressRoute центра обработки данных для доступа к ресурсам Azure. Кроме того, они могут использовать виртуальные сети IPsec для прямого подключения к концентратору Azure и периферийным сетям.

Проекты SD-WAN могут иметь разные области с точки зрения того, какие традиционные сетевые службы они намерены заменить. Некоторые организации могут придерживаться выделенных ссылок или MPLS для крупных объектов и развертывать SD-WAN только для замены устаревших виртуальных сетей IPsec в Интернете на небольших сайтах. Другие организации могут потребовать расширения SD-WAN на подключенные к MPLS сайты и использовать существующую сеть MPLS в качестве высокопроизводительной подложки. Наконец, некоторые организации могут захотеть закрыть IPVPN MPLS. или любая выделенная служба подключения, чтобы принять парадигму SD-WAN. Таким образом, они могут построить всю корпоративную сеть в качестве логического наложения на основе общедоступных или общих наложений (общедоступный Интернет и магистраль Майкрософт).

Архитектура, описанная в этой статье, поддерживает все перечисленные ранее области и основана на следующих принципах:

  • Устройства SD-WAN развертываются как сетевые виртуальные устройства (NVA) в каждом концентраторе Azure и периферийной сети и настраиваются в качестве концентраторов SD-WAN, которые завершают туннели из локальных сайтов.
  • Устройства SD-WAN в Azure настроены для создания туннелей друг с другом, что позволяет создавать полностью сетчатые наложения концентратора и концентратора, которые могут эффективно транспортировать трафик между регионами Azure, а также ретранслятор трафика между географически удаленными локальными сайтами, на вершине магистрали Майкрософт.
  • Устройства SD-WAN развертываются на всех локальных сайтах, охватываемых решением SD-WAN, и настроены для установки туннелей к сетевым сетям SD-WAN в ближайших регионах Azure. Различные сайты могут использовать различные транспортные службы в качестве подложки для туннелей, таких как общедоступный Интернет, подключение ExpressRoute и т. д.
  • Трафик от сайта к любому месту назначения, будь то в Azure или на другом локальном сайте, направляется в сетевые сети SD-WAN в ближайшем регионе Azure. Затем он направляется через наложение "концентратор — концентратор".

Продукты SD-WAN могут использовать собственные протоколы и функции для обнаружения, после динамической установки прямых туннелей между двумя сайтами могут обеспечить лучшую производительность, чем ретрансляция трафика через NVAs SD-WAN в Azure.

Высокоуровневая архитектура глобальной сети SD-WAN, использующая магистраль Майкрософт, общедоступный Интернет и выделенные подключения ER в виде подложек, показана на следующем рисунке.

Схема, показывющая архитектуру высокого уровня SD-WAN. Рис. 1. Высокоуровневая архитектура глобального SD-WAN, использующая магистраль Майкрософт, общедоступный Интернет и выделенные подключения ER в качестве подложек. Черная пунктирная линия показывает, как трафик между двумя локальными сайтами можно направлять через SD-WAN NVAs, развернутые в регионах Azure географически близко к сайтам. Магистраль Майкрософт, из-за ее охвата, емкости и "холодного картофеля" политики маршрутизации может привести к значительно лучшей или прогнозируемой производительности, чем общедоступный Интернет, особенно для длительных подключений.

Продукты SD-WAN в центральных и периферийных сетях Azure

В этом разделе приведены рекомендации по развертыванию устройств CPE, отличных от Microsoft SD-WAN, в качестве NVAs в существующем концентраторе и периферийной сети Azure.

Сетевые сети SD-WAN в виртуальной сети концентратора

Концентратор и периферийный сервер — это топология, которую корпорация Майкрософт рекомендует для создания масштабируемых сетей в регионе Azure с помощью управляемых клиентом виртуальных сетей. В центральной виртуальной сети размещаются общие компоненты, такие как NVAs, отличные от Майкрософт, и собственные службы, предоставляющие сетевые функции, такие как брандмауэр, балансировка нагрузки и подключение к локальным сайтам через виртуальные сети сайта 2-сайта или ExpressRoute. Виртуальная сеть концентратора — это естественное расположение для виртуальных сетей SD-WAN, которые в конечном итоге являются шлюзами, не являющихся корпорацией Майкрософт, предоставляющими доступ к удаленным сетям.

Виртуальные сети SD-WAN должны быть развернуты в центральных виртуальных сетях следующим образом:

  • Для всего трафика SD-WAN используется один сетевой контроллер (сетевой адаптер). Другие сетевые адаптеры, такие как сетевой адаптер управления, можно добавить в соответствии с требованиями к безопасности и соответствию требованиям или придерживаться рекомендаций поставщика для развертываний Azure.
  • Сетевой адаптер, используемый для трафика SD-WAN, должен быть подключен к выделенной подсети. Размер подсети необходимо определить на основе количества виртуальных сетей SD-WAN, развернутых для удовлетворения требований к высокой доступности и масштабированию или пропускной способности, рассмотренных далее в этой статье.
  • Группы безопасности сети (NSG) должны быть связаны с сетевой картой трафика SD-WAN напрямую или на уровне подсети. Эта связь позволяет подключаться с удаленных локальных сайтов через порты TCP/UDP, используемые решением SD-WAN.
  • Ip-пересылка должна быть включена в сетевом адаптере, используемом для трафика SD-WAN.

Сервер маршрутизации Azure в виртуальной сети концентратора

Azure Route Server автоматизирует обмен маршрутами между виртуальными сетями SD-WAN и стеком программно-определяемых сетей (SDN). Сервер маршрутизации поддерживает BGP в качестве протокола динамической маршрутизации. Путем установления подключений BGP между сервером маршрутизации и NVA SD-WAN:

  • Маршруты для всех локальных сайтов, подключенных к SD-WAN, внедряются в таблицы маршрутов виртуальной сети и изучаются всеми виртуальными машинами Azure.
  • Маршруты для всех префиксов IP-адресов, включенных в адресное пространство виртуальных сетей, распространяются на все сайты, подключенные к SD-WAN.

Сервер маршрутов должен быть настроен следующим образом.

  • Его необходимо развернуть в выделенной подсети в виртуальной сети концентратора, как для создания и настройки сервера маршрутизации с помощью портала Azure.
  • Чтобы включить автоматическое обмен маршрутами для всех периферийных виртуальных сетей, пиринг между виртуальными сетями должен быть настроен, чтобы позволить периферийным виртуальным сетям использовать шлюз и сервер маршрутизации концентратора. Подробные сведения, доступные на сервере маршрутизации Azure, часто задаваемые вопросы.
  • Так как сервер маршрутизации и NVA SD-WAN подключены к разным подсетям, сеансы BGP между сервером маршрутизации и NVA SD-WAN должны быть настроены с поддержкой несколькихhop eBGP. Можно задать любое количество прыжков от 2 до максимального, поддерживаемого NVA SD-WAN. Сведения о настройке adjacencies BGP для сервера маршрутизации доступны в статье "Создание и настройка сервера маршрутизации" с помощью портала Azure.
  • Для конечных точек BGP, предоставляемых сервером маршрутизации, необходимо настроить два /32 статических маршрута на NVA SD-WAN. Эта конфигурация гарантирует, что таблица маршрутов NVA всегда содержит маршруты для нескольких одноранговых узлов BGP (не подключенных напрямую).

Сервер маршрутизации не в пути к данным. Это сущность плоскости управления. Он распространяет маршруты между sd-WAN NVA и стеком SDN виртуальной сети, но фактический трафик между NVA SD-WAN и виртуальными машинами в виртуальной сети выполняется стеком AZURE SDN, как показано на следующем рисунке. Чтобы получить такое поведение маршрутизации, сервер маршрутизации внедряет все маршруты, которые он узнает из NVAs SD-WAN с следующим прыжком, заданным для собственного адреса NVA.

Сервер маршрутизации не поддерживает IPv6 по состоянию на данный момент. Эта архитектура используется только для IPv4.

Схема, показывающая, как работает сервер маршрутизации. Рис. 2. Сервер маршрутов поддерживает распространение маршрутов между SD-WAN CPE и стеком SDN виртуальной сети, но не перенаправит трафик между SD-WAN CPE и виртуальными машинами в виртуальной сети.

Высокий уровень доступности для NVAs SD-WAN с помощью сервера маршрутизации

Сервер маршрутов имеет встроенную высокий уровень доступности. Два вычислительных узла возвращают один экземпляр сервера маршрутизации. Они развертываются в разных зонах доступности для регионов с поддержкой зоны доступности или в одной группе доступности. Они предоставляют две конечные точки BGP. Высокий уровень доступности для NVAs SD-WAN достигается путем развертывания нескольких экземпляров в разных зонах доступности, для регионов, поддерживающих их, или в одном наборе доступности. Каждая NVA SD-WAN устанавливает два сеанса BGP с обеими конечными точками, предоставляемыми сервером маршрутов.

Архитектура, описанная в этой статье, не зависит от Azure Load Balancers. В частности:

  • Общедоступные подсистемы балансировки нагрузки не предоставляют конечные точки туннеля SD-WAN. Каждая NVA SD-WAN предоставляет собственную конечную точку туннеля. Удаленные одноранговые узлы устанавливают несколько туннелей, по одному для каждого NVA SD-WAN в Azure.

  • Внутренние подсистемы балансировки нагрузки не распределяют трафик, вызванный виртуальными машинами Azure, на виртуальные машины SD-WAN. Сервер маршрутизации и стек SDN Azure поддерживают маршрутизацию с поддержкой маршрутизации с равными затратами (ECMP). Если несколько NVAs настраивают подключения BGP с помощью сервера маршрутизации и объявляют маршруты для одних и того же назначения (как и в удаленных сетях и сайтах, подключенных к SD-WAN), используя ту же степень предпочтения, route Server:

    • Внедряет несколько маршрутов для этих назначений в таблицу маршрутов виртуальной сети.
    • Задает каждый маршрут для использования другого NVA в качестве следующего прыжка.

Затем стек SDN распределяет трафик в эти места назначения во всех доступных прыжках следующего прыжка.

Результирующая архитектура высокого уровня доступности показана на следующем рисунке:

Схема, показывющая высокий уровень доступности сервера маршрутов. Рис. 3. Сервер маршрутизации поддерживает маршрутизацию Equal-Cost Multipath (ECMP). Azure Load Balancers не требуется, если для обеспечения доступности и (или) масштабируемости используются несколько виртуальных виртуальных машин SD-WAN.

N-активный и активный автономный режим высокой доступности

При использовании нескольких виртуальных сетей SD-WAN и одноранговых подключений с сервером маршрутизации BGP выполняет отработку отказа. Если NVA SD-WAN переходит в автономный режим, он останавливает рекламные маршруты на сервер маршрутизации. Затем маршруты, полученные от неудачного устройства, удаляются из таблицы маршрутов виртуальной сети. Таким образом, если NVA SD-WAN больше не обеспечивает подключение к удаленным сайтам SD-WAN из-за сбоя, в самом устройстве или в подложке, он больше не отображается как возможный следующий прыжок к удаленным сайтам в таблице маршрутов виртуальной сети. Весь трафик переходит к оставшимся работоспособным устройствам. Дополнительные сведения о распространении маршрутов между SD-WAN NVAs и сервером маршрутов см. в разделе "Маршруты", объявленные одноранговым узлом BGP на сервер маршрутизации.

Схема, на которую показана отработка отказа на основе BGP сервера маршрутизации. Рис. 4. Отработка отказа на основе BGP. Если SD-WAN NVA #0 переходит в автономный режим, его сеансы BGP с сервером маршрутизации закрываются. SD-WAN NVA #0 удаляется из таблицы маршрутов виртуальной сети в качестве возможного следующего прыжка для трафика, исходя из Azure на локальный сайт.

Отработка отказа на основе BGP и маршрутизация ECMP, естественно, позволяют использовать архитектуры высокого уровня доступности n с устройствами одновременной обработки трафика. Но вы также можете использовать BGP для реализации активных и пассивных архитектур высокой доступности: настройте пассивное устройство, чтобы сообщить серверу Маршрутизации маршруты с более низкой степенью предпочтения, чем его активный одноранговый узел. Сервер маршрутов удаляет маршруты, полученные от пассивного устройства, если он получает от активного устройства любые маршруты для одних и того же назначения с более высокой степенью предпочтения. И она выполняет только последние маршруты в таблице маршрутов виртуальной сети.

Если активное устройство завершается сбоем или удаляет некоторые из его маршрутов, сервер маршрутов:

  • Выбирает соответствующие маршруты, объявленные пассивным устройством.
  • Перенаправляет маршруты в таблице маршрутов виртуальной сети.

Единственные атрибуты BGP, которые NVA SD-WAN могут использовать для выражения степени предпочтения маршрутов, которые они объявляют серверу маршрутизации, — AS Path.

Рекомендуется использовать архитектуры высокого уровня доступности N-active, так как они обеспечивают оптимальное использование ресурсов (нет автономных NVA SD-WAN) и горизонтальной масштабируемости. Чтобы увеличить пропускную способность, несколько виртуальных сетей могут выполняться параллельно до максимального количества одноранговых узлов BGP, поддерживаемых сервером маршрутов. Дополнительные сведения см. в разделе одноранговых узлов BGP. Но для модели высокого уровня доступности N-active требуется, чтобы NVA SD-WAN действовали в качестве маршрутизаторов уровня 3 без отслеживания состояния. При наличии нескольких туннелей на сайт tcp-подключения можно перенаправить асимметрично. То есть потоки ORIGINAL и REPLY одного и того же TCP-подключения можно направлять через разные туннели и разные NVA. На следующем рисунке показан пример асимметричного перенаправленного TCP-подключения. Такие асимметрии маршрутизации возможны для tcp-подключений, инициированных на виртуальной сети или локальном сайте.

Схема, показывающая асимметричную маршрутизацию в активных и активных конфигурациях. Рис. 5. Асимметричная маршрутизация в архитектурах активной и активной высокой доступности. SD-WAN NVA #0 и SD-WAN NVA #1 объявите тот же маршрут для назначения 192.168.1.0/24 (удаленный SD-WAN сайт) с той же длиной пути AS для сервера маршрутизации. Поток ORIGINAL (из SD-WAN удаленного сайта в Azure, красный путь) направляется через туннель, завершенный на стороне Azure, SD-WAN NVA #1. Локальный SD-WAN CPE выбирает этот туннель. Стек AZURE SDN направляет поток ОТВЕТА (из Azure на удаленный SD-WAN сайт, зеленый путь) в SD-WAN NVA #0, который является одним из возможных следующих прыжков для 192.168.1.0/24 в соответствии с таблицей маршрутов виртуальной сети. Невозможно гарантировать, что следующий прыжок, выбранный стеком SDN Azure, всегда совпадает с SD-WAN CPE, который получил поток ORIGINAL.

Активные и пассивные архитектуры высокого уровня доступности следует учитывать только в том случае, если NVA SD-WAN в Azure выполняют другие сетевые функции, требующие симметрии маршрутизации, например брандмауэр с отслеживанием состояния. Мы не рекомендуем этот подход из-за его последствий на масштабируемость. Выполнение дополнительных сетевых функций на виртуальных машинах SD-WAN увеличивает потребление ресурсов. В то же время архитектура активной и пассивной высокой доступности позволяет использовать один трафик обработки NVA в любой момент времени. То есть весь уровень SD-WAN можно масштабировать только до максимального размера виртуальной машины Azure, который он поддерживает, а не масштабировать. Запустите функции сети с отслеживанием состояния, требующие симметрии маршрутизации в отдельных кластерах NVA, которые используют Load Balancer (цен. категория для n-активной высокой доступности.

Рекомендации по подключению ExpressRoute

Архитектура, описанная в этой статье, позволяет клиентам полностью принять парадигму SD-WAN и построить свою корпоративную сеть как логическую наложение на общедоступный Интернет и магистраль Майкрософт. Он также поддерживает использование выделенных каналов Expressroute для решения конкретных сценариев, описанных далее.

Сценарий #1. Сосуществование ExpressRoute и SD-WAN

Решения SD-WAN могут сосуществовать с подключением ExpressRoute при развертывании устройств SD-WAN только в подмножестве сайтов. Например, некоторые организации могут развертывать SD-WAN решения в качестве замены традиционных виртуальных сетей IPsec на сайтах только с подключением к Интернету. Затем они используют службы MPLS и каналы ExpressRoute для крупных сайтов и центров обработки данных, как показано на следующем рисунке.

Схема сосуществования SD-WAN и ExpressRoute. Рис. 6. SD-WAN решения могут сосуществовать с подключением ExpressRoute, если SD-WAN устройства CPE развертываются только в подмножестве сайтов.

В этом сценарии сосуществования требуется, чтобы виртуальные сети SD-WAN, развернутые в Azure, были способны маршрутизации трафика между сайтами, подключенными к SD-WAN, и сайтам, подключенным к каналам ExpressRoute. Сервер маршрутов можно настроить для распространения маршрутов между шлюзами виртуальной сети ExpressRoute и SD-WAN NVAs в Azure, включив AllowBranchToBranch эту функцию, как описано здесь. Распространение маршрутов между шлюзом виртуальной сети ExpressRoute и NVA SD-WAN происходит через BGP. Сервер маршрутов устанавливает сеансы BGP с обоими и распространяется на каждый одноранговый узел маршрутов, извлеченных из другого. Платформа управляет сеансами BGP между сервером маршрутизации и шлюзом виртуальной сети ExpressRoute. Пользователям не нужно явно настраивать их, но только для включения AllowBranchToBranch флага при развертывании сервера маршрутов.

Схема, показывающая распространение маршрутов при настройке сервера маршрутов с помощью AllowBranchToBranch=TRUE. Рис. 7. Распространение маршрутов между шлюзом виртуальной сети ExpressRoute и SD-WAN NVA происходит через BGP. Сервер маршрутов устанавливает сеансы BGP с обоими и распространяет маршруты в обоих направлениях при настройке с параметром AllowBranchToBranch=TRUE. Сервер маршрутов выступает в качестве отражателя маршрута, то есть не является частью пути к данным.

Этот сценарий сосуществования SD-WAN и ExpressRoute позволяет переносить сети MPLS в SD-WAN. Он предлагает путь между устаревшими сайтами MPLS и недавно перенесенными сайтами SD-WAN, устраняя необходимость маршрутизации трафика через локальные центры обработки данных. Этот шаблон можно использовать не только во время миграции, но и в сценариях, возникающих из-за слияний и приобретений компании, обеспечивая простое взаимодействие разрозненных сетей.

Сценарий #2. Expressroute как подложка SD-WAN

Если локальные сайты имеют подключение ExpressRoute, вы можете настроить устройства SD-WAN для настройки туннелей к сетевым сетям концентратора SD-WAN, работающим в Azure поверх канала ExpressRoute или каналов. Подключение ExpressRoute можно выполнять через каналы типа "точка — точка" или сеть MPLS. Вы можете использовать частный пиринг ExpressRoute и пиринг Майкрософт.

Частный пиринг

При использовании частного пиринга ExpressRoute в качестве подложки все локальные сайты SD-WAN устанавливают туннели к сетевым сетевым сетям центра SD-WAN в Azure. В этом сценарии в этом сценарии не требуется распространение маршрутов между SD-WAN NVAs и шлюзом виртуальной сети ExpressRoute (то есть сервер маршрутизации должен быть настроен с флагом AllowBranchToBranch" значение false).

Этот подход требует надлежащей конфигурации BGP на маршрутизаторах на стороне клиента или поставщика, которые завершают подключение ExpressRoute. На самом деле маршрутизаторы Microsoft Enterprise Edge (MSE) объявляют все маршруты для виртуальных сетей, подключенных к каналу (напрямую или через пиринг виртуальных сетей). Но для перенаправления трафика, предназначенного для виртуальных сетей через туннель SD-WAN, локальный сайт должен узнать эти маршруты с устройства SD-WAN , а не канала ER.

Таким образом, маршрутизаторы на стороне клиента или поставщика, которые завершают подключение ExpressRoute, должны отфильтровать маршруты, полученные из Azure. Единственными маршрутами, настроенными в подложке, должны быть те, которые позволяют локальным устройствам SD-WAN достичь NVAs концентратора SD-WAN в Azure. Клиенты, которые хотят использовать частный пиринг ExpressRoute в качестве подложки SD-WAN, должны убедиться, что они могут соответствующим образом настроить свои устройства маршрутизации. Это особенно важно для клиентов, которые не имеют прямого контроля над своими пограничными устройствами для ExpressRoute. Например, когда канал ExpressRoute предоставляется оператором MPLS поверх службы IPVPN.

Схема, показывающая частный пиринг ExpressRoute в виде SD-WAN подложки. Рис. 8. Частный пиринг ExpressRoute в качестве SD-WAN подложки. В этом сценарии маршрутизаторы клиента и поставщика получают маршруты для виртуальной сети, которая завершает подключение ExpressRoute, в сеансах BGP частного пиринга ER и SD-WAN CPE. Только SD-WAN CPE должен распространять маршруты Azure в локальную сеть сайта.

Пиринг Майкрософт

Вы также можете использовать пиринг ExpressRoute Майкрософт в качестве подложки для туннелей SD-WAN. В этом сценарии сетевые сети концентратора SD-WAN в Azure предоставляют только общедоступные конечные точки туннеля, которые используются как ЦП SD-WAN на сайтах, подключенных к Интернету, так и ЦП SD-WAN на сайтах, подключенных к Expressroute. Хотя пиринг ExpressRoute Майкрософт имеет более сложные предварительные требования, чем частный пиринг, рекомендуется использовать этот параметр в качестве подложки из-за этих двух преимуществ:

  • Для этого не требуются шлюзы виртуальной сети Expressroute в центральной виртуальной сети. Он удаляет сложность, снижает затраты и позволяет масштабировать решение SD-WAN за пределы пропускной способности самого шлюза, если вы не используете ExpressRoute FastPath.

  • Она обеспечивает чистое разделение между наложениями и маршрутами подложки. MsEEs объявляют только общедоступные префиксы сети Майкрософт для пограничных адресов клиента или поставщика. Эти маршруты можно управлять в отдельном VRF и распространять только в сегмент DMZ локальной сети сайта. Устройства SD-WAN распространяют маршруты для корпоративной сети клиента в наложении, включая маршруты для виртуальных сетей. Клиенты, рассматривающие этот подход, должны убедиться, что они могут настроить свои устройства маршрутизации соответствующим образом или запросить соответствующую службу оператору MPLS.

Рекомендации по MPLS

Миграция из традиционных корпоративных сетей MPLS в более современные сетевые архитектуры на основе парадигмы SD-WAN требует значительных усилий и значительного количества времени. Архитектура, описанная в этой статье, позволяет поэтапно переносить SD-WAN. Далее рассматриваются два типичных сценария миграции.

Поэтапное списание MPLS

Клиенты, которые хотят создать SD-WAN на вершине общедоступного Интернета и магистрали Майкрософт, и полностью вывести IPVPN MPLS или другие выделенные службы подключения, могут использовать ExpressRoute и SD-WAN сценарий сосуществования , описанный в предыдущем разделе во время миграции. Он позволяет сайтам SD-WAN подключаться к сайтам, которые по-прежнему подключены к устаревшим MPLS. Как только сайт будет перенесен на устройства SD-WAN и CPE, его ссылка MPLS может быть выведена из эксплуатации. Сайт может получить доступ ко всей корпоративной сети через туннели SD-WAN в ближайшие регионы Azure.

Схема, показывающая архитектуру вывода mpLS из эксплуатации. Рис. 9. Сценарий "Сосуществование ExpressRoute и SD-WAN" обеспечивает поэтапное списание MPLS.

При переносе всех сайтов IPVPN MPLS можно вывести из эксплуатации, а также каналы ExpressRoute, которые подключают его к магистрали Майкрософт. Шлюзы виртуальной сети ExpressRoute больше не нужны и могут быть отменены. Сетевые сети концентратора SD-WAN в каждом регионе становятся единственной точкой входа в концентратор и периферийную сеть этого региона.

Интеграция MPLS

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

  • Подмножество таких сайтов, как центры обработки данных или крупные филиалы.
  • Подмножество подключений, как правило, учитывает задержку или критически важный трафик.

Сценарий Expressroute как SD-WAN наложение , описанное ранее, включает интеграцию SD-WAN и MPLS. Пиринг Microsoft ExpressRoute должен быть предпочтителен для частного пиринга по причинам, рассмотренным ранее. Кроме того, когда используется пиринг Майкрософт, сеть MPLS и общедоступный Интернет становятся функционально эквивалентными наложениями. Они предоставляют доступ ко всем конечным точкам туннеля SD-WAN, предоставляемым NVAs концентратора SD-WAN в Azure. Sd-WAN CPE, развернутый на сайте с подключением к Интернету и MPLS, может установить несколько туннелей в концентраторы SD-WAN в Azure на обоих подложках. Затем они могут направлять различные подключения через различные туннели, основанные на политиках уровня приложения, управляемых плоскостей управления SD-WAN.

Схема, показывющая архитектуру интеграции MPLS. Рис. 10. Сценарий ExpressRoute в качестве SD-WAN подложки позволяет интегрировать SD-WAN и MPLS.

Параметры маршрутизации сервера маршрутов

В обоих сценариях MPLS, описанных в двух предыдущих разделах, некоторые сайты филиалов можно подключить как к IPVPN MPLS, так и к SD-WAN. В результате экземпляры сервера маршрутов, развернутые в центральных виртуальных сетях, могут узнать те же маршруты из шлюзов ExpressRoute и NVAS SD-WAN. Предпочтения маршрутизации сервера маршрутов позволяют управлять тем, какой путь следует предпочтительнее и использовать в таблицах маршрутов виртуальных сетей. Предпочтения маршрутизации полезны, если не удается использовать предустановку пути AS. Примером являются службы MPLS IPVPN, которые не поддерживают пользовательские конфигурации BGP на PEs, которые завершают подключения ExpressRoute.

Ограничения сервера маршрутизации и рекомендации по проектированию

Сервер маршрутов является краеугольным камнем архитектуры, описанной в этой статье. Он распространяет маршруты между виртуальными сетями SD-WAN, развернутыми в виртуальных сетях, и базовым стеком SDN Azure. Он предоставляет подход на основе BGP к выполнению нескольких NVV SD-WAN для обеспечения высокой доступности и горизонтальной масштабируемости. При разработке больших SD-WANs на основе этой архитектуры необходимо учитывать ограничения масштабируемости сервера маршрутизации .

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

Маршруты, объявленные одноранговым сервером BGP на сервер маршрутизации

Сервер маршрутизации не определяет явное ограничение количества маршрутов, которые можно объявить в ExpressRoute виртуальная сеть Шлюзы при установке флагаAllowBranchToBranch. Однако шлюзы ExpressRoute дополнительно распространяют маршруты, к которому они учатся с сервера маршрутов, к каналам ExpressRoute, к которому они подключены.

Существует ограничение на количество маршрутов, которые шлюзы ExpressRoute могут объявлять каналам ExpressRoute через частный пиринг, документируемый в подписке Azure и ограничениях службы, квотах и ограничениях. При проектировании решений SD-WAN на основе рекомендаций, приведенных в этой статье, важно убедиться, что маршруты SD-WAN не вызывают этого ограничения. При попадании сеансы BGP между шлюзами ExpressRoute и каналами ExpressRoute удаляются, а подключение между виртуальными сетями и удаленными сетями, подключенными через ExpressRoute, теряется.

Общее количество маршрутов, объявленных для каналов шлюзами ExpressRoute, — это сумма количества маршрутов, полученных от сервера маршрутов, и количество префиксов, составляющих концентратор Azure и адресное пространство периферийной сети. Чтобы избежать сбоев из-за удаленных сеансов BGP, рекомендуется реализовать следующие способы устранения рисков.

  • Используйте собственные функции устройств SD-WAN, чтобы ограничить количество маршрутов, объявленных на сервер маршрутизации, если эта функция доступна.
  • Используйте оповещения Azure Monitor для упреждающего обнаружения пиков в количестве маршрутов, объявленных шлюзами ExpressRoute. Отслеживаемая метрика называется числом маршрутов, объявленных для однорангового узла, как описано в мониторинге ExpressRoute.

Одноранговые узлы BGP

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

Участвующие виртуальные машины

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

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.

Основные авторы:

Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.

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