I’ll be walking you through a series of videos in the form of detailed configuration guides for our Mist AI driven SD1 solution supporting the SRX platforms. Okay, 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.
[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.