You are on page 1of 152

SAM IP-MPLS Service

Provisioning
TOS36024 Issue 1

STUDENT GUIDE

All Rights Reserved Alcatel-Lucent 2011

All rights reserved Alcatel-Lucent 2011


Passing on and copying of this document, use and communication of its
contents not permitted without written authorization from Alcatel-Lucent

All Rights Reserved Alcatel-Lucent 2011


SAM IP-MPLS Service Provisioning - Page 1

Empty page
Switch to notes view!

All Rights Reserved Alcatel-Lucent 2011

SAM IP-MPLS Service Provisioning

This page is left blank intentionally

All Rights Reserved Alcatel-Lucent 2011


SAM IP-MPLS Service Provisioning - Page 2

Terms of Use and Legal Notices


1. Safetyto
Warning
Switch
notes view!
Both lethal and dangerous voltages may be present within the products used herein. The user is strongly advised not to
wear conductive jewelry while working on the products. Always observe all safety precautions and do not work on the
equipment alone.
The equipment used during this course may be electrostatic sensitive. Please observe correct anti-static precautions.

2. Trade Marks
Alcatel-Lucent and MainStreet are trademarks of Alcatel-Lucent.
All other trademarks, service marks and logos (Marks) are the property of their respective holders, including AlcatelLucent. Users are not permitted to use these Marks without the prior consent of Alcatel-Lucent or such third party owning
the Mark. The absence of a Mark identifier is not a representation that a particular product or service name is not a Mark.
Alcatel-Lucent assumes no responsibility for the accuracy of the information presented herein, which may be subject to
change without notice.

3. Copyright
This document contains information that is proprietary to Alcatel-Lucent and may be used for training purposes only. No
other use or transmission of all or any part of this document is permitted without Alcatel-Lucents written permission, and
must include all copyright and other proprietary notices. No other use or transmission of all or any part of its contents may
be used, copied, disclosed or conveyed to any party in any manner whatsoever without prior written permission from
Alcatel-Lucent.
Use or transmission of all or any part of this document in violation of any applicable legislation is hereby expressly
prohibited.
User obtains no rights in the information or in any product, process, technology or trademark which it includes or
describes, and is expressly prohibited from modifying the information or creating derivative works without the express
All Rights Reserved Alcatel-Lucent 2011
3written consent of Alcatel-Lucent.
SAM IP-MPLS Service Provisioning

All rights reserved Alcatel-Lucent 2011

4. Disclaimer
In no event will Alcatel-Lucent be liable for any direct, indirect, special, incidental or consequential damages, including
lost profits, lost business or lost data, resulting from the use of or reliance upon the information, whether or not AlcatelLucent has been advised of the possibility of such damages.
Mention of non-Alcatel-Lucent products or services is for information purposes only and constitutes neither an
endorsement, nor a recommendation.
This course is intended to train the student about the overall look, feel, and use of Alcatel-Lucent products. The
information contained herein is representational only. In the interest of file size, simplicity, and compatibility and, in some
cases, due to contractual limitations, certain compromises have been made and therefore some features are not entirely
accurate.
Please refer to technical practices supplied by Alcatel-Lucent for current information concerning Alcatel-Lucent equipment
and its operation, or contact your nearest Alcatel-Lucent representative for more information.
The Alcatel-Lucent products described or used herein are presented for demonstration and training purposes only. AlcatelLucent disclaims any warranties in connection with the products as used and described in the courses or the related
documentation, whether express, implied, or statutory. Alcatel-Lucent specifically disclaims all implied warranties,
including warranties of merchantability, non-infringement and fitness for a particular purpose, or arising from a course of
dealing, usage or trade practice.
Alcatel-Lucent is not responsible for any failures caused by: server errors, misdirected or redirected transmissions, failed
internet connections, interruptions, any computer virus or any other technical defect, whether human or technical in
nature

5. Governing Law
The products, documentation and information contained herein, as well as these Terms of Use and Legal Notices are
governed by the laws of France, excluding its conflict of law rules. If any provision of these Terms of Use and Legal
Notices, or the application thereof to any person or circumstances, is held invalid for any reason, unenforceable including,
but not limited to, the warranty disclaimers and liability limitations, then such provision shall be deemed superseded by a
valid, enforceable provision that matches, as closely as possible, the original provision, and the other provisions of these
Terms of Use and Legal Notices shall remain in full force and effect.

All Rights Reserved Alcatel-Lucent 2011


SAM IP-MPLS Service Provisioning - Page 3

Blank Page
Switch to notes view!

All Rights Reserved Alcatel-Lucent 2011

SAM IP-MPLS Service Provisioning

This page is left blank intentionally

All Rights Reserved Alcatel-Lucent 2011


SAM IP-MPLS Service Provisioning - Page 4

About this Student Guide




Conventions
used
in this guide
Switch
to notes
view!
Note
Provides you with additional information about the topic being discussed.
Although this information is not required knowledge, you might find it useful
or interesting.

Technical Reference
(1) 24.348.98 Points you to the exact section of Alcatel-Lucent Technical
Practices where you can find more information on the topic being discussed.

Warning
Alerts you to instances where non-compliance could result in equipment
damage or personal injury.

All Rights Reserved Alcatel-Lucent 2011

Where you can get further information

SAM IP-MPLS Service Provisioning

If you want further information you can refer to the following:


 Technical Practices for the specific product
 Technical support page on the Alcatel website: http://www.alcatel-lucent.com

All Rights Reserved Alcatel-Lucent 2011


SAM IP-MPLS Service Provisioning - Page 5

About this Student Guide [cont.]




Switch to notes view!

6
SAM IP-MPLS Service Provisioning

All Rights Reserved Alcatel-Lucent 2011

This page is left blank intentionally

All Rights Reserved Alcatel-Lucent 2011


SAM IP-MPLS Service Provisioning - Page 6

Do not delete this graphic elements in here:

11

Section 1
System Operation
Module 1
File System and CLI

All Rights Reserved Alcatel-Lucent 2011

All Rights Reserved 2011, Alcatel-Lucent


Section 1 Module 1 Page 1

Objectives
112

Upon successful completion of this module, you will be able to explain:


 Access options






Command Line Interface (CLI) hierarchical structure


File structure
Initialization process
Boot Option File (BOF)
File Management System

5620 SAM IP/MPLS Service Provisioning

All Rights Reserved Alcatel-Lucent 2011

All Rights Reserved 2011, Alcatel-Lucent


Section 1 Module 1 Page 2

SNMP Components SNMP Agent


113

Responds to SNMP
manager requests

Sends Traps
SNMP Manager

(SNMP
(SNMPManaged
ManagedNodes)
Nodes)

Software
process

SNMP
SNMPAgent
Agent

5620 SAM IP/MPLS Service Provisioning

Software
process

Software
process

SNMP
SNMPAgent
Agent

SNMP
SNMPAgent
Agent

All Rights Reserved Alcatel-Lucent 2011

SNMP Components
The SNMP components are:
 Agent
 Manager
 Community
 MIB

SNMP Agent
The SNMP agent is a software process that runs on a managed node. The agent stores a variety of
management data and responds to SNMP manager requests for specific data. The agent can also
asynchronously signal an event (a trap) to the SNMP manager. Each node managed by the 5620 SAM has
an SNMP agent.

All Rights Reserved 2011, Alcatel-Lucent


Section 1 Module 1 Page 3

Introduction to the 5620 SAM Discovery Manager


114

Reconciles router
elements into the
5620 SAM database
SAM DB
Di

 Network Mgmt IP
 Persistence on
 SSH Preserve Key

SN

MP

re

sco

ve
ry
M

sp
on
s

an

ag

er

 Router ID

managed
network

 SNMP security
 SNMP no shutdown

5620 SAM IP/MPLS Service Provisioning

All Rights Reserved Alcatel-Lucent 2011

The 5620 SAM simplifies network provisioning by allowing you to discover devices and reconcile them to
the 5620 SAM database for management.
Network element discovery is executed via SNMP. During the discovery process, the 5620 SAM scans the
network for devices according to user-defined IP addresses or IP address ranges. When the IP address
used to discover the device is the IP address of the device management port, management is considered
out-of-band. Once a device has been discovered through its out-of-band management IP address,
management of that device can be changed to be in-band, at which time the device is managed through
its system IP address, also known as the System ID.
To discover devices, use the Discovery Manager to create one or more discovery rules, choose a discovery
rule, and scan the network as specified by the rule. When a device is discovered, the 5620 SAM sets the
device in a managed state and reconciles device elements into the 5620 SAM database.
Discovery rules contain rule elements. Rule elements specify which devices or subnets are to be included
or excluded from the discovery process. A discovery rule can contain more than one rule element. For
example, one rule element can be configured to discover a subnet, and configure another rule element
to exclude specific IP addresses from the subnet.

All Rights Reserved 2011, Alcatel-Lucent


Section 1 Module 1 Page 4

The Physical Access


115

OOB-CPM
Management
Ethernet
Port

CPM Console Port

In-band
Customer
Facing
Access Ports
&
Network Ports

SR-1
All Rights Reserved Alcatel-Lucent 2011

5620 SAM IP/MPLS Service Provisioning

There are three ways to access a node:


1. The console port, a DB-9 serial port, which is enabled by default. Initially, the node must be
configured through this serial port.
The default settings are:
Baud Rate: 115,200
Data Bits: 8
Parity: None
Stop Bits: 1
Flow Control: None
2. The CPM management Ethernet port, a 10/100 Ethernet management port located on the
front of the CPM, which must be initialized first (in the BOF or through the console). This is
considered Out Of Band (OOB) traffic.
3. Through the access and network ports. These are the in-band ports that carry the network and
customer traffic.
Note: By default, a node can only be accessed through the console port. Once a management IP
address and port have been configured, the Ethernet or in-band management ports can be
used, through the use of Telnet or SSH.

All Rights Reserved 2011, Alcatel-Lucent


Section 1 Module 1 Page 5

The Help Command


116

Help

Displays a brief description of the help system

Lists all commands in the current context

string ?

Lists all commands available in the current context that start


with string

command ?

Displays commands syntax and associated keywords

command keyword ?

Lists the associated arguments for keyword in command

Help Edit

Displays help on editing (editing keystrokes)


Lists available editing key strokes

Help Globals

Displays help on global commands


Lists available global commands

5620 SAM IP/MPLS Service Provisioning

All Rights Reserved Alcatel-Lucent 2011

The Help command is one of the most useful commands. While configuring or managing an SR, the
help command can provide the syntax and attributes available in the current context.
Some basic Help commands:
Help

Displays a brief description on the Help functionality. This command can be


used in any context.

This command displays all the possible commands in the current context.

string ?

Lists all the possible commands in the current context that start with
string.

Command ?

Displays a commands syntax and associated keywords.

Command keyword ?

Lists all the associated arguments for a keyword in a command.

Help Edit

Displays help on editing (editing keystrokes) and lists all available editing
key strokes.

Help Globals

Displays help on the global commands and lists all available global
commands.

All Rights Reserved 2011, Alcatel-Lucent


Section 1 Module 1 Page 6

The CLI command prompt


117

Example: Configuring SNMP

Node>config>system>snmp#
Host name Node

Context separator

Example: Configure system interface


Node>config# router interface system
Node>config>router>if$ address 172.0.0.4/32
At the end of the prompt, there is either a pound sign # or a dollar sign $:
A # indicates the context is an existing context.
A $ indicates the context is newly created.
To view the present working context and the user configured entities:

Node>config>router>if# pwc
All Rights Reserved Alcatel-Lucent 2011

5620 SAM IP/MPLS Service Provisioning

The prompt shows, unless otherwise configured, the current context in the hierarchical tree. The
prompt starts on the left with the name of the router which represents the Root context and
ends on the right with the current context. At the end of the prompt, you will see either a
pound # sign or a dollar $ sign. The # sign indicates you are working in an existing context.
An existing context is one previously created, such as an interface you created earlier in the
day. The $ sign indicates you have created a new context. A newly created loopback interface
would create a new context. You work within this new context to configure the new interface.
The prompt doesnt show the user configured entities, only contexts. To view the present
working context and the user configured entities (such as an interface name):
Node>config>router>if# pwc
To configure the number (for example 2) of higher level CLI contexts to display in the CLI prompt:
Node>environment# reduced-prompt 2
Which will result for example in:
Node>...router>ospf#

All Rights Reserved 2011, Alcatel-Lucent


Section 1 Module 1 Page 7

The Auto-completion Commands


118

Command completion can be achieved by:

Abbreviation, if keystrokes entered are unique enough.


Node>config# ro [ENTER]
Node>config>router#
Tab Key or Space Key to auto-complete the command.
Node>config# ro [TAB]
Node>config# router
Node>config# ro [SPACE]
Node>config# router

If match is not unique CLI will display possible matches:


Node>config# r [TAB]
redundancy router

5620 SAM IP/MPLS Service Provisioning

All Rights Reserved Alcatel-Lucent 2011

The CLI is able to auto-complete partially entered commands. This auto-complete function is
invoked by hitting ENTER, TAB or SPACE.
1. As long as the partial command can uniquely identify a command or context that is allowed in
the current context TAB and SPACE will auto-complete the command.
Node>config# ro [TAB] (or [SPACE])
Node>config# router
2. ENTER will auto-complete the command AND execute it.
Node>config# ro [ENTER]
Node>config>router#
3. If the partial command is ambiguous and indicates more than one option, TAB and SPACE
will list all the remaining possible matches.
Node>config# r [TAB] (or [SPACE])
redundancy router
4. ENTER will result in an error message:
Node>config# r [ENTER]
Error: Ambiguous command
The system maintains a history of 30 previously entered commands that can be displayed with the
history command from any context (global command).

All Rights Reserved 2011, Alcatel-Lucent


Section 1 Module 1 Page 8

File System Structure


119

Root

bof.cfg

Boot
Option
File

boot.ldr

Bootstrap
Image

m
n
Y

TiMOS-m.n.Yz

config.cfg

Default
Configuration
File

cpm.tim

iom.tim

both.tim

(SR-7/-12)

(SR-7/-12)

(SR-1)

CPM
Image
File

IOM
Image
File

Major release number


Minor release number
A
Alpha Release
K
Beta Release
M
Maintenance Release
R
Released Software
J
Internal Engineering and Test Release
Version number

5620 SAM IP/MPLS Service Provisioning

All Rights Reserved Alcatel-Lucent 2011

The following files are required:


1. boot.ldr: Contains the system bootstrap image file.
2. bof.cfg: This user-configurable file contains a set of pointers that indicate locations (e.g.
the image files, the configuration files, ) and initial parameters (e.g. the management port
IP address, the serial interface characteristics, ).
3. TiMOS-m.n.Y.z: This is a directory named according to the major and minor software
release, type of release and version. For example, if the software release is Version 1.2 of a
released software version the name would be TiMOS-6.0.R.0. On an SR-7 and SR-12, this
directory contains two files, cpm.tim and iom.tim, for the SF/CPM and IOM cards
respectively. An SR-1 has an integrated SF/CPM and IOM, there is only one file, named
both.tim.
4. config.cfg: This file contains the default configuration file. The default configuration file is
very basic and provides just enough information to make the system operational. Other
configuration files can be created by the user.
The initialization process requires the Boot.ldr and the Bof.cfg to be present on the Compact
Flash Card 3 (CF3).

All Rights Reserved 2011, Alcatel-Lucent


Section 1 Module 1 Page 9

File System Management


A DOS-like file system is used to stores files used and generated by the system. Files can be
stored on a compact flash (CF) cards in cf1:, cf2:, or cf3:.
All file system commands operate on the local file system and some, such as copy, delete, and
dir, can operate on remote file systems. Arguments for the file commands are based on a URL
structure. Local and remote file operations are divided into three types: local, ftp, and tftp.
Some commands for file and directory management:

Node# file

Enter the CLI File context.

Node>file cf3:\ # attrib

Display or change the current working


directory in the local file system.

Node>file cf3:\ # cd [..]

Display or change the current working


directory in the local file system.

Node>file cf3:\ # dir

Display a list of files and subdirectories


in a directory.

Node>file cf3:\ # md

Create a new directory in the local file


system.

Node>file cf3:\ # rd

Remove (delete) a directory in the local


file system.

Node>file cf3:\ # copy


Node# file copy
cf3:\config.cfg
ftp://10.1.1.1/config.cfg

Copy a file or all files in a directory


from a source URL to a destination URL.
At least one of the specified URLs
should be a local URL. The optional
wildcard (*) can be used to copy
multiple files that share a common
(partial) prefix and/or (partial) suffix.
Copy methods include ftp and tftp as
specified in the URL. The example
copies the file config.cfg from cf3: to
an FTP server.

All Rights Reserved 2011, Alcatel-Lucent


Section 1 Module 1 Page 10

File System CLI Context


1 1 11

Root
File

Attrib
Cd
Copy
Delete
Dir
Md
Move
Rd
Scp
Type
Version

All Rights Reserved Alcatel-Lucent 2011

5620 SAM IP/MPLS Service Provisioning

Some commands:

Node>file cf3:\ # delete

Delete the specified file. The optional


wildcard (*) can be used to delete
multiple files that share a common
(partial) prefix and/or (partial) suffix.

Node>file cf3:\ # move

Move a local file, system file, or a


directory. If the target already exists,
the command fails and an error message
displays.

Node>file cf3:\ # scp

Copy a file from the local files system to


a remote host on the network. scp uses
ssh for the data transfer, and uses the
same authentication and security as ssh.

Node>file cf3:\ # type

Display the content of a text file.

Node>file cf3:\ # version

Display the version of an OS cpm.tim


or iom.tim file.

All Rights Reserved 2011, Alcatel-Lucent


Section 1 Module 1 Page 11

Managing The BOF


1 1 12

Boot
Option
File

The system uses the BOF file to perform the following tasks:
1)
2)
3)
4)
5)
6)
7)
8)
9)
10)

Configure Primary, Secondary, Tertiary image source


Configure Primary, Secondary, Tertiary configuration source
Create an IP address for the CPM Ethernet port
Create a Static route for the CPM Ethernet port
Configure the DNS Domain name
Set up the CPM Ethernet port (speed, duplex, auto)
Configure persistence requirements
Enable/disable Lawful Intercept configuration to be saved locally
Enable/disable separate access to Lawful Intercept (LI) information
Set the console port speed

Always be sure to save the BOF!

All Rights Reserved Alcatel-Lucent 2011

5620 SAM IP/MPLS Service Provisioning

Parameters that are configured in the BOF are shown in the chart above.
Some commands:
Node# bof

Enter the CLI BOF context to change or


create a bof file.

Node>bof# address 10.10.10.2/24


primary

Change or create the CPM Ethernet Port


IP address.

Node>bof# speed 100

Set the CPM Ethernet Port speed to 100


Mbps.

Node>bof# primary-image
cf3:/TIMOS.5.0.R0

Set the primary image directory.

Node>bof# primary-config cf3:/test.cfg

Set the primary configuration file (eg.


test.cfg).

Node>bof# save

Save the bof.

Node# show bof

Display the in-memory bof file (last


used).

All Rights Reserved 2011, Alcatel-Lucent


Section 1 Module 1 Page 12

System Initialization
1 1 13

START

N
Config found ?

Initialize
Hardware

Startup
Failed

Get config
(3 possible locations)

N
Y
Load & Execute
boot strap loader
(cf3:\boot.ldr)

Process
boot option file
(cf3:\bof.cfg)

Image OK ?

Get runtime image


(3 possible locations)

Persistence
Needed for proper SAM
Operation: see
optional topic

Process
persistence
and
Configuration
files

Log In
Prompt

Persistence
File Processed
OK

1
N
Y

SNMP shutdown
Issue Trap (if possible)
Issue Log entry
Issue Console msg

Y
Config File
Processed OK

User intervention point:

Need
Persistence
?
Y

Process
Config File

Wait
required

Boot with Defaults


SNMP shutdown
Issue Trap
Issue Log entry
Issue Console msg

User activity detected

5620 SAM IP/MPLS Service Provisioning

All Rights Reserved Alcatel-Lucent 2011

Persistence specifies whether the system will preserve system indexes when a save command is
executed. During a subsequent boot, the index file is read along with the configuration file.
Indexes uniquely identify objects in the router (ie Interfaces, LSPs) and are used by SNMP tools
(ie MIB Browsers, the SAM database) to identify these objects. When configuration changes on a
device are saved, a
corresponding index file (.ndx extension) is created.
During a reboot of the network element, the configuration file is compared to the index file to
ensure that indexes remain the same, thus establishing a persistent index. This reduces the
number of resynchronizations between the 5620 SAM and the affected network element.

All Rights Reserved 2011, Alcatel-Lucent


Section 1 Module 1 Page 13

1 1 14

Switch to notes view!

System Initialization
When a system is powered up or rebooted the system initialization process follows the sequence
below:
The system checks CF3 for the bootstrap loader (boot.ldr) file used to initialize the basic system
hardware and allow the system to process the boot option file.

Boot Option File (bof.cfg)


The boot option file is stored on CF3 and contains information used to configure access to the
system (serial port speed, management IP address) and the location of Runtime Image and
Configuration files.
After the BOF has been loaded, the system may enter a wait time. Wait times, configured in the
BOF, allow the system initialization process to pause for a configured time. Wait times provide
the user with an opportunity to interrupt the system initialization process.
5620 SAM IP/MPLS Service Provisioning
Runtime
Image

All Rights Reserved Alcatel-Lucent 2011

The runtime image files (cpm.tim, iom.tim or both.tim) contain the system application software.
The runtime image file can be stored locally or remotely in any of three locations (primary,
secondary, and tertiary) specified in the BOF. The system checks each location in sequence for an
image. The first image found is the one that will be used. Once the runtime image is loaded,
control is passed from the bootstrap loader to the image. If a runtime image cannot be loaded
the system will fail to start and user intervention will be required to correct the problem.

Configuration File
After loading the runtime image, a user-configurable configuration file, containing chassis, IOM,
MDA, port, routing, system and service configuration information, is loaded. If a configuration file
cannot be found the system is initialized with default configuration settings and SNMP is
shutdown (Get and Set functionality is disabled), however traps will continue to be issued. The
system issues traps, log messages, and console messages to advise the user. It requires a
configure system snmp no shutdown to reactivate full SNMP functionality.

All Rights Reserved 2011, Alcatel-Lucent


Section 1 Module 1 Page 14

Basic Router Configuration


1 1 15

1.

Launch a CLI or SSH session to the router

2.

Configure Network Management IP


a. # bof <Enter>
b. # show bof

Tip
If address is not defined, type the following:
a. bof# address <IP address/ subnet mask> <Enter>
3.
4.
5.

Set persistence on
a. bof# persist on <Enter>
Define a location to save the configuration file
a. bof# primary-config <file location:/file path/filename.cfg>
Save the bof
a. bof# save

5620 SAM IP/MPLS Service Provisioning

All Rights Reserved Alcatel-Lucent 2011

The first step to enable the 5620 SAM to discover and manage network elements is to provide for the basic
configuration of the devices. Use the following steps to provide the basic configuration 7750/ 7450 and
7710:
1. Initiate a CLI or SSH session with the appropriate network element
2. Configure the Management IP interface

Follow the procedure shown above to define the Ethernet management IP which is used for remote
access to the network element. This address is defined in the bof (boot options file) and is shown
above. Configure the interface, as required.
3. Set persistence on

Persistence is required for management of network devices through the 5620 SAM and is enabled by
default. Set the parameter, as required.
4. Define the location to save the configuration file

Changes to the configuration of the router (interfaces, SNMP, etc) must be saved to ensure that the
parameters are not lost should the element be rebooted. The file location can be either on an ftp
server or any of the compact flashes on the device. There is no specific naming convention for the
filename however, it must end with a .cfg extension. This file will become the default save location
each time an admin save is performed.
5. Save the bof

To ensure that changes are not lost should the network element reboot, perform a bof save as
indicated above.

All Rights Reserved 2011, Alcatel-Lucent


Section 1 Module 1 Page 15

Basic Router Configuration [Cont.]


1 1 16

6.

Define the Router ID


a. # configure router interface system address
<IP address/32> <Enter>

7.

Configure SNMP Security


a. # configure system security snmp <Enter>
b. # community <community string> rwa version both <Enter>

8.

Enable
a. #
b. #
c. #

9.

Enable SSH Preserve Key


a. # configure system security ssh preserve-key <Enter>

SNMP
configure system snmp <Enter>
packet-size 9216 <Enter>
no shutdown <Enter>

10. Confirm changes


a. # show bof <Enter>
b. # show router interface <Enter>
c. # configure system security snmp <Enter>
# info
d. # configure system snmp <Enter>
# info

Attention:
Remember to save theAll Rights
router
Reserved
configuration
Alcatel-Lucent 2011
5620 SAM IP/MPLS Service Provisioning
6. Define the Router ID

Though any interface can be configured as the Router ID, traditionally the system interface, also know
as the loopback address in other vendors equipment, is configured to assume this role.
7. Configure SNMP Security

Deployments are initiated from the SAM to the managed devices through SNMP. By default, SNMP is not
configured on the managed devices. Therefore, network operators or administrators will be required to
define the SNMP parameters. The example above assumes SNMP v1/v2 will be configured on the
devices in the network. SNMPv3 requires more extensive configuration. Refer to the managed devices
technical practices for details.
8. Enable SNMP

By default, SNMP is disabled. Enable the protocol and ensure that the appropriate PDU size is set (5620
SAM requires a PDU size of 9216 bytes).
9. Enable SSH Preserve Key

The SAM keeps track of Host Keys of the routers. Should a router reboot the host key has a potential to
change which could impact an operators ability to SSH into the network element. Enabling SSH
Preserve Key will ensure the NE host key remains the same.
6. Confirm changes
7. Save the configuration changes

# admin save <Enter>

All Rights Reserved 2011, Alcatel-Lucent


Section 1 Module 1 Page 16

1 1 17

End of Module
Operating System, File System and CLI

5620 SAM IP/MPLS Service Provisioning

All Rights Reserved Alcatel-Lucent 2011

All Rights Reserved 2011, Alcatel-Lucent


Section 1 Module 1 Page 17

1 1 18

5620 SAM IP/MPLS Service Provisioning

All Rights Reserved Alcatel-Lucent 2011

All Rights Reserved 2011, Alcatel-Lucent


Section 1 Module 1 Page 18

Do not delete this graphic elements in here:

21

Section 2
IP Routing

All Rights Reserved Alcatel-Lucent 2011

All Rights Reserved 2011, Alcatel-Lucent


Section 2 Module 1 Page 1

Objectives
Upon successful completion of this module, you will be able to explain:
Interface Configuration
Routing Protocol

212

All Rights Reserved Alcatel-Lucent 2011

All Rights Reserved 2011, Alcatel-Lucent


Section 2 Module 1 Page 2

System Interface


System interface IP address must be configured


 IP Address
 No Port - System IP address is referred to as the loopback IP address

System IP address is used when signaling the MPLS LSP (via LDP) and
when signaling the VLL (via t-LDP)

213

All Rights Reserved Alcatel-Lucent 2011

All Rights Reserved 2011, Alcatel-Lucent


Section 2 Module 1 Page 3

Network Interfaces


Only one IP address can be configured per network facing link


 Interface Name
 IP Address
 Port

IP interfaces are maintained during CSM activity switch-over

All connections are assumed to be point-to-point

214

All Rights Reserved Alcatel-Lucent 2011

All Rights Reserved 2011, Alcatel-Lucent


Section 2 Module 1 Page 4

Static Routing

192.168.11.0/30

192.168.11.1 A

192.168.22.0/30

Node1

Node2

10.12.1.0/29

B
10.12.1.1

B
10.12.1.2

Routing Table:
192.168.11.0/30 Direct via interface A
10.12.1.0/29 Direct via interface B
192.168.22.0/30 static via 10.12.1.2

215

A 192.168.22.1

Routing Table:
192.168.22.0/30 Direct via interface A
10.12.1.0/29 Direct via interface B
192.168.11.0/30 static via 10.12.1.1

All Rights Reserved Alcatel-Lucent 2011

Static routes are entries in the routing table that were manually entered by someone, typically the network
administrator. The administrator must have a good understanding of the existing network topology and be
confident that any changes in the network topology will not affect these static routes. Static routes are
often used to connect two ASs (much like an EGP) or to provide a default route for Stub Networks.
There are three types of static routes:
1.

Next-hop: specifies the IP-address of the interface of the next hop router on a directly connected link.

2.

Indirect: specifies the IP address of the interface of the next hop router, not directly connected, but at
least 1 hop away.

3.

Black Hole: used to silently discard an IP packet with the specified IP-DA.

Static routes can be viewed using the following command:


show router static-route

All Rights Reserved 2011, Alcatel-Lucent


Section 2 Module 1 Page 5

Introducing Link State Routing





Each router establishes an adjacency with its neighbors


Event based updates are used - Link State Advertisements (LSAs)
 LSAs include link id, link type, cost based on bandwidth
 Each router maintains a database of received LSAs

Each router uses its link state database to run a shortest path algorithm
(Dijikstras algorithm) to populate the route table

Received
LSAs

Link State
Database

Dijkstras
Algorithm

Route
Table

LSAs are flooded to other interfaces


216

All Rights Reserved Alcatel-Lucent 2011

Link State Routing Protocols distribute local information to every other router in the network using Link State
Advertisements (LSAs). This flooding of LSAs assures that every router has information on routes coming
from the most reliable source, the updating router itself. This new approach radically changed Intra-AS
Routing and resulted in two IGPs, Open Shortest Path First and Intermediate System to Intermediate
System. In addition to changing the way that routing information is updated, these Link State Protocols
offer other advantages:
1. A new metric system, cost or bandwidth based, that is no longer limited to 15 hops.
2. Instead of sending complete updates periodically, only topology changes are sent out, at the time they
occur. This reduces the overhead of route updates compared to the Distance Vector Routing Protocoals.
3. A dual-level hierarchy, together with the unlimited metric allows the network to contain many more
nodes so the new IGPs are scalable for large Autonomous Systems.

All Rights Reserved 2011, Alcatel-Lucent


Section 2 Module 1 Page 6

OSPF Overview
Open Shortest Path First (OSPF) is one of the most popular link-state
interior gateway protocols used in large enterprise networks.
Features:

217

Scalable
Hierarchical (using areas)
Supports authentication
Fast convergence
Uses Dijkstras Shortest Path First (SPF) algorithm for route selection
Classless; supporting VLSM, CIDR, and manual route summarization
Routing metric is based on the physical bandwidth of the port
Traffic Engineering support

All Rights Reserved Alcatel-Lucent 2011

OSPF uses 5 different types of packets to establish and maintain router connectivity and network
convergence:
1. Hello Packets: generated by all OSPF speaking routers. They are used to discover neighbors, and to form
and maintain adjacencies. They are propagated periodically (10 seconds).
2. Database Descriptors: used to distribute a summary of all the networks in the routers database.
Typically this will be the classless network, routers cost to access, and the sequence number associated
with that network entry.
3. Link State Requests: used to request additional information on a particular network entry on which the
present information is non-existant or outdated after comparing the Database Descriptors.
4. Link State Updates: respond to Link State Requests by using the requested LSAs. There are many forms
of LSAs available.
5. Link State Acknowledgments: acknowledge every newly received LSA. Many acknowledgments may be
grouped together into a single Link State Acknowledgment packet.

All Rights Reserved 2011, Alcatel-Lucent


Section 2 Module 1 Page 7

OSPF Configuration

218

Enable OSPF

Create Area

Add Interfaces

All Rights Reserved Alcatel-Lucent 2011

All Rights Reserved 2011, Alcatel-Lucent


Section 2 Module 1 Page 8

ISIS Overview
Intermediate System-to-Intermediate System (IS-IS)
Both ISIS and OSPF are link state protocols

Features:

219

Scalable
IS-IS routing uses two-level hierarchical routing
Supports authentication
Fast convergence
Uses Dijkstras Shortest Path First (SPF) algorithm for route selection
Classless; supporting VLSM, CIDR, and manual route summarization
Routing metric is based on the physical bandwidth of the port
Traffic Engineering support

All Rights Reserved Alcatel-Lucent 2011

Characteristics of IS-IS.
The cost of the links is by default 10 but is configurable (reference bandwidth can also be configured as in
OSPF).
IS-IS uses L2 multicasting (instead of L3 multicast in OSPF):
 Level 1 updates use 01-80-C2-00-00-14
 Level 2 updates use 01-80-C2-00-00-15
 IS-IS works on top of layer 2 in the OSI model, it uses no IP or Transport Layer Protocol but takes care of
their responsibilities itself through the use of acknowledgements and sequence numbers.
 IS-IS uses an ISO standardized network addressing method, called NSAP (Network Service Access Point)
addressing.
IS-IS requires a System ID of 6 bytes which can be derived from the chassis MAC address, the system address,
or the router-id, configured in the config>router# context.
IS-IS supports three types of authentication
None (default).
Simple authentication.
MD5 authentication.

All Rights Reserved 2011, Alcatel-Lucent


Section 2 Module 1 Page 9

ISIS Configuration

2 1 10

Enable ISIS

Create Area

Add Interfaces

All Rights Reserved Alcatel-Lucent 2011

All Rights Reserved 2011, Alcatel-Lucent


Section 2 Module 1 Page 10

End of Module/Lesson
IP Routing

2 1 11

All Rights Reserved Alcatel-Lucent 2011

All Rights Reserved 2011, Alcatel-Lucent


Section 2 Module 1 Page 11

2 1 12

All Rights Reserved Alcatel-Lucent 2011

All Rights Reserved 2011, Alcatel-Lucent


Section 2 Module 1 Page 12

Do not delete this graphic elements in here:

30

Section 3
Multi Protocol Label Switching (MPLS)

All Rights Reserved Alcatel-Lucent 2011

All Rights Reserved 2011, Alcatel-Lucent


Section 3 Module 1 Page 1

Objectives
Upon successful completion of this module, you will be able to describe:
 MPLS Overview
 MPLS RSVP-TE Overview
 LSR Ring and Tree Topology
 Fast Reroute in Ring Topology
 LSP Redundancy

312

All Rights Reserved Alcatel-Lucent 2011

All Rights Reserved 2011, Alcatel-Lucent


Section 3 Module 1 Page 2

MPLS Overview

313

All Rights Reserved Alcatel-Lucent 2011

All Rights Reserved 2011, Alcatel-Lucent


Section 3 Module 1 Page 3

7705 SAR Label Signaling and Distribution Summary

Label Signaling &


Distribution

Manual

Static

Dynamic
MPLS Service Signaling

Dynamic

LDP

RSVP

T-LDP

Hop by Hop
IGP / CSPF

IGP
Best Effort

IGP
Targeted Session
Explicit Path
Loose / Strict Paths

314

MP-BGP

All Rights Reserved Alcatel-Lucent 2011

7705 SAR Supported MPLS Features:


 Static MPLS LSP/Tunnel configuration
 MPLS LSP/Tunnel signaling via LDP
 RSVP-TE
 E-LSP (exp- inferred LSP)
 Downstream-Unsolicited Label Advertisement
 Ordered Label Distribution Control
 Liberal Label Retention
 ECMP
 OAM LSP Ping
 OAM LSP Traceroute

All Rights Reserved 2011, Alcatel-Lucent


Section 3 Module 1 Page 4

MPLS: Basic operation

Push

Swap

LER

Pop

Swap

LSR

LSR

LER

Label Switched Path

data

label

data

label

IP Forwarding

data

label

LABEL SWITCHING

315

data

data
IP Forwarding

All Rights Reserved Alcatel-Lucent 2011

The MPLS LSPs are virtual tunnels created through the use of labels signalled between MPLS speaking
routers. Once a label is chosen at the ingress, the label header is put at the front of the packet header
so that the label value can be carried across the network with the packet. At each subsequent hop,
the Label Switch Router (LSR) simply looks up the label value in a table to make the forwarding
decision, there is no need to parse the IP header. Since the label is a fixed length, label look-up is fast
and simple
MPLS performs three basic operations:


Push - Puts a label onto the packet.

Swap - Swaps or changes a label received at an ingress interface with a label at an egress interface
of the node. The label swapping is done in accordance to the Label Forwarding Information Base
(LFIB).

Pop - Removes the label from the packet.

An LSR router (7705 SAR Release 2.0) can perform pop, push and swap operations. An LER (7705 SAR
Release 1.0) can perform pop and push operations.

All Rights Reserved 2011, Alcatel-Lucent


Section 3 Module 1 Page 5

MPLS Label

Frame header
DA

SA

Type =
88 47

Single Label
MPLS
Header

IP Header

IP Packet

FCS

Label Stack
Data Link
Header

MPLS Header
1

MPLS
Header 2

IP Header

IP Data

FCS

4 Octets

Label Stack
Entry Format

Label
Label:
Exp.:
S:
TTL:

316

Exp.

TTL

Label Value, 20 bits


Experimental, 3 bits (Class of Service)
Bottom of Stack, 1 bit (1 = last entry in label stack)
Time to Live, 8 bits

All Rights Reserved Alcatel-Lucent 2011

Field Descriptions:
 Label: 20-bit field that carries the actual value of the label.
 Exp: This 3-bit field is reserved for experimental use. It is currently used for Class of

Service(CoS).
 S: This bit is set to 1 for the last entry (bottom) in the label stack, and 0 for all other label

stack entries.
 TTL: This 8-bit field is used to encode a TTL value.

In MPLS, packets can carry not just one label, but a set of labels in a stack. An LSR can swap the
label at the top of the stack, pop the stack, or swap the label and push one or more labels into
the stack. The processing is always based on the top label, without regard for the possibility that
some number of other labels may have been above it in the past, or that some number of other
labels may be below it at present.

All Rights Reserved 2011, Alcatel-Lucent


Section 3 Module 1 Page 6

LIB and LFIB


Table
Name

Meaning

Contents

Populated By

RIB

Routing Information Base

Routing updates received

Routing Protocol Exchange - Each routing


protocol has a separate RIB

FIB

Forwarding Information
Base

Active routes

RTM selects the active routes from all


protocol "Best" routes

LIB

Label Information Base

Locally generated and


received MPLS labels

MPLS Label Exchange

LFIB

Label Forwarding
Information Base

Labels used by the LSR

The labels assigned to the active routes (for


each next-hop)

OS
P

Fu
pd

LD

ate

Pu

pd
a

te

RIB OSPF
FIB

LD

IS
IS -

d
up

317

Pu

a
pd

te

RIB IS-IS

ate

LFIB
LIB LDP

All Rights Reserved Alcatel-Lucent 2011

The Label Information Base (LIB) is populated based on the label exchange process. The Label
Forwarding Information Base (LFIB) is built from the LIB and the Forwarding Information Base
(FIB). The LFIB contains only the labels that will be used for label switching packets. If a label is
received from a neighbor for a FEC, and the FIB contains a route for the same FEC for which the
same neighbor is the next-hop, then it is populated into the LFIB.

Difference Between the LIB/LFIB


The difference between the LIB and the LFIB is comparable to the difference between the
Routing Information Base (RIB) and the Forwarding Information Base (FIB) of a routing protocol.

RIB/FIB
In the RIB, all the routes learned by any routing protocol running on the router is stored in that
specific routing protocols RIB. The RIB is a collection of all the possibilities learned through a
the routing protocol. Out of all these possibilities only one route (no ECMP) can be used, this
route is selected by the Route Table Manager (RTM) through the preference and metric
procedures and stored in the FIB. In other words, the FIB represents the best routes of all the
RIBs. The FIB has the actual outgoing port defined where the traffic needs to be send.

LIB/LFIB
The LIB relates to the LFIB as the RIB relates to the FIB. The LIB contains all the labels learned
while the LFIB only stores the best label that will actually be used to forward traffic.

All Rights Reserved 2011, Alcatel-Lucent


Section 3 Module 1 Page 7

LDP Label Distribution Protocol

318

All Rights Reserved Alcatel-Lucent 2011

All Rights Reserved 2011, Alcatel-Lucent


Section 3 Module 1 Page 8

Label Distribution Protocol - Purpose






Each LSR will originate a label for its system address by default
LDP relies on the underlying routing information provided by an IGP in
order to communicate label bindings to peers
The router forwarding information base, or FIB, is responsible for
determining the hop-by-hop path through the network
LSR 2

LSR 1
1/1/2
1/1/3

1/1/3

1/1/1

10.2.1.0/24
1.1.1.1/32

Prefix

1/1/1

1/1/2

1/1/2

1/1/1

10.1.1.0/24

LSR 1
LFIB

LSR 4

LSR 3

Ing.
Label

3.3.3.3/32

2.2.2.2/32

Egr.
Label

Egr.
Intf

Next-hop

LSR 4
LFIB

Prefix

4.4.4.4/32

Ing.
Label

Egr.
Label

Egr.
Intf

Next-hop

10.2.1.0/24

131068

1/1/2

LSR2

10.1.1.0/24

131065

1/1/3

LSR3

4.4.4.4/32

131071

1/1/2

LSR2

1.1.1.1/32

131070

1/1/3

LSR3

Control Plane
319

All Rights Reserved Alcatel-Lucent 2011

Labels are created based on the forwarding equivalence classes (FECs) created through the layer 3 routing protocol.
In order for label swapping to be possible, common understanding of which FECs map to which labels must be
achieved between adjacent routers. The communication of label binding information (I.e. the binding of an FEC
to a specific label value) between LSRs is accomplished by label distribution.
A router passes binding information to its peers after a specific label value is assigned to an FEC. The LSR receiving
this binding information inserts the label value into the label information base associated with the corresponding
FEC.
The upstream LSR is then aware that if it is forwarding a packet associated with the particular FEC, it can use the
associated label value and the downstream LSR that the packet is forwarded to will recognize it as belonging to
that FEC. As this information is communicated along a chain of LSRs, a path will be set up along which a number
of hops can use label swapping and avoid the full layer 3 look-up

Label binding to a FEC


There are two ways defined in the industry to bind a label to a FEC:
1. Advertise a label for each prefix in the routing table of the advertising router. This implies a large number of
labels in the MPLS network and may cause scalability issues.
2. Advertise a label per system address.
Alcatel-Lucent products advertise a label per system address as the default, resulting in fewer labels being used.
Once LDP neighbors have been established, each LSR will originate a label for its system address, and may originate a
label for each FEC for which it has a next-hop that is external to the MPLS domain. To do this, an export policy is
required.
In the example shown above, LSR 4 has an external next-hop for FEC 10.2.1.0/24 and has created a local label
binding for this FEC and will propagate it into the MPLS domain to its LDP peer LSR 3.
Similarly, LSR 1 will originate a label for FEC 10.1.1.0/24.

All Rights Reserved 2011, Alcatel-Lucent


Section 3 Module 1 Page 9

LDP: Downstream Unsolicited Distribution Mode


Downstream:
Advertising labels from downstream to the
upstream direction.

iLER
LIB

Prefix

Next-hop

Label

10.2.1.0/24

LSR 2

131065

10.2.1.0/24

LSR 3

131066

Unsolicited:
1.1.1.1/32

Each LSR will originate a label for its


system address by default. Label
mappings are provided to all peers for
which the local LSR might be a next-hop,
even when not explicitly requested.

iLER

FEC: 10.2.1.0/24
Label: 131065

2.2.2.2/32
LSR2

FEC: 10.2.1.0/24

FEC: 10.2.1.0/24

Label: 131067

Label: 131066

10.2.1.0/24
LSR3
4.4.4.4/32

eLER
FEC: 10.2.1.0/24

3.3.3.3/32

Label: 131067
3 1 10

All Rights Reserved Alcatel-Lucent 2011

The MPLS architecture allows an LSR to distribute label bindings to other LSRs that have not
explicitly requested them.
Downstream Unsolicited (DU) label distribution is not dependent on the data plane. Labels will
be generated and distributed strictly in the control plane prior to the arrival of any user
originated traffic.
In Downstream Unsolicited mode, label mappings are provided to all peers for which the local
LSR might be a next-hop for a given FEC. This would typically be done at least once during the
lifetime of a peer relationship between adjacent LSRs. The label received from the router
providing the active IGP route for the FEC is used (from the best next-hop).
This technique allows the IGP routing topology to provide some level of redundancy should there
be any network issues. For example, should the router providing the active IGP route fail or the
route via that router become unavailable, once the IGP converged to a new active route (from
another router), the label for the FEC received from that peer will be immediately used.
The Alcatel-Lucent 7x50 family supports Downstream Unsolicited label distribution for LDP.

All Rights Reserved 2011, Alcatel-Lucent


Section 3 Module 1 Page 10

LDP: Liberal Retention & Ordered Control Mode

Liberal Retention:

Ordered Control:

The label received from the router


providing the active IGP route for
the FEC is used and the other labels
are kept

The LSP will not pass data until the


setup messages have propagated from
end to end
Label

2.2.2.2/32

131065

LSR2

1.1.1.1/32
iLER
LIB

Prefix

Next-hop

Label

10.2.1.0/24

LSR 2

131065

10.2.1.0/24

LSR 3

131066

iLER

Prefix

Next-hop

10.2.1.0/24

LSR 3

Prefix

Next-hop

Label

10.2.1.0/24

LSR 3

131066

Label
131067

10.2.1.0/24
Step 1
LSR3
4.4.4.4/32

3 1 11

Step 1

iLER
LFIB

131066

Step 2

Label

iLER
FIB

Step 2

Label
131067

eLER
3.3.3.3/32

All Rights Reserved Alcatel-Lucent 2011

Liberal Retention mode


Using Liberal Label Retention mode, all label mappings received from all peer LSRs are saved.
This approach consumes more memory on the LSR, but has the benefit of faster convergence. If
the used label is lost, a label for the same FEC may have been previously received from another
peer and is already present on the router, without the need for signaling.

Ordered Control mode


In Ordered Control mode, LSP setup is initiated at one LSR and propagates from the eLER toward
the iLER. A feature of Ordered Control mode is that an LSP is not completely set up until the
associated control setup messages have propagated from end to end. As a consequence, data is
not sent on the LSP until it is known to be loop free.

All Rights Reserved 2011, Alcatel-Lucent


Section 3 Module 1 Page 11

LDP: Convergence

LSP before the failure


LSP after the failure

LSR2

1/1/2

1/1/3

LSR4

1000

LER2
10.10.10.1/32

LER1
LSR1
LER 1
LFIB

Prefix

10.10.10.1/32

Ingress
Label
-

Egress
Label

Egress
Interface

nexthop

MPLS Convergence =

131068

1/1/2

LSR 2

Failure Detection Time +


IGP Convergence +

LER 1
LFIB

Prefix
10.10.10.1/32

3 1 12

Ingress
Label
-

Egress
Label

Egress
Interface

nexthop

131065

1/1/3

LSR 1

LDP Convergence

All Rights Reserved Alcatel-Lucent 2011

IGP convergence requires a recalculation of the SPF algorithm and a new selection of the best
route. The IGP best route must then be offered to the Routing Table Manager (RTM) to
determine if this route is to be the active route and subsequently installed in the FIB.
In this case, the new best and active route to the destination 10.10.10.1/32 is the route via
LSR1. LDP convergence may then follow. One benefit of liberal label retention mode is that the
label previously received from the new best route is already installed in the LIB. It has been
present all along, but until IGP routing converges, the LFIB may not be populated.
Now that IGP routing has converged, the LFIB may use the label from LSR2 since the next-hop
now belongs to the active route.

All Rights Reserved 2011, Alcatel-Lucent


Section 3 Module 1 Page 12

LDP: Minimum Configuration

PE1

P1

P2
PE2
Provider
Network

PE-3
P3

3 1 13

All Rights Reserved Alcatel-Lucent 2011

All provider core facing interfaces must have LDP enabled. LDP must be enabled on each
routers interface, to allow direct LDP sessions to be established between adjacent routers.
Note that LDP is not enabled on the routers system interface.
Context:

config>router>ldp

Syntax:

interface-parameters

Description:

This command enables the context to configure LDP interfaces and parameters
applied to LDP interfaces.

Context:

config>router>ldp>if-params

Syntax:

[no] interface ip-int-name

Description:

This command enables LDP on the specified IP interface.

The no form of the command deletes the LDP interface and all configuration information
associated with the LDP interface. The LDP interface must be disabled using the shutdown
command before it can be deleted.
Parameters:

ip-int-name - The name of an existing interface.

All Rights Reserved 2011, Alcatel-Lucent


Section 3 Module 1 Page 13

RSVP-TE Resource Reservation Protocol Traffic Engineering

3 1 14

All Rights Reserved Alcatel-Lucent 2011

All Rights Reserved 2011, Alcatel-Lucent


Section 3 Module 1 Page 14

Resource Reservation Protocol - Traffic Engineering (RSVP-TE)

Advantage of using RSVP to establish LSP tunnels is that it enables the


allocation of resources along the path

 For example, bandwidth can be allocated to an LSP tunnel using standard


RSVP reservations and Integrated Services service classes


RSVP-TE includes Traffic Engineering Capabilities:


 Unlike LDP, RSVP-TE can be signaled over a desired path
 Desired amount of bandwidth can be requested for a specific traffic types

Fast Reroute Capabilities:


 One to One Backup a backup LSP is created separately for each protected
LSP
 Facility Backup A bypass tunnel is created to protect a set of LSPs passing
over a common facility

3 1 15

All Rights Reserved Alcatel-Lucent 2011

RSVP-TE operates in downstream-on-demand (DOD) label advertisement mode with ordered LSP control.


A request to bind labels to a specific LSP tunnel is initiated by an ingress node through the RSVP Path
message

Labels are requested downstream and distributed (propagated) upstream by means of the RSVP Resv
message

RSVP-TE is an MPLS signaling protocol based on the resource reservation protocol originally used for
signaling IP quality of service connections.
RSVP-TE defines a set of traffic engineering extensions to the Resource Reservation Protocol (RSVP)
standard. RSVP-TE extensions provide a method by which RSVP may be used for traffic engineering in
MPLS environments. These extensions add support for assigning MPLS labels and specifying explicit
paths as a sequence of loose and strict hops. These extensions are supported by providing a Label
Request field and an Explicit Route Objects field in the path message. The destination LSR responds to
a label request by providing a label object in its RESV message. Labels are then assigned at each
intermediate node which processes the reserve message. RSVP-TE operates in downstream-on-demand
(DoD) label advertisement mode with ordered LSP control.
Since the flow along an LSP is identified by the label applied at the ingress node of the path, these paths
may be treated as tunnels. A key application of LSP tunnels is traffic engineering with MPLS. The
resulting label switched tunnels can be automatically routed away from network failures, congestion,
and bottlenecks.

All Rights Reserved 2011, Alcatel-Lucent


Section 3 Module 1 Page 15

RSVP-TE: Message Types

Downstream on Demand (DoD)




2.2.2.2/32

iLER

Resv: label 131068

LSR2
4.4.4.4/32

3 1 16

LSR1

Path: 3.3.3.3

Path: 3.3.3.3

1.1.1.1/32

Resv: label 131071

PATH message sent


towards tunnel
destination
Receiver sends RESV
message back
towards sender
eLER sends label
binding info in RESV
message
Path Refresh and
RESV Refresh
messages are sent
periodically

eLER
3.3.3.3/32

All Rights Reserved Alcatel-Lucent 2011

RSVP is a network control protocol used by a host to request specific qualities of service from the
network for particular application data streams or flows. RSVP is also used by routers to deliver quality
of service (QoS) requests to all nodes along the path(s) of the flows and to establish and maintain state
to provide the requested service. RSVP requests generally result in resources reserved in each node
along the data path. MPLS leverages this RSVP mechanism to set up traffic engineered LSPs. RSVP
requests resources for simplex flows. It requests resources in only one direction (unidirectional).
RSVP treats a sender as logically distinct from a receiver, although the same application process may
act as both a sender and a receiver at the same time. Duplex flows require two LSPs, one to carry
traffic in each direction. RSVP is not a routing protocol, it operates with unicast and multicast routing
protocols. Routing protocols determine where packets are forwarded and RSVP consults local routing
tables to relay RSVP messages.
The sender (the ingress LER), sends PATH messages toward the receiver (the egress LER) to indicate the
FEC for which label bindings are desired. PATH messages are used to signal and request label bindings
required to establish the LSP from ingress to egress. Each router along the path observes the traffic
type. PATH messages facilitate the routers along the path to make the necessary bandwidth
reservations and distribute the label binding to the router upstream. The egress LER sends label
binding information in the RESV messages in response to PATH messages received. The LSP is
considered operational when the ingress LER receives the label binding information.

All Rights Reserved 2011, Alcatel-Lucent


Section 3 Module 1 Page 16

RSVP-TE: Label allocation

iLabel eLabel Action


--131068 Push

iLabel eLabel Action


131068 131071 Swap
2.2.2.2/32
LSR1

Label Switched Path


Label Switched Path

After the Resv


message is
propagated
upstream to the
sender node, a
label-switched path
is effectively
established

1.1.1.1/32
iLER

eLER
3.3.3.3/32
LSR2
4.4.4.4/32

3 1 17

iLabel eLabel Action


131071 --- Pop

All Rights Reserved Alcatel-Lucent 2011

RSVP Path messages use a label request attribute and await a label reply in the RSVP Resv message.
Once the Resv message is received, a label mapping is created in the LIB which provides a POP, SWAP,
or Push action. The terminology of ingress or egress label is used with respect to the data plane of the
packet flow.
Once an LSP is established, the traffic through the path is defined by the label applied at the ingress
node of the LSP. The set of packets that are assigned the same label value by a specific node are
considered to belong to the same FEC which defines the RSVP flow.

All Rights Reserved 2011, Alcatel-Lucent


Section 3 Module 1 Page 17

RSVP-TE: Optional object Explicit Route Object: ERO

RSVP Path

ERO provides specific


path information for
the RSVP Path
message to follow
If ERO is not present
then IGP determines
the RSVP Path
ERO can be manually
provided or computed
based on RSVP
requirements such as
bandwidth, hop limit,
link coloring

3 1 18

LSP Tunnel (IPv4)


Label_Request
ERO: 10.12.1.2
10.23.1.3
10.34.1.4
4.4.4.4
Session_Attributes

1.1.1.1/32
PE1
.1

2.2.2.2/32
PE2

RRO: 10.12.1.1

.2

RSVP Path

10.12.1.0/29

10.14.1.29/29

10
.13
.1.
0 /2
.1
9

10.23.1.0/29

9
0/2
.1.
4
.2
10
10.34.1.0/29
1/1/2

.3

RSVP Path

.3

.4

.4
PE4
4.4.4.4/32

.2

LSP Tunnel (IPv4)


Label_Request
ERO: 10.12.1.2
10.23.1.3
10.34.1.4
4.4.4.4
Session_Attributes
RRO: 10.34.1.3
10.23.1.2
10.12.1.1

LSP Tunnel (IPv4)


Label_Request
ERO: 10.12.1.2
10.23.1.3
10.34.1.4
4.4.4.4
Session_Attributes
RRO: 10.23.1.2
10.12.1.1

PE3
3.3.3.3/32

All Rights Reserved Alcatel-Lucent 2011

An RSVP PATH message contains a number of objects:


Label Request Object (Mandatory)
 Request intermediate and receiver nodes to provide a label binding for the session
 If a node does not supported this object or is incapable of providing a label binding, it sends
a PathErr message to the ILER
Explicit Route Object (ERO) (optional)
 Sent in the PATH message to specify the path to be followed independent of the IGP
shortest path
 If ERO is not present then IGP is used to follow the path
 Can be manually provided or computed based on RSVP requirements such as
QoS and policy criteria
 Stored in the path state block on each node along the path
Record Route Object (RRO) (optional)
 Records hop-by-hop path information
 Allows the sender and receiver to know the actual route that the LSP tunnel traverses
 May be used for loop detection
Session Attribute Object (optional)
 Includes control information such as the path setup and hold priorities and local-protection

All Rights Reserved 2011, Alcatel-Lucent


Section 3 Module 1 Page 18

RSVP-TE: Optional object Record Route Object: RRO

RSVP Resv

Record Route
Object (RRO) of
RSVP-TE is used for
route recording
purpose

1.1.1.1/32
PE1
.1

 RRO records the


actual route a
packet traversed


LSP Tunnel (IPv4)


Label: 65
Session_Attributes
RRO: 10.12.1.2
10.23.1.3
10.34.1.4

2.2.2.2/32
PE2
.2

10.12.1.0/29
10
.13
.1.
0 /2
.1
.2
9
10.23.1.0/29
10.14.1.29/29
9
.3
.4
0/2
.1.
4
.2
10
10.34.1.0/29

Recording the path


allows the iLER to
know, on a hop-byhop basis, which
LSRs the path
traverses

.4
PE4
4.4.4.4/32

3 1 19

RSVP Resv

RSVP Resv
LSP Tunnel (IPv4)
Label: 13
Session_Attributes
RRO: 10.23.1.3
10.34.1.4

.3

LSP Tunnel (IPv4)


Label: 100
Session_Attributes
RRO: 10.34.1.4

PE3
3.3.3.3/32

All Rights Reserved Alcatel-Lucent 2011

The RSVP RESV message is sent back upstream to the ILER following the path created by the PATH
message, in reverse order. It contains a number of objects:
Label Object (Mandatory)


Sent in response to a PATH message including a Label Request

A node receiving a Label object uses that label for outgoing traffic associated with this LSP tunnel

If the node is not ILER, it allocates a new label and places it in the LABEL object sent upstream

Record Route Object (RRO) (Optional)




Used by the RESV message to follow the same set of hops back to the RSVP originator, reserving
resources along the path and confirming the tunnel creation

Session Attribute Object (Optional)




Includes control information

All Rights Reserved 2011, Alcatel-Lucent


Section 3 Module 1 Page 19

RSVP-TE: The Alcatel-Lucent CSPF Implementation

The Constraint-based Shortest Path First (CSPF) functionality provides


the capability to traffic engineer LSPs based on the following
constraints:
 Link constraints (include/exclude)
 Bandwidth requirements
 Hop count limitations

Enable Traffic-engineering on OSPF:


config>router>ospf# traffic-engineering

3 1 20

All Rights Reserved Alcatel-Lucent 2011

All Rights Reserved 2011, Alcatel-Lucent


Section 3 Module 1 Page 20

RSVP-TE: Signaled LSPs with CSPF

TE Capable IGP
OSPF-TE
IS-IS-TE

Routing Table

Traffic
Engineering
Database (TED)

Constrained
Shortest Path First
(CSPF)

User
Requirements

Explicit Route
Object
(ERO)

Signaling

3 1 21

All Rights Reserved Alcatel-Lucent 2011

CSPF LSP
The Constraint-based Shortest Path First (CSPF) process is an extension to the SPF process
performed by link state routing protocols. The CSPF calculation uses constraints, obtained from
the traffic engineering database (TED) and local input, to compute the shortest path through
the network that matches the configured requirements. Once a path is found by CSPF, the
explicit route object (ERO) in the RSVP message is updated with the path requirement
information and RSVP uses the CSPF path to request the LSP set up.
Constraints taken into account by CSPF include:


Admin groups, including link colors and resource classes (from TED)

Bandwidth

Hop limits

The CSPF algorithm can be enabled during the configuration of an LSP:


config>router>mpls>lsp>cspf
CSPF is also used to calculate the detour routes when fast-reroute is enabled (avoiding a
particular link is a constraint as well). Fast Reroute is covered further in the course.

All Rights Reserved 2011, Alcatel-Lucent


Section 3 Module 1 Page 21

RSVP-TE: LSP Configuration

10.10.43.3

10.10.42.3

10.10.10.101

10.10.10.99

10.10.10.102
10.10.44.3
10.10.10.100

10.10.10.103

RSVP PATH
Primary_Path
config>router# mpls
config>router>mpls#lsp LSP_99_103
config>router>mpls>lsp# to 10.10.10.103
config>router>mpls>lsp# cspf
config>router>mpls>lsp# primary Primary_Path"
config>router>mpls>lsp>primary# hop-limit 4
config>router>mpls>lsp>primary# bandwidth 256
config>router>mpls>lsp>primary# no shutdown
3 1 22

All Rights Reserved Alcatel-Lucent 2011

1. Enable TE on OSPF


CSPF must be enabled if constraint-based LSPs are required or if FRR is to be used

2. Enable MPLS on the router




MPLS is automatically enabled upon creation

The system interface is automatically added into the MPLS instance

3. Configure MPLS on the network interfaces




Interfaces must already be configured

RSVP is enabled by default with MPLS

4. Create an MPLS Path




The path is a list of constraints that are applied to an LSP

A path can be used by multiple LSPs

5. Configure an MPLS LSP


1.

Specify the IP address of the egress router

2.

Specify the primary MPLS path to be used

3.

Specify bandwidth/hop limit/admin group constraints, if any

4.

Specify any secondary paths

All Rights Reserved 2011, Alcatel-Lucent


Section 3 Module 1 Page 22

RSVP-TE: Strict versus Loose hops

Example of strict and loose path


 Blue path => ERO (Explicit Route Object) defines strict hops
 ERO explicitly defines the path PE2 => PE3 => PE4


Red Path => ERO defines only loose hops


 ERO defines only 4.4.4.4 as loose
1.1.1.1/32

Blue Path

2.2.2.2/32

PE1

PE2
10.12.1.2

Red Path

10.23.1.3

10.34.1.4
PE4
4.4.4.4/32
3 1 23

All Rights Reserved Alcatel-Lucent 2011

Strict => next hop address must be directly connected


Loose => next hop does not need to be directly connected
The following example displays path command usage:
Example at PE1: config>router# mpls
config>router>mpls# path toPE4_blue_strict
config>router>mpls>path$ hop 1 10.12.1.2 strict
config>router>mpls>path# hop 2 10.23.1.3 strict
config>router>mpls>path# hop 3 10.34.1.4 strict
config>router>mpls>path# no shutdown
config>router>mpls>path# exit
config>router>mpls# path toPE4_red_loose"
config>router>mpls>path# hop 1 4.4.4.4 loose
config>router>mpls>path# no shutdown

All Rights Reserved 2011, Alcatel-Lucent


Section 3 Module 1 Page 23

PE3
3.3.3.3/32

LSP Redundancy
Primary

LSP Path

 One primary path per LSP


 Can be protected by up to 2 secondary LSPs
Secondary

LSP Path

 Alternative path that the LSP uses when the primary path is not
available
 When the primary path is re-established, the traffic is switched back
to the primary path
 Up to 2 secondary paths can be specified
 Both secondary paths are considered equal and the first available
path is used
 No switch back among secondary paths
 Similar to the primary path: reserved bandwidth, hop-limit count
and inclusion/exclusion of admin groups may be specified
3 1 24

All Rights Reserved Alcatel-Lucent 2011

The following parameters can be configured for primary and secondary LSPs:
 Bandwidth . the amount of bandwidth needed for the secondary LSP can be

reserved and can be any value; it does not need to be identical to the value reserved
by the primary LSP. Bandwidth reservation can be set to 0, which is equivalent to
reserving no bandwidth.
 Inclusion and exclusion of nodes . by including or excluding certain nodes, you

can ensure that the primary and secondary LSPs do not traverse the same nodes and
therefore ensure successful recovery. Each secondary LSP can have its own list of
included and excluded nodes.
 Hop limit . the hop limit is the maximum number of LSR nodes that a secondary

LSP can traverse, including the ingress and egress LER nodes
 Standby (secondary LSPs only) . when a secondary LSP is configured for standby

mode, it is signaled immediately and is ready to take over traffic the moment the
LER learns of a primary LSP failure. This mode is also called hot-standby mode.
When a secondary LSP is not in standby mode, then it is only signaled when the
primary LSP fails. If there is more than one secondary LSP, they are all signaled at
the same time (upon detection of a primary LSP failure) and the first one to come up
is used.
All Rights Reserved 2011, Alcatel-Lucent
Section 3 Module 1 Page 24

LSP with Secondary Path

LSP 1 Primary
Path

LSP 1 Secondary
Path

Secondary LSP Path in Standby


 Path is signaled and maintained indefinitely in a hot-standby state
 Double reservation of resources
 Reduced latency associated with a failed path

Secondary LSP Path Non-Standby


 Path is not signaled until a network failure causes the primary path to fail
 When the ILER node is aware of the failure, it signals the secondary path to
become active
 No double reserving of resources
 Increased latency associated with recovering a failed path

3 1 25

All Rights Reserved Alcatel-Lucent 2011

config>router>mpls>lsp# secondary Secondary_Path"


config>router>mpls>lsp>primary# hop-limit 4
config>router>mpls>lsp>primary# bandwidth 256
config>router>mpls>lsp>primary# no shutdown

All Rights Reserved 2011, Alcatel-Lucent


Section 3 Module 1 Page 25

Fast Re-Route (FRR)

3 1 26

All Rights Reserved Alcatel-Lucent 2011

All Rights Reserved 2011, Alcatel-Lucent


Section 3 Module 1 Page 26

Fast Reroute Overview




Disadvantages of Secondary Path only Protection

 Failure downstream might take a while to reach the head of LSP


 Double booking of resources
 No selective protection of node or link







Fast Reroute (FRR) is used to establish backup label-switched path


(LSP) tunnels for local repair of LSP tunnels
FRR defines ways of pre-configuring and signaling backup paths before a
failure
The mechanisms enable the redirection of traffic onto backup LSP
tunnels within 50 msec upon failure
When Fast Reroute is enabled, each node along the path of the LSP
tries to establish a backup LSP
FRR is only available for the Primary path
CSPF must be enabled for FRR to work

3 1 27

All Rights Reserved Alcatel-Lucent 2011

When Fast Reroute is enabled, each node along the path of the LSP tries to establish a backup LSP

Each upstream node sets up a backup LSP that avoids only the immediate downstream node ( by
default node protection is enabled)
The Point of Local Repair (PLR) looks for the backup path which merges back to the protected LSP
sooner

i.e., the Merge Point (MP) is closer to the PLR

The backup LSP may take one or more hops merging back to the main LSP or it may only merge at
the eLER
If it is not possible to set up a backup LSP that avoids the immediate downstream node, a backup
can be set up to the downstream node on a different interface

In case of failure, traffic is immediately rerouted by the PLR onto the pre-computed backup LSP,
minimizing packet-loss

When the upstream node (ILER) is informed by the PLR that a downstream router is using its backup
LSP, the iLER switches traffic to a standby path if one was set up for the LSP

A locally repaired LSP (i.e., using the backup path) will try to globally revert back when the retry
timer expires

FRR is only available for primary path

No configuration is required on the transit hops of the LSP (except Manual Bypass Tunnel)

CSPF must be enabled for Fast Reroute to work

All Rights Reserved 2011, Alcatel-Lucent


Section 3 Module 1 Page 27

RSVP-TE: LSP Protection

Path Protection
 Primary LSP with Secondary LSP
 Primary LSP with Secondary Standby LSP

Fast Reroute
 One-to-One Backup
 Facilities Backup

3 1 28

All Rights Reserved Alcatel-Lucent 2011

An important concept of RSVP-TE LSPs is the ability for fast recovery, unlike LDP that is
dependent on the re-convergence time of the underlying IGP.
Next to a primary path, up to 8 secondary paths can be defined, should the primary path
become unavailable due to link or node failures in along its path. Once the iLER notices a
problem further along the primary path, it will switch the traffic to a secondary path that can
be configured (non-standby) or configured and signalled in advance (hot standby).
For even faster, sub 50 ms, convergence, Fast Reroute can be activated. Fast Reroute provides a
backup path for every link or node on the path so when a link or node failure occurs, every
node can instantly switch to this backup temporarily until the iLER decides to use the
secondary path.

All Rights Reserved 2011, Alcatel-Lucent


Section 3 Module 1 Page 28

RSVP-TE: Backup LSP LSPs with Secondary Path


Secondary Path: Non-standby or Hot-standby

Failure in primary path triggers secondary LSP


PathErr

R3

R2

R1
R6

R9
R7

Primary LSP:
R1->R2->R3->R4

R4

R8
Secondary LSP:




Primary LSP: One primary path


R1->R6->R7->R8->R9->R4
Secondary LSP
 Alternative path that is used if the primary path is not available.
 Non-Standby  needs to be signaled first (after primary path failure detection
 Hot-Standby  will be signaled upon creation
 Continuously tries to revert back to the primary path.
 Up to 8 secondary paths can be specified.
 All the secondary paths are considered equal and the first available path is used.
 The software will not switch back among secondary paths.
3 1 29

All Rights Reserved Alcatel-Lucent 2011

There can be only one Primary Path defined for a Label Switched Path. This primary path is the
main path for the LSP and will be used in normal conditions.
If for any reason this primary path has become unavailable, up to 7 additional paths can be
defined to take over. If a secondary path is configured as hot-standby the labels for this path
have been signaled and maintained upon creation which results in faster convergence but fewer
labels left. This is a trade-off the network designer has to decide on. When the secondary path
of the LSP is not in standby it will be signaled the moment a network failure causes the primary
path to fail, and the Head-end node is made aware of the failure. After the switch over from the
primary to the secondary, the software continuously tries to revert to the primary path. Up to 8
paths can be specified and are considered equal with the first available path being used. The
software will not switch back among secondary paths. The Primary and Secondary paths can be
configured with strict or loose hops, or with no hops specified.

All Rights Reserved 2011, Alcatel-Lucent


Section 3 Module 1 Page 29

RSVP-TE: LSP Protection with a Secondary Path

Pros
 Deterministic data flow during any point in primary path
 Multiple failures along the primary path can be handled by the same
secondary path
 When statically configured, no nodes or links should be shared by the
Primary and Secondary paths (otherwise if that link or node goes down, both
are lost)
 Entire path is protected

Cons
 Notification of a link or node failure might take a while to reach head of
tunnel
 Full path resources are reserved over both Primary and Secondary paths,
therefore double booking
 Selective protection of link or node is not possible, only end-to-end

3 1 30

All Rights Reserved Alcatel-Lucent 2011

Primary and Secondary paths, when statically configured, are deterministic and will allow
specific path protection as configured. The benefit to configuring Primary and Secondary paths
is that path protection is guaranteed regardless of the location of the failure or if multiple
failures exist. When statically configuring the Primary and Secondary paths, it is not advisable to
configure common links since the failure of the common link will result in the failure of both
LSPs. However, if the Primary and Secondary LSP are created using a Loose path, or if portions
of the LSPs are making use of Loose path then it is entirely possible that the IGP path chosen will
cause both LSPs to make use of a common link.
Primary and Secondary paths protect the entire path. However, a failure anywhere along the
path requires the LSP head end to be notified that a failure has occurred. Its only the LSP head
end that can signal the activation of the Secondary LSP. It might take some time for the head of
the LSP to be notified that a failure has occurred downstream. Furthermore, by creating Primary
and Secondary paths, network resources are being reserved for each LSP. This results in double
booking the resources and overstating the actual resource utilization for the network,
especially with hot standby secondary LSPs.

All Rights Reserved 2011, Alcatel-Lucent


Section 3 Module 1 Page 30

FRR: One-to-one Backup Method Multiple LSPs

R10
PLR

R3
R2

R1

MP
PLR

PLR

R5

MP

R4
MP

(2)

(1)
R9

R6

R7

R8

(1)
Protected LSP 1:
R1->R2->R3->R4

R2s backup for Protected LSP 1


R2->R7->R8->R9->R4

(2)
Protected LSP 2:
R10->R2->R3->R4

3 1 31

R2s backup for Protected LSP 2


R2->R7->R8->R9->R4

All Rights Reserved Alcatel-Lucent 2011

In the case of a one-to-one backup every LSP will create its own detour LSPs to protect itself.
As shown above, only Point of Local Repair (PLR) R2 is shown (R11 and R3 will also create detour
LSPs), two different LSPs with their own labels will be created and have the same Merge Point
(the point where the detour merges with the original path), R4 in this example. The Facility
Backup method, explained further in this course, will only create one bypass and therefore use
less labels then the One-to-one Backup method.

All Rights Reserved 2011, Alcatel-Lucent


Section 3 Module 1 Page 31

FRR: One-to-one Backup Method Path Setup

PLR

R1

R3
R2

PLR

Merge Point
(MP)

(3)

R5

R4

PLR

(2)

(1)
R6

R9
R7

R8

Detour Tunnel
(1)
R1s backup:
R1->R6->R7->R8->R9->R4
Protected LSP:
R1->R2->R3->R4

3 1 32

(2)

(3)
R3s backup:
R3->R9->R4

R2s backup:
R2->R7->R8->R9->R4

All Rights Reserved Alcatel-Lucent 2011

One-to-one backup: Each router along the LSP path establishes a detour LSP that is the best path
to the destination node that avoids the node and/or link at the point of failure. For each LSP
which is backed up, a separate backup LSP is established.
In the example above, the protected LSP runs from R1 to R4. Router R2 can provide user traffic
protection by creating a partial backup LSP which is the best path to R4 that avoids the link
between R2 & R3 (in case of link protection) and the node R3 (in case of node protection). The
partial one-to-one backup LSP [R2->R7->R8->R9->R4] is referred as a detour.
To fully protect an LSP that traverses N nodes, there could be as many as (N - 1) detours. The
paths for the detours necessary to fully protect the LSP in the above example are shown.

All Rights Reserved 2011, Alcatel-Lucent


Section 3 Module 1 Page 32

FRR: One-to-One Backup Method Label Exchange

Inner
label

Inner
label

21

PLR

R1

21

Inner
label

32
R3

R2 32

54

54
MP

R4
159

172

198

187

R9
Protected LSP:
R1->R2->R3->R4

R2s backup:
R2->R7->R8->R9->R4

3 1 33

R7

R8

Control Plane
(label propagation)

All Rights Reserved Alcatel-Lucent 2011

Labels along the Protected LSP path are advertised along the control plane according to common
label propagation rules. Similarly, labels are propagated along the backup path in the same
manner. CSPF is needed to perform these operation and is enable automatically on the transit
routers.
Therefore, the backup path is signaled, established, and prepared for the eventuality of a failed
link. The only difference between the primary LSP and the backup LSP is that the primary LSP is
being used in the data plane while the backup LSP is not.
If the link R2-R3 fails or if the node R3 fails, the PLR (R2) will swap incoming packets that have
label 21 with label 172 and send it out the interface to R7. The MP (R4) will recognize that the
packets arriving on its interface to R9 with label 159 must be POPped since it is the termination
point of the protected LSP.

All Rights Reserved 2011, Alcatel-Lucent


Section 3 Module 1 Page 33

FRR: One-to-One Backup Method Link/Node Failure

Inner
label

R1

Inner
label

32

54

R3

R2 PLR

21

Inner
label

Inner
label

21

X
21

MP

R4
159

172

Inner
label

198

187

Inner
label

172

159

R9

R7

R8
Inner
label

187

Inner
label

198

Protected LSP:
R1->R2->R3->R4

R2s backup:
R2->R7->R8->R9->R4

3 1 34

Control Plane
(label propagation)
All Rights Reserved Alcatel-Lucent 2011

If the link R2-R3 should fail, the PLR will warn the upstream iLER about this failure and will swap
the traffic over the detour LSP by swapping the outer label to the label received from R7 when
the detour was created earlier. The label stack depth is unchanged (as opposed to the Facility
Bypass method), only the outer label will have a different value (and a different egress
interface).
The Merge Point (MP) router R4 will receive the traffic with a different transport label over a
different ingress interface as before the link failure.

All Rights Reserved 2011, Alcatel-Lucent


Section 3 Module 1 Page 34

FRR: Facility Backup Method Link Protection

R10
R3
R2
R1

MP

PLR

R4

R9

R6

R7

Protected LSP 1:
R1->R2->R3->R4

R8

Bypass tunnel
R2->R7->R8->R3

Protected LSP 2:
R10->R2->R3->R4

3 1 35

All Rights Reserved Alcatel-Lucent 2011

The facility backup technique uses a different approach. Instead of creating a separate LSP for
every backed-up LSP, a single LSP is created which serves to backup up a number of LSPs. We
call such an LSP tunnel a bypass tunnel. The advantage of this method is the efficient use of
labels in comparison with the One-to-one Backup method.
When such a bypass tunnel is created from a PLR to a downstream MP all the original LSPs using
this partial path are candidates to use this bypass tunnel to protect themselves.
In the above example, R2 has built a bypass tunnel which protects against the failure of link R2R3. The doubled lines represent this tunnel. Both the protected LSPs, regardless of their source
and destination endpoints, can use this bypass tunnel, which provides a scalability improvement.
As with the one-to-one technique, to fully protect an LSP that traverses N nodes, there could be
as many as (N-1) bypass tunnels. However, each of those bypass tunnels could protect a set of
LSPs.

All Rights Reserved 2011, Alcatel-Lucent


Section 3 Module 1 Page 35

FRR: Facility Backup Link Protection Label Exchange

Works
Worksthe
thesame
sameas
asOne-to-One
One-to-OneBackup
Backupunder
undernormal
normaloperating
operatingconditions
conditions
Inner
label

PLR

21

R2

21

Inner
label

Inner
label

32
R3

32

MP

54

54

R1

R4
172
138

Protected LSP:
R1->R2->R3->R4

R2s backup:
R2->R7->R8->R3

3 1 36

R7 187

R8

Control Plane
(label propagation)

All Rights Reserved Alcatel-Lucent 2011

The data plane functions the same way in the stable LSP scenario as it did during the One-toOne backup method. The control plane prepares a bypass tunnel by signaling available labels
from the MP to the PLR as a response to the PLRs RSVP-TE DoD request.

All Rights Reserved 2011, Alcatel-Lucent


Section 3 Module 1 Page 36

FRR: Facility Backup Link Failure

MP
MPreceives
receivessame
samelabel
labelfrom
frombackup
backuplink
linkas
asititwould
wouldfrom
fromPrimary
PrimaryLSP
LSP

Inner
label

21

21

Inner
label

32

PLR 32

R2

R1

R3

Protected LSP:
R1->R2->R3->R4

R2s backup:
R2->R7->R8->R3

3 1 37

54

54

R4

172
Inner
label

Inner
label

MP

Inner
label

32 172

32 138

138

R7 187
Inner
label

R8

32 187

Control Plane
(label propagation)
All Rights Reserved Alcatel-Lucent 2011

The example above demonstrates the Facility Backup method. If the link R2-R3 should fail, the
PLR will first SWAP the outer label to label 32 because this is the label R3 would expect. On top
of that label, the label 172 is PUSHed and the label stack has increased with one extra label.
This packet will be sent over the backup egress interface and all the intermediate routers of the
bypass tunnel (R7 and R8) will perform the normal swap operations on this extra outer label. It is
the MP that will POP this label, investigate the 32 label and perform the SWAP like in normal
operation.
This method allows the tunneling of multiple LSPs through the bypass and improves the
scalability of the Protected paths.

All Rights Reserved 2011, Alcatel-Lucent


Section 3 Module 1 Page 37

End of Module/Lesson
MPLS

3 1 38

All Rights Reserved Alcatel-Lucent 2011

All Rights Reserved 2011, Alcatel-Lucent


Section 3 Module 1 Page 38

Do not delete this graphic elements in here:

41

Section 4.1
Services Overview

All Rights Reserved Alcatel-Lucent 2011

All Rights Reserved 2011, Alcatel-Lucent


Section 4 Modue 1 Page 1

Objectives
Upon successful completion of this module, you will be able to
describe:

Service components




412

Service Access Points (SAP)


Service Distribution Paths (SDP)
Service tunnels and labels

MTU considerations

All Rights Reserved Alcatel-Lucent 2011

All Rights Reserved 2011, Alcatel-Lucent


Section 4 Modue 1 Page 2

Services Service Configuration Model

413

All Rights Reserved Alcatel-Lucent 2011

All Rights Reserved 2011, Alcatel-Lucent


Section 4 Modue 1 Page 3

Service Configuration Model




To provision a service, the following must be defined:







Customer
100

Customer
Service Type
Service Access Point (SAP) A Services logical entry/exit point
Service Distribution Point (SDP) A unidirectional connection between
services distributed across an MPLS network
SAP

Label Switched Path

SDP 3

SAP
Demux

Service 50

Customer
100

Service 50
Label Switched Path

Demux

Tunnels are unidirectional


and are paired to provide a
bi-directional service

SAP is the
customer point of access

414

SDP 3

SDP binds multiple


services to a tunnel

All Rights Reserved Alcatel-Lucent 2011

Consider the following when configuring a SAP:




A SAP is locally unique, in other words the same SAP ID value may be used on another device

A SAP is associated with a single service and can only be configured on an access port

A port or channel can have more than one SAP configured on it

All SAPs must be explicitly created and are administratively enabled at the time of creation (no
default SAPs)

VLAN IDs have local significance.

A SAP can be configured with an:




Ingress and egress filter policy

Ingress and egress QoS policy

Ingress and egress scheduler policy

Accounting policy

Consider the following SDP characteristics:




SDPs can be created as either GRE or MPLS.

Each multi-site service must have an SDP defined for every remote PE to provide Epipe, VPLS, and
VPRN services.

A service must be bound to an SDP. By default, no SDP is associated with a service. Once an SDP is
created, services can be associated with that SDP.

An SDP is not specific or exclusive to any one service or any type of service. An SDP can have more
than one service bound to it.

In order to configure an MPLS SDP, an MPLS infrastructure must be in place.

In the SDP configuration, automatic ingress and egress labeling (targeted LDP) is enabled by default.
Ingress and egress VC labels are signaled over a TLDP connection between two PE routers.
All Rights Reserved 2011, Alcatel-Lucent
Section 4 Modue 1 Page 4

Note: if signaling on an SDP is disabled, service labels must be manually configured.

Ethertype


The Ethertype field describes the payload of the ethernet frame


Ethertype for some Protocol
common Protocols

0x0800

Internet Protocol, Version 4 (IPv4)

0x0806

Address Resolution Protocol (ARP)

0x8100

VLAN Tagging (Dot1Q)

0x9100

VLAN Tagging (QinQ)

0x86DD

IPv6

0x8847

MPLS unicast

0x88a8

Provider Bridging

For example Etype 8447 identifies this packet as Unicast MPLS


0

DA

SA

0x8847

MPLS
Label

VC
Label

Payload FCS

Ethertype MPLS (8847)

1536

Etype

415

All Rights Reserved Alcatel-Lucent 2011

EtherType numbering generally starts from 0x0800. In the example used, Etype 8847 idicates
a unicast MPLS ethernet frame. As we have seen, an MPLS header includes a MPLS Label and
Virtual Circuit id. When the 7750 SR looks at the etype field and sees 8847, immediately the
following applies:
Service Payload / MTU: 1514 bytes
MPLS tag used as service label: 4 bytes
MPLS tag used for transport label: 4 bytes
DLC Header: 14 bytes
______________________________
1536 bytes

All Rights Reserved 2011, Alcatel-Lucent


Section 4 Modue 1 Page 5

Service Configuration Model




An inner label (VC Label / Service Label) is used to identify traffic as it


exits the MPLS network
 Each Service is identified by a unique label
 Incoming traffic is passed to the appropriate service based on the VC Label
Egress and ingress VC labels
uniquely identifies the service
DA

DA

SA

0x0800

SA

MPLS
Label

0x8847

VC
Label

DA

SA

0x0800

payload

payload

DA

SA

SAP

payload

SAP
SDP 3

Label Switched Path

Demux

Service 50

Service 50
Demux

416

0x0800

Label Switched Path

SDP 3

All Rights Reserved Alcatel-Lucent 2011

When an SDP is configured, automatic ingress and egress labeling (targeted LDP) is enabled by default
and ingress and egress service labels are signaled over a TLDP connection. If signaling is turned off on
an SDP, ingress and egress service labels must be manually configured when the SDP is bound to a
service.

All Rights Reserved 2011, Alcatel-Lucent


Section 4 Modue 1 Page 6

Tunnel Encapsulation

Generic Routing Encapsulation (GRE)


 Encapsulates traffic in an IP/GRE header; appears like an IP
packet.
 Low control plane overhead.
 Uses normal IP routing to find a path.

Multi Protocol Label Switching (MPLS)







Uses LDP or RSVP for label signaling.


LDP auto-bind available to simplify configuration.
LDP relies on an IGP to find its path
RSVP





Requires manual configuration


Can be loose or strict
May reserve bandwidth
Can use Fast ReRoute to speed convergence

417

All Rights Reserved Alcatel-Lucent 2011

SDP Encapsulation
Generic Routing Encapsulation




Low control plane overhead


Uses an IGP (ie. OSPF, IS-IS) to find a path from edge to edge
Convergence depends on the IGP

MPLS



Uses Label Switched Paths (LSP). Primary and secondary paths provide LSP protection).
Paths can be manually configured or signalled using LDP or RSVP-TE

All Rights Reserved 2011, Alcatel-Lucent


Section 4 Modue 1 Page 7

Configuring SDPs
Creating

config>service>sdp sdp-id [gre


| mpls]
description descriptionstring
far-end ip-addr
keep-alive
ldp (only for MPLS SDPs)
lsp lsp-name [lsp-name]
(only for MPLS SDPs)
signaling {off|tldp}
no shutdown

418

an SDP for MPLS (RSVP-TE)

config>service# sdp 8 mpls create


config>service>sdp# far-end 10.10.10.104
config>service>sdp# lsp "to-104"
config>service>sdp# no shutdown
Creating

an SDP with MPLS LDP

config>service# sdp 104 mpls create


config>service>sdp# far-end 10.10.10.94
config>service>sdp# ldp
config>service>sdp# no shutdown
config>service>sdp# exit
Creating

an SDP with GRE

config>service# sdp 122 gre create


config>service>sdp$ far-end 10.10.10.122
config>service>sdp$ no shutdown

All Rights Reserved Alcatel-Lucent 2011

Creating an SDP for GRE


config>service# sdp
config>service>sdp#
config>service>sdp#
config>service>sdp#

2 gre create
description to-GRE-10.10.10.104
far-end 10.10.10.104
no shutdown

Creating an SDP for MPLS (RSVP-TE)


config>service# sdp 8 mpls create
config>service>sdp# description "MPLS-10.10.10.104"
config>service>sdp# far-end 10.10.10.104
config>service>sdp# lsp "to-104"
config>service>sdp# no shutdown
Creating an SDP for MPLS (LDP)
config>service# sdp 104 mpls create
config>service>sdp# description "MPLS-10.10.10.94"
config>service>sdp# far-end 10.10.10.94
config>service>sdp# ldp
config>service>sdp# no shutdown
Creating an SDP with MPLS Static LSP

config>service# sdp 8 mpls create


config>service>sdp# far-end 10.10.10.104
config>service>sdp# lsp "to-104"
config>service>sdp# no shutdown
config>service>sdp# exit

All Rights Reserved 2011, Alcatel-Lucent


Section 4 Modue 1 Page 8

Services Summary: SAP to SDP

Create
an SDP

MPLS

Create a
Pseudowire
Service

Customer

GRE

Apipe

Cpipe

Assign a
Spoke-SDP

Epipe

Ipipe

ATM
VCC VPC

CESoPSN SAToP

IMA

TDM

Ethernet

IP

E1 CAS

VCC VPC

E1

DS1

Null dot1q Ethernet PPP/MLPPP

CAS Channelized Unchannelized

419

Assign a
SAP

All Rights Reserved Alcatel-Lucent 2011

All Rights Reserved 2011, Alcatel-Lucent


Section 4 Modue 1 Page 9

Null dot1q

IPCP

Maximum Transfer Unit (MTU) Considerations

 Port MTU: Determines maximum packet size on a given physical wire.


 Service MTU: Associated with a service and determines the maximum packet size
that can be sent from the customer across the service.

 SDP Path MTU: This is the MTU of the SDP between the service endpoints;
determines the maximum packet size that can be sent over the SDP.

 VC-MTU: Negotiated by T-LDP; the maximum IP payload size that can be carried
inside the tunnel. Derived from Service MTU.

 IP-MTU: Used by IES and VPRN interfaces for spoke-SDP terminations; should be
equal to the VC-MTU of the spoked Epipe/VPLS.

First 4 MTU values are important to get Services in the Operational UP state

4 1 10

All Rights Reserved Alcatel-Lucent 2011

All data links including both physical circuits and pseudo wires have MTUs associated with them.
Pseudo wires can be built using either MPLS or GRE.
Service MTUs must match in order for spoke or mesh sdps to become operationally UP even if
SDP MTUs match. A special case is a spoke-sdp to an IES service from a VPLS service.
Service providers should select a large backbone MTU for all links internal to their backbone.
The selected MTU needs to be supported on all platforms in the backbone. A POS MTU value of
4470 is a suggested minimum, a larger value such as 9000 would be even better. An MTU value
of 9000 is supported by most vendors and would allow a jumbo-frame service of 8000 or more
bytes to those customers who want it.
The LSP path MTU is derived from the network port MTU and cannot be configured. In the case
of Ethernet null encapsulation the LSP path MTU = Port MTU 14.

All Rights Reserved 2011, Alcatel-Lucent


Section 4 Modue 1 Page 10

L2 Service MTUs (Ethernet)

Optional (Null/dot1Q/QinQ)
(will be stripped)

No fragmentation possible
DA

DA

payload

FCS

Access Port MTU

Ether
Type

SA

Ether
802.1q
Type

SA

payload

FCS

Service MTU

Network
Interface
Port
MTU

(*)

DA

SA

VC-MTU

SDP
Path MTU

Ether Path
VC
Type Label Label

DA

Service MTU

SA

Ether
Type

payload

FCS

SDP Path MTU


Network Port MTU
4 1 11

Access
Interface
Port
MTU

* If the network interface is

dot1q encapsulated,
an extra 4 bytes is needed for
the q-tag.

All Rights Reserved Alcatel-Lucent 2011

The Physical MTU on an Ethernet access interface needs to be set to at least:




1514 with mode-access and encap-type null




1518 with mode-access and encap-type dot1q




1500 + 14 Ethernet Frame header

1500 + 14 Ethernet Frame header + 4 dot1q tag

1522 with mode-access and encap-type qinq




1500 + 14 Ethernet Frame header + 4 (first q-tag) + 4 (second q-tag)

All Rights Reserved 2011, Alcatel-Lucent


Section 4 Modue 1 Page 11

Maximum Transfer Unit (MTU) Example

SAP 1/1/1:100
Encap dot1q

Network
2/1/1

Network
3/1/1

Node A

SAP 4/1/1
Encap - Null

Node B

MTU Configuration Example Values


Node A
Access (SAP)
Port (slot/MDA/port) 1/1/1:100
Mode type
dot1q
MTU
1518

4 1 12

Network
2/1/1
network
1536

Node B
Network
3/1/1
network
1536

Access (SAP)
4/1/1
null
1514

All Rights Reserved Alcatel-Lucent 2011

MTU Configuration Example


In order for the maximum length service frame to successfully travel from a local ingress SAP to
a remote egress SAP the MTU values configured on the local ingress SAP, the SDP (MPLS), and the
egress SAP must be coordinated to accept the maximum frame size the service can forward.
For example, the targeted MTU values to configure for a distributed Epipe service (Node A and
Node B) are shown in the slide above.
Since Node A uses dot1q encapsulation, the SAP MTU must be set to 1518 to be able to accept a
1514 byte service frame. Each SDP MTU must be at least 1514 as well.
If Node As network port (2/1/1) is configured as an Ethernet port with an MPLS SDP running on
it, the MTU value of network ports 2/1/1 and 3/1/1 must each be at least 1536 bytes (1514 MTU
+ 8 bytes labels (2) + 14 Ethernet).
Finally, the MTU of Node Bs SAP (access port 4/1/1) must be set to at least 1514, as it uses null
encapsulation.
Note: Any additional labels would increase the MTU size further. For example if FRR bypass is
configured the MTU should size should be set to 1540.
All Rights Reserved 2011, Alcatel-Lucent
Section 4 Modue 1 Page 12

End of Module/Lesson
Services Overview

4 1 13

All Rights Reserved Alcatel-Lucent 2011

All Rights Reserved 2011, Alcatel-Lucent


Section 4 Modue 1 Page 13

4 1 14

All Rights Reserved Alcatel-Lucent 2011

All Rights Reserved 2011, Alcatel-Lucent


Section 4 Modue 1 Page 14

Do not delete this graphic elements in here:

42

Section 4
Services
Module 2
ePipe

All Rights Reserved Alcatel-Lucent 2011

All Rights Reserved 2011, Alcatel-Lucent


Section 5 Module 2 Page 1

Objectives
422

Services ePipe

 Upon successful completion of this module, the student will

understand:
Characteristics of an ePipe service
Steps in configuring an ePipe service
 ePipe service management tasks
 OAM tools SDP-Ping, SDP-MTU, VCCV Ping and Service Ping



All Rights Reserved Alcatel-Lucent 2011

All Rights Reserved 2011, Alcatel-Lucent


Section 5 Module 2 Page 2

VPWS (Virtual Pseudowire Service) - ePipe Service


423

Services ePipe

An VPWS service provides a point to


point connection between two nodes.
 Also referred to as a Virtual Leased Line

(VLL)
 From the customers perspective it
operates as a leased line between the
two locations.
 The Service provider can apply billing,
ingress/egress shaping and policing
 For ePipe, no MAC learning required

ePipe Service
PE C

PE A

IP / MPLS
Network

PE B

All Rights Reserved Alcatel-Lucent 2011

Characteristics


Point-to-point Ethernet service

Provides same functionality as a private line/leased line service

Transparent to higher layer traffic

Customer data is encapsulated and transported over across an IP/MPLS network

Does not perform any MAC learning

Troubleshooting aids such as Service Ping and VCCV Ping, aid in reducing the complexity of
setting up and maintaining the service

All Rights Reserved 2011, Alcatel-Lucent


Section 5 Module 2 Page 3

Creating an ePipe Service


424

Services ePipe

Customer
access
ports

PE-B

SDP

Customer
access
ports

SAP

Service-id

Service-id
SAP

SDP

PE-A
CORE

Service-id:

ePipe
Customer (subscriber) Association

Service Access Point

Select
Select
Select
Select
Select

Service Distribution Path

Binds a service to an SDP

node and port


Accounting Policy (optional)
Ingress/Egress QOS Policies (optional)
scheduler policy (optional)
Filter policies (optional)

All Rights Reserved Alcatel-Lucent 2011

Before any services are provisioned, the following tasks should be completed:


Build the IP (GRE) or IP/MPLS core network.

Configure routing protocols.

Configure MPLS LSPs (if MPLS is used).

Construct the core SDP service tunnel.

Create customer accounts

Create template QoS, scheduler, and accounting policies

Create SDPs

Service-specific Tasks Include:




Creating the service

Configure interfaces and SAPs; apply optional QoS, filter, accounting, and scheduler policies

Bind SDP to the service

All Rights Reserved 2011, Alcatel-Lucent


Section 5 Module 2 Page 4

SAPs and Spoke-SDPs


425

Services ePipe

 Flooded traffic received on SAPs and spoke SDPs:

Replicated on all other ports within the service (spoke-SDPs and SAPs)
 Not replicated on the port it was received on


SAP
ePipe 200

ePipe 200

SDP

SDP
SAP

 SAP Floods to everybody


 Spoke SDP Floods to everybody

All Rights Reserved Alcatel-Lucent 2011

Flooded traffic received on:


 SAP Flooded traffic received on a SAP is replicated to other SAPs, Spoke SDPs, and Mesh SDPs
 Spoke-SDP Flooded traffic received on a Spoke SDP is replicated to other SAPs, Spoke SDPs,

and Mesh SDPs

All Rights Reserved 2011, Alcatel-Lucent


Section 5 Module 2 Page 5

SAP Encapsulations for EPipe Services


426

Services ePipe

Port Type

Encapsulation

Ethernet

NULL

Ethernet

Dot1Q

Ethernet

QinQ

SONET / SDH

IPCP

SONET / SDH

BCP-Null

SONET / SDH TDM

BCP-Dot1Q

SONET / SDH TDM

ATM

SONET / SDH FR

FR

All Rights Reserved Alcatel-Lucent 2011

Null Supports a single service on the port. For example, a single customer edge device attached
to the port
Dot1q Supports multiple services on the port. For example, a customer edge device running
Virtual LANs
QinQ Supports tags within tags
IPCP Internet Protocol Control Protocol is typically used for interconnection using point-to-point
protocol (PPP)
Bridging Control Protocol (BCP-null) is typically used for bridging a single service between two
devices using PPP over SONET/SDH with an encap ID of 0
Bridging Control Protocol (BCP-dot1q) supports multiple services on the SONET/SDH port/channel

All Rights Reserved 2011, Alcatel-Lucent


Section 5 Module 2 Page 6

Epipe Configuration Workflow


427

Services ePipe

Customer
Info.

Configure
Configure aa
Customer
Customer

Bind

Create
Create Service
Service
(Epipe)
(Epipe)

Specify MTU
Specify
Encapsulation type

Configure
Configure
Access
Access Ports
Ports

Bind

Create
Create SAPS
SAPS

Specify transport
tunnels

Create
Create SDPs
SDPs

Bind

Bind
Bind to
to aa SDP
SDP
Virtual
Virtual Circuit
Circuit
(service
(service tunnel)
tunnel)

Bind the service


to the customer
at service
creation time

Assign
Encapsulation
value of the port

Assign VC Label

Manage
Manage Service
Service

Service Topology
View
Properties

All Rights Reserved Alcatel-Lucent 2011

The workflow illustrated above describes the steps for a network administrator or operator to configure a
Virtual Private LAN Service.


Customer - must be assigned to the service. Though the service can have only one Customer, that
customer may be assigned to more than one service.

Create Service - specify the service type (VLL) and add the appropriate service sites.

Create Service Access Points Configure the port Mode for Access, define the Encapsulation Type,
specify the Encapsulation ID (as required) and specify the service MTU size.

Create SDP Bindings Create the Spoke SDP or Mesh SDP Bindings by associating the service to service
tunnels. The VC Label may be assigned manually, by the network administrator or operator, or
automatically, by the 5620 SAM.

Manage Service through the Properties window and/ or by using the Service Topology View.

All Rights Reserved 2011, Alcatel-Lucent


Section 5 Module 2 Page 7

ePipe SAP & SDPs


428

Services ePipe

SAP
SDP Number

VC ID

SAP

SDP 7
SDP 3

All Rights Reserved Alcatel-Lucent 2011

All Rights Reserved 2011, Alcatel-Lucent


Section 5 Module 2 Page 8

SAP

SDP Diagnostics SDP-Ping


429

Services ePipe

 SDP-Ping

Tests for uni-directional or round trip connectivity


 Performs SDP MTU path tests
 Configurable parameters:


Message size (default is 40 bytes)


 Timeout (default is 5 seconds)
 Interval (default is 1 second)
 Number of messages to send (default is 1)
 Originating SDP ID
 Responding SDP ID (optional)
 Forwarding class and in/out-of-profile of the OAM message


All Rights Reserved Alcatel-Lucent 2011

SDP Ping performs in-band uni-directional or round-trip connectivity tests on SDPs. The SDP Ping
OAM packets follow the same path as traffic within the service. The SDP Ping response can be
received out-of-band in the control plane, or in-band using the data plane for a round-trip test.
A unidirectional SDP Ping tests:


Egress SDP ID encapsulation

Ability to reach the far-end IP address of the SDP ID within the SDP encapsulation

Path MTU to the far-end IP address over the SDP ID

Forwarding class mapping between the near-end SDP ID encapsulation and the far-end

tunnel termination

A round-trip SDP Ping specifies a local egress SDP ID and an expected remote SDP ID. SDP round trip
testing is an extension of SDP connectivity testing with the additional ability to test:


Remote SDP ID encapsulation

Potential service round trip time

Round trip path MTU

Round trip forwarding class mapping

All Rights Reserved 2011, Alcatel-Lucent


Section 5 Module 2 Page 9

SDP-Ping
4 2 10

Services ePipe

Unidirectional - Responding SDP


not provided

or
Bidirectional - Responding
SDP Provided

PE-A

DEMUX

DEMUX

SDP

CPU

CPU

SDP

Originating

Forwarding Class

PE-B

QOS Test

Profile

sdp-ping

Originating SDP

Responding SDP

Size

Size Increment

Step

Count

Timeout

Interval

MTU
discovery test

All Rights Reserved Alcatel-Lucent 2011

Originating SDP ID
The SDP-ID to be used by SDP-Ping. The far-end address of the specified SDP-ID is the expected
responder-id within each reply received. The specified SDP-ID defines the encapsulation of the SDP
tunnel encapsulation used to reach the far end, IP/GRE or MPLS.

Responding SDP ID
Optional parameter is used to specify the return SDP-ID to be used by the far-end for the message
reply for round trip SDP connectivity testing.

Forwarding Class Name


The forwarding class of the SDP encapsulation. The state can be specified as in or out-of-profile.

Timeout
The amount of time that the device will wait for a message reply after sending a message request.

Interval
Defines the minimum amount of time that must expire before the next message request is sent.

Size
OAM message size in octets.

Count
The number of messages to send. Each message request must either timeout or receive a reply
before the next message request is sent. The message interval value must be expired before the
next message request is sent.
Note: terminate an SDP-Ping test from the CLI use the Ctrl-C keyboard combination.

All Rights Reserved 2011, Alcatel-Lucent


Section 5 Module 2 Page 10

Service Ping (Svc-Ping)


4 2 11

Services ePipe

If not specified, GRE encapsulation packet


with OAM label used.

Uses the configured


remote SDP
encapsulation and label.

Uses the configured


outbound SDP encapsulation and
label.
local sdp
svc-ping

Target node

remote sdp

Service

Try to limit the number of concurrent service tests.


Different services could be using the same SDPs.
SDP-Ping may be more effective test.

No remote
SDP supplied

PE-A

SDP

VC Label B

SAP

Service-id

DEMUX

SVC

SVC
DEMUX

Customer
access
ports

Service-id
SAP

VC Label A

SDP

No local
SDP supplied

PE-B

Customer
access
ports

All Rights Reserved Alcatel-Lucent 2011

Parameters
Far-End IP Address
The far end IP address that the service ping packet will be sent to.

DNS-Name
The Domain Name Server (DNS) name of the far end device that the service ping packet will be sent
to.

Service-ID
The service ID of the service being tested.

Local-SDP
Specifies that the SVC-Ping request message should be sent using the same service tunnel
encapsulation labeling as service traffic; IP/GRE or MPLS. If the local-SDP parameter is not used,
the SVC-Ping message is sent using GRE encapsulation with an OAM label.

Remote-SDP
Specifies that the SVC-Ping reply message from the far-end should be sent using the same service
tunnel encapsulation labeling as service traffic. If the remote-SDP parameter is not used, the SVCPing reply message is sent using GRE encapsulation with an OAM label.

All Rights Reserved 2011, Alcatel-Lucent


Section 5 Module 2 Page 11

4 2 12

Services ePipe

End of Module
Services ePipe

All Rights Reserved Alcatel-Lucent 2011

All Rights Reserved 2011, Alcatel-Lucent


Section 5 Module 2 Page 12

Do not delete this graphic elements in here:

43

Section 4
Services

Module 3
Virtual Private LAN Service (VPLS)

All Rights Reserved Alcatel-Lucent 2011

All Rights Reserved 2011, Alcatel-Lucent


Section 4 Module 3 Page 1

Objectives
432

Services VPLS

 Upon successful completion of this module, the student will be able

to explain:







Characteristics and benefits of a VPLS service


7750 SR VPLS implementation
Operation of a VPLS service
Configuration of a VPLS service
VPLS service management tasks
OAM tools MAC ping, trace, populate, and purge

All Rights Reserved Alcatel-Lucent 2011

All Rights Reserved 2011, Alcatel-Lucent


Section 4 Module 3 Page 2

Populating a Forwarding Database (FDB)


433

Services VPLS

Host A sends a frame to Host C


The switch receives a frame on port 1/1/1

1.

Host As MAC address is learned from the frames Source Address field and is
associated with port 1/1/1

If the Destination Address is not already in the FDB, the switch floods the
frame out all ports except for the source port 1/1/1
3. Host C responds to Host A, and all other devices drop the flooded frame
2.

From Host Cs response frame, the switch associates Host Cs MAC address with
port 1/1/3
FDB Learning MAC Addresses
1/1/1

00-00-5e-00-01-8e

1/1/3

00-e0-b1-83-32-d8

Host C
Host A
DA

SA

payload

Host B
All Rights Reserved Alcatel-Lucent 2011

All Rights Reserved 2011, Alcatel-Lucent


Section 4 Module 3 Page 3

Forwarding Databases Using Tagging


434

Services VPLS

Virtual LANs (VLANs) are used to split a single switch into multiple
virtual switches, each with the ability to service the hosts associated
within that VLAN
 As an example Hosts A B C are part of VLAN 3, Host D is part of VLAN 6


1.

The switch receives a frame on port 1/1/1:3 (:3 signifies VLAN 3)




Host As MAC address is learned and is associated with in VLAN 3s FDB

If the Destination Address is not already in the FDB, the switch floods the
frame out all ports associated with VLAN 3
3. Host C responds to Host A, and all other devices drop the flooded frame
2.

From Host Cs response frame, the switch populates Host Cs MAC address in
VLAN 3s FDB

6
3

Host D

Host A
DA

SA

VLAN 3

Host C
payload

All Rights Reserved Alcatel-Lucent 2011

All Rights Reserved 2011, Alcatel-Lucent


Section 4 Module 3 Page 4

Host B

Ethertype
435

Services VPLS

 The Ethertype field describes the payload of the ethernet frame


Ethertype for some Protocol
common Protocols
0x0800

Internet Protocol, Version 4 (IPv4)

0x0806

Address Resolution Protocol (ARP)

0x8100

VLAN Tagging (Dot1Q)

0x9100

VLAN Tagging (QinQ)

0x86DD

IPv6

0x8847

MPLS unicast

0x88a8

Provider Bridging

 For example Etype 8447 identifies this packet as Unicast MPLS


0

DA

SA

0x8847

MPLS
Label

VC
Label

Payload FCS

Ethertype MPLS (8847)

1536

Etype

All Rights Reserved Alcatel-Lucent 2011

EtherType numbering generally starts from 0x0800. In the example used, Etype 8847 idicates a
unicast MPLS ethernet frame. As we have seen, an MPLS header includes a MPLS Label and
Virtual Circuit id. When the 7750 SR looks at the etype field and sees 8847, immediately the
following applies:
Service Payload / MTU: 1514 bytes
MPLS tag used as service label: 4 bytes
MPLS tag used for transport label: 4 bytes
DLC Header: 14 bytes
______________________________
1536 bytes

All Rights Reserved 2011, Alcatel-Lucent


Section 4 Module 3 Page 5

Ethertype - VLAN
436

Services VPLS

 Ethernet port encapsulation type can be configured as one of the

following:
Null Header (Raw Mode), all bits after the type field are treated as data
 Dot1q Header (Single tag header), adds an additional 4 byte TAG
 QinQ Header (Two tags header), adds two TAGs after Source Address field


Null No Tagging SAP 1/1/1

DA

SA

0x0800

Payload

FCS
1514

Dot1Q One Tag SAP 1/1/1:3

DA

SA

0x8100 Tag 3

Payload

FCS

1518

QinQ Stacked Tags - SAP 1/1/1:X.Y

DA

SA

0x9100 Tag X 0x8100 Tag Y

Payload

FCS
1522

All Rights Reserved Alcatel-Lucent 2011

The Physical MTU on an ethernet access interface needs to be set to at least:


 1514 with mode-access and encap-type null
 1500 + 14 DLC header
 1518 with mode-access and encap-type dot1q
 1500 + 14 DLC header + 4 dot1q tag
 1522 with Q-in-Q tagging
 1500 + 14 DLC header +4 dot1q tag +4 additional Q tag
SAP Ingress:
 Any frame that does not match a defined SAP within a service will be dropped
 Tags that are explicitly matched become stripped on ingress
 A wildcard can be used as a SAP defined tag (SAP:* or SAP:X.*), this has a 4-byte impact upon
the service MTU as the tag is retained rather that stripped
 There is no limit is put on the number of inner tags or the value of each tag provided the MTU
size has been adjusted to accomidate the extra tagging as these tags are considered part of the
payload
SAP Egress:
 SAP:X push dot1q-etype and tag X on egress frames
 SAP:X.Y push QinQ-etype and tag X / Dot1q-etype and tag Y on egress
 Default and wildcard SAPs do not regenerate tags on egress

All Rights Reserved 2011, Alcatel-Lucent


Section 4 Module 3 Page 6

Building a Local Virtual Private LAN Service (VPLS) Service


437

Services VPLS

Creating a Local VPLS Service, meaning a service that exists solely on


a single node:
Change the ports to port mode access

Ethernet mode access

Enable tagging on the ports

Ethernet encap-type dot1q

Create Service Access Points (SAPs) within the VPLS service using the
desired port/tag

VPLS 300




sap 1/1/1:3
sap 1/1/2:3
sap 1/1/3:3

1/1/4:6

VPLS 600


1/1/3:3

sap 1/1/4:6

1/1/1:3

1/1/2:3

Host A
DA

SA

0x8100

Host D
Host C

VLAN 3

payload

Host B
1518
All Rights Reserved Alcatel-Lucent 2011

All frames that ingress to a service are compared to the FDB to determine which SAP or SDP the
frame is to be forwarded out. If the egressing port is a SAP, the frame will be regenerated with
the appropriate tages (dot1Q and QinQ) based on the SAP definition. For example, a dot1q SAP
that is provisioned as 1/1/1:3 will have the dot1q tag 3 inserted into all frames that egress that
port based on the FDB.
When a wildcard is used, for example 1/1/1:* although the SAP is defined as dot1Q, no additional
tags are added on egress.

All Rights Reserved 2011, Alcatel-Lucent


Section 4 Module 3 Page 7

How is a VPLS provided over MPLS?


438

Services VPLS

 Bridging capable PE routers


 connected with a full mesh of MPLS LSP tunnels
 Per-Service VC labels
 negotiated using draft-Martini
PE B

 Unknown/broadcast
 traffic replicated in a service domain
 MAC learning
 over tunnel & access ports
 separate FIB per VPLS

PE A

PE C

LSP Full-Mesh
PE D

All Rights Reserved Alcatel-Lucent 2011

VPLS Service
For each VPN at each site, a Customer Edge (CE) device connects to the Provider Edge (PE) router
via a point-to-point access connection.
Ethernet serves as the framing technology between the CE device and the PE router in the
providers network. Frames can include IEEE 802.1Q Ethernet VLAN tags, which allow customers
to segment their networks and assign quality of service priorities to LAN traffic. VPLS also
supports QinQ encapsulation, where a second VLAN tag is added as a service delimiter. From
the customers perspective, the entire VPN looks like a single Ethernet LAN, with the PE acting as
a bridge that switches frames on the basis of their Layer-2 destination MAC addresses.
On the providers side, however, PEs are interconnected with Generic Routing Encapsulation
(GRE) and/or Multiprotocol Label Switching (MPLS) tunnels. If PEs are connected using GRE
tunnels traffic is encapsulated and routed through the core network using standard IP frame
formats and addressing. If PEs are connected using MPLS tunnels traffic is encapsulated in an
MPLS frame and transmitted using MPLS labels. MPLS routes can be signaled using RSVP-TE or LDP.

All Rights Reserved 2011, Alcatel-Lucent


Section 4 Module 3 Page 8

Packet Format
439

Services VPLS

DA

DA

SA

SA

0x0800

MPLS
Label

0x8847

VC
Label

DA

SA

0x0800

payload

payload

DA

SA

PE

PE
CPE

CPE

IP/MPLS
PE

PE

0x0800

payload

CPE

CPE

POP

POP

 The customer frame becomes the payload of the MPLS frame


All Rights Reserved Alcatel-Lucent 2011

The L1 encapsulation is the additional L1 information, most likely SONET or SDH, needed to
move data across a carriers infrastructure.
The transport label is the MPLS label that identifies the MPLS tunnel transporting the
encapsulated L2 frames or cells through the MPLS network.
The VC label is an MPLS label that identifies a particular service, that is being transported
through the MPLS tunnel.
The control word contains information about the connection. It may be optional or mandatory
depending on the network configuration.

All Rights Reserved 2011, Alcatel-Lucent


Section 4 Module 3 Page 9

Flooding Traffic within a VPLS


4 3 10

Services VPLS

SDP
VPLS 300

SDP
SDP

SAP

SDP

SAP
SAP Floods to everybody

VPLS 300

SDP
SDP

SAP
Spoke SDP Floods to everybody

SDP
VPLS 300

SDP
SDP

SAP
Mesh SDP Floods to SAPs and Spoke SDPs only
All Rights Reserved Alcatel-Lucent 2011

Flooded traffic received on:


 SAP Flooded traffic received on a SAP is replicated to other SAPs, Spoke SDPs, and Mesh SDPs
 Spoke-SDP Flooded traffic received on a Spoke SDP is replicated to other SAPs, Spoke SDPs,

and Mesh SDPs


 Mesh-SDP Flooded traffic received on a Mesh SDP is replicated to other SAPs, and Spoke SDPs

but is not transmitted on other Mesh SDPs


All frames that ingress to a service are compared to the FDB to determine which SAP or SDP the
frame is to be forwarded out. Flooding only occurs if there is no existing entery in the FDB.
Egress tags are generated based on the SAP definition of the egress port in the FDB.

All Rights Reserved 2011, Alcatel-Lucent


Section 4 Module 3 Page 10

VPLS - VC Label
4 3 11

Services VPLS

 VC-label Signaling between PEs per VPLS service instance

Each PE initiates a targeted LDP session to the far-end System IP address


 LDP protocol is used to communicate the VC label when sending packets for
each service
 The VC label must match between PE nodes


PE2

M-3

pe2-1

PE1

pe1-2

PE1->PE2: For Svc-id 101 UseVC-label pe2-1


PE1->PE3: For Svc-id 101 Use VC-label pe3-1

pe3-2

M-1

VPLS

pe2-3

pe3-1

PE2->PE1: For Svc-id 101 Use VC-label pe1-2


PE2->PE3: For Svc-id 101 Use VC-label pe3-2
PE3->PE1: For Svc-id 101 Use VC-label pe1-3

pe1-3

PE3

M-4

PE3->PE2: For Svc-id 101 Use VC-label pe2-3


All Rights Reserved Alcatel-Lucent 2011

Customer packets are transported either inside an IP packet (GRE) or inside an MPLS packet.
The packet carries an inner (VC) label that identifies the service the packet belongs to. This
label is sometimes referred to as the Martini label which is an MPLS label that identifies the
particular service that is being transported through the MPLS tunnel.
When a packet arrives at the destination, the outer IP address or MPLS label is stripped off. At
this point the inner label is examined to determine which service the packet belongs to.
After determining which service the packet belongs to, the customers Ethernet packet is
examined and its MAC address is looked up in a table on the PE to determine which SAP the
packet should go to.
VC labels can be assigned manually or automatically using targeted LDP (TLDP). The TLDP
protocol is used to dynamically negotiate VC labels between PEs. This method is not error prone
and scales much better then manually assigning labels.

All Rights Reserved 2011, Alcatel-Lucent


Section 4 Module 3 Page 11

VPLS Packet Walkthrough - VPLS Learning


4 3 12

Services VPLS

MAC 3
1/1/2
MAC
MAC3

Location
Remote

Mapping
Tunnel to PE2

Location

MAC
MAC3

Mapping
1/1/2

Local

PE 2
1/1/2

1/1/1
MAC 1
PE 1
MAC 2

PE 3

1/1/3

MAC
MAC3

MAC 4

Location
Remote

Mapping
Tunnel to PE2

 Send a packet from MAC 3 to MAC 1


 PE2 learns that MAC 3 is reached on Port 1/1/2
 PE2 floods to PE1 with VC-label pe2-1 and PE3 with VC-label pe2-3
 PE1 learns that MAC 3 is behind PE2
 PE3 learns that MAC 3 is behind PE2
 PE3 sends on Port 1/1/2
 PE1 sends on Port 1/1/1 & 1/1/3
All Rights Reserved Alcatel-Lucent 2011

PE routers learn the source MAC addresses of the traffic arriving on their access and network ports.
Each PE router maintains a Forwarding Information Base (FIB) for each VPLS service instance and learned
MAC addresses are populated in the FIB table of the service.
All traffic is switched based on MAC addresses and forwarded between all participating PE routers using the
LSP tunnels.
Unknown packets (i.e. destination MAC address has not been learned) are forwarded on all the LSPs to the
participating PE routers for that service until the target station responds and the MAC address is learned by
the PE routers associated with that service

All Rights Reserved 2011, Alcatel-Lucent


Section 4 Module 3 Page 12

VPLS Packet Forwarding


4 3 13

Services VPLS

MAC 3
1/1/2

MAC
MAC3

Location
Local

1/1/2

MAC1

Remote

Tunnel to PE1

Mapping

PE 2
1/1/2

1/1/1
MAC 1
PE 1
MAC 2

PE 3

MAC 4

1/1/3

MAC
MAC3

Location
Remote

Mapping
Tunnel to PE2

MAC1

Local

1/1/1

Reply with a packet from M1 to M3








PE1
PE1
PE1
PE2
PE2

learns M1 is on Port 1/1/1


knows that M3 is reachable via PE2
sends to PE2 using VC-label pe1-2
learns MAC 1 is reachable via PE1
knows that M3 is reachable on Port 1/1/2

All Rights Reserved Alcatel-Lucent 2011

All Rights Reserved 2011, Alcatel-Lucent


Section 4 Module 3 Page 13

4 3 14

Services VPLS

Switch to notes view!

Forwarding Information Base (FIB) Controls


Local and Remote Aging Timers
In a manner similar to a layer 2 switch, learned MAC addresses can be aged out if no packets are
sourced from the MAC address for a period of time (the aging time). Each VPLS instance has
independent aging timers for local (ingressed on a SAP) learned MAC and remote (ingress on a
SDP) learned MAC entries in the forwarding database. Usually the remote-age timer is set to a
longer interval to reduce the amount of flooding of destination-unknown MAC addresses through
the carrier domain.
The MAC aging timers can be disabled, preventing any MAC entries from being removed from the FIB
because of aging.

Disable MAC Learning


When disable-learning is enabled, new local or remote MAC addresses will not be entered into the
VPLS FIB.
This feature is best combined with the following feature, Discard Unknown MAC addresses,
otherwise your network runs the risk of being overwhelmed by excessive flooding of MAC
addresses.
All Rights Reserved Alcatel-Lucent 2011

Discard Unknown MAC Addresses


Unknown MAC discard is a feature which discards all packets ingressing a service where the
destination MAC address is not found in the FIB. Normally all such packet would be flooded to all
end points in the service.
Unknown MAC discard can be used with the Disable MAC Learning and Disable MAC Aging options to
create a fixed set of MAC addresses that are allowed to enter and pass through the service.

FIB Size Limit


The 7750 SR allows setting the maximum number of MAC entries allowed in the FIB per VPLS
instance. This prevents a VPLS instance from consuming a disproportionate amount of resources.
When the number of FIB entries allocated to the VPLS instance are exhausted, MAC learning is
disabled until space becomes available in the FIB.
The size of the VPLS FIB can be configured with a low watermark and a high watermark, expressed
as a percentage of the total FIB size limit. If the actual FIB size grows above the configured high
watermark percentage, an alarm is generated. If the FIB size falls below the configured low
watermark percentage, the alarm is cleared by the system.

All Rights Reserved 2011, Alcatel-Lucent


Section 4 Module 3 Page 14

Building a Distributed VPLS Service


4 3 15

Services VPLS

Creating a Distributed VPLS Service:


Add Service Access Points (SAPs) to the VPLS service on each node

VPLS 300


sap 1/1/1:3

Add Service Distribution Points (SDPs) to the VPLS service on each node

VPLS 300



mesh-sdp 12:300
mesh-sdp 13:300

1/1/1:3
VPLS 300
SDP 21

PE1

SDP 23

PE3

PE2
SDP 12

SDP 32

VPLS 300

VPLS 300
SDP 13

1/1/1:3

SDP 31

1/1/1:3
Host B

Host A
All Rights Reserved Alcatel-Lucent 2011

Core Network
Before a service is provisioned the following tasks should be completed:
 Build the IP or MPLS core network
 Configure routing protocols
 Configure MPLS LSPs (if MPLS used)
 Construct the core SDP service tunnel mesh for the services

Service Administration




Configure group and user access privileges


Build templates for QoS, filter and/or accounting policies needed to support core services
Configure customer accounts

SDP per VPLS Limit


The 7750 SR supports 100 SDPs per VPLS as of release 6.1 (50 SDPs per VPLS pre R6.1)
Service-id:

VPLS
Customer (subscriber) Association

Service Access Point

Select
Select
Select
Select
Select

Service Distribution Path

Binds a service to an SDP


Can be a Spoke or Mesh SDP

node and port


Accounting Policy (optional)
Ingress/Egress QOS Policies (optional)
scheduler policy (optional)
Filter policies (optional)

All Rights Reserved 2011, Alcatel-Lucent


Section 4 Module 3 Page 15

VPLS Configuration Workflow


4 3 16

Services VPLS

Customer
Info.

Configure
Configure aa
Customer
Customer

Bind

Create
Create Service
Service
(VPLS)
(VPLS)

Specify MTU
Specify
Encapsulation type

Configure
Configure
Access
Access Ports
Ports

Bind

Create
Create SAPS
SAPS

Specify transport
tunnels

Create
Create SDPs
SDPs

Bind

Bind
Bind to
to aa SDP
SDP
Virtual
Virtual Circuit
Circuit
(service
(service tunnel)
tunnel)

Bind the service to


the customer at
service creation
time

Assign
Encapsulation value
of the port

Assign VC Label
Specify Mesh-SDPs

Manage
Manage Service
Service

Service Topology
View
Properties

All Rights Reserved Alcatel-Lucent 2011

The workflow illustrated above describes the steps for a network administrator or operator to configure a
Virtual Private LAN Service.


Customer - must be assigned to the service. Though the service can have only one Customer, that
customer may be assigned to more than one service.

Create Service - specify the service type (VLL) and add the appropriate service sites.

Create Service Access Points Configure the port Mode for Access, define the Encapsulation Type,
specify the Encapsulation ID (as required) and specify the service MTU size.

Create SDP Bindings Create the Spoke SDP or Mesh SDP Bindings by associating the service to service
tunnels. The VC Label may be assigned manually, by the network administrator or operator, or
automatically, by the 5620 SAM.

Manage Service through the Properties window and/ or by using the Service Topology View.

All Rights Reserved 2011, Alcatel-Lucent


Section 4 Module 3 Page 16

VPLS SAP & SDPs


4 3 17

Services VPLS

SAP

SDP Number

VC ID

.
.
.

All Rights Reserved Alcatel-Lucent 2011

All Rights Reserved 2011, Alcatel-Lucent


Section 4 Module 3 Page 17

4 3 18

Services VPLS

Switch to notes view!

VPLS MAC Diagnostics


The VPLS MAC diagnostics provide the means to test the learning and forwarding functions on a perVPLS-service basis.
It is possible that although tunnels are operational and correctly bound to a service an incorrect
Forwarding Information Base (FIB) table for the service could prevent connectivity and not be
detected using the ping tools (SDP-Ping, LSP-Ping, and SVC-Ping).

MAC Ping
MAC Ping provides an end-to-end test to identify the customer-facing egress port where a customer
MAC address was learned. MAC Ping can also be used with a broadcast MAC address to identify all
egress points of a service for the specified broadcast MAC.

MAC Ping Characteristics




MAC ping packets can be sent through the control plane or the data plane

Packets sent along the data plane follow the same path as data traffic; when they reach
egress node they are not forwarded out a customer-facing port, they are passed to the
management plane for processing

All Rights Reserved Alcatel-Lucent 2011

Parameters
Service ID
Service ID of the service that you want to test.

Destination
Destination MAC address.

Size
MAC OAM request packet size in octets.

TTL
The Time To Live value in the OAM packet VC label.

Send Control
Including this parameter in the MAC ping command specifies that the control plane, rather than the
data plane is used the send the MAC OAM packet.

All Rights Reserved 2011, Alcatel-Lucent


Section 4 Module 3 Page 18

VPLS MAC Diagnostics MAC Ping


4 3 19

Services VPLS

ACTION

RESULT

Mac-Ping Service 1 to destination MAC address B.


PE-A will send a MAC-ping to PE-B (per the FIB).

PE-B has the MAC in its FIB, acknowledges the ping.

Mac-Ping Service 1 to destination D (unknown)


Sends the MAC-ping to all nodes (per the FIB)

No node responds.

Mac-ping service 1 destination FF:FF:FF:FF:FF:FF

All nodes in the service respond.

PE-A

MAC
Address

SDP

PE-B

SAP

Service 1

SERVICE
CORE

SDP
SDP

SDP

Service 1
SAP

Address
B

SDP

MAC
Address

MAC
SAP

SDP

Service 1

PE-C

Mac-traceroute lists the


intermediate nodes between
source and destination

All Rights Reserved Alcatel-Lucent 2011

Return Control
Including this parameter in the MAC ping command specifies that the control plane, rather than the
data plane is used to reply to the MAC ping message.

Source
The source MAC address from which the MAC OAM request originates. By default, the system MAC
address for the chassis is used.

Interval
This parameter defines the minimum amount of time that must expire before the next message
request is sent.

Count
The number of messages to send; each message request must either timeout or receive a reply
before the next message request is sent.
MAC Ping requests directed to the MAC broadcast address FF:FF:FF:FF:FF:FF and sent through the
data plane are flooded throughout the service flooding domain and will receive a response from all
operational SAPs. Note that SAPs that are operationally down do not reply. A MAC Ping sent to the
MAC broadcast through the control plane (with a sendcontrol option) will not receive a response.

All Rights Reserved 2011, Alcatel-Lucent


Section 4 Module 3 Page 19

4 3 20

Services VPLS

End of Module
Services VPLS

All Rights Reserved Alcatel-Lucent 2011

All Rights Reserved 2011, Alcatel-Lucent


Section 4 Module 3 Page 20

Do not delete this graphic elements in here:

44

Section 4
Services
Module 4
iPipe

All Rights Reserved Alcatel-Lucent 2011

All Rights Reserved 2011, Alcatel-Lucent


Section 4 Module 4 Page 1

What is IP Pseudowires (IPipe) ?


442

Services iPipe

 IPipe is a point-to-point (VPWS) service




Layer 3 IGP/EGP routing protocol that runs over IP can be run over the IPipe
(e.g. OSPF, RIP, BGP)


IS-IS uses Layer 2 for its routing messages and is therefore not supported within an
IPipe

IP connectivity between a CE attached to a point-to-point access circuit


(PPP/IPCP) with routed IPv4 encapsulation and a CE attached to an Ethernet
interface


Example: Interim step during ppp network to ethernet network migration

SDP
SAP

MPLS Network
IP Pseudo-Wires

SDP
SAP

PPP/ML-PPP

IP/Ethernet

All Rights Reserved Alcatel-Lucent 2011

VPWS - Virtual Private Wire Services


IPCP IP Control Protocol
An IPipe can provides IP connectivity between a host attached to a point-to-point access circuit (PPP) with
routed IPv4 encapsulation and a host attached to an Ethernet interface.
A typical use of this application is in a Layer 2 VPN when upgrading a hub site to Ethernet while keeping the
access side with their existing PPP encapsulation.
Supports:
 Ethernet SAP with Null or dot1p encapsulation
 PPP/ML-PPP SAP with IPCP encapsulation
 IP IWF PW: Interworking between IPCP & Ethernet
 Static configuration of CE IP addresses

All Rights Reserved 2011, Alcatel-Lucent


Section 4 Module 4 Page 2

Why iPipes?
Services iPipe

44

 Service Access via n*T1/E1 (e.g.

PPP and ML-PPP) is still very


common


Examples: CE branch equipment


(routers), CDMA base stations
ML-PPP

 Carriers want to modernize their

CDMA BTS

transport infrastructure to IP/MPLS


over Ethernet


Central devices e.g. HQ CE routers


and EV-DO RNCs for CDMA have
Ethernet and Gig E connectivity

Branch Office

IP/MPLS
on Metro Ethernet
Ethernet
& GE

IES/VPRN

RNC/BSC

3|

Regional/ HQ

All Rights Reserved Alcatel-Lucent 2011

IPipes support Ethernet, MLPPP, Frame Relay, ATM SAPs

All Rights Reserved 2011, Alcatel-Lucent


Section 4 Module 4 Page 3

Epipe vs. IPipe


444

Services iPipe

Provides

Epipe
ethernet VPWS

Provides

IPipe
IP interworking VPWS

Supports

bridged encapsulation

Supports

routed encapsulation

More network overhead because


ethernet header is transported

Less

Both hosts appear to be the same


ethernet LAN

Both

No

Mac

Mac learning

Easier

to configure

network overhead because


ethernet header is taken out
hosts appear to be on the
same IP subnet or network
learning

Local

& Remote CE IP address


configuration is required

All Rights Reserved Alcatel-Lucent 2011

It is worth mentioning that on 7750 SR, Ethernet VPWS Interworking can be used to provide connectivity
between Ethernet and ATM/FR sites where bridged encapsulation is being used over the ATM/FR links.
Bridged mode encapsulation enables network interworking at layer 2 by allowing the Ethernet frame to be
transported across the IP/MPLS intermediary network.
Routed mode encapsulation is used for service interworking between two layer 2 technologies.

All Rights Reserved 2011, Alcatel-Lucent


Section 4 Module 4 Page 4

Distributed IPipe
445

Services iPipe

Physical View

IP/MPLS

SR

Logical View

138.120.122.2/29

138.120.122.1/29

RNC

All Rights Reserved Alcatel-Lucent 2011

All Rights Reserved 2011, Alcatel-Lucent


Section 4 Module 4 Page 5

Distributed IPipe
446

Services iPipe

1. The SAR receives the PPP packet on the SAP


2. The SAR encapsulates the IP packet directly into a PW without a

control word
3. The SR receives MPLS packet and removes the PW encapsulation
4. The SR validates the MAC destination address of the received Ethernet
frame


It should match that of the Ethernet SAP

MPLS/PW
PPP/IPCP

IP

IP

Data
Ethernet

Data

IP

Data

IPipe
IP/MPLS

PPP/ML-PPP

SAR

SR

IP/Ethernet

All Rights Reserved Alcatel-Lucent 2011

To forward unicast frames destined to the RNC, the SR needs to know the RNC MAC address
When the IPipe SAP is first configured and administratively enabled, the SR sends an ARP request message
for the RNC MAC address over the Ethernet SAP
Until an ARP reply is received from the RNC, providing the NodeB's MAC address, unicast IP packets destined
for the RNC will be discarded at SR
The SR does not flush the ARP cache unless the SAP goes admin or operationally down
To refresh the ARP cache, the SR sends unsolicited ARP requests

All Rights Reserved 2011, Alcatel-Lucent


Section 4 Module 4 Page 6

Ipipe Configuration Workflow


447

Services iPipe

Configure
Configure aa
Customer
Customer

Bind

Configure
Configure Access
Access Ports
Ports Bind
(Ethernet,
(Ethernet, PPP
PPP // ML-PPP)
ML-PPP)



Create
Create SAPS
SAPS

Bind the service


to the customer
at service
creation time

Assign
Encapsulation
value of the port
Specify CE IP
Address

Specify MTU
Specify
Encapsulation type
Bind

Create
Create SDPs
SDPs


Create
Create Service
Service
(Ipipe)
(Ipipe)

Bind
Bind to
to aa SDP
SDP
Virtual
Virtual Circuit
Circuit
(service
(service tunnel)
tunnel)




Assign VC Label
Specify CE IP
Address

Specify transport
tunnels


Manage
Manage Service
Service

Service Topology
View
Properties

All Rights Reserved Alcatel-Lucent 2011

The workflow illustrated above describes the steps for a network administrator or operator to configure a
Virtual Private LAN Service.


Customer - must be assigned to the service. Though the service can have only one Customer, that
customer may be assigned to more than one service.

Create Service - specify the service type (VLL) and add the appropriate service sites.

Create Service Access Points Configure the port Mode for Access, define the Encapsulation Type,
specify the Encapsulation ID (as required) and specify the service MTU size. Specify the CE IP Address.

Create SDP Bindings Create the Spoke SDP or Mesh SDP Bindings by associating the service to service
tunnels. The VC Label may be assigned manually, by the network administrator or operator, or
automatically, by the 5620 SAM. Specify the CE IP Address.

Manage Service through the Properties window and/ or by using the Service Topology View.

All Rights Reserved 2011, Alcatel-Lucent


Section 4 Module 4 Page 7

IPipe Service : Configuration Overview


448

Services iPipe

 The following steps are required to configure a distributed IPipe

service:






Configure an IPipe Service with Customer ID


Configure a SAP and associate it with the IPipe service
Assign the local IP address to the SAP
Configure a spoke-SDP and associate it with IPipe service
Assign a remote IP address to the spoke-SDP

1.1.1.1

SDP
SAP

IPipe

SDP

SAP

1.1.1.1

1.1.1.2
1.1.1.2

All Rights Reserved Alcatel-Lucent 2011

In order to be able to forward IP packets end to end, the 750/705 is manually configured with
both the NodeB and RNC IP addresses. These are host addresses and are entered in /32 format.
7750/7705 maintains an ARP cache context for each IP interworking VLL.

All Rights Reserved 2011, Alcatel-Lucent


Section 4 Module 4 Page 8

IPipe Service : Configuration Overview


449

Services iPipe

SAP
SDP Number

VC ID

SAP

SDP 6
SDP 1

All Rights Reserved Alcatel-Lucent 2011

All Rights Reserved 2011, Alcatel-Lucent


Section 4 Module 4 Page 9

SAP

4 4 10

Services iPipe

End of Module
Services iPipe

All Rights Reserved Alcatel-Lucent 2011

All Rights Reserved 2011, Alcatel-Lucent


Section 4 Module 4 Page 10

Do not delete this graphic elements in here:

4.5

Section 4
Services

Module 5
Internet Enhanced Service (IES)

All Rights Reserved Alcatel-Lucent 2010

All Rights Reserved 2010, Alcatel-Lucent


Section 4 Module 5 Page 1

Module Objectives
Services IES

45

Upon successful completion of this module, the student will be


familiar with:
 Features of an Internet Enhanced Service
 Basic configuration an IES

All Rights Reserved Alcatel-Lucent 2010

All Rights Reserved 2010, Alcatel-Lucent


Section 4 Module 5 Page 2

Internet Enhanced Service (IES)


Services IES

Interface





SAP
IP Address

IES Interfaces can be included in the following routing protocol:

1.

Static, RIP, OSPF, ISIS, and BGP


3.

An IES is a routed, layer 3 connectivity service:

2.

45

VPLS can be bound to an IES


IES can terminate spoke-SDPs such as an EPipe, IPipe, or H-VPLS
service

IES 500
OSPF
OSPF
SAP
Interface: Port & IP Address
All Rights Reserved Alcatel-Lucent 2010

Internet Enhanced Service (IES) is a routed connectivity service where the subscriber
communicates with an IP router interface to send and receive Internet traffic.
An IES:
 Has one or more logical IP routing interfaces each with a SAP which acts as the access point to

the subscribers network


 Allows customer-facing IP interfaces to participate in the same routing instance used for service

network core routing connectivity


 Requires that the IP addressing scheme used by the subscriber be unique between other provider

addressing schemes and potentially the entire Internet.

All Rights Reserved 2010, Alcatel-Lucent


Section 4 Module 5 Page 3

IES Routed Connectivity Service Example


Services IES

45

Since the traffic in an IES service communicates using an IP interface


for the core routing instance, there is no need for the concept of
tunneling traffic to a remote router
 IES does not require the configuration of any SDPs

IES 500
OSPF
OSPF
SAP

All Rights Reserved Alcatel-Lucent 2010

While IES is part of the routing domain, a portion of the service provider IP address space can be reserved
for IES service provisioning. The reserved portion is user-configurable.
SAP Encapsulations Supported:


Ethernet: null, dot1q, and q-in-q

SONET/SDH: IPCP, BCP-null, and BCP-dot1q

IP Interface:


Most options found on core IP interfaces

VRRP for IES with more than one IP interface

Secondary IP addresses

ICMP options

Routing Protocols Supported:




RIP

OSPF

IS-IS

All Rights Reserved 2010, Alcatel-Lucent


Section 4 Module 5 Page 4

IES Configuration Workflow


Services IES

45

Customer
Info.

Configure
Configure aa
Customer
Customer

Bind

Create
Create Service
Service
(IES)
(IES)

Bind the service


to the customer
at service
creation time

Specify MTU
Specify
Encapsulation type

Configure
Configure
Access
Access Ports
Ports

Create
Create Layer
Layer 33
Access
Access Interface
Interface

Bind

Interface Name
Assign IP Address
Port / SAP

Add
Add to
to OSPF
OSPF

Manage
Manage Service
Service










Enable OSPF
Enable Passive
Mode

Service Topology
View
Properties

All Rights Reserved Alcatel-Lucent 2010

The workflow illustrated above describes the steps for a network administrator or operator to configure a
Internet Enhanced Service.


Customer - must be assigned to the service. Though the service can have only one Customer, that
customer may be assigned to more than one service.

Create Service - specify the service type (VLL) and add the appropriate service sites.

Create Service Access Points Configure the port Mode for Access, define the Encapsulation Type,
specify the Encapsulation ID (as required) and specify the service MTU size.

Create SDP Bindings Create the Spoke SDP or Mesh SDP Bindings by associating the service to service
tunnels. The VC Label may be assigned manually, by the network administrator or operator, or
automatically, by the 5620 SAM.

Manage Service through the Properties window and/ or by using the Service Topology View.

All Rights Reserved 2010, Alcatel-Lucent


Section 4 Module 5 Page 5

Services IES

45

End of Module
Services IES

All Rights Reserved Alcatel-Lucent 2010

All Rights Reserved 2010, Alcatel-Lucent


Section 4 Module 5 Page 6

Do not delete this graphic elements in here:

46

Section 4
Services

Module 6
Virtual Private Routed Networks (VPRN)

All Rights Reserved Alcatel-Lucent 2011

All Rights Reserved 2011, Alcatel-Lucent


Section 4 Module 6 Page 1

Objectives
462

Services VPRN

Upon successful completion of this module, you will be able to explain:




The need for L3 VPNs

L3 VPN : VPRN setup and configuration

Packet Walkthrough

All Rights Reserved Alcatel-Lucent 2011

All Rights Reserved 2011, Alcatel-Lucent


Section 4 Module 6 Page 2

Virtual Private Routed Networks (VPRN): Overview


463

Services VPRN

VRF for Customer 1 VPRN

VRF 1
192.168.1.0/24

Customer 1

192.168.1.0/24

VRF 2

Customer 1
VPN

192.168.2.0/24

Customer 1

Customer 2
VPN

Customer 2

192.168.2.0/24

Customer 2

VRF for Customer 2 VPRN

Challenge :
 Duplicate subnets are mixed together in a single PE Routing table
 Only the best route is selected in routing table
 Large amount of information may be exchanged when routing changes
Solution :
 Isolation of different VPN traffic
 Connectivity between customer sites
 Use of private address spaces in each site

All Rights Reserved Alcatel-Lucent 2011

Without the L3 VPN:




Each customer must use a separate IP address range

All customer routes are carried natively in the provider core

Large amount of information may be exchanged when routing changes

With VPRN:


Each PE router maintains a separate logical routing table for each VPRN

This table is referred to as a Virtual Routing and Forwarding Table (VRF)

Contains customer destination routes

May maintain multiple VRFs depending on the number of customers connected

local sites

remote sites

MP-BGP is used to carry the VPN routes

All Rights Reserved 2011, Alcatel-Lucent


Section 4 Module 6 Page 3

VPN-IPv4
464

Services VPRN

 Isolation of overlapping IP addressing schemes is achieved using VPN-

Internet Protocol version 4 (IPv4) address family


The BGP address family VPN-IPv4 is an extension to the BGP protocol
 In VPN-IPv4 addressing, a route distinguisher is prefixed to the private IPv4
address uniquely identifying the private IPv4 address, even if that address is
used in another customers network


IPv4

VPN-IPv4

IPv6

Mcast
IPv4

All Rights Reserved Alcatel-Lucent 2011

The capability of transporting VPN-IPv4 routes comes along with the support for Multiprotocol Extensions for
BGP-4.
By default, BGP-4 can handle only the native IPv4 routes. To enable the transport of different address
families such as VPN-IPv4, Multicast-IPv4 and IPv6, explicit configuration has to be made under the global
BGP context.
SAR>configure router bgp family ipv4 vpn-ipv4
Route Distinguisher (RD)
The Route Distinguisher is needed to make the VPN routes unique. This is necessary because all VPN routes
are carried in the same routing protocol (MP-BGP).
Different customers may use the same IP addresses within their respective networks. A method is needed to
ensure that the IP addresses remain unique when they are distributed across the service provider network.
This is achieved by pre-pending the 4-byte IPv4 address with an 8-byte Route Distinguisher to form a new
address called the VPN-IPv4 address.
All routes that are originating from a certain VRF on a particular PE have the same and only one RD value
associated with them.

All Rights Reserved 2011, Alcatel-Lucent


Section 4 Module 6 Page 4

IP-VPN: Route Distinguisher


465

Services VPRN

 An identifier called the Route Distinguisher (RD) is added to all IPv4

prefixes in order to be able to represent them as unique entities inside


the BGP RIB

Route Distinguisher

IPv4 Prefix

VPN-IPv4 Prefix

8 bytes

4 bytes

12 bytes

65530 : 10

192.168.1.0/24

65530:10:192.168.1.0/24

ASN

Integer

Type 0 RD Structure:
ASN: Autonomous System # of the VPRN
Integer: Administratively assigned value
All Rights Reserved Alcatel-Lucent 2011

Both Type 0 and Type 1 RD formats are supported on the 7x50. The common convention is Type 0, where the
first part of the RD (before the colon) is represented by the AS (Autonomous System) number of the VPRN
and the second part (after the colon) is an administratively defined and managed integer.
The RD value associated with the VRFs belonging to the same customer on different PEs may be chosen to
be the same or different depending on design requirements.
Both register and private AS numbers can be used, depending on the requirements at customer side.

All Rights Reserved 2011, Alcatel-Lucent


Section 4 Module 6 Page 5

IP-VPN: Route Target


466

Services VPRN

 Another identifier called the Route Target (RT) is used to distribute the






routes in between the VRFs dispersed over several PEs


While exporting a particular route from a VRF, one or more Export
Route Target(s) are associated with that route
A particular route originating from a VRF on a certain PE can have only
one Route Distinguisher value, but it can have multiple Route Target
values
Route Targets are part of the Extended Community Attributes inside
the BGP Updates and can be used in Route Policies
On the receiving PE, if the Import RT value matches the RT field of an
incoming BGP Update, then the associated prefix is populated
(imported) into the appropriate VRF
In a simplistic full-mesh VPRN topology, all the import and export Route
Targets associated with the VRFs belonging to the same customer on all
PEs are typically set to the same value

All Rights Reserved Alcatel-Lucent 2011

Route Targets follow the same notation with the RD, i.e.; using the type 0 format, the first part of the RD
(before the colon) is represented by the AS (Autonomous System) number of the VPRN and the second part
(after the colon) is an administratively defined and managed integer.
Sometimes (most likely on a full-mesh topology with no load balancing requirements) the RD and all RT
values are set to be equal to each other for the sake of simplicity. On the other hand, some more complex
VPRN topologies may require the use of multiple RT values to be associated with a single route. Some
example topologies of this sort are going to be discussed further in the section.

All Rights Reserved 2011, Alcatel-Lucent


Section 4 Module 6 Page 6

IP-VPN: RD vs. RT (Packet Capture)


467

Services VPRN

RT is a part of the extended community attributes

RD is part of the route attributes

All Rights Reserved Alcatel-Lucent 2011

Although sometimes having the same value, Route Distinguisher and Route Target are separate entities,
serving different purposes and located in different fields inside the BGP Update Message.
An example of such an update packet is shown in the figure. It is clearly seen that the RT is a part of the
extended community attributes and the RD now constitutes a portion of the NLRI (Network Layer
Reachability Information) field entries.
Also to note, the label stack values seen to the left of the RD values are the aforementioned Service
Labels also communicated by MP-BGP, to be further used in the data plane where actual customer traffic
is being sent over the IP/MPLS backbone.

All Rights Reserved 2011, Alcatel-Lucent


Section 4 Module 6 Page 7

L3 VPN: VPN Label


468

Services VPRN

For data traffic at an egress PE, which VRF must be used to resolve the
destination address?



Associate a label (the VPN label) with a VPN route at the ingress PE
Demux the traffic based on VPN label at egress PE

Distribute the VPN label with VPN Route information (MP-BGP)


MP-BGP Update
(Prefix =65530:20:192.168.1.0
RT = 65530:20
VPN Label = 131068)

Customer 1

192.168.1.0/24

Customer 1

VRF 1

VRF 1

VRF 2

VRF 2
Customer 2

Customer 2
Layer 2

MPLS
Label

VPN
Label
=
131068

IP Data

All Rights Reserved Alcatel-Lucent 2011

The purpose of the VPN label is to demultiplex VPN traffic arriving at the PE.
The distribution of the VPN label is done using BGP along with the VPN route information.
The distribution of the VPN tunnel information is automatic and does not require manual
intervention.
The forwarding at the egress PE is based on:


an MPLS lookup on the VPN label to determine the appropriate VRF

followed by an IP lookup in that VRF.

All Rights Reserved 2011, Alcatel-Lucent


Section 4 Module 6 Page 8

BGP: Different Routing Information Databases


469

Services VPRN

OSPF

RIP

Static

BGP
Import Policy

(Redistribution)
BGP
Export Policy

BGP

BGP

BGP

RIB-in

RIB

RIB-out

Incoming
BGP Update

Outgoing
BGP Update

Received
and processed
BGP routes
to be used in
routing decisions

Received
BGP Updates
from neighbours

BGP Updates
to be sent
to neighbours

All Rights Reserved Alcatel-Lucent 2011

Every routing protocol has its own separate RIB (Routing Information Base).
In the case of BGP, 3 databases exist:
1. RIB-IN
2. RIB
3. RIB-OUT

A BGP process receives BGP updates (from TCP-stack) and are collected in the RIB-IN.
Optionally, Import Route Policies can be applied to influence the way how incoming BGP updates are
accepted into the actual RIB.
NOTE: There are no default BGP import policies and hence by default: BGP RIB-IN = BGP RIB
On the sending side, the local routes that need to be advertised to other BGP neighbours are selected and
written into RIB-OUT with the use of a BGP export policy. In case of subsequent BGP connections,
received BGP routes are passed onto other BGP neighbours that require them without the need for an
explicit route policy.

All Rights Reserved 2011, Alcatel-Lucent


Section 4 Module 6 Page 9

IP-VPN: Routing Information Exchange (Walkthrough)


4 6 10

Services VPRN

PE-1 VRF:
Prefix
NH
Proto
----------------------------------

CE-1 Route Table:


Prefix
NH Proto
---------------------------1.1.10.0/24 IF_x

Local

10.1.1.0/30 IF_CE
Local
1.1.10.0/24 10.1.1.2 RIP

RD = 100:10
eRT = 100:10

VRF 10
MP-BGP Peering

IF_CE

IF_CE
VPRN
Import Policy

VPRN
Export Policy

Route Update

1.1.10.0/24

1.1.10.0/24 1.1.1.1 BGP VPN

iRT = 100:10

VRF 10

IF_x

PE-2 VRF:
Prefix
NH
Proto
----------------------------------

BGP
RIB-i

BGP
RIB

BGP
RIB-O

BGP Update

BGP
RIB-i

BGP
RIB

BGP
RIB-O

PE-2 (2.2.2.2/32)

PE-1 (1.1.1.1/32)

PE-1 BGP RIB-OUT:


Network
NH
VPN Label
--------------------------------------------100:10:1.1.10.0/24 1.1.1.1
(RT = 100:10)

Route Update

131069

PE-2 BGP RIB:


Network
NH
VPN Label
--------------------------------------------100:10:1.1.10.0/24 1.1.1.1
(RT = 100:10)

131069

All Rights Reserved Alcatel-Lucent 2011

1. CE-1 has a network 1.1.10.0/24 directly attached through the interface IF_x
2. CE-1 advertises this prefix to PE-1 via a route update. Available alternatives for CE-PE communication are
discussed in the next slide.
3. The route update is received on PE-1 at the VPRN access interface IF-CE and thus populated into VRF
10.
4. Through the use of a VPRN Export Policy, the entry in the local VRF is taken out to the BGP RIB-OUT on
PE-1 to be advertised to PE-2
While performing this operation, PE-1 includes the following information:
- An RD value of 100:10 is prepended onto the IPv4 prefix, making it a unique VPN-IPv4 entry inside the
BGP table. If another customer CE attached to PE-1 were to inject an entry with the same prefix value
(1.1.10.0/24), conflict would have been avoided by choosing another unique RD tag for that other
customer prefix.
- An export route target value of 100:10 is written into the Extended Community Attributes field. This is
going to be used at the end (PE-2) to decide which VRF is going receive that route update.
- Also the VPN Label associated with VRF 10 on PE-1 is communicated within the BGP Update message,
later to be used on the data plane.
5. The BGP Update message is received on PE-2 and immediately populated into BGP RIB-in.
6. An optional BGP import policy could be used at this point to control the way if and how certain routes
are accepted into the actual RIB. By default there is no BGP import policy and hence BGP RIB-IN = BGP RIB.
7. PE-2 checks the RT field of the incoming BGP update packet and see if there is a match with any of the
import RT values configured for the VRF(s). This is done via a VPRN Import Policy. As a result, VRF 10
receives the update in again pure IPv4 form.
8. PE-2 may send the update received inside VRF 10 to locally attached CE if there is any dynamic PE-CE
routing protocol configured.
All Rights Reserved 2011, Alcatel-Lucent
Section 4 Module 6 Page 10

Section 7 Module 4 Page 10

IP-VPN: VRF Import and Export Methods


4 6 11

Services VPRN

VRF Policies

vrf-target command

vrf-import & vrf-export


commands (policies)

Imports

and exports everything into


and out of a VRF

Provides

a more selective mechanism


in importing and exporting routes into
and out of a VRF
Policies are first created in the policy
configuration context and then applied
to the relevant VPRN service

All Rights Reserved Alcatel-Lucent 2011

SAR>config>service>vprn#
vrf-export

vrf-import

vrf-target

The vrf-target command facilitates a simplified method to configure the route target to be :
- Added to advertised routes (all non MP-BGP routes of the VRF are advertised) or
- Compared against received routes from other VRFs on the same or remote PE routers (via MP-BGP)
vrf-target target:65530:100: When written in this format, the same RT value (65530:100) is used for both
import and export routes (which is typically the case in a full-mesh VPRN topology). If required, different
RT values can be specified for import and export within this command as shown below:
SAR>config>service>vprn# vrf-target ?
- vrf-target {<ext-community>|{[export <ext-community>][import <ext-community>]}}
BGP-VPN routes imported with a vrf-target statement will use the BGP preference value of 170 when
imported from remote PE routers, or retain the protocol preference value of the exported route when
imported from other VRFs in the same router.
Specified vrf-import or vrf-export policies would override the vrf-target policy.

All Rights Reserved 2011, Alcatel-Lucent


Section 4 Module 6 Page 11

VPRN Configuration Workflow


4 6 12

Services VPRN

Enable
Enable BGP
BGP










Customer
Info.

Specify MTU
Specify
Encapsulation type

Configure
Configure aa
Customer
Customer

Bind

Configure
Configure
Access
Access Ports
Ports

Bind

Create
Create Service
Service
(VPRN)
(VPRN)

Create
Create Layer
Layer 33
Access
Interface
Access Interface

Auto-Bind
Auto-Bind to
to an
an
SDP
Virtual
Circuit
SDP Virtual Circuit

Manage
Manage Service
Service

Specify AS & Router


IP address
Create BGP Peers
Specify Route
Distinguisher & Route
Target
Specify SNMP
Community

Interface Name
Assign IP Address
Port / SAP

Auto-Bind SDPs

Service Topology
View
Properties




All Rights Reserved Alcatel-Lucent 2011

The workflow illustrated above describes the steps for a network administrator or operator to configure a
Virtual Private LAN Service.


Customer - must be assigned to the service. Though the service can have only one Customer, that
customer may be assigned to more than one service.

Create Service - specify the service type (VLL) and add the appropriate service sites.

Create Service Access Points Configure the port Mode for Access, define the Encapsulation Type,
specify the Encapsulation ID (as required) and specify the service MTU size.

Create SDP Bindings Create the Spoke SDP or Mesh SDP Bindings by associating the service to service
tunnels. The VC Label may be assigned manually, by the network administrator or operator, or
automatically, by the 5620 SAM.

Manage Service through the Properties window and/ or by using the Service Topology View.

All Rights Reserved 2011, Alcatel-Lucent


Section 4 Module 6 Page 12

4 6 13

Services VPRN

End of Module
Services VPRN

All Rights Reserved Alcatel-Lucent 2011

All Rights Reserved 2011, Alcatel-Lucent


Section 4 Module 6 Page 13

4 6 14

Services VPRN

All Rights Reserved Alcatel-Lucent 2011

All Rights Reserved 2011, Alcatel-Lucent


Section 4 Module 6 Page 14

Last But One Page


Switch to notes view!

1
@@PRODUCT
@@COURSENAME

All Rights Reserved Alcatel-Lucent 2010

This page is left blank intentionally

All Rights Reserved Alcatel-Lucent 2010


@@COURSENAME - Page 1

All rights reserved Alcatel-Lucent 2010


Passing on and copying of this document, use and communication of its
contents not permitted without written authorization from Alcatel-Lucent
All Rights Reserved Alcatel-Lucent 2010
@@COURSENAME - Page 2