Windows Server 소프트웨어 정의 네트워킹 스택 문제 해결
이 가이드에서는 일반적인 SDN(소프트웨어 정의 네트워킹) 오류 및 실패 시나리오를 살펴보고 사용 가능한 진단 도구를 사용하는 문제 해결 워크플로를 간략하게 설명합니다. SDN에 대한 자세한 내용은 소프트웨어 정의 네트워킹을 참조하세요.
적용 대상: Windows Server 2022, Windows Server 2019, Windows Server 2016, Azure Stack HCI, 버전 21H2 및 20H2
오류 유형
다음 목록은 시장 내 프로덕션 배포에서 Windows Server 2012 R2의 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 호스트 에이전트 간의 제어 경로에서 네트워크 정책 일관성 문제를 식별하는 데 도움이 됩니다.
및 Get-NetworkControllerReplica cmdlet은 Debug-ServiceFabricNodeStatus 네트워크 컨트롤러 노드 가상 머신 중 하나에서 실행되어야 합니다. 다른 모든 NC 진단 cmdlet은 네트워크 컨트롤러에 연결되어 있고 Kerberos(네트워크 컨트롤러 관리 보안 그룹)에 있거나 네트워크 컨트롤러를 관리하기 위한 X.509 인증서에 액세스할 수 있는 모든 호스트에서 실행할 수 있습니다.
Hyper-V 호스트 진단
이러한 cmdlet은 Hyper-V HNV(네트워크 가상화) 진단 cmdlet의 TechNet에 설명되어 있습니다. 테넌트 가상 머신(동/서부)과 SLB VIP(남북)를 통한 수신 트래픽 간의 데이터 경로에서 문제를 식별하는 데 도움이 됩니다.
Debug-VirtualMachineQueueOperation, Get-CustomerRoute, , Get-PACAMappingGet-ProviderAddress, , Get-VMNetworkAdapterPortId, Get-VMSwitchExternalPortId및 Test-EncapOverheadSettings 는 모든 Hyper-V 호스트에서 실행할 수 있는 모든 로컬 테스트입니다. 다른 cmdlet은 네트워크 컨트롤러를 통해 데이터 경로 테스트를 호출하므로 위에서 설명한 대로 네트워크 컨트롤러에 액세스해야 합니다.
GitHub
Microsoft/SDN GitHub 리포지토리에는 이러한 기본 제공 cmdlet을 기반으로 빌드되는 많은 샘플 스크립트 및 워크플로가 있습니다. 특히 진단 스크립트는 진단 폴더에서 찾을 수 있습니다. 끌어오기 요청을 제출하여 이러한 스크립트에 기여하도록 도와주세요.
워크플로 및 가이드 문제 해결
[Hoster] 시스템 상태 유효성 검사
여러 네트워크 컨트롤러 리소스에 Configuration State 라는 포함된 리소스가 있습니다. 구성 상태는 네트워크 컨트롤러의 구성과 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로 설정된 경우에도 이 오류를 무시해도 됩니다.
아래 표에서는 관찰된 구성 상태에 따라 수행할 오류 코드, 메시지 및 후속 작업 목록을 보여 줍니다.
| 코드 | 메시지 | 작업 |
|---|---|---|
| 알 수 없음 | 알 수 없는 오류 | |
| HostUnreachable | 호스트 컴퓨터에 연결할 수 없음 | 네트워크 컨트롤러와 호스트 간의 관리 네트워크 연결 확인 |
| PAIpAddressExhausted | PA IP 주소가 모두 사용됨 | HNV 공급자 논리 서브넷의 IP 풀 크기 늘리기 |
| PAMacAddressExhausted | PA Mac 주소가 모두 사용됨 | Mac 풀 범위 늘리기 |
| PAAddressConfigurationFailure | PA 주소를 호스트에 연결하지 못했습니다. | 네트워크 컨트롤러와 호스트 간의 관리 네트워크 연결을 확인합니다. |
| CertificateNotTrusted | 인증서를 신뢰할 수 없음 | 호스트와의 통신에 사용되는 인증서를 수정합니다. |
| CertificateNotAuthorized | 인증서에 권한이 없음 | 호스트와의 통신에 사용되는 인증서를 수정합니다. |
| PolicyConfigurationFailureOnVfp | VFP 정책 구성 실패 | 런타임 오류입니다. 명확한 해결 방법이 없습니다. 로그를 수집합니다. |
| PolicyConfigurationFailure | NetworkController의 통신 오류 또는 기타 오류로 인해 호스트에 정책을 푸시하는 데 실패했습니다. | 명확한 조치가 없습니다. 이는 네트워크 컨트롤러 모듈의 목표 상태 처리 실패 때문입니다. 로그를 수집합니다. |
| HostNotConnectedToController | 호스트가 네트워크 컨트롤러에 아직 연결되지 않았습니다. | 호스트에 포트 프로필이 적용되지 않거나 네트워크 컨트롤러에서 호스트에 연결할 수 없습니다. HostID 레지스트리 키가 서버 리소스의 인스턴스 ID와 일치하는지 확인합니다. |
| MultipleVfpEnabledSwitches | 호스트에 여러 VFp 사용 스위치가 있습니다. | 네트워크 컨트롤러 호스트 에이전트는 VFP 확장을 사용하도록 설정된 하나의 vSwitch만 지원하므로 스위치 중 하나를 삭제합니다. |
| PolicyConfigurationFailure | 인증서 오류 또는 연결 오류로 인해 VmNic에 대한 VNet 정책을 푸시하지 못했습니다. | 적절한 인증서가 배포되었는지 확인합니다(인증서 주체 이름은 호스트의 FQDN과 일치해야 합니다). 또한 네트워크 컨트롤러를 사용하여 호스트 연결을 확인합니다. |
| PolicyConfigurationFailure | 인증서 오류 또는 연결 오류로 인해 VmNic에 대한 vSwitch 정책을 푸시하지 못했습니다. | 적절한 인증서가 배포되었는지 확인합니다(인증서 주체 이름은 호스트의 FQDN과 일치해야 합니다). 또한 네트워크 컨트롤러를 사용하여 호스트 연결을 확인합니다. |
| PolicyConfigurationFailure | 인증서 오류 또는 연결 오류로 인해 VmNic에 대한 방화벽 정책을 푸시하지 못했습니다. | 적절한 인증서가 배포되었는지 확인합니다(인증서 주체 이름은 호스트의 FQDN과 일치해야 합니다). 또한 네트워크 컨트롤러를 사용하여 호스트 연결을 확인합니다. |
| DistributedRouterConfigurationFailure | 호스트 vNic에서 분산 라우터 설정을 구성하지 못했습니다. | TCPIP 스택 오류입니다. 이 오류가 보고된 서버에서 PA 및 DR 호스트 vNIC를 정리해야 할 수 있습니다. |
| DhcpAddressAllocationFailure | VMNic에 대한 DHCP 주소 할당 실패 | 고정 IP 주소 특성이 NIC 리소스에 구성되어 있는지 확인합니다. |
| CertificateNotTrusted CertificateNotAuthorized |
네트워크 또는 인증서 오류로 인해 Mux에 연결하지 못했습니다. | 오류 메시지 코드에 제공된 숫자 코드를 확인합니다. 이는 winsock 오류 코드에 해당합니다. 인증서 오류는 세분화되어 있습니다(예: 인증서를 확인할 수 없음, 인증되지 않은 인증서 등) |
| HostUnreachable | MUX가 비정상입니다(일반적인 경우는 BGPRouter 연결이 끊김). | RRAS(BGP 가상 머신) 또는 ToR(Top-of-Rack) 스위치의 BGP 피어는 연결할 수 없거나 피어링에 성공하지 못했습니다. 소프트웨어 Load Balancer 멀티플렉서 리소스 및 BGP 피어(ToR 또는 RRAS 가상 머신)에서 BGP 설정을 확인합니다. |
| HostNotConnectedToController | SLB 호스트 에이전트가 연결되지 않음 | SLB 호스트 에이전트 서비스가 실행 중인지 확인합니다. SLBM(NC)이 호스트 에이전트 실행 상태에서 제시한 인증서를 거부한 경우 미묘한 정보가 표시되는 이유는 SLB 호스트 에이전트 로그(자동 실행)를 참조하세요. |
| PortBlocked | VNET/ACL 정책 부족으로 인해 VFP 포트가 차단됨 | 정책이 구성되지 않을 수 있는 다른 오류가 있는지 확인합니다. |
| 오버 로드 | 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 호스트의 포트 TCP:6640에서 수신 대기(NC 호스트 에이전트 서비스)
- 포트 6640의 Hyper-V 호스트 IP에서 임시 포트의 NC 노드 IP로 설정된 두 연결(> 32000)
- 임시 포트의 Hyper-V 호스트 IP에서 포트 6640의 네트워크 컨트롤러 REST 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 지 확인합니다Ok.ReadyHealthState
프로덕션 배포에서 다중 노드 네트워크 컨트롤러를 사용하여 각 서비스의 기본 노드와 개별 복제본(replica) 상태 검사 수 있습니다.
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 키를 업데이트합니다. Hyper-V 호스트(물리적 서버)에서 네트워크 컨트롤러 호스트 에이전트를 다시 시작합니다. VMM을 사용하는 경우 VMM에서 Hyper-V 서버를 삭제하고 HostId 레지스트리 키를 제거합니다. 그런 다음, VMM을 통해 서버를 다시 추가합니다.
Hyper-V 호스트(NC 호스트 에이전트 서비스)와 네트워크 컨트롤러 노드 간의 (SouthBound) 통신에 대해 Hyper-V 호스트에서 사용하는 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에서 해당 서버 리소스를 삭제합니다. 그런 다음 VMM에서 서버 리소스를 다시 만들어 새 X.509 인증서를 생성하고 Hyper-V 호스트에 설치합니다.
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 관리자 VIP 주소의 IP 주소를 나열합니다.
- MuxState - 이 섹션에서는 mux 상태를 제공하는 배포된 각 SLB Mux에 대해 하나의 값을 나열합니다.
- 라우터 구성 - 이 섹션에서는 업스트림 라우터(BGP 피어) ASN(자치 시스템 번호), 전송 IP 주소 및 ID를 나열합니다. SLB Muxes ASN 및 전송 IP도 나열됩니다.
- 연결된 호스트 정보 - 이 섹션에서는 부하 분산된 워크로드를 실행하는 데 사용할 수 있는 모든 Hyper-V 호스트의 관리 IP 주소를 나열합니다.
- Vip 범위 - 이 섹션에서는 공용 및 개인 VIP IP 풀 범위를 나열합니다. SLBM VIP는 이러한 범위 중 하나에서 할당된 IP로 포함됩니다.
- Mux 경로 - 이 섹션에서는 해당 특정 mux에 대한 모든 경로 보급 알림을 포함하는 배포된 각 SLB Mux에 대해 하나의 값을 나열합니다.
- 테넌트
- VipConsolidatedState - 이 섹션에서는 보급된 경로 접두사, Hyper-V 호스트 및 DIP 엔드포인트를 포함하여 각 테넌트 VIP에 대한 연결 상태를 나열합니다.
참고
SLB 상태는 Microsoft SDN GitHub 리포지토리에서 사용할 수 있는 DumpSlbRestState 스크립트를 사용하여 직접 확인할 수 있습니다.
게이트웨이 유효성 검사
네트워크 컨트롤러에서:
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) 스위치의 맨 위에서:
sh ip bgp summary (for 3rd party BGP Routers)
Windows BGP 라우터:
Get-BgpRouter
Get-BgpPeer
Get-BgpRouteInformation
이러한 문제 외에도 지금까지 본 문제(특히 SDNExpress 기반 배포에서)에서 테넌트 구획이 GW VM에 구성되지 않는 가장 일반적인 이유는 FabricConfig.psd1의 GW 용량이 TenantConfig.psd1의 네트워크 Connections(S2S 터널)에 할당하려는 사용자에 비해 적다는 사실인 것 같습니다. 다음 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
[Hoster] Data-Plane 유효성 검사
네트워크 컨트롤러가 배포되고 테넌트 가상 네트워크 및 서브넷이 생성되고 VM이 가상 서브넷에 연결되면 호스트에서 테넌트 연결을 검사 위해 추가 패브릭 수준 테스트를 수행할 수 있습니다.
HNV 공급자 논리 네트워크 연결 확인
Hyper-V 호스트에서 실행되는 첫 번째 게스트 VM이 테넌트 가상 네트워크에 연결되면 네트워크 컨트롤러는 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 네트워크 구획에서 만든 이더넷 어댑터에 할당되며 X가 HNV 공급자(전송) 논리 네트워크에 할당된 VLAN인 VLANX 의 어댑터 이름이 있습니다.
HNV 공급자 논리 네트워크를 사용하는 두 Hyper-V 호스트 간의 연결은 PAhostVNIC가 만들어지는 TCPIP 네트워크 구획인 추가 구획(-c Y) 매개 변수가 있는 ping을 통해 수행할 수 있습니다. 이 구획은 다음을 실행하여 확인할 수 있습니다.
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가 없습니다.
instance 경우 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 |
다음 명령을 사용하여 두 명령 간에 ping하여 HNV 공급자 논리 네트워크 연결을 검사 수 있습니다.
# 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 키워드(keyword) 지원합니다. 그러면 합계가 보급된 MTU로 사용되는 *JumboPacket 키워드(keyword) 값에 이 값이 추가됩니다.
예를 들어 = *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 크기 종단 간을 지원하는지 여부를 테스트하려면 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 키워드(keyword) 지원하지 않는 경우 JumboPacket 키워드(keyword) 1674B 이상으로 조정합니다.
테넌트 VM NIC 연결 확인
게스트 VM에 할당된 각 VM NIC에는 개인 CA(고객 주소)와 PA(HNV 공급자 주소) 공간 간의 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을 사용하여 Get-NetworkControllerNetworkInterface 네트워크 컨트롤러에서 VM NIC 및 IP 구성 리소스를 검사. 또한 NC 호스트 에이전트와 네트워크 컨트롤러 노드 간에 설정된 연결을 검사.
이 정보를 사용하면 이제 cmdlet을 사용하여 네트워크 컨트롤러의 Hoster에서 테넌트 VM ping을 Test-VirtualNetworkConnection 시작할 수 있습니다.
특정 문제 해결 시나리오
다음 섹션에서는 특정 시나리오 문제를 해결하기 위한 지침을 제공합니다.
두 테넌트 가상 머신 간의 네트워크 연결 없음
- [테넌트] 테넌트 가상 머신의 Windows 방화벽이 트래픽을 차단하지 않는지 확인합니다.
- [테넌트] 를 실행
ipconfig하여 IP 주소가 테넌트 가상 머신에 할당되었는지 확인합니다. - [Hoster] Hyper-V 호스트에서 를 실행
Test-VirtualNetworkConnection하여 문제의 두 테넌트 가상 머신 간의 연결 유효성을 검사합니다.
참고
VSID는 가상 서브넷 ID를 나타냅니다. VXLAN의 경우 VNI(VXLAN 네트워크 식별자)입니다. cmdlet을 Get-PACAMapping 실행하여 이 값을 찾을 수 있습니다.
예제
$password = ConvertTo-SecureString -String "password" -AsPlainText -Force
$cred = New-Object pscredential -ArgumentList (".\administrator", $password)
Mgmt IP가 10.127.132.153인 호스트 "sa18n30-2.sa18.nttest.microsoft.com"에서 SenderCA IP가 192.168.1.4인 "녹색 웹 VM 1"에서 192.168.1.5의 ListenerCA IP로 CA-ping을 만듭니다.
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 구성 및 가상 서브넷 살펴보기
- [Hoster]
Get-ProviderAddress문제의 두 테넌트 가상 머신을 호스트하는 두 Hyper-V 호스트에서 실행한 다음 Hyper-V 호스트에서 또는 를 실행Test-LogicalNetworkConnectionping -c <compartment>하여 HNV 공급자 논리 네트워크의 연결 유효성을 검사합니다. - [Hoster] Hyper-V 호스트와 Hyper-V 호스트 간에 계층 2 전환 디바이스에서 MTU 설정이 올바른지 확인합니다. 문제의 모든 Hyper-V 호스트에서 실행
Test-EncapOverheadValue합니다. 또한 160바이트의 최대 오버헤드를 고려하여 MTU가 1674바이트 이상으로 설정된 모든 Layer-2 스위치가 검사. - [Hoster] PA IP 주소가 없거나/또는 CA 연결이 끊어진 경우 네트워크 정책이 수신되었는지 확인하기 위해 검사. 를 실행
Get-PACAMapping하여 오버레이 가상 네트워크를 만드는 데 필요한 캡슐화 규칙 및 CA-PA 매핑이 올바르게 설정되었는지 확인합니다. - [Hoster] 네트워크 컨트롤러 호스트 에이전트가 네트워크 컨트롤러에 연결되어 있는지 확인합니다. 이렇게 하려면 를 실행합니다
netstat -anp tcp |findstr 6640. - [Hoster] HKLM/의 호스트 ID가 테넌트 가상 머신을 호스팅하는 서버 리소스의 인스턴스 ID와 일치하는지 확인합니다.
- [Hoster] 포트 프로필 ID가 테넌트 가상 머신의 VM 네트워크 인터페이스 인스턴스 ID와 일치하는지 확인합니다.
로깅, 추적 및 고급 진단
다음 섹션에서는 고급 진단, 로깅 및 추적에 대한 정보를 제공합니다.
네트워크 컨트롤러 중앙 집중식 로깅
네트워크 컨트롤러는 디버거 로그를 자동으로 수집하여 중앙 집중식 위치에 저장할 수 있습니다. 처음으로 또는 나중에 네트워크 컨트롤러를 배포할 때 로그 수집을 사용하도록 설정할 수 있습니다. 로그는 네트워크 컨트롤러 및 네트워크 컨트롤러에서 관리하는 네트워크 요소(호스트 머신, SLB(소프트웨어 부하 분산 장치) 및 게이트웨이 머신에서 수집됩니다.
이러한 로그에는 네트워크 컨트롤러 클러스터, 네트워크 컨트롤러 애플리케이션, 게이트웨이 로그, SLB, 가상 네트워킹 및 분산 방화벽에 대한 디버그 로그가 포함됩니다. 네트워크 컨트롤러에 새 호스트/SLB/게이트웨이가 추가될 때마다 해당 컴퓨터에서 로깅이 시작됩니다. 마찬가지로 네트워크 컨트롤러에서 호스트/SLB/게이트웨이가 제거되면 해당 컴퓨터에서 로깅이 중지됩니다.
로깅 사용
cmdlet을 사용하여 네트워크 컨트롤러 클러스터를 설치하면 로깅이 Install-NetworkControllerCluster 자동으로 활성화됩니다. 기본적으로 로그는 %systemdrive%\SDNDiagnostics의 네트워크 컨트롤러 노드에서 로컬로 수집됩니다. 이 위치를 로컬이 아닌 원격 파일 공유로 변경하는 것이 좋습니다.
네트워크 컨트롤러 클러스터 로그는 %programData%\Windows Fabric\log\Traces에 저장됩니다. 원격 파일 공유라는 권장 사항을 사용하여 매개 변수를 DiagnosticLogLocation 사용하여 로그 수집에 대한 중앙 집중식 위치를 지정할 수 있습니다.
이 위치에 대한 액세스를 제한하려면 매개 변수를 사용하여 액세스 자격 증명을 LogLocationCredential 제공할 수 있습니다. 로그 위치에 액세스하기 위한 자격 증명을 제공하는 경우 네트워크 컨트롤러 노드에 로컬로 저장된 자격 증명을 암호화하는 데 사용되는 매개 변수도 제공해야 CredentialEncryptionCertificate 합니다.
기본 설정을 사용하면 중앙 위치에 75GB 이상의 여유 공간이 있고 3노드 네트워크 컨트롤러 클러스터의 경우 로컬 노드에 25GB(중앙 위치를 사용하지 않는 경우)가 있는 것이 좋습니다.
로깅 설정 변경
cmdlet을 사용하여 Set-NetworkControllerDiagnostic 언제든지 로깅 설정을 변경할 수 있습니다. 다음 설정을 변경할 수 있습니다.
중앙 집중식 로그 위치입니다.
매개 변수를 사용하여 모든 로그를 저장하도록 위치를 변경할 수 있습니다
DiagnosticLogLocation.로그 위치에 액세스하기 위한 자격 증명입니다.
매개 변수를 사용하여 로그 위치에 액세스하도록 자격 증명을
LogLocationCredential변경할 수 있습니다.로컬 로깅으로 이동합니다.
로그를 저장할 중앙 집중식 위치를 제공한 경우 매개 변수를 사용하여 네트워크 컨트롤러 노드에서 로컬로 로깅으로
UseLocalLogLocation다시 이동할 수 있습니다(큰 디스크 공간 요구 사항으로 인해 권장되지 않음).로깅 scope.
기본적으로 모든 로그가 수집됩니다. 네트워크 컨트롤러 클러스터 로그만 수집하도록 scope 변경할 수 있습니다.
로깅 수준입니다.
기본 로깅 수준은 Informational입니다. 오류, 경고 또는 자세한 정보 표시로 변경할 수 있습니다.
로그 에이징 시간.
로그는 원형 방식으로 저장됩니다. 로컬 로깅 또는 중앙 집중식 로깅을 사용하는지 여부에 관계없이 기본적으로 3일간의 로깅 데이터가 있습니다. 매개 변수를
LogTimeLimitInDays사용하여 이 시간 제한을 변경할 수 있습니다.로그 에이징 크기입니다.
기본적으로 중앙 집중식 로깅을 사용하는 경우 최대 75GB의 로깅 데이터가 있고 로컬 로깅을 사용하는 경우 25GB가 있습니다. 매개 변수를
LogSizeLimitInMBs사용하여 이 제한을 변경할 수 있습니다.
로그 및 추적 수집
VMM 배포는 기본적으로 네트워크 컨트롤러에 대해 중앙 집중식 로깅을 사용합니다. 이러한 로그의 파일 공유 위치는 네트워크 컨트롤러 서비스 템플릿을 배포할 때 지정됩니다.
파일 위치를 지정하지 않은 경우 C :\Windows\tracing\SDNDiagnostics 아래에 저장된 로그가 있는 각 네트워크 컨트롤러 노드에서 로컬 로깅이 사용됩니다. 이러한 로그는 다음 계층 구조를 사용하여 저장됩니다.
- CrashDumps
- NCApplicationCrashDumps
- NCApplicationLogs
- PerfCounters
- SDNDiagnostics
- 추적
네트워크 컨트롤러는 (Azure) Service Fabric을 사용합니다. 특정 문제를 해결할 때 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 호스트 에이전트. 네트워크 컨트롤러 REST 엔드포인트에 대한 액세스 권한이 있는 모든 노드에서 DumpSlbRestState 를 실행합니다.
- 네트워크 컨트롤러 노드 VM(가급적 기본 네트워크 컨트롤러 노드 -
Get-NetworkControllerReplica) 중 하나에서 PerfMon의 SDNSLBMPerfCounters 유효성을 검사합니다.- Load Balancer(LB) 엔진이 SLBM에 연결되어 있나요? (SLBM LBEngine 구성 총 > 0)
- SLBM은 적어도 자체 엔드포인트에 대해 알고 있나요? (VIP 엔드포인트 합계>= 2)
- HYPER-V(DIP) 호스트가 SLBM에 연결되어 있나요? (연결된 HP 클라이언트 == num 서버)
- SLBM이 Muxes에 연결되어 있나요? (Muxes Connected == Muxes Healthy on SLBM == Muxes reporting healthy = # SLB Muxes VM).
- 구성된 BGP 라우터가 SLB MUX와 피어링되었는지 확인합니다.
- 원격 액세스에서 RRAS를 사용하는 경우(즉, BGP 가상 머신):
Get-BgpPeer연결됨을 표시해야 합니다.Get-BgpRouteInformation는 SLBM 자체 VIP에 대한 경로 이상을 표시해야 합니다.
- 물리적 ToR(Top-of-Rack) 스위치를 BGP 피어로 사용하는 경우 설명서를 참조하세요.
- 예:
# show bgp instance
- 예:
- 원격 액세스에서 RRAS를 사용하는 경우(즉, BGP 가상 머신):
- SLB Mux VM의 PerfMon에서 SlbMuxPerfCounters 및 SLBMUX 카운터의 유효성을 검사합니다.
- Software Load Balancer Manager 리소스에서 구성 상태 및 VIP 범위를 확인합니다.
Get-NetworkControllerLoadBalancerConfiguration -ConnectionUri <https://\<FQDN or IP>| convertto-json -depth 8(IP 풀에서 VIP 범위를 검사 SLBM 자체 VIP(LoadBalanacerManagerIPAddress) 및 테넌트 지향 VIP가 이러한 범위 내에 있는지 확인합니다.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
Debug-NetworkControllerConfigurationState -
위의 검사가 실패하면 테넌트 SLB 상태도 실패 모드에 있습니다.
수정
제공된 다음 진단 정보에 따라 다음을 수정합니다.
- SLB 멀티플렉서가 연결되어 있는지 확인
- 인증서 문제 해결
- 네트워크 연결 문제 해결
- BGP 피어링 정보가 성공적으로 구성되었는지 확인
- 레지스트리의 호스트 ID가 서버 리소스의 서버 인스턴스 ID와 일치하는지 확인합니다( HostNotConnected 오류 코드에 대한 참조 부록).
- 로그 수집
SLBM 테넌트 오류(호스팅 서비스 공급자 및 테넌트 작업)
- [Hoster] LoadBalancer 리소스가 오류 상태인지 확인
Debug-NetworkControllerConfigurationState합니다. 부록의 작업 항목 테이블에 따라 완화해 보세요.- VIP 엔드포인트가 있고 경로를 광고하고 있는지 확인합니다.
- VIP 엔드포인트에 대해 검색된 DIP 엔드포인트 수를 확인합니다.
- [테넌트] Load Balancer 리소스가 올바르게 지정되었는지 확인합니다.
- SLBM에 등록된 DIP 엔드포인트가 LoadBalancer 백 엔드 주소 풀 IP 구성에 해당하는 테넌트 가상 머신을 호스팅하는지 확인합니다.
- [Hoster] DIP 엔드포인트가 검색되거나 연결되지 않은 경우:
확인
Debug-NetworkControllerConfigurationState를 사용하여
netstat -anp tcp |findstr 6640)NC 및 SLB 호스트 에이전트가 네트워크 컨트롤러 이벤트 코디네이터에 성공적으로 연결되었는지 확인합니다.체크
HostId인nchostagent서비스 regkey(부록의 참조HostNotConnected오류 코드)는 해당 서버 리소스의 instance ID(Get-NCServer |convertto-json -depth 8)와 일치합니다.가상 머신 포트에 대한 포트 프로필 ID가 해당 가상 머신 NIC 리소스의 인스턴스 ID와 일치하는지 확인합니다.
- [호스팅 공급자] 로그를 수집합니다.
SLB Mux 추적
소프트웨어 Load Balancer 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
피드백
출시 예정: 2024년 내내 콘텐츠에 대한 피드백 메커니즘으로 GitHub 문제를 단계적으로 폐지하고 이를 새로운 피드백 시스템으로 바꿀 예정입니다. 자세한 내용은 다음을 참조하세요. https://aka.ms/ContentUserFeedback
다음에 대한 사용자 의견 제출 및 보기