Felsökningsvägledning för SDN

  • Artikel

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

Checklista för felsökning

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

  1. Get-ProviderAddress Kör kommandot på båda Hyper-V-värdarna som är värdar för de två berörda virtuella klientdatorerna (VM). Test-LogicalNetworkConnection Kör sedan eller ping -c <compartment> från Hyper-V-värden för att verifiera anslutningen i det logiska HNV-providernätverket.
  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ör 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 ett maximalt omkostnader på 160 byte.
  3. Om provideradresser (PA) inte finns eller om kundadressanslutningen (CA) är bruten kontrollerar du att 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. Kontrollera att nätverksstyrenhetens värdagent är ansluten till nätverksstyrenheten. Det gör du genom att köra netstat -anp tcp |findstr 6640.
  5. Kontrollera att värd-ID:t i registernyckeln HKLM 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 nterfaces för de virtuella klientdatorerna.

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

netstat Kör kommandot för att kontrollera att det finns tre upprättade anslutningar mellan nätverkskodningsvärdagenten (NC) och noderna för nätverksstyrenheten. Kontrollera också att det finns en lyssningssocket på Hyper-V-värden. Mer information finns i följande lista.

  • Port TCP:6640 lyssnar på Hyper-V-värd (NC-värdagenttjänst)
  • Två upprättade anslutningar från Hyper-V-värd-IP på port 6640 till NC-nod-IP på tillfälliga portar (portnumret är högre än 32 000)
  • En upprättad anslutning från Hyper-V-värd-IP på en tillfällig port 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älsotillstånd

Om det inte finns tre ETABLERADE anslutningar eller om nätverksstyrenheten inte svarar kontrollerar du 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>

Följande är nätverksstyrenhetstjänstmoduler:

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

Kontrollera att ReplicaStatus är klar och att HealthState är OK. I en produktionsdistribution som använder en nätverksstyrenhet med flera noder kan du också se vilken nod varje tjänst är primär på och kontrollera tjänstens enskilda replikstatus:

Get-NetworkControllerReplica

Kontrollera att replikstatusen är klar för varje tjänst.

Kontrollera stödet 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-inkapsling (eller NVGRE).

Kontrollera anslutningen för klientorganisationens virtuella datornä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-providerns adressutrymme (PA). Dessa mappningar sparas i OVSDB-servertabellerna på varje 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 ToR-växeln (Top-of-Rack) inte kan nås eller inte peering lyckas. Kontrollera BGP-inställningarna för både Software Load Balancer Multiplexer-resurs och BGP-peer (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. Se SLB-värdagentloggarna (körs automatiskt) för orsakerna. 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ärdens virtuella nätverkskort

Det här felet är ett TCP/IP-stackfel. Detta kan kräva att peer-autentisering (PA) och målregel (DR) värd Virtual Network gränssnittskort (VNICs) rensas på servern där det här felet rapporterades.

Felkod: PolicyConfigurationFailure

Felmeddelande:

  • Det gick inte att push-överföra vSwitch-principer för ett vm-nätverkskort (VmNic) på grund av certifikatfel eller anslutningsfel

  • Det gick inte att push-överföra brandväggsprinciper för ett VMNic på grund av certifikatfel eller anslutningsfel

  • Det gick inte att push-överföra principer för virtuella nätverk (VNet) 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 även 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örsbehörighet i det lokala systemet och licensavtalet måste godkännas (när licensavtalet har godkänts uppmanas inte TSS igen).
  2. Vi rekommenderar den lokala datorns RemoteSigned PowerShell-körningsprincip.

Obs!

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 går den tilldelade behörigheten för processnivån tillbaka till det tidigare konfigurerade tillståndet när det angivna PowerShell-fönstret där TSS-körningen har stängts.

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. Godkänn licensavtalet 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.

    Obs!

    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