Understand Aruba Switching

0:00Alright friends, so let's begin talking about Aruba Switches. So here's the thing, with respect to Aruba Switches, they happen to run an operating system known as AOS CX, and this is their modern implementation of network operating systems. So whilst this has been around for quite a few years, if you happen to buy a brand new Aruba Switch as I'm recording this in 2025, this is the operating system that you're gonna get. And the good news is, is that this is a modern operating system with modern technology in mind.

0:30Now one thing to understand with Aruba Switches, we have a whole bunch of different options available. We'll talk about that in an upcoming video. We can have things such as the 6100 series, the 6200 series, we have the 8000 series switches, so on and so forth, a whole bunch of different switches capable of doing a whole bunch of different things. Here is the common denominator though, regardless if you happen to have an 8000 base series switch, or a 6200 or a 6100, it doesn't actually matter with respect to the underlying operating system.

1:00All of these and the rest of the switches that are modern are all gonna be running this AOS CX operating system. And this operating system has been described as a cloud native operating system. Now, you might be thinking that that's a little bit strange, does this mean we have to run the actual devices in the cloud, but it doesn't actually mean that at all. This is just a modern term to pretty much describe the fact that it's allowing for modern technologies, things such as automation. So automation is built in mind from the get-go, and it's not just been added on after the fact, and it also has a focus on having available APIs so that you can access the device in a programmatic manner.

1:40Pretty much what we're saying here is that this operating system is capable of thriving any modern environment. Pretty much if you happen to have experience with old, dusty, legacy CLI-based devices, maybe in your environment, you're having to have some really old other other switches or really old Cisco switches, that type of thing. If, say for example, you've tried to automate those devices, you might find there is quite a complicated task. They've not been designed with automation in mind. Instead, in order to implement such a thing, such as automation, you're gonna have a really limited experience about the actual things that you can do, but this is not the case with AOS CX.

2:17Because this guy here, it has been designed to be automated, to be able to handle telemetry, so on and so forth. So like I say, program ability really is at the heart of the design right here. Now, whether this actually look like in practical terms, so what that means in real terms is that on your aruba devices, you will be able to access them utilizing things known as REST APIs. Now, we're not gonna talk about the deep details of REST APIs at the moment. That is something for another day. But suffice to say, if you want to manage your aruba devices, utilizing something like say the Python programming language, well, by using the Python programming language in conjunction with the device's REST API, you're able to manage that device in a programmatic manner.

2:58This is the type of thing that allows you to get into that device and talk to it in a machine-to-machine lightweight. All right, so let's just look at the actual documentation for aruba on HPE's website. And we can really see here that these are the types of things that the operating system has been built to achieve. Simplify program ability, just as what we're seeing here. Automated visibility to help IT organization scale. High availability. Look at this one here. Ease of rollback to previous configurations. This one is very, very important. So let's say, for example, you happen to make changes to these two devices, okay?

3:30Now the configurations effectively result in a misconfiguration. So what actually happens is the connection between these two devices happens to break. All right, it also will know any point of misconfiguration. We don't let the way things have actually turned out. What we can do here is easily and automatically rollback to a known good configuration in the blink of an eye. So effectively, we can undo those conflicts and then once again, in an instant, our network is going to be operational. Same thing happens if you happen to be managing a device and it just flat out crashes.

4:01Or maybe a software update happens to go wrong. Once again, due to the design of AOS CX. We have that ability to easily rollback our configurations. Now the way that rollbacks are possible is due to the fact of this component right here, the fact that we have this time series database. Pretty much what is happening here is that all the changes in our operating system is ultimately being tracked and mapped via the time series database. So if we happen to have to go back in time, well, we can do that. And in a similar sense, for all of the events happening on our device, if we want to analyze them, well, we can ship that off to our network analytics engine.

4:39Pretty much a network analytics engine allows us to run pieces of software on the actual switch itself so that we can monitor things such as, you know, if something goes wrong, like an interface goes down or perhaps error counters happen to spike, that can be tracked via an A/E agents. And because of this, we can actually invoke automated responses so that could perhaps be just sending an alert. Or it can actually be taking proactive measures to modify the configuration and rectify the problem. Now here's another important point with respect to AOS CX.

5:09This has been designed to be a secure operating system, which kind of makes sense, doesn't it? This is a modern world. If we happen to have a modern operating system, well, this just seems like the bare bones basics that we should have. So of course, that's going to allow us to provide security features such as access control lists, but at an even deeper level, what AOS CX does is implement a trusted boot process. All right, all right, so what does that even mean? Well, pretty much what I'm saying here is that the system itself is not going to even power on at all unless every single piece of hardware passes an authentication check.

5:43So what that means is that perhaps if someone has been tampering with your device, perhaps maybe they've installed a rootkit, that type of thing. So what this actually means in real terms is that the operating system itself has been designed with these possibilities in mind, and it's going to actively combat against and protect your system from these types of attacks. So these are just some of the basic design principles of AOS CX. What I want to talk to you about in the very next video is some of the specifics about the particular platforms running AOS CX. So friends, let's talk about that in the very next video.

0:00Alright friends, let's continue on. Let's go and talk about the actual Aruba switch portfolio. Alright friends, all I've done is went to the HPE Aruba website right here and we can see here these are the HPE Aruba networking switches and of course in 2025 absolutely everything has to be about AI so naturally we can see here in the marketing we can see this as an AI ready networking switch so check this out. Let's scroll on down and find a little bit more information here okay so let's just scroll all the way down to the bottom here and look at these options that we have okay in fact let me just zoom in a little touch okay so look at these headings right here we have campus access, campus core and aggregation as well as data center and then additional campus and DC switches so notice the first option here is campus access so what are we talking about here well if say for example let's just draw a little network topology let's just say we 've got some switches here let's just draw some connections between them if we happen to have some PCs or some printers here that are going to be connecting into the network they be connect into the lower layer of the design model these here are the access switches the devices that are used to access the actual network itself these are the types of ones that we're talking about here with respect to campus access so for the edge of the network where the users happen to connect in this

1:16is a type of thing that we're talking about and we can see here the options that we have available for us okay so if I just scroll to the left here what we can actually see here is we have the CX 6000 series switch we can see here this is layer 2 access switches so it's not focused on layer 3 routing just for switching and we have support for one gig uplinks so again if we just happen to just say for example up at the data sheet here let's have a brief look at what we have as we can see we get the PDF documentation for everything that this particular device supports now straight away look at this okay look at this okay AOS CX in modern software system remember what I said it doesn't matter the type of device that you happen to buy from a rub of these days they're all going to be running the same operating system so what that means therefore is that it doesn't matter if you happen to buy an access layer switch one of the more inexpensive ones such as the CX 6000 series the actual operating system is going to be the exact same as what you would find in the more expensive devices that are within the core or aggregation layer and the good thing about this is that we can figure the exact same things in the exact same manner so if you want to configure a VLAN on this device the command you would issue on these devices up here would be the exact same as the commands you would issue on the devices down there this is very very good for automation

2:31and programmability so what is the big differentiator why would you ever buy an expensive device if it's just the same operating system as the cheaper devices well if we look at the data sheet once again if we look at the key features these are the things that are going to differentiate the different models of switches in this case here we happen to have one gigabit uplinks and we have support for things such as ACLs and QOS as well as static routing but we're not able to configure things like OSPF which is a routing protocol so for layer three operations this switch is not going to support those features so well as it might not support absolutely every feature or might not have the fastest uplinks for the features that it does support such as VLANs or for configuring static routes the actual configuration would be the exact same syntax as you would use on the higher end models that's what i'm trying to highlight here and again as i said even on these cheaper models we still get all the programmability such as being able to deploy the device with zero touch provisioning being able to manage the device via rest APIs all of that good stuff is still available to us even on these lower entry level switches so again we can see if we have more switch available let's just slide on over to say for example the well i don't know let's go with the CX6300 switch what we can see here is that this is a layer three stack

3:48able access and aggregation switch and we've got data transfer capabilities up to 100 gig in this respect now again as we can see here because this device happens to be more powerful more capable of things such as layer three it is an access switch if i try to draw that again john it's an access layer switch but it's also suitable to be used in the aggregation layer as well so this is a more powerful switch capable of more things but again running the same operating system and again if we go into the data sheet look at what is available let's look at this one scroll on down we can see here this model as a stackable layer three switch we're capable of doing things such as bgp which is routing as well as ospf and we're able to do more advanced technologies such as evpn and vxlan we also see we have the increased bandwidth capabilities but once again if we scroll on down sure enough what we're going to see here is what we just see right there okay it's still running the HPE Aruba CX operating system this is aos CX so having that ability for automation having that ability for microservices all of this still available in this particular switch now just going back to the documentation here like i say what you'll notice with some switches is that there is some crossover between what they can actually do some words designed for the access layer such as the 6,000 series whereas 6,300 that straddles both access and aggregation that's

5:09the true also for other particular models so for example the core and aggregation layer look at this okay so these ones here such as the 8000 base series and the 9000 base series such as 9300 or 8400 both are these capable of operating in the core as well as the aggregation layer and we can see here in the case of the 9300 series we have 32 ports of 100 gig and even as high as 400 gig switching speeds and again i would encourage you to look through the data sheets of these particular models become familiar with some of the features let's look at the one for the 9300 here we can see the image of the actual device itself as we can see it in the left hand side we have a whole bunch of key features scrolling on down we can see tons and tons and tons of options but crucially like i say you're not going to be surprised as we can see here the product differenti ators what is the operating system once again it is a os cx the exact same os as all of the other available models so really what i'm trying to highlight to you and really stress here is that there is a lot of consistency across the aruba switching portfolio if you've ever configured a 6 200 series switch you're going to have no problem at all adapting to say for example an 8400 series switch you know maybe this new fancy more expensive device has more capacity to shuttle data quicker maybe it's got the ability to run a few different features that you didn't see on other

6:26devices but generally speaking the way you interact with that device the way you access the rest api the way you can figure realigns that type of thing all of it is going to be very very familiar the real big distinction is much more like things like some will support only 24 ports okay whereas others might support 48 ports some switches are going to be stackable some will support layer 3 and layer 2 while some will only support layer 2 itself now one feature which is really quick cool that you're going to find on the 6200 6300 as well as 6400 series is that they all have support for something known as quick poe as well as always on poe so what even is this technology well let me show you let's say for example in your environment you want to connect a device into your network say for example an IP phone such as this okay now this IP phone itself is going to require some type of power to actually operate that as opposed to having to plug this IP phone into a socket such as you will with your laptop what you can do is just connect the device itself into your aruba switch now the aruba switch itself can supply the device the power it needs to actually operate the actual electricity and it's done over the ethernet connection this is power over ethernet okay now there's a fair good chance that you've already heard of this type of technology but let me just tell you about always on poe so let's say for example in the case here this is

7:44what we've done we have our IP phone here connected to the switch the switch is providing power to the phone over this line right here all good okay but let's now say that for whatever reason this switch here has to be rebooted now ordinarily when this switch happens to be shut off temporarily and it begins to rebutze essentially what happens is that when the power goes off here there is no power to send to the device therefore the phone itself also goes offline now it doesn't matter if it's an IP phone or a CCTV camera the point is is that the end device is using the switch itself to power itself now in the case of always on poe even if the switch itself happens to reboots the power over ethernet across this line here is going to remain persistent and the device itself is going to remain online and active so very very important if you happen to be using IoT devices connected in over power over ethernet or say for example utilizing things such as CCTV that's been powered using power over ethernet so that is always on poe the other one is the quick poe now typically with regular old poe what you would have to do is to wait for the device to fully boot up once it was fully booted then it could begin sending power to the end devices over ethernet now the big distinction here with quick poe is

9:00that the moment you plug in your switch and it begins to cycle on immediately we can begin sending power over ethernet directly to our end device and they can begin functioning as needed so once again very important for your IoT devices for your cameras that type of thing and like I say these particular features are available in the access portion of the aruba switch portfolio so really what i'm suggesting is that the best thing to do is to go to the roba website and become familiar with the switching portfolio whether it's campus access campus current aggregation or data center switches understanding the capabilities is really really important remember though whatever device you happen to be using or choosing what is that common denominator but once again they're all running the exact same operating system they're all running aruba's AOS CX

0:00Alright friends, in this particular video what we're going to do is to talk about these legacy operating systems and how things used to be done Versus how network management happens in the modern world with a modern operating system So let's talk a little bit about the traditional way to manage a network device So say for example, you have this device right here let's just call this device number one quite simply and you want to log into this device and make some configuration changes now Typically what you would do is you would take a console cable and you would connect it into the back of the switch You could open up some type of terminal in either software such as putty or maybe something like security that type of thing and Effectively what you would do is you would go into the device on the command line and you would begin making changes Directly to the configuration itself now the thing about the configuration is that it's effectively stored as flat Configuration files so do I mean when I say that well if we go in and look at this device for example So if I go into my device look at the configuration by saying show ring config What we're actually seeing here is the configuration is running on the device now What I want you to notice is this the configuration here is all just an regular plain text you as a human can read this No problem at all and in a similar way the actual configuration is not in any type of hierarchical structure

1:16We don't have particular sections. We don't have any type of nesting It really is just a linear and straight up and down configuration file now for you as a human This is very human readable the problem is is that when you want to have an automation system manage this type of configuration Well, it really is not so advantageous so else we can see here We clearly do have access to this configuration style as human engineers Just understand that a robust CX also supports other types of formats And we'll talk more about that very very shortly Now similarly if you wanted to manage this particular device and monitor it to make sure nothing goes wrong What you might use is SNMP the simple network management protocol So what you could do is you could perhaps have a little server over here that would be continually querying these devices on a Periodic basis. Let's say every two minutes you go in and grab interface statistics for your devices Making sure all the interfaces are up. Nothing is down that type of thing You can do that utilizing SNMP and in a similar sense Let's say you happen to be having errors on your machine What you can use to identify these errors is something known as syslog and you can just parse through the outputs manually and Identify what the problems may be now. Here's the thing all of this stuff It totally works under NIABLATE does work The problem is is that it is kind of inefficient it will get the job done

2:34But it's error prone and it certainly is an optimal and this is not what we want for a modern operating system For example when you happen to use these flat configuration files It actually is really quite difficult to track the state of the network and in a similar sense If you want to use an automation system that's going to pull the configuration and perhaps run automated tests Then it is really quite difficult for that automation system to parse out really specific pieces of information From that entire linear and flat configuration file alright So here comes a point when I sell you on the benefits of AOS CX okay to a suspect to AOS CX Effectively the configuration itself is not just stored as text or at least not seen by the operating system is just regular text Instead each of the configurations themselves are seen as objects within a wider database Now because of this what you're able to do with automation systems is to easily target very specific pieces of information that you want from the configuration Say you just wanted to parse out perhaps the network mask on this particular interface Well believe it or not for regular CLI based information or rather CLI based configuration Should I say this can be pretty challenging might sound quite simple But it isn't quite so easy Whereas when you happen to have your configuration stored as structured data or

3:53at least have the ability for it to be returned to a structured data Been able to access that type of very specific pieces of information is honestly really trivial and very very easy Now in a similar sense because the configuration is treated as data objects This means that it's really quite easy for you to roll back into a known good state because you can actually try to track the state of the network much easier And as opposed to monitoring your device using something like say SNMP With a modern system such as AOS CX what you can actually do is utilize streaming telemetry whereby once again We can take this structured data I eat a very particular piece of information within the configuration itself and Effectively what you can do is just stream that particular data back to a server that is monitoring it for any type of issues So once again, let's just say that on this particular interface here We want to perhaps check that it never happens to flap there is always in the upstate and let's just imagine We've got a little monitoring device over here. So this can be your server What we can do is configure this device here to stream data back to the server here So that as soon as say for example this interface happens to flap We're not having to wait for this device here to pull the information every few minutes instead We can just have that change directly stream back to us any proactive manner So whether the interface is flapping whether the CPU and the device happens to

5:10be going through the roof and it's way too high We can just stream that data back to our monitoring systems Now another thing to note about a robot AOS CX is that it's built with a micro services architecture Now what in the earth does that even mean this is just buzzwords John? What are we talking about? Well imagine all of the services on your system. So say for example I don't know they're routing on the system itself the actual daemon that is responsible for actually doing the routing on the device It can run as its own independent service on the switch itself And if that particular daemon has to share information to another part of the system Well, it can just freely share that information without it having to be one big monolithic application So let's just say that the mini application that is used for routing on the device happens to crash Well, what it can simply do is just reboot itself and reset as opposed to just having one giant application whereby this type of crash would bring down the entire system Instead things like VLANs or switching so on so forth all of that can just remain unaffected by this type of event And quite honestly This is a type of architecture that you see so often in modern cloud applications as opposed to just having one large Complex codebase instead you just have smaller individual components that are plugged together that can Synchronize with one another and talk to each other in real time

6:27So the beauty of this is like I say we still have access to the good old CLI We still have access to that flat configuration file if you so wish but I think you can see here There is a lot more to this type of operating system

0:00Alright friends, we've mentioned this thing a couple of times already. What is this big, bad, scary thing known as a REST API? Now first thing to state here, we're going to have a dedicated skill on this very topic later on within this very course. However, for a basic introduction, let's talk about some of the basic details behind a REST API. Now first thing to state here is if you have heard the kind of buzz, the excitement around network automation, a lot of it kind of relates to this concept right here.

0:30Many of the devices we are automating now are providing these REST APIs. And this is kind of the hint what I'm getting at here. REST APIs really are friendly to network automation or really for friendly for all types of automation, not just for networking devices. So let's actually discuss what a REST API actually is. So really, the API itself is just an interface. It's a way for you to access your device. Now a REST API is effectively just specifying a particular set of roles in which you can interact with this device in a programmatic manner.

1:03So say for example, I have my device right here and let's imagine that I have a little server here. This is where I'm managing my system from. Okay. Now traditionally, if I did remote management, what I would do would be to log in, oversee SSH and then I could go and just issue the regular commands over the CLI as you ordinarily would. Now instead, as opposed to connecting over SSH, what we can do is connect over HTTP or rather HTTPS, which is the secure version of HTTP. Now the way we actually invoke this connection can be done via a few different ways.

1:34We can actually use a web browser, which is what you use when you go to say, for example, google.com, you are using HTTP to get the web traffic and it's been presented to you in the form of a browser. However, we don't just have to use a browser to interact over HTTP. There are a whole bunch of other options that we have also. Say, for example, we want to use the Python programming language. We can actually use particular Python libraries to talk to our end device using HTTP. And we can do it using all the programmatic magic that we get for my programming language, such as Python. Now in a similar sense, when we happen to make this request over HTTP to our end device, the actual response we get back from our device is not just going to be regular CLI text that we see from the command line. This type of flat config file. Okay.

2:20Instead, typically, we're going to get the response back in something known as JSON, which pretty much gives us access to objects that we can work with. Now again, how this actually operates, this is something for another day, like I said, we'll talk about it later on in another skill. But just understand the fact that we get the information back as actual data objects and not just plain text, just for the moment, take my word for it, that this is really, really powerful when it comes to trying to automate your network. Now, let's just talk a little bit about the request themselves. So say, for example, you want to get information such as, or I don't know, let's just say you want to get VLAN information about your device. If we log in here over the CLI, what we would do is just type in something like say show VLAN and we get the actual information there.

3:01And again, if I want to create a new VLAN, I just type in the command and then if I exit out and again, run show VLAN, we're going to see the new information presented in plain text on the screen. So we have these commands that we just type as regular syntax on the command line right here. That is the legacy way to do things. If we happen to use a REST API, we actually make use of URIs. So what I'm going to say that, well, take for example this, okay, let's just go to a website, for example. All right, to us, all I've done is I went to the Wikipedia page. Now, right now, this is the homepage as it says here, and maybe you can't read this. But in my browser, this says, this says wikipedia.org/wicket/mainpage and it gives me access to everything that has been hosted on the main page. However, let's just say I go and click on something else, okay, so let's just maybe go to, well, I don't know, it says here in basketball, Oklahoma City Thunder. Let's click on this, okay. Now straight away here, what we're actually seeing here is a whole bunch of different information completely different from the main page. This is completely different data.

3:58Now look at this right here. See how the actual URL here happened to change. It says wikipedia.org/wicket and then it says forward slash Oklahoma underscore city underscore thunder. Okay, so what's the point here? Well, there actually is a correlation between what you enter up here, where you send your ACDPS web request and what you actually get back from the server when we make the request to this end point, we get information such as this. And again, if I just scroll through this random way, let's just find another link to click. If I click on say, for example, NBA finals, as so, we're actually making an ACDPS request to this particular endpoint, which is forward slash wikipedia forward slash 2005 underscore NBA finals. And this gives us a completely different resource on the server itself. This time we're just talking about the NBA finals. Now how does this relate to networking at all? Okay, well, let's just say that on this particular device, we could reach it on the IP address of 192 168 1.1. Okay, now let's just say we had our server here, and we want to make an ACDP request to the server using its rest API. Well, pretty much, if I just make that request to this IP address and specify a particular path, that's going to correlate to a particular resource on the server, just like we saw with our web requests. So if I'm my server here, I make the

5:15request to, like I say, 80 DPS colon colon forward slash forward slash then IP address. And then I try something like this as a forward slash rest. And then maybe let's say forward slash VLANs, actually sending this request to this particular endpoint is going to tell the actual switch itself here. Hey, we want to get VLAN information that the resource we're targeting. And we want that information over the rest API, which means it's going to be a term to the server in this programmatic form such as in JSON. Whereas if we wanted to see something like say the routing table, we could maybe change the end point to be forward slash rest, and then just make the request as something like say forward slash routes. And again, by changing the actual endpoint and the same way we get a different resource from the Wikipedia page, we would get a different response from the server based on that actual URI or sending. Now, the question you might think would be, well, how do I find out all the particular URIs that I have to use? Well, pretty much we'll do with that later on in an upcoming skill. But basically, the actual documentation is going to give you a vast list of all of the available endpoints. So you're not just guessing you're not just typing in random words.

6:20That is a very particular structure that a robot is going to follow. And the cool thing is with our REST APIs, we can actually change configurations on the device. So say, for example, we wanted to add in a new static route, we could do so over 80 DPS using the REST API in a programmatic manner. Say, for example, using the Python programming language, or alternatively, what we can also do is pull existing configurations such as the type of information that you would get from a show VLAN or a show run command. And by the way, you can also pull operational state information, what should be the type of thing, like, you know, how many errors are on interface, how many broadcasts are we seeing on this interface, so on, so forth. Now, like I said, the beauty of this, the whole point of this is to enable things like automation. So as opposed to you having to log into each device individually, one by one by one by one, and issuing these commands over SSH on your command line interface, instead, you could have just an automation system that can reach out to all devices at the same time, pulling all the information, run programmatic logic to run tests, it can make configuration changes when necessary, it can allow you to particular errors such as flapping links, we can create information about all devices in our network and feed that information into visualization graphs, so we can actually see how the data utilization is. And

7:37these are just some of the things that we can do with a modern operating system such as AOS CX .

0:00Alright friends, alright alright, in this particular video what we're going to do is talk about dynamic segmentation. Now this is a really really useful feature of Aruba AOS C X, so let's just dive in and talk about what it actually does. So imagine this, wouldn't it be cool if you are a user, let's just say you are down here and you have your little laptop with you. So here is the laptop and this is absolutely awesome drawing skills and what you do is you connect that into a particular switch, okay. Now let's just imagine that the switch had the ability to automatically assign the network policy based on who you are. So let's say I am John, I happen to be a visitor or a contractor on the website or the website on the network should I say and because I'm a visitor I should have well rather limited access to the resources on this particular network and because I happen to be a visitor that's going to be my role in the network and automatically no matter where about I happen to plug in my device I'm going to get the same limited access. Now this is the kind of thing that we're talking about here now contrast this with the more manual assignment of network policy.

1:05So what do I mean I'm going to say that well typically what might actually happen, let me just grab a little PC here to give an example. Here you have PC here and let's just say you connect it into this particular switch on interface let's say interface 113 okay, so there we go right there. Now what you would ordinarily do would be you'd go into this particular switch and you would say hey by the way on interface 113 let's maybe say it's going to be in VLAN 15 okay all right all right so that means anyone connected to that particular port is going to be in this particular VLAN. Now let's just say for let's just say for argument's sake that VLAN 15 happens to be correlating with the finance department all right and here I am John I'm just roaming about and for whatever reason let's just say that this device here happened to be unplugged and I just connected my device into interface 113 but because I have access to that particular interface either user John who really should be a visitor is actually now accessing the finance VLAN because there's a direct correlation between that physical port and the V LAN itself we're not actually considering who the end user is that is connecting to that particular port. Now quite honestly doing this type of configuration is not necessarily a bad thing especially if you have good lockdown security with respect to physical access of your ports and you

2:24can do things like Mac authentication to ensure that not just anyone can connect to any particular ports so we do have defenses against this particular thing but regardless doesn't it sound much easier much more dynamic much more well simplified just to have the ability for any user to connect in anywhere and whatever their role should be that is what the network's going to give them and this is the fact of what we're talking about here we have this concept of a colorless port so when we're talking about a colorless port all we're meaning is that the port itself is not actually a configure with anything special it's just a default setting it's got no particular color no particular policy no particular configuration it's just a bland old colorless port basically there is nothing special about port 113 it's not associated itself with a particular VLAN the policy will be defined based on who actually connects to which particular ports so think about it like this as opposed to having to worry about access controllers and manually configure who's connected on this particular port with this particular IP address who they can talk to as opposed to worrying about who's connected on this particular port and what quality of service should be associated with that particular port or again as we talked about the particular VLAN configuration with a particular port if we just have all of this just automatically defined based on who connects well as

3:41you can imagine this makes our role much much easier and also allows for greater flexibility and mobility of our users throughout our network so this amazing magic known as colorless ports how is it actually implemented well this is what we're talking about with the concept of dynamic segmentation in fact the name itself is kind of giving you a hint the segmentation of the network the way it 's broken up it's not static it's not just defined on particular ports it is dynamic and it's going to be built out depending on where about the network particular users happen to connect now how does it authentication and the building of this particular configuration actually happen now the way this can be implemented is via a product known as aruba clear pass now the way you can kind of conceptualize aruba clear pass is it's basically like a radius server and it's going to be responsible for the authentication of users trying to access the network and it's going to assign particular roles based on that particular user now before we get any further that happens to be two ways in which we're going to implement this type of solution and these relate to the way that the traffic is going to be tunneled so let's first talk about the first way in which things can be tunneled and this is known as UBT so this is user based tunneling and effectively what it's going to do is it's

4:57going to focus on the use of user identities and associated roles just as we're talking about the advantage of this is that it's super super granular okay so pretty much we can be very specific about who is going to connect and what they can actually do within the network now very important when we happen to implement this type of UBT tunneling based on the actual user bound here the role they happen to have we're going to invoke something known as a mobility controller this is going to be a centralized node in the network that is going to act as the central brain for the decision making now this mobility controller it can actually live on the network itself it can be perhaps accessible over the cloud in the internet the point is is we're going to have to build torros to it to make particular decisions so let me just focus in on this for a moment okay let's just go back here delete this so we're not caring about which interface we're connecting to let's just say that once again here I am john I'm a visit on the network or I'm a contract or I'm a contract that type of thing I'm not part of the main network or rather the main team should I say here's my laptop and I just plug it into a particular interface let's say I plug it into interface 1 1 1 okay now the point here is we don't actually care about the actual interface configuration here because it is a colorless port nothing special about this particular interface as it stands

6:15right now what is special though is how I authenticate with the network now straight away what we're going to do here is the switch itself is going to go and connect to a ruba clear pass and it's going to try to authenticate me as a user now how could I authenticate or how could I provide my identity so the identity can come in many different forms the identity could just be the MAC address of my device so they say hey by the way we know your MAC address whatever this MAC address i.e this device connects into the network we will associate that with you most associated with a particular role but it doesn't just have to be a MAC address maybe you're going to be prompted with a particular username and password combination maybe the username is guest and the password is g pass 1 okay that is a user and password combination and given the fact i have this combination this can identify me as a guest on the network okay same type of thing or alternatively maybe it's not going to be a username and password combination maybe instead it's going to be a certificates now there also are other ways in which we can't effectively prove our identity but these are some common ones okay so really what we have here is our identity and this is what we provide effectively to the switch itself either via a MAC address or a username and password or perhaps a certificate that is on our device so we effectively pass that identity to the switch the switch sends it to clear

7:35pass and clear pass is going to do a check and say hey do i have a particular policy for this MAC address or this username password combination or this certificate that i've just been supplied so let's just say we happen to apply a username and password that's sent to clear pass right here and clear pass then assigns to us a role so that information is sent back down to the switch saying pretty much hey the role of the person connected to that particular interface 111 they should have a guest role or maybe a thousand employee i could have the role of employee that type of thing okay now the switch is down here they are going to be configured to understand these particular roles now in this case here because we're using user based authentication and again let me just draw myself here back again just connecting in what the switch is now going to do is going to build a tunnel all the way up to the mobility controller now the controller here is kind of acting like an advanced DHCP server here okay so it can feed down information such as what the IP address should actually be for that particular device connecting down here i could say hey by the way i know that person is going to be a guest i'm going to put in vlan number 25 whatever it may be whatever the guest vlan is going to be we might say hey that particular device given it is a guest should have particular quality of service so it should be rate limited not going to get a whole ton of bandwidth that type of thing and we're also going to implement

8:52some particular access controllers for that particular device now notice what just happened here all of these policies here which are now applied to my device were not determined based on the physical port that i connected to it could have been any port the main thing that happened here is that when i happened to connect into the network the network asked the clear pass device to authenticate who i was once that happened the switch itself then builds a tunnel to the mobility controller to actually define what the policy should be for that device now we have actually authenticated so the cool thing is the next day i could go into the office and here i am once the game with my laptop it's day two of my contract what do i do i connect into the network let 's say connect to port 119 this time again it doesn't matter the port same thing's going to happen the switch is going to tell clear pass who i happen to be clear pass is going to clear it and say hey by the way that is a guest or a visitor the switch once again builds the connection to the controller and then the controller tells the switch right here what the policy should be so i once again get the same vlan configs same qos that type of thing not tied to a particular physical port instead what we can see here is the policy is actually tied to the user itself the actual authentication that we provide to the network so the good thing about this is that it provides a

10:07central point of management based on our policies are controlled via the controller our authentication is controlled via the clear pass server and now all the users and the network are free to roam no problem at all so that is the first way in which we can use dynamic segmentation like you say that is user based tunneling the second way is known as vnbt so this one here is a little bit different it tends to be simpler and it's well it scales really well but the difference is is we're not actually focused on the users connecting themselves instead we are actually focused in on particular network segments i.e. defined via particular vlan's so this one here is known as vnbt which is virtual network based tunneling and essentially what is happening here is particular devices are assigned to particular vlan's based on particular information such as what type of device are you talking about is this a printer is this a CCTV camera is this an IoT device that type of thing so let 's just say we've got an actual server here that connects in okay so we want to associate this with the vlan that deals with servers and again first thing that happens is we connect in to the actual device the switch itself is going to contact clear pass and clear pass is going to do the authentication pretty much defining what the device happens to be now previously with user

11:22based tunneling the next stage would be to build a tunnel from a switch itself to the mobility controller whereby we would actually get the policy in this case though for vnbt we don't use the mobility controller so instead of what happens is like i say the server connects in to the switch itself the switch tells clear pass about this clear pass then authenticates as the device is allowed to be on the network and as opposed to building a tunnel to the mobility controller instead the actual switches themselves build tunnels between them so say for example we build a tunnel to this guy right here this is known as a vxlan tunnel such as say we've got another server here connecting in we can then ride these tunnels and build connections between these devices so the key point to note here is that the virtual tunnels are built to a particular point in the network infrastructure so that could be safe for example a data center if that's where you're going to be connecting to perhaps maybe it's going to be to a particular switch in the network maybe a course switch that type of thing whatever the end pointer is you're trying to reach now basically the whole point of this is that all the devices in the same vlan so like say for example a server vlan they're going to receive the same type of access within the network the same type of security within the network it's based on their vlan membership not their actual user identification so

12:38like you say this happens to be a lot simpler because well it's not quite so fine and granular it 's just based on the device type connecting to the network whereas the first type is actually based on the particular user connecting into the network and the network is going to adapt to that particular user so pretty much you could use user-based tunneling for particular members of staff such as people who belong to the marketing departments or people who happen to be guests on the network and then you could use virtual network based tunneling for devices of a particular type such as your CCTV cameras or your printers or your servers that type of thing pretty much the whole point of this though is whatever one you happen to implement there is a dynamic nature to the network it's not about switching having static configurations on particular physical parts of the network instead as we can see here the network is much more fluid and dynamic and it can adapt to the type of access controller policies the type of QOS policies the type of vlan information IP address assignments all of that can fluctuate depending on who connects to the network or which device type connects to the network and that can be authenticated via aruba clear pass and like I say all of this simplified management and flexible magic is all made available and possible through aruba's AOS CX.

0:00Our reference here is the validation challenge. Imagine you are the network administrator for a company that has recently bought new Aruba CX 6100 and CX8400 switches. The first thing I want you to do is to identify the operating system that will be running on each of these devices respectively and then determine which of the switches would you use for the access layer of your network. To understand that, consider that your team want to central enforce policies based on the identity of users connecting into the network.

0:33So what I want you to do is to think about which Aruba product could you use to authenticate in the scenario and assign the correct roles and policies. And then finally what I want you to do is to identify which tunneling method would be used in this particular scenario. So friends, go give it a go and I will see you in the very next video where we discuss

0:00Alright friends, so let's talk about the answer then. So we are the network admin for a company that has recently bought new aruba switches. We have the CX6100 and CX8400 switches. So the first thing we've got to do is identify which operating system that will be running on each of these devices respectively. So straight away we've got two different switches. This one is a more expensive switch. This one is a little bit cheaper. Which operating system will we be seeing on this one as well as this one? Well if you remember the thing that I really wanted to stress is the independent of these lower entry level switches such as the 6100 and the higher level switches such as 8400 or the 10,000 series, they are all going to be running the same operating system.

0:44That is AOS CX. So really really important to remember that the main differentiator is just the speeds at which these particular switches can operate. I.e. more ports with greater capacity and the higher end switches are going to have more features. But as for the operating system, the syntax, all of it is going to be the same. It's going to be a robot AOS CX. Alright so next thing is to determine which of the switches would you use for the access layer. Well the 6000 series switches are the lower end switches, more designed for the edge of the network.

1:15And in fact the 6100 series particularly is a very good choice for the access layer of your network. Whereas the 8400 series which you could technically put in to the access layer, it would be kind of wasted at that particular point. This would be much more of an aggregation or a core layer switch. Ok so next point here is a team want to centrally enforce policies based on the identity of users connecting into the network. Which aruba product could you use to authenticate in the scenario and assign the correct roles and policies?

1:45Well in this case here we can use aruba clear pass. Remember when we talked about dynamic segmentation, we mentioned that aruba clear pass kind of acts like a radius style server. It's going to allow users to connect in to the network via colourless ports. I.e ports are not actually configured with particular policies or configurations. We just connect them, the switch can then authenticate with clear pass, and clear pass can decide is this user authenticated and which roles should they actually have. And now finally in the scenario whereby we're using clear pass for user based authentication.

2:18We want to identify which tunneling method is going to be used in this particular scenario. Well the tunneling method is going to be UBT this is user based tunneling. So pretty much when a user connects in that particular switch is going to talk to clear pass. Clear pass will determine the roles and policies and from that point the switch is going to build a tunnel to a central point in the network known as the mobility controller. And then the mobility controller can begin giving that particular switch its V LAN configuration, its IP address, its quality of service configuration, its ACL configs, all of that good stuff.

2:53So friends that is us for our validation challenge on aruba.os. CX switching. I hope this has been informative for you. I'd like to thank you for viewing.