Customer is noticing the following sessions in flow session table in his SRX5k series device and is wondering if this indicates a problem or that's normal behavior (no packet loss is reported from users):

Flow Sessions on FPC0 PIC0:

Session ID: 298301, Policy name: allow_vpn_in/149, HA State: Active, Timeout: 4, Session State: Pending
  In: 192.168.3.7/16230 --> 172.16.3.202/0;icmp, Conn Tag: 0x0, If: reth1.0, Pkts: 0, Bytes: 0, CP Session ID: 100416
  Out: 172.16.3.202/0 --> 0.0.0.0/16230;0, Conn Tag: 0x0, If: st0.130, Pkts: 0, Bytes: 0, CP Session ID: 0

...

We can see that there is a pending session for 0.0.0.0 destination IP wing session, but Valid session where the source and destination IP is present, and these sessions both reside on different SPUs:

Flow Sessions on FPC0 PIC0:

Session ID: 298301, Policy name: allow_vpn_in/149, HA State: Active, Timeout: 4, Session State: Pending
  In: 192.168.3.7/16230 --> 172.16.3.202/0;icmp, Conn Tag: 0x0, If: reth1.0, Pkts: 0, Bytes: 0, CP Session ID: 100416
  Out: 172.16.3.202/0 --> 0.0.0.0/16230;0, Conn Tag: 0x0, If: st0.130, Pkts: 0, Bytes: 0, CP Session ID: 0

Flow Sessions on FPC0 PIC1:

Session ID: 1099512201323, Policy name: allow_vpn_in/149, HA State: Active, Timeout: 2, Session State: Valid
  In: 192.168.3.7/16230 --> 172.16.3.202/0;icmp, Conn Tag: 0x0, If: reth1.0, Pkts: 1, Bytes: 84, CP Session ID: 100416
  Out: 172.16.3.202/0 --> 192.168.3.7/16230;icmp, Conn Tag: 0x0, If: st0.130, Pkts: 1, Bytes: 84, CP Session ID: 100416

The described behavior is by design on SRX5k series devices in a scenario where ipsec session affinity is enabled:

security {
    flow {
        ...
        load-distribution {
            session-affinity {
                ipsec;
            }
        }

When a packet for IPsec tunnel is received on non-anchor SPU, this packet will trigger the 0.0.0.0 Pending session installation. It is used only temporarily to forward the actual packet to anchor SPU where first-path session installation is happening. It is used only initially while session is created and should be in Pending state with short timeout value. Next packet that will come into reth1.0 interface belonging to this same session will be sent from NP cache to the anchor SPU directly and we will not see such Pending session with 0.0.0.0 IP.