Who rated this post

I've heard this recommended by Tim as well which is why I'm looking at it. Let me enrich this story and see if it makes a difference in your answer. 

Specifically, we're seeing an issue when we're expanding security groups on a chassis. The basic process is down the standby, insert blades, add them to the security group with autoclone enabled, bring the standby back up. Here's where the problem occurs. When we bring the standby back up there is a mismatch of blades, and we believe that it messes with SyncXL. Where let's say the backup of the connection is on 2_4 (chassis 2 was the standby and where we've expanded the security group). When we bring chassis 2 back up, the SyncXL distribution is different from chassis1 to chassis2, and normally the flow would've gone to 2_04, but instead is sent to 2_11 (new blade) which has no knowledge of the connection and is dropped as out of state.  R&D has said this shouldn't happen, but it was proven in solution center. So my question is, if there is no connection registered on 2_11 and we turn off state check, would 2_11 accept the packet and add it to the connection table? 

Adding to the connection table is the big question since these are long lived connections and we don't expect to see a new SYN.