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

Сводка

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

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

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

Обзор

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

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

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

Эти сетевые точки обозначены их соответствующими номерами в статье.

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

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

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

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

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

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

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

Проверка с помощью портала #REF!

На портале #REF! откройте страницу вашего контура ExpressRoute. В разделе значка "3Overview" страницы перечислены основные сведения ExpressRoute, как показано на следующем снимке экрана:

В разделе "Основные компоненты ExpressRoute " состояние канала указывает состояние канала на стороне Майкрософт, а состояние поставщика указывает, был ли канал подготовлен поставщиком услуг.

Для работы канала 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) и MSEE (5). Каждый канал ExpressRoute может иметь одну или обе из следующих конфигураций пиринга:

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

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

Проверка с помощью портала #REF!

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

В предыдущем примере #REF! приватный пиринг настроен, но #REF! публичный и пиринги Microsoft не настроены. Успешно подготовленный контекст пиринга также будет перечислять основные и вторичные подсети точка-точка. Подсети /30 используются для IP-адресов интерфейсов MSEE и CE/PE-MSEE. В списке также указывается, кто в последний раз изменил конфигурацию.

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

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

$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. На портале #REF! выберите Диагностика и решение проблем из схемы ExpressRoute.

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

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

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

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

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

   Форма для отладки ACL.

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

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

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

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

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

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

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

• Если вы тестируете PsPing из #REF! в локальную среду, отправляемые результаты показывают совпадения, но полученные результаты не показывают совпадений: это означает, что трафик поступает в локальную среду, но не возвращается к #REF!. Обратитесь к поставщику, чтобы узнать, почему трафик не направляется в #REF! через канал 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-адресам в виртуальной сети #REF!. Корпорация Майкрософт управляет этой инфраструктурой и может выполнять обслуживание, уменьшая производительность.

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

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

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

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

   Результаты диагностики.

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

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

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

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