vlan bridging -...

VLAN Bridging

Date: March 2008

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

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

Updates: 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

http://www.thomson-broadband.com

http://www.thomson-broadband.com

E-DOC-CTC-20080229-0004 v1.02

Contents

1 Introduction.................................................................................. 3

2 Port-to-PVC Mapping .................................................................. 4

2.1 Scenario Overview .......................................................................................... 4

2.2 Practical Realization ....................................................................................... 4

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

3.1 Scenario Overview .......................................................................................... 8

3.2 Practical Realization ....................................................................................... 8

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

4.1 Scenario Overview ........................................................................................ 11

4.2 Practical Realization ..................................................................................... 11

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



6 VLAN ID Translation.................................................................. 21



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



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



E-DOC-CTC-20080229-0004 v1.0 3

Chapter 1

1 Introduction

Thomson Gateway as bridgeTo 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.

VLANsThe 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 QoSEthernet 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 documentsFor 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.

4

Chapter 2

2 Port-to-PVC Mapping

2.1 Scenario Overview

IntroductionIn 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:

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

Thomson Gateway

PVC2

DSLAM

PVC1

Local interface WAN interface

E-DOC-CTC-20080229-0004 v1.0

Chapter 2

4 Define the necessary VLANs on the Ethernet bridge.

5 Define which interfaces are part of which VLAN.

6 Save the configuration.

Before you startBefore 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.

Configure ATM interfacesTo create a phonebook entry for each PVC that must be used, execute following CLI commands (the VPI/VCI values are indicative):

To create, configure and connect ATM interfaces on top of these phonebook entries, execute following CLI commands:

Configure bridge portsTo connect the ATM interfaces to the Ethernet bridge, execute following CLI commands:

=>: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

=>:atm phonebook add name=phone_PVC1 addr=0.35=>:atm phonebook add name=phone_PVC2 addr=0.36

=>:atm ifadd intf=atm_PVC1=>:atm ifconfig intf=atm_PVC1 dest=phone_PVC1 encaps=llc 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

: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 5

6

Chapter 2

Make the bridge VLAN awareTo enable the VLAN awareness of the Ethernet bridge, execute following CLI command:

Create a VLANTo define the VLAN to be used, execute following CLI command:

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 membershipConfigure 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:

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:

Save the configurationTo make your changes permanent, execute following CLI command:

Expected resultTo display the list of VLANs on the Ethernet bridge, execute following CLI command:

=>:eth bridge config vlan=enabled

=>:eth vlan add name=MyVLAN_A vid=10 addrule=disabled

=>:eth bridge vlan ifadd name=MyVLAN_A intf=ethport4=>:eth bridge vlan ifdelete name=default intf=ethport4

=>:eth bridge vlan ifadd name=MyVLAN_A intf=bridge_PVC2=>:eth bridge vlan ifdelete name=default intf=bridge_PVC2

=>:saveall

=>:eth vlan listVid Name--- ----1 default10 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:

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.

=>:eth bridge vlan iflistVid Name Bridge interfaces (* = untagged)--- ---- --------------------------------1 default OBC*, ethport1*, ethport2*, ethport3*, bridge_PVC1*10 MyVLAN_A ethport4*, bridge_PVC2*

E-DOC-CTC-20080229-0004 v1.0 7

8

Chapter 3

3 VLAN-Transparent Forwarding


IntroductionIn 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:

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



1 Define which PVC must be used by configuring an ATM interface for it.

2 Connect the ATM interface to the Ethernet bridge.

3 Define that the bridge is not VLAN aware.


Thomson Gateway DSLAM

PVC1

A 5

A 2

B 7

B 3

C 2

C 1

A 5

A 2

B 7

B 3

C 2

C 1

VID 802.1p WAN interface

E-DOC-CTC-20080229-0004 v1.0

Chapter 3






Configure an ATM interfaceTo create a phonebook entry for the PVC that must be used, execute following CLI command (the VPI/VCI value is indicative):

To create, configure and connect an ATM interface on top of this phonebook entry, execute following CLI commands:

Configure a bridge portTo connect the ATM interface to the Ethernet bridge, execute following CLI commands:

Disable VLAN awareness of the bridgeBy default, the bridge is already not VLAN aware.

To check the current status of the Ethernet bridge, execute following CLI command:




=>:saveall

=>:atm phonebook add name=phone_PVC1 addr=0.35


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

=>:eth bridge configAgeing : 300Filter : no_WAN_broadcastVLAN : disabled...

E-DOC-CTC-20080229-0004 v1.0 9

10

Chapter 3

If necessary, disable the VLAN awareness of the Ethernet bridge executing following CLI command:


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

=>:eth bridge config vlan=disabled

=>:saveall

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.

E-DOC-CTC-20080229-0004 v1.0

Chapter 4

4 VLAN ID-Based Forwarding


IntroductionIn 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:


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.






Thomson Gateway

PVC2

DSLAM

PVC1

A 5

A 2

B 7

B 3

C 2

C 1

A 5A 2

B 3 C 1

VID 802.1p

B 7

C 2

WAN interface

E-DOC-CTC-20080229-0004 v1.0 11

12

Chapter 4

4 Define a VLAN for each VLAN ID the Ethernet bridge has to handle.









To create, configure and connect the ATM interfaces on top of the phonebook entries, execute following CLI commands:





=>:saveall




=>: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

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 VLANsTo define the VLANs to be used, execute following CLI commands:

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 VLANsThe 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:

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

=>: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

=>: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

14

Chapter 4




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 framesThe 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:

For example, to accept only VLAN-tagged frames on bridge port 4, execute following 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:

=>:saveall

=>:eth vlan listVid Name--- ----1 default10 MyVLAN_A11 MyVLAN_B12 MyVLAN_C

=>:eth bridge vlan iflistVid Name Bridge interfaces (* = untagged)--- ---- --------------------------------1 default OBC*, ethport1*, ethport2*, ethport3*, ethport4*, bridge_PVC1*,

bridge_PVC2*10 MyVLAN_A ethport4, bridge_PVC111 MyVLAN_B ethport4, bridge_PVC212 MyVLAN_C ethport4, bridge_PVC2

=>:eth bridge ifconfig intf=ethport4 vlan=default

=>:eth bridge ifconfig intf=ethport4 acceptvlanonly=enabled

=>:eth bridge ifconfig intf=bridge_PVC1 ingressfiltering=enabled

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

16

Chapter 5

5 Unknown VLAN Forwarding


IntroductionIn 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:

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





A 5A 2

Y 3

X 2

C 1

PVC1

A 5A 2

VID 802.1p

PVC2

Y 3 C 1B 7

X 2

B 7

Local interface WAN interface

E-DOC-CTC-20080229-0004 v1.0

Chapter 5



4 Define a VLAN for each VLAN ID the Ethernet bridge has to handle in a specific way.


6 Define an unknown VLAN for all VLAN IDs the Ethernet bridge has to handle transparently.








To create, configure and connect the ATM interfaces on top of these phonebook entries, execute following CLI commands:




=>:saveall


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


E-DOC-CTC-20080229-0004 v1.0 17

18

Chapter 5



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 VLANsTo define the VLAN that the Ethernet bridge has to handle in a specific way, execute following CLI commands:


Assign interfaces to the VLANsThe 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:

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:


Configure the unknown VID policyThe 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.





=>:eth bridge vlan ifadd name=MyVLAN_A intf=ethport2 untagged=disabled

=>:eth bridge vlan ifadd name=MyVLAN_A intf=bridge_PVC1 untagged=disabled

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:

The ‘untagged=disabled’ parameter avoids that the VLAN-header is stripped off when the frames are sent out on the interface.


Expected resultTo display the list of known VLANs on the Ethernet bridge, execute following CLI command:


To retrieve an overview of the population of the unknown VLAN, execute following CLI command:

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.


=>:eth bridge unknownvlan ifadd intf=ethport3 untagged=disabled=>:eth bridge unknownvlan ifadd intf=bridge_PVC2 untagged=disabled

=>:saveall


=>:eth bridge vlan iflistVid Name Bridge interfaces (* = untagged)--- ---- --------------------------------1 default OBC*, ethport1*, ethport2*, ethport3*, ethport4*, bridge_PVC1*,

brigde_PVC2*10 MyVLAN_A ethport2, bridge_PVC1

=>:eth bridge unknownvlan iflistBridge Interface Untagged

--------------------------------------bridge ethport3 nobridge bridge_PVC2 no

E-DOC-CTC-20080229-0004 v1.0 19

20

Chapter 5

Untagged frames:




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


E-DOC-CTC-20080229-0004 v1.0

Chapter 6

6 VLAN ID Translation


IntroductionIn 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:


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.



1 Define which PVC must be used by configuring an ATM interface.


A 5A 2

PVC1

Z 5Z 2

VID 802.1p Local interface WAN interface

E-DOC-CTC-20080229-0004 v1.0 21

22

Chapter 6



4 Define a VLAN for the local VLAN ID the Ethernet bridge has to handle.


6 Enable the extra tagging mechanism and define the VID translation table.













=>:saveall




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 VLANTo define the VLAN to be used, execute following CLI command:


Assign interfaces to the VLANThe 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:

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:

To remove PVC1 from the default VLAN, execute following CLI command:

Configure VLAN translationTo enable the extra tagging mechanism, execute following CLI command:

To map the local VID 10 (VLAN A) to the WAN-side VID 4010 (VLAN Z), execute following command:



=>:eth bridge vlan ifadd name=MyVLAN_A intf=ethport4 untagged=disabled

=>:eth bridge vlan ifadd name=MyVLAN_A intf=bridge_PVC1 untagged=enabled

=>:eth bridge vlan ifdelete name=default intf=bridge_PVC1

=>:eth bridge ifconfig intf=bridge_PVC1 xtratagging=c-vlan

=>:eth bridge xtratag add intf=bridge_PVC1 innervid=10 outervid=4010

E-DOC-CTC-20080229-0004 v1.0 23

24

Chapter 6




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

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


Untagged frames:



=>:saveall


=>:eth bridge vlan iflistVid Name Bridge interfaces (* = untagged)--- ---- --------------------------------1 default OBC*, ethport1*, ethport2*, ethport3*, ethport4*10 MyVLAN_A ethport4, bridge_PVC1*

=>:eth bridge xtratag listBridge Interface Inner VID Outer VID

------------------------------------------------------bridge bridge_PVC1 10 4010



E-DOC-CTC-20080229-0004 v1.0

Chapter 6


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

26

Chapter 7

7 VLAN User Priority Mapping to One PVC


IntroductionIn 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:


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.


A 5

A 2

B 7

B 3

C 2

C 1

PVC1

A 5

A 2B 7B 3

C 2C 1

VID 802.1p WAN interface

E-DOC-CTC-20080229-0004 v1.0

Chapter 7


Configuration overviewYou must perform following configuration steps to configure the Thomson Gateway for this scenario:

1 Define which PVC must be used by configuring an ATM interface.



4 Enable VLAN user priority mapping for incoming frames on the local interface.

5 Enable QoS on the PVC to activate priority queuing.












=>:saveall



E-DOC-CTC-20080229-0004 v1.0 27

28

Chapter 7





Enable VLAN priority mappingIn 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:

To verify the configuration of your bridge port, execute following CLI command:

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

=>:eth bridge configAgeing : 300Filter : no_WAN_broadcastVLAN : disabled...


:eth bridge ifconfig intf=ethport4 prioconfig=overwrite regenprio=20134567

=>:eth bridge iflist intf ethport4ethport4 : dest : ethif4

Connection State: connected Retry: 10Port: ethport4 PortNr: 4 PortState: forwarding Interface: downMulticast filter: disabledVLAN: Default VLAN: default Ingressfiltering: disabled Acceptvlanonly: disabledVLAN: Priority: overwrite IP Prec: disabled Priority: 0 Regen table: 20134567RX bytes: 0 frames: 0TX bytes: 0 frames: 0 dropframes: 0

E-DOC-CTC-20080229-0004 v1.0

Chapter 7

Enable QoS on the ATM interfaceTo 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.


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

The mapping between the regenerated user priority and the internal priority class is fixed.

=>: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

E-DOC-CTC-20080229-0004 v1.0 29

30

Chapter 8

8 IP ToS Mapping for PVC Multiplexing


IntroductionIn 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:


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.

Thomson Gateway

PVC2

PVC3

DSLAM

PVC1

5

2

7

3

2

1

IP precedence

5

2

7

3

21

WAN interface

T

The ATM interface bundles feature is only available on selected products.

E-DOC-CTC-20080229-0004 v1.0

Chapter 8


Configuration overviewYou must perform following configuration steps to configure the Thomson Gateway for this scenario:


2 Create an ATM interface bundle to enable traffic multiplexing on multiple PVCs.

3 Connect the ATM interface bundle to the Ethernet bridge.


5 Enable IP TOS priority mapping for incoming frames on the local interfaces.







Configure ATM InterfacesTo create a phonebook entry for each PVC that must be used, execute following CLI commands (the VPI/VCI values are indicative):




=>:saveall

=>: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

32

Chapter 8

To create, configure and connect ATM interfaces on top of these phonebook entries, execute following CLI commands:

Create an ATM interface bundleTo create an ATM interface bundle, execute following CLI commands:

To define which ATM interfaces are part of the ATM interface bundle, execute following CLI commands:

To define which range of the internal priority classes is related to which PVC, execute following CLI commands:

To attach the ATM interface bundle, execute following CLI command:




=>:atm bundle add name=atm_MyBundle=>:atm bundle config name=atm_MyBundle policy=priority

=>: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

=>: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

=>:atm bundle attach name=atm_MyBundle

E-DOC-CTC-20080229-0004 v1.0

Chapter 8

To verify your ATM interface bundle configuration, execute following CLI command:

Configure a bridge portTo connect the ATM interface bundle to the Ethernet bridge, execute following CLI command:




Enable IP TOS priority mappingIn 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.

=>:atm bundle list

atm_MyBundle: Connection state : connectedRetry: 10 Policy: priority Propagate: disabledTX requested bytes: 0 requested frames: 0TX bytes: 0 frames: 0RX bytes: 0 frames: 0Index: 0 Interface: atm_PVC1 State: enabled Selector: 0-5

TX bytes: 0 frames: 0RX bytes: 0 frames: 0RX discarded bytes: 0 discarded frames: 0Disconnects: 0

Index: 1 Interface: atm_PVC2 State: enabled Selector: 6-9TX bytes: 0 frames: 0RX bytes: 0 frames: 0RX discarded bytes: 0 discarded frames: 0Disconnects: 0

Index: 2 Interface: atm_PVC3 State: enabled Selector: 10-15TX bytes: 0 frames: 0RX bytes: 0 frames: 0RX discarded bytes: 0 discarded frames: 0Disconnects: 0

=>:eth bridge ifadd intf=bridge_MyBundle=>:eth bridge ifconfig intf=bridge_MyBundle dst=atm_MyBundle=>:eth bridge ifattach intf=bridge_MyBundle

=>:eth bridge configAgeing : 300Filter : no_WAN_broadcastVLAN : disabled


E-DOC-CTC-20080229-0004 v1.0 33

34

Chapter 8

ipprec=precedence: in this case, the classification criterion is the IP precedence value in the header of an IP packet.


To verify the configuration of your bridge port, execute following CLI command:

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.



Expected resultTo display the IP precedence mapping table, execute following CLI command:

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.

=>:eth bridge ifconfig intf=ethport4 prioconfig=overwrite ipprec=precedence

=>:eth bridge iflist intf=ethport4ethport4: dest : ethif4

Connection State: connected Retry: 10Port: ethport4 PortNr: 4 PortState: forwarding Interface: downMulticast filter: disabledVLAN: Default VLAN: default Ingressfiltering: disabled Acceptvlanonly: disabledVLAN: Priority: overwrite IP Prec: precedence Priority: 0 Regen table: 01234567RX bytes: 0 frames: 0TX bytes: 0 frames: 0 dropframes: 0

=>:eth bridge ifconfig intf=ethport4 prioconfig=increase ipprec=dscp

The precedence mapping table can be configured, the DSCP mapping table is fixed.

=>:saveall

=>:eth bridge configAgeing : 300Filter : no_WAN_broadcastVLAN : disabledIPQoS precedence map for TOS:

IP priority QoS internal class0 41 72 93 114 135 146 157 15

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.

http:\\www.thomson-broadband.com

vlan bridging -...

Documents