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

Сводка

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

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

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

Обзор

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

На схеме цифры указывают ключевые сетевые точки:

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

В этой статье приводятся ссылки на эти сетевые точки по их связанному номеру.

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

В модели прямого подключения архитектура не включает сетевые точки 3 и 4. Вместо этого CEs (2) напрямую подключаются к MSEEs по тёмному волокну.

Если вы используете модель колокации Cloud Exchange, соединение Ethernet типа «точка-точка» или модель прямого подключения, CE (2) устанавливают BGP-пиринг с MSEE (5).

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

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

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

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

Проверка с помощью портала Azure

На портале Azure перейдите на страницу вашего канала ExpressRoute. Раздел страницы содержит основные сведения об ExpressRoute, как показано на следующем снимке экрана:

В разделе основных сведений об ExpressRoute Circuit status отображается состояние канала на стороне Microsoft, а Provider status отображается, подготовил ли поставщик услуг канал.

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

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

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

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

Чтобы получить сведения о конкретном канале 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, можно создать несколько конфигураций маршрутизации, использующих внешние BGP (eBGP) по каналу между CEs/MSEE-PEs (2/4) и MSEEs (5). Каждый канал ExpressRoute может иметь одну или обе из следующих конфигураций пиринга:

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

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

Проверка с помощью портала Azure

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

В предыдущем примере настроен частный пиринг Azure, но общедоступный пиринг Azure и пиринг Microsoft не настроены. Успешно подготовленный контекст пиринга также содержит основную и вторичную подсети типа «точка-точка». Подсети /30 используются для IP-адресов интерфейсов MSEE и 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.

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

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

Если пиринг не настроен, вы получите сообщение об ошибке. Ниже приведен пример ответа, когда указанный пиринг не настроен в канале:

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

Проверка ARP

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

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

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

Сведения о том, как просмотреть таблицу ARP в пиринге ExpressRoute и использовать информацию для устранения проблем с подключением уровня 2, см. в разделе Getting ARP tables in the Resource Manager deployment model.

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

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

Get-AzExpressRouteCircuitRouteTable -DevicePath Primary -ExpressRouteCircuitName <CircuitName> -PeeringType AzurePrivatePeering -ResourceGroupName <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##

Пример ответа, если пиринговое соединение не существует:

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

Подтверждение потока трафика

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

Get-AzExpressRouteCircuitStats -ResourceGroupName <ResourceGroupName> -ExpressRouteCircuitName <CircuitName> -PeeringType 'AzurePrivatePeering'

Пример выходных данных:

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

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

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

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

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

Проверка

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

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

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

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

5. Запустите тест PsPing из локального IP-адреса на IP-адрес Azure и поддерживайте его в рабочем состоянии во время теста.

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

   

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

Просмотрите результаты для основных и вторичных устройств MSEE:

• Совпадения, отправленные и полученные на обоих MSEE: указывает на нормальный входящий и исходящий трафик. Любая потеря происходит на этапе ниже MSEE.

• Получены соответствия, но нет отправленных: Трафик достигает Azure, но не возвращается. Проверьте проблемы с маршрутизацией пути возврата.

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

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

• If вы тестируете 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

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

Шлюз виртуальной сети ExpressRoute управляет подключением к службам приватного канала и частным IP-адресам в виртуальной сети Azure. Microsoft управляет этой инфраструктурой и может выполнять обслуживание, что может снизить производительность.

Чтобы устранить проблемы с подключением и проверить наличие недавнего обслуживания:

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

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

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

   

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

Дальнейшие шаги

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

• Служба поддержки Майкрософт
• Создание и изменение канала ExpressRoute
• Создание и изменение маршрутизации для канала ExpressRoute