SRX

Hey guys.

As explained in this KB article, the primary node in an SRX cluster setup will not sync ICMP sessions to the secondary node. And this can be fixed with the "sync-icmp-session" command on the SRX:

CEC Juniper Community

We've seen issues with ICMP when the request goes out on an interface on the primary node and the reply comes in on an interface on the secondary node. The secondary node drops the incoming reply. And this is natural when the secondary node does not have an session to match with. As I've said, this is fixed with the command "sync-icmp-session". 

But my question is: why is the default behaviour not to sync ICMP sessions to the secondary node? Is there a reason not to always have "sync-icmp-session" configured?

Hey guys.

As explained in this KB article, the primary node in an SRX cluster setup will not sync ICMP sessions to the secondary node. And this can be fixed with the "sync-icmp-session" command on the SRX:

CEC Juniper Community

We've seen issues with ICMP when the request goes out on an interface on the primary node and the reply comes in on an interface on the secondary node. The secondary node drops the incoming reply. And this is natural when the secondary node does not have an session to match with. As I've said, this is fixed with the command "sync-icmp-session". 

But my question is: why is the default behaviour not to sync ICMP sessions to the secondary node? Is there a reason not to always have "sync-icmp-session" configured?

Also, ICMP sessions are quite ephemeral. Or maybe I just can't think of a use case where an ICMP session has to survive for much longer than a couple of packets. So why bother syncing it up to the backup anyway.

Hey guys.

As explained in this KB article, the primary node in an SRX cluster setup will not sync ICMP sessions to the secondary node. And this can be fixed with the "sync-icmp-session" command on the SRX:

CEC Juniper Community

We've seen issues with ICMP when the request goes out on an interface on the primary node and the reply comes in on an interface on the secondary node. The secondary node drops the incoming reply. And this is natural when the secondary node does not have an session to match with. As I've said, this is fixed with the command "sync-icmp-session". 

But my question is: why is the default behaviour not to sync ICMP sessions to the secondary node? Is there a reason not to always have "sync-icmp-session" configured?

Hi Nikolay. Thank you for your insights. 

As I mentioned the reason we look into this is because we have uplinks to the Internet on both the secondary node and the primary node in an SRX cluster. When ICMP requst goes out the interface on the primary node and the return ICMP response comes in on the interface of the secondary node, then the secondary node drops return ICMP packets. This because it does not have a session for the flow. 

Note that this is passing traffic through the SRX cluster (ie. from a client to a host on the Internet). This is not related to ICMP traffic for one of the nodes. 

Juniper added this setting  for some reason as early as in 2012. A colleague of mine is of the opinion that when Juniper adds these kinds of features, it will not become enabled automatically. It will be up to the network administrators to enable it if it is necessary. And the points you make about pinging the secondary node it self through the primary node, might be one of the reasons why they don't enable it by default. 

But this is currently not a potential problem for us. So unless anyone else has opinions about possible issues by enabling this, I think I've got what I needed. 

Also, ICMP sessions are quite ephemeral. Or maybe I just can't think of a use case where an ICMP session has to survive for much longer than a couple of packets. So why bother syncing it up to the backup anyway.

Hey guys.

As explained in this KB article, the primary node in an SRX cluster setup will not sync ICMP sessions to the secondary node. And this can be fixed with the "sync-icmp-session" command on the SRX:

CEC Juniper Community

We've seen issues with ICMP when the request goes out on an interface on the primary node and the reply comes in on an interface on the secondary node. The secondary node drops the incoming reply. And this is natural when the secondary node does not have an session to match with. As I've said, this is fixed with the command "sync-icmp-session". 

But my question is: why is the default behaviour not to sync ICMP sessions to the secondary node? Is there a reason not to always have "sync-icmp-session" configured?

Out of curiosity, how come the return traffic is arriving on the node it didn't go out of?

Hi Nikolay. Thank you for your insights. 

As I mentioned the reason we look into this is because we have uplinks to the Internet on both the secondary node and the primary node in an SRX cluster. When ICMP requst goes out the interface on the primary node and the return ICMP response comes in on the interface of the secondary node, then the secondary node drops return ICMP packets. This because it does not have a session for the flow. 

Note that this is passing traffic through the SRX cluster (ie. from a client to a host on the Internet). This is not related to ICMP traffic for one of the nodes. 

Juniper added this setting  for some reason as early as in 2012. A colleague of mine is of the opinion that when Juniper adds these kinds of features, it will not become enabled automatically. It will be up to the network administrators to enable it if it is necessary. And the points you make about pinging the secondary node it self through the primary node, might be one of the reasons why they don't enable it by default. 

But this is currently not a potential problem for us. So unless anyone else has opinions about possible issues by enabling this, I think I've got what I needed. 

Also, ICMP sessions are quite ephemeral. Or maybe I just can't think of a use case where an ICMP session has to survive for much longer than a couple of packets. So why bother syncing it up to the backup anyway.

Hey guys.

As explained in this KB article, the primary node in an SRX cluster setup will not sync ICMP sessions to the secondary node. And this can be fixed with the "sync-icmp-session" command on the SRX:

CEC Juniper Community

We've seen issues with ICMP when the request goes out on an interface on the primary node and the reply comes in on an interface on the secondary node. The secondary node drops the incoming reply. And this is natural when the secondary node does not have an session to match with. As I've said, this is fixed with the command "sync-icmp-session". 

But my question is: why is the default behaviour not to sync ICMP sessions to the secondary node? Is there a reason not to always have "sync-icmp-session" configured?

Basically it has to do with the fact that we have equal cost routing towards our ISP. And the return traffic from our ISP is determined by the routing on their side. 

Out of curiosity, how come the return traffic is arriving on the node it didn't go out of?

Hi Nikolay. Thank you for your insights. 

As I mentioned the reason we look into this is because we have uplinks to the Internet on both the secondary node and the primary node in an SRX cluster. When ICMP requst goes out the interface on the primary node and the return ICMP response comes in on the interface of the secondary node, then the secondary node drops return ICMP packets. This because it does not have a session for the flow. 

Note that this is passing traffic through the SRX cluster (ie. from a client to a host on the Internet). This is not related to ICMP traffic for one of the nodes. 

Juniper added this setting  for some reason as early as in 2012. A colleague of mine is of the opinion that when Juniper adds these kinds of features, it will not become enabled automatically. It will be up to the network administrators to enable it if it is necessary. And the points you make about pinging the secondary node it self through the primary node, might be one of the reasons why they don't enable it by default. 

But this is currently not a potential problem for us. So unless anyone else has opinions about possible issues by enabling this, I think I've got what I needed. 

Also, ICMP sessions are quite ephemeral. Or maybe I just can't think of a use case where an ICMP session has to survive for much longer than a couple of packets. So why bother syncing it up to the backup anyway.

Hey guys.

As explained in this KB article, the primary node in an SRX cluster setup will not sync ICMP sessions to the secondary node. And this can be fixed with the "sync-icmp-session" command on the SRX:

CEC Juniper Community

We've seen issues with ICMP when the request goes out on an interface on the primary node and the reply comes in on an interface on the secondary node. The secondary node drops the incoming reply. And this is natural when the secondary node does not have an session to match with. As I've said, this is fixed with the command "sync-icmp-session". 

But my question is: why is the default behaviour not to sync ICMP sessions to the secondary node? Is there a reason not to always have "sync-icmp-session" configured?