Solucionar problemas de asimetría de clústeres de FTD que provocan errores de conexión TCP

Problema

Pueden aparecer uno o más de estos síntomas:

• Fallos de conectividad intermitentes para aplicaciones que atraviesan un clúster FTD

• El protocolo de enlace de tres vías TCP falla durante los intentos de conexión.

• El cliente envía un paquete SYN, pero no recibe la respuesta SYN-ACK esperada.

• El cliente envía un paquete RST después del SYN inicial.

Entorno

• Visto por primera vez en Secure Firewall Threat Defence 7.4, otras versiones también pueden verse afectadas

• Configuración de agrupamiento

• Equilibrador de carga en la ruta de red: es opcional

Topología

inline_image_0.png

Resolución

Para originar el problema, debe realizar capturas simultáneas en estos puntos:

• Interfaz interna FW1 (con reinyección y ocultación)

• Interfaz exterior FW1 (con reinyección y ocultación)

• Interfaz de clúster FW1 (CCL)

• Interfaz interior FW2 (con reinyección y ocultación)

• Interfaz exterior FW2 (con reinyección y ocultación)

• Interfaz de clúster FW2 (CCL)

• Cliente (o lo más cerca posible del cliente)

• Servidor (o lo más cerca posible del servidor)

Para obtener detalles sobre cómo configurar la verificación de capturas: Cómo Habilitar las Capturas de Clúster.

 Las capturas realizadas en ambos firewalls, junto con el cliente y el servidor, revelan esta topología:

inline_image_0.png

1. El cliente envía TCP SYN. El paquete llega al balanceador de carga (LB) y se envía a FW1.

2. FW1 recibe el paquete TCP SYN y se convierte en el propietario del flujo.

3. FW1 informa al director (FW2) sobre el propietario del flujo mediante el envío de un mensaje de clúster especial (club add).

4. FW1 reenvía el TCP SYN al servidor de destino.

5. El servidor responde con SYN/ACK. En este caso, tenemos un flujo asimétrico ya que SYN/ACK se envía hacia FW2 debido al algoritmo de balanceo de carga de canal de puerto.

6. SYN/ACK llega a FW2 antes del mensaje de adición de club. Esta es una condición de carrera y es puramente ambiental (como la latencia en CCL). Dado que FW2 no sabe quién es el propietario del flujo, se descarta SYN/ACK.

7. Se envía un TCP RST al servidor.

8. El mensaje de adición de club llega al FW2.

9. El cliente retransmite el paquete TCP SYN. El paquete TCP SYN se reenvía al servidor de destino.

10. En el LB, la conexión TCP para el flujo específico agota el tiempo de espera.

11. El servidor responde con SYN/ACK (retransmisión TCP). El paquete SYN/ACK llega a FW2. Esta vez, FW2 conoce al propietario del flujo, ya que recibió el mensaje club add y el SYN/ACK se reenvía al propietario del flujo a través de CCL. El SYN/ACK se envía al cliente.

12. El LB no conoce este flujo y descarta el SYN/ACK. Por lo tanto, el SYN/ACK nunca llega al cliente.

13. El LB tiene uno o más paquetes TCP RST. 

Captura de firewall con análisis de seguimiento

En estos resultados, las capturas se recopilaron del firewall en las interfaces CCL y de cara al servidor:

· En CCL, la captura se realiza en el puerto UDP 4193.

· En las interfaces de datos, la captura coincide con el tráfico TCP entre los terminales usando la opción reinject-hide. La razón es que queremos ver a dónde llegan realmente los paquetes.

· Dirección IP 192.0.2.65 = cliente

· Dirección IP 192.0.2.6 = servidor

Paso 1: Utilice este comando en el dispositivo de firewall que obtiene el SYN/ACK para ver cuándo llegó el mensaje trace add. En la salida de CLI se muestra el mensaje como Add flow.

firepower# show capture CCL decode 
3 packets captured
   1: 08:14:20.630521       127.2.1.1.51475 > 127.2.2.1.4193:  udp 820
        Cluster ASP message: sender: 1, receiver: 0
        Add flow: owner 1, director 0, backup 0,
                  ifc_in INSIDE(7020a7), ifc_out INSIDE(7020a7)
                  TCP src 192.0.2.65/37468, dest 192.0.2.6/80

  

Paso 2: Rastree el paquete SYN/ACK y céntrese en la marca de tiempo y el resultado de seguimiento:

firepower# show capture CAPI packet-number 1 trace
13 packets captured
   1: 08:14:20.628690       802.1Q vlan#200 P0 192.0.2.6.80 > 192.0.2.65.37468: S 2524735158:2524735158(0) ack 2881263901 win 65160 <mss 1460,sackOK,timestamp 611712900 970937593,nop,wscale 7> 
Phase: 1
Type: CAPTURE
Subtype: 
Result: ALLOW
Elapsed time: 1708 ns
Config:
Additional Information:
MAC Access list
  
Phase: 2
Type: ACCESS-LIST
Subtype: 
Result: ALLOW
Elapsed time: 1708 ns
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 3
Type: INPUT-ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Elapsed time: 13664 ns
Config:
Additional Information:
Found next-hop 192.168.200.140 using egress ifc  INSIDE(vrfid:0)

Phase: 4
Type: CLUSTER-EVENT
Subtype: 
Result: ALLOW
Elapsed time: 16104 ns
Config:
Additional Information:
Input interface: 'INSIDE'
Flow type: NO FLOW
I (0) am becoming owner

Phase: 5
Type: OBJECT_GROUP_SEARCH
Subtype: 
Result: ALLOW
Elapsed time: 19520 ns
Config:
Additional Information:
 Source object-group match count:          0
 Source NSG match count:                   0
 Destination NSG match count:              0
 Classify table lookup count:              1
 Total lookup count:                       1
 Duplicate key pair count:                 0
 Classify table match count:               4

Phase: 6
Type: ACCESS-LIST
Subtype: 
Result: ALLOW
Elapsed time: 366 ns
Config:
access-group CSM_FW_ACL_ global
access-list CSM_FW_ACL_ advanced permit ip any any rule-id 268436480 
access-list CSM_FW_ACL_ remark rule-id 268436480: ACCESS POLICY: mzafeiro_empty - Default
access-list CSM_FW_ACL_ remark rule-id 268436480: L4 RULE: DEFAULT ACTION RULE
Additional Information:
 This packet will be sent to snort for additional processing where a verdict will be reached
  
Phase: 7
Type: CONN-SETTINGS
Subtype:      
Result: ALLOW
Elapsed time: 366 ns
Config:
class-map tcp
 match access-list tcp
policy-map global_policy
 class tcp
  set connection conn-max 0 embryonic-conn-max 0 random-sequence-number disable syn-cookie-mss 1380
service-policy global_policy global
Additional Information:
  
Phase: 8
Type: NAT
Subtype: per-session
Result: ALLOW
Elapsed time: 366 ns
Config:
Additional Information:
  
Phase: 9
Type: IP-OPTIONS
Subtype: 
Result: ALLOW
Elapsed time: 366 ns
Config:
Additional Information:
  
Result:
input-interface: INSIDE(vrfid:0)
input-status: up
input-line-status: up
output-interface: INSIDE(vrfid:0)
output-status: up
output-line-status: up
Action: drop
Time Taken: 54168 ns
Drop-reason: (tcp-not-syn) First TCP packet not SYN, Drop-location: frame snp_sp:7459 flow (NA)/NA

Puntos clave

· El mensaje Add flow llegó a las 08:14:20.630521 mientras que el SYN/ACK ~2 ms antes a las 08:14:20.628690. Esta es la condición de carrera.

· El firewall descarta el paquete SYN/ACK con el motivo tcp-not-syn ASP. Observe que en la fase 4 el firewall intentó identificar si había un propietario de flujo conocido pero no encontró ninguno. Por lo tanto, intentó convertirse en un propietario de flujo.

Este resultado muestra un seguimiento del SYN/ACK cuando el firewall conoce el flujo:

firepower# show capture CAPI packet-number 3 trace

13 packets captured

   3: 08:14:21.629560       802.1Q vlan#200 P0 192.0.2.6.80 > 192.0.2.65.37468: S 2540375172:2540375172(0) ack 2881263901 win 65160 <mss 1460,sackOK,timestamp 611713901 970938595,nop,wscale 7> 
Phase: 1
Type: CAPTURE
Subtype: 
Result: ALLOW
Elapsed time: 1708 ns
Config:
Additional Information:
MAC Access list

Phase: 2
Type: ACCESS-LIST
Subtype: 
Result: ALLOW
Elapsed time: 1708 ns
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 3
Type: CLUSTER-EVENT
Subtype:      
Result: ALLOW
Elapsed time: 3416 ns
Config:
Additional Information:
Input interface: 'INSIDE'
Flow type: STUB
I (0) have flow, valid owner (1).

Phase: 4
Type: CAPTURE
Subtype: 
Result: ALLOW
Elapsed time: 7808 ns
Config:
Additional Information:
MAC Access list

Result:
input-interface: INSIDE(vrfid:0)
input-status: up
input-line-status: up
Action: allow
Time Taken: 14640 ns
              
1 packet shown
firepower#

El punto clave está en la Fase 3. El firewall sabe que la unidad de clúster 1 es el propietario del flujo. Puede utilizar el comando show cluster info para ver qué dispositivo es la unidad 0 y cuál es 1.

Preguntas Frecuentes

P. ¿Por qué vemos problemas de conectividad TCP intermitentes?

R. Dado que se trata de una condición de carrera, se produce al azar. La condición de carrera se puede visualizar en consecuencia:

inline_image_0.png

P. ¿Cuáles son las posibles soluciones para evitar la condición de carrera?

A. 

Solución 1: habilite la aleatorización de números de secuencia TCP para aprovechar el mecanismo de la cookie SYN TCP. En ese caso, la comunicación se estructura en consecuencia:

inline_image_1.png

Solución 2: Elimine la asimetría de la red. En primer lugar, debe identificar el motivo de la asimetría. Esto puede requerir el ajuste del algoritmo de equilibrio de carga del canal de puerto, el nuevo cableado de los cables del canal de puerto en orden diferente, entre otras cosas.

Causa

La causa raíz es una condición de anticipación causada por la asimetría del clúster dentro de la implementación del clúster de FTD. Los paquetes SYN-ACK del servidor están siendo procesados por un nodo de clúster de FTD diferente al que manejó el paquete SYN inicial, lo que impide el establecimiento correcto de la sesión TCP.

Contenido relacionado

• Soporte técnico y descargas de Cisco

Historial de revisiones

Revisión	Fecha de publicación	Comentarios
3.0	23-Apr-2026	Formato y puntuación.
2.0	15-Apr-2026	Imágenes añadidas
1.0	09-Apr-2026	Versión inicial