PDF(298.0 KB) Visualice con Adobe Reader en una variedad de dispositivos
Actualizado:6 de agosto de 2025
ID del documento:224027
Lenguaje no discriminatorio
El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.
Acerca de esta traducción
Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma.
Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional.
Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).
Este documento describe cómo resolver problemas de rendimiento en routers empresariales C8000v en nubes públicas y escenarios de ESXi.
Componentes Utilizados
La información de este documento se basa en estos componentes de hardware y software:
C8000v con versión 17.12
ESXI Versión 7.0 U3
La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.
Resolución general de problemas
Aunque puede alojar su C8000v en diferentes entornos, todavía puede seguir algunos pasos de solución de problemas que son idénticos independientemente de dónde esté alojado el C8000v. Comencemos con los aspectos básicos. Lo primero que debe asegurarse es si el dispositivo está alcanzando sus límites de capacidad o no. Para ello, puede comenzar por la verificación de estos dos resultados:
1. show platform hardware qfp active datapath util summary - Este comando le brinda la información completa de la entrada/salida que el C8000v está recibiendo y transmitiendo desde cada puerto. Debe centrar su atención en el porcentaje de carga de procesamiento. Si se encuentra en una situación en la que alcanza el 100%, significa que está alcanzando el límite de capacidad
------------------ 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 active datapath infrastructure sw-cio - Considere este comando como una versión más detallada del anterior. Proporciona más detalles sobre los núcleos individuales, incluidos los núcleos de E/S y criptografía que no forman parte del número de utilización de QFP. Es muy útil en un escenario donde se desea ver si un núcleo de plano de datos específico está causando un cuello de botella.
Consejo: Un detalle muy importante al utilizar este comando, siempre ejecútelo dos veces. Mientras calcula el porcentaje de utilización del núcleo entre el momento en que se ejecutó el comando.
Ahora, ha determinado si está alcanzando el límite de la plataforma o no. El siguiente paso sería comprobar si hay caídas. Están inherentemente conectados a problemas de rendimiento. Existen tres tipos de caídas que puede considerar dependiendo de dónde se estén produciendo.
Desbordamientos: Este tipo de caída de paquetes ocurre en el extremo Rx. Se producen porque se ha superado la capacidad de procesamiento de uno o varios núcleos.
Caídas de funciones: Este tipo de descarte de paquetes se produce en el PPE. Están relacionados con funciones del router como una ACL o QoS.
Gotas de cola: Este tipo de caída de paquetes ocurre en el extremo Tx. Ocurren debido a la congestión en las memorias intermedias Tx.
Para identificar qué caídas está experimentando, puede utilizar los siguientes resultados:
show platform hardware qfp active drop state clear
show interface
show policy map interface
Usted verifica cómo identificar a qué caídas se enfrenta y cómo mitigarlas. Sin embargo, el mayor enfoque en este artículo va a ser las caídas que se conocen como Taildrops, ya que son particularmente difíciles de resolver en routers virtuales.
Desbordamientos
Una caída de desbordamiento en Cisco IOS XE ocurre cuando la interfaz de red recibe los paquetes más rápido de lo que puede procesarlos o almacenarlos en su buffer. Específicamente, las memorias intermedias internas de las interfaces (cola FIFO) se llenan porque la velocidad de datos entrantes excede la capacidad del hardware para manejarlo. Como resultado, los nuevos paquetes entrantes no se pueden almacenar y se descartan, lo que incrementa el contador de desbordamiento. Básicamente, se trata de una pérdida de paquetes causada por la saturación temporal de la interfaz.
Este tipo de caídas de paquetes ocurre en el extremo Rx. Se producen porque se ha superado la capacidad de procesamiento de uno o más núcleos y el subproceso Rx no puede distribuir los paquetes entrantes al subproceso PP relevante y los búferes de entrada ya están llenos. Para hacer una analogía simple, puede pensarlo como una cola en un contador de caja que se llena demasiado porque los paquetes llegan más rápido de lo que el cajero (hardware de interfaz) puede servirles. Cuando la cola está llena, los nuevos clientes tienen que marcharse sin recibir servicio, ya que estas son las caídas de desbordamiento.
Aunque en esta sección se menciona el hardware, el C8000v es un router basado en software. En este caso, los desbordamientos pueden ser causados por:
Alta utilización del plano de datos: Si la utilización del plano de datos es alta, los paquetes no se pueden sondear lo suficientemente rápido, lo que provoca saturaciones. Por ejemplo, la presencia de "flujos de elefantes" (flujos de datos continuos y de gran tamaño) puede saturar los recursos de procesamiento y provocar saturaciones en las interfaces.
Plantilla de dispositivo incorrecta: El uso de una plantilla de dispositivo inadecuada puede provocar una gestión ineficaz del búfer y saturaciones. Esto se puede verificar con el comando show platform software cpu alloc y se puede cambiar con el comando platform resource <template>.
A cada interfaz se le asigna un conjunto limitado de créditos, este mecanismo evita una interfaz ocupada y la sobrecarga de los recursos del sistema. Cada vez que un paquete nuevo llega al plano de datos, se requiere un crédito. Cuando se realiza el procesamiento de paquetes, se devuelve el crédito para que el subproceso Rx pueda volver a utilizarlo. Si no hay crédito disponible para la interfaz, el paquete debe esperar en el anillo Rx de la interfaz. Por lo general, se espera que el límite de rendimiento relacionado con las caídas sea desbordamientos Rx porque se ha excedido la capacidad de procesamiento de uno o más núcleos.
Para identificar los desbordamientos, normalmente verifica las estadísticas de la interfaz para ver si hay errores de entrada, específicamente el contador de desbordamientos:
Utilice el comando show platform hardware qfp active datapath infrastructure sw-cio para identificar la utilización del núcleo y si se ha excedido el número de créditos para una interfaz específica.
Utilice el comando show interface <interface-name> y busque el conteo de desbordamiento en el resultado.
Los desbordamientos se muestran como parte de los errores de entrada, por ejemplo:
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 <<<<<<<<<<<
Supongamos un caso en el que Gig2 está observando problemas de rendimiento causados por desbordamientos. Para determinar el subproceso de trabajo asociado a esta interfaz, puede utilizar el comando this:
#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
Luego, puede analizar la utilización del subproceso específico responsable del tráfico Rx de esta interfaz y su número de créditos.
En un escenario donde Gig2 está observando problemas de rendimiento debido a sobrecostes, puede esperar que el PP#2 esté constantemente utilizado (Inactivo = 0%), y créditos bajos/cero para la interfaz 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
Caídas de funciones
Los paquetes son manejados por cualquier subproceso de plano de datos disponible y se distribuyen estrictamente en función de la disponibilidad de los núcleos QFP a través de la función Rx del software (x86) - Distribución basada en carga (LBD). Los paquetes que llegan al PPE se pueden descartar con una razón de descarte QFP específica, que se puede comprobar usando esta salida:
#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
Las razones de las caídas son diversas y generalmente se explican por sí mismas. Para investigar más a fondo, se puede utilizar un seguimiento de paquetes.
Gotas
Como se mencionó anteriormente, las caídas de cola ocurren cuando el dispositivo está tratando de transmitir paquetes, pero las memorias intermedias de transmisión están llenas.
En esta subsección, va a ver qué resultados puede examinar cuando se enfrente a este tipo de situación. Qué valores puede ver en ellos significan y qué puede hacer para mitigar el problema.
En primer lugar, debe saber cómo identificarlos. Una de estas maneras es simplemente mirar la interfaz show. Esté atento a cualquier aumento de las gotas de salida:
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
Este comando es particularmente útil para entender si está experimentando congestión o no:
show platform hardware qfp active datapath infrastructure - HQF significa `estructura jerárquica de almacenamiento en cola`. Se trata de una función que permite la gestión de la calidad del servicio (QoS) en diferentes niveles (físico, lógico y de clase) mediante la interfaz de línea de comandos (MQC) de QoS modular. Muestra los costes actuales de RX y TX. Cuando la cola TX está llena, como muestra el resultado (1959 completo)
El resultado sugiere que el hardware subyacente no está al día con el envío de paquetes. Para depurar la interfaz subyacente, es posible que deba buscar fuera del C8000v y en el entorno subyacente en el que se está ejecutando el C8000v para ver si se han notificado errores adicionales en las interfaces físicas subyacentes.
Para verificar el entorno, hay un paso que puede realizar antes de verificar en qué hipervisor se está ejecutando el router C8000v. Esto es para verificar la salida del comando show controller. Sin embargo, usted puede encontrarse perdido en lo que cada contador significa o dónde mirar.
En primer lugar, un detalle importante que debe tener en cuenta al ver este resultado es que la información se obtiene principalmente de las propias vNIC. Cada controlador NIC tiene un conjunto específico de contadores que utilizan, que pueden variar según el controlador, naturalmente. Diferentes hipervisores tienen algún tipo de efecto en lo que se presenta también. Algunos contadores, como los contadores mbuf, son estadísticas del controlador DPDK. Estos pueden variar para diferentes controladores DPDK. El recuento real lo realiza generalmente el hipervisor en la capa de virtualización.
Tómese un minuto aquí para aprender a interpretar y leer estos contadores:
Si ve subX, significa que es una sub-interfaz - una división lógica de la interfaz principal. El sub0 es generalmente el primario/predeterminado. Estos se utilizan a menudo cuando hay varias VLAN involucradas.
Luego, tiene "rx = recepcion" y "tx = transmision".
Finalmente, q0 se refiere a la cola primero/predeterminado utilizada por esa interfaz
Aunque no hay una descripción para cada contador, el artículo describe algunos de ellos, que pueden ser relevantes para su solución de problemas:
"RX_MISSED_ERRORS:" aparece cuando el búfer de NIC (Rx FIFO) se llena en exceso. Esta condición conduce a caídas y a un aumento de la latencia. Una posible solución a esto es aumentar el búfer NIC (lo cual es imposible en nuestro caso) o cambiar el controlador NIC.
"tx_q0_drop_total" y "tx_q0_tx_ring_full": Estos pueden indicarle que el host está descartando paquetes y que el C8000v está experimentando descartes de cola en el C8000v porque el host está presionando hacia atrás el C8000v
En el resultado anterior, no vemos ningún "rx_missing_errors". Sin embargo, como nos estamos centrando en las caídas de cola, vemos "tx_q0_drop_total" y "tx_q0_tx_ring_full". Con esto, podemos concluir que existe una congestión causada por el hardware subyacente del host.
Como se ha mencionado anteriormente, cada hipervisor tiene algún tipo de efecto en lo que se presenta. El artículo se centra en esto en la siguiente sección, ya que trata las diferencias entre los diferentes hipervisores en los que se puede alojar el C8000v. También puede encontrar las diferentes recomendaciones para tratar de mitigar este tipo de problema en cada una de ellas.
Hipervisores
Un hipervisor es una capa de software que permite que varios sistemas operativos (denominados máquinas virtuales o VM) se ejecuten en un único host de hardware físico mediante la administración y asignación de los recursos de hardware, como la CPU, la memoria y el almacenamiento, a cada VM. Garantiza que estas máquinas virtuales funcionen de forma independiente sin interferir unas con otras.
En el contexto de Cisco Catalyst 8000V (C8000v), el hipervisor es la plataforma que aloja la máquina virtual C8000v. ¿Cómo puede averiguar qué hipervisor aloja su C8000v? Hay un resultado bastante útil que nos da esa información. Además, también puede comprobar a qué tipo de recursos tiene acceso nuestro router virtual:
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
ESXi es un hipervisor de tipo 1 desarrollado por VMware que se instala directamente en servidores físicos para habilitar la virtualización. Permite ejecutar varias máquinas virtuales (VM) en un único servidor físico mediante la abstracción de los recursos de hardware y su asignación a cada VM. El router C8000v es una de esas VM.
Puede empezar por repasar un escenario común en el que se está produciendo una congestión. Esto se puede confirmar al verificar el contador tx_q0_tx_ring_full:
Ejemplo:
------------------ 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 -------------------------------------------------------------
Esta congestión se produce cuando el C8000V intenta enviar paquetes a través de la interfaz VMXNET3. Sin embargo, el anillo de búfer ya está lleno de paquetes, que terminan en retrasos o caídas.
En estas condiciones, estas caídas se producen en el hipervisor, como hemos mencionado anteriormente. Si se cumplen todas las recomendaciones, se recomienda consultar con el soporte de VMware para saber qué está sucediendo en la NIC.
A continuación, se ofrecen algunas sugerencias sobre cómo mejorar el rendimiento:
Utilice un vSwitch dedicado y un enlace ascendente para obtener un rendimiento óptimo
Al asignar el C8000V a un vSwitch dedicado respaldado por su propio enlace ascendente físico, podemos aislar su tráfico de vecinos ruidosos y evitar cuellos de botella de recursos compartidos.
Hay algunos comandos que vale la pena examinar desde el lado de ESXi. Por ejemplo, para comprobar la pérdida de paquetes desde la interfaz ESXi, podemos hacer lo siguiente:
Activar SSH.
Conexión a ESXi mediante SSH.
Ejecute esxtop.
Escriba n.
El comando esxtop puede mostrar los paquetes descartados en el switch virtual si el controlador de red de la máquina virtual se queda sin memoria intermedia Rx. Aunque esxtop muestra los paquetes como descartados en el switch virtual, en realidad se descartan entre el switch virtual y el controlador del sistema operativo invitado.
Busque los paquetes que se están descartando en %DRPTX y %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 enumera todas las NIC configuradas en un 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
También existe un comando útil para comprobar el estado de la vNIC asignada a una VM concreta.
Si observamos c8kv-gw-mgmt , que es una máquina virtual C8000v, hay 2 redes asignadas:
c8kv-to-9200l
c8kv a cisco
Puede utilizar el ID de mundo para buscar más información 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:~]
Una vez que disponga de esta información, podrá identificar a qué red está asignado el vSwitch.
Para verificar algunas estadísticas de tráfico de la NIC física asignada al vSwitch, tenemos el comando this:
# esxcli network nic stats get -n <vmnic>
Este comando muestra información como paquetes recibidos, bytes recibidos, paquetes descartados y errores recibidos. Esto puede ayudar a identificar si hay alguna caída sucediendo en la NIC.
Hay algunas configuraciones que se deben verificar que pueden mejorar el rendimiento de Cisco Catalyst 8000V que se ejecuta en un entorno ESXi modificando la configuración en el host y la máquina virtual:
Establezca el hardware virtual: Reserva de CPU establecida en Máximo.
Reserve toda la memoria de invitado en el hardware virtual: Memoria.
Seleccione VMware Paravirtual en Hardware virtual: Controlador SCSI.
Desde el hardware virtual: Adaptador de red: Tipo de adaptador, seleccione SR-IOV para las NIC compatibles
Establezca la opción General Guest OS Version > VM Options en Other 3.x o posterior Linux (64 bits).
Establezca la opción Opciones de VM en Sensibilidad de latencia avanzada en Alta.
En Opciones de VM > Configuración de edición avanzada, agregue "numa.nodeAffinity" al mismo nodo NUMA que la NIC SRIOV
Active la configuración de rendimiento del hipervisor.
Limite la sobrecarga del vSwitch habilitando SR-IOV en las NIC físicas admitidas.
Configure las vCPU de la VM para que se ejecuten en el mismo nodo NUMA que las NIC físicas.
Establezca la sensibilidad de latencia de VM en High (Alta).
AWS
El C8000v admite la implementación en AWS al iniciarse como una imagen de máquina de Amazon (AMI) dentro de una nube privada virtual (VPC) de Amazon, lo que permite a los usuarios aprovisionar una sección aislada lógicamente de la nube de AWS para sus recursos de red.
Colas Multi-TX
En un C8000v que se ejecuta en AWS, una función clave es el uso de colas de transmisión múltiple (Multi-TXQs). Estas colas ayudan a reducir la sobrecarga de procesamiento interno y a mejorar la escalabilidad. Disponer de varias colas hace que asignar paquetes entrantes y salientes a la CPU virtual (vCPU) correcta sea más rápido y sencillo.
A diferencia de algunos sistemas en los que las colas RX/TX se asignan por vCPU, en el C8000v, estas colas se asignan por interfaz. Las colas RX (de recepción) y TX (de transmisión) sirven como puntos de conexión entre la aplicación Catalyst 8000V y la infraestructura o hardware de AWS, y administran cómo se envía y recibe el tráfico de red. AWS controla el número y la velocidad de las colas RX/TX disponibles para cada interfaz, dependiendo del tipo de instancia.
Para crear varias colas TX, Catalyst 8000V necesita tener varias interfaces. Cuando se habilitan varias colas TX, el dispositivo mantiene el orden de los flujos de paquetes mediante un método de hashing basado en la 5-tupla del flujo (IP de origen, IP de destino, puerto de origen, puerto de destino y protocolo). Este hashing decide qué cola TX utilizar para cada flujo.
Los usuarios pueden crear varias interfaces en el Catalyst 8000V utilizando la misma tarjeta de interfaz de red (NIC) física conectada a la instancia de AWS. Esto se realiza mediante la configuración de interfaces de loopback o la adición de direcciones IP secundarias.
Con Multi-TXQs, hay varias colas de transmisión para manejar el tráfico saliente. En el ejemplo, hay doce colas TX (numeradas del 0 al 11). Esta configuración le permite supervisar cada cola individualmente para ver si alguna se está llenando.
Si observa el resultado, puede ver que TX Queue 8 tiene un contador "completo" muy alto (56,406,998), lo que significa que su búfer se está llenando con frecuencia. Las otras colas TX muestran cero para el contador "completo", lo que indica que no están 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
La supervisión de los contadores "completos" de las colas TX ayuda a identificar si alguna cola de transmisión está sobrecargada. Un conteo "completo" en constante aumento en una cola TX en particular apunta a un flujo de tráfico que está estresando al dispositivo. Esto puede implicar el equilibrio del tráfico, el ajuste de las configuraciones o la ampliación de los recursos para mejorar el rendimiento.
Métricas excedidas
AWS establece ciertos límites de red en el nivel de instancia para garantizar un rendimiento de red uniforme y de alta calidad en diferentes tamaños de instancia. Estos límites ayudan a mantener una red estable para todos los usuarios.
Puede verificar estos límites y las estadísticas relacionadas mediante el comando show controllers en su dispositivo. El resultado incluye muchos contadores, pero aquí nos centramos solo en los más importantes para supervisar el rendimiento de la red:
Ahora puede sumergirse y ver a qué se refieren exactamente esos contadores:
bw_in_alloween_exceeded: Número de paquetes en cola o descartados porque el ancho de banda entrante superó el límite de la instancia.
bw_out_alloween_exceeded: Número de paquetes en cola o descartados debido a que el ancho de banda saliente excedió el límite de la instancia.
pps_alloween_exceeded: Número de paquetes en cola o descartados porque el total de paquetes por segundo (PPS) superó el límite de la instancia.
conntrack_alloween_exceeded: Número de conexiones supervisadas que alcanzaron el máximo permitido para el tipo de instancia.
linklocal_alloween_exceeded: Número de paquetes descartados porque el tráfico a los servicios proxy locales (como Amazon DNS, Instance Metadata Service y Time Sync Service) superó el límite de PPS para la interfaz de red. Esto no afecta a los resolvers DNS personalizados.
Lo que esto significa para el rendimiento de C8000v:
Si observa que estos contadores aumentan y experimenta problemas de rendimiento, no siempre significa que el router C8000v sea el problema. En su lugar, a menudo indica que la instancia de AWS que está utilizando ha alcanzado sus límites de capacidad. Puede comprobar las especificaciones de su instancia de AWS para asegurarse de que puede gestionar sus necesidades de tráfico.
Microsoft Azure
En esta sección, explore cómo Microsoft Azure y el router virtual Cisco C8000v se combinan para ofrecer soluciones de red virtuales escalables, seguras y de alto rendimiento en la nube.
Conozca cómo las redes aceleradas (AN) y la fragmentación de paquetes pueden afectar al rendimiento. Además de revisar la importancia de usar un tipo de instancia compatible con Microsoft Azure.
Redes aceleradas
En casos de problemas de rendimiento en los que el C8000v está alojado en la nube de Microsoft Azure. Un aspecto que no puede pasar por alto es si Accelerated Network está o no habilitado. A medida que aumenta considerablemente el rendimiento del router. En pocas palabras, la red acelerada permite la virtualización de E/S de raíz única (SR-IOV) en máquinas virtuales como, por ejemplo, una máquina virtual Cisco Catalyst 8000V. La ruta de red acelerada omite el switch virtual, aumenta la velocidad del tráfico de red, mejora el rendimiento de la red y reduce la latencia y la fluctuación de la red.
Existe una forma muy sencilla de comprobar si la red acelerada está activada. Esto es para verificar la salida de show controllers y verificar si hay o no ciertos contadores:
------------------ 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
Los contadores que está buscando son los que comienzan con vf como vf_rx_good_packets. Si verifica que estos contadores están presentes, puede estar absolutamente seguro de que la red acelerada está habilitada.
Azure y fragmentación
La fragmentación puede tener implicaciones negativas en el rendimiento. Una de las principales razones del efecto sobre el rendimiento es el efecto CPU/memoria de la fragmentación y reensamblado de paquetes. Cuando un dispositivo de red necesita fragmentar un paquete, tiene que asignar recursos de CPU/memoria para realizar la fragmentación.
Lo mismo sucede cuando se reensambla el paquete. El dispositivo de red debe almacenar todos los fragmentos hasta que se reciban para poder reensamblarlos en el paquete original.
Azure no procesa paquetes fragmentados con Accelerated Networking. Cuando una VM recibe un paquete fragmentado, la trayectoria no acelerada lo procesa. Como resultado, los paquetes fragmentados no aprovechan las ventajas de las redes aceleradas, como una latencia más baja, una fluctuación reducida y paquetes más altos por segundo. Por esta razón, se recomienda evitar la fragmentación si es posible.
Azure, de forma predeterminada, descarta los paquetes fragmentados que llegan a la máquina virtual fuera de servicio, lo que significa que los paquetes no coinciden con la secuencia de transmisión desde el punto final de origen. Este problema puede ocurrir cuando los paquetes viajan a través de Internet u otras WAN grandes.
Esto se debe a que los tipos de instancia de la lista son aquellos en los que se ha probado correctamente el C8KV. Ahora, existe una pregunta válida si el C8000v funciona en un tipo de instancia que no está en la lista. La respuesta probablemente sea sí. Sin embargo, cuando está solucionando problemas tan complejos como los problemas de rendimiento, no desea agregar otro factor desconocido al problema. Solo por ese motivo, Cisco TAC siempre recomienda permanecer en un tipo de instancia compatible.
Recursos adicionales
Un problema de rendimiento solo se puede solucionar realmente cuando está sucediendo en el momento. Sin embargo, esto puede ser difícil de atrapar, ya que puede suceder en cualquier momento dado. Por esa razón, proporcionamos este guion de EEM. Ayuda a capturar salidas importantes en el momento en que los paquetes comienzan a ser descartados y se presentan problemas de rendimiento:
Comentarios