Silver Peak Training DST SLIDES 8.10.X-8.3.0.x v1.6.4

A Hewlett Packard
Enterprise Company
Deploying SDWAN
Technologies
(202a - DST)
ILT Version 1.6.4 (April 2021)
Silver Peak Training

training@silver-peak.com
Based on Orchestrator 8.10.13 and EdgeConnect OS 8.3.1.x
Hello. Welcome to the Deploying SDWAN Technologies course. This material

is based on Orchestrator v8.10.x and EdgeConnect Operating System (ECOS)
version 8.3.1.x.
Deploying SDWAN Technologies -

Version 8.10.0/8.3.1.SP - August 2020 1
Class Introductions
If you have not downloaded
1. Name the LAB Guide, search for the
2. Your Location ACTION REQUIRED
email that was sent out.
3. Role/Company (Check junk/spam folder)
4. Any prior Silver Peak &

Networking
experience/training/certs?
5. What do you want to get
from this class?

Objectives
– Become familiar with Silver Peak EdgeConnect appliances and management
software
– Understand the basics of the individual technologies and how they integrate
comprehensively to implement the solution architecture
– Be able to deploy typical network designs
– Be able to install, maintain and administer a
Silver Peak SD-WAN
– Earn your SPSP (Silver Peak SDWAN Professional)
certification!
When you complete this course, you’ll have become familiar with Silver Peak
EdgeConnect appliances and management software.
You’ll understand the basics of the individual technologies and how they
integrate comprehensively to implement the solution architecture.
You will also be able to deploy typical network designs, and install, maintain
and administer a Silver Peak SDWAN.
Additionally, you can earn your Silver Peak SDWAN Professional, or SPSP,
certification if you use the knowledge you take from this course and pass the
SPSP exam.

Agenda: Instructor-Led
– Feature Terminology & Definitions – Automated Provisioning and Deployment
– Silver Peak Products & Licenses • LAB 10 – Complete ECV-3 Installation & Apply The Campusnetwork
Overlay
• LAB 1 – LAB Familiarization & Orchestrator Installation
• LAB 11 – Zero-Touch-Configuration (ZTC) of ECV-4
– Licensing Process
• LAB 12 – Completing Registration of ECV-4 In Orchestrator
– Orchestrator Overview
• LAB 2 – Orchestrator Configuration & Licensing – Virtual Routing Redundancy Protocol
– Path Selection • LAB 13 – VRRP Configuration
– Deployment Modes – Backup, Restore, Image Management

– Data Security
– Monitoring Your Network
– Configuration Process
• LAB 3 – Configure Interface Labels & Groups – Logging
• LAB 4 – Configure Deployment Profiles • LAB 14 – Basic Flow Monitoring
• LAB 5 – Template Groups Configuration – Quality of Service

– Business Intent Overlays • LAB 15 –Reporting
• LAB 6 – Configuring Business Intent Overlays • LAB 16 – Troubleshooting Tools
• LAB 7 – Completing Appliance Configuration
– Troubleshooting
• LAB 8 – Complete Registration of ECV-1 & ECV-2 In Orchestrator
• LAB 9 – Configure A Hub & Spoke Business Intent Overlay – SPSP Exam
In this class, besides viewing lectures on all the elements of installing and
managing an SDWAN network, you’ll engage in a number of hands on labs to
perform various installation, configuration and troubleshooting tasks. Well over
half the course time is spent on labs. It’s worth noting that this course uses a
virtual VMware environment and you’ll be using and installing virtual machines.
Don’t worry if you’ve never used VMware before, the detailed LAB instructions
will walk you through each task.
First, you’ll install Silver Peak management software, called the Orchestrator
from scratch.
Then you’ll prepare for the installation of appliances, by preconfiguring various

types templates in the Orchestrator. In the next steps, you’ll install and deploy
a 3 site network of appliances, bring up connections between them and move
data between the sites using FTP and CIFS connections.
Finally you’ll spend some time learning to monitor and manage your new
network and get exposed to various tool for troubleshooting a real world
installation.

Follow on Class: ASD – Advanced SDWAN Deployments
• ASD is offered as instructor led or a self-paced online course
• Two days of lecture and hands-on LAB exercises
• Hands-on LAB exercises focus on advanced deployments, troubleshooting
hints, and Routing implementations
1. Includes EdgeHA, OSPF, BGP, Route Maps, ZBF, Regions, and more
• Students attending this course should have already
completed the DST course.
• All students completing ASD will be eligible to take the
Silver Peak SD-WAN eXpert (SPSX) exam.
There is a follow on course that builds on the knowledge from this course and
covers additional topics than the basic course. The Advanced SDWAN
Deployments, or ASD, course is two days of lecture and LAB exercises, with
an emphasis on hands on labs. All students who complete ASD are eligible to
take the Silver Peka SDWAN eXpert certification exam.
Just like this course, a self-paced version is available for you to take at your
convenience. All the topics and hands-on exercises are exactly the same.

Class Details…
• Remote (Zoom) Students
1. Breaks and Meal time
2. Downloadable PDFs
3. You can annotate pdf copies of your slides provided to you using the comments and sticky
notes feature in Adobe Acrobat.
• On-site Students
1. Restrooms
2. Exits

A Hewlett Packard
Enterprise Company
Feature Terminology and

Definitions
In this section we’ll go over some of the terminology used in this course to
provide a foundational understanding for the discussion of of the many topics
we’ll cover.
We’ll touch on these to set the stage, and later on dig into each of them in
greater depth.

In case you didn’t know
• Software Defined WAN (SDWAN) is not a standard.
• Every vendor’s implementation is proprietary.
• SDWAN devices from different vendors will likely not work together to
automate your WAN.
To some people, the term SDWAN, or Software Defined WAN is something

they hear about from multiple sources, and each one of them says something
different. To others it’s an altogether unfamiliar term. There is no SDWAN RFC
or other specification for describing a universal standard on how it should
work.
1. This is because SDWAN is an emerging technology and each vendor in this

area has their own proprietary solution. These solutions do not generally
interoperate.
2. In this course, you’ll learn about Silver Peak’s approach, and how to use our
devices to automate many aspects of your network deployment and operation.

Architecture
Cloud Portal
Orchestrator
EdgeConnect
Private EdgeConnect
EdgeConnect
Internet EdgeConnect
EdgeConnect
• EdgeConnect Appliance – Transports and optimizes traffic between sites in the network.
▪ Physical Appliance – Hardware that comes with software loaded and a burned in serial number linked to an account.
▪ Virtual Appliance – Software appliance running in a hypervisor. No serial number - requires license info to link to account.
• Orchestrator – Manages, provisions and monitors the Silver Peak devices in a given network.
▪ Only one Orchestrator is normally used per organization
▪ Must register with the Cloud Portal to manage EdgeConnect appliances.
• Cloud Portal – Silver Peak’s portal on the internet.

▪ Manages licensing of Silver Peak devices in a network. Talks to Orchestrator and EdgeConnect devices. Knows all licenses and
serial numbers of physical devices. Facilitates initial connection between Orchestrator an Edge Connect devices. All devices must
register with the Cloud Portal.
First, let’s talk a little about the Architecture and types of Silver Peak products you’ll
encounter in an SDWAN environment. Here you can see a typical representation of
the internet which is essentially the Wide Area Network (WAN).
1. EdgeConnect appliances are the devices that transport traffic between sites. These
devices can be physical or virtual machines. Physical appliances use standard server
hardware and come preloaded with Sliver Peak software. Virtual appliances are
identical to the physical ones except you install the software yourself as a virtual
machine running under a hypervisor like VMware, HyperV, Xen, or KVM, on your own
server hardware. All EdgeConnect appliances need to be managed by the second
component, the Orchestrator.
2. The Orchestrator is Silver Peak’s management software and is required for

deploying and operating our SDWAN environment with EdgeConnect appliances.
The Orchestrator can manage legacy Silver Peak devices, including the VX, NX, and
VRX products, which are not covered in this course. There is only one Orchestrator
used per organization.
3. Finally there is the Silver Peak Cloud Portal. This manages licensing of the
Orchestrator and all the EdgeConnect devices. It maintains a database of all the
machines and licenses you have purchased. It also facilitates a connection between
newly registering appliances and the Orchestrator associated with your account.
We’ll go into details about how all of this works together in an upcoming module of
this course.

ENCAPSULATION and TUNNELS
Tunnel – a logical connection
EdgeConnect
between two devices, in our
case, two Silver Peak Tunnels
appliances.
• Traffic transported through a
tunnel is encapsulated.
• The tunnel packets carry the EdgeConnect EdgeConnect
source and destination
addresses of the Silver Peak
devices.
• The payload packets they carry
have the original source and
destination addresses of the end
devices.
• Note: A tunnel can carry other EdgeConnect EdgeConnect
tunnels inside it, adding a layer
of encapsulation
Encapsulation – placing a packet (e.g. from a PC or server etc.) inside another packet
• The end device packet becomes the payload of the encapsulating packet.
• The end device packet is usually unaltered except to possibly be encrypted.
10
Data Plane
Now let’s cover some terms related to network connections between the
devices.
Encapsulation is placing a data packet inside another data packet and

transporting it across the network. The encapsulated packet still carries it’s
original source and destination IP addresses. The encapsulating packet that
carries the payload have source and destination addresses that are different,
usually the source address of the device doing the encapsulating, and a
destination device that will strip off the encapsulation.
1. A tunnel is an encapsulated connection between two devices. in our case,

Silver Peak appliances use tunnel connections between them.
2. Packets entering the LAN port on one Silver Peak which are heading for a
destination across the WAN, are placed in the encapsulated tunnel
connection to a remote Silver Peak device. The packet traverses the WAN
in this tunnel, and the remote Silver Peak strips off the encapsulation. The
original packet is forwarded on the LAN to its destination, or to the next hop
LAN-side router.

Flows
Internet
EdgeConnect
Tunnels
Flow EdgeConnect EdgeConnect
EdgeConnect EdgeConnect
• Flow – A stream of packets transmitted between two endpoints

Usually identified by at least a Protocol, Source Address and Destination Address (and possibly
source & dest port numbers). May or may not be tunnelized.
o Stale Flow – A flow that existed prior to a configuration change on a Silver Peak that is operating under old
rules.
• E.G. A policy change is made after a flow has already been established
• Note: In current software, flows are automatically reclassified every minute. This may correct many issues, but it does not
reset a flow (send an RST). A flow reset may be required after certain configuration changes.
11
Data Plane
A flow is a connection like FTP, a web session, etc. Here’s an example of a

flow that goes through a tunnel from one branch office to another. These
packets are encapsulated.
1. While the effects of many configuration changes will be felt immediately, it’s
possible that particular types of configuration changes that are dependent on
identifying the first packet in a newly establishing flow, will not affect a pre-
existing flow. Thus it will continue to operate under the previous configuration.
These flows are called stale flows. So a Stale flow is one that existed before a
configuration change was made. In these cases, it’s necessary for the
endpoints to break and reestablish the connection to operate under the new
rules.

Passthrough Flows
Passthrough Flow
(Local Internet Breakout)
• Passthrough traffic – Flows NOT in an EdgeConnect

Tunnels
SD-WAN tunnel between two
EdgeConnects.
o Traffic is received by an EdgeConnect, but EdgeConnect EdgeConnect
NOT tunneled/optimized/etc. to another
EdgeConnect
o Passed through to the next hop router for
forwarding to its destination. Internet
• Local Internet Breakout – Another way

of referring to traffic usually destined to a
non Silver Peak device. Usually refers to Passthrough and Local Internet Breakout
SaaS/IaaS traffic that may be natively traffic can still be treated with Silver Peak QoS
secured by other means (TLS, SSL, etc.) before being forwarded to the next hop.
12
Data Plane
Some flows, are not passed between two Silver Peaks. In the example shown
here, we see traffic that is being sent from a branch office directly to the
Internet. Any flow that isn’t encapsulated (not in a tunnel) is called a
“Passthrough” flow. Essentially, the EdgeConnect behaves as a router. As
such, traffic is not enhanced or optimized for Passthrough flows.
In today’s cloud-first world where SaaS and IaaS become extensions of the
enterprise network, it is critical for the business to reach these cloud services
by the most efficient and highest performing means. Frequently, cloud
applications perform better from home than from the branch in the case of
Office 365, for example. This is referred to as Local Internet Breakout.
Moreover, different applications often require different treatment when it comes

to how they are handled from a security perspective. For example, a major
financial application processing a sensitive transaction might require
encryption regardless of the type of transport being used to meet compliance
requirements, while SaaS applications could be left to rely on their own native
capabilities (e.g., TLS).
Like any other networking device, Passthrough traffic can still be treated with
Quality of Service.

Underlays & Overlays & BIOs GPS Analogy
GPS Profile
– Business Intent Overlay → Determines Overlay Streets to Drive On
– Overlay → Selected Underlay(s) to Use
– Underlay → The Overlay is Calculated Real Time
based on current “road” conditions
▻ Ethernet
▻ MPLS Internet
▻ LTE
13
The next concepts we will discuss are Underlays, Overlays & Business Intent Overlays (BIOs). This is a
high-level discussion to help visualize the concepts and differences between these key items in a Silver
Peak SD-WAN. Here we see a representation of the Internet. Of course on the Internet, there are tons of
networking devices that are connected via various transport methods such as Ethernet, MPLS, LTE, etc.
1. From a Silver Peak point of view, the concept of an Underlay simply refers to the physical transports
which the appliances are connected to. Another way to look at it, is Underlays are the circuits that
are available to the EdgeConnect.
2. Using a GPS as an analogy, an Underlay is like all the available streets, expressways, and
highways that exist for you to drive on.
3. Since there are many paths or routes over the Internet, an Overlay is a LOGICAL concept that that
is essentially the forwarding path used.
4. Similar to the highlighted route your GPS selects that you are to drive on to get to your destination,
5. GPS's have the ability for users to select how paths are calculated: for example you can choose
settings to avoid Toll Roads, use fastest route vs use shortest route, avoid highways, etc. If GPS's
had the ability to configure different profile settings depending on why or where I am driving, that
would be like a Business Intent Overlay. A more apt way of thinking of a BIO is more like a
“Business Intent Profile”. If you're going to work, you may want to take the shortest path to save gas
so you would create a "Work" profile.
6. Likewise, a Business Intent Overlay is a profile that you, as the administrator, configure with all the
settings to determine how the Overlay is calculated based upon the "intent" of particular types of
traffic: such as guest traffic, voice traffic, or storage traffic.
7. If you're driving the kids to school, you may want to take the fastest path and take advantage of
HOV lanes since you're not alone... so you might have another profile called "School". Note that for
the same types of traffic, the Overlay may not always be the same. Just like sometimes the GPS
might have you drive over different streets to get to work because there is an accident or roads have
been closed.
8. So to re-iterate, this GPS Analogy is a very applicable way to visualize the distinctions. The Overlay,
which is the best path to follow… is determined real-time by the BIO… based on current Underlay
conditions when matched traffic is to be forwarded.

Underlay and Overlay Tunnels
– Underlay Tunnels – Overlay Tunnels
▪ The physical transport network ▪ Logical connections
▻ MPLS, Internet, LTE or other ▻ Uses one or more underlay
transports. tunnels.
▪ Site to site connections built using ▪ Uses multiple underlay tunnels and
IPsec_UDP* tunnels. transports depending on configuration
Overlay Tunnel
* IPsec_UDP is the default. Other tunnel types are supported

14
So to summarize, there are two kinds of tunnels: Underlay and Overlay.
Again, Underlay tunnels are the physical transport network built using IPsec
UDP tunnels between sites. These use the transport network connections
such as MPLS, Broadband, and LTE that you buy from one or more internet
service providers.
1. Overlay tunnels make use of one or more underlay tunnels. Again, Overlay
tunnels are LOGICAL connections that make use of one or more underlay
tunnels. So there is only one IPsec tunnel established and used. When using a
GPS to drive, you don't build new roads each time, Right?
2. Simply data can be distributed across multiple underlay tunnels using

multiple transport methods depending on the configuration of the appliances
routes and how you want to dirrect different types of traffic.

Business Intent Overlays (BIO) More than one BIO can use the same
underlay tunnels in different ways
– The set of policies and

configuration parameters
that determine:
▻ Which transports are
used for underlays
▻ Which underlays are
used for each overlay
▻ How the traffic is
distributed across the
underlays
▻ And more…
Overlay Tunnel
15
The business intent overlay, again, is a set of policies that determine how
different types overlay tunnels will be constructed, which traffic will be routed
through which overlay, and how the traffic flowing through each of the overlays
will make use of the underlay tunnel connections.
1. It’s possible for multiple overlays to use the same underlays differently, so
different traffic types will be treated differently. For example, you might want
your voice traffic to use expensive, but reliable MPLS networks, but email and
file sharing could flow over the Internet normally, and only fall back to MPLS in
the case your broadband connection goes down.

Traffic Handling Features
– Path Conditioning
▻ Forward Error Correction (FEC) – Uses parity packets to reconstruct lost
packets to avoid retransmission
▻ Packet Order Correction (POC) – Reorders any out-of-order packets to avoid
retransmission
Overlay Tunnel
– Dynamic Path Control (DPC)

▻ Methods to dynamically select the appropriate underlay tunnel within a BIO’s
Link Bonding Policy.
16
Silver Peak appliances all have some built in basic traffic handling
enhancements that ensure your data gets across the network reliably with
optimum handling.
Silver peak Path conditioning features include Forward Error Correction and
Packet Order Correction. Forward Error Correction, or FEC, adds additional
parity information to the data stream so that even if some packets are lost in
transmission, the receiving appliance can reconstruct the missing data from
the parity packets, thus avoiding the need for retransmission. This makes the
connection more reliable and saves bandwidth. Packet order correction or
POC, accounts for the fact that different packets in the same flow can take
different paths through the network with differing latencies. This can cause
them to arrive out of order, which can cause confusion in the receiver and
trigger unnecessary retransmissions. POC allows the Silver Peak appliance
across the network to cache incoming packets that arrive early and out of
order until the rest of the packets in the flow have arrived. It then reassembles
everything in the correct order then forwards them on to the destination on the
local LAN in order.
1. Dynamic Path Control refers to the different link bonding methods that
appliances can use to select underlay tunnels for a particular overlay. We’ll
talk more about that in the BIO section.

WAN OPTIMIZATION FEATURE - BOOST
– BOOST = WAN optimization technologies available as an extra cost option
▪ TCP Acceleration – Optimizes the TCP protocol to mitigate the effects of latency
▪ Network Memory – Deduplicates transmitted data to reduce congestion
17
Boost is a set of Silver Peak wan optimization technologies that have been
maturing for over a decade.
TCP acceleration helps to mitigate the effects of latency, by enabling local

devices to transmit a quickly as possible to the local Silver Peak appliance,
and not have to wait for acknowledgements to come back across the network
from the receiver when the TCP transmission window is full.
Network memory is Silver Peak’s disk cache and deduplication technology that
eliminates the need to transmit the same strings of data multiple times, saving
bandwidth on the network. This is especially useful for data flows like backups,
where most of the data being transmitted in a full backup is the same as the
last one.
We’ll talk about how these work in more depth later in the course.

A software defined WAN (SD-WAN)
multiple Business intent overlays
Business Traffic Internet

Goal Underlay Topology Boost?
Intent Type Traffic
Cost Backhaul
Guest Wifi Web Internet Hub & Spoke No
Savings →Zscaler
Salesforce Internet
Maximize Dual Local
Critical Apps O365 MPLS Yes
Quality Hub & Spoke Breakout
CIFS LTE
Internet
Maximize
RealTime VoIP MPLS Mesh No Zscaler
Availability
LTE
* Backup
Each Overlay is created

by a different BIO with
Underlay Tunnels → Physical Transport Networks different characteristics
Overlay Tunnels → Logical path of Underlay Tunnels
18
Now let’s bring it all together and look at the entire Software Defined WAN or SDWAN.
1. At the bottom of this diagram is the underlay network, consisting of the physical transport
connections like Internet, MPLS and LTE network connections.
Above that are 3 overlay networks. The logical options between the sites that can be built
across the underlay networks, each one optimized to support the kind of traffic that needs to be
transported.
2. The bottom overlay is for Realtime traffic like VOIP. The goal for this type of traffic is to have
maximum reliability so we want to utilize a pair of connections. Namely, one MPLS and one
Internet, from two different Service Providers and an LTE network for backup. Also, we specify
a full mesh topology so that direct point-to-point connections would be established to minimize
latency and facilitate the fastest connection. Finally, we want any internet traffic service
chained to Zscaler for full security functionality as a hosted service.
3. The middle overlay is for critical application data such as SaaS offerings or local peer-to-
peer file sharing. The goal here is to provide maximum quality and we want to use MPLS and
the substantially cheaper internet connections to transport data, in a dual hub and spoke
configuration. Likewise, since critical apps comprise up to 80% of all network traffic, let’s
implement boost, our WAN Optimization technology. We want all the sites to connect to a pair
of data center sites as the hubs and internet data is broken out locally at each site.
4. The top overlay is for guest WiFi traffic and since it’s just a service to provide web
connectivity, we use only cheap internet bandwidth to transport data, with everything
backhauled through one hub site where it is then sent through Zscaler for security inspection.
Many other configuration are possible, these are only a few, and we’ll see how to deploy an
overlay configuration that meets your needs in upcoming lessons.

Review #1: Terminology
?
1) What term describes placing a packet into an IPsec tunnel?
2) Describe/define the following:

a. Cloud Portal d) Stale flow
b. Orchestrator e) Business Intent Overlay
c. Passthrough flow f) Local Internet Breakout
3) True/False: An overlay tunnel can use one or more underlay tunnels to transport packets that
match a Business Intent Overlay.
4) How many Orchestrators would be used by a typical organization?
5) Given two tunnels named: “To_ECV-3_MPLS_MPLS” and “To_ECV-3_CriticalApps”:

a. Which do you think is an Overlay tunnel? Why?
b. Which do you think is an Underlay tunnel? Why?
?
19

A Hewlett Packard
Enterprise Company
Silver Peak Products and

Licenses
In this section we’ll take a look at the Silver Peak product line and licenses
available for different features and levels of performance.

Unity EdgeConnect Hardware (US/XS/S/M)
EdgeConnect US EdgeConnect XS EdgeConnect S EdgeConnect M
EC-M-B
Part EC-S-SR
EC-US EC-XS
Identifier EC-S-LR
EC-M-P
Small Branch/ Small Large Head Office

Typical Deployment
Home Office Branch Branch Small Hub
Typical WAN
1–100 Mbps 2–200 Mbps 10–1000 Mbps 50–2000 Mbps
Bandwidth
Simultaneous
256,000 256,000 256,000 2,000,000
Connections
Max # Tunnels 2,000 2,000 5,000 10,000

Boost Capacity 25 Mbps 50 Mbps 200 Mbps 500 Mbps
Redundancy / FRUs No No No Power and SSD
4 x RJ45
3 x RJ45 4 x RJ45 6 x RJ45
Data Path Interfaces 2 x 1/10G Fiber (-B)
10/100/1000 10/100/1000 Dual 1/10G (SR/LR)*
2 x SFP+ (-P)
21
Available platforms in the EdgeConnect product set vary in supported

throughput, available data path interfaces, and hardware redundancy. Based
on the customer’s networking requirements, they can select from the Ultra
Small, Extra Small, Small, Medium…

Unity EdgeConnect Hardware (L/XL)
EdgeConnect L EdgeConnect XL
EC-XL-B, EC-XL-B
Part
Identifier
EC-XL-P EC-XL-P
Data Center Data Center

Typical Deployment
Large Hub Large Hub
Typical WAN Bandwidth 1–5 Gbps 2–10 Gbps
Simultaneous Connections 2,000,000 2,000,000
Max # Tunnels 10,000 10,000
Boost Capacity 1 Gbps 5 Gbps
Redundancy / FRUs Power and SSD Power and SSD
4 x RJ45
4 x 1/10G Fiber (-B)
Data Path Interfaces 2 x 1/10G Fiber
6 x 1/10G SFP+ and/or 10/25G SFP28
2 x SFP+ or 2 x SFP28
Orchestrator is included with EdgeConnect 22
…Large and Extra-Large sizes. Throughput ranges from 100Mb for the small
branch US up to 10 Gb for the data center XL appliance. The Orchestrator
management software is included with the EdgeConnect product. –B = Fail to
Glass Bypass and –P = Pluggable 1/10Gbps SFP+ and 10/25 Gbps SFP28
support.

EdgeConnect Virtual Appliances (EC-V)
– Identical UI and provisioning to physical appliance
– VMs must be licensed to register – could be manual or using an automated process
– Throughput limited by available resources and licensing of Hypervisor
• Refer to EdgeConnect Virtual Appliance Host System Requirements on Silver-Peak.com
• Physical platform it’s deployed on must support desired performance (see Silver Peak documentation)
SD-WAN Processor Memory Storage Storage
Bandwidth Cores Size Configuration
Up to 1 Gbps 2 4 GB 30 GB 2 x 7200 RPM SAS or 2 x SSD
1 to 4 Gbps 4 4 GB 30 GB 2 x 7200 RPM SAS or 2 x SSD
4 to 5 Gbps 8 4 GB 30 GB 2 x 7200 RPM SAS or 2 x SSD
• Adding Boost may increase hardware requirements (choose whichever is greater).

Boost Processor Memory Storage Storage Storage Storage
Bandwidth Cores Size IOPS MB/s Configuration
Up to 10 Mbps 4 4 GB 100 GB 100 25 2 x 7200 RPM SAS or 2 x SSD
10 to 50 Mbps 4 7 GB 100 GB 200 50 3 x SSD
50 to 200 Mbps 8 14 GB 250 GB 1000 250 4 x SSD
200 to 1000 24 30 GB 250 GB 5000 1250 8 x SSD
Mbps
23
EdgeConnects can also be deployed as virtual machines under a hypervisor.

EC-V virtual appliances are identical to in functionality and user interface to
physical appliances, except they are deployed on your hardware.
As we mentioned earlier, since an EC-V doesn’t have a burned in serial

number to identify it to the Cloud Portal, it requires licensing information to
register with the cloud portal. This could be manual, or using an automated
process, for example cloudinit, custom OVF, USB or other method.
EC-Vs are capable of 1 Gbps of throughput and higher, but like all
EdgeConnect appliances, require a license for speeds above 200Mbps. Of
course the hardware must support the required performance, so consult the
Silver Peak documentation online to make sure your hardware meets your
requirements. Don’t forget that adding Boost can require additional resources.

Orchestrator As A Service
• Manage your network from a Silver Peak hosted
Orchestrator in the cloud
• Licensed by number of devices
1. Three Subscription Tiers: Small, Medium & Large
• Tools to assist available
Orchestrator
Cloud Portal
EdgeConnect
EdgeConnect
Private
EdgeConnect
Internet
EdgeConnect
EdgeConnect
24
While all Orchestrators are virtual machines, in addition to hosting the

Orchestrator in your network on your hardware, Silver Peak also offers
Orchestrator as a hosted service in the cloud. This can save you from
managing your own device and eliminate the worry about what happens in
case of failure, as Silver Peak takes care of automatic backups and automated
failure recovery.

Orchestrator Global Enterprise
Enables large enterprises or multi-agency organizations to globally manage and monitor multiple SD-
WAN fabrics to support the requirements of different business units or subsidiary companies
1) Allows you to set up a separate
Orchestrator for each BU, for example,
controlling only appliances in that BU
2) Through Orchestrator Global Enterprise

a user has access to some or all
individual orchestrators (and manged
appliances), based on permissions
3) Allows nearly unlimited scalability using

multiple tenants (individual Orchestrator &
EdgeConnect limits still apply)
4) Use BGP to exchange routing

information and route data between tenant OGE and all tenant orchestrators are hosted by Silver Peak as a cloud
networks if needed service. Tenants can run different SW versions.
25
One additional type of Orchestrator available is Orchestrator Global

Enterprise, a product aimed at very large companies with multiple networks
and Managed Service Providers.
Silver Peak Unity Orchestrator Global Enterprise is a secure, cloud-hosted SaaS

application that enables enterprises to centrally configure and
manage multiple independent SD-WAN fabrics in alignment with business
requirements. Similarly, it helps MSPs manage multiple global enterprise-owned SD-
WAN deployments from a single management console
Each SD-WAN fabric is a deployment of the EdgeConnect SD-WAN edge platform,

managed by a secure, dedicated tenant Orchestrator. In other words, it centrally
manages multiple Orchestrator instances, with each Orchestrator tenant instance
managing an independent SDWAN fabric made up of EdgeConnect devices. The
tenant Orchestrators and fabrics are completely separate, and no data or
configuration or connections are shared between them.
If needed, you can used BGP running between different hubs to exchange
routing information and route data between tenant networks as required.

EdgeConnect Appliance Licensing
• Based on WAN Bandwidth actually used (after Boost applied)
• 20 Mbps, 50 Mbps, 100 Mbps, 200 Mbps, 500 Mbps, 1 Gbps, 2 Gbps, Unlimited
• All include:
➢ SDWAN (Overlays, Zero Touch Provisioning, Zero Touch Configuration)
➢ Path Conditioning - Forward Error Correction & Packet Order Correction
Bandwidth ➢ Dynamic Path Control (DPC)
Tiers ➢ High Availability
• TCP Acceleration (mitigates distance and latency)

• Network Memory (saves bandwidth using deduplication & compression)
• Blocks of 100Mbps - allocated as needed to individual appliances

Boost
26
Now that we’ve talked about some of these technologies and you have some
context, let’s briefly revisit how they fit into Silver Peak’s licensing scheme.
As of August 2019, a new six-tier based licensing structure replaced the old
Mini, Base and Plus licenses used previously. EdgeConnect appliances are
currently licensed according to the total throughput of the WAN interfaces on
each appliance. Each of the tiers includes BIOs, zero touch provisioning and
configuration, Silver Peak’s path conditioning technologies, dynamic path
control, high availability and more. If you have one of the old licenses, things
will continue normally until their expiration date at which time they will be
converted to the applicable tiers.
A Boost license, which is sold in 100Mbps blocks, is required to obtain TCP

Acceleration and Network Memory. TCP Acceleration mitigates the effects of
distance and latency. Network Memory reduces the amount of bandwidth
required using deduplication and compression. Boost can be allocated to
individual machines as needed.

Licensing Discussion Assume all traffic is Boosted & all links active
Total BW Total BW
Small Branch x 10 per EC License Licenses
10Mbps
20 0 300 Mbps
30 Mbps
20Mbps
50 10
100 10
Medium Branch x 5 20Mbps
200 0
50Mbps 80 Mbps 800 Mbps
HA Link 500 0
10Mbps
1G 0
2G 0
Data Center x 1
A 1Gbps
Unlimited 2
6.1 Gbps 12200 Mbps
5Gbps Boost blocks 133
100Mbps 13300 Mbps
Total All BW
B
27
Let’s do an exercise and discuss how much licensing is needed for this network.
Firstly, we must determine the total bandwidth per EdgeConnect. This will allow us to determine which bandwidth tier needs to be
purchased. Looking at the Small Branch, we can see that there is a 10Mbps MPLS link and a 20Mbps Broadband link. So this means
that each EdgeConnect at a Small Branch will require…
1. 30 Mbps. Continuing on, how much bandwidth does each EdgeConnect use at the Medium Branches given the 20Mbps MPLS, 50
Mbps Broadband, and 10 Mbps LTE connections?
2. That’s right! 80 Mbps per EC at Medium Branch because each EC needs to be licensed for all WANs in the HA pair. At the single
Data Center, we see there is a 1 Gbps MPLS, a 5 Gbps Broadband, and a 100 Mbps LTE connection. So together each EdgeConnect
requires…
3. 6.1 Gbps per EC at the data center. Note that 6.1 Gbps is where this network required licensing so we do not need any 500, 1G or
2G licenses. Now that we know the requirements of every EdgeConnect in our network, we can calculate the number of licenses at
each bandwidth tier is needed. How many 50 Mb licenses are required? So we need to look at our appliances and determine how
many of them do not exceed 50 Mb? At the Small Branches, we see that the total BW per EdgeConnect is 30 Mbps. All the other
devices are higher than 50. Therefore,
4. We need ten 50 Mb licenses since there are 10 Small branches.
How many 100 Mb licenses are needed? Since we have devices at 80 Mbps at the Medium branches, and there are 5 of those, we
need 5, right? Actually no. Since we have two EdgeConnects at the Medium branches, and there are five of them,
5. Medium branches therefore will each need ten 100 Mbps licenses.
6. Lastly, the two Data Center appliances remain and don't need 200, 500, 1G or 2G licenses because they are handling a total of 6.1
Gbps each. So the Data Center machines will each need an unlimited license for…
7. a total of two. Now that we have figured out the number and types of licenses we need to handle outgoing WAN bandwidth, we
need to now consider how much Boost is required assuming all traffic is Boosted and all the links are active.
8. So, we have a Total BW used by small branches (10 x 30) at 300 Mbps. How much total bandwidth is used by the Medium
branches?
9. 10 x 80 for a total of 800 Mbps. And at the Data Center…?
10. 2 x 6.1 Gbps for a total of 12,200 Mbps. Adding them all up we get…
11. The Total BW by all machines equals 13,300 Mbps. So, how much Boost is needed? Remember they are sold in 100 Mbps blocks.
13,300 divided by 100 equals…
12. 133 blocks of Boost

Licensing Process Overview New Appliance boots, is
– Network wide policies can easily be pushed down from the Orchestrator discovered by Orchestrator
Deployment
Template
Business EdgeConnect
Profile Cloud Portal
Groups
Intent
Overlays Orchestrator
EdgeConnect
Orchestrator and
Virtual Appliances
use an
Registration
Account Name/Key
toapproved
connect to the
Cloud Portal Configuration pushed to
appliance and network
EdgeConnect EdgeConnect connections built automatically
28
Using the automated tools built into Orchestrator, administrators can easily
manage even the largest EdgeConnect deployments centrally by using policy-
based templates. Everything from path control to QoS to path conditioning can
be managed and maintained with Orchestrator. It is this control that gives
EdgeConnect flexibility in deployment, management, maintenance,
troubleshooting, and visibility.
In this example,
1. We add a new EdgeConnect to the network. Previously configured
templates,
2. including Deployment Profiles, Template Groups and Business Intent
Overlays created and stored on the Orchestrator, are
3. Pushed to the appliance when the operator approves it, and underlay and
overlay network connections are automatically created to the desired peers
using the correct link speeds, addressing and policies.

Review #2: Products and Licensing
?
6) True/False: The Orchestrator is always hosted outside a customer’s network.
7) True/False: The Cloud Portal automatically builds tunnels from a new device to existing
appliances, then tells the Orchestrator the device has been registered.
8) True/False: A 100 Mbps license, or 1 block, is required to handle 75 Mbps of LAN traffic.
9) What is Boost?
10) Which Boost Feature reduces the bandwidth required using deduplication and
compression??
11) Name the other Boost Feature.

a. What does it do?
12) True/False: Boost is included with an Unlimited License.
13) How many blocks of Boost are needed for 4.15 GB (41,500 Mbps)?
?
29

45
LAB 1 LAB Familiarization and Orchestrator C

Installation LA
R
The hands-on labs in this course have been

meticulously crafted to not only enhance your
learning experience, but also to lead you into pitfalls
of commonly experienced misconfigurations. Please
follow the instructions, TASK-by-TASK and Step-by-
step. Most students who follow the instructions
sequentially in order have no issues with the LAB
exercise and have the best experience.
For example, the first Task in this LAB is to read and
familiarize yourself with the LAB environment and
logistics. You will NOT be configuring anything until
Task 2. Eager students who assume that the IP
addresses in the table should immediately be
configured will get lost, because the exact process
is documented for you later on.
Enjoy your labs!

Review #3: Orchestrator Setup Lab
?
14) True/False: The LAB steps are only a guideline. If you simply look at the
screenshots, you can get through the LAB tasks much faster?
15) True/False: I should have written down my ReadyTech LAB Access Code.
16) Why should you select Thin as the Disk Provisioning option when installing
the Orchestrator?
17) True/False: RFC-1701 defines the Enterprise SD-WAN standard.
18) How can you switch between your current window to easily view the LAB
topology?
?
31

Silver Peak Special Sauce
• Dynamic Path Control

• Path Conditioning
• Boost
In the United States, “Special Sauce” refers to sauce that is added to foods,
that enhances and improves the flavor. Typically it is a “secret recipe”. In this
module, let’s look at some Silver Peak specific technologies that differentiate
us from the rest: namely Dynamic Path Control, Path Conditioning, and Boost.

The WAN is Changing
CUSTOMERS MOVING FROM MPLS TO HYBRID MPLS/INTERNET OR DUAL INTERNET FOR WAN
Traditional WAN MPLS
Internet
High Loss, High Latency,
Low Security
Hybrid WAN Low Cost
MPLS
Low Loss, Low Latency,
High Security
High Cost
33
This picture shows the typical choice of many people who are looking for a
reliable network connection. They purchase an MPLS network connection from
their service provider, but of course this comes at some cost, and additionally
they want to have backup if their primary connection goes down.
1. That’s why many users today are supplementing or replacing their high cost
MPLS connection with public internet connections. While MPLS can offer
lower loss and latency, a public internet connection can provide lower cost
redundancy.

WAN Optimization Technologies
Boost
L4 TCP ACCELERATION
DPC IPsec
POC FEC
Packet Packet Forward
QoS Dedup LZ Comp Dynamic
Coalescing
L3 Order
Correction
Error
Correction
Path
Control
NETWORK MEMORY PATH CONDITIONING
Mitigates the effects of latency and Mitigates effects of loss and

reduces Congestion & Bandwidth variability
Requirements
34
This illustrates from a Layer-3 and Layer-4 perspective where and in what
order our different technologies operate out the WAN interface. Based on the
Business Intent Overlay traffic has been matched to,
1. Quality of Service is applied to determine which outgoing traffic class the

traffic should be sent out of.
2. If Boost is to be applied, TCP Acceleration mitigates latency on eligible
traffic and Network Memory then reduces congestion & bandwidth
requirements. This is done using deduplication algorithms, Lempel-Ziv
compression and packet coalescing by reducing the number of receive
interrupts to significantly minimize processing overhead and power
consumption on the system.
3. The amount of parity is calculated for POC and FEC and then
4. forwarded out the Ipsec tunnel based upon the Dynamic Path Control
options selected in the BIO. Let’s look at that first…

Dynamic Path Control and
Link Bonding
In this next section, we’ll discuss how Silver Peak appliances can use various
criteria to continuously and automatically choose the best path to transmit the
data over. This is called Dynamic Path Control and is controlled by
configuration parameters called Link Bonding Policies. DPC and Link Bonding
are related, but not synonymous terms.

Dynamic Path Control (DPC)
– The ability for the appliance to choose the appropriate underlay tunnel on a per-
packet basis
– Used when there is more than one available tunnel to the destination
– Dynamic Path Control is controlled on a per Overlay basis by configuration options
called Link Bonding Policies.
– Link Bonding Policies vary in the following three line characteristics:
1. Forward Error Correction (FEC)

2. Quality
A. Loss Overlay Tunnel
B. Latency
C. Jitter
D. Mean Opinion Score (MOS)
3. Load-balance
36
Recall the GPS analogy: DPC and Link Bonding Policies are some of the individual
configuration options that make up the total driving profile or, in our case, the BIO, that cause it
to choose a particular path at the given time based on various traffic conditions.
When you have multiple transports available, perhaps from multiple service providers,
Dynamic Path Control is the Silver Peak term for the ability for the appliance to choose the
appropriate underlay tunnel associated with an overlay on a per-packet basis. Part of Dynamic
Path Control allows you to select different underlay Link Bonding Policies which affect how
much FEC ratio is used and what failover times are, for example.
There are four Link Bonding Policies that are configuration options within the BIO that choose
which underlays are used for each overlay, and how the underlays are used in a given overlay.
We’ll go over these in more detail later. For now, understand that these policies vary by
overlay based upon the Business Intent of matched traffic.
1. These Link Bonding Policies utilize a combination of three line characteristics:
2. Forward Error Correction allows you to send duplicate data streams to the same
destination appliance over multiple primary underlay tunnels, for bullet proof reliability,
even in cases of severe packet loss.
3. It’s also possible to choose the best primary tunnel based on the Quality; which is
determined based on the amount of loss, latency, jitter, and on the newest code, the Mean
Opinion Score (MOS) on available links. MOS is an industry-standard to measure voice
quality.
4. Finally, with multiple primary transport networks in an overlay, you can load balance
across the paths based on the percentage of link utilization. We’ll talk about the different
link bonding policies available in each overlay in a later lesson.
So, in a nutshell, Dynamic path control is the set of technologies that let Silver Peak
appliances determine the best path on a per packet basis based on current network conditions.
Link Bonding Policies are groups of affect how DPC operates on a per overlay basis.

Dynamically Route Traffic
Steer traffic based on link quality
All other traffic
Internet
Data Center Higher Loss, Latency Remote Site
Real-time
Real-time
X
MPLS
Lower Loss, Latency
37
Here is an example of a network with two tunnels between a pair of

appliances. One goes over an expensive, but more reliable MPLS connection,
while the other tunnel goes over an economical, but lower performing Internet
connection.
Here’s an example of directing traffic of different types over different paths

based on the quality of the link. Real time traffic, like VOIP for example,
demands high link quality because it doesn’t tolerate loss well.
1. But what happens if that link goes down, or begins to experience high
packet loss?
2. In that case the new real time traffic flows will automatically begin to go
over the other link. You can route traffic over the path with the least loss or
latency, or jitter using Silver Peak Business Intent Overlays.

Packet-Based Load Balancing
– Utilize WAN circuits that are currently unused
– Intelligently direct traffic based on % tunnel BW utilization
4G / LTE Packets are

reassembled on egress
MPLS 8 5 4 2
8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1
Internet 7 6 3 1
Packets are distributed proportionally

across the aggregated link
38
This illustrates how when appliances are load balancing across multiple paths,
incoming packets are distributed across parallel tunnels through MPLS and
Internet connections and reassembled in the correct order by the Silver Peak
at the remote end

Application SLA across any Transport
Increase user productivity and satisfaction
Predictable, non-disruptive
application performance even during
transport brownouts or outages Application
• Tunnel bonding Overlay
• Path conditioning Internet

Underlay
• Packet-based load sharing
MPLS
Underlay
Silver Peak Live View monitors network underlay

and application overlay performance in real time
39
The screen shot on the right shows built in real time graphing from a Silver
Peak appliance with internet and mpls underlays that are part of an application
overlay. The brown sections indicate where loss exceeded a desired threshold
of performance and traffic was rerouted to a more efficient path. You can see
that even though the underlays were experiencing loss at various points, the
overlay at the top stayed green, indicating that dynamic path control adapted
to changing conditions and kept overall performance in the desired range for
this Overlay.

Caveats & Best Practices Tunnels
–Parallel load balanced paths are only between Site 2

a single pair of appliances Site 1
Dynamic
LAN WAN
Path
• Paths to the same site, but different appliances won’t Control
work
Load sharing / DPC uses multiple underlay

connections between the same pair of devices Site 1
Dynamic
LAN
–Be consistent with manual rules on both ends
WAN
Path
Control
• Otherwise you may get unexpected results
Site 2
40
It should be pointed out that parallel paths that can be load balanced must be
only between a single pair of appliances, not a pair of sites. For instance, the
two tunnels shown in the top picture between site 1 and 2 will be able to
support Dynamic Path Control (DPC), but the two tunnels in the lower picture
won’t support DPC because they don’t terminate in the same pair of
appliances.
Various path control options are available when configuring Business Intent
Overlays in your Orchestrator.

Review #4: Dynamic Path Control
?
19) When using Business Intent Overlays, is load balancing between appliances flow-
based or packet-based?
20) What are Silver Peak’s three options for dynamically choosing an underlay
tunnel?
21) What four line characteristics are used to determine the quality of a tunnel?
22) Do you think local internet breakout traffic is:
a. Flow or packet based?
Site 1
b. Why?
LAN WAN
23) Can an appliance load-balance an overlay

over the Red and Blue underlay tunnels
shown in the diagram to the right?
Site 2
a. Why or why not?
?
41

Path Conditioning
Now we’ll discuss Path Conditioning. Path conditioning is a set of technologies

that help mitigate the effects of loss and out of order packets in your network
and correctly prioritize the transmission of data.

Understanding Effective Throughput
Bandwidth, Latency, and Loss all have an impact on effective throughput
40.0
Typical WAN Latencies:

30.0
- Cross US: 60-120 ms
Maximum Throughput (Mbps)
- International: 50-200 ms
100ms
20.0 50ms
10ms
- Satellite: 550 ms
10.0
Typical WAN link Typical WAN Loss Rates:
• MPLS: 0.1% to 0.5%
• Public Internet: 0.5% to 1%
0.0
% % % % % % % % % 0%
10 20 50 00 00 00 00 00 00 .00
0.0 0.0 0.0 0.1 0.2 0.5 1.0 2.0 5.0 10
Packet Loss Probability
43
Throughput in the network is negatively affected by Latency and Loss, and of

course the speed of the available links. Latency and Loss are inescapable
facts of life for any network.
Typical WAN latencies are displayed above. Crossing the USA, expect to see
60 to 120 millisecond delays. International network connections can easily see
up to 200 millisecond delays. Satellite connections are the worst. Expect
delays of around a half second, with delays of several seconds not unheard of.
If you buy bandwidth from a carrier, unless you have a private line, your
Service Level Agreement with them will likely include provisions for allowable
loss in the network. An MPLS network will typically have loss ranging from .1%
to .5%. If your data traverses the public internet, expect to see losses from
.5% to 1%. Of course loss on the internet can be much higher than this at
peak times or when there are changes in traffic loads for any number of
reasons.

Problem: Data Loss and packets out-of-order
– Symptoms:
▪ Video quality is poor with pixilation and halts
▪ Transmission rates for many applications is very poor
with high-end applications especially suffering
▪ VoIP calls suffer poor quality or experience increases
in jitter:
▻ Dropped calls
▻ Echos
▻ Clicks
– Commonly seen on shared infrastructure links

such as MPLS or Internet based IP VPNs
Solution: Path Conditioning

44
Packet loss, and packets arriving at their destination out-of-order, cause

problems in your network in many ways. In addition to the slow response
resulting from lost packets that need to be retransmitted, which may also
further congest an overloaded link, time-sensitive applications like video and
voice over IP can suffer from quality and intelligibility problems caused by
packets arriving out of order. Most carrier provided MPLS based networks
have multiple paths with equal cost to any given destination, and the different
transmission times over each of the possible paths makes it very possible that
any two given packets can arrive out of order. The combination of loss and out
of order packets can make video freeze and pixilate. VOIP audio quality can
also suffer resulting in pops and clicks, jitter induced distortion, and lost or
dropped calls.
In upcoming slides we’ll see how Silver Peak’s Path Conditioning technology
can help compensate for lost packets, and reorder packets arriving out of
order at the receiving end to eliminate these symptoms.

Loss Mitigation:
Forward Error Correction (FEC)
Path Conditioning Enables Carrier Grade Reliability Over Internet
Forward Error Correction

Lost Packet Rebuilt from Parity
Packet Lost
4 3 2 1 4 3 22 1 4 3 2 1
P P P P
If your packet loss is due to

Ratio of FEC packets Parity data added to second congestion in the network, FEC
can vary dynamically Primary data stream might make things worse
45
In order to combat the effects of lost packets in your network, Silver Peak
offers Forward Error Correction, or FEC, as part of its Path Conditioning
technology.
1. FEC works by creating extra packets containing parity data that it transmits
along with the regular data packets within the 2nd Primary link.
2. These extra parity packets can be used by the receiving Silver Peak to
reconstruct missing data if a packet is lost in transit. This is similar to the
techniques used in a RAID storage array to rebuild lost data if a redundant
disk goes down in the array. What this means is that you don’t have to
retransmit lost packets, making your network more efficient.
3. The ratio of FEC packets to Data packets can vary dynamically as network
conditions change and Silver Peak appliances detect loss in the network,
so when there is no loss, very little bandwidth is used for FEC.
4. It should be pointed out that there is some network overhead associated
with the FEC packets, as they essentially constitute extra data traversing
the network. This means if you are transmitting over a saturated link, FEC
could actually make the problem worse by trying to move more data across
a link that’s already full. The message here is to know your network, and
make sure that you have adequate bandwidth available for your needs.

Path Conditioning - 1:1 FEC
Provides Voice Quality Reliability
Parity Packets
Each parity packet contains Any lost packets are
data about all 4 packets 4G / LTE rebuilt from parity
4P 3P 2P 1P Internet 4P 3P 2P 1P
Packets Lost
4 3 2 1 MPLS 3 2 1 4 3 2 1
Appliance can recover from the loss of

multiple packets and multiple parity packets
Edge Connect Edge Connect
High Availability Link Bonding Policy
46
High availability link bonding takes advantage of FEC and parallel links to
provide extremely high reliability. In this example, we have an MPLS link and
an internet link that are logically bonded and on this link we make use of 1:1
FEC.
1:1 FEC means that we send one FEC parity packet for each regular data
stream packet. In the example here…
1. The Silver Peak on the left sends the regular data stream packets over the
internet link, and a 100% complete set of parity packets across the MPLS
link.
2. In transmission across the wan, even though there is substantial data loss
on both links, the
3. Silver Peak at the remote end can reconstruct the entire data stream. You
should never even notice the packet loss in transit because the devices at
the remote end never see it happen. This is kind of reliability you want for
traffic sensitive to loss like VOIP and video conferencing.

Packet Order Correction (POC)
– Packets take different paths through the WAN
▪ 3 Out Of Order (OOO) packets = perceived packet loss by receiver
– Inherent problem on all packet switched networks (MPLS, IP VPN)

– Silver Peak reorders prior to delivery
3 2 1 3 2 1
WAN
47
As we discussed earlier, packet switched networks like MPLS networks

managed by service providers, will almost certainly contain some out of order
packet transmissions.
1. As we can see in this animation, this is because even though packets
might be transmitted in the correct order, that fact that the individual
packets might be taking different paths through the network subject to
different latency and processing, can result in them arriving at a destination
out of order.
This can cause needless retransmissions as the receiving device will perceive
that the out of order packet has been lost, and fail to acknowledge that
packet and subsequent packets, causing the sender to have to retransmit.
Silver Peak solves this problem by accurately measuring Round Trip Time,
knowing how long to wait for packets, and caching out of order packets. It
can cache any arriving packets temporarily while it waits for missing
packets to arrive via a different path. When they do, the local Silver Peak
transmits all the packets on the local LAN in the correct order.

Review #5: Path Conditioning
?
24) When can FEC make a loss problem worse?
25) What is a typical WAN ISP SLA for loss for…

a) Internet
b) MPLS
26) What is the impact of loss on throughput for…?

a) TCP
b) UDP
27) True/False: The ratio of FEC packets to data packets is always a fixed ratio.
?
48

Boost
• WAN Optimization Technology
This module covers the basic configuration, theory and technologies

associated with Silver Peak’s Boost. Silver Peak’s Boost features accelerates
data transmission and reduce bandwidth requirements in your network.

Boost Components
TCP Acceleration and Network Memory
Overcome Latency TCP ACCELERATION

• Reliable application EXTEND DISTANCE
Mitigate latency
performance over distance
TM
Reduce Congestion NETWORK MEMORY
• Maximize available bandwidth REDUCES CONGESTION

Real-Time de-duplication of all traffic
50
Recall you can optionally enable TCP Acceleration and Network Memory with
Boost. Boost enabled latency mitigation and data reduction is based on Silver
Peak’s ground-breaking WAN optimization technology. TCP Acceleration helps
you overcome the effects of latency and Network Memory helps you reduce
the amount of bandwidth needed in your network.

Problem: High latency Symptoms:
• Cannot fill the pipe
• Applications never seem to run faster
even when there is more bandwidth
• User complain of “slowness” during
times of sub-maximum utilization
• File transfers are slow
Causes of Latency
Miles/Second • Distance
• Equipment (hop-by-hop delays)
• Loss/Congestion (retransmissions =
latency)
The farther you have to go, the higher the latency Solution: TCP Acceleration
51
One of the most common network problems is High Latency. Latency, of course, is
the delay in the network.
The symptoms that are seen include: an inability for the WAN routers to fully utilize
available WAN bandwidth, applications that operate slowly, users complaining of
slowness and slow file shares, even when there is bandwidth available.
The longer the delays in the network, the slower traffic moves, regardless of actual
link speed, because among other things, devices need to receive acknowledgements
for outstanding packets before they can transmit more data. The longer devices wait
for acknowledgements, the longer it takes to do things like transfer a file.
Past a certain point, buying more bandwidth won’t help you. You won’t be able to fill
the pipe because of latency in the network.
One of the culprits here is the cosmic speed limit. That’s the speed of light: 186,000
miles per second. The universe keeps us from transmitting data over a distance faster
than light can traverse the same distance. This means the further apart two endpoints
are, the longer the inherent latency is. Additionally, hop-by-hop propagation delays
introduced by processing overhead in pieces of equipment in the transmission path
add to network latency. Finally, Loss and Congestion can give the appearance of
latency since they slow things down because of lost packets and acknowledgements
and the resulting required retransmissions.
Silver Peak’s TCP Acceleration can’t change the speed of light, or eliminate
processing delays, but it can help to reduce the effects of latency in your network.
We’ll see how in a moment.

TCP Acceleration
–Delays are caused by acknowledgement

procedures and window sizing in latent
environments
–TCP Acceleration overcomes delays with
four key components
1. Window scaling
2. Selective Acknowledgement
3. Round Trip Time Measurement
4. High Speed TCP
52
As we mentioned earlier, latency in the network causes delays in the transmission of

data, reducing transmission speeds and responsiveness of applications.
1. TCP Acceleration helps overcome this problem. Acting at the TCP layer, this
acceleration modifies network behavior in four key areas:
2. Window Scaling – which allows Silver Peak appliances to expand the size
of the TCP transmit window by a factor of over 250, compared to a standard
device’s TCP stack.
3. Selective Acknowledgement – which reduces the number of

retransmissions in a lossy network environment.
4. Accurate Round Trip Time Measurement allows the appliances to more

precisely adjust the acknowledgement timer. End devices typically have a
fixed length timer. If a packet is lost, they will wait the full length of the timer
before retransmitting a packet, even if the receiver is only a few feet away.
Knowing the actual latency allows the Silver Peak appliances to wait only as
long as the actual latency before counting a packet lost and therefore
retransmitting.
5. High Speed TCP reduces wasted transmission bandwidth by allowing the

appliances to continuously transmit at the available capacity of the network by
accurately judging where loss due to congestion occurs, unlike devices with a
standard TCP stack, which would back off transmission speed in increments
of 50% when loss occurs. This is discussed in more detail in the ASD class.

Proxy and TCP Acceleration
WAN
Transmitting device
Latency
experiences only 2 mSec 150 mSec 2 mSec
LAN latency LAN WAN LAN
Three Way Handshake
TCP Acceleration requires that each

appliance see the full TCP handshake.
53
Here we can see an example of TCP Proxy. TCP Proxy is basically the Silver Peak appliance locally
acknowledging receipt of a packet on behalf of a remote device. This allows the transmitter to continue
sending data even though it hasn’t actually arrived at the far end yet. The device transmitting the data
doesn’t know the acknowledgement, or ack, came from the Silver Peak, and it doesn’t care.
In the drawing above, the red and green arrows represent the conversation between the local device and
the Silver Peak Appliance, with the Silver Peak responding on behalf of the conversation endpoints to
the local device. The blue blocks represent the conversation between the Silver Peak appliances. They
manage the transmission of data across the WAN, any acknowledgements and retransmissions that
need to occur thus ensuring delivery and acknowledgement to the end devices.
In this example, the LAN latency on each end is 2 mSec. The WAN latency is 150 mSec. Normally a
device would have to wait over 300 mSec for an acknowledgement when it transmits a packet. With the
Silver Peaks acknowledging locally, the end devices only wait a couple of mSec, so they can transmit
quickly and not feel the effects of the WAN. Proxying effectively shields the transmitting device from the
effects of network latency on the WAN.
This greatly speeds up the transmission of blocks of data from transmitting devices, and mitigates the
effects of WAN latency on transmission time.
One thing you need to understand is that in order to perform TCP proxy, the Silver Peaks need to see
that data stream in both directions. This is because each segment of data carries a sequence number,
and this number is what allows a device to keep track of which packets have been acknowledged.
1. When a TCP connection starts between two devices, they perform a 3 way handshake. During the
handshake they synchronize their sequence numbers, telling each other how they are going to
number packets, and acknowledging the other devices numbering. As each segment of data is
transmitted, the number is incremented. A device starts a conversation with a SYN containing the
number it is starting with, in this example 1000. The remote device responds with a SYN/ACK,
saying it will start with number 2000, and acknowledging the packet numbered 1000, by responding
with 1001, telling the initiating device that it expects to see 1001 from it next. Finally, the device on
the left responds with an ACK, numbered 1001, and acknowledging the previous packet by telling
the device on the right it expects to see segment with 2001 next.
The takeaway here is that in order to proxy, the Silver Peaks must be able to see the flow in both
directions to keep track of the sequence numbers.

TCP Acceleration requires Symmetric flows
•
SYN
SYN
If we can’t see a flow in each
direction…
o We can’t see the sequence WAN
numbers,
o Can’t proxy
o Therefore, can’t accelerate a flow. Asymmetry
SYN/ACK
SYN/ACK
Asymmetric flows can’t be Network Accelerated, but we can still apply Network Memory
and Forward Error Correction (FEC) and Packet Order Correction (POC)
54
Remember, if the transmission path between the conversation endpoints goes

through the Silver Peaks in one direction, but in the reverse direction switching
or router configurations send the return packets though a path that doesn’t go
through the same pair of Silver Peak appliances, then acceleration cannot
occur.
In the diagram above, we see an example of asymmetric switching and routing

paths. In one direction, packets traverse the gold path through the Silver
Peaks. In the other direction they travel over the red path, which bypasses one
of the Silver Peaks.
We call this an Asymmetric Flow. When a Silver Peak sees only one side of
the conversation, it can apply some optimizations like Network Memory and
Path Conditioning, and shape the traffic using QoS in one direction only, but it
can’t apply TCP acceleration.
You can filter on asymmetric flows in the flow table to find them. Later on in the
course, we will look at the flow details which will will tell use whether a flow is
being TCP accelerated.

Problem: Congestion
• Symptoms
• Link to the WAN is frequently fully utilized
• Users complain of slowness
• Long delays in connection establishment
• Replication falls behind target because it
cannot push data fast enough
• Commonly seen in any environment where
bandwidth resources are out of date or have
recently taken on new requirements
Solution: Network Memory

55
Running out of bandwidth on your network links, as you know, can cause all
kinds of problems like dropped packets along with the resulting response time
and connectivity problems that go with them. Users might complain of
application slowness. Your storage replication targets might not be met
because you can’t push data to your backup sites fast enough. Sites and
applications that used to work fine, may begin to falter as growth in your
network begins to saturate existing links.
Silver Peak can help free up bandwidth with its Network Memory technology.

Network Memory
Deduplicates and compresses transmitted data to reduce bandwidth requirements & congestion
–Deduplication –Compression
o Byte-level disk-based data o Leverages a form of the common
reduction, in which data is reduced LZ (Lempel-Ziv) compression
prior to transmission by removing algorithm to further reduce the
literal data and replacing it with a amount of data transmitted.
fingerprint pointer into the remote
disk cache.
56
The Network Memory features of Boost involve the deduplication and

compression of transmitted data to reduce bandwidth requirements &
congestion.
Silver Peak uses disk caching technology to perform deduplication.
1. Deduplication essentially reduces the amount of bandwidth needed by

eliminating repeated strings of data, and locally caching frequently
accessed data. Deduplication and compression include Silver Peak’s byte-
level data reduction techniques for reducing data sent onto the WAN.
2. In conjunction with utilizing Lempel-Ziv compression techniques, Network

Memory dramatically reduces congestion in your network.
3. In this example, we can see a 94% reduction in the amount of data being
transmitted out the WAN for CIFs traffic.

Deduplication and Compression Reduce Congestion
Layer 3 Byte level deduplication
Deduplication can’t work if the
traffic is encrypted!
1. Byte Fingerprint & Store 3. Byte Fingerprint & Store

Not Cached 2. Compress + Transmit 4. Uncompress & Deliver
1. Data match in disk cache 3. Get Local Data from Cache

Cached
2. Send Fingerprint 4. Deliver
57
This happens in two passes.
1. On the first pass, incoming packets are parsed in real time for common
sequences of data. For each sequence, we store the data in the local disk
cache, along with a small fingerprint to identify the data in the disk cache.
2. Then we transmit the data to the remote appliance
3. which does the same thing before
4. delivering the packet to it’s destination.
5. The next time we see the sequence, the data is matched in in the disk
cache, and instead of sending a large block of data,
6. we send a fingerprint to the destination appliance which uses much less
bandwidth on the WAN.
7. The receiving device uses the fingerprint to look up the original data in its
cache,
8. then reconstructs the original packet and delivers it to it’s destination.
It’s important to note that Deduplication can’t be performed if the data is

encrypted before it is received by the Silver Peaks, because we can’t look into
an encrypted data stream to perform disk caching or fingerprint creation or
matching.

Review #6: Boost
?
28) What are the two primary components of Boost?
29) What three factors are primary contributors to latency?
30) How do we accelerate TCP flows?
31) Why does Asymmetry break TCP Acceleration?
32) What benefit does the Network Memory component of Boost provide?
33) What does Network Memory send instead of duplicate data?
?
58
Take a moment to answer these questions in your Student Guide.

A Hewlett Packard
Enterprise Company
Licensing Process
In this section, we’ll take a closer look at the different pieces of Silver Peak's
solution and how they work together to license the features of the appliances.

Silver Peak Network Elements
–Three essential pieces... All licenses (Devices, Base, Plus,
Boost,) are managed by the Portal.
No customer action required.
Cloud Portal
Orchestrator EdgeConnect
Appliances.
Management Software for Silver Peak Devices.
Must register with Cloud Portal to operate.
Must register with Cloud Portal.
Create network connections and move data as
Required for EdgeConnect appliance
directed by Orchestrator.
registration approval.
Devices must reregister w/ portal periodically
60
Recall there are three essential pieces of the Silver Peak SDWAN solution: the
Orchestrator, EdgeConnect appliances, and the Silver Peak cloud portal.
1. The Cloud Portal is maintained by Silver Peak. It contains a database of all

the machines and licenses associated with each customer. All machines,
including the Orchestrator management software must register with the
Cloud Portal in order to have their licenses approved, much like many
popular software programs that you install and have to register with the
manufacturer.
2. The Orchestrator management software is installed as a virtual machine in
the customer’s network under any of the popular hypervisors, and must
register with the Cloud Portal before it can be used to manage appliances
in the network. A functioning, registered Orchestrator is required for any of
the EdgeConnect appliances in the network to operated.
3. EdgeConnect appliances, which connect the different sites of a customer’s
network together and optimize the traffic flowing between them, must
register with the Cloud Portal, and the registration must be approved by the
customer via the Orchestrator. Additionally, the Orchestrator initiates the
building of overlay and underlay connections between the appliances after
they register with the cloud portal and have their registrations approved.
We’ll look more deeply at the licensing and approval process in the next few
slides.

Step 1: Install Orchestrator
Orchestrator will be used to approve and manage all the Silver Peak devices
Account Name/Key are same
for Orch and Appliances
Orchestrator Cloud Portal
This Orch can now

cloudportal.silver-peak.com
portal.silverpeak.cloud manage devices
associated with this
account.
Orch will constantly talk

to the Cloud Portal to
learn of any new
devices that have
License, Account Name and Account After contacting portal attempted to register
Key are sent to Cloud Portal. Registration = Yes with this account
61
The first step in establishing a connection is to have the Orchestrator installed,

configured, and registered with the Silver Peak Cloud Portal. Once
communication has been established between the Cloud Portal and the
Orchestrator, new EdgeConnect appliances can be installed, registered, and
managed by the Orchestrator.
1. One thing to note is that the Account Name and Account Key obtained from
Silver Peak, and used to register the Orchestrator, is also used and must
be the same on every appliance in the SDWAN.

EdgeConnect Registration Through Orchestrator
• EC is manually configured with Orchestrator’s IP address
• EC connects to Cloud Portal (https) using the Orchestrator as a proxy
• EC Registers with Cloud Portal
Customer Network
10.10.10.1
portal.silverpeak.cloud
Cloud Portal Orchestrator
Private IP
10.10.10.1
Public IP – Untrust Zone

Internet Firewall/Gateway
(S-NAT Outbound
Connection to Cloud Portal)
Private IP - DMZ
Requires that
appliance be able to
reach Orchestrator
EdgeConnect MPLS VPN via mgmt0, or WAN
wanX – Private IP interface(s)
62
t’s not uncommon for customers using an MPLS private network to limit the connectivity of
branch sites directly to the internet, such as in this example here. In many of these cases,
internet connectivity requires connections through a web proxy server, and the appliance
doesn’t support this.
However, you already know that the appliance is required to register through the Cloud Portal,
and that this needs to happen before the appliance can be approved in the Orchestrator, so the
answer is for the appliance to use the Orchestrator as a special proxy sever. This is possible
because the Orchestrator can use a proxy server, and can also act as a proxy for the
appliance registration process.
An appliance can use the Orchestrator as a proxy as follows:
Each appliance is preconfigured to resolve the name of Cloud Portal, portal.silverpeak.cloud,

by default, so it can register. If it can’t reach the Cloud Portal, or can’t resolve the name, it will
attempt to reach the Orchestrator.
1. It is possible to configure the ip address of the Orchestrator, as shown here, so the

appliance knows where to find it.
2. Then the appliance will be able use the Orchestrator as a proxy. The Orchestrator will see
the incoming connection, and forward it to the Cloud Portal, facilitating the conversation
between the appliance and Cloud Portal. This of course means that the Orchestator has to
be reachable from the appliance, via it’s management0 interface, or one of its WAN facing
interfaces.
3. Then the appliance is able to register with the Cloud Portal, but at this point, the
Orchestrator, despite having facilitated the connection, is still not aware of the appliance.
4. The Orchestrator, on its next polling cycle to the Cloud Portal, discovers the new
EdgeConnect appliance, and after the Appliance is approved in the Orchestrator, the
Cloud Portal grants a license to the appliance, and the Orchestrator can begin managing it.

Orchestrator License Management
– Configuration→Licensing: Licenses
Bandwidth tiers will only
– Licenses used/total display if your account has
– Expiration dates purchased those
63
As shown here, the License tab in the Orchestrator displays all managed EC
devices and licensed capabilities.
1. Additionally, the number of used licenses from the available total is shown
for each bandwidth tier, Boost capabilities, as well as the expiration dates
for the licenses.

Licensing Notes:
– Appliance licensed by portal for 30 days at a time
▪ Appliance contacts Cloud Portal and tries to update itself every day
▪ The license period is a moving 30 day window
– Until appliance is approved in Orchestrator, and a license granted, a device will be
in policy drop mode (physical or virtual)
– Device will try to use 8.8.8.8 (Google public DNS
service) if it can’t get local DNS
▪ Might not work in China – use available DNS there
Cloud Portal
– Orchestrator polls portal once each minute
EdgeConnect Orchestrator
64
Here are a few things to remember with regard to the licensing process:
Each appliance license is granted for a rolling 30 day window. Each appliance
will attempt to connect to the Cloud Portal once a day to renew its license. If it
is able to connect, the license is extended by one day. The point is that after
30 days of not being able to connect to the Cloud portal, the appliance license
will expire.
1. You should be aware that appliances will drop all traffic unless they are
licensed and approved in Orchestrator, so you should make sure any
reachability issues are considered and solved prior to going into production.
2. During the installation, if there is no local DNS available, the Orchestrator

and appliances will attempt to use Google’s free public DNS server, located
at 8.8.8.8 to resolve the Cloud Portal address.
3. The Orchestrator, once it has registered, will poll the Cloud Portal once a
minute, so depending on when in the cycle an appliance registers, it could
take a couple of minutes for it to show up in the registration process on the
Orchestrator.

Review #7: Licensing Process
?
34) What is the first step in setting up your Silver Peak network?
35) True/False: There are unique license keys that are different for each
EdgeConnect appliance and the Orchestrator.
36) What is required for an appliance without direct Internet connectivity to

register?
37) How long is a device’s license period?
38) True/False: When the license period expires, the appliance will only forward
traffic through established tunnels using stale flows.
?
65

A Hewlett Packard
Enterprise Company
Orchestrator Overview
Now we’ll have a short overview some key the features of the Orchestrator
and mention some things you need to know about installation and upgrades in
newer versions of code.

Alarms
Orchestrator UI Overview: Tabbed
Where?
Interface
How Many?
Lower Grouping
Radius to separate
sites close together
on map Legend
Help &
Tree View Settings
&
Grouping
Context
Topology sensitive
View menus
67
The Orchestrator client interface is a GUI that is completely HTML 5.0 based.
1. It contains a Tree View with a way to logically group appliances and give
each group a name.
2. There is a Topology View that gives you a graphical view of the network
that can be based on geography.
3. Appliances show up as dots on the map and may display information like
the number of alarms a device is currently experiencing.
4. Mousing over a device will give you context sensitive information about that
device.
5. Clicking on the gear Icon will display a legend to help you decipher the
color coding and different icons that appear in the UI.
6. Above the topology diagram, you’ll notice a number of tabs which can be
opened or closed separately to reduce clutter.
7. One thing you should know about is the grouping radius slider on the
legend. When set to larger values, appliances near to each other on the
map will be collapsed into a single dot on the map. Sliding it all the way to
the left causes all appliances at different sites to be revealed separately as
you zoom in.

Tabbed Interface for configuration and monitoring
Filter Tree View, and set
display options
Select the
appliances to be
affected by function
on the right
68
Clicking on a tab will cause the interface to display information associated with
that function in the main display area. There are many different tabs that can
be displayed or hidden from the various menus on the top navigation bar of the
Orchestrator.
The Tree View on the left also has an effect on what is shown in the main
display area. You can think of it as a filter. If you are viewing tunnels, for
example, only tunnels for those devices selected in tree view will appear in the
list. If you are applying templates, only the selected appliances will have the
templates applied to them.
1. Note that clicking on the gear icon above tree view will let you configure
some options, including whether the management ip address of each
appliance is displayed in tree view.

Orchestrator Search help
Easily find the config or monitoring items you need
Convenient Search Menu
69
The orchestrator has a lot of menus and submenus, so remembering where to

find different functions can be difficult. If you want to quickly find something,
start typing the name of the function into the search menu outlined here in red.
1. Immediately a list of matching menu items will appear. Continuing to type
will refine the list of matches. Click on the one you want, and you will be taken
to the tab that contains that function.

Orchestrator Dashboard
Monitoring→Dashboard
–Appliance & Licensing

summary
–New Map Server
Topology view
–Network Performance
summary
• Numerous charts
and graphs
–Double Chevron icon
takes you to details tab
for each item
70
The Orchestrator dashboard shows you a summary of the status of all the
managed appliances, along with licensing information and more.
There is a new mini topology map, which can be zoomed in our out.
It includes a number of charts and graphs that are constantly updated, and
each one has a clickable double chevron icon that will take you to a separate
tab with information related only to that feature, or in the case of the topology
map, it will take you to the full sized topology display.

View status per Overlay or underlays
Select the Overlay or Underlays
71
As you can see in this full size topology diagram, it’s possible to view the
status of the tunnels in each overlay separately, along with the status of the
underlay by using the drop down list on the topology diagram. This same
functionality is available in the mini topology diagram on the dashboard.

Convenient Functions
72
From tree view, for your convenience, some functions are available in the
menu displayed when you right click on an appliance.
You can now restart the Configuration Wizard that runs as part of the
appliance approval process. This allows you to correct mistakes, or make
updates as needed. Shown here is the screen that allows you to input the
address at which an appliance is located, and get a preview of where it will
appear in the topology map.
Also worth mentioning, is the ability to make changes directly to an appliances

deployment profile by selecting Deployment from the right click menu.

Tunnels Automatically Created
(Overlay/Underlay/Passthrough)
– Tunnels tab shows status of all tunnels
– One or more tunnels will be created to carry traffic that matches a BIO
Overlay tunnel names contain the overlay name
Underlay tunnel names contain the WAN interface labels
Passthrough tunnel names contain the WAN interface labels
73
Here’s a screen shot of the information on the tunnels tab in the Orchestrator.
For the appliances selected in tree view, information on all the overlay and
underlay tunnels is available. When you are viewing tunnels, the status of
each tunnel is available.
1. Note that Overlay tunnel names contain the name of the overlay for which
Orchstrator built them.
2. Similarly, underlay tunnels contain the names of the interface labels. The
column to the right of that shows which overlays are using a given underlay
tunnel.
3. Finally there are passthrough tunnels. These are not really tunnels. They
are just a mechanism for routing traffic out of a particular interface in
passthrough mode, meaning the packets are not encapsulated. These are
used to send local internet breakout traffic out of an interface to a
destination like office 365, or salesforce. Passthrough tunnel names also
include the label of the interface through which they pass packets.

Orchestrator Root and Admin Passwords
– Upon first login, user will be prompted
to change Linux and Orchestrator
passwords
▪ Make sure to document each credential
– Three Accounts need to be set at install
1. Linux admin account
2. Linux root account
3. Orchestrator admin
(GUI)
74
You should know that in the most recent versions of software, the orchestrator
application is becoming more separate from the Linux operating system it runs
on, allowing sys admins greater flexibility in applying the latest security
patches to the OS.
One of the implications of this, is that starting in Orchestrator 8.6, the

operating system and orchestrator application passwords are separately set by
the operator at installation, as you can see in this example screen shot.

Orchestrator 8.6.1+ setup static IP from CLI
1. Login to Orchestrator console
2. Change to subdirectory
cd gms
3. Run setup script
orch-setup –c
4. You will be prompted for
root password
5. Follow the dialog
6. Reboot required
su –c “shutdown –r now” *
* Alternate Option
– use two separate lines to avoid quotes
– useful for those using foreign keyboards
75
When you first install an orchestrator using 8.6.1 or above, it will get an
address, DNS, NTP and other information via DHCP just like it does today, but
if you want to assign a permanent IP address (which is a recommended best
practice) or any other basic networking settings, you need to do it from the
command line of the console as shown here.
1. A setup script will walk you through the changes, as you can see in this
screenshot.

Orchestrator upgrade Via CLI
1. SCP the
upgrade *.gip
file to /home/gms
on the Orchestrator
Always refer to
2. Login to Release Notes for
Orchestrator Release specific
as root upgrade requirements
3. /home/gms/gms/setup/install_orchestrator.sh <filename>
76
Starting in 8.6, you will need to do an orchestrator upgrade from the command
line.
First, SCP the file to the orchestrator. Then login as root and run an upgrade
script as show here. Documentation is available on our website for this as well.
1. It should be noted that depending on which version you are upgrading from
there may be more specific instructions. You should ALWAYS refer to the
Release Notes for that version to ensure all requirements have been met.

20
LAB 2 Orchestrator Configuration and

Licensing

Review #8: Orchestrator Configuration and Licensing Lab
?
39) What is the default user name and password for the Orchestrator GUI?
40) What is the filename extension of the VMware Orchestrator installation file?
41) Select all the correct statements: On the Cloud Portal screen in Orchestrator,
Registered = Yes indicates:
A. The Orchestrator was able to reach the Cloud Portal on the internet.
B. The Orchestrator was recognized by the Cloud Portal to belong to your company
based on its serial number.
C. The Account Name and Account Key were correctly entered.
D. The Orchestrator will now be able to manage any EdgeConnect clients
associated with that account
42) True/False: The Account Name is always the same on the Orchestrator and the
EdgeConnects. The Account Key needs to be individually generated via a script.
?
78

Path Selection
• Subnet Sharing and Routing
In this section we’ll talk about subnet sharing, routing protocols and
management routes.

Data Path Routes and Subnet Sharing
How does an appliance advertise and learn prefixes/subnets?
– Subnet Sharing
• Used between appliances to advertise to each other through tunnels
Auto(System)
– Routing Protocols means subnet is
• Silver Peak advertises the best metric to become the preferred path Directly Attached
• BGP - LAN or WAN
• OSPF – Usually only LAN side
o WAN side is also supported, but PE peering is a very bad idea, local only routers OK
– Can redistribute between Subnet Sharing and Routing Protocols
80
How do Silver Peak appliances learn about the different prefixes and subnets
in your network?
Subnet sharing is used between appliances to exchange information about

locally attached subnets.
Appliances also support the BGP and OSPF routing protocols, and can peer
with 3rd party routers and layer 3 switches, enabling them to learn additional
routes, and advertise routes known to the silver peak appliances, usually with
a preferred metric, so the appliance becomes the best next hop to reach the
destination through the SDWAN fabric.
AUTO IN TYPE FIELD MEANS IT IS A LOCALLY ATTACHED SUBNET THAT

HAS BEEN ADDED AUTOMATICALLY
It’s possible for the appliances to redistribute between routes learned via
subnet sharing and those learned via OSPF and BGP. We’ll discuss this more
later.

Overview: Subnet Sharing
– Allows devices to advertise

LAN WAN
known subnets to each other 10.10.10.0 10.10.20.0
10.10.10.0 at SP2
10.10.20.0
• Directly attached at SP1
• Manually added static SP1 SP2

• Subnets learned via a routing
protocol
– Metric is configurable, lower value
preferred
– Required for overlays to properly Routes learned via Subnet Sharing are
route traffic automatically associated with a destination appliance.
Tunnel must be up. Tunnels to that appliance are used to

No tunnel – No subnet sharing! reach the destination subnet.
81
We’ll start with a quick overview of subnet sharing.

Subnet sharing is a method by which Silver Peak appliances can share
information with each other about local subnets, much like a routing protocol.
When a tunnel is up between them…
1. Each appliance can advertise its local subnets to its peers. When a packet
enters an appliance on the LAN-side, it can then perform a lookup in its
subnet table and put the packet in a tunnel going to the correct destination
based on the advertisements it has received.
It’s important to remember that if there is no tunnel established between two

appliances, no subnet sharing can take place because the advertisements flow
through the tunnels.

Subnet Sharing – Key settings
• Use shared subnet information (use received
advertisements) – NEVER turn this off.
• Automatically include local LAN subnets
– almost always turn on, advertises locally attached LAN
side subnets
• Automatically include local WAN subnets
– usually turn off , advertises locally attached WAN side
subnets. Carries a risk of routing loops and tunnel
instability.
• Metric for local subnets to allow you to prefer one
destination appliance over another
• Allow WAN to WAN routing (hairpinning) allows
intermediate appliance to relay traffic between two others
Tunnel must be up for subnet lacking a direct tunnel between them. Usually on.
information to be advertised to peers!!!
82
Here you can see an example of the subnet sharing configuration in the system
settings on the appliance, and also configurable via templates from the orchestrator.
Key settings include

Use shared subnet information, which means this appliance will use
received advertisements. – You should NEVER turn this off.
Automatically include local LAN subnets.
– You will almost always turn this on. It advertises locally attached LAN side
subnets to Silver Peak peers.
Automatically include local WAN subnets

– You will usually turn this off. It causes the appliance to advertise locally
attached WAN side subnets to other devices. This is usually not necessary
since tunnels would not have come up without the remote appliances knowing
how to reach WAN side subnets already. It also carries a risk of routing loops
and tunnel instability if remote appliances are also learning WAN side routes
via BGP. This is discussed in greater detail in the ASD class.
The Metric for local subnets to allow you to adjust how one destination
appliance is preferred over another.
Allow WAN to WAN routing (also known as hairpinning) allows an

intermediate appliance to relay traffic between two others lacking a direct
tunnel between them. Usually you will turn this on, especially on Hubs in a hub
and spoke topology.

Routes table - Appliance
Redistribution Additional Info Tag
• Configurable globally per protocol • FROM_WAN means the route will only be applied to
incoming traffic from the WAN.
• Configurable per route for static routes
• FROM_LAN means the route will only be applied to traffic
coming from the LAN and being sent to the WAN.
• Blank = both directions
Metric (AD) Applies only to

Lowest Metric w Which protocols to use this traffic.
lowest AD Wins to advertise this subnet
Locally
attached
subnet
Destination Where the route
Subnet/Mask originated
83
Here is a view of the routes table on an appliance. All the routes the appliance knows
will appear there, including those learned via BGP, OSPF or subnet sharing.
It is also possible to configure static routes manually to be advertised by this
appliance. This is useful if there are subnets that the local appliance does not have an
interface address in already and cannot learn via a routing protocol. Make sure that if
you manually advertise a LAN side subnet, that you have also configured a LAN-side
route to the next hop layer 3 device so the appliance can forward incoming packets to
the destination correctly.
Notice the Metric column also includes the administrative distance of the protocol via
which the route was learned or configured. All things being equal, the route with the
lower admin distance will be preferred.
The Advertise to Peers column tells you about how a given route will be advertised or
redistributed.
The Type column will tell you the source of the route. Auto denotes locally attached
subnets. You might also see the name of the peer a route was learned from, as well
as the source routing protocol if the route was learned via BGP or OSPF.
The Additional Info column contains TAGs associated with a route. A tag of
FROM_WAN means the route will only be applied to incoming traffic from the WAN. A
tag of FROM_LAN means the route will only be applied to traffic coming from the LAN
and being sent to the WAN. If there is no tag, the route applies in either direction.
Separate Course Available: 303 - Routing Redistribution and Administrative Distance
(Jan 2020)

Management Routes
–Separate table from data path routes
–Used for self-originated traffic
• E.g. Cloud Portal, Orchestrator, System
Mgmt. Services (NTP, SNMP, Syslog,
Netflow , DHCP Relay)
• If mgmt0 is used and up, that default
route is preferred
–User configured non-default (0.0.0.0)

mgmt routes are also copied to data
path table
• Non-default routes are not copied to data
path Default next hop
configured in initial
config wizard
84
Its important to understand the data path routes table on the previous slide is
only used for payload traffic transiting the appliance. Each appliance also
maintains a management route table for self originated traffic like connections
to the cloud portal, NTP server and so on.
Any static routes you add here, except default routes consisting of all zeros will
also be copied to the data path table.
If you ping from an appliance and don’t specify a source address, the ping will
come from the mgmt0 interface and use this routing table.

Review #9: Path Selection & Subnet Sharing
?
43) What does ‘Auto (system)’ in the route ‘Type’ field mean?
44) What does Subnet Sharing do?
45) What must happen before subnets will be shared between appliances?
46) What happens to shared subnets if all tunnels to a site go down?
47) Besides Subnet Sharing, how else can an appliance dynamically learn routes?
48) What does FROM_WAN mean in the additional info column of the data path
routing table?
49) What is the management routing table used for?
50) True/False: Syslog entries from an appliance will be reported to the Syslog server
using the main data path Routes table.
?
85
85

Group Exercise:
Matching WAN Symptoms to Solutions

Symptom #1: Denver to Colorado Springs
– Environment: ~70 mi/110 km

IP VPN
Internet
Denver Colorado Springs

– Symptom Description:
▪ The remote office is complaining of slow file transfers from the data center. A look at the
data stream indicates that there a lot of retransmissions. Link utilization on the WAN link
is only 50%.
– What are the possible causes?
– What Silver Peak technology will best address the symptoms?
87
Possible causes:
1. What is it not? Short distance, probably not latency. Utilization is low,
probably not congestion.
2. Probably a bad link somewhere.
Fix:
Silver Peak FEC

Symptom #2: San Francisco to Reno
– Environment: ~220mi/350km
Private
Line
San Francisco Reno

▪ The replication of tier 1 data is occasionally falling short of the expected Recovery Point
Objective (RPO) and your manager is pressuring you to increase the frequency of
backups.
▪ Link utilization often hovers near 100%.
– What are the possible causes? RPO = target time

between backups
88
Note: Recovery Point Objective (RPO) is the time between backups,

essentially, how much data you can afford to lose (since the data not
duplicated up since the last backup will be lost in case of failure).
Causes:
1. What is it not? Still short distance, not likely to be latency. It’s a private line,
so loss is not likely to be a problem.
2. Link utilization makes congestion sound likely.
Fix
Dedup and compression – Network Memory (part of BOOST) – will likely solve
this problem by reducing BW requirements and redundant transmission of
data.

Symptom #3: Seattle, Wa to Baltimore, Md
– Environment:
Internet
Seattle, WA 180 mSec→ Baltimore, MD

▪ All traffic is backhauled to company HQ in Baltimore. A Sales Team Member in the office
in Seattle is reporting poor performance opening their documents and emails through
Office 365. No such problem for users in Baltimore. IPERF testing shows the link from
Seattle to have low loss and available bandwidth.
89
Symptom:
1. What is it not? Stated clearly that testing shows loss is low and BW is
available.
2. Latency is the issue. We’re backhauling traffic from Seattle to Baltimore
(about 2700 mi / 4500km) but why? Office 365 is a trusted web app isn’t it?
Fix
1. If the customer is reallllly security conscious and wants to continue to
backhaul everything, TCP acceleration (BOOST) might help depending on
what you are doing.
2. A better solution would probably local internet breakout / direct-to-net,
since there is bound to be an O356 pop near Seattle. Local breakout will be
covered in depth in a later lesson.

Symptom #4: New York to Los Angeles Streaming Video
– Environment:
MPLS
Los Angeles180 mSec→ New York

▪ Streaming Video sourced from New York, plays fine in Los Angeles, but FTP and CIFS
file transfers are slow.
▪ The service provider verified that loss on the line is below .1%. Link Utilization is only
20%.
90
Problem:
1. What is it not? Since video works, it’s probably not loss, and we state it’s
low anyway. Link utilization is low , so it’s not congestion.
2. Latency must be the culprit
3. Why does streaming video work but CIFS and FTP have a problem?
Because video is UDP (no ACKs required) and the others use TCP.
Fix
Network Acceleration (BOOST!) compensates for the effects of latency.

Symptom #5: New York to Miami File Transfers
MPLS
– Environment: Primary
1Gbps
Internet
Backup
1Gbps Used only when MPLS goes down
Miami 60 mSec→ New York
▪ Voice traffic and video conferencing are unreliable in the morning when the office
opens, although they work fine at lunch time.
▪ Link Utilization on the MPLS link is at or near 100% most of the time and you don’t have
budget to buy more bandwidth.
91
Problem
1. What is it not? Latency? Maybe a little, but not all of the problem.
2. Problem happens at peak hours, probably congestion related, especially
since the link is close to saturated most of the time anyway.
Fix
1. It would be nice to use that unused Internet link and double our bandwidth.
Silver Peak can load balance & waterfall, or we could send important stuff
over the MPLS link, and the less critical traffic over the internet using
different overlays.
2. Network Memory (part of boost) will compress and dedup and save us
some BW.
3. Network acceleration will help a bit with the latency, but don’t expect too
much at 60mSec.

A Hewlett Packard
Enterprise Company
Deployment Modes
In this section, we’ll discuss the different ways in which a Silver Peak
Appliance can be installed and used to optimize traffic in a network.

Deployment Types
Goal: Outbound Packets Go Through an Appliance
ILRM (Inline router Mode) is
recommended best practice
In-Path (Inline) Out-of-Path

LAN LAN
WAN
All traffic must physically L3 router or switch must

flow through appliance redirect packets to appliance
93
As we begin to explore the different ways to deploy Silver Peak appliances, it’s
important to understand that there are two main ways that data passes
through the appliances for processing.
1. On the left, we see an example of an In-Path deployment. In this model all
the data physically has to flow through the appliance to get to its
destination.
2. On the right, We see an Out-of-Path deployment. When the Silver Peak is
deployed Out-of-Path, a layer 3 switch or router must redirect incoming
packets to the Silver Peak for processing, which then returns the packets to
that same switch or router for forwarding to their final destinations.
3. Inline Router Mode, which is an inline deployment, is recommended as a
best practice for Silver Peak appliances. We’ll talk about this more in a few
minutes.

Deployment Modes
–Three Possible Modes
ILRM is recommended best practice
–Router Mode
–Bridge Mode
–Server Mode
94
Now we’ll explore the three different deployment mode options available for
Silver Peak appliances: Router Mode, Bridge Mode and Server Mode. These
are the available selections in the web UI when configuring a deployment
profile.

Router Mode
• Inline Router Mode (ILRM):

Recommended Best Practice!
Let’s begin our discussion of deployment modes by looking at router mode,

Although other modes are available and supported, router mode is the easiest
mode to deploy and manage that gives you full access to all the features of the
Silver Peak product line. Inline Router Mode, abbreviated ILRM, is the
deployment recommended as a Silver Peak best practice.

Inline Router Mode Add interface to WAN or LAN, wherever you need them
• Router Mode: At least

two interfaces
1. Each interface has at least
one IP address & next hop.
⁃ subinterfaces possible for more IPs/VLANs
• Provides a data path between two or more different subnets

1. Passthrough traffic can be forwarded between any locally attached interfaces
• Flexible interface deployment options
1. Stateful Firewall support on WAN ILRM is Recommended Best Practice!
2. ZBF on all interfaces LAN
• Appliances can also be managed via data path LAN

interfaces
• Incoming LAN traffic can be placed in any Inline
tunnel or sent direct-to-net. WAN
LAN
96
Router mode is the most flexible deployment model available. The name router mode
simply implies that the appliance’s interfaces have addresses in different subnets,
and can locally forward packets between them based on a routing table lookup.
Router mode devices can also run a routing protocol like OSPF or BGP and
exchange information with layer 3 routers or switches, but this is optional.
When you deploy a physical appliance, it will have certain wan, lan and management
interfaces built in. Virtual appliances come with only a management0 interface, and
allow you to add different lan and wan interfaces as required.
An appliance in Router mode has at least one other data path interface in addition to
mgmt0. Each interface requires an IP address, and all WAN side interfaces require a
next hop router address. You can currently have up to 6 data path interfaces and two
management interfaces. Each interface can have additional subinterfaces if required,
each with their own IP address and these can each be in different VLANS.
1. As shown here, router mode appliances can be flexibly deployed according to

your needs, with varying numbers of interfaces on the lan and wan sides. You can
also enable Silver Peak’s stateful firewall on WAN interfaces and have full support
of Silver Peak’s ZBF on all interfaces.
2. You don’t have to use management interfaces to control router mode appliances.
They can also be managed from data path interfaces.
3. Any traffic entering from any LAN side interface can be put in any tunnel to any
remote site, or broken out locally to the internet.

Forwarding Passthrough (Local Traffic)
• Appliance acts as a router for locally known/attached subnets in ILRM
• Can learn/advertise routes via updates with non SP devices via BGP or OSPF
(8.1+)
• May include direct-to-net traffic Can forward Passthrough
LAN traffic between any local
interfaces L2L, L2W or W2W
LAN
WAN LAN
97
Just to illustrate the point we made earlier, like the name Router Mode implies,
the appliance is capable of forwarding a packet between local interfaces, as
long as it knows which interface to use to reach the destination subnet. It could
have this information as a result of being locally connected to the subnet,
learning the route via OSPF or BGP, or perhaps a static route to the subnet
has been configured, and the Silver Peak will forward a packet to the next hop
router.

ILRM Reference Architecture
• Branch Office
• In-line Router Mode, In-path
• LAN-side
• Could router (BGP or OSPF)
• Could have additional interfaces
LAN • DHCP Server
WAN 0
LAN 0 • WAN-side
WAN 1
• Firewall
L2 Switch • NAT
• Can replace local site router(s)
• Different interfaces (4G LTE, 2 Broadband, etc.)
98
This slide shows Silver Peak’s Branch Office reference architecture. The appliance is
deployed in In-line Router Mode.
The appliance is deployed in-path, therefore all packets arriving or exiting go through the
appliance. This example only shows Internet and MPLS, but you could use LTE, dual-
Internet, or any combination of transports.
This architecture eliminates most of the causes of asymmetric flows. Remember an

asymmetric flow is where traffic goes through a tunnel in one direction but does not return in
the same tunnel.
The Silver Peak appliance can learn routes from any local network inside the branch via
BGP or OSPF. And the appliance can be configured as a DHCP server. And this
configuration allows you to replace a router or layer three device at a branch.
Also the Silver Peak appliance has firewall features for the WAN-side. You can configure
each WAN interface to allow all traffic, be a stateful NATed firewall, or only allow users at
that site to backhaul data leaving the site.
9
8
Version 8.10.0/8.3.1.SP - August 2020
• Traditional HA
• Operates as two devices (Primary, Backup)
• Each appliance connected to all transports
(1 IP per transport)
• HA Links – 1/10 GbE, using LAN/WAN ports
A
LAN
• Migration of overlay tunnel traffic upon failover
• WAN uplink / underlay tunnel tracking
reduces VRRP priority to favor the newly
elected Master EdgeConnect appliance
L2 Switch
B • Advantage: Highly Resilient

L2 or L3
Devices
Make Path Selection

Deterministic: VRRP, BGP, OSPF
99
Here’s an example of our traditional high availability reference architecture.
Each Silver Peak appliance has independent access and connections to all WAN-
side transports.
Here we still use a primary backup or active-passive model. The second Silver Peak
appliance sits and waits on the primary appliance to fail. SLAs can be configured on
the appliances so that if they lose access to any one of their transport services they
will drop in priority. For example, if A loses access to MPLS, B might take over—
provided it still has access to MPLS and the other transport services.
We recommend using BGP, OSPF or VRRP on the LAN side to make incoming LAN
traffic deterministically choose one path in an active-passive configuration. There are
a couple of reasons for this.
One is to avoid asymmetry if you are using boost. The other is to avoid overloading
upstream routers. Each appliance would typically be configured to take advantage of
all available bandwidth. In an active-active configuration an appliance would not be
aware of how much bandwidth was being used by the other appliance and the
combined throughput of the two appliances could oversubscribe the transport
upstream, leading to congestion, lost packets, and network disruption. This is easy to
avoid by using an active-passive configuration.
This architecture is an alternative to our EdgeHA architecture, which we’ll discuss

next, and is typically used in Data Centers or large sites. While it offers excellent
redundancy, it can be much more expensive because WAN-side switches or routers
are required, and each appliance needs its own IP address to connect to the
transport.
9
9
Version 8.10.0/8.3.1.SP - August 2020
• Edge High Availability (HA)
1. Appliance Clustering
⁃ Each appliance has access to the other’s WAN connections via the HA link
⁃ Only need one WAN-Side IP connection per service provider, rather than one per
appliance
⁃ Automatically reroute packets between two appliances in the event of failure
⁃ Router Mode only! (not available in bridge mode)
2. Advantages
⁃ Saves additional IP address per interface
⁃ Eliminates need for Upstream Router/Switch
⁃ Reduces Capex and Opex
HA Link
Make Path Selection Deterministic:

VRRP, BGP, OSPF
100
This slide illustrates Silver Peak’s Edge HA architecture. It provides High

Availability and flexibility, while saving you money. Two Silver Peak
appliances are connected together over an HA link, and each appliance
operates as an independent unit providing transport services for it’s partner if
required.
VRRP, BGP or OSPF on the LAN-side allows the 2 appliances to work in an

active-passive mode.
If one appliance fails on the LAN side, has full access to the other HA peer’s
WAN side interfaces.
The goal here is NOT maximum redundancy—it is redundancy with cost

reduction. The benefit is that each appliance no longer requires an interface
and a separate IP address to connect to each WAN side service.
In this example, Our EdgeHA saves 3 IP addresses, and eliminates the need
for WAN-side switches, reducing cost while still providing reliable connectivity
and redundancy.
This architecture is typically used in a larger branch or regional offices.

Router Mode – out of path
• Use when In-line Router Mode (ILRM) is not possible
• Often used at Data Centers where traffic redirection is required, often due to
preexisting designs
• Traffic can be redirected using
1. BGP
2. OSPF
3. PBR
WAN
• More complicated to configure, manage and troubleshoot

101
Where inline router mode is not possible due to architecture constraints or

integration with existing networks, Silver Peak appliances can be deployed out
of path. We see this implementation most often in large data centers. The
appliances typically attract traffic with the BGP or OSPF routing protocols, or
you can redirect traffic to the appliances with Policy Based Routing, also
known as PBR, or use WCCP, a legacy redirection protocol that is fading in
popularity. Out of path deployment is fully supported, but traffic redirection can
be more complicated to configure, manage and troubleshoot while increasing
the chance of asymmetry if you are using boost. This is why inline router mode
is generally recommended as a best practice instead of out of path.

Review #10: Router Mode
?
51) What is the name of the mode that is the recommended best practice?
52) True/False: You must use mgmt0 out of band to manage the appliances.
53) What are the 3 basic Silver Peak Reference Architectures?
54) True/False: Router Mode cannot be deployed out of path.
55) How many IP addresses do you need

in router mode?
56) True/False: As shown in the diagram, lan0 wan0
in Inline Router Mode, traffic that lan1 wan1 WAN

arrives on lan1 cannot be forwarded
out lan0.
?
102

Bridge Mode
Now let’s look at Bridge Mode. Bridge mode deployments are also inline, but
differ from inline router mode deployments in several ways.

Bridge Mode
–Also Inline - Connects two segments of the same subnet together
• LAN & WAN Interface Pairs (e.g. lan0 & wan0) form a bridge.
1. Traffic entering LAN can be put in tunnels on its paired WAN bvi.
⁃ No forwarding of Passthrough traffic between bridge pairs e.g. bvi0→bvi1 will not happen.
2. Each pair has a Bridge Virtual Interface; one IP address per BVI (used for data path).
• Management interface must be connected to data path (no out of band mgmt.).
• Stateful FW support, but no ZBF.
• No local breakout with multiple BVIs.
LAN 0 WAN 0
1.1.1.3 1.1.1.2
1.1.1.1 bvi0
L2/3 Switch
bvi1
LAN 1 2.2.2.3 WAN 1
2.2.2.1 mgmt0
2.2.2.2
104
In bridge mode, two interfaces, one on the lan side, and one on the wan side
are paired to make a bridge. Examples woud be lan0 and wan0, or lan1 and
wan1. These are bridges like any other network bridge in that they connect two
pieces of the same subnet together.
Each bridge pair has a bvi, or bridge virtual interface, which has a single IP
address to which traffic is directed and which is used for tunnel termination for
each bridge. Any traffic directed to the bvi on the lan side can be put in any
tunnel terminating on any other bvi, but no passthrough traffic can flow
between bridge pairs.
Unlike router mode, bridge mode requires the use of the management
interface to control the appliance; a bvi cannot be used, so remote
management of the appliance means connecting the management interface to
the data path.
Bridge mode appliances do support stateful firewall settings on the WAN side,
but do not support Silver Peak’s Zone Based Firewall.
One important thing to remember is that if you are doing local internet
breakout, you can’t rely on bridge mode because it’s not possible to forward
passthrough traffic between bridge pairs.

Bridge Mode Bypass: Fail-to-Wire (Glass)
• EC-XS and EC-S ship with "bypass disabled" and the EC-M, EC-L,
and EC-XL ship as "bypass enabled“
• Not supported on EC-US In the event of a failure, a physical
• Not available in appliance in Bridge Mode is taken
Router Mode completely out of the circuit by a
relay that fails-to-wire
Relay
lan0 wan0 WAN
Incoming & outgoing interface speeds, duplex etc. and cabling MUST work end-to-end in case of failure
In bypass, appliance looks like crossover cable
105
Here’s an example of a device in Bridge Mode. You can see a representation

of the electrical relay that exists inside the appliance. In the event of a device
failure, the relay physically connects the incoming and outgoing cables
together in a crossover cable configuration. Although it’s possible to connect
the auto-configuring interfaces on the Silver Peak to switches and routers that
have different speeds and duplex settings, you should not do this, because in
the case of a failure, the switch and router may not be able to talk to each
other. You should make sure that the settings are the same on both interface
lan0 and wan0, and test bypass mode before putting the Silver Peak into
production to make sure you’ve cabled everything up and configured it
correctly to obtain correct functionality in the event the appliance has to put
itself in bypass mode for some reason.
It’s important to note that Fail-to-wire functionality is currently only available in

Bridge Mode, and not in Router Mode.
Also, when a physical appliance is powered off, it automatically goes into
bypass mode.
Remember that only physical Silver Peak appliances come with fail-to-wire
hardware by default. Virtual appliances installed on 3rd party hardware will not
include this capability.

In-Path: Bridge Mode vs Router Mode
LAN WAN
Bridge Mode Router Mode

• Connects (bridges) two halves of a single • Connects to a different subnet on each
subnet interface
• Data Path address assigned to bvi, not to • Data Path addresses assigned to each
WAN or LAN interfaces LAN or WAN interface
• Multicast traffic is bridged as Passthrough • Multicast Traffic is supported w/ PIM
sparse, IGMP and RP as of 8.1.9.1
• Passthrough traffic is limited to forwarding
appliance code.
between LAN/WAN pairs
o Bvi0 (lan0, wan0)
Bridge mode limitations:
• Passthrough traffic
o Bvi1(lan1, wan1) o Traffic forwarded between all interfaces when route to a destination subnet is
o Bvi2 (tlan0, twan0) • No local breakout known to be reachable via a local interface
o Bvi3(tlan1, twan1)
• Less path flexibility o Unknown destination subnet and match default route policy
• No EdgeHA mode • LAN→WAN goes to 1st WAN interface next hop
• No ZBF • WAN→LAN goes to 1st LAN interface next hop (if there is an
optional next hop configured)
106
As we have seen, both Router Mode and Bridge Mode appliances can be deployed Inline. Why are there
two modes, and what’s the difference between them?
1. Well the first difference may seem obvious. Just like any other bridge, a bridge mode appliance
connects portions of a subnet together. An appliance in router mode connects to a different subnet
on each interface, just like a router. A router mode appliance will not bridge those different subnets
together.
2. A data path address which is used as an endpoint for tunnel creation, is assigned to a virtual
interface called a BVI or Bridge Virtual Interface in a bridge mode appliance. The data path LAN and
WAN interfaces themselves do not have an address assigned. The path with lan0 and wan0 will use
the IP address for bvi0, and if the appliance is in 4 port bridge mode, the wan1 and lan1 path will use
the IP address associated with bvi1. In router mode, each appliance interface is assigned an ip
address in a different subnet, just like a router.
3. Multicast traffic, like routing updates from layer 3 devices running OSPF or BGP etc., will be
forwarded between the LAN and WAN ports on a bridge as Passthrough traffic. Starting in 8.1.9.1
appliance code, there is support for PIM sparse mode, so the appliance in router mode can
participate as an RP. In earlier versions of code, when multicast traffic arrives at an interface
attached to a router mode device, the traffic is not forwarded. It is dropped.
4. Any Passthrough unicast traffic that arrives at an interface on a bridge mode LAN or WAN interface
is forwarded across to the corresponding interface on the other side of the bridge. For a device in
router mode, the situation is a little more complex. It acts more like a router, of course, so it needs a
little more intelligence to make the best choice. If the destination subnet is known to be reachable
via a specific local interface, the traffic will be forwarded out that interface. If the destination subnet
is not known, then it depends on the direction of flow. If the traffic is coming from a LAN-side
interface then it will be forwarded to next hop router on the 1 st WAN interface that is up, usually
wan0. If coming from the WAN-side, then a packet will be forwarded to the next hop router on the
first LAN-side interface.
5. Finally, let’s recall some limitations of bridge mode
1. There are limitations on local internet breakout
2. You have less path flexibility with passthrough traffic
3. EdgeHA mode is not supported, so WAN side interfaces cannot be shared between
appliances
4. And there is no support for Silver Peak’s Zone Based Firewall.

Review #11: Bridge Mode
?
57) How many IP addresses do you need in Bridge Mode?
58) True/False: The lan0 and wan0 of an appliance in Bridge Mode connect to two
different subnets.
59) What is the failure mode of an appliance in Bridge Mode?
60) If you want an Inline appliance to use multicast, should an appliance be in Bridge
or Router Mode?
61) True/False: In Bridge Mode, you don’t have to use mgmt0 to manage the
appliance, you can use a data path interface.
62) True/False: In Bridge Mode, lan0 wan0
passthrough traffic arriving on lan0 lan1 wan1

WAN
can be forwarded out wan1 (see picture)
?
107
107

Server Mode
Finally, let’s take a quick look at server mode. Server mode has few uses and
is not generally deployed.

Traffic redirection required.
Server Mode (Out-of-Path Only)

LAN WAN
– Rarely used – few applications

▪ limited IP addresses mgmt0
– The appliance only has one interface – mgmt0

▪ Interface used for data and management
In Server Mode, there is only one
– Uses one IP address Silver Peak interface
– No Firewall functionality
– Default for virtual appliances
▪ Additional interfaces are added in the hypervisor
– Deploying Out-of-Path requires traffic to

be directed to the appliance
109
Here we see an example of the simplest Out-of-Path deployment mode, called

Server Mode. The primary feature of Server Mode is that it only has a single
interface, mgmt0. This interface is assigned a single IP address, which is used
for both for management and optimized data path traffic.
While it is the default deployment mode for virtual appliances, you will usually
additional data path interfaces to virtual machines and tailor it to your
environment.
There is no firewall support for server mode.
Since it must always be deployed out of path, traffic arriving at a router or

switch, must be redirected to the Silver Peak in both directions.

Review #12: Server Mode
?
63) True/False: Server mode is the default for freshly installed ECVs.
64) What is the difference between Server Mode and Router Mode?
65) True/False: Server Mode can be Inline or Out-of-Path.
66) Why would you use server mode?
?
110

A Hewlett Packard
Enterprise Company
Data Security
In this section, we’ll discuss some features related to data security.

Interface Firewall
Modes
1. Allow All
2. Harden
3. Stateful
4. Stateful + SNAT
5. Drop
Each wan interface has settings for the built in stateful firewall.
There are 5 options as shown here.

WAN Interface Firewall Modes – Allow All
– All user traffic is allowed in or out.

– Use with upstream firewalls.
– Use with private networks e.g. MPLS.
– Not recommended for Internet facing interfaces.
113
Each wan interface has settings for the built in stateful firewall.
The Allow All setting shown here means that the firewall is effectively disabled,
and all traffic will be allowed in or out. You will generally only use this on
interfaces on private networks, like MPLS, or where there are upstream
firewalls providing local protection. You should not use this on interfaces that
connect to the internet because of the high security risk.

WAN Interface Firewall Modes – HArden
WAN Interfaces on
physical appliances
are hardened by
default until changed
– User traffic is denied both in and out of the site that is not tunneled.
– No direct to Internet (Internet Breakout) is possible if the Internet interface is
hardened.
– Exceptions (for registration and licensing purposes):
▪ Appliance will still be able to talk to cloud portal through a hardened interface.
▪ DHCP requests and responses will be allowed through hardened interfaces.
▪ DNS queries and responses will be allowed through hardened interfaces.
114
WAN hardening is an option that protects your sites against unprotected

connections. When WAN hardening is enabled, only traffic coming into the site
from Silver Peak IPsec tunnels is allowed to enter.
One implication of this is that you can’t use a hardened interface for internet
breakout, because any return traffic from the internet will be blocked.
There are a few exceptions to this. The appliance will still be able to talk to the
cloud portal through a hardened interface. DHCP requests and responses will
be allowed through, along with DNS queries and responses.

WAN Interface Firewall MOdes – Stateful
Basic branch firewall protection
–Simple Layer 3 & 4 functionality

–Applies to passthrough traffic and traffic that arrives outside a tunnel
• Outbound connections originating from the LAN side permitted
• Incoming connections originating from outside that arrive outside a tunnel will be dropped
–Not an IDS/IPS & no L7 content inspection
115
WAN hardening is safe, but it isn’t very sophisticated. The stateful firewall
setting can be enabled on a per interface basis. This stateful firewall provides
basic layer 3 and 4 functionality that may 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 will be permitted. No sessions
can be initiated from outside the stateful firewall.
It should be noted that this is not a substitute for a IDS or IPS that does deep
packet inspection. The Silver Peak firewall does not look at content, only
connection state, so it doesn’t protect against any malware or viruses that
might be hidden in content accessed by device connecting to an insecure
destination. If your site needs that level of protection, you may wish to locally
deploy an external firewall, or backhaul traffic to a data center that offers more
sophisticated protection.

WAN Interface Firewall Modes
Stateful + SNAT
– SNAT Applied outbound to Passthrough traffic only

▪ Tunnel traffic is not NAT’d by Stateful+SNAT
– Source address will be NAT’d to interface IP
– Source port will be preserved if available, otherwise a new source port will be mapped
– Allows 64k connections per destination address
▪ Tuple = sourceIP+64k_source_ports+DestIP
– Use if no upstream NAT (e.g. local external firewall)
116
The Stateful + SNAT option allows you to perform network address translation
on outbound passthrough traffic exiting on a given WAN interface. The LAN
side source address of the transmitting end device will be mapped to IP
address of the WAN interface. The source port will be preserved if possible,
but if already in use, a new source port will be mapped as well. Since you can
reuse source ports on connections going to different destinations, up to 64
thousand connections per destination address are supported.

Inbound Port Forwarding
– Allows WAN-side devices to connect inbound to a LAN-side server with Stateful
Firewall configured on Silver Peak
– Maps WAN-side IP/ports
EC-V
to LAN-side IP/ports W/ Stateful FW
Web Server
– Allows you to restrict Internet 2.2.2.2

incoming source IPs and Ports 1.1.1.1 2.2.2.253
1.1.1.1 port 80 2.2.2.2 port 80
117
Inbound port forwarding allows devices to connect in through a wan side

interface on an appliance to another device, a server perhaps, on a lan side
interface.
It works together with the stateful firewall that you can configure on the WAN
side of Silver Peak appliances.
1. It does this by allowing you to map the incoming connections to a wan side
address and port number, to an IP address and port on the lan side. In this
example the devices on the internet want to connect to the server on the
right. They point to the wan side address of the Silver Peak, and the Silver
Peak maps the connection to a lan side flow
2. You can also restrict incoming connections so that only certain IP source
addresses or port numbers will be allowed to connect in.

Zone Based Firewall
– Assign interfaces and Business
Intent Overlays to zones
– Create Labels for each zone
– Apply the labels to interfaces and BIOs
– Use a simple matrix to create ACL based
rules to permit/deny traffic between zones
▪ Stateful permit deny between adjacent zones
▪ Allows permit connection initiation in one
direction but deny initiation in reverse
– Intra-zone traffic always permitted X
(between devices in same zone)
118
Silver Peak also supports a Zone Based Firewall, orZBF, that works together
with the stateful firewall functionality.
It allows you to assign each interface and business intent overlay to a security
zone.
1. You can create your own labels for each zone.
2. Then you assign a label to each zone or overlay.
3. A simple matrix view shows you a summary of the permissions configured
between each ingress and egress zone. You can think of the ingress zone
as the one the traffic is coming From, and the egress zone as the one the
traffic is going To. You create the rules just like in an Acess Control List,
and then permit or deny traffic between zones.
4. It should be noted that traffic between devices in the same zone is always
permitted.
5. In the example shown here, there are three zones, On the right are the
zones called Users and Accounting, and on the left is a zone called Server
Farm. It’s possible to set up security policies that permit devices in the
6. Users zone to connect to Server Farm, and
7. Accounting to connect to Server Farm, but
8. Deny connections between the Users zone and Accounting zone.
More training on ZBF can be found in Silver Peak’s learning management
system, along with a hands on lab.

Data Security
– Data is encrypted both in transit and on the physical appliance storage
– Disk encryption protects data

at rest with 128 bit AES
encryption
IPsec
IPsec
WAN Internet
– IPsec_UDP protects data IPsec_UDP
in transit with 256 bit AES
encryption
119
We all need to protect ourselves and our data in a world that is increasingly
less private. Silver Peak offers encryption technology that protects your data in
two ways. First Silver Peak builds tunnels using IPsec_UDP tunnels so data in
flight between sites is protected with 256 bit AES encryption,
128 bit AES encryption of cached data on local disks keeps intruders from
stealing your data.

Encrypted Data: SSL / TLS Required
for dedup
SSL Session
LAN ✓ IPsec LAN
IPsec_UDP Tunnels
Ensure Encryption
120
You may have devices in your network that establish secure sessions via SSL or
TLS. The devices participating in the SSL session are using a certificate to sign the
packets and an encryption key to securely encode the packets. Since the data in
these sessions is encrypted, the Silver Peaks would not ordinarily be able to
accelerate or deduplicate the data being exchanged between the devices because it
can’t look into the data stream. The solution is for
1. the Silver Peaks to get the same certificate and encryption key used by the
devices. The appliances actually establish user sessions with the end devices
over SSL. That way,
2. when the packet arrives at the 1st Silver Peak, it can use its copy of the key to
decode the encryption,
3. Store a copy of the data in its cache and fingerprint it if it’s new, or do a lookup for
data that has been seen before and
4. transmit a small fingerprint instead. The packet can then be encrypted as it
crosses the WAN in the Silver Peak tunnel, using IPsec. When the packet arrives,
the remote Silver Peak
5. will do a lookup in cache,
6. reconstruct the packet,
7. use its copy of the certificate to sign the packet and its local copy of the key to
encrypt it,
8. and send it to its destination, where the end device will use it’s copy of the key
and certificate to decrypt and authenticate it
For webUI, we support TLS v 1.2

For acceleration etc., TLS 1.0, 1.1, 1.2

Review #13: Data Security
?
67) True/False: To block all incoming connections from the internet, the Stateful Firewall should
be set to Harden on an interface.
68) True/False: The Stateful+SNAT interface firewall setting maps LAN addresses to WAN
addresses for packets being placed in a tunnel.
69) If you want to allow inbound connections from the Internet to only one LAN side server, what
feature should you use to permit connections ONLY to that server on the LAN?
70) True/False: A Zone Based Firewall policy that permits connections initiated from zone A to
zone B, will also permit connections to be initiated from zone B to zone A.
71) What is required for us to de-duplicate SSL traffic and why do we need to do it?
72) What tunnel protocol is used by Silver Peak appliances by default?
73) What type of encryption is used to secure Silver Peak tunnels?
?
121

A Hewlett Packard
Enterprise Company
Configuration Process
Overview
Before we dive in to the details of how to configure a network, let’s take a

quick overview of the different pieces and the order in which you should do
things when setting up a network.

Three essential pieces…
1. Labels
• Identifiers to be applied to interfaces.
• Orchestrator will treat interfaces with the same labels
in the same way
2. Deployment Profiles
• Configuration templates for the interface configurations
of a site, the labels to be applied to the interfaces,
interface speed, hardening and more.
• Does not contain IP addresses, as these would be
unique to each site.
• Can be applied to each appliance when it is added to
Orchestrator to be managed
3. Business Intent Overlays
• Configuration templates Orchestrator uses to dynamically create the
overlay network of tunnels that connect the appliances together
• Define which interfaces at each site should be connected based on the
labels applied to the interface
• Defines which sources of incoming LAN traffic (based on labels or
ACLs) should be associated with which WAN overlay networks
123
There are 3 essential pieces to an EdgeConnect SDWAN installation that you need to
complete prior to an appliance’s actual installation. We’ll cover them at a high level
here, and then in more depth when we go over these topics in the configuration
sections of the course.
1. First, you need to configure interface labels. These are abstract identifiers that
applied to interfaces. Orchestrator uses an appliances interface labels to determine
how to treat incoming traffic, based on the LAN interface label or an ACL match. It
decides which network connections to use for that traffic based on the WAN interface
labels.
2. Second, you need to configure Deployment Profiles for each of the types of sites
that you’ll be deploying. These are essentially configuration templates for an
appliances network interface connections. It sets the maximum throughput for each
WAN-side interface, and the maximum throughput for the entire appliance. It also
associates the interface labels you configured with each interface the Deployment
Profile is applied to. It does *NOT* contain IP addresses, because a Deployment
Profile might be applied to many similar sites, and of course, they will have different
IP addresses.
3. Third, you will create Business Intent Overlays. These are the configuration
templates that Orchestrator uses to decide which tunnel and overlay connections to
create between appliances when it sets up the SDWAN network and tells it which
types of traffic will use which overlay connections. The Business Intent Overlays
makes use of the labels when setting up these connections and configuring the
appliances to send different types of traffic into different overlays.

Order of Operations
1. Design and Prepare
▻ Obtain/create topology diagrams
▻ Know link speeds etc.
▻ Understand firewalls and NAT/PAT in use
▻ Decide which traffic should be routed to which sites over which underlay
link types (e.g. MPLS, Internet or LTE) under which conditions.
▻ Identify any hub sites.
2. Install and License Orchestrator

3. Configure Orchestrator
▻ Create Labels
▻ Create Business Intent Overlays
▻ Create ACLs and other required configuration templates
▻ Create Deployment Profiles for type of sites you’ll be installing
(small branch office, large branch office, data center, etc.) Edge Connect
4. Install Appliances
▻ Register appliances with the Cloud Portal
▻ Approve the appliances in Orchestrator
5. Watch Magic Happen
124
You might have realized there are several moving parts to the installation, and are
wondering what you should do first, what you should do second, and so on. This will
give you an overview of the order in which you need to execute the various tasks in
order to have a successful installation. I won’t read every bullet on this slide to you,
but it’s here for your reference, and in the labs associated with this course, you’ll do
all these tasks in the correct order.
1. To begin with, always know your network, and the network you are trying to create.
Make sure you have topology diagrams and link speed information etc. so you can
correctly configure and install the appliances.
2. Afterwards, the first part of the actual installation is to install the Orchestrator. It
must be first. You can’t deploy an EdgeConnect appliance until the Orchestrator is
deployed and registered.
3. Once the Orchestrator is registered, you will need to do some pre-configuration to

prepare for appliance installation. This includes creating labels, Deployment Profiles
and Business Intent Overlays as we mentioned earlier. In addition to LAN-side
interface labels, Business Intent Overlays can use ACLs to decide which traffic to
route in to an overlay, so you’ll need to configure those ahead of time if needed.
4. When you have all your pre-configuration tasks completed in Orchestrator, you’re
ready to start installing appliances. It goes pretty quickly because at this point, it’s
mostly applying templates, and filling in a few blanks, like local IP addresses.
5. Then sit back and watch as the Orchestrator builds all the connections and the
appliances start routing traffic between them.

Interface Labels
Once you have installed an Orchestrator and are ready to start installing
appliances, there are some tasks you should complete to prepare for a
seamless installation. We’ll start by discussing interface labels and deployment
profiles.

Interface Labels
– Two Types: LAN and WAN labels
1. LAN labels
▻ Traffic entering a LAN interface with a particular
label could be sent to a particular BIO and handled
as configured in the overlay
▻ Can be applied to an untagged interface, or a
tagged VLAN sub-interface.
2. WAN labels
▻ Identify the network service the WAN interface will
connect to
– Labels are completely arbitrary
▻ They are just names to facilitate other functions
like automatic tunnel building or how traffic will
be handled
▪ You can create new labels as needed and call them
anything you like
– Default labels are created for you
▪ Make more if needed/desired. (e.g. Comcast, BT, AT&T, etc.)
126
Interface labels are pretty much what they sound like. They are completely
arbitrary identifiers used to mark an interface. By themselves, they don’t cause
any functional change, but they do cause all the interfaces with the same
labels to be treated the same way by Orchestrator when it is configuring each
appliances connections to the network.
There are two types of labels, LAN and WAN, which can be applied to their
respective type types of interfaces.
1. In the diagram in the upper right, you can see an example of the interface
used to create and manage labels.
2. Below that, you can see an example of the labels being applied to interface
configurations.
LAN interface labels can be used by Orchestrator to identify the interfaces

from which to route traffic into an overlay network, although it is more common
to match traffic via ACLs rather than interface labels. WAN-side interface
labels identify the WAN connections that Orchestrator should use to build
tunnel connections between appliances.
You’ll see more about how this is done as we explore other topics moving
forward.

Deployment Profiles
After you configure the interface labels, you need to configure deployment
profiles to be used as templates when you are installing appliances in your
network.

Integrated Firewall
Deployment Profile Overview Settings
– A template for how an appliance will be

configured for a site
• Includes Mode and interface configuration (LAN and
WAN)
o Interface Labels
o Firewall Settings per interface
o WAN Link speeds & Max WAN Bandwidth
o VLAN numbers can be saved
o NAT flag (tells orchestrator to use the public IP for tunnel
building)
• Does not include IP addresses (because all sites Total Outbound = Max WAN BW
are probably different) Clicking ‘Σ calc’ will sum int BW
Boost & Plus Licensing
– Create multiple deployment profiles (one for
each type of site) and apply during install from
Orchestrator
• Give each a descriptive name
Looks just like the manually configured
deployment on an appliance
128
Deployment Profiles are templates for configuring the mode and interface
configuration of an appliance. This is where you set the appliance up for
Bridge Mode, Server Mode or Router Mode, and determine the number of
interfaces and sub interfaces it will use. It can include the VLAN numbers
associated with each interface or subinterface.
1. You can also set the throughput limits, the total allocated inbound and
outbound WAN bandwidth for the appliance, also known as Max WAN
bandwidth, and
2. enable Plus and Boost licensing for the appliance.
3. This is also where you where you preset the stateful firewall configuration.
If you are using the zone based firewall feature, this is where you can set
the firewall zone label for the interface.
It should be noted that the deployment profile, since it is a template that might
be applied to multiple sites, does not include IP addresses, as these will differ
by appliance. Instead IP addresses are filled in when the deployment profile is
applied to a site.
You will probably create a deployment profile for each type of site in your
network, and apply them as needed.

TWO Deployment CONFIGURATION AREAS
– Deployment Profile
▪ On the Orchestrator
▪ IP Addresses not
configurable
– Deployment “Screen”
▪ On a specific Appliance
▪ IP Address configurable
129

Deployment vs Deployment Profile
• Both allow configuration of sub-

interfaces, vlans, labels, Firewall
Settings and Bandwidth
130

NAT flag
– Lets Orchestrator know to use the public IP to try as a destination address for tunnel building
– If Public IP changed, Overlay Manager will fix it IKE-less NAT support in 8.1.6+
(IPSEC_udp tunnels)
Allows you to define external IP for

this interface
131
Network Address Translation, or NAT is commonly used to map internal IP

addresses, typically RFC 1918 addresses, to a unique IP address which is
seen on the internet. If you are using NAT with appliances, you should use 1:1
address mapping on at least one end to avoid IPsec negotiation problems.
Additionally, each interface on the deployment profile has a NAT flag which
can be enabled or disabled. When your appliances are behind a NAT device,
and it is necessary to build tunnels across the Internet, this flag can help
Orchestrator build tunnels to the correct address.
You can also enter the external IP address that Orchestrator should use to
build tunnels to this site for a given interface label. This might be necessary if
the NATing to the cloud portal is different than the NATing between the
appliances in the case where there might be multiple service providers, or
paths through different firewalls.
We’ll show you an example of how the NAT Flag works on the next slide.

Internal External
NAT Flag Example
Cloud Portal A=10.10.1.1 75.10.1.1
B=10.10.2.2 75.10.2.2
Internet → Behind NAT
Orchestrator Internet MPLS → Not Behind NAT
A 75.10.1.1 75.10.2.2 B
MPLS
10.10.1.1 10.10.2.2
A Builds Tunnels to B
NAT = Build tunnel from 10.10.1.1 to 75.10.2.2
Not Behind NAT = Build tunnel from 10.10.1.1 to 10.10.2.2

132
This example helps to illustrate how the NAT flag can be properly applied to interfaces.
Here we have two EdgeConnect appliances which are talking to the Silver Peak Cloud Portal,
and are being managed by an Orchestrator. The appliance on the left has an internal RFC
1918 IP address of 10.10.1.1, and the one on the right has an address of 10.10.2.2.
1. They are connected to the Internet through firewalls, which perform Network Address
Translation. The firewall translates the address on the left to an external address of
75.10.1.1, and the one on the right is translated to 75.10.2.2 on the Internet.
2. When the appliances register with the Silver Peak Cloud Portal, they tell it their configured
IP addresses, of 10.10.1.1 and 10.10.2.2. Because the Cloud Portal is getting this
information after NAT has been performed, it sees the registration packets originating from
their translated addresses of 75.10.1.1, and 75.10.2.2 respectively. The Cloud Portal
stores both of these values.
3. The next time the Orchestrator polls the Cloud Portal, it learns both addresses. These
actually show up in the appliance information which can be viewed in Orchestrator. After
approving the appliances, the Orchestrator has to decide which address to use to
terminate the remote end of the tunnels that will be built in each direction. The source
address for each tunnel will always be an internal, locally assigned address, but will it point
to the internal or external address of the remote appliance when building the tunnel.
4. If it is building tunnels across the internet, then you need to enable the NAT flag. When
configuring tunnels on the device on the left, for example, the source address of the tunnel
will be 10.10.1.1, and the destination address will be the translated address of the remote
appliance, or 75.10.1.2. It will do the same thing in the reverse direction on the appliance
on the right.
5. If however, the appliances connect over a private MPLS connection that doesn’t transit the
NATting firewall, then Orchestrator would build a tunnel on the left hand appliance from
10.10.1.1 to 10.10.2.2, and perform the same operation on the device on the right in the
reverse direction.
It’s possible that you will have one interface that connects to the internet, and one that
connects via MPLS. In that case, you would enable the NAT flag on the interfaces connecting
through the Internet, and turn it off on the interfaces connecting through the MPLS network.

VLAN Config This interface will appear in
As of 8.1.9
•
•
the config as wan0.12
12
13
Blank means untagged WAN next hop is needed to

forward tagged Passthrough
traffic for each VLAN
Adds new subinterface. Assign
VLAN number and IP address for
sub-interface
133
133
Configuring VLANs is fairly intuitive. The screen will look a little different
depending on the deployment mode, but the process is very similar. Fill in the
VLAN box on the interface if you want to add the interface to a tagged VLAN.
For untagged native VLANs, the box is left blank.
1. When you tag a VLAN, it will appear in the interfaces configuration tab with
a suffix that uses the VLAN number. These two WAN interfaces would
appear in the interface configuration as wan0.12 and wan1.13 respectively.
2. To add an additional VLAN, add an interface or, click on +IP Address and
then enter the Appliance IP for a new sub-interface, VLAN number, and a
WAN next hop for this VLAN.
3. A next hop WAN address is required for each sub-interface so the
appliance can correctly hand-off tagged Passthrough traffic to the router for
forwarding. Optimized traffic will, of course, be placed in a tunnel and
forwarded to the next hop on the WAN interface associated with the tunnel.

Stateful & Zone Based Firewall (ZBF) settings
• Each interface can be in a different security zone and have a different stateful FW setting.
• Zone labels are defined on Orchestrator and applied in the deployment profile
• Zone labels are used with security policies to permit or deny traffic
Note: Each Overlay is also in a zone.
Account for this when creating
from Ingress zone → Egress zone security policies!
• Connections are stateful, so ‘permits’ are unidirectional between zones
Inline only!
(Bridge or ILRM)
Any Subinterfaces must use the

same setting as main interface
134
Also part of the Deployment profile are the setting for the stateful firewall
mode, and the Zone Based Firewall.
Each interface can have a different stateful firewall setting, and ZBF label
setting. It should be noted that any sub interfaces should use the same
settings as the primary interface when configuring these settings.
Don’t forget when configuring your security policies for ZBF, that each BIO is
also in its own zone, and security policies need to account for this when
considering ingress and egress zones.

Want to know more about ZBF?
304 - Zone Based Firewall (LAB based on 8.5.1/8.1.9) [self-paced] {3 hours)
–ZBF is covered in more detail

in the 221 - ASD course and in
a LAB based self-paced course
at training.silver-peak.com
• You can also do a search for the course in the Learning Management System
135
If you want to know more about Zone Based Firewall, there is a stand alone
self-paced training course covering this subject in depth, that includes a hands
on lab. You can search for Course number 304. Additionally, if you plan on
taking the 221 - Advanced SDWAN Deployments course, most of the same
information and labs are covered in that.

Review #14: Interface Labels and Deployment Profiles
?
74) True/False: An interface labeled ‘Voice’ only allows VOIP traffic.
75) True/False: A deployment profile defines how many interfaces and sub-interfaces will be
configured for an appliance.
76) Does a deployment profile…

a. Contain IP addresses? lan0 wan0 wan0 lan0
Internet
b. Can include VLAN numbers?
c. ZBF (Zone Based Firewall) security policies?
77) Customers need to access a LAN-side web server inside a branch office. (see diagram)
What WAN-side (Internet) firewall settings and features should be used?
78) What is the purpose of the NAT flag?
79) True/False: Your network branch offices have overlapping local subnet addresses in the
192.168.x.x space. Enabling Stateful+SNAT will hide the overlap because the tunnel traffic
will be NAT’d.
?
136

Using Templates
Template groups are useful tools for configuring devices. They let you
configure things like security policies, passwords, enable and disable
different features, and configure logging and alerts and more. Let’s
examine them in the next few slides.

Why use Templates?
‘?’ Inline help is available on most screens
Click on icon
– Simplifies and automates the application of new

or updated configurations to appliances
– Saves Time
– Guarantees consistency of configuration
where it is desired
– Reduces Risk – Using stored & verified
configurations reduce the chance of errors
138
Template groups can greatly simplify and automate the configuration and
management of or your appliances, and helps guarantee that changes are
made in a consistent manner across your network. Using a template to apply
the same changes to multiple appliances can save you time, and, because the
changes will be the same for all appliances that the templates are applied to,
they can reduce the likelihood of configuration error. Silver Peak recommends
that you use templates whenever possible.

Common Terms
–Template Group: A collection of templates used to
configure settings on one or more appliances.
–Template: A group of configuration settings that control
the behavior of a feature or set of features.
• E.g. the System template, Tunnel Template or SNMP template
• Active Templates will be applied to appliances as part of the template
group
‘?’ Inline help is available on most screens

Click on icon
139
Let’s understand some basic terminology before we proceed.
A “Template” is a group of configuration settings that control the behavior of a

feature or set of features.
A Template Group is a collection of templates used to configure settings on a single
appliance, or across multiple appliances.
By clicking the question mark in any template, you can get an explanation of every
field in the template.
In this example you can see we have clicked on the System template on the left, and
part of it is displayed in the lower center of the screen. There are checkboxes for
enabling or disabling features, and input boxes for typing in values. Each template,
like the Tunnels template or the Route Policies template, has a set of values that can
be saved with a template group. Then the active templates in that group can be
applied to the desired appliances in your network.

Merge and Replace
–Some templates will REPLACE all settings on the appliance with the template
settings unless the MERGE option is selected.
140
Some of the templates have a setting allowing you to choose whether to

Merge the items in the template in the Orchestrator with the ones locally set in
the appliance. An example of this would be a list of rules in an access list or
ACL. If you choose Merge, the rules in the template will be merged with the
ones on the appliance. If you choose Replace, the entire ACL in the appliance
will be replaced with the one from the Orchestrator.

Applying Templates Click ‘Hide All’ to show only Active Templates
–To apply templates to

appliances
• Select one or more appliances
in treeview,
• Templates in the Active column
Where a Which can be applied to appliances
template templates
would be would be • Click Apply Templates. A
applied applied
dialog appears, asking you to
confirm your choices.
• Changes must be saved before
you can apply
141
In order to apply any changes to devices in your network, select one or more
appliances in the tree view on the left, make sure that all the templates you’d
like to apply are in the active column, then click apply templates. Only the
templates in the active column will be applied. The settings for templates in the
Available Templates column can be saved as part of the template group, but
not applied.

Review #15: Template Groups
?
80) Why do we use Template Groups?
81) Where can you get an explanation of template fields?
82) How do you determine which appliances a template will be applied to?
83) How do you determine which template(s) will be applied

for a given template group?
84) Some templates replace all the configured entries on the appliance unless
you select _________.
?
142

30
LAB 3 Configure GROUPS and Labels
LAB 4 Configure Deployment Profiles
LAB 5 Template Groups Configuration

Business Intent Overlays
In this lesson we will explain the use and configuration of Business Intent
Overlays, which are created on the Orchestrator, and applied to the
appliances.

BIO Summary Screen
Click ‘+’ to expand column and
show additional information
Overlay Name
Click and drag

to Reorder
(change
priority)
Summary of Each Overlay’s configuration
145
Starting in Orchestrator release 8.7, overlay configuration is summarized, with

a row for each overlay. You can see the 4 default overlays in this list.

BIO Configuration “Tabs”
Click anywhere in these columns to edit basic overlay Click anywhere in this column to
configuration (SD-WAN Traffic to Internal Subnets ) edit policy order and breakout
146
When you click, on an overlay on the summary screen, you get the
configuration screen for that overlay. Here is what the configuration screen for
an individual overlay looks like. Notice there are two tabs:
SD-WAN Traffic to Internal Subnets and Breakout traffic to Internet &
Cloud Services.

Tab 1 - SD-WAN Traffic to Internal Subnets
Configuration options for traffic flowing between appliances in tunnels
Topology Overlay Region
Traffic match config
Tunnel Quality
Thresholds config
Primary and Backup Drag to Primary or Backup

Labels are put here
QoS, Security, Boost
Link Bonding Policy

147
Here is the main tab for configuring SD-WAN Traffic to Internal Subnets. Let’s
take a high level overview of the sections, then we’ll dive deeper into each
section.
1. At the top is where you configure the Traffic Match Policy. As we’ll see in a
moment there are three ways to do this. The most commonly used method,
Overlay ACL is shown here. We’ll look at the others in a moment.
2. Here is where you choose the overlay topology, full mesh, or hub and
spoke for example, as well as their regional variants.
3. In the upper right is where you choose the region you are configuring, if
you are using regional routing.
4. In the center is where you choose the interfaces to be used for this overlay.
This is done by dragging and dropping from the list of available interfaces
to it’s right.
5. At the bottom is where you choose the link bonding policy, which
determines operational parameters for the chosen interfaces.
6. You can configure the Service Level Objectives for loss, latency and jitter. If
one of the configured thresholds are exceeded, the appliance may stop
using a tunnel that is not meeting objectives.
7. Finally you can set QoS, Boost, Firewall Zone and what action to take
when the configured backhaul or breakout actions are not possible.

Tab 2 - Breakout traffic to Internet & Cloud Services
– For traffic not being sent over the SD-WAN fabric

– More details later after we look at Tab 1 Details in next few slides
148

Traffic Access Policy (Match Traffic)
3 ways to match incoming traffic to an overlay… Overlay ACLs editable here…
1. Overlay ACLs
2. Appliance ACLs used to
map different types of traffic
to different overlay networks
Select Appliance ACL from list
3. LAN port labels to map all
traffic on matching ports to
an overlay network
• There must be a local LAN
interface or subinterface with a
matching label or traffic will not
be sent to the overlay network
–One Label or one ACL per

overlay
Select LAN label from list
149
We’re going to go through all of the configuration elements for business intent overlays in the
next few minutes.
Let’s begin by talking about how traffic gets matched to a particular overlay.
The traffic access policy is used to determine which traffic entering an appliance will be sent to
an overlay for transmission across the network. There are three methods available. You can
use Overlay ACLS or Access Control lists, ACLs that are part of a template group, or interface
labels.
1. Per Overlay ACLS are standard Silver Peak ACLs, and just like all the other ACLs you’ll
use in this product. This allows you to automatically pair ACL access with the Business
Intent Overlay, and any changes will automatically get pushed to the appliances.
2. Appliance ACLs are configured on each appliance, and can be pushed out to a group of
appliances via a template group. You can also choose from a list of available ACLS that
will be applied to appliances during installation. Any traffic on any LAN interface that
matches the ACL will be routed into the overlay network.
3. If you are using LAN port labels labels, then traffic entering interfaces with matching labels
will be routed into the overlay network. When you configure the Traffic Access Policy, you
select from a list of available labels to choose the one that will be used in this Overlay. It
should be noted that there must be a local LAN interface or subinterface with a matching
label from which traffic enters the appliance, or the overlay network will be built, but remain
unused by the appliance because there is no matching traffic source. LAN port labels don’t
give you much detailed control and their use for traffic access to a BIO is less common
than ACLs.
4. You can only use one label or ACL per overlay to control traffic match, and the methods
cannot be combined.
Wildcards in ACLs
Can be used in other types of rules also.
• Three different wildcards supported

1. ‘|’ (pipe) functions as ‘OR’ between items in a list
• E.g. 10.110.30.0/24|10.110.33.0/24
2. ‘*’ (splat / asterisk) wildcard matches any value

• E.g. 10.110.*.* or 192.1*8.*.254
3. ‘-’ (dash) allows specifying a range

• E.g. 192.168.1.1-33 or 10.110.20-30.254 or
10.110.22-33.0/24
• Introduced in 8.1.8.1 appliance software
150
Now let’s take a quick look at wildcards. This capability was added in 8.1.8.1 appliance code and can be used in a
number of places whenever you need to enter rules, including ACLs, Route Policies and Security Policies,
First we’ll look at the pipe. You can see an example here of two subnets separated by a short vertical bar that’s
generally referred to as a pipe. The pipe functions as an ‘or’ separating multiple items in a list, meaning that if any of
the values in the list are matched, then the match is considered true. So in this example, Note the pipe ‘|’ between
the subnets. Since this is interpreted as an OR, it means that if either of the subnets entered is matched, then the rule
is a match. Here we entered the same two subnets with a pipe in both the source and destination fields, meaning that
either subnet can be the source or the destination and the rule will be matched. You can string a number of subnets
or addresses together in a rule this way, greatly reducing the number of rules you need to create.
1. It’s also now possible to enter one or more wildcards in an address using an asterisk, also called a splat or a star. In
this example we show 10.110.*.*, meaning that as long as the first two octets in the address contain 10.110, then
either of the last two octets can contain any value. The second example shows 192.1*8.*.254. For a match, the first
octet must be 192, the second must contain 3 digits starting with a one and ending with an 8 but the middle digit can
be any value, the 3rd octet can be any valid value, and the 4th octet must be 254.
2. You can also enter a range of addresses using a dash. The 1st example shows 192.168.1.1-33 meaning that the last
octet is a match for any value between 1 and 33. In the 2nd example, 10.110.20-30.254, the 3rd octet can hold any
value between 20 and 30. The final example will match any subnet starting with 10.110, and having a 3 rd octet in the
22-33 range.
Again, this is only possible in more recent versions of code.

Topology and regions
– Topology
▪ Each BIO has a Topology type:
Mesh, Hub & Spoke, Regional Mesh or Regional Hub & Spoke
▪ Appliances in a Mesh network will have tunnels built between all
devices
▪ Appliances in a Hub & Spoke network will only have tunnels
built from spoke devices to hub devices
– Hubs:
▪ Connect to spokes and each other
▪ Advertise routes to spokes and each other
▪ A hub is a hub in all overlays applied to it
– Regions
Region A Region B
▪ Allow you connect groups of appliances via one or more hubs
▪ Reduces the overall number of tunnels needed because hubs
can connect regions together
Mesh
▪ Spokes can connect to other regions through hubs in their local Hub Hub
region
Spokes
151
One of the first things you need to decide is the topology of an overlay network. Will it
be a mesh network or a hub and spoke network? Also, Will you be using regions, and
if so, will your reqions be full mesh or hub and spoke.
As you can see in the illustrations, mesh devices are all connected to all the other
devices in the mesh.
Spoke devices only connect to hubs, and not to other appliances in the network. In a
regional mesh configuration, which we’ll be discussing in more detail in a few
minutes, the devices a in each region are fully meshed. In a regional hub and spoke
topology, the devices in each region all connect to the hubs in their region.
1. Hub devices for an overlay are selected from the list of devices that Orchestrator
manages. In newer software, a hub is a hub in all Overlays it is a part of. While older
software allowed this selection to be per overlay, it lacked full regional support. We’ll
be focusing on more recent software in this course, and show you how hubs are
selected in just a moment.
2. You can reduce cost and complexity in large networks by using Regions. Regions
allow you to group appliances and they will form connections only within their regions.
Only devices with matching region names will have tunnels built between them
according to the type of topology you have selected. When you enable Regional
Routing, which we’ll talk more about in a minute, the hub sites in different regions
which are part of the same overlay, will connect to hubs in other regions. The
interconnection between hub sites in different regions will be full mesh for all the hubs
checked in the overlay, even if you select a hub and spoke configuration for the
different regions. If you don’t want to build tunnels between certain hub sites, you can
give them the same site name.

Overlay Regions
• Each Overlay can have different configurations for each Region
• E.g. RealTime overlay can have different configs for Region1 vs. Region2 (different Traffic Match, SLA,
different underlay links, link bonding policy etc.)
• Effectively increases the number of available BIOs, since each one can have multiple configs
• Devices not part of a user defined region will be in the Global region and use the Global overlay config
Hubs and Regions are covered in depth in the ASD (Advanced SDWAN Deployments) course and a
self-paced course: 321 - The New Business Intent Overlay UI and Regional Routing
152
152
Each BIO can have a different configuration for each Region it is a part of. For
example, the RealTime overlay shown here, can have different configurations
Globally, or in regions 1, 2 or 3 as shown here.
One implication if this is that you effectively have more overlays than in
previous versions of software, since each overlay can have multiple
configuations.
Any appliances assigned to a region will use the overlay configuration for that
region. Any appliances not assigned to a region will use the Global config for
that overlay.
1. Hubs and Regions are covered in depth in the ASD (Advanced SDWAN
Deployments) course and a
self-paced course: 321 - The New Business Intent Overlay UI and Regional
Routing

Underlay WAN Links to use for THE overlay
Traffic that is matched by LAN label or ACL is transported through underlay network connections based on this
–Primary
• Choose one or more primary networks. Drag available interface
• Traffic will be send on the primary networks labels to Primary or Backup
unless a blackout (link down) or brownout
(performance threshold) condition is
encountered.
–Backup
• Used in case of blackout or brownout
• Choose one or more networks
–Add Backup if…
• Down
• Not Meeting Service Levels
o exceeds performance thresholds (see next
slide)
153
The Primary and Backup interface labels are for choosing the WAN
connections across which the traffic entering the overlay network will be
transported. Remember each logical overlay network makes use of underlying
physical network connections. You choose the underlay connections to use for
this overlay when you configure the primary and backup labels.
Depending on the link bonding policy used, you must choose at least one
primary network. The list of networks is based on the list of WAN interface
labels available. Drag the labels you want to use as primary from the Available
Interfaces column to the primary section, and do the same thing for backup
links to be used in case the primary links all fail.
You have a choice in deciding when to mark a primary network as unusable

and fail over to a backup by choosing Down or Not Meeting Service Levels.
Down, just like it sounds, says go to a backup connection only when it is
completely down. Not meeting service levels used to be called Brownout. It
allows you to set performance criteria for the networks, such that when one of
the criteria is exceeded, the connection is browned out and may not be used
any more. We’ll look at Service Level threshold settings on the next slide.

Cross Connect Groups
–Allows you to add each interface label to
a cross connect group
• In earlier versions you had to cross
connect all labels or none
–Orchestrator will only attempt to build
cross connect tunnels between
interfaces with labels in the same
Cross Connect Group
• Group is selectable per label
• Multiple groups with different labels are
possible
• E.g. in this example, it will try to cross INET1 and INET2 in a Cross Connect Group
connect MPLS1 and INET1, but not INET1 Cross Connect
LTE (which has ‘None’ selected) INET2
–Configurable per Business Intent

Overlay
154
Cross Connect Groups for Primary Interfaces allow you to select the interface
labels that will be included in a group, and Orchestrator will only attempt to
build cross connect tunnels between interfaces with labels in the same group.
This is configurable on a per overlay basis, so they don’t all have to be the
same.
This is for providing additional redundant links between two service provider
networks as illustrated. Cross connect allows some redundancy between
interfaces with different labels. Normally you would only build underlay tunnels
between interfaces with the same label – e.g. inet1 to inet1. But, for example if
you were to lose a connection from inet1 to inet1 between siteA and siteB, but
you are able to reach siteB from siteA with a cross-connect link between inet1-
inet2. having those labels in a cross connect group would allow you to
maintain connectivity using a different underlay tunnel and keep the overlay
up.
Cross connect groups should only be assigned to interfaces that have

connections through the internet, as cross connections between the private
address space of an MPLS network and the public address space of Internet
are likely to fail. Up to 9 cross connect groups are available.

Secondary Connections
Add a layer of failover between Primary and Backup
–Primary will fail over to
Secondary before Backup
–Backups will only be used if
Secondaries also fail
–Drag labels to secondary
box just like primary or
backup
–Failover happens if Service
Level Objectives (SLOs)
are not met
–Click +Secondary to add

Secondary labels
–Click –Secondary to
remove
155

Service Level Objective 0 or no limit
• Under what conditions do you stop sending means Ignore
traffic to an overlay connection that uses a
particular physical link?
• Loss – packets that don’t reach their destination
(pre-FEC)
• Bad for all traffic
• Latency – how long in milliseconds does it take

a packet to arrive Measurements updated each second
• Especially bad for stateful protocols that require packet receipt
acknowledgement like TCP. Reduces throughput. 40.0
Typical WAN Latencies:

• Jitter – packet-to-packet timing arrival variation 30.0
- Cross US: 60-120 ms
Maximum Throughput (Mbps)

- International: 50-200 ms
• High jitter is bad for VOIP and video 100ms
20.0 50ms - Satellite: 550 ms
10ms
• Probably irrelevant for email etc.
• Values are OR’d - only need to exceed one to

10.0
Typical WAN Loss Rates:

• MPLS: 0.1% to 0.5%
trigger a change 0.0
10
%
20
%
50
%
00
%
00
%
00
%
00
%
00
%
00
%
.00
0% • Public Internet: 0.5% to 1%
0.0 0.0 0.0 0.1 0.2 0.5 1.0 2.0 5.0 10
• If there are two Primary links, one would be

Packet Loss Probability
marked down if it exceeds the configured

thresholds.
156
Link Brownout Thresholds are used to set brownout

criteria used to mark a network connection unusable, as
we mentioned on the previous slide.
There are 3 criteria: Loss, Latency and Jitter.
Packet Loss is measured as a percentage, while latency

and jitter are measured in milliseconds. Each
EdgeConnect constantly measures this and updates the
measurements each second. If any one of the
measurements exceeds the threshold value, the link is
browned out. It is not necessary to exceed all three.
It’s worth noting that if any of the values is set to zero or

no limit, then that parameter is ignored. So, for example,
you could set a value of 5% for loss, and set latency and
jitter to zero. Then only loss would be used to mark a link
down.

Link Bonding and Failover
–Link Bonding Provides Greater Resiliency Against WAN Link Failure
Backup 4G / LTE Emphasize: Resiliency or Throughput
MPLS (~1.5 – 10Mbps)

Packet Based Multipathing
Primary Bonded Tunnels
Internet
(~50 – 200Mbps)
Brownout Aware
157
Here is an example of a site with 3 connections. Links can be logically bonded

together to create an overlay connection. As we’ll see in a few moments, the
overlay connections can be configured in various ways to emphasize resiliency
or maximize throughput, and simultaneously make use of multiple links.
In this example, our site has an Internet connection, an MPLS connection and
an LTE connection. We can
1. Logically bond multiple connections, Internet and MPLS, for instance as
our primary paths.
2. If the Internet connection goes down, we can use the MPLS connection.
3. Only if both Internet and MPLS were to fail, will we fail over to LTE as a
backup, and statefully move all the traffic over without dropping a
connection.

Link Bonding Policies
• High Availability (HA)
• 1:1 FEC ratio—Better than mirroring. Send duplicate packets over multiple paths for maximum reliability. Trade bandwidth
efficiency for dependability. Instantaneous failover in the event one path goes down. Requires at least two links active
simultaneously for instantaneous failover and lossless transmission. Only two best quality links will be in use at a time.
• NOTE: In case of link failure, a single remaining link will operate with 1:5 auto FEC until a 2nd primary is available.
• High Quality (HQ)
• >80% BW efficiency on the active link. 1:5 variable auto FEC. Prefers best path. If 2 or more Primary paths, will use 100% of best
path for data, and put FEC on 2nd best path.
• High Throughput (HT)
• Load Balances between available paths (round robin) for greater throughput (traffic is distributed across multiple paths so their
aggregate bandwidth is used). Requires two active links for load balancing. Fills path with most available BW first until available
BW is equal. 1:5 variable auto FEC
• High Efficiency (HE)
• Similar to HT, but no overhead (or protection) from FEC. Load Balance (round robin), Aggregate bandwidth usage most efficient.
Exposure to loss. Requires two active links for load balancing. Fills paths based on % of utilization, so fills path with least %
utilized first.
• Custom
• Tune all the Nerd Knobs
• 98%+ of all customers
will never need this
158
Here are the 4 available link bonding policies

High Availability should be used for your most critical applications and requires at
least two Primary Links. It uses 1:1 Forward Error Correction, or FEC, sending all the
original traffic over the best quality link, and sending an equal number of FEC packets
over the next best link. This is the most resilient configuration, but you are trading
resiliency for some throughput. Bandwidth efficiency is 50% since you are essentially
sending a duplicate copy of the data over the 2nd link.
High Quality also stresses resiliency, but is more bandwidth efficient. It and uses 1:5
variable auto FEC, meaning that if there is no loss, little or no bandwidth will be used
for FEC data, but if loss occurs, it can ramp up to 20% FEC packets. If you are using
two or more primary links, the best quality link will be used for the original traffic, and
FEC will be sent on the 2nd best path.
High Throughput balances throughput and resiliency. It requires two primary links,
and can load balance traffic across them. It uses 1:5 variable auto FEC so at
minimum, it is 80% efficient if FEC traffic rises to its maximum.
High Efficiency is similar to High Throughput, allowing load balancing, but disables
FEC for maximum bandwidth efficiency. This is a setting you might want to use on a
private line with no loss. It’s probably not the best choice for links that have loss as
the retransmissions that must occur in that case can really slow down throughput,
especially in latent environments.
If you are using multiple primary links in a bonding policy, as a best practice, similar
latency characteristics are recommended. Otherwise when loss occurs, you are
somewhat limited by the speed of the slower link. This is not really a Silver Peak
limitation, just the way that data transmission works if you think it through.

Visualizing Link Bonding Policies
Path Conditioning
Link Selection
FEC
1:1 Adaptive
Best Quality Path Load Balance
DPC, FEC, POC None
159
The differences for Path Conditioning, Link Selection, and the use of FEC are
illustrated here. They can essentially be broken down into two sides:
1. For Path Conditioning, traffic is treated when selection the HA, HQ, or HT
bonding policies on the left. When selecting HE, no Path Conditioning is
applied.
2. You can see link selection options are to choose Best Quality Path on the
left for HA and HQ, while Load Balancing is done on the right for HT & HE.
3. Lastly, for FEC, 1:1 is only done on HA, while adaptive FEC is utilize when
selecting HQ and HT. There is no FEC done with HE.
4. Of course, as mentioned, do not use the Custom option without consulting
TAC or your SE.

Different policy settings for hubs & spokes
–Can be different for each hub – all spokes the same
– Click on the hub name If you want branches to backhaul traffic to a hub for
– Uncheck Use Branch settings local internet breakout from the hub site (e.g. a
data center), you must do this!
In the example
shown here,
branches will
Backhaul all traffic,
but hub ECV-4 has
can Break Out
Locally and
Backhaul.
160
It’s possible to have different policy settings on Hubs and Spokes in a network. The
branch settings apply to all devices unless you Click on a hub. This will bring up the
configuration for that hub, which will allow you to configure settings different from the
branch office sites which are not hubs. One use for this is to make it easy to configure
all the branches to backhaul all traffic to the hub sites, and then configure the hub site
to allow internet breakout, and presumably at the hub site, you will have powerful
firewalls that can inspect outgoing and incoming traffic.
At any time you can check the box to revert the hub to use the branch settings by
checking the box that says Use Branch Settings.
In the example shown here, branches will backhaul all traffic, but hub ECV-4 has the
ability to break out locally, in addition to backhaul. ECV-4 should probably advertise a
default route to the branches to attract traffic that needs to be broken out to the
Internet.
So to summarize, you click on Branch settings to configure all the non-hubs. If you
click on a hub name and uncheck the ‘use branch settings box’, settings can be
different for that hub. You can have different settings for every hub in the overlay, but
all the branches will be the same. If you recheck the box for a given hub, it will revert
to branch settings.

Firewall zone
– Each interface and overlay is in a security zone, as defined for the Zone Based Firewall
(ZBF)
– Traffic moving between devices in the same zone (that doesn’t transit a different zone in
between) is always permitted
– Traffic moving from one zone into a different one must be explicitly permitted
– All interfaces and overlays are part of zone ‘Default’ unless you change them, so all
traffic will be permitted by default unless you change the configuration
ZBF is covered in depth in the ASD (Advanced SDWAN Deployments) course
and a self-paced course: 304 - Zone Based Firewall
161
161
In the lower right of the bio config is the QoS, Security and Optimization
section. Let’s begin by talking about the FW zone.
If you are using the ZBF feature, you need to set the security zone for each
overlay. By default, all overlays are in the zone called default, but you can put
each one in a different zone if you want. If you want traffic to be able to be
routed by an overlay when you are using ZBF, you need to make sure you
permit traffic from an ingress zone on a LAN or WAN into the egress zone of
an overlay, and also from the overlay zone to a local egress zone associated
with the destination of the packet.

Boost License
– When Boost is enabled:

– Packets that match this BIO will be Boosted (WAN optimized - e.g. TCP
acceleration, compression etc.)
– Assumes there is licensed Boost bandwidth available
▪ It is possible to run out of Boost BW, and if so, traffic throughput can be limited to the available
licensed Boost on the appliance if you’re not careful with how optimization policies are configured
162
162
Below the FW Zone setting is the Boost License field.
If you enable Boost, then all the traffic matching this overlay will be boosted.
You need to make sure that each appliance has enough boost configured to
support the traffic for all the boosted overlays applied to it. Underlicensing
boost may cause overall throughput to be limited. The Designing SDWAN
Networks, or DSN, course goes into detail about how to estimate the amount
of boost required.

Peer Unavailable option
Use XXXX
• Shaped Passthrough Tunnels
• Forwarded out PT interface to
chosen interface next hop
Use INET1 or Use INET2
Use Best Route
Passthrough Interface • Send to the local next hop associated
Shaper with the route in the table having the
best metric/AD.
Use Best Route
• Subnet shared routes are excluded,
D so traffic won’t
r be put in a tunnel.
o
p Note: Peer Unavailable Option affects traffic that Drop
matches the Traffic Match Policy, but for which no
• Not forwarded
destination overlay tunnel is available!
163
The Peer Unavailable determines what should happen to traffic matching an overlay if there is no
route to a destination associated with the overlay. This could be because all the tunnels to other
destinations are down, or because there is simply no route to the destination in the routing table on
the appliance that is associated with a tunnel used by this overlay.
1. It is possible to configure a Passthrough tunnel as a destination, such as Use MPLS1, or USE

INET2. Choosing a passthrough tunnel will result in a packet being sent to the next hop router on
the interface associated with the passthrough tunnel. You should note that all traffic sent from an
overlay will be shaped.
2. The Use Best Route option means when the peer unavailable action is hit, send the packet to
the local next hop associated with the route in the table having the best metric/AD. When the
routing table lookup is done, routes learned via OSPF of BGP will be included, but subnet shared
routes are excluded, so traffic won’t be put in a tunnel. If you are not running a routing protocol on
the appliance, there is a good chance that the packet will be sent to the next hop on wan0 if it is up,
just like earlier versions of code, since the automatically added default route for wan0 will likely
have the best auto generated metric for locally attached interfaces.
3. Drop of course, means discard the packet if there’s no route. If you are connected to a private
network, then Passthrough is probably a viable option. If your site connects directly to the internet
through an unhardened interface, and you are uncomfortable having unencrypted traffic forwarded
onto the internet, then you might want to drop all traffic if it can’t be backhauled to another site.

QoS Settings
• Allows you to choose which
QoS traffic class that packets
that match this BIO will be
placed in
• Allows you to set DSCP
settings for payload (LAN) IPsec Packet WAN LAN Data IPsecPacket
TCP/IP Payload
DSCP DSCP Payload (Original Packet)
and Tunnel (WAN) headers
• All overlay traffic will use
the default global shaper
• Use template groups to
mange Shaper config
164
1. The Traffic Class is part of the QoS configuration for the overlay, and is
used to determine into which shaper traffic class packets routed into this
overlay should be placed. 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.
2. You can also set the DSCP settings here.
3. LAN DSCP sets the bits in the payload packet header.
4. WAN DSCP settings control the bits in the tunnel packet header seen by the
upstream service provider.
The shaper configuration is best managed via template groups that are applied
to appliances from the Orchestrator. QoS, DSCP and shaper configuration are
discussed in more detail in the QoS section of this course.

Application-driven security policies for Breakout
First-packet iQ enables granular Local Internet Breakout (a.k.a. direct to net)
Identify apps and Granular Internet

web domains on Corporate
Breakout NG-Firewall
the first packet
6 5 4 3 2 1
EdgeConnect
Untrusted /
Suspicious Apps
10,000+ Apps | 300 Million+ Web Domains “Home from
Work” Apps
100s of 1000s of IP Addresses
Trusted Business
Apps
Steer Apps Intelligently Improve App Response Time Reduce Backhaul Save Valuable WAN Bandwidth
Granular, intelligent breakout of Avoid added latency through direct Backhaul only untrusted Avoid consumption of expensive
SaaS and trusted internet-bound access to where the app resides traffic to corporate FW MPLS circuits where not necessary
traffic directly from the branch
165
It’s important to understand that in order to do local internet breakout, it’s

necessary to correctly identify the traffic when the end device initiating the
connection first starts the conversation. Silver Peak devices have a data base
of tens of thousands of applications, and millions of addresses and domains
that is dynamically updated nightly, that allows instant identification of most
traffic based on the destination of the first packet. For destinations that are not
in the data base, Silver Peak can snoop the DNS lookup and cache the
results, so that when the connection starts, we’ll know where to send the
packet.

Breakout traffic to Internet & Cloud Services
Drag and Drop Policies
Select interfaces to
–Drag and drop links use for breakout
just like for
backhauled Fabric
traffic
–Set link selection
and usage
methods
–Set Policies and These policies
are active
order to be used Define IP SLA ping destination to make
for breakout sure external sites are reachable
–Automatic internet On by Default!!!

reachability testing.
Must be reachable
Settings for breakout interface Performance
or no breakout Thresholds (Service Level Objectives)
166
The other tab is for configuring Policy Order and internet breakout. While the
User Interface looks a little different, the functionality is basically the same as
in older versions of the business intent overlay config.

Defining What is Internal vs Breakout traffic
–Control which traffic is broken out
– Traffic NOT matching subnets in Internal

Subnets list may be Broken Out Locally
– Consider Non-default routes as internal subnets

• Applies only to LAN_to_WAN traffic
• If you check the box then any learned route that’s not
0.0.0.0/0 will be treated as an “Internal” subnet/host
and be backhauled to the advertising appliance
instead of locally broken out (even though the subnet
is not in this list)
• Avoid checking this on sites that will be doing the
breakout e.g. hubs or data center sites
167
Before configuring Internet breakout, it’s important to enable the orchestrator

to understand which IP subnets or addresses are internal to your network, and
reachable without breaking it out.
1. On the configuration menu in Orchestrator is a selection called internet

traffic. This can also be accesed directly to the right of the 2nd BIO
configuration tab for Breakout Traffic. Upon opening,
2. The internal subnets configuration screen appears. Here is where you
define your internal networks. Since this list might be quite long, it is
possible to upload a list of the subnets and address in bulk. If an address
does NOT appear in this list, then it is one that can be broken out.
Addresses or subnets that are in the list, may be backhauled via an
overlay. This is a global list, by the way. It applies to all appliances.
3. Be careful with the checkbox labeled Consider Non-default routes as
internal subnets. A default route is considered as 0.0.0.0/0, and matches
everything. You would often configure hubs and data center appliances to
advertise a default route so appliances have a path to the internet or a data
center. Checking this box causes any non default routes learned to be
considered internal, so this can affect your internet breakout. For example,
if a data center advertises and address for a device on the internet, traffic
will be backhauled to the data center, but if you check the box, traffic to that
address or subnet might not be broken out to the internet, because the
route would be considered internal, making the site unreachable.

Breakout Service Level Objectives
When to stop using a link and how-to failover
• Waterfall
o Fill up the best link, then start filling the
next best
• Balanced
o Load share connections on a per-flow
(not per-packet) basis
• Use Loss, Latency and Jitter just like for

backhaul
• Choose which
measurements take
precedence
for link ranking
• If checked, browns out links that are

above threshold
168

Overlay List order = Priority Hint: Put BIOS with
most specific matches
at the top, least specific
– Priority column determines the order of matching top→bottom
at bottom
– Top Overlay = highest priority (lowest number) (e.g. Default Overlay)
• E.g. in this example, RealTime policies will have a higher priority (lower
number) than CriticalApps
Click on = and drag to

reorder the Overlays
Click on x to delete an
Overlay
(x only appears when you mouse over)
169
One thing you should be aware of is that the order of the overlays in the list affects their
priority. The appliance will attempt to match the overlay at the top of the list first, then the
2nd and so on. New BIOS automatically go to the bottom of the list, so if you are not paying
attention to the Traffic Access Policies for the overlays, you could end up routing traffic into
the wrong overlay because it was at the top of the list.
You can also take advantage of this fact to limit the traffic to be Boosted, for example. You
could use an ACL to match the traffic you really want to Boost in one overlay and put it at
the top of the list, followed by a second BIO which matches the rest of the traffic and didn’t
have Boost enabled. Traffic entering the appliance which matched the top BIO would be
sent to that overlay network, while traffic that didn’t could match the second overlay in the
list and be sent to the overlay which didn’t use Boost.
It’s important to remember that any new overlays you create will go to the bottom of the list
and have the lowest priority, but you can move them up if needed.
Click on the = sign in the priority column and drag an overlay up or down to change the
order.
To delete an overlay, you can click on the x below the = sign. It’s hard to see here, but
becomes more visible when you hover your mouse over it.

Apply Overlays Tab – For Manual Changes
–Displays which overlays are applied for each machine selected in tree view
–Allows you to Add or Remove overlays for the selected machines by checking
the box next to each overlay in the list and clicking Apply or Remove
170
It’s possible to manually add or remove BIOs from appliances on the Apply
Overlays tab shown here. Simply select the appliances in tree view, and then
check the add or remove boxes for the desired Business Intent Overlays. This
is also a handy place to see which overlays have already been applied to an
appliance.

Route Policies Automatically Created
–BIO configuration causes the Orchestrator to create Route Policies on appliances
• Match Criteria for specified labels/ACLs
• Set Action puts the traffic in the configured overlay and the tunnels associated with it
–Optimization, QoS and Security policies are also created
Interface Label
Overlay names
Auto opt is the default route policy (65535)

171
Route Policies on an appliance controls where traffic goes, and how it gets
there. We haven’t talked about route policies very much so far, but this is what
a route map on an appliance containing two BIO created route policies and the
default route policy of auto optimized looks like.
Each route policy has match criteria like source and destination addresses,
port numbers, DSCP markings etc. It can also use interface labels, as in these
examples, as match criteria. If your BIO used ACLs, there would be an ACL
name in the column near the left side.
Notice that the destination for incoming traffic matched by the BIO created
route policies is the associated overlay network. The comment field on the far
right also tells you which Business intent overlay created the route policy.
It’s important to understand that if a packet doesn’t match any overlays, then it
will match the route policy numbered 65535, called the default route policy.
The configured destination for the packets that match this policy is auto
optimized. This means the appliance will do a route table lookup, and if it has
an entry that matches the destination, then it will put the packet into an
underlay (not overlay!) tunnel to the destination. If there is no match in the
routing table, then the fallback action will be executed, which is similar to the
Peer Unavailable action in an overlay. In this case, passthrough traffic will be
sent to the next hop router on wan0, or dropped, depending on what is
configured.

Review #16: Business Intent Overlays
?
85) What are the three match choices for placing incoming LAN traffic into an overlay?
a) Which is the most used?
86) What are the three Service Level Objective options?
87) How does an overlay treat a SLO parameter set to ‘0’?
88) In the overlay list, which Business Intent Overlay has the highest priority—the top or bottom?
89) You have two Business Intent Overlays, shown in order. If IP phone traffic arrives on the
“Data” port, which BIO is used? :
• All - matches all traffic coming in on the LAN0 port labeled Data
• VOIP - matches IP phone traffic based on an ACL
90) If no overlays are matched, how will the packet be handled?
?
172

:55 w
break
LAB 6 Configuring Business Intent Overlays
LAB 7 Completing Appliance Configuration
LAB 8 Complete Registration of ECV-1 and

ECV-2 in Orchestrator
LAB 9 Configure a Hub and Spoke Business

Intent Overlay

Review #17: BIO and Appliance Configuration Labs
?
91) What are the four default Business Intent Overlays?
92) What is the purpose of a Port Group?
93) Describe how one can view the MAC addresses of the Network Adapters in
ESXi.
94) True/False: It is best practice to use DHCP to assign the IP Address for
mgmt0.
95) True/False: For licensing purposes, the Account Name used is always the
same, but the Account Key is different on each device.
?
174
BIO and Appliance Configuration Labs

What are the four default Business Intent Overlays?
RealTime, CriticalApps, BulkApps, and DefaultOverlay
What is the purpose of a Port Group?
To designate how virtual Network Adapters are connected to
other devices
Describe how one can view the MAC addresses of the Network Adapters in
ESXi:
Look at the settings of each appliance from the Hardware
Configuration section in the VMware ESXi management GUI
True/False: It is best practice to use DHCP to assign the IP Address for
mgmt0:
False
True/False: For licensing purposes, the Account Name used is always the
same, but the Account Key is different on each device:
False

End of Day 1

Review #18: Orchestrator Registration LAB
?
96) Name some things that could prevent the Appliance Discovered button from
showing.
97) Why might the wrong IP Address show up in the Appliances Discovered tab?
98) What should you do if this is the case?
?
177
Name some things that could prevent the Appliance Discovered button from
showing:
Wrong or missing license name or key; Next-hop address not
configured properly for mgmt0; not clicking Save Changes
True/False: Appliances must always be manually approved by an

Administrator:
False. Using Zero Touch Provisioning, there is an option to
“Automatically Approve”
Why might the wrong IP Address shows up in the Appliances Discovered tab?
The Orchestrator may have the previous dynamic IP in its table.
What should you do if this is the case?

Click on the Refresh Discovery Information button

A Hewlett Packard
Enterprise Company
Automated Provisioning and

Configuration
Speeding up Deployment with Automation
In this section we’ll explain how the Zero Touch Provisioning and the Zero
Touch Configuration features can make it easy to configure new appliances,
speed deployment, and reduce the chance of error in your network.

Zero Touch Provisioning (ZTP)
Physical Device Registration
– The Zero Touch Provisioning refers to the fact that the person deploying the device in the branch just plugs it in and turns it on.
– An admin can click to approve the device in Orchestrator.

EdgeConnect 3. Portal looks up SN in its
database and connects to
1. Plug new physical device into Internet associated Orchestrator
(wan0 or wan1 or both) at the branch. 2. HW Device registers itself with Portal known IP.
Device gets IP/DNS via DHCP. Portal gets SN and does a database lookup It provides Orch with IP &
Connects to cloudportal.silver-peak.com Portal puts devices in ‘Pending Approval’ status SN of the new Edge
device.
5. Appliance status = Yes & Approved.
4. Admin Approves Registration in Orchestrator and adds to group.
179
Now let’s take a look at the process by which a physical EdgeConnect

appliance is able to connect to the Orchestrator via Zero Touch Provisioning.
1. First, the appliance must be connected to the network and obtain an IP
address via DHCP.
2. Then the appliance will resolve the name of the Silver Peak Cloud Portal,
and connect to the portal over the WAN. The Portal will learn the hardware
appliances serial number from the device, then do a lookup in its database
to determine which account it is associated with. It will then put the
appliance in to Pending Admin Approval status.
3. Next, the Portal will determine which Orchestrator associated with the
account to connect to and notifies that Orchestrator, providing the
Orchestrator with the Serial number and IP address of the device.
4. Once the Orchestrator learns of a new device, the Appliances Discovered
notification will appear on the top ribbon. Clicking on this notification will
open
5. …the Discovered Appliances tab in the Orchestrator. This will include
buttons to Approve or deny the connection.
6. After the approval process is completed in the Orchestrator, the appliance
status is updated to Approved and this status is propagated to the
appliance via the portal.

EC - New Virtual Device Registration
– Virtual Devices require configuration. Because they don’t have a burned in serial number, they must be provided with the
Account Name and Account Key. SN is assigned to VM by the Portal.

EdgeConnect
3. Portal contacts
2. Virtual Device registers itself with Portal and provides its
1. Configure new virtual device. Orchestrator and
Account Key and Account Name.
Provide Account Name and provides it with the
Orchestrator generates and assigns a serial number to the VM.
Account Key. IP can be configured IP & SN of the new
or use DHCP. device
Portal associates it with an account and Orchestrator
Portal puts devices in ‘pending’ status
5. Appliance status = Yes & Approved.
4. Admin Approves Registration in Orchestrator and adds to

group.
180
A virtual appliance requires some initial configuration before it can connect to

its Orchestrator.
1. First, the appliance has no burned in serial number like a physical device,
so it must be configured with the account key and account name. You can
let the device obtain an IP address via DHCP or configure a permanent
address.
2. When the EdgeConnect device connects to the portal, it provides the
account key and account name information to the Cloud Portal. The Cloud
Portal uses this information to associate the appliance with an account. The
portal then assigns the device a serial number, and changes its registration
status from No to Pending Administrator Approval as shown here.
3. Next, the Portal will determine which Orchestrator associated with the
account to connect to and notifies that Orchestrator, providing the
Orchestrator with the Serial number and IP address of the device.
4. Once the Orchestrator learns of a new device, the Appliances Discovered
notification will appear on the top ribbon. Clicking on this notification will
open
5. …the Discovered Appliances tab in the Orchestrator. This will include
buttons to Approve or deny the connection. If Approved, the operator will be
given the option of selecting the appliance group to add the device to.
6. After the approval process is completed in the Orchestrator, the appliance
status is updated to Approved and this status is propagated to the
appliance via the portal.

Preconfiguration of appliances
ZTC: Zero Touch Configuration
–Allows you to create preconfiguration files that include most common
• IP addresses, routing protocols, Overlays to be applied etc.
–It’s possible to set up auto approval & config (no human required)
–Can work with ZTP or with VMs (using a manually configured tag)
–Uses YAML files stored on the Orchestrator for each appliance
I’m He’s
New! New! Config
Cloud Portal
EdgeConnect Orchestrator
YAML
181
Where ZTP, or zero touch provisioning, refers to way a physical appliance is

able to automatically register with the cloud portal, and the Orchestrator, ZTC,
or Zero Touch Configuration refers to the ability to automatically configure
those newly registering devices.
This is done with configuration files that are stored on the Orchestrator in
advance of a new device registration. These preconfiguration files can be used
with physical or virtual devices.
1. The files use the YAML markup language, which makes them easy to read
and edit. When a new device registers, it is matched to a preconfig YAML
file, and the configuration is applied to the appliance. This will be discussed
in more detail later in the course.

Appliance Preconfiguration Requires
Done from the Orchestrator 8.5.6+
–Preconfiguration allows you to skip

the wizard
–Uses YAML
• Yet Another Markup Language –
or
• YAML Ain't Markup Language
• Industry Standard
–New files are auto populated with
help and samples of all config
parameters for you to edit
–It is also possible to clone an existing
file, edit it, and save it with a new
name
–Copy and paste is supported
• Use your favorite text or code
editor
182
The appliance preconfiguration feature allows you to specify most of the

configuration parameters you need in an easy to edit text file. The files use
YAML for markup. YAML originally stood for Yet Another Markup Language,
but its proponents now say it stands for YAML Ain’t Markup Language, which is
somewhat recursive if you think about it. The preconfig is done only from
Orchestrator, not on an appliance, since the file contains both Orchestrator
and Appliance configuration parameters.
1. When you click the ‘new’ button on the preconfiguration tab in Orchestrator,
a new, complete sample YAML file is opened for you to edit, and save.
2. If you have an existing file that’s already has most of what you need for a
new site, you can clone it, make edits, and save it with a new name.
3. Files are easy to edit inline, but copy and paste are supported, so you can
also use your favorite text or code editor.

Built in Help
–A new blank preconfig file has field
descriptions built in
–Gives you section by section help -
describes:
• Valid values
• Optional or Required
• Defaults
183
When you click the New button to create a new preconfig file, all the help is
built in to the file and shown in green as you see here. There is a help section
for each section of the preconfig file. VRRP is shown here.
Each parameter in the YAML file is described in detail, and tells you whether
the field is required or optional, the valid values, and the default value.

Appliance Preconfiguration & ZTC*
* Zero Touch Configuration
Unique Name for this file
ECV-4 Config
Allows auto configuration
if Discovery Criteria is a
match
Serial Number is for

ECV-4_spoke
Physical Appliances
Tag is for Virtual

Appliances
184
For each preconfig file, you need to specify a name for the file. Use a name
that helps you match it to its intended use.
1. The auto approve when discovered option, allows you to configure an
incoming appliance that matches the file without any manual intervention.
This is the feature that allows ZTC or Zero Touch Configuration for physical
appliances.
2. The Orchestrator will attempt to match a new appliance to a preconfig file
using it’s serial number, in the case of physical appliances. For virtual
appliances, which have no serial number initially, a tag can be configured
on the appliance to match the file.
3. Here you can see a sample of the setup wizard on a virtual appliance, and
how the tag is entered just below the account name and account key.
Although you wouldn’t usually need to run the wizard on a physical
appliance you were preconfiguring, if you did, you wouldn’t need the tag,
and the serial number of the physical device would match the preconfig file.

Editing an Appliance Preconfiguration File
– Structure and indenting is # = Comment (green)
important. Follow the sample
– Usually ok to leave unused Code is blue or black.
fields blank Overwrite sample data fields
or delete as needed.
• Delete sample data in fields if
needed
Use spaces to indent,
• Check the help in comments to not tabs
see what’s allowed. Edit or delete data, but
not labels
– You can delete whole
sections of file if unneeded
Validate button checks
• E.g. BGP, OSPF etc. your edits, and tells you
where the error is
– Validate will tell you if you
deleted something you
shouldn’t
185
When you are editing a preconfiguration file that uses YAML, as with most
markup languages, syntax, formatting and indenting are important.
Any statement in the file that is preceded by a pound sign, is considered a

comment, colored green, and is ignored by the Orchestrator. In a new file, all
the pre-existing comments contain information on every configuration
parameter in that section, and all the allowed values.
1. Below the comments, you can see the code is shown in black and blue.
Generally the tags are blue, and the data is black. You can edit the sample
values for the existing data, or add values where values are blank. You can
also delete unused data as long as it is not a required value. The
comments will tell you if empty is a permissible value. You can also delete
some entire sections if you are not using a feature. Examples of sections
you can delete would be BGP or OSPF.
2. Use spaces for your indenting. Tabs are not allowed. When you are
finished editing
3. Click the Validate button to check your formatting and data. If an error is
found, the validation will fail, and you will be given a line number or referred
to a section to correct your error. If everything is ok, you will be shown a
message showing the Preconfiguration is valid against a green
background, like the example shown here on the lower right.

Preconfiguration Serial or Tag Matches!
– Approving a new appliance that

matches tag or serial automatically
launches the preconfig dialog (if auto
approve is off)
– Click apply to run script
– You have the ability to opt out, or

choose a different YAML file by
clicking on the Name
186
As we mentioned before, when a new appliance connects to Orchestrator, an

attempt is made to match it to preconfig file based on
1. The serial number for physical appliances, or
2. The tag for virtual appliances.
3. When you click the approve button, The preconfiguration dialog screen will
launch, showing you which preconfig file was a match, and what the match
criteria was.
4. At this point, all you need to do is click the apply preconfiguration button to
complete the setup of the appliance.
5. You do have the ability to opt out and run the manual setup wizard if you’d
like, or you can choose a different YAML file if needed by clicking on the
Name, and selecting a different file from the list of those available.

Applying Preconfig File Status
–Looks similar to the final
apply from the manual
config wizard
–But…
• No typing
• No manual addressing
• No checkboxes etc.
• It’s all in the YAML file
187
As each step of the process runs, you’ll get an indication of success. When all
of the steps have completed, just close the dialog, and go to your dashboard
or topology diagram to check the progress of things like tunnel building as the
device is integrated into the network. That’s all there is to it.

YAML works with Templates and Bios
–YAML files do not contain all

–PreConfig files are meant to work
together with Template Groups and
Business Intent Overlays
188
We should point out that YAML preconfiguration files do not contain every
possible configuration parameter, nor are they meant to. The YAML files work
together with the Template Groups and the BIO configuration to cover all the
configuration requirements for an appliance.
The YAML files contain site specific information needed for IP addressing,
routing protocols and more, in addition to some global network configuration
parameters. Many of the other configuration items are already covered by
Template Groups and Business Intent Overlays configured on the
Orchestrator, so make sure you have set those up prior to applying your
preconfiguration file. As you can see here, the YAML file includes specifying
which overlays and template groups are to be applied to the appliances.

Review #19: Automated Provisioning and Deployment
?
99) What matches a physical device with a preconfiguration file?
100) What matches a virtual appliance with a preconfig YAML file?
101) True/False: A preconfig file cannot assign IP addresses to interfaces because

they are different at every site.
102) True/False: Appliances must always be manually approved by an

Administrator?
103) True/False: The network architect and/or administrator needs to commit to

using the Preconfiguration file because there is no way to avoid it once the
appliance has been discovered by the Orchestrator.
?
189
1. What matches a physical device with a preconfiguration file?

• The burned in serial number
2. What matches a virtual appliance with a preconfig YAML file?

• The tag configured on the appliance license page
3. True/False: A preconfig file cannot assign IP addresses to interfaces because they are different at
every site.
• False – You can have a different YAML file for every appliance and IP addresses for
every interface can be included.
4. True/False: The network architect and/or administrator needs to commit to using the Preconfiguration
file because there is no way to avoid it once the appliance has been discovered by the Orchestrator.
Fales. There is an option to opt out, or choose a different YAML file in the Apply
Appliance Preconfiguration screen
1) True/False: It’s possible to completely install a virtual appliance without a human to configure or
approve it.
• False – You at least have to configure the account name and account key
2) True/False: It’s possible to completely install a physical appliance without a human to configure
or approve it.
• True – a physical device can register with the cloud portal using its burned in serial
number, and ZTP and ZTC can automate registration and configuration.

LAB NOTE: MAC Address Mapping IN Vmware
190
When installing EdgeConnect virtual appliances you will need to correctly map
the virtual machine’s MAC addresses to the correct appliance port. The
network diagram shows mgmt0 needs to be connected to the “Management”
network, lan0 to network 2, wan0 to network 3, and wan1 network 4. Note:
Network means a switch.
<Click>In VMware, you expand the network adapters and find out which MAC
addresses are on which network.
<Click>Next, document these in your LAB guide and assign the appropriate
MAC address to the appropriate appliance port when you run the
Configuration Wizard on the appliance.
In this example, lan0 is on network 2. <Click>Adapter 2 is on network 2, so

<click> that MAC address needs to be assigned on lan0.
<Click>So you will assign all required appliance interfaces to MAC addresses
on the proper networks.

1:10
LAB 10 Complete ECV-3 Installation and

Apply CampusNetwork Overlay
LAB 11 Zero-Touch-Configuration (ZTC) of ECV-4
LAB 12 Complete Registration of ECV-4 in

Orchestrator

A Hewlett Packard
Enterprise Company
Virtual Router Redundancy

Protocol (VRRP)
In this next section, we will look at VRRP.

What is VRRP?
– Defined by IETF RFC 5798
– Redundant Gateway functionality
▪ Layer 2 protocol provides for automatic assignment of available IP routers to participating hosts
– Operates within a single subnet
▪ Not a routing protocol
193
VRRP provides information on the state of a router, not the routes processed
and exchanged by that router. Each VRRP instance is limited, in scope, to a
single subnet. It does not advertise IP routes beyond that subnet or affect
the routing table in any way. VRRP can be used in Ethernet, MPLS and token
ring networks with Internet Protocol Version 4 (IPv4), as well as IPv6.

Virtual Router Redundancy Protocol (VRRP)
Review
10.10.10.253
10.10.10.254
Devices in 10.10.10.0/24 X
A
MASTER
Subnet
LAN vIP = 10.10.10.254
vMAC = WAN
00-00-5E-00-01-XX
Default GW=
10.10.10.254 GA
B
10.10.10.252
1
194
9
4
Let’s quickly review what VRRP does.
End devices, like those on the left of our diagram have a default Gateway to which
they forward IP packets with destinations outside of the local subnet. In our example
all of the end devices are in the 10.10.10.0 subnet, and have a default GW of
10.10.10.254.
1. But what happens if the default GW goes down? Even though there is a
redundant router in our diagram, the end devices will either have to be
reconfigured for a different default GW, or learn the new default GW via a different
mechanism, resulting in down time while the network reconverges. VRRP, or
Virtual Router Redundancy Protocol, is a way for end devices to have a singe
default GW address that never goes down because it’s virtual.
2. In the diagram now, the two routers share a virtual IP address and virtual MAC
address represented by the shaded router in the center. Only one of the routers is
processing traffic addressed to the virtual IP at any one time, however, and this
device
3. is called the Master.
4. The Master sends IP multicast advertisements to the backup router, to let the
backup know it is up and running.
5. If the Master goes down, the backup will fail to receive advertisements, a timer will
pop,
6. and it will become the Master. The new Master will
7. send a gratuitious ARP so the switch will know to forward traffic addressed to the
virtual IP address out the correct port to the new Master.

VRRP Use Cases
–Deterministic LAN side path selection avoids asymmetry
LAN WAN 0
LAN 0
VRRP HA
Link Edge HA
L2 Switch
LAN
0
WAN 1 • Useful with EdgeHA or Traditional HA
• Run VRRP on the LAN side
A • LAN side routers/switches point to VIP
LAN
VRRP Traditional HA
L2 Switch
B
L2 or L3
Devices
195
VRRP is especially useful in cases where there are no other LAN side routers
and you want fast failover, so it is often used when we have an EdgeHA cluster
at a branch office as shown in the top example.
VRRP can also be used with traditional HA as shown in the bottom example.
Since traditional HA is usually found in large branches or data centers, where
there are usually LAN side routers, a routing protocol like BGP is often used to
attract traffic instead.

Out-of-Path: VRRP
One Silver Peak
Devices in 10.10.10.0
Subnet Priority 100
10.10.10.251
LAN
WAN
vIP = 10.10.10.254
vMAC =
Default GW=
X
00-00-5E-00-01-XX
10.10.10.254
Preempt =
YES
MASTER
10.10.10.252
Priority 255
1
196
9
6
Silver Peak also supports the VRRP protocol, and can be the Master. In this
case, the devices forward traffic to the Silver Peak to be optimized when it is
the master.
1. If it goes down, then the router becomes the master and the traffic will be
forwarded across the WAN unoptimized while the appliance is down.
2. Devices have a configurable VRRP Priority.
3. Preemption mode is also configurable. It’s important to make sure that the
Silver Peak has the higher priority, and that preemption is allowed, so that
4. when the Silver peak comes back up,
5. It can resume the role of Master, and start optimizing traffic again. If
preemption is off, then the router will continue to be the master until it is
rebooted.

VRRP – Redundant Silver Peaks
End Devices direct their own traffic to VIP
X MASTER
Backup
LAN
vIP = 10.10.10.254
vMAC =
00-00-5E-00-01-XX 10.10.10.253
Devices in 10.10.10.0/24
Subnet WAN
Default GW=
10.10.10.254
B Preempt
= NO
1
197
9
7
One very useful application of VRRP is to have two Silver Peak appliances
sharing a virtual IP. In our case, Silver Peak A and Silver Peak B are sharing
the default GW address, and Silver Peak A is the master.
1. If it goes down, then
2. Silver Peak B will become the master, and optimization can continue
uninterrupted.
3. In this case, you probably want to disable preemption.
4. When Silver Peak A comes back up, it will automatically go into backup
mode, and be ready to become the master if Silver Peak B were to ever go
down.

Out-of-Path: VRRP – Hybrid Approach
Redundant Appliances
Devices in 10.10.11.0/24
Subnet
WAN
LAN
10.10.11.254
10.10.10.1
Default GW=
10.10.11.254 PBR redirects traffic to
vIP =
VIP 10.10.10.254
End devices and

VRRP VIP in different
subnets
198
We’ve stated previously that the end devices are usually in the same subnet
with the VRRP peers. Configuring the VRRP VIP as the default next-hop
address minimized device reconfiguration, but here’s another way to
accomplish the same thing. In this example:
1. The end devices and the redundant Silver Peaks, and the VIP they are
using are in different subnets. The end devices still point to the local router
as the default next-hop. How will traffic be optimized?
2. You can use PBR to redirect traffic to the virtual IP address of the VRRP
group. This has the advantage of not requiring a reconfiguration of the
router’s interface on the LAN-side. If there are a pair of redundant devices
as shown here, you can get high availability in an active/backup
configuration and use an SLA to monitor the VIP to make sure at least one
of the Silver Peaks is able to optimize traffic. You can configure the Silver
Peaks, and after everything is ready, apply PBR to the LAN interface on the
router, and the WAN interface if you’re not using subnet sharing.
Note that it doesn’t really make sense to do this if you only have one Silver
Peak out of path on it’s own subnet because you don’t get high availability for
optimization. If you only have a single Silver Peak out of path you are better off
just doing PBR without VRRP.

Configuring Appliance VRRP from Orchestrator
–Configuration → VRRP
• Required
o Group ID
–Click edit icon o Interface
o VIP
• Optional but important

o Preemption
199
In order to configure VRRP on the appliance, go to the VRRP configuration

page and click on Add VRRP. That will bring up this dialog. You must configure
a group ID, select the correct interface if there is more than one, and configure
the virtual IP used by the group. By default the appliance will preempt, but
remember that you may want to disable this if you are using redundant Silver
Peaks.

LAB 13 VRRP Configuration

Quality of SERVICE
(QoS)

Quality of Service
– Two Pieces to QoS
– Determination of Maximum Bandwidth in Deployment Profiles
– Traffic Class Management
– Traffic Shaper
– DSCP Markings
202

Two Pieces to QoS
– QoS Policy – Shaper
▪ Determines which traffic class a –Determines the behavior of individual
packet is placed in traffic classes, priorities and limits
▪ Determines the DSCP settings
▻ Tunnel header for encapsulated
traffic
▻ Payload packet header
203
There are two pieces to Silver Peak QoS: the QoS policies and the Shaper
QoS policies determine which traffic class each packet will be placed in, and
also 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, their priorities
and limits.

Max Bandwidth
–Limits appliance throughput and shaper bandwidth allocation
LAN
WAN
wan0
mgmt0
Set Max WAN BW to the sum of the
WAN interfaces on the router
(assumes we get 100% of link BW for tunnel
traffic)
204
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 pipe that size.
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 won’t be able to fill your pipes
and some links may be underutilized. If you set it too high, you may overrun
the appliance WAN links, or cause congestion and drops on the WAN-side
routers.

Deployment Profile
–Total Inbound and

Total Outbound
determine system
bandwidth to be used
by QoS 4,000
4,000
4,000
4,000
4,000
8,000
4,000
4,000
4,000
8,000
205
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.

Traffic Class Management in the Shaper
Traffic class configuration determines how likely packets are to get WAN
bandwidth at any given point in time
–Traffic Class behaviors are Max BW / Total Outbound

defined in the Shaper
• There are up to 10 classes
• Classes are prioritized
o Higher priorities (lower
number) get bandwidth first
–Make sure sensitive traffic like
VOIP gets put in a high priority
traffic class with a low Max Wait
Time
Sum of Traffic class Mins
shouldn’t exceed 100% of
Max Bandwidth
206
206
Now we’ll look at the shaper configuration. Remember the QoS policies determines which shaper traffic
class packets entering a Silver Peak appliance are placed in for processing and transmission across the
WAN. 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 really only has 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. By default, all
traffic will go to traffic class one.
1. Max Bandwidth comes from the deployment profile as we discussed on the previous slides.
2. 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 real-
time, which has a priority of 1. The second highest priority of 2 is for traffic class 3 which is labled
interactive. The default traffic class, traffic class 1 is next in line to receive bandwidth with a priority
of 5.
3. 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.
4. 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 BW in that time slice.
5. Max Bandwidth for each traffic class is next, and is generally always left at 100% of max system
bandwidth.
6. 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.
7. 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.
8. Finally, it’s important to remember this rule: In order to avoid starving any traffic class, the sum of
the Min Bandwidth %s for traffic classes being used, shouldn’t exceed 100% of Max Bandwidth. So
for example, if you are using 3 traffic classes, you could give 33% to two of them and 34% to the
other. If the sum of your mins exceeds 100%, when the appliance becomes congested, then the
lowest priority classes might get starved.

Shaper operation summary
–Basic Rules
• In priority order, give all classes their guarantee (Min Bandwidth)
• Still data in any class AND available bandwidth? → Use weighted round-robin
(Excess Weighting)
–Notes:
• Stop when you run out of bandwidth (Max WAN Bandwidth)
• No class can exceed its Max Bandwidth
• No flow can exceed the Rate Limit for its traffic class
• Drop any packets that have been in the class queue too long (Max Wait Time)
207
We’re 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 BW for the traffic classes. This is optional. In the
current versions of code, you can take the defaults of all zeros if you want.
Second, set the ratios of the weights, which you’ll recall are used to allocate
any remaining bandwidth after all the minimum bandwidths have been
satisfied. 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 used to allocate
BW.
Of course, the configured max 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, if any packets exceed their max wait time
(Spend 1 minute on this slide. The goal is to get them to the next slides to go
into the details.)

Shaper Examples
–Example: Default…Only Weights 100 M
0M
0M Weighted round robin
0M
100 M 50 M
1000 M 50 M
Common to
represent Weights
as percentages
100% Utilized
208
IN this example,
1. The max bw is for the appliance is 100 Mbps and only two of the traffic
classes have packets queued up. Replication has 100 Meg, and guest
wireless has about a gig queued up.
2. Current defaults are used, so This is the way it would look with a fresh
install starting in late 8.1 code. All the priorities are set to one, and all the
mins are set to 0. This means that only excess weights will be used to
allocate BW.
3. Note that weights for all the 5 traffic classes in use here – 1 through 5 - add
up to 100, making it easy to think of the weights as percentages if there is
traffic in all classes
4. However, in this example, the only two traffic classes with data in them are
replication and guest wireless, with equal weights of 10. As a result, these
queues will be serviced, as always using weighted round robin, and
because the weights are equal,
5. Both classes will end up sending 50M of data in this time slice, at which
point
6. We have used 100% of max BW.

Excess Weighting means:
Shaper Examples Realtime sends 1000:1 till it runs out (15 M)
Replication 1:1000 (15k) then (49.85 M)
Example 2: Custom Example 100 M
0M
15 M 40 M 25 M 15M
0M
0M 10 M 1 15k then 49.85M
990 M1000 M
Total Sent: 35 M
100% Utilized
Leftover: 65 M
209
Let’s look at an example where we are using priority and minimum bandwidth
to allocate BW to the different traffic classes. You an see here we are still
using a max BW of 100Meg for the appliance.
We have traffic queued up for the Realtime and replication traffic classes.
Realtime has 40Meg queued up and Replication has 1 Gig of traffic ready to
transmit.
Because Realtime has the highest priority with a value of 1,

1. We will satisfy it’s minimum BW, and transmit 25 Meg of the traffic,
2. leaving 15 Meg in the queue
3. Next we’ll satisfy the minimum for the replication queue with a priority of 9,
and transmit its min of 10Meg,
4. Leaving 990 Meg in the queue.
5. That means we’ve transmitted a total of 35 meg in this time slice so far and
we have 65 Meg of BW left, so we’ll use
6. The ratio of excess weights to allocate the remaining 65 meg of BW.
7. Realtime will get 1000 times more chances to transmit over Replication so
it sends all of its remaining 15 meg while Replication only sends a measly
15k.
8. Then the replication queue, which has been getting 1/1000th of the BW, will
get a chance at the rest of the BW in this time slice and transmit its
remaining 49.85 M since it's the only one sending data now.
9. This accounts for a total of 100Meg, and we have utilized 100% of the BW
in this time slice.

Traffic Class Minimums Must be Set Carefully
– Two sites with 10 Mbps
tunnels
• TC mins are all set to 1 Mbps mgmt0
• Weights control the excess

– Now we add a new smaller LAN WAN
10 Mbps
site with a 1 Mbps link mgmt0 mgmt0
mgmt0
Fix: Set all Min BWs to ‘0’ and Any single TC min could fill the
use Excess Weights to allocate 1 Mbps tunnel, starving out
BW the same in all tunnels other traffic
210
When setting traffic class minimums, care must be taken. In the next couple of
slides, we’ll examine the relationship between traffic class minimum
bandwidths, and excess weighting.
In this example there are two sites, each with a 10 Mbps link, and the tunnels
to each of those sites has full use of the bandwidth. We configure traffic class
minimums for 1 Mbps for each class in use, so even if we 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.
1. Now imagine we add a new site with a 1 Mbps link. Since the minimum BW
for each TC is 1 Mbps, equal to the full BW of the new tunnel, this means
that assuming that there is sufficient traffic queued,
2. any one of the traffic classes, starting with the one having the highest
priority, would be able to completely fill the pipe and starve out lower
priority classes.
3. The solution to this is to set the priorities for all traffic classes to 1, and the
minimum BWs for each traffic class to zero. Because all the mins – at 0 –
are always satisfied, only the ratio of excess weighting will be used to
allocate BW. It turns out when you do this, each of the traffic classes gets
an amount of BW in each tunnel that’s also proportional to the weights.
This keeps one traffic class from starving out the others.

DSCP – Trust / Trust
IPsec_UDP
211
Here’s an example of how DSCP settings work in QoS policy.

In this diagram, and the ones that follow in this section, on the left, is the transmitting
device and the markings of the packet it is sending, proceeding to the right from there,
the Silver Peak appliance is next, along with its DSCP configuration labeled DSCP
markings. To the right of that is a representation of how the packet appears on the
WAN. Notice there are two DSP markings. This is because the packet on the WAN is
encapsulated in a Silver Peak tunnel. The inner packet, or payload, can have a
different marking than that outer header used by the encapsulation. The outer header
is the one seen by other devices on the WAN, such as a service provider’s routers, or
routers on your intranet. These routers don’t see the inner payload packet or its
markings. To the right of that is the Silver Peak destination appliance that terminates
the tunnel, and which will strip off the outer header, and transmit the payload packet
to the end device on the right, preserving the marking of the payload. No change in
DSCP markings is made by Silver Peak devices to packets coming in from the WAN
and destined to the local LAN.
•On the left we see a packet come in from the LAN.
•The appliance is configured for QoS to trust-lan on the LAN-side, and also trust-lan
on the WANside (remember we have incoming and outgoing processing for DSCP
markings in our QoS configuration).
•The appliance puts the packet in the tunnel.
•The inner packet is unchanged because the LAN policy is trust-lan.
•The outer header of the tunnel also carries the same marking because the WAN
policy is trust-lan also. The outer packet header will be seen by devices in the cloud,
like the service providers routers, and they’ll process it based on their own local
policies for DSCP markings.
•When the packet arrives at the remote end, the tunnel header is stripped off, and the
packet is processed based on the DSCP configuration of the devices at the remote
site.

DSCP – ef / BE
IPsec_UDP
212
Here’s another example of how DSCP settings work in QoS policy.

•The appliance is configured for QoS to mark packets as EF on the LAN-side,
and to trust-lan on the WAN-side.
•The inner packet is changed to EF because the LAN policy is EF.
•The outer header of the tunnel is marked as BE because the WAN policy is
trust-lan
•When the packet arrives at the remote end, the tunnel header is stripped off,
and the packet is processed based on the DSCP configuration of the devices
at the remote site.

DSCP – Trust / cs5
IPsec_UDP
213
Here’s another example of how DSCP settings work in QoS policy.

•The appliance is configured for QoS to trust-lan the LAN-side, and to set
DSCP markings to CS5 the WANside.
•The inner packet is kept as BE.
•The outer header of the tunnel is marked as CS5 because the WAN policy is
set to CS5.
•When the packet arrives at the remote end, the tunnel header is stripped off,
and the packet is processed based on the DSCP configuration of the devices
at the remote site.

High Level Data Flow: Tunnelized Traffic
Shaper Config determines the
QoS Policy determines which behavior of a traffic class
traffic class a packet goes to
Security Policies applied
at egress
214
This slide shows a high level data flow of how the different types of policies are
applied. Remember that these policies may be created by the 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 in.
Optimization policies then define the Boost features to be applied.
Bandwidth is allocated according to the shaper configuration, and when

bandwidth is available to transmit the packet, it is sent to the output interface
and placed in the appropriate tunnel.
It should be noted that security policies are applied last, when the egress zone
is fully determined

Review #20: Quality of Service
?
104) What determines which traffic class a packet is placed in?
105) What determines the behavior of individual traffic classes
106) In order to avoid starving any traffic class, the sum of __________ shouldn’t
exceed ________?
107) True/False: The Shaper ID column defines the order in which classes are
serviced.
108) How can you use weights only (ignore priority and min BW) to allocate traffic
in all tunnels equally (assuming traffic mix to all sites is the same)?
?
215

A Hewlett Packard
Enterprise Company
Backup, Restore, Image

Management
In this lesson, we’ll take a quick look at backup, restore and appliance image
management

Back-Up –Appliance and Orchestrator configurations
can be backed up using the Orchestrator
• Appliance configurations are backed up to the
Orchestrator database
o Can also be backed up to a file and downloaded/restored
• Orchestrator configuration and database are backed
up to another server
–Back-ups can be scheduled to occur on a

regular basis
• Orchestrator will back up all appliances when it
backs itself up.
• New appliance backups are taken if there are
saved changes.
217
The Orchestrator allows you to manage the backup and restore of both the
Orchestrator database, and appliance configurations.
Appliances configurations are backed up to the Orchestrator database. All of

the backups are labeled and time-stamped.
The Orchestrator configuration and database containing the appliance configs

etc., is backed up to another server via FTP or SCP. New appliance backups
are taken when the Orchestrator backup runs, if an appliance has saved
changes that have not been backed up previously.

Orchestrator Backup and Restore
–Orchestrator database is
backed up.
–Orchestrator automatic
backup is part of the Getting
Started Wizard
–Restore is done manually
from the CLI
• see Release Notes
218
As you’ve probably seen, configuring regular backups is part of the

Orchestrator installation wizard.
Restoring the Orchestrator database is manual from the UI. Procedures for
manual recovery can be found in the Orchestrator release notes.

Orchestrator Restore (sample)
A. Copy the Orchestrator backup file from your back up server to the Orchestrator
server and put it in /home/gms directory and name it gms.zip
B. Once the file is loaded, execute the following steps:
login as root
1.
2. Refer to the Release Notes!
Stop the orchestrator service: $service gms stop
3.
4.
Procedure may vary by
Logout as root
login as admin
5. Initiate the restore:
version
$/home/gms/gms/setup/restore.sh 2>&1 | tee /tmp/restorelog
6. logout as admin
7. login as root
C. Restart the orchestrator service: $service gms start
219
Here is what the Orchestrator procedure looks like to restore from a backup in
current versions of software. You must do this from the command line via SSH
or the console. The procedure here is copied from the release notes.

Appliance Restore
–Appliance configurations can be

restored via the Orchestrator
• Restores are performed per appliance
• Only relevant configurations are
displayed
–Can also restore from file
You can only restore

one appliance’s
config at a time
220
An appliance restore is easily done from the Orchestrator GUI. When you start
a restore on an appliance, only the relevant backups from the selected
appliance are displayed for you to pick from.
Although you can perform backups from multiple appliances simultaneously,

you can only restore a single appliance at a time. Just select the backup image
that you want, and click start.

Performing an RMA with the RMA Wizard
RMA Wizard: Support → [Technical Assistance] → RMA
1. When replacement appliance is discovered…
2. Run the RMA wizard (select old machine in tree view first)
3. Use old machine’s backup to restore new replacement machine
221
When you RMA an appliance, a wizard is available to automate the process for
you.
You need to install the new replacement appliance onto the network. When it is
discovered by the Orchestrator, you can select the machine to be replaced in
tree view, and then run the RMA wizard, which is available on the Support tab.
The wizard will walk you through the replacement process. You will be
prompted to select a previous backup from the failed machine to use as a
starting image for the new machine.

A Hewlett Packard
Enterprise Company
Monitoring Your Network
In this lesson, we’ll talk about some of the tools available to monitor the
operation of your network.

Health Map
Monitoring→Health Map
– Hourly graphic view of state of Loss, Latency, Jitter & Alarms per appliance
– Adjustable thresholds for color coding
– Click on any box for relevant info
Each box is 1
hour
223
Part of the Orchestrator dashboard we looked at earlier, is the Health map that
displays color coded hourly status for each selected appliance.
Clicking on any of the hourly status blocks will show the status for that
appliance with any alerts related to it.

Network View on Appliance
At a Glance:
• Bandwidth Usage
• Top Applications
• Latency
• Loss
• Top flows
Selectable View Options
• Traffic Type
• Direction
• Time Period
• Tunnel
224
The appliances have their own charting built in. The home page for an
appliance is the Network View, shown here. At a glance you can see
Bandwidth Usage, Top Applications, Latency, Loss and Top Flows. Various
filters allow you to select the type of traffic, direction, time period and which
tunnel Latency and Loss are plotted for. This is an extremely valuable
summary of the current state of the network from the perspective of the
individual appliance. Be aware that loss and latency are charted per tunnel, so
make sure you have selected the desired tunnel from the dropdown menu to
the right of those charts.

TRAFFIC DIRECTIONALITY: Inbound vs. Outbound
OUTBOUND LAN OUTBOUND OUTBOUND WAN
LAN-SIDE DATA IN BYTES WAN-SIDE DATA IN BYTES *

OVER TIME INTERVAL OVER TIME INTERVAL
INBOUND LAN INBOUND WAN

LAN WAN
LAN-SIDE DATA IN BYTES WAN-SIDE DATA IN BYTES *
OVER TIME INTERVAL OVER TIME INTERVAL
INBOUND
Inbound LAN Bytes 19,093 bytes (19k)

Inbound WAN Bytes 27,193 bytes (27k)
Outbound LAN Bytes 5,235,944 bytes (5.2M)
Outbound WAN Bytes 376,608 bytes (377k)
225
On many Silver Peak pages, including the flow table, you will see the terms
inbound and outbound. These refer to the direction the traffic is flowing with
regard to the site. Inbound traffic comes from the WAN. Outbound traffic is
flowing to the WAN.
Keep in mind, that unlike a traditional switch or router, a silver peak appliance
has a very defined sense of LAN and WAN, and inbound and outbound. To
review, when we are talking about traffic direction in the flow table, Inbound
and outbound are referred to with respect to the site where the local appliance
is. This is true for
1. LAN traffic, shown in the light blue bars in the flow table and
2. WAN traffic, shown in the dark blue bars.
3. Outbound light blue LAN traffic is shown as a longer bar than the dark blue
WAN traffic because the lan traffic leaving the site is being compressed
and deduplicated.
4. Similarly, on the inbound side, the light blue bar is longer because inbound
WAN traffic is being uncompressed and repopulated to its original size.
5. The Reduction percent column on each side gives a percentage
comparison of the inbound and outbound data streams in the flow to give
you a quantified result related to the relative lengths of the light and blue
bars.

Flow Monitoring
–Current Flows can be
viewed in real time
–Flows can be reported on

for a single or multiple
appliances
–Click on the Flow Chart

icon to see a real time
graph
–Click on the Detail icon to
see more info (see Current Flows:
upcoming slide) Your Best Friend!!!
226
Flow monitoring is your best friend for helping to diagnose network problems
that are happening at the current time.
You can view flows for one or more appliances simultaneously from the
Orchestrator using data that the Orchestrator is pulling from the appliances in
real-time.
Clicking on the flow chart icon for a given flow, will produce a flow bandwidth
chart for that flow immediately, so you can see how it is operating from
moment to moment. If you can’t find the column, use the Customize button to
add it.
In the detail column, is an icon you can click on to bring up detailed information
about each flow. We’ll examine flow details in depth in an upcoming slide.

Review: Flow Details NAT Information tab
Flow Statistics
Flow addressing, What optimization is

endpoints etc. applied to the flow
QoS Information
Zone Based
Firewall info
227
As we mentioned earlier, the flow table is your best friend, and the flow detail report
contains critical information that will help you with diagnosing problems.
In the upper left of the flow detail are the flow statistics that provide detailed numeric
information associated with the flow,
1. In the upper center is route information for the flow. This section will show you
information about the properties of the, including which entry in which route map a
flow matched. Remember route maps determine the destination of a flow. If your
flow isn’t going to the correct destination, then this section will help you diagnose
why.
2. In the upper right, the Optimization section can tell you which Silver Peak
technologies are being applied to a flow. Remember Optimization policies
determine which technologies are applied to a given flow, and this section will
show you which policy in which optimization map was matched for the flow, which
technologies are turned on for that policy, like TCP acceleration, and whether the
appliance was able to apply them for this flow.
3. In the lower right is the QoS section. In this section, you can see which QoS policy
caused the flow to be placed in the traffic class into which it has been put. If your
traffic isn’t being prioritized properly and has been subject to drops or delays, this
is where you might want to look to understand why.
4. In the lower left, you can see how zone based firewall security policies have been
applied to this flow. In this case, the flow was dropped because the security policy
did not allow traffic between the ingress and egress zones.
5. Finally, You should also notice that there are tabs across the top. The NAT tab will
show you any NATing applied to the flow if this is internet breakout traffic, for
example.

BANDWIDTH (NORMAL) 3 lines:
Ratio indicates BW savings
BW Usage Reduction Ratio

axis axis
228
The bandwidth tab shows you the amount of bandwidth used over time by
selected appliances. The chart shows you three lines that are common on
many Silver Peak grqphs, LAN, WAN and Ratio.
The LAN line shows you bandwidth consumption on the LAN using the scale
on the left of the graph. The WAN line shows the same thing for the WAN,
while the Ratio, shows you the relative sizes of the two using the scale on the
right. This ratio is expressed as a multiplier. This is useful for determining the
amount of compression and deduplication you are getting from the Silver
Peak. For example, on the outgoing side of a flow, the one that data is being
transferred from, you would expect that the amount of data on the WAN should
be significantly lower than the incoming data on the LAN. In the opposite
direction, you would expect the LAN number for uncompressed and
reconstructed packets would be higher than the size of the incoming data
stream on the WAN. In this example, you can see peaks where the reduction
ration is nearly 20x, or 20:1.

Which applications are using the Bandwidth?
Bars implicitly
display ratios
229
Built in reports can show you which applications are using bandwidth in your
network. The ratio of dark to light bars on the inbound and outbound side also
give you an implicit feeling for the amount of data reduction you are getting.
This is also spelled out as a percentage on either side of the bars.

LOSS
Actual Loss Effective Loss
FEC Enabled
230
The Loss tab can show you the amount of packet loss you are experiencing on
a link as reported by the receiving end, and how successful FEC is at
correcting the loss.
1. The light blue line shows you the actual packet loss on the link for received
packets.
2. The dark blue line shows you the effective loss, in other words, the
remaining loss after FEC is applied.
3. In the example above, you an see that FEC was enabled at a point in time
indicated by the callout and after that, effective loss drops to zero as FEC
corrects for the lost data. The light blue line after that point shows there is
still actual loss in the link, but the dark blue line goes to zero, showing that
100% of the loss is being corrected for.

Charts (Appliance)
– Charts cover:
▻ Bandwidth utilization
▻ Data reduction
▻ Packet loss
▻ Out of order packets
▻ Latency
▻ Flow volume
▻ Packets per Second
– Selectable time period up to

30 days
– Zoomable by selecting region
on chart or timeline
231
Charts also available on the appliances for a number of different functions

shown in this list. The charting can be done for stored data covering up to the
last 30 days, and you can zoom in on interesting time persiods or peaks by
selecting the data on the top chart, or the timeline below it. The chart will
automatically fill with the data from the selected period of time.

Realtime Charts (Appliance)
– Realtime Charts update graphs in
three second intervals
– All charts offer some form of
filtering
– Many types of Stats and metrics (3
WAN rate
examples shown) &
Compression
Ratio
QoS
Stats,
TCs 2 & 3
232
Realtime Charts start collecting data as soon as you click on the Plot button.
Multiple charts can be running at once. Just select a new type of data and
Metric,. The charts are updated in 3 second intervals. We can see examples of
different charts here, with WAN rate and Compression Ratio on the top, and
Graphs of QoS traffic class statistics for outbound WAN traffic in traffic classes
2 and 3 on the bottom.

Appliance charting from Orchestrator
–Initiated from Orchestrator: Support→[Reporting] Appliance Charts
–Many Realtime and Historical options
233
It is also possible to display a number of realtime appliance charts directly from

the Orchsestrator. Here we are charting realtime bandwidth usage by two
interfaces and two overlays for an appliance. Many more choices are available
from the menu on the left.

Overlay traffic distribution
Dashboard
–Many more monitoring features than shown here.

–Look around when logged into Orchestrator.
234
Built in PIE charts in Orchestrator can show you the distribution of traffic
through the different overlays. Many more charts are available than we have
time to go into in this course. You should explore next time you are logged into
an Orchestrator.

Configuring Reports - Orchestrator
–Define custom reports on

Reports tab
• Name the report
• Select which charts to include
• Select the targets
• Define the email recipients
–To run the report, go to Report
tab
• Select the report name
• Either schedule it to run later, or
just click Run Report Now
235
Here we see an example of the Reports tab on the Orchestrator. The

Orchestrator can be configured to generated custom reports that run at a
scheduled time daily, weekly, or on demand. The granularity of the created
charts, and the range of time covered by each type of report is selectable. By
checking the appropriate box, you enable or omit the types of charts generated
for applications, tunnels or Appliances. By selecting the appliances in tree
view, and then clicking on the Use Tree Selection button, you can tell the
Orchestrator which devices to include in the report. You can create multiple
reports with different data views, and save them with different names and
reporting schedules. Each report can be mailed to one or more recipients at
the scheduled time.

For more TRAINING on monitoring…
– http://training.silver-peak.com
236
A self-paced Silver Peak course, Managing SDWAN Networks, will give you
additional experience in using the different monitoring tools to identify and
troubleshoot problems in your network. Additionally, an instructor-led and self-
paced Troubleshooting Course covers these tools and more.

Review #21: Reporting and Monitoring
?
109) What 3 lines commonly appear on most Silver Peak statistical graphs?
110) What are the Line colors for those lines? LAN: ________ WAN: ________ Ratio: __________
111) Why is the Ratio usually useful?
112) On an appliance, what single page shows Bandwidth Usage, Top Applications, Latency, Loss and
Top flows?
113) Where should you check first when troubleshooting a problem happening ‘now’?
114) How can you tell if a flow is being optimized?
115) What will tell you which QoS Policy rule caused a flow to end up in a particular shaper traffic class?
116) What are the 5 main sections of a Flow Detail?
117) Where can you find information about any NAT applied to a flow?
?
237
Reporting
1. What 3 lines commonly appear on most Silver Peak statistical graphs?
• LAN, WAN, Ratio
2. What are the Lin colors for those lines?

• LAN – Light Blue, WAN – Dark Blue, Ratio - Green
3. Why is the Ratio usually useful?

• It gives you a comparison as a multiplier, e.g. 20x reduction
4. On an appliance, what single page shows Bandwidth Usage, Top Applications, Latency, Loss and Top flows?
• Network View on an appliance
Flows
4. Where should you check first when troubleshooting a problem happening ‘now’?
• Current flows - your best friend.
5. How can you tell if a flow is being optimized?

• Look at the flow detail. Also remember there are filter buttons in 8.0 that will display Asymmetric flows only, and
you can search for various things.
6. What will tell you which Optimization Policy rule matched to cause a flow to end up in a particular shaper traffic class?
• The QoS section of the flow detail.
7. What are the 5 main sections of a Flow Detail?

• Stats, Routing, Optimization, Security and QoS.
8. Where can you find information about any NAT applied to a flow?
• On the NAT tab of the flow detail.

Logging
Now we will look at some of the logging features supported by the

Orchestrator and appliances.

Logging Overview: Orchestrator
Several types of logging:
–Orchestrator specific:
• Audit logs
• Orchestrator Debug
239
On the Orchestrator Audit logs and a number of different debug logs are
available to help you find problems in your network.

Logging Overview
–Appliance specific (more to come):
• Event Logging – records system events and “level”
• Alarm/Alert Logging – records only events at Alert level or higher
• Audit Logging – records user directed actions performed on the appliance
• Node
240
On the Appliance, Event Logs record system events and the level of the
corresponding event.
The Alarm/Alert logs display events at Alert level or higher.
Audit logs record who did what, for example, which user made a config change
at what time. We’ll look at those in greater detail in a moment.

Alarm Alerting
–Alert emails are configured via the Alarms tab
–Orchestrator and Appliance alarms can go to different users/distribution lists
241
It is possible to have email sent to yourself or others when ever an alarm is

generated. You can control the severity level of the alarms that are sent to
email so that you are not bothered by low level problems.

Netflow / IPFIX
– NetFlow provides a way to send flow records
to a centralized collector from the appliances
– NetFlow data is sent directly from the
appliances, not via Orchestrator
– Configured on the Orchestrator as a
Template
– We now support IPFIX in the new releases
– Reports against two virtual interfaces:
▪ sp_lan: LAN traffic on all interfaces + VLANs
▪ sp_wan: WAN traffic on all interfaces + VLANS
WAN export shows flows inside the tunnel

(LAN traffic flows, not the encapsulated WAN packets)
242
Appliances support NetFlow & IPFIX reporting. They send statistics directly to
one or more collectors, not the Orchestrator, although you do configure them
via the Orchestrator using a template, shown here.
You may notice on the collectors, that there is reporting is done against two
virtual interfaces, sp_lan and sp_wan. Traffic flowing through all the actual
LAN interfaces is reported against sp_lan. All traffic flowing through the actual
WAN interfaces is reported against sp_wan, and it is worth noting that the
WAN export does not report on the tunnel packets themselves, it reports on
the flows that are going through the tunnel. In other words, the packets that
are destined for the tunnel prior to encapsulation and transmission across the
WAN.

Syslog
– Appliance events sent directly to a logging server(s) – not via the Orchestrator
– Syslog is set up as a Template called “Logging” in a Template
– Define:
▪ Level of logging Appliance
▪ File rotation policy
▪ Syslog servers
Orchestrator
IP, URL,
or FQDN
243
Syslog records are sent directly to a Syslog server, and appliance syslogs are
not routed through the Orchestrator. Appliance Syslog configuration can be
done in a Orchestrator template group and applied to multiple devices at once
in a consistent manner. You can see here that the logging configuration is quite
straightforward and easy to understand.

Appliance Audit Log
When it was done Who did it What was done
Local user, the rest

are Orchestrator
244
Here’s an example of the Appliance audit log. Notice you can see
1. the time stamp on the event,
2. the userid that performed the action,
3. a short summary of the action, the target of the action, and some high level
detail about the action.
4. Notice in the column that displays the user who took the action and their IP
address, you can distinguish between locally logged in users, and the
Orchestrator. The Orchestrator entries have a /GMS after them, and the
directly logged in users have only their user id and IP address.
Notice that all the users here are ‘admin’. This is a good reason that the
recommended practice is to give everyone their own login, and not use the
admin login id. If everyone is using admin, then you won’t be able to tell
who did what, and know who to question when a change or action
disrupted the network.

A Hewlett Packard
Enterprise Company
Troubleshooting
In this section we’ll talk about features of the Silver Peak website, and on the
devices, that can help when you have a question, or are facing a difficulty in
your network.

Getting Help from Support
• Trobleshooting

How to Get Help
– Engage TAC when you need help
• Customer Portal: Log in, create a case
• For urgent cases, email or phone (see
next slide)
– In advance of speaking with
someone
• Identify the problem links or devices
• Capture the messages files
• Generate the tech support files (can take
a while)
• Generate the debug-dump files
247
We highly recommend you get a login for the support site. This will give you
access to several tools you can use, including opening cases with the Silver
Peak TAC, or technical assistance center. For urgent cases where you have a
network down, or appliance down, you shouldn’t hesitate to call support
directly.
In order to help support quickly find a solution to your problem, we recommend

you gather data regarding your problem prior to initiating contact. That way
they can get started immediately on the receipt of the information.

Contact Support
Contact info for support is built into

the UI under the Support Tab, Also
link to login to portal and open a
case, upload files etc.
248
To contact support, on the appliances, you can click on Technical Support

under the Support tab. This will give you information related to the appliance
that support will want, and also give you the contact phone numbers and email
address for TAC.

Gathering Support Information - Appliance
Support→Debug Files
Generate a Show Tech and a

Sys Dump for support before
opening a case.
249
Also available is the ability to generate a sysdump or Show Tech information.

Support will usually want the Show Tech information which includes things like
the appliance configuration, software version etc. which can lead to a solution
to your issue more quickly.

Gathering Support Information - Orchestrator
Tech Support tab
Upload files to support
250
In the Orchestrator under the Tech Support tab, is the ability to directly upload
files to support. Some of the files can be quite large, and exceed the allowable
size for email, so this can be a very useful way to get information to support
personnel for troubleshooting.

Documentation (No Login Required)
http://www.silver-peak.com/support/user-documentation
–Manuals
–Quickstart Guides
–Tech Tips
–System
Requirements
–MIBs
–etc…
251
To begin with, you should always consult the Silver Peak documentation. The
product manuals, Quickstart Guides, Tech Tips, System Requirements and
Mibs and much more is all available online without a login.
For network design and deployment questions, the Silver Peak Network
Deployment Guide is a particularly useful ‘how-to’ manual that gives examples,
complete with router configurations of different kinds of implementations,
including PBR, BGP, VRRP, EdgeHA and more.

Diagnostic Tools
Silver Peak provides a number of tools to help you with troubleshooting. We’ll
look at several of them in this lesson.

Ping and Traceroute
– Will source from mgmt0 interface and use
default route
– Must use options to specify appliance
source interface and use data IP address
to local devices
– Ping
▪ ping –I <src addr> <dest addr>
or
▪ ping –I <interface> <dest addr>
– Traceroute
▪ traceroute –s <source_address>
or
▪ traceroute -i <interface>
253
Silver Peak has number of built in tools to aid you in troubleshooting.
Ping and traceroute are available under the maintenance menu on the
appliances as shown in this diagram.
1. By default the appliance will send pings sourced from the mgmt0 IP
address so be sure to run ping with the –I option to test connectivity
between the data path IP addresses.
2. It should be noted the –I option can take either the source address of an
interface or the interface name as arguments. If you choose the source
address, a route table lookup is done, and the ping will exit through the
interface associated with the next hop of the chosen route. If you chose the
interface name, then the ping will exit that interface and used the source
address of the interface you specified as an argument.
3. If you are doing traceroute, the Options are not the same as with ping. ‘-i’
(lower case) is used to specify an interface. ‘-s’ also lower case is used to
specify a source IP address.
-I <source addr> (e.g. –I 192.168.1.4)

routing table lookup is done, ping will exit on interface going to next hop to
destination w/ source addr
-I <interface> (e.g. –I lan0)

ping will exit lan0 interface with source address of lan0

Tools Come Built-In
Iperf
–Use for testing max
throughput, jitter, latency
–Execute from the
Orchestrator
• Select two appliances
• Select Link Integrity Test from the
Maintenance menu
–Can be executed easily
from the Appliance CLI
(must be set up on each
end)
–Do not unintentionally send
it through the tunnel!
• Orchestrator automatically sends Will use all BW on the link. Run in maintenance window!!!
PT or PTU
254
Iperf, a standard performance testing tool, is available to run from the

command line of the appliances in addition to the Orchestrator GUI. Just select
two appliances in tree view, set the parameters and click Start. In addition to
verifying connectivity, it will tell you the actual available bandwidth, latency and
jitter on the link.
1. Be aware that this is performance impacting for production traffic. You
should only run it when you have a maintenance window, and send the
traffic outside the tunnel. If you run the test from the Orchestrator, the traffic
will automatically sent as pass-through or pass-through unshaped.

Built in packet capture 7.1+ –Built in packet capture
–Limit number of packets
–Filter on IP or Port
–Standard pcap files
• Download from appliance (not
through Orchestrator)
–Read with Wireshark etc.
255
Under the maintenance menu on the appliance is a Packet Capture option.

You can set the number of packets to be captured, and filter on IP address and
port number. Capture files are in standard pcap format and are compressed
and dowloadable. Uncompress the files and you can read them with free tools
like WireShark.

What does my appliance
support?
CLI command: show system capabilities
– E.g. how many tunnels are supported

or how much bandwidth etc.
– Capabilities may vary by model,

available resources (VM RAM, disk etc.)
and software version
256
Sometimes, especially with virtual appliances, you may wonder what is

supported by the device with the available resources. The show system
capabilities command will give you easily understood output that tells you
things like how many tunnels are supported and the maximum supported
bandwidth of the appliance.

Review #22: Built in Diagnosis Tools
?
118) What option is required to make sure a Ping is sourced from the correct
interface or IP address when testing reachability?
119) What options can be used to make sure a traceroute is sourced from the
correct IP address or interface when testing reachability?
120) How do you display the options available for running the ping and traceroute
commands from the UI?
121) True/False: Iperf is always safe to run on a production network.
122) What tools can be used to read traffic capture done on an appliance?
?
257
1. What option is required to make sure a Ping is sourced from the correct
interface or IP address when testing reachability?
• ‘-I’ upper case
2. What options can be used to make sure a traceroute is sourced from the
correct IP address or interface when testing reachability?
• ‘-s’ or ‘i’ lower case.
3. How do you display the options available for running the ping and
traceroute commands from the UI?
• Question mark help
4. True/False: Iperf is always safe to run on a production network.

• False – it will use all the BW on the network
5. What tools can be used to read traffic capture done on an appliance?

• Any tools that can read a standard PCAP file, like WireShark.

30
LAB 14 Basic Flow Monitoring
LAB 15 Reporting
LAB 16 Troubleshooting Tools

Data Flow Summary
• Troubleshooting
In this section we’ll review asymmetry, how to distinguish a healthy flow from
an asymmetric one, and some techniques to troubleshoot and correct
problems.

Data Flow Summary
• Do a Lookup in the
routing table
• Traffic Match • Depends on
Preferred Policy • Check Security
Match the Policies of the Is it Internal Policy Allows
1st Packet What kind of BIOs Order – and Transmit to
traffic is this? traffic to an or Internet • Backhaul, • \Use Logical
ID • Usually ACLS Destination Overlay Tunnels
Overlay • Sorted by Priority,
Traffic Breakout or
Service Chain consisting of one
Top to bottom or more Underlay
Tunnels
260
Now that we’ve covered business intent overlay configuration, let’s examine the data flow
through an appliance at a high level.
To begin with, when traffic enters an appliance, the first packet in a flow is examined using
Silver Peak’s data base of millions of domains, IP addresses and applications. This is critical,
because when the connection to the destination is being established, the packet needs to be
sent through the proper path and matched to the correct overlay.
1. Once the traffic has been ID’d then the appliance will match the traffic to an overlay using
the traffic access policy set for each overlay. This is usually done with ACLs, but could
also be done with LAN interface labels.
2. Once the traffic is matched to an overlay, a determination needs to made as to whether the
traffic will be backhauled through an IPsec tunnel to a Silver Peak at a different site,
broken out locally direct to the internet, or sent through a secure tunnel to an external
service like Zscaler on the internet. This will depend on the what is defined as internal vs.
internet traffic as well as the configuration of the overlay that is matched.
3. Once the destination has been determined, the appliance will transport the traffic to its
destination using the transports that you configured for the overlay or internet breakout. If
the traffic is going into a tunnel, it will have boost processing performed if that is configured
for the overlay, and placed in a QoS traffic class to be transmitted with the proper priority,
and the correct DSCP markings. We’ll discuss QoS in more detail in a different section of
this course. When the packet is transmitted, the appliance will dynamically choose which
one of the underlay transport tunnels that carry traffic for this business intent overlay will
carry it to the destination.
4. If there is no path to the destination, either because there is no entry in the appliances
routing or subnet table, or all the underlay tunnels to the destination are down, then Peer
Unavailable action configured for this overlay will be executed. This might be to put the
packet as passthrough via the 1st available local WAN interface, or in a passthrough
tunnel to be routed by an upstream router outside of a tunnel on a particular interface, or
dropped. Dropping the packet is often the best choice if you don’t want unencrypted traffic
going onto the internet to an unknown destination.
5. That’s a summary of how traffic is handled as it moves through an appliance. More
detailed explanations of traffic handling are part of the ASD, or Advanced SDWAN
Deployments course.

Summary: Once the traffic matches an overlay…
1. Main Routes table is used to make path selection
▪ Traffic is placed in a tunnel to a destination from which a subnet is learned
▪ …Or broken out to the internet
2. If there is no route, in the Routes table, the Peer Unavailable Action or Fallback
action will be used
▪ Dropped
▪ Use Best Path: Traffic is sent to the next hop router on wan0
▪ Passthrough tunnel: Traffic is sent to the next hop associated with the PT tunnel wan interface
261
Now let’s summarize the summary.
Remember, once the traffic is matched to an overlay, the main routing table, or
subnet table is used to make a path selection. Traffic will be placed in tunnels
to the destination from which a destination subnet was learned. If you are
using internet breakout for that overlay, then traffic will be broken out
according to your policy configuration.
If there is no route in the routes table, then the Peer Unavailable action will be
executed and the packet will be sent through a passthrough tunnel to a next
hop router, sent passthrough to the next hop on the first WAN interface that is
up, or dropped.

Review #23: Business Intent Overlay Path Selection
?
123) A packet matches a Business Intent Overlay. There's a Routes (subnet) table
match with a destination that is part of the overlay. Is the first packet (SYN) sent
through a tunnel or not?
124) Same scenario as above, but there is no match in Routes table?
125) True/False: Once the traffic is matched to an overlay, a determination needs to
made as to if it will:
a. will be backhauled through an IPsec tunnel to a non-Silver-Peak device.
b. broken out locally direct to the internet.
c. sent through a secure tunnel to an external service like Zscaler.
126) True/False: The above depends on the what is defined as internal vs. internet
traffic as well as the configuration of the overlay that is matched.
?
262

Boost and Asymmetry
• Troubleshooting
In this section we’ll review asymmetry, how to distinguish a healthy flow from
an asymmetric one, and some techniques to troubleshoot and correct
problems.

Healthy flows… Inbound means Outbound means
-Traffic is bidirectional FROM the WAN TO the WAN
Site B
Site A
Silver TUNNEL
Silver
Peak A Peak B
Router A Router B
Host A
Server B
264
If everything is configured properly, all TCP flows will show both Inbound and
Outbound traffic.
1. Remember Inbound means FROM the WAN, and
2. OUTBOUND means Toward the WAN.
Inbound and outbound are not really referenced to traffic on a given interface,
but rather to the direction traffic takes entering or leaving the site.
In this example we see a large CIFS flow between 192.168.1.122 and

192.168.3.13. Since we’re looking at the Site B’s Current Flows, Outbound in
this context is telling us that we have transferred 1.8 gigabytes to a host in Site
A and have seen a reduction rate of 59% on this traffic.
The inbound side of the CIFS flows show s a relatively small

amount of traffic – only 6.1 mega bytes. We can tell by looking at these stats
that the host in Site B is serving up files to the host in Site A because there is
very little traffic Inbound from Site A but a great deal of traffic outbound to Site
A from Site B.
Once you become familiar with Silver Peak’s approach to traffic reporting you’ll
find the information invaluable for solving problems that often aren’t even
related to WAN optimization.

What is TCP Asymmetry?
Asymmetric flows cannot be proxied.

No proxy, no Boost fromTCP acceleration.
Site B
Site A
Silver TUNNEL
Silver
Peak A Peak B
TCP SYN
Router A Router B TCP SYN ACK
Host A
Server B
265
You’ll remember that we have spoken about why with TCP acceleration, the
Silver Peaks on each end of the connection need to see both ends of the three
way handshake when devices initiate a session. Here’s a more detailed
example of one way that asymmetry can be introduced in the network.
ON the left at Site A, you see a device, Host A that is going to access the
server on the right. It starts the application and it begins the connection
sequence to the server.
1. First the device Host A sends a SYN to the server on the right. Notice that it
takes a path through Silver Peak A, on the upper branch of the network on
the right. The device on the right in Site B answers, and because of the
way the local routing and switching is set up,
2. the SYN ACK takes the return path through the lower branch on the right,
bypassing the Silver Peak, and going directly through Router B on the right.
In this case, neither Silver Peak sees both sides of the conversation, so the
flow is completely asymmetric. In this example it’s caused by the underlying
routing and switching mechanisms in the network.
3. Remember Asymmetric flows cannot be proxied, because you can’t see the
sequence numbers in both direction. If the appliance can’t proxy, then it
can’t provide the TCP acceleration component of Boost, which means
network latency will cause a decrease in performance.

Asymmetric flows…
- Diagnosis: Routing Problem
Site B
Site A Default gateway set to Router B
rather than Silver Peak B
Silver Silver
TUNNEL
Peak A Peak B
Router A Router B
Host A
Server B
266
One definite indication of asymmetry is a flow that shows inbound or outbound

bytes incrementing, but ZERO bytes in the opposite direction. This suggest the
flow is only going through the appliance in one direction, and bypassing it in
the other.
1. Traffic from Host A is traversing the Silver Peak appliances, but when we
look at the flows
2. You can see in the flow table on Silver Peak B that bytes are only
incrementing in the inbound direction, but stay at zero in the outbound
direction.
3. This is because the flow from Server B to Host A is bypassing Silver Peak
B.
4. At this point we can make some educated guesses as to the problem. If we
are using host-based forwarding, Server B, is not using the Silver Peak as
its default gateway. There might also be routers and switches we’re not
aware of at Site B, and traffic isn’t being directed to the Silver Peak
because of underlying routing or switching issues.

Diagnosis: Redirection Misconfiguration
Site B
Site A
Silver Silver
TUNNEL
Peak A Peak B
Host A Router A Router B

Router B’s PBR access-list Server B
does not contain Host A
subnet
267
As you can see here, the flow tables on both device reflect asymmetric flows. They
have ZERO bytes in one direction.
1. When packets leave Site A they are properly redirected to the Silver Peak and
across the tunnel to Site B.
2. On the return path The flow bypasses the Silver Peaks resulting in the asymmetric
route you see here. In this example since we have no stateful packet filter traffic
will continue to flow but will only be optimized in one direction.
3. In this example Router B’s ACL is missing the destination subnet at Site A, so
there is no match for the destination in one direction, and the traffic is not
redirected to Silver Peak B by router B. When you deploy out of path, redirection
is just one more thing to configure, and break when it’s done incorrectly.

Stateful Firewall Issue
Fix: add a route

policy to make the
server traffic
Passthrough
Site A Firewall doesn’t see returning Site B

SYN/ACK because it’s in the tunnel
Silver Silver
Peak A SYN/ACK
Peak B
TUNNEL
SYN
ACK
Host A Firewall A Firewall B Server B
Firewall drops ACK packet
due to out-of-state Even without firewalls, 192.168.3.13
this will be asymmetric
268
When we add stateful firewalls to the picture, you don’t just have slow asymmetric
connections, you have flows that are completely broken.
1. Here you can see host A trying to connect to Server B. The Syn for the flow is
sent passthrough to Site B, bypassing the tunnel and gets to Server B. It has
passed through both firewalls, which have permitted and cached the flow state.
2. When the SynAck returns from Server B, it Silver Peak B puts it in the tunnel to
Site A. At this point the flow is asymmetric, but things are still trying to connect.
Note that since the SynAck is encapsulated, the Firewalls can’t see it in the return
direction.
3. Then the final Ack in the 3 way handshake gets sent from Host A, to complete the
three-way TCP handshake. At this point Firewall A will detect that something is
amiss. Having not seen the SYN/ACK coming back from Server B the firewall will
drop the ACK from Host A and prevent the TCP session from starting.
4. By the way, although the connection might come up without stateful firewalls in
the path, the flow will still be asymmetric, and therefore can’t be accelerated.
5. Our example here shows that the user has created a route policy in the Site A
Silver Peak that will match on any traffic destined for 192.168.3.13. The Set
Action column for this rule is configured with “pass-through-unshaped”. The pass-
through-unshaped setting causes the Silver Peak to send the traffic to the next
hop outside the tunnel.
6. The silver Peak at site B has a route policy that matches everything and puts it in
the tunnel to site A.
7. To fix this problem, simply add a Route Policy to Silver Peak B that will pass-
through any traffic with a source of Server B and a destination of ANY, just like on
Silver Peak A on the left. This way the firewalls will see both sides of the
conversation.

Asymmetry can Also Cause THE Zone Based Firewall To Deny
Traffic
– Traffic using ZBF should transit the same zones in both directions
– Traffic that returns in a different zone will be dropped
Overlay Tunnel
Zone Untrust
Zone Untrust
269
This behavior may change in a future release, but that’s the way it works in
8.1/8.2

Flow Redirection It’s better to have deterministic traffic flow
and avoid the need for flow redirection.
Use with redundant appliances (e.g. at a
data center) where asymmetry is unavoidable
–Resolves issues where flows pass through
two different appliances
–Process
• First appliance to see the flow is the Owner
• Owner shares it’s flow table with peers
• If Non-owner sees the responses, the flow is
redirected to the Owner Flow
mgmt1
Flow Redirection
mgmt1
Table
–Interfaces
A B
• Can use any interface; mgmt1 is common
• Typically uses fast network or crossover cable
SYN/ACK
270
Remember that Silver Peaks at each end of the network need to see both
sides of the conversation, but because appliances are often being integrated
into existing network designs, it’s not always possible to avoid asymmetry
when you have redundant appliances – at a data center where traffic is being
redirected for example. Since symmetric flow is essential for tcp acceleration
to work properly, flow redirection can help remedy this.
Flow redirection is a technology that can be used between two or more Silver
Peak appliances to correct for asymmetric routing.
1. When the Silver Peak on the left sees the SYN incoming, it becomes the
owner of the flow and tells the Silver Peak on the right that it owns the flow
by sending a flow table update.
2. When the SynAck is received by the Silver Peak on the right, it can forward
the flow to the owner, and preserve symmetry for the flow so it can be TCP
accelerated.
3. It’s better to create a network design that implements deterministic routing
and avoids asymmetry altogether, however.

Boost Caveat:
If
– An optimization policy matches all traffic
And
– Boost license is less than Max WAN BW
Then
– Overall throughput will be limited to Boost
amount, not Max WAN BW
Solution: Create policies that only
Boost desired traffic, or
apply more Boost
271
One thing you need to be aware of is the fact that you can potentially limit the
maximum throughput of an appliance to the licensed Boost bandwidth when it
is less than the Total Outbound. For example, let’s say you have Boost
enabled for all your overlays. Let’s say also, that you have a total outbound set
to 2Mbps, but you only have 1Mbps of Boost licensing. Since all traffic is
Boosted, you will never be able to exceed the licensed Boost BW for this
appliance, so you will be limited to 1Mbps, even though the appliance is
enabled for 2Mbps of throughput. The solution could be either to add additional
Boost bandwidth licensing, or to exclude some of the traffic from Boost with an
additional overlay.

Review #24: Boost and Asymmetry
?
127) What is TCP asymmetry?
128) What is a good indicator of asymmetry?
129) What are some causes of TCP asymmetry?
130) What are some possible solutions?
131) True/False: You should always prefer flow redirection over deterministic
design that avoids asymmetry.
?
272
1. What is TCP asymmetry?

• A flow doesn’t traverse both of the same pair of appliances.
2. What is a good indicator of asymmetry?

• Flow byte counts will be zero in one direction
3. What are some causes of TCP asymmetry?

• Misconfigured routing in the network. Misconfigured route policies.
Misconfigured firewalls.
4. What are some possible solutions?

• Flow redirection
5. True/False: You should always prefer flow redirection over deterministic

design that avoids asymmetry.
• False - fix underlying routing problems if possible.

The Flow Detail
• Your Best Friend

Review: Flow Details NAT Information tab
Flow Statistics
Which route
policy was What optimization is
matched? applied to the flow
QoS Information
Zone Based
Firewall info
274
As we mentioned earlier, the flow table is your best friend, and the flow detail
report contains critical information that will help you with diagnosing problems.
In the upper left of the flow detail are the flow statistics that provide detailed
numeric information associated with the flow,
1. In the upper center is route information

2. In the upper right, the Optimization section can tell you which Silver Peak
technologies are being applied to a flow.
3. In the lower right is the QoS section.
4. In the lower left, you can see how zone based firewall security policies
have been applied to this flow.
5. Finally, You should also notice that there are tabs across the top. For
example, the NAT tab will show you any NATing applied to the flow.

Flow Detail Stateful+SNAT
NAT info for each flow is shown in the flow detail
–Do any configured policies or upstream firewall rules

account for NATing done by appliance?
–Routers?
NAT can occur on

WAN interfaces and
EdgeHA links
275
Here is a screen shot of the NAT section of a flow detail. Across the top, you
and see the orginal IP address and port numbers. On the body of the tab, you
can see the external IP addresses and port numbers that were used when the
packet address translation was applied. It’s critical to understand this for
troubleshooting.
1. You should note that address and port translation can occur on WAN
interfaces and across EdgeHA links. So if a flow is traversing an HA link prior
to internet breakout, it could get double NAT’d.

Look At the Flow: Security
– Outbound Bytes = 0
– Click on Flow Detail
– Hitting Default Overlay
– Security = Deny
▪ Ingress zone is ‘Users’
▪ Egress zone is ‘default’ Check the security labels and policies for Zone Based Firewall!
276
The flows table is your best friend when troubleshooting. Always go there first.
Here we are using the Orchestrator, to look at the flow on ECV-2, and see that
the flow is being put in the outbound tunnel to ECV-1 using the default overlay.
Notice that outbound bytes on the flow, however, is at zero. What could be
happening.
1. Click on the flow detail icon to learn more about what’s transpiring.
2. In the security section of the flow detail, we can see the action taken is
deny.
3. YOu can see that this flow hit the default overlay.
4. We can also see that while the ingress zone is Users, and The egress zone
is default.
5. A key piece of information here is that the flow was dropped because of
implicit policy. Implicit policy means that unless explicitly permitted, traffic
between different zones is denied and will be dropped. Since the traffic hit
the default overlay, you should remember Overlays are also considered
part of the zone architecture.
6. You need to look at your security policies in this case to make sure that
traffic is permitted between Users and default zones, or that something isn’t
mislabeled. Perhaps the overlay is in the default zone and should not be in
this case.

Review #25: Flow Detail
?
132) What is your best friend when troubleshooting a connection between two
endpoints that transits an appliance?
133) How do you display the Flow Detail?
134) What are the 5 main sections of the Flow Detail?
135) What section will tell you if an overlay or the default route policy was
matched?
136) How can you see the external (upstream) source address of an outbound
flow when the interface is set to Stateful+SNAT?
137) A user is complaining that they are unable to establish a connection to a
server at a different site. How you can tell if a Zone Based Firewall security
policy is permitting or denying the connection?
?
277
1. What is your best friend when troubleshooting a connection between two

endpoints that transits an appliance?
• The flow table
2. How do you display the Flow Detail?

• Click on the detail icon for that flow in the flow table
3. What are the 5 main sections of the Flow Detail?

• Statistics, Routing, Optimization, QoS and Security
4. What section will tell you if an overlay or the default route policy was matched?
• The Routing section
5. How can you see the external (upstream) source address of an outbound flow
when the interface is set to Stateful+SNAT?
• The NAT tab in the detail
6. A user is complaining that they are unable to establish a connection to a server

at a different site. How you can tell if a Zone Based Firewall security policy is
permitting or denying the connection?
• Look at the security section of the flow detail

Overlays and Tunnel
Orchestration
• Troubleshooting
In this lesson, we’ll look at some troubleshooting advice for overlay and tunnel
orchestration.

Overlay Manager
– Runs every 5 minutes, or when the network, or an overlay configuration changes
– Does not apply configuration to appliances that are unreachable, or out of sync
– Constantly working to keep configuration intact
– Will also run in certain configurations on Appliance change
• If you delete a tunnel
• Tunnel went down Make sure the appliances
• Policies are reachable and sync’d.
• Deployment Check the Topology tab.
– What does it do?

• Synchronizes all appliances – checks first
• Builds Tunnels
• Applies Other Configuration
279
The overlay manager is responsible for building and maintaining the tunnel
connections between the appliances, and propagating configuration updates.
The Overlay Manager is resident on the Orchestrator and runs every 5

minutes in the background, or whenever a change in the network or
configuration is detected. The Overlay manager works constantly to correct
any unexpected conditions.
Obviously, if an appliance becomes unreachable, or falls out of

synchronization, the overlay manager will not be able make any changes on
the device.

Tunnel formation
What would keep a tunnel from coming up?
–Labels
• Interface labels set properly?
–Overlays
• Correct interface labels selected in overlay
for Primary & Backup transports?
–IP routing
• Next Hop Reachable?
• Upstream Routers know routes?
• NAT Upstream?
o NAT flag set properly? Overlay Tunnel
280
If a tunnel is not being built, think of the things that will keep it from coming up.
1. Are the interface labels set properly? If not Orchstrator won’t be able to
properly identify the endpoints of the tunnels.
2. Have you checked the correct boxes on the BIO for the primary and
backup interfaces. If not, no tunnels will be built.
3. As always, general IP routing issues can keep tunnels from being built
1. If the next hop is unreachable you will get an alarm, but what about
the hops beyond that?
2. Is there NAT being preformed by an upstream router or firewall? If
so and you don’t have the NAT flag set properly, then a tunnel can’t
be built

IPSEC_udp tunnels
– Firewall must permit tunnel formation LAN
WAN 0
– Holes for IPsec ports? LAN 0
WAN 1
▪ UDP 120xx L2 Switch
▪ Usually just 12000-01
▪ Might be more with HA
– From your web browser do a search for ‘ports used by Silver Peak appliances’ on
the Silver Peak website
▪ Ok to do this from the student PC in your LAB or from your home/office.
281
Don’t forget to permit traffic for the domains, addresses and ports used by the
appliances to create connections. Misconfigured firewalls are a primary cause
of connectivity issues.
If you want a complete list of all the ports and protocols used by silver peak
appliances, a document is available on the Silver Peak website. Just search
for ports used by Silver Peak appliances

HA links and tunnels
– Does the LAN switch or hypervisor Vswitch config permit VLAN trunking?
▪ Multiple VLANs are used for connections built in each direction (10x range)
– IPsec_UDP tunnels are also built across the HA link
▪ UDP ports 120xx
HA Link
282
If you are having problems bringing up an HA link for a virtual appliance, make
sure the hypervisor permits vlan trunking, as the appliances require multiple
connections in multiple vlans between them to connect.

Flows going in wrong tunnels or overlays
– Which overlay is the flow matching?
▪ Look at the flow detail to see the which route policy and/or
overlay was matched
▻ ‘Priority in Map’ points to a route policy on an appliance
▻ Overlay route policy numbers will be in the 20000-20007 range
– Are your overlays in the correct order?

▪ Did you put the most specific matches at the top of the list of
overlays?
– Flows are going in underlay tunnels
▪ They probably didn’t match an overlay.
See if they matched the default route policy 65535
– Flows are going PT instead of a tunnel
▪ Did they hit the Peer Unavailable action?
▪ Check the routes table
▪ Did they match the wrong route policy / overlay?
283
What if you have flows that are going into the wrong tunnels or overlays?
The first thing to do is look at the flow detail and see which priority route policy
is being matched and which overlay, if any it is associated with. In this case,
the flow is not even associated with an overlay. All overlays have policies in
the 20000 range, and this one is 65,500.
1. Next, check to see if your overlays are in the correct order. If traffic is
hitting the wrong overlay, make sure the overlays are in the correct order,
and the ACLs with the most specific match criteria are at the top.
2. If flows are going in underlay tunnels and not being optimized, check the
flow detail to see what they are matching. If it is the default route policy, it
means they didn’t match an overlay, and you should reexamine the match
criteria used for the overlays.
3. If flows are going passthrough instead of being put in a tunnel, they
probably hit the Peer Unavailable action. This could happen because there
is no route to the destination. Check the routes table for the destination
subnet. Matching an overlay that hasn’t been applied to the site where the
destination subnet resides will cause this also. Perhaps you failed to apply
the overlay to all the needed sites.

Review #26: Overlays & Tunnels
?
138) What are some reasons a tunnel might not come up?
139) Can a user configure a Business Intent Overlay from the appliance's web
interface?
140) What effect does the order of overlays in the list on the BIO page have on its
priority?
141) If you delete a BIO created tunnel on an appliance, what will happen within 5
minutes?
142) If you apply a BIO to an appliance without a matching label or ACL, will traffic be
routed into the associated overlay tunnels?
143) How many active primary links do you need for a Link Bonding Policy of “High
Availability”?
144) Which ports are used to build the IPsec_UDP tunnels between appliances?
?
284
1. What are some reasons a tunnel might not come up?

• Incorrect BIOs, unlabeled interfaces, IP reachability, bad next hop router
address… to name a few. With manually created tunnels you can add
encapsulation mismatch, but with Orchestrator created tunnels, this won’t be an
issue.
2. Can a user configure a Business Intent Overlay from the appliance's web interface?
• No, only from Orchestrator
3. What effect does the order of overlays in the list on the BIO page have on it’s priority?
• The one on top has the highest priority and will be matched against first.
4. If you delete a BIO created tunnel on an appliance, what will happen within 5 minutes?
• Orchestrator will try to rebuild it
5. If you apply a BIO to an appliance without a matching label or ACL, will traffic be routed
into the associated overlay tunnels?
• Of course not. Labels must match
6. How many active primary links do you need for a Link Bonding Policy of “High
Availability”?
• At least 2 primary links
7. Which ports are used to build the IPsec_UDP tunnels between appliances?
• They are in the 12,000 range

Licensing
• Troubleshooting Flows and Ports
Now we’ll talk about key elements of licensing and how to troubleshoot
licensing issues.

EdgeConnect Licensing Steps Allow Cloud Portal traffic to:
• cloudportal.silver-peak.com
All communications use port 443 • portal.silverpeak.cloud
EdgeConnect Cloud Portal Orchestrator
Registration: serial number (physical)

Or account name/key (virtual) You may also need
holes for …
Registration OK – waiting for approval
(OK if serial number known to be
associated with the account or account *.amazonaws.com - For
name and key are valid Poll for EdgeConnects reported to Portal uploading support files
for discovery
*.googleapis.com,
User approves a discovered appliance *.gstatic.com - For
topology map
CloudPortal grants license if one
available
These are not needed
for the product to
Orchestrator begins managing Appliance
function properly.
286
This slide reviews the steps in appliance registration. We covered these steps
in detail earlier in the course. The key thing here, is to remember all
connections will use port 443 https so you must permit connections to the
cloud portal from the appliances and Orchestrator via port 443.

Is Orchestrator Registered with the Portal?
–Can Orchestrator Connect via HTTPS & WebSocket?
• Check firewall settings to permit port 443 to Cloud Portal
• If you require a web proxy, configure Orchestrator Orchestrator CloudPortal
(Orchestrator Administration →Proxy Configuration) WebProxy
• IS DNS properly configured and reachable?

o Orchestrator will need proper DNS configuration to resolve:
cloudportal.silver-peak.com
o DO NOT change ‘Host’ from a DNS name to an IP address
(it might change). Fix your DNS…
If Portal isn’t
–Orchestrator NOT Registered with Cloud Portal? reachable,
• Check Account Name and Key & Orchestrator license key Orchestrator
can’t register!
287
The first thing you need to do when setting up a network is install the
Orchestrator and get it registered. If you go to the Silver Peak Cloud Portal
page under Orchestrator Administration, you can see if the Orchestrator is
registered or not. If it says Registered Yes, you are good to go. If not, here are
some things to check.
1. As we mentioned previously, the Orchestrator must be able to reach the

cloud portal via port 443, so make sure your firewall allows this.
2. If you require the use of a web proxy, the Orchestrator supports this,
although the appliances don’t. If the Orchestrator can’t reach the cloud
portal, it will raise an alarm.
3. Also, make sure the Orchestrator can resolve cloudportal.silver-peak.com
via DNS. It will need to be able to do this to find the portal’s IP address and
connect to it to register itself.
4. This might seem obvious, but Check that you’ve configured the correct
Account Name and Account Key. It’s easy to make copy and paste errors.

Portal & License Monitoring
Available on the
Appliance!
288
Starting in 8.1, the Portal and Licensing Monitoring status screen is available
on the appliances. It shows whether the appliance has been able to resolve
the name of the cloud portal, and if it has been able to establish HTTPS and
WebSocket connections to the portal. Additionally, it shows you if the appliance
has been able to establish a websocket connection to its Orchestrator. This is
a great place to go for a summary of reachability information if you are trying to
troubleshoot an appliance license and management issue.

Reachability status
Administration→ Reachability Status
289
There is also a reachability summary tab on Orchestrator under Administration

to show you the status of communications between the Orchestrator and the
appliances.

Orchestrator→Appliances quick test
– Right click on the appliance and select Connectivity
290
If you are having problems there is an easily accessible communication test

available for each appliance in current code. Just right click on the appliance in
tree view and select Connectivity. The test only takes a few seconds and will
tell you if the Orchestrator is able to talk to the appliance.

Orchestrator → EdgeConnect connectivity
– If mgmt0 is used for Orchestrator connection
• Make sure appliance traffic from mgmt0 can get to Orchestrator
• Use Ping / Traceroute (Maintenance menu)
• Bridge Mode MUST have mgmt0 access
– If Data Path interface is used for Orchestrator connection EdgeConnect Orchestrator
• Make sure Data Path next hop to Orchestrator is reachable
• Make sure you can ping Orchestrator with –I option specifying local Data Path Address
o May need to add a static route to the destination subnet/host (Configuration→Routes)
– Ifan appliance has to reach Orchestrator through another Silver Peak, make sure the
intermediate appliance is licensed already!!!
291
Here are some additional tips for troubleshooting Orchestrator to Appliance

connectivity.
First, if you are using mgmt0 for connectivity to Orchestrator, test connectivity
with ping or traceroute. If you are deploying an appliance in Bridge Mode, you
must use mgmt0 for EdgeConnect to Orchestrator connectivity.
If you are using Router Mode, and are planning to use a data path interface for
connecting to the Orchestrator, make sure the next hop router is reachable,
and test the connection hop by hop to the Orchestrator. Remember that when
you are using ping from the appliance maintenance menu or CLI, to use the –I
option to specify the source data path address to use for the ping.

EdgeConnect Licensing: Approval
– Always use the approval button on the Orchestrator to
grant an appliance a license and begin managing it.
– Manual add is only meant for VX/NX
– NEVER EVER MANUALLY ADD AN EdgeConnect to the Orchestrator

▪ EdgeConnect Appliance will not be licensed in this case
▪ To correct, delete the appliance. Approve it when Orchestrator discovers it.
– Not possible in latest code
292
Never manually add an EdgeConnect appliance to the Orchestrator using its

IP address. It won’t work because the appliance won’t have registered with the
cloud portal and won’t be licensed. If you did manually add it, right click on the
appliance in tree view, and select delete. After a couple of minutes you should
see it connect in and the Appliances Discovered button will light up, assuming
you have configured the correct account name and account key if it is a virtual
appliance.

Managing EdgeConnect licenses
– You can edit (add / remove / change) appliance licenses on the Licenses tab in Orchestrator
– Go to Configuration->Licenses tab on Orchestrator
• Select one or more appliances in the list
• Make changes
• Apply
– Example: Adding 4Mbps of Boost to four appliances
• Select all 4 appliances
o Click on top appliance
o Ctrl+Click on other appliances to select them too
• Click to configure EC license
• Click Enable Boost
• Enter 4000 in Bandwidth field
• Click Apply
• Click Save Changes
• Refresh screen to see updated licensing info
– NOTE: You must have available licenses!!!
293
You can edit, add or remove licenses for different features on each appliance
from the license management screen of Orchestrator.
An example is shown here of how to add 4 Mbps of Boost to appliances.
Simply select the desired appliances in the list on the licenses tab, click
Configure EC Licenses, make your edits and click Apply as shown.
Make sure to save the changes on the appliances to make sure the changes
will survive an appliance reboot.
When you add licenses, it’s worth noting that you must have already
purchased them in advance. The available license information is shown to you
on the Licenses tab, so you can see whether or not the operation you want to
perform is possible.

Reclaiming an EdgeConnect license
– You can delete the appliance from Orchestrator.
• On deletion, Orchestrator tells Portal to deny an appliance a license.
• Denial on Portal does not imply that an appliance can no longer pass traffic.
• Appliance will contact Portal every 24 hours to renew its lease. At that time, it is no longer
granted a lease.
– Or you can go to Configuration->Licenses tab on Orchestrator
• Select the appliance in the list
• Click on Configure EdgeConnect license link
• Select Revoke license
• This method keeps the appliance in Orchestrator
– There is one extra Base license for RMAs
294
If you have removed an appliance from your network and need to reclaim the
license for use on another physical or virtual machine, just right click on it in
tree view and choose Delete.
You can also go to the licenses tab under the configuration menu in the
Orchestrator, select the appliance in the list, and then click on Configure EC
Licenses. In the dialog box, choose Revoke, and then Apply the configuration.
You should know that if you are performing an RMA to replace a failed
appliance, there is one extra license available so that you can bring up the
replacement before revoking the failed devices license.

Boost Licensing
–Boost license is required on both sides to enable TCP acceleration and
other protocol acceleration.
–If Boost is applied only on one side, only that side will perform Payload
compression
Remember: Boosted traffic will

not exceed licensed Boost
bandwidth. UnBoosted traffic is
not limited by Boost BW
If Boost license is exceeded: TCP traffic will be

queued until Boost BW is available. Non TCP
traffic will be transmitted, but w/o Boost (no
NM, Compression).
295
Finally, remember that Boost must be configured on the appliances on both

ends of the link to operate properly. If you only license a single appliance in a
connected pair, Boost features like TCP acceleration cannot work.
Remember: Boosted traffic will not exceed licensed Boost bandwidth.

UnBoosted traffic is not limited by Boost BW. This means that you could have
traffic that matches a boosted overlay be limited by the amount of licensed
boost BW, while at the same time, traffic that matches an overlay that has
boost turned off will not be limited, except by max WAN BW for the system,
which affects all traffic globally.
If your available Boost license bandwidth is exceeded: TCP traffic will be

queued until Boost BW is available. Non TCP traffic will be transmitted, but w/o
Boost (this means no Network Memory or Compression, for example). When
Boost BW becomes available again, all the eligible traffic will once again be
boosted.

Flow drops due to no or expired license
–Remember – an appliance
that is not licensed, or with an
expired license will policy
drop traffic
–Tunnels may be up, but traffic
will not be passed
In this example, the tunnels are up and

this appliance has learned the subnet
shared route to the destination with a
metric of 50
296
Remember – an appliance that is not licensed, or with an expired license will

policy drop traffic, even if tunnels are established. In the Red box at the top,
you can see the Transmit reason is Drop-Absent or Expired License.

Cloud Orchestrator Notes
–Appliances need to be able to reach Cloud
Orchestrator on the Internet
• Firewalls, routing etc. need to allow access
–SW upgrades for appliances require Cloud Portal
reachability also Cloud Portal
Orchestrator
Cloud Orchestrator
• Images are stored on the Cloud Portal
• Cloud Orchestrator will provide a url to the appliance at upgrade
time
• Appliance needs DNS to resolve the Cloud Portal domain for
reachability or download may fail Edge Connect
• Newer versions of code will attempt resolution on all interfaces
297
If you are using a cloud orchestrator, it should be obvious that you need
firewall rules that allow devices to access it.
What might not be so obvious is that for software upgrades, they also need
access to the cloud portal. This is because the upgrade images are not stored
in the cloud orchestrator. They are stored on the cloud portal, and the cloud
orchestrator will point the edge connects to a url on the cloud portal at upgrade
time.

Review #27: Licensing
?
145) How long is an appliance license lease?
146) What protocol and port number do the Appliances and Orchestrator use
to talk to the Cloud Portal?
147) Does the Orchestrator require Internet connectivity to register with the Cloud
Portal?
148) Does an appliance require direct internet connectivity to the Cloud Portal to
register? If not, what would need to be configured?
149) True/False: An unlicensed appliance will send all incoming traffic Passthrough
Shaped.
150) True/False: It is possible to revoke a base license from an appliance and apply it
to a new one.
?
298
1. How long is an appliance license lease?

• 30-day rolling window.
2. What protocol and port number do the Appliances and Orchestrator use to talk
to the Cloud Portal?
• HTTPS port 443
3. Does the Orchestrator require Internet connectivity to register with the Cloud
Portal?
• Yes.
4. Does an appliance require direct internet connectivity to the Cloud Portal to

register? If not, what would need to be configured?
• You can configure the appliance to use the Orchestrator as a proxy.
5. True/False: An unlicensed appliance will send all incoming traffic Passthrough

Shaped.
• False. It will policy drop all traffic.
6. True/False: It is possible to revoke a base license from an appliance and apply it

to a new one.
• True – this is done from the licensing tab

Troubleshooting
• Routing and Reachability
Let’s wind up our discussion of troubleshooting by talking about common

reachability and routing issues.

EdgeConnect WAN Hardening
If an interface is WAN hardened, it does the following:
–Allowed (in/out):
• IPsec tunnel traffic (all user traffic traversing the interface MUST be inside the tunnel)
• Cloud Portal traffic
o Hardening does not impact licensing
• DHCP
• DNS
–Everything else is dropped.
• Internet Breakout and Passthrough traffic can’t make connections
–To see if WAN hardening is related to your problem, you can try turning it off
• Might also indicate the traffic is going Passthrough instead of into a tunnel where it belongs
• Be careful as this introduces a security exposure on Internet connected interfaces
300
We talked about WAN hardening in a previous lesson, but let’s talk about the
implications for troubleshooting.
First, recall that user traffic must enter and leave a hardened interface inside
an IPsec tunnel. With a few exceptions, all other traffic will be dropped.
The exceptions include:

Traffic to and from the Cloud Portal so the appliance can license itself,
DHCP traffic so devices can obtain IP addresses, and
DNS traffic, so that the devices can resolve host names, like cloudportal.silver-
peak.com
If you are having trouble bringing up a connection through a hardened

interface, you can try turning it off on the Deployments page temporarily. If
things start to work, then the traffic was probably going Passthrough, and the
connection was being prevented from coming up. This might be due to an
overlay configuration or route policy error. You probably shouldn’t leave
hardening turned off on an Internet facing interface for security reasons. There
is considerably less risk if the interface is connected to an MPLS private
network.

Interface & Cabling Consistency
– When Bridge Mode appliance device is in bypass, the appliance acts as a cross-over
connection
• Will the LAN-side device talk to the WAN-side device if cabled in that way?
• When set to auto-negotiate, the appliance also uses auto-MDIX so cabling issues may not be readily
apparent until bypass happens
– If performance is poor, check the interfaces of the upstream and downstream devices for
half-duplex operation.
Relay
lan0 wan0 WAN
301
301
An area of frequent problems is when one of the devices is set for half duplex.
This can drastically reduce your performance, so make sure to set you links for
full duplex.
Remember also, to check the cabling on Bridge Mode deployments to make

sure that in the event the appliance must be put into bypass mode, that the
devices on either side will still be able to talk to each other. The appliance in
fail to wire mode acts like a crossover cable, meaning transmit pairs on one
side are connected to receive pairs on the other. You should always test
bypass mode operation prior to production deployment. This will make sure
you avoid any cabling, speed and duplex misconfiguration issues and assure
your network stays up if an appliance goes into bypass mode.

Cisco Discovery Protocol (CDP) for Silver Peak
–Default is Disabled
–To verify if CDP is enabled on the
Silver Peak appliances (CLI or
Broadcast CLI only):
• # show cdp
–To enable/disable CDP:
• # config t
• (config)# cdp enable/disable
–To show all connected neighboring
devices
• # show cdp neighbors
–Other commands are: CDP operates at Layer 2
• # show cdp neighbors detail
• # show cdp traffic
302
If you are logged into an appliance via ssh or VMware console, here are the
CDP commands that are supported. As you can see, they look just like the
Cisco commands, so if you are familiar with those, you shouldn’t have any
difficulty with Silver Peak’s implementation. CDP is enabled by default.
One useful characteristic of CDP is that it operates at layer 2. It’s possible

sometimes that layer 3 connectivity can be broken because of ACLs or
security policies, yet CDP information can get through at layer 2. If CDP is
getting through, it indicates you have network adjacency, and your reachability
problem is at layer 3 or above.

Redirection or Attracting fails out of path
–Attracting - Routing Protocols (BGP and OSPF)
• Are the routers learning routes from the Silver Peaks?
o Are the metrics being advertised by the Silver Peaks preferred?
• Is the Silver Peak learning routes from other routers?
• Is a BGP neighbor in Established state?
• Is your OSPF neighbor in Full state?
WAN
–Redirecting - PBR / WCCP

• Are the redirection ACLs using a wild card mask (e.g. 0.0.0.255)?
• Is traffic black holing because you put redirection on the appliance interface?
–VRRP
• Are the local devices pointing to the VIP as the next hop?
• Is a Silver Peak the Master?
303
If traffic is not getting to an out of path appliance, there are several things to
check, depending on how you are redirecting or attracting traffic to the
appliance.
If you are using a routing protocol to attract traffic, this means the silver peaks
must be advertising the routes with the best metrics. Make sure your BGP
neighbors are in the Established state, and the OSPF neighbors are in the Full
state or routes will not be exchanged at all.
If you are using out of path redirection with PBR or WCCP, the most common
problem is to misconfigure the ACL to use a subnet mask instead of a wild
card mask. Remember the bits in a wild card mask are inverted. If
Passthrough connections are failing, make sure you are not redirecting traffic
on the interface where the Silver Peak appliances are connecting as this can
cause black holing.
If you are using VRRP for deterministic routing, make sure one of the
appliances is Master, and traffic is being sent to the VIP, or virtual IP address.
If you are using PBR, make sure route maps are pointing to the VIP, and the
matches are incrementing. Also, make sure the appliance you want to route
traffic through is up and acting as master in the VRRP group.

Network Routing Issues
How are the Silver
–Are you advertising a default route if needed? Peaks in the
network learning
–Routed Subnets not directly connected? these subnets that
• Configuration →Routes are not directly
connected?
• Check subnets table
• Use BGP/OSPF or add Static routes
(and next hops) if required
–Are you redistributing BGP/OSPF learned
routes via Subnet Sharing
–Next Hop Router Reachable?
(should see an alert if unreachable) WAN
• Ping to test reachability

• CLI > show system nexthops
304
As far as general routing issues go, make sure the WAN interfaces on the
appliances are pointing at the correct next hop and it is reachable. Make sure
to advertise default routes or summary routes from hub sites and data centers
if needed. Also, if there are local subnets on the LAN-side that the Silver Peak
is not part of, you’ll need to use a routing protocol like BGP or OSPF so the
appliances can learn the subnets from local L3 devices, or manually add
routes and next hops for those.

Review #28: Routing and Reachability
?
151) True/False: If you are doing internet breakout on a WAN interface, it should be set
to ‘‘Harden”.
152) True/False: CDP (Cisco Discovery Protocol) tests Layer 3 connectivity.
153) What is a common misconfiguration when redirecting traffic out of path?
154) How do the Silver Peaks attract traffic via a routing protocol when the local OEM
routers are learning the same subnets via a different path?
155) What should the local devices point to when redundant Silver Peaks are using
VRRP on the lan side of the network to deterministically route traffic?
156) A data center appliance is BGP peered to local routers and is learning routes from
them. The branch appliances can’t reach the subnets beyond the routers. What
might be the problem?
?
305
305

SPSP Certification Exam
Upon completing all modules, you will be
automatically enrolled in the exam.
❑ You have one hour to
complete this test.
Go to https://training.silver-peak.com
❑ You must achieve a score of
70% to pass.
Login using your userid/password
(it should have been in your registration email) • Use the Question List at
the bottom of the test
interface to navigate back
1. Click to previous questions as
required.
2. Click
❑ When time expires, any
unanswered questions will be
3. Click treated as incorrect.
If you don’t pass, you can retake the test at any time.

A Hewlett Packard
Enterprise Company
More FREE Technical Training Courses at

APPENDIX SLIDES
308

If you have previous license Tiers
Old Licensing Tiers – Mini, Base, Base+Plus continue until current
(prior to Aug 2020) subscription expiration
▪ Adding licenses with new tiers is allowed
License Bandwidth ▪ Purchase upgrade to new tiers will require
Mini 50 Mbps ▻ Orchestrator upgrade to 8.8.1+
Base 200 Mbps ▻ Edge Connect upgrade 8.1.7.19+, 8.1.9.6+ or 8.2.0+
Base + Plus > 200 Mbps – At time of Renewal, old licenses will convert to new
bandwidth tiers
▪ Mini →50Mbps
For purposes of ▪ Base →200Mbps
SPSP exam ▪ Base + Plus → Unlimited
Use NEW Tiers
310
If you were an existing customer before August of 2020, you licensed your
appliances using different bandwidth tiers than the ones that we just talked
about. Since this was new at the time this recording was made at the end of
August in 2020, we thought we should mention them here.
The old bandwidth tiers are shown in the table on the left. If you had Mini Base
and Plus licenses in your network, they will continue until they expire with no
action needed by you.
It should be noted that if you add licenses with the new tiering, or convert your
old licenses, it will require upgrading the Orchestrator and EdgeConnect
appliances to a software version that supports it. If you convert your old
licenses to the new tiers, the Mini and Base will convert to the new
corresponding 50 and 200 Mbps tiers. The old Base + Plus will convert to the
new Unlimited tier.
For purposes of answering any exam SPSP questions, use the new tiers
shown on the previous slides.

The 4 Standard policies
Custom Link Bonding Field Summary should cover 98% of
customer needs.
Waterfall packets across eligible underlays based on one of five
quality measurements:
• Overall Quality (combination of latency and loss, “MOS for data”)
• Latency
order matters
• Loss with Link
• Jitter Order
• Link Order NEW

Balanced -Per-packet load balancing across all eligible underlays
based on one of three modes:
• Link Capacity (Local) – Choose link w/ most unused BW
• Link Utilization (Local) – Choose link w/ lowest % utilization
• Link Utilization (Local & Remote) – Same as above, but consider
remote device’s % utilization also.
• FEC Wait Time - Controls how long we wait to fill a FEC packet before sending
• Lower number means more FEC overhead because more FEC packets will be sent. Ignore or set to very low value
• Exclude Links - Controls when we decide to remove an underlay from an overlay during brownout conditions
• On Overlay Brownout: wait for the overlay itself to see loss before removing underlays from the overlay
• On Underlay Brownout: remove the underlay from the overlay as soon as it violates the brownout threshold
• Link Reorder Frequency – how aggressively we evaluate the underlays and switch traffic from one link to another
• Aggressive: Changes are detected in few seconds – High speed networks such as dual High speed internet links.
• Moderate: About a minute – default, works for most setups.
• Conservative: Several minutes. E.g. switch to LTE links only when primaries have down for a while. Reduces LTE costs
• Path Conditioning – Sets the lower and upper range of % of FEC packets. 100/100 = 1:1 FEC
• Packet Reorder Wait Time – Sets Upper and Lower limit of POC timer variability. If POC timer expires, packet is marked lost.
311
Here is a summary of the custom link bonding policy options.
Let’s start by saying that you shouldn’t need to use them, because the four
standard link bonding policies are well tested and should cover most of the
needs of almost any customer. Custom link policies are the kind of thing you
might implement at the direction of the Silver Peak TAC. You should be very
careful and make sure to thoroughly test any custom policies before putting
them into production.
That being said, we’ve provided definitions and some guidelines for the
configurable options in the custom link bonding policy. Use them wisely. A
deep dive discussion of these is beyond the scope of this course and will be
covered in an upcoming mini course.

SELF-PACED SLIDES
313

Agenda: Self-Paced
PART 1 PART 2
– Feature Terminology & Definitions
– Automated Provisioning and Deployment
– Silver Peak Products & Licenses
– Virtual Routing Redundancy Protocol
– Licensing Process
– Orchestrator Overview
– Backup, Restore, Image Management
– Path Selection – Monitoring Your Network

– Deployment Modes – Logging
– Data Security – Quality of Service
– Configuration Process • LAB 9 – Obtaining your LAB Access Code for Part Two
– Business Intent Overlays • LAB 10 – Configure A Hub & Spoke Business Intent Overlay
• LAB 1 – LAB Familiarization & Orchestrator Installation • LAB 11 – Complete ECV-3 Installation & Apply The
• LAB 2 – Orchestrator Configuration & Licensing Campusnetwork Overlay
• LAB 3 – Configure Interface Labels & Groups • LAB 12 – Zero-Touch-Configuration (ZTC) of ECV-4
• LAB 4 – Configure Deployment Profiles • LAB 13 – Completing Registration of ECV-4 In Orchestrator
• LAB 5 – Template Groups Configuration • LAB 14 – VRRP Configuration
• LAB 6 – Configuring Business Intent Overlays
• LAB 15 – Basic Flow MonitoringLAB 15 –Reporting
• LAB 7 – Completing Appliance Configuration
• LAB 16 – Troubleshooting Tools
• LAB 8 – Complete Registration of ECV-1 & ECV-2 In Orchestrator
– Troubleshooting
314
The course is divided into two parts, each followed by a set of Hands-On
exercises. First off, you will view a series of videos which will prepare you for
the group of labs you will do. Besides viewing lectures on all the elements of
installing and managing an SDWAN network, you’ll engage in a number of
hands on labs to perform various installation, configuration and troubleshooting
tasks. Well over half the course time is spent on labs. It’s worth noting that this
course uses a virtual VMware environment and you’ll be using and installing
virtual machines. Don’t worry if you’ve never used VMware before, the detailed
LAB instructions will walk you through each task.
Then you’ll prepare for the installation of appliances, by preconfiguring various

types templates in the Orchestrator. In the next steps, you’ll install and deploy
a 3 site network of appliances, bring up connections between them and move
data between the sites using FTP and CIFS connections.
Second, you’ll spend some time learning how to configure VRRP, monitor and
manage your new network and understand the Silver Peak Quality of Service
implementation. Lastly, we will expose you to various tools for troubleshooting.


Silver Peak Training DST SLIDES 8.10.X-8.3.0.x v1.6.4

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Silver Peak Training DST SLIDES 8.10.X-8.3.0.x v1.6.4

Uploaded by

Copyright:

Available Formats

A Hewlett Packard

Silver Peak Training

Based on Orchestrator 8.10.13 and EdgeConnect OS 8.3.1.x

Hello. Welcome to the Deploying SDWAN Technologies course. This material

Deploying SDWAN Technologies -

4. Any prior Silver Peak &

Deploying SDWAN Technologies -

Deploying SDWAN Technologies -

– Deployment Modes – Backup, Restore, Image Management

• LAB 4 – Configure Deployment Profiles • LAB 14 – Basic Flow Monitoring

• LAB 5 – Template Groups Configuration – Quality of Service

Then you’ll prepare for the installation of appliances, by preconfiguring various

Deploying SDWAN Technologies -

Deploying SDWAN Technologies -

Deploying SDWAN Technologies -

Feature Terminology and

Deploying SDWAN Technologies -

To some people, the term SDWAN, or Software Defined WAN is something

1. This is because SDWAN is an emerging technology and each vendor in this

Deploying SDWAN Technologies -

• Cloud Portal – Silver Peak’s portal on the internet.

2. The Orchestrator is Silver Peak’s management software and is required for

Deploying SDWAN Technologies -

Encapsulation is placing a data packet inside another data packet and

1. A tunnel is an encapsulated connection between two devices. in our case,

Deploying SDWAN Technologies -

Flow EdgeConnect EdgeConnect

• Flow – A stream of packets transmitted between two endpoints

A flow is a connection like FTP, a web session, etc. Here’s an example of a

Deploying SDWAN Technologies -

• Passthrough traffic – Flows NOT in an EdgeConnect

• Local Internet Breakout – Another way

Moreover, different applications often require different treatment when it comes

Deploying SDWAN Technologies -

Deploying SDWAN Technologies -

* IPsec_UDP is the default. Other tunnel types are supported

So to summarize, there are two kinds of tunnels: Underlay and Overlay.

2. Simply data can be distributed across multiple underlay tunnels using

Deploying SDWAN Technologies -

– The set of policies and

Deploying SDWAN Technologies -

– Dynamic Path Control (DPC)

Deploying SDWAN Technologies -

TCP acceleration helps to mitigate the effects of latency, by enabling local

Deploying SDWAN Technologies -

Business Traffic Internet

Each Overlay is created

Deploying SDWAN Technologies -

1) What term describes placing a packet into an IPsec tunnel?

2) Describe/define the following:

4) How many Orchestrators would be used by a typical organization?

5) Given two tunnels named: “To_ECV-3_MPLS_MPLS” and “To_ECV-3_CriticalApps”:

Deploying SDWAN Technologies -

Silver Peak Products and

Deploying SDWAN Technologies -

Small Branch/ Small Large Head Office

Max # Tunnels 2,000 2,000 5,000 10,000

Available platforms in the EdgeConnect product set vary in supported

Deploying SDWAN Technologies -

Data Center Data Center

Orchestrator is included with EdgeConnect 22

Deploying SDWAN Technologies -

• Adding Boost may increase hardware requirements (choose whichever is greater).

EdgeConnects can also be deployed as virtual machines under a hypervisor.