Risolvere i problemi relativi allo stack di rete software defined di Windows Server
La presente guida esamina gli errori comuni di SDN (Software Defined Networking) e gli scenari di errore, descrivendo un flusso di lavoro di risoluzione dei problemi che ricorre agli strumenti di diagnostica disponibili. Per ulteriori informazioni su SDN, vedere Software Defined Networking.
Si applica a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Azure Stack HCI, versioni 21H2 e 20H2
L'elenco seguente rappresenta la classe di problemi più spesso riscontrati con Virtualizzazione rete Hyper-V (HNVv1) in Windows Server 2012 R2 dalle distribuzioni di produzione sul mercato. Da numerosi punti di vista, coincide con gli stessi tipi di problemi riscontrati in Windows Server 2016 HNVv2 con il nuovo stack SDN (Software Defined Network).
La maggior parte degli errori può essere classificata in un piccolo set di classi:
Configurazione non valida o non supportata
Un utente richiama l'API NorthBound in modo non corretto o con criteri non validi.
Errore nell'applicazione dei criteri
I criteri del controller di rete non sono stati recapitati a un host Hyper-V, ritardato o non aggiornato in tutti gli host Hyper-V, ad esempio dopo una migrazione in tempo reale.
Deviazione della configurazione o bug software
Problemi relativi al percorso dei dati che causano pacchetti eliminati.
Errore esterno correlato all'hardware/driver della scheda di interfaccia di rete o all'infrastruttura di rete sottostante
Offload di attività non correttamente comportate(ad esempio VMQ) o infrastruttura di rete insoded (ad esempio, MTU)Mishaving task offloads (ad esempio VMQ) or underlay network fabric misconfigured (ad esempio MTU)
La presente guida alla risoluzione dei problemi esamina ciascuna di queste categorie di errori e indica le procedure consigliate e gli strumenti di diagnostica disponibili per identificare e correggere l'errore.
Prima di discutere dei flussi di lavoro per la risoluzione dei problemi per ciascuno di questi tipi di errori, esaminare gli strumenti di diagnostica disponibili.
Per usare gli strumenti di diagnostica controller di rete (percorso di controllo), è necessario prima installare la RSAT-NetworkController
funzionalità e importare il NetworkControllerDiagnostics
modulo:
Add-WindowsFeature RSAT-NetworkController -IncludeManagementTools
Import-Module NetworkControllerDiagnostics
Per usare gli strumenti di diagnostica HNV (data-path), è necessario importare il modulo HNVDiagnostics
:
# Assumes RSAT-NetworkController feature has already been installed
Import-Module hnvdiagnostics
Questi cmdlet sono documentati in TechNet nel cmdlet Di diagnostica del controller di rete. Consentono di identificare i problemi relativi alla coerenza dei criteri di rete nel percorso di controllo tra i nodi del controller di rete e tra il controller di rete e gli agenti host NC in esecuzione negli host Hyper-V.
I Debug-ServiceFabricNodeStatus
cmdlet e Get-NetworkControllerReplica
devono essere eseguiti da una delle macchine virtuali del nodo Controller di rete. Tutti gli altri cmdlet di diagnostica NC possono essere eseguiti da qualsiasi host che disponga di connettività al controller di rete e che si trovi nel gruppo di sicurezza di gestione del controller di rete (Kerberos) o che abbia accesso al certificato X.509 per la gestione del controller di rete.
Questi cmdlet sono documentati in TechNet nel cmdlet Di diagnostica di virtualizzazione rete Hyper-V (HNV). Consentono di identificare i problemi nel percorso dati tra le macchine virtuali tenant (est/ovest) e il traffico in ingresso attraverso un indirizzo VIP del software di bilanciamento del carico (nord/sud).
Gli Debug-VirtualMachineQueueOperation
oggetti , Get-CustomerRoute
, Get-ProviderAddress
Get-PACAMapping
Get-VMNetworkAdapterPortId
, , Get-VMSwitchExternalPortId
, e Test-EncapOverheadSettings
sono tutti i test locali che possono essere eseguiti da qualsiasi host Hyper-V. Gli altri cmdlet richiamano i test del percorso dati tramite il controller di rete e devono quindi accedere al controller di rete, come descritto in precedenza.
Il repository GitHub Microsoft/SDN include numerosi script di esempio e flussi di lavoro basati su questi cmdlet predefiniti. In particolare, gli script di diagnostica sono disponibili nella cartella Diagnostica. L'utente può contribuire a questi script inviando richieste pull.
È presente una risorsa incorporata denominata Stato di configurazione in varie risorse del controller di rete. Lo stato di configurazione fornisce informazioni sull'integrità del sistema, inclusa la coerenza tra la configurazione del controller di rete e lo stato effettivo (in esecuzione) negli host Hyper-V.
Per controllare lo stato di configurazione, eseguire il comando seguente da qualsiasi host Hyper-V che dispone di connettività al controller di rete.
Nota
Il valore per il NetworkController
parametro deve essere il nome FQDN o l'indirizzo IP in base al nome soggetto del certificato X.509 >creato per Il controller di rete.
Il Credential
parametro deve essere specificato solo se il controller di rete usa l'autenticazione Kerberos (tipica nelle distribuzioni VMM). Le credenziali devono corrispondere a quelle di un utente che si trova nel gruppo di sicurezza di gestione del controller di rete.
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
Di seguito è riportato un messaggio di stato di configurazione di esempio:
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.
----------------------------------------------------------------------------------------------------------
Nota
Si è verificato un bug nel sistema in cui le risorse dell'interfaccia di rete per la scheda di interfaccia di rete della macchina virtuale di transito Mux del software di bilanciamento del carico si trovano in uno stato di errore con errore "Commutatore virtuale - Host non connesso al controller". Questo errore può essere ignorato in modo sicuro, se la configurazione IP nella risorsa della scheda di interfaccia di rete della macchina virtuale è impostata su un indirizzo IP dal pool IP della rete logica di transito.
Nel sistema è presente un secondo bug in cui le risorse dell'interfaccia di rete per le schede di interfaccia di rete della macchina virtuale del provider HNV del gateway si trovano in uno stato di errore con errore "Commutatore virtuale - PortBlocked". Questo errore può anche essere ignorato in modo sicuro, se la configurazione IP nella risorsa scheda di interfaccia di rete della macchina virtuale è impostata su Null (per impostazione predefinita).
La tabella seguente mostra l'elenco di codici di errore, di messaggi e di azioni di completamento da eseguire in base allo stato di configurazione osservato.
Codice | Messaggio | Azione |
---|---|---|
Sconosciuto | Errore sconosciuto | |
HostUnreachable | Il computer host non è raggiungibile | Controllare la connettività di rete di gestione tra controller di rete e host |
PAIpAddressExhausted | Gli indirizzi IP PA esauriti | Aumentare le dimensioni del pool IP della subnet logica del provider HNV |
PAMacAddressExhausted | Gli indirizzi Mac PA sono esauriti | Aumentare l'intervallo del pool Mac |
PAAddressConfigurationFailure | Impossibile eseguire il plumbing degli indirizzi PA all'host | Controllare la connettività di rete di gestione tra controller di rete e host. |
CertificateNotTrusted | Il certificato non è attendibile | Correggere i certificati usati per la comunicazione con l'host. |
CertificateNotAuthorized | Certificato non autorizzato | Correggere i certificati usati per la comunicazione con l'host. |
PolicyConfigurationFailureOnVfp | Errore durante la configurazione dei criteri VFP | Si tratta di un errore di runtime. Non esiste nessuna soluzione alternativa definita. Raccogliere i log. |
PolicyConfigurationFailure | Errore durante il push dei criteri negli host, a causa di errori di comunicazione o di altri errori in NetworkController. | Non esiste nessuna azione definita. Ciò è dovuto a un errore nell'elaborazione dello stato obiettivo nei moduli del Controller di rete. Raccogliere i log. |
HostNotConnectedToController | L'host non è ancora connesso al controller di rete | Il profilo di porta non è applicato all'host o l'host non è raggiungibile dal controller di rete. Verificare che la chiave del registro di sistema HostID corrisponda all'ID istanza della risorsa server |
MultipleVfpEnabledSwitches | Nell'host sono presenti più commutatori abilitati per VFp | Eliminare uno dei commutatori, poiché l'agente host controller di rete supporta un unico vSwitch con l'estensione VFP abilitata |
PolicyConfigurationFailure | Impossibile eseguire il push dei criteri di rete virtuale per una scheda di interfaccia di rete virtuale a causa di errori di certificato o di connettività | Controllare se sono stati distribuiti certificati appropriati (il nome soggetto del certificato deve corrispondere al nome FQDN dell'host). Verificare anche la connettività dell'host con il controller di rete |
PolicyConfigurationFailure | Impossibile eseguire il push dei criteri di vSwitch per una VmNic a causa di errori di connettività o di errori di connettività del certificato | Controllare se sono stati distribuiti certificati appropriati (il nome soggetto del certificato deve corrispondere al nome FQDN dell'host). Verificare anche la connettività dell'host con il controller di rete |
PolicyConfigurationFailure | Failed to push Firewall policies for a VmNic due to certificate errors or connectivity errors (Impossibile eseguire il push dei criteri del firewall per una VmNic a causa di errori di certificato o di connettività) | Controllare se sono stati distribuiti certificati appropriati (il nome soggetto del certificato deve corrispondere al nome FQDN dell'host). Verificare anche la connettività dell'host con il controller di rete |
DistributedRouterConfigurationFailure | Impossibile configurare le impostazioni del router distribuito nella vNic host | Errore dello stack TCPIP. Potrebbe essere necessario pulire le vNIC dell'host PA e DR nel server in cui è stato segnalato questo errore |
DhcpAddressAllocationFailure | Allocazione di indirizzi DHCP non riuscita per una VMNic | Controllare se l'attributo indirizzo IP statico è configurato nella risorsa NIC |
CertificateNotTrusted CertificateNotAuthorized |
Impossibile connettersi a Mux a causa di errori di rete o certificato | Controllare il codice numerico fornito nel codice del messaggio di errore: corrisponde al codice di errore winsock. Gli errori del certificato sono dettagliati (ad esempio, Non è possibile verificare il certificato, Certificato non autorizzato e così via) |
HostUnreachable | MUX non integro (il caso comune è BGPRouter disconnesso) | Il peer BGP nella RRAS (macchina virtuale BGP) o nel commutatore Top-of-Rack (ToR) non è raggiungibile o non è possibile eseguire correttamente il peering. Controllare le impostazioni BGP sia nella risorsa Multiplexer del software di bilanciamento del carico che nel peer BGP (ToR o macchina virtuale RRAS) |
HostNotConnectedToController | L'agente host del software di bilanciamento del carico non è connesso | Verificare che il servizio agente host del software di bilanciamento del carico sia in esecuzione; fare riferimento ai log dell'agente host del software di bilanciamento del carico (esecuzione automatica) alla ricerca dei possibili motivi, nel caso SLBM (NC) abbia rifiutato il certificato presentato dall'agente host che esegue lo stato verranno visualizzate informazioni sfumate |
PortBlocked | La porta VFP è bloccata, a causa della mancanza di criteri VNET/ACL | Controllare se sono presenti altri errori, che potrebbero causare la mancata configurazione dei criteri. |
Overloaded | MUX di loadbalancer è sottoposto a overload | Problemi di prestazioni con MUX |
RoutePublicationFailure | Loadbalancer MUX non è connesso a un router BGP | Controllare se MUX dispone di connettività con i router BGP e che il peering BGP sia configurato correttamente |
VirtualServerUnreachable | Loadbalancer MUX non è connesso al manager del software di bilanciamento del carico | Controllare la connettività tra SLBM e MUX |
QosConfigurationFailure | Impossibile configurare i criteri QOS | Verificare se è disponibile una larghezza di banda sufficiente per tutte le macchine virtuali se viene usata la prenotazione QOS |
Verificare la connettività di rete tra il controller di rete e l'host Hyper-V (servizio agente host NC)
Eseguire il netstat
comando seguente per verificare che siano presenti tre ESTABLISHED
connessioni tra l'agente host NC e i nodi del controller di rete e un LISTENING
socket nell'host Hyper-V.
- IN ASCOLTO sulla porta TCP:6640 nell'host Hyper-V (servizio agente host NC)
- Due connessioni stabilite dall'IP host Hyper-V sulla porta 6640 all'IP del nodo NC su porte temporanee (> 32000)
- Una sola connessione attiva dall'indirizzo IP dell'host Hyper-V su porta effimera all'indirizzo IP REST del controller di rete sulla porta 6640
Nota
In un host Hyper-V possono essere presenti solo due connessioni stabilite, se non sono presenti macchine virtuali tenant distribuite in questo host specifico.
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
Il controller di rete comunica con due servizi di agenti host sugli host Hyper-V: agente host SLB e agente host NC. È possibile che uno o entrambi questi servizi non siano in esecuzione. Controllare lo stato e riavviare, se non sono in esecuzione.
Get-Service SlbHostAgent
Get-Service NcHostAgent
# (Re)start requires -Force flag
Start-Service NcHostAgent -Force
Start-Service SlbHostAgent -Force
Se non sono presenti tre ESTABLISHED
connessioni o se il controller di rete non risponde, verificare che tutti i nodi e i moduli di servizio siano operativi usando i cmdlet seguenti.
# Prints a DIFF state (status is automatically updated if state is changed) of a particular service module replica
Debug-ServiceFabricNodeStatus [-ServiceTypeName] <Service Module>
I moduli del servizio del controller di rete sono:
- ControllerService
- ApiService
- SlbManagerService
- ServiceInsertion
- FirewallService
- VSwitchService
- GatewayManager
- FnmService
- HelperService
- UpdateService
Verificare che ReplicaStatus
sia Ready
e HealthState
sia Ok
.
In una distribuzione di produzione si usa un controller di rete multinodo, è anche possibile controllare il nodo in cui ogni servizio è primario e il relativo stato di replica singola.
Get-NetworkControllerReplica
# Sample Output for the API service module
Replicas for service: ApiService
ReplicaRole : Primary
NodeName : SA18N30NC3.sa18.nttest.microsoft.com
ReplicaStatus : Ready
Verificare che lo stato della replica sia Pronto per ciascun servizio.
Verificare la presenza di hostID e certificati corrispondenti tra il controller di rete e ogni host Hyper-V
In un host Hyper-V eseguire i cmdlet seguenti per verificare che HostID corrisponda all'ID istanza di una risorsa server nel controller di rete
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
Correzione
Se si usano script SDNExpress o distribuzione manuale, aggiornare la chiave HostId nel Registro di sistema in modo che corrisponda all'ID istanza della risorsa server. Riavviare l'agente host del controller di rete nell'host Hyper-V (server fisico). Se si usa VMM, eliminare il server Hyper-V da VMM e rimuovere la chiave HostId dal registro di sistema. Aggiungere quindi di nuovo il server tramite VMM.
Verificare che le identificazioni personali dei certificati X.509 utilizzati dall'host Hyper-V (il nome host sarà il nome soggetto del certificato) per la comunicazione (SouthBound) tra l'host Hyper-V (servizio agente host NC) e i nodi controller di rete siano le medesime. Verificare anche che il certificato REST del controller di rete abbia il nome soggetto di 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**
...
È anche possibile controllare i parametri seguenti di ogni certificato per assicurarsi che il nome del soggetto sia quello previsto (nome host o FQDN REST NC o IP), il certificato non è ancora scaduto e che tutte le autorità di certificazione nella catena di certificati siano incluse nell'autorità radice attendibile.
- Nome soggetto
- Data di scadenza
- Attendibile dall'autorità radice
Se più certificati hanno lo stesso nome soggetto nell'host Hyper-V, l'agente host controller di rete sceglierà in modo casuale uno da presentare al controller di rete. Questo potrebbe non corrispondere all'identificazione personale della risorsa server nota al controller di rete. In questo caso, eliminare uno dei certificati con lo stesso nome soggetto nell'host Hyper-V e quindi riavviare il servizio Agente host del controller di rete. Se non è ancora possibile stabilire una connessione, eliminare l'altro certificato con lo stesso nome soggetto nell'host Hyper-V ed eliminare la risorsa server corrispondente in VMM. Ricreare quindi la risorsa server in VMM, che genererà un nuovo certificato X.509 e lo installerà nell'host Hyper-V.
Lo stato di configurazione del bilanciamento del carico software può essere determinato come parte dell'output del Debug-NetworkController
cmdlet. Questo cmdlet restituisce anche il set corrente di risorse del controller di rete nei file JSON, tutte le configurazioni IP di ogni host Hyper-V (server) e i criteri di rete locali dalle tabelle di database dell'agente host.
Per impostazione predefinita, verranno raccolte altre tracce. Per non raccogliere tracce, aggiungere il -IncludeTraces:$false
parametro .
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
Nota
Il percorso di output predefinito sarà la directory <working_directory>\NCDiagnostics\ La directory di output predefinita può essere modificata usando il parametro -OutputDirectory
.
Le informazioni sullo stato di configurazione del software di bilanciamento del carico sono disponibili nel file diagnostics-slbstateResults.Json presente in questa directory.
Questo file JSON può essere suddiviso nelle sezioni seguenti:
- Infrastruttura
- SlbmVips: questa sezione elenca l'indirizzo IP dell'indirizzo VIP del manager del software di bilanciamento del carico, usato dal controller di rete per coordinare la configurazione e l'integrità tra i MUX del software di bilanciamento del carico e gli agenti host del software di bilanciamento del carico.
- MuxState: questa sezione elenca un valore per ogni Mux del software di bilanciamento del carico distribuito in modo da ottenere lo stato del mux
- Configurazione del router: questa sezione elenca il numero di sistema autonomo (ASN) del router upstream (BGP Peer), l'indirizzo IP di transito e l'ID. Elencherà anche l'ASN del MUX del software di bilanciamento del carico e l'indirizzo IP di transito.
- Informazioni sull'host connesso: questa sezione elenca l'indirizzo IP di gestione di tutti gli host Hyper-V disponibili per eseguire carichi di lavoro con carico bilanciato.
- Intervalli vip: questa sezione elenca gli intervalli di pool di indirizzi IP VIP pubblici e privati. L'indirizzo VIP SLBM verrà incluso come indirizzo IP allocato da uno di questi intervalli.
- Route Mux: questa sezione elenca un valore per ogni Mux del software di bilanciamento del carico contenente tutti gli annunci di route per quel particolare mux.
- Tenant
- VipConsolidatedState: questa sezione elenca lo stato di connettività per ogni indirizzo VIP tenant, incluso il prefisso di route annunciato, l'host Hyper-V e gli endpoint DIP.
Nota
Lo stato del software di bilanciamento del carico può essere verificato direttamente usando lo script DumpSlbRestState disponibile nel repository GitHub SDN Microsoft.
Dal controller di rete:
Get-NetworkControllerLogicalNetwork
Get-NetworkControllerPublicIPAddress
Get-NetworkControllerGatewayPool
Get-NetworkControllerGateway
Get-NetworkControllerVirtualGateway
Get-NetworkControllerNetworkInterface
Dalla macchina virtuale del gateway:
Ipconfig /allcompartments /all
Get-NetRoute -IncludeAllCompartments -AddressFamily
Get-NetBgpRouter
Get-NetBgpRouter | Get-BgpPeer
Get-NetBgpRouter | Get-BgpRouteInformation
Dall'interruttore top of rack (ToR):
sh ip bgp summary (for 3rd party BGP Routers)
Router BGP di Windows:
Get-BgpRouter
Get-BgpPeer
Get-BgpRouteInformation
Oltre a questi, dai problemi riscontrati finora (in particolare nelle distribuzioni basate su SDNExpress), il motivo più comune per cui il raggruppamento tenant non viene configurato nelle macchine virtuali GW sembra essere il fatto che la capacità GW in FabricConfig.psd1 è inferiore rispetto a ciò che gli utenti tentano di assegnare alle connessioni di rete (tunnel S2S) in TenantConfig.psd1. Questa operazione può essere verificata facilmente confrontando gli output dei cmdlet seguenti:
PS > (Get-NetworkControllerGatewayPool -ConnectionUri $uri).properties.Capacity
PS > (Get-NetworkControllerVirtualgatewayNetworkConnection -ConnectionUri $uri -VirtualGatewayId "TenantName").properties.OutboundKiloBitsPerSecond
PS > (Get-NetworkControllerVirtualgatewayNetworkConnection -ConnectionUri $uri -VirtualGatewayId "TenantName").property
Dopo aver distribuito il controller di rete, aver creato le reti virtuali tenant e le subnet ed aver collegato le macchine virtuali alle subnet virtuali, è possibile eseguire test aggiuntivi a livello di infrastruttura da parte dell'host per controllare la connettività del tenant.
Dopo che la prima macchina virtuale guest in esecuzione in un host Hyper-V è stata connessa a una rete virtuale tenant, il controller di rete assegnerà due indirizzi IP del provider HNV (indirizzi IP PA) all'host Hyper-V. Questi indirizzi IP provengono dal pool IP della rete logica del provider HNV e saranno gestiti dal controller di rete. Per scoprire quali sono questi due indirizzi IP HNV:
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
Questi indirizzi IP del provider HNV (IP PA) vengono assegnati alle schede Ethernet create in un raggruppamento di rete TCPIP separato e hanno un nome di scheda VLANX, dove X è la VLAN assegnata alla rete logica del provider HNV (trasporto).
La connettività tra due host Hyper-V tramite la rete logica del provider HNV può essere eseguita da un ping con un parametro aggiuntivo (-c Y), dove Y rappresenta il raggruppamento di rete TCPIP in cui vengono creati i PAhostVNIC. Questo raggruppamento può essere determinato eseguendo:
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> ...
Nota
Le schede vNIC dell'host PA non vengono usate nel percorso dati e pertanto non dispongono di un indirizzo IP assegnato alla "scheda vEthernet (PAhostVNic)".
Si supponga, ad esempio, che gli host Hyper-V 1 e 2 abbiano i seguenti indirizzi IP del provider HNV (PA):
Host Hyper-V | Indirizzo IP PA 1 | Indirizzo IP PA 2 |
---|---|---|
Host 1 | 10.10.182.64 | 10.10.182.65 |
Host 2 | 10.10.182.66 | 10.10.182.67 |
è possibile effettuare il ping tra i due indirizzi usando il comando seguente per controllare la connettività di rete logica del provider 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
Correzione
Se il ping del provider HNV non funziona, controllare la connettività di rete fisica, inclusa la configurazione VLAN. Le schede di interfaccia di rete fisiche di ogni host Hyper-V devono essere in modalità trunk, senza una specifica VLAN assegnata. La scheda di interfaccia di rete virtuale dell'host di gestione deve essere isolata nella VLAN della rete logica di gestione.
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> ...
Un altro problema comune nella rete logica del provider HNV è che le porte di rete fisiche e/o la scheda Ethernet non hanno una MTU sufficientemente grande configurata per gestire l'overhead dall'incapsulamento VXLAN (o NVGRE).
Nota
Alcune schede Ethernet e driver supportano la nuova *EncapOverhead
parola chiave che verrà impostata automaticamente dall'agente host controller di rete su un valore pari a 160. Tale valore verrà quindi aggiunto al valore della parola chiave *JumboPacket, la cui somma viene usata come MTU pubblicizzato.
Ad esempio, *EncapOverhead
= 160 e *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
Per verificare se la rete logica del provider HNV supporta le dimensioni end-to-end di MTU maggiori, usare il Test-LogicalNetworkSupportsJumboPacket
cmdlet :
# 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.
Correzione
- Regolare le dimensioni MTU sulle porte del commutatore fisico in modo che siano almeno di 1674B (incluse intestazioni Ethernet da 14B e trailer)
- Se la scheda NIC non supporta la parola chiave EncapOverhead, modificare la parola chiave JumboPacket in modo che sia almeno 1674B
Ogni scheda di interfaccia di rete della macchina virtuale assegnata a una macchina virtuale guest ha un mapping CA-PA tra l'indirizzo del cliente privato (CA) e lo spazio dell'indirizzo del provider HNV (PA). Questi mapping vengono mantenuti nelle tabelle del server OVSDB in ogni host Hyper-V e sono disponibili eseguendo il cmdlet seguente.
# 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
Nota
Se i mapping CA-PA previsti non vengono restituiti per una determinata macchina virtuale tenant, controllare la scheda di interfaccia di rete della macchina virtuale e le risorse di configurazione IP nel controller di rete usando il Get-NetworkControllerNetworkInterface
cmdlet . Controllare anche le connessioni stabilite tra l'agente host NC e i nodi del controller di rete.
Con queste informazioni, è ora possibile avviare un ping della macchina virtuale tenant da Hoster dal controller di rete usando il Test-VirtualNetworkConnection
cmdlet .
Le sezioni seguenti forniscono indicazioni per la risoluzione dei problemi relativi a scenari specifici.
- [Tenant] Assicurarsi che Windows Firewall non blocchi il traffico nelle macchine virtuali tenant.
- [Tenant] Verificare che gli indirizzi IP siano stati assegnati alla macchina virtuale tenant eseguendo
ipconfig
. - [Hoster] Eseguire
Test-VirtualNetworkConnection
dall'host Hyper-V per convalidare la connettività tra le due macchine virtuali tenant in questione.
Nota
VSID fa riferimento all'ID della subnet virtuale. Nel caso di VXLAN, si tratta dell'identificatore di rete VXLAN (VNI). È possibile trovare questo valore eseguendo il Get-PACAMapping
cmdlet .
$password = ConvertTo-SecureString -String "password" -AsPlainText -Force
$cred = New-Object pscredential -ArgumentList (".\administrator", $password)
Creare un ping CA tra "Green Web VM 1" con SenderCA IP di 192.168.1.4 nell'host "sa18n30-2.sa18.nttest.microsoft.com" con l'indirizzo IP Mgmt 10.127.132.153 verso l'IP ListenerCA 192.168.1.5 entrambi collegati alla subnet virtuale (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> ...
[Tenant] Verificare che nella subnet virtuale o nelle interfacce di rete della macchina virtuale non siano specificati criteri firewall distribuiti che bloccano il traffico.
Eseguire una query sull'API REST del controller di rete disponibile nell'ambiente demo di sa18n30nc nel dominio sa18.nttest.microsoft.com.
$uri = "https://sa18n30nc.sa18.nttest.microsoft.com"
Get-NetworkControllerAccessControlList -ConnectionUri $uri
Esaminare la configurazione IP e le subnet virtuali che fanno riferimento a questo elenco di controllo di accesso
- [Provider dei servizi di hosting] Eseguire
Get-ProviderAddress
in entrambi gli host Hyper-V che ospitano le due macchine virtuali tenant in questione e quindi eseguireTest-LogicalNetworkConnection
oping -c <compartment>
dall'host Hyper-V per convalidare la connettività nella rete logica del provider HNV - [Provider dei servizi di hosting] Assicurarsi che le impostazioni di MTU siano corrette negli host Hyper-V e su qualsiasi dispositivo di commutazione di livello 2 tra gli host Hyper-V. Eseguire
Test-EncapOverheadValue
in tutti gli host Hyper-V in questione. Verificare inoltre che tutte le opzioni di livello 2 tra abbiano MTU impostato su almeno 1674 byte per tenere conto dell'overhead massimo di 160 byte. - [Provider dei servizi di hosting] Se gli indirizzi IP PA non sono presenti e/o la connettività CA è interrotta, verificare che i criteri di rete siano stati ricevuti. Eseguire
Get-PACAMapping
per verificare se vengono stabilite correttamente le regole di incapsulamento e i mapping CA-PA necessari per la creazione di reti virtuali sovrapposte. - [Provider dei servizi di hosting] Verificare che l'agente host del controller di rete sia connesso al controller di rete. A tale scopo, eseguire
netstat -anp tcp |findstr 6640
. - [Provider dei servizi di hosting] Verificare che l'ID host in HKLM/ corrisponda all'ID dell'istanza delle risorse del server che ospitano le macchine virtuali tenant.
- [Provider dei servizi di hosting] Verificare che l'ID profilo porta corrisponda all'ID istanza delle interfacce di rete della macchina virtuale delle macchine virtuali tenant.
Le sezioni seguenti forniscono informazioni su diagnostica avanzata, registrazione e tracing.
Il controller di rete può raccogliere automaticamente i log del debugger e archiviarli in una posizione centralizzata. La raccolta di log può essere abilitata quando si distribuisce il controller di rete per la prima volta o in qualsiasi momento successivo. I log vengono raccolti dai controller di rete e dagli elementi di rete gestiti dal controller di rete: computer host, software di bilanciamento del carico (SLB) e computer gateway.
Questi log includono i log di debug per il cluster del controller di rete, l'applicazione del controller di rete, i log del gateway, il software di bilanciamento del carico, la rete virtuale e il firewall distribuito. Ogni volta che viene aggiunto un nuovo host/software di bilanciamento del carico/gateway al controller di rete, la registrazione viene avviata in tali computer. Analogamente, quando un host/software di bilanciamento del carico/gateway viene rimosso dal controller di rete, la registrazione viene arrestata in tali computer.
La registrazione viene abilitata automaticamente quando si installa il cluster controller di rete usando il Install-NetworkControllerCluster
cmdlet . Per impostazione predefinita, i log vengono raccolti localmente nei nodi del controller di rete in %systemdrive%\SDNDiagnostics. È consigliabile modificare questo percorso in modo che sia una condivisione file remota (non locale).
I log del cluster del controller di rete vengono archiviati in %programData%\Windows Fabric\log\Traces. È possibile specificare un percorso centralizzato per la raccolta di log con il DiagnosticLogLocation
parametro con la raccomandazione che si tratta anche di una condivisione file remota.
Se si vuole limitare l'accesso a questo percorso, è possibile fornire le credenziali di accesso con il LogLocationCredential
parametro . Se si specificano le credenziali per accedere al percorso del log, è necessario specificare anche il CredentialEncryptionCertificate
parametro , usato per crittografare le credenziali archiviate localmente nei nodi del controller di rete.
Con le impostazioni predefinite, è consigliabile avere almeno 75 GB di spazio libero nella posizione centrale e 25 GB nei nodi locali (se non si usa una posizione centrale) per un cluster controller di rete a tre nodi.
È possibile modificare le impostazioni di registrazione in qualsiasi momento usando il cmdlet Set-NetworkControllerDiagnostic
. È possibile modificare le impostazioni seguenti:
Percorso del log centralizzato.
È possibile modificare il percorso in modo da archiviare tutti i log, utilizzando il parametro
DiagnosticLogLocation
.Credenziali per accedere al percorso del log.
È possibile modificare le credenziali per accedere al percorso del log, utilizzando il parametro
LogLocationCredential
.Passare alla registrazione locale.
Se è stato specificato un percorso centralizzato per archiviare i log, è possibile tornare alla registrazione in locale nei nodi del controller di rete con il parametro
UseLocalLogLocation
(non consigliato a causa di requisiti di spazio su disco di grandi dimensioni).Ambito di registrazione.
Per impostazione predefinita, vengono raccolti tutti i log. È possibile modificare l'ambito per raccogliere solo i log del cluster del controller di rete.
Livello di registrazione.
Il livello di registrazione predefinito è Informazioni. È possibile modificarlo in Errore, Avviso o Dettagliato.
Durata del log.
I log vengono archiviati in modo circolare. Sono disponibili tre giorni di registrazione dei dati per impostazione predefinita, sia che si usi la registrazione locale o quella centralizzata. È possibile modificare questo limite di tempo con il
LogTimeLimitInDays
parametro .Dimensioni della durata del log.
Per impostazione predefinita, si avrà un massimo di 75 GB di dati di registrazione se si utilizza la registrazione centralizzata e 25 GB se si usa quella locale. È possibile modificare questo limite con il
LogSizeLimitInMBs
parametro .
Per impostazione predefinita, le distribuzioni VMM usano la registrazione centralizzata per il controller di rete. Il percorso della condivisione file per questi log viene specificato durante la distribuzione del modello di servizio del controller di rete.
Se non è stato specificato un percorso di file, la registrazione locale verrà usata in ogni nodo del controller di rete con i log salvati in C:\Windows\tracing\SDNDiagnostics. Questi log vengono salvati usando la gerarchia seguente:
- CrashDumps
- NCApplicationCrashDumps
- NCApplicationLogs
- PerfCounters
- SDNDiagnostics
- Tracce
Il controller di rete utilizza Service Fabric (Azure). I log di Service Fabric potrebbero essere necessari per la risoluzione di determinati problemi. Questi log sono disponibili in ogni nodo controller di rete in C:\ProgramData\Microsoft\Service Fabric.
Se un utente ha eseguito il Debug-NetworkController
cmdlet, saranno disponibili altri log in ogni host Hyper-V, specificato con una risorsa server nel controller di rete. Questi log (e le tracce, se abilitati) vengono mantenuti in C:\NCDiagnostics.
- Verificare che SLBM funzioni e che i livelli di orchestrazione possano comunicare tra loro: SLBM -> SLB Mux and SLBM -> SLB Host Agents. Eseguire DumpSlbRestState da qualsiasi nodo con accesso all'endpoint REST del controller di rete.
- Convalidare SDNSLBMPerfCounters in PerfMon in una delle macchine virtuali del nodo del controller di rete (preferibilmente il nodo del controller di rete primario -
Get-NetworkControllerReplica
):- Il motore del bilanciamento del carico (LB) è connesso a SLBM? (SLBM LBEngine Configurations Total > 0)
- SBM conosce almeno i propri endpoint? (VIP Endpoints Total>= 2)
- Gli host Hyper-V (DIP) sono connessi a SLBM? (HP clients connected == num servers)
- SLBM è connesso a Mux? (Muxes Connected == Muxes Healthy on SLBM == Muxes reporting healthy = # SLB Muxes VMs).
- Verificare che il router BGP configurato sia stato eseguito correttamente il peering con il MUX SLB.
- Se si usa RRAS con accesso remoto (ovvero, macchina virtuale BGP):
Get-BgpPeer
dovrebbe essere connesso.Get-BgpRouteInformation
dovrebbe mostrare almeno una route per l'indirizzo VIP self-SLBM.
- Se si usa il commutatore Top-of-Rack (ToR) fisico come peer BGP, consultare la documentazione:
- Ad esempio:
# show bgp instance
- Ad esempio:
- Se si usa RRAS con accesso remoto (ovvero, macchina virtuale BGP):
- Convalidare i contatori SlbMuxPerfCounters e SLBMUX in PerfMon nella macchina virtuale Mux SLB.
- Controllare lo stato di configurazione e gli intervalli VIP nella risorsa di Gestione bilanciamento del carico software.
Get-NetworkControllerLoadBalancerConfiguration -ConnectionUri <https://\<FQDN or IP>| convertto-json -depth 8
(controllare gli intervalli VIP nei pool IP e assicurarsi che l'indirizzo VIP self-VIP slBM (LoadBalanacerManagerIPAddress) e tutti gli indirizzi VIP rivolti al tenant si trovino all'interno di questi intervalli)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 -
Se uno dei controlli precedenti ha esito negativo, anche lo stato del software di bilanciamento del carico del tenant sarà in modalità di errore.
Correzione
In base alle informazioni di diagnostica seguenti presentate, correggere quanto segue:
- Verificare che i multiplexer SLB siano connessi
- Risolvere i problemi relativi al certificato
- Correggere i problemi di connettività di rete
- Verificare che le informazioni sul peering BGP siano configurate correttamente
- Verificare che l'ID host nel registro di sistema corrisponda all'ID istanza del server nella risorsa server (fare riferimento all'appendice per il codice errore HostNotConnected)
- Raccogliere i log
- [Hoster] Verificare
Debug-NetworkControllerConfigurationState
se le risorse loadBalancer sono in uno stato di errore. Provare a mitigare seguendo la tabella Attività presente nell'Appendice.- Verificare che un endpoint VIP sia presente e che le route pubblicitarie siano visualizzate.
- Controllare il numero di endpoint DIP individuati per l'endpoint VIP.
- [Tenant] Verificare che le risorse di Load Balancer siano specificate correttamente.
- Convalidare gli endpoint DIP registrati in SLBM ospitano macchine virtuali tenant, che corrispondono alle configurazioni IP del pool di indirizzi back-end di LoadBalancer.
- [Provider di servizi di hosting] Se gli endpoint DIP non vengono individuati o connessi:
Controllare
Debug-NetworkControllerConfigurationState
Verificare che il controller di rete e l'agente host SLB siano connessi correttamente al coordinatore eventi del controller di rete tramite
netstat -anp tcp |findstr 6640)
.Archiviare
HostId
la chiave regkey del servizio (codice di errore di riferimentoHostNotConnected
nell'Appendice) corrisponde all'ID istanza della risorsa server corrispondente (Get-NCServer |convertto-json -depth 8
).nchostagent
Controllare l'ID del profilo di porta per verificare che la porta della macchina virtuale corrisponda all'ID istanza della risorsa della scheda di interfaccia di rete della macchina virtuale corrispondente.
- [Provider di hosting] Raccogliere i log.
Le informazioni dei mux del software di bilanciamento del carico possono essere determinate anche tramite il Visualizzatore eventi.
- Selezionare Mostra log analitici e di debug nel menu Visualizza Visualizzatore eventi.
- Passare a Registri applicazioni e servizi di>Microsoft>Windows>SlbMuxDriver>trace in Visualizzatore eventi.
- Fare clic con il pulsante destro del mouse su di esso e selezionare Abilita log.
Nota
È consigliabile abilitare questa registrazione solo per un breve periodo di tempo durante il tentativo di riprodurre un problema.
Da qualsiasi host Hyper-V che ospita una macchina virtuale guest collegata a una rete virtuale tenant, è possibile raccogliere una traccia VFP per determinare dove possono trovarsi i problemi.
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