Now we're going to dive into a discussion on VSS and StackWise.
So what is VSS and what is StackWise?
Well, let's start off with VSS and its newer next-gen version called StackWise Virtual.
And then we'll talk about StackWise after.
So StackWise Virtual and StackWise are different things, okay?
So you've got to be clear about that for the certification exam.
But VSS and StackWise Virtual are essentially the exact same thing.
So VSS stands for Virtual Switching System.
It's a technology that was developed by Cisco.
And the goal of it is to combine together two physical Cisco catalyst switches into
a single logical network entity.
So these two devices being combined together.
These two devices being combined together.
That's the point of VSS and StackWise Virtual.
So VSS is supported under 4500s, 6500s, 6800s.
And StackWise Virtual, the next-gen version of VSS, is supported under 9400s, 9500s, 9600
series switches.
So what are we getting with this?
We're getting things like resiliency.
We're getting scalability.
But more importantly, we're getting what we call simplified network management.
Because instead of having to manage both of these switches individually, I can now manage
them as a combined entity.
So when I perform my configurations, I am going to be doing it on a single device.
And that information is going to be synchronized to the other device.
And regardless of which one is up and running at the moment in time, meaning active versus
standby, it doesn't matter.
We have a single management IP address that I can utilize to manage this now grouping
of switches that we have.
So VSS, StackWise Virtual, increases operational efficiency by simplifying the network and
reducing switch management overhead.
And so we have a single configuration file, a single node to manage.
So now I don't have to configure both switches.
I configure one.
The other one magically gets configured with identical policies, configurations, and so
on and so forth.
So what we end up with here is we end up with an active, standby, control plane, and management
plane situation.
But we end up with an active, active data plane situation.
So we have our two chassis.
They are acting as one.
But in order to ensure they're acting as one, what do we need?
We need to share that control information.
We need to share that management information.
And that's where the virtual switch link comes into play.
The VSL.
So the VSL is a special link that carries control traffic and management traffic between
the two chassis that are in the VSS or in the StackWise Virtual.
It is going to be an ether channel bundle.
So minimum two links, maximum eight links, preferably 10 gig links.
So anywhere from two to eight 10 gig links that are combined together in an ether channel
bundle.
And, I have to tell you this, just in case it shows up in your future, the switches don't
actually have to be geographically close to each other for this to work.
That's right.
These switches can be geographically separated.
What does that mean?
It means as long as you can run the cable, extend the cable, the signal through various
layer one slash layer two devices, you can have these switches far apart from each other.
Not something that most of us are commonly going to do, but hey, it is something you
can do and something that I need to share with you.
That it is something you can do if you ever need to.
All right.
So pay attention here as to what's going on.
You can see here that we have an active control plane, an active management plane.
Over here, standby control plane, standby management plane.
So when I am managing the devices, when the control traffic is being calculated, spanning
tree protocol doing its job, or dynamic routing protocols doing their jobs, and so on and
so forth, it's this device because it's the active one that's doing all the work.
And this device is going to learn about that.
So we have a centralized control plane, a centralized management plane.
That's what we have here.
But take a peek at the data plane.
You see how both of them are active for the data plane?
Both of them can forward traffic based on what they've learned from the control plane.
So although the control plane is centralized to one device and synchronized to the other
device, the data plane is the responsibility of the individual entities.
So I have what is called a distributed data plane in this particular case.
So both devices are going to be responsible for forwarding frames, forwarding packets,
but only one of them is responsible for the control and management information.
So between these devices on that virtual switch link, we have the link management protocol
running, the LMP.
So LMP is a link management protocol that runs on the virtual switch link between the
active and standby devices.
So it is responsible for what?
Exchanging information required to establish communication between the two chassis.
So what can it do?
It can verify link integrity by establishing bi-directional traffic forwarding.
And ultimately, in the end, reject any unidirectional links that exist.
Why?
Because we need bi-directional communication in this case.
So any unidirectional links are going to be what?
Rejected and not utilized.
It's going to exchange periodic hellos.
So LMP is exchanging those periodic hellos over that VSL to monitor and maintain the
health of those links.
And then it even has the ability to negotiate the version of stack-wise virtual headers
that are going to be used between the switches in the actual switch stack.
So LMP, a very important protocol running on VSL, the virtual switch link, in order
to make all of this magic happen for us.
So before VSS, before stack-wise virtual, what do we have?
Two independent physical devices.
But with VSS and stack-wise virtual, what do we get?
We now get a logical single entity.
And so because it's a logical single entity, how do these devices see those switches now?
So instead of seeing two independent physical devices, they're actually seeing one logical
device.
And this is really important.
Why is that?
Because right now you can see that each switch is connected to each physical device in the
distribution layer.
And spanning tree protocol is not going to allow us to use all of those links.
In addition, what else?
We cannot ether channel bundle those together because they are two different distribution
layer switches.
I can't do that.
But once you combine those together logically at the distribution layer, this all changes.
Now even though I have these two links going to two different devices, once you logically
combine them together, I can bundle those links together now.
So my access switch connects to both chassis of the VSS using one logical port channel
now.
And VSS is going to be managing what?
The redundancy, the load bouncing on the port channel, and even ensure that we have a loop
free layer two network topology.
So this is what?
Improving everything, right?
It's improving our uplink speed.
It's improving our uplink resiliency now.
And we can use both of those links.
It's great.
So can I have four links going from this switch to one of them, four links from this switch
going to the other one, and then bundle them together as eight links in my ether channel
bundle?
Sure.
Absolutely.
Right?
And that's layer two.
Let's not forget about layer three though.
Because remember, in layer three, we're using routed ports up here.
So before you think about what we had, we had this physical device, this physical device
connecting to the physical devices in the core.
But now when we combine those together as a logical entity, that appears as one layer
three device, therefore using one neighborship for something like OSPF or EIGRP.
So now instead of having a peering to each individual device, so instead of having a
peering here and a peering here, you just have a peering to one device now.
And with ether channel bundles, we now have that uplink.
But wait, we can take this further.
Why can we take this further?
We can take this further because if we do the same thing in the core now with VSS and
Stackwise Virtual, we simplify the layer three network topology.
Because now what do we have?
We just have a single routing peer between here and a single routing peer between here.
Even though there's four physical devices, it's one peering, and we can do ether channel
bundle on all of those links now, up to eight.
So that is VSS and Stackwise Virtual to get you ready for the on-core certification exam.
But now let's talk about just purely Stackwise.
So Stackwise is for where?
Stackwise is for here.
So Stackwise Virtual is for here and here, VSS is for here and here, pure just Stackwise
is for here.
And what does that allow us to do?
It allows us to stack those access layer switches on top of each other.
Now some of you might actually be using these types of switches, better versions of them,
at your distribution layer.
And if you are, then you could use Stackwise there to combine them together as a single
logical entity instead of individual physical devices.
So if you don't have at your distribution layer devices that support VSS or Stackwise
Virtual, but they support Stackwise, then you could do Stackwise as a distribution layer.
But what's happening here?
It's allowing us to stack up to eight switches.
So remember, VSS and Stackwise Virtual is what?
Two devices.
Stackwise is eight devices.
Now some of you may be like, whoa, wait a second.
I have some older devices at the access layer and I can do nine.
Yeah, I know.
I know.
I know where you're going with that.
So the problem is that over time, we've had different numbers, different options available
to us.
So let's focus on newer Catalyst switches, like the Catalyst 9300 series that we might
be using at our access layer.
In this case, the rules are eight switches.
Eight switches.
And when we combine together those eight switches, we can get up to, depending on the switch
models and stuff like that, as part of that 9300 series family, we get one terabyte throughput
or 480 gig throughput or 320 gig throughput with our stack bandwidth.
So we have the opportunity now to have up to eight switches stacked together and control
them as a single entity.
So you can think of it as building like a virtual modular switch.
We are going to have one single control plane now for all eight devices, but all eight devices
are like line cards that can continue to forward through their data ports.
So this is really expanding our form factor.
It's increasing our switching capabilities.
It's giving us a higher port density.
It's providing redundancy, as well as providing a single control plane and a distributed data
plane.
So resiliency, scalability, centralized management, these are all buzzwords that I want you to
remember.
So how is this going to happen for us?
How do we go from having individual single devices where we have to manage them independently
to having something that we can manage as a group, a single control plane with a distributed
data plane?
That is where our stacking ports and our stacking cables come into play.
So any switch that supports Stackwise is going to have stack ports on it for this purpose,
and you're going to have to get stack cables to go along with it.
So in this particular case, you can see that we have a stack port and cable going from
the top device to the bottom device, and then notice how we're just connecting them up.
And this is how you would do it.
So we have eight devices, top connects all the way down to the bottom, and you up and
up and up and up and up and up and up and up, and there you go.
It's that easy to cable them together.
And so depending on the model of switches you have, anywhere, like I said, from one
terabyte throughput with our 9300 series, you get 480 gigs depending on the models,
and all the way down to 320 gigs of throughput.
And so something to realize is that in order to get that full throughput, you need to have
all of them cabled together perfectly.
If, for example, one of the cables gets disconnected or you end up with a broken cable, a cut cable,
hopefully not, but let's say it happens, then your bandwidth gets cut in half.
So if your entire stack supported one terabyte throughput, and then all of a sudden one of
the cables was disconnected or broken or the port failed or whatever happened, then now
you're half of that.
If you were 480, then you're half of that.
If you're 320, then you're half of that if you lose one of those particular cables.
So in the end, logically, what are we getting in this particular case?
Logically we're getting this result here where we have a ring topology.
And in this ring topology of eight switches in this particular example, we are going to
have to elect an active switch.
We are going to have to have a standby switch, and then everybody else is going to be members
in that particular stack.
So how do we elect the active switch, and when is the active switch elected?
It's going to be elected during the boot-up process.
That's when the election happens.
So during the boot-up process, all switches are going to go through an election, and as
a result of that, they have approximately two minutes, 120 seconds to decide during
that boot-up process who is going to be active.
And it's based on what?
A priority number, which all of them have as one by default, so the default priority
is one.
I'm going to write that down for you.
Higher is better, so higher is better, but if they all have a priority of one, then what
breaks that tie?
Lowest MAC address is used to break the tie.
Now what type of MAC address?
We're talking about the chassis MAC address, the base Ethernet MAC address of the chassis.
Just like with spanning tree protocol, remember when we were electing the root bridge?
How do we do that?
We said, well, it's going to be based on a priority number, and if that priority number
is tied, we break the tie based on the lowest MAC address, which is the base Ethernet MAC
address of the chassis that you can verify with the output of what?
Show version.
So same idea here, except our priority is one by default instead of, what, 32,768 like
it is with spanning tree protocol.
So priority one, lowest MAC address.
So by default, it's the lowest MAC address that ultimately determines who is going to
be the active device.
So once that is figured out by default, then we end up with our active device.
Now once the device that is chosen to be active is figured out, then all the other
switches just join the stack as stack members, and once all the switches in the stack are
discovered as members, then the active switch elects the standby switch at that particular
point in time.
Essentially, it's going to be the one with, what, the next highest priority, the next
lowest MAC address, so on and so forth when it's all said and done.
So any switch that is not active, that is not standby, is just going to be a member
of that particular stack.
Now you, and it's highly encouraged, should be setting up a deterministic system when
it comes to who the active device is.
What does that mean?
It simply means you control who the active device is.
That's better.
So it's recommended that you do that.
So how are you going to do that?
Adjust the switch priority of your stack switches.
So whoever you want to be active, give it the highest priority.
Don't rely on the MAC address to figure things out.
So give it the highest priority, standby, give it the next highest priority, and then
your members, you can just leave them as one if you want to.
Remember, higher is better in this particular case.
Spanning tree protocol, lower is better.
So stack-wise, higher is better.
So leave, you can leave all the members as one, but then put the standby as the next
highest and active as the highest possible value that you want.
So now it's deterministic.
You know who's going to be active.
You know who's going to be standby.
You know who the members are.
But always remember this, whenever you change the priority for this election process, you
are going to have to reboot.
That's what you're going to have to do.
So none of these changes are going to take effect until what?
Until you reload your switches in order for that election to then take place in order
for the active device with the highest priority to elect itself as that active device and
then become the control plane of everybody else.
So the active device is the control plane.
And so there's going to be a single management IP address that you're setting up as well.
And whoever is active, so if the active fails and the standby becomes active, it's still
the same IP address.
So you don't have to worry about changing IP addresses or anything like that.
Any changes you make on the active gets synchronized to all the members in the standby in the stack.
So all of that magically happens for you.
So when you configure now this stack, you're configuring it from a single management IP
address entity.
And it doesn't matter who the active device is.
It's going to be using that particular IP address.
So all changes you make get synchronized to all the members in the stack so they understand
what the topology is supposed to be, how they are supposed to behave.
Remember, the active device is the brains.
That's what it is.
So it would be no different than you having something like a system with redundant supervisor
modules in it, as an example.
So if you had redundant supervisor modules in it, one's active, one's standby.
The standby supervisor module is synchronized to the active.
Same idea here.
Active is the brains in this case.
The standby is the backup brains.
And all the members still have to learn, but they don't make any decisions at all.
So awesome, awesome, awesome solution to have.
Because now, instead of having all these individual switches all acting independently, they can
act as a cohesive group instead.
So now, the before picture, they're all individual, right?
So look at this.
We have each channel bundle going from here to here, going from here to here, going from
here to here, going from here to here.
But if we stack now these together, could we not combine them all together?
Could we not combine?
Of course we could, right?
So think about this.
You have one link going to one switch, the other link going to the other switch.
One link going to one, one link going to the other.
So every single one of these switches has two uplinks, that's it.
But each one is going to a different distribution switch, which is logically combined together.
Well, now if we combine all of these together, and we have a single active device for the
control plane, then that means all of these are seeing everything the exact same way as
well.
And these devices see these devices as a single entity, as opposed to individual entities.
So now you end up with something like this.
And that's the power of using VSS, Stackwise Virtual, and Stackwise in your environment.
Do we even need to run Spanning Tree Protocol now?
Well, it's going to be running, obviously, but in the end, there is no loop.
That's right, there is no loop.
And because there is no loop, we can use all of our links.
And why is there no loop?
Because these technologies are ensuring that we are not having a loop between all of these
devices.
Why?
Because of the specialized stacking cables.
Why?
Because of our VSL links.
So because of these new features that are running, and these new technologies that are
running, right, those are not necessarily Ethernet connections.
As a result of that, we wouldn't be having a loop, especially with those stacking cables.
So that's why we're able to get away with this.
It's because of how the technology has been implemented.
We can go ahead and we can do our stacks, single point of entity, all the switches see
the network the same way, so they all understand what is appropriate forwarding versus not
appropriate forwarding from the same perspective, bundle all our links together, everything's
just beautiful.
So for the exam, what do you want to know?
You want to understand what VSS is, you want to understand what stack-wise virtual is,
you want to understand the fact that we have centralized control planes, distributed data
planes, make sure you know VSL, make sure you know LMP, and then when we get to actual
stack-wise discussion, as we said, eight switches, you've got your active device, that's your
control plane, so centralized control plane, distributed data plane, those are the things
you want to take away to make sure that you can answer the fundamental questions that
will be presented to you for VSS stack-wise virtual and stack-wise.
Now that I'm at the end of this discussion, if you look at the exam objectives as of right
now when I recorded this video, it's not listed in the exam objectives at all, it's not.
So you might be saying, well, wait a second, why are you covering it, Raymond?
Well, don't forget, I build my courses based on what, exam objectives and exam experience.
So I've added this discussion in here, I've tailored it specifically to help you be successful
in the exam in case it comes up.
So don't overlook this discussion because if you do get a question or two on the exam,
at least you'll be able to get them right.