WEBVTT 00:00:00.000 --> 00:00:09.680 Now we're going to dive into a discussion on VSS and StackWise. 00:00:09.680 --> 00:00:12.760 So what is VSS and what is StackWise? 00:00:12.760 --> 00:00:21.040 Well, let's start off with VSS and its newer next-gen version called StackWise Virtual. 00:00:21.040 --> 00:00:23.280 And then we'll talk about StackWise after. 00:00:23.280 --> 00:00:27.040 So StackWise Virtual and StackWise are different things, okay? 00:00:27.040 --> 00:00:31.240 So you've got to be clear about that for the certification exam. 00:00:31.240 --> 00:00:34.920 But VSS and StackWise Virtual are essentially the exact same thing. 00:00:34.920 --> 00:00:39.560 So VSS stands for Virtual Switching System. 00:00:39.560 --> 00:00:42.500 It's a technology that was developed by Cisco. 00:00:42.500 --> 00:00:51.880 And the goal of it is to combine together two physical Cisco catalyst switches into 00:00:51.880 --> 00:00:56.340 a single logical network entity. 00:00:56.340 --> 00:01:02.740 So these two devices being combined together. 00:01:02.740 --> 00:01:06.540 These two devices being combined together. 00:01:06.540 --> 00:01:11.660 That's the point of VSS and StackWise Virtual. 00:01:11.660 --> 00:01:17.380 So VSS is supported under 4500s, 6500s, 6800s. 00:01:17.380 --> 00:01:25.060 And StackWise Virtual, the next-gen version of VSS, is supported under 9400s, 9500s, 9600 00:01:25.060 --> 00:01:27.740 series switches. 00:01:27.740 --> 00:01:28.980 So what are we getting with this? 00:01:28.980 --> 00:01:31.020 We're getting things like resiliency. 00:01:31.020 --> 00:01:32.740 We're getting scalability. 00:01:32.740 --> 00:01:37.820 But more importantly, we're getting what we call simplified network management. 00:01:37.820 --> 00:01:46.700 Because instead of having to manage both of these switches individually, I can now manage 00:01:46.700 --> 00:01:50.740 them as a combined entity. 00:01:50.740 --> 00:01:58.820 So when I perform my configurations, I am going to be doing it on a single device. 00:01:58.820 --> 00:02:04.260 And that information is going to be synchronized to the other device. 00:02:04.260 --> 00:02:09.580 And regardless of which one is up and running at the moment in time, meaning active versus 00:02:09.580 --> 00:02:11.780 standby, it doesn't matter. 00:02:11.780 --> 00:02:18.780 We have a single management IP address that I can utilize to manage this now grouping 00:02:18.780 --> 00:02:22.660 of switches that we have. 00:02:22.660 --> 00:02:32.940 So VSS, StackWise Virtual, increases operational efficiency by simplifying the network and 00:02:32.940 --> 00:02:37.820 reducing switch management overhead. 00:02:37.820 --> 00:02:46.900 And so we have a single configuration file, a single node to manage. 00:02:47.020 --> 00:02:50.660 So now I don't have to configure both switches. 00:02:50.660 --> 00:02:52.340 I configure one. 00:02:52.340 --> 00:02:59.060 The other one magically gets configured with identical policies, configurations, and so 00:02:59.060 --> 00:03:02.980 on and so forth. 00:03:02.980 --> 00:03:11.740 So what we end up with here is we end up with an active, standby, control plane, and management 00:03:11.740 --> 00:03:14.220 plane situation. 00:03:14.340 --> 00:03:19.620 But we end up with an active, active data plane situation. 00:03:19.620 --> 00:03:22.420 So we have our two chassis. 00:03:22.420 --> 00:03:28.580 They are acting as one. 00:03:28.580 --> 00:03:33.900 But in order to ensure they're acting as one, what do we need? 00:03:33.900 --> 00:03:36.300 We need to share that control information. 00:03:36.300 --> 00:03:38.980 We need to share that management information. 00:03:38.980 --> 00:03:44.060 And that's where the virtual switch link comes into play. 00:03:44.060 --> 00:03:45.060 The VSL. 00:03:45.060 --> 00:03:53.460 So the VSL is a special link that carries control traffic and management traffic between 00:03:53.460 --> 00:04:02.980 the two chassis that are in the VSS or in the StackWise Virtual. 00:04:02.980 --> 00:04:07.660 It is going to be an ether channel bundle. 00:04:07.660 --> 00:04:18.360 So minimum two links, maximum eight links, preferably 10 gig links. 00:04:18.360 --> 00:04:24.700 So anywhere from two to eight 10 gig links that are combined together in an ether channel 00:04:24.700 --> 00:04:25.700 bundle. 00:04:25.700 --> 00:04:32.300 And, I have to tell you this, just in case it shows up in your future, the switches don't 00:04:32.300 --> 00:04:39.340 actually have to be geographically close to each other for this to work. 00:04:39.340 --> 00:04:40.980 That's right. 00:04:40.980 --> 00:04:45.260 These switches can be geographically separated. 00:04:45.260 --> 00:04:46.260 What does that mean? 00:04:46.260 --> 00:04:53.660 It means as long as you can run the cable, extend the cable, the signal through various 00:04:53.660 --> 00:05:03.700 layer one slash layer two devices, you can have these switches far apart from each other. 00:05:03.700 --> 00:05:07.820 Not something that most of us are commonly going to do, but hey, it is something you 00:05:07.820 --> 00:05:11.980 can do and something that I need to share with you. 00:05:11.980 --> 00:05:15.100 That it is something you can do if you ever need to. 00:05:15.100 --> 00:05:16.100 All right. 00:05:16.100 --> 00:05:18.620 So pay attention here as to what's going on. 00:05:18.620 --> 00:05:27.500 You can see here that we have an active control plane, an active management plane. 00:05:27.500 --> 00:05:32.900 Over here, standby control plane, standby management plane. 00:05:32.900 --> 00:05:40.900 So when I am managing the devices, when the control traffic is being calculated, spanning 00:05:40.900 --> 00:05:45.740 tree protocol doing its job, or dynamic routing protocols doing their jobs, and so on and 00:05:45.820 --> 00:05:50.340 so forth, it's this device because it's the active one that's doing all the work. 00:05:50.340 --> 00:05:53.460 And this device is going to learn about that. 00:05:53.460 --> 00:06:01.340 So we have a centralized control plane, a centralized management plane. 00:06:01.340 --> 00:06:03.180 That's what we have here. 00:06:03.180 --> 00:06:06.460 But take a peek at the data plane. 00:06:06.460 --> 00:06:09.680 You see how both of them are active for the data plane? 00:06:09.680 --> 00:06:14.400 Both of them can forward traffic based on what they've learned from the control plane. 00:06:14.400 --> 00:06:18.480 So although the control plane is centralized to one device and synchronized to the other 00:06:18.480 --> 00:06:24.040 device, the data plane is the responsibility of the individual entities. 00:06:24.040 --> 00:06:29.900 So I have what is called a distributed data plane in this particular case. 00:06:29.900 --> 00:06:35.120 So both devices are going to be responsible for forwarding frames, forwarding packets, 00:06:35.120 --> 00:06:40.560 but only one of them is responsible for the control and management information. 00:06:40.560 --> 00:06:48.640 So between these devices on that virtual switch link, we have the link management protocol 00:06:48.640 --> 00:06:50.760 running, the LMP. 00:06:50.760 --> 00:06:56.120 So LMP is a link management protocol that runs on the virtual switch link between the 00:06:56.120 --> 00:07:00.580 active and standby devices. 00:07:00.580 --> 00:07:02.520 So it is responsible for what? 00:07:02.520 --> 00:07:08.460 Exchanging information required to establish communication between the two chassis. 00:07:08.460 --> 00:07:09.460 So what can it do? 00:07:09.460 --> 00:07:18.840 It can verify link integrity by establishing bi-directional traffic forwarding. 00:07:18.840 --> 00:07:24.520 And ultimately, in the end, reject any unidirectional links that exist. 00:07:24.520 --> 00:07:25.520 Why? 00:07:25.520 --> 00:07:30.460 Because we need bi-directional communication in this case. 00:07:30.460 --> 00:07:33.920 So any unidirectional links are going to be what? 00:07:33.920 --> 00:07:36.140 Rejected and not utilized. 00:07:36.140 --> 00:07:39.380 It's going to exchange periodic hellos. 00:07:39.400 --> 00:07:44.800 So LMP is exchanging those periodic hellos over that VSL to monitor and maintain the 00:07:44.800 --> 00:07:47.720 health of those links. 00:07:47.720 --> 00:07:52.520 And then it even has the ability to negotiate the version of stack-wise virtual headers 00:07:52.520 --> 00:07:56.960 that are going to be used between the switches in the actual switch stack. 00:07:56.960 --> 00:08:01.480 So LMP, a very important protocol running on VSL, the virtual switch link, in order 00:08:01.480 --> 00:08:06.480 to make all of this magic happen for us. 00:08:06.500 --> 00:08:12.940 So before VSS, before stack-wise virtual, what do we have? 00:08:12.940 --> 00:08:16.660 Two independent physical devices. 00:08:16.660 --> 00:08:19.260 But with VSS and stack-wise virtual, what do we get? 00:08:19.260 --> 00:08:22.140 We now get a logical single entity. 00:08:22.140 --> 00:08:30.640 And so because it's a logical single entity, how do these devices see those switches now? 00:08:30.660 --> 00:08:38.700 So instead of seeing two independent physical devices, they're actually seeing one logical 00:08:38.700 --> 00:08:40.120 device. 00:08:40.120 --> 00:08:41.760 And this is really important. 00:08:41.760 --> 00:08:43.620 Why is that? 00:08:43.620 --> 00:08:52.620 Because right now you can see that each switch is connected to each physical device in the 00:08:52.620 --> 00:08:56.920 distribution layer. 00:08:56.920 --> 00:09:02.060 And spanning tree protocol is not going to allow us to use all of those links. 00:09:02.060 --> 00:09:04.260 In addition, what else? 00:09:04.260 --> 00:09:10.900 We cannot ether channel bundle those together because they are two different distribution 00:09:10.900 --> 00:09:11.900 layer switches. 00:09:11.900 --> 00:09:13.540 I can't do that. 00:09:13.540 --> 00:09:21.500 But once you combine those together logically at the distribution layer, this all changes. 00:09:21.500 --> 00:09:28.480 Now even though I have these two links going to two different devices, once you logically 00:09:28.480 --> 00:09:34.680 combine them together, I can bundle those links together now. 00:09:34.680 --> 00:09:44.640 So my access switch connects to both chassis of the VSS using one logical port channel 00:09:44.640 --> 00:09:46.880 now. 00:09:46.880 --> 00:09:48.500 And VSS is going to be managing what? 00:09:48.500 --> 00:09:53.700 The redundancy, the load bouncing on the port channel, and even ensure that we have a loop 00:09:53.700 --> 00:09:58.060 free layer two network topology. 00:09:58.060 --> 00:09:59.060 So this is what? 00:09:59.060 --> 00:10:00.060 Improving everything, right? 00:10:00.060 --> 00:10:06.560 It's improving our uplink speed. 00:10:06.560 --> 00:10:11.060 It's improving our uplink resiliency now. 00:10:11.060 --> 00:10:13.260 And we can use both of those links. 00:10:13.260 --> 00:10:15.460 It's great. 00:10:15.460 --> 00:10:21.700 So can I have four links going from this switch to one of them, four links from this switch 00:10:21.700 --> 00:10:26.140 going to the other one, and then bundle them together as eight links in my ether channel 00:10:26.140 --> 00:10:27.140 bundle? 00:10:27.140 --> 00:10:28.140 Sure. 00:10:28.140 --> 00:10:29.140 Absolutely. 00:10:29.140 --> 00:10:30.140 Absolutely. 00:10:30.140 --> 00:10:31.140 Right? 00:10:31.140 --> 00:10:32.140 And that's layer two. 00:10:32.140 --> 00:10:33.140 Let's not forget about layer three though. 00:10:33.140 --> 00:10:37.260 Because remember, in layer three, we're using routed ports up here. 00:10:37.260 --> 00:10:43.960 So before you think about what we had, we had this physical device, this physical device 00:10:43.960 --> 00:10:47.540 connecting to the physical devices in the core. 00:10:47.540 --> 00:10:53.880 But now when we combine those together as a logical entity, that appears as one layer 00:10:53.880 --> 00:11:01.160 three device, therefore using one neighborship for something like OSPF or EIGRP. 00:11:01.160 --> 00:11:07.520 So now instead of having a peering to each individual device, so instead of having a 00:11:07.520 --> 00:11:15.120 peering here and a peering here, you just have a peering to one device now. 00:11:15.120 --> 00:11:19.600 And with ether channel bundles, we now have that uplink. 00:11:19.600 --> 00:11:22.280 But wait, we can take this further. 00:11:22.280 --> 00:11:23.580 Why can we take this further? 00:11:23.580 --> 00:11:28.200 We can take this further because if we do the same thing in the core now with VSS and 00:11:28.200 --> 00:11:33.800 Stackwise Virtual, we simplify the layer three network topology. 00:11:33.800 --> 00:11:34.800 Because now what do we have? 00:11:34.800 --> 00:11:39.600 We just have a single routing peer between here and a single routing peer between here. 00:11:39.600 --> 00:11:44.760 Even though there's four physical devices, it's one peering, and we can do ether channel 00:11:44.760 --> 00:11:51.680 bundle on all of those links now, up to eight. 00:11:51.680 --> 00:11:57.760 So that is VSS and Stackwise Virtual to get you ready for the on-core certification exam. 00:11:57.760 --> 00:12:01.460 But now let's talk about just purely Stackwise. 00:12:01.460 --> 00:12:03.760 So Stackwise is for where? 00:12:03.760 --> 00:12:06.360 Stackwise is for here. 00:12:06.360 --> 00:12:14.300 So Stackwise Virtual is for here and here, VSS is for here and here, pure just Stackwise 00:12:14.300 --> 00:12:16.380 is for here. 00:12:16.380 --> 00:12:17.840 And what does that allow us to do? 00:12:17.840 --> 00:12:24.080 It allows us to stack those access layer switches on top of each other. 00:12:24.080 --> 00:12:30.320 Now some of you might actually be using these types of switches, better versions of them, 00:12:30.320 --> 00:12:31.760 at your distribution layer. 00:12:31.760 --> 00:12:37.780 And if you are, then you could use Stackwise there to combine them together as a single 00:12:37.780 --> 00:12:41.700 logical entity instead of individual physical devices. 00:12:41.700 --> 00:12:46.580 So if you don't have at your distribution layer devices that support VSS or Stackwise 00:12:46.580 --> 00:12:51.900 Virtual, but they support Stackwise, then you could do Stackwise as a distribution layer. 00:12:51.900 --> 00:12:53.900 But what's happening here? 00:12:53.900 --> 00:12:56.300 It's allowing us to stack up to eight switches. 00:12:56.520 --> 00:13:00.400 So remember, VSS and Stackwise Virtual is what? 00:13:00.400 --> 00:13:02.240 Two devices. 00:13:02.240 --> 00:13:05.920 Stackwise is eight devices. 00:13:05.920 --> 00:13:08.600 Now some of you may be like, whoa, wait a second. 00:13:08.600 --> 00:13:12.280 I have some older devices at the access layer and I can do nine. 00:13:12.280 --> 00:13:13.960 Yeah, I know. 00:13:13.960 --> 00:13:15.640 I know. 00:13:15.640 --> 00:13:17.040 I know where you're going with that. 00:13:17.040 --> 00:13:22.920 So the problem is that over time, we've had different numbers, different options available 00:13:22.920 --> 00:13:23.200 to us. 00:13:23.220 --> 00:13:27.620 So let's focus on newer Catalyst switches, like the Catalyst 9300 series that we might 00:13:27.620 --> 00:13:28.860 be using at our access layer. 00:13:28.860 --> 00:13:32.140 In this case, the rules are eight switches. 00:13:32.140 --> 00:13:33.140 Eight switches. 00:13:33.140 --> 00:13:35.980 And when we combine together those eight switches, we can get up to, depending on the switch 00:13:35.980 --> 00:13:41.420 models and stuff like that, as part of that 9300 series family, we get one terabyte throughput 00:13:41.420 --> 00:13:46.520 or 480 gig throughput or 320 gig throughput with our stack bandwidth. 00:13:46.520 --> 00:13:54.300 So we have the opportunity now to have up to eight switches stacked together and control 00:13:54.300 --> 00:13:55.460 them as a single entity. 00:13:55.460 --> 00:14:00.340 So you can think of it as building like a virtual modular switch. 00:14:00.340 --> 00:14:06.300 We are going to have one single control plane now for all eight devices, but all eight devices 00:14:06.300 --> 00:14:11.060 are like line cards that can continue to forward through their data ports. 00:14:11.060 --> 00:14:13.300 So this is really expanding our form factor. 00:14:13.300 --> 00:14:15.620 It's increasing our switching capabilities. 00:14:15.720 --> 00:14:18.240 It's giving us a higher port density. 00:14:18.240 --> 00:14:23.920 It's providing redundancy, as well as providing a single control plane and a distributed data 00:14:23.920 --> 00:14:24.920 plane. 00:14:24.920 --> 00:14:30.200 So resiliency, scalability, centralized management, these are all buzzwords that I want you to 00:14:30.200 --> 00:14:32.120 remember. 00:14:32.120 --> 00:14:37.900 So how is this going to happen for us? 00:14:37.900 --> 00:14:44.320 How do we go from having individual single devices where we have to manage them independently 00:14:44.320 --> 00:14:49.780 to having something that we can manage as a group, a single control plane with a distributed 00:14:49.780 --> 00:14:51.280 data plane? 00:14:51.280 --> 00:14:57.160 That is where our stacking ports and our stacking cables come into play. 00:14:57.160 --> 00:15:05.000 So any switch that supports Stackwise is going to have stack ports on it for this purpose, 00:15:05.000 --> 00:15:08.800 and you're going to have to get stack cables to go along with it. 00:15:08.800 --> 00:15:14.480 So in this particular case, you can see that we have a stack port and cable going from 00:15:14.480 --> 00:15:19.680 the top device to the bottom device, and then notice how we're just connecting them up. 00:15:19.680 --> 00:15:20.960 And this is how you would do it. 00:15:20.960 --> 00:15:25.480 So we have eight devices, top connects all the way down to the bottom, and you up and 00:15:25.480 --> 00:15:28.400 up and up and up and up and up and up and up, and there you go. 00:15:28.400 --> 00:15:31.240 It's that easy to cable them together. 00:15:31.240 --> 00:15:35.560 And so depending on the model of switches you have, anywhere, like I said, from one 00:15:35.560 --> 00:15:41.960 terabyte throughput with our 9300 series, you get 480 gigs depending on the models, 00:15:41.960 --> 00:15:44.720 and all the way down to 320 gigs of throughput. 00:15:44.720 --> 00:15:50.000 And so something to realize is that in order to get that full throughput, you need to have 00:15:50.000 --> 00:15:52.520 all of them cabled together perfectly. 00:15:52.520 --> 00:15:59.840 If, for example, one of the cables gets disconnected or you end up with a broken cable, a cut cable, 00:15:59.840 --> 00:16:03.600 hopefully not, but let's say it happens, then your bandwidth gets cut in half. 00:16:03.640 --> 00:16:07.480 So if your entire stack supported one terabyte throughput, and then all of a sudden one of 00:16:07.480 --> 00:16:12.840 the cables was disconnected or broken or the port failed or whatever happened, then now 00:16:12.840 --> 00:16:13.840 you're half of that. 00:16:13.840 --> 00:16:15.520 If you were 480, then you're half of that. 00:16:15.520 --> 00:16:22.320 If you're 320, then you're half of that if you lose one of those particular cables. 00:16:22.320 --> 00:16:26.080 So in the end, logically, what are we getting in this particular case? 00:16:26.080 --> 00:16:32.520 Logically we're getting this result here where we have a ring topology. 00:16:32.520 --> 00:16:37.400 And in this ring topology of eight switches in this particular example, we are going to 00:16:37.400 --> 00:16:40.080 have to elect an active switch. 00:16:40.080 --> 00:16:44.220 We are going to have to have a standby switch, and then everybody else is going to be members 00:16:44.220 --> 00:16:47.720 in that particular stack. 00:16:47.720 --> 00:16:51.600 So how do we elect the active switch, and when is the active switch elected? 00:16:51.600 --> 00:16:54.840 It's going to be elected during the boot-up process. 00:16:54.840 --> 00:16:56.660 That's when the election happens. 00:16:56.660 --> 00:17:03.420 So during the boot-up process, all switches are going to go through an election, and as 00:17:03.420 --> 00:17:10.340 a result of that, they have approximately two minutes, 120 seconds to decide during 00:17:10.340 --> 00:17:14.460 that boot-up process who is going to be active. 00:17:14.460 --> 00:17:15.460 And it's based on what? 00:17:15.460 --> 00:17:21.040 A priority number, which all of them have as one by default, so the default priority 00:17:21.040 --> 00:17:22.040 is one. 00:17:22.040 --> 00:17:24.580 I'm going to write that down for you. 00:17:25.580 --> 00:17:31.500 Higher is better, so higher is better, but if they all have a priority of one, then what 00:17:31.500 --> 00:17:32.940 breaks that tie? 00:17:32.940 --> 00:17:37.860 Lowest MAC address is used to break the tie. 00:17:37.860 --> 00:17:38.860 Now what type of MAC address? 00:17:38.860 --> 00:17:43.780 We're talking about the chassis MAC address, the base Ethernet MAC address of the chassis. 00:17:43.780 --> 00:17:47.500 Just like with spanning tree protocol, remember when we were electing the root bridge? 00:17:47.500 --> 00:17:48.500 How do we do that? 00:17:48.500 --> 00:17:52.220 We said, well, it's going to be based on a priority number, and if that priority number 00:17:52.220 --> 00:17:56.740 is tied, we break the tie based on the lowest MAC address, which is the base Ethernet MAC 00:17:56.740 --> 00:17:59.260 address of the chassis that you can verify with the output of what? 00:17:59.260 --> 00:18:00.340 Show version. 00:18:00.340 --> 00:18:06.540 So same idea here, except our priority is one by default instead of, what, 32,768 like 00:18:06.540 --> 00:18:07.780 it is with spanning tree protocol. 00:18:07.780 --> 00:18:10.420 So priority one, lowest MAC address. 00:18:10.420 --> 00:18:15.060 So by default, it's the lowest MAC address that ultimately determines who is going to 00:18:15.060 --> 00:18:16.960 be the active device. 00:18:16.960 --> 00:18:20.900 So once that is figured out by default, then we end up with our active device. 00:18:20.900 --> 00:18:28.100 Now once the device that is chosen to be active is figured out, then all the other 00:18:28.100 --> 00:18:33.180 switches just join the stack as stack members, and once all the switches in the stack are 00:18:33.180 --> 00:18:37.820 discovered as members, then the active switch elects the standby switch at that particular 00:18:37.820 --> 00:18:38.820 point in time. 00:18:38.820 --> 00:18:41.700 Essentially, it's going to be the one with, what, the next highest priority, the next 00:18:41.700 --> 00:18:45.140 lowest MAC address, so on and so forth when it's all said and done. 00:18:45.140 --> 00:18:50.380 So any switch that is not active, that is not standby, is just going to be a member 00:18:50.380 --> 00:18:52.540 of that particular stack. 00:18:52.540 --> 00:19:03.260 Now you, and it's highly encouraged, should be setting up a deterministic system when 00:19:03.260 --> 00:19:04.940 it comes to who the active device is. 00:19:04.940 --> 00:19:05.940 What does that mean? 00:19:05.940 --> 00:19:07.860 It simply means you control who the active device is. 00:19:07.860 --> 00:19:08.860 That's better. 00:19:08.860 --> 00:19:09.860 So it's recommended that you do that. 00:19:09.860 --> 00:19:10.860 So how are you going to do that? 00:19:10.860 --> 00:19:13.660 Adjust the switch priority of your stack switches. 00:19:13.660 --> 00:19:16.900 So whoever you want to be active, give it the highest priority. 00:19:16.900 --> 00:19:18.820 Don't rely on the MAC address to figure things out. 00:19:18.820 --> 00:19:22.300 So give it the highest priority, standby, give it the next highest priority, and then 00:19:22.300 --> 00:19:24.860 your members, you can just leave them as one if you want to. 00:19:24.860 --> 00:19:27.740 Remember, higher is better in this particular case. 00:19:27.740 --> 00:19:30.100 Spanning tree protocol, lower is better. 00:19:30.100 --> 00:19:32.300 So stack-wise, higher is better. 00:19:32.300 --> 00:19:36.420 So leave, you can leave all the members as one, but then put the standby as the next 00:19:36.420 --> 00:19:39.800 highest and active as the highest possible value that you want. 00:19:39.800 --> 00:19:41.580 So now it's deterministic. 00:19:41.580 --> 00:19:42.580 You know who's going to be active. 00:19:42.580 --> 00:19:43.580 You know who's going to be standby. 00:19:43.580 --> 00:19:44.780 You know who the members are. 00:19:44.780 --> 00:19:48.540 But always remember this, whenever you change the priority for this election process, you 00:19:49.260 --> 00:19:50.260 are going to have to reboot. 00:19:50.260 --> 00:19:52.180 That's what you're going to have to do. 00:19:52.180 --> 00:19:56.540 So none of these changes are going to take effect until what? 00:19:56.540 --> 00:20:01.820 Until you reload your switches in order for that election to then take place in order 00:20:01.820 --> 00:20:08.940 for the active device with the highest priority to elect itself as that active device and 00:20:08.940 --> 00:20:11.260 then become the control plane of everybody else. 00:20:11.260 --> 00:20:13.740 So the active device is the control plane. 00:20:13.740 --> 00:20:17.540 And so there's going to be a single management IP address that you're setting up as well. 00:20:17.540 --> 00:20:20.660 And whoever is active, so if the active fails and the standby becomes active, it's still 00:20:20.660 --> 00:20:21.660 the same IP address. 00:20:21.660 --> 00:20:24.380 So you don't have to worry about changing IP addresses or anything like that. 00:20:24.380 --> 00:20:28.700 Any changes you make on the active gets synchronized to all the members in the standby in the stack. 00:20:28.700 --> 00:20:30.980 So all of that magically happens for you. 00:20:30.980 --> 00:20:37.620 So when you configure now this stack, you're configuring it from a single management IP 00:20:37.620 --> 00:20:38.620 address entity. 00:20:38.620 --> 00:20:40.220 And it doesn't matter who the active device is. 00:20:40.220 --> 00:20:42.700 It's going to be using that particular IP address. 00:20:42.700 --> 00:20:46.620 So all changes you make get synchronized to all the members in the stack so they understand 00:20:46.700 --> 00:20:50.500 what the topology is supposed to be, how they are supposed to behave. 00:20:50.500 --> 00:20:53.100 Remember, the active device is the brains. 00:20:53.100 --> 00:20:54.100 That's what it is. 00:20:54.100 --> 00:20:59.900 So it would be no different than you having something like a system with redundant supervisor 00:20:59.900 --> 00:21:01.420 modules in it, as an example. 00:21:01.420 --> 00:21:04.860 So if you had redundant supervisor modules in it, one's active, one's standby. 00:21:04.860 --> 00:21:07.380 The standby supervisor module is synchronized to the active. 00:21:07.380 --> 00:21:08.780 Same idea here. 00:21:08.780 --> 00:21:10.220 Active is the brains in this case. 00:21:10.220 --> 00:21:11.700 The standby is the backup brains. 00:21:11.700 --> 00:21:17.740 And all the members still have to learn, but they don't make any decisions at all. 00:21:17.740 --> 00:21:21.140 So awesome, awesome, awesome solution to have. 00:21:21.140 --> 00:21:28.500 Because now, instead of having all these individual switches all acting independently, they can 00:21:28.500 --> 00:21:31.380 act as a cohesive group instead. 00:21:31.380 --> 00:21:35.700 So now, the before picture, they're all individual, right? 00:21:35.700 --> 00:21:36.700 So look at this. 00:21:36.700 --> 00:21:40.300 We have each channel bundle going from here to here, going from here to here, going from 00:21:40.300 --> 00:21:42.220 here to here, going from here to here. 00:21:42.220 --> 00:21:46.980 But if we stack now these together, could we not combine them all together? 00:21:46.980 --> 00:21:47.980 Could we not combine? 00:21:47.980 --> 00:21:48.980 Of course we could, right? 00:21:48.980 --> 00:21:49.980 So think about this. 00:21:49.980 --> 00:21:55.340 You have one link going to one switch, the other link going to the other switch. 00:21:55.340 --> 00:21:57.420 One link going to one, one link going to the other. 00:21:57.420 --> 00:22:01.660 So every single one of these switches has two uplinks, that's it. 00:22:01.660 --> 00:22:07.260 But each one is going to a different distribution switch, which is logically combined together. 00:22:08.220 --> 00:22:16.580 Well, now if we combine all of these together, and we have a single active device for the 00:22:16.580 --> 00:22:21.620 control plane, then that means all of these are seeing everything the exact same way as 00:22:21.620 --> 00:22:22.620 well. 00:22:22.620 --> 00:22:28.940 And these devices see these devices as a single entity, as opposed to individual entities. 00:22:28.940 --> 00:22:35.260 So now you end up with something like this. 00:22:35.260 --> 00:22:43.300 And that's the power of using VSS, Stackwise Virtual, and Stackwise in your environment. 00:22:43.300 --> 00:22:46.180 Do we even need to run Spanning Tree Protocol now? 00:22:46.180 --> 00:22:50.700 Well, it's going to be running, obviously, but in the end, there is no loop. 00:22:50.700 --> 00:22:53.720 That's right, there is no loop. 00:22:53.720 --> 00:22:58.700 And because there is no loop, we can use all of our links. 00:22:58.700 --> 00:22:59.940 And why is there no loop? 00:22:59.940 --> 00:23:08.460 Because these technologies are ensuring that we are not having a loop between all of these 00:23:08.460 --> 00:23:09.460 devices. 00:23:09.460 --> 00:23:10.460 Why? 00:23:10.460 --> 00:23:14.300 Because of the specialized stacking cables. 00:23:14.300 --> 00:23:15.300 Why? 00:23:15.300 --> 00:23:17.140 Because of our VSL links. 00:23:17.140 --> 00:23:23.060 So because of these new features that are running, and these new technologies that are 00:23:23.060 --> 00:23:28.580 running, right, those are not necessarily Ethernet connections. 00:23:28.580 --> 00:23:34.620 As a result of that, we wouldn't be having a loop, especially with those stacking cables. 00:23:34.620 --> 00:23:36.940 So that's why we're able to get away with this. 00:23:36.940 --> 00:23:39.840 It's because of how the technology has been implemented. 00:23:39.840 --> 00:23:43.660 We can go ahead and we can do our stacks, single point of entity, all the switches see 00:23:43.660 --> 00:23:49.860 the network the same way, so they all understand what is appropriate forwarding versus not 00:23:49.860 --> 00:23:53.820 appropriate forwarding from the same perspective, bundle all our links together, everything's 00:23:53.820 --> 00:23:56.980 just beautiful. 00:23:56.980 --> 00:24:00.260 So for the exam, what do you want to know? 00:24:00.260 --> 00:24:04.220 You want to understand what VSS is, you want to understand what stack-wise virtual is, 00:24:04.220 --> 00:24:07.860 you want to understand the fact that we have centralized control planes, distributed data 00:24:07.860 --> 00:24:13.900 planes, make sure you know VSL, make sure you know LMP, and then when we get to actual 00:24:13.900 --> 00:24:20.140 stack-wise discussion, as we said, eight switches, you've got your active device, that's your 00:24:20.140 --> 00:24:24.880 control plane, so centralized control plane, distributed data plane, those are the things 00:24:24.880 --> 00:24:29.360 you want to take away to make sure that you can answer the fundamental questions that 00:24:29.360 --> 00:24:33.200 will be presented to you for VSS stack-wise virtual and stack-wise. 00:24:33.200 --> 00:24:39.480 Now that I'm at the end of this discussion, if you look at the exam objectives as of right 00:24:39.480 --> 00:24:49.760 now when I recorded this video, it's not listed in the exam objectives at all, it's not. 00:24:49.760 --> 00:24:52.280 So you might be saying, well, wait a second, why are you covering it, Raymond? 00:24:52.280 --> 00:24:57.160 Well, don't forget, I build my courses based on what, exam objectives and exam experience. 00:24:57.160 --> 00:25:02.680 So I've added this discussion in here, I've tailored it specifically to help you be successful 00:25:02.680 --> 00:25:06.760 in the exam in case it comes up. 00:25:06.760 --> 00:25:11.160 So don't overlook this discussion because if you do get a question or two on the exam, 00:25:11.160 --> 00:25:12.280 at least you'll be able to get them right.