Versa SDWAN – Teridion Integration as SDWAN Underlay
by Matej Kultan and Ehsan NseratPurpose
This wiki article focuses on how to configure any Underlay, that is not-directly connected. This could be AWS/Azure/GoogleCloud or even a Private or MPLS network. In this case Teridion middle-mile provider is being an SD-WAN underlay The breakthrough lies in leveraging Hyper-Scaler’s Backbone as an additional underlay for the SD-WAN solution. Private Hyperscalers like AWS, Microsoft, and Google offer superior network performance between regions compared to the public Internet, akin to choosing private highways over public roads. By connecting to the Hyper-Scaler Backbone through local Internet Hyperscaler network Points of Presence (PoPs), the SD-WAN discovers dynamically underlay and establishes overlay over the new paths. The local SD-WAN branch dynamically determines whether to route premium, latency-sensitive traffic over the public Internet or tunnel it through the Hyperscaler Backbone based on real-time path parameters. The key benefit for branch users is an enhanced experience with reduced delay, jitter, and packet loss compared to the unguaranteed non-SLA Internet connections. SD-WAN achieves this by establishing IPSec-in-IPSec or IPSec-in-GRE tunnels from each applicable SD-WAN branch to the closest Hyperscaler PoP, enabling SLA path monitoring, and setting SD-WAN policies for traffic steering based on appropriate SLA criteria.Teridion Introduction
Teridion service aims to improve the performance and reliability of internet connections by leveraging a distributed network of cloud-based PoPs interconnected by Hyperscalers underlay (AWS, Microsoft, Google, etc..) Teridion use real-time network measurements and analytics to select the most efficient path. This optimisation is particularly beneficial for applications that require low latency, such as real-time communication, video streaming, and other interactive services. The Versa Networks SD-WAN solution is highly flexible and allows you to establish SD-WAN tunnels over Public Internet or Private Underlays. In this new use-case, the Teridion Underlay is not directly attached. To reach Teridion Private Underlay, an IPSec or GRE tunnel is needed from each Branch location. Once two or more SD-WAN Branches are connected to their closest Teridion PoPs, Versa can create dynamic full-mesh tunnel network over Teridion Underlay.High-Level Diagram
Below Diagram shows the Solution topology. Pair of SD-WAN Routers connected over Internet, use additional Underlays such as Hyperscalers and MPLS.
Reference Topology
Three Branches will be part of the following Article, EMEA, US and India Branch-1-VSSE will be connected from EMEA Region over GRE tunnel to Teridion EMEA PoP. GRE Tunnel is allowed only if Branch uses Public IP on its interface. If it is NAT-ed, you need to use IPSec, that allows NAT-Traversal. Branch-2-VSSE, will be connected from US Region over IPSec tunnel to Teridion US PoP. . Branch-3-VSSE, will be connected from APAC Region over IPSec tunnel to Teridion APAC PoP. Note: This node will not be part of below diagrams, but it is configured as the Branch-2-VSSE. Let’s focus firstly on EMEA and US Branches. In both Branches an additional Teridion-Transport-VR will be created and tunnel tvi-0/555 interfaces will be used for creating the SDWAN overlay. Since IPSec or GRE are only the Branch-to-PoP connection, there is mutual interoperability between node Branch-1-VSSE and Branch-2-VSSE. Below diagram shows, that Yellow path will be created by default over the Internet. The Green will be established thanks to GRE and IPSec tunnels towards the Underlay.
Branch-1-VSSE Configuration might be done over Service Template – preferred , Device Template or Device level configuration. We will start with Device Template/Device configuration first.
Case Branch-1-VSSE – GRE Based Configuration (Option A)
– GRE is less recommended as there is need for Public IP on Versa INET-WAN. For IPSec please go to the section. In this Example Branch-1-VSSE will be using 10.1.0.10/30 and the Teridion PoP will be 10.1.0.9/30. The same IP – 10.1.0.9 will be also used later as static default route next-hop to reach all other Branches. In case Device level configuration would require “Build”, “Configure”, “Commit” sequence due to new VRs and TVIs. In case of Template there is not such need as the Config validation will be done during the Commit Template procedure.1. A) Start with TVI GRE point-to-point interface), in this example tvi-0/555.0
The Source and Destination are Public IP Addresses of the Branch and Teridion PoP. Create a Local TVI unit 0 with /30 private subnet. This subnet will require only 2x /32 IP adresses:- Teridion-Transport-VR Tunnel IP on Versa (10.1.0.10/30) Teridion PoP IP (10.1.0.9/30)
Case Branch-2-VSSE – IPSec Based Configuration (Option B)
In this Example Branch-2-VSSE will be using 10.1.0.6/30 and the Teridion PoP will be 10.1.0.5/30. The same IP – 10.1.0.5 will be also used later as static default route next-hop to reach all other Branches. Branch-2-VSSE Configuration might be done over Service Template – preferred , Device Template or Device level configuration. Note: In case Device level configuration would require “Build”, “Configure”, “Commit” sequence due to new VRs and TVI.- B) Create TVI Interface for IPSec tunnel (skip for GRE)
2. Add that TVI interface into Organization→Limits. Note that Interface shall belong to the Appliance Owner, in case multi-tenant case is expected.
3. Create TERIDION-WAN-VR and add that TVI interface into the VR
4. Create Static Default Route via the TVI Interface and Teridion PoP IP.
5. Add TERIDION-WAN-VR into the Organization – Limits – Available/Owned Routing Instances
5 B) (skip for GRE) in Case you configure IPSec based access: Services -> VPN Profiles→ + Add new → Site to Site
Insert the IKE Phase 1 (these parameters are from Defaults of Teridion, feel free to change on both sides identically if needed some). The PSK shall be identical for remote and local. The identity will be the Public IP of Versa and Teridion PoP.
Insert the IPsec Phase 2 (these parameters are from Defaults of Teridion, feel free to change on both sides identically if needed some).
6. Create in Services->SDWAN-> Path Policies, that will cover only Branch-to-Branch Probing.
There is a need for to-Branch Term – Match “Branch”
The to-Controller Term is not needed, as it is not expected to use Teridion for Controllers
6. In Terms-Actions – configure SLA Monitoring. Defaults are inspired by Versa default values: Interval 2000ms, 300s Logging Interval, 3x Loss Threshold. Adaptive SLA Monitoring or Data Driven might be useful if there is no communication between nodes. Default are 300 Inactivity and 30 Suspend Interval
7. Under System→Site Config→Interface and add WAN Interfaces tvi-0/555.0 and select TERIDION Transport Domain and put Hyperscaler Circuit Name, in this example TERIDION.
8. Under SDWAN – Site – Edit Site – and add WAN Interfaces tvi-0/555.0 with SLA Monitoring Policy defined earlier in steps 5. and 6.
Versa Configuration is finished. The traffic will be by default Load-Balanced accross Internet and Teridion. You might need to create SDWAN policy for appropiate Teridion-WAN usage.
Teridion Configuration
1. The Default screen in Teridion is Network Health where it is possible to monitor existing tunnels to SD-WAN. Below you can see respective Gateways and Usage. The Usage currently is only based on Versa SLA Monitor Probes. Note this document is generated based on existing configuration, while for your setup, you will start with + ADD SITE button in Network Health or in Site Configuration tab.
2. You can also enter the Site Configuration Tab, where you can edit existing Sites configurations and see the Local & Remote Public IPs, BGP ASNs and state of Configuration.
3. Let’s review/configure an IPSec Site. Site Name and Location needs to be entered.
Important!: Please keep scrolling in Teridion Web GUI, it might have additional input fields, but not seen without scrolling down.
4. Tunnel Type IPSEC (recommended due to Branch deployments behind NAT). Route based (static), will take into consideration the Prefix/es of the Site. For SDWAN purposes Static is Fine.
5. In this setup we keep Redundancy OFF.
6. In the GW Configuration you shall enter GW IP and Site ID, it is recommended to enter identical values. The Pre-Shared Key is identical for Remote and Local Authentication. Scroll down for next parameters.
7. Enter the Monitoring IP. In this case the NAT IP is not pingable, and another IP is used. You can also skip the monitor for that node as well, if there is no pingable IP available.
8. Enter the Teridion IP, Network and Versa IP. As in the Versa configuration this will be a prefix related to Brance-VSSE-2.
9. The Site type is Hub, so it can communicate with all other Sites in a Full-Mesh topology
10. Set up the IPSec parameters for IKE Phase 1 and Phase 2. In this configuration we kept the default values of Teridion, but feel free to modify if needed on both ends to more secure parameters.
11. Scroll down for setting the IPSec Phase 2 config.
12. Set up your Bandwidth
13. Finish the configuration and Save your changes.
Versa Verification
1. IPSec Tunnel IKE verification, in Monitoring verify the IKE is Done. Otherwise you need to revise if Timeout – wrong IP/Reachability or Auth Failed – IKE Parameters are wrong.
2. IPSec Tunnel IPsec History verification for Last Status Active.
3. The Hyperscaler Underlay with respective IP is known and announced to MP-BGP Versa Private.
4. Once configured the service on at least 2x Nodes, you can verify the Tunnel is established also over Hyperscaler underlay – Connection State UP with TERIDION
5. Also there is an option to see the Latency over TERIDION underlay. Note in some cases like in this example the Latency might not be better than direct connectivity. An SDWAN Policy for Voice is recommended to set for Lowest Latency Path selection, therefore once the full mesh network is available, it will perform the selection based on dynamic parameters.
Alternative Verifications using CLI
Example Below shows Branch-3-VSSE in APAC India – Delhi, that is configured as IPSEC based solution, using attached Template. As you can see the Latency is better for Teridion between India and US with around 47ms. Therefore there might be significant experience difference for Voice calls or similar type of appliacations
Service Template
Bind Data to Branch-VSSE-1 (GRE) Please see only 4 parameters are required to be filled in.
Service Template ST-GRE-to-Teridion
devices {
template ST-GRE-to-Teridion {
config {
/* Tags: replace */
interfaces {
tvi tvi-0/555 {
enable true;
mtu 1400;
mode ipsec;
type gre;
tunnel {
source "{$v_tvi-0-555_IP__tunnelGreSource}";
destination "{$v_tvi-0-555_IP__tunnelGreDestination}";
routing-instance INET-Transport-VR;
}
unit 0 {
enable true;
family {
inet {
address "{$v_TERIDION_IPv4_Prefix-0__tunnelStaticAddress}";
}
}
}
}
}
/* Tags: replace */
orgs {
org Versa-SSE {
appliance-owner;
available-routing-instances [ TERIDION-WAN-VR ];
owned-routing-instances [ TERIDION-WAN-VR ];
options {
session-limit 1000000;
}
traffic-identification {
using [ tvi-0/555.0 ];
}
sd-wan {
site {
wan-interfaces {
vni tvi-0/555.0 {
sla-monitoring-policy to-Teridion-Path-Policy;
management-traffic {
priority 0;
}
}
}
path-policy to-Teridion-Path-Policy {
terms {
term to-Branches {
match {
remote-site-type [ branch ];
}
action {
forwarding-class [ fc_ef ];
sla-monitoring {
logging-interval 300;
interval 2000;
loss-threshold 3;
adaptive {
inactivity-interval 300;
suspend-interval 30;
}
}
}
}
}
}
}
}
}
org-services Versa-SSE;
}
/* Tags: replace */
routing-instances {
routing-instance TERIDION-WAN-VR {
instance-type virtual-router;
interfaces [ tvi-0/555.0 ];
routing-options {
static {
route {
rti-static-route-list 0.0.0.0/0 "{$v_TERIDION-WAN-VR_NextHopAddress_IPv4-0__vrHopAddress}" tvi-0/555.0 {
preference 1;
}
}
}
}
}
routing-instance INET-Transport-VR {
instance-type virtual-router;
}
}
/* Tags: replace */
service-node-groups {
service-node-group default-sng {
id 0;
type internal;
services [ sdwan ];
}
}
system {
/* Tags: replace */
sd-wan {
site {
wan-interfaces {
vni tvi-0/555.0 {
transport-domains [ TERIDION ];
inet {
circuit-name TERIDION;
}
}
}
}
transport-domains {
transport-domain TERIDION {
id 15;
}
}
}
}
}
}
}
Bind Data to Branch-VSSE-2 (IPSec)
Please see only 5 parameters are required to be filled in. The additional 2x help to change easily from INET to INET2 WAN-Uplinks etc.
From 21.3.2 you can upload also multiple sites from a single GUI window.:
Service Template ST-IPSec-to-Teridion
devices {
template ST-IPSec-to-Teridion {
config {
/* Tags: replace */
interfaces {
tvi tvi-0/555 {
enable true;
mtu 1400;
mode ipsec;
type ipsec;
unit 0 {
enable true;
family {
inet {
address "{$v_TERIDION_IPv4_Prefix-0__tunnelStaticAddress}";
}
}
}
}
}
/* Tags: replace */
orgs {
org Versa-SSE {
appliance-owner;
available-routing-instances [ TERIDION-WAN-VR ];
owned-routing-instances [ TERIDION-WAN-VR ];
options {
session-limit 1000000;
}
traffic-identification {
using [ tvi-0/555.0 ];
}
sd-wan {
site {
wan-interfaces {
vni tvi-0/555.0 {
sla-monitoring-policy to-Teridion-Path-Policy;
management-traffic {
priority 0;
}
}
}
path-policy to-Teridion-Path-Policy {
terms {
term to-Branches {
match {
remote-site-type [ branch ];
}
action {
forwarding-class [ fc_ef ];
sla-monitoring {
logging-interval 300;
interval 2000;
loss-threshold 3;
adaptive {
inactivity-interval 300;
suspend-interval 30;
}
}
}
}
}
}
}
}
}
org-services Versa-SSE {
ipsec {
vpn-profile to-Teridion-IPSec-tunnel {
vpn-type site-to-site;
alarms {
ipsec-state-change enable;
ike-state-change enable;
ike-auth-failure enable;
}
local-auth-info {
auth-type psk;
id-type ip;
key "{$v_Versa-SSE_to-Teridion-IPSec-tunnel_PSK__IKELKey}";
id-string "{$v_Versa-SSE_to-Teridion-IPSec-tunnel_Local_auth_Public_IP__IKEIPIdentifier}";
}
local {
interface-name "{$v_Versa-SSE_to-Teridion-IPSec-tunnel_INET_VNI__generalLocalIterface}";
}
routing-instance "{$v_Versa-SSE_to-Teridion-IPSec-INET-WAN-VR__routingInstance}";
tunnel-routing-instance TERIDION-WAN-VR;
tunnel-initiate automatic;
ipsec {
fragmentation pre-fragmentation;
force-nat-t disable;
transform esp-aes128-sha1;
mode tunnel;
pfs-group mod5;
anti-replay enable;
life {
duration 3600;
}
hello-interval {
send-interval 10;
}
}
ike {
version v1;
mode main;
group mod5;
transform aes128-sha1;
lifetime 3600;
dpd-timeout 10;
}
peer-auth-info {
auth-type psk;
id-type ip;
key "{$v_Versa-SSE_to-Teridion-IPSec-tunnel_PSK__IKELKey}";
id-string "{$v_Versa-SSE_to-Teridion-IPSec-tunnel_TERIDION_GW__generalPeerIp}";
}
peer {
address [ "{$v_Versa-SSE_to-Teridion-IPSec-tunnel_TERIDION_GW__generalPeerIp}" ];
}
tunnel-interface tvi-0/555.0;
hardware-accelerator any;
}
}
}
}
/* Tags: replace */
routing-instances {
routing-instance TERIDION-WAN-VR {
instance-type virtual-router;
interfaces [ tvi-0/555.0 ];
routing-options {
static {
route {
rti-static-route-list 0.0.0.0/0 "{$v_TERIDION-WAN-VR_NextHopAddress_IPv4-0__vrHopAddress}" tvi-0/555.0 {
preference 1;
}
}
}
}
}
}
/* Tags: replace */
service-node-groups {
service-node-group default-sng {
id 0;
type internal;
services [ sdwan ];
}
}
system {
/* Tags: replace */
sd-wan {
site {
wan-interfaces {
vni tvi-0/555.0 {
transport-domains [ TERIDION ];
inet {
circuit-name TERIDION;
}
}
}
}
transport-domains {
transport-domain TERIDION {
id 15;
}
}
}
}
}
}
}
