Active sessions timeout @ 14,400 seconds (4 hours) [ Edited ]

[Visitor]

Hi,

This is not as per the design behaviour. I will suggest you to enabled the traceoptions for bi-directional packet flow and decrease the ideal time out to 5 sec.So that we can see a session tear down in 40 sec and capture all the information.

The traceoptions can be configured as 

[edit security flow traceoptions]

#set flag basic-datapath

#set file trace

#set packet-filter p1 source-prefix <src.ip> destination-prefix <dst.ip>

#set packet-filter p2 source-prefix <dst.ip> destination-prefix <src.ip>

#commit

Packet filter p2 is for return traffic.Capture the logs and provide the same.

Regards,

Visitor

[olfen]

Was this solved? if so how? Because I have the exact same behavior running 11.2R2.4

[rakeshc]

Hi Ecables,

      This is a known issue. Here is a work around for you. You will have to disable the tcp syn check to get around this problem. Here is the command to do that:

set security flow tcp-session no-syn-check

This issue will be fixed in the future. So using the above command is the only work around. Hope  that helps.

Let me know if you have any questions.

Thanks,
Rakesh

Please mark this as a Solution if your question is answered or your issue is resolved.

Please be sure to visit these great resources:

Knowledge Base - http://kb.juniper.net
JNET forums - http://forums.juniper.net/jnet/

NOTE: Any information that has been provided is to the best of my knowledge and may not reflect the actual information from Juniper.

[Minotaur]

Hello,

> Hi Ecables,

>       This is a known issue. Here is a work around for you. You will have to disable the tcp syn check to get around this >problem. Here is the command to do that:

> 

>set security flow tcp-session no-syn-check

> 

>This issue will be fixed in the future. So using the above command is the only work around. Hope  that helps.

 I have similar issue on cluster of two J6350 boxes with Junos 10.2R3.10.

node1 is primary, node0 is backup at current moment.

minotaur@BACKUP# run show security flow session source-prefix 217.175.10.227
node0:
--------------------------------------------------------------------------

Session ID: 9, Policy name: default-policy/2, State: Backup, Timeout: 2060, Valid
  In: 217.175.10.227/3113 --> 194.247.174.33/80;tcp, If: reth0.501, Pkts: 0, Bytes: 0
  Out: 194.247.174.33/80 --> 217.175.10.227/3113;tcp, If: reth0.609, Pkts: 0, Bytes: 0

Session ID: 22422, Policy name: default-policy/2, State: Backup, Timeout: 470, Valid
  In: 217.175.10.227/1892 --> 194.247.174.33/80;tcp, If: reth0.501, Pkts: 0, Bytes: 0
  Out: 194.247.174.33/80 --> 217.175.10.227/1892;tcp, If: reth0.609, Pkts: 0, Bytes: 0

Session ID: 96085, Policy name: default-policy/2, State: Backup, Timeout: 2092, Valid
  In: 217.175.10.227/3149 --> 194.247.174.14/80;tcp, If: reth0.501, Pkts: 0, Bytes: 0
  Out: 194.247.174.14/80 --> 217.175.10.227/3149;tcp, If: reth0.609, Pkts: 0, Bytes: 0
Total sessions: 3

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

 Why there are backup sessions on node0 without active ones on node1?

set security flow tcp-session no-syn-check is configured but does not help.

[absmith]

---

rakeshc wrote:

Hi Ecables,

      This is a known issue. Here is a work around for you. You will have to disable the tcp syn check to get around this problem. Here is the command to do that:

set security flow tcp-session no-syn-check

This issue will be fixed in the future. So using the above command is the only work around. Hope  that helps. 

---

Is there a  PR number for this?

[marks]

This is an issue that I am experiencing in a cluster of SRX240's running 12.1r2.9  

Anyone know of a fix or release?  For now, I'm going to have the client power down the secondary node.  

[absmith]

The fix jtac had for me was to disable ethernet-switching and change the interface to regular one with VLAN trunking.

JTAC note:

Traffic through a VLAN interface in cluster mode spawns an active session on the backup 
node that will eventually kill the active primary when it times out. We avoided this 
issue entirely by changing that interface into a regular one with VLAN trunking.

[marks]

OK.  I just moved the interfaces to reth interfaces with vlan-tagging and subinterfaces instead of ethernet switching.  I will see if after powering the other node on the issue is still apparent.  Thanks!