Оптимизация маршрутизации ExpressRoute
При наличии нескольких каналов ExpressRoute к сети Майкрософт можно подключиться по нескольким маршрутам. Поэтому маршрутизация может быть неоптимальной, а это значит, что при передаче трафика из вашей сети в сеть Майкрософт и наоборот он будет проходить более длинный маршрут. А это, в свою очередь, может стать причиной возникновения длительной задержки, Задержка напрямую влияет на производительность приложений и взаимодействие с пользователем. В этой статье показано, как оптимизировать маршрутизацию с помощью стандартных технологий маршрутизации.
Выбор пути для пиринга Майкрософт
Важно убедиться, что при использовании Корпорации Майкрософт трафик передается по нужному пути, если у вас есть один или несколько каналов ExpressRoute. Кроме того, необходимо убедиться, что пути к Интернету используют Интернет Exchange (IX) или поставщик услуг Интернета (ISP). BGP использует лучший алгоритм выбора пути на основе многих факторов, включая самый длинный совпадение префикса (LPM). Чтобы убедиться, что трафик, предназначенный для Azure через Корпорацию Майкрософт, проходит по пути ExpressRoute, необходимо реализовать атрибут локального предпочтения . Этот параметр гарантирует, что путь всегда предпочтителен в ExpressRoute.
Примечание.
Локальный параметр по умолчанию обычно равен 100. Более предпочтительны более высокие местные предпочтения.
Рассмотрим следующий сценарий в качестве примера:
В приведенном выше примере, чтобы предпочесть пути ExpressRoute, настройте локальные предпочтения следующим образом.
Конфигурация Cisco IOS-XE с точки зрения R1:
R1(config)#route-map prefer-ExR permit 10
R1(config-route-map)#set local-preference 150
R1(config)#router BGP 345
R1(config-router)#neighbor 1.1.1.2 remote-as 12076
R1(config-router)#neighbor 1.1.1.2 activate
R1(config-router)#neighbor 1.1.1.2 route-map prefer-ExR in
Конфигурация Junos с точки зрения R1:
- user@R1# set protocols bgp group ibgp type internal
- user@R1# set protocols bgp group ibgp local-preference 150
Неоптимальная маршрутизация от клиента к Майкрософт
Рассмотрим проблему маршрутизации более детально на следующем примере. Предположим, что есть два офиса, расположенных в США: один — в Лос-Анджелесе, а другой — в Нью-Йорке. Эти офисы подключены к глобальной сети (WAN): либо к вашей собственной магистральной, либо к предоставленной поставщиком услуг VPN на базе IP-сети. У вас есть два канала ExpressRoute: один — в западной части США, а другой — в восточной. Оба подключения также подключены к глобальной сети. Очевидно, что подключение к сети Майкрософт можно установить по двум каналам.
Теперь представьте, что у вас есть развертывание Azure, например служба приложение Azure как на западе США, так и на востоке США. Ваше намерение — подключить пользователей в Лос-Анджелесе к Западной части США Azure и пользователям в Нью-йорке к Восточной части США. Причина этой настройки заключается в том, что администратор службы объявляет, что пользователи в каждом офисе получают доступ к близлежащим службам Azure для оптимального взаимодействия. План хорошо работает для пользователей восточного побережья, но не для пользователей западного побережья.
Причина проблемы заключается в каждом канале ExpressRoute, мы объявляем локальный префикс в Azure East 23.100.0.0/16 и префикс в Azure West 13.100.0.0/16. Если вы не знаете, какой префикс является из какого региона, вы не сможете обработать его по-другому. Глобальная сеть может распознать префиксы в качестве относящихся ближе к региону "Восточная часть США", чем к "Западная часть США" и направить трафик пользователей обоих офисов по каналу ExpressRoute в восточной части США. В конце концов, у вас много несчастных пользователей в офисе Лос-Анджелеса.
Решение. Использование сообщества BGP
Чтобы оптимизировать маршрутизацию для обоих офисов, необходимо определить, какой префикс относится к региону Azure "Западная часть США", а какой — к региону "Восточная часть США". Эти сведения кодируются с использованием значений сообществ BGP. Мы назначили уникальное значение сообщества BGP для каждого региона Azure, например 12076:51004 для восточной части США, 12076:51006 для западной части США. Теперь, определив префикс для каждого региона Azure, можно настроить канал ExpressRoute, который необходимо использовать. Так как мы используем BGP для обмена сведениями о маршрутизации, вы можете использовать локальные предпочтения BGP для влияния на маршрутизацию.
В нашем примере для префикса 13.100.0.0/16 западной части США можно установить более высокое значение локального предпочтения, чем для префикса восточной части США, и точно так же можно установить более высокое значение локального предпочтения для префикса 23.100.0.0/16 восточной части США по сравнению с префиксом западной. Эта конфигурация гарантирует, что при наличии обоих путей к Корпорации Майкрософт пользователи в Лос-Анджелесе принимают канал ExpressRoute на западе США, чтобы подключиться к Западной части США, а пользователи в Нью-Йорке принимают ExpressRoute на востоке США к Восточной части США. Это обеспечивает оптимальную маршрутизацию на обоих сторонах.
Примечание.
Локальное предпочтение также можно назначить для маршрутизации от клиента к виртуальной сети Azure, когда используется частный пиринг. Корпорация Майкрософт не добавляет значения сообщества BGP к префиксам, объявленным в Azure для вашей сети. Тем не менее, так как известно, какое развертывание виртуальной сети ближе к каждому офису, можно настроить маршрутизаторы таким образом, чтобы они предпочитали один канал ExpressRoute другому.
Неоптимальная маршрутизация от Майкрософт к клиенту
В этом примере у нас есть подключения от Корпорации Майкрософт, чтобы получить более длинный путь к сети. В этом случае используются Exchange Online и локальные серверы Exchange в гибридной среде. Офисы подключены к глобальной сети. Вы объявляете префиксы локальных серверов в обоих офисах корпорации Майкрософт через два канала ExpressRoute.
Exchange Online инициирует подключения к локальным серверам в таких случаях, как миграция почтовых ящиков. Подключение к офису Лос-Анджелеса направляется в канал ExpressRoute на востоке США, прежде чем пройти весь континент обратно на западное побережье. В этом случае причина та же, что и в первом примере. Без какого-либо указания сеть Майкрософт не может сказать, какой локальный префикс близок к востоку от США, и какой из них близок к западной части США. Возможно, что подключение к офису в Лос-Анджелесе будет установлено по неправильному каналу.
Решение. Использование атрибута AS PATH
Эту проблему можно решить двумя способами. Во-первых, вы просто рекламируете локальный префикс для вашего офиса в Лос-Анджелесе 177.2.0.0/31 на канале ExpressRoute на западе США. Затем вы рекламируете локальный префикс для своего офиса в Нью-Йорке 177.2.0.2/31 на канале ExpressRoute на востоке США. В результате существует только один путь, по которому корпорация Майкрософт может подключаться к каждому из офисов. Неоднозначность и маршрутизация оптимизирована. В этом случае следует обдумать стратегию отработки отказа. Если путь к Microsoft через ExpressRoute завершается, необходимо убедиться, что Exchange Online по-прежнему может подключаться к локальным серверам.
Второе решение — вам также необходимо объявить префикс для обоих каналов ExpressRoute и, кроме того, предоставить сведения о том, какой префикс используется для каждого офиса. Так как Майкрософт поддерживает использование атрибута AS Path BGP, с его помощью можно управлять маршрутизацией. В этом примере можно продлить AS PATH для 172.2.0.0/31 на востоке США, чтобы мы предпочитали канал ExpressRoute на западе США для трафика, предназначенного для этого префикса. Аналогичным образом можно продлить AS PATH для 172.2.0.2/31 на западе США, чтобы мы предпочитали канал ExpressRoute на востоке США. Это позволит оптимизировать маршрутизацию для обоих офисов. Если один из каналов ExpressRoute недоступен, подключение Exchange Online к вашей сети будет установлено через другой канал ExpressRoute и вашу глобальную сеть.
Внимание
Мы удаляем частные номера AS в Пути AS для префиксов, полученных при пиринге Майкрософт при пиринге с использованием частного номера AS. Вам необходимо подключиться к общедоступной AS и добавить общедоступные номера AS в Пути AS, чтобы повлиять на маршрутизацию для пиринга Майкрософт.
Примечание.
Хотя примеры, приведенные здесь, предназначены для пиринга Майкрософт, мы поддерживаем те же возможности для частного пиринга. Кроме того, атрибут AS PATH можно использовать в отдельном канале ExpressRoute. Он влияет на выбор основного и дополнительного путей.
Неоптимальная маршрутизация виртуальных сетей
С помощью ExpressRoute вы можете обеспечить обмен данными между виртуальными сетями, связав их с каналом ExpressRoute. Если связать их с несколькими каналами ExpressRoute, это может вызвать неоптимальную маршрутизацию между виртуальными сетями. Рассмотрим пример. У вас есть два канала ExpressRoute: один — в западной части США, а другой — в восточной. В каждом регионе имеется две виртуальные сети. Веб-серверы развернуты в одной виртуальной сети, а серверы приложений — в другой. Чтобы обеспечить избыточность, вы связываете две виртуальные сети в каждом регионе с локальным каналом ExpressRoute и удаленным каналом ExpressRoute. Как видно на следующей схеме, из каждой виртуальной сети есть два пути к другой виртуальной сети. Виртуальным сетям неизвестно, какой канал ExpressRoute является локальным, а какой удаленным. Так как маршрутизация с равной стоимостью и несколькими путями (ECMP) используется для балансировки трафика между виртуальными сетями, некоторые потоки трафика занимают более длинный путь и направляются в удаленном канале ExpressRoute.
Решение. Назначение высокого веса для локального подключения
Решение простое. Зная, где расположены виртуальные сети и каналы, вы можете определить, какой путь подходит для каждой виртуальной сети. В нашем примере для локального подключения нужно назначить более высокий вес, чем для удаленного (пример конфигурации см. здесь). Когда виртуальная сеть получает префикс другой виртуальной сети в нескольких подключениях, она предпочитает подключение с наибольшим весом для отправки трафика, предназначенного для этого префикса.
Примечание.
Вы также можете повлиять на маршрутизацию из виртуальной сети в локальную сеть, если у вас несколько каналов ExpressRoute, настроив вес подключения вместо применения предустановки AS PATH, метод, описанный во втором сценарии. При выборе способа отправки трафика для каждого префикса сначала просматривается вес подключения, а потом длина AS Path.