Проверка подключения ExpressRoute.

  • Статья

Изучив сведения из этой статьи, вы узнаете, как проверить и устранить неполадки с подключением Azure ExpressRoute. ExpressRoute расширяет локальную сеть в Microsoft Cloud через частное подключение, которое обычно упрощает поставщик подключений. Как правило, для подключения ExpressRoute требуется три отдельные зоны сети:

  • Клиентская сеть
  • сеть поставщика;
  • центр обработки данных Майкрософт.

Примечание.

В модели подключения ExpressRoute Direct можно напрямую подключиться к порту маршрутизаторов Microsoft Enterprise Edge (MSEE). Модель прямого подключения включает только ваши и сетевые зоны Майкрософт.

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

Важно!

Эта статья предназначена для диагностики и устранения простых проблем. Она не заменит услуг службы поддержки Майкрософт. Если вы не можете решить проблему, следуя указаниям из этой статьи, отправьте запрос в службу поддержки Майкрософт.

Обзор

На следующей схеме показано логическое подключение между клиентской сетью и сетью Майкрософт через ExpressRoute. 1

На схеме выше цифрами обозначены ключевые точки сети.

  1. Клиентское вычислительное устройство (например, сервер или компьютер).
  2. Клиентские пограничные маршрутизаторы (CE).
  3. Пограничные маршрутизаторы (коммутаторы) поставщика услуг связи (PE), подключенные к клиентским пограничным маршрутизаторам.
  4. PE, подключенные к маршрутизаторам Microsoft Enterprise Edge (MSEE) ExpressRoute. В этой статье они называются PE-MSEE.
  5. MSEE.
  6. Шлюз виртуальной сети.
  7. Вычислительные устройства в виртуальной сети Azure.

Для указания точек сети в этой статье иногда используются соответствующие номера.

В зависимости от модели подключения ExpressRoute точки сети 3 и 4 могут быть коммутаторами (устройствами уровня 2) или маршрутизаторами (устройствами уровня 3). Модели подключения ExpressRoute: совместное размещение в Cloud Exchange, подключение типа "точка — точка" через Ethernet или "любой к любому" (IPVPN).

В модели прямого подключения отсутствуют точки сети 3 и 4. Вместо этого CE (2) напрямую подключаются к MSEE через темное волокно.

Если используется модель совместного размещения в Cloud Exchange, подключение типа "точка — точка" через Ethernet или прямое подключение, в пограничных маршрутизаторах клиента (2) устанавливается пиринг по протоколу BGP с MSEE (5).

Если используется модель подключения типа "любой к любому" (IPVPN), маршрутизаторы PE (подключенные к MSEE) (4) устанавливают пиринг BGP с маршрутизаторами MSEE (5). Маршрутизаторы периметра провайдера (РЕ), подключенные к MSEE, распространяют маршруты в обратном направлении в сеть клиента по сети поставщика услуг IPVPN.

Примечание.

Для обеспечения высокой доступности корпорация Майкрософт устанавливает полностью избыточное параллельное подключение между парами MSEE и PE-MSEE. Также рекомендуется использовать полностью избыточный параллельный сетевой путь между клиентской сетью и парами маршрутизаторов PE-CE. Дополнительные сведения о высокой доступности см. в статье Проектирование для обеспечения высокой доступности с помощью ExpressRoute.

В последующих разделах приведены логические шаги для устранения неполадок канала ExpressRoute.

Проверка подготовки и состояния канала

При подготовке канала ExpressRoute устанавливается избыточное подключение уровня 2 между маршрутизаторами CE/PE-MSEE (2/4) и MSEE (5). Дополнительные сведения о создании, изменении, подготовке и проверке канала ExpressRoute см. в кратком руководстве Создание и изменение канала ExpressRoute.

Совет

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

Проверка на портале Azure

На портале Azure откройте страницу канала ExpressRoute. В 3 разделе страницы перечислены основные компоненты ExpressRoute, как показано на следующем снимке экрана:

4

Параметр Состояние цепи в разделе основных сведений об ExpressRoute указывает состояние канала на стороне Майкрософт. Параметр Состояние поставщика указывает, был ли канал подготовлен на стороне поставщика услуг.

Для работы канала ExpressRoute параметр Состояние цепи должен иметь значение Включено, а параметр Состояние поставщика — значение Подготовлено.

Примечание.

Если после настройки канала ExpressRoute для параметра Состояние канала по-прежнему отображается значение Не включено, обратитесь в службу поддержки Майкрософт. Если параметр Состояние поставщика по-прежнему имеет значение Не подготовлено, обратитесь к поставщику услуг связи.

Проверка с помощью PowerShell

Чтобы получить список всех каналов ExpressRoute в группе ресурсов, используйте следующую команду:

Get-AzExpressRouteCircuit -ResourceGroupName "Test-ER-RG"

Совет

Если вы ищете имя группы ресурсов, вы можете получить его, перечислив все группы ресурсов в подписке с помощью команды Get-AzResourceGroup.

Чтобы выбрать конкретный канал ExpressRoute в группе ресурсов, используйте следующую команду:

Get-AzExpressRouteCircuit -ResourceGroupName "Test-ER-RG" -Name "Test-ER-Ckt"

Вот пример ответа:

Name                             : Test-ER-Ckt
ResourceGroupName                : Test-ER-RG
Location                         : westus2
Id                               : /subscriptions/***************************/resourceGroups/Test-ER-RG/providers/***********/expressRouteCircuits/Test-ER-Ckt
Etag                             : W/"################################"
ProvisioningState                : Succeeded
Sku                              : {
                                    "Name": "Standard_UnlimitedData",
                                    "Tier": "Standard",
                                    "Family": "UnlimitedData"
                                   }
CircuitProvisioningState         : Enabled
ServiceProviderProvisioningState : Provisioned
ServiceProviderNotes             :
ServiceProviderProperties        : {
                                    "ServiceProviderName": "****",
                                    "PeeringLocation": "******",
                                    "BandwidthInMbps": 100
                                   }
ServiceKey                       : **************************************
Peerings                         : []
Authorizations                   : []

Чтобы подтвердить работоспособность канала ExpressRoute, обратите особое внимание на следующие поля:

CircuitProvisioningState         : Enabled
ServiceProviderProvisioningState : Provisioned

Примечание.

После настройки канала ExpressRoute, если состояние канала зависло в состоянии "Не включено", обратитесь к служба поддержки Майкрософт. Если состояние поставщика зависло в состоянии "Не подготовлено", обратитесь к поставщику услуг.

Проверка конфигурации пиринга

Когда поставщик услуг завершит подготовку канала ExpressRoute, через этот канал можно будет создать несколько конфигураций маршрутизации eBGP между маршрутизаторами CE/MSEE-PE (2/4) и MSEE (5). Каждый канал ExpressRoute может иметь одну или обе из следующих конфигураций пиринга:

  • частный пиринг Azure — трафик к частным виртуальным сетям в Azure;
  • пиринг Майкрософт — трафик к общедоступным конечным точкам PaaS (платформа как услуга) и SaaS (программное обеспечение как услуга).

Дополнительные сведения о создании и изменении настроек маршрутизации см. в руководстве Создание и изменение пиринга для канала ExpressRoute с помощью портала Azure.

Проверка на портале Azure

Примечание.

В модели подключения IPVPN поставщики услуг отвечают за настройку пиринга (служб уровня 3). В такой модели после настройки пиринга поставщиком услуг, а также в случае, если сведения о пиринге на портале пусты, попробуйте обновить конфигурацию канала с помощью кнопки "Обновить" на портале. Эта операция извлечет правильную конфигурацию маршрутизации из вашей схемы.

Состояние канала ExpressRoute можно проверить на странице этого канала на портале Azure. В 3 разделе страницы перечислены пиринги ExpressRoute, как показано на следующем снимке экрана:

5

В предыдущем примере частный пиринг Azure подготовлен, тогда как общедоступный пиринг Azure и пиринг Майкрософт не подготовлены. Если контекст пиринга успешно подготовлен, в списке также отобразятся первичные и вторичные подсети типа "точка — точка". Подсети /30 используются для IP-адреса интерфейса маршрутизаторов MSEE и CE/PE-MSEE. Для подготавливаемых пирингов в списке также указывается, кто в последний раз изменял конфигурацию.

Примечание.

В случае сбоя включения пиринга проверьте, соответствуют ли назначенные первичные и вторичные подсети конфигурации связанных маршрутизаторов CE/PE-MSEE. Также проверьте, используются ли на маршрутизаторах MSEE правильные значения VlanId, AzureASN и PeerASN и соответствуют ли они значениям, используемым на связанном маршрутизаторе CE/PE-MSEE.

Если вы выбрали хэширование MD5, общий ключ должен быть одинаковым для пар маршрутизаторов MSEE и CE/PE-MSEE. Ранее настроенный общий ключ не будет отображаться из соображений безопасности.

Если на маршрутизаторе MSEE необходимо изменить любую из этих конфигураций, см. статью Создание и изменение маршрутизации для канала ExpressRoute.

Примечание.

В подсети /30, назначенной для интерфейса, Майкрософт выберет второй доступный IP-адрес подсети для интерфейса MSEE. Поэтому убедитесь, что первый доступный IP-адрес подсети назначен на одноранговом узле CE/PE-MSEE.

Проверка с помощью PowerShell

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

$ckt = Get-AzExpressRouteCircuit -ResourceGroupName "Test-ER-RG" -Name "Test-ER-Ckt"
Get-AzExpressRouteCircuitPeeringConfig -Name "AzurePrivatePeering" -ExpressRouteCircuit $ckt

Вот пример ответа в случае успешной настройки частного пиринга:

Name                       : AzurePrivatePeering
Id                         : /subscriptions/***************************/resourceGroups/Test-ER-RG/providers/***********/expressRouteCircuits/Test-ER-Ckt/peerings/AzurePrivatePeering
Etag                       : W/"################################"
PeeringType                : AzurePrivatePeering
AzureASN                   : 12076
PeerASN                    : 123##
PrimaryPeerAddressPrefix   : 172.16.0.0/30
SecondaryPeerAddressPrefix : 172.16.0.4/30
PrimaryAzurePort           :
SecondaryAzurePort         :
SharedKey                  :
VlanId                     : 200
MicrosoftPeeringConfig     : null
ProvisioningState          : Succeeded

Если контекст пиринга включен, в списке отобразятся первичные и вторичные префиксы адресов. Подсети /30 используются для IP-адреса интерфейса маршрутизаторов MSEE и CE/PE-MSEE.

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

$ckt = Get-AzExpressRouteCircuit -ResourceGroupName "Test-ER-RG" -Name "Test-ER-Ckt"
Get-AzExpressRouteCircuitPeeringConfig -Name "AzurePublicPeering" -ExpressRouteCircuit $ckt

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

$ckt = Get-AzExpressRouteCircuit -ResourceGroupName "Test-ER-RG" -Name "Test-ER-Ckt"
Get-AzExpressRouteCircuitPeeringConfig -Name "MicrosoftPeering" -ExpressRouteCircuit $ckt

Если пиринг не настроен, вы получите сообщение об ошибке. Вот пример ответа, если указанный пиринг (в этом примере — общедоступный пиринг Azure) не настроен в канале:

Get-AzExpressRouteCircuitPeeringConfig : Sequence contains no matching element
At line:1 char:1
    + Get-AzExpressRouteCircuitPeeringConfig -Name "AzurePublicPeering ...
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        + CategoryInfo          : CloseError: (:) [Get-AzExpr...itPeeringConfig], InvalidOperationException
        + FullyQualifiedErrorId : Microsoft.Azure.Commands.Network.GetAzureExpressRouteCircuitPeeringConfigCommand

Примечание.

В случае сбоя включения пиринга проверьте, соответствуют ли назначенные первичные и вторичные подсети конфигурации связанных маршрутизаторов CE/PE-MSEE. Также проверьте, используются ли на маршрутизаторах MSEE правильные значения VlanId, AzureASN и PeerASN и соответствуют ли они значениям, используемым на связанном маршрутизаторе CE/PE-MSEE.

Если вы выбрали хэширование MD5, общий ключ должен быть одинаковым для пар маршрутизаторов MSEE и CE/PE-MSEE. Ранее настроенный общий ключ не будет отображаться из соображений безопасности.

Если на маршрутизаторе MSEE необходимо изменить любую из этих конфигураций, см. статью Создание и изменение маршрутизации для канала ExpressRoute.

Примечание.

В подсети /30, назначенной для интерфейса, Майкрософт выберет второй доступный IP-адрес подсети для интерфейса MSEE. Поэтому убедитесь, что первый доступный IP-адрес подсети назначен на одноранговом узле CE/PE-MSEE.

Проверка ARP

Таблица протокола ARP обеспечивает сопоставление IP-адреса и MAC-адреса для конкретного пиринга. Таблица ARP для пиринга канала ExpressRoute содержит следующие сведения о каждом интерфейсе (первичном и вторичном).

  • Сопоставление IP-адреса интерфейса локального маршрутизатора с MAC-адресом.
  • Сопоставление IP-адреса интерфейса маршрутизатора ExpressRoute с MAC-адресом (необязательно).
  • Длительность сопоставления.

Таблицы ARP помогают проверить конфигурацию уровня 2 и устранить проблемы с подключением на базовом уровне 2.

Примечание.

В зависимости от аппаратной платформы результаты ARP могут отличаться и отображать только локальный интерфейс.

Сведения о том, как просмотреть таблицу ARP пиринга ExpressRoute и как использовать эту информацию для устранения неполадок подключения уровня 2, см. в документе Получение таблиц ARP в модели развертывания с помощью Resource Manager.

Проверка BGP и маршрутов MSEE

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

Get-AzExpressRouteCircuitRouteTable -DevicePath Primary -ExpressRouteCircuitName ******* -PeeringType AzurePrivatePeering -ResourceGroupName ****

Вот пример ответа:

Network : 10.1.0.0/16
NextHop : 10.17.17.141
LocPrf  :
Weight  : 0
Path    : 65515

Network : 10.1.0.0/16
NextHop : 10.17.17.140*
LocPrf  :
Weight  : 0
Path    : 65515

Network : 10.2.20.0/25
NextHop : 172.16.0.1
LocPrf  :
Weight  : 0
Path    : 123##

Примечание.

Если пиринг eBGP между MSEE и CE/PE-MSEE находится в состоянии Активно или Бездействие, проверьте, соответствуют ли назначенные первичные и вторичные подсети конфигурации связанных маршрутизаторов CE/PE-MSEE. Также проверьте, используются ли на маршрутизаторах MSEE правильные значения VlanId, AzureASN и PeerASN и соответствуют ли они значениям, используемым на связанном маршрутизаторе CE/PE-MSEE. Если вы выбрали хэширование MD5, общий ключ должен быть одинаковым для пар маршрутизаторов MSEE и CE/PE-MSEE. Если на маршрутизаторе MSEE необходимо изменить любую из этих конфигураций, см. статью Создание и изменение маршрутизации для канала ExpressRoute.

Примечание.

Если некоторые целевые объекты недоступны посредством пиринга, проверьте таблицу маршрутов MSEE на наличие соответствующего контекста пиринга. Если в таблице маршрутизации указан соответствующий префикс (это может быть преобразованный через NAT IP-адрес), проверьте, не блокируют ли трафик на пути брандмауэры, группы безопасности сети или списки управления доступом (ACL).

В следующем примере показан ответ команды, если пиринг не существует:

Get-AzExpressRouteCircuitRouteTable : The BGP Peering AzurePublicPeering with Service Key ********************* is not found.
StatusCode: 400

Подтверждение наличия трафика

Для получения сводной статистики трафика (переданных и полученных байтов) по первичному и вторичному пути для контекста пиринга используйте следующую команду:

Get-AzExpressRouteCircuitStats -ResourceGroupName $RG -ExpressRouteCircuitName $CircuitName -PeeringType 'AzurePrivatePeering'

Вот пример выходных данных этой команды:

PrimaryBytesIn PrimaryBytesOut SecondaryBytesIn SecondaryBytesOut
-------------- --------------- ---------------- -----------------
     240780020       239863857        240565035         239628474

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

Get-AzExpressRouteCircuitRouteTable : The BGP Peering AzurePublicPeering with Service Key ********************* is not found.
StatusCode: 400

Тестирование частного пирингового подключения

Проверьте подключение частного пиринга, подсчитав количество входящих и исходящих пакетов на границе Майкрософт канала ExpressRoute на устройствах MSEE. Это средство диагностики использует ACL в MSEE для подсчета числа пакетов, которые соответствуют определенным правилам ACL. Это средство позволяет подтвердить работоспособность подключения, получив ответы на такие вопросы:

  • Поступают ли мои пакеты в Azure?
  • Возвращаются ли они в локальную среду?

Проверка

  1. Чтобы воспользоваться этим средством диагностики, выберите Диагностика и решение проблем в своем канале ExpressRoute на портале Azure.

    Screenshot of the button for diagnosing and solving problems from the ExpressRoute circuit.

  2. Выберите Подключение проблемы с производительностью и производительностью.

    Screenshot of the option for connectivity issues.

  3. В раскрывающемся списке "Сообщите нам больше о проблеме" выберите "Проблемы с частным пирингом".

    Screenshot of the dropdown option for the problem that the user is experiencing.

  4. Прокрутите вниз до раздела подключения к частному пирингу и разверните его.

    Screenshot of the options for troubleshooting connectivity issues, with the option for private peering highlighted.

  5. Выполните проверку PsPing с локального IP-адреса на IP-адрес Azure и обеспечьте ее выполнение в течение проверки подключения.

  6. Заполните поля формы. Обязательно укажите те же локальные IP-адреса и IP-адреса Azure, которые использовались на шаге 5. Затем выберите Отправить и дождитесь загрузки результатов.

    Screenshot of the form for debugging an A C L.

Интерпретация результатов

Когда результаты будут готовы, у вас есть два набора для основных и вторичных устройств MSEE. Просмотрите количество совпадений для входных и выходных данных и воспользуйтесь сценариями ниже, чтобы интерпретировать результаты:

  • Отправленные и полученные пакеты на обоих MSEE совпадают. Это свидетельствует о надлежащем приеме и отправке трафика для MSEE в вашем канале. Если в локальной среде или в Azure наблюдается потеря данных, причину нужно искать за MSEE.

  • Если при проверке с помощью PsPing из локальной среды в Azure (полученные пакеты) вы получаете совпадения, но при отправке совпадений нет, это свидетельствует о том, что трафик отправляется в Azure, но не возвращается в локальную среду. Проверьте, нет ли проблем маршрутизации обратного пути. Например, проверьте, объявляете ли вы соответствующие префиксы в Azure. Переопределяет ли префиксы определяемый пользователем маршрут (UDR)?

  • Если при проверке с помощью PsPing из Azure в локальную среду (отправленные пакеты) совпадений нет, но при получении совпадения отсутствуют, это свидетельствует о том, что трафик поступает в локальную среду, но не возвращается в Azure. Обратитесь к своему поставщику, чтобы определить, почему трафик не направляется в Azure через ваш канал ExpressRoute.

  • Один маршрутизатор MSEE не показывает совпадений, а другой показывает.Это свидетельствует о том, что один маршрутизатор MSEE не получает или не передает трафик. Возможно, он отключен (например, BGP/ARP не работает).

    • Вы можете выполнить дополнительное тестирование, чтобы выявить неработоспособный путь, объявив уникальный локальный маршрут /32 через сеанс BGP на этом пути.
    • Выполните команду "Проверка подключения частного пиринга" с помощью уникального адреса /32, объявленного в качестве локального адреса назначения, и просмотрите результаты, чтобы подтвердить работоспособность пути.

Результаты проверки каждого устройства MSEE будут выглядеть аналогично тому, как показано в примере ниже.

src 10.0.0.0 dst 20.0.0.0 dstport 3389 (received): 120 matches
src 20.0.0.0 srcport 3389 dst 10.0.0.0 (sent): 120 matches

Этот результат проверки имеет следующие свойства:

  • порт IP-адреса: 3389;
  • CIDR локального IP-адреса: 10.0.0.0;
  • CIDR IP-адреса в Azure: 20.0.0.0.

Проверка доступности шлюза виртуальной сети

Шлюз ExpressRoute для виртуальной сети упрощает операции уровня управления для подключений к службам приватных каналов и к частным IP-адресам в виртуальной сети Azure. Корпорация Майкрософт управляет инфраструктурой шлюза виртуальной сети и иногда выполняет обслуживание.

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

  1. Выберите Диагностика и решение проблем в своем канале ExpressRoute на портале Azure.

    Screenshot of the button for diagnosing and solving problem from an ExpressRoute circuit.

  2. Выберите вариант Проблемы с производительностью.

    Screenshot of selecting the option for performance issues.

  3. Дождитесь запуска диагностики и оцените результаты.

    Screenshot of the diagnostic results.

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

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

Дополнительные сведения доступны в следующих источниках: