Dela via

Felsökningsvägledning för SDN

Det här avsnittet hjälper dig att felsöka scenarier för de SDN-tekniker (Software Defined Networking) som ingår i Windows Server 2019, Windows Server 2016 och Azure Stack HCI. De flesta användare brukar kunna lösa sitt problem med hjälp dessa lösningar.

Checklista för felsökning

Kontrollera IP-konfiguration och virtuella undernät som refererar till ACL:en

  1. Kör kommandot Get-ProviderAddress på båda Hyper-V-värdarna som är värdar för de två berörda virtuella klientdatorerna (VM). Verifiera anslutningen i det logiska HNV-providernätverket genom att sedan köra Test-LogicalNetworkConnection eller ping -c <compartment> från Hyper-V-värden.
  2. Kontrollera att MTU-inställningarna är korrekta på Hyper-V-värdarna och på alla Layer-2-växlingsenheter som finns mellan Hyper-V-värdarna. Körs Test-EncapOverheadValue på alla berörda Hyper-V-värdar. Kontrollera också om alla Layer-2-växlar mellan värdarna har MTU inställt på minst 1 674 byte för att ta hänsyn till en maximal belastning på 160 byte.
  3. Om provideradresser (PA) inte finns eller om kundadressanslutningen (CA) är bruten så kontrollera om nätverksprincipen har tagits emot. Kör Get-PACAMapping för att se om inkapslingsreglerna och CA-PA-mappningarna som krävs för att skapa virtuella överläggsnätverk är korrekt etablerade.
  4. Verifiera att nätverksstyrenhetens värdagent är ansluten till nätverksstyrenheten. Gör detta genom att köra netstat -anp tcp |findstr 6640.
  5. Kontrollera att värd-ID:t i HKLM-registernyckeln matchar instans-ID:t för de serverresurser som är värdar för de virtuella klientdatorerna.
  6. Kontrollera att portprofil-ID:t matchar instans-ID:t för det virtuella datornätverkets gränssnitt för de virtuella klientdatorerna.

Kontrollera nätverksanslutningen mellan nätverksstyrenheten och Hyper-V-värden

Kör kommandot netstat för att kontrollera om det finns tre etablerade anslutningar mellan nätverkskodningsagenten (NC) och nätverksstyrenhetsnoderna. Kontrollera också om det finns någon lyssningssocket på Hyper-V-värden. Mer information finns i följande lista.

  • Port TCP:6640 lyssnar på Hyper-V-värden (NC Host Agent Service)
  • Två etablerade anslutningar från Hyper-V-värd-IP-adressen på port 6640 till NC-nod-IP-adressen på tillfälliga portar (portnumret är högre än 32 000)
  • En upprättad anslutning från Hyper-V-värd-IP-adressen på den tillfälliga porten till nätverksstyrenhetens REST IP på port 6640

Kontrollera värdagenttjänster

Nätverksstyrenheten kommunicerar med två värdagenttjänster på Hyper-V-värdarna: SLB-värdagenten och NC-värdagenten. Det är möjligt att en eller båda av dessa tjänster inte körs. Kontrollera deras tillstånd och starta om dem om de inte körs:

Get-Service SlbHostAgent
Get-Service NcHostAgent

# Start
Start-Service NcHostAgent
Start-Service SlbHostAgent

Kontrollera nätverksstyrenhetens hälsa

Om det inte finns tre ETABLERADE anslutningar, eller om nätverksstyrenheten inte svarar, så kontrollera om alla noder och tjänstmoduler är igång:

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

De följande är nätverksstyrenhetstjänstmoduler:

  • ControllerService
  • ApiService
  • SlbManagerService
  • ServiceInsertion
  • FirewallService
  • VSwitchService
  • GatewayManager
  • FnmService
  • HelperService
  • UpdateService

Verifiera att ReplicaStatus är Redo och att HealthState är OK.. I en produktionsdistribution som använder en nätverksstyrenhet för flera noder kan du även se på vilken nod respektive tjänst är primär och kontrollera tjänstens enskilda replikstatus:

Get-NetworkControllerReplica

Verifiera att Replikstatus är Redo för varje tjänst.

Kontrollera stöd för MTU och Jumbo Frame i HNV-providerns logiska nätverk

Ett annat vanligt problem i det logiska HNV-providernätverket är att de fysiska nätverksportarna eller Ethernet-kortet inte har en tillräckligt stor MTU konfigurerad för att hantera omkostnaderna från VXLAN- eller NVGRE-inkapslingen.

Kontrollera anslutningen för den virtuella klientdatorns nätverkskort

Varje virtuellt datornätverkskort som har tilldelats till en virtuell gästdator har en CA-PA-mappning mellan den privata kundadressen (CA) och HNV-provideradressens (PA) utrymme. Dessa mappningar sparas i OVSDB-servertabellerna på respektive Hyper-V-värd. Du hittar dem genom att köra följande cmdlet:

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

Vanliga fel och lösningar baserat på konfigurationstillståndet

Felkod: HostUnreachable

Felmeddelande:

MUX är inte felfri (vanligt fall är BGPRouter frånkopplat)

Det här felet beror på att CBGP-peer (Credible Border Gateway Protocol) på RRAS-växeln (Routing and Remote Access Service) (BGP VM) eller Top-of-Rack (ToR) inte går att nå eller inte peering. Kontrollera BGP-inställningarna på både Software Load Balancer Multiplexer-resursen och BGP-peerdatorn (ToR eller RRAS VM).

Felkod: CertificateNotTrusted och CertificateNotAuthorized

Felmeddelande:

Det gick inte att ansluta till Mux på grund av nätverks- eller certifikatfel

Om du vill felsöka det här problemet kontrollerar du den numeriska kod som anges i felmeddelandekoden. Detta motsvarar winsock-felkoden. Certifikatfel är detaljerade. Certifikatet kan till exempel inte verifieras eller så är certifikatet inte auktoriserat.

Felkod: HostNotConnectedToController

Felmeddelande:

SLB-värdagenten är inte ansluten

Följ dessa steg för att felsöka det här problemet:

  1. Kontrollera att värdagenttjänsten för programlastbalanserare (SLB) körs.
  2. Information om orsakerna finns i SLB-värdagentloggarna (körs automatiskt). Om Software Load Balancer Manager (SLBM) (NC) avvisade certifikatet som presenterades av värdagenten kan körningstillståndet visa nyanserad information.

Felkod: DistributedRouterConfigurationFailure

Felmeddelande:

Det gick inte att konfigurera inställningarna för distribuerad router på värd-vNic

Det här felet är ett TCP/IP-stackfel. Detta kan kräva rensning av PA (Peer Authentication) och VNIC:er (Destination Rule (DR) Host Virtual Network Interface Cards) på den server där felet rapporterades.

Felkod: PolicyConfigurationFailure

Felmeddelande:

  • Det gick inte att skicka vSwitch-principer för ett nätverkskort för virtuella datorer (VmNic) på grund av certifikatfel eller anslutningsfel

  • Det gick inte att skicka brandväggsprinciper för ett VmNic på grund av certifikatfel eller anslutningsfel

  • Det gick inte att skicka principer för virtuellt nätverk för ett VmNic på grund av certifikatfel eller anslutningsfel

Om du vill felsöka det här problemet kontrollerar du om lämpliga certifikat har distribuerats. Certifikatets ämnesnamn måste matcha värdens FQDN. Kontrollera också värdanslutningen med nätverksstyrenheten.

Datainsamling

Innan du kontaktar Microsofts support kan du samla in information om problemet.

Förutsättningar

  1. TSS måste köras av konton med administratörsprivilegier i det lokala systemet, och serviceavtalet måste godkännas (när licensavtalet har godkänts uppmanas inte TSS igen).
  2. Vi rekommenderar den lokala datorns RemoteSigned PowerShell-körningsprincip.

Kommentar

Om den aktuella PowerShell-körningsprincipen inte tillåter körning av TSS vidtar du följande åtgärder:

  • RemoteSigned Ange körningsprincipen för processnivån genom att köra cmdleten PS C:\> Set-ExecutionPolicy -scope Process -ExecutionPolicy RemoteSigned.
  • Kontrollera om ändringen börjar gälla genom att köra cmdleten PS C:\> Get-ExecutionPolicy -List.
  • Eftersom behörigheterna på processnivå endast gäller för den aktuella PowerShell-sessionen, när det angivna PowerShell-fönstret där TSS körs stängs, återgår även den tilldelade behörigheten för processnivån till det tidigare konfigurerade tillståndet.

Samla in viktig information innan du kontaktar Microsofts support

  1. Ladda ned TSS på alla noder och packa upp den i mappen C:\tss.

  2. Öppna mappen C:\tss från en upphöjd PowerShell-kommandotolk.

  3. Starta spårningarna med hjälp av följande cmdlet:

    TSS.ps1 -Scenario NET_SdnNC

  4. Acceptera serviceavtalet om spårningarna körs för första gången på datorn.

  5. Tillåt inspelning (PSR eller video).

  6. Återskapa problemet innan du anger Y.

    Kommentar

    Om du samlar in loggar på både klienten och servern väntar du på det här meddelandet på båda noderna innan du återskapar problemet.

  7. Ange Y för att slutföra loggsamlingen när problemet har återskapats.

Spårningarna lagras i en zip-fil i mappen C:\MS_DATA , som kan laddas upp till arbetsytan för analys.

Referens

  • Last updated on