SD-WAN 6.2 Study Guide-Online

DO NOT REPRINT
© FORTINET
SD-WAN Study Guide

for FortiOS 6.2
DO NOT REPRINT
© FORTINET
Fortinet Training
http://www.fortinet.com/training
Fortinet Document Library
http://docs.fortinet.com
Fortinet Knowledge Base
http://kb.fortinet.com
Fortinet Forums
https://forum.fortinet.com
Fortinet Support
https://support.fortinet.com
FortiGuard Labs
http://www.fortiguard.com
Fortinet Network Security Expert Program (NSE)

https://www.fortinet.com/support-and-training/training/network-security-expert-program.html
Feedback
Email: courseware@fortinet.com
11/5/2019
DO NOT REPRINT
© FORTINET
TABLE OF CONTENTS
01 Introduction 4
02 Routing, Sessions, and Performance SLA 29
03 SD-WAN Rules 62
04 Traffic Shaping 95
05 Integration 126
06 Advanced IPsec 154
07 Autodiscovery VPN 180
Solution Slides 209
Introduction
DO NOT REPRINT
© FORTINET
In this lesson, you will learn about SD-WAN.
SD-WAN 6.2 Study Guide 4

Introduction
DO NOT REPRINT
© FORTINET
After completing this section, you should be able to to achieve the objectives shown on this slide.
By demonstrating competence in SD-WAN, you should be able to configure the SD-WAN virtual link and
traffic load balancing to use multiple WAN links effectively on FortiGate.

Introduction
DO NOT REPRINT
© FORTINET
To understand SD-WAN, we will take an example of a road trip.
Everyone loves a good road trip, enjoying relaxed, transit-free travel.

Introduction
DO NOT REPRINT
© FORTINET
But no one likes congestion or bad road quality.

Introduction
DO NOT REPRINT
© FORTINET
In the old days, you had to resort to paper maps; but they really don’t solve most of the aforementioned
problems.
Now we live in an age of information, and all of that is in the past because of the power of technology. With
the help of technology, you can even avoid these kind of issues entirely.

Introduction
DO NOT REPRINT
© FORTINET
SD-WAN is a way to solve very similar issues, but on a network, for instance a saturated Internet link. Or, the
link may not be saturated, but could have a series of impairments like packet loss or high latency. You also
need to plan for complete link failure.

Introduction
DO NOT REPRINT
© FORTINET
In technical terms, SD-WAN is a virtual interface consisting of a group of member interfaces that can be
connected to different link types. FortiGate groups all the physical member interfaces into a single virtual
interface: the SD-WAN interface. Using SD-WAN simplifies configuration, because the administrator can
configure a single set of routes and firewall policies and apply them to all member interfaces. There can be
only one SD-WAN interface per VDOM.
One of the main motivators for deploying SD-WAN is effective WAN use, when you are using multiple WAN
links. Effective WAN use is achieved using various load balancing algorithms, such as bandwidth usage,
sessions, or application-aware routing. Another important feature of SD-WAN is link quality measurements.
Using ping or HTTP echo, FortiGate can determine the latency, jitter, or packet loss percentage for each link,
and dynamically select links based on these measurements. This ensures high availability (HA) for business-
critical applications.

Introduction
DO NOT REPRINT
© FORTINET
FortiGate offers a secure SD-WAN solution that includes reliable SD-WAN routing with next-generation
firewall security and QoS.

Introduction
DO NOT REPRINT
© FORTINET
FotiGate offers advanced SD-WAN features, such as application-aware routing, multipath intelligence,
multibroadband support, simplified monitoring, and security.

Introduction
DO NOT REPRINT
© FORTINET
SD-WAN offers features to route and control the performance of specific applications using rules and
performance SLAs.

Introduction
DO NOT REPRINT
© FORTINET
You can now specify a performance SLA for specific rules to provide priorities to application-specific traffic.

Introduction
DO NOT REPRINT
© FORTINET
Fortinet’s SD-WAN SOC4 ASIC is designed to provide the highest quality experience for business critical
applications, enabling and accelerating SD-WAN, advanced routing, and security to achieve the highest
quality experience possible, without any performance and security concerns.
This custom-designed silicon chip delivers the fastest application identification and steering in the industry,
while providing connectivity and advanced security capabilities 10 times faster than the competition.

Introduction
DO NOT REPRINT
© FORTINET
Now, you will learn about SD-WAN use cases. In the example shown on this slide, the customer depends
heavily on expensive, inflexible MPLS. All the traffic is routed through the MPLS circuit to the provider cloud,
then to the public cloud or Internet, based on the applications. There is no flexibility in this scenario, and yet it
is an expensive solution for the customer. How can the customer add redundancy, flexibility, reliability, and
most importantly, security, without adding costly infrastructure? You will learn about the solution in this lesson.

Introduction
DO NOT REPRINT
© FORTINET
In the example shown on this slide, the customer would like to keep MPLS for business critical applications
while adding flexibility and redundancy. MPLS is being used to send business-critical traffic (for example,
voice and video) based on the best path with less delay, jitter, or packet loss. In case the current path
degrades below the policy threshold, business-critical traffic will be rerouted to a new tunnel. Also, non-critical
traffic is load balanced across different lines to maximize bandwidth or minimize cost. At the same time, the
branch can have direct secure access to the Internet, which improves the cloud application performance, and
can load balance SaaS and IaaS content if needed.

Introduction
DO NOT REPRINT
© FORTINET
In the example shown on this slide, costly MPLS is replaced by two Internet VPN tunnels, yet gains robust
resiliency and redundancy. By replacing MPLS, the customer can minimize cost while maximizing quality. The
SD-WAN solution is a network-application-aware solution that dynamically selects the best WAN to maintain
higher SLA.

Introduction
DO NOT REPRINT
© FORTINET
When you configure SD-WAN, you must specify at least two member interfaces and their associated
gateways. You should configure SD-WAN early, during the initial setup of FortiGate because, if an interface is
already referenced by a firewall policy or static route, you cannot use it as a member interface. If you intend to
use an interface as an SD-WAN member, and that interface is being referenced by a firewall policy or static
route, you must delete the associated firewall policy and static route before you can assign that interface as
an SD-WAN member. SD-WAN supports physical interfaces as well as VLAN, aggregate, and IPsec
interfaces.
You can also easily add another member interface at a later date, to add more bandwidth or QoS options.
FortiGate groups all the member interfaces into a single virtual interface: the SD-WAN interface. Using SD-
WAN simplifies configuration because the administrator can configure a single set of routes and firewall
policies and apply them to all member interfaces. There can be only one SD-WAN interface per VDOM.
An implicit rule is automatically generated when you enable SD-WAN. If none of the conditions for any of the
other rules are met, then the implicit rule will be used. This implicit rule is simply designed to balance the
traffic among all the available SD-WAN member links. You will learn about SD-WAN rules later in this lesson.

Introduction
DO NOT REPRINT
© FORTINET
SD-WAN load balancing uses traffic distribution methods that are similar to those used by equal cost
multipath (ECMP). However, SD-WAN link load balancing includes one more balancing method: volume.
By default, the load-balance-mode is set to source-ip-based. However, you can change the load balancing
mode to any of the following:
• Source IP (source-ip-based):
o All traffic from a source IP is sent to the same interface.
• Weight (weight-based):
o Interfaces with higher weights have higher priority and get more traffic.
• Spillover (usage-based):
o All traffic is sent to the first interface on the list. When the bandwidth on that interface exceeds the
spillover limit, new traffic is sent to the next interface.
• Source-destination IP (source-dest-ip-based):
o Source and destination IP load balancing. All traffic from a source IP to a destination IP is sent to
the same interface.
• Volume (measured-volume-based):
o Volume-based load balancing. Sessions are load balanced based on traffic volume (in bytes).
More traffic is sent to interfaces with higher volume ratios.

Introduction
DO NOT REPRINT
© FORTINET
Using session-based and volume-based load balancing, you can customize traffic distribution with the
interface weight you configure for each SD-WAN members. This weight applies only to SD-WAN static routing
and will be used for dynamic routing. Using these load balancing methods, the traffic is being load balanced
based on session.
In a session-based load balancing algorithm, weighted distribution is based on the number of sessions on
each SD-WAN member.
In a volume-based load balancing algorithm, weighted distribution is based on the cumulative number of bytes
sent across each SD-WAN member.

Introduction
DO NOT REPRINT
© FORTINET
Using this load balancing algorithm, traffic will be load balanced based on the maximum usable bandwidth
defined. Once the configured limit is reached, another interface is chosen to send the traffic out.

Introduction
DO NOT REPRINT
© FORTINET
After you have enabled SD-WAN, and configured the member interfaces and the load balancing method, a
logical interface with the name SD-WAN is automatically added to the interface list. Next, you must create the
routes and firewall policies using this virtual interface.
You must still configure a default route when implementing SD-WAN. The default route configuration using the
SD-WAN interface does not require a gateway address because FortiGate will forward packets to the
appropriate gateway, based on the member interface gateway information.
When using SD-WAN, you do not need to configure multiple firewall policies for individual member interfaces.
Firewall policies created with the SD-WAN interface allow traffic to be forwarded through any member
interface.

Introduction
DO NOT REPRINT
© FORTINET
Even though you must configure routes using the SD-WAN virtual interface, FortiGate installs individual
routes for the member interfaces in the routing table. These routes share the same attributes (destination
address and subnet, distance, and priority) and are both active. This allows FortiGate to remove individual
routes in the event of an interface outage, and redirect all traffic to the remaining member interfaces, without
affecting the whole SD-WAN load balancing group.

Introduction
DO NOT REPRINT
© FORTINET
SD-WAN rules function as policy routes. Policy routes will take precedence over any other routes in the
routing table. When it comes to policy routing, FortiGate will first check regular policy routes before coming to
SD-WAN policy routes.

Introduction
DO NOT REPRINT
© FORTINET
SD-WAN rules are evaluated in the same way as the firewall policies: from top to bottom, using the first
match.
An implicit rule is automatically generated when you enable SD-WAN. If none of the conditions of any of the
other rules are met, then the implicit rule will be used. This implicit rule is designed to balance the traffic
among all the available SD-WAN member links.
Double-clicking the implicit rule will display the load balancing options.

Introduction
DO NOT REPRINT
© FORTINET
The link health monitor is a mechanism for detecting when a router along the path is stopped or degraded.
FortiGate can check the status (or health) of each SD-WAN member interface participating in a performance
SLA, by periodically sending probing signals through each member link to a server that acts as a beacon. You
can specify up to two servers to act as your beacons. This is to guard against the server being at fault, and not
the link.

Introduction
DO NOT REPRINT
© FORTINET
This slide shows the objectives that you covered in this lesson.
By mastering the objectives covered in this lesson, you learned how to configure the SD-WAN virtual link and
traffic load balancing to use multiple WAN links effectively on FortiGate.

Routing, Sessions, and Performance SLA
DO NOT REPRINT
© FORTINET
In this lesson, you will learn about routing, sessions, and performance SLA.

DO NOT REPRINT
© FORTINET
After completing this section, you should be able to achieve the objectives shown on this slide.
By demonstrating competence in routing, you will be able to understand the routing fundamentals.

DO NOT REPRINT
© FORTINET
A FortiGate is a stateful device, so it decodes a lot of information at the beginning of a session, based
on the first packets. For any traffic session, FortiGate usually performs only two routing lookups: one
on the first packet sent by the originator and another one on the first reply packet coming from the
responder. After that, all the routing information is written in the FortiGate session table. However, after
a change to the routing table, the route information is flushed from the affected entries in the session
table. So, FortiGate would perform additional routing table lookups in order to repopulate the session
table with the new routing information.

DO NOT REPRINT
© FORTINET
How does FortiGate decide routes? FortiGate has multiple routing modules. This slide shows the logic
of the routing modules.
First, FortiGate searches its policy routes. You can view them using the command diagnose
firewall proute list. If there is a match in a policy route, and the action is Forward Traffic,
FortiGate routes the packet accordingly. If the action is Stop Policy Routing, FortiGate goes to
the next table, which is the route cache. You can view that content using the CLI command diagnose
ip rtcache list.
Finally, FortiGate searches the forwarding information base (FIB). The FIB is generated by the routing
process, and is the table used for packet forwarding. Think of the routing table’s purpose as
management, while the FIB’s purpose is forwarding. This separation becomes clearer in FortiGate an
active-active high availability (HA) cluster. In an HA cluster, both route management and forwarding
tables exist on the primary FortiGate. But on the secondary FortiGate, only the FIB exists.
If there’s no match in any of those tables, FortiGate drops the packet because it is unroutable.

DO NOT REPRINT
© FORTINET
When there is more than one route to a destination, this is the process for selecting which route to use.
First, FortiGate uses the most specific route, which is the one with the longest netmask (smallest
subnet). If there are two or more routes with the same longest netmask, the unit selects the one with
the shortest distance. After that, the lowest metric is used as the tiebreaker for dynamic routes. In the
case of static routes, the priority is used instead. If there are multiple routes with the same netmask,
distance, metric, and priority, FortiGate shares the traffic among all of them. This is called equal cost
multipath (ECMP). ECMP is supported for static, BGP, and OSPF routes.

DO NOT REPRINT
© FORTINET
By demonstrating competence in understanding session table, you will be able to understand the
session table on FortiGate.

DO NOT REPRINT
© FORTINET
The FortiGate session table contains detailed information about every IP connection that crosses or
terminates at FortiGate. The command get system session status displays the total number of
sessions in the active VDOM. The command get system session list provides a brief summary
of each session. This command lists one session on each line, and includes information such as
protocol, source IP address, destination IP address, and port. You can use the grep utility with this
command to list only the sessions for a specific IP address.

DO NOT REPRINT
© FORTINET
This slide shows a sample of the output contained in the FortiGate session table. From left to right, and
from top to bottom, the following information is highlighted:
• The IP protocol number and the protocol state
• The length of time until the session expires (if there is no more traffic)
• Traffic shaping counters
• Session flags
• Received and transmitted packet and byte counters
• If the unit is doing NAT, this portion shows the type of NAT (source or destination) for each traffic
direction, and the NAT IP address
• The source MAC address of the packet
• The ID number of the matching policy
• Counters for hardware acceleration

DO NOT REPRINT
© FORTINET
The protocol state in the session table is a two-digit number. For TCP, the first number (from left to
right) is related to the server-side state and is 0 when the session is not subject to any inspection (flow
or proxy). If flow or proxy inspection is done, then the first digit will be different from 0. The second digit
is the client-side state. This table and flow graph correlate the second-digit value with the different TCP
session states. For example, when FortiGate receives the SYN packet, the second digit is 2. It
changes to 3 when the SYN/ACK packet is received. After the three-way handshake, the state value
changes to 1.
When a session is closed by both sides, FortiGate keeps that session in the session table for a few
seconds more, to allow for any out-of-order packets that might arrive after the FIN/ACK packet. This is
the state value 5.

DO NOT REPRINT
© FORTINET
For UDP, the session state can only have two values: 00 when traffic is only one way, and 01 when
there is traffic two ways. For ICMP, the protocol state is always 00.

DO NOT REPRINT
© FORTINET
This table shows the meaning of the most important session flags. For example, the log flag indicates
that the session is being logged. The local flag indicates that the session originated from FortiGate or
terminates in FortiGate.

DO NOT REPRINT
© FORTINET
Take a look at the dirty and may_dirty flags. When FortiGate receives the first packet for a new
session, it evaluates whether the traffic should or shouldn’t be allowed, based on firewall policies. As
long as there are no changes in the firewall policy configuration, this evaluation is done on only the first
session packet. If the traffic is allowed by a firewall policy, FortiGate creates a session and flags the
session as may_dirty.
After that, if there is a change in the firewall policy configuration, all the existing sessions with the
may_dirty flag are also flagged as dirty. This indicates to FortiGate that it needs to re-evaluate
the next session packet to determine if the session must be blocked. If the session is still allowed, the
dirty flag is removed, but the may_dirty flag is kept. If the session must be blocked, it is flagged as
block and remains in the session table until it expires. Any packet matching a session with the block
flag is dropped.

DO NOT REPRINT
© FORTINET
You can use the CLI commands shown on this slide to modify FortiGate’s session handling behaviour
after policy changes.
The system-level setting is global, or per-VDOM, if you have VDOMs enabled. The default option is
check-all, where all policy information is removed from sessions affected by a policy change. When
new packets arrive, FortiGate re-evaluates them before adding them to the session table. This is the
most resource-intensive behavior.
The check-new option is another alternative. When this option is enabled, FortiGate does not modify
any existing session after a policy change. When new sessions arrive, FortiGate evaluates them
against the modified policies. You can use this option if you have policies handling millions of sessions.
The check-policy-option is the most granular setting you can use. When you enable this option,
the firewall policy-level settings become available, which you can use to modify how FortiGate handles
sessions on a per-policy level.

DO NOT REPRINT
© FORTINET
After completing this section, you should be able to achieve the objective shown on this slide.
By demonstrating competence in routing changes, you will be able to session behaviour at the time of
the routing changes on FortiGate.

DO NOT REPRINT
© FORTINET
When FortiGate is not applying SNAT, after a change in the routing table, the routing information is
removed from the sessions that are affected by the change. Additionally, related route cache entries
are deleted. So, two more routing lookups are done for the next packets, in order to learn the new
routing information, and store it in the routing table.
This slide shows a sample of a session just after a routing change. The gateways in both directions
change to 0.0.0.0/0 and the interfaces to 0, indicating that this information must be learned again.
Additionally, the dirty flag is added.

DO NOT REPRINT
© FORTINET
You can configure session route persistence at the interface level using the commands shown on this
slide. The default value is disable. If you enable this setting, sessions passing through that interface
will continue to pass without being affected by the routing changes. The routing changes will apply only
to new sessions.

DO NOT REPRINT
© FORTINET
In sessions where SNAT is applied, the action that FortiGate takes after a routing change depends on
the snat-route-change setting.

DO NOT REPRINT
© FORTINET
When the snat-route-change setting is disabled, the behavior that occurs after a routing change is
different for sessions using SNAT. Sessions using SNAT keep using the same outbound interface, as
long as the old route is still active.
In the example shown on this slide, FortiGate is connected to two different ISPs. A client with the IP
address 10.1.0.1/24 is connected behind a FortiGate device. FortiGate is doing SNAT of the client
traffic to a public IP address, depending on which ISP is using it. The FortiGate routing table contains
two default routes: one for each ISP. The two default routes are the same distance, but have different
priorities. The route with the lowest priority (port1) is the primary. When both ISP connections are up,
the primary route is selected by FortiGate for Internet traffic. So, all sessions to the Internet are created
using port1 as the outbound interface.

DO NOT REPRINT
© FORTINET
If you increase the priority assigned to port1 to a value that is higher than the value assigned to port2,
and if snat-route-change is disabled, all new sessions start using port2, because it has the lowest
priority. However, all the existing sessions continue to use port1. The default route is through port1.
Even though the default route is no longer the best route, it is still active. If FortiGate is doing SNAT,
the existing sessions will continue to use the original route until they expire. If FortiGate isn’t doing
SNAT, all the existing sessions will switch to port2 after the change.

DO NOT REPRINT
© FORTINET
When snat-route-change is enabled, after a routing change, the actions are the same as they are
for sessions without SNAT:
• Routing information is flushed from the session table

• Route cache entries are removed
• Routing lookups are done again for the next packets, which can potentially change the outbound
interface being used to route the traffic
• RPF check is done again for the first packet in the original direction
In the example shown on this slide, FortiGate is connected to two different ISPs. A client with the IP
address 10.1.0.1/24 is connected behind a FortiGate device. The FortiGate routing table contains
two default routes: one for each ISP. The two default routes are the same distance, but have different
priorities. The route with the lowest priority (port1) is the primary. When both ISP connections are up,
the primary route is selected by FortiGate for Internet traffic. So, all sessions to the Internet are created
using port1 as the outbound interface.

DO NOT REPRINT
© FORTINET
The scenario shown on this slide has multiple ISPs. If the customer owns a pool of public IP
addresses, the customer can configure a single IP pool for SNAT for all the Internet providers. The
advantage is that if the main ISP goes down, sessions are routed through a secondary ISP,
maintaining the same public source IP address. In this way, sessions can remain up.
So, in the example shown in this slide, if you increase the priority for port1 to a value higher than the
priority for port2, and if snat-route-change is enabled, after a routing change, routing information
is flushed from existing SNAT sessions. All sessions start using port2, because it has the lowest
priority. Additionally, if the port2 route shared a common IP pool with the old best route of port1, the
SNAT sessions will keep using the same public IP addresses for the translation of the private IP
addresses.

DO NOT REPRINT
© FORTINET
By demonstrating competence in the SD-WAN performance SLA, you should be able to configure the
SD-WAN performance SLA, and identify how FortiGate measures link quality.

DO NOT REPRINT
© FORTINET
Now, you will learn about the two parts that make up the Performance SLA window: the link health
monitor (or status check), and SLA Targets.

DO NOT REPRINT
© FORTINET
Sequence numbers are assigned based on the order of the members added to the SD-WAN
configuration. These sequence numbers are referenced in all the diagnostics outputs.
For example, as shown on the slide, port1 and port2 are the two SD-WAN members configured.
port1 was added first and is assigned sequence number 1. In the diagnostic output shown on the
slide, seq(1) refers to port1 and seq(2) refers to port2.

DO NOT REPRINT
© FORTINET
The link health monitor is a mechanism for detecting when a router along the path is stopped or
degraded.
FortiGate can check the status (or health) of each SD-WAN member interface participating in a
performance SLA, by periodically sending probing signals through each member link to a server that
acts as a beacon. You can specify up to two servers to act as your beacons. This is to guard against
the server being at fault, and not the link.
A FIB route entry is added in the kernel to reach the servers defined on the Performance SLA page
over each participant interface. These kernel routes are flagged as proto=17. These kernel routes will
act independently of the usual sources of routing.
The GUI provides two protocol options with which to perform the status check: Ping and HTTP, but in
the CLI you have five options. Those options are: ping and HTTP as in the GUI, but also TCP echo,
UDP echo, and Two-Way Active Measurement Protocol (TWAMP).

DO NOT REPRINT
© FORTINET
The quality of service for the traffic associated with this performance SLA is defined by the SLA
Targets. An SD-WAN member link assigned to this performance SLA must meet the SLA target in
order to be selected over the other participating links. You can configure the latency, jitter, and packet
loss thresholds to meet your needs, and create granular SLA targets to fine-tune the SD-WAN for
specific applications.
Although SLA Targets are specified on the Performance SLA page, they are not actually used there.
The values configured there, are used only when referenced by a rule. You can create multiple SLA
targets per performance SLA, although there are few scenarios in which you would want to do that.
For example, you are located in a branch office and use a few different applications that run on the
same server headquarters. You could create one performance SLA that will perform the health check
on that server, but then have different SLA targets for the different applications. You could make the
rules for some apps lenient, but more strict for others. If, however, the applications are running on
different servers, then you would want to create different performance SLAs for each application in
order to have the health check go against the specific application’s server. And each performance SLA
would require only one SLA target for that application.

DO NOT REPRINT
© FORTINET
This is where you can set how often the system checks the link status to determine if it needs to
transfer the traffic to another link. The Failure before Inactive and Restore link after settings are to
help prevent the system from continuously transferring traffic back and forth between links, a condition
known as flapping.

DO NOT REPRINT
© FORTINET
The Performance SLA (health checks) measures the quality of the links connected to the member
interface participating in a performance SLA. Three different criteria are used for this measurement:
latency, jitter, and packet loss percentage.
It’s these values that are used against the SLA criteria within the rules that are used to route traffic
based on the link quality of each member.
The packet loss, latency, and jitter that are displayed are based on the replies (averaged over a short
period) from the server that the performance SLA is using. The system will start with the first server. If
that server becomes unavailable, then it will switch to the second server. It will stay with that second
server until it becomes unavailable, at which point it will go back to the first server. If both servers are
unavailable, then that performance SLA is deemed dead.
It is important to note that the green up arrows are indicating only that the server is responding to the
health check, regardless of the packet loss, latency, and jitter values. They are not an indication that
any of the SLA targets are being met.

DO NOT REPRINT
© FORTINET
The CLI commands for configuring a performance SLA provides more options. The tcp-echo, udp-
echo, and twamp options are only available on the CLI. These options provide different methods of
measuring round-trip network performance between any two devices that support them. There are
other CLI-only options that are available based only on the performance SLA protocol you choose. For
more information about these options, refer to the CLI Reference Guide on docs.fortinet.com.
You can configure the warning and alert thresholds for the latency, jitter, and packet loss quality
checks. These are also not available on the GUI.
You can also configure multiple SLA targets with different values on both the GUI and the CLI.

DO NOT REPRINT
© FORTINET
An SD-WAN member is considered alive as long as its configured failure threshold has not been
reached. Alive status is not affected by measured packet-loss, latency, and jitter values. These
members are in the selected state in the SD-WAN rules.

DO NOT REPRINT
© FORTINET
If the failure threshold is reached by any SD-WAN member referred to in a Performance SLA, the
member will be marked dead. In the example shown on this slide, five consecutive probes remained
unanswered through port1. As a result, port1 was marked dead. Port 1 will be also marked dead in all
the rules associated with the performance SLA DC_PBX_SLA.

DO NOT REPRINT
© FORTINET
If Update static route is enabled, all static routes will be updated if an SD-WAN member is dead. The
dead member(s) are removed from the routing table.
After removing the static route, existing sessions will be revalidated.

DO NOT REPRINT
© FORTINET
By mastering the objectives covered in this lesson, you learned how to perform SD-WAN advanced
configuration and routing.

SD-WAN Rules
DO NOT REPRINT
© FORTINET
In this lesson, you will learn about SD-WAN rules.

SD-WAN Rules
DO NOT REPRINT
© FORTINET
By demonstrating competence in SD-WAN rules, you should be able to configure dynamic link selection
based on link quality to ensure high availability for business critical applications.

SD-WAN Rules
DO NOT REPRINT
© FORTINET
SD-WAN rules allow you to specify which traffic you want to route through which interface. You can configure
the SD-WAN rules to choose the egress interface(s) based on different strategies. The rules are evaluated in
the same way as firewall policies: from top to bottom, using the first match. You can use the following
parameters to match the traffic:
• Source IP address
• Destination IP address
• Destination port number
• ISDB address objects as destination
• Firewall application as destination
• Users or user groups
• Type of service (ToS)
SD-WAN rules offer great flexibility when matching traffic. For example, you can route Netflix traffic from
specific authenticated users through one ISP, while routing the rest of your Internet traffic through another
ISP.

SD-WAN Rules
DO NOT REPRINT
© FORTINET
SD-WAN can use the Internet services database, as well as the application control database to steer
applications along a specific link.
FortiGuard maintains these databases, and FortiGate periodically gets an updated copy. When using the
application control database, you should enable SSL deep inspections, because it is a requirement for an
accurate application identification.
4
SD-WAN Rules
DO NOT REPRINT
© FORTINET
FortiGate SD-WAN offers four strategies for selecting an outgoing interface(s): Manual, Best Quality,
Lowest Cost (SLA), and Maximize Bandwidth (SLA).
With the Manual strategy, you can select the interface you want to send traffic out from. If the traffic matches
the rule criteria, the traffic will go out from the selected interface. This strategy does not depend on
performance SLA or SLA targets.

SD-WAN Rules
DO NOT REPRINT
© FORTINET
The best quality strategy is based on the performance of the link. In the example shown on this slide, port1
and port2 are included in the interface preference. So, port1 will be used (because it is the first one on the list)
until the quality of the port1 's link is 10% or more worse than that the quality of port2's link, at which point
port2 would take over. By default, the quality threshold is 10%, but you can change it on the CLI using the set
link-cost-threshold command. Note that you don't use any of the SLAs here. FortiGate is estimating
the quality of each link based on either latency, jitter, or packet loss percentage.
The last option, custom profile-1, allows you to estimate the quality of each link based on a combination of
the same three performance measures. The link quality will be determined by the equation.
Leave the weight value at zero to exclude that criteria from the equation.

SD-WAN Rules
DO NOT REPRINT
© FORTINET
You can also use the bandwidth options (Downstream bandwidth, Upstream bandwidth, or bidirectional
Bandwidth) so that FortiGate selects the link based on the available bandwidth in the incoming direction,
outgoing direction, or both.
To use this type of rules, you must configure the estimated upstream and downstream bandwidths using the
CLI.

SD-WAN Rules
DO NOT REPRINT
© FORTINET
With the lowest cost (SLA) strategy, you select an SLA target from a performance SLA. Note that even if a
performance SLA has multiple SLA targets, you can only select one of the SLA targets from that particular
performance SLA.

SD-WAN Rules
DO NOT REPRINT
© FORTINET
(slide contains animation)
FortiGate follows the flow shown on this slide to select an outgoing interface based on Lowest Cost (SLA).
For example, SD-WAN has four members; port1, port2, port3, and port4.
First, FortiGate considers the SLA targets and eliminates port4 from the list of potential outgoing interfaces, as
port4 does not satisfy the SLA target.
Then, FortiGate considers the cost to eliminate any interface from the potential list. You can configure the cost
by clicking Network then SD-WAN under SD-WAN Interface Members. FortiGate will prefer an interface
with a lower cost. In the example shown on this slide, ports1 and 2 have both a cost of 5, and port3 has a cost
of 10. In this case, FortiGate will eliminate interface 3 from the list of potential outgoing interfaces.
Lastly, FortiGate checks the Interface Preference for all the interfaces and select an outgoing interface. In
the example shown on this slide, port2 has a higher preference than port1. In this case, FortiGate will select
port2 as the outgoing interface for the traffic matching the rule. (click)

SD-WAN Rules
DO NOT REPRINT
© FORTINET
(slide contains animation)
This feature introduces a new load balancing mode for the SD-WAN rule. If traffic matches the rule settings,
the traffic will be load balanced among all the members that satisfy the SLA target. If there are multiple SLA
targets, traffic will be load balanced over all the members that meet all the targets. With this strategy, the
traffic will be load balanced using session based round robin method.
The example on this slide shows that port1, port2, and port3 satisfy the SLA target requirements and port4
does not. In this case, the traffic matching the rule will be load balanced between port1, 2 and 3. (Click)
When using this method, FortiGate will not take cost or preference into consideration.

SD-WAN Rules
DO NOT REPRINT
© FORTINET
The CLI commands for configuring SD-WAN rules provide more options.
Using the input-device-negate enable option, you can select all interfaces as acceptable source
interfaces, but exempt the ones you configure using the command set input-device. With input-
device-negate enable, the SD-WAN rule will match all the incoming interfaces except the interfaces
configured with the set input-device command.
You can select any of the four modes you learned about in this section here. You also have the option to
select auto mode. With auto mode, the FortiGate selects an SD-WAN member based on the quality of the link.
• auto: to select the interface based on the quality of the link
• manual: to select Manual strategy
• priority: to select Best Quality strategy
• sla: to select Lowest Cost (SLA) strategy
• load-balanced: to select Maximize Bandwidth (SLA) strategy
You can use set default enable to use SD-WAN as the default service. You will learn about the
interface selection flow for this option later in the lesson.

SD-WAN Rules
DO NOT REPRINT
© FORTINET
By demonstrating competence in the SD-WAN policy routing, you should be able to understand the interface
selection and routing flow for any traffc.

SD-WAN Rules
DO NOT REPRINT
© FORTINET
As discussed earlier in this lesson, SD-WAN rules are policy-based routes that route specific traffic over one
or more SD-WAN members. When it comes to policy routing, FortiGate first checks regular policy routes
before checking SD-WAN policy routes. If no policy routes matches the traffic, a FIB lookup is performed. If
the FIB-resolved interface is an SD-WAN member, FortiGate will select an outgoing interface based on the
load-balancing algorithm configured under the implicit rule.

SD-WAN Rules
DO NOT REPRINT
© FORTINET
This slide shows the criteria for selecting the outgoing SD-WAN interface when FortiGate receives the first
packet.
SD-WAN policy routes are checked from top to bottom (first match). FortiGate will match specifications
defined under the rule, such as inbound interface, destination IP, source IP, source port, destination port and
so on.
If the policy route is matched for the packet coming in, FortiGate checks the SD-WAN rule settings.
With the default of set default disable FIB lookups are done to validate the route to the destination.
Requirements to select an outbound interface are:
• Best match to the destination must reference an SD-WAN member.
• A policy-route (proute) outbound interface (oif) is considered acceptable only if it has a FIB route to the
destination.
• The first oif from the proute’s OIF_LIST (outbound interface list) fulfilling this requirement is
selected.
• If none of the oif fulfills this requirement, this policy route is considered a no-match and the SD-
WAN policy-route lookup resumes to the next SD-WAN policy-route.
With the configuration set default enable + set gateway enable, FortiGate will select the first
outbound interface in the SD-WAN policy route and will skip the FIB lookup.

SD-WAN Rules
DO NOT REPRINT
© FORTINET
Locally originated traffic is subject to policy-route lookup. Examples of locally originated traffic are BGP,
syslogs, SNMP traps, and so on. Locally originated traffic, like BGP destined to a directly connected BGP
peer, may egress over another interface because of a policy route.
There are a few ways to prevent locally originated traffic from matching a regular and an SD-WAN policy
route:
• Avoid using all as source address, and restrict the source with address objects that do not cover the IP
addresses used by the self-originated traffic.
or
• Enforce an ingress interface in the SD-WAN rule so that only traffic arriving to the FortiGate (and not self-
originated traffic) matches the policy route.
or
• Create regular policy route with the IP addresses of the SNMP server, syslog server, and BGP neighbors
as destination addresses and select Stop Policy Routing as Action, to skip all policy routes.

SD-WAN Rules
DO NOT REPRINT
© FORTINET
After a routing change, sessions are revalidated and may failover to another SD-WAN member.
Examples of a routing change are:

• When the order of the interfaces in the policy-route changes
• When an SD-WAN member state changes
• When there is a dynamic routing update
You can use the interface-level command shown on this slide to force the session to stay on the same SD-
WAN member.

SD-WAN Rules
DO NOT REPRINT
© FORTINET
By demonstrating competence in the identifying application methods, you should be able to understand and
configure SD-WAN rules to match and route application traffic.

SD-WAN Rules
DO NOT REPRINT
© FORTINET
You will now learn some of the methods for identifying applications from the traffic flow.
One of the method is ISDB. This database of well-known Internet service definitions is made of public IP
addresses and destination ports. The ISDB database is updated frequently from FortiGuard. This method also
identifies the application immediately. However, and although it includes all the most well-known Internet
services, it does not include all of them.
The custom ISDB method uses a user-defined ISDB. Administrators can create custom services. Customer
services can be grouped into custom service groups. This method is flexible and the identification is also fast,
although it requires manual maintenance.
Another method uses FQDN firewall addresses as destinations. With this method, FortiGate uses DNS to
resolve the FQDN into IP addresses. It is simple and fast, but it is not accurate for cloud services, neither for
most of the well-known Internet services.

SD-WAN Rules
DO NOT REPRINT
© FORTINET
A requirement for the DSCP method is that the traffic must be marked with IP DSCP before reaching
FortiGate. With this method, FortiGate uses the DSCP marking of packets to apply an SD-WAN rule. This
method is useful to integrate SD-WAN with an existing architecture. However, by using this method you may
have less control over traffic identification. Also, users and/or applications may interfere with marking.
With application control, FortiGate identifies applications based on signatures. The well-known applications
list is updated from FortiGuard servers automatically. This method requires a learning phase during which the
first session is required to identify the application and may not match the expected SD-WAN rule. After the
initial learning phase, dynamic cache entries are stored in the ISDB to avoid the learning phase again.
With the customer application control method, users can define a custom application control signature.

SD-WAN Rules
DO NOT REPRINT
© FORTINET
ISDB entries are dynamically updated from FortiGuard servers. Because of automatic updates, the ISDB is
free from any maintenance by administrators. The ISDB is a database of well-known Internet services
definitions made of public IP addresses and destination ports.
The ISDB database is loaded in the kernel. Each ISDB entry is identified with a number starting from 65536.
Each entry is made of:

• A direction, which can be a destination, source, or both.
• A reference to a second-level domain internal list
• A reference to an IP-range internal list
• A reference to an IP number
• A reputation, which is coded with a number from 1 to 5. The meanings of each code are:
1. Known malicious sites related to botnet servers, phishing sites, and so on
2. Sites providing high-risk services such as TOR, proxy, P2P, and so on
3. Unverified sites
4. Reputable sites from social media such as Twitter, Instagram, and Facebook
5. Known and verified safe sites such as Gmail, Yahoo mail, and so on

SD-WAN Rules
DO NOT REPRINT
© FORTINET
You can use the command diagnose internet-service id to collect information regarding all the IP
addresses and ports for any given ISDB entry.
If you would like to get information regarding which ISDB entry includes a specific IP and a specific port, you
can use the diagnose internet-service info command. You can also search for ISDB entries that
include a specific IP using the diagnose internet-service match command.

SD-WAN Rules
DO NOT REPRINT
© FORTINET
On the GUI, you can check all the ISDB entries under Internet Service Database. Additionally, you can
enable or disable any IP ranges and port ranges based on your network requirement.
You can also enable or disable entries through the CLI using the config firewall internet-service-
extension command. This slide shows an example of how the administrator disabled the IP range 3.0.0.0
for the Amazon-AWS service.

SD-WAN Rules
DO NOT REPRINT
© FORTINET
With this method, you can specify applications in the SD-WAN rule to be matched and route traffic to. The
application database is dynamically updated from the FortiGuard server.
For this method, you must have application control profiles in the firewall policies allowing the SD-WAN traffic.
Enabling SSL deep inspection is recommended, because it improves the accuracy of the application
detection. If you are using Google signatures, you must block QUIC traffic.
First session is required for leaning phase to identify the application and may not match the expected rule.

SD-WAN Rules
DO NOT REPRINT
© FORTINET
The application control relies on the IPS to identify the application. The IPS engine requires the first session to
identify the application. Therefore, the first session to any destination might not match the correct rule,
because the application has not yet been identified by FortiGate and at the moment FortiGate had to take a
routing decision.
After the IPS identifies the application, it adds an entry to a dynamic ISDB table with the destination IP
address and port. Any further session to the same destination will use the ISDB entry to immediately identify
the application.
In the example shown on this slide, a rule has been created to route traffic matching application Dailymotion
to port2. The last rule routes everything else to port1. When you access Dailymotion, FortiGate will require the
first session to identify the application. This first session will not match the Dailymotion rule because the
application has not been identified by the IPS engine. This first session will go through the All_Access_Rule
and will be routed out from port1.
Once the application has been identified by IPS, it will create a dynamic ISDB entry and will add destination
IP addresess and destination port(s) to the dynamic ISDB entry for Dailymotion. This entry will be pushed to
the kernel firewall.
From the next session, if the traffic is destined to the IP addresses and ports listed under the dynamic ISDB
entry, FortiGate will use the information in the dynamic ISDB cache to immediately identify the application and
will route traffic through the right SD-WAN rule.
The dynamic ISDB database can hold up to 512 entries.

SD-WAN Rules
DO NOT REPRINT
© FORTINET
By demonstrating competence in SD-WAN diagnostics, you should be able to maintain an efficient and
effective SD-WAN solution.

SD-WAN Rules
DO NOT REPRINT
© FORTINET
You can use the diagnose sys virtual-wan-link command to collect different information as shown
on the slide. To collect basic information regarding SD-WAN members, you can use the diagnose sys
virtual-wan-link command to check the detailed description for the number of SD-WAN members.

SD-WAN Rules
DO NOT REPRINT
© FORTINET
You can use the SD-WAN usage monitor to view traffic distribution between the member interfaces, based on
bandwidth or volume.
The Volume view gives a better representation of the traffic sent and received across all the member
interfaces; whereas the Bandwidth view shows you how much bandwidth each interface is using as a result
of the sessions passing through them. The Sessions view shows the number of sessions passing through for
each interface.

SD-WAN Rules
DO NOT REPRINT
© FORTINET
Because link quality plays a big role in link selection when using SD-WAN, monitoring the link quality status of
the SD-WAN member interfaces is a good practice. Any prolonged issues with packet loss and latency should
be investigated to ensure your network traffic does not experience outage or degraded performance. Green
arrows indicate interfaces are active in the SD-WAN group. Red arrows indicate that the interface is inactive
for that specific status check.
FortiGate will also generate system event logs when an SD-WAN member interface’s route is removed or
added to the routing table. Use System Events to investigate any route failovers.

SD-WAN Rules
DO NOT REPRINT
© FORTINET
You can collect the same information regarding link status and health-check logs from the CLI using the
debug commands shown on this slide. By using the diagnose sys virtual-wan-link health-check
command, you can check if any member of the performance SLA is dead or not.

SD-WAN Rules
DO NOT REPRINT
© FORTINET
The process responsible for performing SLA probes is lnkmtd. You can collect different information about the
link-monitor by using the diagnostic commands shown on this slide. You have to select an appropriate level to
collect specific information.
For example, to collect debug information for ICMP probes, you can run the following commands:
diagnose debug enable

diagnose debug application link-monitor 8

SD-WAN Rules
DO NOT REPRINT
© FORTINET
You can use the Destination Interface column in the forward traffic logs to verify that traffic is egressing the
SD-WAN member interfaces. Alternatively, you can use verbosity levels 4 and 6 to view the egress interface
using the CLI packet capture tool.

SD-WAN Rules
DO NOT REPRINT
© FORTINET
You can collect detailed information regarding any SD-WAN rule using the commands shown on this slide.
This shows you a detailed description regarding SD-WAN rules including address mode, protocol, mode, link
cost factor, health-check referenced, members, and member sequence.

SD-WAN Rules
DO NOT REPRINT
© FORTINET
By mastering the objectives covered in this lesson, you learned how to perform SD-WAN advanced
configuration and routing.

Traffic Shaping
DO NOT REPRINT
© FORTINET
In this lesson, you will learn about traffic shaping.

Traffic Shaping
DO NOT REPRINT
© FORTINET
By demonstrating competence in traffic shaping, you should be able to effectively prioritize specific traffic
flows over other traffic on FortiGate.

Traffic Shaping
DO NOT REPRINT
© FORTINET
Traffic shaping attempts to normalize traffic peaks and bursts to prioritize certain flows over others.
FortiGate provides quality of service (QoS) by applying bandwidth limits and prioritization. Using traffic
shaping, you can adjust how your FortiGate allocates resources to different traffic types, to improve the
performance and stability of latency-sensitive or bandwidth-intensive network applications.

Traffic Shaping
DO NOT REPRINT
© FORTINET
Because bandwidth is finite and because some types of traffic are slow, jitter or packet loss sensitive,
bandwidth intensive, or operation critical, QoS can be a useful tool for optimizing the performance of the
various applications on your network.
Discovering the needs and relative importance of each traffic type on your network will help you to design an
appropriate overall approach, including how you will configure each available QoS component technique.
Traffic policing is dropping packets that do not conform to bandwidth limitations.
Traffic shaping consists of a mixture of traffic policing to enforce bandwidth limits and priority queue
adjustment to assist packets in achieving the guaranteed rate.
Queuing ensures that packets are transmitted in order of their assigned priority queue for that physical
interface.

Traffic Shaping
DO NOT REPRINT
© FORTINET
By demonstrating competence in traffic shaping configuration, you should be able to configure different types
of shapers and enable them on traffic shaping policy.

Traffic Shaping
DO NOT REPRINT
© FORTINET
When configuring traffic shaping for your network, there are three different methods to control the flow of
network traffic to ensure that the desired traffic gets through while also limiting bandwidth for less important or
bandwidth consuming traffic.
There are three methods:

• Policy shaping enables you to define the maximum bandwidth and the guaranteed bandwidth set for a
security policy.
• Per-IP shaping enables you to define traffic control on a more granular level.
• Interface-based shaping goes further, enabling traffic controls based on percentage of the interface
bandwidth.

Traffic Shaping
DO NOT REPRINT
© FORTINET
There are few preconfigured shapers that you can use in the traffic shaping policy to control the traffic.
You can also monitor real-time statistics for shapers which will show current bandwidth utilization and dropped
bytes.

Traffic Shaping
DO NOT REPRINT
© FORTINET
The Max Bandwidth option will set the largest amount of traffic allowed using a policy where this shaper is
enabled. If traffic goes above this limit then FortiGate will start dropping packets.
The Guaranteed Bandwidth option ensures there is a consistent reserved bandwidth available for traffic
passing through the policy. It should be significantly less than the bandwidth capacity of the interface. If not, it
will cause unwanted latency for other traffic passing through that shaper policy.
In the Traffic Priority drop-down list, you can select High, Medium, or Low.
When the per-policy option is disabled (default is disable), FortiGate applies shaping rules to all policies using
this shaper. If the per-policy option is enabled, then FortiGate applies shaping rules to each policy individually.
In the example shown on this slide, 30 Mbps of maximum bandwidth is allocated and 10 Mbps bandwidth is
guaranteed. So, the traffic passing through this policy will be guaranteed 10 Mbps of bandwidth at any given
point in time.

Traffic Shaping
DO NOT REPRINT
© FORTINET
Per-IP traffic shaping enables you to limit the behavior of each IP address of a policy to prevent one user from
using all the available bandwidth; it is shared within a group, equally. You can also define the maximum
number of concurrent sessions for an IP address.
For example, if you apply a per-IP shaper of 5 Mbps to your entire network, FortiOS allocates each user/IP
address 5 Mbps of bandwidth. Even if the network consists of a single user, FortiOS allocates them 5 Mbps. If
there are ten users, each user gets 5 Mbps of bandwidth, totaling 50 Mbps of outgoing traffic. In the example
shown on this slide, each user will be allocated 5 Mbps of maximum bandwidth and five concurrent sessions
at a time.

Traffic Shaping
DO NOT REPRINT
© FORTINET
The traffic shaping policy controls how traffic will be shaped.
You need to define the criteria using different options (source address, destination address, and so on) and
then apply the action by defining the outgoing interface with appropriate shapers, or classify it as a group to be
used with interface-based shaping.

Traffic Shaping
DO NOT REPRINT
© FORTINET
You can control traffic by specific application, application category, and/or URL category.
In the example shown on the slide, a security policy has been configured with application control enabled first,
so you have a traffic shaping policy for YouTube guaranteeing 100 kbps bandwidth.

Traffic Shaping
DO NOT REPRINT
© FORTINET
Enabling a shared shaper on a traffic shaping policy will affect only outbound traffic.
In the example shown on the slide, the Shared shaper and Reverse shaper options are enabled on the
traffic shaping policy. FortiGate will restrict upload and download speed when accessing YouTube.

Traffic Shaping
DO NOT REPRINT
© FORTINET
Traffic flow has an associated bucket with the size of your configured bandwidth limit. Tokens are added into a
bucket (which represents available bandwidth) at a fixed configured rate, up to the capacity of the bucket.
Excess tokens are discarded.
Each token usually represents a packet or a number of bytes in the packet. (So, several tokens may be
needed to match a packet.) When a packet is to be processed, the bucket is inspected. If the bucket contains
the number of tokens matching the packet, the tokens are removed from the bucket and the packet is sent
forward. If the number of available tokens is insufficient, the packet will be dropped.
The guaranteed bandwidth feature attempts to achieve or exceed the rate, rather than limit it. FortiGate does
not discard non-conforming packets like it does for maximum bandwidth. Instead, when the flow does not
achieve the rate, FortiGate increases the packets’ priority queue in an effort to increase the rate.

Traffic Shaping
DO NOT REPRINT
© FORTINET
By design, traffic shaping configured in a firewall policy, application list, traffic shaper policy, uses an initial
burst approach. This means that during transitions from no traffic to having traffic, for the first second of the
transition, the rate can be up to two times the configured rate. Then, after the first second of the transition, the
rate reduces to the configured rate, and should stay there.
Sometimes, you will see the current bandwidth utilization of a particular shaper going above the configured
maximum bandwidth limit.

Traffic Shaping
DO NOT REPRINT
© FORTINET
By demonstrating competence in interface-based traffic shaping, you should be able to configure traffic
shaping on an interface level.

Traffic Shaping
DO NOT REPRINT
© FORTINET
With the presence of SD-WAN, shaping-profile entries make shaping more flexible. Since SD-WAN can direct
traffic to any link, and different links can have different bandwidths, defining the percentage of interface
bandwidth for each class of traffic makes more sense.
There are three steps to configuring interface-based shaping:

1. Classify traffic into different groups using traffic shaping policy.
2. Configure the traffic shaping profile; assign a percentage-based value for guaranteed and maximum
bandwidth, along with priority to each group.
3. Assign shaping profile to interface with outbound bandwidth configured.

Traffic Shaping
DO NOT REPRINT
© FORTINET
You can configure up to 30 groups or class IDs ranging between 2 to 31.
In the example shown on the slide, traffic has been classified based on different source addresses. Group 3 is
configured for the admin staff network and all other traffic (Non_Admin_Staff) is classified into group 2
(default class).
You will use these configured groups in the traffic shaping profile.

Traffic Shaping
DO NOT REPRINT
© FORTINET
Shaping profiles define how different shaping groups or classes of traffic are prioritized.
Based on the traffic shaping policy configuration, you can classify traffic into different groups and then use
those groups in the traffic shaping profile configuration.
Each group is assigned a guaranteed bandwidth, maximum bandwidth (in percentage) and a priority value,
which will use the outbound bandwidth limit configured on an interface for shaping.
Group 3 (Admin_Staff) is assigned 70% of the interface bandwidth, and the default group 2
(Non_Admin_Staff) is assigned 30% of the interface bandwidth.

Traffic Shaping
DO NOT REPRINT
© FORTINET
In the example shown on the slide, SD-WAN has two members: port1 and port2. Both links have a different
ISP pipe; port1 has 100 Mbps, and port2 has 80 Mbps.
Traffic coming from the Admin_Staff network going through port1 will be guaranteed 70% of 100 Mbps (the
configured outbandwidth on the interface), which will be 70Mbps; and when going through port2, it will be
guaranteed 70% of 80 Mbps, which will result in 56 Mbps.
Traffic coming from the Non_Admin_Staff network going through port1 will be guaranteed 30% of 100
Mbps, which will be 30Mbps; and when going through port2, it will be guaranteed 30% of 80 Mbps which will
result in 24 Mbps.

Traffic Shaping
DO NOT REPRINT
© FORTINET
As an example, say that interface bandwidth is configured at 100 Mbps.
Both class 2 and 3 will be assigned their guaranteed bandwidth first, which would be 20 Mbps each (20% of
100 Mbps). Then, the remaining available bandwidth of 60 Mbps will be allocated to class 2, because of its
higher priority.
If you assign multiple classes with the same priority, the rule for allocating bandwidth to same priority classes
is as follows:
When the same priority classes compete for available bandwidth, the allocation to each class will be
proportional to its guaranteed-bandwidth-percentage. Consider a slightly more complex example: All
classes will be assigned their guaranteed bandwidth first, which would be 20 Mbps for class 2, 20 Mbps for
class 3, and 30 Mbps for class 4. The remaining 30 Mbps will be allocated to class 2 and class 4, because of
their higher priority. The allocation for this remaining 30 Mbps will be proportional to their guaranteed
bandwidth. In this case, it will be 12 Mbps for class 2 (30 Mbps * 20 / 50), and 18 Mbps for class 4 (30 Mbps *
30 / 50).

Traffic Shaping
DO NOT REPRINT
© FORTINET
After completing this section, you should be able to to achieve the objective shown on this slide.

Traffic Shaping
DO NOT REPRINT
© FORTINET
In this example, SIP audio traffic and data traffic is going through FortiGate with a 100 Mbps ISP link. You
want to prioritize SIP traffic, limit any streaming site access, and assign medium priority to all other traffic.

Traffic Shaping
DO NOT REPRINT
© FORTINET
In the example shown on this slide, three shapers are configured and each of them are enabled on traffic
shaping policies.
A guaranteed bandwidth of 20 Mbps is allocated for VoIP traffic, with a maximum allowed bandwidth of 50
Mbps and a priority as high.
The second shaper is allocated for video traffic, for which only 5 Mbps maximum bandwidth is configured.
Policy 2 is configured with that shaper and in the URL Category list Streaming Media and Download is
selected as a matching criteria. We need to have an IPv4 policy with web filter for this setup to work.
The third shaper is configured for the remaining traffic that does not match the first two policies’ criteria. In this
shaper, the maximum bandwidth is 100 Mbps and the priority is set to medium.

Traffic Shaping
DO NOT REPRINT
© FORTINET
Based on the configuration discussed on the previous slide, consider the following scenario:
SIP audio traffic will always be guaranteed 20 Mbps, and streaming video traffic will max out at 5 Mbps. Any
video traffic above 5 Mbps will be dropped by FortiGate. All other traffic will use the available bandwidth.
If SIP traffic continues to increase, FortiGate will keep prioritizing SIP over video packets until SIP traffic
reaches the bandwidth value defined as maximum. When this happens, FortiGate will start to drop the SIP
packets.
Because there is no guaranteed bandwidth for video packets, and also because video packets have a low
priority, these packets will be dropped first, when competing against SIP traffic and all other traffic.

Traffic Shaping
DO NOT REPRINT
© FORTINET
By demonstrating competence in troubleshooting, you should be able to identify different messages when
running debug flow, and identify sessions with different shapers.

Traffic Shaping
DO NOT REPRINT
© FORTINET
Using the commands shown on this slide, you can view the bandwidth actively being used by a specific
shaper, priority queue value, and number of dropped packets if traffic is going above the maximum bandwidth.
When configuring the shaper, you configured the bandwidth value in Kbps; however in CLI debugs, you see
output in KBps.
When you use the per-IP shaper, you can clearly see that for each IP, only five concurrent sessions are
allowed and any excess packets are dropped by the shaper.

Traffic Shaping
DO NOT REPRINT
© FORTINET
In the session table, you can see shaper information and other detailed information, like the packet drop
counter.

Traffic Shaping
DO NOT REPRINT
© FORTINET
You can see the per-IP shaper associated with a particular session in the session table.

Traffic Shaping
DO NOT REPRINT
© FORTINET
In a shared and per-IP shaper configuration, when traffic is exceeding the configured maximum bandwidth,
you will see the “exceeded shaper limit, drop“ message when running debug flow.
In a per-IP shaper configuration, if an IP exceeds the configured concurrent session limit, you will see the
“Denied by quota check“ message.

Traffic Shaping
DO NOT REPRINT
© FORTINET
Using the command shown on the slide, you can determine the bandwidth allocated for a particular class-id
based on priority.

Traffic Shaping
DO NOT REPRINT
© FORTINET
By mastering the objectives covered in this lesson, you learned how to configure traffic shaping to limit or
shape bandwidth use by different traffic on FortiGate.

Integration
DO NOT REPRINT
© FORTINET
In this lesson, you will learn about FortiManager basics, SD-WAN manager, VPN manager, and zero-touch
provisioning.

Integration
DO NOT REPRINT
© FORTINET
By demonstrating competence in understanding the key features of FortiManager, you will be able to use those
features effectively in your network.

Integration
DO NOT REPRINT
© FORTINET
When should you use FortiManager in your network?
In large enterprises and managed security service providers (MSSPs), the size of the network introduces
challenges that smaller networks don’t have: mass provisioning; scheduling rollout of configuration changes; and
maintaining, tracking, and auditing many changes.
Centralized management through FortiManager can help you to more easily manage many deployment types
with many devices, and to reduce the cost of operation.
What can FortiManager do?
• Provision firewall policies across your network

• Act as a central repository for configuration revision control and security audits
• Deploy and manage complex mesh-and-star IPsec VPNs
• Act as a private FortiGuard distribution server (FDS) for your managed devices
• Script and automate device provisioning, policy changes, and more with JSON APIs

Integration
DO NOT REPRINT
© FORTINET
FortiManager can help you to better organize and manage your network. Key features of FortiManager include:
• Centralized management: Instead of logging in to hundreds of FortiGate devices individually, you can use
FortiManager to manage them all from a single console.
• Administrative domains (ADOMs): FortiManager can group devices into geographic or functional ADOMs,
which is ideal if you have a large team of network security administrators.
• Configuration revision control: Your FortiManager keeps a history of all configuration changes. You can
schedule FortiManager to deploy a new configuration or revert managed devices to a previous configuration.
• Local FortiGuard service provisioning: To reduce network delays and minimize Internet bandwidth usage,
your managed devices can use FortiManager as a private FDN server.
• Firmware management: FortiManager can schedule firmware upgrades for managed devices.
• Scripting: FortiManager supports CLI-based and TCL-based scripts for configuration deployments.
• Pane Managers (VPN, FortiAP, FortiSwitch, and Fabric View): FortiManager management panes simplify
the deployment and administration of VPN, FortiAP, FortiSwitch and Fabric View (Security Fabric).
• Logging and reporting: Managed devices can store logs on FortiManager. From that log data, you can
generate SQL-based reports, because FortiManager has many of the same logging and reporting features as
FortiAnalyzer.
• FortiMeter: Allows you turn FortiOS-VMs and FortiWebOS-VMs on and off as needed, paying only for the
volume and consumption of traffic that you use. These VMs are also sometimes called pay-as-you-go VMs.
You must have a FortiMeter license and the FortiMeter license must be linked with the FortiManager unit by
using FortiCare.

Integration
DO NOT REPRINT
© FORTINET
By demonstrating competence understanding FortiManager software architecture, you will be able to plan and set
up FortiManager in your network.

Integration
DO NOT REPRINT
© FORTINET
To organize and efficiently manage a large-scale network, FortiManager has multiple management layers.
The Global ADOM layer has two key pieces: the global object database and header and footer policy packages.
Header and footer policy packages envelop each ADOM’s policies. An example of where policy packages are
used is in a carrier environment, where the carrier allows customer traffic to pass through their network, but does
not allow the customer to have access to the carrier’s network infrastructure.
The ADOM layer is where policy packages are created, managed, and installed on managed devices or device
groups. Multiple policy packages can be created here. The ADOM layer includes one common object database
for each ADOM. The common object database contains information such as addresses, services, and security
profiles.
The Device Manager layer records information on devices that are centrally managed by the FortiManager
device, such as the name of the device, type of device, model, IP address, current firmware installed, revision
history, and real-time status.

Integration
DO NOT REPRINT
© FORTINET
Understanding the layers of FortiManager’s management model is important.
In the Global ADOM layer, you create header and footer policy rules. These policy rules can be assigned to
multiple ADOMs. If multiple ADOM policy packages require the same policies and objects, you can create them in
this layer so that you don’t have to maintain copies in each ADOM.
In the ADOM layer, objects and policy packages in each ADOM share a common object database. You can
create, import from, and install policy packages on many managed devices at once.
In the Device Manager layer, you can configure and install device settings for each device. If a configuration
change is detected—made locally or on FortiManager—FortiManager compares the current configuration to the
changed configuration, and creates a new configuration revision on FortiManager. Whether the configuration
change is big or small, FortiManager records it and saves the new configuration. This can help administrators to
audit configuration changes, and to revert to a previous revision, if required.

Integration
DO NOT REPRINT
© FORTINET
What is an ADOM?
ADOMs enable the admin account to create groupings of devices for administrators to monitor and manage. For
example, administrators can manage devices specific to their geographic location or business division. ADOMs
are not enabled by default and must be enabled by the administrator.
The purpose of ADOMs is to divide the administration of devices, by grouping them based on management
criteria, and to control (restrict) administrative access. Administrative access is assigned based on an
administrator profile that allows access to one or multiple ADOMs on the device. If virtual domains (VDOMs) are
used, ADOMs can further restrict access to data from only a specific device’s VDOM. The number of available
ADOMs varies based on model.

Integration
DO NOT REPRINT
© FORTINET
The Device Manager pane provides device and installation wizards to aid you in various administrative and
maintenance tasks. Using these wizards can decrease the amount of time it takes to do many common tasks.
There are four main wizards on the Device Manager pane:
• Add Device is used to add devices to central management and import their configurations.
• Install Wizard is used to install configuration changes from the Device Manager pane or Policies & Objects
pane to the managed devices. It allows you to preview the changes and, if the administrator doesn’t agree with
the changes, cancel and modify them.
• Import Policy is used to import interface mappings, policy databases, and objects associated with the
managed devices into a policy package under the Policy & Object pane. It runs with the Add Device wizard,
by default, and may be run at any time from the managed device list.
• Re-install Policy is used to perform a quick install of the policy package. It provides the ability to preview the
changes that will be installed on the managed device.
You can open the Import policy and Re-install Policy wizards by right-clicking your managed device in the
Device Manager.

Integration
DO NOT REPRINT
© FORTINET
By demonstrating competence in understanding SD-WAN and its feature sets, you will be able to install and
configure the settings required to use those features in your network.

Integration
DO NOT REPRINT
© FORTINET
When you configure an SD-WAN, you must specify at least two member interfaces. You should configure an SD-
WAN early during the initial setup of FortiGate because if an interface is already referenced by a firewall policy or
static route, you cannot use it as a member interface. If you intend to use an interface as an SD-WAN member,
and that interface is being referenced by a firewall policy or static route, you must delete the associated firewall
policy and static route before you can assign that interface as an SD-WAN member. SD-WAN supports physical
interfaces as well as VLAN, aggregate, and IPsec interfaces.
FortiManager groups all the member interfaces into a single virtual interface: the SD-WAN interface. Using SD-
WAN simplifies configuration because the administrator can configure a single set of routes and firewall policies
and apply them to all member interfaces. There can be only one SD-WAN interface per VDOM.
The first step in creating an SD-WAN using FortiManager is to enable SD-WAN central management in the
ADOM.

Integration
DO NOT REPRINT
© FORTINET
Configure the Health-Check Servers to be used in SD-WAN Templates and the Performance SLA.
Health-Check Servers is a mechanism for detecting when a router along the path is stopped or degraded.
FortiGate can check the status (or health) of each SD-WAN member interface participating in a Performance
SLA, by periodically sending probing signals through each member link to a server that acts as a beacon. You
can specify multiple servers to act as your beacons. This is to guard against the server being at fault, and not the
link.
When you configure SD-WAN, you must specify at least two member interfaces and their associated gateways.

Integration
DO NOT REPRINT
© FORTINET
SD-WAN Templates allows you to add your SD-WAN components to a single template. You can add interface
members, Performance SLA, and SD-WAN Rules.
You can create new SD-WAN rules or use the default implicit rule. The implicit rule is designed to balance the
traffic among all the available SD-WAN member links. SD-WAN rules allow you to specify which traffic you want
to route through which interface. You can configure the SD-WAN Rules to choose the egress interface based on
a link’s latency, jitter, or packet loss percentage that you configured in the Performance SLA section. The rules
are evaluated in the same way as firewall policies: from top to bottom, using the first match.

Integration
DO NOT REPRINT
© FORTINET
You must assign your devices for SD-WAN configuration in the Assigned Devices section. After you select your
device and WAN template, you will see all your SD-WAN member interfaces.

Integration
DO NOT REPRINT
© FORTINET
When using SD-WAN, you do not need to configure multiple firewall policies for individual member interfaces.
Firewall policies created with the SD-WAN interface allow traffic to be forwarded through any member interface.
You must configure correct dynamic interfaces and map ports before you install SD-WAN policies. In the example
shown on this slide, Local-Fortigate is a newly imported device and does not have firewall policies or correct port
mapping because SD-WAN configuration does not require policies to be associated with its member interfaces.
You must correctly map port3 to Local-FortiGate port3 using dynamic mapping as per the example shown on this
slide.

Integration
DO NOT REPRINT
© FORTINET
After you install all the settings successfully, you can check the SD-WAN status on the FortiManager SD-WAN
Monitor or on the managed FortiGate device.

Integration
DO NOT REPRINT
© FORTINET
By demonstrating competence in configuring IPsec VPNs using the FortiManager VPN manager, you will be able
to install and configure the settings required to use those features in your network.

Integration
DO NOT REPRINT
© FORTINET
On the VPN Manager screen, you can configure IPsec VPN settings that you can install on multiple devices. The
settings are stored as objects in the objects database. You push the IPsec VPN settings to one or more devices
by installing a policy package. Follow these steps to configure VPNs with the VPN manager:
1. Create a VPN community.
2. Add gateways (members) to the community.
3. Install the VPN community and gateways configuration.
4. Add the firewall policies.
5. Install the firewall policies.

Integration
DO NOT REPRINT
© FORTINET
Depending on the VPN topology to install, there are three types of communities:
• Full mesh
• Star
• Dial-up

Integration
DO NOT REPRINT
© FORTINET
The VPN community contains the IPsec phase 1 and 2 settings that are common to all the gateways.

Integration
DO NOT REPRINT
© FORTINET
The next step is to add gateways to the community. There are two types of gateways:
• Managed gateways
• External gateways
Managed gateways are managed by FortiManager in the current ADOM. Devices in a different ADOM or other
vendor devices can be treated as external gateways. VPN configuration must be handled manually by the
administrator in that ADOM.

Integration
DO NOT REPRINT
© FORTINET
In VPN gateways, you configure the node type (hub, spoke, and so on), depending on the VPN topology you
select. For example, hub and spoke options are only available in star and dial-up topologies.
For each gateway, you can also configure the protected subnet, interfaces, and some advanced settings.

Integration
DO NOT REPRINT
© FORTINET
By demonstrating competence in zero -touch provisioning, you will be able to understand and configure the
settings required to use this feature in your network.

Integration
DO NOT REPRINT
© FORTINET
Zero-touch provisioning allows you to provision and configure FortiGate and FortiAP devices automatically.
Rather than using the CLI to configure devices one at a time, administrators can use the Fortinet FortiDeploy
feature to configure all devices simultaneously and to manage all of those devices with a single click.
You can use this feature only when the FortiGate restarts after a factory reset, or on a new FortiGate device.
To use this feature, FortiGate must have Internet access, and a DHCP server must assign an IP address to the
FortiGate interface.

Integration
DO NOT REPRINT
© FORTINET
FortiDeploy allows administrators to add FortiGate and FortiAP devices in bulk to their FortiGate Cloud or FortiAP
Cloud accounts. From there, the multi-tenancy feature of FortiDeploy allows administrators to select a
configuration template and operating system version (FortiOS) to deploy with the newly added devices.
When you include FortiDeploy on your Fortinet device order, you will receive a bulk deployment FortiCloud key
tied to all supported devices within that order. When you visit your FortiGate Cloud or FortiAP Cloud management
console, you can enter either the key for a single device, or the bulk key for all devices sent with your order.
As devices are plugged in at their respective remote locations, FortiGate automatically obtains an IP address
through DHCP. After network connectivity is established, FortiGate automatically heartbeats to FortiGuard and
establishes a management tunnel. The FortiGate device then receives the preconfigured management
information for these devices. When this process is complete, the devices can be monitored and managed from
the chosen Fortinet management interface.

Integration
DO NOT REPRINT
© FORTINET
You can configure FortiGate with an SD-WAN configuration using zero-touch provisioning with FortiDeploy and
FortiManager.
• Add the FortiGate Cloud key to FortiGate Cloud

• Set up the configuration template with the central management configuration to redirect FortiGate to
FortiManager
• Connect FortiGate to a DHCP server and turn on FortiGate
• FortiGate receives an IP address from the DHCP server and establishes a management tunnel with FortiGate
Cloud
• FortiGate completes zero-touch provisioning by obtaining the central management configuration from
FortiGate Cloud
• FortiGate appears as an unauthorized device in the FortiManager root ADOM
• Authorize FortiGate and assign an SD-WAN template
• Install the SD-WAN configuration on FortiGate
FortiGate is configured with the SD-WAN configuration, without any manual configuration being done on the
FortiGate.

Integration
DO NOT REPRINT
© FORTINET
This feature is useful when FortiGate cannot access the Internet. First, unbox FortiGate and note the serial
number. Register FortiGate to FortiManger using the serial number. After registration, you can add the new
FortiGate to an ADOM, and then configure the device based on your requirements.
After the FortiGate device is registered and configured on FortiManager, connect FortiGate to a DHCP server
configured with option 240 or 241 with FortiManager IP or FQDN. Now, start the FortiGate. After FortiGate starts,
it will be assigned an IP address by the DHCP server and also will be provided with FortiManager information.
FortiGate will use this information to configure central management with the FortiManger IP or FQDN received
from the DHCP server.
Now that the FortiGate device is connected and managed by FortiManager, you can install a specific
configuration on FortiGate.
To prevent spoofing, if a different FortiManager IP comes from the DHCP server later, FortiGate does not change
the central management configuration.

Integration
DO NOT REPRINT
© FORTINET
By mastering the objectives covered in this lesson, you learned how to use FortiManager key features and
architecture, install and configure SD-WAN, and deploy IPSec using VPN manager.

Advanced IPsec
DO NOT REPRINT
© FORTINET
In this lesson, you will learn about IPsec.

Advanced IPsec
DO NOT REPRINT
© FORTINET
After completing this lesson, you should be able to achieve the objectives shown on this slide.
By demonstrating competence in IPsec VPN, you should be able to understand IPsec VPN fundamentals, and
route IPsec VPN traffic for your network.

Advanced IPsec
DO NOT REPRINT
© FORTINET
IPsec is a suite of protocols for authenticating and encrypting traffic between two peers. The two most-used
protocols in the suite are:
• IKE, which does the handshake, tunnel maintenance, and disconnection
• ESP, which ensures data integrity and encryption

Advanced IPsec
DO NOT REPRINT
© FORTINET
IKE negotiates the private keys, authentications, and encryption that FortiGate uses to create an IPsec tunnel.
Security associations (SAs) provide the basis for building security functions into IPsec. There are two distinct
phases that IKE uses: phase 1 uses a single bi-directional SA, and phase 2 uses two IPsec SAs, one for each
traffic direction.

Advanced IPsec
DO NOT REPRINT
© FORTINET
Next, you will review the differences between aggressive mode and main mode. This slide shows main mode,
where six packets are exchanged:
1. The client initiates by proposing the security policies.
2. The responder selects which security policy it will agree to use, and replies.
3. The initiator sends its Diffie Hellman public value.
4. The responder replies with its own Diffie Hellman public value.
5. The initiator sends its peer ID and hash payload.
6. The responder replies with its peer ID and hash payload.

Advanced IPsec
DO NOT REPRINT
© FORTINET
In comparison, this slide shows the aggressive mode negotiation in which only three packets are exchanged:
1. The client initiates by suggesting the security policies, and providing its Diffie Hellman public value and peer
ID.
2. The responder replies with the same information, plus a hash.
3. The initiator sends its hash payload.

Advanced IPsec
DO NOT REPRINT
© FORTINET
Extended authentication (XAuth) can be used as an additional level of authentication. When XAuth is used, one
side must provide credentials (username and password) in order to successfully authenticate.
XAuth happens after the phase 1 is up and before any phase 2 negotiation. That is why XAuth is sometimes
referred to as phase 1.5.
In any XAuth communication, there is always one client and one server. The server sends a CFG_REQUEST
packet, which must be replied to by the client with a CFG_REPLY packet. The CFG_REPLY packet includes the
user credentials. If the authentication is ok, the server sends CFG_SET and the client replies with CFG-ACK.

Advanced IPsec
DO NOT REPRINT
© FORTINET
A FortiGate supports three different methods for automatically configuring the IP settings of IPsec clients: IKE
mode configuration, DHCP over IPsec, and L2TP over IPsec.
This slide shows the IKE mode configuration.
After phase 1 is up, and before the phase 2, the client sends a CFG_REQUEST message listing the required IP
settings (or attributes). The server replies with a CFG_REPLY, which contains the assigned values for each of
the attributes requested.

Advanced IPsec
DO NOT REPRINT
© FORTINET
When the first phase1 IPsec packet arrives, the FortiGate acting as the responder uses the first phase 1
configuration (in alphabetical order) that matches the following:
• Local gateway IP
• Mode (aggressive or main)
• Peer ID, if aggressive mode is used. As explained, only aggressive mode includes the peer ID in the first
packet.
• Authentication method (for pre-shared key and certificates)
• Digital certificate information, if certificates are used as the authentication method
• Proposal
• DH group
However, in some circumstances, FortiOS can switch to a different phase 1, if it finds that it initially selected the
wrong phase 1. This is called gateway revalidation and only applies to the following:
• IKEv1 with certificate authentication

• IKEv2 with pre-shared key authentication
• IKEv2 with certificate authentication

Advanced IPsec
DO NOT REPRINT
© FORTINET
If a FortiGate device has multiple dialup VPNs using pre-shared keys and sharing the same local gateway,
proposal, and DH group, you must use aggressive mode and different peer IDs. Using this method, the FortiGate
identifies the right VPN configuration for each incoming IPsec proposal.

Advanced IPsec
DO NOT REPRINT
© FORTINET
If the IPsec VPN has been configured in interface mode, statics routes are automatically added to clients each
time a dialup IPsec connects. The destination subnets of the static routes are the ones received in the phase 2
quick mode selectors. When IKE mode configuration, or DHCP over IPsec is used, those subnets (with a /32
mask) matched the IP addresses assigned to dialup users.
If you are running a dynamic routing protocol over IPsec, disable add-route. This will prevent FortiGate from
dynamically adding the route, as that is not required because the dynamic routing protocol updates the routing
table once the tunnel is up.
By default, the distance assigned to those dynamic routes is 15, and the priority is 0. You can change those
values in the phase 1 configuration.

Advanced IPsec
DO NOT REPRINT
© FORTINET
When the phase 1 setting add-route is enabled, FortiGate creates separated virtual interfaces for each dial-up
client. This is the default behaviour. The names of those interfaces comprise the phase 1 name and an index
number.
When you use this configuration, FortiGate uses the information in the destination subnets of the quick-mode
selectors to learned the networks behind each remote IPsec client. Each virtual IPsec interface is associated with
one client (or one IKE SA).

Advanced IPsec
DO NOT REPRINT
© FORTINET
If net-device is disabled, FortiGate creates a single IPsec virtual interface that is shared by all IPsec clients
connecting to the same dialup VPN
In this case, the tunnel-search setting determines how FortiGate learns the networks behind each remote
client. If tunnel-search is set to selectors, FortiGate uses, as in the previous case, the destinations subnets of
the quick-mode selectors to populate the routing table with information about the remote networks.
In this scenario, however, there can be multiple clients (or IKE SA) associated with a single interface. FortiGate
needs more information (precisely the tunnel index to each remote network) to route traffic to the clients properly.

Advanced IPsec
DO NOT REPRINT
© FORTINET
You can use the command diagnose vpn tunnel list to display extra routing information.
The output from this command shows the mapping between each remote subnet (learned through quick-mode
selectors) and the phase 1 index that must be used to properly route the traffic to the correct destinations.

Advanced IPsec
DO NOT REPRINT
© FORTINET
If net-device is set to disable, and tunnel-search is set to nexthop, FortiGate does not use the quick-
mode selectors to learn about remote networks. FortiGate will learn those routes with the assistance of a dynamic
routing protocol, which must be configured to run over the IPsec tunnels.

Advanced IPsec
DO NOT REPRINT
© FORTINET
As with tunnel-search set to nexthop, FortiGate creates one single IPsec virtual interface that is shared by
all IPsec clients. FortiGate needs more information about how to route the IPsec traffic through the correct IKE
SA. With this configuration, FortiGate learns the remote IPs for each client through IKE messages. By default,
these remote IPs belong to the IPsec virtual interfaces of the clients. FortiGate combines this information, with the
routes learned through a routing protocol, to properly route the IPsec traffic, selecting the correct outbound IPsec
virtual interface and IKE SA.
The output of the diagnose vpn tunnel list command shows the list of remote IPs and the associated
tunnel indexes.

Advanced IPsec
DO NOT REPRINT
© FORTINET
If two remote sites have the same subnets, they might create overlapping static routes on the central FortiGate.
The setting route-overlap, found in phase 2, defines what action FortiGate will take when a new remote site
is connecting and there is a remote site already connected with an overlapping subnet. The possible actions
include:
• use-new (default): Disconnect the existing dialup VPN and accept the new VPN
• use-old: Keep the existing dialup VPN up and reject the new one
• allow: Keep the existing dialup VPN up and accept the new one. Traffic for sessions that start from the
central FortiGate will be load balanced (ECMP) between both VPNs

Advanced IPsec
DO NOT REPRINT
© FORTINET
Two or more IPsec tunnels between two sites can be combined to create an aggregated tunnel. This is similar to
LACP port aggregation. One single aggregated IPsec interface is created and used for routing and firewall
policing.
Aggregated IPsec tunnels support four load balancing methods:
• round-robin: Traffic is balanced per-packet.

• L3: Traffic is balanced based on the Layer-3 header information
• L4: Traffic is balanced based on the Layer-4 header information
• redundant: All traffic is sent though the tunnel that came up first. The other tunnels are used for backup

Advanced IPsec
DO NOT REPRINT
© FORTINET
Forward Error Correction (FEC) is a phase1 setting that, when enabled, adds additional packets with redundant
data. The recipient can use this redundant information to reconstruct any lost packet, or any packet that arrived
with errors. Although this feature increases the bandwidth usage, it improves reliability that can overcome
adverse WAN conditions such as lossy or noisy links. FEC can be critical for delivering a better user experience
for business-critical applications like voice and video services.

Advanced IPsec
DO NOT REPRINT
© FORTINET
You can use this wizard to automatically set up multiple VPN tunnels to the same destination over multiple
outgoing interfaces for redundancy. The duel VPN wizard includes automatically configuring IPsec, routing, and
firewall settings, avoiding cumbersome and error-prone configuration steps.

Advanced IPsec
DO NOT REPRINT
© FORTINET
By demonstrating competence in OCVPN, you should be able to understand OCVPN requirements and
limitations, and configure OCVPN for your network.

Advanced IPsec
DO NOT REPRINT
© FORTINET
OCVPN is a cloud-based solution that greatly simplifies the user experience for provisioning and setting up IPsec
VPN. When OCVPN is enabled on FortiGate devices that are registered to FortiCare using the same FortiCare
account, IPsec phase 1 and phase 2 configuration, static routes, and firewall policies are generated automatically.
If the network topology on any FortiGate devices in the community experiences changes, such as a change in a
public IP address in DHCP mode, the addition or removal of protected subnets, or a failover in dual WAN, the
IPsec-related configuration for all devices is updated with OCVPN cloud portal assistance in self-learning mode.
No intervention is required.
FortiGate devices supports full mesh and hub-spoke OCVPN. You can also configure hub-spoke OCVPN with
auto discovery VPN (ADVPN).
OCVPN is supported only on FortiOS 6.2.0 or later versions. FortiGate devices must have Internet access and
must be registered on FortiCare using the same FortiCare account. OCVPN is supported only on the root VDOM.

Advanced IPsec
DO NOT REPRINT
© FORTINET
When you log in to the OCVPN portal, the OCVPN license type and device information display. The device
information includes the device serial number, OCVPN role, hostname, public IP address, port number, and
overlays. You can unregister an OCVPN device from the OCVPN portal in the Device section on the right.
Select Diagram to view the OCVPN network topology.

Advanced IPsec
DO NOT REPRINT
© FORTINET
To configure full mesh OCVPN, you must register all the devices under the same FortiCare account. After you
register the device, you can configure OCVPN on the FortiGate device.
On the FortiGate GUI, enable OCVPN, and in the Role field select Spoke. Then create the overlays that you
would like to add to the OCVPN . When you create an overlay, you will specify a name, local subnet(s), and local
interface(s).
Note that the overlay names on each device must be the same for local and remote selector pairs to be
negotiated. Also, the local subnet must be routable and interfaces must have IP addresses.
You can configure how often FortiGate tries to fetch OCVPN-related data from the OCVPN Cloud using the set
poll-interval. By default the interval is 60 minutes; however, you can configure the interval from between 30
minutes to 120 minutes.
After you complete the configuration on all FortiGate devices, the OCVPN cloud automatically updates each
member. Instead of the administrator actively directing and pushing out devices in response to network topology
changes, FortiGate devices uses device polling to propagate changes across nodes in the VPN. State changes
are tracked carefully across the system so that all devices always have the same view of the network. Similarly,
the OCVPN cloud always knows the state of each device.

Advanced IPsec
DO NOT REPRINT
© FORTINET
OCVPN also supports hub-spoke with an ADVPN shortcut. OCVPN automatically detects the network topology
based on members' information.
To configure hub-spoke with an ADVPN shortcut, you will need to select the appropriate role for the devices. At
least one device must announce its role as the primary hub, another device can work as the secondary hub (for
redundancy), while others function as spokes.
If you are configuring a secondary hub, overlays are synced from the primary hub and cannot be defined in the
secondary hub.

Advanced IPsec
DO NOT REPRINT
© FORTINET
By mastering the objectives covered in this lesson, you learned IPsec fundamentals, routing IPsec traffic, and
configuring OCVPN.

Autodiscovery VPN
DO NOT REPRINT
© FORTINET
In this lesson, you will learn about autodiscovery VPN (ADVPN).

Autodiscovery VPN
DO NOT REPRINT
© FORTINET
By demonstrating competence in ADVPN, you will be able to configure ADVPN, troubleshoot ADVPN, and
understand SD-WAN support for ADVPN.

Autodiscovery VPN
DO NOT REPRINT
© FORTINET
Why should you use ADVPN? To find the answer, you will review the most common VPN topologies.
One point-to-multipoint topology variation is called hub-and-spoke. As its name describes, all clients connect
through a central hub, similar to the way spokes connect to hubs on wheels.
In the example shown on this slide, each client—spoke—is a branch-office FortiGate. For any branch office to
reach another branch office, its traffic must pass through the hub.
One advantage of using this topology is that you can easily manage the VPN configuration and firewall policies.
Also, system requirements are minimal for the FortiGate devices that function as branch offices, because each
FortiGate must maintain only one tunnel, or two SAs. In this example, four tunnels, or eight security associations
(SAs), are necessary in the hub.
A disadvantage of using this topology is that communication between branch offices through headquarters (HQ)
is slower than it would be using a direct connection, especially if HQ is physically distant, as it can be for global
companies. For example, if your company’s HQ is in Brazil, and your company also has offices in Japan and
Germany, latency can be significant. Another disadvantage is lack of redundancy. For example, if FortiGate at
HQ fails, the VPN fails company-wide. Also, FortiGate at HQ must be more powerful, because it handles four
tunnels simultaneously, or eight SAs.

Autodiscovery VPN
DO NOT REPRINT
© FORTINET
This slide shows a VPN that has a partial mesh topology. There are two types of mesh topologies, partial mesh
and full mesh.
Partial mesh attempts to compromise, minimizing required resources as well as latency. Partial mesh can be
appropriate if communication is not required between every location. This slide shows additional connections
between Spoke-1 and Spoke-2, and Spoke-3 and Spoke-4 connections. However, each FortiGate’s configuration
is still more complex than hub-and-spoke. Routing, especially, may require extensive planning.

Autodiscovery VPN
DO NOT REPRINT
© FORTINET
This slide shows a VPN that has a full mesh topology.
Full mesh connects every location to every other location. Like the previous hub-and-spoke example, the
example on this slide shows only five locations. In order to fully interconnect, each FortiGate needs four VPN
tunnels, or eight SAs, to the other FortiGate devices. This equals three more tunnels for each spoke FortiGate. In
total, 10 tunnels are needed. If your company were to expand to six locations, it would require 15 tunnels. Seven
locations would need 21 tunnels, and so on. You can use the formula N sites = N (N-1) / 2 to calculate
the number of tunnels. This topology causes less latency and requires much less HQ bandwidth than hub-and-
spoke. Its disadvantages? Every spoke FortiGate must be more powerful. Additionally, both administration and
troubleshooting get more complicated.
So, in general, if your company has many locations, hub-and-spoke will be cheaper, but slower, than a mesh
topology. Mesh toplogies place less strain on the central location and can be more fault-tolerant, but are also
more expensive.

Autodiscovery VPN
DO NOT REPRINT
© FORTINET
ADVPN was introduced in FortiOS 5.4. It combines the benefits of hub-and-spoke and full-mesh topologies
because all the spoke-to-spoke tunnels are dynamically created on demand. After a shortcut tunnel is established
between two spokes and routing has converged, spoke-to-spoke traffic no longer needs to flow through the hub.
ADVPN provides direct connectivity.

Autodiscovery VPN
DO NOT REPRINT
© FORTINET
• ADVPN supports single or multiple hub architectures

• NAT is supported for the on-demand tunnels, as long as one of the spokes is not behind NAT
• ADVPN requires the use of a routing protocol
• Currently, it supports BGP and RIPv2/RIPng
• It also supports PIM and multicast
• Both IPv4 and IPv6 are supported

Autodiscovery VPN
DO NOT REPRINT
© FORTINET
This slide shows an example of how ADVPN works.
An administrator configures IPsec VPNs in multiple FortiGate devices to form VPN hub-and-spoke topologies. In
this example, there are two hubs. Hub 1 has three spokes. Hub 2 has two spokes. There is also a VPN
connecting both hubs.
The dynamic tunnels between spokes are created on demand. Say that a user in Boston sends traffic to London.
Initially, the direct tunnel between Boston and London has not been negotiated. So, the first packets from Boston
to London are routed through Hub 1 and Hub 2. When Hub 1 receives those packets, it knows that ADVPN is
enabled in all the VPNs all the way to London because of auto-discovery-sender enable settings. So,
Hub 1 sends an IKE message to Boston informing it that it can try to negotiate a direct connection to London. On
receipt of this IKE message, Boston creates a FortiOS-specific IKE information message that contains its public
IP address, its local subnet, the desired destination subnet (London's subnet), and an auto-generated PSK
(alternatively, it can also use digital certificate authentication). This IKE message is sent to London through Hub 1
and Hub 2. When London receives the IKE message from Boston, it stores the PSK and replies with another IKE
information message that contains London's public IP address. After the reply arrives in Boston, the dynamic
tunnel is negotiated between both peers. The negotiation succeeds because London is expecting a connection
attempt from Boston's public IP address. You will explore this in greater detail in the next few slides.

Autodiscovery VPN
DO NOT REPRINT
© FORTINET
Now, you will examine the IKE messages that are exchanged when an on-demand tunnel is being negotiated:
1. The client behind Spoke-1 generates traffic for devices located on Spoke-2’s network.
2. Spoke-1 receives the packet, encrypts it, and sends it to the Hub.
3. The Hub receives the packet from Spoke-1 and forwards it to Spoke-2.
4. Spoke-2 receives the packet, decrypts it, and forwards it to the destination device.
5. The Hub knows that a more direct tunnel option might be available from Spoke-1 to Spoke-2. The Hub sends
a shortcut offer message to Spoke-1.
6. Spoke-1 acknowledges the shortcut offer by sending a shortcut query to the Hub.
7. The Hub forwards the shortcut query message to Spoke-2.
8. Spoke-2 acknowledges the shortcut query and sends a shortcut reply to the Hub.
9. The Hub forwards the shortcut reply to Spoke-1.
10. Spoke 1 and Spoke 2 initiate the tunnel IKE negotiation.

Autodiscovery VPN
DO NOT REPRINT
© FORTINET
As mentioned earlier, ADVPN requires the use of a dynamic routing protocol. In the next slides, you will learn
how to configure ADVPN with IBGP.
As an example, you will use an IBGP topology made up of one hub with two spokes. All the devices are in the AS
65100.

Autodiscovery VPN
DO NOT REPRINT
© FORTINET
This slide shows the following ADVPN configuration in the hub:

• Disable set add-route to ensure that dynamic routing is used for learning the spokes’ protected subnets.
• Set tunnel-search to nexthop, to ensure the next-hop IP of the route matched by a packet is used to
decide into which tunnel the packet must be sent.
• Disable set net-device to ensure FortiGate does not create a dynamic interface.
• You must enable set auto-discovery-sender if you want ADVPN. This setting indicates that when
IPsec traffic transits the hub, it should send a shortcut offer to the initiator of the traffic to indicate that it could
perhaps establish a more direct connection (shortcut).
• Assign an overlay IP address to the IPsec virtual interface. This is a requirement for having a dynamic routing
protocol over IPsec.
• The overlay IPs of all hub-and-spoke participants are in the same subnet.
• For the remote-ip, you can use an unused IP from the overlay subnet. You will need to add the appropriate
subnet based on the number of hub and spokes.
• For the phase-2 configuration, ensure that quick modes are set to all (0.0.0.0/0.0.0.0).
• Set a firewall policy to allow the traffic from the spokes to the hub, from the hub to the spokes, and between
spokes through the hub.

Autodiscovery VPN
DO NOT REPRINT
© FORTINET
This slide shows the following ADVPN configuration in a spoke:

• Enable ADVPN with the command auto-discovery-receiver. Use this command to indicate that this
IPsec tunnel wants to participate in an auto-discovery VPN (that is, receive a SHORTCUT-OFFER).
• Assign an interface IP, remote IP, and subnet to the IPsec virtual interface.

Autodiscovery VPN
DO NOT REPRINT
© FORTINET
This slide shows the following IBGP configuration in the hub:

• Configure a BGP neighbor group. All the spokes are part of it.
• Create a neighbor range with a prefix that includes all the spokes. In this way, you don’t need to define each
spoke individually as a neighbor.
• If you are using IBGP for ADVPN, you must configure the hub as a route reflector. So, routes learned from one
spoke are forwarded to the other spokes.
• Add the local network(s) behind the hub to be advertised over BGP.

Autodiscovery VPN
DO NOT REPRINT
© FORTINET
This slide shows the following IBGP configuration in one of the spokes:
• Configure the hub as a BGP neighbor
• Define the internal network that will be advertised over the BGP

Autodiscovery VPN
DO NOT REPRINT
© FORTINET
If you are configuring ADVPN on FortiManager using the VPN manager, remember the following:
• Set the protected networks to all
• Use scripts to enable ADVPN in phase 1
• Disable the option Add Route on the hub
• Configure IP addresses on the IPsec virtual interfaces
• Configure dynamic routing. If you are using IBGP, use a script to enable route reflector on the hub.
• It is important to know that when creating phase1 using a FortiManager VPN console, the phase1 name is
created with an underscore and a zero (phase1name_0). For example, a phase1 named VPN will be created
as VPN_0.

Autodiscovery VPN
DO NOT REPRINT
© FORTINET
The configuration of the Protected Subnet is under All VPN Communities.

Autodiscovery VPN
DO NOT REPRINT
© FORTINET
For ADVPN, turn off the Add Route switch under the VPN gateway configuration of the hub.
This prevents the hub from adding routes based on IKE negotiations. For that purpose, ADVPN uses a dynamic
routing protocol instead.

Autodiscovery VPN
DO NOT REPRINT
© FORTINET
After the tunnels between the hub and the spokes come up, you can run the following commands in the spokes to
verify that routing updates are taking place:
get router info bgp network
get router info routing-table all
This slide shows that Spoke-1 learned the routes to the hubs and to the networks of Spoke-2, through BGP.
Spoke-2 is currently accessible through the hub.

Autodiscovery VPN
DO NOT REPRINT
© FORTINET
You can specify multiple IP addresses when debugging IKE. This is very useful when debugging ADVPN
shortcuts and spoke-to-spoke ADVPN negotiation issues.

Autodiscovery VPN
DO NOT REPRINT
© FORTINET
If you run the IKE real-time debug during the negotiation of an ADVPN tunnel, you will see the exchange of all
shortcuts. This slide shows an example of the output of the real-time debug. You can see that the Spoke-1
receives an OFFER from the Hub because of the data traffic from Spoke-1 to Spoke-2.
Spoke-1 sends a shortcut-query to Spoke-2 and the Hub receives this shortcut-query and forwards it to
Spoke-2.

Autodiscovery VPN
DO NOT REPRINT
© FORTINET
In the example shown on this slide, Spoke-2 receives the shortcut-query and sends a shortcut-reply to
Spoke-1.
Hub receives the shortcut-reply and forwards it to Spoke-1.

Autodiscovery VPN
DO NOT REPRINT
© FORTINET
Finally, Spoke-1 receives the reply message and initiates a shortcut negotiation directly with Spoke-2, and the
dynamic tunnel interface is created.

Autodiscovery VPN
DO NOT REPRINT
© FORTINET
Using the get ipsec tunnel list command, you can verify which on-demand tunnels are up. It is
important to note that on-demand tunnels remain active until their SAs are manually flushed, or until they time
out.

Autodiscovery VPN
DO NOT REPRINT
© FORTINET
This slide shows the routing table after the on-demand tunnel is up.
You can confirm that the network of Spoke-2 is directly accessible using the on-demand tunnel: H2S_0_0.

Autodiscovery VPN
DO NOT REPRINT
© FORTINET
In FortiOS 6.2.1and later, SD-WAN now supports ADVPN. Before this feature, SD-WAN can only use static VPNs
as a member and the shortcut tunnels were not supported through SD-WAN.
With this feature, SD-WAN is able to use SDVPN dynamic spoke-to-spoke shortcut tunnels. This feature allows
SD-WAN to combine a dynamic shortcut tunnel between spokes and the static tunnel to the hub. When the static
tunnel to the hub is referred to in the SD-WAN rules, the rules will add a dynamic shortcut tunnel automatically
when a shortcut tunnel is established, and the traffic between spokes will travel through the shortcut tunnel.

Autodiscovery VPN
DO NOT REPRINT
© FORTINET
As shown on this slide, you can see the comparison between routing tables and service information for the
ADVPN before and after the shortcut tunnel has been established. You can verify that the SD-WAN rule
automatically adds the shortcut tunnel as a sub-interface of the static tunnel.

Autodiscovery VPN
DO NOT REPRINT
© FORTINET
SD-WAN rules can use BGP learned routes as dynamic destinations. You can accept a route that matches a
community and set a tag to the routes. These tags can be used as dynamic destinations in the SD-WAN rules.

Autodiscovery VPN
DO NOT REPRINT
© FORTINET
You can see the routes being advertised as matching community 1:2 are tagged with 15. These routes are
automatically added to the SD-WAN rule setup to match the dynamic destination matching route tag 15.

Autodiscovery VPN
DO NOT REPRINT
© FORTINET
By mastering the objectives covered in this lesson, you learned how to configure ADVPN with iBGP, test ADVPN,
troubleshoot using debug commands, and understand SD-WAN support for ADVPN.

Solution Slides
DO NOT REPRINT
© FORTINET
These slides contain the solutions to the troubleshooting exercises.

Solution Slides
DO NOT REPRINT
© FORTINET
Now, we will look at the solutions for the troubleshooting exercise in the traffic and session monitoring lab.

Solution Slides
DO NOT REPRINT
© FORTINET
There are two problems:

• NGFW-1 is configured with SD-WAN with members port1 and port2, yet traffic is only going out from port1.
• On NGFW-1, SD-WAN rules is in place to route traffic destined to 8.8.8.8 to port1, still the traffic is going
out to port2 only.

Solution Slides
DO NOT REPRINT
© FORTINET
In the first problem, there is only one route in the routing table for port1. There isn’t any route added for port2.
After verifying the static route you will see there is no default route is created using SD-WAN.

Solution Slides
DO NOT REPRINT
© FORTINET
There was no default route for SD-WAN created on the firewall. As a result it was only routing traffic through
port1 as that was the only possible route out to the Internet.
To resolve the issue, delete the existing static route and create a default route for SD-WAN.

Solution Slides
DO NOT REPRINT
© FORTINET
For the second problem, the debug flow indicated traffic is matching a policy route. However, the SD-WAN
policy route is configured to route the traffic out to port2.
Checking the proute list shows there are two policy routes for traffic destined to 8.8.8.8 and FortiGate is
selecting regular policy route over SD-WAN route.

Solution Slides
DO NOT REPRINT
© FORTINET
Regular policy route always has higher priority than SD-WAN policy route. As a result, traffic destined to
8.8.8.8 was being routed through port1.

DO NOT REPRINT
© FORTINET
No part of this publication may be reproduced in any form or by any means or used to make any
derivative such as translation, transformation, or adaptation without permission from Fortinet Inc.,
as stipulated by the United States Copyright Act of 1976.
Copyright© 2019 Fortinet, Inc. All rights reserved. Fortinet®, FortiGate®, FortiCare® and FortiGuard®, and certain other marks are registered trademarks of Fortinet,
Inc., in the U.S. and other jurisdictions, and other Fortinet names herein may also be registered and/or common law trademarks of Fortinet. All other product or company
names may be trademarks of their respective owners. Performance and other metrics contained herein were attained in internal lab tests under ideal conditions, and
actual performance and other results may vary. Network variables, different network environments and other conditions may affect performance results. Nothing herein
represents any binding commitment by Fortinet, and Fortinet disclaims all warranties, whether express or implied, except to the extent Fortinet enters a binding written
contract, signed by Fortinet’s General Counsel, with a purchaser that expressly warrants that the identified product will perform according to certain expressly-identified
performance metrics and, in such event, only the specific performance metrics expressly identified in such binding written contract shall be binding on Fortinet. For
absolute clarity, any such warranty will be limited to performance in the same ideal conditions as in Fortinet’s internal lab tests. In no event does Fortinet make any
commitment related to future deliverables, features, or development, and circumstances may change such that any forward-looking statements herein are not accurate.
Fortinet disclaims in full any covenants, representations,and guarantees pursuant hereto, whether express or implied. Fortinet reserves the right to change, modify,
transfer, or otherwise revise this publication without notice, and the most current version of the publication shall be applicable.

SD-WAN 6.2 Study Guide-Online

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SD-WAN 6.2 Study Guide-Online

Uploaded by

Copyright:

Available Formats

DO NOT REPRINT

SD-WAN Study Guide

Fortinet Network Security Expert Program (NSE)

In this lesson, you will learn about SD-WAN.

SD-WAN 6.2 Study Guide 4

SD-WAN 6.2 Study Guide 5

To understand SD-WAN, we will take an example of a road trip.

Everyone loves a good road trip, enjoying relaxed, transit-free travel.

SD-WAN 6.2 Study Guide 6

But no one likes congestion or bad road quality.

SD-WAN 6.2 Study Guide 7

SD-WAN 6.2 Study Guide 8

SD-WAN 6.2 Study Guide 9

SD-WAN 6.2 Study Guide 10

SD-WAN 6.2 Study Guide 11

SD-WAN 6.2 Study Guide 12

SD-WAN 6.2 Study Guide 13

SD-WAN 6.2 Study Guide 14

SD-WAN 6.2 Study Guide 15

SD-WAN 6.2 Study Guide 16

SD-WAN 6.2 Study Guide 17

SD-WAN 6.2 Study Guide 18

SD-WAN 6.2 Study Guide 19

SD-WAN 6.2 Study Guide 20

SD-WAN 6.2 Study Guide 21

SD-WAN 6.2 Study Guide 22

SD-WAN 6.2 Study Guide 23

SD-WAN 6.2 Study Guide 24

SD-WAN 6.2 Study Guide 25

SD-WAN 6.2 Study Guide 26

SD-WAN 6.2 Study Guide 27

SD-WAN 6.2 Study Guide 28

SD-WAN 6.2 Study Guide 29

SD-WAN 6.2 Study Guide 30

SD-WAN 6.2 Study Guide 31

SD-WAN 6.2 Study Guide 32

SD-WAN 6.2 Study Guide 33

SD-WAN 6.2 Study Guide 34

SD-WAN 6.2 Study Guide 35

SD-WAN 6.2 Study Guide 36

SD-WAN 6.2 Study Guide 37

SD-WAN 6.2 Study Guide 38

SD-WAN 6.2 Study Guide 39

SD-WAN 6.2 Study Guide 40

SD-WAN 6.2 Study Guide 41

SD-WAN 6.2 Study Guide 42

SD-WAN 6.2 Study Guide 43

SD-WAN 6.2 Study Guide 44

SD-WAN 6.2 Study Guide 45

SD-WAN 6.2 Study Guide 46

SD-WAN 6.2 Study Guide 47

• Routing information is flushed from the session table

SD-WAN 6.2 Study Guide 48

SD-WAN 6.2 Study Guide 49

SD-WAN 6.2 Study Guide 50

SD-WAN 6.2 Study Guide 51

SD-WAN 6.2 Study Guide 52

SD-WAN 6.2 Study Guide 53

SD-WAN 6.2 Study Guide 54

SD-WAN 6.2 Study Guide 55

SD-WAN 6.2 Study Guide 56

SD-WAN 6.2 Study Guide 57

SD-WAN 6.2 Study Guide 58

SD-WAN 6.2 Study Guide 59