Alcatel-Lucent University Antwerp 1 University VLAN forwarding modes and IB Alcatel-Lucent University Antwe University 7302-7330/5523 operator part 1 section D
VLAN setup and IB7302-7330/5523 operator part 1 section D
Alcatel-Lucent University Antwerp
University
During class please switch off your mobile, pager or other that may
interrupt.
Entry level requirements:
Understand how the RB-VLAN is behaving
Creation of a RB-VLAN via AWS and CLI
The RB-VLAN association on an ATM over xDSL port
The RB-VLAN association on an ETH over xDSL Port
Application purpose of the RB-VLAN
*
NT
x/Eth
x/Eth
FW Engine
*
Decision
ANT
Different forwarding modes are supported in order to make it fit
into different network models of different operators.
If the DSLAMs are mainly connected to a bridged Metro Ethernet
network, the MAC scalability may become an issue when only layer 2
forwarding is done in the DSLAM.
In that case the MAC addresses of all end-user terminals will have
to be learned in the Metro-Ethernet network, while the MAC tables
of bridges are quite limited. In that case, it will probably be
better to use the layer 2+ or L3 forwarding function of the
ISAM.
However, if IP routers are used in the Metro Ethernet Network close
to the DSLAMs, MAC scalability will not be an issue, and layer 2
forwarding in the DSLAM may be an interesting option, because in
general layer 2 means less configuration effort. With 7302 ISAM,
operators have the flexibility to choose the forwarding mode which
best fits in their network.
In general, the previous layer 2 and layer 3 forwarding functions
are an overkill for network-VPN services towards business
customers, given the number of connections to the same VPN from one
DSLAM will be mostly only one, or only very few connections per
VPN. In such cases, the VLAN cross-connect mode of the ISAM is much
more appropriate for these business users:
less configuration effort,
Alcatel-Lucent University Antwerp
encapsulation at CPE must include Ethernet
Phys layer
Anything
In case the 7302 ISAM performs L2 forwarding, it means that the
internal forwarding is basically done on layer 2 information. The
layer 2 is Ethernet, including the concept of VLANs.
*
the intelligent bridging (IB): one (or more) circuits per
VLAN
Forwarding based upon MAC addresses and VLAN
the cross-connect (CC): one (or more) VLANs per circuit
Forwarding based upon
User side: PVC for ATM or DSL port for EFM
Network side: Single or stacked VLAN tag
The ISAM 7302 provides a special Layer 2 behavior that results from
being deployed in an access environment. I.e. it supports the
'cross connect mode' and it supports the 'Intelligent Bridging
mode'.
In cross-connect mode, a particular VLAN-id is associated to one
user connection only.
In intelligent bridging mode, multiple user connections can be
associated with each virtual LAN.
*
IWF
In general the aggregation function implemented by means of the
Service Hub, on the NT, behaves as a standard bridge. A few extra
features makes that the Service Hub can be configured to behave in
the IB mode or XC mode.
The Service Hub (Ethernet Switch) is composed of:
1) the Ethernet transceiver function
2) the Forwarding Engine, providing the Ethernet L2 switching
function
3) the switch, providing network (trunk) ports, cascade (trunk)
ports, user Ethernet ports, ISM1 port, NT Ethernet port, Out-band
management Ethernet port and ASAM Ethernet ports.
It is the IWF (Interworking Function) on the LT board that serves
as the ATM to Ethernet interworking device.
In the upstream direction (ingress ATM PVC port), the IWF on the
LTs receives traffic on the ATM PVC ports, reassembles the Ethernet
frames from the ATM cells and forwards them towards the E-MAN
network.
In the downstream direction the network interface of the Service
Hub receives the Ethernet frames and forwards them towards the
correct egress port on the Service Hub. Once the Ethernet frame is
received on the ingress Ethernet port of the IWF, the frame is
forwarded towards the correct user logical port where the received
Ethernet frames are segmented into ATM cells and forwarded toward
the correct ATM PVC ports.
The Service Hub and the IWFs on the LTs behave (as much as
possible) as two independent Layer 2 systems: they both will learn
and age independently on MAC addresses.
*
E-MAN
Network
Eth
GE
Eth
FE/GE
Switch
Eth
FE/GE
Eth
PHY
Switch
The customer’s CPE is connected to the ASAM-Core with an ATM
interface. It is the IWF on the LT that provides the interworking
between the ATM and the Ethernet/VLAN technology.
The Service Hub will behave as a standard bridge with some
enhancements and perform layer 2/Ethernet forwarding
The layer 2 access offered via the IWF does not offer the same
capabilities as the traditional ATM Layer 2 access offered by the
ASAM.
A traditional ATM Layer 2 access network is transparent for
everything on top of ATM and as such supports many more frame
encapsulation techniques at the CPE.
The proposed E-MAN/ATM layer 2 access supports only CPEs using
Ethernet over ATM, encapsulated by AAL5 and RFC2684 “bridged”
In the case that the 7302 ISAM performs layer 2 forwarding and the
Ethernet switches in between (EMAN) are working as bridges. In that
case the Ethernet L2 environment is terminated in the IP edge
(typically the BRAS).
Alcatel-Lucent University Antwerp
No guaranteed delivery of frames
A bridge learns MAC addresses
Flooding occurs when destination MAC address is broadcast,
multicast or unknown, :
“If you do not know, send it to everybody’
If the destination MAC address has been learned, the frame is
forwarded to the indicated interface
STP = Spanning Tree Protocol
Learning: relay disabled, learning enabled
Forwarding: relay enabled, learning enabled
Blocking: relay disabled
*
Broadcast frames (ARP, PPPoE-PADI…) forwarded to
all users & flooding to all ports.
MAC-address of a user is exposed to other users
Broadcast storms
*
Restrictions on services and revenues:
IP edge device has no info on the access line
So not possible to limit the # of sessions per access line
User-to-user communication possible without passing the BRAS
NOT FIT FOR USE IN PUBLIC NETWORKS
Scalability:
Broadcast storms
Broadcast frames are flooded over the entire aggregation network .
This generates an important amount of traffic, that can result in
service degradation or denial of service
Bridges have to learn MAC-addresses of all devices connected to the
network
Security
Broadcast frames (ARP, PPPoE - PADI, …) are forwarded to all
users
MAC-address of a user is exposed to other users
Customer segregation
customers are identified by MAC-address, and MAC-addresses are not
guaranteed unique
undesirable & unstable behaviour: user B gets traffic destined
to user A and vice versa.
PADI = PPPoE Active Discovery Initiation packet (which is
broadcasted)
Alcatel-Lucent University Antwerp
Multiple users connected to 1 VLAN ID
IB-VLAN has:
1 or more user logical ports, subtending ports or user Ethernet
ports
1 or more network ports
Internet
E-MAN
Network
ISP2
ISP1
Routing to the correct ISP is based on the VLAN-id
Routing to the correct ISP is done based on user-id and password in
the BRAS
E-MAN
Network
IP
Internet
ISP
Corporate
Note: Tagged frames not supported for IB if Rel. <3.1
BAS
In case of Intelligent bridging multiple users are connected to the
same VLAN, or in other words we have aggregation at DSLAM level
within a VLAN.
In the figure at the left we see multiple VLAN bridges supported in
1 DSLAM, to connect to different SPs (wholesale). Each SP is
connected to the DSLAM with a specific VLAN-ID. The user ports are
connected to the VLAN of their corresponding SP. Multiple user
ports can be associated to a single VLAN-ID.
Users 2 and 5 are connected to ISP1 VLAN
Users 1, 3 & 4 are connected to the ISP2 VLAN.
The MAC address lookup is performed in the forwarding table of the
respective VLAN. With the principle that we have 1 VLAN ID per
{IP-edge-DSLAM} pair this means that in each Ethernet switch the SP
has its own forwarding table.
*
Why VLAN Translation (customer vlan to network vlan)
Wholesale per service
Drivers: VDSL and Eth offer more BW, so it makes sense to wholesale
this “in pieces” rather than the complete DSL line as a whole
Consequences: Model with VLANs on DSL line; behaviour equivalent to
multi-VC model on ATM/ADSL
VLAN per service and per provider in the aggregation network
Service provider is free to choose CPE configuration, but VLANs in
aggregation network are under control of ILEC
Ultimately 1 subscriber (1 line) may have to support 2 HSIA
services or 2 video services from different service
providers.
There are many operators who base their network architecture on one
PVC per service when connecting ADSL subscribers. Once those
operators start deploying VDSL, they are immediately confronted
with the issue, that their is no similar approach for EFM
interfaces. That’s why we have introduced VLAN Translation.
*
Special layer 2 behavior needed in an access environment
IB with VLAN tagging
Intelligent Bridge (IB) means
Frames from a user always sent towards the network
No user to user communication
prevent broadcast traffic from escalating
avoid broadcast or flooding to all users
secure MAC-address learning within a VLAN
avoid MAC-address duplication over multiple ports
protocol filtering
may lead to a frame being forwarded, sent to a host processor,
discarded or forwarded & sent to a host processor
In a standard bridge all ports are treated equally. The special
thing about Intelligent Bridging is that it makes a distinction
between network ports and user ports.
With Intelligent Bridging, frames received from a user will always
be sent towards the network and never to another user. All traffic
received from a user interface is forwarded only on the uplink, and
never to other users. This avoids that a user's MAC-address is
exposed to other users; and also assures that user's traffic is
passing through the IP edge point where it can be charged
for.
Unicast frames: user-to-user communication is not permitted.
Broadcast and multicast frames from a user are only forwarded to
the interface towards the network and not to all other users.
A second difference with standard bridging is the prevention of
broadcast storms:
In a standard bridge, a broadcast frame will be sent to all ports
in a particular VLAN. In case of a Intelligent Bridging this is no
longer true.
Depending on the type of broadcast frame (depending on the protocol
above Ethernet e.g. DHCP) the treatment will be different. Each
protocol will deal with the restriction of Intelligent Bridging in
a different way. In all cases a broadcast to all users is
avoided.
E.g. Broadcast as a consequence of flooding (when the MAC DA is
unknown) or in case of multicast.
Another difference with standard bridging is the way on how MAC
addresses are learned: protection is built in to avoid the use
within one particular VLAN of the same MAC address over multiple
ports.
*
Problem:
ISAM
VLAN1
BR
ISAM
Ethernet
In the two former slides we saw how user to user communication is
avoided inside the ISAM. But it is also important to mention that a
VLAN must be unique between an [IP-edge-ISAM]-pair in the Ethernet
network to support the Intelligent Bridging feature. Take e.g. the
network configuration shown in the figure above, where 2 ISAMs with
same VLAN are connected to the IPedge via the EMAN network through
a single VLAN. Or in other words a single VLAN exists between
ISAM1, ISAM2, and the IP-edge).
In this case, the Ethernet switch learns all user MAC addresses and
if user A can obtain the MAC address of user C, then user A can
send traffic directly to user C without going to the IP-edge. This
is not acceptable: in Intelligent Bridging mode no direct user to
user communication is allowed in the network.
*
Broadcast messages & flooding US
Upstream BC frames & flooding only forwarded towards network
port(s) within a VLAN
1 VLAN per IP-edge
Ethernet
BRAS
BR
Blocking user to user communication at L2
The principle is to avoid that 2 users connected to the same ISAM
will communicate with each other directly at L2. In this case, when
user A sends message with destination MAC-address B, message is
sent to the uplink, not to user B.
In case of PPP this is not an issue, since all messages coming from
the DSL users will have destination MAC-address = MAC-address of
the BRAS
The objective is that all traffic passes a L3 box. The motivation
is twofold:
Security:
If direct user-to-user communication at L2 would be allowed, this
would give malicious users an easy way to find out the MAC address
of other users, and then try to take it over. Note: blocking
duplicate MAC-addresses will solve most of it, but if the malicious
user is waiting until the MAC-address has aged, and then tries to
take it for himself, he blocks the other user.
Accounting for traffic:
*
For some applications forwarding of BC is “needed”
Solution: Make BC flooding / BC discarding a configurable option
per VLAN
ISAM
Ethernet
BRAS
PC
CPE
ISAM
PC
CPE
PC
CPE
In a normal bridge when a message is received with a destination
MAC-address not yet in the self-learning table, the message is
broadcast to all the other interfaces.
Also broadcast messages are flooded to all interfaces
In an Intelligent bridge you want to avoid that in the downstream,
messages are unintentionally distributed to all users. Therefore
you need to put mechanisms in place that together with the systems
set up in the upstream, will inhibit BC messages to be sent to all
users and avoid the flooding of messages with unknown MAC DA to all
users.
*
intelligent bridging enhancements implemented on ISAM
LT and SHUB have
aging timers are configurable [10...1000000] sec
Recommended default value is 300 sec
The Service Hub and the LTs autonomously learn MAC addresses. They
also autonomously age on these MAC addresses. Aging timers are
configurable. The idea is that the Service Hub is configured with
the same aging timer than the one of the IWF of the LT. This is
needed to avoid conflicts, e.g. when the MAC address is aged on the
Service Hub, then the Service Hub could learn the MAC address on
another interface with unpredictable behavior as a
consequence.
Once a MAC address is aged, then no downstream communication is
possible until the address is learned again in the upstream
direction.
So it’s important that the MAC ageing time is properly configured,
otherwise data-plane connectivity may be lost between the network
and the ISAM end-users (nightly SW download on STB, incoming VoIP
calls, …)
In case of PPPoE traffic the MAC aging time can be kept small,
because PPP has a built-in keep-alive mechanism
*
only in the upstream - when initiated from user logical port
Self-learning can be disabled per user logical port.
In case of self-learning, limiting number of MAC addresses is
possible.
LT
NO selflearning
x
y
z
MacA
MacB
MacC
*
Self-learning implemented for both upstream and downstream
Discard all user unicast frames with MAC DA known on an ASAM or
subtending port
No user to user communication
Learning of Source Mac@ within VLAN
LT
LT
An interface can only communicate with its mapping ports
ASAM links
8 Network
User links
subtending link
*
block user to user communication on the service hub
user links
subtending links
NT
LT
LT
E-MAN
It is possible that a VLAN used to transport user frames will
contain ASAM/ subtending / user interface(s) and a network
interface(s) or even more ASAM interfaces and subtending interfaces
…. Possibly also both an ASAM and a subtending interface can be
present in the same VLAN. The question arrises how we prevent user
to user communication within the same VLAN
The blocking of user-to user communication on the Service Hub is
provided by port mapping
This way we allow L2 bi-directional communication with supporting
tagged frames (within the same VLAN) only between network ports and
ASAM ports, between network ports and subtending ports, between
network ports and user ports, between the controller port and each
ASAM port and between the controller and the network ports and
subtending ports.
The drawing in the slide gives you the different possible links and
the flooding strategy (Layer2) of the frames.
The handling of control protocol frames (Radius, VBAS, IGMP, ARP
and DHCP) and internal communication at a layer higher than the MAC
layer is not in the scope of the rules explained hereafter.
Frames received over a network interface: can be (layer 2)
forwarded by the Service Hub to the ASAM, the user, the subtending,
and the control interfaces. In PPPoE demo, ISM1 related ports are
at the same position as network interface.
Frames received over an ASAM interface: can be forwarded to the
network interfaces and to the control interface.
Frames received over a subtending interface: can be forwarded to
the network interfaces or to the control interface.
Frames received over a user interface: can be forwarded to the
network interfaces or to the control interface.
*
Only user to network allowed
The ISAM only allows user to network communication in the
upstream,
Blocked on the same LT by the IWF
Blocked by the port mapping configuration on the SHUB (see
later)
This is valid for all cases, i.e. Broadcast (BC), Unknown MAC
Destination Address and Known MAC Destination address.
unicast frames with unknown destination MAC addresses are flooded
to the networkside.
no user to user communication within the LIM
no flooding from user to user port
broadcast frames are flooded towards the NW port …
frames with known destination MAC addresses aren’t forwarded to
user ports, but to the networkside
No user to user communication within the LT
*
Broadcast control configurable per VLAN in IB mode
Broadcast from Network to User only allowed if enabled by the
operator, per VLAN in IB mode.
For the ‘unknown MAC DA case’, the LT will not forward the frames
to the users.
In case of a known MAC DA, all frames are forwarded.
unicast frames with known MAC DA are forwarded to the appropriate
logical user port
unicast frames with unknown MAC DA are discarded
No flooding from NW port to user port
No user to user communication
By default broadcast as a consequence of flooding, which happens in
case of standard bridging when the MAC DA is unknown or in case of
multicast, is avoided with intelligent bridging.
Sheet1
<--
<--
BC -->
Duplicate MAC-address learning
Traffic from duplicate MAC-address in separate DSLAM, can be
distinguished as separate flows in the Ethernet switches of the
aggregation Network, when different VLAN id per DSLAM is used
Mac A
Mac A
Problem:
?
Mac A
If a user on line x is using a certain MAC-address and a second
user on a different line y is trying to connect with the same
MAC-address, a mechanisme should be there so that that
MAC-addresses will only appear once in the (filtering db) learning
table of that VLAN.
If this would not be done, then the MAC-address would be
overwritten in the bridge's learning table, such that traffic is
forwarded either to user A or B in a rather unpredictable way. so
this feature allows to guarantee uniqueness of MAC-addresses in the
aggregation network.
In the 7302 ISAM specific rules are implemented making sure that
the MAC-address will only be learned once, this is what they call
secure MAC-address learning
We are not only resolving the customer segregation issue but we
also avoid that in case of a malicious user, user 1 cannot take
over the MAC-address of user 2 (MAC-address anti-spoofing, blocking
duplicate MAC-address)
*
MAC movement to highest priority
Within priority , always MAC Movement
Within priority , MAC movement only when feature is enabled in the
VLAN
LT
user links
subtending links
network links,
On the IWF
If the MAC-address was already configured or learnt on another user
logical port, the MAC-address won’t be learnt on the second port
and the frame is dropped (Conflict alarm)
On the Service Hub
You have the possibility to provision, if MAC movement is allowed
or not on a per VLAN basis. The default value is no MAC movement
.
Mac movement means that in case the same MAC-SA is received on a
second interface , the MAC-address will enter the learning table of
that interface and is removed from the 1st
If you do not perform MAC movement, it means that the duplicate
MAC-address is not learnt on the 2nd interface and the frames are
discarded
If the Service Hub receives a frame with MAC SA on a different
interface than previously learnt, then it will apply the following
rules:
Control interface has first priority: Learning a MAC address on the
control interface will always take priority on the learning of MAC
addresses on a network, an ASAM user or subtending interface,
irrespective of the order of learning.
Network interface has second priority: In case the MAC address is
first learnt on a subtending, ASAM or user port, and then on an
Ethernet network interface, then this movement of the MAC address
will be learnt (meaning that the MAC address on the subtending,
user or ASAM port is removed). In case the Duplicate MAC-address is
learnt on a network interface but it was learnt before on another
NW interface the last one takes priority.
ASAM link, subtending link, user link have third priority. If the
duplicate MAC address is received on a ASAM, user or subtending
port, and the same MAC address is already learnt on an Ethernet
network interface in the same VLAN, then the MAC address is not
learnt and the frame is dropped.
If the duplicate MAC address is learnt on a DSLAM, user or
subtending port, and the same MAC address was already learnt on a
port within this priority the action will depend on the
configuration of the VLAN. ( MAC movement allowed or not –
configurable per VLAN).
*
Prevents attacks that would fill up the bridging tables
Subscription rules: maximum devices connected simultaneously.
Configure MAC-addresses for Discarding
ISAM
port
ID
00-08-02-E9-F2-9D
BAS
There are 2 motivations to block the number of MAC-addresses per
port :
- Security: avoid that a malicious user can fill up all the
complete bridging table of devices in the network (DSLAM and
others), by sending traffic with different MAC addresses.
- Service differentiation: by limiting the number of MAC addresses
per port, the operator can offer different types of service
subscriptions to the user, limiting or allowing a certain number of
devices to connect simultaneously to the network. For this
application, it is clear that the limitation should be configurable
per port.
Note:
In this example the users PCs are connected to the internet via
PPPoE. In that case actually the BAS also has the possibility to
limit the number of PPPoE sessions per user-id. Within PPPoE, the
unique PPPoE session-id can be used to provide this additional
security. The BAS can use the PPPoE session-id for
user-identification during the session itself which is linked to an
earlier username/password given during the PPPoE session set-up.
The BAS knows that user has been given so many sessions. If you
have information on VP/VC you can of course also additionaly limit
the number of PPPoE sessions per VP/VC. In case of Ethernet
Backhaul however the BAS has no info on the VP/VC.
Within DHCP there is no information that identifies the user. In
that case limiting the number of MAC-addresses learnt per port on
the DSLAM is a possible solution, but what with a multi-edge
environment? .
If we want the DHCP server itself to be able to limite the number
of sessions of the user, the DHCP request needs to provide the
information that defines the user ( VP/VC , port …) This is
possible by implementing DHCP-option 82 (see later)
*
Security Services !
Solutions: PPP-connections (BRAS) or DHCP option 82…
User can access network with a different IP address than the
assigned IP address.
Pure layer 2 device
Within the same VLAN
Switches learn all MAC addresses of all end-users
IP edge learns all MAC addresses & IP addresses of all
end-users
*
Advised to use unique VLAN per [IPedge-DSLAM]-pair in EMAN
Avoid user-to-user communication
User to user traffic in EMAN
Easy IP network configuration
MAC-address spoofing
Traffic will be rerouted to any spoofed MAC address
Alcatel-Lucent University Antwerp
Add ports to VLAN
On SHUB and LTs
Service mapped on specific VLAN-ID
Different versions of one template possible
Create VLAN for
Here you’ll learn how to:
Distinguish different forwarding models and choose the right VLAN
mode for a certain forwarding model
Create a VLAN via CLI (on Service hub and ASAM-CORE)
Create a service template e.g. for a residential bridge VLAN via
AWS and deploy it to one or more ISAMs.
Add ports to a VLAN.
*
Parameters to configure
System mode settings
Service 2
Service 3
Service 4
Service 5
Service 6
Service 7
“Service Templates”
on AWS
VLAN 5
- RB VLAN
Ready for use
Can’t return to status “under construction”
Service parameters can only be modified via a new version of VLAN
service template
Obsolete
ANEL
Service
Definition
Create
Modify
By default AWS puts Service Identifier = Service Name
AWS
Disabled (default):
Enabled:
Disabled (default):
Enabled:
BC button not checked by Default
LT
Disabled (default):
Enabled:
Protocol Group Filter
3 possibilities
PPPoE + IPoE: allow only PPPoE and IPoE on VLAN
Protocol based VLAN association >> see later
*
Creation of VLAN in 2 steps
on SHUB
Create VLAN
Create VLAN on LT
The VLAN type in the service hub permits us
to do consistency checks between SHUB and ASAM CORE (with
AWS)
to couple specific configuration behavior to a VLAN.
Intelligent (Residential) Bridging mode: forwarding based on L2 and
multiple user connections can be associated to each VLAN.
RB on ASAM-CORE: multiple end-user ports can be assigned to a RB
VLAN
RB on SHUB: one VLAN on the SHUB that will be associated to all
(configured) network ports and ASAM ports
Note: AWS will automatically add new configured port to VLAN . When
configuration with CLI, operator needs to make sure that if needed
port is added to respective VLAN
IP aware bridging mode: Forwarding decision in ASAM-CORE is based
on L3, SHUB still behaves as a L2 device
L2 terminated on ASAM-CORE: associated with VLAN based on IP
DA.
L2 terminated on SHUB: one VLAN on the SHUB that will be associated
to all (configured) network ports and ASAM ports
Note: AWS will automatically add new configured port to VLAN . When
configuration with CLI, operator needs to make sure that if needed
port is added to respective VLAN
*
Hidden slide with text in notes pages
Routed mode: Forwarding decision in ASAM-CORE is based on L3 (IP
forwarding) . SHUB behaves as a Full router.
L2 terminated on ASAM-CORE: association with V-VLAN based on IP
DA.
Layer2-term-nwport on SHUB: a VLAN on the SHUB will only be
associated to network ports. That means the VLAN is terminated on
the SHUB.
In Cross-connect mode different models exist
C-VLAN cross-connect : Straightforward VLAN cross-connect model
where one or more VLANs at the EMAN side are associated with a
given PVC at the user side
CC on ASAM-CORE : only one end-user port (PVC or bridge port EFM)
associated to a specific C-VLAN
CC on SHUB: since there’s only one user associated to a specific
C-VLAN on the SHUB one ASAM-link and one or more network ports are
associated to the VLAN
S-VLAN at the EMAN side is associated with a PVC at the user side,
the C-VLANs carried within the S-VLAN are then passed transparently
to the end user.
CC on ASAM-CORE : only one end-user port (PVC or bridge port EFM)
associated to a specific S-VLAN
CC on SHUB: since there’s only one user associated to a specific
S-VLAN on the SHUB one ASAM-link and one or more network ports are
associated to the S-VLAN
S-VLAN/C-VLAN cross-connect mode : PVC – C-VLAN mapping, where the
S-VLAN tag can be used by the EMAN as route-identifier towards the
ISAM
CC on ASAM-CORE : Different end-user ports (PVC or bridge port EFM)
can be associated to a specific S-VLAN.
The C-VLAN identifies the user-port
*
Layer2 Terminated *
Layer2 Terminated *
Layer2 Terminated *
Layer2 Terminated *
Routed
* : see next chapters
Below you can already find an overview of the other non CC services
which will be covered later in this course as well
VLAN mode Model
Layer2 Terminated *
Layer2 Terminated *
Layer2 Terminated *
Layer2 Terminated *
Vlan ID range: 1 to 4093
Exluding the VLAN ID used for management
Create VLAN on ASAM-CORE
Optional parameters
[no] PPPoE relay – only for RB vlan
[no] dhcp-option-82 – only for RB vlan
Create VLAN on SHUB
Optional parameters
Id: [2...4093,4097] vlan id
Mode: Mandatory parameter with possible values (on
ASAM-CORE):
1) cross-connect, 2) residential-bridge, 3) qos-aware, 4)
layer2-terminated
Priority: optional parameter with default value: 0. Range:
{0...7}
[no]switch-broadcast: optional parameter to control downstream
broadcast frames
(default value:"discard-broadcast“). Broadcast control is
configurable per VLAN: on/off
[No] broadcast frames ‘broadcast frames’ means: broadcast allowed
(= ON)
[no] protocol filter (default: pass all).
Other possibilities: pass pppoe ,pass ipoe,pass pppoe-ipoe
[no]enable-pppoe-relay: optional parameter with default value:
"disable-pppoe-relay“ adding tag for pppoe relayed traffic (rb
vlan)
[no]dhcp-opt-82-on: optional parameter with default value:
"dhcp-opt-82-off“ enable adding dhcp option 82 (rb vlan)
CONFIGURATION OF VLAN ON SHUB
Mode: Mandatory parameter with possible values (on SHUB):
1) cross-connect, 2) residential-bridge, 3) layer2-terminated, 4)
layer2-term-nwport,
5) v-vlan = virtual vlan, 6) reserved (internal and external
communication via vlan)
[no] mac-move-allow: for residential bridges (no) mac-address
movement allowed between priority 3 ports (ASAM ports, subtending
ports and user ports on the SHUB).
Note: Adding ports to the VLAN also with “configure VLAN” command,
but not in one go with the creation of the VLAN! You need to enter
two consecutive commands. (see next chapter – add port to
VLAN)
Same for VLAN on SHUB
*
VLAN service template: Allocation strategy
When service is deployed on ISAM, it is mapped to one VLAN-ID
VLAN ID in function of allocation strategy
User select = At download VLAN-ID per ISAM is defined
Shared with VLAN-ID = ISAMs share the same VLAN-ID
AWS
AWS
ISAM
Give
VLAN-ID/NE
Give
VLAN-ID/NE
ISAM
ISAM
ISAM
When user select is chosen the operator chooses for a unique
VLAN
per [ISAM - IP-edge] pair. In this way when working in the Layer 2
forwarding model - Residential/Intelligent bridging mode, we avoid
user to user communication within the VLAN bridge.
In case the allocation strategy of the service is to share the same
VLAN-ID with different ISAMs this implies that we
- allow user to user communication within EMAN if the forwarding
mode for the service is Residential/Intelligent bridge
*
Remark: this diagram may be slightly different in different
releases!
Modification of Service Template in status under construction
Modifications within the same version
Service is not deployed to ISAM
Not possible when service is in state under construction
Modification of Service Template in state ready for use
Only possible by introducing/creation of new version
State modification of VLAN service Template
Under construction Ready for use
Ready for use Obsolete/preferred
Preferred Obsolete/Ready for use
Obsolete Ready for use
xDSL based on ATM
1 logical user port on the IWF of the LT.
1 xDSL line can have multiple VP/VCs
xDSL based on Ethernet (VDSL2/EFM)
1 end user is mapped to one logical
user port on the IWF of the LT
One to one mapping
xDSL based on ATM
1 VP/VC used per service (HSI, VoIP, STB), max 8 VP/VC per xDSL
line
xDSL based on Ethernet
VLAN per Service on UNI for all services, VLAN translation
CPE generates the VLAN in function of the (ISP, Service),
potentially requiring CPE management in case of wholesaling
QoS discrimination per VLAN (priority remarking, policing, …)
Multicast replication (one VLAN only)
*
One logical user port can be mapped to multiple VIDs
One logical port associated to CC or Residential-bridge VIDs
One logical user port can accept tagged or untagged frames
Configured on the level of VID Association
Per user logical port a PVID can be defined
Before PVID can be configured VLAN association has to be
configured
Configuration of VID within the bridged port
Support of 48 x 16 = 768 I-Bridges
on L3 LIMs
Also called the default VLAN ID
Port-and-protocol-based VLAN classification
VID based on port of arrival and the protocol identifier of the
frame
Multiple VLAN-ID’s associated with port of the bridge – VID
set
VLAN Translation
VID based on port of arrival and translated to a network VID
A VLAN bridge supports port-based VLAN classification, and may, in
addition, support port-and-protocol-based VLAN classification
In port-based VLAN classification within a bridge, the VLAN-ID
associated with an untagged or priority tagged frame is determined
based on the port of arrival of the frame into the bridge. This
classification mechanism requires the association of a specific
Port VLAN Identifier, or PVID, with each of the bridge’s ports. In
this case, the PVID for a given port provides the VLAN-ID for
untagged and priority tagged frames received through that
port.
For bridges that implement port-and-protocol-based VLAN
classification, the VLAN-ID associated with an untagged or
priority-tagged frame is determined based on the port of arrival of
the frame into the bridge and on the protocol identifier of the
frame.
For port-and-protocol based tagging, the VLAN bridge will have to
look at the Ethertype, the SSAP, or the SNAP-type of the incoming
frames. When the protocol is identified, the VID associated with
the protocol group to which the protocol belongs will be assigned
to the frame. This classification mechanism requires the
association of multiple VLAN-IDs with each of the ports of the
bridge; this is known as the “VID Set” for that port.
BTV and Port & protocol-based VLAN on R3.1-3.2
*
IB VLAN association of port on ASAM-CORE
Frames received from end users are untagged
User port can be mapped to multiple VID using port-Protocol based
association or PVID
Frames received from end users are tagged
On logical port define different VIDs and configure frames received
from end-user as tagged
Send frames back to the subscriber to be set as Single Tagged
E-MAN
Network
CPE
LT
E-MAN
Network
CPE
LT
IPoE
PPPoE
xxx
= PVID
IPoE
PPPoE
xxx
Frames received by the end users are tagged
Association Settings Send frames back to the subscriber as: Single
Tagged
Frames received from end users are untagged
*
VLAN Translation, frames received from end users are tagged
VLAN 1 (HSIA)
CPE
There are many operators who base their network architecture on one
PVC per service when connecting ADSL subscribers. Once those
operators start deploying VDSL, they need to use the VLAN as a "PVC
emulation".
The ISAM support the ability to emulate a multi-PVC configuration
on an EFM interface using the VLAN as a "PVC emulation", i.e. it is
possible to associate a set of VLAN Id's at the subscriber
interface with a set of forwarding engines being chosen from the
following list :
VLAN-CC (Transparent or Protocol aware) In this case, the C-VLAN
received at the user side is either forwarded as a C-VLAN CC or
encapsulated into an S-VLAN (VLAN stacking).
i-Bridge In this case, the VLAN received at the user side will be
bridged into an i-bridge identified by the same VLAN Id.
IP Aware Bridge
IP Routing
*
Add ports to VLAN
Add NW interfaces and all ASAM interfaces to this VLAN
In the ASAM
Add port to VLAN
Select ATM termination point
VLAN needs to be deployed first
EML
USM
Connection
Assign port to RB VLAN Rel.:<3.3
VLAN with protocol filtering: only PPPoE allowed
*
Select ATM termination point
VLAN needs to be deployed first
EML
USM
Connection
VLAN translation: assign Subscriber Vlan and Network VLAN
No VLAN Translation: assign Network VLAN = Subscriber VLAN
*
PVID setting
*
VLAN association on SHUB ports
*
Add port to a IB VLAN on the SHUB via CLI (1/2)
Attachment of ports to the VLAN included in the “configure VLAN
SHUB” command.
configure vlan shub id <VLAN ID>
mode residential-bridge
Optional parameters
[no] mac-move-allow: allow mac-address movement between ports with
priority 3 (user ports, ASAM ports, subtending ports). Default: no
mac-address movement allowed.
[no] egress-port: ports to be added to the VLAN. Three different
types of egress-ports exist:
LT (ASAM port)
Network
NT (any port on the NT, e.g. a user port or subtending port)
[no] untag port: send frames (un)tagged on egress-port.
*
Add port to a IB VLAN on the SHUB via CLI (2/2)
Attachment of ports to the VLAN on SHUB for IB.
Define egress ports in the “configure VLAN shub” command
Configure>vlan>shub>id <VLAN ID> egress-port
lt:<...>
defines an ASAM-link
defines an external NT port
Tag mode can be configured on network ports
Configure vlan shub id <VLAN ID> untag-port
network:<...>
ASAM-links support only tagged frames
*
vlan-id <VLAN ID> or
VLAN Translation
pvid <VLAN ID>
No VLAN Translation:
leg:isadmin>configure>bridge>port>1/1/4/1:8:36#
info
#---------------------------------------------------------------------------------------------------
leg:isadmin>configure>bridge>port>1/1/4/1:8:36#
info
#---------------------------------------------------------------------------------------------------
Deletion of VLAN
It is not possible to delete a VLAN if there are still ports
attached to the VLAN
Deleting VLAN on ASAM-CORE
Deleting VLAN on SHUB
*
Display list of command via “Show vlan ?”
Interesting commands on ASAM-CORE
gives al bridge ports connected to vlan
Show vlan bridge-port-fdb < bridge port id >
Gives all MAC-adresses learned or configured on that port
Show vlan fdb <VLAN ID>
Gives you MAC -adresses learned on all ports of that vlan
Show vlan port-vlan-map <bridge port id>
Gives all the VLANS to which that port is mapped
Same commands available on shub
Alcatel-Lucent University Antwerp
_______________________________________________________________
Objectives After completing the assignments in this chapter, the
trainee will be able to:
XXXXXX
Alcatel 5523 AWS: customer documentation
_________________________________________________________________
Perform these exercises with CLI and AWS unless specified
differently
Retrieval of Global Service/VLAN information
1. Which Services are created on the AWS?
2 . Find all the VLANs (Services) that are configured on the
ISAM.
*
4 . What are the ports belonging to vlan 200 on the SHUB? Explain
what you see.
5. Which logical ports are associated to VLAN 200?
6 Explain the total configuration of the user logical port PVC 8/35
on port TRAINING-a.
*
Exercises on notepage
What happens when the end-user sends a frame with VLAN tag
200?
What happens when the end-user sends a frame with VLAN tag
300?
What happens when the end-user sends an untagged frame ?
What happens whit a frame with VLAN tag 200 coming from the
network?
What happens whit a frame with VLAN tag 300 coming from the
network?
How many MAC-addresses can be learned in VLAN 200 on the logical
user port VP/VC 8/35 of port TRAINING-a
*
Exercises on notepage
Global Service/VLAN configuration
1. Create RB VLAN with VLAN ID=20x ( x
= adsl-x) via CLI. All traffic type is possible within the VLAN.
The VLAN is default VLAN on logical port 8/35. 4 user sessions
possible on the logical port.
2 Create RB VLAN with VLAN IS 120x (x = adsl-x) via AWS and apply
on the same port
<--<--<-- BCUser A - LT1
NetworkSHUBLT-->User B - LT1
NetworkSHUBLT-->User B - LT4
NetworkSHUB-->LT-->User B - LT1
-->-->User C - LT4
NetworkSHUB-->LT-->User B - LT1
-->-->User C - LT4