Hello and welcome back to this series on network reliability. In the previous article, we examined switched network designs and how they impact redundancy. We looked at active standby redundancy in switches using the spanning tree protocol. We also examined active/active redundancy in Layer 2 networks using the Per-VLAN spanning tree protocol and multiple spanning tree protocol. You can view the first article here.
In this article, we will continue examining Layer 2 reliability technologies. We will start with link aggregation mechanisms and we will then consider switch stacking technologies and how they affect the redundancy and the reliability of a network. So let’s get started.
We already know that we can use the spanning tree protocol to manage redundant links in a Layer 2 network. However, spanning tree protocol is typically an active/standby redundancy protocol, so we have to deal with a lot of unused links on the network. And even in cases where we have multiple instances of spanning trees on a single network, ports have to stay as standby for one instance and stay active in another instance. Remember our example from the previous article;
So, can we keep multiple ports in forwarding mode for a single spanning tree protocol instance? Well, not if they stay as multiple ports. The solution is to bundle multiple ports together to form a single logical port; that is the concept of link aggregation.
What is the benefit of link aggregation? With link aggregation, two or more physical ports work as a single logical link and this means that we no longer have to block one of the ports! If we bundle the two ports connecting the aggregation switches in the diagram above, the resulting topology would be:
In the diagram above, the links between the root bridges are always in the forwarding mode; this allows traffic for both instances (VLANs) to be passed across both links at the same time.
How does this work? Basically, you can select ports on a switch and configure them as members of one logical bundle. Once ports are configured to be members of a bundle, the corresponding end on the other switch must have a similar configuration for the bundle to work. There are a couple of things to consider when setting up link aggregation:
The physical properties of all the physical link members must match: Physical properties include speed, duplex settings etc.
The configuration on the physical ports must match: VLAN and other port configurations must be identical.
The link aggregation protocol should be the same at both ends.
Different equipment vendors have their own unique implementations of link aggregation. In fact, the concept of link bundling is given different names by different vendors. In Cisco, it is called etherchannel. Cisco’s proprietary port aggregation protocol was developed in 1994 and it is still in use today. For a more vendor-neutral solution, the IEEE developed the Link Aggregation Control Protocol (802.1AD) in 2000, and this has been implemented by most switch vendors. The IEEE 802.1AD was revised to IEEE 802.1AX in 2008. You can read more about it here: http://www.ieee802.org/1/pages/802.1AX-rev.html
For more details on how to configure link aggregation on Cisco routers, you should read this article (http://resources.intenseschool.com/ccna-prep-etherchannel-implementation-and-optimization/) in our CCNA series. A sample configuration for configuring etherchannels on Cisco switches is shown below:
AGG_Swith1 (config)# interface range Gigabitethernet0/1 -2
AGG_Swith1 (config-if-range)# switchport mode access
AGG_Swith1 (config-if-range)# switchport access vlan 10
AGG_Swith1 (config-if-range)# channel-group 1 mode desirable
Similarly, on the second aggregation switch, the configuration would be:
AGG_Swith2 (config)# interface range Gigabitethernet0/1 -2
AGG_Swith2 (config-if-range)# switchport mode access
AGG_Swith2 (config-if-range)# switchport access vlan 10
AGG_Swith2 (config-if-range)# channel-group 1 mode desirable
This configuration creates a new logical interface called a port channel. The individual interfaces are now members of this new port channel. Further configuration changes from this point should be made directly to the port channel. To verify the states of the etherchannel, you can use the “show etherchannel summary” CLI command.
Before we move on from link aggregation, I’d like to point out that link aggregation is a very useful way to provide redundancy in servers. You can connect multiple links between servers and switches and bundle these links for increased capacity and redundancy. This way, you can have active/active redundancy in servers, too.
Okay, so we’ve seen how we can bundle links together so they can act as a single logical link. Now let us take it a step further. Using the same logic, is it possible to bundle two or more switches so that they can act as a single logical switch? An interesting way to achieve this is via switch stacking.
In switches that support stacking, we can connect switches together so that they act as a single logical device. The diagram below shows an example of Cisco switches that are connected together using special stacking cables.
In this scenario, a switch is selected as the master and the management of the entire stack is done through that master. The switch stack will share one management IP address and usually have one general configuration file, which is replicated among the switches. If a member of the stack fails, the remaining switches can still continue functioning together in the stack. While there is no clear standard for the stacking technology, many vendors have their own implementation of switch stacking and many Cisco switches (like the 3750s above) support some stacking (or a similar technology).
So how does this affect active/active redundancy in switches? When switches are stacked , they act as a single switch and this means we do not have to choose a root bridge anymore, they can now become the root bridge at the same time! Awesome, right? In our topology, when we stack the switches together, our new topology becomes like this:
Now we have a single aggregation switch (from a logical perspective) that is acting as the root bridge and each of the access switches has dual connections to the root bridge. However, we can still see that one of the uplink ports on each switch is being blocked. Again, this is due to STP. With the spanning tree protocol, ports that are not root or designated ports are put in blocking mode to prevent loops.
What can we do to further optimize the network? Since we have dual connections to the same (logical) switch, we can use link aggregation technologies to bundle this ports together into a single logical port. In Cisco switches, this is called cross-stack etherchannels and you can use the LACP protocol for this. Basically, the configuration is the same as regular etherchannels except that, in this case, we will be using LACP.
Access_Swith (config)# interface range Gigabitethernet0/1 -2
Access_Swith (config-if-range)# switchport mode access
Access_Swith (config-if-range)# switchport access vlan 10
Access_Swith (config-if-range)# channel-group 1 mode active
With this new configuration, the network topology will look like this:
Now all the blocked links are gone! In fact, from a logical standpoint, we now have single links from each access switch connecting a single access switch. If we simplify the diagram from a logical perspective, we would have exactly the same diagram that we started with at the beginning of the last article.
By carefully applying network redundancy technologies, we have been able to improve the reliability of the network without changing the basic topology of the network. Nice!
This article concludes Layer 2 redundancy. In the last two articles, we explored various redundancy technologies that operate in the datalink layer of the OSI model. We started with a simple basic network and how we can make it more reliable by adding more links and switches to the network. We then considered the impact of spanning tree in blocking loops and how this impacts the utilization of the links on the network. We also considered active redundancy by running multiple instances of spanning tree, using either the Per-VLAN spanning tree protocol or the multiple spanning tree protocol.
On a more advanced note, we explored how we can consolidate active/active redundancy using link aggregation and switch stacking. And, with this, we have gone full circle and come back to a more reliable version of the network that we started with in the first place.
I hope you enjoyed reading these articles; I certainly enjoyed writing them. In the next article, we will start exploring Layer 3 reliability and see what redundancy technologies we can employ to make our networks more reliable beyond a single broadcast domain. As usual, if you have any comments or questions, feel free to use the comments section to share your thoughts. And if you have any suggestions about topics that you would like to read (and discuss) about, just drop a line in the comments section.
Thank you for reading and I look forward to sharing the next article with you soon. Until then, keep building reliable networks!