Student Guide

Aruba Accredited SD-WAN Expert

Study Guide
version 9.2, revision 1.1
AASX Study Guide Page 2

© Copyright 2023 Hewlett Packard Enterprise Development LP

The information contained herein is subject to change without notice. The only warranties for HPE products and services
are set forth in the express warranty statements accompanying such products and services. Nothing herein should be
construed as constituting an additional warranty. Hewlett Packard Enterprise shall not be liable for technical or editorial
errors or omissions contained herein.

This is an HPE copyrighted work that may not be reproduced without the written permission of Hewlett Packard
Enterprise. You may not use these materials to deliver training to any person outside of your organization without the
written permission of HPE.

Printed in the US

Aruba Accredited SD-WAN Expert Study Guide

August 2023
AASX Study Guide Page 3

Contents
Introduction........................................................................................................................................................................................................................................................................................................... 4
Path & Route Selection............................................................................................................................................................................................................................................................................. 6
Policies .................................................................................................................................................................................................................................................................................................................... 12
Loopback Interfaces & Orchestration................................................................................................................................................................................................................................... 16
Packet Classification & Internet Breakout........................................................................................................................................................................................................................ 18
IP SLA ...................................................................................................................................................................................................................................................................................................................... 21
LACP: Link Aggregation Control Protocol ...................................................................................................................................................................................................................... 24
OSPF: Open Shortest Path First.................................................................................................................................................................................................................................................. 28
BGP: Border Gateway Protocol .................................................................................................................................................................................................................................................... 33
BFD: Bidirectional Forwarding Detection.......................................................................................................................................................................................................................... 39
Route Maps ....................................................................................................................................................................................................................................................................................................... 42
Regional Routing & Hub Behavior........................................................................................................................................................................................................................................... 47
Flow Redirection .......................................................................................................................................................................................................................................................................................... 53
Additional Security Features .......................................................................................................................................................................................................................................................... 56
Zone Based Firewall ................................................................................................................................................................................................................................................................................. 59
Routing Segmentation (VRF)........................................................................................................................................................................................................................................................ 68
QoS: Quality of Service .......................................................................................................................................................................................................................................................................... 73
Intrusion Detection & Prevention ............................................................................................................................................................................................................................................. 78
AASX Study Guide Page 4

Introduction
Advanced SD-WAN Deployments
Welcome to the Advanced Aruba SD-WAN Deployments course. This course is based on the 9.2 versions of
Orchestrator and ECOS. It provides information that builds upon the fundamentals you learned from the Deploying
Aruba SD-WAN Technologies course.
The modules in this student guide correspond with the course’s presentation slides. You can note the title of a slide
the instructor presents and then match it with the corresponding header. Some sections of this student guide
include images for reference purposes when appropriate.

This Is an Advanced Course

This is the second course in our technical training series. You need to complete the Deploying Aruba SD-WAN
Technologies course to have the necessary knowledge and experience for this course.

AASX Assessment Overview

You can enroll in the assessment at this URL:
https://inter.viewcentral.com/events/cust/cust_tracks.aspx?company_login_id=aruba&pid=1&track_id=43
The AASX assessment has 40 multiple-choice questions, a 1-hour time limit, is open-book, and has a minimum
passing score of 70%. If you do not pass the assessment twice, you must wait 1 week before your next attempt.

Objectives
These are the objectives for this course:
• Understand how EdgeConnect SD-WAN appliances make data forwarding decisions.
• Explain the parts of BIO-created policies, how they are arranged in policy maps, and to consider manual
policies.
• Configure Flow Redirection on appliances to avoid asymmetry in Traditional HA environments.
• Explain the configuration of Link Aggregation Control Protocol (LACP), Bidirectional Forwarding Detection
(BFD), and IP SLAs.
• Work with hands-on labs for Loopback Orchestration, OSPF, BGP, Zone Based Firewall, Routing
Segmentation (VRF), and Regional Routing.

Agenda: Instructor-led Version

During this course, you will learn about these topics:
• Introduction • Loopback Interfaces & Orchestration
• Path & Route Selection • Packet Classification and Internet Breakout
• Policies • Link Aggregation Control Protocol
AASX Study Guide Page 7

• OSPF – Open Shortest Path First • Zone Based Firewall

• Bidirectional Forwarding Detection • Flow Redirection
• BGP – Border Gateway Protocol • Routing Segmentation (VRF)
• IP SLA • Quality of Service
• Route Maps • Intrusion Detection & Prevention
• Regional Routing & Hub Behavior • Cool Tips & Last Things
• Additional Security Features

Instructor-led Attendance Criteria

To be marked Complete for an instructor-led class, you must attend the lectures, participate in the discussions,
and complete the labs. If in the opinion of the instructor, the student fails to meet these requirements, the
instructor marks the student as Not Complete. If this happens, you have three options:
• Complete the course’s eLearning version. If you choose this option, do not redeem your lab voucher
unless you have about 6 hours total to complete the labs within 24 hours.
• Repeat the entire instructor-led course.
• Send an email to [email protected] to appeal the decision.

AASD: Lab Topology

You can find a diagram of the lab in the lab topology PDF file, the lab guide, and on the Landing Desktop
computer of your ReadyTech lab.
Student Guide Page 6

Path & Route Selection

EdgeConnect Appliances Route Traffic Inline
As Router Mode implies, an
EdgeConnect SD-WAN
appliance can forward a
packet between its local
interfaces if it knows which
one reaches the destination
network. The appliance can
learn this information in one of
the following ways:
• Locally connected
subnet
• Dynamic routing
protocol: SD-WAN
fabric subnet sharing,
BGP-4, or OSPF
• Static routing
Subnet sharing is a proprietary
routing protocol between
EdgeConnect appliances. It
exchanges information about
locally attached subnets. Appliances can also use BGP and OSPF to advertise routes to third-party routers and
learn routes from them. By advertising these routes with a preferred metric, the appliance becomes the best
next-hop to reach the destination through the SD-WAN fabric.
Auto (System) in the Type field of the Routes tab indicates a locally attached subnet that’s been automatically
added by EdgeConnect. It’s also possible for the appliances to redistribute between routes learned via subnet
sharing, BGP, and OSPF.

Path Selection Order

This is how an EdgeConnect SD-WAN appliance uses its routes
table to forward traffic:
1. Longest matching route prefix: The route prefix with the
longest subnet mask has priority (e.g. /30 versus /24).
2. Administrative distance: The lowest administrative
distance has priority (e.g. AD 10 versus AD 110). Use the
built-in help function to learn more about administrative
distance values.
3. Route metric: The lowest route metric has priority (e.g. 50
versus 70).
4. Peer Priority: The lowest peer priority has priority (e.g. 10
versus 20). This is an optional configuration setting you
must configure for the appliance to use it.
5. Random selection: If the previous criteria are all equal, the
appliance randomly selects which matching route it uses.
Student Guide Page 7

Built-in Help
When you work with a feature, you
can click the blue circle with a
question mark in the center to view built-in
help information that opens in a separate web
browser window.

Route Tags
The routes table of an EdgeConnect can apply routes
that affect which routes it uses:
• Any (No tag): It uses the route in either
direction.
• FROM_LAN: It only uses the route for traffic that
entered from a LAN interface.
• FROM_WAN: It only uses the route for traffic that
entered from a WAN interface.
Student Guide Page 8

Find Preferred Route

Find Preferred Route is a button on an appliance’s Routes tab. You can enter a destination IP address or
subnet and make other
selections in this tool.
The tool references its
own data path routes
table. Its output lists
what the appliance
considers the best
path to that
destination. It does this
for SD-WAN and
passthrough traffic. If
your SD-WAN has
multiple equal-cost
routes to a destination,
the tool can list
different outputs each
time you use it.

Advertise-only Route
An EdgeConnect considers any static route you configure without a next-hop IP address to be an advertise-
only route. EdgeConnect doesn’t use this static route to forward traffic. It uses its other default routes, or more
specific routes, to make routing decisions. EdgeConnect advertises this advertise-only static route via subnet
sharing to EdgeConnect peers, or by redistributing it into BGP or OSPF advertisements to third-party peers, to
attract traffic. These remote peers use this advertised route for their own routing decisions.
As an example, the top appliance represents a hub site that advertises a default
route to the spoke Edge Connect in the center. The spoke EdgeConnect
advertises this default route to the LAN-side router at the bottom. If traffic from
the users at the bottom needs to reach the hub site or the internet, this default route
attracts traffic to the spoke EdgeConnect in the center. The spoke
EdgeConnect then forwards the traffic to the hub site which performs local
internet breakout. However, if all connections to the hub site go down, the
default route advertised by the hub would be lost. Local internet
breakout from the hub appliance would fail because the LAN-side
router would also lose this default route.
You can solve this problem by configuring an advertise-only static
route. The spoke EdgeConnect advertises it to attract traffic. The
spoke EdgeConnect could use any routes learned from a service
provider’s next-hop router for routing decisions. The spoke
EdgeConnect would
then perform local
internet breakout for
users at the local
site, even though
they lost
connectivity to the
hub site. However, if
you do this, you
Student Guide Page 9

should use a route map to prevent the spoke site from advertising the advertise-only default route into the
SD-WAN fabric.

Flow Table Filters

The current flow table includes many filters. In the upper-left section, you can filter by IP address, layer-4 port
number, application, application group, role, and user name. In the upper-middle section, you can filter by
firewall zone, VLAN, DSCP value, protocol, or domain. In the upper-right section, you can filter by overlay,
transport, and flow characteristics. The table also has a drop-down list of preset filter settings in the center. You
can create and add your filters to this list.
Be aware of the Active and Ended filters. You might be looking at a flow that has already ended if you click the
Ended button and it’s highlighted. You can use this button to display flows that ended during the past few
minutes. The default is flows from the last 5 minutes, but you can go back further.
In the outlined area of the lower-left section the Flows tab lists counts for distinct types of flows. You can use
these flow counts to determine if passthrough, asymmetric, or dropped flows are included in the table.

Flow Table Best Practice

Follow these best practices when you use the flows table:
1. Clear existing filters.
2. Select applicable filter options.
3. Click the Refresh icon to display the results.
4. If you cannot see a flow, clear the filters.
Student Guide Page 10

Flow Reset Selections

Stale flows are flows that were established before you made a policy or network change that might still be
operating under the previous rules. By resetting a flow, you make the EdgeConnect end it. When the appliance
re-establishes the flow, it will operate under the new rules. This is disruptive but sometimes necessary when
you make changes to the network.
If you need to reset flows, we recommend you do so during a scheduled maintenance period. There are three
options possible when resetting flows:
• Reset All: Resets all the flows.
• Reset Returned: Resets all flows that are shown after you apply a filter. If you do not set a filter, it
resets all flows.
• Reset Selected: Resets a flow or flows that you click on in the list of returned flows.

Traffic Directionality: Inbound vs. Outbound

Unlike a traditional switch or
router, EdgeConnect has definite
LAN and WAN interfaces. When
you see charts, graphs, or tables
that refer to traffic flows, think of
them from the perspective of the
EdgeConnect appliance, not the
individual interfaces. Outbound
traffic always flows from the LAN
side to the WAN side. Inbound
traffic allows flows from the
WAN side to the LAN side.
• Outbound LAN: Light blue in color. Traffic from the LAN to the appliance.
• Outbound WAN: Dark blue in color. Traffic from the appliance to the WAN.
• Inbound WAN: Dark blue in color. Traffic from the WAN to the appliance.
• Inbound LAN: Light blue in color. Traffic from the appliance to the LAN.
Student Guide Page 11

Orchestrator Reachability in a NAT Environment

Since many companies have multiple service providers to different
networks, and the internal IP address of the Orchestrator might
have NAT applied to it, the appliances need to know which
external IP addresses to use to connect to the Orchestrator. On the
Administration menu of the Orchestrator, you can define these
external IP addresses. Each WAN interface have uses NAT should
have a fixed 1:1 NAT IP address so it will not change.
Student Guide Page 12

Policies
Business Intent Overlays (BIOs) Create Four Types of Policies
Business Intent Overlays create four types of policies:
• Route policies: They determine how the EdgeConnect forwards
matching traffic to its destination using an overlay tunnel.
• Optimization policies: They determine whether EdgeConnect
applies Boost to matching traffic.
• QoS policies: They determine into which traffic close the
EdgeConnect puts matching traffic and what the LAN and WAN
DSCP markings are.
• Security policies: The EdgeConnect has two implicit security policies for intra-zone traffic and
interzone traffic. Intra-zone traffic is within the same firewall zone and is permitted by default.
Interzone traffic is between two different firewall zones and is denied by default.
An EdgeConnect organizes each type of policy into a logical group called a map. So, it has a route map, a QoS
map, an optimization map, and a security map. The route map is a logical container for route policies. It is not
the feature you use to control the redistribution of routes between routing protocols.

Policy Rules Have Priority, Match Criteria, & Action

Policies are logical objects that contain rules and have these components:
• Priority: The numeric order in which EdgeConnect evaluates each rule in a policy. It starts with the
lowest value and continues until it reaches the highest value. The default policy in each policy map has
a value of 65535. These are the ranges for priorities:
o 1-999: User-created manual policies you can define as an exception to automatic, Business
Intent Overlay-created policies.
o 1000-9999: Orchestrator-created rules from a template group.
o 10000+: Orchestrator-created optimization (i.e. Boost) policies based on your
o 20000-24999: Orchestrator-created rules based on the Business Intent Overlays.
o 25000-65499: User-created manual policies you can define as an exception to automatic,
Business Intent Overlay-created policies.
o 65500-65534: Already used for built-in policies.
o 65535: The default rule in each policy map. The default route policy forwards passthrough
traffic from the wan0 interface.
• Match Criteria: The traffic that matches the policy. It can include applications, application groups, IP
addresses, and other criteria.
• Set Actions: What the EdgeConnect does with the matching traffic. The set actions differ for each type
of policy.
Student Guide Page 13

BIO Configuration Causes Orchestrator to Configure Policies

When you configure a
Business Intent Overlay,
Orchestrator creates
policies, like the route
policies shown here, that
it pushes to the
EdgeConnect appliances.
Each of these policies
has a priority number,
match criteria, and set
actions. The set actions indicate what the appliance does with matching traffic. In addition to these policies,
every policy map has a default policy with a priority of 65535.

Route Policies Automatically Created

An appliance’s route policies control how matching traffic gets to its destination. This is what a route policy
table on an appliance looks like. This software version has two route policies for each overlay. Processing
resources is the reason for the two sets of policies. The appliance uses the bottom set when it performs ACL
matching for a new flow. The appliance uses the top set when it receives matching traffic in an overlay tunnel
from another site.
Therefore, the
appliance already
knows the overlay to
use, and it only needs
to determine the link
bonding policy and
optimization to apply
to the flow.

Manual Route Policies

You only need to define manual
route policies for exception traffic,
that cannot otherwise be handled
with the other traffic by the
Business Intent Overlays . An
example of this would be traffic
that you always want to drop, like
preventing your users from
accessing gambling websites.
Student Guide Page 14

QoS Policies
QoS configuration
has two parts, QoS
policies and the
Shaper configuration.
QoS policies
determine into which
Shaper traffic class
an EdgeConnect puts
a packet for
processing. Just like
Business Intent
Overlay-created route and optimization policies, the QoS policy numbering is in the 20000 range and has the
same match criteria. QoS policies have three set actions: a traffic class, the LAN DSCP marking, and the WAN
DSCP marking. The LAN DSCP marking is in the original IP packet’s header. The WAN DSCP marking is in the
encapsulating IP packet’s header. The comments field tells you which Business Intent Overlay created a QoS
policy. The Shaper determines how an EdgeConnect prioritizes traffic and how likely it is to get bandwidth in
the event of congestion.

Boost & Optimization Policies

Optimization Policies control the behavior of Boost related features including Network Memory and TCP
Acceleration. The Orchestrator generally handles this behavior for you using the built-in optimization policies
on the appliances and the Boost option of each Business Intent Overlay. You might occasionally need to create
a manual optimization policy to exclude a certain device or protocol from Boost that matches a Business Intent
Overlay that has Boost enabled.
Optimization policies in the 10000 range are used in conjunction with the Boost option of the Business Intent
Overlays. If you enable Boost, the appliances use these policies to determine Boost for matching traffic.
Student Guide Page 15

Security Policies
Security policies permit or deny communication between firewall zones. An EdgeConnect appliance has two
implicit policies. Intra-zone
communication within the same firewall
zone is always allowed. Interzone
communication between different
firewall zones is denied by default. You
must define specific security policies to
allow traffic initiated in one zone to flow
to the other zone and then back again.
This handy zone matrix display shows
you a quick summary of every firewall
zone. You click the field at the
intersection of a From zone and a To
zone to define the rules of a security
policy.

Built-in Policies
Each appliance has non-editable built-in policies in the
65500+ range that handle internal flows for communication
to the Orchestrator, the Cloud Portal, or for underlying
protocols like BGP or IPsec. You do not usually need to pay
attention to them, but you might occasionally need to look at
them to understand why an appliance handles a flow a
certain way. If you look at a flow detail, and it matched a
policy in the 65500+ range, it’s one of these built-in policies.

Policy Tables in Summary

An EdgeConnect appliance evaluates policies in numeric order. Remember though that built-in policies are
evaluated ahead of
all other types of
policies to ensure
the operation of
routing protocols
and other
communications
protocols.
Student Guide Page 16

Loopback Interfaces & Orchestration

Loopback Interfaces
An EdgeConnect allows you to create loopback interfaces. They are logical interfaces you can use as source or
endpoint of a connection without the worry of physical interface failure. You can give them an IP address and
use them for appliance management instead of the mgmt0 interface.

Loopback Orchestration
It’s possible to automate the creation and management of loopback
interfaces with /32 IP addresses directly from Orchestrator. As you will
see, with a few mouse clicks you can create these on all the devices in
your network. Orchestrator will assign IP addresses to the loopback
interfaces it creates, starting with the lowest available addresses. As we
will see on the next slide, only one pool of addresses can be used.

Configuring Orchestrator
You can only configure one
address pool from which the
Orchestrator can assign IP
addresses to appliances.
However, you can use different
loopback interface groups that
draw from same pool of IP
addresses. In this example, each
appliance you select in the
appliance tree gets two
loopback addresses. They
would each have different interface labels and be in different firewall zones. If you try to edit the pool of IP
addresses on one row, it changes them on every row because you can configure only one IP address pool. For
pre-existing interfaces, this also readdresses all the loopback interfaces the Orchestrator manages.
If you check the Management checkbox when creating a new group, the Orchestrator assigns those loopback
interfaces to manage appliances. So, if you do this, you need to disable the mgmt0 interface to avoid conflicts
with the management loopback interface.
When you remove an EdgeConnect from the Orchestrator, you also remove its assigned loopback interface IP
address. This prevents confusion by network management systems. You can reclaim these IP address to return
them to the global IP address pool for loopback interfaces.
Student Guide Page 17

Operational Notes (1/2)

Loopback interfaces
the Orchestrator
assigns to appliances
start with lo20000.
The 20000 range is
consistent with other
Orchestrator-created
items like policies. You
cannot edit
Orchestrator-created
loopback interfaces on
the appliances and the
addressing is
automatic from the
pool of IP addresses
you define.

Operational Notes (2/2)

From a routing and
advertising
perspective, loopback
interfaces are LAN-
side interfaces. For
example, if you
configure the
appliance to
automatically
advertise all LAN
subnets, it advertises
the /32 loopback IP addresses to peers via subnet sharing.
If you configure a loopback interface to be the management interface for an appliance, it uses the data path
routing table for all traffic including self-originated management traffic.

Loopback Required for DNS Proxy

The DNS proxy feature requires the use of loopback interfaces. It allows the appliance to intercept DNS
lookups for domains you specify and forwards them to the designated servers. DNS lookups for unlisted
domains can be forwarded to alternate servers. Snooping the upstream DNS responses permits caching. This
allows the appliance to
remember the response
and respond locally with
lower latency.
In this example, you
select a loopback
interface label for the
loopback interface, not a
specific loopback
interface number.
Student Guide Page 18

Packet Classification & Internet Breakout

Application-driven Security Policies
Many companies backhaul traffic to the internet from a data center. However, when the connections are for
trusted applications like Office 365 or Salesforce, sending the traffic directly to the internet from each office
can provide better performance with no additional risk. This can also reduce the required bandwidth and cost.
EdgeConnect allows you to instantly identify traffic you want to send to the internet First Packet iQ.

Local Internet Breakout

An IP SLA can detect whether WAN-side interfaces can reach destinations on chosen network connections.
This contains a list of destinations that can be
pinged to detect reachability. If no destinations
are reachable, then breakout is disabled, and
the EdgeConnect performs the next action in
the Preferred Policy Order of the Business
Intent Overlay.
To configure local internet breakout, open the
Breakout Traffic to Internet & Cloud Services
tab in the Business Intent Overlay, and then
click the edit icon. The default destinations
are sp-ipsla.silverpeak.cloud and 8.8.8.8.
Student Guide Page 19

Policy Order is Important!

The order of the policies in the Preferred Policy Order of a Business Intent
Overlay affects the processing of traffic. This example shows the two
different policy orders. On the left, Break Out Locally is positioned above
Backhaul via overlay, and on the right, the policies are in the reverse order.
On the left, the first thing that happens is that traffic is matched against
the list of internal networks we discussed on the previous slide. If it’s not a
match, it’s sent as passthrough traffic using the configured breakout
interfaces.
If the traffic is a match for the internal network list, it’s not broken out locally. It’s sent through an overlay tunnel
to the destination EdgeConnect appliance based on the routes table. If the local breakout interfaces were to fail
based on the IP SLA, then traffic that would have been broken out locally would instead be backhauled
through the overlay. So, backhaul can be seen as a backup function for local breakout.
On the right, the policies are in reverse order. For any traffic entering the overlay, the appliance first does a
routes table lookup. If there is a matching destination subnet or default route, the traffic will be backhauled
through the overlay tunnels to one of the other appliances connected to the overlay. If there is no match in the
route table lookup, or connections to remote appliances were to fail, then non-internal traffic will be broken out
locally. In this case local breakout is a backup to backhaul.
While we covered the two preconfigured options here, it’s also possible to define other policies. For example,
traffic can be broken out to Zscaler or other services.

First-Packet iQ: How Is It Done?

For internet breakout, it’s important to identify the
destination as soon as possible, preferably on the first
packet. The database on each appliance is updated daily.
So, new websites, applications and addresses are
automatically added with no action by the user. Many of
these are pre-grouped into general categories that allow
you to easily classify large amounts of your traffic by adding
a group to an ACL. Additionally, if there are proprietary
applications not covered by the appliance’s database, you
can define your own, by identifying the addresses and port
numbers, and add them to the list with an easily recognized
user-defined name.
Student Guide Page 20

First-Packet iQ: How Is It Done? (Continued)

DNS lookup snooping is another techniques used by EdgeConnect to automatically identify traffic destinations
that might not already be in the database. If an EdgeConnect is in the lookup path, it can snoop DNS traffic,
dynamically identify any unknown addresses associated with a domain, and then add them to its database.
Since many applications in the cloud spin up additional servers on demand around the globe, new addresses
can appear for a given application at any time. This allows an EdgeConnect to correctly classify traffic
connecting to ephemeral IP addresses.

Backhaul Branch Traffic to Internet Through a Data Center

Large networks with small branch offices often backhaul
internet traffic to a hub site, like a data center, for secure
processing. While you could advertise all subnets and sites
to which traffic is allowed individually, this could be very
difficult to manage. So, it’s common to advertise a default
route of all zeros from the data center. This causes the
branch appliances to forward all traffic not matching routes
tables entries to the data center EdgeConnect that
advertised the default routes with the best metrics.
Student Guide Page 21

IP SLA
IP SLA
An IP SLA allows you to initiate triggered actions based on a change in network conditions. There are currently
four IP SLA monitor types available:
• Interface
• Ping
• HTTP/HTTPS
Each IP SLA allows you to configure one action, although it’s easy to initiate multiple actions by simply creating
more than one IP SLA that monitors the same condition. Additionally, you can configure an SLA to only raise
an alarm to notify you. This can be useful if you do not want to make any changes to the network when a
monitored condition changes but want to know it occurred.

Interface Monitor
The interface monitor checks
whether an interface is up or
down every configured interval.
You can monitor the same
interface with multiple instances
with each one configured to
perform a different up or down
action.

Ping Monitor
The ping monitor pings one or more domains or IP addresses for reachability. Enter them in the address list
separated by commas. If any one of the addresses or domains is reachable, then the SLA is marked up and no
action is performed. Only when every address or domain fails to respond to a ping will the IP SLA be marked
down, and the down action performed.
Student Guide Page 22

The available up and down actions for the ping monitor are shown here. They include actions like enabling or
disabling tunnels, disabling subnet advertising, modifying the subnet sharing metric, changing the VRRP
priority, and raising or clearing an alarm.
You can set the ping interval,
which controls how often the
destinations are pinged.
Sampling window is the size of
the rolling window in which
metrics for reachability, loss,
and latency are averaged. For
Reachability, you configure
how many successful or failed
pings are required to mark a
destination up or down. For
loss and latency, thresholds
are configurable. If loss or
latency values are set to 0,
that metric is ignored.
Averaging is done every
second by the IPSLA monitor.
Any action taken, however, is
determined by the Monitor
Sampling Interval.
The Monitor Sampling Interval
determines how quickly higher-level processes like the Business Intent Overlays check whether the IP SLA
condition has changed. A large value results in a delay in responding to a condition change, and a value set too
low can cause unnecessary churn. It’s usually best to set it the same or slightly larger than the Mark Down
value.

HTTP/HTTPS Monitor
The HTTP/HTTPS
monitor uses HTTP
connections on port 80 or
HTTPS connections on
port 443 to test
reachability every
configured interval. This
monitor is useful for sites
that block or limit ICMP
requests.
Student Guide Page 23

VRRP Monitor
The VRRP monitor is useful
with two EdgeConnect
appliances in a high-
availability configuration. It
checks to see if the appliance
is the master or backup of
the VRRP group. If it’s the
master, the IP SLA is marked
up and the up action is
performed. If the appliance is
the backup, the SLA is
marked down, and the down
action is performed.
Depending on your topology,
if a VRRP master is marked
down, it might indicate its
WAN-side destinations are
no longer available, or no
longer the best route to a
destination. This is a way to
dynamically affect network routing preferences.

Sample IP SLA Use Cases

IP SLAs give you the ability to monitor SD-WAN conditions and automatically respond to them. These are
some examples of how you might use IP SLAs.
• Use case 1: interface monitor (HA environment: VRRP used on LAN side)
o WAN interface down  Force VRRP failover to backup EdgeConnect.
o Reason: Do not blackhole traffic because the LAN interface remains up.
• Use case 2: interface monitor (any device advertising LAN-side subnets)
o LAN interface down  Remove local subnets from routes table.
o Reason: Do not send traffic to a device that cannot reach the destination.
• Use case 3: ping failure (local breakout to Zscaler policy on the overlay)
o WAN IP address down  Failover from primary to secondary WAN tunnel.
o Reason: Zscaler GRE tunnels to POP 1 and POP 2.
• Example from the field: VRRP & HA (change advertised subnet sharing metric for faster failover)
o EC 1 is the VRRP master with the default subnet sharing metric of 50. VRRP preemption is
enabled so EC 1 is the master when up.
o EC 2 is the VRRP backup with a subnet sharing metric of 45.
o Configure a VRRP monitor IP SLA on EC 2
 <down action add delta of 10 to subnet sharing metric> This makes the subnet
sharing metric 55—45 + 10—under normal circumstances.
 “Poisoning” is enabled on EC 2. It becomes the preferred SD-WAN path after a VRRP
state change of about 3 seconds.
Student Guide Page 24

LACP: Link Aggregation Control Protocol

Link Aggregation Control Protocol (LACP)
LACP is a mechanism for improving situations when you need to bundle multiple physical
Ethernet interfaces into an aggregated group. It allows us to scale up to throughput higher
than a single physical Ethernet interface. If I have a gigabit interface, and I add another one, I
now have two gigabit interfaces. Depending on the load balancing strategy, this doubles the
amount of bandwidth that I can send between Switch A and Switch B or Switch B and Server 5.
It also has a high availability aspect to it. The appliance will transition rapidly from using more
interfaces to fewer if one or more fail.

LACP Operation
You can configure up to four link aggregation groups (LAGs), or channel groups, that can each have up to four
interfaces. In the Orchestrator Interfaces tab also has an LACP status column that’s intended to be a quick
visual reference you know that the physical interface is up, and the LACP layer is up.

LACP Configuration Options

This is the link aggregation configuration panel. You can then go through the same process that we would use
for a link aggregation group. When you get here, you specify your interfaces, lan0, lan1, and then just check
LACP mode. These are some additional LACP configuration options:
Student Guide Page 25

• LACP rate: slow | fast: This affects the timeout and the rate at which we request the LACP partner to
send LACPDU packets. It is
either slow, one packet per
30 seconds and timeout
after 90 seconds, or fast,
one packet per second and
timeout after 3 seconds.
Slow is the default setting.

• LACP priority: You use

this to break ties with other
peers connecting to the
same LACP partner. When
you have a switch and there
are two different devices
talking to it, the priority
determines which one of
those two LAGs win.

Converting Static LAG to LACP

Follow these steps to convert a static LAG to use LACP:
1. Remove the interface from the bonded interface.
2. Remove the bonded interface from the
Deployment page.
3. Create the bonded interface with LACP
enabled.
4. Assign the bonded interface with LACP
enabled to the Deployment page.

LACP Interface Will Appear on Deployment Page

After you
enable the
bonded
interface with
LACP, you’ll
then have
access to in
the interface dropdown in the Deployment page listed as blan0 or bwan0.

Link Aggregation Interface State Details

You can click the State Details icon to view information about the bonded
interface that can be useful if troubleshooting an issue.
Student Guide Page 26

LACP Port States

The actor is the Edge Connect
appliance, and the partners are
the other LACP devices with
which it communicates
dynamically.

EdgeConnect Enterprise LACP CLI Commands

LACP can operate in three different modes: Active, Passive, and on. EdgeConnect appliances operates in Active
mode.
There are CLI commands, which you could potentially use in broadcast CLI if you really, you feel like you
needed to. , there are not many though. It's straightforward. The main thing to know here is that there are three
different LACP modes that you'll come across: active, passive, and on
CX6200F via Central w/EC LACP – Configuration
This image shows the Link Aggregation configuration page of an Aruba CX6200F via Aruba Central.
Student Guide Page 27

CX6200F via Central w/EC LACP: Configuration

This image shows an example of LACP configuration for a CX6200F switch.

LACP Load Balancing

This shows a representation of 4-tuple load balancing of flows across the interfaces of a bonded interface
configured by LACP. It’s the Layer-3 source/destination hashing. So, if you have several interfaces in the
channel group, how our packets or flows get distributed across those interfaces is to fill them evenly. The
EdgeConnect uses the source destination IP address plus port numbers. Basically each flow ends up on one of
the interfaces in the channel group unless it’s a very large flow. This is not configurable. It’s always flow-based
load balancing, but you can have a different load balancing method configured on the switch.
Student Guide Page 28

OSPF: Open Shortest Path First

What Is OSPF?
OSPF is an interior Gateway Protocol (IGP). EdgeConnect appliances support OSPF v2, which is based on IPV4.
This means that it’s intended to control routing within a single network, not between a network of networks like
the Internet. You need an exterior gateway protocol
(EGP) like BGP for that.
Just like with BGP, a group of OSPF routers in a single
administrative domain is referred to as an autonomous
system. However, because OSPF is an IGP, it has no ASN.
It doesn’t need one because it doesn’t talk directly to
other autonomous systems.
OSPF is a link state protocol. It sends link state
advertisements (LSAs) to its peers. All the LSAs received
by a device are used to construct a logical network
topology, from which the best route to any destination is
derived.

OSPF Can Be Grouped into Areas

OSPF is defined by RFC 2328. It uses port 89
(TCP). It’s intended for use as an Interior
Gateway Protocol (IGP). OSPF always has an
Area 0 that is also known as the Backbone Area.
Within Area 0, different types of Link State
Advertisements (LSAs) are exchanged by OSPF
routers. Link State Updates are used to describe
any changes within an area by other routers as
well and ensure every router has a synchronized
Link State Database (LSDB). OSPF routers
aggregate all LSAs and link state updates
(LSUs) into an LSDB. As such, OSPF dynamically
adapts to network changes, allowing routers to
choose the most efficient routes.

OSPF Areas & Router Types

Dividing the network into areas helps with scalability and efficient routing. It allows routers to focus on local
routing within their respective areas, reducing the amount of routing information they need to process. It also
helps control the size of the routing tables and improves network performance for efficient routing within the
area.
There are different area types and routers within OSPF. We begin with a Backbone Area, which is the core area
of the OSPF network. It is labeled as Area 0. Any router that is part of Area 0 is considered a Backbone Router
Let's add an additional area, like Area 1. If it's not a special area, it’s a standard area. But all areas need to be
connected to the Backbone area and be able to directly communicate with Area 0. Notice Area 1 is connected
Student Guide Page 29

via Router A. This makes Router A an Area Border Router

(ABR). ABRs participate in updates for all areas they have
interfaces in. They have independent copies of LSDBs for
each area.
OSPF routers can also participate in a single area that’s not
the backbone such as Router H. This is known as an
Internal Router. Let’s add a second area with ABR E, a
purple subnet, and purple LSDB. This is also a standard
area. Sometimes, areas cannot be directly connected to the
backbone like the turquoise Area 3, with ABR F but it’s
connected to Area 2. So, we need to connect Router F (An
ABR) to the Backbone with a virtual link to establish
connectivity so Router F can directly communicate with
Area 0 via Router E. Other configuration options can be to
configure an area as a stub, instead of a standard area.
Any router that learns routes from another source, like
static routes or BGP, is considered an Autonomous System Boundary Router (ASBR).

OSPF Configuration

OSPF Appliance Configuration

After turning on the toggle switch to enable OSPF, you must configure a router ID using one of the interface
addresses on the appliance. A mgmt0 interface IP address is used in this example. Next, you must add
interfaces to participate in OSPF by clicking the Add button. You must define the area that each interface is in.
A Default cost of 1 has been used here, but this might need to be changed in your network depending on the
design. Finally, you can control redistribution of external routes from subnet sharing and BGP into OSPF, to be
advertised to OSPF neighbors using the configuration parameters available in OSPF route map.

OSPF Interface Configuration

To participate in OSPF and become fully adjacent to OSPF neighbors, you must enable OSPF on each interface
that you intend to use for this purpose. Click the Add button on the OSPF configuration screen to configure the
interface. You must choose the interface and configure the area ID, although the interface cost might be
Student Guide Page 30

something you need to adjust as needed. It’s possible to

administratively set OSPF up or down on each interface if you need
to do this for deployment staging or troubleshooting.

System Management & Verification – Appliance

OSPF Summary
The OSPF tab in the Orchestrator has three different displays:
Summary, Interfaces and Neighbors, selected by the button at the
top of the tab. The summary shows whether OSPF is enabled for
each appliance, and some high-level details regarding redistribution.
Click the details icon for a given appliance to see information about
timer configuration, whether the machine is advertising and learning
routes, and if so, how many.

OSPF Interfaces
The interfaces display shows information about each interface on each
appliance that’s configured to participate in OSPF, and the state of the
appliance on that interface. In the example shown here, ECV-2 and
ECV-3 are DRs on each of their participating interfaces, but it could be
different on each interface. On any interface, an appliance could be a
BDR, or backup designated router, or simply a neighbor, called a
DROther.
Click the details icon for any interface to see additional information
about timers, the number of neighbors, and the DR and BDR for an
interface.

OSPF Neighbors
The neighbors display shows a list of neighbors for each appliance, and the state of their adjacency. The Full
state indicates that appliances are fully adjacent and can exchange LSAs. .
Student Guide Page 31

Click the details icon to see details about each neighbor, but
most of this information is already displayed in the row for a
neighbor.

OSPF Routes
On the Routes tab is a filter button to only display routes learned via OSPF. The origin of the route and which
appliance it was learned from is in the Type field.
Routes that were learned directly from an OSPF neighbor router by an EdgeConnect running OSPF display a
route metric computed by adding the associated link costs together. These routes have an administrative
distance of 110, the default for routes learned from OSPF.
A route that originated in OSPF as the Type field shows, but has a metric of 51, which has been determined by
the metric set in a route map for OSPF routes redistributed into subnet sharing. We know it was learned via
subnet sharing because the Type field says SP (i.e. Silver Peak) and the administrative distance is 15.
We see some routes that were advertised by two EdgeConnect appliances that are OSPF neighbors. These
routes were redistributed into OSPF from subnet sharing. Because they were learned via OSPF, they carry an
administrative distance of 110. The metrics vary because they originated in different protocols, although the
source protocol information is lost because OSPF doesn’t have a way to propagate it like subnet sharing does.
Student Guide Page 32

Management & Verification of Aruba AOS-CX Router

Aruba AOS-CX Verification Commands

The show ip ospf neighbor
command is useful for viewing
the adjacencies that have been
formed by this router, and on
which interface the connection
has been made.

Show IP Route OSPF

Show IP route shows the routes that will be used by this router to make routing decisions. The routing table
can contain routes
from a variety of
sources, including
OSPF, BGP, and
other routing
protocols. The
notation to the left
of each route
identifies the
source of the
route. This
example contains
OSPF learned
routes, signified by
the ‘O’, and locally
attached routes,
indicated by an ‘L’.
External routes are
indicated by an E1
or E2.
Student Guide Page 33

BGP: Border Gateway Protocol

What is BGP?
BGP, or Border Gateway Protocol, is a routing protocol that allows
routers to exchange network reachability information. With protocols
like OSPF, you create logical groups in which any correctly configured
router can participate. All the group members exchange information
according to certain algorithms. The big difference between BGP and
other routing protocols is that it is policy oriented. With BGP, each
neighbor must be specifically defined on both sides of the connection.
You must specify which routes to advertise to other peer routers, and
to what traffic you forward to them based on learned routes. This is
often negotiated by different companies, like internet service
providers, that connect their networks together to form the internet.

Session Startup – “A” Initiates

This chart shows
how a session is
initiated
between two
BGP peers. The
two statuses you
will see the most
are Active and
Established.
Active means
this device is
trying to start a
session with the
peer. A standard
TCP 3-way handshake is used to start the session. Remember that BGP is transported over TCP and uses port
179. Established means that this device is fully connected to the peer, and they can advertise and receive
routes with each other. If the session is not in Established state, the peers are not able to advertise prefixes to
each other. If you see a session remain in the idle state on EdgeConnect, you probably overlooked the selection
of route maps during peer configuration.

Autonomous Systems
Each group of BGP routers is organized in an autonomous system,
and each system has an autonomous system number, or AS number.
The AS number is how the different AS’s identify themselves to each
other. AS numbers used on the public internet are assigned by a
central authority. Just like with IP addresses, there’s also a set of
private AS numbers you can use internally without restriction on your
network, but these numbers should never be used on an internet
facing connection. We’ll use numbers in that range in this class.
BGP is primarily concerned with the flow of routing information between autonomous systems. Often, within an
AS, another protocol like OSPF or ISIS is used to optimize routing.
Student Guide Page 34

iBGP vs. eBGP (1/2)

One thing that is important to understand is the difference
between iBGP and eBGP. iBGP is internal BGP. It’s concerned with
the exchange of routes between BGP peers within the same
autonomous system. When an iBGP peer learns a route from a
directly connected iBGP peer, it doesn’t readvertise it to other
iBGP peers. It’s assumed that all the iBGP peers are connected in
a full mesh and there is no need to do this. This also helps to
avoid problems with routing loops. For example, if a router that
originated the route was to go down.
eBGP is external BGP. It describes the connections between
routers in different autonomous systems. eBGP peers can
advertise routes to each other regardless of whether they were
learned from an eBGP or iBGP peer. When routes are advertised
between autonomous systems, the ASNs are appended to the
advertisement as the AS Path. If the route is advertised to additional autonomous systems, the AS Path gets
longer as each ASN is appended to the route advertisement. This keeps loops from forming as each device can
see where the advertisement came from, and which other autonomous systems it has traversed. If a loop is
detected, the route is ignored.

iBGP vs. eBGP (2/2)

BGP peers do not necessarily advertise all the routes they know. They advertise
the best routes—the ones they use. When peers first connect, a full list of all the
preferred routes is exchanged. After that, updates are incremental. When a route
goes down, the route is withdrawn by sending an update to the peer router.

BGP – Border Gateway Protocol – Configuration & Operation

BGP Global Configuration

You can configure BGP for the necessary EdgeConnect appliances from the BGP tab of the Orchestrator. This
is where you configure the local ASN and the router ID after you enable BGP. You will probably want to enable
Student Guide Page 35

the AS Path Propagate option. It allows the appliance to send the full AS Path to EdgeConnect peers via subnet
sharing for route prefixes associated with other routers and appliances to avoid routing loops.

EdgeConnect Peer Type

We talked about the fact that when configuring a peer, you must select one of 2 peer types. The first of these
we mentioned was the Branch router.
A branch router can be connected as shown here, although other physical configurations are certainly possible.
A key characteristic of a branch router is that it only knows and advertises prefixes local to the branch site.
These are the only ones it will be advertising to the EdgeConnect appliance. It does not have connections to
peers across the network, although there may be other local peers, although none are shown in this diagram.
The EdgeConnect might have an eBGP or iBGP session with a branch router, and will by default, advertise all
route types to a branch router.
Provider Edge, or PE routers are the routers that connect to the edge of the service provider’s network. The
local appliances should have eBGP sessions with a PE router. The PE router may have a full internet load and
can advertise many routes into the branches. The Appliances cannot support a full internet load from a PE
router, so it’s more likely that the branch appliances will have some default routes that point to the PE routers
as the next-hop.
The local EdgeConnect appliances can advertise any local public prefixes to PE routers but should NOT
advertise routes learned via subnet sharing from remote EdgeConnect peers, as this might cause reachability
problems in the form of routing loops or black holes.
Any routes learned from a PE router will not be subnet shared to other appliances for the same reason.

BGP Peer Configuration

This is the configuration for a BGP peer. At the top is the peer IP
address. Below that is a field that allows you to restrict
connections to the peer with a particular interface. The peer’s
ASN is next. You can administratively mark a peer up or down to
enable or disable connections to that peer.
The peer type is important. The two peer types are Branch and
Provider Edge (PE). We do not want to advertise BGP routes
that originated from subnet sharing to PE routers or we might
cause routing loops. Branch peers are less risky because you will
not create a routing loop.
Next-hop-self causes prefixes advertised to the peer by the
appliance to carry the appliance’s IP address as the next-hop.
The selections for the inbound and outbound route maps are
important. You must choose a route map. If you do not, the
connections remain in the idle state. It’s important to select the
Student Guide Page 36

default route map for the correct peer type, branch or PE router. The route maps for Branch Routers end with
“br” while those for PE routers end with “pe.” You cannot see the end of the route map labels until you click the
drop-down arrows to display the list of available route maps. The edit icon let you edit the selected route map.
The Keep Alive Timer indicates how often the appliance should send keep alive messages to the peer and
expect to receive them from it.
The Hold Timer indicates the time during which if the appliances doesn’t receive a keep alive message that the
peer is marked down, and all routes learned from it are discarded. The Hold Timer is set to three times the
Keep Alive Timer by default.

BGP Monitoring
The BGP tab in the Orchestrator shows a summary of the configuration and the operational status for each of
the appliances you select in the appliance tree. The refresh button retrieves the status from each of the
appliances. If you click the edit icon next to the name of an appliance, you can configure BGP for it. The
Summary screen shows configuration details associated with the local appliance like it’s local ASN and router
ID. Clicking the BGP State Details shows a summary of how many routes have been learned and advertised via
BGP by this appliance. The Peers button shows you information about all configured peers for the appliances
selected in the appliance tree. A peer state of Established indicates that a TCP session has formed, and routes
can be advertised to and learned from that peer. Peer Details brings up a tabbed dialog box that displays the
status of the connection of each peer configured for an individual appliance.

Routes Table Example

This routes table shows BGP routes that appliances ECV-4 and ECV-5 have learned. The first four routes were
learned directly from a BGP peer. The peer’s IP address is given in the Type column, along with the fact that it
was an iBGP peer.
The bottom four
routes were
learned via subnet
sharing although
they originated
from iBGP. You
can see this in the
Type and
Additional Info
columns.
Student Guide Page 37

BGP Metrics in the Routes Table

When an appliance
learns routes via
BGP, there might be
an associated Multi-
exit Discriminator
(MED) attribute
that affects the
metric in the subnet
table. If the route is
learned from a
router and carries a
MED attribute, then
that MED attribute
is used as the metric in the routes table. If there is no MED attribute in the learned prefix, then the metric is
250 for iBGP routes and 70 for eBGP routes. The routes in this example came from an iBGP peer in AS 65001.
Since they have no associated MED attribute in the advertisement, the appliance assigns the default metric of
250 for iBGP-learned routes.
Additionally, note the difference in the Administrative Distances between iBGP, eBGP, and the subnet shared
routes. The default administrative distance for iBGP learned routes is 200. eBGP learned routes—not shown
here—carry a default administrative distance of 20. BGP-originated routes learned via subnet sharing have an
administrative distance of 15. This means that eBGP routes are preferred over iBGP routes. However, BGP
routes that were redistributed and learned via subnet sharing are preferred over those learned locally directly
from a BGP peer. Remember that administrative distance is configurable and can be changed.

BGP Soft Reset

An EdgeConnect appliance supports BGP soft reset. This
allows it to refresh routes from a BGP peer without
terminating their TCP session or disabling the protocol. It’s
useful when local routing policies have changed, and you
want to apply the configuration changes to routes from a
neighbor with minimal network disruption. In the event of a
route that wasn’t learned from a peer, it’s also useful to force a
refresh of update messages.

BGP Communities
BGP communities are supported and can be set or filtered per BGP peer
using route maps. They are often used in conjunction with the local
preference attribute to affect route preferences. Inbound and outbound
filtering and setting are separate and per BGP peer.
Student Guide Page 38

BGP Related Options That Affect Routing

The following two options are useful, especially
when you have two EdgeConnect appliances in a
Traditional HA configuration with iBGP
connections to the same local peer:
• Filter Routes From SD-WAN Fabric
With Matching Local ASN: This option
prevents an EdgeConnect appliance from
using a route learned via subnet sharing
if it includes the appliance’s own local
ASN. This can help to avoid routing
loops. However, you will see during the
labs for this course that if you use it in the wrong situation, it can cause necessary routes from an
appliance in the same AS to be filtered.
• Include BGP Local ASN to routes sent to SD-WAN Fabric: This option causes the appliance to
include its ASN with a subnet advertised to another appliance via subnet sharing. This affects all
routes, not just routes learned by BGP.

BGP over IPsec

EdgeConnect appliances share routing information via subnet sharing through SD-WAN fabric connections.
However, it’s possible to peer them together via BGP across the network using a virtual tunnel interface (VTI)
and a manually configured passthrough IPsec tunnel. These BGP over IPsec connections can be used to
connect EdgeConnect appliances in a BGP peer relationship over the WAN, as well as to third-party devices
that support this.
Student Guide Page 39

BFD: Bidirectional Forwarding Detection

Bidirectional Forwarding Detection – Overview
Bidirectional Forwarding Detection
(BFD) is a networking protocol that
detects faults between routers with the
goal of faster convergence.
EdgeConnect appliances support BFD
for both BGP and OSPF. It supports up
to 200 BFD sessions across all routing
segments (VRFs).
BFD exchanges control packets that
are like the ID of the network device.
Each BFD device listens for the other.
BFD has two types of control packets:
• Single-hop (UDP 3784)
• Multi-hop (UDP 4784)
Before devices establish a session, BFD has two operational modes:
• Active mode: EdgeConnect always uses this mode. It sends BFD control packets without waiting for
them from its peer.
• Passive mode: The device sends BFD control packets after it receives one from its peer.
After devices establish a session, they can operate in these modes:
• Asynchronous Mode: EdgeConnect always uses this mode. The device sends periodic BFD control
packets and considers the session down if it does not receive these packets from its peer within a
specific interval.
• Demand Mode: The device sends periodic BFD control packets. If the peer uses Asynchronous mode,
it stops sending control packets. If the peer uses Demand mode, both devices stop sending control
packets. A device sends a few control packets when it needs to verify connectivity. If the device does
not receive a response within the detection interval, it considers the session to be down.
Student Guide Page 40

BFD Configuration
BFD can detect BGP and
OSPF failures within one
second. You can configure
BFD from Orchestrator,
the Appliance Manager, a
template, appliance
preconfiguration, or the
REST API.
This BFD mechanism here
will allow you to detect
OSPF and BGP failures
within about one second.
You can configure these
BFD settings for
EdgeConnect:
• Min Tx Interval:
Configure a value
from 300 to 5000
ms. The default
setting is 300 ms.
• Min Rx Interval: Configure a value from 300 to 5000 ms. The default setting is 300 ms.
• Detection Multiplier: Minimum transmit interval in milliseconds (ms). Specify a value from 300 to
5000. The default setting is 300.

BFD for OSPF & BGP

From the BFD page, you can go to a specific appliance and edit it then enable the BFD protocol. For OSPF, you
can see the option to enable BFD on the interface. For BGP, on the Peer configuration, you must specify for
peer adjacency has to be single-hop as the BFD Peer must be directly attached. Then enable the Peer for BGP
with the checkbox.
Student Guide Page 41

Monitoring BFD
These images show examples of BFD monitoring features.

BFD Using YAML Preconfiguration File

These images are examples from a preconfiguration YAML file. Note, you must indicate the peer is
SINGLE_HOP.
Student Guide Page 42

Route Maps
What Are Route Maps?
In addition to sharing routes with other appliances over the SD-WAN fabric using subnet sharing, EdgeConnect
appliances can also peer to external third-party devices using OSPF and BGP. Route maps control how routes
learned via one protocol are readvertised into other routing protocols. For example, how routes learned via
subnet sharing are advertised into BGP, and how the metrics are set when the routes are advertised to a BGP
peer. Likewise, if routes are learned from an OSPF neighbor, how are the metrics set when the routes are
advertised to other appliances via subnet sharing. In the case where the appliance is running both BGP and
OSPF, route maps can control how routes are redistributed between those two protocols.
It should be noted that there are inbound and outbound route maps. Inbound controls what is distributed into
the SD-WAN fabric and subnet shared between EdgeConnect appliances. Inbound route maps are found on
the Routes pages for each appliance. Outbound controls what is redistributed by an appliance into another
routing protocol, like OSPF or BGP, and is found on the configuration page for those protocols. BGP is slightly
different from OSPF in that it contains inbound and outbound route maps per peer.
At a high level, just like ACLs, each route map has a set of rules. Each rule has match criteria, which include the
source protocol from which the route was originally learned and more.
Each rule can permit or deny the redistribution of routes that match the
rules. Finally, for routes that are permitted, it’s possible to modify
attributes of the advertised prefixes, by doing things like setting the
metric.
When you are creating a route map rule, 0.0.0.0/0 matches all prefixes,
it doesn’t match just match default routes. So, for example, if you want
to deny advertising default routes into a particular protocol, but allow
other local or static routes, you must permit the more specific routes
first.

Route Maps Are Used For Directional Redistribution of Prefixes

This diagram represents
the redistribution of
routes between SD-WAN
fabric subnet sharing,
OSPF, and BGP. Subnet
sharing and OSPF each
have one active route
map. BGP has one active
inbound and outbound
route map per peer. The
route maps give you
control over source
protocol match criteria
Student Guide Page 43

and protocol-specific set actions the appliance can perform in addition to permitting or denying a route.

Redistribute Routes into Subnet Sharing

The route map that
controls routes
redistributed into the
SD-WAN fabric via
subnet sharing is
found on the Routes
page for each
appliance. To edit the
route map, click the
edit icon. The default
route map rules might
not permit
redistribution of all
source protocols, so if
you are missing
routes, ensure there
are rules that permit
the routes you are looking for.
Only one route map can be active at a time. You can select the active route map from the drop-down list. Add a
new route map by clicking the button. You can clone an existing map, give it a new name, and modify its rules.
Each of the rules in a route map is priority-numbered like an ACL, and they are applied in order, starting with
the lowest-numbered rule and proceeding to the highest-numbered rule. If a route matches an entry, the set
actions are performed. You can edit each rule by clicking the edit icon on the left. You can delete a rule by
clicking the x icon on the right.

Each Route Map Rule Is Set by Source Protocol

Rules are set per source protocol,
and each protocol has its own
match criteria. In this example, for
routes redistributed into subnet
sharing, you can have rules that
affect only certain source
protocols. All rules allow you
match on source addresses or
subnets. You can have multiple
rules for each source protocol,
each of which has different match
criteria, permit or deny settings,
and different set actions for
permitted routes. The source
protocol choices for subnet
sharing into the SD-WAN fabric
include the following:
• Local/static routes
originating on the local
Student Guide Page 44

appliance that allow you to set the metric for permitted routes.
• BGP routes that allow you to match various characteristics including the route prefix and communities.
• OSPF routes that allow you to match on OSPF tags.

Redistribute into OSPF

The route maps for redistributing routes into OSPF are found on the OSPF configuration
page of each appliance. Click the edit icon to view or edit the rules in the route
map. Local/Static and BGP routes are denied redistribution into OSPF by
default.

Redistribute into OSPF Rules

You can enable or disable the rules in a route map. This is useful for
testing while troubleshooting. It’s also useful for staging a rollout
during a network change. You can add the rules in advance, and then
enable them when you are ready. Like all route maps the match criteria
varies by source protocol and includes the prefix or host, BGP
communities, and OSPF tags. For routes that are permitted, the set
actions into OSPF include adding an OSPF tag, setting the metric type,
and setting the metric or link cost. By default, if you do not set it here,
it inherits the metric from the source protocol. By default this is 50 for
subnet shared routes, 70 for eBGP routes, and 250 for iBGP routes.
Student Guide Page 45

Inbound and Outbound BGP Route Maps Are per Peer

BGP features one inbound and outbound route map per peer. In other words,
each BGP peer has its own settings. There are separate default route maps for
each peer type whether it’s a Branch peer or a
Provider Edge peer.

Outbound Route Maps to BGP

BGP route maps provide a lot of flexibility with settings for each source protocol.
For SD-WAN routes, it allows you to discriminate between
routes that are native SD-WAN
routes, and those that were
learned by the local appliance via
subnet sharing but originated at
some other site from OSPF or
BGP. This can be important for
avoiding routing loops.

Defaults: Outbound for

Branch vs. PE
Branch peers are usually—but
not always—in the same AS
and found on the LAN side of
an EdgeConnect. The risk of
routing loops in the BGP
protocol is lower in this case,
so the appliance is allowed to
advertise its SD-WAN fabric
routes to the branch peers by
default.
Provider Edge (PE) peers
usually connect one of your
sites to a service provider’s
network in a different AS.
Since appliances at other sites
are usually learning routes
from the local appliance via
Student Guide Page 46

subnet sharing, advertising the SD-WAN fabric routes to a PE peer has a higher risk of creating a routing loop.
So, it’s not a good idea to advertise SD-WAN routes to PE routers, and the default rules deny subnet shared
routes outbound to PE peers.

Route Redistribution Maps Template

You can create and distribute
route maps using the Route
Redistribution Maps template
in a template group. While this
is a useful tool, you should
exercise caution since
addressing and routing
requirements often relate to a
particular network site or
appliance.

Route Map Limits

You can have up to 10 route maps each for subnet
sharing and OSPF. For BGP, you can have up to 20
inbound and outbound. Each route map can have up to
128 rules.
Student Guide Page 47

Regional Routing & Hub Behavior

The Advantage of Regions
Regional routing is an important network scalability feature that is enabled by default. It helps reduce the
number of tunnels needed in your network, which can reduce complexity, overhead and cost. One of the
reasons for Regional Routing is to provide a way to connect the different global pieces of a network that
connects through different ISPs in different areas of the globe. Regions allow you to group appliances. They
form underlays only within their region according to the topology you choose.

Regional Topologies
A mesh topology connects all your EdgeConnect appliances to one
another. Spoke appliances only connect to hubs, and not to other
appliances in the network. The hub appliances for an overlay are selected
from the appliance tree that the Orchestrator manages. A hub is a hub in
every overlay it’s a part of. The interconnection between hub sites in
different regions is a full mesh for all the hubs in the overlay, even if you
select a hub and spoke configuration for the different regions. If you do
not want to build tunnels between certain hub sites, you can give them
the same site name. Hub sites in different regions that are part of the
same BIO connect to hubs in other regions.

Metrics with Regional Routing

EdgeConnect appliances add 50 to the metric of
readvertised routes. This also happens between
regions. These are some examples of how this works:
• EC1 advertises its routes with the default
subnet sharing metric of 50.
• H1 learns the route to EC1 with a metric of 50.
• H2 learns the route to EC1 with a metric of
100 because H1 adds 50 to the original metric
of 50.
• EC3, EC4, EC5, and EC6 learn the route to EC1
with a metric of 150 from H2, because H2 adds
50 to the metric of 100 that H2 associates with
the route.
Student Guide Page 48

Hub Route Advertising

With Regional Routing, hubs readvertise routes they learn
from spokes to other spokes via subnet sharing. H2 learns
routes from S2, and then it advertises those routes to S1 via
subnet sharing. Readvertised routes have 50 added to their
metric. This keeps a hub from being a preferred path if there
is also a direct link between spoke or mesh sites. Spokes
know from the readvertised routes that hubs have a path to
subnets on other spokes. Hubs automatically route between
directly connected spokes. H1 routes traffic between S1 and
S2.
Hubs advertise their own locally connected networks to each
other, as well as to other non-hubs in their local region. In
other words, the subnets of connected networks to each hub
can be advertised to other hubs. H1 advertises its directly connected networks to H2 so traffic can be routed
between the hubs for devices on directly connected networks. Hubs do not re-advertise learned routes to hubs
in the same region. If a hub learns a network from S2, it doesn’t readvertise this network to other hubs in the
region to prevent routing loops.
Hubs must learn local routes in a region from the devices they are directly connected to. H2 will not advertise
routes it learns from S2 to H1. H1 must learn those routes directly from S2. The implication of this is that hubs
will not route spoke-to-spoke traffic through another hub. So, traffic cannot go from S2 to H2 to H1 to reach
S1.

Hubs Are Useful in Mesh Regions

You might think that because you have a full mesh network
hubs aren’t necessary. However, hubs in a mesh overlay can
provide a backup path between the fully meshed appliances.
Hubs add 50 to the metric for readvertised routes. H3, EC5, and
EC6 each learn red network with a metric of 50. EC4, H3, and
EC6 learn the blue network with a metric of 50. H3 advertises
the red network to E5 with a metric of 100. So, if the link
between EC4 and EC5 goes down, traffic can go from EC4 to H3
to EC5. However, this can only happen if H3 is a hub that
readvertises the networks it learns from other appliances, with a
higher metric, so it’s the less preferred path. This means that the
hub only acts as a backup path since it’s advertising a route with
a less preferred metric. Appliances prefer a direct link to each
other unless the link between them is down, and then the traffic
can be routed through a hub.
Student Guide Page 49

Hubs Do Not Readvertise to Other Hubs in Their

Region
Hubs that learn a route from another region will not
readvertise that route to other hubs in their local
region. For example, if H2 learns a route from H1,
then H2 will not advertise that route to H3. This is
one of the reasons that hubs must be fully meshed
between regions, so H3 can learn the route from H1.

Hubs Do Not Readvertise to Hubs in Other Regionals Either

Routes learned from a hub in another region aren’t
readvertised to hubs in other regions. This means
that there is no inter-regional transit routing. Traffic
flowing from Region 2 to Region 3, for instance,
never goes through Region 1. It must always go
directly from Region 2 to Region 3. Here is an
example:
• H1 advertises routes it learns from A1 to
H2 and H4.
• H2 will not advertise routes from A1 to H3.
• H4 will not advertise routes from A1 to H2.

Regional Hub Behavior

Hubs must be fully meshed with each of the hubs
in the other regions. Let’s change A4 and make it a
hub. When you use Regional Routing, you must
know two things. First, the hubs within a region
must be fully meshed with each other. Second,
hubs must be fully meshed with the hubs in the
other regions.
Student Guide Page 50

Topology Selection in BIO

To optimize the scalability provided by Regional Routing, you
should be careful with your topology selection. Just because
Regional Routing is enabled, it doesn’t mean tunnels will not be
built between appliances in different regions. You must also ensure
your overlays use regional topologies. If you choose a non-regional
topology, it can result in tunnels being built between appliances in
different regions, rather than having all the traffic routed between
hubs in the local region.

Hub & Spoke Routes in Routes Table

When you have Regional Routing configured and look at the routing table, you can tell which routes were
learned from hubs or spokes. If you look in the Type column, you can see each route is marked in a way that
identifies its source as a hub or spoke. This indicates which type of appliance this route was learned from, not
necessarily whether the route originated on a hub or spoke in the other region.
However there is more information that can help you tell the difference. For example the 10.110.10.0 subnet
was advertised to this device, ECV-4, by ECV-1, which is in a different region. Remember hubs add 50 to the
default subnet sharing metric when they readvertise learned routes to hubs in another region. So, if the route
had been readvertised by ECV-1, it would have added 50 to the default metric, and ECV-4 would have learned
it with a metric of 100. This is one way you can tell. In this case, since ECV-1 is in another region, and the route
was learned by ECV-4 with a metric of 50, the subnet could only be one that is directly connected to ECV-1.
Any routes that ECV-1 learned from another appliance and readvertised, would have been announced with a
metric of 100 to ECV-4.

Regional Routing Tasks

Follow these steps to enable Regional Routing:
1. Create a label for each region.
2. Designate specific EdgeConnect appliances as hubs.
3. Configure regional topologies for overlays.
a. Make any region-specific changes to the overlays.
4. Add EdgeConnect appliances to the regions.
Student Guide Page 51

Managing Regions
Regions are managed from the Regions tab. Click Edit Regions to add new region names or edit existing ones.
These are just labels, so you can call them anything that makes sense to you. Once you have created regions,
you can add or remove appliances from a region by selecting the EdgeConnect appliances in the appliance tree
and using the add and remove check boxes. If Regional Routing is off, hubs do not readvertise routes learned
from spokes. To enable route redistribution by hubs, you need to enable Regional Routing.

Regional Routing Behavior

To enable Regional Routing, you need to turn it on. As we saw
earlier, this parameter is available from the Regions tab, or the
Configuration menu under Networking. When you enable Regional
routing, the behavior of hubs in regions changes. They still learn
routes from spokes and non-hub appliances in a mesh, but with
Regional Routing enabled, hubs can automatically readvertise
subnet shared learned routes to non-hub appliances in the same
region. Regional routing makes spoke-to-spoke routing via hubs
automatic, since the hub advertises routes to the spokes. With
Regional Routing turned off, behavior is like earlier versions of
software. Although a hub learns routes to the spokes, it will not
readvertise them, and static routes are needed for spoke-to-spoke
routing.

Managing Hubs
The Hubs tab manages which appliances are
classified as hubs. This is reachable from the
Configuration menu, or from the link on the
Business Intent Overlays tab. Remember, a
hub is a hub for every overlay it’s a part of. If
you create a hub and want to later remove it
from the hub role, you must first remove the
Business Intent Overlays from it. After you’ve
removed the appliance from the hub role, you
can reapply the necessary Business Intent
Overlays.
Student Guide Page 52

Default Region
The Default region is the one that all appliances are in until
you assign them to a user-created region. You can see here,
ECV-1 is not in a region as shown on the Regions tab. If we
look at the System Settings for ECV-1, we can see that it
shows its region as Default.

Overlay Regions
Each Business Intent Overlay can have a different configuration for each Region it’s a part of. For example, the
RealTime Business Intent Overlay
can have different configurations
globally or in regions 1, 2, or 3. One
implication of this is that you
effectively have more Business
Intent Overlays than in older
versions of software, since each
overlay can have multiple
configurations. Any appliances
assigned to a region use the
overlay configuration for that
region. Any appliances not
assigned to a region use the
Business Intent Overlay’s global
configuration.

Include Hubs in Other Regions

There are times when you might want appliances in one region to connect to hubs in another region. This
might be at a data center with a server that all devices in your network must be able to reach. In this case, for
each regional overlay, you can also include hubs from other regions. In this case, hubs in the external region
can advertise routes to spokes in a different region that include it. This option is not available for the Global
region associated with a Business Intent Overlay, only the user-defined regions.
Student Guide Page 53

Flow Redirection
Active/Active & Asymmetry
Here we have an
example of an
active/active deployment
in a Traditional HA
environment. This might
be at a data center where
there was more traffic
than a single
EdgeConnect could
handle. If the
transmission path between two conversation endpoints goes through the EdgeConnect appliances in one
direction, but in the reverse direction, the traffic returns along a path that doesn’t go through the same pair of
EdgeConnect appliances, then TCP Acceleration cannot be performed. This is because an EdgeConnect cannot
track the sequence numbers in a flow for missing packets and act as a TCP proxy that performs local
acknowledgments.
In the active/active diagram here, packets from the LAN on the left might be sent to either EdgeConnect A or B
because they are load sharing, and each advertises a route to the destination at an equal cost. This means
traffic between the LAN device on the left and the server on the right is subject to asymmetry. We generally
see active/active configurations in large data centers and in cloud deployments utilizing large workloads, such
as you might find in AWS or Azure, for example. When an active/active deployment with asymmetric routing is
unavoidable, Flow Redirection can help restore symmetry to make TCP Acceleration possible.

Flow Redirection Corrects Asymmetric Flows

Flow redirection is an EdgeConnect feature for correcting underlying
asymmetric flows in the network. EdgeConnect appliances are configured
as peers in a redirection cluster. Although it’s unlikely you’d have more than
one or two peers, you can cluster up to 32 appliances.
Devices in a cluster communicate over a cluster interface, usually mgmt1. If
you need more than 1 Gbps of redirection bandwidth, you can choose to
use a faster interface. The IP addresses for the cluster interfaces must be in
the same subnet, and that subnet must be separate from the mgmt0
interface.
As shown here, traffic can be sent to one appliance. When a second
appliance detects it’s a packet for a flow owned by the other appliance, it
sends the packet over the cluster interface to the flow owner. In this way,
asymmetric flows are corrected without having to make any changes to the
routing in the network.
Student Guide Page 54

How Does Flow Redirection Work?

How do the devices in a cluster know which one owns the flow in a TCP
conversation? The device that sees the SYN owns the flow. Flow
Redirection appliances exchange flow tables with each other using a
proprietary protocol. Updates are sent dynamically as needed between
clustered devices. A packet received by an appliance that is not the
owner of the flow forwards the packet to the flow owner over the cluster
interface. The flow will not appear in the Active & Recent Flows tab of
the redirecting appliance. The flow only appears in the Flows tab of the
appliance that owns the flow, although statistics are available to tell you
the number of packets and bytes each appliance redirects.
When an appliance receives a SYN/ACK, and it hasn’t seen the SYN or
received a flow table update from a cluster peer, it briefly holds the
packet. This allows time for a cluster peer to send a table update, so it
knows where to redirect the packet. If the wait time expires before a peer
notifies the appliance that it owns the flow, the flow is marked
asymmetric. The wait time is adjustable to compensate for the latency of
the redirection link.

Configure Flow Redirection from Appliance Manager

You need to configure the
cluster interface globally, then
add peers one at a time. If you
have a high-latency environment
between the peers, you might
need to adjust the wait time.
However, the default should
work in most cases. After you’ve
added the peer, check the box to
enable Flow Redirection.
Student Guide Page 55

Monitoring Flow Redirection

How do you tell if Flow Redirection is working properly? If you view Active & Current Flows, you should not see
asymmetric flows if some were there previously. If there are asymmetric stale flows present, make sure you
reset them. When the flows are reestablished, they should be symmetric. Also remember, that the flows only
appear on the owner appliance, not on the one doing the redirection.
To check the status of an individual cluster peer, look at the Flow Redirection configuration page and check its
state. If it’s down, check reachability after ensuring that you’ve correctly configured the IP address on each end.
For more detail, go to Flow Redirection under Monitoring. There’s one for flows by peer, that shows you the
number of flows, packets, and bytes redirected or received, as well as the peer’s status of the peer. There’s also
one for control messages exchanged by peers.
Student Guide Page 56

Additional Security Features

Stateful Firewall
WAN hardening is secure
but not sophisticated.
EdgeConnect appliances
include a stateful firewall
that can be enabled on a
per WAN interface basis.
This firewall provides
basic layer-3 and layer-4 functionality that might be suitable for branch offices with local traffic going to the
internet. If a device on the local LAN originates a connection to an outside device, the session is permitted. No
externally initiated sessions are permitted inbound through the stateful firewall unless you enable inbound port
forwarding. This is not a substitute for an IDS or IPS that does deep packet inspection. The stateful firewall
doesn’t examine Layer-7 data, only the connection state, so it doesn’t protect against hidden malware or
viruses in content accessed by a device that connects to an insecure destination. If your site needs that level of
protection, you might want to locally deploy an external firewall, or to backhaul traffic to a data center that
offers more sophisticated security.

Firewall: Stateful & Stateful + SNAT

Let’s discuss the Stateful and Stateful+SNAT
settings available on EdgeConnect appliances’
WAN interfaces. When you select either of these
options, the WAN interface becomes a stateful
firewall, and only outbound connections are
permitted. Connections initiated from the WAN
side are not permitted, and this traffic is dropped.
If you select the Stateful+SNAT option, then
outbound passthrough traffic exiting through that WAN interface are subject to source NAT. Traffic that goes
into a tunnel will not be affected. Network source addresses are translated to an address using a port with the
IP address of the WAN interface through which the traffic passes. If the source port is not in use by SNAT, then
the source port is unchanged. If another device is already using that source port, then a new source port is
mapped. You should probably only enable SNAT if there is no upstream device, a standalone firewall or router
for example, that is already performing this function.
A flow detail for each flow shows the original IP addresses and ports, as well as the post SNAT outbound
address and port information.
Student Guide Page 57

IPsec Key Rotation

Another important feature is IPsec key rotation.
This allows you to schedule times when all the
appliances run a predetermined algorithm that
modifies the existing encryption key. After the
algorithm runs, all the appliances still have
matching keys, but this increases the difficulty for
any outside hacking attempts by making sure the
key is periodically updated.

IPsec UDP Tunnels (IKE-less)

EdgeConnect appliances supports IPsec
UDP tunnels that give you the encrypted
protection of standard IPsec but without
some of its restrictions. Standard IPsec
tunnel negotiation can fail when it takes
place through NAT/PAT, especially when
there are multiple devices trying to
establish IPsec sessions on one side of the
device that performs NAT. In this case port
numbers cannot be preserved due to
previous use by other devices.
Additionally, with Internet Key Exchange
(IKE) negotiation mismatches between the IP address in the payload and the source IP address in the header
after the source IP has been translated can cause problems.
Various NAT traversal (NAT-T) solutions can solve some of these problems, but the EdgeConnect appliance’s
IKE-less solution completely avoids these problems and provides
additional security. Key distribution is managed by the Orchestrator,
and each tunnel uses unique keys. The design also provides for
faster negotiation and improved scalability.

IP Allow List: Restricts Access to Orchestrator

An EdgeConnect allows you to restrict network access to the
Orchestrator based on the source subnet. Configure any addresses
here to restrict access to only the listed subnets or hosts. Click the
IP Allow List Drops link at the bottom of the page to see a list of
devices that have been denied access. Ensure when you configure
addresses or subnets, you consider whether the devices connecting
to the Orchestrator are subject to NAT. If so, you need to add their
external, translated addresses, not their original ones.
Student Guide Page 58

EdgeConnect Can Build Tunnels to Service Chain

EdgeConnect supports automated deployment to a few third-party services like Zscaler and Checkpoint
CloudGuard Connect. If your service is not one of those currently automated, we also support Service
Orchestration using manually created IPsec or GRE tunnels.

Automated Zscaler Orchestration Example

An Orchestrator can automatically connect to the Zscaler service and builds tunnels for you. All you need to do
is provide account credentials, choose the interface labels to use, and add the Zscaler policy to a Business
Intent Overlay. The Orchestrator automatically queries Zscaler to detect which Zscaler Enforcement Node
(ZEN) to connect to for each appliance and builds the tunnels for you.
Student Guide Page 59

Zone Based Firewall

Zone Based Firewall
The Zone Based Firewall allows you to
label interfaces as being in a particular
zone. Then based on permissions you
configure, traffic between firewall zones is
either permitted or denied. For example,
we have three firewall zones: Users,
Accounting, and ServerFarm. You might
permit connections to be initiated from
Users to the Server Farm, or Accounting
to ServerFarm, but not allow sessions to
be initiated from ServerFarm to
Accounting or Users.
An EdgeConnect’s Zone Based Firewall is stateful. This means that if a session is permitted to initiate in one
direction, like Accounting to ServerFarm, return traffic from ServerFarm to Accounting is allowed because the
firewall is aware of where the connection initiated. This is true even though sessions are blocked from being
initiated from ServerFarm to Accounting.

Define Zones for LAN & WAN Interfaces

Each interface is assigned to a zone that is defined by a zone label. Each circle represents a zone boundary.

Zones are Defined on Both LAN & WAN Interfaces

All traffic has an
ingress (From)
zone and an
egress (To)
zone. The
source host is in
the ingress zone.
The destination
host is in the
egress zone. Traffic moves from the ingress zone to the egress zone.
Student Guide Page 60

SD-WAN Traffic from PC-1 to PC-6

This example shows
traffic from PC-1 in
zone A sent via an
SD-WAN overlay
tunnel to PC-6 in
zone G. PC-1
creates a packet
with the PC-1’s
source IP address and PC-6’s destination IP address, and then it forwards the packet to its next hop, the lan0
interface of the EC-V on the left side. The traffic matches a matches a Business Intent Overlay and a Zone
Based Firewall security that permits traffic from Zone A to Zone G. The appliance forwards the packet through
the overlay tunnel. The EC-V on the right side receives the packet and removes the IPsec UDP encapsulation.
The same Zone Based Firewall security policy on this appliance permits traffic into Zone G, and the appliance
forwards the packet to its destination of PC-6.

IPsec UDP Header Contains Source Firewall Zone

IPsec UDP packets include a header with a tag that specifies the source firewall zone. To determine the
destination firewall zone, the appliance performs a lookup in the routes table based on the matching Business
Intent Overlay and routing segment. Security policies specify the source LAN zone and destination LAN zone
for SD-WAN overlay tunnel traffic. Security policies specify the source LAN zone and destination WAN zone for
passthrough or internet breakout traffic. This is an example of this process:
1. Device D wants to establish a session with a Server S. Device D in Zone A connects to EC-1. Server S in
Zone C connects to EC-2.
2. If a packet matches an intra-zone security policy for Zone A to Zone C, then EC-1 permits it. Otherwise,
it drops the traffic.
3. EC-1 transmits the traffic to EC-2 through an overlay tunnel. Packets in an overlay tunnel carry a
source firewall zone tag in their IPsec UDP header.
4. When EC-2 receives the packet, EC-2 evaluates its security policies. It reads the source firewall zone
tag, permits the traffic, and forwards it to Server S.
5. EC-2 and EC-1 both permit the return traffic from Server S to Device D because security policy
enforcement is stateful.

Apply to Interfaces on Deployment Page

Zone Based Firewall is supported only with an inline, router mode deployment. After you configure the names
of the necessary firewall zones, you need to assign them to interfaces from the Deployment page of your
Student Guide Page 61

appliances. WAN and LAN interfaces have a FW zone field. The firewall zones’ names are in a drop-down list.
Unless you change it, each interface or VLAN is in the Default zone. An interface can belong to only one firewall
zone. However, a
firewall zone can
include multiple
interfaces that are all
associated with it. The
firewall zone fields for
each interface will not
appear as configuration
options on the
Deployment page until
you create firewall
zones to put them into.
Only the zone named
Default exists by
default.

Zones, Subinterfaces, & VLANs

While multiple firewall zones are permitted on the same physical interface or virtual NIC, they must be in
separate VLANs if you want them to be in separate firewall zones. If you use subinterfaces, and they are
untagged or in the same VLAN, they must be in the same zone.

Order of Operations
While you set up a new network or add a new appliance, you generally will not need to worry about disruption.
But when implementing Zone Based Firewalls in an existing network, you need to think about the order in
which you do things.
1. Start by configuring your zone labels. This must be done first, since if there are no firewall zones, you
cannot do any filtering.
2. Next configure your security profiles and apply them to the appliances. Remember by default, all
interfaces are in the Default firewall zone. Since traffic between devices within a zone is always
permitted, there’s no impact until you start adding firewall zones.
3. You need to configure the appliance to use the firewall zones.
4. Since you cannot change everything at once to match the security profiles you set up, as you move
interfaces out of the Default firewall zone, some network disruption will occur, so you should schedule a
maintenance window to do this.
Student Guide Page 62

First Configure Firewall Zones

First, you need to create the firewall zone labels. Give the firewall zones
meaningful names to differentiate them, especially if your SD-WAN has
Routing Segmentation (VRF) enabled.

Matrix View of Security Policies

Policies are applied when traffic goes from
one firewall zone to another. The “From”
zone is the source zone, where the
connection is being initiated from. The “To”
zone is the destination zone, or where the
packet is being sent next. Clicking at the
intersection of a From and a To firewall
zone allows you to configure the security
policies for access between those zones. In
this example you can see that we have
previously configured a policy to allow
people in the Users zone to access systems
in the Server Farm zone using file sharing
applications like CIFS. Other traffic like FTP
would be denied by the default policy
shown at the bottom of that intersection.
Remember, the Zone Based Firewall is
stateful. So, if a session is permitted in one direction, the return traffic for that session is permitted.

Table View
If you prefer, you can choose a table view of the
security policies instead of the matrix view.
Student Guide Page 63

Granular Security Policies

This is what
editing a security
policy’s rules
looks like. By
default, a rule you
add permits all
traffic until you
change its match
criteria. This
brings up a
simple dialog box
that allows you to
filter based on
Application
Group, a
particular
application, or use
an ACL that you’ve already created. If you want more match criteria, click More Options. This brings up a long
list of configurable options, which you can see is quite detailed, allowing for a great deal of granularity in your
filtering. The last rule in any security policy matches everything and denies any traffic you haven’t specifically
permitted.

Apply Security Policies to Appliances

To apply the Security Policies template,
select the appliances you want to apply it
to in the appliance tree and click Apply
Template Groups. If you’ve previously
applied a template to an appliance before,
then it becomes associated with that
appliance. Any changes you make to that
template are applied immediately to all the
associated appliances. However, you can
change this from the Apply Template
Groups tab of the Orchestrator. Be careful
with the Merge and Replace options. The
Merge option inserts your changes into the
security policies in priority order. The
Replace option overwrites what you
previously configured.

WAN Zones for Passthrough & Internet Breakout Traffic

When you consider which WAN
interfaces to use for internet
breakout traffic, it’s best practice to
choose a firewall zone label that
describes its destination. Interzone
traffic is permitted by default. You
should configure the WAN firewall
Student Guide Page 64

zone name as something different than the local LAN firewall zones. Configure a security policy that permits
passthrough or breakout traffic. Only passthrough or internet breakout traffic flows from a LAN firewall zone to
a WAN firewall zone. Overlay tunnel traffic flows from a local LAN firewall zone to a remote LAN firewall zone.

Monitoring & Troubleshooting

Enable/Disable Individual Rules

It’s possible to enable and disable individual rules in a security policy rule. This is useful while troubleshooting
potentially related issues.

Examine the Flow

The Flows tab is your best friend when troubleshooting.
From the Orchestrator, click a flow detail icon to learn
more about how the EdgeConnect appliances handle a
flow’s traffic. In this example, the traffic matched the
BulkApps Business Intent Overlay. In the Security section,
we see the deny action. We can also see that while the
source zone is Pacific, the destination zone is Fabric. The
Priority is default. This indicates that the appliance
matched the flow to the default deny interzone security
policy. You would need to create a specific security policy
to allow traffic between these firewall zones.
Student Guide Page 65

Monitoring Firewall Drops

If you want to see what the appliance drops in real time, you can go to the flows table. In the flows table, you
can see the dropped flows have red text. A count of dropped flows shows in the flow count summary, and you
have a built-in Flow Characteristics filter to display Firewall Dropped flows.

Monitoring Drops
If you want to see what is being dropped in real
time, you can go to the flow table, which is
always your best friend. In the flow table, you can
see that dropped flows are shown in red, like the
one displayed here. A count of dropped flows is
shown in the flow count summary and you have
a built-in filter to display only those flows which
were dropped by the firewall functions.

Zone to Zone Exercise

In this exercise, you see the following:
1. TG-03 in the Accounting
firewall zone sends traffic to
TG-02 in the Users zone.
2. ECV-3 has a matching
security policy, so it permits
the traffic from TG-03.
3. ECV-1 performs WAN-to-
WAN routing for the flow.
4. ECV-2 has a matching
security policy, so it permits
the traffic to TG-02.
Student Guide Page 66

5. The Zone Based Firewall is stateful, so the appliances permit the return-path traffic from TG-02 to
TG-03.

Troubleshooting Notes
A Zone Based Firewall permit or deny is based on First Packet iQ application identification. That happens when
the flow is first established. When you make a security policy change, a flow reset—not reclassify—is necessary
for application identification to happen again. Otherwise, the existing flows become stale flows, meaning they
continue to handle traffic according to the previous security policies when the flows were first established.
There is a background process called auto-reclassify that periodically inspects existing flows to attempt to
conform them to current rules. However, auto-reclassify doesn’t reset the flow to avoid disrupting traffic, so it
cannot perform a new First Packet iQ lookup on established flows. Auto-reclassify could result in flows being
dropped, however, if a routing change caused a zone to change. In this case, when you examine a flow detail,
the security policy Deny Reason would say routing. A manual flow reset or other action that caused the session
to be reestablished would be necessary to apply the new security policy based on First Packet iQ.
Traffic that doesn’t create a flow in the flow table (e.g. bypass or some passthrough unshaped) is not subject to
security policy. So if, for example, you have manual route policies that send traffic PTU, that traffic would not be
subject to security policies. However, If that same traffic was sent passthrough unshaped because of the Peer
Unavailable Option of a Business Intent Overlay, it would be subject to security policies. So, you would be able
to see this in its flow details.

Do You Need Zone Based Firewall?

If you don’t want to use ZBF, then
do nothing. Just leave all the
interfaces in the Default zone and
everything will behave the same
way it does without a Zone Based
Firewall. Remember that intra-
zone traffic, traffic flowing between
two devices in the same zone, is
always permitted, so if everything
is in the Default zone there are no
security restrictions. Only
interzone traffic can be denied by
security policies.

Zone Based Firewall vs Stateful Firewall

What’s the difference between an
EdgeConnect appliance’s stateful firewall
(i.e. FW Mode for WAN interfaces) and
Zone Based Firewall on WAN interfaces?
They can work together but have different
functions.
Student Guide Page 67

The stateful firewall is a simple way to control passthrough LAN-to-WAN flows. If the connection originates on
the LAN side, the state is stored, and return traffic is permitted. Inbound connections originating from the WAN
side, arriving outside of a tunnel are dropped.
The Zone Based Firewall is much more powerful. Each interface is a member of a zone, and rules can be set to
permit or deny traffic between any two firewall zones. Control can be very granular, because configurable
security policies can be created using standard access lists to permit or deny different kinds of traffic, instead of
the simple global control of the WAN-side stateful firewall. Like the stateful firewall, the Zone Based Firewall
stores the session’s state which allows you to permit connections initiated in one direction between two firewall
zones, but deny connections initiated in the reverse direction.

Zone Based Firewall Limits

It’s best practice to use 10 or fewer firewall zones. However, you can use up to seven WAN-side firewall zones,
and 127 LAN-side zones minus the number of WAN-side zones. Finally, a security policy can include up to 100
rules per source-destination firewall zone pair.
Student Guide Page 68

Routing Segmentation (VRF)

Why Use Routing Segmentation?
It’s often desirable to break your network into separate routing domains in which the devices and flows in each
one are separate from each other for data security reasons. HPE Aruba Networking uses the term Segments to
describe these separate routing domains.

What Are Segments?

Segments establish separate virtual data planes within each EdgeConnect appliance. Segments (i.e. VRFs)
establish logically and physically separate routing and transport domains within a device, and within a network
of connected appliances. Each interface of an appliance is in only one segment. An interface cannot be part of
multiple segments. Traffic is allowed to flow between devices within the same segment by default.

Intersegment Routing
Traffic that originates in a segment is restricted to destinations in that same segment by default. The routing
tables in each segment are separate from those for other segments, and there is no intersegment route
advertising or route leaking. Traffic between destinations in different segments is only possible if you explicitly
permit it . Three things are necessary for this to happen:
• Intersegment routing policies must be configured to permit intersegment connections.
• Zone Based Firewall security policies must also permit it
• A route to the destination in the other segments must also be known.
Student Guide Page 69

Segments Make Use of Business Intent Overlays

Traffic flowing within and between
segments, works with, and makes use of
Business Intent Overlays, just like all other
traffic. Any segment might have traffic
destined for any Business Intent Overlay.
The traffic for each segment is still
separate and secure within each overlay,
and the BIO still determines how the traffic
is handled and which underlays are used.

Segmentation Configuration

Routing Segmentation Configuration Tasks

This is an overview of the necessary tasks to configure Routing Segmentation:
1. Enable Routing Segmentation globally in Orchestrator.
2. Define the label for each of the segments.
3. Configure the routing options for each segment.
4. Assign interfaces to segments in the deployment profiles for each appliance.
5. (Optional) You can also define intersegment routing and destination NAT (DNAT) exceptions and
define intersegment source NAT (SNAT) exceptions.

Segmentation Is Enabled by Default

You enable Routing Segmentation (VRF) by clicking its toggle button on that tab in the Orchestrator.

Add Segments
After you have enabled
Routing Segmentation, the
+Add Segment link becomes
active. Then you can add
new segments and name
them. In this example two
additional segments, SegA
and SegB, have been added.
Just adding segments
doesn’t change anything.
Until you change the
configuration, all appliances,
interfaces and routes remain
in the default segment.
Student Guide Page 70

Each Interface Is in a Configured Segment

Each interface is in one segment, and until you change it, all interfaces are in the Default segment. After you
have created your segment labels, you can go to the deployment page for an appliance and select the available
segments from a drop-down list to assign your LAN interfaces to a segment. A LAN interface can be assigned
to any of the segments you created.
All WAN interfaces are hard-coded to be in the Default segment. This cannot be changed. Traffic flowing
through any tunnels that terminate on a WAN interface aren’t affected by the label of the WAN interface.
Segmentation is preserved inside the overlay tunnels themselves.
When you enable segmentation, you also begin using the Zone Based Firewall. The chosen firewall zone is the
instance of that zone in that segment. In other words, if you chose SegA, and a firewall zone of default, that’s
not the same as the default firewall zone in SegB or the default segment.

Intersegment Routing – No DNAT

To enable intersegment routing
you need to create an
intersegment routing and
DNAT rule. This example does
not use DNAT because there
are no overlapping address
spaces. In this example the
traffic is coming from TG-01, is
in Segment A. The destination
IP address could be a subnet or a host address. We are allowing traffic to any device in the 10.110.120.0/24
subnet. The destination subnet is in the Default segment, so that is specified in the Send To Segment field. The
Translated Destination Address is left blank because we do not need that feature when the address spaces are
not overlapping.

Intersegment Routing – Overlapping Address Spaces

In this example, we allow intersegment routing. Because the source and destination subnets have overlapping
address spaces, we must use the DNAT feature. TG-01 needs to be able to reach TG-03. There are
10.110.10.0/24 subnets in both the source and destination subnets. To work around this, we have chosen a
proxy address of 10.110.112.111 to serve as the destination address that devices on the left, like TG-01, try to
Student Guide Page 71

reach when they want to connect to TG-03 on the right. TG-01 will send a SYN packet to this proxy address of
10.110.112.111.
To make sure it can reach its intended destination, we have configured an intersegment routing rule with
DNAT. The rule applies to traffic coming from segment SegA, where TG-01 is located, that matches the
destination address of 10.110.112.111, which is the proxy address we chose for TG-03 in SegA.
Then we need to translate the destination address of 10.110.112.111 to the actual destination address of
TG-03 which is 10.110.10.111,
but in segment SegB. This way,
when the SYN gets forwarded
from ECV-1 to ECV-3, the
destination IP address is
changed to 10.110.10.111, and
it’s forwarded to segment SegB,
so it can be sent to the
destination. When ECV-3
forwards it to its destination,
source NAT automatically
translates the source IP address
ECV-3’s LAN address. This is
part of the Auto Source NAT
feature enabled for this segment.

Skipping Overlays
It’s possible to configure each Business Intent
Overlay to use or skip each segment. The
default is for each Business Intent Overlay to
use every segment. However. if you want to
disable a Business Intent Overlay for a
segment, click in the Overlays & Breakout
column, and then click to toggle the setting
for that overlay and segment.

Per Segment Firewall Zones

We previously showed how to set Zone Based Firewall security policies for intersegment traffic. This can be
done globally from the Routing Segmentation tab, or on individual appliances from the Security Policies tab. Be
sure to select the correct source and destination segments, and then configure rules for the from and to firewall
zones. This example shows a rule that allows traffic to go to the 10.110.120.0/24 subnet from the Default zone
in segment SegA to the Default zone in segment SegB. Although both firewall zones are called Default, they are
Student Guide Page 72

in different
segments, so they
are treated as
different firewall
zones. Traffic flow
between these
firewall zones will
be denied by
default unless a
rule specifically
allows some or all
traffic between
them.
Student Guide Page 73

QoS: Quality of Service

Review of QoS Settings in BIO
The traffic class is part of the QoS
configuration for the overlay. The appliance
uses it to determine into which Shaper traffic
class it puts packets routed into an overlay. It
affects the building of QoS policies on the
appliance.
The behavior of the individual traffic classes,
and how they prioritize traffic is controlled by
the Shaper. The Shaper configuration screen is
shown here. All overlays use the default global
Shaper. You can also set the DSCP settings
here. LAN DSCP sets the bits in the payload
packet’s IP header. WAN DSCP settings control the bits in the tunnel packet IP header seen by the upstream
service provider. The Shaper configuration is best managed via template groups.

The BIO Can Trust or Set Both DSCP Markings

Here is an example of how
DSCP markings work in QoS
policy. On the left we see a
packet come in from the
LAN that matches the
CriticalApps BIO. The
computer marked it with EF.
EdgeConnect is configured
for QoS to trust-lan on the
LAN side, so it preserves EF
in the Payload IP Header
and sets the IPsec header’s
DSCP markings to CS5 on
the WAN side.
The EdgeConnect puts the packet in the tunnel to B. When the packet arrives at the remote end, the
EdgeConnect removes the outer header and processes the packet based on the DSCP configuration of the
devices at the remote site preserving the EF marking. Likewise it sends another packet marked with EF for the
RealTime Business Intent Overlay.
The EdgeConnect is configured for QoS to 25 on the LAN side. So, instead of trusting what came in the LAN, it
marks the Payload with a DSCP of 25 in the payload packet’s IP header and sets the IPsec header’s DSCP to
af33 for the on the WAN side.
The EdgeConnect puts the packet in the tunnel to B. When the packet arrives at the remote end, the
EdgeConnect removes the outer header and processes the packet based on the DSCP configuration of the
devices at the remote site. This time the server gets a value of 25 even though the computer originally sent EF.
Student Guide Page 74

Two Pieces to QoS

There are two pieces to EdgeConnect QoS: the QoS policies and the Shaper. QoS policies determine which
traffic class each packet will be placed in and allow changing the DSCP markings in the tunnel packet headers,
and the headers of the payload packets they carry. The Shaper determines the behavior of individual traffic
classes, including their priorities and limits.

Max Bandwidth
As a best practice, you should
total up the speeds of the WAN
links on the WAN routers and
configure that as the MAX WAN
Bandwidth. Make sure the
appliance has enough bandwidth
on its WAN interfaces to fill a link
that size. One thing to remember
is that the total inbound and
outbound system bandwidth is
defined in the deployment profile.
These configured values appear
in the Shaper configuration.
When configuring the Max Bandwidth, you need to consider the speed of the appliance WAN interfaces and
the speeds of the WAN links on the routers that are fed by that appliance WAN interfaces.
If you set the MAX WAN Bandwidth too low, you will not be able to fill your link and some of them might be
under-utilized. If you set it too high, you may overrun the appliance WAN links, or cause congestion and drops
on the WAN-side routers.

Traffic Class Management in the Shaper

Now we’ll look at the Shaper configuration. Remember the QoS policies determines which Shaper traffic class
packets entering an EdgeConnect appliance are placed in for processing. The configuration of the traffic
classes determines how likely packets are to get WAN bandwidth at any given point in time. It’s worth noting
that the Shaper only needs to limit transmission when you start to run out of bandwidth and congestion occurs.
Individual traffic class behavior in the event of congestion is controlled by the Shaper configuration. There are
up to 10 traffic classes per Shaper, and you can send traffic to any of them.
Each traffic class in a Shaper is prioritized, and the packets in that class are processed according to that
prioritization. Classes with a higher priority, meaning the ones with the smallest number in the priority column
get processed ahead of classes with a lower priority. Classes with equal priorities are treated equally. So, in this
example, the highest priority traffic class is traffic class 2, labeled RealTime, which has a priority of 1. The
second highest priority of 2 is for traffic class 3 which is labeled CriticalApps.
Student Guide Page 75

When allocating BW, the appliance will first satisfy the Min Bandwidth for each traffic class in use. You configure
this as a percentage of Max Bandwidth.
If there is any BW left after satisfying the minimum BWs for each traffic class, then the ratio of Excess Weights
are used to allocate any remaining bandwidth.
Max Bandwidth for each traffic class is next and is generally always left at 100% of Max Bandwidth.
When a packet is considered for transmission, if it has been in the queue for a length of time exceeding the
Max Wait Time, it is dropped.
It is possible to rate limit individual flows in each traffic class to keep large flows from dominating the traffic
class by setting absolute value on the transmission bandwidth available to each flow. If you leave it set to 0, no
rate limiting is imposed on flows in that traffic class.
Finally, it’s important to remember
this rule: To avoid starving any
traffic class, the sum of the Min
Bandwidth percentages for traffic
classes being used should not
exceed 100% of the Max
Bandwidth. For example, if you are
using three traffic classes, you
could give 33% to two of them and
34% to the other. If the sum of
your Min BW values exceeds
100%, when the appliance
becomes congested, then the
lowest priority classes might not
be serviced.

Shaper Operation Basic Rules – 2 Passes

We are going to walk through some
examples of Shaper behavior, but before we
do, here are some general guidelines for
configuring traffic class behavior in the
Shaper. First, if needed, define the Minimum
BW for each of the traffic classes in use.
This defines the guaranteed bandwidth for the traffic classes and is optional. You use the defaults of all zeros if
you want. Second, set the ratios of the weights. The ratio of the different weight values is used to allocate the
portion of bandwidth to each traffic class.
Remember if the minimum bandwidths are all set to the current default of zero, then only the weights will be
used to allocate bandwidth. Of course, the configured Maximum BW, which is the total wan BW configured on
the deployment profile, cannot be exceeded, nor can any traffic class exceed its Max BW. No flow can exceed
the configured Rate limit for the traffic class it’s in. Finally, packets that exceed their Max Wait Time are
dropped.

Shaper Examples (1/2)

In this example, the Max BW for the appliance is 100 Mbps, and only two of the traffic classes have packets
queued up. Guest has 100 MB, and Default has about 1 GB queued. The priorities are set to one, and all the
Min Bandwidth settings are set to 0. This means that only Excess Weighting will be used to allocate bandwidth.
Student Guide Page 76

The Excess Weighting for all the five traffic classes in use add up to 100. This makes it easy to incorrectly think
of the Excess Weighting values
as percentages. However, in
this example, the only two
traffic classes with data in them
are Guest and Default, with
equal weights of 10. As a result,
these queues will be serviced,
using weighted round robin.
Because the weights are equal,
both classes will end up
sending 50M of data in this
time interval, at which point we
have used 100% of Max
Bandwidth.

Shaper Examples (2/2)

Let’s look at an example
where we are using
priority and minimum
bandwidth to allocate
bandwidth to the traffic
classes. You can see here
we are still using a Max
Bandwidth of 100 Mbps
for the appliance. We have
traffic queued up for the
CriticalApps and Default
traffic classes. CriticalApps
has 40 MB queued up and
Default has 1 GB ready to
transmit. Because
CriticalApps has the
highest priority with a value of 1, the Shaper will satisfy its Min Bandwidth and transmit 25 MB of the traffic,
leaving 15 MB in the queue.
Next, the Shaper will satisfy the minimum for the Default traffic class with a priority of 9, and transmit its Min
Bandwidth of 10 MB, leaving 990 Meg in the traffic class. That means the appliance has transmitted a total of
35 MB in this time interval so far and still has 65 MB available. The appliance uses the ratio Excess Weighting
to allocate the remaining 65 MB.
CriticalApps will get 1000 times more chances to transmit than Default, so it sends all its remaining 15 MB
while Default only sends 15 KB Then the Default traffic class, which has been getting 1/1000th of the Max
Bandwidth, will get a chance at the rest of the bandwidth in this time interval. It will transmit its remaining
49.85 MB since it's the only traffic class with data queued. This accounts for a total of 100 MB. We have
utilized 100% of the Max Bandwidth in this time interval.

Traffic Class Minimums Must Be Set Carefully

In this example there are two sites, each with a 10 Mbps link, and the tunnels to each of those sites have full
use of the Max Bandwidth. We configure traffic class minimums for 1 Mbps for each class in use, so even if we
Student Guide Page 77

are using all 10 traffic classes, each will be guaranteed no more than 10% of the bandwidth. At any point in
time, our Excess Weighting will divide up the rest of the bandwidth if there is any left.
Now imagine we add a new site with a 1 Mbps link. Since the Min BW for each traffic class is 1 Mbps, equal to
the full BW of the new tunnel, this means that assuming that there is sufficient traffic queued, any one of the
traffic classes, starting with the one with the highest priority, can completely fill the links, not providing service
to lower priority traffic classes.
The solution is to set the priorities
for all traffic classes to 1 and the Min
BW for each traffic class to 0.
Because all the Min BW settings—at
0—are always satisfied, only the ratio
of Excess Weighting will be used to
allocate bandwidth. When you do
this, each of the traffic classes gets
an amount of bandwidth in each
tunnel that is proportional to the
weights. This keeps one traffic class
preventing the others from being
processed.

High Level Data Flow: Tunnel Traffic

This diagram shows a
high-level data flow of
how the different
types of policies are
applied. These
policies can be
created by Business
Intent Overlay
configuration or
manually. First, the
route policy matches
the packet to an
overlay or destination.
Then, the QoS policy
defines which traffic
class a packet will be
placed into. Optimization policies then define the Boost features to be applied. Bandwidth is allocated
according to the Shaper configuration. When bandwidth is available to transmit the packet, it’s sent to the
egress interface and put into the correct tunnel. Security policies are applied last, after the egress zone is
determined.
Student Guide Page 78

Intrusion Detection & Prevention

Intrusion Detection (IDS) and Protection Services (IPS)
The Intrusion Detection/Prevention System (IDS/IPS) monitors traffic for threats and malicious activity. It
generates threat events based on preconfigured rules. Packets are copied and inspected against signatures
downloaded to Orchestrator from Cloud Portal. The Orchestrator sends to the signature file and any rules that
have been added to the allow list to the appliances. IDS designates traffic for inspection using matching rules
enabled in the Zone Based Firewall. IPS protects traffic by matching a signature and then performing a
configured action of Drop, Inspect, or Allow. Use the Intrusion Detection/Prevention tab to view IDS/IPS status
or state, or to modify the IDS/IPS configuration for appliances you select in the appliance tree.

Automated Updates Against Emerging Threats

The Cloud Portal provides a daily update of threat
signatures to the Orchestrator which sends them to the
EdgeConnect appliances.

Configuring IPS Is a Simple Two-step Process

Perform these two steps to configure IPS:
1. Apply the
IDS/IPS
modes.
2. Specify the
IDS/IPS
signature
and action.

IDS/IPS Main Tab

This is the main
screen that has
buttons to apply
IDS/IPS to
EdgeConnect
appliances and
manage the global
allow list. You can
also upgrade the
signatures. You can
also view
information about
events and stats.
Student Guide Page 79

IDS/IPS Signature: Search and Filter

You can enter
keywords into the
Search Rules field
and adjust the Show
Rules drop-down
menus of Class Type,
Severity Type, and
Action Type.

IDS/IPS Events and Stats

You can view IDS/IPS events and
stats. The Events icon shows this
information for each logged event:
• Date
• Rule ID
• Message
The Stats icon displays these graphs:
• Packets per second sent to
the IDS/IPS
• IPS Flow Drops (Cumulative)
• Threats Detected
• Bits per second sent to the
IDS/IPS

IDS/IPS Allow-Listing
You can add signatures that relate to threats
that do not apply to your network.
EdgeConnect appliances do not check these
signatures during IDS/IPS processing.
Student Guide Page 80

Configuring IDS/IPS Rules

You configure IDS inspection and IPS protection from Zone Based Firewall security policies. You can configure
an action of allow, deny, or inspect for each policy’s rules. Flows that match IDS inspection or IPS protection
policy are replicated to the IDS/IPS engine.

IPS Details on the Flows Tab

The Flows tab
now includes
an IPS
Dropped Flow
Characteristics
filter. Also, the
Security
section of the
flow details
page shows
Deny – IPS
Drop in the
Action field
and an IPS
Drop Reason
for such drops.

Events and Logs

The Logging template shows the log
facilities for IDS/IPS events. Suricata
logs are written to the System logs,
and events are written to the IDS/IPS
Events facility. You can also configure
secure logging for remote log
receivers.