SAM IP-MPLS Service Provisioning

SAM IP-MPLS Service Provisioning - Page 1
All Rights Reserved Alcatel-Lucent 2011

SAM IP-MPLS Service
Provisioning
STUDENT GUIDE
TOS36024 Issue 1
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
SAM IP-MPLS Service Provisioning
2
Empty page
Switch to notes view!
This page is left blank intentionally
3
Terms of Use and Legal Notices
1. Safety Warning
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 Alcatel-
Lucent. 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
written consent of Alcatel-Lucent.
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 Alcatel-
Lucent 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. Alcatel-
Lucent 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.
4
Blank Page
5
About this Student Guide
Conventions used in this guide
Where you can get further information
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
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.
6
About this Student Guide [cont.]
Section 1 Module 1 Page 1
All Rights Reserved 2011, Alcatel-Lucent
Do not delete this graphic elements in here:
11
Module 1
File System and CLI
Section 1
System Operation
1 1 2
5620 SAM IP/MPLS Service Provisioning
Objectives
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

1 1 3
Software
process
SNMP Agent
SNMP Agent
Software
process
SNMP Agent
SNMP Agent
SNMP Agent
SNMP Agent
Software
process
Responds to SNMP
manager requests
SNMP Components SNMP Agent
Sends Traps
(SNMP Managed Nodes)
(SNMP Managed Nodes)
SNMP Manager
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.
1 1 4
Introduction to the 5620 SAM Discovery Manager
Network Mgmt IP
Persistence on
SSH Preserve Key
Router ID
SNMP security
SNMP no shutdown
D
i
s
c
o
v
e
r
y

M
a
n
a
g
e
r
SAM DB
Reconciles router
elements into the
5620 SAM database
managed
network
S
N
M
P

r
e
s
p
o
n
s
e
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.
1 1 5
The Physical Access
OOB-CPM
Management
Ethernet
Port
In-band
Customer
Facing
Access Ports
&
Network Ports
CPM Console Port
SR-1

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.
1 1 6
The Help Command
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

Displays help on the global commands and lists all available global
commands.
Help Globals
Displays help on editing (editing keystrokes) and lists all available editing
key strokes.
Help Edit
Lists all the associated arguments for a keyword in a command. Command keyword ?
Displays a commands syntax and associated keywords. Command ?
Lists all the possible commands in the current context that start with
string.
string ?
This command displays all the possible commands in the current context. ?
Displays a brief description on the Help functionality. This command can be
used in any context.
Help
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:
1 1 7
The CLI command prompt
Example: Configuring SNMP
Node>config>system>snmp#
Example: Configure system interface
Node>config# router interface system
Node>config>router>if$ address 172.0.0.4/32
Host name Node Context separator

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
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#
1 1 8
The Auto-completion Commands
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

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).
1 1 9
File System Structure

Root
bof.cfg boot.ldr config.cfg TiMOS-m.n.Yz
cpm.tim
(SR-7/-12)
iom.tim
(SR-7/-12)
Boot
Option
File
Bootstrap
Image
Default
Configuration
File
CPM
Image
File
IOM
Image
File
m Major release number
n Minor release number
Y A Alpha Release
K Beta Release
M Maintenance Release
R Released Software
J Internal Engineering and Test Release
z Version number
both.tim
(SR-1)
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).
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:
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.
Node>file cf3:\ # copy
Node# file copy
cf3:\config.cfg
ftp://10.1.1.1/config.cfg
Remove (delete) a directory in the local
file system.
Node>file cf3:\ # rd
Create a new directory in the local file
system.
Node>file cf3:\ # md
Display a list of files and subdirectories
in a directory.
Node>file cf3:\ # dir
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:\ # attrib
Enter the CLI File context. Node# file
1 1 11
File System CLI Context
Root
File
Attrib
Cd
Copy
Delete
Dir
Md
Move
Rd
Scp
Type
Version

Display the version of an OS cpm.tim
or iom.tim file.
Node>file cf3:\ # version
Display the content of a text file. Node>file cf3:\ # type
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:\ # scp
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:\ # move
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:\ # delete
Some commands:
1 1 12
Managing The BOF
Boot
Option
File
The system uses the BOF file to perform the following tasks:
1) Configure Primary, Secondary, Tertiary image source
2) Configure Primary, Secondary, Tertiary configuration source
3) Create an IP address for the CPM Ethernet port
4) Create a Static route for the CPM Ethernet port
5) Configure the DNS Domain name
6) Set up the CPM Ethernet port (speed, duplex, auto)
7) Configure persistence requirements
8) Enable/disable Lawful Intercept configuration to be saved locally
9) Enable/disable separate access to Lawful Intercept (LI) information
10) Set the console port speed
Always be sure to save the BOF!

Display the in-memory bof file (last
used).
Node# show bof
Save the bof. Node>bof# save
Set the primary configuration file (eg.
test.cfg).
Node>bof# primary-config cf3:/test.cfg
Set the primary image directory.
Node>bof# primary-image
cf3:/TIMOS.5.0.R0
Set the CPM Ethernet Port speed to 100
Mbps.
Node>bof# speed 100
Change or create the CPM Ethernet Port
IP address.
Node>bof# address 10.10.10.2/24
primary
Enter the CLI BOF context to change or
create a bof file.
Node# bof
Parameters that are configured in the BOF are shown in the chart above.
Some commands:
1 1 13
System Initialization
START
Load & Execute
boot strap loader
(cf3:\boot.ldr)
Process
boot option file
(cf3:\bof.cfg)
Initialize
Hardware
Wait
required
Get runtime image
(3 possible locations)
Y
N
Get config
(3 possible locations)
Image OK ?
Startup
Failed
N
Y
Config found ?
Boot with Defaults
SNMP shutdown
Issue Trap
Issue Log entry
Issue Console msg
N
Need
Persistence
?
Y
Config File
Processed OK
Log In
Prompt
N
Y
Y
N Persistence
File Processed
OK
Y
N
User intervention point:
1
User activity detected
SNMP shutdown
Issue Trap (if possible)
Issue Log entry
Issue Console msg
Process
persistence
and
Configuration
files
1
Process
Config File
Persistence
Needed for proper SAM
Operation: see
optional topic

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.
1 1 14
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.
Runtime Image
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.
1 1 15
Tip
If address is not defined, type the following:
a. bof# address <IP address/ subnet mask> <Enter>
Basic Router Configuration
1. Launch a CLI or SSH session to the router
2. Configure Network Management IP
a. # bof <Enter>
b. # show bof
3. Set persistence on
a. bof# persist on <Enter>
5. Save the bof
a. bof# save
4. Define a location to save the configuration file
a. bof# primary-config <file location:/file path/filename.cfg>
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.
1 1 16
Basic Router Configuration [Cont.]
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 SNMP
a. # configure system snmp <Enter>
b. # packet-size 9216 <Enter>
c. # 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 the router configuration
9. Enable SSH Preserve Key
a. # configure system security ssh preserve-key <Enter>
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>
1 1 17
End of Module
Operating System, File System and CLI
1 1 18
21
Section 2
IP Routing
All Rights Reserved Alcatel-Lucent 2011 2 1 2
Objectives
Interface Configuration
Routing Protocol
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)
System Interface
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
Network Interfaces
Static Routing
192.168.11.1 192.168.22.1
10.12.1.1 10.12.1.2
192.168.22.0/30 192.168.11.0/30
10.12.1.0/29
A
A
B B
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
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
Node1
Node2
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
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
Route
Table
Dijkstras
Algorithm
Link State
Database
LSAs are flooded to other interfaces
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.
Open Shortest Path First (OSPF) is one of the most popular link-state
interior gateway protocols used in large enterprise networks.
Features:
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
OSPF Overview
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.
OSPF Configuration
Enable OSPF
Create Area Add Interfaces
Intermediate System-to-Intermediate System (IS-IS)
Both ISIS and OSPF are link state protocols
Features:
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
ISIS Overview
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.
ISIS Configuration
Enable ISIS
Create Area Add Interfaces
End of Module/Lesson
IP Routing
30
Section 3
Multi Protocol Label Switching (MPLS)
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
MPLS Overview
7705 SAR Label Signaling and Distribution Summary
Label Signaling &
Distribution
Dynamic Manual
Dynamic
MPLS Service Signaling
Static LDP RSVP T-LDP MP-BGP
IGP
Best Effort
Hop by Hop
IGP / CSPF
Explicit Path
Loose / Strict Paths
IGP
Targeted Session

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
MPLS: Basic operation
LABEL SWITCHING
data
LER LER LSR LSR
IP Forwarding
IP Forwarding
data data label data label data label
Pop
Push
Swap Swap
Label Switched Path

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.
MPLS Label
Label Exp. S
TTL
Label: Label Value, 20 bits
Exp.: Experimental, 3 bits (Class of Service)
S: Bottom of Stack, 1 bit (1 = last entry in label stack)
TTL: Time to Live, 8 bits
4 Octets
Label Stack
Entry Format
MPLS
Header
IP Packet Type =
88 47
SA IP Header FCS DA
Frame header
MPLS
Header 2
MPLS Header
1
Data Link
Header
IP Data FCS IP Header
Single Label
Label Stack

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.
LIB and LFIB
LFIB
LIB
FIB
RIB
Table
Name
Routing Protocol Exchange - Each routing
protocol has a separate RIB
Routing updates received Routing Information Base
RTM selects the active routes from all
protocol "Best" routes
Active routes Forwarding Information
Base
MPLS Label Exchange Locally generated and
received MPLS labels
Label Information Base
Labels used by the LSR
Contents
The labels assigned to the active routes (for
each next-hop)
Label Forwarding
Information Base
Populated By Meaning

RIB OSPF
RIB IS-IS
LIB LDP
FIB
LFIB
O
S
P
F
u
p
d
a
t
e
IS
-
IS
u
p
d
a
t
e
L
D
P
u
p
d
a
t
e
L
D
P
u
p
d
a
t
e
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.
LDP Label Distribution Protocol
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
10.2.1.0/24
LSR 4 LSR 3 LSR 2
LSR 1
10.1.1.0/24
Control Plane
1/1/3
1/1/1 1/1/2
1/1/1
1/1/2
1/1/1
1/1/2
1/1/3
LSR2 1/1/2 131071 - 4.4.4.4/32
LSR2 1/1/2 131068 - 10.2.1.0/24
LSR 1
LFIB
Egr.
Label
Ing.
Label
Egr.
Intf
Prefix Next-hop
LSR3 1/1/3 131070 - 1.1.1.1/32
LSR3 1/1/3 131065 - 10.1.1.0/24
LSR 4
LFIB
Egr.
Label
Ing.
Label
Egr.
Intf
Prefix Next-hop
1.1.1.1/32 2.2.2.2/32
3.3.3.3/32
4.4.4.4/32
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.
LDP: Downstream Unsolicited Distribution Mode
Downstream:
Advertising labels from downstream to the
upstream direction.
Unsolicited:
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.
131065 LSR 2 10.2.1.0/24
LSR 3
Next-hop
131066
Label
iLER
LIB
10.2.1.0/24
Prefix
iLER
eLER
LSR3
LSR2
1.1.1.1/32
2.2.2.2/32
3.3.3.3/32
4.4.4.4/32
10.2.1.0/24

FEC: 10.2.1.0/24
Label: 131066
FEC: 10.2.1.0/24
Label: 131067
FEC: 10.2.1.0/24
Label: 131065
FEC: 10.2.1.0/24
Label: 131067
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.
LDP: Liberal Retention & Ordered Control Mode
131065 LSR 2 10.2.1.0/24
LSR 3
Next-hop
131066
Label
iLER
LIB
10.2.1.0/24
Prefix
Ordered Control:
The LSP will not pass data until the
setup messages have propagated from
end to end
Liberal Retention:
The label received from the router
providing the active IGP route for
the FEC is used and the other labels
are kept
iLER
FIB
LSR 3
Next-hop
10.2.1.0/24
Prefix
LSR 3
Next-hop
131066
Label
iLER
LFIB
10.2.1.0/24
Prefix
iLER
eLER
LSR3
LSR2
1.1.1.1/32
2.2.2.2/32
3.3.3.3/32
4.4.4.4/32
10.2.1.0/24

S
t
e
p

1
Label
131067
Step 1
Label
131067
S
t
e
p

2
Label
131066
Step 2
Label
131065
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.
LER1
LER2
10.10.10.1/32
LSR2
LSR1
LSR4
1000
LDP: Convergence
LSP after the failure
LSP before the failure
MPLS Convergence =
Failure Detection Time +
IGP Convergence +
LDP Convergence
LER 1
LFIB
131068
Egress
Label
-
Ingress
Label
1/1/2
Egress
Interface
10.10.10.1/32
Prefix
LSR 2
next-
hop
1/1/2
LER 1
LFIB
131065
Egress
Label
-
Ingress
Label
1/1/3
Egress
Interface
10.10.10.1/32
Prefix
LSR 1
next-
hop

1/1/3
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.
LDP: Minimum Configuration
Provider
Network
PE1
PE2
P 3
P 2 P 1
PE-3

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.
RSVP-TE Resource Reservation Protocol Traffic Engineering
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
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.
RSVP-TE: Message Types
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
LSR2
iLER
1.1.1.1/32
LSR1
2.2.2.2/32
eLER
3.3.3.3/32 4.4.4.4/32
Path: 3.3.3.3
P
a
t
h
:

3
.
3
.
3
.
3
R
e
s
v
:

l
a
b
e
l

1
3
1
0
7
1
Resv: label 131068

Downstream on Demand (DoD)
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.
RSVP-TE: Label allocation
iLER
LSR2
1.1.1.1/32
LSR1
2.2.2.2/32
eLER
3.3.3.3/32
4.4.4.4/32
iLabel eLabel Action
--- 131068 Push
131068 131071 Swap
131071 --- Pop
Label Switched Path
After the Resv
message is
propagated
upstream to the
sender node, a
label-switched path
is effectively
established

L
a
b
e
l

S
w
i
t
c
h
e
d

P
a
t
h
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.
RSVP-TE: Optional object Explicit Route Object: ERO
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
10.14.1.29/29
PE1
PE3 PE4
PE2
1/1/2
1.1.1.1/32 2.2.2.2/32
3.3.3.3/32
4.4.4.4/32
10.12.1.0/29
10.23.1.0/29
10.34.1.0/29
.1 .2
.3 .4
1
0
.
2
4
.
1
.
0
/
2
9
1
0
.
1
3
.
1
.
0
/
2
9
.2 .1
.3
.4
RSVP Path
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.12.1.1
RSVP Path
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
RSVP Path
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

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
RSVP-TE: Optional object Record Route Object: RRO
Record Route
Object (RRO) of
RSVP-TE is used for
route recording
purpose
RRO records the
actual route a
packet traversed
Recording the path
allows the iLER to
know, on a hop-by-
hop basis, which
LSRs the path
traverses
4.4.4.4/32
PE1
PE3 PE4
PE2
1.1.1.1/32 2.2.2.2/32
3.3.3.3/32
10.12.1.0/29
10.14.1.29/29
10.23.1.0/29
10.34.1.0/29
.1 .2
.3 .4
1
0
.
2
4
.
1
.
0
/
2
9
1
0
.
1
3
.
1
.
0
/
2
9
.2 .1
.3
.4
RSVP Resv
LSP Tunnel (IPv4)
Label: 65
Session_Attributes
RRO: 10.12.1.2
10.23.1.3
10.34.1.4
RSVP Resv
LSP Tunnel (IPv4)
Label: 100
Session_Attributes
RRO: 10.34.1.4
RSVP Resv
LSP Tunnel (IPv4)
Label: 13
Session_Attributes
RRO: 10.23.1.3
10.34.1.4

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
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
RSVP-TE: Signaled LSPs with CSPF
Routing Table
Traffic
Engineering
Database (TED)
Signaling
TE Capable IGP
OSPF-TE
IS-IS-TE
Constrained
Shortest Path First
(CSPF)
User
Requirements
Explicit Route
Object
(ERO)

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.
RSVP-TE: LSP Configuration
10.10.10.103
10.10.10.102
10.10.10.101
10.10.10.100
10.10.10.99
10.10.43.3
10.10.44.3
RSVP PATH
Primary_Path
10.10.42.3

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
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
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
PE1
PE3 PE4
PE2
1.1.1.1/32 2.2.2.2/32
3.3.3.3/32 4.4.4.4/32
Blue Path
Red Path
10.12.1.2
10.23.1.3
10.34.1.4

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

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.
LSP with 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
LSP 1 Primary
Path
LSP 1 Secondary
Path
X

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
Fast Re-Route (FRR)
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
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
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

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.
RSVP-TE: Backup LSP LSPs with Secondary Path
Primary LSP: One primary path
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.
R1
R2
R3
R4
R6
R7
R8
R9
Primary LSP:
R1->R2->R3->R4
Secondary LSP:
R1->R6->R7->R8->R9->R4
Failure in primary path triggers secondary LSP
Secondary Path: Non-standby or Hot-standby

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

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.
FRR: One-to-one Backup Method Multiple LSPs
R1
R2
R3
R4
R6
R7 R8
R9
Protected LSP 1:
R1->R2->R3->R4
R2s backup for Protected LSP 1
R2->R7->R8->R9->R4
PLR
(1)
(1)
R10
R2s backup for Protected LSP 2
R2->R7->R8->R9->R4
(2)
(2)
PLR
Protected LSP 2:
R10->R2->R3->R4
MP
R5

MP
PLR
MP
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.
FRR: One-to-one Backup Method Path Setup
R1
R2
R3
R4
R6
R7 R8
R9
Protected LSP:
R1->R2->R3->R4
R1s backup:
R1->R6->R7->R8->R9->R4
R2s backup:
R2->R7->R8->R9->R4
R3s backup:
R3->R9->R4
PLR
PLR
(1)
(2)
(3)
(1)
(2)
(3)
Detour Tunnel
Merge Point
(MP)
R5

PLR
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.
FRR: One-to-One Backup Method Label Exchange
R1
R2
R3
R4
R7
R8
54
32
21
172
187
198
Control Plane
(label propagation)
R2s backup:
R2->R7->R8->R9->R4
Protected LSP:
R1->R2->R3->R4
R9
159

PLR
MP
21
Inner
label
32
Inner
label
54
Inner
label
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.
FRR: One-to-One Backup Method Link/Node Failure
Control Plane
(label propagation)
R2s backup:
R2->R7->R8->R9->R4
Protected LSP:
R1->R2->R3->R4
172
Inner
label
187
Inner
label
198
Inner
label
R1
R2
R3
R4
R8
21
172
187
198
R9
159
159
Inner
label
R7

PLR
MP
X
21
Inner
label
32
Inner
label
54
Inner
label
21
Inner
label
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.
FRR: Facility Backup Method Link Protection
R1
R2
R3
R4
R6
R7 R8
R9
Protected LSP 1:
R1->R2->R3->R4
R10
Bypass tunnel
R2->R7->R8->R3
PLR
Protected LSP 2:
R10->R2->R3->R4
MP

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 R2-
R3. 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.
FRR: Facility Backup Link Protection Label Exchange
R1
R2
R3
R4
R7
R8
54
32
21
172
187
138
Control Plane
(label propagation)
R2s backup:
R2->R7->R8->R3
Protected LSP:
R1->R2->R3->R4
21 32 54
Inner
label
Inner
label
Inner
label
Works the same as One-to-One Backup under normal operating conditions
Works the same as One-to-One Backup under normal operating conditions

PLR
MP
The data plane functions the same way in the stable LSP scenario as it did during the One-to-
One 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.
FRR: Facility Backup Link Failure
R1
R2
R3
R4
R7
R8
54
21
172
187
138
Control Plane
(label propagation)
R2s backup:
R2->R7->R8->R3
Protected LSP:
R1->R2->R3->R4
21
Inner
label
54
Inner
label
172
Inner
label
32
187
Inner
label
32
MP receives same label from backup link as it would from Primary LSP
MP receives same label from backup link as it would from Primary LSP
138
Inner
label
32
32
Inner
label
32

PLR
MP
X
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.
MPLS
Section 4 Modue 1 Page 1
41
Section 4.1
Services Overview
Objectives
Upon successful completion of this module, you will be able to
describe:
Service components
Service Access Points (SAP)
Service Distribution Paths (SDP)
Service tunnels and labels
MTU considerations
Services Service Configuration Model
Label Switched Path
Label Switched Path
Service Configuration Model
To provision a service, the following must be defined:
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
Service 50
Customer
100
SDP 3
Demux
SAP
Service 50
Customer
100
SDP 3
Demux
Tunnels are unidirectional
and are paired to provide a
bi-directional service
SDP binds multiple
services to a tunnel
SAP is the
customer point of access
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.
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
For example Etype 8447 identifies this packet as Unicast MPLS
IPv6 0x86DD
MPLS unicast 0x8847
Provider Bridging 0x88a8
VLAN Tagging (QinQ) 0x9100
VLAN Tagging (Dot1Q) 0x8100
Address Resolution Protocol (ARP) 0x0806
Internet Protocol, Version 4 (IPv4) 0x0800
Protocol Ethertype for some
common Protocols
DA SA
VC
Label
Payload FCS
MPLS
Label
0x8847 Ethertype MPLS (8847)
0
1536
Etype
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
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
SAP
Service 50
SDP 3
Demux
SAP
Service 50
SDP 3
Demux Label Switched Path
payload DA SA 0x0800
payload DA SA
MPLS
Label
0x8847
VC
Label
DA SA 0x0800
payload DA SA 0x0800
Egress and ingress VC labels
uniquely identifies the service
Label Switched Path
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.
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
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
Configuring SDPs
config>service>sdp sdp-id [gre
| mpls]
description description-
string
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
Creating 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# ldp
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
Creating an SDP for GRE
config>service# sdp 2 gre create
config>service>sdp# description to-GRE-10.10.10.104
Creating an SDP for MPLS (RSVP-TE)
config>service>sdp# description "MPLS-10.10.10.104"
Creating an SDP for MPLS (LDP)
config>service>sdp# description "MPLS-10.10.10.94"
config>service>sdp# ldp
Creating an SDP with MPLS Static LSP
config>service>sdp# exit
Create
an SDP
Services Summary: SAP to SDP
Apipe
IMA
MPLS GRE
Customer
Create a
Pseudowire
Service
Assign a
Spoke-SDP
Assign a
SAP
Cpipe Epipe Ipipe
ATM TDM Ethernet IP
VCC VPC E1 DS1 Null dot1q Ethernet PPP/MLPPP
CAS Channelized Unchannelized Null dot1q IPCP
CESoPSN SAToP E1 CAS VCC VPC
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

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.
L2 Service MTUs (Ethernet)
Network
Interface
-
Port
MTU
SDP
Path MTU
Service MTU
Access
Interface
-
Port
MTU
VC-MTU
Service MTU
payload DA SA FCS
Ether
Type
payload FCS 802.1q
Optional (Null/dot1Q/QinQ)
(will be stripped)
DA SA
Ether
Type
Access Port MTU
SDP Path MTU
Network Port MTU
No fragmentation possible
(*) payload DA SA FCS
Ether
Type
SA
Ether
Type
Path
Label
VC
Label
DA
*
If the network interface is
dot1q encapsulated,
an extra 4 bytes is needed for
the q-tag.

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 Ethernet Frame header
1518 with mode-access and encap-type dot1q
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)
Maximum Transfer Unit (MTU) Example
SAP 1/1/1:100
Encap dot1q
SAP 4/1/1
Encap - Null
Network
2/1/1
Network
3/1/1
MTU Configuration Example Values
Node A Node B
Access (SAP) Network Network Access (SAP)
Port (slot/MDA/port) 1/1/1:100 2/1/1 3/1/1 4/1/1
Mode type dot1q network network null
MTU 1518 1536 1536 1514
Node A Node B

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.
Services Overview
42
Module 2
ePipe
Section 4
Services
Services ePipe 4 2 2
Objectives
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

VPWS (Virtual Pseudowire Service) - ePipe Service
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
PE A PE C
PE B
IP / MPLS
Network
ePipe Service

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
Creating an ePipe Service
Service-id: ePipe
Customer (subscriber) Association
Service Access Point Select node and port
Select Accounting Policy (optional)
Select Ingress/Egress QOS Policies (optional)
Select scheduler policy (optional)
Select Filter policies (optional)
Service Distribution Path Binds a service to an SDP
CORE
Service-id
SAP
SAP
PE-A
PE-B
Customer
access
ports
Customer
access
ports SDP
SDP
Service-id
D
D

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
SAPs and Spoke-SDPs
SAP
SDP
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
SDP
ePipe 200
SAP Floods to everybody
Spoke SDP Floods to everybody
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
SAP Encapsulations for EPipe Services
FR SONET / SDH FR
ATM SONET / SDH TDM
BCP-Dot1Q SONET / SDH TDM
BCP-Null SONET / SDH
IPCP SONET / SDH
QinQ Ethernet
Dot1Q Ethernet
NULL Ethernet
Encapsulation Port Type
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
Epipe Configuration Workflow
Create Service
(Epipe)
Create Service
(Epipe)
Bind the service
to the customer
at service
creation time
Manage Service
Manage Service
Service Topology
View
Properties
Configure a
Customer
Configure a
Customer
Configure
Access Ports
Configure
Access Ports
Specify MTU
Specify
Encapsulation type
Bind to a SDP
Virtual Circuit
(service tunnel)
Bind to a SDP
Virtual Circuit
(service tunnel)
Assign VC Label
Create SAPS
Create SAPS
Assign
Encapsulation
value of the port
Customer
Info.
Create SDPs
Create SDPs Bind Specify transport
tunnels
Bind
Bind
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.
ePipe SAP & SDPs

SDP Number
VC ID
SAP
SAP SAP
SDP 7
SDP 3

SDP Diagnostics SDP-Ping
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

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
SDP-Ping
sdp-ping
Originating SDP Responding SDP Interval Timeout Count Size
Size Increment Step
MTU
discovery test
PE-A
PE-B
SDP
SDP D
E
M
U
X
D
E
M
U
X
CPU
Originating
Bidirectional - Responding
SDP Provided
CPU
Unidirectional - Responding SDP
not provided
QOS Test
Forwarding Class Profile
or

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.
Service Ping (Svc-Ping)
svc-ping Target node Service
local sdp remote sdp
Uses the configured
outbound SDP encapsulation and
label.
Try to limit the number of concurrent service tests.
Different services could be using the same SDPs.
SDP-Ping may be more effective test.
Uses the configured
remote SDP
encapsulation and label.
If not specified, GRE encapsulation packet
with OAM label used.
Service-id
SAP
PE-A
PE-B
Customer
access
ports SDP
SDP D
E
M
U
X
D
E
M
U
X
SVC
VC Label A
VC Label B
SVC
Customer
access
ports
No remote
SDP supplied
No local
SDP supplied
SAP
Service-id

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 SVC-
Ping reply message is sent using GRE encapsulation with an OAM label.
End of Module
Services ePipe
43
Module 3
Virtual Private LAN Service (VPLS)
Section 4
Services
Services VPLS 4 3 2
Objectives
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

Services VPLS 4 3 3
Populating a Forwarding Database (FDB)
Host A sends a frame to Host C
1. The switch receives a frame on port 1/1/1
Host As MAC address is learned from the frames Source Address field and is
associated with port 1/1/1
2. 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
From Host Cs response frame, the switch associates Host Cs MAC address with
port 1/1/3
payload DA SA
Host A
Host C
Host B
00-00-5e-00-01-8e 1/1/1
00-e0-b1-83-32-d8 1/1/3
FDB Learning MAC Addresses
Services VPLS 4 3 4
Forwarding Databases Using Tagging
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
2. 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
From Host Cs response frame, the switch populates Host Cs MAC address in
VLAN 3s FDB
payload DA SA VLAN 3
Host A
Host C
Host B
Host D
3 3
6
Services VPLS 4 3 5
Ethertype
The Ethertype field describes the payload of the ethernet frame
For example Etype 8447 identifies this packet as Unicast MPLS
IPv6 0x86DD
MPLS unicast 0x8847
Provider Bridging 0x88a8
VLAN Tagging (QinQ) 0x9100
VLAN Tagging (Dot1Q) 0x8100
Address Resolution Protocol (ARP) 0x0806
Internet Protocol, Version 4 (IPv4) 0x0800
Protocol Ethertype for some
common Protocols
DA SA
VC
Label
Payload FCS
MPLS
Label
0x8847 Ethertype MPLS (8847)
0
1536
Etype
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
Services VPLS 4 3 6
Ethertype - VLAN
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
DA
DA
DA
SA
SA
SA
0x0800 Payload FCS
Tag Y Tag X
0x8100
0x9100 0x8100
Null No Tagging SAP 1/1/1
Dot1Q One Tag SAP 1/1/1:3
QinQ Stacked Tags - SAP 1/1/1:X.Y
0
1514
0
1518
0
1522
Payload FCS Tag 3
Payload FCS
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
Services VPLS 4 3 7
Building a Local Virtual Private LAN Service (VPLS) Service
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
VPLS 600
sap 1/1/4:6
payload DA SA VLAN 3
Host A
Host B
1/1/1:3
0x8100
1/1/2:3
Host C
1/1/3:3 Host D
1/1/4:6
1518
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.
Services VPLS 4 3 8
How is a VPLS provided over MPLS?
Bridging capable PE routers
connected with a full mesh of MPLS LSP tunnels
Per-Service VC labels
negotiated using draft-Martini
Unknown/broadcast
traffic replicated in a service domain
MAC learning
over tunnel & access ports
separate FIB per VPLS
LSP Full-Mesh
PE A PE C
PE B
PE D

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.
Services VPLS 4 3 9
Packet Format
The customer frame becomes the payload of the MPLS frame
IP/MPLS
POP
POP
CPE
CPE
CPE
CPE
PE
PE
PE
PE

payload DA SA 0x0800 payload DA SA 0x0800
payload DA SA
MPLS
Label
0x8847
VC
Label
DA SA 0x0800
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.
Services VPLS 4 3 10
Flooding Traffic within a VPLS
SAP
SAP
SDP
SDP
SDP
VPLS 300
SAP
SDP
SDP
SDP
SAP
SDP
SDP
SDP
SAP Floods to everybody
Spoke SDP Floods to everybody
Mesh SDP Floods to SAPs and Spoke SDPs only
VPLS 300
VPLS 300
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.
VPLS - VC Label
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
PE1->PE2: For Svc-id 101 UseVC-label pe2-1
PE2->PE1: For Svc-id 101 Use VC-label pe1-2
PE1
PE2
PE3
M-1
M-3
M-4
pe2-1
pe1-2
pe3-2
pe3-1
pe1-3
pe2-3
VPLS VPLS

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.
VPLS Packet Walkthrough - VPLS Learning
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
Tunnel to PE2 Remote MAC3
Mapping Location MAC
1/1/2
1/1/2
PE 2
PE 3
PE 1

MAC 3
1/1/1
1/1/3
MAC 2
MAC 1
MAC 4
1/1/2 Local MAC3
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
VPLS Packet Forwarding
Reply with a packet from M1 to M3
PE1 learns M1 is on Port 1/1/1
PE1 knows that M3 is reachable via PE2
PE1 sends to PE2 using VC-label pe1-2
PE2 learns MAC 1 is reachable via PE1
PE2 knows that M3 is reachable on Port 1/1/2

1/1/1
1/1/3
1/1/2
1/1/2
PE 2
PE 3
PE 1
MAC 2
MAC 1
MAC 3
MAC 4
1/1/2 Local MAC3
1/1/1 Local MAC1
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.
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.
Building a Distributed VPLS Service
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
Host A
1/1/1:3
SDP 13
Host B
1/1/1:3
SDP 31
VPLS 300 VPLS 300
SDP 12 SDP 32
SDP 21 SDP 23
VPLS 300
1/1/1:3
PE1
PE2
PE3
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 node and port
Select Accounting Policy (optional)
Select Ingress/Egress QOS Policies (optional)
Select scheduler policy (optional)
Select Filter policies (optional)
Service Distribution Path Binds a service to an SDP
Can be a Spoke or Mesh SDP
VPLS Configuration Workflow
Create Service
(VPLS)
Create Service
(VPLS)
Bind the service to
the customer at
service creation
time
Manage Service
Manage Service
Service Topology
View
Properties
Configure a
Customer
Configure a
Customer
Configure
Access Ports
Configure
Access Ports
Specify MTU
Specify
Encapsulation type
Bind to a SDP
Virtual Circuit
(service tunnel)
Bind to a SDP
Virtual Circuit
(service tunnel)
Assign VC Label
Specify Mesh-SDPs
Create SAPS
Create SAPS
Assign
Encapsulation value
of the port
Customer
Info.
Create SDPs
Create SDPs Bind Specify transport
tunnels
Bind
Bind
VPLS SAP & SDPs
SDP Number
VC ID
SAP
.
.
.
VPLS MAC Diagnostics
The VPLS MAC diagnostics provide the means to test the learning and forwarding functions on a per-
VPLS-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
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.
VPLS MAC Diagnostics MAC Ping
MAC
Address
A
Service 1
SAP
PE-C
SDP
D
SDP
Service 1
SAP
PE-B
SDP
D
SDP
MAC
Address
B
Service 1
SAP
PE-A
SDP
D
SDP
Mac-traceroute lists the
intermediate nodes between
source and destination
MAC
Address
C
SERVICE
CORE
PE-B has the MAC in its FIB, acknowledges the ping. Mac-Ping Service 1 to destination MAC address B.
PE-A will send a MAC-ping to PE-B (per the FIB).
All nodes in the service respond. Mac-ping service 1 destination FF:FF:FF:FF:FF:FF
No node responds. Mac-Ping Service 1 to destination D (unknown)
Sends the MAC-ping to all nodes (per the FIB)
RESULT ACTION

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.
End of Module
Services VPLS
44
Module 4
iPipe
Section 4
Services
Services iPipe 4 4 2
MPLS Network
IP Pseudo-Wires
PPP/ML-PPP
IP/Ethernet
What is IP Pseudowires (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
SAP SAP
SDP
SDP
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
Service Access via n*T1/E1 (e.g.
PPP and ML-PPP) is still very
common
Examples: CE branch equipment
(routers), CDMA base stations
Carriers want to modernize their
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
3 |
CDMA BTS Branch Office
IP/MPLS
on Metro Ethernet
ML-PPP
IES/VPRN
Ethernet
& GE
RNC/BSC
Regional/ HQ
Why iPipes?
IPipes support Ethernet, MLPPP, Frame Relay, ATM SAPs
3
Epipe vs. IPipe
IPipe
Provides IP interworking VPWS
Supports routed encapsulation
Less network overhead because
ethernet header is taken out
Both hosts appear to be on the
same IP subnet or network
Mac learning
Local & Remote CE IP address
configuration is required
Epipe
Provides ethernet VPWS
Supports bridged encapsulation
More network overhead because
ethernet header is transported
Both hosts appear to be the same
ethernet LAN
No Mac learning
Easier to configure
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.
SR
Physical View
Logical View
138.120.122.2/29 138.120.122.1/29
RNC
IP/MPLS
Distributed IPipe
SR
IPipe
PPP/IPCP IP Data
IP/MPLS
MPLS/PW
SAR
Distributed IPipe
PPP/ML-PPP
IP/Ethernet
IP Data
Ethernet IP Data
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
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
Ipipe Configuration Workflow
Create Service
(Ipipe)
Create Service
(Ipipe)
Bind the service
to the customer
at service
creation time
Manage Service
Manage Service
Service Topology
View
Properties
Configure a
Customer
Configure a
Customer
Configure Access Ports
(Ethernet, PPP / ML-PPP)
Configure Access Ports
(Ethernet, PPP / ML-PPP)
Specify MTU
Specify
Encapsulation type
Bind to a SDP
Virtual Circuit
(service tunnel)
Bind to a SDP
Virtual Circuit
(service tunnel)
Assign VC Label
Specify CE IP
Address
Create SAPS
Create SAPS
Assign
Encapsulation
value of the port
Specify CE IP
Address
Create SDPs
Create SDPs
Bind
Specify transport
tunnels
Bind
Bind
specify the Encapsulation ID (as required) and specify the service MTU size. Specify the CE IP Address.
automatically, by the 5620 SAM. Specify the CE IP Address.
IPipe Service : Configuration Overview
1.1.1.1
SAP SAP
SDP SDP IPipe
1.1.1.2
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.2 1.1.1.1
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.
IPipe Service : Configuration Overview
SDP Number
VC ID
SAP
SAP SAP SDP 6
SDP 1
End of Module
Services iPipe
4.5
Module 5
Internet Enhanced Service (IES)
Section 4
Services
Services IES 4 5 2
Module Objectives
Upon successful completion of this module, the student will be
familiar with:
Features of an Internet Enhanced Service
Basic configuration an IES
Services IES 4 5 3
Internet Enhanced Service (IES)
An IES is a routed, layer 3 connectivity service:
Interface
SAP
IP Address
1. IES Interfaces can be included in the following routing protocol:
Static, RIP, OSPF, ISIS, and BGP
2. VPLS can be bound to an IES
3. IES can terminate spoke-SDPs such as an EPipe, IPipe, or H-VPLS
service
SAP
IES 500
OSPF
OSPF
Interface: Port & IP Address
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.
Services IES 4 5 4
IES Routed Connectivity Service Example
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
SAP
IES 500
OSPF
OSPF
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
Services IES 4 5 5
IES Configuration Workflow
Create Service
(IES)
Create Service
(IES)
Bind the service
to the customer
at service
creation time
Manage Service
Manage Service
Service Topology
View
Properties
Configure a
Customer
Configure a
Customer
Configure
Access Ports
Configure
Access Ports
Specify MTU
Specify
Encapsulation type
Add to OSPF
Add to OSPF
Enable OSPF
Enable Passive
Mode
Create Layer 3
Access Interface
Create Layer 3
Access Interface
Customer
Info.
Bind
Bind
Interface Name
Assign IP Address
Port / SAP
Internet Enhanced Service.
Services IES 4 5 6
End of Module
Services IES
46
Module 6
Virtual Private Routed Networks (VPRN)
Section 4
Services
Services VPRN 4 6 2
Objectives
The need for L3 VPNs
L3 VPN : VPRN setup and configuration
Packet Walkthrough

Services VPRN 4 6 3
Virtual Private Routed Networks (VPRN): Overview
192.168.1.0/24
192.168.1.0/24
192.168.2.0/24
192.168.2.0/24
Customer 1
Customer 2 Customer 2
VRF for Customer 1 VPRN
VRF for Customer 2 VPRN
Customer 1
Customer 1
VPN
Customer 2
VPN
VRF 1 VRF 1
VRF 2
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
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)
May maintain multiple VRFs depending on the number of customers connected
Contains customer destination routes
local sites
remote sites
MP-BGP is used to carry the VPN routes
Services VPRN 4 6 4
VPN-IPv4
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
VPN-IPv4 IPv6
Mcast
IPv4
IPv4
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.
Services VPRN 4 6 5
IP-VPN: Route Distinguisher
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
8 bytes
IPv4 Prefix
4 bytes
VPN-IPv4 Prefix
12 bytes
192.168.1.0/24 65530 : 10 65530:10:192.168.1.0/24
ASN
Type 0 RD Structure:
ASN: Autonomous System # of the VPRN
Integer: Administratively assigned value
Integer
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.
Services VPRN 4 6 6
IP-VPN: Route Target
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
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.
Services VPRN 4 6 7

IP-VPN: RD vs. RT (Packet Capture)
RT is a part of the extended community attributes
RD is part of the route attributes
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.
Services VPRN 4 6 8
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)
L3 VPN: VPN Label
MP-BGP Update
(Prefix =65530:20:192.168.1.0
RT = 65530:20
VPN Label = 131068)

VRF 1
VRF 2
Customer 1
Customer 2
MPLS
Label
Layer 2 VPN
Label
=
131068
IP Data
192.168.1.0/24
Customer 2
Customer 1
VRF 1
VRF 2
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.
Services VPRN 4 6 9
RIB-in RIB
RIB-out
BGP
BGP
BGP
Received
and processed
BGP routes
to be used in
routing decisions
Received
BGP Updates
from neighbours
BGP Updates
to be sent
to neighbours
Outgoing
BGP Update
Incoming
BGP Update
BGP
Import Policy
OSPF RIP Static
BGP
Export Policy
(Redistribution)
BGP: Different Routing Information Databases
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.
Services VPRN 4 6 10
PE-1 (1.1.1.1/32)
PE-2 (2.2.2.2/32)
IP-VPN: Routing Information Exchange (Walkthrough)
VPRN
Export Policy
CE-1 Route Table:
Prefix NH Proto
----------------------------
1.1.10.0/24 IF_x Local
VRF 10 VRF 10
RIB RIB-O RIB-i
BGP BGP BGP
RIB RIB-O RIB-i
BGP BGP BGP
VPRN
Import Policy
RD = 100:10
eRT = 100:10
PE-1 VRF:
Prefix NH Proto
----------------------------------
10.1.1.0/30 IF_CE Local
1.1.10.0/24 10.1.1.2 RIP
PE-2 BGP RIB:
Network NH VPN Label
---------------------------------------------
100:10:1.1.10.0/24 1.1.1.1 131069
(RT = 100:10)
PE-2 VRF:
Prefix NH Proto
----------------------------------
1.1.10.0/24 1.1.1.1 BGP VPN
Route Update
BGP Update
Route Update
iRT = 100:10
MP-BGP Peering
IF_CE IF_CE
1.1.10.0/24
IF_x

PE-1 BGP RIB-OUT:
Network NH VPN Label
---------------------------------------------
100:10:1.1.10.0/24 1.1.1.1 131069
(RT = 100:10)
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.

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
VRF Policies
vrf-target command vrf-import & vrf-export
commands (policies)
IP-VPN: VRF Import and Export Methods
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.
VPRN Configuration Workflow
Create Service
(VPRN)
Create Service
(VPRN)
Specify AS & Router
IP address
Create BGP Peers
Manage Service
Manage Service
Auto-Bind SDPs
Configure a
Customer
Configure a
Customer
Configure
Access Ports
Configure
Access Ports
Specify MTU
Specify
Encapsulation type
Auto-Bind to an
SDP Virtual Circuit
Auto-Bind to an
SDP Virtual Circuit
Interface Name
Assign IP Address
Port / SAP
Create Layer 3
Access Interface
Create Layer 3
Access Interface
Specify Route
Distinguisher & Route
Target
Specify SNMP
Community
Customer
Info.
Bind
Bind
Enable BGP
Enable BGP
Service Topology
View
Properties
End of Module
Services VPRN
@@COURSENAME - Page 1
@@COURSENAME
@@PRODUCT
1
Last But One Page
@@COURSENAME - Page 2
Passing on and copying of this document, use and communication of its
contents not permitted without written authorization from Alcatel-Lucent

SAM IP-MPLS Service Provisioning

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SAM IP-MPLS Service Provisioning

Uploaded by

Copyright:

Available Formats

SAM IP-MPLS Service Provisioning - Page 1

All Rights Reserved Alcatel-Lucent 2011

You might also like