Solución de problemas de paquetes ignorados e interrupciones por falta de memoria en el router de Internet de la serie Cisco 12000

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 los consejos de Troubleshooting para un número creciente de ningunos descensos del mem en la salida de los reguladores de la demostración del <slot-> del execute-on slot (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: Una cantidad creciente de descartes de la cola de entrada, como se muestra en el resultado de show interfaces, se aborda en Resolución de problemas de descarte de entrada en el router de Internet de la serie 12000 de Cisco.

prerrequisitos

Requisitos

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 la salida del frfab de los reguladores de la demostración |

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. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). 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 Cisco 12000 Series Internet Router utiliza una arquitectura distribuida para asegurar el 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. Estos almacenes intermedios del paquete varían de tamaño y se diseñan generalmente soportar la Unidad máxima de transmisión (MTU) (MTU) - las tramas clasificadas.

Después de que determine la interfaz de salida para un paquete, el Forwarding Processor hace el siguiente:

1. 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.

2. 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.

3. La tarjeta de línea saliente almacena los paquetes en la memoria intermedia.

4. 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 de salida es oversubscribed, comienza a mitigar los paquetes en exceso. Durante los periodos de sobresuscripción continua, las colas de transmisión salientes LC 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 de entrada comienza a mitigar los paquetes en exceso.	Errores ignorados en el resultado del comando show interfaces y/o no hay pérdidas de memoria en el resultado del comando slot <número de ranura> show controllers tofab QM stat de la LC de entrada, según su motor de reenvío L3. ¹
Motor 2, 3, 4	Cae cualquier paquete en exceso en la salida.	Ningún mem cae en el comando execute-on slot <slot-> show controllers frfab QM stat hecho salir en el 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 discordancía en las tarifas de la interfaz, los errores ignorados pueden incrementar cuando el índice de paquetes de llegada es mayor que el CPU pueden 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. Ésta es la caja para el motor 0 LC donde las porciones de características se implementan en el software. Sin embargo, en motores posteriores, casi todas las características se implementan en hardware. Por ejemplo, Motor 3 (motor de los Servicios IP - El ISE) y linecards del motor 4+ se diseña para las aplicaciones de borde y implementa los servicios del IP mejorado (tales como calidad de servicio - QoS) en hardware sin el impacto del 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 a los errores ignorados y a ningunos descensos del mem causados por el oversubscription de la interfaz de salida es lo mismo para motor L3 el tipo -- prevenga el hambre del buffer. 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.

Aquí está una salida de muestra del comando show interfaces con un contador ignorado no nulo en un Cisco 12000 Series Router:

router#show interfaces G3/0GigabitEthernet3/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 entonces mitiga los paquetes en exceso en sus colas de administración del tráfico del tofab correspondiente a este slot 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

El linecards usando motor L3 una arquitectura más reciente no utiliza 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. Del bajar el mecanismo se ha implementado solamente para el LC de motor 2 en el lado del 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 controllerfrfab 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" counter0 rawq drops, 0 global red drops, 0 global force drops0 no memory (ns), 0 no memory hwm (Ns)no free queue0       0       0       00       0       0       00       0       0       00       0       0       00 multicast dropsTx Counts Interface 08390658710246 TX bytes, 2098330790 TX pkts, 212452 kbps, 6641 pps Interface 10 TX bytes, 0 TX pkts, 0 kbps, 0 PPS Interface 20 TX bytes, 0 TX pkts, 0 kbps, 0 PPS Interface 30 TX bytes, 0 TX pkts, 0 kbps, 0 PPS

Usted necesita encontrar una manera de evitar que el lado del frfab mitigue a la punta donde el LC cualquiera sostiene a la interfaz de entrada o cae simplemente los paquetes.

Una solución simple para todo el linecards, excepto el LC de motor 2, es reducir la cantidad de búfers disponible a una interfaz de salida particular en una multi-interfaz LC. 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 el linecards del motor 2-based.

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, que nos da un tubo más grande. Pero tubos más grandes pueden llenar rápidamente. Así, la solución recomendada es implementar los mecanismos del Calidad de Servicio (QoS) en el LC saliente.

La característica del Weighted Random Early Detection (WRED) de Cisco implementa un mecanismo de descarte distinguido 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. Los otros motor L3 LC soportan el WRED en hardware.

Para más información sobre configurar el WRED, refiera a estos documentos:

• Detección temprana aleatoria ponderada en el router de Cisco serie 12000

• Configurar 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 el TCP maneja la pérdida de tráfico y cómo el router obra recíprocamente con el TCP para más información sobre cómo el TCP reacciona a la pérdida del paquete.

Otro mecanismo de Calidad de servicio (QoS) soportado en las Cisco 12000 Series es Vigilancia de tráfico usando el Committed Access Rate (CAR) en el motor 0 y el motor 1 LC, y una versión modificada del CAR sabida según el control de velocidad de interfaz (PIRC) en el 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). Usted comenzará a conseguir los paquetes ignorados porque el CPU no puede continuar con la cantidad de paquetes. ¡Estos paquetes se dirigen al CPU del LC, no al Gigabit Route Processor (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 éste es el caso, usted debe actuar por consiguiente quitando la característica o actualizando el Cisco IOS Software a una versión posterior donde se mejora la misma implementación de la característica (por ejemplo 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 depende realmente del tipo de motor del 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: El Motor 3 (Motor de servicios IP - ISE) y las tarjetas de línea del Motor 4+ están diseñados para aplicaciones Edge y para implementar servicios IP optimizados (como QoS) en hardware sin impacto sobre 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 el motor 0, 1 y 2 LC, todo el proceso de los ACL se hacen en el 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 requiere las características específicas a un conjunto de los 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.

Puesto que el resultado de la cola tofab indicó un gran número de paquetes en cola destinados para el LC en el slot 4, marque las colas de administración del tráfico del frfab en este 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/2POS4/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/2Router(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 usted todavía ve los paquetes ignorados, y la información en este documento no soluciona su problema, entran en contacto el Centro de Asistencia Técnica (TAC) de Cisco para la ayuda.

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 la salida del frfab de los reguladores de la demostración |
• Weighted Random Early Detection en el Cisco 12000 Series Internet Router
• Configurar 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
• Release Note de los Cisco 12000 Series Router
• Soporte Técnico y Documentación - Cisco Systems