WAN Assurance Configuration Overview

Hi, I'm Nick Norman. Welcome to the AI-driven SD-WAN session. WAN Assurance in the Juniper Mist cloud abstracts away complex technologies and provides a simplified user experience.

We leverage zero-touch provisioning, which is available in all cloud-ready Juniper devices, to eliminate the need for double shipping and remote hands to onboard new equipment. Leveraging variables and multi-device configuration templates within Mist, WAN Assurance increases efficiency and allows users to work from a set of common elements that apply across the entire self-driving network domains of Wireless Assurance, Wired Assurance, and now WAN Assurance. WAN Assurance is built on top of the success that we've seen across the other portfolios, from Wired Assurance to Wi-Fi Assurance, and now WAN Assurance.

This gives us full view of the network from the user's point of view. Why is my Zoom call breaking up? The platform is cloud-native and AI-driven. What you're going to see are examples of how we go through the setup of a device using WAN Assurance from day zero all the way through to day two.

Onboarding, deploying, and operating is completely simplified using Mist. WAN Assurance is focused on a couple use cases, standalone full stack deployment of branch secure routers, branch firewalls, and then hub-and-spoke SD-WAN deployments. We support the BSRX platform all the way through to the SRX4600.

WAN Assurance day zero. Who are my users and device segments that I'm talking to? What applications are they using? What's my topology? Am I setting up a standalone full stack deployment or am I doing a hub-and-spoke SD-WAN deployment? How sessions are delivered through policy and at what scale? Have I deployed my templates using variables so that I can leverage one variable across multiple sites or several sites using the same template? Just a quick illustration, visual illustration here of the two main focuses for WAN Assurance, the topologies. So we've got on the left the full stack where we've got Mist APs, EX switches, and either SSR or SRX gateway devices all being managed in the Mist Cloud.

On the right side, we have similar remote sites that are full stack and they are building a SD-WAN topology through hub devices. And you'll notice that our steps for standalone versus hub-and-spoke are very similar. With both, we create a site and have site-specific variables.

We have networks and applications that we're going to create and then use in those templates. We're going to create those WAN edge templates for a standalone device and we're going to assign bind that template to a site. Change to a hub-and-spoke topology, we're just creating a hub profile.

A couple of high-level definitions here. We've got our WAN edge template which is made up of several different components. We've got hub profiles.

The hub profile automates the overlay definition with a path per WAN. We have networks that we define the subnet. We create these LAN segments and then use those in the template.

And then we have applications that we pick up within the template as well. Diving down into the overlay a little bit more here, Mist is a certificate authority and generates transfers of certificates used to authenticate IPsec tunnels created between the hub-and-spoke devices. IBGP is also set up.

Later on in the presentation, you'll see where we select to advertise certain LAN segments on the overlay. This is what is then picked up by IBGP and announced to the different sites via the hub. We also create automatic failover on the WAN links.

We have a probe that will detect a failover and reroute traffic automatically when that probe fails. Here we've got our high-level slide here showing some of our new menu items here under the WAN edge portion of the platform. Diving right in at step one, we're creating a site and some site-specific variables.

Here in our example, we've got a DNS variable or DNS1 where I've got the 1.1.1.1 DNS servers defined. Also calling out here that the platform uses a lot of application visibility, and I've selected here that my device has the WAN edge application visibility. Through the checkbox, Mist will automatically deliver the AppTrack database to my device.

For step two in the network side, who are my users and devices, and then how is my network segmented? Here I'm showing my DC1 servers. That is my 10.0.0.0 slash 24 subnet, and I've got my spoke corporate as my 10.10.2.0 and 10.10.3.0, depending on what site it is. These resolve specifically to each site.

Then I've got a 172.16 spoke guest network that also changes to .2 to .3 to .4 in the third octet for my site ID. Diving into the define a network detail screen here, I've given my network a name. I've used those variables there, called out then specifically at the site.

We've got the checkbox for advertise via the overlay so that it will pick up this subnet in IBGP and advertise it. We also have access to Mist cloud, so I've got access points and switches behind this WAN edge device. This will automatically allow common ports to connect to Mist cloud like 6514, 2200, and 443.

In this example, I've got a specific printer, a 10.10.2, 10.10.3, whatever it may be, .10 that I would like to reference specifically. We also have the ability to dive into static source NAT, source NAT pool, and destination NAT. In step three, we've got our applications.

These are what are my users connecting to in the application detail screen here. You can see I've got those public DNS servers for Google and Cloudflare called out, and we've got our protocol UDP53. So this combines layer three and layer four.

We also have support for dynamic or application from the application database. Here I've got Spotify layer seven matching. A lot of the screens we're going to see within our device templates are the same for hub profiles.

The difference between a hub profile and a device template is that the hub profile is applied to an individual device that's at a site, and the templates are bound to sites that can have multiple devices and bound the same template across multiple sites. Hub profiles drive the addition, removal of paths on your overlay, and then that's what you will see then on the spoke side to pick those. Here we have our WAN edge templates.

I'm going to drive into detail this a little bit more. Here I've got some elements I can configure like my DNS server, my NTP servers as well. I've got our WAN links here to start off with.

We're going to create two WAN links. I've got ge-0/0/0 on my first WAN or WAN0. I've also given it an IP address, 10.11.0.2. It's a 10.11.0.1. It's my gateway.

Default route will be added automatically then based on that. I don't need to do any further static routing. If I needed to announce or if I needed for Mist to pick up a different public IP address than defined on this address, we have the ability to override there.

In the gray box, I would give my public IP address. If I was deploying in some type of cloud environment where my device had a private on it but yet it had a static NAT, I could give that IP address here. Here I've got my WAN edge template for the LAN.

Here I've got my LAN portion of the template. I picked that LAN network from the dropdown list from the available networks that I've defined previously. Then I've inserted the related IP information and defined whether I want this to be tagged or not on my interfaces.

Again, I'm using variables here. I'm using variables within the DHCP. Just to call out that previous screen, I showed DNS1.

You can see that variable down below here I'm using in the DHCP scope. Further on in the WAN edge template, we've got our traffic steering profiles. I've got three different examples called out here.

My underlay path, this is where we are defining our path out to the internet. Here I've got my WAN links captured. When I use this traffic steering path in a policy, it will create a security policy on the SRX device to those zones.

There'll be policy two WAN zero and policy two WAN one. I've also got my LAN path here. If I use this as an inbound, maybe a DESNAT rule where I had servers on ADM443, I would then use the traffic steering path of my DC1 servers in that rule.

I've got my overlay path as the last option here where I would then create policy to allow maybe phones from this spoke to the hub or something of that nature that I would put in the traffic steering path of the overlay. Diving into the detail of access policies, you can see here as I click on the plus, I get little dropdown boxes and I can see those network elements. For instance, that printer that I had specifically defined there or those network elements that I have created previously would show up there on the left-hand side.

It also resolves into my source zone for that traffic. Then I've got my application on the right-hand side, whether my action is permit or deny. Then we've got our traffic steering all the way on the right.

Just stepping through these policies a little bit, our first policy is for local breakout or internet going, my traffic going out the internet from my spoke corporate. I've got my guest network also allowed to go out the internet, but I've restricted that to guest web application, which is ADM443, and then public DNS servers. Specifically to those public DNS servers do I allow this spoke guest traffic to get to.

I've got a spoke out and a spoke in. This would be maybe my slash 16 aggregate allowed to talk to my slash 16 coming in. Maybe I have phones between my branches that I want to have connectivity.

Then I've got a policy at the bottom here for my overlay. It would allow any other traffic that would match that to go on the overlay. Here on the hub side, I've called out an example of what that looks like here.

Very similar. I've got my DC servers allowed to go to the internet. I've got this inbound ping rule, so this is a corporate network coming in.

Yeah, so it does allow ping, but it's from the overlay, not from the untrust. We also have the support for additional CLI commands. This would be things that I may want to use to push to the device that MIST may not have a graphic element to support yet.

We're assigning that WAN address template to a site, getting into a specific destination NAT example. Here we've got a public SSH server coming from the internet on the left side there. That's a network that I've defined as quad zeros.

MIST understands that to be from the WAN zone, whatever I define as my WAN. Then here I'm coming into my server via SSH. That is a specific application I've created with the ports TCP 22.

It's coming into my DC1 server zone based on the traffic steering profile. This is some screens to show what that network looks like on the left there, the internet. Then on the right, the destination NAT created on the network.

Here we've got the screen captured here on that application as well. As I mentioned, port 22 going to that DC corp net values here. I can use variables as well.

Maybe I've got the same kind of service across multiple sites. I can make sure it resolves to the correct IP address using these variables in the traffic steering portion of DESNAP. Outbound NAT is handled on the WAN interface.

Here we've got our source NAT enabled there. Source NAT interface is what we're leveraging. Now we're into day one.

Here we've got our claim code on our devices that are shipped out. We can use that claim code to activate or adopt our WAN as devices. Effectively, just to want to call it here, Greenfield versus Brownfield.

Greenfield being brand new devices, Brownfield being devices that may be already deployed with configurations. You want to use zero-touch provisioning or claim on the Greenfield devices versus adoption on the Brownfield devices. Sample screen, what that looks like here.

I can input my claim code. We also have the MIST app that you can use to onboard your devices. Here's a couple of screens on what a Brownfield adoption may look like.

Once our device is online, we can see the templates that are bound here. Also support device level overrides. Here I've got a DNS that I'm overriding by checking that box at the top there.

It's showing what was inherited from the template in gray. By checking the box, it becomes editable where I can change that. On more into day two, I think here we've got some, you know, I can see the status of my tunnels.

I can also see config differences here. I've got a commit that came through and I can click under the diff. We also have a remote shell we can open up on the device page and get into do maybe more troubleshooting the shell itself.

Hey, thank you for your time.