When I was an impressionable youth back in my college years, I decided it might be a good idea to take Japanese as a foreign language. I spent three semesters learning vocabulary and kanji and eventually managed to forget pretty much everything I learned. One lesson that did stick with me, however, occurred in my first semester. Our professor was explaining to us gaijins (Westerners) that we needed to be very careful about how we pronounced certain words. Since words in Japanese are limited by a very small number of vowel sounds, there are many cases were words use the same sounds but have totally different meanings. Such is the case with shujin. When pronounced as I have written it, it is the word for “husband”. However, if you hold the “u” sound a little too long, as in shuujin, you instead have referred to that person as a “prisoner”. As my professor explained, “Well, perhaps those two words really aren’t so different.” In this case, a small difference in pronunciation can have a profound difference in meaning.
Another place where I see an issue similar to this is when someone starts asking questions about terminology differences between HP Networking (nee Procurve) and Cisco terminology on switches. Often, these questions boil down to two major terminology differences based around one word: trunk. It’s pronounced the same in both vendors world, but just like in Japanese, it can have a very different meaning depending on how it’s used. Allow me to illustrate:
In Ciscoland, when I use the term trunk, I am referring to a port that carries multiple VLANs. Trunk ports carry information about each of the VLANs on the switch in either Cisco’s ISL proprietary format or in the 802.1q vendor-neutral format. Newer switches, like the 2960, have no support for ISL and will only form trunks using 802.1q, so I’ll use 802.1q for my examples. Just keep in mind that if the switch doesn’t support ISL, you don’t need to configure the trunk encapsulation. When these ports are designated as “trunks”, the frames are tagged with a special 802.1q header that indicates which VLAN they are a part of. The only VLAN that is not tagged with an 802.1q header (by default) is the native VLAN. On Cisco equipment, the default native VLAN for an 802.1q trunk is VLAN 1. The behavior of Cisco IOS is to transmit information about all VLANs present on the switch over the trunk. You can narrow this behavior through use of the switchport trunk allowed vlan command. A sample Cisco trunk config might look like this:
Switch(config)#interface gig 0/1 Switch(config-int)#switchport trunk encapsulation dot1q Switch(config-int)#switchport trunk allowed vlan 1,10,99 Switch(config-int)#switchport mode trunk
This configuration is sufficient to setup an 802.1q trunk and only allow VLANs 1, 10, and 99 to pass traffic on it.
In HPvania, the terminology used for a port that carries multiple VLANs is a tagged port. On an HP switch, the individual ports are rarely configured directly. Instead, the VLAN itself is configured and the ports are added to the VLAN configuration. In order to setup an access port, it is configured as an untagged member of the VLAN it needs to belong to. Since HP does not support ISL trunking, the terminology is straight from 802.1q. The untagged ports do not carry 802.1q headers that specify they VLAN information. This would be known as an “access port” on a Cisco switch. In order to create a port that carries information for multiple VLANs, we must “tag” those VLANs on that port. This modifies the packets sent on that port to carry VLAN tags for the VLANs indicated. A sample configuration for an HP switch connected to the above Cisco switch might look like this:
Switch(config)#vlan 1 Switch(config-vlan)#untagged 1 Switch(config-vlan)#untagged 48 Switch(config-vlan)#vlan 10 Switch(config-vlan)#tagged 48 Switch(config-vlan)#vlan 99 Switch(config-vlan)#tagged 48
Notice that the configuration is done under the VLAN and references the port number on the switch. Access ports are untagged members of a particular VLAN, and the native VLAN of an 802.1q trunk is also an untagged member. Even though 802.1q has a native VLAN that doesn’t carry a tag, on an HP switch this VLAN needs to be explicitly set. The other VLANs must be tagged to the uplink port in order for their information to be carried between switches. This lends itself to being an additive solution, where VLANs are only present on a trunk if they have been specifically configured. There is no need to prune VLANs or exclude them from the trunk if they aren’t needed. They just aren’t configured in the first place.
Which method is better? This tends to devolve into an OSPF vs. IS-IS type of argument. If you are more comfortable with one you tend to prefer it. I tend to use the Cisco terminology in my day-to-day operations, and I have a slight preference for not needing to remember to add each individual VLAN to an uplink port. However, from a security perspective, I do like the HP idea of only adding VLANs that are needed. In fact, this same concept of VLAN creation is present in the Force10 OS. If you’d like to see more of it in action, you should check out Stretch’s excellent intro to Force10 over on Packetlife.net.
So, if HP refers to an uplink carrying multiple VLANs are a tagged port, then does HP have a “trunk”? In fact they do. In HPvania, a trunk is a logical construct that aggregates multiple ports into one logical link. For those of you that might be out there scratching your heads about this one, this means that when you “trunk” a group of ports on an HP switch, you are creating one LACP link from up to four individual ports. This kind of configuration should look like this:
Switch(config)#trunk 19-24 Switch(config)#trk1 Switch(config-trk)#lacp Switch(config-trk)#vlan 1 Swtich(config-vlan)#untagged trk1 Swtich(config-vlan)#vlan 10 Swtich(config-vlan)#tagged trk1 Swtich(config-vlan)#vlan 99 Swtich(config-vlan)#tagged trk1
Those of you that are fans of irony will appreciate that the above config sets up this LACP port aggregation to pass multiple VLANs to another switch. In other words, we are configuring a Cisco “trunk” on top of an HP “trunk”.
In Ciscoland, the idea of aggregating multiple ports into a grouping is referred to by many names, usually “port channeling” or “Etherchanneling”. The latter is the term that usually describes the Cisco-proprietary Port Aggregation Protocol (PAgP) links that are created by default. However, this term has more or less become genericized and is used to refer to any group of aggregated ports on a Cisco switch. Cisco does support LACP on aggregated ports, so let’s see how we’d configure this switch to use LACP and send tagged VLAN traffic back to the HP switch:
Switch(config)#interface range gi 0/19-24 Switch(config-int-range)#switchport trunk encapsulation dot1q Switch(config-int-range)#switchport trunk allowed vlan 1,10,99 Switch(config-int-range)#switchport mode trunk Switch(config-int-range)#channel-group 1 mode active Switch(config-int-range)#channel-protocol lacp
This will set the aggregated ports to use LACP and pass VLANs across the link with 802.1q tags. Note that you must set the channel-group command to “active” in order to use LACP on the link. If you set it to “auto” or “desirable”, it will use PagP by default. If you set the mode to “on”, it will not use LACP or PAgP at all.
There you have it. The terminology is different, but as long as you know what you are trying to accomplish, you can usually figure out what you need to configure in order to make it all work correctly. Hopefully you’ll never find yourself married to any particular configuration, much less become a prisoner of it. In the end, just remember that a trunk is still just a trunk. The meaning is entirely up to you.