PDF(298.2 KB) Ver no Adobe Reader em vários dispositivos
ePub(95.8 KB) Ver em vários aplicativos no iPhone, iPad, Android, Sony Reader ou Windows Phone
Mobi (Kindle)(94.4 KB) Ver no dispositivo Kindle ou no aplicativo Kindle em vários dispositivos
Atualizado:6 de agosto de 2025
ID do documento:224027
Linguagem imparcial
O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.
Sobre esta tradução
A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização.
Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional.
A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
Este documento descreve como solucionar problemas de desempenho em roteadores corporativos C8000v em nuvens públicas e cenários ESXi.
Componentes Utilizados
As informações neste documento são baseadas nestes componentes de hardware e software:
C8000v executando a versão 17.12
ESXI Versão 7.0 U3
As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.
Troubleshooting Geral
Embora o C8000v possa ser hospedado em ambientes diferentes, ainda existem algumas etapas de solução de problemas que podem ser realizadas e que são idênticas, independentemente de onde o C8000v esteja hospedado. Vamos começar com os fundamentos. A primeira coisa que você precisa verificar é se o dispositivo está atingindo seus limites de capacidade ou não. Para isso, você pode começar verificando estas duas saídas:
1. show platform hardware qfp ative datapath util summary - esse comando fornece informações completas sobre a entrada/saída que o C8000v está recebendo e transmitindo de cada porta. Você deve concentrar sua atenção na porcentagem de carga de processamento. Se você estiver em um cenário em que está atingindo 100%, isso significa que você está atingindo o limite de capacidade
------------------ show platform hardware qfp active datapath utilization summary ------------------
CPP 0: 5 secs 1 min 5 min 60 min
Input: Total (pps) 93119 92938 65941 65131
(bps) 997875976 1000204000 708234904 699462016
Output: Total (pps) 93119 92949 65944 65131
(bps) 1052264704 1054733128 746744264 737395744
Processing: Load (pct) 14 14 10 10
2. show platform hardware qfp ative datapath infrastructure sw-cio - Pense neste comando como uma versão mais detalhada da versão acima. Ele fornece mais detalhes sobre os núcleos individuais, incluindo os núcleos de E/S e de criptografia que não fazem parte do número de utilização do QFP. É muito útil em um cenário em que você deseja ver se um núcleo de plano de dados específico está causando um gargalo.
Tip: Um detalhe muito importante ao usar este comando, sempre execute-o duas vezes. À medida que calcula a porcentagem de utilização do núcleo entre o momento em que o comando foi executado.
Agora, você determinou se está atingindo o limite da plataforma ou não. A próxima etapa seria verificar se há quedas. Eles estão inerentemente conectados a problemas de desempenho. Há três tipos de quedas que podem ser considerados, dependendo de onde estejam ocorrendo.
Superações: Esse tipo de queda de pacote ocorre na extremidade Rx. Eles ocorrem porque a capacidade de processamento de um ou mais núcleos foi excedida.
Quedas de recursos: Esse tipo de queda de pacote ocorre no PPE. Eles estão relacionados aos recursos do roteador, como uma ACL ou QoS.
Quedas de energia: Esse tipo de queda de pacote ocorre na extremidade Tx. Elas acontecem devido ao congestionamento nos buffers de Tx.
Para identificar quais descartes você está experimentando, você pode usar estas saídas:
show platform hardware qfp ative drop state clear
show interface
show policy map interface
Você verifica como identificar quais descartes você está enfrentando e como reduzi-los. No entanto, o foco maior neste artigo será nos descartes conhecidos como Taildrops, pois eles são particularmente difíceis de solucionar em roteadores virtuais.
Overruns
Uma queda de saturação no Cisco IOS XE ocorre quando a interface de rede recebe pacotes mais rápido do que pode processá-los ou armazená-los em seu buffer. Especificamente, os buffers internos das interfaces (fila FIFO) ficam cheios porque a taxa de dados de entrada excede a capacidade do hardware de manipulá-los. Como resultado, novos pacotes de entrada não podem ser armazenados e são descartados, o que incrementa o contador de saturação. Isso é essencialmente uma perda de pacotes causada pela sobrecarga temporária da interface.
Esse tipo de descarte de pacote ocorre na extremidade Rx. Eles acontecem porque a capacidade de processamento de um ou mais núcleos foi excedida e o thread Rx é incapaz de distribuir pacotes de entrada para o thread PP relevante e os buffers de entrada já estão cheios. Para fazer uma simples analogia, você pode pensar nela como uma fila em um caixa que fica muito cheia porque os pacotes estão chegando mais rápido do que o caixa (hardware de interface) pode atendê-los. Quando a fila está cheia, os novos clientes precisam sair sem serem atendidos - esses são os pontos de sobrecarga.
Embora o hardware seja mencionado nesta seção, o C8000v é um roteador baseado em software. Neste caso, as derrapagens podem ser causadas por:
Alta utilização do plano de dados: Se a utilização do plano de dados for alta, os pacotes não poderão ser interrogados com a rapidez necessária, levando a sobrecargas. Por exemplo, a presença de "fluxos de elefantes" (fluxos de dados grandes e contínuos) pode saturar os recursos de processamento e causar saturações nas interfaces.
Modelo de dispositivo incorreto: O uso de um modelo de dispositivo inadequado pode resultar em gerenciamento ineficiente de buffer e saturações. Isso pode ser verificado com o comando show platform software cpu alloc e pode ser alterado com o comando platform resource <template>.
Cada interface recebe um conjunto limitado de créditos, esse mecanismo impede uma interface ocupada e sobrecarrega os recursos do sistema. Cada vez que um novo pacote chega ao dataplane, um crédito é necessário. Quando o processamento do pacote estiver concluído, o crédito será retornado para que o thread Rx possa usá-lo novamente. Se não houver crédito disponível para a interface, o pacote precisará aguardar no anel Rx da interface. Em geral, você espera que as quedas relacionadas ao limite de desempenho sejam saturações de Rx porque a capacidade de processamento de um ou mais núcleos foi excedida.
Para identificar saturações, você normalmente verifica as estatísticas da interface em busca de erros de entrada, especificamente o contador de saturação:
Use o comando show platform hardware qfp ative datapath infrastructure sw-cio para identificar a utilização principal e se o número de créditos para uma interface específica tiver sido excedido.
Use o comando show interface <interface-name> e procure a contagem de saturação na saída.
As saturações são mostradas como parte dos erros de entrada, por exemplo:
Gig2 is up, line protocol is up 241302424557 packets input, 168997587698686 bytes, 0 no buffer 20150 input errors, 0 CRC, 0 frame, 20150 overrun, 0 ignored <<<<<<<<<<<
Vamos supor um caso em que Gig2 está observando problemas de desempenho causados por saturações. Para determinar o thread de trabalho associado a esta interface, você pode usar este comando:
#show platform hardware qfp active datapath infra binding Port Instance Bindings:
ID Port IOS Port WRKR 2 1 rcl0 rcl0 Rx+Tx 2 ipc ipc Rx+Tx 3 vxe_punti vxe_puntif Rx+Tx 4 Gi1 GigabitEthernet1 Rx+Tx 5 Gi2 GigabitEthernet2 Rx+Tx <<< in this case, WRKR2 is the thread responsible for both Rx and Tx
Em seguida, você pode analisar a utilização do segmento específico responsável pelo tráfego Rx dessa interface e seu número de créditos.
Em um cenário em que o Gig2 está observando problemas de desempenho devido a saturações, você pode esperar que o PP#2 seja constantemente totalmente utilizado (Ocioso = 0%) e créditos baixos/zero para a interface Gig2:
#show platform hardware qfp active datapath infrastructure sw-cio Credits Usage:
Core Utilization over preceding 1.0047 seconds ---------------------------------------------- ID: 0 1 2 % PP: 0.77 0.00 0.00 % RX: 0.00 0.00 0.44 % TM: 0.00 0.00 5.63 % IDLE: 99.23 99.72 93.93 <<< the core ID relevant in this case would be PP#2
Quedas de recursos
Os pacotes são tratados por qualquer thread de plano de dados disponível e são distribuídos estritamente com base na disponibilidade de núcleos QFP através da função Rx do software (x86) - Distribuição Baseada em Carga (LBD). Os pacotes que chegam no PPE podem ser descartados com uma razão de descarte QFP específica, que pode ser verificada usando esta saída:
#show drops
------------------ show platform hardware qfp active statistics drop detail ------------------
Last clearing of QFP drops statistics : never
--------------------------------------------------------------------------------
ID Global Drop Stats Packets Octets
--------------------------------------------------------------------------------
319 BFDoffload 403 31434
139 Disabled 105 7487
61 Icmp 135 5994
94 Ipv4NoAdj 1 193
33 Ipv6NoRoute 2426 135856
215 UnconfiguredIpv4Fia 1937573 353562196
216 UnconfiguredIpv6Fia 8046173 1057866418
------------------ show platform hardware qfp active interface all statistics drop_summary ------------------
----------------------------------------------------------------
Drop Stats Summary:
note: 1) these drop stats are only updated when PAL
reads the interface stats.
2) the interface stats include the subinterface
Interface Rx Pkts Tx Pkts
---------------------------------------------------------------------------
GigabitEthernet1 9980371 0
GigabitEthernet2 4012 0
As razões para as gotas são diversas e geralmente são autoexplicativas. Para investigar mais, um rastreamento de pacote pode ser usado.
Taildrops
Como foi mencionado antes, as quedas de cauda ocorrem onde o dispositivo está tentando transmitir pacotes, mas os buffers de transmissão estão cheios.
Nesta subseção, você examinará quais saídas podem ser examinadas diante desse tipo de situação. Quais valores você pode ver neles significam e o que você pode fazer para mitigar o problema.
Primeiro, você precisa saber como identificá-los. Uma dessas maneiras é simplesmente observar o show interface. Fique atento a qualquer queda de saída que aumente:
GigabitEthernet2 is up, line protocol is up Hardware is vNIC, address is 0050.56ad.c777 (bia 0050.56ad.c777) Description: Connected-To-ASR Cloud Gateway Internet address is 10.6.255.81/29 MTU 1500 bytes, BW 10000000 Kbit/sec, DLY 10 usec, reliability 255/255, txload 2/255, rxload 3/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full Duplex, 10000Mbps, link type is force-up, media type is Virtual output flow-control is unsupported, input flow-control is unsupported ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:00, output 00:00:00, output hang never Last clearing of "show interface" counters 03:16:21 Input queue: 0/375/0/0 (size/max/drops/flushes); Total output drops: 7982350 <<<<<<<< Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 150449000 bits/sec, 20461 packets/sec 5 minute output rate 89116000 bits/sec, 18976 packets/sec
Esse comando é particularmente útil para entender se você está passando por congestionamento ou não:
show platform hardware qfp ative datapath infrastructure - HQF significa ‘Hierarchical Queueing Framework`. Este é um recurso que permite o gerenciamento da Qualidade de Serviço (QoS - Quality of Service) em diferentes níveis (físico, lógico e de classe) usando a interface de linha de comando QoS modular (MQC - QoS Command-Line Interface). Ele mostra os custos atuais de RX e TX. Quando a fila TX está cheia, como mostra a saída (full 1959)
A saída sugere que o hardware subjacente não está acompanhando o envio de pacotes. Para depurar a interface subjacente, você precisa potencialmente olhar para fora do C8000v e para o ambiente subjacente em que o C8000v está sendo executado para ver se há erros adicionais relatados nas interfaces físicas subjacentes.
Para verificar o ambiente, há uma etapa que você pode executar antes de verificar em qual hipervisor o roteador C8000v está sendo executado. Isso serve para verificar a saída do comando show controller. No entanto, você pode se ver perdido no que cada contador significa ou onde olhar.
Primeiro, um detalhe importante que você precisa ter em mente ao observar essa saída é que as informações são originadas principalmente dos próprios vNICs. Cada driver NIC tem um conjunto específico de contadores que eles usam, que podem variar naturalmente de acordo com o driver. Hipervisores diferentes têm algum tipo de efeito sobre o que é apresentado também. Alguns contadores, como os contadores mbuf, são estatísticas do driver DPDK. Eles podem variar de acordo com os diferentes drivers DPDK. A contagem real geralmente é feita pelo hipervisor na camada de virtualização.
Dedique um minuto aqui para saber como interpretar e ler estes contadores:
Se você vir subX, significa que é uma sub-interface - uma divisão lógica da interface principal. O sub0 é geralmente o principal/padrão. Eles são frequentemente usados quando várias VLANs estão envolvidas.
Em seguida, você terá "rx = recebendo" e "tx = transmitindo".
Finalmente, q0 refere-se à primeira fila/padrão usada por essa interface
Embora não haja uma descrição para cada contador, o artigo descreve alguns deles, que podem ser relevantes para a solução de problemas:
"RX_MISSED_ERRORS:" é visto quando o buffer da NIC (Rx FIFO) fica sobrecarregado. Essa condição leva a quedas e um aumento na latência. Uma possível solução para isso é aumentar o buffer da placa de rede (o que é impossível no nosso caso) ou alterar o driver da placa de rede.
"tx_q0_drop_total" e "tx_q0_tx_ring_full": Eles podem dizer que o host está descartando pacotes, e o C8000v está experimentando quedas de cauda no C8000v porque o host está pressionando novamente o C8000v
Na saída acima, não vemos nenhum "rx_missing_errors". No entanto, como estamos nos concentrando em taildrops, vemos "tx_q0_drop_total" e "tx_q0_tx_ring_full". Com isso, podemos concluir que há realmente um congestionamento causado pelo hardware subjacente do host.
Como mencionado anteriormente, cada hipervisor tem algum tipo de efeito sobre o que é apresentado. O artigo aborda isso na próxima seção, à medida que aborda as diferenças entre os diferentes hipervisores onde o C8000v pode ser hospedado. Você também pode encontrar as diferentes recomendações para tentar atenuar esse tipo de problema em cada uma delas.
Hipervisores
Um hipervisor é uma camada de software que permite que vários sistemas operacionais (chamados de máquinas virtuais ou VMs) sejam executados em um único host de hardware físico, gerenciando e alocando os recursos de hardware, como CPU, memória e armazenamento, para cada VM. Ele garante que essas máquinas virtuais operem de forma independente, sem interferir umas nas outras.
No contexto do Cisco Catalyst 8000V (C8000v), o hipervisor é a plataforma que hospeda a máquina virtual do C8000v. Como descobrir qual hipervisor está hospedando seu C8000v? Há uma saída bastante útil que nos dá essas informações. Além disso, você também pode verificar a que tipo de recursos nosso roteador virtual tem acesso:
C8000v#show platform software system all Processor Details ================= Number of Processors : 8 Processor : 1 - 8 vendor_id : GenuineIntel cpu MHz : 2593.906 cache size : 36608 KB Crypto Supported : Yes model name : Intel(R) Xeon(R) Platinum 8272CL CPU @ 2.60GHz
VNIC Details ============ Name Mac Address Driver Name Status Platform MTU GigabitEthernet1 0022.480d.7a05 net_netvsc UP 1500 GigabitEthernet2 6045.bd69.83a0 net_netvsc UP 1500 GigabitEthernet3 6045.bd69.8042 net_netvsc UP 1500
Hypervisor Details =================== Hypervisor: AZURE Manufacturer: Microsoft Corporation Product Name: Virtual Machine Serial Number: 0000-0002-0201-5310-5478-4052-71 UUID: 8b06091c-f1d3-974c-85a5-a78dfb551bf2 Image Variant: None
VMware ESXi
O ESXi é um hipervisor tipo 1 desenvolvido pela VMware que é instalado diretamente em servidores físicos para permitir a virtualização. Ele permite que várias máquinas virtuais (VMs) sejam executadas em um único servidor físico abstraindo os recursos de hardware e alocando-os a cada VM. O roteador C8000v é uma dessas VMs.
Você pode começar analisando um cenário comum em que o congestionamento está ocorrendo. Isso pode ser confirmado verificando-se o contador tx_q0_tx_ring_full:
Exemplo:
------------------ show platform software vnic-if interface-mapping ------------------
------------------------------------------------------------- Interface Name Driver Name Mac Addr ------------------------------------------------------------- GigabitEthernet3 net_vmxnet3 <-- 0050.5606.2239 GigabitEthernet2 net_vmxnet3 0050.5606.2238 GigabitEthernet1 net_vmxnet3 0050.5606.2237 -------------------------------------------------------------
Esse congestionamento ocorre quando o C8000V tenta enviar pacotes através da interface VMXNET3. No entanto, o anel de buffer já está cheio de pacotes, que acabam em atrasos ou quedas.
Nessas condições, essas quedas estão acontecendo no lado do hipervisor, como mencionamos antes. Se todas as recomendações forem atendidas, é recomendável consultar o suporte da VMware para entender o que está acontecendo na placa de rede.
Aqui estão algumas sugestões sobre como melhorar o desempenho:
Use um vSwitch e um uplink dedicados para obter o desempenho ideal
Ao atribuir o C8000V a um vSwitch dedicado apoiado por seu próprio uplink físico, podemos isolar seu tráfego de vizinhos ruidosos e evitar gargalos de recursos compartilhados.
Há alguns comandos que valem a pena observar no lado do ESXi. Por exemplo, para verificar a perda de pacotes da interface ESXi, podemos fazer o seguinte:
Ative o SSH.
Conecte-se ao ESXi usando SSH.
Execute esxtop.
Digite n.
O comando esxtop pode mostrar pacotes descartados no switch virtual se o driver de rede da máquina virtual ficar sem memória de buffer Rx. Mesmo que esxtop mostre os pacotes como descartados no switch virtual, eles são realmente descartados entre o switch virtual e o driver do sistema operacional convidado.
Procure qualquer pacote descartado em %DRPTX e %DRPRX:
12:34:43pm up 73 days 16:05, 907 worlds, 9 VMs, 53 vCPUs; CPU load average: 0.42, 0.42, 0.42
Este comando lista todas as NICs configuradas em um host:
esxcli network nic list Name PCI Device Driver Admin Status Link Status Speed Duplex MAC Address MTU Description ------ ------------ ------ ------------ ----------- ----- ------ ----------------- ---- ----------- vmnic0 0000:01:00.0 igbn Up Up 1000 Full fc:99:47:49:c5:0a 1500 Intel(R) I350 Gigabit Network Connection vmnic1 0000:01:00.1 igbn Up Up 1000 Full fc:99:47:49:c5:0b 1500 Intel(R) I350 Gigabit Network Connection vmnic2 0000:03:00.0 ixgben Up Up 1000 Full a0:36:9f:1c:1f:cc 1500 Intel(R) Ethernet Controller 10 Gigabit X540-AT2 vmnic3 0000:03:00.1 ixgben Up Up 1000 Full a0:36:9f:1c:1f:ce 1500 Intel(R) Ethernet Controller 10 Gigabit X540-AT2
Há também um comando útil para verificar o status do vNIC atribuído a uma VM específica.
Observando o c8kv-gw-mgmt , que é uma VM do C8000v, há duas redes atribuídas:
c8kv-to-9200l
c8kv-para-cisco
Você pode usar a ID mundial para procurar mais informações sobre esta VM:
[root@localhost:~] esxcli network vm port list -w 2101719 Port ID: 67108890 vSwitch: vSwitch-to-9200L Portgroup: c8kv-to-9200l DVPort ID: MAC Address: 00:0c:29:31:a6:b6 IP Address: 0.0.0.0 Team Uplink: vmnic1 Uplink Port ID: 2214592519 Active Filters:
Port ID: 100663323 vSwitch: vSwitch-to-Cisco Portgroup: c8kv-to-cisco DVPort ID: MAC Address: 00:0c:29:31:a6:ac IP Address: 0.0.0.0 Team Uplink: vmnic0 <---- Uplink Port ID: 2248146954 Active Filters: [root@localhost:~]
Depois de obter essas informações, você pode identificar a qual rede o vSwitch está atribuído.
Para verificar algumas estatísticas de tráfego da NIC física atribuída ao vSwitch, temos este comando:
# esxcli network nic stats get -n <vmnic>
Esse comando exibe informações como pacotes recebidos, bytes recebidos, pacotes descartados e erros recebidos. Isso pode ajudar a identificar se há quedas acontecendo na placa de rede.
Há algumas configurações a serem verificadas que podem melhorar o desempenho do Cisco Catalyst 8000V executado em um ambiente ESXi modificando as configurações no host e na máquina virtual:
Defina o hardware virtual: Configuração de reserva de CPU para Máximo.
Reserve toda a memória do convidado no Hardware virtual: Memória.
Selecione VMware Paravirtual no hardware virtual: Controladora SCSI.
Na página Hardware virtual: Adaptador de rede: Tipo de adaptador, selecione SR-IOV para as placas de rede suportadas
Defina a opção General Guest OS Version > VM Options como Other 3.x ou posterior Linux (64 bits).
Defina a opção Opções de VM em Sensibilidade de latência avançada como Alta.
Em Opções da VM > Configuração de Edição Avançada, adicione "numa.nodeAffinity" ao mesmo nó NUMA da NIC SRIOV
Habilite as configurações de desempenho do hipervisor.
Limite a sobrecarga do vSwitch habilitando o SR-IOV nas placas de rede físicas suportadas.
Configure os vCPUs da VM para execução no mesmo nó NUMA que as NICs físicas.
Defina a sensibilidade de latência da VM como Alta.
AWS
O C8000v suporta a implantação no AWS, iniciando como uma Amazon Machine Image (AMI) dentro de uma Amazon Virtual Private Cloud (VPC), permitindo que os usuários provisionem uma seção logicamente isolada da nuvem do AWS para seus recursos de rede.
Filas Multi-TX
Em um C8000v executado em AWS, um recurso importante é o uso de Filas Multi-TX (Multi-TXQs). Essas filas ajudam a reduzir a sobrecarga de processamento interno e melhoram a escalabilidade. Ter várias filas torna mais rápido e simples atribuir pacotes de entrada e saída à CPU virtual (vCPU) correta.
Diferentemente de alguns sistemas em que as filas RX/TX são atribuídas por vCPU, no C8000v, essas filas são atribuídas por interface. As filas RX (recepção) e TX (transmissão) servem como pontos de conexão entre o aplicativo Catalyst 8000V e a infraestrutura ou hardware AWS, gerenciando como o tráfego de rede é enviado e recebido. O AWS controla o número e a velocidade das filas RX/TX disponíveis para cada interface, dependendo do tipo de instância.
Para criar várias filas TX, o Catalyst 8000V precisa ter várias interfaces. Quando várias filas TX são ativadas, o dispositivo mantém a ordem dos fluxos de pacotes usando um método de hash baseado na tupla 5 do fluxo (IP origem, IP destino, porta origem, porta destino e protocolo). Esse hash decide qual fila de TX usar para cada fluxo.
Os usuários podem criar várias interfaces no Catalyst 8000V usando a mesma placa de interface de rede (NIC) física conectada à instância do AWS. Isso é feito por meio da configuração de interfaces de loopback ou da adição de endereços IP secundários.
Com Multi-TXQs, há várias filas de transmissão para lidar com o tráfego de saída. No exemplo, há doze filas TX (numeradas de 0 a 11). Essa configuração permite monitorar cada fila individualmente para ver se alguma está ficando cheia.
Observando a saída, você pode ver que a Fila TX 8 tem um contador "completo" muito alto (56.406.998), o que significa que seu buffer está sendo preenchido com frequência. As outras filas TX mostram zero para o contador "cheio", indicando que não estão congestionadas.
Router#show platform hardware qfp active datapath infrastructure sw-cio pmd b17a2f00 device Gi2 RX: pkts 9525 bytes 1229599 return 0 badlen 0 Out-of-credits: Hi 0 Lo 0 pkts/burst 1 cycl/pkt 560 ext_cycl/pkt 360 Total ring read 117322273, empty 117312792 TX: pkts 175116324 bytes 246208197526 pri-0: pkts 157 bytes 10238 pkts/send 1 pri-1: pkts 75 bytes 4117 pkts/send 1 pri-2: pkts 91 bytes 6955 pkts/send 1 pri-3: pkts 95 bytes 8021 pkts/send 1 pri-4: pkts 54 bytes 2902 pkts/send 1 pri-5: pkts 75 bytes 4082 pkts/send 1 pri-6: pkts 104 bytes 8571 pkts/send 1 pri-7: pkts 74 bytes 4341 pkts/send 1 pri-8: pkts 175115328 bytes 246208130411 pkts/send 2 pri-9: pkts 85 bytes 7649 pkts/send 1 pri-10: pkts 106 bytes 5784 pkts/send 1 pri-11: pkts 82 bytes 7267 pkts/send 1 Total: pkts/send 2 cycl/pkt 203 send 68548581 sendnow 175024880 forced 1039215617 poll 1155226129 thd_poll 0 blocked 2300918060 retries 68534370 mbuf alloc err 0 TX Queue 0: full 0 current index 0 hiwater 0 TX Queue 1: full 0 current index 0 hiwater 0 TX Queue 2: full 0 current index 0 hiwater 0 TX Queue 3: full 0 current index 0 hiwater 0 TX Queue 4: full 0 current index 0 hiwater 0 TX Queue 5: full 0 current index 0 hiwater 0 TX Queue 6: full 0 current index 0 hiwater 0 TX Queue 7: full 0 current index 0 hiwater 0 TX Queue 8: full 56406998 current index 224 hiwater 224 <<<<<<<<<< TX Queue 9: full 0 current index 0 hiwater 0 TX Queue 10: full 0 current index 0 hiwater 0 TX Queue 11: full 0 current index 0 hiwater 0
A monitoração dos contadores "completos" das filas TX ajuda a identificar se alguma fila de transmissão está sobrecarregada. Uma contagem "completa" em aumento constante em uma fila TX específica aponta para um fluxo de tráfego que está sobrecarregando o dispositivo. Abordar isso pode envolver o balanceamento de tráfego, o ajuste de configurações ou o dimensionamento de recursos para melhorar o desempenho.
Métricas Excedidas
O AWS define certos limites de rede no nível da instância para garantir desempenho de rede consistente e de alta qualidade em diferentes tamanhos de instância. Esses limites ajudam a manter uma rede estável para todos os usuários.
Você pode verificar esses limites e as estatísticas relacionadas usando o comando show controllers em seu dispositivo. A saída inclui muitos contadores, mas aqui nos concentramos apenas nos mais importantes para monitorar o desempenho da rede:
Agora você pode se aprofundar e ver exatamente a que esses contadores se referem:
bw_in_permit_beyond: Número de pacotes na fila ou descartados porque a largura de banda de entrada ultrapassou o limite da instância.
bw_out_permit_beyond: Número de pacotes enfileirados ou descartados porque a largura de banda de saída ultrapassou o limite da instância.
pps_permit_beyond: Número de pacotes enfileirados ou descartados porque o total de pacotes por segundo (PPS) excedeu o limite da instância.
conntrack_permit_beyond: Número de conexões rastreadas que atingiram o máximo permitido para o tipo de instância.
linklocal_permit_beyond: Número de pacotes descartados porque o tráfego para serviços proxy locais (como Amazon DNS, Instance Metadata Service e Time Sync Service) excedeu o limite de PPS para a interface de rede. Isso não afeta os resolvedores DNS personalizados.
O que isso significa para o desempenho do seu C8000v:
Se você observar que esses contadores aumentam e apresentam problemas de desempenho, isso nem sempre significa que o roteador C8000v é o problema. Em vez disso, geralmente indica que a instância do AWS que você está usando atingiu seus limites de capacidade. Você pode verificar as especificações de sua instância do AWS para garantir que ela possa lidar com suas necessidades de tráfego.
Microsoft Azure
Nesta seção, explore como o Microsoft Azure e o roteador virtual Cisco C8000v se combinam para fornecer soluções de rede virtual escaláveis, seguras e de alto desempenho na nuvem.
Veja como a Rede Acelerada (AN) e a fragmentação de pacotes podem afetar o desempenho. Além de revisar a importância de usar um tipo de instância com suporte para o Microsoft Azure.
Rede acelerada
Em casos de problemas de desempenho em que o C8000v está hospedado na Nuvem do Microsoft Azure. Um aspecto que não pode ser ignorado é se a Accelerated Network está ativada ou não. À medida que aumenta muito o desempenho do roteador. Resumindo, a rede acelerada permite a virtualização de E/S de raiz única (SR-IOV) em VMs como uma VM do Cisco Catalyst 8000V. O caminho de rede acelerado ignora o switch virtual, aumenta a velocidade do tráfego de rede, melhora o desempenho da rede e reduz a latência e o jitter da rede.
Há uma maneira muito simples de verificar se a rede acelerada está ativada. Isso serve para verificar a saída do comando show controllers e se um determinado contador está presente ou não:
------------------ show controllers ------------------
GigabitEthernet1 - Gi1 is mapped to UIO on VXE
rx_good_packets 6497723453
tx_good_packets 14690462024
rx_good_bytes 2271904425498
tx_good_bytes 6276731371987
rx_q0_good_packets 58576251
rx_q0_good_bytes 44254667162
vf_rx_good_packets 6439147188
vf_tx_good_packets 14690462024
vf_rx_good_bytes 2227649747816
vf_tx_good_bytes 6276731371987
Os contadores que você está procurando são aqueles que começam com vf como vf_rx_good_packets. Se você verificar que esses contadores estão presentes, poderá ter certeza absoluta de que a rede acelerada está habilitada.
Azure e Fragmentação
A fragmentação pode ter implicações de desempenho negativas. Uma das principais razões para o efeito no desempenho é o efeito CPU/memória da fragmentação e remontagem de pacotes. Quando um dispositivo de rede precisa fragmentar um pacote, ele precisa alocar recursos de CPU/memória para executar a fragmentação.
O mesmo acontece quando o pacote é remontado. O dispositivo de rede deve armazenar todos os fragmentos até que sejam recebidos para que possa reagrupá-los no pacote original.
O Azure não processa pacotes fragmentados com a Rede Acelerada. Quando uma VM recebe um pacote fragmentado, o caminho não acelerado o processa. Como resultado, os pacotes fragmentados perdem os benefícios da rede acelerada, como menor latência, atraso de sincronismo reduzido e pacotes mais altos por segundo. Por esse motivo, a recomendação é evitar a fragmentação, se possível.
O Azure, por padrão, descarta pacotes fragmentados que chegam à VM fora de ordem, o que significa que os pacotes não correspondem à sequência de transmissão do ponto de extremidade de origem. Esse problema pode ocorrer quando os pacotes trafegam pela Internet ou por outras WANs grandes.
Tipos de Instância com Suporte para o Microsoft Azure
A razão para isso é porque os tipos de instância nessa lista são aqueles em que o C8KV foi devidamente testado. Agora, há uma pergunta válida se o C8000v funciona em um tipo de instância que não está listado? A resposta é provavelmente sim. No entanto, quando estiver solucionando problemas tão complexos quanto problemas de desempenho, você não desejará adicionar outro fator desconhecido ao problema. Só por isso, o Cisco TAC sempre recomenda que você permaneça em um tipo de instância compatível.
Outros recursos
Um problema de desempenho só pode ser realmente solucionado quando estiver acontecendo no momento. No entanto, isso pode ser difícil de capturar, pois pode acontecer a qualquer momento. Por esse motivo, fornecemos este script EEM. Ele ajuda a capturar saídas importantes no momento em que os pacotes começam a ser descartados e problemas de desempenho ocorrem:
Feedback