Even if we have redundant links between our switches to increase bandwidth or provide a level of comfort if a link fails, Spanning Tree Protocol will disallow traffic to flow on one of those links because it sees it as a loop. So let's see how we can override this behavior by using ether channel and ultimately allowing us to use both links at the same time while maximizing our bandwidth.
The need for EtherChannel
We know the challenge and that is, spanning tree doesn't like redundancy. Its mission is in fact to remove it and as a result, our parallel links between the switches, they exist, but spanning tree removes them. And look at the case, where the bottom two switches are involved.
It's completely removed from the bandwidth equation and half of the bandwidth across the horizontal link and going up into the left from the bottom, that's removed as well. So we want the ability to augment bandwidth and going faster is an option. But there is another option and that is, figure out a way to marry the fact that spanning tree needs to run in our environment still. With the technology that we're about to show you, that is going to allow us to fix spanning tree out a little bit and essentially give us our cake and allow us to eat it as well.
Advantages of EtherChannel. Load balancing
Focus your attention on the topology. Notice EtherChannel. What are we doing? We're bundling the links together, aggregating them together, improving the bandwidth and the distribution of traffic in our topology. But I really want you to focus on spanning tree protocol's blocked port. Is it just a port it's blocking? No, not in this case, it's blocking the entire EtherChannel bundle. So it sees it as a bundle here of all those physical ports, instead of individual physical ports. So what's our ratio now? Well out of these six links we're using four. It's better than what we originally had, which was only two out of the six we were using.
Now you may be thinking out there, this is dangerous, OK? You might be thinking that this is dangerous because what happens if one of the member links of an EtherChannel bundle goes down? I want to have stability in my network. Well this is one of the most amazing things about EtherChannel: if a member link goes down, the EtherChannel bundle endures. And how many ports can you stick in an EtherChannel bundle? Sixteen. Turns out that only eight can be active at any given time. But let's say, we had eight in an EtherChannel bundle. So you start to think, oh man, I got eight. So the likelihood of one of those eight going down is exponentially larger but if one goes down, no problem. The remaining links stay up and keep the EtherChannel bundle active. So the throughput and connectivity still exists. So the only time an EtherChannel link will go down is when all physical links fail within the bundle.
That makes this not only more attuned to our needs in terms of availability, but it also gives us our bandwidth that we're looking for. So this is so tremendously powerful to the scaling of our network. So if I need to go faster than Fast Ethernet, I could put four Fast Ethernet links together in a bundle or eight. And if I need to go faster than gigabit, maybe I'll bundle a few gigabit and we can even bundle 10 GB links in an EtherChannel bundle. So this is a technology that is used in so many different places. We call it adapter teaming in some places. We don't usually say that for Cisco. Sometimes we see it down to the server but we're going to focus on this technology between our switches.
Let's recall the discussion we had on spanning tree protocol on a VLAN, short for virtual LAN, by VLAN basis. One instance of spanning tree protocol per VLAN. So folks, we can still have VLAN 1 traffic following the path on one EtherChannel bundle, while VLAN 2 traffic is following a different path in a different EtherChannel bundle uplink. So when we look at it from this perspective, yeah, we're blocking that EtherChannel bundle, but it's still, from a spanning tree perspective, on a VLAN by VLAN basis. So think about all the different uplinks you have and then when you manipulate spanning tree protocol, you can use them all, you can use them all in that case. Really a great way for us to improve and increase our bandwidth at a relatively low cost.
There are a few things that you're going to need to take away from this discussion. We're about to share with you one of those two I would say, and that is, the protocols that could dynamically negotiate the bundle. I want you to understand that we don't need these. We don't need either of them. We can go it our own and manually configure an EtherChannel bundle, or we can use a kinder and gentler negotiation approach. And that's where the protocols of PAgP, short for Port Aggregation Protocol, and LACP, short for Link Aggregation Control Protocol, come in to play, or LACP whatever you want to say. PAgP is Cisco's proprietary EtherChannel protocol - Port Aggregation Protocol. But given a standardized approach we often lean towards a standardized approach.
In my mind these are equal, except for the fact that one is standard; one is proprietary. So I don't really see a big difference in terms of behavior and so let's choose LACP, this 802.3ad standard and we are going to teach you how to set up LACP to negotiate our EtherChannel bundles. But it's the configuration options that I need you to know that are going to help you understand the ramifications of our configuration because the configuration will tie back to one of these two protocols, and you need to know exactly how that works.
So PAgP has two modes of operation: Desirable and Auto. Now I know we see On here but I want you to remember that in this mode there is no protocol. If you specify a mode of On, you are not using PAgP, you explicitly are turning on EtherChannel with no protocol. So really we are dealing with Desirable and Auto. Desirable and Auto, we saw those terms earlier. Those are trunking protocols: Desirable, meaning we're actively trying to form that EtherChannel bundle; Auto, meaning we are passively waiting for someone to ask us to form an EtherChannel bundle. So if you look at the different options here: On-On, we will form a bundle. Desirable-Desirable, we will form a bundle. Desirable-Auto, we will form a bundle. And those are the only options. Notice I never said On and Desirable or On and Auto. This is different than our trunks. Our trunks, we can set it to trunk, which was On and we would form a trunk with a Desirable or Auto site, because DTP was still being used. This is the difference, and you can get thrown off by differences like this on any type of exam. In this case, On - no protocol, therefore, both sides have to be On in order to form the EtherChannel bundle.
I can vividly recall crashing some switches, trying to do On on one side and Auto on the other. Because I was thinking that it was like our trunking. It's not and in fact, I crashed them. Because when I moved the far side to On, that side had one port that was previously blocking. When you turn it On, you're activating all ports of the EtherChannel bundle, so you can't have a blocked port in an EtherChannel bundle. So I essentially moved a port to the forwarding state, causing a loop. So you have to be very careful, very, very careful in the real world with this configuration.
So PAgP Cisco proprietary; LACP industry standard, and notice it has modes as well. On means no protocol. So the same discussion of On here would be the same as what we just had with PAgP. You have to be On-On on both sides in order for the bundle to be formed. But notice the difference here now, with the modes for LACP. We have Active. Active meaning actively ask to form the EtherChannel bundle, whereas, Passive passively wait for the other side to ask you to form the bundle.
If I'm going to configure this, I'm probably going to do Active on both sides. I don't like to push these protocols that are negotiation-centric to the extreme: Active on one side and Passive on another. That would work but I would like to have the same configuration. I would like to be able to copy and paste. But so that you understand, if you were ever asked, hey, I want you to configure a standardized EtherChannel bundle and I want this switch to communicate to the other side to form the bundle; that would be a clue for you that you should set that switch to Active and potentially the other switch to Passive to meet the design goals of that configuration.