Windows Server 소프트웨어 정의 네트워킹 스택 문제 해결

아티클
08/22/2024

이 가이드에서는 일반적인 SDN(소프트웨어 정의 네트워킹) 오류 및 오류 시나리오를 살펴보고 사용 가능한 진단 도구를 사용하는 문제 해결 워크플로를 간략하게 설명합니다. SDN에 대한 자세한 내용은 소프트웨어 정의 네트워킹을 참조 하세요.

적용 대상: Windows Server 2022, Windows Server 2019, Windows Server 2016, Azure Stack HCI, 버전 21H2 및 20H2

오류 형식

다음 목록에는 시장에서 프로덕션 배포에서 Windows Server 2012 r 2에서의 Hyper-v 네트워크 가상화 (HNVv1) 흔히 볼 문제 클래스를 나타냅니다와 일치 하는 여러 가지 방법으로는 동일한 유형의 새 네트워크 SDN (소프트웨어) 스택과 Windows Server 2016 HNVv2에서 동안 문제가 발생 합니다.

대부분의 오류는 다음과 같은 클래스의 작은 집합으로 분류할 수 있습니다.

잘못 되었거나 지원 되지 않는 구성

잘못 되거나 잘못 된 정책 NorthBound API를 호출 하는 사용자.
정책 적용 하는 동안 오류가 발생 했습니다.

네트워크 컨트롤러의 정책이 Hyper-V 호스트에 배달되지 않았거나, 지연되었거나, 모든 Hyper-V 호스트에서 최신이 아닙니다(예: 실시간 마이그레이션 후).
구성 드리프트 또는 소프트웨어 버그

삭제 된 패킷의 결과 데이터 경로 문제가 있습니다.
외부 오류 NIC 하드웨어와 관련 된 / 드라이버 또는 언더레이 패브릭 네트워크

오동작 작업 오프 로드 (예: VMQ) 또는 언더레이 네트워크 패브릭 MTU) (예: 잘못 구성 되었습니다.

이 문제 해결 가이드는 이러한 각 오류 범주를 검사 하 고 모범 사례 및 확인 하 고 오류를 해결 하려면 사용할 수 있는 진단 도구를 권장 합니다.

진단 도구

이러한 각 유형의 오류에 대한 문제 해결 워크플로를 논의하기 전에 사용 가능한 진단 도구를 살펴보겠습니다.

네트워크 컨트롤러(제어 경로) 진단 도구를 사용하려면 먼저 기능을 설치 RSAT-NetworkController 하고 모듈을 NetworkControllerDiagnostics 가져와야 합니다.

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

HNV 진단 (데이터 경로) 진단 도구를 사용 하려면 가져와야는 HNVDiagnostics 모듈:

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

네트워크 컨트롤러 진단

이러한 cmdlet은 네트워크 컨트롤러 진단 cmdlet의 TechNet에 설명되어 있습니다. 네트워크 정책 일관성은 제어 경로 및 네트워크 컨트롤러와 Hyper-v 호스트에서 실행 되는 NC 호스트 에이전트 네트워크 컨트롤러 노드 사이 문제를 식별 도움이 있습니다.

Debug-ServiceFabricNodeStatus 네트워크 컨트롤러 노드 가상 머신 중 하나에서 cmdlet 및 Get-NetworkControllerReplica cmdlet을 실행해야 합니다. 다른 모든 NC 진단 cmdlet은 네트워크 컨트롤러에 연결되어 있고 Kerberos(네트워크 컨트롤러 관리 보안 그룹)에 있거나 네트워크 컨트롤러를 관리하기 위한 X.509 인증서에 액세스할 수 있는 모든 호스트에서 실행할 수 있습니다.

Hyper-v 호스트에 대 한 진단 유틸리티

이러한 cmdlet은 HNV(Hyper-V 네트워크 가상화) 진단 cmdlet의 TechNet에 설명되어 있습니다. 테 넌 트 가상 컴퓨터 (동/서) 간의 데이터 경로에 문제를 식별 하는 데 도움이 및는 SLB VIP (남/북)를 통해 수신 트래픽을 합니다.

Hyper-V Debug-VirtualMachineQueueOperationGet-ProviderAddressTest-EncapOverheadSettings Get-CustomerRouteGet-PACAMappingGet-VMNetworkAdapterPortIdGet-VMSwitchExternalPortId호스트에서 실행할 수 있는 모든 로컬 테스트입니다. 다른 cmdlet은 네트워크 컨트롤러를 통해 데이터 경로 테스트를 호출하므로 위에서 설명한 대로 네트워크 컨트롤러에 액세스해야 합니다.

GitHub

Microsoft/SDN GitHub 리포지토리에는 이러한 기본 제공 cmdlet을 기반으로 빌드되는 많은 샘플 스크립트 및 워크플로가 있습니다. 특히, 진단 스크립트에 있습니다는 진단 폴더입니다. 끌어오기 요청을 제출하여 이러한 스크립트에 기여하도록 도와주세요.

워크플로 및 가이드 문제 해결

[호스터] 시스템 상태 유효성 검사

라는 포함된 된 리소스는 구성 상태 네트워크 컨트롤러 리소스 중 몇 개에 있습니다. 구성 상태는 네트워크 컨트롤러의 구성 및 Hyper-v 호스트에 실제 (실행) 상태 간에 일관성을 포함 하 여 시스템 상태에 대 한 정보를 제공 합니다.

구성 상태를 확인 하려면에서 다음을 실행 모든 Hyper-v 호스트에 연결 된 네트워크 컨트롤러에 있습니다.

참고 항목

매개 변수 값 NetworkController 은 네트워크 컨트롤러용으로 만든 X.509 >인증서의 주체 이름을 기반으로 하는 FQDN 또는 IP 주소여야 합니다.

네트워크 컨트롤러가 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.
----------------------------------------------------------------------------------------------------------

참고 항목

SLB Mux 전송 중 VM NIC에 대 한 네트워크 인터페이스 리소스가 "가상 스위치-호스트 연결에 컨트롤러가 아닌" 오류와 함께 실패 상태에 있는 시스템에 버그가 있습니다. VM NIC 리소스의 IP 구성이 전송 논리 네트워크의 IP 풀에서 IP 주소로 설정 된 경우이 오류 수 안전 하 게 무시 됩니다.

게이트웨이 HNV 공급자 VM Nic에 대 한 네트워크 인터페이스 리소스가 "가상 스위치-PortBlocked" 오류와 함께 실패 상태에 있는 시스템에서 두 번째 버그가 있습니다. 이 오류도 안전 하 게 무시할 수 VM NIC 리소스의 IP 구성이 설정 된 경우 null로 (디자인).

아래 표에서 오류 코드, 메시지 및 관찰 된 구성 상태에 따라 수행할 작업이의 목록입니다.

코드	메시지	작업
Unknown	알 수 없는 오류
HostUnreachable	호스트 컴퓨터에 연결할 수 없다는	네트워크 컨트롤러와 호스트 간의 네트워크 연결을 관리 확인
PAIpAddressExhausted	PA IP 주소가 소진됨	HNV 공급자 논리 서브넷의 IP 풀 크기 늘리기
PAMacAddressExhausted	PA Mac 주소를 모두 사용된 했습니다.	Mac 풀 범위를 넓힐
PAAddressConfigurationFailure	호스트에 대 한 PA 주소 전문가가 연결 하지 못했습니다.	네트워크 컨트롤러와 호스트 간의 관리 네트워크 연결을 확인 합니다.
CertificateNotTrusted	인증서를 신뢰할 수 없는 경우	호스트와의 통신에 사용 되는 인증서를 수정 합니다.
CertificateNotAuthorized	권한이 없는 인증서	호스트와의 통신에 사용 되는 인증서를 수정 합니다.
PolicyConfigurationFailureOnVfp	VFP 정책 구성에 실패	런타임 오류입니다. 명확한 해결 방법이 없습니다. 로그를 수집 합니다.
PolicyConfigurationFailure	통신 오류 또는 다른 사용자로 인해 호스트에 정책을 푸시하여의 오류는 NetworkController에 오류가 있습니다.	전체 작업이 없습니다. 이 목표 상태 네트워크 컨트롤러 모듈에서 처리 하는 동안 오류가 발생 합니다. 로그를 수집 합니다.
HostNotConnectedToController	호스트는 네트워크 컨트롤러에 아직 연결 되지 않은	포트 프로필의 호스트 또는 호스트에 적용 되지 않았습니다 네트워크 컨트롤러에서 연결 되지 않습니다. HostID 레지스트리 키에는 서버 리소스의 인스턴스 ID와 일치 하는지 확인 합니다.
MultipleVfpEnabledSwitches	여러 VFp 호스트에서 스위치를 사용 하도록 설정	네트워크 컨트롤러 호스트 에이전트만는 지원 하므로 하나의 vSwitch VFP 확장을 사용 하는 사용 되는 스위치 중 하나를 삭제합니다
PolicyConfigurationFailure	인증서 오류 또는 연결 오류로 인해 VmNic VNet 정책을 푸시 하지 못했습니다.	적절 한 인증서가 배포 되었는지 확인 하십시오 (호스트의 FQDN 인증서 주체 이름은 일치 해야 합니다). 또한 네트워크 컨트롤러를 호스트 연결 확인
PolicyConfigurationFailure	인증서 오류 또는 연결 오류로 인해 VmNic vSwitch 정책을 푸시 하지 못했습니다.	적절 한 인증서가 배포 되었는지 확인 하십시오 (호스트의 FQDN 인증서 주체 이름은 일치 해야 합니다). 또한 네트워크 컨트롤러를 호스트 연결 확인
PolicyConfigurationFailure	인증서 오류 또는 연결 오류로 인해 VmNic에 대 한 방화벽 정책을 푸시 하지 못했습니다.	적절 한 인증서가 배포 되었는지 확인 하십시오 (호스트의 FQDN 인증서 주체 이름은 일치 해야 합니다). 또한 네트워크 컨트롤러를 호스트 연결 확인
DistributedRouterConfigurationFailure	호스트 vNic에 분산 라우터 설정을 구성 하지 못했습니다.	TCPIP 스택 오류가 발생 했습니다. 이 오류를 보고 서버에서 PA 및 DR 호스트 vNICs를 정리 해야 할 수 있습니다.
DhcpAddressAllocationFailure	VMNic에 대 한 DHCP 주소를 할당 하지 못했습니다.	NIC 리소스에 대해 정적 IP 주소 특성은 구성 확인
CertificateNotTrusted CertificateNotAuthorized	네트워크 또는 인증 오류로 인해 Mux에 연결 하지 못했습니다.	오류 메시지 코드에 제공 된 숫자 코드를 확인 하십시오: winsock 오류 코드에 해당 합니다. 인증서 오류 세분화 됩니다 (예를 들어 인증서를 확인할 수 없으면 cert 권한이 없는 등이 있습니다.)
HostUnreachable	MUX은 비정상 (일반적인 경우 BGPRouter 연결 끊김)	RRAS (BGP 가상 머신) 또는 위쪽-Tor () 스위치에 대한 BGP 피어를 성공적으로 액세스할 수 없거나 하지 피어 링입니다. 소프트웨어 부하 분산 장치 멀티플렉서 리소스와 BGP 피어 (ToR 또는 RRAS 가상 머신)에서 BGP 설정을 확인합니다.
HostNotConnectedToController	SLB 호스트 에이전트에 연결 되어 있지 않습니다.	SLB 호스트 에이전트 서비스가 실행 중인지 확인 같은 이유로 SLB 호스트 에이전트 로그 (자동 실행)를 참조 이유, SLBM (NC) 실행 되는 호스트 에이전트를 제공한 인증서를 거부 하는 경우 상태 정보가 표시 됩니다 미묘한
PortBlocked	VNET의 부족으로 인해 VFP 포트는 차단 됩니다 / ACL 정책	다른 오류를 정책을 구성 하지 않을 수를 확인 합니다.
오버로드됨	Loadbalancer MUX 오버 로드	MUX 성능 문제
RoutePublicationFailure	Loadbalancer MUX BGP 라우터에 연결 되지 않은	가 MUX에 BGP 라우터 연결, 그리고 해당 BGP 피어 링가 제대로 설치 확인
VirtualServerUnreachable	Loadbalancer MUX SLB 관리자에 연결 되지 않은	SLBM 및 MUX 간 연결 확인
QosConfigurationFailure	QOS 정책을 구성 하지 못했습니다.	QOS 예약을 사용 하는 경우 모든 VM에 대해 사용 가능한 충분 한 대역폭이 있는지

네트워크 컨트롤러와 Hyper-v 호스트 (NC 호스트 에이전트 서비스) 간의 네트워크 연결 확인

netstat 아래 명령을 실행하여 NC 호스트 에이전트와 네트워크 컨트롤러 노드 사이에 세 ESTABLISHED 개의 연결이 있고 Hyper-V 호스트에 하나의 LISTENING 소켓이 있는지 확인합니다.

Hyper-v 호스트 (NC 호스트 에이전트 서비스)에서 포트 TCP:6640에서 수신 대기
포트 6640의 Hyper-V 호스트 IP에서 임시 포트의 NC 노드 IP로 설정된 두 연결(> 32000)
네트워크 컨트롤러 REST ip 포트 6640에서 임시 포트에 Hyper-v 호스트 IP에서 설정 된 하나의 연결

참고 항목

있을 수 있습니다만 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 개의 연결이 없거나 네트워크 컨트롤러가 응답하지 않는 것으로 표시되는 경우 다음 cmdlet을 사용하여 모든 노드 및 서비스 모듈이 실행 중인지 확인합니다.

# 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
FirewallService
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 호스트 간에 해당 HostID 및 인증서 확인

Hyper-V 호스트에서 다음 cmdlet을 실행하여 HostID가 네트워크 컨트롤러에 있는 서버 리소스의 인스턴스 ID에 해당하는지 확인합니다.

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/4c4c4544-0056-4a10-8059-b8c04f395931
InstanceId       : **162cd2c8-08d4-4298-8cb4-10c2977e3cfe**
Etag             : W/"50f89b08-215c-495d-8505-0776baab9cb3"
ResourceMetadata : Microsoft.Windows.NetworkController.ResourceMetadata
ResourceId       : 4c4c4544-0056-4a10-8059-b8c04f395931
Properties       : Microsoft.Windows.NetworkController.ServerProperties

수정

SDNExpress 스크립트 또는 수동 배포를 사용하는 경우 서버 리소스의 인스턴스 ID와 일치하도록 레지스트리의 HostId 키를 업데이트합니다. VMM을 사용 하 여 VMM에서 Hyper-v 서버를 삭제 하는 경우에 Hyper-v 호스트 (실제 서버)의 네트워크 컨트롤러 호스트 에이전트를 다시 시작 하 고 HostId 레지스트리 키를 제거 합니다. 그런 다음, VMM을 통해 서버를 다시 추가합니다.

(호스트 이름이 인증서의 주체 이름 수는) Hyper-v 호스트에서 Hyper-v 호스트 (NC 호스트 에이전트 서비스)와 네트워크 컨트롤러 노드 간의 (SouthBound) 통신에 사용 되는 X.509 인증서의 지문이 동일한 지 확인 합니다. 또한 네트워크 컨트롤러의 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 FQDN 또는 IP), 인증서가 아직 만료되지 않았는지, 인증서 체인의 모든 인증 기관이 신뢰할 수 있는 루트 기관에 포함되어 있는지 확인할 수 있습니다.

주체 이름
만료 날짜
루트 기관에서 신뢰할 수 있는

여러 인증서가 Hyper-V 호스트에서 동일한 주체 이름을 갖는 경우 네트워크 컨트롤러 호스트 에이전트는 네트워크 컨트롤러에 표시할 인증서를 임의로 선택합니다. 네트워크 컨트롤러에 알려진 서버 리소스의 지문과 일치하지 않을 수 있습니다. 이 경우 Hyper-V 호스트에서 동일한 주체 이름을 가진 인증서 중 하나를 삭제한 다음 네트워크 컨트롤러 호스트 에이전트 서비스를 다시 시작합니다. 여전히 연결할 수 없는 경우 Hyper-V 호스트에서 동일한 주체 이름을 가진 다른 인증서를 삭제하고 VMM에서 해당 서버 리소스를 삭제합니다. 그런 다음 새 X.509 인증서를 생성하고 Hyper-V 호스트에 설치하는 VMM에서 서버 리소스를 다시 만듭니다.

SLB 구성 상태 확인

SLB 구성 상태는 cmdlet에 대한 출력 Debug-NetworkController 의 일부로 확인할 수 있습니다. 이 cmdlet은 JSON 파일, 각 Hyper-v 호스트 (서버)에서 모든 IP 구성을 호스트 에이전트 데이터베이스 테이블에서 로컬 네트워크 정책에서 네트워크 컨트롤러 리소스의 현재 집합을 출력도.

기본적으로 더 많은 추적이 수집됩니다. 추적을 수집하지 않려면 매개 변수를 추가합니다 -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 구성 상태 정보를 찾을 수는 진단 slbstateResults.Json 이 디렉터리의 파일입니다.

다음 섹션으로이 JSON 파일을 구분할 수 있습니다.

직물
- SlbmVips - 이 섹션에는 SLB Muxes와 SLB 호스트 에이전트 간의 구성 및 상태를 조정하기 위해 네트워크 컨트롤러에서 사용하는 SLB Manager VIP 주소의 IP 주소가 나열되어 있습니다.
- MuxState-이 섹션은 하나의 값에 나열 각 SLB 먹 싱 배포는 mux의 상태를 제공 합니다.
- 라우터 구성-이 섹션에는 업스트림 라우터 (BGP 피어) 나열 됩니다 번호 ASN (Autonomous System), 전송 중인 IP 주소 및 id입니다. 또한 SLB Muxes ASN 및 전송 IP 나열 됩니다.
- 호스트 정보-이 섹션에 연결 된 목록 관리 IP 다룰 모든 Hyper-v 호스트 부하 분산 된 작업을 실행할 수 있습니다.
- Vip 범위-이 섹션은 공용 및 개인 VIP IP 풀 범위를 나열 합니다. SLBM VIP는 이러한 범위 중 하나에서 할당 된 IP로 포함 됩니다.
- Mux 경로-이 섹션에 대 한 각 SLB 먹 싱 배포 된 모든 해당 특정 mux에 대 한 경로 알림에 포함 된 하나의 값을 나열 됩니다.
테 넌 트
- VipConsolidatedState - 이 섹션에서는 보급된 경로 접두사, Hyper-V 호스트 및 DIP 엔드포인트를 포함하여 각 테넌트 VIP에 대한 연결 상태를 나열합니다.

참고 항목

SLB 상태를 사용 하 여 직접 조사할 수 있습니다는 DumpSlbRestState 스크립트에서 사용할 수는 Microsoft SDN GitHub 리포지토리합니다.

게이트웨이 유효성 검사

네트워크 컨트롤러에서:

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

게이트웨이 VM에서:

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

ToR(Top of Rack) 스위치에서:

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

Windows BGP 라우터:

Get-BgpRouter
Get-BgpPeer
Get-BgpRouteInformation

이외에도, (특히 SDNExpress 기반 배포의 경우)에서 지금까지 살펴본 문제에서 테 넌 트 구획 가져오기에 구성 되어 있지 GW Vm에 대 한 가장 일반적인 이유를 찾을 수 있다는 사실을 FabricConfig.psd1의 GW 용량 작은에서 비해 네트워크 연결 (S2S 터널)에 할당 하려고 하는 담당자 TenantConfig.psd1 합니다. 다음 cmdlet의 출력을 비교하여 쉽게 확인할 수 있습니다.

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

[호스터] 평면 데이터의 유효성을 검사합니다

네트워크 컨트롤러 배포한 하 고 테 넌 트 가상 네트워크 및 서브넷을 만든 가상 서브넷에 연결 된 Vm, 후 호스터 테 넌 트 연결을 확인 하 여 추가 패브릭 수준 테스트를 수행할 수 있습니다.

HNV 공급자 논리 네트워크 연결 확인

네트워크 컨트롤러 VM을 Hyper-v 호스트에서 실행 되는 테 넌 트 가상 네트워크에 연결 하는 첫 번째 게스트 후 Hyper-v 호스트에 두 개의 HNV 공급자 IP 주소 (PA IP 주소)를 할당 합니다. 이러한 Ip는 HNV 공급자 논리 네트워크의 IP 풀에서 옵니다 네트워크 컨트롤러에서 관리 합니다. 다음 두 HNV IP 주소가 무엇인지 확인하려면:

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

이러한 HNV 공급자 IP 주소 (PA Ip)는 별도 TCPIP 네트워크 구획에서 만든 이더넷 어댑터에 할당 되어 있고의 어댑터 이름을 VLANX 여기서 X는 HNV 공급자 (전송) 논리 네트워크에 할당 된 VLAN입니다.

논리 네트워크는 추가 구획이 있는 ping 하 여 수행할 수 있습니다 HNV 공급자를 사용 하는 두 Hyper-v 호스트 간 연결 (-c Y) 매개 변수 Y는 PAhostVNICs 만들어집니다 TCPIP 네트워크 구획입니다. 실행 하 여이 구획을 확인할 수 있습니다.

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 호스트 vNIC 어댑터의 데이터 경로에 사용 되지 않으며 따라서 "vEthernet (PAhostVNic)"어댑터에 할당 된 IP를 갖지 않습니다.

예를 들어, 가정 Hyper-v 호스트 1과 2의 HNV PA (공급자) IP 주소:

Hyper-V 호스트	PA IP 주소 1	PA IP 주소 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

수정

HNV 공급자 ping이 작동하지 않는 경우 VLAN 구성을 포함하여 실제 네트워크 연결을 확인합니다. 각 Hyper-v 호스트의 실제 Nic 할당 없는 특정 vlan 트렁크 모드에 있어야 합니다. 관리 호스트 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> ...

HNV 공급자 논리 네트워크에서 MTU 및 점보 프레임 지원 확인

HNV 공급자 논리 네트워크의 또 다른 일반적인 문제는 물리적 네트워크 포트 및/또는 이더넷 카드에 VXLAN(또는 NVGRE) 캡슐화의 오버헤드를 처리하도록 구성된 충분한 MTU가 없다는 것입니다.

참고 항목

일부 이더넷 카드 및 드라이버는 네트워크 컨트롤러 호스트 에이전트에서 자동으로 160 값으로 설정되는 새 *EncapOverhead 키워드를 지원합니다. 그런 다음 이 값은 합계가 보급된 MTU로 사용되는 *JumboPacket 키워드의 값에 추가됩니다.

예를 들어 *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 크기 엔드투엔드(end-to-end)를 지원하는지 여부를 테스트하려면 cmdlet을 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 이더넷 헤더 및 트레일러 포함)
NIC 카드가 EncapOverhead 키워드를 지원하지 않는 경우 JumboPacket 키워드를 1674B 이상으로 조정합니다.

테넌트 VM NIC 연결 확인

게스트 VM에 할당 된 각 VM NIC에 개인 고객 주소 (CA)와 HNV PA (공급자 주소) 공간 간의 CA-PA 매핑이 있습니다. 이러한 매핑은 각 Hyper-v 호스트에서 OVSDB 서버 테이블에 유지 되 고 다음 cmdlet을 실행 하 여 찾을 수 있습니다.

# 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 매핑이 지정된 테넌트 VM에 대한 출력이 아닌 경우 cmdlet을 사용하여 네트워크 컨트롤러에서 VM NIC 및 IP 구성 리소스를 Get-NetworkControllerNetworkInterface 확인하세요. 또한 NC 호스트 에이전트 및 네트워크 컨트롤러 노드 간에 설정 된 연결을 확인 합니다.

이 정보를 사용하면 이제 cmdlet을 사용하여 네트워크 컨트롤러에서 Hoster가 테넌트 VM ping을 Test-VirtualNetworkConnection 시작할 수 있습니다.

특정 문제 해결 시나리오

다음 섹션에서는 특정 시나리오 문제를 해결하기 위한 지침을 제공합니다.

두 개의 테 넌 트 가상 컴퓨터 간 네트워크 연결 없음

[Tenant] 테 넌 트 가상 컴퓨터에서 Windows 방화벽이 트래픽을 차단 하지 확인 합니다.
[테넌트] 를 실행 ipconfig하여 IP 주소가 테넌트 가상 머신에 할당되었는지 확인합니다.
[호스터] 실행 Test-VirtualNetworkConnection 에 두 명의 테 넌 트 가상 컴퓨터 간의 연결 유효성을 검사 하는 Hyper-v 호스트에서.

참고 항목

Vsid가 참조 된 가상 서브넷 id. VXLAN의 경우는 VXLAN 네트워크 식별자 (vni) 또는입니다. cmdlet을 Get-PACAMapping 실행하여 이 값을 찾을 수 있습니다.

예시

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

192.168.1.5의 ListenerCA IP에 Mgmt IP가 10.127.132.153인 호스트 "sa18n30-2.sa18.nttest.microsoft.com"에서 SenderCA IP가 192.168.1.5인 "Green Web VM 1" 간에 CA ping을 만듭니다. 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> ...

[테넌트] 트래픽을 차단하는 가상 서브넷 또는 VM 네트워크 인터페이스에 지정된 분산 방화벽 정책이 없는지 확인합니다.

데모 환경에서 sa18.nttest.microsoft.com 도메인의 sa18n30nc에 있는 네트워크 컨트롤러 REST API를 쿼리합니다.

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

이 ACL을 참조하는 IP 구성 및 가상 서브넷 살펴보기

[호스터] 실행 Get-ProviderAddress 두 hyper-v 호스트 두 호스팅 질문의 가상 컴퓨터를 테 넌 트 한 다음 실행 Test-LogicalNetworkConnection 또는 ping -c <compartment> HNV 공급자 논리 네트워크에 대 한 연결 유효성을 검사 하는 Hyper-v 호스트에서
[호스터] Hyper-v 호스트에 올바른 및 모든 계층 2 디바이스 사이 Hyper-v 호스트를 전환 MTU 설정 되어 있는지 확인 합니다. 실행 Test-EncapOverheadValue 에 모든 Hyper-v 호스트에 있습니다. 또한 확인 사이 있는 모든 계층 2 스위치 MTU 160 바이트의 최대 오버 헤드를 고려 하 1674 바이트 이상으로 설정 합니다.
[호스터] PA IP 주소가 없는 경우, CA 연결이 끊어진 네트워크 정책을 받은 있는지 확인 합니다. 실행 Get-PACAMapping 캡슐화 규칙 및 오버레이 가상 네트워크를 만드는 데 필요한 CA-PA 매핑은 올바르게 설정 하는 경우를 확인 합니다.
[호스터] 네트워크 컨트롤러 호스트 에이전트가 네트워크 컨트롤러에 연결 되어 있는지 확인 합니다. 이 위해 실행 netstat -anp tcp |findstr 6640합니다.
[호스터] HKLM에 호스트 ID 확인 / 테 넌 트 가상 컴퓨터를 호스팅하는 서버 리소스의 인스턴스 ID와 일치 합니다.
[호스터] 포트 프로필 ID 테 넌 트 가상 컴퓨터의 VM 네트워크 인터페이스의 인스턴스 ID와 일치 하는지 확인 합니다.

로깅, 추적 및 고급 진단

다음 섹션에서는 고급 진단, 로깅 및 추적에 대한 정보를 제공합니다.

네트워크 컨트롤러 중앙 집중식으로 로깅

자동으로 네트워크 컨트롤러 디버거 로그를 수집 하 고 중앙 집중화 된 위치에 저장할 수 있습니다. 네트워크 컨트롤러를 처음 배포하거나 나중에 언제든지 로그 수집을 사용하도록 설정할 수 있습니다. 로그의 네트워크 컨트롤러에서 수집 되 고 네트워크 네트워크 컨트롤러가 관리 하는 요소: 컴퓨터, 소프트웨어 부하 분산 장치 (SLB) 및 게이트웨이 컴퓨터를 호스트 합니다.

이러한 로그에는 네트워크 컨트롤러 클러스터, 네트워크 컨트롤러 애플리케이션, 게이트웨이 로그, SLB, 가상 네트워킹 및 분산 방화벽에 대한 디버그 로그가 포함됩니다. 새 호스트/SLB/게이트웨이 네트워크 컨트롤러에 추가 되 면 때마다 로깅 해당 컴퓨터에서 시작 됩니다. 마찬가지로, 호스트/SLB/게이트웨이 네트워크 컨트롤러에서 제거 되 면 해당 컴퓨터에서 로깅이 중지 됩니다.

로깅 사용

로깅은 cmdlet을 사용하여 Install-NetworkControllerCluster 네트워크 컨트롤러 클러스터를 설치할 때 자동으로 사용하도록 설정됩니다. 기본적으로 로그는 로컬로 수집의 네트워크 컨트롤러 노드에서 %systemdrive%\SDNDiagnostics합니다. 이 위치를 로컬이 아닌 원격 파일 공유로 변경하는 것이 좋습니다.

네트워크 컨트롤러 클러스터 로그에 저장 된 %programData%\Windows Fabric\log\Traces합니다. 원격 파일 공유라는 권장 사항을 사용하여 매개 변수를 DiagnosticLogLocation 사용하여 로그 수집에 대한 중앙 집중식 위치를 지정할 수 있습니다.

이 위치에 대 한 액세스를 제한 하려는 경우에 대 한 액세스 자격 증명을 제공할 수 있습니다는 LogLocationCredential 매개 변수입니다. 또한 제공 해야 로그 위치에 액세스 하는 데 사용할 자격 증명을 제공 하는 경우는 CredentialEncryptionCertificate 네트워크 컨트롤러 노드에 로컬로 저장 된 자격 증명을 암호화 하는 데 사용 되는 매개 변수입니다.

기본 설정을 사용하면 중앙 위치에 최소 75GB의 여유 공간이 있고 3노드 네트워크 컨트롤러 클러스터의 경우 로컬 노드(중앙 위치를 사용하지 않는 경우)에 25GB를 사용하는 것이 좋습니다.

로깅 설정 변경

로깅 설정을 사용 하는 모든 시간에 변경할 수는 Set-NetworkControllerDiagnostic cmdlet입니다. 다음 설정은 변경할 수 있습니다.

중앙 집중식 로그 위치입니다.

적용 된 모든 로그를 저장 하는 위치를 변경할 수는 DiagnosticLogLocation 매개 변수입니다.
로그 위치에 액세스하기 위한 자격 증명입니다.

로그 위치와 액세스 하는 데 사용할 자격 증명을 변경할 수는 LogLocationCredential 매개 변수입니다.
로컬 로깅으로 이동합니다.

로그를 저장 하는 중앙된 위치를 입력 한 경우 다시 이동할 수 있습니다 사용 하 여 네트워크 컨트롤러 노드를 로컬로 로그온 하는 UseLocalLogLocation 매개 변수 (많은 디스크 공간 요구 사항으로 인해 권장 하지 않음).
로깅 범위입니다.

기본적으로 모든 로그가 수집 됩니다. 유일한 네트워크 컨트롤러 클러스터 로그를 수집 하도록 범위를 변경할 수 있습니다.
로깅 수준입니다.

기본 로깅 수준을 정보입니다. 오류, 경고 또는 자세한 정보 표시를 변경할 수 있습니다.
로그 에이징 시간입니다.

로그는 순환 방식으로 저장 됩니다. 로컬 로깅을 사용하든 중앙 집중식 로깅을 사용하든 간에 기본적으로 3일간의 로깅 데이터가 있습니다. 매개 변수를 LogTimeLimitInDays 사용하여 이 시간 제한을 변경할 수 있습니다.
로그 에이징 크기입니다.

기본적으로 로컬 로깅을 사용 하는 경우 중앙 집중식된 로깅 및 25GB를 사용 하는 경우 로깅 데이터의 최대 75GB를 해야 합니다. 이 제한 되어 있으며 변경할 수는 LogSizeLimitInMBs 매개 변수입니다.

로그 및 추적 수집

VMM 배포는 기본적으로 네트워크 컨트롤러에 대 한 중앙 집중식된 로깅을 사용합니다. 이러한 로그에 대 한 파일 공유 위치는 네트워크 컨트롤러 서비스 템플릿을 배포할 때 지정 됩니다.

파일 위치를 지정하지 않으면 C:\Windows\tracing\SDNDiagnostics 아래에 저장된 로그가 있는 각 네트워크 컨트롤러 노드에서 로컬 로깅이 사용됩니다. 이러한 로그는 다음과 같은 계층을 사용 하 여 저장 됩니다.

크래시 덤프
NCApplicationCrashDumps
NCApplicationLogs
PerfCounters
SDNDiagnostics
Traces

네트워크 컨트롤러는 서비스 패브릭 (Azure)를 사용합니다. 특정 문제를 해결할 때 Service Fabric 로그가 필요할 수 있습니다. 이러한 로그는 C:\ProgramData\Microsoft\Service Fabric의 각 네트워크 컨트롤러 노드에서 찾을 수 있습니다.

사용자가 cmdlet을 실행한 경우 네트워크 컨트롤러의 Debug-NetworkController 서버 리소스로 지정된 각 Hyper-V 호스트에서 더 많은 로그를 사용할 수 있습니다. 이러한 로그(및 활성화된 경우 추적)는 C:\NCDiagnostics 아래에 유지됩니다.

SLB 진단

SLBM 패브릭 오류(호스팅 서비스 공급자 작업)

SLBM(Software Load Balancer Manager)이 작동하고 있으며 오케스트레이션 계층이 서로 통신할 수 있는지 확인합니다. SLBM -> SLB Mux 및 SLBM -> SLB 호스트 에이전트. 실행 DumpSlbRestState 네트워크 컨트롤러 REST 엔드포인트에 액세스할 수 있는 모든 노드에서 합니다.
네트워크 컨트롤러 노드 VM(기본 네트워크 컨트롤러 노드 - Get-NetworkControllerReplica가급적) 중 하나에서 PerfMon의 SDNSLBMPerfCounters 유효성을 검사합니다.
1. 부하 분산 장치 (LB) 엔진 SLBM에 연결 되어 있습니까? (SLBM LBEngine 구성 합계 > 0)
2. SLBM 적어도 알 자체 엔드포인트에 대 한? (VIP 엔드포인트 합계>= 2)
3. Hyper-v (DIP) 호스트 SLBM에 연결 되어 있습니까? (연결 된 HP 클라이언트 num 서버 = =)
4. SLBM은 Muxes에 연결 되어 있습니까? (Muxes Connected == Muxes Healthy on SLBM == Muxes reporting healthy = # SLB Muxes VM).
구성된 BGP 라우터가 SLB MUX와 피어링되었는지 확인합니다.
1. 원격 액세스에서 RRAS를 사용하는 경우(즉, BGP 가상 머신):
  1. Get-BgpPeer 연결됨을 표시해야 합니다.
  2. Get-BgpRouteInformation 는 SLBM 자체 VIP에 대한 경로 이상을 표시해야 합니다.
2. 물리적 ToR(Top-of-Rack) 스위치를 BGP 피어로 사용하는 경우 설명서를 참조하세요.
  1. 예: # show bgp instance
SLB Mux VM의 PerfMon에서 SlbMuxPerfCounters 및 SLBMUX 카운터의 유효성을 검사합니다.
소프트웨어 Load Balancer 관리자 리소스에서 구성 상태 및 VIP 범위를 확인합니다.
1. Get-NetworkControllerLoadBalancerConfiguration -ConnectionUri <https://\<FQDN or IP>| convertto-json -depth 8 (IP 풀에서 VIP 범위를 확인하고 SLBM 자체 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 피어 링 정보 성공적으로 구성 되어 있는지 확인
서버 리소스에 있는 서버 인스턴스 ID를 일치 하는 레지스트리에서 호스트 ID 확인 (부록 d 참조 HostNotConnected 오류 코드)
로그 수집

SLBM 테넌트 오류(호스팅 서비스 공급자 및 테넌트 작업)

[호스터] LoadBalancer 리소스가 오류 상태인지 확인 Debug-NetworkControllerConfigurationState 합니다. 부록에는 테이블 작업 항목에 따라 완화 하려고 합니다.
1. VIP 엔드포인트가 있는지 확인하고 경로를 보급합니다.
2. VIP 엔드포인트에 대해 검색된 DIP 엔드포인트 수를 확인합니다.
[테넌트] Load Balancer 리소스가 올바르게 지정되었는지 확인합니다.
1. SLBM에 등록된 DIP 엔드포인트가 LoadBalancer 백 엔드 주소 풀 IP 구성에 해당하는 테넌트 가상 머신을 호스팅하는지 확인합니다.
[호스터] DIP 엔드포인트가 검색되거나 연결되지 않은 경우:
1. Debug-NetworkControllerConfigurationState 확인
  
  를 사용하여 netstat -anp tcp |findstr 6640)NC 및 SLB 호스트 에이전트가 네트워크 컨트롤러 이벤트 코디네이터에 성공적으로 연결되었는지 확인합니다.
2. HostId서비스 regkey 체크 인nchostagent(부록의 참조 HostNotConnected 오류 코드)이 해당 서버 리소스의 인스턴스 ID(Get-NCServer |convertto-json -depth 8)와 일치합니다.
3. 가상 머신 포트에 대한 포트 프로필 ID가 해당 가상 머신 NIC 리소스의 인스턴스 ID와 일치하는지 확인합니다.
[호스팅 공급자] 로그를 수집합니다.

SLB Mux 추적

소프트웨어 부하 분산 장치 Muxes의 정보는 또한 이벤트 뷰어를 통해 확인할 수 있습니다.

이벤트 뷰어 보기 메뉴에서 분석 및 디버그 로그 표시를 선택합니다.
이벤트 뷰어 애플리케이션 및 서비스 로그>Microsoft>Windows>SlbMuxDriver>추적으로 이동합니다.
마우스 오른쪽 단추로 클릭하고 로그 사용을 선택합니다.

참고 항목

문제를 재현하는 동안 이 로깅을 잠시 동안만 사용하도록 설정하는 것이 좋습니다.

VFP 및 vSwitch 추적

테넌트 가상 네트워크에 연결된 게스트 VM을 호스팅하는 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

다음을 통해 공유

Windows Server 소프트웨어 정의 네트워킹 스택 문제 해결

오류 형식

진단 도구

네트워크 컨트롤러 진단

Hyper-v 호스트에 대 한 진단 유틸리티

GitHub

워크플로 및 가이드 문제 해결

[호스터] 시스템 상태 유효성 검사

네트워크 컨트롤러와 Hyper-v 호스트 (NC 호스트 에이전트 서비스) 간의 네트워크 연결 확인

호스트 에이전트 서비스 확인

네트워크 컨트롤러의 상태를 확인 합니다.

네트워크 컨트롤러와 각 Hyper-V 호스트 간에 해당 HostID 및 인증서 확인

SLB 구성 상태 확인

게이트웨이 유효성 검사

[호스터] 평면 데이터의 유효성을 검사합니다

HNV 공급자 논리 네트워크 연결 확인

HNV 공급자 논리 네트워크에서 MTU 및 점보 프레임 지원 확인

테넌트 VM NIC 연결 확인

특정 문제 해결 시나리오

두 개의 테 넌 트 가상 컴퓨터 간 네트워크 연결 없음

예시

이 ACL을 참조하는 IP 구성 및 가상 서브넷 살펴보기

로깅, 추적 및 고급 진단

네트워크 컨트롤러 중앙 집중식으로 로깅

로깅 사용

로깅 설정 변경

로그 및 추적 수집

SLB 진단

SLBM 패브릭 오류(호스팅 서비스 공급자 작업)

SLBM 테넌트 오류(호스팅 서비스 공급자 및 테넌트 작업)

SLB Mux 추적

VFP 및 vSwitch 추적

피드백

추가 리소스