- Windows network interface errors
- Диагностика стека программно-конфигурируемой сети Windows Server Troubleshoot the Windows Server Software Defined Networking Stack
- Типы ошибок Error types
- Диагностические средства Diagnostic tools
- Диагностика сетевого контроллера Network controller diagnostics
- Диагностика узлов Hyper-V Hyper-V host diagnostics
- GitHub GitHub
- Устранение неполадок рабочих процессов и руководств Troubleshooting Workflows and Guides
- Поставщика услуг размещения Проверка работоспособности системы [Hoster] Validate System Health
- Проверка сетевого подключения между сетевым контроллером и узлом Hyper-V (служба агента узла NC) Check network connectivity between the network controller and Hyper-V Host (NC Host Agent service)
- Проверка служб агента узла Check Host Agent services
- Проверка работоспособности сетевого контроллера Check health of network controller
- Проверьте наличие соответствующих Хостидс и сертификатов между сетевым контроллером и каждым узлом Hyper-V. Check for corresponding HostIDs and certificates between network controller and each Hyper-V Host
- Проверка состояния конфигурации SLB Check the SLB Configuration State
- Проверка шлюза Gateway Validation
- Поставщика услуг размещения Проверка Data-Plane [Hoster] Validate Data-Plane
- Проверка подключения к логической сети поставщика HNV Check HNV Provider Logical Network Connectivity
- Проверка поддержки кадров MTU и крупных размеров в логической сети поставщика HNV Check MTU and Jumbo Frame support on HNV Provider Logical Network
- Проверка подключения сетевого адаптера виртуальной машины клиента Check Tenant VM NIC connectivity
- Конкретные сценарии устранения неполадок Specific Troubleshooting Scenarios
- Отсутствует сетевое подключение между двумя виртуальными машинами клиента No network connectivity between two tenant virtual machines
- Пример Example
- Просмотреть IP-конфигурацию и виртуальные подсети, ссылающиеся на этот ACL Look at IP Configuration and Virtual Subnets which are referencing this ACL
- Ведение журналов, трассировка и Расширенная диагностика Logging, Tracing and advanced diagnostics
- Централизованное ведение журналов сетевого контроллера Network controller centralized logging
- Включение ведения журналов Enable logging
- Изменение параметров ведения журнала Change logging settings
- Сбор журналов и трассировок Collecting Logs and Traces
- Диагностика SLB SLB Diagnostics
- Ошибки фабрики SLBM (действия поставщика услуг размещения) SLBM Fabric errors (Hosting service provider actions)
- Ошибки клиента SLBM (действия поставщика услуг хостинга и клиента) SLBM Tenant errors (Hosting service provider and tenant actions)
- Трассировка мультиплексора SLB SLB Mux Tracing
- Трассировка VFP и vSwitch VFP and vSwitch Tracing
Windows network interface errors
Пожалуйста, сообщите об этом — просто выделите ошибочное слово или фразу и нажмите Shift Enter.
| Как посмотреть статистику ошибок на сетевых интерфейсах |
| Написал microsin | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 24.04.2008 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| На Linux это можно сделать командой ifconfig и netstat. На FreeBSD — командой netstat. Под Windows netstat -e (к сожалению, без указания конкретного интерфейса). Под IOS Cisco show interfaces имя_интерфейса. Примеры: Windows Red Hat Linux ]# ifconfig ]# netstat -i Диагностика стека программно-конфигурируемой сети Windows Server Troubleshoot the Windows Server Software Defined Networking Stack
В этом руководство рассматриваются распространенные ошибки и случаи сбоя программно-определяемой сети (SDN), а также описывается процесс устранения неполадок, использующий доступные средства диагностики. This guide examines the common Software Defined Networking (SDN) errors and failure scenarios and outlines a troubleshooting workflow that leverages the available diagnostic tools. Дополнительные сведения о программно определяемой сети Майкрософт см. в разделе программно определяемая сеть. For more information about Microsoft’s Software Defined Networking, see Software Defined Networking. Типы ошибок Error typesВ следующем списке представлен класс проблем, наиболее часто возникающих при использовании виртуализации сети Hyper-V (HNVv1) в Windows Server 2012 R2 из рабочих развертываний на рынке, и совпадают различные типы проблем, возникающих в Windows Server 2016 HNVv2 с новым стеком программно-определяемой сети (SDN). The following list represents the class of problems most often seen with Hyper-V Network Virtualization (HNVv1) in Windows Server 2012 R2 from in-market production deployments and coincides in many ways with the same types of problems seen in Windows Server 2016 HNVv2 with the new Software Defined Network (SDN) Stack. Большинство ошибок можно классифицировать в небольшой набор классов: Most errors can be classified into a small set of classes: Недопустимая или неподдерживаемая конфигурация Пользователь неправильно вызывает API обмена или имеет недопустимую политику. Invalid or unsupported configuration A user invokes the NorthBound API incorrectly or with invalid policy. Ошибка в приложении политики Политика сетевого контроллера не доставляется на узел Hyper-V, значительно отложена и (или) не обновлена на всех узлах Hyper-V (например, после динамическая миграция). Error in policy application Policy from Network Controller was not delivered to a Hyper-V Host, significantly delayed and / or not up to date on all Hyper-V hosts (for example, after a Live Migration). Отклонение конфигурации или ошибка программного обеспечения Проблемы с путями с данными, приводящие к потере пакетов. Configuration drift or software bug Data-path issues resulting in dropped packets. Внешняя ошибка, связанная с сетевым адаптером, драйверами или структурой сети ундерлай Неправильно настроенные разгрузки задач (например, VMQ) или ундерлай Network Fabric (например, MTU) External error related to NIC hardware / drivers or the underlay network fabric Misbehaving task offloads (such as VMQ) or underlay network fabric misconfigured (such as MTU) В этом руководство по устранению неполадок изучаются все эти категории ошибок и приводятся рекомендации и средства диагностики, доступные для выявления и исправления ошибок. This troubleshooting guide examines each of these error categories and recommends best practices and diagnostic tools available to identify and fix the error. Диагностические средства Diagnostic toolsПрежде чем обсуждать рабочие процессы устранения неполадок для каждого из этих типов ошибок, давайте рассмотрим доступные средства диагностики. Before discussing the troubleshooting workflows for each of these type of errors, let’s examine the diagnostic tools available. Чтобы использовать средства диагностики сетевого контроллера (Control-Path), необходимо сначала установить компонент RSAT-NetworkController и импортировать NetworkControllerDiagnostics модуль: To use the Network Controller (control-path) diagnostic tools, you must first install the RSAT-NetworkController feature and import the NetworkControllerDiagnostics module: Чтобы использовать средства диагностики диагностики HNV (Data-Path), необходимо импортировать HNVDiagnostics модуль: To use the HNV Diagnostics (data-path) diagnostic tools, you must import the HNVDiagnostics module: Диагностика сетевого контроллера Network controller diagnosticsЭти командлеты описаны на сайте TechNet в разделе Командлет диагностики сетевого контроллера. These cmdlets are documented on TechNet in the Network Controller Diagnostics Cmdlet Topic. Они помогают выявление проблем с согласованностью сетевых политик в узлах сетевого контроллера, а также между сетевым контроллером и агентами узла NC, запущенными на узлах Hyper-V. They help identify problems with network policy consistency in the control-path between Network Controller nodes and between the Network Controller and the NC Host Agents running on the Hyper-V hosts. Командлеты Debug-сервицефабрикнодестатус и Get-нетворкконтроллерреплика должны запускаться с одной из виртуальных машин узла сетевого контроллера. The Debug-ServiceFabricNodeStatus and Get-NetworkControllerReplica cmdlets must be run from one of the Network Controller node virtual machines. Все остальные командлеты диагностики NC можно запускать с любого узла, который имеет подключение к сетевому контроллеру и находится в группе безопасности управления сетевым контроллером (Kerberos) или имеет доступ к сертификату X. 509 для управления сетевым контроллером. All other NC Diagnostic cmdlets can be run from any host which has connectivity to the Network Controller and is in either in the Network Controller Management security group (Kerberos) or has access to the X.509 certificate for managing the Network Controller. Диагностика узлов Hyper-V Hyper-V host diagnosticsЭти командлеты описаны на сайте TechNet в разделе командлета диагностики виртуализации сети Hyper-V (HNV). These cmdlets are documented on TechNet in the Hyper-V Network Virtualization (HNV) Diagnostics Cmdlet Topic. Они помогают выявление проблем в пути передачи данных между виртуальными машинами клиента (Восток/Западная) и входящим трафиком через виртуальный IP-адрес SLB (Север/Юг). They help identify problems in the data-path between tenant virtual machines (East/West) and ingress traffic through an SLB VIP (North/South). Для всех локальных тестов, которые можно запускать с любого узла Hyper-V, поддерживаются Отладка-виртуалмачинекуеуеоператион, Get- кустомеррауте , Get- провидераддресс, Get- вмнетворкадаптерпортид, Get-VMSwitchExternalPortId и Test-EncapOverheadSettings . The Debug-VirtualMachineQueueOperation, Get-CustomerRoute, Get-PACAMapping, Get-ProviderAddress, Get-VMNetworkAdapterPortId, Get-VMSwitchExternalPortId, and Test-EncapOverheadSettings are all local tests which can be run from any Hyper-V host. Другие командлеты вызывают проверку пути к данным через сетевой контроллер, поэтому требуется доступ к сетевому контроллеру как дескриед выше. The other cmdlets invoke data-path tests through the Network Controller and therefore need access to the Network Controller as descried above. GitHub GitHubРепозиторий GitHub Microsoft/Sdn содержит ряд примеров сценариев и рабочих процессов, которые создаются на основе этих командлетов. The Microsoft/SDN GitHub Repo has a number of sample scripts and workflows which build on top of these in-box cmdlets. В частности, диагностические сценарии можно найти в папке Diagnostics . In particular, diagnostic scripts can be found in the Diagnostics folder. Помогите нам участвовать в этих сценариях, отправив запросы на вытягивание. Please help us contribute to these scripts by submitting Pull Requests. Устранение неполадок рабочих процессов и руководств Troubleshooting Workflows and GuidesПоставщика услуг размещения Проверка работоспособности системы [Hoster] Validate System HealthВ некоторых ресурсах сетевого контроллера имеется внедренный ресурс с именем Configuration State . There is an embedded resource named Configuration State in several of the Network Controller resources. Состояние конфигурации предоставляет сведения о работоспособности системы, включая согласованность конфигурации сетевого контроллера и фактическое (запущенное) состояние на узлах Hyper-V. Configuration state provides information about system health including the consistency between the network controller’s configuration and the actual (running) state on the Hyper-V hosts. Чтобы проверить состояние конфигурации, выполните следующую команду с любого узла Hyper-V с подключением к сетевому контроллеру. To check configuration state, run the following from any Hyper-V host with connectivity to the Network Controller. Значение параметра нетворкконтроллер должно быть либо полным доменным именем, либо IP-адресом, исходя из имени субъекта сертификата X. 509 >, созданного для сетевого контроллера. The value for the NetworkController parameter should either be the FQDN or IP address based on the subject name of the X.509 >certificate created for Network Controller. Параметр Credential необходимо указывать, только если сетевой контроллер использует проверку подлинности Kerberos (обычно в развертываниях VMM). The Credential parameter only needs to be specified if the network controller is using Kerberos authentication (typical in VMM deployments). Учетные данные должны быть заданы для пользователя, который находится в группе безопасности «Управление сетевым контроллером». The credential must be for a user who is in the Network Controller Management Security Group. Ниже приведен пример сообщения о состоянии конфигурации. A sample Configuration State message is shown below: В системе имеется ошибка, в которой ресурсы сетевого интерфейса для транзитного сетевого адаптера виртуальной машины мультиплексора SLB находятся в состоянии сбоя с ошибкой «виртуальный коммутатор — узел не подключен к контроллеру». There is a bug in the system where the Network Interface resources for the SLB Mux Transit VM NIC are in a Failure state with error «Virtual Switch — Host Not Connected To Controller». Эту ошибку можно спокойно проигнорировать, если в IP-конфигурации в ресурсе NIC виртуальной машины задан IP-адрес из пула IP-адресов транзитной логической сети. This error can be safely ignored if the IP configuration in the VM NIC resource is set to an IP Address from the Transit Logical Network’s IP Pool. В системе есть вторая ошибка, в которой ресурсы сетевого интерфейса для сетевых адаптеров виртуальных машин поставщика HNV шлюза находятся в состоянии сбоя с ошибкой «Virtual Switch-Портблоккед». There is a second bug in the system where the Network Interface resources for the Gateway HNV Provider VM NICs are in a Failure state with error «Virtual Switch — PortBlocked». Эту ошибку также можно спокойно проигнорировать, если IP-конфигурация в ресурсе NIC виртуальной машины имеет значение null (по шаблону). This error can also be safely ignored if the IP configuration in the VM NIC resource is set to null (by design). В таблице ниже приведен список кодов ошибок, сообщений и дальнейших действий, которые необходимо выполнить в зависимости от состояния конфигурации. The table below shows the list of error codes, messages, and follow-up actions to take based on the configuration state observed.
Проверка сетевого подключения между сетевым контроллером и узлом Hyper-V (служба агента узла NC) Check network connectivity between the network controller and Hyper-V Host (NC Host Agent service)Выполните следующую команду netstat , чтобы проверить наличие трех установленных подключений между агентом узла NC и узлами сетевого контроллера и одним СОКЕТом прослушивания на узле Hyper-V. Run the netstat command below to validate that there are three ESTABLISHED connections between the NC Host Agent and the Network Controller node(s) and one LISTENING socket on the Hyper-V Host
На узле Hyper-V может быть только два установленных подключения, если на этом узле не развернуты виртуальные машины клиента. There may only be two established connections on a Hyper-V host if there are no tenant virtual machines deployed on that particular host. Проверка служб агента узла Check Host Agent servicesСетевой контроллер взаимодействует с двумя службами агента узла на узлах Hyper-V: агент узла SLB и агент узла NC. The network controller communicates with two host agent services on the Hyper-V hosts: SLB Host Agent and NC Host Agent. Возможно, одна или обе службы не работают. It is possible that one or both of these services is not running. Проверьте их состояние и перезапустите, если они не запущены. Check their state and restart if they’re not running. Проверка работоспособности сетевого контроллера Check health of network controllerЕсли нет трех установленных подключений или сетевой контроллер не отвечает, убедитесь, что все узлы и модули службы работают и работают с помощью следующих командлетов. If there are not three ESTABLISHED connections or if the Network Controller appears unresponsive, check to see that all nodes and service modules are up and running by using the following cmdlets. Модули службы сетевого контроллера: The network controller service modules are:
Убедитесь, что состояние реплики готово для каждой службы. Check that the Replica Status is Ready for each service. Проверьте наличие соответствующих Хостидс и сертификатов между сетевым контроллером и каждым узлом Hyper-V. Check for corresponding HostIDs and certificates between network controller and each Hyper-V HostНа узле Hyper-V выполните следующие команды, чтобы проверить, соответствует ли HostID идентификатору экземпляра ресурса сервера на сетевом контроллере. On a Hyper-V Host, run the following commands to check that the HostID corresponds to the Instance Id of a server resource on the Network Controller Исправление При использовании скриптов Сднекспресс или ручного развертывания Обновите ключ HostId в реестре в соответствии с идентификатором экземпляра ресурса сервера. Remediation If using SDNExpress scripts or manual deployment, update the HostId key in the registry to match the Instance Id of the server resource. Перезапустите агент узла сетевого контроллера на узле Hyper-V (физический сервер), если используется VMM, удалите сервер Hyper-V из VMM и удалите раздел реестра HostId. Restart the Network Controller Host Agent on the Hyper-V host (physical server) If using VMM, delete the Hyper-V Server from VMM and remove the HostId registry key. Затем повторно добавьте сервер с помощью VMM. Then, re-add the server through VMM. Убедитесь, что отпечатки сертификатов X. 509, используемых узлом Hyper-V (имя узла будет совпадать с именем субъекта сертификата) для (Подсистемамми) связи между узлом Hyper-V (служба агента узла NC) и узлами сетевого контроллера, совпадают. Check that the thumbprints of the X.509 certificates used by the Hyper-V host (the hostname will be the cert’s Subject Name) for (SouthBound) communication between the Hyper-V Host (NC Host Agent service) and Network Controller nodes are the same. Также убедитесь, что в сертификате RESTFUL сетевого контроллера есть имя субъекта CN =. Also check that the Network Controller’s REST certificate has subject name of CN=. Кроме того, можно проверить следующие параметры каждого сертификата, чтобы убедиться, что имя субъекта является ожидаемым (имя узла или полное доменное имя или IP-адрес для остальных узлов), срок действия сертификата еще не истек и все центры сертификации в цепочке сертификатов включены в доверенный корневой центр сертификации. You can also check the following parameters of each cert to make sure the subject name is what is expected (hostname or NC REST FQDN or IP), the certificate has not yet expired, and that all certificate authorities in the certificate chain are included in the trusted root authority.
Исправление Если на узле Hyper-V несколько сертификатов имеют одно и то же имя субъекта, агент узла сетевого контроллера будет случайным образом выбрать один из них для сетевого контроллера. Remediation If multiple certificates have the same subject name on the Hyper-V host, the Network Controller Host Agent will randomly choose one to present to the Network Controller. Это может не соответствовать отпечатку ресурса сервера, известного сетевому контроллеру. This may not match the thumbprint of the server resource known to the Network Controller. В этом случае удалите один из сертификатов с тем же именем субъекта на узле Hyper-V, а затем повторно запустите службу агента узла сетевого контроллера. In this case, delete one of the certificates with the same subject name on the Hyper-V host and then re-start the Network Controller Host Agent service. Если подключение по-прежнему не удается выполнить, удалите другой сертификат с тем же именем субъекта на узле Hyper-V и удалите соответствующий ресурс сервера в VMM. If a connection can still not be made, delete the other certificate with the same subject name on the Hyper-V Host and delete the corresponding server resource in VMM. Затем повторно создайте ресурс сервера в VMM, который создаст новый сертификат X. 509 и установит его на узле Hyper-V. Then, re-create the server resource in VMM which will generate a new X.509 certificate and install it on the Hyper-V host. Проверка состояния конфигурации SLB Check the SLB Configuration StateСостояние конфигурации SLB можно определить как часть выходных данных для командлета Debug-NetworkController. The SLB Configuration State can be determined as part of the output to the Debug-NetworkController cmdlet. Этот командлет также выводит текущий набор ресурсов сетевого контроллера в JSON-файлах, все конфигурации IP из каждой политики узла Hyper-V (сервера) и локальной сети из таблиц базы данных агента узла. This cmdlet will also output the current set of Network Controller resources in JSON files, all IP configurations from each Hyper-V host (server) and local network policy from Host Agent database tables. По умолчанию будут собираться дополнительные трассировки. Additional traces will be collected by default. Чтобы не выполнять накопление трассировок, добавьте параметр-Инклудетрацес: $false. To not collect traces, add the -IncludeTraces:$false parameter. Расположением выходных данных по умолчанию будет каталог \Нкдиагностикс. The default output location will be the \NCDiagnostics\ directory. Выходной каталог по умолчанию можно изменить с помощью -OutputDirectory параметра. The default output directory can be changed by using the -OutputDirectory parameter. Сведения о состоянии конфигурации SLB можно найти в diagnostics-slbstateResults.Js файле в этом каталоге. The SLB Configuration State information can be found in the diagnostics-slbstateResults.Json file in this directory. Этот файл JSON можно разделить на следующие разделы: This JSON file can be broken down into the following sections:
Состояние SLB можно проверить непосредственно с помощью скрипта думпслбрестстате , доступного в репозитории GitHub Microsoft Sdn. SLB State can be ascertained directly by using the DumpSlbRestState script available on the Microsoft SDN GitHub repository. Проверка шлюза Gateway ValidationИз сетевого контроллера: From Network Controller: Из виртуальной машины шлюза: From Gateway VM: Переключение с верхней части стойки (ToR): From Top of Rack (ToR) Switch: sh ip bgp summary (for 3rd party BGP Routers) Маршрутизатор Windows BGP Windows BGP Router В дополнение к ним, от проблем, которые мы видели до сих пор (особенно при развертывании на основе Сднекспресс), наиболее распространенной причиной, по которой для секции клиента не настраивается на виртуальных машинах GW, является тот факт, что емкость GW в FabricConfig.psd1 меньше по сравнению с тем, что люди пытаются назначить сетевому подключению (туннели S2S) в TenantConfig.psd1. In addition to these, from the issues we have seen so far (especially on SDNExpress based deployments), the most common reason for Tenant Compartment not getting configured on GW VMs seem to be the fact that the GW Capacity in FabricConfig.psd1 is less compared to what folks try to assign to the Network Connections (S2S Tunnels) in TenantConfig.psd1. Это можно легко проверить, сравнив выходные данные следующих команд: This can be checked easily by comparing outputs of the following commands: Поставщика услуг размещения Проверка Data-Plane [Hoster] Validate Data-PlaneПосле развертывания сетевого контроллера были созданы виртуальные сети и подсети клиента, а виртуальные сети подключены к виртуальным подсетям. поставщик услуг размещения может выполнять дополнительные тесты на уровне структуры для проверки возможности подключения клиента. After the Network Controller has been deployed, tenant virtual networks and subnets have been created, and VMs have been attached to the virtual subnets, additional fabric level tests can be performed by the hoster to check tenant connectivity. Проверка подключения к логической сети поставщика HNV Check HNV Provider Logical Network ConnectivityПосле подключения первой гостевой виртуальной машины, запущенной на узле Hyper-V к виртуальной сети клиента, сетевой контроллер присвоит узлу Hyper-V два IP-адреса поставщика HNV (IP-адреса PA). After the first guest VM running on a Hyper-V host has been connected to a tenant virtual network, the Network Controller will assign two HNV Provider IP Addresses (PA IP Addresses) to the Hyper-V Host. Эти IP-адреса будут поступать из пула HNVов логической сети поставщика услуг и управляться сетевым контроллером. These IPs will come from the HNV Provider logical network’s IP Pool and be managed by the Network Controller. Чтобы узнать, что такое два IP-адреса HNV To find out what these two HNV IP Addresses are ‘s Эти IP-адреса поставщика HNV (PA) назначаются адаптерам Ethernet, созданным в отдельном сетевом сегменте TCPIP, и имеют имя адаптера вланкс , где X — это виртуальная ЛС, назначенная логической сети поставщика HNV (Transport). These HNV Provider IP Addresses (PA IPs) are assigned to Ethernet Adapters created in a separate TCPIP network compartment and have an adapter name of VLANX where X is the VLAN assigned to the HNV Provider (transport) logical network. Связь между двумя узлами Hyper-V, использующими логическую сеть поставщика HNV, может выполняться командой ping с дополнительным параметром секции (-c Y), где Y — это Секция сети TCPIP, в которой создаются Пахоствникс. Connectivity between two Hyper-V hosts using the HNV Provider logical network can be done by a ping with an additional compartment (-c Y) parameter where Y is the TCPIP network compartment in which the PAhostVNICs are created. Эту секцию можно определить, выполнив следующую команду: This compartment can be determined by executing: Адаптеры узла PA vNIC не используются в пути к данным и поэтому не имеют IP-адреса, назначенного адаптеру «адаптера vethernet (Пахоствник)». The PA Host vNIC Adapters are not used in the data-path and so do not have an IP assigned to the «vEthernet (PAhostVNic) adapter». Например, предположим, что узлы Hyper-V 1 и 2 имеют IP-адреса HNV Provider (PA): For instance, assume that Hyper-V hosts 1 and 2 have HNV Provider (PA) IP Addresses of:
Мы можем проверить связь между двумя с помощью следующей команды для проверки подключения к логической сети поставщика HNV. we can ping between the two using the following command to check HNV Provider logical network connectivity. Исправление Если проверка связи с поставщиком HNV не работает, проверьте подключение к физической сети, включая конфигурацию виртуальной ЛС. Remediation If HNV Provider ping does not work, check your physical network connectivity including VLAN configuration. Физические сетевые адаптеры на каждом узле Hyper-V должны находиться в режиме магистрали без определенной назначенной виртуальной ЛС. The physical NICs on each Hyper-V host should be in trunk mode with no specific VLAN assigned. Узел управления vNIC должен быть изолирован к виртуальной ЛС логической сети управления. The Management Host vNIC should be isolated to the Management Logical Network’s VLAN. Проверка поддержки кадров MTU и крупных размеров в логической сети поставщика HNV Check MTU and Jumbo Frame support on HNV Provider Logical NetworkЕще одна распространенная проблема в логической сети поставщика HNV заключается в том, что физические сетевые порты и/или плата Ethernet не имеют достаточного размера MTU, настроенного для снижения нагрузки на ВКСЛАН (или NVGRE). Another common problem in the HNV Provider logical network is that the physical network ports and/or Ethernet card do not have a large enough MTU configured to handle the overhead from VXLAN (or NVGRE) encapsulation. Некоторые карты и драйверы Ethernet поддерживают новое ключевое слово * Енкаповерхеад, которое автоматически устанавливается агентом узла сетевого контроллера в значение 160. Some Ethernet cards and drivers support the new *EncapOverhead keyword which will automatically be set by the Network Controller Host Agent to a value of 160. Затем это значение будет добавлено к значению ключевого слова * Жумбопаккет, сумма которого используется в качестве объявленного MTU. This value will then be added to the value of the *JumboPacket keyword whose summation is used as the advertised MTU. Например, * Енкаповерхеад = 160 и * Жумбопаккет = 1514 => MTU = 1674B e.g. *EncapOverhead = 160 and *JumboPacket = 1514 => MTU = 1674B Чтобы проверить, поддерживает ли логическая сеть поставщика HNV более полный размер MTU, используйте командлет Test-логикалнетворксуппортсжумбопаккет : To test whether or not the HNV Provider logical network supports the larger MTU size end-to-end, use the Test-LogicalNetworkSupportsJumboPacket cmdlet:
Проверка подключения сетевого адаптера виртуальной машины клиента Check Tenant VM NIC connectivityКаждая сетевая карта виртуальных машин, назначенная гостевой виртуальной машине, имеет сопоставление CA-PA между частным адресом клиента (CA) и пространством поставщика HNV (PA). Each VM NIC assigned to a guest VM has a CA-PA mapping between the private Customer Address (CA) and the HNV Provider Address (PA) space. Эти сопоставления хранятся в таблицах сервера ОВСДБ на каждом узле Hyper-V, и их можно найти, выполнив следующий командлет. These mappings are kept in the OVSDB server tables on each Hyper-V host and can be found by executing the following cmdlet. Если для указанной виртуальной машины клиента не выводятся сопоставления CA-PA, проверьте ресурсы сетевого адаптера виртуальной машины и конфигурации IP-адресов на сетевом контроллере с помощью командлета Get-нетворкконтроллернетворкинтерфаце . If the CA-PA mappings you expect are not output for a given tenant VM, please check the VM NIC and IP Configuration resources on the Network Controller using the Get-NetworkControllerNetworkInterface cmdlet. Кроме того, проверьте наличие установленных соединений между агентом узла NC и узлами сетевого контроллера. Also, check the established connections between the NC Host Agent and Network Controller nodes. Используя эти сведения, поставщик услуг размещения может инициировать проверку связи для виртуальной машины клиента с помощью командлета Test-виртуалнетворкконнектион . With this information, a tenant VM ping can now be initiated by the Hoster from the Network Controller using the Test-VirtualNetworkConnection cmdlet. Конкретные сценарии устранения неполадок Specific Troubleshooting ScenariosВ следующих разделах приводятся рекомендации по устранению неполадок в конкретных сценариях. The following sections provide guidance for troubleshooting specific scenarios. Отсутствует сетевое подключение между двумя виртуальными машинами клиента No network connectivity between two tenant virtual machines
VSID ссылается на идентификатор виртуальной подсети. The VSID refers to the Virtual Subnet ID. В случае с ВКСЛАН это идентификатор ВКСЛАН Network (вни). In the case of VXLAN, this is the VXLAN Network Identifier (VNI). Это значение можно найти, выполнив командлет Get-пакамаппинг . You can find this value by running the Get-PACAMapping cmdlet. Пример ExampleСоздайте CA-ping между «зеленой веб-виртуальной машиной 1» и Сендерка IP-адресом 192.168.1.4 на узле «sa18n30-2.sa18.nttest.microsoft.com» с IP-адресом 10.127.132.153 на Листенерка IP-адрес 192.168.1.5, подключенных к виртуальной подсети (VSID) 4114. Create CA-ping between «Green Web VM 1» with SenderCA IP of 192.168.1.4 on Host «sa18n30-2.sa18.nttest.microsoft.com» with Mgmt IP of 10.127.132.153 to ListenerCA IP of 192.168.1.5 both attached to Virtual Subnet (VSID) 4114.
Запросите REST API сетевого контроллера, который находится в демонстрационной среде по адресу sa18n30nc в домене sa18.nttest.microsoft.com. Query the Network Controller REST API found in demo environment at sa18n30nc in the sa18.nttest.microsoft.com domain. Просмотреть IP-конфигурацию и виртуальные подсети, ссылающиеся на этот ACL Look at IP Configuration and Virtual Subnets which are referencing this ACL
Ведение журналов, трассировка и Расширенная диагностика Logging, Tracing and advanced diagnosticsВ следующих разделах приведены сведения о расширенной диагностике, ведении журнала и трассировке. The following sections provide information on advanced diagnostics, logging, and tracing. Централизованное ведение журналов сетевого контроллера Network controller centralized loggingСетевой контроллер может автоматически получать журналы отладчика и хранить их в централизованном расположении. The Network Controller can automatically collect debugger logs and store them in a centralized location. Сбор журналов можно включить при первом развертывании сетевого контроллера или в любое другое время. Log collection can be enabled when you deploy the Network Controller for the first time or any time later. Журналы собираются из сетевого контроллера, а сетевые элементы управляются сетевым контроллером: компьютерами размещения, подсистемами балансировки нагрузки программного обеспечения (SLB) и шлюзами. The logs are collected from the Network Controller, and network elements managed by Network Controller: host machines, software load balancers (SLB) and gateway machines. Эти журналы содержат журналы отладки для кластера сетевого контроллера, приложения сетевого контроллера, журналов шлюзов, SLB, виртуальных сетей и распределенного брандмауэра. These logs include debug logs for the Network Controller cluster, the Network Controller application, gateway logs, SLB, virtual networking and the distributed firewall. При добавлении нового узла, SLB или шлюза в сетевой контроллер на этих компьютерах запускается ведение журнала. Whenever a new host/SLB/gateway is added to the Network Controller, logging is started on those machines. Аналогично, при удалении узла, SLB или шлюза из сетевого контроллера, ведение журнала на этих компьютерах останавливается. Similarly, when a host/SLB/gateway is removed from the Network Controller, logging is stopped on those machines. Включение ведения журналов Enable loggingВедение журнала включается автоматически при установке кластера сетевого контроллера с помощью командлета Install-нетворкконтроллерклустер . Logging is automatically enabled when you install the Network Controller cluster using the Install-NetworkControllerCluster cmdlet. По умолчанию журналы собираются локально на узлах сетевого контроллера по адресу %системдриве%\сдндиагностикс. By default, the logs are collected locally on the Network Controller nodes at %systemdrive%\SDNDiagnostics. Настоятельно рекомендуется изменить это расположение на удаленную общую папку (не локальную). It is STRONGLY RECOMMENDED that you change this location to be a remote file share (not local). Журналы кластера сетевого контроллера хранятся на сайте %Програмдата%\виндовс фабрик\лог\трацес. The Network Controller cluster logs are stored at %programData%\Windows Fabric\log\Traces. Можно указать централизованное расположение для сбора журналов с помощью параметра диагностиклоглокатион с рекомендацией, что это также удаленная общая папка. You can specify a centralized location for log collection with the DiagnosticLogLocation parameter with the recommendation that this is also be a remote file share. Если вы хотите ограничить доступ к этому расположению, можно указать учетные данные доступа с помощью параметра логлокатионкредентиал . If you want to restrict access to this location, you can provide the access credentials with the LogLocationCredential parameter. При предоставлении учетных данных для доступа к расположению журнала необходимо также указать параметр кредентиаленкриптионцертификате , который используется для шифрования учетных данных, хранимых локально на узлах сетевого контроллера. If you provide the credentials to access the log location, you should also provide the CredentialEncryptionCertificate parameter, which is used to encrypt the credentials stored locally on the Network Controller nodes. При использовании параметров по умолчанию рекомендуется иметь не менее 75 ГБ свободного места в центральном расположении и 25 ГБ на локальных узлах (если не используется центральное расположение) для кластера сетевого контроллера с тремя узлами. With the default settings, it is recommended that you have at least 75 GB of free space in the central location, and 25 GB on the local nodes (if not using a central location) for a 3-node Network Controller cluster. Изменение параметров ведения журнала Change logging settingsПараметры ведения журнала можно изменить в любое время с помощью Set-NetworkControllerDiagnostic командлета. You can change logging settings at any time using the Set-NetworkControllerDiagnostic cmdlet. Можно изменить следующие параметры: The following settings can be changed:
Сбор журналов и трассировок Collecting Logs and TracesПо умолчанию развертывания VMM используют централизованное ведение журналов для сетевого контроллера. VMM deployments use centralized logging for the Network Controller by default. Расположение общих файловых ресурсов для этих журналов указывается при развертывании шаблона службы сетевого контроллера. The file share location for these logs is specified when deploying the Network Controller service template. Если расположение файла не указано, на каждом узле сетевого контроллера будет использоваться локальное ведение журнала с журналами, сохраненными в К:\виндовс\траЦинг\сдндиагностикс. If a file location has not been specified, local logging will be used on each Network Controller node with logs saved under C:\Windows\tracing\SDNDiagnostics. Эти журналы сохраняются с помощью следующей иерархии: These logs are saved using the following hierarchy:
Сетевой контроллер использует Service Fabric (Azure). The Network Controller uses (Azure) Service Fabric. При устранении определенных проблем могут потребоваться Service Fabric журналы. Service Fabric logs may be required when troubleshooting certain issues. Эти журналы можно найти на каждом узле сетевого контроллера в К:\програмдата\микрософт\сервице Fabric. These logs can be found on each Network Controller node at C:\ProgramData\Microsoft\Service Fabric. Если пользователь выполнил командлет Debug-нетворкконтроллер , дополнительные журналы будут доступны на каждом узле Hyper-V, который был указан с помощью ресурса сервера в сетевом контроллере. If a user has run the Debug-NetworkController cmdlet, additional logs will be available on each Hyper-V host which has been specified with a server resource in the Network Controller. Эти журналы (и трассировки, если они включены) хранятся в разделе К:\нкдиагностикс These logs (and traces if enabled) are kept under C:\NCDiagnostics Диагностика SLB SLB DiagnosticsОшибки фабрики SLBM (действия поставщика услуг размещения) SLBM Fabric errors (Hosting service provider actions)
Если какая-либо из перечисленных выше проверок завершается ошибкой, состояние SLB клиента также будет в режиме сбоя. If any of the checks above fail, the tenant SLB state will also be in a failure mode. Исправление На основе приведенных ниже диагностических сведений исправьте следующее. Remediation Based on the following diagnostic information presented, fix the following:
Ошибки клиента SLBM (действия поставщика услуг хостинга и клиента) SLBM Tenant errors (Hosting service provider and tenant actions)
Трассировка мультиплексора SLB SLB Mux TracingСведения из программного Load Balancer мультиплексоров также можно определить с помощью Просмотр событий. Information from the Software Load Balancer Muxes can also be determined through Event Viewer.
Рекомендуется включить это ведение журнала в течение короткого периода времени, пока вы пытаетесь воспроизвести проблему. It is recommended that you only have this logging enabled for a short time while you are trying to reproduce a problem Трассировка VFP и vSwitch VFP and vSwitch TracingНа любом узле Hyper-V, на котором размещена гостевая виртуальная машина, подключенная к виртуальной сети клиента, можно собрать трассировку VFP, чтобы определить, где могут находиться проблемы. From any Hyper-V host which is hosting a guest VM attached to a tenant virtual network, you can collected a VFP trace to determine where problems might lie. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
