Диагностика и устранение неисправностей программно-определяемого сетевого стека Windows Server

В этом руководстве рассматриваются распространенные ошибки программно-определяемой сети (SDN) и сценарии сбоев, а также описан рабочий процесс устранения неполадок, использующий доступные средства диагностики. Дополнительные сведения о SDN см. в разделе "Программное определение сети".

Применимо к: Windows Server 2022, Windows Server 2019, Windows Server 2016 и Azure Stack HCI, версии 21H2 и 20H2

Типы ошибок

В следующем списке представлен класс проблем, которые наиболее часто возникают при работе с виртуализацией сети Hyper-V (HNVv1) в Windows Server 2012 R2 на реальных развертываниях, и в значительной степени совпадают с проблемами, наблюдаемыми в Windows Server 2016 HNVv2 с использованием нового стека программно-определяемых сетей (SDN).

Большинство ошибок можно классифицировать в небольшой набор классов:

  • Недопустимая или неподдерживаемая конфигурация

    Пользователь вызывает API NorthBound неправильно или с недопустимой политикой.

  • Ошибка в приложении политики

    Политика из сетевого контроллера не была доставлена на узел Hyper-V, отложена или не обновлена на всех узлах Hyper-V (например, после динамической миграции).

  • Смещение конфигурации или ошибка программного обеспечения

    Проблемы с путем передачи данных, приводящие к потерянным пакетам.

  • Внешняя ошибка, связанная с сетевым адаптером или драйверами или подложной сетевой структурой

    Неправильная разгрузка задач (например, VMQ) или неправильно настроенная сетевая структура (например, MTU)

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

Средства диагностики

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

Чтобы использовать средства диагностики сетевого контроллера (control-path), необходимо сначала установить функцию RSAT-NetworkController и импортировать модуль NetworkControllerDiagnostics.

Add-WindowsFeature RSAT-NetworkController -IncludeManagementTools
Import-Module NetworkControllerDiagnostics

Чтобы использовать средства диагностики HNV (путь к данным), необходимо импортировать модуль HNVDiagnostics:

# Assumes RSAT-NetworkController feature has already been installed
Import-Module hnvdiagnostics

Диагностика сетевого контроллера

Эти командлеты описаны в TechNet в командлете диагностики сетевого контроллера. Они помогают определить проблемы согласованности политики сети в пути управления между узлами сетевого контроллера и между сетевым контроллером и агентами узла NC, работающими на Hyper-V узлах.

Командлеты Debug-ServiceFabricNodeStatus и Get-NetworkControllerReplica должны выполняться с одной из виртуальных машин узла Управляющего Контроллера. Все остальные командлеты диагностики NC можно запускать с любого узла, который имеет подключение к сетевому контроллеру и находится в группе безопасности управления сетевыми контроллерами (Kerberos) или имеет доступ к сертификату X.509 для управления сетевым контроллером.

диагностика узла Hyper-V

Эти командлеты описаны в TechNet в командлете диагностики Hyper-V Network Virtualization (HNV). Они помогают выявить проблемы в пути передачи данных между виртуальными машинами арендаторов (трафик Восток-Запад) и входящим трафиком через SLB VIP (трафик Север-Юг).

Debug-VirtualMachineQueueOperation, , Get-CustomerRoute, Get-PACAMappingGet-ProviderAddressGet-VMNetworkAdapterPortIdGet-VMSwitchExternalPortIdи Test-EncapOverheadSettings являются всеми локальными тестами, которые могут выполняться из любого узла Hyper-V. Другие командлеты вызывают тесты маршрута данных через сетевой контроллер и, следовательно, требуют доступ к сетевому контроллеру, как описано ранее.

GitHub

Репозиторий GitHub Microsoft/SDN содержит множество примеров скриптов и рабочих процессов, которые создаются на основе этих встроенных командлетов. В частности, скрипты диагностики можно найти в папке диагностики . Помогите нам внести свой вклад в эти сценарии, отправив пул-реквесты.

Устранение неполадок рабочих процессов и руководств

[Hoster] Проверка работоспособности системы

В нескольких ресурсах сетевого контроллера есть внедренный ресурс с именем "Состояние конфигурации ". Состояние конфигурации предоставляет сведения о работоспособности системы, включая согласованность между конфигурацией сетевого контроллера и фактическим (запущенным) состоянием на Hyper-V узлах.

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

Замечание

Значением параметра NetworkController должно быть полное доменное имя или IP-адрес на основе имени субъекта сертификата X.509 >, созданного для сетевого контроллера.

Параметр Credential необходимо указать только в том случае, если сетевой контроллер использует проверку подлинности Kerberos (обычно в развертываниях VMM). Учетные данные должны быть для пользователя, который находится в группе безопасности управления сетевыми контроллерами.

Debug-NetworkControllerConfigurationState -NetworkController <FQDN or NC IP> [-Credential <PS Credential>]

# Healthy State Example - no status reported
$cred = Get-Credential
Debug-NetworkControllerConfigurationState -NetworkController 10.127.132.211 -Credential $cred

Fetching ResourceType:     accessControlLists
Fetching ResourceType:     servers
Fetching ResourceType:     virtualNetworks
Fetching ResourceType:     networkInterfaces
Fetching ResourceType:     virtualGateways
Fetching ResourceType:     loadbalancerMuxes
Fetching ResourceType:     Gateways

Сообщение о состоянии конфигурации напоминает следующий пример:

Fetching ResourceType:     servers
---------------------------------------------------------------------------------------------------------
ResourcePath:     https://10.127.132.211/Networking/v1/servers/4c4c4544-0056-4b10-8058-b8c04f395931
Status:           Warning

Source:           SoftwareLoadBalancerManager
Code:             HostNotConnectedToController
Message:          Host is not Connected.
----------------------------------------------------------------------------------------------------------

Замечание

В системе возникает ошибка, из-за которой ресурсы сетевого интерфейса для NIC транзитной ВМ SLB Mux находятся в состоянии сбоя с ошибкой "Виртуальный коммутатор — хост не подключен к контроллеру". Эта ошибка может быть безопасно проигнорирована, если IP-конфигурация в NIC для ВМ установлена на IP-адрес из пула IP-адресов Транзитной Логической Сети.

В системе возникает вторая ошибка, из-за которой ресурсы сетевого интерфейса для сетевых адаптеров HNV Provider VM для шлюза находятся в состоянии ошибки с сообщением "Виртуальный коммутатор — порт заблокирован". Эта ошибка также может быть безопасно проигнорирована, если ip-конфигурация в ресурсе сетевой карты виртуальной машины имеет значение NULL (по проектированию).

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

Code Message Действие
Неизвестно Неизвестная ошибка
Хост недоступен Хост-компьютер недоступен Проверка сетевого подключения управления между сетевым контроллером и узлом
PAIpAddressExhausted (исчерпан адрес IP) IP-адреса PA исчерпаны Увеличьте размер пула IP-адресов логической подсети поставщика HNV
PAИсчерпанMacAddress Адреса PA Mac исчерпаны Увеличение диапазона пула MAC
Ошибка настройки адреса ПАК Не удалось подключить PA-адреса к хосту Проверьте сетевое подключение управления между сетевым контроллером и узлом.
СертификатНеДоверен Сертификат не является доверенным Исправьте сертификаты, используемые для взаимодействия с узлом.
СертификатНеАвторизован Сертификат не авторизован Исправьте сертификаты, используемые для взаимодействия с узлом.
Ошибка конфигурации политики на Vfp (PolicyConfigurationFailureOnVfp) Сбой при настройке политик VFP Это сбой среды выполнения. Нет конкретных обходных решений. Сбор журналов.
Сбой настройки политики Сбой при отправке политик на узлы из-за сбоев связи или других ошибок в NetworkController. Никаких определенных действий. Это связано с сбоем в обработке состояния цели в модулях сетевого контроллера. Соберите журналы.
ХостНеПодключенККонтроллеру Хост еще не подключен к сетевому контроллеру Профиль порта не применяется к узлу или узел недоступен для сетевого контроллера. Убедитесь, что раздел реестра HostID соответствует идентификатору экземпляра ресурса сервера.
Множественные Vfp-включенные переключатели На узле есть несколько включенных коммутаторов VFp Удалите один из коммутаторов, так как агент узла сетевого контроллера поддерживает только один vSwitch с включенным расширением VFP.
ОшибкаНастройкиПолитики Не удалось отправить политики виртуальной сети для виртуального сетевого интерфейса из-за ошибок сертификата или проблем с подключением. Проверьте, были ли развернуты правильные сертификаты (имя субъекта сертификата должно соответствовать полному доменному имени хоста). Также проверьте подключение узла к сетевому контроллеру.
СбойНастройкиПолитики Не удалось отправить политики vSwitch для VmNic из-за ошибок сертификата или ошибок подключения. Проверьте, были ли развернуты правильные сертификаты (имя субъекта сертификата должно соответствовать полному доменному имени узла). Также проверьте подключение узла к сетевому контроллеру.
ОшибкаНастройкиПолитики Не удалось создать политики брандмауэра для виртуального сетевого интерфейса (VmNic) из-за ошибок с сертификатом или подключения. Проверьте, были ли развернуты правильные сертификаты (имя субъекта сертификата должно соответствовать полному доменному имени узла). Также проверьте подключение узла к сетевому контроллеру.
Сбой конфигурации распределенного маршрутизатора Не удалось сконфигурировать параметры распределённого маршрутизатора на виртуальном сетевом интерфейсе узла. Ошибка стека TCPIP. Может потребоваться очистка виртуальных сетевых интерфейсов узлов PA и DR на сервере, на котором была зарегистрирована эта ошибка.
Ошибка выделения адреса DHCP Сбой выделения DHCP-адреса для интерфейса VMNic. Проверьте, настроен ли атрибут статического IP-адреса в ресурсе сетевого адаптера.
Сертификат не доверен
СертификатНеАвторизован		 Не удалось подключиться к Mux из-за ошибок сети или сертификатов Проверьте числовой код, предоставленный в коде сообщения об ошибке: это соответствует коду ошибки winsock. Ошибки сертификата детализированы (например, сертификат не может быть проверен, сертификат не авторизован и т. д.).
Хост недоступен MUX является неработоспособным (распространенный случай — BGPRouter отключен) Пиринговое подключение BGP на виртуальной машине RRAS (BGP) или коммутаторе Top-of-Rack (ToR) недоступно или не устанавливается успешно. Проверьте настройки BGP как на ресурсе программного мультиплексора балансировки нагрузки, так и у однорангового узла BGP (виртуальная машина ToR или RRAS).
УзелНеПодключенККонтроллеру Агент узла SLB не подключен Убедитесь, что служба агента узла SLB запущена. Обратитесь к автоматически запущенным журналам агента узла SLB, чтобы понять причины, по которым SLBM (NC) мог отклонить сертификат, представленный агентом узла. Состояние выполнения агента показывает детализированную информацию.
Порт заблокирован Порт VFP заблокирован из-за отсутствия политик виртуальной сети или ACL Проверьте наличие других ошибок, которые могут привести к тому, что политики не настроены.
Перегруженные Балансировщик нагрузки MUX перегружен Проблема с производительностью мультиплексора.
RoutePublicationFailure Балансировщик нагрузки MUX не подключен к маршрутизатору BGP Проверьте, есть ли у мультиплексора подключение к маршрутизаторам BGP и правильно ли настроено пиринговое соединение BGP.
Виртуальный сервер недоступен Load balancer MUX не подключен к SLB manager Проверьте подключение между SLBM и MUX.
Ошибка настройки QoS Не удалось настроить политики QOS Узнайте, доступна ли достаточная пропускная способность для всех виртуальных машин, если используется резервирование QOS.

Проверьте сетевое подключение между сетевым контроллером и узлом Hyper-V (служба агента узла NC)

Выполните следующую netstat команду, чтобы убедиться, что существует три ESTABLISHED соединения между агентом узла NC и узлом(узлами) сетевого контроллера, а также один LISTENING сокет на узле Hyper-V.

  • ПРОСЛУШИВАНИЕ ЧЕРЕЗ ПОРТ TCP: 6640 на узле Hyper-V (служба агента узла NC)
  • Два установленных подключения от IP-адреса узла Hyper-V через порт 6640 к IP-адресу узла NC на временных портах (> 32000)
  • Одно установленное подключение из IP-адреса узла Hyper-V на эфемерный порт к IP-адресу REST интерфейса сетевого контроллера через порт 6640

Замечание

На узле Hyper-V может быть только два установленных подключения, если на этом конкретном узле не развернуты виртуальные машины клиента.

netstat -anp tcp |findstr 6640

# Successful output
  TCP    0.0.0.0:6640           0.0.0.0:0              LISTENING
  TCP    10.127.132.153:6640    10.127.132.213:50095   ESTABLISHED
  TCP    10.127.132.153:6640    10.127.132.214:62514   ESTABLISHED
  TCP    10.127.132.153:50023   10.127.132.211:6640    ESTABLISHED

Проверка служб агента хоста

Сетевой контроллер взаимодействует с двумя службами агента узла на Hyper-V узлах: агент узла SLB и агент узла NC. Возможно, что одна или обе эти службы не работают. Проверьте их состояние и перезапустите, если они не запущены.

Get-Service SlbHostAgent
Get-Service NcHostAgent

# (Re)start requires -Force flag
Start-Service NcHostAgent -Force
Start-Service SlbHostAgent -Force

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

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

# Prints a DIFF state (status is automatically updated if state is changed) of a particular service module replica
Debug-ServiceFabricNodeStatus [-ServiceTypeName] <Service Module>

Модули службы сетевого контроллера:

  • ControllerService
  • ApiService
  • SlbManagerService
  • ServiceInsertion
  • СлужбаБрандмауэра
  • VSwitchService
  • GatewayManager
  • FnmService
  • HelperService
  • UpdateService

Убедитесь, что ReplicaStatus является Ready и HealthState является Ok.

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

Get-NetworkControllerReplica

# Sample Output for the API service module
Replicas for service: ApiService

ReplicaRole   : Primary
NodeName      : SA18N30NC3.sa18.nttest.microsoft.com
ReplicaStatus : Ready

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

Проверьте наличие соответствующих идентификаторов узлов и сертификатов между сетевым контроллером и каждым узлом Hyper-V

На узле Hyper-V выполните следующие командлеты, чтобы убедиться, что HostID соответствует идентификатору экземпляра ресурса сервера на сетевом контроллере

Get-ItemProperty "hklm:\system\currentcontrolset\services\nchostagent\parameters" -Name HostId |fl HostId

HostId : **162cd2c8-08d4-4298-8cb4-10c2977e3cfe**

Get-NetworkControllerServer -ConnectionUri $uri |where { $_.InstanceId -eq "162cd2c8-08d4-4298-8cb4-10c2977e3cfe"}

Tags             :
ResourceRef      : /servers/a0a0a0a0-bbbb-cccc-dddd-e1e1e1e1e1e1
InstanceId       : **162cd2c8-08d4-4298-8cb4-10c2977e3cfe**
Etag             : W/"50f89b08-215c-495d-8505-0776baab9cb3"
ResourceMetadata : Microsoft.Windows.NetworkController.ResourceMetadata
ResourceId       : a0a0a0a0-bbbb-cccc-dddd-e1e1e1e1e1e1
Properties       : Microsoft.Windows.NetworkController.ServerProperties

Исправление

При использовании скриптов SDNExpress или ручного развертывания обновите раздел HostId в реестре, чтобы он соответствовал идентификатору экземпляра ресурса сервера. Перезапустите агент узла сетевого контроллера на узле Hyper-V (физическом сервере) При использовании VMM удалите сервер Hyper-V из VMM и удалите раздел реестра HostId. Затем снова добавьте сервер через VMM.

Убедитесь, что отпечатки сертификатов X.509, используемых узлом Hyper-V (имя узла — это имя субъекта сертификата) для Южного направления связи между узлом Hyper-V (служба агента узла NC) и узлами сетевого контроллера, одинаковы. Кроме того, убедитесь, что REST-сертификат сетевого контроллера имеет имя субъекта CN=<FQDN or IP>.

# On Hyper-V Host
dir cert:\\localmachine\my

Thumbprint                                Subject
----------                                -------
2A3A674D07D8D7AE11EBDAC25B86441D68D774F9  CN=SA18n30-4.sa18.nttest.microsoft.com
...

dir cert:\\localmachine\root

Thumbprint                                Subject
----------                                -------
30674C020268AA4E40FD6817BA6966531FB9ADA4  CN=10.127.132.211 **# NC REST IP ADDRESS**

# On Network Controller Node VM
dir cert:\\localmachine\root

Thumbprint                                Subject
----------                                -------
2A3A674D07D8D7AE11EBDAC25B86441D68D774F9  CN=SA18n30-4.sa18.nttest.microsoft.com
30674C020268AA4E40FD6817BA6966531FB9ADA4  CN=10.127.132.211 **# NC REST IP ADDRESS**
...

Вы также можете проверить следующие параметры каждого сертификата, чтобы убедиться, что имя субъекта является ожидаемым (имя узла или полное доменное имя NC REST ИЛИ IP-адрес), сертификат еще не истек, и что все центры сертификации в цепочке сертификатов включены в доверенный корневой центр.

  • Имя субъекта
  • Дата окончания срока действия
  • Доверенный корневым удостоверяющим центром

Если несколько сертификатов имеют одно и то же имя субъекта на узле Hyper-V, агент узла сетевого контроллера случайным образом выбирает один для представления сетевому контроллеру. Это может не совпадать с отпечатком ресурса сервера, известного сетевому контроллеру. В этом случае удалите один из сертификатов с тем же именем субъекта на узле Hyper-V, а затем перезапустите службу агента узла сетевого контроллера. Если подключение еще не удается сделать, удалите другой сертификат с тем же именем субъекта на узле Hyper-V и удалите соответствующий ресурс сервера в VMM. Затем повторно создайте ресурс сервера в VMM, который создает новый сертификат X.509 и установите его на узле Hyper-V.

Проверка состояния конфигурации SLB

Состояние конфигурации SLB можно определить как часть выходных данных командлета Debug-NetworkController . Этот командлет также перечисляет текущий список ресурсов сетевого контроллера в JSON-файлах, все IP-конфигурации из каждого узла Hyper-V (сервера) и локальные сетевые политики из таблиц базы данных агента узла.

По умолчанию собираются трассировки mMore. Чтобы не собирать следы, добавьте параметр -IncludeTraces:$false.

Debug-NetworkController -NetworkController <FQDN or IP> [-Credential <PS Credential>] [-IncludeTraces:$false]

# Don't collect traces
$cred = Get-Credential
Debug-NetworkController -NetworkController 10.127.132.211 -Credential $cred -IncludeTraces:$false

Transcript started, output file is C:\NCDiagnostics.log
Collecting Diagnostics data from NC Nodes

Замечание

Расположение выходных данных по умолчанию — <каталог working_directory>\NCDiagnostics\. Выходной каталог по умолчанию можно изменить с помощью -OutputDirectory параметра.

Сведения о состоянии конфигурации SLB можно найти в файле diagnostics-slbstateResults.Json в этом каталоге.

Этот JSON-файл можно разбить на следующие разделы:

  • Ткань
    • SlbmVips - В этом разделе перечислен VIP-адрес диспетчера SLB, который используется сетевым контроллером для координации конфигурации и состояния между мультиплексорами SLB и агентами узлов SLB.
    • MuxState — в этом разделе перечислено одно значение для каждого развернутого балансировщика SLB Mux, показывающее состояние мультиплексора.
    • Конфигурация маршрутизатора. В этом разделе перечислены номер автономной системы (ASN), IP-адрес, и идентификатор вышестоящего маршрутизатора (BGP peer). Он также перечисляет SLB Muxes ASN и транзитные IP-адреса.
    • Сведения о подключенном узле. В этом разделе перечислены IP-адрес управления все узлы Hyper-V, доступные для выполнения рабочих нагрузок с балансировкой нагрузки.
    • Диапазоны VIP-адресов - В этом разделе перечислены диапазоны пулов общедоступных и частных IP-адресов. IP-адрес SLBM VIP включается в качестве выделенного IP-адреса из одного из этих диапазонов.
    • Маршруты Mux — в этом разделе перечисляется одно значение для каждого развернутого SLB Mux, содержащего все объявления маршрутов для данного конкретного Mux.
  • Съёмщик
    • VipConsolidatedState — в этом разделе перечислены состояния подключения для каждого VIP арендатора, включая объявленный префикс маршрута, хост Hyper-V и конечные точки DIP.

Замечание

Состояние SLB можно определить непосредственно с помощью скрипта DumpSlbRestState , доступного в репозитории GitHub Microsoft SDN.

Проверка шлюза

Из сетевого контроллера:

Get-NetworkControllerLogicalNetwork
Get-NetworkControllerPublicIPAddress
Get-NetworkControllerGatewayPool
Get-NetworkControllerGateway
Get-NetworkControllerVirtualGateway
Get-NetworkControllerNetworkInterface

Из виртуальной машины шлюза:

Ipconfig /allcompartments /all
Get-NetRoute -IncludeAllCompartments -AddressFamily
Get-NetBgpRouter
Get-NetBgpRouter | Get-BgpPeer
Get-NetBgpRouter | Get-BgpRouteInformation

От коммутатора верхнего уровня стойки (ToR):

sh ip bgp summary (for 3rd party BGP Routers)

Маршрутизатор BGP Для Windows:

Get-BgpRouter
Get-BgpPeer
Get-BgpRouteInformation

В дополнение к этим проблемам, которые мы видели до сих пор (особенно в развертываниях на основе SDNExpress), наиболее распространенная причина того, что отсек клиента не настраивается на виртуальных машинах GW, кажется, тот факт, что емкость GW в FabricConfig.psd1 меньше по сравнению с тем, что люди пытаются назначить сетевым подключениям (S2S Tunnels) в TenantConfig.psd1. Это можно легко проверить, сравнивая выходные данные следующих командлетов:

PS > (Get-NetworkControllerGatewayPool -ConnectionUri $uri).properties.Capacity
PS > (Get-NetworkControllerVirtualgatewayNetworkConnection -ConnectionUri $uri -VirtualGatewayId "TenantName").properties.OutboundKiloBitsPerSecond
PS > (Get-NetworkControllerVirtualgatewayNetworkConnection -ConnectionUri $uri -VirtualGatewayId "TenantName").property

[Hoster] Проверить Data-Plane

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

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

После подключения первой гостевой виртуальной машины на узле Hyper-V к виртуальной сети клиента сетевой контроллер назначает два IP-адреса поставщика HNV (IP-адреса PA) узлу Hyper-V. Эти IP-адреса приходят из пула IP-адресов поставщика HNV, а сетевой контроллер управляет ими. Чтобы узнать, что такое два IP-адреса HNV, выполните следующий командлет:

PS > Get-ProviderAddress

# Sample Output
ProviderAddress : 10.10.182.66
MAC Address     : 40-1D-D8-B7-1C-04
Subnet Mask     : 255.255.255.128
Default Gateway : 10.10.182.1
VLAN            : VLAN11

ProviderAddress : 10.10.182.67
MAC Address     : 40-1D-D8-B7-1C-05
Subnet Mask     : 255.255.255.128
Default Gateway : 10.10.182.1
VLAN            : VLAN11

Эти IP-адреса поставщика HNV (IP-адреса PA) назначаются адаптерам Ethernet, созданным в отдельном сетевом сегменте TCPIP и имеющим имя адаптера VLANX, где X — это VLAN, назначенная логической сети поставщика HNV (транспортировка).

Подключение между двумя узлами Hyper-V с использованием логической сети поставщика HNV можно проверить с помощью команды ping с дополнительным параметром (-c Y), где Y — это сетевой compartment TCPIP, в котором создаются PAhostVNICs. Чтобы определить этот раздел, выполните следующую команду в командной строке Windows:

C:\> ipconfig /allcompartments /all

<snip> ...
==============================================================================
Network Information for *Compartment 3*
==============================================================================
   Host Name . . . . . . . . . . . . : SA18n30-2
<snip> ...

Ethernet adapter VLAN11:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Microsoft Hyper-V Network Adapter
   Physical Address. . . . . . . . . : 40-1D-D8-B7-1C-04
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::5937:a365:d135:2899%39(Preferred)
   IPv4 Address. . . . . . . . . . . : 10.10.182.66(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.128
   Default Gateway . . . . . . . . . : 10.10.182.1
   NetBIOS over Tcpip. . . . . . . . : Disabled

Ethernet adapter VLAN11:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Microsoft Hyper-V Network Adapter
   Physical Address. . . . . . . . . : 40-1D-D8-B7-1C-05
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::28b3:1ab1:d9d9:19ec%44(Preferred)
   IPv4 Address. . . . . . . . . . . : 10.10.182.67(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.128
   Default Gateway . . . . . . . . . : 10.10.182.1
   NetBIOS over Tcpip. . . . . . . . : Disabled

*Ethernet adapter vEthernet (PAhostVNic):*
<snip> ...

Замечание

Виртуальные сетевые адаптеры хоста PA не используются в канале передачи данных и поэтому адаптеру vEthernet (PAhostVNic) не назначен IP-адрес.

Например, предположим, что узел Hyper-V 1, и узел 2 имеют IP-адреса поставщика HNV (PA):

Узел Hyper-V IP-адрес PA 1 IP-адрес PA 2
Хост 1 10.10.182.64 10.10.182.65
Хост 2 10.10.182.66 10.10.182.67

Для проверки логического сетевого подключения поставщика HNV можно выполнить ping между двумя узлами, используя следующую команду.

# Ping the first PA IP Address on Hyper-V Host 2 from the first PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.66 -S 10.10.182.64

# Ping the second PA IP Address on Hyper-V Host 2 from the first PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.67 -S 10.10.182.64

# Ping the first PA IP Address on Hyper-V Host 2 from the second PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.66 -S 10.10.182.65

# Ping the second PA IP Address on Hyper-V Host 2 from the second PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.67 -S 10.10.182.65

Исправление

Если команда ping для поставщика HNV не работает, проверьте подключение к физической сети, включая конфигурацию VLAN. Физические сетевые адаптеры на каждом узле Hyper-V должны находиться в режиме магистрали без назначения определенной виртуальной локальной сети. Сетевой адаптер управления (vNIC) должен быть изолирован в VLAN логической сети управления.

PS C:\> Get-NetAdapter "Ethernet 4" |fl

Name                       : Ethernet 4
InterfaceDescription       : <NIC> Ethernet Adapter
InterfaceIndex             : 2
MacAddress                 : F4-52-14-55-BC-21
MediaType                  : 802.3
PhysicalMediaType          : 802.3
InterfaceOperationalStatus : Up
AdminStatus                : Up
LinkSpeed(Gbps)            : 10
MediaConnectionState       : Connected
ConnectorPresent           : True
*VlanID                     : 0*
DriverInformation          : Driver Date 2016-08-28 Version 5.25.12665.0 NDIS 6.60

# VMM uses the older PowerShell cmdlet <Verb>-VMNetworkAdapterVlan to set VLAN isolation
PS C:\> Get-VMNetworkAdapterVlan -ManagementOS -VMNetworkAdapterName <Mgmt>

VMName VMNetworkAdapterName Mode     VlanList
------ -------------------- ----     --------
<snip> ...
       Mgmt                 Access   7
<snip> ...

# SDNExpress deployments use the newer PowerShell cmdlet <Verb>-VMNetworkAdapterIsolation to set VLAN isolation
PS C:\> Get-VMNetworkAdapterIsolation -ManagementOS

<snip> ...

IsolationMode        : Vlan
AllowUntaggedTraffic : False
DefaultIsolationID   : 7
MultiTenantStack     : Off
ParentAdapter        : VMInternalNetworkAdapter, Name = 'Mgmt'
IsTemplate           : True
CimSession           : CimSession: .
ComputerName         : SA18N30-2
IsDeleted            : False

<snip> ...

Проверьте поддержку MTU и джамбо фреймов в логической сети HNV-поставщика.

Еще одна распространенная проблема в логической сети поставщика HNV заключается в том, что физические сетевые порты и/или Ethernet-карта не настроены на достаточную величину MTU для обработки дополнительной нагрузки от инкапсуляции VXLAN (или NVGRE).

Замечание

Некоторые карты Ethernet и драйверы поддерживают новое *EncapOverhead ключевое слово, которое сетевой контроллер автоматически устанавливает на значение 160. Затем это значение будет добавлено к значению ключевого слова *JumboPacket, суммирование которого используется для определения объявленного MTU.

Например, *EncapOverhead = 160 и *JumboPacket = 1514 => MTU = 1674B

# Check whether or not your Ethernet card and driver support *EncapOverhead
PS C:\ > Test-EncapOverheadSettings

Verifying Physical Nic : <NIC> Ethernet Adapter #2
Physical Nic  <NIC> Ethernet Adapter #2 can support SDN traffic. Encapoverhead value set on the nic is  160
Verifying Physical Nic : <NIC> Ethernet Adapter
Physical Nic  <NIC> Ethernet Adapter can support SDN traffic. Encapoverhead value set on the nic is  160

Чтобы проверить, поддерживает ли логическая сеть поставщика HNV более крупный размер MTU по всей длине соединения, используйте командлет Test-LogicalNetworkSupportsJumboPacket.

# Get credentials for both source host and destination host (or use the same credential if in the same domain)
$sourcehostcred = Get-Credential
$desthostcred = Get-Credential

# Use the Management IP Address or FQDN of the Source and Destination Hyper-V hosts
Test-LogicalNetworkSupportsJumboPacket -SourceHost sa18n30-2 -DestinationHost sa18n30-3 -SourceHostCreds $sourcehostcred -DestinationHostCreds $desthostcred

# Failure Results
SourceCompartment : 3
pinging Source PA: 10.10.182.66 to Destination PA: 10.10.182.64 with Payload: 1632
pinging Source PA: 10.10.182.66 to Destination PA: 10.10.182.64 with Payload: 1472
Checking if physical nics support jumbo packets on host
Physical Nic  <NIC> Ethernet Adapter #2 can support SDN traffic. Encapoverhead value set on the nic is  160
Cannot send jumbo packets to the destination. Physical switch ports may not be configured to support jumbo packets.
Checking if physical nics support jumbo packets on host
Physical Nic  <NIC> Ethernet Adapter #2 can support SDN traffic. Encapoverhead value set on the nic is  160
Cannot send jumbo packets to the destination. Physical switch ports may not be configured to support jumbo packets.

Исправление

  • Настройте размер MTU на портах физического коммутатора как минимум до 1674B (включая 14B заголовок и конец Ethernet).
  • Если ваша NIC карта не поддерживает ключевое слово EncapOverhead, измените значение ключевого слова JumboPacket на как минимум 1674 байта.

Проверка подключения сетевого адаптера виртуальной машины клиента

Каждый сетевой адаптер виртуальной машины, назначенный гостевой ВМ, имеет сопоставление CA-PA между частным адресом клиента (ЦС) и адресным пространством поставщика HNV (PA). Эти сопоставления хранятся в таблицах серверов OVSDB на каждом узле Hyper-V и могут быть найдены, выполнив следующий командлет.

# Get all known PA-CA Mappings from this particular Hyper-V Host
PS > Get-PACAMapping

CA IP Address CA MAC Address    Virtual Subnet ID PA IP Address
------------- --------------    ----------------- -------------
10.254.254.2  00-1D-D8-B7-1C-43              4115 10.10.182.67
10.254.254.3  00-1D-D8-B7-1C-43              4115 10.10.182.67
192.168.1.5   00-1D-D8-B7-1C-07              4114 10.10.182.65
10.254.254.1  40-1D-D8-B7-1C-06              4115 10.10.182.66
192.168.1.1   40-1D-D8-B7-1C-06              4114 10.10.182.66
192.168.1.4   00-1D-D8-B7-1C-05              4114 10.10.182.66

Замечание

Если ожидаемые сопоставления CA-PA не отображаются для данной виртуальной машины клиента, проверьте ресурсы сетевой карты и IP-конфигурации виртуальной машины на сетевом контроллере с помощью командлета Get-NetworkControllerNetworkInterface . Кроме того, проверьте установленные подключения между хост-агентом NC и узлами сетевого контроллера.

С помощью этой информации хост-сервер может инициировать связь с виртуальной машиной клиента из сетевого контроллера с помощью командлета Test-VirtualNetworkConnection .

Конкретные сценарии устранения неполадок

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

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

  1. [клиент] Убедитесь, что брандмауэр Windows на виртуальных машинах клиента не блокирует трафик.
  2. [арендатор] Убедитесь, что IP-адреса принадлежат виртуальной машине арендатора, выполнив команду ipconfig.
  3. [Hoster] Запустите Test-VirtualNetworkConnection с узла Hyper-V, чтобы проверить подключение между двумя виртуальными машинами клиента.

Замечание

VSID ссылается на идентификатор виртуальной подсети. В случае VXLAN это сетевой идентификатор VXLAN (VNI). Это значение можно найти, выполнив Get-PACAMapping командлет.

Example

$password = ConvertTo-SecureString -String "password" -AsPlainText -Force
$cred = New-Object pscredential -ArgumentList (".\administrator", $password)

Создайте CA-пинг между "Green Web VM 1" с IP-адресом SenderCA 192.168.1.4 на хосте "sa18n30-2.sa18.nttest.microsoft.com" с IP-адресом управления 10.127.132.153 на IP-адрес ListenerCA 192.168.1.5, оба подключены к виртуальной подсети (VSID) 4114.

Test-VirtualNetworkConnection -OperationId 27 -HostName sa18n30-2.sa18.nttest.microsoft.com -MgmtIp 10.127.132.153 -Creds $cred -VMName "Green Web VM 1" -VMNetworkAdapterName "Green Web VM 1" -SenderCAIP 192.168.1.4 -SenderVSID 4114 -ListenerCAIP 192.168.1.5 -ListenerVSID 4114
Test-VirtualNetworkConnection at command pipeline position 1

Starting CA-space ping test
Starting trace session
Ping to 192.168.1.5 succeeded from address 192.168.1.4
Rtt = 0 ms

CA Routing Information:

    Local IP: 192.168.1.4
    Local VSID: 4114
    Remote IP: 192.168.1.5
    Remote VSID: 4114
    Distributed Router Local IP: 192.168.1.1
    Distributed Router Local MAC: 40-1D-D8-B7-1C-06
    Local CA MAC: 00-1D-D8-B7-1C-05
    Remote CA MAC: 00-1D-D8-B7-1C-07
    Next Hop CA MAC Address: 00-1D-D8-B7-1C-07

PA Routing Information:

    Local PA IP: 10.10.182.66
    Remote PA IP: 10.10.182.65

 <snip> ...

[клиент] Убедитесь, что в виртуальной подсети или сетевых интерфейсах виртуальной машины нет политик распределенного брандмауэра, которые блокируют трафик.

Отправьте запрос к REST API сетевого контроллера, расположенного в демонстрационной среде на sa18n30nc в домене sa18.nttest.microsoft.com.

$uri = "https://sa18n30nc.sa18.nttest.microsoft.com"
Get-NetworkControllerAccessControlList -ConnectionUri $uri

Просмотрите IP-конфигурацию и виртуальные подсети, ссылающиеся на этот ACL

  1. [Hoster] Запустите Get-ProviderAddress на обоих узлах Hyper-V, которые обслуживают две виртуальные машины арендатора. Затем, чтобы проверить подключение к логической сети поставщика HNV, запустите Test-LogicalNetworkConnection или ping -c <compartment> из узла Hyper-V.
  2. [Hoster] Убедитесь, что параметры MTU верны на узлах Hyper-V и всех коммутаторах уровня 2 между узлами Hyper-V. Запустите Test-EncapOverheadValue на всех рассматриваемых Hyper-V хостах. Кроме того, убедитесь, что у всех коммутаторов уровня 2 между ними MTU установлено значение не менее 1674 байт, чтобы учитывать максимальный накладной расход в 160 байт.
  3. [Hoster] Если IP-адреса PA отсутствуют или подключение к Удостоверяющему центру (ЦС) нарушено, убедитесь, что сетевая политика получена. Выполните команду Get-PACAMapping , чтобы узнать, правильно ли установлены правила инкапсуляции и CA-PA сопоставления, необходимые для создания наложенных виртуальных сетей.
  4. [Hoster] Убедитесь, что агент узла сетевого контроллера подключен к сетевому контроллеру. Для этого выполните команду netstat -anp tcp |findstr 6640.
  5. [Hoster] Убедитесь, что идентификатор узла в HKLM/ соответствует идентификатору экземпляра ресурсов сервера, на которых размещены виртуальные машины клиента.
  6. [Hoster] Убедитесь, что идентификатор профиля порта соответствует идентификатору экземпляра сетевых интерфейсов виртуальных машин клиента.

Ведение журнала, трассировка и расширенная диагностика

В следующих разделах содержатся сведения о расширенной диагностике, ведении журнала и трассировке.

Централизованное ведение журнала сетевого контроллера

Сетевой контроллер может автоматически собирать журналы отладчика и хранить их в централизованном расположении. Сбор журналов можно включить при первом развертывании сетевого контроллера или в любое время позже. Журналы собираются из сетевого контроллера и сетевых элементов, управляемых сетевым контроллером: хост-компьютеры, подсистемы балансировки нагрузки программного обеспечения (SLB) и компьютеры шлюза.

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

Включение ведения журнала

Ведение журнала автоматически включено при установке кластера сетевого контроллера с помощью командлета Install-NetworkControllerCluster . По умолчанию журналы собираются локально на узлах сетевого контроллера в %systemdrive%\SDNDiagnostics. Рекомендуется поменять местоположение на общий доступ к файлам по сети, а не локальный.

Журналы кластера сетевого контроллера хранятся в %programData%\Windows Fabric\log\Traces. Вы можете указать централизованное расположение для сбора журналов с помощью параметра DiagnosticLogLocation. Это расположение также должно быть удаленным файловый ресурс.

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

При использовании параметров по умолчанию рекомендуется иметь не менее 75 ГБ свободного места в центральном расположении и 25 ГБ на локальных узлах (если они не используют центральное расположение) для кластера сетевого контроллера с тремя узлами.

Изменение параметров ведения журнала

Параметры ведения журнала можно изменить в любое время с помощью командлета Set-NetworkControllerDiagnostic . Можно изменить следующие параметры:

  • Централизованное хранение логов.

    Вы можете изменить расположение для хранения всех журналов с параметром DiagnosticLogLocation .

  • Учетные данные для доступа к местоположению журнала.

    Вы можете изменить учетные данные для доступа к расположению журнала с помощью параметра LogLocationCredential.

  • Перейдите в локальное ведение журнала.

    Если вы предоставили централизованное расположение для хранения журналов, вы можете вернуться к ведению журнала локально на узлах сетевого контроллера с UseLocalLogLocation параметром (не рекомендуется из-за требований к большому объему дискового пространства).

  • Область ведения логирования.

    По умолчанию собираются все журналы. Область можно изменить, чтобы собирать только журналы кластера сетевого контроллера.

  • Уровень ведения журнала.

    Уровень ведения журнала по умолчанию — информационный. Его можно изменить на Error, Warning или Verbose.

  • Время устаревания журнала.

    Журналы хранятся в циклической форме. По умолчанию у вас есть три дня ведения журнала, независимо от того, используется ли локальное ведение журнала или централизованное ведение журнала. Это ограничение времени можно изменить с LogTimeLimitInDays помощью параметра.

  • Размер устаревания журнала.

    По умолчанию у вас есть не более 75 ГБ данных ведения журнала, если вы используете централизованное ведение журнала и 25 ГБ при использовании локального ведения журнала. Это ограничение можно изменить с LogSizeLimitInMBs помощью параметра.

Сбор журналов и трассировок

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

Если не указать расположение файла, каждый узел сетевого контроллера сохраняет журналы локально. Каждый узел сохраняет журналы в папке C:\Windows\tracing\SDNDiagnostics. Эти журналы сохраняются с помощью следующей иерархии:

  • CrashDumps
  • NCApplicationCrashDumps
  • NCApplicationLogs
  • PerfCounters
  • SDNDiagnostics
  • Следы

Сетевой контроллер использует Service Fabric (Azure). Журналы Service Fabric могут потребоваться при устранении определенных проблем. Эти журналы можно найти на каждом узле сетевого контроллера в C:\ProgramData\Microsoft\Service Fabric.

Если пользователь запустил командлет Debug-NetworkController, на каждом узле Hyper-V, который указан с серверным ресурсом в сетевом контроллере, будет доступно больше журналов. Эти журналы (и трассировки, если они включены) хранятся в C:\NCDiagnostics.

Диагностика SLB

Ошибки структуры SLBM (действия поставщика услуг размещения)

  1. Убедитесь, что диспетчер балансировки нагрузки программного обеспечения (SLBM) работает и что уровни оркестрации могут взаимодействовать друг с другом: SLBM -> SLB Mux и SLBM -> SLB Host Agents. Запустите DumpSlbRestState с любого узла с доступом к конечной точке REST контроллера сети.
  2. Проверьте SDNSLBMPerfCounters в PerfMon на одной из виртуальных машин узла сетевого контроллера (предпочтительно основной узел сетевого контроллера — Get-NetworkControllerReplica):
    1. Подключен ли движок Load Balancer (LB) к SLBM? (Конфигурации SLBM LBEngine, всего > 0)
    2. Знает ли SLBM хотя бы о своих конечных точках? (Итог конечных точек ВИРТУАЛЬНЫХ IP-адресов>= 2)
    3. Подключены ли узлы Hyper-V (DIP) к SLBM? (клиенты HP подключены == количество серверов)
    4. Подключен ли SLBM к Muxes? (Подключенные мультиплексоры == Исправность мультиплексоров на SLBM == Мультиплексоры, сообщающие о исправности = # ВМ SLB мультиплексоров).
  3. Убедитесь, что маршрутизатор BGP настроен и успешно установлено соединение с серверным балансировщиком нагрузки MUX.
    1. Если используется RRAS с удаленным доступом (то есть виртуальная машина BGP):
      1. Get-BgpPeer должно отображать состояние 'подключено'.
      2. Get-BgpRouteInformation должен показать по крайней мере маршрут для самостоятельного виртуального IP-адреса SLBM.
    2. При использовании физического коммутатора top-of-Rack (ToR) в качестве однорангового узла BGP обратитесь к документации:
      1. Например: # show bgp instance
  4. Проверьте счетчики SlbMuxPerfCounters и SLBMUX в PerfMon на виртуальной машине SLB Mux.
  5. Проверьте состояние конфигурации и диапазоны виртуальных IP-адресов в менеджере ресурсов Software Load Balancer.
    1. Get-NetworkControllerLoadBalancerConfiguration -ConnectionUri <https://\<FQDN or IP>| convertto-json -depth 8 (проверьте диапазоны VIP в пулах IP-адресов и убедитесь, что SLBM self-VIP (LoadBalanacerManagerIPAddress) и все ориентированные на арендаторов VIP находятся в пределах этих диапазонов)
      1. Get-NetworkControllerIpPool -NetworkId "<Public/Private VIP Logical Network Resource ID>" -SubnetId "<Public/Private VIP Logical Subnet Resource ID>" -ResourceId "\<IP Pool Resource Id>" -ConnectionUri $uri |convertto-json -depth 8
    2. Debug-NetworkControllerConfigurationState -

Если какая-либо из указанных выше проверок завершается ошибкой, состояние SLB клиента также будет находиться в режиме сбоя.

Исправление

На основе приведенных ниже диагностических сведений исправьте следующее:

  • Убедитесь, что мультиплексоры SLB подключены
    • Устранение проблем с сертификатом
    • Устранение проблем с сетевым подключением
  • Убедитесь, что информация о пиринге BGP успешно настроена
  • Убедитесь, что идентификатор узла в реестре соответствует идентификатору экземпляра сервера в ресурсе сервера (см. справочник по коду ошибки HostNotConnected).
  • Соберите журналы

Ошибки арендатора SLBM (действия поставщика услуг размещения и арендатора)

  1. [Hoster] Проверьте Debug-NetworkControllerConfigurationState , находятся ли ресурсы LoadBalancer в состоянии ошибки. Попробуйте устранить проблему, выполнив таблицу элементов действия в приложении.
    1. Убедитесь, что присутствует конечная точка виртуального IP-адреса и анонсирует маршруты.
    2. Проверьте, сколько конечных точек DIP обнаружено для конечной точки VIP.
  2. [Арендатор] Проверьте правильность указания ресурсов Load Balancer.
    1. Проверьте конечные точки DIP, зарегистрированные в SLBM, на которых размещены виртуальные машины клиента, которые соответствуют конфигурациям IP пула задних адресов LoadBalancer.
  3. [Hoster] Если конечные точки DIP не обнаружены или не подключены:

    1. Проверьте Debug-NetworkControllerConfigurationState

      Убедитесь, что агент узла NC и агент узла SLB успешно подключены к координатору событий сетевого контроллера с помощью netstat -anp tcp |findstr 6640).

    2. Убедитесь, что HostIdnchostagent в regkey службы соответствует идентификатору экземпляра ресурса сервера HostNotConnected, как указано в коде ошибки в приложении Get-NCServer |convertto-json -depth 8.

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

  4. [Поставщик размещения] Собирайте журналы.

Трассировка Mux SLB

Сведения из мультиплексоров программного балансировщика нагрузки также можно определить с помощью средства просмотра событий.

  1. Выберите "Показать журналы аналитики и отладки" в меню "Просмотр событий".
  2. Перейдите к Журналы приложений и служб>Microsoft>Windows>SlbMuxDriver>Трассировки в средстве просмотра событий.
  3. Щелкните его правой кнопкой мыши и выберите "Включить журнал".

Замечание

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

Трассировка VFP и vSwitch

Из любого узла Hyper-V, на котором размещена гостевая виртуальная машина, подключенная к виртуальной сети клиента, можно собрать трассировку VFP, чтобы определить, где могут лежать проблемы.

netsh trace start provider=Microsoft-Windows-Hyper-V-VfpExt overwrite=yes tracefile=vfp.etl report=disable provider=Microsoft-Windows-Hyper-V-VmSwitch
netsh trace stop
netsh trace convert .\vfp.etl ov=yes
  • Last updated on