SRX Services Gateway
SRX Services Gateway

Chassis cluster some traffic only seen on secondary / inactive node

[ Edited ]
‎12-20-2018 06:37 AM

Hi!

 

I have a strange issue.

I have a static NAT Rule configured on my chussis cluster. So far so good.

It worked for a couple of months. Today users complain that they cannot connect to the server behind this NAT rule.

 

set security nat static rule-set static_nat_rule_untrust rule static_nat_rule_test match destination-address 2.2.2.2/32
set security nat static rule-set static_nat_rule_untrust rule static_nat_rule_test match destination-port 60000
set security nat static rule-set static_nat_rule_untrust rule static_nat_rule_test match destination-port to 60050
set security nat static rule-set static_nat_rule_untrust rule static_nat_rule_test then static-nat prefix 192.168.0.1/32
set security nat static rule-set static_nat_rule_untrust rule static_nat_rule_test then static-nat prefix mapped-port 60000
set security nat static rule-set static_nat_rule_untrust rule static_nat_rule_test then static-nat prefix mapped-port to 60050

 

When I take a look at the security flow, I see that the traffic is only hitting the passive node (node0).

show security flow session source-prefix 46.142.2.219 destination-prefix 2.2.2.2    
node0:
--------------------------------------------------------------------------

Session ID: 242003, Policy name: untrust_nach_pritunl/465, State: Backup, Timeout: 1798, Valid
  In: 46.142.2.219/49746 --> 2.2.2.2/60009;udp, If: reth0.1, Pkts: 0, Bytes: 0
  Out: 192.168.0.1/60009 --> 46.142.2.219/49746;udp, If: reth6.1, Pkts: 0, Bytes: 0
Total sessions: 1

node1:
--------------------------------------------------------------------------
Total sessions: 0

 Here's my chassis cluster status:

show chassis cluster status 
Monitor Failure codes:
    CS  Cold Sync monitoring        FL  Fabric Connection monitoring
    GR  GRES monitoring             HW  Hardware monitoring
    IF  Interface monitoring        IP  IP monitoring
    LB  Loopback monitoring         MB  Mbuf monitoring
    NH  Nexthop monitoring          NP  NPC monitoring              
    SP  SPU monitoring              SM  Schedule monitoring
 
Cluster ID: 1
Node   Priority Status         Preempt Manual   Monitor-failures

Redundancy group: 0 , Failover count: 3
node0  100      secondary      no      yes      None           
node1  255      primary        no      yes      None           

Redundancy group: 1 , Failover count: 5
node0  100      secondary      no      no       None           
node1  1        primary        no      no       None        

All the other NAT rules (source/destination/static) are working just fine!

Any idea why node1 is not getting any of this packages?

 

 

Greetings

Andy

3 REPLIES 3
SRX Services Gateway
Solution
Accepted by topic author MetzingerAn
‎02-20-2019 06:22 AM

Re: Chassis cluster some traffic only seen on secondary / inactive node

‎12-20-2018 08:16 AM

Looks like the issue is external to SRX. May be session is reset by server. Is the server accessible locally on those ports?

The session timeout on secondary node is 8 times higher than primary node and the session will not age immediately on secondary node like primary node. If you have access to internal system, try to do packet capture or do it from SRX and analyze it.

 

 

 

Thanks,
Nellikka
JNCIE x3 (SEC #321; SP #2839; ENT #790)
Please Mark My Solution Accepted if it Helped, Kudos are Appreciated too!!!
SRX Services Gateway

Re: Chassis cluster some traffic only seen on secondary / inactive node

‎12-21-2018 03:20 AM

how are the switch ports connected to the SRX cluster RETH interfaces configured?

I've seen this behavior if the switch side is an AE bundle facing the RETH redundant interface.  They don't then know that the RETH is active/passive and not a lag bundle.

 

Steve Puluka BSEET - Juniper Ambassador
IP Architect - DQE Communications Pittsburgh, PA (Metro Ethernet & ISP)
http://puluka.com/home
SRX Services Gateway

Re: Chassis cluster some traffic only seen on secondary / inactive node

‎02-20-2019 06:24 AM

Sorry for the late reply!

You were totally right. The Server had reset the sessions therefore I wasn't able to see those sessions...

 

Thanks to everyone for your help.