Hello and welcome. My name is [inaudible]. I’m a part of the product management team and today we are talking about wired assurance and focusing on RADIUS configurations using wired assurance with dot1x as well as MAC-Auth.
Using Juniper Mist wired assurance, there are two simple steps for you to configure RADIUS services from a template perspective. RADIUS servers, which are very commonly used for us to authenticate clients coming to the network are the first piece that you would configure in the constructs of all switches configuration with RADIUS services underneath. You go ahead and provide your authentication server. You could also provide your accounting server in here. The authentication server, providing the details by default, it’s on port 1812 as well as a shared secret that could help you authenticate against your RADIUS server. The next part of the story is to be able to assign a source address. A source address on a per individual switch basis will be the IP from which RADIUS transactions will happen from the switch to your RADIUS server.
Juniper switches have always been compliant with every single RADIUS server that is out there, so any RADIUS servers that that could be, including FreeRADIUS, ClearPass, and ISE, you could use any of them as we use standard space protocols. For you to communicate, you would need a source IP address from a switch perspective and you could assign the VLAN on which the IP address is so that at a template level we could automatically identify the interface from which we need to make the RADIUS transaction from. The second part of the configuration from a template perspective would be for us to assign and create a port profile. One of the elements before creating port profile would be for us to create VLANs. We will be using VLAN2 in this particular example for us to assign devices to be part of a particular VLAN.
The second part is creation of the port profiles themselves. Port profile is the persona that you will be using with physical properties on each of these switches. Now in this example there’s a port profile named as dot1x, the port would be enabled. The port mode would be access and assigned to a VLAN2. Now the most critical part of the story is us using dot1x. You could also use MAC authentication as a fallback. In this particular scenario, you’re using dot1x as primary, and if dot1x doesn’t work, you could use MAC authentication as a failback. If you want to only use MAC authentication and not use dot1x, you’ll be checking the third box as well. Subsequently, in case of a failure, if you’d like to put the device on a guest network, you can absolutely do that using the “Use guest network.”
In case the RADIUS server is at launch and is not responding to any of the RADIUS requests, what would you do as a switch for the clients coming in? You could actually say, I could use cached credentials, that the same device was authenticated prior and I would like to authenticate it automatically again and we could bypass the authentication when we know this device had recently passed authentication. The rest of the properties on the port are left at default, speed, duplex. If POE is enabled or not. Would you anticipate BPD use on this particular port? Enable MTUs, storm control, all of them have been left blank in here. So you’ve created two things from a template perspective. One, a RADIUS server, two, a port profile. Every single time you create a template, you will assign that to a particular site, a site which contains many switches. Now let’s get into the actual site where the switches are. Now, you have inherited the template that you created on each of these switches.
Now, how do you leverage these elements for you to configure all of them at scale? One way of doing it is assigning them at an individual device level. The other way is to be able to do this at scale in the same template that we were in. You could go all the way to the bottom, define the nature of devices that would need these configurations. In this example, we’re saying any device that has a role of POE, which is a role as a free form text that you could define here in “Apply to individual switches,” those devices will get the following port configurations. One of them is gig [inaudible] . All of them get the dot1x port profile that we just created. So this is an easy way for us to inherit configurations and push them down to multitudes of switches across at scale.
And this is how Juniper Mist with wired assurance, you’re able to scale to the enterprise level where you may have different nature of access devices and whichever devices need these configurations, we can push them down automatically instead of you having to do this across every single switch, one switch at a time. Now let’s get into the actual switch itself. You’ve inherited the template, you’ve created the port profile. All of these elements are in here. Let’s go quickly check that this particular switch has inherited all the port profiles because that particular template was applied to the site at which the switch resides. Similarly, all of the VLANs that were created are also available for you in here, VLAN2 to be very precise. Now, one important thing to keep in mind every single time, just because we have defined a port profile and a network in a template would not necessarily mean we would pass down all of the parameters including the VLAN or RADIUS server configurations and corresponding RADIUS parameters down to the switch.
We only send down those configurations to the switch if there are ports assigned for that particular operation. So in this example, gig 101 and gig 1017 have been enabled for dot1x. Only then if none of the ports that are listed here have a dot1x port profile, this particular switch would not receive any of the dot1x credentials. Not nor does it receive the VLAN2 definition nor any of the dot1x references that have been made in here, including the RADIUS server constructs. So this is an intelligent way of us pruning configurations that are not required on the box, although they appear that you have inherited from the template. Let’s take a look at what is happening at gig 101. Gig 101 was one of the first interfaces on which you have enabled dot1x. You could actually dive in on gig 101.
On hover, you can actually look at a bunch of important details. There’s username in this particular case, the username is stranger, the MAC limit or MAC Count is present. We also understand what the manufacturer is based on in this example, it’s a raspberry pie that we’re testing out. Further to that wired client insights also provide you ample amount of data regarding every single event that happens on a wired client. In this particular example, we have set this for it to be consistently authenticating against the device ever so frequently, and all of these events are listed here for you. Other events also have more detail. One of the detail is it is was successfully authenticated. It was the username of stranger, the MAC address of the device, as well as the interface on which it was authenticated with, also the VLAN on which it was authenticated. Now all of these elements, including the MAC address, are all set here on a first switch basis. All of these elements help you determine how the authentication process is going through on a per-device basis.
If the question is, “I’ve enabled dot1x across my entire network, I don’t know if all the clients are doing okay or if there are housed in connection status on a per device basis or even a per site basis going along in our network.” And that’s where the SLEs come into picture and the SLEs are our definition of client-level experiences across everything that goes on on your network. In this particular example, we will focus on the successful connect SLE. The successful connect SLE is at 32%, which is telling us that the rest 68% of the time, there is difficulty for the clients to authenticate. Let’s look at what is going on on the network. We know it could be either DHCP being the reason or authentication. In our case it is authentication that’s failing 100% of the time. Now, if you’d like to know across your thousand ports that may exist on a particular site, which two ports are consistently failing, SLE is the answer for you to look at.
We came from a 10,000-foot view of 32% failure rate or a 32% pass rate across your entire site to exactly that one interface and on one particular switch failing, is the important aspect of how we find needle in the haystack and that’s where SLEs help us. So in this example, what we do see is gig 1017, which is the other interface that we had enabled for dot1x is failing and the MAC address of the device that is connected on the other end that is failing authentication is that. If you’d like to look into exactly what is going on, we can actually look into the exact switch that is in question and also what is going on under the switch. Again, the events come to rescue. You can actually see that the dot1x user is denied. The particular username that’s used is liar and the MAC address that is trying to authenticate the client MAC address is so-and-so.
So you now went in from a 10,000-foot view of just seeing how a successful connect metric looks from a user perspective to exactly that one user that is being affected. So wire assurance not only helps you configure all of these devices at scale, but also helps you monitor what is the nature of how dot1x is working at a global scale. Now, if you’re somebody who’d like to understand what goes on behind the scenes, this is an example of exactly what configurations look like under the hood. When you say gig 1017 was one of the interfaces, we pushed the dot1x configuration down to the switch, it was a part of the VLAN2. We also have the dot1x configurations listed in here, which is the RADIUS server we provided, what is the authentication, what is the accounting server.
We provided both of them as the same. Which other interfaces are part of this network? Now, subsequently, if you’d like to know what’s going on underneath, we already showcased that to you on wire clients and insights for every single client. But you could also look at that from a, “Show dot1x interface,” perspective to see gig 101 is authenticated while gig 1017 is not, and it’s continuously trying to authenticate onto the network. Hopefully this was a good primer for you to get started with dot1x and MAC authentication configuration with any RADIUS server overall from a perspective of authenticating clients that are entering the network. Thank you so much for listening and you have a good day.