SAM IP-MPLS Service Provisioning PDF

SAM IP-MPLS Service
Provisioning
TOS36024 Issue 1
STUDENT GUIDE
All Rights Reserved Alcatel-Lucent 2011
All rights reserved Alcatel-Lucent 2011

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

SAM IP-MPLS Service Provisioning - Page 1
Empty page
Switch to notes view!
SAM IP-MPLS Service Provisioning
This page is left blank intentionally

Terms of Use and Legal Notices

1. Safetyto
Warning
Switch
notes view!
Both lethal and dangerous voltages may be present within the products used herein. The user is strongly advised not to
wear conductive jewelry while working on the products. Always observe all safety precautions and do not work on the
equipment alone.
The equipment used during this course may be electrostatic sensitive. Please observe correct anti-static precautions.
2. Trade Marks
Alcatel-Lucent and MainStreet are trademarks of Alcatel-Lucent.
All other trademarks, service marks and logos (Marks) are the property of their respective holders, including AlcatelLucent. Users are not permitted to use these Marks without the prior consent of Alcatel-Lucent or such third party owning
the Mark. The absence of a Mark identifier is not a representation that a particular product or service name is not a Mark.
Alcatel-Lucent assumes no responsibility for the accuracy of the information presented herein, which may be subject to
change without notice.
3. Copyright
This document contains information that is proprietary to Alcatel-Lucent and may be used for training purposes only. No
other use or transmission of all or any part of this document is permitted without Alcatel-Lucents written permission, and
must include all copyright and other proprietary notices. No other use or transmission of all or any part of its contents may
be used, copied, disclosed or conveyed to any party in any manner whatsoever without prior written permission from
Alcatel-Lucent.
Use or transmission of all or any part of this document in violation of any applicable legislation is hereby expressly
prohibited.
User obtains no rights in the information or in any product, process, technology or trademark which it includes or
describes, and is expressly prohibited from modifying the information or creating derivative works without the express
3written 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 AlcatelLucent has been advised of the possibility of such damages.
Mention of non-Alcatel-Lucent products or services is for information purposes only and constitutes neither an
endorsement, nor a recommendation.
This course is intended to train the student about the overall look, feel, and use of Alcatel-Lucent products. The
information contained herein is representational only. In the interest of file size, simplicity, and compatibility and, in some
cases, due to contractual limitations, certain compromises have been made and therefore some features are not entirely
accurate.
Please refer to technical practices supplied by Alcatel-Lucent for current information concerning Alcatel-Lucent equipment
and its operation, or contact your nearest Alcatel-Lucent representative for more information.
The Alcatel-Lucent products described or used herein are presented for demonstration and training purposes only. AlcatelLucent disclaims any warranties in connection with the products as used and described in the courses or the related
documentation, whether express, implied, or statutory. Alcatel-Lucent specifically disclaims all implied warranties,
including warranties of merchantability, non-infringement and fitness for a particular purpose, or arising from a course of
dealing, usage or trade practice.
Alcatel-Lucent is not responsible for any failures caused by: server errors, misdirected or redirected transmissions, failed
internet connections, interruptions, any computer virus or any other technical defect, whether human or technical in
nature
5. Governing Law
The products, documentation and information contained herein, as well as these Terms of Use and Legal Notices are
governed by the laws of France, excluding its conflict of law rules. If any provision of these Terms of Use and Legal
Notices, or the application thereof to any person or circumstances, is held invalid for any reason, unenforceable including,
but not limited to, the warranty disclaimers and liability limitations, then such provision shall be deemed superseded by a
valid, enforceable provision that matches, as closely as possible, the original provision, and the other provisions of these
Terms of Use and Legal Notices shall remain in full force and effect.

Blank Page

About this Student Guide

Conventions
used
in this guide
Switch
to notes
view!
Note
Provides you with additional information about the topic being discussed.
Although this information is not required knowledge, you might find it useful
or interesting.
Technical Reference
(1) 24.348.98 Points you to the exact section of Alcatel-Lucent Technical
Practices where you can find more information on the topic being discussed.
Warning
Alerts you to instances where non-compliance could result in equipment
damage or personal injury.
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

About this Student Guide [cont.]

6

Do not delete this graphic elements in here:
11
Section 1
System Operation
Module 1
File System and CLI
All Rights Reserved 2011, Alcatel-Lucent

Section 1 Module 1 Page 1
Objectives
112
Upon successful completion of this module, you will be able to explain:

Access options

Command Line Interface (CLI) hierarchical structure

File structure
Initialization process
Boot Option File (BOF)
File Management System
5620 SAM IP/MPLS Service Provisioning

SNMP Components SNMP Agent

113
Responds to SNMP
manager requests
Sends Traps
SNMP Manager
(SNMP
(SNMPManaged
ManagedNodes)
Nodes)
Software
process
SNMP
SNMPAgent
Agent
Software
process
Software
process
SNMP
SNMPAgent
Agent
SNMP
SNMPAgent
Agent
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.

Introduction to the 5620 SAM Discovery Manager

114
Reconciles router
elements into the
5620 SAM database
SAM DB
Di
Network Mgmt IP
Persistence on
SSH Preserve Key
SN
MP
re
sco
ve
ry
M
sp
on
s
an
ag
er
Router ID
managed
network
SNMP security
SNMP no shutdown
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.

The Physical Access

115
OOB-CPM
Management
Ethernet
Port
CPM Console Port
In-band
Customer
Facing
Access Ports
&
Network Ports
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.

The Help Command

116
Help
Displays a brief description of the help system
Lists all commands in the current context
string ?
Lists all commands available in the current context that start

with string
command ?
Displays commands syntax and associated keywords
command keyword ?
Lists the associated arguments for keyword in command
Help Edit
Displays help on editing (editing keystrokes)

Lists available editing key strokes
Help Globals
Displays help on global commands

Lists available global commands
The Help command is one of the most useful commands. While configuring or managing an SR, the
help command can provide the syntax and attributes available in the current context.
Some basic Help commands:
Help
Displays a brief description on the Help functionality. This command can be

used in any context.
This command displays all the possible commands in the current context.
string ?
Lists all the possible commands in the current context that start with
string.
Command ?
Displays a commands syntax and associated keywords.
Command keyword ?
Lists all the associated arguments for a keyword in a command.
Help Edit
Displays help on editing (editing keystrokes) and lists all available editing
key strokes.
Help Globals
Displays help on the global commands and lists all available global
commands.

The CLI command prompt

117
Example: Configuring SNMP
Node>config>system>snmp#
Host name Node
Context separator
Example: Configure system interface

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

The Auto-completion Commands

118
Command completion can be achieved by:
Abbreviation, if keystrokes entered are unique enough.

Node>config# ro [ENTER]
Node>config>router#
Tab Key or Space Key to auto-complete the command.
Node>config# ro [TAB]
Node>config# router
Node>config# ro [SPACE]
Node>config# router
If match is not unique CLI will display possible matches:

Node>config# r [TAB]
redundancy router
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).

File System Structure

119
Root
bof.cfg
Boot
Option
File
boot.ldr
Bootstrap
Image
m
n
Y
TiMOS-m.n.Yz
config.cfg
Default
Configuration
File
cpm.tim
iom.tim
both.tim
(SR-7/-12)
(SR-7/-12)
(SR-1)
CPM
Image
File
IOM
Image
File
Major release number

Minor release number
A
Alpha Release
K
Beta Release
M
Maintenance Release
R
Released Software
J
Internal Engineering and Test Release
Version number
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:
Node# file
Enter the CLI File context.
Node>file cf3:\ # attrib
Display or change the current working

directory in the local file system.
Node>file cf3:\ # cd [..]
Display or change the current working

directory in the local file system.
Node>file cf3:\ # dir
Display a list of files and subdirectories

in a directory.
Node>file cf3:\ # md
Create a new directory in the local file

system.
Node>file cf3:\ # rd
Remove (delete) a directory in the local

file system.
Node>file cf3:\ # copy

Node# file copy
cf3:\config.cfg
ftp://10.1.1.1/config.cfg
Copy a file or all files in a directory

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

File System CLI Context

1 1 11
Root
File
Attrib
Cd
Copy
Delete
Dir
Md
Move
Rd
Scp
Type
Version
Some commands:
Node>file cf3:\ # delete
Delete the specified file. The optional

wildcard (*) can be used to delete
multiple files that share a common
(partial) prefix and/or (partial) suffix.
Node>file cf3:\ # move
Move a local file, system file, or a

directory. If the target already exists,
the command fails and an error message
displays.
Node>file cf3:\ # scp
Copy a file from the local files system to

a remote host on the network. scp uses
ssh for the data transfer, and uses the
same authentication and security as ssh.
Node>file cf3:\ # type
Display the content of a text file.
Node>file cf3:\ # version
Display the version of an OS cpm.tim

or iom.tim file.

Managing The BOF

1 1 12
Boot
Option
File
The system uses the BOF file to perform the following tasks:
1)
2)
3)
4)
5)
6)
7)
8)
9)
10)
Configure Primary, Secondary, Tertiary image source

Configure Primary, Secondary, Tertiary configuration source
Create an IP address for the CPM Ethernet port
Create a Static route for the CPM Ethernet port
Configure the DNS Domain name
Set up the CPM Ethernet port (speed, duplex, auto)
Configure persistence requirements
Enable/disable Lawful Intercept configuration to be saved locally
Enable/disable separate access to Lawful Intercept (LI) information
Set the console port speed
Always be sure to save the BOF!
Parameters that are configured in the BOF are shown in the chart above.
Some commands:
Node# bof
Enter the CLI BOF context to change or

create a bof file.
Node>bof# address 10.10.10.2/24

primary
Change or create the CPM Ethernet Port

IP address.
Node>bof# speed 100
Set the CPM Ethernet Port speed to 100

Mbps.
Node>bof# primary-image
cf3:/TIMOS.5.0.R0
Set the primary image directory.
Node>bof# primary-config cf3:/test.cfg
Set the primary configuration file (eg.

test.cfg).
Node>bof# save
Save the bof.
Node# show bof
Display the in-memory bof file (last

used).

System Initialization
1 1 13
START
N
Config found ?
Initialize
Hardware
Startup
Failed
Get config
(3 possible locations)
N
Y
Load & Execute
boot strap loader
(cf3:\boot.ldr)
Process
boot option file
(cf3:\bof.cfg)
Image OK ?
Get runtime image

(3 possible locations)
Persistence
Needed for proper SAM
Operation: see
optional topic
Process
persistence
and
Configuration
files
Log In
Prompt
Persistence
File Processed
OK
1
N
Y
SNMP shutdown
Issue Trap (if possible)
Issue Log entry
Issue Console msg
Y
Config File
Processed OK
User intervention point:
Need
Persistence
?
Y
Process
Config File
Wait
required
Boot with Defaults

SNMP shutdown
Issue Trap
Issue Log entry
Issue Console msg
User activity detected
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.

Basic Router Configuration

1 1 15
1.
Launch a CLI or SSH session to the router
2.
Configure Network Management IP

a. # bof <Enter>
b. # show bof
Tip
If address is not defined, type the following:
a. bof# address <IP address/ subnet mask> <Enter>
3.
4.
5.
Set persistence on
a. bof# persist on <Enter>
Define a location to save the configuration file
a. bof# primary-config <file location:/file path/filename.cfg>
Save the bof
a. bof# save
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.

Basic Router Configuration [Cont.]

1 1 16
6.
Define the Router ID

a. # configure router interface system address
<IP address/32> <Enter>
7.
Configure SNMP Security

a. # configure system security snmp <Enter>
b. # community <community string> rwa version both <Enter>
8.
Enable
a. #
b. #
c. #
9.
Enable SSH Preserve Key

a. # configure system security ssh preserve-key <Enter>
SNMP
configure system snmp <Enter>
packet-size 9216 <Enter>
no shutdown <Enter>
10. Confirm changes

a. # show bof <Enter>
b. # show router interface <Enter>
c. # configure system security snmp <Enter>
# info
d. # configure system snmp <Enter>
# info
Attention:
Remember to save theAll Rights
router
Reserved
configuration
Alcatel-Lucent 2011
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

Objectives
Interface Configuration
Routing Protocol
212

System Interface
System interface IP address must be configured

IP Address
No Port - System IP address is referred to as the loopback IP address
System IP address is used when signaling the MPLS LSP (via LDP) and
when signaling the VLL (via t-LDP)
213

Network Interfaces
Only one IP address can be configured per network facing link

Interface Name
IP Address
Port
IP interfaces are maintained during CSM activity switch-over
All connections are assumed to be point-to-point
214

Static Routing
192.168.11.0/30
192.168.11.1 A
192.168.22.0/30
Node1
Node2
10.12.1.0/29
B
10.12.1.1
B
10.12.1.2
Routing Table:
192.168.11.0/30 Direct via interface A
10.12.1.0/29 Direct via interface B
192.168.22.0/30 static via 10.12.1.2
215
A 192.168.22.1
Routing Table:
192.168.22.0/30 Direct via interface A
10.12.1.0/29 Direct via interface B
192.168.11.0/30 static via 10.12.1.1
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
Link State
Database
Dijkstras
Algorithm
Route
Table
LSAs are flooded to other interfaces

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

OSPF Overview
Open Shortest Path First (OSPF) is one of the most popular link-state
interior gateway protocols used in large enterprise networks.
Features:
217
Scalable
Hierarchical (using areas)
Supports authentication
Fast convergence
Uses Dijkstras Shortest Path First (SPF) algorithm for route selection
Classless; supporting VLSM, CIDR, and manual route summarization
Routing metric is based on the physical bandwidth of the port
Traffic Engineering support
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
218
Enable OSPF
Create Area
Add Interfaces

ISIS Overview
Intermediate System-to-Intermediate System (IS-IS)
Both ISIS and OSPF are link state protocols
Features:
219
Scalable
IS-IS routing uses two-level hierarchical routing
Supports authentication
Fast convergence
Uses Dijkstras Shortest Path First (SPF) algorithm for route selection
Classless; supporting VLSM, CIDR, and manual route summarization
Routing metric is based on the physical bandwidth of the port
Traffic Engineering support
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
2 1 10
Enable ISIS
Create Area
Add Interfaces

End of Module/Lesson
IP Routing
2 1 11

2 1 12

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
312

MPLS Overview
313

7705 SAR Label Signaling and Distribution Summary
Label Signaling &

Distribution
Manual
Static
Dynamic
MPLS Service Signaling
Dynamic
LDP
RSVP
T-LDP
Hop by Hop
IGP / CSPF
IGP
Best Effort
IGP
Targeted Session
Explicit Path
Loose / Strict Paths
314
MP-BGP
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
Push
Swap
LER
Pop
Swap
LSR
LSR
LER
Label Switched Path
data
label
data
label
IP Forwarding
data
label
LABEL SWITCHING
315
data
data
IP Forwarding
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
Frame header
DA
SA
Type =
88 47
Single Label
MPLS
Header
IP Header
IP Packet
FCS
Label Stack
Data Link
Header
MPLS Header
1
MPLS
Header 2
IP Header
IP Data
FCS
4 Octets
Label Stack
Entry Format
Label
Label:
Exp.:
S:
TTL:
316
Exp.
TTL
Label Value, 20 bits

Experimental, 3 bits (Class of Service)
Bottom of Stack, 1 bit (1 = last entry in label stack)
Time to Live, 8 bits
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

Table
Name
Meaning
Contents
Populated By
RIB
Routing Information Base
Routing updates received
Routing Protocol Exchange - Each routing

protocol has a separate RIB
FIB
Forwarding Information
Base
Active routes
RTM selects the active routes from all

protocol "Best" routes
LIB
Label Information Base
Locally generated and

received MPLS labels
MPLS Label Exchange
LFIB
Label Forwarding
Information Base
Labels used by the LSR
The labels assigned to the active routes (for

each next-hop)
OS
P
Fu
pd
LD
ate
Pu
pd
a
te
RIB OSPF
FIB
LD
IS
IS -
d
up
317
Pu
a
pd
te
RIB IS-IS
ate
LFIB
LIB LDP
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
318

Label Distribution Protocol - Purpose

Each LSR will originate a label for its system address by default
LDP relies on the underlying routing information provided by an IGP in
order to communicate label bindings to peers
The router forwarding information base, or FIB, is responsible for
determining the hop-by-hop path through the network
LSR 2
LSR 1
1/1/2
1/1/3
1/1/3
1/1/1
10.2.1.0/24
1.1.1.1/32
Prefix
1/1/1
1/1/2
1/1/2
1/1/1
10.1.1.0/24
LSR 1
LFIB
LSR 4
LSR 3
Ing.
Label
3.3.3.3/32
2.2.2.2/32
Egr.
Label
Egr.
Intf
Next-hop
LSR 4
LFIB
Prefix
4.4.4.4/32
Ing.
Label
Egr.
Label
Egr.
Intf
Next-hop
10.2.1.0/24
131068
1/1/2
LSR2
10.1.1.0/24
131065
1/1/3
LSR3
4.4.4.4/32
131071
1/1/2
LSR2
1.1.1.1/32
131070
1/1/3
LSR3
Control Plane
319
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.
iLER
LIB
Prefix
Next-hop
Label
10.2.1.0/24
LSR 2
131065
10.2.1.0/24
LSR 3
131066
Unsolicited:
1.1.1.1/32
Each LSR will originate a label for its

system address by default. Label
mappings are provided to all peers for
which the local LSR might be a next-hop,
even when not explicitly requested.
iLER
FEC: 10.2.1.0/24
Label: 131065
2.2.2.2/32
LSR2
FEC: 10.2.1.0/24
FEC: 10.2.1.0/24
Label: 131067
Label: 131066
10.2.1.0/24
LSR3
4.4.4.4/32
eLER
FEC: 10.2.1.0/24
3.3.3.3/32
Label: 131067
3 1 10
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
Liberal Retention:
Ordered Control:
The label received from the router

providing the active IGP route for
the FEC is used and the other labels
are kept
The LSP will not pass data until the

setup messages have propagated from
end to end
Label
2.2.2.2/32
131065
LSR2
1.1.1.1/32
iLER
LIB
Prefix
Next-hop
Label
10.2.1.0/24
LSR 2
131065
10.2.1.0/24
LSR 3
131066
iLER
Prefix
Next-hop
10.2.1.0/24
LSR 3
Prefix
Next-hop
Label
10.2.1.0/24
LSR 3
131066
Label
131067
10.2.1.0/24
Step 1
LSR3
4.4.4.4/32
3 1 11
Step 1
iLER
LFIB
131066
Step 2
Label
iLER
FIB
Step 2
Label
131067
eLER
3.3.3.3/32
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.

LDP: Convergence
LSP before the failure

LSP after the failure
LSR2
1/1/2
1/1/3
LSR4
1000
LER2
10.10.10.1/32
LER1
LSR1
LER 1
LFIB
Prefix
10.10.10.1/32
Ingress
Label
-
Egress
Label
Egress
Interface
nexthop
MPLS Convergence =
131068
1/1/2
LSR 2
Failure Detection Time +

IGP Convergence +
LER 1
LFIB
Prefix
10.10.10.1/32
3 1 12
Ingress
Label
-
Egress
Label
Egress
Interface
nexthop
131065
1/1/3
LSR 1
LDP Convergence
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
PE1
P1
P2
PE2
Provider
Network
PE-3
P3
3 1 13
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
3 1 14

Resource Reservation Protocol - Traffic Engineering (RSVP-TE)
Advantage of using RSVP to establish LSP tunnels is that it enables the

allocation of resources along the path
For example, bandwidth can be allocated to an LSP tunnel using standard

RSVP reservations and Integrated Services service classes
RSVP-TE includes Traffic Engineering Capabilities:

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

One to One Backup a backup LSP is created separately for each protected
LSP
Facility Backup A bypass tunnel is created to protect a set of LSPs passing
over a common facility
3 1 15
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
Downstream on Demand (DoD)

2.2.2.2/32
iLER
Resv: label 131068
LSR2
4.4.4.4/32
3 1 16
LSR1
Path: 3.3.3.3
Path: 3.3.3.3
1.1.1.1/32
Resv: label 131071
PATH message sent

towards tunnel
destination
Receiver sends RESV
message back
towards sender
eLER sends label
binding info in RESV
message
Path Refresh and
RESV Refresh
messages are sent
periodically
eLER
3.3.3.3/32
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
iLabel eLabel Action

--131068 Push

131068 131071 Swap
2.2.2.2/32
LSR1
Label Switched Path

Label Switched Path
After the Resv

message is
propagated
upstream to the
sender node, a
label-switched path
is effectively
established
1.1.1.1/32
iLER
eLER
3.3.3.3/32
LSR2
4.4.4.4/32
3 1 17

131071 --- Pop
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
RSVP Path
ERO provides specific

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

Label_Request
ERO: 10.12.1.2
10.23.1.3
10.34.1.4
4.4.4.4
Session_Attributes
1.1.1.1/32
PE1
.1
2.2.2.2/32
PE2
RRO: 10.12.1.1
.2
RSVP Path
10.12.1.0/29
10.14.1.29/29
10
.13
.1.
0 /2
.1
9
10.23.1.0/29
9
0/2
.1.
4
.2
10
10.34.1.0/29
1/1/2
.3
RSVP Path
.3
.4
.4
PE4
4.4.4.4/32
.2
LSP Tunnel (IPv4)

Label_Request
ERO: 10.12.1.2
10.23.1.3
10.34.1.4
4.4.4.4
Session_Attributes
RRO: 10.34.1.3
10.23.1.2
10.12.1.1
LSP Tunnel (IPv4)

Label_Request
ERO: 10.12.1.2
10.23.1.3
10.34.1.4
4.4.4.4
Session_Attributes
RRO: 10.23.1.2
10.12.1.1
PE3
3.3.3.3/32
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
RSVP Resv
Record Route
Object (RRO) of
RSVP-TE is used for
route recording
purpose
1.1.1.1/32
PE1
.1
RRO records the

actual route a
packet traversed
LSP Tunnel (IPv4)

Label: 65
Session_Attributes
RRO: 10.12.1.2
10.23.1.3
10.34.1.4
2.2.2.2/32
PE2
.2
10.12.1.0/29
10
.13
.1.
0 /2
.1
.2
9
10.23.1.0/29
10.14.1.29/29
9
.3
.4
0/2
.1.
4
.2
10
10.34.1.0/29
Recording the path

allows the iLER to
know, on a hop-byhop basis, which
LSRs the path
traverses
.4
PE4
4.4.4.4/32
3 1 19
RSVP Resv
RSVP Resv
LSP Tunnel (IPv4)
Label: 13
Session_Attributes
RRO: 10.23.1.3
10.34.1.4
.3
LSP Tunnel (IPv4)

Label: 100
Session_Attributes
RRO: 10.34.1.4
PE3
3.3.3.3/32
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
3 1 20

RSVP-TE: Signaled LSPs with CSPF
TE Capable IGP
OSPF-TE
IS-IS-TE
Routing Table
Traffic
Engineering
Database (TED)
Constrained
Shortest Path First
(CSPF)
User
Requirements
Explicit Route
Object
(ERO)
Signaling
3 1 21
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.43.3
10.10.42.3
10.10.10.101
10.10.10.99
10.10.10.102
10.10.44.3
10.10.10.100
10.10.10.103
RSVP PATH
Primary_Path
config>router# mpls
config>router>mpls#lsp LSP_99_103
config>router>mpls>lsp# to 10.10.10.103
config>router>mpls>lsp# cspf
config>router>mpls>lsp# primary Primary_Path"
config>router>mpls>lsp>primary# hop-limit 4
config>router>mpls>lsp>primary# bandwidth 256
config>router>mpls>lsp>primary# no shutdown
3 1 22
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
1.1.1.1/32
Blue Path
2.2.2.2/32
PE1
PE2
10.12.1.2
Red Path
10.23.1.3
10.34.1.4
PE4
4.4.4.4/32
3 1 23
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

PE3
3.3.3.3/32
LSP Redundancy
Primary
LSP Path
One primary path per LSP

Can be protected by up to 2 secondary LSPs
Secondary
LSP Path
Alternative path that the LSP uses when the primary path is not
available
When the primary path is re-established, the traffic is switched back
to the primary path
Up to 2 secondary paths can be specified
Both secondary paths are considered equal and the first available
path is used
No switch back among secondary paths
Similar to the primary path: reserved bandwidth, hop-limit count
and inclusion/exclusion of admin groups may be specified
3 1 24
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
LSP 1 Primary
Path
LSP 1 Secondary
Path
Secondary LSP Path in Standby

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

Path is not signaled until a network failure causes the primary path to fail
When the ILER node is aware of the failure, it signals the secondary path to
become active
No double reserving of resources
Increased latency associated with recovering a failed path
3 1 25
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)
3 1 26

Fast Reroute Overview

Disadvantages of Secondary Path only Protection
Failure downstream might take a while to reach the head of LSP

Double booking of resources
No selective protection of node or link

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

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

Secondary Path: Non-standby or Hot-standby
Failure in primary path triggers secondary LSP

PathErr
R3
R2
R1
R6
R9
R7
Primary LSP:
R1->R2->R3->R4
R4
R8
Secondary LSP:

Primary LSP: One primary path

R1->R6->R7->R8->R9->R4
Secondary LSP
Alternative path that is used if the primary path is not available.
Non-Standby needs to be signaled first (after primary path failure detection
Hot-Standby will be signaled upon creation
Continuously tries to revert back to the primary path.
Up to 8 secondary paths can be specified.
All the secondary paths are considered equal and the first available path is used.
The software will not switch back among secondary paths.
3 1 29
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
3 1 30
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
R10
PLR
R3
R2
R1
MP
PLR
PLR
R5
MP
R4
MP
(2)
(1)
R9
R6
R7
R8
(1)
Protected LSP 1:
R1->R2->R3->R4
R2s backup for Protected LSP 1

R2->R7->R8->R9->R4
(2)
Protected LSP 2:
R10->R2->R3->R4
3 1 31
R2s backup for Protected LSP 2

R2->R7->R8->R9->R4
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
PLR
R1
R3
R2
PLR
Merge Point
(MP)
(3)
R5
R4
PLR
(2)
(1)
R6
R9
R7
R8
Detour Tunnel
(1)
R1s backup:
R1->R6->R7->R8->R9->R4
Protected LSP:
R1->R2->R3->R4
3 1 32
(2)
(3)
R3s backup:
R3->R9->R4
R2s backup:
R2->R7->R8->R9->R4
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
Inner
label
Inner
label
21
PLR
R1
21
Inner
label
32
R3
R2 32
54
54
MP
R4
159
172
198
187
R9
Protected LSP:
R1->R2->R3->R4
R2s backup:
R2->R7->R8->R9->R4
3 1 33
R7
R8
Control Plane
(label propagation)
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
Inner
label
R1
Inner
label
32
54
R3
R2 PLR
21
Inner
label
Inner
label
21
X
21
MP
R4
159
172
Inner
label
198
187
Inner
label
172
159
R9
R7
R8
Inner
label
187
Inner
label
198
Protected LSP:
R1->R2->R3->R4
R2s backup:
R2->R7->R8->R9->R4
3 1 34
Control Plane
(label propagation)
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
R10
R3
R2
R1
MP
PLR
R4
R9
R6
R7
Protected LSP 1:
R1->R2->R3->R4
R8
Bypass tunnel
R2->R7->R8->R3
Protected LSP 2:
R10->R2->R3->R4
3 1 35
The facility backup technique uses a different approach. Instead of creating a separate LSP for
every backed-up LSP, a single LSP is created which serves to backup up a number of LSPs. We
call such an LSP tunnel a bypass tunnel. The advantage of this method is the efficient use of
labels in comparison with the One-to-one Backup method.
When such a bypass tunnel is created from a PLR to a downstream MP all the original LSPs using
this partial path are candidates to use this bypass tunnel to protect themselves.
In the above example, R2 has built a bypass tunnel which protects against the failure of link R2R3. The doubled lines represent this tunnel. Both the protected LSPs, regardless of their source
and destination endpoints, can use this bypass tunnel, which provides a scalability improvement.
As with the one-to-one technique, to fully protect an LSP that traverses N nodes, there could be
as many as (N-1) bypass tunnels. However, each of those bypass tunnels could protect a set of
LSPs.

FRR: Facility Backup Link Protection Label Exchange
Works
Worksthe
thesame
sameas
asOne-to-One
One-to-OneBackup
Backupunder
undernormal
normaloperating
operatingconditions
conditions
Inner
label
PLR
21
R2
21
Inner
label
Inner
label
32
R3
32
MP
54
54
R1
R4
172
138
Protected LSP:
R1->R2->R3->R4
R2s backup:
R2->R7->R8->R3
3 1 36
R7 187
R8
Control Plane
(label propagation)
The data plane functions the same way in the stable LSP scenario as it did during the One-toOne backup method. The control plane prepares a bypass tunnel by signaling available labels
from the MP to the PLR as a response to the PLRs RSVP-TE DoD request.

FRR: Facility Backup Link Failure
MP
MPreceives
receivessame
samelabel
labelfrom
frombackup
backuplink
linkas
asititwould
wouldfrom
fromPrimary
PrimaryLSP
LSP
Inner
label
21
21
Inner
label
32
PLR 32
R2
R1
R3
Protected LSP:
R1->R2->R3->R4
R2s backup:
R2->R7->R8->R3
3 1 37
54
54
R4
172
Inner
label
Inner
label
MP
Inner
label
32 172
32 138
138
R7 187
Inner
label
R8
32 187
Control Plane
(label propagation)
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
3 1 38

41
Section 4.1
Services Overview

Section 4 Modue 1 Page 1
Objectives
Upon successful completion of this module, you will be able to
describe:
Service components

412
Service Access Points (SAP)

Service Distribution Paths (SDP)
Service tunnels and labels
MTU considerations

Services Service Configuration Model
413

Service Configuration Model

To provision a service, the following must be defined:

Customer
100
Customer
Service Type
Service Access Point (SAP) A Services logical entry/exit point
Service Distribution Point (SDP) A unidirectional connection between
services distributed across an MPLS network
SAP
Label Switched Path
SDP 3
SAP
Demux
Service 50
Customer
100
Service 50
Label Switched Path
Demux
Tunnels are unidirectional

and are paired to provide a
bi-directional service
SAP is the
customer point of access
414
SDP 3
SDP binds multiple

services to a tunnel
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

Ethertype for some Protocol
common Protocols
0x0800
Internet Protocol, Version 4 (IPv4)
0x0806
Address Resolution Protocol (ARP)
0x8100
VLAN Tagging (Dot1Q)
0x9100
VLAN Tagging (QinQ)
0x86DD
IPv6
0x8847
MPLS unicast
0x88a8
Provider Bridging
For example Etype 8447 identifies this packet as Unicast MPLS

0
DA
SA
0x8847
MPLS
Label
VC
Label
Payload FCS
Ethertype MPLS (8847)
1536
Etype
415
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
Egress and ingress VC labels
uniquely identifies the service
DA
DA
SA
0x0800
SA
MPLS
Label
0x8847
VC
Label
DA
SA
0x0800
payload
payload
DA
SA
SAP
payload
SAP
SDP 3
Label Switched Path
Demux
Service 50
Service 50
Demux
416
0x0800
Label Switched Path
SDP 3
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
417
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
Creating
config>service>sdp sdp-id [gre

| mpls]
description descriptionstring
far-end ip-addr
keep-alive
ldp (only for MPLS SDPs)
lsp lsp-name [lsp-name]
(only for MPLS SDPs)
signaling {off|tldp}
no shutdown
418
an SDP for MPLS (RSVP-TE)
config>service# sdp 8 mpls create

config>service>sdp# far-end 10.10.10.104
config>service>sdp# lsp "to-104"
config>service>sdp# no shutdown
Creating
an SDP with MPLS LDP

config>service>sdp# 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
config>service>sdp#
config>service>sdp#
config>service>sdp#
2 gre create
description to-GRE-10.10.10.104
far-end 10.10.10.104
no shutdown
Creating an SDP for MPLS (RSVP-TE)

config>service>sdp# 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

Services Summary: SAP to SDP
Create
an SDP
MPLS
Create a
Pseudowire
Service
Customer
GRE
Apipe
Cpipe
Assign a
Spoke-SDP
Epipe
Ipipe
ATM
VCC VPC
CESoPSN SAToP
IMA
TDM
Ethernet
IP
E1 CAS
VCC VPC
E1
DS1
Null dot1q Ethernet PPP/MLPPP
CAS Channelized Unchannelized
419
Assign a
SAP

Null dot1q
IPCP
Maximum Transfer Unit (MTU) Considerations
Port MTU: Determines maximum packet size on a given physical wire.

Service MTU: Associated with a service and determines the maximum packet size
that can be sent from the customer across the service.
SDP Path MTU: This is the MTU of the SDP between the service endpoints;
determines the maximum packet size that can be sent over the SDP.
VC-MTU: Negotiated by T-LDP; the maximum IP payload size that can be carried
inside the tunnel. Derived from Service MTU.
IP-MTU: Used by IES and VPRN interfaces for spoke-SDP terminations; should be
equal to the VC-MTU of the spoked Epipe/VPLS.
First 4 MTU values are important to get Services in the Operational UP state
4 1 10
All 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)
Optional (Null/dot1Q/QinQ)
(will be stripped)
No fragmentation possible
DA
DA
payload
FCS
Access Port MTU
Ether
Type
SA
Ether
802.1q
Type
SA
payload
FCS
Service MTU
Network
Interface
Port
MTU
(*)
DA
SA
VC-MTU
SDP
Path MTU
Ether Path
VC
Type Label Label
DA
Service MTU
SA
Ether
Type
payload
FCS
SDP Path MTU

Network Port MTU
4 1 11
Access
Interface
Port
MTU
* If the network interface is
dot1q encapsulated,
an extra 4 bytes is needed for
the q-tag.
The Physical MTU on an Ethernet access interface needs to be set to at least:

1514 with mode-access and encap-type null

1518 with mode-access and encap-type dot1q

1500 + 14 Ethernet Frame header
1500 + 14 Ethernet Frame header + 4 dot1q tag
1522 with mode-access and encap-type qinq

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

Maximum Transfer Unit (MTU) Example
SAP 1/1/1:100
Encap dot1q
Network
2/1/1
Network
3/1/1
Node A
SAP 4/1/1
Encap - Null
Node B
MTU Configuration Example Values

Node A
Access (SAP)
Port (slot/MDA/port) 1/1/1:100
Mode type
dot1q
MTU
1518
4 1 12
Network
2/1/1
network
1536
Node B
Network
3/1/1
network
1536
Access (SAP)
4/1/1
null
1514
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
4 1 13

4 1 14

42
Section 4
Services
Module 2
ePipe

Objectives
422
Services ePipe
Upon successful completion of this module, the student will
understand:
Characteristics of an ePipe service
Steps in configuring an ePipe service
ePipe service management tasks
OAM tools SDP-Ping, SDP-MTU, VCCV Ping and Service Ping


VPWS (Virtual Pseudowire Service) - ePipe Service

423
Services ePipe
An VPWS service provides a point to

point connection between two nodes.
Also referred to as a Virtual Leased Line
(VLL)
From the customers perspective it
operates as a leased line between the
two locations.
The Service provider can apply billing,
ingress/egress shaping and policing
For ePipe, no MAC learning required
ePipe Service
PE C
PE A
IP / MPLS
Network
PE B
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

424
Services ePipe
Customer
access
ports
PE-B
SDP
Customer
access
ports
SAP
Service-id
Service-id
SAP
SDP
PE-A
CORE
Service-id:
ePipe
Customer (subscriber) Association
Service Access Point
Select
Select
Select
Select
Select
Service Distribution Path
Binds a service to an SDP
node and port

Accounting Policy (optional)
Ingress/Egress QOS Policies (optional)
scheduler policy (optional)
Filter policies (optional)
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

425
Services ePipe
Flooded traffic received on SAPs and spoke SDPs:
Replicated on all other ports within the service (spoke-SDPs and SAPs)
Not replicated on the port it was received on
SAP
ePipe 200
ePipe 200
SDP
SDP
SAP
SAP Floods to everybody

Spoke SDP Floods to everybody
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

426
Services ePipe
Port Type
Encapsulation
Ethernet
NULL
Ethernet
Dot1Q
Ethernet
QinQ
SONET / SDH
IPCP
SONET / SDH
BCP-Null
SONET / SDH TDM
BCP-Dot1Q
SONET / SDH TDM
ATM
SONET / SDH FR
FR
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

427
Services ePipe
Customer
Info.
Configure
Configure aa
Customer
Customer
Bind
Create
Create Service
Service
(Epipe)
(Epipe)
Specify MTU
Specify
Encapsulation type
Configure
Configure
Access
Access Ports
Ports
Bind
Create
Create SAPS
SAPS
Specify transport
tunnels
Create
Create SDPs
SDPs
Bind
Bind
Bind to
to aa SDP
SDP
Virtual
Virtual Circuit
Circuit
(service
(service tunnel)
tunnel)
Bind the service

to the customer
at service
creation time
Assign
Encapsulation
value of the port
Assign VC Label
Manage
Manage Service
Service
Service Topology
View
Properties
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

428
Services ePipe
SAP
SDP Number
VC ID
SAP
SDP 7
SDP 3

SAP
SDP Diagnostics SDP-Ping

429
Services ePipe
SDP-Ping
Tests for uni-directional or round trip connectivity

Performs SDP MTU path tests
Configurable parameters:
Message size (default is 40 bytes)

Timeout (default is 5 seconds)
Interval (default is 1 second)
Number of messages to send (default is 1)
Originating SDP ID
Responding SDP ID (optional)
Forwarding class and in/out-of-profile of the OAM message
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
4 2 10
Services ePipe
Unidirectional - Responding SDP

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

4 2 11
Services ePipe
If not specified, GRE encapsulation packet

with OAM label used.
Uses the configured

remote SDP
encapsulation and label.
Uses the configured

outbound SDP encapsulation and
label.
local sdp
svc-ping
Target node
remote sdp
Service
Try to limit the number of concurrent service tests.

Different services could be using the same SDPs.
SDP-Ping may be more effective test.
No remote
SDP supplied
PE-A
SDP
VC Label B
SAP
Service-id
DEMUX
SVC
SVC
DEMUX
Customer
access
ports
Service-id
SAP
VC Label A
SDP
No local
SDP supplied
PE-B
Customer
access
ports
Parameters
Far-End IP Address
The far end IP address that the service ping packet will be sent to.
DNS-Name
The Domain Name Server (DNS) name of the far end device that the service ping packet will be sent
to.
Service-ID
The service ID of the service being tested.
Local-SDP
Specifies that the SVC-Ping request message should be sent using the same service tunnel
encapsulation labeling as service traffic; IP/GRE or MPLS. If the local-SDP parameter is not used,
the SVC-Ping message is sent using GRE encapsulation with an OAM label.
Remote-SDP
Specifies that the SVC-Ping reply message from the far-end should be sent using the same service
tunnel encapsulation labeling as service traffic. If the remote-SDP parameter is not used, the SVCPing reply message is sent using GRE encapsulation with an OAM label.

4 2 12
Services ePipe
End of Module
Services ePipe

43
Section 4
Services
Module 3
Virtual Private LAN Service (VPLS)

Objectives
432
Services VPLS
Upon successful completion of this module, the student will be able
to explain:

Characteristics and benefits of a VPLS service

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

Populating a Forwarding Database (FDB)

433
Services VPLS
Host A sends a frame to Host C

The switch receives a frame on port 1/1/1
1.
Host As MAC address is learned from the frames Source Address field and is
associated with port 1/1/1
If the Destination Address is not already in the FDB, the switch floods the
frame out all ports except for the source port 1/1/1
3. Host C responds to Host A, and all other devices drop the flooded frame
2.
From Host Cs response frame, the switch associates Host Cs MAC address with
port 1/1/3
FDB Learning MAC Addresses
1/1/1
00-00-5e-00-01-8e
1/1/3
00-e0-b1-83-32-d8
Host C
Host A
DA
SA
payload
Host B

Forwarding Databases Using Tagging

434
Services VPLS
Virtual LANs (VLANs) are used to split a single switch into multiple
virtual switches, each with the ability to service the hosts associated
within that VLAN
As an example Hosts A B C are part of VLAN 3, Host D is part of VLAN 6
1.
The switch receives a frame on port 1/1/1:3 (:3 signifies VLAN 3)

Host As MAC address is learned and is associated with in VLAN 3s FDB
If the Destination Address is not already in the FDB, the switch floods the
frame out all ports associated with VLAN 3
3. Host C responds to Host A, and all other devices drop the flooded frame
2.
From Host Cs response frame, the switch populates Host Cs MAC address in
VLAN 3s FDB
6
3
Host D
Host A
DA
SA
VLAN 3
Host C
payload

Host B
Ethertype
435
Services VPLS
The Ethertype field describes the payload of the ethernet frame

Ethertype for some Protocol
common Protocols
0x0800
Internet Protocol, Version 4 (IPv4)
0x0806
Address Resolution Protocol (ARP)
0x8100
VLAN Tagging (Dot1Q)
0x9100
VLAN Tagging (QinQ)
0x86DD
IPv6
0x8847
MPLS unicast
0x88a8
Provider Bridging
For example Etype 8447 identifies this packet as Unicast MPLS

0
DA
SA
0x8847
MPLS
Label
VC
Label
Payload FCS
Ethertype MPLS (8847)
1536
Etype
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

Ethertype - VLAN
436
Services VPLS
Ethernet port encapsulation type can be configured as one of the
following:
Null Header (Raw Mode), all bits after the type field are treated as data
Dot1q Header (Single tag header), adds an additional 4 byte TAG
QinQ Header (Two tags header), adds two TAGs after Source Address field
Null No Tagging SAP 1/1/1
DA
SA
0x0800
Payload
FCS
1514
Dot1Q One Tag SAP 1/1/1:3
DA
SA
0x8100 Tag 3
Payload
FCS
1518
QinQ Stacked Tags - SAP 1/1/1:X.Y
DA
SA
0x9100 Tag X 0x8100 Tag Y
Payload
FCS
1522
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

Building a Local Virtual Private LAN Service (VPLS) Service

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

a single node:
Change the ports to port mode access
Ethernet mode access
Enable tagging on the ports
Ethernet encap-type dot1q
Create Service Access Points (SAPs) within the VPLS service using the
desired port/tag
VPLS 300

sap 1/1/1:3
sap 1/1/2:3
sap 1/1/3:3
1/1/4:6
VPLS 600
1/1/3:3
sap 1/1/4:6
1/1/1:3
1/1/2:3
Host A
DA
SA
0x8100
Host D
Host C
VLAN 3
payload
Host B
1518
All 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.

How is a VPLS provided over MPLS?

438
Services VPLS
Bridging capable PE routers

connected with a full mesh of MPLS LSP tunnels
Per-Service VC labels
negotiated using draft-Martini
PE B
Unknown/broadcast
traffic replicated in a service domain
MAC learning
over tunnel & access ports
separate FIB per VPLS
PE A
PE C
LSP Full-Mesh
PE D
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.

Packet Format
439
Services VPLS
DA
DA
SA
SA
0x0800
MPLS
Label
0x8847
VC
Label
DA
SA
0x0800
payload
payload
DA
SA
PE
PE
CPE
CPE
IP/MPLS
PE
PE
0x0800
payload
CPE
CPE
POP
POP
The customer frame becomes the payload of the MPLS frame

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.

Flooding Traffic within a VPLS

4 3 10
Services VPLS
SDP
VPLS 300
SDP
SDP
SAP
SDP
SAP
SAP Floods to everybody
VPLS 300
SDP
SDP
SAP
Spoke SDP Floods to everybody
SDP
VPLS 300
SDP
SDP
SAP
Mesh SDP Floods to SAPs and Spoke SDPs only
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
4 3 11
Services VPLS
VC-label Signaling between PEs per VPLS service instance
Each PE initiates a targeted LDP session to the far-end System IP address

LDP protocol is used to communicate the VC label when sending packets for
each service
The VC label must match between PE nodes
PE2
M-3
pe2-1
PE1
pe1-2
PE1->PE2: For Svc-id 101 UseVC-label pe2-1

PE1->PE3: For Svc-id 101 Use VC-label pe3-1
pe3-2
M-1
VPLS
pe2-3
pe3-1

pe1-3
PE3
M-4

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

4 3 12
Services VPLS
MAC 3
1/1/2
MAC
MAC3
Location
Remote
Mapping
Tunnel to PE2
Location
MAC
MAC3
Mapping
1/1/2
Local
PE 2
1/1/2
1/1/1
MAC 1
PE 1
MAC 2
PE 3
1/1/3
MAC
MAC3
MAC 4
Location
Remote
Mapping
Tunnel to PE2
Send a packet from MAC 3 to MAC 1

PE2 learns that MAC 3 is reached on Port 1/1/2
PE2 floods to PE1 with VC-label pe2-1 and PE3 with VC-label pe2-3
PE1 learns that MAC 3 is behind PE2
PE3 learns that MAC 3 is behind PE2
PE3 sends on Port 1/1/2
PE1 sends on Port 1/1/1 & 1/1/3
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

4 3 13
Services VPLS
MAC 3
1/1/2
MAC
MAC3
Location
Local
1/1/2
MAC1
Remote
Tunnel to PE1
Mapping
PE 2
1/1/2
1/1/1
MAC 1
PE 1
MAC 2
PE 3
MAC 4
1/1/3
MAC
MAC3
Location
Remote
Mapping
Tunnel to PE2
MAC1
Local
1/1/1
Reply with a packet from M1 to M3

PE1
PE1
PE1
PE2
PE2
learns M1 is on Port 1/1/1

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

4 3 14
Services VPLS
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

4 3 15
Services VPLS
Creating a Distributed VPLS Service:

Add Service Access Points (SAPs) to the VPLS service on each node
VPLS 300
sap 1/1/1:3
Add Service Distribution Points (SDPs) to the VPLS service on each node
VPLS 300

mesh-sdp 12:300
mesh-sdp 13:300
1/1/1:3
VPLS 300
SDP 21
PE1
SDP 23
PE3
PE2
SDP 12
SDP 32
VPLS 300
VPLS 300
SDP 13
1/1/1:3
SDP 31
1/1/1:3
Host B
Host A
Core Network
Before a service is provisioned the following tasks should be completed:
Build the IP or MPLS core network
Configure routing protocols
Configure MPLS LSPs (if MPLS used)
Construct the core SDP service tunnel mesh for the services
Service Administration

Configure group and user access privileges

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

The 7750 SR supports 100 SDPs per VPLS as of release 6.1 (50 SDPs per VPLS pre R6.1)
Service-id:
VPLS
Customer (subscriber) Association
Service Access Point
Select
Select
Select
Select
Select
Service Distribution Path
Binds a service to an SDP

Can be a Spoke or Mesh SDP
node and port

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

VPLS Configuration Workflow

4 3 16
Services VPLS
Customer
Info.
Configure
Configure aa
Customer
Customer
Bind
Create
Create Service
Service
(VPLS)
(VPLS)
Specify MTU
Specify
Encapsulation type
Configure
Configure
Access
Access Ports
Ports
Bind
Create
Create SAPS
SAPS
Specify transport
tunnels
Create
Create SDPs
SDPs
Bind
Bind
Bind to
to aa SDP
SDP
Virtual
Virtual Circuit
Circuit
(service
(service tunnel)
tunnel)
Bind the service to

the customer at
service creation
time
Assign
Encapsulation value
of the port
Assign VC Label
Specify Mesh-SDPs
Manage
Manage Service
Service
Service Topology
View
Properties

VPLS SAP & SDPs

4 3 17
Services VPLS
SAP
SDP Number
VC ID
.
.
.

4 3 18
Services VPLS
VPLS MAC Diagnostics

The VPLS MAC diagnostics provide the means to test the learning and forwarding functions on a perVPLS-service basis.
It is possible that although tunnels are operational and correctly bound to a service an incorrect
Forwarding Information Base (FIB) table for the service could prevent connectivity and not be
detected using the ping tools (SDP-Ping, LSP-Ping, and SVC-Ping).
MAC Ping
MAC Ping provides an end-to-end test to identify the customer-facing egress port where a customer
MAC address was learned. MAC Ping can also be used with a broadcast MAC address to identify all
egress points of a service for the specified broadcast MAC.
MAC Ping Characteristics

MAC ping packets can be sent through the control plane or the data plane
Packets sent along the data plane follow the same path as data traffic; when they reach
egress node they are not forwarded out a customer-facing port, they are passed to the
management plane for processing
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

4 3 19
Services VPLS
ACTION
RESULT
Mac-Ping Service 1 to destination MAC address B.

PE-A will send a MAC-ping to PE-B (per the FIB).
PE-B has the MAC in its FIB, acknowledges the ping.
Mac-Ping Service 1 to destination D (unknown)

Sends the MAC-ping to all nodes (per the FIB)
No node responds.
Mac-ping service 1 destination FF:FF:FF:FF:FF:FF
All nodes in the service respond.
PE-A
MAC
Address
SDP
PE-B
SAP
Service 1
SERVICE
CORE
SDP
SDP
SDP
Service 1
SAP
Address
B
SDP
MAC
Address
MAC
SAP
SDP
Service 1
PE-C
Mac-traceroute lists the

intermediate nodes between
source and destination
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.

4 3 20
Services VPLS
End of Module
Services VPLS

44
Section 4
Services
Module 4
iPipe

What is IP Pseudowires (IPipe) ?

442
Services iPipe
IPipe is a point-to-point (VPWS) service

Layer 3 IGP/EGP routing protocol that runs over IP can be run over the IPipe
(e.g. OSPF, RIP, BGP)
IS-IS uses Layer 2 for its routing messages and is therefore not supported within an
IPipe
IP connectivity between a CE attached to a point-to-point access circuit

(PPP/IPCP) with routed IPv4 encapsulation and a CE attached to an Ethernet
interface
Example: Interim step during ppp network to ethernet network migration
SDP
SAP
MPLS Network
IP Pseudo-Wires
SDP
SAP
PPP/ML-PPP
IP/Ethernet
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

Why iPipes?
Services iPipe
44
Service Access via n*T1/E1 (e.g.
PPP and ML-PPP) is still very

common
Examples: CE branch equipment

(routers), CDMA base stations
ML-PPP
Carriers want to modernize their
CDMA BTS
transport infrastructure to IP/MPLS

over Ethernet
Central devices e.g. HQ CE routers

and EV-DO RNCs for CDMA have
Ethernet and Gig E connectivity
Branch Office
IP/MPLS
on Metro Ethernet
Ethernet
& GE
IES/VPRN
RNC/BSC
3|
Regional/ HQ
IPipes support Ethernet, MLPPP, Frame Relay, ATM SAPs

Epipe vs. IPipe

444
Services iPipe
Provides
Epipe
ethernet VPWS
Provides
IPipe
IP interworking VPWS
Supports
bridged encapsulation
Supports
routed encapsulation
More network overhead because

ethernet header is transported
Less
Both hosts appear to be the same

ethernet LAN
Both
No
Mac
Mac learning
Easier
to configure
network overhead because

ethernet header is taken out
hosts appear to be on the
same IP subnet or network
learning
Local
& Remote CE IP address

configuration is required
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.

Distributed IPipe
445
Services iPipe
Physical View
IP/MPLS
SR
Logical View
138.120.122.2/29
138.120.122.1/29
RNC

Distributed IPipe
446
Services iPipe
1. The SAR receives the PPP packet on the SAP

2. The SAR encapsulates the IP packet directly into a PW without a
control word
3. The SR receives MPLS packet and removes the PW encapsulation
4. The SR validates the MAC destination address of the received Ethernet
frame
It should match that of the Ethernet SAP
MPLS/PW
PPP/IPCP
IP
IP
Data
Ethernet
Data
IP
Data
IPipe
IP/MPLS
PPP/ML-PPP
SAR
SR
IP/Ethernet
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

447
Services iPipe
Configure
Configure aa
Customer
Customer
Bind
Configure
Configure Access
Access Ports
Ports Bind
(Ethernet,
(Ethernet, PPP
PPP // ML-PPP)
ML-PPP)

Create
Create SAPS
SAPS
Bind the service

to the customer
at service
creation time
Assign
Encapsulation
value of the port
Specify CE IP
Address
Specify MTU
Specify
Encapsulation type
Bind
Create
Create SDPs
SDPs
Create
Create Service
Service
(Ipipe)
(Ipipe)
Bind
Bind to
to aa SDP
SDP
Virtual
Virtual Circuit
Circuit
(service
(service tunnel)
tunnel)

Assign VC Label
Specify CE IP
Address
Specify transport
tunnels
Manage
Manage Service
Service
Service Topology
View
Properties
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

448
Services iPipe
The following steps are required to configure a distributed IPipe
service:

Configure an IPipe Service with Customer ID

Configure a SAP and associate it with the IPipe service
Assign the local IP address to the SAP
Configure a spoke-SDP and associate it with IPipe service
Assign a remote IP address to the spoke-SDP
1.1.1.1
SDP
SAP
IPipe
SDP
SAP
1.1.1.1
1.1.1.2
1.1.1.2
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

449
Services iPipe
SAP
SDP Number
VC ID
SAP
SDP 6
SDP 1

SAP
4 4 10
Services iPipe
End of Module
Services iPipe

4.5
Section 4
Services
Module 5
Internet Enhanced Service (IES)

Module Objectives
Services IES
45
Upon successful completion of this module, the student will be

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

Internet Enhanced Service (IES)

Services IES
Interface

SAP
IP Address
IES Interfaces can be included in the following routing protocol:
1.
Static, RIP, OSPF, ISIS, and BGP

3.
An IES is a routed, layer 3 connectivity service:
2.
45
VPLS can be bound to an IES

IES can terminate spoke-SDPs such as an EPipe, IPipe, or H-VPLS
service
IES 500
OSPF
OSPF
SAP
Interface: Port & IP Address
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.

IES Routed Connectivity Service Example

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

for the core routing instance, there is no need for the concept of
tunneling traffic to a remote router
IES does not require the configuration of any SDPs
IES 500
OSPF
OSPF
SAP
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

IES Configuration Workflow

Services IES
45
Customer
Info.
Configure
Configure aa
Customer
Customer
Bind
Create
Create Service
Service
(IES)
(IES)
Bind the service

to the customer
at service
creation time
Specify MTU
Specify
Encapsulation type
Configure
Configure
Access
Access Ports
Ports
Create
Create Layer
Layer 33
Access
Access Interface
Interface
Bind
Interface Name
Assign IP Address
Port / SAP
Add
Add to
to OSPF
OSPF
Manage
Manage Service
Service

Enable OSPF
Enable Passive
Mode
Service Topology
View
Properties
Internet Enhanced Service.

Services IES
45
End of Module
Services IES

46
Section 4
Services
Module 6
Virtual Private Routed Networks (VPRN)

Objectives
462
Services VPRN

The need for L3 VPNs
L3 VPN : VPRN setup and configuration
Packet Walkthrough

Virtual Private Routed Networks (VPRN): Overview

463
Services VPRN
VRF for Customer 1 VPRN
VRF 1
192.168.1.0/24
Customer 1
192.168.1.0/24
VRF 2
Customer 1
VPN
192.168.2.0/24
Customer 1
Customer 2
VPN
Customer 2
192.168.2.0/24
Customer 2
VRF for Customer 2 VPRN
Challenge :
Duplicate subnets are mixed together in a single PE Routing table
Only the best route is selected in routing table
Large amount of information may be exchanged when routing changes
Solution :
Isolation of different VPN traffic
Connectivity between customer sites
Use of private address spaces in each site
Without the L3 VPN:

Each customer must use a separate IP address range
All customer routes are carried natively in the provider core
Large amount of information may be exchanged when routing changes
With VPRN:
Each PE router maintains a separate logical routing table for each VPRN
This table is referred to as a Virtual Routing and Forwarding Table (VRF)
Contains customer destination routes
May maintain multiple VRFs depending on the number of customers connected
local sites
remote sites
MP-BGP is used to carry the VPN routes

VPN-IPv4
464
Services VPRN
Isolation of overlapping IP addressing schemes is achieved using VPN-
Internet Protocol version 4 (IPv4) address family

The BGP address family VPN-IPv4 is an extension to the BGP protocol
In VPN-IPv4 addressing, a route distinguisher is prefixed to the private IPv4
address uniquely identifying the private IPv4 address, even if that address is
used in another customers network
IPv4
VPN-IPv4
IPv6
Mcast
IPv4
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.

IP-VPN: Route Distinguisher

465
Services VPRN
An identifier called the Route Distinguisher (RD) is added to all IPv4
prefixes in order to be able to represent them as unique entities inside

the BGP RIB
Route Distinguisher
IPv4 Prefix
VPN-IPv4 Prefix
8 bytes
4 bytes
12 bytes
65530 : 10
192.168.1.0/24
65530:10:192.168.1.0/24
ASN
Integer
Type 0 RD Structure:
ASN: Autonomous System # of the VPRN
Integer: Administratively assigned value
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.

IP-VPN: Route Target

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

routes in between the VRFs dispersed over several PEs

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

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

467
Services VPRN
RT is a part of the extended community attributes
RD is part of the route attributes
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.

L3 VPN: VPN Label

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

Associate a label (the VPN label) with a VPN route at the ingress PE
Demux the traffic based on VPN label at egress PE
Distribute the VPN label with VPN Route information (MP-BGP)

MP-BGP Update
(Prefix =65530:20:192.168.1.0
RT = 65530:20
VPN Label = 131068)
Customer 1
192.168.1.0/24
Customer 1
VRF 1
VRF 1
VRF 2
VRF 2
Customer 2
Customer 2
Layer 2
MPLS
Label
VPN
Label
=
131068
IP Data
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.

BGP: Different Routing Information Databases

469
Services VPRN
OSPF
RIP
Static
BGP
Import Policy
(Redistribution)
BGP
Export Policy
BGP
BGP
BGP
RIB-in
RIB
RIB-out
Incoming
BGP Update
Outgoing
BGP Update
Received
and processed
BGP routes
to be used in
routing decisions
Received
BGP Updates
from neighbours
BGP Updates
to be sent
to neighbours
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.

IP-VPN: Routing Information Exchange (Walkthrough)

4 6 10
Services VPRN
PE-1 VRF:
Prefix
NH
Proto
----------------------------------
CE-1 Route Table:

Prefix
NH Proto
---------------------------1.1.10.0/24 IF_x
Local
10.1.1.0/30 IF_CE
Local
1.1.10.0/24 10.1.1.2 RIP
RD = 100:10
eRT = 100:10
VRF 10
MP-BGP Peering
IF_CE
IF_CE
VPRN
Import Policy
VPRN
Export Policy
Route Update
1.1.10.0/24
1.1.10.0/24 1.1.1.1 BGP VPN
iRT = 100:10
VRF 10
IF_x
PE-2 VRF:
Prefix
NH
Proto
----------------------------------
BGP
RIB-i
BGP
RIB
BGP
RIB-O
BGP Update
BGP
RIB-i
BGP
RIB
BGP
RIB-O
PE-2 (2.2.2.2/32)
PE-1 (1.1.1.1/32)
PE-1 BGP RIB-OUT:

Network
NH
VPN Label
--------------------------------------------100:10:1.1.10.0/24 1.1.1.1
(RT = 100:10)
Route Update
131069
PE-2 BGP RIB:

Network
NH
VPN Label
--------------------------------------------100:10:1.1.10.0/24 1.1.1.1
(RT = 100:10)
131069
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.
IP-VPN: VRF Import and Export Methods

4 6 11
Services VPRN
VRF Policies
vrf-target command
vrf-import & vrf-export

commands (policies)
Imports
and exports everything into

and out of a VRF
Provides
a more selective mechanism

in importing and exporting routes into
and out of a VRF
Policies are first created in the policy
configuration context and then applied
to the relevant VPRN service
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

4 6 12
Services VPRN
Enable
Enable BGP
BGP

Customer
Info.
Specify MTU
Specify
Encapsulation type
Configure
Configure aa
Customer
Customer
Bind
Configure
Configure
Access
Access Ports
Ports
Bind
Create
Create Service
Service
(VPRN)
(VPRN)
Create
Create Layer
Layer 33
Access
Interface
Access Interface
Auto-Bind
Auto-Bind to
to an
an
SDP
Virtual
Circuit
SDP Virtual Circuit
Manage
Manage Service
Service
Specify AS & Router

IP address
Create BGP Peers
Specify Route
Distinguisher & Route
Target
Specify SNMP
Community
Interface Name
Assign IP Address
Port / SAP
Auto-Bind SDPs
Service Topology
View
Properties


4 6 13
Services VPRN
End of Module
Services VPRN

4 6 14
Services VPRN

Last But One Page

1
@@PRODUCT
@@COURSENAME

@@COURSENAME - Page 1

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

SAM IP-MPLS Service Provisioning PDF

Uploaded by

Document Information

Original Title

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 PDF

Uploaded by

Copyright:

Available Formats

SAM IP-MPLS Service

All Rights Reserved Alcatel-Lucent 2011

All rights reserved Alcatel-Lucent 2011

All Rights Reserved Alcatel-Lucent 2011

All Rights Reserved Alcatel-Lucent 2011