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.
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 diversas técnicas de análisis de captura de paquetes que tienen como objetivo resolver de manera efectiva los problemas de la red. Todos los escenarios presentados en este documento se basan en casos reales de usuario que se ven en el Cisco Technical Assistance Center (TAC). El documento cubre las capturas de paquetes desde el punto de vista de un firewall de última generación (NGFW) de Cisco, pero los mismos conceptos se aplican también a otros tipos de dispositivos.
Cisco recomienda que tenga conocimiento sobre estos temas:
Además, antes de empezar a analizar las capturas de paquetes, es muy recomendable cumplir estos requisitos:
La información que contiene este documento se basa en las siguientes versiones de software y hardware.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.
La captura de paquetes es una de las herramientas de resolución de problemas más ignoradas disponibles hoy en día. Cada día, Cisco TAC resuelve muchos problemas de los clientes analizando los datos recopilados. El objetivo de este documento es ayudar a los ingenieros de redes y seguridad a identificar y resolver problemas comunes de red basados principalmente en el análisis de captura de paquetes.
En el caso de una aplicación Firepower (1xxx, 21xx, 41xx, 93xx) y Firepower Threat Defense (FTD), se puede visualizar un procesamiento de paquetes como se muestra en la imagen.
Según la arquitectura mostrada, las capturas de FTD se pueden realizar en 3 lugares diferentes:
El proceso se describe en este documento:
Las capturas de FXOS sólo se pueden tomar en la dirección de ingreso desde el punto de vista del switch interno se muestran en la imagen aquí.
Como se muestra en la imagen, estos son dos puntos de captura por dirección (debido a la arquitectura de switch interna).
Los paquetes capturados en los puntos 2, 3 y 4 tienen una etiqueta de red virtual (VNTag).
Nota: Las capturas a nivel de chasis FXOS sólo están disponibles en las plataformas FP41xx y FP93xx. FP1xxx y FP21xx no proporcionan esta capacidad.
Puntos de captura principales:
Puede utilizar Firepower Management Center User Interface (FMC UI) o FTD CLI para habilitar y recopilar las capturas de Lina FTD.
Habilite la captura desde CLI en la interfaz INSIDE:
firepower# capture CAPI interface INSIDE match icmp host 192.168.103.1 host 192.168.101.1
Esta captura coincide con el tráfico entre las IP 192.168.103.1 y 192.168.101.1 en ambas direcciones.
Habilite la captura ASP para ver todos los paquetes descartados por el motor FTD Lina:
firepower# capture ASP type asp-drop all
Exportar una captura Lina FTD a un servidor FTP:
firepower# copy /pcap capture:CAPI ftp://ftp_username:ftp_password@192.168.78.73/CAPI.pcap
Exportar una captura Lina FTD a un servidor TFTP:
firepower# copy /pcap capture:CAPI tftp://192.168.78.73
A partir de la versión 6.2.x de FMC, puede habilitar y recopilar capturas de Lina de FTD desde la interfaz de usuario de FMC.
Otra forma de recopilar capturas de FTD de un firewall gestionado por FMC es esta.
Paso 1
En caso de captura de LINA o ASP, copie la captura en el disco FTD, por ejemplo:
firepower# copy /pcap capture:capin disk0:capin.pcap Source capture name [capin]? Destination filename [capin.pcap]? !!!!
Paso 2
Vaya al modo experto, localice la captura guardada y cópiela en la ubicación /ngfw/var/common:
firepower# Console connection detached. > expert admin@firepower:~$ sudo su Password: root@firepower:/home/admin# cd /mnt/disk0 root@firepower:/mnt/disk0# ls -al | grep pcap -rwxr-xr-x 1 root root 24 Apr 26 18:19 CAPI.pcap -rwxr-xr-x 1 root root 30110 Apr 8 14:10 capin.pcap -rwxr-xr-x 1 root root 6123 Apr 8 14:11 capin2.pcap root@firepower:/mnt/disk0# cp capin.pcap /ngfw/var/common
Paso 3
Inicie sesión en el FMC que administra el FTD y navegue hasta Dispositivos > Administración de dispositivos. Localice el dispositivo FTD y seleccione el icono Troubleshooting:
Paso 4
Seleccione Resolución de problemas avanzada:
Especifique el nombre del archivo de captura y seleccione Descargar:
Para obtener más ejemplos sobre cómo habilitar/recopilar capturas de la interfaz de usuario de FMC, consulte este documento:
El punto de captura se muestra en la imagen aquí.
Habilite la captura de nivel Snort:
> capture-traffic Please choose domain to capture traffic from: 0 - br1 1 - Router Selection? 1 Please specify tcpdump options desired. (or enter '?' for a list of supported options) Options: -n host 192.168.101.1
Para escribir la captura en un archivo con el nombre capture.pcap y copiarla a través de FTP en un servidor remoto:
> capture-traffic Please choose domain to capture traffic from: 0 - br1 1 - Router Selection? 1 Please specify tcpdump options desired. (or enter '?' for a list of supported options) Options: -w capture.pcap host 192.168.101.1 CTRL + C <- to stop the capture
> file copy 10.229.22.136 ftp / capture.pcap Enter password for ftp@10.229.22.136: Copying capture.pcap Copy successful. >
Para obtener más ejemplos de captura de nivel Snort que incluyan diferentes filtros de captura, consulte este documento:
La topología se muestra en la imagen aquí:
Descripción de problemas: HTTP no funciona
Flujo afectado:
IP de servidor: 192.168.0.100
Dst IP: 10.10.1.100
Protocolo: TCP 80
Habilitar capturas en el motor FTD LINA:
firepower# capture CAPI int INSIDE match ip host 192.168.0.100 host 10.10.1.100 firepower# capture CAPO int OUTSIDE match ip host 192.168.0.100 host 10.10.1.100
Capturas - Escenario funcional:
Como base, siempre es muy útil tener capturas de un escenario funcional.
La captura realizada en la interfaz INTERNA de NGFW es como se muestra en la imagen:
Puntos clave:
La captura tomada en la interfaz NGFW OUTSIDE, se muestra en la imagen aquí:
Puntos clave:
Capturas: escenario no funcional
Desde la CLI del dispositivo, las capturas se ven de la siguiente manera:
firepower# show capture capture CAPI type raw-data interface INSIDE [Capturing - 484 bytes] match ip host 192.168.0.100 host 10.10.1.100 capture CAPO type raw-data interface OUTSIDE [Capturing - 0 bytes] match ip host 192.168.0.100 host 10.10.1.100
Contenido de CAPI:
firepower# show capture CAPI 6 packets captured 1: 11:47:46.911482 192.168.0.100.3171 > 10.10.1.100.80: S 1089825363:1089825363(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 2: 11:47:47.161902 192.168.0.100.3172 > 10.10.1.100.80: S 3981048763:3981048763(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 3: 11:47:49.907683 192.168.0.100.3171 > 10.10.1.100.80: S 1089825363:1089825363(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 4: 11:47:50.162757 192.168.0.100.3172 > 10.10.1.100.80: S 3981048763:3981048763(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 5: 11:47:55.914640 192.168.0.100.3171 > 10.10.1.100.80: S 1089825363:1089825363(0) win 8192 <mss 1460,nop,nop,sackOK> 6: 11:47:56.164710 192.168.0.100.3172 > 10.10.1.100.80: S 3981048763:3981048763(0) win 8192 <mss 1460,nop,nop,sackOK>
firepower# show capture CAPO 0 packet captured 0 packet shown
Esta es la imagen de la captura CAPI en Wireshark:
Puntos clave:
Sobre la base de las 2 capturas, se puede concluir que:
Las acciones enumeradas en esta sección tienen como objetivo reducir aún más el problema.
Acción 1. Verifique el Seguimiento de un Paquete Emulado.
Utilice la herramienta packet-tracer para ver cómo se supone que el firewall maneja un paquete. En caso de que la política de acceso del firewall descarte el paquete, el seguimiento del paquete emulado es similar a este resultado:
firepower# packet-tracer input INSIDE tcp 192.168.0.100 11111 10.10.1.100 80 Phase: 1 Type: CAPTURE Subtype: Result: ALLOW Config: Additional Information: MAC Access list Phase: 2 Type: ACCESS-LIST Subtype: Result: ALLOW Config: Implicit Rule Additional Information: MAC Access list Phase: 3 Type: ROUTE-LOOKUP Subtype: Resolve Egress Interface Result: ALLOW Config: Additional Information: found next-hop 192.168.2.72 using egress ifc OUTSIDE Phase: 4 Type: ACCESS-LIST Subtype: log Result: DROP Config: access-group CSM_FW_ACL_ global access-list CSM_FW_ACL_ advanced deny ip any any rule-id 268439946 event-log flow-start access-list CSM_FW_ACL_ remark rule-id 268439946: ACCESS POLICY: FTD_Policy - Default access-list CSM_FW_ACL_ remark rule-id 268439946: L4 RULE: DEFAULT ACTION RULE Additional Information: Result: input-interface: INSIDE input-status: up input-line-status: up output-interface: OUTSIDE output-status: up output-line-status: up Action: drop Drop-reason: (acl-drop) Flow is denied by configured rule, Drop-location: frame 0x00005647a4f4b120 flow (NA)/NA
Acción 2. Verifique los seguimientos de los paquetes activos.
Habilite el seguimiento de paquetes para verificar cómo el firewall maneja los paquetes SYN TCP reales. De forma predeterminada, sólo se rastrea los primeros 50 paquetes de ingreso:
firepower# capture CAPI trace
Borre el búfer de captura:
firepower# clear capture /all
En caso de que la política de acceso del firewall descarte el paquete, el seguimiento se asemeja a este resultado:
firepower# show capture CAPI packet-number 1 trace 6 packets captured 1: 12:45:36.279740 192.168.0.100.3630 > 10.10.1.100.80: S 2322685377:2322685377(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> Phase: 1 Type: CAPTURE Subtype: Result: ALLOW Config: Additional Information: MAC Access list Phase: 2 Type: ACCESS-LIST Subtype: Result: ALLOW Config: Implicit Rule Additional Information: MAC Access list Phase: 3 Type: ROUTE-LOOKUP Subtype: Resolve Egress Interface Result: ALLOW Config: Additional Information: found next-hop 192.168.2.72 using egress ifc OUTSIDE Phase: 4 Type: ACCESS-LIST Subtype: log Result: DROP Config: access-group CSM_FW_ACL_ global access-list CSM_FW_ACL_ advanced deny ip any any rule-id 268439946 event-log flow-start access-list CSM_FW_ACL_ remark rule-id 268439946: ACCESS POLICY: FTD_Policy - Default access-list CSM_FW_ACL_ remark rule-id 268439946: L4 RULE: DEFAULT ACTION RULE Additional Information: Result: input-interface: INSIDE input-status: up input-line-status: up output-interface: OUTSIDE output-status: up output-line-status: up Action: drop Drop-reason: (acl-drop) Flow is denied by configured rule, Drop-location: frame 0x00005647a4f4b120 flow (NA)/NA 1 packet shown
Acción 3. Verifique los registros de Lina de FTD.
Para configurar Syslog en FTD a través de FMC, verifique este documento:
Se recomienda encarecidamente tener un servidor Syslog externo configurado para los registros de Lina FTD. Si no hay ningún servidor Syslog remoto configurado, habilite los registros del búfer local en el firewall mientras soluciona los problemas. La configuración de registro que se muestra en este ejemplo es un buen punto de inicio:
firepower# show run logging … logging enable logging timestamp logging buffer-size 1000000 logging buffered informational
Establezca el terminal pager en 24 líneas para controlar el terminal pager:
firepower# terminal pager 24
Borre el búfer de captura:
firepower# clear logging buffer
Pruebe la conexión y verifique los registros con un filtro de analizador. En este ejemplo, la política de acceso del firewall descarta los paquetes:
firepower# show logging | include 10.10.1.100 Oct 09 2019 12:55:51: %FTD-4-106023: Deny tcp src INSIDE:192.168.0.100/3696 dst OUTSIDE:10.10.1.100/80 by access-group "CSM_FW_ACL_" [0x97aa021a, 0x0] Oct 09 2019 12:55:51: %FTD-4-106023: Deny tcp src INSIDE:192.168.0.100/3697 dst OUTSIDE:10.10.1.100/80 by access-group "CSM_FW_ACL_" [0x97aa021a, 0x0] Oct 09 2019 12:55:54: %FTD-4-106023: Deny tcp src INSIDE:192.168.0.100/3696 dst OUTSIDE:10.10.1.100/80 by access-group "CSM_FW_ACL_" [0x97aa021a, 0x0] Oct 09 2019 12:55:54: %FTD-4-106023: Deny tcp src INSIDE:192.168.0.100/3697 dst OUTSIDE:10.10.1.100/80 by access-group "CSM_FW_ACL_" [0x97aa021a, 0x0]
Acción 4. Verifique las caídas ASP del firewall.
Si sospecha que el firewall descarta el paquete, puede ver los contadores de todos los paquetes descartados por el firewall en el nivel de software:
firepower# show asp drop Frame drop: No route to host (no-route) 234 Flow is denied by configured rule (acl-drop) 71 Last clearing: 07:51:52 UTC Oct 10 2019 by enable_15 Flow drop: Last clearing: 07:51:52 UTC Oct 10 2019 by enable_15
Puede habilitar capturas para ver todas las caídas de nivel de software ASP:
firepower# capture ASP type asp-drop all buffer 33554432 headers-only
Consejo: Si no está interesado en el contenido del paquete, puede capturar solamente los encabezados del paquete (opción sólo encabezados). Esto le permite capturar muchos más paquetes en el búfer de captura. Además, puede aumentar el tamaño del búfer de captura (de forma predeterminada es de 500 Kbytes) a un valor de hasta 32 Mbytes (opción de búfer). Por último, a partir de la versión 6.3 de FTD, la opción file-size permite configurar un archivo de captura de hasta 10 GBytes. En ese caso, sólo puede ver el contenido de la captura en un formato pcap.
Para comprobar el contenido de la captura, puede utilizar un filtro para restringir la búsqueda:
firepower# show capture ASP | include 10.10.1.100 18: 07:51:57.823672 192.168.0.100.12410 > 10.10.1.100.80: S 1870382552:1870382552(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 19: 07:51:58.074291 192.168.0.100.12411 > 10.10.1.100.80: S 2006489005:2006489005(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 26: 07:52:00.830370 192.168.0.100.12410 > 10.10.1.100.80: S 1870382552:1870382552(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 29: 07:52:01.080394 192.168.0.100.12411 > 10.10.1.100.80: S 2006489005:2006489005(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 45: 07:52:06.824282 192.168.0.100.12410 > 10.10.1.100.80: S 1870382552:1870382552(0) win 8192 <mss 1460,nop,nop,sackOK> 46: 07:52:07.074230 192.168.0.100.12411 > 10.10.1.100.80: S 2006489005:2006489005(0) win 8192 <mss 1460,nop,nop,sackOK>
En este caso, dado que los paquetes ya se encuentran rastreados en el nivel de interfaz, el motivo de la caída no se menciona en la captura ASP. Recuerde que un paquete sólo se puede rastrear en un lugar (interfaz de ingreso o caída ASP). En ese caso, se recomienda tomar varias caídas ASP y establecer un motivo de caída ASP específico. A continuación se muestra un enfoque recomendado:
1. Limpiar los contadores de caídas de ASP actuales:
firepower# clear asp drop
2. Envíe el flujo que soluciona problemas a través del firewall (ejecute una prueba).
3. Vuelva a comprobar los contadores de caídas de ASP y observe que los contadores han aumentado, p. ej.
firepower# show asp drop Frame drop: No route to host (no-route) 234 Flow is denied by configured rule (acl-drop) 71
4. Habilitar capturas ASP para las caídas específicas que se ven:
firepower# capture ASP_NO_ROUTE type asp-drop no-route firepower# capture ASP_ACL_DROP type asp-drop acl-drop
5. Envíe el flujo que soluciona problemas a través del firewall (ejecute una prueba).
6. Compruebe las capturas de ASP. En este caso, los paquetes se descartaron debido a una ruta ausente:
firepower# show capture ASP_NO_ROUTE | include 192.168.0.100.*10.10.1.100 93: 07:53:52.381663 192.168.0.100.12417 > 10.10.1.100.80: S 3451917925:3451917925(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 95: 07:53:52.632337 192.168.0.100.12418 > 10.10.1.100.80: S 1691844448:1691844448(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 101: 07:53:55.375392 192.168.0.100.12417 > 10.10.1.100.80: S 3451917925:3451917925(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 102: 07:53:55.626386 192.168.0.100.12418 > 10.10.1.100.80: S 1691844448:1691844448(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 116: 07:54:01.376231 192.168.0.100.12417 > 10.10.1.100.80: S 3451917925:3451917925(0) win 8192 <mss 1460,nop,nop,sackOK> 117: 07:54:01.626310 192.168.0.100.12418 > 10.10.1.100.80: S 1691844448:1691844448(0) win 8192 <mss 1460,nop,nop,sackOK>
Acción 5. Verifique la tabla de conexión Lina de FTD.
Puede haber casos en los que espere que el paquete ingrese a la interfaz 'X', pero por las razones que sean, se dirige a la interfaz 'Y'. La determinación de la interfaz de salida del firewall se basa en este orden de operación:
Para verificar la tabla de conexión FTD:
firepower# show conn 2 in use, 4 most used Inspect Snort: preserve-connection: 2 enabled, 0 in effect, 4 most enabled, 0 most in effect TCP DMZ 10.10.1.100:80 INSIDE 192.168.0.100:11694, idle 0:00:01, bytes 0, flags aA N1 TCP DMZ 10.10.1.100:80 INSIDE 192.168.0.100:11693, idle 0:00:01, bytes 0, flags aA N1
Puntos clave:
Esto se puede visualizar en la imagen aquí:
Nota: Dado que todas las interfaces FTD tienen un Nivel de Seguridad de 0, el orden de la interfaz en el resultado show conn se basa en el número de interfaz. Específicamente, la interfaz con vpif-num superior (número de interfaz de plataforma virtual) se selecciona como interna mientras que la interfaz con vpif-num inferior se selecciona como externa. Puede ver el valor vpif de la interfaz usando el comando show interface detail. Mejoras relacionadas, CSCvi15290 ENH: FTD debe mostrar la direccionalidad de conexión en la salida "show conn" de FTD
firepower# show interface detail | i Interface number is|Interface [P|E].*is up ... Interface Ethernet1/2 "INSIDE", is up, line protocol is up Interface number is 19 Interface Ethernet1/3.202 "OUTSIDE", is up, line protocol is up Interface number is 20 Interface Ethernet1/3.203 "DMZ", is up, line protocol is up Interface number is 22
Nota: A partir de la versión 6.5 del software Firepower, ASA versión 9.13.x los resultados del comando show conn long y show conn detail proporcionan información sobre el iniciador de la conexión y el respondedor
Salida 1:
firepower# show conn long ... TCP OUTSIDE: 192.168.2.200/80 (192.168.2.200/80) INSIDE: 192.168.1.100/46050 (192.168.1.100/46050), flags aA N1, idle 3s, uptime 6s, timeout 30s, bytes 0 Initiator: 192.168.1.100, Responder: 192.168.2.200 Connection lookup keyid: 228982375
Salida 2:
firepower# show conn detail ... TCP OUTSIDE: 192.168.2.200/80 INSIDE: 192.168.1.100/46050, flags aA N1, idle 4s, uptime 11s, timeout 30s, bytes 0 Initiator: 192.168.1.100, Responder: 192.168.2.200 Connection lookup keyid: 228982375
Además, el comando show conn long muestra las IPs NATed dentro de un paréntesis en caso de una Traducción de Dirección de Red:
firepower# show conn long ... TCP OUTSIDE: 192.168.2.222/80 (192.168.2.222/80) INSIDE: 192.168.1.100/34792 (192.168.2.150/34792), flags aA N1, idle 0s, uptime 0s, timeout 30s, bytes 0, xlate id 0x2b5a8a4314c0 Initiator: 192.168.1.100, Responder: 192.168.2.222 Connection lookup keyid: 262895
Acción 6. Verifique la memoria caché del protocolo de resolución de direcciones (ARP) del firewall.
Si el firewall no puede resolver el salto siguiente, el firewall descarta silenciosamente el paquete original (TCP SYN en este caso) y envía continuamente solicitudes ARP hasta que resuelva el salto siguiente.
Para ver la memoria caché ARP del firewall, utilice el comando:
firepower# show arp
Además, para verificar si hay hosts no resueltos puede utilizar el comando:
firepower# show arp statistics Number of ARP entries in ASA: 0 Dropped blocks in ARP: 84 Maximum Queued blocks: 3 Queued blocks: 0 Interface collision ARPs Received: 0 ARP-defense Gratuitous ARPS sent: 0 Total ARP retries: 182 < indicates a possible issue for some hosts Unresolved hosts: 1 < this is the current status Maximum Unresolved hosts: 2
Si desea verificar más a fondo la operación ARP, puede habilitar una captura específica de ARP:
firepower# capture ARP ethernet-type arp interface OUTSIDE firepower# show capture ARP ... 4: 07:15:16.877914 802.1Q vlan#202 P0 arp who-has 192.168.2.72 tell 192.168.2.50 5: 07:15:18.020033 802.1Q vlan#202 P0 arp who-has 192.168.2.72 tell 192.168.2.50
En este resultado, el firewall (192.168.2.50) intenta resolver el salto siguiente (192.168.2.72), pero no hay respuesta ARP
El resultado aquí muestra un escenario funcional con una resolución ARP adecuada:
firepower# show capture ARP 2 packets captured 1: 07:17:19.495595 802.1Q vlan#202 P0 arp who-has 192.168.2.72 tell 192.168.2.50 2: 07:17:19.495946 802.1Q vlan#202 P0 arp reply 192.168.2.72 is-at 4c:4e:35:fc:fc:d8 2 packets shown
firepower# show arp INSIDE 192.168.1.71 4c4e.35fc.fcd8 9 OUTSIDE 192.168.2.72 4c4e.35fc.fcd8 9
En caso de que no haya entrada ARP en el lugar, se muestra un seguimiento de un paquete SYN TCP activo:
firepower# show capture CAPI packet-number 1 trace 6 packets captured 1: 07:03:43.270585 192.168.0.100.11997 > 10.10.1.100.80: S 4023707145:4023707145(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> Phase: 1 Type: CAPTURE Subtype: Result: ALLOW Config: Additional Information: MAC Access list Phase: 2 Type: ACCESS-LIST Subtype: Result: ALLOW Config: Implicit Rule Additional Information: MAC Access list Phase: 3 Type: ROUTE-LOOKUP Subtype: Resolve Egress Interface Result: ALLOW Config: Additional Information: found next-hop 192.168.2.72 using egress ifc OUTSIDE … Phase: 14 Type: FLOW-CREATION Subtype: Result: ALLOW Config: Additional Information: New flow created with id 4814, packet dispatched to next module … Phase: 17 Type: ROUTE-LOOKUP Subtype: Resolve Egress Interface Result: ALLOW Config: Additional Information: found next-hop 192.168.2.72 using egress ifc OUTSIDE Result: input-interface: INSIDE input-status: up input-line-status: up output-interface: OUTSIDE output-status: up output-line-status: up Action: allow
Como se puede ver en el resultado, el seguimiento muestra Acción: ¡permita incluso cuando el salto siguiente no sea alcanzable y el paquete sea descartado silenciosamente por el firewall! En este caso, la herramienta packet-tracer también debe verificarse, ya que proporciona una salida más precisa:
firepower# packet-tracer input INSIDE tcp 192.168.0.100 1111 10.10.1.100 80 Phase: 1 Type: CAPTURE Subtype: Result: ALLOW Config: Additional Information: MAC Access list Phase: 2 Type: ACCESS-LIST Subtype: Result: ALLOW Config: Implicit Rule Additional Information: MAC Access list Phase: 3 Type: ROUTE-LOOKUP Subtype: Resolve Egress Interface Result: ALLOW Config: Additional Information: found next-hop 192.168.2.72 using egress ifc OUTSIDE … Phase: 14 Type: FLOW-CREATION Subtype: Result: ALLOW Config: Additional Information: New flow created with id 4816, packet dispatched to next module … Phase: 17 Type: ROUTE-LOOKUP Subtype: Resolve Egress Interface Result: ALLOW Config: Additional Information: found next-hop 192.168.2.72 using egress ifc OUTSIDE Result: input-interface: INSIDE input-status: up input-line-status: up output-interface: OUTSIDE output-status: up output-line-status: up Action: drop Drop-reason: (no-v4-adjacency) No valid V4 adjacency, Drop-location: frame 0x00005647a4e86109 flow (NA)/NA
En las versiones recientes de ASA/Firepower, el mensaje anterior se ha optimizado para:
Drop-reason: (no-v4-adjacency) No valid V4 adjacency. Check ARP table (show arp) has entry for nexthop., Drop-location: f
Si sólo ve un paquete TCP SYN en las interfaces de ingreso, pero ningún paquete TCP SYN enviado desde la interfaz de salida esperada, algunas causas posibles son:
Posible Causa |
Acciones recomendadas |
El paquete es descartado por la política de acceso del firewall. |
|
El filtro de captura es incorrecto. |
|
El paquete se envía a una interfaz de salida diferente. |
Si el paquete se envía a una interfaz incorrecta porque coincide con una conexión existente, utilice el comando clear conn address y especifique el 5-tuple de la conexión que desea borrar. |
No hay ruta hacia el destino. |
|
No hay entrada ARP en la interfaz de egreso. |
|
La interfaz de salida está inactiva. |
Verifique el resultado del comando show interface ip brief en el firewall y verifique el estado de la interfaz. |
Esta imagen muestra la topología:
Descripción de problemas: HTTP no funciona
Flujo afectado:
IP de servidor: 192.168.0.100
Dst IP: 10.10.1.100
Protocolo: TCP 80
Habilite las capturas en el motor FTD LINA.
firepower# capture CAPI int INSIDE match ip host 192.168.0.100 host 10.10.1.100 firepower# capture CAPO int OUTSIDE match ip host 192.168.0.100 host 10.10.1.100
Capturas: escenario no funcional:
Desde la CLI del dispositivo, las capturas son las siguientes:
firepower# show capture capture CAPI type raw-data trace interface INSIDE [Capturing - 834 bytes] match ip host 192.168.0.100 host 10.10.1.100 capture CAPO type raw-data interface OUTSIDE [Capturing - 878 bytes] match ip host 192.168.0.100 host 10.10.1.100
Contenido de CAPI:
firepower# show capture CAPI 1: 05:20:36.654217 192.168.0.100.22195 > 10.10.1.100.80: S 1397289928:1397289928(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 2: 05:20:36.904311 192.168.0.100.22196 > 10.10.1.100.80: S 2171673258:2171673258(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 3: 05:20:36.905043 10.10.1.100.80 > 192.168.0.100.22196: R 1850052503:1850052503(0) ack 2171673259 win 0 4: 05:20:37.414132 192.168.0.100.22196 > 10.10.1.100.80: S 2171673258:2171673258(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 5: 05:20:37.414803 10.10.1.100.80 > 192.168.0.100.22196: R 31997177:31997177(0) ack 2171673259 win 0 6: 05:20:37.914183 192.168.0.100.22196 > 10.10.1.100.80: S 2171673258:2171673258(0) win 8192 <mss 1460,nop,nop,sackOK> ...
Contenido de la CAPO:
firepower# show capture CAPO 1: 05:20:36.654507 802.1Q vlan#202 P0 192.168.0.100.22195 > 10.10.1.100.80: S 2866789268:2866789268(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK> 2: 05:20:36.904478 802.1Q vlan#202 P0 192.168.0.100.22196 > 10.10.1.100.80: S 4785344:4785344(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK> 3: 05:20:36.904997 802.1Q vlan#202 P0 10.10.1.100.80 > 192.168.0.100.22196: R 0:0(0) ack 4785345 win 0 4: 05:20:37.414269 802.1Q vlan#202 P0 192.168.0.100.22196 > 10.10.1.100.80: S 4235354730:4235354730(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK> 5: 05:20:37.414758 802.1Q vlan#202 P0 10.10.1.100.80 > 192.168.0.100.22196: R 0:0(0) ack 4235354731 win 0 6: 05:20:37.914305 802.1Q vlan#202 P0 192.168.0.100.22196 > 10.10.1.100.80: S 4118617832:4118617832(0) win 8192 <mss 1380,nop,nop,sackOK>
Esta imagen muestra la captura de CAPI en Wireshark.
Puntos clave:
Esta imagen muestra la captura de CAPO en Wireshark:
Puntos clave:
Sobre la base de las 2 capturas, se puede concluir que:
Las acciones enumeradas en esta sección tienen como objetivo reducir aún más el problema.
Acción 1. Verifique la dirección MAC de origen que envía el RST TCP.
Verifique que el MAC de destino visto en el paquete TCP SYN sea el mismo que el MAC de origen visto en el paquete TCP RST.
Esta comprobación tiene como objetivo confirmar dos cosas:
Acción 2. Compare los paquetes de ingreso y de salida.
Comparar visualmente los 2 paquetes en Wireshark para verificar que el firewall no modifica/corrompe los paquetes. Se destacan algunas diferencias esperadas.
Puntos clave:
Acción 3. Realice una captura en el destino.
Si es posible, tome una captura en el destino mismo. Si esto no es posible, tome una captura lo más cerca posible del destino. El objetivo aquí es verificar quién envía el RST TCP (¿es el servidor de destino o hay algún otro dispositivo en la trayectoria?).
Esta imagen muestra la topología:
Descripción de problemas: HTTP no funciona
Flujo afectado:
IP de servidor: 192.168.0.100
Dst IP: 10.10.1.100
Protocolo: TCP 80
Habilite las capturas en el motor FTD LINA.
firepower# capture CAPI int INSIDE match ip host 192.168.0.100 host 10.10.1.100 firepower# capture CAPO int OUTSIDE match ip host 192.168.0.100 host 10.10.1.100
Capturas: escenario no funcional:
Hay un par de maneras diferentes en las que este problema puede manifestarse en las capturas.
Tanto el firewall captura CAPI como el CAPO contienen los mismos paquetes, como se muestra en la imagen.
Puntos clave:
Las acciones enumeradas en esta sección tienen como objetivo reducir aún más el problema.
Acción 1. Realice las capturas lo más cerca posible de los dos terminales.
Las capturas del firewall indican que el cliente ACK no fue procesado por el servidor. Esto se basa en estos hechos:
La captura en el servidor muestra el problema. El cliente ACK del intercambio de señales TCP de 3 vías nunca llegó:
Tanto el firewall captura CAPI como el CAPO contienen los mismos paquetes, como se muestra en la imagen.
Puntos clave:
A partir de esta captura se puede concluir que aunque hay un intercambio de señales TCP de 3 vías a través del firewall, parece que nunca se completa en un punto final (las retransmisiones lo indican).
Igual que en el caso 3.1
Tanto el firewall captura CAPI como el CAPO contienen los mismos paquetes, como se muestra en la imagen.
Puntos clave:
Sobre la base de estas capturas se puede concluir que:
Igual que en el caso 3.1
Ambos firewalls captura CAPI y CAPO contienen estos paquetes, como se muestra en la imagen.
Puntos clave:
Acción: Realice las capturas lo más cerca posible del servidor.
Un RST TCP inmediato del servidor podría indicar un servidor que funciona mal o un dispositivo en la trayectoria que envía el RST TCP. Tome una captura en el propio servidor y determine el origen del RST TCP.
Esta imagen muestra la topología:
Descripción del problema: HTTP no funciona.
Flujo afectado:
IP de servidor: 192.168.0.100
Dst IP: 10.10.1.100
Protocolo: TCP 80
Habilite las capturas en el motor FTD LINA.
firepower# capture CAPI int INSIDE match ip host 192.168.0.100 host 10.10.1.100 firepower# capture CAPO int OUTSIDE match ip host 192.168.0.100 host 10.10.1.100
Capturas: escenario no funcional:
Éstos son los contenidos CAPI.
firepower# show capture CAPI 14 packets captured 1: 12:32:22.860627 192.168.0.100.47078 > 10.10.1.100.80: S 4098574664:4098574664(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 2: 12:32:23.111307 192.168.0.100.47079 > 10.10.1.100.80: S 2486945841:2486945841(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 3: 12:32:23.112390 192.168.0.100.47079 > 10.10.1.100.80: R 3000518858:3000518858(0) win 0 4: 12:32:25.858109 192.168.0.100.47078 > 10.10.1.100.80: S 4098574664:4098574664(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 5: 12:32:25.868698 192.168.0.100.47078 > 10.10.1.100.80: R 1386249853:1386249853(0) win 0 6: 12:32:26.108118 192.168.0.100.47079 > 10.10.1.100.80: S 2486945841:2486945841(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 7: 12:32:26.109079 192.168.0.100.47079 > 10.10.1.100.80: R 3000518858:3000518858(0) win 0 8: 12:32:26.118295 192.168.0.100.47079 > 10.10.1.100.80: R 3000518858:3000518858(0) win 0 9: 12:32:31.859925 192.168.0.100.47078 > 10.10.1.100.80: S 4098574664:4098574664(0) win 8192 <mss 1460,nop,nop,sackOK> 10: 12:32:31.860902 192.168.0.100.47078 > 10.10.1.100.80: R 1386249853:1386249853(0) win 0 11: 12:32:31.875229 192.168.0.100.47078 > 10.10.1.100.80: R 1386249853:1386249853(0) win 0 12: 12:32:32.140632 192.168.0.100.47079 > 10.10.1.100.80: R 3000518858:3000518858(0) win 0 13: 12:32:32.159995 192.168.0.100.47079 > 10.10.1.100.80: S 2486945841:2486945841(0) win 8192 <mss 1460,nop,nop,sackOK> 14: 12:32:32.160956 192.168.0.100.47079 > 10.10.1.100.80: R 3000518858:3000518858(0) win 0 14 packets shown
Estos son los contenidos de la CAPO:
firepower# show capture CAPO 11 packets captured 1: 12:32:22.860780 802.1Q vlan#202 P0 192.168.0.100.47078 > 10.10.1.100.80: S 1386249852:1386249852(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK> 2: 12:32:23.111429 802.1Q vlan#202 P0 192.168.0.100.47079 > 10.10.1.100.80: S 3000518857:3000518857(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK> 3: 12:32:23.112405 802.1Q vlan#202 P0 192.168.0.100.47079 > 10.10.1.100.80: R 3514091874:3514091874(0) win 0 4: 12:32:25.858125 802.1Q vlan#202 P0 192.168.0.100.47078 > 10.10.1.100.80: S 1386249852:1386249852(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK> 5: 12:32:25.868729 802.1Q vlan#202 P0 192.168.0.100.47078 > 10.10.1.100.80: R 2968892337:2968892337(0) win 0 6: 12:32:26.108240 802.1Q vlan#202 P0 192.168.0.100.47079 > 10.10.1.100.80: S 3822259745:3822259745(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK> 7: 12:32:26.109094 802.1Q vlan#202 P0 192.168.0.100.47079 > 10.10.1.100.80: R 40865466:40865466(0) win 0 8: 12:32:31.860062 802.1Q vlan#202 P0 192.168.0.100.47078 > 10.10.1.100.80: S 4294058752:4294058752(0) win 8192 <mss 1380,nop,nop,sackOK> 9: 12:32:31.860917 802.1Q vlan#202 P0 192.168.0.100.47078 > 10.10.1.100.80: R 1581733941:1581733941(0) win 0 10: 12:32:32.160102 802.1Q vlan#202 P0 192.168.0.100.47079 > 10.10.1.100.80: S 4284301197:4284301197(0) win 8192 <mss 1380,nop,nop,sackOK> 11: 12:32:32.160971 802.1Q vlan#202 P0 192.168.0.100.47079 > 10.10.1.100.80: R 502906918:502906918(0) win 0 11 packets shown
Los registros del firewall muestran:
firepower# show log | i 47741 Oct 13 2019 13:57:36: %FTD-6-302013: Built inbound TCP connection 4869 for INSIDE:192.168.0.100/47741 (192.168.0.100/47741) to OUTSIDE:10.10.1.100/80 (10.10.1.100/80) Oct 13 2019 13:57:36: %FTD-6-302014: Teardown TCP connection 4869 for INSIDE:192.168.0.100/47741 to OUTSIDE:10.10.1.100/80 duration 0:00:00 bytes 0 TCP Reset-O from INSIDE Oct 13 2019 13:57:39: %FTD-6-302013: Built inbound TCP connection 4870 for INSIDE:192.168.0.100/47741 (192.168.0.100/47741) to OUTSIDE:10.10.1.100/80 (10.10.1.100/80) Oct 13 2019 13:57:39: %FTD-6-302014: Teardown TCP connection 4870 for INSIDE:192.168.0.100/47741 to OUTSIDE:10.10.1.100/80 duration 0:00:00 bytes 0 TCP Reset-O from INSIDE Oct 13 2019 13:57:45: %FTD-6-302013: Built inbound TCP connection 4871 for INSIDE:192.168.0.100/47741 (192.168.0.100/47741) to OUTSIDE:10.10.1.100/80 (10.10.1.100/80) Oct 13 2019 13:57:45: %FTD-6-302014: Teardown TCP connection 4871 for INSIDE:192.168.0.100/47741 to OUTSIDE:10.10.1.100/80 duration 0:00:00 bytes 0 TCP Reset-O from INSIDE
Estos registros indican que hay un TCP RST que llega en la interfaz INSIDE del firewall
Captura de CAPI en Wireshark:
Siga la primera secuencia TCP, como se muestra en la imagen.
En Wireshark, navegue hasta Edit > Preferences > Protocols > TCP y deseleccione la opción Relative sequence number como se muestra en la imagen.
Esta imagen muestra el contenido del primer flujo en la captura CAPI:
Puntos clave:
El mismo flujo en la captura de CAPO contiene:
Puntos clave:
Sobre la base de las dos capturas se puede concluir que:
Las acciones enumeradas en esta sección tienen como objetivo reducir aún más el problema.
Acción 1. Realice una captura en el cliente.
Según las capturas recopiladas en el firewall, existe una fuerte indicación de un flujo asimétrico. Esto se basa en el hecho de que el cliente envía un RST TCP con un valor de 1386249853 (el ISN aleatorizado):
Puntos clave:
Esto se puede visualizar como:
Acción 2. Verifique el ruteo entre el Cliente y el Firewall.
Confirme que:
Hay escenarios donde el RST proviene de un dispositivo que se encuentra entre el firewall y el cliente mientras hay un ruteo asimétrico en la red interna. En la imagen se muestra un caso típico:
En este caso, la captura tiene este contenido. Observe la diferencia entre la dirección MAC de origen del paquete TCP SYN frente a la dirección MAC de origen del RST TCP y la dirección MAC de destino del paquete TCP SYN/ACK:
firepower# show capture CAPI detail 1: 13:57:36.730217 4c4e.35fc.fcd8 00be.75f6.1dae 0x0800 Length: 66 192.168.0.100.47740 > 10.10.1.100.80: S [tcp sum ok] 3045001876:3045001876(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> (DF) (ttl 127, id 25661) 2: 13:57:36.981104 4c4e.35fc.fcd8 00be.75f6.1dae 0x0800 Length: 66 192.168.0.100.47741 > 10.10.1.100.80: S [tcp sum ok] 3809380540:3809380540(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> (DF) (ttl 127, id 25662) 3: 13:57:36.981776 00be.75f6.1dae a023.9f92.2a4d 0x0800 Length: 66 10.10.1.100.80 > 192.168.0.100.47741: S [tcp sum ok] 1304153587:1304153587(0) ack 3809380541 win 8192 <mss 1380,nop,wscale 8,nop,nop,sackOK> (DF) (ttl 127, id 23339) 4: 13:57:36.982126 a023.9f92.2a4d 00be.75f6.1dae 0x0800 Length: 54 192.168.0.100.47741 > 10.10.1.100.80: R [tcp sum ok] 3809380541:3809380541(0) ack 1304153588 win 8192 (ttl 255, id 48501) ...
Descripción de problemas:
La transferencia SFTP entre los hosts 10.11.4.171 y 10.77.19.11 es lenta. Aunque el ancho de banda mínimo (BW) entre los 2 hosts es de 100 Mbps, la velocidad de transferencia no supera los 5 Mbps.
Al mismo tiempo, la velocidad de transferencia entre los hosts 10.11.2.124 y 172.25.18.134 es bastante mayor.
Teoría Precedente:
La velocidad máxima de transferencia para un único flujo TCP viene determinada por el producto Bandwidth Delay Product (BDP). La fórmula utilizada se muestra en la imagen:
Para obtener más información sobre BDP, consulte los recursos aquí:
Esta imagen muestra la topología:
Flujo afectado:
IP de servidor: 10.11.4.171
Dst IP: 10.77.19.11
Protocolo: SFTP (FTP sobre SSH)
Habilitar capturas en el motor FTD LINA:
firepower# capture CAPI int INSIDE buffer 33554432 match ip host 10.11.4.171 host 10.77.19.11 firepower# capture CAPO int OUTSIDE buffer 33554432 match ip host 10.11.4.171 host 10.77.19.11
Advertencia: Las capturas de LINA en las capturas de FP1xxx y FP21xx afectan a la velocidad de transferencia del tráfico que pasa por el FTD. No habilite las capturas de LINA en las plataformas FP1xxx y FP21xxx cuando resuelva problemas de rendimiento (transferencia lenta a través del FTD). En su lugar, utilice SPAN o un dispositivo HW Tap además de las capturas en los hosts de origen y destino. El problema se documenta en CSCvo30697 .
firepower# capture CAPI type raw-data trace interface inside match icmp any any WARNING: Running packet capture can have an adverse impact on performance.
Las acciones enumeradas en esta sección tienen como objetivo reducir aún más el problema.
Cálculo del tiempo de viaje de ida y vuelta (RTT)
Primero, identifique el flujo de transferencia y sígalo:
Cambie la vista Wireshark para mostrar los segundos transcurridos desde el paquete anterior mostrado. Esto facilita el cálculo del RTT:
El RTT se puede calcular agregando los valores de tiempo entre 2 intercambios de paquetes (uno hacia el origen y otro hacia el destino). En este caso, el paquete #2 muestra el RTT entre el firewall y el dispositivo que envió el paquete SYN/ACK (servidor). El paquete n.º 3 muestra el RTT entre el firewall y el dispositivo que envió el paquete ACK (cliente). La adición de los 2 números proporciona una buena estimación sobre el RTT de extremo a extremo:
RTT aprox. 80 ms
Cálculo del Tamaño de la Ventana TCP
Expanda un paquete TCP, expanda el encabezado TCP, seleccione Tamaño de ventana calculado y seleccione Aplicar como columna:
Verifique la columna Valor de tamaño de ventana calculado para ver cuál era el valor máximo de tamaño de ventana durante la sesión TCP. También puede seleccionar el nombre de la columna y ordenar los valores.
Si prueba una descarga de archivos (servidor > cliente) debe comprobar los valores anunciados por el servidor. El valor de tamaño máximo de ventana anunciado por el servidor determina la velocidad máxima de transferencia alcanzada.
En este caso, el tamaño de la ventana TCP es de 50000 bytes aproximadamente
A partir de estos valores y con el uso de la fórmula de producto de retraso del ancho de banda, obtiene el ancho de banda teórico máximo que se puede lograr en estas condiciones: 50000*8/0.08 = ancho de banda teórico máximo de 5 Mbps.
Esto coincide con la experiencia del cliente en este caso.
Verifique atentamente el intercambio de señales TCP de 3 vías. Ambos lados, y lo que es más importante, el servidor, anuncian un valor de escala de ventana de 0, lo que significa 2^0 = 1 (sin escalado de Windows). Esto afecta negativamente a la velocidad de transferencia:
En este punto, es necesario tomar una captura en el servidor, confirmar que es el que anuncia la escala de ventana = 0 y reconfigurarla (puede que necesite verificar la documentación del servidor para hacer esto).
Ahora examinemos el escenario adecuado (transferencia rápida a través de la misma red):
Topología:
El flujo de interés:
IP de servidor: 10.11.2.124
Dst IP: 172.25.18.134
Protocolo: SFTP (FTP sobre SSH)
Habilitar capturas en motor FTD LINA
firepower# capture CAPI int INSIDE buffer 33554432 match ip host 10.11.2.124 host 172.25.18.134 firepower# capture CAPO int OUTSIDE buffer 33554432 match ip host 10.11.2.124 host 172.25.18.134
Cálculo del tiempo de viaje de ida y vuelta (RTT): En este caso, el RTT es aproximado a 300 mseg.
Cálculo del Tamaño de la Ventana TCP: El servidor anuncia un factor de escala de ventana TCP de 7.
El tamaño de la ventana TCP del servidor es aproximado a 160000 bytes:
Basándose en estos valores, la fórmula Producto de Retraso de Ancho de Banda proporciona:
160000*8/0,3 = velocidad máxima teórica de transferencia de 43 Mbps
Descripción de problemas: La transferencia de archivos FTP (descarga) a través del firewall es lenta.
Esta imagen muestra la topología:
Flujo afectado:
IP de servidor: 192.168.2.220
Dst IP: 192.168.1.220
Protocolo: FTP
Habilite las capturas en el motor FTD LINA.
firepower# capture CAPI type raw-data buffer 33554432 interface INSIDE match tcp host 192.168.2.220 host 192.168.1.220 firepower# cap CAPO type raw-data buffer 33554432 interface OUTSIDE match tcp host 192.168.2.220 host 192.168.1.220
Seleccione un paquete FTP-DATA y siga el canal de datos FTP en FTD INSIDE capture (CAPI):
El contenido de flujo FTP-DATA:
El contenido de la captura CAPO:
Puntos clave:
Consejo: Guarde las capturas mientras navega hasta Archivo > Exportar paquetes especificados. A continuación, guarde sólo el rango de paquetes Mostrados
Las acciones enumeradas en esta sección tienen como objetivo reducir aún más el problema.
Acción 1. Identifique la ubicación de pérdida de paquetes.
En casos como este, debe tomar capturas simultáneas y utilizar la metodología de división y conquista para identificar los segmentos de red que causan la pérdida de paquetes. Desde el punto de vista del firewall, existen tres escenarios principales:
Pérdida de paquetes causada por el firewall: Para identificar si la pérdida de paquetes es causada por el firewall, es necesario comparar la captura de ingreso con la captura de egreso. Hay muchas maneras de comparar dos capturas diferentes. En esta sección se muestra una forma de realizar esta tarea.
Procedimiento para Comparar 2 Capturas para Identificar la Pérdida de Paquetes
Paso 1. Asegúrese de que las 2 capturas contengan paquetes de la misma ventana de tiempo. Esto significa que no debe haber paquetes en una captura que hayan sido capturados antes o después de la otra captura. Hay algunas maneras de hacerlo:
En este ejemplo puede ver que los primeros paquetes de cada captura tienen los mismos valores de ID de IP:
En caso de que no sean iguales:
(frame.time >= "16 de octubre de 2019 16:13:43.244692000") y&(frame.time <= "16 de octubre de 2019 16:20:21.78513000 0")
3. Exporte los paquetes especificados a una nueva captura, seleccione Archivo > Exportar paquetes especificados y luego guarde los paquetes mostrados. En este punto, ambas capturas deben contener paquetes que cubran la misma ventana de tiempo. Ahora puede iniciar la comparación de las 2 capturas.
Paso 2. Especifique qué campo de paquete se utiliza para la comparación entre las dos capturas. Ejemplo de campos que se pueden utilizar:
Cree una versión de texto de cada captura que contenga el campo para cada paquete especificado en el paso 1. Para ello, deje sólo la columna de interés, por ejemplo, si desea comparar paquetes según la identificación IP, modifique la captura como se muestra en la imagen.
El resultado:
Paso 3. Cree una versión de texto de la captura (Archivo > Exportar disecciones de paquetes > Como texto sencillo...), como se muestra en la imagen:
Desactive las opciones Incluir encabezados de columna y Detalles del paquete para exportar sólo los valores del campo mostrado, como se muestra en la imagen:
Paso 4. Ordene los paquetes en los archivos. Puede utilizar el comando Linux sort para hacer esto:
# sort CAPI_IDs > file1.sorted # sort CAPO_IDs > file2.sorted
Paso 5. Utilice una herramienta de comparación de texto (por ejemplo, WinMerge) o el comando Linux diff para encontrar las diferencias entre las dos capturas.
En este caso, la captura CAPI y CAPO para el tráfico de datos FTP son idénticas. Esto prueba que la pérdida de paquetes no fue causada por el firewall.
Identifique la pérdida de paquetes de flujo ascendente/descendente.
Puntos clave:
1. Este paquete es una retransmisión TCP. Específicamente, es un paquete TCP SYN enviado desde el cliente al servidor para datos FTP en modo pasivo. Dado que el cliente reenvía el paquete y puede ver el SYN inicial (paquete n.º 1), el paquete se perdió en sentido ascendente hacia el firewall.
En este caso, podría haber incluso la posibilidad de que el paquete SYN llegara al servidor, pero el paquete SYN/ACK se perdió en el camino de regreso:
2. Hay un paquete del servidor y Wireshark identificó que el segmento anterior no se vio/capturó. Dado que el paquete no capturado se envió desde el servidor al cliente y no se vio en la captura del firewall, esto significa que el paquete se perdió entre el servidor y el firewall.
Esto indica que hay pérdida de paquetes entre el servidor FTP y el firewall.
Acción 2. Tome capturas adicionales.
Realice capturas adicionales junto con capturas en los terminales. Intente aplicar el método de división y conquista para aislar aún más el segmento problemático que causa la pérdida de paquetes.
Puntos clave:
¿Qué significan los ACK duplicados?
Acción 3. Calcule el tiempo de procesamiento del firewall para los paquetes de tránsito.
Aplique la misma captura en 2 interfaces diferentes:
firepower# capture CAPI buffer 33554432 interface INSIDE match tcp host 192.168.2.220 host 192.168.1.220 firepower# capture CAPI interface OUTSIDE
Exportar la captura verifique la diferencia de tiempo entre los paquetes de ingreso y de egreso
Descripción de problemas:
El cliente inalámbrico (192.168.21.193) intenta conectarse a un servidor de destino (192.168.14.250 - HTTP) y hay dos escenarios diferentes:
Esta imagen muestra la topología:
Flujo afectado:
IP de servidor: 192.168.21.193
Dst IP: 192.168.14.250
Protocolo: TCP 80
Habilitar capturas en el motor FTD LINA:
firepower# capture CAPI int INSIDE match ip host 192.168.21.193 host 192.168.14.250 firepower# capture CAPO int OUTSIDE match ip host 192.168.21.193 host 192.168.14.250
Capturas - Escenario funcional:
Como punto de partida, siempre es muy útil tener capturas de un escenario en funcionamiento.
Esta imagen muestra la captura tomada en la interfaz INTERNA de NGFW
Esta imagen muestra la captura tomada en la interfaz NGFW OUTSIDE.
Puntos clave:
Capturas: escenario no operativo:
El contenido de captura de ingreso (CAPI).
Puntos clave:
Esta imagen muestra el contenido de la captura de salida (CAPO).
Puntos clave:
Las dos capturas son casi idénticas (consideremos la aleatorización de ISN):
Verifique el paquete malformado:
Puntos clave:
Las acciones enumeradas en esta sección tienen como objetivo reducir aún más el problema.
Acción 1. Tome capturas adicionales, incluidas las capturas en los terminales y, si es posible, intente aplicar el método de dividir y conquistar para aislar el origen de la corrupción de paquetes, por ejemplo,
En este caso, los 2 bytes adicionales fueron agregados por el controlador de interfaz "A" del switch y la solución era reemplazar el switch que causa la corrupción.
Descripción de problemas: Los mensajes de Syslog (UDP 514) no se ven en el servidor Syslog de destino.
Esta imagen muestra la topología:
Flujo afectado:
IP de servidor: 192.168.1.81
Dst IP: 10.10.1.73
Protocolo: UDP 514
Habilitar capturas en el motor FTD LINA:
firepower# capture CAPI int INSIDE trace match udp host 192.168.1.81 host 10.10.1.73 eq 514 firepower# capture CAPO int OUTSIDE match udp host 192.168.1.81 host 10.10.1.73 eq 514
Las capturas de FTD no muestran paquetes:
firepower# show capture capture CAPI type raw-data trace interface INSIDE [Capturing - 0 bytes] match udp host 192.168.1.81 host 10.10.1.73 eq syslog capture CAPO type raw-data interface OUTSIDE [Capturing - 0 bytes] match udp host 192.168.1.81 host 10.10.1.73 eq syslog
Las acciones enumeradas en esta sección tienen como objetivo reducir aún más el problema.
Acción 1. Verifique la tabla de conexión FTD.
Para comprobar una conexión específica, puede utilizar esta sintaxis:
firepower# show conn address 192.168.1.81 port 514 10 in use, 3627189 most used Inspect Snort: preserve-connection: 6 enabled, 0 in effect, 74 most enabled, 0 most in effect UDP INSIDE 10.10.1.73:514 INSIDE 192.168.1.81:514, idle 0:00:00, bytes 480379697, flags -oN1
Puntos clave:
Acción 2. Realice capturas a nivel del chasis.
Conéctese al administrador del chasis Firepower y habilite la captura en la interfaz de ingreso (E1/2 en este caso) y en las interfaces de backplane (E1/9 y E1/10), como se muestra en la imagen:
Después de unos segundos:
Consejo: En Wireshark, excluya los paquetes etiquetados con VN para eliminar la duplicación de paquetes en el nivel de interfaz física
Antes:
Después de:
Puntos clave:
Acción 3. Utilice packet-tracer.
Dado que los paquetes no atraviesan el motor LINA del firewall, no puede realizar un seguimiento en tiempo real (captura con seguimiento), pero puede rastrear un paquete emulado con packet-tracer:
firepower# packet-tracer input INSIDE udp 10.10.1.73 514 192.168.1.81 514 Phase: 1 Type: CAPTURE Subtype: Result: ALLOW Config: Additional Information: MAC Access list Phase: 2 Type: ACCESS-LIST Subtype: Result: ALLOW Config: Implicit Rule Additional Information: MAC Access list Phase: 3 Type: FLOW-LOOKUP Subtype: Result: ALLOW Config: Additional Information: Found flow with id 25350892, using existing flow Phase: 4 Type: SNORT Subtype: Result: ALLOW Config: Additional Information: Snort Verdict: (fast-forward) fast forward this flow Phase: 5 Type: ROUTE-LOOKUP Subtype: Resolve Egress Interface Result: ALLOW Config: Additional Information: found next-hop 192.168.1.81 using egress ifc INSIDE Phase: 6 Type: ADJACENCY-LOOKUP Subtype: next-hop and adjacency Result: ALLOW Config: Additional Information: adjacency Active next-hop mac address a023.9f92.2a4d hits 1 reference 1 Phase: 7 Type: CAPTURE Subtype: Result: ALLOW Config: Additional Information: MAC Access list Result: input-interface: INSIDE input-status: up input-line-status: up output-interface: INSIDE output-status: up output-line-status: up Action: allow
Acción 4. Confirme el ruteo FTD.
Verifique la tabla de ruteo del firewall para ver si hay algún problema de ruteo:
firepower# show route 10.10.1.73 Routing entry for 10.10.1.0 255.255.255.0 Known via "eigrp 1", distance 90, metric 3072, type internal Redistributing via eigrp 1 Last update from 192.168.2.72 on OUTSIDE, 0:03:37 ago Routing Descriptor Blocks: * 192.168.2.72, from 192.168.2.72, 0:02:37 ago, via OUTSIDE Route metric is 3072, traffic share count is 1 Total delay is 20 microseconds, minimum bandwidth is 1000000 Kbit Reliability 255/255, minimum MTU 1500 bytes Loading 29/255, Hops 1
Puntos clave:
Acción 5. Confirme el tiempo de actividad de la conexión.
Verifique el tiempo de actividad de la conexión para ver cuándo se estableció esta conexión:
firepower# show conn address 192.168.1.81 port 514 detail 21 in use, 3627189 most used Inspect Snort: preserve-connection: 19 enabled, 0 in effect, 74 most enabled, 0 most in effect Flags: A - awaiting responder ACK to SYN, a - awaiting initiator ACK to SYN, b - TCP state-bypass or nailed, C - CTIQBE media, c - cluster centralized, D - DNS, d - dump, E - outside back connection, e - semi-distributed, F - initiator FIN, f - responder FIN, G - group, g - MGCP, H - H.323, h - H.225.0, I - initiator data, i - incomplete, J - GTP, j - GTP data, K - GTP t3-response k - Skinny media, L - decap tunnel, M - SMTP data, m - SIP media N - inspected by Snort (1 - preserve-connection enabled, 2 - preserve-connection in effect) n - GUP, O - responder data, o - offloaded, P - inside back connection, p - passenger flow q - SQL*Net data, R - initiator acknowledged FIN, R - UDP SUNRPC, r - responder acknowledged FIN, T - SIP, t - SIP transient, U - up, V - VPN orphan, v - M3UA W - WAAS, w - secondary domain backup, X - inspected by service module, x - per session, Y - director stub flow, y - backup stub flow, Z - Scansafe redirection, z - forwarding stub flow UDP INSIDE: 10.10.1.73/514 INSIDE: 192.168.1.81/514, flags -oN1, idle 0s, uptime 3m49s, timeout 2m0s, bytes 4801148711
Punto clave:
Acción 6. Borre la conexión existente.
En este caso, los paquetes coinciden con una conexión establecida y se rutean a una interfaz de salida incorrecta que causa un loop. Esto se debe al orden de las operaciones del firewall:
Dado que la conexión nunca se agota (el cliente Syslog envía paquetes continuamente mientras que el tiempo de espera inactivo de la conexión UDP es de 2 minutos), es necesario borrar manualmente la conexión:
firepower# clear conn address 10.10.1.73 address 192.168.1.81 protocol udp port 514 1 connection(s) deleted.
Verifique que se establezca una nueva conexión:
firepower# show conn address 192.168.1.81 port 514 detail | b 10.10.1.73.*192.168.1.81 UDP OUTSIDE: 10.10.1.73/514 INSIDE: 192.168.1.81/514, flags -oN1, idle 1m15s, uptime 1m15s, timeout 2m0s, bytes 408
Acción 7. Configure el tiempo de espera de la conexión flotante.
Esta es la solución adecuada para abordar el problema y evitar el ruteo subóptimo, especialmente para los flujos UDP. Navegue hasta Dispositivos > Configuración de plataforma > Tiempos de espera y establezca el valor:
Puede encontrar más detalles sobre el tiempo de espera de conn flotante en la Referencia de Comandos:
Descripción de problemas: No se puede establecer la comunicación HTTPS entre el cliente 192.168.201.105 y el servidor 192.168.202.101
Esta imagen muestra la topología:
Flujo afectado:
IP de servidor: 192.168.201.111
Dst IP: 192.168.202.111
Protocolo: TCP 443 (HTTPS)
Habilitar capturas en el motor FTD LINA:
La IP utilizada en la captura OUTSIDE es diferente debido a la configuración de Traducción de Dirección de Puerto .
firepower# capture CAPI int INSIDE match ip host 192.168.201.111 host 192.168.202.111 firepower# capture CAPO int OUTSIDE match ip host 192.168.202.11 host 192.168.202.111
Esta imagen muestra la captura tomada en la interfaz INTERNA de NGFW:
Puntos clave:
Esta imagen muestra la captura tomada en la interfaz NGFW OUTSIDE.
Puntos clave:
Las acciones enumeradas en esta sección tienen como objetivo reducir aún más el problema.
Acción 1. Realice capturas adicionales.
Una captura tomada en el servidor revela que el servidor recibió los Hellos del Cliente TLS con suma de comprobación TCP dañada y los descarta silenciosamente (no hay RST TCP ni ningún otro paquete de respuesta hacia el cliente):
Cuando todo se junta:
En este caso, para entender lo que está sucediendo es necesario habilitar en Wireshark la opción Validar la suma de comprobación TCP si es posible. Vaya a Edit > Preferences > Protocols > TCP, como se muestra en la imagen.
En este caso, es útil poner las capturas una al lado de la otra para obtener el panorama completo:
Puntos clave:
Para referencia:
Procesamiento de intercambio de señales SSL/TLS de Firepower
Descripción del problema: falla el registro de FMC Smart License.
Esta imagen muestra la topología:
Flujo afectado:
IP de servidor: 192.168.0.100
Dst: tools.cisco.com
Protocolo: TCP 443 (HTTPS)
Habilite la captura en la interfaz de administración de FMC:
Intente registrarse de nuevo. Cuando aparezca el mensaje de error, presione CTRL-C para detener la captura:
root@firepower:/Volume/home/admin# tcpdump -i eth0 port 443 -s 0 -w CAP.pcap HS_PACKET_BUFFER_SIZE is set to 4. tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes ^C264 packets captured <- CTRL-C 264 packets received by filter 0 packets dropped by kernel root@firepower:/Volume/home/admin#
Recopile la captura del FMC (Sistema > Estado > Monitor, seleccione el dispositivo y seleccione Resolución de problemas avanzada), como se muestra en la imagen:
La imagen muestra la captura de FMC en Wireshark:
Consejo: Para verificar todas las sesiones TCP nuevas capturadas, utilice el filtro de visualización tcp.flag==0x2 en Wireshark. Esto filtra todos los paquetes TCP SYN capturados.
Consejo: Aplique como columna el campo Server Name desde SSL Client Hello.
Consejo: Aplique este filtro de visualización para ver solamente los mensajes de saludo del cliente ssl.handshake.type == 1
Nota: En el momento de escribir este artículo, el portal de licencias inteligentes (tools.cisco.com) utiliza estas IP: 72.163.4.38, 173.37.145.8
Siga uno de los flujos TCP (Seguir > Secuencia TCP), como se muestra en la imagen.
Puntos clave:
Seleccione el certificado de servidor y expanda el campo emisor para ver el nombre común. En este caso, Common Name muestra un dispositivo que ejecuta Man-in-the-middle (MITM).
Esto se muestra en esta imagen:
Las acciones enumeradas en esta sección tienen como objetivo reducir aún más el problema.
Acción 1. Realice capturas adicionales.
Realice capturas en el dispositivo de firewall de tránsito:
CAPI muestra:
CAPO muestra:
Estas capturas demuestran que el firewall de tránsito modifica el certificado del servidor (MITM)
Acción 2. Verifique los registros del dispositivo.
Puede recopilar el paquete TS de FMC como se describe en este documento:
En este caso, el archivo /dir-archives/var-log/process_stdout.log muestra mensajes como este:
SOUT: 10-23 05:45:14 2019-10-23 05:45:36 sla[10068]: *Wed .967 UTC: CH-LIB-ERROR: ch_pf_curl_send_msg[494],
failed to perform, err code 60, err string "SSL peer certificate or SSH remote key was not OK" ...
SOUT: 10-23 05:45:14 2019-10-23 05:45:36 sla[10068]: *Wed .967 UTC: CH-LIB-TRACE: ch_pf_curl_is_cert_issue[514],
cert issue checking, ret 60, url "https://tools.cisco.com/its/
Solución recomendada
Inhabilite el MITM para el flujo específico para que FMC pueda registrarse correctamente en la nube de Smart Licensing.
Descripción de problemas: Los hosts internos (situados detrás de la interfaz INSIDE del firewall) no pueden comunicarse con los hosts externos (los hosts ubicados detrás de la interfaz EXTERNA del firewall).
Esta imagen muestra la topología:
Flujo afectado:
IP de servidor: fc00:1:1:1::100
Dst IP: fc00:1:1:2::2
Protocolo: cualquiera
Habilite las capturas en el motor FTD LINA.
firepower# capture CAPI int INSIDE match ip any6 any6 firepower# capture CAPO int OUTSIDE match ip any6 any6
Capturas: situación no funcional
Estas capturas se realizaron en paralelo con una prueba de conectividad ICMP desde IP fc00:1:1:1::100 (router interno) a IP fc00:1:1:2::2 (router ascendente).
La captura en la interfaz INSIDE del firewall contiene:
Puntos clave:
La captura en la interfaz FUERA del firewall contiene:
Puntos clave:
El punto 4 es muy interesante. Normalmente, el router ascendente solicita la MAC de la interfaz FUERA del firewall (fc00:1:1:2::2), pero en su lugar, solicita la interfaz fc00:1:1:1::100. Esto indica un error de configuración.
Las acciones enumeradas en esta sección tienen como objetivo reducir aún más el problema.
Acción 1. Verifique la tabla de vecino IPv6.
La tabla de vecinos IPv6 del firewall se ha rellenado correctamente.
firepower# show ipv6 neighbor | i fc00 fc00:1:1:2::2 58 4c4e.35fc.fcd8 STALE OUTSIDE fc00:1:1:1::100 58 4c4e.35fc.fcd8 STALE INSIDE
Acción 2. Verifique la configuración de IPv6.
Esta es la configuración del firewall.
firewall# show run int e1/2 ! interface Ethernet1/2 nameif INSIDE cts manual propagate sgt preserve-untag policy static sgt disabled trusted security-level 0 ip address 192.168.0.1 255.255.255.0 ipv6 address fc00:1:1:1::1/64 ipv6 enable firewall# show run int e1/3.202 ! interface Ethernet1/3.202 vlan 202 nameif OUTSIDE cts manual propagate sgt preserve-untag policy static sgt disabled trusted security-level 0 ip address 192.168.103.96 255.255.255.0 ipv6 address fc00:1:1:2::1/64 ipv6 enable
La configuración del dispositivo ascendente revela la configuración errónea:
Router# show run interface g0/0.202 ! interface GigabitEthernet0/0.202 encapsulation dot1Q 202 vrf forwarding VRF202 ip address 192.168.2.72 255.255.255.0 ipv6 address FC00:1:1:2::2/48
Capturas: situación funcional
El cambio de máscara de subred (de /48 a /64) solucionó el problema. Esta es la captura CAPI en el escenario funcional.
Punto clave:
Contenido de la CAPO:
Puntos clave:
Descripción de problemas: Los hosts internos (192.168.0.x/24) tienen problemas de conectividad intermitentes con hosts en la misma subred
Esta imagen muestra la topología:
Flujo afectado:
IP de servidor: 192.168.0.x/24
Dst IP: 192.168.0.x/24
Protocolo: cualquiera
La memoria caché ARP de un host interno parece estar envenenada:
Habilitar una captura en el motor FTD LINA
Esta captura sólo captura paquetes ARP en la interfaz INSIDE:
firepower# capture CAPI_ARP interface INSIDE ethernet-type arp
Capturas: situación no funcional:
La captura en la interfaz INSIDE del firewall contiene.
Puntos clave:
Las acciones enumeradas en esta sección tienen como objetivo reducir aún más el problema.
Acción 1. Verifique la configuración de NAT.
Dependiendo de la configuración de NAT, hay casos en los que la palabra clave no-proxy-arp puede prevenir el comportamiento anterior:
firepower# show run nat nat (INSIDE,OUTSIDE) source static NET_1.1.1.0 NET_2.2.2.0 destination static NET_192.168.0.0 NET_4.4.4.0 no-proxy-arp
Acción 2. Inhabilite la funcionalidad proxy-arp en la interfaz de firewall.
Si la palabra clave "no-proxy-arp" no resuelve el problema, considere desactivar el ARP proxy en la propia interfaz. En el caso de FTD, en el momento de escribir este artículo, tendrá que utilizar FlexConfig e implementar el siguiente comando (especifique el nombre de la interfaz correspondiente).
sysopt noproxyarp INSIDE
Este caso demuestra cómo se identificaron ciertos OID de SNMP para el sondeo de memoria como la causa raíz de los errores de CPU (problema de rendimiento) basándose en el análisis de capturas de paquetes de la versión 3 de SNMP (SNMPv3).
Descripción de problemas: Los desbordamientos en las interfaces de datos aumentan continuamente. La resolución de problemas adicional reveló que también hay acaparamientos de la CPU (causados por el proceso SNMP) que son la causa raíz de los desbordamientos de la interfaz.
El siguiente paso en el proceso de solución de problemas fue identificar la causa raíz de los acaparamientos de la CPU causados por el proceso SNMP y, en particular, limitar el alcance del problema para identificar los identificadores de objetos SNMP (OID) que, cuando se sondearon, podrían potencialmente dar lugar a acaparamiento de la CPU.
Actualmente, el motor FTD LINA no proporciona un comando 'show' para OID SNMP que se consultan en tiempo real. La lista de OID SNMP para sondeo se puede recuperar de la herramienta de monitoreo SNMP, sin embargo, en este caso, hubo estos factores limitantes:
Dado que el administrador de FTD tenía las credenciales para la autenticación SNMP versión 3 y el cifrado de datos, se propuso este plan de acción:
Configure las capturas de paquetes SNMP en la interfaz que se utiliza en la configuración del host snmp-server:
firepower# show run snmp-server | include host snmp-server host management 192.168.10.10 version 3 netmonv3 firepower# show ip address management System IP Address: Interface Name IP address Subnet mask Method Management0/0 management 192.168.5.254 255.255.255.0 CONFIG Current IP Address: Interface Name IP address Subnet mask Method Management0/0 management 192.168.5.254 255.255.255.0 CONFIG firepower# capture capsnmp interface management buffer 10000000 match udp host 192.168.10.10 host 192.168.5.254 eq snmp firepower# show capture capsnmp capture capsnmp type raw-data buffer 10000000 interface outside [Capturing - 9512 bytes] match udp host 192.168.10.10 host 192.168.5.254 eq snmp
Puntos clave:
Las acciones enumeradas en esta sección tienen como objetivo reducir aún más el problema.
Acción 1. Descifrar las capturas SNMP.
Guarde las capturas y edite las preferencias del protocolo SNMP de Wireshark para especificar las credenciales SNMP versión 3 para descifrar los paquetes.
firepower# copy /pcap capture: tftp: Source capture name [capsnmp]? Address or name of remote host []? 192.168.10.253 Destination filename [capsnmp]? capsnmp.pcap !!!!!! 64 packets copied in 0.40 secs
Abra el archivo de captura en Wireshark, seleccione un paquete SNMP y navegue hasta Preferencias de protocolo > Tabla de usuarios, como se muestra en la imagen:
En la tabla Usuarios SNMP se especificaron el nombre de usuario, el modelo de autenticación, la contraseña de autenticación, el protocolo de privacidad y la contraseña de privacidad de SNMP versión 3 (las credenciales reales no se muestran a continuación):
Una vez que se aplicó la configuración de los usuarios SNMP, Wireshark mostró PDU SNMP descifradas:
Puntos clave:
Acción 2. Identifique los OID de SNMP.
SNMP Object Navigator mostró que OID 1.3.6.1.4.1.9.9.221.1 pertenece a la base de información de administración (MIB) denominada CISCO-ENHANCED-MEMPOOL-MIB, como se muestra en la imagen:
Para mostrar los OID en formato legible por el usuario en Wireshark, siga estos pasos:
2. En Wireshark en la ventana Edit > Preferences > Name ResolutionEnable OID Resolution está marcada. En la ventana SMI (trayectorias MIB y PIB) especifique la carpeta con las MIBs descargadas y en los módulos SMI (MIB y PIB). CISCO-ENHANCED-MEMPOOL-MIB se agrega automáticamente a la lista de módulos:
3. Una vez que se reinicia Wireshark, se activa la resolución OID:
En base al resultado descifrado del archivo de captura, la herramienta de monitoreo SNMP era datos de sondeo periódicos (intervalo de 10 segundos) sobre el uso de conjuntos de memoria en el FTD. Como se explica en el artículo de TechNote Sondeo SNMP ASA para estadísticas relacionadas con la memoria que sondea el uso del Global Shared Pool (GSP) usando resultados SNMP en los acaparamientos de CPU. En este caso a partir de las capturas, estaba claro que el uso del Conjunto Compartido Global se sondeaba periódicamente como parte del comando SNMP getBulkRequest primitivo.
Para minimizar los acaparamientos de la CPU causados por el proceso SNMP, se recomendó seguir los pasos de mitigación para los Hogs de la CPU para SNMP mencionados en el artículo y evitar sondear los OID relacionados con el GSP. Sin el sondeo SNMP para los OID que se relacionan con el GSP, no se observó ningún acaparamiento de la CPU causado por el proceso SNMP y la velocidad de desbordamientos disminuyó significativamente.