Get Started with IBNS 2.0 for Wired 802.1X

0:00Hey there y'all, how's it going?

0:02I hope your day is going great so far.

0:04Now you remember all of those authentication commands?

0:08We've got let's see authentication port control auto, authentication priority,

0:13authentication

0:14order all of those?

0:15Well, we looked at those because that's the traditional way, the easy way,

0:20relatively

0:21speaking at least, of configuring 802.1x.

0:24So it's a great way to get introduced to it.

0:28But now that we know how to configure 802.1x using this traditional what's

0:33called IBNS

0:341.0 method, well, just like anything that has a 1.0, inevitably, eventually,

0:39there's

0:40going to be a 2.0.

0:43And in the case of IBNS, which stands for identity-based networking services, 2

0:48.0, the big keyword

0:51that we need to focus on throughout this entire skill is going to be

0:55flexibility.

0:57This with IBNS 2.0, it shakes up the ground a lot compared to IBNS 1.0, and a

1:04lot of that

1:05comes from the fact that now we're configuring 802.1x using custom policies.

1:12And this solves the biggest problem with IBNS 1.0, which is that all things

1:18considered,

1:19it's very cookie cutter.

1:21Sure, we have a lot of authentication commands, but those commands and what

1:26they do and what

1:27settings they set are very set in stone.

1:30It's kind of like ordering a cookie cutter to cut cookies with.

1:34Sure, there are a lot of shapes for cookie cutters online if we go look, but

1:39when we

1:39take that cookie cutter out of the plastic wrap, it is going to stay that exact

1:43shape

1:43forever.

1:44So, in the grand scheme of things, there just aren't that many possibilities

1:49with IBNS

1:501, 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

2:02.

2:02And because we're working with custom policies that we can shape into whatever

2:07we want, now

2:08that raises the ceiling effectively to infinity right up to the sky.

2:13But it also means that because we don't have the guard rails of the cookie cut

2:18ters anymore,

2:19we don't have those very set in stone authentication commands that keep us

2:23straight.

2:24Well, 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.

2:33So our focus in this skill to use our cookie analogy again is cool.

2:39We have this knife to cut the cookie dough.

2:41However we want to, how do we do it safely?

2:44In other words, we have all of this power of IBNS 2.

2:48How do we make sure that our 802.1x policy still comes out working at the end?

2:53Let'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.

0:05It stands for the Cisco Common Classification, that's where we get C3 from, 3Cs

0:11, and then

0:12Policy Language.

0:13Honestly, if we're trying to figure out what it is from the name, the 3Cs are

0:18not that

0:18useful.

0:19In my opinion, anyway.

0:21What's way more useful is the Policy Language part.

0:26It'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

0:39access

0:40authentication settings.

0:42And on the surface, that probably seems pretty confusing because isn't that

0:46exactly what

0:47IPNS2 is?

0:48Well, kind of.

0:50We can think of IPNS2 as this big umbrella.

0:55Let's see if I can draw an umbrella correctly.

0:57And, you know what, good enough.

1:00And under this umbrella, we have a lot of ideas that Cisco came up with in

1:05order to improve

1:07the authentication manager in iOS.

1:10The authentication manager is basically the program running inside of Cisco iOS

1:15that manages

1:16all of these connections and authentication requests that are coming in and

1:20hitting the

1:20switch.

1:21In fact, they improved it so much, they gave it a new name.

1:25Not even a new version number.

1:27No, no, no.

1:28They said, you know what, you're not called the authentication manager anymore.

1:31You're called the access session manager.

1:34So for example, one of Cisco's big ideas under this umbrella is to improve Flex

1:40off

1:41to make it more flexible.

1:43So with this better Flexoff comes the ability to do MAB and 802.1x at the same

1:50time.

1:51Okay, that's a pretty big improvement.

1:53There's also better critical authentication.

1:56And being able to enforce more complex policies like ACLs even when ICE is down

2:02.

2:02Of course, we also have the elephant in the room with IBNS1, which is the

2:07flexibility

2:08of our policies.

2:10And this is in terms of the number of possibilities that we have for config

2:15uring our rules to

2:16enforce network access.

2:18We also have better device tracking or better connection tracking is the better

2:23way to put

2:23that being able to keep better tabs on individual connections and

2:27authentication sessions, even

2:30when we have multiple on a single port.

2:33And the last broad category that we're going to talk about although there are

2:36many more,

2:37this is a big change is better support for IPV six.

2:43In terms of being able to track IPV six clients and enforce IPV six policies

2:48like access lists.

2:50Now getting back to cdpl, you might be like, well, Kelvin, that's a lot of

2:55words under

2:56that umbrella and all of that's nice.

2:58But I don't see cdpl under there.

3:00And the reason is that cdpl is what ties everything in the umbrella together.

3:07Basically Cisco looked at all of these improvements and said, wow, yeah, that's

3:12a lot.

3:13We don't want to try to cram all of these improvements into this old

3:16traditional way

3:17of configuring authentication.

3:20It's going to be a lot better if we design this new system for configuring

3:25authentication

3:26that natively accommodates all of these improvements and let's see three PL.

3:31So effectively, see three PL is the face of IBNS two.

3:37It's how we interact with IBNS two.

0:00Now, the big core piece of CdPL are our policy maps.

0:07And in fact, let's actually put a giant star next to it, just to emphasize how

0:12important

0:13it is.

0:14A policy map is the only technically required piece of CdPL.

0:19Now, we say technically required because you can't do much without some of the

0:24other

0:24components, but we don't technically need them.

0:28Now, if you're familiar with doing QLS on Cisco, there's probably more than a

0:33dozen

0:33light bulbs going off in your head right now going, "Wait, wait, I know policy

0:38maps."

0:39And if you've worked in policy maps for MQC, you're going to feel right at home

0:44.

0:44This is very similar.

0:46There are some big differences, but it is very similar.

0:50So policy maps are where we actually define the rules that we want our switch

0:56to follow

0:57when it's enforcing network access.

1:00We can think of it basically like a recipe or a cookbook.

1:03Just like how a cookbook tells us exactly how to make a perfect dinner, the

1:08policy map

1:09tells us the switch exactly what steps it needs to take in order to enforce the

1:13perfect

1:14level of network access.

1:16That is, assuming we build it correctly, because just like how there are bad

1:19cookbooks,

1:20there are bad policy maps.

1:22Now, inside of our policy maps, let's pretend that this box down here, this big

1:28rectangle,

1:29is our policy set or policy map, rather.

1:32Get ready to mix up saying policy map and policy set a lot, by the way.

1:37So inside of our policy map, there we go, we've got three different stages.

1:42The first stage is the event.

1:46So the event is what actually happens to trigger this policy map, because for

1:52the most part,

1:53the policy map is just going to sit there sleeping until it needs to wake up in

1:57order

1:58to enforce some rules.

2:00So an example of an event would be a device connecting or the authentication

2:05fails or

2:06on the flip side, the authentication succeeds.

2:10And there's a bunch more events that we're going to dive into when we get into

2:14the configuration.

2:15The event is important for the policy map, because it tells the switch in a

2:19very high-level

2:20general sense what it needs to do to respond.

2:24So as an analogy, think about calling emergency services, so 911, for example.

2:29Pretty much the first question that that emergency operator is going to ask is,

2:33"Hello, is this

2:33issue fire, medical, or police?"

2:36Because depending on what kind of event it is, the response is drastically

2:41different.

2:42So we know the general event, but we still need some details about what that

2:48event really

2:49is.

2:50And that's where this next stage comes into play, which is our class.

2:56And keep in mind that as we go from events to classes, each event, each kind of

3:01event

3:01is going to have its own set of classes.

3:04We can basically think of a class as a sub-event.

3:09So let's take the example of an authentication failure.

3:12The switch vaguely knows that the authentication failed.

3:16It doesn't know why though.

3:18If the user just literally failed authentication, so they typed in the wrong

3:22credentials, for

3:23example, well, that's on them, that's one thing.

3:27But what if the authentication failed because the AAA server is down?

3:32Because ICE went down, "Ah, now it's not the user's fault.

3:35Now we're interested potentially in looking at critical authentication, for

3:40example."

3:41So see how just by switching up the details, the way that we want to respond is

3:46very different.

3:48To go back to our 911 analogy, that would be like the difference between

3:52someone calling

3:53911 because they'd stop their toe versus someone who was actively going through

3:56a heart attack.

3:58Very big difference.

3:59And finally, once we've used our classes to really pinpoint and lock down

4:05exactly what

4:06happened, then we can move on to our third stage, which is, so what?

4:11What are we going to do about it?

4:12What actions are we going to take for a particular class?

4:16This is really the recipe part of the policy map that we were talking about

4:21earlier.

4:22So let's say that the AAA server went down.

4:25Okay, well, the first step is going to be assuming we're doing critical

4:28authentication.

4:29The first step is going to be to apply our critical authentication properties.

4:35So the critical VLAN, for example, and then the second is going to be to

4:39authorize that

4:41device 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.

4:48So to finish up our emergency analogy, that would be where the emergency

4:53operator goes,

4:54"Okay, you stop your toe, go to a pharmacy and get a pack of band-aids."

4:58This is a heart attack where the operator is going, "Hey, can we get an

5:01ambulance out

5:02there as fast as we can?"

5:03Now, again, policy maps aren't that useful on their own.

5:07Sure, the list of events is statically defined inside of the policy map.

5:12There's only so many events, but the classes, there are a lot of potential

5:17reasons for the

5:19event happening.

5:20So in order to allow us to customize the individual classes, Cisco brought in

5:26the help

5:26of "dada-da-da" class maps.

5:30And again, if you're familiar with the modular QoS, the LiR MQC for QoS, class

5:36maps are also

5:37going to make you feel right at home.

5:39So when we define a class inside of our policy map, we're actually referencing

5:45a class map.

5:46And the class map's job is to answer this question of what actually counts.

5:53What counts as falling under this class?

5:56So we can basically think of it as conditions in ice.

6:00So inside of our class map, let's say at this box down here again, this is our

6:05class

6:05map.

6:06Firstly, there's three kinds of class maps.

6:09The first is match any.

6:11The second is match all.

6:14And the third is match none.

6:17That'll make a bit more sense in a moment.

6:20Anyway, inside of our class map, there's two main statements that we can define

6:25.

6:25The first is our match statement.

6:27So this allows us to match on a lot of different attributes, like the MAC

6:31address, for example,

6:33of good device that's connecting, or the result type.

6:36What actually happened that we can access RejectBack, for example, was a AAA

6:41server dead.

6:42We're not going to go through all of the attributes.

6:44There is a laundry list that we can match on.

6:46But using the match statement, we can ensure that a particular attribute has

6:51some value.

6:52The 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.

7:01We essentially want to make sure that a particular attribute, like the MAC

7:04address, for example,

7:05is not equal to some value.

7:08Now, it's important to remember that we can have multiple match and no match

7:12statements

7:13inside of our class map.

7:16And that's where these three options that we talked about earlier come into

7:20play.

7:20If we do have multiple match or no match statements, these three options allow

7:25us to control how

7:27many of them have to be true, how many of them have to be satisfied before we

7:31can call

7:32the 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

7:40come back

7:41as true, anyone will do the entire class of us going to be true.

7:46So the class map coming back as true means that in our policy map, we're

7:50actually going

7:50to go into that class and do whatever the actions are.

7:54Alternatively, match all means that all of them have to match.

7:58So all of the match statements and no match statements have to be true in order

8:03for the

8:04class to be true.

8:05And finally match none, you can imagine, none of them can be true.

8:10And the class itself will come as true.

8:11Otherwise, if there's even one match or no match statement that comes back as

8:16true,

8:17the entire class map is not going to be satisfied.

8:20Now after we actually satisfied the conditions of a class map and we start

8:24doing the actions

8:25under that class, we mentioned earlier setting properties for connection, for

8:31example, setting

8:32the VLAN or applying an ACL doing those things in an action requires that we

8:37define something

8:38called a service template.

8:41So these are applied to an individual connection or an individual session in

8:46other words, in

8:47order to control what kind of access that connection has and it's applied as

8:53part of

8:54our policy map actions.

8:56So think of the service template as a laundry list of the things that we want

9:01for connection.

9:02So let's pretend that again, you're probably useless by now.

9:05This box is our service template.

9:08We'll just write ST to save some time.

9:10And again, inside of the service template, we literally just have a list of

9:14configurations

9:15of settings.

9:16So for example, we want this connection to be in VLAN 101.

9:21We want to use list ACL.

9:24We want this connection to be in the voice domain.

9:29If this is a phone that we're applying the service template to, for example,

9:32again, we'll

9:33see when we actually apply service templates that the list goes on and on.

9:38Now one thing that's worth noting about service templates is that we can

9:41actually apply them

9:42not only as part of actions in a policy map, but we can also apply them in an

9:47ICE authorization

9:49profile as well.

9:50The way this works is that the switch would have the service template locally

9:54defined in

9:55its configuration.

9:57And then when the client goes to authenticate with ICE and ICE pushes down

10:01these authorization

10:02results, it's going to include a specific attribute value pair.

10:06And actually it's the subscriber service name attribute.

10:11It's going to push down this attribute value pair that contains the name of the

10:15service

10:16template 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

10:26normal authentication

10:27with AL2.1x, for example, it's not that useful because most of these settings,

10:33VLAN, ACL,

10:34choice domain, we could push those down normally via an authorization profile

10:39anyway.

10:40So for our use case, just dealing with normal AL2.1x, service templates are

10:45most useful when

10:46we use them to perform local authorization.

10:49In other words, authorization without involving ICE.

10:52So everything that we've just talked about, service templates, class maps,

10:57policy maps,

10:58in some way they all tie back to the policy map at the core.

11:03But we also know that our endpoints are connecting to our switches via

11:08interfaces.

11:09Well, at some point, we need to actually tell the switch to use the cdpl policy

11:15on this interface.

11:16In other words, apply the policy map.

11:19And there's a couple of ways to do that.

11:21We could as option one, just directly configure the interface.

11:27Obviously, this is pretty straightforward.

11:29We just apply a command to either a single interface or an interface range.

11:34So very easy, very straightforward, we're all used to it.

11:38But the disadvantage is that it means that all of the interfaces are separate

11:43in terms

11:43of their configuration.

11:45This is a problem because anytime we want to make a change to the configuration

11:50under

11:50an interface, even if we go to an interface range, we still are at the end of

11:54the day

11:55manipulating the configuration at each interface.

11:58Well, if all of the interfaces that are connected to our endpoints have the

12:03exact same boiler

12:04plate configuration for enabling authentication and enabling MAB, then why have

12:10all of those

12:11separate configurations spread out across all of our interfaces?

12:15That's where option two comes into play.

12:18Interface templates.

12:20Strictly speaking, this isn't a cdpl feature, but it is something that we're

12:24going to use

12:25with cdpl.

12:27So think of these templates as profiles for our ports or for our interfaces

12:32rather.

12:33The way this works and here it comes again, get ready, pretend this box is our

12:38interface

12:38template.

12:39Our boiler plate config goes in here once, so switch port mode access and

12:45authentication

12:46port control auto and MAB and so on and so forth.

12:51You get the point.

12:52Let's say that we have multiple interfaces going to multiple endpoints.

12:56We can take this interface template and apply it to each of these interfaces.

13:01The advantage of doing this is that if we ever need to make a change to some of

13:05the configuration

13:06in here, we can just go and change the interface template once and then all of

13:11the interfaces

13:12using this template are automatically going to inherit those changes.

13:16We don't need to go around and mess with interface range.

13:20And another very powerful thing with interface templates is that we can assign

13:25them through

13:26an ICE authorization profile, except unlike service templates, where assigning

13:31a service

13:32template via ICE is pretty niche because a lot of these service template

13:36settings are

13:37already configurable inside of the authorization profile.

13:41When we're talking about interface templates, there's no way to configure the

13:44switch port

13:44mode inside of our authorization profile.

13:48So it lets us build some really cool policies like dynamically changing a port

13:53from switch

13:54port mode access to switch port mode trunk based on who's connecting or we

13:58could just

13:59be basic and assign it manually.

14:02Now interface templates tie back into cdpl because whenever we want to apply a

14:07policy map for

14:09cdpl to our endpoint interfaces, guess how Cisco recommends that we do it.

14:14That's right, put the command to apply that policy map

14:17into an interface template.

0:00Alright, so we're logged into one of the switches, switch one in this case, in

0:04our lab environment,

0:06and let's do a quick show run, and let's filter this down to the configuration

0:11for

0:12interface, gig 1.0.25.

0:14That's leading to desktop one.

0:17And right off the bat, we'll see a whack ton of traditional IDNS1 style

0:22authentication

0:24configuration.

0:25It looks like this interface is configured for both 802.1x and mab, but

0:30otherwise, nothing

0:31looks after the ordinary.

0:32This is all of the traditional or what's also called the legacy style

0:37configuration

0:39that we've all come to know and love.

0:41But what if I told you that this configuration, even though nothing looks off

0:45about it, it's

0:46hiding a dark secret?

0:48And that secret is the fact that this configuration really just exists for show

0:54.

0:54It exists for us to look at, but it's not the actual configuration that iOS

0:59uses to

0:59operate.

1:01And the reason for that is that way back when Cisco had this dilemma, they knew

1:05that a

1:06bunch of administrators would be super used to working with these traditional

1:11authentication

1:12commands that we see in IDNS1.

1:14And so if how different IDNS2 is, they wouldn't want to switch.

1:19So you've got administrators that really want IBNS1, but you also have Cisco

1:24that wants

1:25to build their software around the newer, fancier IBNS2 with all of its new

1:30features.

1:31So the way that Cisco solved this dilemma is the exact same way that a kid

1:36would solve

1:37a dilemma between what kind of candy they want.

1:40Why not both?

1:42So what they did is they'll still allow us to configure authentication using

1:47this traditional

1:48legacy IBNS1 style, but as soon as we actually configure IBNS1, iOS on the back

1:56end, hidden

1:57away from us, it'll create this equivalent IBNS2 configuration, which is also

2:02called

2:03the new style.

2:05So on the back end, we've got two separate configurations, the IBNS1 that

2:10actually shows

2:11us in the running config and the cdpl that realistically speaking is what

2:16actually matters.

2:19So we'll put a little star next to it to show that because this configuration

2:22is what actually

2:22runs.

2:23But at the end of the day, we don't notice this again because the IBNS1 and IB

2:28NS2 configurations

2:30are one to one in terms of functionality.

2:32They are exactly equivalent in terms of their behavior.

2:36Now you might be wondering why does that matter if they behave the same anyway?

2:40Well, it's because it makes it a lot easier to go back and forth between IBNS1

2:48and IBNS2.

2:49Because when we configure authentication using IBNS1, the IBNS2 configuration

2:54is just chilling

2:55back there.

2:56And so we can tell iOS really easily to just show us the IBNS2 configuration.

3:01Now something to note before we go on and half the switch show us the IBNS2

3:05configuration

3:07is that it'll only have both versions, one and two, as long as we configure it

3:12using

3:13IBNS1.

3:14So if we just fully commit and we use IBNS2 in our configuration as well, Cisco

3:20's not

3:20going to go back and maintain an IBNS1 version of that configuration.

3:25As long as we're on board the IBNS2 train, Cisco's also on board.

3:29So we're just going to have that one IBNS2 configuration in that case.

3:33So let's clear this off and let's look at the IBNS2 version of this

3:37configuration.

3:39Now it's really easy to do that.

3:41All we need to do from privilege the exact mode, so not from global config,

3:45from right

3:46here, 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.

3:55We've got config mode.

3:57And if we run this, this is going to show us what our running config is

4:01currently using.

4:02So all this is telling us is that our running configuration and our startup

4:06configuration

4:07actually are written using the legacy style.

4:11Now if we want to look at what the cdrepl version of that configuration looks

4:16like,

4:17all we need to do is let's up arrow and remove config mode and let's replace

4:23that with new

4:24style.

4:25And when we run that, we're going to get this big message.

4:28I wouldn't really call it a warning, it's just telling us that we can always

4:33revert back

4:33to the legacy style unless we change the configuration.

4:38So with that, let's go back and we'll rerun that show run interface gig 1.0 25

4:44command

4:45and immediately whoa, hang on.

4:47That looks a lot different.

4:49Where did all of our authentication commands go?

4:53Ah, remember in IBNS one, the actual piece of software, the program that's

4:58running in

4:59iOS that manages all of our authentication, let's call it the authentication

5:05manager.

5:06So the commands that control how that authentication manager work, well, they

5:10are authentication

5:11commands make sense.

5:13But in IBNS two, that name got changed to the access session manager.

5:19So these commands have really just been renamed to reflect that change.

5:24That's all that's happened.

5:25So instead of it being authentication control direction in, now it's access

5:30session control

5:31direction in.

5:32But for the most part, we still have a lot of our commands.

5:35We 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

5:45changed at

5:45all.

5:46So if map, we still have dot one X P a, a de indicator, the one big change that

5:52we can

5:52see immediately is this access session closed command.

5:57What's that all about?

5:58Ah, well, this is a big change going from IBNS one to IBNS two with IBNS one.

6:04It was always assumed that interfaces were in closed mode by default.

6:10And you could make them open as a custom configuration using authentication

6:16open.

6:16So let's use for running monitor mode, for example, or low impact mode with a

6:21pre authentication

6:22ACL.

6:23But in IBNS two, they changed our functionality and basically reversed it.

6:29So now get the fault is open.

6:33And if we want to use close mode, we need to run the access session.

6:38So a dash S is going to be how we write that out closed.

6:41And that's this command that we see right here.

6:44So 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

6:51have an

6:51ACL, all traffic is going to be allowed even if authentication fails.

6:56Now, notably, we do still have some commands that are stragglers.

7:01So in this case, we see that authentication periodic and our timers, those are

7:07still

7:07going to be under the classic authentication command.

7:12But for the most part, most of the commands did get pulled over to the access

7:16session

7:16side.

7:17It's just that a couple were left on the other side.

7:21Of course, we still haven't accounted for all of the commands.

7:25For example, we scroll back up to our old legacy style of configuration.

7:31Where did our violation mode go?

7:33Where did our flex off go?

7:35Where did our critical authentication go?

7:37Ah, well, all of that got moved to our policy map.

7:43And this is where the magic of cdpl starts list command or right here service

7:48policy type

7:49control subscriber list command is what applies our cdpl policy map.

7:56Now you might recognize this command from dealing with QOS policy maps, where

8:01with QOS

8:02policy maps, we would do service policy input and in the name of the policy map

8:07.

8:07The big two differences with this command for cdpl is that we have this type

8:13control

8:13subscriber.

8:15This is what telescope switch that we're talking about a cdpl policy map

8:19specifically.

8:20So it's not going to try to apply a policy map that we're using for QOS, for

8:24example.

8:25And we also don't have a direction.

8:27The reason for that is that it wouldn't make much sense to talk about the

8:31direction

8:31when we're talking about 802.1x because we're always going to be talking about

8:36authenticating

8:37the device, the endpoint that's connected to this interface.

8:40We're never going to be talking about the endpoint authenticating the switch.

8:44Now let's also look at another interface, gig one, oh 26.

8:48This is connected to desktop two.

8:51And in the legacy IBS one world, I can tell you that these two interfaces were

8:55configured

8:56exactly the same way.

8:58So we can see we've got map and we've got 802.1x enabled and the IP and S2

9:03configuration

9:04also looks pretty much the exact same except we're using different policy maps.

9:11So when iOS creates this equivalent IP and S2 configuration from our legacy

9:17style configuration,

9:19it does it on a per interface basis.

9:22So every interface gets its own policy map and this goes against one of the big

9:27selling

9:27points of cdpl and IB and S2, which is that we can have multiple interfaces,

9:34but have

9:34a single policy map for both of them.

9:39That way, if we ever need to make a change to any of our authentication

9:42settings, we

9:43just make it once inside of this policy map and both of these interfaces are

9:47going to

9:48inherit that change.

9:50But because an IB and S1, we could have interfaces that have different settings

9:55.

9:55Ultimately, Cisco just took the easy way out and said, fine, because these

9:59interfaces

10:00could have different settings, we're just going to create separate policy maps

10:05for each

10:05interface just to make things simple.

10:07All 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.

10:18We don't have any interface templates to find right now.

10:20So we'll take a look at those in another skill.

10:23Let's do a show run and we're just going to filter just those things out of our

10:28configuration.

10:29So policy map and class map and service template.

10:34And I scroll to the end of that configuration, but we can see, wow, that is a

10:39lot of configuration.

10:40And actually see some configuration that's not related to cdpl.

10:44So let's actually have a bit of a tighter filter.

10:47So type control subscriber.

10:49We'll make sure that's on our policy map and our class map that should do it.

10:55And yep, that looks a lot better.

10:57So we're not going to go into the significance of every single setting.

11:02We're going to save that for another skill.

11:04The main takeaway for now, just so we can properly digest all of this, because

11:09this

11:09is a lot of configuration, the main takeaway is really how policy maps, class

11:15maps and

11:16service 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.

11:27And let's specifically focus into this section right here, starting at event

11:33session started.

11:34And then we've got this 10 class always statement.

11:38Now as a side note, for some reason, it looks like show run is actually dupl

11:43icating a bunch

11:44of configuration.

11:45So we've got 10 class always twice.

11:48That's just a bug though.

11:49In reality, this wouldn't be configured twice like this.

11:52You wouldn't have this other block down here, for example.

11:55But in any event, walking through the process, the first thing we would do is

12:00trigger the

12:00policy map.

12:02And that would happen because the policy map is tied to an interface.

12:06And we've got an end point on the interface that's trying to authenticate.

12:09So let's go ahead and put that in there.

12:12So we start off at the policy map, but then we dive into a specific event.

12:18We 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

12:27out how

12:27we should respond.

12:29And inside of the event, we've got a list of classes.

12:33Now in this case, for session started, we just have the one class, which is

12:37class always,

12:38but we could have a whole list of them.

12:41And depending on how the event is configured, whether it's configured to be

12:46match all, like

12:46session started is, or it could also be match first with match all we would

12:52execute the

12:53actions under any of the classes that match.

12:56Whereas with match first, just like with an ACL, where we go from the top and

13:00then go

13:00down until we match on the first entry, that's what's happening here.

13:05We looked through this list of classes until we find the first one that matches

13:10, and then

13:11we do the actions under that class, and then we stop looking.

13:14So if there's classes that come after that, that we would match, do bad.

13:19Now you might be asking, how do we know which one comes first?

13:22And 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

13:32under those

13:32classes.

13:33So those numbers are line numbers.

13:36So these line numbers allow us to define which lines are the top and which

13:41lines come

13:41after.

13:43And usually it's good practice.

13:44We can see to separate these by 10.

13:46So if we need to come in and make a change and insert a line between two lines,

13:51it makes

13:52it a lot easier to do that.

13:54So we can see down here it goes 10, 20, 30, 40, for example.

13:58That's just the best practice.

13:59We can make these line numbers whatever we want though.

14:02As long as they go in the order that we want.

14:05So for classes, the line numbers tell us the order that we're going to be

14:09looking at the

14:10classes and seeing if they match what actually happened for actions.

14:15The line numbers are going to tell us what order we want to execute the actions

14:19in.

14:19So looking down here, for example, at this triple A server down on

14:22authenticated host

14:24class, we have four actions.

14:26And 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.

14:33We'll also see though that events themselves, if we erase this, we'll see it

14:37more clearly,

14:38but events themselves don't have line numbers.

14:42And the reason for that is pretty simple.

14:44There's nothing that could ever happen that would fall under two different

14:48events.

14:49So we don't ever need to be worried about what event comes first.

14:52So getting back to our classes, we'll see how what comes after is usually going

14:58to be

14:58a class map.

14:59The exception to that we can see under session started is going to be always

15:05class.

15:06And that does exactly what it sounds like.

15:09It will always run unconditionally, which is why it doesn't take a class map

15:14because

15:14class maps are there for us to define conditions.

15:18Now there's also a setting that comes after the class map.

15:21In this case, it's due until failure and this is good default, but there are

15:26multiple

15:26options.

15:27We could also have do all and do until success there.

15:34And this has to do with how many actions we're actually going to execute do

15:38until failure

15:39means that we're going to do every action under the class until one fails, then

15:45we're

15:45going to stop.

15:46So for example, if we have this authentication statement under this class and

15:50we have a bunch

15:51of other actions after it, if that authentication fails, we're not going to do

15:55anything that

15:56comes after it.

15:57Due until success is the opposite, where if we have a bunch of actions under a

16:02class,

16:03we're going to do all of those actions until one succeeds, then we stop and do

16:08all is just,

16:09you know what, we don't care succeed fail, whatever, just do all of it.

16:14Now 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

16:22something happens,

16:23we can handle it.

16:24Now we're at it match all is the default for events.

16:28And we would swap that to match first if we wanted to really make sure that we

16:33didn't

16:33have any conflicts between classes.

16:36In other words, that we don't have one class doing one thing and then another

16:40class that

16:41comes after it coming along and undoing all of that.

16:44That's why authentication failure, this event is match first.

16:48So anyway, I've cleared this off to give us some more space.

16:52And in the situations, we're not using class always.

16:55So let's take a look at event authentication failure, for example, and five

17:00class dot one

17:01X failed.

17:02If it's not always, this is going to refer to a class map.

17:06So let's see if we can find it dot one X fail dot one X fail.

17:09There we go.

17:10We can see that this is a match all class map.

17:14And notice that just like we alluded to earlier, this is also type control

17:18subscriber to tell

17:19us that this is a C three P O class map.

17:22And 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

17:30to dot one

17:30X and that the result is authoritative.

17:33So let's work class maps come into play.

17:36Now after we match on a class, we're going to execute the actions that are

17:41sitting inside

17:42of that class.

17:44And usually this doesn't require anything extra that we need to configure

17:47beyond the

17:48action itself.

17:49So we can see in the session started event under the always class, we're saying

17:54authenticate

17:54using map.

17:56So we're doing map authentication.

17:57Great.

17:58We can see under dot one X failed this class, we are terminating dot one X.

18:03That also doesn't take any other configuration beyond just the action.

18:07But let's come down here to this other class with a super long class map name.

18:13So this is our critical authentication.

18:16And with critical authentication, remember, we are applying authorization

18:20results locally.

18:21We are putting them into a critical VLAN.

18:25So 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

18:33connection called

18:34critical off VLAN and then the interface.

18:38So let's see if we can find that service template.

18:42Let's scroll up and look for it.

18:45And indeed, we can right up here.

18:46So we've got this service template configured and it's super duper simple.

18:51Literally all it contains is one statement saying, yep, VLAN 1140.

18:56That's the VLAN.

18:57When we said that a service temple is just a list of settings, we literally

19:01meant it.

0:00Now, just like we mentioned earlier, we didn't change any of this.

0:03So we can always go back to IBNS1 by saying authentication display, again, all

0:09from privilege

0:10exec mode and legacy.

0:13And if we now do a show run and we look for our, let's say, policy map type

0:19control subscriber,

0:20hey, it's not there anymore.

0:22And if we go back and look at our interface configuration, the layers are

0:27familiar face.

0:29Or IBNS1 configuration.

0:31Now let's say that we're like, I actually want to do stuff with IBNS2.

0:36So let's go in and let's configure our policy map type control subscriber.

0:41And let's call this c3pl is awesome.

0:45And before we ignore this warning and just press enter, this is actually a

0:48really important

0:49message.

0:50So let's read through it.

0:51This operation will permanently convert all relevant authentication commands to

0:56their

0:56c3, I guess they have a missing three there.

1:00Let's help them out and Jordan see three PL control policy equivalent.

1:05It is irreversible and will disable the conversion CLI authentication display.

1:11Whoa, whoa, hang on a second.

1:13What this is really saying is if you want to run an IBNS2 command, you cannot

1:18go back

1:19to IBNS1.

1:21This is not allowed.

1:23You can go the other way.

1:24You can go IBNS1 to IBNS2, sure, but not from new to old.

1:31Now even though we should respect this warning, it is telling a truth.

1:35It's really telling a half truth because yeah, if we go forward and we convert

1:40the configuration,

1:40we can't go back right now.

1:43But if we reboot without saving the configuration and it boots back up with

1:48that IBNS1 configuration

1:50that's sitting in the startup configuration, we're good to go.

1:54We'll keep using IBNS1.

1:56It's only if we do this and then save the configuration to our startup config

2:01and we

2:01reboot into the startup config that it's truly irreversible without actually

2:06just wiping

2:07the 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

2:19is that the

2:19switch is looking at what it's booting up with.

2:23Is it booting up with IBNS1 configuration or IBNS2?

2:29If it's booting up with IBNS1 configuration, then that gives us access to all

2:35of our IBNS1

2:36commands and the option to switch to IBNS2, whether permanently or through that

2:42authentication

2:43display command to just do it temporarily.

2:46But we can't configure any IBNS2 settings.

2:51Granted, the IBNS2 configuration will still exist as we saw on the back end

2:55hidden away

2:56from us, but it will always be set to mirror what we do in the IBNS1 world.

3:02Whereas if we boot up with IBNS2 configuration, well, that gives us the ability

3:07to work with

3:08IBNS2 and actually configure it, but we can't switch back to IBNS1.

3:14And that's really the significance of that authentication display config mode

3:18command

3:19that we saw earlier.

3:21This tells us what it's booting up with.

3:23So again, to permanently convert, we can run any IBNS2 command or there's also

3:29a dedicated

3:30command just to convert, which is authentication convert to and new style.

3:36And we can see big difference.

3:37Now we're running it inside of the global configuration mode because what we're

3:42doing

3:43right here actually affects the configuration.

3:46So let's press enter and list time will accept the warning.

3:50And now if we go back and do a authentication display config mode, now telling

3:56us that our

3:57configuration is a new style.

3:59But if we do authentication display question mark, we'll notice that as the

4:04only command

4:05under authentication display now, we can't do authentication display legacy

4:09because that

4:10IBNS1 configuration no longer exists.

4:13So in our running configuration, let's go look at our interface again.

4:19And of course, we're using our new style cdpl configuration.

4:23And if we launch into our configuration mode and then look at the interface and

4:29under authentication,

4:31if we try to run, let's say authentication host mode and then let's say multi

4:37domain,

4:38we'll see that it's now telling us that this command is disabled, that we

4:42should be using

4:43access session instead.

4:45But of course, we haven't run a copy run start or a write memory right now.

4:49So in our startup configuration, let's look for gigabit ethernet, one oh 25.

4:56We'll see all of our IBNS one configuration is still intact, ready to blow that

5:01away.

5:02WR.

5:03So again, before we just did that, we could have reloaded and gotten ourselves

5:07out of

5:07IBNS2.

5:08So now we are fully committed to the IBNS-2 train.

0:00All right, let's close out the PowerShell window,

0:03starts up with the lab,

0:04and we're gonna open up our router and switch console

0:07and navigate to switch one.

0:10So our first task is gonna be to display

0:14the current configuration mode of our running config.

0:17So to do that, we just need to run

0:19the authentication display config mode command.

0:23And we'll see that our output is that

0:25the current configuration mode is legacy.

0:27So let's go look at this question.

0:30So was the output say the current configuration mode

0:32is legacy.

0:34Awesome.

0:34Let's move on to our next task.

0:36So we wanna configure the switch

0:38so that when we run the show run command,

0:41it'll show the cdpl configuration.

0:44But we also wanna be able to go back to IBS1 at any point.

0:48So this is not the permanent conversion.

0:51Instead, we just wanna do an authentication display.

0:56And let's run the new style version of this command.

0:59And now if we launch into a show run,

1:03and let's just look at our interface, gig 02,

1:06we'll see that we are indeed looking

1:08at our cdpl configuration.

1:11Now looking at our lab tasks,

1:13it's telling us to examine the configuration

1:16for gigabit ethernet 02.

1:19And we're gonna assume that we're dealing

1:20with the authentication failure event.

1:22So let's just filter down our show run

1:26to just look at policy map type control subscriber,

1:31and then policy, gi 02.

1:33And let's find our authentication failure event right there.

1:37And our first question is which five of the following

1:41are class maps that are referenced by the policy?

1:45So let's point out the class maps at this references.

1:49So the first is on line five, this .1x failed class map.

1:53The second is on line 10, this triple A server down

1:57on authenticated host one.

1:59The third one, line 20, is this authenticated host version

2:02of that earlier class map.

2:03These are some beautiful rectangles I'm drawing by the way.

2:06Online 30, we've got map failed.

2:09That's another one.

2:1040, we've got .1x, no response or no resp.

2:14So that's our five,

2:16but we also have another class entry.

2:19So always, what's up with this one?

2:21Well, remember this one is not a class map.

2:26This class is effectively built right into

2:30the policy map itself.

2:32And it doesn't need a class map

2:34because there are no conditions for the always class.

2:38As long as we actually get to evaluating this class,

2:42so in other words, if this doesn't match first,

2:44which it is, that any of the other classes

2:46didn't match before it, assuming we get to it though,

2:50it will always run.

2:52So those are our five, let's clear off our screen.

2:55And let's select the five that we saw before.

2:57So .1x failed, map failed, .1x on response,

3:01and then the two triple A server ones.

3:04Now, if we look at these other three

3:06and go back to our policy map,

3:09we'll see that in critical VLAN

3:11and not in critical VLAN are actually class maps

3:14that are referenced by this policy map,

3:17but they're not under the authentication failure event.

3:20Instead, they're under triple A available.

3:23And the critical of VLAN GI02,

3:27this is actually not a class map, it's a service template

3:30that's activated under one of the classes that we selected.

3:34So that's it for that question.

3:36Let's submit this and move on to the next one.

3:40So this question is asking us to put

3:42these cdpl objects in order.

3:45And the first thing we need to do

3:47is figure out what these cdpl objects are anyway.

3:50So let's look to our policy map.

3:54And we'll see that policy GI02 list is a policy map.

3:59So actually we'll put that first,

4:01because the policy map is always gonna be

4:04the first thing to trigger.

4:05And then if we look further down authentication failure,

4:09that's an event, so that comes next.

4:11So the question is what these two are.

4:13So if we look at our policy,

4:16we'll see a triple A server down unauthenticated host.

4:19This is a class that's right under

4:22the authentication failure event.

4:24So that goes under the event,

4:26which leaves this critical of VLAN GI02,

4:29which we saw just a moment ago,

4:31is a, where is it?

4:33There we go, service template.

4:34So our order goes policy map event class

4:38and then service template as an action.

4:41So let's press submit and move on to our last question.

4:45Now for this task, we're trying to ensure

4:48that the running configuration contains cdpl

4:52and cannot be reverted back to legacy mode,

4:56even after a reboot.

4:58So we wanna make this permanent.

5:00So to do that, all we need to do

5:02is hop on over to our lab again.

5:05And let's switch this back to authentication display

5:09legacy mode, just to see that we are indeed running

5:11IBNS one configuration in the running config.

5:15And to do our conversion, there's two main ways.

5:17The first is just to run any IBNS two commands.

5:21So let's go under our interface

5:23and try running access session host mode multi-off.

5:27And it's gonna ask us if we wanna permanently convert

5:30our IBNS one to IBNS two to actually run this command

5:34or alternatively we'll press control C to get out of that.

5:37Alternatively, what we can do is run the authentication

5:41convert to new style command from global config.

5:45And this will also directly convert our configuration

5:49from IBNS one to IBNS two.

5:51So we just press enter on that

5:53and let's run the authentication display config style command

5:58or whoops, rather, that's not the command.

6:00It's config mode, yep.

6:02And bingo, our current configuration mode is new style

6:06but we're not actually done even if it looks like it

6:09because our lab task also says that we want this

6:12to persist even after a reboot.

6:14So for that, all we need to do is write our configuration

6:18or copy run serve, that's more your jam.

6:21And answering the last question that we've got,

6:24what three of the following statements are true,

6:26we just saw that we did it using

6:28the authentication convert to new style commands.

6:30So that's the first one that's true.

6:33There is a warning that must be accepted

6:34before the conversion is complete, yep.

6:37We also just saw that giant warning

6:39that got plastered onto our CLI.

6:41The conversion is only complete after a reboot.

6:44Ah, this one's actually not true

6:45because if we go back and look at

6:47our authentication display config mode command,

6:50we'll see it this switch to new style

6:52from what it was earlier, which was, let's find it again,

6:56legacy and the entire time we didn't have to reboot the switch.

7:00So the conversion will immediately happen.

7:03It's just that we need to save our configuration

7:05in order for it to persist across reboots.

7:08All right, our next answer choice,

7:10this can be achieved by running any IBNS2 command, yep.

7:13Instead of using that dedicated convert to command,

7:16we can also just run any IBNS2 command

7:18and it's gonna prompt us to convert

7:20before we're actually allowed to go through with running it.

7:24So those are our three, so these next two must be wrong.

7:26This can be achieved by using the authentication display command.

7:30Nope, that's just to display the configuration

7:33temporarily in that style.

7:35And also as a side note, it's new style,

7:37not cdpl in that command.

7:39And this is gonna be achieved by using

7:41the convert to cdpl command.

7:43Nope, it's convert to new styles

7:46we saw in this first answer.

7:47So let's press submit.

7:49And that's it for our knowledge activity.