Sei sulla pagina 1di 6

IEEE 802.

1Q
From Wikipedia, the free encyclopedia

Jump to: navigation, search This article may be too technical for most readers to understand. Please improve this article to make it understandable to non-experts, without removing the technical details. (September 2010) IEEE 802.1Q, or VLAN tagging, is a networking standard promulgated by the IEEE 802.1 work group for the sharing of a physical Ethernet network link by multiple independent logical networks. IEEE 802.1Q defines the meaning of a virtual LAN (VLAN) with respect to the specific conceptual model underpinning bridging at the Media Access Control layer and to the IEEE 802.1D Spanning Tree Protocol. This protocol allows nodes on different VLANs to communicate with one another through a network switch with Network Layer (OSI layer 3) capabilities, or a router.

Contents
[hide]

1 Example application 2 Frame format o 2.1 Double tagging 3 Trunk ports and the native VLAN 4 Multiple VLAN Registration Protocol 5 Multiple Spanning Tree Protocol 6 See also 7 References 8 External links

[edit] Example application


A company wishes to provide data separation and security between network traffic from its various departments by creating separate logical networks for each of its departments dispersed throughout the enterprise, while using only one corporate physical network. A network administrator assigns a unique VLAN to each department. Edge switches on the corporate network are configured to insert an appropriate VLAN tag into all data frames arriving from equipment belonging to a given department. After the frames are transmitted on their respective VLANs through the corporate network, the VLAN tag is stripped before the frame is sent to another computer belonging to the same department.

[edit] Frame format

Insertion of 802.1Q Tag in Ethernet-II frame 802.1Q does not actually encapsulate the original frame. Instead, for Ethernet II frames, it adds a 32-bit field between the source MAC address and the EtherType/Length fields of the original frame. Two bytes are used for the tag protocol identifier (TPID), the other two bytes for tag control information (TCI). The TCI field is further divided into PCP, CFI, and VID. 16 bits 3 bits 1 bit 12 bits TCI TPID PCP CFI VID Tag Protocol Identifier (TPID): a 16-bit field set to a value of 0x8100 in order to identify the frame as an IEEE 802.1Q-tagged frame. This field is located at the same position as the EtherType/Size field in untagged frames, and is thus used to distinguish the frame from untagged frames.

Tag Control Identifier (TCI) o Priority Code Point (PCP): a 3-bit field which refers to the IEEE 802.1p priority. It indicates the frame priority level. Values are from 0 (best effort) to 7 (highest); 1 represents the lowest priority. These values can be used to prioritize different classes of traffic (voice, video, data, etc). o Canonical Format Indicator (CFI): a 1-bit field. If the value of this field is 1, the MAC address is in non-canonical format. If the value is 0, the MAC address is in canonical format. It is always set to zero for Ethernet switches. CFI is used for compatibility between Ethernet and Token Ring networks. If a frame received at an Ethernet port has a CFI set to 1, then that frame should not be bridged to an untagged port. o VLAN Identifier (VID): a 12-bit field specifying the VLAN to which the frame belongs. A value of 0 means that the frame does not belong to any VLAN; in this case the 802.1Q tag specifies only a priority and is referred to as a priority tag. The hexadecimal values of 0x000 and 0xFFF are reserved. All other values may be used as VLAN identifiers, allowing up to 4094 VLANs. On bridges, VLAN 1 (the default VLAN ID) is often reserved for management.

For frames using IEEE 802.2/SNAP encapsulation with an OUI field of 00-00-00 (so that the protocol ID field in the SNAP header is an EtherType), as would be the case on LANs

other than Ethernet, the EtherType value in the SNAP header is set to 0x8100 and the aforementioned extra 4 bytes are appended after the SNAP header.[citation needed] Because inserting the VLAN tag changes the frame, 802.1Q encapsulation forces a recalculation of the original FCS field in the Ethernet trailer. It also increases the maximum frame size by 4 bytes.

[edit] Double tagging


With the IEEE standard 802.1ad, double-tagging can be useful for Internet service providers, allowing them to use VLANs internally while mixing traffic from clients that are already VLAN-tagged. The outer (next to source MAC and representing ISP VLAN) S-TAG (service tag) comes first, followed by the inner C-TAG (customer tag). In such cases, 802.1ad specifies a TPID of 0x88a8 for service-provider outer S-TAG.

Insertion of 802.1ad DoubleTag in Ethernet-II frame Non-standard triple-tagging is also possible. The third tag of 4 bytes allows extended addressing and also a small hop-count. The 66-bit addressing plan now uses a fixed (nonstacking) QinQinQ format. The result is three 32-bit tags plus the 16-bit EtherType/Size for a total of 112 bits. The two 48-bit (MAC) address fields add another 96 bits. The total header is 208-bits compared to a 320-bit IPv6 header. The 66-bit addressing is 18+48. The 18-bits are encoded 6-bits per 32-bit tag in the 12-bit VID fields. The 16-bit EtherType/Size field can contain the Payload Size or an EtherType for Payloads that contain their own Length, such as IPv4. 16 bits 3 bits 1 bit 12 bits TPID0 PCP CFI VID0 TPID1 CONTENT RATING CFI VID1 TPID2 HOP CFI VID2 The contents of TPID0+TPID1+TPID2 contain the 48-bit MAC Address of the Source Device.

[edit] Trunk ports and the native VLAN

Clause 9 of the 1998 802.1Q standard defines the encapsulation protocol used to multiplex VLANs over a single link, by adding VLAN tags. However, it is possible to send frames either tagged or untagged, so to help explain which frames will be sent with or without tags, some vendors (most notably Cisco) use the concepts of a) trunk ports and b) the native VLAN for that trunk. The concept of a trunk port is that once a port is designated as a trunk port, it will forward and receive tagged frames. Frames belonging to the native VLAN do NOT carry VLAN tags when sent over the trunk. Conversely, if an untagged frame is received on a trunk port, the frame is associated with the Native VLAN for this port. For example, if an 802.1Q port has VLANs 2, 3 and 4 assigned to it with VLAN 2 being the Native VLAN, frames on VLAN 2 that egress (exit) the aforementioned port are not given an 802.1Q header (i.e. they are plain Ethernet frames). Frames which ingress (enter) this port and have no 802.1Q header are put into VLAN 2. Behaviour of traffic relating to VLANs 3 & 4 is as to be expected - frames arriving for VLANs 3 & 4 are expected to be carrying tags that identify them so, and frames leaving the port for VLANs 3 & 4 will carry their respective VLAN tag. Note that in this case, frames received on the port and tagged with VLAN ID 2 shall still be assigned to VLAN 2, but since the VLAN configuration shall be symmetric between emitting and receiving bridges, the distant bridge may not process the returning frames : it shall expect a tagged VLAN 2 frame, but will receive only untagged frames for it, then either discard them or distribute them in the wrong VLAN (the one defined as the "untagged" one on his side). Not all vendors use the concept of trunk ports and native VLANs. Annex D to the 1998 802.1Q standard uses the concept of trunk links, but the current (IEEE Std 802.1D- 2004) standard does not use the terms trunk or native. Some use the term "Qtrunk" to avoid confusion with 802.3ad "link aggregation" that is often named a trunk as well.

[edit] Multiple VLAN Registration Protocol


In addition, IEEE 802.1Q defines the Multiple VLAN Registration Protocol (MVRP), an application of the Multiple Registration Protocol, allowing bridges to negotiate the set of VLANs to be used over a specific link. MVRP replaced the slower GARP VLAN Registration Protocol (GVRP) in 2007 with the IEEE 802.1ak-2007 amendment.

[edit] Multiple Spanning Tree Protocol

The 2003 revision of the standard included the Multiple Spanning Tree Protocol (MSTP) which was originally defined in IEEE 802.1s

Multiple Spanning Tree Protocol (MSTP)


The Multiple Spanning Tree Protocol (MSTP), originally defined in IEEE 802.1s and later merged into IEEE 802.1Q-2005, defines an extension to RSTP to further develop the usefulness of virtual LANs (VLANs). This "Per-VLAN" Multiple Spanning Tree Protocol configures a separate Spanning Tree for each VLAN group and blocks all but one of the possible alternate paths within each Spanning Tree. If there is only one Virtual LAN (VLAN) in the network, single (traditional) STP works appropriately. If the network contains more than one VLAN, the logical network configured by single STP would work, but it is possible to make better use of the alternate paths available by using an alternate spanning tree for different VLANs or groups of VLANs. MSTP allows formation of MST regions that can run multiple MST instances (MSTI). Multiple regions and other STP bridges are interconnected using one single common spanning tree (CST). MSTP is similar to Cisco Systems' Multiple Instances Spanning Tree Protocol (MISTP), and is an evolution of the Spanning Tree Protocol and the Rapid Spanning Tree Protocol. It was introduced in IEEE 802.1s as an amendment to 802.1Q, 1998 edition. Standard IEEE 802.1Q-2005 now includes MSTP. Unlike some proprietary per-VLAN spanning tree implementations,[14] MSTP includes all of its spanning tree information in a single BPDU format. Not only does this reduce the number of BPDUs required on a LAN to communicate spanning tree information for each VLAN, but it also ensures backward compatibility with RSTP (and in effect, classic STP too). MSTP does this by encoding additional region information after the standard RSTP BPDU as well as a number of MSTI messages (from 0 to 64 instances, although in practice many bridges support fewer). Each of these MSTI configuration messages conveys the spanning tree information for each instance. Each instance can be assigned a number of configured VLANs and frames (packets) assigned to these VLANs operate in this spanning tree instance whenever they are inside the MST region. In order to avoid conveying their entire VLAN to spanning tree mapping in each BPDU, bridges encode an MD5 digest of their VLAN to instance table in the MSTP BPDU. This digest is then used by other MSTP bridges, along with other administratively configured values, to determine if the neighboring bridge is in the same MST region as itself. MSTP is fully compatible with RSTP bridges, in that an MSTP BPDU can be interpreted by an RSTP bridge as an RSTP BPDU. This not only allows compatibility with RSTP bridges without configuration changes, but also causes any RSTP bridges outside of an MSTP region to see the region as a single RSTP bridge, regardless of the number of MSTP bridges inside the region itself. In order to further facilitate this view of an MST

region as a single RSTP bridge, the MSTP protocol uses a variable known as remaining hops as a time to live counter instead of the message age timer used by RSTP. The message age time is only incremented once when spanning tree information enters an MST region, and therefore RSTP bridges will see a region as only one "hop" in the spanning tree. Ports at the edge of an MST region connected to either an RSTP or STP bridge or an endpoint are known as boundary ports. As in RSTP, these ports can be configured as edge ports to facilitate rapid changes to the forwarding state when connected to endpoints.

[edit] Rapid Per-VLAN Spanning Tree (R-PVST)


Cisco's proprietary protocol that combines the functionalities of RSTP and PVST. It is based on a per VLAN instance that creates a tree for each VLAN.

Potrebbero piacerti anche