WAN Edge for SRX Platforms – Configuration Video Series

[S0:P0]

Hi, everyone. My name is Shay Dunevich, and I’m a Solution Architect here at Juniper on the Mist AI-Driven Enterprise team. And I’ll be walking you through a series of videos in the form of detailed configuration guides for our Mist AI-driven SD WAN Solution supporting the SRX platforms.

OK, so I have divided these guides into two main parts. Part one is going to be an overview. We’re going to look at the network topology and the address scheme that I have in my lab and throughout this configuration and demo that you’ll be able to correlate my topology with the configuration that I’ll be using, the MST UI.

Section two is a walkthrough of the different NAT use cases, Source NAT, Destination NAT, Static NAT. We can configure Static NAT, actually, all NATs from overlay or underlay, so we’ll look into this. And then I’ll walk you through the lab topology, itself, the setup that I have, what are the SPOKEs, LAN, Hosts, hubs, and run traffic between them.

In part two, we’ll dive into detailed configurations of different sections. In section one, we’ll show you how to define and create sites on Mist and then create the WAN Edge configuration templates that will be used to onboard the devices, either SPOKEs or Hubs.

In section two, we look into how to define networks that are attached to the SPOKEs or to the Hub from the LAN side, as well as applications, which is usually referred to as destinations in the steering profiles or the security policies that we will be creating. In section three, we look into how we actually onboard devices. We have two ways to onboard devices under this solution, either through Adopt Device to a Site or we have another option, which is a full ZTP of the SRX devices.

Section five, we look into Hub and Spoke VPN traffic flow, and specifically, how to configure Steering Profiles and the different policies using the different Steering Profiles. Steering Profiles are used to define how many paths and how many overlays IPSec tunnels, each specific destination, will be using.

Section six is where we’ll start looking into how do I configure Source NAT to Overlay. This is for specific use cases where you have overlapping IPs in each and every site that are all going to be talking to some resources and workloads in your data center behind the hub.

Section seven is Destination NAT.

This is the other way around, where the hub or some management stations would like to access different LAN segments that has overlapping IPs in each of your sites.

Section eight is the combination between Source and Destination, which is referred by SRX Junos as Static NAT. And this is, again, from or to Overlay, meaning between spokes and hubs.

Section nine is where you’re going to configure Source NAT as an option as a Source NAT pool where you do local breakout from your SPOKE to the internet through the Underlay network. And section 10 is the other way around, where you want to allow some traffic from the internet or from your Underlay network going into a specific LAN segment or specific host in your data center.

For example, if you have a web server that is running behind your hub, you want to allow specific traffic from the internet or specific IPs hitting this web server on a private IP, then you will use destination NAT as well. OK, so I’ll see you in the next segment.

 

P1:S1

Hi everyone, welcome back to our AI driven SD1 configuration guide series of videos. This is going to be section one of part one which is the overview part. And in this segment we’ll discuss network topology and address scheme.
If we look at a typical hub and spoke topology, in this example I’ll be showing three sites, 123 designated as our spokes and we’ll have two hubs, hub A and Hub B and we also have an underlay network. In this case we can imagine these spokes are connected to service provider networks with two physical links.
The ISP one and ISP two, and there might be an MPLS network or an Internet network, it doesn’t really matter. But I mean, in this example, the emphasis is that we have two separate physical links and there’s going to be an overlay network using an auto VPN, Ipsec tunnels that are going to be built by missed automation that is connecting these folks to the hubs.
In the missed solution, we can have multiple hubs. It’s not limited to two hubs. In this example I’m just showing a high level topology of hub A and hub B, but you may have multiple hubs. As an example, if you have two hubs in your headquarters and maybe an additional hub deployed in a cloud provider, that is supported as well.
If we look at a high level topology, just for simplification I have chosen to go with hub one only or hub a that’s going to be. I think you know you’ll be able to better understand how to configure the different not use cases as I’ve mentioned before, but really a hub, an additional hub or.
Two more hubs. It’s the same, it’s just deploying an additional Ipsec tunnels and replicating the policies to hub B. So in my topology I’m going to have five different hosts emulating different prefixes or different LAN prefixes in each and every site. And here’s an example, you can see LAN zero, LAN one.
2-3 In fact, in LAN three I’m showing two separate host devices connected through a layer to switch and this is going to be used for a destination, not use cases as I’ll discuss in a few videos in section in Part 2.
On the hub, we’ll have very similar topology with up to four hosts, LAN 012 and three just so it will be easier for us to emulate different use cases and and traffic patterns between hub and spoke or spoke to hub. And we’ll obviously going to have the same in Site 2 and Site 3 because these are going to be replicated sites.
So LAN 0 is going to be used as our distinct IPS in every site, including in Hub A. So for an example, you know these are slash 24 segments, but in site one, LAN 0 is going to be 10:01 which stands for site one the third octet.
.1254 is going to be our default gateway which is the IP on the spoke interface site 21002 site 31003 and on the hub the IP will be 10 zero 101 and again 254 is on the hub interface. Once we’ll get to the lab topology detailed topology, you’ll see the entire addresses in each and every interface.
Land one I’m going to be using to emulate a use case where I have overlapping IP in each and every site. So for an example site one I have 10168.1 dot one this this host and I have the same IP in site 2-3 and so on. On the hub side there’s a 1192 one 68100.1 so obviously when spokes land one on the spoke side.
Will be communicating sending traffic towards land one of hub A. We will need to source not on the spoke, so the return traffic will be returned to the right destination. So that’s going to be used to emulate or to show you how to configure source, not.
From the overlay network by the way, in this example here you don’t see the underlay network. Imagine the overlay VPN is in just a schematic that I included here, but actually it’s going to be an Ipsec tunnels that are connecting these spokes to the hub.
LAN two is where we’ll be showing A use case where we use static Nat. These are not overlapping Ip’s however there is any requirements as an example that every IP on the spoke side every host. As an example, if you take site one LAN 21020 dot 1.1, it would need to be statically Natted to a different IP 172.20.
Prefix because the 17220 is the only routable IP on the hub site, so similarly 10.20 dot 2.1 which is again different IP than site one would also need to be statically noted to a 17220 segment before it is sent using the overlay network to the hub.
And LAN three I’m going to be showing or using to show an overlapping AP use case where these Ip’s traffic from spoke to hub. For example 1030 zero one traffic is originated from host one LAN 3 on site 1 going to 17230.
Would need to be source noted, But on the other hand, when hub A LAN three would like to access or the region the originating traffic is actually from, Hub A would like to access each and every host on the spoke side. We would need to destination that on the spoke using a specific port.
To hit the right host on the spoke, which will dive in more details in the next few slides If you look just quickly on the underlay topology. So as we have discussed previously, there’s let’s say the example here we have two physical links in each and every spoke and on the hub.
And we have two ISPs. Obviously they might be connected between them if it’s an Internet connectivity, not necessarily MPLS private network. But I also included an emulation for a remote site. Let’s say that I have only one VM or host on 1721699.
That I’ll be using to show a destination not from the underlying network reaching one of the LAN segments on the hub. So this is a typical use case where you have some workloads or a web server that is deployed on the hub LAN side that you would like to have access from the Internet or from specific IPS.
So with that, see you in the next segment, where we’ll dive into more details behind each and every use case and traffic flow, and I’ll explain how to configure each one of these use cases.

P1:S2

Hi everyone, welcome back to our Mist AI Driven SD-WAN Configuration

Guides series. I’m a Solution

Architect here at Juniper on the Mist AI Driven Enterprise team

and this is going to going be Section 2 of Part 1 and in

this section we’ll discuss Source, Destination and Static

NAT Use Cases both from overlay and underlay in Hub and

Spoke environment. And with that let’s get started. So just to

recap from previous section my topology and setup, I have three

sites, Site-1,

2 and 3 is Spokes and Hub-A on single Hub, and in each

site I have five different segments or prefixes LAN 0, 1, 2, 3

and I’m going to be using those different segments or different

prefixes to describe different Use Cases for distinct IPs,

overlapping IPs where I do Source NAT and then obviously

Static NAT as well.

For bi-directional traffic between Spoke to Hub and then

some Use Cases for Destination NAT where we are going to be

accessing the Spoke hosts from the Hub.

So with that let’s look at the first Use Case which is our LAN-0

and in LAN-0, as we can see, we have distinct IPs, unique

IPs in each and every site. So Site-1 we have 10.0.1.1 and and

again these are a /24 prefixes. In my example 254 is

the IP on the Spoke. You’ll see this in a few in in in in

further few videos,

where I’ll discuss the lab Topology itself. So

10.0.1, 10.0.2 10.0.3, the third object stands for the site number and

the Hub is at 100, so 10.0.100 and in this case you know

it’s a simple communication between both Spoke to Hub and

Hub to Spoke.

So if Spoke wants to access the Hub 10.0.1.1, to 10.0.100.1,

it will send traffic without any NATing, neither Source or

Destination and similarly from Site-2 and Site 3 to the

Hub and again in the Mist UI or the way the intent model

configuration in Mist works.

I will be using one single template to onboard our Spoke

sites and we would need to define networks. In this case we

will define a Network called Spokes_LAN-0, but we will use

variables and the reason I’m going to use variables is

because there’s single template that applies to multiple sites

and as I mentioned I have chosen here in my address scheme. The

third octet would be the site number,

this is why I would have 10.0.1 10.0.2 and 10.0.3 and we can

also have the mask the prefix length to be variablized as

well because we would need to accept on the Hub traffic from

all Spokes which might be /16, which I’ll go over it once

we’ll dive in more details into the topology and how to

configure this.

LAN-1 is going to be our next Use Case where we will have

overlapping IP’s in each and every site. So if you look at

Site-1_LAN-1 it is 10.168.1.1 and I have the same

exact IP on all these 3 hosts in Site-2 and Site-3. So obviously

when Site-1 would need to communicate with or sending

traffic to

Hub-A_LAN-1, which is on one 192.168.100.1, we would need to

Source NAT this traffic before it leaves Site-1. So the

return path from Hub to the Spoke would know how to reach

the right destination. And in our Mist solution we have iBGP

running which are advertising all these networks to the Hub.

So the Hub would know the 192.168.1.1 network,

rather than we we rather than knowing who is 10.168.1 and this

is why we have Source NAT from Site-1. Similarly traffic that

is flowing from Site-2 and 3 towards the Hub we would

Source NAT at. But in this case we will use a different IP so

Site-2 traffic that leaves Site-2 will be Source NAT’d with

192.168.1.2.

And similarly Site-3 is .3, so the Hub actually sees three

unique IP’s .1, .2 and .3 and so the return path would know

how to get to the right site number or Spoke number. Again

we’ll be using variablized network definition which the the

last the 4th octet is actually correlates to the site number.

In my topology. So Site-3 is going to get to 192.168.1.3

and it’s going to be a /32 because you know, I’m I’m,

I’m going to be representing all these Spokes, all these hosts

that are behind a LAN-1 in each and every site. I’m going

to be representing them with a single /32 IP to the Hub.

LAN-2 is where we’re going to show or configure Static NAT. In

this example, the requirement is to have bi-directional

communication between the hosts in each and every site to the

Hub and vice versa from the Hub to each and every Spoke. So as

you can see here, the site has 10.20.1.1.

However, there is a requirement to staticly NAT this address

of the Spoke to be 172.20 prefix because as an example there are

many you know many instances where 10.20 or the address scheme

you have on the Spoke is maybe not routable or it is not

available on your Hub or Datacenter site.

So in this case when Site-1 for example LAN-2, this host

sends traffic to the Hub to Hub-2_LAN-2 ,to 172.20.100, it’s

going to be 1 to 1 NAT’d to 172.20.1.1. Again in my

scheme here the third octet represents the site number.

Similarly traffic that is going from Site-2 and Site-3.

We’re also going to be staticly NAT in it 1 to 1 from

10.20.2.1 to 172.20.2.1. This is, you know, just to

showcase that if you look at the Hub you have all unique IP’s

with all these hosts on each and every site.

That’s why we refer to it as a staticly NAT’d distinct IPs

and bi-directional communication between Spoke to Hub or the Hub

can access each and every of these hosts on the Spokes as

well. We’re going to define this network again in a variablized

fashion through Mist UI and the variable I’m going to be using

is site number which correlates to the third octet on my Spoke

sites.

LAN-3 is where we’re going to look at a more complex Use

Case of both Source and Destination NAT from Spoke to

Hub and Hub to Spoke. In this case, my topology shows up shows

as two different hosts in on LAN-3 , meaning the segment is

10.30.0.

/24, but then imagine you may have obviously multiple

hosts on the same on the same segment. As you know for example

there are all connected through a LAN switch, a layer to switch

into the Spoke which is going to be our SD-WAN device. So for that

say we have 10.30.0.1 wants to send traffic towards Hub-A_LAN-3

towards 172.30.0.1. In this case we’re going to use Source NAT

as we showed previously, we’re going to be Source NATing,

everything that is coming from this LAN-3 segment. We’re going

to Source NAT 10.30 to 172.30 and similarly if we look at Site-2.

Site-2 would also going to be sending traffic and Site-3 and

similarly we’re going to be Source NATing to a different

unique IP .2 and .3. And then these three IPs representing the

sites, well, the segment LAN-3 on each site they’re going to be

advertised via overlay iBGP to the Hub so the Hub would know

how to get back

to each and every Spoke and then the Spoke would Source NAT, I

mean the other way around right now the other way around is

where the Hub, a LAN-3 would want to access each one of these

six hosts two in each site. And as you can see, obviously these

hosts are overlapping IP in each site. I have the same IP 10.30.0.1

10.30.0.1, 10.30.0.1, 0.2.

So how would we do that? So assume we have, let’s say we

want to have an SSH session from Hub-A_LAN 3, from this Hub

originated from Hub-A_LAN-3 and this SSH session would want

to go and SSH to each one of these hosts in Site-1.

So the way this is going to be done is we’re going to be SSHing

to 172.30.0.1 which is the single IP represents site 1, the whole

prefix and based on the port number we’re going to then

Destination NAT the traffic into a specific host on each

site. So essentially in this device the Spoke SD-WAN

device,

there is a Destination NAT that is going to happen and translate

the packet that is coming from Hub-A into Hub-1 and Hub 2.

This is why here you can see the SSH session will go to 172.30.0.1

on port 2201 and it would actually be translated to 10.30.0.1

port 22 and if you SSH to 2202 meaning the second host

it’s going to be translated to 10.30.0.2 again on on port

22. Similarly just to illustrate, if you send traffic

to each one of these hosts on Site-2 and Site-3, the only

difference really is that the SSH will go the destination address

is going to be different 172.30.0.2 instead of 0.1.

And 0.3 instead of 0.2, which represents the outer IP of each

site. And again just to illustrate, how would you

configure different ports as an example if you also have HTTPS

traffic that would need to access from the same Hub-A_LAN-3,

HTTPS server that is actually running in each one of these

sites, so the only difference is the port number and these are

pretty flexible. In this case I’ve chosen to use 443 for HTTPS

and then 1,2,3,4 which will send the traffic to a different host.

So if you open your browser in Hub-A_LAN-3

and you would try and reach 172.30.0.1 4431, you would need to

land on a page which will show us that we are in Site-1_LAN-3

, Host-1. Similarly if we open a page to 4432 on the same

IP we will LAN on Site-1_LAN-3. So hope this makes

sense.

Okay, and the last Use Case we would want to show is where we

have a remote site and we only going to be focusing on the

underlay topology here. Let’s say the underlay network, but

essentially there’s a remote site that would want to access

some workloads or resources in your that are deployed on the

LAN side of your Hub and since the Hub has

Static IP’s on the WAN interfaces. In this case you know the IP of

WAN-0 is going to be 10.100.0.2 and IP of the second interface

of the Hub WAN-1 is going to be 10.100.1.2. This site if you have

remote site sitting somewhere on the Internet would want to

access some workloads in Hub-A LAN-0,

you would open your browser here and type say 10.100.0.2

which is the public IP or the outer IP of the Hub. Obviously

this is a lab environment so this IP is not a public IP, but

it’s a private IP but it’s emulating

a real topology where these these IP’s might be public

public IP’s on the Hub. So essentially if you open a

browser and try to access 10.100.0.2 or 10.100.1.2 you would

essentially going to be destination translating the

packet from on this Hub

to reach Hub-A_LAN-0, so that’s the Use Case of Destination NAT,

but not from the overlay as we have seen in previous case but

from the underlay.

So with that, I’ll see you in the next segment where we’ll

dive into the lab topology and detail addressing and how this

whole Use Cases are being emulated and configured. Thanks

for watching.

P1:S3

Hi everyone, welcome back to our Mist AI Driven SD-WAN

Configuration Guides series. I am a

Solution Architect here at Juniper on the Mist AI Driven

Enterprise team and this is going to be Section 3 of part

1.

This is where I’ll dive into the lab setup itself, that I have

created to showcase all the previous Use Cases that I’ve

covered in Section 2 and 1. If you haven’t watched those,

please go back and watch Section 2 and Section 1 for more

details. With that, let’s get going.

So again quick recap, this is a high level schematics logical

topology of three Spokes and two Hubs. These are – this is

basically going to be your typical Hub and Spoke network

for any Enterprise network where you will have two ISPs.

You have underlay links that are connecting those Spokes in each

site as well as in on the Hub and then an overlay network,

which in the SRX case is created by using an IPSec tunnels in an

auto VPN fashion.

This is the slide that I’ve covered in Section 2, which is

basically showing then on each side including Hubs, I have up

to 3-4 different segments or LAN prefixes where I have two hosts

on LAN-3 to emulate Destination NAT and Source NAT. And again

please go back and watch Section 2 of part 1 because I am

describing in detail each one of the Use Cases and what we are

trying to achieve,

from an overlay perspective. Again the communication between

these LAN segments on the Spoke and to the Hub and the other

direction are going to be using the overlay IPSec network.

However, we also have a Use Case where we show an underlay

access. So as an example if you have a remote site here as we

described.

And this remote site would like to access HUB-A_LAN-0 from

the underlay. We’ll have a Use Case where we show a Destination

NAT on the Hub device for specific ports and specific

destinations. So let’s look at the lab topology that I have the

actual setup that I’ll be using for all these NAT Use Cases.

So the full I mean I actually have a full topology with Hub-A

and HUB-B. 2 Hubs and 3 Spokes as I have described and under

the Mist solution these Hubs can be used as primary and

secondary or ECMP or any other preferences of routing traffic

or steering traffic from different LAN segments on the

Spokes to the Hubs.

And obviously there might be even Datacenters that are

connected behind the Hub, but this is please watch the other

segments under the configuration for failover scenarios and how

these are going to be managed. And again, if we look at this

common topology, we’ll have each Spoke in a full topology with

two Hubs, each Spoke creates 2 IPSec tunnels

to each Hub using the first using WAN-0 and WAN-1. So I

have IPSec tunnels that are correlating to the different

underlay links to underlay links on each Spoke. But again for

these videos we are focusing on Use Cases around NAT, underlay

and overlay.

And I think it’s going to be easier for us to just describe

one Hub instead of two Hubs. So again, this is the simplified

topology. The only difference here is that I’m going to be

using one Hub and I also have this remote site. So if you look

at this drawing,

each site first of all I’m using vSRX’s as my devices but any

other SRX platform is supported as Mist WAN Edge as SD-WAN

devices. Please refer to the Datasheet on which devices are

actually supported. But most of the branch SRX devices are

supported under Mist solution. But for the lab environment I’m

going to be using virtualized SRX’s.

And each vSRX is connected using two physical links WAN-0 and WAN-1

. And these links are connected to two different

routers. In your topology it can be also a single router but

in this case, the only job for these ISP1 and ISP2 simple

router is routing between these segments, the segments of the

Spokes and the Hub.

The outside connectivity is going to be done through this

main firewall to the Internet. So obviously each Spoke or the

LAN segments that would want to access local breakout on the

Spoke to the Internet, they’re going to be going through this

main firewall.

Also on this main firewall I added this remote site that we

have discussed because I would want to show Use Case where the

remote site accessing Web server that is hosted here in HUB-A in

LAN-0 and in order for this host to access from the underlay

network it would go through this firewall either through ISP1 or

through ISP2 depending on failure scenarios and it will

then routed towards HUB-A WAN-0 or WAN-1 and destination NAT’d to

LAN-0. You can watch previous section in part one where I

described this in more detail. So for this example then each

Spoke since it has two

physical links it would use two IPSec tunnels or two IPSec

tunnels will be created from each Spoke to HUB-A. And so Hub-A

will maintain up to six IPSec tunnels to each and every Spoke.

These are going to be set up obviously by Mist automation

and using Auto VPN methodology.

So with that let’s just briefly look at the address scheme in

each site. The sites are actually replicated. There are I

mean few segments are having different IPs if they are

distinct IP prefixes. But in general LAN-0 as we have

discussed is 10.0.1.0 /24 segment.

The 3rd octet 1 stands for the site number. So site number one

is 10.0.1.0 and you know if you look at site #2, LAN-0 is

10.0.2.0 /24. .1 is going to be the interface on this VM. This

is a simple virtual machine host that will be sending traffic on

this LAN segment.

Obviously in real deployments there are going to be multiple

hosts, either through a layer 2 switch, that is not covered in

this example. .254 is the interface here on the Spoke

towards the LAN side.

We look at the LAN-1 segment. This is where I have overlapping

IPs in each and every site. But again 10.168.1 stands for LAN-1

and this is a /24 prefix as well just for the just for

simplicity reasons. And 254 is the interface on the Spoke.

LAN-2, it has distinct IPs. They’re going to be emulating

Static NAT as I’ve covered in the previous section, and again

this is a /24 and LAN-3 , I actually have two hosts

that are connected through a Layer 2 to switch, and the reason I’ve

chosen to go with two different hosts here, .1 and .2 is because

we would want to

use Destination NAT where traffic is going to be sent from

the Hub towards these two hosts. We’re going to Destination NAT

this traffic on the Spoke using different ports, but again LAN-3

is an overlapping IPs in each and every site. So LAN-3 in

Site-1, Host-1, Host-2 is the same as IP as Host-1 and

Host-2 in Site-2 and Site-3 and so on and so forth.

The remote site, again, this is emulating a site that is

actually accessing maybe from the underlay from the Internet,

trying to reach one of the workloads here on the LAN side

of the Hub. But again, since it’s a lab environment, this is

all inside, internally within the lab. I’m not using outside

actual public IPs

to access this. So this remote site again is on 172.16.99 /24, 24

Prefix .1 is this VM, 254 is on this firewall but again the

traffic is routable to the underlay physical links of the

Hub, WAN-0 or WAN-1.

So with that, I’ll see you in the next section, which is going

to be the first section of part one configuration and we will

start configuring Mist Sites, Templates, onboarding the first

Hub and Spoke and looking at IPSec tunnels that are being

built.

And then we’ll go each Use Case, one by one, and configure the

different networks and applications and so on. So see

you in the next video. Thanks for watching.

P2:s1

Hi everyone, welcome back to our Mist AI Driven SDwan Configuration

Guides series of videos. My name is Shay Donovich and I’m

Solution Architect here at Juniper on the Mist AI driven

Enterprise team.

And this is going to be Part 2 configuration. And in this

section which is Section 1, we’ll discuss sites one Edge

configuration templates, how do we create sites? How we

configure configuration templates which will allow us to

onboard devices, hubs and spokes based on the use cases we have

specified in part one.

If you haven’t watched part one, I encourage you to go back and

watch section one through three in part one. And with that let’s

get started. So if we look at this topology here, I just took

one slice of the example topology and use cases we have

described in part one.

So LAN-0 is going to be 1 segment here on the spoke on the

left, site one, LAN-0 and we would want this host to be

sending traffic and communicating with HUB-A, LAN-0 host in HUB-A obviously.

That we would need to onboard at least two devices just to start

with. As a simple example, hub and spoke one hub and 1 spoke

and then we will form an Ipsec tunnels 2 Ipsec tunnels from

spoke to hub which will use WAN-0 and WAN-1. Both of these

underlay links as we see here the hub.

Has a static IP 10.100.0.2 on one, 10.100.1.2 on

one, one and the spoke. Because you know mostly you would need

the hub to be on a static IP because in order to form the

Ipsec tunnels the spoke would need to initiate an Ipsec tunnel

through Natty towards the hub. So it would need to know on

which IP the hub, when links are reachable the underly links.

On the spoke though, we would use DHCP because these are going

to be the most common scenarios where you deploy spoke devices.

Again, in my lab here I’m using vSRXs.

And so step one is going to be creating a hub site and a spoke

site through the Mist UI Management console. And Step 2,

we’re going to create what we refer to a hub profile which

specifies some parameters on the Wan links and the other LAN

segments, etc.

And step three, we’re going to also need to create WAN edge

template. WAN edge template under Mist refers to a templates

that are applied on sites where you will deploy your spokes and

similarly to the one to the hub. We’ll need to configure hub

interfaces, select overlays to know which overlay we want to

spoke to use in order to connect to the hub.

So step one is site creation. As an example, we’re going to

create a site named Site-1 and really there as you will

see in a second, there’s going to be a lot of parameters you

can configure under Site in Mist, but the minimum you would

need is to set an address.

In this case I’ll use the Sunnyvale headquarters address

from my sides. You would also need to include a root password

and also you would need to enable or check the box of

saying yeah you do have license or license exist for WAN edge

application visibility. Application visibility is using

the up ID database.

On the SRX platforms, and it is required for not only

visibility, but also for steering traffic for SDwan

applications. Similarly we’ll define another site, we’ll name

it HUB-A to be correlating to what we have in our topologies

and again, just a quick root password as a minimum

configuration and application visibility.

So now let’s switch to the Mist UI and I’ll show you how to

configure this. So here we are logged into the Mist UI and I

assume you all have an account created. And in this case I have

created a demo organization named Mist Aid Live.

If you need to know how to create an organization, please

watch the other segments on creating accounts and

organizations. But really this is the default organization and

in this case it has one site and the site name is primary site.

If you go under Organization and then Site configuration you

would see that we have one site Primary site.

You can either use this site or we can go ahead and create

additional sites. In any case, we would need to create

additional sites for our topology because as you recall

we have three sites and one hub, so it’s a minimum of four sites.

So we’ll go ahead and create newly sites and I’ll also show

you how to delete a site if we don’t want to use our primary

site. So to create a site you click on Create site.

And you give it a name. In our case we name the site Dash_1.

It doesn’t really matter what the name you would refer to, you

would put an address. And again as a minimum we would need to go

ahead and include root password so we can always know which

password Mist would use in order to set the root password

on your devices, on the WAN edge devices.

So I will include a password here and also it is advisable to

approve or click the box of saying yeah there is a license

or I have a license on my SRX devices for application ID or

Uptrack license and once you are happy with the settings you

click on save and the site is created.

By the way, since we’re not going to be using primary site,

just for the sake of simplicity, we’ll go ahead and delete the

site. In order to delete the site you would need to type the

name of the site and then you can click on delete. So in this

case we would have then one site. In order to create an

additional site, you can either go ahead and click on Create

Site in order to create your hub or you can select your site and

say Clone site.

And if you clone site, all the parameters from the previous

created site will be cloned. The only thing you would need to use

is to put the site name which is HUB-A and the address of our

site and as you can see here this settings that we had on

site one.

Is already included and also our root password for the one edge

devices is included as well. By the way, you can have a separate

password for the switch for wired devices or switching EX

platforms, but that’s a different segment, different

video. So click on save and we can see that we have two sites

created. We can make sure maybe HUB-A would be our first site,

so you can sort it by whichever way you’d like.

To sort here okay so next what we need to do is to create our

hub profile and spoke profile with the minimum parameters that

will require to onboard the hub and create this overlay

connectivity so.

Here is how HUB profile would look like, just the bare minimum

without specifically connecting any LAN devices at this point.

The reason I’m showing you this is because I want to go step by

step and then add to the profile as we go, so we would define the

interface name.

We call it WAN-0, but really you can choose whatever name you’d

like, DSL, LTE, you know, MPLS, inet, whichever you want. I

mean, I’m choosing to refer to the interfaces by the, you know,

10.1.1, or if I have more interfaces 1213 etc. So

interface name then the interface itself. The first

interface I’ll be using on my VSRX access is ge-0/0/0.

The IP address this is a /24 in my lab here, so 10.100.0.2 stands for WAN-0. The third octet is going to be

on the hub and then my gateway IP on this interface of this

ISP-1 router is 10.100.0.1. Similarly WAN-1 it’s going to be

ge-0/0/1. Specify the interface and you know very similar IP.

The only thing is the third octet is referencing in my lab

to show 1.1 and so it’s 10.100.1 and let’s switch to the Mist UI

and we’ll show you how to configure the hub profile so if

we click under Organization, we can see we can navigate to hub

profile’s page.

We have no HUB profils listed here because we have not created

yet HUB profile. Just know that although it says beta here HUB

profile is a fully released feature GA part of our solution.

Sometimes within Mist we see beta tag for specific features

or capabilities that are not yet fully released. So inside HUB

profile will have something I’ll show you in the next slides.

That is not yet released. This is why you would see a beta tag

from the upper level navigation. But a hub profile is a fully

released features. So if we click on Create profile, we’ll

be prompt to give our profile a name. I’ll just name it as we

named the hub and you click on create.

And as I mentioned, there’s many parameters here that we’ll be

configuring as we go. But as a minimum, in order to have a site

onboarded and a hub device onboarded, you would need to

configure your WAN interfaces, WAN interfaces and here’s what I

mentioned, we have a feature that is Secure Edge Connect,

which is essentially.

Part of our SASY solution that I’ll cover in a different

video, but for now to create WAN-1 interface we would go and click

on Add WAN interface and we’ll be prompt to enter our details

from the previous slide.

Okay. So just so it would be easier for us to follow, I’ve

placed the different parameters as we mentioned for Wan

interfaces on the right hand side here. So the first thing is

we want to give it a name. As I mentioned, I’m using WAN-0

and WAN1 for the different interfaces. You’ll have an

option here to define what type of interface it is if you’re

using DSL.

Or even LTE but for now I will go with the straight simple

Ethernet interfaces and in my hub vSRX ge-0/0/0 is for WAN-0 and the IP

address is going to be 10.100.0.2 and it is a /24

segment and the gateway as I mentioned is 100.0.1.

There are other options here that we’ll cover in a second in

a different video on source, not pool or interface, but for now

we can just click on Add and we could see the new interface WAN-0

has been added to the list. We’ll go ahead similarly and add

the second interface.

It’s gonna be ge-0/0/1 and at this point we have the two

interfaces. And again, as I mentioned, that’s the minimum

configuration you would need in order to onboard a hub into

Mist solution. So click on save.

And if you go back to your hub profile list, you can see that

we have hub_A which is our first hub profile. At this point we

have not yet assigned any devices to this hub profile

because we have not onboarded any devices. But I’ll show you

in the next video how you onboard a device and assign it

to a specific site and assign a specific hub profile to it.

Okay. So next thing we need to do is to create our spoke

profile so we can we’ll be able to onboard the spoke device as

well a spoke profile under Mist UI, it is referred WAN

edge templates. The reason is WAN edge, it’s the overall.

Solution for Mist for WAN edge devices because we can have

either hub and spoke profiles or stand alone. So the general

reference to when devices we name them one edge templates or

one edge profiles. So very similar here WAN-0 is going to be

ge-0/0/0 and 1.1 is going to be ge-0/0/1 and.

The only difference is for spokes. As I’ve mentioned it’s

going to be DHCP because these ISP-1 and ISP-2 routers in my

lab. But there are also DHCP servers, so there will be a list

list IPs for all my spokes in the lab, and again for the hub

spoke profile we’ll associate an overlay endpoint.

Which essentially will allow Mist to create overlay Ipsec

tunnels from WAN-0 to WAN-1 on the hub. So as you can see

here in the picture we have two overlay tunnels 2 Ipsec overlay

tunnels Okay. So next we’ll create a Spoke template that

will be able to onboard a spoke device and associate to this

hub. So if we click under organization under our WAN

options here.

You can see the last one is WAN edge templates. Click on WAN

edge templates and similarly to HUB profiles we have no WAN edge

templates created yet. So I would click on create a template

and we can give it a name.

And then the reason I’m using the name spokes is because you

will see next that I’m also going to be I’m actually going

to be using one single template to onboard multiple spokes.

That’s the power of Mist automation that we use one

template and different variables in order to associate a template

with multiple sites.

And in this case we obviously need to select spoke because we

are creating WAN edge template that will be associated with a

spoke device that is connecting to hubs the standalone as I

mentioned. If you want to manage a standalone WAN edge router

security device under your sites, click on create.

And here is the spoke or WAN edge template profile. Again,

there are many parameters here that will need to be defined,

but for now just for simplicity reasons, I’ll just go ahead and

add only the one interfaces as we did with the hub profiles.

Click on add WAN, so WAN-0. We give it a name and similarly to.

What I had on the hub Profile ge-0/0/0 is going to be associated

with my WAN-0 interface and in this case as we mentioned

it’s going to be DHCP and here’s where we would need to click on

Add overlay hub endpoints and we would associate the WAN-0 on

the spoke with.

HUB_A-WAN-0 interface. So essentially it’s basically

saying an Ipsec tunnel will be created between WAN interface on

the spoke to WAN-0 interface on the hub. Click on add and you can

see the first interface created. The same goes for the second

interface.

And for ge-0/0/1 which is our WAN-1 interface, we click on Add

overlay hub endpoints and we will associate the hub endpoints

with HUB_A-WAN-1, click on add and as we can see we have our

two Wan interfaces WAN-0 and WAN-1 and we can go ahead and

click on save, go back to our WAN edge template lists we can

see that we have one.

WAN edge template created. No sites are yet associated with

this template. Once we’re on board sites, I’ll show you how

to associate a site A device to a template Okay. So next we’ll

onboard our hub device and the spoke assign the templates and

we’ll check connectivity and with that see you in the next

segment. Thanks for watching.

P2:S2

Hi everyone, welcome back to our Mist AI Driven SD Wan

Configuration Guides series of videos. My name is Shay Dunevich

and I’m a solution Architect here at Juniper on the Mist AI

Driven Enterprise team and this is going to be Section 2 of Part

2, our configuration guides.

In this section we’ll look into device onboarding. How do we

onboard spoke and hub devices, associate them to sites and

apply configuration templates onto these devices. And with

that, let’s get going. So in the previous section we have created

two sites, Hub-A and Site-1.

And we also created a Hub Profile and a spokes configuration

template. And in this section as I mentioned, we’ll look into how

we onboard devices. So under Mist there are two options to

onboard device, you could either have a short configuration

snippet that is committed onto a device or a full ZTP (Zero Touch

Provisioning), which is using a call home server.

In this case, since I’m using vSRX’s in my lab, a vSRX (Virtual

SRX) device doesn’t come with a claim code out-of-the-box and so

if you are utilizing vSRX’s for your lab setups, the best way is

to have a simple base config and have a short few lines of

configuration snippet to be committed on these

devices, as I’ll show you in the next few slides. So the first

thing that I did with my vSRX is basically make sure that each

vSRX, be it a hub or a spoke, will be able to have

connectivity to the Internet in order to reach Mist cloud

and Mist managed servers. And for that really all you need is

have at least one interface. In this case I’m using ge-0/0/0 as my WAN0

and it has a DHCP. You also would need the configuration

zone that this interface is attached to. In my case I’ll

show you I have WAN0 as my single zone.

And since the device will be reached to Mist cloud using

FQDNs, then you would need the DNS name server configured. And

also it’s very beneficial or advisable to have an NTP which

makes sure that you have your time and date synchronized as

well. So I’m using in my lab I just timed@google.com as my NTP

server, but if you have a local NTP servers you can use them as

well.

And obviously root password just to make sure that we can commit

configuration on this device. So looking at the config, really

this is how it looks from JUNOS perspective. The first line is

just making sure I know which device I’m dealing with. So I’m

setting the host name and then the root password as I mentioned

name server. I’m using 8.8.8.8 and then ntp.

And then this single zone with one interface attached and a

DHCP. Similarly for the hub device. Really there’s no much

difference. The only difference is our hub devices using static

IPs and so on. ge-0/0/0, I have a static IP configured which again

pointing to 10.100.0.2 as my WAN0 interface.

And then also have a static route which is pointing my

default route to the next hop which is my ISP1 router. Again,

once this device is on boarded and assigned to the Hub Profile

that we have configured previously, then WAN1 will

be or the entire configuration will be pushed to the device

including the second interface.

So again, the point here is we need the bare minimum

configuration on the device in order for the device to reach

Mist cloud. One note here for the SRX platforms, not the non

virtual platforms. The default config that you have on the

device already comes with the right configuration for you to

make sure you’ll be able to onboard this.

Via the ZTP Zero touch provisioning process. And please watch my

second video that will show you how to ZTP SRX platforms, branch

SRX platform devices including claim code and then the default

config that the device has out-of-the-box. Okay. So let’s

quickly look at our devices that I have in this lab.

Here’s Hub-A, I have a few vSRX’s deployed on the server and as I

mentioned if you look on this device the configuration, the

bare minimum configuration that we have is actually pointing

out. I’m using version 21.2, host name and we can root

password and you can check connectivity to make sure you

have connectivity to the Internet.

And also we can check to make sure we have the right DNS

resolution as well and we can ping. We can resolve any FQDN.

And this is our hub. So if we look at our interfaces as I

mentioned, we have ge-0/0/0 which is 10.100.0.2 and your routes.

Is actually your default is pointing to 10.100.0.1. And

just a quick note on licensing, if you’re using vSRX’s you need

to make sure that you have the appropriate license at least,

IDP at least, AppID sig as a minimum in order to use the

steering profiles in the next segment.

Okay. So once we have our base config on the vSRX devices,

we’re ready to onboard the devices onto the Mist cloud. And

really the process is pretty simple. If we would go under

Inventories that I’ll show you in a second, there’s an option

to click on adopt device and there’s going to be a short

config snippet be generated specifically for your

organization.

And this config should be copied and transferred and committed on

the vSRX device. So let’s switch to Mist UI and we’ll copy this

config. So under Organizations we can click on Inventory.

And under WAN Edge devices we have no device currently on

boarded and we’re looking at the entire org. So here in the top

right hand corner there’s a button called Adopt WAN Edge

devices and as you can see there is a short config

that is being generated, we can copy it to our clipboard and

switch to the vSRX CLI and commit this config on the

device. So back to our hub device we can go into

configuration mode and just copy paste the config and we can

commit the config and quit. Also,

you can check on system connections. Basically this

config is creating an outbound SSH to the Mist Cloud

so you can look at on port 2200 and you can see there’s a

connection established into Mist Cloud. Okay, so the next step in

onboarding our device as you can see we would go to our Mist

inventory page

and refresh the page and we would see the Hub device appears

under Inventory and it would be showing as an unassigned until

we will assign it to a specific site. In this case, the Hub

would be assigned to Hub-A site name that we have created

previously. So let’s switch to the Mist UI. Switching back to

Mist, we can now refresh the page

of the inventory and we can see our device is now showing up as

unassigned and next we would need to go ahead and assign it

to a site and specifically assign then the hub profile

since this is our hub device.

So we can go ahead and select this device and here under More

there’s an option to assign this device to a site. Click on

Assign this device to a site and we can select our site which is

again going to be Hub-A.

And here you have a few options. You can either select Manage

configuration with Mist which means Mist will take whatever

the configuration you have on your hub profile or WAN Edge

template and will override the config on the device. Or you can

have it unselected if you just want to monitor the devices with

Mist AI. And also there are three options here as far as

which settings applying to licenses you would want to use.

As you recall under site we have configured that we have licenses

on the device. So I would go by the site configuration or either

you can select this specific device has license, we’ll keep

it as use site settings for app track licenses and we will go

ahead and click on assign to site and the message appears

saying the device has been assigned to a site.

Okay. So once the device has been assigned to a site, we

would need to go into the site, click on the site name and we

would need to associate a hub profile with this device that

has been assigned to this site. Okay. So if we select the device

from our inventory list, the one that we just onboarded.

It would take us directly to the site itself or shows the device

page. You can also navigate to the site and devices. Sites are

under WAN Edges so if you click on WAN Edges you can see a list

of sites. You can either select your site from here. We have

nothing on site 1 yet in site 1 yet because this is going to be

our spoke device.

But Hub-A we have this device which is on boarded and if we

click on the device we can see this is our vSRX. There are a

few interfaces that are connected on my server to

different bridges. However we have not yet enabled

configuration by Mist. This is why this is grayed out and we

need also to associate the Hub profile with this site.

So to do that we would need to select our Hub profile. This is

a list of all hub profiles you have configured. Obviously we

have only one. So we will select Hub_A as our device

profile and we would go ahead and enable configuration by

Mist and we also have a name here and we can go ahead and

click on Save.

Once we clicked on Save and we go back to our device, we would

see that there’s immediately config being pushed to the

device and Mist does config, commit, commit/confirm

so, if something happens, it will be able to roll back to config.

So you can see the config is being committed on the device.

And we can look at our interfaces. We can see that we

already have the second interface we have configured

which is 10.100.1.2. And also if we look at the route table we can

see that we have two default through WAN-0 and WAN-1 and

also a few routing instances that we will explore in the next

segment including the overlay routing instance where we have

the Ipsec.

Tunnels configured from. If we take a look at our Ipsec tunnel,

we can see that we have no Ipsec tunnels yet because we have not

yet onboarded our SPOKE device. So let’s go ahead and onboard

the Spoke device as well. Okay, similarly to our hub device,

let’s take a look at our Spoke device.

Here’s the Spoke device we have here. If we look at our

configuration, we have a very similar configuration. The

interface here, as I mentioned, is in DHCP. If we look at our

routing table, we have our routing table according to our

lab address scheme which is 10.1 for Site-1 0.2 and the default is

pointing to 10.1.0.1 which is our ISP1 router.

Also checking connectivity to make sure I have connectivity

and we can then go ahead and do a similar process to the Hub

profile and get the config from the Inventory page on Mist

Okay. So if we look at our Inventory page, we see our hub

device showing up under the inventory list.

And we’ll go ahead and onboard our Spoke device as well. So

clicking on Adopt WAN Edge devices and the same process,

I’m copying the config snippet to my clipboard. Back to my spoke

device. We need to in configuration mode, copying the config and

committing the config on the device. Once the config is

committed, we can

refresh the page and we should see the Spoke device showing up

as unassigned and similarly to the Hub device we would need to

assign the Spoke, first to a site. So I will select the spoke

device under More assigned to Site and I will select SITE-1

as the site for this spoke device. So clicking on Assign to

Site.

A message saying the device has been assigned and you can either

click on the device from the inventory list again or go to WAN

Edge devices, select your site which is SITE-1 and you would

click on the device and here’s the Spoke device. Since it is

just being assigned the device takes a few minutes to show up

under the site.

We can go to the Spoke device. We can see that the connection

to Mist has been already established. So we should also

go ahead and enable config management by Mist. Similarly to

what we have done for the Hub device. We can click on Save

and

here is the Spoke device shows up. Again I have multiple

interfaces that are connected but at this point we have not

yet assigned the template to the Spoke. So to assign the WAN Edge

template to the Spoke. You can either click on this link which

says None (Configure) right and it will take you to the WAN Edge

template configuration

and in this WAN Edge template configuration you can see that

there are zero sites or zero devices that are attached to

this configuration template. You can click on Assign sites and

you’ll have to select which site you would like to

assign this configuration WAN Edge template to. So in this

case I will select SITE-1

as this is my Spoke site and the configuration that we are, the

template that we are referring to here is the WAN Edge template

which are assigned to spokes. So clicking on apply and you can

see that there’s one site and inside this one site called SITE-1

we have one WAN Edge device. So if you go back to WAN Edges and we

can see that in this site SITE-1.

We have a WAN edge device that we have named SITE-1 as well. If

you switch to HUB-A you can see that we have HUB-A and other WAN

Edge device and HUB-A. So back to SITE-1. Here’s our spoke

and everything looks good here. So if we look at our device we

can see that immediately as we have assigned the spoke

template.

There is config being pushed to the device to our spoke device.

If we look at our interfaces we can see that we already see the

second interface which is 10.1.1.2. Also in this point the spoke

should be forming 2 Ipsec tunnels to our Hub. So if we

list our Ike tunnels and IPSec tunnels. We can see we have two

tunnels already up, one is going to 10.100.0.2 WAN0 of

our Hub and 10.100.1.2, which is WAN1 of our hub. Similarly

we can we can look at IPSec tunnels

and we can see that we have two IPSec tunnels, 1 to each

direction on port 4500 established to the hub as well.

If we go back to our Spoke site we can click on WAN Edge

insights

and you can also see the overlay tunnels shows up here in the

Peer IP is 10.100.0.2, which is our Hub. We also see that we

have BGP/iBGP session established to the hub. This is

how in our solution we exchange routes between Hub and Spokes.

So this is shows up here and there are other parameters that

we can see here which we’ll dive into in a different video. So at

this point we have established onboarded these two devices

Spoke and Hub and also as we have seen we have our overlay tunnels

established already so.

Next we’re gonna go ahead and connect two LAN segments

emulated by two hosts, one on the Spoke, the other one on the

Hub as our LAN-0. And we’ll configure Steering profiles and

also security policies so we’ll have networks and applications

and so we can exchange

traffic between this spoke to hub LAN side. So with that I’ll

see you in the next segment and thanks for watching.

P2:S3

Hi everyone and welcome back to our Mist AI Driven SD Wan

Configuration Guide series of videos. My name is Shay Donovich

and I’m a solution Architect here at Juniper on the Mist AI

Driven Enterprise team and this is going to be our Section 3 of

Part 2.

LAN networks and applications. If you haven’t watched the

previous sections in Part 2 or part one, I highly encourage you

to go back and watch the other parts and sections as each one

is actually building on top of each other.

So in this section, we’ll be looking at creating networks and

applications and how do we associate networks LAN segments

with the hub and spokes and then how do we create applications

and custom applications in order to set our steering profiles and

security policies between spoke and hub. And with that, let’s

get started.

So just a quick recap on where we left on previous sections. We

have created two sites, one for our spoke site, one and the

other one for HUB-A which is our hub site and we also created

configuration templates, WAN edge template for spokes and then hub

profiles that are associated to Hub-A.

We then onboarded 2 devices in my lab. I’m using vSRX’s so we

have onboarded the hub vSRX and a spoke vSRX and assigned them

to specific sites. And then we also applied the configuration

templates and associated them with both the spoke and the hub.

And the configuration templates were pretty simple, just

configuring the Wan interfaces on the spoke and on the hub.

And after the config has been applied, we could see that we

have two Ipsec tunnels which are related as our VPN overlay

network overlay tunnels established between the spoke

and the hub. And next we would want to go ahead and create the

LAN segments.

So in order to add 2 LAN segments or two hosts, one on

the spoke side and one on the hub side, this is our first use

case LAN-0 where we have distinct IPs on each side and

also on the hub we would need to 1st create networks and

applications.

And really networks and applications. This is how the

Mist intent model is actually working. Everything is driven by

the networks as a source and applications as destinations,

and then different policies and steering profiles that can be

applied for both directions under Mist UI. So as an

example, if we would want to have site one LAN-0.

10.0.1.0 network communicate with hub a LAN-0 which is 10110 zero

10.0.100.0/24. We would need to create a network that is

called sites LAN-0 or spokes LAN-0. And then we would need

to create an application that is a custom app at this point

because it you know their application can be also referred

to our layer 7 application like you know Zoom Office 365

etcetera.

But in this case, the application can also be defined

as a prefix or as a LAN segment. Also, when HUB-A would want to

send traffic to site One LAN-0, we would need to create a

network for Hub-A, attach this network to the hub on ge-0/0/3 and

then also create an application which will be referred to as

Spokes LAN-0 or Site-1 LAN-0.

That will be able to allow traffic from a hub to spoke. So

in this case again as I mentioned, what we will do is on

the spoke we’re going to create a network called site one LAN-0

and it would be then used in order to allow traffic

flowing to HUB_A_LAN-0.

And then on the spoke, on the spoke template we would also

need to accept traffic that is coming from a network called

HUB-A_LAN-0 going to an application which is site one

LAN-0, right? So in other words, the config is going to be

applied to this device using the configuration templates. We’ll

all would need to have policies created to send traffic and

accept traffic.

From network to applications and from network very similarly if

we look on the hub, the same network that is used on the

spoke to accept traffic to the same application would need to

be configured on the hub in order to accept traffic from

this network. Site one LAN-0 that is going to an application

called HUB-A_LAN-0.

And similarly, we would need to allow traffic from LAN-0 on

the hub going to the same application SITE-1_ LAN-0

on the spoke. If you really take a closer look, these are the

same directions and using the same networks and applications,

so please just remember this, I’ll show you.

In the next video on how we create policies and how we can

actually create one time the policy and then it will be

associated with both the spoke and the hub Okay. So the first

thing we need to do is we need to create then a network LAN-0.

And as mentioned, LAN-0, it’s actually two separate networks.

First, we have a network that instead of calling it SITE-1_

LAN-0, I’ll call it SPOKEs_LAN-0 and you will see why

because again we would have one single template that we named it

Spokes and this template would actually be assigned to multiple

sites. We will discuss this in a future video.

But in general, the network that I’ll be adding, I’ll call it

Spokes_LAN-0 and then this is a pretty simple for now

configuration of this network. It only specifying the subnet of

this network, meaning the prefix and the prefix length. And also

we will allow advertise via overlay. In other words, this

network when it will be applied and configured on the spoke it

will be advertised.

Towards the hub. So the hub side would know how to reach this

network. Very similarly, we would create an additional

network. The second network would be called a HUB-A_LAN-0

, and this network again would only have a prefix. In

this case it’s going to be 10.0.100 because our hub is

always associated with 100 as a third or second octet.

And again we will select the option to advertise this network

to overlay Okay. So let’s go ahead and configure our two

networks as we have defined. You will see the inventory again, we

have our Hub-A and site one and if we navigate under

organizations, we could see we have an option here to create

networks. So clicking on networks.

Will take us to the page where we will see the list of

networks. We have not yet created any networks so This is

why it doesn’t show any networks and so create a network. We can

click on add networks and the first thing you would need to do

is to give it a name. So first network I’ll create is my HUB-A_LAN-0 and as we.

Mentioned we want to create a /24 10.0.100.0 segment

or prefix and we would select advertise via overlay access to

Mist cloud. This is also an option if you have any other

devices connected to this network on the LAN side such as

Mist AP’s or EX switching devices.

You would want to have this option selected so the correct

policy will be pushed into our secure as the one device in

order to allow traffic towards the Mist Cloud so we can onboard

other devices. So this is where access to Mist Cloud is used for

and for now let’s click on add.

And as we can see the first network was added HUB-A_LAN-0,

which is going to be our LAN-0 on the hub. So similarly we

can create a spoke LAN-0 network Clicking on add networks

we call it SPOKEs_LAN-0 and the prefix would be 10.0.1.0

/24 Again, for now that prefix would only be able to be

applied on site one. And in the future videos once we discussed

variables and how you configure variables and how you use

variables, we’ll change this to a variable that will associate

with then multiple sites using one single template. But for now

we also click on Advertise via overlay.

And at this point we would not want to override whatever is

being advertised because we want the spoke to advertise 10.0.1.0/24 to all other spokes and hubs. So you know if there’s a

traffic from hub obviously need to go to the spoke, it would

need to know it would have a route towards this network going

through the overlay to the spoke. So advertise via overlay

is being used so you can save.

And we can see our two networks have been created here. As we

discussed, we also need applications to be configured or

defined in order for traffic to flow from hub to spoke and spoke

to hub. So then the first application will create, we’ll

name it spokes_LAN-0.

And this application would only just be a custom app, another

layer 7 app and the custom application. For now we will

define it as a as a simple prefix 10.0.1.0 /24, which is

essentially the prefix the LAN-0 on the spoke. And again in

a very similar manner, we’ll define HUB-A_LAN-0 application,

so when traffic is going to be sent from spoke to hub.

We’ll use this applications as our destination and the IP

prefix is very similar to the network, it’s just 10.0.100.0/24 and we’ll see how we apply these networks and applications

in the next video.

Okay. So next we’re going to configure our SPOKE WAN Edge

template and hub profile to add the LAN networks we just

created. So for the network, for the LAN-0 network on the

SPOKE.

We’re going to use a DHCP server and basically as I have in my

topology here, the IP of the interface of the spoke towards

the LAN. It’s going to be ge-0/0/2 and the IP is going to be

10.0.1.254 and then we’re going to have a DHCP server.

That on the start IP can be then .1 and let’s say we configure 10

IPs for this DHCP server and the minimum we would need to specify

is the gateway on the IP on the DHCP and also a DNS server very

similar.

To the spoke on the hub profile we’re going to attach the, we’re

going to attach the hub a LAN-0 network interface ge-0/0/3 and

the IP address is going to be 10.0.100.254 and again I’ll

attach a DHCP server here as well. So the host that we will

connect to this interface.

HUB-A_LAN-0 host and site one LAN-0 host. They’ll be able

to get an IP from a DHCP server deployed in the vSRX okay. So

now let’s go ahead and attach these two networks as discussed

to our hub and to spoke in site one.

So if I navigate back to my hub profiles, here’s my hub profile

that we have created in the previous segment. Click on hub

profile and we can see here that we have our 2 WAN interfaces, WAN-0

and WAN-1 and under LAN we don’t have any LAN interface

attached yet. So in order to attach a LAN interface you can

click on Add LAN.

And the first thing we would need to do is to select our

network. So here we have our two networks that we previously

created. I will select HUB-A_LAN-0 and our interface is going

to be ge-0/0/3. And we have different options here for port

aggregation, LAG and redundancy, but that’s going to be covered

in a different video.

And we will select this interface to be an untagged VLAN

or untagged interface. It can also be a trunk if it’s going to

let’s say a switch or an EX switch that is connected on the

one side. But for now this is a simple example where we have a

single host here LAN-0, so we will select untagged.

And the IP interface, the IP address of that specific

interface just for simplicity help reason, it would actually

shows you what is the subnet of the network that you have

selected. But the interface is going to be 254 prefix is 24 and

we also decided that we will deploy a server a DCP server.

Onto this interface, So start IP would be .1 and let’s say

we’re going to assign 10 IPs and the gateway here gateway for

this host is going to be the LAN interface here of the hub. So

it’s 254 and we’ll provide just a simple one DNS server or you

can provide multiple DNS servers as well.

And once you’re happy with this you click on Add and then we can

see the first LAN segment on interface ge-0/0/3 has been created

and for now we can just click save on this hub profile and

once we click on save this configuration by Mist

instantly will be pushed to the device.

And if we can go to the device we can see that this ge-0/0/3

interface was created. So here is our HUB-A device. If we list

our configuration interfaces we can see our ge-0/0/0 interface ge-0/0/1

and here is ge-0/0/3 interface having 10.0.100.254 as

the interface AP.

So next we’re going to navigate to our spoke one edge template

and we will configure and attach the LAN-0 on the spokes as

well. So clicking on spokes template which is again attached

to one site or site one and one device and similarly to the hub

at this point we just have WAN-0 and WAN-1 and the overlay

Ipsec tunnels.

As we have previously configured and under LAN, here is where we

can click on add LAN to add the LAN segment and so the first

thing we would need to do is to select our network. Here’s the

SPOKEs_LAN-0 network and the interface on the spoke is ge-0/0/2

as I see it listed here.

ge-0/0/2 and again we covered the port aggregation and other

options in different videos and here similarly to the hub, it’s

going to be untagged and the IP address is showing up here as

the network subnet and the IP is 254 because that’s the interface

IP and /24 segment.

And also we’ll add a DHCP server here as well. So that’s going to

be starting .1 10 addresses and the gateway is 254 and I will

configure DNS server here as well and once I’m done with

that, I can click on add and here we can see the first LAN

segment was created as well on the spoke.

And we can click on save and once this configuration has been

saved on this template, since the template is already applied

to the site, the config will be pushed to the device as well.

And so if we quickly switch to the device, we can see here’s

SITE-1 which is our spoke device and we list our

interfaces, we could see ge-0/0/1 and then.

Here is ge-0/0/2 which is our LAN-0 interface. 10.0.1.254 has been

already configured on the device okay. So as we have discussed

after creating the networks and attach those LAN-0 networks

to both spoken hub, we will need to go ahead and create also our

applications. So the first application would be LAN-0

for the spoke.

We can name it SPOKEs_LAN-0. And again, this is a custom app,

not a layer 7, so it’s just referencing for now a simple

prefix, the 10.0.1.0 /24, which is the spokes prefix. And

then we’re going to create another application, it’s going

to be HUB-A_LAN-0, and again we’ll name it the same as the

network and also include only the prefix.

/24 for the hub. So let’s switch to the Mist UI and

we’ll see how we create and add applications. So other

organization. We have networks and then also we have

applications. If we click on applications we can see we have

no applications defined yet. So we can go ahead and click on add

applications and we.

Have put our application name so SPOKEs_LAN-0. You can add a

description and since it’s a custom app I will add the spoke

prefix and you can also define some specific ports and

protocols. But for now to keep it simple we’ll only use the

prefix name, the prefix address.

Similarly we can define the HUB-A_ LAN-0, so HUB-A_LAN-0 and

the prefix is going to be .100.0/24 and we will

click on add.

So now after we have defined our networks and applications and

attached the networks to each one of the devices to the spoke

vSRX and the hub vSRX, we’ll be able to go ahead and define our

steering profile to steer traffic from the spoke going to

the hub through the two overlay tunnels as an ECMP as an

example.

And the other way around, from hub to spoke and configure our

security policies to accept traffic from this specific spoke

to hub. And we’ll show you how to do this in the next segments.

So with that, see you in the next segment. And thanks for

watching.

P2:S4

Hi everyone, welcome back to our Mist AI driven SD-WAN configuration

guides. My name is and I’m a solution architect

here at Juniper on the Mist AI Driven Enterprise team. This is

going to be Section 4 of Part 2.

A Hub and Spoke VPN traffic flow. This is where we’re going

to look at how we create Steering Profiles and

Application Policies in order to allow traffic flow from Spoke to

Hub or Hub to Spoke using our Overlay tunnels, the VPN

network. And with that, let’s get going.

So in previous section what we did we this is our first Use

Case where we have this simple host on Site-1 which is our

Spoke Site-1 LAN-0 and we wanted to send traffic to Hub-A

LAN-0 it’s a host connected on the Hub side.

And for that we have created both these Networks, Spokes, LAN-0

and then this Network on the Hub and we also created

Applications that represents both destinations and so in

order to allow traffic between this Spoke to the Hub or vice

versa.

We would need to go and add to our Spokes WAN Edge Templates or

to the Hub Profile. We would need to add specific what we

referred to as a Steering Profile and also an Application

Policy that is using this Steering Profile that we are

going to create in order to allow traffic to flow through

this two IPSec tunnels that we have that were created between

the Spoke and the Hub.

So really there’s the Mist intent model, or it is being

referred to as the user specifies what he would want to

do. In our case, sending traffic from LAN-0 on the Spoke to

LAN-0 on the Hub and Mist intent model will translate this

to a specific API and obviously,

down to the CLI commands that are being executed on both of

these SRX devices in order to allow you know policies,

Security Policies and specific traffic steering using APBR

mechanisms and or NAT Policies in order for traffic to

to reach its destination and so the intent model.

It’s actually pretty simple. It’s basically referred to from

where we are going to where we want to reach and the path that

we would like this traffic to take. So in our case, as we

mentioned before, from is referred in Mist UI

configuration as a Network. I’m going from this Network on the

Spoke to

an Application that represents either a layer 7 app like you

know, Zoom, Office 365 or any other 5000 or 4000 something

applications that are supported out of the box in SRX devices. Or

it can also represent a custom app that the simplest definition

of a custom app might be just a prefix.

That in this case we have defined a custom app that is

representing Hub-A LAN-0 and then the path that we would want

to take it is represented by Steering Profile and the

Steering Profile is actually defining the different paths

that are available. In this case we would define a Steering

Profile that uses both of these IPSec tunnels.

And these tunnels can be used in different either ECMP per flow

ECMP or these tunnels can be also used as an ordered based on

the specific preference. But in essence that’s how the intent

model in Mist would work.

So if you/we look at this Spoke device, really what we would

need to allow on the Spoke is Spokes_LAN-0 network that we

have defined as 10.0.1.0 /24 which is representing this host

that is connected here going to an Application which is our Hub-A

LAN-0.

And so in order to achieve that we would need to add to our

Spokes Template, WAN Edge Configuration Templates we

would need to add 2 things, but number one, we would need to

configure a Traffic Steering Profile as mentioned and the

Traffic Steering Profiles I’ll show you in a second basically

saying okay, well this traffic that we see here from the Spoke

we wanted to use

both of these IPSec tunnels that we have over WAN-0 and WAN-1

and we want to send traffic to the Hub and so once the traffic

reaches the Hub it would actually be forwarded to the

LAN side of the Hub.

So we would set the strategy whether we want to have it as

ECMP or the other options as an ordered or some preferences. And

then the path type in this case is going to be Overlay because

we would also have an option to send it to Underlay if you want

to do a local breakout or something or even to a different

LAN. This is between you know LAN to LAN traffic.

And then you define how many paths you want in that specific

Steering Profile. So in this example, I’ll create a Steering

Profile called To-VPN, that’s just a name. And then I would

add both of these IPSec tunnels as part of the Steering Profile,

right? So if one tunnel goes down, then we would actually

have the other tunnel available as a backup.

And once this Steering Profile has been created, we would use

this Steering Profile in our Application Policy. And really

again the Application Policy says give it a name. In this

case, you know, I’ll name it Spokes LAN-0 to Hub-A LAN-0

and it’s basically saying again from where you’re coming

from, it’s, you know, we are actually coming from Spokes LAN-0

.

And then we want to go to our application, which is the

destination to Hub-A LAN-0 and the action is going to be

allowed because you don’t want to block this traffic

specifically, and for that you’re going to use the Steering

Profile which is To-VPN that we have created as well. So with

that let’s switch to Mist UI and I’ll show you how to configure

this and apply on the device.

Okay. So if we navigate back to our WAN Edge Template, this is

the Spoke Configuration Template. Click on Spokes again.

Just a reminder, the reason it is called Spokes because this

one sigle Configuration Template, as you will see in

future videos will be applied and assigned to multiple sites.

So that’s the power of Mist automation.

Which you basically go ahead and you know, set your

configurations and you know throughout all your organization

sites, if all sites are the same or maybe even not the same, you

can use variables and adjust you know whatever needed for each

site. But single Template applies. So we’ll look at it

once we’re onboard our Site-2 and 3 and even more sites.

But for now we also have defined 2 Wan interfaces, WAN-0 and WAN-1

. And we also have added our Spokes LAN-0 or this is the

first interface we use, which is this 10.0.1/24 the interface and

IP of that specific 254 as well. And here is where we need to add

a Steering Profile and an Application Policy.

Okay, so to add a Traffic Steering Profile we can click on

Add Traffic Steering and here is where we would need to give it a

name To-VPN, but really you can name it any name you want.

And then the strategy we can either select ordered which

you’ll be able to use specific order but by however many paths

you’d have. I mean in this case if we have Overlay IPSec,

Overlay one and two, you can define whether your priority

going to be first sending over one path and then or switch to

the different path. But for now I’ll use ECMP.

Just a simplistic Traffic Steering because this video is

the basics of how Traffic Steering are being created and

application Policies and then we can go ahead and add Paths. So

the type that we are adding is Overlay. But we have other

options as mentioned if we select WAN, as we see this is

where we will send traffic to the Underlay as local breakout,

but for now we’re going to select Overlay.

And once you click on the name of the Overlay, you see that you

have here both names which is represented by the destination

endpoint of this Overlay. In this case it’s Hub-A WAN-1 and Hub-A

WAN-1. So if you select WAN-1 and then we would also want to add

an additional Overlay which is WAN-1, then we can go ahead

and click on Add.

And we can see that our Traffic Steering has been created named

To-VPN Okay. The next thing we want to do is we want to add the

Application Policy that is actually using the Steering

Profile we have created. I’ll cover import Application

Policies in the next video, but for now you can just simply add

Application Policies from this screen here.

And the first thing we need, we can go ahead and give it a name

and we wanted to call it Spokes LAN-0 to Hub-A LAN-0. So we just

use this name. And then here’s where you select from or the

network. If you click on Add, you can see that we have two

networks defined. One is the

Hub-A LAN-0 network, but we’re actually selecting LAN-0

because we’re going from the Spoke to the Hub and then our

application. We also define an Application called Hub-A. This

is a custom app that represents the prefix of LAN-0 on the

Hub. So you select LAN-0. Your action can be either block

or allow, but in this case we will allow the traffic.

I would always have an option also to select IDP Profile that

you want to apply, but to keep it simple, we at least need to

select our Traffic Steering Profile and this is the Traffic

Steering Profile we have created here on the top which is part of

our Traffic Steerings. And that’s it. And if you are happy

with that, you would go ahead and Save the Template.

Once we save the Template, the configuration will be pushed

instantly to the device and we can go ahead and see the

Security Policy that has been applied to the device. Okay, so

let’s look at our Site-1 Spoke device.

So we can see basically we have only two policies here, Security

Policies. The first one is VPN Overlay to zone of VPN Overlay.

We basically have by default the security open for our entire VPN

if we have other sites, but then you can obviously block specific

addresses. But here is the Policy that we just added. It’s

basically matching on our source network which is 10.0.1.0.

Going to the Hub LAN side 10.0.100.0/24 and we allow this

traffic. Also if we take a look at our routing table we have an

APBR routing instance created.

That you can see we have advertised from the Hub 10.0.100.0

and it is actually pointing to use our IPSec

Overlay tunnels on the Spoke. And by the way for now if we

look at the Hub.

We can see for now we have no Policy to accept the traffic

that is coming from the LAN side of the Spoke and for that

we would need to go ahead and do some configuration on our Hub

Profile as well. By the way just a quick note, if you go to your

WAN Edge devices, Site-1, here’s our site 1 Spoke device.

You can always open Remote shell console to your device from

within Mist UI as well under Utilities. We have different

tools here but one of them is Remote Shell. If you click on

Remote Shell, Mist would actually create a remote shell

session directly to your device and this is the same as

executing your commands your CLI commands from any console,

if you don’t have console to your to your devices so the same

thing here ‘match policies’. You can see that here’s the the

Policy that we have created from 10.0.1 to 10.0.100.0. So

that’s just a quick note to mention that you can create and

you can always open the CLI, command, CLI shell, remote

shell from within Mist as well

if you don’t have console access. All right, so once we

have the correct Policy applied on the Spoke to allow traffic

from the LAN-0 on the Spoke going to the Overlay to the

Overlay tunnels, we would need to have or to make sure that the

Hub accept traffic from the Overlays going into the LAN-0

host as well.

So in this case, very similarly the network would be based on

the Mist intent model, the network would be Spokes LAN-0

, then the destination or the Application is actually Hub

on LAN-0 as well. And very similarly to what we have

configured on the Spoke Template, the WAN Edge Template

we would need to configure on the Hub Profile with slightly

different Steering Profile because again the Steering

Profile is actually saying

what would be the path that the traffic would need to use in

order to reach its destination. So in this case the destination

is the Hub, on LAN-0 right? And the path that we would want

it to take once the traffic arrives into the Hub from the

Overlay tunnels. We would want this to take the path going to

the LAN side. So this is why in this case we’ll create it on a

Steering Profile

named To-LAN-0 and the path strategy it doesn’t matter

because we only have one single link at this point towards the

LAN. So path type is LAN instead of Overlay and you choose the

path which is going to be Hub-A.

And then after we configured the Steering Profile, we would also

add the Application Policy. And the Application Policy is very

similar again to the Application Policy we have configured on the

WAN Edge Template, the Spoke, the Spoke. And the only

difference is that again the Traffic Steering Profile here

would point towards the LAN which we will use the Traffic

Steering we created instead of the Traffic Steering on the

Spoke that is pointing towards the VPN.

So with that let’s switch to the Mist UI and we’ll configure the

Hub Profile with these two parameters Steering Profile and

the Application Policy Okay. So let’s go ahead and navigate to

our Hub Profile, Hub_A and as we can see we only have configured

previously WAN-0/WAN-1 and also our LAN interface and here is where we

would need to go and

add the Steering Profile, Traffic Steering Profile and

then also the Application Policy as we have discussed. So

clicking on Add Steering Traffic Steering Profile we want to name

the profile here To-LAN-0. Again it’s just a name and we

add the path here and we select LAN instead of Overlays we have

selected on the Spoke.

And here you’ll be presented with all the Networks that you

have on your LAN side of the Hub. In this case, we only have

the first network only, so we have LAN-0. We select the

Network and select Yes and then we can go ahead and click on

Add. OK, so once we created this Traffic Steering Profile, we can

click on Add Application Policy. We would need to give it a name.

We wanted to use the same name as we used on the Spoke because

that’s kind of you know, but this is only name, so whatever

you choose is going to be fine And then you select your source

which is the Spokes LAN-0 network and then your

application is the same as on the Spoke and here is where the

difference between the Spoke WAN Edge Template and the Hub

Profile.

The traffic steering is towards the LAN side and once you’re

happy with that, you can go ahead and click on Save and the

config will be instantly pushed to the Hub device, to allow this

Policy. Let’s switch to the console and just to verify that

the Policy has been pushed to the device.

So now if we can look at our Hub device we can see that we have a

new Policy created, which is essentially allowing the source

of the Spoke 10.0.1.0 /24 and the destination is the Hub LAN-0

which is 10.0.100.0 /24. Similarly if we look at the

routing table.

We can look at our VPN Overlay routing table and you can see

that we have the 10.0.1 network which is attached to the Spoke

advertised. So the Hub would know how the return traffic to

go through the Overlay tunnels back to the Spoke when the Spoke

sends traffic to the Hub.

By the way, quick note on configuration changes and device

Insights. If you navigate to your Hub device, that would just

push the configuration to the Hub. Click on the Hub device or

any device, be it a Spoke or a Hub, there’s WAN Edge insights.

If you click on WAN Edge insights, it brings you to a

page where you have a lot of information on the Hub or the

Spoke. But,

what I wanted just to cover here is to see that there is every

configuration push shows up here. You can actually see that

there is a config changed or committed. The change is

actually user changed to config. It’s Shay Dunevich changed the

config on Hub-A, the configuration has been committed

and there’s another change that was done on the device as well.

So you can always follow up on what configs has been changed on

every device. Same goes for WAN Edge devices or our Spoke. If

you can go on our Spoke device WAN Edge Insights, it brings up

the screen. There’s a lot of useful information here that

will cover under the monitoring section.

But just wanted to point out that the configurations and any

changes that are being done on the device are actually shows up

here as well. Another thing I just wanted to mention for those

of you who are familiar with JUNOS and we were looking at

policies here and in this case the source address is 10-0-1-0.

So this is actually a name

that we use in our address book entry, which is actually

referring to the IP itself. So if you look at the address book

entry here, you can actually see that a name 10-0-1-0_24, it

actually results to an address 10.0.1.0/24.

So just note moving forward that any address you see here,

although it doesn’t look like a valid IP address, it’s actually

a name that refers to an address in our global address book or

Security Address Book on each and every device. So this is

just a quick note.

Okay. So at this point we have established connectivity between

Site-1 LAN-0 to Hub-A LAN-0. We have configured our

Steering Profiles both on the WAN Edge Template for the Spokes

and on the Hub Profile for Hub-A and we also configured on each

one of the Templates the Spokes and Hub an Application Policy

that is basically using the Steering Profile. However, there

is another way under Mist UI to manage Application Policies

in a central way and that’s what I want to cover next. So

basically as we noticed in our configuration, the Application

Policy on the Spoke, we named it as Spokes LAN-0 to Hub-A

LAN-0.

It’s actually the same configuration, exactly the same

as on the Hub Profile which is also you know deliberately I use

the same name, Spokes LAN-0 to Hub-A LAN-0. And really

the only difference is that on the Spokes Template we directing

the traffic to the VPN and on the Hub Profile we actually

directing the traffic coming from the VPN towards the LAN-0,

right.

So instead of writing all our policies twice, if they are

basically the same but just the difference is the traffic

steering, what we can do is we can go ahead and write them once

in a central way and then import them both to the WAN Edge

Templates on the Spoke as well as on to the Hub Profile that

assigned to Hub-A.

So essentially the way it is done under Mist is that you

would go ahead and configure your Application Policy or

create an Application Policy again only one time, which is

going to be the same. You give it a name, we’ll use the same

name, network from application to and the action is allowed and

then under each one of the Configuration Templates, WAN Edge

Template and the Hub Profile we’re going to import

this one Application Policy that we have configured under Mist

and the only difference is that we will direct or assign the

traffic steering on the Spoke to point towards the VPN and we

will assign to this Application Policy that we’re importing on

the Hub a Traffic Steering Profile that will point the

traffic towards the LAN.

So that’s actually the difference and again, it

actually saves time and also there is a way to, I mean it’s

better to have it managed in a central way. So with that, let’s

switch to Mist UI and I’ll show you how to do that. So the way

we configure Application Policy, the central Application Policy

is by navigating under organizations we can see here we

have an option called Application Policy and if we

click on Application Policy we can see we have no Application

Policies defined yet as a central repository. So we can go

ahead and do add Application Policy, click on Application

Policy and we can give it a name.

Spokes LAN-0 to Hub-A LAN-0 and again similarly to what

we have done previously, we select Spokes. This is the

network Spokes LAN-0 and the destination is the Application

Hub-A LAN-0 and we can define IDP. In a different video, we’ll

cover IDP Policies etc. Action is allowed and we can go ahead

and click on Save.

Once we click on Save, we have our Application Policy centrally

defined. So we can first go ahead and open our Spokes

Template. That’s the WAN Edge Template. We can navigate to our

Application Policies that we have previously defined and we

can go ahead and delete this Application Policy.

And here’s where we see an option which we previously used

add Application Policy here or import Application Policy. So

when we import Application Policy, this is where we’ll be

prompt into import from our central repository of all the

Application Policies we have defined. For now we have only

one, but you’ll see in future videos that will have much more

Application Policies for all our,

four or five different line segments and you know showcasing

the NAT Use Cases, so that was going to be pretty easy to

understand. In any case, you select your specific Policy that

you want to import, click on import and here is the

Application Policy shows up in grayed out because again it is

not written here under the Spokes WAN Edge Profile, but it’s

actually imported from the central repository

and the only thing we would need to add is that Traffic Steering

right? So when we click on plus here we can add the To-VPN

,which is our Traffic Steering Profile we have defined on this

Spoke. And in this case what we going to have is the same thing

we previously configured manually but now we just

imported the Application Policy once from this central

repository. So we go ahead and click on Save.

And then we’re going to navigate to our Hub Profiles. This is Hub

a Hub Profile and the same exact thing here. Previously we have

written this Application Policy here from scratch, but then we

can go ahead and delete this Application Policy, click on

Import Application Policy, import the same one, because

again, we’re trying to

pick up the Network on the Hub coming from Spokes going to the

Hub application, Hub prefix, so we click on import and then the

Traffic Steering Profile that we have on the Hub is actually

accepting traffic from the Overlay going to the LAN. So we

can click on add plus and here is where we can see sorry and

here is where we can see To-LAN.

And then we can go ahead and click on Save. So the way to

note that this Application Policy was configured in this

central repository is it is actually grayed out and that’s

actually going to be the same as we previously did, but

you know, I just wanted to show you this Application Policy

central repository that here is where we’re going to manage all

our application Policies to each and every direction and then

we’re going to just import them into the correspondent Hub

Profile or Spoke WAN Edge Template. Okay. So now that we

have established connectivity between the Spoke LAN VM to the

Hub LAN-0 VM.

We can also go ahead and quickly check connectivity by logging

into these two VMs on the Spoke and on the Hub. So if we switch back

to our Site-1 and Hub 1, I have a VM attached to this site

one and another LAN-0 VM attached to Hub-A. Also as you

recall, we have configured DHCP server on these two segments.

So if I can go ahead and look at the DHCP server binding and this

is in LAN routing instance. So as you can see there’s one

address that was being leased to on the ge-0/0/2, which is our LAN

VM and if we can look at this LAN VM here.

And I look at the interface in ens3, I can actually see it’s

10.0.1.1 and also the default route here will be pointing to 10.0.1.254

towards this Spoke. Similarly on the Hub site.

We have 10.0.100.1, which is the VM on connected to ge-0/0/3 on the

Hub site and again the same on the LAN VM. We have this

interface that was given through DHCP 10.0.100.1 and the default

route should be pointing.

Should be pointing to 254 as well, default is going to 254.

And by the way, just a quick note, if we go back to our

Mist UI and you go to your site, in this case Site-1, you

can actually see that we have DHCP statistics. So you can

actually see the segment Spokes LAN-0, right? And we have

assigned in this DHCP server 10 IPs and you know there’s one

leased IP already showing up here, so you can also follow your DHCP

statistics from the UI as well. And the same goes for the Hub

site, very similar. You would see here that there’s a one list

IP towards this Hub-A LAN-0.

And then we can go ahead and check the connectivity. So if we

on our Site-1 LAN-0, we can ping our Hub VM which is

pinging. And obviously if you were trying to ping from the

Hub, you would see that there’s no connectivity because we have

not established any policy or connectivity from traffic from

Hub towards the Spoke yet.

Also Please note if you try to ping 8.8.8.8 so there’s no

connectivity from the LAN side to the Internet. As an example

which we’ll do next, we’ll create a local breakout and

another thing that I have under these VMs I can remote desktop

onto this VM. So as an example here is I’m already ping

remotely into my lab to Site-1 LAN-0 Host-1.

And if we can go ahead and open a browser to net you can see

that this is not working. Obviously we don’t have

connectivity. However I have a small HTTP server deployed on

the Hub side LAN-0 VM. So if I try and open my browser

towards this VM I can see that I land on the page.

Which is Hub-A LAN-0. So this is just a quick way for me to

test connectivity as well either HTTP or even using HTTPS 443

. The reason I’m bringing this up is because we will be

able to use this method to when we when we’ll talk about

destination NAT forwarding and source NAT, so we’ll be able to.

To use this capability to show either SSH or 443 traffic as I

mentioned in part one section one of this video series okay.

So we have enabled then communication from Spoke to Hub.

But as mentioned we also need to look at the other direction if

Hub-A LAN-0 VM here wants to actually access the Spokes Vms

as well.

So in this case, traffic will be coming, the source is going to

be the Hub-A LAN-0, network going to an application which is

sites or Spokes LAN-0. And really then the difference is,

as you can see here, the network becomes Hub-A LAN-0 and then

the application is actually Spokes LAN-0 as well. So it’s

the same as previously, but you know the other the other

direction.

And so if we look at the Steering Profile again, you

probably notice that this Steering Profile that we will

configure on Hub-A would actually direct traffic to VPN

because using, you know, trying to use the both of the IPSec

tunnels going to the Spoke and then the Steering Profile here

on the Spoke would actually direct traffic that is coming

through the Overlay tunnels, the IPSec Overlay tunnels towards

the LAN side of the Spoke which is the host VM here on LAN-0.

And as before we would then go ahead and configure our central

repository of Application Policies which would actually

going to be Hub-A LAN-0 to Spokes LAN-0.

From Hub-A and then the application again is Spokes. And

then we will do the same as previously. We’re going to

import this application both to the Hub Profile and to the Spoke

Template. And the only difference would be then that on

the Hub will have the traffic steering pointing towards the

VPN using the traffic steering to VPN and on the Spoke on this

Application Policy we’ll be configuring using the traffic

steering to LAN-0. So again.

Pretty much the same, but the opposite direction. And let’s

switch to Mist UI and I’ll show you quickly how to configure

this as well.

Okay, so we have configured the opposite direction from Hub to

Spoke and just to quickly check what do we have on the device,

if we look at our Spoke device, we can actually see an

additional policy has been created here which the source

address is 10.0.100.0 ,which is the Hub side,

going to our destination which is 10.0.1.0 which is our Spoke side

and if we look at the Hub Policies we can see also an

additional policy has been added which is actually allowing

traffic from the Hub 10.0.100.0 going to the Spoke and

allow. You can actually see here that it’s coming from the Hub-A

LAN-0 zone towards the VPN Overlay zone and here the other

way around on the Spoke,

it is actually coming from VPN Overlay going into the Spoke

LAN-0 zone. And then you know if we go and try and ping

now from our Hub LAN-A to our Spoke 10.0.1.1, we can see now we

have connectivity from Hub to Spoke and obviously if we ping

from the Spoke side to the Hub

we can also get across the VPN as well, Okay, so in the next

video we’re going to look at how we can add local breakout for

the LAN-0 on the Spoke if we want to send traffic to the

Internet as well via the Underlay, not necessarily going

to the VPN. So we look at how we add an application called Inet-ALL

or Internet ALL,

basically Quad Zero. And then how do we add an additional

Steering Profile and Application Policy to allow this local

breakout to the Internet as well? So with that, see you in

the next video and thanks for watching.

P2:S5

Hi everyone, welcome back to our Mist AI Driven SD-WAN

Configuration Guides series of videos. My name is

and I’m a solution Architect here at Juniper on the Mist AI

Driven Enterprise team and this is going to be Section 5 of Part

2.

That’s going to be a quick video. We’re going to look at

how do we enable or create Steering Profiles and Policies

to enable local breakout traffic to the Internet from the side,

from the LAN side via the Underlay networks. And with that

let’s get going. So looking again at our first example where

LAN-0 on the Spoke is sending traffic

towards Hub-A LAN-0, over the VPN IPSec tunnels. But

indeed also we want to allow traffic going to the Internet

via the Underlay network WAN-0 and WAN1, what we refer to as Local

Breakout from this LAN-0 towards the Internet and for that we

would need to create an Application,

0.0.0.0, in this example, or it can be any other destination, not

necessarily a custom app, but it might be even Zoom or any layer

7 applications. And we would also need to create a specific

Steering Profile for that to direct traffic towards the

Underlay instead of going Overlay towards the IPSec

tunnels.

Okay, so looking at this Spoke LAN-0 we can just to

identify. We can clearly see that our intent is to direct

traffic to the Underlay going to the Internet through my lab

firewall. And really what we would need to do is we need to

have a Policy on our Spoke Template or WAN Edge Template

that would direct the Network or any traffic coming from

Spoke LAN-0 10.0.1.0/24 going to an application. But in this

case the Application is ine_ALL ,which is going to be 0.0.0.0

and this Application is resides somewhere on the

Internet, right, and not on the Hub or over the VPN as we have

previously configured in the in the last video.

So in order to do that, the first thing we would need to do

is to create this Application, and in this case I’ll name my

Application inet-ALL, stands for Internet ALL and I’ll just

include the default quad 0.0.0.0 essentially saying anything that

you are trying to send to anywhere

it would go towards the Local Breakout going to the Internet.

You may ask, ‘Well, I mean we have another traffic that already

going to a specific IP, which is this 10.0.100.1 as we this as

we are configured in the previous video’. But that’s okay

because the way we’ll manage the Security Policies on our SRX

would be first,

they’re varying this traffic from LAN-0 on the Spoke to

the Hub, but then the rest will go to the Internet. So really if

we take a look at our WAN Edge Profile here after creating this

Application, we will go ahead and we’ll open again the WAN

Edge Template for Spokes and we will configure an additional

Steering Profile, very similar way.

We’ll name it To-inet_LBO just to make sure we identify where

are we going to be diverting our traffic towards the Internet.

And again, I’ll show you in subsequent videos that we can

also do breakout to the Internet through the Hub. There are some

cases that you would want to do that as well. This is why I’m

mentioning in my Steering Profile that this one

specifically is referring to LBO (local breakout) on the Spoke

device. And the strategy is going to be ordered and I first

want to use WAN-0 as my primary link and if primary link

fails or degraded, we’re going to switch to WAN-1. As an

example, WAN-0 might be my broadband link

and DSL cable and then WAN-1 might be my LTE link as a

backup. And I’m not sure I’m gonna use my LTE for traffic if

my broadband is intact. So that’s why my strategy would be

ordered first use WAN-0 and then use WAN-1.

And similarly to our previous, the way we configured

Application Policies in the central repository, we’ll go

ahead and we add another Policy named Spokes LAN-0 to inet-ALL

, you know and the network would be again Spokes LAN-0

inet-ALL is the Application and allow and then we’re going

to follow the same process of importing this Policy into the

WAN Edge Template for the Spokes.

And just applying the Steering Profile that we have configured.

So with that let’s switch to Mist UI and I’ll show you how to

configure this. Okay, so the first thing we want to do is we

want to add this additional Application to our Applications

list. We click on Applications and then Add Applications and we

wanted to call it inet_ALL.

And we would include our default 0.0.0.0 as a custom app. By the

way, I mean if you would like to specifically direct traffic to

specific destination, we can always pick from the list of –

there are 7 apps that we support, as an example Zoom or other

things. But I’ll cover this in a different video we’ll discuss on

regarding web filtering. So for now we can click on Add

and the Application has been added. The next thing we want to

do is we want to navigate it to our Application Policy which is

our central repository for all Application for all Application

Policies that will be then imported to different Profiles

in WAN Edge Templates. And here is where we have the previously

2 created Application Policies already to direct traffic to VPN

and from VPN.

And we can then go ahead and click on Add Application Policy.

I wanted to give it a name and we wanted to name it Spokes LAN-0

to inet-ALL. And we can then go ahead and pick up the

Network, which is LAN-0 on the Spokes. And then the Application

that we have just created, inet-ALL , shows up here on our

Application list that we can pick from. Click on Done

and we can go ahead and save this Policy. The next thing we

want to do is we want to navigate to our WAN Edge

Template for the Spokes. Click on Spokes and we can see here we

have our previously created two Steering Profiles to direct

traffic to VPN going to the Hub and from the VPN going to Spoke

LAN-0.

And here’s where we can go ahead and click on Add another Traffic

Steering at Traffic Steering and we’re going to call this traffic

Steering 2, inet_LBO local breakout. And then we’re going

to add the different paths to this Traffic Steering. And

obviously it’s not going to be an Overlay, but there’s going to

be an Underlay WAN and you can then select how many WAN links

you want to have in this

Steering Profile. In my case I do want to have both of them both WAN-0

and WAN-1 that would be acting as the first preference

is going to be WAN-0 because my broadband is an example and then

I failover to WAN-1 and we can go ahead and click on Add.

And here is the additional Steering Profile has been

created.

And now we can use the Application Policy we have

configured as import Application Policy and you can see these two

are grayed out because already included in this WAN Edge

Profile and the only one that we can select is Spokes LAN-0 to

inet-ALL. So we’re going to click on Import and then we’re

going to select here our Steering Profile that we just

created to inet-ALL via local breakout.

And as we can see here basically the three Policies that we

currently have configured, the first one says Spoke to Hub LAN-0

, which means the specific prefix that we would direct

towards the VPN and then we have Spoke LAN-0 going to inet_ALL,

which is picking up the default.

Anything other than 10.0.100.0 would actually use the

Local Breakout towards the Internet. And with that we can go

ahead and click on Save to save the Profile the Template.

And once this Template has been saved, the configuration is

always instantly pushed to the device, to the Spoke or actually

to all Spokes. Depends on how many Spokes you have, but for

now we have only one, but we will be adding the additional

sites. So any configuration you do here, they’re actually going

to be pushed to all our Spokes.

And we can quickly switch to the device just to see what is the

Application Policy or Security Policies that have been

configured on the device to allow traffic to the Internet.

So looking at our Site-1 which is our Spoke device, we can look

at the additional Policy that has been created here and as we

can see

, we have Spokes LAN-0 going to WAN-0 zone picking up the prefix

10.0.1.0 going to any address and application and saying we have a

Policy created for WAN-1 going to LAN-0 going to WAN-1 as

well and so we can then quickly ping

1.0.100.1, which again the Hub and we can see we can get across the

VPN and we can also ping 8.8.8.8 and we can see now that we have

connectivity to the Internet as well. And we can also look at our

Spoke device

by opening an RDP session to the device so previously we were

able to get the page on LAN-0 of Hub-A and if we open a new

tab we can also see that we have connectivity to the Internet. So

that means that we have connectivity to any

application or any destination as we have configured to

mist.com as an example. You can browse the documents. By the

way, there’s the documentation under SRX and you can – here

there’s a Design Guides. And here’s all our video series as

well where you can browse from here.

Also just a quick note on Source NAT since we are going Local

Breakout to the Internet. If I go back to my WAN Edge Template

for the Spokes I can see here WAN-0 and WAN-1 and as a

reminder when we configured each one of the WAN interfaces,

we have selected or by default. the selection is to do Source

NAT by the interface. We’ll discuss in a later video on how

do we have the other options to configure NAT for pool. Pool NAT as

well if you have different range of public IPs that you wouldn’t

use for your Source NAT, but then for now it is configured as

Source NAT via the interface and so.

If we switch back to our device we can look at the NAT Policy

that has been configured as well and we can see here that we have

a rule set that is basically picking up Spokes LAN-0 to WAN-0

and this is allowing Source NAT

interface to be used when going out to the Internet. So again

this is just a quick note on that as well. Okay, so with that

we have completed our first Use Case and now we have LAN-0 on

the Spoke traffic is enabled to reach the Hub as well as going

to the Internet via Local Breakout.

Okay, so next what we want to do is we want to add Site-2 and

Site-3 and so we’ll have LAN-0 in all three sites. And as

you would probably figure out, we would need to use variables.

This is where I’ll introduce you to the way you use variables

with Mist.

That’s in order to have distinct segments here, per our Use Case

here, Site-2 is going to be 10.0.2 and 10.0.3 in Site-3. And in

order to do that by using one single Template, which is our

Spokes Template, we would need to define the Network a bit

different using a Site Variable and also a Mask Variable as

well. And so I’ll show you this in the next video.

So with that, see you in the next segment. Thanks for

watching.

P2:S6

Hi everyone, welcome back to our MIST AI driven SD1 configuration

guides. My name is Shai Dolovich, I’m a solution

architect here at Juniper on the Mist AI driven Enterprise team

and this is going to be section 6 of Part 2.

We’re going to look at site variables and onboarding

additional devices and how do we make use of site variables to

have different values for our networks, IPS and other

parameters while using one single template or one edge

template or even hub profile. So with that let’s get going.

So, so far on previous videos we have completed our configuration

for site one and Hub A and we have connected our first LAN

segment 10/01/24 on the spoke and 10 zero 100.0 slash 24 on

Hub A.

And we have tested connectivity and local breakout etc. If you

haven’t watched the previous sections, please go back and

watch the previous sections because that would give you more

insight of where we are at this point. So next we want to add

the two other sites that we have in my topology which is site 2

and we’re going to obviously connect this in the same way.

Although the address is going to be slightly different, the

underlay, the 2nd octet in my lab is representing the site

number. So site 2 is 1020 is 1 zero and one is 1/1 so 1021. And

then it’s going to be DHCP and whenever the site is going to be

on boarded the two Ipsec tunnels will be created added to the

VPN.

And if we look at our land side on site two, it’s going to be

10/02 and instead of 10/01/24. So that’s going to be slightly

different and we’re going to see how we do that. And obviously

similarly site #3 we’re going to on board and we’ll see that it’s

going to be 10/3 or 10/03 on the land side.

So with that, let’s go switch to miss UI and we’ll onboard site

two. I’m going to run through this quickly because this is the

same way I have onboarded site one in Section 2 of Part 2, so

you can go back and watch that section as well. So here we are,

We logged into site two, my device. These are VSRX devices

that I have in my lab and so I have console access.

We’re going to quickly check connectivity to the Internet,

make sure we can resolve domain names and then we can commit the

config we have copied from adopt device onto this device.

Back to our missed UI inventory, we can quickly refresh the page

and we can see that we have this additional device shows up here.

It’s unassigned and we want to go ahead and assign this device

to Site 2.

We can click on Assign to Site and we’re going to. At this

point we’ll select our site that is Site 2 and we want to manage

config with Missed. You can actually do it from here and

then we’ll follow the abstract license we have configured on

the site settings. Please watch section one of Part 2 regarding

licensing and then I can click on Assign to Site.

Message saying device is assigned closed. One thing we

want to do we would want to go back to our one edge template

and to our spokes template and make sure that the spoke

template is actually assigned to site 2 as well. At this point

you can see that we have only one site assigned to this spokes

template and obviously one edge device because we have one

device under site one. But if you can click on assign to site.

We can see that we can select site 2 now as well and assign

this template to site 2 as well. So if we click on apply we’ll

see two sites and two one edge devices in total and so this

one. This device is now assigned to the site and the config

should be pushed to this device based on this template as well.

If we go back to our one edges sites, we can actually now

select site 2.

And we can see we have Site 2 device here shows up as well,

and if we log into it we can see the device is up and running

after a few minutes and it actually all looks good. When

you click on one edge you can see it has two Ipsec tunnels and

a BGP IBGP session as well.

Looking at Site 2 device we can see that we have, we can see we

have our two tunnels up towards the hub 10100 zero two and pier

is 10100 zero one and also this is our hub. So we can look at

the icon IP SEC tunnels here as well and we can see that the hub

is now connected to both site 110 one and 10 two. So that that

looks good.

And if we look at our interfaces quickly, we can see we have G00

which is our 10 interface and G001 which is 11 interface and

here is G002 which is their land zero interface. However here’s

the problem, in this interface G002 we actually see 10/01.

And not 10:02. Again this is site 2 and I would expect to see

here 10:02 instead of 10/01. So this is where we would need to

use site variables in order to make sure that in site 2 land 0

segment will be 10/02 and not 10/01 as similar as in site one.

So let’s go ahead and I’ll show you what we need to create and

how we use site variables.

So again the concept is pretty simple. What we would need to do

is we need to create our network to read 10, zero and then a

specific variable that will change based on the site number

in my case.

And I’m also going to include the subnet mask to be variable

as well and I’ll show you why in the next video. But in general,

you know this site variable will resolve into different number

for each and every site. So we’ll have the right segments

under LAN zero and the way we do that under Mist, we first need

to go ahead and create site variables in each site.

This is being done under site settings. So here’s an example.

We’ll go to site one and we’ll add 2 variables. The first one

will be site number and it would the value for site one would be

one and then the land zero mask is also going to be slash 24.

And then once the variable were created we’re going to switch to

the network and we’re going to edit the network we have created

previously without variables.

Which is the spokes LAN Zero Again, This is why I named my

network spokes and not site one because again, this network is

basically shared or is the same network that is applied to all

my spokes. And then the subnet IP would actually be 10 Zero

site #0 and the prefix is going to be LAN Zero MASK. And here’s

another just to make sure we have it written when we

configure it.

So LAN or spokes land zero network, it’s going to read. The

third object would be the site number. So for site one these

are going to be two variables and it will then resolve to

10010 and then you know in site 2 they’re going to be the same 2

variables but the site number will resolve to 2 and so the

segment will be on the device. Apply on the device would be

10/02 and similarly to site 3.

And so on and so forth. So that’s the concept of how do we

use variables under Missed. Let’s switch to the Missed UI

and I’ll show you how to configure this. Okay. So first

we’re going to navigate to Site One settings. This is under Site

Configuration and we can click on Site One and then if we

Scroll down here, you’ll see a section named Site Variables and

we can go ahead and add a variable.

And the first variable we’re going to add is site_number and

the value would be 1 because we’re in site one. And then

we’re going to add another variable which we named LAN zero

mask and we’re going to give it a value of 24.

Again, the variables are just names, so you’re welcome to use

any name that makes sense to you, but that’s what I’m using

in my example. And once I’m happy with that, I’m going to go

ahead and click on save and then we’re going to go to site 2 and

we’ll do a similar variables here, so site number.

And here it’s going to be resolved to #2 value 2 and then

site mask sorry land zero mask and we resolve it to 24 Site

number and land zero mask.

By the way, you do not need to configure it obviously site by

site. The way to do this I mean, I’m obviously doing it step by

step in order to show you the different parameters. But when

you deploy a complete network, you would go ahead and create

one site and once you’re happy with that site, you just go

ahead and clone and create multiple sites. And obviously

Mist is we support APIs.

So you can quickly create multiple number of sites,

hundreds of sites in the click for button using our APIs. So

just bear in mind on that. So once we have created our site

variables we can go ahead and click and navigate to our

networks and here is our spokes land 0 network.

And instead of one that we had previously configured, here I’ll

go ahead and I’ll add my variables which is site number

and then instead of 24 I will include the LAN zero_mask

variable as well clicking on save.

And then what we also need to do is we would need to go ahead and

update our one inch template. Clicking on spokes, it is not

yet, it is not updated automatically. So if you click

on the spokes you can actually see that we have configured here

10/01, but essentially it actually needs to be 10 zero

site #254.

And then the mask would be also the verbalized mask as well. And

since we have configured DHCP server here, we’re going to go

ahead and update this DHCP server 10 devices and also 254

and then we can go ahead and click on save.

And now we can see that the IP configuration shows up using the

variables as well, and we can go ahead and click on save. And now

this configuration will be updated on both devices, site

one and site 2. And let’s go ahead quickly switch to our

console just to verify that this has been configured correctly.

Switching back to Site 2 and we can look at the configuration

under Interfaces again after the configure has been pushed and we

can now see that G002 which is our LAN zero reads ten 0.2

instead of .1 and we can also check the same under site one.

And we can see that G002 and site one, it’s actually ten

01254. So this is how you use variables and if we look at our

policies, we can see that the correct policy here from

Spokesland 0 going to the VPN towards the hub.

Is now updated to 10020 slash 24 going to 10100. But if you look

at the the opposite direction coming from the hub toward this

land zero on the spoke, it actually the source address is

10 zero 100, however the destination is 10/01.

And we are in site 2, so that’s obviously not going to work. And

on site two we will not have the correct policy. So for that we

actually need to update the application we have created

instead of 10/01, we can actually have the application to

cover all our spokes land zero and maybe we’ll create an

application prefix that would be a 16.

So let’s go ahead and just quickly update that as well. So

if we navigate back to applications and here we have

our Spokes LAN 0 application. And again the reason I named it

Spokes LAN 0 is because I want to cover all spokes instead of

having a specific list of IPS per each and every site. And

here is what I can do is I can just go ahead and make it 10000

sixteen.

And if the third octet in my topology in my example

specifically represents the site number, you will see that we can

just have the policy accept or destination would be 1000

sixteen. So that’s one way to resolve it. We can click on save

and the config will be actually pushed instantly to the device.

So we just go back to the device to verify that we have the right

config now.

So if we look at our policies again on site 2, we can now see

that we accept traffic from 10/01 hundred zero to 1000 slash

16, which represents our application policy and very

similar in site one. If we look at our policies again, the

source address going to the hub actually picks up 10:01 because

it’s site one.

And the reverse path from the the reverse traffic from the hub

initiated traffic from the hub towards the LAN zero we actually

accept from 1000 sixteen. And one quick note, if we navigate

to our hub A and we look at our route table, we have the routing

instance VPN org overlay.

And we can see that both spokes spoke one site one and site two

are actually advertising 10/01 and 10/02/24. So now we have the

right advertisement and the right segments and there are not

overlapping between both sites and if we quickly go to our land

zero on the hub.

If we ping just to check, make sure that we have connectivity.

If we ping our host one LAN zero on site 110011 we can see that

we can get across the VPN and if we want to ping the two we can

also see we have connectivity towards site 2 as well.

Now one more thing we need to do is we also need to include

similar variables on the hub profile as well. If we negate

back to our hub profile hub A we can see we have configured a

traffic steering to accept traffic from LAN 0 spokes LAN

zero right? Which in now it is covering all sites spokes LAN 0

not only individual one which is .1.

And so when Mist is going to push configuration and configure

this policy on the hub, it would actually configure a network

called Spokes LAN Zero in order to allow traffic going to hub a

LAN 0 which is our application 10 zero 100 Zero. Now The thing

is when we change the network now on Spokes LAN Zero, the

network is now using variables.

And so the hub site would also need to include variables in

order for this network to be able to resolve this network

when config is being pushed to the hub. So what we can do is we

can then on the hub if we want to accept from all spokes LAN

zero. In this case we would want to accept 1000 sixteen again

coming from all spokes.

And the prefix would be 16 and not 24. What we can do is we can

go to our hub site if we navigate to our site

configuration hub site and we can add the variables here as

well. The site number here would be 0.

Because then the third octet would be 1000 and we’ll accept

all traffic from all spokes, LAN zero sites and we’re also going

to add a variable LAN zero and we’re going to give it a value

of 16. So again.

Same 2 variables that we have on the spoke sites we also need to

have on the hub site because Ms. will need to resolve this

variable when config is being pushed to the hub site or to the

hub device and we can go ahead and click on save and then if we

quickly look at our hub device under we match policies.

So we can see now that the source address anything coming

from the VPN overlay zone going to the hub a LAN zero. The

source address is actually 1000 slash 16 third octet is 0 result

on the hub accepting from all sides and the destination

address is a slash 24 segment that is on the hub LAN zero. And

the other way around is also matching what we have

configured.

Coming from hub a LAN 0 going to the VPN meaning going to all our

sites overlay using the overlay tunnel Ipsec tunnels we can see

that the destination address shows up here as 1000 slash 16

which is going to allow traffic to go to all sites LAN zero. OK

so now once we have our variables configured on both

sites.

We can go ahead and clone site 2 and onboard our site 3 device as

well. So we can navigate again to our site configuration, enter

site 2 and do clone site and then give it a name and an

address.

And the only thing we would need to if you Scroll down here we

have our variables. Here the mask is going to be slash 24 but

the only thing we would need to change is #3 and then we can

click on save and there we have site #3 created as well. So now

I can go to inventory under one edge devices and I can click on

adopt one edge device.

And follow the same process as I’ve done before.

So this is how you make use of site variables and the missed

automation that in general you can have one template. Your

configuration for all your sites are included in one single

template.

But then based on different sites, you can define which

specific IP addresses you may have on each site. So in the

next video we’re going to look at our second use case which is

LAN one. And in this case we wanted to see how we can take

advantage of source not from the site going to the hub using the

overlay.

In this case, we’re going to have an overlapping IPS in each

and every site, meaning same IP for LAN, one inside 123 and

we’re going to then make sure we source not the traffic to a

specific IP which is different IP for each site, again using

variables going to hub A. So with that see you in the next

segment and thanks for watching.

P2:S7

Hi everyone, welcome back to our Mist AI-Driven SD-WAN

Configuration Guides series. My name is Shay Dunevich, and I’m a

Solution Architect here at Juniper on the Mist Air Driven

Enterprise team and this is going to be Section 7 of Part 2,

the configuration guides.

We’ll take a look at how we can configure Source NAT from

Spokes to HUB via the overlay in the hub & spoke topology. This

is useful when we have an Overlapping IPs in each and

every site and then we want to communicate with our hubs. So

with that let’s get going. Okay. So just a quick recap, this is

our lab topology.

We have three sites, Site 1, 2, 3 and one hub – Hub A and we have

different LAN segments here that is basically emulating different

use cases as you can see here on the right hand side. This is

what I’ve already covered in part one which is the overview

part.

And we already covered LAN Zero in our previous sections of Part

2, so I highly encourage you to go back and watch section one

through 6 in Part 2. And in this section, as I mentioned, we’re

going to take a look at LAN One, which is our overlapping Ip’s

use case.

So if you consider then Len 1 to be overlapping IP will show you

how to configure source not on each and every site and also

accept traffic on the hub. So just again to baseline

ourselves, let’s say site one I have 10168.1 dot one. This is a

host on a 0 on a .0 slash 24 network and it would want to.

Communicate with the hub. Hub a LAN one host and we’re going to

source, not when it leaves the spoke using the overlay, we’re

going to source, not this to one. 82168 dot 1.11 stands for

site one.

Similarly from site two and three traffic will be noted

because it’s an overlapping IP and each and every site is the

same segment. Land one is same segment and one 168.1 slash .0

slash 24 and hence we need to source noted to a different IP

so they return traffic from hub.

Towards the site would know how to get back to the perspective

site. So one 92168 dot 1.2 is going to be noted from traffic

that is coming from site 2 and site 3 and so on. And for that

as you will see in the next few slides, we’re going to take a

look at how we use site variables.

And use them on networks. Again, I covered this already in

previous sections when we talked in when we discussed Land 0 use

case. But again, this is a very powerful way to use a single

template that is associated with multiple sites on Mist. So we’re

going to do this here in Land one as well.

So now let’s take a look at our lab topology. Here’s our VSRX

spoke and hub. I just isolated one site, site one just for me,

just so it will be easier for me to explain what parameters and

configuration we need to use on the LAN one network. And then as

we already discussed, it would be replicated and used on all

sites, all spokes.

So in this case, just to make it more realistic, land one, we

would probably have multiple hosts on land one, right? So

again, land one on the spoke which is the 10168 dot 1.0 slash

24 segment would want to we would want to communicate or to

send traffic towards hub A.

LAN one which is one 92168 dot 100.1. This is the host here.

Assume let’s say we have an HTTP HTTPS server web server on LAN 1

deployed in the hub and you know each host on the spoke would

want to access this this server. The communication is only going

to be initiated from the spoke side to the hub and not vice

versa.

So again, just to make it realistic, I’ve added two more

segments here, sorry, two more hosts here on the same LAN, one

segment, so we have H1 host 1H2 and 254 is actually the

interface here on the VSRX 10168 dot 1.254.

And then each one of the hosts is going to be dot 1.2. You

know, don’t text, right. I mean so again realistically we have

the segment, but we’re not going to have probably one host

deployed in each side, but multiple And so then if we take

a look on what’s going to happen here, you know each traffic that

is generated from each and every host will be source knotted.

In this case to using one single IP in my example here I’m going

to be using one 92168 dot 1.1 slash 32 and then So what I’m

basically showing here that each and every spoke, each and every

host on LAN one is going to be source noted to the same IP

going to the hub using the overlays and so.

Basically the network here again for site one LAN one, the

network is 10168 dot 1.0 slash 24 and so we would need to

advertise to the hub a network or an IP that the hub would need

to know how to have the reverse traffic reach a specific spoke

or the right spoke. So in this case we’re going to advertise on

behalf of site one, LAN one.

We’re going to advertise this one single IP which is this one

82168.1 dot one because that’s going to be the IP that every

host here we’re going to be source nothing to this IP and

sending it to the hub and obviously in site two and three

it’s going to be the two. But again just looking at example of

1 site to make it to make it more clear.

So we have we would need to configure on a network under

missed three different parameters for site one. So

first of all we would actually need to configure the 10168 dot

1.0 segment or network which is the actual IP that all these

hosts of plan one are going to be sitting on.

And then we’re going to configure source, not pool. And

in this case again I’ve chosen to use a slash 32 pool and one

82168.1 which is going to be our source, not and spoke one site.

One, as we mentioned, will be advertising via ibgp through the

overlay because we have ibgp sessions running between spokes

to hubs.

So it’s going to be advertising 180 to 168.1 dot one and again

the reason is because the hub would know how to have the

reverse traffic going to the right side. And if we look at

the hub site, the hub site is obviously very simple. We have

one network which is 180 to 168 dot 100.0.

And we have one host here because I have installed HTTPS

server on this host. So we will be able to get RDP session on

each one of these hosts and see that the traffic is actually

working and flowing correctly and so.

When this spoke one will send traffic to to hub A, it would

actually send traffic after it leaves the spoke. It’s going to

be as we mentioned 18 to 168.1 dot one going to 1/8 to 168 dot

100.1 and so because we’re advertising the reverse traffic

would know how to get back to spoke one.

Very similarly on spoke two, just so we have it written when

we configure the networks, the same network will exist in Site

2 spoke 2 because as we said this use case is actually an

overlapping APS and then the source not pool is going to be

.2 and .1 and then also we’re going to advertise .2. So

basically again you know the two is going to be going to the hub.

.100 Network .101 which is the host on the hub and it would

know how to get back because this is what we’re going to

advertise and as you probably figure out, it’s going to be the

same exact on site three. However, the IP is going to be

different.

And so for that there will be deployed the security policy.

Mist will deploy a security policy part of the application

policy. A security policy on this VSRX allowing dot X

whatever you know dot 1.2 on each side is going to be

different, allowing traffic going to .0 after it has been

sourced. Noted and obviously on the hub will have a security

policy that should receive traffic however.

Here is what we’re going to do on the hub. We’re going to have

one security policy that is going to be accepting traffic

from a .0 slash 24. The reason is because let’s assume we have

multiple sites. Each site is going to be dot 1.2 dot 3.4 and

so on. Well depends how many sites we have, but let’s assume

it’s a slash 24256 sites.

So we would want to have on the hub policy that is accepting

traffic coming from the overlay which is the .0 slash 24 from

all sides going to this 180 to 168 network on the hub. So This

is why I just stop pointing it out because you’ll see in the

next slide we would need to use different variables on different

sides in order to make it happen because here again on on the

spoke side is going to be a slash 32A specific IP.

And on the hub side, it will accept traffic from all spokes

and This is why I mentioned it’s going to be a slash 24. So now

let’s look at how we configure the network and use the right

site variables and use the variables in the networks in

order for these IPS as we outlined here to be configured

correctly.

So again based on the misintend model, we always communicate

between a network to an application. In our case again

the network is folks land one and then our application is the

hub land one network. In this case, right, We covered

applications in previous sections whether it is a layer 7

applications or just a custom application which in this case

is just identified by.

A prefix. So you know, please go back and look at that segment in

previous videos. So if I take a look at configuring or creating

Spokesland One network here, I need to configure then specify

the network prefix and in this case it’s going to be the .0

slash 24.

And we would need to, as we mentioned, configure a source,

not pool. And since the last octet is identifying our site,

we’ll use a site variable site_number to signify the

correct IP when this network is deployed on each site.

And we also need to override the prefix to advertise towards the

hub. And because we would not want to advertise the 10168.1

dot zero network, the original network because the hub doesn’t

actually see this network. I mean everything is going to be

source noted to the source, not pool. So we would need to

override the advertisement. I’ll show you in the next slide how

we do it on list as well.

But in this case I wanted to override this with one 92168.1

dot site number as we mentioned and the prefix when it’s going

to be land one mask. And when this be going to be resolving

and configured under the spoke site, it will resolve and will

result in configuring the advertised prefix to be a slash

32 as we mentioned in previous slides.

And however, just just know that on the hub, as we mentioned,

Mist would need to allow this network spokesland one on the

hub, it would need to allow this network to communicate with the

hub host, the .100. And in this case we would want to make sure

that this advertised prefix or the 180 to 168 network.

Would actually be resolved to .0 slash 24. So again we’re going

to use site number and the site number variable on the hub will

resolve to 0 and the land one mask on the hub will resolve to

24. So I just want to kind of again you know the point here is

I wanted to make you aware that this network that we will create

when this network, the config is pushed to a spoke device.

The network will be slash 32 and based on the site number. But

when this network would need to be allowed, meaning there is a

security policy that would need to be configured on the hub.

This network will resolve to .0 slash 24 based on the different

variables that we will have on the hub.

And so here is our variables. So we will go ahead and configure

in site one site number equals one, which by the way will be

have this variable because we used it on LAN 0 use cases. You

know the previous sections and LAN one mask. This is the

additional new variable we have on the site. On site one it will

resolve to 32.

And based on these two variables, these are going to be

actual the Ip’s that we will get when config is pushed to spoke

one, site 1. Similarly on site two we already have two but the

land one mask on site 2 is going to be again 32 and this is going

to be the network according to what we have specified. And site

3 is going to be 3 and 332 and we’ll get this network as well.

And on the hub side, again, in order to make sure we’ll have

this network resolved correctly on the hub, we’ll set the site

number to zero as we did already in the previous use case for

land zero and then land one mask variable on the hub side will

result to 24. And in these two parameters it would actually

these two variables.

The network that will be configured in the security

policy on the hub to accept traffic is actually going to be

the 102168.1.0 slash 24 using these two variables. So next

let’s see how we configure the networks and application on the

Mist to allow this traffic.

So the first thing we need to do is to configure or to add the

land one mask variable under each site. In this example I’m

showing site one which is going to have adding a slash 32 as

described and also hub A we’re going to have or add a slash 24.

So let’s switch to miss UI and I’ll show you how to configure

this one as well.

Okay, so let’s go ahead and navigate to our site settings

under Organization Site Configuration and we’ll click on

Site one and if we Scroll down we can add another variable here

for the LAN one mask and there’s going to be a slash 32.

And since we have already cloned those sites, we would need to go

ahead and do that for site 2 and site 3. But again, you know, if

you create first your template, the way to create it, you first

create a template and you apply to site one and then you’re

going to go and clone these sites, right? But since we made

these series of videos.

Step by step I would need to go ahead and quickly add the same

variable LAN one_mask to all sites Site 2 and Site three.

Click on save.

OK. And also we would need to go ahead and configure on Hub a

site. We’ll add the same variable, but as a reminder, it

would need to result to a slash 24.

Okay, we added our variables and next we would need to go ahead

and configure our networks. Okay. So next we’re going to

create this spokes land one network that is going to apply

to all spokes and the configuration that we need to

provide is going to be the following. The name is going to

be land one.

And the IP address of that network is going to be .0 ten

168 dot 1.0 slash 24 and we would need to configure as

discussed the source not pool prefix which we want to source

noted to 180 to 168.1 dot the site number. This is why we’re

using the variable and we’ll click on advertise to overlay,

meaning this network we will know now advertise to hub.

What is the IP? However, we’re going to override the prefix to

advertise instead of advertising the original network, which is

the 10168.1 dot zero, we would actually advertise the one

82168.1 dot site number and slash 32 because that’s the land

one mask that is going to be resolving on each site. And if

we look at the Mr. UI.

That’s how the screen looks like. Name IP. Here’s where I

clicked on advertise override prefix to advertise and so when

this is going to be again as mentioned applied to site one.

In this example, this is going to be the IP that we’ll be

resolving and when this network will apply it on Hub A for the

security policy.

It’s actually going to be resolving to the .0 slash 24 as

discussed in previous slide. So let’s quickly jump to Missdui

and configure this network. So we’re going to go ahead and

navigate to our networks and we can add a new network and the

name is going to be Spokes LAN One.

168.1 dot zero and it’s going to be a slash 24 segment in each

and every site. And then here is where we’re going to configure

the source, not pooled. We would want to source not this network

which is going to be one 92168.1 dot the site number and it’s

going to be a slash 32.

And we would want to advertise this via overlay. However we

would want to override the prefix instead of this 10168.0.

You can click on override prefix to advertise and you can then go

ahead and advertise this other the same 180 to 168.1 dot one in

this case, but the prefix length is going to be land one.

Mask okay so we can go ahead and click on add and here we can see

the new network has been added. Spokes LAN one and it shows that

we have a source not pool and this is again related to source

not pool towards the overlay.

In the next sections we’ll discuss static Nat and also

Destination Nat, but for now we have this only the segment is

only doing source Nat towards the hub. We also need to add the

hub, a LAN, one network and also application.

Because. But this is pretty simple. On hub a LAN one the

application itself, because we’re going to be communicating

from spokes towards this application, from network to

application. So it’s going to be only the prefix 182 one 68100.0.

And we’re going to also add a network that we would need to

apply on the hub added to the hub profile. And again, the

network is a pretty simple network configuration, no

nothing, just 180 to one, 68100, zero and slash 24. And we want

to advertise this via overlay, meaning the hub advertises this

network to the spoke. So obviously the spoke would know

how to reach this network when sending traffic towards this

hub, a land one application.

So let’s switch quickly to MSDUI and we’ll configure this one

network, the Hublin one, and also the application.

Okay. So next we’re going to go ahead and add our LAN one

network to the spokes template, one inch template and also to

the hub profile. So again, we’re going to be adding a new LAN

segment to this VSRX site one which is going to be the LAN one

using the network we have configured. And also on the hub,

we’re going to be adding LAN one as an additional host connected

to the VSRX.

So again, the entire, I mean all communication is between network

to and Applications and we have configured this application hub

a land one and the original spokes land one network is this

one 92168 dot 1.0 before it’s being source noted.

So if we take a look then on the VSRX on the spoke side, it’s

going to be going to hub a LAN one and we’re going to add G003

which is the next free interface we have. We’re going to apply

this network and we’re going to give it a DHCP server as well.

Just as an example, 10 hosts here, 254 is going to be the

interface here and very similarly on the hub.

We’re going to add the network we have created hub, a LAN one.

We’re going to add it to the hub profile, Hub a hub profile and

we’re going to use a TCP server as well, although not

necessarily, but we can use it as well.

Okay. So now once we edit the LAN one interface to each and

every device, let’s quickly take a look at our devices to make

sure we have the additional interface configuration pushed.

Already Show configuration interfaces. We can see G001 here

is LAN zero and we can see that we have a new interface G003.

Len one which is 10168.1 dot 254 as we have configured and we we

look at site two we would expect to see the same IP. As we

mentioned this is going to be an overlapping segment. Each and

every site has the same IP 10168.1 dot 254. This is G003 on

site 2 and obviously we have the same on site 3.

Here’s our site 3 and if we look at the hub, a routing table.

Well First off let’s look and see if we have an additional

interfaces added here as well. And here’s G004 LAN 11821 Sixty

8.100.254 and if we look at the routing table, VPN overlay.

We can see that we have these three IPS, the ones that we

configured as override prefix to advertise 18 to 168.1, dot one

and then dot 1.2 coming from overlay pointing towards the St.

tunnels, the Ipsec tunnels going to each and every spoke and here

is dot 1.3.

So we can see we actually have these three IPS which correlates

to the source not pool and the advertised prefix from each and

every spoke. So we should be good to go now to create our

application policy and then see if we have traffic flowing

between spoke and hub.

Okay. So now once we have created our networks and

attached them to the devices G003 on the spoke and four on

the hub, we can go ahead and create an application policy and

then a steering profile as we have done previously for LAN 0.

If you haven’t watched those segments, please go back and

watch the segments in Part 2 where I show you how to do this,

but in general.

We would add an application policy that will allow spokes

land one network going to an application hub a which we have

created and obviously the same will be applied on the hub and

so in order to do that we would also need to create on the one

inch templates for the spoke traffic steering profile.

In this case, we already have created 2VPN steering profile on

the spokes template because we have used the same steering

profile that was used for Land 0 going to the hub and on the hub

side we would need to create a new steering profile that

accepting traffic from the overlay and steering it towards

land 1 instead of land zero which we have created

previously.

So that’s going to be then profile name to LAN one and the

path would be hub a LAN one. And after we’ll do that, we can go

ahead and create an application policy in our central repository

for the applications, we’ll select the from network, which

is the from it’s going to be LAN one and then we’ll be able to

select our application since we have already added hub, a LAN

one application.

And the action would be allow and then in each one of these

spoke template and also the hub profile we’ll be able to import

this one single policy that we have created and then just to

apply the correct steering profile. So on the spoke

template we will apply the steering profile saying to VPN.

And on the hub, the steering profile would actually say to

LAN one because it would accept traffic from the overlay going

to LAN one. So let’s jump back to miss UI and we’ll configure

this application policy and also then import application policy

into each one of the templates and create the additional

steering profile on the hub.

Okay, so now that we have edited our application policy and

configured the steering profile on the spokes 1 inch template

and the hub profile config has been pushed to the device, we

can go ahead and check what’s the config for the source not

and the policy that has been applied on this device. So here

we are on site one and if we look at.

The source not configuration. We can see that there is a new

source not from zone spokeland 1 going to the overlay zone and

we’re matching on any address. But we are applying a source not

pool of 180 two 168 dot 1.1 slash 32 as we have configured.

Again, just a reminder, this is actually a name that is

resolving in the security address book.

To 180 to 168 dot 1.1 slash 32 and if we look at also the

policy we can see that source address our one 10168.1 dot 0/24

network which is the land one network on the spoke going to

the hub land one which is 180 to 168 dot 100.0 we are allowing

this traffic to go to the hub.

And if we also check on site 2, we can look at the source, not

we can see that we have the same source not policy, but the IP

the pool is applied, which is the two we can actually check

the pool maybe match on pool.

And you can see that there was a configured pool 182168 that’s

again the name and the address is 182168.1.2 because this is

site 2 and then obviously this is applied on the source not.

And if we look at our policy so we can see that the policy is

again the same exact policies we have in site one source address

one 10168.1 dot zero, same segment.

Going to the hub and the application is the policy is

allowed. Looking at site three we have as expected. We can see

that we have the source not pull configured to 182168.1.3 as it’s

site 3 and the same if you look at the policy again same same

segment.

And if we look at the hub, just to make sure we have the correct

policy, we can see that we are accepting traffic coming from

the overlay zone 180 to 168 dot 1.0 which is the whole slash 24

as we have expected and configured allowing traffic

towards this one host that we have on the dot 100.0 segment.

So traffic is allowed.

So we can go ahead and quickly check connectivity now. So

here’s site one, land one, host one. This is the host that is

connected to the site 1 spoke and if we list our interface we

can see that the IP is 10168.1 dot one.

EN S3 as expected. And also if we look at if we look at our

default route we can see that the default route is pointing

towards the 254 interface which is our interface on the VSRX.

And we can go ahead and ping our host on the hub one 82168 dot

100.1 and we can see that we are pinging.

And similarly here is our site 2 land one, host one is the one

that is connected on site 2. If config EN S3 we can see that we

have the same overlapping IP 10168.1 dot one on site 2 as

well. And if we look at our our route we can see that default is

again pointing to the VSRX and we can go ahead.

And check connectivity and ping our 192 one 68100.1. Again this

is the host on the hub site and we can see that we can ping also

from site 2. Although it is an overlapping IP of this VM, we

can ping the host as well and the same if we can go to site 3

land one host one.

We can see that also the IP is the same 10168.1 dot one and if

we ping our host on the hub we can see we can ping from spoke

as well. All right. So in this segment then we covered the LAN

one which is the second use case we wanted to show using source

not.

Going to overlay from spokes to hub, and again, this is useful

if all spokes are communicating with the hub, if you have some

workloads or resources, web service, etc. But in this case

there’s no communication from the hub to initiate towards each

and every spoke that is going to be covered in the next section.

Where we’re going to look at destination Nat, meaning the hub

would actually go towards the spokes and also we have static

Nat if we want to just Nat each and every IP on the spoke to the

hub. So in the next video we’re going to take a look at LAN 2.

That’s our third use case where we’re going to add another.

Interface on the spoke and on the hub. It’s going to have a

different IP address just so we can identify this use case. And

in this one we’ll show how to configure static Nat. And as you

will see, each and every host on the spokes is going to be

statically Natted to an IP going towards the hub, and so the hub

can have communication back.

To the spoke as well. That’s what it’s referred to as one to

one natting. So with that, see you in the next video and thanks

for watching.

P2:S8

Hi everyone, welcome back to our Mist, a driven SD1 configuration

guide series of videos. My name is Shari Donovich and I’m a

solution architect here at Juniper on the Mist, a driven

enterprise team and this is going to be Section 8 of Part 2

device onboarding using a full zero touch provisioning method.

If you recall in Section 2, I covered the other method we have

under Miss to onboard device and assign them to sites, which is

an adopted device essentially using a short configuration

commands to create outbound SSH to miss cloud. And since I’m

using a VSRX in my lab and VSRX does not come out-of-the-box

with the default config including phone home client.

I first showed you how you can adopt Vsrxs and onboard them to

miss cloud, but here I also want to cover now a physical device

how a ZTP process works and how you would use a claim code in

order to ZTP physical devices to sites.

I’ll be using an SRX 380 for that demonstration, but we have

a full variety of branch SRX devices that are actually

supported under Miss Cloud as part of our solution. So with

that let’s get started. Okay. So, so far we have onboarded 3

spokes site, one site, two site, three in a single hub, all using

Vsrx’s because this is my lab setup.

And we also have two LAN segments in each site, Len 0 and

Len one. If you haven’t watched the previous sections in Part 2,

I encourage you to go back and watch the previous sections as I

go step by step on how you would onboard VSRX is using the adopt

method and also configure the LAN segments and with the

different use cases, source Nat, etc.

But in this section I want to add an additional site. We’ll

add site 11 and in site 11 it’s actually going to be the same as

other sites, but we will be using a physical device, SRX 380

in this case and as every branch SRX also SRX 380 comes from a

factory from the factory with a claim code.

Imprinted on the device, usually a sticker that is found in the

front end of the device or on the backside of the device. It

is a short code that you will use in order to claim the device

on the missed portal and assign this device to specific site.

Once the device is on boarded, this device as well will create

2 Ipsec tunnels to Hub A the same as we have under site 1-2

and three. So essentially again each site that you on board

creates 2 Ipsec tunnels going from spoke in our case to Hub A.

If you have obviously 2 hubs it would go to two hubs, but as I

mentioned just for the purpose of these series of videos.

We’re going to be using one single hub, but in general you

know you would probably have two hubs. Okay. So if we take a look

at the ZTP workflow, here’s our SRX 380 that we’ll be using for

this site 11 and you would first need to locate the claim code

that, as I mentioned, imprinted on the front panel of the

device. Usually a small sticker with the claim code.

On the sticker and what you would do is under the inventory

page under Mist UI you would have an option to click on Claim

device or Claim device to site. Essentially the screen would

look like this. Pretty simple, you would enter your claim code.

You also have an option to select assign the device. Once

the device is ztped you will have an option to say OK well

automatically assign the device to a specific site. You can also

generate a name of the device once assigned to the site. In

this case it’ll be using site dash 11_SRX 380 just so we can

identify easily the site that has a physical device.

And similarly to adopt device to site, we’ll have an option to

set our root password or use the root password that is actually

configured under the site settings. Once you click on

claim, it would go ahead and communicate with the miss cloud

and the device would be assigned and ZTP to the site.

If we look at the SRX 380, we have two set of ports here.

There’s a one Gigabit Ethernet ports BOE Plus and we also have

a 10 Gigabit Ethernet SFB Plus ports. I wanted to show you both

ways to use either the one Gigabit Ethernet ports as your

Wan links 10 and one one but also the 10 Gigabit Ethernet

ports.

And the reason I’m mentioning this is because the SRX 380

comes with the default factory default config which has G000

which is the first port on the left side. The one Gigabit

Ethernet ports is configured DHCP client. In other words, if

you connect this port in your branch when you know when you

set up a new branch. As an example, if you connect it to

your service provider and you have a DHCP lease that is being

handled.

Over from your service provider equipment then G000 will get an

IP, but if you choose to have a larger branch and you would use

A10 Gigabit Ethernet interfaces. XE 0019 which is the last

interface in this box is also configured as DHCP client.

So we’ll use both methods. In fact, I’ll use one SRX 380 to

ZTP using one Gigabit Internet ports to Site 11. And then we

also use Site 12 and ZTP, an additional SRX 380 into Site 12

as I’ll show you in the next few slides.

So to start with, here’s an example. If we use G000 as our

branch device, it would get an IP and then once the box has an

IP, the factory default config will include a phone home client

that will reach out to a redirect server which will be

redirected to a specific missed cloud.

Termination point that will be actually pushing the config back

to the device and here is another option that I mentioned.

If you choose to use A10 Gigabit Ethernet ports as your as your

as your service provider connectivity then XE0019 would

actually also receive or are is able to receive a DHCP lease.

From a service provider using the factory default config that

the box comes with and then again communicate with the miss

cloud and the onboarding process and the ZTP process will

complete okay. So let’s then use site 11 to ZTP this SRX 380

using the one Gigabit Ethernet interfaces. And again what we’ll

need to do is we first need to create site 11.

We’ll just go ahead and clone site three or one of the site to

site 11 as we have previously done with other sites and then

we assign the spokes 1 edge template name spokes to site 11

as well. So we’ll have the same config because essentially the

SRX 380 will use the same port configuration.

As we used on the Vsrxes that means that G000 will be our win

zero and win one and then our LAN zero and LAN one would be

G002 and G003. So since the port are the same and the config is

the same so Juno, SSRX so everything is the same here and

so This is why we can actually use the same template for these

books.

So then once the site has been created and we assign the spokes

template to the site, we can as mentioned go ahead and use the

claim code we have on the device and claim this device and start

the ZTP process.

After the process finished, obviously the config will be

pushed to the device including the LAN interfaces and LAN

segments and so both interfaces when zero and one one will

become active towards the Internet and towards the using

the overlay Ipsec tunnels. So again just a quick reminder on

how we create sites.

We can clone one of the sites, just give it a name and the

location as the two minimum configurations. And also we

would need to change the variables to reflect that this

is site 11. And then once the site has been created we can

navigate to our one edge template spokes template and

select site 11 as well to be assigned to this template.

And then again we can navigate under the inventory page, click

on claim, enter our claim code and select Manage by Mist which

essentially going to also use the root password that we have

configured under the site settings and once the ZTP

process will finish.

We will see the device under the inventory page Site 11_SRX 380.

That’s the name that I will give this device in site 11 as you

can see here. And so once the ZTP is complete, we’ll be able

to go and select the device under site 11.

And we’ll see the front panel of the SRX 380 with the four

interfaces according to the diagram 1011 and it will LAN

interfaces and the one Edge Insight page and so on. So now

let’s quickly jump to the Missed UI and I’ll show you how to

configure this and then check connectivity from the device

itself as well.

OK, so let’s first go ahead and create site 11, navigate to our

site configuration and then let’s pick up Site 3. We can go

ahead and click on Clone Site, OK? And then give the site a

name. We’re going to name it Site 11 and we’re going to set

our location, which is again my lab is the same location.

And one thing we want to do is we want to update the site

variables here. So if we will Scroll down to Site variables

here is where we want to update the value for 11 because this is

going to be used to set the LAN segments as you recall from

previous sections. Click on save.

The LAN zero mask and Len one mask is actually going to be the

same, so we only need to change this variable here and then we

can go ahead and scroll up and click on save to save this site

11. And as we can see site 11 here has been created and so the

next thing we want to assign the same spokes template to site 11.

We can navigate to our one edge templates, click on our spoke

template and as of now we can see it says 3 sites with three

One edge devices. Click on Assign to sites and here’s where

we can select our newly created site which is site eleven. Click

on apply.

Now we basically have four sites that this same template is

assigned to them. And again since in this case our SRX 380

will be using G000 and G001 as Win Zero and Win one, we can go

ahead and use the same template as we have used for our VSRX

devices.

So next we’re going to go ahead and navigate to our inventory

page. We can see our four devices, the three Vsrxs site

123 and here is on the top right hand side we have those two

options to onboard devices as mentioned adopt one inch device.

This is where you would copy the outbound SSH config that we have

done.

In previous sections when we’re onboarding the Vsrxes, but here

on the left hand side there is a Claim One Edge device which is

essentially using a full ZTP process using a claim code for

physical VSRX. So you click on Claim One Edge device and we can

go ahead and enter our claim code, click on Add.

And then we wanted to assign the device automatically to the

newly created site. So we’ll pick up site 11 from this list

here and we can also generate the name, the host name for this

device and we wanted to call it site 11_SRX 380 just so we can

identify this device which is different from the Vsrx’s.

And we’ll select the Manage configuration with missed and we

have this root password that we have already assigned in our

site settings. And so now we can go ahead and click on Claim. But

before we do that, let’s quickly look at the device, the factory

default configuration.

To verify that we have connectivity and you know we

have an IP that has been handed by the DHCP server. So here’s

our SRX 380 device console, and if I try to log in with root as

a user, you see there’s no password, which means the device

is in a factory default.

State either after zeroizing the device or out-of-the-box. That’s

how the config actually on the device. So if we go ahead and

look at our interfaces and we can match on DHCP.

You can see that there are two interfaces which are configured

as DHCP client. This is the first interface on the box as I

mentioned GE000 and also the last interface on the box which

is the XE 0019 which is a 10 gig interface. But for now for this

use case we’re going to be Zdping this device to site 11

using the Gigabit Ethernet interfaces.

So we would accept we would expect to have IP on G000. So if

we are going to go and take a look at our route table we can

see we have default pointing to site 11 which is 101102.

And it’s pointing to 101101 as our gateway and we can just

quickly check connectivity as we always do to make sure we can TP

the device and also we can go ahead and do to make

pinggoogle.com to make sure we have DNS resolution as well.

And so we’re going to be ready to ZTP this device. Also just a

quick note on the redirect server and the home home phone

home client, if we take a look at our configuration match phone

HOME, you can see that we have basically phone home server

which is redirect to juniper.net.

And this is how the device will reach out first to the redirect

server and then will be redirected to the miss cloud in

order to be ztped by the Miss Cloud. So now we can go ahead

and click on claim and we’ll get a message saying device has been

claimed and assigned to the site as well Click on close.

And we can see here the device showing up on under the

inventory page. At this point it says disconnected because it

hasn’t been yet. You know the config has not been applied yet.

It will take a few minutes and then once the config, the

configuration will be pushed by the missed cloud to the device.

We will be able to see the device turns green, state will

be connected and we can navigate to the device as well. So after

a few minutes the device has been ztped and configured. If we

refresh the page, we can actually see that the device

shows up as connected which is online.

And you can click on the device, you will navigate to the device

page and here we can see that we have our four interfaces, 2 Wan

interfaces and two LAN interfaces. And if we click on

one edge insights you can see that we have our two Ipsec

tunnels and they are going to Hub A and other useful

information that we’ll cover in the next few videos.

And if we quickly switch back to our device console, we can also

see that we have the two Ipsec tunnels that are open from this

device going to hub A. And if we list our interfaces we can see

that we use G00 for one, zero and 11G001 and then also G002.

As our LAN interface. And by the way, since this is site 11, we

can also see here that we have 10, zero, 11 to 54 as our

interface address based on the variables that we have

configured in previous sections and are part of the

configuration template for the spokes.

So let’s go ahead and onboard an additional SRX 380 device to

Site 12. And again, this is just an example to show SRX 380 using

A10 Gigabit infinite interfaces or Wan interfaces as I mentioned

in the previous.

Slides. And again, the LAN interfaces here will remain the

same G002 and three. And the only difference we’ll be using

the 10 Gigabit Ethernet interfaces is our Win Zero and

Win One. And they’re going to be connected the same kind of to

our two ISPs.

And then the same process or the same workflow will exist on

claiming the device using a claim code and adopting it,

assigning it to site site 12 and as I’ve mentioned SRX 380

factory default config includes XE 0019, the last port as a DHCP

client.

So potentially if you connected to your service provider and you

have a DHCP server that would hand out an IP to this

interface, the device will be able to ZTP to the missed cloud

after the config will be pushed. Obviously we’ll be also using

Wan one as an additional Wan interface as well.

So the first thing we would need to do is we would need to create

an additional 1 edge template. Similarly to the template we

currently using which named spokes, we’ll create an

additional template by cloning the existing template.

We’ll use 10G the spokes to identify that this new template

is going to be used for our sites that we have a 10 Gigabit

Ethernet when interfaces for some sites.

Right. And so again, the differences are that we would

change when zero and when one. Instead of having G00 and G001

interfaces, we’ll assign XE zeros and 19 and 18, and pretty

much that’s the only difference would be between the two

templates. But again, we would need to since you can’t use

variables for the interfaces, we will create a new template.

And we’ll name it 10 G just to identify that this is a template

that is going to be used for sites who has devices with 10

Gigabit Infinity interfaces. So similarly to site 11, we’ll go

ahead and create site 12 by cloning one of the sites and

changing the site variables to point to site 12, basically the

site number that we are using.

And then once we have site 12 and 10 gig 10G spokes template

has been created, we will assign this template only to site 12 as

you can see here in the picture below. And then once the site is

created and we have the template, we can go ahead and

create our add our claim code under the inventory claim

device.

Assign it to site 12, we’ll give it a name to the device, site

12_SRX 380-10G just to identify the device again. And the root

password is the same as previously is taking from the

site configuration. And once the ZTP process will complete,

you’ll see the device shows up as connected under inventory and

we’ll be able to navigate.

To the site, if you click on the device, we will see that G002

and three are our LAN interfaces and instead of G00 and G001

we’ll have our 19 and 18 as our 10 Gigabit Wan interfaces. So

with that let’s quickly jump to Missed UI and I’ll show you how

to clone the template.

And then create a site and then I’ll speed up the video to ztp

the device to the site as well. Okay. So first thing let’s go

ahead and navigate our one edge templates and here is the

template that we have created and we’ve been using so far

Spokes if I click on this template under more actions so

we can clone this template.

And we’ll give it a name, 10G spokes clone. And what we want

to do is, as we discussed, we want to change the interfaces

instead of G000 and G001 for our win Zero and Win one interface,

we’ll change it to the 10 gig interfaces. So clicking on G000

and we’re going to go ahead and change it to XE.

0019 which is the first interface. Everything else stays

the same and the same goes for when one we’re going to go ahead

and do change it to XE 0018 and click on save and again XE 0019

by default from a factory default config.

It has a DHCP client enabled, so we’ll be able to get an IP and

ZTP this device. So after we change these two interfaces, we

can go ahead and click on save and then we can navigate to

sites and we can clone site 11 clicking on clone site, OK and.

We’ll name it site 12 and give it a location and then click on

Oh, before we click on save we want to change the variable for

the site which is the site_number. This is here. So

site_number would now be equal 12 because we are onboarding

site 12 to our setup and then we can go ahead and click on save.

So once site 12 is created let’s quickly Now we have these two

templates, 1 inch template, 10 gig spokes or 10G spokes and

spokes and under 10G we can assign only site 12. The other

sites are using the other template. As you can see it says

here spokes. You click on apply it would say this template is

assigned to one site. However we have not yet.

Onboarded any device is why one inch devices shows up as zero,

right? But again now we can see that site 12 is assigned to this

template and the other sites are spokes Hub is actually the hub

profile. So once this is assigned we can go ahead and

click on our inventory one inch devices and we can see here we

have the SRX 380 that we have.

Previously ztped using the 1 gig interfaces and we can go ahead

now and click on claim one edge devices or click claim one edge

and we’ll go ahead and enter our claim code. Click on add and we

want to assign this device to site 12 and let’s go ahead and

also generate.

The host name for this device, so site 12_SRX 380. Then you

want to name it 10 G just so we know that this is using the 10

Gigabit interfaces and once we’re happy with that we can

click on claim message saying the device has been claimed

successfully.

And it is now shows up under inventory as disconnected. But

in a few minutes once the device will reach out to our phone to

our redirect server and then to miss cloud, it will be ZTP. Then

the config will be pushed to the device and after a few minutes

we can go ahead and refresh this inventory page and as we can see

now the device shows connected. Here’s our site 12.

And we can navigate to the site and here is we see our exe 19

and 18 which are one zero and one one interfaces and the two

LAN interfaces that we have so far for the two use cases. And

if we quickly switch to our device console here we can see

that the prompt.

Has changed to the name we have assigned to the site site 12 SRX

380-10G and if we look at our route table we can also see that

our default route now pointing through XE 0019 on the 12:01 and

1:00 and 1:00 is 12.

11101211 and also if we take a look at our hub we can see that

if we list our security Ipsec tunnels we can see that now the

hub is connected to all five sites site 1-2 and three and

also site 11:00 and 12:00.

On 11/02/11 zero, one meaning two IP SEC tunnels to each site

and also if we take a look at our routing table on the hub we

can see that here is each site advertises the first LAN 0

segment 100123100, eleven and 1012.

And we can also see the 190 to 168 if you recall this is the

second use case we have covered already for the source not and

each site is advertising a unique IP that that is being

that you know the land one segment is being source noted.

So here are the two new sites we have edit .111 and 190 to 168.1

dot 12.

Okay. So then we also added site 12 for the 10 gig interfaces and

again This site is also connected via the overlay to IPC

overlay tunnels. And so you know, essentially we have added

also these two physical devices to our lab setup, the SRX three

80s.

And the next segment, we’ll continue describing our third

use case, which is the static Nat from and to overlay using

LAN 2. That’s going to be our third LAN segment that we’ll add

and we’ll show you how to configure this use case as well.

So with that, see you in the next section and thanks for

watching.