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

ネットワーク コント ローラーの診断

これらのコマンドレットについては、 Network コントローラー診断コマンドレットの TechNet に関する記事を参照してください。 コントロール パスとネットワーク コント ローラーと HYPER-V ホストで実行されている NC ホスト エージェントの間にネットワーク コント ローラーのノード間でネットワーク ポリシーの整合性に問題を特定するのに役立ちます。

Debug-ServiceFabricNodeStatusおよびGet-NetworkControllerReplicaコマンドレットは、ネットワーク コントローラー ノードの仮想マシンのいずれかから実行する必要があります。 その他のすべての NC 診断コマンドレットは、ネットワーク コントローラーに接続でき、ネットワーク コントローラーの管理セキュリティ グループ (Kerberos) に所属しているか、ネットワーク コントローラーを管理するための X.509 証明書にアクセスできるすべてのホストから実行できます。

HYPER-V ホストでの診断

これらのコマンドレットは、TechNet の Hyper-V Network Virtualization (HNV) 診断コマンドレットに記載されています。 テナント仮想マシン (東または西) 間のデータ パスの問題を特定できると SLB VIP (北または南) からトラフィックを受信します。

Debug-VirtualMachineQueueOperation、Get-CustomerRoute、Get-PACAMapping、Get-ProviderAddress、Get-VMNetworkAdapterPortId、Get-VMSwitchExternalPortId、Test-EncapOverheadSettingsはすべて、任意の Hyper-V ホストから実行できるローカル テストです。 その他のコマンドレットでは、ネットワーク コントローラーを介してデータパス テストを呼び出すので、前述のようにネットワーク コントローラーへのアクセスが必要になります。

GitHub

Microsoft/SDN GitHub リポジトリには、これらのインボックス コマンドレットに基づいて構築されたサンプル スクリプトやワークフローが多数用意されています。 具体的には、診断のスクリプトは記載されて、 診断 フォルダーです。 Pull Requests を送信することで、これらのスクリプトの改善にご協力ください。

ワークフローとガイドのトラブルシューティング

[Hoster]システムの正常性を検証する

という名前の埋め込みリソースがある 構成状態 ネットワーク コント ローラーのリソースのいくつか。 構成の状態は、ネットワーク コント ローラーの構成と HYPER-V ホスト上の実際の (実行中) 状態の一貫性を含むシステム正常性に関する情報を提供します。

構成の状態を確認するには、ネットワーク コント ローラーへの接続にすべての HYPER-V ホストから、次を実行します。

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.
----------------------------------------------------------------------------------------------------------

次の表には、監視構成の状態に基づいて実行するには、エラー コード、メッセージ、およびフォロー アップのアクションの一覧が表示されます。

コード	メッセージ	アクション
Unknown	不明なエラー
HostUnreachable	ホスト コンピューターが到達可能ではありません。	ネットワーク コント ローラーとホスト間での管理ネットワーク接続を確認します。
PAIpAddressExhausted	PA IP アドレスが使い果たされました	HNV プロバイダー論理サブネットの IP プールのサイズを増やす
PAMacAddressExhausted	PA の Mac アドレスをすべて使用しました。	Mac プールの範囲を広げる
PAAddressConfigurationFailure	ホストの PA アドレスを組み込むために失敗しました	ネットワーク コント ローラーとホスト間の管理ネットワーク接続を確認します。
CertificateNotTrusted	証明書が信頼されていません。	ホストとの通信に使用される証明書を修正します。
CertificateNotAuthorized	証明書が承認されていません。	ホストとの通信に使用される証明書を修正します。
PolicyConfigurationFailureOnVfp	VFP ポリシーの構成の失敗	これは、実行時エラーです。 確実な回避策はありません。 ログを収集します。
PolicyConfigurationFailure	通信エラーまたはその他のユーザーによる、ホストへのポリシーのプッシュの障害、NetworkController のエラーです。	確実な操作はありません。 これは、目標とする状態、ネットワーク コント ローラー モジュールの処理のエラーが原因です。 ログを収集します。
HostNotConnectedToController	ホストがネットワーク コント ローラーにまだ接続されていません。	ポート プロファイルが適用されない、または、ホスト上では、ネットワーク コント ローラーから到達できません。 ホスト Id のレジストリ キーにサーバー リソースのインスタンス ID が一致することを検証します。
MultipleVfpEnabledSwitches	複数 VFp が、ホストでスイッチを有効には	ネットワーク コント ローラーのホストのエージェントでは、VFP 拡張を有効化と 1 つの vSwitch のみがサポートされているので、スイッチのいずれかを削除します。
PolicyConfigurationFailure	証明書のエラーまたは接続エラーのため VmNic の VNet のポリシーをプッシュできませんでした。	確認して適切な証明書が展開されているかどうか (証明書サブジェクト名は、ホストの FQDN を一致する必要があります)。 また、ホストと接続を確認、ネットワーク コント ローラー
PolicyConfigurationFailure	証明書のエラーまたは接続エラーのため VmNic の vSwitch ポリシーをプッシュできませんでした。	確認して適切な証明書が展開されているかどうか (証明書サブジェクト名は、ホストの FQDN を一致する必要があります)。 また、ホストと接続を確認、ネットワーク コント ローラー
PolicyConfigurationFailure	証明書のエラーまたは接続エラーのため VmNic のファイアウォール ポリシーをプッシュできませんでした。	確認して適切な証明書が展開されているかどうか (証明書サブジェクト名は、ホストの FQDN を一致する必要があります)。 また、ホストと接続を確認、ネットワーク コント ローラー
DistributedRouterConfigurationFailure	ホスト vNic の分散ルーター設定を構成できませんでした。	TCP/IP スタックのエラーです。 このエラーが報告されたサーバー上の PA と災害復旧ホスト Vnic のクリーンアップが必要な場合があります。
DhcpAddressAllocationFailure	VMNic の DHCP アドレス割り当てに失敗しました	NIC のリソースに静的 IP アドレス属性が構成されているかどうかは確認します。
CertificateNotTrusted CertificateNotAuthorized	ネットワークまたは証明書のエラーにより Mux に接続できませんでした。	エラー メッセージのコードで提供されている数値コードを確認します。 これは winsock エラー コードに対応します。 きめ細かいものでは証明書のエラー (たとえば、証明書を確認することはできません、証明書が承認されていないなどです)。
HostUnreachable	MUX に問題があります (一般的なケースは切断 BGPRouter)	BGP ピア RRAS (BGP 仮想マシン) または上部ラック (ToR) スイッチでは、正常に到達できないまたはいないピアリングです。 ソフトウェア ロード バランサー マルチプレクサー リソースと 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 とマルチプレクサー間の接続を確認します。
QosConfigurationFailure	QOS ポリシーの構成に失敗しました	十分な帯域幅は、QOS の予約を使用する場合はすべての仮想マシン用に使用可能なかどうかを参照してください。

ネットワーク コント ローラーと HYPER-V ホスト (NC ホスト エージェント サービス) の間のネットワーク接続を確認します。

次の netstat コマンドを実行して、NC ホスト エージェントとネットワーク コントローラー ノードと Hyper-V ホスト上の 1 つのLISTENING ソケットの間に 3 つのESTABLISHED接続があることを検証します。

• HYPER-V ホスト (NC ホスト エージェント サービス) にポート TCP:6640 でリッスンしています。
• ポート 6640 の HYPER-V ホスト IP から、エフェメラル ポート (> 32000) の NC ノード IP への確立された 2 つの接続
• ネットワーク コント ローラー REST ip ポート 6640 で一時的なポートでの HYPER-V ホストの IP から 1 つに確立された接続

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 ホスト上の 2 つのホスト エージェント サービスと通信します。 SLB ホスト エージェントと NC ホスト エージェント。 これらのサービスの一方または両方が実行されていない場合があります。 その状態を確認し、それらを実行していない場合は再起動します。

Get-Service SlbHostAgent
Get-Service NcHostAgent

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

ネットワーク コント ローラーの状態を確認します。

ESTABLISHED接続が 3 つない場合、またはネットワーク コントローラーが応答していないように見える場合は、次のコマンドレットを使用して、すべてのノードとサービス モジュールが稼働していることを確認します。

# 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 ホストで、次のコマンドレットを実行して、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 を使用して、HYPER-V サーバーを VMM から削除する場合は、HYPER-V ホスト (物理サーバー) 上のネットワーク コント ローラー ホスト エージェントを再起動し、ホスト Id のレジストリ キーを削除します。 次に、VMM を使用してサーバーをもう一度追加します。

(SouthBound) 間の通信、HYPER-V ホスト (NC ホスト エージェント サービス) とネットワーク コント ローラーのノード (ホスト名は証明書のサブジェクト名になります) から 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 構成状態は、 Debug-NetworkController コマンドレットへの出力の一部として決定できます。 このコマンドレットは、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

SLB 構成の状態については記載されて、 診断 slbstateResults.Json このディレクトリ内のファイルです。

この JSON ファイルは、次のセクションに分けることができます。

• ファブリック
  • SlbmVips - このセクションでは、SLB マネージャーの VIP アドレスの IP アドレスを一覧表示します。これは、SLB Muxes と SLB ホスト エージェントの間で構成と正常性を調整するためにネットワーク コントローラーで使用されます。
  • MuxState - このセクションには 1 つの値の一覧各 SLB Mux 展開、mux の状態を与える
  • ルーターの構成 - このセクションで、上流のルーターの (BGP ピア) ボックスの一覧は自律システム番号 (ASN)、転送中の IP アドレス、および ID SLB Muxes ASN および転送中の IP も表示されます。
  • ホスト情報のこのセクションで接続されている、管理 ip アドレス] ボックスの一覧のすべてのワークロードの負荷分散を実行できるように HYPER-V ホスト アドレスします。
  • Vip 範囲 - このセクションには、パブリックとプライベートの VIP IP プールの範囲が表示されます。 SLBM VIP は割り当てられている IP からこれらの範囲のいずれかとして含まれます。
  • Mux ルート] - このセクションには 1 つの値の一覧各 SLB Mux 展開されているすべての特定のマルチプレクサーのルートのアドバタイズを含みます。
• テナント
  • VipConsolidatedState - このセクションでは、アドバタイズされたルート プレフィックス、HYPER-V ホスト、DIP エンドポイントなど、テナント VIP ごとの接続状態を一覧表示します。

ゲートウェイの検証

ネットワーク コントローラーから:

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 にしようとするどのような人々 (S2S トンネル) のネットワーク接続に割り当てるよりも少なくします。 これは、次のコマンドレットの出力を比較することで簡単に確認できます。

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 プロバイダーの論理ネットワーク接続を確認する

HYPER-V ホストで実行されている VM がテナントの仮想ネットワークに接続された最初のゲストの後にネットワーク コント ローラーは、HYPER-V ホストに 2 つの HNV プロバイダー IP アドレス (PA IP アドレス) を割り当てます。 これらの Ip では、HNV プロバイダー論理ネットワークの IP プールから取得され、ネットワーク コント ローラーで管理します。 これら 2 つの 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 プロバイダーを使用して 2 つの 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> ...

たとえば、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 プロバイダーの論理ネットワークの接続をチェックする 2 つの 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 プロバイダー論理ネットワークのもう 1 つの一般的な問題は、物理ネットワーク ポートやイーサネット カードに、VXLAN (または NVGRE) カプセル化のオーバーヘッドを処理するための十分な大きさの MTU が構成されていないことです。

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

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

HNV プロバイダーの論理ネットワークで、より大きな MTU サイズのエンド ツー エンドがサポートされているかどうかをテストするには、 Test-LogicalNetworkSupportsJumboPacket コマンドレットを使用します。

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

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

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

修正

• 以上である物理スイッチ ポートで MTU サイズを調整する 1674B (14B イーサネット ヘッダーとトレーラーを含む)
• NIC カードで EncapOverhead キーワードがサポートされていない場合は、JumboPacket キーワードを 1674B 以上に調整します

テナント VM の NIC 接続を確認する

ゲスト VM に割り当てられている各 VM の NIC には、プライベート カスタマー アドレス (CA) と HNV プロバイダー アドレス (PA) 空間の間で CA と PA マッピングがあります。 これらのマッピングが各 HYPER-V ホストで OVSDB server のテーブルに保持され、次のコマンドレットを実行することによって検出されたことができます。

# 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

この情報により、 Test-VirtualNetworkConnection コマンドレットを使用して、ネットワーク コントローラーから Hoster によってテナント VM ping を開始できるようになりました。

特定のトラブルシューティング シナリオ

次のセクションでは、特定のシナリオのトラブルシューティングに関するガイダンスを提供します。

2 つのテナント仮想マシン間のネットワーク接続なし

1. [テナント]テナントの仮想マシンで Windows ファイアウォールがトラフィックをブロックしていないことを確認します。
2. [テナント] ipconfigを実行して、テナント仮想マシンに IP アドレスが割り当てられていることを確認します。
3. [ホスト]実行 Test-VirtualNetworkConnection 問題の 2 つのテナントの仮想マシン間の接続を検証する HYPER-V ホストからです。

例

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

ホスト "sa18n30-2.sa18.nttest.microsoft.com" 上の 192.168.1.4 の SenderCA IP と 10.127.132.153 の Mgmt IP を持つ "Green Web VM 1" から、192.168.1.5 の ListenerCA IP への 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 構成と仮想サブネットを確認する

1. [ホスト]実行 Get-ProviderAddress 両方の HYPER-V でホストをホストしている 2 つの質問の仮想マシンをテナントし、実行 Test-LogicalNetworkConnection または ping -c <compartment> HNV プロバイダーの論理ネットワーク上の接続を検証できる HYPER-V ホストから
2. [ホスト]MTU 設定が HYPER-V ホスト上で正しいことと、レイヤー 2 HYPER-V ホストの間にデバイスを切り替えることを確認します。 実行 Test-EncapOverheadValue 対象のすべての HYPER-V ホストにします。 また間にあるすべてのレイヤー 2 スイッチが MTU 160 バイトの最大のオーバーヘッドを考慮する最小限の 1674 バイトに設定をあることを確認します。
3. [ホスト]PA IP アドレスが存在しない CA 接続を確立できない場合や場合、は、ネットワーク ポリシーが受信されたことを確認することを確認します。 実行 Get-PACAMapping をカプセル化のルールと仮想ネットワークのオーバーレイを作成するために必要な CA と PA のマッピングが正しく確立されるかどうかを参照してください。
4. [ホスト]ネットワーク コント ローラーにネットワーク コント ローラーのホストのエージェントが接続されていることを確認してください。 これを行うには、netstat -anp tcp |findstr 6640 を実行します。
5. [ホスト]ホストが HKLM に ID チェック テナントの仮想マシンをホストしているサーバーのリソースのインスタンス ID と一致します。
6. [ホスト]ポート プロファイルの ID に、テナントの仮想マシンの VM ネットワーク インターフェイスのインスタンス ID が一致することを確認してください。

ログ記録、トレース、および高度な診断

次のセクションでは、高度な診断、ログ記録、およびトレースについて説明します。

ネットワーク コント ローラーがログ記録を集中管理

ネットワーク コント ローラーを自動的にデバッガーのログを収集し、一元的な場所に保管します。 ログ収集は、ネットワーク コントローラーを初めて展開するときや、それ以降ならいつでも有効にすることができます。 ログを選択して、ネットワーク コント ローラーから収集されるネットワーク ネットワーク コント ローラーで管理されている要素: コンピューター、ソフトウェアによる負荷分散 (SLB) とゲートウェイのマシンをホストします。

これらのログには、ネットワーク コントローラー クラスター、ネットワーク コントローラー アプリケーション、ゲートウェイのログ、SLB、仮想ネットワーク、分散型ファイアウォールのデバッグ ログが含まれます。 ネットワーク コント ローラーに新しいホスト/SLB/ゲートウェイを追加するたびにそれらのコンピューターのログ記録が開始されます。 同様に、ネットワーク コント ローラーからホスト/SLB/ゲートウェイが削除されると、それらのコンピューターのログが停止されました。

ログの有効化

Install-NetworkControllerCluster コマンドレットを使用してネットワーク コントローラー クラスターをインストールすると、ログ記録が自動的に有効になります。 既定では、ログ収集されます。 ローカルでのネットワーク コント ローラーのノードに %systemdrive%\SDNDiagnosticsします。 この場所は、(ローカルではなく) リモート ファイル共有に変更することをお勧めします。

ネットワーク コント ローラーのクラスター ログが格納されている %programData%\Windows Fabric\log\Tracesします。 DiagnosticLogLocation パラメーターを使用して、ログ収集の一元化された場所を指定できます。この場所もリモート ファイル共有にすることをお勧めします。

この場所へのアクセスを制限する場合に、アクセス資格情報を提供できます、 LogLocationCredential パラメーター。 ログの場所にアクセスする資格情報を指定する場合もを入力してください、 CredentialEncryptionCertificate パラメーターは、ネットワーク コント ローラーのノードでローカルに格納されている資格情報を暗号化するために使用します。

既定の設定を使用する場合、3 ノード ネットワーク コントロール クラスターでは、一元的な場所に 75 GB 以上の空き領域と、(一元的な場所を使用しない場合は) ローカル ノードに 25 GB の空き領域を確保することをお勧めします。

ログ設定を変更します。

使用して任意のログ設定を変更することができます、 Set-NetworkControllerDiagnostic コマンドレットです。 次の設定を変更できます。

• 一元的なログの場所。

  すべてのログを保存する場所を変更する、 DiagnosticLogLocation パラメーター。

• ログの場所にアクセスする資格情報。

  ログの場所を表示する資格情報を変更することができます、 LogLocationCredential パラメーター。

• ローカル ログへの移行。

  ログの保存先の一元的な場所を指定した場合、戻すことができますとネットワーク コント ローラーのノードのローカル ログインに、 UseLocalLogLocation パラメーター (大容量のディスク領域の要件によっては推奨されません)。

• ログ記録のスコープ。

  既定では、すべてのログが収集されます。 唯一のネットワーク コント ローラーがクラスター ログを収集するスコープを変更することができます。

• ログ記録レベル。

  既定のログ レベルは Informational です。 エラー、警告、または詳細を変更することができます。

• ログ エージング時間。

  ログは、循環形式で格納されます。 ローカル ログを使用するか、一元的なログを使用するかにかかわらず、既定で 3 日間のログ データが保持されます。 この制限時間は、 LogTimeLimitInDays パラメーターで変更できます。

• ログ エージング サイズ。

  既定では、ローカルのログを使用した場合は、集中ログと 25 GB を使用する場合、ログ データの場合は、最大 75 GB があります。 この制限を変更する、 LogSizeLimitInMBs パラメーター。

ログとトレースの収集

VMM の展開は、既定では、ネットワーク コント ローラーの集中ログを使用します。 これらのログのファイル共有の場所は、ネットワーク コント ローラーのサービス テンプレートを展開するときに指定します。

ファイルの場所が指定されていない場合は、各ネットワーク コントローラー ノードでローカル ログが使用され、ログは C:\Windows\tracing\SDNDiagnostics に保存されます。 これらのログは、次の階層を使用して保存されます。

• CrashDumps
• NCApplicationCrashDumps
• NCApplicationLogs
• PerfCounters
• SDNDiagnostics
• トレース

ネットワーク コント ローラーは、(Azure) の Service Fabric を使用します。 特定の問題のトラブルシューティングを行うときは、Service Fabric ログが必要になる場合があります。 これらのログは、 C:\ProgramData\Microsoft\Service Fabric の各ネットワーク コントローラー ノードにあります。

ユーザーが Debug-NetworkController コマンドレットを実行した場合、ネットワーク コントローラーのサーバー リソースで指定されている各 Hyper-V ホストで、さらに多くのログを使用できるようになります。 これらのログ (および有効な場合はトレース) は、 C:\NCDiagnostics の下に保持されます。

SLB 診断

SLBM ファブリック エラー (ホスティング サービス プロバイダーアクション)

1. ソフトウェア ロード バランサー マネージャー (SLBM) が機能していることと、オーケストレーションのレイヤー相互で通信できることを確認します: [SLBM] -> [SLB Mux と SLBM] -> [SLB ホスト エージェント]。 実行 DumpSlbRestState ネットワーク コント ローラーの REST エンドポイントにアクセス権を持つ任意のノードから。
2. ネットワーク コントローラー ノード VM の 1 つ (できればプライマリ ネットワーク コントローラー ノード - Get-NetworkControllerReplica) で PerfMon の SDNSLBMPerfCounters を検証します。
   1. ロード バランサー (LB) エンジンが SLBM に接続されているでしょうか。 (SLBM LBEngine Configurations Total > 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)。
3. 構成されている BGP ルーターが SLB MUX と正常にピアリングされていることを確認します。
   1. リモート アクセス (つまり BGP 仮想マシン) で RRAS を使用する場合:
      1. Get-BgpPeer 接続済みと表示されます。
      2. Get-BgpRouteInformation は、SLBM セルフ VIP のルートを少なくとも表示する必要があります。
   2. BGP ピアとして物理 Top-of-Rack (ToR) スイッチを使用する場合は、ドキュメントを参照してください。
      1. 例: # show bgp instance
4. SLB 多重化 VM 上の PerfMon の SlbMuxPerfCounters カウンターと SLBMUX カウンターを検証します。
5. ソフトウェア ロード バランサー マネージャー リソースの構成状態と 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 Multiplexers が接続されていることを確認します。
  • 証明書の問題を修正します。
  • ネットワーク接続の問題を修正する
• BGP ピアリング情報が正常に構成されていることを確認します。
• レジストリでのホスト ID がサーバー リソース内のサーバー インスタンスの ID と一致することを確認 (については、付録を参照 HostNotConnected エラー コード)
• ログの収集

SLBM テナント エラー (ホスティング サービス プロバイダーとテナント アクション)

1. [Hoster] Debug-NetworkControllerConfigurationState チェックして、LoadBalancer リソースがエラー状態であるかどうかを確認します。 次のアクション アイテム付録内のテーブルで軽減しようとしてください。
   1. VIP エンドポイントとアドバタイズ ルートが存在することを確認します。
   2. VIP エンドポイントで検出された DIP エンドポイントの数を確認します。
2. [テナント]Load Balancer リソースが正しく指定されていることを検証します。
   1. SLBM に登録されている DIP エンドポイントが、LoadBalancer バックエンド アドレス プールの IP 構成に対応するテナント仮想マシンをホストしていることを検証します。
3. [ホスト]DIP エンドポイントの検出または接続されていない: 場合

   1. Debug-NetworkControllerConfigurationState を確認する

      netstat -anp tcp |findstr 6640)を使用して、NC および SLB ホスト エージェントがネットワーク コントローラー イベント コーディネーターに正常に接続されていることを検証します。

   2. サービス regkey HostIdnchostagent確認します (付録のエラー コードHostNotConnected参照) が、対応するサーバー リソースのインスタンス ID (Get-NCServer |convertto-json -depth 8) と一致します。

   3. 仮想マシン のポートのポート プロファイル ID が、対応する仮想マシン NIC リソースのインスタンス ID と一致するかどうかを確認します。

4. [ホスティング プロバイダー]ログを収集します。

SLB 多重化トレース

ソフトウェア ロード バランサー Muxes からの情報は、イベント ビューアーからも判断できます。

1. イベント ビューアー View メニュー[Show Analytic and Debug Logs]\(分析ログとデバッグ ログの表示\) を選択します。
2. イベント ビューアーの Applications and Services Logs>Microsoft>Windows>SlbMuxDriver>Trace に移動します。
3. それを右クリックし、 [ログの作成]を選択します。

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