| Description |
This article describes how to identify a specific session that is not sync from the primary to the secondary FortiGate unit in an HA setup. |
| Scope | FortiGate. |
| Solution |
First, run the following commands on both the primary and secondary units to display the session list for SCTP Traffic:
diag sys session filter clear diag sys session filter proto 132 diag sys session list diag sys session list | grep total
Here, the primary unit has 25233:
The secondary unit has 25229:
There are 4 SCTP sessions not synced from master to slave.
The second step is to save these session list logs to the linux device (Ubuntu in this example). In this case, they were saved under the /var/log directory.
Now, run this command on a Linux box to filter the serial number of each session from the logs and save it in another separate text file, and then compare them. This will help to identify which sessions are present in the primary unit but not in the secondary, using the serial details in the session list.
Now, compare the primary unit's serial log with the secondary unit's serial log and output it to another text file to see which session serial is present in the primary and not in the secondary.
From there, identify which serial was present in the primary and not in the secondary unit using the diffmasterslaveserial.txt file.
It is now possible to use this serial number to check the session list that was gathered in step one to identify the sessions present in the primary but not in the secondary. For example, using the serial number 7c521b3a:
In this example, research was conducted to understand why this session was not syncing from the primary to the secondary unit. Based on findings, this session has a SCTP proto_state of 05: it will not sync from the primary FortiGate to the secondary because this proto_state 05 can be considered a dead SCTP session. See Troubleshooting Tip: FortiGate session table information for more information. |
