Fortinet Document Library

Version:

Version:


Table of Contents

Administration Guide

Download PDF
Copy Link

Verification

Generate traffic from the Tester to target the following sessions numbers:

  • There will be 2500 sessions on each component between AWS-CORP, CORP-AWS, Azure-CORP, and CORP-Azure.
  • There will be 200 sessions on each component between the Customer-CORP and CORP-Customer networks. These sessions are SNAT and DNAT on the corresponding VDOMs.
  • In order to observe failover cases to ensure that there is no session failure, the sessions will be opened, kept active, and data will be sent inside each session. When the target session number is reached, new sessions will no longer be created, but data will continue to be sent over the open sessions.

Session synchronization between all FGSP members

The VDOM data shows that the sessions are synchronized between FGSP members. Because the FG-3600-1 and FG-3600-2 have AS-Path prepending, the FG-3400-1 is chosen as the preferred route. Sessions are synchronized among the FGSP members, but traffic only passes through the FG-3400-1.

Global VDOM

FG-3400-1:

FG-3600-1:

FG-3600-2:

AWS VDOM

FG-3400-1:

FG-3600-1:

FG-3600-2:

Azure VDOM

FG-3400-1:

FG-3600-1:

FG-3600-2:

Customer VDOM

FG-3400-1:

FG-3600-1:

FG-3600-2:

Root VDOM

FG-3400-1:

FG-3600-1:

FG-3600-2:

Example SNAT and DNAT output from Customer VDOM:
(Cust) # get system session list

Session continuation while FGSP members fail

When the FG-3400-1 and FG-3600-1 are rebooted in that order, traffic continues to flow on FGSP members based on route preference.

FG-3400-1 SNMP statistics during reboot test:

FG-3600-1 SNMP statistics during reboot test:

FG-3600-2 SNMP statistics during reboot test:

Summary

In these two scenarios, sessions are successfully synchronized between FGSP members with different models and firmware. In the event of failure, traffic successfully gets re-routed to the next preferred firewall and continues to flow.

These functions can be applied to broader use cases where a new FortiGate model can be rolled out into production with minimal downtime by using FGSP to peer with existing FortiGates and executing session synchronization. Another use case is to temporarily offload traffic to a standby FortiGate of a different model in order to performance maintenance on the production firewall.

Verification

Generate traffic from the Tester to target the following sessions numbers:

  • There will be 2500 sessions on each component between AWS-CORP, CORP-AWS, Azure-CORP, and CORP-Azure.
  • There will be 200 sessions on each component between the Customer-CORP and CORP-Customer networks. These sessions are SNAT and DNAT on the corresponding VDOMs.
  • In order to observe failover cases to ensure that there is no session failure, the sessions will be opened, kept active, and data will be sent inside each session. When the target session number is reached, new sessions will no longer be created, but data will continue to be sent over the open sessions.

Session synchronization between all FGSP members

The VDOM data shows that the sessions are synchronized between FGSP members. Because the FG-3600-1 and FG-3600-2 have AS-Path prepending, the FG-3400-1 is chosen as the preferred route. Sessions are synchronized among the FGSP members, but traffic only passes through the FG-3400-1.

Global VDOM

FG-3400-1:

FG-3600-1:

FG-3600-2:

AWS VDOM

FG-3400-1:

FG-3600-1:

FG-3600-2:

Azure VDOM

FG-3400-1:

FG-3600-1:

FG-3600-2:

Customer VDOM

FG-3400-1:

FG-3600-1:

FG-3600-2:

Root VDOM

FG-3400-1:

FG-3600-1:

FG-3600-2:

Example SNAT and DNAT output from Customer VDOM:
(Cust) # get system session list

Session continuation while FGSP members fail

When the FG-3400-1 and FG-3600-1 are rebooted in that order, traffic continues to flow on FGSP members based on route preference.

FG-3400-1 SNMP statistics during reboot test:

FG-3600-1 SNMP statistics during reboot test:

FG-3600-2 SNMP statistics during reboot test:

Summary

In these two scenarios, sessions are successfully synchronized between FGSP members with different models and firmware. In the event of failure, traffic successfully gets re-routed to the next preferred firewall and continues to flow.

These functions can be applied to broader use cases where a new FortiGate model can be rolled out into production with minimal downtime by using FGSP to peer with existing FortiGates and executing session synchronization. Another use case is to temporarily offload traffic to a standby FortiGate of a different model in order to performance maintenance on the production firewall.