Solución de problemas de paquetes ignorados e interrupciones por falta de memoria en el router de Internet de la serie Cisco 12000
Contenido
Introducción
Este documento explica cómo resolver problemas relacionados con el motivo por el cual el resultado del comando show interfaces en un router de Internet 12000 de Cisco muestra un número cada vez mayor de errores ignorados. También proporciona consejos para la resolución de problemas para un número creciente de caídas no mem en la salida de execute-on slot <slot#> show controllers (frfab | tofab) qm stat. Cuando esté tratando de resolver problemas relacionados con estos errores, verifique que el contador esté aumentando y que no sea simplemente un valor histórico.
Nota: Un número creciente de caídas de cola de entrada, como se muestra en el resultado show interfaces, se trata por separado en Resolución de problemas de caídas de entrada en el router de Internet de la serie Cisco 12000.
Prerequisites
Requirements
Este documento requiere la compresión de la arquitectura del router de Internet de la serie Cisco 12000, en particular las colas ToFab y FrFab. Vea Cómo Leer el Resultado del comando show controllers frfab | tofab queue Commands para referencia.
Componentes Utilizados
La información que contiene este documento se basa en las versiones de software y hardware indicadas a continuación.
-
Todos los lanzamientos de software Cisco IOS® que soporten el router de la serie de Internet 12000 de Cisco. Por lo general, éstas son las versiones 12.0S y 12.0ST.
-
Este documento abarca todas las plataformas 12000 de Cisco Éstas incluyen 12008, 12012, 12016, 12404, 12410 y 12416.
La información que se presenta en este documento se originó a partir de dispositivos dentro de un ambiente de laboratorio específico. All of the devices used in this document started with a cleared (default) configuration. Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener un comando antes de ejecutarlo.
Convenciones
Para obtener más información sobre las convenciones del documento, consulte Convenciones de Consejos Técnicos de Cisco.
Síntomas
El router de Internet de la serie 12000 de Cisco utiliza una arquitectura distribuida para garantizar un rendimiento de reenvío óptimo. Para soportar altas velocidades de reenvío, mantiene búfers de paquetes en las tarjetas de líneas entrantes y salientes. Estas memorias intermedias de paquetes varían en tamaño y generalmente están diseñadas para admitir tramas de tamaño de unidad de transmisión máxima (MTU).
Después de que determina la interfaz saliente para un paquete, el procesador de reenvío hace lo siguiente:
-
El procesador de reenvío envía un puntero con información acerca del paquete (incluyendo la ubicación en memoria) a la cola de salida virtual de la interfaz de salida.
-
El programador de la tarjeta de línea envía un pedido al programador El programador emite un permiso y el paquete se envía desde la memoria intermedia a través del switch fabric hasta la tarjeta de línea.
-
La tarjeta de línea saliente almacena los paquetes en la memoria intermedia.
-
El procesador L3 y los Circuitos integrados de aplicación específica (ASIC) asociados en la LC de salida transmiten el paquete fuera de la interfaz.
Si la interfaz saliente se sobresuscribe, comienza a almacenar en búfer los paquetes excedentes. Durante los períodos de exceso de suscripción sostenida, las colas de transmisión de la LC saliente se llenan. En esta condición, pasa lo siguiente dependiendo de la LC de salida:
| Tipo de motor de LC de salida | Respuesta a la congestión de salida | Contador de errores |
|---|---|---|
| Motor 0 y 1 | Envía una señal de contrapresión. La interfaz entrante comienza a almacenar en búfer los paquetes excedentes. | Errores ignorados en la salida del comando show interfaces y/o no hay caídas de mem en la salida del comando execute-on slot <slot#> show controllers tofab QM stat de la LC entrante, dependiendo de su motor de reenvío L3.¹ |
| Motor 2, 3, 4 | Descarta cualquier exceso de paquetes en la salida. | No hay caídas mem en la salida del comando execute-on slot <slot#> show controllers frfab QM stat en la LC saliente. |
Obtendrá errores ignorados para las LC de ingreso de los motores 0, 1 y 2. Sin embargo, para cuatro, 16 y más puertos en las LC del Motor 2, el contador ignorado no aumentará.
En cualquier dispositivo de red inteligente, cuando una o más interfaces de alta velocidad alimentan a una interfaz de velocidad relativamente baja, ocurre una discordancia entre las velocidades de las interfaces. Dado que la interfaz saliente de menor velocidad no puede devolver memorias intermedias con la misma velocidad que la interfaz de entrada de mayor velocidad las envía a la cola de retención de salida, un retardo en el retorno de memoria intermedia ocasiona algún tipo de caídas. Este flujo de paquetes descarta la suposición de que la interfaz de salida regresa la memoria intermedia a la velocidad del momento de administración de memoria intermedia.
Además de una discordancia en las velocidades de interfaz, los errores ignorados pueden aumentar cuando la velocidad de los paquetes que llegan es mayor de lo que la CPU puede procesarlos. Ésta es una condición muy extraña en Cisco 12000 y generalmente se debe a una gran cantidad de paquetes muy pequeños o a que una función de uso intensivo de la CPU, como las listas de control de acceso (ACL) o la vigilancia de tráfico, se activa en una LC que implementa estas funciones en el software. Este es el caso de las LC de Motor 0 donde se implementan muchas funciones en el software. Sin embargo, en los motores posteriores, casi todas las funciones se implementan en hardware. Por ejemplo, las tarjetas de línea del motor 3 (motor de servicios IP - ISE) y del motor 4+ están diseñadas para aplicaciones perimetrales e implementan servicios IP mejorados (como calidad de servicio - QoS) en hardware sin impacto en el rendimiento. Los ejemplos de este hardware incluyen CHOC-48 ISE de 1 puerto, CHOC-12 ISE de 4 puertos, OC-3 POS ISE de 16 puertos, OC-12 POS ISE de 4 puertos, OC-48 POS ISE de 1 puerto y OC-48 POS ISE de 1 puerto.
El contador ignorado puede asimismo incrementarse cuando llega un paquete en una tarjeta de línea de ingreso y no se encuentra disponible un búfer de paquetes del tamaño adecuado para procesar este paquete. No obstante, esta condición es muy rara y no se incluye en este documento.
Administración de exceso de suscripción de interfaz de salida
La solución para los errores ignorados y ninguna pérdida mem causada por la sobresuscripción de la interfaz de salida es la misma para cualquier tipo de Motor L3 — evitar la hambruna de búfer. En otras palabras, necesitamos un mecanismo que prevenga que las colas FrFab se llenen.
Motores 0 y 1
En resumen, el contador ignorado aumenta cuando llega un paquete en una Tarjeta de línea (LC) de ingreso y no se encuentra disponible un búfer de paquetes del tamaño adecuado para manejar este paquete. De esta manera, los paquetes ignorados, por lo general, no apuntan hacia un error en el software del IOS de Cisco.
A continuación se muestra un ejemplo de salida del comando show interfaces con un contador ignorado no nulo en un Cisco 12000 Series Router:
router#show interfaces G3/0
GigabitEthernet3/0 is up, line protocol is up
Hardware is GigMac GigabitEthernet, address is 0030.71f5.7980
(bia 0030.71f5.7980)
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, rely 255/255, load 1/255
Encapsulation ARPA, loopback not set
Keepalive not set
Full-duplex mode, link type is force-up, media type is SX
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 00:00:07
Queueing strategy: fifo
Output queue 0/40, 0 drops; input queue 0/75, 0 drops
5 minute input rate 99000 bits/sec, 74 packets/sec
5 minute output rate 104000 bits/sec, 68 packets/sec
478 packets input, 71057 bytes, 0 no buffer
Received 19 broadcasts, 0 runts, 0 giants, 0 throttles
2 input errors, 2 CRC, 0 frame, 0 overrun, 25 ignored
!--- Ignored counter is > 0. Ensure it is incrementing.
0 watchdog, 53 multicast, 0 pause input
541 packets output, 139133 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out
Cuando la LC de salida es un motor 0 o 1, envía un mensaje de contrapresión a las otras LC pidiéndoles que no envíen más datos a esa LC particular. La interfaz de entrada luego almacena en la memoria intermedia los paquetes excedentes en sus colas ToFab correspondientes a esta ranura de destino.
A fin de aislar la causa más probable del aumento del contador Ignorado, necesita observar las colas ToFab de la LC de ingreso. Usted puede adjuntar al LC en el BUS de mantenimiento (MBUS) mediante el comando attach, o utilizar el comando execute-on slot <slot#> show controllers tofab queue para verificar las colas ToFab. Ejecute este comando pocas veces y busque los siguientes síntomas:
-
Un valor decreciente y bajo o un valor de 0 en la columna #Qelem de una cola libre no IPC
-
Un valor alto en la columna #Qelem en una cola de ranura de destino.
Motores 2, 3, 4
Las tarjetas de línea que utilizan una arquitectura de motor L3 más reciente no utilizan un mecanismo de contrapresión. Por el contrario, cuando una interfaz cuenta con un exceso de suscriptores y se agota una cola FrFab, simplemente se rechazan los paquetes en cuanto llegan a la tarjeta de la línea de egreso.
Las LC del Motor 2 no se repliegan al siguiente agrupamiento de memorias intermedias de mayor tamaño cuando se agota un agrupamiento menor. El mecanismo de retroceso sólo se ha implementado para las LC del motor 2 en el lado ToFab (Rx). Si sucede, el contador de "bumps" se incrementará en el resultado del comando execute-on slot <ranura> show controller tofab QM stat.
Se cuentan estas caídas como no mem drops en el resultado del comando execute-on slot <ranura#> show controllers frfab QM stat, como se ilustra a continuación:
Router#execute-on slot 1 show controller frfab QM stat ========= Line Card (Slot 1) ======= 174 no mem drop, 0 soft drop, 0 bump count !--- Look for an incrementing value for the "no mem drop" counter 0 rawq drops, 0 global red drops, 0 global force drops 0 no memory (ns), 0 no memory hwm (Ns) no free queue 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 multicast drops Tx Counts Interface 0 8390658710246 TX bytes, 2098330790 TX pkts, 212452 kbps, 6641 pps Interface 1 0 TX bytes, 0 TX pkts, 0 kbps, 0 PPS Interface 2 0 TX bytes, 0 TX pkts, 0 kbps, 0 PPS Interface 3 0 TX bytes, 0 TX pkts, 0 kbps, 0 PPS
Debe encontrar una manera de evitar que el lado FrFab se almacene en búfer hasta el punto en el que la LC realiza una copia de seguridad de la interfaz entrante o simplemente descarta los paquetes.
Una solución simple para todas las tarjetas de línea, excepto las LC del Motor 2, es reducir el número de búfers disponibles para una interfaz saliente determinada en una LC multiinterfaz. Como opción predeterminada, una interfaz puede usar todas las memorias intermedias FrFab divididas. Para configurar un valor no predeterminado, utilice el comando tx-queue-limit. Esto evita que se almacene el LC de egreso más que el número configurado de paquetes en la cola de la interfaz de ese puerto específico. Asegúrese de configurar este número lo suficientemente bajo de manera que no incluya todas las colas FrFab para esta interfaz. Observe que este método no diferencia entre los paquetes de alta y baja prioridad y simplemente implementa la eliminación del extremo de la cola de manera más agresiva para una interfaz específica.
Las tarjetas de línea de Motor 3 exigen el uso de Modular QoS CLI (MQC) en lugar de la Interfaz de línea de instrucciones (CLI) heredada. Este comando no se soporta en las tarjetas de línea basadas en el Motor 2.
Aquí se presenta un ejemplo de configuración mediante la configuración de Clase de servicio (CoS) heredada:
interface POS 0/0
tx-queue-limit <max Q length in packets>
Aquí se presenta un ejemplo de configuración mediante MQC:
policy-map TX_QUEUE_LIMIT
class class-default
queue-limit
interface POS 0/0
service-policy out TX_QUEUE_LIMIT
Otra solución es implementar una interfaz de salida más rápida, lo que nos da una tubería más grande. Pero las tuberías más grandes pueden llenarse rápidamente. Por lo tanto, la solución recomendada es implementar mecanismos de calidad de servicio (QoS) en la LC saliente.
La función Weighted Random Early Detection (WRED) de Cisco implementa un mecanismo de caída diferenciado o inteligente. Esta función fue diseñada para operar con tráfico adaptable, como el de los flujos TCP. Monitorea el tamaño de la cola y trabaja para mantener un tamaño de cola promedio consistente mediante la eliminación aleatoria de paquetes de varios flujos cuando la cola promedio calculada se eleva por sobre un umbral mínimo configurable.
Cuando se implementa en la serie 12000 de Cisco, WRED puede evitar que las colas FrFab se completen y seleccionar qué paquetes desea perder. Los LC de motor 0 admiten WRED en el software, mientras que los LC de motor 1 directamente no admiten WRED. Las otras LC del motor L3 soportan WRED en hardware.
Para obtener más información sobre la configuración de WRED, consulte estos documentos:
-
Detección temprana aleatoria ponderada en el router de Cisco serie 12000
-
Configuración de MPLS CoS en un Cisco 12000 Series GSR Router
Este mecanismo que evita la congestión funciona únicamente en un entorno basado en TCP. TCP responde de manera adecuada (aunque rudamente) a la pérdida de tráfico al reducir la transmisión de su tráfico. Vea Cómo TCP maneja la pérdida de tráfico y Cómo el router interactúa con TCP para obtener detalles sobre cómo reacciona TCP a la pérdida de paquetes.
Otro mecanismo de QoS compatible en la serie 12000 de Cisco es la regulación del tráfico mediante la Velocidad de acceso comprometida (CAR) en las LC de Motor 0 y Motor 1, y una versión modificada de CAR conocida como Control de velocidad por interfaz (PIRC) en las LC de Motor 2. Configure la regulación del tráfico en la interfaz de salida.
Administración de CPU sobrecargada en la tarjeta de línea de entrada
¡Esta situación es muy rara!
Puede verificar si la CPU está sobrecargada en la LC entrante con el comando execute-on slot <número de ranura> show controllers tofab queues. Si ve un número muy elevado en la columna #Qelem de la fila de la “Cola sin procesar”, significa que se intenta que la CPU administre demasiados paquetes (que está ubicada en la LC misma). Empezará a recibir paquetes ignorados porque la CPU no puede seguir el ritmo de la cantidad de paquetes. Estos paquetes se dirigen a la CPU de la LC, no al Procesador de ruta Gigabit (GRP).
Ahora, debe cambiar una parte del tráfico de esta LC de entrada de manera que su CPU reciba un impacto menor.
También debería revisar la configuración LC para verificar si alguna de las funciones configuradas en ella afectan a la CPU. Algunas características (como CAR, ACL y NetFlow) pueden degradar el rendimiento de la LC cuando se las implementa en software (sólo en LC de Motor 0). Si este es el caso, debe actuar en consecuencia, ya sea eliminando la función o actualizando el software Cisco IOS a una versión posterior donde se mejora la misma implementación de la función (como Turbo ACL). Vea las notas de versión de los routers Cisco de la serie 12000 para saber qué funciones han sido implementadas o mejoradas para distintas LC.
Finalmente, la única solución puede ser intercambiar la LC por una más reciente donde la característica solicitada esté implementada en el hardware. Esto realmente depende del tipo de motor de la LC.
Puede utilizar el siguiente comando de acceso directo para determinar el tipo de motor de la Capa 3 de una LC:
Router#show diag | i (SLOT | Engine) ... SLOT 1 (RP/LC 1 ): 1 port ATM Over SONET OC12c/STM-4c Multi Mode L3 Engine: 0 - OC12 (622 Mbps) SLOT 3 (RP/LC 3 ): 3 Port Gigabit Ethernet L3 Engine: 2 - Backbone OC48 (2.5 Gbps) ...
Nota: Las tarjetas de línea del motor 3 (IP Services Engine - ISE) y del motor 4+ están diseñadas para aplicaciones perimetrales e implementan servicios IP mejorados (como QoS) en hardware sin impacto en el rendimiento.
Resumen de las pautas de diseño
-
Use Turbo ACL, que optimizan el rendimiento al permitir que el router compile las ACL antes de descargarlas al procesador LC.
-
Evite el uso de la palabra clave "log" en las ACL.
-
Siempre que sea posible, evite las ACL de salida. En un sistema con Motor 0, 1 y 2 LC, todo el procesamiento de las ACL se realiza en la LC entrante. Hasta el filtrado ACL de salida se realiza en la tarjeta de entrada una vez que sabe a cuál interfaz de salida se dirige el paquete. Por este motivo, la configuración de la ACL saliente en la interfaz afecta todas las LC en el sistema. Además, las LC de motor 2 pueden ejecutar ACL entrantes o salientes, pero no ambas simultáneamente en el ASIC que realiza reenvío de hardware. Si configura las ACL de entrada y de salida, la LC recurre al reenvío basado en la CPU para las listas de acceso salientes provocando un impacto en el rendimiento de la conmutación de la LC. Sin embargo, los motores más nuevos como el Motor 3 y el Motor 4+ están altamente optimizados para prestar servicios IP mejorados como las ACL y las ACL de salida de procesos en la LC saliente.
-
Asigne el tráfico que requiera funciones específicas a un conjunto de LC.
-
Asigne tráfico que no requiera características para otro conjunto de LC para mantener un rendimiento pico del reenvío de paquetes .
-
Utilice LCs con tipos de motores más elevados cuando se necesita un rendimiento superior.
-
Diseñe la estructura básica (o núcleo) orientado hacia las tarjetas de línea (LC) para ejecutar las funciones admitidas por el hardware o el microcódigo.
Caso Práctico
Este caso práctico muestra cómo solucionar los errores ignorados en aumento en una interfaz de un LC en la ranura 6.
Paso 1 - Verificar las colas ToFab en la ranura 6.
Router#exec slot 6 show controllers tofab queue
========= Line Card (Slot 6) =======
Carve information for ToFab buffers
SDRAM size: 134217728 bytes, address: 30000000, carve base: 30019100
134115072 bytes carve size, 4 SDRAM bank(s), 8192 bytes SDRAM pagesize,
2 carve(s)
max buffer data size 4544 bytes, min buffer data size 80 bytes
174538/174538 buffers specified/carved
110797216/110797216 bytes sum buffer sizes specified/carved
Qnum Head Tail #Qelem LenThresh
---- ---- ---- ------ ---------
4 non-IPC free queues:
88964/88964 (buffers specified/carved), 50.97%, 80 byte data size
1 21120 84604 81074 262143
54076/54076 (buffers specified/carved), 30.98%, 608 byte data size
2 122270 116965 49567 262143
26165/26165 (buffers specified/carved), 14.99%, 1568 byte data size
3 164160 145355 19518 262143
!-- Out of the 26165 buffers that are carved, only 19518 are available
5233/5233 (buffers specified/carved), 2.99%, 4544 byte data size
4 172325 172088 5233 262143
IPC Queue:
100/100 (buffers specified/carved), 0.5%, 4112 byte data size
30 61 60 100 262143
Raw Queue:
31 44229 88895 0 43634
!-- The Raw Queue has a low or 0 value for the #Qelem column, indicating !-- that the CPU is not overwhelmed with packets destined to it.
ToFab Queues:
Dest
Slot
0 73769 60489 0 262143
1 7909 27395 0 262143
2 61416 71346 0 262143
3 80352 14567 0 262143
4 138236 107121 18955 262143
!-- 18955 packets are waiting for space in the outbound queues !-- on the LC in slot 4.
5 4852 48171 0 262143
6 98318 111757 0 262143
7 44229 88895 0 262143
8 0 0 0 262143
9 0 0 0 262143
10 0 0 0 262143
11 0 0 0 262143
12 0 0 0 262143
13 0 0 0 262143
14 0 0 0 262143
15 0 0 0 262143
Multicast 0 0 0 262143
Paso 2: verifique FrFab queues en la ranura 4.
Dado que la salida de cola ToFab indicó un gran número de paquetes en cola destinados a la LC en la ranura 4, verifique las colas FrFab en esta LC.
Router#exec slot 4 show controllers frfab queue
========= Line Card (Slot 4) =======
Carve information for FrFab buffers
SDRAM size: 67108864 bytes, address: 20000000, carve base: 2002D100
66924288 bytes carve size, 0 SDRAM bank(s), 0 bytes SDRAM pagesize,
2 carve(s)
max buffer data size 4544 bytes, min buffer data size 80 bytes
65534/65534 buffers specified/carved
66789056/66789056 bytes sum buffer sizes specified/carved
Qnum Head Tail #Qelem LenThresh
---- ---- ---- ------ ---------
4 non-IPC free queues:
26174/26174 (buffers specified/carved), 39.93%, 80 byte data size
1 10123 4332 14515 65535
19630/19630 (buffers specified/carved), 29.95%, 608 byte data size
2 27898 37167 12279 65535
13087/13087 (buffers specified/carved), 19.96%, 1568 byte data size
3 0 52275 0 65535
!-- Zero buffers available for this pool
6543/6543 (buffers specified/carved), 9.98%, 4544 byte data size
4 60805 60804 6543 65535
IPC Queue:
100/100 (buffers specified/carved), 0.15%, 4112 byte data size
30 75 74 100 65535
Raw Queue:
31 0 80 0 65535
Interface Queues:
0 0 39413 0 65535
1 0 44192 0 65535
2 48426 58230 32111 65535
!-- Interface 2 is using half or 32111 of the carved packet buffers
3 0 41219 0 65535
Paso 3. Compare la salida de los comandos de interfaces show para la misma interfaz oversubscribed.
Haga coincidir la interfaz con exceso de suscriptores que se indica en la salida de show controllers frfab queue con la salida de show interfaces para la misma interfaz. El siguiente resultado confirma que la velocidad del interfaz de salida está a la misma velocidad de la línea y se encuentra excedida de suscriptores:
Router#show interfaces POS 4/2
POS4/2 is up, line protocol is up
Hardware is Packet over SONET
Description: Pacbell OC3 to other ISP...
Internet address is 10.10.10.10/30
MTU 4470 bytes, BW 155000 Kbit, DLY 100 usec, rely 255/255, load 156/255
Encapsulation HDLC, crc 32, loopback not set
Keepalive set (10 sec)
Scramble enabled
Last input 00:00:01, output 00:00:03, output hang never
Last clearing of "show interface" counters never
Queueing strategy: FIFO Output queue 0/300, 0 drops; input queue 0/300,
0 drops
5 minute input rate 20274000 bits/sec, 6263 packets/sec
5 minute output rate 148605000 bits/sec, 28776 packets/sec
!-- The output interface rate is at line rate which means that the interface !-- is oversubscribed.
1018621328 packets input, 2339977099 bytes, 0 no buffer
Received 0 broadcasts, 1 runts, 0 giants, 0 throttles
0 parity
1 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
378645 packets output, 156727974 bytes, 0 underruns
0 output errors, 0 applique, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
1 carrier transitions
Paso 4 - Implementar una solución.
Consulte las secciones de las soluciones de este documento para los próximos pasos para solucionar los errores ignorados incrementados sobre la base de la arquitectura de la interfaz de salida particular. Por ejemplo, en un Motor 0 LC, intente desviar parte del tráfico hacia otra interfaz o, como medida temporaria, reducir el número de búfers de paquetes que puede usar esta interfaz en particular desde las colas libres de las tarjetas de línea. Use el siguiente comando:
Router(config)#int POS 4/2 Router(config-if)#tx-queue-limit 5000
Errores de software de Cisco IOS
En algunas ocasiones, los contadores aumentan debido a un defecto en el software del IOS de Cisco. Asegúrese de que está ejecutando en su tren la última versión disponible del IOS de Cisco, a fin de eliminar todo error que ya se haya corregido. Si todavía ve paquetes ignorados y la información en este documento no resuelve su problema, comuníquese con Cisco Technical Assistance Center (TAC) para obtener asistencia.
Información Relacionada
- Resolución de problemas de caídas de entradas en el router de Internet de la serie 12000 de Cisco
- Cómo leer el resultado del comando show controllers frfab Comandos | tofab queue
- Detección temprana aleatoria ponderada en el router de Internet de la serie 12000 de Cisco
- Configuración de MPLS CoS en un Cisco 12000 Series GSR Router
- Cómo TCP maneja la pérdida de tráfico
- Cómo interactúa el router con TCP
- Configuración de la velocidad de acceso comprometida
- Notas de la versión de los routers de la serie Cisco 12000
- Soporte Técnico y Documentación - Cisco Systems
ComentariosContacte a Cisco
- Abrir un caso de soporte
- (Requiere un Cisco Service Contract)