802.1Q: VLANs and Vendor Interoperability

802.1Q: VLANs and Vendor Interoperability

Because vendors took individual approaches to create VLANs, network administrators were impaired whenever multiple vendor solutions were introduced into their system. A multi-vendor VLAN must be carefully handled to deal with interoperability shortcomings. Recognizing this deficiency in the industry, IEEE commissioned the 802.1Q committee to develop a vendor-independent method to create interoperable virtual bridged local area networks.

IEEE 802.1Q describes concepts called the shared VLAN (SVL) and independent VLAN (IVL). These define how bridges store MAC addresses in their bridging tables. SVL constrains a MAC address to only one VLAN. SVL-based devices build a giant bridge table, but allow a MAC address to appear only once in the table, regardless of how many VLANs exist. For many networks, this is fine.

However, this can be an undesirable constraint when devices or protocols reuse MAC addresses in different broadcast domains. For example, SUN workstations reuse a MAC address whenever two NICs are installed in the workstation. Yet each NIC attaches to a different broadcast domain and has different logical addresses. Clearly, this violates the rules of SVL networks, but not legacy networks. DecNet IV has a similar characteristic, in that MAC addresses can be reused in different broadcast domains. This too, fails in an SVL network.

Yet a third situation where SVL devices cannot work is when a router interconnects VLANs by routing some protocols and bridging others. For example, in Figure 5-8, Stations A and B support multiple protocols: TCP/IP and NetBEUI. A router in the system interconnects VLAN1 (Switch-A Ports 1 and 2) and VLAN2 (Switch-A Ports 3 and 4). The router performs routing for TCP/IP traffic and bridging for NetBEUI. (Bridging is necessary because NetBEUI is a non-routable protocol.)

Figure 5-8. An SVL Capable Switch and a Router that Routes and Bridges

When Station A transmits an IP frame to Station B, Station A transmits a frame with the router’s R1 MAC address as the destination and Station A’s address as the source. The router routes the frame to Station B using the router’s R2 MAC address for the source and Station B’s MAC address for the destination. When Station B responds to Station A, the switch learns about Station B on Port 4 Switch-A’s bridge table looks like that shown in Table 5-2, Event 1.

The table shows the four ports on Switch-A (1, 2, 3, and 4) and the learned MAC addresses on each of the ports. Ports 1 and 2 belong to VLAN 1, and Ports 3 and 4 belong to VLAN 2. The MAC addresses are represented as A and B for the two workstations and R1 and R2 for the two router interfaces. Switch-A knows about Station A’s MAC address on Port 1 and the router interfaces R1 and R2 MAC addresses on Ports 2 and 3, respectively.

When Station A transmits a NetBEUI frame, the switch relearns Station A’s MAC address on Port 1. When a router routes a frame, it replaces the source MAC address with its own MAC address. But, when the router bridges the frame out interface R2, the router does not replace the MAC address header and passes the original source MAC address through. Therefore, Switch-A now sees a frame from Station A on Port A.3. This causes the switch to believe that Station A moved. The bridge table now looks like Event 2 in Table 5-2. When Station B attempts to respond to Station A, the switch forwards the frame to router interface R2.

But when the router sends the frame out interface R1, the switch does not forward the frame to Port 1. Rather, the switch filters the frame because the switch believes that Station A is on Port 3, a different VLAN.

Table 5-2. Bridging Table

VLAN 1 2
Port 1 2 3 4
Event 1 A R1 R2 B
Event 2 R1 R2,A B

One final deficiency with 802.1Q concerns Spanning Tree. With 802.1Q, there is currently only one instance of Spanning Tree. This forces all VLANs to the same Spanning Tree topology which might not be optimal for all VLANs. The Catalyst, for example, uses multiple instances of Spanning Tree: one for each VLAN. This allows you to optimize the topology for each VLAN. Part II of this book, “Spanning Tree” provides details on the multiple instances of Spanning Tree.

The Catalyst does not use SVL tables. Rather, it uses Independent VLAN learning (IVL) which allows the same MAC address to appear in different broadcast domains. An IVL-capable device maintains independent bridge tables for each VLAN, allowing devices to reuse a MAC address in different VLANs. All of the Catalyst bridging examples in this book illustrate IVL methods.

About the author


Leave a Comment