Sie sind auf Seite 1von 36

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


5.1 Scenario Overview ........................................................................................ 16

5.2 Practical Realization ..................................................................................... 16

6 VLAN ID Translation.................................................................. 21
6.1 Scenario Overview ........................................................................................ 21

6.2 Practical Realization ..................................................................................... 21

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


7.1 Scenario Overview ........................................................................................ 26

7.2 Practical Realization ..................................................................................... 27

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


8.1 Scenario Overview ........................................................................................ 30

8.2 Practical Realization ..................................................................................... 31

2 E-DOC-CTC-20080229-0004 v1.0
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.

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

2 Port-to-PVC Mapping

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

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

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

3 VLAN-Transparent Forwarding

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

A 2
A 5 B 7 C 1
B 7
A 2 B 3
B 3
C 2
PVC1
C 2

C 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 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 for it.
2 Connect the ATM interface to the Ethernet bridge.
3 Define that the bridge is not VLAN aware.
4 Save the configuration.

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

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 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 bridge config


Ageing : 300
Filter : no_WAN_broadcast
VLAN : disabled
...

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

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

=>:eth bridge config vlan=disabled

Save the configuration


To make your changes permanent, execute following CLI command:

=>: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 VLAN ID-Based Forwarding

4.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 5
A 2 A 2

B 7 PVC1

B 3 B 7 C 1
B 3
C 2
C 2
PVC2
C 1

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

E-DOC-CTC-20080229-0004 v1.0
11
Chapter 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

12 E-DOC-CTC-20080229-0004 v1.0
Chapter 4

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.

E-DOC-CTC-20080229-0004 v1.0
13
Chapter 4

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

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 Unknown VLAN Forwarding

5.1 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 5 A 5
A 2 A 2

PVC1

B 7 B 7 C 1
X 2
Y 3
C 1 Y 3 X 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 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.

16 E-DOC-CTC-20080229-0004 v1.0
Chapter 5

2 Connect the ATM interfaces to the Ethernet bridge.


3 Make the bridge VLAN aware.
4 Define a VLAN for each VLAN ID the Ethernet bridge has to handle in a specific way.
5 Define which interfaces are part of which VLAN.
6 Define an unknown VLAN for all VLAN IDs the Ethernet bridge has to handle transparently.
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 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 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

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

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 VLANs


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

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

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

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.

Save the configuration


To make your changes permanent, execute following CLI command:

=>:saveall

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

=>:eth vlan list


Vid Name
--- ----
1 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)
--- ---- --------------------------------
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.

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:

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:

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

For example, to accept only VLAN-tagged frames on bridge port 2, execute following command:

=>:eth bridge ifconfig intf=ethport2 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

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

20 E-DOC-CTC-20080229-0004 v1.0
Chapter 6

6 VLAN ID Translation

6.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 Z 5
A 2 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.

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

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

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

22 E-DOC-CTC-20080229-0004 v1.0
Chapter 6

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

E-DOC-CTC-20080229-0004 v1.0
23
Chapter 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
--- ----
1 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)
--- ---- --------------------------------
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).

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

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

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
25
Chapter 7

7 VLAN User Priority Mapping to One PVC

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

A 2 A 2
B 3 B 7
C 1 C 2
B 7 A 5

B 3 PVC1

C 2

C 1

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 Practical Realization

Configuration overview
You 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.
2 Connect the ATM interface to the Ethernet bridge.
3 Define that the bridge is not VLAN aware.
4 Enable VLAN user priority mapping for incoming frames on the local interface.
5 Enable QoS on the PVC to activate priority queuing.
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 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

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

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

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 bridge config


Ageing : 300
Filter : no_WAN_broadcast
VLAN : disabled
...

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

=>:eth bridge config vlan=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.

Save the configuration


To make your changes permanent, execute following CLI command:

=>: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 IP ToS Mapping for PVC Multiplexing

8.1 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 DSLAM

7 5
5

2 PVC1

7
3
3
PVC2
2

1 2 1
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 Practical Realization

Configuration overview
You must perform following configuration steps 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 Create an ATM interface bundle to enable traffic multiplexing on multiple PVCs.
3 Connect the ATM interface bundle to the Ethernet bridge.
4 Define that the bridge is not VLAN aware.
5 Enable IP TOS priority mapping for incoming frames on the local interfaces.
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
=>: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

Configure a bridge port


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

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 bridge config


Ageing : 300
Filter : no_WAN_broadcast
VLAN : disabled

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

=>:eth bridge config vlan=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.

Save the configuration


To make your changes permanent, execute following CLI command:

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

Das könnte Ihnen auch gefallen