AppNote VLANBr

VLAN Bridging
Date: Version:
March 2008 v1.0
Abstract:
This Application Notes describes the configuration of a specific feature of the Thomson Gateway: VLAN Bridging. This feature is explained by integrating the Thomson Gateway in a scenario where untagged, priority-tagged or VLAN-tagged frames have to be bridged between the local Ethernet segment and the DSL line. The practical realization of the scenario is described using CLI commands. This Application Note applies to all Thomson DSL Gateways with R7.4 and higher. Thomson continuously develops new solutions, but is also committed to improving its existing products. For more information on Thomson's latest technological innovations, documents and software releases, visit us at http://www.thomson-broadband.com
Applicability: Updates:
Contents
1 2
2.1 2.2
Introduction.................................................................................. 3 Port-to-PVC Mapping .................................................................. 4

Scenario Overview .......................................................................................... 4 Practical Realization ....................................................................................... 4
3
3.1 3.2
VLAN-Transparent Forwarding .................................................. 8

Scenario Overview .......................................................................................... 8 Practical Realization ....................................................................................... 8
4
4.1 4.2
VLAN ID-Based Forwarding...................................................... 11

Scenario Overview ........................................................................................ 11 Practical Realization ..................................................................................... 11
5
5.1 5.2
Unknown VLAN Forwarding .................................................... 16

6
6.1 6.2
VLAN ID Translation.................................................................. 21
7
7.1 7.2
VLAN User Priority Mapping to One PVC ............................... 26

8
8.1 8.2
IP ToS Mapping for PVC Multiplexing ..................................... 30

E-DOC-CTC-20080229-0004 v1.0
Chapter 1
Introduction
Thomson Gateway as bridge

To set up the scenario of this document, the Thomson Gateway is configured as bridge. This means that Ethernet frames are forwarded between the local Ethernet segment (LAN) and the WAN Ethernet segment (PVCs on which RFC 1483 LLC encapsulation is used) on the link layer. In other words, the Thomson Gateway does not terminate or route received Ethernet frames.
VLANs
The Ethernet frames that have to be forwarded may reside in different VLANs. This implies that all Ethernet frames contain a (802.1Q) VLAN ID. Communication between different VLANs is not allowed on the link layer. Only routers can make connections between different VLANs. VLANs create thus separated logical Ethernet segments within a single physical segment.
Ethernet QoS
Ethernet frames optionally contain a (802.1p) user priority indication. If Ethernet QoS is taken into account during bridging, it can be based on two steps: 1 Mapping the user priority of an incoming frame to an internal priority class. This classification can be based on: The type of the interface on which the frame is entering the bridge. The (802.1p) user priority value. The IP Type of Service octet (TOS-byte) for IP packets, using the Precedence or DSCP notation. 2 Sending out the frame while taking into account its internal priority class. This class can be used to: Perform priority queuing on a single PVC. Perform traffic multiplexing over a range of PVCs.
Related documents
For detailed information on the features, CLI commands and parameters used in this document, see: Thomson Gateway Ethernet Configuration Guide. Thomson Gateway VLAN Configuration Guide. Thomson Gateway Ethernet QoS Configuration Guide.
E-DOC-CTC-20080229-0004 v1.0
Chapter 2
2 2.1
Port-to-PVC Mapping Scenario Overview
Introduction
In this scenario, the Thomson Gateway is intended to classify untagged Ethernet frames based on the receiving local interface. Per local interface, you have to be able to configure to which PVC the frames must be forwarded. This scenario configures the Thomson Gateway as bridge with two PVCs. Traffic on all local interfaces, except for one, is forwarded to the first PVC. Traffic on a specific local interface is forwarded to the second PVC. For example, you can use one PVC for normal Internet traffic and a second PVC for multicast traffic. Following illustration shows the port-to-PVC mapping scenario:
Thomson Gateway
DSLAM
PVC1
PVC2
Local interface
WAN interface
Mechanisms
To set up this scenario, we use following mechanisms: VLANs: the Ethernet bridge uses VLANs to forward traffic to different PVCs. Configuring the VLAN membership of the bridge ports enables you to configure from which local interface to which PVC the traffic must be forwarded. Port isolation: this term is used when a bridge port is added to a VLAN and explicitly removed from the default VLAN.
2.2
Practical Realization
Configuration overview
Following configuration steps have to be performed to configure the Thomson Gateway for this scenario: 1 2 3 Define which PVCs must be used by configuring an ATM interface for each one of them. Connect the ATM interfaces to the Ethernet bridge. Make the bridge VLAN aware.
E-DOC-CTC-20080229-0004 v1.0
Chapter 2
4 5 6
Define the necessary VLANs on the Ethernet bridge. Define which interfaces are part of which VLAN. Save the configuration.
Before you start

Before you start to configure the Thomson Gateway, make following preparations: Reset the Thomson Gateway to the factory defaults and reboot the device. Make sure the telnet session with the Thomson Gateway never times out. Remove the factory default interfaces and settings that you do not need for the configuration. Make these changes permanent. Now, you can start from a clean situation.
=>:system reset factory=yes proceed=yes =>:env set var=SESSIONTIMEOUT value=0 =>:ppp =>:ppp =>:eth =>:atm =>:atm relay flush flush flush flush phonebook flush
=>:saveall
Configure ATM interfaces

To create a phonebook entry for each PVC that must be used, execute following CLI commands (the VPI/VCI values are indicative):
=>:atm phonebook add name=phone_PVC1 addr=0.35 =>:atm phonebook add name=phone_PVC2 addr=0.36
To create, configure and connect ATM interfaces on top of these phonebook entries, execute following CLI commands:
=>:atm ifadd intf=atm_PVC1 =>:atm ifconfig intf=atm_PVC1 dest=phone_PVC1 encaps=llc ulp=mac =>:atm ifattach intf=atm_PVC1 =>:atm ifadd intf=atm_PVC2 =>:atm ifconfig intf=atm_PVC2 dest=phone_PVC2 encaps=llc ulp=mac =>:atm ifattach intf=atm_PVC2
Configure bridge ports

To connect the ATM interfaces to the Ethernet bridge, execute following CLI commands:
:eth bridge ifadd intf=bridge_PVC1 :eth bridge ifconfig intf=bridge_PVC1 dest=atm_PVC1 :eth bridge ifattach intf=bridge_PVC1 :eth bridge ifadd intf=bridge_PVC2 :eth bridge ifconfig intf=bridge_PVC2 dest=atm_PVC2 :eth bridge ifattach intf=bridge_PVC2
E-DOC-CTC-20080229-0004 v1.0
Chapter 2
Make the bridge VLAN aware

To enable the VLAN awareness of the Ethernet bridge, execute following CLI command:
=>:eth bridge config vlan=enabled
Create a VLAN
To define the VLAN to be used, execute following CLI command:
=>:eth vlan add name=MyVLAN_A vid=10 addrule=disabled
A logical name is associated with the effective VID that is used by the Ethernet bridge for that VLAN. The addrule=disabled parameter forces the Thomson Gateway to create a separate filtering database for the created VLAN. As a result, the same MAC address (e.g. the DSLAM MAC address) can be used in different VLANs, for example when different VLANs are connected to the same device (e.g. the DSLAM).
Configure VLAN membership

Configure port isolation of the ethport4 bridge port: add the bridge port (local interface) to the new VLAN and explicitly remove it from the default VLAN, executing following CLI commands:
=>:eth bridge vlan ifadd name=MyVLAN_A intf=ethport4 =>:eth bridge vlan ifdelete name=default intf=ethport4
Configure port isolation of the bridge_PVC2 bridge port: add the bridge port (WAN interface) to the new VLAN and explicitly remove it from the default VLAN, executing following CLI commands:
=>:eth bridge vlan ifadd name=MyVLAN_A intf=bridge_PVC2 =>:eth bridge vlan ifdelete name=default intf=bridge_PVC2
Save the configuration

To make your changes permanent, execute following CLI command:
=>:saveall
Expected result
To display the list of VLANs on the Ethernet bridge, execute following CLI command:
=>:eth vlan list Vid Name -----1 default 10 MyVLAN_A
E-DOC-CTC-20080229-0004 v1.0
Chapter 2
To retrieve an overview of the population of the different VLANs, execute following CLI command:
=>:eth bridge vlan iflist Vid Name Bridge interfaces (* = untagged) ------------------------------------1 default OBC*, ethport1*, ethport2*, ethport3*, bridge_PVC1* 10 MyVLAN_A ethport4*, bridge_PVC2*
Each bridge port is member of a single VLAN. Untagged frames received on a bridge port are only forwarded to bridge ports that are member of the same VLAN: Frames received on bridge port 4 are forwarded to PVC2 and vice versa. Frames received on other bridge ports are forwarded within the default VLAN.
E-DOC-CTC-20080229-0004 v1.0
Chapter 3
3 3.1
VLAN-Transparent Forwarding Scenario Overview
Introduction
In this scenario, the Thomson Gateway is intended to forward all VLAN-tagged frames between the local Ethernet segment and a PVC transparently. This scenario configures the Thomson Gateway as bridge with one PVC. All incoming frames on all local interfaces have to be forwarded transparently to this PVC. The PVC to which all traffic has to be forwarded, is chosen at configuration time. The exact value of the VLAN ID (VID) or the user priority indication should not influence the result. Following illustration shows the VLAN-transparent forwarding scenario:
Thomson Gateway
DSLAM
A A B B C C
5 2 7 3
PVC1
A A
5 2
B B
7 3 C
2 1
VID
802.1p
WAN interface
Mechanism
To set up this scenario, we use following key mechanism: we explicitly define that the Ethernet bridge is not VLAN aware. Ethernet frames coming in on the Thomson Gateway have a VLAN tag in their header. However, neither the VLAN ID nor the user priority indication should be taken into account. If the Ethernet bridge is VLAN aware, we have to define all VLANs that have to pass through the Thomson Gateway. Otherwise, unknown VLANs are dropped.
3.2
Following configuration steps have to be performed to configure the Thomson Gateway for this scenario: 1 2 3 4 Define which PVC must be used by configuring an ATM interface for it. Connect the ATM interface to the Ethernet bridge. Define that the bridge is not VLAN aware. Save the configuration.
E-DOC-CTC-20080229-0004 v1.0
Chapter 3
Before you start

=>:saveall
Configure an ATM interface

To create a phonebook entry for the PVC that must be used, execute following CLI command (the VPI/VCI value is indicative):
=>:atm phonebook add name=phone_PVC1 addr=0.35
To create, configure and connect an ATM interface on top of this phonebook entry, execute following CLI commands:
=>:atm ifadd intf=atm_PVC1 =>:atm ifconfig intf=atm_PVC1 dest=phone_PVC1 encaps=llc ulp=mac =>:atm ifattach intf=atm_PVC1
Configure a bridge port

To connect the ATM interface to the Ethernet bridge, execute following CLI commands:
=>:eth bridge ifadd intf=bridge_PVC1 =>:eth bridge ifconfig intf=bridge_PVC1 dest=atm_PVC1 =>:eth bridge ifattach atm_PVC1
Disable VLAN awareness of the bridge

By default, the bridge is already not VLAN aware. To check the current status of the Ethernet bridge, execute following CLI command:
=>:eth Ageing Filter VLAN ... bridge config : 300 : no_WAN_broadcast : disabled
E-DOC-CTC-20080229-0004 v1.0
Chapter 3
If necessary, disable the VLAN awareness of the Ethernet bridge executing following CLI command:
=>:eth bridge config vlan=disabled

=>:saveall
Expected result
All incoming frames on a local interface are forwarded to the configured PVC. The same is true for frames arriving on the Thomson Gateway via the DSL line: these frames are forwarded to the local Ethernet segment. Whether the frame has a VLAN tag or not is irrelevant for the current scenario. All frames are forwarded in both directions. In this statement, all frames has to be understood as all frames that should be forwarded by a regular bridge. There are exceptions, for example, administered reserve multicast destination addresses.
10
E-DOC-CTC-20080229-0004 v1.0
Chapter 4
4 4.1
VLAN ID-Based Forwarding Scenario Overview
Introduction
In this scenario, the Thomson Gateway is intended to classify VLAN-tagged Ethernet frames based on their VLAN ID. Per VLAN ID, you have to be able to configure to which PVC the frames must be forwarded. This scenario configures the Thomson Gateway as bridge with two PVCs. Frames coming in on a local interface are checked on their VLAN ID and are only forwarded on PVCs that are member of the same VLAN. For example, frames that are member of VLAN A are forwarded to the first PVC. Frames that are member of VLAN B or VLAN C are forwarded to the second PVC. The receiving local interface should not influence the result. Following illustration shows the VLAN ID-based forwarding scenario:
Thomson Gateway
DSLAM
A A B B C C
5 2 7 3 2 1
PVC2
PVC1
3 C
C 2
VID
802.1p
WAN interface
Mechanisms
To set up this scenario, we use following mechanisms: VLAN awareness: the Ethernet bridge must be fully VLAN aware. As a result, the Ethernet bridge takes the VLAN tag in the header of received frames into account. VLANs: several VLANs are created on the Thomson Gateway. The local interfaces must be member of all possible VLANs that can appear in the VLAN tag of received frames. The configured VLAN membership of the PVCs defines to which PVC the frames must be forwarded.
4.2
Following configuration steps have to be performed to configure the Thomson Gateway for this scenario: 1 2 3 Define which PVCs must be used by configuring an ATM interface for each one of them. Connect the ATM interfaces to the Ethernet bridge. Make the bridge VLAN aware.
E-DOC-CTC-20080229-0004 v1.0
11
Chapter 4
4 5 6
Define a VLAN for each VLAN ID the Ethernet bridge has to handle. Define which interfaces are part of which VLAN. Save the configuration.
Before you start

=>:saveall

To create, configure and connect the ATM interfaces on top of the phonebook entries, execute following CLI commands:
=>:atm ifadd intf=atm_PVC1 =>:atm ifconfig intf=atm_PVC1 dest=phone_PVC1 encaps=llc ulp=mac =>:atm ifattach intf=atm_PVC1 =>:atm ifadd intf=atm_PVC2 =>:atm ifconfig intf=atm_PVC2 dest=phone_PVC2 encaps=llc ulp=mac =>:atm ifattach intf=atm_PVC2

=>:eth bridge ifadd intf=bridge_PVC1 =>:eth bridge ifconfig intf=bridge_PVC1 dest=atm_PVC1 =>:eth bridge ifattach intf=bridge_PVC1 =>:eth bridge ifadd intf=bridge_PVC2 =>:eth bridge ifconfig intf=bridge_PVC2 dest=atm_PVC2 =>:eth bridge ifattach intf=bridge_PVC2R
12
E-DOC-CTC-20080229-0004 v1.0
Chapter 4

From this moment on, all Ethernet frames coming in on the Ethernet bridge with a VLAN tag are only forwarded to interfaces configured as an explicit member of that VLAN.
Create the VLANs

To define the VLANs to be used, execute following CLI commands:
=>:eth vlan add name=MyVLAN_A vid=10 addrule=disabled =>:eth vlan add name=MyVLAN_B vid=11 addrule=disabled =>:eth vlan add name=MyVLAN_C vid=12 addrule=disabled
A logical name is associated with the effective VID that is used in the VLAN tag of the frame. The addrule=disabled parameter forces the Thomson Gateway to create a separate filtering database for the created VLAN. As a result, the same MAC address (e.g. the DSLAM MAC address) can be used in different VLANs, for example when different VLANs are connected to the same device (e.g. the DSLAM).
Assign local interfaces to VLANs

The LAN-side bridge ports must be member of each VLAN from which they have to accept frames. In this example, we only enable bridge port 4 to receive VLAN-tagged frames from the LAN. To put bridge port 4 in all three defined VLANs, execute following CLI commands:
=>:eth bridge vlan ifadd name=MyVLAN_A intf=ethport4 untagged=disabled =>:eth bridge vlan ifadd name=MyVLAN_B intf=ethport4 untagged=disabled =>:eth bridge vlan ifadd name=MyVLAN_C intf=ethport4 untagged=disabled
The untagged=disabled parameter avoids that the VLAN tag is stripped off when the frames are sent out on the interface.
Assign WAN interfaces to VLANs

The VLAN membership of the WAN-side bridge ports defines to which PVCs the frames are forwarded. In this example, frames of VLAN A are forwarded to one PVC, frames of VLAN B and VLAN C are forwarded to the other PVC. To add each WAN-side bridge port to the correct VLAN(s), execute following CLI commands:
=>:eth bridge vlan ifadd name=MyVLAN_A intf=bridge_PVC1 untagged=disabled =>:eth bridge vlan ifadd name=MyVLAN_B intf=bridge_PVC2 untagged=disabled =>:eth bridge vlan ifadd name=MyVLAN_C intf=bridge_PVC2 untagged=disabled
E-DOC-CTC-20080229-0004 v1.0
13
Chapter 4

=>:saveall
Expected result
=>:eth vlan list Vid Name -----1 default 10 MyVLAN_A 11 MyVLAN_B 12 MyVLAN_C
=>:eth Vid --1 10 11 12 bridge vlan iflist Name Bridge interfaces (* = untagged) ----------------------------------default OBC*, ethport1*, ethport2*, ethport3*, ethport4*, bridge_PVC1*, bridge_PVC2* MyVLAN_A ethport4, bridge_PVC1 MyVLAN_B ethport4, bridge_PVC2 MyVLAN_C ethport4, bridge_PVC2
Frames received on a bridge port are checked for their VLAN ID and are only sent out on bridge ports that are member of the same VLAN. The table above shows that frames with VID 10 (representing VLAN A) are only transmitted on PVC1. Frames with VID 11 (VLAN B) or 12 (VLAN C) are transmitted on PVC2. It can be seen that all interfaces are also member of the default VLAN, and, as a result, also have connectivity with the Thomson Gateway.
Optionally control unexpected frames

The current configuration does not explicitly regulate the handling of unexpected frames that arrive on any of the bridge ports of the Thomson Gateway: Untagged frames: For example, to assign untagged frames to the default VLAN, execute following CLI command:
=>:eth bridge ifconfig intf=ethport4 vlan=default
For example, to accept only VLAN-tagged frames on bridge port 4, execute following command:
=>:eth bridge ifconfig intf=ethport4 acceptvlanonly=enabled
Tagged frames arriving on an incorrect interface: For example, to drop VLAN-tagged frames coming in on PVC1 if the VID differs from 10, execute following CLI command:
=>:eth bridge ifconfig intf=bridge_PVC1 ingressfiltering=enabled
14
E-DOC-CTC-20080229-0004 v1.0
Chapter 4
Additionally, you can use following CLI command to prevent the Thomson Gateway from modifying the user priority indication in the VLAN tag:
=>:eth bridge ifconfig intf=bridge_PVC1 priotransparent=enabled
E-DOC-CTC-20080229-0004 v1.0
15
Chapter 5
5 5.1
Unknown VLAN Forwarding Scenario Overview
Introduction
In this scenario, the Thomson Gateway is intended to forward VLAN-tagged frames between the local Ethernet segment and PVCs. For a limited number of VLAN IDs, you have to be able to configure to which PVC the frames must be forwarded. For all other VLAN IDs, the frames have to be forwarded transparently to a single PVC. This PVC is also selected at configuration time. This scenario configures the Thomson Gateway as bridge with two PVCs. One local interface receives frames that are member of VLAN A. These frames are forwarded to the first PVC. Another local interface receives frames that are member of several other VLANs. All these frames are forwarded to the second PVC. Following illustration shows the unknown VLAN forwarding scenario:
Thomson Gateway
DSLAM
A A 2
PVC1
7 C 1
X Y
2 3
3 X
C 2
PVC2
Local interface VID 802.1p
WAN interface
Mechanism
To set up this scenario, we use following mechanisms: VLAN awareness: the Ethernet bridge must be VLAN aware. As a result, the Ethernet bridge takes the VLAN tag in the header of received frames into account. VLANs: VLAN A is created on the Thomson Gateway. The configured VLAN membership of the interfaces defines from which local interface to which PVC the frames must be forwarded. Unknown VID policy: this mechanism avoids the need to configure all possible VLANs that can appear in the VLAN tag of received frames. A special VLAN, the unknown VLAN, is created on the Ethernet bridge. This way, all frames that are member of VLANs that are not explicitly configured, can be forwarded transparently.
5.2
Following configuration steps have to be performed to configure the Thomson Gateway for this scenario: 1 Define which PVCs must be used by configuring an ATM interface for each one of them.
16
E-DOC-CTC-20080229-0004 v1.0
Chapter 5
2 3 4 5 6 7
Connect the ATM interfaces to the Ethernet bridge. Make the bridge VLAN aware. Define a VLAN for each VLAN ID the Ethernet bridge has to handle in a specific way. Define which interfaces are part of which VLAN. Define an unknown VLAN for all VLAN IDs the Ethernet bridge has to handle transparently. Save the configuration.
Before you start

=>:saveall

To create, configure and connect the ATM interfaces on top of these phonebook entries, execute following CLI commands:
=>:atm ifadd intf=atm_PVC1 =>:atm ifconfig intf=atm_PVC1 dest=phone_PVC1 ulp=mac =>:atm ifattach intf=atm_PVC1 =>:atm ifadd intf=atm_PVC2 =>:atm ifconfig intf=atm_PVC2 dest=phone_PVC2 ulp=mac =>:atm ifattach intf=atm_PVC2
E-DOC-CTC-20080229-0004 v1.0
17
Chapter 5

=>:eth bridge ifadd intf=bridge_PVC1 =>:eth bridge ifconfig intf=bridge_PVC1 dest=atm_PVC1 =>:eth bridge ifattach intf=bridge_PVC1 =>:eth bridge ifadd intf=bridge_PVC2 =>:eth bridge ifconfig intf=bridge_PVC2 dest=atm_PVC2 =>:eth bridge ifattach intf=bridge_PVC2

From this moment on, all Ethernet frames arriving on the Ethernet bridge with a VLAN tag are only forwarded to interfaces configured as an explicit member of that VLAN.
Create the VLANs

To define the VLAN that the Ethernet bridge has to handle in a specific way, execute following CLI commands:
Assign interfaces to the VLANs

The LAN-side bridge ports must be member of each VLAN from which they have to accept frames. In this example, we only enable Ethernet port 2 to receive VLAN-tagged frames from VLAN A. To put Ethernet port 2 in the (explicitly) defined VLAN A, execute following CLI command:
=>:eth bridge vlan ifadd name=MyVLAN_A intf=ethport2 untagged=disabled
The VLAN membership of the WAN-side bridge ports defines to which PVCs the frames are forwarded. In this example, frames of VLAN A are forwarded to the first PVC. To put the ATM-based bridge port for the first PVC in VLAN A, execute following CLI command:
=>:eth bridge vlan ifadd name=MyVLAN_A intf=bridge_PVC1 untagged=disabled
Configure the unknown VID policy

The interfaces that receive or forward VLAN-tagged frames with a VLAN ID that is not explicitly defined on the Ethernet bridge, must be member of the unknown VLAN.
18
E-DOC-CTC-20080229-0004 v1.0
Chapter 5
To put Ethernet port 3 and the second PVC in the unknown VLAN, execute following CLI command:
=>:eth bridge unknownvlan ifadd intf=ethport3 untagged=disabled =>:eth bridge unknownvlan ifadd intf=bridge_PVC2 untagged=disabled
The untagged=disabled parameter avoids that the VLAN-header is stripped off when the frames are sent out on the interface.

=>:saveall
Expected result
To display the list of known VLANs on the Ethernet bridge, execute following CLI command:
=>:eth bridge vlan iflist Vid Name Bridge interfaces (* = untagged) ------------------------------------1 default OBC*, ethport1*, ethport2*, ethport3*, ethport4*, bridge_PVC1*, brigde_PVC2* 10 MyVLAN_A ethport2, bridge_PVC1
To retrieve an overview of the population of the unknown VLAN, execute following CLI command:
=>:eth bridge unknownvlan iflist Bridge Interface Untagged -------------------------------------bridge ethport3 no bridge bridge_PVC2 no
Frames received on a bridge port are checked for their VLAN ID and are only sent out on bridge ports that are member of the same VLAN. The table above shows that frames with VID 10 (representing VLAN A) are only transmitted on PVC1. Frames with any other VID are transmitted transparently on PVC2. It can be seen that all interfaces are also member of the default VLAN, and, as a result, also have connectivity with the Thomson Gateway.

The current configuration does not explicitly regulate the handling of unexpected frames that arrive on any of the bridge ports of the Thomson Gateway:
E-DOC-CTC-20080229-0004 v1.0
19
Chapter 5
Untagged frames: For example, to assign untagged frames to the default VLAN, execute following CLI command:
Tagged frames arriving on an incorrect interface: For example, to drop VLAN-tagged frames coming in on PVC1 if the VID differs from 10, execute following CLI command:
=>:eth bridge ifconfig intf=bridge_PVC1 ingressfiltering=enabled
20
E-DOC-CTC-20080229-0004 v1.0
Chapter 6
6 6.1
VLAN ID Translation Scenario Overview
Introduction
In this scenario, the Thomson Gateway is intended to forward VLAN-tagged Ethernet frames between the local Ethernet segment and the PVCs. The local VID of a frame received on a local interface is translated to a WAN-side VID before the frame is sent out on a WAN interface. Per interface and per VLAN ID, you have to be able to configure the translation from a local VID to a WAN-side VID. This scenario configures the Thomson Gateway as bridge with one PVC. Frames coming in on a local interface are checked on VLAN ID and are only forwarded on PVCs that are member of the same VLAN. Before the frame is sent out by the PVC, the VLAN ID is translated. For example, a local VID A is translated into a WAN-side VID Z. Following illustration shows the VLAN ID translation scenario:
Thomson Gateway
DSLAM
Z A 2
PVC1
VID 802.1p Local interface
WAN interface
Mechanisms
To set up this scenario, we use following mechanisms: VLAN awareness: the Ethernet bridge must be fully VLAN aware. As a result, the Ethernet bridge takes the VLAN tag in the header of received frames into account. VLANs: several VLANs are created on the Thomson Gateway. The configured VLAN membership of the interfaces defines to which PVC the frames must be forwarded. Extra tagging (stacked VLANs): this mechanism enables the use of a VID translation table. The VID translation table defines, per interface and per local VID, the mapping between the local VID and the WAN-side VID.
6.2
Following configuration steps have to be performed to configure the Thomson Gateway for this scenario: 1 Define which PVC must be used by configuring an ATM interface.
E-DOC-CTC-20080229-0004 v1.0
21
Chapter 6
2 3 4 5 6 7
Connect the ATM interface to the Ethernet bridge. Make the bridge VLAN aware. Define a VLAN for the local VLAN ID the Ethernet bridge has to handle. Define which interfaces are part of which VLAN. Enable the extra tagging mechanism and define the VID translation table. Save the configuration.
Before you start

=>:saveall

=>:atm ifadd intf=atm_PVC1 =>:atm ifconfig intf=atm_PVC1 dest=phone_PVC1 ulp=mac =>:atm ifattach intf=atm_PVC1

=>:eth bridge ifadd intf=bridge_PVC1 =>:eth bridge ifconfig intf=bridge_PVC1 dest=atm_PVC1 =>:eth bridge ifattach intf=bridge_PVC1
22
E-DOC-CTC-20080229-0004 v1.0
Chapter 6

From this moment on, all Ethernet frames arriving on the Ethernet bridge with a VLAN tag are only forwarded to interfaces configured as an explicit member of that VLAN.
Create the VLAN

To define the VLAN to be used, execute following CLI command:
Assign interfaces to the VLAN

The LAN-side bridge ports must be member of each VLAN from which they have to accept frames. In this example, we only enable bridge port 4 to receive VLAN-tagged frames from VLAN A. The untagged=disabled parameter avoids that the VLAN tag is stripped off when the frames are sent out on the interface. To put bridge port 4 in VLAN A, execute following CLI command:
=>:eth bridge vlan ifadd name=MyVLAN_A intf=ethport4 untagged=disabled
The VLAN membership of the WAN-side bridge ports defines to which PVCs the frames are forwarded. In this example, frames of VLAN A must be forwarded to PVC1. The untagged=enabled parameter means that the VLAN tag is stripped off when the frames are sent out on the interface. To put PVC1 in VLAN A, execute following CLI command:
=>:eth bridge vlan ifadd name=MyVLAN_A intf=bridge_PVC1 untagged=enabled
To remove PVC1 from the default VLAN, execute following CLI command:
=>:eth bridge vlan ifdelete name=default intf=bridge_PVC1
Configure VLAN translation

To enable the extra tagging mechanism, execute following CLI command:
=>:eth bridge ifconfig intf=bridge_PVC1 xtratagging=c-vlan
To map the local VID 10 (VLAN A) to the WAN-side VID 4010 (VLAN Z), execute following command:
=>:eth bridge xtratag add intf=bridge_PVC1 innervid=10 outervid=4010
E-DOC-CTC-20080229-0004 v1.0
23
Chapter 6

=>:saveall
Expected result
=>:eth bridge vlan iflist Vid Name Bridge interfaces (* = untagged) ------------------------------------1 default OBC*, ethport1*, ethport2*, ethport3*, ethport4* 10 MyVLAN_A ethport4, bridge_PVC1*
To display the VID translation table, execute following CLI command:

=>:eth bridge xtratag list Bridge Interface Inner VID Outer VID -----------------------------------------------------bridge bridge_PVC1 10 4010
Frames received on a bridge port are checked for their VLAN ID and are only sent out on bridge ports that are member of the same VLAN. The table above shows that frames with VID 10 (representing VLAN A) are only transmitted on PVC1. Using the extra tagging feature on PVC1, two tags are added: a tag with an inner VID 10 and a tag with an outer VID 4010. As the bridge port PVC1 is untagged member, the tag with the inner VID is stripped off. In the downstream direction, the translation table is consulted to assign frames with VID 4010 to VLAN A (VID 10).

The current configuration does not explicitly regulate the handling of unexpected frames that arrive on any of the bridge ports of the Thomson Gateway: Untagged frames: For example, to assign untagged frames to the default VLAN, execute following CLI command:
24
E-DOC-CTC-20080229-0004 v1.0
Chapter 6
Tagged frames arriving on an incorrect interface: For example, to drop VLAN-tagged frames coming in on bridge port 4 if the VID differs from 10, execute following CLI command:
=>:eth bridge ifconfig intf=ethport4 ingressfiltering=enabled
E-DOC-CTC-20080229-0004 v1.0
25
Chapter 7
7 7.1
VLAN User Priority Mapping to One PVC Scenario Overview
Introduction
In this scenario, the Thomson Gateway is intended to forward the incoming VLAN-tagged Ethernet frames to a single PVC. Based on the VLAN user priority available in the VLAN tag, high priority marked frames get priority when sending out the frames on the PVC. This scenario configures the Thomson Gateway as bridge with one PVC. Frames coming in on a local interface are checked on VLAN user priority. This priority is mapped to an internal priority class. Taking this internal priority class into account, the frames are sent out on the PVC. Following illustration shows the VLAN user priority mapping to one PVC scenario:
Thomson Gateway
DSLAM
A A B B C C
5 2 7 3 2 1 C 1 A 2 C
PVC1
3 A
B 5
VID
802.1p
WAN interface
Mechanisms
To set up this scenario, we use following mechanisms: Disabled VLAN awareness: Ethernet frames coming in on the Thomson Gateway have a VLAN tag in their header. However, the VLAN ID should not be taken into account. If the Ethernet bridge is VLAN aware, we have to define all VLANs that have to pass through the Thomson Gateway. Otherwise, unknown VLANs are dropped. Ingress classification: this mechanism ensures that an internal priority class is assigned to a received frame. In this scenario, the classification criterion has to be the VLAN user priority value. Priority queuing: even in bridging mode, we can make advantage of the powerful Thomson Gateway IPQoS implementation. By enabling IPQoS on the used PVC, we enable the queuing mechanism, which is active on ATM interface level. This queuing mechanism handles incoming frames according to their internal priority class. This way, frames passing the bridge can be treated in the same way as packets that come from the IPQoS framework.
26
E-DOC-CTC-20080229-0004 v1.0
Chapter 7
7.2
You must perform following configuration steps to configure the Thomson Gateway for this scenario: 1 2 3 4 5 6 Define which PVC must be used by configuring an ATM interface. Connect the ATM interface to the Ethernet bridge. Define that the bridge is not VLAN aware. Enable VLAN user priority mapping for incoming frames on the local interface. Enable QoS on the PVC to activate priority queuing. Save the configuration.
Before you start

=>:saveall

=>:atm ifadd intf=atm_PVC1 =>:atm ifconfig intf=atm_PVC1 dest=phone_PVC1 encaps=llc ulp=mac =>:atm ifattach intf=atm_PVC1
E-DOC-CTC-20080229-0004 v1.0
27
Chapter 7

=>:eth bridge ifadd intf=bridge_PVC1 =>:eth bridge ifconfig intf bridge_PVC1 dest=atm_PVC1 =>:eth bridge ifattach intf=bridge_PVC1

=>:eth Ageing Filter VLAN ... bridge config : 300 : no_WAN_broadcast : disabled
Enable VLAN priority mapping

In the scenario, we enable the mapping of the 802.1p user priority indication of VLAN-tagged frames to an internal priority class for Ethernet port 4. Several parameters of the :eth bridge ifconfig command are relevant to this scenario: prioconfig= overwrite: in this case, the medium the frame is received on is not taken into account to determine the internal priority class. Only the classification criterion is used. ipprec=disabled: in this case, the classification criterion is the 802.1p user priority of VLAN-tagged frames. This is the default parameter value. regenprio=20134567: in this case, the mapping between the 802.1p user priority indication and the regenerated user priority is defined as follows: 0 is mapped to 2, 1 is mapped to 0,..., 7 is mapped to 7. priority=0: in this case, the regenerated user priority 0 is assigned to untagged frames, which have no 802.1p user priority indication. This is the default parameter value. Execute following CLI command to enable this:
:eth bridge ifconfig intf=ethport4 prioconfig=overwrite regenprio=20134567
To verify the configuration of your bridge port, execute following CLI command:
=>:eth bridge iflist intf ethport4 ethport4 : dest : ethif4 Connection State: connected Retry: 10 Port: ethport4 PortNr: 4 PortState: forwarding Interface: down Multicast filter: disabled VLAN: Default VLAN: default Ingressfiltering: disabled Acceptvlanonly: disabled VLAN: Priority: overwrite IP Prec: disabled Priority: 0 Regen table: 20134567 RX bytes: 0 frames: 0 TX bytes: 0 frames: 0 dropframes: 0
28
E-DOC-CTC-20080229-0004 v1.0
Chapter 7
The mapping between the regenerated user priority and the internal priority class is fixed.
Enable QoS on the ATM interface

To enable the queuing mechanism, execute following CLI commands. The ATM interface on which we enable the queuing mechanism has to be detached and re-attached before the QoS changes take effect.
=>:ipqos config dest=phone_PVC1 state=enabled =>:eth bridge ifdetach intf=bridge_PVC1 =>:atm ifdetach intf=atm_PVC1 =>:atm ifattach intf=atm_PVC1 =>:eth bridge ifattach intf=bridge_PVC1
The mapping between the internal priority class and the IP QoS queue is fixed.

=>:saveall
Expected result
At this moment all frames containing a VLAN user priority indication are, priority-wise, bridged on one PVC. At the ingress side, frames received on a bridge port are checked for their VLAN user priority. This user priority is mapped to the regenerated user priority, which in its turn corresponds to an internal priority class. For example, VLAN user priority 1 is mapped to regenerated user priority 0, which corresponds to internal priority class 4. At the egress side, the internal priority class of a frame determines which queue is used. For example, frames with internal priority class 4 are put in the best-effort queue on PVC1.
E-DOC-CTC-20080229-0004 v1.0
29
Chapter 8
8 8.1
IP ToS Mapping for PVC Multiplexing Scenario Overview
Introduction
In this scenario, the Thomson Gateway is intended to forward the incoming VLAN-tagged Ethernet frames to a set of PVCs. Based on the ToS byte in the header of IP packets in the frames, it is decided to which PVC the frame must be forwarded. This scenario configures the Thomson Gateway as bridge with three PVCs. Frames coming in on a local interface are checked on the ToS byte in the IP header. This information is mapped to an internal priority class. Taking this internal priority class into account, the frames are multiplexed over the three PVCs. Following illustration shows the IP ToS mapping for ATM multiplexing scenario:
Thomson Gateway
7
PVC1
DSLAM
5
5 2 7 3 2 1
PVC2
2
PVC3
IP precedence
WAN interface
Mechanisms
To set up this scenario, we use following mechanisms: Disabled VLAN awareness: Ethernet frames coming in on the Thomson Gateway have a VLAN tag in their header. However, neither the VLAN ID nor the VLAN user priority indication should be taken into account. If the Ethernet bridge is VLAN aware, we have to define all VLANs that have to pass through the Thomson Gateway. Otherwise, unknown VLANs are dropped. Ingress classification: this mechanism ensures that an internal priority class is assigned to a received frame. In this scenario, the classification criterion has to be the IP precedence field in the header of an IP packet. ATM interface bundles: this mechanism makes it possible to forward frames over multiple PVCs based on the internal priority class assigned to each frame. Therefore, the priority mapping policy must be used to configure a priority range for each PVC. The ATM interface bundles feature is only available on selected products.
T
30
E-DOC-CTC-20080229-0004 v1.0
Chapter 8
8.2
You must perform following configuration steps to configure the Thomson Gateway for this scenario: 1 2 3 4 5 6 Define which PVCs must be used by configuring an ATM interface for each one of them. Create an ATM interface bundle to enable traffic multiplexing on multiple PVCs. Connect the ATM interface bundle to the Ethernet bridge. Define that the bridge is not VLAN aware. Enable IP TOS priority mapping for incoming frames on the local interfaces. Save the configuration.
Before you start

=>:saveall
Configure ATM Interfaces

=>:atm phonebook add name=phone_PVC1 addr=0.35 =>:atm phonebook add name=phone_PVC2 addr=0.36 =>:atm phonebook add name=phone_PVC3 addr=0.37
E-DOC-CTC-20080229-0004 v1.0
31
Chapter 8
To create, configure and connect ATM interfaces on top of these phonebook entries, execute following CLI commands:
=>:atm ifadd intf=atm_PVC1 =>:atm ifconfig intf=atm_PVC1 dest=phone_PVC1 encaps=llc ulp=mac =>:atm ifattach intf=atm_PVC1 =>:atm ifadd intf=atm_PVC2 =>:atm ifconfig intf=atm_PVC2 dest=phone_PVC2 encaps=llc ulp=mac =>:atm ifattach intf=atm_PVC2 =>:atm ifadd intf=atm_PVC3 =>:atm ifconfig intf=atm_PVC3 dest=phone_PVC3 encaps=llc ulp=mac =>:atm ifattach intf=atm_PVC3
Create an ATM interface bundle

To create an ATM interface bundle, execute following CLI commands:
=>:atm bundle add name=atm_MyBundle =>:atm bundle config name=atm_MyBundle policy=priority
To define which ATM interfaces are part of the ATM interface bundle, execute following CLI commands:
=>:atm bundle ifadd name=atm_MyBundle intf=atm_PVC1 =>:atm bundle ifadd name=atm_MyBundle intf=atm_PVC2 =>:atm bundle ifadd name=atm_MyBundle intf=atm_PVC3
To define which range of the internal priority classes is related to which PVC, execute following CLI commands:
=>:atm bundle ifconfig name=atm_MyBundle intf=atm_PVC1 state=enabled low=0 high=5 =>:atm bundle ifconfig name=atm_MyBundle intf=atm_PVC2 state=enabled low=6 high=9 =>:atm bundle ifconfig name=atm_MyBundle intf=atm_PVC3 state=enabled low=10 high=15
To attach the ATM interface bundle, execute following CLI command:

=>:atm bundle attach name=atm_MyBundle
32
E-DOC-CTC-20080229-0004 v1.0
Chapter 8
To verify your ATM interface bundle configuration, execute following CLI command:
=>:atm bundle list atm_MyBundle: Connection state : connected Retry: 10 Policy: priority Propagate: disabled TX requested bytes: 0 requested frames: 0 TX bytes: 0 frames: 0 RX bytes: 0 frames: 0 Index: 0 Interface: atm_PVC1 State: enabled Selector: 0-5 TX bytes: 0 frames: 0 RX bytes: 0 frames: 0 RX discarded bytes: 0 discarded frames: 0 Disconnects: 0 Index: 1 Interface: atm_PVC2 State: enabled Selector: 6-9 TX bytes: 0 frames: 0 RX bytes: 0 frames: 0 RX discarded bytes: 0 discarded frames: 0 Disconnects: 0 Index: 2 Interface: atm_PVC3 State: enabled Selector: 10-15 TX bytes: 0 frames: 0 RX bytes: 0 frames: 0 RX discarded bytes: 0 discarded frames: 0 Disconnects: 0

To connect the ATM interface bundle to the Ethernet bridge, execute following CLI command:
=>:eth bridge ifadd intf=bridge_MyBundle =>:eth bridge ifconfig intf=bridge_MyBundle dst=atm_MyBundle =>:eth bridge ifattach intf=bridge_MyBundle

=>:eth Ageing Filter VLAN bridge config : 300 : no_WAN_broadcast : disabled
Enable IP TOS priority mapping

In this scenario, we enable the mapping of the IP precedence field of IP packets within frames to an internal priority class for Ethernet port 4. Several parameters of the :eth bridge ifconfig command are relevant to this scenario: prioconfig=overwrite: in this case, the medium the frame is received on is not taken into account to determine the internal priority class. Only the classification criterion is used.
E-DOC-CTC-20080229-0004 v1.0
33
Chapter 8
ipprec=precedence: in this case, the classification criterion is the IP precedence value in the header of an IP packet. Execute following CLI command to enable this:
=>:eth bridge ifconfig intf=ethport4 prioconfig=overwrite ipprec=precedence
To verify the configuration of your bridge port, execute following CLI command:
=>:eth bridge iflist intf=ethport4 ethport4: dest : ethif4 Connection State: connected Retry: 10 Port: ethport4 PortNr: 4 PortState: forwarding Interface: down Multicast filter: disabled VLAN: Default VLAN: default Ingressfiltering: disabled Acceptvlanonly: disabled VLAN: Priority: overwrite IP Prec: precedence Priority: 0 Regen table: 01234567 RX bytes: 0 frames: 0 TX bytes: 0 frames: 0 dropframes: 0
Another example could be to check the IP DSCP marking, but only increase the internal class if the IP priority indicates a higher priority than the default port priority. Execute following CLI command to enable this:
=>:eth bridge ifconfig intf=ethport4 prioconfig=increase ipprec=dscp
The precedence mapping table can be configured, the DSCP mapping table is fixed.

=>:saveall
Expected result
To display the IP precedence mapping table, execute following CLI command:
=>:eth bridge config Ageing : 300 Filter : no_WAN_broadcast VLAN : disabled IPQoS precedence map for TOS: IP priority QoS internal class 0 4 1 7 2 9 3 11 4 13 5 14 6 15 7 15
At this moment, all packets will be mapped onto one of the PVCs in the ATM-bundle, based upon the priority indication of the IP header.
34
E-DOC-CTC-20080229-0004 v1.0
Chapter 8
At the ingress side, frames received on a bridge port are checked for their IP precedence value. This value is mapped to an internal priority class. For example, IP precedence value 1 is mapped to internal priority class 7. At the egress side, the internal priority class of a frame determines which PVC is used. For example, frames with internal priority class 7 are sent out on PVC2.
E-DOC-CTC-20080229-0004 v1.0
35
Visit us at:
www.thomson-broadband.com
Coordinates:
Thomson Telecom Prins Boudewijnlaan 47 B-2650 Edegem Belgium
Copyright
2008 Thomson. All rights reserved. The content of this document is furnished for informational use only, may be subject to change without notice, and should not be construed as a commitment by Thomson. Thomson assumes no responsibility or liability for any errors or inaccuracies that may appear in this document. The information contained in this document represents the current view of Thomson on the issues discussed as of the date of publication. Because Thomson must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Thomson, and Thomson cannot guarantee the accuracy of any information presented after the date of publication. This document is for informational purposes only. Thomson MAKES NO WARRANTIES, EXPRESS OR IMPLIED, AS TO THE INFORMATION IN THIS DOCUMENT. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

AppNote VLANBr

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

AppNote VLANBr

Transféré par

Droits d'auteur :

Formats disponibles

VLAN Bridging

March 2008 v1.0

Introduction.................................................................................. 3 Port-to-PVC Mapping .................................................................. 4

VLAN-Transparent Forwarding .................................................. 8

VLAN ID-Based Forwarding...................................................... 11

Unknown VLAN Forwarding .................................................... 16

VLAN User Priority Mapping to One PVC ............................... 26

IP ToS Mapping for PVC Multiplexing ..................................... 30

Thomson Gateway as bridge

Port-to-PVC Mapping Scenario Overview

Before you start

Configure ATM interfaces

Configure bridge ports

Make the bridge VLAN aware

Configure VLAN membership

Save the configuration

VLAN-Transparent Forwarding Scenario Overview

Before you start

Configure an ATM interface

Configure a bridge port

Disable VLAN awareness of the bridge

Save the configuration

VLAN ID-Based Forwarding Scenario Overview

Before you start

Configure ATM interfaces

Configure bridge ports

Make the bridge VLAN aware

Create the VLANs

Assign local interfaces to VLANs

Assign WAN interfaces to VLANs

Save the configuration

Optionally control unexpected frames

Unknown VLAN Forwarding Scenario Overview

Local interface VID 802.1p

Before you start

Configure ATM interfaces

Configure bridge ports

Make the bridge VLAN aware

Create the VLANs

Assign interfaces to the VLANs

Configure the unknown VID policy

Save the configuration

Optionally control unexpected frames

VLAN ID Translation Scenario Overview

VID 802.1p Local interface

Before you start

Configure an ATM interface

Configure a bridge port

Make the bridge VLAN aware

Create the VLAN

Assign interfaces to the VLAN

Configure VLAN translation

Save the configuration

To display the VID translation table, execute following CLI command:

Optionally control unexpected frames

VLAN User Priority Mapping to One PVC Scenario Overview

Before you start

Configure an ATM interface

Configure a bridge port

Disable VLAN awareness of the bridge

Enable VLAN priority mapping

Enable QoS on the ATM interface