Hi, I’m Nick Norman. Welcome to the AI Driven SD-WAN session. WAN Assurance in the Juniper Mist cloud abstracts away complex technologies, provides a simplified user experience. We leverage zero-touch provisioning, which is available on 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 all across the other portfolios, from Wired Assurance to Wi-Fi Assurance, and now WAN Assurance. This gives us the 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 0 all the way through to Day 2. On boarding, deploying, and operating is completely simplified using Mist. WAN Assurance is focused on a couple of use-cases, standalone full-stack deployment of Branch Secure Routers, Branch Firewalls, and then Hub and Spoke SD-WAN deployments. We support the vSRX platform all the way through to SRX4600.
WAN Assurance Day 0. 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 SDwan 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 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 APIs, EX switches, and either SSR or SRX gateway devices all being managed in this 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 notice that our steps for stand alone 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 the path per WAN. We have networks that we define the subnet, we create these LAN segments and then use those in the template. And 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 the 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 then picked up by IBGP and announced to the different sites via the Hub. We also create automatic failover on the links. We have a probe that will detect a failover and reroute traffic automatically when that probe fails.
Here we’ve got a high level slide showing some of our new menu items here under the WAN Edge portion of the platform. Diving right in at Step 1, we’re creating a site and some site-specific variables. Here in our example we’ve got a DNS variable or DNS 1 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’d just like to hear that my device has the WAN Edge application visibility. Through the checkbox, Mist will automatically deliver the uptrack database to my device.
For Step 2 on 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 10000 /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. It also changes to .2 to .3 to .4 and the 3rd 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 with the site. We’ve got the checkbox for Advertise via 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 the 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 a static source NAT, source NAT pool, and destination NAT.
In Step 3, we’ve got our applications. These are what are my users connecting to? In the applications 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 UDP 53. So this combines layer 3 and layer 4. We also have support for dynamic application from the application database. Here, I’ve got Spotify layer 7 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 have multiple devices and bound with 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. Going to drive into detail of 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 links. I’ve got ge0-0-0 on my first WAN, or wan0. I’ve also given it an IP address 10.11.0.2. It’s a /30, so 10.11.0.1 is 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 grayed out box I would give my public IP address. So if I was deploying 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.
And 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. And just to call out that previous screen, I showed DNS 1. You can see that variable down below here, I’m using it 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. And here I’ve got my web links captured, and so when I use this Traffic Steering path in a policy it will create a security policy on the device to those zones. So there will be policy to wan0 and a policy to wan1.
I’ve also got my LAN path here. So if I use this as an inbound, maybe a dst-nat rule where I had servers on 80 and 443. I would then use the Traffic Steering path of my DC1 servers in that rule. And 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 then as 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 the little dropdown boxes and I can see those network elements. So 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.
And then I’ve got my application on the right-hand side, whether my action is Permit or Deny. And then we’ve got our Traffic Steering all the way on the right.
Kind of just stepping through these policies a little bit. Our first policy is for local breakout or traffic going out the internet for 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 80 and 443, and then public DNS server. So specifically to those public DNS servers do I allow this spoke guest traffic to get to.
And then I’ve got a spoke out and a spoke in. So this would be maybe my /16 aggregate allowed to talk to my /16 coming in. Maybe I have phones between my branches that I want to have connectivity. And then I’ve got kind of a policy 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 may not have a graphic element to support yet. We’re showing assigning that WAN Edge 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. And then here I’m coming into my server via SSH. That is a specific application I’ve created with ports TCP 22 and 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 and then on the right, the destination NAT created on the network. We’ve got the screen captured here on that application, as well. As I mentioned port 22 going to that dc_corp net value here. I can use variables as well. So 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 dst-nat.
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.
And now we’re into Day 1. 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 Edge devices, effectively– just to want to call out here– greenfield versus brownfield. Greenfield being brand new devices, brownfield being devices that may be already deployed with configurations. You’ll 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. And 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 overwriting by checking that box at the top there. So it’s showing what was inherited from the template in gray and then by checking the box, it becomes editable where I can change that.
On more into Day 2. I think we’ve got– 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 in to do maybe more troubleshooting the shell itself.
Thank you for your time.