Устранение неполадок 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-адрес брандмауэра.
Почему не удается выполнить 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 и сервер маршрутизации находятся в разных подсетях в виртуальной сети.
Пиринг BGP между моим NVA и сервером маршрутизации выполняется. Я вижу, что они правильно выполняют обмен маршрутами. Почему в таблице маршрутизации моей виртуальной машины нет маршрутов NVA?
Если виртуальная машина находится в той же виртуальной сети, что и NVA и сервер маршрутизации:
Сервер маршрутизации предоставляет два одноранговых IP-адреса BGP, размещенных на двух виртуальных машинах, которые совместно используют отправку маршрутов всем остальным виртуальным машинам, работающим в виртуальной сети. Каждый NVA должен настроить два одинаковых сеанса BGP (например, использовать тот же номер AS, тот же путь AS и объявить один и тот же набор маршрутов) на две виртуальные машины, чтобы виртуальные машины в виртуальной сети могли получать согласованную информацию о маршрутизации с сервера маршрутизации Azure.
При наличии двух или более экземпляров NVA можно объявить разные пути AS для одного маршрута из разных экземпляров NVA, если вы хотите назначить один экземпляр NVA как активный, а другой как пассивный.
Если виртуальная машина находится в другой виртуальной сети, отличной от виртуальной сети, в которую размещается NVA и сервер маршрутизации. Проверьте, включена ли пиринг между двумя виртуальными сетями и включен ли удаленный сервер маршрутизации в виртуальной сети виртуальной машины.
Почему функция "Равные затраты с несколькими путями" (ECMP) моего ExpressRoute отключена после развертывания сервера маршрутизации в виртуальной сети?
При объявлении одинаковых маршрутов из локальной сети в Azure через несколько подключений ExpressRoute обычно ECMP включен по умолчанию для трафика, предназначенного для этих маршрутов из Azure обратно в локальную сеть. В настоящее время при развертывании сервера маршрутизации данные с несколькими путями теряются в обмене BGP между ExpressRoute и сервером маршрутизации, и, следовательно, трафик из Azure будет проходить только в одном из подключений ExpressRoute.
Следующий шаг
Сведения о создании и настройке сервера маршрутизации Azure см. в статье: