Guia de solução de problemas do Nexus 1000V no Hyper-V
Contents
Introduction
Este documento descreve os procedimentos usados para solucionar problemas de switches Cisco Nexus 1000V (N1KV) Series em servidores Microsoft (MS) Hyper-V. A implementação do Hyper-V é muito diferente da do ESXi, portanto, haverá alguns problemas encontrados com frequência; portanto, este documento foi criado.
Grande parte das informações descritas neste documento vem diretamente do NPI (Engineering New Product Introduction, Introdução de novo produto de engenharia) e de problemas encontrados durante o teste beta. Este documento é de natureza dinâmica e será atualizado em conformidade.
Prerequisites
Requirements
A Cisco recomenda que você tenha conhecimento destes tópicos:
- Switches N1KV Series
- Servidores MS Hyper-V
Componentes Utilizados
Este documento não se restringe a versões de software e hardware específicas.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Problemas do aplicativo de instalação
Há muitos problemas com o aplicativo Instalador, e esta seção descreve os mais comuns.
Use o aplicativo de instalação com cuidado
Aqui estão alguns motivos pelos quais você deve usar este aplicativo com cuidado:
- Ele não espera o suficiente para que o Virtual Supervisor Module (VSM) comece em várias plataformas e, frequentemente, falha.
- Ele move a interface de gerenciamento (mgmt) para um Switch lógico MS e não o informa, mesmo que você não queira mover a interface de gerenciamento.
- O switch lógico criado não pode usar uma interface agrupada. Isso significa que não há redundância para o switch ou para a interface mgmt.
- Você não pode simplesmente adicionar outra Placa de Interface de Rede (NIC) ao switch lógico para torná-lo agrupado; você deve criar um novo switch com uma interface agrupada e mover tudo para ter redundância.
- O aplicativo não reconhece se os hosts nos quais você instala os VSMs fazem parte de um cluster. Isso significa que os discos virtuais estão instalados no armazenamento local, não no armazenamento de cluster.
- O aplicativo cria um uplink de rede com um conjunto de redes do sistema. Cada segmento de rede deve ter uma rede de sistema definida. Este é um grande bug, portanto, esteja ciente disso.
Local do log do aplicativo de instalação
O aplicativo Instalador deve funcionar somente em ambientes de campo verde. Não tente usar o aplicativo em uma configuração estabelecida anteriormente. Para verificar se o instalador está com erros, navegue até C: > Users > <username> > AppData > Local > Temp > 2 > Nexus1000vInstaller_xxxxxxx.txt, e verifique o log.
O aplicativo de instalação migra a NIC de gerenciamento
O comportamento padrão (e somente) do aplicativo Instalador é exibir e usar a placa de rede física à qual a interface de gerenciamento está conectada. Ao executar o aplicativo Instalador, você só poderá escolher uma placa de rede - a placa de rede de gerenciamento.
O aplicativo Instalador:
- Cria um switch lógico MS
- Adiciona os dois hosts que têm VSMs ao switch lógico
- Migra a NIC de gerenciamento para uma nNIC virtual no switch lógico
- Adiciona as conexões de rede VSM a esse switch lógico
Esta imagem ilustra como um dos hosts agora tem um switch lógico MS atribuído e uma NIC virtual que transporta o tráfego de gerenciamento:
Você pode ver que o uplink está definido com Sem grupo de uplink quando você visualiza o switch lógico criado. Isso é um problema porque você não pode adicionar outra placa de rede ou uma placa de rede em grupo a esse switch. Você não tem permissão para alterar o tipo de Equipe quando o switch for criado. Além disso, o aplicativo de instalação não permite adicionar uma interface agrupada.
Para alterar o switch para o grupo, você deve removê-lo e adicioná-lo novamente com um conjunto de grupos. Isso é possível, mas tedioso. Você quer redundância, portanto, se não estiver agrupada, há um problema em potencial.
O switch lógico para gerenciamento e VSM não é criado em todos os switches
Esse é outro problema porque os VSMs estão vinculados somente a esses dois hosts. Portanto, a migração ao vivo e o Cisco Home-Agent (HA) estão limitados a dois hosts. Você tem a opção de migrar os outros hosts do Hyper-V para o switch lógico do MS criado, mas ele não é concluído automaticamente pelo aplicativo Instalador.
O aplicativo de instalação não utiliza armazenamento baseado em cluster
Quando as configurações da máquina virtual (VM) do VSM são criadas, a disponibilidade tem um valor de Baixo. O MS só permite que VMs com valores de disponibilidade de alta sejam incluídas no armazenamento baseado em cluster. Isso coloca as informações de VSM Virtual Disk (VD) e VM no armazenamento local do host Hyper-V. Novamente, isso limita a migração em tempo real e o HA para as VMs do VSM.
Problemas com a configuração do VSM que o aplicativo de instalação cria
O aplicativo Instalador cria uma configuração muito básica no VSM e importa parte dessa configuração para o System Center Virtual Machine Manager (SCVMM).
O aplicativo executa estas ações do lado N1KV:
- Cria uma rede lógica padrão
- Cria um pool de segmentos de rede padrão
- Cria uma rede de uplink padrão
- Cria um perfil de porta padrão eth com o pin mac do grupo de canais
- Cria um perfil de porta de veth padrão para sem restrição
- Cria um modelo de pool IP padrão
- Cria o switch lógico N1KV no SCVMM
O aplicativo não só cria essas configurações no VSM, como preenche essas informações no SCVMM quando cria o switch lógico.
O aplicativo funciona bem no aspecto de configuração, mas tem problemas com a rede de uplink. É assim que o uplink de rede é criado:
nsm network uplinkn1kv_uplink_network_1_VSM-install1
import port-profile n1kv_uplink_network_policy_VSM-install1
allow network segment pool n1kv_network_segment_pool_VSM-install1
native network segment n1kv_vmaccess_1_VSM-install1
system network uplink
publish network uplink
Há um uplink de rede do sistema, que causa um problema. Se você tiver um uplink com uplink de rede do sistema definido, todos os segmentos de rede e perfis de porta que usam esse uplink também deverão ser do sistema. Isso significa que você está limitado a 32 segmentos de rede que podem usar esse uplink.
Não está claro se isso é um problema, mas vamos mostrar um exemplo do que acontece se você criar um novo segmento de rede e um modelo de pool de IP para a VLAN 152:
VSM-install1(config)# nsm ip pool template vlan-152
VSM-install1(config-ip-pool-template)# ip address 192.168.152.2 192.168.152.253
VSM-install1(config-ip-pool-template)# network 192.168.152.0 255.255.255.0
VSM-install1(config-ip-pool-template)# default-router 192.168.152.1
VSM-install1(config)# nsm network segment segment-vlan-152
VSM-install1(config-net-seg)# switchport mode access
VSM-install1(config-net-seg)# switchport access vlan 152
VSM-install1(config-net-seg)# ip pool import template vlan-152
VSM-install1(config-net-seg)# member-of network segment pool n1kv_network_
segment_pool_VSM-install1
VSM-install1(config-net-seg)# publish network segment
VSM-install1(config-net-seg)#
Atualize a extensão SCVMM N1KV e adicione a rede VM ao segmento de rede que você criou. Ao tentar atribuir uma VM à nova rede VM, você recebe estes erros:
Error (12700)
Failed while applying switch port settings 'Ethernet Switch Port Profile Settings'
on switch 'n1kv_VSM-install1': A device attached to the system is not functioning.
(0x8007001F). Unknown error (0x8005)
Error (26908)
Virtual switch on host to which the virtual network adapter is to be connected
(n1kv_VSM-install1) is a non compliant logical switch instance
Esses erros são causados porque o uplink de rede transporta uma rede de sistema e o segmento de rede não. Você tem duas opções: crie um novo uplink de rede sem uma rede de sistema ou adicione uma rede de sistema ao novo segmento de rede.
O SCVMM não consegue se conectar ao VSM
A conectividade entre o VSM e o SCVMM é diferente com o Hyper-V do que com o ESXi. Na solução Hyper-V, o SCVMM se comunica com nossa API (Nexus 1000V). Isso significa que a conexão é estabelecida e mantida a partir do host SCVMM. Quando o comando show svs connection é usado no VSM, ele não mostra nada; não há conexão SVS nesta solução.
O SCVMM também pesquisa o VSM uma vez a cada trinta minutos. Isso significa que você deve forçar uma atualização se quiser ver as alterações do VSM aparecerem imediatamente no SCVMM.
Verifique se o provedor está instalado
O provedor do Hyper-V é semelhante ao plug-in do N1KV no ESXi. A diferença é que não há provedor único para cada VSM. Você só precisa executar a instalação do provedor uma vez. Isso preenche o SCVMM com as informações necessárias para entender como falar com o VSM.
O provedor não é específico para cada VSM. O fornecedor está registrado no Registro do Windows. Você pode procurar VSEM no registro ou navegar até este local:
Se você estiver em uma posição em que não possa excluir o provedor, poderá excluir a entrada no registro e reiniciar o serviço SCVMM.
Observe o local do módulo na entrada do registro. A DLL (Dynamic Loadable Library) do provedor deve ser instalada em c:\Program Files\Cisco\Nexus1000V, juntamente com um script powershell usado para instalar o provedor. Verifique se a DLL está presente.
Desinstale/reinstale o provedor com o painel de controle
Uma desinstalação do provedor é concluída por meio de uma desinstalação de programa do painel de controle do Hyper-V Server 2012. Para reinstalar o provedor, clique duas vezes no instalador do provedor.
Verifique a conformidade de extensão
Verifique se a extensão do provedor está ativa e em conformidade com o SCVMM. Navegue até Configurações > Provedores de configuração. Verifique se a extensão Cisco Systems Nexus 1000V está ativa. Isso significa que a extensão é usada pelo SCVMM.
Verificar a conectividade entre VSM e SCVMM
O SCVMM se comunica com o VSM, portanto, você deve solucionar problemas do host do SCVMM.
Verifique se:
- Você pode fazer ping no VSM a partir do host do SCVMM.
- Você pode navegar por um navegador da Web até a API (Application Programming Interface, Interface de programação de aplicativos) N1KV.
Se você não conseguir fazer ping no VSM, verifique os firewalls do Windows e verifique se há problemas de conectividade de rede. Não há requisito de que o VSM e o SCVMM estejam na mesma sub-rede.
Para verificar a API, use o Internet Explorer (IE) e navegue até a API REST do VSM com esta string: http://<vsm-ip>/api/n1kv.
Você deve receber esta saída:
Se você não puder acessar a API, verifique se:
- Não há proxies de Internet configurados no host SCVMM. O SCVMM herda proxies se eles estiverem definidos no IE. Verifique as Configurações de Internet no IE para verificar se um proxy está definido. Talvez seja necessário adicionar uma exceção para o VSM.
- O Servidor Web e a API estão acessíveis no VSM. Verifique se o servidor http está habilitado no VSM e se há firewalls ativados que bloqueiam o tráfego da porta 80.
Problemas do módulo Ethernet virtual (VEM)
O N1KV no Hyper-V usa apenas o controle L3. Não há como controlar o Hyper-V com o controle L2. O controle de configuração L3 no Hyper-V é muito mais fácil do que uma configuração semelhante no VMware. Não há necessidade de dedicar uma placa de rede ao VEM; o VSM se comunica diretamente com a NIC de gerenciamento do Hyper-V Server 2012. Não há nenhum requisito para que a placa de rede de gerenciamento seja conectada ao módulo VEM, o que significa que você não precisa de um perfil de porta de veth especial para o controle L3.
A instalação do VEM também é muito mais fácil. Não há componente do VMware Update Manager (VUM) com SCVMM. A capacidade de instalar componentes de extensão é integrada diretamente no SCVMM. Se o VEM não estiver instalado no host Hyper-V, o SCVMM copia e instala o VEM no host de destino do Hyper-V automaticamente. Se você quiser instalar manualmente o VEM, é um simples clique duplo do aplicativo instalador do VEM no host. A desinstalação também é um programa simples removido do Painel de controle.
O host Hyper-V não é instalado no N1KV
Um erro comum que você pode encontrar é que um host Hyper-V não é adicionado ao N1KV através do SCVMM. Há várias verificações que devem ser feitas para solucionar esse problema.
Aqui está um erro típico que você pode ver no SCVMM quando a instalação do VEM falha:
Verifique se há equipes de rede antigas no host Hyper-V
Pode haver um grupo antigo de outro N1KV no host Hyper-V. Em caso afirmativo, exclua a equipe antiga antes de adicionar o host ao N1KV. No host Hyper-V, execute o Powershell e insira o comando Get-NetSwitchTeam. Se um grupo antigo for exibido, você deverá removê-lo com o comando Remove-NetSwitchTeam.
PS C:\> Get-NetSwitchTeam
Name: HPV7b9901d8-70b8-4063-b60e-bcd6679384f7 <<<< Logical Switch name is ?HPV?
Members: Ethernet
PS C:\> Remove-NetSwitchTeam -Name HPV7b9901d8-70b8-4063-b60e-bcd6679384f7
A MTU (Maximum Transmission Unit, Unidade Máxima de Transmissão) das NICs e o N1KV não correspondem
As configurações de MTU no Hyper-V são definidas por NIC através das configurações da NIC. Quando você cria uma equipe, a MS exige que as configurações de MTU de todas as NICs da equipe sejam idênticas.
Há duas maneiras de definir e verificar as configurações de MTU. A primeira é através das configurações do adaptador de rede. A segunda maneira é usar o Powershell. Aqui está um exemplo que ilustra o uso do Powershell para obter e definir a configuração de MTU ao mesmo tempo:
PS C:\Program Files (x86)\cisco\Nexus1000V>
Get-NetAdapterAdvancedProperty -RegistryKeyword
*jumbo* -Name ?" | Set-NetAdapterAdvancedProperty
-RegistryValue
A nova configuração não funciona devido à configuração N1KV antiga/obsoleta
Você pode encontrar um problema em que há uma configuração N1KV antiga no host Hyper-V que não permite que ela seja adicionada à nova configuração. Geralmente, quando você exclui o N1KV antigo do SCVMM ou do Gerenciador do Hyper-V, ele limpa a configuração. Entretanto, pode haver um caso em que você deve verificar e excluir a antiga configuração N1KV do registro do host do Hyper-V.
Digite o comando Regedit e exclua a configuração N1KV neste local:
HKEY_LOCAL_MACHINE\SYSTEM > CurrentControlSet > Services > VMSMP >
Parameters >SwitchList
Depois de excluir a entrada do registro, limpe-a pelo Gerenciador do Hyper-V e reinicialize.
Os drivers necessários não foram encontrados
Você pode receber um erro de que os drivers ou MSI necessários não foram encontrados ao tentar adicionar um host Hyper-V ao N1KV. Aqui está um exemplo do erro na Janela Trabalhos:
Isso geralmente significa que o código VEM N1KV não existe no servidor SCVMM. O servidor SCVMM deve verificar a extensão que está instalada no host Hyper-V. Mesmo que o código VEM já esteja instalado no host Hyper-V, o instalador do VEM N1KV deve ser copiado para um diretório no servidor SCVMM.
Verifique se o instalador do VEM N1KV é copiado para C:\ProgramData\Switch Extension Drivers no servidor SCVMM. Se ele não existir, copie o arquivo no diretório e adicione o host do Hyper-V ao N1KV.
O módulo VEM não é exibido no VSM
Nesse caso, tudo parece funcionar no SCVMM, mas o módulo nunca aparece no VSM . É raro que isso aconteça com o Hyper-V, pois a configuração é tão simples. Quando isso acontece, há poucas coisas simples a tentar.
Reinicie o processo N1KV no host Hyper-V
Use o Gerenciador de Tarefas ou Serviços para reiniciar o processo N1KV no host Hyper-V que apresenta o problema.
Aqui está uma captura de tela do serviço N1KV no Gerenciador de Tarefas - clique com o botão direito do mouse nele e selecione Reiniciar:
A equipe do VEM não foi criada corretamente
Ao criar o switch lógico no SCVMM, você pode escolher Nenhum grupo ou equipe. Com o N1KV, você deve sempre escolher Team, mesmo que tenha apenas uma NIC conectada.
Aqui está uma captura de tela que ilustra onde definir a configuração do grupo para o switch lógico:
Todas as portas VETH são desativadas após uma reinicialização de host
O Hyper-V é muito capaz a este respeito; se perceber que as VMs estão ligadas e que a Administração emitiu uma reinicialização, ele pausa o estado das VMs e reinicializa. Quando o sistema volta a ficar on-line, ele tenta colocar as VMs novamente on-line o mais rápido possível. Isso pressupõe que você não migrou ao vivo todas as VMs do host antes da reinicialização.
O problema é que o Hyper-V coloca as VMs novamente on-line antes que o processo do VEM realmente seja iniciado. A solução alternativa é definir as VMs com um atraso de início automático. A Engenharia recomenda que um atraso de trinta segundos seja usado para permitir que o VEM e o VSM se comuniquem antes que o Hyper-V tente retomar/ligar todas as VMs.
Erro de Switch Compatível com Não Foi Possível Localizar
Quando você tenta criar ou mover uma VM para o N1KV, ou migrar uma VM ao vivo de um host para outro, você pode receber este erro:
Esta é uma mensagem de aviso mais do que e erro. Embora apareça como um erro na tela de trabalho, isso não indica que algo está seriamente quebrado. O problema é que o SCVMM tenta manter um estado de conformidade entre si, o VSM e o VEM. Por algum motivo, o SCVMM ocasionalmente pensa que o estado está fora de sincronia e determina que para certos hosts o N1KV não é compatível. A conformidade dos hosts individuais é monitorada em Fabric > Logical switches > <seu switch lógico N1KV>.
Clique no botão Hosts na faixa de opções na parte superior da tela:
Se o host não for compatível, você deve tentar corrigir o host. Selecione o host fora de conformidade e clique no botão Corrigir na parte superior da tela. Isso ativa o SCVMM para sincronizar os dados entre si, o VSM e o módulo VEM. Após alguns minutos, o estado é alterado para Compatível e você não vê nenhum erro.
Outros problemas e comandos úteis
Esta seção descreve vários problemas diversos e comandos úteis para o N1KV no Hyper-V.
O VSM não pode ser aninhado no Hyper-V
No momento, você não pode executar o VSM em um host Hyper-V aninhado. Ao contrário do ESXi, por alguma razão, o VSM não pode ser executado em um host virtual Hyper-V. A engenharia está ciente do problema, mas no momento ele é de baixa prioridade, portanto, esteja ciente dessa restrição. No entanto, você pode executar o VSM em um host ESXi aninhado, de modo que essa seja uma solução possível.
Enfileiramento de máquina virtual (VMQ)
A VMQ é quase idêntica à VMware Virtual Machine Device Queue (VMDQ). A VMQ exige que a placa de rede física suporte a VMQ. A placa de rede cria uma fila de rede para cada VM no sistema, o que permite que o tráfego de rede flua diretamente do hipervisor para a VM. Isso melhora o desempenho da rede para as VMs.
Comandos do Powershell usados para verificar o VMQ
Há dois comandos úteis usados para verificar as informações de VMQ através do Powershell no host Hyper-V:
- Get-NetAdapterVmq
- Get-NetAdapterVmqQueue
Uso de comandos Vemcmd para verificar a VMQ
Este é o comando principal usado para exibir informações sobre os VETHs para os quais as filas foram alocadas:
>vemcmd show vmq allocation
LTL VSM Port Phy LTL Queue id Team queue id
49 Veth13 17 1 49
18 2 49
50 Veth14 17 2 50
18 3 50
51 Veth16 19 1 51
20 1 51
Uso do Vemcmd para visualizar recursos do VMQ
Este comando exibe informações sobre NICs físicas habilitadas para VMQ:
>vemcmd show vmq resources
LTL VSM Port Max queues Free queues
17 Eth3/1 16 10
18 Eth3/2 16 10
19 Eth3/3 8 7
Comandos úteis do PowerShell
Há vários comandos do Powershell que inserem ou enviam dados para o VSM. Isso permite a instalação de scripts e a orquestração de VMs no N1KV. Ele também permite que você obtenha informações mais detalhadas que mostram relações entre os objetos SCVMM e N1KV.
Use o Powershell do SCVMM
Você deve garantir que use um Powershell que tenha os plug-ins do SCVMM. A maneira mais fácil de fazer isso é iniciar o Powershell a partir do console do SCVMM:
A classificação Get-SCPort Comando
Este comando é usado para visualizar o link entre uma classificação de porta SCVMM e o perfil de porta N1KV ao qual está vinculado:
PS C:\Users\Administrator.HYPERV> Get-SCPortClassification
Name : NexusNoRestrict-2
Description :
ServerConnection : Microsoft.SystemCenter.VirtualMachineManager.
Remoting.ServerConnection
ID : 9f8819c1-8b53-42bd-a6fd-0173804e3194
IsViewOnly : False
ObjectType : PortClassification
MarkedForDeletion : False
IsFullyCached : True
O Get-SCVirtualNetworkAdapterExtensionPortProfile Comando
Esse comando é usado para exibir informações sobre o perfil da porta de uplink:
PS C:\Users\Administrator.HYPERV> Get-SCVirtualNetworkAdapterExtensionPortProfile
Name : NoRest-unicast-norest
ExternalId : 308ad66b-7c42-4067-90af-13f7a6e59afe
NetworkEntityAccessType : ExternallyManaged
VirtualSwitchExtension : n1kv-test
Tags : {}
AllowedVNicType : Both
MaxNumberOfPorts : 32
MaxNumberOfPortsPerHost : 216
ProfileData : 0
ServerConnection : Microsoft.SystemCenter.VirtualMachineManager.
Remoting.ServerConnection
ID : 8934a01c-0cb7-4ee2-ae9d-21ff5b26568f
IsViewOnly : False
ObjectType : VirtualSwitchExtensionVirtualPortProfile
MarkedForDeletion : False
IsFullyCached : True
O comando Get-SCConfigurationProvider
Este comando é usado para visualizar informações sobre as Extensões de Provedor carregadas no servidor SCVMM:
PS C:\Users\Administrator.HYPERV> Get-SCConfigurationProvider
Name : Cisco Systems Nexus 1000V
Type : VirtualSwitchExtensionManager
Description : Provider for Cisco Systems Nexus 1000V
Virtual Switch Extension Manager
LatestVersion : 1.0
PublishDate :
Publisher : Cisco Systems, Inc.
Manufacturer : Cisco Systems, Inc.
Model : {Nexus 1000V}
Error :
ServerConnection : Microsoft.SystemCenter.VirtualMachineManager.
Remoting.ServerConnection
ID : 22a8f431-b5fe-4ee8-a0f5-9b5a99f723f2
IsViewOnly : False
ObjectType : ConfigurationProvider
MarkedForDeletion : False
IsFullyCached : True
Locais de Vemcmd e Vemlog
Os comandos VEM estão disponíveis em C: > Arquivos de programa (x86) > Cisco > Nexus1000V.
Verifique o inventário do adaptador físico através do registro
Para verificar a conectividade do adaptador físico com o N1KV no registro, acesse este local do registro:
- Colmeia do Registro: HKEY_LOCAL_MACHINE > SYSTEM > CurrentControlSet
- Chave do Registro: Serviços > Nexus1000V > Parâmetros > HostPhyAdapters
Não é possível excluir objetos N1KV devido ao modelo temporário
Você pode encontrar esse problema se tiver implementado modelos e criado VMs por meio do aplicativo Modelo de serviço SCVMM e tiver permitido que os usuários de autoatendimento criem suas próprias VMs. Este modelo temporário não é um objeto visível através do SCVMM. Você deve usar o SCVMM Powershell para excluir o modelo temporário com este comando:
Get-SCVMTemplate | where {$_.Name -like "Temporary*"} | Remove-SCVMTemplate
VMs atribuídas a N1KV recebem erros de conformidade de switch lógico
Às vezes, os erros de conformidade são apenas uma função da maneira como o SCVMM opera. O N1KV pode ser totalmente compatível com o SCVMM, mas você ainda recebe erros de conformidade.
Você também pode receber esta mensagem, onde não tem permissão para escolher ou modificar qualquer configuração de rede para uma VM:
Isso ocorre quando um dos nós do cluster MS tem problemas. O SCVMM descobre que todos os nós não estão em conformidade e não permite que você faça alterações até que você remova ou corrija o nó com o problema. Esse comportamento é esperado no SCVMM.
Para determinar qual nó tem problemas, use o SCVMM ou o Gerenciador de failover de cluster e corrija o nó com problema. Se não for possível corrigir o nó, você deverá removê-lo ou pausá-lo do cluster. Depois que isso for concluído, você poderá adicionar e modificar VMs ao N1KV.
Histórico de revisões
| Revisão | Data de publicação | Comentários |
|---|---|---|
1.0 |
01-Oct-2013 |
Versão inicial |
FeedbackContate a Cisco
- Abrir um caso de suporte
- (É necessário um Contrato de Serviço da Cisco)