Utilizando la nueva función de captura de paquetes

Cuando se solucionan problemas sobre pérdida de paquetes en un lugar remoto donde no está disponible un sniffer de paquetes, es difícil aislar el problema en LAN o WAN. En el nuevo Cisco IOS 12.4(20)T hay una característica de captura de paquetes. Los filtros se pueden aplicar basándose en el nombre de la interfaz, dirección, ACL, e incluso si debe ser llevado al nivel de proceso.

La referencia de comandos de configuración está disponible en la página Solución y Gestión de Problemas en la sección infraestructura de la captura de paquetes.

Contenido

[hide]

  • 3 Notas Importantes

Problema de ejemplo

Vamos a ver un ejemplo de cómo usarlo para depurar un problema de pérdida de paquetes

Topología

La topología para el ejercicio es:

untitled.JPG

Las direcciones IP son:

RouterA Ethernet 0/0: 10.10.10.1/255.255.255.0

CaptureRouter Ethernet 0/0: 10.10.10.2/255.255.255.0

CaptureRouter Ethernet 1/0: 10.10.20.1/255.255.255.0

RouterB Ethernet 1/0: 10.10.20.2/255.255.255.0

Declaración de problema

Cuando hacemos ping del RouterA al RouterB con paquetes de 100 bytes no hay pérdida de paquetes. Sin embargo, usando paquetes de 1000 bytes, el resultado en la pérdida es del 50%.

Primero intentamos un ping con paquetes de 100 bytes:


RouterA#ping 10.10.20.2 size 100 repeat 4 timeout 1

Type escape sequence to abort.
Sending 4, 100-byte ICMP Echos to 10.10.20.2, timeout is 1 seconds:
!!!!
Success rate is 100 percent (4/4), round-trip min/avg/max = 1/4/12 ms

Luego intentamos con paquetes de 1000 bytes:


RouterA#ping 10.10.20.2 size 1000 repeat 4 timeout 1
Type escape sequence to abort.
Sending 4, 1000-byte ICMP Echos to 10.10.20.2, timeout is 1 seconds:
!.!.
Success rate is 50 percent (2/4), round-trip min/avg/max = 1/34/68 ms

Resolución De Problemas

Hagamos la suposición que como el administrador de la red usted tiene solamente acceso al CaptureRouter y usted necesita probar si la pérdida del paquete está en ese dispositivo. El primer paso es determinar si los paquetes están realmente entrando al CaptureRouter.                                    Previamente uno podría utilizar varias cosas tales como un ingreso de ACL y mirar los contadores de aciertos o configurar el netflow en la interfaz de ingreso. Este ejercicio nos muestra cómo utilizar la característica de la captura de paquetes para aislar la pérdida.

  • Todos los comandos se hacen en el      prompt EXEC así que el acceso a la configuración no se requiere a menos      que usted necesite definir una lista de acceso (ACL) para hacer la captura      más granular.
  • Los pasos siguientes son      necesarios para capturar las tramas:
  1. Definir un buffer de captura -      > Aquí es donde se salvan las tramas una vez capturadas.
  2. Definir un punto de captura -      > Esto da al usuario la habilidad de ser más puntual sobre que interfaz      y ruta de Switching las tramas son capturadas.
  3. Asociar el punto de captura con      el buffer de captura - > Usted puede asociar múltiples puntos al mismo      buffer.
  4. Comenzar      la captura
  5. Ver la captura y/o exportarla a      un archivo PCAP para el análisis fuera de línea.

Ejemplo de Troubleshooting

Veamos cada uno de estos pasos para definir una captura de paquetes para las tramas con las características siguientes en el CaptureRouter:

  • La captura del paquete se      filtra para que las tramas correspondan solamente con los paquetes icmp      entre la fuente/destino del flujo del ping.

Primero configurar el ACL para filtrar la ruta. Esto requiere el acceso a la configuración porque ésa es actualmente la única manera de definir el ACL.

CaptureRouter#config t
Enter configuration commands, one per line.  End with CNTL/Z.
CaptureRouter(config)#access-list 144 permit icmp host 10.10.10.1 host 10.10.20.2
CaptureRouter(config)#access-list 144 permit icmp host 10.10.20.2 host 10.10.10.1
CaptureRouter(config)#end

Esto produce una lista de acceso que corresponde solamente con los paquetes icmp entre esas dos direcciones IP.

El buffer de la captura necesita después ser creado por el paso 1:

CaptureRouter#monitor capture buffer holdpackets
CaptureRouter#monitor capture buffer holdpackets ?
  circular  Circular Buffer
  clear     Clear contents of capture buffer
  export    Export in Pcap format
  filter    Configure filters
  limit     Limit the packets dumped to the buffer
  linear    Linear Buffer(Default)
  max-size  Maximum size of element in the buffer (in bytes)
  size      Packet Dump buffer size (in Kbytes)
  <cr>
CaptureRouter#monitor capture buffer holdpackets filter access-list 144
Filter Association succeeded

CaptureRouter#

Después en el paso 2 configura el punto de la captura:

CaptureRouter#monitor capture point ip cef icmptrace all both
CaptureRouter#
*Sep 11 15:51:06.395: %BUFCAP-6-CREATE: Capture Point icmptrace created.
CaptureRouter#

Hay muchas más opciones de filtro bajo el comando monitor capture point que se pueden utilizar para filtrar aún más, tales como nombre de la interfaz, dirección, trayectoria de la ruta, etc.


CaptureRouter#monitor capture point ip cef icmptrace ?
  Serial             Serial
  Tunnel             Tunnel interface
  all                All interfaces
  drop               Drop on any interface
  punt               Punt on any interface

Acabamos de configurar esta ruta para capturar en la trayectoria CEF las tramas que entran y salen en cualquier interfaz en el router desde que aplicamos el filtro ACL para limitar las tramas capturadas en el buffer.

El paso 3 es asociar el punto de la captura con el buffer de la captura:


CaptureRouter#monitor capture point associate icmptrace holdpackets

Paso 4 Comienzo de la captura:


CaptureRouter#monitor capture point start icmptrace

Ahora enviar los 4 paquetes para simular el problema.


RouterA#ping 10.10.20.2 size 1000 repeat 4 timeout 1

Type escape sequence to abort.
Sending 4, 1000-byte ICMP Echos to 10.10.20.2, timeout is 1 seconds:
!.!.
Success rate is 50 percent (2/4), round-trip min/avg/max = 1/14/28 ms

RouterA#

Mirando el CaptureRouter vemos 10 paquetes que corresponden en el buffer:

CaptureRouter#show monitor capture buffer holdpackets parameters
Capture buffer holdpackets (linear buffer)
Buffer Size : 262144 bytes, Max Element Size : 68 bytes, Packets : 10
Allow-nth-pak : 0, Duration : 0 (seconds), Max packets : 0, pps : 0
Associated Capture Points:
Name : icmptrace, Status : Active
Configuration:
monitor capture buffer holdpackets
monitor capture point associate icmptrace holdpackets
monitor capture buffer holdpackets filter access-list 144

¿Cuántos paquetes habrían aparecido en el buffer si los 4 paquetes de ping hubieran sido exitosos? La respuesta es 16. La razón es que nosotros configuramos la ruta en el ingreso y la salida. Entonces para cada paquete que transita la caja, el buffer consideraría la trama en el ingreso y en la salida. Entonces para cada ping esta la petición de eco y la respuesta de eco, así que para un solo ping su respuesta consideraría 4 paquetes en el buffer. 4 ping fueron enviados de modo que habrá un total de 16 tramas.

El buffer se puede vaciar para ver la carga útil llena mediante el comando show monitor capture buffer holdpackets dump.

Mirando el buffer aquí están las 4 tramas para el primer ping exitoso:


CaptureRouter#show monitor capture buffer holdpackets dump
18:22:57.946 EST Sep 11 2008 : IPv4 LES CEF    : Et0/0 None
042F3400: AABBCC01 F600AABB CC01F500 08004500  *;L.v.*;L.u...E.
042F3410: 03E8006E 0000FE01 86900A0A 0A010A0A  .h.n..~.........
042F3420: 14020800 12130015 00000000 000000F6  ...............v
042F3430: 6BA4ABCD ABCDABCD ABCDABCD ABCDABCD  k$+M+M+M+M+M+M+M
042F3440: ABCDABCD 00                          +M+M.          
18:22:57.946 EST Sep 11 2008 : IPv4 LES CEF    : Et0/0 Et1/0
042F3400: AABBCC01 F701AABB CC01F601 08004500  *;L.w.*;L.v...E.
042F3410: 03E8006E 0000FE01 86900A0A 0A010A0A  .h.n..~.........
042F3420: 14020800 12130015 00000000 000000F6  ...............v
042F3430: 6BA4ABCD ABCDABCD ABCDABCD ABCDABCD  k$+M+M+M+M+M+M+M
042F3440: ABCDABCD 00                          +M+M.          
18:22:57.946 EST Sep 11 2008 : IPv4 LES CEF    : Et1/0 None
042F3400: AABBCC01 F601AABB CC01F701 08004500  *;L.v.*;L.w...E.
042F3410: 03E8006E 0000FE01 86900A0A 14020A0A  .h.n..~.........
042F3420: 0A010000 1A130015 00000000 000000F6  ...............v
042F3430: 6BA4ABCD ABCDABCD ABCDABCD ABCDABCD  k$+M+M+M+M+M+M+M
042F3440: ABCDABCD 00                          +M+M.          
18:22:57.946 EST Sep 11 2008 : IPv4 LES CEF    : Et1/0 Et0/0
042F3400: AABBCC01 F500AABB CC01F600 08004500  *;L.u.*;L.v...E.
042F3410: 03E8006E 0000FE01 86900A0A 14020A0A  .h.n..~.........
042F3420: 0A010000 1A130015 00000000 000000F6  ...............v
042F3430: 6BA4ABCD ABCDABCD ABCDABCD ABCDABCD  k$+M+M+M+M+M+M+M
042F3440: ABCDABCD 00                          +M+M.          

Esto tiene sentido, como la primera trama que entro en E0/0 hace una búsqueda de reenvío y la manda por E1/0 para la petición de eco. La Respuesta de eco regresa por E1/0, hace una búsqueda de reenvío y la devuelve hacia 10.10.10.1 por E0/0.

Mirando los dos paquetes siguientes vemos:

18:22:57.966 EST Sep 11 2008 : IPv4 LES CEF    : Et0/0 None
042F3400: AABBCC01 F600AABB CC01F500 08004500  *;L.v.*;L.u...E.
042F3410: 03E8006F 0000FE01 868F0A0A 0A010A0A  .h.o..~.........
042F3420: 14020800 11F20015 00010000 000000F6  .....r.........v
042F3430: 6BC4ABCD ABCDABCD ABCDABCD ABCDABCD  kD+M+M+M+M+M+M+M
042F3440: ABCDABCD 00                          +M+M.          
18:22:58.966 EST Sep 11 2008 : IPv4 LES CEF    : Et0/0 None
042F3400: AABBCC01 F600AABB CC01F500 08004500  *;L.v.*;L.u...E.
042F3410: 03E80070 0000FE01 868E0A0A 0A010A0A  .h.p..~.........
042F3420: 14020800 0E090015 00020000 000000F6  ...............v
042F3430: 6FACABCD ABCDABCD ABCDABCD ABCDABCD  o,+M+M+M+M+M+M+M
042F3440: ABCDABCD 00                          +M+M.          


Espera, eso no parece correcto porque no vemos que la trama se reenvió hacia fuera de la interfaz E1/0. Eso nos dice que la trama entro y CEF la vio pero por alguna razón la trama no fue enviada hacia la interfaz de la salida E1/0. Por lo tanto checa la configuración de la interfaz en la trayectoria. Al hacer eso encontramos la causa raíz para este problema.

La interfaz de salida E1/0 tiene una política de calidad de servicio (QoS) para limpiar el tráfico y con los tamaños de trama más grandes excede la política.


CaptureRouter#show run int Ethernet1/0
Building configuration

interface Ethernet1/0
ip address 10.10.20.1 255.255.255.0
load-interval 30
service-policy output police
end

CaptureRouter#show policy-map interface Ethernet1/0
Ethernet1/0

  Service-policy output: police

    Class-map: class-default (match-any)
      69 packets, 10718 bytes
      30 second offered rate 0 bps, drop rate 0 bps
      Match: any
      police:
          cir 8000 bps, bc 1500 bytes
        conformed 2 packets, 2028 bytes; actions:
          transmit
        exceeded 2 packets, 2028 bytes; actions:
          drop
        conformed 0 bps, exceed 0 bps

Este ejemplo tiene la capacidad de capturar los paquetes en el ingreso y la salida para aislar que las caídas de paquetes sucedían de hecho en el dispositivo. El CaptureRouter en este ejemplo vio las tramas entrar en la ruta pero no fueron enviadas hacia afuera así que el foco entonces fue puesto en el dispositivo mismo. Si la ruta hubiera mostrado la salida del paquete fuera de la caja el foco se habría movido en dirección del destino del paquete.

Era más fácil ver la inconsistencia filtrando el buffer de la siguiente manera:


CaptureRouter#show monitor capture buffer holdpackets dump | include LES
17:39:38.691 EST Sep 11 2008 : IPv4 LES CEF    : Et0/0 None
17:39:38.691 EST Sep 11 2008 : IPv4 LES CEF    : Et0/0 Et1/0
17:39:38.691 EST Sep 11 2008 : IPv4 LES CEF    : Et1/0 None
17:39:38.691 EST Sep 11 2008 : IPv4 LES CEF    : Et1/0 Et0/0
17:39:38.711 EST Sep 11 2008 : IPv4 LES CEF    : Et0/0 None
17:39:39.711 EST Sep 11 2008 : IPv4 LES CEF    : Et0/0 None
17:39:39.711 EST Sep 11 2008 : IPv4 LES CEF    : Et0/0 Et1/0
17:39:39.711 EST Sep 11 2008 : IPv4 LES CEF    : Et1/0 None
17:39:39.711 EST Sep 11 2008 : IPv4 LES CEF    : Et1/0 Et0/0
17:39:39.715 EST Sep 11 2008 : IPv4 LES CEF    : Et0/0 None

Muestra que el 2do ECO ICMP (el 5to paquete) no fue reenviado a través de la caja.

Habría sido incluso más fácil analizar si el búfer es exportado vía PCAP y analizarlo en Wireshark u otra aplicación de sniffer.

Esto se habría podido hacer mediante:


CaptureRouter#monitor capture buffer holdpackets export tftp://10.10.10.1/captureut.pcap


10.10.10.1 es la dirección IP del servidor TFTP y captureout.pcap es el archivo que ya esta creado en el servidor TFTP y los privilegios son fijados para permitirle el acceso de escritura.

Para hacer un punto de vista más corto aquí está la secuencia de comandos que hay que ejecutar desde el inicio hasta el final:


CaptureRouter#config t
Enter configuration commands, one per line.  End with CNTL/Z.
CaptureRouter(config)#access-list 144 permit icmp host 10.10.10.1 host 10.10.20.2
CaptureRouter(config)#access-list 144 permit icmp host 10.10.20.2 host 10.10.10.1
CaptureRouter(config)#end
CaptureRouter#monitor capture buffer holdpackets
CaptureRouter#monitor capture buffer holdpackets filter access-list 144
CaptureRouter#monitor capture point ip cef icmptrace all both
CaptureRouter#monitor capture point associate icmptrace holdpackets
CaptureRouter#monitor capture point start icmptrace


Para ver todos los buffers de captura:


CaptureRouter#show monitor capture buffer all parameters
Capture buffer holdpackets (linear buffer)
Buffer Size : 262144 bytes, Max Element Size : 68 bytes, Packets : 10
Allow-nth-pak : 0, Duration : 0 (seconds), Max packets : 0, pps : 0
Associated Capture Points:
Name : icmptrace, Status : Inactive
Configuration:
monitor capture buffer holdpackets
monitor capture point associate icmptrace holdpackets

Para ver todos los puntos de captura:


CaptureRouter#show monitor capture point all
Status Information for Capture Point icmptrace
IPv4 CEF
Switch Path: IPv4 CEF            , Capture Buffer: holdpackets        
Status : Inactive

Configuration:
monitor capture point ip cef icmptrace all both

Para detener una ruta:

CaptureRouter#monitor capture point stop icmptrace       
CaptureRouter#
*Sep 12 17:35:54.121: %BUFCAP-6-DISABLE: Capture Point icmptrace disabled.

Para quitar un punto de captura usted tiene que ejecutar el comando entero para la configuración del punto:

CaptureRouter#no monitor capture point ip cef icmptrace all both
CaptureRouter#
*Sep 12 17:37:14.417: %BUFCAP-6-DELETE: Capture Point icmptrace deleted.

Y para borrar el buffer de captura:

CaptureRouter#no monitor capture buffer holdpackets
Capture Buffer deleted

Notas importantes

Un par de cosas que hay que recordar con esta característica de la captura.

  • Trabaja solamente para paquetes      IP para el dispositivo o que atraviese el dispositivo.
  • Capturará solamente los      paquetes multicast en el ingreso y no capturará los paquetes replegados en      la salida.
  • No capturará las tramas      encapsuladas MPLS.
  • Se implementa al principio del      vector que conmuta en el ingreso y muy cercano al final del vector que      conmuta en la salida. Por lo tanto, si la trama no es vista en una ruta de      ingreso es muy improbable que la trama sea hecha para el dispositivo      porque el único lugar donde podría ser tirada seria en la interfaz de      ingreso antes de que la trama sea entregada al vector que conmuta para      procesamiento. En la salida también, si la ruta dice que el paquete fue      reenviado es muy probable que la trama se hizo hacia fuera hacia el      siguiente salto a menos que fuera tirada por el código del driver de      salida.
  • El archivo de captura solamente      se podría exportar fuera de la caja en la primera implementación pero la      capacidad de salvar localmente en el dispositivo fue agregada en un estado      posterior.
  • Cuando el punto de captura se      configura en una interfaz de túnel GRE, se captura el tráfico de datos de salida      después de que la encapsulación de túnel se aplique al paquete, mientras      que en la dirección de ingreso, los paquetes de datos se capturan sin la      encapsulación de túnel.
  • Hay una limitación con usar el      EPC en un IPSec VTI (interfaz de túnel virtual), donde los paquetes de      datos de salida no se capturan si el buffer de captura se asocia a un      filtro que corresponda con el flujo IP de pre-encapsulación.

- Rodney Dunn, TAC de Cisco

Para recibir la información más reciente sobre las herramientas en línea de Cisco, las certificaciones, la documentación de soporte, las observaciones de los expertos de Cisco y los acontecimientos próximos visita Cisco Technical Services Newsletter.

Historial de versiones
Revisión n.º
1 de 1
Última actualización:
‎11-29-2011 11:32 AM
Actualizado por:
 
Etiquetas (1)