Group-Based Policy Configuration Overview (Mist)

Hello and welcome to the Juniper Networks Campus Fabric Group-Based Policy Microsegmentation Overview and Demo. Juniper, driven by Mist AI, supports various campus architectures based on EVP and VXLAN. The Campus Fabric IP Clos architecture extends EVP and VXLAN from the core through the distribution down to the access layer.

One of the main deliverables for customers implementing this solution set, this architecture, would be support of varying degrees of microsegmentation. Microsegmentation can happen within the VLAN itself, within the broadcast domain, and is typically supported through proprietary technology such as private VLANs. Private VLANs have been around for some time, but lack scale, lack interoperability, and are very difficult to extend past a single switch.

Group-Based Policy is a standards-based implementation that leverages the VXLAN header that we'll see in the next slide. Notice intra and intra-switch support of microsegmentation, as well as dynamic GPP or scalable group tagging with the access control device. This allows the access layer switches to build firewall filters not on MAC entries, but on scalable group tags, which provides a condensed look and a much more concise look.

Group-Based Policy is supported at the same level where devices authenticate into the network at the access layer. You notice the Group-Based Policy ID and where it sits within the VXLAN header itself. And as critical as traffic leaves the switch, the ingress switch, that VXLAN Group-Based Policy ID is routed across the network, lands at the far end, VXLAN VTAP is stripped off and policies are applied at that point.

This particular demo focuses on GBP microsegmentation capabilities within the same switch. Although GBP is supported across an EVPN VXLAN fabric, Juniper supports GBP microsegmentation capabilities within the same switch. In this case, a medical department laptop and mobile X-ray device are both plugged into the same 4400 access switch.

They both authenticate against the FreeRadius server where they receive VLAN information. They receive disparate scalable group tags. And the 4400 firewall filters are applied to drop traffic between these two scalable group tags within the same switch.

Let's move on to the demo. We're here at the demo at desktop one. IP address of 10.99.99.99. We have desktop two.

IP address of 10.99.99.42, both in the same broadcast domain, VLAN 1099. And we have our 4400 switch. First, order of business to validate both devices can communicate outside of its respective VLAN.

Let's reach 1.1. We're routing this through the campus fabric accordingly. Second item we want to validate is the fact that both devices have dynamically authenticated against the Radius server, and those credentials have been passed on to the 4400. Notice a couple of discrepancies.

The first, remember the picture we had before, port 11, that is our laptop, our medical laptop. It has a supplicant, but it's a Mac-based supplicant. So there might not be anything on that laptop specifically other than just its Mac address that it's authenticating with.

This could be an older device that does not support a .1x supplicant. You'll see Mac Radius here as our method. We're placing the 10.0.9.9, and we have received a dynamic group tag of 200.

This is our scalable group tag. Down below, this is our X-ray device. It does have an .1x supplicant and username.

Notice there's a Mac address also that's associated with that. Authentication method is Radius, the same VLAN, and we've received a different group-based tag, different scalable group tag. So this demonstration really is very similar to private VLAN, where you have multiple devices in the same VLAN, in this case on the same switch, but these devices have to be isolated entirely.

That's a proprietary implementation amongst all vendors, and it's almost impossible to support across multiple switches, and certainly across a dynamic fabric or a large network. So let's try to ping Desktop 2 from Desktop 1, and this should fail, and it does. Going to the 4400, we look at our firewall filter, and we do see that the filter is being hit.

For each connection, and we also want to spend a little bit of time and look at the firewall filter. You'll notice that a vast majority of the filtering is done at the group-based tag, so I don't have to manage a large, extensive Mac address filter ACL. You'll notice I do have a Mac address filter down below, and this might be for one-off environments, where you might need to implement this particular filter, but for the vast majority of what we're testing and showing today, this is focusing on the group tags, from source group tag to destination group tag, whether we discard or we accept, and we also always add counters, so there are firewall filters up top here will be hit.

Hopefully this demonstration's been valuable. Next demonstration, we'll focus on extending this capability across an EVPN VXLAN fabric. This particular demo extends GBP market segmentation across EVPN VXLAN fabric.

We add an additional device to this demonstration, mobile X-ray number two off EX4400 number two. You'll notice that all devices are placed in the same VLAN upon authentication. They all receive disparate scalable group tags, and yet the policy is implemented on both the 44001 and 2 switch to allow SGT100 to talk to SGT300, but this allows any communication between the medical department and both X-ray one and X-ray two.

Let's move to the demo. Let's jump into demo two. You'll notice we have desktop one and desktop two, our partners in crime from the first demo.

We have also added desktop four, which is attached to switch number two. So remember the diagram we just showed. This switch, this device is attached to port number 12, multi-gig port on access switch number two.

This device is also in the same VLAN as the other devices, VLAN 1099, its IP address is 10.99.99.23. What we wanna show here is that it can reach out to the internet. And so let's kind of do the same thing we did before. Let's go look at authentication, real-time authentication requirements on both devices.

We see we've got both devices authenticated as we had before on access switch number one. We also have the same type of authentication requirements on access switch number two. Notice that this X-ray machine is falling back to Mac supplicant.

So there's no .1X supplicant on this particular device in the same VLAN. And we are now actually in GBP tag 300. So we have three distinct GBP tags or scalable group tags, 100, 200, 300.

200 is completely isolated from 100 and 300 and 100 and 300 can talk amongst themselves. And so the connectivity between these devices should be as such, I should not be able to ping desktop two or desktop four from desktop one. From desktop two, I should be able to ping desktop number four, which I can.

I should not be able to ping desktop number one, which I can't. And then across the network, I should be able to ping desktop number two, which I can. And once again, I should not be able to reach desktop number one, which is discarded.

And as with anything, we look at our firewall filters here and we see those particular filters incrementing depending on what type of flow is coursing through the system. You'll also notice that both devices have very similar, if not identical, firewall filters. In this case, it makes sense to keep them the same.

In some cases, maybe not, but you'll notice that once again, we focus on the group-based policy source and destination tags on both. So hopefully this demonstration was valuable. The focus of this demonstration was to validate and verify micro-segmentation using group-based policies across a campus fabric running EVP and VXLAN.

Thank you.

Okay. Welcome back to the second demo, which is group based policy micro segmentation leverage leveraging the Mist cloud. So remember, we just build a fabric, a campus fabric, IP-Clos.

We did that just, a couple of minutes ago, and we now have full, telemetry from, from the campus side of it. So you notice that access two here now is fully green, and we've got some nice, nice telemetry coming in. A couple things that, I I really wanna show as well, and I'll include this in this particular, piece of the demonstration is EVP and insights, switch insights. This is really valuable information, deep seated telemetry that, customers can use to determine the state of the network.

And, what we see here is we've got access to and for of course, we could we can go back in time, over the last, you know, twenty four hours, seven days, last sixty minutes to just to take a look at what's happening. And you we see here, of of course, it's very important when BGP peer state changes. That's something that we absolutely want to understand. Why did it go from, you know, established to active or active back to established.

Certainly established is what we wanna see. This is the the latest, update from, the cloud. So the cool thing is is that, you know, the the campus fabric, once it's built, we can leverage, once again, the the telemetry across these links to, pull into into the Mist UI to make, discernible information for the end user. So let's jump into a group-based policy.

First of all, what I want to do is I want to verify that my desktops can communicate. So I'm gonna go ahead and hit ten nine nine.

Let's do a traceroute first of all. Let's do a traceroute to ten nine nine nine nine nine nine.

First of all, let's ping it.

Alright. We're able to ping that. Good deal. Okay. So the trace route probably didn't work because I don't have TTL turned on. So, we've got our ping going here. I'm able to ping obviously back to the workstation.

Okay. I'm able to ping out to the Internet.

Good deal there. And let's go ahead and trace route back to Internet again just to make sure that I am using, the path that I want to use, which is ten nine nine nine nine dot one. Okay. Good deal. Alright. So, let's keep the ping going there.

I'll keep this ping, to the Internet. Let's just do that. Okay. So, what we're gonna do is we're gonna build a policy through the Mist UI, and using a template based construct.

So here if we look at, we go to organizational switch templates, what's cool about templates is that we can build pre build information, whether the system's operational or not. We talked about that earlier in the campus fabric build. But here we've got predefined not predefined. We've got we've got defined policies based on what we call group based policy tags.

So a GBP tag is a standard, mechanism to share tagging information across an EVPN/VXLAN network.

So remember, we've got access one and access two. They're connected to this fabric. We've got desktop one, desktop two connected back through access one and access two, and they're routing through this EVPN VXLAN network. The VXLAN header itself has a sixteen bit tag, and that's where the group based policy construct resides.

So what Juniper has done, we've done this for some time, we fall into, really fall into standards. We we believe that this is the right approach for us and for our customers is to leverage standards that are already built so that we don't have to reinvent the wheel.

So what we've done here is we've built, some current tags and which are which are relatively straightforward. So for instance, guest Wi Fi, that entire network, which is a VLAN ten o one one o three three, irrespective of where it's located, will have this tag, one zero three one zero, three three. Our contractors that are coming in can have a different type of tag based on maybe an IP subnet. So the way that GBP can be associated, it can be associated with a MAC address.

It could be associated with, an IP address, a range of IP addresses. It could be associated with a VLAN, and, also a port. So you can actually create a VLAN port combination.

So what we're what you're looking at here are tags that are that are defined, and they're defined through this interface. And you could see that this is actually relatively straightforward. Now what makes it even easier is you come down here to our to our switch policy, and and we basically say, look, contractors can't talk to developers or IT staff.

And and so by default, that's gonna block them, but they'll be able to access everything else. IT staff and developers, we certainly want them to communicate. And the reason why I have this here is because the desktops that I'm gonna communicate from, or between are, desktop one is part of IT staff. It's part of that particular subnet, ten nine nine nine nine.

And, desktop two is part of developer subnet, which is ten eight eight eight eight. So what I want to do is really just have my allow all policy, and I'm gonna build a new, tag for desktop one, and we're going to assign to its particular IP address. Now we can use a this is going to be, think of this as almost like a host IP address. Let's assign that ninety nine, and then we'll assign desktop to eighty eight. Okay. Remember they are in distinctly different, subnets, although the subnets by default can communicate amongst themselves.

Okay. So we're pretty much doing like an override to that particular, switch policy which we're gonna create right now. So we're gonna call this we're gonna call this desktop. So what I wanna do here is basically select from a group of options here.

I'm gonna say select desktop one. We're gonna go desktop one, talking to desktop two, and we're going to block that. Now I could have multiple devices here. I I can really be pretty flexible in how I build the switch policy.

Okay. So that makes sense. If you look at it, it makes sense. It's human readable format.

We're in pretty good shape, and we are still pinging from, desktop one out to the Internet. Obviously we we wouldn't expect that to change. And we've got, desktop two ping desktop one. So let's go ahead and push out this policy.

Alright. So I'm gonna go back over here to our, active ping, and we should see this policy any second here stop.

And it looks like it has.

Okay. Cool. So I'm still able to ping the Internet from desktop one, that hasn't affected me.

And I can't ping ten eight eight eight eight eight eight, and I can't obviously do that here either. So, you know, although I should be able to ping other, you know, other devices and other subnets here from this workstation, I'm just not gonna be able to ping the host ten nine nine nine nine. Right? And that's because of our policy. So this was a pretty high level overview of group based policy. We've imported that into the NIST cloud. It pushes the policy down to the respective devices, the access switches that are are, layer three boundary supporting VXLAN layer two, layer three gateway capability.

Really exciting stuff. Hopefully, this has been educational for you. Thank you for spending time.