802.1Q trunking between network vendors
When you’re going to link two switches from different vendors together, you have to make sure that your VLAN mappings match up on both sides. Unfortunately, each switching vendor does things their own way, so you might have to adjust your configuration to get everything working properly.
I am going to focus on discussing trunking between switches. At the most basic level, this is just a cable running between two switches. What’s important is the configuration of the interfaces.
Native VLAN
Every switch port has a native or default VLAN . Cisco calls this the native VLAN, others call it the default VLAN, Extreme Networks refers to it as the untagged VLAN, etc. The key is that this VLAN represents all of the traffic on the switch that doesn’t have an 802.1Q tag on it. You might make the assumption that you could plug a Cisco port with a native VLAN of 10 into an Extreme port with an untagged VLAN of 20 and that would bridge both networks together, without either switch knowing that there was a mismatch. Unfortunately, higher-level STP protocols will actually catch the mismatch and shut the port down unless you specifically tell STP to ignore the error. So, native VLANs should be match where possible. Because of this, I don’t recommend ever using a switch’s default VLAN, but rather resetting your “default” VLAN to 10 or 20 or something to ensure compatibility later on. Alternatively, you can create a new “native-only” VLAN that specifically serves as the native VLAN for trunk negotiation.
Cisco calls it the native VLAN, and the default VLAN ID is 1.
Juniper calls it the default VLAN, and the default VLAN ID is 0.
Extreme calls it the untagged VLAN, and the default VLAN ID is 1.
HP calls it the untagged VLAN, and the default VLAN ID is 1.
Dell is weird. They call it the untagged VLAN or the PVID, and the default VLAN ID is 1. On a PowerConnect interface in “trunk” mode, VLAN 1 is tagged! You have to set the interface mode to “general” and then mark VLAN 1 as untagged.
In general, your native VLAN needs to match on both sides. Even if you plan on trunking everything other VLAN, switches often won’t negotiate a link without a matching native VLAN. Sometimes it will work, sometimes it won’t. Don’t leave it up to chance.
Trunking
When you configure a trunk in Cisco, it essentially adds every VLAN to that interface as tagged VLANs. If you want to connect two Cisco together, you can just set both interfaces as trunks and plug a cable in. However, most of the time we want to control which VLANs are being passed between the switches. We should always use 802.1Q for our trunk encapsulation, since it’s universally supported.
Note that many vendors use the word “trunk” to describe a set of aggregated interfaces (like LACP or etherchannel), which can confuse things.
In the VLAN-centric world, you configure your desired VLANs as tagged so that they’ll be passed between the switches over a single link. Here’s an example:
configure vlan native add port 5 untagged
configure vlan voice add port 5 tagged
configure vlan storage add port 5 tagged
configure vlan data add port 5 tagged
In the interface-centric world, you configured the allowed VLANs that can cross the link. Don’t forget to include your designated native VLAN in your list of allowed VLANs! Here’s an example:
interface gi-0/5
switchport trunk allowed vlan add 1,5,12-13
You need to make sure that your VLAN IDs match up on both sides, as if a switch sees a packet with an 802.1Q tag that it doesn’t recognize or have on the allowed list, the packet will be dropped.