The store nodes have been unable to obtain IP addresses from the DHCP server in the IDC(hub) through PEER. Through the previous packet capture, it was found that the session of the DHCP request packet can only be seen on the CPE of the store(spoke), and the corresponding session ID cannot be queried on the CPE of the hub. After packet capture at the LAN port of the store and the DMZ interface of the hub, when a problem occurs, there are no data packets on the corresponding DMZ interface of the hub.

The session will return to normal once the specified DHCP session was deleted and the session was re-established. The same can be seen in the packet capture. The successfully requested DHCP is the connection re-established once the session is deleted.

Below symptoms can be noticed in the spoke and the hub.

1. Spoke nodes are unable to obtain IP-Addresses from the DHCP server in the hub.
2. Deleting the existing DHCP session and re-establishing the session resolves the problem.

The Traffic Flow is as below.

Host(dhcp configured)-------> Cisco Switch(Dhcp relay configured)------->SSR (Store)--------->SSR(Hub)------>DHCP Server

Packet is routed from switch(Relay) to DHCP server with normal routing, there is no relay configuration in SSR.

From the packet captures, we could only see the see the Dhcp Discover & Dhcp Request we couldnt see and Dhcp Ack from the server until the user manually delete the existing session. As soon as the existing session is deleted, we start receiving DHCP Discover, Offer, Request and Ack from the DHCP server towards the DHCP relay and once the relay receives the acknowledgement, the spokes are provided with the IP-Addresses.

The relay sessions on the spoke have activity on the forward flow but not the reverse and hence it is an issue with the stuck sessions. From the stats, we can see that the spoke is not sending out any delete-stuck-session packets, which would normally be sent to the hub to delete the session there to unstuck relay traffic.

SSR has a session-recovery-detection config field that specifies how to detect a stuck-session. By default this is packet-based, but since there are no packets coming in on the forward flow, we need to change the setting to inactivity-based which will allow the spoke to catch these relay sessions being stuck since there is no activity on the reverse flow. Detailed information about session-recovery-detection can be found at session-recovery-detection.

The below configuration needs to be added on the conductor and the routers where the sessions are getting stuck.

From GUI : The option is available under Authority

 From PCLI : The below configuration needs to be added.

config

  authority     

    session-recovery-detection

      mode        inactivity-based

      inactivity-timeout 1

    exit

  exit

exit