VLAN ID-Based Forwarding

Transcription

1 VLAN ID-Based Forwarding 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-Based Forwarding. 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-Based Forwarding 2.1 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 5 A 2 B 7 B 3 C 2 C 1 A 5 PVC1 B 7 PVC2 A 2 C 1 B 3 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. 2.2 Practical Realization Configuration overview 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. 2 Connect the ATM interfaces to the Ethernet bridge. 3 Make the bridge VLAN aware. 2

4 4 Define a VLAN for each VLAN ID the Ethernet bridge has to handle. 5 Define which interfaces are part of which VLAN. 6 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 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 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 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_pvc2r 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 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 The untagged=disabled parameter avoids that the VLAN tag is stripped off when the frames are sent out on the interface. 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 11 MyVLAN_B 12 MyVLAN_C 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*, bridge_pvc1*, bridge_pvc2* 10 MyVLAN_A ethport4, bridge_pvc1 11 MyVLAN_B ethport4, bridge_pvc2 12 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 5

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