Recently in Networking Category

This post definitely qualifies as a "super-techy-technology-specific" post, so if this doesn't interest you, may I interest you in something more interesting? 

So, we've recently received a ton of iSCSI storage for Project Bubblewrap, the Exchange 2007 implementation and deployment project at the School.  One of the main considerations when moving to iSCSI is that, for all but the most expensive iSCSI products, only 1-Gigabit line-speed is available.  This is in stark contrast to the readily available (albeit more expensive) 4Gps fiber-channel connectivity with more traditional SAN storage.

Cheaper is sort of the operative word when it comes to iSCSI.  Ethernet switches are significantly cheaper.  Ethernet interface cards (also known as Network cards) are cheap.  Ethernet cabling (e.g. copper) is cheaper than optical fiber.  All these things play a hand in iSCSI's tremendous popularity with smaller business.

So, 4Gps default line speed per port with Fiber Channel.  1Gps line speed for Ethernet, with 10Gbps available but astronomically more expensive.  Why can't you just use more than one gigabit networking port and somehow bundle that aggregate throughput?

Enter Link Aggregation, also known as 802.3ad Link Aggregation, which almost all modern managed switches support.

We want to duplicate the 4Gbps line speed of Fiber-Channel (FC) with Ethernet (IP).  You need four ports, four cables (CAT6 or CAT5e if you please), and a little bit of configuration.

NOTE: For all you networking experts out there, bear with me.  I'm learning as I'm going.

First, a couple of things to note.  Link Aggregate Groups, or LAGs, are treated as a separate, single logical link.  So all the settings (like spanning-tree protection from bridge loops and VLANs) are configured for each LAG, independent of the configuration each member port in the LAG.  For example, the LAG can be up and operational, even though the member ports are configured to be shutdown.  Crazy huh?

Because spanning-tree settings are per-LAG, if you are configuring a inter-switch uplink, it's important that you have the appropriate spanning-tree settings configured for your LAG before you bring it online.

So here's the nitty gritty.

From a console or telnet session to the Dell PowerConnect switch:

• console# configure
• console(config-if)# interface range port-channel all
• console(config-if)# shutdown
• console(config-if)# interface range ethernet g(1-4)
• console(config-if)# channel-group 1 mode auto (add those ports to LAG 1 (of 8), and use the LACP protocol to configure the LAG)
• console(config-if)# int range port-channel 1
• console(config-if)# no spanning-tree disable
• console(config-if)# flowcontrol on
• repeat the above on the partner switch and it's LAG ports
• console(config-if)# no shutdown

In plain-spoken English:

• Enter configuration mode
• Select all port-channel interfaces; remember, a LAG is treated as a logical port, hence the "interface" command
• Just to protect yourself from bringing down a switch or subnet, make sure the LAG is off before configuring.  Not that this happened to me before or anything...definitely not twice,either.
• Select the ports that you are going to use in the LAG
• Add those ports to LAG 1, of the 8 available, and use the LACP protocol to configure the LAG (auto)
• Choose the port-channel interface you just created
• Enable spanning-tree
• Enable Flow Control, which is a specific iSCSI recommendation
• This is already in English so no translation necessary
• The port-channel 1 interface is still the active interface, so just bring up the LAG.

There you have it.  4Gbps uplink between the two switches!  The legwork for this particular implementation sort of opens up the door for other networking bandwidth aggregation options, especially because as we get into really dense blade-based servers and Virtual Machine infrastructures.  The next step is to try and configure a LAG or NIC-team from the actual servers themselves up to the switches, but one thing at a time, people!