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

Устранение неполадок Azure Route Server

  • Статья

Узнайте, как устранить некоторые распространенные проблемы с сервером маршрутизации Azure.

Проблемы с подключением

Почему виртуальное сетевое устройство (NVA) теряет подключение к Интернету после объявления маршрута по умолчанию (0.0.0.0/0) на сервер маршрутизации?

Когда NVA объявляет маршрут по умолчанию, сервер маршрутизации программирует его для всех виртуальных машин в виртуальной сети, включая сам NVA. Этот маршрут по умолчанию задает NVA в качестве следующего прыжка для всего трафика, привязанного к Интернету. Если для NVA требуется подключение к Интернету, необходимо настроить определяемый пользователем маршрут (UDR), чтобы переопределить этот маршрут по умолчанию из NVA и подключить UDR к подсети, где размещается NVA. В противном случае главный компьютер NVA продолжает отправлять трафик, связанный с Интернетом, включая тот, который отправляет NVA обратно в сам NVA. Дополнительные сведения см. в разделе "Определяемые пользователем маршруты".

Маршрут Следующий прыжок
0.0.0.0/0 Интернет

Почему NVA теряет подключение к серверу маршрутизации после принудительного подключения всего трафика к брандмауэру с помощью определяемого пользователем маршрута (UDR) в шлюзеSubnet?

Если вы хотите проверить локальный трафик с помощью брандмауэра, вы можете принудительно принудительно принудить весь локальный трафик к брандмауэру с помощью определяемого пользователем маршрута (UDR) на шлюзеSubnet (таблица маршрутов, связанная с ШлюзомSubnet с UDR). Однако этот UDR может нарушить связь между сервером маршрутизации и шлюзом, принудив трафик уровня управления (BGP) к брандмауэру (эта проблема возникает, если вы проверяете трафик, предназначенный для виртуальной сети с сервером маршрутизации). Чтобы избежать этой проблемы, необходимо добавить еще один UDR в таблицу маршрутов GatewaySubnet, чтобы исключить трафик плоскости управления от принудительного подключения к брандмауэру (в случае добавления правила BGP в брандмауэр не требуется или возможно):

Маршрут Следующий прыжок
10.0.0.0/16 10.0.2.1
10.0.1.0/27 Виртуальная сеть

10.0.0.0/16 — это адресное пространство виртуальной сети, а 10.0.1.0/27 — адресное пространство RouteServerSubnet. 10.0.2.1 — это IP-адрес брандмауэра.

Я добавил определяемый пользователем маршрут (UDR) с типом следующего прыжка как шлюз виртуальная сеть, но этот UDR не действует. Так и должно быть?

Да, это ожидаемое поведение. Определяемые пользователем маршруты с типом следующего прыжка виртуальная сеть шлюз не поддерживаются для подсетей в виртуальной сети сервера маршрутизации и одноранговых виртуальных сетях. Однако если вы хотите настроить следующий прыжок как сетевой виртуальный модуль (NVA) или Интернет, то поддерживается добавление определяемого пользователем маршрута с типом следующего прыжка VirtualAppliance или Internet .

В эффективных маршрутах сетевого интерфейса моей виртуальной машины, почему у меня есть определяемый пользователем маршрут (UDR) с типом следующего прыжка, равным None?

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

Почему после связывания политики конечной точки службы с RouteServerSubnet или GatewaySubnet я потеряю подключение?

Если вы связываете политику конечной точки службы с RouteServerSubnet или GatewaySubnet, то связь между базовой платформой управления Azure и этими соответствующими службами Azure (шлюз Route Server и VPN/ExpressRoute). Это может привести к тому, что эти ресурсы Azure вступают в неработоспособное состояние, что приводит к потере подключения между локальными и рабочими нагрузками Azure.

Почему после использования настраиваемой DNS вместо используемой по умолчанию виртуальной сети сервера маршрутизации теряются подключения (dns, предоставляемые Azure) для виртуальной сети сервера маршрутизации?

Для виртуальной сети, в которую развернут сервер маршрутизации, если вы не используете DNS по умолчанию (предоставлено Azure), убедитесь, что настраиваемая конфигурация DNS может разрешать имена общедоступных доменов. Это гарантирует, что службы Azure (шлюз Route Server и VPN/ExpressRoute) могут взаимодействовать с базовой плоскостей управления Azure. См. примечание о правилах подстановочных знаков в документации по частному сопоставителям Azure DNS.

Почему не удается выполнить tcp-связь из NVA к IP-адресу однорангового узла BGP сервера маршрутизации после настройки пиринга BGP между ними?

В некоторых NVA необходимо добавить статический маршрут в подсеть сервера маршрутизации, чтобы иметь возможность tcp-подключения к серверу маршрутизации из NVA и избегать свернутого пиринга BGP. Например, если сервер маршрутизации находится в версии 10.0.255.0/27, а NVA находится в версии 10.0.1.0/24, необходимо добавить следующий маршрут в таблицу маршрутизации в NVA:

Маршрут Следующий прыжок
10.0.255.0/27 10.0.1.1

10.0.1.1 — это стандартный IP-адрес шлюза в подсети, в которой размещен NVA (или, точнее, одна из сетевых карт).

Почему я потеряю подключение к локальной сети через ExpressRoute и (или) VPN Azure при развертывании сервера маршрутизации в виртуальной сети, которая уже имеет шлюз ExpressRoute и (или) VPN-шлюз Azure?

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

Проблемы с уровнем управления

Почему локальная сеть, подключенная к VPN-шлюзу Azure, не получает маршрут по умолчанию, объявленный сервером маршрутизации?

Хотя VPN-шлюз Azure может получить маршрут по умолчанию от своих одноранговых узлов BGP, включая сервер маршрутизации, он не объявляет маршрут по умолчанию другим одноранговым узлам.

Почему NVA не получает маршруты от сервера маршрутов, даже если пиринг BGP работает?

ASN, который использует сервер маршрутизации, имеет значение 65515. Убедитесь, что для NVA настроен другой ASN, чтобы сеанс eBGP можно было установить между NVA и сервером маршрутов, чтобы распространение маршрутов может произойти автоматически. Убедитесь, что в конфигурации BGP включена поддержка нескольких прыжков, так как NVA и сервер маршрутизации находятся в разных подсетях в виртуальной сети.

Почему подключение не работает при объявлении маршрутов с ASN 0 в AS-Path?

Сервер маршрутов Azure удаляет маршруты с ASN 0 в AS-Path. Чтобы эти маршруты успешно объявлялись в Azure, as-Path не должен содержать 0.

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

  • Если виртуальная машина находится в той же виртуальной сети, что и NVA и сервер маршрутизации:

    Сервер маршрутизации предоставляет два одноранговых IP-адреса BGP, которые разделяют ответственность за отправку маршрутов всем остальным виртуальным машинам, работающим в виртуальной сети. Каждый NVA должен настроить два одинаковых сеанса BGP (например, использовать тот же номер AS, тот же путь AS и объявлять один и тот же набор маршрутов) для двух одноранговых IP-адресов BGP, чтобы виртуальные машины в виртуальной сети могли получать согласованную информацию о маршрутизации с сервера маршрутизации Azure.

    Схема, на которой показан виртуальный сетевой модуль (NVA) с сервером маршрутизации Azure.

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

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

Почему функция "Равные затраты с несколькими путями" (ECMP) моего ExpressRoute отключена после развертывания сервера маршрутизации в виртуальной сети?

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

Операционные проблемы

Почему возникает ошибка о недопустимой области и авторизации для выполнения операций сервера маршрутизации?

Если вы видите ошибку в приведенном ниже формате, убедитесь, что у вас есть следующие разрешения: роли сервера маршрутов и разрешения

Формат сообщения об ошибке: "Клиент с идентификатором {} объекта не имеет авторизации для выполнения действий {} над областью {} или область недопустим. If access was recently granted, please refresh your credentials."

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

Сведения о создании и настройке сервера маршрутизации Azure см. в статье:

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