Course 301 – Secured Network Deployment and IPSec VPN

Course 301 – Secured Network Deployment and IPSec VPN
High Availability High Availability RTOL

High Availability Module Objectives By the end of this module participants will be able to: Identify the components in a FortiGate high availability cluster Describe the FortiGate HA modes of operation Describe the use of the FortiGate Clustering Protocol Define the failover methods used in FortiGate HA Configure session synchronization Configure a FortiGate HA cluster RTOL

High Availability High Availability Two or more FortiGate units operate as a cluster If one cluster unit fails, another in the cluster replaces it FortiGate HA is implemented by configuring 2 or more FortiGate units to operate as an HA cluster To the network the cluster appears to function as a single FortiGate unit Cluster units share state and configuration information If one unit fails, the other unit in the cluster replaces it After the failure the cluster continues to process network traffic and provide FortiGate services with virtually no interruptions FortiGate HA provides a solution for 2 key requirements of critical enterprise networking Enhanced reliability Increased performance RTOL

High Availability High Availability FortiGate HA is implemented by configuring two or more FortiGate units to operate as an HA cluster The cluster appears to function as a single FortiGate unit Provides enhanced reliability and increased performance Cluster units share state and configuration information If one unit fails, the other unit in the cluster replaces it If one cluster unit fails, another in the cluster replaces it RTOL

High Availability Cluster Membership HA cluster All cluster units require: Identical hardware model Identical firmware versions Same hard disk configuration Same operating mode A FortiGate unit HA cluster can contain up to 32 units. Virtual clustering available for use on FortiGate units with virtual domains. Identical hardware model Identical firmware versions Same hard disk configuration Same operating mode RTOL

High Availability Cluster Units Subordinate units Cluster Primary unit Every FortiGate cluster contains one primary unit (also called a master) and one or more subordinate (slave) units. The primary unit Controls how the cluster operates. It sends hello packets to all cluster units to synchronize session information, cluster configuration and cluster routing table. Also confirms for the subordinate units that the primary is still functioning. The primary also tracts the status of all the subordinate units. Each cluster contains one or more units that are not functioning as the primary unit. They are always waiting to become the primary unit. If it doesn’t receive Hello packets from the primary, it attempts to become the primary. RTOL

High Availability Cluster Units Every cluster contains one primary (master) unit and one or more subordinate (slave) units The primary unit controls how the cluster operates Synchronizes session information with subordinates Synchronizes cluster configuration with subordinates Synchronizes cluster routing table Tracks status of subordinates Subordinates are always waiting to become primary RTOL

Viewing Cluster Members
Course 301 – Secured Network Deployment and IPSec VPN High Availability Viewing Cluster Members Change hostname of the FortiGate unit to simplify administration Using a friendly name for the hostname of the FortiGate device will make it easier to identify the device in the cluster member list. RTOL

High Availability Modes of Operation
Course 301 – Secured Network Deployment and IPSec VPN High Availability High Availability Modes of Operation Active-Passive Configuration of primary is synchronized with subordinates Subordinates run in standby mode Subordinate units Primary unit Active-Passive Mode An active-passive HA cluster provides hot standby failover protection: Provides transparent device failover amongst cluster units. If a cluster unit fails another immediately takes its place. An active-passive HA cluster consists of a primary unit that processes traffic and one or more subordinate units. Subordinates run in standby mode: Subordinate will take over processing traffic if primary unit fails Subordinate unit is synchronized with the configuration of the primary unit The subordinate units monitor the status of the primary unit If session failover is enabled, subordinate units receive cluster state information from the primary unit: This information includes a list of all communication settings being processed by the primary unit. This information is used to resume processing network communications sessions if the primary unit fails. Primary unit processes traffic If primary fails, a subordinate immediately takes its place Click here to read more about HA modes of operation RTOL

Course 301 – Secured Network Deployment and IPSec VPN High Availability High Availability Modes of Operation Active-Passive An active-passive cluster provides hot standby failover protection In an active-passive cluster, the primary unit processes all traffic, while the subordinate units run in standby mode The configuration of primary is synchronized with subordinates If primary unit fails, a subordinate will resume processing traffic Synchronized state information provides transparent failover Click here to read more about HA modes of operation RTOL

Course 301 – Secured Network Deployment and IPSec VPN High Availability High Availability Modes of Operation Active-Active Subordinate units also process traffic Active-Active Mode Active-active HA load balances communication sessions and provides failover protection among all cluster units. The cluster consists of primary unit that processes communication settings and one or more subordinate units that also process communication sessions. The primary receives all the sessions and load balances sessions for traffic passing through application proxies. May result in an active-active cluster having a higher throughput than active-passive. During an active-active HA load balancing operation when the primary unit receives the first packet of a UTM profile session the primary unit uses the configured load balancing schedule to determine the cluster unit that will process the session. The primary unit stores the load balancing information for each load balanced session in the cluster load balancing session table. The primary unit can the forward all of the remaining packets in each session to the appropriate cluster unit. The load balancing session table is synchronized among all cluster units. Active-active HA also provides device and link failover protections similar to active-passive. If the primary unit fails a subordinate unit becomes the primary unit and resumes operating the cluster. Active-active HA does not provide session failover for threat management profile sessions or UDP, ICMP, multicast and broadcast sessions: These are not failed over and must be restarted If a subordinate unit fails the primary unit redistributes all TCP communication sessions among the available subordinate units. Active-active HA can be a less robust session failover solution than active-passive HA. Primary unit processes traffic Primary unit load balances sessions with subordinates If primary fails, a subordinate immediately takes its place RTOL

Course 301 – Secured Network Deployment and IPSec VPN High Availability High Availability Modes of Operation Active-Active An active-active cluster balances communication session and provides failover protection In an active-active cluster, both the primary and subordinate units process traffic The primary unit load balances sessions If the primary unit fails, a subordinate will resume operations as the primary RTOL

FortiGate Clustering Protocol
Course 301 – Secured Network Deployment and IPSec VPN High Availability FortiGate Clustering Protocol FortiGate Clustering Protocol (FGCP) is used to discover other FortiGate units configured for high availability and to negotiate the creation of a cluster FGCP shares communication and synchronization information among cluster members Referred to as HA heartbeat The cluster uses FGCP to select the primary unit and provide device and link failover FortiGate Clustering Protocol (FGCP) is used to discover other FortiGate units configured for high availability and to negotiate the creation of a cluster. FGCP shares communication and synchronization information among cluster members. Referred to as HA heartbeat. The cluster uses FGCP to select the primary unit and provide device and link failover. On startup the cluster units use the FortiGate Clustering Protocol (FGCP) to find other FortiGate units configured for HA operation and to negotiate to create a cluster. During cluster operation FGCP is used to share communications and synchronize information among cluster members. The cluster uses FGCP to select the primary unit and to provide device and link failover. Click here to read more about FortiGate Clustering Protocol RTOL

High Availability Virtual MAC Addresses Original device Virtual MAC addresses assigned to each interface Failover device When a cluster is operating FGCP assigns a virtual MAC address to each primary unit interface If a failover occurs the new primary unit interface will have the same MAC address as the failed primary unit interfaces If the MAC address changed after a failover the network would take longer to recover because all attached network devices would have to learn the new MAC addresses before they could communicate with the cluster When a cluster starts up after a failover the primary unit sends gratuitous ARP packets to update the switches connected to the cluster interfaces with the virtual MAC address The switches update their MAC forwarding tables with the new MAC addresses As a result the switches direct all network traffic to the primary unit. Depending on the cluster configuration the primary unit either processes this network traffic itself or load balances the network traffic among all the cluster units The cluster virtual MAC addresses depend on the cluster group ID If there are more than one FortiGate cluster on the same network each cluster should have a different group ID If 2 clusters on the same network have the same group ID duplicate MAC addresses could cause addressing conflicts on the network Same virtual MAC addresses assigned to each interface RTOL

High Availability Virtual MAC Addresses Original device FGCP assigns virtual MAC addresses to each primary interface If a failover occurs, the new unit interfaces will have the same MAC addresses as the failed unit Allows the network to recover more quickly since attached network devices do not have to learn new MAC addresses before they can communicate with the cluster Virtual MAC addresses assigned to each interface Failover device Same virtual MAC addresses assigned to each interface RTOL

High Availability FGCP Heartbeat Cluster members The heartbeat keeps cluster units communicating with each other The heartbeat consists of Hello packets that are sent out at regular intervals by the heartbeat interface of all cluster units The hello packets describe the state of the cluster units including communication sessions that are being processed, and are used by other cluster units to keep all the units synchronized The default interval time between HA heartbeats is 200ms The heartbeat operates on TCP port 703 The FGCP also uses telnet administrative sessions on port 23 to communicate statistics, synchronize configuration and allow management connections between individual cluster units On startup a FortiGate unit configured for HA operations broadcasts FGCP heartbeat hello packets from its HA heartbeat interface to find other FortiGate units configured to operate in HA mode If 2 or more FortiGate units operating in HA mode connect with each other they compare HA configurations (HA mode, HA password and HA Group IDs). If they configurations match the units negotiate to form a cluster While the cluster is operating the heartbeat confirms that all cluster units are functioning normally Uses IP address not assigned to any FortiGate unit interface The primary unit heartbeat device IP address is Subordinate units are assigned heartbeat device IP addresses , , Both HA heartbeat and data traffic are supported on the same physical FortiGate unit interface but they are logically separated across 2 VDOMs All heartbeat communications take place on a VDOM called vsys_ha and traffic uses a virtual interface called port_ha in the vsys_ha VDOM RTOL

High Availability FGCP Heartbeat The FGCP heartbeat keeps cluster units communicating with each other Hello packets are sent at regular intervals by the heartbeat interface of all cluster units Describes the state of the units and keeps all unit synchronized Operates on TCP port 703 Default time interval between heartbeats is 200ms Cluster members RTOL

High Availability Heartbeat Interfaces For redundancy purposes, two interfaces should be assigned as heartbeat interfaces Default heartbeat interfaces depend on model The heartbeat interface with the highest priority is used for all HA heartbeat communications If two interface have same priority, interface highest in list used If communications are interrupted and the FortiGate device cannot failover to second heartbeat interface, the cluster stops processing traffic Multiple network interfaces can be configured to be heartbeat interfaces All FortiGate models have 2 interfaces configured to be heartbeat interfaces which can be changed as required The defaults used for these interfaces will depend on the model The heartbeat interface with the highest priority is used for all HA heartbeat communications If the interface fails or becomes disconnected the selected heartbeat interface that has the next highest priority handles all heartbeat communications If two interface have the same priority the interface highest in the list is used If heartbeat communication is interrupted and cannot failover to the second heartbeat interface, the cluster stops processing traffic Heartbeat packets may use a considerable amount of network bandwidth It is preferable to isolate this traffic from user networks since it can reduce the capacity of a FortiGate unit interface to process network traffic Default heartbeat interfaces of all cluster units can be isolated by connecting them all to the same switch If the cluster consists of 2 units the heartbeat interfaces can be connected together using cross-over cables RTOL

Heartbeat Interface IP Addresses
Course 301 – Secured Network Deployment and IPSec VPN High Availability Heartbeat Interface IP Addresses Cluster assigns virtual IP to interfaces processing traffic Primary: Subordinates: , and If both units boot up and join cluster at the same time, FGCP will assign to the FortiGate unit with the highest serial number IP addresses do not need to be assigned to heartbeat interfaces Cluster assigns virtual IP to interfaces processing traffic Primary: Subordinates: , etc Isolate heartbeat traffic from user networks Uses considerable bandwidth Isolate using switch or connecting heartbeat interfaces using crossover cable RTOL

Heartbeat Interface IP Addresses
Course 301 – Secured Network Deployment and IPSec VPN High Availability Heartbeat Interface IP Addresses Sample output for master with IP address of : diag sys ha status HA information Statistics traffic.local = s:20871 p:78602 b: traffic.total = s:20980 p:78602 b: activity.fdb = c:0 q:0 Model=50, Mode=2 Group=12 Debug=0 nvcluster=1, ses_pickup=0 HA group member information: is_manage_master=1. FG50BH3G , 1. Master:128 FG50BH3G FG50BH3G , 0. Slave:128 FG50BH3G vcluster 1, state=work, master_ip= , master_id=0: FG50BH3G , 0. Master:128 FG50BH3G (prio=0, rev=0) FG50BH3G , 1. Slave:128 FG50BH3G (prio=1, rev=1) RTOL

HA Configuration Synchronization
Course 301 – Secured Network Deployment and IPSec VPN High Availability HA Configuration Synchronization Incremental synchronization The change is synchronized on the subordinate unit A configuration change is made on primary unit Subordinate unit Primary unit Config FGCP uses a combination of incremental and periodic synchronization to make sure that the configurations of all cluster units are synchronized. Incremental synchronizations: Configuration changes are first made to the primary then changes are immediately synchronized to subordinates. Also synchronizes other dynamic configuration information such as DHCP server address lease database, routing table updates etc. When a change is made to the cluster unit configuration incremental synchronization sends the same configuration change to all other cluster units over the HA heartbeat link. Synchronization takes place silently. No log message recorded unless level set to Information. Config RTOL

Course 301 – Secured Network Deployment and IPSec VPN High Availability HA Configuration Synchronization Incremental synchronization This change is synchronized on the subordinate unit Another configuration change is made on primary unit Subordinate unit Primary unit RTOL

Course 301 – Secured Network Deployment and IPSec VPN High Availability HA Configuration Synchronization Incremental synchronization This change is synchronized on the subordinate unit The change is synchronized on the subordinate unit FGCP uses synchronization to ensure that the configurations of all cluster units are identical With incremental synchronization, changes made to the primary unit are immediately made to the subordinate Includes dynamic information such as DHCP leases, routing table updates etc Synchronization is silent No log message unless level is set to Information Another configuration change is made on primary unit Subordinate unit Primary unit Config Config RTOL

Course 301 – Secured Network Deployment and IPSec VPN High Availability HA Configuration Synchronization Periodic synchronization The change is synchronized on the subordinate unit Checksum values are compared on cluster members A configuration change is made on primary unit Subordinate unit Primary unit Config Checksum Checksum Periodic synchronization is a mechanism that looks for synchronization problems and fixes them Every minute the cluster compares the configuration file checksum of the primary unit with the configuration file checksum of each subordinate unit If the subordinate unit checksum values are the same as the primary unit checksum all cluster units are considered synchronized If there is no match after five attempts the subordinate retrieves configuration information from the primary and the subordinate unit resumes operation with the same configuration as the primary Config Checksum Checksum RTOL

Course 301 – Secured Network Deployment and IPSec VPN High Availability HA Configuration Synchronization Periodic synchronization This change is synchronized on the subordinate unit Checksum values are compared on cluster members Another configuration change is made on primary unit Subordinate unit Primary unit Checksum Checksum Checksum Checksum RTOL

Course 301 – Secured Network Deployment and IPSec VPN High Availability HA Configuration Synchronization Periodic synchronization The change is synchronized on the subordinate unit Period synchronization is a mechanism that looks for and fixes synchronization problems The checksum value of the configuration file on each cluster member is compared If checksum values match, cluster units are consider synchronized If there is not a match, the subordinate will retrieve the configuration from the primary Another configuration change is made on primary unit Subordinate unit Primary unit Config Checksum Checksum Checksum Config Checksum Checksum Checksum RTOL

High Availability Load Balancing dstMAC , srcMAC X, TCP ACK dport 80 dstMAC 0b-a4-8c, srcMAC 0b-a1-c0, TCP ACK dport 80 dstMAC , srcMAC Y, TCP SYN ACK sport 80 dstMAC 0b-a4-8e, srcMAC 0b-a1-c2, TCP SYN ACK sport 80 dstMAC Y, srcMAC 0b-a4-8e, TCP ACK dport 80 The above diagram applies to NAT/Route mode. In Transparent mode, the source and destination MAC addresses will be X and Y and not the cluster Virtual MAC addresses. As the master device is the only device forwarding layer 2 broadcast traffic in transparent mode, the MAC address Y will be associated with the switch port connected to the master unit. In order to communicate destination MAC address information to the slave units, the packet 2 is not redirected but encapsulated in an Ethernet frame, Ethernet type 8891, and sent to the slave. 1. dstMAC , srcMAC X, TCP ACK dport 80 2. dstMAC 0b-a4-8c, srcMAC 0b-a1-c0, TCP ACK dport 80 3. dstMAC , srcMAC Y, TCP SYN ACK sport 80 4. dstMAC 0b-a4-8e, srcMAC 0b-a1-c2, TCP SYN ACK sport 80 5. dstMAC Y, srcMAC 0b-a4-8e, TCP ACK dport 80 Click here to read more about FortiGate HA load balancing RTOL

Load Balancing dstMAC 09-01-01, srcMAC X, TCP ACK dport 80
dstMAC 0b-a4-8c, srcMAC 0b-a1-c0, TCP ACK dport 80 dstMAC , srcMAC Y, TCP SYN ACK sport 80 dstMAC 0b-a4-8e, srcMAC 0b-a1-c2, TCP SYN ACK sport 80 dstMAC Y, srcMAC 0b-a4-8e, TCP ACK dport 80 Click here to read more about FortiGate HA load balancing

Load Balancing Master Session Table
Course 301 – Secured Network Deployment and IPSec VPN High Availability Load Balancing Master Session Table session info: proto=6 proto_state=11 expire=3599 timeout=3600 flags= av_idx=4 use=5 bandwidth=0/sec guaranteed_bandwidth=0/sec traffic=0/sec prio=0 logtype=session ha_id=0 hakey=49729 tunnel=/ state=redir log local may_dirty statistic(bytes/packets/err): org=1253/21/0 reply=1503/19/0 tuples=3 orgin->sink: org pre->post, reply pre->post oif=3/5 gwy= / hook=post dir=org act=snat :2287-> :21( :2287) hook=pre dir=reply act=dnat :21-> :2287( :2287) hook=post dir=reply act=noop :21-> :2287( :0) pos/(before,after) /(0,8), 0/(0,0) misc=20004 domain_info=0 auth_info=0 ftgd_info=0 ids=0x0 vd=0 serial=00005ae5 tos=ff/ff session info: proto=6 proto_state=11 expire=3595 timeout=3600 flags= av_idx=4 use=6 bandwidth=0/sec guaranteed_bandwidth=0/sec traffic=0/sec prio=0 logtype=session ha_id=1 hakey=49729 state=redir log may_dirty statistic(bytes/packets/err): org=999/21/0 reply=1921/19/0 tuples=3 hook=post dir=org act=snat :2291-> :21( :2291) hook=pre dir=reply act=dnat :21-> :2291( :2291) hook=post dir=reply act=noop :21-> :2291( :0) pos/(before,after) /(8,16), 0/(0,0) misc=20004 domain_info=0 auth_info=0 ftgd_info=0 ids=0x0 vd=0 serial=00005b07 tos=ff/ff Cluster ID of device handing session AV scan enabled for FTP RTOL

High Availability Failover FGCP provides transparent device and link failover Can be caused by hardware failure, software failure, or even a network cable disconnected When failover occurs, cluster detects and takes steps so network can operate without interruption Internal operation of cluster changes Components outside of cluster notice little or no change Cluster records log messages Also send SNMP trap or alert Session failover means that a cluster maintains active networks sessions after device or link failover. FortiGate HA does not support session failover by default. To enable session failover the HA configuration must be changed to select Enable Session Pick-up FGCP maintains a session table for most communication sessions being process by the cluster If a cluster unit fails this session table information is available to the remaining cluster units and these units resume the sessions that were being processed by the failed cluster unit without interruption Active-passive clusters provide session failover for TCP, UDP, ICMP, multicast and broadcast sessions Active-active clusters provide session failover for TCP sessions only Session failover is supported for all IPSec VPN tunnels however session failover is not supported for SSL VPN tunnels Cookie failover is supported for the communications between the SSL VPN client and the FortiGate unit so after failover an SSL VPN session can be established without the user having to authenticate again All sessions inside the SSL VPN tunnel that were running before the failover are stopped and must be restarted Click here to read more about FortiGate HA failover RTOL

High Availability Device Failover If the FortiGate device fails, another device automatically takes its place Does not maintain communication sessions Session must be restarted HA can be configured to support session failover Subordinate units sends heartbeat packets to detect primary failure If a failure is detected, a subordinate unit will assume the primary role New primary unit has same network identity as failed primary unit Configuration synchronization insures that new primary unit has same configuration as the failed primary unit If the FortiGate device fails, another device automatically takes its place. Does not maintain communication sessions: Session must be restarted. HA can be configured to support session failover. Subordinate units sends heartbeat packets to detect primary failure: If a failure is detected, a subordinate unit will assume the primary role. New primary unit has same network identity as failed primary unit. Configuration synchronization insures that new primary unit has same configuration as the failed primary unit. RTOL

High Availability Link Failover If a monitored interface fails, the cluster reorganizes to reestablish link to the network Continue operation with minimal or no disruption The cluster monitors each unit to determine if the monitored interfaces are operating and connected Each cluster unit stores link state information for all monitored units in link state database If a monitored interface fails, the cluster reorganizes to reestablish link to the network. Continue operation with minimal or no disruption. The cluster monitors each unit to determine if the monitored interfaces are operating and connected. Each cluster unit stores link state information for all monitored units in link state database. RTOL

High Availability Session Failover Cluster maintains active networks sessions after device or link failover Must enable session pick-up Only sessions not being handled by a proxy can failover FGCP maintains a session table for most communication sessions being process by cluster Information available to cluster members to resume sessions being processed by failed unit Cluster maintains active networks sessions after device or link failover: Must enable session pick-up. Only sessions not being handled by a proxy can failover. FGCP maintains a session table for most communication sessions being process by cluster. Information available to cluster members to resume sessions being processed by failed unit. RTOL

Session Synchronization
Course 301 – Secured Network Deployment and IPSec VPN High Availability Session Synchronization Secondary FortiGate unit Sync management Relies on external networking device for traffic redirection Primary FortiGate unit FortiGate session synchronization provides an alternative to an active-passive HA configuration allowing per-VDOM session synchronization. Session synchronization requires two FortiGate units in standalone mode Both units will handle traffic This type of HA configuration will help reduce some of the complexity of HA by relying on network devices such as routers or load balancers for traffic redirection Only TCP sessions are synchronized using this feature Only for firewall traffic without threat management profiles The configuration on the two FortiGate units must match FortiManager can be used to apply configuration changes to both primary and secondary units in the configuration Click here to read more about FortiGate HA session synchronization RTOL

Session Synchronization
Course 301 – Secured Network Deployment and IPSec VPN High Availability Session Synchronization Secondary FortiGate unit This mechanism provides an alternative to an active-passive HA configuration for session synchronization Two units operating in standalone mode Configurations synched between the two units An external networking device (router or load-balancer) is responsible for traffic redirection Sync management Relies on external networking device for traffic redirection Primary FortiGate unit Click here to read more about FortiGate HA session synchronization RTOL

Configuring Session Synchronization
Course 301 – Secured Network Deployment and IPSec VPN High Availability Configuring Session Synchronization On primary FortiGate unit: config global config system interface edit "port2" set vdom "root" set ip set allowaccess ping set type physical next .../... config system session-sync edit 1 set peerip set peervd "root" set syncvd "VDT1" end On primary FortiGate unit: config global config system interface edit "port2" set vdom "root" set ip set allowaccess ping set type physical next .../... config system session-sync edit 1 set peerip set peervd "root" set syncvd "VDT1" end RTOL

Configuring Session Synchronization
Course 301 – Secured Network Deployment and IPSec VPN High Availability Configuring Session Synchronization On secondary FortiGate unit: config global config system interface edit "port2" set vdom "root" set ip set allowaccess ping set type physical next .../... config system session-sync edit 1 set peerip set peervd "root" set syncvd "VDT1" end On secondary FortiGate unit: config global config system interface edit "port2" set vdom "root" set ip set allowaccess ping set type physical next .../... config system session-sync edit 1 set peerip set peervd "root" set syncvd "VDT1" end RTOL

High Availability Virtual Clustering Active-passive HA Domain A Domain B Domain C Domain A Domain D Domain E Primary Subordinate Virtual clustering is used for FortiGate units operating with virtual domains It operates in active-passive mode to provide failover between two instances of a virtual domain operating on two different cluster units Virtual clustering only operates on two FortiGate units with virtual domains enabled. Each virtual domain creates its own cluster. One cluster unit is the primary unit for each virtual domain and the other cluster unit is the subordinate unit for each virtual domain. The primary unit processes all traffic for the virtual domain Click here to read more about FortiGate HA virtual clustering RTOL

High Availability Virtual Clustering Active-passive HA Virtual clustering provides failover between two instances of virtual domains operating on two different cluster units Operates in active-passive mode Can also be configured to provide load balancing The primary unit processes all traffic for the virtual domain Domain A Domain B Domain C Domain A Domain D Domain E Primary Subordinate Click here to read more about FortiGate HA virtual clustering RTOL

High Availability Upgrades Upgrading or downgrading cluster firmware is similar to upgrading or downgrading a standalone FortiGate firmware. The firmware is uploaded once to the primary unit and the cluster automatically upgrades or downgrades all cluster units in one operation with minimal or no service interruption The firmware upgrade takes place without interrupting communication through the cluster RTOL

High Availability Upgrades To upgrade the firmware without interrupting communication through the cluster: The administrator uploads a new firmware image from Web Config or CLI If the cluster is operating in active-active mode, load balancing is turned off The cluster upgrades the firmware running on all of the subordinate units Once the subordinate units have been upgraded, a new primary unit is selected. This primary unit will be running the new upgraded firmware. The cluster now upgrades the firmware of the former primary unit. RTOL

High Availability Full Mesh HA Full mesh HA is a method of reducing the number of single points of failure on a network that includes an HA cluster On FortiGate model 310B or higher Full mesh HA uses 802.3ad aggregate or redundant interfaces to create full mesh cluster configuration The resulting full mesh HA configuration includes redundant connections between all network components RTOL

High Availability Full Mesh HA Full mesh HA is a method of reducing the number of single points of failure on a network that includes an HA cluster Available on certain FortiGate models Uses aggregate and redundant interfaces to include redundant connections between all network components RTOL

High Availability Lab Topology
Course 301 – Secured Network Deployment and IPSec VPN High Availability High Availability Lab Topology RTOL

Labs Lab – High Availability Configuring the Student FortiGate device as the Master Configuring the Remote FortiGate device as the Slave Verifying HA synchronization and failover Click here for step-by-step instructions on completing this lab RTOL

High Availability Student Resources Click here to view the list of resources used in this module RTOL

Course 301 – Secured Network Deployment and IPSec VPN

Similar presentations

Presentation on theme: "Course 301 – Secured Network Deployment and IPSec VPN"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Course 301 – Secured Network Deployment and IPSec VPN

Similar presentations

Presentation on theme: "Course 301 – Secured Network Deployment and IPSec VPN"— Presentation transcript:

Similar presentations

About project

Feedback