Fortinet black logo

Session-Aware Load Balancing Cluster Guide

Dual mode SLBC with four FortiController-5103Bs and two chassis

5.2.10
Copy Link
Copy Doc ID 31a89d05-200d-11e9-b6f6-f8bc1258b856:251939
Download PDF

Dual mode SLBC with four FortiController-5103Bs and two chassis

This example describes how to setup a dual-mode session-aware load balancing cluster (SLBC) consisting of two FortiGate-5000 chassis, four FortiController-5103Bs two in each chassis, and six FortiGate-5001Bs acting as workers, three in each chassis. This SLBC configuration can have up to 14 redundant 10Gbit network connections.

In this dual mode configuration, the FortiController in chassis 1 slot 1 is configured to become the primary unit. Both of the FortiControllers in chassis 1 receive traffic and load balance it to the workers in chassis 1. In dual mode configuration the front panel interfaces of both FortiControllers are active. All networks have single connections to the FortiController in slot 1 or the FortiController in slot 2. It is a best practice in a dual-mode configuration to distribute traffic evenly between the FortiControllers. So in this example, ingress traffic from the Internet is processed by the FortiController in slot 1 and egress traffic for the internal network is processed by the FortiController in slot 2.

Note Redundant connections to a network from the FortiControllers in the same chassis is not supported (unless you configure link aggregation).

The front panel F1 to F8 interfaces of the FortiController in slot 1 are named fctrl1/f1 to fctrl1/f8 and the front panel F1 to F8 interfaces of the FortiController in slot 2 are named fctrl2/f1 to fctrl2/f8.

The network connections to the FortiControllers in chassis 1 are duplicated with the FortiControllers in chassis 2. If one of the FortiControllers in chassis 1 fails, the FortiController in chassis 2 slot 1 becomes the primary FortiController and all traffic fails over to the FortiControllers in chassis 2. If one of the FortiControllers in chassis 2 fails, the remaining FortiController in chassis 2 keeps processing traffic received by its front panel interfaces. Traffic to and from the failed FortiController is lost.

Heartbeat and base control and management communication is established between the chassis using the FortiController B1 and B2 interfaces. Only one heartbeat connection is required but redundant connections are recommended. Connect all of the B1 and all of the B2 interfaces together using switches. This example shows using one switch for the B1 connections and another for the B2 connections. You could also use one switch for both the B1 and B2 connections but using separate switches provides more redundancy.

The following VLAN tags and subnets are used by traffic on the B1 and B2 interfaces:

  • Heartbeat traffic uses VLAN 999.
  • Base control traffic on the 10.101.11.0/255.255.255.0 subnet uses VLAN 301.
  • Base management on the 10.101.10.0/255.255.255.0 subnet uses VLAN 101.

This example also includes a FortiController session sync connection between the FortiControllers using the FortiController F4 front panel interface (resulting in the SLBC having a total of 14 redundant 10Gbit network connections). (You can use any fabric front panel interface, F4 is used in this example to make the diagram clearer.)

In a two chassis dual mode cluster, session sync ports need to be 1-to-1 connected according to chassis slot. So F4 from the FortiController in chassis 1 slot 1 needs to be connected to F4 in chassis 2 slot 1. And, F4 in chassis 1 slot 2 needs to be connected to F4 in chassis 2 slot 2. Because these are 1 to 1 connections you can use patch cables to connect them. You can also make these connections through a switch.

FortiController-5103B session sync traffic uses VLAN 2000.

This example sets the device priority of the FortiController in chassis 1 slot 1 higher than the device priority of the other FortiControllers to make sure that the FortiController in chassis 1 slot 1 becomes the primary FortiController for the cluster. Override is also enabled on the FortiController in chassis 1 slot 1. Override may cause the cluster to negotiate more often to select the primary unit. This makes it more likely that the unit that you select to be the primary unit will actually be the primary unit; but enabling override can also cause the cluster to negotiate more often.

Dual mode SLBC with four FortiController-5103Bs and two chassis

This example describes how to setup a dual-mode session-aware load balancing cluster (SLBC) consisting of two FortiGate-5000 chassis, four FortiController-5103Bs two in each chassis, and six FortiGate-5001Bs acting as workers, three in each chassis. This SLBC configuration can have up to 14 redundant 10Gbit network connections.

In this dual mode configuration, the FortiController in chassis 1 slot 1 is configured to become the primary unit. Both of the FortiControllers in chassis 1 receive traffic and load balance it to the workers in chassis 1. In dual mode configuration the front panel interfaces of both FortiControllers are active. All networks have single connections to the FortiController in slot 1 or the FortiController in slot 2. It is a best practice in a dual-mode configuration to distribute traffic evenly between the FortiControllers. So in this example, ingress traffic from the Internet is processed by the FortiController in slot 1 and egress traffic for the internal network is processed by the FortiController in slot 2.

Note Redundant connections to a network from the FortiControllers in the same chassis is not supported (unless you configure link aggregation).

The front panel F1 to F8 interfaces of the FortiController in slot 1 are named fctrl1/f1 to fctrl1/f8 and the front panel F1 to F8 interfaces of the FortiController in slot 2 are named fctrl2/f1 to fctrl2/f8.

The network connections to the FortiControllers in chassis 1 are duplicated with the FortiControllers in chassis 2. If one of the FortiControllers in chassis 1 fails, the FortiController in chassis 2 slot 1 becomes the primary FortiController and all traffic fails over to the FortiControllers in chassis 2. If one of the FortiControllers in chassis 2 fails, the remaining FortiController in chassis 2 keeps processing traffic received by its front panel interfaces. Traffic to and from the failed FortiController is lost.

Heartbeat and base control and management communication is established between the chassis using the FortiController B1 and B2 interfaces. Only one heartbeat connection is required but redundant connections are recommended. Connect all of the B1 and all of the B2 interfaces together using switches. This example shows using one switch for the B1 connections and another for the B2 connections. You could also use one switch for both the B1 and B2 connections but using separate switches provides more redundancy.

The following VLAN tags and subnets are used by traffic on the B1 and B2 interfaces:

  • Heartbeat traffic uses VLAN 999.
  • Base control traffic on the 10.101.11.0/255.255.255.0 subnet uses VLAN 301.
  • Base management on the 10.101.10.0/255.255.255.0 subnet uses VLAN 101.

This example also includes a FortiController session sync connection between the FortiControllers using the FortiController F4 front panel interface (resulting in the SLBC having a total of 14 redundant 10Gbit network connections). (You can use any fabric front panel interface, F4 is used in this example to make the diagram clearer.)

In a two chassis dual mode cluster, session sync ports need to be 1-to-1 connected according to chassis slot. So F4 from the FortiController in chassis 1 slot 1 needs to be connected to F4 in chassis 2 slot 1. And, F4 in chassis 1 slot 2 needs to be connected to F4 in chassis 2 slot 2. Because these are 1 to 1 connections you can use patch cables to connect them. You can also make these connections through a switch.

FortiController-5103B session sync traffic uses VLAN 2000.

This example sets the device priority of the FortiController in chassis 1 slot 1 higher than the device priority of the other FortiControllers to make sure that the FortiController in chassis 1 slot 1 becomes the primary FortiController for the cluster. Override is also enabled on the FortiController in chassis 1 slot 1. Override may cause the cluster to negotiate more often to select the primary unit. This makes it more likely that the unit that you select to be the primary unit will actually be the primary unit; but enabling override can also cause the cluster to negotiate more often.