Junos MPLS Fundamentals Student Guide, Revision V-16.a

Junos MPLS Fundamentals
V-16.a
Student Guide
Worldwide Education Services
1133 Innovation Way

Sunnyvale, CA 94089
USA
408-745-2000
www.juniper.net
Course Number: EDU-JUN-JMF

This document is produced by Juniper Networks, Inc.
This document or any part thereof may not be reproduced or transmitted in any form under penalty of law, without the prior written permission of Juniper Networks Education
Services.
Juniper Networks, Junos, Steel-Belted Radius, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United States and other countries. The
Juniper Networks Logo, the Junos logo, and JunosE are trademarks of Juniper Networks, Inc. All other trademarks, service marks, registered trademarks, or registered service
marks are the property of their respective owners.
Junos MPLS Fundamentals Student Guide, Revision V-16.a
Copyright © 2017 Juniper Networks, Inc. All rights reserved.
Printed in USA.
Revision History:
Revision 15.a—February 2016
Revision V-16.a—February 2017
The information in this document is current as of the date listed above.
The information in this document has been carefully verified and is believed to be accurate for Junos software Release 16.1R3.10. Juniper Networks assumes no
responsibilities for any inaccuracies that may appear in this document. In no event will Juniper Networks be liable for direct, indirect, special, exemplary, incidental, or
consequential damages resulting from any defect or omission in this document, even if advised of the possibility of such damages.
Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice.
YEAR 2000 NOTICE
Juniper Networks hardware and software products do not suffer from Year 2000 problems and hence are Year 2000 compliant. The Junos operating system has no known
time-related limitations through the year 2038. However, the NTP application is known to have some difficulty in the year 2036.
SOFTWARE LICENSE
The terms and conditions for using Juniper Networks software are described in the software license provided with the software, or to the extent applicable, in an agreement
executed between you and Juniper Networks, or Juniper Networks agent. By using Juniper Networks software, you indicate that you understand and agree to be bound by its
license terms and conditions. Generally speaking, the software license restricts the manner in which you are permitted to use the Juniper Networks software, may contain
prohibitions against certain uses, and may state conditions under which the license is automatically terminated. You should consult the software license for further details.
Contents
Chapter 1: Course Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1
Chapter 2: MPLS Fundamentals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

MPLS Foundations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3
Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-18
MPLS Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-30
MPLS Packet Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-39
Lab: MPLS Fundamentals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-50
Chapter 3: Label Distribution Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

Label Distribution Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3
RSVP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7
LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-54
Lab: Label Distribution Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-81
Chapter 4: LSPs and Routing Table Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

Mapping BGP Next Hops to LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3
Route Resolution Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-8
Binding Additional Prefixes to LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-17
Altering the Default Traffic Engineering Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-22
Lab: Routing Table Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-31
Chapter 5: Constrained Shortest Path First . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

RSVP Behavior Without CSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3
CSPF Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7
CSPF Tie Breaking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-21
Administrative Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-27
Inter-Area Traffic Engineered LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-44
Path Computation Element Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-51
Corouted Bidirectional LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-54
Proactive Loss and Delay Measurement over Associated Bidirectional LSPs . . . . . . . . . . . . . . . . 5-57
Lab: CSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-62
Chapter 6: Traffic Protection and LSP Optimization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1

Default Traffic Protection Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3
Primary and Secondary LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-8
Fast Reroute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-20
RSVP Link Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-32
LDP Link Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-40
LSP Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-47
Lab: Traffic Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-57
www.juniper.net Contents • iii

Chapter 7: Fate Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1
Junos OS Fate Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3
SRLG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-8
Extended Admin Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-16
Lab: Fate Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-25
Chapter 8: Miscellaneous MPLS Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1

Forwarding Adjacencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3
Policy Control over LSP Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-6
LSP Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-9
Automatic Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-11
Container LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-15
TTL Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-19
Explicit Null Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-24
MPLS Pings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-26
Lab: Miscellaneous MPLS Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-30
Acronym List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ACR-1
iv • Contents www.juniper.net
Course Overview
This two-day course is designed to provide students with a solid foundation on Multiprotocol Label Switching (MPLS).
After introducing concepts such as MPLS forwarding and the structure of the MPLS header, the course will delve into the
configuration and operation of the two main label distribution protocols, RSVP and LDP. Special emphasis is given to the
central topics of traffic engineering and MPLS traffic protection, including fast reroute, link/node protection, and LDP
loop-free alternate.
The concepts are put into practice with a series of in-depth hands-on labs, which will allow participants to gain
experience in configuring and monitoring MPLS on Junos OS devices. These hands-on labs utilize Juniper Networks
vMX Series devices using the Junos OS Release 16.1R3.10, but are also applicable to other MX Series devices.
Course Level
Junos MPLS Fundamentals (JMF) is an intermediate-level course.
Intended Audience
This course benefits individuals responsible for configuring and monitoring devices running the Junos OS.
Prerequisites
Students should have intermediate-level networking knowledge and be familiar with the Junos OS command-line
interface (CLI). Students should also attend the Introduction to the Junos Operating System (IJOS), Junos Routing
Essentials (JRE), Junos Intermediate Routing (JIR), and Junos Service Provider Switching (JSPX) courses prior to
attending this class.
Objectives
After successfully completing this course, you should be able to:
• Describe the history and rationale for MPLS, as well as its basic terminology.
• Explain the MPLS label operations (push, pop, swap) and the concept of label-switched path (LSP).
• Describe the configuration and verification of MPLS forwarding.
• Describe the functionalities and operation of RSVP and LDP.
• Configure and verify RSVP-signaled and LDP-signaled LSPs.
• Select and configure the appropriate label distribution protocol for a given set of requirements.
• Describe the default Junos OS MPLS traffic engineering behavior.
• Explain the Interior Gateway Protocol (IGP) extensions used to build the Traffic Engineering Database (TED).
• Describe the Constrained Shortest Path First (CSPF) algorithm, its uses, and its path selection process.
• Describe administrative groups and how they can be used to influence path selection.
• Describe the default traffic protection behavior of RSVP-signaled LSPs.
• Explain the use of primary and secondary LSPs.
• Describe the operation and configuration of fast reroute.
• Describe the operation and configuration of link and node protection.
• Describe the operation and configuration of LDP loop-free alternate.
• Describe the LSP optimization options.
• Explain LSP priority and preemption.
• Describe the behavior of fate sharing.
• Describe how Shared Risk Link Groups (SRLG) changes the CSPF algorithm when computing the path of a
secondary LSP.
• Explain how extended admin groups can be used to influence path selection.
• Explain the purpose of several miscellaneous MPLS features.
www.juniper.net Course Overview • v

Course Agenda
Day 1
Chapter 1: Course Introduction
Chapter 2: MPLS Fundamentals
Lab: MPLS Fundamentals
Chapter 3: Label Distribution Protocols
Lab: Label Distribution Protocols
Chapter 4: Routing Table Integration
Lab: Routing Table Integration
Day 2
Chapter 5: Constrained Shortest Path First
Lab: CSPF
Chapter 6: Traffic Protection and LSP Optimization
Lab: Traffic Protection
Chapter 7: Fate Sharing
Lab: Fate Sharing
Chapter 8: Miscellaneous MPLS Features
Lab: Miscellaneous MPLS Features
vi • Course Agenda www.juniper.net

Document Conventions
CLI and GUI Text

Frequently throughout this course, we refer to text that appears in a command-line interface (CLI) or a graphical user
interface (GUI). To make the language of these documents easier to read, we distinguish GUI and CLI text from chapter
text according to the following table.
Style Description Usage Example
Franklin Gothic Normal text. Most of what you read in the Lab Guide
and Student Guide.
Courier New Console text:

commit complete
• Screen captures
• Noncommand-related Exiting configuration mode
syntax
GUI text elements:
Select File > Open, and then click
• Menu names Configuration.conf in the
Filename text box.
• Text field entry
Input Text Versus Output Text

You will also frequently see cases where you must enter input text yourself. Often these instances will be shown in the
context of where you must enter them. We use bold style to distinguish text that is input versus text that is simply
displayed.
Normal CLI No distinguishing variant. Physical interface:fxp0,

Enabled
Normal GUI
View configuration history by clicking
Configuration > History.
CLI Input Text that you must enter. lab@San_Jose> show route
GUI Input Select File > Save, and type
config.ini in the Filename field.
Defined and Undefined Syntax Variables

Finally, this course distinguishes between regular text and syntax variables, and it also distinguishes between syntax
variables where the value is already assigned (defined variables) and syntax variables where you must assign the value
(undefined variables). Note that these styles can be combined with the input style as well.
CLI Variable Text where variable value is already policy my-peers

assigned.
GUI Variable Click my-peers in the dialog.
CLI Undefined Text where the variable’s value is Type set policy policy-name.
the user’s discretion or text where
ping 10.0.x.y
the variable’s value as shown in
GUI Undefined the lab guide might differ from the Select File > Save, and type
value the user must input filename in the Filename field.
according to the lab topology.
www.juniper.net Document Conventions • vii

Additional Information
Education Services Offerings

You can obtain information on the latest Education Services offerings, course dates, and class locations from the World
Wide Web by pointing your Web browser to: http://www.juniper.net/training/education/.
About This Publication
The Junos MPLS Fundamentals Student Guide was developed and tested using Junos software Release 16.1R3.10.
Previous and later versions of software might behave differently so you should always consult the documentation and
release notes for the version of code you are running before reporting errors.
This document is written and maintained by the Juniper Networks Education Services development team. Please send
questions and suggestions for improvement to training@juniper.net.
Technical Publications
You can print technical manuals and release notes directly from the Internet in a variety of formats:
• Go to http://www.juniper.net/techpubs/.
• Locate the specific software or hardware release and title you need, and choose the format in which you
want to view or print the document.
Documentation sets and CDs are available through your local Juniper Networks sales office or account representative.
Juniper Networks Support
For technical support, contact Juniper Networks at http://www.juniper.net/customers/support/, or at 1-888-314-JTAC
(within the United States) or 408-745-2121 (outside the United States).
viii • Additional Information www.juniper.net

Chapter 1: Course Introduction

We Will Discuss:
• Objectives and course content information;
• Additional Juniper Networks, Inc. courses; and
• The Juniper Networks Certification Program.
Chapter 1–2 • Course Introduction www.juniper.net

Introductions
The slide asks several questions for you to answer during class introductions.
www.juniper.net Course Introduction • Chapter 1–3

Course Contents
The slide lists the topics we discuss in this course.

Prerequisites
The slide lists the prerequisites for this course.

General Course Administration

The slide documents general aspects of classroom administration.

Training and Study Materials

The slide describes Education Services materials that are available for reference both in the classroom and online.

Additional Resources
The slide provides links to additional resources available to assist you in the installation, configuration, and operation of
Juniper Networks products.

Satisfaction Feedback
Juniper Networks uses an electronic survey system to collect and analyze your comments and feedback. Depending on the
class you are taking, please complete the survey at the end of the class, or be sure to look for an e-mail about two weeks
from class completion that directs you to complete an online survey form. (Be sure to provide us with your current e-mail
address.)
Submitting your feedback entitles you to a certificate of class completion. We thank you in advance for taking the time to
help us improve our educational offerings.

Juniper Networks Education Services Curriculum

Juniper Networks Education Services can help ensure that you have the knowledge and skills to deploy and maintain
cost-effective, high-performance networks for both enterprise and service provider environments. We have expert training
staff with deep technical and industry knowledge, providing you with instructor-led hands-on courses in the classroom and
online, as well as convenient, self-paced eLearning courses. In addition to the courses shown on the slide, Education
Services offers training in automation, E-Series, firewall/VPN, IDP, network design, QFabric, support, and wireless LAN.
Courses
Juniper Networks courses are available in the following formats:
• Classroom-based instructor-led technical courses
• Online instructor-led technical courses
• Hardware installation eLearning courses as well as technical eLearning courses
• Learning bytes: Short, topic-specific, video-based lessons covering Juniper products and technologies
Find the latest Education Services offerings covering a wide range of platforms at
http://www.juniper.net/training/technical_education/.

Juniper Networks Certification Program

A Juniper Networks certification is the benchmark of skills and competence on Juniper Networks technologies.

Juniper Networks Certification Program Overview

The Juniper Networks Certification Program (JNCP) consists of platform-specific, multitiered tracks that enable participants
to demonstrate competence with Juniper Networks technology through a combination of written proficiency exams and
hands-on configuration and troubleshooting exams. Successful candidates demonstrate a thorough understanding of
Internet and security technologies and Juniper Networks platform configuration and troubleshooting skills.
The JNCP offers the following features:
• Multiple tracks;
• Multiple certification levels;
• Written proficiency exams; and
• Hands-on configuration and troubleshooting exams.
Each JNCP track has one to four certification levels—Associate-level, Specialist-level, Professional-level, and Expert-level. The
Associate-level, Specialist-level, and Professional-level exams are computer-based exams composed of multiple choice
questions administered at Pearson VUE testing centers worldwide.
Expert-level exams are composed of hands-on lab exercises administered at select Juniper Networks testing centers. Please
visit the JNCP website at http://www.juniper.net/certification for detailed exam information, exam pricing, and exam
registration.

Preparing and Studying

The slide lists some options for those interested in preparing for Juniper Networks certification.

Junos Genius
The Junos Genius application takes certification exam preparation to a new level. With Junos Genius you can practice for
your exam with flashcards, simulate a live exam in a timed challenge, and even build a virtual network with device
achievements earned by challenging Juniper instructors. Download the app now and Unlock your Genius today!

Find Us Online
The slide lists some online resources to learn and share information about Juniper Networks.

Any Questions?
If you have any questions or concerns about the class you are attending, we suggest that you voice them now so that your
instructor can best address your needs during class.

Chapter 2: MPLS Fundamentals

We Will Discuss:
• The need for traffic engineering and the role of MPLS;
• Common terms relating to MPLS;
• Packet flow and handling through a label-switched path (LSP);
• Configuration and verification of MPLS forwarding; and
• Understanding the information in the Label Information Base (LIB).
Chapter 2–2 • MPLS Fundamentals www.juniper.net

MPLS Foundations
The slide lists the topics we will discuss. We discuss the highlighted topic first.
www.juniper.net MPLS Fundamentals • Chapter 2–3

MPLS Foundations
The main ideas that led to MPLS were developed in the mid ‘90s as an answer to a number of perceived concerns, the most
prominent of which were:
• The scalability of the IP control plane: the technology at the time was thought to be unable to cope with the
growth of interfaces speed and the explosion of the global routing table; the operation of selecting “the best
route” over a table which was predicted to reach hundred of thousands of entries was simply not feasible with
the technology of the time, which revolved around ordinary CPU-based routers.
• The necessity of integrating with (and eventually replacing) contemporary layer-2 technologies like ATM and
Frame Relay, collapsing them into a single, versatile infrastructure.
• The need of fine-grained traffic engineering capabilities, much more accurate than any approach based on
conventional IP routing.
Over the years, advances in ASIC technology and the disappearance of legacy layer-2 technologies made the first two
concerns irrelevant.
But the need of traffic engineering came to be the first “killer application” of MPLS, causing its wide deployment in most (if
not all) major service-provider networks, already strained by the incredible traffic growth at the end of the 1990s. After that,
several other applications were developed to take full advantage of the new forwarding capabilities that MPLS offered.

Service Providers and IGP Metrics

Since the early days of the Internet, service providers have been using IGP metrics to try and maximize network utilization
and minimize congestion.
IGP metrics were initially derived from interface speeds. This caused traffic to avoid lower-capacity links, and favor
higher-capacity ones. This approach was working when the network topology was simple (i.e. not many nodes, and not many
links between them), but quickly started to show its limitations.
As networks became bigger and more interconnected, the metrics-based approach proved to be less and less feasible, and
more problematic from an operational point of view. The decision of changing the metric value of a link would typically cause
huge shifts in traffic and, with them, big changes in utilization.
Moreover, there is a whole range of forwarding behaviors that simply cannot be achieved with metrics alone, no matter how
carefully adjusted they were.

IGP Metrics Give Network Operators Very Little Control

The main limitation of IGP metrics as a traffic engineering tool is their all-or-nothing approach; even when several alternative
paths exist between two routers, IGPs will only chose the one with lowest metric, and, if several paths share the lowest metric
value, load-balance traffic, spreading it between the equal-cost paths. All other feasible paths are not used at all, no matter
how much free capacity they could potentially provide.
IGP Metrics Lack Optimization Capabilities

In addition to this, IGP metrics do not allow to map different services to different paths between two endpoints. This is
especially useful when the different paths consist of links with very different characteristics; for example a high-delay,
high-throughput satellite link could be used for non-real-time services, saving the expensive fiber capacity for real-time
traffic. But ordinary destination-based IP routing do not allow this level of control on forwarding behavior.

Core Limitations of IGP Metrics

Even in a simple topology, there is a variety of problems that simply cannot be solved with IGP metrics manipulations and
destination-based routing.
In the diagram, the desired behavior is to route traffic between R1 and R6 via R3, and the traffic between R1 and R7 via R4.
But there is no way of meeting these requirements by manipulating IGP metrics: all traffic between R2 and R5 will be treated
equally, no matter if the destination is R6 or R5.
In a nutshell, if the only tool you have at your disposal is manipulating the IGP metrics, there are only three possible network
behaviors that you can obtain:
• All traffic takes the path via R3
• All traffic takes the path via R4
• Traffic is load-balanced across the two paths
This may not seem very limiting, but if, for example, the links on the path R2-R4-R5-R7 have lower capacity than the links
R2-R3-R5, you cannot load-balance traffic as you would risk congestion on the lower-capacity links. This forces you to use
only the higher-capacity links, wasting the capacity offered by the lower-speed links.
This is just a simple example of the type of problems service providers used to face at the end of the 1990s, with
ever-growing traffic levels driven by the ubiquitous diffusion of the Internet.

The MPLS Solution

To solve the traffic engineering problem and to address routing scalability concerns, MPLS offers a simple yet very powerful
solution:
• Prepend to each packet entering the domain a small, fixed-length header with a 24-bit numerical value, called
label
• Forward the packet within the domain only according to the label value, removing the need of doing a costly
route lookup at every hop
The possibility of setting up arbitrary label-switched paths (LSPs) across the domain makes it possible to do “true” traffic
engineering.
Moreover, while with IP routing every hop is forced to do a complex route lookup over a huge global routing table, a
label-switching router can take a forwarding decision by looking for an exact match in a much smaller table. The table size
depends on the number of label-switched paths crossing the router, i.e. the number of exit points within the domain. This is
easily several orders of magnitude smaller than the size of the global routing table.
Finally, since label-switching routers take forwarding decisions only according to the label value, it becomes possible to
transport arbitrary frames across a MPLS domain, not just IP packets: this soon led to the development of a whole range of
new and very profitable MPLS applications.

Other MPLS Applications

The widespread adoption of MPLS, mainly due to the need of traffic engineering, soon led to the development of several
other applications. Among the most successful ones are:
• The transport of Layer-2 frames across an MPLS-enabled backbone.
The need to “migrate away” from obsolete networking protocols as ATM and Frame Relay gave rise to several
technologies, from the creation of simple point-to-point layer-2 connections, to extremely sophisticated and
powerful layer-2 transport mechanisms (EVPN) which today have a very prominent role, driven by the rise of
virtualization and the need for data center interconnection.
• The creation of Virtual Private Networks, each dedicated to a customer, on the same MPLS infrastructure.
What started out as a simple way of providing private IP connectivity on a shared backbone (Layer-3 VPN,
RFC4364) has now evolved to provide services as diverse as private IPv6 connectivity (6VPE) and private
multicast distribution (MVPN). Many service providers offer MPLS-based Layer-3 VPN services, as this turned
out to be both very profitable and very convenient for large customers.
Some MPLS applications fall within multiple categories. For example Layer-2 VPNs, VPLS and EVPNs are both a Layer-2
transport technology and a VPN technology.
Continued on the next page.

Other MPLS Applications (contd.)
• The distribution of multicast over a point-to-multipoint labels-switched path.
The possibility of using MPLS as a multicast technology, removing the need of protocols such as PIM and
providing much better traffic protection features, enabled the deployment of large-scale use IPTV distribution
systems.
There is little doubt that in the future many more MPLS applications will be developed for use in enterprises, data centers
and service provider networks.

The MPLS Header, Part 1

The 32-bit MPLS header, sometimes called MPLS shim header, is prepended to each packet as it enters the MPLS domain,
and is typically removed at the end of the label-switched path, as the packet is delivered to its destination.
Sometimes the term MPLS label is used to mean the whole MPLS header, but strictly speaking the label is just one of its
fields. Still, there is not much ambiguity, and expressions like “adding a label” or “removing a label” always mean adding and
removing a whole 32-bit MPLS header.
Once traffic reaches the end of a label-switched path, forwarding can continue according to the actual payload. For example,
in case of IP traffic engineering, forwarding will continue with ordinary destination-based IP routing.

The MPLS Header, Part 2

The MPLS shim header is composed of four fields:
• 20-bit label: Identifies the packet as belonging to a particular LSP. This value changes as the packet flows on
the LSP from LSR to LSR.
• Traffic Class (TC): Formerly called EXP (experimental), these three bits can be used to convey class-of-service
information, specifically the forwarding class a given packet belongs to. The 3-bit width of this field makes it
possible to give a frame a total of eight possible markings, each of them potentially linked to a different
forwarding behavior, for example a different queuing priority and a different buffer size.
• Bottom-of-stack bit: many MPLS applications require a packet to be tagged with several labels, one stacked on
top of the other.
The bottom-of-stack bit of a MPLS header is set to 1 if this is the bottom of the label stack, and below is the
payload. The bottom-of-stack bit is set to zero instead if below the header lays another MPLS header (i.e.
another label).
Among the applications which require label stacking are for example VPNs. Here the outer label, or transport
label, indicates which label-switching router traffic should be delivered to. The inner label, called service label,
describes instead how the payload should be treated once it reaches its destination label-switching router.

The MPLS Header: Part 2 (contd.)
• Time to live (TTL): As in the case for the equivalent IP field, TTL limits the number of hops a MPLS packet can
travel. It is decremented at each hop, and if its value drops to zero, the packet is discarded. When using MPLS
for IP traffic engineering, the default behavior is to copy the value of the IP TTL field into the MPLS TTL field. This
allows diagnostic tools like traceroute to continue working even when packets are encapsulated within MPLS
and sent down a label-switched path.

Labels Have Only Local Significance

A very important point to keep in mind is that labels have only local significance: they are assigned by each router according
to its own label availability. In other words, you can establish a label-switched path across a domain, between two endpoints,
and traffic following the path will typically be tagged with a different label at each hop.
A second important point is that generally labels are global to the router, and not tied to the incoming interface; a packet
tagged with a given label will be subject to the same forwarding treatment regardless from the interface it has been received
on. This apparently minor point will play a major role in MPLS traffic protection - a set of MPLS features that try and minimize
packet loss during a link or a node failure.
There are only very few exceptions to this rule, mostly to do with specific (and very advanced) MPLS applications. One
example is carrier-of-carriers, where a MPLS-enabled service provider offers a MPLS transport service to other service
providers.

Reserved MPLS Label Values

Labels 0 through 15 are reserved (RFC 3032, MPLS Label Stack Encoding).
• A value of 0 represents the IP version 4 (IPv4) explicit null label. This label indicates that the label must be
popped, and the forwarding of the packet must then be based on what is below it, either another label or the
payload.
• A value of 1 represents the router alert label. This label value is legal anywhere in the label stack except at the
bottom. When a received packet contains this label value at the top of the label stack, it is delivered to a local
software module for processing. The label beneath it in the stack determines the actual forwarding of the
packet. However, if the packet is forwarded further, the router alert label should be pushed back onto the label
stack before forwarding. The use of this label is analogous to the use of the router alert option in IP packets.
• A value of 2 represents the IP version 6 (IPv6) explicit null label. This label value is legal only when it is the sole
label stack entry. It indicates that the label stack must be popped, and the forwarding of the packet then must
be based on the IPv6 header.
• A value of 3 represents the implicit null label. This is a label that a LSR can assign and distribute, but it never
actually appears in the encapsulation. When an LSR would otherwise replace the label at the top of the stack with
a new label, but the new label is implicit null, the LSR pops the stack instead of doing the replacement. Although
this value can never appear in the encapsulation, it can be specified by a label signaling protocol.

Reserved MPLS Label Values (contd.)
• A value of 7 is used for the Entropy Label Indicator (ELI). After determining a load balancing methodology, the ELI
allows the ingress LSR to notify the downstream LSRs of the chosen load balancing methodology.
• A value of 13 is used for Generic Associated Channel Label (GAL). This label informs an LSR that a received LSP
belongs to a Virtual Circuit Connectivity Verification (VCCV) control channel.
• A value of 14 is used as the OAM Alert Label. This label indicates that a packet is an MPLS OAM packet as
described in ITU-T Recommendation Y.1711.
• Values 4–6, 8-12, and 15 are reserved for future use.

Implicit and Explicit Null Labels

Two labels deserve special attention: Label 0 and Label 3. These two labels can only be used at the end of an LSP, between
the penultimate (that is, second-to-last) and the egress router.
• Label 0 (Explicit null): This label is always assigned an action of “decapsulate” (pop); the label-switching router
will just remove the MPLS header, and take a forwarding action based on what is below it (either another label,
or the actual LSP payload).
• Label 3 (Implicit Null): This is a special label value that is never actually found in MPLS frames, but only within
MPLS signaling protocols. It is used by the egress router, i.e. the last hop in a label-switched path, to request the
previous router to remove the MPLS header. This behavior, referred to as penultimate-hop popping, is the
Junos OS default.

Terminology
The slide highlights the topic we discuss next.

Label-Switching Router
The original definition of label-switching router is “a router that takes forwarding decisions based only on the content of the
MPLS header”. In other words, a label-switching router always operates in label-switching mode. We will use a definition
which is slightly less restrictive, to include also ingress and egress routers, sometimes referred to as label edge routers.
Traffic at the ingress or at the egress of a label-switched path is typically not encapsulated into MPLS, so label-switching is
not possible, and a forwarding decision needs to be taken according to other rules.
We will use the term label-switching router (LSR) to mean any router which participates in MPLS forwarding, including both
the ingress and the egress nodes. For brevity, in the rest of the course we will also use the term router as synonym for
label-switching router.

MPLS Label Operations

The forwarding behavior of a label-switching router is defined according to three basic label operations:
• Push: add a MPLS header (a label) to a packet.
This operation is typically done by the label-switching router at the beginning of a label-switched path, to
encapsulate a non-MPLS packet and allow it to be forwarded by label switching within the MPLS domain.
• Pop: remove a MPLS header from a MPLS-encapsulated packet.
This is often done either at the end of an LSP or, as we will see shortly, by the second-to-last router (the
penultimate hop).
• Swap: replace the label value of a MPLS packet with another value.
This operation is typically performed by transit label-switching routers, as a packet traverses a label-switched
path.
After performing one of these MPLS basic operations, the packet is generally forwarded to the next-hop router.
In some cases the forwarding treatment can be more complex, involving different combinations of the three basic
operations. For some types of services, for example for VPNs, it is common to see a double-push forwarding action; while in
some traffic protection scenarios, when building a local detour to avoid a link failure, sometimes a transit router will have to
perform a swap-push operation.

Label-Switched Path
A label-switched path (LSP) is a unidirectional path through the network defined in terms of label switching operations (push,
pop, swap). You can think of a LSP as a tunnel: any packet that enters it is delivered to its endpoint, no matter what type of
payload it contains.
Establishing a label-switched path across a MPLS domain means determining the actual labels and label operations
performed by the label-switching routers on the path. This can be done with manual configuration, or by some type of
dynamic label distribution protocol.
Often a label-switched path will reside within a single MPLS domain, for example within a single service provider. However,
the development of advanced BGP-based MPLS signaling allows the creation of label-switched paths that span multiple
domains and multiple administrations.

Ingress Label Switching Router

The ingress router, sometimes called head end, is typically performing a label operation of push, inserting the MPLS header
between the layer-2 encapsulation and the payload packet. Its role is encapsulating non-MPLS traffic by adding one or more
labels to it, and forwarding it down a label-switched path.
The ingress router is not a pure label-switching router: the initial decision of which traffic to forward down which LSP is taken
not according to the content of labels (which are not present yet), but according to other criteria, e.g. a route lookup for IP
MPLS traffic engineering, or even the incoming interface, in case of point-to-point transport of layer-2 frames over MPLS
(layer-2 circuits, circuit-cross-connect).

Transit Label Switching Routers

The transit label-switching routers are LSRs that are neither at the beginning nor at the end of a label-switched path. They
typically operate in pure label switching mode, taking forwarding decisions only based on the label value of incoming MPLS
frames.
Very often transit LSRs will perform a swap operation, replacing the incoming label with the one expected by the next-hop of
the label-switched path. Transit LSRs are typically not aware of the content of the MPLS traffic they are forwarding, and do
not know if the payload is IP, IPv6, layer-2 frames or anything else.

The Label Information Base

The Label Information Base contains the actual MPLS label switching table which associates incoming MPLS labels to
forwarding actions, typically a label operation of either swap or pop and a forwarding next-hop.
Even if the label information base can be populated by static entries, generally this is done by a dynamic label distribution
protocol.

Penultimate-Hop Popping
Often the MPLS header is removed by the second-to-last (the penultimate) router in an LSP. This removal is an optimization
that helps in several cases, including using MPLS for IP traffic engineering. Removing the label at the penultimate hop
facilitates the work of the last-hop (egress) router, which, instead of having both to remove the MPLS header and then take
an IP routing decision, will only need to do the latter.
Penultimate-hop popping (PHP) is the default behavior on Juniper routers; however, it can be disabled in the configuration.
Some applications require PHP to be disabled, but that is often done automatically: the Junos OS is smart enough to detect
the need to signal the LSP so that PHP is disabled.

Egress Label Switching Router

The egress router (or tail end) of a LSP is the last router in the label-switched path. Exactly as in the case of the ingress LSR,
it is generally not a pure label-switching router, as it has to take a forwarding decision based on other factors than the
incoming label.
In case of MPLS IP traffic engineering, the egress router will be delivered ordinary IP packets due to penultimate-hop
popping, and will take a forwarding decision based on ordinary IP routing.

When Must Penultimate-Hop Popping Be Disabled?

With penultimate-hop popping, the MPLS header is removed at the second-to-last hop, and is not available to the egress
router. In particular, two important fields will be missing: the label value itself and the TC bits.
This disablement can create problems in two types of applications:
• Class of service applications that use the TC bits to mark packets as belonging to different forwarding classes,
for example for real-time and non-real-time traffic. If the TC bits are lost, the egress router will not be able to
recognize which packet belongs to which forwarding class, and prioritize traffic correctly.
• Applications that need to preserve the “identity” of a LSP even at the last hop; some examples are the
distribution of multicast traffic in a VPN environment, and circuit-cross-connect (CCC), an early technology to
transport layer-2 frames over MPLS.

Label Information Base

On routers running the Junos OS, the label information base is stored into the mpls.0 table.
As soon as you enable MPLS processing, four default entries are automatically created: they are for label 0 (explicit null),
label 1 (router alert), label 2 (ipv6 explicit null) and label 13 (Generic Associated Label, used for Operation and Maintenance
and defined in RFC5586).

Label to Forwarding Action Mappings

On top of the pre-defined four labels, the mpls.0 table can be populated by static configuration or, much more frequently, by
dynamic label distribution protocols.
Each label is associated with a forwarding action, typically composed of a MPLS label operation (push, pop, swap or a
combination of these) and a next-hop. In this example, label 300576 has been installed by a dynamic protocol called LDP,
while the remaining label, 1004792, has been configured statically.
Note that there are two entries for this last label. This is because, in some cases, a label-switching router may have to take
different forwarding actions according to whether the label is or is not at the bottom of the label stack. In this case, the
forwarding actions turn out to be the same: pop the MPLS header and sent the content to 172.17.23.1 via interface ge-1/1/
5.0. The IP address of the next hop needs of course to be directly connected: it is only use to derive which MAC address to
use for layer-2 encapsulation.

MPLS Configuration

Interface Configuration
To enable MPLS on an interface, you will first need to configure family mpls at the logical unit level. This allows an
interface to receive and process MPLS frames.

Protocol Configuration
After enabling MPLS frame processing at the interface level, you will need to list the interfaces running MPLS at the [edit
protocol mpls] level.
Historically, this was needed to inform the routing protocol process (RPD) about which interfaces could be used for MPLS
signaling. Enabling family mpls on interfaces would instead cause the microcode for MPLS de-capsulation to be
uploaded to line cards. While more modern platforms may work differently, this syntax remained. In order to use MPLS you
need both to configure interfaces for family mpls, and to enumerate the interfaces again at the [edit protocols
mpls] level.
In a lab scenario, you can also use the shortcut interface all, which enables MPLS on every interface on which
family mpls is configured. In a realistic configuration this is almost never done, as typically there are several other
properties and configuration knobs that need to be enabled on a per-interface basis.

MPLS Interface Verification

A useful command to verify the correct configuration of MPLS interfaces is show mpls interface. If an interface is
missing from the command output, it probably means that either family mpls has not been configured at the logical unit
level, or the interface has not been correctly listed at the [edit protocols mpls] level. This often happens when you
use the wrong logical unit.

Configuring Static LSPs: Preliminary Information

• Naming: each LSP should be given a unique name, and the name should be kept consistent on all routers in the
path.
Even if the actual LSP name is typically only used at the ingress (for example, in policies or as next-hop for static
routes), keeping it consistent will make troubleshooting and management much easier.
• Label values: The label range reserved for static LSPs is between 1000000 and 1048575. Static LSPs on
transit routers can only accept incoming labels in this range. The remaining label space is used by dynamic
label distribution protocols.
Label 0 (explicit null) is also allowed at the penultimate hop, if the design requires it. This is useful if TC bits are
being used to convey Class of Service information.

Configuring Static LSPs on the Ingress Router

Configure a router as an ingress node is very straightforward: for each LSP, specify the name and the forwarding action, that
is which label to push, and where to send the resulting MPLS frame.
In addition to this, you will need to specify the MPLS egress point via the to statement. This will be installed into the inet.3
table, and may be used by different MPLS applications as BGP traffic engineering, Layer-3 VPNs and so on.
We will examine how the inet.3 table is used later on, when discussing BGP MPLS traffic engineering.

Configuring Static LSPs on a Transit Router

To configure a router as the transit node for a LSP, specify the incoming label and the forwarding action — that is, MPLS label
operation and forwarding next-hop.
The forwarding action will generally be a swap, except on the penultimate hop; there, it can be either a swap with label 0
(Explicit Null) or, when doing penultimate-hop popping, a pop. In either case there is no need to configure anything specific
on the egress router.
Of course when penultimate-hop popping is disabled the egress router needs to have MPLS forwarding enabled on the
incoming interface.

MPLS Directly Affects Two Tables

On Juniper routers, the configuration of a static LSP directly affects two tables:
• The mpls.0 table (the label switching table) which holds mappings between incoming MPLS labels and
forwarding actions.
• The inet.3 table, which is used to keep track of LSP egress points.
We will explain the use of this table later on in the course.
Note that the inet.0 and inet.6 tables which are respectively used for IP and IPv6 forwarding are not affected by static
LSP configuration. This means that a Juniper router will not, by default, use MPLS for forwarding IPv4 or IPv6 traffic.

Static Routes with a Static LSP as the Next-Hop

A very easy way to get a static label-switched path to be used for forwarding is to create a static route with the static LSP as
next-hop. The static route will then be installed into the inet.0 table, and will be used to forward traffic.
There are also other ways (discussed later on) to associate prefixes to label-switched paths for forwarding. However static
routes with LSP next-hops have several advantages, including the possibility of easily setting route-specific attributes, and
the fact that static routes are easy to manipulate and redistribute with policies.

MPLS Packet Forwarding


Configuring a Static LSP for IP Forwarding

We will now look at the full configuration of a static LSP spanning four nodes, checking the effect of the different
configuration statements on routing table and label information base, and finally putting some IP traffic on the LSP to verify
the forwarding behavior.
To do this, we will need to configure R1 as ingress, R2 as transit and R3 (still transit) for penultimate-hop popping. No
configuration is needed on R4 - it will receive ordinary IP packers and forward them according to normal IP routing.

Ingress Router Configuration

On top of configuring the router as ingress for a LSP, we will also need to define a static route with the static LSP as next-hop.
This will allow us to verify MPLS forwarding.

Ingress Router Operational Mode Commands

A useful command to verify the state of an LSP on the ingress node is show mpls static-lsp ingress. Note that the
up state only means the LSP is configured, the outgoing interface is up and the next-hop is reachable, but there is no
guarantee that the path is working end-to-end as there is no signaling mechanism to check it.
This is one of the reasons why static LSPs are never really deployed in production networks: a link failure downstream would
cause all traffic sent into the LSP to be lost.

Transit Router Configuration

The transit router operates in pure label switching mode, so we only need to define incoming labels and their associated
forwarding actions. The label operation will typically be a “swap”, unless the router is the penultimate-hop — in this case, an
action of “pop” is also possible, if penultimate-hop popping is enabled.
For point-to-point interfaces (e.g., SONET/SDH) the next-hop can be expressed with an interface name rather than with an IP
address. This is of course not possible with multi-access layer-2 technologies such as Ethernet.

Transit Router Operational Mode Commands

To check the state of a LSP on a transit router, the show mpls static-lsp transit (optionally followed by name
<name>) is a good starting point; with the extensive modifier it will also print traffic statistics and the outgoing label:
user@R2> show mpls static-lsp name R1-to-R6 transit extensive
Transit LSPs:
LSPname: R1-to-R4, Incoming-label: 1000822
State: Up, Sub State: Traffic via primary but unprotected
Nexthop: 172.17.23.10 Via ge-1/1/7.0
LabelOperation: Swap, Outgoing-label: 1000675
Created: Tue Nov 10 09:31:24 2015
Bandwidth: 0 bps
Statistics: Packets 14595, Bytes 1283226
Total 1, displayed 1, Up 1, Down 0
You can also find the outgoing label by checking the label switching table, mpls.0: to do this, you can use show route
table mpls.0| find <label>, where <label> is the static LSP incoming label.

Penultimate Hop Router Configuration

The configuration on the penultimate hop router is similar to the one for transit routers. The only difference is the forwarding
action, that can be either a pop (for penultimate-hop popping) or a swap with 0 (explicit null). In this example, the action was
set to pop - the Junos OS default.

Penultimate Hop Router Operational Mode Commands

The operational mode commands for the penultimate hop router are exactly the same as for any transit router. The only
difference is the forwarding action; in the example, the action is pop.
Note the two entries in the mpls.0 table for the static LSP incoming label; they can be used in some scenarios to handle
differently packets with a single label (s=1) or multiple stacked labels (s=0).

End Result
One way of checking the forwarding behavior is to run a traceroute through the static LSP. Remember though that LSPs are
unidirectional, and the return ICMP TTL-expired packets used by traceroute need to be able to follow a normal IP route back
to the traceroute source (in this example, C1).
Traceroute also allows you to see the actual labels: within each TTL-expired ICMP packet is part of the frame which triggered
it, and this allows traceroute implementations to decode and display the fields of MPLS headers.

We Discussed:
• Common terms relating to MPLS;
• The way a label-switching router forwards MPLS;
• Packet flow and label operations through an LSP;
• Configuration and verification of MPLS forwarding; and
• The content of the label information base.

Review Questions
1.
2.
3.

Lab: MPLS Fundamentals

The slide provides the objectives for this lab.

Answers to Review Questions
1.
The MPLS header is composed of a label field (20 bits), a Traffic Class field (3 bits), a bottom-of-the stack bit (one bit) and a
TTL field (8 bits), for a total of 32 bits.
2.
An ingress router will typically perform a pop action, while a transit router will perform a swap action. If the transit router
happens to be the second-to-last and penultimate-hop popping is required, it may perform a pop rather than a swap action.
3.
The mpls.0 table contains the label switching table, which associates to each incoming label its forwarding operation
(typically a MPLS operation of push, pop or swap plus a forwarding next-hop to which traffic should be sent).


Chapter 3: Label Distribution Protocols

We Will Discuss:
• Two label distribution protocols used by the Junos operating system;
• Configuration and verification of RSVP-signaled and LDP-signaled label-switched paths (LSPs); and
• Given a set of requirements, choosing and configuring the appropriate label distribution protocol.
Chapter 3–2 • Label Distribution Protocols www.juniper.net

Label Distribution Protocols

www.juniper.net Label Distribution Protocols • Chapter 3–3

Deployment of Static LSPs Is Not Realistic

Establishing label-switched paths and allocating labels using static configuration is not a realistic option: not only it would be
difficult to keep track of label allocation on every label-switching router, but a static LSP would not be able to react to
changes in topology, for example to a link going down.
Dynamically Allocate Labels and Establish LSPs

A solution to both these problems is a dynamic label distribution protocol capable of allocating labels and distributing label
information across the network. A label distribution protocol also needs to be able to react to changes in network topology,
for example signaling to the ingress router that a given label-switched path is no longer usable.
This chapter discusses two label distribution protocols: RSVP and LDP. Even if they are both designed to build label-switched
paths and distribute label information, their uses, capabilities and operation are very different. It is important to know both,
as each has its own applications.

RSVP
RSVP is a generic signaling protocol designed originally to be used by applications to request and reserve specific
quality-of-service (QoS) treatment across the Internet. Resources are reserved hop by hop across the network: each router
receives the resource reservation request, establishes and maintains the necessary state for the data flow, and forwards the
resource reservation request to the next router along the path.
The Junos OS uses RSVP as the label distribution protocol for traffic engineering. Allocating labels along a label-switched
path, optionally with an associated bandwidth reservation, can be viewed as a resource reservation problem, so it was
natural to create a set of RSVP extensions to handle label allocation and bandwidth reservation.
Some of the capabilities offered by RSVP are:
• The creation of an LSP that along an arbitrary path, without having to follow the interior gateway protocol (IGP);.
This opened the possibility of doing “real” traffic engineering.
• The distribution of label information to all LSRs in the LSP in a consistent way, avoiding problems such as
label-switching loops.
• The reservation of bandwidth along the path
• The possibility of requesting a specific Class of Service treatment for traffic traversing a label-switched path.

RSVP (contd.)
With time, several other extensions were developed and standardized, including the possibility of creating point-to-multipoint
label-switched paths, the support for traffic protection, and many others.
RSVP uses the underlaying IP unicast infrastructure, i.e. the IGP, to signal paths through the network. Its major capability is
the possibility to specify path constraints - a list of nodes or hops that a given LSP should traverse. Because of this, its main
applications are related to MPLS traffic engineering.
LDP
LDP is a radically different protocol compared to RSVP. Its main goal was neither to reserve resources nor to do traffic
engineering, but simply to offload the forwarding plane of core routers by building a full mesh of label-switched paths, from
any node to any other node.
The LDP signaling protocol always establishes LSPs that follow the IGP best path, and because of this it cannot be used for
traffic engineering. However, if finds important applications in scenarios such as large Layer 2 or Layer 3 VPN deployments,
and generally all scenarios where it is not important the actual path a LSP takes as it crosses the network.

RSVP

RSVP
RSVP was originally designed as part of the Integrated Services architecture (RFC1633), an initial and now abandoned effort
to provide fine-grained Quality of Service across the Internet.
RSVP is a general resource reservation protocol, whose goal was to “provide a general facility for creating and maintaining
distributed reservation state across a set of multicast or unicast delivery paths” (RFC 2205). Originally it was supposed to be
deployed on hosts (end systems), and used for requesting and allocating guaranteed bandwidth along a path for
applications for such as videoconferencing and voice calls. It was explicitly designed to support extensibility by means of
opaque objects, complex entities transported in a transparent way by the protocol, and handled by the networking nodes in
the path independently from the protocol itself. The idea was to allow RSVP to handle reservations for any type of resource,
present or future; and this extreme flexibility and versatility allowed RSVP to be re-deployed as a label distribution protocol,
running not anymore between hosts, but between routers.
It is worth noting again that RSVP is a signaling, not a routing protocol: its purpose it to establish and tear down
label-switched paths, as well as to detect problems along an established LSP. The Junos OS uses RSVP as the label
distribution protocol for traffic engineering applications.

RSVP Message Types

RSVP uses six different message types:
• During LSP setup and label distribution
– Path messages are sent by the ingress router to request that a path (LSP) be created.
– Resv messages reserve resources, including label assignments, for the LSP.
• For tearing down existing LSPs
– PathTear messages delete the path and corresponding reservation state from routers that receive them.
The PathTear message is originated by the sender, or by a router whose path state has timed out. It
always travels downstream toward the receiver.
– ResvTear also removes the reservation state, but is sent in the opposite direction: upstream towards the
sender.

RSVP Message Types (contd.)
• For error handling
– PathErr messages report errors in processing path messages, and travel upstream towards the ingress
along the reverse route of path messages.
– Resv Err messages report errors in the processing of Resv messages, and travel hop by hop downstream
towards the egress. All RSVP messages share a common RSVP header that includes a field for identifying
the message type. The messages is comprised of this common header followed by one or more RSVP
objects.
All RSVP messages share a common header, and generally include several RSVP objects. We will examine in the following
slides the operations of the protocol, and the role and use of each of those messages.

Creating an LSP Is a Two-Step Process

The creation of a new LSP is initiated by the ingress router, which starts the process by sending a PATH message
downstream towards the egress router or, if traffic engineering is desired, towards the next node to be traversed by the LSP.
The PATH message is sent with the router-alert bit set (RFC 2113), so every router in the path will be able to examine it,
create a path state block and modify it as needed before sending it onwards. Each path state block contains information
about a particular RSVP session, and is stored by each router along the path.

Included in RSVP PATH Messages

The path message can include a number of RSVP objects. Among the most common ones are:
• SESSION object: Acts as a session identifier, and contains the LSP endpoints plus a tunnel-id which is
dynamically allocated by the Junos OS.
• SESSION_ATTRIBUTE object: Characteristics of the session, including the LSP name and the setup and hold
priorities assigned to the LSP for bandwidth reservation, and a list of flags which specify if link or node traffic
protection is requested for this LSP.
• SENDER_TSPEC: Bandwidth reservation associated with the LSP.
• RSVP-HOP object: Each node sending a Path message will set this object to the IP address of the outgoing
interface; this will be important in the reservation phase.
• LABEL_REQUEST object: Request for label from the downstream router.
• RECORD_ROUTE object: List of addresses of all interfaces traversed by the path message.
When traffic engineering is required, additional objects are typically included:
• EXPLICIT_ROUTE object (ERO): List of strict or loose hops that RSVP path messages must traverse. We will
examine the behavior of RSVP when this object is present in the following slides.

RESV Messages and Label Allocation

Once the RSVP PATH message reaches the egress LSR, the actual MPLS label allocation starts. Allocated labels are included
in a RESV message, which is sent back towards the ingress following the same route of the PATH message.
As in the case of PATH messages, each RESV message creates a reservation state block on each LSR it traverses.

Included in RSVP RESV Messages

• SESSION object: Uniquely identifies the session (that is, the LSP) to which the message belongs.
• LABEL object: The MPLS label that the LSR which sent the RESV message expects to receive for traffic
belonging to this LSP.
This is what allows the creation of the label-switched path: generally, a transit router receiving a RSVP RESV
message will allocate a new label from its free label allocation space, relay it upstream using a RESV message
and install a swap operation from the newly allocated label to the label expected by the next-hop. This method
of label allocation is called upstream on demand. Upstream as labels are allocated from the egress to the
ingress, against the flow of traffic. On demand as labels are allocated only after an explicit request, in the form
of the label request object contained in PATH messages.
• RECORD_ROUTE object: Returns the LSPs path to the sender of the original Resv message. This will allows
every router in the LSP, and specifically the ingress, to have full visibility about the actual path taken by the LSP
within the network.
• STYLE object: Used to reserve bandwidth. It is used to request shared explicit, wildcard or fixed filter reservation
style. We will examine the difference between these reservation styles in a later chapter.
• HOP object: Indicates the previous hop’s IP address.

RSVP Session Maintenance

RSVP is a “soft state” protocol: this means that state (that is, reservations and their corresponding label allocations) are not
permanent, but need to be refreshed periodically; if they are not refreshed, they will time out and disappear.
A reservation is refreshed by periodically sending again PATH and RESV messages, exactly as it was first done when the LSP
was set up. The reservation state is refreshed every (approximately) 30 seconds; a configurable keep-multiplier (with a
default value of 3) indicates how many RESV/PATH messages can be lost before the reservation is considered expired, and
state is removed.
The expiration time of a RSVP reservation is given by this formula:
lifetime = (keep-multiplier + 0.5) x (1.5 x refresh-time)
This would bring the lifetime of a reservation (with default timers) to well over two and half minutes, making this mechanism
almost useless for failure detection.
Luckily there are two mechanisms that help improve substantially failure detection times:
• RSVP hello packets, an RSVP extension that helps detect neighbor failures faster than the refresh mechanism.
• RSVP tracking of IGP adjacencies: the Junos OS keeps track and reacts to any change in IGP state on interfaces
towards RSVP neighbors.

RSVP Session Maintenance (contd.)
For more details, please see the chapter “RSVP and IGP Hello Packets and Timers” in the Junos OS MPLS applications guide,
available on the Juniper Networks website.
The RSVP refresh operation can be rather resource intensive when the number of LSPs is high. To help improve scalability, it
is possible to bundle multiple refresh operations into a single packet using RSVP refresh reduction extensions (RFC2961),
provided all routers in the path support them.

Use of PathErr and ResvErr Messages

The PathErr and ResvErr are typically used to signal error conditions during the LSP setup phase:
• PathErr: It is sent upstream towards the ingress router whenever a LSR cannot forward the PATH message. This
can happen if MPLS is not enabled on the outgoing interface, or, when reserving bandwidth, if there is not
enough free bandwidth on the outgoing interface.
The PathErr message is also used with already established LSPs in some traffic protection scenarios, to signal
to the ingress LSR the occurrence of a non-fatal error condition.
• ResvErr: It is sent downstream, towards the egress, whenever a router receives a RESV message but cannot
complete the reservation. This is a bit less common, but can happen - for example, because of MPLS label
allocation failure.

RSVP Teardown Messages For Established LSPs

RSVP Teardown messages are used to remove path and reservation state.
• PathTear: travels downstream, towards the egress, deleting both path state and the corresponding reservation
state along the way. It can be initiated by an intermediate node after detecting a failure on the previous hop.
• ResvTear: travels upstream from its point of initiation, towards the ingress.
You can think of a PathTear message as a the inverse of a PATH message: it travels in the same direction, downstream
towards the egress, removing the path state and its associated reservation state as it travels. In the same way, you can thing
of a ResvTear message as the inverse of a RESV message: it is sent upstream towards the ingress, clearing state as it
travels.
A teardown request can be initiated by the ingress router as a result of operator intervention, as well as by any router in the
path after state timeout or LSP preemption. Once initiated, a teardown request must be forwarded hop by hop without delay.

EROs Allow LSR to Influence the Path of An LSP

By including the EXPLICIT_ROUTE Object (ERO) in the PATH message, the ingress LSR can control the path through which a
LSP is established, independently from the IGP best path. This is by far the most important feature of RSVP as a label
distribution protocol, as it allows it to be used for traffic engineering.
You can think about an EROs as a list of hops that the LSP should be traversing, or a list of path constraints that the LSP
needs to verify. Each hop within an ERO has either a qualifier of strict (the default) or loose.
The use of a EROs changes the RSVP LSP setup process.Tto understand how, we can follow a simple example of an ERO
composed of two constraints, a loose hop followed by a strict one.
Without using EROs, the RSVP PATH message is sent towards the egress router using the IGP best path. The destination
address of the RSVP IP packets is the LSP endpoint, and—due to the fact that the IP router-alert option is set—every router in
the path will receive, examine and process them.
With EROs, the PATH message is sent towards the first hop listed in the ERO - that is, the first constraint to be verified. In the
example, the ingress router, R1, will send a RSVP packet with a destination address of R7, which will be routed according to
the best IGP path.

ERO Loose Constraint Processing

Once a router receives a PATH message with a loose hop as a first constraint, it will check if the hop is one of its local
addresses, and if it is not, it will forward the PATH message without modifying the ERO.
In this example, R6 receives the PATH message with an ERO={R7 loose, R4 strict}. Since it cannot satisfy the constraint at
the top of the ERO, it will keep on forwarding the PATH message towards R7, after creating the local PATH state.

ERO Loose Constraint Verification

After crossing the transit router R6, the RSVP PATH message is received by R7; at this point, the first constraint (R7 loose) is
satisfied, so it is removed from the ERO object. After creating a PATH state, R7 will then send the PATH message (now with
only a single constraint in the ERO) towards R4.

ERO Strict Constraint Verification

If a router receives a RSVP PATH message with an ERO which has a strict hop at the top, two cases are possible:
1. The router can verify the constraint, that is the address listed in the strict hop is either the interface the PATH
message has been received on, or a loopback address. In this case the constraint is removed from the ERO,
and the forwarding of the PATH message can continue, either towards the next constraint to be verified in the
ERO or, if the ERO is empty, towards the egress.
2. The router cannot satisfy the constraint as the address of the strict hop is neither the address of the incoming
interface nor a loopback address. In this case, a PathErr message is sent back towards the ingress with an error
message of wrong delivery, and the LSP setup process fails.
In other words, a strict hop in a ERO is used to determine the next hop a LSP should go through; it does not allow for
intermediate routers in the path. If you use a strict hop as a first constraint in the ERO, that will be the first hop of your LSP;
if you use a strict hop after a loose hop, it will be the next hop after that loose hop.
In the example, R4 can verify the strict constraint; the last remaining element of the ERO is removed, and forwarding can
continue towards the egress.

RESV Message and LSP Setup

Once the PATH message reaches the egress router, the reservation phase can begin. The RESV message will go through the
same hops as the PATH message, as every router kept track in their PATH state of what the previous hop was for that LSP—
remember that PATH messages include a RSVP-hop object exactly for this purpose.

The RRO Provides End-to-End Path Visibility

The Record Route Object (RRO) keeps track of the actual path an LSP is traversing. Every node adds to the RRO the address of
the interface on which the PATH message has been received. This will become the MPLS forwarding next-hop used by the
upstream router once the RESV phase is complete and labels are allocated.
After the PATH message reaches the LSP egress, the complete RRO object is sent back towards the ingress using the RESV
message. This is done so that all label-switching routers have full visibility of the path taken by the LSP as it traverses the
network.
Other than providing visibility, there is another important function of the RRO object: the detection of possible forwarding loops.
We will examine this feature in the next slide.

The Record Route Object and Loop Detection

For normal IP routing, the loop-free property is guaranteed by the fact that traffic follows the IGP, which, when correctly
configured, does not allow for loops. But setting up arbitrary paths with Explicit Route Objects can cause an LSP to cross the
same node twice, resulting in a loop.
The Record Route Object (RRO) can detect this situation in the PATH phase of LSP setup. If a node receives a PATH message
with one of its local addresses listed within the RRO, it sends back a PathErr message indicating Routing Loop Detected and
aborts the LSP setup.
In this example, an ERO={R7 LOOSE, R4 STRICT, R2 STRICT} could cause a loop with traffic crossing twice the link between
R2 and R4. However this is prevented by RRO processing:
1. R4 receives the PATH message through R7, it will add to the RRO the address of the interface on which the
message has been received (that is, of the link R4-R7), and forward the PATH message towards R2.
2. R2 will add the address of its interface facing R4 to the RRO object, and forward the PATH message back
towards R4.
3. R4 will detect one of its own addresses in the ERO, and abort the process after sending back towards the
ingress a PathErr message.
The PathErr message will contain an error object which specifies the interface on which the loop has been detected, in this
case the interface on R4 facing R7. This makes it easy to locate and address the problem.

Minimal RSVP Configuration

Before configuring RSVP, MPLS need to be enabled on all interfaces on which label-switched paths will be signaled. This
means:
• Configuring family mpls at the logical unit level.
• Listing again the interfaces at the [edit protocols mpls] level, or, as an alternative, use interface
all.
After these preliminary steps are completed, the basic RSVP configuration involves just enumerating the interfaces again at
the [edit protocol rsvp] level. This is already a valid minimal configuration, and the router will be able to initiate or
participate in RSVP LSP setup.

RSVP Label-Switched Paths Are Configured Under Protocols MPLS

The configuration to trigger the creation of a RSVP label-switched path takes place at the [edit protocol mpls] level,
in the ingress router.
The only mandatory arguments are:
• LSP name: Just a string used to identify the LSP. It has several uses, e.g. you can use it to identify the LSP to use
as a next-hop for a static route, or in a policy.
• LSP endpoint: The IP address of the egress point of the LSP. This will be installed into the inet.3 table as a
/32 prefix, which will then be used by MPLS applications such as traffic engineering and MPLS VPNs.
Note the no-cspf command. This is important, as by default the Junos OS tries to use Constrained Shortest Path First
(CSPF) to pre-compute LSP paths using data derived from traffic engineering extensions to the IGP. Since we are only
interested in the mechanisms used by RSVP to signal LSPs, for the moment we will disable this functionality. CSPF will be
covered in detail in the following chapters.
Committing the configuration will cause the LSP setup process to start, and the PATH message to be sent towards the egress
point. Note that we did not specify any Explicit Route Object, so the PATH message will be forwarded hop-by-hop towards the
egress following the IGP.

An RSVP-Signaled LSP Can Be Configured to Reserve Bandwidth Along the Path

It is possible for an LSP to be configured to reserve bandwidth along its path. During the setup process, each downstream
router will receive a request to reserve bandwidth for the LSP in the form of the traffic specification (TSpec) object. Each
router along the path will make its own individual decision as whether it has enough available bandwidth on its egress
interface for the LSP. If there is not enough available bandwidth, LSP setup will fail and the upstream routers will be informed
of this by a PathErr message.
By default the bandwidth parameter is only used for LSP setup, not to police or rate-limit actual traffic. In other words, even if
an LSP has been signaled with a specific bandwidth reservation, it is in fact possible to put on it an arbitrary amount of
traffic, even exceeding the reserved bandwidth.
It is possible, however, to override the default behavior and have the ingress router police the traffic that enters an LSP. This
can be done by configuring auto-policing or configuring a firewall filter and applying it directly to the LSP.

RSVP Allows the Whole Interface Bandwidth to Be Reserved

By default, RSVP allows the whole interface bandwidth to be reserved. However it is possible to specify a subscription
percentage (between 0 and 65000). This allows to restrict the amount of bandwidth that RSVP can allocate, or, if greater
than 100, to oversubscribe the interface, i.e. allocate more bandwidth than the physical interface can provide.

Configuring a Path (ERO) for the LSP

Configuring an explicit path for an LSP involves two steps:
• Define a path at the [edit protocol mpls] level, and assign it a name. The path will just be a series of
strict or loose hops, which will be translated into the Explicit Route Object included in the RSVP PATH message.
• Apply the path to the LSP using the keyword primary. This keyword should make you suspect that is possible
to define also secondary paths, which will be used if the primary fails and is no longer usable. The use of
secondary paths will be described later on in the course.
In the example, loopback addresses are used for both strict and loose hops. It is possible to use either interface addresses
or loopback addresses when specifying hops, but of course the results will be different. The general rule is to use interface
addresses, typically as strict hops, if you want to nail down an LSP to a specific incoming interface, and loopback address if
you do not care about the incoming interface, but you are only interested in the LSP crossing a given node.

RSVP Operational Mode Commands

Here are some of the most useful RSVP-related operational mode commands:
• show mpls lsp: By far the most useful command to check LSP status.
• show rsvp sessions: This is a useful complement to show mpls lsp as it gives some additional useful
information, including actual MPLS labels (label-in and label-out), the current path MTU (if MTU signaling is
enabled) and traffic protection features active at the current node.
• show rsvp interface It is a good command to run after configuring RSVP on an interface. For each
interfaces, it also shows the number of existing reservations (i.e. the number of LSPs), and the bandwidth
available to new reservations.
• clear rsvp session and clear mpls lsp: These commands will tear down the LSP and attempt to
re-signal it.
We will look at those commands in detail in the following slides. For more information, please see the “Operational
Commands” section in the “Junos OS MPLS Applications Feature Guide for Routing Devices”, available on the Juniper
website.

Checking MPLS and RSVP Interfaces

In order to signal an LSP through an interface, MPLS needs to be enabled. Because of this, a good first step is to verify this
with the show mpls interface command.
The show rsvp interface command, without any modifier, will display a summary of the interfaces on which RSVP has
been enabled, including the number of active reservations (that is, the number of LSPs), the available bandwidth that can be
used for reservations, and the high water mark—the maximum amount of bandwidth that has ever been reserved on the
interface.
The example shows a single LSP which reserved 400Mb of a Gigabit Ethernet interface. The high-water mark shows that at
one point in the past 921Mb were reserved on that interface.

Checking the Overall State of LSPs

A good command to check the overall state of all LSPs going through the router is show mpls lsp. Optionally you can
restrict the output by specifying one of the keywords ingress, egress or transit, or select a single LSP by name.
In this example, taken on router R2, the LSP named R1-to-R6 is listed as down. To find out why, we will need to examine the
state of that specific LSP in detail. Often the best place to do this is the ingress router.

Examining a LSP in Detail

To check in detail the state of an LSP, you can use the command show mpls lsp name <name> extensive. This will
print a wealth of information about the LSP, including its path through the network (derived by the RRO object), the name of
the path (the ERO) used to signal it (if any), whether penultimate-hop popping is enabled or not and, finally, a short log
detailing the last events which affected the LSP. After a LSP-down event, it is usually enough to check the output of this
command to have, if not a complete diagnosis, at least a good idea about what the problem is.

An Example: Routing Loop Detected

This example shows how the show mpls lsp command can help pinpoint the reason of an lsp-down event. In this case,
the RRO detected a routing loop due to an incorrect configuration of the ERO object.
The error has been detected on an interface whose address is 172.17.23.18. With the help of a network topology diagram it
should be easy to find out why a routing loop was created, and change the configuration of the LSP path to avoid it.

Examining RSVP Sessions

Each RSVP LSP has an associated RSVP session, and examining it using the show rsvp session command is a useful
complement to show mpls lsp. It is possible to display the session of a single LSP by specifying its name. This is generally
a very good idea, given the verbose output this command generates.
In this example, we are examining an LSP from the point of view of the second router in the path. You can see this by
checking the RRO object: the current node is expressed with the <self> tag.

MD5-Based Authentication of RSVP Messages

It is possible to authenticate RSVP messages using a keyed Hash Message Authentication Code (HMAC). The authentication
key can be configured at the interface level, and can be different for each interface.
It is possible to verify authentication by using the command show rsvp interface <name> extensive, as in the
example.

MTU Discovery for RSVP-Signaled LSPs

The Junos OS supports maximum transmission unit (MTU) discovery when using RSVP signaling. The discovery mechanism
is performed according to the integrated services object as defined in RFCs 2210 and 2215. This feature helps to prevent
the black hole condition that is normally associated with mismatched MTUs along an the elements that make up an LSP.
MTU discovery signaling can be configured independently of ingress LSR fragmentation, but you must have
mtu-signaling configured if you are configuring the allow-fragmentation option. Both options are configured at
the [edit protocols mpls path-mtu] hierarchy.
In operation, the ingress LSR sets the M value in the TSPEC to 9192 and codes the egress interface’s IP MTU in the ADSPEC
object in the PATH message. At each hop transit LSRs update the MTU value in the ADSPEC object with the minimum of the
incoming value and egress interface MTU. When the PATH message is received by the egress LSR the smaller of the two
values coded in the TSPEC and ADSPEC objects is signaled back to the ingress router using the Flowspec object in the RESV
message. This behavior is shown on the slide where the 1500-byte MTU is correctly reported to the egress router in the
ADSPEC object.
Note that all routers (not only the ingress) must be configured for path MTU signaling.
Special care must be taken when using advanced traffic protection features like fast reroute, link or node protection; a link
failure could cause traffic to be rerouted through a bypass or a detour LSP, and when this happens the new MTU is only
signaled at the time the bypass/detour becomes active. Thus, during the time it takes for the new path MTU to be
propagated, there can be packet loss due to MTU mismatch.

Verifying the LSP Path MTU

You can use the show rsvp session name <lsp-name> extensive command to verify the path MTU reported by
RSVP.
In this example, the path is detected as 1500 bytes; but of those, only 1488 are used for forwarding. The reason is that, to
be safe, it is best to assume that the actual payload will be preceded by least 3 labels (12 bytes): one transport label that will
decide where traffic should be delivered, one service label to indicate how traffic should be treated once it reaches the
egress router, and finally one label to be used for traffic protection, for example for link or node protection.

I
Point-to-Multipoint LSP Configuration

RSVP allows the creation of point-to-multipoint LSPs, that is LSPs which have multiple egress points. Any packet that is sent
into the LSP is duplicated and delivered to all egress LSRs.
This feature is used in many MPLS applications that require efficient packet replication:
• VPLS and EVPN, for delivering Broadcast. Multicast and Unknown Unicast (BUM) traffic to multiple recipients.
• MVPN, to handle packet replication for multicast traffic within a VPN.
• IP multicast over MPLS, to deliver IP multicast streams to multiple routers without running multicast protocols
such as PIM.

P2MP LSPs Are Signaled as Multiple Sub-LSPs

Configuring a point-to-multipoint LSP means configuring a number of sub-LSPs, one for every egress point, and then linking
them together using the p2mp <name> configuration statement.
In the example you can see a very simple application, a static route for a multicast address pointing to the LSP as next-hop.
This will case all multicast traffic for group 224.7.7.7 to be replicated by the LSP and delivered to both R3 and R5. The
multicast statement at the [edit routing-options] level allows an interface to receive multicast frames even if
no multicast routing protocol is enabled.

Bidirectional Forwarding Detection for RSVP LSPs

RSVP does not provide any mechanism for fast failure detection. Even if Juniper implemented a RSVP hello object to improve
convergence, this was never standardized across all vendors, potentially creating interoperability issues. As a workaround,
Juniper implemented IGP tracking of RSVP adjacencies. This means that, if an IGP adjacency goes down on an interface, all
LSPs going through it will be notified of the failure. This provides a reasonably fast failure detection mechanism without the
need of proprietary extensions.
Juniper recommends using BFD for IGP adjacencies to improve RSVP failure detection times, but this does not test the LSP
forwarding plane end-to-end. For this, it is possible to enable Bidirectional Forwarding Detection on the LSP itself. This is
guaranteed to detect even non-obvious forwarding plane problems, e.g. when all IGP adjacencies are still up and the RSVP
state is being refreshed, but, due to some failure, some of the traffic going through the LSP is lost.

Sample Output for LSP with BFD

Once BFD has been configured for a LSP, the show mpls lsp output will report its status.

Many MPLS Applications Require a Full Mesh of LSPs

Many MPLS applications, including for example MPLS VPNs and VPLS, require a full mesh of LSPs between nodes. This can
make adding a new node problematic as, in addition to configuring the new node, every other node also needs to have their
configuration changed.
To address this limitation, the Junos OS provides an auto-mesh feature which is capable of automatically provisioning new
LSPs, should an application demand one.

Basic RSVP Auto-Mesh Configuration

All auto-mesh configuration besides enabling MPLS and RSVP is done under the [edit routing-options] hierarchy.
Here you can specify a name, an id and a prefix to possible destinations, for example all loopback addresses of provider
edge routers in a VPN scenario.
To influence the characteristics of the dynamic LSPs created by auto-mesh it is possible to configure a LSP template, which
can be used to change some of their attributes and properties, e.g. bandwidth reservation or desired traffic protection mode.

Operational Mode Commands for RSVP Auto-Mesh

To list all LSPs that have been dynamically created by RSVP auto-mesh you can use the command show
dynamic-tunnels database. This will show the LSPs and a counter of applications which are using them (reference
count). A reference count of zero means no application is using the dynamic LSPs. This trigger an expiration timer of about
15 minutes, after which the dynamic LSPs are automatically removed.

The Ultimate-Hop-Popping Command

Sometimes it is important to preserve the identity of an LSP even at the egress LSR - for example if you want to measure
delay and loss on an LSP using in-band frames, (frames that are transported through the LSP itself).
For those applications, it is possible to configure a LSP for ultimate hop popping; this would cause an ordinary label (not
label 0 or 3) to be allocated by the egress router. An implication of this is that the egress router will need to do two lookup
operations every times it receives a frame through the LSP. The initial lookup operation is used to identify the frame as part
of the LSP, and the second lookup to handle the payload.

Example of show mpls lsp with Ultimate-Hop Popping

This slide shows the output of show mpls lsp extensive for a LSP configured for ultimate-hop popping. You can see
this in the LSP type field.

On-Demand Packet Loss and Delay Measurement

Some applications are critically sensitive to latency, delay and loss — in other words, to the behavior of the underlaying MPLS
network. To allow the measurements of these critical parameters using in-band forwarding, the Junos OS provides
on-demand packet loss and delay measurement over a bidirectional LSP configured with ultimate-hop popping,
In order to use this feature two LSPs, one in each direction, need to be configured between the endpoints and associated
with each other. The two LSPs need to be configured for ultimate-hop-popping, and oam mpls-tp-mode, which
turns on processing of GAL frames (label 13).

Packet Loss and Delay Measurement Results

After the bidirectional LSPs have been configured, you can start a test by running the operational mode command monitor
mpls loss-delay rsvp <lsp>. By default each test is composed of 11 probe packets, sent every second. Both those
parameters are configurable with the arguments count and interval.

Graceful Restart Maintains Forwarding State During a Router Restart or Reboot

The Junos OS supports RSVP graceful restart as defined in RFC 3473. To enable graceful restart, add the
graceful-restart statement at the [edit routing-options] level. This global configuration statement enables
graceful restart on all protocols that support the capability, for example LDP and OSPF. To specifically disable RSVP graceful
restart, helper mode, or both, add explicit configuration to the RSVP stanza as shown on the slide.
In operation, a router makes its RSVP graceful restart capabilities known through the inclusion of a Restart_Cap object in its
hello messages. By default, both graceful restart and helper mode are enabled for RSVP when the graceful-restart
statement is added to the main routing instance. After a restart, the local router signals that it was able to preserve its
forwarding state by sending a Restart_Cap object with a recovery-time value that is not zero. Neighbors with helper mode
enabled respond to this message by sending back the labels that were last advertised by the restarting router. The result is
that the restarting router’s signaling plane can be bootstrapped back into its pre-restart state, while forwarding continues
unabated.
Note that you cannot modify the timers associated with RSVP graceful restart at this time. Also note that RSVP helper mode
is enabled by default, even when the graceful-restart option is not specified in the main routing instance. Therefore, the
Junos OS RSVP implementation will always try to help another RSVP peer restart, unless you explicitly disable helper mode.

Verify RSVP Graceful Restart

On top of displaying the default timers, the show rsvp version command shows the state of different RSVP features,
including graceful restart and its evolution, non-stop routing.

RSVP Traceoptions
As usual in the Junos OS, it is possible to enable protocol traceoptions (debugging) at the [edit protocols rsvp]
level.
The flags which are available are:
• error: Trace error conditions.
• event: Trace RSVP related events.
• lmp: Trace RSVP-LMP related interactions.
• lsp-prefix: Prefix the trace messages with LSP information.
• nsr-synchronization: Trace NSR synchronization events.
• packets: Trace all RSVP packets.
• path: Trace RSVP path messages.
• pathtear: Trace RSVP PathTear messages.
• resv: Trace RSVP Resv messages.
• resvtear: Trace RSVP ResvTear messages.
• route: Trace routing information.
• state: Trace state transitions.

LDP

LDP Concepts
The Label Distribution Protocol (LDP) protocol had very different origins and goals than RSVP. Its original design goal was to
offload core routers so that they did not have to do a full route lookup for every packet. The key observation was that there
should be no need to do a lookup at every hop on a table that typically contains thousand and thousands of prefixes.
LDP introduces the concept of FEC (Forwarding Equivalence Class), a class of packets which should be treated in the same
manner, or, in simpler terms, a class of packets which are headed to the same egress point within a MPLS network. In LDP,
every router will advertise one label for each FEC. We will see in the next slide how this is used to build a tree of LSPs from
every possible ingress router.
The Junos OS implementation of LDP supports LDP Version 1, using the ordered downstream unsolicited mode with liberal
label retention, as defined in RFC 3036. This means that each LDP peer will store all label bindings received (liberal
retention), that each downstream peer will advertise all FECs for which it is prepared to receive labeled traffic (downstream
unsolicited), and that FECs are only advertised when the router is the egress point or when it has received a label mapping
for the traffic’s next hop (ordered).
Since version 12.2, the Junos OS also supports downstream on-demand label distribution mode. For this, all routers need to
be configured with the downstream-on-demand command, at the [edit protocols ldp session
<session-address>] hierarchy.

LDP Concepts (contd.)
This mode is more rarely used, but can find an application in cases where, in a core/access design, access routers need to
receive the minimal amount of labels, i.e. only the labels for the egress points they need. To do this, each access router can
define a policy matching only the prefixes it requires, and then configure that policy at the [edit protocols ldp
dod-request-policy] level.
For the rest of this module we will focus on the downstream unsolicited label distribution mode. For more details on the
downstream on demand mode, please see the chapter “Configuring LDP Downstream on Demand” in the Junos OS MPLS
Applications guide.
The Junos OS provides two options for LDP neighbor discovery:
• Basic neighbor discovery can establish an LDP session only with directly connected neighbors. LDP hello
messages are sent to a link-local destination address, 224.0.0.2, the “all routers on subnet” address.
• Extended discovery allows establishment of a LDP session between routers which are not directly connected. In
this case, discovery happens with targeted unicast hello packets, and the address of LDP neighbors needs to
be explicitly configured.
There are several interesting applications for extended discovery, including Layer-2 circuits, a technology to
transport Layer 2 frames over MPLS, and LDP tunneling, which allows to LDP to integrate with RSVP-based
traffic engineering.

Purpose of LDP: Building Trees of LSPs

The purpose of LDP is to create, for every egress router, a tree of LSPs from every possible ingress router. The label
information is exchanged in a hop by hop fashion, and by default every LSR in the LDP domain will become an ingress router
to all other routers. Once this process is repeated for each router, there will be a full-mesh of LSPs from every LDP router to
every other LDP router.
To prevent loops, LDP will refuse to accept a label mapping for a given prefix unless the interface on which the mapping is
received is on the best IGP path to that prefix. This on one side prevents loops, but on the other forces label-switched paths
to follow the IGP, precluding the possibility of traffic engineering.
The slide displays the LSPs which will be generated with R5 as egress point. Initially, R5 will allocate a label for its FECs; by
default, it will be label 3 for penultimate hop popping. Its neighbors, R3 and R2, will then allocate a free label from their label
allocation space, install the appropriate label operation (in this case, POP) and forward the label mapping to their neighbors.
The process is then repeated, and the end result will be that each router will then have an LSP to transport traffic by label
switching up to R5.
By default, the Junos OS implementation of LDP advertises a single prefix, the router’s loopback address. This can be
changed by configuring an egress policy.

LDP Message Types

LDP uses several messages types to establish mappings and report errors. All LDP messages have a common structure that
incorporate a type/length/value (TLV) encoding scheme.
• Discovery Messages: Discovery messages announce and maintain the presence of a router in a network.
Routers indicate their presence in a network by periodically sending hello messages. This hello message is
encapsulated within a User Datagram Protocol (UDP) packet that is sent to the LDP port (646) using the
multicast all-routers group address, 224.0.0.2. The use of a link-local multicast address limits neighbor
discovery to directly connected peers. Extended LDP neighbor discovery is discussed on a subsequent page.
• Session Messages: Session messages establish, maintain, and terminate sessions between LDP peers. When a
router establishes a session with another router learned through hello exchanges, it uses the LDP initialization
procedure over a Transmission Control Protocol (TCP) transport. Note that the higher IP address is responsible
for establishing the TCP session. When the initialization procedure completes successfully the two routers are
LDP peers and they can begin the exchange of advertisement messages.
• Advertisement Messages: Advertisement messages create, change, and delete label mappings for FECs.
Requesting a label or advertising a label mapping to a peer is a decision made by the local router. In general,
the router requests a label mapping from a neighboring router when it needs one and it advertises a label
mapping to a neighboring router when it wants the neighbor to use a label.
• Notification Messages: Notification messages convey advisory and error related information. LDP sends
notification messages to report errors and other events of interest.

LDP Message Types (contd.)
There are two kinds of LDP notification messages:
1. Error notifications: signal fatal errors. If a router receives an error notification from a peer, it terminates the LDP
session by closing the TCP transport connection and discarding all label mappings learned that were learned
through that session.
2. Advisory notifications: pass information to the router about the LDP session, and do not indicate a fatal error
nor do they terminate the session.

Hello-Based Neighbor Discovery

The discovery process can either send a hello message to 224.0.0.2 (basic discovery) or to a specific address (extended
discovery), in both cases using UDP and port 646. 224.0.0.2 is the all routers on this subnet multicast address. A station’s
response to a hello message indicates its desire to establish an LDP session with the neighboring router.
The transport address is used to determine which side is active. The transport address is placed into the Hello message as a
transport address object. If the transport address object is not specified, the source address of the hello packet is used to
determine it.

Session Establishment
The router with the numerically highest IP address is responsible for initiating the LDP TCP session. After the TCP 3-way
handshake has been completed, the LDP session can be established.

LDP Label Distribution

LDP labels are assigned sequentially, starting from the egress router, and moving upstream.
In this example, you can see the creation of a series of LSPs from each of the routers R4, R3 and R2 to the router on the
right, R1.
R1 will advertise a prefix (in this case, its loopback address 10.0.0.1) with a label of 3 (implicit null), which will cause the
penultimate router to remove the MPLS header (penultimate hop popping). R2 will receive this label mapping, and perform
two operations
• Install in its inet.3 table the prefix 10.0.0.1/32, with no label (due to penultimate-hop popping) and a
forwarding action of “send to R1”.
• Allocate a new label from its free label space (in this case, 252), and advertise the label mapping [prefix
10.0.0.1, label 252] to R3, after installing a label operation of “pop, send to R1” for label 252 in its mpls.0
table.
R3 will receive this label mapping, and will repeat again the two steps:
• Install into its inet.3 table the prefix 10.0.0.1/32, with a forwarding action of “push 252, send to R2”.
• Allocate a new label from its free label space (in this case 917), and advertise on the label mapping (10.0.0.1,
917) to R4, after installing a label operation of “swap 252, send to R2”.
Now R3 has a LSP to the prefix announced by R1, 10.0.0.1/32.

LDP Label Distribution (contd.)
The process will continue, radiating away from the egress; at the end, every router will have a LSP that brings traffic to the
prefix announced by R1. In other words, a many-to-one tree of LSPs with R1 as root will be created.
Note that this example is simplified, as it focuses on a single prefix; in fact, every LSP speaker will both relay received label
mappings and add their own mappings. So if, as is the default, every router advertises its own loopback address, at the end
of the process every router will have an LSP towards every other router’s loopback address.
Note that this label allocation mechanisms makes the protocol extremely scalable in terms of number of LSPs. Unlike what
happens with RSVP, there is no need to maintain or refresh a session for each LSP. The price of this scalability is lack of
control: LSPs will only follow IGP best paths, making traffic engineering impossible.

Session Maintenance
An LDP peer must receive an LDP packet every keepalive period to prevent the tear down of neighbor state. Any LDP protocol
message is acceptable for keepalive purposes, so keepalive messages are sent only in the absence of other LDP traffic.
Either end can shut down the session by issuing a shutdown message. If a router has multiple links to an LDP peer then
hellos are sent across all of the links. As long as one of the links can continue to exchange hellos, the LDP session remains
active.
The LDP hello messages enable LDP routers to discover one another and to detect the failure of a neighbor, or the link to
that neighbor. Hello messages are sent periodically on all interfaces on which LDP is enabled. By default, LDP sends hello
messages every 5 seconds. This value can be configured depending on the network requirements.
The hold time determines how long a router can wait for a hello message before declaring the neighbor lost. The configured
value is sent inside of hello messages to inform the receiving router how often it should expect to receive a hello; this
mechanism means that hello intervals do not need to be the same between neighbors. The default hold time is 15 seconds;
this value represents the recommended setting of three times the hello interval.
You can control the LDP transport address, that is the address used by the TCP session. You can configure the transport
address globally for all LDP sessions or for each interface independently. If you select interface, the interface address is
used as the transport address for any LDP sessions to neighbors that are reachable over that interface.
You cannot specify interface when there are multiple parallel links to the same LDP neighbor because the LDP specification
requires that the same transport address be advertised on all interfaces to the same neighbor. If LDP detects multiple
parallel links to the same neighbor, it disables interfaces to that neighbor one by one until the condition is cleared.

A Functional LDP Configuration

The minimal LDP configuration consists only in listing the interfaces on which you want to run LDP at the [edit protocol
ldp] level. Of course, before this you will need to enable MPLS frame processing on the interfaces, which means both
configuring family mpls at the logical unit level and listing the interface again at the [edit protocols mpls] level.
By default, the Junos OS implementation of LDP only advertises the primary loopback address; this behavior can be changed
by means of an egress policy, which will be described later.

MD5-Based Authentication for TCP transport

It is possible to authenticate an LDP session with the TCP MD5 signature option, and this provides some protection against
possible denial-of-service attacks targeted against LSRs. However, this comes at a cost: it is not possible to either introduce
authentication or change key without causing the LDP session to go down. The fact that there is no easy way to change keys
without disrupting existing sessions limits the usefulness of this mechanism.

A More Flexible Authentication Scheme

To overcome the limitations of the TCP MD5 signature (option 19), a new, more flexible authentication method has been
developed: TCP authentication (option 29).
Its big advantage is the possibility of hitless key rollover, i.e. of changing the key without causing LDP sessions to go down.
From a configuration point of view, instead of a single key you define a keychain with multiple keys, each with its own start
period. A tolerance period allows multiple keys to be accepted during transition from one key to the other.

LDP Policies
Differently from most other protocols which typically use two types of policy (import and export), LDP can be configured to
use three types of policy:
• Import policy: can be used to filter and control the label mappings (that is, the [prefix, label] pairs) that you are
willing to accept from your neighbors.
By default a router will accept all label mapping from its neighbors.
• Export policy: they are typically used to restrict the label mapping you advertise to your neighbors. This can be
useful in many scenarios where you would need to reduce the number of label mappings you advertise from the
core towards an access network.
By default a router will advertise all its LDP mapping to its peers.
Note that a LDP export policy behaves differently from export policies from most other protocols. Specifically,
you cannot use an export policy to redistribute routes from other protocols into LDP.
• Egress policy: this third policy allows to advertise additional label mappings, a function that is very similar to the
one of export policies in other protocols. For example, you could write a policy that matches your interface
routes; if you apply it as an egress policy, the router will advertise a label mapping for all directly connected
networks.
The default egress policy is to advertise a single prefix: the router’s primary loopback address.

LDP Tunneling Allows to Combine RSVP Traffic Engineering with LDP Label Distribution
LDP tunneling allows to combine RSVP-based traffic engineering with LDP-style label distribution. It is often used in
core-access networks, where RSVP is used for network optimization across the core, while LDP is used to distribute a large
amount of labels to access LSRs providing different services, for example MPLS-based VPNs.
LDP tunneling requires two LSPs, i.e. a bidirectional RSVP path, between endpoints. In this example, two LSPs exist between
R2 and R7, and a targeted LDP session between the routers’ loopbacks allows the two routers to exchange LDP labels.
Traffic across the RSVP core will use two stacked labels: an inner LDP label which will be preserved across the core, and an
outer RSVP label which will typically be subject to swap operations at every hop.

LDP Tunneling Configuration

To configure LDP tunneling between two endpoints, only two steps are needed:
• The loopback interface needs to be running LDP; this is needed in order to establish the targeted LDP session.
• The RSVP LSPs between the two endpoints need to be configured with the ldp-tunneling keyword.
Once these requirements are met, the targeted LDP session can be established and begin to exchange labels.

Graceful Restart Maintains Forwarding State During a Restart or a Reboot

The Junos OS supports LDP graceful restart as defined in RFC 3478: Graceful Restart Mechanism for Label Distribution
Protocol. LDP graceful restart is enabled when you add the graceful-restart statement to the main routing instance at
the [edit routing-options] hierarchy, which enables graceful restart on all protocols that support the capability. In
operation, a router makes its LDP graceful restart capabilities known through the inclusion of the Fault Tolerant TLV in its
session initialization messages.
By default, both graceful restart and helper mode are enabled for LDP when the graceful-restart statement is added
to the main routing instance. After a restart, the local router signals that it was able to preserve its forwarding state by
sending a nonzero recovery-time TLV in session messages to all neighbors. Neighbors with LDP helper mode enabled
maintain the label mappings they last advertised to the restarting peer. When the LDP session is reestablished, the retained
labels are readvertised (using mapping messages), which allows the restarting router to refresh all label bindings that are
still valid (nonrefreshed labels are marked as stale and flushed).
The result is that the restarting router’s signaling plane can be brought back into its pre-restart state, while forwarding
continued undisturbed.
As mentioned earlier, LDP graceful restart and helper modes are enabled by default when graceful restart is configured. You
can explicitly disable of LDP graceful restart and recovery, as well as prevent the router from performing helper mode
function to a restarting router.

Verify LDP Graceful Restart

The slides shows the output of show ldp session command with the detail switch, which can be used to verify LDP
graceful restart.

Useful LDP Operational Mode Commands

This slides shows a summary of useful LDP-related operational mode commands. We will look at them in more detail in the
following slides.

Checking Interfaces, Neighbors, and Sessions

To check the state of the LDP protocol and to verify its correct operation, it is often a good idea to start by verifying the state
of each neighbor using these three commands:
• show ldp interface: it is used to check which interfaces the LDP protocol is running on, as well as the
number of neighbors seen behind each interface.
• show ldp neighbor: lists the LDP neighbors.
• show ldp session: shows the status and hold time of each active LDP session, together with the
advertising mode. Using the detail modifier allows to display more information about the session, including
how long it has been up, the reason of the last LDP-down event and the number of flaps.
Here is an example:
user@R2> show ldp session 172.17.20.1 detail
Address: 172.17.20.1, State: Operational, Connection: Open, Hold time: 25
Session ID: 172.17.20.2:0--172.17.20.1:0
Next keepalive in 5 seconds
Active, Maximum PDU: 4096, Hold time: 30, Neighbor count: 1
Neighbor types: discovered

Checking Interfaces, Neighbors, and Sessions (contd.)
Keepalive interval: 10, Connect retry interval: 1
Local address: 172.17.20.2, Remote address: 172.17.20.1
Up for 01:12:59
Last down 01:13:01 ago; Reason: received notification from peer
Number of session flaps: 1
Capabilities advertised: none
Capabilities received: none
Protection: disabled
Session flags: none
Local - Restart: enabled, Helper mode: enabled, Reconnect time: 60000
Remote - Restart: enabled, Helper mode: enabled, Reconnect time: 60000
Local maximum neighbor reconnect time: 120000 msec
Local maximum neighbor recovery time: 240000 msec
Local Label Advertisement mode: Downstream unsolicited
Remote Label Advertisement mode: Downstream unsolicited
Negotiated Label Advertisement mode: Downstream unsolicited
MTU discovery: disabled
Nonstop routing state: Not in sync
Next-hop addresses received:
10.1.0.2
10.2.0.2
172.17.20.1
172.17.23.1
172.17.23.5

Verify the Label Mappings

It is possible to see the actual label mappings sent and received from a LDP neighbor with show ldp database
session <session>.
The output of the command is divided in two parts: the input label database, which lists all label mappings received from a
peer, and the output label database, the label mapping advertised to a peer.
In the example, checking the input database shows that we are receiving from neighbor 172.17.20.1 a label of 3 for its own
loopback, a label of 299888 to reach 10.1.20.1/32, a label 299872 to reach 10.2.20.1/32 and so on.
If you instead check the output database, you can see that the router is advertising all its labels mappings to every LDP
neighbor. This means that even the label that we allocated for the prefixes we received from a neighbor are sent back to that
neighbor. As an example, we received with a label of 3 for 172.17.20.1, then allocated a new local label (303056) for this
destination, and advertised it back to 172.17.20.1. This label will not be used for forwarding, nor advertised back further,
since all mappings are checked against the IGP, and are discarded if they do not follow IGP best paths, to prevent loops.

Checking LDP Reachability

We briefly mentioned that all LSP egress points are stored in the inet.3 table. To quickly find out all the LDP LSP
destinations (that is, all LDP egress points) a very handy and useful command is show route protocols ldp table
inet.3.
Omitting table inet.3 causes the command to print all LDP-installed entries, including labels advertised for transit. This
might be too verbose, especially if you are acting as transit for many LSPs.

Displaying Label Utilization

The show mpls label usage command displays available label space as absolute value and as a percentage of the
total. In the example. you can see the global space is divided in sections, each of them dedicated to a set of features.

We Discussed:
• The two label distribution protocols that the Junos OS supports;
• The configuration elements needed to implement RSVP or LDP to dynamically signal a LSP
• The capabilities of both LDP and RSVP when using the Junos OS.

Review Questions
1.
2.
3.

Lab: Label Distribution Protocols


1.
The only router that requires configuration is the ingress router. The other routers need to have protocols MPLS and RSVP
configured but do not need configuration specific to the label-switched-path.
2.
There are many RSVP Objects. We discussed the SESSION, LABEL_REQUEST, EXPLICIT_ROUTE (ERO), RECORD_ROUTE
(RRO), SESSION_ATTRIBUTE, RSVP-HOP, and the LABEL objects within this chapter.
3.
No. The Junos OS does not support traffic engineering for LDP signaled LSPs. You can however, us LDP tunneling over RSVP
traffic engineered LSPs to apply traffic engineering to LDP traffic.

Chapter 4: LSPs and Routing Table Integration

We Will Discuss:
• The use and role of the inet.3 table in the Junos OS;
• How MPLS LSPs can be used for BGP next-hop resolution; and
• How the default traffic engineering behavior of the Junos OS can be changed.
Chapter 4–2 • LSPs and Routing Table Integration www.juniper.net

Mapping BGP Next Hops to LSPs

www.juniper.net LSPs and Routing Table Integration • Chapter 4–3

BGP Traffic Engineering

Without a doubt, BGP RSVP-based traffic engineering was one of the first and most successful MPLS applications,
contributing substantially to the success of the first Juniper Networks product, the M40 Internet Router.
The possibility of specifying the path traffic should take without the limitations of IGP metrics allowed Service Providers to
mitigate the impact the explosive growth in Internet traffic at the end of the 1990s and in the early 2000s. This capability
was immediately embraced and widely deployed by many carriers: it allowed them a relatively simple solution to utilize their
growing network capacity in an efficient way.
It is partly due to this history that on routers running the Junos OS BGP traffic engineering is on by default, and does not
require any special configuration past LSP and BGP session establishment.

Structure of a BGP Route

A BGP route is a composite object: it includes a number of attributes, classified in mandatory and optional. Among the
mandatory attributes, probably the most important is the next-hop, the gateway to which traffic should be delivered to reach
the route destination.
The next-hop is, in the case of IBGP, typically not directly connected. Because of this, the BGP next-hop needs to be resolved,
that is, translated in an actual forwarding address where to send traffic. If MPLS is not enabled, this resolution is typically
done using the IGP. But enabling MPLS changes next-hop resolution, as we will see in the following slides.

Junos Routing Tables Review

Before going ahead, it is worth to do a small review of the main Junos routing tables.
In summary, three tables are important when you configure MPLS along with other routing protocols: inet.0, inet.3, and
mpls.0:
• inet.0: The primary IP unicast routing table. IP forwarding is by default done by selecting the best route within the
inet.0 table.
• inet.3: The table of LSP egress points. Whenever a new LSP is established, its egress point is installed into
inet.3, so that the different MPLS application can find it and use it.
• mpls.0: The MPLS label switching table. Transit and sometimes egress routers use the contents of this table
to swap and pop labels as needed.

Default BGP Next-Hop Resolution

The Junos OS BGP implementation makes traffic engineering possible by using both the inet.0 and inet.3 tables when
resolving next-hops.
When the same prefix appears in both the inet.0 and inet.3 tables, BGP will select the route with the lowest preference.
With default protocol precedences, this results in the selection of an LSP over a normal IGP path. In the event of a preference
tie, entries in inet.3 are preferred over inet.0 entries.
In other words, if a BGP next-hop also happens to be the egress point of an LSP, then the LSP will be used as forwarding
next-hop. This opens the possibility of fine-grained traffic engineering for BGP destinations, since it is possible to control the
path a RSVP LSP takes using an ERO,

Route Resolution Example


A Simple BGP Transit Scenario

In this simple example, a prefix originated in AS65511 is advertised through R4 to AS65512. The default rules for handling
the BGP next-hop attribute change according to the type of BGP session.
• For EBGP session, the next-hop is changed by default to be the advertising router.
In the example, R4 will see the border router in AS65511 as next-hop, independently to what the original
next-hop within AS65511 was.
• For IBGP sessions instead, the next-hop attribute is preserved by default. So R4 will propagate the next-hop as it
is, and R1 will receive the same next-hop as it is seen on R4: the far-end of the link between the two
autonomous systems, which typically causes the next-hop to be unusable: the inter-as link is not running IGP. In
this scenario, unless some additional steps are taken, the only router that will be able to use the routes
advertised by AS65511 is R4. The routes will instead be “hidden” on all IBGP peers of R4.

Hidden Routes Due to Unreachable Next-Hop

You can use the show route hidden command in order to display hidden routes. In the example, the prefix advertised by
AS65511 is seen on R1 as hidden, with a next-hop marked as unusable. R1 does not know how to deliver traffic to the
route’s protocol next-hop.
To examine routes that have been marked as hidden due to next-hop resolution failure, you can also use the command show
route resolution unresolved. In the example below, you can clearly see that the protocol next-hop is in fact on the
inter-AS link.
user@R1> show route resolution unresolved
Tree Index 1
Tree Index 2
Tree Index 3
Tree Index 4
64.25.1.0/24
Protocol Nexthop: 182.19.200.1
Indirect nexthop: 0x0 - INH Session ID: 0x0

Two Solutions for Hidden Routes

There are two standard solutions to the problem of unresolved next-hop:
1. Apply a policy on IBGP sessions so that the next-hop is changed to be the loopback address of the advertising
router. This can then be resolved using the IGP. This solution is by far the preferred one. Not only it helps with
scalability by keeping the number of IGP prefixes to the minimum, but it is also facilitates MPLS RSVP-based
traffic engineering.
2. Distribute the inter-AS link in the IGP, leaving the next-hop unchanged. This is generally not recommended.
Distributing inter-AS links in the IGP can contribute to its instability, as router LSAs (OSPF) or Link-State PDUs
(ISIS) need to be re-generated whenever an inter-AS link goes down.
Moreover, in many cases the addressing of the inter-AS link belongs to the IP space of the peer AS. Distributing
extraneous, unnecessary prefixes in the IGP is technically possible, but not optimal for scalability.

Configuring next-hop self on Border Routes

After next-hop self is applied, the protocol next-hop becomes the advertising router. In this case, the next-hop will be
the loopback of R4.
Since loopback addresses are distributed in the IGP, the route will cease to be in hidden state and become active.
On Juniper routers, applying next-hop self is done using an export policy towards the IBGP peers:
user@R4> show configuration policy-options
policy-statement next-hop-self {
then {
next-hop self;
}
}

Configuring next-hop self on Border Routers (contd.)
After being defined, the policy is then applied to IBGP peers:
user@R4> show configuration protocols bgp

group ebgp {
peer-as 65511;
neighbor 182.19.200.1;
}
group ibgp {
type internal;
local-address 172.17.20.4;
export next-hop-self;
neighbor 172.17.20.1;
neighbor 172.17.20.2;
neighbor 172.17.20.3;
}
The route becomes active as soon as the policy is applied, and that the next-hop is changed to the loopback of R4:
lab@R1> show route protocol bgp detail
inet.0: 26 destinations, 26 routes (26 active, 0 holddown, 0 hidden)

64.25.1.0/24 (1 entry, 1 announced)
*BGP Preference: 170/-101
Next hop type: Indirect, Next hop index: 0
Address: 0x31d3af0
Next-hop reference count: 2
Source: 172.17.20.4
Next hop type: Router, Next hop index: 677
Next hop: 172.17.23.2 via ge-1/0/5.0, selected
Session Id: 0x1a5
Protocol next hop: 172.17.20.4
Indirect next hop: 0x3256cc0 1048574 INH Session ID: 0x1a8
State: <Active Int Ext>
Local AS: 65512 Peer AS: 65512
Age: 29:26 Metric2: 20
Validation State: unverified
Task: BGP_65512.172.17.20.4
Announcement bits (2): 0-KRT 5-Resolve tree 4
AS path: 65511 I
Accepted
Localpref: 100
Router ID: 10.10.10.10

Establishing an LSP
After next-hop self has been configured, it is sufficient to establish a LSP towards R4’s loopback address to be able to
do traffic engineering.
Remember that LSPs egress points are stored into the inet.3 table, with the preference of the label distribution protocol
used to create it. If we create, as in this example, a LSP to R4’s loopback address, then R1 will have two entries for R4’s
loopback: one installed into the inet.0 table and created by the IGP, and a second one installed into inet.3 and created
by RSVP.

BGP Next-Hop Resolved through an LSP

Due to the default Junos behavior, which allows BGP next-hops to be resolved both in inet.0 and inet.3, the BGP route
(still installed in inet.0 and used for forwarding) will use a MPLS LSP to reach its next-hop.
Since the path taken by a RSVP LSP can be influenced using Explicit Route Object, we can now control the path of BGP
transit traffic, regardless from IGP metrics. This opens up a whole range of additional possibilities for traffic engineering and
network optimization.
If the LSP for any reason goes down, the BGP next-hop can still be resolved using the IGP. IP traffic will still be able to reach
its destination through the IGP best path to the BGP next-hop.

With IGP-Passive, BGP Next-Hop Is Resolved Using IGP

As mentioned in a previous slide, there are several reasons to keep inter-AS links out of the IGP. An additional reason is that
it interferes with BGP traffic engineering.
If, instead of using next-hop self, the inter-AS link is put in the IGP as a passive interface, then the BGP next-hop will remain
the remote side of the inter-AS link. This is not the egress point of any LSP, so is not present in the inet.3 table. Because of
this, even if the route is active, the next-hop will be resolved using the IGP and not using MPLS.

Binding Additional Prefixes to LSPs


Additional Prefixes in the inet.3 Table

We already mentioned that the inet.3 table contains each LSP’s egress point.
This is a good default, but sometimes it is not enough. Sometimes you need to inform a router about additional destinations
reachable using a LSP. Junos provides a way of binding additional prefixes to a LSP.
The actual mechanism and configuration varies according to the protocol used to signal the LSP. For RSVP, you can use the
install statement on the ingress router, while for LDP you need to write an egress policy and apply it on the egress router.
This could in principle be used to avoid the need of next-hop self to resolve BGP routes: by installing the inter-AS link in the
inet.3 routing table, you would be able to resolve the unchanged BGP next-hop using a LSP.
While this is surely possible, it is not considered best practice. The main reason is that this typically does not eliminate the
need of distributing the inter-AS link in the IGP, with negative consequences for scalability and stability. For RSVP-based
LSPs, the inter-AS link may need to be in the IGP to allow delivery of transit traffic using best IGP metrics, in case the LSP
goes down. For LDP, instead, distributing the inter-As link in the IGP is a protocol requirement.

Installing Additional Prefixes for RSVP LSPs

In this example, an additional /24 prefix is bound to an LSP and installed into the inet.3 table. As soon as the LSP is
signaled MPLS applications, including BGP traffic engineering, will became aware of the fact that the 10.0.0.0/24 prefix can
be reached using the LSP named to-R1.
If you add the keyword active after the prefix, then the prefix will be installed into the inet.0 table rather than the
inet.3 table. The LSP will then be used for normal unicast forwarding, even without BGP. Since BGP resolves its next-hops
both in inet.0 and inet.3, a prefix installed with the active keyword can still be used for BGP next-hop resolution. In a
way, this configuration achieves a similar result to a static route with a RSVP LSP as next-hop.

Installing Additional Prefixes for LDP LSPs

On Juniper routers, the default behavior for LDP is to advertise a single label for the router’s loopback address. This can be
changed using an egress policy, which can select additional routes, provided they are active in the routing table, and
advertise them to LDP neighbors.
One important point to remember is that if you specify an egress policy it will replace the existing one. If you need to install
additional prefixes and keep the default loopback advertisement, your policy will need to explicitly match both.
A second point to remember is that, due to the LDP protocol operation, any prefix that you want to advertise using LDP must
to be present in the IGP too, otherwise all other LDP neighbors will just ignore the label advertisement.

install active Versus Static Routes

Using install active achieves similar results as a static route with a LSP next-hop. However there are two main
differences:
• The protocol, which will be either RSVP or static. This can influence redistribution policies.
• The preference, which will be 7 or 5. A static route will by default take priority over an active RSVP route.
From the configuration point of view, a static route also allows setting a number of other attributes, making it a slightly more
flexible choice.

Altering the Default Traffic Engineering Behavior

The slide lists the topic we discuss next.

Default Junos Traffic Engineering Behavior

In the previous slides, we examined the default Junos traffic engineering behavior. Junos installs LSPs egress points in the
inet.3 table, and uses them only for BGP next-hop resolution. Other internal destinations, typically not associated with
BGP next-hops, keep on being forwarded using the best IGP path, and do not use LSPs.
Altering Default Behavior

While the default behavior is very useful in a wide range of situations, it is possible to change it by selecting one of several
pre-defined traffic engineering settings. The desired behavior can be selected at the [edit protocols mpls
traffic-engineering] hierarchy. We will now examine what each of the possible traffic engineering option does.

Default Behavior: BGP Only

The default behavior is to use MPLS only for BGP next-hop resolution, using the inet.3 table. In this case, MPLS will be
used for forwarding only when traffic is following a BGP route which has a MPLS egress point as next-hop.
It is worth noting that, in addition to BGP, a number of other applications, if configured, will make use of MPLS LSPs. Among
those, MPLS-based Layer 2 and Layer 3 VPNs, Layer 2 circuits, Circuit Cross Connect (CCC) and so on. For more information
about MPLS applications, please refer to the Junos OS VPN configuration guide and the Junos MPLS Applications guide, both
available on the Juniper website.

Traffic Engineering bgp-igp

This configuration installs all MPLS routes and egress points into the inet.0 table rather than in inet.3, which will
remain empty. This setup is sometimes seen, together with LDP egress policies redistributing interface routes, when it is
desired to use MPLS to forward traffic for both internal and external destinations.
However, the fact that inet.3 is not used prevents other MPLS applications (e.g. VPNs) from working. For this reason, the
usefulness of this option is rather limited.

Traffic Engineering bgp-igp-both-ribs

This option addresses some of the limitations of traffic-engineering bgp-igp. As the names implies, with this
setting the MPLS routes and egress points are installed in both the inet.0 and the inet.3 table. This allows MPLS to be
used for internal forwarding, while preserving the possibility of configuring MPLS services and applications which make use
of the inet.3 table.

Traffic Engineering mpls-forwarding

This mode of operation completely changes the way a router operates. From a practical point of view, this configuration will
work in a way that is similar to bgp-igp-both-ribs.
However, there is a very important difference. The router will keep two set of routes: a set of routes to be used for forwarding
only, which will include MPLS egress points, and a set of ordinary routes which will be computed by routing protocols, e.g.
BGP, IGP, static routes and so on. As soon as the command is configured, all CLI commands that display routing information
will start to display the two different route types.
This mode of operation has been designed to work around a problem encountered when configuring
bgp-igp-both-ribs: the better protocol preference of MPLS-related protocols can cause MPLS routes to “overshadow”
IGP and BGP routes, affecting policies and the redistribution between protocols.

MPLS Forwarding: Operational Commands

The slide shows how the output of the show route command changes after enabling traffic-engineering
mpls-forwarding.
For each prefix, the command will show two entries: the first one, preceded by the @ symbol, will be the usual IGP, BGP or
static route, which will be considered and used for redistribution. The other entry, preceded by the # symbol, will be the one
used for actual traffic forwarding.

We Discussed:
• The content of the inet.3 table, and how it is used by different applications;
• The role and use of MPLS LSPs for BGP next-hop resolution; and
• Different alternatives to the default Junos OS traffic engineering behavior.

Review Questions
1.
2.
3.

Lab: Routing Table Integration


1.
False; several other functionalities make use by default of the inet.3 table; among them, several types of VPNs (e.g. VPLS,
Virtual Private LAN Service) and layer-2 circuits (transport of layer-2 frames over MPLS.
2.
For RSVP-signaled LSP you can use the install <prefix> statement within the LSP definition; for LDP-signaled LSPs
you can use an egress policy. In this case, the prefixes you want to distribute must also be in the IGP.
3.
The difference is that with bgp-igp, the inet.3 table is not used and is left empty, preventing several MPLS applications
from working correctly. With bgp-igp-both-ribs, the LSP egress points are copied in both inet.0 and inet.3.

Chapter 5: Constrained Shortest Path First

We Will Discuss:
• The path selection process of RSVP without the use of the Constrained Shortest Path First (CSPF) algorithm;
• The interior gateway protocol (IGP) extensions used to build the traffic engineering database (TED);
• The CSPF algorithm and its path selection process;
• Administrative groups and how they can be used to influence path selection; and
• The behavior of inter-area traffic engineered label switched paths (LSPs).
Chapter 5–2 • Constrained Shortest Path First www.juniper.net

RSVP Behavior Without CSPF

www.juniper.net Constrained Shortest Path First • Chapter 5–3

RSVP Behavior Without CSPF

Without IGP traffic engineering extension, RSVP can only reserve bandwidth hop by hop. If at some point one of the nodes
does not have enough available bandwidth, the LSP setup process just fails. Even if potentially there could be other
alternative paths with enough bandwidth, RSVP on its own cannot be aware of them.
IGP Traffic Engineering extensions were developed to resolve this specific problem, to make RSVP aware of the full MPLS
topology, including available bandwidth on each link, so that each LSR could make better use of network capacity.

Using Traffic Engineering Extensions to the IGP to Improve Bandwidth Utilization

A key driver in MPLS adoption was the possibility of making efficient use of available network resources. It is with this goal in
mind that TE extensions were first developed. The main idea was to extend the IGP (OSPF and ISIS) to distribute information
about the MPLS topology, including how much bandwidth was available on each link. This allows an ingress node to compute
an optimal path, and then request RSVP to signal an LSP on that path using a strict ERO object.
In the example, due to IGP extensions the ingress router, R3, is aware that there is not enough capacity on the link between
R5 and R6, and will instead compute a path via R1, R2 and R4. IGP TE extensions effectively allowed the ingress router to
“discover” and use available bandwidth in the network.

Today, the Most Important Application of CSPF Is Traffic Protection

Even if it was originally developed to improve efficient network utilization, today’s central application for CSPF is traffic
protection, the set of features that allow MPLS-enabled networks to minimize packet loss after a failure. Some of the most
widely used protection methods for RSVP or LDP-signaled LSPs (like fast reroute and link protection) use the CSPF algorithm
to find detours and bypasses around a failure.

CSPF Algorithm
This slide highlights the topic we discuss next.

IGP Extensions
Both OSPF and IS-IS can propagate additional information through some form of extension. IS-IS carries different parameters
in type/length/value (TLV) tuples, which are propagated only within a level. OSPF, instead, uses Type 10 opaque LSAs to carry
traffic engineering extensions. Type 10 LSAs have an area flooding scope, meaning that the information is propagated within
an area. OSPF traffic engineering extensions do not cross area border routers (ABRs). The MPLS Traffic Engineering
Information carried by IGP extensions is defined in RFCs 3630 and 4203 for OSPF, and RFCs 3784 and 4205 for IS-IS.

IGP TE Extensions Example: IS-IS

The TLVs listed here are based on IS-IS traffic engineering extensions. OSPF supports more or less the same functionality,
the primary difference is how the extended information is encoded and propagated. ISIS will use TLVs in a link-state PDU,
while OSPF will use TLVs within an opaque LSA. Traffic engineering extensions are active by default in ISIS.
• Router ID (TLV 134): Single stable address, regardless of node’s interface state.
• Extended IP Reachability (TLV 135): One bit used for route leaking (up/down bit); extends metrics from 6 bits to
32 bits.

IGP TE Extensions Example: IS-IS (contd.)
• Extended IS Reachability (TLV 22): Contains information about a series of neighbors. Consists of the following
sub-TLVs:
– IPv4 Neighbor Address (Sub-TLV 8).
– Maximum Link Bandwidth (Sub-TLV 9): A 32-bit field, Institute of Electrical and Electronics Engineers
(IEEE) floating point format. Units are bytes per second and unidirectional.
– Maximum Reservable Bandwidth (Sub-TLV 10): A 32-bit field, IEEE floating point format. Units are bytes
per second and unidirectional. Supports over subscription (can be greater than link bandwidth).
– Unreserved Bandwidth (Sub-TLV 11): A 32-bit field, IEEE floating point format. Units are bytes per second.
A value is specified for each priority level 0 through 7.
– Traffic Engineering Default Metric (Sub-TLV 18): A 24-bit unsigned integer.
– Resource Class/Color (Sub-TLV 3): Specifies administrative group membership (also known as affinity
class). Up to 32 different groups. Each group is represented by a different bit.

IGP TE Extensions Example: OSPF

Opaque LSAs carrying Traffic Engineering extensions are silently discarded by non-traffic-engineering-aware routers in
accordance with opaque LSA processing rules. OSPF traffic engineering extensions include the following TLVs.
• Router TLV: Stable IP address of advertising router.
• Link TLV: Composed of the following sub-TLVs:
– Link Type: Point-to-Point or multiaccess.
– Link ID: Identifies other end of link. A designated router is identified if the link is used for multiaccess.
– Local Interface Address: IP address of the link; advertising router address if unnumbered link.
– Remote Interface IP Address: Neighbors’ IP address; first two octets 0 if unnumbered, remaining octets
are local interface index assignment. This sub-TLV and local address used to discern multiple parallel
links between systems.
– Traffic Engineering Metric: Link metric for traffic engineering. Might be different than the OSPF link
metric.

IGP TE Extensions Example: OSPF (contd.)
– Maximum Bandwidth (Unidirectional): A 32-bit IEEE floating point format. Bytes per second.
– Maximum Reservable Bandwidth: A 32-bit IEEE floating point format. Over subscription supported. Bytes
per second.
– Unreserved Bandwidth: Unreserved bandwidth for each of the eight priority levels. Bytes per second.
32-bit IEEE floating point format. Each value less than or equal to maximum reservable bandwidth.
– Resource Class/Color: Specifies administrative group membership (also known as affinity class). Up to
32 different groups. Each group is represented by a different bit.

The TED Is Used for Calculating MPLS Paths Across the Network
The IGP contains full information about the topology of the area (for OSPF) or of the level (for ISIS). Traffic engineering
extensions supplement this information, and maintain it up-to-date by re-generating and re-flooding link-state updates or
link-state PDUs when needed.
Information distributed by TE extensions includes the amount of free bandwidth, and the amount of bandwidth reserved at
each priority level. It is possible that a link may have no bandwidth available for a low-priority LSP, but still have available
bandwidth for a high-priority LSP, if LSP preemption is allowed.
Together with bandwidth-related data, the TED can also store administrative colors (also called link affinity), a feature which
allows a designer to specify a set of links that a given LSP should or should not traverse.

Examining the TED

You can analyze the content of the Traffic Engineering Database using the show ted database command. If you use as
argument the system-id (for ISIS) or router-id (for OSPF) of a node, the command will display all links in the TED terminating
on that node.
Using the extensive modifier will display, for each link, also the amount of free and reserved bandwidth at each of the
seven priority levels, as well as administrative colors (if assigned).
The Local: and Remote: fields specify IP address information about the link. Four different combinations of Local: and
Remote: values are possible.
• If both fields contain nonzero IP addresses, the link is a point-to-point link.
• If the both fields are 0.0.0.0, the link represents a pseudonode.
• If only the Remote: value is 0.0.0.0, the link is a LAN interface.
• Finally, if only the Local: value is 0.0.0.0, the link is an unnumbered interface.
In the example, we can see one link connected to a pseudonode. In other words, the link leads to a multi-access LAN where
a DR has been elected.

CSPF Is a Modified Shortest-Path-First Algorithm Which Operates with TED Data

The CSPF algorithm is an extension of the usual IGP SPF, designed to find paths meeting a number of constraints—for
example, on available bandwidth, or on a specific node the path should cross.
CSPF works by removing from the candidate topology all links which do not verify the user constraints (for example, all links
with not enough bandwidth). Then, on the remaining topology, the SPF algorithm is used to find out the optimal path.
The end result of this computation, if successful, is used to build a RSVP ERO object so that RSVP can signal the LSP along
the computed path. If the CSPF computation fails because there is no way of meeting all user constrains, the algorithm will
return an error, and the LSP will stay in down state.

CSPF Path Computation

The CSPF algorithm computes the path of LSPs one at a time, beginning with the highest-priority LSP, the one with the
numerically lowest setup priority value. Among LSPs of equal priority, CSPF begins with those that have the highest
bandwidth requirement.
For each LSP, the following sequence is executed:
1. Prune from the topology all links that do not meet the desired constraints on bandwidth, on administrative
groups etc.
2. If a path (a list of strict or loose hops the LSP should cross) has been specified:
a. Set P equal to the list of strict and loose constraints to be verified.
b. Calculate the shortest path to the first constraint in P, then add that path segment to the computed LSP
path.
c. Remove the constraint from P and prune all links crossed to verify it. This is to avoid traversing the same
link twice to verify two different constraints, creating a loop.
d. Repeat from step b until the list P is empty, and all path constraints have been verified.
e. On the remaining topology, after both links that did not meet initial requirements and links already
crossed to verify path constrains have been removed, compute the best path to the egress LSR.

CSPF Path Computation (contd.)
f. If multiple, equal-cost paths exist, pick the one with smaller number of hops.
g. If multiple, equal-cost paths with the same number of hops still exist, select according to a
user-configurable tie-break rule. If no tie-break rule is configured, the Junos OS will pick one of the
candidate paths at random.

Ingress LSR Operations

There are six primary aspects of the CSPF process from the perspective of the ingress label switching router:
1. Information Propagation: Traffic engineering extensions to either Intermediate System-to-Intermediate System
(IS-IS) or Open Shortest Path First (OSPF) carry traffic engineering topology information.
2. Information Storage: The router stores traffic engineering link-state information in the TED.
3. User Constraints: The user specifies constraints for a specific LSP through configuration settings.
4. Path Calculation: The CSPF algorithm finds the shortest path using only links that conform to a set of
user-provided constraints.
5. Explicit Route Generation: The router computes a strict ERO that describes the sequence of nodes and links
representing the shortest compliant path between ingress and egress LSRs.
6. RSVP-signaling: The router passes the computed ERO to RSVP for LSP signaling. Note that because the TED
contains a relatively up-to-date view of the entire network’s current state, a high probability exists that the
RSVP-signaled LSP will succeed. Recent changes in the state of the network might result in the TED being
slightly out of date, and this can lead to RSVP path signaling failures until the TED is again synchronized with
the real state of the network.

IGP Update Threshold

Distributing TE information in the IGP means that whenever bandwidth is allocated or freed, all nodes on the path need to
re-flood traffic engineering information to reflect the change in available bandwidth. This could lead to excessive flooding,
limiting IGP scalability.
As a compromise between having an accurate picture of the network and introducing excessive flooding, a LSR re-floods
updated bandwidth values only if capacity changes more than a configurable threshold (by default 10%).
Setting a higher threshold decreases flooding, but can increase the possibility of a mismatch between the content of the TED
and the actual state of the network. This inconsistency will resolve on its own as OSPF LSAs and ISIS LS PDUs age out and
are re-generated. Still, there is a window where a CSPF-computed LSA could fail to be signaled due to lack of bandwidth on
one of the downstream nodes.

Mitigating the Effect of TED Inconsistency

Due to the effect of the update threshold, the TED state may for a short period be inconsistent with the actual bandwidth
availability, This mismatch happens whenever bandwidth changes are below the update threshold.
This condition can lead to CSPF computing a path and RSVP failing to signal it with a no-bandwidth error. When this happens,
an additional mechanism is needed to prevent CSPF from re-computing the same path, which would fail again, and force it to
compute a different path which avoids the interface with no available bandwidth.
Negative Feedback: PathErr Message Handling

Junos OS automatically retains knowledge of RSVP PathErr messages for a short period of time, and adds a huge metric
penalty to the link which reported the error. This prevents CSPF from re-computing the LSP along the same path. By default,
the system maintains knowledge of PathErr messages for 20 seconds, configurable from 0 to 240 seconds in the [edit
protocols mpls] hierarchy with the rsvp-error-hold-time command.

CSPF Tie Breaking


CSPF Tie-Breaking Terms

The terms and relations shown on the slide are used by the description of CSPF tie-breaking rules. You should familiarize
yourself with these terms and formulas to understand the various CSPF tie-breaking behaviors available in Junos OS. We
explain these rules in the following pages.

CSPF Tie-Breaking Options

If more than one path is available after running CSPF, a configurable tie-breaking rule is applied. Three tie-breaking rules are
available: random, least fill, and most fill.
• Random: The default tie-breaking method is random, which chooses one of the qualifying paths at random. This
rule tends to place an equal number of LSPs on each link, regardless of the available bandwidth.
• Least fill: The least-fill option chooses the path with the largest minimum available bandwidth ratio. This rule
tries to equalize the reservation levels on each link.
• Most fill: The most-fill option prefers the path with the smallest minimum available bandwidth ratio. The
most-fill option tends to fully pack your lower bandwidth links first, such that your highest bandwidth links
remain available for LSPs with large bandwidth requirements. This is the main motivation for using this strategy.
Tie-Breaking Rule Configuration

To explicitly configure a tie-breaking behavior, include the random, least-fill, or most-fill statement at the [edit
protocols mpls label-switched-path path-name] hierarchy level. Note that you do not have to explicitly
configure random load balancing as it is the default.

Example: Least Fill Strategy

Because all four paths shown on the slide have equal metric cost, CSPF will select the path that has the greater available
bandwidth ratio. Remember that you are selecting the path that is least full on a percentage basis, that is, the path that has
the largest relative available bandwidth.
Amongst the two lower hop count links, the top path has the largest minimum available bandwidth ratio. Least fill is
desirable when you want to spread out your reserved bandwidth on all available links.

Example: Most-Fill Strategy

Because all four paths shown on the slide have equal metric costs, CSPF will select the path that has the least available
bandwidth ratio. Remember that you are selecting the path that is most full on a percentage basis—the one that has the
smallest relative available bandwidth. Amongst the two lower hop count links, the bottom path has the smallest minimum
available bandwidth ratio.
You might configure most fill load balancing when you want to maximize network utilization, so that more resources can
remain available for new LSPs with large bandwidth requirements.

Example: Relative Versus Absolute Bandwidth

As previously explained, if multiple equal cost feasible paths are found, the CSPF algorithm will select the paths with the
smallest hop count. This rules out the two middle links, so the least-fill tie-break rule will be applied only to the top and to the
bottom links.
The top link has an available bandwidth ratio of 95%, and the bottom link has an available bandwidth ratio of 80%.
Therefore, even though the absolute available bandwidth on the Gigabit Ethernet path is much greater than that of the Fast
Ethernet path, the LSP will be routed over the Fast Ethernet links due to the higher available bandwidth ratio.
The use of relative bandwidth can sometimes lead to counterintuitive results like these, where the lower path, despite having
the lowest available bandwidth ratio (80%), had in fact 800Mb/s of free bandwidth, while the top path, which had the
highest available bandwidth ratio (95%), in fact only had 95Mb/s of free bandwidth.

Administrative Groups

Administrative Group Overview

Administrative groups allow to tag each link with one or more groups (also called colors), and constrain the path of an LSP to
the set of links marked with a user-specified set of groups. Due to the way administrative groups are encoded, there can be
a maximum of 32 different groups. The administrative groups associated with each interface are communicated through the
extended IGP and stored in the TED. CSPF will then be able to use colors in its computation, as specified in the LSP
definition. The net result is that the routing of the LSP will be controlled by its need to avoid, or make use of, links with the
specified colors.

Administrative Groups Advertised by the Extended IGP

A traffic engineering aware IGP communicates the administrative group of each interface as a 32-bit (4 bytes) bit field. Each
of the bit represents a different administrative group.
Colors Can Be Associated with Descriptive Name

Each bit value can be associated in the configuration with a human-friendly name. This capability helps simplify router
management, as a descriptive name is easier to remember than a number. Group names can be any descriptive term you
want. Each link can have one or more bits enabled, and can therefore be associated with one or more colors simultaneously.
The colors advertised by each link are displayed in both hexadecimal and in symbolic form in the output of show ted
database extensive command. When multiple bits are set in the TED, the order of the colors displayed correlates to
the order of the bits that are set. When no colors are assigned, the 32 bits default to all zeros (0x00000000).
If you use administrative groups, you must configure them identically on all routers participating in an MPLS domain; failing
to do so can lead to CSPF failures which are sometimes difficult to troubleshoot. You can assign more than one
administrative group to each physical link, as well as leave links uncolored by not assigning them any administrative group
values.

Administrative Groups: Configuration

You can configure group names and their associated bit values at the [edit protocols mpls] level. The bit values can
range from 0 to 31. Note that the actual group name is local only, which means the user is responsible of making sure color
names and values are consistent among all routers in the traffic engineering domain. It is recommended to configure all
defined groups that are in use within the traffic engineering domain on all routers, even though a particular group might not
be used on a given router.
After defining all groups, it is possible to associate one or more groups to each router interface.
Remember that you can configure multiple groups on a single interface; in this example, the interface ge-1/0/0.220 has
been associated two administrative groups, gold and management.

CSPF Administrative Groups Constraints

When you configure an include-any list, only links that contain at least one of the specified administrative groups are
included in the SPF calculation. When you configure an include-all list, only links that contain all of the specified
administrative groups are included in the SPF calculation. Finally, when you configure an exclude list, links that contain
any of the specified administrative groups present are automatically excluded from the SPF calculation.
When you specify multiple conditions among include-any, include-all, and exclude lists for a given LSP, each link
considered in the SPF calculation must satisfy all conditions.
Changing an LSP's administrative group causes an immediate re-computation of its path, which may result in the LSP being
rerouted.

Displaying Administrative Group Assignments

You can verify the colors assigned to each MPLS-enabled interface using the show mpls interface command. The
command will display groups with their human-friendly name, as defined in the configuration.

Administrative Groups I: IGP Routing

In this initial example, you must determine the shortest path from A to I according to the IGP. Each link displays the
associated IGP metric value.
This calculation reflects normal IGP processing and, therefore, the default routing of an RSVP-signaled LSP. You can
influence LSP routing with the inclusion of administrative constraints, as is demonstrated in subsequent pages.

Administrative Groups I: Solution

This slide displays the solution to the question asked on the previous slide. In this case, the IGP’s shortest path has a metric
of 6 and consists of the path A, D, E, G, and I.

Administrative Groups II: Include-Any Constraints

The LSP definition in this example requires that the link include either the color gold or the color silver. The CSPF
algorithm begins by pruning the following links because they do not include the required colors: A-B, A-D, C-D, B-E, B-G, D-E,
E-G, D-H, F-H, G-H, or H-I. The links that do comply with the constraints are A-C, C-F, F-G, and G-I.
A shortest path is computed from the links that remain, which in this case yields only one viable path.

Administrative Groups II: Solution

This slide displays the solution to the question asked on the previous slide. In this case, the only path meeting the provided
include-any constraints consists of the path A, C, F, G, and I.

Administrative Groups III: Include-Any and Exclude Constraints

The LSP definition in this case requires that the link include either the copper or bronze colors, while also excluding the
admin color. Put another way, a qualifying link can include copper and exclude admin, or it can include bronze and
exclude admin. The CSPF algorithm begins by pruning the following links because they do not include the required colors:
A-C, A-B, C-F, C-D, F-G, F-H, and G-I.
The CSPF algorithm then prunes the following links because they are associated with an excluded color: D-H. Note that links
A-B and F-H are already excluded by virtue of the include-any constraint but that link D-H passes the include-any
constraint, and so it is not pruned until the exclude constraint is processed.
The links that pass both sets of constraints are A-D, D-E, E-B, B-G, E-G, G-H, and H-I. A shortest path is now computed from
the compliant links. In this case two possible paths exist: A-D-E-B-G-H-I, with a cost of 19, and A-D-E-G-H-I, with a cost of 13.

Administrative Groups III: Solution

This slide displays the solution to the question asked on the previous slide. In this case, between the two paths meeting both
the include-any and exclude constraints, the lowest-metric one is chosen. CSPF will return the path A, D, E, G, H, and I.

Administrative Groups IV: Include-Any and Exclude Constraints

The LSP definition in this case once again requires that the link include either the copper or bronze colors, while also
excluding the admin color. Note that the destination node and the cost of the G-H link has been changed from previous
examples.
The CSPF algorithm begins by pruning the following links because they do not include the required colors: A-C, A-B, C-F, C-D,
F-G, and F-H. The CSPF algorithm then prunes the D-H link because it is associated with the excluded color admin. Note that
links A-B and F-H are already excluded by virtue of the include-any constraint but that link D-H passes the
include-any constraint, and so it is not pruned until the exclude constraint is processed.
The links that pass both sets of constraints are A-D, D-E, E-B, B-G, E-G, G-I, G-H, and H-I. A shortest path is now computed
from the set of compliant links. In this case, four possible paths exist: A-D-E-B-G-H (cost 14), A-D-E-G-H (cost 8), A-D-E-B-G-I-H
(cost 13), and A-D-E-G-I-H (cost 7). The CSPF algorithm the selects the lowest metric path, which is A-D-E-G-I-H.
Note that the path chosen in this example has the lowest metric but not the lowest hop count. This is because it has a lower
metric cost to traverse both the G-I and I-H links (2) than to cross the G-H link directly (3).

Administrative Groups IV: Solution

This slide displays the solution to the question asked on the previous slide. In this case, the best path that meets both the
include-any and exclude constraints consists of the path A, D, E, G, I, and H.

Administrative Groups V: Include-All Constraints

In this case, the LSP definition requires that the link include both the gold and silver colors.
The CSPF algorithm begins by pruning the links that do not include the required colors. In this example, no link includes both
the gold and silver colors. Therefore, all links are pruned from the topology and the LSP setup process fails because
there is no path that meets the defined constraints.

Administrative Groups V: Solution

This slide displays the solution to the question asked on the previous slide. In this case, there is no path between A and H
that meets the defined constraints. LSP setup fails.

Check Your Knowledge

The answer to the question on the slide is no. The CSPF algorithm prunes links that do not have the specified include
colors or that specifically match any exclude colors. In this example, there are no include constraints, and therefore,
CSPF does not prune the C-D link. The exclude color in this case is admin, and because link C-D has no color, it does meet
this constraint.

Inter-Area Traffic Engineered LSPs


CSPF Must Have Visibility of the Whole Topology

In order to compute a path, CSPF needs to have visibility of the whole topology. Remember that Traffic Engineering
extensions do not cross area or level boundary, and because of this all routers must reside in the same OSPF area or ISIS
level. If a router along the path is in a different area or level than the ingress router, the CSPF algorithm will fail and the LSP
will never come up.
You can override this default behavior by applying the inter-domain statement to an LSP. The following slides will
describe the behavior change that this statement causes on the ingress router. This statement only works for OSPF. There is
no comparable feature for ISIS.

inter-domain Behavior: The Role of the Ingress Router

The slide shows that an LSP has been configured with the inter-domain statement and a user-defined loose hop of the
R5 router. R1 immediately notices that the user-defined R5 hop cannot be found in the TED database. This means that R5 is
located in a different OSPF area. R1 then looks at the standard OSPF database to determine the best ABR to use to reach
R5. Once the ABR is determined (R4 in the slide), R1 runs the CSPF algorithm only up to the ABR. This CSPF run produces a
complete list of strict hops to the ABR. R1 then appends any remaining user defined hops that lie beyond R4 to the ERO. This
appended ERO is then used by R1 in the Path message to instantiate the LSP. R2 and R3 process the received Path
message and it’s ERO as normal, removing themselves from the list of hops before passing to the downstream router.

inter-domain Behavior: The Role of the ABR

R4 and R5 process the received Path message and its ERO as normal, removing themselves from the list of hops before
passing to the downstream router. They each use the unicast routing table (inet.0) to determine the direction to send the
Path message.

ABRs Behavior Can Lead to Poor Results

The slide shows that an LSP has been configured with the inter-domain statement and a bandwidth reservation of
200Mbps. R1 is able to calculate the path of the LSP as far as the ABR using the TED database. Once the PATH message
arrives to R4, the router uses the IGP to determine the best path to R6, the egress router. The shortest path to R6 is along
the R4-R6 link, but, since there are only 100Mbps of bandwidth available, the setup of the LSP just fails.

A Workaround: Have ABRs Perform a CSPF Calculation

As a solution to the problem described in the previous slide, you can configure the expand-loose-hop command on the
ABR. This will cause the ABR to run a CSPF calculation as it determines the direction to send the PATH message. To get the
ABR to run a CSPF calculation, these conditions must be true:
1. expand-loose-hop must be configured on the ABR.
2. The first of the remaining hops in the ERO (after the ABR has removed itself) must be a loose hop. It is the
existence of this loose hop that will trigger the CSPF run. If there are no more hops left in the ERO, the egress
router is treated as a loose hop. If the first remaining hop in the ERO is a strict hop, there will be no CSPF
calculation. The Path message will be sent directly to the strict hop using inet.0.
3. The ABR must have knowledge in the TED of how to get from itself to the loose hop that triggered the CSPF run.
In the example, OSPF traffic-engineering must be enabled in Area 1.
In the example, R4 removes itself from the received ERO which leaves an empty ERO. Since the egress router is considered a
loose hop, described above. R4 performs a CSPF calculation to determine the remaining path of the PATH message. Using
the TED information that describes Area 1, it finds a path that satisfies the 200Mbps bandwidth constraint of the LSP. R4
takes the resulting expanded ERO and places it in the PATH message before sending it off to R5. R5 and R6 process the
PATH message as normal.

Some Considerations on expand-loose-hop

Unless you have a specific need, you should only configure the expand-loose-hop command on ABRs. Remember, if the
router does not have TED-based knowledge of the loose hop that is triggering the CSPF calculation the calculation will fail
and the LSP will not come up. Also, remember that even user-defined loose hops can trigger the CSPF calculation. In the
previous example, if, when R4 removed itself from the ERO list, there was a user-defined loose hop left in the ERO, a CSPF
calculation would be triggered but the calculation would only produce an “expanded” ERO to the user-defined loose hop, not
the egress router. This may not be your desired result. Be very careful when configuring user defined loose hops that lie
beyond the ABR.
A router configured with expand-loose-hop will consider the user-defined bandwidth, setup priority, hold priority,
exclude-any, include-any, include-all admin groups during its CSPF calculation. All of this information is carried in the
received PATH message.

Path Computation Element Protocol


Delegating Path Computation to an External Entity

One limitation of CSPF is that each LSP is established individually and sequentially. Each ingress router just checks for a
feasible path, and signals the LSP if one is available. This mode of operation lacks a global view of bandwidth demand
across the network: there is no central control point that can coordinate rerouting of LSPs on multiple ingress nodes to make
room for new requests. Moreover, CSPF cannot react asynchronously and in real time to a change in utilization.
A possible solution is to delegate path computation to an external entity, a Path Computation Element. This requires a
dedicated protocol, the Path Computation Element Protocol (RFC5440), to run between routers and the Path Computation
Element. The Path Computation Element Protocol is mainly in charge of relaying path computation requests from routers to
the Path Computation Element and delivering the corresponding Path Computation Replies to routers. However, the protocol
can also inform routers of asynchronous events via notifications.

Configuring PCEP
Configuring PCEP involves three steps:
• Configuring each Path Computation Element at the [edit protocol pcep] level. The mandatory
parameters are IP address, port, and PCE type.
• Declaring each server at the [edit protocol mpls] level.
• Finally, for each LSP that needs to be externally controlled, specify the PCE name.
The protocol itself can handle both path computation, and synchronization of the PCE with the actual network state.
For more information on PCEP, please refer to the Junos MPLS applications guide available on the Juniper website.

Corouted Bidirectional LSPs


Corouted Bidirectional LSPs: Background

Many MPLS applications require bidirectional MPLS connectivity between two endpoints. Typical examples are the different
kinds of MPLS-based VPNs (Layer 2, Layer 3, and VPLS) or point-to-point transport of Layer 2 frames (Layer 2 circuit, CCC). All
these applications often benefit from a consistent path between the endpoints: the path from A to B should cross the same
links as the path from B to A.
A possible solution is to use corouted bidirectional LSPs, which behave like a pair of LSPs traversing the same path in
opposite directions.

Corouted Bidirectional LSPs: Configuration

Configuring a bidirectional LSP is similar to configuring an ordinary LSP, with the addition of the keyword
corouted-bidirectional at the LSP definition level. The return LSP will be signaled back automatically. The router which holds
the configuration will be considered ingress in CLI commands, even if in fact it will be also egress for the return LSP.

Proactive Loss and Delay Measurement over Associated Bidirectional LSPs


Loss and Delay Statistics Collection Over a Pair of Associated UHP LSPs
For critical, delay-sensitive services it is possible to enable automatic delay and loss statistic collection over a pair of
associated LSPs. The LSPs need to be configured for ultimate hop popping, which is needed to preserve the identity of LSPs
even after the penultimate hop.
In the configuration above all intervals are in milliseconds. It is possible to specify different MPLS TC classes for each probe,
to check how your network prioritizes different traffic types according to the MPLS Traffic Class field.

Loss and Delay Monitoring Example

Once proactive monitoring is enabled, it is possible to display its results with the show performance-monitoring
mpls lsp name <name> command.
In this example you can see forward and backward loss measurements (both zero) and forward and backward delay and
delay variation.

We Discussed:
• The path selection process of RSVP without the use of the CSPF algorithm;
• The IGP extensions used to build the TED;
• The CSPF algorithm and its path selection process;
• Administrative groups and how they can be used to influence path selection; and
• The behavior of inter-area traffic engineered LSPs.

Review Questions
1.
2.
3.
4.

Lab: CSPF

1.
OSPF supports the flooding of the opaque type 10 LSA. IS-IS supports the flooding of extended TLVs for traffic engineering.
Both of the extensions to the protocols support the advertisement of rsvp bandwidth, administrative group, and router ID.
2.
Some possible user inputs are bandwidth requirement, administrative group requirement, explicit route, and priority.
3.
The default CSPF tie-breaking algorithm is random.
4.
When configuring an LSP, an administrator can specify which administrative groups the LSP can traverse. The administrator
can specify several administrative group constraints for an LSP by using the include-any, include-all, and the
exclude statements.


Chapter 6: Traffic Protection and LSP Optimization

We Will Discuss:
• The default traffic protection behavior of RSVP-signaled label-switched paths
• The use of primary and secondary LSPs
• LSP priority and preemption
• Operation and configuration of fast reroute
• Operation and configuration of link and node protection
• LSP optimization options
Chapter 6–2 • Traffic Protection and LSP Optimization www.juniper.net

Default Traffic Protection Behavior

www.juniper.net Traffic Protection and LSP Optimization • Chapter 6–3

Failures in MPLS Networks

A central problem in MPLS is how to handle network failures. When a failure occurs down a label-switched path, there is an
interval of time when the ingress router is not yet aware of the problem, and is sending traffic down a LSP which is in fact no
longer unusable. Without any traffic protection feature, this traffic would be lost. The duration of this loss period will depend
on many factors, including the length in terms of hops of the LSP. In the example, until R1 receives ResvTear message for the
LSP, R1 will continue forwarding traffic down the LSP. All that traffic will then be dropped on R3.
Traffic protection features like fast reroute and link protection are designed to minimize this downtime.

Example: Downstream Failure

The following slides illustrate a failure scenario using the default settings of an RSVP-signaled LSP. No traffic protection
mechanism has been configured.
Transit packets begin to drop the instant the link between R3 and R4 fails. In response to the link failure, R3 will send a
ResvTear message upstream to R2. R2 will, in turn, forward the ResvTear upstream to R1. As the ResvTear messages travel
upstream, packets sent down the LSP are still being dropped.

ResvTear Processing at the Ingress

When R1 receives the ResvTear it will mark the LSP as down, delete PATH and RESV state blocks, and remove from inet.3 the
LSP egress point.
Any BGP route that had been using the LSP as a next-hop will need to re-compute its forwarding next-hop. At this point, if the
LSP was only being used to forward standard IP traffic, packet drops stops and new packets are forwarded using next-hops
learned via the IGP.
However, many applications and services require a MPLS label-switched path to work. For example in a virtual private
network (VPN) scenario, a route in inet.3 must exist to forward VPN traffic between Site 1 and Site 2. The VPN service will
stay down due to the lack of a valid route for the remote side in the inet.3 table.
In parallel, R1 will also attempt to reestablish the failed LSP by sending a Path message downstream, towards the egress
router.

The LSP Is Re-Established

If the link between R3 and R4 remains in a failed state, the LSP is re-established using R5 as a path around the failed link.
Once the LSP comes up, the /32 route for the LSP egress point is added back into inet.3. At this point, all services are
restored.

Primary and Secondary LSPs


LSP Path Options and Timers

Primary paths are optional. Only one primary path is permitted per LSP definition. The primary path can specify loose or
strict hops under the named path hierarchy. Within the primary physical path you can specify parameters, like bandwidth or
priority, that affect only the primary physical path. As a side note, the same parameters specified at the
label-switched-path hierarchy affect both the primary and secondary physical path.
By default, an LSP fails over to its secondary path if its primary path fails. This occurs even if another physical path exists
that complies with the primary path constraints. The LSP still fails over to a secondary path, if defined, before attempting to
resignal an alternate primary physical path.
The router tries to resignal the primary path according to the number of seconds specified by the retry-timer, and it
attempts to resignal the primary path LSP the number of times specified by the retry-limit. The alternate primary
physical path must be up and stable for at least the number of seconds specified by the revert-timer before the LSP
reverts back to the primary path.
By default, the retry-timer is 30 seconds, the retry-limit is 0 (unlimited retries), and the revert-timer is 60
seconds. Setting the revert-timer to 0 means the LSP will not revert. If the revert-timer is set to 0 or the
retry-limit is exceeded, you must manually clear the LSP to restart signaling attempts and move traffic to the primary
path.
You configure the retry-timer and retry-limit values for individual LSPs at the [edit protocols mpls
label-switched-path lsp-name] configuration hierarchy. You can specify the revert-timer for all LSPs at the
[edit protocols mpls] configuration hierarchy or for an individual LSP at the [edit protocols mpls
label-switched-path lsp-name] configuration hierarchy. When specified, the per-LSP value overrides the global
value.

Secondary Paths
Like primary paths, secondary paths are optional. By default, a secondary path is signaled only when it is needed, after a
failure. When multiple secondary paths are defined, they are signaled in the order they appear in the configuration.
Standby
You can specify the standby option for a secondary path. This causes the router to signal the secondary path immediately,
even if it is not needed yet. Note that standby secondaries result in routers having to maintain additional state in the form
of the pre-established standby LSPs. When the standby option is specified at the label-switched-path lsp-name
hierarchy, the router maintains standby state for all secondary paths. To keep only selected secondaries in standby state,
specify the standby keyword at the secondary name hierarchy, as shown here:
[edit protocols mpls label-switched-path green]
user@R1# show
to 192.168.24.1;
primary one {
bandwidth 35m;
priority 6 6;
}
secondary two {
standby;
}

Primary and Secondary Configuration

The Junos operating system does not require that a primary and secondary path share the same parameters. You can decide
to configure your primary paths with stringent resource requirements while your secondary paths are far more lax in their
demands. Such asymmetric settings helps to ensure that your secondary paths can be established during periods of
diminished resources. In the example on the slide, primary path one requires 35 Mbps of bandwidth while secondary path
two requires only IP reachability.

Automatic Path Selection

By default, the primary path is selected as the path to actively carry traffic. If the primary path is down or degraded, the
automatic path selection algorithm tries secondary paths in the order in which they appear in the configuration. The first
secondary path that is up and stable becomes the active path. Traffic reverts to a recently restored primary path based on
the parameters previously discussed.
Overriding Default Behavior

You can override the automatic selection of the active path by specifying either select unconditional or select
manual at the [edit protocols mpls label-switched-path lsp-name primary primary-path-name]
or the [edit protocols mpls label-switched-path lsp-name secondary secondary-path-name]
configuration hierarchy. The two parameters are mutually exclusive and will override the primary and secondary attributes of
the LSP’s configured paths. Also, only one path per LSP can specify each parameter. If one path specifies select
unconditional and another path specifies select manual, the path with select unconditional takes
precedence.
The select unconditional parameter forces the path to become active even if it is down or degraded. The select
manual parameter forces the path to become active as long as it is up and stable (and select unconditional is not
configured on another path). If the path with select manual is down or degraded, automatic path selection is used to
choose the active path. Upon restoration, traffic reverts to the path with the select manual parameter based on the
settings of retry-timer, retry-limit, and revert-timer.

Overriding Default Behavior (contd.)
The operator can also choose to not configure any, and the automatic path selection algorithm is used, same as in the past.
If any path is configured with select manual, other paths of the LSP cannot be configured with it. Likewise for
select-unconditional, only one of the path is permitted to own it.
select unconditional has the highest precedence. It means the path will be select for carrying traffic unconditionally.
This is done regardless if the path is currently down, or degraded (receiving errors from downstream). This parameter
overrides select manual and/or primary/secondary attributes. Since select unconditional causes immediately
switch over without regard to the current path status, there are potential consequences when using this parameter:
• If a path isn't currently up when select unconditional is specified on it, it may cause disruptions to user
traffic. Making sure a path is working before specifying select unconditional on it avoids the problem.
• Once a path is selected due to select unconditional, all other paths of the LSP will be cleared gradually,
including primary/standby paths. This is because no path can act as standby to a select unconditional
path, so signaling those paths just wastes resources.
select manual has the second precedence. It means the path will be selected for carrying traffic if it is up and stable for
at least the revert-timer window. Traffic moves away to other working paths if the path is down or degraded. This parameter
overrides primary/secondary attributes.
Both parameters can be (de)configured on-the-fly with no impact on traffic. select unconditional is analogous to
forced switching in the SONET APS world, while select manual is analogous to manual switching.


By default, when a primary path fails, traffic switches over to a secondary path and reverts back to the primary path when it
is again operational.
This behavior brings us to the first question on the slide: How can you configure alternate LSP paths without chancing
reversion to a path that has previously failed?
The second question is designed to test your understanding of secondary paths and how they are handled during failures.

Check Your Knowledge: Solution

By default, the Junos OS will revert back to the primary path when it is available, but you can disable this behavior by
specifying a revert-timer of 0. When specified at the LSP level, this value affects only a single LSP. When specified at
the MPLS level, it affects all LSPs.
An alternative solution involves the definition of secondary paths only. In this case, Junos OS brings up the second
configured secondary LSP when the first secondary path fails. Later, if the first secondary path is up again, the Junos OS
continues to use the existing secondary path and does not revert.
To answer the second question, remember that if neither select unconditional nor select manual is configured
and the primary path is absent or down, the Junos OS attempts to establish an active path by signaling each secondary LSP
in the order in which they appears in the configuration. If the first secondary path fails or cannot be established, the router
attempts to signal the next secondary physical, and so on. The select unconditional and select manual
parameters override this behavior.

LSP Priorities and Preemption

RSVP-signaled LSPs support the notion of LSP setup and hold priorities. These priorities work together to determine the
relative priority of a new LSP in case of contention with existing LSPs. When insufficient resources exist, an LSP with a strong
setup priority preempts an existing LSP with a weaker hold priority. LSPs are signaled in order from strongest to weakest
setup priority. This behavior ensures that high-priority LSPs are established first and are assigned optimal paths.
LSP setup and hold priorities range in value from 0 (the strongest) to 7 (the weakest). The default settings disable
preemption by assigning all LSPs the weakest setup priority (7) and the strongest hold priority (0). Note that you cannot
commit a configuration in which an LSP’s hold priority is weaker than its setup priority because such a configuration can lead
to preemption churn.
LSP priority values are displayed in the output of the show mpls lsp extensive command.
Using Soft Preemption

In normal operation, a preempted LSP is torn down before a new path is located. During this process, traffic associated with
the preempted LSP can be lost. To avoid traffic loss the Junos OS can specify soft preemption behavior on a per-LSP basis.
When configured, the ingress LSR sets the soft preemption desired flag in the record route object (RRO) sub-object of the
path message to signal the desire for soft preemption behavior in downstream nodes. This feature is backwards compatible
in that LSP establishment succeeds even if one or more nodes does not support this sub-object. To enable soft preemption,
add the soft-preemption keyword at the [edit protocols mpls label-switched-path lsp-name]
hierarchy. The output of a show rsvp session detail command displays whether soft preemption is requested for a
given LSP.

Monitoring Preemption
This slide shows the effects of preemption over an established LSP.
The LSP is defined with an associated bandwidth of 800M, and setup and hold priorities both set to 4. The primary path has
two strict hops, while the secondary path has no constraints.
user@R1> show configuration protocols mpls
...
label-switched-path green {
to 172.17.20.6;
bandwidth 800m;
priority 4 4;
primary via-R2-R4;
secondary any-path;
}
path via-R2-R4 {
172.17.20.2 strict;
172.17.20.4 strict;
}
path any-path;

Monitoring Preemption (contd.)
At 14:17:12, the LSP is preempted by another one, starting from a different router but defined with setup and hold priorities
both equal to one.
user@R2> show configuration protocols mpls
...
label-switched-path blue {
to 172.17.20.6;
bandwidth 800m;
priority 1 1;
}
As soon as the new blue lsp is signaled, the existing green lsp is preempted; the primary path goes down, and CSPF
computes a secondary path which still respects the bandwidth constraints.
user@R1> show mpls lsp name green extensive
Ingress LSP: 4 sessions
172.17.20.6
From: 172.17.20.1, State: Up, ActiveRoute: 0, LSPname: green
ActivePath: any-path (secondary)
LSPtype: Static Configured, Penultimate hop popping
LoadBalance: Random
Encoding type: Packet, Switching type: Packet, GPID: IPv4
Primary via-R2-R4 State: Dn
Priorities: 4 4
Bandwidth: 800Mbps
SmartOptimizeTimer: 180
Will be enqueued for recomputation in 19 second(s).
13 Jan 5 14:17:38.092 CSPF failed: no route toward 172.17.20.2[2 times]
12 Jan 5 14:17:12.489 Clear Call: CSPF computation failed
11 Jan 5 14:17:12.488 172.17.23.2: Requested bandwidth unavailable
10 Jan 5 14:17:12.400 Deselected as active
9 Jan 5 14:17:12.398 Originate Call
8 Jan 5 14:17:12.394 Clear Call
7 Jan 5 14:17:12.394 CSPF: computation result accepted 172.17.23.2 172.17.23.14
172.17.23.22 172.17.23.30
6 Jan 5 14:17:12.393 172.17.23.14: Session preempted
5 Jan 5 14:16:39.226 Selected as active path
4 Jan 5 14:16:39.225 Record Route: 172.17.23.2 172.17.23.14 172.17.23.26
3 Jan 5 14:16:39.225 Up
2 Jan 5 14:16:39.166 Originate Call
1 Jan 5 14:16:39.166 CSPF: computation result accepted 172.17.23.2 172.17.23.14
172.17.23.26
*Secondary any-path State: Up
Priorities: 4 4
Bandwidth: 800Mbps
SmartOptimizeTimer: 180
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 31)
172.17.23.6 S 172.17.23.18 S 172.17.23.30 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt
20=Node-ID):
172.17.23.6 172.17.23.18 172.17.23.30
6 Jan 5 14:17:38.172 Selected as active path
[...]


You can assume in this example that all links with existing LSPs have less than 10Mbps available. Therefore, the only way to
establish LSP Red is for it to preempt one of the existing LSPs. Can you determine which LSP will be preempted by LSP Red?
The setup priority for Red is 6 (the first number). The hold priority (the second number) for LSPs Green and Purple are
both less than 6, which gives these LSPs a stronger hold priority that will prevent their preemption. In contrast, LSP Blue
has a hold a priority of 7, which is weaker that LSP Red’s setup priority. Thus, LSP Red can only preempt LSP Blue. Note the
IS-IS metric has no effect on LSP preemption.
Question: What if LSP Red had priority 3 7?
Answer: This is a trick question because such a priority setting is not allowed. Recall that an LSP cannot have a setup priority
that is stronger than its hold setting.

Fast Reroute

Two Interesting Questions

When you define a secondary path with the standby option, the router pre-signals an alternate path which is then ready to
be used in case the primary fails. However, there is still a gap where traffic transiting the LSP is lost, as the information about
a downstream failure is forwarded to the ingress router.
This is a central problem in MPLS networks: how to handle situations where traffic is sent down a path and then lost
because the ingress router does not yet know that the path, downstream, failed at some point. All features and
functionalities that strive to address this problem fall under the name of traffic protection features.
One of the earliest traffic protection features is fast reroute, which provides a way for intermediate LSRs to immediately
switch to a detour after a failure, while simultaneously alerting the ingress LSR. This can dramatically reduce packet loss.

Fast Reroute Reduces Packet Loss

Fast reroute enables a LSR upstream of a failure to keep on delivering traffic via a detour LSP, while the primary path is torn
down and re-signaled. This helps reduce packet loss after a path failure. Once a new primary path is signaled, the fast
reroute detours are torn down. Fast reroute is a short-term solution, designed to cover the interim period between the
moment a failure is detected and the moment a new path has been signaled and is ready to be used.
When fast reroute is enabled, the ingress router adds an object to the RSVP Path messages requesting that downstream
routers establish detour LSPs. When an active path fails and a detour is available, the upstream router sends a PathErr
message to the ingress router. This message triggers new CSPF computations and a switchover to an alternate path if
available. If a detour is not available, the downstream node sends a ResvTear message and begins withdrawing the MPLS
labels, bringing down the LSP. A fast reroute path might stay up indefinitely if an alternative primary path is not found.

The Roles of Ingress and Transit Routers

A long-term rerouting solution can only be initiated by the ingress router, since it is the only LSR in the path with knowledge of
all traffic engineering constraints of the LSP. Fast reroute detours by default only inherit the administrative group settings
from the original LSP. It is therefore possible for a detour to have substantially less bandwidth than was specified in the
original LSP. As soon as the ingress node re-signals a new path, the old path with all its detours is torn down. Note that the
newly signaled path will have the correct traffic parameters, including bandwidth constraints. This behavior shows again that
fast reroute detours are a temporary solution. You can configure the following fast reroute parameters if wanted: bandwidth,
hop limit, include and exclude administrative groups. You can also disable the inheritance of include and exclude
administrative groups, which is enabled by default.
By default, each router uses the traffic engineering database (TED) to calculate a detour path. These detours can add up to
an additional six hops to the path in an attempt to bypass the downstream node. Use the hop-count parameter to change
the default number of hops the router will consider when calculating a detour.
When a router with an available detour recognizes a link or node failure, it immediately begins to detour the traffic. The
Packet Forwarding Engine (PFE) maintains precomputed fast reroute detours to provide convergence times that, in some
cases, rival SONET Automatic Protection Switching (APS)!
Each downstream node tries to originate its own detours. It is possible that a given node is not able to establish a detour
path. The result is that some portions of the LSP might have fast reroute protection while other portions do not. An LSP will
never be torn down just because fast reroute detours cannot be established.
You can configure fast reroute at the label-switched-path lsp-name hierarchy, which causes LSR along the primary
and all standby secondary paths to signal their detours.

LSP from San Francisco to New York

In this example, we begin with San Francisco acting as the ingress node for a LSP that terminates at New York. The routing of
this LSP is via Los Angeles, Austin, and Miami, as shown on the slide.

Enable Fast Reroute on Ingress
The configuration of the to-NY LSP is shown here. Note that the fast-reroute keyword is present in the LSP definition.
As a result, San Francisco determines the next downstream node is Los Angeles, with a follow-on node of Austin. Node San
Francisco therefore calculates and signals a fast reroute path around Los Angeles to New York. Los Angeles likewise
calculates and signals a path around Austin to New York. Austin calculates and signals a route around Miami to New York. If
any link or node fails, the fast reroute path recognizes the failed LSP quickly and immediately begins sending traffic on the
fast reroute path.
mpls {
label-switched-path to-NY {
to 192.168.2.2;
primary use-austin;
secondary use-seattle;
fast-reroute;
}
path use-austin {
192.168.1.2 loose;
}
path use-seattle {
192.168.8.1 loose;
}
}

Los Angeles Detects Failure

In the example on the slide, the link between Los Angeles and Austin failed. Los Angeles recognizes the failure and
immediately begins to forward the traffic along the detour to node Phoenix. It also sends a PathErr message to San Francisco
so that San Francisco can resignal the LSP.
The Final Solution

Once notified of the primary path failure, node San Francisco signals the secondary path through Seattle to New York. Traffic
is then switched from the primary path, which is still using a fast reroute detour, and the remnants of the primary path are
torn down. At this point, node San Francisco tries to resignal a new primary path.

Configuring Fast Reroute

You configure fast reroute by including the fast-reroute keyword at the label-switched-path lsp-name
hierarchy. This setting applies to all defined primary and secondary paths.
By default, fast reroute detours have a limit of six additional hops to get to the next downstream path. You can configure a
larger or smaller number with the hop-count parameter.
The slide also shows the constraints that can be applied to detour paths.

Monitoring Fast Reroute: Ingress

The output of the show mpls lsp extensive command indicates that fast reroute was requested, and that the detour
is up.

Monitoring Fast Reroute: Transit

This slide shows the output of show mpls lsp extensive for a downstream transit LSR.
This output shows a detour branch and its Record Route object. The detour has been pre-signaled and is ready to carry
traffic in case the primary path fails.

Increasing Fast Reroute Responsiveness

One important optimization can greatly speed up switching to a detour path after a failure. On Juniper routers, by default,
only the active path is installed in the forwarding table and programmed into the Packet Forwarding Engine, as you can verify
with the show route forwarding table command.
As a result of this, whenever a failure is detected a new next-hop needs to be installed, first in the forwarding table, then in
the Packet Forwarding Engine itself. These operations can take time, even tens of milliseconds. However, this can be
changed by enabling per-packet load balancing.

Enabling Load Balancing Reduces Downtime

Enabling per-packet load balancing changes the default by allowing fast reroute to pre-install detour next-hops even before
they are needed.
This is purely an internal Juniper optimization, and traffic is never in fact load-balanced between the normal path and its
detour. But enabling load-balancing, as a side effect, allows the Junos OS to pre-program detour next-hops in the forwarding
table and in the PFE, reducing switchover time after a failure and therefore reducing packet loss.
The output on the slide above shows that after applying the load balancing policy to the forwarding table, two next hops are
available in the forwarding table.

RSVP Link Protection


A Different Approach: Link Protection—RFC4090

While fast reroute attempts to protect the entire path of an LSP, link protection follows a different approach: it builds bypass
LSPs to protect any LSP crossing a given protected interface.
The slide shows how R2 is protecting its interface and link to R3 through a bypass LSP that is calculated using CSPF.
Unlike fast reroute, link protection requires a designer to select, on the basis of the topology, which interfaces should be
protected. LSPs must also be configured with the link-protection option in order to make use of bypasses.

Protecting Against Failures of the Downstream Node

Node Protection is the Junos OS nomenclature for the facility backup feature defined in RFC 4090. Node Protection uses
similar messaging as link protection, but tries to bypass the whole next-hop router, instead of just a single interface. The
slide shows that R2 is protecting against the complete failure of R3 through a bypass LSP that is calculated using CSPF.
As for link protection, LSPs must be configured with the node-link-protection option to make use of bypass LSPs.

A Single Bypass LSP Is Created By Default

The ingress router signals that an LSP is configured for link protection via its RSVP PATH message. If the LSP traverses a link
that is configured for link protection, the transit router will automatically create a bypass LSP.
You can also request that the router create more than one bypass LSP. Finally, you can also manually configure a number of
bypass LSPs. The slide shows the algorithm that is used to determine which bypass LSP will be used to protect a new LSP
configured for link protection.

Configuring the Protected Interfaces

You can specify the interfaces to be protected at the [edit protocols rsvp] level. This configuration does not
immediately cause a bypass LSP to be signaled. Instead, it is the PATH message for a new LSP requesting protection that
causes the bypass LSP to be created. Of course, bypass LSP can only be created if the node (R1, in this case) can detect in
the TED database a feasible path for the bypass LSP.
Note that the mere presence of a bypass LSP does not, in itself, provide protection to the LSPs that cross the protected
interface. You must also add the link-protection option on the ingress node, in the LSP definition.
The slide shows the minimum configuration for a router to support both link protection or node-link protection on an
interface.

Bypass LSP Options

Bypass LSPs are configured at the [edit protocols rsvp interface interface-name] level of the
configuration hierarchy. You can specify manual pre-configured bypasses by name, along with optional parameters.
To create more the one bypass LSP, simply use the max-bypasses statement using a value greater than 1.

LSP Configuration
To take advantage of protection, an LSP needs to be configured with either the link-protection or the
node-link-protection keyword. If Node Protection is not available, then the behavior will fall back to link protection.
This can happen because in the topology there is no alternative path that bypasses the next-hop router.

Monitoring Link and Node Protection

This slide shows how the output of a show rsvp interface extensive command indicates the presence of a bypass
LSP at the transit node.

LDP Link Protection


Protecting LDP Against Interface Failures

Label Distribution Protocol (LDP) link protection is similar to the RSVP link protection as it protects individual interfaces
instead of the entire path. LDP relies on the IGP to determine the label and interface that should be used as the next hop of
an LSP. When a link is configured for IGP link protection, the IGP attempts to find a loop free alternate next-hop (LFA) for all
destinations that have a primary next hop reachable via the protected interface. The calculated LFA next-hop is then installed
in the forwarding table, ready to be used in case of need. If the protected interface fails, the LFA next-hop is already available
in the routing table for forwarding.
While the LFA next-hop is computed by the IGP, LDP will also make use of it during a failure.
In some cases, the IGP may be unable to calculate a loop-free path to the downstream router. In this case, a bypass RSVP
LSP can either be manually configured or dynamically created. LDP tunneling is used over the RSVP bypass LSP, so in a
failure traffic will be sent through the bypass with two labels: an inner LDP label, and the outer RSVP transport label from the
bypass LSP.

IGP Loop Free Alternate

When IGP link-protection is enabled, the IGP will try to determine a second best, loop free path for routes that use the
protected interface as a next hop. In the routing table the LFA next hop appears to be an equal cost next-hop, however the
actual cost of the path is higher that the usual IGP path.
A router will not calculate an LFA next hop in the following cases:
• If there is no secondary loop free path to a destination;
• In case of multiple adjacencies to the downstream LSR (i.e parallel links);
• If there is an existing targeted session to downstream LSR (for example, for LDP tunneling); and
• When no operational LDP session exists to the downstream LSR
Finally, you cannot enable dynamic RSVP-based link protection to downstream LSR if LDP is not configured on loopback
interface.

RSVP Backup Next-Hop

If no LFA next-hop can be determined by the IGP, you can manually configure an RSVP LSP to the downstream router. You
should ensure that the LSP will not cross the protected link, typically by specifying an alternate path in the configuration. For
the RSVP LSP to be used by the IGP, the backup statement must be configured. For the RSVP LSP to be used by LDP, both
the backup and ldp-tunneling statement must be configured.

LDP Link Protection Configuration

By default, LDP will automatically use the LFA calculated by the IGP, if it can be determined, with no further configuration
needed. For multipoint LDP (mLDP) to use the LFA next-hop, the link-protection statement must be explicitly
configured at the [edit protocols ldp interface interface-name] hierarchy.

Monitoring Link Protection

This slide shows how the output of a show ldp interface extensive command indicates that link protection is
enabled.

Label Mapping
The slide shows the alternate next-hop that is installed by link protection. The next-hop will be available to protect traffic in
case of failure of the protected interface, ge-1/0/4.105.

LSP Optimization

LSP Rerouting
Once an LSP is established, changes in topology or available resources might result in the existing path becoming
suboptimal. A subsequent CSPF recomputation might find that a better path is now available. When optimization is enabled,
LSPs can be rerouted as a result of periodic CSPF recomputations. Without optimization the LSP has a fixed path and cannot
take advantage of newly available network resources, at least until the next topology change or operator intervention. Note
that optimization is not related to failover; a new path is always computed when topology failures disrupt an established
path.
Enable Optimization
Because of the potential system overhead involved, you should carefully consider the frequency at which routers perform
optimization runs. By default, the optimize-timer is set to 0 (that is, it is disabled). LSP optimization is only meaningful
for CSPF LSPs. Due to statistical characteristics that arise in large topologies, a network can effectively synchronize and end
up trying to recalculate all LSPs at the same time when all reoptimization timers are set the same. To prevent this behavior,
the LSP reoptimization timer is modified to include a randomization factor when recalculating LSPs. The randomization
factor is fixed and cannot be modified.
Note that you can manually trigger optimization with the operational mode clear mpls lsp optimize command.

Optimization Rules
By default, an LSP can only have its path optimized when all of the following criteria are met. These rules are intentionally
conservative as stability is better than being optimal in many cases.
1. The new path is not higher in CSPF metric. (The metric for the old path is updated during computation, so if a
recent link metric changed somewhere along the old path, it is accounted for.)
2. If the new path has the same CSPF metric, it must not have more hops.
3. The new path does not cause preemption. (This is to reduce the ripple effect of one preemption causing yet more
preemption.)
4. The new path does not worsen congestion overall. This is determined by comparing the percentage of available
bandwidth on each link traversed by the new and old paths, starting from the most congested links.
When all the above conditions are met, then if the new path has a lower CSPF metric, it is accepted. If the new path has an
equal CSPF metric and lower hop count, it is accepted. If you choose least fill as a load-balancing algorithm and if the new
path reduces congestion by at least 10 percent aggregated over all links it traversed, it is accepted. For random or most-fill
algorithms, this rule does not apply. Otherwise, the new path is rejected.

Optimization Rules (contd.)
Here is a sample calculation to help explain how links are compared. You compare the percentage of available bandwidth on
each link traversed by the new and old paths, starting from the most congested links. Assume that Path 1 (active) has four
hops with availability: hop 1: 10%; hop 2: 15%; hop 3: 25%; hop 4:15%. The new candidate path has a lower IGP metric, will
not cause preemption, and is three hops away with availability as follows if the new LSP was implemented, and the old LSP
removed:
hop 1: 10%; hop 2: 50%; hop 3: 15%. The active path will be sorted as 10, 15, 15, 25. The candidate path will be sorted as
10, 15, 50, 100. The two paths will be compared, on an item by item basis. 100>25, 50>15, 15=15 10=10. The candidate
path does not worsen congestion. Every single link in the candidate path must have available bandwidth >= those in the
active. For example, all four candidate links were >= available bandwidth of the original path (do not forget that a pseudo
100 availability was used for the final link).
What if only three out of four links had better availability? In this case, the congestion is considered worsened so the
reoptimization is not accepted.
To force the reoptimization to be based upon IGP metric only, enable the optimize-aggressive keyword. This setting
negates the tests outlined in Steps 2, 3, and 4 on the previous page. You can manually trigger aggressive optimization with a
clear mpls optimize-aggressive command. The LSP must still comply with the original CSPF constraints when
optimized aggressively, but no attention is paid to available bandwidth ratios, as explained in the sample calculation above,
so you will tend to see more LSP rerouting when operating in aggressive mode.

Adaptive Provides Make Before Break

You can configure an LSP to use a shared explicit (SE) style reservation by setting it to be adaptive. While any LSP can be
established with an SE-style reservation, this capability is most useful when attempting to reroute an LSP. When an LSP is
adaptive, it holds onto existing resources until the new path is successfully established and traffic is cut over to the new
path. To retain its resources, an adaptive LSP does the following: 1) Maintains existing paths and allocated bandwidths
(which ensures that the existing path is not torn down prematurely and allows the current traffic to continue flowing while the
new path is being set up), and 2) Avoids double-counting for links that share the new and old paths. Double-counting occurs
when an intermediate router does not recognize that the new and old paths belong to the same LSP and counts them as two
separate LSPs, requiring separate bandwidth allocations. If some links are close to saturation, double-counting might cause
the setup of the new path to fail. By default, adaptive behavior is disabled.
Configuration Example
To define an adaptive LSP, include the adaptive statement when defining the LSP, as shown on the slide. When
adaptive is specified at the label-switched-path lsp-name hierarchy and sufficient resources exist to establish
both LSPs, the primary and all secondary paths share the same bandwidth reservation (the higher of all bandwidths
defined). When adaptive is included at the primary or secondary hierarchy level, the SE-style reservation behavior is
enabled only for the path (primary or secondary) that is so configured. When specified at the primary and secondary level,
the corresponding primary and secondary paths are considered as separate adaptive settings, and therefore, their
resources are double-counted.

RSVP Reservation Styles

Fixed filter (FF): The FF-style reservation is commonly used for applications where traffic from each sender is likely to be
concurrent and independent. Each of the individual senders is identified by an IP address and an internal identification
number—an LSP ID.
When used with MPLS, the FF style allows the establishment of multiple, parallel, unicast, point-to-point LSPs to support
load balancing. If the LSPs share a common link, the total amount of reserved bandwidth for the shared link is the sum of
the reservations for the individual senders. By default, Junos OS uses the FF style.
Shared Explicit (SE): SE reservations share the bandwidth of the largest request across any shared links. The SE-style
reservation is critical for supporting the ability to reroute an LSP with the make-before-break capability because on shared
links, if reservations are counted twice, the router’s admission control function could reject the new LSP due to a lack of
resources. The SE reservation style permits the old and new LSPs to share resources over shared links. You can configure
SE-style reservations with the adaptive keyword under the LSP or primary/secondary path configuration hierarchy.

RSVP Reservation Styles (contd.)
It is extremely important that the flow of subscriber traffic is not disrupted when an LSP is rerouted. A smooth transition
requires support for a concept called make before break—the new LSP tunnel must be established and the traffic
transferred to it before the old LSP tunnel is torn down. One of the benefits of RSVP signaling is that the legacy SE
reservation style provides an elegant solution to this challenging problem.
Establishing the Initial LSP Tunnel: In the initial Path message, the ingress LSR:
1. Forms a LSP_TUNNEL_IPv4 SESSION object that uniquely identifies the LSP tunnel. The LSP_TUNNEL_IPv4
SESSION object contains: a) IP version 4 (IPv4) address of the egress node for the LSP tunnel, b) Tunnel_ID that
remains constant for the life of the LSP tunnel between the ingress and egress LSRs, and c) the
Extended_Tunnel_ID that identifies the ingress node of the tunnel (that is, the ingress router's IPv4 address).
2. Sets the ingress node might reroute bit of the SESSION_ATTRIBUTE object to request that the egress LSR use the
SE reservation style.
3. Forms a SENDER_TEMPLATE object that contains: a) The IPv4 address of the sender (ingress) node, and b) an
LSP_ID that can be changed in the future to allow the ingress LSR to appear as a different sender so it can share
resources with itself if the LSP needs to be rerouted (see the LSP_ID field of the LSP_TUNNEL_IPv4 C-type
extension for the SENDER_TEMPLATE and FILTER_SPEC objects).
4. Upon receipt of the Path message, the egress LSR sends a Resv message with a SE reservation style toward the
ingress node. When the ingress LSR receives the Resv message, the initial LSP tunnel is established with an SE
reservation style.
Establishing the Rerouted LSP Tunnel: When the ingress LSR wants to increase the bandwidth or change the path for an
existing LSP, it transmits a new Path message. During the reroute operation, the ingress LSR must appear as two different
senders to the RSVP session. This is achieved by including a new LSP_ID in the SENDER_TEMPLATE and the FILTER_SPEC
objects. In the new Path message, the ingress LSR:
1. Creates an EXPLICIT_ROUTE (ERO) object for the new LSP tunnel.
2. Uses the existing LSP_TUNNEL_IPv4 SESSION object to identify the LSP that will be rerouted.
3. Picks a new LSP_ID and creates a new SENDER_TEMPLATE. By selecting a new LSP_ID for the SENDER_TEMPLATE,
the ingress LSR appears as a different sender to the RSVP session.
4. The ingress LSR transmits the new Path message toward the egress LSR. (However, the ingress LSR continues to
use the old LSP tunnel to forward traffic and continues to refresh the original Path message.)
5. The egress LSR responds to the receipt of the new Path message with a Resv message that contains a number of
RSVP objects, including: a) A LABEL object to support the upstream on demand label distribution process, and b)
an SE reservation style object.
On links not shared by the old and new LSP tunnels, the new Path/Resv message pair is treated as a new conventional LSP
setup. However, on links that are traversed by both the old and the new LSP tunnels, the LSP_TUNNEL_IPv4 SESSION object
and SE reservation style allow the new LSP tunnel to be established so that it shares resources with the old LSP tunnel. This
eliminates the double counting problem on shared links. After the ingress LSR receives the Resv message for the new LSP, it
can begin using the new LSP tunnel to forward traffic. The ingress LSR should send a PathTear message for the old LSP
tunnel to remove its state from intermediate LSRs.

Check Your Knowledge: Adaptive

In the example on the slide, the secondary physical path Green will be in a down state. Although the adaptive keyword
indicates resources should not be double-counted, this behavior only applies to LSPs that are considered to belong to a
common session.
Because the adaptive keyword was specified at both the primary and secondary levels, the result is two independent
sessions that both signal an SE-style reservation. The fact that the two sessions are seen as being independent means that,
despite the SE-style reservations, the bandwidth requirements for the primary and secondary paths will be
double-counted. In this specific topology shown on the slide, this causes the secondary path to fail. Note that application of
the adaptive keyword at the LSP level, as shown here, allows the establishment of both primary and secondary paths with
a single session ID that does not incur double bandwidth counting.
[edit protocols mpls]
user@HongKong# show label-switched-path to-AM
to 192.168.24.1;
bandwidth 85m;
no-cspf;
adaptive;
primary Blue;
secondary Green {
standby;
adaptive;
}

We Discussed:
• The default traffic protection behavior of RSVP-signaled LSPs;
• The use of primary and secondary LSPs;
• LSP priority and preemption;
• Operation and configuration of fast reroute;
• Operation and configuration of link and node protection; and
• LSP optimization options.

Review Questions
1.
2.
3.

Lab: Traffic Protection


1.
When a primary is active and there is a failure along the path the ingress router will signal the secondary LSP to provide
protection for traffic while the primary is down.
2.
Fast reroute protects an entire LSP from failures along the path. Link protection provides protection for the failure of a single
link.
3.
Aggressive optimization only takes IGP metric into consideration. Normal optimization also takes into consideration number
of hops, congestion, and preemption.

Chapter 7: Fate Sharing

We Will Discuss:
• The behavior of fate sharing;
• How Shared Risk Link Groups (SRLG) change the Constrained Shortest Path First (CSPF) algorithm when
computing the secondary path of a LSP; and
• How extended administrative groups can be used to influence path selection.
Chapter 7–2 • Fate Sharing www.juniper.net

Junos OS Fate Sharing

www.juniper.net Fate Sharing • Chapter 7–3

Avoiding Common Points of Failure

The slide shows that a primary path is configured and signaled along the upper set of routers. Once the primary path is
established, the router is configured to establish a secondary path to act as a backup in the case the primary fails. By
default, the Junos OS attempts to establish the secondary path along a different set of links than the primary. This is done by
adding the CSPF metric of 8,000,000 to all links shared with the primary. Then, when the CSPF algorithm is computing the
secondary path, the links shared with the primary path will be less likely to be chosen simply based on their higher metric.
Still, if no alternative path can be found at the time of signaling, the secondary can still be signaled on a path that shares
some links with the primary.
For simplicity, we will consider the fate-sharing behavior between a primary and a secondary path. However, similar behavior
occurs between an LSP and its associated bypass LSPs for link protection, or with its detour LSPs for fast reroute.

CSPF Cannot Detect All Common Points of Failure

Unfortunately, not all common points of failure can be detected by CSPF. The fate sharing behavior cannot recognize on its
own when multiple links are traversing the same fiber, the same Ethernet switch, or the same point of presence (POP).The
example on the slide shows the primary being signaled along the R1-R3-R6 path. Even after 8,000,000 is added to the links
along the primary path, R1 will chose the R1-R4-R6 path for the secondary because of the lower IGP cost to the egress
router. Unfortunately, both primary and secondary paths are now traversing the same single point of failure, i.e. the Ethernet
Switch.

Ensuring That Secondary Paths Avoid Share Risks

The Junos OS fate sharing feature was introduced in release 7.4. The slide shows how you can group a set of links or nodes
together and associate a CSPF metric to them.
In the example on the slide, R1 determines that the primary path traverses one of the links or nodes in the
ethernet-switch fate sharing group. Prior to running the CSPF algorithm to compute the secondary path, R1 adds the
cost, 20000 in the example, to all links in the fate sharing group. Although the links in the group can still be used, they are
not chosen because the cost to get to R6 along the R1-R2-R5-R6 path is only 3,(compared to 20002 along the R1-R4-R6
path.

Fate Sharing Configuration Options

The slide shows how to configure members of a fates sharing group based on the interface type.
The fate sharing configuration will only effect new CSPF computations, and will not affect paths which have already been
signaled. To force a CSPF computation, you could wait until the optimize timer expires (if configured) or alternatively you can
issue the clear mpls lsp optimize command.

SRLG

SRLG Standard
The purpose of SRLG is defined in RFC 4202. SRLG relies on the distribution of SRLG values using the IGP similar to admin
groups. RFC 4203 describes the Open Shortest Path First (OSPF) extensions to support the distribution of SRLG information.
RFC 5307 describes the extensions to Intermediate System Intermediate System (ISIS) to support the distribution of SRLG
information.
When trying to understand SRLG, you should equate them to admin groups. Interfaces are associated with one or more
SRLG values. Just like admin groups, you configure a static table in the configuration that converts the numeric SRLG value
to a named value. Unlike admin groups, SRLG values assigned to an interface are not advertised as a single 32-bit value but
are instead advertised with one, unique 32-bit value for every assigned SRLG value. The slide shows that two SRLG values
(each 32-bits in length) that will be advertised by a router that has an interface assigned to two different SRLGs.

SRLG Relationship to Fate Sharing

SRLG solves the same problem as fate sharing. The goal of both features is to ensure that secondary paths are not signaled
along common points of failure.
Unlike fate sharing, there is no need to configure anything on the ingress router. Instead, as it happens with administrative
groups, the IGP distributes SRLG information. The ingress router can use this information to determine the path and SLRGs
that the primary path of an LSP crosses. When signaling the secondary path of an LSP, the ingress router will attempt to
avoid the SRLGs crossed by the primary path.

Name to Value Table

Each SLRG value is actually a 32-bit number. To make things more manageable, in order to use SRLG you must create a
table that maps the numeric SRLG value to a name. For each shared risk, you must specify a cost. After the signaling of the
primary path and prior to the CSPF calculation of a secondary path, this configured cost will be added to any links associated
with the same SRLGs traversed by the primary path. There are over 4 million possible SRLG values (2^32).

Interface Configuration
Like admin groups, SLRG are assigned to interfaces under the [edit protocols mpls] hierarchy. Use the show mpls
interface detail command to view the SRLGs that are currently assigned to your interfaces.

IGP SRLG Distribution

Once interfaces are configured with SRLG assignments, the router will propagate SRLG assignments using the IGP. The slide
shows the show ospf database command issued on R1, where you can see that the OpaqArea LSA from R3 is
advertising the SRLG switch1 with value1.

CSPF Calculation
The router, when signaling the secondary path, will automatically attempt to avoid the SRLGs that the primary path traverses.
As shown in the traceoptions output, the router simply adds the configured SRLG cost to the CSPF metric of the links
that belong to the SRLG.

Excluding SRLG
By default, it is possible for a secondary path to traverse the same SRLGs as of the primary path. This could happen because
there is no alternative path, or because the increase in metric due to the SRLG is not enough to make the path non-best.
If you would like the router to prune the SRLG links, apply the exclude-srlg configuration option to your LSP. This will
ensure that primary and secondaries will not have any common SRLG.

Extended Admin Groups


Admin Group Review

The slide shows the single, 32-bit field that is used to advertise standard admin groups. In the example, there are 5 bits set
in the admin group field. This means that there are 5 admin groups assigned to the interface that this value represents.
Unfortunately, since there are only 32 groups available, many customers have run out of groups and need more to work with.

SRLG/Admin Group Similarities

SRLG are similar in that they are both carried by the IGP to represent the characteristics of a router’s interfaces. Both are 32
bits in size.
SRLG/Admin Group Differences

Although both values are 32 bits in size, and SRLG value represents a single SRLG assignment. If a second SRLG is assigned
to an interface, the a second SRLG value is advertised in the link state information for that interface. Instead of interpreting
SRLG values as a bit field (like admin groups), it is interpreted as a numeric value. That means, that there are over 4 million
possible values for SRLGs. It is really unlikely that anybody would ever want to describe four million shared risks in the same
IGP domain, so an obvious question is, can we make any alternative use of the SRLG IGP infrastructure?

Repurposing SRLG Values

The Junos OS allows you to repurpose some of the 4 million SRLG values to be used as extended admin groups. The slide
shows how you must first specify the range of SRLGs that will be repurposed and interpreted as extended admin groups.
Then you must configure the extended admin group name-to-value table similar to how you would define standard admin
groups. All of this configuration is performed at the [edit routing-options] hierarchy.

Applying Extended Admin Groups to Interfaces

The next step is to simply assign the extended admin groups to your interfaces. Like admin groups, this is performed at the
[edit protocol mpls interface interface-name] hierarchy. Use the show mpls interface command to
view the extended admin groups that have been assigned your interfaces.

IGP Distribution
The slide shows how the extended admin groups are advertised along with the SRLG values (if any) that have been assigned
to interfaces. Although they are advertised as SRLG values, as long as they have correctly been repurposed at the [edit
routing-options] hierarchy they will be interpreted as extended admin groups.

Using Extended Administrative Groups

Now that the extended admin groups are being distributed by the IGP, you use them similar to how you would use standard
admin groups. As you can see in the slide, the only difference is that you must refer to them as admin-group-extended
in the configuration.

We Discussed:
• The behavior of fate sharing;
• How SRLG configuration changes the CSPF algorithm when computing the path of a secondary multiprotocol
LSP; and
• How extended admin groups can be used to influence path selection.

Review Questions:
1.
2.
3.

Lab: Fate Sharing


1.
By default, a Juniper router attempts to avoid the links traversed by the primary path when signaling the secondary path. It does
this by adding 8000000 to the CSPF metric of the links traversed by the primary path prior to running the CSPF algorithm for the
secondary path.
2.
Because SRLG values are distributed using the IGP, an ingress router is aware of the SRLGs that the primary path of an LSP
traverses. Every SRLG values will have a configured cost on the ingress router. During the CSPF calculation for the secondary
LSP, this configured cost will be added to any links associated with the same SRLGs traversed by the primary path.
3.
Extended admin groups are simply repurposed SRLG values that are to be used for the same purpose as admin groups. Once
they have been repurposed, they can be used like admin groups to determine the path of both primary and secondary LSPs.

Chapter 8: Miscellaneous MPLS Features

We Will Discuss:
• The purpose of several miscellaneous MPLS features.
Chapter 8–2 • Miscellaneous MPLS Features www.juniper.net

Forwarding Adjacencies
www.juniper.net Miscellaneous MPLS Features • Chapter 8–3

Establishing an IGP Adjacency Over LSPs

Forwarding adjacencies allow to establish an IGP adjacency over a pair of matching RSVP-signaled LSPs, which are then
distributed into the IGP and treated as a point-to-point link. This allows RSVP traffic engineering even for IGP destinations.
Forwarding adjacencies might be useful in a network that uses RSVP traffic-engineered LSPs between core routers.
Forwarding adjacencies allow edge routers to utilize traffic-engineered LSPs in the core without extending RSVP
traffic-engineered LSPs to all routers.
Both ISIS and OSPF are supported. The configuration for both protocols is similar, and very straightforward: the LSP to the
remote side of the adjacency is simply configured as if it were a regular ISIS or OSPF interface. It is also possible, and
generally it is very useful, to manually assign a metric to the LSP, as you would do with any IGP interface.

Control Plane Example

From the control plane point of view, the forwarding adjacency behaves just like any other adjacency. This is reflected in the
output of commands like show ospf neighbor or show isis adjacency, where the LSP to the remote side is
displayed as if it were an interface.
Remember that LSPs are unidirectional. IS-IS requires that an LSP have a corresponding LSP in the reverse direction before
advertising the forwarding adjacency in link-state advertisements. OSPF only requires the reverse direction to have IP-level
reachability (by means of an LSP or a routed path) before advertising the forwarding adjacency in link-state advertisements.
In both IS-IS and OSPF the LSP is advertised into the IGP, but no hellos or routing updates occur over the LSP, only user
traffic is sent over the LSP. IS-IS and OSPF rely on RSVP to detect LSP-down events.
Control Plane Caveat: Do Not Use no-cspf LSPs If You Plan to Use Forwarding Adjacencies
You should only use Constrained Shortest Path First (CSPF) LSPs when deploying forwarding adjacencies. Forwarding
adjacencies are not placed into the Traffic Engineering Database, as they do not run MPLS. Because of this, CSPF will never
compute a path which crosses a forwarding adjacency.
If you use LSPs with the no-cspf configuration option, it is possible that RSVP may attempt to establish a new LSP over a
forwarding adjacency due to its lower IGP cost, which will cause the LSP setup to fail.

Policy Control over LSP Selection


Controlling LSP Next Hops Installation Via Policies

When multiple equal-cost LSPs to a destination exist, you can use a policy to control which LSP gets installed in the
forwarding table. This control provides fine-grained traffic engineering capabilities, and allows the design and
implementation of MPLS services fine-tuned to the underlying network characteristics.
In the example a LSP is chosen on the basis of a route filter, but more often other conditions on route attributes are used. For
example, it is possible to forward traffic to destinations tagged with a given BGP community over a dedicated set of LSP.

Controlling LSP Next Hops Installation Via Policies (contd.)
To use this feature, set install-nexthop lsp lsp-name as the action in a policy, and then apply the policy to the
forwarding table. The configuration on the slide will install LSP-1 as the next hop for the 192.168.48.0/24 prefix and LSP-2
as the next hop for the 192.168.49.0/24 prefix. You can then use the show route command to confirm the effect of the
policy:
user@R7> show route 192.168.48.0/24 exact

+ = Active Route, - = Last Active, * = Both
192.168.48.0/24 *[BGP/170] 2d 06:23:21, MED 0, localpref 100, from 192.168.1.4

AS path: I
> to 172.22.211.2 via ge-1/0/1.211, label-switched-path LSP-1
user@R7> show route 192.168.49.0/24 exact

+ = Active Route, - = Last Active, * = Both
192.168.49.0/24 *[BGP/170] 00:20:29, MED 0, localpref 100, from 192.168.1.4

AS path: I
> to 172.22.210.2 via ge-1/0/0.210, label-switched-path LSP-2

LSP Metrics

Metrics Used by CSPF

By default, CSPF uses the default IGP metric when computing best paths. For IS-IS, you can assign a te-metric on each
interface that is only used for CSPF, while the IS-IS link-state database continues to utilize the standard IS-IS link metric.
CSPF will use either the IGP metric or the te-metric value when configured. In essence, the te-metric option allows
you to have an IS-IS shortest path topology that differs from the TEDs view of the shortest path through your network.
Metrics Used for LSP Selection

By default, each LSP inherits the IGP’s shortest-path metric, regardless of whether or not the LSP actually follows the
shortest path. You can override the value derived from the TED by explicitly specifying an LSP metric value within the LSP’s
definition using the metric keyword.
When using forwarding adjacencies, you can also explicitly specify an LSP metric along with the LSP’s declaration in the
corresponding IGP stanza. To avoid awkward forwarding situations, you should only explicitly assign a metric in the MPLS
definition OR in the LSP’s reference within the IGP; we recommend that you do not assign a metric in both places.

Automatic Bandwidth

Automatic Bandwidth Provisioning

Automatic bandwidth provisioning allows the router to monitor actual traffic usage on LSPs and reconfigure their bandwidth
to support observed traffic levels.
The MPLS statistics feature gathers utilization data that are then used for automatic bandwidth calculation. The router
monitors the highest utilization levels for the LSP over a predefined time period, 24 hours by default. At the end of the time
period, the existing LSP is resignaled with an updated bandwidth reservation, using make-before-break and shared explicit
(SE)-style reservations.

Configure Automatic Bandwidth Provisioning

This slide provides a sample configuration in support of automatic bandwidth provisioning. Note that MPLS statistics must
be enabled to allow the router to monitor traffic usage. By default, the router monitors usage every 300 seconds. If the
average utilization over the adjustment interval exceeds a certain value, the router resignals the LSP. The following options
are available for automatic bandwidth provisioning:
Option Meaning
adjust-interval Time to adjust LSP bandwidth (300..4294967295
seconds)
adjust-threshold Change in average LSP utilization to trigger

auto-adjustment
maximum-bandwidth Maximum LSP bandwidth (bps)
minimum-bandwidth Minimum LSP bandwidth (bps)
monitor-bandwidth Monitor LSP bandwidth without adjustments

Monitor Automatic Bandwidth Provisioning

The operational aspects of automatic bandwidth provision is displayed in the output of a show mpls lsp extensive
command.

Container LSPs

Challenges with Auto-Bandwidth

Even if auto-bandwidth has proven extremely successful in helping improve network utilization and efficiency,
operational experience showed it is not a fully automatic solution: sometimes LSPs require manual intervention, for example
to re-balance traffic among a set of LSPs. These issue stem from two main causes:
All-or-None Reservation
RSVP reservation either succeed in allocating the requested bandwidth, or they fail. This all-or-nothing behavior does not
allow - for example - to split the LSP and allocate the requested bandwidth over separate paths going the same egress point.
This can lead to inefficiencies, as some capacity between endpoints is not used.
Non-Optimal Distribution of LSPs on Available Links

Mapping LSPs to a topology in the most efficient way is a computationally difficult problem, even more so when the actual
mapping of LSPs to links is done in a distributed way by each ingress router. This problem is known in literature as bin
packing problem, and is a generalization of the more famous Knapsack problem.
Even if finding an optimal solution is difficult, reasonably good solutions can be found if it is possible to split LSPs into
lower-bandwidth, easier-to-manage sub-LSP, that can then be mapped over independent paths. This is the idea of container
LSPs.

A Solution: Container LSPs

To ease the limitation of auto-bandwidth with ordinary LSPs, Juniper introduced a new construct, called container LSP. A
container LSP is composed of multiple, dynamically signaled member LSPs, whose number and bandwidth is driven by
actual traffic levels. Since member LSPs can take independent paths, it is possible to make use of all available bandwidth
between two endpoints, distributing traffic among the member LSPs.
Each container LSP goes through a periodic normalization process, where new LSPs are signaled if needed, or existing LSPs
are merged together if traffic levels decrease. The split and merge thresholds as well as the normalization interval are
configurable.

Container LSP Configuration

On the slide you can see the full configuration of a container LSP. From the definition, you can see that a minimum of 2 and
a maximum of 20 LSPs are going to be dynamically created. The normalization interval is of 400 seconds, a very low value,
but useful in a lab environment.
All dynamic member LSPs are signaled according to a template; in this case, the template was used to configure
auto-bandwidth parameters as well as a number of other features (adaptive, link-protection).
For more information about container LSP and other features designed to help improving the efficiency of a MPLS-enabled
network, please see the whitepaper “Maximize Bandwidth Utilization with Juniper Networks TE++” available on the Juniper
Networks website.

TTL Handling

Default TTL Behavior

By default, the time-to-live (TTL) value in the packet header is decremented by 1 for every hop the packet traverses, thereby
preventing loops and allowing topology discovery. If the TTL field value reaches 0, packets are dropped and an Internet
Control Message Protocol (ICMP) error packet can be sent to the originating router. You might want to disable normal TTL
decrementing to make the MPLS cloud appear transparent, thereby hiding the network topology.
The normal TTL handing behavior maps the IP packet's TTL value into the MPLS TTL field on the ingress router. When the
MPLS packet leaves the router, it is decremented by one, as shown in the slide. Each transit label-switching router (LSR)
decrements the TTL field by one until the packet reaches the penultimate hop. At the penultimate hop, the penultimate
router strips off the top label and writes the MPLS TTL value back into the IP TTL value. The egress router decrements the IP
TTL by one. The TTL values are indicated for every hop in the path on the slide.

MPLS TTL Handling: No Decrement

On the ingress of the LSP, if you include the no-decrement-ttl statement at the
[edit protocols mpls label-switched-path lsp-name] hierarchy, the ingress router negotiates with all
downstream routers using a proprietary RSVP object to ensure all routers are in agreement. This command can also be typed
within the primary or secondary path hierarchy. If negotiation succeeds, the whole LSP appears as two hops for transit IP
traffic.
[edit protocols mpls label-switched-path lsp-name]
user@R1# set no-decrement-ttl
Note that the RSVP object is proprietary to the Junos OS and might not work with other vendors. Further, this potential
incompatibility applies only to RSVP-signaled LSPs, not LDP-signaled LSPs. Also note that you can apply
no-decrement-ttl on a per-LSP basis or globally under the [edit protocols mpls] hierarchy.
If normal TTL decrement is disabled, the TTL field of IP packets entering LSPs are decremented by 1 upon transiting the LSP,
making the LSP appear as a two-hop router to diagnostic tools like traceroute. This function is performed by the ingress
router, which pushes a label on IP packets with the TTL field in the label initialized to 255. The label's TTL field value is
decremented by 1 for every hop the MPLS packet traverses in the LSP. On the penultimate hop of the LSP, the router pops
the label but does not write the label's TTL field value to the IP packet's TTL field. Instead, when the IP packet reaches the
egress router, the IP packet's TTL field value is decremented by 1.
When you use traceroute to diagnose problems with an LSP, traceroute sees the ingress router, although the egress router
performs the TTL decrement. Note that this assumes that traceroute is initiated outside of the LSP. The behavior of
traceroute is different if it is initiated from the ingress router of the LSP. In this case, the egress router would be the first
router to respond to traceroute.

MPLS TTL Handling: No Propagate

You must include the no-propagate-ttl statement at the [edit protocols mpls] hierarchy level of all routers in
the path of the LSP for proper operation, which is in contrast to the ingress based setting for the no-decrement-ttl
option. Note that this statement applies to all LSPs in a global manner, regardless of whether they are RSVP or LDP signaled.
Once set, all future LSPs traversing through this router behave as a single hop to IP packets. LSPs established before this
statement is committed are not affected. Note that this option affects RSVP-signaled LSPs, despite its being configured
under the [edit protocol mpls] hierarchy:
[edit protocols mpls]
user@R1# set no-propagate-ttl
Make sure all routers are configured consistently within an MPLS domain when using no-propagate-ttl; failing to do so
might cause the IP packet TTL to increase while in transit within LSPs. This can happen, for example, when the ingress router
has no-propagate-ttl configured but the penultimate router does not, which results in the penultimate router writing
the MPLS TTL value (which starts from the ingress router as 255) back into the IP packet.
The no-propagate-ttl option is designed to be interoperable with equipment made by other vendors. However, you
must ensure all routers are configured identically.

MPLS TTL Handling: No Propagate (contd.)
The no-propagate-ttl option also causes the MPLS cloud to show up as two hops from the perspective of IP packets
transiting the LSP.
The penultimate router pops the label and forwards the IP packet, but does not copy the MPLS TTL value back into the IP
packet’s TTL field. The egress router then decrements the IP packet, thereby making the cloud appear as if it consisted of
only two hops.
Note that with either option (no-propagate-ttl and no-decrement-ttl), the ingress router decrements the IP
packet’s TTL by one prior to placing the MPLS shim label on incoming packets. This performance is to prevent the possibility
of an endless routing loop (formed when two LSPs have a routing loop pointing at each other). If the IP TTL were not
decremented by one on ingress, the egress router would encapsulate the IP packet with a new MPLS header without
decrementing the IP TTL. If the two routers have a routing loop, the packet would loop to infinity.

Explicit Null Configuration


Configuring Explicit Null

Penultimate-hop popping can create problems for Class of Service designs that use the TC bits (also known as EXP bits) to
mark MPLS frames as belonging to a given forwarding class. Since the MPLS shim header (and the TC bits) are removed at
the penultimate hop, the egress router will have to use other criteria to assign frames to forwarding class, creating additional
complexity.
With the Junos OS you can turn off the default PHP behavior from configuration. In operation, the egress router will signal
label 0 upstream instead of label 3. As a result, the same CoS configuration used at transit LSRs can now also be used for
the egress router.
This feature is configured globally for either MPLS or LDP. The implementation is compliant with RFC 3032, “MPLS Label
Stack Encoding”.

MPLS Pings

MPLS Ping Utility

The slide illustrates the operation of the MPLS ping capability. By adding the mpls switch to a standard ping command, you
can now verify the forwarding plane of RSVP-signaled or LDP-signaled LSPs. For RSVP-signaled LSPs, you specify the LSP
name as the target for the MPLS ping.
Note that the target address of an MPLS ping is hard-coded to 127.0.0.1; the LSP’s egress node must have a 127.0.0.1
address assigned to its loopback interface for the MPLS ping to succeed.The Junos OS automatically creates a lo0.16384
with the 127.0.0.1/32 address assigned. You might however, need to manually assign the 127.0.0.1/32 address if the
egress router is not running the Junos OS. You can verify the loopback address is present on the egress router by issuing the
show interfaces terse | match lo0 operational mode command on the egress router.
user@R4> show interfaces terse | match lo0
lo0 up up
lo0.0 up up inet 192.168.1.4 --> 0/0
lo0.16384 up up inet 127.0.0.1 --> 0/0
lo0.16385 up up inet
The detail switch provides additional output:
user@R1> ping mpls rsvp test count 1 detail
Request for seq 1, to interface 9, labels <100096, 0, 0>
Reply for seq 1, return code: Egress-ok
--- lsping statistics ---

1 packets transmitted, 1 packets received, 0% packet loss

We Discussed:
• Several miscellaneous MPLS features; and
• Features that fulfill some given design requirements.

Review Questions
1.
2.

Lab: Miscellaneous MPLS Features


1.
The default resignaling interval is 24 hours when using the auto-bandwidth feature.
2.
First no-decrement-ttl is only configured on the ingress router and no-propagate-ttl must be configured on all
LSRs in the path. Second, using no-decrement-ttl allows you to change default behavior on a per LSP basis while
no-propagate-ttl is only allowed at the global level and applies to all LSPs.


Acronym List
ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Augmented Backus-Naur Form
ABR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . area border router
AI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . advanced insight
AI-Scripts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Advanced Insight Scripts
AIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . advanced insight solution
API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .application programming interface
APS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Automatic Protection Switching
ASAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Automated Support and Prevention
ASIC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .application-specific integrated circuit
CDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cisco Discovery Protocol
CES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . circuit emulation services
CFM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .connectivity fault management
CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .command-line interface
CoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . class-of-service
CSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Constrained Shortest Path First
CSV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . comma-separated variable
DMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Device Management Interface
DWR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Direct Web Remoting
eJMB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . errored reactive JMB
ELAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . emulated LAN
ELINE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Ethernet private line
EMS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . enterprise management system
EOE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . end of engineering
EOL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . end of life
EOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . end of support
ERO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . EXPLICIT_ROUTE object
ETREE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Ethernet tree
FCoE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fibre Channel over Ethernet
FF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . fixed filter
FRU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . field-replaceable unit
GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .graphical user interface
HMAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Hashed Message Authentication Code
HTML. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hypertext Markup Language
HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hypertext Transfer Protocol
HTTPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hypertext Transfer Protocol over Secure Sockets Layer
ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Internet Control Message Protocol
IDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Integrated Development Environment
IEEE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Institute of Electrical and Electronics Engineers
IGP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interior Gateway Protocol
iJMB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . intelligence-based Juniper Message bundle
ILP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .inventory landing page
IPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . intrusion prevention system
IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IP Security
IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IP version 4
IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IP version 6
IS-IS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Intermediate System-to-Intermediate System
ISV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . independent software vendor
JDBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Java Database Connectivity
JMB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Juniper Message Bundle
JNCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Juniper Networks Certification Program
JSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Juniper Support Services
JTAC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Juniper Networks Technical Assistance Center
LAG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . link aggregation group
LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Label Distribution Protocol
LLDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Link Layer Discovery Protocol
www.juniper.net Acronym List • ACR–1

LSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . label-switched path
LSR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .label-switching router
LSYS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . logical systems
MAC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . media access control
MEP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . maintenance association end point
MTTR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .mean time to resolution
NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Network Address Translation
NBI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . North Bound Interface
NIC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .network interface card
N-PE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . network provider edge
NSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Network and Security Manager
NSOR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . network as system of record
NTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Network Time Protocol
OAM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Operation, Administration, and Maintenance
OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Open Shortest Path First
OSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . operations support systems
PBN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Proactive Bug Notification
PE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . provider edge
PFE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Packet Forwarding Engine
PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .penultimate-hop-popping
PR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Problem Report
PSN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Public Service Notification
PTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Precision Time Protocol
PWE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pseudowire emulation
QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . quality of service
RBAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . role-based access system
RED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . random early detection
RESTful . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . representational state transfer
RHEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Red Hat Enterprise Linux
RPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . remote procedure call
RRO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Record Route Object
RSTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Rapid Spanning Tree Protocol
SAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . storage area network
scp. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .secure copy
SCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Secure Copy Protocol
SDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . software development kit
SE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sales Engineer
SKU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . stock keeping unit
SLA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .service-level agreement
SME. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .subject matter expert
SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Simple Network Management Protocol
SNMPv2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Simple Network Management Protocol version 2
SNMPv3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Simple Network Management Protocol version 3
SRLG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Shared Risk Link Group
SyncE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . synchronous Ethernet
TCO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . total cost of ownership
TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Transmission Control Protocol
TED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Traffic Engineering Database
TLV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . type/length/value
TSpec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . traffic speculation
TTL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . time-to-live
UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .User Datagram Protocol
UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . user interface
UNI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . user-to-network interface
UTM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .universal threat management
VCID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . virtual circuit identifier
vDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .VMware vNetwork Distributed Switch
VEPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Virtual Ethernet Port Adapter
vGW. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Virtual Gateway
VID. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VLAN identifier
ACR–2 • Acronym List www.juniper.net

VIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . virtual IP
VLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .virtual LAN
VM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .virtual machine
VNIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . virtual NIC
VoIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . voice over IP
VPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . virtual private LAN service
VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . virtual private network
VSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vendor-specific attribute
XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Extensible Markup Language
XSD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XML Schema Definition Language
www.juniper.net Acronym List • ACR–3

ACR–4 • Acronym List www.juniper.net

Junos MPLS Fundamentals Student Guide, Revision V-16.a

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Junos MPLS Fundamentals Student Guide, Revision V-16.a

Transféré par

Droits d'auteur :

Formats disponibles

Junos MPLS Fundamentals

Worldwide Education Services

1133 Innovation Way

Course Number: EDU-JUN-JMF

Chapter 1: Course Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1

Chapter 2: MPLS Fundamentals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

Chapter 3: Label Distribution Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

Chapter 4: LSPs and Routing Table Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

Chapter 5: Constrained Shortest Path First . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

Chapter 6: Traffic Protection and LSP Optimization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1

www.juniper.net Contents • iii

Chapter 8: Miscellaneous MPLS Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1

Acronym List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ACR-1

www.juniper.net Course Overview • v

vi • Course Agenda www.juniper.net

CLI and GUI Text

Style Description Usage Example

Courier New Console text:

Input Text Versus Output Text

Style Description Usage Example

Normal CLI No distinguishing variant. Physical interface:fxp0,

Defined and Undefined Syntax Variables

Style Description Usage Example

CLI Variable Text where variable value is already policy my-peers

www.juniper.net Document Conventions • vii

Education Services Offerings

viii • Additional Information www.juniper.net

Chapter 1: Course Introduction

Chapter 1–2 • Course Introduction www.juniper.net

www.juniper.net Course Introduction • Chapter 1–3

Chapter 1–4 • Course Introduction www.juniper.net

www.juniper.net Course Introduction • Chapter 1–5

General Course Administration

Chapter 1–6 • Course Introduction www.juniper.net

Training and Study Materials

www.juniper.net Course Introduction • Chapter 1–7

Chapter 1–8 • Course Introduction www.juniper.net

www.juniper.net Course Introduction • Chapter 1–9

Juniper Networks Education Services Curriculum

Chapter 1–10 • Course Introduction www.juniper.net

Juniper Networks Certification Program

www.juniper.net Course Introduction • Chapter 1–11

Juniper Networks Certification Program Overview

Chapter 1–12 • Course Introduction www.juniper.net

Preparing and Studying

www.juniper.net Course Introduction • Chapter 1–13

Chapter 1–14 • Course Introduction www.juniper.net

www.juniper.net Course Introduction • Chapter 1–15

Chapter 1–16 • Course Introduction www.juniper.net

Chapter 2: MPLS Fundamentals

Chapter 2–2 • MPLS Fundamentals www.juniper.net

www.juniper.net MPLS Fundamentals • Chapter 2–3

Chapter 2–4 • MPLS Fundamentals www.juniper.net

Service Providers and IGP Metrics

www.juniper.net MPLS Fundamentals • Chapter 2–5

IGP Metrics Give Network Operators Very Little Control

IGP Metrics Lack Optimization Capabilities

Chapter 2–6 • MPLS Fundamentals www.juniper.net

Core Limitations of IGP Metrics

www.juniper.net MPLS Fundamentals • Chapter 2–7

The MPLS Solution

Chapter 2–8 • MPLS Fundamentals www.juniper.net

Other MPLS Applications