Virtual LAN (VLAN) technology, which is defined under the IEEE 802.1q specifications, has allowed enterprise to extend the reach of their corporate networks across the WAN. VLANs enable a LAN to be partitioned based on functional requirements while maintaining connectivity across all devices on the network. VLAN groups network devices and enables them to behave as if they are in one single network. One level of data security is ensured by keeping the data exchanged between devices of a particular VLAN within the same network.
With VLANs becoming more pervasive, it's vital for networking equipment designers to understand in detail how VLANs operate. Thus, in this two-part tutorial, we'll provide an inside look at the key technical elements that make VLAN work. In Part 1 of this article, we'll examine the types of VLANs available and the key structures, such as tasks and identifiers, that make VLANs work. In Part 2, we'll follow up the discussion by looking at the generic attribute registration protocol (GARP) and GARP VLAN registration protocol. We will also look at emerging VLAN stacking and virtual private LAN service (VPLS) techniques.
VLAN Types
Typically, there are two types of VLANs: port-based and MAC address-based. Let's provide a quick overview of both.
In a small enterprise network, as shown in Figure 1 below, all subnets are connected to each other with the help of an IEEE 802.1D Ethernet media access control (MAC) bridge. To enable the data of one division in the enterprise to remain within that division, the network is made to support three VLANs. Network ports 1, 3, 6 and 8 are made part of VLAN A and similarly networks connected to 2 and 4, 5 and 7 belong to VLAN B and VLAN C respectively. The VLAN bridge functionality ensures data reception and forwarding among groups of ports (1, 3, 6 and 8) (2 and 4) and (5 and 7).
These VLANs described in the paragraph above are known as port-based VLANs, where the data packets do not require any modification. When a data frame is received on a port, the VLAN bridge (VBridge) determines the associated VLAN based on the port of reception. Using the forwarding database information, the VBridge forwards the data frame on the appropriate port(s).
In addition to port-based implementations, VLANs can be created using MAC addresses (see Figure 1 below). MAC-based VLANs can be created with MAC addresses of all devices on a network. MAC-based VLANs provide device mobility and the privacy of their own LAN.
In Figure 1, MAC-based VLAN B removes the restriction for a sales division device to be attached to networks connected via ports 5 and 7 and enables the device to be part of any network reachable via the 8 ports. In MAC-based VBridges, when a data packet is received on a port, the source MAC address determines the associated VLAN. While MAC-based VLANs provide benefits, they are rarely used due to administrative overheads.
Figure 1: Diagram showing a sample VLAN-enabled enterprise network.
VLAN Tags
Figure 2 shows a sample network supporting multiple VBridges. This network supports five VLANs connected via three VBridges. Assuming the spanning tree protocol has disabled the forwarding of data frames over link 3, the data flows via links 1 and 2. Data belonging to more than one VLAN flows over links 1 and 2. This requires a modification in the data frames to determine their associated VLANs. This is done with the help of VLAN tags.
Figure 2: Example multi-switch VLAN network.
The VLAN tag is 2 bytes in length (Figure 3). The last 12 bits of the tag is reserved for a VLAN identifier (VID), which enables the creation of 4096 VLANs. VLANs with IDs 0 and 4095 are reserved.
Figure 3: Diagram showing a the format for a VLAN tag.
The first 3 bits of the VLAN tag indicate user priority for the data packets. A canonical format indicator (CFI) bit indicates the direction of source routing information in 802.3/Ethernet and transparent FDD1 MAC methods. VLAN-unaware devices transmit and receive normal MAC data frames, such as untagged data packets. VLAN-aware devices are capable of transmitting and receiving tagged data packets. Depending on the type of devices connected to a VBridge port, the VBridge port can receive either only untagged or both types of data frames. Note: Data frames that are tagged with VID 0 are known as priority-tagged data frames.
PVID and Data Flows
In a VBridge, every data frame received on a port is associated with a unique VLAN to enable further processing and forwarding. In case of tagged data frames, the associated VLAN is determined from the VLAN tag. In the case of untagged data frames, the associated VLAN equals the permanent VLAN identifier (PVID) associated with the received port.
A VBridge port can be assigned only one VLAN-ID as its associated PVID. By default, this enables the port to be a member of the associated VLAN.
A VBridge port can also be assigned as member port of other VLANs. For example, in Figure 2 above, Bridge 1: Port 1 is assigned a PVID of 1, and is also assigned as member port of VLAN_2. This enables Port P1 to receive untagged data frames associated with VLAN_1 as well as receive VLAN_2 tagged data frames. When data frames associated with VLAN_2 are transmitted on VB1.P1, they will be tagged for VLAN_2. When data frames associated with VLAN_1 is transmitted on VB1.P1, they will be untagged.
The following are some data flows between the hosts and across the VLAN Bridges:
- H2 and H23. VLAN-unaware H2 generates untagged data frames DF1. VB1 associates DF1 with VLAN_1 at Port P1. Port P2 is the other member port of VLAN_1 and DF1 needs to be forwarded on Port P2. VBridge B1 tags the data frame and forwards it on P2. DF1 received at VBridge B3 Port P3 is associated with VLAN_1 (since the frames carry VLAN tag with VID 1). VB3 now forwards the DF1 to H23 on P1. VB3.P1's PVID is 1. VB3 untags the data frame before forwarding DF1 towards H23.
- H10 and H16. VLAN-aware H10 generates tagged data frames DF2. VB1 forwards this tagged data frame over P6, as P6 is a member port of VLAN_4. (VB1.P6's PVID is 1) VB2 receives the tagged data frame on its port P2 and forwards the tagged data frame over P3 towards H16. Being VLAN aware, H16 is capable of receiving tagged data frames.
- H22 and H5. H22 generates tagged data frames DF3 being VLAN aware. VB3 forwards this VLAN_2 tagged data frames over Port P3. VB1 receives the tagged data frames over Port P2 and forwards the data frame over Port P3 towards H5. VB1 now untags the data frame and forwards the data frame since devices on Port P3 are VLAN-unaware (VB1.P3's PVID is 2)
In addition to the MAC conversion, VBridges need to perform VLAN tag insertion and removal. Table 1 summarizes the VLAN tag insertion and removal requirements at a VBridge.
Table 1: VLAN Tag Insertion/Removal Requirements
Data Processing Sequence in VLAN Bridges
The reception and forwarding of data frames at a VBridge is done as a series of steps. Figure 4 below (Reproduction of 802.1Q-2003 Fig 8.8) provides a data flow of the data frame processing. A data frame on a received port is checked against a set of rules (statically or dynamically created) known as ingress rule checking. Some example rules are:
- The received data frame should not have a VLAN Tag value of 0xFFF
- The received data frame should be in one of the valid frame types expected at the port
- The received data frame should be acceptable as per the Ingress filtering rules
Figure 4: Diagram showing data forwarding in a VLAN bridge.
After the ingress rule check, a check is done for active topology condition. Ports are part of active topology only if they are in forwarding state as per the spanning tree protocol-enabled at the VBridge. A data packet can be received and transmitted over ports that are part of the active topology.
After ingress rule- and active topology-based checks, frame filtering rules are applied on the received data frame. The filtering rules are based on destination MAC address and the VID in the filtering database. The data frame selected for further forwarding after frame filtering process is checked for egress rules, such as whether the forwarding port is a valid member of the VLAN, the data frame needs to be tagged or untagged.
The egress rules applied data frame is queued for further transmission. Data frames are picked up from the queue based on user priority associated with the frames. The required frame format modification and frame check sequence (FCS) calculations are then done before final transmission.
VLAN Filtering Database
The filtering database is an important component of a VBridge and contains information for determining the forwarding process of a data frame. The forwarding is done based on the data frame's destination MAC address and associated VID. Filtering database contains both management configured static information and dynamically learnt information during the bridge operations. In the filtering database, information related to MAC addresses are known as filtering information and the information related to VLANs are known as registration information. A filtering database has:
- Static filtering entries
- Dynamic filtering entries
- Static VLAN registration entries
- Dynamic VLAN registration entries
Static filtering entries for an unicast or a multicast (group) address consist of:
- a MAC address
- a VLAN identifier
- a port map (list of outbound ports) with control information. The control information provides information as how this static entry information is to be used in association with any other dynamic or default filtering information
Dynamic filtering (for both unicast / multicast) entries consist of:
- a MAC address
- a filtering identifier (FID)
- a port map (list of outbound ports) with control information
The outbound port for forwarding data is determined with the help of FID and the port map. Unicast entries are created based on the source MAC address learnt while the multicast entries are created with the help of GARP multicast registration protocol (GMRP). Dynamic entries are removed if the entries are not refreshed at regular intervals within an aging time of 300 s.
Static VLAN registration entry consists of:
A VLAN identifier
- Port map with control information. The control information provides input such as:
- Filtering related to the VLAN
- Whether GVRP is enabled on the port and GVRP packet data units (PDUs) can be transmitted
- Whether dynamic learning of VLANs is enabled on the port
- Whether the outgoing data frames needs to be tagged or untagged
A Dynamic VLAN registration entry contains:
- VID of the VLAN
- Port map with control information for each outbound port
A filtering information database (FID) contains information associated with the source MAC addresses learnt by the normal bridge process. A FID contains source address (SA) information associated to a single VLAN or with multiple VLANs. If the VBridge uses independent VLAN learning (IVL), then there will be a single VID to FID mapping and in the case of shared VLAN learning (SVL), there will be multiple VIDs mapped to a FID. In a SVL configuration, information learned based on data frames on one VLAN is used for forwarding on other VLANs. In an IVL configuration, the information is learnt for each VLAN.
Port- and Protocol-Based VLANs
So far, we learned that a data frame's associated VID is either based on the tag or based on the port's PVID. The port- and protocol-based VLAN (PPV) classification initially defined in IEEE 802.1v (currently amended as part of 802.1Q-2003) enables data frame classification and assignment to unique VLANs based on the received data frame type and the protocol information in its payload. The PPV classification can be applied only to untagged data frames or to priority tagged data frames after the removal of the priority tag.
The data frame types currently covered under this classification are:
- Ethernet (IEEE 802.3 frame)
- RFC 1042 (Data frame with 802.3 type field in 802.2 snap header as specified in RFC 1042)
- SNAP_802.1H (Data frame with 802.3 type field in 802.2 snap header as specified in IEEE 802.1H)
- SNAP_Other (logical link control [LLC] PDUs with LLC address for SNAP with SNAP id values not covered by the ranges specified in RFC 1402 or IEEE 802.1H)
- LLC other (LLC PDUs, with formats not covered by the above definitions)
The type of the protocol information carried in the data frames is indicated by the type field in the MAC header. For example, the 16-bit type field in the Ethernet MAC frame indicates that the Ethernet frame contains an IP datagram or an IPX data packet or an address resolution protocol (ARP) PDU and so on.
A VBridge that supports PPV classification has
- Protocol Group Database (PGD) [Table 2]: This maintains an association between a protocol template and a protocol group identifier (PGI). Protocol template consists of frame type and protocol type.
- Port-VID Sets: At each port, the associated VID set indicates a unique mapping of PGI and its mapped VID. The scope of PGI-VID mapping is limited to a given port. This enables a PGI to be associated with different VLANs on different ports.
Table 2: Sample PGD Configuration
Table 2 above indicates a sample PGD entries and Port-VID sets. Applying Table 2 configuration to VB1 in Figure 2 above, an untagged IP PDU for H16 encapsulated in an Ethernet frame generated by H2 and received at VB1.P1 will be associated with VLAN_ID 4. Similarly, an ARP PDU in an Ethernet frame for H5 is associated with VLAN_ID 2. The data frame associated with VID 4 will be transmitted tagged on P6 while a frame associated with VID 2 will be transmitted as untagged on P3.
An untagged data frame is associated with the default PVID at a PPV supporting VBridge port when 1) no PGD entry exists matching the received data frame type and protocol type or 2) no PGI-VID mapping exists for the matched PGI at the received Port. A port Px becomes a member of VLAN_z, if a PGI g is assigned to VLAN_z at Port Px.
On To Part 2
That wraps up Part 1 of our look at VLANs. In Part 2, we'll look at GARP and GVRP. We'll also examine VPLS and VLAN stacking. To view Part 2, click here.
About the Author
Manikantan Srinivasan is the engineering manager at Net-O2 Technologies. He has an ME (Computer Science & Engineering) from the Indian Institute of Science, Bangalore, India and a B.Sc in Physics and Electronics from the University of Bangalore, India. Manikantan can be reached at manis@net-o2.com
