Get Started with IBNS 2.0 for Wired 802.1X

0:00Hey there y'all, how's it going? I hope your day is going great so far. Now you remember all of those authentication commands? We've got let's see authentication port control auto, authentication priority, authentication order all of those? Well, we looked at those because that's the traditional way, the easy way, relatively speaking at least, of configuring 802.1x. So it's a great way to get introduced to it. But now that we know how to configure 802.1x using this traditional what's called IBNS 1.0 method, well, just like anything that has a 1.0, inevitably, eventually, there's going to be a 2.0.

0:43And in the case of IBNS, which stands for identity-based networking services, 2 .0, the big keyword that we need to focus on throughout this entire skill is going to be flexibility. This with IBNS 2.0, it shakes up the ground a lot compared to IBNS 1.0, and a lot of that comes from the fact that now we're configuring 802.1x using custom policies. And this solves the biggest problem with IBNS 1.0, which is that all things considered, it's very cookie cutter.

1:21Sure, we have a lot of authentication commands, but those commands and what they do and what settings they set are very set in stone. It's kind of like ordering a cookie cutter to cut cookies with. Sure, there are a lot of shapes for cookie cutters online if we go look, but when we take that cookie cutter out of the plastic wrap, it is going to stay that exact shape forever. So, in the grand scheme of things, there just aren't that many possibilities with IBNS 1, and so it gets very difficult to handle a lot of the edge cases that pop up.

1:56So what Cisco said was, you know what, fine, you want control, you have control . And because we're working with custom policies that we can shape into whatever we want, now that raises the ceiling effectively to infinity right up to the sky. But it also means that because we don't have the guard rails of the cookie cut ters anymore, we don't have those very set in stone authentication commands that keep us straight. Well, now the floor is also a lot lower.

2:28So it's a lot easier for us to potentially mess up our 802.1x policy. So our focus in this skill to use our cookie analogy again is cool. We have this knife to cut the cookie dough. However we want to, how do we do it safely? In other words, we have all of this power of IBNS 2. How do we make sure that our 802.1x policy still comes out working at the end? Let's dive in and take a look.

0:00So, in order to break down what cdpl is, let's look at what it stands for. It stands for the Cisco Common Classification, that's where we get C3 from, 3Cs , and then Policy Language. Honestly, if we're trying to figure out what it is from the name, the 3Cs are not that useful. In my opinion, anyway. What's way more useful is the Policy Language part. It's a language that we use to communicate our policy with the device.

0:32So to put that another way, this cdpl is a configuration method for our network access authentication settings. And on the surface, that probably seems pretty confusing because isn't that exactly what IPNS2 is? Well, kind of. We can think of IPNS2 as this big umbrella. Let's see if I can draw an umbrella correctly. And, you know what, good enough. And under this umbrella, we have a lot of ideas that Cisco came up with in order to improve the authentication manager in iOS.

1:10The authentication manager is basically the program running inside of Cisco iOS that manages all of these connections and authentication requests that are coming in and hitting the switch. In fact, they improved it so much, they gave it a new name. Not even a new version number. No, no, no. They said, you know what, you're not called the authentication manager anymore. You're called the access session manager. So for example, one of Cisco's big ideas under this umbrella is to improve Flex off to make it more flexible.

1:43So with this better Flexoff comes the ability to do MAB and 802.1x at the same time. Okay, that's a pretty big improvement. There's also better critical authentication. And being able to enforce more complex policies like ACLs even when ICE is down . Of course, we also have the elephant in the room with IBNS1, which is the flexibility of our policies. And this is in terms of the number of possibilities that we have for config uring our rules to enforce network access.

2:18We also have better device tracking or better connection tracking is the better way to put that being able to keep better tabs on individual connections and authentication sessions, even when we have multiple on a single port. And the last broad category that we're going to talk about although there are many more, this is a big change is better support for IPV six. In terms of being able to track IPV six clients and enforce IPV six policies like access lists.

2:50Now getting back to cdpl, you might be like, well, Kelvin, that's a lot of words under that umbrella and all of that's nice. But I don't see cdpl under there. And the reason is that cdpl is what ties everything in the umbrella together. Basically Cisco looked at all of these improvements and said, wow, yeah, that's a lot. We don't want to try to cram all of these improvements into this old traditional way of configuring authentication. It's going to be a lot better if we design this new system for configuring authentication that natively accommodates all of these improvements and let's see three PL.

3:31So effectively, see three PL is the face of IBNS two. It's how we interact with IBNS two.

0:00Now, the big core piece of CdPL are our policy maps. And in fact, let's actually put a giant star next to it, just to emphasize how important it is. A policy map is the only technically required piece of CdPL. Now, we say technically required because you can't do much without some of the other components, but we don't technically need them. Now, if you're familiar with doing QLS on Cisco, there's probably more than a dozen light bulbs going off in your head right now going, "Wait, wait, I know policy maps."

0:39And if you've worked in policy maps for MQC, you're going to feel right at home . This is very similar. There are some big differences, but it is very similar. So policy maps are where we actually define the rules that we want our switch to follow when it's enforcing network access. We can think of it basically like a recipe or a cookbook. Just like how a cookbook tells us exactly how to make a perfect dinner, the policy map tells us the switch exactly what steps it needs to take in order to enforce the perfect level of network access.

1:16That is, assuming we build it correctly, because just like how there are bad cookbooks, there are bad policy maps. Now, inside of our policy maps, let's pretend that this box down here, this big rectangle, is our policy set or policy map, rather. Get ready to mix up saying policy map and policy set a lot, by the way. So inside of our policy map, there we go, we've got three different stages. The first stage is the event. So the event is what actually happens to trigger this policy map, because for the most part, the policy map is just going to sit there sleeping until it needs to wake up in order to enforce some rules.

2:00So an example of an event would be a device connecting or the authentication fails or on the flip side, the authentication succeeds. And there's a bunch more events that we're going to dive into when we get into the configuration. The event is important for the policy map, because it tells the switch in a very high-level general sense what it needs to do to respond. So as an analogy, think about calling emergency services, so 911, for example. Pretty much the first question that that emergency operator is going to ask is, "Hello, is this issue fire, medical, or police?"

2:36Because depending on what kind of event it is, the response is drastically different. So we know the general event, but we still need some details about what that event really is. And that's where this next stage comes into play, which is our class. And keep in mind that as we go from events to classes, each event, each kind of event is going to have its own set of classes. We can basically think of a class as a sub-event.

3:09So let's take the example of an authentication failure. The switch vaguely knows that the authentication failed. It doesn't know why though. If the user just literally failed authentication, so they typed in the wrong credentials, for example, well, that's on them, that's one thing. But what if the authentication failed because the AAA server is down? Because ICE went down, "Ah, now it's not the user's fault. Now we're interested potentially in looking at critical authentication, for example."

3:41So see how just by switching up the details, the way that we want to respond is very different. To go back to our 911 analogy, that would be like the difference between someone calling 911 because they'd stop their toe versus someone who was actively going through a heart attack. Very big difference. And finally, once we've used our classes to really pinpoint and lock down exactly what happened, then we can move on to our third stage, which is, so what?

4:11What are we going to do about it? What actions are we going to take for a particular class? This is really the recipe part of the policy map that we were talking about earlier. So let's say that the AAA server went down. Okay, well, the first step is going to be assuming we're doing critical authentication. The first step is going to be to apply our critical authentication properties. So the critical VLAN, for example, and then the second is going to be to authorize that device or that user in order to access the critical VLAN.

4:44It's a bit more involved than that, but for now we'll simplify the steps. So to finish up our emergency analogy, that would be where the emergency operator goes, "Okay, you stop your toe, go to a pharmacy and get a pack of band-aids." This is a heart attack where the operator is going, "Hey, can we get an ambulance out there as fast as we can?" Now, again, policy maps aren't that useful on their own. Sure, the list of events is statically defined inside of the policy map. There's only so many events, but the classes, there are a lot of potential reasons for the event happening.

5:20So in order to allow us to customize the individual classes, Cisco brought in the help of "dada-da-da" class maps. And again, if you're familiar with the modular QoS, the LiR MQC for QoS, class maps are also going to make you feel right at home. So when we define a class inside of our policy map, we're actually referencing a class map. And the class map's job is to answer this question of what actually counts.

5:53What counts as falling under this class? So we can basically think of it as conditions in ice. So inside of our class map, let's say at this box down here again, this is our class map. Firstly, there's three kinds of class maps. The first is match any. The second is match all. And the third is match none. That'll make a bit more sense in a moment. Anyway, inside of our class map, there's two main statements that we can define .

6:25The first is our match statement. So this allows us to match on a lot of different attributes, like the MAC address, for example, of good device that's connecting, or the result type. What actually happened that we can access RejectBack, for example, was a AAA server dead. We're not going to go through all of the attributes. There is a laundry list that we can match on. But using the match statement, we can ensure that a particular attribute has some value. The other command that we can configure in our class map is no match.

6:57And let's work the exact same way as match except in the reverse. We essentially want to make sure that a particular attribute, like the MAC address, for example, is not equal to some value. Now, it's important to remember that we can have multiple match and no match statements inside of our class map. And that's where these three options that we talked about earlier come into play. If we do have multiple match or no match statements, these three options allow us to control how many of them have to be true, how many of them have to be satisfied before we can call the entire class map as a whole, a success or a failure.

7:36So match any means that as long as any of these match or no match statements come back as true, anyone will do the entire class of us going to be true. So the class map coming back as true means that in our policy map, we're actually going to go into that class and do whatever the actions are. Alternatively, match all means that all of them have to match. So all of the match statements and no match statements have to be true in order for the class to be true. And finally match none, you can imagine, none of them can be true.

8:10And the class itself will come as true. Otherwise, if there's even one match or no match statement that comes back as true, the entire class map is not going to be satisfied. Now after we actually satisfied the conditions of a class map and we start doing the actions under that class, we mentioned earlier setting properties for connection, for example, setting the VLAN or applying an ACL doing those things in an action requires that we define something called a service template.

8:41So these are applied to an individual connection or an individual session in other words, in order to control what kind of access that connection has and it's applied as part of our policy map actions. So think of the service template as a laundry list of the things that we want for connection. So let's pretend that again, you're probably useless by now. This box is our service template. We'll just write ST to save some time. And again, inside of the service template, we literally just have a list of configurations of settings.

9:16So for example, we want this connection to be in VLAN 101. We want to use list ACL. We want this connection to be in the voice domain. If this is a phone that we're applying the service template to, for example, again, we'll see when we actually apply service templates that the list goes on and on. Now one thing that's worth noting about service templates is that we can actually apply them not only as part of actions in a policy map, but we can also apply them in an ICE authorization profile as well.

9:50The way this works is that the switch would have the service template locally defined in its configuration. And then when the client goes to authenticate with ICE and ICE pushes down these authorization results, it's going to include a specific attribute value pair. And actually it's the subscriber service name attribute. It's going to push down this attribute value pair that contains the name of the service template that the switch should apply to that client to that connection.

10:21So this is a way to dynamically assign service templates, but in the context of normal authentication with AL2.1x, for example, it's not that useful because most of these settings, VLAN, ACL, choice domain, we could push those down normally via an authorization profile anyway. So for our use case, just dealing with normal AL2.1x, service templates are most useful when we use them to perform local authorization. In other words, authorization without involving ICE.

10:52So everything that we've just talked about, service templates, class maps, policy maps, in some way they all tie back to the policy map at the core. But we also know that our endpoints are connecting to our switches via interfaces. Well, at some point, we need to actually tell the switch to use the cdpl policy on this interface. In other words, apply the policy map. And there's a couple of ways to do that. We could as option one, just directly configure the interface.

11:27Obviously, this is pretty straightforward. We just apply a command to either a single interface or an interface range. So very easy, very straightforward, we're all used to it. But the disadvantage is that it means that all of the interfaces are separate in terms of their configuration. This is a problem because anytime we want to make a change to the configuration under an interface, even if we go to an interface range, we still are at the end of the day manipulating the configuration at each interface.

11:58Well, if all of the interfaces that are connected to our endpoints have the exact same boiler plate configuration for enabling authentication and enabling MAB, then why have all of those separate configurations spread out across all of our interfaces? That's where option two comes into play. Interface templates. Strictly speaking, this isn't a cdpl feature, but it is something that we're going to use with cdpl. So think of these templates as profiles for our ports or for our interfaces rather.

12:33The way this works and here it comes again, get ready, pretend this box is our interface template. Our boiler plate config goes in here once, so switch port mode access and authentication port control auto and MAB and so on and so forth. You get the point. Let's say that we have multiple interfaces going to multiple endpoints. We can take this interface template and apply it to each of these interfaces. The advantage of doing this is that if we ever need to make a change to some of the configuration in here, we can just go and change the interface template once and then all of the interfaces using this template are automatically going to inherit those changes.

13:16We don't need to go around and mess with interface range. And another very powerful thing with interface templates is that we can assign them through an ICE authorization profile, except unlike service templates, where assigning a service template via ICE is pretty niche because a lot of these service template settings are already configurable inside of the authorization profile. When we're talking about interface templates, there's no way to configure the switch port mode inside of our authorization profile.

13:48So it lets us build some really cool policies like dynamically changing a port from switch port mode access to switch port mode trunk based on who's connecting or we could just be basic and assign it manually. Now interface templates tie back into cdpl because whenever we want to apply a policy map for cdpl to our endpoint interfaces, guess how Cisco recommends that we do it. That's right, put the command to apply that policy map into an interface template.

0:00Alright, so we're logged into one of the switches, switch one in this case, in our lab environment, and let's do a quick show run, and let's filter this down to the configuration for interface, gig 1.0.25. That's leading to desktop one. And right off the bat, we'll see a whack ton of traditional IDNS1 style authentication configuration. It looks like this interface is configured for both 802.1x and mab, but otherwise, nothing looks after the ordinary.

0:32This is all of the traditional or what's also called the legacy style configuration that we've all come to know and love. But what if I told you that this configuration, even though nothing looks off about it, it's hiding a dark secret? And that secret is the fact that this configuration really just exists for show . It exists for us to look at, but it's not the actual configuration that iOS uses to operate. And the reason for that is that way back when Cisco had this dilemma, they knew that a bunch of administrators would be super used to working with these traditional authentication commands that we see in IDNS1.

1:14And so if how different IDNS2 is, they wouldn't want to switch. So you've got administrators that really want IBNS1, but you also have Cisco that wants to build their software around the newer, fancier IBNS2 with all of its new features. So the way that Cisco solved this dilemma is the exact same way that a kid would solve a dilemma between what kind of candy they want. Why not both? So what they did is they'll still allow us to configure authentication using this traditional legacy IBNS1 style, but as soon as we actually configure IBNS1, iOS on the back end, hidden away from us, it'll create this equivalent IBNS2 configuration, which is also called the new style.

2:05So on the back end, we've got two separate configurations, the IBNS1 that actually shows us in the running config and the cdpl that realistically speaking is what actually matters. So we'll put a little star next to it to show that because this configuration is what actually runs. But at the end of the day, we don't notice this again because the IBNS1 and IB NS2 configurations are one to one in terms of functionality. They are exactly equivalent in terms of their behavior.

2:36Now you might be wondering why does that matter if they behave the same anyway? Well, it's because it makes it a lot easier to go back and forth between IBNS1 and IBNS2. Because when we configure authentication using IBNS1, the IBNS2 configuration is just chilling back there. And so we can tell iOS really easily to just show us the IBNS2 configuration. Now something to note before we go on and half the switch show us the IBNS2 configuration is that it'll only have both versions, one and two, as long as we configure it using IBNS1.

3:14So if we just fully commit and we use IBNS2 in our configuration as well, Cisco 's not going to go back and maintain an IBNS1 version of that configuration. As long as we're on board the IBNS2 train, Cisco's also on board. So we're just going to have that one IBNS2 configuration in that case. So let's clear this off and let's look at the IBNS2 version of this configuration. Now it's really easy to do that. All we need to do from privilege the exact mode, so not from global config, from right here, all we need to do is type authentication display.

3:50And if we question mark, we've got a bunch of sub commands under that. We've got config mode. And if we run this, this is going to show us what our running config is currently using. So all this is telling us is that our running configuration and our startup configuration actually are written using the legacy style. Now if we want to look at what the cdrepl version of that configuration looks like, all we need to do is let's up arrow and remove config mode and let's replace that with new style.

4:25And when we run that, we're going to get this big message. I wouldn't really call it a warning, it's just telling us that we can always revert back to the legacy style unless we change the configuration. So with that, let's go back and we'll rerun that show run interface gig 1.0 25 command and immediately whoa, hang on. That looks a lot different. Where did all of our authentication commands go? Ah, remember in IBNS one, the actual piece of software, the program that's running in iOS that manages all of our authentication, let's call it the authentication manager.

5:06So the commands that control how that authentication manager work, well, they are authentication commands make sense. But in IBNS two, that name got changed to the access session manager. So these commands have really just been renamed to reflect that change. That's all that's happened. So instead of it being authentication control direction in, now it's access session control direction in. But for the most part, we still have a lot of our commands. We still have our host mode command, our port control command.

5:40And on top of that, our map and dot one X specific commands, they haven't changed at all. So if map, we still have dot one X P a, a de indicator, the one big change that we can see immediately is this access session closed command. What's that all about? Ah, well, this is a big change going from IBNS one to IBNS two with IBNS one. It was always assumed that interfaces were in closed mode by default. And you could make them open as a custom configuration using authentication open.

6:16So let's use for running monitor mode, for example, or low impact mode with a pre authentication ACL. But in IBNS two, they changed our functionality and basically reversed it. So now get the fault is open. And if we want to use close mode, we need to run the access session. So a dash S is going to be how we write that out closed. And that's this command that we see right here. So that takes a little bit of gain used to that.

6:47If we don't see that closed command, then that means that assuming we don't have an ACL, all traffic is going to be allowed even if authentication fails. Now, notably, we do still have some commands that are stragglers. So in this case, we see that authentication periodic and our timers, those are still going to be under the classic authentication command. But for the most part, most of the commands did get pulled over to the access session side.

7:17It's just that a couple were left on the other side. Of course, we still haven't accounted for all of the commands. For example, we scroll back up to our old legacy style of configuration. Where did our violation mode go? Where did our flex off go? Where did our critical authentication go? Ah, well, all of that got moved to our policy map. And this is where the magic of cdpl starts list command or right here service policy type control subscriber list command is what applies our cdpl policy map.

7:56Now you might recognize this command from dealing with QOS policy maps, where with QOS policy maps, we would do service policy input and in the name of the policy map . The big two differences with this command for cdpl is that we have this type control subscriber. This is what telescope switch that we're talking about a cdpl policy map specifically. So it's not going to try to apply a policy map that we're using for QOS, for example. And we also don't have a direction.

8:27The reason for that is that it wouldn't make much sense to talk about the direction when we're talking about 802.1x because we're always going to be talking about authenticating the device, the endpoint that's connected to this interface. We're never going to be talking about the endpoint authenticating the switch. Now let's also look at another interface, gig one, oh 26. This is connected to desktop two. And in the legacy IBS one world, I can tell you that these two interfaces were configured exactly the same way.

8:58So we can see we've got map and we've got 802.1x enabled and the IP and S2 configuration also looks pretty much the exact same except we're using different policy maps. So when iOS creates this equivalent IP and S2 configuration from our legacy style configuration, it does it on a per interface basis. So every interface gets its own policy map and this goes against one of the big selling points of cdpl and IB and S2, which is that we can have multiple interfaces, but have a single policy map for both of them.

9:39That way, if we ever need to make a change to any of our authentication settings, we just make it once inside of this policy map and both of these interfaces are going to inherit that change. But because an IB and S1, we could have interfaces that have different settings . Ultimately, Cisco just took the easy way out and said, fine, because these interfaces could have different settings, we're just going to create separate policy maps for each interface just to make things simple. All right, now let's quickly take a look at our cdpl configuration.

10:12So it's going to be our policy maps, our class maps and our service templates. We don't have any interface templates to find right now. So we'll take a look at those in another skill. Let's do a show run and we're just going to filter just those things out of our configuration. So policy map and class map and service template. And I scroll to the end of that configuration, but we can see, wow, that is a lot of configuration. And actually see some configuration that's not related to cdpl.

10:44So let's actually have a bit of a tighter filter. So type control subscriber. We'll make sure that's on our policy map and our class map that should do it. And yep, that looks a lot better. So we're not going to go into the significance of every single setting. We're going to save that for another skill. The main takeaway for now, just so we can properly digest all of this, because this is a lot of configuration, the main takeaway is really how policy maps, class maps and service templates tie into each other and seeing that in action in the CLI.

11:21So looking at our policy map, just for the gig one, oh, 25 interface. And let's specifically focus into this section right here, starting at event session started. And then we've got this 10 class always statement. Now as a side note, for some reason, it looks like show run is actually dupl icating a bunch of configuration. So we've got 10 class always twice. That's just a bug though. In reality, this wouldn't be configured twice like this.

11:52You wouldn't have this other block down here, for example. But in any event, walking through the process, the first thing we would do is trigger the policy map. And that would happen because the policy map is tied to an interface. And we've got an end point on the interface that's trying to authenticate. So let's go ahead and put that in there. So we start off at the policy map, but then we dive into a specific event. We can see in this case that this is the session started event.

12:22So when the session is started, we look at a specific class in order to figure out how we should respond. And inside of the event, we've got a list of classes. Now in this case, for session started, we just have the one class, which is class always, but we could have a whole list of them. And depending on how the event is configured, whether it's configured to be match all, like session started is, or it could also be match first with match all we would execute the actions under any of the classes that match.

12:56Whereas with match first, just like with an ACL, where we go from the top and then go down until we match on the first entry, that's what's happening here. We looked through this list of classes until we find the first one that matches , and then we do the actions under that class, and then we stop looking. So if there's classes that come after that, that we would match, do bad. Now you might be asking, how do we know which one comes first? And the key to that are these numbers at the very front.

13:27So we have numbers for our classes, and also we can see numbers for the actions under those classes. So those numbers are line numbers. So these line numbers allow us to define which lines are the top and which lines come after. And usually it's good practice. We can see to separate these by 10. So if we need to come in and make a change and insert a line between two lines, it makes it a lot easier to do that. So we can see down here it goes 10, 20, 30, 40, for example.

13:58That's just the best practice. We can make these line numbers whatever we want though. As long as they go in the order that we want. So for classes, the line numbers tell us the order that we're going to be looking at the classes and seeing if they match what actually happened for actions. The line numbers are going to tell us what order we want to execute the actions in. So looking down here, for example, at this triple A server down on authenticated host class, we have four actions. And the first one that we're going to do is line number 10.

14:29The second one we're going to do is line number 20 and so on and so forth. We'll also see though that events themselves, if we erase this, we'll see it more clearly, but events themselves don't have line numbers. And the reason for that is pretty simple. There's nothing that could ever happen that would fall under two different events. So we don't ever need to be worried about what event comes first. So getting back to our classes, we'll see how what comes after is usually going to be a class map. The exception to that we can see under session started is going to be always class.

15:06And that does exactly what it sounds like. It will always run unconditionally, which is why it doesn't take a class map because class maps are there for us to define conditions. Now there's also a setting that comes after the class map. In this case, it's due until failure and this is good default, but there are multiple options. We could also have do all and do until success there. And this has to do with how many actions we're actually going to execute do until failure means that we're going to do every action under the class until one fails, then we're going to stop.

15:46So for example, if we have this authentication statement under this class and we have a bunch of other actions after it, if that authentication fails, we're not going to do anything that comes after it. Due until success is the opposite, where if we have a bunch of actions under a class, we're going to do all of those actions until one succeeds, then we stop and do all is just, you know what, we don't care succeed fail, whatever, just do all of it. Now both of these are relatively niche, especially due until success.

16:19Most of the time we're going to want to use do until failure so that if something happens, we can handle it. Now we're at it match all is the default for events. And we would swap that to match first if we wanted to really make sure that we didn't have any conflicts between classes. In other words, that we don't have one class doing one thing and then another class that comes after it coming along and undoing all of that. That's why authentication failure, this event is match first. So anyway, I've cleared this off to give us some more space.

16:52And in the situations, we're not using class always. So let's take a look at event authentication failure, for example, and five class dot one X failed. If it's not always, this is going to refer to a class map. So let's see if we can find it dot one X fail dot one X fail. There we go. We can see that this is a match all class map. And notice that just like we alluded to earlier, this is also type control subscriber to tell us that this is a C three P O class map. And we can see in it, we've got a bunch of conditions that we're matching on.

17:26So we're matching on the result being, well, firstly, that the method is able to dot one X and that the result is authoritative. So let's work class maps come into play. Now after we match on a class, we're going to execute the actions that are sitting inside of that class. And usually this doesn't require anything extra that we need to configure beyond the action itself. So we can see in the session started event under the always class, we're saying authenticate using map. So we're doing map authentication.

17:57Great. We can see under dot one X failed this class, we are terminating dot one X. That also doesn't take any other configuration beyond just the action. But let's come down here to this other class with a super long class map name. So this is our critical authentication. And with critical authentication, remember, we are applying authorization results locally. We are putting them into a critical VLAN. So to do that, we need to use a service template.

18:28So we can see on line number 20, we are activating this service template for a connection called critical off VLAN and then the interface. So let's see if we can find that service template. Let's scroll up and look for it. And indeed, we can right up here. So we've got this service template configured and it's super duper simple. Literally all it contains is one statement saying, yep, VLAN 1140. That's the VLAN. When we said that a service temple is just a list of settings, we literally meant it.

0:00Now, just like we mentioned earlier, we didn't change any of this. So we can always go back to IBNS1 by saying authentication display, again, all from privilege exec mode and legacy. And if we now do a show run and we look for our, let's say, policy map type control subscriber, hey, it's not there anymore. And if we go back and look at our interface configuration, the layers are familiar face. Or IBNS1 configuration.

0:31Now let's say that we're like, I actually want to do stuff with IBNS2. So let's go in and let's configure our policy map type control subscriber. And let's call this c3pl is awesome. And before we ignore this warning and just press enter, this is actually a really important message. So let's read through it. This operation will permanently convert all relevant authentication commands to their c3, I guess they have a missing three there. Let's help them out and Jordan see three PL control policy equivalent.

1:05It is irreversible and will disable the conversion CLI authentication display. Whoa, whoa, hang on a second. What this is really saying is if you want to run an IBNS2 command, you cannot go back to IBNS1. This is not allowed. You can go the other way. You can go IBNS1 to IBNS2, sure, but not from new to old. Now even though we should respect this warning, it is telling a truth. It's really telling a half truth because yeah, if we go forward and we convert the configuration, we can't go back right now.

1:43But if we reboot without saving the configuration and it boots back up with that IBNS1 configuration that's sitting in the startup configuration, we're good to go. We'll keep using IBNS1. It's only if we do this and then save the configuration to our startup config and we reboot into the startup config that it's truly irreversible without actually just wiping the configuration or going back to a configuration that had the IBNS1 commands.

2:13And that fact really reveals how this is actually working under the hood, which is that the switch is looking at what it's booting up with. Is it booting up with IBNS1 configuration or IBNS2? If it's booting up with IBNS1 configuration, then that gives us access to all of our IBNS1 commands and the option to switch to IBNS2, whether permanently or through that authentication display command to just do it temporarily.

2:46But we can't configure any IBNS2 settings. Granted, the IBNS2 configuration will still exist as we saw on the back end hidden away from us, but it will always be set to mirror what we do in the IBNS1 world. Whereas if we boot up with IBNS2 configuration, well, that gives us the ability to work with IBNS2 and actually configure it, but we can't switch back to IBNS1. And that's really the significance of that authentication display config mode command that we saw earlier.

3:21This tells us what it's booting up with. So again, to permanently convert, we can run any IBNS2 command or there's also a dedicated command just to convert, which is authentication convert to and new style. And we can see big difference. Now we're running it inside of the global configuration mode because what we're doing right here actually affects the configuration. So let's press enter and list time will accept the warning. And now if we go back and do a authentication display config mode, now telling us that our configuration is a new style.

3:59But if we do authentication display question mark, we'll notice that as the only command under authentication display now, we can't do authentication display legacy because that IBNS1 configuration no longer exists. So in our running configuration, let's go look at our interface again. And of course, we're using our new style cdpl configuration. And if we launch into our configuration mode and then look at the interface and under authentication, if we try to run, let's say authentication host mode and then let's say multi domain, we'll see that it's now telling us that this command is disabled, that we should be using access session instead.

4:45But of course, we haven't run a copy run start or a write memory right now. So in our startup configuration, let's look for gigabit ethernet, one oh 25. We'll see all of our IBNS one configuration is still intact, ready to blow that away. WR. So again, before we just did that, we could have reloaded and gotten ourselves out of IBNS2. So now we are fully committed to the IBNS-2 train.

0:00All right, let's close out the PowerShell window, starts up with the lab, and we're gonna open up our router and switch console and navigate to switch one. So our first task is gonna be to display the current configuration mode of our running config. So to do that, we just need to run the authentication display config mode command. And we'll see that our output is that the current configuration mode is legacy. So let's go look at this question.

0:30So was the output say the current configuration mode is legacy. Awesome. Let's move on to our next task. So we wanna configure the switch so that when we run the show run command, it'll show the cdpl configuration. But we also wanna be able to go back to IBS1 at any point. So this is not the permanent conversion. Instead, we just wanna do an authentication display. And let's run the new style version of this command. And now if we launch into a show run, and let's just look at our interface, gig 02, we'll see that we are indeed looking at our cdpl configuration.

1:11Now looking at our lab tasks, it's telling us to examine the configuration for gigabit ethernet 02. And we're gonna assume that we're dealing with the authentication failure event. So let's just filter down our show run to just look at policy map type control subscriber, and then policy, gi 02. And let's find our authentication failure event right there. And our first question is which five of the following are class maps that are referenced by the policy?

1:45So let's point out the class maps at this references. So the first is on line five, this .1x failed class map. The second is on line 10, this triple A server down on authenticated host one. The third one, line 20, is this authenticated host version of that earlier class map. These are some beautiful rectangles I'm drawing by the way. Online 30, we've got map failed. That's another one. 40, we've got .1x, no response or no resp. So that's our five, but we also have another class entry.

2:19So always, what's up with this one? Well, remember this one is not a class map. This class is effectively built right into the policy map itself. And it doesn't need a class map because there are no conditions for the always class. As long as we actually get to evaluating this class, so in other words, if this doesn't match first, which it is, that any of the other classes didn't match before it, assuming we get to it though, it will always run.

2:52So those are our five, let's clear off our screen. And let's select the five that we saw before. So .1x failed, map failed, .1x on response, and then the two triple A server ones. Now, if we look at these other three and go back to our policy map, we'll see that in critical VLAN and not in critical VLAN are actually class maps that are referenced by this policy map, but they're not under the authentication failure event. Instead, they're under triple A available.

3:23And the critical of VLAN GI02, this is actually not a class map, it's a service template that's activated under one of the classes that we selected. So that's it for that question. Let's submit this and move on to the next one. So this question is asking us to put these cdpl objects in order. And the first thing we need to do is figure out what these cdpl objects are anyway. So let's look to our policy map.

3:54And we'll see that policy GI02 list is a policy map. So actually we'll put that first, because the policy map is always gonna be the first thing to trigger. And then if we look further down authentication failure, that's an event, so that comes next. So the question is what these two are. So if we look at our policy, we'll see a triple A server down unauthenticated host. This is a class that's right under the authentication failure event. So that goes under the event, which leaves this critical of VLAN GI02, which we saw just a moment ago, is a, where is it?

4:33There we go, service template. So our order goes policy map event class and then service template as an action. So let's press submit and move on to our last question. Now for this task, we're trying to ensure that the running configuration contains cdpl and cannot be reverted back to legacy mode, even after a reboot. So we wanna make this permanent. So to do that, all we need to do is hop on over to our lab again.

5:05And let's switch this back to authentication display legacy mode, just to see that we are indeed running IBNS one configuration in the running config. And to do our conversion, there's two main ways. The first is just to run any IBNS two commands. So let's go under our interface and try running access session host mode multi-off. And it's gonna ask us if we wanna permanently convert our IBNS one to IBNS two to actually run this command or alternatively we'll press control C to get out of that.

5:37Alternatively, what we can do is run the authentication convert to new style command from global config. And this will also directly convert our configuration from IBNS one to IBNS two. So we just press enter on that and let's run the authentication display config style command or whoops, rather, that's not the command. It's config mode, yep. And bingo, our current configuration mode is new style but we're not actually done even if it looks like it because our lab task also says that we want this to persist even after a reboot.

6:14So for that, all we need to do is write our configuration or copy run serve, that's more your jam. And answering the last question that we've got, what three of the following statements are true, we just saw that we did it using the authentication convert to new style commands. So that's the first one that's true. There is a warning that must be accepted before the conversion is complete, yep. We also just saw that giant warning that got plastered onto our CLI. The conversion is only complete after a reboot. Ah, this one's actually not true because if we go back and look at our authentication display config mode command, we'll see it this switch to new style from what it was earlier, which was, let's find it again, legacy and the entire time we didn't have to reboot the switch.

7:00So the conversion will immediately happen. It's just that we need to save our configuration in order for it to persist across reboots. All right, our next answer choice, this can be achieved by running any IBNS2 command, yep. Instead of using that dedicated convert to command, we can also just run any IBNS2 command and it's gonna prompt us to convert before we're actually allowed to go through with running it. So those are our three, so these next two must be wrong. This can be achieved by using the authentication display command. Nope, that's just to display the configuration temporarily in that style.

7:35And also as a side note, it's new style, not cdpl in that command. And this is gonna be achieved by using the convert to cdpl command. Nope, it's convert to new styles we saw in this first answer. So let's press submit. And that's it for our knowledge activity.