Understand Aruba Switching

0:00Alright friends, so let's begin talking about Aruba Switches.

0:03So here's the thing, with respect to Aruba Switches,

0:06they happen to run an operating system known as AOS CX,

0:10and this is their modern implementation

0:12of network operating systems.

0:14So whilst this has been around for quite a few years,

0:16if you happen to buy a brand new Aruba Switch

0:19as I'm recording this in 2025,

0:21this is the operating system that you're gonna get.

0:23And the good news is,

0:24is that this is a modern operating system

0:27with modern technology in mind.

0:30Now one thing to understand with Aruba Switches,

0:32we have a whole bunch of different options available.

0:35We'll talk about that in an upcoming video.

0:37We can have things such as the 6100 series,

0:40the 6200 series, we have the 8000 series switches,

0:43so on and so forth, a whole bunch of different switches

0:45capable of doing a whole bunch of different things.

0:48Here is the common denominator though,

0:50regardless if you happen to have an 8000 base series switch,

0:54or a 6200 or a 6100,

0:56it doesn't actually matter with respect

0:58to the underlying operating system.

1:00All of these and the rest of the switches that are modern

1:03are all gonna be running this AOS CX operating system.

1:07And this operating system has been described

1:10as a cloud native operating system.

1:13Now, you might be thinking that that's a little bit strange,

1:16does this mean we have to run the actual devices

1:18in the cloud, but it doesn't actually mean that at all.

1:20This is just a modern term

1:22to pretty much describe the fact

1:24that it's allowing for modern technologies,

1:26things such as automation.

1:28So automation is built in mind from the get-go,

1:31and it's not just been added on after the fact,

1:34and it also has a focus on having available APIs

1:37so that you can access the device in a programmatic manner.

1:40Pretty much what we're saying here

1:42is that this operating system

1:43is capable of thriving any modern environment.

1:46Pretty much if you happen to have experience

1:48with old, dusty, legacy CLI-based devices,

1:51maybe in your environment,

1:52you're having to have some really old

1:54other other switches or really old Cisco switches,

1:56that type of thing.

1:57If, say for example, you've tried to automate those devices,

2:01you might find there is quite a complicated task.

2:04They've not been designed with automation in mind.

2:06Instead, in order to implement such a thing,

2:08such as automation,

2:10you're gonna have a really limited experience

2:12about the actual things that you can do,

2:14but this is not the case with AOS CX.

2:17Because this guy here,

2:19it has been designed to be automated,

2:21to be able to handle telemetry, so on and so forth.

2:24So like I say,

2:25program ability really is at the heart

2:27of the design right here.

2:28Now, whether this actually look like in practical terms,

2:31so what that means in real terms is that

2:33on your aruba devices,

2:34you will be able to access them utilizing things

2:36known as REST APIs.

2:38Now, we're not gonna talk about the deep details

2:40of REST APIs at the moment.

2:41That is something for another day.

2:43But suffice to say,

2:45if you want to manage your aruba devices,

2:47utilizing something like say the Python programming language,

2:50well, by using the Python programming language

2:52in conjunction with the device's REST API,

2:55you're able to manage that device in a programmatic manner.

2:58This is the type of thing that allows you to get into that

3:01device and talk to it in a machine-to-machine lightweight.

3:04All right, so let's just look at the actual documentation

3:06for aruba on HPE's website.

3:09And we can really see here that these are the types of things

3:11that the operating system has been built to achieve.

3:14Simplify program ability, just as what we're seeing here.

3:16Automated visibility to help IT organization scale.

3:19High availability.

3:21Look at this one here.

3:22Ease of rollback to previous configurations.

3:24This one is very, very important.

3:25So let's say, for example,

3:26you happen to make changes to these two devices, okay?

3:30Now the configurations effectively result

3:31in a misconfiguration.

3:33So what actually happens is the connection between

3:36these two devices happens to break.

3:38All right, it also will know

3:39any point of misconfiguration.

3:41We don't let the way things have actually turned out.

3:43What we can do here is easily and automatically rollback

3:47to a known good configuration in the blink of an eye.

3:49So effectively, we can undo those conflicts

3:53and then once again, in an instant,

3:55our network is going to be operational.

3:57Same thing happens if you happen to be managing a device

3:59and it just flat out crashes.

4:01Or maybe a software update happens to go wrong.

4:04Once again, due to the design of AOS CX.

4:07We have that ability to easily rollback our configurations.

4:10Now the way that rollbacks are possible

4:13is due to the fact of this component right here,

4:15the fact that we have this time series database.

4:18Pretty much what is happening here is that all the changes

4:21in our operating system is ultimately being tracked

4:24and mapped via the time series database.

4:27So if we happen to have to go back in time,

4:29well, we can do that.

4:30And in a similar sense,

4:31for all of the events happening on our device,

4:34if we want to analyze them,

4:35well, we can ship that off to our network analytics engine.

4:39Pretty much a network analytics engine

4:41allows us to run pieces of software

4:43on the actual switch itself

4:45so that we can monitor things such as, you know,

4:47if something goes wrong, like an interface goes down

4:49or perhaps error counters happen to spike,

4:51that can be tracked via an A/E agents.

4:55And because of this, we can actually invoke

4:57automated responses so that could perhaps be

4:59just sending an alert.

5:01Or it can actually be taking proactive measures

5:03to modify the configuration and rectify the problem.

5:06Now here's another important point with respect to AOS CX.

5:09This has been designed to be a secure operating system,

5:13which kind of makes sense, doesn't it?

5:15This is a modern world.

5:16If we happen to have a modern operating system,

5:18well, this just seems like the bare bones basics

5:20that we should have.

5:21So of course, that's going to allow us to provide security

5:24features such as access control lists,

5:26but at an even deeper level,

5:28what AOS CX does is implement a trusted boot process.

5:32All right, all right, so what does that even mean?

5:34Well, pretty much what I'm saying here

5:35is that the system itself is not going to even power on at all

5:39unless every single piece of hardware

5:42passes an authentication check.

5:43So what that means is that perhaps

5:45if someone has been tampering with your device,

5:47perhaps maybe they've installed a rootkit, that type of thing.

5:49So what this actually means in real terms

5:51is that the operating system itself

5:53has been designed with these possibilities in mind,

5:56and it's going to actively combat against

5:58and protect your system from these types of attacks.

6:01So these are just some of the basic design principles

6:03of AOS CX.

6:05What I want to talk to you about in the very next video

6:07is some of the specifics about the particular platforms

6:10running AOS CX.

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

0:03switch portfolio.

0:04Alright friends, all I've done is went to the HPE Aruba website right here and

0:09we can see here

0:10these are the HPE Aruba networking switches and of course in 2025 absolutely

0:17everything has to be

0:18about AI so naturally we can see here in the marketing we can see this as an AI

0:23ready networking

0:24switch so check this out. Let's scroll on down and find a little bit more

0:28information here okay

0:29so let's just scroll all the way down to the bottom here and look at these

0:31options that we have okay

0:33in fact let me just zoom in a little touch okay so look at these headings right

0:36here we have campus

0:37access, campus core and aggregation as well as data center and then additional

0:42campus and DC

0:43switches so notice the first option here is campus access so what are we

0:48talking about here well

0:49if say for example let's just draw a little network topology let's just say we

0:52've got some

0:53switches here let's just draw some connections between them if we happen to

0:57have some PCs or

0:58some printers here that are going to be connecting into the network they be

1:01connect into the lower

1:02layer of the design model these here are the access switches the devices that

1:07are used to access the

1:08actual network itself these are the types of ones that we're talking about here

1:11with respect to campus

1:12access so for the edge of the network where the users happen to connect in this

1:16is a type of

1:16thing that we're talking about and we can see here the options that we have

1:19available for us okay

1:21so if I just scroll to the left here what we can actually see here is we have

1:25the CX 6000 series

1:26switch we can see here this is layer 2 access switches so it's not focused on

1:30layer 3 routing

1:31just for switching and we have support for one gig uplinks so again if we just

1:36happen to just

1:37say for example up at the data sheet here let's have a brief look at what we

1:40have as we can see

1:41we get the PDF documentation for everything that this particular device

1:45supports now straight away

1:46look at this okay look at this okay AOS CX in modern software system remember

1:52what I said it

1:53doesn't matter the type of device that you happen to buy from a rub of these

1:56days they're all going

1:57to be running the same operating system so what that means therefore is that it

2:01doesn't matter

2:02if you happen to buy an access layer switch one of the more inexpensive ones

2:05such as the CX 6000 series

2:07the actual operating system is going to be the exact same as what you would

2:11find in the more

2:12expensive devices that are within the core or aggregation layer and the good

2:15thing about this

2:16is that we can figure the exact same things in the exact same manner so if you

2:19want to configure

2:20a VLAN on this device the command you would issue on these devices up here

2:24would be the exact same

2:25as the commands you would issue on the devices down there this is very very

2:29good for automation

2:31and programmability so what is the big differentiator why would you ever buy an

2:35expensive device if

2:36it's just the same operating system as the cheaper devices well if we look at

2:40the data sheet once

2:41again if we look at the key features these are the things that are going to

2:44differentiate the

2:45different models of switches in this case here we happen to have one gigabit

2:50uplinks and we have

2:51support for things such as ACLs and QOS as well as static routing but we're not

2:56able to configure

2:57things like OSPF which is a routing protocol so for layer three operations this

3:02switch is not

3:03going to support those features so well as it might not support absolutely

3:07every feature or

3:08might not have the fastest uplinks for the features that it does support such

3:13as VLANs

3:13or for configuring static routes the actual configuration would be the exact

3:18same syntax as you would

3:19use on the higher end models that's what i'm trying to highlight here and again

3:23as i said even on these

3:24cheaper models we still get all the programmability such as being able to

3:27deploy the device with

3:29zero touch provisioning being able to manage the device via rest APIs all of

3:33that good stuff is

3:34still available to us even on these lower entry level switches so again we can

3:38see if we have

3:39more switch available let's just slide on over to say for example the well i

3:42don't know let's go

3:43with the CX6300 switch what we can see here is that this is a layer three stack

3:48able access and

3:49aggregation switch and we've got data transfer capabilities up to 100 gig in

3:54this respect now

3:55again as we can see here because this device happens to be more powerful more

3:59capable of things such

4:00as layer three it is an access switch if i try to draw that again john it's an

4:04access layer switch

4:06but it's also suitable to be used in the aggregation layer as well so this is a

4:10more powerful switch

4:11capable of more things but again running the same operating system and again if

4:15we go into the data

4:16sheet look at what is available let's look at this one scroll on down we can

4:20see here this model as

4:21a stackable layer three switch we're capable of doing things such as bgp which

4:25is routing

4:25as well as ospf and we're able to do more advanced technologies such as evpn

4:30and vxlan we also see

4:32we have the increased bandwidth capabilities but once again if we scroll on

4:36down sure enough what

4:37we're going to see here is what we just see right there okay it's still running

4:41the HPE Aruba

4:42CX operating system this is aos CX so having that ability for automation having

4:48that ability

4:49for microservices all of this still available in this particular switch now

4:54just going back to

4:55the documentation here like i say what you'll notice with some switches is that

4:58there is some

4:59crossover between what they can actually do some words designed for the access

5:02layer such as the

5:036,000 series whereas 6,300 that straddles both access and aggregation that's

5:09the true also for

5:10other particular models so for example the core and aggregation layer look at

5:14this okay so these

5:15ones here such as the 8000 base series and the 9000 base series such as 9300 or

5:208400 both are

5:21these capable of operating in the core as well as the aggregation layer and we

5:25can see here

5:26in the case of the 9300 series we have 32 ports of 100 gig and even as high as

5:32400 gig switching

5:33speeds and again i would encourage you to look through the data sheets of these

5:36particular models

5:37become familiar with some of the features let's look at the one for the 9300

5:41here we can see the

5:41image of the actual device itself as we can see it in the left hand side we

5:45have a whole bunch of

5:46key features scrolling on down we can see tons and tons and tons of options but

5:50crucially like i

5:51say you're not going to be surprised as we can see here the product differenti

5:55ators what is the

5:55operating system once again it is a os cx the exact same os as all of the other

6:01available models so

6:02really what i'm trying to highlight to you and really stress here is that there

6:06is a lot of

6:06consistency across the aruba switching portfolio if you've ever configured a 6

6:11200 series switch

6:13you're going to have no problem at all adapting to say for example an 8400

6:17series switch you know

6:18maybe this new fancy more expensive device has more capacity to shuttle data

6:22quicker maybe it's got

6:23the ability to run a few different features that you didn't see on other

6:26devices but generally

6:28speaking the way you interact with that device the way you access the rest api

6:31the way you can

6:32figure realigns that type of thing all of it is going to be very very familiar

6:36the real big

6:36distinction is much more like things like some will support only 24 ports okay

6:40whereas others might

6:41support 48 ports some switches are going to be stackable some will support

6:46layer 3 and layer 2

6:47while some will only support layer 2 itself now one feature which is really

6:51quick cool that you're

6:51going to find on the 6200 6300 as well as 6400 series is that they all have

6:57support for something

6:58known as quick poe as well as always on poe so what even is this technology

7:03well let me show you

7:05let's say for example in your environment you want to connect a device into

7:08your network say

7:09for example an IP phone such as this okay now this IP phone itself is going to

7:14require some type of

7:15power to actually operate that as opposed to having to plug this IP phone into

7:19a socket such

7:20as you will with your laptop what you can do is just connect the device itself

7:24into your aruba

7:24switch now the aruba switch itself can supply the device the power it needs to

7:29actually operate the

7:30actual electricity and it's done over the ethernet connection this is power

7:34over ethernet okay now

7:36there's a fair good chance that you've already heard of this type of technology

7:39but let me just

7:40tell you about always on poe so let's say for example in the case here this is

7:44what we've done we have

7:45our IP phone here connected to the switch the switch is providing power to the

7:50phone over this line

7:51right here all good okay but let's now say that for whatever reason this switch

7:55here has to be

7:56rebooted now ordinarily when this switch happens to be shut off temporarily and

8:00it begins to rebutze

8:02essentially what happens is that when the power goes off here there is no power

8:07to send to the device

8:08therefore the phone itself also goes offline now it doesn't matter if it's an

8:12IP phone or a CCTV

8:13camera the point is is that the end device is using the switch itself to power

8:18itself now in the case

8:19of always on poe even if the switch itself happens to reboots the power over

8:24ethernet across this

8:25line here is going to remain persistent and the device itself is going to

8:28remain online and active

8:30so very very important if you happen to be using IoT devices connected in over

8:34power over ethernet

8:35or say for example utilizing things such as CCTV that's been powered using

8:39power over ethernet so

8:41that is always on poe the other one is the quick poe now typically with regular

8:47old poe what you

8:48would have to do is to wait for the device to fully boot up once it was fully

8:53booted then it could

8:54begin sending power to the end devices over ethernet now the big distinction

8:58here with quick poe is

9:00that the moment you plug in your switch and it begins to cycle on immediately

9:05we can begin

9:06sending power over ethernet directly to our end device and they can begin

9:10functioning as needed

9:12so once again very important for your IoT devices for your cameras that type of

9:16thing and like I

9:17say these particular features are available in the access portion of the aruba

9:23switch portfolio

9:24so really what i'm suggesting is that the best thing to do is to go to the roba

9:27website and become

9:28familiar with the switching portfolio whether it's campus access campus current

9:33aggregation

9:34or data center switches understanding the capabilities is really really

9:38important

9:39remember though whatever device you happen to be using or choosing what is that

9:43common denominator

9:44but once again they're all running the exact same operating system they're all

9:48running aruba's AOS CX

0:00Alright friends, in this particular video what we're going to do is to talk

0:02about these legacy operating systems and how things used to be done

0:06Versus how network management happens in the modern world with a modern

0:11operating system

0:12So let's talk a little bit about the traditional way to manage a network device

0:17So say for example, you have this device right here

0:20let's just call this device number one quite simply and you want to log into

0:24this device and make some configuration changes now

0:27Typically what you would do is you would take a console cable and you would

0:30connect it into the back of the switch

0:31You could open up some type of terminal in either software such as putty or

0:35maybe something like security that type of thing and

0:38Effectively what you would do is you would go into the device on the command

0:42line and you would begin making changes

0:44Directly to the configuration itself now the thing about the configuration is

0:48that it's effectively stored as flat

0:50Configuration files so do I mean when I say that well if we go in and look at

0:54this device for example

0:55So if I go into my device look at the configuration by saying show ring config

0:59What we're actually seeing here is the configuration is running on the device

1:02now

1:03What I want you to notice is this the configuration here is all just an regular

1:07plain text you as a human can read this

1:09No problem at all and in a similar way the actual configuration is not in any

1:14type of hierarchical structure

1:16We don't have particular sections. We don't have any type of nesting

1:18It really is just a linear and straight up and down configuration file now for

1:22you as a human

1:23This is very human readable the problem is is that when you want to have an

1:27automation system manage this type of configuration

1:29Well, it really is not so advantageous so else we can see here

1:34We clearly do have access to this configuration style as human engineers

1:38Just understand that a robust CX also supports other types of formats

1:42And we'll talk more about that very very shortly

1:44Now similarly if you wanted to manage this particular device and monitor it to

1:49make sure nothing goes wrong

1:50What you might use is SNMP the simple network management protocol

1:55So what you could do is you could perhaps have a little server over here that

1:58would be continually querying these devices on a

2:00Periodic basis. Let's say every two minutes you go in and grab interface

2:04statistics for your devices

2:06Making sure all the interfaces are up. Nothing is down that type of thing

2:09You can do that utilizing SNMP and in a similar sense

2:14Let's say you happen to be having errors on your machine

2:16What you can use to identify these errors is something known as syslog and you

2:21can just parse through the outputs manually and

2:23Identify what the problems may be now. Here's the thing all of this stuff

2:27It totally works under NIABLATE does work

2:30The 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

2:38want for a modern operating system

2:40For example when you happen to use these flat configuration files

2:44It actually is really quite difficult to track the state of the network and in

2:49a similar sense

2:49If you want to use an automation system that's going to pull the configuration

2:53and perhaps run automated tests

2:55Then it is really quite difficult for that automation system to parse out

2:59really specific pieces of information

3:01From that entire linear and flat configuration file alright

3:05So here comes a point when I sell you on the benefits of AOS CX okay to a

3:09suspect to AOS CX

3:11Effectively the configuration itself is not just stored as text or at least not

3:16seen by the operating system is just regular text

3:19Instead each of the configurations themselves are seen as objects within a

3:23wider database

3:24Now because of this what you're able to do with automation systems is to easily

3:28target very specific pieces of information that you want from the configuration

3:32Say you just wanted to parse out perhaps the network mask on this particular

3:36interface

3:37Well believe it or not for regular CLI based information or rather CLI based

3:42configuration

3:43Should I say this can be pretty challenging might sound quite simple

3:46But it isn't quite so easy

3:48Whereas 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

3:56Been able to access that type of very specific pieces of information is

4:00honestly really trivial and very very easy

4:03Now in a similar sense because the configuration is treated as data objects

4:07This means that it's really quite easy for you to roll back into a known good

4:11state because you can actually try to track the state of the network much

4:14easier

4:14And as opposed to monitoring your device using something like say SNMP

4:18With a modern system such as AOS CX what you can actually do is utilize

4:23streaming telemetry whereby once again

4:25We can take this structured data

4:27I eat a very particular piece of information within the configuration itself

4:31and

4:31Effectively what you can do is just stream that particular data back to a

4:35server that is monitoring it for any type of issues

4:38So once again, let's just say that on this particular interface here

4:42We want to perhaps check that it never happens to flap there is always in the

4:46upstate and let's just imagine

4:47We've got a little monitoring device over here. So this can be your server

4:50What we can do is configure this device here to stream data back to the server

4:54here

4:54So that as soon as say for example this interface happens to flap

4:58We're not having to wait for this device here to pull the information every few

5:01minutes instead

5:02We can just have that change directly stream back to us any proactive manner

5:06So 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

5:12We can just stream that data back to our monitoring systems

5:15Now another thing to note about a robot AOS CX is that it's built with a micro

5:19services architecture

5:20Now what in the earth does that even mean this is just buzzwords John? What are

5:24we talking about?

5:24Well imagine all of the services on your system. So say for example

5:29I don't know they're routing on the system itself the actual daemon that is

5:33responsible for actually doing the routing on the device

5:36It can run as its own independent service on the switch itself

5:40And if that particular daemon has to share information to another part of the

5:43system

5:43Well, it can just freely share that information without it having to be one big

5:48monolithic application

5:49So let's just say that the mini application that is used for routing on the

5:52device happens to crash

5:54Well, what it can simply do is just reboot itself and reset as opposed to just

5:58having one giant application whereby this type of crash would bring down the

6:02entire system

6:03Instead things like VLANs or switching so on so forth all of that can just

6:08remain unaffected by this type of event

6:10And quite honestly

6:11This is a type of architecture that you see so often in modern cloud

6:14applications as opposed to just having one large

6:18Complex codebase instead you just have smaller individual components that are

6:22plugged together that can

6:23Synchronize 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

6:31We still have access to that flat configuration file if you so wish but I think

6:34you can see here

6:35There is a lot more to this type of operating system

0:00Alright friends, we've mentioned this thing a couple of times already.

0:03What is this big, bad, scary thing known as a REST API?

0:06Now first thing to state here, we're going to have a dedicated skill on this

0:10very topic

0:11later on within this very course.

0:13However, for a basic introduction, let's talk about some of the basic details

0:18behind a REST API.

0:20Now first thing to state here is if you have heard the kind of buzz, the

0:24excitement around

0:26network 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.

0:35And this is kind of the hint what I'm getting at here.

0:38REST APIs really are friendly to network automation or really for friendly for

0:43all types of automation,

0:44not just for networking devices.

0:45So let's actually discuss what a REST API actually is.

0:49So really, the API itself is just an interface.

0:52It's a way for you to access your device.

0:54Now a REST API is effectively just specifying a particular set of roles in

0:59which you can interact

1:01with 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

1:07little server

1:07here. This is where I'm managing my system from.

1:10Okay.

1:10Now traditionally, if I did remote management, what I would do would be to log

1:13in,

1:14oversee SSH and then I could go and just issue the regular commands over the

1:18CLI as you ordinarily

1:19would.

1:20Now instead, as opposed to connecting over SSH, what we can do is

1:24connect over HTTP or rather HTTPS, which is the secure version of HTTP.

1:31Now the way we actually invoke this connection can be done via a few different

1:34ways.

1:34We can actually use a web browser, which is what you use when you go to say,

1:38for example,

1:38google.com, you are using HTTP to get the web traffic and it's been presented

1:43to you in the form

1:44of a browser. However, we don't just have to use a browser to interact over

1:49HTTP.

1:49There are a whole bunch of other options that we have also.

1:52Say, for example, we want to use the Python programming language.

1:56We can actually use particular Python libraries to talk to our end device using

2:00HTTP.

2:01And we can do it using all the programmatic magic that we get for my

2:04programming language,

2:05such as Python. Now in a similar sense, when we happen to make this request

2:09over HTTP to our

2:11end device, the actual response we get back from our device is not just going

2:15to be regular CLI

2:16text 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

2:24JSON,

2:24which pretty much gives us access to objects that we can work with.

2:28Now again, how this actually operates, this is something for another day, like

2:31I said,

2:31we'll talk about it later on in another skill. But just understand the fact

2:35that we get the

2:36information back as actual data objects and not just plain text, just for the

2:40moment,

2:40take my word for it, that this is really, really powerful when it comes to

2:44trying to automate

2:45your network. Now, let's just talk a little bit about the request themselves.

2:48So say,

2:48for example, you want to get information such as, or I don't know, let's just

2:52say you want to get

2:53VLAN information about your device. If we log in here over the CLI, what we

2:57would do is just

2:58type in something like say show VLAN and we get the actual information there.

3:01And again,

3:02if I want to create a new VLAN, I just type in the command and then if I exit

3:05out and again,

3:06run show VLAN, we're going to see the new information presented in plain text

3:10on the screen.

3:11So we have these commands that we just type as regular syntax on the command

3:15line right here.

3:16That is the legacy way to do things. If we happen to use a REST API, we

3:19actually make use of

3:21URIs. So what I'm going to say that, well, take for example this, okay, let's

3:24just go to a website,

3:26for example. All right, to us, all I've done is I went to the Wikipedia page.

3:30Now, right now,

3:30this is the homepage as it says here, and maybe you can't read this. But in my

3:34browser, this says,

3:35this says wikipedia.org/wicket/mainpage and it gives me access to everything

3:40that has been

3:41hosted on the main page. However, let's just say I go and click on something

3:44else, okay, so let's

3:45just maybe go to, well, I don't know, it says here in basketball, Oklahoma City

3:49Thunder. Let's click

3:50on this, okay. Now straight away here, what we're actually seeing here is a

3:53whole bunch of

3:54different information completely different from the main page. This is

3:57completely different data.

3:58Now look at this right here. See how the actual URL here happened to change. It

4:02says wikipedia.org/wicket

4:04and then it says forward slash Oklahoma underscore city underscore thunder.

4:08Okay, so what's the

4:09point here? Well, there actually is a correlation between what you enter up

4:13here, where you send

4:14your ACDPS web request and what you actually get back from the server when we

4:19make the request to

4:20this end point, we get information such as this. And again, if I just scroll

4:23through this random

4:24way, let's just find another link to click. If I click on say, for example, NBA

4:28finals, as so,

4:30we're actually making an ACDPS request to this particular endpoint, which is

4:35forward slash wikipedia

4:36forward slash 2005 underscore NBA finals. And this gives us a completely

4:40different resource on the

4:41server itself. This time we're just talking about the NBA finals. Now how does

4:44this relate to networking

4:46at all? Okay, well, let's just say that on this particular device, we could

4:49reach it on the IP address

4:50of 192 168 1.1. Okay, now let's just say we had our server here, and we want to

4:57make an ACDP request

4:59to the server using its rest API. Well, pretty much, if I just make that

5:04request to this IP address

5:06and specify a particular path, that's going to correlate to a particular

5:10resource on the server,

5:12just like we saw with our web requests. So if I'm my server here, I make the

5:15request to, like I say,

5:1780 DPS colon colon forward slash forward slash then IP address. And then I try

5:21something like

5:22this as a forward slash rest. And then maybe let's say forward slash VLANs,

5:26actually sending this

5:27request to this particular endpoint is going to tell the actual switch itself

5:32here. Hey, we want to

5:33get VLAN information that the resource we're targeting. And we want that

5:37information over the rest

5:38API, which means it's going to be a term to the server in this programmatic

5:42form such as in JSON.

5:43Whereas if we wanted to see something like say the routing table, we could

5:47maybe change the end

5:48point to be forward slash rest, and then just make the request as something

5:51like say forward slash

5:52routes. And again, by changing the actual endpoint and the same way we get a

5:56different resource from

5:57the Wikipedia page, we would get a different response from the server based on

6:01that actual

6:02URI or sending. Now, the question you might think would be, well, how do I find

6:05out all the particular

6:06URIs that I have to use? Well, pretty much we'll do with that later on in an

6:10upcoming skill. But

6:11basically, the actual documentation is going to give you a vast list of all of

6:16the available

6:17endpoints. So you're not just guessing you're not just typing in random words.

6:20That is a very

6:21particular structure that a robot is going to follow. And the cool thing is

6:25with our REST APIs,

6:26we can actually change configurations on the device. So say, for example, we

6:30wanted to add in a new

6:31static route, we could do so over 80 DPS using the REST API in a programmatic

6:35manner. Say, for example,

6:37using the Python programming language, or alternatively, what we can also do is

6:42pull existing configurations

6:43such as the type of information that you would get from a show VLAN or a show

6:47run command. And by

6:49the way, you can also pull operational state information, what should be the

6:52type of thing,

6:53like, you know, how many errors are on interface, how many broadcasts are we

6:57seeing on this interface,

6:58so on, so forth. Now, like I said, the beauty of this, the whole point of this

7:02is to enable

7:02things like automation. So as opposed to you having to log into each device

7:06individually,

7:07one by one by one by one, and issuing these commands over SSH on your command

7:12line interface,

7:13instead, you could have just an automation system that can reach out to all

7:17devices at the same time,

7:18pulling all the information, run programmatic logic to run tests, it can make

7:23configuration

7:23changes when necessary, it can allow you to particular errors such as flapping

7:27links,

7:28we can create information about all devices in our network and feed that

7:31information into

7:33visualization graphs, so we can actually see how the data utilization is. And

7:37these are just

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

7:42.

0:00Alright friends, alright alright, in this particular video what we're going to

0:02do is talk about

0:04dynamic segmentation. Now this is a really really useful feature of Aruba AOS C

0:09X, so let's just dive

0:10in and talk about what it actually does. So imagine this, wouldn't it be cool

0:14if you are a user,

0:15let's just say you are down here and you have your little laptop with you. So

0:19here is the laptop

0:20and this is absolutely awesome drawing skills and what you do is you connect

0:24that into a particular

0:25switch, okay. Now let's just imagine that the switch had the ability to

0:29automatically assign the

0:30network policy based on who you are. So let's say I am John, I happen to be a

0:36visitor or a contractor

0:38on the website or the website on the network should I say and because I'm a

0:42visitor I should have

0:43well rather limited access to the resources on this particular network and

0:48because I happen to be a

0:49visitor that's going to be my role in the network and automatically no matter

0:53where about I happen

0:54to plug in my device I'm going to get the same limited access. Now this is the

0:59kind of thing

0:59that we're talking about here now contrast this with the more manual assignment

1:04of network policy.

1:05So what do I mean I'm going to say that well typically what might actually

1:08happen,

1:08let me just grab a little PC here to give an example. Here you have PC here and

1:12let's just

1:12say you connect it into this particular switch on interface let's say interface

1:16113 okay,

1:17so there we go right there. Now what you would ordinarily do would be you'd go

1:21into this particular

1:22switch and you would say hey by the way on interface 113 let's maybe say it's

1:26going to be in VLAN 15

1:28okay all right all right so that means anyone connected to that particular port

1:33is going to be

1:34in this particular VLAN. Now let's just say for let's just say for argument's

1:38sake that VLAN 15

1:39happens to be correlating with the finance department all right and here I am

1:44John I'm just

1:45roaming about and for whatever reason let's just say that this device here

1:50happened to be unplugged

1:51and I just connected my device into interface 113 but because I have access to

1:57that particular

1:58interface either user John who really should be a visitor is actually now

2:02accessing the finance

2:04VLAN because there's a direct correlation between that physical port and the V

2:08LAN itself we're not

2:10actually considering who the end user is that is connecting to that particular

2:14port. Now quite

2:14honestly doing this type of configuration is not necessarily a bad thing

2:18especially if you have

2:20good lockdown security with respect to physical access of your ports and you

2:24can do things like

2:25Mac authentication to ensure that not just anyone can connect to any particular

2:28ports so we do have

2:29defenses against this particular thing but regardless doesn't it sound much

2:33easier much more dynamic

2:35much more well simplified just to have the ability for any user to connect in

2:40anywhere and whatever

2:41their role should be that is what the network's going to give them and this is

2:45the fact of what

2:46we're talking about here we have this concept of a colorless port so when we're

2:49talking about a

2:50colorless port all we're meaning is that the port itself is not actually a

2:53configure with anything

2:54special it's just a default setting it's got no particular color no particular

2:59policy no particular

3:00configuration it's just a bland old colorless port basically there is nothing

3:05special about

3:06port 113 it's not associated itself with a particular VLAN the policy will be

3:11defined

3:12based on who actually connects to which particular ports so think about it like

3:16this as opposed to

3:17having to worry about access controllers and manually configure who's connected

3:20on this particular

3:21port with this particular IP address who they can talk to as opposed to

3:25worrying about who's

3:26connected on this particular port and what quality of service should be

3:29associated with that particular

3:31port or again as we talked about the particular VLAN configuration with a

3:35particular port if we

3:36just have all of this just automatically defined based on who connects well as

3:41you can imagine this

3:42makes our role much much easier and also allows for greater flexibility and

3:46mobility of our users

3:48throughout our network so this amazing magic known as colorless ports how is it

3:53actually implemented

3:54well this is what we're talking about with the concept of dynamic segmentation

3:58in fact the name

3:59itself is kind of giving you a hint the segmentation of the network the way it

4:03's broken up it's not

4:04static it's not just defined on particular ports it is dynamic and it's going

4:10to be built out

4:10depending on where about the network particular users happen to connect now how

4:15does it authentication

4:16and the building of this particular configuration actually happen now the way

4:20this can be implemented

4:21is via a product known as aruba clear pass now the way you can kind of

4:25conceptualize aruba clear

4:26pass is it's basically like a radius server and it's going to be responsible

4:30for the authentication

4:32of users trying to access the network and it's going to assign particular roles

4:36based on that

4:36particular user now before we get any further that happens to be two ways in

4:40which we're going to

4:41implement this type of solution and these relate to the way that the traffic is

4:45going to be tunneled

4:46so let's first talk about the first way in which things can be tunneled and

4:50this is known as UBT

4:53so this is user based tunneling and effectively what it's going to do is it's

4:57going to focus on

5:00the use of user identities and associated roles just as we're talking about the

5:04advantage of this

5:05is that it's super super granular okay so pretty much we can be very specific

5:10about who is going to

5:11connect and what they can actually do within the network now very important

5:14when we happen to

5:16implement this type of UBT tunneling based on the actual user bound here the

5:21role they happen to

5:22have we're going to invoke something known as a mobility controller this is

5:26going to be a centralized

5:27node in the network that is going to act as the central brain for the decision

5:31making now this

5:32mobility controller it can actually live on the network itself it can be

5:36perhaps accessible over

5:37the cloud in the internet the point is is we're going to have to build torros

5:40to it to make

5:41particular decisions so let me just focus in on this for a moment okay let's

5:45just go back here

5:46delete this so we're not caring about which interface we're connecting to let's

5:51just say that once

5:52again here I am john I'm a visit on the network or I'm a contract or I'm a

5:55contract that type of

5:56thing I'm not part of the main network or rather the main team should I say

5:59here's my laptop and I

6:00just plug it into a particular interface let's say I plug it into interface 1 1

6:041 okay now the point

6:06here is we don't actually care about the actual interface configuration here

6:09because it is a

6:10colorless port nothing special about this particular interface as it stands

6:15right now what is special

6:16though is how I authenticate with the network now straight away what we're

6:20going to do here is

6:22the switch itself is going to go and connect to a ruba clear pass and it's

6:25going to try to

6:26authenticate me as a user now how could I authenticate or how could I provide

6:31my identity so the identity

6:32can come in many different forms the identity could just be the MAC address of

6:36my device so they say

6:38hey by the way we know your MAC address whatever this MAC address i.e this

6:41device connects into the

6:43network we will associate that with you most associated with a particular role

6:47but it doesn't

6:47just have to be a MAC address maybe you're going to be prompted with a

6:50particular username and

6:52password combination maybe the username is guest and the password is g pass 1

6:57okay that is a user

6:59and password combination and given the fact i have this combination this can

7:03identify me as a

7:04guest on the network okay same type of thing or alternatively maybe it's not

7:08going to be a

7:08username and password combination maybe instead it's going to be a certificates

7:13now there also are

7:13other ways in which we can't effectively prove our identity but these are some

7:16common ones okay so

7:17really what we have here is our identity and this is what we provide

7:21effectively to the switch itself

7:24either via a MAC address or a username and password or perhaps a certificate

7:28that is on our device

7:29so we effectively pass that identity to the switch the switch sends it to clear

7:35pass and clear pass

7:36is going to do a check and say hey do i have a particular policy for this MAC

7:40address or this

7:41username password combination or this certificate that i've just been supplied

7:45so let's just say

7:46we happen to apply a username and password that's sent to clear pass right here

7:50and clear pass

7:51then assigns to us a role so that information is sent back down to the switch

7:54saying pretty much

7:55hey the role of the person connected to that particular interface 111 they

8:00should have a guest

8:01role or maybe a thousand employee i could have the role of employee that type

8:05of thing okay now

8:06the switch is down here they are going to be configured to understand these

8:10particular roles

8:11now in this case here because we're using user based authentication and again

8:15let me just draw

8:16myself here back again just connecting in what the switch is now going to do is

8:19going to build

8:20a tunnel all the way up to the mobility controller now the controller here is

8:25kind of acting like an

8:26advanced DHCP server here okay so it can feed down information such as what the

8:30IP address

8:31should actually be for that particular device connecting down here i could say

8:34hey by the way i

8:35know that person is going to be a guest i'm going to put in vlan number 25

8:39whatever it may be

8:40whatever the guest vlan is going to be we might say hey that particular device

8:44given it is a

8:44guest should have particular quality of service so it should be rate limited

8:48not going to get a

8:49whole ton of bandwidth that type of thing and we're also going to implement

8:52some particular access

8:53controllers for that particular device now notice what just happened here all

8:57of these policies

8:58here which are now applied to my device were not determined based on the

9:02physical port that i

9:03connected to it could have been any port the main thing that happened here is

9:06that when i

9:07happened to connect into the network the network asked the clear pass device to

9:11authenticate who i

9:13was once that happened the switch itself then builds a tunnel to the mobility

9:17controller to

9:18actually define what the policy should be for that device now we have actually

9:22authenticated

9:23so the cool thing is the next day i could go into the office and here i am once

9:26the game with my

9:27laptop it's day two of my contract what do i do i connect into the network let

9:31's say connect to

9:32port 119 this time again it doesn't matter the port same thing's going to

9:36happen the switch is

9:37going to tell clear pass who i happen to be clear pass is going to clear it and

9:41say hey by the way

9:42that is a guest or a visitor the switch once again builds the connection to the

9:46controller and then

9:47the controller tells the switch right here what the policy should be so i once

9:51again get the same

9:52vlan configs same qos that type of thing not tied to a particular physical port

9:57instead what we can

9:58see here is the policy is actually tied to the user itself the actual

10:03authentication that we

10:04provide to the network so the good thing about this is that it provides a

10:07central point of

10:08management based on our policies are controlled via the controller our

10:12authentication is controlled

10:13via the clear pass server and now all the users and the network are free to

10:17roam no problem at all

10:19so that is the first way in which we can use dynamic segmentation like you say

10:22that is user based

10:24tunneling the second way is known as vnbt so this one here is a little bit

10:29different it tends to be

10:30simpler and it's well it scales really well but the difference is is we're not

10:35actually focused on

10:36the users connecting themselves instead we are actually focused in on

10:40particular network segments

10:42i.e. defined via particular vlan's so this one here is known as vnbt which is

10:46virtual network based

10:48tunneling and essentially what is happening here is particular devices are

10:52assigned to particular

10:54vlan's based on particular information such as what type of device are you

10:57talking about is this

10:58a printer is this a CCTV camera is this an IoT device that type of thing so let

11:03's just say we've

11:04got an actual server here that connects in okay so we want to associate this

11:07with the vlan that

11:08deals with servers and again first thing that happens is we connect in to the

11:12actual device

11:13the switch itself is going to contact clear pass and clear pass is going to do

11:17the authentication

11:18pretty much defining what the device happens to be now previously with user

11:22based tunneling

11:23the next stage would be to build a tunnel from a switch itself to the mobility

11:27controller whereby

11:29we would actually get the policy in this case though for vnbt we don't use the

11:34mobility controller

11:35so instead of what happens is like i say the server connects in to the switch

11:38itself the switch

11:40tells clear pass about this clear pass then authenticates as the device is

11:44allowed to be on the network

11:45and as opposed to building a tunnel to the mobility controller instead the

11:49actual switches themselves

11:50build tunnels between them so say for example we build a tunnel to this guy

11:54right here this is

11:54known as a vxlan tunnel such as say we've got another server here connecting in

11:59we can then

12:00ride these tunnels and build connections between these devices so the key point

12:03to note here is

12:04that the virtual tunnels are built to a particular point in the network

12:08infrastructure so that

12:09could be safe for example a data center if that's where you're going to be

12:12connecting to perhaps

12:13maybe it's going to be to a particular switch in the network maybe a course

12:16switch that type of thing

12:18whatever the end pointer is you're trying to reach now basically the whole

12:20point of this

12:22is that all the devices in the same vlan so like say for example a server vlan

12:27they're going to

12:27receive the same type of access within the network the same type of security

12:31within the network

12:33it's based on their vlan membership not their actual user identification so

12:38like you say this

12:38happens to be a lot simpler because well it's not quite so fine and granular it

12:42's just based on the

12:43device type connecting to the network whereas the first type is actually based

12:47on the particular

12:48user connecting into the network and the network is going to adapt to that

12:51particular user so pretty

12:53much you could use user-based tunneling for particular members of staff such as

12:57people who belong to

12:58the marketing departments or people who happen to be guests on the network and

13:02then you could use

13:03virtual network based tunneling for devices of a particular type such as your

13:08CCTV cameras or

13:09your printers or your servers that type of thing pretty much the whole point of

13:12this though is

13:13whatever one you happen to implement there is a dynamic nature to the network

13:16it's not about

13:17switching having static configurations on particular physical parts of the

13:21network instead as we can

13:22see here the network is much more fluid and dynamic and it can adapt to the

13:26type of access

13:27controller policies the type of QOS policies the type of vlan information IP

13:31address assignments

13:32all of that can fluctuate depending on who connects to the network or which

13:36device type

13:37connects to the network and that can be authenticated via aruba clear pass and

13:41like I say all of this

13:42simplified management and flexible magic is all made available and possible

13:47through aruba's AOS CX.

0:00Our reference here is the validation challenge.

0:02Imagine you are the network administrator for a company that has recently

0:07bought new

0:08Aruba CX 6100 and CX8400 switches.

0:13The first thing I want you to do is to identify the operating system that will

0:17be running on

0:18each of these devices respectively and then determine which of the switches

0:22would you

0:22use for the access layer of your network.

0:25To understand that, consider that your team want to central enforce policies

0:29based on

0:30the 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

0:37authenticate

0:38in the scenario and assign the correct roles and policies.

0:42And then finally what I want you to do is to identify which tunneling method

0:45would be used

0:46in this particular scenario.

0:48So friends, go give it a go and I will see you in the very next video where we

0:51discuss

0:00Alright friends, so let's talk about the answer then.

0:02So we are the network admin for a company that has recently bought new aruba

0:07switches.

0:07We have the CX6100 and CX8400 switches.

0:12So the first thing we've got to do is identify which operating system that will

0:16be running on each of these devices respectively.

0:18So straight away we've got two different switches.

0:20This one is a more expensive switch.

0:23This one is a little bit cheaper.

0:24Which operating system will we be seeing on this one as well as this one?

0:29Well if you remember the thing that I really wanted to stress is the

0:32independent of these lower entry level switches such as the 6100

0:36and the higher level switches such as 8400 or the 10,000 series,

0:41they are all going to be running the same operating system.

0:44That is AOS CX.

0:46So really really important to remember that the main differentiator is just the

0:50speeds at which these particular switches can operate.

0:52I.e. more ports with greater capacity and the higher end switches are going to

0:57have more features.

0:58But as for the operating system, the syntax, all of it is going to be the same.

1:02It's going to be a robot AOS CX.

1:04Alright so next thing is to determine which of the switches would you use for

1:07the access layer.

1:08Well the 6000 series switches are the lower end switches, more designed for the

1:14edge of the network.

1:15And in fact the 6100 series particularly is a very good choice for the access

1:20layer of your network.

1:21Whereas the 8400 series which you could technically put in to the access layer,

1:26it would be kind of wasted at that particular point.

1:28This would be much more of an aggregation or a core layer switch.

1:32Ok so next point here is a team want to centrally enforce policies based on the

1:36identity of users connecting into the network.

1:39Which aruba product could you use to authenticate in the scenario and assign

1:43the correct roles and policies?

1:45Well in this case here we can use aruba clear pass.

1:48Remember when we talked about dynamic segmentation,

1:51we mentioned that aruba clear pass kind of acts like a radius style server.

1:55It's going to allow users to connect in to the network via colourless ports.

1:59I.e ports are not actually configured with particular policies or

2:02configurations.

2:03We just connect them, the switch can then authenticate with clear pass,

2:07and clear pass can decide is this user authenticated and which roles should

2:11they actually have.

2:13And now finally in the scenario whereby we're using clear pass for user based

2:17authentication.

2:18We want to identify which tunneling method is going to be used in this

2:22particular scenario.

2:23Well the tunneling method is going to be UBT this is user based tunneling.

2:28So pretty much when a user connects in that particular switch is going to talk

2:32to clear pass.

2:33Clear pass will determine the roles and policies and from that point the switch

2:37is going to build a tunnel to a central point in the network known as the

2:41mobility controller.

2:42And then the mobility controller can begin giving that particular switch its V

2:46LAN configuration,

2:47its IP address, its quality of service configuration, its ACL configs, all of

2:52that good stuff.

2:53So friends that is us for our validation challenge on aruba.os. CX switching.

2:57I hope this has been informative for you. I'd like to thank you for viewing.