This Application Note applies to all Thomson DSL Gateways with R7.4 and higher.

Transcription

1 VLAN ID Translation Date: March 2008 Version: v1.0 Abstract: Applicability: Updates: This Application Notes describes the configuration of a specific feature of the Thomson Gateway: VLAN ID Translation. 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

2 Chapter 1 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. 1

3 2 VLAN ID Translation 2.1 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 A 5 A 2 Z 5 Z 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. 2.2 Practical Realization Configuration overview 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. 2

4 2 Connect the ATM interface to the Ethernet bridge. 3 Make the bridge VLAN aware. 4 Define a VLAN for the local VLAN ID the Ethernet bridge has to handle. 5 Define which interfaces are part of which VLAN. 6 Enable the extra tagging mechanism and define the VID translation table. 7 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 relay flush =>:ppp flush =>:eth flush =>:atm flush =>:atm phonebook flush =>: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 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 intf=bridge_pvc1 3

5 Make the bridge VLAN aware To enable the VLAN awareness of the Ethernet bridge, execute following CLI command: =>:eth bridge config vlan=enabled 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: =>:eth vlan add name=myvlan_a vid=10 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 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 4

6 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 default 10 MyVLAN_A To retrieve an overview of the population of the different VLANs, execute following CLI command: =>:eth bridge vlan iflist Vid Name Bridge interfaces (* = untagged) 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_pvc 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 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). 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 5

7 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 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 6

8

9 Visit us at: 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.