Problemen met FTD-clusterasymmetrie oplossen die TCP-verbindingsfouten veroorzaken

uitgeven

Een of meer van deze symptomen kunnen optreden:

• Intermitterende connectiviteitsfouten voor toepassingen die een FTD-cluster doorkruisen

• TCP-handshake in drie richtingen mislukt tijdens verbindingspogingen.

• De client verzendt een SYN-pakket, maar ontvangt niet de verwachte SYN-ACK-respons.

• De client verzendt een RST-pakket na de eerste SYN.

milieu

• Voor het eerst gezien in Secure Firewall Threat Defense 7.4 - andere versies kunnen ook worden beïnvloed

• Clusterconfiguratie

• Load balancer in het netwerkpad — optioneel

Topologie

inline_image_0.png

resolutie

Om het probleem bij de wortel te veroorzaken, moet u op deze punten gelijktijdig vastleggen:

• FW1-binneninterface (met opnieuw injecteren-verbergen)

• FW1-buiteninterface (met opnieuw injecteren-verbergen)

• FW1-clusterinterface (CCL)

• FW2-binneninterface (met opnieuw injecteren-verbergen)

• FW2-buiteninterface (met opnieuw injecteren-verbergen)

• FW2-clusterinterface (CCL)

• De klant (of zo dicht mogelijk bij de klant)

• Server (of zo dicht mogelijk bij de server)

Voor meer informatie over het configureren van de vastgelegde bestanden, controleert u: Hoe kunt u de vastgelegde clusters inschakelen.

 Opnamen die op beide firewalls samen met client en server zijn gemaakt, onthullen deze topologie:

inline_image_0.png

1. De client verzendt TCP SYN. Het pakket komt aan bij de load balancer (LB) en wordt verzonden naar FW1.

2. FW1 ontvangt het TCP SYN-pakket en wordt eigenaar van de stroom.

3. FW1 informeert de regisseur (FW2) over de eigenaar van de stroom door een speciaal (clu add) clusterbericht te verzenden.

4. FW1 stuurt het TCP-SYN door naar de bestemmingsserver.

5. De server antwoordt met SYN/ACK. In dit geval hebben we een asymmetrische stroom omdat de SYN / ACK naar FW2 wordt verzonden vanwege het algoritme voor load-balancing van het poortkanaal.

6. SYN/ACK arriveert op FW2 voordat het clu-bericht wordt toegevoegd. Dit is een raciale conditie en is puur omgevingsgebonden (zoals latentie in CCL). Aangezien FW2 niet weet wie de eigenaar van de stroom is, wordt de SYN/ACK verwijderd.

7. Er wordt een TCP RST naar de server verzonden.

8. Het clu-add-bericht komt binnen op FW2.

9. De client verzendt het TCP SYN-pakket opnieuw. Het TCP SYN-pakket wordt doorgestuurd naar de bestemmingsserver.

10. Op de LB, de TCP-verbinding voor de specifieke doorstroomtijden uit.

11. De server antwoordt met SYN/ACK (TCP-hertransmissie). Het SYN/ACK-pakket komt binnen op FW2. Deze keer weet FW2 van de eigenaar van de stroom, omdat deze het clu add-bericht heeft gekregen en de SYN / ACK wordt doorgestuurd naar de eigenaar van de stroom via de CCL. De SYN/ACK wordt naar de client verzonden.

12. De LB is niet op de hoogte van deze stroom en laat de SYN/ACK vallen. De SYN/ACK komt dus nooit aan bij de klant.

13. De LB één of meer TCP RST-pakketten. 

Firewall vastleggen met sporenanalyse

In deze uitgangen werden opnames verzameld van de firewall op CCL en server-facing interfaces:

· Op CCL is de opname op de UDP 4193-poort.

· Op de data-interfaces komt het vastleggen overeen met TCP-verkeer tussen de eindpunten met behulp van de optie opnieuw injecteren-verbergen. De reden is dat we willen zien waar de pakketten daadwerkelijk aankomen.

· IP-adres 192.0.2.65 = client

· IP-adres 192.0.2.6 = server

Stap 1: Gebruik deze opdracht op het firewall-apparaat dat de SYN/ACK krijgt om te zien wanneer het clu-add-bericht is aangekomen. In de CLI-uitvoer wordt het bericht weergegeven als stroom toevoegen.

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

  

Stap 2: Traceer het SYN/ACK-pakket en focus op de tijdstempel en het traceresultaat:

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

Belangrijkste punten

· Het bericht Add flow arriveerde om 08:14:20.630521 terwijl de SYN/ACK ~2 msec eerder om 08:14:20.628690 arriveerde. Dit is de conditie van het ras.

· Het SYN/ACK-pakket wordt door de firewall gedropt met tcp-not-syn ASP-reden. Merk op dat in fase 4 de firewall probeerde te identificeren of er een bekende eigenaar van de stroom was, maar er geen vond. Het probeerde een flow-eigenaar te worden.

Deze uitvoer toont een spoor van de SYN/ACK wanneer de firewall weet van de stroom:

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#

Het belangrijkste punt is fase 3. De firewall weet dat de clustereenheid 1 de eigenaar van de stroom is. U kunt de opdracht Clusterinfo weergeven gebruiken om te zien welk apparaat eenheid 0 is en welk apparaat eenheid 1 is.

Veelgestelde vragen

V. Waarom zien we intermitterende TCP-connectiviteitsproblemen?

A. Aangezien dit een racetoestand is, gebeurt dit willekeurig. De conditie van het ras kan dienovereenkomstig worden gevisualiseerd:

inline_image_0.png

V. Wat zijn mogelijke oplossingen om de race conditie te voorkomen?

A. 

Oplossing 1: Schakel de TCP-volgnummerrandomisatie in om te profiteren van het TCP SYN-cookiemechanisme. In dat geval is de communicatie dienovereenkomstig gestructureerd:

inline_image_1.png

Oplossing 2: Elimineer de asymmetrie in het netwerk. Eerst moet je de oorzaak van de asymmetrie achterhalen. Dit kan onder andere vereisen dat het algoritme voor de load-balancing van het poortkanaal wordt afgestemd, dat de kabels van het poortkanaal in verschillende volgorde worden herbekabeld.

Oorzaak

De hoofdoorzaak is een racetoestand die wordt veroorzaakt door clusterasymmetrie binnen de FTD-clusterimplementatie. De SYN-ACK-pakketten van de server worden verwerkt door een andere FTD-clusternode dan degene die het eerste SYN-pakket heeft verwerkt, waardoor de juiste instelling van TCP-sessies wordt voorkomen.

Verwante inhoud

• Cisco Technical Support en downloads

Revisiegeschiedenis

Revisie	Publicatiedatum	Opmerkingen
3.0	23-Apr-2026	Opmaak en interpunctie.
2.0	15-Apr-2026	Afbeeldingen toegevoegd
1.0	09-Apr-2026	Eerste vrijgave