Junos® OS

MPLS Applications Configuration Guide

Release

12.1

Published: 2012-03-13

Copyright © 2012, Juniper Networks, Inc.

Juniper Networks, Inc.
1194 North Mathilda Avenue
Sunnyvale, California 94089
USA
408-745-2000
www.juniper.net
This product includes the Envoy SNMP Engine, developed by Epilogue Technology, an Integrated Systems Company. Copyright © 1986-1997,
Epilogue Technology Corporation. All rights reserved. This program and its documentation were developed at private expense, and no part
of them is in the public domain.

This product includes memory allocation software developed by Mark Moraes, copyright © 1988, 1989, 1993, University of Toronto.

This product includes FreeBSD software developed by the University of California, Berkeley, and its contributors. All of the documentation
and software included in the 4.4BSD and 4.4BSD-Lite Releases is copyrighted by the Regents of the University of California. Copyright ©
1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994. The Regents of the University of California. All rights reserved.

GateD software copyright © 1995, the Regents of the University. All rights reserved. Gate Daemon was originated and developed through
release 3.0 by Cornell University and its collaborators. Gated is based on Kirton’s EGP, UC Berkeley’s routing daemon (routed), and DCN’s
HELLO routing protocol. Development of Gated has been supported in part by the National Science Foundation. Portions of the GateD
software copyright © 1988, Regents of the University of California. All rights reserved. Portions of the GateD software copyright © 1991, D.
L. S. Associates.

This product includes software developed by Maker Communications, Inc., copyright © 1996, 1997, Maker Communications, Inc.

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.

Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right to change, modify,
transfer, or otherwise revise this publication without notice.

Products made or sold by Juniper Networks or components thereof might be covered by one or more of the following patents that are
owned by or licensed to Juniper Networks: U.S. Patent Nos. 5,473,599, 5,905,725, 5,909,440, 6,192,051, 6,333,650, 6,359,479, 6,406,312,
6,429,706, 6,459,579, 6,493,347, 6,538,518, 6,538,899, 6,552,918, 6,567,902, 6,578,186, and 6,590,785.

®
Junos OS MPLS Applications Configuration Guide
Release 12.1
Copyright © 2012, Juniper Networks, Inc.
All rights reserved.

Revision History
February 2012—R1 Junos OS 12.1

The information in this document is current as of the date on the title page.

YEAR 2000 NOTICE

Juniper Networks hardware and software products are Year 2000 compliant. Junos OS has no known time-related limitations through the
year 2038. However, the NTP application is known to have some difficulty in the year 2036.

END USER LICENSE AGREEMENT

The Juniper Networks product that is the subject of this technical documentation consists of (or is intended for use with) Juniper Networks
software. Use of such software is subject to the terms and conditions of the End User License Agreement (“EULA”) posted at
http://www.juniper.net/support/eula.html. By downloading, installing or using such software, you agree to the terms and conditions
of that EULA.

ii Copyright © 2012, Juniper Networks, Inc.

Abbreviated Table of Contents
About This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxvii

Part 1 Overview
Chapter 1 Traffic Engineering Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Chapter 2 Complete MPLS Applications Configuration Statements . . . . . . . . . . . . . . . . 9

Part 2 MPLS
Chapter 3 MPLS Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Chapter 4 MPLS Router Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Chapter 5 MPLS-Signaled LSP Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . . 143
Chapter 6 DiffServ-Aware Traffic Engineering Configuration Guidelines . . . . . . . . . . 187
Chapter 7 Static and Explicit-Path LSP Configuration Guidelines . . . . . . . . . . . . . . . . . 211
Chapter 8 Point-to-Multipoint LSP Configuration Guidelines . . . . . . . . . . . . . . . . . . . . 221
Chapter 9 Miscellaneous MPLS Properties Configuration Guidelines . . . . . . . . . . . . . 247
Chapter 10 Summary of MPLS Configuration Statements . . . . . . . . . . . . . . . . . . . . . . . 273

Part 3 RSVP
Chapter 11 RSVP Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
Chapter 12 RSVP Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
Chapter 13 Summary of RSVP Configuration Statements . . . . . . . . . . . . . . . . . . . . . . . 425

Part 4 LDP
Chapter 14 LDP Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463
Chapter 15 LDP Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
Chapter 16 Summary of LDP Configuration Statements . . . . . . . . . . . . . . . . . . . . . . . . 503

Part 5 CCC and TCC

Chapter 17 CCC and TCC Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 539
Chapter 18 CCC and TCC Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543
Chapter 19 Summary of CCC and TCC Configuration Statements . . . . . . . . . . . . . . . . 565

Part 6 GMPLS
Chapter 20 GMPLS Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579
Chapter 21 GMPLS Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585

Copyright © 2012, Juniper Networks, Inc. iii

Junos OS 12.1 MPLS Applications Configuration Guide

Chapter 22 Hierarchy of RSVP LSPs Configuration Guidelines . . . . . . . . . . . . . . . . . . . . 601

Chapter 23 Summary of GMPLS Configuration Statements . . . . . . . . . . . . . . . . . . . . . 607

Part 7 Indexes
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 627
Index of Statements and Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 647

iv Copyright © 2012, Juniper Networks, Inc.

Table of Contents
About This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxvii
Junos OS Documentation and Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . xxvii
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxviii
Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxviii
Supported Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxviii
Using the Indexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxix
Using the Examples in This Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxix
Merging a Full Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxix
Merging a Snippet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxx
Documentation Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxx
Documentation Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxii
Requesting Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxii
Self-Help Online Tools and Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxiii
Opening a Case with JTAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxiii

Part 1 Overview
Chapter 1 Traffic Engineering Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Traffic Engineering Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Components of Traffic Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Packet Forwarding Component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Packet Forwarding Based on Label Swapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
How a Packet Traverses an MPLS Backbone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Information Distribution Component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Path Selection Component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Offline Planning and Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Signaling Component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Flexible LSP Calculation and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Chapter 2 Complete MPLS Applications Configuration Statements . . . . . . . . . . . . . . . . 9
[edit logical-systems] Hierarchy Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
[edit protocols connections] Hierarchy Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
[edit protocols ldp] Hierarchy Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
[edit protocols link-management] Hierarchy Level . . . . . . . . . . . . . . . . . . . . . . . . . 12
[edit protocols mpls] Hierarchy Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
[edit protocols rsvp] Hierarchy Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Copyright © 2012, Juniper Networks, Inc. v

Junos OS 12.1 MPLS Applications Configuration Guide

Part 2 MPLS
Chapter 3 MPLS Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
MPLS Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Supported MPLS Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Link-Layer Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
MPLS and Traffic Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Label Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Special Labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Label Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Operations on Labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Routers in an LSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
How a Packet Travels Along an LSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Types of LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Scope of LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Constrained-Path LSP Computation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
How CSPF Selects a Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Path Selection Tie-Breaking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Computing Paths Offline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
LSPs on an Overloaded Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Fate Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
SRLG Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
IGP Shortcuts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Enabling IGP Shortcuts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
LSPs Qualified in Shortcut Computations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
IGP Shortcut Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
IGP Shortcuts and Routing Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
IGP Shortcuts and VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Advertising LSPs into IGPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
IP and MPLS Packets on Aggregated Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
MPLS Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
BGP Destinations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
IGP and BGP Destinations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Selecting a Forwarding LSP Next Hop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
MPLS and Routing Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
MPLS and Traffic Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Fast Reroute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Fast Reroute Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Detour Merging Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Detour Computations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Fast Reroute Path Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Automatic Bandwidth Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Point-to-Multipoint LSPs Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

vi Copyright © 2012, Juniper Networks, Inc.

 Table of Contents

Chapter 4 MPLS Router Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Minimum MPLS Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Configuring the Ingress Router for MPLS-Signaled LSPs . . . . . . . . . . . . . . . . . . . . 56
Creating Named Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Examples: Creating Named Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Configuring Alternate Backup Paths Using Fate Sharing . . . . . . . . . . . . . . . . 58
Configuring Fate Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Implications for CSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Example: Configuring Fate Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Example: Configuring a Constrained-Path LSP for Which Junos OS Makes All
Forwarding Decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Example: Configuring an Explicit-Path LSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Example: Configuring a Constrained-Path LSP for Which Junos OS Makes Most
Forwarding Decisions and Considers Hop Constraints . . . . . . . . . . . . . . . . . . 62
Example: Configuring a Constrained-Path LSP for Which Junos OS Makes Most
Forwarding Decisions and the Secondary Path Is Explicit . . . . . . . . . . . . . . . 62
Configuring the Intermediate and Egress Routers for MPLS-Signaled LSPs . . . . . 63
Improving Traffic Engineering Database Accuracy with RSVP PathErr
Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
PathErr Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Identifying the Problem Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Configuring the Router to Improve Traffic Engineering Database
Accuracy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Configuring MPLS-Signaled LSPs to Use GRE Tunnels . . . . . . . . . . . . . . . . . . . . . 66
Example: Configuring MPLS-Signaled LSPs to Use GRE Tunnels . . . . . . . . . 66
Example: Tunneling IPv6 Traffic over MPLS IPv4 Networks . . . . . . . . . . . . . . . . . . 67
Configuring ICMP Message Tunneling for MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Example: Configuring SRLG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Example: Excluding SRLG Links Completely for the Secondary LSP . . . . . . . . . . . 85
Example: Configuring SRLG With Link Protection . . . . . . . . . . . . . . . . . . . . . . . . . 90
Example: Configuring SRLG With Link Protection With the exclude-srlg
Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Configuring the MPLS Transport Profile for OAM . . . . . . . . . . . . . . . . . . . . . . . . . 129
MPLS Transport Profile Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Example: Configuring the MPLS Transport Profile for OAM . . . . . . . . . . . . . 130
Chapter 5 MPLS-Signaled LSP Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . . 143
LSP Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Configuring the Ingress and Egress Router Addresses for LSPs . . . . . . . . . . . . . . 147
Configuring the Ingress Router Address for LSPs . . . . . . . . . . . . . . . . . . . . . . 147
Configuring the Egress Router Address for LSPs . . . . . . . . . . . . . . . . . . . . . . 148
Preventing the Addition of Egress Router Addresses to Routing Tables . . . . 148
Configuring Primary and Secondary LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Configuring Primary and Secondary Paths for an LSP . . . . . . . . . . . . . . . . . . 150
Configuring the Revert Timer for LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Specifying the Conditions for Path Selection . . . . . . . . . . . . . . . . . . . . . . . . . 151
Configuring a Text Description for LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Configuring Fast Reroute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Configuring the Optimization Interval for Fast Reroute Paths . . . . . . . . . . . . . . . 154

Copyright © 2012, Juniper Networks, Inc. vii

Junos OS 12.1 MPLS Applications Configuration Guide

Adding LSP-Related Routes to the inet.3 Routing Table . . . . . . . . . . . . . . . . . . . . 154

Configuring the Connection Between Ingress and Egress Routers . . . . . . . . . . . . 155
Configuring LSP Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Configuring Dynamic LSP Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Configuring Static LSP Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Configuring CSPF Tie Breaking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Configuring Load Balancing Based on MPLS Labels . . . . . . . . . . . . . . . . . . . . . . . 158
Disabling Normal TTL Decrementing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Configuring MPLS Soft Preemption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Configuring Automatic Bandwidth Allocation for LSPs . . . . . . . . . . . . . . . . . . . . 163
Configuring MPLS Statistics for Automatic Bandwidth Allocation . . . . . . . . 164
Configuring Automatic Bandwidth Allocation on LSPs . . . . . . . . . . . . . . . . . 165
Configuring the Automatic Bandwidth Allocation Interval . . . . . . . . . . . 165
Configuring the Maximum and Minimum Bounds of the LSP’s
Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Configuring the Automatic Bandwidth Adjustment Threshold . . . . . . . 166
Configuring a Limit on Bandwidth Overflow and Underflow
Samples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Configuring Passive Bandwidth Utilization Monitoring . . . . . . . . . . . . . . 169
Requesting Automatic Bandwidth Allocation Adjustment . . . . . . . . . . . . . . 169
Disabling Constrained-Path LSP Computation . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Configuring Administrative Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Configuring Extended Administrative Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Configuring Preference Values for LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Disabling Path Route Recording . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Configuring Class of Service for MPLS LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Class of Service for MPLS Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Configuring the MPLS CoS Bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Rewriting IEEE 802.1p Packet Headers with the MPLS CoS Value . . . . . . . . . 177
Configuring Adaptive LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Configuring Priority and Preemption for LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Optimizing Signaled LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Configuring the Smart Optimize Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Limiting the Number of Hops in LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Configuring the Bandwidth Value for LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Configuring Hot Standby of Secondary Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Damping Advertisement of LSP State Changes . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Chapter 6 DiffServ-Aware Traffic Engineering Configuration Guidelines . . . . . . . . . . 187
DiffServ-Aware Traffic Engineering Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 188
DiffServ-Aware Traffic Engineering Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
DiffServ-Aware Traffic Engineering Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 188
DiffServ-Aware Traffic Engineering Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
DiffServ-Aware Traffic Engineered LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
DiffServ-Aware Traffic Engineered LSPs Overview . . . . . . . . . . . . . . . . . . . . . . . . 190
DiffServ-Aware Traffic Engineered LSPs Operation . . . . . . . . . . . . . . . . . . . . . . . . 191
Multiclass LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Multiclass LSP Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

viii Copyright © 2012, Juniper Networks, Inc.

 Table of Contents

Establishing a Multiclass LSP on the Differentiated Services Domain . . . . . . . . . 192

Configuring Routers for DiffServ-Aware Traffic Engineering . . . . . . . . . . . . . . . . . 193
Configuring the Bandwidth Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Configuring Traffic Engineering Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Requirements and Limitations for the Traffic Engineering Class
Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Configuring Class of Service for DiffServ-Aware Traffic Engineering . . . . . . 196
Bandwidth Oversubscription Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
LSP Size Oversubscription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Link Size Oversubscription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Class Type Oversubscription and Local Oversubscription Multipliers . . . . . . . . . 198
Class Type Bandwidth and the LOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
LOM Calculation for the MAM and Extended MAM Bandwidth Models . . . . . . . . 199
LOM Calculation for the Russian Dolls Bandwidth Model . . . . . . . . . . . . . . . . . . 200
Example: LOM Calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Configuring the Bandwidth Subscription Percentage for LSPs . . . . . . . . . . . . . . 201
Constraints on Configuring Bandwidth Subscription . . . . . . . . . . . . . . . . . . 202
Configuring LSPs for DiffServ-Aware Traffic Engineering . . . . . . . . . . . . . . . . . . 203
Configuring Class of Service for the Interfaces . . . . . . . . . . . . . . . . . . . . . . . 204
Configuring IGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Configuring Traffic-Engineered LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Configuring Policing for LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Configuring Fast Reroute for Traffic-Engineered LSPs . . . . . . . . . . . . . . . . . 205
Configuring Multiclass LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Configuring Class of Service for the Interfaces . . . . . . . . . . . . . . . . . . . . . . . 206
Configuring the IGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Configuring Class-Type Bandwidth Constraints for Multiclass LSPs . . . . . . 207
Configuring Policing for Multiclass LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Configuring Fast Reroute for Multiclass LSPs . . . . . . . . . . . . . . . . . . . . . . . . 208
Chapter 7 Static and Explicit-Path LSP Configuration Guidelines . . . . . . . . . . . . . . . . . 211
Configuring Static LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Configuring the Ingress Router for Static LSPs . . . . . . . . . . . . . . . . . . . . . . . . 211
Example: Configuring the Ingress Router . . . . . . . . . . . . . . . . . . . . . . . . . 213
Configuring the Intermediate (Transit) and Egress Routers for Static
LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Example: Configuring an Intermediate Router . . . . . . . . . . . . . . . . . . . . 215
Example: Configuring an Egress Router . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Configuring a Bypass LSP for the Static LSP . . . . . . . . . . . . . . . . . . . . . . . . . 217
Configuring the Protection Revert Timer for Static LSPs . . . . . . . . . . . . . . . . 217
Configuring Static Unicast Routes for Point-to-Multipoint LSPs . . . . . . . . . . 217
Configuring Explicit-Path LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Chapter 8 Point-to-Multipoint LSP Configuration Guidelines . . . . . . . . . . . . . . . . . . . . 221
Configuring Primary and Branch LSPs for Point-to-Multipoint LSPs . . . . . . . . . . 221
Configuring the Primary Point-to-Multipoint LSP . . . . . . . . . . . . . . . . . . . . . 222
Configuring a Branch LSP for Point-to-Multipoint LSPs . . . . . . . . . . . . . . . . 222
Configuring the Branch LSP as a Dynamic Path . . . . . . . . . . . . . . . . . . . 223
Configuring the Branch LSP as a Static Path . . . . . . . . . . . . . . . . . . . . . 223
Configuring Link Protection for Point-to-Multipoint LSPs . . . . . . . . . . . . . . . . . . 223

Copyright © 2012, Juniper Networks, Inc. ix

Junos OS 12.1 MPLS Applications Configuration Guide

Configuring Graceful Restart for Point-to-Multipoint LSPs . . . . . . . . . . . . . . . . . 224

Configuring a Multicast RPF Check Policy for Point-to-Multipoint LSPs . . . . . . . 224
Example: Configuring Multicast RPF Check Policy for a Point-to-Multipoint
LSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Configuring Ingress PE Router Redundancy for Point-to-Multipoint LSPs . . . . . 225
Enabling Point-to-Point LSPs to Monitor Egress PE Routers . . . . . . . . . . . . . . . . 226
Preserving Point-to-Multipoint LSP Functioning with Different Junos OS
Releases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Example: Configuring an RSVP-Signaled Point-to-Multipoint LSP . . . . . . . . . . . 227
Configuring Inter-domain P2MP LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Chapter 9 Miscellaneous MPLS Properties Configuration Guidelines . . . . . . . . . . . . . 247
Configuring the Maximum Number of MPLS Labels . . . . . . . . . . . . . . . . . . . . . . . 247
Configuring MPLS to Pop the Label on the Ultimate-Hop Router . . . . . . . . . . . . 249
Advertising Explicit Null Labels to BGP Peers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Configuring Traffic Engineering for LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Using LSPs for Both BGP and IGP Traffic Forwarding . . . . . . . . . . . . . . . . . . 251
Using LSPs for Forwarding in Virtual Private Networks . . . . . . . . . . . . . . . . . 251
Using RSVP and LDP Routes for Forwarding but Not Route Selection . . . . . 252
Advertising the LSP Metric in Summary LSAs . . . . . . . . . . . . . . . . . . . . . . . . 252
Enabling Interarea Traffic Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
Enabling Inter-AS Traffic Engineering for LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Inter-AS Traffic Engineering Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Inter-AS Traffic Engineering Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Configuring OSPF Passive TE Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Configuring MPLS to Gather Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
Configuring System Log Messages and SNMP Traps for LSPs . . . . . . . . . . . . . . . 257
Configuring MPLS Firewall Filters and Policers . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
Configuring MPLS Firewall Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Examples: Configuring MPLS Firewall Filters . . . . . . . . . . . . . . . . . . . . . . . . 260
Configuring Policers for LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
LSP Policer Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
Example: Configuring an LSP Policer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
Configuring Automatic Policers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
Configuring Automatic Policers for LSPs . . . . . . . . . . . . . . . . . . . . . . . . 263
Configuring Automatic Policers for DiffServ-Aware Traffic Engineering
LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
Configuring Automatic Policers for Point-to-Multipoint LSPs . . . . . . . . 264
Disabling Automatic Policing on an LSP . . . . . . . . . . . . . . . . . . . . . . . . 265
Example: Configuring Automatic Policing for an LSP . . . . . . . . . . . . . . 265
Writing Different DSCP and EXP Values in MPLS-Tagged IP Packets . . . . . 266
Configuring MPLS Rewrite Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
Rewriting the EXP Bits of All Three Labels of an Outgoing Packet . . . . . . . . 266
Rewriting MPLS and IPv4 Packet Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
Configuring BFD for MPLS IPv4 LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
Configuring BFD for RSVP-Signaled LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
Configuring a Failure Action for the BFD Session on an RSVP LSP . . . . . . . 269

x Copyright © 2012, Juniper Networks, Inc.

 Table of Contents

Pinging LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270

Pinging MPLS LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
Pinging Point-to-Multipoint LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
Pinging the Endpoint Address of MPLS LSPs . . . . . . . . . . . . . . . . . . . . . . . . . 271
Pinging CCC LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Pinging Layer 3 VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Support for LSP Ping and Traceroute Commands Based on RFC 4379 . . . . 271
Tracing MPLS and LSP Packets and Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Chapter 10 Summary of MPLS Configuration Statements . . . . . . . . . . . . . . . . . . . . . . . 273
adaptive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
adjust-interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
adjust-threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
adjust-threshold-overflow-limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
adjust-threshold-underflow-limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
admin-down . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
admin-group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
admin-group (for Interfaces) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
admin-group (for LSPs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
admin-groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
admin-group-extended . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
admin-groups-extended . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
admin-groups-extended-range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
advertisement-hold-time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
allow-fragmentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
always-mark-connection-protection-tlv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
associate-backup-pe-groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
associate-lsp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
auto-bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
auto-policing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
backup-pe-group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
bandwidth (Fast Reroute, Signaled, and Multiclass LSPs) . . . . . . . . . . . . . . . . . 288
bandwidth (Static LSP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
bandwidth-model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
bandwidth-percent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
bfd-liveness-detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
bypass (Static LSP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
class-of-service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
diffserv-te . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
disable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
encoding-type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
exclude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
exclude (for Administrative Groups) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
exclude (for Fast Reroute) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
exclude-srlg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
expand-loose-hop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
explicit-null . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
failure-action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302

Copyright © 2012, Juniper Networks, Inc. xi

Junos OS 12.1 MPLS Applications Configuration Guide

family mpls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303

fast-reroute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
fate-sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
from . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
gpid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
hop-limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
icmp-tunneling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
include-all . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
include-all (for Administrative Groups) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
include-all (for Fast Reroute) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
include-any . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
include-any (for Administrative Groups) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
include-any (for Fast Reroute) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
ingress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
install . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
ipv6-tunneling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
label-switched-path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
ldp-tunneling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
least-fill . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
link-protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
link-protection (Dynamic LSPs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
link-protection (Static LSPs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
log-updown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
lsp-attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
maximum-bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
maximum-labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
metric . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
minimum-bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
monitor-bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
most-fill . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
mpls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
mpls-tp-mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
mtu-signaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
next-hop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
no-cspf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
no-decrement-ttl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
no-exclude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
no-include-all . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
no-include-any . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
no-mcast-replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
no-install-to-address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
node-protection (Static LSP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
no-propagate-ttl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
no-record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
no-trap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
node-protection (Static LSP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
oam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
optimize-aggressive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337

xii Copyright © 2012, Juniper Networks, Inc.

 Table of Contents

optimize-timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
p2mp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
p2mp-lsp-next-hop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
path-mtu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
policing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
pop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
preference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
primary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
protection-revert-time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
push . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
random . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
retry-limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
retry-timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
revert-timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
rpf-check-policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
rsvp-error-hold-time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
secondary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
select . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
signal-bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
smart-optimize-timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
soft-preemption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
srlg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
srlg-cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
srlg-value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
standby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
static-label-switched-path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
swap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
switch-away-lsps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
switching-type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
te-class-matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
to . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
traceoptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368
traffic-engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
transit-lsp-association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371

Part 3 RSVP
Chapter 11 RSVP Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
RSVP Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
Supported RSVP Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
Junos OS RSVP Protocol Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
RSVP Operation Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
RSVP Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
RSVP and IGP Hello Packets and Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
RSVP Message Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379

Copyright © 2012, Juniper Networks, Inc. xiii

Junos OS 12.1 MPLS Applications Configuration Guide

Path Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380

Resv Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380
PathTear Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380
ResvTear Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380
PathErr Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
ResvErr Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
ResvConfirm Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
RSVP Reservation Styles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
RSVP Refresh Reduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
MTU Signaling in RSVP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
How the Correct MTU Is Signaled in RSVP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
Determining an Outgoing MTU Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
MTU Signaling in RSVP Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
Fast Reroute, Node Protection, and Link Protection . . . . . . . . . . . . . . . . . . . . . . . 385
Link Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
Multiple Bypass LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387
Node Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387
RSVP Graceful Restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388
RSVP Graceful Restart Standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
RSVP Graceful Restart Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
RSVP Graceful Restart Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
Processing the Restart Cap Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
Chapter 12 RSVP Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
Minimum RSVP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
Configuring RSVP and MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
Example: Configuring RSVP and MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
Configuring RSVP Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
Configuring RSVP Refresh Reduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
Determining the Refresh Reduction Capability of RSVP Neighbors . . . 397
Configuring the RSVP Hello Interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398
Configuring RSVP Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398
Configuring the Bandwidth Subscription for Class Types . . . . . . . . . . . . . . . 399
Configuring the RSVP Update Threshold on an Interface . . . . . . . . . . . . . . . 399
Configuring RSVP for Unnumbered Interfaces . . . . . . . . . . . . . . . . . . . . . . . 400
Configuring RSVP Node ID Hellos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401
Configuring Hello Acknowledgments for Nonsession RSVP Neighbors . . . . . . . . 401
Configuring Node Protection or Link Protection for LSPs . . . . . . . . . . . . . . . . . . 402
Switching LSPs Away from a Network Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403
Configuring Inter-AS Node and Link Protection . . . . . . . . . . . . . . . . . . . . . . . . . . 404
Configuring Link Protection on Interfaces Used by LSPs . . . . . . . . . . . . . . . . . . . 404
Configuring Bypass LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
Configuring the Next-Hop or Next-Next-Hop Node Address for Bypass
LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406
Configuring Administrative Groups for Bypass LSPs . . . . . . . . . . . . . . . . . . 406
Configuring the Bandwidth for Bypass LSPs . . . . . . . . . . . . . . . . . . . . . . . . . 407
Configuring Class of Service for Bypass LSPs . . . . . . . . . . . . . . . . . . . . . . . . 407
Configuring the Hop Limit for Bypass LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . 408
Configuring the Maximum Number of Bypass LSPs . . . . . . . . . . . . . . . . . . . 408

xiv Copyright © 2012, Juniper Networks, Inc.

 Table of Contents

Disabling CSPF for Bypass LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409

Disabling Node Protection for Bypass LSPs . . . . . . . . . . . . . . . . . . . . . . . . . 409
Configuring the Optimization Interval for Bypass LSPs . . . . . . . . . . . . . . . . 409
Configuring an Explicit Path for Bypass LSPs . . . . . . . . . . . . . . . . . . . . . . . . 410
Configuring the Amount of Bandwidth Subscribed for Bypass LSPs . . . . . . . 411
Configuring Priority and Preemption for Bypass LSPs . . . . . . . . . . . . . . . . . . 411
Configuring RSVP Setup Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412
Configuring RSVP Graceful Restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412
Enabling Graceful Restart for All Routing Protocols . . . . . . . . . . . . . . . . . . . 413
Disabling Graceful Restart for RSVP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
Disabling RSVP Helper Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
Configuring the Maximum Helper Recovery Time . . . . . . . . . . . . . . . . . . . . . 413
Configuring the Maximum Helper Restart Time . . . . . . . . . . . . . . . . . . . . . . . 414
Configuring Load Balancing Across RSVP LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . 414
Configuring RSVP Automatic Mesh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
Configuring Timers for RSVP Refresh Messages . . . . . . . . . . . . . . . . . . . . . . . . . . 416
Preempting RSVP Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
Configuring MTU Signaling in RSVP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
Enabling MTU Signaling in RSVP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
Enabling Packet Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
Configuring RSVP to Pop the Label on the Ultimate-Hop Router . . . . . . . . . . . . 419
Disabling Adjacency Down and Neighbor Down Notification in IS-IS and
OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420
Enabling Ultimate-Hop Popping on Point-to-Multipoint LSPs . . . . . . . . . . . . . . 420
Tracing RSVP Protocol Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
Examples: Tracing RSVP Protocol Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422
Chapter 13 Summary of RSVP Configuration Statements . . . . . . . . . . . . . . . . . . . . . . . 425
admin-group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425
aggregate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426
authentication-key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427
bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428
bypass (Signaled LSP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429
bypass (Static LSP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430
class-of-service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431
disable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432
fast-reroute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
graceful-deletion-timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
graceful-restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434
hello-acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435
hello-interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435
hop-limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436
interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437
keep-multiplier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438
link-protection (RSVP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439
load-balance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440
max-bypasses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441
no-local-reversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442
node-hello . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443

Copyright © 2012, Juniper Networks, Inc. xv

Junos OS 12.1 MPLS Applications Configuration Guide

no-adjacency-down-notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
no-aggregate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
no-cspf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444
no-interface-hello . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444
no-neighbor-down-notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445
no-node-id-subobject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445
no-p2mp-sublsp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446
no-reliable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446
node-link-protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446
optimize-timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448
peer-interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449
preemption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450
priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451
refresh-time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452
reliable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452
rsvp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453
rsvp-te . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454
setup-protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
soft-preemption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
subscription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456
traceoptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457
transit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459
tunnel-services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460
update-threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460

Part 4 LDP
Chapter 14 LDP Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463
LDP Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463
Supported LDP Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464
Junos OS LDP Protocol Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464
LDP Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465
Tunneling LDP LSPs in RSVP LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465
Tunneling LDP LSPs in RSVP LSPs Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465
Label Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466
LDP Message Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467
Discovery Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467
Session Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468
Advertisement Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468
Notification Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468
LDP Session Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468
LDP Graceful Restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469
Chapter 15 LDP Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
Minimum LDP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472
Enabling and Disabling LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472
Configuring the LDP Timer for Hello Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 472
Configuring the LDP Timer for Link Hello Messages . . . . . . . . . . . . . . . . . . . 473
Configuring the LDP Timer for Targeted Hello Messages . . . . . . . . . . . . . . . 473

xvi Copyright © 2012, Juniper Networks, Inc.

 Table of Contents

Configuring the Delay Before LDP Neighbors Are Considered Down . . . . . . . . . . 473
Configuring the LDP Hold Time for Link Hello Messages . . . . . . . . . . . . . . . 474
Configuring the LDP Hold Time for Targeted Hello Messages . . . . . . . . . . . 474
Enabling Strict Targeted Hello Messages for LDP . . . . . . . . . . . . . . . . . . . . . . . . . 475
Configuring the Interval for LDP Keepalive Messages . . . . . . . . . . . . . . . . . . . . . 475
Configuring the LDP Keepalive Timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475
Configuring LDP Route Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476
Configuring LDP Graceful Restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476
Enabling Graceful Restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476
Disabling LDP Graceful Restart or Helper Mode . . . . . . . . . . . . . . . . . . . . . . 477
Configuring Reconnect Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477
Configuring Recovery Time and Maximum Recovery Time . . . . . . . . . . . . . . 478
Filtering Inbound LDP Label Bindings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478
Examples: Filtering Inbound LDP Label Bindings . . . . . . . . . . . . . . . . . . . . . 480
Filtering Outbound LDP Label Bindings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480
Examples: Filtering Outbound LDP Label Bindings . . . . . . . . . . . . . . . . . . . . 481
Specifying the Transport Address Used by LDP . . . . . . . . . . . . . . . . . . . . . . . . . . 482
Configuring the Prefixes Advertised into LDP from the Routing Table . . . . . . . . 483
Example: Configuring the Prefixes Advertised into LDP . . . . . . . . . . . . . . . . 483
Configuring FEC Deaggregation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484
Configuring Policers for LDP FECs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484
Configuring LDP IPv4 FEC Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485
Configuring BFD for LDP LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486
Configuring ECMP-Aware BFD for LDP LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488
Configuring a Failure Action for the BFD Session on an LDP LSP . . . . . . . . . . . . 488
Configuring the Holddown Interval for the BFD Session . . . . . . . . . . . . . . . . . . . 489
Configuring OAM Ingress Policies for LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489
Configuring LDP LSP Traceroute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490
Collecting LDP Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491
LDP Statistics Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491
Disabling LDP Statistics on the Penultimate-Hop Router . . . . . . . . . . . . . . 492
LDP Statistics Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492
Tracing LDP Protocol Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493
Tracing LDP Protocol Traffic at the Protocol and Routing Instance
Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493
Tracing LDP Protocol Traffic Within FECs . . . . . . . . . . . . . . . . . . . . . . . . . . . 494
Examples: Tracing LDP Protocol Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494
Configuring Miscellaneous LDP Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495
Configuring LDP to Use the IGP Route Metric . . . . . . . . . . . . . . . . . . . . . . . . 496
Preventing Addition of Ingress Routes to the inet.0 Routing Table . . . . . . . 496
Multiple-Instance LDP and Carrier-of-Carriers VPNs . . . . . . . . . . . . . . . . . . 496
Configuring MPLS and LDP to Pop the Label on the Ultimate-Hop
Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496
Enabling LDP over RSVP-Established LSPs . . . . . . . . . . . . . . . . . . . . . . . . . 497
Enabling LDP over RSVP-Established LSPs in Heterogeneous Networks . . 497
Configuring the TCP MD5 Signature for LDP Sessions . . . . . . . . . . . . . . . . . 498
Configuring LDP Session Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499
Disabling SNMP Traps for LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499
Configuring LDP Synchronization with the IGP on LDP Links . . . . . . . . . . . . 499

Copyright © 2012, Juniper Networks, Inc. xvii

Junos OS 12.1 MPLS Applications Configuration Guide

Configuring LDP Synchronization with the IGP on the Router . . . . . . . . . . . 500

Configuring the Label Withdrawal Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . 500
Ignoring the LDP Subnet Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501
Chapter 16 Summary of LDP Configuration Statements . . . . . . . . . . . . . . . . . . . . . . . . 503
allow-subnet-mismatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503
authentication-key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504
bfd-liveness-detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505
deaggregate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506
disable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507
ecmp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508
egress-policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508
explicit-null . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509
export . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509
failure-action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 510
graceful-restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511
hello-interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512
helper-disable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513
holddown-interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513
hold-time (LDP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514
ignore-lsp-metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515
igp-synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515
import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516
ingress-policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516
interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517
keepalive-interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518
keepalive-timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518
l2-smart-policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519
label-withdrawal-delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519
ldp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520
ldp-synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521
log-updown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521
maximum-neighbor-recovery-time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522
no-deaggregate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522
no-forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523
oam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524
p2mp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525
periodic-traceroute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526
policing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527
preference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528
reconnect-time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528
recovery-time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529
session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529
session-protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 530
strict-targeted-hellos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 530
targeted-hello . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531
traceoptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532
track-igp-metric . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534
traffic-statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535

xviii Copyright © 2012, Juniper Networks, Inc.

 Table of Contents

transport-address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536

Part 5 CCC and TCC

Chapter 17 CCC and TCC Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 539
CCC Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 539
Transmitting Nonstandard BPDUs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540
TCC Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540
CCC and TCC Graceful Restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541
Chapter 18 CCC and TCC Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543
Configuring Layer 2 Switching Cross-Connects Using CCC . . . . . . . . . . . . . . . . . 543
Configuring the CCC Encapsulation for Layer 2 Switching
Cross-Connects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544
Configuring ATM Encapsulation for Layer 2 Switching
Cross-Connects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544
Configuring Ethernet Encapsulation for Layer 2 Switching
Cross-Connects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545
Configuring Ethernet VLAN Encapsulation for Layer 2 Switching
Cross-Connects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545
Configuring Aggregated Ethernet Encapsulation for Layer 2 Switching
Cross-Connects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546
Configuring Frame Relay Encapsulation for Layer 2 Switching
Cross-Connects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547
Configuring PPP and Cisco HDLC Encapsulation for Layer 2 Switching
Cross-Connects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548
Configuring the CCC Connection for Layer 2 Switching Cross-Connects . . . 548
Configuring MPLS for Layer 2 Switching Cross-Connects . . . . . . . . . . . . . . 549
Example: Configuring a Layer 2 Switching Cross-Connect . . . . . . . . . . . . . . 549
Configuring MPLS LSP Tunnel Cross-Connects Using CCC . . . . . . . . . . . . . . . . . 551
Configuring the CCC Encapsulation for LSP Tunnel Cross-Connects . . . . . . 552
Configuring the CCC Connection for LSP Tunnel Cross-Connects . . . . . . . . 553
Example: Configuring an LSP Tunnel Cross-Connect . . . . . . . . . . . . . . . . . . 554
Configuring LSP Stitching Cross-Connects Using CCC . . . . . . . . . . . . . . . . . . . . 555
Example: Configuring an LSP Stitching Cross-Connect . . . . . . . . . . . . . . . . 556
Configuring TCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556
Configuring the Encapsulation for Layer 2 Switching TCCs . . . . . . . . . . . . . . 557
Configuring PPP and Cisco HDLC Encapsulation for Layer 2 Switching
TCCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557
Configuring ATM Encapsulation for Layer 2 Switching TCCs . . . . . . . . . 558
Configuring Frame Relay Encapsulation for Layer 2 Switching TCCs . . 558
Configuring Ethernet Encapsulation for Layer 2 Switching TCCs . . . . . 558
Configuring Ethernet Extended VLAN Encapsulation for Layer 2
Switching TCCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 559
Configuring ARP for Ethernet and Ethernet Extended VLAN
Encapsulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 560
Configuring the Connection for Layer 2 Switching TCCs . . . . . . . . . . . . . . . . 560
Configuring MPLS for Layer 2 Switching TCCs . . . . . . . . . . . . . . . . . . . . . . . . 561
Configuring CCC and TCC Graceful Restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562

Copyright © 2012, Juniper Networks, Inc. xix

Junos OS 12.1 MPLS Applications Configuration Guide

Configuring CCC Switching for Point-to-Multipoint LSPs . . . . . . . . . . . . . . . . . . 562

Configuring the Point-to-Multipoint LSP Switch on Ingress PE Routers . . . 562
Configuring the Point-to-Multipoint LSP Switch on Egress PE Routers . . . . 563
Chapter 19 Summary of CCC and TCC Configuration Statements . . . . . . . . . . . . . . . . 565
connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566
encapsulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567
encapsulation (Logical Interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 568
encapsulation (Physical Interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 570
interface-switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 572
lsp-switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573
p2mp-receive-switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574
p2mp-transmit-switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575
remote-interface-switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576

Part 6 GMPLS
Chapter 20 GMPLS Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579
Supported GMPLS Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579
GMPLS Terms and Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 580
Introduction to GMPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 581
GMPLS Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 582
GMPLS and OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583
GMPLS and CSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583
GMPLS Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584
Chapter 21 GMPLS Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585
LMP Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585
Configuring LMP Traffic Engineering Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586
Configuring the Local IP Address for Traffic Engineering Links . . . . . . . . . . . 587
Configuring the Remote IP Address for Traffic Engineering Links . . . . . . . . . 587
Configuring the Remote ID for Traffic Engineering Links . . . . . . . . . . . . . . . . 588
Configuring LMP Peers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 588
Configuring the ID for LMP Peers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589
Configuring the Interface for Control Channels Between LMP Peers . . . . . . 589
Configuring the LMP Control Channel Interface for the Peer . . . . . . . . . . . . 589
Configuring the Remote IP Address for LMP Control Channels . . . . . . . . . . 590
Configuring Hello Message Intervals for LMP Control Channels . . . . . . . . . 590
Controlling Message Exchange for LMP Control Channels . . . . . . . . . . . . . . 591
Preventing the Local Peer from Initiating LMP Negotiation . . . . . . . . . . . . . 592
Associating Traffic Engineering Links with LMP Peers . . . . . . . . . . . . . . . . . 592
Disabling the Traffic Engineering Link for LMP Peers . . . . . . . . . . . . . . . . . . 592
Configuring RSVP and OSPF for LMP Peer Interfaces . . . . . . . . . . . . . . . . . . . . . 593
Configuring RSVP Signaling for LMP Peer Interfaces . . . . . . . . . . . . . . . . . . 593
Configuring OSPF Routing for LMP Peer Interfaces . . . . . . . . . . . . . . . . . . . 593
Configuring the Hello Interval for LMP Peer Interfaces . . . . . . . . . . . . . . . . . 594
Configuring MPLS Paths for GMPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594
Tracing LMP Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595

xx Copyright © 2012, Juniper Networks, Inc.

 Table of Contents

Configuring MPLS LSPs for GMPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595

Configuring the Encoding Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596
Configuring the GPID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596
Configuring the Signal Bandwidth Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597
Configuring GMPLS Bidirectional LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597
Allowing Nonpacket GMPLS LSPs to Establish Paths Through Routers
Running the Junos OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597
Gracefully Tearing Down GMPLS LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 598
Temporarily Deleting GMPLS LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 598
Permanently Deleting GMPLS LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 598
Configuring the Graceful Deletion Timeout Interval . . . . . . . . . . . . . . . . . . . 599
Chapter 22 Hierarchy of RSVP LSPs Configuration Guidelines . . . . . . . . . . . . . . . . . . . . 601
Hierarchy of RSVP LSPs Standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 601
Hierarchy of RSVP LSPs Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 601
Hierarchy of RSVP LSPs Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 601
Hierarchy of RSVP LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 602
Advertising the Forwarding Adjacency with OSPF . . . . . . . . . . . . . . . . . . . . . . . . 602
Configuring a Hierarchy of RSVP LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 602
Configuring an RSVP LSP on Ingress Routers . . . . . . . . . . . . . . . . . . . . . . . . 603
Configuring Forwarding Adjacencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603
Configuring the Local IP Address for Forwarding Adjacencies . . . . . . . 603
Configuring the Remote IP Address for Forwarding Adjacencies . . . . . 603
Configuring the LSP for Forwarding Adjacencies . . . . . . . . . . . . . . . . . . 604
Configuring RSVP for Forwarding Adjacencies . . . . . . . . . . . . . . . . . . . . . . . 604
Advertising Forwarding Adjacencies Using OSPF . . . . . . . . . . . . . . . . . . . . . 605
Chapter 23 Summary of GMPLS Configuration Statements . . . . . . . . . . . . . . . . . . . . . 607
address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 607
control-channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 608
dead-interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 608
disable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 609
disable (GMPLS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 609
disable (OSPF Peer Interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 609
hello-dead-interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 610
hello-interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 611
hello-interval (LMP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 611
hello-interval (OSPF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 612
interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 612
label-switched-path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613
link-management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613
lmp-control-channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614
lmp-protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614
local-address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615
passive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615
peer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616
peer-interface (OSPF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617
remote-address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 618
remote-address (for LMP Control Channel) . . . . . . . . . . . . . . . . . . . . . . . . . 618
remote-address (for LMP Traffic Engineering) . . . . . . . . . . . . . . . . . . . . . . . 618

Copyright © 2012, Juniper Networks, Inc. xxi

Junos OS 12.1 MPLS Applications Configuration Guide

remote-id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 619
retransmission-interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 619
retransmit-interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 620
retry-limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 620
te-link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 621
traceoptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 622
transit-delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624

Part 7 Indexes
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 627
Index of Statements and Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 647

xxii Copyright © 2012, Juniper Networks, Inc.

List of Figures
Part 2 MPLS
Chapter 3 MPLS Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Figure 1: Label Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Figure 2: Class-of-Service Bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Figure 3: CSPF Computation Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Figure 4: Aggregation Router A Dual-Homed on Core Routers B and C . . . . . . . . . 35
Figure 5: Typical SPF Tree, Sourced from Router A . . . . . . . . . . . . . . . . . . . . . . . . . 37
Figure 6: Modified SPF Tree, Using LSP A–D as a Shortcut . . . . . . . . . . . . . . . . . . 37
Figure 7: Modified SPF Tree, Using LSP A–D and LSP A–E as Shortcuts . . . . . . . . 38
Figure 8: IGP Shortcuts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Figure 9: IGP Shortcuts in a Bigger Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Figure 10: SPF Computations with Advertised LSPs . . . . . . . . . . . . . . . . . . . . . . . . 41
Figure 11: MPLS Application Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Figure 12: How BGP Determines How to Reach Next-Hop Addresses . . . . . . . . . . 44
Figure 13: Routing and Forwarding Tables, traffic-engineering bgp . . . . . . . . . . . . 45
Figure 14: Routing and Forwarding Tables, traffic-engineering bgp-igp . . . . . . . . 46
Figure 15: Detours Established for an LSP Using Fast Reroute . . . . . . . . . . . . . . . . 48
Figure 16: Detour After the Link from Router B to Router C Fails . . . . . . . . . . . . . . 48
Figure 17: Detours Merging into Other Detours . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Figure 18: Point-to-Multipoint LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Chapter 4 MPLS Router Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Figure 19: IPv6 Networks Linked by MPLS IPv4 Tunnels . . . . . . . . . . . . . . . . . . . . 68
Figure 20: MPLS-TP OAM Associated Bidirectional LSPs . . . . . . . . . . . . . . . . . . . 132
Chapter 5 MPLS-Signaled LSP Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . . 143
Figure 21: least-fill Load Balancing Algorithm Example . . . . . . . . . . . . . . . . . . . . . 181
Chapter 7 Static and Explicit-Path LSP Configuration Guidelines . . . . . . . . . . . . . . . . . 211
Figure 22: Static MPLS Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Chapter 8 Point-to-Multipoint LSP Configuration Guidelines . . . . . . . . . . . . . . . . . . . . 221
Figure 23: RSVP-Signaled Point-to-Multipoint LSP . . . . . . . . . . . . . . . . . . . . . . . 228

Part 3 RSVP
Chapter 11 RSVP Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
Figure 24: Link Protection Creating a Bypass LSP for the Protected Interface . . 386
Figure 25: Node Protection Creating a Next-Next-Hop Bypass LSP . . . . . . . . . . 388

Copyright © 2012, Juniper Networks, Inc. xxiii

Junos OS 12.1 MPLS Applications Configuration Guide

Part 4 LDP
Chapter 14 LDP Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463
Figure 26: Swap and Push When LDP LSPs Are Tunneled Through RSVP
LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466
Figure 27: Double Push When LDP LSPs Are Tunneled Through RSVP LSPs . . . 467

Part 5 CCC and TCC

Chapter 17 CCC and TCC Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 539
Figure 28: TCC Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540
Figure 29: Remote Interface Switch Connecting Two CE Routers Using CCC . . . 541
Chapter 18 CCC and TCC Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543
Figure 30: Layer 2 Switching Cross-Connect . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543
Figure 31: Topology of a Frame Relay Layer 2 Switching Cross-Connect . . . . . . . 549
Figure 32: Sample Topology of a VLAN Layer 2 Switching Cross-Connect . . . . . 550
Figure 33: MPLS Tunnel Cross-Connect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 551
Figure 34: Example Topology of MPLS LSP Tunnel Cross-Connect . . . . . . . . . . 554
Figure 35: LSP Stitching Cross-Connect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555
Figure 36: Example Topology of LSP Stitching Cross-Connect . . . . . . . . . . . . . . 556

xxiv Copyright © 2012, Juniper Networks, Inc.

List of Tables
About This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxvii
Table 1: Notice Icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxi
Table 2: Text and Syntax Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxi

Part 2 MPLS
Chapter 5 MPLS-Signaled LSP Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . . 143
Table 3: MPLS LSP Load Balancing Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Table 4: MPLS CoS Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Chapter 6 DiffServ-Aware Traffic Engineering Configuration Guidelines . . . . . . . . . . 187
Table 5: Default Values for the Traffic Engineering Class Matrix . . . . . . . . . . . . . . 195
Chapter 9 Miscellaneous MPLS Properties Configuration Guidelines . . . . . . . . . . . . . 247
Table 6: Sample Scenarios for Using 3, 4, or 5 MPLS Labels . . . . . . . . . . . . . . . . 248

Part 3 RSVP
Chapter 11 RSVP Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
Table 7: One-to-One Backup Compared with Facility Backup . . . . . . . . . . . . . . . 385
Chapter 12 RSVP Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
Table 8: RSVP Refresh Reduction Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396

Part 4 LDP
Chapter 15 LDP Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
Table 9: from Operators That Apply to LDP Received-Label Filtering . . . . . . . . . 479
Table 10: to Operators for LDP Outbound-Label Filtering . . . . . . . . . . . . . . . . . . . 481

Copyright © 2012, Juniper Networks, Inc. xxv

Junos OS 12.1 MPLS Applications Configuration Guide

xxvi Copyright © 2012, Juniper Networks, Inc.

About This Guide
®
This preface provides the following guidelines for using the Junos OS MPLS Applications
Configuration Guide:

• Junos OS Documentation and Release Notes on page xxvii

• Objectives on page xxviii
• Audience on page xxviii
• Supported Platforms on page xxviii
• Using the Indexes on page xxix
• Using the Examples in This Manual on page xxix
• Documentation Conventions on page xxx
• Documentation Feedback on page xxxii
• Requesting Technical Support on page xxxii

Junos OS Documentation and Release Notes

For a list of related Junos OS documentation, see

http://www.juniper.net/techpubs/software/junos/ .

If the information in the latest release notes differs from the information in the
documentation, follow the Junos OS Release Notes.
®
To obtain the most current version of all Juniper Networks technical documentation,
see the product documentation page on the Juniper Networks website at
http://www.juniper.net/techpubs/ .

Juniper Networks supports a technical book program to publish books by Juniper Networks
engineers and subject matter experts with book publishers around the world. These
books go beyond the technical documentation to explore the nuances of network
architecture, deployment, and administration using the Junos operating system (Junos
OS) and Juniper Networks devices. In addition, the Juniper Networks Technical Library,
published in conjunction with O'Reilly Media, explores improving network security,
reliability, and availability using Junos OS configuration techniques. All the books are for
sale at technical bookstores and book outlets around the world. The current list can be
viewed at http://www.juniper.net/books .

Copyright © 2012, Juniper Networks, Inc. xxvii

Junos OS 12.1 MPLS Applications Configuration Guide

Objectives

This guide provides an overview of the MPLS applications functions of the Junos OS and
describes how to configure MPLS applications on the router.

NOTE: For additional information about the Junos OS—either corrections to

or information that might have been omitted from this guide—see the software
release notes at http://www.juniper.net/ .

Audience

This guide is designed for network administrators who are configuring and monitoring a
Juniper Networks M Series, MX Series, T Series, EX Series, or J Series router or switch.

To use this guide, you need a broad understanding of networks in general, the Internet
in particular, networking principles, and network configuration. You must also be familiar
with one or more of the following Internet routing protocols:

• Border Gateway Protocol (BGP)

• Distance Vector Multicast Routing Protocol (DVMRP)

• Intermediate System-to-Intermediate System (IS-IS)

• Internet Control Message Protocol (ICMP) router discovery

• Internet Group Management Protocol (IGMP)

• Multiprotocol Label Switching (MPLS)

• Open Shortest Path First (OSPF)

• Protocol-Independent Multicast (PIM)

• Resource Reservation Protocol (RSVP)

• Routing Information Protocol (RIP)

• Simple Network Management Protocol (SNMP)

Personnel operating the equipment must be trained and competent; must not conduct
themselves in a careless, willfully negligent, or hostile manner; and must abide by the
instructions provided by the documentation.

Supported Platforms

For the features described in this manual, the Junos OS currently supports the following
platforms:

• J Series

• M Series

xxviii Copyright © 2012, Juniper Networks, Inc.

 About This Guide

• MX Series

• T Series

• EX Series

• PTX Series

Using the Indexes

This reference contains two indexes: a complete index that includes topic entries, and
an index of statements and commands only.

In the index of statements and commands, an entry refers to a statement summary

section only. In the complete index, the entry for a configuration statement or command
contains at least two parts:

• The primary entry refers to the statement summary section.

• The secondary entry, usage guidelines, refers to the section in a configuration guidelines
chapter that describes how to use the statement or command.

Using the Examples in This Manual

If you want to use the examples in this manual, you can use the load merge or the load
merge relative command. These commands cause the software to merge the incoming
configuration into the current candidate configuration. The example does not become
active until you commit the candidate configuration.

If the example configuration contains the top level of the hierarchy (or multiple
hierarchies), the example is a full example. In this case, use the load merge command.

If the example configuration does not start at the top level of the hierarchy, the example
is a snippet. In this case, use the load merge relative command. These procedures are
described in the following sections.

Merging a Full Example

To merge a full example, follow these steps:

1. From the HTML or PDF version of the manual, copy a configuration example into a
text file, save the file with a name, and copy the file to a directory on your routing
platform.

For example, copy the following configuration to a file and name the file ex-script.conf.
Copy the ex-script.conf file to the /var/tmp directory on your routing platform.

system {
scripts {
commit {
file ex-script.xsl;
}
}
}

Copyright © 2012, Juniper Networks, Inc. xxix

Junos OS 12.1 MPLS Applications Configuration Guide

interfaces {
fxp0 {
disable;
unit 0 {
family inet {
address 10.0.0.1/24;
}
}
}
}

2. Merge the contents of the file into your routing platform configuration by issuing the
load merge configuration mode command:

[edit]
user@host# load merge /var/tmp/ex-script.conf
load complete

Merging a Snippet
To merge a snippet, follow these steps:

1. From the HTML or PDF version of the manual, copy a configuration snippet into a text
file, save the file with a name, and copy the file to a directory on your routing platform.

For example, copy the following snippet to a file and name the file
ex-script-snippet.conf. Copy the ex-script-snippet.conf file to the /var/tmp directory
on your routing platform.

commit {
file ex-script-snippet.xsl; }

2. Move to the hierarchy level that is relevant for this snippet by issuing the following
configuration mode command:

[edit]
user@host# edit system scripts
[edit system scripts]

3. Merge the contents of the file into your routing platform configuration by issuing the
load merge relative configuration mode command:

[edit system scripts]

user@host# load merge relative /var/tmp/ex-script-snippet.conf
load complete

For more information about the load command, see the Junos OS CLI User Guide.

Documentation Conventions

Table 1 on page xxxi defines notice icons used in this guide.

xxx Copyright © 2012, Juniper Networks, Inc.

 About This Guide

Table 1: Notice Icons

Icon Meaning Description

Informational note Indicates important features or instructions.

Caution Indicates a situation that might result in loss of data or hardware damage.

Warning Alerts you to the risk of personal injury or death.

Laser warning Alerts you to the risk of personal injury from a laser.

Table 2 on page xxxi defines the text and syntax conventions used in this guide.

Table 2: Text and Syntax Conventions

Convention Description Examples

Bold text like this Represents text that you type. To enter configuration mode, type the
configure command:

user@host> configure

Fixed-width text like this Represents output that appears on the user@host> show chassis alarms
terminal screen.
No alarms currently active

Italic text like this • Introduces important new terms. • A policy term is a named structure
• Identifies book names. that defines match conditions and
actions.
• Identifies RFC and Internet draft titles.
• Junos OS System Basics Configuration
Guide
• RFC 1997, BGP Communities Attribute

Italic text like this Represents variables (options for which Configure the machine’s domain name:
you substitute a value) in commands or
configuration statements. [edit]
root@# set system domain-name
domain-name

Text like this Represents names of configuration • To configure a stub area, include the
statements, commands, files, and stub statement at the [edit protocols
directories; interface names; ospf area area-id] hierarchy level.
configuration hierarchy levels; or labels • The console port is labeled CONSOLE.
on routing platform components.

< > (angle brackets) Enclose optional keywords or variables. stub <default-metric metric>;

Copyright © 2012, Juniper Networks, Inc. xxxi

Junos OS 12.1 MPLS Applications Configuration Guide

Table 2: Text and Syntax Conventions (continued)

Convention Description Examples

| (pipe symbol) Indicates a choice between the mutually broadcast | multicast

exclusive keywords or variables on either
side of the symbol. The set of choices is (string1 | string2 | string3)
often enclosed in parentheses for clarity.

# (pound sign) Indicates a comment specified on the rsvp { # Required for dynamic MPLS only
same line as the configuration statement
to which it applies.

[ ] (square brackets) Enclose a variable for which you can community name members [
substitute one or more values. community-ids ]

Indention and braces ( { } ) Identify a level in the configuration [edit]

hierarchy. routing-options {
static {
route default {
; (semicolon) Identifies a leaf statement at a
nexthop address;
configuration hierarchy level.
retain;
}
}
}

J-Web GUI Conventions

Bold text like this Represents J-Web graphical user • In the Logical Interfaces box, select
interface (GUI) items you click or select. All Interfaces.
• To cancel the configuration, click
Cancel.

> (bold right angle bracket) Separates levels in a hierarchy of J-Web In the configuration editor hierarchy,
selections. select Protocols>Ospf.

Documentation Feedback

We encourage you to provide feedback, comments, and suggestions so that we can

improve the documentation. You can send your comments to
[email protected], or fill out the documentation feedback form at
https://www.juniper.net/cgi-bin/docbugreport/ . If you are using e-mail, be sure to include
the following information with your comments:

• Document or topic name

• URL or page number

• Software release version (if applicable)

Requesting Technical Support

Technical product support is available through the Juniper Networks Technical Assistance
Center (JTAC). If you are a customer with an active J-Care or JNASC support contract,

xxxii Copyright © 2012, Juniper Networks, Inc.

 About This Guide

or are covered under warranty, and need postsales technical support, you can access
our tools and resources online or open a case with JTAC.

• JTAC policies—For a complete understanding of our JTAC procedures and policies,

review the JTAC User Guide located at
http://www.juniper.net/us/en/local/pdf/resource-guides/7100059-en.pdf .

• Product warranties—For product warranty information, visit

http://www.juniper.net/support/warranty/ .

• JTAC Hours of Operation —The JTAC centers have resources available 24 hours a day,
7 days a week, 365 days a year.

Self-Help Online Tools and Resources

For quick and easy problem resolution, Juniper Networks has designed an online
self-service portal called the Customer Support Center (CSC) that provides you with the
following features:

• Find CSC offerings: http://www.juniper.net/customers/support/

• Find product documentation: http://www.juniper.net/techpubs/

• Find solutions and answer questions using our Knowledge Base: http://kb.juniper.net/

• Download the latest versions of software and review release notes:

http://www.juniper.net/customers/csc/software/

• Search technical bulletins for relevant hardware and software notifications:

https://www.juniper.net/alerts/

• Join and participate in the Juniper Networks Community Forum:

http://www.juniper.net/company/communities/

• Open a case online in the CSC Case Management tool: http://www.juniper.net/cm/

To verify service entitlement by product serial number, use our Serial Number Entitlement
(SNE) Tool: https://tools.juniper.net/SerialNumberEntitlementSearch/

Opening a Case with JTAC

You can open a case with JTAC on the Web or by telephone.

• Use the Case Management tool in the CSC at http://www.juniper.net/cm/ .

• Call 1-888-314-JTAC (1-888-314-5822 toll-free in the USA, Canada, and Mexico).

For international or direct-dial options in countries without toll-free numbers, visit us at

http://www.juniper.net/support/requesting-support.html

Copyright © 2012, Juniper Networks, Inc. xxxiii

Junos OS 12.1 MPLS Applications Configuration Guide

xxxiv Copyright © 2012, Juniper Networks, Inc.

PART 1

Overview
• Traffic Engineering Overview on page 3
• Complete MPLS Applications Configuration Statements on page 9

Copyright © 2012, Juniper Networks, Inc. 1

Junos OS 12.1 MPLS Applications Configuration Guide

2 Copyright © 2012, Juniper Networks, Inc.

CHAPTER 1

Traffic Engineering Overview

This chapter discusses the following topics:

• Traffic Engineering Capabilities on page 3

• Components of Traffic Engineering on page 4
• Packet Forwarding Component on page 4
• Packet Forwarding Based on Label Swapping on page 4
• How a Packet Traverses an MPLS Backbone on page 5
• Information Distribution Component on page 5
• Path Selection Component on page 6
• Offline Planning and Analysis on page 6
• Signaling Component on page 7
• Flexible LSP Calculation and Configuration on page 7

Traffic Engineering Capabilities

The task of mapping traffic flows onto an existing physical topology is called traffic
engineering. Traffic engineering provides the ability to move traffic flow away from the
shortest path selected by the interior gateway protocol (IGP) and onto a potentially less
congested physical path across a network.

Traffic engineering provides the capabilities to do the following:

• Route primary paths around known bottlenecks or points of congestion in the network.

• Provide precise control over how traffic is rerouted when the primary path is faced with
single or multiple failures.

• Provide more efficient use of available aggregate bandwidth and long-haul fiber by
ensuring that subsets of the network do not become overutilized while other subsets
of the network along potential alternate paths are underutilized.

• Maximize operational efficiency.

Copyright © 2012, Juniper Networks, Inc. 3

Junos OS 12.1 MPLS Applications Configuration Guide

• Enhance the traffic-oriented performance characteristics of the network by minimizing

packet loss, minimizing prolonged periods of congestion, and maximizing throughput.

• Enhance statistically bound performance characteristics of the network (such as loss

ratio, delay variation, and transfer delay) required to support a multiservices Internet.

Components of Traffic Engineering

In the Junos OS, traffic engineering is implemented with MPLS and RSVP. Traffic
engineering is composed of four functional components:

• Packet Forwarding Component on page 4

• Information Distribution Component on page 5

• Path Selection Component on page 6

• Signaling Component on page 7

Packet Forwarding Component

The packet forwarding component of the Junos traffic engineering architecture is MPLS,
which is responsible for directing a flow of IP packets along a predetermined path across
a network. This path is called a label-switched path (LSP). LSPs are simplex; that is, the
traffic flows in one direction from the head-end (ingress) router to a tail-end (egress)
router. Duplex traffic requires two LSPs: one LSP to carry traffic in each direction. An LSP
is created by the concatenation of one or more label-switched hops, allowing a packet
to be forwarded from one router to another across the MPLS domain.

When an ingress router receives an IP packet, it adds an MPLS header to the packet and
forwards it to the next router in the LSP. The labeled packet is forwarded along the LSP
by each router until it reaches the tail end of the LSP, the egress router. At this point the
MPLS header is removed, and the packet is forwarded based on Layer 3 information such
as the IP destination address. The value of this scheme is that the physical path of the
LSP is not limited to what the IGP would choose as the shortest path to reach the
destination IP address.

This section discusses the following topics:

• Packet Forwarding Based on Label Swapping on page 4

• How a Packet Traverses an MPLS Backbone on page 5

Packet Forwarding Based on Label Swapping

The packet forwarding process at each router is based on the concept of label swapping.
This concept is similar to what occurs at each Asynchronous Transfer Mode (ATM) switch
in a permanent virtual circuit (PVC). Each MPLS packet carries a 4-byte encapsulation
header that contains a 20-bit, fixed-length label field. When a packet containing a label
arrives at a router, the router examines the label and copies it as an index to its MPLS
forwarding table. Each entry in the forwarding table contains an interface-inbound label

4 Copyright © 2012, Juniper Networks, Inc.

 Chapter 1: Traffic Engineering Overview

pair mapped to a set of forwarding information that is applied to all packets arriving on
the specific interface with the same inbound label.

How a Packet Traverses an MPLS Backbone

This section describes how an IP packet is processed as it traverses an MPLS backbone

network.

At the entry edge of the MPLS backbone, the IP header is examined by the ingress router.
Based on this analysis, the packet is classified, assigned a label, encapsulated in an MPLS
header, and forwarded toward the next hop in the LSP. MPLS provides a high degree of
flexibility in the way that an IP packet can be assigned to an LSP. For example, in the
Junos traffic engineering implementation, all packets arriving at the ingress router that
are destined to exit the MPLS domain at the same egress router are forwarded along the
same LSP.

Once the packet begins to traverse the LSP, each router uses the label to make the
forwarding decision. The MPLS forwarding decision is made independently of the original
IP header: the incoming interface and label are used as lookup keys into the MPLS
forwarding table. The old label is replaced with a new label, and the packet is forwarded
to the next hop along the LSP. This process is repeated at each router in the LSP until
the packet reaches the egress router.

When the packet arrives at the egress router, the label is removed and the packet exits
the MPLS domain. The packet is then forwarded based on the destination IP address
contained in the packet’s original IP header according to the traditional shortest path
calculated by the IP routing protocol.

Information Distribution Component

Traffic engineering requires detailed knowledge about the network topology as well as
dynamic information about network loading. To implement the information distribution
component, simple extensions to the IGPs are defined. Link attributes are included as
part of each router’s link-state advertisement. IS-IS extensions include the definition of
new type length values (TLVs), whereas OSPF extensions are implemented with opaque
link-state advertisements (LSAs). The standard flooding algorithm used by the link-state
IGPs ensures that link attributes are distributed to all routers in the routing domain. Some
of the traffic engineering extensions to be added to the IGP link-state advertisement
include maximum link bandwidth, maximum reserved link bandwidth, current bandwidth
reservation, and link coloring.

Each router maintains network link attributes and topology information in a specialized
traffic engineering database. The traffic engineering database is used exclusively for
calculating explicit paths for the placement of LSPs across the physical topology. A
separate database is maintained so that the subsequent traffic engineering computation
is independent of the IGP and the IGP’s link-state database. Meanwhile, the IGP continues
its operation without modification, performing the traditional shortest-path calculation
based on information contained in the router’s link-state database.

Copyright © 2012, Juniper Networks, Inc. 5

Junos OS 12.1 MPLS Applications Configuration Guide

Path Selection Component

After network link attributes and topology information are flooded by the IGP and placed
in the traffic engineering database, each ingress router uses the traffic engineering
database to calculate the paths for its own set of LSPs across the routing domain. The
path for each LSP can be represented by either a strict or loose explicit route. An explicit
route is a preconfigured sequence of routers that should be part of the physical path of
the LSP. If the ingress router specifies all the routers in the LSP, the LSP is said to be
identified by a strict explicit route. If the ingress router specifies only some of the routers
in the LSP, the LSP is described as a loose explicit route. Support for strict and loose
explicit routes allows the path selection process to be given broad latitude whenever
possible, but to be constrained when necessary.

The ingress router determines the physical path for each LSP by applying a Constrained
Shortest Path First (CSPF) algorithm to the information in the traffic engineering database.
CSPF is a shortest-path-first algorithm that has been modified to take into account
specific restrictions when the shortest path across the network is calculated. Input into
the CSPF algorithm includes:

• Topology link-state information learned from the IGP and maintained in the traffic
engineering database

• Attributes associated with the state of network resources (such as total link bandwidth,
reserved link bandwidth, available link bandwidth, and link color) that are carried by
IGP extensions and stored in the traffic engineering database

• Administrative attributes required to support traffic traversing the proposed LSP (such
as bandwidth requirements, maximum hop count, and administrative policy
requirements) that are obtained from user configuration

As CSPF considers each candidate node and link for a new LSP, it either accepts or rejects
a specific path component based on resource availability or whether selecting the
component violates user policy constraints. The output of the CSPF calculation is an
explicit route consisting of a sequence of router addresses that provides the shortest
path through the network that meets the constraints. This explicit route is then passed
to the signaling component, which establishes the forwarding state in the routers along
the LSP.

Offline Planning and Analysis

Despite the reduced management effort resulting from online path calculation, an offline
planning and analysis tool is still required to optimize traffic engineering globally. Online
calculation takes resource constraints into account and calculates one LSP at a time.
The challenge with this approach is that it is not deterministic. The order in which LSPs
are calculated plays a critical role in determining each LSP’s physical path across the
network. LSPs that are calculated early in the process have more resources available to
them than LSPs calculated later in the process because previously calculated LSPs
consume network resources. If the order in which the LSPs are calculated is changed,
the resulting set of physical paths for the LSPs also can change.

6 Copyright © 2012, Juniper Networks, Inc.

 Chapter 1: Traffic Engineering Overview

An offline planning and analysis tool simultaneously examines each link’s resource
constraints and the requirements of each LSP. Although the offline approach can take
several hours to complete, it performs global calculations, compares the results of each
calculation, and then selects the best solution for the network as a whole. The output of
the offline calculation is a set of LSPs that optimizes utilization of network resources.
After the offline calculation is completed, the LSPs can be established in any order
because each is installed according to the rules for the globally optimized solution.

Signaling Component

An LSP is not known to be workable until it is actually established by the signaling

component. The signaling component, which is responsible for establishing LSP state
and distributing labels, relies on a number of extensions to RSVP:

• The Explicit Route object allows an RSVP path message to traverse an explicit sequence
of routers that is independent of conventional shortest-path IP routing. The explicit
route can be either strict or loose.

• The Label Request object permits the RSVP path message to request that intermediate
routers provide a label binding for the LSP that it is establishing.

• The Label object allows RSVP to support the distribution of labels without changing
its existing mechanisms. Because the RSVP Resv message follows the reverse path
of the RSVP path message, the Label object supports the distribution of labels from
downstream nodes to upstream nodes.

Flexible LSP Calculation and Configuration

Traffic engineering involves mapping traffic flow onto a physical topology. You can
determine the paths online using constraint-based routing. Regardless of how the physical
path is calculated, the forwarding state is installed across the network through RSVP.

The Junos OS supports the following ways to route and configure an LSP:

• You can calculate the full path for the LSP offline and individually configure each router
in the LSP with the necessary static forwarding state. This is analogous to the way
some Internet service providers (ISPs) configure their IP-over-ATM cores.

• You can calculate the full path for the LSP offline and statically configure the ingress
router with the full path. The ingress router then uses RSVP as a dynamic signaling
protocol to install a forwarding state in each router along the LSP.

• You can rely on constraint-based routing to perform dynamic online LSP calculation.
You configure the constraints for each LSP; then the network itself determines the
path that best meets those constraints. Specifically, the ingress router calculates the
entire LSP based on the constraints and then initiates signaling across the network.

• You can calculate a partial path for an LSP offline and statically configure the ingress
router with a subset of the routers in the path; then you can permit online calculation
to determine the complete path.

Copyright © 2012, Juniper Networks, Inc. 7

Junos OS 12.1 MPLS Applications Configuration Guide

For example, consider a topology that includes two east-west paths across the United
States: one in the north through Chicago and one in the south through Dallas. If you
want to establish an LSP between a router in New York and one in San Francisco, you
can configure the partial path for the LSP to include a single loose-routed hop of a
router in Dallas. The result is an LSP routed along the southern path. The ingress router
uses CSPF to compute the complete path and RSVP to install the forwarding state
along the LSP.

• You can configure the ingress router with no constraints whatsoever. In this case,
normal IGP shortest-path routing is used to determine the path of the LSP. This
configuration does not provide any value in terms of traffic engineering. However, it is
easy and might be useful in situations when services such as virtual private networks
(VPNs) are needed.

In all these cases, you can specify any number of LSPs as backups for the primary LSP,
thus allowing you to combine more than one configuration approach. For example, you
might explicitly compute the primary path offline, set the secondary path to be
constraint-based, and have the tertiary path be unconstrained. If a circuit on which the
primary LSP is routed fails, the ingress router notices the outage from error notifications
received from a downstream router or by the expiration of RSVP soft-state information.
Then the router dynamically forwards traffic to a hot-standby LSP or calls on RSVP to
create a forwarding state for a new backup LSP.

8 Copyright © 2012, Juniper Networks, Inc.

CHAPTER 2

Complete MPLS Applications

Configuration Statements

This chapter is organized as follows:

• [edit logical-systems] Hierarchy Level on page 9

• [edit protocols connections] Hierarchy Level on page 10
• [edit protocols ldp] Hierarchy Level on page 10
• [edit protocols link-management] Hierarchy Level on page 12
• [edit protocols mpls] Hierarchy Level on page 13
• [edit protocols rsvp] Hierarchy Level on page 17

[edit logical-systems] Hierarchy Level

The following MPLS protocol statements can be configured at the [edit logical-systems]
hierarchy level. This is not a comprehensive list of statements available for logical systems.
Only the statements that are also documented in this manual are listed here. For more
information about logical systems, see the Junos OS Routing Protocols Configuration Guide.

NOTE: Beginning with Junos OS Release 9.3, the logical router feature has
been renamed logical system.

All configuration statements, operational commands, show command

outputs, error messages, log messages, and SNMP MIB objects that contain
the string logical-router or logical-routers have been changed to
logical-system and logical-systems, respectively.

logical-systems {
logical-system-name {
protocols {
connections {
connections-configuration;
}
ldp {
ldp-configuration;
}

Copyright © 2012, Juniper Networks, Inc. 9

Junos OS 12.1 MPLS Applications Configuration Guide

link-management {
link-management-configuration;
}
mpls {
mpls-configuration;
}
rsvp {
rsvp-configuration;
}
}
}
}

[edit protocols connections] Hierarchy Level

The following statements can also be configured at the [edit

logical-systems logical-system-name] hierarchy level:

protocols {
connections {
interface-switch connection-name {
interface interface-name.unit-number;
}
lsp-switch connection-name {
transmit-lsp label-switched-path;
receive-lsp label-switched-path;
}
p2mp-receive-switch {
output-interface interface-name.unit-number;
receive-p2mp-lsp receiving-point-to-multipoint-lsp;
}
p2mp-transmit-switch {
input-interface input-interface-name.unit-number;
transmit-p2mp-lsp transmitting-point-to-multipoint-lsp;
}
remote-interface-switch connection-name {
interface interface-name.unit-number;
transmit-lsp label-switched-path;
receive-lsp label-switched-path;
}
}
}

[edit protocols ldp] Hierarchy Level

The following statements can also be configured at the [edit

logical-systems logical-system-name] hierarchy level:

protocols {
ldp {
(deaggregate | no-deaggregate);
egress-policy [ policy-names ];
explicit-null;
export [ policy-names ];
graceful-restart {

10 Copyright © 2012, Juniper Networks, Inc.

 Chapter 2: Complete MPLS Applications Configuration Statements

disable;
helper-disable;
maximum-neighbor-recovery-time seconds;
reconnect-time seconds;
recovery-time seconds;
}
import [ policy-names];
interface (interface-name | all) {
disable;
hello-interval seconds;
hold-time seconds;
transport-address (interface | router-id);
}
keepalive-interval seconds;
keepalive-timeout seconds;
log-updown {
trap disable;
}
no-forwarding;
oam {
bfd-liveness-detection {
detection-time threshold milliseconds;
ecmp;
failure-action {
remove-nexthop;
remove-route;
}
holddown-interval milliseconds;
minimum-interval milliseconds;
minimum-receive-interval milliseconds;
minimum-transmit-interval milliseconds;
multiplier detection-time-multiplier;
no-adaptation;
transmit-interval {
minimum-interval milliseconds;
threshold milliseconds;
}
}
fec fec-address;
ingress-policy ingress-policy-name;
periodic-traceroute {
disable;
exp exp-value;
fanout fanout-value;
frequency minutes;
paths number-of-paths;
retries retry-attempts;
source address;
ttl ttl-value;
wait seconds;
}
}
p2mp;
policing {
fec fec-address {
ingress-traffic filter-name;

Copyright © 2012, Juniper Networks, Inc. 11

Junos OS 12.1 MPLS Applications Configuration Guide

transit-traffic filter-name;
}
}
preference preference;
session address {
authentication-key md5-authentication-key;
}
strict-targeted-hellos;
traceoptions {
file filename <files number <size size> <world-readable | no-world-readable>;
flag flag <flag-modifier> <disable>;
}
track-igp-metric;
traffic-statistics {
file filename <files number> <size size> <world-readable | no-world-readable>;
interval interval;
no-penultimate-hop;
}
transport-address (address | interface | router-id);
}
}

[edit protocols link-management] Hierarchy Level

The following statements can also be configured at the [edit

logical-systems logical-system-name] hierarchy level:

protocols {
link-management {
peer peer-name {
address address;
control-channel [ control-channel-interfaces ];
te-link [te-link-names];
}
te-link te-link-name {
disable;
interface interface-name {
disable;
local-address address;
remote-address address;
remote-id id-number;
}
label-switched-path label-switched-path-name;
local-address address;
remote-address address;
remote-id id-number;
}
traceoptions {
file filename <files number> <size size> <world-readable | no-world-readable>;
flag flag <flag-modifier> <disable>;
}
}
}

12 Copyright © 2012, Juniper Networks, Inc.

 Chapter 2: Complete MPLS Applications Configuration Statements

[edit protocols mpls] Hierarchy Level

The following statements can also be configured at the [edit

logical-systems logical-system-name] hierarchy level:

protocols {
mpls {
disable;
admin-group {
exclude [ group-names ];
include-all [ group-names ];
include-any [ group-names ];
}
admin-groups {
group-name group-value;
}
advertisement-hold-time seconds;
auto-policing {
class all (drop | loss-priority-high | loss-priority-low);
class ctnumber (drop | loss-priority-high | loss-priority-low);
}
bandwidth bps {
ct0 bps;
ct1 bps;
ct2 bps;
ct3 bps;
}
class-of-service cos-value;
diffserv-te {
bandwidth-model {
extended-mam;
mam;
rdm;
}
te-class-matrix {
tenumber {
priority priority;
traffic-class ctnumber priority priority;
}
}
}
explicit-null;
hop-limit number;
icmp-tunneling;
interface (interface-name | all) {
disable;
admin-group [group-names];
srlg srlg-name;
}
ipv6-tunneling;
label-switched-path lsp-name {
disable;
adaptive;
admin-down;

Copyright © 2012, Juniper Networks, Inc. 13

Junos OS 12.1 MPLS Applications Configuration Guide

admin-group {
exclude [ group-names ];
include-all;
include-any [ group-names ];
}
associate-lsp;
auto-bandwidth {
adjust-interval seconds;
adjust-threshold percent;
maximum-bandwidth bps;
minimum-bandwidth bps;
monitor-bandwidth;
}
bandwidth bps {
ct0 bps;
ct1 bps;
ct2 bps;
ct3 bps;
}
class-of-service cos-value;
description text;
exclude-srlg;
fast-reroute {
(bandwidth bps | bandwidth-percent percent);
(exclude [ group-names ] | no-exclude);
hop-limit number;
(include-all [ group-names ] | no-include-all);
(include-any [ group-names ] | no-include-any);
}
from address;
hop-limit number;
install {
destination-prefix/prefix-length <active>;
}
ldp-tunneling;
link-protection;
lsp-attributes {
encoding-type (ethernet | packet | pdh | sonet-sdh);
gpid (ethernet | hdlc | ipv4 | ppp);
signal-bandwidth type;
switching-type (fiber | lambda | psc-1 | tdm);
}
metric number;
no-cspf;
no-decrement-ttl;
node-link-protection;
optimize-timer seconds;
p2mp path-name;
policing {
filter filter-name;
no-auto-policing;
}
preference preference;
primary path-name {
adaptive;
admin-group {

14 Copyright © 2012, Juniper Networks, Inc.

 Chapter 2: Complete MPLS Applications Configuration Statements

exclude [ group-names ];
include-all [ group-names ];
include-any [ group-names ];
}
bandwidth bps {
ct0 bps;
ct1 bps;
ct2 bps;
ct3 bps;
}
class-of-service cos-value;
hop-limit number;
no-cspf;
no-decrement-ttl;
optimize-timer seconds;
preference preference;
priority setup-priority reservation-priority;
(record | no-record);
select (manual | unconditional);
}
standby;
}
priority setup-priority reservation-priority;
(random | least-fill | most-fill);
(record | no-record);
retry-limit number;
retry-timer seconds;
revert-timer seconds;
secondary path-name {
adaptive;
admin-group {
exclude [ group-names ];
include-all [ group-names ];
include-any [ group-names ];
}
bandwidth bps {
ct0 bps;
ct1 bps;
ct2 bps;
ct3 bps;
}
class-of-service cos-value;
hop-limit number;
no-cspf;
no-decrement-ttl;
optimize-timer seconds;
preference preference;
priority setup-priority reservation-priority;
(record | no-record);
select (manual | unconditional);
standby;
}
soft-preemption;
standby;
to address;
traceoptions {

Copyright © 2012, Juniper Networks, Inc. 15

Junos OS 12.1 MPLS Applications Configuration Guide

file filename <files number> <size size> <world-readable | no-world-readable>;

flag flag <flag-modifier> <disable>;
}
}
log-updown {
no-trap {
mpls-lsp-traps;
rfc3812-traps;
}
(syslog | no-syslog);
trap;
trap-path-down;
trap-path-up;
}
oam {
lsp-ping-interval;
mpls-tp-mode;
traceoptions;
}
no-cspf;
no-decrement-ttl;
no-propagate-ttl;
optimize-aggressive;
optimize-timer seconds;
path path-name {
(address | hostname) <strict | loose>;
}
path-mtu {
allow-fragmentation;
rsvp {
mtu-signaling;
}
}
preference preference;
priority setup-priority reservation-priority;
(record | no-record);
revert-timer seconds;
rsvp-error-hold-time seconds;
smart-optimize-timer seconds;
standby;
static-label-switched-path lsp-name {
bypass bypass-name {
bandwidth bps;
description string;
next-hop (address | interface-name | address/interface-name);
push out-label;
to address;
}
ingress {
bandwidth bps;
class-of-service cos-value;
description string;
install {
destination-prefix <active>;
}
link-protection bypass-name name;

16 Copyright © 2012, Juniper Networks, Inc.

 Chapter 2: Complete MPLS Applications Configuration Statements

metric metric;
next-hop (address | interface-name | address/interface-name);
node-protection bypass-name name next-next-label label;
no-install-to-address;
policing {
filter filter-name;
no-auto-policing;
}
preference preference;
push out-label;
to address;
}
transit incoming-label {
bandwidth bps;
description string;
link-protection bypass-name name;
next-hop (address | interface-name | address/interface-name);
node-protection bypass-name name next-next-label label;
pop;
swap out-label;
}
statistics {
auto-bandwidth;
file filename <files number> <size size> <world-readable | no-world-readable>;
interval seconds;
}
traceoptions {
file filename <files number> <size size> <world-readable | no-world-readable>;
flag flag;
}
traffic-engineering (bgp | bgp-igp | bgp-igp-both-ribs | mpls-forwarding);
transit-lsp-association;
}

[edit protocols rsvp] Hierarchy Level

The following statements can also be configured at the [edit

logical-systems logical-system-name] hierarchy level:

protocols {
rsvp {
disable;
fast-reroute optimize-timer seconds;
graceful-deletion-timeout seconds;
graceful-restart {
disable;
helper-disable;
maximum-helper-recovery-time seconds;
maximum-helper-restart-time seconds;
}
interface interface-name {
disable;
(aggregate | no-aggregate);
authentication-key key;
bandwidth bps;

Copyright © 2012, Juniper Networks, Inc. 17

Junos OS 12.1 MPLS Applications Configuration Guide

hello-interval seconds;
link-protection {
disable;
admin-group {
exclude group-names;
include-all group-names;
include-any group-names;
}
bandwidth bandwidth;
bypass bypass-name {
bandwidth bps {
ct0 bps;
ct1 bps;
ct2 bps;
ct3 bps;
}
description text;
hop-limit number;
no-cspf;
path address <strict | loose>;
priority setup-priority reservation-priority;
to address;
}
class-of-service cos-value;
exclude-srlg;
hop-limit number;
max-bypasses number;
no-cspf;
no-node-protection;
optimize-timer seconds;
path address <strict | loose>;
priority setup-priority reservation-priority;
subscription percentage {
ct0 percentage;
ct1 percentage;
ct2 percentage;
ct3 percentage;
}
}
(reliable | no-reliable);
subscription percentage {
ct0 percentage;
ct1 percentage;
ct2 percentage;
ct3 percentage;
}
update-threshold percentage;
}
keep-multiplier number;
load-balance {
bandwidth;
}
no-node-id-subobject;
no-p2mp-sublsp;
peer-interface peer-interface-name {
(aggregate | no-aggregate);

18 Copyright © 2012, Juniper Networks, Inc.

 Chapter 2: Complete MPLS Applications Configuration Statements

authentication-key key;
disable;
hello-interval seconds;
(reliable | no-reliable);
}
preemption {
(aggressive | disabled | normal);
soft-preemption {
cleanup-timer seconds;
}
}
refresh-time seconds;
traceoptions {
file filename <files number> <size size> <world-readable | no-world-readable>;
flag flag <flag-modifier> <disable>;
}
tunnel-services {
devices device-names;
}
}
}

Copyright © 2012, Juniper Networks, Inc. 19

Junos OS 12.1 MPLS Applications Configuration Guide

20 Copyright © 2012, Juniper Networks, Inc.

PART 2

MPLS
• MPLS Overview on page 23
• MPLS Router Configuration Guidelines on page 55
• MPLS-Signaled LSP Configuration Guidelines on page 143
• DiffServ-Aware Traffic Engineering Configuration Guidelines on page 187
• Static and Explicit-Path LSP Configuration Guidelines on page 211
• Point-to-Multipoint LSP Configuration Guidelines on page 221
• Miscellaneous MPLS Properties Configuration Guidelines on page 247
• Summary of MPLS Configuration Statements on page 273

Copyright © 2012, Juniper Networks, Inc. 21

Junos OS 12.1 MPLS Applications Configuration Guide

22 Copyright © 2012, Juniper Networks, Inc.

CHAPTER 3

MPLS Overview

This chapter discusses the following topics:

• MPLS Introduction on page 24

• Supported MPLS Standards on page 24
• Link-Layer Support on page 26
• MPLS and Traffic Engineering on page 27
• Label Description on page 27
• Special Labels on page 28
• Label Allocation on page 28
• Operations on Labels on page 30
• Routers in an LSP on page 30
• How a Packet Travels Along an LSP on page 31
• Types of LSPs on page 31
• Scope of LSPs on page 32
• Constrained-Path LSP Computation on page 32
• How CSPF Selects a Path on page 33
• Path Selection Tie-Breaking on page 34
• Computing Paths Offline on page 34
• LSPs on an Overloaded Router on page 35
• Fate Sharing on page 35
• SRLG Overview on page 36
• IGP Shortcuts on page 37
• Enabling IGP Shortcuts on page 38
• LSPs Qualified in Shortcut Computations on page 38
• IGP Shortcut Applications on page 39
• IGP Shortcuts and Routing Table on page 39
• IGP Shortcuts and VPNs on page 40
• Advertising LSPs into IGPs on page 40
• IP and MPLS Packets on Aggregated Interfaces on page 41

Copyright © 2012, Juniper Networks, Inc. 23

Junos OS 12.1 MPLS Applications Configuration Guide

• MPLS Applications on page 42

• BGP Destinations on page 42
• IGP and BGP Destinations on page 44
• Selecting a Forwarding LSP Next Hop on page 44
• MPLS and Routing Tables on page 45
• MPLS and Traffic Protection on page 46
• Fast Reroute on page 47
• Fast Reroute Overview on page 47
• Detour Merging Process on page 49
• Detour Computations on page 50
• Fast Reroute Path Optimization on page 51
• Automatic Bandwidth Allocation on page 51
• Point-to-Multipoint LSPs Overview on page 52

MPLS Introduction

MPLS provides a mechanism for engineering network traffic patterns that is independent
of routing tables. MPLS assigns short labels to network packets that describe how to
forward them through the network. MPLS is independent of any routing protocol and
can be used for unicast packets.

In the traditional Level 3 forwarding paradigm, as a packet travels from one router to the
next, an independent forwarding decision is made at each hop. The IP network layer
header is analyzed, and the next hop is chosen based on this analysis and on the
information in the routing table. In an MPLS environment, the analysis of the packet
header is performed just once, when a packet enters the MPLS cloud. The packet is then
assigned to a stream, which is identified by a label, which is a short (20-bit), fixed-length
value at the front of the packet. Labels are used as lookup indexes for the label forwarding
table. For each label, this table stores forwarding information. You can associate additional
information with a label—such as class-of-service (CoS) values—that can be used to
prioritize packet forwarding.

Supported MPLS Standards

The Junos OS substantially supports the following RFCs and Internet drafts, which define
standards for MPLS and traffic engineering.

• RFC 2858, Multiprotocol Extensions for BGP-4

• RFC 3031, Multiprotocol Label Switching Architecture

• RFC 3032, MPLS Label Stack Encoding

• RFC 3140, Per Hop Behavior Identification Codes

• RFC 3270, Multi-Protocol [sic] Label Switching (MPLS) Support of Differentiated Services

Only E-LSPs are supported.

24 Copyright © 2012, Juniper Networks, Inc.

 Chapter 3: MPLS Overview

• RFC 3443, Time To Live (TTL) Processing in Multi-Protocol [sic] Label Switching (MPLS)
Networks

• RFC 3478, Graceful Restart Mechanism for Label Distribution Protocol

• RFC 4090, Fast Reroute Extensions to RSVP-TE for LSP Tunnels

Node protection in facility backup is not supported.

• RFC 4124, Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering

• RFC 4364, BGP/MPLS IP Virtual Private Networks (VPNs)

• RFC 4379, Detecting Multi-Protocol [sic] Label Switched (MPLS) Data Plane Failures

The traceroute functionality is supported only on transit routers.

• RFC 4950, ICMP Extensions for Multiprotocol Label Switching

• Internet draft draft-ietf-bfd-mpls-02.txt, BFD for MPLS LSPs

• Internet draft draft-ietf-mpls-rsvp-te-p2mp-01.txt, Extensions to RSVP-TE for Point to

Multipoint TE LSPs (expires June 2005)

• Internet draft draft-ietf-mpls-soft-preemption-02.txt, MPLS Traffic Engineering Soft

preemption

The following RFCs and Internet drafts do not define standards, but provide information
about MPLS, traffic engineering, and related technologies. The IETF classifies them
variously as “Experimental,” “Historic,” or “Informational.”

• RFC 2547, BGP/MPLS VPNs

• RFC 2702, Requirements for Traffic Engineering Over MPLS

• RFC 3063, MPLS Loop Prevention Mechanism

• RFC 3208, PGM Reliable Transport Protocol Specification

Only the network element is supported.

• RFC 3469, Framework for Multi-Protocol [sic] Label Switching (MPLS)-based Recovery

• RFC 3564, Requirements for Support of Differentiated Services-aware MPLS Traffic

Engineering

• RFC 4125, Maximum Allocation Bandwidth Constraints Model for Diffserv-aware MPLS
Traffic Engineering

• RFC 4127, Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic
Engineering

Copyright © 2012, Juniper Networks, Inc. 25

Junos OS 12.1 MPLS Applications Configuration Guide

• Internet draft draft-martini-l2circuit-encap-mpls-11.txt, Encapsulation Methods for

Transport of Layer 2 Frames Over IP and MPLS Networks

The Junos OS differs from the Internet draft in the following ways:

• A packet with a sequence number of 0 is treated as out of sequence.

• Any packet which does not have the next incremental sequence number is considered
out of sequence.

• When out-of-sequence packets arrive, the expected sequence number for the
neighbor is set to the sequence number in the Layer 2 circuit control word.

• Internet draft draft-martini-l2circuit-trans-mpls-19.txt, Transport of Layer 2 Frames

Over MPLS

• Internet draft draft-raggarwa-mpls-p2mp-te-02.txt, Establishing Point to Multipoint

MPLS TE LSPs

The features discussed in the indicated sections of the draft are not supported:

• Nonadjacent signaling for branch LSPs (section 7.1)

• Make-before-break and fast reroute (section 9)

• LSP hierarchy using point-to-point LSPs (section 10)

Related • Supported GMPLS Standards on page 579

Documentation
• Supported LDP Standards on page 464

• Supported RSVP Standards on page 376

• Accessing Standards Documents on the Internet

Link-Layer Support

MPLS supports the following link-layer protocols, which are all supported in the Junos
OS MPLS implementation:

• Point-to-Point Protocol (PPP)—Protocol ID 0x0281, Network Control Protocol (NCP)

protocol ID 0x8281.

• Ethernet/Cisco High-level Data Link Control (HDLC)—Ethernet type 0x8847.

• Asynchronous Transfer Mode (ATM)—Subnetwork attachment point encoded

(SNAP-encoded) Ethernet type 0x8847. Support is included for both point-to-point
mode or nonbroadcast multiaccess (NBMA) mode. Support is not included for encoding
MPLS labels as part of ATM virtual path identifier/virtual circuit identifier (VPI/VCI).

• Frame Relay—SNAP-encoded, Ethernet type 0x8847. Support is not included for

encoding MPLS labels as part of Frame Relay data-link connection identifier (DLCI).

• Generic routing encapsulation (GRE) tunnel—Ethernet type 0x8847.

26 Copyright © 2012, Juniper Networks, Inc.

 Chapter 3: MPLS Overview

MPLS and Traffic Engineering

Traffic engineering allows you to control the path that data packets follow, bypassing
the standard routing model, which uses routing tables. Traffic engineering moves flows
from congested links to alternate links that would not be selected by the automatically
computed destination-based shortest path. With traffic engineering, you can:

• Make more efficient use of expensive long-haul fibers.

• Control how traffic is rerouted in the face of single or multiple failures.

• Classify critical and regular traffic on a per-path basis.

The core of the traffic engineering design is based on building label-switched paths
(LSPs) among routers. An LSP is connection-oriented, like a virtual circuit in Frame Relay
or ATM. LSPs are not reliable: Packets entering an LSP do not have delivery guarantees,
although preferential treatment is possible. LSPs also are similar to unidirectional tunnels
in that packets entering a path are encapsulated in an envelope and switched across the
entire path without being touched by intermediate nodes. LSPs provide fine-grained
control over how packets are forwarded in a network. To provide reliability, an LSP can
use a set of primary and secondary paths.

LSPs can be configured for BGP traffic only (traffic whose destination is outside of an
autonomous system [AS]). In this case, traffic within the AS is not affected by the
presence of LSPs. LSPs can also be configured for both BGP and interior gateway protocol
(IGP) traffic; therefore, both intra-AS and inter-AS traffic is affected by the LSPs.

This section discusses the following topics:

• Label Description on page 27

• Label Allocation on page 28

• Routers in an LSP on page 30

• How a Packet Travels Along an LSP on page 31

• Types of LSPs on page 31

• Scope of LSPs on page 32

• Constrained-Path LSP Computation on page 32

• LSPs on an Overloaded Router on page 35

• Fate Sharing on page 35

• IGP Shortcuts on page 37

• Advertising LSPs into IGPs on page 40

Label Description

Packets traveling along an LSP are identified by a label—a 20-bit, unsigned integer in the
range 0 through 1,048,575. For push labels on ingress routers, no labels in this range are

Copyright © 2012, Juniper Networks, Inc. 27

Junos OS 12.1 MPLS Applications Configuration Guide

restricted. For incoming labels on the transit static LSP, the label value is restricted to
1,000,000 through 1,048,575.

Special Labels

Some of the reserved labels (in the 0 through 15 range) have well-defined meanings. For
more complete details, see RFC 3032, MPLS Label Stack Encoding.

• 0, IPv4 Explicit Null label—This value is legal only when it is the sole label entry (no
label stacking). It indicates that the label must be popped upon receipt. Forwarding
continues based on the IP version 4 (IPv4) packet.

• 1, Router Alert label—When a packet is received with a top label value of 1, it is delivered
to the local software module for processing.

• 2, IPv6 Explicit Null label—This value is legal only when it is the sole label entry (no
label stacking). It indicates that the label must be popped on receipt. Forwarding
continues based on the IP version 6 (IPv6) packet.

• 3, Implicit Null label—This label is used in the control protocol (LDP or RSVP) only to
request label popping by the downstream router. It never actually appears in the
encapsulation. Labels with a value of 3 should not be used in the data packet as real
labels. No payload type (IPv4 or IPv6) is implied with this label.

• 4 through 15—Unassigned.

Special labels are commonly used between the egress and penultimate routers of an
LSP. If the LSP is configured to carry IPv4 packets only, the egress router might signal
the penultimate router to use 0 as a final-hop label. If the LSP is configured to carry IPv6
packets only, the egress router might signal the penultimate router to use 2 as a final-hop
label.

The egress router might simply signal the penultimate router to use 3 as the final label,
which is a request to perform penultimate-hop label popping. The egress router will not
process a labeled packet; rather, it receives the payload (IPv4, IPv6, or others) directly,
reducing one MPLS lookup at egress.

For label-stacked packets, the egress router receives an MPLS label packet with its top
label already popped by the penultimate router. The egress router cannot receive
label-stacked packets that use label 0 or 2. It typically requests label 3 from the
penultimate router.

Label Allocation

In the Junos OS, label values are allocated per router. The display output shows only the
label (for example, 01024). Labels for multicast packets are independent of those for
unicast packets. Currently, the Junos OS does not support multicast labels.

Labels are assigned by downstream routers relative to the flow of packets. A router
receiving labeled packets (the next-hop router) is responsible for assigning incoming
labels. A received packet containing a label that is unrecognized (unassigned) is dropped.
For unrecognized labels, the router does not attempt to unwrap the label to analyze the

28 Copyright © 2012, Juniper Networks, Inc.

 Chapter 3: MPLS Overview

network layer header, nor does it generate an Internet Control Message Protocol (ICMP)
destination unreachable message.

A packet can carry a number of labels, organized as a last-in, first-out stack. This is
referred to as a label stack. At a particular router, the decision about how to forward a
labeled packet is based exclusively on the label at the top of the stack.

Figure 1 on page 29 shows the encoding of a single label. The encoding appears after
data link layer headers, but before any network layer header.

Figure 1: Label Encoding

Figure 2 on page 29 illustrates the purpose of the class-of-service bits (also known as
the EXP or experimental bits). Bits 20 and 21 specify the queue number. Bit 22 is the
packet loss priority (PLP) bit used to specify the random early detection (RED) drop
profile. For more information about class of service and the class-of-service bits, see
“Configuring Class of Service for MPLS LSPs” on page 175.

Figure 2: Class-of-Service Bits

Copyright © 2012, Juniper Networks, Inc. 29

Junos OS 12.1 MPLS Applications Configuration Guide

Operations on Labels

The router supports the following label operations:

• Push—Add a new label to the top of the packet. For IPv4 packets, the new label is the
first label. The time-to-live (TTL) and s bits are derived from the IP packet header. The
MPLS class of service (CoS) is derived from the queue number. If the push operation
is performed on an existing MPLS packet, you will have a packet with two or more
labels. This is called label stacking. The top label must have its s bit set to 0, and might
derive CoS and TTL from lower levels. The new top label in a label stack always
initializes its TTL to 255, regardless of the TTL value of lower labels.

• Pop—Remove the label from the beginning of the packet. Once the label is removed,
the TTL is copied from the label into the IP packet header, and the underlying IP packet
is forwarded as a native IP packet. In the case of multiple labels in a packet (label
stacking), removal of the top label yields another MPLS packet. The new top label
might derive CoS and TTL from a previous top label. The popped TTL value from the
previous top label is not written back to the new top label.

• Swap—Replace the label at the top of the label stack with a new label. The S and CoS
bits are copied from the previous label, and the TTL value is copied and decremented
(unless the no-decrement-ttl or no-propagate-ttl statement is configured). A transit
router supports a label stack of any depth.

• Multiple Push—Add multiple labels (up to three) on top of existing packets. This
operation is equivalent to pushing multiple times.

• Swap and Push—Replace the existing top of the label stack with a new label, and then
push another new label on top.

Routers in an LSP

Each router in an LSP performs one of the following functions:

• Ingress router—The router at the beginning of an LSP. This router encapsulates IP

packets with an MPLS Layer 2 frame and forwards it to the next router in the path.
Each LSP can have only one ingress router.

• Egress router—The router at the end of an LSP. This router removes the MPLS
encapsulation, thus transforming it from an MPLS packet to an IP packet, and forwards
the packet to its final destination using information in the IP forwarding table. Each
LSP can have only one egress router. The ingress and egress routers in an LSP cannot
be the same router.

• Transit router—Any intermediate router in the LSP between the ingress and egress
routers. A transit router forwards received MPLS packets to the next router in the MPLS
path. An LSP can contain zero or more transit routers, up to a maximum of 253 transit
routers in a single LSP.

30 Copyright © 2012, Juniper Networks, Inc.

 Chapter 3: MPLS Overview

A single router can be part of multiple LSPs. It can be the ingress or egress router for one
or more LSPs, and it also can be a transit router in one or more LSPs. The functions that
each router supports depend on your network design.

How a Packet Travels Along an LSP

When an IP packet enters an LSP, the ingress router examines the packet and assigns it
a label based on its destination, placing the label in the packet’s header. The label
transforms the packet from one that is forwarded based on its IP routing information to
one that is forwarded based on information associated with the label.

The packet is then forwarded to the next router in the LSP. This router and all subsequent
routers in the LSP do not examine any of the IP routing information in the labeled packet.
Rather, they use the label to look up information in their label forwarding table. They
then replace the old label with a new label and forward the packet to the next router in
the path.

When the packet reaches the egress router, the label is removed, and the packet again
becomes a native IP packet and is again forwarded based on its IP routing information.

Types of LSPs

There are three types of LSPs:

• Static LSPs—For static paths, you must manually assign labels on all routers involved
(ingress, transit, and egress). No signaling protocol is needed. This procedure is similar
to configuring static routes on individual routers. Like static routes, there is no error
reporting, liveliness detection, or statistics reporting.

• LDP-signaled LSPs—See “LDP Introduction” on page 463.

• RSVP-signaled LSPs—For signaled paths, RSVP is used to set up the path and
dynamically assign labels. (RSVP signaling messages are used to set up signaled
paths.) You configure only the ingress router. The transit and egress routers accept
signaling information from the ingress router, and they set up and maintain the LSP
cooperatively. Any errors encountered while establishing an LSP are reported to the
ingress router for diagnostics. For signaled LSPs to work, a version of RSVP that supports
tunnel extensions must be enabled on all routers.

There are two types of RSVP-signaled LSPs:

• Explicit-path LSPs—All intermediate hops of the LSP are manually configured. The
intermediate hops can be strict, loose, or any combination of the two. Explicit path
LSPs provide you with complete control over how the path is set up. They are similar
to static LSPs but require much less configuration.

• Constrained-path LSPs—The intermediate hops of the LSP are automatically computed

by the software. The computation takes into account information provided by the
topology information from the IS-IS or OSPF link-state routing protocol, the current
network resource utilization determined by RSVP, and the resource requirements and
constraints of the LSP. For signaled constrained-path LSPs to work, either the IS-IS or

Copyright © 2012, Juniper Networks, Inc. 31

Junos OS 12.1 MPLS Applications Configuration Guide

OSPF protocol and the IS-IS or OSPF traffic engineering extensions must be enabled
on all routers.

Scope of LSPs

For constrained-path LSPs, the LSP computation is confined to one IGP domain, and
cannot cross any AS boundary. This prevents an AS from extending its IGP into another
AS.

Explicit-path LSPs, however, can cross as many AS boundaries as necessary. Because

intermediate hops are manually specified, the LSP does not depend on the IGP topology
or a local forwarding table.

Constrained-Path LSP Computation

The Constrained Shortest Path First (CSPF) algorithm is an advanced form of the
shortest-path-first (SPF) algorithm used in OSPF and IS-IS route computations. CSPF
is used in computing paths for LSPs that are subject to multiple constraints. When
computing paths for LSPs, CSPF considers not only the topology of the network, but also
the attributes of the LSP and the links, and it attempts to minimize congestion by
intelligently balancing the network load.

The constraints that CSPF considers include:

• LSP attributes

• Administrative groups (that is, link color requirements)

• Bandwidth requirements

• Explicit route (strict or loose)

• Hop limitations

• Priority (setup and hold)

• Link attributes

• Administrative groups (that is, link colors assigned to the link)

• Reservable bandwidth of the links (static bandwidth minus the currently reserved
bandwidth)

The data that CSPF considers comes from the following sources:

• Traffic engineering database—Provides CSPF with up-to-date topology information,

the current reservable bandwidth of links, and the link colors. For the CSPF algorithm
to perform its computations, a link-state IGP (such as OSPF or IS-IS) with special
extensions is needed. For CSPF to be effective, the link-state IGP on all routers must
support the special extensions. While building the topology database, the extended
IGP must take into consideration the current LSPs and must flood the route information
everywhere. Because changes in the reserved link bandwidth and link color cause

32 Copyright © 2012, Juniper Networks, Inc.

 Chapter 3: MPLS Overview

database updates, an extended IGP tends to flood more frequently than a normal IGP.
See Figure 3 on page 33 for a diagram of the relationships between these components.

• Currently active LSPs—Includes all the LSPs that should originate from the router and
their current operational status (up, down, or timeout).

Figure 3: CSPF Computation Process

This section discusses the following topics:

• How CSPF Selects a Path on page 33

• Path Selection Tie-Breaking on page 34

• Computing Paths Offline on page 34

How CSPF Selects a Path

To select a path, CSPF follows these steps:

1. Computes LSPs one at a time, beginning with the highest priority LSP (the one with
the lowest setup priority value). Among LSPs of equal priority, CSPF starts with those
that have the highest bandwidth requirement.

2. Prunes the traffic engineering database of all the links that are not full duplex and do
not have sufficient reservable bandwidth.

3. If the LSP configuration includes the include statement, prunes all links that do not
share any included colors.

4. If the LSP configuration includes the exclude statement, prunes all links that contain
excluded colors. If the link does not have a color, it is accepted.

5. Finds the shortest path toward the LSP’s egress router, taking into account
explicit-path constraints. For example, if the path must pass through Router A, two
separate SPFs are computed, one from the ingress router to Router A, the other from
Router A to the egress router.

6. If several paths have equal cost, chooses the one whose last-hop address is the same
as the LSP’s destination.

Copyright © 2012, Juniper Networks, Inc. 33

Junos OS 12.1 MPLS Applications Configuration Guide

7. If several equal-cost paths remain, selects the one with the fewest number of hops.

8. If several equal-cost paths remain, applies the CSPF load-balancing rule configured
on the LSP (least fill, most fill, or random).

Path Selection Tie-Breaking

If more than one path is available after the rules from the previous section have been
applied, a tie-breaking rule is applied to choose the path for the LSP. There are three
tie-breaking rules:

• Random—One of the remaining paths is picked at random. This rule tends to place an
equal number of LSPs on each link, regardless of the available bandwidth ratio.

• Least fill—The path with the largest minimum available bandwidth ratio is preferred.
This rule tries to equalize the reservation on each link.

• Most fill—The path with the smallest minimum available bandwidth ratio is preferred.
This rule tries to fill a link before moving on to alternative links.

The rule used depends on the configuration. Random is the default rule.

For the other rules, the following definitions are needed:

• Reservable bandwidth = bandwidth of link x subscription factor of link

• Available bandwidth = reservable bandwidth – (sum of the bandwidths of the LSPs

traversing the link)

• Available bandwidth ratio = available bandwidth/reservable bandwidth

• Minimum available bandwidth ratio (for a path) = the smallest available bandwidth
ratio of the links in a path

Computing Paths Offline

The Junos OS provides online, real-time CSPF computation only; each router performs
CSPF calculations independent of the other routers in the network. These calculations
are based on currently available topology information—information that is usually recent,
but not completely accurate. LSP placements are locally optimized, based on current
network status.

To optimize links globally across the network, you can use an offline tool to perform the
CSPF calculations and determine the paths for the LSPs. You can create such a tool
yourself, or you can modify an existing network design tool to perform these calculations.
You should run the tool periodically (daily or weekly) and download the results into the
router. An offline tool should take the following into account when performing the
optimized calculations:

• All the LSP’s requirements

• All link attributes

• Complete network topology

34 Copyright © 2012, Juniper Networks, Inc.

 Chapter 3: MPLS Overview

LSPs on an Overloaded Router

An overloaded router is a router running IS-IS with its overload bit set in its IS-IS
configuration. In this case, an MPLS LSP specifically refers to an RSVP-signaled or
LDP-signaled LSP. In the case of RSVP, it applies to both CSPF and non-CSPF LSPs.

You cannot establish transit LSPs through an overloaded router. However, you can
configure ingress and egress LSPs through an overloaded router.

NOTE: When you set the overload bit on an IS-IS router, all LSPs transiting
through it are recomputed and rerouted away from it. If the recomputation
fails, no additional attempt to reconfigure the LSP is made, and the affected
LSPs are disconnected.

An example of when you might want to establish transit LSPs through an overloaded
router is illustrated in Figure 4 on page 35, which shows an aggregation router
(Router A) dual-homed on two core routers (Router B and Router C). You want to include
the aggregation router in the LSP mesh, but transit LSPs should not pass through it,
because it is a less capable router with relatively low-bandwidth uplinks to the core.
Certain failure and rerouting scenarios could make it impossible for the aggregation router
to establish some of its LSPs. Consequently, you run the router in a steady state with the
overload bit set, but you are still able to establish ingress and egress LSPs through it.

Figure 4: Aggregation Router A Dual-Homed on Core Routers B and C

Fate Sharing

Fate sharing allows you to create a database of information that CSPF uses to compute
one or more backup paths to use in case the primary path becomes unstable. The
database describes the relationships between elements of the network, such as routers
and links. You can specify one or more elements within a group.

Through fate sharing, you can configure backup paths that minimize the number of shared
links and fiber paths with the primary paths as much as possible, to ensure that if a fiber
is cut, the minimum amount of data is lost and a path still exists to the destination.

Copyright © 2012, Juniper Networks, Inc. 35

Junos OS 12.1 MPLS Applications Configuration Guide

For a backup path to work optimally, it must not share links or physical fiber paths with
the primary path, ensuring that a single point of failure will not affect the primary and
backup paths simultaneously. For more information about fate sharing, see the Junos OS
Routing Protocols Configuration Guide.

SRLG Overview

In MPLS traffic engineering, a Shared Risk Link Group (SRLG) is a set of links sharing a
common resource, which affects all links in the set if the common resource fails. These
links share the same risk of failure and are therefore considered to belong to the same
SRLG. For example, links sharing a common fiber are said to be in the same SRLG because
a fault with the fiber might cause all links in the group to fail.

An SRLG is represented by a 32-bit number unique within an IGP (OSPFv2 and IS-IS)
domain. A link might belong to multiple SRLGs. The SRLG of a path in a label-switched
path (LSP) is the set of SRLGs for all the links in the path. When computing the secondary
path for an LSP, it is preferable to find a path such that the secondary and primary paths
do not have any links in common in case the SRLGs for the primary and secondary paths
are disjoint. This ensures that a single point of failure on a particular link does not bring
down both the primary and secondary paths in the LSP.

When the SRLG is configured, the device uses the Constrained Shortest Path First (CSPF)
algorithm and tries to keep the links used for the primary and secondary paths mutually
exclusive. If the primary path goes down, the CSPF algorithm computes the secondary
path by trying to avoid links that share any SRLG with the primary path. In addition, when
computing the path for a bypass LSP, CSPF tries to avoid links that share any SRLG with
the protected links.

When the SRLG is not configured, CSPF only takes into account the costs of the links
when computing the secondary path.

Any change in link SRLG information triggers the IGP to send LSP updates for the new
link SRLG information. CSPF recomputes the paths during the next round of reoptimization.

Junos OS Release 11.4 and later supports SRLG based on the following RFCs:

• RFC 4203, OSPF Extensions in Support of Generalized Multi-Protocol Label Switching

(GMPLS).

• RFC 5307, IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching

(GMPLS).

NOTE: Currently, the “Fate Sharing” feature continues to be supported with

the SRLG feature.

Related • Example: Configuring SRLG on page 76

Documentation
• Example: Excluding SRLG Links Completely for the Secondary LSP on page 85

• Example: Configuring SRLG With Link Protection on page 90

36 Copyright © 2012, Juniper Networks, Inc.

 Chapter 3: MPLS Overview

• Example: Configuring SRLG With Link Protection With the exclude-srlg Option on
page 110

• Fate Sharing on page 35

IGP Shortcuts

Link-state protocols, such as OSPF and IS-IS, use the SPF algorithm to compute the
shortest-path tree to all nodes in the network. The results of such computations can be
represented by the destination node, next-hop address, and output interface, where the
output interface is a physical interface. LSPs can be used to augment the SPF algorithm,
for the purposes of resolving BGP next hops. On the node performing the calculations,
LSPs appear to be logical interfaces directly connected to remote nodes in the network.
If you configure the IGP to treat LSPs the same as a physical interface and use the LSPs
as a potential output interface, the SPF computation results are represented by the
destination node and output LSP, effectively using the LSP as a shortcut through the
network to the destination.

As an illustration, begin with a typical SPF tree (see Figure 5 on page 37).

Figure 5: Typical SPF Tree, Sourced from Router A

If an LSP connects Router A to Router D and if IGP shortcuts are enabled on Router A,
you might have the SPF tree shown in Figure 6 on page 37.

Figure 6: Modified SPF Tree, Using LSP A–D as a Shortcut

Note that Router D is now reachable through LSP A–D. When computing the shortest
path to reach Router D, Router A has two choices:

• Use IGP path A–B–D.

• Use LSP A–D.

Copyright © 2012, Juniper Networks, Inc. 37

Junos OS 12.1 MPLS Applications Configuration Guide

Router A decides between the two choices by comparing the IGP metrics for path A–B–D
with the LSP metrics for LSP A–D. If the IGP metric is lower, path A–B–D is chosen (Figure
5 on page 37). If the LSP metric is lower, LSP A–D is used (Figure 6 on page 37). If both
metrics are equal, LSP A–D is chosen because LSP paths are preferred over IGP paths.

Note that Routers E and F are also reachable through LSP A–D, because they are
downstream from Router D in the SPF tree.

Assuming that another LSP connects Router A to Router E, you might have the SPF tree
shown in Figure 7 on page 38.

Figure 7: Modified SPF Tree, Using LSP A–D and LSP A–E as Shortcuts

This section discusses the following topics:

• Enabling IGP Shortcuts on page 38

• LSPs Qualified in Shortcut Computations on page 38

• IGP Shortcut Applications on page 39

• IGP Shortcuts and Routing Table on page 39

• IGP Shortcuts and VPNs on page 40

Related • Configuring IS-IS Traffic Engineering Attributes

Documentation
• OSPF Extensions to Support Traffic Engineering

Enabling IGP Shortcuts

IGP shortcuts are supported for both IS-IS and OSPF. A link-state protocol is required
for IGP shortcuts. Shortcuts are disabled by default. For information about enabling IGP
shortcuts for IS-IS and OSPF, see the Junos OS Routing Protocols Configuration Guide. You
can enable IGP shortcuts on a per-router basis; you do not need to enable shortcuts
globally. A router’s shortcut computation does not depend on another router performing
similar computations, and shortcuts performed by other routers are irrelevant.

LSPs Qualified in Shortcut Computations

Not all LSPs are used in IGP shortcuts. Only those LSPs whose egress point (using the
to statement) matches the router ID of the egress node are considered. Other LSPs,

38 Copyright © 2012, Juniper Networks, Inc.

 Chapter 3: MPLS Overview

whose egress point matches the egress node interface address, are ignored in IGP
shortcuts.

There are exceptions, however. If an LSP has an alias egress point (using the install
statement) and it matches certain router IDs, it is included in the shortcut computation
as well. If multiple equal metric LSPs destined to the same router ID exist, traffic can
load-share among them.

IGP Shortcut Applications

You can use shortcuts to engineer traffic traveling toward destination nodes that do not
support MPLS LSPs. For example, in Figure 7 on page 38, traffic traveling toward Router
F enters LSP A–E. You can control traffic between Router A and Router F by manipulating
LSP A–E; you do not need to explicitly set up an LSP between Router A and Router F.

In Figure 8 on page 39, all traffic from Region 1 to Region 2 traverses LSP A–B if IGP
shortcuts are enabled on the ingress router (Router A), permitting aggregation of
interregional traffic into one LSP. To perform traffic engineering on the interregional
traffic, you have to manipulate LSP A-B only, which avoids creating n2 LSPs from all
routers in Region 1 to all routers in Region 2 and allows efficient resource controls on the
backbone network.

Figure 8: IGP Shortcuts

Shortcuts allow you to deploy LSPs into a network in an incremental, hierarchical fashion.
In Figure 9 on page 39, each region can choose to implement traffic engineering LSPs
independently, without requiring cooperation from other regions. Each region can choose
to deploy intraregion LSPs to fit the region’s bandwidth needs, at the pace appropriate
for the region.

Figure 9: IGP Shortcuts in a Bigger Network

When intraregion LSPs are in place, interregional traffic automatically traverses the
intraregion LSPs as needed, eliminating the need for a full mesh of LSPs between edge
routers. For example, traffic from Router A to Router D traverses LSPs A–B, B–C, and
C–D.

IGP Shortcuts and Routing Table

IGP typically performs two independent computations. The first is performed without
considering any LSP. The result of the computation is stored in the inet.0 table. This step

Copyright © 2012, Juniper Networks, Inc. 39

Junos OS 12.1 MPLS Applications Configuration Guide

is no different from traditional SPF computations and is always performed even if IGP
shortcut is disabled.

The second computation is performed considering only LSPs as a logical interface. Each
LSP’s egress router is considered. The list of destinations whose shortest path traverses
the egress router (established during the first computation) is placed in the inet.3 routing
table. These destinations are given the egress router of the LSP as a next hop, enabling
BGP on the local router to use these LSPs to access BGP next hops beyond the egress
router. Normally, BGP can use only LSPs that terminate at the BGP next hop. Note that
BGP is the only protocol that uses the inet.3 routing table. Other protocols will not route
traffic through these LSPs.

If traffic engineering for IGP and BGP is enabled (see “IGP and BGP Destinations” on
page 44), IGP moves all routes in inet.3 into inet.0, merging all routes while emptying the
inet.3 table. The number of routes in inet.0 will be exactly the same as before. Route
next-hops can traverse a physical interface, an LSP, or the combination of the two if the
metrics are equal.

IGP shortcuts are enabled on a per-node basis. You do not need to coordinate with
other nodes.

IGP Shortcuts and VPNs

You can configure IGP shortcuts for either IS-IS or OSPF. IGP shortcuts allow the IGP to
use an LSP as the next hop instead of the IGP route. IGP shortcuts can also be enabled
for VPNs by also specifying the bgp-igp-both-ribs or mpls-forwarding options for the
traffic-engineering statement at the [edit protocols mpls] hierarchy level. VPNs are
dependant on routes stored in the inet.3 routing table. The bgp-igp option for the
traffic-engineering statement moves all routes from the inet.3 routing table to the inet.0
routing table and is therefore incompatible with VPNs.

Related • Configuring Traffic Engineering for LSPs on page 250

Documentation
• Configuring IS-IS Traffic Engineering Attributes

• OSPF Extensions to Support Traffic Engineering

Advertising LSPs into IGPs

You can configure your IGP to treat an LSP as a link. IGP shortcuts allow only the ingress
router of an LSP to use the LSP in its SPF computation. However, other routers on the
network do not know of the existence of that LSP, so they cannot use it. This can lead
to suboptimal traffic engineering. In addition, only BGP can use an IGP shortcut to an
LSP. When you advertise an LSP as a link into the IGP, all traffic can traverse it, and all
routers know about it.

As an example, consider the network shown in Figure 10 on page 41.

40 Copyright © 2012, Juniper Networks, Inc.

 Chapter 3: MPLS Overview

Figure 10: SPF Computations with Advertised LSPs

Assume that Router A is computing a path to Router D. The link between Router E and
Router F has a metric of 20; all other links have a metric of 10. Here, the path chosen by
Router A is A–B–C–D, which has a metric of 30, instead of A–E–F–D, which has a metric
of 40.

If Router E has an LSP to Router D with a metric of 15, you want traffic from Router A to
Router D to use the path A–E–D, which has a metric of 25, instead of the path A–B–C–D.
However, because Router A does not know about the LSP between Router E and Router D,
it cannot route traffic through this path.

For all routers on the network to know about the LSP between Router E and Router D,
you need to advertise it. This advertisement announces the LSP as a unidirectional,
point-to-point link in the link-state database, and all routers can compute paths using
the LSP. The link-state database maintains information about the AS topology and
contains information about the router’s local state (for example, the router’s usable
interfaces and reachable neighbors). In Figure 10 on page 41, Router A will see the link
from Router E to Router D and route traffic along this lower-metric path.

Because an LSP is announced as a unidirectional link, you might need to configure a

reverse LSP (one that starts at the egress router and ends at the ingress router) so that
the SPF bidirectionality check succeeds. As a step in the SPF computation, IS-IS considers
a link from Router E to Router D. Before IS-IS uses any link, it verifies that there is a link
from Router D to Router E (there is bidirectional connectivity between router E and D).
Otherwise, the SPF computation will not use an announced LSP.

When an LSP is advertised to the IGP, the advertising router uses the LSP as the forwarding
path for regular routes after installing them in the inet.0 routing table. All packets
traversing the router could be forwarded through the LSP. Conversely, IGP shortcuts are
used only to forward packets that are following BGP routes.

NOTE: Do not configure IGP shortcuts and advertise LSPs to the IGP at the
same time.

IP and MPLS Packets on Aggregated Interfaces

You can send IP and MPLS packets over aggregated interfaces. To the IP or MPLS session,
there is a single LSP composed of the aggregated interfaces. Packets sent to an LSP

Copyright © 2012, Juniper Networks, Inc. 41

Junos OS 12.1 MPLS Applications Configuration Guide

that is part of an aggregated interface are redistributed over the aggregated member
interfaces.

Sending IP and MPLS packets over aggregated interfaces has the following benefits:

• Bandwidth aggregation—You can increase the number of MPLS packet flows sent over
each connection. In MPLS, a set of packets sharing the same label is considered a part
of the same flow.

• Link redundancy—If a link or a line card failure affects an aggregate member link, the
traffic flowing across that link is immediately forwarded across one of the remaining
links.

The Junos OS supports aggregated SONET and Ethernet interfaces.

Note that the Junos implementation of IP and MPLS over aggregated interfaces
(aggregated Ethernet devices only) complies with IEEE 802.3ad.

For information about how to configure aggregated Ethernet or aggregated SONET

interfaces, see the Junos OS Network Interfaces Configuration Guide.

MPLS Applications

In the Junos OS implementation of MPLS, establishing an LSP installs on the ingress

router a host route (a 32-bit mask) toward the egress router. The address of the host
route is the destination address of the LSP. By default, the route has a preference value
of 7, a value that is higher than all routes except direct interface and static routes. The
32-bit mask ensures that the route is more specific (that is, a longer match) than all other
subnet routes. The host routes can be used to traffic-engineer BGP destinations only, or
both IGP and BGP destinations.

This section discusses the following topics:

• BGP Destinations on page 42

• IGP and BGP Destinations on page 44

• Selecting a Forwarding LSP Next Hop on page 44

BGP Destinations

You can configure MPLS to control the paths that traffic takes to destinations outside
an AS.

Both IBGP and EBGP take advantage of the LSP host routes without requiring extra
configuration. BGP compares the BGP next-hop address with the LSP host route. If a
match is found, the packets for the BGP route are label-switched over the LSP. If multiple
BGP routes share the same next-hop address, all the BGP routes are mapped to the
same LSP route, regardless of which BGP peer the routes are learned from. If the BGP
next-hop address does not match an LSP host route, BGP routes continue to be forwarded
based on the IGP routes within the routing domain. In general, when both an LSP route

42 Copyright © 2012, Juniper Networks, Inc.

 Chapter 3: MPLS Overview

and an IGP route exist for the same BGP next-hop address, the one with the lowest
preference is chosen.

Figure 11 on page 43 shows an MPLS topology that illustrates how MPLS and LSPs work.
This topology consists of a single domain with four routers. The two routers at the edges
of the domain, Router 1 and Router 4, are running EBGP to communicate with peers
outside the domain and IBGP to communicate between themselves. For intradomain
communication, all four routers are running an IGP. Finally, an LSP tunnel exists from
Router 1 to Router 4.

Figure 11: MPLS Application Topology

When BGP on Router 1 receives prefixes from Router 4, it must determine how to reach
a BGP next-hop address. Typically, when traffic engineering is not enabled, BGP uses
IGP routes to determine how to reach next-hop addresses. (See the left side of Figure 12
on page 44.) However, when traffic engineering is enabled, if the BGP next-hop matches
the LSP tunnel endpoint (that is, the MPLS egress router), those prefixes enter the LSP
tunnel. (To track these prefixes, look at the Active Route field in the show mpls lsp
command output or at the output of the show route label-switched-path path-name
command.) If the BGP next hop does not match an LSP tunnel endpoint, those prefixes
are sent following the IGP’s shortest path. (See Figure 12 on page 44.)

Copyright © 2012, Juniper Networks, Inc. 43

Junos OS 12.1 MPLS Applications Configuration Guide

Figure 12: How BGP Determines How to Reach Next-Hop Addresses

IGP and BGP Destinations

You can configure MPLS to control the paths that traffic takes to destinations within an
AS.

When traffic engineering is for BGP destinations only, the MPLS host routes are installed
in the inet.3 routing table (see Figure 13 on page 45), separate from the routes learned
from other routing protocols. Not all inet.3 routes are downloaded into the forwarding
table. Packets directly addressed to the egress router do not follow the LSP, which
prevents routes learned from LSPs from overriding routes learned from IGPs or other
sources.

Traffic within a domain, including BGP control traffic between BGP peers, is not affected
by LSPs. MPLS affects interdomain traffic only; that is, it affects only those BGP prefixes
that are learned from an external domain. MPLS does not disrupt intradomain traffic, so
IS-IS or OSPF routes remain undisturbed. If you issue a ping or traceroute command to
any destination within the domain, the ping or traceroute packets follow the IGP path.
However, if you issue a ping or traceroute command from Router 1 in Figure 11 on page 43
(the LSP ingress router) to a destination outside of the domain, the packets use the LSP
tunnel.

When traffic engineering for IGP and BGP destinations is enabled, the MPLS host routes
are installed in the inet.0 table (see Figure 14 on page 46) and downloaded into the
forwarding table. Any traffic destined to the egress router could enter the LSP. In effect,
it moves all the routes in inet.3 into inet.0, causing the inet.3 table to be emptied.

RSVP packets automatically avoid all MPLS LSPs, including those established by RSVP
or LDP. This prevents placing one RSVP session into another LSP, or in other words,
nesting one LSP into another.

Selecting a Forwarding LSP Next Hop

If more than one LSP tunnel to a BGP next hop exists, the prefixes learned from the BGP
next hop are randomly divided among the LSP tunnels. To control which LSP BGP uses
to forward data for a given prefix, use the install-nexthop statement in the export policy

44 Copyright © 2012, Juniper Networks, Inc.

 Chapter 3: MPLS Overview

applied to the forwarding table. For more information, see the Junos OS Routing Protocols
Configuration Guide.

MPLS and Routing Tables

The IGPs and BGP store their routing information in the inet.0 routing table, the main IP
routing table. If the traffic-engineering bgp command is configured, thereby allowing only
BGP to use MPLS paths for forwarding traffic, MPLS path information is stored in a
separate routing table, inet.3. Only BGP accesses the inet.3 routing table. BGP uses both
inet.0 and inet.3 to resolve next-hop addresses. If the traffic-engineering bgp-igp command
is configured, thereby allowing the IGPs to use MPLS paths for forwarding traffic, MPLS
path information is stored in the inet.0 routing table. (Figure 13 on page 45 and Figure 14
on page 46 illustrate the routing tables in the two traffic engineering configurations.)

Figure 13: Routing and Forwarding Tables, traffic-engineering bgp

The inet.3 routing table contains the host address of each LSP’s egress router. This routing
table is used on ingress routers to route packets to the destination egress router. BGP
uses the inet.3 routing table on the ingress router to help in resolving next-hop addresses.

MPLS also maintains an MPLS path routing table (mpls.0), which contains a list of the
next label-switched router in each LSP. This routing table is used on transit routers to
route packets to the next router along an LSP.

Typically, the egress router in an LSP does not consult the mpls.0 routing table. (This
router does not need to consult mpls.0 because the penultimate router in the LSP either
changes the packet’s label to a value of 0 or pops the label.) In either case, the egress
router forwards it as an IPv4 packet, consulting the IP routing table, inet.0, to determine
how to forward the packet.

When a transit or egress router receives an MPLS packet, information in the MPLS
forwarding table is used to determine the next transit router in the LSP or to determine
that this router is the egress router.

Copyright © 2012, Juniper Networks, Inc. 45

Junos OS 12.1 MPLS Applications Configuration Guide

When BGP resolves a next-hop prefix, it examines both the inet.0 and inet.3 routing tables,
seeking the next hop with the lowest preference. If it finds a next-hop entry with an equal
preference in both routing tables, BGP prefers the entry in the inet.3 routing table.

Figure 14: Routing and Forwarding Tables, traffic-engineering bgp-igp

Generally, BGP selects next-hop entries in the inet.3 routing table because their
preferences are always lower than OSPF and IS-IS next-hop preferences. When you
configure LSPs, you can override the default preference for MPLS LSPs, which might
alter the next-hop selection process.

When BGP selects a next-hop entry from the inet.3 routing table, it installs that LSP into
the forwarding table in the Packet Forwarding Engine, which causes packets destined
for that next hop to enter and travel along the LSP. If the LSP is removed or fails, the path
is removed from the inet.3 routing table and from the forwarding table, and BGP reverts
to using a next hop from the inet.0 routing table.

MPLS and Traffic Protection

Typically, when an LSP fails, the router immediately upstream from the failure signals
the outage to the ingress router. The ingress router calculates a new path to the egress
router, establishes the new LSP, and then directs the traffic from the failed path to the
new path. This rerouting process can be time-consuming and prone to failure. For example,
the outage signals to the ingress router might get lost, or the new path might take too
long to come up, resulting in significant packet drops. The Junos OS provides several
complementary mechanisms for protecting against LSP failures:

• Standby secondary paths—You can configure primary and secondary paths. You
configure secondary paths with the standby statement. To activate traffic protection,
you need to configure these standby paths only on the ingress router. If the primary
path fails, the ingress router immediately reroutes traffic from the failed path to the
standby path, thereby eliminating the need to calculate a new route and signal a new
path. For information about configuring standby LSPs, see “Configuring Hot Standby
of Secondary Paths” on page 185.

46 Copyright © 2012, Juniper Networks, Inc.

 Chapter 3: MPLS Overview

• Fast reroute—You configure fast reroute on an LSP to minimize the effect of a failure
in the LSP. Fast reroute enables a router upstream from the failure to route around the
failure quickly to the router downstream of the failure. The upstream router then signals
the outage to the ingress router, thereby maintaining connectivity before a new LSP is
established. For a detailed overview of fast reroute, see “Fast Reroute Overview” on
page 47. For information about configuring fast reroute, see “Configuring Fast Reroute”
on page 152.

• Link protection—You can configure link protection to help ensure that traffic traversing
a specific interface from one router to another can continue to reach its destination in
the event that this interface fails. When link protection is configured for an interface
and configured for an LSP that traverses this interface, a bypass LSP is created that
handles this traffic if the interface fails. The bypass LSP uses a different interface and
path to reach the same destination. For information about configuring link protection,
see “Configuring Link Protection on Interfaces Used by LSPs” on page 404.

When standby secondary path, and fast reroute or link protection are configured on an
LSP, full traffic protection is enabled. When a failure occurs in an LSP, the router upstream
from the failure routes traffic around the failure and notifies the ingress router of the
failure. This rerouting keeps the traffic flowing while waiting for the notification to be
processed at the ingress router. After receiving the failure notification, the ingress router
immediately reroutes the traffic from the patched primary path to the more optimal
standby path.

Fast reroute and link protection provide a similar type of traffic protection. Both features
provide a quick transfer service and employ a similar design. Fast reroute and link
protection are both described in RFC 4090, Fast Reroute Extensions to RSVP-TE for LSP
Tunnels. However, you need to configure only one or the other. Although you can configure
both, there is little, if any, benefit in doing so.

Fast Reroute

The following sections provide an overview of how fast reroute works:

• Fast Reroute Overview on page 47

• Detour Merging Process on page 49

• Detour Computations on page 50

• Fast Reroute Path Optimization on page 51

Fast Reroute Overview

Fast reroute provides redundancy for an LSP path. When you enable fast reroute, detours
are precomputed and preestablished along the LSP. In case of a network failure on the
current LSP path, traffic is quickly routed to one of the detours. Figure 15 on page 48
illustrates an LSP from Router A to Router F, showing the established detours. Each
detour is established by an upstream node to avoid the link toward the immediate
downstream node and the immediate downstream node itself. Each detour might traverse
through one or more label-switched routers that are not shown in the figure.

Copyright © 2012, Juniper Networks, Inc. 47

Junos OS 12.1 MPLS Applications Configuration Guide

Fast reroute protects traffic against any single point of failure between the ingress and
egress routers. If there are multiple failures along an LSP, fast reroute itself might fail.
Also, fast reroute does not protect against failure of the ingress or egress routers.

Figure 15: Detours Established for an LSP Using Fast Reroute

If a node detects that a downstream link has failed (using a link-layer-specific liveness
detection mechanism) or that a downstream node has failed (for example, using the
RSVP neighbor hello protocol), the node quickly switches the traffic to the detour and,
at the same time, signals the ingress router about the link or node failure. Figure 16 on
page 48 illustrates the detour taken when the link between Router B and Router C fails.

Figure 16: Detour After the Link from Router B to Router C Fails

If the network topology is not rich enough (there are not enough routers with sufficient
links to other routers), some of the detours might not succeed. For example, the detour
from Router A to Router C in Figure 15 on page 48 cannot traverse link A-B and Router B.
If such a path is not possible, the detour does not occur.

Note that after the node switches traffic to the detour, it might switch the traffic again
to a newly calculated detour soon after. This is because the initial detour route might not
be the best route. To make rerouting as fast as possible, the node switches traffic onto
the initial detour without first verifying that the detour is valid. Once the switch is made,
the node recomputes the detour. If the node determines that the initial detour is still
valid, traffic continues to flow over this detour. If the node determines that the initial
detour is no longer valid, it again switches the traffic to a newly computed detour.

NOTE: If you issue show commands after the node has switched traffic to
the initial detour, the node might indicate that the traffic is still flowing over
the original LSP. This situation is temporary and should correct itself quickly.

48 Copyright © 2012, Juniper Networks, Inc.

 Chapter 3: MPLS Overview

The time required for a fast-rerouting detour to take effect depends on two independent
time intervals:

• Amount of time to detect that there is a link or node failure—This interval depends
greatly on the link layer in use and the nature of the failure. For example, failure detection
on an SONET/SDH link typically is much faster than on a Gigabit Ethernet link, and
both are much faster than detection of a router failure.

• Amount of time required to splice the traffic onto the detour—This operation is
performed by the Packet Forwarding Engine, which requires little time to splice traffic
onto the detour. The time needed can vary depending on the number of LSPs being
switched to detours.

Fast reroute is a short-term patch to reduce packet loss. Because detour computation
might not reserve adequate bandwidth, the detours might introduce congestion on the
alternate links. The ingress router is the only router that is fully aware of LSP policy
constraints and, therefore, is the only router able to come up with adequate long-term
alternate paths.

Detours are created by use of RSVP and, like all RSVP sessions, they require extra state
and overhead in the network. For this reason, each node establishes at most one detour
for each LSP that has fast reroute enabled. Creating more than one detour for each LSP
increases the overhead, but serves no practical purpose.

To reduce network overhead further, each detour attempts to merge back into the LSP
as soon as possible after the failed node or link. If you can consider an LSP that travels
through n router nodes, it is possible to create n – 1 detours. For instance, in Figure 17 on
page 49, the detour tries to merge back into the LSP at Router D instead of at Router E
or Router F. Merging back into the LSP makes the detour scalability problem more
manageable. If topology limitations prevent the detour from quickly merging back into
the LSP, detours merge with other detours automatically.

Figure 17: Detours Merging into Other Detours

Detour Merging Process

This section describes the process used by a router to determine which LSP to select
when the router receives path messages from different interfaces with identical Session
and Sender Template objects. When this occurs, the router needs to merge the path
states.

Copyright © 2012, Juniper Networks, Inc. 49

Junos OS 12.1 MPLS Applications Configuration Guide

The router employs the following process to determine when and how to merge path
states:

• When all the path messages do not include a fast reroute or a detour object, or when
the router is the egress of the LSP, no merging is required. The messages are processed
according to RSVP traffic engineering.

• Otherwise, the router must record the path state in addition to the incoming interface.
If the path messages do not share the same outgoing interface and next-hop router,
the router considers them to be independent LSPs and does not merge them.

• For all the path messages that share the same outgoing interface and next-hop router,
the router uses the following process to select the final LSP:

• If only one LSP originates from this node, select it as the final LSP.

• If only one LSP contains a fast reroute object, select it as the final LSP.

• If there are several LSPs and some of them have a detour object, eliminate those
containing a detour object from the final LSP selection process.

• If several final LSP candidates remain (that is, there are still both detour and protected
LSPs), select the LSPs with fast reroute objects.

• If none of the LSPs have fast reroute objects, select the ones without detour objects.
If all the LSPs have detour objects, select them all.

• Of the remaining LSP candidates, eliminate from consideration those that traverse
nodes that other LSPs avoid.

• If several candidate LSPs still remain, select the one with the shortest explicit route
object (ERO) path length. If more than one LSP has the same path length, select
one randomly.

• Once the final LSP has been identified, the router must transmit only the path messages
that correspond to this LSP. All other LSPs are considered merged at this node.

Detour Computations

Computing and setting up detours is done independently at each node. On a node, if an

LSP has fast reroute enabled and if a downstream link or node can be identified, the
router performs a Constrained Shortest Path First (CSPF) computation using the
information in the local traffic engineering database. For this reason, detours rely on your
IGP supporting traffic engineering extensions. Without the traffic engineering database,
detours cannot be established.

CSPF initially attempts to find a path that skips the next downstream node. Attempting
to find this path provides protection against downstream failures in either nodes or links.
If a node-skipping path is not available, CSPF attempts to find a path on an alternate
link to the next downstream node. Attempting to find an alternate link provides protection
against downstream failures in links only. Detour computations might not succeed the
first time. If a computation fails, the router recomputes detours approximately once every

50 Copyright © 2012, Juniper Networks, Inc.

 Chapter 3: MPLS Overview

refresh interval until the computation succeeds. The RSVP metric for each detour is set
to a value in the range from 10,000 through 19,999.

Fast Reroute Path Optimization

A fast reroute protection path is nondeterministic. The actual protection path of a

particular node depends on the history of the LSP and the network topology when the
fast reroute path was computed. The lack of deterministic behavior can lead to operational
difficulties and poorly optimized paths after multiple link flaps in a network. Even in a
small network, after a few link flaps fast reroute paths can traverse an arbitrarily large
number of nodes and can remain in that state indefinitely. This is inefficient and makes
the network less predictable.

Fast reroute optimization addresses this deficiency. It provides a global path optimization
timer, allowing you to optimize all LSPs that have fast reroute enabled and a detour path
up and running. The timer value can be varied depending on the expected RE processing
load.

The fast reroute optimization algorithm is based on the IGP metric only. As long as the
new path’s IGP metric is lower than the old path’s, the CSPF result is accepted, even if
the new path might be more congested (higher bandwidth utilization) or traverses more
hops.

In conformance with RFC 4090, Fast Reroute Extensions to RSVP-TE for LSP Tunnels,
when a new path is computed and accepted for fast reroute optimization, the existing
detour is destroyed first and then the new detour is established. To prevent traffic loss,
detours actively protecting traffic are not optimized.

Automatic Bandwidth Allocation

Automatic bandwidth allocation allows an MPLS tunnel to automatically adjust its

bandwidth allocation based on the volume of traffic flowing through the tunnel. You can
configure an LSP with minimal bandwidth; this feature can dynamically adjust the LSP’s
bandwidth allocation based on current traffic patterns. The bandwidth adjustments do
not interrupt traffic flow through the tunnel.

You set a sampling interval on an LSP configured with automatic bandwidth allocation.
The average bandwidth is monitored during this interval. At the end of the interval, an
attempt is made to signal a new path for the LSP with the bandwidth allocation set to
the maximum average value for the preceding sampling interval. If the new path is
successfully established and the original path is removed, the LSP is switched over to
the new path. If a new path is not created, the LSP continues to use its current path until
the end of the next sampling interval, when another attempt is made to establish a new
path. Note that you can set minimum and maximum bandwidth values for the LSP.

During the automatic bandwidth allocation interval, the router might receive a steady
increase in traffic (increasing bandwidth utilization) on an LSP, potentially causing
congestion or packet loss. To prevent this, you can define a second trigger to prematurely
expire the automatic bandwidth adjustment timer before the end of the current
adjustment interval.

Copyright © 2012, Juniper Networks, Inc. 51

Junos OS 12.1 MPLS Applications Configuration Guide

Point-to-Multipoint LSPs Overview

A point-to-multipoint MPLS LSP is an LSP with a single source and multiple destinations.
By taking advantage of the MPLS packet replication capability of the network,
point-to-multipoint LSPs avoid unnecessary packet replication at the ingress router.
Packet replication takes place only when packets are forwarded to two or more different
destinations requiring different network paths.

This process is illustrated in Figure 18 on page 52. Router PE1 is configured with a
point-to-multipoint LSP to Routers PE2, PE3, and PE4. When Router PE1 sends a packet
on the point-to-multipoint LSP to Routers P1 and P2, Router P1 replicates the packet and
forwards it to Routers PE2 and PE3. Router P2 sends the packet to Router PE4.

This feature is described in detail in the Internet drafts

draft-raggarwa-mpls-p2mp-te-02.txt (expired February 2004), Establishing Point to
Multipoint MPLS TE LSPs, draft-ietf-mpls-rsvp-te-p2mp-02.txt, Extensions to Resource
Reservation Protocol-Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE
Label-Switched Paths (LSPs), and draft-ietf-mpls-ldp-p2mp-10.txt, Label Distribution
Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched
Paths.

Figure 18: Point-to-Multipoint LSPs

52 Copyright © 2012, Juniper Networks, Inc.

 Chapter 3: MPLS Overview

The following are some of the properties of point-to-multipoint LSPs:

• A point-to-multipoint LSP enables you to use MPLS for point-to-multipoint data

distribution. This functionality is similar to that provided by IP multicast.

• You can add and remove branch LSPs from a main point-to-multipoint LSP without
disrupting traffic. The unaffected parts of the point-to-multipoint LSP continue to
function normally.

• You can configure a node to be both a transit and an egress router for different branch
LSPs of the same point-to-multipoint LSP.

• You can enable link protection on a point-to-multipoint LSP. Link protection can provide
a bypass LSP for each of the branch LSPs that make up the point-to-multipoint LSP.
If any of the primary paths fail, traffic can be quickly switched to the bypass.

• You can configure branch LSPs either statically, dynamically, or as a combination of

static and dynamic LSPs.

• You can enable graceful Routing Engine switchover (GRES) and graceful restart for
point-to-multipoint LSPs at ingress and egress routers. The point-to-multipoint LSPs
must be configured using either static routes or circuit cross-connect (CCC). GRES and
graceful restart allow the traffic to be forwarded at the Packet Forwarding Engine
based on the old state while the control plane recovers. Feature parity for GRES and
graceful restart for MPLS point-to-multipoint LSPs on the Junos Trio chipset is
supported in Junos OS Releases 11.1R2, 11.2R2, and 11.4.

Related • Junos OS High Availability Configuration Guide

Documentation
• Example: Configuring an RSVP-Signaled Point-to-Multipoint LSP on Logical Systems

• Example: NG-VPLS Using Point-to-Multipoint LSPs

• Example: Configuring Point-to-Multipoint LDP LSPs as the Data Plane for Intra-AS
MBGP MVPNs

Copyright © 2012, Juniper Networks, Inc. 53

Junos OS 12.1 MPLS Applications Configuration Guide

54 Copyright © 2012, Juniper Networks, Inc.

CHAPTER 4

MPLS Router Configuration Guidelines

This chapter discusses the following topics:

• Minimum MPLS Configuration on page 55

• Configuring the Ingress Router for MPLS-Signaled LSPs on page 56
• Example: Configuring a Constrained-Path LSP for Which Junos OS Makes All Forwarding
Decisions on page 60
• Example: Configuring an Explicit-Path LSP on page 61
• Example: Configuring a Constrained-Path LSP for Which Junos OS Makes Most
Forwarding Decisions and Considers Hop Constraints on page 62
• Example: Configuring a Constrained-Path LSP for Which Junos OS Makes Most
Forwarding Decisions and the Secondary Path Is Explicit on page 62
• Configuring the Intermediate and Egress Routers for MPLS-Signaled LSPs on page 63
• Improving Traffic Engineering Database Accuracy with RSVP PathErr
Messages on page 63
• Configuring MPLS-Signaled LSPs to Use GRE Tunnels on page 66
• Example: Tunneling IPv6 Traffic over MPLS IPv4 Networks on page 67
• Configuring ICMP Message Tunneling for MPLS on page 76
• Example: Configuring SRLG on page 76
• Example: Excluding SRLG Links Completely for the Secondary LSP on page 85
• Example: Configuring SRLG With Link Protection on page 90
• Example: Configuring SRLG With Link Protection With the exclude-srlg
Option on page 110
• Configuring the MPLS Transport Profile for OAM on page 129

Minimum MPLS Configuration

To enable MPLS on the router, you must include at least the following statements. This
minimum configuration enables MPLS on a logical interface. All other MPLS configuration
statements are optional. Note that this configuration does nothing more than enable
MPLS on the router and on the specified interface.

Include the family mpls statement:

Copyright © 2012, Juniper Networks, Inc. 55

Junos OS 12.1 MPLS Applications Configuration Guide

family mpls;

You can include this statement at the following hierarchy levels:

• [edit interfaces interface-name unit logical-unit-number]

• [edit logical-systems logical-system-name interfaces interface-name unit

logical-unit-number]

Include the interface in the MPLS and RSVP protocol configuration:

mpls {
interface (interface-name | all); # Required to enable MPLS on the interface
}
rsvp { # Required for RSVP-signaled MPLS only
interface interface-name;
}

You can configure these statements at the following hierarchy levels:

• [edit protocols]

• [edit logical-systems logical-system-name protocols]

For every interface you enable, two special routes are installed automatically in the MPLS
forwarding table. One route has a label value of 0, and the second has a label value of
1. (For information about these labels, see “Special Labels” on page 28.)

Configuring the Ingress Router for MPLS-Signaled LSPs

MPLS-signaled label-switched paths (LSPs) run from a specific ingress router to a specific
egress router. For basic MPLS-signaled LSP function, you must configure the ingress
router, but do not have to configure any other routers.

To configure signaled LSPs, perform the following tasks on the ingress router:

• Creating Named Paths on page 56

• Configuring Alternate Backup Paths Using Fate Sharing on page 58

Creating Named Paths

To configure signaled LSPs, you must first create one or more named paths on the ingress
router. For each path, you can specify some or all transit routers in the path, or you can
leave it empty.

Each pathname can contain up to 32 characters and can include letters, digits, periods,
and hyphens. The name must be unique within the ingress router. Once a named path is
created, you can use the named path with the primary or secondary statement to configure
LSPs at the [edit protocols mpls label-switched-path label-path-name] hierarchy level.
You can specify the same named path on any number of LSPs.

To determine whether an LSP is associated with the primary or secondary path in an

RSVP session, issue the show rsvp session detail command. For more information, see
the Junos OS Routing Protocols and Policies Command Reference.

56 Copyright © 2012, Juniper Networks, Inc.

 Chapter 4: MPLS Router Configuration Guidelines

To create an empty path, create a named path by including the following form of the
path statement. This form of the path statement is empty, which means that any path
between the ingress and egress routers is accepted. In actuality, the path used tends to
be the same path as is followed by destination-based, best-effort traffic.

path path-name;

You can include this statement at the following hierarchy levels:

• [edit protocols mpls]

• [edit logical-systems logical-system-name protocols mpls]

To create a path in which you specify some or all transit routers in the path, include the
following form of the path statement, specifying one address for each transit router:

path path-name {
(address | hostname) <strict | loose>;
}

You can include this statement at the following hierarchy levels:

• [edit protocols mpls]

• [edit logical-systems logical-system-name protocols mpls]

In this form of the path statement, you specify one or more transit router addresses.
Specifying the ingress or egress routers is optional. You can specify the address or
hostname of each transit router, although you do not need to list each transit router if its
type is loose. Specify the addresses in order, starting with the ingress router (optional)
or the first transit router, and continuing sequentially along the path up to the egress
router (optional) or the router immediately before the egress router. You need to specify
only one address per router hop. If you specify more than one address for the same router,
only the first address is used; the additional addresses are ignored and truncated.

For each router address, you specify the type, which can be one of the following:

• strict—(Default) The route taken from the previous router to this router is a direct path
and cannot include any other routers. If address is an interface address, this router also
ensures that the incoming interface is the one specified. Ensuring that the incoming
interface is the one specified is important when there are parallel links between the
previous router and this router. It also ensures that routing can be enforced on a per-link
basis.

For strict addresses, you must ensure that the router immediately preceding the router
you are configuring has a direct connection to that router. The address can be a loopback
interface address, in which case the incoming interface is not checked.

• loose—The route taken from the previous router to this router need not be a direct path,
can include other routers, and can be received on any interface. The address can be
any interface address or the address of the loopback interface.

Copyright © 2012, Juniper Networks, Inc. 57

Junos OS 12.1 MPLS Applications Configuration Guide

Examples: Creating Named Paths

Configure a path, to-hastings, to specify the complete strict path from the ingress to the
egress routers through 14.1.1.1, 13.1.1.1, 12.1.1.1, and 11.1.1.1, in that order. There cannot be any
intermediate routers except the ones specified. However, there can be intermediate
routers between 11.1.1.1 and the egress router because the egress router is not specifically
listed in the path statement. To prevent intermediate routers before egress, configure
the egress router as the last router, with a strict type.

[edit protocols mpls]

path to-hastings {
14.1.1.1 strict;
13.1.1.1 strict;
12.1.1.1 strict;
11.1.1.1 strict;
}

Create a path, alt-hastings, to allow any number of intermediate routers between routers
14.1.1.1 and 11.1.1.1. In addition, intermediate routers are permitted between 11.1.1.1 and the
egress router.

[edit protocols mpls]

path alt-hastings {
14.1.1.1 strict;
11.1.1.1 loose;
}

Configuring Alternate Backup Paths Using Fate Sharing

You can create a database of information that Constrained Shortest Path First (CSPF)
uses to compute one or more backup paths in case the primary path becomes unstable.
The database describes the relationships between elements of the network, such as
routers and links. Because these network elements share the same fate, this relationship
is called fate sharing.

You can configure backup paths that minimize the number of shared links and fiber paths
with the primary paths as much as possible to ensure that, if a fiber is cut, the minimum
amount of data is lost and a path still exists to the destination.

For a backup path to work optimally, it must not share links or physical fiber paths with
the primary path. This ensures that a single point of failure will not affect the primary
and backup paths at the same time.

The following sections describe how to configure fate sharing and how it affects CSPF,
and provides a fate sharing configuration example:

• Configuring Fate Sharing on page 58

• Implications for CSPF on page 60
• Example: Configuring Fate Sharing on page 60

Configuring Fate Sharing

To configure fate sharing, include the fate-sharing statement:

58 Copyright © 2012, Juniper Networks, Inc.

 Chapter 4: MPLS Router Configuration Guidelines

fate-sharing {
group group-name {
cost value;
from address <to address>;
}
}

For a list of hierarchy levels at which you can include this statement, see the statement
summary section for this statement.

Each fate-sharing group must have a name, which can be up to 32 characters long and
can contain letters, digits, periods (.) and hyphens (-). You can define up to 512 groups.

Fate-sharing groups contain three types of objects:

• Point-to-point links—Identified by the IP addresses at each end of the link. Unnumbered

point-to-point links are typically identified by borrowing IP addresses from other
interfaces. Order is not important; from 1.2.3.4 to 1.2.3.5 and from 1.2.3.5 to 1.2.3.4 have
the same meaning.

• Non-point-to-point links—Include links on a LAN interface (such as Gigabit Ethernet

interfaces) or nonbroadcast multiaccess (NBMA) interfaces (such as Asynchronous
Transfer Mode [ATM] or Frame Relay). You identify these links by their individual
interface address. For example, if the LAN interface 192.168.200.0/24 has four routers
attached to it, each router link is individually identified:

from 192.168.200.1; # LAN interface of router 1

from 192.168.200.2; # LAN interface of router 2
from 192.168.200.3; # LAN interface of router 3
from 192.168.200.4; # LAN interface of router 4

You can list the addresses in any order.

• A router node—Identified by its configured router ID.

All objects in a group share certain similarities. For example, you can define a group for
all fibers that share the same fiber conduit, all optical channels that share the same fiber,
all links that connect to the same LAN switch, all equipment that shares the same power
source, and so on. All objects are treated as /32 host addresses.

For a group to be meaningful, it should contain at least two objects. You can configure
groups with zero or one object; these groups are ignored during processing.

An object can be in any number of groups, and a group can contain any number of objects.
Each group has a configurable cost attributed to it, which represents the level of impact
this group has on CSPF computations. The higher the cost, the less likely a backup path
will share with the primary path any objects in the group. The cost is directly comparable
to traffic engineering metrics. By default, the cost is 1. Changing the fate-sharing database
does not affect established LSPs until the next reoptimization of CSPF. The fate-sharing
database does influence fast-reroute computations.

Copyright © 2012, Juniper Networks, Inc. 59

Junos OS 12.1 MPLS Applications Configuration Guide

Implications for CSPF

When CSPF computes the primary paths of an LSP (or secondary paths when the primary
path is not active), it ignores the fate-sharing information. You always want to find the
best possible path (least IGP cost) for the primary path.

When CSPF computes a secondary path while the primary path (of the same LSP) is
active, the following occurs:

1. CSPF identifies all fate-sharing groups that are associated with the primary path.
CSPF does this by identifying all links and nodes that the primary path traverses and
compiling group lists that contain at least one of the links or nodes. CSPF ignores the
ingress and egress nodes in the search.

2. CSPF checks each link in the traffic engineering database against the compiled group
list. If the link is a member of a group, the cost of the link is increased by the cost of
the group. If a link is a member of multiple groups, all group costs are added together.

3. CSPF performs the check for every node in the traffic engineering database, except
the ingress and egress node. Again, a node can belong to multiple groups, so costs
are additive.

4. The router performs regular CSPF computation with the adjusted topology.

Example: Configuring Fate Sharing

Configure fate-sharing groups east and west. Because west has no objects, it is ignored
during processing.

[edit routing-options]
fate-sharing {
group east {
cost 20; # Optional, default value is 1
from 1.2.3.4 to 1.2.3.5; # A point-to-point link
from 192.168.200.1; # LAN interface
from 192.168.200.2; # LAN interface
from 192.168.200.3; # LAN interface
from 192.168.200.4; # LAN interface
from 10.168.1.220; # Router ID of a router node
from 10.168.1.221; # Router ID of a router node
}
group west {
.....
}
}

Example: Configuring a Constrained-Path LSP for Which Junos OS Makes All Forwarding
Decisions

On the ingress router, create a constrained-path LSP in which the Junos OS makes all
the forwarding decisions. When the LSP is successfully set up, a route toward 10.1.1.1/32
is installed in the inet.3 table so that all BGP routes with matching BGP next-hop addresses
can be forwarded through the LSP.

60 Copyright © 2012, Juniper Networks, Inc.

 Chapter 4: MPLS Router Configuration Guidelines

[edit]
interfaces {
so-0/0/0 {
unit 0 {
family mpls;
}
}
}
protocols {
rsvp {
interface so-0/0/0;
}
mpls {
label-switched-path to-hastings {
to 10.1.1.1;
}
interface so-0/0/0;
}
}

Example: Configuring an Explicit-Path LSP

On the ingress router, create an explicit-path LSP, and specify the transit routers between
the ingress and egress routers. In this configuration, no constrained-path computation
is performed. For the primary path, all intermediate hops are strictly specified so that its
route cannot change. The secondary path must travel through router 14.1.1.1 first, then
take whatever route is available to reach the destination. The remaining route taken by
the secondary path is typically the shortest path computed by the IGP.

[edit]
interfaces {
so-0/0/0 {
unit 0 {
family mpls;
}
}
}
protocols {
rsvp {
interface so-0/0/0;
}
mpls {
path to-hastings {
14.1.1.1 strict;
13.1.1.1 strict;
12.1.1.1 strict;
11.1.1.1 strict;
}
path alt-hastings {
14.1.1.1 strict;
11.1.1.1 loose; # Any IGP route is acceptable
}
label-switched-path hastings {
to 11.1.1.1;
hop-limit 32;

Copyright © 2012, Juniper Networks, Inc. 61

Junos OS 12.1 MPLS Applications Configuration Guide

bandwidth 10m; # Reserve 10 Mbps

no-cspf; # do not perform constrained-path computation
primary to-hastings;
secondary alt-hastings;
}
interface so-0/0/0;
}
}

Example: Configuring a Constrained-Path LSP for Which Junos OS Makes Most

Forwarding Decisions and Considers Hop Constraints

On the ingress router, create a constrained-path LSP in which the Junos OS makes most
of the forwarding decisions, taking into account the hop constraints listed in the path
statements. The LSP is adaptive so that no bandwidth double-counting occurs on links
shared by primary and secondary paths. To acquire the necessary link bandwidth, this
LSP is allowed to preempt lower priority sessions. Finally, this path always keeps the
secondary path in hot-standby state for quick failover.

[edit protocols]
mpls {
path to-hastings {
14.1.1.1 loose;
}
path alt-hastings {
12.1.1.1 loose;
11.1.1.1 strict;
}
label-switched-path hastings {
to 11.1.1.1;
bandwidth 10m; # Reserve 10 Mbps
priority 0 0; # Preemptive, but not preemptable
adaptive; # Set adaptivity
primary to-hastings;
secondary alt-hastings {
standby;
bandwidth 1m; # Reserve only 1 Mbps for the secondary path
}
}
interface all;
}

Example: Configuring a Constrained-Path LSP for Which Junos OS Makes Most

Forwarding Decisions and the Secondary Path Is Explicit

On the ingress router, create a constrained-path LSP in which the Junos OS makes most
of the forwarding decisions for the primary path, subject to constraints of the path
to-hastings, and in which the secondary path is an explicit path. The primary path must
transit green or yellow links and must stay away from red links. The primary path is
periodically recomputed and reoptimized. Finally, this path always keeps the secondary
path in hot-standby state for quick failover.

62 Copyright © 2012, Juniper Networks, Inc.

 Chapter 4: MPLS Router Configuration Guidelines

When the LSP is up—either because the primary or secondary path is up, or because both
paths are up—the prefix 16.0.0.0/8 is installed in the inet.3 table so that all BGP routes
whose BGP next hop falls within that range can use the LSP. Also, the prefix 17/8 is
installed in the inet.0 table so that BGP can resolve only its next hop through that prefix.
The route also can be reached with the traceroute or ping command. These two routes
are in addition to the 11.1.1.1/32 route.

[edit protocols]
mpls {
admin-groups {
green 1;
yellow 2;
red 3;
}
path to-hastings {
14.1.1.1 loose;
}
path alt-hastings {
14.1.1.1 strict;
13.1.1.1 strict;
12.1.1.1 strict;
11.1.1.1 strict;
}
label-switched-path hastings {
to 11.1.1.1;
bandwidth 100m;
install 16.0.0.0/8; # in inet.3; cannot use to traceroute or ping
install 17.0.0.0/8 active; # installed in inet.0; can use to traceroute or ping
primary to-hastings {
admin-group { # further constraints for path computation
include-all [ green yellow ];
exclude red;
}
optimize-timer 3600; # reoptimize every hour
}
secondary alt-hastings {
standby;
no-cspf; # do not perform constrained-path computation
}
}
interface all;

Configuring the Intermediate and Egress Routers for MPLS-Signaled LSPs

To configure signaled LSPs on all MPLS routers that should participate in MPLS, you
need to enable MPLS and RSVP on these routers, as described in “Minimum MPLS
Configuration” on page 55 and “Minimum RSVP Configuration” on page 393.

Improving Traffic Engineering Database Accuracy with RSVP PathErr Messages

An essential element of RSVP-based traffic engineering is the traffic engineering database.

The traffic engineering database contains a complete list of all network nodes and links
participating in traffic engineering, and a set of attributes each of those links can hold.

Copyright © 2012, Juniper Networks, Inc. 63

Junos OS 12.1 MPLS Applications Configuration Guide

(For more information about the traffic engineering database, see “Constrained-Path
LSP Computation” on page 32.) One of the most important link attributes is bandwidth.

Bandwidth availability on links changes quickly as RSVP LSPs are established and
terminated. It is likely that the traffic engineering database will develop inconsistencies
relative to the real network. These inconsistencies cannot be fixed by increasing the rate
of IGP updates.

Link availability can share the same inconsistency problem. A link that becomes
unavailable can break all existing RSVP LSPs. However, its unavailability might not readily
be known by the network.

When you configure the rsvp-error-hold-time statement, a source node (ingress of an

RSVP LSP) learns from the failures of its LSP by monitoring PathErr messages transmitted
from downstream nodes. Information from the PathErr messages is incorporated into
subsequent LSP computations, which can improve the accuracy and speed of LSP setup.
Some PathErr messages are also used to update traffic engineering database bandwidth
information, reducing inconsistencies between the traffic engineering database and the
network.

You can control the frequency of IGP updates by using the update-threshold statement.
See “Configuring the RSVP Update Threshold on an Interface” on page 399.

This section discusses the following topics:

• PathErr Messages on page 64

• Identifying the Problem Link on page 65
• Configuring the Router to Improve Traffic Engineering Database Accuracy on page 65

PathErr Messages
PathErr messages report a wide variety of problems by means of different code and
subcode numbers. You can find a complete list of these PathErr messages in RFC 2205,
Resource Reservation Protocol (RSVP), Version 1, Functional Specification and RFC 3209,
RSVP-TE: Extensions to RSVP for LSP Tunnels.

When you configure the rsvp-error-hold-time statement, two categories of PathErr

messages, which specifically represent link failures, are examined:

• Link bandwidth is low for this LSP: Requested bandwidth unavailable—code 1, subcode
2

This type of PathErr message represents a global problem that affects all LSPs
transiting the link. They indicate that the actual link bandwidth is lower than that
required by the LSP, and that it is likely that the bandwidth information in the traffic
engineering database is an overestimate.

When this type of error is received, the available link bandwidth is reduced in the local
traffic engineering database, affecting all future LSP computations.

• Link unavailable for this LSP:

64 Copyright © 2012, Juniper Networks, Inc.

 Chapter 4: MPLS Router Configuration Guidelines

• Admission Control failure—code 1, any subcode except 2

• Policy Control failures—code 2

• Service Preempted—code 12

• Routing problem—no route available toward destination—code 24, subcode 5

These types of PathErr messages are generally pertinent to the specified LSP. The
failure of this LSP does not necessarily imply that other LSPs could also fail. These
errors can indicate maximum transfer unit (MTU) problems, service preemption (either
manually initiated by the operator or by another LSP with a higher priority), that a
next-hop link is down, that a next-hop neighbor is down, or service rejection because
of policy considerations. It is best to route this particular LSP away from the link.

Identifying the Problem Link

Each PathErr message includes the sender’s IP address. This information is propagated
unchanged toward the ingress router. A lookup in the traffic engineering database can
identify the node that originated the PathErr message.

Each PathErr message carries enough information to identify the RSVP session that
triggered the message. If this is a transit router, it simply forwards the message. If this
router is the ingress router (for this RSVP session), it has the complete list of all nodes
and links the session should traverse. Coupled with the originating node information, the
link can be uniquely identified.

Configuring the Router to Improve Traffic Engineering Database Accuracy

To improve the accuracy of the traffic engineering database, configure the
rsvp-error-hold-time statement. When this statement is configured, a source node (ingress
of an RSVP LSP) learns from the failures of its LSP by monitoring PathErr messages
transmitted from downstream nodes. Information from the PathErr messages is
incorporated into subsequent LSP computations, which can improve the accuracy and
speed of LSP setup. Some PathErr messages also are used to update traffic engineering
database bandwidth information, reducing inconsistencies between the traffic engineering
database and the network.

To configure how long MPLS should remember RSVP PathErr messages and consider
them in CSPF computation, include the rsvp-error-hold-time statement:

rsvp-error-hold-time seconds;

You can include this statement at the following hierarchy levels:

• [edit protocols mpls]

• [edit logical-systems logical-system-name protocols mpls]

The time can be a value from 1 to 240 seconds. The default is 25 seconds. Configuring a
value of 0 disables the monitoring of PathErr messages.

Copyright © 2012, Juniper Networks, Inc. 65

Junos OS 12.1 MPLS Applications Configuration Guide

Configuring MPLS-Signaled LSPs to Use GRE Tunnels

MPLS LSPs can use generic routing encapsulation (GRE) tunnels to cross routing areas,
autonomous systems, and ISPs. Bridging MPLS LSPs over an intervening IP domain is
possible without disrupting the outlying MPLS domain.

LSPs can reach any destination that the GRE tunnels can reach. MPLS applications can
be deployed without requiring all transit nodes to support MPLS, or requiring all transit
nodes to support the same label distribution protocols (LDP or RSVP). If you use CSPF,
you must configure OSPF or IS-IS through the GRE tunnel. Traffic engineering is not
supported over GRE tunnels; for example, you cannot reserve bandwidth or set priority
or preemption.

NOTE: Use the no-control word statement to disable the control word when
the topology uses GRE as the connection mechanism between provider edge
routers and one of the provider edge routers is an M Series Multiservice Edge
Router.

For more information about GRE tunnels, see the Junos OS Services Interfaces Configuration
Guide.

Example: Configuring MPLS-Signaled LSPs to Use GRE Tunnels

To configure MPLS over GRE tunnels:

1. Enable family mpls under the GRE interface configuration:

[edit interfaces]
interface gr-1/2/0 {
unit 0 {
tunnel {
source 192.168.1.1;
destination 192.168.1.2;
}
family inet {
address 5.1.1.1/30;
}
family iso;
family mpls;
}
}

2. Enable RSVP and MPLS over the GRE tunnel:

[edit protocols]
rsvp {
interface gr-1/2/0.0;
}
mpls {
...
interface gr-1/2/0.0;
}

66 Copyright © 2012, Juniper Networks, Inc.

 Chapter 4: MPLS Router Configuration Guidelines

3. Configure LSPs to travel through the GRE tunnel endpoint address:

[edit protocols]
mpls {
label-switched-path gre-tunnel {
to 5.1.1.2;
...
}
}

Standard LSP configuration options apply. If the routing table specifies that a particular
route will traverse a GRE tunnel, the RSVP packets will traverse the tunnel as well.

Example: Tunneling IPv6 Traffic over MPLS IPv4 Networks

This example shows how to configure the Junos OS to tunnel IPv6 over an MPLS-based
IPv4 network. External BGP (EBGP) is used between the customer edge (CE) and provider
edge (PE) devices. The remote CE devices have different AS numbers for loop detection.

• Requirements on page 67
• Overview on page 67
• Configuration on page 70
• Verification on page 75

Requirements
No special configuration beyond device initialization is required before you configure this
example.

Overview
Detailed information about the Juniper Networks implementation of IPv6 over MPLS is
described in the following Internet drafts:

• Internet draft draft-ietf-l3vpn-bgp-ipv6-07.txt, BGP-MPLS IP VPN extension for IPv6

VPN (expires January 2006)

• Internet draft draft-ooms-v6ops-bgp-tunnel-06.txt, Connecting IPv6 Islands over IPv4

MPLS using IPv6 Provider Edge Routers (expires July 2006)

These Internet drafts are available on the IETF website at http://www.ietf.org/.

This example shows you how to interconnect a two IPv6 networks over an IPv4-based
network core, giving you the ability to provide IPv6 service without having to upgrade the
routers in your core network. Multiprotocol Border Gateway Protocol (MP-BGP) is
configured to exchange routes between the IPv6 networks, and data is tunneled between
these IPv6 networks by means of IPv4-based MPLS.

In Figure 19 on page 68, Routers PE1 and PE2 are dual-stack BGP routers, meaning they
have both IPv4 and IPv6 stacks. The PE routers link the IPv6 networks through the
customer edge (CE) routers to the IPv4 core network. The CE routers and the PE routers
connect through a link layer that can carry IPv6 traffic. The PE routers use IPv6 on the

Copyright © 2012, Juniper Networks, Inc. 67

Junos OS 12.1 MPLS Applications Configuration Guide

CE router-facing interfaces and use IPv4 and MPLS on the core-facing interfaces. Note
that one of the connected IPv6 networks could be the global IPv6 Internet.

Figure 19: IPv6 Networks Linked by MPLS IPv4 Tunnels

The two PE routers are linked through an MP-BGP session using IPv4 addresses. They
use the session to exchange IPv6 routes with an IPv6 (value 2) address family indicator
(AFI) and a subsequent AFI (SAFI) (value 4). Each PE router sets the next hop for the
IPv6 routes advertised on this session to its own IPv4 address. Because MP-BGP requires
the BGP next hop to correspond to the same address family as the network layer
reachability information (NLRI), this IPv4 address needs to be embedded within an IPv6
format.

The PE routers can learn the IPv6 routes from the CE routers connected to them using
routing protocols Routing Information Protocol next generation (RIPng) or MP-BGP, or
through static configuration. Note that if BGP is used as the PE-router-to-CE-router
protocol, the MP-BGP session between the PE router and CE router could occur over an
IPv4 or IPv6 Transmission Control Protocol (TCP) session. Also, the BGP routes exchanged
on that session would have SAFI unicast. You must configure an export policy to pass
routes between IBGP and EBGP, and between BGP and any other protocol.

The PE routers have MPLS LSPs routed to each others’ IPv4 addresses. IPv4 provides
signaling for the LSPs by means of either LDP or RSVP. These LSPs are used to resolve
the next-hop addresses of the IPv6 routes learned from MP-BGP. The next hops use
IPv4-mapped IPv6 addresses, while the LSPs use IPv4 addresses.

The PE routers always advertise IPv6 routes to each other using a label value of 2, the
explicit null label for IPv6 as defined in RFC 3032, MPLS Label Stack Encoding. As a
consequence, each of the forwarding next hops for the IPv6 routes learned from remote
PE routers normally push two labels. The inner label is 2 (this label could be different if
the advertising PE router is not a Juniper Networks routing platform), and the outer label
is the LSP label. If the LSP is a single-hop LSP, then only Label 2 is pushed.

68 Copyright © 2012, Juniper Networks, Inc.

 Chapter 4: MPLS Router Configuration Guidelines

It is also possible for the PE routers to exchange plain IPv6 routes using SAFI unicast.
However, there is one major advantage in exchanging labeled IPv6 routes. The
penultimate-hop router for an MPLS LSP can pop the outer label and then send the
packet with the inner label as an MPLS packet. Without the inner label, the
penultimate-hop router would need to discover whether the packet is an IPv4 or IPv6
packet to set the protocol field in the Layer 2 header correctly.

When the PE1 router in Figure 19 on page 68 receives an IPv6 packet from the CE1 router,
it performs a lookup in the IPv6 forwarding table. If the destination matches a prefix
learned from the CE2 router, then no labels need to be pushed and the packet is simply
sent to the CE2 router. If the destination matches a prefix that was learned from the PE2
router, then the PE1 router pushes two labels onto the packet and sends it to the provider
router. The inner label is 2 and the outer label is the LSP label for the PE2 router.

Each provider router in the service provider’s network handles the packet as it would any
MPLS packet, swapping labels as it passes from provider router to provider router. The
penultimate-hop provider router for the LSP pops the outer label and sends the packet
to the PE2 router. When the PE2 router receives the packet, it recognizes the IPv6 explicit
null label on the packet (Label 2). It pops this label and treats it as an IPv6 packet,
performing a lookup in the IPv6 forwarding table and forwarding the packet to the CE3
router.

This example includes the following settings:

• In addition to configuring the family inet6 statement on all the CE router–facing

interfaces, you must also configure the statement on all the core-facing interfaces
running MPLS. Both configurations are necessary because the router must be able to
process any IPv6 packets it receives on these interfaces. You should not see any regular
IPv6 traffic arrive on these interfaces, but you will receive MPLS packets tagged with
Label 2. Even though Label 2 MPLS packets are sent in IPv4, these packets are treated
as native IPv6 packets.

• You enable IPv6 tunneling by including the ipv6-tunneling statement in the configuration
for the PE routers. This statement allows IPv6 routes to be resolved over an MPLS
network by converting all routes stored in the inet.3 routing table to IPv4-mapped IPv6
addresses and then copying them into the inet6.3 routing table. This routing table can
be used to resolve next hops for both inet6 and inet6-vpn routes.

NOTE: BGP automatically runs its import policy even when copying routes
from a primary routing table group to a secondary routing table group. If
IPv4 labeled routes arrive from a BGP session (for example, when you have
configured the labeled-unicast statement at the [edit protocols bgp family
inet] hierarchy level on the PE router), the BGP neighbor’s import policy
also accepts IPv6 routes, since the neighbor’s import policy is run while
doing the copy operation to the inet6.3 routing table.

• When you configure MP-BGP to carry IPv6 traffic, the IPv4 MPLS label is removed at
the destination PE router. The remaining IPv6 packet without a label can then be

Copyright © 2012, Juniper Networks, Inc. 69

Junos OS 12.1 MPLS Applications Configuration Guide

forwarded to the IPv6 network. To enable this, nclude the explicit-null statement in
the BGP configuration.

Configuration
CLI Quick To quickly configure this example, copy the following commands, paste them into a text
Configuration file, remove any line breaks, change any details necessary to match your network
configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy
level.

Device PE1 set interfaces fe-1/2/0 unit 2 family inet6 address ::10.1.1.2/126
set interfaces fe-1/2/0 unit 2 family mpls
set interfaces fe-1/2/1 unit 5 family inet address 10.1.1.5/30
set interfaces fe-1/2/1 unit 5 family inet6
set interfaces fe-1/2/1 unit 5 family mpls
set interfaces lo0 unit 2 family inet address 1.1.1.2/32
set protocols mpls ipv6-tunneling
set protocols mpls interface fe-1/2/0.2
set protocols mpls interface fe-1/2/1.5
set protocols bgp group toCE1 type external
set protocols bgp group toCE1 local-address ::10.1.1.2
set protocols bgp group toCE1 family inet6 unicast
set protocols bgp group toCE1 export send-bgp6
set protocols bgp group toCE1 peer-as 1
set protocols bgp group toCE1 neighbor ::10.1.1.1
set protocols bgp group toPE2 type internal
set protocols bgp group toPE2 local-address 1.1.1.2
set protocols bgp group toPE2 family inet6 labeled-unicast explicit-null
set protocols bgp group toPE2 export next-hop-self
set protocols bgp group toPE2 export send-v6
set protocols bgp group toPE2 neighbor 1.1.1.4
set protocols ospf area 0.0.0.0 interface fe-1/2/1.5
set protocols ospf area 0.0.0.0 interface lo0.2 passive
set protocols ldp interface fe-1/2/1.5
set policy-options policy-statement next-hop-self then next-hop self
set policy-options policy-statement send-bgp6 from family inet6
set policy-options policy-statement send-bgp6 from protocol bgp
set policy-options policy-statement send-bgp6 then accept
set policy-options policy-statement send-v6 from family inet6
set policy-options policy-statement send-v6 from protocol bgp
set policy-options policy-statement send-v6 from protocol direct
set policy-options policy-statement send-v6 then accept
set routing-options router-id 1.1.1.2
set routing-options autonomous-system 2

Device PE2 set interfaces fe-1/2/0 unit 10 family inet address 10.1.1.10/30
set interfaces fe-1/2/0 unit 10 family inet6
set interfaces fe-1/2/0 unit 10 family mpls
set interfaces fe-1/2/1 unit 13 family inet6 address ::10.1.1.13/126
set interfaces fe-1/2/1 unit 13 family mpls
set interfaces lo0 unit 4 family inet address 1.1.1.4/32
set protocols mpls ipv6-tunneling
set protocols mpls interface fe-1/2/0.10
set protocols mpls interface fe-1/2/1.13
set protocols bgp group toPE1 type internal

70 Copyright © 2012, Juniper Networks, Inc.

 Chapter 4: MPLS Router Configuration Guidelines

set protocols bgp group toPE1 local-address 1.1.1.4

set protocols bgp group toPE1 family inet6 labeled-unicast explicit-null
set protocols bgp group toPE1 export next-hop-self
set protocols bgp group toPE1 export send-v6
set protocols bgp group toPE1 neighbor 1.1.1.2
set protocols bgp group toCE3 type external
set protocols bgp group toCE3 local-address ::10.1.1.13
set protocols bgp group toCE3 family inet6 unicast
set protocols bgp group toCE3 export send-bgp6
set protocols bgp group toCE3 peer-as 3
set protocols bgp group toCE3 neighbor ::10.1.1.14
set protocols ospf area 0.0.0.0 interface fe-1/2/0.10
set protocols ospf area 0.0.0.0 interface lo0.4 passive
set protocols ldp interface fe-1/2/0.10
set policy-options policy-statement next-hop-self then next-hop self
set policy-options policy-statement send-bgp6 from family inet6
set policy-options policy-statement send-bgp6 from protocol bgp
set policy-options policy-statement send-bgp6 then accept
set policy-options policy-statement send-v6 from family inet6
set policy-options policy-statement send-v6 from protocol bgp
set policy-options policy-statement send-v6 from protocol direct
set policy-options policy-statement send-v6 then accept
set routing-options router-id 1.1.1.4
set routing-options autonomous-system 2

Device P set interfaces fe-1/2/0 unit 6 family inet address 10.1.1.6/30

set interfaces fe-1/2/0 unit 6 family inet6
set interfaces fe-1/2/0 unit 6 family mpls
set interfaces fe-1/2/1 unit 9 family inet address 10.1.1.9/30
set interfaces fe-1/2/1 unit 9 family inet6
set interfaces fe-1/2/1 unit 9 family mpls
set interfaces lo0 unit 3 family inet address 1.1.1.3/32
set protocols mpls interface fe-1/2/0.6
set protocols mpls interface fe-1/2/1.9
set protocols ospf area 0.0.0.0 interface fe-1/2/0.6
set protocols ospf area 0.0.0.0 interface fe-1/2/1.9
set protocols ospf area 0.0.0.0 interface lo0.3 passive
set protocols ldp interface fe-1/2/0.6
set protocols ldp interface fe-1/2/1.9
set routing-options router-id 1.1.1.3
set routing-options autonomous-system 2

Device CE1 set interfaces fe-1/2/0 unit 1 family inet6 address ::10.1.1.1/126
set interfaces fe-1/2/0 unit 1 family mpls
set interfaces lo0 unit 1 family inet6 address ::1.1.1.1/128
set protocols bgp group toPE1 type external
set protocols bgp group toPE1 local-address ::10.1.1.1
set protocols bgp group toPE1 family inet6 unicast
set protocols bgp group toPE1 export send-v6
set protocols bgp group toPE1 peer-as 2
set protocols bgp group toPE1 neighbor ::10.1.1.2
set policy-options policy-statement send-v6 from family inet6
set policy-options policy-statement send-v6 from protocol direct
set policy-options policy-statement send-v6 then accept
set routing-options router-id 1.1.1.1

Copyright © 2012, Juniper Networks, Inc. 71

Junos OS 12.1 MPLS Applications Configuration Guide

set routing-options autonomous-system 1

Device CE3 set interfaces fe-1/2/0 unit 14 family inet6 address ::10.1.1.14/126
set interfaces fe-1/2/0 unit 14 family mpls
set interfaces lo0 unit 5 family inet6 address ::1.1.1.5/128
set protocols bgp group toPE2 type external
set protocols bgp group toPE2 local-address ::10.1.1.14
set protocols bgp group toPE2 family inet6 unicast
set protocols bgp group toPE2 export send-v6
set protocols bgp group toPE2 peer-as 2
set protocols bgp group toPE2 neighbor ::10.1.1.13
set policy-options policy-statement send-v6 from family inet6
set policy-options policy-statement send-v6 from protocol direct
set policy-options policy-statement send-v6 then accept
set routing-options router-id 1.1.1.5
set routing-options autonomous-system 3

Configuring Device PE1

Step-by-Step The following example requires you to navigate various levels in the configuration
Procedure hierarchy. For information about navigating the CLI, see Using the CLI Editor in
Configuration Mode in the Junos OS CLI User Guide.

To configure Device PE1:

1. Configure the interfaces.

[edit interfaces]
user@PE1# set interfaces fe-1/2/0 unit 2 family inet6 address ::10.1.1.2/126
user@PE1# set interfaces fe-1/2/0 unit 2 family mpls

user@PE1# set interfaces fe-1/2/1 unit 5 family inet address 10.1.1.5/30

user@PE1# set interfaces fe-1/2/1 unit 5 family inet6
user@PE1# set interfaces fe-1/2/1 unit 5 family mpls

user@PE1# set interfaces lo0 unit 2 family inet address 1.1.1.2/32

2. Configure MPLS on the interfaces.

[edit protocols mpls]

user@PE1# set ipv6-tunneling
user@PE1# set interface fe-1/2/0.2
user@PE1# set interface fe-1/2/1.5

3. Configure BGP.

[edit protocols bgp]

user@PE1# set group toCE1 type external
user@PE1# set group toCE1 local-address ::10.1.1.2
user@PE1# set group toCE1 family inet6 unicast
user@PE1# set group toCE1 export send-bgp6
user@PE1# set group toCE1 peer-as 1
user@PE1# set group toCE1 neighbor ::10.1.1.1

user@PE1# set group toPE2 type internal

user@PE1# set group toPE2 local-address 1.1.1.2

72 Copyright © 2012, Juniper Networks, Inc.

 Chapter 4: MPLS Router Configuration Guidelines

user@PE1# set group toPE2 family inet6 labeled-unicast explicit-null

user@PE1# set group toPE2 export next-hop-self
user@PE1# set group toPE2 export send-v6
user@PE1# set group toPE2 neighbor 1.1.1.4

4. Configure OSPF

[edit protocols ospf area 0.0.0.0]

user@PE1# set interface fe-1/2/1.5
user@PE1# set interface lo0.2 passive

5. Configure a signaling protocol.

[edit protocols]
user@PE1# set ldp interface fe-1/2/1.5

6. Configure the routing policies.

[edit policy-options]
user@PE1# set policy-statement next-hop-self then next-hop self

user@PE1# set policy-statement send-bgp6 from family inet6

user@PE1# set policy-statement send-bgp6 from protocol bgp
user@PE1# set policy-statement send-bgp6 then accept

user@PE1# set policy-statement send-v6 from family inet6

user@PE1# set policy-statement send-v6 from protocol bgp
user@PE1# set policy-statement send-v6 from protocol direct
user@PE1# set policy-statement send-v6 then accept

7. Configure the router ID and the autonomous system (AS) number.

[edit routing-options]
user@PE1# set router-id 1.1.1.2
user@PE1# set autonomous-system 2

Results From configuration mode, confirm your configuration by entering the show interfaces,
show policy-options, show protocols, and show routing-options commands. If the output
does not display the intended configuration, repeat the instructions in this example to
correct the configuration.

user@R1# show interfaces

fe-1/2/0 {
unit 2 {
family inet6 {
address ::10.1.1.2/126;
}
family mpls;
}
}
fe-1/2/1 {
unit 5 {
family inet {
address 10.1.1.5/30;
}
family inet6;
family mpls;

Copyright © 2012, Juniper Networks, Inc. 73

Junos OS 12.1 MPLS Applications Configuration Guide

}
}
lo0 {
unit 2 {
family inet {
address 1.1.1.2/32;
}
}
}

user@R1# show policy-options

policy-statement next-hop-self {
then {
next-hop self;
}
}
policy-statement send-bgp6 {
from {
family inet6;
protocol bgp;
}
then accept;
}
policy-statement send-v6 {
from {
family inet6;
protocol [ bgp direct ];
}
then accept;
}

user@R1# show protocols

mpls {
ipv6-tunneling;
interface fe-1/2/0.2;
interface fe-1/2/1.5;
}
bgp {
group toCE1 {
type external;
local-address ::10.1.1.2;
family inet6 {
unicast;
}
export send-bgp6;
peer-as 1;
neighbor ::10.1.1.1;
}
group toPE2 {
type internal;
local-address 1.1.1.2;
family inet6 {
labeled-unicast {
explicit-null;
}
}
export [ next-hop-self send-v6 ];

74 Copyright © 2012, Juniper Networks, Inc.

 Chapter 4: MPLS Router Configuration Guidelines

neighbor 1.1.1.4;
}
}
ospf {
area 0.0.0.0 {
interface fe-1/2/1.5;
interface lo0.2 {
passive;
}
}
}
ldp {
interface fe-1/2/1.5;
}

user@R1# show routing-options

router-id 1.1.1.2;
autonomous-system 2;

If you are done configuring the device, enter commit from configuration mode.
Configure the other devices in the topology, as shown in “CLI Quick Configuration” on
page 70.

Verification
Confirm that the configuration is working properly.

Verifying That the CE Devices Have Connectivity

Purpose Make sure that the tunnel is operating.

Action From operational mode, enter the ping command.

user@CE1> ping ::10.1.1.14

PING6(56=40+8+8 bytes) ::10.1.1.1 --> ::10.1.1.14
16 bytes from ::10.1.1.14, icmp_seq=0 hlim=61 time=10.687 ms
16 bytes from ::10.1.1.14, icmp_seq=1 hlim=61 time=9.239 ms
16 bytes from ::10.1.1.14, icmp_seq=2 hlim=61 time=1.842 ms

user@CE3> ping ::10.1.1.1

PING6(56=40+8+8 bytes) ::10.1.1.14 --> ::10.1.1.1
16 bytes from ::10.1.1.1, icmp_seq=0 hlim=61 time=1.484 ms
16 bytes from ::10.1.1.1, icmp_seq=1 hlim=61 time=1.338 ms
16 bytes from ::10.1.1.1, icmp_seq=2 hlim=61 time=1.351 ms

Meaning The IPv6 CE devices can communicate over the core IPv4 network.

Related • Configuring the Ingress Router for MPLS-Signaled LSPs on page 56

Documentation
• Configuring the Intermediate and Egress Routers for MPLS-Signaled LSPs on page 63

• Minimum RSVP Configuration on page 393

Copyright © 2012, Juniper Networks, Inc. 75

Junos OS 12.1 MPLS Applications Configuration Guide

Configuring ICMP Message Tunneling for MPLS

Internet Control Message Protocol (ICMP) is one of the core TCP/IP protocols. Routers
can send ICMP advertisements over the network to enable hosts to discover the addresses
of operating routers. ICMP is also useful for network debugging by enabling the ping and
traceroute functions commonly used by network administrators.

ICMP message tunneling enables you to send ICMP messages over an LSP for debugging
purposes. To enable this feature, configure the icmp-tunneling statement at the [edit
protocols mpls] hierarchy level on each of the routers from which you wish to receive
ICMP messages.

ICMP messages generated by an intermediate LSR (for an LSP) are forwarded to the
egress router using the same LSP. The egress router uses IP routing or a reverse LSP to
send the ICMP message back towards the original source of the packet that generated
the ICMP message at the intermediate LSR.

ICMP message tunneling can handle ICMP traceroute using ICMP time exceeded
messages. It can also handle path MTU discovery which relies on the ICMP error message
“fragmentation needed, but do-not-fragment bit is set.”

To configure ICMP message tunneling for MPLS, include the icmp-tunneling statement:

icmp-tunneling;

You can include this statement at the following hierarchy levels:

• [edit protocols mpls]

• [edit logical-systems logical-system-name protocols mpls]

Example: Configuring SRLG

This example shows how to configure Shared Link Risk Groups (SRLGs) on a device.

• Requirements on page 76
• Overview on page 77
• Configuration on page 78
• Verification on page 83

Requirements
This example uses the following hardware and software components:

• Seven routers that can be a combination of M Series, MX Series, or T Series routers

• Junos OS Release 11.4 or later running on all the devices

76 Copyright © 2012, Juniper Networks, Inc.

 Chapter 4: MPLS Router Configuration Guidelines

Overview
Junos OS Release 11.4 and later support SRLG configuration in an IGP (OSPFv2 and IS-IS)
domain. In this example, you configure SRLG and associate it with the MPLS interface
on a device.

The device uses the SRLG cost parameter for the Constrained Shortest Path First (CSPF)
algorithm and tries to keep the links used for the primary and secondary paths mutually
exclusive by avoiding links that share any SRLG with the primary path.

To configure the SRLG, you first define the SRLG parameters at the [edit routing-options
srlg srlg-name] hierarchy level and then associate the SRLG with an MPLS interface at
the [edit mpls interface interface-name] hierarchy level.

The srlg srlg-name statement has the following options:

• srlg-cost—Include a cost for the SRLG ranging from 1 through 65535. The cost of the
SRLG determines the level of impact this SRLG has on the CSPF algorithm for path
computations. The higher the cost, the less likely it is for a secondary path to share the
same SRLG as the primary path. By default, the srlg-cost is 1.

• srlg-value—Include a group ID for the SRLG ranging from 1 through 4294967295.

In this example, PE1 is the ingress router and PE2 is the egress router. P1, P2, and P3, P4,
and P5 are transit routers. OSPF is configured on all the routers as the interior gateway
protocol (IGP). SRLG is configured on all seven routers. The primary path includes SRLG
srlg-a. For the standby secondary path, the link P2>PE2 belongs to SRLG srlg-a. The
effective link metric, with the added srlg-cost of 10, becomes 11. Therefore, the computed
secondary path is PE1>P3>P4>P5>PE2 with a CSPF link metric of 4.

Copyright © 2012, Juniper Networks, Inc. 77

Junos OS 12.1 MPLS Applications Configuration Guide

Configuration
CLI Quick To quickly configure this section of the example, copy the following commands, paste
Configuration them into a text file, remove any line breaks, change any details necessary to match your
network configuration, and then copy and paste the commands into the CLI at the [edit]
hierarchy level.

Router PE1 set interfaces ge-0/0/1 unit 0 family inet address 192.168.12.1/24
set interfaces ge-0/0/1 unit 0 family mpls
set interfaces ge-0/0/2 unit 0 family inet address 192.168.13.1/24
set interfaces ge-0/0/2 unit 0 family mpls
set interfaces ge-0/0/3 unit 0 family inet address 192.168.14.1/24
set interfaces ge-0/0/3 unit 0 family mpls
set interfaces lo0 unit 0 family inet address 10.255.0.1/32
set routing-options srlg srlg-a srlg-value 101
set routing-options srlg srlg-a srlg-cost 10
set protocols rsvp interface ge-0/0/1.0
set protocols rsvp interface ge-0/0/2.0
set protocols rsvp interface ge-0/0/3.0
set protocols mpls optimize-timer 120
set protocols mpls label-switched-path pe1-pe2 to 10.255.0.7
set protocols mpls label-switched-path pe1-pe2 primary via-p1
set protocols mpls label-switched-path pe1-pe2 secondary path2 standby
set protocols mpls path via-p1 10.255.0.2 strict
set protocols mpls path path2
set protocols mpls interface ge-0/0/1.0
set protocols mpls interface ge-0/0/2.0
set protocols mpls interface ge-0/0/3.0
set protocols ospf traffic-engineering
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
set protocols ospf area 0.0.0.0 interface ge-0/0/2.0
set protocols ospf area 0.0.0.0 interface ge-0/0/3.0
set protocols ospf area 0.0.0.0 interface lo0.0

Router P1 set interfaces ge-0/0/1 unit 0 family inet address 192.168.12.2/24

set interfaces ge-0/0/1 unit 0 family mpls
set interfaces ge-0/0/2 unit 0 family inet address 192.168.27.2/24
set interfaces ge-0/0/2 unit 0 family mpls
set interfaces lo0 unit 0 family inet address 10.255.0.2/32
set routing-options srlg srlg-a srlg-value 101
set routing-options srlg srlg-a srlg-cost 10
set protocols rsvp interface ge-0/0/1.0
set protocols rsvp interface ge-0/0/2.0
set protocols mpls interface ge-0/0/1.0
set protocols mpls interface ge-0/0/2.0 srlg srlg-a
set protocols ospf traffic-engineering
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
set protocols ospf area 0.0.0.0 interface ge-0/0/2.0
set protocols ospf area 0.0.0.0 interface lo0.0

Router P2 set interfaces ge-0/0/1 unit 0 family inet address 192.168.13.3/24

set interfaces ge-0/0/1 unit 0 family mpls
set interfaces ge-0/0/2 unit 0 family inet address 192.168.37.3/24
set interfaces ge-0/0/2 unit 0 family mpls
set interfaces lo0 unit 0 family inet address 10.255.0.3/32

78 Copyright © 2012, Juniper Networks, Inc.

 Chapter 4: MPLS Router Configuration Guidelines

set routing-options srlg srlg-a srlg-value 101

set routing-options srlg srlg-a srlg-cost 10
set protocols rsvp interface ge-0/0/1.0
set protocols rsvp interface ge-0/0/2.0
set protocols mpls interface ge-0/0/1.0
set protocols mpls interface ge-0/0/2.0 srlg srlg-a
set protocols ospf traffic-engineering
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
set protocols ospf area 0.0.0.0 interface ge-0/0/2.0
set protocols ospf area 0.0.0.0 interface lo0.0

Router P3 set interfaces ge-0/0/1 unit 0 family inet address 192.168.14.4/24

set interfaces ge-0/0/1 unit 0 family mpls
set interfaces ge-0/0/2 unit 0 family inet address 192.168.45.4/24
set interfaces ge-0/0/2 unit 0 family mpls
set interfaces lo0 unit 0 family inet address 10.255.0.4/32
set routing-options srlg srlg-a srlg-value 101
set routing-options srlg srlg-a srlg-cost 10
set protocols rsvp interface ge-0/0/1.0
set protocols rsvp interface ge-0/0/2.0
set protocols mpls interface ge-0/0/1.0
set protocols mpls interface ge-0/0/2.0
set protocols ospf traffic-engineering
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
set protocols ospf area 0.0.0.0 interface ge-0/0/2.0
set protocols ospf area 0.0.0.0 interface lo0.0

Router P4 set interfaces ge-0/0/1 unit 0 family inet address 192.168.45.5/24

set interfaces ge-0/0/1 unit 0 family mpls
set interfaces ge-0/0/2 unit 0 family inet address 192.168.56.5/24
set interfaces ge-0/0/2 unit 0 family mpls
set interfaces lo0 unit 0 family inet address 10.255.0.5/32
set routing-options srlg srlg-a srlg-value 101
set routing-options srlg srlg-a srlg-cost 10
set protocols rsvp interface ge-0/0/1.0
set protocols rsvp interface ge-0/0/2.0
set protocols mpls interface ge-0/0/1.0
set protocols mpls interface ge-0/0/2.0
set protocols ospf traffic-engineering
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
set protocols ospf area 0.0.0.0 interface ge-0/0/2.0
set protocols ospf area 0.0.0.0 interface lo0.0

Router P5 set interfaces ge-0/0/1 unit 0 family inet address 192.168.56.6/24

set interfaces ge-0/0/1 unit 0 family mpls
set interfaces ge-0/0/2 unit 0 family inet address 192.168.67.6/24
set interfaces ge-0/0/2 unit 0 family mpls
set interfaces lo0 unit 0 family inet address 10.255.0.6/32
set routing-options srlg srlg-a srlg-value 101
set routing-options srlg srlg-a srlg-cost 10
set protocols rsvp interface ge-0/0/1.0
set protocols rsvp interface ge-0/0/2.0
set protocols mpls interface ge-0/0/1.0
set protocols mpls interface ge-0/0/2.0
set protocols ospf traffic-engineering

Copyright © 2012, Juniper Networks, Inc. 79

Junos OS 12.1 MPLS Applications Configuration Guide

set protocols ospf area 0.0.0.0 interface ge-0/0/1.0

set protocols ospf area 0.0.0.0 interface ge-0/0/2.0
set protocols ospf area 0.0.0.0 interface lo0.0

Router PE2 set interfaces ge-0/0/1 unit 0 family inet address 192.168.27.7/24
set interfaces ge-0/0/1 unit 0 family mpls
set interfaces ge-0/0/2 unit 0 family inet address 192.168.37.7/24
set interfaces ge-0/0/2 unit 0 family mpls
set interfaces ge-0/0/3 unit 0 family inet address 192.168.67.7/24
set interfaces ge-0/0/3 unit 0 family mpls
set interfaces lo0 unit 0 family inet address 10.255.0.7/32
set routing-options srlg srlg-a srlg-value 101
set routing-options srlg srlg-a srlg-cost 10
set protocols rsvp interface ge-0/0/1.0
set protocols rsvp interface ge-0/0/2.0
set protocols rsvp interface ge-0/0/3.0
set protocols mpls interface ge-0/0/1.0
set protocols mpls interface ge-0/0/2.0
set protocols mpls interface ge-0/0/3.0
set protocols ospf traffic-engineering
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
set protocols ospf area 0.0.0.0 interface ge-0/0/2.0
set protocols ospf area 0.0.0.0 interface ge-0/0/3.0
set protocols ospf area 0.0.0.0 interface lo0.0

Step-by-Step The following example requires you to navigate various levels in the configuration
Procedure hierarchy. For information about navigating the CLI, see the Junos OS CLI User Guide.

To configure the ingress router PE1:

1. Configure the device interfaces.

[edit interfaces]
user@PE1# set ge-0/0/1 unit 0 family inet address 192.168.12.1/24
user@PE1# set ge-0/0/1 unit 0 family mpls
user@PE1# set ge-0/0/2 unit 0 family inet address 192.168.13.1/24
user@PE1# set ge-0/0/2 unit 0 family mpls
user@PE1# set ge-0/0/3 unit 0 family inet address 192.168.14.1/24
user@PE1# set ge-0/0/3 unit 0 family mpls
user@PE1# set lo0 unit 0 family inet address 10.255.0.1/32

2. Configure OSPF on the interfaces.

[edit protocols ospf]

user@PE1# set traffic-engineering
user@PE1# set area 0.0.0.0 interface ge-0/0/1.0
user@PE1# set area 0.0.0.0 interface ge-0/0/2.0
user@PE1# set area 0.0.0.0 interface ge-0/0/3.0
user@PE1# set area 0.0.0.0 interface lo0.0

3. Configure the SRLG definitions.

[edit routing-options]
user@PE1# set routing-options srlg srlg-a srlg-value 101
user@PE1# set routing-options srlg srlg-a srlg-cost 10

4. Configure MPLS and the LSPs.

80 Copyright © 2012, Juniper Networks, Inc.

 Chapter 4: MPLS Router Configuration Guidelines

[edit protocols mpls]

user@PE1# set interface ge-0/0/1.0
user@PE1# set interface ge-0/0/2.0
user@PE1# set interface ge-0/0/3.0
user@PE1# set optimize-timer 120
user@PE1# set label-switched-path pe1-pe2 to 10.255.0.7
user@PE1# set label-switched-path pe1-pe2 primary via-p1
user@PE1# set label-switched-path pe1-pe2 secondary path2 standby
user@PE1# set path via-p1 10.255.0.2 strict
user@PE1# set path path2

5. Enable RSVP on the interfaces.

[edit protocols rsvp]

user@PE1# set interface ge-0/0/1.0
user@PE1# set interface ge-0/0/2.0
user@PE1# set interface ge-0/0/3.0

Results From configuration mode, confirm your configuration by entering the show interfaces,
show protocols ospf, show routing-options, show protocols mpls, and show protocols rsvp
commands. If the output does not display the intended configuration, repeat the
instructions in this example to correct the configuration.

user@PE1# show interfaces

interfaces {
ge-0/0/1 {
unit 0 {
family inet {
address 192.168.12.1/24;
}
family mpls;
}
}
ge-0/0/2 {
unit 0 {
family inet {
address 192.168.13.1/24;
}
family mpls;
}
}
ge-0/0/3 {
unit 0 {
family inet {
address 192.168.14.1/24;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 10.255.0.1/32;
}
}
}

Copyright © 2012, Juniper Networks, Inc. 81

Junos OS 12.1 MPLS Applications Configuration Guide

user@PE1# show protocols ospf

traffic-engineering;
area 0.0.0.0 {
interface ge-0/0/1.0;;
interface ge-0/0/2.0;
interface ge-0/0/3.0;
interface lo0.0;
}

user@PE1# show protocols mpls

optimize-timer 120;
label-switched-path pe1-pe2 {
to 10.255.0.7;
primary via-p1;
secondary path2 {
standby;
}
}
path via-p1 {
10.255.0.2 strict;
}
path path2;
interface ge-0/0/1.0;
interface ge-0/0/2.0;
interface ge-0/0/3.0;

user@PE1# show protocols rsvp

interface ge-0/0/1.0;
interface ge-0/0/2.0;
interface ge-0/0/3.0;

user@PE1# show routing-options

routing-options {
srlg {
srlg-a {
srlg-value 101;
srlg-cost 10;
}
}
}

If you are done configuring the device, enter commit from configuration mode.

NOTE: Repeat this procedure for every Juniper Networks router in the IGP
domain, after modifying the appropriate interface names, addresses, and
any other parameters for each router.

82 Copyright © 2012, Juniper Networks, Inc.

 Chapter 4: MPLS Router Configuration Guidelines

Verification
Confirm that the configuration is working properly.

• Verifying SRLG Definitions on page 83

• Verify TE-Link SRLG on page 83
• Verify Standby Secondary Path on page 83

Verifying SRLG Definitions

Purpose Verify SRLG-to-value mappings and SRLG cost.

Action user@PE1> show mpls srlg

SRLG Value Cost

srlg-a 101 10

Verify TE-Link SRLG

Purpose Verify the traffic engineering link SRLG association.

Action user@PE1> show ted link detail

...
10.255.0.2->192.168.27.7-1, Local: 192.168.27.2, Remote: 0.0.0.0
Local interface index: 0, Remote interface index: 0
LocalPath: 1, Metric: 1, StaticBW: 1000Mbps, AvailBW: 1000Mbps
Color: 0 <none>
SRLGs: srlg-a
localBW [0] 0bps [1] 0bps [2] 0bps [3] 0bps
localBW [4] 0bps [5] 0bps [6] 0bps [7] 0bps

...
10.255.0.3->192.168.37.7-1, Local: 192.168.37.3, Remote: 0.0.0.0
Local interface index: 0, Remote interface index: 0
LocalPath: 0, Metric: 1, StaticBW: 1000Mbps, AvailBW: 1000Mbps
Color: 0 <none>
SRLGs: srlg-a
localBW [0] 0bps [1] 0bps [2] 0bps [3] 0bps
localBW [4] 0bps [5] 0bps [6] 0bps [7] 0bps

...

Meaning Links P1-PE2 and P2-PE2 are associated with SRLG srlg-a.

Verify Standby Secondary Path

Purpose Check the SRLG link cost and its impact on the CSPF computation of the standby
secondary path link.

Action user@PE1> show mpls lsp ingress extensive

Ingress LSP: 1 sessions

10.255.0.7

Copyright © 2012, Juniper Networks, Inc. 83

Junos OS 12.1 MPLS Applications Configuration Guide

From: 10.255.0.1, State: Up, ActiveRoute: 0, LSPname: pe1-pe2

ActivePath: via-p1 (primary)
LSPtype: Static Configured
LoadBalance: Random
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary via-p1 State: Up
Priorities: 7 0
OptimizeTimer: 120
SmartOptimizeTimer: 180
SRLG: srlg-a
Reoptimization in 110 second(s).
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 2)
192.168.12.2 S 192.168.27.7 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt
20=Node-ID):
192.168.12.2 192.168.27.7
7 Oct 13 15:17:11.310 CSPF: computation result ignored, new path no benefit
6 Oct 13 15:15:14.959 Selected as active path
5 Oct 13 15:15:14.958 Record Route: 192.168.12.2 192.168.27.7
4 Oct 13 15:15:14.954 Up
3 Oct 13 15:15:14.793 Originate Call
2 Oct 13 15:15:14.793 CSPF: computation result accepted 192.168.12.2
192.168.27.7
1 Oct 13 15:14:46.214 CSPF failed: no route toward 10.255.0.2
Standby path2 State: Up
Priorities: 7 0
OptimizeTimer: 120
SmartOptimizeTimer: 180
Reoptimization in 115 second(s).
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 4)
192.168.14.4 S 192.168.45.5 S 192.168.56.6 S 192.168.67.7 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt
20=Node-ID):
192.168.14.4 192.168.45.5 192.168.56.6 192.168.67.7
10 Oct 13 15:17:11.929 Record Route: 192.168.14.4 192.168.45.5 192.168.56.6
192.168.67.7
9 Oct 13 15:17:11.929 Up
8 Oct 13 15:17:11.729 Originate Call
7 Oct 13 15:17:11.729 Clear Call
6 Oct 13 15:17:11.729 CSPF: computation result accepted 192.168.14.4
192.168.45.5 192.168.56.6 192.168.67.7
5 Oct 13 15:17:11.729 CSPF: Reroute due to re-optimization
4 Oct 13 15:15:14.984 Record Route: 192.168.13.3 192.168.37.7
3 Oct 13 15:15:14.984 Up
2 Oct 13 15:15:14.830 Originate Call
1 Oct 13 15:15:14.830 CSPF: computation result accepted 192.168.13.3
192.168.37.7
Created: Thu Oct 13 15:13:46 2011
Total 1 displayed, Up 1, Down 0

Meaning Check the standby secondary path. The effective link cost for P2>PE2 is 11 (with the added
srlg-cost of 10). CSPF computes the secondary path as PE1>P3>P4>P5>PE2 with a CSPF
link metric of 4.

Related • SRLG Overview on page 36

Documentation
• Example: Excluding SRLG Links Completely for the Secondary LSP on page 85

• srlg on page 357

84 Copyright © 2012, Juniper Networks, Inc.

 Chapter 4: MPLS Router Configuration Guidelines

• srlg-cost on page 358

• srlg-value on page 358

Example: Excluding SRLG Links Completely for the Secondary LSP

This example shows how to configure the exclude-srlg option to exclude Shared Risk
Link Group (SRLG) links for the secondary label-switched path (LSP).

• Requirements on page 85
• Overview on page 85
• Configuration on page 86
• Verification on page 89

Requirements
This example uses the following hardware and software components:

• M Series, MX Series, or T Series devices

• Junos OS Release 11.4 or later running on all the devices

Overview
For critical links where it is imperative to keep the secondary and primary paths completely
disjoint from any common SRLG, you can optionally configure the exclude-srlg statement
at the [edit protocols mpls] or [edit protocols mpls label-switched-path path-name]
hierarchy levels. For logical systems, you configure the exclude-srlg statement at the edit
logical-systems protocols mpls[edit logical-systems logical-system-name protocols mpls
label-switched-path path-name] hierarchy level.

If exclude-srlg is configured, the Constrained Shortest Path First (CSPF) algorithm

excludes any link belonging to the set of SRLGs in the primary path. If exclude-srlg is not
configured, and if a link belongs to the set of SRLGs in the primary path, CSPF adds the
SRLG cost to the metric, but still accepts the link for computing the path.

In this example, PE1 is the ingress router and PE2 is the egress router. P1, P2, and P3, P4,
and P5 are transit routers. OSPF is configured on all the routers as the interior gateway
protocol (IGP). SRLG is configured on all seven routers. The primary path includes SRLG
srlg-a. For the standby secondary path, the link P2>PE2 belongs to SRLG srlg-a. Because

Copyright © 2012, Juniper Networks, Inc. 85

Junos OS 12.1 MPLS Applications Configuration Guide

exclude-srlg is configured, CSPF rejects link P2>PE2 as the link belongs to the SRLG srlg-a.
Therefore, the computed standby secondary path is PE1>P3>P4>P5>PE2.

Configuration
CLI Quick To quickly configure this section of the example, copy the following commands, paste
Configuration them into a text file, remove any line breaks, change any details necessary to match your
network configuration, and then copy and paste the commands into the CLI at the [edit]
hierarchy level.

Router PE1 set interfaces ge-0/0/1 unit 0 family inet address 192.168.12.1/24
set interfaces ge-0/0/1 unit 0 family mpls
set interfaces ge-0/0/2 unit 0 family inet address 192.168.13.1/24
set interfaces ge-0/0/2 unit 0 family mpls
set interfaces ge-0/0/3 unit 0 family inet address 192.168.14.1/24
set interfaces ge-0/0/3 unit 0 family mpls
set interfaces lo0 unit 0 family inet address 10.255.0.1/32
set routing-options srlg srlg-a srlg-value 101
set protocols rsvp interface ge-0/0/1.0
set protocols rsvp interface ge-0/0/2.0
set protocols rsvp interface ge-0/0/3.0
set protocols mpls optimize-timer 120
set protocols mpls exclude-srlg
set protocols mpls label-switched-path pe1-pe2 to 10.255.0.7
set protocols mpls label-switched-path pe1-pe2 primary via-p1
set protocols mpls label-switched-path pe1-pe2 secondary path2 standby
set protocols mpls path via-p1 10.255.0.2 strict
set protocols mpls path path2
set protocols mpls interface ge-0/0/1.0
set protocols mpls interface ge-0/0/2.0
set protocols mpls interface ge-0/0/3.0
set protocols ospf traffic-engineering

86 Copyright © 2012, Juniper Networks, Inc.

 Chapter 4: MPLS Router Configuration Guidelines

set protocols ospf area 0.0.0.0 interface ge-0/0/1.0

set protocols ospf area 0.0.0.0 interface ge-0/0/2.0
set protocols ospf area 0.0.0.0 interface ge-0/0/3.0
set protocols ospf area 0.0.0.0 interface lo0.0

Step-by-Step The following example requires you to navigate various levels in the configuration
Procedure hierarchy. For information about navigating the CLI, see the Junos OS CLI User Guide.

1. Configure the device interfaces.

[edit interfaces]
user@PE1# set ge-0/0/1 unit 0 family inet address 192.168.12.1/24
user@PE1# set ge-0/0/1 unit 0 family mpls
user@PE1# set ge-0/0/2 unit 0 family inet address 192.168.13.1/24
user@PE1# set ge-0/0/2 unit 0 family mpls
user@PE1# set ge-0/0/3 unit 0 family inet address 192.168.14.1/24
user@PE1# set ge-0/0/3 unit 0 family mpls
user@PE1# set lo0 unit 0 family inet address 10.255.0.1/32

2. Configure OSPF on the interfaces.

[edit protocols ospf]

user@PE1# set traffic-engineering
user@PE1# set area 0.0.0.0 interface ge-0/0/1.0
user@PE1# set area 0.0.0.0 interface ge-0/0/2.0
user@PE1# set area 0.0.0.0 interface ge-0/0/3.0
user@PE1# set area 0.0.0.0 interface lo0.0

3. Configure the SRLG definitions.

[edit routing-options]
user@PE1# set routing-options srlg srlg-a srlg-value 101

4. Configure MPLS and the LSPs.

[edit protocols mpls]

user@PE1# set interface ge-0/0/1.0
user@PE1# set interface ge-0/0/2.0
user@PE1# set interface ge-0/0/3.0
user@PE1# set optimize-timer 120
user@PE1# set exclude-srlg
user@PE1# set label-switched-path pe1-pe2 to 10.255.0.7
user@PE1# set label-switched-path pe1-pe2 primary via-p1
user@PE1# set label-switched-path pe1-pe2 secondary path2 standby
user@PE1# set path via-p1 10.255.0.2 strict
user@PE1# set path path2

5. Configure the exclude-srlg statement to forcibly keep the links for the secondary
path completely disjoint from the primary LSP path.

user@PE1 set protocols mpls exclude-srlg

6. Enable RSVP on the interfaces.

[edit protocols rsvp]

user@PE1# set interface ge-0/0/1.0
user@PE1# set interface ge-0/0/2.0
user@PE1# set interface ge-0/0/3.0

Copyright © 2012, Juniper Networks, Inc. 87

Junos OS 12.1 MPLS Applications Configuration Guide

Results From configuration mode, confirm your configuration by entering the show interfaces,
show protocols ospf, show routing-options, show protocols mpls, and show protocols rsvp
commands. If the output does not display the intended configuration, repeat the
instructions in this example to correct the configuration.

user@PE1# show interfaces

interfaces {
ge-0/0/1 {
unit 0 {
family inet {
address 192.168.12.1/24;
}
family mpls;
}
}
ge-0/0/2 {
unit 0 {
family inet {
address 192.168.13.1/24;
}
family mpls;
}
}
ge-0/0/3 {
unit 0 {
family inet {
address 192.168.14.1/24;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 10.255.0.1/32;
}
}
}
}

user@PE1# show protocols ospf

traffic-engineering;
area 0.0.0.0 {
interface ge-0/0/1.0;;
interface ge-0/0/2.0;
interface ge-0/0/3.0;
interface lo0.0;
}

user@PE1# show protocols mpls

optimize-timer 120;
label-switched-path pe1-pe2 {
to 10.255.0.7;
primary via-p1;
secondary path2 {
standby;

88 Copyright © 2012, Juniper Networks, Inc.

 Chapter 4: MPLS Router Configuration Guidelines

}
}
path via-p1 {
10.255.0.2 strict;
}
path path2;
interface ge-0/0/1.0;
interface ge-0/0/2.0;
interface ge-0/0/3.0;

user@PE1# show protocols rsvp

interface ge-0/0/1.0;
interface ge-0/0/2.0;
interface ge-0/0/3.0;

user@PE1# show routing-options

routing-options {
srlg {
srlg-a srlg-value 101;
}
}

If you are done configuring the device, enter commit from configuration mode.

NOTE: Repeat this procedure for every Juniper Networks router in the IGP
domain, after modifying the appropriate interface names, addresses, and
any other parameters for each router.

Verification
Confirm that the configuration is working properly.

Verifying the Secondary Path Link for the LSP

Purpose Verify that the link for the secondary path is completely disjoint from the primary path.

Action user@PE1> show mpls lsp show mpls lsp detail

Ingress LSP: 1 sessions

10.255.0.7
From: 10.255.0.1, State: Up, ActiveRoute: 0, LSPname: pe1-pe2
ActivePath: via-p1 (primary)
LSPtype: Static Configured
LoadBalance: Random
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary via-p1 State: Up
Priorities: 7 0
OptimizeTimer: 120
SmartOptimizeTimer: 180
SRLG: srlg-a
Reoptimization in 77 second(s).
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 2)
192.168.12.2 S 192.168.27.7 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt

Copyright © 2012, Juniper Networks, Inc. 89

Junos OS 12.1 MPLS Applications Configuration Guide

20=Node-ID):
192.168.12.2 192.168.27.7
Standby path2 State: Up
Priorities: 7 0
OptimizeTimer: 120
SmartOptimizeTimer: 180
Reoptimization in 106 second(s).
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 4)
192.168.14.4 S 192.168.45.5 S 192.168.56.6 S 192.168.67.7 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt
20=Node-ID):
192.168.14.4 192.168.45.5 192.168.56.6 192.168.67.7
Total 1 displayed, Up 1, Down 0

Link P1->PE2: SRLG srlg-a

Link P2->PE2: SRLG srlg-a

Primary path: PE1-P1-PE2 (CSPF metric: 2)

Standby secondary: PE1-P3-P4-P5-PE2 (CSPF metric: 4)

Meaning Primary path includes SRLG srlg-a. For the standby secondary path, the link P2>PE2
belongs to SRLG srlg-a. CSPF rejects link P2>PE2 because the link belongs to the SRLG
srlg-a.

Related • SRLG Overview on page 36

Documentation
• Example: Configuring SRLG on page 76

• exclude-srlg on page 300

Example: Configuring SRLG With Link Protection

This example shows how to configure SRLG with link protection without the exclude-srlg
option.

• Requirements on page 90
• Overview on page 90
• Configuration on page 91
• Verification on page 108

Requirements
This example uses the following hardware and software components:

• M Series, MX Series, or T Series devices

• Junos OS Release 11.4 or later running on all the devices

Overview
In this example, PE1 is the ingress router and PE2 is the egress router. P1, P2, and P3, P4,
and P5 are transit routers. OSPF is configured on all the routers as the interior gateway

90 Copyright © 2012, Juniper Networks, Inc.

 Chapter 4: MPLS Router Configuration Guidelines

protocol (IGP). SRLG is configured on all seven routers. The link P1>PE2 (primary path)
and the link P2>PE2 belong to SRLG srlg-a.

You configure link protection for the interface P1>PE2 by including the link-protection
statement.

When SRLG srlg-a is configured on the link P1>PE2 and P2>PE2, the bypass takes the
longer path P1>P4>P5>PE2, not selecting the link P2>PE2 because of the added SRLG
cost for srlg-a.

Primary path
Secondary path

P2
srlg-a

PE1 P1 PE2
srlg-a

P3 P4 P5

g040926
Configuration
CLI Quick To quickly configure this section of the example, copy the following commands, paste
Configuration them into a text file, remove any line breaks, change any details necessary to match your
network configuration, and then copy and paste the commands into the CLI at the [edit]
hierarchy level.

Router PE1 set interfaces ge-0/0/1 unit 0 family inet address 192.168.12.1/24
set interfaces ge-0/0/1 unit 0 family mpls
set interfaces ge-0/0/2 unit 0 family inet address 192.168.13.1/24
set interfaces ge-0/0/2 unit 0 family mpls
set interfaces ge-0/0/3 unit 0 family inet address 192.168.14.1/24
set interfaces ge-0/0/3 unit 0 family mpls
set interfaces lo0 unit 0 family inet address 10.255.0.1/32
set routing-options srlg srlg-a srlg-value 101
set routing-options srlg srlg-a srlg-cost 10
set protocols rsvp interface ge-0/0/1.0
set protocols rsvp interface ge-0/0/2.0
set protocols rsvp interface ge-0/0/3.0
set protocols mpls optimize-timer 120
set protocols mpls label-switched-path pe1-pe2 to 10.255.0.7
set protocols mpls label-switched-path pe1-pe2 link-protection

Copyright © 2012, Juniper Networks, Inc. 91

Junos OS 12.1 MPLS Applications Configuration Guide

set protocols mpls label-switched-path pe1-pe2 primary via-p1

set protocols mpls label-switched-path pe1-pe2 secondary path2 standby
set protocols mpls path via-p1 10.255.0.2 strict
set protocols mpls path path2
set protocols mpls interface ge-0/0/1.0
set protocols mpls interface ge-0/0/2.0
set protocols mpls interface ge-0/0/3.0
set protocols ospf traffic-engineering
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
set protocols ospf area 0.0.0.0 interface ge-0/0/2.0
set protocols ospf area 0.0.0.0 interface ge-0/0/3.0
set protocols ospf area 0.0.0.0 interface lo0.0

Router P1 set interfaces ge-0/0/1 unit 0 family inet address 192.168.12.2/24

set interfaces ge-0/0/1 unit 0 family mpls
set interfaces ge-0/0/2 unit 0 family inet address 192.168.27.2/24
set interfaces ge-0/0/2 unit 0 family mpls
set interfaces ge-0/0/3 unit 0 family inet address 192.168.23.2/24
set interfaces ge-0/0/3 unit 0 family mpls
set interfaces ge-0/0/4 unit 0 family inet address 192.168.25.2/24
set interfaces ge-0/0/4 unit 0 family mpls
set interfaces lo0 unit 0 family inet address 10.255.0.2/32
set routing-options srlg srlg-a srlg-value 101
set routing-options srlg srlg-a srlg-cost 10
set protocols rsvp interface ge-0/0/1.0
set protocols rsvp interface ge-0/0/2.0 link-protection
set protocols rsvp interface ge-0/0/3.0
set protocols rsvp interface ge-0/0/4.0
set protocols mpls interface ge-0/0/1.0
set protocols mpls interface ge-0/0/2.0 srlg srlg-a
set protocols mpls interface ge-0/0/3.0
set protocols mpls interface ge-0/0/4.0
set protocols ospf traffic-engineering
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
set protocols ospf area 0.0.0.0 interface ge-0/0/2.0
set protocols ospf area 0.0.0.0 interface ge-0/0/3.0
set protocols ospf area 0.0.0.0 interface ge-0/0/4.0
set protocols ospf area 0.0.0.0 interface lo0.0

Router P2 set interfaces ge-0/0/1 unit 0 family inet address 192.168.13.3/24

set interfaces ge-0/0/1 unit 0 family mpls
set interfaces ge-0/0/2 unit 0 family inet address 192.168.37.3/24
set interfaces ge-0/0/2 unit 0 family mpls
set interfaces ge-0/0/3 unit 0 family inet address 192.168.23.3/24
set interfaces ge-0/0/3 unit 0 family mpls
set interfaces lo0 unit 0 family inet address 10.255.0.3/32
set routing-options srlg srlg-a srlg-value 101
set routing-options srlg srlg-a srlg-cost 10
set protocols rsvp interface ge-0/0/1.0
set protocols rsvp interface ge-0/0/2.0
set protocols rsvp interface ge-0/0/3.0
set protocols mpls interface ge-0/0/1.0
set protocols mpls interface ge-0/0/2.0 srlg srlg-a
set protocols mpls interface ge-0/0/3.0
set protocols ospf traffic-engineering

92 Copyright © 2012, Juniper Networks, Inc.

 Chapter 4: MPLS Router Configuration Guidelines

set protocols ospf area 0.0.0.0 interface ge-0/0/1.0

set protocols ospf area 0.0.0.0 interface ge-0/0/2.0
set protocols ospf area 0.0.0.0 interface ge-0/0/3.0
set protocols ospf area 0.0.0.0 interface lo0.0

Router P3 set interfaces ge-0/0/1 unit 0 family inet address 192.168.14.4/24

set interfaces ge-0/0/1 unit 0 family mpls
set interfaces ge-0/0/2 unit 0 family inet address 192.168.45.4/24
set interfaces ge-0/0/2 unit 0 family mpls
set interfaces lo0 unit 0 family inet address 10.255.0.4/32
set routing-options srlg srlg-a srlg-value 101
set routing-options srlg srlg-a srlg-cost 10
set protocols rsvp interface ge-0/0/1.0
set protocols rsvp interface ge-0/0/2.0
set protocols mpls interface ge-0/0/1.0
set protocols mpls interface ge-0/0/2.0
set protocols ospf traffic-engineering
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
set protocols ospf area 0.0.0.0 interface ge-0/0/2.0
set protocols ospf area 0.0.0.0 interface lo0.0

Router P4 set interfaces ge-0/0/1 unit 0 family inet address 192.168.45.5/24

set interfaces ge-0/0/1 unit 0 family mpls
set interfaces ge-0/0/2 unit 0 family inet address 192.168.56.5/24
set interfaces ge-0/0/2 unit 0 family mpls
set interfaces ge-0/0/3 unit 0 family inet address 192.168.25.5/24
set interfaces ge-0/0/3 unit 0 family mpls
set interfaces lo0 unit 0 family inet address 10.255.0.5/32
set routing-options srlg srlg-a srlg-value 101
set routing-options srlg srlg-a srlg-cost 10
set protocols rsvp interface ge-0/0/1.0
set protocols rsvp interface ge-0/0/2.0
set protocols rsvp interface ge-0/0/3.0
set protocols mpls interface ge-0/0/1.0
set protocols mpls interface ge-0/0/2.0
set protocols mpls interface ge-0/0/3.0
set protocols ospf traffic-engineering
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
set protocols ospf area 0.0.0.0 interface ge-0/0/2.0
set protocols ospf area 0.0.0.0 interface ge-0/0/3.0
set protocols ospf area 0.0.0.0 interface lo0.0

Router P5 set interfaces ge-0/0/1 unit 0 family inet address 192.168.56.6/24

set interfaces ge-0/0/1 unit 0 family mpls
set interfaces ge-0/0/2 unit 0 family inet address 192.168.67.6/24
set interfaces ge-0/0/2 unit 0 family mpls
set interfaces lo0 unit 0 family inet address 10.255.0.6/32
set routing-options srlg srlg-a srlg-value 101
set routing-options srlg srlg-a srlg-cost 10
set protocols rsvp interface ge-0/0/1.0
set protocols rsvp interface ge-0/0/2.0
set protocols mpls interface ge-0/0/1.0
set protocols mpls interface ge-0/0/2.0
set protocols ospf traffic-engineering
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0

Copyright © 2012, Juniper Networks, Inc. 93

Junos OS 12.1 MPLS Applications Configuration Guide

set protocols ospf area 0.0.0.0 interface ge-0/0/2.0

set protocols ospf area 0.0.0.0 interface lo0.0

Router PE2 set interfaces ge-0/0/1 unit 0 family inet address 192.168.27.7/24
set interfaces ge-0/0/1 unit 0 family mpls
set interfaces ge-0/0/2 unit 0 family inet address 192.168.37.7/24
set interfaces ge-0/0/2 unit 0 family mpls
set interfaces ge-0/0/3 unit 0 family inet address 192.168.67.7/24
set interfaces ge-0/0/3 unit 0 family mpls
set interfaces lo0 unit 0 family inet address 10.255.0.7/32
set routing-options srlg srlg-a srlg-value 101
set routing-options srlg srlg-a srlg-cost 10
set protocols rsvp interface ge-0/0/1.0
set protocols rsvp interface ge-0/0/2.0
set protocols rsvp interface ge-0/0/3.0
set protocols mpls interface ge-0/0/1.0
set protocols mpls interface ge-0/0/2.0
set protocols mpls interface ge-0/0/3.0
set protocols ospf traffic-engineering
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
set protocols ospf area 0.0.0.0 interface ge-0/0/2.0
set protocols ospf area 0.0.0.0 interface ge-0/0/3.0
set protocols ospf area 0.0.0.0 interface lo0.0

Configuring Device PE1

Step-by-Step The following example requires you to navigate various levels in the configuration
Procedure hierarchy. For information about navigating the CLI, see the Junos OS CLI User Guide.

To configure the ingress router PE1:

1. Configure the device interfaces.

[edit interfaces]
user@PE1# set ge-0/0/1 unit 0 family inet address 192.168.12.1/24
user@PE1# set ge-0/0/1 unit 0 family mpls
user@PE1# set ge-0/0/2 unit 0 family inet address 192.168.13.1/24
user@PE1# set ge-0/0/2 unit 0 family mpls
user@PE1# set ge-0/0/3 unit 0 family inet address 192.168.14.1/24
user@PE1# set ge-0/0/3 unit 0 family mpls
user@PE1# set lo0 unit 0 family inet address 10.255.0.1/32

2. Configure OSPF on the interfaces.

[edit protocols ospf]

user@PE1# set traffic-engineering
user@PE1# set area 0.0.0.0 interface ge-0/0/1.0
user@PE1# set area 0.0.0.0 interface ge-0/0/2.0
user@PE1# set area 0.0.0.0 interface ge-0/0/3.0
user@PE1# set area 0.0.0.0 interface lo0.0

3. Configure the SRLG definitions.

[edit routing-options]
user@PE1# set routing-options srlg srlg-a srlg-value 101
user@PE1# set routing-options srlg srlg-a srlg-cost 10

94 Copyright © 2012, Juniper Networks, Inc.

 Chapter 4: MPLS Router Configuration Guidelines

4. Configure MPLS and the LSPs and configure link protection for the pe1-pe2 LSP.

[edit protocols mpls]

user@PE1# set interface ge-0/0/1.0
user@PE1# set interface ge-0/0/2.0
user@PE1# set interface ge-0/0/3.0
user@PE1# set optimize-timer 120
user@PE1# set label-switched-path pe1-pe2 to 10.255.0.7
user@PE1# set protocols mpls label-switched-path pe1-pe2 link-protection
user@PE1# set label-switched-path pe1-pe2 primary via-p1
user@PE1# set label-switched-path pe1-pe2 secondary path2 standby
user@PE1# set path via-p1 10.255.0.2 strict
user@PE1# set path path2

5. Enable RSVP on the interfaces.

[edit protocols rsvp]

user@PE1# set interface ge-0/0/1.0
user@PE1# set interface ge-0/0/2.0
user@PE1# set interface ge-0/0/3.0

Results From configuration mode, confirm your configuration by entering the show interfaces,
show protocols ospf, show routing-options, show protocols mpls, and show protocols rsvp
commands. If the output does not display the intended configuration, repeat the
instructions in this example to correct the configuration.

user@PE1# show interfaces

ge-0/0/1 {
unit 0 {
family inet {
address 192.168.12.1/24;
}
family mpls;
}
}
ge-0/0/2 {
unit 0 {
family inet {
address 192.168.13.1/24;
}
family mpls;
}
}
ge-0/0/3 {
unit 0 {
family inet {
address 192.168.14.1/24;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 10.255.0.1/32;
}

Copyright © 2012, Juniper Networks, Inc. 95

Junos OS 12.1 MPLS Applications Configuration Guide

}
}
}

user@PE1# show protocols ospf

traffic-engineering;
area 0.0.0.0 {
interface ge-0/0/1.0;
interface ge-0/0/2.0;
interface ge-0/0/3.0;
interface lo0.0;
}

user@PE1# show protocols mpls

optimize-timer 120;
label-switched-path pe1-pe2 {
to 10.255.0.7;
link-protection;
primary via-p1;
secondary path2 {
standby;
}
}
path via-p1 {
10.255.0.2 strict;
}
path path2;
interface ge-0/0/1.0;
interface ge-0/0/2.0;
interface ge-0/0/3.0;

user@PE1# show protocols rsvp

interface ge-0/0/1.0;
interface ge-0/0/2.0;
interface ge-0/0/3.0;

user@PE1# show routing-options

srlg {
srlg-a {
srlg-value 101;
srlg-cost 10;
}
}

If you are done configuring the device, enter commit from configuration mode.

Configuring Device P1

Step-by-Step The following example requires you to navigate various levels in the configuration
Procedure hierarchy. For information about navigating the CLI, see the Junos OS CLI User Guide.

To configure device P1:

1. Configure the device interfaces.

[edit interfaces]
user@P1# set ge-0/0/1 unit 0 family inet address 192.168.12.2/24
user@P1# set ge-0/0/1 unit 0 family mpls

96 Copyright © 2012, Juniper Networks, Inc.

 Chapter 4: MPLS Router Configuration Guidelines

user@P1# set ge-0/0/2 unit 0 family inet address 192.168.27.2/24

user@P1# set ge-0/0/2 unit 0 family mpls
user@P1# set ge-0/0/3 unit 0 family inet address 192.168.23.2/24
user@P1# set ge-0/0/3 unit 0 family mpls
user@P1# set ge-0/0/4 unit 0 family inet address 192.168.25.2/24
user@P1# set ge-0/0/4 unit 0 family mpls
user@P1# set lo0 unit 0 family inet address 10.255.0.2/32

2. Configure OSPF on the interfaces.

[edit protocols ospf]

user@P1# set traffic-engineering
user@P1# set area 0.0.0.0 interface ge-0/0/1.0
user@P1# set area 0.0.0.0 interface ge-0/0/2.0
user@P1# set area 0.0.0.0 interface ge-0/0/3.0
user@P1# set area 0.0.0.0 interface ge-0/0/4.0
user@P1# set area 0.0.0.0 interface lo0.0

3. Configure the SRLG definitions.

[edit routing-options]
user@P1# set routing-options srlg srlg-a srlg-value 101
user@P1# set routing-options srlg srlg-a srlg-cost 10

4. Configure MPLS on the interfaces and associate the SRLG srlg-a with interface
ge-0/0/2.0 for the P1>PE2 link.

[edit protocols mpls]

user@P1# set interface ge-0/0/1.0
user@P1# set interface ge-0/0/2.0 srlg srlg-a
user@P1# set interface ge-0/0/3.0
user@P1# set interface ge-0/0/4.0

5. Enable RSVP on the interfaces and configure link-protection for interface ge-0/0/2.0.

[edit protocols rsvp]

user@P1# set interface ge-0/0/1.0
user@P1# set interface ge-0/0/2.0 link-protection
user@P1# set interface ge-0/0/3.0
user@P1# set interface ge-0/0/4.0

Results From configuration mode, confirm your configuration by entering the show interfaces,
show protocols ospf, show protocols mpls, show protocols rsvp, and show routing-options
commands. If the output does not display the intended configuration, repeat the
instructions in this example to correct the configuration.

user@P1# show interfaces

ge-0/0/1 {
unit 0 {
family inet {
address 192.168.12.2/24;
}
family mpls;
}
}
ge-0/0/2 {
unit 0 {
family inet {

Copyright © 2012, Juniper Networks, Inc. 97

Junos OS 12.1 MPLS Applications Configuration Guide

address 192.168.27.2/24;
}
family mpls;
}
}
ge-0/0/3 {
unit 0 {
family inet {
address 192.168.23.2/24;
}
family mpls;
}
}
ge-0/0/4 {
unit 0 {
family inet {
address 192.168.25.2/24;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 10.255.0.2/32;
}
}
}

user@P1# show protocols ospf

traffic-engineering;
area 0.0.0.0 {
interface ge-0/0/1.0;
interface ge-0/0/2.0;
interface ge-0/0/3.0;
interface ge-0/0/4.0;
interface lo0.0;
}

user@P1# show protocols mpls

interface ge-0/0/1.0;
interface ge-0/0/2.0 {
srlg srlg-a;
}
interface ge-0/0/3.0;
interface ge-0/0/4.0;

user@P1# show protocols rsvp

interface ge-0/0/1.0;
interface ge-0/0/2.0 {
link-protection;
}
interface ge-0/0/3.0;
interface ge-0/0/4.0;

user@P1# show routing-options

srlg {

98 Copyright © 2012, Juniper Networks, Inc.

 Chapter 4: MPLS Router Configuration Guidelines

srlg-a {
srlg-value 101;
srlg-cost 10;
}
}

If you are done configuring the device, enter commit from configuration mode.

Configuring Device P2

Step-by-Step The following example requires you to navigate various levels in the configuration
Procedure hierarchy. For information about navigating the CLI, see the Junos OS CLI User Guide.

To configure P2:

1. Configure the device interfaces.

[edit interfaces]
user@P2# set ge-0/0/1 unit 0 family inet address 192.168.13.3/24
user@P2# set ge-0/0/1 unit 0 family mpls
user@P2# set ge-0/0/2 unit 0 family inet address 192.168.37.3/24
user@P2# set ge-0/0/2 unit 0 family mpls
user@P2# set ge-0/0/3 unit 0 family inet address 192.168.23.3/24
user@P2# set ge-0/0/3 unit 0 family mpls
user@P2# set lo0 unit 0 family inet address 10.255.0.3/32

2. Configure OSPF on the interfaces.

[edit protocols ospf]

user@P2# set traffic-engineering
user@P2# set area 0.0.0.0 interface ge-0/0/1.0
user@P2# set area 0.0.0.0 interface ge-0/0/2.0
user@P2# set area 0.0.0.0 interface ge-0/0/3.0
user@P2# set area 0.0.0.0 interface lo0.0

3. Configure the SRLG definitions.

[edit routing-options]
user@P2# set routing-options srlg srlg-a srlg-value 101
user@P2# set routing-options srlg srlg-a srlg-cost 10

4. Configure MPLS on the interfaces and associate the SRLG srlg-a with interface
ge-0/0/2.0 for the P2>PE2 link.

[edit protocols mpls]

user@P2# set interface ge-0/0/1.0
user@P2# set interface ge-0/0/2.0 srlg srlg-a
user@P2# set interface ge-0/0/3.0

5. Enable RSVP on the interfaces.

[edit protocols rsvp]

user@P2# set interface ge-0/0/1.0
user@P2# set interface ge-0/0/2.0
user@P2# set interface ge-0/0/3.0

Results From configuration mode, confirm your configuration by entering the show interfaces,
show protocols ospf, show protocols mpls, show protocols rsvp, and show routing-options

Copyright © 2012, Juniper Networks, Inc. 99

Junos OS 12.1 MPLS Applications Configuration Guide

commands. If the output does not display the intended configuration, repeat the
instructions in this example to correct the configuration.

user@P2# show interfaces

ge-0/0/1 {
unit 0 {
family inet {
address 192.168.13.3/24;
}
family mpls;
}
}
ge-0/0/2 {
unit 0 {
family inet {
address 192.168.37.3/24;
}
family mpls;
}
}
ge-0/0/3 {
unit 0 {
family inet {
address 192.168.23.3/24;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 10.255.0.3/32;
}
}
}
}

user@P2# show protocols ospf

traffic-engineering;
area 0.0.0.0 {
interface ge-0/0/1.0;
interface ge-0/0/2.0;
interface ge-0/0/3.0;
interface lo0.0;
}

user@P2# show protocols mpls

interface ge-0/0/1.0;
interface ge-0/0/2.0 {
srlg srlg-a;
}
interface ge-0/0/3.0;
}

user@P2# show protocols rsvp

interface ge-0/0/1.0;
interface ge-0/0/2.0;

100 Copyright © 2012, Juniper Networks, Inc.

 Chapter 4: MPLS Router Configuration Guidelines

interface ge-0/0/3.0;

user@P2# show routing-options

srlg {
srlg-a {
srlg-value 101;
srlg-cost 10;
}
}

If you are done configuring the device, enter commit from configuration mode.

Configuring Device P3

Step-by-Step The following example requires you to navigate various levels in the configuration
Procedure hierarchy. For information about navigating the CLI, see the Junos OS CLI User Guide.

To configure P3:

1. Configure the device interfaces.

[edit interfaces]
user@P3# set ge-0/0/1 unit 0 family inet address 192.168.14.4/24
user@P3# set ge-0/0/1 unit 0 family mpls
user@P3# set ge-0/0/2 unit 0 family inet address 192.168.45.4/24
user@P3# set ge-0/0/2 unit 0 family mpls
user@P3# set lo0 unit 0 family inet address 10.255.0.4/32

2. Configure OSPF on the interfaces.

[edit protocols ospf]

user@P3# set traffic-engineering
user@P3# set area 0.0.0.0 interface ge-0/0/1.0
user@P3# set area 0.0.0.0 interface ge-0/0/2.0
user@P3# set area 0.0.0.0 interface lo0.0

3. Configure the SRLG definitions.

[edit routing-options]
user@P3# set routing-options srlg srlg-a srlg-value 101
user@P3# set routing-options srlg srlg-a srlg-cost 10

4. Configure MPLS on the interfaces.

[edit protocols mpls]

user@P3# set interface ge-0/0/1.0
user@P3# set interface ge-0/0/2.0

5. Enable RSVP on the interfaces.

[edit protocols rsvp]

user@P3# set interface ge-0/0/1.0
user@P3# set interface ge-0/0/2.0

Results From configuration mode, confirm your configuration by entering the show interfaces,
show protocols ospf, show protocols mpls, show protocols rsvp, and show routing-options
commands. If the output does not display the intended configuration, repeat the
instructions in this example to correct the configuration.

Copyright © 2012, Juniper Networks, Inc. 101

Junos OS 12.1 MPLS Applications Configuration Guide

user@P3# show interfaces

interfaces {
ge-0/0/1 {
unit 0 {
family inet {
address 192.168.14.4/24;
}
family mpls;
}
}
ge-0/0/2 {
unit 0 {
family inet {
address 192.168.45.4/24;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 10.255.0.4/32;
}
}
}
}

user@P3# show protocols ospf

traffic-engineering;
area 0.0.0.0 {
interface ge-0/0/1.0;
interface ge-0/0/2.0;
interface lo0.0;
}

user@P3# show protocols mpls

interface ge-0/0/1.0;
interface ge-0/0/2.0;

user@P3# show protocols rsvp

interface ge-0/0/1.0;
interface ge-0/0/2.0;

user@P3# show routing-options

srlg {
srlg-a {
srlg-value 101;
srlg-cost 10;
}
}

If you are done configuring the device, enter commit from configuration mode.

102 Copyright © 2012, Juniper Networks, Inc.

 Chapter 4: MPLS Router Configuration Guidelines

Configuring Device P4

Step-by-Step The following example requires you to navigate various levels in the configuration
Procedure hierarchy. For information about navigating the CLI, see the Junos OS CLI User Guide.

To configure P4:

1. Configure the device interfaces.

[edit interfaces]
user@P4# set ge-0/0/1 unit 0 family inet address 192.168.45.5/24
user@P4# set ge-0/0/1 unit 0 family mpls
user@P4# set ge-0/0/2 unit 0 family inet address 192.168.56.5/24
user@P4# set ge-0/0/2 unit 0 family mpls
user@P4# set ge-0/0/3 unit 0 family inet address 192.168.25.5/24
user@P4# set ge-0/0/3 unit 0 family mpls
user@P4# set lo0 unit 0 family inet address 10.255.0.5/32

2. Configure OSPF on the interfaces.

[edit protocols ospf]

user@P4# set traffic-engineering
user@P4# set area 0.0.0.0 interface ge-0/0/1.0
user@P4# set area 0.0.0.0 interface ge-0/0/2.0
user@P4# set area 0.0.0.0 interface ge-0/0/3.0
user@P4# set area 0.0.0.0 interface lo0.0

3. Configure the SRLG definitions.

[edit routing-options]
user@P4# set routing-options srlg srlg-a srlg-value 101
user@P4# set routing-options srlg srlg-a srlg-cost 10

4. Configure MPLS on the interfaces.

[edit protocols mpls]

user@P4# set interface ge-0/0/1.0
user@P4# set interface ge-0/0/2.0
user@P4# set interface ge-0/0/3.0

5. Enable RSVP on the interfaces.

[edit protocols rsvp]

user@P4# set interface ge-0/0/1.0
user@P4# set interface ge-0/0/2.0
user@P4# set interface ge-0/0/3.0

Results From configuration mode, confirm your configuration by entering the show interfaces,
show protocols ospf, show protocols mpls, show protocols rsvp, and show routing-options
commands. If the output does not display the intended configuration, repeat the
instructions in this example to correct the configuration.

user@P4# show interfaces

ge-0/0/1 {
unit 0 {
family inet {
address 192.168.45.5/24;
}

Copyright © 2012, Juniper Networks, Inc. 103

Junos OS 12.1 MPLS Applications Configuration Guide

family mpls;
}
}
ge-0/0/2 {
unit 0 {
family inet {
address 192.168.56.5/24;
}
family mpls;
}
}
ge-0/0/3 {
unit 0 {
family inet {
address 192.168.25.5/24;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 10.255.0.5/32;
}
}
}

user@P4# show protocols ospf

traffic-engineering;
area 0.0.0.0 {
interface ge-0/0/1.0;
interface ge-0/0/2.0;
interface ge-0/0/3.0;
interface lo0.0;
}

user@P4# show protocols mpls

interface ge-0/0/1.0;
interface ge-0/0/2.0;
interface ge-0/0/3.0;

user@P4# show protocols rsvp

interface ge-0/0/1.0;
interface ge-0/0/2.0;
interface ge-0/0/3.0;

user@P4# show routing-options

srlg {
srlg-a {
srlg-value 101;
srlg-cost 10;
}
}

If you are done configuring the device, enter commit from configuration mode.

104 Copyright © 2012, Juniper Networks, Inc.

 Chapter 4: MPLS Router Configuration Guidelines

Configuring Device P5

Step-by-Step The following example requires you to navigate various levels in the configuration
Procedure hierarchy. For information about navigating the CLI, see the Junos OS CLI User Guide.

To configure P5:

1. Configure the device interfaces.

[edit interfaces]
user@P5# set ge-0/0/1 unit 0 family inet address 192.168.56.6/24
user@P5# set ge-0/0/1 unit 0 family mpls
user@P5# set ge-0/0/2 unit 0 family inet address 192.168.67.6/24
user@P5# set ge-0/0/2 unit 0 family mpls
user@P5# set lo0 unit 0 family inet address 10.255.0.6/32

2. Configure OSPF on the interfaces.

[edit protocols ospf]

user@P5# set traffic-engineering
user@P5# set area 0.0.0.0 interface ge-0/0/1.0
user@P5# set area 0.0.0.0 interface ge-0/0/2.0
user@P5# set area 0.0.0.0 interface lo0.0

3. Configure the SRLG definitions.

[edit routing-options]
user@P5# set routing-options srlg srlg-a srlg-value 101
user@P5# set routing-options srlg srlg-a srlg-cost 10

4. Configure MPLS on the interfaces.

[edit protocols mpls]

user@P5# set interface ge-0/0/1.0
user@P5# set interface ge-0/0/2.0

5. Enable RSVP on the interfaces.

[edit protocols rsvp]

user@P5# set interface ge-0/0/1.0
user@P5# set interface ge-0/0/2.0

Results From configuration mode, confirm your configuration by entering the show interfaces,
show protocols ospf, show protocols mpls, show protocols rsvp, and show routing-options
commands. If the output does not display the intended configuration, repeat the
instructions in this example to correct the configuration.

user@P5# show interfaces

ge-0/0/1 {
unit 0 {
family inet {
address 192.168.56.6/24;
}
family mpls;
}
}
ge-0/0/2 {
unit 0 {

Copyright © 2012, Juniper Networks, Inc. 105

Junos OS 12.1 MPLS Applications Configuration Guide

family inet {
address 192.168.67.6/24;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 10.255.0.6/32;
}
}
}

user@P5# show protocols ospf

traffic-engineering;
area 0.0.0.0 {
interface ge-0/0/1.0;
interface ge-0/0/2.0;
interface lo0.0;
}

user@P5# show protocols mpls

interface ge-0/0/1.0;
interface ge-0/0/2.0;

user@P5# show protocols rsvp

interface ge-0/0/1.0;
interface ge-0/0/2.0;

user@P5# show routing-options

srlg {
srlg-a {
srlg-value 101;
srlg-cost 10;
}
}

If you are done configuring the device, enter commit from configuration mode.

Configuring Device PE2

Step-by-Step The following example requires you to navigate various levels in the configuration
Procedure hierarchy. For information about navigating the CLI, see the Junos OS CLI User Guide.

To configure PE2:

1. Configure the device interfaces.

[edit interfaces]
user@PE2# set ge-0/0/1 unit 0 family inet address 192.168.27.7/24
user@PE2# set ge-0/0/1 unit 0 family mpls
user@PE2# set ge-0/0/2 unit 0 family inet address 192.168.37.7/24
user@PE2# set ge-0/0/2 unit 0 family mpls
user@PE2# set ge-0/0/3 unit 0 family inet address 192.168.67.7/24
user@PE2# set ge-0/0/3 unit 0 family mpls
user@PE2# set lo0 unit 0 family inet address 10.255.0.7/32

106 Copyright © 2012, Juniper Networks, Inc.

 Chapter 4: MPLS Router Configuration Guidelines

2. Configure OSPF on the interfaces.

[edit protocols ospf]

user@PE2# set traffic-engineering
user@PE2# set area 0.0.0.0 interface ge-0/0/1.0
user@PE2# set area 0.0.0.0 interface ge-0/0/2.0
user@PE2# set area 0.0.0.0 interface ge-0/0/3.0
user@PE2# set area 0.0.0.0 interface lo0.0

3. Configure the SRLG definitions.

[edit routing-options]
user@PE2# set routing-options srlg srlg-a srlg-value 101
user@PE2# set routing-options srlg srlg-a srlg-cost 10

4. Configure MPLS on the interfaces.

[edit protocols mpls]

user@PE2# set interface ge-0/0/1.0
user@PE2# set interface ge-0/0/2.0
user@PE2# set interface ge-0/0/3.0

5. Enable RSVP on the interfaces.

[edit protocols rsvp]

user@PE2# set interface ge-0/0/1.0
user@PE2# set interface ge-0/0/2.0
user@PE2# set interface ge-0/0/3.0

Results From configuration mode, confirm your configuration by entering the show interfaces,
show protocols ospf, show protocols mpls, show protocols rsvp, and show routing-options
commands. If the output does not display the intended configuration, repeat the
instructions in this example to correct the configuration.

user@PE2# show interfaces

interfaces {
ge-0/0/1 {
unit 0 {
family inet {
address 192.168.27.7/24;
}
family mpls;
}
}
ge-0/0/2 {
unit 0 {
family inet {
address 192.168.37.7/24;
}
family mpls;
}
}
ge-0/0/3 {
unit 0 {
family inet {
address 192.168.67.7/24;
}

Copyright © 2012, Juniper Networks, Inc. 107

Junos OS 12.1 MPLS Applications Configuration Guide

family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 10.255.0.7/32;
}
}
}
}

user@PE2# show protocols ospf

traffic-engineering;
area 0.0.0.0 {
interface ge-0/0/1.0;
interface ge-0/0/2.0;
interface ge-0/0/3.0;
interface lo0.0;
}

user@PE2# show protocols mpls

interface ge-0/0/1.0;
interface ge-0/0/2.0;
interface ge-0/0/3.0;

user@PE2# show protocols rsvp

interface ge-0/0/1.0;
interface ge-0/0/2.0;
interface ge-0/0/3.0;

user@PE2# show routing-options

srlg {
srlg-a {
srlg-value 101;
srlg-cost 10;
}
}

If you are done configuring the device, enter commit from configuration mode.

Verification
Confirm that the configuration is working properly.

Verifying the SRLG Cost Is Added to the TE Link

Purpose Verify that the SRLG cost is added to the TE link if it belongs to the SRLG of the protected
link. Issue the show ted link detail and show rsvp session extensive bypass commands on
device P1.

Action user@P1> show ted link detail

...
10.255.0.2->192.168.27.7-1, Local: 192.168.27.2, Remote: 0.0.0.0
Local interface index: 0, Remote interface index: 0
LocalPath: 0, Metric: 1, StaticBW: 1000Mbps, AvailBW: 1000Mbps

108 Copyright © 2012, Juniper Networks, Inc.

 Chapter 4: MPLS Router Configuration Guidelines

Color: 0 <none>
SRLGs: srlg-a
localBW [0] 0bps [1] 0bps [2] 0bps [3] 0bps
localBW [4] 0bps [5] 0bps [6] 0bps [7] 0bps
[...]
10.255.0.3->192.168.37.7-1, Local: 192.168.37.3, Remote: 0.0.0.0
Local interface index: 0, Remote interface index: 0
LocalPath: 0, Metric: 1, StaticBW: 1000Mbps, AvailBW: 1000Mbps
Color: 0 <none>
SRLGs: srlg-a
localBW [0] 0bps [1] 0bps [2] 0bps [3] 0bps
localBW [4] 0bps [5] 0bps [6] 0bps [7] 0bps
...

user@P1> show rsvp session extensive bypass

Ingress RSVP: 1 sessions

10.255.0.7
From: 10.255.0.2, LSPstate: Up, ActiveRoute: 0
LSPname: Bypass->192.168.27.7
LSPtype: Static Configured
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: 299776
Resv style: 1 SE, Label in: -, Label out: 299776
Time left: -, Since: Fri Oct 21 13:19:21 2011
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 1 receiver 52081 protocol 0
Type: Bypass LSP
Number of data route tunnel through: 1
Number of RSVP session tunnel through: 0
PATH rcvfrom: localclient
Adspec: sent MTU 1500
Path MTU: received 1500
PATH sentto: 192.168.25.5 (ge-0/0/4.0) 26 pkts
RESV rcvfrom: 192.168.25.5 (ge-0/0/4.0) 26 pkts
Explct route: 192.168.25.5 192.168.56.6 192.168.67.7
Record route: <self> 192.168.25.5 192.168.56.6 192.168.67.7
Total 1 displayed, Up 1, Down 0

Meaning The shortest path for the bypass protecting the link P1->PE2 would have been
P1->P2->PE2. Because the links P1>PE2 and P2>PE2 both belong to SRLG srlg-a, the
SRLG cost of 10 for srlg-a is added to the metric for the link P2>PE2. This makes the
metric for the link P2>PE2 too high to be selected for the shortest path. Therefore, the
CSPF result for the computed path for the bypass becomes P1>P4>P5>PE2.

Related • SRLG Overview on page 36

Documentation
• Example: Configuring SRLG on page 76

• Example: Configuring SRLG With Link Protection With the exclude-srlg Option on
page 110

Copyright © 2012, Juniper Networks, Inc. 109

Junos OS 12.1 MPLS Applications Configuration Guide

Example: Configuring SRLG With Link Protection With the exclude-srlg Option

This example shows how to configure SRLG with link protection with the exclude-srlg
option.

• Requirements on page 110

• Overview on page 110
• Configuration on page 111
• Verification on page 128

Requirements
This example uses the following hardware and software components:

• M Series, MX Series, or T Series devices

• Junos OS Release 11.4 or later running on all the devices

Overview
In this example, PE1 is the ingress router and PE2 is the egress router. P1, P2, and P3, P4,
and P5 are transit routers. OSPF is configured on all the routers as the interior gateway
protocol (IGP). SRLG is configured on all seven routers. The link P1>PE2 (primary path)
and the link P2>PE2 belong to SRLG srlg-a.

You configure link protection for the interface P1>PE2 by including the link-protection
statement along with the exclude-srlg option. This makes the bypass LSP and the
protected link completely disjoint in any SRLG.

110 Copyright © 2012, Juniper Networks, Inc.

 Chapter 4: MPLS Router Configuration Guidelines

When SRLG srlg-a is configured on the link P1>PE2 and P2>PE2, the link P2>PE2 is
rejected for CSPF consideration due to the exclude-srlg configuration. Therefore, the
computed path for the bypass becomes P1>P4>P5>PE2.

Primary path
Secondary path

P2
srlg-a

PE1 P1 PE2
srlg-a

P3 P4 P5

g040926
Configuration
CLI Quick To quickly configure this section of the example, copy the following commands, paste
Configuration them into a text file, remove any line breaks, change any details necessary to match your
network configuration, and then copy and paste the commands into the CLI at the [edit]
hierarchy level.

Router PE1 set interfaces ge-0/0/1 unit 0 family inet address 192.168.12.1/24
set interfaces ge-0/0/1 unit 0 family mpls
set interfaces ge-0/0/2 unit 0 family inet address 192.168.13.1/24
set interfaces ge-0/0/2 unit 0 family mpls
set interfaces ge-0/0/3 unit 0 family inet address 192.168.14.1/24
set interfaces ge-0/0/3 unit 0 family mpls
set interfaces lo0 unit 0 family inet address 10.255.0.1/32
set routing-options srlg srlg-a srlg-value 101
set protocols rsvp interface ge-0/0/1.0
set protocols rsvp interface ge-0/0/2.0
set protocols rsvp interface ge-0/0/3.0
set protocols mpls optimize-timer 120
set protocols mpls label-switched-path pe1-pe2 to 10.255.0.7
set protocols mpls label-switched-path pe1-pe2 link-protection
set protocols mpls label-switched-path pe1-pe2 primary via-p1
set protocols mpls label-switched-path pe1-pe2 secondary path2 standby
set protocols mpls path via-p1 10.255.0.2 strict
set protocols mpls path path2
set protocols mpls interface ge-0/0/1.0
set protocols mpls interface ge-0/0/2.0
set protocols mpls interface ge-0/0/3.0

Copyright © 2012, Juniper Networks, Inc. 111

Junos OS 12.1 MPLS Applications Configuration Guide

set protocols ospf traffic-engineering

set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
set protocols ospf area 0.0.0.0 interface ge-0/0/2.0
set protocols ospf area 0.0.0.0 interface ge-0/0/3.0
set protocols ospf area 0.0.0.0 interface lo0.0

Router P1 set interfaces ge-0/0/1 unit 0 family inet address 192.168.12.2/24

set interfaces ge-0/0/1 unit 0 family mpls
set interfaces ge-0/0/2 unit 0 family inet address 192.168.27.2/24
set interfaces ge-0/0/2 unit 0 family mpls
set interfaces ge-0/0/3 unit 0 family inet address 192.168.23.2/24
set interfaces ge-0/0/3 unit 0 family mpls
set interfaces ge-0/0/4 unit 0 family inet address 192.168.25.2/24
set interfaces ge-0/0/4 unit 0 family mpls
set interfaces lo0 unit 0 family inet address 10.255.0.2/32
set routing-options srlg srlg-a srlg-value 101
set routing-options srlg srlg-a srlg-cost 10
set protocols rsvp interface ge-0/0/1.0
set protocols rsvp interface ge-0/0/2.0 link-protection exclude-srlg
set protocols mpls interface ge-0/0/1.0
set protocols mpls interface ge-0/0/2.0 srlg srlg-a
set protocols mpls interface ge-0/0/3.0
set protocols mpls interface ge-0/0/4.0
set protocols ospf traffic-engineering
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
set protocols ospf area 0.0.0.0 interface ge-0/0/2.0
set protocols ospf area 0.0.0.0 interface ge-0/0/3.0
set protocols ospf area 0.0.0.0 interface ge-0/0/4.0
set protocols ospf area 0.0.0.0 interface lo0.0

Router P2 set interfaces ge-0/0/1 unit 0 family inet address 192.168.13.3/24

set interfaces ge-0/0/1 unit 0 family mpls
set interfaces ge-0/0/2 unit 0 family inet address 192.168.37.3/24
set interfaces ge-0/0/2 unit 0 family mpls
set interfaces ge-0/0/3 unit 0 family inet address 192.168.23.3/24
set interfaces ge-0/0/3 unit 0 family mpls
set interfaces lo0 unit 0 family inet address 10.255.0.3/32
set routing-options srlg srlg-a srlg-value 101
set routing-options srlg srlg-a srlg-cost 10
set protocols rsvp interface ge-0/0/1.0
set protocols rsvp interface ge-0/0/2.0
set protocols rsvp interface ge-0/0/3.0
set protocols mpls interface ge-0/0/1.0
set protocols mpls interface ge-0/0/2.0 srlg srlg-a
set protocols mpls interface ge-0/0/3.0
set protocols ospf traffic-engineering
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
set protocols ospf area 0.0.0.0 interface ge-0/0/2.0
set protocols ospf area 0.0.0.0 interface ge-0/0/3.0
set protocols ospf area 0.0.0.0 interface lo0.0

Router P3 set interfaces ge-0/0/1 unit 0 family inet address 192.168.14.4/24

set interfaces ge-0/0/1 unit 0 family mpls
set interfaces ge-0/0/2 unit 0 family inet address 192.168.45.4/24
set interfaces ge-0/0/2 unit 0 family mpls

112 Copyright © 2012, Juniper Networks, Inc.

 Chapter 4: MPLS Router Configuration Guidelines

set interfaces lo0 unit 0 family inet address 10.255.0.4/32

set routing-options srlg srlg-a srlg-value 101
set routing-options srlg srlg-a srlg-cost 10
set protocols rsvp interface ge-0/0/1.0
set protocols rsvp interface ge-0/0/2.0
set protocols mpls interface ge-0/0/1.0
set protocols mpls interface ge-0/0/2.0
set protocols ospf traffic-engineering
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
set protocols ospf area 0.0.0.0 interface ge-0/0/2.0
set protocols ospf area 0.0.0.0 interface lo0.0

Router P4 set interfaces ge-0/0/1 unit 0 family inet address 192.168.45.5/24

set interfaces ge-0/0/1 unit 0 family mpls
set interfaces ge-0/0/2 unit 0 family inet address 192.168.56.5/24
set interfaces ge-0/0/2 unit 0 family mpls
set interfaces ge-0/0/3 unit 0 family inet address 192.168.25.5/24
set interfaces ge-0/0/3 unit 0 family mpls
set interfaces lo0 unit 0 family inet address 10.255.0.5/32
set routing-options srlg srlg-a srlg-value 101
set routing-options srlg srlg-a srlg-cost 10
set protocols rsvp interface ge-0/0/1.0
set protocols rsvp interface ge-0/0/2.0
set protocols rsvp interface ge-0/0/3.0
set protocols mpls interface ge-0/0/1.0
set protocols mpls interface ge-0/0/2.0
set protocols mpls interface ge-0/0/3.0
set protocols ospf traffic-engineering
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
set protocols ospf area 0.0.0.0 interface ge-0/0/2.0
set protocols ospf area 0.0.0.0 interface ge-0/0/3.0
set protocols ospf area 0.0.0.0 interface lo0.0

Router P5 set interfaces ge-0/0/1 unit 0 family inet address 192.168.56.6/24

set interfaces ge-0/0/1 unit 0 family mpls
set interfaces ge-0/0/2 unit 0 family inet address 192.168.67.6/24
set interfaces ge-0/0/2 unit 0 family mpls
set interfaces lo0 unit 0 family inet address 10.255.0.6/32
set routing-options srlg srlg-a srlg-value 101
set routing-options srlg srlg-a srlg-cost 10
set protocols rsvp interface ge-0/0/1.0
set protocols rsvp interface ge-0/0/2.0
set protocols mpls interface ge-0/0/1.0
set protocols mpls interface ge-0/0/2.0
set protocols ospf traffic-engineering
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
set protocols ospf area 0.0.0.0 interface ge-0/0/2.0
set protocols ospf area 0.0.0.0 interface lo0.0

Router PE2 set interfaces ge-0/0/1 unit 0 family inet address 192.168.27.7/24
set interfaces ge-0/0/1 unit 0 family mpls
set interfaces ge-0/0/2 unit 0 family inet address 192.168.37.7/24
set interfaces ge-0/0/2 unit 0 family mpls
set interfaces ge-0/0/3 unit 0 family inet address 192.168.67.7/24
set interfaces ge-0/0/3 unit 0 family mpls

Copyright © 2012, Juniper Networks, Inc. 113

Junos OS 12.1 MPLS Applications Configuration Guide

set interfaces lo0 unit 0 family inet address 10.255.0.7/32

set routing-options srlg srlg-a srlg-value 101
set routing-options srlg srlg-a srlg-cost 10
set protocols rsvp interface ge-0/0/1.0
set protocols rsvp interface ge-0/0/2.0
set protocols rsvp interface ge-0/0/3.0
set protocols mpls interface ge-0/0/1.0
set protocols mpls interface ge-0/0/2.0
set protocols mpls interface ge-0/0/3.0
set protocols ospf traffic-engineering
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
set protocols ospf area 0.0.0.0 interface ge-0/0/2.0
set protocols ospf area 0.0.0.0 interface ge-0/0/3.0
set protocols ospf area 0.0.0.0 interface lo0.0

Configuring Device PE1

Step-by-Step The following example requires you to navigate various levels in the configuration
Procedure hierarchy. For information about navigating the CLI, see the Junos OS CLI User Guide.

To configure the ingress router PE1:

1. Configure the device interfaces.

[edit interfaces]
user@PE1# set ge-0/0/1 unit 0 family inet address 192.168.12.1/24
user@PE1# set ge-0/0/1 unit 0 family mpls
user@PE1# set ge-0/0/2 unit 0 family inet address 192.168.13.1/24
user@PE1# set ge-0/0/2 unit 0 family mpls
user@PE1# set ge-0/0/3 unit 0 family inet address 192.168.14.1/24
user@PE1# set ge-0/0/3 unit 0 family mpls
user@PE1# set lo0 unit 0 family inet address 10.255.0.1/32

2. Configure OSPF on the interfaces.

[edit protocols ospf]

user@PE1# set traffic-engineering
user@PE1# set area 0.0.0.0 interface ge-0/0/1.0
user@PE1# set area 0.0.0.0 interface ge-0/0/2.0
user@PE1# set area 0.0.0.0 interface ge-0/0/3.0
user@PE1# set area 0.0.0.0 interface lo0.0

3. Configure the SRLG definitions.

[edit routing-options]
user@PE1# set routing-options srlg srlg-a srlg-value 101
user@PE1# set routing-options srlg srlg-a srlg-cost 10

4. Configure MPLS and the LSPs and configure link protection for the pe1-pe2 LSP.

[edit protocols mpls]

user@PE1# set interface ge-0/0/1.0
user@PE1# set interface ge-0/0/2.0
user@PE1# set interface ge-0/0/3.0
user@PE1# set optimize-timer 120
user@PE1# set label-switched-path pe1-pe2 to 10.255.0.7
user@PE1# set protocols mpls label-switched-path pe1-pe2 link-protection
user@PE1# set label-switched-path pe1-pe2 primary via-p1

114 Copyright © 2012, Juniper Networks, Inc.

 Chapter 4: MPLS Router Configuration Guidelines

user@PE1# set label-switched-path pe1-pe2 secondary path2 standby

user@PE1# set path via-p1 10.255.0.2 strict
user@PE1# set path path2

5. Enable RSVP on the interfaces.

[edit protocols rsvp]

user@PE1# set interface ge-0/0/1.0
user@PE1# set interface ge-0/0/2.0
user@PE1# set interface ge-0/0/3.0

Results From configuration mode, confirm your configuration by entering the show interfaces,
show protocols ospf, show routing-options, show protocols mpls, and show protocols rsvp
commands. If the output does not display the intended configuration, repeat the
instructions in this example to correct the configuration.

user@PE1# show interfaces

ge-0/0/1 {
unit 0 {
family inet {
address 192.168.12.1/24;
}
family mpls;
}
}
ge-0/0/2 {
unit 0 {
family inet {
address 192.168.13.1/24;
}
family mpls;
}
}
ge-0/0/3 {
unit 0 {
family inet {
address 192.168.14.1/24;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 10.255.0.1/32;
}
}
}
}

user@PE1# show protocols ospf

traffic-engineering;
area 0.0.0.0 {
interface ge-0/0/1.0;
interface ge-0/0/2.0;
interface ge-0/0/3.0;

Copyright © 2012, Juniper Networks, Inc. 115

Junos OS 12.1 MPLS Applications Configuration Guide

interface lo0.0;
}

user@PE1# show protocols mpls

optimize-timer 120;
label-switched-path pe1-pe2 {
to 10.255.0.7;
link-protection;
primary via-p1;
secondary path2 {
standby;
}
}
path via-p1 {
10.255.0.2 strict;
}
path path2;
interface ge-0/0/1.0;
interface ge-0/0/2.0;
interface ge-0/0/3.0;

user@PE1# show protocols rsvp

interface ge-0/0/1.0;
interface ge-0/0/2.0;
interface ge-0/0/3.0;

user@PE1# show routing-options

srlg {
srlg-a {
srlg-value 101;
srlg-cost 10;
}
}

If you are done configuring the device, enter commit from configuration mode.

Configuring Device P1

Step-by-Step The following example requires you to navigate various levels in the configuration
Procedure hierarchy. For information about navigating the CLI, see the Junos OS CLI User Guide.

To configure device P1:

1. Configure the device interfaces.

[edit interfaces]
user@P1# set ge-0/0/1 unit 0 family inet address 192.168.12.2/24
user@P1# set ge-0/0/1 unit 0 family mpls
user@P1# set ge-0/0/2 unit 0 family inet address 192.168.27.2/24
user@P1# set ge-0/0/2 unit 0 family mpls
user@P1# set ge-0/0/3 unit 0 family inet address 192.168.23.2/24
user@P1# set ge-0/0/3 unit 0 family mpls
user@P1# set ge-0/0/4 unit 0 family inet address 192.168.25.2/24
user@P1# set ge-0/0/4 unit 0 family mpls
user@P1# set lo0 unit 0 family inet address 10.255.0.2/32

2. Configure OSPF on the interfaces.

116 Copyright © 2012, Juniper Networks, Inc.

 Chapter 4: MPLS Router Configuration Guidelines

[edit protocols ospf]

user@P1# set traffic-engineering
user@P1# set area 0.0.0.0 interface ge-0/0/1.0
user@P1# set area 0.0.0.0 interface ge-0/0/2.0
user@P1# set area 0.0.0.0 interface ge-0/0/3.0
user@P1# set area 0.0.0.0 interface ge-0/0/4.0
user@P1# set area 0.0.0.0 interface lo0.0

3. Configure the SRLG definitions.

[edit routing-options]
user@P1# set routing-options srlg srlg-a srlg-value 101
user@P1# set routing-options srlg srlg-a srlg-cost 10

4. Configure MPLS on the interfaces and associate the SRLG with interface ge-0/0/2.0
for the P1>PE2 link.

[edit protocols mpls]

user@P1# set interface ge-0/0/1.0
user@P1# set interface ge-0/0/2.0 srlg srlg-a
user@P1# set interface ge-0/0/3.0
user@P1# set interface ge-0/0/4.0

5. Enable RSVP on the interfaces and include the link-protection statement with the
exclude-srlg option for interface ge-0/0/2.0.

[edit protocols rsvp]

user@P1# set interface ge-0/0/1.0
user@P1# set interface ge-0/0/2.0 link-protection exclude-srlg
user@P1# set interface ge-0/0/3.0
user@P1# set interface ge-0/0/4.0

Results From configuration mode, confirm your configuration by entering the show interfaces,
show protocols ospf, show protocols mpls, show protocols rsvp, and show routing-options
commands. If the output does not display the intended configuration, repeat the
instructions in this example to correct the configuration.

user@P1# show interfaces

ge-0/0/1 {
unit 0 {
family inet {
address 192.168.12.2/24;
}
family mpls;
}
}
ge-0/0/2 {
unit 0 {
family inet {
address 192.168.27.2/24;
}
family mpls;
}
}
ge-0/0/3 {
unit 0 {
family inet {

Copyright © 2012, Juniper Networks, Inc. 117

Junos OS 12.1 MPLS Applications Configuration Guide

address 192.168.23.2/24;
}
family mpls;
}
}
ge-0/0/4 {
unit 0 {
family inet {
address 192.168.25.2/24;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 10.255.0.2/32;
}
}
}

user@P1# show protocols ospf

traffic-engineering;
area 0.0.0.0 {
interface ge-0/0/1.0;
interface ge-0/0/2.0;
interface ge-0/0/3.0;
interface ge-0/0/4.0;
interface lo0.0;
}

user@P1# show protocols mpls

interface ge-0/0/1.0;
interface ge-0/0/2.0 {
srlg srlg-a;
}
interface ge-0/0/3.0;
interface ge-0/0/4.0;

user@P1# show protocols rsvp

interface ge-0/0/1.0;
interface ge-0/0/2.0 {
link-protection {
exclude-srlg;
}
interface ge-0/0/3.0;
interface ge-0/0/4.0;
}

user@P1# show routing-options

srlg {
srlg-a {
srlg-value 101;
srlg-cost 10;
}
}

If you are done configuring the device, enter commit from configuration mode.

118 Copyright © 2012, Juniper Networks, Inc.

 Chapter 4: MPLS Router Configuration Guidelines

Configuring Device P2

Step-by-Step The following example requires you to navigate various levels in the configuration
Procedure hierarchy. For information about navigating the CLI, see the Junos OS CLI User Guide.

To configure P2:

1. Configure the device interfaces.

[edit interfaces]
user@P2# set ge-0/0/1 unit 0 family inet address 192.168.13.3/24
user@P2# set ge-0/0/1 unit 0 family mpls
user@P2# set ge-0/0/2 unit 0 family inet address 192.168.37.3/24
user@P2# set ge-0/0/2 unit 0 family mpls
user@P2# set ge-0/0/3 unit 0 family inet address 192.168.23.3/24
user@P2# set ge-0/0/3 unit 0 family mpls
user@P2# set lo0 unit 0 family inet address 10.255.0.3/32

2. Configure OSPF on the interfaces.

[edit protocols ospf]

user@P2# set traffic-engineering
user@P2# set area 0.0.0.0 interface ge-0/0/1.0
user@P2# set area 0.0.0.0 interface ge-0/0/2.0
user@P2# set area 0.0.0.0 interface ge-0/0/3.0
user@P2# set area 0.0.0.0 interface lo0.0

3. Configure the SRLG definitions.

[edit routing-options]
user@P2# set routing-options srlg srlg-a srlg-value 101
user@P2# set routing-options srlg srlg-a srlg-cost 10

4. Configure MPLS on the interfaces and associate the SRLG with interface ge-0/0/2.0
for the P2>PE2 link.

[edit protocols mpls]

user@P2# set interface ge-0/0/1.0
user@P2# set interface ge-0/0/2.0 srlg srlg-a
user@P2# set interface ge-0/0/3.0

5. Enable RSVP on the interfaces.

[edit protocols rsvp]

user@P2# set interface ge-0/0/1.0
user@P2# set interface ge-0/0/2.0
user@P2# set interface ge-0/0/3.0

Results From configuration mode, confirm your configuration by entering the show interfaces,
show protocols ospf, show protocols mpls, show protocols rsvp, and show routing-options
commands. If the output does not display the intended configuration, repeat the
instructions in this example to correct the configuration.

user@P2# show interfaces

ge-0/0/1 {
unit 0 {
family inet {

Copyright © 2012, Juniper Networks, Inc. 119

Junos OS 12.1 MPLS Applications Configuration Guide

address 192.168.13.3/24;
}
family mpls;
}
}
ge-0/0/2 {
unit 0 {
family inet {
address 192.168.37.3/24;
}
family mpls;
}
}
ge-0/0/3 {
unit 0 {
family inet {
address 192.168.23.3/24;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 10.255.0.3/32;
}
}
}
}

user@P2# show protocols ospf

traffic-engineering;
area 0.0.0.0 {
interface ge-0/0/1.0;
interface ge-0/0/2.0;
interface ge-0/0/3.0;
interface lo0.0;
}

user@P2# show protocols mpls

interface ge-0/0/1.0;
interface ge-0/0/2.0 {
srlg srlg-a;
}
interface ge-0/0/3.0;
}

user@P2# show protocols rsvp

interface ge-0/0/1.0;
interface ge-0/0/2.0;
interface ge-0/0/3.0;

user@P2# show routing-options

srlg {
srlg-a {
srlg-value 101;
srlg-cost 10;

120 Copyright © 2012, Juniper Networks, Inc.

 Chapter 4: MPLS Router Configuration Guidelines

}
}

If you are done configuring the device, enter commit from configuration mode.

Configuring Device P3

Step-by-Step The following example requires you to navigate various levels in the configuration
Procedure hierarchy. For information about navigating the CLI, see the Junos OS CLI User Guide.

To configure P3:

1. Configure the device interfaces.

[edit interfaces]
user@P3# set ge-0/0/1 unit 0 family inet address 192.168.14.4/24
user@P3# set ge-0/0/1 unit 0 family mpls
user@P3# set ge-0/0/2 unit 0 family inet address 192.168.45.4/24
user@P3# set ge-0/0/2 unit 0 family mpls
user@P3# set lo0 unit 0 family inet address 10.255.0.4/32

2. Configure OSPF on the interfaces.

[edit protocols ospf]

user@P3# set traffic-engineering
user@P3# set area 0.0.0.0 interface ge-0/0/1.0
user@P3# set area 0.0.0.0 interface ge-0/0/2.0
user@P3# set area 0.0.0.0 interface lo0.0

3. Configure the SRLG definitions.

[edit routing-options]
user@P3# set routing-options srlg srlg-a srlg-value 101
user@P3# set routing-options srlg srlg-a srlg-cost 10

4. Configure MPLS on the interfaces.

[edit protocols mpls]

user@P3# set interface ge-0/0/1.0
user@P3# set interface ge-0/0/2.0

5. Enable RSVP on the interfaces.

[edit protocols rsvp]

user@P3# set interface ge-0/0/1.0
user@P3# set interface ge-0/0/2.0

Results From configuration mode, confirm your configuration by entering the show interfaces,
show protocols ospf, show protocols mpls, show protocols rsvp, and show routing-options
commands. If the output does not display the intended configuration, repeat the
instructions in this example to correct the configuration.

user@P3# show interfaces

interfaces {
ge-0/0/1 {
unit 0 {
family inet {
address 192.168.14.4/24;

Copyright © 2012, Juniper Networks, Inc. 121

Junos OS 12.1 MPLS Applications Configuration Guide

}
family mpls;
}
}
ge-0/0/2 {
unit 0 {
family inet {
address 192.168.45.4/24;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 10.255.0.4/32;
}
}
}
}

user@P3# show protocols ospf

traffic-engineering;
area 0.0.0.0 {
interface ge-0/0/1.0;
interface ge-0/0/2.0;
interface lo0.0;
}

user@P3# show protocols mpls

interface ge-0/0/1.0;
interface ge-0/0/2.0;

user@P3# show protocols rsvp

interface ge-0/0/1.0;
interface ge-0/0/2.0;

user@P3# show routing-options

srlg {
srlg-a {
srlg-value 101;
srlg-cost 10;
}
}

If you are done configuring the device, enter commit from configuration mode.

Configuring Device P4

Step-by-Step The following example requires you to navigate various levels in the configuration
Procedure hierarchy. For information about navigating the CLI, see the Junos OS CLI User Guide.

To configure P4:

1. Configure the device interfaces.

[edit interfaces]
user@P4# set ge-0/0/1 unit 0 family inet address 192.168.45.5/24

122 Copyright © 2012, Juniper Networks, Inc.

 Chapter 4: MPLS Router Configuration Guidelines

user@P4# set ge-0/0/1 unit 0 family mpls

user@P4# set ge-0/0/2 unit 0 family inet address 192.168.56.5/24
user@P4# set ge-0/0/2 unit 0 family mpls
user@P4# set ge-0/0/3 unit 0 family inet address 192.168.25.5/24
user@P4# set ge-0/0/3 unit 0 family mpls
user@P4# set lo0 unit 0 family inet address 10.255.0.5/32

2. Configure OSPF on the interfaces.

[edit protocols ospf]

user@P4# set traffic-engineering
user@P4# set area 0.0.0.0 interface ge-0/0/1.0
user@P4# set area 0.0.0.0 interface ge-0/0/2.0
user@P4# set area 0.0.0.0 interface ge-0/0/3.0
user@P4# set area 0.0.0.0 interface lo0.0

3. Configure the SRLG definitions.

[edit routing-options]
user@P4# set routing-options srlg srlg-a srlg-value 101
user@P4# set routing-options srlg srlg-a srlg-cost 10

4. Configure MPLS on the interfaces.

[edit protocols mpls]

user@P4# set interface ge-0/0/1.0
user@P4# set interface ge-0/0/2.0
user@P4# set interface ge-0/0/3.0

5. Enable RSVP on the interfaces.

[edit protocols rsvp]

user@P4# set interface ge-0/0/1.0
user@P4# set interface ge-0/0/2.0
user@P4# set interface ge-0/0/3.0

Results From configuration mode, confirm your configuration by entering the show interfaces,
show protocols ospf, show protocols mpls, show protocols rsvp, and show routing-options
commands. If the output does not display the intended configuration, repeat the
instructions in this example to correct the configuration.

user@P4# show interfaces

ge-0/0/1 {
unit 0 {
family inet {
address 192.168.45.5/24;
}
family mpls;
}
}
ge-0/0/2 {
unit 0 {
family inet {
address 192.168.56.5/24;
}
family mpls;
}
}

Copyright © 2012, Juniper Networks, Inc. 123

Junos OS 12.1 MPLS Applications Configuration Guide

ge-0/0/3 {
unit 0 {
family inet {
address 192.168.25.5/24;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 10.255.0.5/32;
}
}
}

user@P4# show protocols ospf

traffic-engineering;
area 0.0.0.0 {
interface ge-0/0/1.0;
interface ge-0/0/2.0;
interface ge-0/0/3.0;
interface lo0.0;
}

user@P4# show protocols mpls

interface ge-0/0/1.0;
interface ge-0/0/2.0;
interface ge-0/0/3.0;

user@P4# show protocols rsvp

interface ge-0/0/1.0;
interface ge-0/0/2.0;
interface ge-0/0/3.0;

user@P4# show routing-options

srlg {
srlg-a {
srlg-value 101;
srlg-cost 10;
}
}

If you are done configuring the device, enter commit from configuration mode.

Configuring Device P5

Step-by-Step The following example requires you to navigate various levels in the configuration
Procedure hierarchy. For information about navigating the CLI, see the Junos OS CLI User Guide.

To configure P5:

1. Configure the device interfaces.

[edit interfaces]
user@P5# set ge-0/0/1 unit 0 family inet address 192.168.56.6/24
user@P5# set ge-0/0/1 unit 0 family mpls
user@P5# set ge-0/0/2 unit 0 family inet address 192.168.67.6/24

124 Copyright © 2012, Juniper Networks, Inc.

 Chapter 4: MPLS Router Configuration Guidelines

user@P5# set ge-0/0/2 unit 0 family mpls

user@P5# set lo0 unit 0 family inet address 10.255.0.6/32

2. Configure OSPF on the interfaces.

[edit protocols ospf]

user@P5# set traffic-engineering
user@P5# set area 0.0.0.0 interface ge-0/0/1.0
user@P5# set area 0.0.0.0 interface ge-0/0/2.0
user@P5# set area 0.0.0.0 interface lo0.0

3. Configure the SRLG definitions.

[edit routing-options]
user@P5# set routing-options srlg srlg-a srlg-value 101
user@P5# set routing-options srlg srlg-a srlg-cost 10

4. Configure MPLS on the interfaces.

[edit protocols mpls]

user@P5# set interface ge-0/0/1.0
user@P5# set interface ge-0/0/2.0

5. Enable RSVP on the interfaces.

[edit protocols rsvp]

user@P5# set interface ge-0/0/1.0
user@P5# set interface ge-0/0/2.0

Results From configuration mode, confirm your configuration by entering the show interfaces,
show protocols ospf, show protocols mpls, show protocols rsvp, and show routing-options
commands. If the output does not display the intended configuration, repeat the
instructions in this example to correct the configuration.

user@P5# show interfaces

ge-0/0/1 {
unit 0 {
family inet {
address 192.168.56.6/24;
}
family mpls;
}
}
ge-0/0/2 {
unit 0 {
family inet {
address 192.168.67.6/24;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 10.255.0.6/32;
}
}
}

Copyright © 2012, Juniper Networks, Inc. 125

Junos OS 12.1 MPLS Applications Configuration Guide

user@P5# show protocols ospf

traffic-engineering;
area 0.0.0.0 {
interface ge-0/0/1.0;
interface ge-0/0/2.0;
interface lo0.0;
}

user@P5# show protocols mpls

interface ge-0/0/1.0;
interface ge-0/0/2.0;

user@P5# show protocols rsvp

interface ge-0/0/1.0;
interface ge-0/0/2.0;

user@P5# show routing-options

srlg {
srlg-a {
srlg-value 101;
srlg-cost 10;
}
}

If you are done configuring the device, enter commit from configuration mode.

Configuring Device PE2

Step-by-Step The following example requires you to navigate various levels in the configuration
Procedure hierarchy. For information about navigating the CLI, see the Junos OS CLI User Guide.

To configure PE2:

1. Configure the device interfaces.

[edit interfaces]
user@PE2# set ge-0/0/1 unit 0 family inet address 192.168.27.7/24
user@PE2# set ge-0/0/1 unit 0 family mpls
user@PE2# set ge-0/0/2 unit 0 family inet address 192.168.37.7/24
user@PE2# set ge-0/0/2 unit 0 family mpls
user@PE2# set ge-0/0/3 unit 0 family inet address 192.168.67.7/24
user@PE2# set ge-0/0/3 unit 0 family mpls
user@PE2# set lo0 unit 0 family inet address 10.255.0.7/32

2. Configure OSPF on the interfaces.

[edit protocols ospf]

user@PE2# set traffic-engineering
user@PE2# set area 0.0.0.0 interface ge-0/0/1.0
user@PE2# set area 0.0.0.0 interface ge-0/0/2.0
user@PE2# set area 0.0.0.0 interface ge-0/0/3.0
user@PE2# set area 0.0.0.0 interface lo0.0

3. Configure the SRLG definitions.

[edit routing-options]
user@PE2# set routing-options srlg srlg-a srlg-value 101
user@PE2# set routing-options srlg srlg-a srlg-cost 10

126 Copyright © 2012, Juniper Networks, Inc.

 Chapter 4: MPLS Router Configuration Guidelines

4. Configure MPLS on the interfaces.

[edit protocols mpls]

user@PE2# set interface ge-0/0/1.0
user@PE2# set interface ge-0/0/2.0
user@PE2# set interface ge-0/0/3.0

5. Enable RSVP on the interfaces.

[edit protocols rsvp]

user@PE2# set interface ge-0/0/1.0
user@PE2# set interface ge-0/0/2.0
user@PE2# set interface ge-0/0/3.0

Results From configuration mode, confirm your configuration by entering the show interfaces,
show protocols ospf, show protocols mpls, show protocols rsvp, and show routing-options
commands. If the output does not display the intended configuration, repeat the
instructions in this example to correct the configuration.

user@PE2# show interfaces

interfaces {
ge-0/0/1 {
unit 0 {
family inet {
address 192.168.27.7/24;
}
family mpls;
}
}
ge-0/0/2 {
unit 0 {
family inet {
address 192.168.37.7/24;
}
family mpls;
}
}
ge-0/0/3 {
unit 0 {
family inet {
address 192.168.67.7/24;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 10.255.0.7/32;
}
}
}
}

user@PE2# show protocols ospf

traffic-engineering;

Copyright © 2012, Juniper Networks, Inc. 127

Junos OS 12.1 MPLS Applications Configuration Guide

area 0.0.0.0 {
interface ge-0/0/1.0;
interface ge-0/0/2.0;
interface ge-0/0/3.0;
interface lo0.0;
}

user@PE2# show protocols mpls

interface ge-0/0/1.0;
interface ge-0/0/2.0;
interface ge-0/0/3.0;

user@PE2# show protocols rsvp

interface ge-0/0/1.0;
interface ge-0/0/2.0;
interface ge-0/0/3.0;

user@PE2# show routing-options

srlg {
srlg-a {
srlg-value 101;
srlg-cost 10;
}
}

If you are done configuring the device, enter commit from configuration mode.

Verification
Confirm that the configuration is working properly.

Verifying the SRLG Cost Is Added to the TE Link

Purpose Verify that the TE link is excluded if it belongs to the SRLG of the protected link when
link-protection is configured with exclude-srlg. Issue the show ted link detail and show
rsvp session extensive bypass commands on device P1.

Action user@P1> show ted link detail

...
10.255.0.2->192.168.27.7-1, Local: 192.168.27.2, Remote: 0.0.0.0
Local interface index: 0, Remote interface index: 0
LocalPath: 0, Metric: 1, StaticBW: 1000Mbps, AvailBW: 1000Mbps
Color: 0 <none>
SRLGs: srlg-a
localBW [0] 0bps [1] 0bps [2] 0bps [3] 0bps
localBW [4] 0bps [5] 0bps [6] 0bps [7] 0bps
[...]
10.255.0.3->192.168.37.7-1, Local: 192.168.37.3, Remote: 0.0.0.0
Local interface index: 0, Remote interface index: 0
LocalPath: 0, Metric: 1, StaticBW: 1000Mbps, AvailBW: 1000Mbps
Color: 0 <none>
SRLGs: srlg-a
localBW [0] 0bps [1] 0bps [2] 0bps [3] 0bps
localBW [4] 0bps [5] 0bps [6] 0bps [7] 0bps
...

user@P1> show rsvp session extensive bypass

128 Copyright © 2012, Juniper Networks, Inc.

 Chapter 4: MPLS Router Configuration Guidelines

Ingress RSVP: 1 sessions

10.255.0.7
From: 10.255.0.2, LSPstate: Up, ActiveRoute: 0
LSPname: Bypass->192.168.27.7
LSPtype: Static Configured
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: 299776
Resv style: 1 SE, Label in: -, Label out: 299776
Time left: -, Since: Fri Oct 21 13:19:21 2011
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 1 receiver 52081 protocol 0
Type: Bypass LSP
Number of data route tunnel through: 1
Number of RSVP session tunnel through: 0
PATH rcvfrom: localclient
Adspec: sent MTU 1500
Path MTU: received 1500
PATH sentto: 192.168.25.5 (ge-0/0/4.0) 63 pkts
RESV rcvfrom: 192.168.25.5 (ge-0/0/4.0) 63 pkts
Explct route: 192.168.25.5 192.168.56.6 192.168.67.7
Record route: <self> 192.168.25.5 192.168.56.6 192.168.67.7
Total 1 displayed, Up 1, Down 0

Meaning The shortest path for the bypass protecting the link P1>PE2 would have been P1>P2>PE2.
Because the links P1>PE2 and P2>PE2 both belong to SRLG srlg-a, the link P2>PE2 is
rejected for CSPF consideration due to the exclude-srlg constraint. Therefore, the
computed path for the bypass becomes P1>P4>P5>PE2.

Related • SRLG Overview on page 36

Documentation
• Example: Configuring SRLG on page 76

• Example: Configuring SRLG With Link Protection on page 90

• exclude-srlg on page 300

Configuring the MPLS Transport Profile for OAM

• MPLS Transport Profile Overview on page 129

• Example: Configuring the MPLS Transport Profile for OAM on page 130

MPLS Transport Profile Overview

RFC 5654, Requirements of an MPLS Transport Profile, describes the requirements for
the MPLS Transport Profile (MPLS-TP) that extends capabilities for Operation,
Administration, and Maintenance (OAM) when MPLS is used for transport services and
transport network operations. These capabilities help in troubleshooting and maintenance
of a pseudowire or label-switched path (LSP).

Copyright © 2012, Juniper Networks, Inc. 129

Junos OS 12.1 MPLS Applications Configuration Guide

MPLS-TP mechanisms for OAM contain two main components:

• Generic Associated Channel Label (GAL)—A special label that enables an exception
mechanism that informs the egress label-switching router (LSR) that a packet it
receives on an LSP belongs to an associated control channel or the control plane.

• Generic Associated Channel Header (G-Ach)—A special header field that identifies
the type of payload contained in the MPLS label-switched paths (LSPs). G-Ach has
the same format as a pseudowire associated control channel header.

For more information about MPLS-TP, see RFC 5654, Requirements of an MPLS Transport
Profile. For specific information about GAL and G-Ach, see RFC 5586, MPLS Generic
Associated Channel.

Example: Configuring the MPLS Transport Profile for OAM

This example shows how to configure the MPLS Transport Profile (MPLS-TP) for sending
and receiving of OAM GAL and G-Ach messages across a label-switched path (LSP).

• Requirements on page 130

• Overview on page 130
• Configuration on page 132
• Verification on page 139

Requirements

This example uses the following hardware and software components:

• Six devices that can be a combination of M Series, MX Series, and T Series routers

• Junos OS Release 12.1 or later running on the devices

Overview

Junos OS Release 12.1 and later support MPLS Transport Profile (MPLS-TP) Operation,
Administration, and Maintenance (OAM) capabilities. MPLS-TP introduces new
capabilities for OAM when MPLS is used for transport services and transport network
operations. This includes configuring Generic Associated Channel Label (GAL) and Generic
Associated Channel Header (G-Ach) for OAM messages.

This example shows how to configure MPLS-TP OAM capability to send and receive GAL
and G-Ach OAM messages without IP encapsulation. In addition, it also shows how to
associate two unidirectional RSVP label-switched paths (LSPs) between a pair of routers
to create an associated bidirectional LSP for binding a path for the GAL and G-Ach OAM
messages.

Junos OS Release 12.1 and later support the following MPLS-TP capabilities:

• MPLS-TP OAM capability and the infrastructure required for MPLS applications to
send and receive packets with GAL and G-Ach, without IP encapsulation.

• LSP-ping and Bidirectional Forwarding Detection (BFD) applications to send and

receive packets using GAL and G-Ach, without IP encapsulation on transport LSPs.

130 Copyright © 2012, Juniper Networks, Inc.

 Chapter 4: MPLS Router Configuration Guidelines

• The association of two unidirectional RSVP LSPs, between a pair of routers, with each
other to create an associated bidirectional LSP for binding a path for the GAL and
G-Ach OAM messages. The associated bidirectional LSP model is supported only for
associating the primary paths. A single BFD session is established for the associated
bidirectional LSP.

Junos OS Release 12.1 and later does not support the following MPLS-TP capabilities:

• Point-to-multipoint RSVP LSPs and BGP LSPs

• Loss Measurement and Delay Measurement

You can enable GAL and G-Ach OAM operation using the following configuration
statements:

• mpls-tp-mode—Include this statement at the [edit protocols mpls oam] hierarchy level
to enable GAL and G-Ach OAM operation, without IP encapsulation, on all LSPs in the
MPLS network.

[edit protocols mpls oam]

mpls-tp-mode;

Include this statement at the [edit protocols mpls label-switched-path lsp-name oam]
hierarchy level to enable GAL and G-Ach OAM operation without IP encapsulation on
a specific LSP in the network.

[edit protocols mpls label-switched-path lsp-name oam]

mpls-tp-mode;

• associate-lsp lsp-name from from-ip-address—Include this statement at the [edit

protocols mpls label-switched-path lsp-name] hierarchy level to configure associated
bidirectional LSPs on the two ends of the LSP.

[edit protocols mpls label-switched-path lsp-name ]

associate-lsp lsp-name {
from from-ip-address;
}

The from from-ip-address configuration for the LSP is optional. If omitted, it is derived
from the to address of the ingress LSP configuration.

• transit-lsp-association—Include this statement at the [edit protocols mpls]

hierarchy level to associate two LSPs at a transit router.

[edit protocols mpls]

transit-lsp-association transit-association-lsp-group-name {
lsp-name-1 name-of-associated-lsp-1;
from-1 address-of-associated-lsp-1;
lsp-name-2 name-of-associated-lsp-2;
from-2 address-of-associated-lsp-2;
}

The association of the LSPs in the transit nodes is useful for the return LSP path for
TTL-expired LSP ping packets or traceroute.

Copyright © 2012, Juniper Networks, Inc. 131

Junos OS 12.1 MPLS Applications Configuration Guide

In this example, R0 is the ingress router and R4 is the egress router. R1, R2, R3, and R5 are
transit routers. The associated bidirectional LSP is established between the transit routers
for sending and receiving the GAL and G-Ach OAM messages.

Figure 20 on page 132 shows the topology used in this example.

Figure 20: MPLS-TP OAM Associated Bidirectional LSPs

R0 R1 R2 R3 R4

g040928
R5

Configuration

CLI Quick NOTE: This example shows the configuration on all devices and shows
Configuration step-by-step procedures for configuring the ingress router, R0, and transit
router R1. Repeat the step-by-step procedure described for the ingress router,
R0, on the egress router, R4. Repeat the step-by-step procedure for the transit
router, R1, on the other transit routers, R2, R3, and R5. Be sure to modify the
appropriate interface names, addresses, and other parameters appropriately.

To quickly configure this example, copy the following commands, paste them into a text
file, remove any line breaks, change any details necessary to match your network
configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy
level.

Router R0 set interfaces ge-4/1/1 unit 0 family inet address 10.10.11.1/30

set interfaces ge-4/1/1 unit 0 family iso
set interfaces ge-4/1/1 unit 0 family inet6
set interfaces ge-4/1/1 unit 0 family mpls
set interfaces ge-5/0/0 unit 0 family inet address 10.10.10.1/30
set interfaces ge-5/0/0 unit 0 family iso
set interfaces ge-5/0/0 unit 0 family inet6

132 Copyright © 2012, Juniper Networks, Inc.

 Chapter 4: MPLS Router Configuration Guidelines

set interfaces ge-5/0/0 unit 0 family mpls

set protocols rsvp interface ge-5/0/0.0
set protocols rsvp interface ge-4/1/1.0
set protocols mpls label-switched-path r0-to-r4 to 10.255.8.86
set protocols mpls label-switched-path r0-to-r4 oam mpls-tp-mode
set protocols mpls label-switched-path r0-to-r4 associate-lsp r4-to-r0 from 10.255.8.86
set protocols mpls interface ge-5/0/0.0
set protocols mpls interface ge-4/1/1.0
set protocols ospf traffic-engineering
set protocols ospf area 0.0.0.0 interface ge-5/0/0.0
set protocols ospf area 0.0.0.0 interface ge-4/1/1.0
set protocols ospf area 0.0.0.0 interface lo0.0 passive

Router R1 set interfaces ge-0/0/5 unit 0 family inet address 10.10.10.2/30

set interfaces ge-0/0/5 unit 0 family iso
set interfaces ge-0/0/5 unit 0 family inet6
set interfaces ge-0/0/5 unit 0 family mpls
set interfaces ge-0/2/2 unit 0 family inet address 10.10.12.2/30
set interfaces ge-0/2/2 unit 0 family iso
set interfaces ge-0/2/2 unit 0 family inet6
set interfaces ge-0/2/2 unit 0 family mpls
set interfaces ge-1/0/2 unit 0 family inet address 10.10.13.2/30
set interfaces ge-1/0/2 unit 0 family iso
set interfaces ge-1/0/2 unit 0 family inet6
set interfaces ge-1/0/2 unit 0 family mpls
set interfaces ge-2/0/2 unit 0 family inet address 10.10.11.2/30
set interfaces ge-2/0/2 unit 0 family iso
set interfaces ge-2/0/2 unit 0 family inet6
set interfaces ge-2/0/2 unit 0 family mpls
set protocols rsvp interface ge-0/2/2.0
set protocols rsvp interface ge-0/0/5.0
set protocols rsvp interface ge-1/0/2.0
set protocols rsvp interface ge-2/0/2.0
set protocols mpls transit-lsp-association trace1 lsp-name-1 r0-to-r4
set protocols mpls transit-lsp-association trace1 from-1 10.255.8.207
set protocols mpls transit-lsp-association trace1 lsp-name-2 r4-to-r0
set protocols mpls transit-lsp-association trace1 from-2 10.255.8.86
set protocols mpls interface ge-0/0/5.0
set protocols mpls interface ge-2/0/2.0
set protocols mpls interface ge-1/0/2.0
set protocols mpls interface ge-0/2/2.0
set protocols ospf traffic-engineering
set protocols ospf area 0.0.0.0 interface ge-0/0/5.0
set protocols ospf area 0.0.0.0 interface ge-0/2/2.0 metric 100
set protocols ospf area 0.0.0.0 interface ge-1/0/2.0
set protocols ospf area 0.0.0.0 interface ge-2/0/2.0
set protocols ospf area 0.0.0.0 interface lo0.0 passive

Router R2 set interfaces ge-0/2/3 unit 0 family inet address 10.10.13.1/30

set interfaces ge-0/2/3 unit 0 family iso
set interfaces ge-0/2/3 unit 0 family inet6
set interfaces ge-0/2/3 unit 0 family mpls
set interfaces ge-1/3/2 unit 0 family inet address 10.10.14.1/30
set interfaces ge-1/3/2 unit 0 family iso
set interfaces ge-1/3/2 unit 0 family inet6

Copyright © 2012, Juniper Networks, Inc. 133

Junos OS 12.1 MPLS Applications Configuration Guide

set interfaces ge-1/3/2 unit 0 family mpls

set interfaces ge-1/3/4 unit 0 family inet address 10.10.15.1/30
set interfaces ge-1/3/4 unit 0 family iso
set interfaces ge-1/3/4 unit 0 family inet6
set interfaces ge-1/3/4 unit 0 family mpls
set protocols rsvp interface ge-0/2/3.0
set protocols rsvp interface ge-1/3/2.0
set protocols rsvp interface ge-1/3/4.0
set protocols mpls transit-lsp-association trace1 lsp-name-1 r0-to-r4
set protocols mpls transit-lsp-association trace1 from-1 10.255.8.207
set protocols mpls transit-lsp-association trace1 lsp-name-2 r4-to-r0
set protocols mpls transit-lsp-association trace1 from-2 10.255.8.86
set protocols mpls interface ge-0/2/3.0
set protocols mpls interface ge-1/3/2.0
set protocols mpls interface ge-1/3/4.0
set protocols ospf traffic-engineering
set protocols ospf area 0.0.0.0 interface ge-0/2/3.0
set protocols ospf area 0.0.0.0 interface ge-1/3/2.0
set protocols ospf area 0.0.0.0 interface ge-1/3/4.0 metric 100
set protocols ospf area 0.0.0.0 interface lo0.0 passive

Router R3 set interfaces ge-1/2/1 unit 0 family inet address 10.10.16.2/30

set interfaces ge-1/2/1 unit 0 family iso
set interfaces ge-1/2/1 unit 0 family inet6
set interfaces ge-1/2/1 unit 0 family mpls
set interfaces ge-2/0/7 unit 0 family inet address 10.10.17.2/30
set interfaces ge-2/0/7 unit 0 family iso
set interfaces ge-2/0/7 unit 0 family inet6
set interfaces ge-2/0/7 unit 0 family mpls
set interfaces ge-2/2/0 unit 0 family inet address 10.10.14.2/30
set interfaces ge-2/2/0 unit 0 family iso
set interfaces ge-2/2/0 unit 0 family inet6
set interfaces ge-2/2/0 unit 0 family mpls
set protocols rsvp interface ge-2/2/0.0
set protocols rsvp interface ge-1/2/1.0
set protocols rsvp interface ge-2/0/7.0
set protocols mpls transit-lsp-association trace1 lsp-name-1 r0-to-r4
set protocols mpls transit-lsp-association trace1 from-1 10.255.8.207
set protocols mpls transit-lsp-association trace1 lsp-name-2 r4-to-r0
set protocols mpls transit-lsp-association trace1 from-2 10.255.8.86
set protocols mpls interface ge-2/2/0.0
set protocols mpls interface ge-1/2/1.0
set protocols mpls interface ge-2/0/7.0
set protocols ospf traffic-engineering
set protocols ospf area 0.0.0.0 interface ge-2/2/0.0
set protocols ospf area 0.0.0.0 interface ge-1/2/1.0
set protocols ospf area 0.0.0.0 interface ge-2/0/7.0 metric 100
set protocols ospf area 0.0.0.0 interface lo0.0 passive

Router R4 set interfaces ge-0/0/3 unit 0 family inet address 10.10.16.1/30

set interfaces ge-0/0/3 unit 0 family iso
set interfaces ge-0/0/3 unit 0 family inet6
set interfaces ge-0/0/3 unit 0 family mpls
set protocols rsvp interface ge-0/0/3.0
set protocols mpls label-switched-path r4-to-r0 to 10.255.8.207

134 Copyright © 2012, Juniper Networks, Inc.

 Chapter 4: MPLS Router Configuration Guidelines

set protocols mpls label-switched-path r4-to-r0 oam mpls-tp-mode

set protocols mpls label-switched-path r4-to-r0 associate-lsp r0-to-r4 from 10.255.8.207
set protocols mpls interface ge-0/0/3.0
set protocols ospf traffic-engineering
set protocols ospf area 0.0.0.0 interface ge-0/0/3.0
set protocols ospf area 0.0.0.0 interface lo0.0 passive

Router R5 set interfaces ge-1/2/0 unit 0 family inet address 10.10.15.2/30

set interfaces ge-1/2/0 unit 0 family iso
set interfaces ge-1/2/0 unit 0 family inet6
set interfaces ge-1/2/0 unit 0 family mpls
set interfaces ge-2/0/0 unit 0 family inet address 10.10.12.1/30
set interfaces ge-2/0/0 unit 0 family iso
set interfaces ge-2/0/0 unit 0 family inet6
set interfaces ge-2/0/0 unit 0 family mpls
set interfaces ge-4/0/7 unit 0 family inet address 10.10.17.1/30
set interfaces ge-4/0/7 unit 0 family iso
set interfaces ge-4/0/7 unit 0 family inet6
set interfaces ge-4/0/7 unit 0 family mpls
set protocols rsvp interface ge-2/0/0.0
set protocols rsvp interface ge-1/2/0.0
set protocols rsvp interface ge-4/0/7.0
set protocols mpls transit-lsp-association trace1 lsp-name-1 r0-to-r4
set protocols mpls transit-lsp-association trace1 from-1 10.255.8.207
set protocols mpls transit-lsp-association trace1 lsp-name-2 r4-to-r0
set protocols mpls transit-lsp-association trace1 from-2 10.255.8.86
set protocols mpls interface ge-2/0/0.0
set protocols mpls interface ge-1/2/0.0
set protocols mpls interface ge-4/0/7.0
set protocols ospf traffic-engineering
set protocols ospf area 0.0.0.0 interface ge-2/0/0.0 metric 100
set protocols ospf area 0.0.0.0 interface ge-1/2/0.0 metric 100
set protocols ospf area 0.0.0.0 interface ge-4/0/7.0 metric 100
set protocols ospf area 0.0.0.0 interface lo0.0 passive

Configuring Device R0

Step-by-Step To configure the ingress router, R0:

Procedure
1. Configure the interfaces.

[edit interfaces]
user@R0# set ge-4/1/1 unit 0 family inet address 10.10.11.1/30
user@R0# set ge-4/1/1 unit 0 family iso
user@R0# set ge-4/1/1 unit 0 family inet6
user@R0# set ge-4/1/1 unit 0 family mpls
user@R0# set ge-5/0/0 unit 0 family inet address 10.10.10.1/30
user@R0# set ge-5/0/0 unit 0 family iso
user@R0# set ge-5/0/0 unit 0 family inet6
user@R0# set ge-5/0/0 unit 0 family mpls

2. Configure MPLS on the interfaces.

[edit protocols mpls]

user@R0# set interface ge-5/0/0.0
user@R0# set interface ge-4/1/1.0

Copyright © 2012, Juniper Networks, Inc. 135

Junos OS 12.1 MPLS Applications Configuration Guide

3. Configure an interior gateway protocol, such as OSPF.

[edit protocols ospf]

user@R0# set traffic-engineering
user@R0# set area 0.0.0.0 interface ge-5/0/0.0
user@R0# set area 0.0.0.0 interface ge-4/1/1.0
user@R0# set area 0.0.0.0 interface lo0.0 passive

4. Configure a signaling protocol, such as RSVP.

[edit protocols rsvp]

user@R0# set interface ge-5/0/0.0
user@R0# set interface ge-4/1/1.0

5. Configure the LSP.

[edit protocols mpls]

user@R0# set label-switched-path r0-to-r4 to 10.255.8.86

6. Enable GAL and G-Ach OAM operation without IP encapsulation on the LSPs.

[edit protocols mpls]

user@R0# set label-switched-path r0-to-r4 oam mpls-tp-mode

7. Configure associated bidirectional LSPs on the two ends of the LSP.

[edit protocols mpls]

user@R0# set label-switched-path r0-to-r4 associate-lsp to-r0 from 10.255.8.86

8. After you are done configuring the device, commit the configuration.

[edit]
user@R0# commit

Results Confirm your configuration by issuing the show interfaces and show protocols commands.

user@R0# show interfaces

ge-4/1/1 {
unit 0 {
family inet {
address 10.10.11.1/30;
}
family iso;
family inet6;
family mpls;
}
}
ge-5/0/0 {
unit 0 {
family inet {
address 10.10.10.1/30;
}
family iso;
family inet6;
family mpls;
}
}

user@R0# show protocols

rsvp {

136 Copyright © 2012, Juniper Networks, Inc.

 Chapter 4: MPLS Router Configuration Guidelines

interface ge-5/0/0.0;
interface ge-4/1/1.0;
}
mpls {
label-switched-path r0-to-r4 {
to 10.255.8.86;
oam mpls-tp-mode;
associate-lsp r4-to-r0 {
from 10.255.8.86;
}
}
interface ge-4/1/1.0;
interface ge-5/0/0.0;
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface ge-5/0/0.0;
interface ge-4/1/1.0;
interface lo0.0 {
passive;
}
}
}

Configuring Device R1

Step-by-Step To configure the transit router, R1:

Procedure
1. Configure the interfaces.

[edit interfaces]
user@R1# set ge-0/0/5 unit 0 family inet address 10.10.10.2/30
user@R1# set ge-0/0/5 unit 0 family iso
user@R1# set ge-0/0/5 unit 0 family inet6
user@R1# set ge-0/0/5 unit 0 family mpls
user@R1# set ge-0/2/2 unit 0 family inet address 10.10.12.2/30
user@R1# set ge-0/2/2 unit 0 family iso
user@R1# set ge-0/2/2 unit 0 family inet6
user@R1# set ge-0/2/2 unit 0 family mpls
user@R1# set ge-2/0/2 unit 0 family inet address 10.10.11.2/30
user@R1# set ge-2/0/2 unit 0 family iso
user@R1# set ge-2/0/2 unit 0 family inet6
user@R1# set ge-2/0/2 unit 0 family mpls
user@R1# set ge-1/0/2 unit 0 family inet address 10.10.13.2/30
user@R1# set ge-1/0/2 unit 0 family iso
user@R1# set ge-1/0/2 unit 0 family inet6
user@R1# set ge-1/0/2 unit 0 family mpls

2. Configure MPLS on the interfaces.

[edit protocols mpls]

user@R1# set interface ge-0/0/5.0
user@R1# set interface ge-2/0/2.0
user@R1# set interface ge-1/0/2.0
user@R1# set interface ge-0/2/2.0

Copyright © 2012, Juniper Networks, Inc. 137

Junos OS 12.1 MPLS Applications Configuration Guide

3. Configure an interior gateway protocol, such as OSPF.

[edit protocols ospf]

user@R1# set traffic-engineering
user@R1# set area 0.0.0.0 interface ge-0/0/5.0
user@R1# set area 0.0.0.0 interface ge-2/0/2.0
user@R1# set area 0.0.0.0 interface ge-1/0/2.0
user@R1# set area 0.0.0.0 interface ge-0/2/2.0 metric 100
user@R1# set area 0.0.0.0 interface lo0.0 passive

4. Configure a signaling protocol, such as RSVP.

[edit protocols rsvp]

user@R1# set interface ge-0/0/5.0
user@R1# set interface ge-2/0/2.0
user@R1# set interface ge-1/0/2.0
user@R1# set interface ge-0/2/2.0

5. Configure the association of the two LSPs on the transit router.

[edit protocols mpls]

user@R1# set transit-lsp-association trace1 lsp-name-1 r0-to-r4
user@R1# set transit-lsp-association trace1 from-1 10.255.8.207
user@R1# set transit-lsp-association trace1 lsp-name-2 r4-to-r0
user@R1# set transit-lsp-association trace1 from-2 10.255.8.86

6. If you are done configuring the device, commit the configuration.

[edit]
user@R1# commit

Results Confirm your configuration by issuing the show interfaces and show protocols commands.

user@R1# show interfaces

ge-0/0/5 {
unit 0 {
family inet {
address 10.10.10.2/30;
}
family iso;
family inet6;
family mpls;
}
}
ge-0/2/2 {
unit 0 {
family inet {
address 10.10.12.2/30;
}
family iso;
family inet6;
family mpls;
}
}
ge-2/0/2 {
unit 0 {
family inet {
address 10.10.11.2/30;

138 Copyright © 2012, Juniper Networks, Inc.

 Chapter 4: MPLS Router Configuration Guidelines

}
family iso;
family inet6;
family mpls;
}
}
ge-1/0/2 {
unit 0 {
family inet {
address 10.10.13.2/30;
}
family iso;
family inet6;
family mpls;
}
}

user@R1# show protocols

rsvp {
interface ge-0/0/5.0;
interface ge-2/0/2.0;
interface ge-1/0/2.0;
interface ge-0/2/2.0;
}
mpls {
transit-lsp-association trace1 {
lsp-name-1 r0-to-r4;
from-1 10.255.8.207;
lsp-name-2 r4-to-r0;
from-2 10.255.8.86;
}
interface ge-0/0/5.0;
interface ge-2/0/2.0;
interface ge-1/0/2.0;
interface ge-0/2/2.0;
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface ge-0/0/5.0;
interface ge-1/0/2.0;
interface ge-2/0/2.0;
interface ge-0/2/2.0 {
metric 100;
}
interface lo0.0 {
passive;
}
}
}

Verification

Confirm that the configuration is working properly.

Copyright © 2012, Juniper Networks, Inc. 139

Junos OS 12.1 MPLS Applications Configuration Guide

Verifying Associated Bidirectional LSPs

Purpose Verify that the associated bidirectional LSP configuration is working properly.

Action user@host> show mpls lsp

Ingress LSP: 1 sessions
To From State Rt P ActivePath LSPname
10.10.11.1 10.255.8.86 Up 0 * r0-to-r4 Assoc-Bidir
Total 1 displayed, Up 1, Down 0

Egress LSP: 1 sessions

To From State Rt Style Labelin Labelout LSPname
10.10.16.1 10.255.8.207 Up 0 1 FF 3 r4-to-r0 Assoc-Bidir
Total 2 displayed, Up 2, Down 0

Transit LSP: 1 sessions

To From State Rt Style Labelin Labelout LSPname
10.10.10.2 10.255.8.168 Up 1 1 FF 301264 3 r0-to-r4 Assoc-Bidir
Total 3 displayed, Up 3, Down 0

user@host> show mpls lsp detail

Ingress LSP: 1 sessions

10.10.11.1
From: 10.255.8.86, State: Up, ActiveRoute: 0, LSPname: r0-to-r4
Associated Bidirectional
Associated LSP: r0-to-r4, 10.255.8.86
ActivePath: (primary)
LSPtype: Static Configured
LoadBalance: Random
Encoding type: Packet, Switching type: PSC-1, GPID: Unknown
*Primary State: Up

Egress LSP: 1 sessions

10.255.102.29
From: 10.255.102.172, LSPstate: Up, ActiveRoute: 0
LSPname: r4-to-r0, LSPpath: Primary
Associated Bidirectional
Associated LSP: 10.10.16.1, to-r0>
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: -
Resv style: 1 FF, Label in: 3, Label out: -
Time left: 144, Since: Fri Jun 17 21:41:05 2011
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 6 receiver 14468 protocol 0
PATH rcvfrom: 10.10.13.1 (ge-2/0/0.0) 84 pkts
Adspec: received MTU 1500
PATH sentto: localclient
RESV rcvfrom: localclient
Record route: 10.10.14.2 10.10.13.1 <self>

Transit LSP: 1 sessions

10.255.102.30
From: 10.255.102.172, LSPstate: Up, ActiveRoute: 1
LSPname: to_airstream, LSPpath: Primary
Associated Bidirectional
Associated LSP: r0-to-r4, 10.255.8.168

140 Copyright © 2012, Juniper Networks, Inc.

 Chapter 4: MPLS Router Configuration Guidelines

Suggested label received: -, Suggested label

Recovery label received: -, Recovery label sent: 3
Resv style: 1 FF, Label in: 301264, Label out: 3
Time left: 132, Since: Fri Jun 17 21:40:56 2011
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 28 receiver 14465 protocol 0
PATH rcvfrom: 10.10.13.1 (ge-2/0/0.0) 84 pkts
Adspec: received MTU 1500 sent MTU 1500
PATH sentto: 10.10.10.1 (ge-3/0/0.0) 84 pkts
RESV rcvfrom: 10.10.10.1 (ge-3/0/0.0) 84 pkts
Explct route: 10.10.10.1
Record route: 10.10.16.1 10.10.15.2 10.10.13.1 <self> 10.10.10.1

user@host> show mpls lsp bidirectional

Ingress LSP: 1 session
To From State Rt P ActivePath LSPname
10.255.8.86 10.255.8.207 Up 0 * r0-to-r4
Assoc-Bidir
Total 1 displayed, Up 1, Down 0
Aug 28 06:56:26 [TRACE] [R0 coleman re0]
Egress LSP: 1 session
To From State Rt Style Labelin Labelout LSPname
10.255.8.207 10.255.8.86 Up 0 1 FF 3 - to-r0
Assoc-Bidir
Total 1 displayed, Up 1, Down 0
Aug 28 06:56:26 [TRACE] [R0 coleman re0]
Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0

Meaning The output of the show mpls lsp, show mpls detail, and show mpls bidirectional commands
displays the details of the associated bidirectional LSPs and the LSP association
information.

Copyright © 2012, Juniper Networks, Inc. 141

Junos OS 12.1 MPLS Applications Configuration Guide

142 Copyright © 2012, Juniper Networks, Inc.

CHAPTER 5

MPLS-Signaled LSP Configuration

Guidelines

MPLS-signaled label-switched paths (LSPs) run from a specific ingress router to a specific
egress router. This chapter describes how to configure LSPs. You can configure an LSP
so that the Junos OS makes all forwarding decisions, or you can configure some or all
routers in the path.

• LSP Configuration Overview on page 144

• Configuring the Ingress and Egress Router Addresses for LSPs on page 147
• Configuring Primary and Secondary LSPs on page 149
• Configuring a Text Description for LSPs on page 152
• Configuring Fast Reroute on page 152
• Configuring the Optimization Interval for Fast Reroute Paths on page 154
• Adding LSP-Related Routes to the inet.3 Routing Table on page 154
• Configuring the Connection Between Ingress and Egress Routers on page 155
• Configuring LSP Metrics on page 156
• Configuring CSPF Tie Breaking on page 157
• Configuring Load Balancing Based on MPLS Labels on page 158
• Disabling Normal TTL Decrementing on page 161
• Configuring MPLS Soft Preemption on page 162
• Configuring Automatic Bandwidth Allocation for LSPs on page 163
• Disabling Constrained-Path LSP Computation on page 170
• Configuring Administrative Groups on page 171
• Configuring Extended Administrative Groups on page 173
• Configuring Preference Values for LSPs on page 175
• Disabling Path Route Recording on page 175
• Configuring Class of Service for MPLS LSPs on page 175
• Configuring Adaptive LSPs on page 178
• Configuring Priority and Preemption for LSPs on page 179
• Optimizing Signaled LSPs on page 180

Copyright © 2012, Juniper Networks, Inc. 143

Junos OS 12.1 MPLS Applications Configuration Guide

• Configuring the Smart Optimize Timer on page 183

• Limiting the Number of Hops in LSPs on page 184
• Configuring the Bandwidth Value for LSPs on page 184
• Configuring Hot Standby of Secondary Paths on page 185
• Damping Advertisement of LSP State Changes on page 186

LSP Configuration Overview

To configure an MPLS-signaled LSP, you define the properties associated with the LSP
on the ingress router. Include the label-switched-path statement:

label-switched-path lsp-name {
disable;
adaptive;
admin-down;
admin-group {
exclude [ group-names ];
include-all [ group-names ];
include-any [ group-names ];
}
auto-bandwidth {
adjust-interval seconds;
adjust-threshold percent;
adjust-threshold-overflow-limit number;
adjust-threshold-underflow-limit number;
maximum-bandwidth bps;
minimum-bandwidth bps;
monitor-bandwidth;
}
bandwidth bps {
ct0 bps;
ct1 bps;
ct2 bps;
ct3 bps;
}
class-of-service cos-value;
description text;
fast-reroute {
(bandwidth bps | bandwidth-percent percentage);
(exclude [ group-names ] | no-exclude);
hop-limit number;
(include-all [ group-names ] | no-include-all);
(include-any [ group-names ] | noinclude-any);
}
from address;
hop-limit number;
install {
destination-prefix/prefix-length <active>;
}
ldp-tunneling;
link-protection;
lsp-attributes {
encoding-type (ethernet | packet | pdh | sonet-sdh);

144 Copyright © 2012, Juniper Networks, Inc.

 Chapter 5: MPLS-Signaled LSP Configuration Guidelines

gpid (ethernet | hdlc | ipv4 | pos-scrambling-crc-16 | pos-no-scrambling-crc-16 |

pos-scrambling-crc-32 | pos-no-scrambling-crc-32 | ppp);
signal-bandwidth type;
switching-type (fiber | lambda | psc-1 | tdm);
}
metric number;
no-cspf;
no-decrement-ttl;
node-link-protection;
optimize-timer seconds;
p2mp lsp-name;
policing {
filter filter-name;
no-auto-policing;
}
preference preference;
primary path-name {
adaptive;
admin-group {
exclude [ group-names ];
include-all [ group-names ];
include-any [ group-names ];
}
bandwidth bps {
ct0 bps;
ct1 bps;
ct2 bps;
ct3 bps;
}
class-of-service cos-value;
hop-limit number;
no-cspf;
no-decrement-ttl;
optimize-timer seconds;
preference preference;
priority setup-priority reservation-priority;
(record | no-record);
select (manual | unconditional);
standby;
}
priority setup-priority reservation-priority;
(random | least-fill | most-fill);
(record | no-record);
retry-limit number;
retry-timer seconds;
revert-timer seconds;
secondary path-name {
adaptive;
admin-group {
exclude [ group-names ];
include-all [ group-names ];
include-any [ group-names ];
}
bandwidth bps {
ct0 bps;
ct1 bps;

Copyright © 2012, Juniper Networks, Inc. 145

Junos OS 12.1 MPLS Applications Configuration Guide

ct2 bps;
ct3 bps;
}
class-of-service cos-value;
hop-limit number;
no-cspf;
no-decrement-ttl;
optimize-timer seconds;
preference preference;
priority setup-priority reservation-priority;
(record | no-record);
select (manual | unconditional);
standby;
}
soft-preemption {
cleanup-timer seconds;
}
standby;
to address;
traceoptions {
file filename <files number> <size size> <world-readable | no-world-readable>;
flag flag <flag-modifier> <disable>;
}
}

You can include this statement at the following hierarchy levels:

• [edit protocols mpls]

• [edit logical-systems logical-system-name protocols mpls]

Each LSP must have a name, lsp-name, which can be up to 64 characters long and can
contain letters, digits, periods (.), and hyphens (-). The name must be unique within the
ingress router. For ease of management and identification, configure unique names across
the entire domain.

When you configure LSPs, you can specify the following statements either for each LSP
or for each path. For statements that you configure on a per-LSP basis, the value applies
to all paths in the LSP. For statements that you configure on a per-path basis, the path
value overrides the per-LSP value.

• adaptive

• admin-group (for LSPs)

• auto-bandwidth

• bandwidth (Fast Reroute, Signaled, and Multiclass LSPs)

• class-of-service

• hop-limit

• no-cspf

• optimize-timer

• preference

146 Copyright © 2012, Juniper Networks, Inc.

 Chapter 5: MPLS-Signaled LSP Configuration Guidelines

• priority

• record or no-record

• standby

For maintenance purposes, you can also configure the following attributes across all
LSPs and any paths within those LSPs:

• admin-group (for LSPs)

• bandwidth (Fast Reroute, Signaled, and Multiclass LSPs)

• class-of-service

• no-decrement-ttl

• no-record

• optimize-timer

• preference

• priority

• smart-optimize-timer

• standby

Configuring the Ingress and Egress Router Addresses for LSPs

The following sections describe how to specify the addresses of an LSP’s ingress and
egress routers:

• Configuring the Ingress Router Address for LSPs on page 147

• Configuring the Egress Router Address for LSPs on page 148
• Preventing the Addition of Egress Router Addresses to Routing Tables on page 148

Configuring the Ingress Router Address for LSPs

The local router always is considered to be the ingress router, which is the beginning of
the LSP. The software automatically determines the proper outgoing interface and IP
address to use to reach the next router in an LSP.

By default, the router ID is chosen as the address of the ingress router. To override the
automatic selection of the source address, specify a source address in the from statement:

from address;

You can include this statement at the following hierarchy levels:

• [edit protocols mpls label-switched-path lsp-name]

• [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name]

The outgoing interface used by the LSP is not affected by the source address that
you configure.

Copyright © 2012, Juniper Networks, Inc. 147

Junos OS 12.1 MPLS Applications Configuration Guide

Configuring the Egress Router Address for LSPs

When configuring an LSP, you must specify the address of the egress router by including
the to statement:

to address;

You can include this statement at the following hierarchy levels:

• [edit protocols mpls label-switched-path lsp-name]

• [edit protocols mpls static-label-switched-path lsp-name]

• [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name]

• [edit logical-systems logical-system-name protocols mpls static-label-switched-path

lsp-name]

When you are setting up a signaled LSP, the to statement is the only required statement.
All other statements are optional.

After the LSP is established, the address of the egress router is installed as a host route
in the routing table. This route can then be used by BGP to forward traffic.

To have the software send BGP traffic over an LSP, the address of the egress router is
the same as the address of the BGP next hop. You can specify the egress router’s address
as any one of the router’s interface addresses or as the BGP router ID. If you specify a
different address, even if the address is on the same router, BGP traffic is not sent over
the LSP.

To determine the address of the BGP next hop, use the show route detail command. To
determine the destination address of an LSP, use the show mpls lsp command. To
determine whether a route has gone through an LSP, use the show route or show route
forwarding-table command. In the output of these last two commands, the
label-switched-path or push keyword included with the route indicates it has passed
through an LSP. Also, use the traceroute command to trace the actual path to which the
route leads. This is another indication whether a route has passed through an LSP.

You also can manipulate the address of the BGP next hop by defining a BGP import policy
filter that sets the route’s next-hop address.

Preventing the Addition of Egress Router Addresses to Routing Tables

You must configure an address using the to statement for all LSPs. This address is always
installed as a /32 prefix in the inet.3 or inet.0 routing tables. You can prevent the egress
router address configured using the to statement from being added to the inet.3 and
inet.0 routing tables by including the no-install-to-address statement.

Some reasons not to install the to statement address in the inet.3 and inet.0 routing
tables include the following:

• Allow Constrained Shortest Path First (CSPF) RSVP LSPs to be mapped to traffic
intended for secondary loopback addresses. If you configure an RSVP tunnel, including

148 Copyright © 2012, Juniper Networks, Inc.

 Chapter 5: MPLS-Signaled LSP Configuration Guidelines

the no-install-to-address statement, and then configure an install pfx/ <active> policy
later, you can do the following:

• Verify that the LSP was set up correctly without impacting traffic.

• Map traffic to the LSP in incremental steps.

• Map traffic to the destination loopback address (the BGP next hop) by removing
the no-install-to-address statement once troubleshooting is complete.

• Prevent CCC connections from losing IP traffic. When an LSP determines that it does
not belong to a connection, it installs the address specified with the to statement in
the inet.3 routing table. IP traffic is then forwarded to the CCC remote endpoint, which
can cause some types of PICs to fail.

To prevent the egress router address configured using the to statement from being added
to the inet.3 and inet.0 routing tables, include the no-install-to-address statement:

no-install-to-address;

You can include this statement at the following hierarchy levels:

• [edit protocols mpls label-switched-path lsp-name]

• [edit protocols mpls static-label-switched-path lsp-name]

• [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name]

• [edit logical-systems logical-system-name protocols mpls static-label-switched-path

lsp-name]

Configuring Primary and Secondary LSPs

By default, an LSP routes itself hop-by-hop toward the egress router. The LSP tends to
follow the shortest path as dictated by the local routing table, usually taking the same
path as destination-based, best-effort traffic. These paths are “soft” in nature because
they automatically reroute themselves whenever a change occurs in a routing table or
in the status of a node or link.

To configure the path so that it follows a particular route, create a named path using the
path statement, as described in “Creating Named Paths” on page 56. Then apply the
named path by including the primary or secondary statement. A named path can be
referenced by any number of LSPs.

To configure primary and secondary paths for an LSP, complete the steps in the following
sections:

• Configuring Primary and Secondary Paths for an LSP on page 150

• Configuring the Revert Timer for LSPs on page 150
• Specifying the Conditions for Path Selection on page 151

Copyright © 2012, Juniper Networks, Inc. 149

Junos OS 12.1 MPLS Applications Configuration Guide

Configuring Primary and Secondary Paths for an LSP

The primary statement creates the primary path, which is the LSP’s preferred path. The
secondary statement creates an alternative path. If the primary path can no longer reach
the egress router, the alternative path is used.

To configure primary and secondary paths, include the primary and secondary statements:

primary path-name {
...
}
secondary path-name {
...
}

You can include these statements at the following hierarchy levels:

• [edit protocols mpls label-switched-path lsp-name]

• [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name]

When the software switches from the primary to a secondary path, it continuously
attempts to revert to the primary path, switching back to it when it is again reachable,
but no sooner than the retry time specified in the retry-timer statement. (For more
information, see “Configuring the Connection Between Ingress and Egress Routers” on
page 155.)

You can configure zero or one primary path. If you do not configure a primary path, the
first secondary path that is established is selected as the path.

You can configure zero or more secondary paths. All secondary paths are equal, and the
software tries them in the order that they are listed in the configuration. The software
does not attempt to switch among secondary paths. If the current secondary path is not
available, the next one is tried. To create a set of equal paths, specify secondary paths
without specifying a primary path.

If you do not specify any named paths, or if the path that you specify is empty, the software
makes all routing decisions necessary to reach the egress router.

Configuring the Revert Timer for LSPs

For LSPs configured with both primary and secondary paths, it is possible to configure
the revert timer. If a primary path goes down and traffic is switched to the secondary
path, the revert timer specifies the amount of time (in seconds) that the LSP must wait
before it can revert traffic back to a primary path. If during this time, the primary path
experiences any connectivity problems or stability problems, the timer is restarted. You
can configure the revert timer for both static and dynamic LSPs.

The Junos OS also makes a determination as to which path is the preferred path. The
preferred path is the path which has not encountered any difficulty in the last revert timer
period. If both the primary and secondary paths have encountered difficulty, neither path
is considered preferred. However, if one of the paths is dynamic and the other static, the
dynamic path is selected as the preferred path.

150 Copyright © 2012, Juniper Networks, Inc.

 Chapter 5: MPLS-Signaled LSP Configuration Guidelines

The range of values you can configure for the revert timer is 0 through 65,535 seconds.
The default value is 60 seconds.

If you configure a value of 0 seconds, the traffic on the LSP, once switched from the
primary path to the secondary path, remains on the secondary path permanently (until
the network operator intervenes or until the secondary path goes down).

You can configure the revert timer for all LSPs on the router at the [edit protocols mpls]
hierarchy level or for a specific LSP at the [edit protocols mpls label-switched-path
lsp-name] hierarchy level.

To configure the revert timer, include the revert-timer statement:

revert-timer seconds;

For a list of hierarchy levels at which you can include this statement, see the summary
section for this statement.

Specifying the Conditions for Path Selection

When you have configured both primary and secondary paths for an LSP, you may need
to ensure that only a specific path is used.

The select statement is optional. If you do not include it, MPLS uses an automatic path
selection algorithm.

The manual and unconditional options do the following:

• manual—The path is immediately selected for carrying traffic as long as it is up and

stable. Traffic is sent to other working paths if the current path is down or degraded
(receiving errors). This parameter overrides all other path attributes except the select
unconditional statement.

• unconditional—The path is selected for carrying traffic unconditionally, regardless of

whether the path is currently down or degraded (receiving errors). This parameter
overrides all other path attributes.

Because the unconditional option switches to a path without regard to its current status,
be aware of the following potential consequences of specifying it:

• If a path is not currently up when you enable the unconditional option, traffic can be
disrupted. Ensure that the path is functional before specifying the unconditional
option.

• Once a path is selected because it has the unconditional option enabled, all other
paths for the LSP are gradually cleared, including the primary and standby paths.
No path can act as a standby to an unconditional path, so signaling those paths
serves no purpose.

For a specific path, the manual and unconditional options are mutually exclusive. You
can include the select statement with the manual option in the configuration of only one
of an LSP’s paths, and the select statement with the unconditional option in the
configuration of only one other of its paths.

Copyright © 2012, Juniper Networks, Inc. 151

Junos OS 12.1 MPLS Applications Configuration Guide

Enabling or disabling the manual and unconditional options for the select statement while
LSPs and their paths are up does not disrupt traffic.

To specify that a path be selected for carrying traffic if it is up and stable for at least the
revert timer window, include the select statement with the manual option:

select manual;

To specify that a path should always be selected for carrying traffic, even if it is currently
down or degraded, include the select statement with the unconditional option:

select unconditional;

You can include the select statement at the following hierarchy levels:

• [edit protocols mpls label-switched-path lsp-name (primary | secondary) path-name]

• [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name

(primary | secondary) path-name]

Configuring a Text Description for LSPs

You can provide a textual description for the LSP. Enclose any descriptive text that
includes spaces in quotation marks (" "). Any descriptive text you include is displayed in
the output of the show mpls lsp detail command and has no effect on the operation of
the LSP.

To provide a textual description for the LSP, include the description statement:

description text;

You can include this statement at the following hierarchy levels:

• [edit protocols mpls label-switched-path lsp-name]

• [edit protocols mpls static-label-switched-path lsp-name]

• [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name]

• [edit logical-systems logical-system-name protocols mpls static-label-switched-path

lsp-name]

The description text can be no more than 80 characters in length.

Configuring Fast Reroute

Fast reroute provides a mechanism for automatically rerouting traffic on an LSP if a node
or link in an LSP fails, thus reducing the loss of packets traveling over the LSP.

To configure fast reroute on an LSP, include the fast-reroute statement on the ingress
router:

fast-reroute {
(bandwidth bps | bandwidth-percent percentage);
(exclude [ group-names ] | no-exclude );
hop-limit number;

152 Copyright © 2012, Juniper Networks, Inc.

 Chapter 5: MPLS-Signaled LSP Configuration Guidelines

(include-all [ group-names ] | no-include-all);

(include-any [ group-names ] | no-include-any);
}

You can include this statement at the following hierarchy levels:

• [edit protocols mpls label-switched-path lsp-name]

• [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name]

You do not need to configure fast reroute on the LSP’s transit and egress routers. Once
fast reroute is enabled, the ingress router signals all the downstream routers that fast
reroute is enabled on the LSP, and each downstream router does its best to set up detours
for the LSP. If a downstream router does not support fast reroute, it ignores the request
to set up detours and continues to support the LSP. A router that does not support fast
reroute will cause some of the detours to fail, but otherwise has no impact on the LSP.

NOTE: To enable PFE fast reroute, configure a routing policy statement with
the load-balance per-packet statement at the [edit policy-options
policy-statement policy-name then] hierarchy level on each of the routers
where traffic might be rerouted. See also “Configuring Load Balancing Across
RSVP LSPs” on page 414.

By default, no bandwidth is reserved for the rerouted path. To allocate bandwidth for
the rerouted path, include either the bandwidth statement or the bandwidth-percent
statement. You can only include one of these statements at a time. If you do not include
either the bandwidth statement or the bandwidth-percent statement, the default setting
is to not reserve bandwidth for the detour path.

When you include the bandwidth statement, you can specify the specific amount of
bandwidth (in bits per second [bps]) you want to reserve for the detour path. The
bandwidth does not need to be identical to that allocated for the LSP.

When you specify a bandwidth percent using the bandwidth-percent statement, the
detour path bandwidth is computed by multiplying the bandwidth percentage by the
bandwidth configured for the main traffic-engineered LSP. For information about how
to configure the bandwidth for a traffic-engineered LSP, see “Configuring
Traffic-Engineered LSPs” on page 204.

Hop-limit constraints define how many more routers a detour is allowed to traverse
compared with the LSP itself. By default, the hop limit is set to 6. For example, if an LSP
traverses 4 routers, any detour for the LSP can be up to 10 (that is, 4 + 6) router hops,
including the ingress and egress routers.

By default, a detour inherits the same administrative (coloring) group constraints as its
parent LSP when CSPF is determining the alternate path. Administrative groups, also
known as link coloring or resource class, are manually assigned attributes that describe
the “color” of links, such that links with the same color conceptually belong to the same
class. If you specify the include-any statement when configuring the parent LSP, all links
traversed by the alternate session must have at least one color found in the list of groups.

Copyright © 2012, Juniper Networks, Inc. 153

Junos OS 12.1 MPLS Applications Configuration Guide

If you specify the include-all statement when configuring the parent LSP, all links traversed
by the alternate session must have all of the colors found in the list of groups. If you
specify the exclude statement when configuring the parent LSP, none of the links must
have a color found in the list of groups. For more information about administrative group
constraints, see “Configuring Administrative Groups” on page 171.

Configuring the Optimization Interval for Fast Reroute Paths

You can enable path optimization for fast reroute by configuring the fast reroute optimize
timer. The optimize timer triggers a periodic optimization process that recomputes the
fast reroute detour LSPs to use network resources more efficiently.

To enable fast reroute path optimization, specify the number of seconds using the
optimize-timer option for the fast-reroute statement:

fast-reroute seconds;

You can include this statement at the following hierarchy levels:

• [edit protocols rsvp]

• [edit logical-systems logical-system-name protocols rsvp]

Adding LSP-Related Routes to the inet.3 Routing Table

By default, a host route toward the egress router is installed in the inet.3 routing table.
(The host route address is the one you configure in the to statement.) Installing the host
route allows BGP to perform next-hop resolution. It also prevents the host route from
interfering with prefixes learned from dynamic routing protocols and stored in the inet.0
routing table.

Unlike the routes in the inet.0 table, routes in the inet.3 table are not copied to the Packet
Forwarding Engine, and hence they cause no changes in the system forwarding table
directly. You cannot use the ping or traceroute command through these routes. The only
use for inet.3 is to permit BGP to perform next-hop resolution. To examine the inet.3
table, use the show route table inet.3 command.

To inject additional routes into the inet.3 routing table, include the install statement:

install {
destination-prefix <active>;
}

You can include this statement at the following hierarchy levels:

• [edit protocols mpls label-switched-path lsp-name]

• [edit protocols mpls static-label-switched-path lsp-name]

• [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name]

• [edit logical-systems logical-system-name protocols mpls static-label-switched-path

lsp-name]

154 Copyright © 2012, Juniper Networks, Inc.

 Chapter 5: MPLS-Signaled LSP Configuration Guidelines

The specified routes are installed as aliases into the routing table when the LSP is
established. Installing additional routes allows BGP to resolve next hops within the
specified prefix and to direct additional traffic for these next hops to a particular LSP.

Including the active option with the install statement installs the specified prefix into the
inet.0 routing table, which is the primary forwarding table. The result is a route that is
installed in the forwarding table any time the LSP is established, which means you can
ping or trace the route. Use this option with care, because this type of prefix is very similar
to a static route.

You use alias routes for routers that have multiple addresses being used as BGP next
hops, or for routers that are not MPLS capable. In either of these cases, the LSP can be
configured to another MPLS capable system within the local domain, which then acts
as a “border” router. The LSP then terminates on the border router and, from that router,
Layer 3 forwarding takes the packet to the true next-hop router.

In the case of an interconnect, the domain’s border router can act as the proxy router
and can advertise the prefix for the interconnect if the border router is not setting the
BGP next hop to itself.

In the case of a point of presence (POP) that has routers that do not support MPLS, one
router (for example, a core router) that supports MPLS can act as a proxy for the entire
POP and can inject a set of prefixes that cover the POP. Thus, all routers within the POP
can advertise themselves as interior BGP (IBGP) next hops, and traffic can follow the
LSP to reach the core router. This means that normal IGP routing would prevail within
the POP.

You cannot use the ping or traceroute commands on routes in the inet.3 routing table.

For BGP next-hop resolution, it makes no difference whether a route is in inet.0 or inet.3;
the route with the best match (longest mask) is chosen. Among multiple best-match
routes, the one with the highest preference value is chosen.

Configuring the Connection Between Ingress and Egress Routers

The ingress router might make many attempts to connect and reconnect to the egress
router using the primary path. You can control how often the ingress router tries to
establish a connection using the primary path and how long it waits between retry
attempts.

The retry timer configures how long the ingress router waits before trying to connect
again to the egress router using the primary path. The default retry time is 30 seconds.
The time can be from 1 through 600 seconds. To modify this value, include the retry-timer
statement:

retry-timer seconds;

You can configure this statement at the following hierarchy levels:

• [edit protocols mpls label-switched-path lsp-name]

• [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name]

Copyright © 2012, Juniper Networks, Inc. 155

Junos OS 12.1 MPLS Applications Configuration Guide

By default, no limit is set to the number of times an ingress router attempts to establish
or reestablish a connection to the egress router using the primary path. To limit the number
of attempts, include the retry-limit statement:

retry-limit number;

You can configure this statement at the following hierarchy levels:

• [edit protocols mpls label-switched-path lsp-name]

• [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name]

The limit can be a value up to 10,000. When the retry limit is exceeded, no more attempts
are made to establish a path connection. At this point, intervention is required to restart
the primary path.

If you set a retry limit, it is reset to 1 each time a successful primary path is created.

Configuring LSP Metrics

The LSP metric is used to indicate the ease or difficulty of sending traffic over a particular
LSP. Lower LSP metric values (lower cost) increase the likelihood of an LSP being used.
Conversely, high LSP metric values (higher cost) decrease the likelihood of an LSP being
used.

The LSP metric can be specified dynamically by the router or explicitly by the user as
described in the following sections:

• Configuring Dynamic LSP Metrics on page 156

• Configuring Static LSP Metrics on page 156

Configuring Dynamic LSP Metrics

If no specific metric is configured, an LSP attempts to track the IGP metric toward the
same destination (the to address of the LSP). IGP includes OSPF, IS-IS, Routing
Information Protocol (RIP), and static routes. BGP and other RSVP or LDP routes are
excluded.

For example, if the OSPF metric toward a router is 20, all LSPs toward that router
automatically inherit metric 20. If the OSPF toward a router later changes to a different
value, all LSP metrics change accordingly. If there are no IGP routes toward the router,
the LSP raises its metric to 65,535.

Note that in this case, the LSP metric is completely determined by IGP; it bears no
relationship to the actual path the LSP is currently traversing. If LSP reroutes (such as
through reoptimization), its metric does not change, and thus it remains transparent to
users. Dynamic metric is the default behavior; no configuration is required.

Configuring Static LSP Metrics

You can manually assign a fixed metric value to an LSP. Once configured with the metric
statement, the LSP metric is fixed and cannot change:

156 Copyright © 2012, Juniper Networks, Inc.

 Chapter 5: MPLS-Signaled LSP Configuration Guidelines

metric number;

You can include this statement at the following hierarchy levels:

• [edit protocols mpls label-switched-path lsp-name]

• [edit protocols mpls static-label-switched-path lsp-name]

• [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name]

• [edit logical-systems logical-system-name protocols mpls static-label-switched-path

lsp-name]

The LSP metric has several uses:

• When there are parallel LSPs with the same egress router, the metrics are compared
to determine which LSP has the lowest metric value (the lowest cost) and therefore
the preferred path to the destination. If the metrics are the same, the traffic is shared.

Adjusting the metric values can force traffic to prefer some LSPs over others, regardless
of the underlying IGP metric.

• When an IGP shortcut is enabled (see “IGP Shortcuts” on page 37), an IGP route might
be installed in the routing table with an LSP as the next hop, if the LSP is on the shortest
path to the destination. In this case, the LSP metric is added to the other IGP metrics
to determine the total path metric. For example, if an LSP whose ingress router is X
and egress router is Y is on the shortest path to destination Z, the LSP metric is added
to the metric for the IGP route from Y to Z to determine the total cost of the path. If
several LSPs are potential next hops, the total metrics of the paths are compared to
determine which path is preferred (that is, has the lowest total metric). Or, IGP paths
and LSPs leading to the same destination could be compared by means of the metric
value to determine which path is preferred.

By adjusting the LSP metric, you can force traffic to prefer LSPs, prefer the IGP path,
or share the load among them.

• If router X and Y are BGP peers and if there is an LSP between them, the LSP metric
represents the total cost to reach Y from X. If for any reason the LSP reroutes, the
underlying path cost might change significantly, but X’s cost to reach Y remains the
same (the LSP metric), which allows X to report through a BGP multiple exit
discriminator (MED) a stable metric to downstream neighbors. As long as Y remains
reachable through the LSP, no changes are visible to downstream BGP neighbors.

It is possible to configure IS-IS to ignore the configured LSP metric by including the
ignore-lsp-metrics statement at the [edit protocols isis traffic-engineering shortcuts]
hierarchy level. This statement removes the mutual dependency between IS-IS and
MPLS for path computation. For more information, see the Junos OS Routing Protocols
Configuration Guide.

Configuring CSPF Tie Breaking

When selecting a path for an LSP, CSPF uses a tie-breaking process if there are several
equal-cost paths. For information about how CSPF selects a path, see “How CSPF Selects
a Path” on page 33.

Copyright © 2012, Juniper Networks, Inc. 157

Junos OS 12.1 MPLS Applications Configuration Guide

You can configure one of the following statements (you can only configure one of these
statements at a time) to alter the behavior of CSPF tie-breaking:

• To configure a random tie-breaking rule for CSPF to use to choose among equal-cost
paths, include the random statement:

random;

• To prefer the path with the least-utilized links, include the least-fill statement:

least-fill;

• To prefer the path with the most-utilized links, include the most-fill statement:

most-fill;

You can include each of these statements at the following hierarchy levels:

• [edit protocols mpls label-switched-path lsp-name]

• [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name]

Configuring Load Balancing Based on MPLS Labels

Juniper Networks routers can load-balance on a per-packet basis in MPLS. Load balancing
can be performed on information in both the IP header and on up to three MPLS labels,
providing a more uniform distribution of MPLS traffic to next hops. This feature is enabled
on supported platforms by default and requires no configuration.

Load balancing is used to evenly distribute traffic when the following conditions apply:

• There are multiple equal-cost next hops over different interfaces to the same
destination.

• There is a single next hop over an aggregated interface.

By default, when load balancing is used to help distribute traffic, Junos OS employs a
hash algorithm to select a next-hop address to install into the forwarding table. Whenever
the set of next hops for a destination changes in any way, the next-hop address is
reselected by means of the hash algorithm. You can configure how the hash algorithm
is used to load-balance traffic across a set of equal-cost label switched paths (LSPs).

An LSP tends to load-balance its placement by randomly selecting one of the equal-cost
next hops and using it exclusively. The random selection is made independently at each
transit router, which compares Interior Gateway Protocol (IGP) metrics alone. No
consideration is given to bandwidth or congestion levels.

To load-balance based on the MPLS label information, configure the family mpls
statement:

[edit forwarding-options hash-key]

family mpls {
label-1;
label-2;
label-3;

158 Copyright © 2012, Juniper Networks, Inc.

 Chapter 5: MPLS-Signaled LSP Configuration Guidelines

no-labels;
no-label-1-exp;
payload {
ether-pseudowire;
ip {
layer-3-only;
port-data {
destination-lsb;
destination-msb;
source-lsb;
source-msb;
}
}
}
}

You can include this statement at the following hierarchy levels:

• [edit logical-systems logical-system-name forwarding-options hash-key]

• [edit forwarding-options hash-key]

This feature applies to aggregated Ethernet and aggregated SONET/SDH interfaces as

well as multiple equal-cost MPLS next hops. In addition, on the T Series, MX Series, M120,
and M320 routers only, you can configure load balancing for IPv4 traffic over Layer 2
Ethernet pseudowires. You can also configure load balancing for Ethernet pseudowires
based on IP information. The option to include IP information in the hash key provides
support for Ethernet circuit cross-connect (CCC) connections.

Table 3 on page 159 provides detailed information about all of the possible MPLS LSP
load-balancing options.

Table 3: MPLS LSP Load Balancing Options

Statement MPLS LSP Load Balancing Options

label-l Include the first label in the hash key. Use this option for single label packets.

label-2 Include the second label in the hash key. You must also configure the label-1 option. The entire first
label and the first 16 bits of the second label are used in the hash key.

label-3 Include the third label in the hash key. You must also configure the label-1 option and the label-2
option.

no-labels Excludes MPLS labels from the hash key.

no-label-1-exp Excludes the EXP bit of the top label from the hash key. You must also configure the label-l option.

For Layer 2 VPNs, the router could encounter a packet reordering problem. When a burst of traffic
pushes the customer traffic bandwidth to exceed its limits, the traffic might be affected in mid flow.
Packets might be reordered as a result. By excluding the EXP bit from the hash key, you can avoid this
reordering problem.

payload Allows you to configure which parts of the IP packet payload to include in the hash key.

Copyright © 2012, Juniper Networks, Inc. 159

Junos OS 12.1 MPLS Applications Configuration Guide

Table 3: MPLS LSP Load Balancing Options (continued)

Statement MPLS LSP Load Balancing Options

ether-pseudowire (M120, M320, MX Series, and T Series routers only5)—Load-balance IPv4 traffic over Layer 2 Ethernet
pseudowires.

ip Include the IPv4 or IPv6 address in the hash key. You must also configure either label-l or no-labels.

layer-3-only Include only the Layer 3 IP information in the hash key. Excludes all of the port-data bytes from the
hash key.

port-data Include the source and destination port field information. By default, the most significant byte and
least significant byte of the source and destination port fields are used in the hash key. To select
specific bytes to use in the hash key, include one or more of the source-msb, source-lsb, destination-msb,
and destination-lsb options at the [edit forwarding-options hash-key family mpls payload ip port-data]
hierarchy level. To prevent all four bytes from being hashed, include the layer-3-only statement at the
[edit forwarding-options hash-key family mpls payload ip] hierarchy level.

destination-lsb Include the least significant byte of the destination port in the hash key. Can be combined with any
of the other port-data options.

destination-msb Include the most significant byte of the destination port in the hash key. Can be combined with any
of the other port-data options.

source-lsb Include the least significant byte of the source port in the hash key. Can be combined with any of the
other port-data options.

source-msb Include the most significant byte of the source port in the hash key. Can be combined with any of the
other port-data options.

The following examples illustrate ways in which you can configure MPLS LSP load
balancing:

• To include the IP address as well as the first label in the hash key, configure the label-1
statement and the ip option for the payload statement at the [edit forwarding-options
hash-key family mpls] hierarchy level:

[edit forwarding-options hash-key family mpls]

label-1;
payload {
ip;
}

• To include the IP address as well as both the first and second labels in the hash key,
configure the label-1 and label-2 options and the ip option for the payload statement
at the [edit forwarding-options hash-key family mpls] hierarchy level:

[edit forwarding-options hash-key family mpls]

label-1;
label-2;
payload {
ip;
}

160 Copyright © 2012, Juniper Networks, Inc.

 Chapter 5: MPLS-Signaled LSP Configuration Guidelines

NOTE: You can include this combination of statements on M320 and T

Series Core Routers only. If you include them on an M Series Multiservice
Edge Router, only the first MPLS label and the IP payload are used in the
hash key.

• For Layer 2 VPNs, the router could encounter a packet reordering problem. When a
burst of traffic pushes the customer traffic bandwidth to exceed its limits, the traffic
might be affected in mid flow. Packets might be reordered as a result. By excluding
the EXP bit from the hash key, you can avoid this reordering problem. To exclude the
EXP bit of the first label from the hash calculations, include the no-label-1-exp statement
at the [edit forwarding-options hash-key family mpls] hierarchy level:

[edit forwarding-options hash-key family mpls]

label-1;
no-label-1-exp;
payload {
ip;
}

Related • Configuring Load Balancing for Ethernet Pseudowires

Documentation

Disabling Normal TTL Decrementing

By default, the time-to-live (TTL) field value in the packet header is decremented by 1
for every hop the packet traverses in the LSP, thereby preventing loops. If the TTL field
value reaches 0, packets are dropped, and an Internet Control Message Protocol (ICMP)
error packet is sent to the originating router.

If the normal TTL decrement is disabled, the TTL field of IP packets entering LSPs are
decremented by only 1 on transiting the LSP, making the LSP appear as a one-hop router
to diagnostic tools, such as traceroute. Decrementing the TTL field by 1 is done 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 from outside that LSP,
traceroute sees the ingress router, even though the egress router performs the TTL
decrement. 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.

You can disable normal TTL decrementing in an LSP so that the TTL field value does not
reach 0 before the packet reaches its destination, thus preventing the packet from being
dropped. You can also disable normal TTL decrementing to make the MPLS cloud appear
as a single hop, thereby hiding the network topology.

Copyright © 2012, Juniper Networks, Inc. 161

Junos OS 12.1 MPLS Applications Configuration Guide

There are two ways to disable TTL decrementing:

• On the ingress of the LSP, if you include the no-decrement-ttl statement, the ingress
router negotiates with all downstream routers using a proprietary RSVP object, to
ensure all routers are in agreement. If negotiation succeeds, the whole LSP behaves
as one hop to transit IP traffic.

no-decrement-ttl;

For a list of hierarchy levels at which you can include this statement, see the statement
summary section for this statement.

NOTE: The RSVP object is proprietary to the Junos OS and might not work
with other software. This potential incompatibility applies only to
RSVP-signaled LSPs. When you include the no-decrement-ttl statement,
TTL hiding can be enforced on a per-LSP basis.

• On the ingress router, you can include the no-propagate-ttl statement. The
no-propagate-ttl statement applies to all LSPs, regardless of whether they are
RSVP-signaled or LDP-signaled. Once set, all future LSPs traversing through this router
behave as a single hop to IP packets. LSPs established before you configure this
statement are not affected.

no-propagate-ttl;

You can include this statement at the following hierarchy levels:

• [edit protocols mpls]

• [edit logical-systems logical-system-name protocols mpls]

The operation of the no-propagate-ttl statement is interoperable with other vendors’

equipment. However, you must ensure that all routers are configured identically.

To configure the TTL behavior for a single VRF routing instance, include the
no-vrf-propagate-ttl or the vrf-propagate-ttl statement in the routing instance
configuration at the [edit routing-instances instance-name] hierarchy level. The
no-vrf-propagate-ttl or the vrf-propagate-ttl statement overrides the behavior configured
globally for the router. If the router is operating in default mode with normal TTL
decrementing, the no-vrf-propagate-ttl overrides the global behavior for the routing
instance on which the no-vrf-propagate-ttl statement is configured.

Related • Example: Disabling Normal TTL Decrementing in a VRF Routing Instance (on Layer 3
Documentation VPNs Configuration Guide in the Junos VPNs Configuration Guide

Configuring MPLS Soft Preemption

Soft preemption attempts to establish a new path for a preempted LSP before tearing
down the original LSP. The default behavior is to tear down a preempted LSP first, signal
a new path, and then reestablish the LSP over the new path. In the interval between
when the path is taken down and the new LSP is established, any traffic attempting to

162 Copyright © 2012, Juniper Networks, Inc.

 Chapter 5: MPLS-Signaled LSP Configuration Guidelines

use the LSP is lost. Soft preemption prevents this type of traffic loss. The trade-off is
that during the time when an LSP is being soft preempted, two LSPs with their
corresponding bandwidth requirements are used until the original path is torn down.

MPLS soft preemption is useful for network maintenance. For example, you can move
all LSPs away from a particular interface, then take the interface down for maintenance
without interrupting traffic. MPLS soft preemption is described in detail in Internet draft
draft-ietf-mpls-soft-preemption-02.txt, MPLS Traffic Engineering Soft Preemption.

Soft preemption is a property of the LSP and is disabled by default. You configure it at
the ingress of an LSP by including the soft-preemption statement:

soft-preemption;

You can include this statement at the following hierarchy levels:

• [edit protocols mpls label-switched-path lsp-name]

• [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name]

You can also configure a timer for soft preemption. The timer designates the length of
time the router should wait before initiating a hard preemption of the LSP. At the end of
the time specified, the LSP is torn down and resignaled. The soft-preemption cleanup
timer has a default value of 30 seconds; the range of permissible values is 0 through
180 seconds. A value of 0 means that soft preemption is disabled. The soft-preemption
cleanup timer is global for all LSPs.

Configure the timer by including the cleanup-timer statement:

cleanup-timer seconds;

You can include this statement at the following hierarchy levels:

• [edit protocols rsvp preemption soft-preemption]

• [edit logical-systems logical-system-name protocols rsvp preemption soft-preemption]

NOTE: Soft preemption cannot be configured on LSPs for which secondary

paths or fast reroute has been configured. The configuration fails to commit.
However, you can enable soft preemption in conjunction with node and link
protection.

Configuring Automatic Bandwidth Allocation for LSPs

Automatic bandwidth allocation allows an MPLS tunnel to automatically adjust its

bandwidth allocation based on the volume of traffic flowing through the tunnel. You can
configure an LSP with minimal bandwidth, and this feature can dynamically adjust the
LSP’s bandwidth allocation based on current traffic patterns. The bandwidth adjustments
do not interrupt traffic flow through the tunnel.

At the end of the automatic bandwidth allocation time interval, the current maximum
average bandwidth usage is compared with the allocated bandwidth for the LSP. If the

Copyright © 2012, Juniper Networks, Inc. 163

Junos OS 12.1 MPLS Applications Configuration Guide

LSP needs more bandwidth, an attempt is made to set up a new path where bandwidth
is equal to the current maximum average usage. If the attempt is successful, the LSP’s
traffic is routed through the new path and the old path is removed. If the attempt fails,
the LSP continues to use its current path.

NOTE: You might not be able to use this feature to adjust the bandwidth of
fast-reroute LSPs. Because the LSPs use a fixed filter (FF) reservation style,
when a new path is signaled, the bandwidth might be double-counted.
Double-counting can prevent a fast-reroute LSP from ever adjusting its
bandwidth when automatic bandwidth allocation is enabled.

To configure automatic bandwidth allocation, complete the steps in the following

sections:

• Configuring MPLS Statistics for Automatic Bandwidth Allocation on page 164

• Configuring Automatic Bandwidth Allocation on LSPs on page 165
• Requesting Automatic Bandwidth Allocation Adjustment on page 169

Configuring MPLS Statistics for Automatic Bandwidth Allocation

To enable automatic bandwidth allocation, you first need to configure MPLS statistics.
Include the auto-bandwidth option for the statistics statement. You can also use the
interval option to specify the interval for calculating the average bandwidth usage.

These settings apply to all LSPs configured on the router on which you have also
configured the auto-bandwidth statement at the [edit protocols mpls label-switched-path
label-switched-path-name] hierarchy level. You can also set the adjustment interval on
specific LSPs.

NOTE: To prevent unnecessary resignaling of LSPs, it is best to configure an

LSP adjustment interval that is at least three times longer than the MPLS
automatic bandwidth statistics interval. For example, if you configure a value
of 30 seconds for the MPLS automatic bandwidth statistics interval (interval
statement at the [edit protocols mpls statistics] hierarchy level), you should
configure a value of at least 90 seconds for the LSP adjustment interval
(adjust-interval statement at the [edit protocols mpls label-switched-path
label-switched-path-name auto-bandwidth] hierarchy level). See also
“Configuring the Automatic Bandwidth Allocation Interval” on page 165.

To configure the MPLS and automatic bandwidth allocation statistics, include the
statistics statement:

statistics {
auto-bandwidth;
file filename <files number> <size size> <world-readable | no-world-readable>;
interval seconds;
}

164 Copyright © 2012, Juniper Networks, Inc.

 Chapter 5: MPLS-Signaled LSP Configuration Guidelines

You can include this statement at the following hierarchy levels:

• [edit protocols mpls]

• [edit logical-systems logical-system-name protocols mpls]

Configuring Automatic Bandwidth Allocation on LSPs

To enable automatic bandwidth allocation on an LSP, include the auto-bandwidth
statement:

auto-bandwidth {
adjust-interval seconds;
adjust-threshold percent;
adjust-threshold-overflow-limit number;
adjust-threshold-underflow-limit number;
minimum-bandwidth bps;
maximum-bandwidth bps;
monitor-bandwidth;
}

You can include this statement at the following hierarchy levels:

• [edit protocols mpls label-switched-path lsp-name]

• [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name]

The statements configured at the [edit protocols mpls label-switched-path

label-switched-path-name auto-bandwidth] hierarchy level are optional and explained in
the following sections:

• Configuring the Automatic Bandwidth Allocation Interval on page 165

• Configuring the Maximum and Minimum Bounds of the LSP’s Bandwidth on page 166
• Configuring the Automatic Bandwidth Adjustment Threshold on page 166
• Configuring a Limit on Bandwidth Overflow and Underflow Samples on page 167
• Configuring Passive Bandwidth Utilization Monitoring on page 169

Configuring the Automatic Bandwidth Allocation Interval

At the end of the automatic bandwidth allocation interval, the automatic bandwidth
computation and new path setup process is triggered.

NOTE: To prevent unnecessary resignaling of LSPs, it is best to configure an

LSP adjustment interval that is at least three times longer than the MPLS
automatic bandwidth statistics interval. For example, if you configure a value
of 30 seconds for the MPLS automatic bandwidth statistics interval (interval
statement at the [edit protocols mpls statistics] hierarchy level), you should
configure a value of at least 90 seconds for the LSP adjustment interval
(adjust-interval statement at the [edit protocols mpls label-switched-path
label-switched-path-name auto-bandwidth] hierarchy level). See also
“Configuring MPLS Statistics for Automatic Bandwidth Allocation” on page 164.

Copyright © 2012, Juniper Networks, Inc. 165

Junos OS 12.1 MPLS Applications Configuration Guide

To specify the bandwidth reallocation interval in seconds for a specific LSP, include the
adjust-interval statement:

adjust-interval seconds;

You can include this statement at the following hierarchy levels:

• [edit protocols mpls label-switched-path lsp-name auto-bandwidth]

• [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name

auto-bandwidth]

Configuring the Maximum and Minimum Bounds of the LSP’s Bandwidth

You can maintain the LSP’s bandwidth between minimum and maximum bounds by
specifying values for the minimum-bandwidth and maximum-bandwidth statements.

To specify the minimum amount of bandwidth allocated for a specific LSP, include the
minimum-bandwidth statement:

minimum-bandwidth bps;

You can include this statement at the following hierarchy levels:

• [edit protocols mpls label-switched-path lsp-name auto-bandwidth]

• [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name

auto-bandwidth]

To specify the maximum amount of bandwidth allocated for a specific LSP, include the
maximum-bandwidth statement:

maximum-bandwidth bps;

You can include this statement at the following hierarchy levels:

• [edit protocols mpls label-switched-path lsp-name auto-bandwidth]

• [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name

auto-bandwidth]

Configuring the Automatic Bandwidth Adjustment Threshold

Use the adjust-threshold statement to specify the sensitivity of the automatic bandwidth
adjustment of an LSP to changes in bandwidth utilization. You can set the threshold for
when to trigger automatic bandwidth adjustments. When configured, bandwidth demand
for the current interval is determined and compared to the LSP’s current bandwidth
allocation. If the percentage difference in bandwidth is greater than or equal to the
specified adjust-threshold percentage, the LSP’s bandwidth is adjusted to the current
bandwidth demand.

For example, assume that the current bandwidth allocation is 100 megabits per second
(Mbps) and that the percentage configured for the adjust-threshold statement is 15
percent. If the bandwidth demand increases to 110 Mbps, the bandwidth allocation is not
adjusted. However, if the bandwidth demand increases to 120 Mbps (20 percent over

166 Copyright © 2012, Juniper Networks, Inc.

 Chapter 5: MPLS-Signaled LSP Configuration Guidelines

the current allocation) or decreases to 80 Mbps (20 percent under the current allocation),
the bandwidth allocation is increased to 120 Mbps or decreased to 80 Mbps, respectively.

To configure the threshold for automatic bandwidth adjustment, include the

adjust-threshold statement:

adjust-threshold percent;

You can include this statement at the following hierarchy levels:

• [edit protocols mpls label-switched-path lsp-name auto-bandwidth]

• [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name

auto-bandwidth]

Configuring a Limit on Bandwidth Overflow and Underflow Samples

The automatic bandwidth adjustment timer is a periodic timer which is triggered every
adjust interval to determine whether any bandwidth adjustments are required on the
LSP's active path. This interval is typically configured as a long period of time, usually
hours. If, at the end of adjust interval, the change in bandwidth is above a certain adjust
threshold, the LSP is resignaled with the new bandwidth.

During the automatic bandwidth adjustment interval, the router might receive a steady
increase in traffic (increasing bandwidth utilization) on an LSP, potentially causing
congestion or packet loss. To prevent this, you can define a second trigger to prematurely
expire the automatic bandwidth adjustment timer before the end of the current
adjustment interval.

Every statistics interval, the router samples the average bandwidth utilization of an LSP
and if this has exceeded the current maximum average bandwidth utilization, the
maximum average bandwidth utilization is updated.

During each sample period, the following conditions are also checked:

• Is the current average bandwidth utilization above the active bandwidth of the path?

• Has the difference between the average bandwidth utilization and the active bandwidth
exceeded the adjust threshold (bandwidth utilization has changed significantly)?

If these conditions are true, it is considered to be one bandwidth overflow sample. Using
the adjust-threshold-overflow-limit statement, you can define a limit on the number of
bandwidth overflow samples such that when the limit is reached, the current automatic
bandwidth adjustment timer is expired and a bandwidth adjustment is triggered. Once
this adjustment is complete, the normal automatic bandwidth adjustment timer is reset
to expire after the periodic adjustment interval.

To specify a limit on the number of bandwidth overflow samples before triggering an

automatic bandwidth allocation adjustment, configure the adjust-threshold-overflow-limit
statement:

adjust-threshold-overflow-limit number;

Copyright © 2012, Juniper Networks, Inc. 167

Junos OS 12.1 MPLS Applications Configuration Guide

Similarly, you can specify a limit on the number of bandwidth underflow samples before
triggering an automatic bandwidth allocation adjustment by configuring the
adjust-threshold-underflow-limit statement:

adjust-threshold-underflow-limit number;

These statements can be configured at the following hierarchy levels:

• [edit protocols mpls label-switched-path lsp-name auto-bandwidth]

• [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name

auto-bandwidth]

You must configure the adjust-threshold and minimum-bandwidth statements whenever

you configure the adjust-threshold-underflow-limit statement. You must configure the
adjust-threshold and maximum-bandwidth statements whenever you configure the
adjust-threshold-overflow-limit statement

• You must configure a nonzero value for the adjust-threshold statement if you configure
the adjust-threshold-overflow-limit or adjust-threshold-underflow-limit statement.

• Any bandwidth increase or decrease below the value configured for the adjust-threshold
statement does not constitute an overflow or underflow condition.

• To prevent unlimited increases in LSP bandwidth (to limit overflow beyond a certain
bandwidth), you must also configure the maximum-bandwidth statement when you
configure the adjust-threshold-overflow-limit statement.

The following describes the other aspects of the adjust-threshold-overflow-limit

statement:

• It only applies to bandwidth overflows. If the bandwidth is decreasing, the normal

automatic bandwidth adjustment interval is used.

• It does not affect manually triggered automatic bandwidth adjustment.

• It applies to single-class DiffServ-TE LSPs.

• Because the adjust-threshold-overflow-limit statement can trigger a bandwidth

adjustment, it cannot be enabled at the same time as the monitor-bandwidth statement
(for information about that statement, see “Configuring Passive Bandwidth Utilization
Monitoring” on page 169).

• You cannot configure automatic bandwidth adjustments to occur more often than
every 300 seconds. The adjust-threshold-overflow-limit statement is subject to the
same minimum value with regard to the minimum frequency of adjustment allowed.
Overflow condition based adjustments can occur no sooner than 300 seconds from
the start of the overflow condition. Therefore it is required that:

sample interval x adjust-threshold-overflow-limit >= 300s

These values are checked during the commit operation. An error is returned if the value
is less than 300 seconds.

• If you change the value of the adjust-threshold-overflow-limit statement on a working

router, you can expect the following behavior:

168 Copyright © 2012, Juniper Networks, Inc.

 Chapter 5: MPLS-Signaled LSP Configuration Guidelines

• If you increase the current value of the adjust-threshold-overflow-limit statement,

the old value is replaced with the new one.

• If you decrease the current value of the adjust-threshold-overflow-limit statement

and the current bandwidth overflow count is less than the new value, the old value
is replaced with the new one.

• If you decrease the current value of the adjust-threshold-overflow-limit statement

and the current bandwidth overflow count is greater than the new value, the
adjustment timer is immediately expired and a bandwidth adjustment is initiated.

Configuring Passive Bandwidth Utilization Monitoring

Use the monitor-bandwidth statement to switch to a passive bandwidth utilization

monitoring mode. In this mode, no automatic bandwidth adjustments are made, but the
maximum average bandwidth utilization is continuously monitored and recorded.

To configure passive bandwidth utilization monitoring, include the monitor-bandwidth

statement:

monitor-bandwidth;

You can include this statement at the following hierarchy levels:

• [edit protocols mpls label-switched-path lsp-name auto-bandwidth]

• [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name

auto-bandwidth]

If you have configured an LSP with primary and secondary paths, the automatic bandwidth
allocation statistics are carried over to the secondary path if the primary path fails. For
example, consider a primary path whose adjustment interval is half complete and whose
maximum average bandwidth usage is currently calculated as 50 Mbps. If the primary
path suddenly fails, the time remaining for the next adjustment and the maximum average
bandwidth usage are carried over to the secondary path.

Requesting Automatic Bandwidth Allocation Adjustment

For MPLS LSP automatic bandwidth allocation adjustment, the minimum value for the
adjustment interval is 5 minutes (300 seconds). You might find it necessary to trigger a
bandwidth allocation adjustment manually, for example in the following circumstances:

• When you are testing automatic bandwidth allocation in a network lab.

• When the LSP is configured for automatic bandwidth allocation in monitor mode (the
monitor-bandwidth statement is included in the configuration as described in
“Configuring Passive Bandwidth Utilization Monitoring” on page 169), and want to initiate
an immediate bandwidth adjustment.

To use the request mpls lsp adjust-autobandwidth command, the following must be true:

• Automatic bandwidth allocation must be enabled on the LSP.

Copyright © 2012, Juniper Networks, Inc. 169

Junos OS 12.1 MPLS Applications Configuration Guide

• The criteria required to trigger a bandwidth adjustment have been met (the difference
between the adjust bandwidth and the current LSP path bandwidth is greater than
the threshold limit).

A manually triggered bandwidth adjustment operates only on the active LSP path. Also,
if you have enabled periodic automatic bandwidth adjustment, the periodic automatic
bandwidth adjustment parameters (the adjustment interval and the maximum average
bandwidth) are not reset after a manual adjustment.

For example, suppose the periodic adjust interval is 10 hours and there are currently
5 hours remaining before an automatic bandwidth adjustment is triggered. If you initiate
a manual adjustment with the request mpls lsp adjust-autobandwidth command, the
adjust timer is not reset and still has 5 hours remaining.

To manually trigger a bandwidth allocation adjustment, you need to use the request mpls
lsp adjust-autobandwidth command. You can trigger the command for all affected LSPs
on the router, or you can specify a particular LSP:

user@host> request mpls lsp adjust-autobandwidth

Once you execute this command, the automatic bandwidth adjustment validation process
is triggered. If all the criteria for adjustment are met, the LSP’s active path bandwidth is
adjusted to the adjusted bandwidth value determined during the validation process.

Related • request mpls lsp adjust-autobandwidth

Documentation

Disabling Constrained-Path LSP Computation

If the IGP is a link-state protocol (such as IS-IS or OSPF) and supports extensions that
allow the current bandwidth reservation on each router’s link to be reported,
constrained-path LSPs are computed by default.

The Junos implementations of IS-IS and OSPF include the extensions that support
constrained-path LSP computation.

• IS-IS—These extensions are enabled by default. To disable this support, include the
disable statement at the [edit protocols isis traffic-engineering] hierarchy level, as
discussed in the Junos OS Routing Protocols Configuration Guide.

• OSPF—These extensions are disabled by default. To enable this support, include the
traffic-engineering statement in the configurations of all routers running OSPF, as
described in the Junos OS Routing Protocols Configuration Guide.

If IS-IS is enabled on a router or you enable OSPF traffic engineering extensions, MPLS
performs the constrained-path LSP computation by default. For information about how
constrained-path LSP computation works, see “Constrained-Path LSP Computation”
on page 32.

Constrained-path LSPs have a greater chance of being established quickly and

successfully for the following reasons:

• The LSP computation takes into account the current bandwidth reservation.

170 Copyright © 2012, Juniper Networks, Inc.

 Chapter 5: MPLS-Signaled LSP Configuration Guidelines

• Constrained-path LSPs reroute themselves away from node failures and congestion.

When constrained-path LSP computation is enabled, you can configure the LSP so that
it is periodically reoptimized, as described in “Optimizing Signaled LSPs” on page 180.

When an LSP is being established or when an existing LSP fails, the constrained-path
LSP computation is repeated periodically at the interval specified by the retry timer until
the LSP is set up successfully. Once the LSP is set up, no recomputation is done. For more
information about the retry timer, see “Configuring the Connection Between Ingress and
Egress Routers” on page 155.

By default, constrained-path LSP computation is enabled. You might want to disable

constrained-path LSP computation when all nodes do not support the necessary traffic
engineering extensions. To disable constrained-path LSP computation, include the
no-cspf statement:

no-cspf;

For a list of hierarchy levels at which you can include this statement, see the statement
summary section for this statement.

If you disable constrained-path LSP computation on LSPs by configuring the no-cspf

statement and then attempt to advertise other LSPs with lower metrics than the IGPs
from this router in either IS-IS or OSPF, new LSPs cannot be established.

Configuring Administrative Groups

Administrative groups, also known as link coloring or resource class, are manually assigned
attributes that describe the “color” of links, such that links with the same color
conceptually belong to the same class. You can use administrative groups to implement
a variety of policy-based LSP setups.

Administrative groups are meaningful only when constrained-path LSP computation is

enabled.

You can assign up to 32 names and values (in the range 0 through 31), which define a
series of names and their corresponding values. The administrative names and values
must be identical across all routers within a single domain.

NOTE: The administrative value is distinct from the priority. You configure
the priority for an LSP using the priority statement. See “Configuring Priority
and Preemption for LSPs” on page 179.

To configure administrative groups, follow these steps:

1. Define multiple levels of service quality by including the admin-groups statement:

admin-groups {
group-name group-value;
}

Copyright © 2012, Juniper Networks, Inc. 171

Junos OS 12.1 MPLS Applications Configuration Guide

You can include this statement at the following hierarchy levels:

• [edit protocols mpls]

• [edit logical-systems logical-system-name protocols mpls]

The following configuration example illustrates how you might configure a set of
administrative names and values for a domain:

[edit protocols mpls]

admin-groups {
gold 1;
silver 2;
copper 3;
best-effort 4;
}

2. Define the administrative groups to which an interface belongs. You can assign multiple
groups to an interface. Include the interface statement:

interface interface-name {
admin-group [ group-names ];
}

You can include this statement at the following hierarchy levels:

• [edit protocols mpls]

• [edit logical-systems logical-system-name protocols mpls]

If you do not include the admin-group statement, an interface does not belong to any
group.

IGPs use the group information to build link-state packets, which are then flooded
throughout the network, providing information to all nodes in the network. At any
router, the IGP topology, as well as administrative groups of all the links, is available.

Changing the interface’s administrative group affects only new LSPs. Existing LSPs
on the interface are not preempted or recomputed to keep the network stable. If LSPs
need to be removed because of a group change, issue the clear rsvp session command.

3. Configure an administrative group constraint for each LSP or for each primary or
secondary LSP path. Include the label-switched-path statement:

label-switched-path lsp-name {
to address;
...
admin-group {
exclude [ group-names ];
include-all [ group-names ];
include-any [ group-names ];
}
primary path-name {
admin-group {
exclude [ group-names ];
include-all [ group-names ];
include-any [ group-names ];
}

172 Copyright © 2012, Juniper Networks, Inc.

 Chapter 5: MPLS-Signaled LSP Configuration Guidelines

}
secondary path-name {
admin-group {
exclude [ group-names ];
include-all [ group-names ];
include-any [ group-names ];
}
}
}

You can include the label-switched-path statement at the following hierarchy levels:

• [edit protocols mpls]

• [edit logical-systems logical-system-name protocols mpls]

If you omit the include-all, include-any, or exclude statements, the path computation
proceeds unchanged. The path computation is based on the constrained-path LSP
computation. For information about how the constrained-path LSP computation is
calculated, see “How CSPF Selects a Path” on page 33.

NOTE: Changing the LSP’s administrative group causes an immediate

recomputation of the route; therefore, the LSP might be rerouted.

Configuring Extended Administrative Groups

In MPLS traffic engineering, a link can be configured with a set of administrative groups
(also known as colors or resource classes). Administrative groups are carried in the interior
gateway protocol (IGP) (OSPFv2 and IS-IS) as a 32-bit value assigned to each link.
Juniper Networks routers normally interpret this 32-bit value as a bit mask with each bit
representing a group, limiting each network to a total of 32 distinct administrative groups
(value range 0 through 31).

You configure extended administrative groups, represented by a 32-bit value, expanding

the number of administrative groups supported in the network beyond just 32. The original
range of values available for administrative groups is still supported for backwards
compatibility.

The extended administrative groups configuration accepts a set of interfaces with a

corresponding set of extended administrative group names. It converts the names into
a set of 32-bit values and propagates this information into the IGP. The extended
administrative group values are global and must be identically configured on all the
supported routers participating in the network. The domain-wide extended administrative
groups database, learned from other routers through IGP flooding, is used by Constrained
Shortest Path First (CSPF) for path computation.

The following procedure describes how to configure extended administrative groups:

1. Configure the admin-groups-extended-range statement:

admin-groups-extended-range {
maximum maximum-number;

Copyright © 2012, Juniper Networks, Inc. 173

Junos OS 12.1 MPLS Applications Configuration Guide

mininum minimum-number;
}

You can include this statement at the following hierarchy levels:

• [edit routing-options]

• [edit logical-systems logical-system-name routing-options]

The admin-groups-extended-range statement includes the minimum and maximum

options. The range maximum must be greater than the range minimum.

2. Configure the admin-groups-extended statement:

admin-groups-extended group-name {
group-value group-identifier;
}

You can include this statement at the following hierarchy levels:

• [edit routing-options]

• [edit logical-systems logical-system-name routing-options]

The admin-groups-extended statement enables you to configure a group name and

group value for the administrative group. The group value must be within the range
of values configured using the admin-groups-extended-range statement.

3. The extended administrative groups for an MPLS interface consist of the set of
extended administrative group names assigned for the interface. The interface
extended administrative group names must be configured for the global extended
administrative groups.

To configure an extended administrative group for an MPLS interface, specify the

administrative group name within the MPLS interface configuration using the
admin-groups-extended statement:

admin-groups-extended group-name;

You can include this statement at the following hierarchy levels:

• [edit protocols mpls interface interface-name]

• [edit logical-systems logical-system-name protocols mpls interface interface-name]

4. The LSP extended administrative groups define the set of include and exclude
constraints for an LSP and for a path’s primary and secondary paths. The extended
administrative group names must be configured for the global extended administrative
groups.

To configure extended administrative groups for an LSP, include the

admin-group-extended statement at an LSP hierarchy level:

admin-group-extended {
apply-groups group-value;
apply-groups-except group-value;
exclude group-value;
include-all group-value;
include-any group-value;

174 Copyright © 2012, Juniper Networks, Inc.

 Chapter 5: MPLS-Signaled LSP Configuration Guidelines

The admin-group-extended statement includes the following options: apply-groups,

apply-groups-except, exclude, include-all, and include-any. Each option enables you
to configure one or more extended administrative groups.

For the list of the hierarchy levels at which you can configure this statement, see the
statement summary for this statement.

5. To display the currently configured extended administrative groups, issue the show
mpls admin-groups-extended command.

Related • Configuring Administrative Groups on page 171

Documentation

Configuring Preference Values for LSPs

As an option, you can configure multiple LSPs between the same pair of ingress and
egress routers. This is useful for balancing the load among the LSPs because all LSPs,
by default, have the same preference level. To prefer one LSP over another, set different
preference levels for individual LSPs. The LSP with the lowest preference value is used.
The default preference for RSVP LSPs is 7 and for LDP LSPs is 9. These preference values
are lower (more preferred) than all learned routes except direct interface routes.

To change the default preference value, include the preference statement:

preference preference;

For a list of hierarchy levels at which you can include this statement, see the statement
summary section for this statement.

Disabling Path Route Recording

The Junos implementation of RSVP supports the Record Route object, which allows an
LSP to actively record the routers through which it transits. You can use this information
for troubleshooting and to prevent routing loops. By default, path route information is
recorded. To disable recording, include the no-record statement:

no-record;

For a list of hierarchy levels at which you can include the record and no-record statements,
see the statement summary section for the statement.

Configuring Class of Service for MPLS LSPs

The following sections provide an overview of MPLS class of service (CoS) and describe
how to configure the MPLS CoS value:

• Class of Service for MPLS Overview on page 176

• Configuring the MPLS CoS Bits on page 176
• Rewriting IEEE 802.1p Packet Headers with the MPLS CoS Value on page 177

Copyright © 2012, Juniper Networks, Inc. 175

Junos OS 12.1 MPLS Applications Configuration Guide

Class of Service for MPLS Overview

When IP traffic enters an LSP tunnel, the ingress router marks all packets with a CoS
value, which is used to place the traffic into a transmission priority queue. On the router,
for SDH/SONET and T3 interfaces, each interface has four transmit queues. The CoS
value is encoded as part of the MPLS header and remains in the packets until the MPLS
header is removed when the packets exit from the egress router. The routers within the
LSP utilize the CoS value set at the ingress router. The CoS value is encoded by means
of the CoS bits (also known as the EXP or experimental bits). For more information, see
“Label Allocation” on page 28.

MPLS class of service works in conjunction with the router’s general CoS functionality.
If you do not configure any CoS features, the default general CoS settings are used. For
MPLS class of service, you might want to prioritize how the transmit queues are serviced
by configuring weighted round-robin, and to configure congestion avoidance using random
early detection (RED). The general CoS features are described in the Junos OS Class of
Service Configuration Guide.

Configuring the MPLS CoS Bits

When traffic enters an LSP tunnel, the CoS bits in the MPLS header are set in one of two
ways:

• The number of the output queue into which the packet was buffered and the packet
loss priority (PLP) bit are written into the MPLS header and are used as the packet’s
CoS value. This behavior is the default, and no configuration is required. The Junos OS
Class of Service Configuration Guide explains the IP CoS values, and summarizes how
the CoS bits are treated.

• You set a fixed CoS value on all packets entering the LSP tunnel. A fixed CoS value
means that all packets entering the LSP receive the same class of service.

To set a fixed CoS value on all packets entering the LSP, include the class-of-service
statement:

class-of-service cos-value;

For a list of hierarchy levels at which you can include this statement, see the statement
summary section for this statement.

The CoS value set using the class-of-service statement at the [edit protocols mpls]
hierarchy level supersedes the CoS value set at the [edit class-of-service] hierarchy level
for an interface. Effectively, the CoS value configured for an LSP overrides the CoS value
set for an interface.

The CoS value can be a decimal number from 0 through 7. This number corresponds to
a 3-bit binary number. The high-order 2 bits of the CoS value select which transmit queue
to use on the outbound interface card.

The low-order bit of the CoS value is treated as the PLP bit and is used to select the RED
drop profile to use on the output queue. If the low-order bit is 0, the non-PLP drop profile
is used, and if the low-order bit is 1, the PLP drop profile is used. It is generally expected

176 Copyright © 2012, Juniper Networks, Inc.

 Chapter 5: MPLS-Signaled LSP Configuration Guidelines

that RED will more aggressively drop packets that have the PLP bit set. For more
information about RED and drop profiles, see the Junos OS Class of Service Configuration
Guide.

NOTE: Configuring the PLP drop profile to drop packets more aggressively
(for example, setting the CoS value from 6 to 7) decreases the likelihood of
traffic getting through.

Table 4 on page 177 summarizes how MPLS CoS values correspond to the transmit queue
and PLP bit. Note that in MPLS, the mapping between the CoS bit value and the output
queue is hard-coded. You cannot configure the mapping for MPLS; you can configure it
only for IPv4 traffic flows, as described in the Junos OS Class of Service Configuration Guide.

Table 4: MPLS CoS Values

MPLS CoS Value Bits Transmit Queue PLP Bit

0 000 0 Not set

1 001 0 Set

2 010 1 Not set

3 011 1 Set

4 100 2 Not set

5 101 2 Set

6 110 3 Not set

7 111 3 Set

Because the CoS value is part of the MPLS header, the value is associated with the
packets only as they travel through the LSP tunnel. The value is not copied back to the
IP header when the packets exit from the LSP tunnel.

Rewriting IEEE 802.1p Packet Headers with the MPLS CoS Value
For Ethernet interfaces installed on a T Series router or an M320 router with a peer
connection to an M Series router or a T Series router, you can rewrite both MPLS CoS
and IEEE 802.1p bits to a configured value (the MPLS CoS bits are also known as the EXP
or experimental bits). Rewriting these bits allows you to pass the configured value to the
Layer 2 VLAN path. To rewrite both the MPLS CoS and IEEE 802.1p bits, you must include
the EXP and IEEE 802.1p rewrite rules in the class of service interface configuration. The
EXP rewrite table is applied when you configure the IEEE 802.1p and EXP rewrite rules.

For information about how to configure the EXP and IEEE 802.1p rewrite rules, see the
Junos OS Class of Service Configuration Guide.

Copyright © 2012, Juniper Networks, Inc. 177

Junos OS 12.1 MPLS Applications Configuration Guide

Configuring Adaptive LSPs

An LSP occasionally might need to reroute itself for these reasons:

• The continuous reoptimization process is configured with the optimize-timer statement.

• The current path has connectivity problems.

• The LSP is preempted by another LSP configured with the priority statement and is
forced to reroute.

• The explicit-path information for an active LSP is modified, or the LSP’s bandwidth is
increased.

You can configure an LSP to be adaptive when it is attempting to reroute itself. When it
is adaptive, the LSP holds onto existing resources until the new path is successfully
established and traffic has been cut over to the new LSP. To retain its resources, an
adaptive LSP does the following:

• Maintains existing paths and allocated bandwidths—This 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.

• 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. You can include the adaptive statement in two
different hierarchy levels.

If you specify the adaptive statement at the LSP hierarchy levels, the adaptive behavior
is enabled on all primary/secondary paths of the LSP. This means both the primary and
secondary paths share the same bandwidth on common links.

To configure adaptive behavior for all LSP paths, include the adaptive statement in the
LSP configuration:

adaptive;

You can include this statement at the following hierarchy levels:

• [edit protocols mpls label-switched-path lsp-name]

• [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name]

If you specify the adaptive statement at the [edit protocols mpls label-switched-path
lsp-name (primary | secondary) path-name] hierarchy level, adaptive behavior is enabled
only on the path on which it is specified. Bandwidth double-counting occurs between
different paths. However, if you also have the adaptive statement configured at the [edit
protocols mpls label-switched-path lsp-name] hierarchy level, it overrides the adaptive
behavior of each individual path.

178 Copyright © 2012, Juniper Networks, Inc.

 Chapter 5: MPLS-Signaled LSP Configuration Guidelines

To configure adaptive behavior for either the primary or secondary level, include the
adaptive statement:

adaptive;

You can include this statement at the following hierarchy levels:

• [edit protocols mpls label-switched-path lsp-name (primary | secondary) path-name]

• [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name

(primary | secondary) path-name]

Configuring Priority and Preemption for LSPs

When there is insufficient bandwidth to establish a more important LSP, you might want
to tear down a less important existing LSP to free the bandwidth. You do this by
preempting the existing LSP.

Whether an LSP can be preempted is determined by two properties associated with the
LSP:

• Setup priority—Determines whether a new LSP that preempts an existing LSP can be
established. For preemption to occur, the setup priority of the new LSP must be higher
than that of the existing LSP. Also, the act of preempting the existing LSP must produce
sufficient bandwidth to support the new LSP. That is, preemption occurs only if the
new LSP can be set up successfully.

• Reservation priority—Determines the degree to which an LSP holds on to its session

reservation after the LSP has been set up successfully. When the reservation priority
is high, the existing LSP is less likely to give up its reservation, and hence it is unlikely
that the LSP can be preempted.

You cannot configure an LSP with a high setup priority and a low reservation priority,
because permanent preemption loops might result if two LSPs are allowed to preempt
each other. You must configure the reservation priority to be higher than or equal to the
setup priority.

The setup priority also defines the relative importance of LSPs on the same ingress router.
When the software starts, when a new LSP is established, or during fault recovery, the
setup priority determines the order in which LSPs are serviced. Higher-priority LSPs tend
to be established first and hence enjoy more optimal path selection.

To configure the LSP’s preemption properties, include the priority statement:

priority setup-priority reservation-priority;

For a list of hierarchy levels at which you can include this statement, see the statement
summary section for this statement.

Both setup-priority and reservation-priority can be a value from 0 through 7. The value 0
corresponds to the highest priority, and the value 7 to the lowest. By default, an LSP has
a setup priority of 7 (that is, it cannot preempt any other LSPs) and a reservation priority
of 0 (that is, other LSPs cannot preempt it). These defaults are such that preemption

Copyright © 2012, Juniper Networks, Inc. 179

Junos OS 12.1 MPLS Applications Configuration Guide

does not happen. When you are configuring these values, the setup priority should always
be less than or equal to the hold priority.

Optimizing Signaled LSPs

Once an LSP has been established, topology or resources changes might, over time,
make the path suboptimal. A new path might have become available that is less
congested, has a lower metric, and traverses fewer hops. You can configure the router
to recompute paths periodically to determine whether a more optimal path has become
available.

If reoptimization is enabled, an LSP can be rerouted through different paths by

constrained-path recomputations. However, if reoptimization is disabled, the LSP has a
fixed path and cannot take advantage of newly available network resources. The LSP is
fixed until the next topology change breaks the LSP and forces a recomputation.

Reoptimization is not related to failover. A new path is always computed when topology
failures occur that disrupt an established path.

Because of the potential system overhead involved, you need to control carefully the
frequency of reoptimization. Network stability might suffer when reoptimization is enabled.
By default, the optimize-timer statement is set to 0 (that is, it is disabled).

Configuring LSP optimization is meaningful only when constrained-path LSP computation

is enabled, which is the default behavior. For more information about constrained-path
LSP computation, see “Disabling Constrained-Path LSP Computation” on page 170.

To enable path reoptimization, include the optimize-timer statement:

optimize-timer seconds;

For a list of hierarchy levels at which you can include this statement, see the statement
summary section for this statement.

Once you have configured the optimize-timer statement, the reoptimization timer
continues its countdown to the configured value even if you delete the optimize-timer
statement from the configuration. The next optimization uses the new value. You can
force the Junos OS to use a new value immediately by deleting the old value, committing
the configuration, configuring the new value for the optimize-timer statement, and then
committing the configuration again.

After reoptimization is run, the result is accepted only if it meets the following criteria:

1. The new path is not higher in IGP 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 IGP metric, it is not more hops away.

3. The new path does not cause preemption. (This is to reduce the ripple effect of
preemption causing more preemption.)

4. The new path does not worsen congestion overall.

180 Copyright © 2012, Juniper Networks, Inc.

 Chapter 5: MPLS-Signaled LSP Configuration Guidelines

The relative congestion of the new path is determined as follows:

a. The percentage of available bandwidth on each link traversed by the new path is
compared to that for the old path, starting from the most congested links.

b. For each current (old) path, the software stores the four smallest values for
bandwidth availability for the links traversed in ascending order.

c. The software also stores the four smallest bandwidth availability values for the
new path, corresponding to the links traversed in ascending order.

d. If any of the four new available bandwidth values are smaller than any of the
corresponding old bandwidth availability values, the new path has at least one link
that is more congested than the link used by the old path. Because using the link
would cause more congestion, traffic is not switched to this new path.

e. If none of the four new available bandwidth values is smaller than the corresponding
old bandwidth availability values, the new path is less congested than the old path.

When all the above conditions are met, then:

5. If the new path has a lower IGP metric, it is accepted.

6. If the new path has an equal IGP metric and lower hop count, it is accepted.

7. If you choose least-fill as a load balancing algorithm, LSPs are load balanced as
follows:

a. The LSP is moved to a new path that is utilized at least 10% less than the current
path. This might reduce congestion on the current path by only a small amount.
For example, if an LSP with 1 MB of bandwidth is moved off a path carrying a
minimum of 200 MB, congestion on the original path is reduced by less than 1%.

b. For random or most-fill algorithms, this rule does not apply.

The following example illustrates how the least-fill load balancing algorithm works.

Figure 21: least-fill Load Balancing Algorithm Example

L1 L3 L5 L7 L9 L11 L13
A B C D E F G H
g040560

L2 L4 L6 L8 L10 L12 L14

As shown in Figure 21 on page 181, there are two potential paths for an LSP to traverse
from router A to router H, the odd links from L1 through L13 and the even links from L2
through L14. Currently, the router is using the even links as the active path for the LSP.
Each link between the same two routers (for example, router A and router B) has the
same bandwidth:

• L1, L2 = 10GE

• L3, L4 = 1GE

• L5, L6 = 1GE

Copyright © 2012, Juniper Networks, Inc. 181

Junos OS 12.1 MPLS Applications Configuration Guide

• L7, L8 = 1GE

• L9, L10 = 1GE

• L11, L12 = 10GE

• L13, L14 = 10GE

The 1GE links are more likely to be congested. In this example, the odd 1GE links have
the following available bandwidth:

• L3 = 41%

• L5 = 56%

• L7 = 66%

• L9 = 71%

The even 1GE links have the following available bandwidth:

• L4 = 37%

• L6 = 52%

• L8 = 61%

• L10 = 70%

Based on this information, the router would calculate the difference in available
bandwidth between the odd links and the even links as follows:

• L4 - L3 = 41% - 37% = 4%

• L6 - L5 = 56% - 52% = 4%

• L8 - L7 = 66% - 61% = 5%

• L10 - L9 = 71% - 70% = 1%

The total additional bandwidth available over the odd links is 14% (4% + 4% + 5%
+ 1%). Since 14% is greater than 10% (the least-fill algorithm minimum threshold),
the LSP is moved to the new path over the odd links from the original path using the
even links.

8. Otherwise, the new path is rejected.

You can disable the following reoptimization criteria (a subset of the criteria listed
previously):

• If the new path has the same IGP metric, it is not more hops away.

• The new path does not cause preemption. (This is to reduce the ripple effect of
preemption causing more preemption.)

182 Copyright © 2012, Juniper Networks, Inc.

 Chapter 5: MPLS-Signaled LSP Configuration Guidelines

• The new path does not worsen congestion overall.

• If the new path has an equal IGP metric and lower hop count, it is accepted.

To disable them, either issue the clear mpls lsp optimize-aggressive command or include
the optimize-aggressive statement:

optimize-aggressive;

You can include this statement at the following hierarchy levels:

• [edit protocols mpls]

• [edit logical-systems logical-system-name protocols mpls]

Including the optimize-aggressive statement in the configuration causes the reoptimization

procedure to be triggered more often. Paths are rerouted more frequently. It also limits
the reoptimization algorithm to the IGP metric only.

Configuring the Smart Optimize Timer

Because of network and router resource constraints, it is typically inadvisable to configure

a short interval for the optimize timer. However, under certain circumstances, it might be
desirable to reoptimize a path sooner than would normally be provided by the optimize
timer.

For example, an LSP is traversing a preferred path that subsequently fails. The LSP is
then switched to a less desirable path to reach the same destination. Even if the original
path is quickly restored, it could take an excessively long time for the LSP to use it again,
because it has to wait for the optimize timer to reoptimize the network paths. For such
situations, you might want to configure the smart optimize timer.

When you enable the smart optimize timer, an LSP is switched back to its original path
so long as the original path has been restored within 3 minutes of going down. Also, if
the original path goes down again within 60 minutes, the smart optimize timer is disabled,
and path optimization behaves as it normally does when the optimize timer alone is
enabled. This prevents the router from using a flapping link.

The smart optimize timer is dependant on other MPLS features to function properly. For
the scenario described here in which an LSP is switched to an alternate path in the event
of a failure on the original path, it is assumed that you have configured one or more of
the MPLS traffic protection features, including fast reroute, link protection, and standby
secondary paths. These features help to ensure that traffic can reach its destination in
the event of a failure.

At the least, you must configure a standby secondary path for the smart optimize timer
feature to work properly. Fast reroute and link protection are more temporary solutions
to a network outage. A secondary path ensures that there is a stable alternate path in
the event the primary path fails. If you have not configured any sort of traffic protection
for an LSP, the smart optimize timer by itself does not ensure that traffic can reach its
destination. For more information about MPLS traffic protection, see “MPLS and Traffic
Protection” on page 46.

Copyright © 2012, Juniper Networks, Inc. 183

Junos OS 12.1 MPLS Applications Configuration Guide

When a primary path fails and the smart optimize timer switches traffic to the secondary
path, the router might continue to use the secondary path even after the primary path
has been restored. If the ingress router completes a CSPF calculation, it might determine
that the secondary path is the better path.

This might be undesirable if the primary path should be the active path and the secondary
path should be used as a backup only. Also, if the secondary path is being used as the
active path (even though the primary path has been reestablished) and the secondary
path fails, the smart optimize timer feature will not automatically switch traffic back to
the primary path. However, you can enable protection for the secondary path by
configuring node and link protection or an additional standby secondary path, in which
case, the smart optimize timer can be effective.

Specify the time in seconds for the smart optimize timer using the smart-optimize-timer
statement:

smart-optimize-timer seconds;

You can include this statement at the following hierarchy levels:

• [edit protocols mpls]

• [edit logical-systems logical-system-name protocols mpls]

Related • MPLS and Traffic Protection on page 46

Documentation
• Optimizing Signaled LSPs on page 180

Limiting the Number of Hops in LSPs

By default, each LSP can traverse a maximum of 255 hops, including the ingress and
egress routers. To modify this value, include the hop-limit statement:

hop-limit number;

For a list of hierarchy levels at which you can include this statement, see the statement
summary section for this statement.

The number of hops can be from 2 through 255. (A path with two hops consists of the
ingress and egress routers only.)

Configuring the Bandwidth Value for LSPs

Each LSP has a bandwidth value. This value is included in the sender’s Tspec field in
RSVP path setup messages. You can specify a bandwidth value in bits per second. If you
configure more bandwidth for an LSP, it should be able to carry a greater volume of
traffic. The default bandwidth is 0 bits per second.

A nonzero bandwidth requires that transit and egress routers reserve capacity along the
outbound links for the path. The RSVP reservation scheme is used to reserve this capacity.
Any failure in bandwidth reservation (such as failures at RSVP policy control or admission

184 Copyright © 2012, Juniper Networks, Inc.

 Chapter 5: MPLS-Signaled LSP Configuration Guidelines

control) might cause the LSP setup to fail. If there is insufficient bandwidth on the
interfaces for the transit or egress routers, the LSP is not established.

To specify a bandwidth value for a signaled LSP, include the bandwidth statement:

bandwidth bps;

For a list of hierarchy levels at which you can include this statement, see the statement
summary section for this statement.

Configuring Hot Standby of Secondary Paths

By default, secondary paths are set up only as needed. To have the system maintain a
secondary path in a hot-standby state indefinitely, include the standby statement:

standby;

You can include this statement at the following hierarchy levels:

• [edit protocols mpls label-switched-path lsp-name secondary]

• [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name

secondary]

The hot-standby state is meaningful only on secondary paths. Maintaining a path in a

hot-standby state enables swift cutover to the secondary path when downstream routers
on the current active path indicate connectivity problems. Although it is possible to
configure the standby statement at the [edit protocols mpls label-switched-path lsp-name
primary path-name] hierarchy level, it has no effect on router behavior.

If you configure the standby statement at the following hierarchy levels, the hot-standby
state is activated on all secondary paths configured beneath that hierarchy level:

• [edit protocols mpls]

• [edit protocols mpls label-switched-path lsp-name]

• [edit logical-systems logical-system-name protocols mpls]

• [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name]

The hot-standby state has two advantages:

• It eliminates the call-setup delay during network topology changes. Call setup can
suffer from significant delays when network failures trigger large numbers of LSP
reroutes at the same time.

• A cutover to the secondary path can be made before RSVP learns that an LSP is down.
There can be significant delays between the time the first failure is detected by protocol
machinery (which can be an interface down, a neighbor becoming unreachable, a route
becoming unreachable, or a transient routing loop being detected) and the time an
LSP actually fails (which requires a timeout of soft state information between adjacent
RSVP routers). When topology failures occur, hot-standby secondary paths can usually
achieve the smallest cutover delays with minimal disruptions to user traffic.

Copyright © 2012, Juniper Networks, Inc. 185

Junos OS 12.1 MPLS Applications Configuration Guide

When the primary path is considered to be stable again, traffic is automatically switched
from the standby secondary path back to the primary path. The switch is performed no
faster than twice the retry-timer interval and only if the primary path exhibits stability
throughout the entire switch interval.

The drawback of the hot-standby state is that more state information must be maintained
by all the routers along the path, which requires overhead from each of the routers.

Damping Advertisement of LSP State Changes

When an LSP changes from being up to being down, or from down to up, this transition
takes effect immediately in the router software and hardware. However, when advertising
LSPs into IS-IS and OSPF, you may want to damp LSP transitions, thereby not advertising
the transition until a certain period of time has transpired (known as the hold time). In
this case, if the LSP goes from up to down, the LSP is not advertised as being down until
it has remained down for the hold-time period. Transitions from down to up are advertised
into IS-IS and OSPF immediately. Note that LSP damping affects only the IS-IS and
OSPF advertisements of the LSP; other routing software and hardware react immediately
to LSP transitions.

To damp LSP transitions, include the advertisement-hold-time statement:

advertisement-hold-time seconds;

seconds can be a value from 0 through 65,535 seconds. The default is 5 seconds.

You can include this statement at the following hierarchy levels:

• [edit protocols mpls]

• [edit logical-systems logical-system-name protocols mpls]

186 Copyright © 2012, Juniper Networks, Inc.

CHAPTER 6

DiffServ-Aware Traffic Engineering

Configuration Guidelines

This chapter describes how to configure DiffServ-aware traffic engineering for LSPs and
multiclass LSPs:

• DiffServ-Aware Traffic Engineering Introduction on page 188

• DiffServ-Aware Traffic Engineering Standards on page 188
• DiffServ-Aware Traffic Engineering Terminology on page 188
• DiffServ-Aware Traffic Engineering Features on page 189
• DiffServ-Aware Traffic Engineered LSPs on page 190
• DiffServ-Aware Traffic Engineered LSPs Overview on page 190
• DiffServ-Aware Traffic Engineered LSPs Operation on page 191
• Multiclass LSPs on page 191
• Multiclass LSP Overview on page 192
• Establishing a Multiclass LSP on the Differentiated Services Domain on page 192
• Configuring Routers for DiffServ-Aware Traffic Engineering on page 193
• Bandwidth Oversubscription Overview on page 197
• LSP Size Oversubscription on page 198
• Link Size Oversubscription on page 198
• Class Type Oversubscription and Local Oversubscription Multipliers on page 198
• Class Type Bandwidth and the LOM on page 199
• LOM Calculation for the MAM and Extended MAM Bandwidth Models on page 199
• LOM Calculation for the Russian Dolls Bandwidth Model on page 200
• Example: LOM Calculation on page 200
• Configuring the Bandwidth Subscription Percentage for LSPs on page 201
• Configuring LSPs for DiffServ-Aware Traffic Engineering on page 203
• Configuring Multiclass LSPs on page 206

Copyright © 2012, Juniper Networks, Inc. 187

Junos OS 12.1 MPLS Applications Configuration Guide

DiffServ-Aware Traffic Engineering Introduction

Differentiated Services (DiffServ)-aware traffic engineering provides a way to guarantee

a specified level of service over an MPLS network. The routers providing DiffServ-aware
traffic engineering are part of a differentiated services network domain. All routers
participating in a differentiated services domain must have DiffServ-aware traffic
engineering enabled.

To help ensure that the specified service level is provided, it is necessary to ensure that
no more than the amount of traffic specified is sent over the differentiated services
domain. You can accomplish this goal by configuring a policer to police or rate-limit the
volume of traffic transiting the differentiated service domain. For more information about
how to configure policers for label-switched paths (LSPs), see “Configuring Policers for
LSPs” on page 260.

This feature can help to improve the quality of Internet services such as voice over IP
(VoIP). It also makes it possible to better emulate an Asynchronous Transfer Mode (ATM)
circuit over an MPLS network.

DiffServ-Aware Traffic Engineering Standards

The following RFCs provide information on DiffServ-aware traffic engineering and

multiclass LSPs:

• RFC 3270, Multi-Protocol Label Switching (MPLS) Support of Differentiated Services

• RFC 3564, Requirements for Support of Differentiated Services-aware MPLS Traffic

Engineering

• RFC 4124, Protocol Extensions for Support of Differentiated-Service-Aware MPLS Traffic

Engineering

• RFC 4125, Maximum Allocation Bandwidth Constraints Model for Diff-Serv-aware MPLS
Traffic Engineering

• RFC 4127, Russian Dolls Bandwidth Constraints Model for Diff-Serv-aware MPLS

These RFCs are available on the IETF website at http://www.ietf.org/.

DiffServ-Aware Traffic Engineering Terminology

B
Bandwidth model The bandwidth model determines the values of the available bandwidth advertised by the
interior gateway protocols (IGPs).

C
CAC Call admission control (CAC) checks to ensure there is adequate bandwidth on the path before
the LSP is established. If the bandwidth is insufficient, the LSP is not established and an error
is reported.

188 Copyright © 2012, Juniper Networks, Inc.

 Chapter 6: DiffServ-Aware Traffic Engineering Configuration Guidelines

Class type A collection of traffic flows that is treated equivalently in a differentiated services domain. A
class type maps to a queue and is much like a class-of-service (CoS) forwarding class in
concept. It is also known as a traffic class.

D
Differentiated Services Differentiated Services make it possible to give different treatment to traffic based on the EXP
bits in the MPLS header. Traffic must be marked appropriately and CoS must be configured.

Differentiated Services The routers in a network that have Differentiated Services enabled.
domain

DiffServ-aware traffic A type of constraint-based routing. It can enforce different bandwidth constraints for different
engineering classes of traffic. It can also do CAC on each traffic engineering class when an LSP is
established.

M
MAM The maximum allocation bandwidth constraint model divides the available bandwidth between
the different classes. Sharing of bandwidth between the class types is not allowed.

Multiclass LSP A multiclass LSP functions like a standard LSP, but it also allows you to reserve bandwidth
from multiple class types. The EXP bits of the MPLS header are used to distinguish between
class types.

R
RDM The Russian dolls bandwidth constraint model makes efficient use of bandwidth by allowing
the class types to share bandwidth.

T
Traffic engineering A paired class type and priority.
class

Traffic engineering A map between the class types, priorities, and traffic engineering classes. The traffic engineering
class map class mapping must be consistent across the Differentiated Services domain.

DiffServ-Aware Traffic Engineering Features

DiffServ-aware traffic engineering provides the following features:

• Traffic engineering at a per-class level rather than at an aggregate level

• Different bandwidth constraints for different class types (traffic classes)

• Different queuing behaviors per class, allowing the router to forward traffic based on
the class type

In comparison, standard traffic engineering does not consider CoS, and it completes its
work on an aggregate basis across all Differentiated Service classes.

DiffServ-aware traffic engineering provides the following advantages:

Copyright © 2012, Juniper Networks, Inc. 189

Junos OS 12.1 MPLS Applications Configuration Guide

• Traffic engineering can be performed on a specific class type instead of at the aggregate
level.

• Bandwidth constraints can be enforced on each specific class type.

• It forwards traffic based on the EXP bits.

This makes it possible to guarantee service and bandwidth across an MPLS network.
With DiffServ-aware traffic engineering, among other services, you can provide ATM
circuit emulation, VoIP, and a guaranteed bandwidth service.

The following describes how the IGP, Constrained Shortest Path First (CSPF), and RSVP
participate in DiffServ-aware traffic engineering:

• The IGP can advertise the unreserved bandwidth for each traffic engineering class to
the other members of the differentiated services domain. The traffic engineering
database stores this information.

• A CSPF calculation is performed considering the bandwidth constraints for each class
type. If all the constraints are met, the CSPF calculation is considered successful.

• When RSVP signals an LSP, it requests bandwidth for specified class types.

DiffServ-Aware Traffic Engineered LSPs

A DiffServ-aware traffic engineered LSP is an LSP configured to reserve bandwidth for

one of the supported class types and to carry traffic for that class type. The following
sections discuss this type of LSPs:

• DiffServ-Aware Traffic Engineered LSPs Overview on page 190

• DiffServ-Aware Traffic Engineered LSPs Operation on page 191

DiffServ-Aware Traffic Engineered LSPs Overview

A DiffServ-aware traffic engineered LSP is an LSP configured with a bandwidth reservation

for a specific class type. This LSP can carry traffic for a single class type. On the packets,
the class type is specified by the EXP bits (also known as the class-of-service bits) and
the per-hop behavior (PHB) associated with the EXP bits. The mapping between the
EXP bits and the PHB is static, rather than being signaled in RSVP.

The class type must be configured consistently across the Differentiated Services domain,
meaning the class type configuration must be consistent from router to router in the
network. You can unambiguously map a class type to a queue. On each node router, the
class-of-service queue configuration for an interface translates to the available bandwidth
for a particular class type on that link.

For more information about topics related to LSPs and DiffServ-aware traffic engineering,
see the following:

190 Copyright © 2012, Juniper Networks, Inc.

 Chapter 6: DiffServ-Aware Traffic Engineering Configuration Guidelines

• For forwarding classes and class of service, see the Junos OS Class of Service Configuration
Guide.

• For EXP bits, see “Label Allocation” on page 28.

• For differentiated services, see RFC 3270, Multi-Protocol Label Switching (MPLS)
Support of Differentiated Services.

• For information about how the IGPs and RSVP have been modified to support
Differentiated Services-aware MPLS traffic engineering, see RFC 4124, Protocol
Extensions for Support of Differentiated-Service-Aware MPLS Traffic Engineering.

DiffServ-Aware Traffic Engineered LSPs Operation

When configuring a DiffServ-aware traffic engineered LSP, you specify the class type
and the bandwidth associated with it. The following occurs when an LSP is established
with bandwidth reservation from a specific class type:

1. The IGPs advertise how much unreserved bandwidth is available for the traffic
engineering classes.

2. When calculating the path for an LSP, CSPF is used to ensure that the bandwidth
constraints are met for the class type carried by the LSP at the specified priority level.

CSPF also checks to ensure that the bandwidth model is configured consistently on
each router participating in the LSP. If the bandwidth model is inconsistent, CSPF
does not compute the path (except for LSPs from class type ct0).

3. Once a path is found, RSVP signals the LSP using the Classtype object in the path
message. At each node in the path, the available bandwidth for the class types is
adjusted as the path is set up.

An LSP that requires bandwidth from a particular class (except class type ct0) cannot
be established through routers that do not understand the Classtype object. Preventing
the use of routers that do not understand the Classtype object helps to ensure consistency
throughout the Differentiated Services domain by preventing the LSP from using a router
that cannot support Differentiated Services.

By default, LSPs are signaled with setup priority 7 and holding priority 0. An LSP configured
with these values cannot preempt another LSP at setup time and cannot be preempted.

It is possible to have both LSPs configured for DiffServ-aware traffic engineering and
regular LSPs configured at the same time on the same physical interfaces. For this type
of heterogeneous environment, regular LSPs carry best-effort traffic by default. Traffic
carried in the regular LSPs must have the correct EXP settings (either by remarking the
EXP settings or by assuming that the traffic arrived with the correct EXP settings from
the upstream router).

Multiclass LSPs

Multiclass LSPs function like standard LSPs, but they also allow you to configure multiple
class types with guaranteed bandwidth. The EXP bits of the MPLS header are used to
distinguish between class types. Multiclass LSPs can be configured for a variety of

Copyright © 2012, Juniper Networks, Inc. 191

Junos OS 12.1 MPLS Applications Configuration Guide

purposes. For example, you can configure a multiclass LSP to emulate the behavior of
an ATM circuit. An ATM circuit can provide service-level guarantees to a class type. A
multiclass LSP can provide a similar guaranteed level of service.

The following sections discuss multiclass LSPs:

• Multiclass LSP Overview on page 192

• Establishing a Multiclass LSP on the Differentiated Services Domain on page 192

Multiclass LSP Overview

A multiclass LSP is an LSP that can carry several class types. One multiclass LSP can be
used to support up to four class types. On the packets, the class type is specified by the
EXP bits (also known as the class-of-service bits) and the per-hop behavior (PHB)
associated with the EXP bits. The mapping between the EXP bits and the PHB is static,
rather than being signaled in RSVP.

Once a multiclass LSP is configured, traffic from all of the class types can:

• Follow the same path

• Be rerouted along the same path

• Be taken down at the same time

Class types must be configured consistently across the Differentiated Services domain,
meaning the class type configuration must be consistent from router to router in the
network.

You can unambiguously map a class type to a queue. On each node router, the CoS queue
configuration for an interface translates to the available bandwidth for a particular class
type on that link.

The combination of a class type and a priority level forms a traffic engineering class. The
IGPs can advertise up to eight traffic engineering classes for each link.

For more information about the EXP bits, see “Label Allocation” on page 28.

For more information about forwarding classes, see the Junos OS Class of Service
Configuration Guide.

Establishing a Multiclass LSP on the Differentiated Services Domain

The following occurs when a multiclass LSP is established on the differentiated services
domain:

1. The IGPs advertise how much unreserved bandwidth is available for the traffic
engineering classes.

2. When calculating the path for a multiclass LSP, CSPF is used to ensure that the
constraints are met for all the class types carried by the multiclass LSP (a set of
constraints instead of a single constraint).

192 Copyright © 2012, Juniper Networks, Inc.

 Chapter 6: DiffServ-Aware Traffic Engineering Configuration Guidelines

3. Once a path is found, RSVP signals the LSP using an RSVP object in the path message.
At each node in the path, the available bandwidth for the class types is adjusted as
the path is set up. The RSVP object is a hop-by-hop object. Multiclass LSPs cannot
be established through routers that do not understand this object. Preventing routers
that do not understand the RSVP object from carrying traffic helps to ensure
consistency throughout the differentiated services domain by preventing the multiclass
LSP from using a router that is incapable of supporting differentiated services.

By default, multiclass LSPs are signaled with setup priority 7 and holding priority 0. A
multiclass LSP configured with these values cannot preempt another LSP at setup time
and cannot be preempted.

It is possible to have both multiclass LSPs and regular LSPs configured at the same time
on the same physical interfaces. For this type of heterogeneous environment, regular
LSPs carry best-effort traffic by default. Traffic carried in the regular LSPs must have the
correct EXP settings.

Configuring Routers for DiffServ-Aware Traffic Engineering

To configure DiffServ-aware traffic engineering, include the diffserv-te statement:

diffserv-te {
bandwidth-model {
extended-mam;
mam;
rdm;
}
te-class-matrix {
traffic-class {
tenumber {
priority priority;
traffic-class ctnumber priority priority;
}
}
}
}

You can include this statement at the following hierarchy levels:

• [edit protocols mpls]

• [edit logical-systems logical-system-name protocols mpls]

You must include the diffserv-te statement in the configuration on all routers participating
in the Differentiated Services domain. However, you are not required to configure the
traffic engineering class matrix (by including the te-class-matrix statement at the [edit
protocols mpls diffserv-te] or [edit logical-systems logical-system-name protocols mpls
diffserv-te] hierarchy level).

Copyright © 2012, Juniper Networks, Inc. 193

Junos OS 12.1 MPLS Applications Configuration Guide

NOTE: To prevent the possibility of an incorrect configuration when migrating

to Diffserv-aware traffic engineering, a policy control failure error might be
triggered if there is conflict between the old LSPs and the newly configured
TE-class matrix.

An old node might request an LSP with setup and hold priorities in such a
way that the combination of the ct0 class and the priority does not match
with the configured TE-class matrix. All LSPs on the router that are configured
prior to configuring diffserv-aware traffic engineering are designated as being
from class ct0.

The error appears in the RSVP tracing logs as a Session preempted error. For
the router where the error originates, the error could appear as follows:

Jun 17 16:35:59 RSVP error for session 10.255.245.6(port/tunnel ID 31133)

Proto 0: (class ct0, priority 2) is not a valid TE-class Jun 17
16:35:59 RSVP originate PathErr 192.168.37.22->192.168.37.23 Session
preempted

For the router receiving the error, the error can appear as follows:

Jun 17 16:37:51 RSVP recv PathErr 192.168.37.22->192.168.37.23 Session

preempted LSP to-f(2/31133)

To configure DiffServ-aware traffic engineering, complete the procedures in the following

sections:

• Configuring the Bandwidth Model on page 194

• Configuring Traffic Engineering Classes on page 195
• Configuring Class of Service for DiffServ-Aware Traffic Engineering on page 196

Configuring the Bandwidth Model

You must configure a bandwidth model on all routers participating in the Differentiated
Services domain. The bandwidth models available are MAM, extended MAM, and RDM:

• Maximum allocation bandwidth constraints model (MAM)—Defined in RFC 4125,

Maximum Allocation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic
Engineering.

• Extended MAM—A proprietary bandwidth model that behaves much like standard
MAM. If you configure multiclass LSPs, you must configure the extended MAM
bandwidth model.

• Russian-dolls bandwidth allocation model (RDM)—Makes efficient use of bandwidth

by allowing the class types to share bandwidth. RDM is defined in RFC 4127, Russian
Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering.

To configure a bandwidth model, include the bandwidth-model statement and specify

one of the bandwidth model options:

bandwidth-model {
extended-mam;

194 Copyright © 2012, Juniper Networks, Inc.

 Chapter 6: DiffServ-Aware Traffic Engineering Configuration Guidelines

mam;
rdm;
}

You can include this statement at the following hierarchy levels:

• [edit protocols mpls diffserv-te]

• [edit logical-systems logical-system-name protocols mpls diffserv-te]

NOTE: If you change the bandwidth model on an ingress router, all the
LSPs enabled on the router are taken down and resignaled.

Configuring Traffic Engineering Classes

Configuring traffic engineering classes is optional. Table 5 on page 195 shows the default
values for everything in the traffic engineering class matrix. The default mapping is
expressed in terms of the default forwarding classes defined in the CoS configuration.

Table 5: Default Values for the Traffic Engineering Class Matrix

Traffic Engineering Class Class Type Queue Priority

te0 ct0 0 7

te1 ct1 1 7

te2 ct2 2 7

te3 ct3 3 7

te4 ct0 0 0

te5 ct1 1 0

te6 ct2 2 0

te7 ct3 3 0

If you want to override the default mappings, you can configure traffic engineering classes
0 through 7. For each traffic engineering class, you configure a class type (or queue) from
0 through 3. For each class type, you configure a priority from 0 through 7.

To configure traffic engineering classes explicitly, include the te-class-matrix statement:

te-class-matrix {
tenumber {
priority priority;
traffic-class {
ctnumber priority priority;
}

Copyright © 2012, Juniper Networks, Inc. 195

Junos OS 12.1 MPLS Applications Configuration Guide

}
}

You can include this statement at the following hierarchy levels:

• [edit protocols mpls diffserv-te]

• [edit logical-systems logical-system-name protocols mpls diffserv-te]

The following example shows how to configure traffic engineering class te0 with class
type ct1 and a priority of 4:

[edit protocols mpls diffserv-te]

te-class-matrix {
te0 traffic-class ct1 priority 4;
}

NOTE: If you explicitly configure a value for one of the traffic engineering
classes, all the default values in the traffic engineering class matrix are
dropped.

When you explicitly configure traffic engineering classes, you must also
configure a bandwidth model; otherwise, the configuration commit operation
fails.

Requirements and Limitations for the Traffic Engineering Class Matrix

When you configure a traffic engineering class matrix, be aware of the following
requirements and limitations:

• A mapping configuration is local and affects only the router on which it is configured.
It does not affect other systems participating in the differentiated services domain.
However, for a Differentiated Services domain to function properly, you need to
configure the same traffic engineering class matrix on all the routers participating in
the same domain.

• When explicitly configuring traffic engineering classes, you must configure the classes
in sequence (te0, te1, te2, te3, and so on); otherwise, the configuration commit operation
fails.

The first traffic engineering class you configure must be te0; otherwise, the configuration
commit operation fails.

Configuring Class of Service for DiffServ-Aware Traffic Engineering

To configure DiffServ-aware traffic engineering, you must also configure class of service.
The following example illustrates a class-of-service configuration that would allocate
25 percent of the link bandwidth to each class:

class-of-service {
interfaces {
all {
scheduler-map simple-map;

196 Copyright © 2012, Juniper Networks, Inc.

 Chapter 6: DiffServ-Aware Traffic Engineering Configuration Guidelines

}
}
scheduler-maps {
simple-map {
forwarding-class assured-forwarding scheduler simple_sched;
forwarding-class best-effort scheduler simple_sched;
forwarding-class network-control scheduler simple_sched;
forwarding-class expedited-forwarding scheduler simple_sched;
}
}
schedulers {
simple_sched {
transmit-rate percent 25;
buffer-size percent 25;
}
}
}

For more information on how to configure class of service, see the Junos OS Class of Service
Configuration Guide.

Bandwidth Oversubscription Overview

LSPs are established with bandwidth reservations configured for the maximum amount
of traffic you expect to traverse the LSP. Not all LSPs carry the maximum amount of
traffic over their links at all times. For example, even if the bandwidth for link A has been
completely reserved, actual bandwidth might still be available but not currently in use.
This excess bandwidth can be used by allowing other LSPs to also use link A,
oversubscribing the link. You can oversubscribe the bandwidth configured for individual
class types or specify a single value for all of the class types using an interface.

You can use oversubscription to take advantage of the statistical nature of traffic patterns
and to permit higher utilization of links.

The following examples describe how you might use bandwidth oversubscription and
undersubscription:

• Use oversubscription on class types where peak periods of traffic do not coincide in
time.

• Use oversubscription of class types carrying best-effort traffic. You take the risk of
temporarily delaying or dropping traffic in exchange for making better utilization of
network resources.

• Give different degrees of oversubscription or undersubscription of traffic for the different

class types. For instance, you configure the subscription for classes of traffic as follows:

• Best effort—ct0 1000

• Voice—ct3 1

When you undersubscribe a class type for a multiclass LSP, the total demand of all RSVP
sessions is always less than the actual capacity of the class type. You can use
undersubscription to limit the utilization of a class type.

Copyright © 2012, Juniper Networks, Inc. 197

Junos OS 12.1 MPLS Applications Configuration Guide

The bandwidth oversubscription calculation occurs on the local router only. Because no
signaling or other interaction is required from other routers in the network, the feature
can be enabled on individual routers without being enabled or available on other routers
which might not support this feature. Neighboring routers do not need to know about
the oversubscription calculation, they rely on the IGP.

The following sections describe the types of bandwidth oversubscription available in the
Junos OS:

• LSP Size Oversubscription on page 198

• Link Size Oversubscription on page 198

• Class Type Oversubscription and Local Oversubscription Multipliers on page 198

LSP Size Oversubscription

For LSP size oversubscription, you simply configure less bandwidth than the peak rate
expected for the LSP. You also might need to adjust the configuration for automatic
policers. Automatic policers manage the traffic assigned to an LSP, ensuring that it does
not exceed the configured bandwidth values. LSP size oversubscription requires that the
LSP can exceed its configured bandwidth allocation.

Policing is still possible. However, the policer must be manually configured to account
for the maximum bandwidth planned for the LSP, rather than for the configured value.

Link Size Oversubscription

You can increase the maximum reservable bandwidth on the link and use the inflated
values for bandwidth accounting. Use the subscription statement to oversubscribe the
link. The configured value is applied to all class type bandwidth allocations on the link.
For more information about link size oversubscription, see “Configuring the Bandwidth
Subscription Percentage for LSPs” on page 201.

Class Type Oversubscription and Local Oversubscription Multipliers

Local oversubscription multipliers (LOMs) allow different oversubscription values for

different class types. LOMs are useful for networks where the oversubscription ratio
needs to be configured differently on different links and where oversubscription values
are required for different classes. You might use this feature to oversubscribe class types
handling best-effort traffic, but use no oversubscription for class types handling voice
traffic. An LOM is calculated locally on the router. No information related to an LOM is
signaled to other routers in the network.

An LOM is configurable on each link and for each class type. The per-class type LOM
allows you to increase or decrease the oversubscription ratio. The per-class-type LOM
is factored into all local bandwidth accounting for admission control and IGP
advertisement of unreserved bandwidths.

198 Copyright © 2012, Juniper Networks, Inc.

 Chapter 6: DiffServ-Aware Traffic Engineering Configuration Guidelines

The LOM calculation is tied to the bandwidth model (MAM, extended MAM, and Russian
dolls) used, because the effect of oversubscription across class types must be accounted
for accurately.

NOTE: All LOM calculations are performed by the Junos OS and require no
user intervention.

The formulas related to the oversubscription of class types are described in

the following sections:

• Class Type Bandwidth and the LOM on page 199

• LOM Calculation for the MAM and Extended MAM Bandwidth Models on
page 199

• LOM Calculation for the Russian Dolls Bandwidth Model on page 200

• Example: LOM Calculation on page 200

Class Type Bandwidth and the LOM

The following formula expresses the relationship between the bandwidth of the class
type and the LOM. The normalized bandwidth of the class type (N ) is equal to the
B
reserved bandwidth of the class type (R ) divided by the LOM of the class type (L ):
B C

N = R /L
B B C

When calculating available bandwidth, you need to subtract the normalized bandwidth
from the relevant bandwidth constraint.

NOTE: When using an LOM, values advertised for the available bandwidth
might be larger than the bandwidth constraint values. However, the values
advertised in the maximum link bandwidth advertisement are not affected
by local oversubscription.

LOM Calculation for the MAM and Extended MAM Bandwidth Models

The following formulas show how the LOM is calculated for the MAM and extended MAM
bandwidth models.

Unreserved TE-Class(i) = LOMc x [ BCc – SUM ( Normalized (CTc, q) ) ] for q <= p

Or

Unreserved TE-Class(i) = ( LOMc x BCc ) – SUM ( Reserved (CTc, q) ) for q <= p

where:

Copyright © 2012, Juniper Networks, Inc. 199

Junos OS 12.1 MPLS Applications Configuration Guide

• LOMc—LOM for class type c.

• BCc—Bandwidth constraint for class type c.

• CTc—Class type c.

• TE-Class(i) <––> ( CTc , preemption p ) in the configured TE-Class mapping.

LOM Calculation for the Russian Dolls Bandwidth Model

The following formulas show how the LOM is calculated for the Russian dolls bandwidth
model:

Unreserved TE-Class (i) = LOMc x MIN [

[ BCc - SUM ( Normalized (CTb, q) ) ] for q <= p and c <= b <= 7,

...
[ BC0 - SUM ( Normalized (CTb, q) ) ] for q <= p and 0 <= b <= 7,

where:

• LOMc—LOM for class type c.

• BCc—Bandwidth constraint for class type c.

• TE-Class(i) <– –>(CTc , preemption p ) in the configured TE-Class mapping.

Note that the impact of an LSP on the unreserved bandwidth of a class type does not
depend only on the LOM for that class type—it also depends on the LOM for the class
type of the LSP.

Example: LOM Calculation

The following example illustrates how an LOM calculation is made for four classes of
traffic: ct0, ct1, ct2, and ct3.

The class types have been assigned the following values:

ct0 = 40
ct1 = 30
ct2 = 20
ct3 = 10

These class type values yield the following bandwidth constraints:

BC0 = (ct3 + ct2 + ct1 + ct0) = 100

BC1 = (ct3 + ct2 + ct1) = 60
BC2 = (ct3 + ct2) = 30
BC3 = (ct3) = 10

LSPs from class type ct0 can take up to 100 percent of bandwidth on the link. LSPs from
class type ct1 can take up to 60 percent of the bandwidth on the link, and so on.

If you assume for this example that the class types have the following LOM values:

200 Copyright © 2012, Juniper Networks, Inc.

 Chapter 6: DiffServ-Aware Traffic Engineering Configuration Guidelines

LOM(ct0) = 8
LOM(ct1) = 4
LOM(ct2) = 2
LOM(ct3) = 1

In the absence of any other reservation, LSPs from class type ct0 can take up to
800 percent of the available bandwidth (8 x 100 = 800). In the absence of any other
reservation, LSPs from class type ct1 can take up to 240 percent of the available
bandwidth (4 x 60 = 240). and so on.

The maximum amount of bandwidth that can be reserved is:

ct0 = LOM(ct0) x BC0 = 800

ct1 = LOM(ct1) x BC1 = 240
ct2 = LOM(ct2) x BC2 = 60
ct3 = LOM(ct3) x BC3 = 10

For the undersubscribed class type ct3, the maximum reservable bandwidth is the same
as the bandwidth constraint. For the overbooked class types, these values are not the
values of the bandwidth constraint-taking into account the oversubscription for each
class type separately. The oversubscription per class type in the sum is not taken into
account because ultimately the entire bandwidth constraint can be filled with the
bandwidth reservation of just one class type, so you have to account for that class type’s
bandwidth oversubscription only.

When calculating the available bandwidth for CTc, you need to express reservations from
other classes as if they were from CTc. The reservation from class ctx is normalized with
the LOM of ctx, but it is then multiplied by the LOM of CTc.

For the previous example, assume that LSP1 has class type ct3 configured with bandwidth
of 10 and a priority of 0.

The values for the reservable bandwidth will be:

ct0 = 8 x (100 - 10) = 720

ct1 = 4 x min((100-10), (60-10)) = 200
ct2 = 2 x min((100-10), (60-10), (30-10)) = 40
ct3 = 1 x min((100-10), (60-10), (30-10), (10-10)) = 0

These numbers can be rationalized as follows: the normalized reservation is 10 percent.

If this bandwidth came from class type ct0, it would be equivalent to an overbooked
reservation of 80 percent. You can see that 720 percent (800 – 80 = 720) of the bandwidth
remains available for other LSPs.

Configuring the Bandwidth Subscription Percentage for LSPs

By default, RSVP allows all of a class type’s bandwidth (100 percent) to be used for
RSVP reservations. When you oversubscribe a class type for a multiclass LSP, the
aggregate demand of all RSVP sessions is allowed to exceed the actual capacity of the
class type.

If you want to oversubscribe or undersubscribe all of the class types on an interface using
the same percentage bandwidth, configure the percentage using the subscription
statement:

Copyright © 2012, Juniper Networks, Inc. 201

Junos OS 12.1 MPLS Applications Configuration Guide

subscription percentage;

For a list of hierarchy levels at which you can include this statement, see the statement
summary section.

To undersubscribe or oversubscribe the bandwidth for each class type, configure a

percentage for each class type (ct0, ct1, ct2, and ct3) option for the subscription statement.
When you oversubscribe a class type, an LOM is applied to calculate the actual bandwidth
reserved. See “Class Type Oversubscription and Local Oversubscription Multipliers” on
page 198 for more information.

subscription {
ct0 percentage;
ct1 percentage;
ct2 percentage;
ct3 percentage;
}

For a list of hierarchy levels at which you can include this statement, see the statement
summary section.

percentage is the percentage of class type bandwidth that RSVP allows to be used for
reservations. It can be a value from 0 through 65,000 percent. If you specify a value
greater than 100, you are oversubscribing the interface or class type.

The value you configure when you oversubscribe a class type is a percentage of the class
type bandwidth that can actually be used. The default subscription value is 100 percent.

You can use the subscription statement to disable new RSVP sessions for one or more
class types. If you configure a percentage of 0, no new sessions (including those with
zero bandwidth requirements) are permitted for the class type.

Existing RSVP sessions are not affected by changing the subscription factor. To clear an
existing session, issue the clear rsvp session command. For more information on the clear
rsvp session command, see the Junos OS Routing Protocols and Policies Command Reference.

Constraints on Configuring Bandwidth Subscription

Be aware of the following issues when configuring bandwidth subscription:

• If you configure bandwidth constraints at the [edit class-of-service interface

interface-name] hierarchy level, they override any bandwidth configuration you specify
at the [edit protocols rsvp interface interface-name bandwidth] hierarchy level for
Diffserv-TE. Also note that either of the CoS or RSVP bandwidth constraints can override
the interface hardware bandwidth constraints.

• If you configure a bandwidth subscription value for a specific interface that differs from
the value configured for all interfaces (by including different values for the subscription
statement at the [edit protocols rsvp interface interface-name] and [edit protocols rsvp
interface all] hierarchy levels), the interface-specific value is used for that interface.

• You can configure subscription for each class type only if you also configure a bandwidth
model. If no bandwidth model is configured, the commit operation fails with the
following error message:

202 Copyright © 2012, Juniper Networks, Inc.

 Chapter 6: DiffServ-Aware Traffic Engineering Configuration Guidelines

user@host# commit check

[edit protocols rsvp interface all]

'subscription'
RSVP: Must have a diffserv-te bandwidth model configured when configuring
subscription per traffic class.
error: configuration check-out failed

• You cannot include the subscription statement both in the configuration for a specific
class type and the configuration for the entire interface. The commit operation fails
with the following error message:

user@host# commit check

[edit protocols rsvp interface all]

'subscription'
RSVP: Cannot configure both link subscription and per traffic class
subscription.
error: configuration check-out failed

Configuring LSPs for DiffServ-Aware Traffic Engineering

You must configure the Differentiated Services domain (see “Configuring Routers for
DiffServ-Aware Traffic Engineering” on page 193) before you can enable DiffServ-aware
traffic engineering for LSPs. The Differentiated Services domain provides the underlying
class types and corresponding traffic engineering classes that you reference in the LSP
configuration. The traffic engineering classes must be configured consistently on each
router participating in the Differentiated Services domain for the LSP to function properly.

NOTE: You must configure either MAM or RDM as the bandwidth model when
you configure DiffServ-aware traffic engineering for LSPs. See “Configuring
the Bandwidth Model” on page 194.

The actual data transmitted over this Differentiated Services domain is carried by an
LSP. Each LSP relies on the EXP bits of the MPLS packets to enable DiffServ-aware traffic
engineering. Each LSP can carry traffic for a single class type.

All the routers participating in the LSP must be Juniper Networks routers running Junos
OS Release 6.3 or later. The network can include routers from other vendors and Juniper
Networks routers running earlier versions of the Junos OS. However, the DiffServ-aware
traffic engineering LSP cannot traverse these routers.

NOTE: You cannot simultaneously configure multiclass LSPs and

DiffServ-aware traffic engineering LSPs on the same router.

To enable DiffServ-aware traffic engineering for LSPs, you need to configure the following:

• Configuring Class of Service for the Interfaces on page 204

• Configuring IGP on page 204

Copyright © 2012, Juniper Networks, Inc. 203

Junos OS 12.1 MPLS Applications Configuration Guide

• Configuring Traffic-Engineered LSPs on page 204

• Configuring Policing for LSPs on page 205
• Configuring Fast Reroute for Traffic-Engineered LSPs on page 205

Configuring Class of Service for the Interfaces

The existing class-of-service (CoS) infrastructure ensures that traffic that is consistently
marked receives the scheduling guarantees for its class. The classification, marking, and
scheduling necessary to accomplish this are configured using the existing Junos OS CoS
features.

NOTE: The Junos OS does not support CoS on ATM interfaces.

For information about how to configure CoS, see the Junos OS Class of Service Configuration
Guide.

Configuring IGP
You can configure either IS-IS or OSPF as the IGP. The IS-IS and OSPF configurations
for routers supporting LSPs are standard. For information about how to configure these
protocols, see the Junos OS Routing Protocols Configuration Guide.

Configuring Traffic-Engineered LSPs

You configure an LSP by using the standard LSP configuration statements and procedures.
To configure DiffServ-aware traffic engineering for the LSP, specify a class type bandwidth
constraint by including the bandwidth statement:

label-switched-path lsp-name {
bandwidth {
ctnumber bps;
}
}

For a list of hierarchy levels at which you can include the bandwidth statement, see the
statement summary sections for this statement.

If you do not specify a bandwidth for a class type, ct0 is automatically specified as the
queue for the LSP. You can configure only one class type for each LSP, unlike multiclass
LSPs.

The class type statements specify bandwidth (in bits per second) for the following
classes:

• ct0—Bandwidth reserved for class 0

• ct1—Bandwidth reserved for class 1

• ct2—Bandwidth reserved for class 2

• ct3—Bandwidth reserved for class 3

204 Copyright © 2012, Juniper Networks, Inc.

 Chapter 6: DiffServ-Aware Traffic Engineering Configuration Guidelines

You can configure setup and holding priorities for an LSP, but the following restrictions
apply:

• The combination of class and priority must be one of the configured traffic engineering
classes. The default setup priority is 7 and the default holding priority is 0.

• Configuring an invalid combination of class type and priority causes the commit
operation to fail.

• Automatic bandwidth allocation is not supported. If you configure automatic bandwidth

allocation, the commit operation fails.

• LSPs configured with the bandwidth statement but without specifying a class type use
the default class type ct0.

• For migration issues, see Internet draft draft-ietf-tewg-diff-te-proto-07.txt.

Configuring Policing for LSPs

Policing allows you to control the amount of traffic forwarded through a particular LSP.
Policing helps to ensure that the amount of traffic forwarded through an LSP never
exceeds the requested bandwidth allocation. You can configure multiple policers for
each LSP.

For information about how to configure a policer for an LSP, see “Configuring Policers
for LSPs” on page 260.

Configuring Fast Reroute for Traffic-Engineered LSPs

You can configure fast reroute for traffic engineered LSPs (LSPs carrying a single class
of traffic). It is also possible to reserve bandwidth on the detour path for the class of
traffic when fast reroute is enabled. The same class type number is used for both the
traffic engineered LSP and its detour.

If you configure the router to reserve bandwidth for the detour path, a check is made to
ensure that the link is capable of handling DiffServ-aware traffic engineering and for CoS
capability before accepting it as a potential detour path. Unsupported links are not used.

You can configure the amount of bandwidth to reserve for detours using either the
bandwidth statement or the bandwidth-percent statement. You can only configure one
these statements at a time. If you do not configure either the bandwidth statement or
the bandwidth-percent statement, the default setting is to not reserve bandwidth for the
detour path (the bandwidth guarantee will be lost if traffic is switched to the detour).

When you configure the bandwidth statement, you can specify the specific amount of
bandwidth (in bits per second [bps]) you want to reserve for the detour path. For
information, see “Configuring Fast Reroute” on page 152.

The bandwidth-percent statement allows you to specify the bandwidth of the detour
path as a percentage of the bandwidth configured for the protected path. For example,
if you configure 100 millions bps of bandwidth for the protected path and configure 20
for the bandwidth-percent statement, the detour path will have 20 million bps of
bandwidth reserved for its use.

Copyright © 2012, Juniper Networks, Inc. 205

Junos OS 12.1 MPLS Applications Configuration Guide

To configure the percent of bandwidth used by the detour path based on the bandwidth
of the protected path, include the bandwidth-percent statement:

bandwidth-percent percentage;

You can include this statement at the following hierarchy levels:

• [edit protocols mpls label-switched-path lsp-name fast-reroute]

• [edit logical-systems logical-system-name protocols mpls label-switched-path

lsp-name fast-reroute]

Configuring Multiclass LSPs

A multiclass LSP is an LSP configured to reserve bandwidth for multiple class types and
also carries the traffic for these class types. The differentiated service behavior is
determined by the EXP bits.

You must configure the Differentiated Services domain (see “Configuring Routers for
DiffServ-Aware Traffic Engineering” on page 193) before you can enable a multiclass LSP.
The Differentiated Services domain provides the underlying class types and corresponding
traffic engineering classes that you reference in a multiclass LSP configuration. The traffic
engineering classes must be configured consistently on each router participating in the
Differentiated Services domain for the multiclass LSP to function properly.

NOTE: You must configure extended MAM as the bandwidth model when
you configure multiclass LSPs. See “Configuring the Bandwidth Model” on
page 194.

All the routers participating in a multiclass LSP must be Juniper Networks routers running
Junos OS Release 6.2 or later. The network can include routers from other vendors and
Juniper Networks routers running earlier versions of the Junos OS. However, the multiclass
LSP cannot traverse these routers.

To enable multiclass LSPs, you need to configure the following:

• Configuring Class of Service for the Interfaces on page 206

• Configuring the IGP on page 207
• Configuring Class-Type Bandwidth Constraints for Multiclass LSPs on page 207
• Configuring Policing for Multiclass LSPs on page 208
• Configuring Fast Reroute for Multiclass LSPs on page 208

Configuring Class of Service for the Interfaces

The existing class-of-service infrastructure ensures that traffic that is consistently marked
receives the scheduling guarantees for its class. The classification, marking, and scheduling
necessary to consistently mark traffic are configured with the existing Junos OS CoS
features.

206 Copyright © 2012, Juniper Networks, Inc.

 Chapter 6: DiffServ-Aware Traffic Engineering Configuration Guidelines

NOTE: The Junos OS does not support ATM interfaces.

For information about how to configure CoS, see the Junos OS Class of Service Configuration
Guide.

Configuring the IGP

You can configure either IS-IS or OSPF. The IS-IS and OSPF configurations for routers
supporting multiclass LSPs are standard. For information about how to configure these
protocols, see the Junos OS Routing Protocols Configuration Guide.

Configuring Class-Type Bandwidth Constraints for Multiclass LSPs

You configure a multiclass LSP by using the standard LSP configuration statements and
procedures. To configure an LSP as a multiclass LSP, specify the class type bandwidth
constraints by including the bandwidth statement:

bandwidth {
ct0 bps;
ct1 bps;
ct2 bps;
ct3 bps;
}

For a list of hierarchy levels at which you can include the bandwidth statement, see the
statement summary sections for these statements.

The class type statements specify bandwidth (in bits per second) for the following
classes:

• ct0—Bandwidth reserved for class 0

• ct1—Bandwidth reserved for class 1

• ct2—Bandwidth reserved for class 2

• ct3—Bandwidth reserved for class 3

For example, to configure 50 megabytes of bandwidth for class type 1 and 30 megabytes
of bandwidth for class type 2, include the bandwidth statement as follows:

[edit protocols mpls]

label-switched-path traffic-class {
bandwidth {
ct1 50M;
ct2 30M;
}
}

You cannot configure a bandwidth for a class type and also configure a bandwidth at
the [edit protocols mpls label-switched-path lsp-name bandwidth] hierarchy level. For
example, the following configuration cannot be committed:

[edit protocols mpls]

label-switched-path traffic-class {

Copyright © 2012, Juniper Networks, Inc. 207

Junos OS 12.1 MPLS Applications Configuration Guide

bandwidth {
20M;
ct1 10M;
}
}

You can configure setup and holding priorities for a multiclass LSP, but the following
restrictions apply:

• The setup and holding priorities apply to all classes for which bandwidth is requested.

• The combination of class and priority must be one of the configured traffic engineering
classes. The default traffic engineering class configuration results in multiclass LSPs
that cannot preempt and cannot be preempted. The default setup priority is 7 and the
default holding priority is 0.

• Configuring an invalid combination of class type and priority causes the commit
operation to fail.

• Automatic bandwidth allocation is not supported for multiclass LSPs. If you configure
automatic bandwidth allocation, the commit operation fails.

• LSPs configured with the bandwidth statement but without specifying a class type use
the default class type ct0.

Configuring Policing for Multiclass LSPs

Policing allows you to control the amount of traffic forwarded through a particular
multiclass LSP. Policing helps to ensure that the amount of traffic forwarded through
an LSP never exceeds the requested bandwidth allocation. You can configure multiple
policers for each multiclass LSP. You can also enable automatic policing for multiclass
LSPs.

For information about how to configure a policer for a multiclass LSP, see “Configuring
Policers for LSPs” on page 260 and “Configuring Automatic Policers” on page 262.

Configuring Fast Reroute for Multiclass LSPs

You can enable fast reroute for multiclass LSPs. The bandwidth guarantees for the class
types can be carried over to the detour path in case the primary path of the multiclass
LSP fails. The same traffic class types configured for the primary multiclass LSP are also
signaled for the detour LSP.

The bandwidth guarantee for the detour path is a percentage of the bandwidth configured
for the class types of the primary path. For example, you configure a value of 50 percent
for the detour path and the protected LSP carries traffic for class types CT0 through CT3.
The detour path is signaled with the same class types (CT0 through CT3) but with 50
percent of the bandwidth configured for the protected LSP.

If you configure the router to reserve bandwidth for the detour path, a check is made to
ensure that the link is capable of handling DiffServ-aware traffic engineering, that all of
the traffic class types needed are available, and for CoS capability before accepting it
as a potential detour path. Unsupported links are not used.

208 Copyright © 2012, Juniper Networks, Inc.

 Chapter 6: DiffServ-Aware Traffic Engineering Configuration Guidelines

The bandwidth percentage for fast reroute is signaled from the ingress router to the
egress router. All of the intermediate devices must complete their own CSPF computations
and signaling.

When you configure the bandwidth-percent statement, the detour path bandwidth is
computed by multiplying by the bandwidth configured for the primary multiclass LSP.
For information about how to configure the bandwidth for the multiclass LSP, see
“Configuring Traffic-Engineered LSPs” on page 204.

To configure the percentage of bandwidth used by the detour path based on the
bandwidth of the protected path, include the bandwidth-percent statement:

bandwidth-percent percentage;

You can include this statement at the following hierarchy levels:

• [edit protocols mpls label-switched-path lsp-name fast-reroute]

• [edit logical-systems logical-system-name protocols mpls label-switched-path

lsp-name fast-reroute]

Copyright © 2012, Juniper Networks, Inc. 209

Junos OS 12.1 MPLS Applications Configuration Guide

210 Copyright © 2012, Juniper Networks, Inc.

CHAPTER 7

Static and Explicit-Path LSP Configuration

Guidelines

The following sections describe how to configure static and explicit-path label-switched
paths (LSPs):

• Configuring Static LSPs on page 211

• Configuring Explicit-Path LSPs on page 218

Configuring Static LSPs

To configure static LSPs, configure the ingress router and each router along the path up
to and including the egress router.

To configure static MPLS, perform the following tasks:

• Configuring the Ingress Router for Static LSPs on page 211

• Configuring the Intermediate (Transit) and Egress Routers for Static LSPs on page 214
• Configuring a Bypass LSP for the Static LSP on page 217
• Configuring the Protection Revert Timer for Static LSPs on page 217
• Configuring Static Unicast Routes for Point-to-Multipoint LSPs on page 217

Configuring the Ingress Router for Static LSPs

The ingress router checks the IP address in the incoming packet’s destination address
field and, if it finds a match in the routing table, applies the label associated with that
address to the packets. The label has forwarding information associated with it, including
the address of the next-hop router, and the route preference and CoS values.

To configure static LSPs on the ingress router, include the ingress statement:

ingress {
bandwidth bps;
class-of-service cos-value;
description string;
install {
destination-prefix <active>;
}
link-protection bypass-name name;

Copyright © 2012, Juniper Networks, Inc. 211

Junos OS 12.1 MPLS Applications Configuration Guide

metric metric;
next-hop (address | interface-name | address/interface-name);
no-install-to-address;
node-protection bypass-name name next-next-label label;
policing {
filter filter-name;
no-auto-policing;
}
preference preference;
push out-label;
to address;
}

You can include these statements at the following hierarchy levels:

• [edit protocols mpls static-label-switched-path static-lsp-name]

• [edit logical-systems logical-system-name protocols mpls static-label-switched-path

static-lsp-name]

When you configure a static LSP on the ingress router, the next-hop, push, and to
statements are required; the other statements are optional.

The configuration for a static LSP on the ingress router requires you to configure the
following parts:

• Criteria for analyzing an incoming packet:

• The install statement creates an LSP that handles IPv4 packets. All static MPLS
routes created using the install statement are installed in inet.3 routing table, and
the creating protocol is identified as static. This process is no different from creating
static IPv4 routes at the [edit routing-options static] hierarchy level.

• In the to statement, you configure the IP destination address to check when incoming
packets are analyzed. If the address matches, the specified outgoing label (push
out-label) is assigned to the packet, and the packet enters an LSP. Manually assigned
outgoing labels can have values from 0 through 1,048,575. Each prefix that you
specify is installed as a static route in the routing table.

• The next-hop statement, which supplies the IP address of the next hop to the
destination. You can specify this as the IP address of the next hop, the interface name
(for point-to-point interfaces only), or as address/interface-name to specify an IP
address on an operational interface. When the next hop is on a directly attached
interface, the route is installed in the routing table. You cannot configure a LAN or
nonbroadcast multiaccess (NBMA) interface as a next-hop interface.

• Properties to apply to the LSP (all are optional):

• Bandwidth reserved for this LSP (bandwidth bps)

• Link protection and node protection to apply to the LSP (bypass bypass-name,
link-protection bypass-name name, node-protection bypass-name next-next-label
label)

• Metric value to apply to the LSP (metric)

212 Copyright © 2012, Juniper Networks, Inc.

 Chapter 7: Static and Explicit-Path LSP Configuration Guidelines

• Class-of-service value to apply to the LSP (class-of-service)

• Preference value to apply to the LSP (preference)

• Traffic policing to apply to the LSP (policing)

• Text description to apply to the LSP (description)

• Install or no-install policy (install or no-install-to-address)

To determine whether a static ingress route is installed, use the command show route
table inet.0 protocol static. Sample output follows. The push keyword denotes that a
label is to be added in front of an IP packet.
10.0.0.0 *[Static/5] 00:01:48
> to 11.1.1.1 via so-0/0/0, push 1000123

Example: Configuring the Ingress Router

Configure the ingress router for a static LSP that consists of three routers (see Figure 22
on page 213).

Figure 22: Static MPLS Configuration

For packets addressed to 10.0.0.0, assign label 1000123 and transmit them to the next-hop
router at 11.1.1.1:

[edit]
interfaces {
so-0/0/0 {
unit 0 {
family mpls;
}
}
}
protocols {
mpls {
static-label-switched-path path1 {
ingress {
next-hop 11.1.1.1;
to 10.0.0.0;
push 1000123;
}
}

Copyright © 2012, Juniper Networks, Inc. 213

Junos OS 12.1 MPLS Applications Configuration Guide

interface so-0/0/0.0;
}
}
routing-options {
static {
route 10.0.0.0/8 {
static-lsp-next-hop path1;
}
}

To determine whether the static ingress route is installed, use the following command:

user@host> show route table inet.0 protocol static

Sample output follows. The push 1000123 keyword identifies the route.

10.0.0.0/8 *[Static/5] 00:01:48

> to 11.1.1.1 via so-0/0/0.0, push 1000123

Configuring the Intermediate (Transit) and Egress Routers for Static LSPs
Intermediate (transit) and egress routers perform similar functions—they modify the
label that has been applied to a packet. An intermediate router can change the label. An
egress router removes the label (if the packet still contains a label) and continues
forwarding the packet to its destination.

To configure static LSPs on intermediate and egress routers, include the transit statement:

static-label-switched-path lsp-name {
transit incoming-label {
bandwidth bps;
description string;
link-protection bypass-name name;
next-hop (address | interface-name | address/interface-name);
node-protection bypass-name name next-next-label label;
pop;
swap out-label;
}

You can include these statements at the following hierarchy levels:

• [edit protocols mpls static-label-switched-path static-lsp-name]

• [edit logical-systems logical-system-name protocols mpls static-label-switched-path

static-lsp-name]

For the transit statement configuration, the next-hop and pop | swap statements are
required. The remaining statements are optional.

Each statement within the transit statement consists of the following parts:

• Packet label (specified in the transit statement)

• The next-hop statement, which supplies the IP address of the next hop to the
destination. The address is specified as the IP address of the next hop, or the interface
name (for point-to-point interfaces only), or address and interface-name to specify an
IP address on an operational interface. When the specified next hop is on a directly

214 Copyright © 2012, Juniper Networks, Inc.

 Chapter 7: Static and Explicit-Path LSP Configuration Guidelines

attached interface, this route is installed in the routing table. You cannot configure a
LAN or NBMA interface as a next-hop interface.

• Operation to perform on the labeled packet:

• For egress routers, you generally just remove the packet’s label altogether (pop) and
continue forwarding the packet to the next hop. However, if the previous router
removed the label, the egress router examines the packet’s IP header and forwards
the packet toward its IP destination.

• For intermediate (transit) routers only, exchange the label for another label (swap
out-label). Manually assigned incoming labels can have values from 1,000,000
through 1,048,575. Manually assigned outgoing labels can have values from 0 through
1,048,575.

• Label properties to apply to the packet (all are optional):

• Bandwidth reserved for this route (bandwidth bps).

• Link-protection and node-protection to apply to the LSP (bypass bypass-name,

link-protection bypass-name name, node-protection bypass-name next-next-label
label).

• Text description to apply to the LSP (specified in the description statement).

The static routes are installed in the default MPLS routing table, mpls.0, and the creating
protocol is identified as static. To verify that a static route is properly installed, use the
command show route table mpls.0 protocol static. Sample output follows:

1000123 *[Static/5] 00:00:38

> to 12.2.2.2 via so-5/0/0.0, swap 1000456

You can configure a revert timer for a static LSP transiting an intermediate router. After
traffic has been switched to a bypass static LSP, it is typically switched back to the
primary static LSP when it comes back up. There is a configurable delay in the time (called
the revert timer) between when the primary static LSP comes up and when traffic is
reverted back to it from the bypass static LSP. This delay is needed because when the
primary LSP comes back up, it is not certain whether all of the interfaces on the
downstream node of the primary path have come up yet. You can display the revert timer
value for an interface using the show mpls interface detail command. For more information,
see “Configuring the Revert Timer for LSPs” on page 150.

Example: Configuring an Intermediate Router

For packets labeled 1000123 arriving on interface so-0/0/0, assign the label 1000456,
and transmit them to the next-hop router at 12.2.2.2:

[edit]
interfaces {
so-0/0/0 {
unit 0 {
family mpls;
}
}
}

Copyright © 2012, Juniper Networks, Inc. 215

Junos OS 12.1 MPLS Applications Configuration Guide

protocols {
mpls {
static-label-switched-path path1 {
transit 1000123 {
next-hop 12.2.2.2;
swap 1000456;
}
}
interface so-0/0/0.0;
}
}

To determine whether the static intermediate route is installed, use the following
command:

user@host> show route table mpls.0 protocol static

Sample output follows. The swap 1000456 keyword identifies the route.

1000123 *[Static/5] 00:01:48

> to 12.2.2.2 via so-0/0/0, swap 1000456

Example: Configuring an Egress Router

For packets labeled 1000456 arriving on interface so-0/0/0, remove the label and transmit
the packets to the next-hop router at 13.3.3.3:

[edit]
interfaces {
so-0/0/0 {
unit 0 {
family mpls;
}
}
}
protocols {
mpls {
static-label-switched-path path1 {
transit 1000456 {
next-hop 13.3.3.3;
pop;
}
}
interface so-0/0/0.0;
}
}

To determine whether the static egress route is installed, use the following command:

user@host> show route table mpls.0 protocol static

Sample output follows. The pop keyword identifies the egress route.

1000456 *[Static/5] 00:01:48

> to 13.3.3.3 via so-0/0/0, pop

216 Copyright © 2012, Juniper Networks, Inc.

 Chapter 7: Static and Explicit-Path LSP Configuration Guidelines

Configuring a Bypass LSP for the Static LSP

To enable a bypass LSP for the static LSP, configure the bypass statement:

bypass bypass-name {
bandwidth bps;
description string;
next-hop (address | interface-name | address/interface-name);
push out-label;
to address;
}

Configuring the Protection Revert Timer for Static LSPs

For static LSPs configured with a bypass static LSP, it is possible to configure the
protection revert timer. If a static LSP goes down and traffic is switched to the bypass
LSP, the protection revert timer specifies the amount of time (in seconds) that the LSP
must wait before it can revert back to the original static LSP.

The range of values you can configure for the protection revert timer is 0 through 65,535
seconds. The default value is 5 seconds.

If you configure a value of 0 seconds, the traffic on the LSP, once switched from the
original static LSP to the bypass static LSP, remains on the bypass LSP permanently
(until the network operator intervenes or until the bypass LSP goes down).

You can configure the protection revert timer for all LSPs on the router at the [edit
protocols mpls] hierarchy level or for a specific LSP at the [edit protocols mpls
label-switched-path lsp-name] hierarchy level.

To configure the protection revert timer for static LSPs include the protection-revert-time
statement:

protection-revert-time seconds;

For a list of hierarchy levels at which you can include this statement, see the summary
section for this statement.

Configuring Static Unicast Routes for Point-to-Multipoint LSPs

You can configure a static unicast IP route with a point-to-multipoint LSP as the next
hop. For more information about point-to-multipoint LSPs, see “Point-to-Multipoint LSPs
Overview” on page 52, “Configuring Primary and Branch LSPs for Point-to-Multipoint
LSPs” on page 221, and “Configuring CCC Switching for Point-to-Multipoint LSPs” on
page 562.

To configure a static unicast route for a point-to-multipoint LSP, complete the following
steps:

1. On the ingress PE router, configure a static IP unicast route with the point-to-multipoint
LSP name as the next hop by including the p2mp-lsp-next-hop statement:

p2mp-lsp-next-hop point-to-multipoint-lsp-next-hop;

Copyright © 2012, Juniper Networks, Inc. 217

Junos OS 12.1 MPLS Applications Configuration Guide

You can include this statement at the following hierarchy levels:

• [edit routing-options static route route-name]

• [edit logical-systems logical-system-name routing-options static route route-name]

2. On the egress PE router, configure a static IP unicast route with the same destination
address configured in Step 1 (the address configured at the [edit routing-options static
route] hierarchy level) by including the next-hop statement:

next-hop address;

You can include this statement at the following hierarchy levels:

• [edit routing-options static route route-name]

• [edit logical-systems logical-system-name routing-options static route route-name]

NOTE: CCC and static routes cannot use the same point-to-multipoint
LSP.

For more information on static routes, see the Junos OS Routing Protocols Configuration
Guide.

The following show route command output displays a unicast static route pointing to a
point-to-multipoint LSP on the ingress PE router where the LSP has two branch next
hops:

user@host> show route 5.5.5.5 detail

inet.0: 29 destinations, 30 routes (28 active, 0 holddown, 1 hidden)
5.5.5.5/32 (1 entry, 1 announced)
*Static Preference: 5
Next hop type: Flood
Next hop: via so-0/3/2.0 weight 1
Label operation: Push 100000
Next hop: via t1-0/1/1.0 weight 1
Label operation: Push 100064
State: <Active Int Ext>
Local AS: 10458
Age: 2:41:15
Task: RT
Announcement bits (2): 0-KRT 3-BGP.0.0.0.0+179
AS path: I

Configuring Explicit-Path LSPs

If you disable constrained-path label-switched path (LSP) computation, as described

in “Disabling Constrained-Path LSP Computation” on page 170, you can configure LSPs
manually or allow the LSPs to follow the IGP path.

When explicit-path LSPs are configured, the LSP is established along the path you
specified. If the path is topologically not feasible, either because the network is partitioned
or insufficient resources are available along some parts of the path, the LSP will fail. No

218 Copyright © 2012, Juniper Networks, Inc.

 Chapter 7: Static and Explicit-Path LSP Configuration Guidelines

alternative paths can be used. If the setup succeeds, the LSP stays on the defined path
indefinitely.

To configure an explicit-path LSP, follow these steps:

1. Configure the path information in a named path, as described in “Creating Named

Paths” on page 56. To configure complete path information, specify every router hop
between the ingress and egress routers, preferably using the strict attribute. To
configure incomplete path information, specify only a subset of router hops, using the
loose attribute in places where the path is incomplete.

For incomplete paths, the MPLS routers complete the path by querying the local
routing table. This query is done on a hop-by-hop basis, and each router can figure
out only enough information to reach the next explicit hop. It might be necessary to
traverse a number of routers to reach the next (loose) explicit hop.

Configuring incomplete path information creates portions of the path that depend
on the current routing table, and this portion of the path can reroute itself as the
topology changes. Therefore, an explicit-path LSP that contains incomplete path
information is not completely fixed. These types of LSPs have only a limited ability to
repair themselves, and they tend to create loops or flaps depending on the contents
of the local routing table.

2. To configure the LSP and point it to the named path, use either the primary or secondary
statement, as described in “Configuring Primary and Secondary LSPs” on page 149.

3. Disable constrained-path LSP computation by including the no-cspf statement either

as part of the LSP or as part of a primary or secondary statement. For more information,
see “Disabling Constrained-Path LSP Computation” on page 170.

4. Configure any other LSP properties.

Using explicit-path LSPs has the following drawbacks:

• More configuration effort is required.

• Configured path information cannot take into account dynamic network bandwidth
reservation, so the LSPs tend to fail when resources become depleted.

• When an explicit-path LSP fails, you might need to manually repair it.

Because of these limitations, we recommend that you use explicit-path LSPs only in
controlled situations, such as to enforce an optimized LSP placement strategy resulting
from computations with an offline simulation software package.

Copyright © 2012, Juniper Networks, Inc. 219

Junos OS 12.1 MPLS Applications Configuration Guide

220 Copyright © 2012, Juniper Networks, Inc.

CHAPTER 8

Point-to-Multipoint LSP Configuration

Guidelines

This chapter discusses the following topics:

• Configuring Primary and Branch LSPs for Point-to-Multipoint LSPs on page 221
• Configuring Link Protection for Point-to-Multipoint LSPs on page 223
• Configuring Graceful Restart for Point-to-Multipoint LSPs on page 224
• Configuring a Multicast RPF Check Policy for Point-to-Multipoint LSPs on page 224
• Configuring Ingress PE Router Redundancy for Point-to-Multipoint LSPs on page 225
• Enabling Point-to-Point LSPs to Monitor Egress PE Routers on page 226
• Preserving Point-to-Multipoint LSP Functioning with Different Junos OS
Releases on page 227
• Example: Configuring an RSVP-Signaled Point-to-Multipoint LSP on page 227
• Configuring Inter-domain P2MP LSPs on page 245

Configuring Primary and Branch LSPs for Point-to-Multipoint LSPs

A point-to-multipoint MPLS label-switched path (LSP) is an RSVP LSP with multiple

destinations. By taking advantage of the MPLS packet replication capability of the network,
point-to-multipoint LSPs avoid unnecessary packet replication at the ingress router. For
more information about point-to-multipoint LSPs, see “Point-to-Multipoint LSPs
Overview” on page 52.

To configure a point-to-multipoint LSP, you need to configure the primary LSP from the
ingress router and the branch LSPs that carry traffic to the egress routers, as described
in the following sections:

• Configuring the Primary Point-to-Multipoint LSP on page 222

• Configuring a Branch LSP for Point-to-Multipoint LSPs on page 222

Copyright © 2012, Juniper Networks, Inc. 221

Junos OS 12.1 MPLS Applications Configuration Guide

Configuring the Primary Point-to-Multipoint LSP

A point-to-multipoint LSP must have a configured primary point-to-multipoint LSP to
carry traffic from the ingress router. The configuration of the primary point-to-multipoint
LSP is similar to a signaled LSP. See “Configuring the Ingress Router for MPLS-Signaled
LSPs” on page 56 for more information. In addition to the conventional LSP configuration,
you need to specify a path name for the primary point-to-multipoint LSP by including
the p2mp statement:

p2mp p2mp-lsp-name;

You can include this statement at the following hierarchy levels:

• [edit protocols mpls label-switched-path lsp-name]

• [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name]

You can enable the optimization timer for point-to-multipoint LSPs. See “Optimizing
Signaled LSPs” on page 180 for more information.

Configuring a Branch LSP for Point-to-Multipoint LSPs

The primary point-to-multipoint LSP sends traffic to two or more branch LSPs carrying
traffic to each of the egress provider edge (PE) routers. In the configuration for each of
these branch LSPs, the point-to-multipoint LSP path name you specify must be identical
to the path name configured for the primary point-to-multipoint LSP. See “Configuring
the Primary Point-to-Multipoint LSP” on page 222 for more information.

To associate a branch LSP with the primary point-to-multipoint LSP, specify the
point-to-multipoint LSP name by including the p2mp statement:

p2mp p2mp-lsp-name;

You can include this statement at the following hierarchy levels:

• [edit protocols mpls label-switched-path lsp-name]

• [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name]

NOTE: Any change in any of the branch LSPs of a point-to-multipoint LSP,

either due to a user action or an automatic adjustment made by the router,
causes the primary and branch LSPs to be resignaled. The new
point-to-multipoint LSP is signaled first before the old path is taken down.

The following sections describe how you can configure the branch LSP as a dynamically
signaled path using Constrained Shortest Path First (CSPF), as a static path, or as a
combination of dynamic and static paths:

• Configuring the Branch LSP as a Dynamic Path on page 223

• Configuring the Branch LSP as a Static Path on page 223

222 Copyright © 2012, Juniper Networks, Inc.

 Chapter 8: Point-to-Multipoint LSP Configuration Guidelines

Configuring the Branch LSP as a Dynamic Path

By default, the branch LSP for a point-to-multipoint LSP is signaled dynamically using
CSPF and requires no configuration.

When a point-to-multipoint LSP is changed, either by the addition or deletion of new

destinations or by the recalculation of the path to existing destinations, certain nodes in
the tree might receive data from more than one incoming interface. This can happen
under the following conditions:

• Some of the branch LSPs to destinations are statically configured and might intersect
with statically or dynamically calculated paths to other destinations.

• When a dynamically calculated path for a branch LSP results in a change of incoming
interface for one of the nodes in the network, the older path is not immediately torn
down after the new one has been signaled. This ensures that any data in transit relying
on the older path can reach its destination. However, network traffic can potentially
use either path to reach the destination.

• A faulty router at the ingress calculates the paths to two different branch destinations
such that a different incoming interface is chosen for these branch LSPs on a router
node common to these branch LSPs.

Configuring the Branch LSP as a Static Path

You can configure the branch LSP for a point-to-multipoint LSP as a static path. See
“Configuring Static LSPs” on page 211 for more information.

Configuring Link Protection for Point-to-Multipoint LSPs

Link protection helps to ensure that traffic going over a specific interface to a neighboring
router can continue to reach this router if that interface fails. When link protection is
configured for an interface and a point-to-multipoint LSP that traverses this interface,
a bypass LSP is created that handles this traffic if the interface fails. The bypass LSP
uses a different interface and path to reach the same destination.

To extend link protection to all of the paths used by a point-to-multipoint LSP, link
protection must be configured on each router that each branch LSP traverses. If you
enable link protection on a point-to-multipoint LSP, you must enable link protection on
all of the branch LSPs.

The Internet draft draft-ietf-mpls-rsvp-te-p2mp-01.txt, Extensions to RSVP-TE for Point

to Multipoint TE LSPs, describes link protection for point-to-multipoint LSPs.

To enable link protection on point-to-multipoint LSPs, complete the following steps:

1. Configure link protection on each branch LSP. To configure link protection, include
the link-protection statement:

link-protection;

You can include this statement at the following hierarchy levels:

Copyright © 2012, Juniper Networks, Inc. 223

Junos OS 12.1 MPLS Applications Configuration Guide

• [edit protocols mpls label-switched-path branch-lsp-name]

• [edit logical-systems logical-system-name protocols mpls label-switched-path

branch-lsp-name]

2. Configure link protection for each RSVP interface on each router that the branch LSP
traverses. For information about how to configure link protection on RSVP interfaces,
see “Configuring Link Protection on Interfaces Used by LSPs” on page 404.

For more information on how to configure link protection, see “Configuring Node Protection
or Link Protection for LSPs” on page 402.

Configuring Graceful Restart for Point-to-Multipoint LSPs

You can configure graceful restart on point-to-multipoint LSPs. Graceful restart allows
a router undergoing a restart to inform its adjacent neighbors of its condition. The
restarting router requests a grace period from the neighbor or peer, which can then
cooperate with the restarting router. The restarting router can still forward MPLS traffic
during the restart period; convergence in the network is not disrupted. The restart is not
apparent to the rest of the network, and the restarting router is not removed from the
network topology. RSVP graceful restart can be enabled on both transit routers and
ingress routers.

To enable graceful restart on a router handling point-to-multipoint LSP traffic, include

the graceful-restart statement:

graceful-restart;

You can include this statement at the following hierarchy levels:

• [edit routing-options]

• [edit logical-systems logical-system-name routing-options]

The graceful restart configuration for point-to-multipoint LSPs is identical to that of

point-to-point LSPs. For more information on how to configure graceful restart, see
“Configuring RSVP Graceful Restart” on page 412.

Configuring a Multicast RPF Check Policy for Point-to-Multipoint LSPs

You can control whether a reverse path forwarding (RPF) check is performed for a source
and group entry before installing a route in the multicast forwarding cache. This makes
it possible to use point-to-multipoint LSPs to distribute multicast traffic to PIM islands
situated downstream from the egress routers of the point-to-multipoint LSPs.

By configuring the rpf-check-policy statement, you can disable RPF checks for a source
and group pair. You would typically configure this statement on the egress routers of a
point-to-multipoint LSP, because the interface receiving the multicast traffic on a
point-to-multipoint LSP egress router might not always be the RPF interface.

You can also configure a routing policy to act upon a source and group pair. This policy
behaves like an import policy, so if no policy term matches the input data, the default
policy action is “acceptance.” An accept policy action enables RPF checks. A reject policy

224 Copyright © 2012, Juniper Networks, Inc.

 Chapter 8: Point-to-Multipoint LSP Configuration Guidelines

action (applied to all source and group pairs that are not accepted) disables RPF checks
for the pair.

To configure a multicast RPF check policy for a point-to-multipoint LSP, specify the RPF
check policy using the rpf-check-policy statement:

rpf-check-policy policy;

You can include this statement at the following hierarchy levels:

• [edit routing-options multicast]

• [edit logical-systems logical-system-name routing-options multicast]

You also must configure a policy for the multicast RPF check. You configure policies at
the [edit policy-options] hierarchy level. For more information, see the Junos OS Policy
Framework Configuration Guide.

NOTE: When you configure the rpf-check-policy statement, the Junos OS

cannot perform RPF checks on incoming traffic and therefore cannot detect
traffic arriving on the wrong interface. This might cause routing loops to form.

Example: Configuring Multicast RPF Check Policy for a Point-to-Multipoint LSP

Configure a policy to ensure that an RPF check is not performed for sources with prefix
128.83/16 or longer that belong to groups having a prefix of 228/8 or longer:

[edit]
policy-options {
policy-statement rpf-sg-policy {
from {
route-filter 228.0.0.0/8 orlonger;
source-address-filter 128.83.0.0/16 orlonger;
}
then {
reject;
}
}
}

Configuring Ingress PE Router Redundancy for Point-to-Multipoint LSPs

You can configure one or more PE routers as part of a backup PE router group to enable
ingress PE router redundancy. You accomplish this by configuring the IP addresses of
the backup PE routers (at least one backup PE router is required) and the local IP address
used by the local PE router.

You must also configure a full mesh of point-to-point LSPs between the primary and
backup PE routers. You also need to configure BFD on these LSPs. See “Configuring BFD
for RSVP-Signaled LSPs” on page 268 and “Configuring BFD for LDP LSPs” on page 486 for
more information.

Copyright © 2012, Juniper Networks, Inc. 225

Junos OS 12.1 MPLS Applications Configuration Guide

To configure ingress PE router redundancy for point-to-multipoint LSPs, include the

backup-pe-group statement:

backup-pe-group pe-group-name {
backups [addresses];
local-address address;
}

For a list of hierarchy levels at which you can include these statements, see the statement
summary sections for these statements.

After you configure the ingress PE router redundancy backup group, you must also apply
the group to a static route on the PE router. This ensures that the static route is active
(installed in the forwarding table) when the local PE router is the designated forwarder
for the backup PE group. You can only associate a backup PE router group with a static
route that also has the p2mp-lsp-next-hop statement configured. For more information,
see “Configuring Static Unicast Routes for Point-to-Multipoint LSPs” on page 217.

Enabling Point-to-Point LSPs to Monitor Egress PE Routers

Configuring an LSP with the associate-backup-pe-groups statement enables it to monitor

the status of the PE router to which it is configured. You can configure multiple backup
PE router groups using the same router's address. A failure of this LSP indicates to all of
the backup PE router groups that the destination PE router is down. The
associate-backup-pe-groups statement is not tied to a specific backup PE router group.
It applies to all groups that are interested in the status of the LSP to that address.

To allow an LSP to monitor the status of the egress PE router, include the
associate-backup-pe-groups statement:

associate-backup-pe-groups;

This statement can be configured at the following hierarchy levels:

• [edit protocols mpls label-switched-path lsp-name]

• [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name]

If you configure the associate-backup-pe-groups statement, you must configure BFD for
the point-to-point LSP. For information about how to configure BFD for an LSP, see
“Configuring BFD for MPLS IPv4 LSPs” on page 267 and “Configuring BFD for LDP LSPs”
on page 486.

You also must configure a full mesh of point-to-point LSPs between the PE routers in
the backup PE router group. A full mesh is required so that each PE router within the
group can independently determine the status of the other PE routers, allowing each
router to independently determine which PE router is currently the designated forwarder
for the backup PE router group.

If you configure multiple LSPs with the associate-backup-pe-groups statement to the

same destination PE router, the first LSP configured is used to monitor the forwarding
state to that PE router. If you configure multiple LSPs to the same destination, make sure

226 Copyright © 2012, Juniper Networks, Inc.

 Chapter 8: Point-to-Multipoint LSP Configuration Guidelines

to configure similar parameters for the LSPs. With this configuration scenario, a failure
notification might be triggered even though the remote PE router is still up.

Preserving Point-to-Multipoint LSP Functioning with Different Junos OS Releases

In Junos OS Release 9.1 and earlier, Resv messages that include the S2L_SUB_LSP object
are rejected by default. In Junos OS Release 9.2 and later, such messages are accepted
by default. To ensure proper functioning of point-to-multipoint LSPs in a network that
includes both devices running Junos OS Release 9.1 and earlier and devices running Junos
9.2 and later, you must include the no-p2mp-sublsp statement in the configuration of
the devices running Junos 9.2 and later:

no-p2mp-sublsp;

You can include this statement at the following hierarchy levels:

• [edit protocols rsvp]

• [edit logical-systems logical-system-name protocols rsvp]

Example: Configuring an RSVP-Signaled Point-to-Multipoint LSP

This example shows how to configure a collection of paths to create an RSVP-signaled

point-to-multipoint label-switched path (LSP).

• Requirements on page 227

• Overview on page 227
• Configuration on page 228
• Verification on page 244

Requirements
In this example, no special configuration beyond device initialization is required.

Overview
In this example, multiple routing devices serve as the transit, branch, and leaf nodes of
a single point-to-multipoint LSP. On the provider edge (PE), Device PE1 is the ingress
node. The branches go from PE1 to PE2, PE1 to PE3, and PE1 to PE4. Static unicast routes
on the ingress node (PE1) point to the egress nodes.

This example also demonstrates static routes with a next hop that is a point-to-multipoint
LSP, using the p2mp-lsp-next-hop statement. This is useful when implementing
filter-based forwarding.

NOTE: Another option is to use the lsp-next-hop statement to configure a

regular point-to-point LSP to be the next hop. Though not shown in this
example, you can optionally assign an independent preference and metric
to the next hop.

Copyright © 2012, Juniper Networks, Inc. 227

Junos OS 12.1 MPLS Applications Configuration Guide

Topology Diagram

Figure 23 on page 228 shows the topology used in this example.

Figure 23: RSVP-Signaled Point-to-Multipoint LSP

P2 PE2 CE2

CE1 PE1 P3 PE3 CE3

P4 PE4 CE4

g041174
Configuration
CLI Quick To quickly configure this example, copy the following commands, paste them into a text
Configuration file, remove any line breaks, change any details necessary to match your network
configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy
level.

Device PE1 set interfaces ge-2/0/2 unit 0 description PE1-to-CE1

set interfaces ge-2/0/2 unit 0 family inet address 10.0.244.10/30
set interfaces fe-2/0/10 unit 1 description PE1-to-P2
set interfaces fe-2/0/10 unit 1 family inet address 2.2.2.1/24
set interfaces fe-2/0/10 unit 1 family mpls
set interfaces fe-2/0/9 unit 8 description PE1-to-P3
set interfaces fe-2/0/9 unit 8 family inet address 6.6.6.1/24
set interfaces fe-2/0/9 unit 8 family mpls
set interfaces fe-2/0/8 unit 9 description PE1-to-P4
set interfaces fe-2/0/8 unit 9 family inet address 3.3.3.1/24
set interfaces fe-2/0/8 unit 9 family mpls
set interfaces lo0 unit 1 family inet address 100.10.10.10/32
set protocols rsvp interface fe-2/0/10.1
set protocols rsvp interface fe-2/0/9.8
set protocols rsvp interface fe-2/0/8.9
set protocols rsvp interface lo0.1
set protocols mpls traffic-engineering bgp-igp
set protocols mpls label-switched-path PE1-PE2 to 100.50.50.50
set protocols mpls label-switched-path PE1-PE2 link-protection
set protocols mpls label-switched-path PE1-PE2 p2mp p2mp1

228 Copyright © 2012, Juniper Networks, Inc.

 Chapter 8: Point-to-Multipoint LSP Configuration Guidelines

set protocols mpls label-switched-path PE1-PE3 to 100.70.70.70

set protocols mpls label-switched-path PE1-PE3 link-protection
set protocols mpls label-switched-path PE1-PE3 p2mp p2mp1
set protocols mpls label-switched-path PE1-PE4 to 100.40.40.40
set protocols mpls label-switched-path PE1-PE4 link-protection
set protocols mpls label-switched-path PE1-PE4 p2mp p2mp1
set protocols mpls interface fe-2/0/10.1
set protocols mpls interface fe-2/0/9.8
set protocols mpls interface fe-2/0/8.9
set protocols mpls interface lo0.1
set protocols ospf traffic-engineering
set protocols ospf area 0.0.0.0 interface ge-2/0/2.0
set protocols ospf area 0.0.0.0 interface fe-2/0/10.1
set protocols ospf area 0.0.0.0 interface fe-2/0/9.8
set protocols ospf area 0.0.0.0 interface fe-2/0/8.9
set protocols ospf area 0.0.0.0 interface lo0.1
set routing-options static route 5.5.5.0/24 p2mp-lsp-next-hop p2mp1
set routing-options static route 7.7.7.0/24 p2mp-lsp-next-hop p2mp1
set routing-options static route 4.4.4.0/24 p2mp-lsp-next-hop p2mp1
set routing-options router-id 100.10.10.10

Device CE1 set interfaces ge-1/3/2 unit 0 family inet address 10.0.244.9/30
set interfaces ge-1/3/2 unit 0 description CE1-to-PE1
set routing-options static route 10.0.104.8/30 next-hop 10.0.244.10
set routing-options static route 10.0.134.8/30 next-hop 10.0.244.10
set routing-options static route 10.0.224.8/30 next-hop 10.0.244.10

Device CE2 set interfaces ge-1/3/3 unit 0 family inet address 10.0.224.9/30
set interfaces ge-1/3/3 unit 0 description CE2-to-PE2
set routing-options static route 10.0.244.8/30 next-hop 10.0.224.10

Device CE3 set interfaces ge-2/0/1 unit 0 family inet address 10.0.134.9/30
set interfaces ge-2/0/1 unit 0 description CE3-to-PE3
set routing-options static route 10.0.244.8/30 next-hop 10.0.134.10

Device CE4 set interfaces ge-3/1/3 unit 0 family inet address 10.0.104.10/30
set interfaces ge-3/1/3 unit 0 description CE4-to-PE4
set routing-options static route 10.0.244.8/30 next-hop 10.0.104.9

Configuring the Ingress Label-Switched Router (LSR) (Device PE1)

Step-by-Step To configure Device PE1:

Procedure
1. Configure the interfaces, interface encapsulation, and protocol families.

[edit interfaces]
user@PE1# set ge-2/0/2 unit 0 description PE1-to-CE1
user@PE1# set ge-2/0/2 unit 0 family inet address 10.0.244.10/30
user@PE1# set fe-2/0/10 unit 1 description PE1-to-P2
user@PE1# set fe-2/0/10 unit 1 family inet address 2.2.2.1/24
user@PE1# set fe-2/0/10 unit 1 family mpls
user@PE1# set fe-2/0/9 unit 8 description PE1-to-P3
user@PE1# set fe-2/0/9 unit 8 family inet address 6.6.6.1/24
user@PE1# set fe-2/0/9 unit 8 family mpls
user@PE1# set fe-2/0/8 unit 9 description PE1-to-P4

Copyright © 2012, Juniper Networks, Inc. 229

Junos OS 12.1 MPLS Applications Configuration Guide

user@PE1# set fe-2/0/8 unit 9 family inet address 3.3.3.1/24

user@PE1# set fe-2/0/8 unit 9 family mpls
user@PE1# set lo0 unit 1 family inet address 100.10.10.10/32

2. Enable RSVP, MPLS, and OSPF on the interfaces.

[edit protocols]
user@PE1# set rsvp interface fe-2/0/10.1
user@PE1# set rsvp interface fe-2/0/9.8
user@PE1# set rsvp interface fe-2/0/8.9
user@PE1# set rsvp interface lo0.1
user@PE1# set mpls interface fe-2/0/10.1
user@PE1# set mpls interface fe-2/0/9.8
user@PE1# set mpls interface fe-2/0/8.9
user@PE1# set mpls interface lo0.1
user@PE1# set ospf area 0.0.0.0 interface ge-2/0/2.0
user@PE1# set ospf area 0.0.0.0 interface fe-2/0/10.1
user@PE1# set ospf area 0.0.0.0 interface fe-2/0/9.8
user@PE1# set ospf area 0.0.0.0 interface fe-2/0/8.9
user@PE1# set ospf area 0.0.0.0 interface lo0.1

3. Configure the MPLS point-to-multipoint LSPs.

[edit protocols]
user@PE1# set mpls label-switched-path PE1-PE2 to 100.50.50.50
user@PE1# set mpls label-switched-path PE1-PE2 p2mp p2mp1
user@PE1# set mpls label-switched-path PE1-PE3 to 100.70.70.70
user@PE1# set mpls label-switched-path PE1-PE3 p2mp p2mp1
user@PE1# set mpls label-switched-path PE1-PE4 to 100.40.40.40
user@PE1# set mpls label-switched-path PE1-PE4 p2mp p2mp1

4. (Optional) Enable link protection on the LSPs.

Link protection helps to ensure that traffic sent over a specific interface to a
neighboring router can continue to reach the router if that interface fails.

[edit protocols]
user@PE1# set mpls label-switched-path PE1-PE2 link-protection
user@PE1# set mpls label-switched-path PE1-PE3 link-protection
user@PE1# set mpls label-switched-path PE1-PE4 link-protection

5. Enable MPLS to perform traffic engineering for OSPF.

[edit protocols]
user@PE1# set mpls traffic-engineering bgp-igp

This causes the ingress routes to be installed in the inet.0 routing table. By default,
MPLS performs traffic engineering for BGP only. You need to enable MPLS traffic
engineering on the ingress LSR only.

6. Enable traffic engineering for OSPF.

[edit protocols]
user@PE1# set ospf traffic-engineering

This causes the shortest-path first (SPF) algorithm to take into account the LSPs
configured under MPLS.

230 Copyright © 2012, Juniper Networks, Inc.

 Chapter 8: Point-to-Multipoint LSP Configuration Guidelines

7. Configure the router ID.

[edit routing-options]
user@PE1# set router-id 100.10.10.10

8. Configure static IP unicast routes with the point-to-multipoint LSP name as the
next hop for each route.

[edit routing-options]
user@PE1# set static route 5.5.5.0/24 p2mp-lsp-next-hop p2mp1
user@PE1# set static route 7.7.7.0/24 p2mp-lsp-next-hop p2mp1
user@PE1# set static route 4.4.4.0/24 p2mp-lsp-next-hop p2mp1

9. If you are done configuring the device, commit the configuration.

[edit]
user@PE1# commit

Configuring the Transit and Egress LSRs (Devices P2, P3, P4, PE2, PE3, and PE4)

Step-by-Step To configure the transit and egress LSRs:

Procedure
1. Configure the interfaces, interface encapsulation, and protocol families.

[edit]
user@P2# set interfaces fe-2/0/10 unit 2 description P2-to-PE1
user@P2# set interfaces fe-2/0/10 unit 2 family inet address 2.2.2.2/24
user@P2# set interfaces fe-2/0/10 unit 2 family mpls
user@P2# set interfaces fe-2/0/9 unit 10 description P2-to-PE2
user@P2# set interfaces fe-2/0/9 unit 10 family inet address 5.5.5.1/24
user@P2# set interfaces fe-2/0/9 unit 10 family mpls
user@P2# set interfaces lo0 unit 2 family inet address 100.20.20.20/32

user@PE2# set interfaces ge-2/0/3 unit 0 description PE2-to-CE2

user@PE2# set interfaces ge-2/0/3 unit 0 family inet address 10.0.224.10/30
user@PE2# set interfaces fe-2/0/10 unit 5 description PE2-to-P2
user@PE2# set interfaces fe-2/0/10 unit 5 family inet address 5.5.5.2/24
user@PE2# set interfaces fe-2/0/10 unit 5 family mpls
user@PE2# set interfaces lo0 unit 5 family inet address 100.50.50.50/32

user@P3# set interfaces fe-2/0/10 unit 6 description P3-to-PE1

user@P3# set interfaces fe-2/0/10 unit 6 family inet address 6.6.6.2/24
user@P3# set interfaces fe-2/0/10 unit 6 family mpls
user@P3# set interfaces fe-2/0/9 unit 11 description P3-to-PE3
user@P3# set interfaces fe-2/0/9 unit 11 family inet address 7.7.7.1/24
user@P3# set interfaces fe-2/0/9 unit 11 family mpls
user@P3# set interfaces lo0 unit 6 family inet address 100.60.60.60/32

user@PE3# set interfaces ge-2/0/1 unit 0 description PE3-to-CE3

user@PE3# set interfaces ge-2/0/1 unit 0 family inet address 10.0.134.10/30
user@PE3# set interfaces fe-2/0/10 unit 7 description PE3-to-P3
user@PE3# set interfaces fe-2/0/10 unit 7 family inet address 7.7.7.2/24
user@PE3# set interfaces fe-2/0/10 unit 7 family mpls
user@PE3# set interfaces lo0 unit 7 family inet address 100.70.70.70/32

Copyright © 2012, Juniper Networks, Inc. 231

Junos OS 12.1 MPLS Applications Configuration Guide

user@P4# set interfaces fe-2/0/10 unit 3 description P4-to-PE1

user@P4# set interfaces fe-2/0/10 unit 3 family inet address 3.3.3.2/24
user@P4# set interfaces fe-2/0/10 unit 3 family mpls
user@P4# set interfaces fe-2/0/9 unit 12 description P4-to-PE4
user@P4# set interfaces fe-2/0/9 unit 12 family inet address 4.4.4.1/24
user@P4# set interfaces fe-2/0/9 unit 12 family mpls
user@P4# set interfaces lo0 unit 3 family inet address 100.30.30.30/32

user@PE4# set interfaces ge-2/0/0 unit 0 description PE4-to-CE4

user@PE4# set interfaces ge-2/0/0 unit 0 family inet address 10.0.104.9/30
user@PE4# set interfaces fe-2/0/10 unit 4 description PE4-to-P4
user@PE4# set interfaces fe-2/0/10 unit 4 family inet address 4.4.4.2/24
user@PE4# set interfaces fe-2/0/10 unit 4 family mpls
user@PE4# set interfaces lo0 unit 4 family inet address 100.40.40.40/32

2. Enable RSVP, MPLS, and OSPF on the interfaces.

[edit]
user@P2# set protocols rsvp interface fe-2/0/10.2
user@P2# set protocols rsvp interface fe-2/0/9.10
user@P2# set protocols rsvp interface lo0.2
user@P2# set protocols mpls interface fe-2/0/10.2
user@P2# set protocols mpls interface fe-2/0/9.10
user@P2# set protocols mpls interface lo0.2
user@P2# set protocols ospf area 0.0.0.0 interface fe-2/0/10.2
user@P2# set protocols ospf area 0.0.0.0 interface fe-2/0/9.10
user@P2# set protocols ospf area 0.0.0.0 interface lo0.2

user@PE2# set protocols rsvp interface fe-2/0/10.5

user@PE2# set protocols rsvp interface lo0.5
user@PE2# set protocols mpls interface fe-2/0/10.5
user@PE2# set protocols mpls interface lo0.5
user@PE2# set protocols ospf area 0.0.0.0 interface ge-2/0/3.0
user@PE2# set protocols ospf area 0.0.0.0 interface fe-2/0/10.5
user@PE2# set protocols ospf area 0.0.0.0 interface lo0.5

user@P3# set protocols rsvp interface fe-2/0/10.6

user@P3# set protocols rsvp interface fe-2/0/9.11
user@P3# set protocols rsvp interface lo0.6
user@P3# set protocols mpls interface fe-2/0/10.6
user@P3# set protocols mpls interface fe-2/0/9.11
user@P3# set protocols mpls interface lo0.6
user@P3# set protocols ospf area 0.0.0.0 interface fe-2/0/10.6
user@P3# set protocols ospf area 0.0.0.0 interface fe-2/0/9.11
user@P3# set protocols ospf area 0.0.0.0 interface lo0.6

user@PE3# set protocols rsvp interface fe-2/0/10.7

user@PE3# set protocols rsvp interface lo0.7
user@PE3# set protocols mpls interface fe-2/0/10.7
user@PE3# set protocols mpls interface lo0.7
user@PE3# set protocols ospf area 0.0.0.0 interface ge-2/0/1.0
user@PE3# set protocols ospf area 0.0.0.0 interface fe-2/0/10.7
user@PE3# set protocols ospf area 0.0.0.0 interface lo0.7

232 Copyright © 2012, Juniper Networks, Inc.

 Chapter 8: Point-to-Multipoint LSP Configuration Guidelines

user@P4# set protocols rsvp interface fe-2/0/10.3

user@P4# set protocols rsvp interface fe-2/0/9.12
user@P4# set protocols rsvp interface lo0.3
user@P4# set protocols mpls interface fe-2/0/10.3
user@P4# set protocols mpls interface fe-2/0/9.12
user@P4# set protocols mpls interface lo0.3
user@P4# set protocols ospf area 0.0.0.0 interface fe-2/0/10.3
user@P4# set protocols ospf area 0.0.0.0 interface fe-2/0/9.12
user@P4# set protocols ospf area 0.0.0.0 interface lo0.3

user@PE4# set protocols rsvp interface fe-2/0/10.4

user@PE4# set protocols rsvp interface lo0.4
user@PE4# set protocols mpls interface fe-2/0/10.4
user@PE4# set protocols mpls interface lo0.4
user@PE4# set protocols ospf area 0.0.0.0 interface ge-2/0/0.0
user@PE4# set protocols ospf area 0.0.0.0 interface fe-2/0/10.4
user@PE4# set protocols ospf area 0.0.0.0 interface lo0.4

3. Enable traffic engineering for OSPF.

[edit]
user@P2# set protocols ospf traffic-engineering

user@P2# set protocols ospf traffic-engineering

user@P3# set protocols ospf traffic-engineering

user@PE2# set protocols ospf traffic-engineering

user@PE3# set protocols ospf traffic-engineering

user@PE4# set protocols ospf traffic-engineering

This causes the shortest-path first (SPF) algorithm to take into account the LSPs
configured under MPLS.

4. Configure the router IDs.

[edit]
user@P2# set routing-options router-id 100.20.20.20

user@P3# set routing-options router-id 100.60.60.60

user@P4# set routing-options router-id 100.30.30.30

user@PE2# set routing-options router-id 100.50.50.50

user@PE3# set routing-options router-id 100.70.70.70

user@PE4# set routing-options router-id 100.40.40.40

5. If you are done configuring the devices, commit the configuration.

[edit]

Copyright © 2012, Juniper Networks, Inc. 233

Junos OS 12.1 MPLS Applications Configuration Guide

user@host# commit

Results From configuration mode, confirm your configuration by entering the show interfaces,
show protocols, and show routing-options commands. If the output does not display the
intended configuration, repeat the instructions in this example to correct the configuration.

Device PE1 user@PE1# show interfaces

ge-2/0/2 {
unit 0 {
description R1-to-CE1;
family inet {
address 10.0.244.10/30;
}
}
}
fe-2/0/10 {
unit 1 {
description PE1-to-P2;
family inet {
address 2.2.2.1/24;
}
family mpls;
}
}
fe-2/0/9 {
unit 8 {
description PE1-to-P2;
family inet {
address 6.6.6.1/24;
}
family mpls;
}
}
fe-2/0/8 {
unit 9 {
description PE1-to-P3;
family inet {
address 3.3.3.1/24;
}
family mpls;
}
}
lo0 {
unit 1 {
family inet {
address 100.10.10.10/32;
}
}
}

user@PE1# show protocols

rsvp {
interface fe-2/0/10.1;
interface fe-2/0/9.8;
interface fe-2/0/8.9;

234 Copyright © 2012, Juniper Networks, Inc.

 Chapter 8: Point-to-Multipoint LSP Configuration Guidelines

interface lo0.1;
}
mpls {
traffic-engineering bgp-igp;
label-switched-path PE1-to-PE2 {
to 100.50.50.50;
link-protection;
p2mp p2mp1;
}
label-switched-path PE1-to-PE3 {
to 100.70.70.70;
link-protection;
p2mp p2mp1;
}
label-switched-path PE1-to-PE4 {
to 100.40.40.40;
link-protection;
p2mp p2mp1;
}
interface fe-2/0/10.1;
interface fe-2/0/9.8;
interface fe-2/0/8.9;
interface lo0.1;
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface ge-2/0/2.0;
interface fe-2/0/10.1;
interface fe-2/0/9.8;
interface fe-2/0/8.9;
interface lo0.1;
}
}

user@PE1# show routing-options

static {
route 5.5.5.0/24 {
p2mp-lsp-next-hop p2mp1;
}
route 7.7.7.0/24 {
p2mp-lsp-next-hop p2mp1;
}
route 4.4.4.0/24 {
p2mp-lsp-next-hop p2mp1;
}
}
router-id 100.10.10.10;

Device P2 user@P2# show interfaces

fe-2/0/10 {
unit 2 {
description P2-to-PE1;
family inet {
address 2.2.2.2/24;
}
family mpls;

Copyright © 2012, Juniper Networks, Inc. 235

Junos OS 12.1 MPLS Applications Configuration Guide

}
fe-2/0/9 {
unit 10 {
description P2-to-PE2;
family inet {
address 5.5.5.1/24;
}
family mpls;
}
}
lo0 {
unit 2 {
family inet {
address 100.20.20.20/32;
}
}
}

user@P2# show protocols

rsvp {
interface fe-2/0/10.2;
interface fe-2/0/9.10;
interface lo0.2;
}
mpls {
interface fe-2/0/10.2;
interface fe-2/0/9.10;
interface lo0.2;
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface fe-2/0/10.2;
interface fe-2/0/9.10;
interface lo0.2;
}
}

user@P2# show routing-options

router-id 100.20.20.20;

Device P3 user@P3# show interfaces

fe-2/0/10 {
unit 6 {
description P3-to-PE1;
family inet {
address 6.6.6.2/24;
}
family mpls;
}
}
fe-2/0/9 {
unit 11 {
description P3-to-PE3;
family inet {
address 7.7.7.1/24;

236 Copyright © 2012, Juniper Networks, Inc.

 Chapter 8: Point-to-Multipoint LSP Configuration Guidelines

}
family mpls;
}
}
lo0 {
unit 6 {
family inet {
address 100.60.60.60/32;
}
}
}

user@P3# show protocols

rsvp {
interface fe-2/0/10.6;
interface fe-2/0/9.11;
interface lo0.6;
}
mpls {
interface fe-2/0/10.6;
interface fe-2/0/9.11;
interface lo0.6;
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface fe-2/0/10.6;
interface fe-2/0/9.11;
interface lo0.6;
}
}

user@P2# show routing-options

router-id 100.60.60.60;

Device P4 user@P4# show interfaces

fe-2/0/10 {
unit 3 {
description P4-to-PE1;
family inet {
address 3.3.3.2/24;
}
family mpls;
}
}
fe-2/0/9 {
unit 12 {
description P4-to-PE4;
family inet {
address 4.4.4.1/24;
}
family mpls;
}
}
lo0 {
unit 3 {

Copyright © 2012, Juniper Networks, Inc. 237

Junos OS 12.1 MPLS Applications Configuration Guide

family inet {
address 100.30.30.30/32;
}
}
}

user@P4# show protocols

rsvp {
interface fe-2/0/10.3;
interface fe-2/0/9.12;
interface lo0.3;
}
mpls {
interface fe-2/0/10.3;
interface fe-2/0/9.12;
interface lo0.3;
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface fe-2/0/10.3;
interface fe-2/0/9.12;
interface lo0.3;
}
}

user@P3# show routing-options

router-id 100.30.30.30;

Device PE2 user@PE2# show interfaces

ge-2/0/3 {
unit 0 {
description PE2-to-CE2;
family inet {
address 10.0.224.10/30;
}
}
}
fe-2/0/10 {
unit 5 {
description PE2-to-P2;
family inet {
address 5.5.5.2/24;
}
family mpls;
}
}
lo0 {
unit 5 {
family inet {
address 100.50.50.50/32;
}
}
}
}

238 Copyright © 2012, Juniper Networks, Inc.

 Chapter 8: Point-to-Multipoint LSP Configuration Guidelines

user@PE2# show protocols

rsvp {
interface fe-2/0/10.5;
interface lo0.5;
}
mpls {
interface fe-2/0/10.5;
interface lo0.5;
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface ge-2/0/3.0;
interface fe-2/0/10.5;
interface lo0.5;
}
}

user@PE2# show routing-options

router-id 100.50.50.50;

Device PE3 user@PE3# show interfaces

ge-2/0/1 {
unit 0 {
description PE3-to-CE3;
family inet {
address 10.0.134.10/30;
}
}
}
fe-2/0/10 {
unit 7 {
description PE3-to-P3;
family inet {
address 7.7.7.2/24;
}
family mpls;
}
}
lo0 {
unit 7 {
family inet {
address 100.70.70.70/32;
}
}
}
}

user@PE3# show protocols

rsvp {
interface fe-2/0/10.7;
interface lo0.7;
}
mpls {
interface fe-2/0/10.7;
interface lo0.7;

Copyright © 2012, Juniper Networks, Inc. 239

Junos OS 12.1 MPLS Applications Configuration Guide

}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface ge-2/0/1.0;
interface fe-2/0/10.7;
interface lo0.7;
}
}

user@PE3# show routing-options

router-id 100.70.70.70;

Device PE4 user@PE4# show interfaces

ge-2/0/0 {
unit 0 {
description PE4-to-CE4;
family inet {
address 10.0.104.9/30;
}
}
}
fe-2/0/10 {
unit 4 {
description PE4-to-P4;
family inet {
address 4.4.4.2/24;
}
family mpls;
}
}
lo0 {
unit 4 {
family inet {
address 100.40.40.40/32;
}
}
}
}

user@PE4# show protocols

rsvp {
interface fe-2/0/10.4;
interface lo0.4;
}
mpls {
interface fe-2/0/10.4;
interface lo0.4;
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface ge-2/0/0.0;
interface fe-2/0/10.4;
interface lo0.4;
}

240 Copyright © 2012, Juniper Networks, Inc.

 Chapter 8: Point-to-Multipoint LSP Configuration Guidelines

user@PE4# show routing-options

router-id 100.40.40.40;

Configuring Device CE1

Step-by-Step To configure Device CE1:

Procedure
1. Configure an interface to Device PE1.

[edit interfaces]
user@CE1# set ge-1/3/2 unit 0 family inet address 10.0.244.9/30
user@CE1# set ge-1/3/2 unit 0 description CE1-to-PE1

2. Configure static routes from Device CE1 to the three other customer networks, with
Device PE1 as the next hop.

[edit routing-options]
user@CE1# set static route 10.0.104.8/30 next-hop 10.0.244.10
user@CE1# set static route 10.0.134.8/30 next-hop 10.0.244.10
user@CE1# set static route 10.0.224.8/30 next-hop 10.0.244.10

3. If you are done configuring the device, commit the configuration.

[edit]
user@CE1# commit

Results From configuration mode, confirm your configuration by entering the show interfaces and
show routing-options commands. If the output does not display the intended configuration,
repeat the instructions in this example to correct the configuration.

user@CE1# show interfaces

ge-1/3/2 {
unit 0 {
family inet {
address 10.0.244.9/30;
description CE1-to-PE1;
}
}
}

user@CE1# show routing-options

static {
route 10.0.104.8/30 next-hop 10.0.244.10;
route 10.0.134.8/30 next-hop 10.0.244.10;
route 10.0.224.8/30 next-hop 10.0.244.10;
}

Configuring Device CE2

Step-by-Step To configure Device CE2:

Procedure
1. Configure an interface to Device PE2.

[edit interfaces]
user@CE2# set ge-1/3/3 unit 0 family inet address 10.0.224.9/30

Copyright © 2012, Juniper Networks, Inc. 241

Junos OS 12.1 MPLS Applications Configuration Guide

user@CE2# set ge-1/3/3 unit 0 description CE2-to-PE2

2. Configure a static route from Device CE2 to CE1, with Device PE2 as the next hop.

[edit routing-options]
user@CE2# set static route 10.0.244.8/30 next-hop 10.0.224.10

3. If you are done configuring the device, commit the configuration.

[edit]
user@CE2# commit

Results From configuration mode, confirm your configuration by entering the show interfaces and
show routing-options commands. If the output does not display the intended configuration,
repeat the instructions in this example to correct the configuration.

user@CE2# show interfaces

ge-1/3/3 {
unit 0 {
family inet {
address 10.0.224.9/30;
description CE2-to-PE2;
}
}
}

user@CE2# show routing-options

static {
route 10.0.244.8/30 next-hop 10.0.224.10;
}

Configuring Device CE3

Step-by-Step To configure Device CE3:

Procedure
1. Configure an interface to Device PE3.

[edit interfaces]
user@CE3# set ge-2/0/1 unit 0 family inet address 10.0.134.9/30
user@CE3# set ge-2/0/1 unit 0 description CE3-to-PE3

2. Configure a static route from Device CE3 to CE1, with Device PE3 as the next hop.

[edit routing-options]
user@CE3# set static route 10.0.244.8/30 next-hop 10.0.134.10

3. If you are done configuring the device, commit the configuration.

[edit]
user@CE3# commit

Results From configuration mode, confirm your configuration by entering the show interfaces and
show routing-options commands. If the output does not display the intended configuration,
repeat the instructions in this example to correct the configuration.

user@CE3# show interfaces

ge-2/0/1 {

242 Copyright © 2012, Juniper Networks, Inc.

 Chapter 8: Point-to-Multipoint LSP Configuration Guidelines

unit 0 {
family inet {
address 10.0.134.9/30;
description CE3-to-PE3;
}
}
}

user@CE3# show routing-options

static {
route 10.0.244.8/30 next-hop 10.0.134.10;
}

Configuring Device CE4

Step-by-Step To configure Device CE4:

Procedure
1. Configure an interface to Device PE4.

[edit interfaces]
user@CE4# set ge-3/1/3 unit 0 family inet address 10.0.104.10/30
user@CE4# set ge-3/1/3 unit 0 description CE4-to-PE4

2. Configure a static route from Device CE4 to CE1, with Device PE4 as the next hop.

[edit routing-options]
user@CE4# set static route 10.0.244.8/30 next-hop 10.0.104.9

3. If you are done configuring the device, commit the configuration.

[edit]
user@CE4# commit

Results From configuration mode, confirm your configuration by entering the show interfaces and
show routing-options commands. If the output does not display the intended configuration,
repeat the instructions in this example to correct the configuration.

user@CE4# show interfaces

ge-3/1/3 {
unit 0 {
family inet {
address 10.0.104.10/30;
description CE4-to-PE4;
}
}
}

user@CE4# show routing-options

static {
route 10.0.244.8/30 next-hop 10.0.104.9;
}

Copyright © 2012, Juniper Networks, Inc. 243

Junos OS 12.1 MPLS Applications Configuration Guide

Verification
Confirm that the configuration is working properly.

• Verifying Connectivity on page 244

• Verifying the State of the Point-to-Multipoint LSP on page 244
• Checking the Forwarding Table on page 245

Verifying Connectivity

Purpose Make sure that the devices can ping each other.

Action Run the ping command from CE1 to the interface on CE2 connecting to PE2.

user@CE1> ping 10.0.224.9

PING 10.0.224.9 (10.0.224.9): 56 data bytes
64 bytes from 10.0.224.9: icmp_seq=0 ttl=61 time=1.387 ms
64 bytes from 10.0.224.9: icmp_seq=1 ttl=61 time=1.394 ms
64 bytes from 10.0.224.9: icmp_seq=2 ttl=61 time=1.506 ms
^C
--- 10.0.224.9 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.387/1.429/1.506/0.055 ms

Run the ping command from CE1 to the interface on CE3 connecting to PE3.

user@CE1> ping 10.0.134.9

PING 10.0.134.9 (10.0.134.9): 56 data bytes
64 bytes from 10.0.134.9: icmp_seq=0 ttl=61 time=1.068 ms
64 bytes from 10.0.134.9: icmp_seq=1 ttl=61 time=1.062 ms
64 bytes from 10.0.134.9: icmp_seq=2 ttl=61 time=1.053 ms
^C
--- 10.0.134.9 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.053/1.061/1.068/0.006 ms

Run the ping command from CE1 to the interface on CE4 connecting to PE4.

user@CE1> ping 10.0.104.10

PING 10.0.104.10 (10.0.104.10): 56 data bytes
64 bytes from 10.0.104.10: icmp_seq=0 ttl=61 time=1.079 ms
64 bytes from 10.0.104.10: icmp_seq=1 ttl=61 time=1.048 ms
64 bytes from 10.0.104.10: icmp_seq=2 ttl=61 time=1.070 ms
^C
--- 10.0.104.10 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.048/1.066/1.079/0.013 ms

Verifying the State of the Point-to-Multipoint LSP

Purpose Make sure that the ingress, transit, and egress LSRs are in the Up state.

Action Run the show mpls lsp p2mp command on all of the LSRs. Only the ingress LSR is shown
here.

244 Copyright © 2012, Juniper Networks, Inc.

 Chapter 8: Point-to-Multipoint LSP Configuration Guidelines

user@PE1> show mpls lsp p2mp

Ingress LSP: 1 sessions
P2MP name: p2mp1, P2MP branch count: 3
To From State Rt P ActivePath LSPname
100.40.40.40 100.10.10.10 Up 0 * PE1-PE4
100.70.70.70 100.10.10.10 Up 0 * PE1-PE3
100.50.50.50 100.10.10.10 Up 0 * PE1-PE2
Total 3 displayed, Up 3, Down 0
...

Checking the Forwarding Table

Purpose Make sure that the routes are set up as expected by running the show route
forwarding-table command. Only the routes to the remote customer networks are shown
here.

Action user@PE1> show route forwarding-table

Routing table: default.inet
Internet:
Destination Type RtRef Next hop Type Index NhRef Netif
...
10.0.104.8/30 user 0 3.3.3.2 ucst 1006 6 fe-2/0/8.9
10.0.134.8/30 user 0 6.6.6.2 ucst 1010 6 fe-2/0/9.8
10.0.224.8/30 user 0 2.2.2.2 ucst 1008 6 fe-2/0/10.1
...

Related • Point-to-Multipoint LSPs Overview on page 52 in the Junos OS MPLS Applications

Documentation Configuration Guide

Configuring Inter-domain P2MP LSPs

An inter-domain P2MP LSP is a P2MP LSP that has one or more sub-LSPs (branches)
that span multiple domains in a network. Examples of such domains include IGP areas
and autonomous systems (ASs). A sub-LSP of an inter-domain P2MP LSP may be
intra-area, inter-area, or inter-AS, depending on the location of the egress node (leaf)
with respect to the ingress node (source).

On the ingress node, a name is assigned to the inter-domain P2MP LSP and shared by
all constituent sub-LSPs. Each sub-LSP is configured separately, with its own egress
node and optionally an explicit path. The location of the egress node of the sub-LSP with
respect to the ingress node determines whether the sub-LSP is intra-area, inter-area, or
inter-AS.

Inter-domain P2MP LSPs can be used to transport traffic in the following applications
in a multi-area or multi-AS network:

• Layer 2 broadcast and multicast over MPLS

• Layer 3 BGP/MPLS VPN

• VPLS

Copyright © 2012, Juniper Networks, Inc. 245

Junos OS 12.1 MPLS Applications Configuration Guide

On each domain boundary node (ABR or ASBR) along the path of the P2MP LSP, the
expand-loose-hop statement must be configured at the [edit protocols mpls] hierarchy
level so that CSPF can extend a loose-hop ERO (usually the first entry of the ERO list
carried by RSVP Path message) towards the egress node or the next domain boundary
node.

CSPF path computation for inter-domain P2MP LSPs:

• CSPF path computation is supported on each sub-LSP for inter-domain P2MP LSPs.
A sub-LSP may be intra-area, inter-area, or inter-AS. CSPF treats an inter-area or
inter-AS sub-LSP in the same manner as an inter-domain P2P LSP.

• On an ingress node or a domain boundary node (ABR or ASBR), CSPF can perform an
Explicit Route Object (ERO) expansion per-RSVP query. The destination queried could
be an egress node or a received loose-hop ERO. If the destination resides in a
neighboring domain that the node is connected to, CSPF generates either a sequence
of strict-hop EROs towards it or a sequence of strict-hop EROs towards another domain
boundary node that can reach the destination.

• If RSVP fails to signal a path through a previously selected domain bounday node,
RSVP attempts to signal a path through other available domain boundary nodes in a
round-robin fashion.

• When a sub-LSP is added or removed to or from an inter-domain P2MP LSP, causing

its path (branch) to be merged or pruned with or from the current P2MP tree, the paths
being taken by the other sub-LSPs should not be affected, helping to prevent traffic
disruption on those sub-LSPs.

Be aware of the following when deploying inter-domain P2MP LSPs in your network:

• Periodic path re-optimization is supported for inter-domain P2MP LSPs on ingress

nodes. It can be turned on for an inter-domain P2MP LSP by configuring the
optimize-timer statement at the [edit protocols mpls label-switched-path lsp-name]
hierarchy level with the same interval for every sub-LSP.

• Only link protection bypass LSPs are supported for inter-domain P2MP LSPs. To enable
it for an inter-domain P2MP LSP, link-protection must be configured for all sub-LSPs
and on all of the RSVP interfaces that the P2MP LSP might travel through.

• Only OSPF areas are supported for inter-domain P2MP LSPs. IS-IS levels are not
supported.

246 Copyright © 2012, Juniper Networks, Inc.

CHAPTER 9

Miscellaneous MPLS Properties

Configuration Guidelines

This chapter discusses the following topics:

• Configuring the Maximum Number of MPLS Labels on page 247

• Configuring MPLS to Pop the Label on the Ultimate-Hop Router on page 249
• Advertising Explicit Null Labels to BGP Peers on page 249
• Configuring Traffic Engineering for LSPs on page 250
• Enabling Interarea Traffic Engineering on page 253
• Enabling Inter-AS Traffic Engineering for LSPs on page 254
• Configuring MPLS to Gather Statistics on page 256
• Configuring System Log Messages and SNMP Traps for LSPs on page 257
• Configuring MPLS Firewall Filters and Policers on page 258
• Configuring MPLS Rewrite Rules on page 266
• Configuring BFD for MPLS IPv4 LSPs on page 267
• Pinging LSPs on page 270
• Tracing MPLS and LSP Packets and Operations on page 271

Configuring the Maximum Number of MPLS Labels

For interfaces that you configure for MPLS applications, you can set the maximum number
of labels upon which MPLS can operate.

By default, the maximum number of labels is three. You can change the maximum to
four labels or five labels for applications that require four or five labels. For example,
suppose you configure a two-tier carrier-of-carriers VPN service for customers who
provide VPN service. A carrier-of-carrier VPN is a two-tiered relationship between a
provider carrier (Tier 1 ISP) and a customer carrier (Tier 2 ISP). In a carrier-of-carrier VPN,
the provider carrier provides a VPN backbone network for the customer carrier. The
customer carrier in turn provides Layer 3 VPN service to its end customers. The customer
carrier sends labeled traffic to the provider carrier to deliver it to the next hop on the other
side of the provider carrier’s network. This scenario requires a three-label stack: one label

Copyright © 2012, Juniper Networks, Inc. 247

Junos OS 12.1 MPLS Applications Configuration Guide

for the provider carrier VPN, another label for the customer carrier VPN, and a third label
for the transport route.

If you add fast reroute service, the PE routers in the provider carrier’s network must be
configured to support a fourth label (the reroute label). If the customer carrier is using
LDP as its signaling protocol and the provider carrier is using RSVP, the provider carrier
must support LDP over RSVP tunnel service. This additional service requires an additional
label, for a total of five labels.

To the customer carrier, the router it uses to connect to the provider carrier’s VPN is a PE
router. However, the provider carrier views this device as a CE router.

Table 6 on page 248 summarizes the label requirements.

Table 6: Sample Scenarios for Using 3, 4, or 5 MPLS Labels

Number of Labels Required Scenarios

3 Carrier-of-carriers VPN or a VPN with two labels and fast reroute

4 Combination of carrier-of-carriers and fast reroute

5 Carrier-of-carriers with fast reroute and the customer carrier running LDP, with
the provider carrier running RSVP

The system reserves label space when you configure the maximum number of labels on
the interface. When you configure features that require MPLS labels, the label push is
automatic. You do not need to explicitly push the labels. The transport route can be a
static, LDP-signaled, or RSVP-signaled LSP.

This feature is supported on the following routers:

• MX Series 3D Universal Edge Router

• M120 Multiservice Edge Router

• M320 Multiservice Edge Router with Enhanced III FPCs

• M7i Multiservice Edge Router and M10i Multiservice Edge Router with Enhanced
Compact Forwarding Engine Board (CFEB-E)

• T640, T1600, TX Matrix, and TX Matrix Plus routers with Enhanced Scaling FPC1,
Enhanced Scaling FP2, Enhanced Scaling FPC3, and Enhanced Scaling FPC4.

To configure and monitor the maximum number of labels:

1. Specify the maximum on the logical interface. Apply this configuration to the carrier’s
PE routers.
[edit interfaces ge-0/1/3 unit 0 family mpls]
user@switch# set maximum-labels 5

2. Verify the configuration.

[edit system]
user@switch# show interfaces ge-0/1/3.0

248 Copyright © 2012, Juniper Networks, Inc.

 Chapter 9: Miscellaneous MPLS Properties Configuration Guidelines

Logical interface ge-0/1/3.0 (Index 77) (SNMP ifIndex 507)

Flags: SNMP-Traps Encapsulation: ENET2
Input packets : 0
Output packets: 0
Protocol mpls, MTU: 1480, Maximum labels: 5
Flags: Is-Primary

The command output includes the Maximum labels: 5 field under the logical interface
unit 0.

Related • Fast Reroute Overview on page 47

Documentation
• Tunneling LDP LSPs in RSVP LSPs Overview on page 465

• Junos VPNs Configuration Guide for a carrier-of-carriers configuration example

Configuring MPLS to Pop the Label on the Ultimate-Hop Router

You can control the label value advertised on the egress router of a label-switched path
(LSP). The default advertised label is label 3 (Implicit Null Label). If label 3 is advertised,
the penultimate-hop router removes the label and sends the packet to the egress router.
By enabling ultimate-hop popping, label 0 (IPv4 Explicit Null Label) is advertised.
Ultimate-hop popping ensures that any packets traversing an MPLS network include a
label.

To configure MPLS to pop the label on the ultimate-hop router, include the explicit-null
statement:

explicit-null;

You can configure this statement at the following hierarchy levels:

• [edit protocols mpls]

• [edit logical-systems logical-system-name protocols mpls]

NOTE: Juniper Networks routers queue packets based on the incoming

label. Routers from other vendors might queue packets differently. Keep
this in mind when working with networks containing routers from multiple
vendors.

For more information about labels, see “Label Description” on page 27 and “Label
Allocation” on page 28.

Advertising Explicit Null Labels to BGP Peers

For the IPv4 (inet) family only, BGP peers in a routing group can send an explicit NULL
label for a set of connected routes (direct and loopback routes) for the inet
labeled-unicast and inet6 labeled-unicast NLRI. By default, peers advertise label 3
(implicit NULL). If the explicit-null statement is enabled, peers advertise label 0 (explicit
NULL). The explicit NULL labels ensures that labels are always present on packets

Copyright © 2012, Juniper Networks, Inc. 249

Junos OS 12.1 MPLS Applications Configuration Guide

traversing an MPLS network. If the implicit NULL label is used. the penultimate hop router
removes the label and sends the packet as a plain IP packet to the egress router. This
might cause issues in queuing the packet properly on the penultimate hop router if the
penultimate hop is another vendor’s router. Some other vendors queue packets based
on the CoS bits in the outgoing label rather than the incoming label.

To advertise an explicit null label, include the following statements in the configuration:

family inet {
labeled-unicast {
aggregate-label {
community community-name:
}
explicit-null {
connected-only;
}
}
}

For a list of hierarchy levels at which you can include this statement, see the statement
summary section for this statement.

The connected-only statement is required to advertise explicit null labels.

To verify that the explicit NULL label is being advertised for connected routes, use the
show route advertising-protocol bgp neighbor-address command.

Related • Configuring MPLS and LDP to Pop the Label on the Ultimate-Hop Router on page 496
Documentation
• Configuring RSVP to Pop the Label on the Ultimate-Hop Router on page 419

Configuring Traffic Engineering for LSPs

When you configure an LSP, a host route (a 32-bit mask) is installed in the ingress router
toward the egress router; the address of the host route is the destination address of the
LSP. The bgp option for the traffic engineering statement at the [edit protocols mpls]
hierarchy level is enabled by default (you can also explicitly configure the bgp option),
allowing only BGP to use LSPs in its route calculations. The other traffic-engineering
statement options allow you to alter this behavior in the master routing instance. This
functionality is not available for specific routing instances. Also, you can enable only one
of the traffic-engineering statement options (bgp, bgp-igp, bgp-igp-both-ribs, or
mpls-forwarding) at a time.

NOTE: Enabling or disabling any of the traffic-engineering statement options

causes all the MPLS routes to be removed and then reinserted into the routing
tables.

You can configure OSPF and traffic engineering to advertise the LSP metric in summary
link-state advertisements (LSAs) as described in the section “Advertising the LSP Metric
in Summary LSAs” on page 252.

250 Copyright © 2012, Juniper Networks, Inc.

 Chapter 9: Miscellaneous MPLS Properties Configuration Guidelines

The following sections describe how to configure traffic engineering for LSPs:

• Using LSPs for Both BGP and IGP Traffic Forwarding on page 251
• Using LSPs for Forwarding in Virtual Private Networks on page 251
• Using RSVP and LDP Routes for Forwarding but Not Route Selection on page 252
• Advertising the LSP Metric in Summary LSAs on page 252

Using LSPs for Both BGP and IGP Traffic Forwarding

You can configure BGP and the IGPs to use LSPs for forwarding traffic destined for egress
routers by including the bgp-igp option for the traffic-engineering statement. The bgp-igp
option causes all inet.3 routes to be moved to the inet.0 routing table.

On the ingress router, include bgp-igp option for the traffic-engineering statement:

traffic-engineering bgp-igp;

You can include this statement at the following hierarchy levels:

• [edit protocols mpls]

• [edit logical-systems logical-system-name protocols mpls]

NOTE: The bgp-igp option for the traffic-engineering statement cannot be

configured for VPN). VPNs require that routes be in the inet.3 routing table.

Using LSPs for Forwarding in Virtual Private Networks

VPNs require that routes remain in the inet.3 routing table to function properly. For VPNs,
configure the bgp-igp-both-ribs option of the traffic-engineering statement to cause BGP
and the IGPs to use LSPs for forwarding traffic destined for egress routers. The
bgp-igp-both-ribs option installs the ingress routes in both the inet.0 routing table (for
IPv4 unicast routes) and the inet.3 routing table (for MPLS path information).

On the ingress router, include the traffic-engineering bgp-igp-both-ribs statement:

traffic-engineering bgp-igp-both-ribs;

You can include this statement at the following hierarchy levels:

• [edit protocols mpls]

• [edit logical-systems logical-system-name protocols mpls]

When you use the bgp-igp-both-ribs statement, the routes from the inet.3 table get copied
into the inet.0 table. The copied routes are LDP-signaled or RSVP-signaled, and are likely
to have a lower preference than other routes in inet.0. Routes with a lower preference
are more likely to be chosen as the active routes. This can be a problem because routing
policies only act upon active routes. To prevent this problem, use the mpls-forwarding
option instead.

Copyright © 2012, Juniper Networks, Inc. 251

Junos OS 12.1 MPLS Applications Configuration Guide

Using RSVP and LDP Routes for Forwarding but Not Route Selection
If you configure the bgp-igp or bgpp-igp-both-ribs options for the traffic-engineering
statement, high-priority LSPs can supersede IGP routes in the inet.0 routing table. IGP
routes might no longer be redistributed since they are no longer the active routes.

If you configure the mpls-forwarding option for the traffic-engineering statement, LSPs
are used for forwarding but are excluded from route selection. These routes are added
to both the inet.0 and inet.3 routing tables. LSPs in the inet.0 routing table are given a
low preference when the active route is selected. However, LSPs in the inet.3 routing
table are given a normal preference and are therefore used for selecting forwarding next
hops.

When you activate the mpls-forwarding option, routes whose state is ForwardingOnly
are preferred for forwarding even if their preference is lower than that of the currently
active route. To examine the state of a route, execute a show route detail command.

To use LSPs for forwarding but exclude them from route selection, include the
mpls-forwarding option for the traffic-engineering statement:

traffic-engineering mpls-forwarding;

You can include this statement at the following hierarchy levels:

• [edit protocols mpls]

• [edit logical-systems logical-system-name protocols mpls]

When you configure the mpls-forwarding option, IGP shortcut routes are copied to the
inet.0 routing table only.

Unlike the bgp-igp-both-ribs option, the mpls-forwarding option allows you to use the
LDP-signaled and RSVP-signaled routes for forwarding, and keep the BGP and IGP routes
active for routing purposes so that routing policies can act upon them.

For example, suppose a router is running BGP and it has a BGP route of 10.10.10.1/32 that
it needs to send to another BGP speaker. If you use the bgp-igp-both-ribs option, and
your router also has a label-switched-path (LSP) to 10.10.10.1, the MPLS route for 10.10.10.1
becomes active in the inet.0 routing table. This prevents your router from advertising the
10.10.10.1 route to the other BGP router. On the other hand, if you use the mpls-forwarding
option instead of the bgp-igp-both-ribs option, the 10.10.10.1/32 BGP route is advertised
to the other BGP speaker, and the LSP is still used to forward traffic to the 10.10.10.1
destination.

Advertising the LSP Metric in Summary LSAs

You can configure MPLS and OSPF to treat an LSP as a link. This configuration allows
other routers in the network to use this LSP. To accomplish this goal, you need to configure
MPLS and OSPF traffic engineering to advertise the LSP metric in summary LSAs.

For MPLS, include the traffic-engineering bgp-igp and label-switched-path statements:

traffic-engineering bgp-igp;

252 Copyright © 2012, Juniper Networks, Inc.

 Chapter 9: Miscellaneous MPLS Properties Configuration Guidelines

label-switched-path lsp-name {
to address;
}

You can include these statements at the following hierarchy levels:

• [edit protocols mpls]

• [edit logical-systems logical-system-name protocols mpls]

For OSPF, include the lsp-metric-into-summary statement:

lsp-metric-into-summary;

You can include this statement at the following hierarchy levels:

• [edit protocols ospf traffic-engineering shortcuts]

• [edit logical-systems logical-system-name protocols ospf traffic-engineering shortcuts]

For more information about OSPF traffic engineering, see the Junos OS Routing Protocols
Configuration Guide.

Enabling Interarea Traffic Engineering

The Junos OS can signal a contiguous traffic-engineered LSP across multiple OSPF areas.
The LSP signaling must be done using either nesting or contiguous signaling, as described
in RFC 4206, Label-Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label
Switching (GMPLS) Traffic Engineering (TE). However, contiguous signaling support is
limited to just basic signaling. Reoptimization is not supported with contiguous signaling.

The following describes some of the interarea traffic engineering features:

• Interarea traffic engineering can be enabled when the loose-hop area border routers
(ABRs) are configured on the ingress router using CSPF for the Explicit Route Object
(ERO) calculation within an OSPF area. ERO expansion is completed on the ABRs.

• Interarea traffic engineering can be enabled when CSPF is enabled, but without ABRs
specified in the LSP configuration on the ingress router (ABRs can be automatically
designated).

• Differentiated Services (DiffServ) traffic engineering is supported as long as the class

type mappings are uniform across multiple areas.

To enable interarea traffic engineering, include the expand-loose-hop statement in the

configuration for each LSP transit router:

expand-loose-hop;

You can include this statement at the following hierarchy levels:

• [edit protocols mpls]

• [edit logical-systems logical-system-name protocols mpls]

Copyright © 2012, Juniper Networks, Inc. 253

Junos OS 12.1 MPLS Applications Configuration Guide

Enabling Inter-AS Traffic Engineering for LSPs

Generally, traffic engineering is possible for LSPs that meet the following conditions:

• Both ends of the LSP are in the same OSPF area or at the same IS-IS level.

• The two ends of the LSP are in different OSPF areas within the same autonomous
system (AS). LSPs that end in different IS-IS levels are not supported.

• The two ends of an explicit-path LSP are in different OSPF ASs and the autonomous
system border routers (ASBRs) are configured statically as the loose hops supported
on the explicit-path LSP. For more information, see “Configuring Explicit-Path LSPs”
on page 218.

Without statically defined ASBRs on LSPs, traffic engineering is not possible between
one routing domain, or AS, and another. However, when the ASs are under the control
of single service provider, it is possible in some cases to have traffic engineered LSPs
span the ASs and dynamically discover the OSPF ASBRs linking them (IS-IS is not
supported with this feature).

Inter-AS traffic engineered LSPs are possible as long as certain network requirements
are met, none of the limiting conditions apply, and OSPF passive mode is configured with
EBGP. Details are provided in the following sections:

• Inter-AS Traffic Engineering Requirements on page 254

• Inter-AS Traffic Engineering Limitations on page 255
• Configuring OSPF Passive TE Mode on page 255

Inter-AS Traffic Engineering Requirements

The proper establishment and functioning of inter-AS traffic engineered LSPs depend
on the following network requirements, all of which must be met:

• All ASs are under control of a single service provider.

• OSPF is used as the routing protocol within each AS, and EBGP is used as the routing
protocol between the ASs.

• ASBR information is available inside each AS.

• EBGP routing information is distributed by OSPF, and an IBGP full mesh is in place
within each AS.

• Transit LSPs are not configured on the inter-AS links, but are configured between entry
and exit point ASBRs on each AS.

• The EBGP link between ASBRs in different ASs is a direct link and must be configured
as a passive traffic engineering link under OSPF. The remote link address itself, not the
loopback or any other link address, is used as the remote node identifier for this passive
link. For more information about OSPF passive traffic engineering mode configuration,
see “Configuring OSPF Passive TE Mode” on page 255.

254 Copyright © 2012, Juniper Networks, Inc.

 Chapter 9: Miscellaneous MPLS Properties Configuration Guidelines

In addition, the address used for the remote node of the OSPF passive traffic engineering
link must be the same as the address used for the EBGP link. For more information about
OSPF and BGP in general, see the Junos OS Routing Protocols Configuration Guide.

Inter-AS Traffic Engineering Limitations

Only LSP hierarchical, or nested, signaling is supported for inter-AS traffic engineered
LSPs. Only point-to-point LSPs are supported (there is no point-to-multipoint support).

In addition, the following limitations apply. Any one of these conditions is sufficient to
render inter-AS traffic engineered LSPs impossible, even if the above requirements are
met.

• The use of multihop BGP is not supported.

• The use of policers or topologies that prevent BGP routes from being known inside the
AS is not supported.

• Multiple ASBRs on a LAN between EBGP peers are not supported. Only one ASBR on
a LAN between EBGP peers is supported (others ASBRs can exist on the LAN, but
cannot be advertised).

• Route reflectors or policies that hide ASBR information or prevent ASBR information
from being distributed inside the ASs are not supported.

• Bidirectional LSPs are not supported (LSPs are unidirectional from the traffic
engineering perspective).

• Topologies with both inter-AS and intra-AS paths to the same destination are not
supported.

In addition, several features that are routine with all LSPs are not supported with inter-AS
traffic engineering:

• Admin group link colors are not supported.

• Secondary standby is not supported.

• Reoptimization is not supported.

• Crankback on transit routers is not supported.

• Diverse path calculation is not supported.

• Graceful restart is not supported.

These lists of limitations or unsupported features with inter-AS traffic engineered LSPs
are not exhaustive.

Configuring OSPF Passive TE Mode

Ordinarily, interior routing protocols such as OSPF are not run on links between ASs.
However, for inter-AS traffic engineering to function properly, information about the
inter-AS link, in particular, the address on the remote interface, must be made available
inside the AS. This information is not normally included either in EBGP reachability
messages or in OSPF routing advertisements.

Copyright © 2012, Juniper Networks, Inc. 255

Junos OS 12.1 MPLS Applications Configuration Guide

To flood this link address information within the AS and make it available for traffic
engineering calculations, you must configure OSPF passive mode for traffic engineering
on each inter-AS interface. You must also supply the remote address for OSPF to
distribute and include in the traffic engineering database.

To configure OSPF passive mode for traffic engineering on an inter-AS interface, include
the passive statement for the link at the [edit protocols ospf area area-id interface
interface-name] hierarchy level:

passive {
traffic-engineering {
remote-node-id ip-address; /* IP address at far end of inter-AS link */
}
}

OSPF must be properly configured on the router. The following example configures the
inter-AS link so-1/1/0 to distribute traffic engineering information with OSPF within the
AS. The remote IP address is 192.168.207.2.

[edit protocols ospf area 0.0.0.0]

interface so-1/1/0 {
unit 0 {
passive {
traffic-engineering {
remote-node-id 192.168.207.2;
}
}
}
}

Configuring MPLS to Gather Statistics

You can configure MPLS so that it periodically gathers traffic statistics about all MPLS
sessions, including transit sessions, by configuring the statistics statement. You must
configure the statistics statement if you want to collect MPLS traffic statistics using
SNMP polling of MPLS Management Information Bases (MIBs).

To enable MPLS statistics collection, include the statistics statement:

statistics {
auto-bandwidth;
file filename <files number> <size size> <world-readable | no-world-readable>;
interval seconds;
}

You can configure these statements at the following hierarchy levels:

• [edit protocols mpls]

• [edit logical-systems logical-system-name protocols mpls]

The default interval is 300 seconds.

If you configure the file option, the statistics are placed in a file, with one entry per LSP.
During the specified interval, the following information is recorded in this file:

256 Copyright © 2012, Juniper Networks, Inc.

 Chapter 9: Miscellaneous MPLS Properties Configuration Guidelines

• The number of packets, number of bytes, packets per second, and bytes per second
transmitted by each LSP. Feature parity for the display of packet and byte statistics
for sub-LSPs of a point-to-multipoint LSP on the Junos Trio chipset is supported in
Junos OS Releases 11.1R2, 11.2R2, and 11.4.

• The percent of bandwidth transmitted over a given LSP in relation to the bandwidth
percentage configured for that LSP. If no bandwidth is configured for an LSP, 0 percent
is recorded in the percentage column.

At the end of each periodic report, a summary shows the current time, total number of
sessions, number of sessions read, number of sessions ignored, and read errors, if any.
Ignored sessions are typically those not in the up state or those with a reserved
(0 through 15) incoming label (typically the egress point of an LSP). The reason for a
read error appears on the same line as the entry for the LSP on which the error occurred.
Gathering statistics is an unreliable process; occasional read errors might affect their
accuracy. Sample output follows:
lsp6 0 pkt 0 Byte 0 pps 0 Bps 0
lsp5 0 pkt 0 Byte 0 pps 0 Bps 0
lsp6.1 34845 pkt 2926980 Byte 1049 pps 88179 Bps 132
lsp5.1 0 pkt 0 Byte 0 pps 0 Bps 0
lsp4 0 pkt 0 Byte 0 pps 0 Bps 0
Dec 7 17:28:38 Total 6 sessions: 5 success, 0 fail, 1 ignored

Configuring System Log Messages and SNMP Traps for LSPs

Whenever an LSP makes a transition from up to down, or down to up, and whenever an
LSP switches from one active path to another, the ingress router generates a system log
message and sends an SNMP trap. The following shows a sample system log message:
MPLS lsp sheep1 up on primary(any) Route 192.168.1.1 192.168.1.2 192.168.1.3
MPLS lsp sheep1 change on primary(any) Route 192.168.1.1 192.168.1.2 192.168.1.3
MPLS lsp sheep1 down on primary(any)
MPLS lsp sheep1 up on secondary(any) Route 192.168.1.1 192.168.1.2 192.168.1.3
MPLS lsp sheep1 change on secondary(any) to primary(any), Route 192.168.1.1
192.168.1.2 192.168.1.3

For information about the MPLS SNMP traps and the proprietary MPLS MIBs, see the
Junos OS Network Management Configuration Guide.

To generate system log messages for LSPs, include the syslog option to the log-updown
statement:

log-updown {
syslog;
}

To generate SNMP traps for LSPs, include the trap option to the log-updown statement:

log-updown {
trap;
}

To generate SNMP traps whenever an LSP path goes down, include the trap-path-down
option to the log-updown statement:

Copyright © 2012, Juniper Networks, Inc. 257

Junos OS 12.1 MPLS Applications Configuration Guide

log-updown {
trap-path-down;
}

To generate SNMP traps whenever an LSP path comes up, include the trap-path-up
option to the log-updown statement:

log-updown {
trap-path-up;
}

To disable the generation of system log messages, include the no-syslog option to the
log-updown statement:

log-updown {
no-syslog;
}

To disable the generation of SNMP traps, include the no-trap statement:

no-trap {
mpls-lsp-traps;
rfc3812-traps;
}

You can include this statement at the following hierarchy levels:

• [edit protocols mpls log-updown]

• [edit logical-systems logical-system-name protocols mpls log-updown]

For scalability reasons, only the ingress router generates SNMP traps. By default, MPLS
issues traps for all configured LSPs. If you have many LSPs, the number of traps can
become quite large. To disable the generation of SNMP traps, configure the no-trap
statement.

The no-trap statement also includes the following options which allow you to block
certain categories of MPLS SNMP traps:

• mpls-lsp-traps—Blocks the MPLS LSP traps defined in the jnx-mpls.mib, but allows
the rfc3812.mib traps.

• rfc-3812-traps—Blocks the traps defined in the rfc3812.mib, but allows the MPLS LSP
traps defined in the jnx-mpls.mib.

Configuring MPLS Firewall Filters and Policers

You can configure an MPLS firewall filter to count packets based on the EXP bits for the
top-level MPLS label in a packet. You can also configure policers for MPLS LSPs.

The following sections discuss MPLS firewall filters and policers:

• Configuring MPLS Firewall Filters on page 259

• Examples: Configuring MPLS Firewall Filters on page 260
• Configuring Policers for LSPs on page 260

258 Copyright © 2012, Juniper Networks, Inc.

 Chapter 9: Miscellaneous MPLS Properties Configuration Guidelines

• Example: Configuring an LSP Policer on page 262

• Configuring Automatic Policers on page 262
• Writing Different DSCP and EXP Values in MPLS-Tagged IP Packets on page 266

Configuring MPLS Firewall Filters

You can configure an MPLS firewall filter to count packets based on the EXP bits for the
top-level MPLS label in a packet. You can then apply this filter to a specific interface.
You can also configure a policer for the MPLS filter to police (that is, rate-limit) the traffic
on the interface to which the filter is attached. You cannot apply MPLS firewall filters to
Ethernet (fxp0) or loopback (lo0) interfaces.

You can configure an MPLS firewall filter on the M Series Multiservice Edge Routers and
the T Series Core Routers.

You can configure the following match criteria attributes for MPLS filters at the [edit
firewall family mpls filter filter-name term term-name from] hierarchy level:

• exp

• exp-except

These attributes can accept EXP bits in the range 0 through 7. You can configure the
following choices:

• A single EXP bit—for example, exp 3;

• Several EXP bits—for example, exp 0, 4;

• A range of EXP bits—for example, exp [0-5];

If you do not specify a match criterion (that is, you do not configure the from statement
and use only the then statement with the count action keyword), all the MPLS packets
passing through the interface on which the filter is applied will be counted.

You also can configure any of the following action keywords at the [edit firewall family
mpls filter filter-name term term-name then] hierarchy level:

• count

• accept

• discard

• next

• policer

For more information about how to configure firewall filters, see the Junos OS Policy
Framework Configuration Guide. For more information about how to configure interfaces,
see the Junos OS Network Interfaces Configuration Guide and the Junos OS Services Interfaces
Configuration Guide.

Copyright © 2012, Juniper Networks, Inc. 259

Junos OS 12.1 MPLS Applications Configuration Guide

Examples: Configuring MPLS Firewall Filters

The following examples illustrate how you might configure an MPLS firewall filter and
then apply the filter to an interface. This filter is configured to count MPLS packets with
EXP bits set to either 0 or 4.

The following shows a configuration for an MPLS firewall filter:

[edit firewall]
family mpls {
filter expf {
term expt0 {
from {
exp 0,4;
}
then {
count counter0;
accept;
}
}
}
}

The following shows how to apply the MPLS firewall filter to an interface:

[edit interfaces]
so-0/0/0 {
mtu 4474;
encapsulation ppp;
sonet-options {
fcs 32;
}
unit 0 {
point-to-point;
family mpls {
filter {
input expf;
output expf;
}
}
}
}

The MPLS firewall filter is applied to the input and output of an interface (see the input
and output statements in the preceding example).

Configuring Policers for LSPs

MPLS LSP policing allows you to control the amount of traffic forwarded through a
particular LSP. Policing helps to ensure that the amount of traffic forwarded through an
LSP never exceeds the requested bandwidth allocation. LSP policing is supported on
regular LSPs, LSPs configured with DiffServ-aware traffic engineering, and multiclass
LSPs. You can configure multiple policers for each multiclass LSP. For regular LSPs, each
LSP policer is applied to all of the traffic traversing the LSP. The policer's bandwidth

260 Copyright © 2012, Juniper Networks, Inc.

 Chapter 9: Miscellaneous MPLS Properties Configuration Guidelines

limitations become effective as soon as the total sum of traffic traversing the LSP exceeds
the configured limit.

You configure the multiclass LSP and DiffServ-aware traffic engineering LSP policers in
a filter. The filter can be configured to distinguish between the different class types and
apply the relevant policer to each class type. The policers distinguish between class types
based on the EXP bits.

You configure LSP policers under the family any filter. The family any filter is used because
the policer is applied to traffic entering the LSP. This traffic might be from different
families: IPv6, MPLS, and so on. You do not need to know what sort of traffic is entering
the LSP, as long as the match conditions apply to all types of traffic.

You can configure only those match conditions that apply across all types of traffic. The
following are the supported match conditions for LSP policers:

• forwarding-class

• packet-length

• interface

• interface-set

To enable a policer on an LSP, first you need to configure a policing filter and then include
it in the LSP configuration. For information about how to configure policers, see the Junos
OS Policy Framework Configuration Guide.

To configure a policer for an LSP, specify a filter by including the filter option to the policing
statement:

policing {
filter filter-name;
}

You can include the policing statement at the following hierarchy levels:

• [edit protocols mpls label-switched-path lsp-name]

• [edit protocols mpls static-label-switched-path lsp-name]

• [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name]

• [edit logical-systems logical-system-name protocols mpls static-label-switched-path

lsp-name]

LSP Policer Limitations

When configuring MPLS LSP policers, be aware of the following limitations:

• LSP policers are supported for packet LSPs only.

• LSP policers are supported for unicast next hops only. Multicast next hops are not
supported.

• LSP policers are not supported on aggregated interfaces.

Copyright © 2012, Juniper Networks, Inc. 261

Junos OS 12.1 MPLS Applications Configuration Guide

• The LSP policer runs before any output filters.

• Traffic sourced from the Routing Engine (for example, ping traffic) does not take the
same forwarding path as transit traffic. This type of traffic cannot be policed.

• LSP policers work on all T Series routers and on M Series routers that have the Internet
Processor II application-specific integrated circuit (ASIC).

Example: Configuring an LSP Policer

The following example shows how you can configure a policing filter for an LSP:

[edit firewall]
policer police-ct1 {
if-exceeding {
bandwidth-limit 50m;
burst-size-limit 1500;
}
then {
discard;
}
}
policer police-ct0 {
if-exceeding {
bandwidth-limit 200m;
burst-size-limit 1500;
}
then {
discard;
}
}
family any {
filter bar {
term discard-ct0 {
then {
policer police-ct0;
accept;
}
}
}
term discard-ct1 {
then {
policer police-ct1;
accept;
}
}
}

Configuring Automatic Policers

Automatic policing of LSPs allows you to provide strict service guarantees for network
traffic. Such guarantees are especially useful in the context of Differentiated Services
for traffic engineered LSPs, providing better emulation for ATM wires over an MPLS
network. For more information about Differentiated Services for LSPs, see “DiffServ-Aware
Traffic Engineering Introduction” on page 188.

262 Copyright © 2012, Juniper Networks, Inc.

 Chapter 9: Miscellaneous MPLS Properties Configuration Guidelines

Differentiated Services for traffic engineered LSPs allow you to provide differential
treatment to MPLS traffic based on the EXP bits. To ensure these traffic guarantees, it
is insufficient to simply mark the traffic appropriately. If traffic follows a congested path,
the requirements might not be met.

LSPs are guaranteed to be established along paths where enough resources are available
to meet the requirements. However, even if the LSPs are established along such paths
and are marked properly, these requirements cannot be guaranteed unless you ensure
that no more traffic is sent to an LSP than there is bandwidth available.

It is possible to police LSP traffic by manually configuring an appropriate filter and applying
it to the LSP in the configuration. However, for large deployments it is cumbersome to
configure thousands of different filters. Configuration groups cannot solve this problem
either, since different LSPs might have different bandwidth requirements, requiring
different filters. To police traffic for numerous LSPs, it is best to configure automatic
policers.

When you configure automatic policers for LSPs, a policer is applied to all of the LSPs
configured on the router. However, you can disable automatic policing on specific LSPs.

NOTE: You cannot configure automatic policing for LSPs carrying CCC traffic.

The following sections describe how to configure automatic policers for LSPs:

• Configuring Automatic Policers for LSPs on page 263

• Configuring Automatic Policers for DiffServ-Aware Traffic Engineering LSPs on page 264
• Configuring Automatic Policers for Point-to-Multipoint LSPs on page 264
• Disabling Automatic Policing on an LSP on page 265
• Example: Configuring Automatic Policing for an LSP on page 265

Configuring Automatic Policers for LSPs

To configure automatic policers for standard LSPs (neither DiffServ-aware traffic

engineered LSPs nor multiclass LSPs), include the auto-policing statement with either
the class all policer-action option or the class ct0 policer-action option:

auto-policing {
class all policer-action;
class ct0 policer-action;
}

You can include this statement at the following hierarchy levels:

• [edit protocols mpls]

• [edit logical-systems logical-system-name protocols mpls]

You can configure the following policer actions for automatic policers:

• drop—Drop all packets.

Copyright © 2012, Juniper Networks, Inc. 263

Junos OS 12.1 MPLS Applications Configuration Guide

• loss-priority-high—Set the packet loss priority (PLP) to high.

• loss-priority-low—Set the PLP to low.

These policer actions are applicable to all types of LSPs. The default policer action is to
do nothing.

Automatic policers for LSPs police traffic based on the amount of bandwidth configured
for the LSPs. You configure the bandwidth for an LSP using the bandwidth statement at
the [edit protocols mpls label-switched-path lsp-path-name] hierarchy level. If you have
enabled automatic policers on a router, change the bandwidth configured for an LSP,
and commit the revised configuration, the change does not take affect on the active
LSPs. To force the LSPs to use the new bandwidth allocation, issue a clear mpls lsp
command.

NOTE: You cannot configure automatic policers for LSPs that traverse
aggregated interfaces or Multilink Point-to-Point Protocol (MLPPP) interfaces.

Configuring Automatic Policers for DiffServ-Aware Traffic Engineering LSPs

To configure automatic policers for DiffServ-aware traffic engineering LSPs and for
multiclass LSPs, include the auto-policing statement:

auto-policing {
class all policer-action;
class ctnumber policer-action;
}

You can include this statement at the following hierarchy levels:

• [edit protocols mpls]

• [edit logical-systems logical-system-name protocols mpls]

You include either the class all policer-action statement or a class ctnumber policer-action
statement for each of one or more classes (you can configure a different policer action
for each class). For a list of the actions that you can substitute for the policer-action
variable, see “Configuring Automatic Policers for LSPs” on page 263. The default policer
action is to do nothing.

NOTE: You cannot configure automatic policers for LSPs that traverse
aggregated interfaces or MLPPP interfaces.

Configuring Automatic Policers for Point-to-Multipoint LSPs

You can configure automatic policers for point-to-multipoint LSPs by including the
auto-policing statement with either the class all policer-action option or the class ct0
policer-action option. You only need to configure the auto-policing statement on the
primary point-to-multipoint LSP (for more information on primary point-to-multipoint
LSPs, see “Configuring the Primary Point-to-Multipoint LSP” on page 222). No additional

264 Copyright © 2012, Juniper Networks, Inc.

 Chapter 9: Miscellaneous MPLS Properties Configuration Guidelines

configuration is required on the subLSPs for the point-to-multipoint LSP.

Point-to-multipoint automatic policing is applied to all branches of the point-to-multipoint
LSP. In addition, automatic policing is applied to any local VRF interfaces that have the
same forwarding entry as a point-to-multipoint branch. Feature parity for automatic
policers for MPLS point-to-multipoint LSPs on the Junos Trio chipset is supported in
Junos OS Releases 11.1R2, 11.2R2, and 11.4.

The automatic policer configuration for point-to-multipoint LSPs is identical to the

automatic policer configuration for standard LSPs. For more information, see “Configuring
Automatic Policers for LSPs” on page 263.

Disabling Automatic Policing on an LSP

When you enable automatic policing, all of the LSPs on the router or logical system are
affected. To disable automatic policing on a specific LSP on a router where you have
enabled automatic policing, include the policing statement with the no-auto-policing
option:

policing no-auto-policing;

You can include this statement at the following hierarchy levels:

• [edit protocols mpls label-switched-path lsp-name]

• [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name]

Example: Configuring Automatic Policing for an LSP

Configure automatic policing for a multiclass LSP, specifying different actions for class
types ct0, ct1, ct2, and ct3.

[edit protocols mpls]

diffserv-te {
bandwidth-model extended-mam;
}
auto-policing {
class ct1 loss-priority-low;
class ct0 loss-priority-high;
class ct2 drop;
class ct3 loss-priority-low;
}
traffic-engineering bgp-igp;
label-switched-path sample-lsp {
to 3.3.3.3;
bandwidth {
ct0 11;
ct1 1;
ct2 1;
ct3 1;
}
}
interface fxp0.0 {
disable;
}
interface t1-0/5/3.0;

Copyright © 2012, Juniper Networks, Inc. 265

Junos OS 12.1 MPLS Applications Configuration Guide

interface t1-0/5/4.0;

Writing Different DSCP and EXP Values in MPLS-Tagged IP Packets

You can selectively set the DiffServ code point (DSCP) field of MPLS-tagged IPv4 and
IPv6 packets to 0 without affecting output queue assignment, and continue to set the
MPLS EXP field according to the configured rewrite table, which is based on forwarding
classes. You can accomplish this by configuring a firewall filter for the MPLS-tagged
packets.

For instructions on how to write different DSCP and EXP values in MPLS-tagged IP
packets, see the Junos OS Class of Service Configuration Guide. For instructions on how to
configure firewall filters, see the Junos OS Policy Framework Configuration Guide.

Configuring MPLS Rewrite Rules

You can apply a number of different rewrite rules to MPLS packets.

For more information about how to configure statements at the [edit class-of-service]
hierarchy level, see the Junos OS Class of Service Configuration Guide.

The following sections describe how you can apply rewrite rules to MPLS packets:

• Rewriting the EXP Bits of All Three Labels of an Outgoing Packet on page 266
• Rewriting MPLS and IPv4 Packet Headers on page 267

Rewriting the EXP Bits of All Three Labels of an Outgoing Packet

In interprovider, carrier-of-carrier, and complex traffic engineering scenarios, it is
sometimes necessary to push three labels on the next hop.

By default, on M Series routers except the M320, the top MPLS EXP label of an outgoing
packet is not rewritten when you configure swap-push-push and triple-push operations.
You can rewrite the EXP bits of all three labels of an outgoing packet, thereby maintaining
the class of service (CoS) of an incoming MPLS or non-MPLS packet.

To push three labels on incoming MPLS packets, include the exp-swap-push-push default
statement at the [edit class-of-service interfaces interface-name unit logical-unit-number
rewrite-rules] hierarchy level:

[edit class-of-service interfaces interface-name unit logical-unit-number rewrite-rules]

exp-swap-push-push default;

To push three labels on incoming non-MPLS packets, include the exp-push-push-push

default statement at the [edit class-of-service interfaces interface-name unit
logical-unit-number rewrite-rules] hierarchy level:

[edit class-of-service interfaces interface-name unit logical-unit-number rewrite-rules]

exp-push-push-push default;

For more information about how to configure statements at the [edit class-of-service]
hierarchy level, see the Junos OS Class of Service Configuration Guide.

266 Copyright © 2012, Juniper Networks, Inc.

 Chapter 9: Miscellaneous MPLS Properties Configuration Guidelines

Rewriting MPLS and IPv4 Packet Headers

You can apply a rewrite rule to MPLS and IPv4 packet headers simultaneously. This
allows you to initialize MPLS EXP and IP precedence bits at LSP ingress. You can configure
different rewrite rules depending on whether the traffic is VPN or non-VPN.

To rewrite MPLS and IPv4 packet headers, include the protocol statement at the
[edit class-of-service interfaces interface-name unit logical-unit-number rewrite-rules exp
rewrite-rule-name] hierarchy level:

[edit class-of-service interfaces interface-name unit logical-unit-number rewrite-rules exp

rewrite-rule-name]
protocol types;

Use the protocol statement to specify the types of MPLS packets and packet headers
to which to apply the rewrite rule. The MPLS packet can be a standard MPLS packet or
an MPLS packet with an IPv4 payload. Specify the type of MPLS packet by using the
following options:

• mpls-any—Applies the rewrite rule to MPLS packets and writes the code point value
to MPLS headers.

• mpls-inet-both—Applies the rewrite rule to VPN MPLS packets with IPv4 payloads.
Writes the code point value to the MPLS and IPv4 headers in T Series (except T4000
routers) and M320 routers. On M Series routers, except the M320, the mpls-inet-both
option causes all ingress MPLS LSP packets with IPv4 payloads to be initialized with
000 code points for IP precedence and MPLS EXP values.

• mpls-inet-both-non-vpn—Applies the rewrite rule to any non-VPN MPLS packets with

IPv4 payloads. Writes the code point value to the MPLS and IPv4 headers in T Series
and M320 routers. On M Series routers, except the M320, the mpls-inet-both-non-vpn
option causes all ingress MPLS LSP packets with IPv4 payloads to be initialized with
000 code points for IP precedence and MPLS EXP values.

For a detailed example on how to configure rewrite rules for MPLS and IPv4 packets and
for more information about how to configure class of service, see the Junos OS Class of
Service Configuration Guide.

Configuring BFD for MPLS IPv4 LSPs

You can configure Bidirectional Forwarding Detection (BFD) protocol on MPLS IPv4 LSPs
as outlined in the Internet draft draft-ietf-bfd-mpls-02.txt, BFD for MPLS LSPs. BFD is
used as a periodic Operation, Administration, and Maintenance (OAM) feature for LSPs
to detect LSP data plane faults. You can configure BFD for LSPs that use either LDP or
RSVP as the signaling protocol.

You can also use the LSP ping commands to detect LSP data plane faults. However,
BFD has a couple of benefits: it requires less computer processing than LSP ping
commands and can quickly detect faults in large numbers of LSPs (LSP ping commands
must be issued for each LSP individually). On the other hand, BFD cannot be used to
verify the control plane against the data plane at the egress LSR, which is possible when
an LSP ping echo request is associated with a forwarding equivalence class (FEC).

Copyright © 2012, Juniper Networks, Inc. 267

Junos OS 12.1 MPLS Applications Configuration Guide

For configuration instructions for LDP-signaled LSPs, see “Configuring BFD for LDP LSPs”
on page 486. For configuration instructions for RSVP-signaled LSPs, see the following
section.

Configuring BFD for RSVP-Signaled LSPs

BFD for RSVP supports unicast IPv4 LSPs. When BFD is configured for an RSVP LSP on
the ingress router, it is enabled on the primary path and on all standby secondary paths
for that LSP. You can enable BFD for all LSPs on a router or for specific LSPs. If you
configure BFD for a specific LSP, whatever values configured globally for BFD are
overridden. The BFD sessions originate only at the ingress router and terminate at the
egress router.

An error is logged whenever a BFD session for a path fails. The following example shows
how BFD for RSVP LSP log messages might appear:
RPD_MPLS_PATH_BFD_UP: MPLS BFD session for path path1 up on LSP R0_to_R3
RPD_MPLS_PATH_BFD_DOWN: MPLS BFD session for path path1 down on LSP R0_to_R3

You can configure BFD for all of the RSVP LSPs on the router, a specific LSP, or the
primary path of a specific LSP. To configure BFD for RSVP LSPs, include the oam and
bfd-liveness-detection statements.

oam {
bfd-liveness-detection {
failure-action {
make-before-break teardown-timeout seconds;
teardown;
}
failure-action teardown;
minimum-interval milliseconds;
minimum-receive-interval milliseconds;
minimum-transmit-interval milliseconds;
multiplier detection-time-multiplier;
}
lsp-ping-interval seconds;
}

You can configure this statement at the following hierarchy levels:

• [edit protocols mpls]

• [edit protocols mpls label-switched-path lsp-name]

• [edit protocols mpls label-switched-path lsp-name primary path-name]

The bfd-liveness-detection statement includes the following options:

• minimum-interval—Specifies the minimum transmit and receive interval.

• minimum-receive-interval—Specifies the minimum receive interval. The range is from

1 through 255,000 milliseconds.

• minimum-transmit-interval—Specifies the minimum transmit interval. The range is

from 1 through 255,000 milliseconds.

• multiplier—Specifies the detection time multiplier. The range is from 1 through 255.

268 Copyright © 2012, Juniper Networks, Inc.

 Chapter 9: Miscellaneous MPLS Properties Configuration Guidelines

NOTE: To avoid triggering false negatives, configure a BFD fault detection

time that is longer than the fast reroute time.

You can also configure the lsp-ping-interval option to adjust the time interval between
LSP pings. The LSP ping command for RSVP-signaled LSPs is ping mpls rsvp. For more
information on the ping mpls rsvp command, see the Junos OS System Basics and Services
Command Reference.

Configuring a Failure Action for the BFD Session on an RSVP LSP

When the BFD session for an RSVP LSP goes down, the LSP is torn down and resignaled.
Traffic can be switched to a standby LSP, or you can simply tear down the LSP path. Any
actions performed are logged.

When a BFD session for an RSVP LSP path goes down, you can configure the Junos OS
to resignal the LSP path or to simply disable the LSP path. A standby LSP path could be
configured to handle traffic while the primary LSP path is unavailable. The router can
automatically recover from LSP failures that can be detected by BFD. By default, if a BFD
session fails, the event is simply logged.

To enable the Junos OS to tear down an RSVP LSP path in the event of a BFD event,
include the failure-action statement:

failure-action {
make-before-break teardown-timeout seconds;
teardown;
}

For a list of the hierarchy levels at which you can include this statement, see the statement
summary section for this statement.

You can configure either the teardown or make-before-break options:

• teardown—Causes the LSP path to be taken down and resignaled immediately.

• make-before-break—Causes the Junos OS to attempt to signal a new LSP path before

tearing down the old LSP path. You can also configure the teardown-timeout option
to automatically tear down the LSP after the time period specified if the attempt to
resignal the LSP fails within the teardown-timeout interval. If you specify a value of 0
for the teardown-timeout interval, the LSP is taken down and resignaled immediately
(the same behavior as when you configure the teardown option).

To configure a failure action for all of the RSVP LSPs, include the failure-action statement
at the [edit protocols mpls oam bfd-liveness-detection] hierarchy level. To configure a
failure action for a specific RSVP LSP, include the failure-action statement at the [edit
protocols mpls label-switched-path lsp-name oam bfd-liveness-detection] hierarchy level.

To configure a failure action for a specific primary path, include the failure-action
statement at the [edit protocols mpls label-switched path lsp-name primary path-name
oam bfd-liveness-detection] hierarchy level. To configure a failure action for a specific
secondary LSP path, include the failure-action statement at the [edit protocols mpls

Copyright © 2012, Juniper Networks, Inc. 269

Junos OS 12.1 MPLS Applications Configuration Guide

label-switched-path lsp-name secondary path-name oam bfd-liveness-detection] hierarchy

level.

Pinging LSPs

The following sections describe how to use the ping mpls command to confirm LSP
functioning.

• Pinging MPLS LSPs on page 270

• Pinging Point-to-Multipoint LSPs on page 270
• Pinging the Endpoint Address of MPLS LSPs on page 271
• Pinging CCC LSPs on page 271
• Pinging Layer 3 VPNs on page 271
• Support for LSP Ping and Traceroute Commands Based on RFC 4379 on page 271

Pinging MPLS LSPs

You can ping a specific LSP. Echo requests are sent over the LSP as MPLS packets. The
payload is a User Datagram Protocol (UDP) packet forwarded to an address in the 127/8
range (127.0.0.1 by default, this address is configurable) and port 3503. The label and
interface information for building and sending this information as an MPLS packet is the
same as for standard LSP traffic.

When the echo request arrives at the egress node, the receiver checks the contents of
the packet and sends a reply containing the correct return value, by using UDP. The router
sending the echo request waits to receive an echo reply after a timeout of 2 seconds (you
cannot configure this value).

You must configure MPLS at the [edit protocols mpls] hierarchy level on the remote router
to be able to ping an LSP terminating there. You must configure MPLS even if you intend
to ping only LDP forwarding equivalence classes (FECs).

To ping an MPLS LSP use the ping mpls <count count> <ldp <fec>> <rsvp <exp
forwarding-class> <lsp-name>> command. To ping a secondary MPLS LSP, use the ping
mpls <count count> <rsvp <lsp-name>> standby path-name command. For a detailed
description of this command, see the Junos OS Routing Protocols and Policies Command
Reference.

NOTE: The ping mpls command is not supported within routing instances.

Pinging Point-to-Multipoint LSPs

To ping a point-to-multipoint LSP, use the ping mpls rsvp lsp-name multipoint or ping
mpls rsvp egress address commands. The ping mpls rsvp lsp-name multipoint command
returns a list of all of the egress router identifiers and the current status of the
point-to-multipoint LSP egress routers. The ping mpls rsvp lsp-name multipoint egress
address command returns the current status of the specified egress router.

270 Copyright © 2012, Juniper Networks, Inc.

 Chapter 9: Miscellaneous MPLS Properties Configuration Guidelines

Pinging the Endpoint Address of MPLS LSPs

To determine whether an LSP between two provider edge (PE) routers is up and running,
you can ping the endpoint address of the LSP. To ping an MPLS LSP endpoint, use the
ping mpls lsp-end-point address command. This command tells you what type of LSP
(RSVP or LDP) terminates at the address specified and whether that LSP is up or down.

For a detailed description of this command, see the Junos OS Routing Protocols and Policies
Command Reference.

Pinging CCC LSPs

You can ping a specific CCC LSP. The CCC LSP ping command is identical to the one
used for MPLS LSPs. The command you use is ping mpls <count count> <rsvp <lsp-name>>.
You can also ping a secondary standby CCC LSP by using the ping mpls <count count>
<rsvp <lsp-name>> standby path-name command.

For a detailed description of this command, see the Junos OS Routing Protocols and Policies
Command Reference.

Pinging Layer 3 VPNs

You can use a similar command, ping mpls l3vpn vpn-name prefix prefix <count count>,
to ping a Layer 3 VPN. For more information about this command, see the Junos OS VPNs
Configuration Guide and the Junos OS Routing Protocols and Policies Command Reference.

Support for LSP Ping and Traceroute Commands Based on RFC 4379
The Junos OS partially supports LSP ping and traceroute commands based on RFC 4379,
Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures. However, the Junos
OS only supports this functionality on LSP transit routers. If a ping or traceroute command
is issued from a router that fully supports RFC 4379, it can propagate correctly on routers
running the Junos OS.

LSP ping and traceroute commands based on RFC 4379 attempt to trace the path taken
by an LSP by relying on MPLS TTL expiration. An LSP can take multiple paths from ingress
to egress. This occurs in particular with Equal Cost Multipath (ECMP). The LSP traceroute
command can trace all possible paths to an LSP egress node.

Tracing MPLS and LSP Packets and Operations

To trace MPLS and LSP packets and operations, include the traceoptions statement:

traceoptions {
file filename <files number> <size size> <world-readable | no-world-readable>;
flag flag;
}

For a list of hierarchy levels at which you can include this statement, see the statement
summary section for this statement.

You can specify the following MPLS-specific flags in the MPLS traceoptions statement:

Copyright © 2012, Juniper Networks, Inc. 271

Junos OS 12.1 MPLS Applications Configuration Guide

• all—Trace all operations.

• connection—Trace all circuit cross-connect (CCC) activity.

• connection-detail—Trace detailed CCC activity.

• cspf—Trace CSPF computations.

• cspf-link—Trace links visited during CSPF computations.

• cspf-node—Trace nodes visited during CSPF computations.

• error—Trace MPLS error conditions.

• graceful-restart—Trace MPLS graceful restart events.

• lsping—Trace LSP ping packets and return codes.

• nsr-synchronization—Trace nonstop routing (NSR) synchronization events.

• nsr-synchronization-detail—Trace NSR synchronization events in detail.

• state—Trace all LSP state transitions.

• static—Trace static label-switched path.

When you configure trace options to track an MPLS LSP using the cspf option, the CSPF
log displays information about the MPLS LSP using the term “generalized MPLS” (GMPLS).
For example, a message in the CSPF log might state that the “link passes GMPLS
constraints”. Generalized MPLS (GMPLS) is a superset of MPLS, so this message is normal
and does not affect proper MPLS LSP operation.

For general information about tracing and global tracing options, see the Junos OS Routing
Protocols Configuration Guide.

272 Copyright © 2012, Juniper Networks, Inc.

CHAPTER 10

Summary of MPLS Configuration

Statements

This chapter shows the complete MPLS configuration statements. The statements are
organized alphabetically.

adaptive

Syntax adaptive;

Hierarchy Level [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name],

[edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name
(primary | secondary) path-name],
[edit protocols mpls label-switched-path lsp-name],
[edit protocols mpls label-switched-path lsp-name (primary | secondary) path-name]

Release Information Statement introduced before Junos OS Release 7.4.

Description During reroute, do not double-count bandwidth on links shared by the old and new paths.
Including this statement causes RSVP to use shared explicit (SE) reservation styles and
assists in smooth transition during rerouting.

Default The configured object is disabled.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring Adaptive LSPs on page 178

Documentation

Copyright © 2012, Juniper Networks, Inc. 273

Junos OS 12.1 MPLS Applications Configuration Guide

adjust-interval

Syntax adjust-interval seconds;

Hierarchy Level [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name

auto-bandwidth],
[edit protocols mpls label-switched-path lsp-name auto-bandwidth]

Release Information Statement introduced before Junos OS Release 7.4.

Description Specify the bandwidth reallocation interval.

Options seconds—Bandwidth reallocation interval, in seconds.

Range: 300 through 4,294,967,295 seconds
Default: 86,400 seconds

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring the Automatic Bandwidth Allocation Interval on page 165

Documentation

adjust-threshold

Syntax adjust-threshold percent;

Hierarchy Level [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name

auto-bandwidth],
[edit protocols mpls label-switched-path lsp-name auto-bandwidth]

Release Information Statement introduced before Junos OS Release 7.4.

Description Specify how sensitive the automatic bandwidth adjustment for a label-switched path
(LSP) is to changes in bandwidth utilization.

Options percent—Bandwidth demand for the current bandwidth adjustment interval is determined
and compared to the LSP’s current bandwidth allocation. If the percentage difference
in bandwidth is greater than or equal to the percentage specified by this statement,
the LSP’s bandwidth is adjusted to the current bandwidth demand.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring the Automatic Bandwidth Adjustment Threshold on page 166

Documentation

274 Copyright © 2012, Juniper Networks, Inc.

 Chapter 10: Summary of MPLS Configuration Statements

adjust-threshold-overflow-limit

Syntax adjust-threshold-overflow-limit number;

Hierarchy Level [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name

auto-bandwidth],
[edit protocols mpls label-switched-path lsp-name auto-bandwidth]

Release Information Statement introduced in Junos OS Release 7.5.

Description Specify the number of consecutive bandwidth overflow samples before triggering a
bandwidth adjustment.

Options number—Number of consecutive bandwidth overflow samples.

Range: 1 through 65,535
Default: This feature is disabled by default.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring a Limit on Bandwidth Overflow and Underflow Samples on page 167
Documentation

adjust-threshold-underflow-limit

Syntax adjust-threshold-underflow-limit number;

Hierarchy Level [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name

auto-bandwidth],
[edit protocols mpls label-switched-path lsp-name auto-bandwidth]

Release Information Statement introduced in Junos OS Release 11.3.

Description Specify the number of consecutive bandwidth underflow samples before triggering a
bandwidth adjustment.

Options number—Number of consecutive bandwidth underflow samples.

Range: 1 through 65,535
Default: This feature is disabled by default.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring a Limit on Bandwidth Overflow and Underflow Samples on page 167
Documentation

Copyright © 2012, Juniper Networks, Inc. 275

Junos OS 12.1 MPLS Applications Configuration Guide

admin-down

Syntax admin-down;

Hierarchy Level [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name],

[edit protocols mpls label-switched-path lsp-name]

Release Information Statement introduced in Junos OS Release 8.2.

Description Set a nonpacket GMPLS LSP to the administrative down state. This statement does not
affect control path setup or data forwarding for packet LSPs.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Allowing Nonpacket GMPLS LSPs to Establish Paths Through Routers Running the
Documentation Junos OS on page 597

276 Copyright © 2012, Juniper Networks, Inc.

 Chapter 10: Summary of MPLS Configuration Statements

admin-group

See the following sections:

• admin-group (for Interfaces) on page 277

• admin-group (for LSPs) on page 278

admin-group (for Interfaces)

Syntax admin-group [ group-names ];

Hierarchy Level [edit logical-systems logical-system-name protocols mpls interface interface-name],

[edit protocols mpls interface interface-name]

Release Information Statement introduced before Junos OS Release 7.4.

Description Define administrative groups for an interface.

Options group-names—One or more names of groups defined with the admin-groups statement
at the [edit protocols mpls] hierarchy level.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring Administrative Groups on page 171

Documentation
• admin-groups on page 279

Copyright © 2012, Juniper Networks, Inc. 277

Junos OS 12.1 MPLS Applications Configuration Guide

admin-group (for LSPs)

Syntax admin-group {
exclude [ group-names ];
include-all [ group-names ];
include-any [ group-names ];
}

Hierarchy Level [edit logical-systems logical-system-name protocols mpls],

[edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name],
[edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name
(primary | secondary) path-name],
[edit protocols mpls],
[edit protocols mpls label-switched-path lsp-name],
[edit protocols mpls label-switched-path lsp-name (primary | secondary) path-name]

Release Information Statement introduced before Junos OS Release 7.4.

Description Define the administrative groups to include or exclude an LSP and a path’s primary and
secondary paths.

Options The statements are explained separately.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring Administrative Groups on page 171

Documentation

278 Copyright © 2012, Juniper Networks, Inc.

 Chapter 10: Summary of MPLS Configuration Statements

admin-groups

Syntax admin-groups {
group-name group-value;
}

Hierarchy Level [edit logical-systems logical-system-name protocols mpls],

[edit protocols mpls]

Release Information Statement introduced before Junos OS Release 7.4.

Description Configure administrative groups to implement link coloring of resource classes.

Options group-name—Name of the group. You can assign up to 32 names. The names and their
corresponding values must be identical across all routers within a single domain.

group-value—Value assigned to the group. The names and their corresponding values
must be identical across all routers within a single domain.
Range: 0 through 31

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring Administrative Groups on page 171

Documentation
• admin-group (for Interfaces) on page 277

Copyright © 2012, Juniper Networks, Inc. 279

Junos OS 12.1 MPLS Applications Configuration Guide

admin-group-extended

Syntax admin-group-extended {
apply-groups group-value;
apply-groups-except group-value;
exclude [ group-values ];
include-all [ group-values ];
include-any [ group-values ];
}

Hierarchy Level [edit logical-systems logical-system-name protocols mpls],

[edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name],
[edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name
(primary | secondary) path-name],
[edit protocols mpls],
[edit protocols mpls label-switched-path lsp-name],
[edit protocols mpls label-switched-path lsp-name (primary | secondary) path-name]

Release Information Statement introduced in Junos OS Release 11.1.

Description Specifies the group name and group identifier for an administrative group. The group
identifier must be within the range of values specified by the admin-groups-extended-range
statement. The extended administrative group values are global and must be identically
configured on all the supported routers participating in the network. The domain-wide
extended administrative groups database, learned from other routers through IGP flooding,
is used by CSPF for path computation.

Options apply-groups—Apply the specified administrative groups for the LSP or for the primary
and secondary paths.

apply-groups-except—Exclude the specified administrative groups from the LSP or from

the primary and secondary paths.

exclude—Define the administrative groups to exclude from an LSP or from the primary
and secondary paths.

include-all—Require the LSP to traverse links that include all of the defined administrative
groups.

include-any—Define the administrative groups to include for an LSP for the primary and
secondary paths.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring Extended Administrative Groups on page 173

Documentation
• Configuring Administrative Groups on page 171

• admin-groups-extended on page 281

• admin-groups-extended-range on page 282

280 Copyright © 2012, Juniper Networks, Inc.

 Chapter 10: Summary of MPLS Configuration Statements

admin-groups-extended

Syntax admin-groups-extended group-name {

group-value group-identifier;
}

Hierarchy Level [edit logical-systems logical-system-name protocols mpls interface interface-name],

[edit logical-systems logical-system-name routing-options],
[edit protocols mpls interface interface-name],
[edit routing-options]

Release Information Statement introduced in Junos OS Release 11.1.

Description Specifies the group name and group identifier for an administrative group. The group
identifier must be within the range of values specified by the admin-groups-extended-range
statement. The extended administrative group values are global and must be identically
configured on all the supported routers participating in the network. The domain-wide
extended administrative groups database, learned from other routers through IGP flooding,
is used by CSPF for path computation.

Options group-name—The range of configurable values is between 32 and 4,294,967,295. The

range maximum must be greater than the range minimum.

group-value group-identifier—The group identifier must be within the range of configurable

values, 32 and 4,294,967,295.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring Extended Administrative Groups on page 173

Documentation
• Configuring Administrative Groups on page 171

• admin-group-extended on page 280

• admin-groups-extended-range on page 282

Copyright © 2012, Juniper Networks, Inc. 281

Junos OS 12.1 MPLS Applications Configuration Guide

admin-groups-extended-range

Syntax admin-groups-extended-range {
maximum maximum-number;
mininum minimum-number;
}

Hierarchy Level [edit logical-systems logical-system-name routing-options],

[edit routing-options]

Release Information Statement introduced in Junos OS Release 11.1.

Description Enables you to configure extended administrative groups, represented by a 32-bit value,
expanding the number of administrative groups supported in the network beyond just
32. In MPLS traffic engineering, a link can be configured with a set of administrative groups
(also known as colors or resource classes). Administrative groups are carried in IGPs
(OSPFv2 and IS-IS) as a 32-bit value assigned to each link. By default, Juniper Networks
routers interpret this 32-bit value as a bit mask with each bit representing a group. This
normally limits each network to a total of 32 distinct administrative groups (value range
0 through 31).

The extended administrative groups configuration accepts a set of interfaces with a

corresponding set of extended administrative group names. It converts the names into
a set of 32-bit values and propagates this information into the IGP. The extended
administrative group values are global and must be identically configured on all the
supported routers participating in the network. The domain-wide extended administrative
groups database, learned from other routers through IGP flooding, is used by CSPF for
path computation.

Options maximum maximum-number—The range of configurable values is between 32 and

4,294,967,295. The range maximum must be greater than the range minimum.

minimum minimum-number—The range of configurable values is between 32 and

4,294,967,295. The range maximum must be greater than the range minimum.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring Extended Administrative Groups on page 173

Documentation
• Configuring Administrative Groups on page 171

• admin-group-extended on page 280

282 Copyright © 2012, Juniper Networks, Inc.

 Chapter 10: Summary of MPLS Configuration Statements

advertisement-hold-time

Syntax advertisement-hold-time seconds;

Hierarchy Level [edit logical-systems logical-system-name protocols mpls],

[edit protocols mpls]

Release Information Statement introduced before Junos OS Release 7.4.

Description Do not advertise when the LSP goes from up to down, for a certain period of time known
as the hold time.

Options seconds—Hold time, in seconds.

Range: 0 through 65,535 seconds
Default: 5 seconds

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Damping Advertisement of LSP State Changes on page 186

Documentation

allow-fragmentation

Syntax allow-fragmentation;

Hierarchy Level [edit logical-systems logical-system-name protocols mpls path-mtu],

[edit protocols mpls path-mtu]

Release Information Statement introduced before Junos OS Release 7.4.

Description Allow IP packets to be fragmented before they are encapsulated in MPLS.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Enabling Packet Fragmentation on page 419

Documentation

Copyright © 2012, Juniper Networks, Inc. 283

Junos OS 12.1 MPLS Applications Configuration Guide

always-mark-connection-protection-tlv

Syntax always-mark-connection-protection-tlv;

Hierarchy Level [edit logical-systems logical-systems-name protocols mpls interface interface-name],

[edit protocols mpls interface interface-name]

Release Information Statement introduced in Junos OS Release 10.2.

Description (MX Series routers only) Enable you to switch an LSP away from a network node using
a bypass LSP. This feature could be used in maintenance of active networks when a
network device needs to be replaced without interrupting traffic passing through the
network. The LSPs can be either static or dynamic.

This statement marks all OAM traffic transiting this interface in preparation for switching
the traffic to an alternate path based on the OAM functionality. To switch traffic to the
bypass LSP, you then need to configure the switch-away-lsps statement.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Switching LSPs Away from a Network Node on page 403

Documentation

associate-backup-pe-groups

Syntax associate-backup-pe-groups;

Hierarchy Level [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name],

[edit protocols mpls label-switched-path lsp-name]

Release Information Statement introduced in Junos OS Release 9.0.

Description Enable an LSP to monitor the status of its destination PE router. You can configure
multiple backup PE router groups using the same router's address. Backup PE router
groups provide ingress PE router redundancy when point-to-multipoint LSPs are
configured for multicast distribution. A failure of this LSP indicates to all of the backup
PE router groups that the destination PE router is down. This statement is not tied to a
specific backup PE router group. It applies to all groups that are interested in the status
of the LSP to the destination address.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Enabling Point-to-Point LSPs to Monitor Egress PE Routers on page 226

Documentation

284 Copyright © 2012, Juniper Networks, Inc.

 Chapter 10: Summary of MPLS Configuration Statements

associate-lsp

Syntax associate-lsp lsp-name {

from from-ip-address;
}

Hierarchy Level [edit protocols mpls label-switched-path lsp-name oam]

Release Information Statement introduced in Junos OS Release 12.1.

Description Configure associated bidirectional label-switched paths (LSPs) on the two ends of an
LSP for sending and receiving GAL and G-Ach OAM messages.

Options from from-ip-address—(Optional) Source address for the associated LSP configuration.
If omitted, this is derived from the to address of the ingress LSP configuration.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Example: Configuring the MPLS Transport Profile for OAM on page 130
Documentation

auto-bandwidth

Syntax auto-bandwidth {
adjust-interval seconds;
adjust-threshold percent;
adjust-threshold-overflow-limit number;
adjust-threshold-underflow-limit number;
maximum-bandwidth bps;
minimum-bandwidth bps;
monitor-bandwidth;
}

Hierarchy Level [edit protocols mpls label-switched-path lsp-name]

Release Information Statement introduced before Junos OS Release 7.4.

Description Allow an MPLS tunnel to automatically adjust its bandwidth allocation based on the
volume of traffic flowing through the tunnel.

Options The statements are explained separately.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring Automatic Bandwidth Allocation for LSPs on page 163

Documentation
• request mpls lsp adjust-autobandwidth

Copyright © 2012, Juniper Networks, Inc. 285

Junos OS 12.1 MPLS Applications Configuration Guide

auto-policing

Syntax auto-policing {
class all (drop | loss-priority-high | loss-priority-low);
class ctnumber (drop | loss-priority-high | loss-priority-low);
}

Hierarchy Level [edit logical-systems logical-system-name protocols mpls],

[edit protocols mpls]

Release Information Statement introduced before Junos OS Release 7.4.

Description Enable the automatic policing of all the MPLS LSPs on the router or logical system.

Options class all—Apply the same policer action to all the class types (ct0, ct1, ct2, and ct3).

class ctnumber—Specific class type (ct0, ct1, ct2, or ct3) to which to apply a policer action.

Policer actions—You can specify the following policer actions:

Default: no action

• drop—Drop all packets.

• loss-priority-high—Set the packet loss priority (PLP) to high.

• loss-priority-low—Set the PLP to low.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • policing on page 341

Documentation
• Configuring Automatic Policers on page 262v

286 Copyright © 2012, Juniper Networks, Inc.

 Chapter 10: Summary of MPLS Configuration Statements

backup-pe-group

Syntax backup-pe-group pe-group-name {

backups [ addresses ];
local-address address;
}

Hierarchy Level [edit logical-systems logical-system-name routing-instances routing-instance-name

routing-options multicast],
[edit logical-systems logical-system-name routing-options multicast],
[edit routing-instances routing-instance-name routing-options multicast],
[edit routing-options multicast]

Release Information Statement introduced in Junos OS Release 9.0.

Description Configure a backup provider edge (PE) group for ingress PE router redundancy when
point-to-multipoint label-switched paths (LSPs) are used for multicast distribution.

Options backups addresses—Specify the address of backup PE routers for ingress PE redundancy
when point-to-multipoint LSPs are used for multicast distribution.

local-address address—Specify the address of the local PE router for ingress PE redundancy
when point-to-multipoint LSPs are used for multicast distribution.

pe-group-name—Specify the name for the group of PE routers that provide ingress PE
router redundancy for point-to-multipoint LSPs.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring Ingress PE Router Redundancy for Point-to-Multipoint LSPs on page 225
Documentation

Copyright © 2012, Juniper Networks, Inc. 287

Junos OS 12.1 MPLS Applications Configuration Guide

bandwidth (Fast Reroute, Signaled, and Multiclass LSPs)

Syntax bandwidth bps {

ct0 bps;
ct1 bps;
ct2 bps;
ct3 bps;
}

Hierarchy Level [edit logical-systems logical-system-name protocols mpls],

[edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name],
[edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name
fast-reroute],
[edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name
(primary | secondary) path-name],
[edit protocols mpls],
[edit protocols mpls label-switched-path lsp-name],
[edit protocols mpls label-switched-path lsp-name fast-reroute],
[edit protocols mpls label-switched-path lsp-name (primary | secondary) path-name]

Release Information Statement introduced before Junos OS Release 7.4.

Description When configuring an LSP, specify the traffic rate associated with the LSP.

When configuring fast reroute, allocate bandwidth for the reroute path. By default, no
bandwidth is reserved for the rerouted path. The fast reroute bandwidth does not need
to be identical to that allocated for the LSP itself.

When configuring a multiclass LSP, use the ctnumber bandwidth statements to specify
the bandwidth to be allocated for each class type.

Options bps—Bandwidth, in bits per second. You can specify this as an integer value. You can also
use the abbreviations k (for a thousand), m (for a million), or g (for a billion).
Range: Any positive integer
Default: 0 (no bandwidth is reserved)

ctnumber bps—Bandwidth for the specified class type, in bits per second. You can specify
this as an integer value. If you do so, count your zeros carefully, or you can use the
abbreviations k (for a thousand), m (for a million), or g (for a billion [also called a
thousand million]).
Range: Any positive integer
Default: 0 (no bandwidth is reserved)

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring Fast Reroute on page 152

Documentation
• Configuring the Bandwidth Value for LSPs on page 184

• Configuring Traffic-Engineered LSPs on page 204

288 Copyright © 2012, Juniper Networks, Inc.

 Chapter 10: Summary of MPLS Configuration Statements

• Configuring Class-Type Bandwidth Constraints for Multiclass LSPs on page 207

bandwidth (Static LSP)

Syntax bandwidth bps;

Hierarchy Level [edit logical-systems logical-system-name protocols mpls

static-label-switched-path lsp-name bypass],
[edit logical-systems logical-system-name protocols mpls
static-label-switched-path lsp-name ingress],
[edit logical-systems logical-system-name protocols mpls
static-label-switched-path lsp-name transit incoming-label],
[edit protocols mpls static-label-switched-path lsp-name bypass],
[edit protocols mpls static-label-switched-path lsp-name ingress],
[edit protocols mpls static-label-switched-path lsp-name transit incoming-label]

Release Information Statement introduced in Junos OS Release 10.1.

Description When configuring a static LSP, specify the traffic rate associated with the LSP.

Options bps—Bandwidth, in bits per second. You can specify this as an integer value. You can also
use the abbreviations k (for a thousand), m (for a million), or g (for a billion).
Range: Any positive integer
Default: 0 (no bandwidth is reserved)

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring Static LSPs on page 211

Documentation

Copyright © 2012, Juniper Networks, Inc. 289

Junos OS 12.1 MPLS Applications Configuration Guide

bandwidth-model

Syntax bandwidth-model {
extended-mam;
mam;
rdm;
}

Hierarchy Level [edit logical-systems logical-system-name protocols mpls diffserv-te],

[edit protocols mpls diffserv-te]

Release Information Statement introduced before Junos OS Release 7.4.

Description Configure the bandwidth model for differentiated services. Note that you cannot configure
both bandwidth models at the same time.

Options extended-mam—The extended maximum allocation model (MAM) is a bandwidth model

based on MAM.

mam—The MAM is defined in RFC 4125, Maximum Allocation Bandwidth Constraints Model
for Diffserv-aware MPLS Traffic Engineering.

rdm—The Russian dolls bandwidth allocation model (RDM) is defined in RFC 4127, Russian
Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering. RDM
makes efficient use of bandwidth by allowing the class types to share bandwidth.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring the Bandwidth Model on page 194

Documentation

290 Copyright © 2012, Juniper Networks, Inc.

 Chapter 10: Summary of MPLS Configuration Statements

bandwidth-percent

Syntax bandwidth-percent percentage;

Hierarchy Level [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name

fast-reroute],
[edit protocols mpls label-switched-path lsp-name fast-reroute]

Release Information Statement introduced before Junos OS Release 7.4.

Description Configure the percentage of bandwidth to reserve for the detour path in case the primary
path for a traffic engineered LSP or a multiclass LSP fails. The percentage configured
indicates the percentage of the protected path’s bandwidth that is reserved for the detour
path.

Options percentage—The percentage of the protected path’s bandwidth that is reserved for the
detour path.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring Fast Reroute on page 152

Documentation
• Configuring Fast Reroute for Traffic-Engineered LSPs on page 205

• Configuring Fast Reroute for Multiclass LSPs on page 208

Copyright © 2012, Juniper Networks, Inc. 291

Junos OS 12.1 MPLS Applications Configuration Guide

bfd-liveness-detection

Syntax bfd-liveness-detection {
failure-action {
make-before-break teardown-timeout seconds;
teardown;
}
minimum-interval milliseconds;
minimum-receive-interval milliseconds;
minimum-transmit-interval milliseconds;
multiplier detection-time-multiplier;
}

Hierarchy Level [edit protocols mpls label-switched-path lsp-name oam],

[edit protocols mpls oam]

Release Information Statement introduced in Junos OS Release 7.6.

failure-action option added in Junos OS Release 8.5.

Description Enable Bidirectional Forwarding Detection (BFD) for all of the MPLS LSPs or for just a
specific LSP.

Options minimum-interval—Minimum transmit and receive interval.

Range: 50 through 255,000 milliseconds
Default: 50

minimum-receive-interval—Minimum receive interval.

Range: 50 through 255,000 milliseconds
Default: 50

minimum-transmit-interval—Minimum transmit interval.

Range: 50 through 255,000 milliseconds
Default: 50

multiplier—Detection time multiplier.

Range: 1 through 255
Default: 3

The failure-action statement is explained separately.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring BFD for MPLS IPv4 LSPs on page 267

Documentation

292 Copyright © 2012, Juniper Networks, Inc.

 Chapter 10: Summary of MPLS Configuration Statements

bypass (Static LSP)

Syntax bypass bypass-name {

bandwidth bps;
description string;
next-hop (address | interface-name | address/interface-name);
push out-label;
to address;
}

Hierarchy Level [edit logical-systems logical-system-name protocols mpls static-label-switched-path

lsp-name],
[edit protocols mpls static-label-switched-path lsp-name]

Release Information Statement introduced before Junos OS Release 10.1.

Description Configure specific bandwidth and path constraints for a bypass ingress LSP. It is possible
to configure multiple bypass LSPs individually. If you do not, they all share the same path
and bandwidth constraints.

The remaining statements are explained separately.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring Static LSPs on page 211

Documentation

Copyright © 2012, Juniper Networks, Inc. 293

Junos OS 12.1 MPLS Applications Configuration Guide

class-of-service

Syntax class-of-service cos-value;

Hierarchy Level [edit logical-systems logical-system-name protocols mpls],

[edit logical-systems logical-system-name protocols mpls static-label-switched-path
lsp-name ingress],
[edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name],
[edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name
(primary | secondary) path-name],
[edit protocols mpls],
[edit protocols mpls label-switched-path lsp-name],
[edit protocols mpls label-switched-path lsp-name (primary | secondary) path-name],
[edit logical-systems logical-system-name protocols mpls static-label-switched-path
lsp-name ingress]

Release Information Statement introduced before Junos OS Release 7.4.

Description Class-of-service (CoS) value given to all packets in the LSP.

The CoS value might affect the scheduling or queuing algorithm of traffic traveling along
an LSP.

Options cos-value—CoS value. A higher value typically corresponds to a higher level of service.
Range: 0 through 7
Default: If you do not specify a CoS value, the IP precedence bits from the packet’s IP
header are used as the packet’s CoS value.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring Class of Service for MPLS LSPs on page 175

Documentation
• Configuring the Ingress Router for Static LSPs on page 211

• Configuring the Intermediate (Transit) and Egress Routers for Static LSPs on page 214

294 Copyright © 2012, Juniper Networks, Inc.

 Chapter 10: Summary of MPLS Configuration Statements

description

Syntax description text;

Hierarchy Level [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name],

[edit logical-systems logical-system-name protocols mpls
static-label-switched-path lsp-name bypass],
[edit logical-systems logical-system-name protocols mpls
static-label-switched-path lsp-name ingress],
[edit logical-systems logical-system-name protocols mpls
static-label-switched-path lsp-name transit incoming-label],
[edit protocols mpls label-switched-path lsp-name],
[edit protocols mpls static-label-switched-path lsp-name bypass],
[edit protocols mpls static-label-switched-path lsp-name ingress],
[edit protocols mpls static-label-switched-path lsp-name transit incoming-label]

Release Information Statement introduced before Junos OS Release 7.4.

Description Provides a textual description of the LSP. Enclose any descriptive text that includes
spaces in quotation marks (" "). Any descriptive text you include is displayed in the output
of the show mpls lsp detail command and has no effect on the operation of the LSP.

Options text—Provide a textual description of the LSP. The description text can be no more than
80 characters in length.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring a Text Description for LSPs on page 152

Documentation

Copyright © 2012, Juniper Networks, Inc. 295

Junos OS 12.1 MPLS Applications Configuration Guide

diffserv-te

Syntax diffserv-te {
bandwidth-model {
extended-mam;
mam;
rdm;
}
te-class-matrix {
tenumber {
priority priority;
traffic-class {
ctnumber priority priority;
}
}
}
}

Hierarchy Level [edit logical-systems logical-system-name protocols mpls],

[edit protocols mpls]

Release Information Statement introduced before Junos OS Release 7.4.

Description Specify properties for differentiated services in traffic engineering.

Options The statements are explained separately.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring Routers for DiffServ-Aware Traffic Engineering on page 193

Documentation

296 Copyright © 2012, Juniper Networks, Inc.

 Chapter 10: Summary of MPLS Configuration Statements

disable

Syntax disable;

Hierarchy Level [edit logical-systems logical-system-name protocols mpls],

[edit logical-systems logical-system-name protocols mpls interface interface-name],
[edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name],
[edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name
auto-bandwidth],
[edit protocols mpls],
[edit protocols mpls interface interface-name],
[edit protocols mpls label-switched-path lsp-name]

Release Information Statement introduced before Junos OS Release 7.4.

Description Disable the functionality of the configured object.

Default The configured object is enabled (operational) unless explicitly disabled.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Minimum MPLS Configuration on page 55

Documentation

encoding-type

Syntax encoding-type (ethernet | packet | pdh | sonet-sdh);

Hierarchy Level [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name

lsp-attributes],
[edit protocols mpls label-switched-path lsp-name lsp-attributes]

Release Information Statement introduced before Junos OS Release 7.4.

Description Specify the encoding type of payload carried by the LSP. It can be any of the following:

• ethernet—Ethernet

• packet—Packet

• pdh—Plesiochronous digital hierarchy (PDH)

• sonet-sdh—SONET/SDH

Default packet

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring the Encoding Type on page 596

Documentation

Copyright © 2012, Juniper Networks, Inc. 297

Junos OS 12.1 MPLS Applications Configuration Guide

exclude

See the following sections:

• exclude (for Administrative Groups) on page 298

• exclude (for Fast Reroute) on page 299

exclude (for Administrative Groups)

Syntax exclude [ group-names ];

Hierarchy Level [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name

admin-group],
[edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name
(primary | secondary) path-name admin-group],
[edit protocols mpls label-switched-path lsp-name admin-group],
[edit protocols mpls label-switched-path lsp-name (primary | secondary) path-name
admin-group]

Release Information Statement introduced before Junos OS Release 7.4.

Description Define the administrative groups to exclude for an LSP or for a path’s primary and
secondary paths.

Options group-names—Names of one or more groups defined with the admin-groups statement.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring Administrative Groups on page 171

Documentation

298 Copyright © 2012, Juniper Networks, Inc.

 Chapter 10: Summary of MPLS Configuration Statements

exclude (for Fast Reroute)

Syntax (exclude [ group-names ] | no-exclude);

Hierarchy Level [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name

fast-reroute],
[edit protocols mpls label-switched-path lsp-name fast-reroute]

Release Information Statement introduced before Junos OS Release 7.4.

Description Control exclusion of administrative groups:

• exclude—Define the administrative groups to exclude for fast reroute.

• no-exclude—Disable administrative group exclusion.

Options group-names—Names of one or more groups defined with the admin-groups statement.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring Fast Reroute on page 152

Documentation
• admin-groups on page 279

Copyright © 2012, Juniper Networks, Inc. 299

Junos OS 12.1 MPLS Applications Configuration Guide

exclude-srlg

Syntax exclude-srlg;

Hierarchy Level [edit protocols mpls],

[edit logical-systems logical-system-name protocols mpls],
[edit protocols mpls label-switched-path path-name],
[edit logical-systems logical-system-name protocols mpls label-switched-path path-name],
[edit protocols rsvp interface interface-name link-protection],
[edit logical-systems logical-system-name protocols rsvp interface interface-name
link-protection],
[edit protocols rsvp interface interface-name link-protection bypass destination],
[edit logical-systems logical-system-name protocols rsvp interface interface-name
link-protection bypass destination]

Release Information Statement introduced in Junos OS Release 11.4.

Description Exclude Shared Risk Link Group (SRLG) links for the secondary path for critical links
where it is imperative to keep the secondary and primary label-switched paths completely
disjoint from any common SRLG.

When specified, the Constrained Shortest Path First (CSPF) algorithm excludes any link
belonging to the set of SRLGs in the primary path. When not specified and if a link belongs
to the set of SRLGs in the primary path, CSPF adds the SRLG cost to the metric, but still
accepts the link for computing the path.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Example: Excluding SRLG Links Completely for the Secondary LSP on page 85
Documentation

300 Copyright © 2012, Juniper Networks, Inc.

 Chapter 10: Summary of MPLS Configuration Statements

expand-loose-hop

Syntax expand-loose-hop;

Hierarchy Level [edit logical-systems logical-system-name protocols mpls],

[edit protocols mpls]

Release Information Statement introduced in Junos OS Release 7.6.

Point-to-multipoint LSP support introduced in Junos OS Release 11.2.

Description Allow an LSP to traverse multiple OSPF areas within a service provider’s network.

Allows a point-to-multipoint LSP to span multiple domains in a network. Effectively, this

allows you to configure one or more sub-LSPs (branches) in separate network domains.
Examples of such domains include OSPF areas and autonomous systems (ASs). A
sub-LSP of an inter-domain point-to-multipoint LSP can be intra-area, inter-area, or
inter-AS, depending on the location of the egress node (leaf) with respect to the ingress
node (source). Only OSPF areas are supported for inter-domain point-to-multipoint
LSPs. IS-IS levels are not supported.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Enabling Interarea Traffic Engineering on page 253

Documentation
• Configuring Inter-domain P2MP LSPs on page 245

explicit-null

Syntax explicit-null;

Hierarchy Level [edit logical-systems logical-system-name protocols mpls],

[edit protocols mpls]

Release Information Statement introduced before Junos OS Release 7.4.

Description Advertise label 0 to the egress router of an LSP.

Default If you do not include the explicit-null statement in the MPLS configuration, label 3 (implicit
null) is advertised.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring RSVP to Pop the Label on the Ultimate-Hop Router on page 419
Documentation

Copyright © 2012, Juniper Networks, Inc. 301

Junos OS 12.1 MPLS Applications Configuration Guide

failure-action

Syntax failure-action {
make-before-break teardown-timeout seconds;
teardown;
}

Hierarchy Level [edit logical-systems logical-system-name protocols mpls oam bfd-liveness-detection],

[edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name
oam bfd-liveness-detection],
[edit protocols mpls label-switched-path lsp-name oam bfd-liveness-detection],
[edit protocols mpls oam bfd-liveness-detection]

Release Information Statement introduced in Junos OS Release 9.4.

Description Configure route and next-hop properties in the event of a Bidirectional Forwarding
Detection (BFD) protocol session failure event on an RSVP label-switched path (LSP).
The failure event could be an existing BFD session that has gone down or a BFD session
that never came up. RSVP adds back the route or next hop when the relevant BFD session
comes back up.

Options make-before-break—When a BFD session fails for an RSVP LSP, an attempt is made to
signal a new LSP path before tearing down the old LSP path.

teardown—When a BFD session fails for an RSVP LSP, the associated LSP path is taken
down and resignaled immediately.

teardown-timeout seconds—When you configure the make-before-break option, you can

specify a time in seconds for the teardown-timeout option. At the end of the time
specified, the associated RSVP LSP is automatically torn down and resignaled.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring a Failure Action for the BFD Session on an RSVP LSP on page 269
Documentation

302 Copyright © 2012, Juniper Networks, Inc.

 Chapter 10: Summary of MPLS Configuration Statements

family mpls

Syntax family mpls {

label-1;
label-2;
label-3;
no-labels;
no-label-1-exp;
payload {
ether-pseudowire;
ip {
layer-3-only;
port-data {
source-msb;
source-lsb;
destination-msb;
destination-lsb;
}
}
}
}

Hierarchy Level [edit forwarding-options hash-key]

Release Information Statement introduced before Junos OS Release 7.4.

no-label-1-exp option introduced in Junos OS Release 8.0.
label-3 and no-labels options introduced in Junos OS Release 8.1.
ether-pseudowire statement introduced in Junos OS Release 9.1 (M320 and T Series
routers only); support extended to M120 and MX Series routers in Junos OS Release 9.4.

Description For aggregated Ethernet and SONET/SDH interfaces only, configure load balancing
based on MPLS labels and payload. Only the IPv4 protocol is supported.

Options label-1—Use this to include the first MPLS label in the hash key. Used for one-label packet.

label-2—Use this to include the second MPLS label in the hash key. Configure this when
you want to include the second MPLS label in the hash key. If both label-1 and label-2
are specified, the entire first label and the first 16 bits of the second label are hashed.

label-3—Use this to include the third MPLS label in the hash key. You must configure the
label-1, label-2, and label-3 statements in order to include the third label.

no-labels—Use this to omit MPLS labels from the hash key.

no-label-1-exp—Use this to omit the EXP bit of the first label from the hash calculation.
Use this to avoid complications from reordering.

payload—Use this to incorporate bits from the IP payload in the hash key.

ether-pseudowire (M120, M320, MX Series, and T Series routers)—Load-balance IPv4

traffic over Layer 2 Ethernet pseudowires.

Copyright © 2012, Juniper Networks, Inc. 303

Junos OS 12.1 MPLS Applications Configuration Guide

ip—Use this to include the IP address of the IPv4 or IPv6 payload in the hash key.

layer-3-only—Use this to include only Layer 3 IP information from the IP payload data.

port-data—Use this to include the source and destination port field information. By default,
the most significant byte and least significant byte of the source and destination
port fields are hashed. To select specific bytes to be hashed, include one or more of
the source-msb, source-lsb, destination-msb, and destination-lsb options at the [edit
forwarding-options hash-key family mpls payload ip port-data] hierarchy level. To
prevent all four bytes from being hashed, include the layer-3-only statement at the
[edit forwarding-options hash-key family mpls payload ip] hierarchy level.

destination-lsb—Use this to include the least significant byte of the destination port.

destination-msb—Use this to include the most significant byte of the destination port.

source-lsb—Use this to include the least significant byte of the source port.

source-msb—Use this to include the most significant byte of the source port.

Required Privilege interface—To view this statement in the configuration.

Level interface-control—To add this statement to the configuration.

Related • Configuring Load Balancing Based on MPLS Labels on page 158

Documentation
• Configuring Load Balancing for Ethernet Pseudowires

fast-reroute

Syntax fast-reroute {
(bandwidth bps | bandwidth-percent percentage);
(exclude [ group-names ] | no-exclude );
hop-limit number;
(include-all [ group-names ] | no-include-all);
(include-any [ group-names ] | no-include-any);
}

Hierarchy Level [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name],

[edit protocols mpls label-switched-path lsp-name]

Release Information Statement introduced before Junos OS Release 7.4.

Description Establish detours for the LSP so that if a node or link in the LSP fails, the traffic on the
LSP can be rerouted with minimal packet loss.

Options The statements are explained separately.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring Fast Reroute on page 152

Documentation

304 Copyright © 2012, Juniper Networks, Inc.

 Chapter 10: Summary of MPLS Configuration Statements

fate-sharing

Syntax fate-sharing {
group group-name {
cost value;
from address <to address>;
}
}

Hierarchy Level [edit logical-systems logical-system-name routing-options],

[edit logical-systems logical-system-name routing-instances routing-instance-name
routing-options],
[edit routing-options],
[edit routing-instances routing-instance-name routing-options]

Release Information Statement introduced before Junos OS Release 7.4.

Statement introduced in Junos OS Release 11.3 for the QFX Series.

Description Specify groups of objects that share characteristics resulting in backup paths to be used
if primary paths fail. All objects are treated as /32 host addresses. You specify one or
more objects within a group. The objects can be LAN interfaces, router IDs, or
point-to-point links. The sequence is insignificant.

Options cost value—Cost assigned to the group.

Range: 1 through 65,535
Default: 1

from address—Address of the router or address of the LAN/NBMA interface. For example,
an Ethernet network with four hosts in the same fate-sharing group would require
you to list all four of the separate from addresses in the group.

group group-name—Each fate-sharing group must have a name, which can have a
maximum of 32 characters, including letters, numbers, periods (.), and hyphens (-).
You can define up to 512 groups.

to address—(Optional) Address of egress router. For point-to-point link objects, you must
specify both a from and a to address.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring Alternate Backup Paths Using Fate Sharing on page 58

Documentation

Copyright © 2012, Juniper Networks, Inc. 305

Junos OS 12.1 MPLS Applications Configuration Guide

from

Syntax from address;

Hierarchy Level [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name],

[edit protocols mpls label-switched-path lsp-name]

Release Information Statement introduced before Junos OS Release 7.4.

Description Specify the source address to use for the LSP.

The address you specify does not affect the outgoing interface used by the LSP.

Default If you do not include this statement, the software automatically selects the loopback
interface as the address.

Options address—IP address.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring the Ingress Router Address for LSPs on page 147
Documentation

306 Copyright © 2012, Juniper Networks, Inc.

 Chapter 10: Summary of MPLS Configuration Statements

gpid

Syntax gpid (ethernet | hdlc | ipv4 | pos-scrambling-crc-16 | pos-no-scrambling-crc-16 |

pos-scrambling-crc-32 | pos-no-scrambling-crc-32 | ppp);

Hierarchy Level [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name

lsp-attributes],
[edit protocols mpls label-switched-path lsp-name lsp-attributes]

Release Information Statement introduced before Junos OS Release 7.4.

pos-scrambling-crc-16, pos-no-scrambling-crc-16, pos-scrambling-crc-32, and
pos-no-scrambling-crc-32 options added in Junos OS Release 8.0.

Description Specify the type of payload carried by the LSP. It can be any of the following:

• ethernet—Ethernet (GPID value: 33)

• hdlc—High-level Data Link Control (HDLC) (GPID value: 44)

• ipv4—IP version 4 (GPID value: 0x0800)

• pos-no-scrambling-crc-16—for interoperability with other vendors’ equipment (GPID

value: 29)

• pos-no-scrambling-crc-32—for interoperability with other vendors’ equipment (GPID

value: 30)

• pos-scrambling-crc-16—for interoperability with other vendors’ equipment (GPID value:

31)

• pos-scrambling-crc-32—for interoperability with other vendors’ equipment (GPID value:

32)

• ppp—Point-to-Point Protocol (PPP) (GPID value: 50)

Default ipv4

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring the GPID on page 596

Documentation

Copyright © 2012, Juniper Networks, Inc. 307

Junos OS 12.1 MPLS Applications Configuration Guide

hop-limit

Syntax hop-limit number;

Hierarchy Level [edit logical-systems logical-system-name protocols mpls],

[edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name],
[edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name
fast-reroute],
[edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name
(primary | secondary) path-name],
[edit protocols mpls],
[edit protocols mpls label-switched-path lsp-name],
[edit protocols mpls label-switched-path lsp-name fast-reroute],
[edit protocols mpls label-switched-path lsp-name (primary | secondary) path-name]

Release Information Statement introduced before Junos OS Release 7.4.

Description For an LSP, specify the maximum number of routers that the LSP can traverse, including
the ingress and egress routers.

For fast reroute, how many more routers a detour is allowed to traverse compared with
the LSP itself. For example, if an LSP traverses 4 routers, any detour for the LSP can be
no more than 10 router hops, including the ingress and egress routers.

Options number—Maximum number of hops.

Range: 2 through 255 (for an LSP); 0 through 255 (for fast reroute)
Default: 255 (for an LSP); 6 (for fast reroute)

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring Fast Reroute on page 152

Documentation
• Limiting the Number of Hops in LSPs on page 184

308 Copyright © 2012, Juniper Networks, Inc.

 Chapter 10: Summary of MPLS Configuration Statements

icmp-tunneling

Syntax icmp-tunneling;

Hierarchy Level [edit logical-systems logical-system-name protocols mpls],

[edit protocols mpls]

Release Information Statement introduced before Junos OS Release 7.4.

Description Enable ICMP message tunneling for MPLS LSPs. This feature helps you to trace the route
path and debug LSPs.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring ICMP Message Tunneling for MPLS on page 76

Documentation

Copyright © 2012, Juniper Networks, Inc. 309

Junos OS 12.1 MPLS Applications Configuration Guide

include-all

See the following sections:

• include-all (for Administrative Groups) on page 310

• include-all (for Fast Reroute) on page 311

include-all (for Administrative Groups)

Syntax include-all [ group-names ];

Hierarchy Level [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name

admin-group],
[edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name
(primary | secondary) path-name admin-group],
[edit protocols mpls label-switched-path lsp-name admin-group],
[edit protocols mpls label-switched-path lsp-name (primary | secondary) path-name
admin-group]

Release Information Statement introduced before Junos OS Release 7.4.

Description Require the LSP to traverse links that include all of the defined administrative groups.

Options group-names—One or more names of groups defined with the admin-groups statement.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring Administrative Groups on page 171

Documentation
• admin-groups on page 279

310 Copyright © 2012, Juniper Networks, Inc.

 Chapter 10: Summary of MPLS Configuration Statements

include-all (for Fast Reroute)

Syntax (include-all [ group-names ] | no-include-all);

Hierarchy Level [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name

fast-reroute],
[edit protocols mpls label-switched-path lsp-name fast-reroute]

Release Information Statement introduced before Junos OS Release 7.4.

Description Control inclusion of administrative groups:

• include-all—Define the administrative groups that must all be included for fast reroute.

• no-include-all—Disable administrative group inclusion.

Options group-names—One or more names of groups defined with the admin-groups statement.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring Fast Reroute on page 152

Documentation

Copyright © 2012, Juniper Networks, Inc. 311

Junos OS 12.1 MPLS Applications Configuration Guide

include-any

See the following sections:

• include-any (for Administrative Groups) on page 312

• include-any (for Fast Reroute) on page 313

include-any (for Administrative Groups)

Syntax include-any [ group-names ];

Hierarchy Level [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name

admin-group],
[edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name
(primary | secondary) path-name admin-group],
[edit protocols mpls label-switched-path lsp-name admin-group],
[edit protocols mpls label-switched-path lsp-name (primary | secondary) path-name
admin-group]

Release Information Statement introduced before Junos OS Release 7.4.

Description Define the administrative groups to include for an LSP or for a path’s primary and
secondary paths.

Options group-names—One or more names of groups defined with the admin-groups statement.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring Administrative Groups on page 171

Documentation

312 Copyright © 2012, Juniper Networks, Inc.

 Chapter 10: Summary of MPLS Configuration Statements

include-any (for Fast Reroute)

Syntax (include-any [ group-names ] | no-include-any);

Hierarchy Level [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name

fast-reroute],
[edit protocols mpls label-switched-path lsp-name fast-reroute]

Release Information Statement introduced before Junos OS Release 7.4.

Description Control inclusion of administrative groups:

• include-any—Define the administrative groups to include for fast reroute.

• no-include-any—Disable administrative group inclusion.

Options group-names—One or more names of groups defined with the admin-groups statement.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring Fast Reroute on page 152

Documentation

Copyright © 2012, Juniper Networks, Inc. 313

Junos OS 12.1 MPLS Applications Configuration Guide

ingress

Syntax ingress {
bandwidth bps;
class-of-service cos-value;
description string;
install {
destination-prefix <active>;
}
link-protection bypass-name name;
metric metric;
next-hop (address | interface-name | address/interface-name);
node-protection bypass-name name next-next-label label;
no-install-to-address;
policing {
filter filter-name;
no-auto-policing;
}
preference preference;
push out-label;
to address;
}

Hierarchy Level [edit logical-systems logical-system-name protocols mpls static-label-switched-path

lsp-name],
[edit protocols mpls static-label-switched-path lsp-name]

Release Information Statement introduced in Junos OS Release 10.1.

Description Configure an ingress LSR for a static LSP.

The remaining statements are explained separately

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring Static LSPs on page 211

Documentation

314 Copyright © 2012, Juniper Networks, Inc.

 Chapter 10: Summary of MPLS Configuration Statements

install

Syntax install {
destination-prefix <active>;
}

Hierarchy Level [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name],

[edit logical-systems logical-system-name protocols mpls static-label-switched-path
lsp-name ingress],
[edit protocols mpls label-switched-path lsp-name],
[edit protocols mpls static-label-switched-path lsp-name ingress]

Release Information Statement introduced before Junos OS Release 7.4.

Description Associate one or more prefixes with an LSP. When the LSP is up, all the prefixes are
installed as entries into the inet.3 routing table.

Options active—(Optional) Install the route into the inet.0 routing table. This allows you to issue
a ping or traceroute command on this address.

destination-prefix—Address to associate with the LSP.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Adding LSP-Related Routes to the inet.3 Routing Table on page 154
Documentation

Copyright © 2012, Juniper Networks, Inc. 315

Junos OS 12.1 MPLS Applications Configuration Guide

interface

Syntax interface (interface-name | all) {

disable;
admin-group [ group-names ];
srlg srlg-name;
}

Hierarchy Level [edit logical-systems logical-system-name protocols mpls],

[edit protocols mpls]

Release Information Statement introduced before Junos OS Release 7.4.

Description Enable MPLS on one or more interfaces.

Options interface-name—Name of the interface on which to configure MPLS. To configure all

interfaces, specify all. For details about specifying interfaces, see the Junos OS Network
Interfaces Configuration Guide.

srlg srlg-name—Name of the SRLG to associate with an interface.

The remaining options are explained separately.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring the Intermediate (Transit) and Egress Routers for Static LSPs on page 214
Documentation
• Example: Configuring SRLG on page 76

ipv6-tunneling

Syntax ipv6-tunneling;

Hierarchy Level [edit logical-systems logical-system-name protocols mpls],

[edit protocols mpls]

Release Information Statement introduced before Junos OS Release 7.4.

Description Allow IPv6 routes to be resolved over an MPLS network by converting all routes stored
in the inet.3 routing table to IPv4-mapped IPv6 addresses and then copying them into
the inet6.3 routing table. This routing table can be used to resolve next hops for both
inet6 and inet6-vpn routes.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Example: Tunneling IPv6 Traffic over MPLS IPv4 Networks on page 67
Documentation

316 Copyright © 2012, Juniper Networks, Inc.

 Chapter 10: Summary of MPLS Configuration Statements

label-switched-path

Syntax label-switched-path lsp-name {

disable;
adaptive;
admin-down;
admin-group {
exclude [ group-names ];
include-all [ group-names ];
include-any [ group-names ];
}
auto-bandwidth {
adjust-interval seconds;
adjust-threshold percentage;
maximum-bandwidth bps;
minimum-bandwidth bps;
monitor-bandwidth;
}
bandwidth bps {
ct0 bps;
ct1 bps;
ct2 bps;
ct3 bps;
}
class-of-service cos-value;
description text;
fast-reroute {
(bandwidth bps | bandwidth-percent percentage);
(exclude [ group-names ] | no-exclude);
hop-limit number;
(include-all [ group-names ] | no-include-all);
(include-any [ group-names ] | no-include-any);
}
from address;
install {
destination-prefix/prefix-length <active>;
}
ldp-tunneling;
link-protection;
lsp-attributes {
encoding-type (ethernet | packet | pdh | sonet-sdh);
gpid (ethernet | hdlc | ipv4 | pos-scrambling-crc-16 | pos-no-scrambling-crc-16 |
pos-scrambling-crc-32 | pos-no-scrambling-crc-32 | ppp);
signal-bandwidth type;
switching-type (fiber | lambda | psc-1 | tdm);
}
metric metric;
no-cspf;
no-decrement-ttl;
node-link-protection;
optimize-timer seconds;
p2mp lsp-name;
policing {
filter filter-name;

Copyright © 2012, Juniper Networks, Inc. 317

Junos OS 12.1 MPLS Applications Configuration Guide

no-auto-policing;
}
preference preference;
primary path-name {
adaptive;
admin-group {
exclude [ group-names ];
include-all [ group-names ];
include-any [ group-names ];
}
bandwidth bps {
ct0 bps;
ct1 bps;
ct2 bps;
ct3 bps;
}
class-of-service cos-value;
hop-limit number;
no-cspf;
no-decrement-ttl;
optimize-timer seconds;
preference preference;
priority setup-priority reservation-priority;
(record | no-record);
select (manual | unconditional);
standby;
}
priority setup-priority reservation-priority;
(random | least-fill | most-fill);
(record | no-record);
retry-limit number;
retry-timer seconds;
revert-timer seconds;
secondary path-name {
adaptive;
admin-group {
exclude[ group-names ];
include-all [ group-names ];
include-any [ group-names ];
}
bandwidth bps {
ct0 bps;
ct1 bps;
ct2 bps;
ct3 bps;
}
class-of-service cos-value;
hop-limit number;
no-cspf;
no-decrement-ttl;
optimize-timer seconds;
preference preference;
priority setup-priority reservation-priority;
(record | no-record);
select (manual | unconditional);
standby;

318 Copyright © 2012, Juniper Networks, Inc.

 Chapter 10: Summary of MPLS Configuration Statements

}
soft-preemption;
standby;
to address;
traceoptions {
file filename <files number> <size size> <world-readable | no-world-readable>;
flag flag <flag-modifier> <disable>;
}
}

Hierarchy Level [edit logical-systems logical-system-name protocols mpls],

[edit protocols mpls]

Release Information Statement introduced before Junos OS Release 7.4.

Description Configure an LSP to use in dynamic MPLS. When configuring an LSP, you must specify
the address of the egress router in the to statement. All remaining statements are optional.

Options lsp-name—Name that identifies the LSP. The name can be up to 64 characters and can
contain letters, digits, periods, and hyphens. To include other characters, enclose
the name in quotation marks. The name must be unique within the ingress router.

The remaining statements are explained separately.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Minimum MPLS Configuration on page 55

Documentation
• LSP Configuration Overview on page 144

ldp-tunneling

Syntax ldp-tunneling;

Hierarchy Level [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name],

[edit protocols mpls label-switched-path lsp-name]

Release Information Statement introduced before Junos OS Release 7.4.

Description Enable the LSP to be used for LDP tunneling.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Enabling LDP over RSVP-Established LSPs on page 497

Documentation

least-fill

See random

Copyright © 2012, Juniper Networks, Inc. 319

Junos OS 12.1 MPLS Applications Configuration Guide

link-protection

See the following sections:

• link-protection (Dynamic LSPs) on page 320

• link-protection (Static LSPs) on page 321

link-protection (Dynamic LSPs)

Syntax link-protection;

Hierarchy Level [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name],

[edit protocols mpls label-switched-path lsp-name]

Release Information Statement introduced before Junos OS Release 7.4.

Description Enable link protection on the specified LSP, which helps to ensure that traffic sent over
a specific interface to a neighboring router can continue to reach the router if that interface
fails. For point-to-multipoint LSPs, including this statement extends link protection to
all of the paths used by the LSP.

To fully enable link protection, you must also include the link-protection statement at
the [edit protocols rsvp interface interface-name] or [edit
logical-systems logical-system-name protocols rsvp interface interface-name] hierarchy
level.

Default Link protection is disabled.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring Link Protection for Point-to-Multipoint LSPs on page 223

Documentation
• Configuring Node Protection or Link Protection for LSPs on page 402

• link-protection (RSVP) on page 439

320 Copyright © 2012, Juniper Networks, Inc.

 Chapter 10: Summary of MPLS Configuration Statements

link-protection (Static LSPs)

Syntax link-protection bypass-name name;

Hierarchy Level [edit logical-systems logical-system-name protocols mpls

static-label-switched-path lsp-name ingress],
[edit logical-systems logical-system-name protocols mpls
static-label-switched-path lsp-name transit incoming-label],
[edit protocols mpls static-label-switched-path lsp-name ingress],
[edit protocols mpls static-label-switched-path lsp-name transit incoming-label]

Release Information Statement introduced in Junos OS Release 10.1.

Description Enable link protection on the specified static LSP. Link protection helps to ensure that
traffic sent over a specific interface to a neighboring router can continue to reach the
router if that interface fails.

Default Link protection is disabled.

Options bypass-name name—Bypass LSP name.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring Static LSPs on page 211

Documentation
• Example: Configuring Point-to-Multipoint LSPs with Static Routes

Copyright © 2012, Juniper Networks, Inc. 321

Junos OS 12.1 MPLS Applications Configuration Guide

log-updown

Syntax log-updown {
no-trap {
mpls-lsp-traps;
rfc3812-traps;
}
(syslog | no-syslog);
trap;
trap-path-down;
trap-path-up;
}

Hierarchy Level [edit logical-systems logical-system-name protocols mpls],

[edit protocols mpls]

Release Information Statement introduced before Junos OS Release 7.4.

The mpls-lsp-traps and rfc-3812-traps options added in Junos OS Release 9.0.

Description Log a message or send an SNMP trap whenever an LSP makes a transition from up to
down, or vice versa, and whenever an LSP switches from one active path to another. Only
the ingress router performs these operations.

Default There is no default behavior for this statement. If you do not specify the options, the
configuration cannot be committed.

Options no-syslog—Do not log a message to the system log file.

no-trap—Do not send an SNMP trap.

syslog—Log a message to the system log file.

trap—Send an SNMP trap.

trap-path-down—Send an SNMP trap when an LSP path goes down.

trap-path-up—Send an SNMP trap when an LSP path comes up.

The no-trap statement is explained separately.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring System Log Messages and SNMP Traps for LSPs on page 257
Documentation
• Junos OS Network Management Configuration Guide

• no-trap on page 334

• traceoptions on page 368

322 Copyright © 2012, Juniper Networks, Inc.

 Chapter 10: Summary of MPLS Configuration Statements

lsp-attributes

Syntax lsp-attributes {
encoding-type (ethernet | packet | pdh | sonet-sdh);
gpid (ethernet | hdlc | ipv4 | pos-scrambling-crc-16 | pos-no-scrambling-crc-16 |
pos-scrambling-crc-32 | pos-no-scrambling-crc-32 | ppp);
signal-bandwidth type;
switching-type (fiber | lambda | psc-1 | tdm);
}

Hierarchy Level [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name],

[edit protocols mpls label-switched-path lsp-name]

Release Information Statement introduced before Junos OS Release 7.4.

pos-scrambling-crc-16, pos-no-scrambling-crc-16, pos-scrambling-crc-32, and
pos-no-scrambling-crc-32 options added in Junos OS Release 8.0.

Description Define the parameters signaled during LSP setup. These usually determine the nature
of the resource (label) allocated for the LSP.

The options are explained separately.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring MPLS LSPs for GMPLS on page 595

Documentation

maximum-bandwidth

Syntax maximum-bandwidth bps;

Hierarchy Level [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name

auto-bandwidth],
[edit protocols mpls label-switched-path lsp-name auto-bandwidth]

Release Information Statement introduced before Junos OS Release 7.4.

Description Specify the maximum amount of bandwidth in bits per second (bps).

Options bps—Maximum amount of bandwidth.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring the Maximum and Minimum Bounds of the LSP’s Bandwidth on page 166
Documentation

Copyright © 2012, Juniper Networks, Inc. 323

Junos OS 12.1 MPLS Applications Configuration Guide

maximum-labels

Syntax maximum-labels maximum-labels;

Hierarchy Level [edit interfaces interface-name unit logical-unit-number family mpls],

[edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number
family mpls]

Release Information Statement introduced in Junos OS Release 10.1.

Description On the logical interface, specify the maximum number of MPLS labels upon which MPLS
can operate.

You can configure this statement on the following routers:

• MX Series 3D Universal Edge Router

• M120 Multiservice Edge Router

• M320 Multiservice Edge Router with Enhanced III FPCs

• M7i Multiservice Edge Router and M10i Multiservice Edge Router with Enhanced
Compact Forwarding Engine Board (CFEB-E)

• T640, T1600, TX Matrix, and TX Matrix Plus routers with Enhanced Scaling FPC1,
Enhanced Scaling FP2, Enhanced Scaling FPC3, and Enhanced Scaling FPC4

Options maximum-labels—Maximum number of labels.

Range: 3 through 5
Default: 3

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring the Maximum Number of MPLS Labels on page 247

Documentation
• Junos OS VPNs Configuration Guide

324 Copyright © 2012, Juniper Networks, Inc.

 Chapter 10: Summary of MPLS Configuration Statements

metric

Syntax metric metric;

Hierarchy Level [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name],

[edit logical-systems logical-system-name protocols mpls
static-label-switched-path lsp-name ingress],
[edit protocols mpls label-switched-path lsp-name],
[edit protocols mpls static-label-switched-path lsp-name ingress]

Release Information Statement introduced before Junos OS Release 7.4.

Description Compare against another LSP or against an IGP route. To disable dynamic metric tracking,
assign a fixed metric value to an LSP. If no metric is assigned, the LSP metric is dynamic
and automatically tracks underlying IGP metrics.

Options metric—LSP metric value.

Default: No metric assigned (dynamic)
Range: 1 through 16,777,215

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring Static LSP Metrics on page 156

Documentation

minimum-bandwidth

Syntax minimum-bandwidth bps;

Hierarchy Level [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name

auto-bandwidth],
[edit protocols mpls label-switched-path lsp-name auto-bandwidth]

Release Information Statement introduced before Junos OS Release 7.4.

Description Set the minimum bandwidth in bps for an LSP with automatic bandwidth allocation
enabled.

Options bps—Miniminum bandwidth for the LSP.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring the Maximum and Minimum Bounds of the LSP’s Bandwidth on page 166
Documentation

Copyright © 2012, Juniper Networks, Inc. 325

Junos OS 12.1 MPLS Applications Configuration Guide

monitor-bandwidth

Syntax monitor-bandwidth;

Hierarchy Level [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name

auto-bandwidth],
[edit protocols mpls label-switched-path lsp-name auto-bandwidth]

Release Information Statement introduced before Junos OS Release 7.4.

Description Do not automatically adjust bandwidth allocation. However, the maximum average
bandwidth utilization is monitored on the LSP, and the information is recorded in the
MPLS statistics file.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring Passive Bandwidth Utilization Monitoring on page 169

Documentation

most-fill

See random

mpls

Syntax mpls { ... }

Hierarchy Level [edit logical-systems logical-system-name protocols],

[edit protocols]

Release Information Statement introduced before Junos OS Release 7.4.

Description Enable MPLS on the router.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Minimum MPLS Configuration on page 55

Documentation

326 Copyright © 2012, Juniper Networks, Inc.

 Chapter 10: Summary of MPLS Configuration Statements

mpls-tp-mode

Syntax mpls-tp-mode;

Hierarchy Level [edit protocols mpls label-switched-path lsp-name oam],

[edit protocols mpls oam]

Release Information Statement introduced in Junos OS Release 12.1.

Description Enable GAL or G-Ach OAM operation without IP encapsulation on a label-switched path
(LSP).

Include this statement at the [edit protocols mpls oam] hierarchy level to enable GAL or
G-Ach OAM operation without IP encapsulation on all LSPs in the MPLS network. Include
this statement at the [edit protocols mpls label-switched-path lsp-name oam] hierarchy
level to enable GAL and G-Ach OAM operation without IP encapsulation on a specific
LSP.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Example: Configuring the MPLS Transport Profile for OAM on page 130
Documentation

mtu-signaling

Syntax mtu-signaling;

Hierarchy Level [edit logical-systems logical-system-name protocols mpls path-mtu rsvp],

[edit protocols mpls path-mtu rsvp]

Release Information Statement introduced before Junos OS Release 7.4.

Description Enable MTU signaling in RSVP.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Enabling MTU Signaling in RSVP on page 418

Documentation

Copyright © 2012, Juniper Networks, Inc. 327

Junos OS 12.1 MPLS Applications Configuration Guide

next-hop

Syntax next-hop (address | interface-name | address/interface-name);

Hierarchy Level [edit logical-systems logical-system-name protocols mpls

static-label-switched-path lsp-name bypass],
[edit logical-systems logical-system-name protocols mpls
static-label-switched-path lsp-name ingress],
[edit logical-systems logical-system-name protocols mpls
static-label-switched-path lsp-name transit incoming-label],
[edit protocols mpls static-label-switched-path lsp-name bypass],
[edit protocols mpls static-label-switched-path lsp-name ingress],
[edit protocols mpls static-label-switched-path lsp-name transit incoming-label]

Release Information Statement introduced before Junos OS Release 7.4.

Description IP address of the next hop to the destination, specified as the IP address of the next hop,
the interface name (for point-to-point interfaces only), or the address/interface-name to
specify an IP address on an operational interface.

Options address—IP address of the next-hop router.

interface-name—IP address of the outgoing interface. It must be a point-to-point interface.

The name can be a simple or fully qualified domain name.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring the Ingress Router for Static LSPs on page 211
Documentation
• Configuring the Intermediate (Transit) and Egress Routers for Static LSPs on page 214

328 Copyright © 2012, Juniper Networks, Inc.

 Chapter 10: Summary of MPLS Configuration Statements

no-cspf

Syntax no-cspf;

Hierarchy Level [edit logical-systems logical-system-name protocols mpls],

[edit logical-systems logical-system-name protocols mplslabel-switched-path lsp-name],
[edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name
(primary | secondary) path-name],
[edit protocols mpls],
[edit protocols mpls label-switched-path lsp-name],
[edit protocols mpls label-switched-path lsp-name (primary | secondary) path-name]

Release Information Statement introduced before Junos OS Release 7.4.

Description Disable constrained-path LSP computation.

An explicit-path LSP is completely configured through operator action. Once configured,

it is initiated only along the explicitly specified path.

A constrained-path LSP relies on an ingress router to compute the complete path. The
ingress router takes into account the following information during the computation:

• Interior gateway protocol (IGP) topology database

• Link utilization information from extensions in the IGP link-state database

• Administrative group information from extensions in the IGP link-state database

• LSP requirements, including bandwidth, hop count, and administrative group

Constrained-path LSPs can generally avoid link failures and congested links. They also
permit recomputation (therefore, a new path) during topology changes or unsuccessful
setup.

Default Constrained-path LSP computation enabled.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Disabling Constrained-Path LSP Computation on page 170

Documentation
• Configuring Explicit-Path LSPs on page 218

Copyright © 2012, Juniper Networks, Inc. 329

Junos OS 12.1 MPLS Applications Configuration Guide

no-decrement-ttl

Syntax no-decrement-ttl;

Hierarchy Level [edit logical-systems logical-system-name protocols mpls],

[edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name],
[edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name
(primary | secondary) path-name],
[edit protocols mpls],
[edit protocols mpls label-switched-path lsp-name],
[edit protocols mpls label-switched-path lsp-name (primary | secondary) path-name]

Release Information Statement introduced before Junos OS Release 7.4.

Description Disable normal time-to-live (TTL) decrementing, which decrements the TTL field in the
IP header by 1. This statement decrements the IP TTL by 1 before encapsulating the IP
packet within an MPLS packet. When the penultimate router pops off the top label, it
does not use the standard write-back procedure of writing the MPLS TTL into the IP TTL
field. Therefore, the IP packet is decremented by 1. The ultimate router then decrements
the packet by one more for a total cloud appearance of 2, thus hiding the network
topology.

Default Normal TTL decrementing enabled; the TTL field value is decremented by 1 as the packet
passes through each label-switched router in the LSP.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Disabling Normal TTL Decrementing on page 161

Documentation
• no-propagate-ttl on page 333

no-exclude

See exclude (for Fast Reroute)

no-include-all

See include-all (for Fast Reroute)

no-include-any

See include-any (for Fast Reroute)

330 Copyright © 2012, Juniper Networks, Inc.

 Chapter 10: Summary of MPLS Configuration Statements

no-mcast-replication

Syntax no-mcast-replication;

Hierarchy Level [edit chassis fpc slot-number pic pic-number],

[edit chassis lcc number fpc slot-number pic pic-number]

Release Information Statement introduced in Junos OS Release 11.3.

Description For point-to-multipoint LSPs configured on T Series routers, protect the Packet Forwarding
Engine (PFE) from bandwidth saturation. When a PFE does not need to replicate traffic,
the PFE’s bandwidth is less likely to become saturated. When you include the
no-mcast-replication statement, the PFE is forced to be a leaf node in the binary tree.
Leaf nodes, unlike branch nodes, do not replicate traffic in the process of forwarding
traffic. Because leaf nodes have no children, they do not need to replicate traffic, and
thus are less likely to become saturated with traffic.

Default If you omit the no-mcast-replication statement, the PFE can become a branch node or
a leaf node. When the PFE becomes a branch node, the PFE must replicate traffic.

Required Privilege interface—To view this statement in the configuration.

Level interface-control—To add this statement to the configuration.

Related • Point-to-Multipoint LSPs Overview on page 52

Documentation

no-install-to-address

Syntax no-install-to-address;

Hierarchy Level [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name],

[edit logical-systems logical-system-name protocols mpls
static-label-switched-path lsp-name ingress],
[edit protocols mpls label-switched-path lsp-name],
[edit protocols mpls static-label-switched-path lsp-name ingress]

Release Information Statement introduced in Junos OS Release 7.4.

Description Prevent the egress router address configured using the to statement from being installed
into the inet.3 and inet.0 routing tables.

Default The egress router address for an LSP is installed into the inet.3 and inet.0 routing tables.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Preventing the Addition of Egress Router Addresses to Routing Tables on page 148
Documentation
• to on page 367

Copyright © 2012, Juniper Networks, Inc. 331

Junos OS 12.1 MPLS Applications Configuration Guide

node-protection (Static LSP)

Syntax node-protection bypass-name name next-next-label label;

Hierarchy Level [edit logical-systems logical-system-name protocols mpls

static-label-switched-path lsp-name ingress],
[edit logical-systems logical-system-name protocols mpls
static-label-switched-path lsp-name transit incoming-label],
[edit protocols mpls static-label-switched-path lsp-name ingress],
[edit protocols mpls static-label-switched-path lsp-name transit incoming-label]

Release Information Statement introduced in JUNOS Release 10.1.

Description Enable node protection on the specified static bypass LSP. Node protection ensures that
traffic from an LSP traversing a neighboring router can continue to reach its destination
even if the neighboring router fails.

Default Node protection is disabled.

Options bypass-name name—Bypass LSP name.

next-next-label label—Bypass LSP name.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring Static LSPs on page 211

Documentation

332 Copyright © 2012, Juniper Networks, Inc.

 Chapter 10: Summary of MPLS Configuration Statements

no-propagate-ttl

Syntax no-propagate-ttl;

Hierarchy Level [edit logical-systems logical-system-name protocols mpls],

[edit protocols mpls]

Release Information Statement introduced before Junos OS Release 7.4.

Description Disable normal time-to-live (TTL) decrementing. You configure this statement once per
router, and it affects all RSVP-signaled or LDP-signaled LSPs. When this router acts as
an ingress router for an LSP, it pushes an MPLS header with a TTL value of 255, regardless
of the IP packet TTL. When the router acts as the penultimate router, it pops the MPLS
header without writing the MPLS TTL into the IP packet.

Default Normal TTL decrementing enabled; the TTL field value is decremented by 1 as the packet
passes through each label-switched router in the LSP.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Disabling Normal TTL Decrementing on page 161

Documentation
• Example: Disabling Normal TTL Decrementing in a VRF Routing Instance (on Layer 3
VPNs Configuration Guide or in the Junos VPNs Configuration Guide)

• no-decrement-ttl on page 330

no-record

See record

Copyright © 2012, Juniper Networks, Inc. 333

Junos OS 12.1 MPLS Applications Configuration Guide

no-trap

Syntax no-trap {
mpls-lsp-traps;
rfc-3812-traps;
}

Hierarchy Level [edit logical-systems logical-system-name protocols mpls log-updown],

[edit protocols mpls log-updown]

Release Information Statement introduced before Junos OS Release 7.4.

The mpls-lsp-traps and rfc-3812-traps options added in Junos OS Release 9.0.

Description Prevent the transmission of SNMP traps.

Options mpls-lsp-traps—Block the MPLS LSP traps defined in the jnx-mpls.mib, but allows the
rfc3812.mib traps.

rfc-3812-traps—Block the traps defined in the rfc3812.mib, but allows the MPLS LSP traps
defined in the jnx-mpls.mib.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring System Log Messages and SNMP Traps for LSPs on page 257
Documentation
• Junos OS Network Management Configuration Guide

• traceoptions on page 368

334 Copyright © 2012, Juniper Networks, Inc.

 Chapter 10: Summary of MPLS Configuration Statements

node-protection (Static LSP)

Syntax node-protection bypass-name name next-next-label label;

Hierarchy Level [edit logical-systems logical-system-name protocols mpls

static-label-switched-path lsp-name ingress],
[edit logical-systems logical-system-name protocols mpls
static-label-switched-path lsp-name transit incoming-label],
[edit protocols mpls static-label-switched-path lsp-name ingress],
[edit protocols mpls static-label-switched-path lsp-name transit incoming-label]

Release Information Statement introduced in JUNOS Release 10.1.

Description Enable node protection on the specified static bypass LSP. Node protection ensures that
traffic from an LSP traversing a neighboring router can continue to reach its destination
even if the neighboring router fails.

Default Node protection is disabled.

Options bypass-name name—Bypass LSP name.

next-next-label label—Bypass LSP name.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring Static LSPs on page 211

Documentation

Copyright © 2012, Juniper Networks, Inc. 335

Junos OS 12.1 MPLS Applications Configuration Guide

oam

Syntax oam {
bfd-liveness-detection{
failure-action teardown;
minimum-interval milliseconds;
minimum-receive-interval milliseconds;
minimum-transmit-interval milliseconds;
multiplier detection-time-multiplier;
}
lsp-ping-interval seconds;
}

Hierarchy Level [edit protocols mpls],

[edit protocols mpls label-switched-path lsp-name]
[edit protocols mpls label-switched-path lsp-name primary path-name]

Release Information Statement introduced in Junos OS Release 7.6.

lsp-ping-interval option introduced in Junos OS Release 9.4.

Description Enable Operation, Administration, and Maintenance (OAM) for RSVP-signaled LSPs.

Options lsp-ping-interval seconds—Specify the duration of the LSP ping interval in seconds. To
issue a ping on an RSVP-signaled LSP, use the ping mpls rsvp command.

The remaining statements are explained separately.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring BFD for MPLS IPv4 LSPs on page 267

Documentation

336 Copyright © 2012, Juniper Networks, Inc.

 Chapter 10: Summary of MPLS Configuration Statements

optimize-aggressive

Syntax optimize-aggressive;

Hierarchy Level [edit logical-systems logical-system-name protocols mpls],

[edit protocols mpls]

Release Information Statement introduced before Junos OS Release 7.4.

Description If enabled, the LSP reoptimization is based solely on the IGP metric. The reoptimization
process ignores the available bandwidth ratio calculations, the least-fill 10 percent
congestion improvement rule, and the hop-counts rule. This statement makes
reoptimization more aggressive than the default.

Default Aggressive optimization is disabled.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Optimizing Signaled LSPs on page 180

Documentation

Copyright © 2012, Juniper Networks, Inc. 337

Junos OS 12.1 MPLS Applications Configuration Guide

optimize-timer

Syntax optimize-timer seconds;

Hierarchy Level [edit logical-systems logical-system-name protocols mpls],

[edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name],
[edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name
(primary | secondary) path-name],
[edit protocols mpls],
[edit protocols mpls label-switched-path lsp-name],
[edit protocols mpls label-switched-path lsp-name (primary | secondary) path-name]

Release Information Statement introduced before Junos OS Release 7.4.

Description Enable periodic reoptimization of an LSP that is already set up. If topology changes occur,
an existing path might become suboptimal, and a subsequent recomputation might be
able to determine a better path. This option is useful only on LSPs for which
constrained-path computation is enabled; that is, for which the no-cspf statement is not
configured.

To avoid extensive resource consumption that might result because of frequent path
recomputations, or to avoid destabilizing the network as a result of constantly changing
LSPs, we recommend that you either leave the timer value sufficiently large or disable
the timer value.

Default The optimize timer is disabled.

Options seconds—Length of the optimize timer, in seconds.

Range: 0 through 65,535 seconds
Default: 0 seconds (the optimize timer is disabled)

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Optimizing Signaled LSPs on page 180

Documentation

338 Copyright © 2012, Juniper Networks, Inc.

 Chapter 10: Summary of MPLS Configuration Statements

p2mp

Syntax p2mp p2mp-lsp-name;

Hierarchy Level [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name],

[edit protocols mpls label-switched-path lsp-name]

Release Information Statement introduced before Junos OS Release 7.4.

Description Specify an LSP as either a point-to-multipoint LSP or as a branch LSP of a

point-to-multipoint LSP by specifying the point-to-multipoint LSP path name.

Options p2mp-lsp-name—Name of the point-to-multipoint LSP path that identifies the sequence
of nodes that form the point-to-multipoint LSP. The name can contain up to 32
characters and can include letters, digits, periods, and hyphens. To include other
characters or use a longer name, enclose the name in quotation marks. The name
must be unique within the ingress router.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring the Primary Point-to-Multipoint LSP on page 222

Documentation

p2mp-lsp-next-hop

Syntax p2mp-lsp-next-hop point-to-multipoint-lsp-next-hop;

Hierarchy Level [edit logical-systems logical-system-name routing-options static route route-name],

[edit routing-options static route route-name]

Release Information Statement introduced before Junos OS Release 7.4.

Description Specify the name of the point-to-multipoint LSP to be used as a next hop for the static
route.

Options point-to-multipoint-lsp-next-hop—Name of the point-to-multipoint LSP.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring Static Unicast Routes for Point-to-Multipoint LSPs on page 217
Documentation

Copyright © 2012, Juniper Networks, Inc. 339

Junos OS 12.1 MPLS Applications Configuration Guide

path

Syntax path path-name {

(address | hostname) <strict | loose>;
}

Hierarchy Level [edit logical-systems logical-system-name protocols mpls],

[edit protocols mpls]

Release Information Statement introduced before Junos OS Release 7.4.

Description Create a named path and optionally specify the sequence of explicit routers that form
the path.

You must include this statement when configuring explicit LSPs.

Options address—IP address of each transit router in the LSP. You must specify the address or
hostname of each transit router, although you do not need to list each transit router
if its type is loose. As an option, you can include the ingress and egress routers in the
path. Specify the addresses in order, starting with the ingress router (optional) or
the first transit router, and continuing sequentially along the path until reaching the
egress router (optional) or the router immediately before the egress router.
Default: If you do not specify any routers explicitly, no routing limitations are imposed
on the LSP.

hostname—See address.
Default: If you do not specify any routers explicitly, no routing limitations are imposed
on the LSP.

loose—(Optional) Indicate that the next address in the path statement is a loose link.
This means that the LSP can traverse through other routers before reaching this
router.
Default: strict

path-name—Name that identifies the sequence of nodes that form an LSP. The name
can contain up to 32 characters and can include letters, digits, periods, and hyphens.
To include other characters or use a longer name, enclose the name in quotation
marks. The name must be unique within the ingress router.

strict—(Optional) Indicate that the LSP must go to the next address specified in the path
statement without traversing other nodes. This is the default.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Creating Named Paths on page 56

Documentation

340 Copyright © 2012, Juniper Networks, Inc.

 Chapter 10: Summary of MPLS Configuration Statements

path-mtu

Syntax path-mtu {
allow-fragmentation;
rsvp {
mtu-signaling;
}
}

Hierarchy Level [edit logical-systems logical-system-name protocols mpls],

[edit protocols mpls]

Release Information Statement introduced before Junos OS Release 7.4.

Description Configure MTU options for MPLS paths, including packet fragmentation and MTU
signaling.

The remaining statements are explained separately.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring MTU Signaling in RSVP on page 418

Documentation

policing

Syntax policing {
filter filter-name;
no-auto-policing;
}

Hierarchy Level [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name],

[edit logical-systems logical-system-name protocols mpls
static-label-switched-path lsp-name ingress],
[edit protocols mpls label-switched-path lsp-name],
[edit protocols mpls static-label-switched-path lsp-name ingress]

Release Information Statement introduced before Junos OS Release 7.4.

Description Specify the policing filter for the LSP.

Options filter filter-name—Specify the name of the policing filter.

no-auto-policing—Disable automatic policing on this LSP.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring Policers for LSPs on page 260

Documentation
• auto-policing on page 286

Copyright © 2012, Juniper Networks, Inc. 341

Junos OS 12.1 MPLS Applications Configuration Guide

pop

Syntax pop;

Hierarchy Level [edit logical-systems logical-system-name protocols mpls

static-label-switched-path lsp-name transit incoming-label],
[edit protocols mpls static-label-switched-path lsp-name transit incoming-label]

Release Information Statement introduced before Junos OS Release 7.4.

Description Remove the label from the top of the label stack. If there is another label in the stack,
that label becomes the label at the top of the label stack. Otherwise, the packet is
forwarded as a native protocol packet (typically, as an IP packet).

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring the Intermediate (Transit) and Egress Routers for Static LSPs on page 214
Documentation
• swap on page 363

342 Copyright © 2012, Juniper Networks, Inc.

 Chapter 10: Summary of MPLS Configuration Statements

preference

Syntax preference preference;

Hierarchy Level [edit logical-systems logical-system-name protocols mpls],

[edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name],
[edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name
(primary | secondary) path-name],
[edit logical-systems logical-system-name protocols mpls
static-label-switched-path lsp-name ingress],
[edit protocols mpls],
[edit protocols mpls label-switched-path lsp-name],
[edit protocols mpls label-switched-path lsp-name (primary | secondary) path-name],
[edit protocols mpls static-label-switched-path lsp-name ingress]

Release Information Statement introduced before Junos OS Release 7.4.

Description Preference for the route.

You can optionally configure multiple LSPs between the same pair of ingress and egress
routers. This is useful for balancing the load among the LSPs because all LSPs, by default,
have the same preference level. To prefer one LSP over another, set different preference
levels for individual LSPs. The LSP with the lowest preference value is used. The default
preference for LSPs is lower (more preferred) than all learned routes except direct
interface routes.

Options preference—Preference to assign to the route. A route with a lower preference value is
preferred.
Range: 1 through 255
Default: 5 for static MPLS LSPs, 7 for RSVP MPLS LSPs, 9 for LDP MPLS LSPs

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring Preference Values for LSPs on page 175

Documentation
• Configuring the Ingress Router for Static LSPs on page 211

• Configuring the Intermediate (Transit) and Egress Routers for Static LSPs on page 214

Copyright © 2012, Juniper Networks, Inc. 343

Junos OS 12.1 MPLS Applications Configuration Guide

primary

Syntax primary path-name {

adaptive;
admin-group {
exclude [ group-names ];
include-all [ group-names ];
include-any [ group-names ];
}
bandwidth bps;
class-of-service cos-value;
hop-limit number;
no-cspf;
no-decrement-ttl;
optimize-timer seconds;
preference preference;
priority setup-priority reservation-priority;
(record | no-record);
select (manual | unconditional);
standby;
}

Hierarchy Level [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name],

[edit protocols mpls label-switched-path lsp-name]

Release Information Statement introduced before Junos OS Release 7.4.

Description Specify the primary path to use for an LSP. You can configure only one primary path.

You can optionally specify preference, CoS, and bandwidth values for the primary path,
which override any equivalent values that you configure for the LSP (at the [edit mpls
label-switched-path lsp-name] hierarchy level).

Options path-name—Name of a path that you created with the path statement.

The remaining statements are explained separately.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring Primary and Secondary LSPs on page 149

Documentation

344 Copyright © 2012, Juniper Networks, Inc.

 Chapter 10: Summary of MPLS Configuration Statements

priority

Syntax priority setup-priority reservation-priority;

Hierarchy Level [edit logical-systems logical-system-name protocols mpls],

[edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name],
[edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name
(primary | secondary) path-name],
[edit protocols mpls],
[edit protocols mpls label-switched-path lsp-name],
[edit protocols mpls label-switched-path lsp-name (primary | secondary) path-name]

Release Information Statement introduced before Junos OS Release 7.4.

Description Configure the setup priority and reservation priority for an LSP. If insufficient link bandwidth
is available during session establishment, the setup priority is compared with other setup
priorities for established sessions on the link to determine whether some of them should
be preempted to accommodate the new session. Sessions with lower hold priorities are
preempted.

Options reservation-priority—Reservation priority, used to keep a reservation after it has been set
up. A smaller number has a higher priority. The priority must be greater than or equal
to the setup priority to prevent preemption loops.
Range: 0 through 7, where 0 is the highest and 7 is the lowest priority.
Default: 0 (Once the session is set up, no other session can preempt it.)

setup-priority—Setup priority.
Range: 0 through 7, where 0 is the highest and 7 is the lowest priority.
Default: 7 (The session cannot preempt any existing sessions.)

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring Priority and Preemption for LSPs on page 179

Documentation

Copyright © 2012, Juniper Networks, Inc. 345

Junos OS 12.1 MPLS Applications Configuration Guide

protection-revert-time

Syntax protection-revert-time seconds;

Hierarchy Level [edit logical-systems logical-system-name protocols mpls interface interface-name static],
[edit protocols mpls interface interface-name static]

Release Information Statement introduced in Junos OS Release 10.1.

Description Specify the amount of time (in seconds) that a static LSP must wait before traffic reverts
from the bypass path to the original path.

If you have configured a value of 0 seconds for the protection-revert-time statement and
traffic is switched to the bypass path, the traffic remains on that path indefinitely. It is
never switched back to the original path unless the bypass path is down or you intervene.

Options seconds—Time in seconds.

Range: 0 through 65,535 seconds
Default: 5 seconds

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring Static LSPs on page 211

Documentation

346 Copyright © 2012, Juniper Networks, Inc.

 Chapter 10: Summary of MPLS Configuration Statements

push

Syntax push out-label;

Hierarchy Level [edit logical-systems logical-system-name protocols mpls

static-label-switched-path lsp-name bypass],
[edit logical-systems logical-system-name protocols mpls
static-label-switched-path lsp-name ingress],
[edit protocols mpls static-label-switched-path lsp-name bypass],
[edit protocols mpls static-label-switched-path lsp-name ingress]

Release Information Statement introduced before Junos OS Release 7.4.

Description Add a new label to the top of the label stack. This statement is used to configure static
LSPs at ingress routers and to configure bypass LSPs for static LSPs.

Options out-label—Manually assigned outgoing label value.

Range: 0 through 1,048,575.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • pop on page 342

Documentation
• swap on page 363

• Configuring the Ingress Router for Static LSPs on page 211

Copyright © 2012, Juniper Networks, Inc. 347

Junos OS 12.1 MPLS Applications Configuration Guide

random

Syntax (random | least-fill | most-fill);

Hierarchy Level [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name],

[edit protocols mpls label-switched-path lsp-name]

Release Information Statement introduced before Junos OS Release 7.4.

Description Configure the preferred path when several equal-cost candidate paths to a destination
exist, and prefer the path with the highest available bandwidth (with the largest minimum
available bandwidth ratio). The available bandwidth ratio of a link is the available
bandwidth on a link divided by the maximum reservable bandwidth on the link.

• least-fill—Prefer the path with the most available bandwidth (with the largest minimum
available bandwidth ratio).

• most-fill—Prefer the path with the least available bandwidth (with the minimum
available bandwidth ratio). The minimum available bandwidth ratio of a path is the
smallest available bandwidth ratio belonging to any of the links in the path.

• random—Choose the path at random.

Default random

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring CSPF Tie Breaking on page 157

Documentation

348 Copyright © 2012, Juniper Networks, Inc.

 Chapter 10: Summary of MPLS Configuration Statements

record

Syntax (record | no-record);

Hierarchy Level [edit logical-systems logical-system-name protocols mpls],

[edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name],
[edit logical-systems logical-system-name protocols mpls label-switched-path (primary |
secondary) path-name],
[edit protocols mpls],
[edit protocols mpls label-switched-path lsp-name],
[edit protocols mpls label-switched-path lsp-name (primary | secondary) path-name]

Release Information Statement introduced before Junos OS Release 7.4.

Description Specify whether an LSP should actively record the routes in the path. Recording routes
requires that all transit routers support the RSVP Record Route object. Recording routes
can be useful for diagnostics and loop detection.

Default Record routes.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Disabling Path Route Recording on page 175

Documentation

retry-limit

Syntax retry-limit number;

Hierarchy Level [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name],

[edit protocols mpls label-switched-path lsp-name],

Release Information Statement introduced before Junos OS Release 7.4.

Description Maximum number of times the ingress router tries to establish the primary path. This
counter is reset each time a primary path is created successfully. When the limit is
exceeded, no more connection attempts are made. Intervention is then required to restart
the connection.

Options number—Maximum number of tries to establish the primary path.

Range: 0 through 10,000
Default: 0 (The ingress node never stops trying to establish the primary path.)

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring the Connection Between Ingress and Egress Routers on page 155
Documentation

Copyright © 2012, Juniper Networks, Inc. 349

Junos OS 12.1 MPLS Applications Configuration Guide

retry-timer

Syntax retry-timer seconds;

Hierarchy Level [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name],

[edit protocols mpls label-switched-path lsp-name]

Release Information Statement introduced before Junos OS Release 7.4.

Description Amount of time the ingress router waits between attempts to establish the primary path.

Options seconds—Amount of time between attempts to connect to the primary path.

Range: 1 through 600 seconds
Default: 30 seconds

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring the Connection Between Ingress and Egress Routers on page 155
Documentation

350 Copyright © 2012, Juniper Networks, Inc.

 Chapter 10: Summary of MPLS Configuration Statements

revert-timer

Syntax revert-timer seconds;

Hierarchy Level [edit logical-systems logical-system-name protocols mpls],

[edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name],
[edit protocols mpls],
[edit protocols mpls label-switched-path lsp-name]

Release Information Statement introduced before Junos OS Release 7.4.

BFD behavior modified in Junos OS Release 9.0.

Description Specify the amount of time (in seconds) that an LSP must wait before traffic reverts to
a primary path. If during this time the primary path experiences any connectivity problem
or stability problem, the timer is restarted.

If you have configured BFD on the LSP, the Junos OS waits until the BFD session is restored
before starting the revert timer counter.

If you have configured a value of 0 seconds for the revert-timer statement and traffic is
switched to the secondary path, the traffic remains on that path indefinitely. It is never
switched back to the primary path unless you intervene.

Options seconds—Time in seconds.

Range: 0 through 65,535 seconds
Default: 60 seconds

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring the Revert Timer for LSPs on page 150

Documentation

Copyright © 2012, Juniper Networks, Inc. 351

Junos OS 12.1 MPLS Applications Configuration Guide

rpf-check-policy

Syntax rpf-check-policy policy;

Hierarchy Level [edit logical-systems logical-system-name routing-options multicast],

[edit routing-options multicast]

Release Information Statement introduced in Junos OS Release 8.0.

Description Enable you to control whether a reverse path forwarding (RPF) check is performed for
a source and group entry before installing a route in the multicast forwarding cache. This
makes it possible to use point-to-multipoint LSPs to distribute multicast traffic to Protocol
Independent Multicast (PIM) islands situated downstream from the egress routers of
the point-to-multipoint LSPs.

Options policy—Name of the RPF check routing policy.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring a Multicast RPF Check Policy for Point-to-Multipoint LSPs on page 224
Documentation

352 Copyright © 2012, Juniper Networks, Inc.

 Chapter 10: Summary of MPLS Configuration Statements

rsvp-error-hold-time

Syntax rsvp-error-hold-time seconds;

Hierarchy Level [edit logical-systems logical-system-name protocols mpls],

[edit protocols mpls]

Release Information Statement introduced before Junos OS Release 7.4.

Description Amount of time MPLS retains RSVP PathErr messages and considers them for CSPF
computations. The more time you configure, the more time a source node (ingress of an
RSVP LSP) can have to learn about the failures of its LSP by monitoring PathErr messages
transmitted from downstream nodes.

Information from the PathErr messages is incorporated into subsequent LSP

computations, which can improve the accuracy and speed of LSP setup. Some PathErr
messages are also used to update traffic engineering database bandwidth information,
reducing inconsistencies between the database and the network.

Options seconds—Amount of time MPLS retains RSVP PathErr messages and considers them for
CSPF computations.
Range: 0 through 240 seconds
Default: 25 seconds

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Improving Traffic Engineering Database Accuracy with RSVP PathErr Messages on
Documentation page 63

Copyright © 2012, Juniper Networks, Inc. 353

Junos OS 12.1 MPLS Applications Configuration Guide

secondary

Syntax secondary path-name {

adaptive;
admin-group {
exclude [ group-names ];
include-all [ group-names ];
include-any [ group-names ];
}
bandwidth bps;
class-of-service cos-value;
hop-limit number;
no-cspf;
no-decrement-ttl;
optimize-timer seconds;
preference preference;
priority setup-priority reservation-priority;
(record | no-record);
retry-limit number;
retry-timer seconds;
select (manual | unconditional);
standby;
}

Hierarchy Level [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name],

[edit protocols mpls label-switched-path lsp-name]

Release Information Statement introduced before Junos OS Release 7.4.

Description Specify one or more secondary paths to use for the LSP. You can configure more than
one secondary path. All secondary paths are equal, and the first one that is available is
chosen.

You can specify secondary paths even if you have not specified any primary paths.

Optionally, you can specify preference, CoS, and bandwidth values for the secondary
path, which override any equivalent values that you configure for the LSP (at the [edit
mpls label-switched-path] hierarchy level).

Options path-name—Name of a path that you created with the path statement.

The remaining statements are explained separately.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring Primary and Secondary LSPs on page 149

Documentation

354 Copyright © 2012, Juniper Networks, Inc.

 Chapter 10: Summary of MPLS Configuration Statements

select

Syntax select (manual | unconditional);

Hierarchy Level [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name

(primary | secondary) path-name],
[edit protocols mpls label-switched-path lsp-name (primary | secondary) path-name]

Release Information Statement introduced before Junos OS Release 7.4.

Description Specify the conditions under which the path is selected to carry traffic. The manual and
unconditional options are mutually exclusive.

Options manual—The path is selected for carrying traffic if it is up and stable for at least the revert
timer window (potentially before the revert timer has elapsed). Traffic is sent to
other working paths if the current path is down or degraded (receiving errors).

unconditional—The path is always selected for carrying traffic, even if it is currently down
or degraded (receiving errors).

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Specifying the Conditions for Path Selection on page 151

Documentation

signal-bandwidth

Syntax signal-bandwidth type;

Hierarchy Level [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name

lsp-attributes],
[edit protocols mpls label-switched-path lsp-name lsp-attributes]

Release Information Statement introduced before Junos OS Release 7.4.

Description Specify the bandwidth encoding of the signal used for path computation and admission
control.

Options type—Configure the type of bandwidth encoding used on the LSP. It can be any of the
following values: 10gigether, ds1, ds3, e1, e3, ethernet, fastether, gigether, stm-1, stm-4,
stm-16, stm-64, stm-256, sts-1, vt1-5, or vt2.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring the Signal Bandwidth Type on page 597

Documentation

Copyright © 2012, Juniper Networks, Inc. 355

Junos OS 12.1 MPLS Applications Configuration Guide

smart-optimize-timer

Syntax smart-optimize-timer seconds;

Hierarchy Level [edit logical-systems logical-system-name protocols mpls],

[edit protocols mpls]

Release Information Statement introduced before Junos OS Release 7.4.

Description Enable the smart optimization timer. When you enable the smart optimization timer on
a router, the Junos OS operates on the assumption that the original LSP path is preferable
to any alternate or secondary path. When you enable the smart optimization timer and
an LSP fails and its traffic is switched to an alternate path, the smart optimization timer
starts and waits 3 minutes (this time is configurable). After 3 minutes have passed, the
LSP is switched back to the original path. If the original path fails again and the LSP is
switched to an alternate path again, the router waits 1 hour before attempting to switch
the LSP back to its original path.

Default The smart optimization timer is disabled by default.

Options seconds—(Optional) Specify the number of seconds to wait before switching an LSP
back to its original path. If you do not specify the number of seconds, the default
value is used.
Range: 0 through 65,535 seconds
Default: 180 seconds

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring the Smart Optimize Timer on page 183

Documentation
• Optimizing Signaled LSPs on page 180

• optimize-aggressive on page 337

• optimize-timer on page 338

356 Copyright © 2012, Juniper Networks, Inc.

 Chapter 10: Summary of MPLS Configuration Statements

soft-preemption

Syntax soft-preemption;

Hierarchy Level [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name],

[edit protocols mpls label-switched-path lsp-name]

Release Information Statement introduced before Junos OS Release 7.4.

Description Attempt to establish a new path for a preempted LSP before tearing it down.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring MPLS Soft Preemption on page 162

Documentation

srlg

Syntax srlg {
srlg-name {
srlg-cost srlg-cost;
srlg-value srlg-value;
}
}

Hierarchy Level [edit routing-options],

[edit logical-systems logical-system-name routing-options]
[edit protocols mpls interface interface-name]

Release Information Statement introduced in Junos OS Release 11.4.

Description Configure Shared Risk Link Group (SRLG) parameters.

Options srlg-cost srlg-cost—Specify a cost for the SRLG ranging from 1 through 65535.

srlg-value srlg-value—Specify a Group ID for the SRLG ranging from 1 through 4294967295.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Example: Configuring SRLG on page 76

Documentation

Copyright © 2012, Juniper Networks, Inc. 357

Junos OS 12.1 MPLS Applications Configuration Guide

srlg-cost

Syntax srlg-cost srlg-cost;

Hierarchy Level [edit routing-options srlg],

[edit logical-systems logical-system-name routing-options srlg]

Release Information Statement introduced in Junos OS Release 11.4.

Description Specify a cost for the Shared Risk Link Group (SRLG) ranging from 1 through 65535.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Example: Configuring SRLG on page 76

Documentation

srlg-value

Syntax srlg-value srlg-value;

Hierarchy Level [edit routing-options srlg],

[edit logical-systems logical-system-name routing-options srlg]

Release Information Statement introduced in Junos OS Release 11.4.

Description Specify a Group ID for the Shared Risk Link Group (SRLG) ranging from 1 through
4294967295.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Example: Configuring SRLG on page 76

Documentation

358 Copyright © 2012, Juniper Networks, Inc.

 Chapter 10: Summary of MPLS Configuration Statements

standby

Syntax standby;

Hierarchy Level [edit logical-systems logical-system-name protocols mpls],

[edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name],
[edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name
(primary | secondary) path-name],
[edit protocols mpls],
[edit protocols mpls label-switched-path lsp-name],
[edit protocols mpls label-switched-path lsp-name (primary | secondary) path-name]

Release Information Statement introduced before Junos OS Release 7.4.

Description Have the path remain up at all times to provide instant switchover if connectivity problems
occur.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring Hot Standby of Secondary Paths on page 185

Documentation

Copyright © 2012, Juniper Networks, Inc. 359

Junos OS 12.1 MPLS Applications Configuration Guide

static-label-switched-path

Syntax static-label-switched-path lsp-name {

bypass bypass-name {
bandwidth bps;
description string;
next-hop (address | interface-name | address/interface-name);
push out-label;
to address;
}
ingress {
bandwidth bps;
class-of-service cos-value;
description string;
install {
destination-prefix <active>;
}
link-protection bypass-name name;
metric metric;
next-hop (address | interface-name | address/interface-name);
node-protection bypass-name name next-next-label label;
no-install-to-address;
policing {
filter filter-name;
no-auto-policing;
}
preference preference;
push out-label;
to address;
}
transit incoming-label {
bandwidth bps;
description string;
link-protection bypass-name name;
next-hop (address | interface-name | address/interface-name);
node-protection bypass-name name next-next-label label;
pop;
swap out-label;
}

Hierarchy Level [edit logical-systems logical-system-name protocols mpls],

[edit protocols mpls]

Release Information Statement introduced in Junos OS Release 10.1.

Description Configure a static LSP.

Options lsp-name—Name of the path.

The remaining statements are explained separately.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

360 Copyright © 2012, Juniper Networks, Inc.

 Chapter 10: Summary of MPLS Configuration Statements

Related • Configuring Static LSPs on page 211

Documentation

Copyright © 2012, Juniper Networks, Inc. 361

Junos OS 12.1 MPLS Applications Configuration Guide

statistics

Syntax statistics {
auto-bandwidth;
file filename <files number> <size size> <world-readable | no-world-readable>;
interval seconds;
}

Hierarchy Level [edit logical-systems logical-system-name protocols mpls],

[edit protocols mpls]

Release Information Statement introduced before Junos OS Release 7.4.

Description Enable MPLS statistics collection and reporting.

Options auto-bandwidth—Collect statistics related to automatic bandwidth.

file filename—(Optional) Name of the file to receive the output. We recommend that you
place MPLS tracing output in the file mpls-stat in the /var/log directory.

files number—(Optional) Maximum number of trace files. When a trace file named file
reaches its maximum size, it is renamed file.0, then file.1, and so on, until the maximum
number of files is reached. Then, the oldest file is overwritten.
Range: 2 or more
Default: 2 files

If you specify a maximum number of files, you also must specify a maximum file size with
the size option.

interval seconds—Interval at which to periodically collect statistics.

Range: 1 through 65,535
Default: 300 seconds

no-world-readable—(Optional) Prevent users from reading the log file.

size size—(Optional) Maximum size of each file, in kilobytes (KB), megabytes (MB),
or gigabytes (GB). When a file named file reaches this size, it is renamed file.0. When
the file again reaches its maximum size, file.0 is renamed file.1 and file is renamed
file.0. This renaming scheme continues until the maximum number of files is reached.
Then the oldest trace file is overwritten.
Syntax: Syntax: xk to specify KB, xm to specify MB, or xg to specify GB
Range: 10 KB through the maximum file size supported on your system
Default: 1 MB

If you specify a maximum file size, you also must specify a maximum number of files with
the files option.

world-readable—(Optional) Enable users to read the log file.

362 Copyright © 2012, Juniper Networks, Inc.

 Chapter 10: Summary of MPLS Configuration Statements

Required Privilege routing and trace—To view this statement in the configuration.
Level routing-control and trace-control—To add this statement to the configuration.

Related • Configuring MPLS to Gather Statistics on page 256

Documentation
• Configuring MPLS Statistics for Automatic Bandwidth Allocation on page 164

swap

Syntax swap out-label;

Hierarchy Level [edit logical-systems logical-system-name protocols mpls static-label-switched-path

lsp-name transit incoming-label],
[edit protocols mpls static-label-switched-path lsp-name transit incoming-label]

Release Information Statement introduced before Junos OS Release 7.4.

Description Remove the label at the top of the label stack and replace it with the specified label.
Manually assigned incoming labels can have values from 1,000,000 through 1,048,575.
This statement is used to configure static LSPs at transit routers.

Options out-label—Manually assigned outgoing label value.

Range: 0 through 1,048,575
Default: If you do not define the out-label option, the original label value remains
unchanged.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • pop on page 342

Documentation
• push on page 347

• Configuring the Intermediate (Transit) and Egress Routers for Static LSPs on page 214

Copyright © 2012, Juniper Networks, Inc. 363

Junos OS 12.1 MPLS Applications Configuration Guide

switch-away-lsps

Syntax switch-away-lsps;

Hierarchy Level [edit logical-systems logical-systems-name protocols mpls interface interface-name],

[edit protocols mpls interface interface-name]

Release Information Statement introduced in Junos OS Release 10.2.

Description (MX Series routers only) Enable you to switch an LSP away from a network node using
a bypass LSP. This feature could be used in maintenance of active networks when a
network device needs to be replaced without interrupting traffic passing through the
network. The LSPs can be either static or dynamic. Configure this statement only after
you have configured and committed the always-mark-connection-protection-tlv statement.

The always-mark-connection-protection-tlv statement marks all OAM traffic transiting

this interface in preparation for switching the traffic to an alternate path based on the
OAM functionality. When you configure the switch-away-lsps statement, traffic is switched
to the bypass LSP.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Switching LSPs Away from a Network Node on page 403

Documentation

364 Copyright © 2012, Juniper Networks, Inc.

 Chapter 10: Summary of MPLS Configuration Statements

switching-type

Syntax switching-type (fiber | lambda | psc-1 | tdm);

Hierarchy Level [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name

lsp-attributes],
[edit protocols mpls label-switched-path lsp-name lsp-attributes]

Release Information Statement introduced before Junos OS Release 7.4.

Description Specify the switching method for the LSP. The switching method can be one of the
following values:

• fiber—Fiber switching

• lambda—Lambda switching

• psc-1—Packet switching

• tdm—Time-division multiplexing (TDM) switching

Default psc-1

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring MPLS LSPs for GMPLS on page 595

Documentation

Copyright © 2012, Juniper Networks, Inc. 365

Junos OS 12.1 MPLS Applications Configuration Guide

te-class-matrix

Syntax te-class-matrix {
tenumber {
priority priority;
traffic-class {
ctnumber priority priority;
}
}
}

Hierarchy Level [edit logical-systems logical-system-name protocols mpls diffserv-te],

[edit protocols mpls diffserv-te]

Release Information Statement introduced before Junos OS Release 7.4.

Description Specify the traffic engineering class matrix for a multiclass LSP or a DiffServ-aware traffic
engineering LSP.

Default The default traffic engineering class matrix is:

te-class-matrix {
te0 traffic-class ct0 priority 7;
te1 traffic-class ct1 priority 7;
te2 traffic-class ct2 priority 7;
te3 traffic-class ct3 priority 7;
te4 traffic-class ct0 priority 0;
te5 traffic-class ct1 priority 0;
te6 traffic-class ct2 priority 0;
te7 traffic-class ct3 priority 0;
}

If you define any of the traffic engineering classes, all the default values are dropped.

Options ctnumber—Specify the number of the class type. It can be one of four values: ct0, ct1, ct2,
or ct3.

priority priority—Specify the priority of the class type. It can be one of eight values from
0 through 7.

tenumber—Specify the number of the traffic engineering class. It can be one of eight
values: te0, te1, te2, te3, te4, te5, te6, or te7. You must configure the traffic engineering
classes in order, starting with te0.

traffic-class—Specify the traffic class for the traffic engineering class.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring Traffic Engineering Classes on page 195

Documentation

366 Copyright © 2012, Juniper Networks, Inc.

 Chapter 10: Summary of MPLS Configuration Statements

to

Syntax to address;

Hierarchy Level [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name],

[edit logical-systems logical-system-name protocols mpls static-label-switched-path
lsp-name bypass],
[edit logical-systems logical-system-name protocols mpls static-label-switched-path
lsp-name ingress],
[edit protocols mpls label-switched-path lsp-name],
[edit protocols mpls static-label-switched-path lsp-name bypass],
[edit protocols mpls static-label-switched-path lsp-name ingress]

Release Information Statement introduced before Junos OS Release 7.4.

Description Specify the egress router of a dynamic LSP.

Options address—Address of the egress router.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring the Egress Router Address for LSPs on page 148
Documentation

Copyright © 2012, Juniper Networks, Inc. 367

Junos OS 12.1 MPLS Applications Configuration Guide

traceoptions

Syntax traceoptions {
file filename <files number> <size size> <world-readable | no-world-readable>;
flag flag;
}

Hierarchy Level [edit logical-systems logical-system-name protocols mpls],

[edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name],
[edit protocols mpls],
[edit protocols mpls label-switched-path lsp-name]

Release Information Statement introduced before Junos OS Release 7.4.

Description Configure MPLS tracing options at the protocol level or for a label-switched path.

To specify more than one tracing operation, include multiple flag statements.

Default The default MPLS protocol-level tracing options are inherited from the routing protocols
traceoptions statement included at the [edit routing-options] hierarchy level.

Options filename—Name of the file to receive the output of the tracing operation. All files are
placed in the directory /var/log. We recommend that you place MPLS tracing output
in the file mpls-log.

files number—(Optional) Maximum number of trace files. When a trace file named
trace-file reaches its maximum size, it is renamed trace-file.0, then trace-file.1, and
so on, until the maximum number of trace files is reached. Then the oldest trace file
is overwritten.
Range: 2 through 1000
Default: 2 files

If you specify a maximum number of files, you must also include the size statement to
specify the maximum file size.

flag—Tracing operation to perform. To specify more than one tracing operation, include
multiple flag statements.

MPLS Tracing Flags

• all—Trace all operations

• connection—All circuit cross-connect (CCC) activity

• connection-detail—Detailed CCC activity

• cspf—CSPF computations

• cspf-link—Links visited during CSPF computations

• cspf-node—Nodes visited during CSPF computations

• error—MPLS error packets

368 Copyright © 2012, Juniper Networks, Inc.

 Chapter 10: Summary of MPLS Configuration Statements

• graceful-restart—Trace MPLS graceful restart events

• lsping—Trace lsping packets and return codes

• nsr-synchronization—Trace NSR synchronization events

• nsr-synchronization-detail—Trace NSR synchronization events in detail

• state—All LSP state transitions

• static—Trace static label-switched path

• timer—Timer usage

no-world-readable—(Optional) Allow only certain users to read the log file.

size size—(Optional) Maximum size of each trace file, in kilobytes (KB), megabytes (MB),
or gigabytes (GB). When a trace file named trace-file reaches this size, it is renamed
trace-file.0. When the trace-file again reaches this size, trace-file.0 is renamed
trace-file.1 and trace-file is renamed trace-file.0. This renaming scheme continues
until the maximum number of trace files is reached. Then the oldest trace file is
overwritten.
Syntax: xk to specify KB, xm to specify MB, or xg to specify GB
Range: 10 KB through the maximum file size supported on your system
Default: 1 MB

If you specify a maximum file size, you must also include the files statement to specify
the maximum number of files.

world-readable—(Optional) Allow any user to read the log file.

Required Privilege routing and trace—To view this statement in the configuration.
Level routing-control and trace-control—To add this statement to the configuration.

Related • Tracing MPLS and LSP Packets and Operations on page 271
Documentation

Copyright © 2012, Juniper Networks, Inc. 369

Junos OS 12.1 MPLS Applications Configuration Guide

traffic-engineering

Syntax traffic-engineering (bgp | bgp-igp | bgp-igp-both-ribs | mpls-forwarding);

Hierarchy Level [edit logical-systems logical-system-name protocols mpls],

[edit protocols mpls]

Release Information Statement introduced before Junos OS Release 7.4.

Statement introduced in Junos OS Release 12.1 for EX Series switches.

Description Select whether MPLS performs traffic engineering on BGP destinations only or on both
BGP and IGP destinations. Affects only LSPs originating from this routing device, not
transit or egress LSPs.

Default bgp

Options bgp—On BGP destinations only. Ingress routes are installed in the inet.3 routing table.

bgp-igp—On both BGP and IGP destinations. Ingress routes are installed in the inet.0
routing table. If IGP shortcuts are enabled, the shortcut routes are automatically
installed in the inet.0 routing table.

bgp-igp-both-ribs—On both BGP and IGP destinations. Ingress routes are installed in the
inet.0 and inet.3 routing tables. This option is used to support VPNs.

mpls-forwarding—On both BGP and IGP destinations. Use ingress routes for forwarding
only, not for routing.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring Traffic Engineering for LSPs on page 250

Documentation
• Configuring MPLS on Provider Edge Switches Using IP Over MPLS (CLI Procedure)

370 Copyright © 2012, Juniper Networks, Inc.

 Chapter 10: Summary of MPLS Configuration Statements

transit-lsp-association

Syntax transit-lsp-association transit-association-lsp-group-name {

from-1 address-of-associated-lsp-1;
from-2 address-of-associated-lsp-2;
lsp-name-1 name-of-associated-lsp-1;
lsp-name-2 name-of-associated-lsp-2;
}

Hierarchy Level [edit protocols mpls]

Release Information Statement introduced in Junos OS Release 12.1.

Description Associate two label-swiched paths (LSPs) at a transit node to configure a path for
sending and receiving GAL and G-Ach messages for MPLS-TP OAM.

Options transit-association-lsp-group-name—Name of the transit association LSP group.

from-1 address-of-associated-lsp-1—Address of the first associated LSP.

from-2 address-of-associated-lsp-2—Address of the second associated LSP.

lsp-name-1 name-of-associated-lsp-1—Name of the first associated LSP.

lsp-name-2 name-of-associated-lsp-1—Name of the second associated LSP.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Example: Configuring the MPLS Transport Profile for OAM on page 130
Documentation

Copyright © 2012, Juniper Networks, Inc. 371

Junos OS 12.1 MPLS Applications Configuration Guide

372 Copyright © 2012, Juniper Networks, Inc.

PART 3

RSVP
• RSVP Overview on page 375
• RSVP Configuration Guidelines on page 393
• Summary of RSVP Configuration Statements on page 425

Copyright © 2012, Juniper Networks, Inc. 373

Junos OS 12.1 MPLS Applications Configuration Guide

374 Copyright © 2012, Juniper Networks, Inc.

CHAPTER 11

RSVP Overview

This chapter discusses the following topics:

• RSVP Introduction on page 376

• Supported RSVP Standards on page 376
• Junos OS RSVP Protocol Implementation on page 378
• RSVP Operation Overview on page 378
• RSVP Authentication on page 379
• RSVP and IGP Hello Packets and Timers on page 379
• RSVP Message Types on page 379
• Path Messages on page 380
• Resv Messages on page 380
• PathTear Messages on page 380
• ResvTear Messages on page 380
• PathErr Messages on page 381
• ResvErr Messages on page 381
• ResvConfirm Messages on page 381
• RSVP Reservation Styles on page 381
• RSVP Refresh Reduction on page 382
• MTU Signaling in RSVP on page 383
• How the Correct MTU Is Signaled in RSVP on page 384
• Determining an Outgoing MTU Value on page 384
• MTU Signaling in RSVP Limitations on page 385
• Fast Reroute, Node Protection, and Link Protection on page 385
• Link Protection on page 386
• Multiple Bypass LSPs on page 387
• Node Protection on page 387
• RSVP Graceful Restart on page 388
• RSVP Graceful Restart Standard on page 389
• RSVP Graceful Restart Terminology on page 389

Copyright © 2012, Juniper Networks, Inc. 375

Junos OS 12.1 MPLS Applications Configuration Guide

• RSVP Graceful Restart Operation on page 389

• Processing the Restart Cap Object on page 390

RSVP Introduction

RSVP is a resource reservation setup protocol that is used by both network hosts and
routers. Hosts use RSVP to request a specific class of service (CoS) from the network
for particular application flows. Routers use RSVP to deliver CoS requests to all routers
along the data path. RSVP also can maintain and refresh states for a requested CoS
application flow.

RSVP treats an application flow as a simplex connection. That is, the CoS request travels
only in one direction—from the sender to the receiver. RSVP is a transport layer protocol
that uses IP as its network layer. However, RSVP does not transport application flows.
Rather, it is more of an Internet control protocol, similar to the Internet Control Message
Protocol (ICMP) and Internet Group Management Protocol (IGMP). RSVP runs as a
separate software process in the Junos OS and is not in the packet forwarding path.

RSVP is not a routing protocol, but rather is designed to operate with current and future
unicast and multicast routing protocols. The routing protocols are responsible for choosing
the routes to use to forward packets, and RSVP consults local routing tables to obtain
routes. RSVP only ensures the CoS of packets traveling along a data path.

The receiver in an application flow requests the preferred CoS from the sender. To do
this, the receiver issues an RSVP CoS request on behalf of the local application. The
request propagates to all routers in reverse direction of the data paths toward the sender.
In this process, RSVP requests might be merged, resulting in a protocol that scales well
when there are a large number of receivers.

Because the number of receivers in an application flow is likely to change and the flow
of delivery paths might change during the life of an application flow, RSVP takes a
soft-state approach in its design, creating and removing the protocol states in routers
and hosts incrementally over time. RSVP sends periodic refresh messages to maintain
its state and to recover from occasional lost messages. In the absence of refresh
messages, RSVP states automatically time out and are deleted.

Supported RSVP Standards

The Junos OS substantially supports the following RFCs and Internet drafts, which define
standards for RSVP.

• RFC 2205, Resource ReSerVation [sic] Protocol (RSVP)—Version 1 Functional

Specification

• RFC 2210, The Use of RSVP with IETF Integrated Services

• RFC 2211, Specification of the Controlled-Load Network Element Service

• RFC 2212, Specification of Guaranteed Quality of Service

• RFC 2215, General Characterization Parameters for Integrated Service Network Elements

• RFC 2745, RSVP Diagnostic Messages

376 Copyright © 2012, Juniper Networks, Inc.

 Chapter 11: RSVP Overview

• RFC 2747, RSVP Cryptographic Authentication (updated by RFC 3097)

• RFC 2961, RSVP Refresh Overhead Reduction Extensions

• RFC 3097, RSVP Cryptographic Authentication—Updated Message Type Value

• RFC 3209, RSVP-TE: Extensions to RSVP for LSP Tunnels

The Null Service Object for maximum transmission unit (MTU) signaling in RSVP is
not supported.

• RFC 3473, Generalized Multi-Protocol [sic] Label Switching (GMPLS) Signaling Resource
ReserVation [sic] Protocol-Traffic Engineering (RSVP-TE) Extensions

Only Section 9, “Fault Handling,” is supported.

• RFC 3477, Signalling Unnumbered Links in Resource ReSerVation [sic] Protocol - Traffic
Engineering (RSVP-TE)

• RFC 4090, Fast Reroute Extensions to RSVP-TE for LSP Tunnels

Node protection in facility backup is not supported.

• RFC 4203, OSPF Extensions in Support of Generalized Multi-Protocol [sic] Label Switching
(GMPLS)

(OSPF extensions can carry traffic engineering information over unnumbered links.)

• RFC 4558, Node-ID Based Resource Reservation Protocol (RSVP) Hello: A Clarification
Statement

• RFC 4561, Definition of a Record Route Object (RRO) Node-Id Sub-Object

The RRO node ID subobject is for use in inter-AS link and node protection configurations.

• Internet draft draft-ietf-mpls-rsvp-te-p2mp-01.txt, Extensions to RSVP-TE for Point to

Multipoint TE LSPs (expires June 2005)

The following RFCs do not define standards, but provide information about RSVP and
related technologies. The IETF classifies them variously as “Experimental” or
“Informational.”

• RFC 2209, Resource ReSerVation [sic] Protocol (RSVP)—Version 1 Message Processing

Rules

• RFC 2216, Network Element Service Specification Template

• RFC 4125, Maximum Allocation Bandwidth Constraints Model for Diffserv-aware MPLS
Traffic Engineering

• RFC 4127, Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic
Engineering

Related • Supported GMPLS Standards on page 579

Documentation
• Supported LDP Standards on page 464

• Supported MPLS Standards on page 24

• Accessing Standards Documents on the Internet

Copyright © 2012, Juniper Networks, Inc. 377

Junos OS 12.1 MPLS Applications Configuration Guide

Junos OS RSVP Protocol Implementation

The Junos implementation of RSVP supports RSVP version 1. The software includes
support for all mandatory objects and RSVP message types, and supports message
integrity and node authentications through the Integrity object.

The primary purpose of the Junos RSVP software is to support dynamic signaling within
MPLS label-switched paths (LSPs). Supporting resource reservations over the Internet
is only a secondary purpose of the Junos OS implementation. Since supporting resource
reservations is secondary, the Junos RSVP software does not support the following
features:

• IP multicasting sessions.

• Traffic control. The software cannot make resource reservations for real-time video
or audio sessions.

With regard to the protocol mechanism, packet processing, and RSVP objects supported,
the Junos OS implementation of the software is interoperable with other RSVP
implementations.

RSVP Operation Overview

RSVP creates independent sessions to handle each data flow. A session is identified by
a combination of the destination address, an optional destination port, and a protocol.
Within a session, there can be one or more senders. Each sender is identified by a
combination of its source address and source port. An out-of-band mechanism, such as
a session announcement protocol or human communication, is used to communicate
the session identifier to all senders and receivers.

A typical RSVP session involves the following sequence of events:

1. A potential sender starts sending RSVP path messages to the session address.

2. A receiver, wanting to join the session, registers itself if necessary. For example, a
receiver in a multicast application would register itself with IGMP.

3. The receiver receives the path messages.

4. The receiver sends appropriate Resv messages toward the sender. These messages
carry a flow descriptor, which is used by routers along the path to make reservations
in their link-layer media.

5. The sender receives the Resv message and then starts sending application data.

This sequence of events is not necessarily strictly synchronized. For example, receivers
can register themselves before receiving path messages from the sender, and application
data can flow before the sender receives Resv messages. Application data that is delivered
before the actual reservation contained in the Resv message typically is treated as
best-effort, non-real-time traffic with no CoS guarantee.

378 Copyright © 2012, Juniper Networks, Inc.

 Chapter 11: RSVP Overview

RSVP Authentication

The Junos OS supports both the RSVP authentication style described in RFC 2747
(allowing for multivendor compatibility) and the RSVP authentication style described
in Internet draft draft-ietf-rsvp-md5-03.txt. The Junos OS uses the authentication style
described in Internet draft draft-ietf-rsvp-md5-08.txt by default. If the router receives
an RFC 2747-style RSVP authentication from a neighbor, it switches to this style of
authentication for that neighbor. The RSVP authentication style for each neighboring
router is determined separately.

RSVP and IGP Hello Packets and Timers

RSVP monitors the status of the interior gateway protocol (IGP) (IS-IS or OSPF) neighbors
and relies on the IGP protocols to detect when a node fails. If an IGP protocol declares
a neighbor down (because hello packets are no longer being received), RSVP also brings
down that neighbor. However, the IGP protocols and RSVP still act independently when
bringing a neighbor up.

In the Junos OS, RSVP typically relies on IGP hello packet detection to check for node
failures. RSVP sessions are kept up even if RSVP hello packets are no longer being
received, so long as the router continues to receive IGP hello packets. RSVP sessions are
maintained until either the router stops receiving IGP hello packets or the RSVP Path and
Resv messages time out. Configuring a short time for the IS-IS or OSPF hello timers
allows these protocols to detect node failures quickly.

RSVP hellos can be relied on when the IGP does not recognize a particular neighbor (for
example, if IGP is not enabled on the interface) or if the IGP is RIP (not IS-IS or OSPF).
Also, the equipment of other vendors might be configured to monitor RSVP sessions
based on RSVP hello packets. This equipment might also take an RSVP session down
due to a loss of RSVP hello packets.

We do not recommend configuring a short RSVP hello timer. If quick discovery of a failed
neighbor is needed, configure short IGP (OSPF or IS-IS) hello timers.

OSPF and IS-IS have infrastructure to manage rapid hello message sending and receiving
reliably, even if the routing protocols or some other process are straining the processing
capability of the router. Under the same circumstances, RSVP hellos might time out
prematurely even though the neighbor is functioning normally.

RSVP Message Types

RSVP uses the following types of messages to establish and remove paths for data flows,
establish and remove reservation information, confirm the establishment of reservations,
and report errors:

• Path Messages on page 380

• Resv Messages on page 380

• PathTear Messages on page 380

Copyright © 2012, Juniper Networks, Inc. 379

Junos OS 12.1 MPLS Applications Configuration Guide

• ResvTear Messages on page 380

• PathErr Messages on page 381

• ResvErr Messages on page 381

• ResvConfirm Messages on page 381

Path Messages

Each sender host transmits path messages downstream along the routes provided by
the unicast and multicast routing protocols. Path messages follow the exact paths of
application data, creating path states in the routers along the way, thus enabling routers
to learn the previous-hop and next-hop node for the session. Path messages are sent
periodically to refresh path states.

The refresh interval is controlled by a variable called the refresh-time, which is the
periodical refresh timer expressed in seconds. A path state times out if a router does not
receive a specified number of consecutive path messages. This number is specified by
a variable called keep-multiplier. Path states are kept for ( (keep-multiplier + 0.5) x 1.5 x
refresh-time ) seconds.

Resv Messages

Each receiver host sends reservation request (Resv) messages upstream toward senders
and sender applications. Resv messages must follow exactly the reverse path of path
messages. Resv messages create and maintain a reservation state in each router along
the way.

Resv messages are sent periodically to refresh reservation states. The refresh interval is
controlled by the same refresh time variable, and reservation states are kept for
( (keep-multiplier + 0.5) x 1.5 x refresh-time ) seconds.

PathTear Messages

PathTear messages remove (tear down) path states as well as dependent reservation
states in any routers along a path. PathTear messages follow the same path as path
messages. A PathTear typically is initiated by a sender application or by a router when
its path state times out.

PathTear messages are not required, but they enhance network performance because
they release network resources quickly. If PathTear messages are lost or not generated,
path states eventually time out when they are not refreshed, and the resources associated
with the path are released.

ResvTear Messages

ResvTear messages remove reservation states along a path. These messages travel
upstream toward senders of the session. In a sense, ResvTear messages are the reverse
of Resv messages. ResvTear messages typically are initiated by a receiver application
or by a router when its reservation state times out.

380 Copyright © 2012, Juniper Networks, Inc.

 Chapter 11: RSVP Overview

ResvTear messages are not required, but they enhance network performance because
they release network resources quickly. If ResvTear messages are lost or not generated,
reservation states eventually time out when they are not refreshed, and the resources
associated with the reservation are released.

PathErr Messages

When path errors occur (usually because of parameter problems in a path message),
the router sends a unicast PathErr message to the sender that issued the path message.
PathErr messages are advisory; these messages do not alter any path state along the
way.

ResvErr Messages

When a reservation request fails, a ResvErr error message is delivered to all the receivers
involved. ResvErr messages are advisory; these messages do not alter any reservation
state along the way.

ResvConfirm Messages

Receivers can request confirmation of a reservation request, and this confirmation is sent
with a ResvConfirm message. Because of the complex RSVP flow-merging rules, a
confirmation message does not necessarily provide end-to-end confirmation of the entire
path. Therefore, ResvConfirm messages are an indication, not a guarantee, of potential
success.

Juniper Networks routers never request confirmation using the ResvConfirm message;
however, a Juniper Networks router can send a ResvConfirm message if it receives a
request from another vendor's equipment.

RSVP Reservation Styles

A reservation request includes options for specifying the reservation style. The reservation
styles define how reservations for different senders within the same session are treated
and how senders are selected.

Two options specify how reservations for different senders within the same session are
treated:

• Distinct reservation—Each receiver establishes its own reservation with each upstream
sender.

• Shared reservation—All receivers make a single reservation that is shared among many
senders.

Two options specify how senders are selected:

• Explicit sender—List all selected senders.

• Wildcard sender—Select all senders, which then participate in the session.

Copyright © 2012, Juniper Networks, Inc. 381

Junos OS 12.1 MPLS Applications Configuration Guide

The following reservation styles, formed by a combination of these four options, currently
are defined:

• Fixed filter (FF)—This reservation style consists of distinct reservations among explicit
senders. Examples of applications that use fixed-filter-style reservations are video
applications and unicast applications, which both require flows that have a separate
reservation for each sender. The fixed filter reservation style is enabled on RSVP LSPs
by default.

• Wildcard filter (WF)—This reservation style consists of shared reservations among

wildcard senders. This type of reservation reserves bandwidth for any and all senders,
and propagates upstream toward all senders, automatically extending to new senders
as they appear. A sample application for wildcard filter reservations is an audio
application in which each sender transmits a distinct data stream. Typically, only a
few senders are transmitting at any one time. Such a flow does not require a separate
reservation for each sender; a single reservation is sufficient.

• Shared explicit (SE)—This reservation style consists of shared reservations among

explicit senders. This type of reservation reserves bandwidth for a limited group of
senders. A sample application is an audio application similar to that described for
wildcard filter reservations.

RSVP Refresh Reduction

RSVP relies on soft-state to maintain the path and reservation states on each router. If
the corresponding refresh messages are not sent periodically, the states eventually time
out and reservations are deleted. RSVP also sends its control messages as IP datagrams
with no reliability guarantee. It relies on periodic refresh messages to handle the occasional
loss of Path or Resv messages.

The RSVP refresh reduction extensions, based on RFC 2961, addresses the following
problems that result from relying on periodic refresh messages to handle message loss:

• Scalability—The scaling problem arises from the periodic transmission and processing
overhead of refresh messages, which increases as the number of RSVP sessions
increases.

• Reliability and latency—The reliability and latency problem stems from the loss of
nonrefresh RSVP messages or one-time RSVP messages such as PathTear or PathErr.
The time to recover from such a loss is usually tied to refresh interval and the keepalive
timer.

The RSVP refresh reduction capability is advertised by enabling the refresh reduction
(RR) capable bit in the RSVP common header. This bit is only significant between RSVP
neighbors.

RSVP refresh reduction includes the following features:

• RSVP message bundling using the bundle message

• RSVP Message ID to reduce message processing overhead

382 Copyright © 2012, Juniper Networks, Inc.

 Chapter 11: RSVP Overview

• Reliable delivery of RSVP messages using Message ID, Message Ack, and Message
Nack

• Summary refresh to reduce the amount of information transmitted every refresh interval

The RSVP refresh reduction specification (RFC 2961) allows you to enable some or all
of the above capabilities on a router. It also describes various procedures that a router
can use to detect the refresh reduction capabilities of its neighbor.

The Junos OS supports all of the refresh reduction extensions, some of which can be
selectively enabled or disabled. The Junos OS supports Message ID and therefore can
perform reliable message delivery only for Path and Resv messages.

For information about how to configure RSVP refresh reduction, see “Configuring RSVP
Refresh Reduction” on page 395.

MTU Signaling in RSVP

The maximum transmission unit (MTU) is the largest size packet or frame, in bytes, that
can be sent in a network. An MTU that is too large might cause retransmissions. Too
small an MTU might cause the router to send and handle relatively more header overhead
and acknowledgments. There are default values for MTUs associated with various
protocols. You can also explicitly configure an MTU on an interface.

When an LSP is created across a set of links with different MTU sizes, the ingress router
does not know what the smallest MTU is on the LSP path. By default, the MTU for an
LSP is 1,500 bytes.

If this MTU is larger than the MTU of one of the intermediate links, traffic might be dropped,
because MPLS packets cannot be fragmented. Also, the ingress router is not aware of
this type of traffic loss, because the control plane for the LSP would still function normally.

To prevent this type of packet loss in MPLS LSPs, you can configure MTU signaling in
RSVP. This feature is described in RFC 3209. Juniper Networks supports the Integrated
Services object for MTU signaling in RSVP. The Integrated Services object is described
in RFCs 2210 and 2215. MTU signaling in RSVP is disabled by default.

To avoid packet loss due to MTU mismatches, the ingress router needs to do the following:

• Signal the MTU on the RSVP LSP—To prevent packet loss from an MTU mismatch,
the ingress router needs to know what the smallest MTU value is along the path taken
by the LSP. Once this MTU value is obtained, the ingress router can assign it to the LSP.

• Fragment packets—Using the assigned MTU value, packets that exceed the size of the
MTU can be fragmented into smaller packets on the ingress router before they are
encapsulated in MPLS and sent over the RSVP-signaled LSP.

Once both MTU signaling and packet fragmentation have been enabled on an ingress
router, any route resolving to an RSVP LSP on this router uses the signaled MTU value.
For information about how to configure this feature, see “Configuring MTU Signaling in
RSVP” on page 418.

Copyright © 2012, Juniper Networks, Inc. 383

Junos OS 12.1 MPLS Applications Configuration Guide

The following sections describe how MTU signaling in RSVP works:

• How the Correct MTU Is Signaled in RSVP on page 384

• Determining an Outgoing MTU Value on page 384

• MTU Signaling in RSVP Limitations on page 385

How the Correct MTU Is Signaled in RSVP

How the correct MTU is signaled in RSVP varies depending on whether the network
devices (for example, routers) explicitly support MTU signaling in RSVP or not.

If the network devices support MTU signaling in RSVP, the following occur when you
enable MTU signaling:

• The MTU is signaled from the ingress router to the egress router by means of the Adspec
object. Before forwarding this object, the ingress router enters the MTU value associated
with the interface over which the path message is sent. At each hop in the path, the
MTU value in the Adspec object is updated to the minimum of the received value and
the value of the outgoing interface.

• The ingress router uses the traffic specification (Tspec) object to specify the parameters
for the traffic it is going to send. The MTU value signaled for the Tspec object at the
ingress router is the maximum MTU value (9192 bytes). This value does not change
en route to the egress router.

• When the Adspec object arrives at the egress router, the MTU value is correct for the
path (meaning it is the smallest MTU value discovered). The egress router compares
the MTU value in the Adspec object to the MTU value in the Tspec object. It signals
the smaller MTU using the Flowspec object in the Resv message.

• When the Resv object arrives at the ingress router, the MTU value in this object is used
as the MTU for the next hops that use the LSP.

In a network where there are devices that do not support MTU signaling in RSVP, you
might have the following behaviors:

• If the egress router does not support MTU signaling in RSVP, the MTU is set to 1,500
bytes by default.

• A Juniper Networks transit router that does not support MTU signaling in RSVP sets
an MTU value of 1,500 bytes in the Adspec object by default.

Determining an Outgoing MTU Value

The outgoing MTU value is the smaller of the values received in the Adspec object
compared to the MTU value of the outgoing interface. The MTU value of the outgoing
interface is determined as follows:

• If you configure an MTU value under the [family mpls] hierarchy level, this value is
signaled.

384 Copyright © 2012, Juniper Networks, Inc.

 Chapter 11: RSVP Overview

• If you do not configure an MTU, the inet MTU is signaled.

MTU Signaling in RSVP Limitations

The following are limitations to MTU signaling in RSVP:

• Changes in the MTU value might cause a temporary loss of traffic in the following
situations:

• For link protection and node protection, the MTU of the bypass is only signaled at
the time the bypass becomes active. During the time it takes for the new path MTU
to be propagated, packet loss might occur because of an MTU mismatch.

• For fast reroute, the MTU of the path is updated only after the detour becomes active,
causing a delay in an update to the MTU at the ingress router. Until the MTU is
updated, packet loss might occur if there is an MTU mismatch.

In both cases, only packets that are larger than the detour or bypass MTU are lost.

• When an MTU is updated, it triggers a change in the next hop. Any change in the next
hop causes the route statistics to be lost.

• The minimum MTU supported for MTU signaling in RSVP is 1,488 bytes. This value
prevents a false or incorrectly configured value from being used.

• For single-hop LSPs, the MTU value displayed by the show commands is the
RSVP-signaled value. However, this MPLS value is ignored and the correct IP value is
used.

Fast Reroute, Node Protection, and Link Protection

RFC 4090, Fast Reroute Extensions to RSVP-TE for LSP Tunnels, describes two different
types of traffic protection for RSVP-signaled LSPs:

• One-to-one backup—In the Junos OS this type of traffic protection is provided by fast
reroute. Each LSP requires a protecting LSP to be signaled at each hop except the
egress router. This protecting LSP cannot be shared.

• Facility backup—This is sometimes called many-to-one backup. In the Junos OS this

type of traffic protection is provided by node and link protection. Each LSP requires a
protecting LSP to be signaled at each hop except the egress router. Unlike fast reroute,
this protecting LSP can be shared by other LSPs.

Table 7 on page 385 summarizes the traffic protection types.

Table 7: One-to-One Backup Compared with Facility Backup

Comparison One-to-One Backup Facility Backup

Name of the protecting LSP Detour LSP Bypass LSP

Sharing of the protecting LSP Cannot be shared Can be shared by multiple

LSPs

Copyright © 2012, Juniper Networks, Inc. 385

Junos OS 12.1 MPLS Applications Configuration Guide

Table 7: One-to-One Backup Compared with Facility Backup (continued)

Comparison One-to-One Backup Facility Backup

Junos configuration statements fast-reroute node-link-protection and

link-protection

Link Protection

Link protection helps to ensure that traffic going over a specific interface to a neighboring
router can continue to reach this router if that interface fails. When link protection is
configured for an interface and an LSP that traverses this interface, a bypass LSP is
created that will handle this traffic if the interface fails. The bypass LSP uses a different
interface and path to reach the same destination. The path used can be configured
explicitly, or you can rely on CSPF. The RSVP metric for the bypass LSP is set in the range
of 20,000 through 29,999 (this value is not user configurable).

If a link-protected interface fails, traffic is quickly switched to the bypass LSP. Note that
a bypass LSP cannot share the same egress interface with the LSPs it monitors.

In Figure 24 on page 386, link protection is enabled on Interface B between Router 1 and
Router 2. It is also enabled on LSP A, an LSP that traverses the link between Router 1 and
Router 2. If the link between Router 1 and Router 2 fails, traffic from LSP A is quickly
switched to the bypass LSP generated by link protection.

Figure 24: Link Protection Creating a Bypass LSP for the Protected
Interface

Although LSPs traversing an interface can be configured to take advantage of link

protection, it is important to note that it is specifically the interface that benefits from
link protection. If link protection is enabled on an interface but not on a particular LSP
traversing that interface, then if the interface fails, that LSP will also fail.

NOTE: Link protection does not work on unnumbered interfaces.

To protect traffic over the entire route taken by an LSP, you should configure fast reroute.
For more information, see “Configuring Fast Reroute” on page 152.

The following sections provide more information on link protection:

• Fast Reroute, Node Protection, and Link Protection on page 385

386 Copyright © 2012, Juniper Networks, Inc.

 Chapter 11: RSVP Overview

• Multiple Bypass LSPs on page 387

Multiple Bypass LSPs

By default, link protection relies on a single bypass LSP to provide path protection for an
interface. However, you can also specify multiple bypass LSPs to provide link protection
for an interface. You can individually configure each of these bypass LSPs or create a
single configuration for all of the bypass LSPs. If you do not configure the bypass LSPs
individually, they all share the same path and bandwidth constraints.

The following algorithm describes how and when an additional bypass LSP is activated
for an LSP:

1. If any currently active bypass can satisfy the requirements of the LSP (bandwidth,
link protection, or node-link protection), the traffic is directed to that bypass.

2. If no active bypass LSP is available, scan through the manual bypass LSPs in first-in,
first-out (FIFO) order, skipping those that are already active (each manual bypass
can only be activated once). The first inactive manual bypass that can satisfy the
requirements is activated and traffic is directed to that bypass.

3. If no manual bypass LSPs are available and if the max-bypasses statement activates
multiple bypass LSPs for link protection, determine whether an automatically
configured bypass LSP can satisfy the requirements. If an automatically configured
bypass LSP is available and if the total number of active automatically configured
bypass LSPs does not exceed the maximum bypass LSP limit (configured with the
max-bypasses statement), activate another bypass LSP.

For information about how to configure multiple bypass LSPs for link protection, see
“Configuring Bypass LSPs” on page 405.

Node Protection

Node protection extends the capabilities of link protection. Link protection helps to ensure
that traffic going over a specific interface to a neighboring router can continue to reach
this router if that interface fails. Node protection ensures that traffic from an LSP traversing
a neighboring router can continue to reach its destination even if the neighboring router
fails.

When you enable node protection for an LSP, you must also enable link protection. Once
enabled, node protection and link protection establish the following types of bypass
LSPs:

• Next-hop bypass LSP—Provides an alternate route for an LSP to reach a neighboring

router. This type of bypass LSP is established when you enable either node protection
or link protection.

• Next-next-hop bypass LSP—Provides an alternate route for an LSP to get around a

neighboring router en route to the destination router. This type of bypass LSP is
established exclusively when node protection is configured. If a next-next-hop bypass
LSP cannot be created, an attempt is made to signal a next-hop bypass LSP.

Copyright © 2012, Juniper Networks, Inc. 387

Junos OS 12.1 MPLS Applications Configuration Guide

In Figure 25 on page 388, node protection is enabled on Interface B on Router 1. Node

protection is also enabled on LSP A, an LSP that traverses the link transiting Router 1,
Router 2, and Router 3. If Router 2 suffers a hardware or software failure, traffic from LSP
A is switched to the next-next-hop bypass LSP generated by node protection.

Figure 25: Node Protection Creating a Next-Next-Hop Bypass LSP

Interface B
LSP A LSP A
1 2 3

g017083
Next-Next-Hop Bypass LSP for Interface B

The time needed by node protection to switch traffic to a next-next-hop bypass LSP can
be significantly longer than the time needed by link protection to switch traffic to a
next-hop bypass LSP. Link protection relies on a hardware mechanism to detect a link
failure, allowing it to quickly switch traffic to a next-hop bypass LSP.

Node failures are often due to software problems on the node router. Node protection
relies on the receipt of hello messages from a neighboring router to determine whether
it is still functioning. The time it takes node protection to divert traffic partly depends on
how often the node router sends hello messages and how long it takes the node-protected
router to react to having not received a hello message. However, once the failure is
detected, traffic can be quickly diverted to the next-next-hop bypass LSP.

NOTE:
Node protection provides traffic protection in the event of an error or
interruption of the physical link between two routers. It does not provide
protection in the event of control plane errors. The following provides an
example of a control plane error:

• A transit router changes the label of a packet due to a control plane error.

• When the ingress router receives the packet, it considers the label change
to be a catastrophic event and deletes both the primary LSP and the
associated bypass LSP.

Related • Configuring Node Protection or Link Protection for LSPs on page 402
Documentation

RSVP Graceful Restart

RSVP graceful restart allows a router undergoing a restart to inform its adjacent neighbors
of its condition. The restarting router requests a grace period from the neighbor or peer,
which can then cooperate with the restarting router. The restarting router can still forward
MPLS traffic during the restart period; convergence in the network is not disrupted. The
restart is not visible to the rest of the network, and the restarting router is not removed

388 Copyright © 2012, Juniper Networks, Inc.

 Chapter 11: RSVP Overview

from the network topology. RSVP graceful restart can be enabled on both transit routers
and ingress routers. It is available for both point-to-point LSPs and point-to-multipoint
LSPs.

RSVP graceful restart is described in the following sections:

• RSVP Graceful Restart Standard on page 389

• RSVP Graceful Restart Terminology on page 389

• RSVP Graceful Restart Operation on page 389

• Processing the Restart Cap Object on page 390

RSVP Graceful Restart Standard

RSVP graceful restart is described in RFC 3473, Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)
Extensions (only Section 9, “Fault Handling”).

RSVP Graceful Restart Terminology

R
Recovery time Applies only when the control channel is up (the hello exchange is complete) before the restart
(in milliseconds) time. Applies only to nodal faults.

When a graceful restart is in progress, the time left to complete a recovery is advertised. At
other times, this value is zero. The maximum advertised recovery time is 2 minutes (120,000
milliseconds).

During the recovery time, a restarting node attempts to recover its lost states with assistance
from its neighbors. The neighbor of the restarting node must send the path messages with the
recovery labels to the restarting node within a period of one-half the recovery time. The
restarting node considers its graceful restart complete after its advertised recovery time.

Restart time The default value is 60,000 milliseconds (1 minute). The restart time is advertised in the hello
(in milliseconds) message. The time indicates how long a neighbor should wait to receive a hello message from
a restarting router before declaring that router dead and purging states.

The Junos OS can override a neighbor’s advertised restart time if the time is greater than
one-third the local restart time. For example, given the default restart time of 60 seconds, a
router would wait 20 seconds or less to receive a hello message from a restarting neighbor. If
the restart time is zero, the restarting neighbor can immediately be declared dead.

RSVP Graceful Restart Operation

For RSVP graceful restart to function, the feature must be enabled on the global routing
instance. RSVP graceful restart can be disabled at the protocol level (for RSVP alone)
or at the global level for all protocols.

Copyright © 2012, Juniper Networks, Inc. 389

Junos OS 12.1 MPLS Applications Configuration Guide

RSVP graceful restart requires the following of a restarting router and the router’s
neighbors:

• For the restarting router, RSVP graceful restart attempts to maintain the routes installed
by RSVP and the allocated labels, so that traffic continues to be forwarded without
disruption. RSVP graceful restart is done quickly enough to reduce or eliminate the
impact on neighboring nodes.

• The neighboring routers must have RSVP graceful restart helper mode enabled, thus
allowing them to assist a router attempting to restart RSVP.

An object called Restart Cap that is sent in RSVP hello messages advertises a node’s
restart capability. The neighboring node sends a Recover Label object to the restarting
node to recover its forwarding state. This object is essentially the old label that the
restarting node advertised before the node went down.

The following lists the RSVP graceful restart behaviors, which vary depending on the
configuration and on which features are enabled:

• If you disable helper mode, the Junos OS does not attempt to help a neighbor restart
RSVP. Any information that arrives with a Restart Cap object from a neighbor is ignored.

• When you enable graceful restart under the routing instance configuration, the router
can restart gracefully with the help of its neighbors. RSVP advertises a Restart Cap
object (RSVP RESTART) in hello messages in which restart and recovery times are
specified (neither value is 0).

• If you explicitly disable RSVP graceful restart under the [protocols rsvp] hierarchy level,
the Restart Cap object is advertised with restart and recovery times specified as 0. The
restart of neighboring routers is supported (unless helper mode is disabled), but the
router itself does not preserve the RSVP forwarding state and cannot recover its control
state.

• If after a restart RSVP realizes that no forwarding state has been preserved, the Restart
Cap object is advertised with restart and recovery times specified as 0.

• If graceful restart and helper mode are disabled, RSVP graceful restart is completely
disabled. The router neither recognizes nor advertises the RSVP graceful restart objects.

You cannot explicitly configure values for the restart and recovery times.

Unlike other protocols, there is no way for RSVP to determine that it has completed a
restart procedure, other than a fixed timeout. All RSVP graceful restart procedures are
timer-based. A show rsvp version command might indicate that the restart is still in
progress even if all RSVP sessions are back up and the routes are restored.

Processing the Restart Cap Object

The following assumptions are made about a neighbor based on the Restart Cap object
(assuming that a control channel failure can be distinguished unambiguously from a
node restart):

390 Copyright © 2012, Juniper Networks, Inc.

 Chapter 11: RSVP Overview

• A neighbor that does not advertise the Restart Cap object in its hello messages cannot
assist a router with state or label recovery, nor can it perform an RSVP graceful restart.

• After a restart, a neighbor advertising a Restart Cap object with a restart time equal to
any value and a recovery time equal to 0 has not preserved its forwarding state. When
a recovery time equals 0, the neighbor is considered dead and any states related to
this neighbor are purged, regardless of the value of the restart time.

• After a restart, a neighbor advertising its recovery time with a value other than 0 can
keep or has kept the forwarding state. If the local router is helping its neighbor with
restart or recovery procedures, it sends a Recover Label object to this neighbor.

Copyright © 2012, Juniper Networks, Inc. 391

Junos OS 12.1 MPLS Applications Configuration Guide

392 Copyright © 2012, Juniper Networks, Inc.

CHAPTER 12

RSVP Configuration Guidelines

This chapter describes how to configure RSVP and discusses the following configuration
tasks:

• Minimum RSVP Configuration on page 393

• Configuring RSVP and MPLS on page 394
• Configuring RSVP Interfaces on page 395
• Configuring RSVP Node ID Hellos on page 401
• Configuring Hello Acknowledgments for Nonsession RSVP Neighbors on page 401
• Configuring Node Protection or Link Protection for LSPs on page 402
• Switching LSPs Away from a Network Node on page 403
• Configuring Inter-AS Node and Link Protection on page 404
• Configuring Link Protection on Interfaces Used by LSPs on page 404
• Configuring RSVP Setup Protection on page 412
• Configuring RSVP Graceful Restart on page 412
• Configuring Load Balancing Across RSVP LSPs on page 414
• Configuring RSVP Automatic Mesh on page 415
• Configuring Timers for RSVP Refresh Messages on page 416
• Preempting RSVP Sessions on page 417
• Configuring MTU Signaling in RSVP on page 418
• Configuring RSVP to Pop the Label on the Ultimate-Hop Router on page 419
• Disabling Adjacency Down and Neighbor Down Notification in IS-IS and
OSPF on page 420
• Enabling Ultimate-Hop Popping on Point-to-Multipoint LSPs on page 420
• Tracing RSVP Protocol Traffic on page 421

Minimum RSVP Configuration

To enable RSVP on a single interface, include the rsvp statement and specify the interface
using the interface statement. This is the minimum RSVP configuration. All other RSVP
configuration statements are optional.

rsvp {

Copyright © 2012, Juniper Networks, Inc. 393

Junos OS 12.1 MPLS Applications Configuration Guide

interface interface-name;
}

You can include these statements at the following hierarchy levels:

• [edit protocols]

• [edit logical-systems logical-system-name protocols]

To enable RSVP on all interfaces, substitute all for the interface-name variable.

If you have configured interface properties on a group of interfaces and want to disable
RSVP on one of the interfaces, include the disable statement:

interface interface-name {
disable;
}

You can include this statement at the following hierarchy levels:

• [edit protocols rsvp interface interface-name ]

• [edit logical-systems logical-system-name protocols rsvp interface interface-name ]

Configuring RSVP and MPLS

The primary purpose of the Junos RSVP software is to support dynamic signaling within
label-switched paths (LSPs). When you enable both MPLS and RSVP on a router, MPLS
becomes a client of RSVP. No additional configuration is required to bind MPLS and
RSVP.

You can configure MPLS to set up signaled paths by using the label-switched-path
statement at the [edit protocols mpls] hierarchy level. Each LSP translates into a request
for RSVP to initiate an RSVP session. This request is passed through the internal interface
between label switching and RSVP. After examining the request information, checking
RSVP states, and checking the local routing tables, RSVP initiates one session for each
LSP. The session is sourced from the local router and is destined for the target of the
LSP.

When an RSVP session is successfully created, the LSP is set up along the paths created
by the RSVP session. If the RSVP session is unsuccessful, RSVP notifies MPLS of its
status. It is up to MPLS to initiate backup paths or continue retrying the initial path.

To pass label-switching signaling information, RSVP supports four additional objects:

Label Request object, Label object, Explicit Route object, and Record Route object. For
an LSP to be set up successfully, all routers along the path must support MPLS, RSVP,
and the four objects. Of the four objects, the Record Route object is not mandatory.

To configure MPLS and make it a client of RSVP, do the following:

• Enable MPLS on all routers that will participate in the label switching (this is, on all
routers that might be part of a label-switching path).

• Enable RSVP on all routers and on all router interfaces that form the LSP.

394 Copyright © 2012, Juniper Networks, Inc.

 Chapter 12: RSVP Configuration Guidelines

• Configure the routers at the beginning of the LSP.

Example: Configuring RSVP and MPLS

The following shows a sample configuration for a router at the beginning of an LSP:

[edit]
protocols {
mpls {
label-switched-path sf-to-london {
to 192.168.1.4;
}
}
rsvp {
interface so-0/0/0;
}
}

The following shows a sample configuration for all the other routers that form the LSP:

[edit]
protocols {
mpls {
interface so-0/0/0;
}
rsvp {
interface so-0/0/0;
}
}

Configuring RSVP Interfaces

The following sections describe how to configure RSVP interfaces:

• Configuring RSVP Refresh Reduction on page 395

• Configuring the RSVP Hello Interval on page 398
• Configuring RSVP Authentication on page 398
• Configuring the Bandwidth Subscription for Class Types on page 399
• Configuring the RSVP Update Threshold on an Interface on page 399
• Configuring RSVP for Unnumbered Interfaces on page 400

Configuring RSVP Refresh Reduction

You can configure RSVP refresh reduction on each interface by including the following
statements in the interface configuration:

• aggregate—Enable all RSVP refresh reduction features: RSVP message bundling, RSVP
message ID, reliable message delivery, and summary refresh.

• no-aggregate—Disable RSVP message bundling and summary refresh.

• reliable—Enable RSVP message ID and reliable message delivery.

• no-reliable—Disable RSVP message ID, reliable message delivery, and summary refresh.

Copyright © 2012, Juniper Networks, Inc. 395

Junos OS 12.1 MPLS Applications Configuration Guide

For more information on RSVP refresh reduction, see “RSVP Refresh Reduction” on
page 382.

Table 8 on page 396 lists various combinations of the RSVP refresh reduction configuration
statements and how they alter the behavior of the Junos OS. The table describes only
the expected behavior based on the configuration on the router. The actual behavior is
dictated not only by the local configuration on this router, but also on the refresh reduction
capabilities of its RSVP neighbors. Note that by configuring the aggregate statement,
you enable all RSVP refresh reduction features, including reliable message delivery.

Table 8: RSVP Refresh Reduction Behavior

Configuration Statement Send Capability Receive Capability

aggregate or aggregate and RR bit = 1BundleMessage ID BundleAck/Nack (all

reliable (Path/Resv messages)Ack/Nack messages)Summary
(all messages)Summary Refresh Refresh

aggregate and no-reliable RR bit = 1BundleAck/Nack (all BundleMessage ID (all

messages) messages)

reliable or reliable and RR bit = 0Message ID (Path/Resv BundleMessage ID (all

no-aggregate messages)Ack/Nack (all messages)Ack/Nack
messages)

The send capability shown in Table 8 on page 396 lists the RSVP messages and objects
related to RSVP refresh reduction that the router is capable of sending. This does not
mean that all these messages are exchanged between this router and a neighbor. For
example, if the router is configured with the aggregate statement, but RSVP refresh
reduction is not enabled on its neighbor, then no Summary Refresh message is sent to
this neighbor even though the router is capable of sending it.

The receive capability shown in Table 8 on page 396 lists the messages and objects related
to RSVP refresh reduction that the router is capable of receiving and processing without
generating any errors or resulting in error conditions.

If the no-reliable statement is configured on the router (reliable message delivery is

disabled), the router accepts RSVP messages that include the Message ID object but
ignore the Message ID object and continue performing standard message processing.
No error is generated in this case, and RSVP operates normally.

However, not all combinations between two neighbors with different refresh reduction
capabilities function correctly. For example, a router is configured with either the aggregate
statement and no-reliable statement or with the reliable and no-aggregate statements.
If an RSVP neighbor sends a Summary Refresh object to this router, no error is generated,
but the Summary Refresh object cannot be processed. Consequently, RSVP states can
time out on this router if the neighbor is relying only on Summary Refresh to refresh those
RSVP states.

We recommend, unless there are specific requirements, that you configure RSVP refresh
reduction in a similar manner on each RSVP neighbor.

396 Copyright © 2012, Juniper Networks, Inc.

 Chapter 12: RSVP Configuration Guidelines

To enable all RSVP refresh reduction features on an interface, include the aggregate
statement:

aggregate;

You can include this statement at the following hierarchy levels:

• [edit protocols rsvp interface interface-name]

• [edit logical-systems logical-system-name protocols rsvp interface interface-name]

To disable RSVP message bundling and summary refresh, include the no-aggregate
statement:

no-aggregate;

You can include this statement at the following hierarchy levels:

• [edit protocols rsvp interface interface-name]

• [edit logical-systems logical-system-name protocols rsvp interface interface-name]

To enable RSVP message ID and reliable message delivery on an interface, include the
reliable statement:

reliable;

You can include this statement at the following hierarchy levels:

• [edit protocols rsvp interface interface-name]

• [edit logical-systems logical-system-name protocols rsvp interface interface-name]

To disable RSVP message ID, reliable message delivery, and summary refresh, include
the no-reliable statement:

no-reliable;

You can include this statement at the following hierarchy levels:

• [edit protocols rsvp interface interface-name]

• [edit logical-systems logical-system-name protocols rsvp interface interface-name]

Determining the Refresh Reduction Capability of RSVP Neighbors

To determine the RSVP refresh reduction capability of an RSVP neighbor, you need the
following information:

• The RR bit advertised by the neighbor

• The local configuration of RSVP refresh reduction

• The actual RSVP messages received from the neighbor

To obtain this information, you can issue a show rsvp neighbor detail command. Sample
output follows:

user@host> show rsvp neighbor detail

Copyright © 2012, Juniper Networks, Inc. 397

Junos OS 12.1 MPLS Applications Configuration Guide

RSVP neighbor: 6 learned

Address: 192.168.224.178 via: fxp1.0 status: Up
Last changed time: 10:06, Idle: 5 sec, Up cnt: 1, Down cnt: 0
Message received: 36
Hello: sent 69, received: 69, interval: 9 sec
Remote instance: 0x60b8feba, Local instance: 0x74bc7a8d
Refresh reduction: not operational

Address: 192.168.224.186 via: fxp2.0 status: Down

Last changed time: 10:17, Idle: 40 sec, Up cnt: 0, Down cnt: 0
Message received: 6
Hello: sent 20, received: 0, interval: 9 sec
Remote instance: 0x0, Local instance: 0x2ae1b339
Refresh reduction: incomplete
Remote end: disabled, Ack-extension: enabled

Address: 192.168.224.188 via: fxp2.0 status: Up

Last changed time: 4:15, Idle: 0 sec, Up cnt: 1, Down cnt: 0
Message received: 55
Hello: sent 47, received: 31, interval: 9 sec
Remote instance: 0x6436a35b, Local instance: 0x663849f0
Refresh reduction: operational
Remote end: enabled, Ack-extension: enabled

For more information on the show rsvp neighbor detail command, see the Junos OS Routing
Protocols and Policies Command Reference.

Configuring the RSVP Hello Interval

RSVP monitors the status of the interior gateway protocol (IGP) (IS-IS or OSPF) neighbors
and relies on the IGP protocols to detect when a node fails. If an IGP protocol declares
a neighbor down (because hello packets are no longer being received), RSVP also brings
down that neighbor. However, the IGP protocols and RSVP still act independently when
bringing a neighbor up.

For Juniper Networks routers, configuring a shorter or longer RSVP hello interval has no
impact on whether or not an RSVP session is brought down. RSVP sessions are kept up
even if RSVP hello packets are no longer being received. RSVP sessions are maintained
until either the router stops receiving IGP hello packets or the RSVP Path and Resv
messages time out.

However, the RSVP hello interval might impact when another vendor’s equipment brings
down an RSVP session. For example, a neighboring non-Juniper Networks router might
be configured to monitor RSVP hello packets.

To modify how often RSVP sends hello packets, include the hello-interval statement:

hello-interval seconds;

For a list of hierarchy levels at which you can include this statement, see the statement
summary section.

Configuring RSVP Authentication

All RSVP protocol exchanges can be authenticated to guarantee that only trusted
neighbors participate in setting up reservations. By default, RSVP authentication is
disabled.

398 Copyright © 2012, Juniper Networks, Inc.

 Chapter 12: RSVP Configuration Guidelines

RSVP authentication uses a Hashed Message Authentication Code (HMAC)-MD5

message-based digest. This scheme produces a message digest based on a secret
authentication key and the message contents. (The message contents also include a
sequence number.) The computed digest is transmitted with RSVP messages. Once you
have configured authentication, all received and transmitted RSVP messages with all
neighbors are authenticated on this interface.

MD5 authentication provides protection against forgery and message modification. It

also can prevent replay attacks. However, it does not provide confidentiality, because
all messages are sent in clear text.

By default, authentication is disabled. To enable authentication, configure a key on each

interface by including the authentication-key statement:

authentication-key key;

You can include this statement at the following hierarchy levels:

• [edit protocols rsvp interface interface-name]

• [edit logical-systems logical-system-name protocols rsvp interface interface-name]

Configuring the Bandwidth Subscription for Class Types

By default, RSVP allows 100 percent of the bandwidth for a class type to be used for
RSVP reservations. When you oversubscribe a class type for a multiclass LSP, the
aggregate demand of all RSVP sessions is allowed to exceed the actual capacity of the
class type.

For detailed instructions on how to configure the bandwidth subscription for class types,
see “Configuring the Bandwidth Subscription Percentage for LSPs” on page 201.

Configuring the RSVP Update Threshold on an Interface

The interior gateway protocols (IGPs) maintain the traffic engineering database, but the
current available bandwidth on the traffic engineering database links originates from
RSVP. When a link’s bandwidth changes, RSVP informs the IGPs, which can then update
the traffic engineering database and forward the new bandwidth information to all
network nodes. The network nodes then know how much bandwidth is available on the
traffic engineering database link (local or remote), and CSPF can correctly compute the
paths.

However, IGP updates can consume excessive system resources. Depending on the
number of nodes in a network, it might not be desirable to perform an IGP update for
small changes in bandwidth. By configuring the update-threshold statement at the [edit
protocols rsvp] hierarchy level, you can adjust the threshold at which a change in the
reserved bandwidth triggers an IGP update.

You can configure a value of from 1 percent through 20 percent (the default is 10 percent)
for when to trigger an IGP update. If the change in the reserved bandwidth is greater than
or equal to the configured threshold percentage of the static bandwidth on that interface,
then an IGP update occurs. For example, if you have configured the update-threshold
statement to be 15 percent and the router discovers that the reserved bandwidth on a

Copyright © 2012, Juniper Networks, Inc. 399

Junos OS 12.1 MPLS Applications Configuration Guide

link has changed by 10 percent of the link bandwidth, RSVP does not trigger an IGP update.
However, if the reserved bandwidth on a link changes by 20 percent of the link bandwidth,
RSVP triggers an IGP update.

To adjust the threshold at which a change in the reserved bandwidth triggers an IGP
update, include the update-threshold statement:

update-threshold percentage;

You can include this statement at the following hierarchy levels:

• [edit protocols rsvp interface interface-name]

• [edit logical-systems logical-system-name protocols rsvp interface interface-name]

Because of the update threshold, it is possible for Constrained Shortest Path First (CSPF)
to compute a path using outdated traffic engineering database bandwidth information
on a link. If RSVP attempts to establish an LSP over that path, it might find that there is
insufficient bandwidth on that link. When this happens, RSVP triggers an IGP traffic
engineering database update, flooding the updated bandwidth information on the
network. CSPF can then recompute the path by using the updated bandwidth information,
and attempt to find a different path, avoiding the congested link. Note that this
functionality is the default and does not need any additional configuration.

You can configure the rsvp-error-hold-time statement at the [edit protocols mpls] hierarchy
level or the [edit logical-systems logical-system-name protocols mpls] hierarchy level to
improve the accuracy of the traffic engineering database (including the accuracy of
bandwidth estimates for LSPs) using information provided by PathErr messages. See
“Improving Traffic Engineering Database Accuracy with RSVP PathErr Messages” on
page 63.

Configuring RSVP for Unnumbered Interfaces

The Junos OS supports RSVP traffic engineering over unnumbered interfaces. Traffic
engineering information about unnumbered links is carried in the IGP traffic engineering
extensions for OSPF and IS-IS as described in RFC 4203, OSPF Extensions in Support of
Generalized Multi-Protocol Label Switching (GMPLS), and RFC 4205, Intermediate System
to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label
Switching (GMPLS). Unnumbered links can also be specified in the MPLS traffic
engineering signaling as described in RFC 3477, Signalling Unnumbered Links in Resource
ReSerVation Protocol - Traffic Engineering (RSVP-TE). This feature allows you avoid
having to configure IP addresses for each interface participating in the RSVP-signaled
network.

To configure RSVP for unnumbered interfaces, you must configure the router with a
router ID using the router-id statement specified at the [edit routing-options] hierarchy
level. The router ID must be available for routing (you can typically use the loopback
address). The RSVP control messages for the unnumbered links are sent using the router
ID address (rather than a randomly selected address).

To configure link protection and fast reroute on a router with unnumbered interfaces
enabled, you must configure at least two addresses. We recommend that you configure
a secondary interface on the loopback in addition to configuring the router ID.

400 Copyright © 2012, Juniper Networks, Inc.

 Chapter 12: RSVP Configuration Guidelines

Configuring RSVP Node ID Hellos

You can configure node-ID based RSVP hellos to ensure that Juniper Networks routers
can interoperate with the equipment of other vendors. By default, the Junos OS uses
interface-based RSVP hellos. Node-ID based RSVP hellos are specified in RFC 4558,
Node-ID Based Resource Reservation Protocol (RSVP) Hello: A Clarification Statement.
RSVP node-ID hellos are useful if you have configured BFD to detect problems over RSVP
interfaces, allowing you to disable interface-hellos for these interfaces. You can also use
node-ID hellos for graceful-restart procedures.

Node-ID hellos can be enabled globally for all RSVP neighbors. By default, node-ID hello
support is disabled. If you have not enabled RSVP node IDs on the router, the Junos OS
does not accept any node-ID hello packets.

To enable RSVP node-ID hellos globally on the router, include the node-hello statement:

node-hello;

You can include this statement at the following hierarchy levels:

• [edit protocols rsvp]

• [edit logical-systems logical-systems-name protocols rsvp]

You can also explicitly disable RSVP interface hellos globally. This type of configuration
might be necessary in networks where the Juniper Networks router has numerous RSVP
connections with equipment from other vendors. However, if you disable RSVP interface
hellos globally, you can also configure a hello interval on an RSVP interface using the
hello-interval statement. This configuration disables RSVP interface hellos globally, but
enables RSVP interface hellos on the specified interface (the RSVP interface you configure
the hello-interval statement on). This configuration might be necessary in a heterogeneous
network in which some devices support RSVP node ID hellos and other devices support
RSVP interface hellos.

To disable RSVP interface hellos globally on the router, include the no-interface-hello
statement:

no-interface-hello;

You can include this statement at the following hierarchy levels:

• [edit protocols rsvp]

• [edit logical-systems logical-systems-name protocols rsvp]

Configuring Hello Acknowledgments for Nonsession RSVP Neighbors

The hello-acknowledgements statement controls the hello acknowledgment behavior

between RSVP neighbors regardless of whether or not they are in the same session.

Hello messages received from RSVP neighbors that are not part of a common RSVP
session are discarded. If you configure the hello-acknowledgements statement at the
[edit protocols rsvp] hierarchy level, hello messages from nonsession neighbors are

Copyright © 2012, Juniper Networks, Inc. 401

Junos OS 12.1 MPLS Applications Configuration Guide

acknowledged with a hello acknowledgment message. When hellos are received from
nonsession neighbors, an RSVP neighbor relationship is created and periodic hello
messages can now be received from the nonsession neighbor. The
hello-acknowledgements statement is disabled by default. Configuring this statement
allows RSVP-capable routers to be discovered using hello packets and verifies that the
interface is able to receive RSVP packets before sending any MPLS LSP setup messages.

Once you enable hello acknowledgments for nonsession RSVP neighbors, the router
continues to acknowledge hello messages from any nonsession RSVP neighbors unless
the interface itself goes down or you change the configuration. Interface-based neighbors
are not automatically aged out.

hello-acknowledgements;

You can include this statement at the following hierarchy levels:

• [edit protocols rsvp]

• [edit logical-systems logical-system-name protocols rsvp]

Configuring Node Protection or Link Protection for LSPs

When you configure node protection or link protection on a router, bypass LSPs are
created to the next-hop or next-next-hop routers for the LSPs traversing the router. You
must configure node protection or link protection for each LSP that you want protected.
To extend protection along the entire path used by an LSP, you must configure protection
on each router that the LSP traverses.

You can configure node protection or link protection for both static and dynamic LSPs.

To configure node protection on a router for a specified LSP, include the

node-link-protection statement:

node-link-protection;

You can include this statement at the following hierarchy levels:

• [edit protocols mpls label-switched-path lsp-name]

• [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name]

To configure link protection on a router for a specified LSP, include the link-protection
statement:

link-protection;

You can include this statement at the following hierarchy levels:

• [edit protocols mpls label-switched-path lsp-name]

• [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name]

402 Copyright © 2012, Juniper Networks, Inc.

 Chapter 12: RSVP Configuration Guidelines

NOTE: To complete the configuration of node or link protection, you must

also configure link protection on all unidirectional RSVP interfaces that the
LSPs traverse, as described in “Configuring Link Protection on Interfaces Used
by LSPs” on page 404.

Switching LSPs Away from a Network Node

You can configure the router to switch active LSPs away from a network node using a
bypass LSP enabled for an interface. This feature might be used to maintain active
networks when a device needs to be replaced without interrupting traffic transiting the
network. The LSPs can be either static or dynamic.

1. You first need to configure either link or node protection for the traffic that needs to
pass around the network device you intend to disable. To function properly, the bypass
LSP must use a different logical interface than the protected LSP.

2. To prepare the router to begin switching traffic away from a network node, configure
the always-mark-connection-protection-tlv statement:

always-mark-connection-protection-tlv;

The router then marks all OAM traffic transiting this interface in preparation for
switching the traffic to an alternate path based on the OAM functionality.

You can configure this statement at the following hierarchy levels:

• [edit protocols mpls interface interface-name]

• [edit logical-systems logical-system-name protocols mpls interface interface-name]

3. You then need to configure the switch-away-lsps statement to switch the traffic from
the protected LSP to the bypass LSP, effectively bypassing the default downstream
network device. The actual link itself is not brought down by this configuration.

To configure the router to switch traffic away from a network node, configure the
switch-away-lsps statement:

switch-away-lsps;

You can configure this statement at the following hierarchy levels:

• [edit protocols mpls interface interface-name]

• [edit logical-systems logical-system-name protocols mpls interface interface-name]

Note the following limitations related to switching active LSPs away from a network
node:

• The switch-away feature is supported on MX Series routers only.

• The switch-away feature is not supported for switching traffic from primary
point-to-multipoint LSPs to bypass point-to-multipoint LSPs. If you configure the
switch-away-lsps statement for a point-to-multipoint LSP, traffic is not switched to
the bypass point-to-multipoint LSP.

Copyright © 2012, Juniper Networks, Inc. 403

Junos OS 12.1 MPLS Applications Configuration Guide

• If you configure the switch-away feature on an interface along the path of a dynamic
LSP, new dynamic LSPs cannot be established over that path. The switch-away feature
prevents the make-before-break behavior of RSVP-signaled LSPs. The
make-before-break behavior normally causes the router to first attempt to re-signal
a dynamic LSP before tearing down the original.

Related • Configuring Node Protection or Link Protection for LSPs on page 402
Documentation

Configuring Inter-AS Node and Link Protection

To interoperate with other vendors’ equipment, the Junos OS supports the record route
object (RRO) node ID subobject for use in inter-AS link and node protection configurations.
The RRO node ID subobject is defined in RFC 4561, Definition of a Record Route Object
(RRO) Node-Id Sub-Object. This functionality is enabled by default in Junos OS Release 9.4
and later.

If you have Juniper Networks routers running Junos OS Release 9.4 and later releases in
the same MPLS-TE network as routers running Junos OS Release 8.4 and earlier releases,
you might need to disable the RRO node ID subobject by configuring the
no-node-id-subobject statement:

no-node-id-subobject;

You can include this statement at the following hierarchy levels:

• [edit protocols rsvp]

• [edit logical-systems logical-system-name protocols rsvp]

Configuring Link Protection on Interfaces Used by LSPs

When you configure node protection or link protection on a router for LSPs as described
in “Configuring Node Protection or Link Protection for LSPs” on page 402, you also must
configure the link-protection statement on the RSVP interfaces used by the LSPs.

To configure link protection on the interfaces used by the LSPs, include the link-protection
statement:

link-protection {
disable;
admin-group
exclude group-names;
include-all group-names;
include-any group-names;
}
bandwidth bps;
bypass bypass-name {
bandwidth bps;
description text;
hop-limit number;
no-cspf;
path address <strict | loose>;
priority setup-priority reservation-priority;

404 Copyright © 2012, Juniper Networks, Inc.

 Chapter 12: RSVP Configuration Guidelines

to address;
}
class-of-service cos-value;
hop-limit number;
max-bypasses number;
no-cspf;
no-node-protection;
optimize-timer seconds;
path address <strict | loose>;
priority setup-priority reservation-priority;
subscription percent {
ct0 percent;
ct1 percent;
ct2 percent;
ct3 percent;
}
}

You can include this statement at the following hierarchy levels:

• [edit protocols rsvp interface interface-name]

• [edit logical-systems logical-system-name protocols rsvp interface interface-name]

All the statements under link-protection are optional.

The following sections describe how to configure link protection:

• Configuring Bypass LSPs on page 405

• Configuring Administrative Groups for Bypass LSPs on page 406
• Configuring the Bandwidth for Bypass LSPs on page 407
• Configuring Class of Service for Bypass LSPs on page 407
• Configuring the Hop Limit for Bypass LSPs on page 408
• Configuring the Maximum Number of Bypass LSPs on page 408
• Disabling CSPF for Bypass LSPs on page 409
• Disabling Node Protection for Bypass LSPs on page 409
• Configuring the Optimization Interval for Bypass LSPs on page 409
• Configuring an Explicit Path for Bypass LSPs on page 410
• Configuring the Amount of Bandwidth Subscribed for Bypass LSPs on page 411
• Configuring Priority and Preemption for Bypass LSPs on page 411

Configuring Bypass LSPs

You can configure specific bandwidth and path constraints for a bypass LSP. You can
also individually configure each bypass LSP generated when you enable multiple bypass
LSPs. If you do not configure the bypass LSPs individually, they all share the same path
and bandwidth constraints (if any).

If you specify the bandwidth, hop-limit, and path statements for the bypass LSP, these
values take precedence over the values configured at the [edit protocols rsvp interface

Copyright © 2012, Juniper Networks, Inc. 405

Junos OS 12.1 MPLS Applications Configuration Guide

interface-name link-protection] hierarchy level. The other attributes (subscription,

no-node-protection, and optimize-timer) are inherited from the general constraints.

To configure a bypass LSP, specify a name for the bypass LSP using the bypass statement.
The name can be up to 64 characters in length.

bypass bypass-name {
bandwidth bps;
description text;
class-of-service cos-value;
hop-limit number;
no-cspf;
path address <strict | loose>;
priority setup-priority reservation-priority;
to address;
}

You can include this statement at the following hierarchy levels:

• [edit protocols rsvp interface interface-name link-protection]

• [edit logical-systems logical-system-name protocols rsvp interface interface-name

link-protection]

Configuring the Next-Hop or Next-Next-Hop Node Address for Bypass LSPs

If you configure a bypass LSP, you must also configure the to statement. The to statement
specifies the address for the interface of the immediate next-hop node (for link protection)
or the next-next-hop node (for node-link protection). The address specified determines
whether this is a link protection bypass or a node-link protection bypass. On multiaccess
networks (for example, a LAN), this address is also used to specify which next-hop node
is being protected.

Configuring Administrative Groups for Bypass LSPs

Administrative groups, also known as link coloring or resource class, are manually assigned
attributes that describe the “color” of links, such that links with the same color
conceptually belong to the same class. You can use administrative groups to implement
a variety of policy-based LSP setups. You can configure administrative groups for bypass
LSPs. For more information about configuring administrative groups, see “Configuring
Administrative Groups” on page 171.

To configure administrative groups for bypass LSPs, include the admin-group statement:

admin-group {
exclude group-names;
include-all group-names;
include-any group-names;
}

To configure an administrative group for all of the bypass LSPs, include the admin-group
statement at the following hierarchy levels:

• [edit protocols rsvp interface interface-name link-protection]

406 Copyright © 2012, Juniper Networks, Inc.

 Chapter 12: RSVP Configuration Guidelines

• [edit logical-systems logical-system-name protocols rsvp interface interface-name

link-protection]

To configure an administrative groups for a specific bypass LSP, include the admin-group
statement at the following hierarchy levels:

• [edit protocols rsvp interface interface-name link-protection bypass bypass-name]

• [edit logical-systems logical-system-name protocols rsvp interface interface-name

link-protection bypass bypass-name]

Configuring the Bandwidth for Bypass LSPs

You can specify the amount of bandwidth allocated for automatically generated bypass
LSPs or you can individually specify the amount of bandwidth allocated for each LSP.

If you have enabled multiple bypass LSPs, this statement is required.

To specify the bandwidth allocation, include the bandwidth statement:

bandwidth bps;

For automatically generated bypass LSPs, include the bandwidth statement at the
following hierarchy levels:

• [edit protocols rsvp interface interface-name link-protection]

• [edit logical-systems logical-system-name protocols rsvp interface interface-name

link-protection]

For individually configured bypass LSPs, include the bandwidth statement at the following
hierarchy levels:

• [edit protocols rsvp interface interface-name link-protection bypass bypass-name]

• [edit logical-systems logical-system-name protocols rsvp interface interface-name

link-protection bypass bypass-name]

Configuring Class of Service for Bypass LSPs

You can specify the class-of-service value for bypass LSPs by including the class-of-service
statement:

class-of-service cos-value;

To apply a class-of-service value to all the automatically generated bypass LSPs, include
the class-of-service statement at the following hierarchy levels:

• [edit protocols rsvp interface interface-name link-protection]

• [edit logical-systems logical-system-name protocols rsvp interface interface-name

link-protection]

To configure a class-of-service value for a specific bypass LSPs, include the

class-of-service statement at the following hierarchy levels:

Copyright © 2012, Juniper Networks, Inc. 407

Junos OS 12.1 MPLS Applications Configuration Guide

• [edit protocols rsvp interface interface-name link-protection bypass bypass-name]

• [edit logical-systems logical-system-name protocols rsvp interface interface-name

link-protection bypass bypass-name]

Configuring the Hop Limit for Bypass LSPs

You can specify the maximum number of hops a bypass can traverse. By default, each
bypass can traverse a maximum of 255 hops (the ingress and egress routers count as
one hop each, so the minimum hop limit is two).

To configure the hop limit for bypass LSPs, include the hop-limit statement:

hop-limit number;

For automatically generated bypass LSPs, include the hop-limit statement at the following
hierarchy levels:

• [edit protocols rsvp interface interface-name link-protection]

• [edit logical-systems logical-system-name protocols rsvp interface interface-name

link-protection]

For individually configured bypass LSPs, include the hop-limit statement at the following
hierarchy levels:

• [edit protocols rsvp interface interface-name link-protection bypass bypass-name]

• [edit logical-systems logical-system-name protocols rsvp interface interface-name

link-protection bypass bypass-name]

Configuring the Maximum Number of Bypass LSPs

You can specify the maximum number of dynamic bypass LSPs permitted for protecting
an interface using the max-bypasses statement at the [edit protocols rsvp interface
interface-name link-protection] hierarchy level. When this statement is configured, multiple
bypasses for link protection are enabled. Call admission control (CAC) is also enabled.

By default, this option is disabled and only one bypass is enabled for each interface. You
can configure a value of between 0 through 99 for the max-bypasses statement.
Configuring a value of 0 prevents the creation of any dynamic bypass LSPs for the
interface. If you configure a value of 0 for the max-bypasses statement, you need to
configure one or more static bypass LSPs to enable link protection on the interface.

If you configure the max-bypasses statement, you must also configure the bandwidth
statement (discussed in “Configuring the Bandwidth for Bypass LSPs” on page 407).

To configure the maximum number of bypass LSPs for a protected interface, include the
max-bypasses statement:

max-bypasses number;

You can include this statement at the following hierarchy levels:

408 Copyright © 2012, Juniper Networks, Inc.

 Chapter 12: RSVP Configuration Guidelines

• [edit protocols rsvp interface interface-name link-protection]

• [edit logical-systems logical-system-name protocols rsvp interface interface-name

link-protection]

Disabling CSPF for Bypass LSPs

Under certain circumstances, you might need to disable CSPF computation for bypass
LSPs and use the configured Explicit Route Object (ERO) if available. For example, a
bypass LSP might need to traverse multiple OSPF areas or IS-IS levels, preventing the
CSPF computation from working. To ensure that link and node protection function properly
in this case, you have to disable CSPF computation for the bypass LSP.

You can disable CSPF computation for all bypass LSPs or for specific bypass LSPs.

To disable CSPF computation for bypass LSPs, include the no-cspf statement:

no-cspf;

For a list of hierarchy levels where you can include this statement, see the statement
summary for this statement.

Disabling Node Protection for Bypass LSPs

You can disable node protection on the RSVP interface. Link protection remains active.
When this option is configured, the router can only initiate a next-hop bypass, not a
next-next-hop bypass.

To disable node protection for bypass LSPs, include the no-node-protection statement:

no-node-protection;

You can include this statement at the following hierarchy levels:

• [edit protocols rsvp interface interface-name link-protection]

• [edit logical-systems logical-system-name protocols rsvp interface interface-name

link-protection]

Configuring the Optimization Interval for Bypass LSPs

You can configure an optimization interval for bypass LSPs using the optimize-timer
statement. At the end of this interval, an optimization process is initiated that attempts
to either minimize the number of bypasses currently in use, minimize the total amount
of bandwidth reserved for all of the bypasses, or both. You can configure an optimization
interval from 1 through 65,535 seconds. A default value of 0 disables bypass LSP
optimization.

Copyright © 2012, Juniper Networks, Inc. 409

Junos OS 12.1 MPLS Applications Configuration Guide

When you configure the optimize-timer statement, bypass LSPs are reoptimized
automatically when you configure or change the configuration of any of the following:

• Administrative group for a bypass LSP—The configuration for an administrative group

has been changed on a link along the path used by the bypass LSP. Configure an
administrative group using the admin-group statement at the [edit protocols rsvp
interface interface-name link-protection] hierarchy level.

• Fate sharing group—The configuration for a fate sharing group has been changed.
Configure a fate sharing group using the group statement at the [edit routing-options
fate-sharing] hierarchy level.

• IS-IS overload—The configuration for IS-IS overload has been changed on a router
along the path used by the bypass LSP. Configure IS-IS overload using the overload
statement at the [edit protocols isis] hierarchy level.

• IGP metric—The IGP metric has been changed on a link along the path used by the
bypass LSP.

To configure the optimization interval for bypass LSPs, include the optimize-timer
statement:

optimize-timer seconds;

You can include this statement at the following hierarchy levels:

• [edit protocols rsvp interface interface-name link-protection]

• [edit logical-systems logical-system-name protocols rsvp interface interface-name

link-protection]

Configuring an Explicit Path for Bypass LSPs

By default, when you establish a bypass LSP to an adjacent neighbor, CSPF is used to
discover the least-cost path. The path statement allows you to configure an explicit path
(a sequence of strict or loose routes), giving you control over where and how the bypass
LSP is established. To configure an explicit path, include the path statement:

path address <strict | loose>;

For automatically generated bypass LSPs, include the path statement at the following
hierarchy levels:

• [edit protocols rsvp interface interface-name link-protection]

• [edit logical-systems logical-system-name protocols rsvp interface interface-name

link-protection]

For individually configured bypass LSPs, include the path statement at the following
hierarchy levels:

• [edit protocols rsvp interface interface-name link-protection bypass bypass-name]

• [edit logical-systems logical-system-name protocols rsvp interface interface-name

link-protection bypass bypass-name]

410 Copyright © 2012, Juniper Networks, Inc.

 Chapter 12: RSVP Configuration Guidelines

Configuring the Amount of Bandwidth Subscribed for Bypass LSPs

You can configure the amount of bandwidth subscribed to bypass LSPs. You can configure
the bandwidth subscription for the whole bypass LSP or for each class type that might
traverse the bypass LSP. You can configure any value between 1 percent and 65,535
percent. By configuring a value less than 100 percent, you are undersubscribing the bypass
LSPs. By configuring a value greater than 100 percent, you are oversubscribing the bypass
LSPs.

The ability to oversubscribe the bandwidth for the bypass LSPs makes it possible to more
efficiently use network resources. You can configure the bandwidth for the bypass LSPs
based on the average network load as opposed to the peak load.

To configure the amount of bandwidth subscribed for bypass LSPs, include the
subscription statement:

subscription percentage {
ct0 percentage;
ct1 percentage;
ct2 percentage;
ct3 percentage;
}

You can include this statement at the following hierarchy levels:

• [edit protocols rsvp interface interface-name link-protection]

• [edit logical-systems logical-system-name protocols rsvp interface interface-name

link-protection]

Configuring Priority and Preemption for Bypass LSPs

When there is insufficient bandwidth to establish a more important LSP, you might want
to tear down a less important existing LSP to release the bandwidth. You do this by
preempting the existing LSP.

For more detailed information on configuring setup priority and reservation priority for
LSPs, see “Configuring Priority and Preemption for LSPs” on page 179.

To configure the bypass LSP’s priority and preemption properties, include the priority
statement:

priority setup-priority reservation-priority;

For a list of hierarchy levels at which you can include this statement, see the statement
summary section for this statement.

Copyright © 2012, Juniper Networks, Inc. 411

Junos OS 12.1 MPLS Applications Configuration Guide

Configuring RSVP Setup Protection

You can configure the facility-backup fast reroute mechanism to provide setup protection
for LSPs which are in the process of being signaled. Both point-to-point LSPs and
point-to-multipoint LSPs are supported. This feature is applicable in the following
scenario:

1. A failed link or node is present on the strict explicit path of an LSP before the LSP is
signaled.

2. There is also a bypass LSP protecting the link or node.

3. RSVP signals the LSP through the bypass LSP. The LSP appears as if it was originally
set up along its primary path and then failed over to the bypass LSP because of the
link or node failure.

4. When the link or node has recovered, the LSP can be automatically reverted to the
primary path.

You should configure the setup-protection statement at the [edit protocols rsvp] on each
of the routers along the LSP path on which you want to enable LSP setup protection.
You should also configure IGP traffic engineering on all of the routers on the LSP path.
You can issue a show rsvp session command to determine whether or not the LSP has
setup protection enabled on a router acting as a point of local repair (PLR) or a merge
point.

To enable RSVP setup protection, include the setup-protection statement

setup-protection;

You can include this statement at the following hierarchy levels:

• [edit protocols rsvp]

• [edit logical-systems logical-system-name protocols rsvp]

Configuring RSVP Graceful Restart

The following RSVP graceful restart configurations are possible:

• Graceful restart and helper mode are both enabled (the default).

• Graceful restart is enabled but helper mode is disabled. A router configured in this way
can restart gracefully, but cannot help a neighbor with its restart and recovery
procedures.

• Graceful restart is disabled but helper mode is enabled. A router configured in this way
cannot restart gracefully, but can help a restarting neighbor.

• Graceful restart and helper mode both are disabled. This configuration completely
disables RSVP graceful restart (including restart and recovery procedures and helper
mode). The router behaves like a router that does not support RSVP graceful restart.

412 Copyright © 2012, Juniper Networks, Inc.

 Chapter 12: RSVP Configuration Guidelines

NOTE: In order to turn on RSVP graceful restart, you must set the global
graceful restart timer to at least 180 seconds.

The following sections describe how to configure RSVP graceful restart:

• Enabling Graceful Restart for All Routing Protocols on page 413

• Disabling Graceful Restart for RSVP on page 413
• Disabling RSVP Helper Mode on page 413
• Configuring the Maximum Helper Recovery Time on page 413
• Configuring the Maximum Helper Restart Time on page 414

Enabling Graceful Restart for All Routing Protocols

To enable graceful restart for RSVP, you need to enable graceful restart for all the
protocols that support graceful restart on the router. For more information about graceful
restart, see the Junos OS Routing Protocols Configuration Guide.

To enable graceful restart on the router, include the graceful-restart statement:

graceful-restart;

You can include this statement at the following hierarchy levels:

• [edit routing-options]

• [edit logical-systems logical-system-name routing-options]

Disabling Graceful Restart for RSVP

By default, RSVP graceful restart and RSVP helper mode are enabled when you enable
graceful restart. However, you can disable one or both of these capabilities.

To disable RSVP graceful restart and recovery, include the disable statement at the [edit
protocols rsvp graceful-restart] hierarchy level:

disable;

Disabling RSVP Helper Mode

To disable RSVP helper mode, include the helper-disable statement at the [edit protocols
rsvp graceful-restart] hierarchy level:

helper-disable;

Configuring the Maximum Helper Recovery Time

To configure the amount of time the router retains the state of its RSVP neighbors while
they undergo a graceful restart, include the maximum-helper-recovery-time statement
at the [edit protocols rsvp graceful-restart] hierarchy level. This value is applied to all
neighboring routers, so it should be based on the time required by the slowest RSVP
neighbor to recover.

maximum-helper-recovery-time seconds;

Copyright © 2012, Juniper Networks, Inc. 413

Junos OS 12.1 MPLS Applications Configuration Guide

Configuring the Maximum Helper Restart Time

To configure the delay between when the router discovers that a neighboring router has
gone down and when it declares the neighbor down, include the
maximum-helper-restart-time statement at the [edit protocols rsvp graceful-restart]
hierarchy level. This value is applied to all neighboring routers, so it should be based on
the time required by the slowest RSVP neighbor to restart.

maximum-helper-restart-time seconds;

Configuring Load Balancing Across RSVP LSPs

By default, when you have configured several RSVP LSPs to the same egress router, the
LSP with the lowest metric is selected and carries all traffic. If all of the LSPs have the
same metric, one of the LSPs is selected at random and all traffic is forwarded over it.

Alternatively, you can load-balance traffic across all of the LSPs by enabling per-packet
load balancing.

To enable per-packet load balancing on an ingress LSP, configure the policy-statement

statement as follows:

[edit policy-options]
policy-statement policy-name {
then {
load-balance per-packet;
}
accept;
}

You then need to apply this statement as an export policy to the forwarding table. For
more information on how to configure the policy-statement statement, see the Junos OS
Policy Framework Configuration Guide.

Once per-packet load balancing is applied, traffic is distributed equally between the
LSPs (by default).

You need to configure per-packet load balancing if you want to enable PFE fast reroute.
To enable PFE fast reroute, include the policy-statement statement for per-packet load
balancing shown in this section in the configuration of each of the routers where a reroute
might take place. See also “Configuring Fast Reroute” on page 152.

You can also load-balance the traffic between the LSPs in proportion to the amount of
bandwidth configured for each LSP. This capability can better distribute traffic in networks
with asymmetric bandwidth capabilities across external links, since the configured
bandwidth of an LSP typically reflects the traffic capacity of that LSP.

To configure RSVP LSP load balancing, include the load-balance statement with the
bandwidth option:

load-balance {
bandwidth;
}

414 Copyright © 2012, Juniper Networks, Inc.

 Chapter 12: RSVP Configuration Guidelines

You can configure this statement at the following hierarchy levels:

• [edit protocols rsvp]

• [edit logical-systems logical-system-name protocols rsvp]

Keep the following information in mind when you use the load-balance statement:

• If you configure the load-balance statement, the behavior of currently running LSPs is
not altered. To force currently running LSPs to use the new behavior, you can issue a
clear mpls lsp command.

• The load-balance statement only applies to ingress LSPs that have per-packet load
balancing enabled.

• For Differentiated Services–aware traffic engineered LSPs, the bandwidth of an LSP

is calculated by summing the bandwidth of all of the class types.

Configuring RSVP Automatic Mesh

BGP and MPLS VPNs are based on a peer model. To add a new site to an existing VPN,
you need to configure the CE router at the new site and the PE router connected to the
CE router. You do not have to modify the configuration of all of the other PE routers
participating in the VPN. The PE routers automatically learn about the routes associated
with the new site (a process called automatic discovery).

The requirements are a bit different if you need to add a new PE router (as opposed to
a CE router) to the network. A BGP and MPLS VPN requires that the BGP session be fully
meshed and that there also be a full mesh of PE router-to-PE router MPLS LSPs between
all of the PE routers in the network. When you add a new PE router to the network, all of
the existing PE routers must be reconfigured to peer with the new PE router. Much of the
configuration effort can be reduced if you configure BGP route reflectors (mitigating the
full mesh requirement for BGP) and if you configure LDP as the signaling protocol for
MPLS.

However, if you need to add a new PE router to a network configured with a full mesh of
RSVP-signaled LSPs, you need to reconfigure each of the PE routers to have a peer
relationship with the new PE router. You can configure RSVP automatic mesh to address
this particular operational scenario. When you enable RSVP automatic mesh, RSVP LSPs
are dynamically created between a new PE router and the existing PE routers, eliminating
the need to reconfigure all of the PE routers manually. For dynamic tunnel creation to
function properly, BGP must be configured to exchange routes between all of the
participating PE routers. If two BGP peers did not exchange routes, it would not be possible
to configure a dynamic tunnel between them.

RSVP includes numerous capabilities that are not available in LDP, including fast reroute.
RSVP automatic mesh helps to reduce the operation and maintenance requirements for
RSVP, making it possible to deploy RSVP in larger and more complicated networks.

Every PE router can reach every other PE router in the network because this information
is distributed by the IGP. A PE router can set up an RSVP LSP to any other PE router in
the network so long as it knows that such an LSP is required. To build a full mesh of LSPs

Copyright © 2012, Juniper Networks, Inc. 415

Junos OS 12.1 MPLS Applications Configuration Guide

between the PE routers requires that each PE router know which of the other PE routers
make up the full mesh.

You can configure RSVP to establish LSPs automatically for any new PE router added
to a full mesh of LSPs. To enable this feature, you must configure the rsvp-te statement
on all of the PE routers in the full mesh.

NOTE: You cannot configure RSVP automatic mesh in conjunction with CCC.
CCC cannot use the dynamically generated tunnels.

To configure RSVP automatic mesh, include the rsvp-te statement:

rsvp-te {
destination-networks network-prefix;
label-switched-path-template {
default-template;
template-name;
}
}

You can configure these statements at the following hierarchy levels:

• [edit routing-options dynamic-tunnels tunnel-name]

• [edit logical-systems logical-system-name routing-options dynamic-tunnels tunnel-name]

You can configure the following optional statements for RSVP automatic mesh:

• destination-networks—Specify the IP version 4 (IPv4) prefix range for the destination

network. Dynamic tunnels within the specified IPv4 prefix range are allowed to be
initiated.

• label-switched-path-template—You can configure either the default template explicitly

using the default-template option or you can configure an LSP template of your own
using the template-name option. The LSP template acts as a model configuration for
all of the dynamically generated LSPs.

Configuring Timers for RSVP Refresh Messages

RSVP uses two related timing parameters:

• refresh-time—The refresh time controls the interval between the generation of

successive refresh messages. The default value for the refresh time is 45 seconds. This
number is derived from the refresh-time statement’s default value of 30, multiplied by
a fixed value of 1.5. This computation differs from RFC 2205, which states that the
refresh time should be multiplied by a random value in the range from 0.5 through 1.5.

Refresh messages include path and Resv messages. Refresh messages are sent
periodically so that reservation states in neighboring nodes do not time out. Each path
and Resv message carries the refresh timer value, and the receiving node extracts this
value from the messages.

416 Copyright © 2012, Juniper Networks, Inc.

 Chapter 12: RSVP Configuration Guidelines

• keep-multiplier—The keep multiplier is a small, locally configured integer from 1 through

255. The default value is 3. It indicates the number of messages that can be lost before
a particular state is declared stale and must be deleted. The keep multiplier directly
affects the lifetime of an RSVP state.

To determine the lifetime of a reservation state, use the following formula:

lifetime = (keep-multiplier + 0.5) x (1.5 x refresh-time)

In the worst case, (keep-multiplier – 1) successive refresh messages must be lost before
a reservation state is deleted.

We do not recommend configuring a short RSVP hello timer. If quick discovery of a failed
neighbor is needed, configure short IGP (OSPF or IS-IS) hello timers.

By default, the refresh timer value is 30 seconds. To modify this value, include the
refresh-time statement:

refresh-time seconds;

You can include this statement at the following hierarchy levels:

• [edit protocols rsvp]

• [edit logical-systems logical-system-name protocols rsvp]

The default value of the keep multiplier is 3. To modify this value, include the
keep-multiplier statement:

keep-multiplier number;

You can include this statement at the following hierarchy levels:

• [edit protocols rsvp]

• [edit logical-systems logical-system-name protocols rsvp]

Preempting RSVP Sessions

Whenever bandwidth is insufficient to handle all RSVP sessions, you can control the
preemption of RSVP sessions. By default, an RSVP session is preempted only by a new
higher-priority session.

To always preempt a session when the bandwidth is insufficient, include the preemption
statement with the aggressive option:

preemption aggressive;

You can include this statement at the following hierarchy levels:

• [edit protocols rsvp]

• [edit logical-systems logical-system-name protocols rsvp]

Copyright © 2012, Juniper Networks, Inc. 417

Junos OS 12.1 MPLS Applications Configuration Guide

To disable RSVP session preemption, include the preemption statement with the disabled
option:

preemption disabled;

To return to the default (that is, preempt a session only for a new higher-priority session),
include the preemption statement with the normal option:

preemption normal;

You can include this statement at the following hierarchy levels:

• [edit protocols rsvp]

• [edit logical-systems logical-system-name protocols rsvp]

Configuring MTU Signaling in RSVP

To configure maximum transmission unit (MTU) signaling in RSVP, you need to configure
MPLS to allow IP packets to be fragmented before they are encapsulated in MPLS. You
also need to configure MTU signaling in RSVP. For troubleshooting purposes, you can
configure MTU signaling alone without enabling packet fragmentation.

To configure MTU signaling in RSVP, include the path-mtu statement:

path-mtu {
allow-fragmentation;
rsvp {
mtu-signaling;
}
}

You can include this statement at the following hierarchy levels:

• [edit protocols mpls]

• [edit logical-systems logical-system-name protocols mpls]

The following sections describe how to enable packet fragmentation and MTU signaling
in RSVP:

• Enabling MTU Signaling in RSVP on page 418

• Enabling Packet Fragmentation on page 419

Enabling MTU Signaling in RSVP

To enable MTU signaling in RSVP, include the rsvp mtu-signaling statement:

rsvp mtu-signaling;

You can include this statement at the following hierarchy levels:

• [edit protocols mpls path-mtu]

• [edit logical-systems logical-system-name protocols mpls path-mtu]

418 Copyright © 2012, Juniper Networks, Inc.

 Chapter 12: RSVP Configuration Guidelines

Once you have committed the configuration, changes in the MTU signaling behavior for
RSVP take effect the next time the path is refreshed.

You can configure the mtu-signaling statement by itself at the [edit protocols mpls
path-mtu rsvp] hierarchy level. This can be useful for troubleshooting. If you configure
just the mtu-signaling statement, you can use the show rsvp session detail command to
determine what the smallest MTU is on an LSP. The show rsvp session detail command
displays the MTU value received and sent in the Adspec object.

Enabling Packet Fragmentation

To allow IP packets to be fragmented before they are encapsulated in MPLS, include the
allow-fragmentation statement:

allow-fragmentation;

You can include this statement at the following hierarchy levels:

• [edit protocols mpls path-mtu]

• [edit logical-systems logical-system-name protocols mpls path-mtu]

NOTE: Do not configure the allow-fragmentation statement alone. Always

configure it in conjunction with the mtu-signaling statement.

Configuring RSVP to Pop the Label on the Ultimate-Hop Router

You can control the label value advertised on the egress router of an LSP. The default
advertised label is label 3 (Implicit Null label). If label 3 is advertised, the penultimate-hop
router removes the label and sends the packet to the egress router. When ultimate-hop
popping is enabled, label 0 (IP version 4 [IPv4] Explicit Null label) is advertised.
Ultimate-hop popping ensures that any packets traversing an MPLS network include a
label.

To configure ultimate-hop popping for RSVP, include the explicit-null statement:

explicit-null;

You can include this statement at the following hierarchy levels:

• [edit protocols mpls]

• [edit logical-systems logical-system-name protocols mpls]

NOTE: Juniper Networks routers queue packets based on the incoming

label. Routers from other vendors might queue packets differently. Keep
this in mind when working with networks containing routers from multiple
vendors.

Copyright © 2012, Juniper Networks, Inc. 419

Junos OS 12.1 MPLS Applications Configuration Guide

For more information about labels, see “Label Description” on page 27 and “Label
Allocation” on page 28.

Disabling Adjacency Down and Neighbor Down Notification in IS-IS and OSPF

Whenever IS-IS is deactivated, the IS-IS adjacencies are brought down. IS-IS signals to
RSVP to bring down any RSVP neighbors associated with the IS-IS adjacencies, and this
further causes the associated LSPs signaled by RSVP to go down as well.

A similar process occurs whenever OSPF is deactivated. The OSPF neighbors are brought
down. OSPF signals to RSVP to bring down any of the RSVP neighbors associated with
the OSPF neighbors, and this further causes the associated LSPs signaled by RSVP to
go down as well.

If you need to migrate from IS-IS to OSPF or from OSPF to IS-IS, the IGP notification to
RSVP for an adjacency or neighbor down event needs to be ignored. Using the
no-adjacency-down-notification or no-neighbor-down-notification statements, you can
disable IS-IS adjacency down notification or OSPF neighbor down notification,
respectively, until the migration is complete. The network administrator is responsible
for configuring the statements before the migration, and then removing them from the
configuration afterward, so that IGP notification can function normally.

To disable adjacency down notification in IS-IS, include the

no-adjacency-down-notification statement:

no-adjacency-down-notification;

You can include this statement at the following hierarchy levels:

• [edit protocols isis interface interface-name]

• [edit logical-systems logical-system-name protocols isis interface interface-name]

To disable neighbor down notification in OSPF, include the no-neighbor-down-notification

statement:

no-neighbor-down-notification;

You can include this statement at the following hierarchy levels:

• [edit protocols ospf area area-id interface interface-name]

• [edit logical-systems logical-system-name protocols ospf area area-id interface

interface-name]

Enabling Ultimate-Hop Popping on Point-to-Multipoint LSPs

By default, for both point-to-point and point-to-multipoint LSPs, penultimate-hop

popping is used for MPLS traffic. MPLS labels are removed from packets on the router
just before the egress router of the LSP. The plain IP packets are then forwarded to the
egress router. For ultimate-hop popping, the egress router is responsible for both removing
the MPLS label and processing the plain IP packet.

420 Copyright © 2012, Juniper Networks, Inc.

 Chapter 12: RSVP Configuration Guidelines

It can be beneficial to enable ultimate-hop popping on point-to-multipoint LSPs,

particularly when transit traffic is traversing the same egress device. If you enable
ultimate-hop popping, a single copy of traffic can be sent over the incoming link, saving
significant bandwidth. By default, ultimate-hop popping is disabled.

You enable ultimate-hop popping for point-to-multipoint LSPs by configuring the

tunnel-services statement. When you enable ultimate-hop popping, the Junos OS selects
one of the available virtual loopback tunnel (VT) interfaces to loop back the packets to
the PFE for IP forwarding. By default, the VT interface selection process is performed
automatically. Bandwidth admission control is used to limit the number of LSPs that can
be used on one VT interface. Once all the bandwidth is consumed on one interface, the
Junos OS selects another VT interface with sufficient bandwidth for admission control.

If an LSP requires more bandwidth than is available from any of the VT interfaces,
ultimate-hop popping cannot be enabled and penultimate-hop popping is enabled
instead.

You can explicitly configure which VT interfaces handle the RSVP traffic by including the
devices option for the tunnel-services statement. The devices option allows you to specify
which VT interfaces are to be used by RSVP. If you do not configure this option, all of the
VT interfaces available to the router can be used.

For ultimate-hop popping on point-to-multipoint LSPs to function properly, the egress

router must have a PIC that provides tunnel services, such as the tunnel services PIC or
the adaptive services PIC. Tunnel services are needed for popping the final MPLS label
and for returning packets for IP address lookups.

If you configure the tunnel-services statement on an operating router, only the behavior
of newly signaled LSPs changes. Existing LSPs are not affected. To force all existing LSPs
to use ultimate-hop popping, issue a clear mpls lsp command. Note that this causes all
of the MPLS LSPs on the router to be signaled again.

To enable ultimate-hop popping for the egress point-to-multipoint LSPs on a router,

configure the tunnel-services statement:

tunnel-services {
devices device-names;
}

You can configure this statement at the [edit protocols rsvp] hierarchy level.

To enable ultimate-hop popping for egress point-to-multipoint LSPs, you must also
configure the interface statement with the all option:

interface all;

You must configure this statement at the [edit protocols rsvp] hierarchy level.

Tracing RSVP Protocol Traffic

To trace RSVP protocol traffic, include the traceoptions statement:

traceoptions {
file filename <files number> <size size> <world-readable | no-world-readable>;

Copyright © 2012, Juniper Networks, Inc. 421

Junos OS 12.1 MPLS Applications Configuration Guide

flag flag <flag-modifier> <disable>;

}

You can include this statement at the following hierarchy levels:

• [edit protocols rsvp]

• [edit logical-systems logical-system-name protocols rsvp]

You can specify the following RSVP-specific flags in the RSVP traceoptions statement:

Use the file statement to specify the name of the file that receives the output of the
tracing operation. All files are placed in the directory /var/log. We recommend that you
place RSVP tracing output in the file rsvp-log.

• all—All tracing operations.

• error—All detected error conditions

• event—RSVP-related events (helps to trace events related to RSVP graceful restart)

• lmp—RSVP-Link Management Protocol (LMP) interactions

• packets—All RSVP packets

• path—All path messages

• pathtear—PathTear messages

• resv—Resv messages

• resvtear—ResvTear messages

• route—Routing information

• state—Session state transitions

For general information about tracing and global tracing options, see the Junos OS Routing
Protocols Configuration Guide.

Examples: Tracing RSVP Protocol Traffic

Trace RSVP path messages in detail:

[edit]
protocols {
rsvp {
traceoptions {
file rsvp size 10m files 5;
flag path;
}
}
}

Trace all RSVP messages:

[edit]
protocols {
rsvp {
traceoptions {

422 Copyright © 2012, Juniper Networks, Inc.

 Chapter 12: RSVP Configuration Guidelines

file rsvp size 10m files 5;

flag packets;
}
}
}

Trace all RSVP error conditions:

[edit]
protocols {
rsvp {
traceoptions {
file rsvp size 10m files 5;
flag error;
}
}
}

Copyright © 2012, Juniper Networks, Inc. 423

Junos OS 12.1 MPLS Applications Configuration Guide

424 Copyright © 2012, Juniper Networks, Inc.

CHAPTER 13

Summary of RSVP Configuration

Statements

This chapter provides a reference for each RSVP configuration statement. The statements
are organized alphabetically.

admin-group

Syntax admin-group {
exclude [ group-names ];
include-all [ group-names ];
include-any [ group-names ];
}

Hierarchy Level [edit logical-systems logical-system-name protocols rsvp interface interface-name

link-protection],
[edit logical-systems logical-system-name protocols rsvp interface interface-name
link-protection bypass bypass-name],
[edit protocols rsvp interface interface-name link-protection],
[edit protocols rsvp interface interface-name link-protection bypass bypass-name]

Release Information Statement introduced in Junos OS Release 9.2.

Description Enable you to configure administrative groups for bypass label-switched paths (LSPs).
You can configure administrative groups either globally for all bypass LSPs traversing an
interface or for just a specific bypass LSP.

Options exclude group-names—Specify the administrative groups to exclude for a bypass LSP.

include-all group-names—Specify the administrative groups whose links the bypass LSP
must traverse.

include-any group-names—Specify the administrative groups whose links the bypass LSP
can traverse.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring Administrative Groups for Bypass LSPs on page 406

Documentation

Copyright © 2012, Juniper Networks, Inc. 425

Junos OS 12.1 MPLS Applications Configuration Guide

aggregate

Syntax (aggregate | no-aggregate);

Hierarchy Level [edit logical-systems logical-system-name protocols rsvp interface interface-name],

[edit logical-systems logical-system-name protocols rsvp peer-interface peer-interface-name],
[edit protocols rsvp interface interface-name],
[edit protocols rsvp peer-interface peer-interface-name]

Release Information Statement introduced before Junos OS Release 7.4.

Description Control the use of RSVP aggregate messages on an interface or peer interface:

• aggregate—Use RSVP aggregate messages.

• no-aggregate—Do not use RSVP aggregate messages.

Aggregate messages can pack multiple RSVP messages into a single transmission,
thereby reducing network overhead and enhancing efficiency. The number of
supportable sessions and processing overhead are significantly improved when
aggregation is enabled.

Not all routers connected to a subnet need to support aggregation simultaneously.

Each RSVP router negotiates its intention to use aggregate messages on a per-neighbor
basis. Only when both routers agree are aggregate messages sent.

Default Aggregation is disabled.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring RSVP Refresh Reduction on page 395

Documentation

426 Copyright © 2012, Juniper Networks, Inc.

 Chapter 13: Summary of RSVP Configuration Statements

authentication-key

Syntax authentication-key key;

Hierarchy Level [edit logical-systems logical-system-name protocols rsvp interface interface-name],

[edit logical-systems logical-system-name protocols rsvp peer-interface peer-interface-name],
[edit protocols rsvp interface interface-name],
[edit protocols rsvp peer-interface peer-interface-name]

Release Information Statement introduced before Junos OS Release 7.4.

Description Authentication key (password). Neighboring routers use the password to verify the
authenticity of packets sent from this interface or peer interface.

RSVP uses HMAC-MD5 authentication, which is defined in RFC 2104, HMAC:

Keyed-Hashing for Message Authentication.

All routers that are connected to the same IP subnet must use the same authentication
scheme and password.

Options key—Authentication password. It can be 1 through 16 contiguous digits or letters. Separate

decimal digits with periods. Separate hexadecimal digits with periods and precede
the string with 0x. If you include spaces in the password, enclose the entire password
in quotation marks (" ").

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring RSVP Authentication on page 398

Documentation

Copyright © 2012, Juniper Networks, Inc. 427

Junos OS 12.1 MPLS Applications Configuration Guide

bandwidth

Syntax bandwidth bps;

Hierarchy Level [edit logical-systems logical-system-name protocols rsvp interface interface-name],

[edit logical-systems logical-system-name protocols rsvp interface interface-name
link-protection],
[edit logical-systems logical-system-name protocols rsvp interface interface-name
link-protection bypass bypass-name],
[edit protocols rsvp interface interface-name],
[edit protocols rsvp interface interface-name link-protection],
[edit protocols rsvp interface interface-name link-protection bypass bypass-name]

Release Information Statement introduced before Junos OS Release 7.4.

Description For certain logical interfaces (such as Asynchronous Transfer Mode [ATM], Permanent
Virtual Circuit [PVC], or Frame Relay), you cannot determine the correct bandwidth from
the hardware. This statement enables you to specify the actual available bandwidth.

This statement also enables you to specify the bandwidth for a bypass label switched
path (LSP). If you have configured multiple bypasses, this statement is mandatory and
is applied to all of the bypass LSPs.

Default The hardware raw bandwidth is used.

Options bps—Bandwidth in bits per second. You can specify this as an integer value. If you do so,
count your zeros carefully, or you can use the abbreviations k (for a thousand), m
(for a million), or g (for a billion [also called a thousand million]).
Range: Any positive integer
Default: 0 (no bandwidth is reserved)

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring the Bandwidth for Bypass LSPs on page 407

Documentation
• Configuring Link Protection on Interfaces Used by LSPs on page 404

• Configuring Bypass LSPs on page 405

428 Copyright © 2012, Juniper Networks, Inc.

 Chapter 13: Summary of RSVP Configuration Statements

bypass (Signaled LSP)

Syntax bypass bypass-name {

bandwidth bps;
description text;
hop-limit number;
no-cspf;
path address <strict | loose>;
priority setup-priority reservation-priority;
to address;
}

Hierarchy Level [edit logical-systems logical-system-name protocols rsvp interface interface-name

link-protection],
[edit protocols rsvp interface interface-name link-protection]

Release Information Statement introduced before Junos OS Release 7.4.

The description option was added in Junos OS Release 10.4.

Description Enables you to configure specific bandwidth and path constraints for a bypass LSP. It is
possible to individually configure multiple bypass LSPs. If you do not configure the bypass
LSPs individually, they all share the same path and bandwidth constraints.

If you specify the bandwidth, hop-limit, and path statements for the bypass LSP, these
values take precedence over the values configured at the [edit protocols rsvp interface
interface-name link-protection] hierarchy level. The other attributes (subscription,
no-node-protection, and optimize-timer) are inherited from the general constraints.

Options bypass-name—(Required) Specify a name for the bypass LSP. The name can be up to
64 characters.

description—Provides a textual description of the bypass LSP. Enclose any descriptive

text that includes spaces in quotation marks (" "). Any descriptive text you include
is displayed in the output of the show mpls lsp bypass detail command and has no
effect on the operation of the bypass LSP. The description text can be no more than
80 characters in length.

to address—(Required) Specify the address for the interface of the immediate next-hop
node (for link protection) or the next-next-hop node (for node-link protection). The
address specified determines whether this is a link protection bypass or a node-link
protection bypass. On multiaccess networks (for example, a LAN), this address is
also used to specify which next-hop node is being protected.

The remaining statements are explained separately.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring Bypass LSPs on page 405

Documentation

Copyright © 2012, Juniper Networks, Inc. 429

Junos OS 12.1 MPLS Applications Configuration Guide

bypass (Static LSP)

Syntax bypass bypass-name {

bandwidth bps;
description string;
next-hop (address | interface-name | address/interface-name);
push out-label;
to address;
}

Hierarchy Level [edit logical-systems logical-system-name protocols mpls static-label-switched-path

lsp-name],
[edit protocols mpls static-label-switched-path lsp-name]

Release Information Statement introduced before Junos OS Release 10.1.

Description Configure specific bandwidth and path constraints for a bypass ingress LSP. It is possible
to configure multiple bypass LSPs individually. If you do not, they all share the same path
and bandwidth constraints.

The remaining statements are explained separately.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring Static LSPs on page 211

Documentation

430 Copyright © 2012, Juniper Networks, Inc.

 Chapter 13: Summary of RSVP Configuration Statements

class-of-service

Syntax class-of-service cos-value;

Hierarchy Level [edit logical-systems logical-system-name protocols rsvp interface interface-name

link-protection],
[edit logical-systems logical-system-name protocols rsvp interface interface-name
link-protection bypass bypass-name],
[edit protocols rsvp interface interface-name link-protection],
[edit protocols rsvp interface interface-name link-protection bypass bypass-name]

Release Information Statement introduced before Junos OS Release 7.4.

Description Class-of-service (CoS) value given to all packets in the bypass LSP. You can specify a
single CoS value for all the bypass LSPs traversing an interface. You can also configure
CoS values for specific bypass LSPs traversing an interface.

The CoS value might affect the scheduling or queuing algorithm of traffic traveling along
an LSP.

Options cos-value—CoS value. A higher value typically corresponds to a higher level of service.
Range: 0 through 7
Default: If you do not specify a CoS value, the IP precedence bits from the packet’s IP
header are used as the packet’s CoS value.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring Class of Service for Bypass LSPs on page 407

Documentation

Copyright © 2012, Juniper Networks, Inc. 431

Junos OS 12.1 MPLS Applications Configuration Guide

disable

Syntax disable;

Hierarchy Level [edit logical-systems logical-system-name protocols rsvp],

[edit logical-systems logical-system-name protocols rsvp graceful-restart],
[edit logical-systems logical-system-name protocols rsvp interface interface-name],
[edit logical-systems logical-system-name protocols rsvp interface interface-name
link-protection],
[edit logical-systems logical-system-name protocols rsvp peer-interface peer-interface-name],
[edit protocols rsvp],
[edit protocols rsvp graceful-restart],
[edit protocols rsvp interface interface-name],
[edit protocols rsvp interface interface-name link-protection],
[edit protocols rsvp peer-interface peer-interface-name]

Release Information Statement introduced before Junos OS Release 7.4.

Description Explicitly disable RSVP or RSVP graceful restart. Explicitly disable link protection on the
specified interface.

Default RSVP is enabled on interfaces and peer interfaces configured with the RSVP interface
statement. RSVP graceful restart is enabled on the router. Link protection is disabled.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Minimum RSVP Configuration on page 393

Documentation
• Configuring RSVP Graceful Restart on page 412

• Configuring Link Protection on Interfaces Used by LSPs on page 404

432 Copyright © 2012, Juniper Networks, Inc.

 Chapter 13: Summary of RSVP Configuration Statements

fast-reroute

Syntax fast-reroute optimize-timer seconds;

Hierarchy Level [edit logical-systems logical-system-name protocols rsvp],

[edit protocols rsvp]

Release Information Statement added in Junos OS Release 7.5.

Description Configure the optimize timer for fast reroute. The optimize timer triggers a periodic
optimization process that recomputes the fast reroute detour LSPs to use network
resources more efficiently.

Options seconds—Specify the number of seconds between fast reroute detour LSP optimizations.
Range: 0 through 65,535 seconds
Default: 0 (disabled)

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring the Optimization Interval for Fast Reroute Paths on page 154
Documentation

graceful-deletion-timeout

Syntax graceful-deletion-timeout seconds;

Hierarchy Level [edit logical-systems logical-system-name protocols rsvp],

[edit protocols rsvp]

Release Information Statement introduced before Junos OS Release 7.4.

Description Specify the time, in seconds, before completing graceful deletion of signaling.

Options seconds—Time before completing graceful deletion of signaling.

Range: 1 through 300 seconds
Default: 30 seconds

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring the Graceful Deletion Timeout Interval on page 599

Documentation

Copyright © 2012, Juniper Networks, Inc. 433

Junos OS 12.1 MPLS Applications Configuration Guide

graceful-restart

Syntax graceful-restart {
disable;
helper-disable;
maximum-helper-recovery-time seconds;
maximum-helper-restart-time seconds;
}

Hierarchy Level [edit logical-systems logical-system-name routing-options],

[edit protocols rsvp],
[edit routing-options]

Release Information Statement introduced before Junos OS Release 7.4.

Description Enable graceful restart on the router. You must configure the graceful-restart statement
at the [edit routing-options] hierarchy level to enable graceful restart on the router.

Options disable—Disable graceful restart on the router or for RSVP.

helper-disable—Disable RSVP graceful restart helper mode (this option is only available
at the [edit protocols rsvp] hierarchy level).
Default: Helper mode is enabled by default.

maximum-helper-recovery-time seconds—The maximum length of time the router stores

the state of neighboring routers when they undergo a graceful restart. The value
applies to all neighboring routers, so it should be based on the time that the slowest
RSVP neighbor requires for restart.
Default: 180 seconds
Range: 1 through 3600 seconds

maximum-helper-restart-time seconds—The maximum length of time the router waits

between when it discovers that a neighboring router has gone down and when it
declares the neighbor down. This value is applied to all neighboring routers, so it
should be based on the time that the slowest RSVP neighbor requires for restart.
Default: 20 seconds
Range: 1 through 1800 seconds

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring RSVP Graceful Restart on page 412

Documentation

434 Copyright © 2012, Juniper Networks, Inc.

 Chapter 13: Summary of RSVP Configuration Statements

hello-acknowledgements

Syntax hello-acknowledgements;

Hierarchy Level [edit logical-systems logical-systems-name protocols rsvp],

[edit protocols rsvp]

Release Information Statement introduced in Junos OS Release 10.2.

Description Enable hello messages from nonsession neighbors to be acknowledged with a hello
acknowledgment message. Once hello acknowledgments are enabled, the router
continues to acknowledge hello messages from any nonsession RSVP neighbors unless
the interface itself goes down or the configuration is changed by an administrator.

Default Hello acknowledgments are disabled.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring Hello Acknowledgments for Nonsession RSVP Neighbors on page 401
Documentation

hello-interval

Syntax hello-interval seconds;

Hierarchy Level [edit logical-systems logical-system-name protocols rsvp interface interface-name],

[edit logical-systems logical-system-name protocols rsvp peer-interface peer-interface-name],
[edit protocols rsvp interface interface-name],
[edit protocols rsvp peer-interface peer-interface-name]

Release Information Statement introduced before Junos OS Release 7.4.

Description Enable the sending of hello packets on the interface.

Options seconds—Length of time between hello packets. A value of 0 disables the sending of
hello packets on the interface.
Range: 1 through 60 seconds
Default: 9 seconds

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring the RSVP Hello Interval on page 398

Documentation

Copyright © 2012, Juniper Networks, Inc. 435

Junos OS 12.1 MPLS Applications Configuration Guide

hop-limit

Syntax hop-limit number;

Hierarchy Level [edit logical-systems logical-system-name protocols rsvp interface interface-name

link-protection],
[edit logical-systems logical-system-name protocols rsvp interface interface-name
link-protection bypass bypass-name],
[edit protocols rsvp interface interface-name link-protection],
[edit protocols rsvp interface interface-name link-protection bypass bypass-name]

Release Information Statement introduced before Junos OS Release 7.4.

Description Specify the maximum number of hops a bypass can traverse. By default, each bypass
can traverse a maximum of 255 hops, including the ingress and egress routers.

Options number—Maximum number of hops a bypass can traverse.

Range: 2 through 255 hops
Default: 255 hops

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring the Hop Limit for Bypass LSPs on page 408
Documentation

436 Copyright © 2012, Juniper Networks, Inc.

 Chapter 13: Summary of RSVP Configuration Statements

interface

Syntax interface interface-name {

disable;
(aggregate | no-aggregate);
authentication-key key;
bandwidth bps;
hello-interval seconds;
link-protection {
disable;
admin-group {
exclude [ group-names ];
include-all [ group-names ];
include-any [ group-names ];
}
bandwidth bps;
bypass bypass-name {
bandwidth bps {
ct0 bps;
ct1 bps;
ct2 bps;
ct3 bps;
}
description text;
class-of-service cos-value;
hop-limit number;
no-cspf;
path address <strict | loose>;
priority setup-priority reservation-priority;
to address;
}
class-of-service cos-value;
hop-limit number;
max-bypasses number;
no-cspf;
no-node-protection;
optimize-timer seconds;
path address <strict | loose>;
priority setup-priority reservation-priority;
subscription percentage;
}
(reliable | no-reliable);
subscription percentage {
ct0 percentage;
ct1 percentage;
ct2 percentage;
ct3 percentage;
}
update-threshold threshold;
}

Hierarchy Level [edit logical-systems logical-system-name protocols rsvp],

[edit protocols rsvp]

Copyright © 2012, Juniper Networks, Inc. 437

Junos OS 12.1 MPLS Applications Configuration Guide

Release Information Statement introduced before Junos OS Release 7.4.

Description Enable RSVP on one or more router interfaces.

Default RSVP is disabled on all interfaces.

Options interface-name—Name of an interface. To configure all interfaces, specify all. For details
about specifying interfaces, see the Junos OS Network Interfaces Configuration Guide.

The remaining statements are explained separately.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Minimum RSVP Configuration on page 393

Documentation

keep-multiplier

Syntax keep-multiplier number;

Hierarchy Level [edit logical-systems logical-system-name protocols rsvp],

[edit protocols rsvp]

Release Information Statement introduced before Junos OS Release 7.4.

Description Set the keep multiplier value.

Options number—Multiplier value.

Range: 1 through 255
Default: 3

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring Timers for RSVP Refresh Messages on page 416

Documentation

438 Copyright © 2012, Juniper Networks, Inc.

 Chapter 13: Summary of RSVP Configuration Statements

link-protection (RSVP)

Syntax link-protection {
disable;
admin-group {
exclude [ group-names ];
include-all [ group-names ];
include-any [ group-names ];
}
bandwidth bps;
bypass bypass-name {
bandwidth bps {
ct0 bps;
ct1 bps;
ct2 bps;
ct3 bps;
}
description text;
class-of-service cos-value;
hop-limit number;
no-cspf;
path address <strict | loose>;
priority setup-priority reservation-priority;
to address;
}
class-of-service cos-value;
hop-limit number;
max-bypasses number;
no-cspf;
no-node-protection;
optimize-timer seconds;
path address <strict | loose>;
priority setup-priority reservation-priority;
subscription percentage;
}

Hierarchy Level [edit logical-systems logical-system-name protocols rsvp interface interface-name],

[edit protocols rsvp interface interface-name]

Release Information Statement introduced before Junos OS Release 7.4.

Description Enable link protection on the specified interface. Using link protection, you can configure
a network to reroute traffic quickly around broken links. To fully enable link protection,
you also need to configure the link-protection statement at the [edit protocols mpls
label-switched-path lsp-name] hierarchy level. You can configure single or multiple
bypasses for protected interface.

Default Link protection is disabled.

Options no-node-protection—Disable node-link protection on the RSVP interface. Link protection

remains active. When this option is configured, the router can only initiate a next-hop
bypass, not a next-next-hop bypass.

Copyright © 2012, Juniper Networks, Inc. 439

Junos OS 12.1 MPLS Applications Configuration Guide

The remaining statements are explained separately.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring Link Protection on Interfaces Used by LSPs on page 404

Documentation
• link-protection (Dynamic LSPs) on page 320

load-balance

Syntax load-balance {
bandwidth;
}

Hierarchy Level [edit logical-systems logical-system-name protocols rsvp],

[edit protocols rsvp]

Release Information Statement introduced before Junos OS Release 7.4.

Description Load-balance traffic between RSVP LSPs.

Options bandwidth—Load-balance traffic between RSVP LSPs based on the bandwidth configured
for each LSP.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring Load Balancing Across RSVP LSPs on page 414

Documentation

440 Copyright © 2012, Juniper Networks, Inc.

 Chapter 13: Summary of RSVP Configuration Statements

max-bypasses

Syntax max-bypasses number;

Hierarchy Level [edit logical-systems logical-system-name protocols rsvp interface interface-name],

[edit protocols rsvp interface interface-name]

Release Information Statement introduced before Junos OS Release 7.4.

Range modified in Junos OS Release 9.3.

Description Specify the maximum number of dynamic bypass LSPs permitted for protecting this
interface. When this option is configured, multiple bypasses for link protection are enabled.
Call admission control (CAC) is also enabled. The limit on bypasses configured applies
only to dynamically generated bypass LSPs. By default, this option is disabled and only
one dynamic bypass LSP is enabled for each interface. If you configure max-bypasses,
you must also configure the bandwidth statement.

Options number—Configure the maximum number of bypass LSPs. If you configure a value of 0,
no dynamic bypass LSPs are allowed to be established for the interface. Only static
bypass LSPs can be configured.
Range: 0 through 99
Default: 1

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring the Maximum Number of Bypass LSPs on page 408

Documentation

Copyright © 2012, Juniper Networks, Inc. 441

Junos OS 12.1 MPLS Applications Configuration Guide

no-local-reversion

Syntax no-local-reversion;

Hierarchy Level [edit logical-systems logical-system-name protocols rsvp],

[edit protocols rsvp]

Release Information Statement introduced in Junos OS Release 10.4.

Description Disables RSVP local revertive mode as specified in RFC 4090, Fast Reroute Extensions
to RSVP-TE for LSP Tunnels. RSVP local revertive mode is supported on all Juniper
Networks routers running the Junos OS. It is the default behavior. If you include this
statement, the Juniper Networks router uses global revertive mode instead. You might
need to disable RSVP local revertive mode on Juniper Networks routers if your network
includes equipment that does not support this mode.

The following information can also be found in RFC 4090. Refer to the full RFC for
additional information. When an LSP fails, the connection can be repaired locally using
a traffic protection mechanism such as fast reroute. To restore the LSP to a full working
path, RFC 4090 specifies the following strategies:

• Local revertive mode—Upon detecting that the path is restored, the point of local repair
(PLR) resignals each of the LSPs that were formerly routed over the restored path.
Every LSP successfully resignaled along the restored path is switched back.

• Global revertive mode—The ingress router of each tunnel is responsible for reoptimizing
the LSPs that used the failed path. There are several potential reoptimization triggers:
RSVP error messages, inspection of OSPF LSAs or IS-IS LSPs, and timers. This
re-optimization process can proceed as soon as the failure is detected. It is not tied to
the restoration of the failed path.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

442 Copyright © 2012, Juniper Networks, Inc.

 Chapter 13: Summary of RSVP Configuration Statements

node-hello

Syntax node-hello;

Hierarchy Level [edit logical-systems logical-system-name protocols rsvp],

[edit protocols rsvp]

Release Information Statement introduced in JUNOS Release 10.0.

Description Enables node-ID based RSVP hellos globally on all of the RSVP interfaces on the router
to allow Juniper Networks routers to interoperate with the equipment of other vendors.
By default, the JUNOS Software uses interface-based RSVP hellos and node-ID based
RSVP hellos are disabled. If you have not enabled RSVP node IDs on the router, the
JUNOS software does not accept any node-ID hello packets.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring RSVP Node ID Hellos on page 401

Documentation

no-adjacency-down-notification

Syntax no-adjacency-down-notification;

Hierarchy Level [edit logical-systems logical-system-name protocols isis interface interface-name],

[edit protocols isis interface interface-name]

Release Information Statement introduced in Junos OS Release 8.0.

Description Disable adjacency down notification for IS-IS to allow for migration from IS-IS to OSPF
without disruption of the RSVP neighbors and associated RSVP-signaled LSPs.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Disabling Adjacency Down and Neighbor Down Notification in IS-IS and OSPF on
Documentation page 420

no-aggregate

See aggregate.

Copyright © 2012, Juniper Networks, Inc. 443

Junos OS 12.1 MPLS Applications Configuration Guide

no-cspf

Syntax no-cspf;

Hierarchy Level [edit logical-systems logical-system-name protocols rsvp interface interface-name

link-protection],
[edit logical-systems logical-system-name protocols rsvp interface interface-name
link-protection bypass bypass-name],
[edit protocols rsvp interface interface-name link-protection],
[edit protocols rsvp interface interface-name link-protection bypass bypass-name]

Release Information Statement introduced in Junos OS Release 7.5.

Description Disable CSPF computation on all bypass LSPs or on a specific bypass LSP. You need to
disable CSPF for link protection to function properly on interarea paths.

Default CSPF is enabled.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Disabling CSPF for Bypass LSPs on page 409

Documentation

no-interface-hello

Syntax no-interface-hello;

Hierarchy Level [edit logical-systems logical-system-name protocols rsvp],

[edit protocols rsvp]

Release Information Statement introduced in JUNOS Release 10.0.

Description Allows you to explicitly disable RSVP interface hellos globally on the router. This type of
configuration might be necessary in networks where the Juniper Networks router has
numerous RSVP connections with equipment from other vendors. However, if you disable
RSVP interface hellos globally, you can also configure a hello interval on an RSVP interface
using the hello-interval statement. This configuration disables RSVP interface hellos
globally but enables RSVP interface hellos on the specified interface. This configuration
might be necessary in a heterogeneous network where some devices support RSVP node
ID hellos and other devices support RSVP interface hellos.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring RSVP Node ID Hellos on page 401

Documentation
• hello-interval on page 435

444 Copyright © 2012, Juniper Networks, Inc.

 Chapter 13: Summary of RSVP Configuration Statements

no-neighbor-down-notification

Syntax no-neighbor-down-notification;

Hierarchy Level [edit logical-systems logical-system-name protocols ospf area area-id interface
interface-name],
[edit protocols ospf area area-id interface interface-name]

Release Information Statement introduced in Junos OS Release 8.0.

Description Disable neighbor down notification for OSPF to allow for migration from OSPF to IS-IS
without disruption of the RSVP neighbors and associated RSVP-signaled LSPs.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Disabling Adjacency Down and Neighbor Down Notification in IS-IS and OSPF on
Documentation page 420

no-node-id-subobject

Syntax no-node-id-subobject;

Hierarchy Level [edit logical-systems logical-system-name protocols rsvp],

[edit protocols rsvp]

Release Information Statement introduced in Junos OS Release 9.4.

Description Disable the record route object (RRO) node ID subobject for compatibility with earlier
versions of the Junos OS. To interoperate with other vendors’ equipment, the Junos OS
supports the RRO node ID subobject for use in inter-AS link and node protection
configurations.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring Inter-AS Node and Link Protection on page 404

Documentation

Copyright © 2012, Juniper Networks, Inc. 445

Junos OS 12.1 MPLS Applications Configuration Guide

no-p2mp-sublsp

Syntax no-p2mp-sublsp;

Hierarchy Level [edit logical-systems logical-system-name protocols rsvp],

[edit protocols rsvp]

Release Information Statement introduced in Junos OS Release 9.2.

Description Reject Resv messages that include the S2L_SUB_LSP object. By default, Resv messages
that include the S2L_SUB_LSP object are accepted. However, in a network which includes
Juniper Networks devices running both Junos OS Release 9.2 and later and Junos OS
Release 9.1 and earlier, it is necessary to configure the no-p2mp-sublsp statement on
devices running Junos OS Release 9.2 and later to ensure that point-to-multipoint LSPs
function properly.

Default Resv messages that include the S2L_SUB_LSP object are accepted.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Preserving Point-to-Multipoint LSP Functioning with Different Junos OS Releases on

Documentation page 227

no-reliable

See reliable

node-link-protection

Syntax node-link-protection;

Hierarchy Level [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name],

[edit protocols mpls label-switched-path lsp-name]

Release Information Statement introduced before Junos OS Release 7.4.

Description Enable node and link protection on the specified LSP. To fully enable node and link
protection, you also need to include the link-protection statement at the [edit protocols
rsvp interface interface-name] hierarchy level.

Default Node and link protection is disabled.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring Node Protection or Link Protection for LSPs on page 402
Documentation

446 Copyright © 2012, Juniper Networks, Inc.

 Chapter 13: Summary of RSVP Configuration Statements

optimize-timer

Syntax optimize-timer seconds;

Hierarchy Level [edit logical-systems logical-system-name protocols rsvp interface interface-name

link-protection],
[edit protocols rsvp interface interface-name link-protection]

Release Information Statement introduced before Junos OS Release 7.4.

Description Configure an optimize timer for a bypass LSP. The optimize timer initiates a periodic
optimization process that reshuffles data LSPs among bypass LSPs to achieve the most
efficient use of network resources. The optimization process attempts to either minimize
the number of bypasses currently in use, minimize the total amount of bandwidth reserved
for all bypasses, or both.

Options seconds—Specify the number of seconds between optimizations.

Range: 0 through 65,535 seconds
Default: 0 (disabled)

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring the Optimization Interval for Bypass LSPs on page 409
Documentation

Copyright © 2012, Juniper Networks, Inc. 447

Junos OS 12.1 MPLS Applications Configuration Guide

path

Syntax path address <strict | loose>;

Hierarchy Level [edit logical-systems logical-system-name protocols rsvp interface interface-name

link-protection],
[edit logical-systems logical-system-name protocols rsvp interface interface-name
link-protection bypass bypass-name],
[edit protocols rsvp interface interface-name link-protection],
[edit protocols rsvp interface interface-name link-protection bypass bypass-name]

Release Information Statement introduced before Junos OS Release 7.4.

Description Configure an explicit path (a sequence of strict or loose routes) to control where and
how a bypass LSP is established. If multiple bypasses are configured, they all will use
the same explicit path.

Default No path is configured. CSPF automatically calculates the path the bypass LSP takes.

Options address—IP address of each transit router in the LSP. You must specify the address or
hostname of each transit router, although you do not need to list each transit router
if its type is loose. As an option, you can include the ingress and egress routers in the
path. Specify the addresses in order, starting with the ingress router (optional) or
the first transit router, and continuing sequentially along the path until reaching the
egress router (optional) or the router immediately before the egress router.
Default: If you do not specify any routers explicitly, no routing limitations are imposed
on the bypass LSP.

loose—(Optional) The next address in the path statement is loose. The LSP can traverse
other routers before reaching this router.
Default: strict

strict—(Optional) The LSP must go to the next address specified in the path statement
without traversing other nodes. This is the default.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring an Explicit Path for Bypass LSPs on page 410

Documentation

448 Copyright © 2012, Juniper Networks, Inc.

 Chapter 13: Summary of RSVP Configuration Statements

peer-interface

Syntax peer-interface peer-interface-name {

disable;
(aggregate | no-aggregate);
authentication-key key;
hello-interval seconds;
(reliable | no-reliable);
}

Hierarchy Level [edit logical-systems logical-system-name protocols rsvp],

[edit protocols rsvp]

Release Information Statement introduced before Junos OS Release 7.4.

Description Configure the name of the LMP peer device.

The remaining statements are explained separately.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring RSVP and OSPF for LMP Peer Interfaces on page 593
Documentation

Copyright © 2012, Juniper Networks, Inc. 449

Junos OS 12.1 MPLS Applications Configuration Guide

preemption

Syntax preemption {
(aggressive | disabled | normal);
soft-preemption {
cleanup-timer seconds;
}
}

Hierarchy Level [edit logical-systems logical-system-name protocols rsvp],

[edit protocols rsvp]

Release Information Statement introduced before Junos OS Release 7.4.

Description Control RSVP session preemption.

Default normal

Options aggressive—Preempt RSVP sessions whenever bandwidth is insufficient to handle all

sessions. A session is preempted whenever bandwidth is lowered or a new
higher-priority session is established.

disabled—Do not preempt RSVP sessions.

normal—Preempt RSVP sessions to accommodate new higher-priority sessions when

bandwidth is insufficient to handle all sessions.

The remaining statements are explained separately.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Preempting RSVP Sessions on page 417

Documentation

450 Copyright © 2012, Juniper Networks, Inc.

 Chapter 13: Summary of RSVP Configuration Statements

priority

Syntax priority setup-priority reservation-priority;

Hierarchy Level [edit logical-systems logical-system-name protocols rsvp interface interface-name

link-protection],
[edit logical-systems logical-system-name protocols rsvp interface interface-name
link-protection bypass bypass-name],
[edit protocols rsvp interface interface-name link-protection],
[edit protocols rsvp interface interface-name link-protection bypass bypass-name],

Release Information Statement introduced before Junos OS Release 7.4.

Description Configure the setup priority and reservation priority for a bypass LSP. If insufficient link
bandwidth is available during session establishment, the setup priority is compared with
other setup priorities for established sessions on the link to determine whether some of
them should be preempted to accommodate the new session. The session with the
lower-hold priority is preempted.

Options reservation-priority—Reservation priority, used to keep a reservation after it has been set
up. A smaller number has a higher priority. The priority must be greater than or equal
to the setup priority to prevent preemption loops.
Range: 0 through 7, where 0 is the highest and 7 is the lowest priority.
Default: 0 (Once the session is set up, no other session can preempt it.)

setup-priority—Setup priority.
Range: 0 through 7, where 0 is the highest and 7 is the lowest priority.
Default: 7 (The session cannot preempt any existing sessions.)

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring Priority and Preemption for Bypass LSPs on page 411
Documentation
• Configuring Priority and Preemption for LSPs on page 179

Copyright © 2012, Juniper Networks, Inc. 451

Junos OS 12.1 MPLS Applications Configuration Guide

refresh-time

Syntax refresh-time seconds;

Hierarchy Level [edit logical-systems logical-system-name protocols rsvp],

[edit protocols rsvp]

Release Information Statement introduced before Junos OS Release 7.4.

Description Set the refresh time.

Options seconds—Refresh time.

Range: 1 through 65,535
Default: 30 seconds

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring Timers for RSVP Refresh Messages on page 416

Documentation

reliable

Syntax (reliable | no-reliable);

Hierarchy Level [edit logical-systems logical-system-name protocols rsvp interface interface-name],

[edit logical-systems logical-system-name protocols rsvp peer-interface peer-interface-name],
[edit protocols rsvp interface interface-name],
[edit protocols rsvp peer-interface peer-interface-name]

Release Information Statement introduced before Junos OS Release 7.4.

Description Enable reliable message delivery on the interface.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring RSVP Refresh Reduction on page 395

Documentation

452 Copyright © 2012, Juniper Networks, Inc.

 Chapter 13: Summary of RSVP Configuration Statements

rsvp

Syntax rsvp { ... }

Hierarchy Level [edit logical-systems logical-system-name protocols],

[edit protocols]

Release Information Statement introduced before Junos OS Release 7.4.

Description Enable RSVP routing on the router.

You must include the rsvp statement in the configuration to enable RSVP on the router.

Default RSVP is disabled on the router.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Minimum RSVP Configuration on page 393

Documentation

Copyright © 2012, Juniper Networks, Inc. 453

Junos OS 12.1 MPLS Applications Configuration Guide

rsvp-te

Syntax rsvp-te entry-name {

destination-networks network-prefix;
label-switched-path-template {
default-template;
template-name;
}
}

Hierarchy Level [edit logical-systems logical-system-name routing-options dynamic-tunnels tunnel-name],

[edit routing-options dynamic-tunnels tunnel-name]

Release Information Statement introduced in Junos OS Release 10.1.

Description Enable RSVP to automatically establish LSPs for any new PE router added to a full mesh
of LSPs. To enable this feature, you must configure the rsvp-te statement on all of the
PE routers in the full mesh.

Options destination-networks network-prefix—Specify the IP version 4 (IPv4) prefix range for the
destination network. Dynamic tunnels within the specified IPv4 prefix range are
allowed to be initiated.

entry-name—Specify the entry for the RSVP tunnel.

label-switched-path-template—Configure the default template using the default-template

option, or configure your own template using the template-name option.

Usage Guidelines See “Configuring RSVP Automatic Mesh” on page 415.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

454 Copyright © 2012, Juniper Networks, Inc.

 Chapter 13: Summary of RSVP Configuration Statements

setup-protection

Syntax setup-protection;

Hierarchy Level [edit logical-systems logical-system-name protocols rsvp],

[edit protocols rsvp]

Description The facility-backup fast reroute mechanism can provide setup protection for LSPs which
are in the process of being signaled. Both point-to-point LSPs and point-to-multipoint
LSPs are supported. You should configure the setup-protection statement on each of
the routers along the LSP path on which you want to enable LSP setup protection. You
should also configure IGP traffic engineering on all of the routers on the LSP path.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring RSVP Setup Protection on page 412

Documentation

soft-preemption

Syntax soft-preemption {
cleanup-timer seconds;
}

Hierarchy Level [edit logical-systems logical-system-name protocols rsvp preemption],

[edit protocols rsvp preemption]

Release Information Statement introduced before Junos OS Release 7.4.

Description Enable soft preemption to attempt to establish a new path for a preempted LSP before
tearing it down.

Options cleanup-timer—A value of 0 disables soft preemption.

Range: 0 through 180 seconds
Default: 30 seconds

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring MPLS Soft Preemption on page 162

Documentation

Copyright © 2012, Juniper Networks, Inc. 455

Junos OS 12.1 MPLS Applications Configuration Guide

subscription

Syntax subscription percentage {

ct0 percentage;
ct1 percentage;
ct2 percentage;
ct3 percentage;
}

Hierarchy Level [edit logical-systems logical-system-name protocols rsvp interface interface-name],

[edit logical-systems logical-system-name protocols rsvp interface interface-name
link-protection],
[edit protocols rsvp interface interface-name],
[edit protocols rsvp interface interface-name link-protection]

Release Information Statement introduced before Junos OS Release 7.4.

Description Configure the amount of bandwidth subscribed to a class type (when you have enabled
Differentiated Services) or bypass LSP (when you have enabled link protection).
subscription is the percentage of the link bandwidth that can be used for the RSVP
reservation process.

Options ctnumber percentage—Percentage of the class-type bandwidth allowed for reservations.

If you specify a value greater than 100, you are oversubscribing the class type. You
can specify bandwidth subscriptions for class types 0 through 3. This option is not
available for bypass LSPs.
Range: 0 through 65,000
Default: 100 percent

percentage—Percentage of the class-type or bypass LSP bandwidth allowed for

reservations. If you specify a value greater than 100, you are oversubscribing the
class type or bypass LSP.
Range: 0 through 65,000
Default: 100 percent

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring the Bandwidth Subscription Percentage for LSPs on page 201
Documentation
• Configuring the Amount of Bandwidth Subscribed for Bypass LSPs on page 411

456 Copyright © 2012, Juniper Networks, Inc.

 Chapter 13: Summary of RSVP Configuration Statements

traceoptions

Syntax traceoptions {
file filename <files number> <size size> <world-readable | no-world-readable>;
flag flag <flag-modifier> <disable>;
}

Hierarchy Level [edit logical-systems logical-system-name protocols rsvp],

[edit protocols rsvp]

Release Information Statement introduced before Junos OS Release 7.4.

Description Enable RSVP-level trace options.

Default The default RSVP-level trace options are those inherited from the routing protocols
traceoptions statement included at the [edit routing-options] hierarchy level.

Options disable—(Optional) Disable the tracing operation. You can use this option to disable a
single operation when you have defined a broad group of tracing operations, such
as all.

filename—Name of the file to receive the output of the tracing operation. Enclose the
name within quotation marks. All files are placed in the directory /var/log. We
recommend that you place RSVP tracing output in the file rsvp-log.

files number—(Optional) Maximum number of trace files. When a trace file named
trace-file reaches its maximum size, it is renamed trace-file.0, then trace-file.1, and
so on, until the maximum number of trace files is reached. Then the oldest trace file
is overwritten.
Range: 2 through 1000
Default: 2 files

If you specify a maximum number of files, you must also include the size statement to
specify the maximum file size.

flag—Tracing operation to perform. To specify more than one tracing operation, include
multiple flag statements.

• all—All tracing operations

• error—All detected error conditions

• event—RSVP-related events

• lmp—RSVP-LMP interactions

• packets—All RSVP packets

• path—All path messages

• pathtear—PathTear messages

• resv—Resv messages

Copyright © 2012, Juniper Networks, Inc. 457

Junos OS 12.1 MPLS Applications Configuration Guide

• resvtear—ResvTear messages

• route—Routing information

• state—Session state transitions

flag-modifier—(Optional) Modifier for the tracing flag. You can specify one or more of
these modifiers:

• detail—Provide detailed trace information

• receive—Packets being received

• send—Packets being transmitted

no-world-readable—(Optional) Enable only certain users to read the log file.

size size—(Optional) Maximum size of each trace file, in kilobytes (KB), megabytes (MB),
or gigabytes (GB). When a trace file named trace-file reaches this size, it is renamed
trace-file.0. When the trace-file again reaches this size, trace-file.0 is renamed
trace-file.1 and trace-file is renamed trace-file.0. This renaming scheme continues
until the maximum number of trace files is reached. Then the oldest trace file is
overwritten.
Syntax: xk to specify KB, xm to specify MB, or xg to specify GB
Range: 10 KB through the maximum file size supported on your system
Default: 1 MB

If you specify a maximum file size, you must also include the files statement to specify
the maximum number of files.

world-readable—(Optional) Enable any user to read the log file.

Required Privilege routing and trace—To view this statement in the configuration.
Level routing-control and trace-control—To add this statement to the configuration.

Related • Tracing RSVP Protocol Traffic on page 421

Documentation

458 Copyright © 2012, Juniper Networks, Inc.

 Chapter 13: Summary of RSVP Configuration Statements

transit

Syntax transit incoming-label {

bandwidth bps;
description string;
link-protection bypass-name name;
next-hop (address | interface-name | address/interface-name);
node-protection bypass-name name next-next-label label;
pop;
swap out-label;
}

Hierarchy Level [edit logical-systems logical-system-name protocols mpls static-label-switched-path

lsp-name],
[edit protocols mpls static-label-switched-path lsp-name]

Release Information Statement introduced in Junos OS Release 10.1.

Description Configure a transit static LSP.

The remaining statements are explained separately.

Options incoming-label—Incoming label value.

Range: 1000000 through 1048575

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring Static LSPs on page 211

Documentation

Copyright © 2012, Juniper Networks, Inc. 459

Junos OS 12.1 MPLS Applications Configuration Guide

tunnel-services

Syntax tunnel-services {
devices device-names;
}

Hierarchy Level [edit protocols rsvp]

Release Information Statement introduced in Junos OS Release 8.1.

Description Enable ultimate-hop popping on point-to-multipoint LSPs. The Junos OS selects one of
the available virtual tunnel (VT) interfaces to de-encapsulate the egress traffic. By default,
the selection process is performed automatically.

Default Ultimate-hop popping is disabled.

Options devices device-names—Specify which VT interfaces are used to handle the RSVP traffic.
Range: 0 to 8 devices

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Enabling Ultimate-Hop Popping on Point-to-Multipoint LSPs on page 420

Documentation

update-threshold

Syntax update-threshold threshold;

Hierarchy Level [edit logical-systems logical-system-name protocols rsvp interface interface-name],

[edit protocols rsvp interface interface-name]

Release Information Statement introduced before Junos OS Release 7.4.

Description Adjust the threshold at which a change in bandwidth triggers an interior gateway protocol
(IGP) update.

Options threshold—Specify the percentage change in bandwidth to trigger an IGP update.

Range: 1 through 20 percent
Default: 10 percent

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring the RSVP Update Threshold on an Interface on page 399

Documentation

460 Copyright © 2012, Juniper Networks, Inc.

PART 4

LDP
• LDP Overview on page 463
• LDP Configuration Guidelines on page 471
• Summary of LDP Configuration Statements on page 503

Copyright © 2012, Juniper Networks, Inc. 461

Junos OS 12.1 MPLS Applications Configuration Guide

462 Copyright © 2012, Juniper Networks, Inc.

CHAPTER 14

LDP Overview

This chapter discusses the following topics:

• LDP Introduction on page 463

• Supported LDP Standards on page 464
• Junos OS LDP Protocol Implementation on page 464
• LDP Operation on page 465
• Tunneling LDP LSPs in RSVP LSPs on page 465
• Tunneling LDP LSPs in RSVP LSPs Overview on page 465
• Label Operations on page 466
• LDP Message Types on page 467
• Discovery Messages on page 467
• Session Messages on page 468
• Advertisement Messages on page 468
• Notification Messages on page 468
• LDP Session Protection on page 468
• LDP Graceful Restart on page 469

LDP Introduction

The Label Distribution Protocol (LDP) is a protocol for distributing labels in

non-traffic-engineered applications. LDP allows routers to establish label-switched
paths (LSPs) through a network by mapping network-layer routing information directly
to data link layer-switched paths.

These LSPs might have an endpoint at a directly attached neighbor (comparable to IP

hop-by-hop forwarding), or at a network egress node, enabling switching through all
intermediary nodes. LSPs established by LDP can also traverse traffic-engineered LSPs
created by RSVP.

LDP associates a forwarding equivalence class (FEC) with each LSP it creates. The FEC
associated with an LSP specifies which packets are mapped to that LSP. LSPs are
extended through a network as each router chooses the label advertised by the next hop

Copyright © 2012, Juniper Networks, Inc. 463

Junos OS 12.1 MPLS Applications Configuration Guide

for the FEC and splices it to the label it advertises to all other routers. This process forms
a tree of LSPs that converge on the egress router.

Supported LDP Standards

The Junos OS substantially supports the following RFCs, which define standards for LDP.

• RFC 3212, Constraint-Based LSP Setup using LDP

• RFC 3478, Graceful Restart Mechanism for Label Distribution Protocol

The following RFCs do not define standards, but provide information about LDP. The
IETF classifies them as “Informational.”

• RFC 3215, LDP State Machine

• RFC 5036, LDP Specification

For the following features described in the indicated sections of the RFC, the Junos OS
supports one of the possible modes but not the other:

• Label distribution control (section 2.6.1): Ordered mode is supported, but not
Independent mode.

• Label retention (section 2.6.2): Liberal mode is supported, but not Conservative
mode.

• Label advertisement (section 2.6.3): Downstream Unsolicited mode is supported,

but not Downstream on Demand mode.

• RFC 5443, LDP IGP Synchronization

Related • Supported GMPLS Standards on page 579

Documentation
• Supported MPLS Standards on page 24

• Supported RSVP Standards on page 376

• Accessing Standards Documents on the Internet

Junos OS LDP Protocol Implementation

The Junos OS implementation of LDP supports LDP version 1. The Junos OS supports a
simple mechanism for tunneling between routers in an interior gateway protocol (IGP),
to eliminate the required distribution of external routes within the core. The Junos OS
allows an MPLS tunnel next hop to all egress routers in the network, with only an IGP
running in the core to distribute routes to egress routers. Edge routers run BGP but do not
distribute external routes to the core. Instead, the recursive route lookup at the edge
resolves to an LSP switched to the egress router. No external routes are necessary on
the transit LDP routers.

464 Copyright © 2012, Juniper Networks, Inc.

 Chapter 14: LDP Overview

LDP Operation

You must configure LDP for each interface on which you want LDP to run. LDP creates
LSP trees rooted at each egress router for the router ID address that is the subsequent
BGP next hop. The ingress point is at every router running LDP. This process provides an
inet.3 route to every egress router. If BGP is running, it will attempt to resolve next hops
by using the inet.3 table first, which binds most, if not all, of the BGP routes to MPLS
tunnel next hops.

Two adjacent routers running LDP become neighbors. If the two routers are connected
by more than one interface, they become neighbors on each interface. When LDP routers
become neighbors, they establish an LDP session to exchange label information. If
per-router labels are in use on both routers, only one LDP session is established between
them, even if they are neighbors on multiple interfaces. For this reason, an LDP session
is not related to a particular interface.

LDP operates in conjunction with a unicast routing protocol. LDP installs LSPs only when
both LDP and the routing protocol are enabled. For this reason, you must enable both
LDP and the routing protocol on the same set of interfaces. If this is not done, LSPs might
not be established between each egress router and all ingress routers, which might result
in loss of BGP-routed traffic.

You can apply policy filters to labels received from and distributed to other routers through
LDP. Policy filters provide you with a mechanism to control the establishment of LSPs.

For LDP to run on an interface, MPLS must be enabled on a logical interface on that
interface. For more information, see the Junos OS Network Interfaces Configuration Guide.

Tunneling LDP LSPs in RSVP LSPs

You can tunnel LDP LSPs over RSVP LSPs. The following sections describe how tunneling
of LDP LSPs in RSVP LSPs works:

• Tunneling LDP LSPs in RSVP LSPs Overview on page 465

• Label Operations on page 466

Tunneling LDP LSPs in RSVP LSPs Overview

If you are using RSVP for traffic engineering, you can run LDP simultaneously to eliminate
the distribution of external routes in the core. The LSPs established by LDP are tunneled
through the LSPs established by RSVP. LDP effectively treats the traffic-engineered LSPs
as single hops.

When you configure the router to run LDP across RSVP-established LSPs, LDP
automatically establishes sessions with the router at the other end of the LSP. LDP
control packets are routed hop-by-hop, rather than carried through the LSP. This routing
allows you to use simplex (one-way) traffic-engineered LSPs. Traffic in the opposite
direction flows through LDP-established LSPs that follow unicast routing rather than
through traffic-engineered tunnels.

Copyright © 2012, Juniper Networks, Inc. 465

Junos OS 12.1 MPLS Applications Configuration Guide

If you configure LDP over RSVP LSPs, you can still configure multiple OSPF areas and
IS-IS levels in the traffic engineered core and in the surrounding LDP cloud.

Label Operations

Figure 26 on page 466 depicts an LDP LSP being tunneled through an RSVP LSP. (For
definitions of label operations, see “Label Description” on page 27.) The shaded inner
oval represents the RSVP domain, whereas the outer oval depicts the LDP domain. RSVP
establishes an LSP through routers B, C, D, and E, with the sequence of labels L3, L4. LDP
establishes an LSP through Routers A, B, E, F, and G, with the sequence of labels L1, L2,
L5. LDP views the RSVP LSP between Routers B and E as a single hop.

When the packet arrives at Router A, it enters the LSP established by LDP, and a label
(L1) is pushed onto the packet. When the packet arrives at Router B, the label (L1) is
swapped with another label (L2). Because the packet is entering the traffic-engineered
LSP established by RSVP, a second label (L3) is pushed onto the packet.

This outer label (L3) is swapped with a new label (L4) at the intermediate router (C)
within the RSVP LSP tunnel, and when the penultimate router (D) is reached, the top
label is popped. Router E swaps the label (L2) with a new label (L5), and the penultimate
router for the LDP-established LSP (F) pops the last label.

Figure 26: Swap and Push When LDP LSPs Are Tunneled Through RSVP LSPs

Figure 27 on page 467 depicts a double push label operation (L1L2). A double push label
operation is used when the ingress router (A) for both the LDP LSP and the RSVP LSP
tunneled through it is the same device. Note that Router D is the penultimate hop for the
LDP-established LSP, so L2 is popped from the packet by Router D.

466 Copyright © 2012, Juniper Networks, Inc.

 Chapter 14: LDP Overview

Figure 27: Double Push When LDP LSPs Are Tunneled Through RSVP LSPs

LDP Message Types

LDP uses the message types described in the following sections to establish and remove
mappings and to report errors. All LDP messages have a common structure that uses a
type, length, and value (TLV) encoding scheme.

• Discovery Messages on page 467

• Session Messages on page 468

• Advertisement Messages on page 468

• Notification Messages on page 468

Discovery Messages

Discovery messages announce and maintain the presence of a router in a network. Routers
indicate their presence in a network by sending hello messages periodically. Hello
messages are transmitted as UDP packets to the LDP port at the group multicast address
for all routers on the subnet.

LDP uses the following discovery procedures:

• Basic discovery—A router periodically sends LDP link hello messages through an
interface. LDP link hello messages are sent as UDP packets addressed to the LDP
discovery port. Receipt of an LDP link hello message on an interface identifies an
adjacency with the LDP peer router.

• Extended discovery—LDP sessions between routers not directly connected are

supported by LDP extended discovery. A router periodically sends LDP targeted hello
messages to a specific address. Targeted hello messages are sent as UDP packets
addressed to the LDP discovery port at the specific address. The targeted router decides
whether to respond to or ignore the targeted hello message. A targeted router that
chooses to respond does so by periodically sending targeted hello messages to the
initiating router.

Copyright © 2012, Juniper Networks, Inc. 467

Junos OS 12.1 MPLS Applications Configuration Guide

Session Messages

Session messages establish, maintain, and terminate sessions between LDP peers. When
a router establishes a session with another router learned through the hello message, it
uses the LDP initialization procedure over TCP transport. When the initialization procedure
is completed successfully, the two routers are LDP peers and can exchange advertisement
messages.

Advertisement Messages

Advertisement messages create, change, and delete label mappings for forwarding
equivalence classes (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 advertises a label mapping to a
neighboring router when it wants the neighbor to use a label.

Notification Messages

Notification messages provide advisory information and signal error information. LDP
sends notification messages to report errors and other events of interest. There are two
kinds of LDP notification messages:

• Error notifications, which signal fatal errors. If a router receives an error notification
from a peer for an LDP session, it terminates the LDP session by closing the TCP
transport connection for the session and discarding all label mappings learned through
the session.

• Advisory notifications, which pass information to a router about the LDP session or the
status of some previous message received from the peer.

LDP Session Protection

LDP session protection is based on the LDP targeted hello functionality defined in RFC
5036, LDP Specification, and is supported by the Junos OS as well as the LDP
implementations of most other vendors. It involves sending unicast User Datagram
Protocol (UDP) hello packets to a remote neighbor address and receiving similar packets
from the neighbor router.

If you configure LDP session protection on a router, the LDP sessions are maintained as
follows:

1. An LDP session is established between a router and a remote neighboring router.

2. If all of the direct links between the routers go down, the LDP session remains up so
long as there is IP connectivity between the routers based on another connection over
the network.

3. When the direct link between the routers is reestablished, the LDP session is not
restarted. The routers simply exchange LDP hellos with each other over the direct link.

468 Copyright © 2012, Juniper Networks, Inc.

 Chapter 14: LDP Overview

They can then begin forwarding LDP-signaled MPLS packets using the original LDP
session.

By default, LDP targeted hellos are set to the remote neighbor so long as the LDP session
is up, even if there are no more link neighbors to that router. You can also specify the
duration you would like to maintain the remote neighbor connection in the absence of
link neighbors. When the last link neighbor for a session goes down, the Junos OS starts
an LDP session protection timer. If this timer expires before any of the link neighbors
come back up, the remote neighbor connection is taken down and the LDP session is
terminated. If you configure a different value for the timer while it is currently running,
the Junos OS updates the timer to the specified value without disrupting the current state
of the LDP session.

LDP Graceful Restart

LDP graceful restart enables a router whose LDP control plane is undergoing a restart to
continue to forward traffic while recovering its state from neighboring routers. It also
enables a router on which helper mode is enabled to assist a neighboring router that is
attempting to restart LDP.

During session initialization, a router advertises its ability to perform LDP graceful restart
or to take advantage of a neighbor performing LDP graceful restart by sending the graceful
restart TLV. This TLV contains two fields relevant to LDP graceful restart: the reconnect
time and the recovery time. The values of the reconnect and recovery times indicate the
graceful restart capabilities supported by the router.

When a router discovers that a neighboring router is restarting, it waits until the end of
the recovery time before attempting to reconnect. The recovery time is the length of time
a router waits for LDP to restart gracefully. The recovery time period begins when an
initialization message is sent or received. This time period is also typically the length of
time that a neighboring router maintains its information about the restarting router,
allowing it to continue to forward traffic.

You can configure LDP graceful restart in both the master instance for the LDP protocol
and for a specific routing instance. You can disable graceful restart at the global level
for all protocols, at the protocol level for LDP only, and on a specific routing instance.
LDP graceful restart is disabled by default, because at the global level, graceful restart
is disabled by default. However, helper mode (the ability to assist a neighboring router
attempting a graceful restart) is enabled by default.

The following are some of the behaviors associated with LDP graceful restart:

• Outgoing labels are not maintained in restarts. New outgoing labels are allocated.

• When a router is restarting, no label-map messages are sent to neighbors that support
graceful restart until the restarting router has stabilized (label-map messages are
immediately sent to neighbors that do not support graceful restart). However, all other
messages (keepalive, address-message, notification, and release) are sent as usual.
Distributing these other messages prevents the router from distributing incomplete
information.

Copyright © 2012, Juniper Networks, Inc. 469

Junos OS 12.1 MPLS Applications Configuration Guide

• Helper mode and graceful restart are independent. You can disable graceful restart in
the configuration, but still allow the router to cooperate with a neighbor attempting
to restart gracefully.

470 Copyright © 2012, Juniper Networks, Inc.

CHAPTER 15

LDP Configuration Guidelines

This chapter describes the minimum required LDP configuration and discusses the
following configuration tasks:

• Minimum LDP Configuration on page 472

• Enabling and Disabling LDP on page 472
• Configuring the LDP Timer for Hello Messages on page 472
• Configuring the Delay Before LDP Neighbors Are Considered Down on page 473
• Enabling Strict Targeted Hello Messages for LDP on page 475
• Configuring the Interval for LDP Keepalive Messages on page 475
• Configuring the LDP Keepalive Timeout on page 475
• Configuring LDP Route Preferences on page 476
• Configuring LDP Graceful Restart on page 476
• Filtering Inbound LDP Label Bindings on page 478
• Filtering Outbound LDP Label Bindings on page 480
• Specifying the Transport Address Used by LDP on page 482
• Configuring the Prefixes Advertised into LDP from the Routing Table on page 483
• Configuring FEC Deaggregation on page 484
• Configuring Policers for LDP FECs on page 484
• Configuring LDP IPv4 FEC Filtering on page 485
• Configuring BFD for LDP LSPs on page 486
• Configuring ECMP-Aware BFD for LDP LSPs on page 488
• Configuring a Failure Action for the BFD Session on an LDP LSP on page 488
• Configuring the Holddown Interval for the BFD Session on page 489
• Configuring OAM Ingress Policies for LDP on page 489
• Configuring LDP LSP Traceroute on page 490
• Collecting LDP Statistics on page 491
• Tracing LDP Protocol Traffic on page 493
• Configuring Miscellaneous LDP Properties on page 495

Copyright © 2012, Juniper Networks, Inc. 471

Junos OS 12.1 MPLS Applications Configuration Guide

Minimum LDP Configuration

To enable LDP on a single interface, include the ldp statement and specify the interface
using the interface statement. This is the minimum LDP configuration. All other LDP
configuration statements are optional.

ldp {
interface interface-name;
}

To enable LDP on all interfaces, specify all for interface-name.

For a list of hierarchy levels at which you can include these statements, see the statement
summary sections.

Enabling and Disabling LDP

LDP is routing-instance-aware. To enable LDP on a specific interface, include the following

statements:

ldp {
interface interface-name;
}

For a list of hierarchy levels at which you can include these statements, see the statement
summary sections.

To enable LDP on all interfaces, specify all for interface-name.

If you have configured interface properties on a group of interfaces and want to disable
LDP on one of the interfaces, include the interface statement with the disable option:

interface interface-name {
disable;
}

For a list of hierarchy levels at which you can include this statement, see the statement
summary section.

Configuring the LDP Timer for Hello Messages

LDP hello messages enable LDP nodes to discover one another and to detect the failure
of a neighbor or the link to the neighbor. Hello messages are sent periodically on all
interfaces where LDP is enabled.

There are two types of LDP hello messages:

• Link hello messages—Sent through the LDP interface as UDP packets addressed to
the LDP discovery port. Receipt of an LDP link hello message on an interface identifies
an adjacency with the LDP peer router.

• Targeted hello messages—Sent as UDP packets addressed to the LDP discovery port
at a specific address. Targeted hello messages are used to support LDP sessions

472 Copyright © 2012, Juniper Networks, Inc.

 Chapter 15: LDP Configuration Guidelines

between routers that are not directly connected. A targeted router determines whether
to respond or ignore a targeted hello message. A targeted router that chooses to
respond does so by periodically sending targeted hello messages back to the initiating
router.

By default, LDP sends hello messages every 5 seconds for link hello messages and every
15 seconds for targeted hello messages. You can configure the LDP timer to alter how
often both types of hello messages are sent. However, you cannot configure a time for
the LDP timer that is greater than the LDP hold time. For more information, see
“Configuring the Delay Before LDP Neighbors Are Considered Down” on page 473.

Configuring the LDP Timer for Link Hello Messages

To modify how often LDP sends link hello messages, specify a new link hello message
interval for the LDP timer using the hello-interval statement:

hello-interval seconds;

For a list of hierarchy levels at which you can include this statement, see the statement
summary section for this statement.

Configuring the LDP Timer for Targeted Hello Messages

To modify how often LDP sends targeted hello messages, specify a new targeted hello
message interval for the LDP timer by configuring the hello-interval statement as an
option for the targeted-hello statement:

targeted-hello {
hello-interval seconds;
}

For a list of hierarchy levels at which you can include these statements, see the statement
summary sections for these statements.

Configuring the Delay Before LDP Neighbors Are Considered Down

The hold time determines how long an LDP node should wait for a hello message before
declaring a neighbor to be down. This value is sent as part of a hello message so that
each LDP node tells its neighbors how long to wait. The values sent by each neighbor do
not have to match.

The hold time should normally be at least three times the hello interval. The default is
15 seconds for link hello messages and 45 seconds for targeted hello messages. However,
it is possible to configure an LDP hold time that is close to the value for the hello interval.

NOTE: By configuring an LDP hold time close to the hello interval (less than
three times the hello interval), LDP neighbor failures might be detected more
quickly. However, this also increases the possibility that the router might
declare an LDP neighbor down that is still functioning normally. For more
information, see “Configuring the LDP Timer for Hello Messages” on page 472.

Copyright © 2012, Juniper Networks, Inc. 473

Junos OS 12.1 MPLS Applications Configuration Guide

The LDP hold time is also negotiated automatically between LDP peers. When two LDP
peers advertise different LDP hold times to one another, the smaller value is used. If an
LDP peer router advertises a shorter hold time than the value you have configured, the
peer router’s advertised hold time is used. This negotiation can affect the LDP keepalive
interval as well.

If the local LDP hold time is not shortened during LDP peer negotiation, the user-configured
keepalive interval is left unchanged. However, if the local hold time is reduced during
peer negotiation, the keepalive interval is recalculated. If the LDP hold time has been
reduced during peer negotiation, the keepalive interval is reduced to one-third of the new
hold time value. For example, if the new hold-time value is 45 seconds, the keepalive
interval is set to 15 seconds.

This automated keepalive interval calculation can cause different keepalive intervals to
be configured on each peer router. This enables the routers to be flexible in how often
they send keepalive messages, because the LDP peer negotiation ensures they are sent
more frequently than the LDP hold time.

When you reconfigure the hold-time interval, changes do not take effect until after the
session is reset. The hold time is negotiated when the LDP peering session is initiated
and cannot be renegotiated as long as the session is up (required by RFC 5036, LDP
Specification). To manually force the LDP session to reset, issue the clear ldp session
command.

Configuring the LDP Hold Time for Link Hello Messages

To modify how long an LDP node should wait for a link hello message before declaring
the neighbor down, specify a new time in seconds using the hold-time statement:

hold-time seconds;

For a list of hierarchy levels at which you can include this statement, see the statement
summary section for this statement.

Configuring the LDP Hold Time for Targeted Hello Messages

To modify how long an LDP node should wait for a targeted hello message before
declaring the neighbor down, specify a new time in seconds using the hold-time statement
as an option for the targeted-hello statement:

targeted-hello {
hold-time seconds;
}

For a list of hierarchy levels at which you can include these statements, see the statement
summary sections for these statements.

474 Copyright © 2012, Juniper Networks, Inc.

 Chapter 15: LDP Configuration Guidelines

Enabling Strict Targeted Hello Messages for LDP

Use strict targeted hello messages to prevent LDP sessions from being established with
remote neighbors that have not been specifically configured. If you configure the
strict-targeted-hellos statement, an LDP peer does not respond to targeted hello
messages coming from a source that is not one of its configured remote neighbors.
Configured remote neighbors can include:

• Endpoints of RSVP tunnels for which LDP tunneling is configured

• Layer 2 circuit neighbors

If an unconfigured neighbor sends a hello message, the LDP peer ignores the message
and logs an error (with the error trace flag) indicating the source. For example, if the LDP
peer received a targeted hello from the Internet address 10.0.0.1 and no neighbor with
this address is specifically configured, the following message is printed to the LDP log
file:

LDP: Ignoring targeted hello from 10.0.0.1

To enable strict targeted hello messages, include the strict-targeted-hellos statement:

strict-targeted-hellos;

For a list of hierarchy levels at which you can include this statement, see the statement
summary section for this statement.

Configuring the Interval for LDP Keepalive Messages

The keepalive interval determines how often a message is sent over the session to ensure
that the keepalive timeout is not exceeded. If no other LDP traffic is sent over the session
in this much time, a keepalive message is sent. The default is 10 seconds. The minimum
value is 1 second.

The value configured for the keepalive interval can be altered during LDP session
negotiation if the value configured for the LDP hold time on the peer router is lower than
the value configured locally. For more information, see “Configuring the Delay Before
LDP Neighbors Are Considered Down” on page 473.

To modify the keepalive interval, include the keepalive-interval statement:

keepalive-interval seconds;

For a list of hierarchy levels at which you can include this statement, see the statement
summary section for this statement.

Configuring the LDP Keepalive Timeout

After an LDP session is established, messages must be exchanged periodically to ensure

that the session is still working. The keepalive timeout defines the amount of time that
the neighbor LDP node waits before deciding that the session has failed. This value is
usually set to at least three times the keepalive interval. The default is 30 seconds.

Copyright © 2012, Juniper Networks, Inc. 475

Junos OS 12.1 MPLS Applications Configuration Guide

To modify the keepalive interval, include the keepalive-timeout statement:

keepalive-timeout seconds;

For a list of hierarchy levels at which you can include this statement, see the statement
summary section for this statement.

The value configured for the keepalive-timeout statement is displayed as the hold time
when you issue the show ldp session detail command.

Configuring LDP Route Preferences

When several protocols calculate routes to the same destination, route preferences are
used to select which route is installed in the forwarding table. The route with the lowest
preference value is selected. The preference value can be a number in the range 0 through
255. By default, LDP routes have a preference value of 9.

To modify the route preferences, include the preference statement:

preference preference;

For a list of hierarchy levels at which you can include this statement, see the statement
summary section for this statement.

Configuring LDP Graceful Restart

When you alter the graceful restart configuration at either the [edit routing-options
graceful-restart] or [edit protocols ldp graceful-restart] hierarchy levels, any running LDP
session is automatically restarted to apply the graceful restart configuration. This behavior
mirrors the behavior of BGP when you alter its graceful restart configuration.

By default, graceful restart helper mode is enabled, but graceful restart is disabled. Thus,
the default behavior of a router is to assist neighboring routers attempting a graceful
restart, but not to attempt a graceful restart itself.

To configure LDP graceful restart, see the following sections:

• Enabling Graceful Restart on page 476

• Disabling LDP Graceful Restart or Helper Mode on page 477
• Configuring Reconnect Time on page 477
• Configuring Recovery Time and Maximum Recovery Time on page 478

Enabling Graceful Restart

To enable LDP graceful restart, you also need to enable graceful restart on the router.
To enable graceful restart, include the graceful-restart statement:

graceful-restart;

You can include this statement at the following hierarchy levels:

• [edit routing-options]

476 Copyright © 2012, Juniper Networks, Inc.

 Chapter 15: LDP Configuration Guidelines

• [edit logical-systems logical-system-name routing-options]

The graceful-restart statement enables graceful restart for all protocols supporting this
feature on the router. For more information about graceful restart, see the Junos OS
Routing Protocols Configuration Guide.

By default, LDP graceful restart is enabled when you enable graceful restart at both the
LDP protocol level and on all the routing instances. However, you can disable both LDP
graceful restart and LDP graceful restart helper mode.

Disabling LDP Graceful Restart or Helper Mode

To disable LDP graceful restart and recovery, include the disable statement:

ldp {
graceful-restart {
disable;
}
}

For a list of hierarchy levels at which you can include this statement, see the statement
summary section for this statement.

You can disable helper mode at the LDP protocols level only. You cannot disable helper
mode for a specific routing instance. To disable LDP helper mode, include the
helper-disable statement:

ldp {
graceful-restart {
helper-disable;
}
}

For a list of hierarchy levels at which you can include this statement, see the statement
summary section for this statement.

The following LDP graceful restart configurations are possible:

• LDP graceful restart and helper mode are both enabled.

• LDP graceful restart is disabled but helper mode is enabled. A router configured in this
way cannot restart gracefully but can help a restarting neighbor.

• LDP graceful restart and helper mode are both disabled. The router does not use LDP
graceful restart or the graceful restart type, length, and value (TLV) sent in the
initialization message. The router behaves as a router that cannot support LDP graceful
restart.

A configuration error is issued if you attempt to enable graceful restart and disable helper
mode.

Configuring Reconnect Time

After the LDP connection between neighbors fails, neighbors wait a certain amount of
time for the gracefully restarting router to resume sending LDP messages. After the wait

Copyright © 2012, Juniper Networks, Inc. 477

Junos OS 12.1 MPLS Applications Configuration Guide

period, the LDP session can be reestablished. You can configure the wait period in seconds.
This value is included in the fault tolerant session TLV sent in LDP initialization messages
when LDP graceful restart is enabled.

Suppose that Router A and Router B are LDP neighbors. Router A is the restarting Router.
The reconnect time is the time that Router A tells Router B to wait after Router B detects
that Router A restarted.

To configure the reconnect time, include the reconnect-time statement:

graceful-restart {
reconnect-time seconds;
}

You can set the reconnect time to a value in the range from 30 through 300 seconds. By
default, it is 60 seconds.

For a list of hierarchy levels at which you can configure these statements, see the
statement summary sections for these statements.

Configuring Recovery Time and Maximum Recovery Time

The recovery time is the amount of time a router waits for LDP to restart gracefully. The
recovery time period begins when an initialization message is sent or received. This period
is also typically the amount of time that a neighboring router maintains its information
about the restarting router, allowing it to continue to forward traffic.

To prevent a neighboring router from being adversely affected if it receives a false value
for the recovery time from the restarting router, you can configure the maximum recovery
time on the neighboring router. A neighboring router maintains its state for the shorter
of the two times. For example, Router A is performing an LDP graceful restart. It has sent
a recovery time of 900 seconds to neighboring Router B. However, Router B has its
maximum recovery time configured at 400 seconds. Router B will only wait for
400 seconds before it purges its LDP information from Router A.

To configure recovery time, include the recovery-time statement and the

maximum-neighbor-recovery-time statement:

graceful-restart {
maximum-neighbor-recovery-time seconds;
recovery-time seconds;
}

For a list of hierarchy levels at which you can configure these statements, see the
statement summary sections for these statements.

Filtering Inbound LDP Label Bindings

You can filter received LDP label bindings, applying policies to accept or deny bindings
advertised by neighboring routers. To configure received-label filtering, include the import
statement:

import [ policy-names ];

478 Copyright © 2012, Juniper Networks, Inc.

 Chapter 15: LDP Configuration Guidelines

For a list of hierarchy levels at which you can include this statement, see the statement
summary section for this statement.

The named policy (configured at the [edit policy-options] hierarchy level) is applied to
all label bindings received from all LDP neighbors. All filtering is done with from
statements. Table 9 on page 479 lists the only from operators that apply to LDP
received-label filtering.

Table 9: from Operators That Apply to LDP Received-Label Filtering

from Operator Description

interface Matches on bindings received from a neighbor that is

adjacent over the specified interface

neighbor Matches on bindings received from the specified LDP

router ID

next-hop Matches on bindings received from a neighbor advertising

the specified interface address

route-filter Matches on bindings with the specified prefix

If a binding is filtered, it still appears in the LDP database, but is not considered for
installation as part of a label-switched path (LSP).

Generally, applying policies in LDP can be used only to block the establishment of LSPs,
not to control their routing. This is because the path that an LSP follows is determined
by unicast routing, and not by LDP. However, when there are multiple equal-cost paths
to the destination through different neighbors, you can use LDP filtering to exclude some
of the possible next hops from consideration. (Otherwise, LDP chooses one of the possible
next hops at random.)

LDP sessions are not bound to interfaces or interface addresses. LDP advertises only
per-router (not per-interface) labels; so if multiple parallel links exist between two routers,
only one LDP session is established, and it is not bound to a single interface. When a
router has multiple adjacencies to the same neighbor, take care to ensure that the filter
does what is expected. (Generally, using next-hop and interface is not appropriate in this
case.)

If a label has been filtered (meaning that it has been rejected by the policy and is not
used to construct an LSP), it is marked as filtered in the database:

user@host> show ldp database

Input label database, 10.10.255.1:0-10.10.255.6:0
Label Prefix
3 10.10.255.6/32 (Filtered)
Output label database, 10.10.255.1:0-10.10.255.6:0
Label Prefix
3 10.10.255.1/32 (Filtered)

For more information about how to configure policies for LDP, see the Junos OS Policy
Framework Configuration Guide.

Copyright © 2012, Juniper Networks, Inc. 479

Junos OS 12.1 MPLS Applications Configuration Guide

Examples: Filtering Inbound LDP Label Bindings

Accept only /32 prefixes from all neighbors:

[edit]
protocols {
ldp {
import only-32;
...
}
}
policy-options {
policy-statement only-32 {
term first {
from {
route-filter 0.0.0.0/0 upto /31;
}
then reject;
}
then accept;
}
}

Accept 131.108/16 or longer from router ID 10.10.255.2 and accept all prefixes from all
other neighbors:

[edit]
protocols {
ldp {
import nosy-neighbor;
...
}
}
policy-options {
policy-statement nosy-neighbor {
term first {
from {
neighbor 10.10.255.2;
route-filter 131.108.0.0/16 orlonger accept;
route-filter 0.0.0.0/0 orlonger reject;
}
}
then accept;
}
}

Filtering Outbound LDP Label Bindings

You can configure export policies to filter LDP outbound labels. You can filter outbound
label bindings by applying routing policies to block bindings from being advertised to
neighboring routers. To configure outbound label filtering, include the export statement:

export [policy-name];

480 Copyright © 2012, Juniper Networks, Inc.

 Chapter 15: LDP Configuration Guidelines

For a list of hierarchy levels at which you can include this statement, see the statement
summary section for this statement.

The named export policy (configured at the [edit policy-options] hierarchy level) is applied
to all label bindings transmitted to all LDP neighbors. The only from operator that applies
to LDP outbound label filtering is route-filter, which matches bindings with the specified
prefix. The only to operators that apply to outbound label filtering are the operators in
Table 10 on page 481.

Table 10: to Operators for LDP Outbound-Label Filtering

to Operator Description

interface Matches on bindings sent to a neighbor that is adjacent over the specified
interface

neighbor Matches on bindings sent to the specified LDP router ID

next-hop Matches on bindings sent to a neighbor advertising the specified interface

address

If a binding is filtered, the binding is not advertised to the neighboring router, but it can
be installed as part of an LSP on the local router. You can apply policies in LDP to block
the establishment of LSPs, but not to control their routing. The path an LSP follows is
determined by unicast routing, not by LDP.

LDP sessions are not bound to interfaces or interface addresses. LDP advertises only
per-router (not per-interface) labels. If multiple parallel links exist between two routers,
only one LDP session is established, and it is not bound to a single interface.

Do not use the next-hop and interface operators when a router has multiple adjacencies
to the same neighbor.

Filtered labels are marked in the database:

user@host> show ldp database

Input label database, 10.10.255.1:0-10.10.255.3:0
Label Prefix
100007 10.10.255.2/32
3 10.10.255.3/32
Output label database, 10.10.255.1:0-10.10.255.3:0
Label Prefix
3 10.10.255.1/32
100001 10.10.255.6/32 (Filtered)

For more information about how to configure policies for LDP, see the Junos OS Policy
Framework Configuration Guide.

Examples: Filtering Outbound LDP Label Bindings

Block transmission of the route for 10.10.255.6/32 to any neighbors:

[edit protocols]
ldp {
export block-one;

Copyright © 2012, Juniper Networks, Inc. 481

Junos OS 12.1 MPLS Applications Configuration Guide

}
policy-options {
policy-statement block-one {
term first {
from {
route-filter 10.10.255.6/32 exact;
}
then reject;
}
then accept;
}
}

Send only 131.108/16 or longer to router ID 10.10.255.2, and send all prefixes to all other
routers:

[edit protocols]
ldp {
export limit-lsps;
}
policy-options {
policy-statement limit-lsps {
term allow-one {
from {
route-filter 131.108.0.0/16 orlonger;
}
to {
neighbor 10.10.255.2;
}
then accept;
}
term block-the-rest {
to {
neighbor 10.10.255.2;
}
then reject;
}
then accept;
}
}

Specifying the Transport Address Used by LDP

You can control the transport address used by LDP. The transport address is the address
used for the TCP session over which LDP is running. To configure transport address
control, include the transport-address statement:

transport-address (router-id | interface);

For a list of hierarchy levels at which you can include this statement, see the statement
summary section for this statement.

If you specify the router-id option, the address of the router identifier is used as the
transport address (unless otherwise configured, the router identifier is typically the same
as the loopback address). If you specify the interface option, the interface address is used

482 Copyright © 2012, Juniper Networks, Inc.

 Chapter 15: LDP Configuration Guidelines

as the transport address for any LDP sessions to neighbors that can be reached over that
interface. Note that the router identifier is used as the transport address by default.

You cannot specify the interface option 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, either by disconnecting the neighbor on an interface or by specifying the
router-id option.

Configuring the Prefixes Advertised into LDP from the Routing Table

You can control the set of prefixes that are advertised into LDP and cause the router to
be the egress router for those prefixes. By default, only the loopback address is advertised
into LDP. To configure the set of prefixes from the routing table to be advertised into
LDP, include the egress-policy statement:

egress-policy policy-name;

For a list of hierarchy levels at which you can include this statement, see the statement
summary section for this statement.

NOTE: If you configure an egress policy for LDP that does not include the
loopback address, it is no longer advertised in LDP. To continue to advertise
the loopback address, you need to explicitly configure it as a part of the LDP
egress policy.

The named policy (configured at the [edit policy-options] or [edit logical-systems

logical-system-name policy-options] hierarchy level) is applied to all routes in the routing
table. Those routes that match the policy are advertised into LDP. You can control the
set of neighbors to which those prefixes are advertised by using the export statement.
Only from operators are considered; you can use any valid from operator. For more
information, see the Junos OS Routing Protocols Configuration Guide.

Example: Configuring the Prefixes Advertised into LDP

Advertise all connected routes into LDP:

[edit protocols]
ldp {
egress-policy connected-only;
}
policy-options {
policy-statement connected-only {
from {
protocol direct;
}
then accept;
}
}

Copyright © 2012, Juniper Networks, Inc. 483

Junos OS 12.1 MPLS Applications Configuration Guide

Configuring FEC Deaggregation

When an LDP egress router advertises multiple prefixes, the prefixes are bound to a single
label and aggregated into a single forwarding equivalence class (FEC). By default, LDP
maintains this aggregation as the advertisement traverses the network.

By default, because an LSP cannot be split across multiple next hops and all the prefixes
are bound into a single LSP, you cannot load-balance across equal-cost paths.

To change the default to load-balance across equal-cost paths, you need to deaggregate
the FECs. Deaggregating the FECs causes each prefix to be bound to a separate label
and become a separate LSP.

To configure deaggregated FECs, include the deaggregate statement:

deaggregate;

For a list of hierarchy levels at which you can include this statement, see the statement
summary section for this statement.

For all LDP sessions, you can configure deaggregated FECs only globally.

Deaggregating a FEC allows the resulting multiple LSPs to be distributed across multiple
equal-cost paths and distributes LSPs across the multiple next hops on the egress
segments but installs only one next hop per LSP.

To aggregate FECs, include the no-deaggregate statement:

no-deaggregate;

For a list of hierarchy levels at which you can include this statement, see the statement
summary section for this statement.

For all LDP sessions, you can configure aggregated FECs only globally.

Configuring Policers for LDP FECs

You can configure the Junos OS to track and police traffic for LDP FECs. LDP FEC policers
can be used to do any of the following:

• Track or police the ingress traffic for an LDP FEC.

• Track or police the transit traffic for an LDP FEC.

• Track or police LDP FEC traffic originating from a specific forwarding class.

• Track or police LDP FEC traffic originating from a specific virtual routing and forwarding
(VRF) site.

• Discard false traffic bound for a specific LDP FEC.

To police traffic for an LDP FEC, you must first configure a filter. Specifically, you need
to configure either the interface statement or the interface-set statement at the [edit
firewall family protocol-family filter filter-name term term-name from] hierarchy level. The

484 Copyright © 2012, Juniper Networks, Inc.

 Chapter 15: LDP Configuration Guidelines

interface statement allows you to match the filter to a single interface. The interface-set
statement allows you to match the filter to multiple interfaces.

For more information on how to configure the interface statement, the interface-set
statement, and policers for LDP FECs, see the Junos OS Policy Framework Configuration
Guide.

Once you have configured the filters, you need to include them in the policing statement
configuration for LDP. To configure policers for LDP FECs, include the policing statement:

policing {
fec fec-address {
ingress-traffic filter-name;
transit-traffic filter-name;
}
}

For a list of hierarchy levels at which you can include this statement, see the statement
summary section for this statement.

The policing statement includes the following options:

• fec—Specify the FEC address for the LDP FEC you want to police.

• ingress-filter—Specify the name of the ingress traffic filter.

• transit-traffic—Specify the name of the transit traffic filter.

Configuring LDP IPv4 FEC Filtering

By default, when a targeted LDP session is established, the Junos OS always exchanges
both the IPv4 forwarding equivalence classes (FECs) and the Layer 2 circuit FECs over
the targeted LDP session. For an LDP session to an indirectly connected neighbor, you
might only want to export Layer 2 circuit FECs to the neighbor if the session was
specifically configured to support Layer 2 circuits or VPLS.

In a mixed vendor network where all non-BGP prefixes are advertised into LDP, the LDP
database can become large. For this type of environment, it can be useful to prevent the
advertisement of IPv4 FECs over LDP sessions formed because of Layer 2 circuit or LDP
VPLS configuration. Similarly, it can be useful to filter any IPv4 FECs received in this sort
of environment.

If all the LDP neighbors associated with an LDP session are Layer 2 only, you can configure
the Junos OS to advertise only Layer 2 circuit FECs by configuring the l2-smart-policy
statement. This feature also automatically filters out the IPv4 FECs received on this
session. If you have configured an explicit export or import policy, this feature is disabled.

If one of the LDP session’s neighbors is formed because of a discovered adjacency or if

the adjacency is formed because of an LDP tunneling configuration on one or more RSVP
LSPs, the IPv4 FECs are advertised and received using the default behavior.

Copyright © 2012, Juniper Networks, Inc. 485

Junos OS 12.1 MPLS Applications Configuration Guide

To prevent LDP from exporting IPv4 FECs over LDP sessions with Layer 2 neighbors only
and to filter out IPv4 FECs received over such sessions, include the l2-smart-policy
statement:

l2-smart-policy;

For a list of hierarchy levels at which you can configure this statement, see the statement
summary for this statement.

Configuring BFD for LDP LSPs

You can configure Bidirectional Forwarding Detection (BFD) for LDP LSPs. The BFD
protocol is a simple hello mechanism that detects failures in a network. Hello packets
are sent at a specified, regular interval. A neighbor failure is detected when the router
stops receiving a reply after a specified interval. BFD works with a wide variety of network
environments and topologies. The failure detection timers for BFD have shorter time
limits than the failure detection mechanisms of static routes, providing faster detection.

An error is logged whenever a BFD session for a path fails. The following shows how BFD
for LDP LSP log messages might appear:
RPD_LDP_BFD_UP: LDP BFD session for FEC 10.255.16.14/32 is up
RPD_LDP_BFD_DOWN: LDP BFD session for FEC 10.255.16.14/32 is down

You can also configure BFD for RSVP LSPs, as described in “Configuring BFD for
RSVP-Signaled LSPs” on page 268.

To enable BFD for LDP LSPs, include the oam and bfd-liveness-detection statements:

oam {
bfd-liveness-detection {
detection-time threshold milliseconds;
ecmp;
failure-action {
remove-nexthop;
remove-route;
}
holddown-interval seconds;
ingress-policy ingress-policy-name;
minimum-interval milliseconds;
minimum-receive-interval milliseconds;
minimum-transmit-interval milliseconds;
multiplier detection-time-multiplier;
no-adaptation;
transmit-interval {
minimum-interval milliseconds;
threshold milliseconds;
}
}
fec fec-address;
lsp-ping-interval seconds;
periodic-traceroute {
disable;
exp exp-value;
fanout fanout-value;

486 Copyright © 2012, Juniper Networks, Inc.

 Chapter 15: LDP Configuration Guidelines

frequency minutes;
paths number-of-paths;
retries retry-attempts;
source address;
ttl ttl-value;
wait seconds;
}
}

You can enable BFD for the LDP LSPs associated with a specific forwarding equivalence
class (FEC) by configuring the FEC address using the fec option at the [edit protocols
ldp] hierarchy level. Alternatively, you can configure an Operation Administration and
Management (OAM) ingress policy to enable BFD on a range of FEC addresses. For more
information, see “Configuring OAM Ingress Policies for LDP” on page 489.

You cannot enable BFD LDP LSPs unless their equivalent FEC addresses are explicitly
configured or OAM is enabled on the FECs using an OAM ingress policy. If BFD is not
enabled for any FEC addresses, the BFD session will not come up.

You can configure the oam statement at the following hierarchy levels:

• [edit protocols ldp]

• [edit logical-systems logical-system-name protocols ldp]

The oam statement includes the following options:

• fec—Specify the FEC address. You must either specify a FEC address or configure an
OAM ingress policy to ensure that the BFD session comes up.

• lsp-ping-interval—Specify the duration of the LSP ping interval in seconds. To issue a

ping on an LDP-signaled LSP, use the ping mpls ldp command. For more information,
see the Junos OS System Basics and Services Command Reference.

The bfd-liveness-detection statement includes the following options:

• ecmp—Cause LDP to establish BFD sessions for all ECMP paths configured for the
specified FEC. If you configure the ecmp option, you must also configure the
periodic-traceroute statement for the specified FEC. If you do not do so, the commit
operation fails. You can configure the periodic-traceroute statement at the global
hierarchy level ([edit protocols ldp oam]) while only configuring the ecmp option for a
specific FEC ([edit protocols ldp oam fec address bfd-liveness-detection]).

• holddown-interval—Specify the duration the BFD session should remain up before

adding the route or next hop. Specifying a time of 0 seconds causes the route or next
hop to be added as soon as the BFD session comes back up.

• minimum-interval—Specify the minimum transmit and receive interval. If you configure

the minimum-interval option, you do not need to configure the minimum-receive-interval
option or the minimum-transmit-interval option.

• minimum-receive-interval—Specify the minimum receive interval. The range is from 1

through 255,000 milliseconds.

Copyright © 2012, Juniper Networks, Inc. 487

Junos OS 12.1 MPLS Applications Configuration Guide

• minimum-transmit-interval—Specify the minimum transmit interval. The range is from

1 through 255,000 milliseconds.

• multiplier—Specify the detection time multiplier. The range is from 1 through 255.

Configuring ECMP-Aware BFD for LDP LSPs

When you configure BFD for a FEC, a BFD session is established for only one active local
next-hop for the router. However, you can configure multiple BFD sessions, one for each
FEC associated with a specific equal-cost multipath (ECMP) path. For this to function
properly, you also need to configure LDP LSP periodic traceroute. (See “Configuring LDP
LSP Traceroute” on page 490.) LDP LSP traceroute is used to discover ECMP paths. A BFD
session is initiated for each ECMP path discovered. Whenever a BFD session for one of
the ECMP paths fails, an error is logged.

LDP LSP traceroute is run periodically to check the integrity of the ECMP paths. The
following might occur when a problem is discovered:

• If the latest LDP LSP traceroute for a FEC differs from the previous traceroute, the BFD
sessions associated with that FEC (the BFD sessions for address ranges that have
changed from previous run) are brought down and new BFD sessions are initiated for
the destination addresses in the altered ranges.

• If the LDP LSP traceroute returns an error (for example, a timeout), all the BFD sessions
associated with that FEC are torn down.

To configure LDP to establish BFD sessions for all ECMP paths configured for the specified
FEC, include the ecmp statement.

ecmp;

For a list of hierarchy levels at which you can include this statement, see the statement
summary section for this statement.

Along with the ecmp statement, you must also include the periodic-traceroute statement,
either in the global LDP OAM configuration (at the [edit protocols ldp oam] or [edit
logical-systems logical-system-name protocols ldp oam] hierarchy level) or in the
configuration for the specified FEC (at the [edit protocols ldp oam fec address] or [edit
logical-systems logical-system-name protocols ldp oam fec address] hierarchy level).
Otherwise, the commit operation fails.

Configuring a Failure Action for the BFD Session on an LDP LSP

You can configure route and next-hop properties in the event of a BFD session failure
event on an LDP LSP. The failure event could be an existing BFD session that has gone
down or could be a BFD session that never came up. LDP adds back the route or next
hop when the relevant BFD session comes back up.

488 Copyright © 2012, Juniper Networks, Inc.

 Chapter 15: LDP Configuration Guidelines

You can configure one of the following failure action options for the failure-action
statement in the event of a BFD session failure on the LDP LSP:

• remove-nexthop—Removes the route corresponding to the next hop of the LSP's route
at the ingress node when a BFD session failure event is detected.

• remove-route—Removes the route corresponding to the LSP from the appropriate

routing tables when a BFD session failure event is detected. If the LSP is configured
with ECMP and a BFD session corresponding to any path goes down, the route is
removed.

To configure a failure action in the event of a BFD session failure on an LDP LSP, include
either the remove-nexthop option or the remove-route option for the failure-action
statement:

failure-action {
remove-nexthop;
remove-route;
}

For a list of hierarchy levels at which you can include this statement, see the statement
summary section for this statement.

Configuring the Holddown Interval for the BFD Session

You can specify the duration the BFD session should be up before adding a route or next
hop by configuring the holddown-interval statement at either the [edit protocols ldp oam
bfd-livenesss-detection] hierarchy level or at the [edit protocols ldp oam fec address
bfd-livenesss-detection] hierarchy level. Specifying a time of 0 seconds causes the route
or next hop to be added as soon as the BFD session comes back up.

holddown-interval seconds;

For a list of hierarchy levels at which you can include this statement, see the statement
summary section for this statement.

Configuring OAM Ingress Policies for LDP

Using the ingress-policy statement, you can configure an Operation, Administration, and
Management (OAM) policy to choose which forwarding equivalence classes (FECs) need
to have OAM enabled. If the FEC passes through the policy or if the FEC is explicitly
configured, OAM is enabled for a FEC. For FECs chosen using a policy, the BFD parameters
configured under [edit protocols ldp oam bfd-liveness-detection] are applied.

You configure the OAM ingress policy at the [edit policy-options] hierarchy level. To
configure an OAM ingress policy, include the ingress-policy statement:

ingress-policy ingress-policy-name;

You can configure this statement at the following hierarchy levels:

• [edit protocols ldp oam]

• [edit logical-systems logical-system-name protocols ldp oam]

Copyright © 2012, Juniper Networks, Inc. 489

Junos OS 12.1 MPLS Applications Configuration Guide

Configuring LDP LSP Traceroute

You can trace the route followed by an LDP-signaled LSP. LDP LSP traceroute is based
on RFC 4379, Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures. This
feature allows you to periodically trace all paths in a FEC. The FEC topology information
is stored in a database accessible from the CLI.

A topology change does not automatically trigger a trace of an LDP LSP. However, you
can manually initiate a traceroute. If the traceroute request is for an FEC that is currently
in the database, the contents of the database are updated with the results.

The periodic traceroute feature applies to all FECs specified by the oam statement
configured at the [edit protocols ldp] hierarchy level. To configure periodic LDP LSP
traceroute, include the periodic-traceroute statement:

periodic-traceroute {
disable;
exp exp-value;
fanout fanout-value;
frequency minutes;
paths number-of-paths;
retries retry-attempts;
source address;
ttl ttl-value;
wait seconds;
}

You can configure this statement at the following hierarchy levels:

• [edit protocols ldp oam]

• [edit protocols ldp oam fec address]

You can configure the periodic-traceroute statement by itself or with any of the following
options:

• exp—Specify the class of service to use when sending probes.

• fanout—Specify the maximum number of next hops to search per node.

• frequency—Specify the interval between traceroute attempts.

• paths—Specify the maximum number of paths to search.

• retries—Specify the number of attempts to send a probe to a specific node before

giving up.

• source—Specify the IPv4 source address to use when sending probes.

• ttl—Specify the maximum time-to-live value. Nodes that are beyond this value are not
traced.

• wait—Specify the wait interval before resending a probe packet.

490 Copyright © 2012, Juniper Networks, Inc.

 Chapter 15: LDP Configuration Guidelines

Collecting LDP Statistics

LDP traffic statistics show the volume of traffic that has passed through a particular FEC
on a router.

When you configure the traffic-statistics statement at the [edit protocols ldp] hierarchy
level, the LDP traffic statistics are gathered periodically and written to a file. You can
configure how often statistics are collected (in seconds) by using the interval option. The
default collection interval is 5 minutes. You must configure an LDP statistics file; otherwise,
LDP traffic statistics are not gathered. If the LSP goes down, the LDP statistics are reset.

To collect LDP traffic statistics, include the traffic-statistics statement:

traffic-statistics {
file filename <files number> <size size> <world-readable | no-world-readable>;
interval interval;
no-penultimate-hop;
}

For a list of hierarchy levels at which you can include this statement, see the statement
summary section for this statement.

This section includes the following topics:

• LDP Statistics Output on page 491

• Disabling LDP Statistics on the Penultimate-Hop Router on page 492
• LDP Statistics Limitations on page 492

LDP Statistics Output

The following sample output is from an LDP statistics file:
FEC Type Packets Bytes Shared
10.255.350.448/32 Transit 0 0 No
Ingress 0 0 No
10.255.350.450/32 Transit 0 0 Yes
Ingress 0 0 No
10.255.350.451/32 Transit 0 0 No
Ingress 0 0 No
220.220.220.1/32 Transit 0 0 Yes
Ingress 0 0 No
220.220.220.2/32 Transit 0 0 Yes
Ingress 0 0 No
220.220.220.3/32 Transit 0 0 Yes
Ingress 0 0 No
May 28 15:02:05, read 12 statistics in 00:00:00 seconds

The LDP statistics file includes the following columns of data:

• Bytes—Number of bytes of data passed by the FEC since its LSP came up.

• FEC—FEC for which LDP traffic statistics are collected.

• Packets—Number of packets passed by the FEC since its LSP came up.

Copyright © 2012, Juniper Networks, Inc. 491

Junos OS 12.1 MPLS Applications Configuration Guide

• read—This number (which appears next to the date and time) might differ from the
actual number of the statistics displayed. Some of the statistics are summarized before
being displayed.

• Shared—A Yes value indicates that several prefixes are bound to the same label (for
example, when several prefixes are advertised with an egress policy). The LDP traffic
statistics for this case apply to all the prefixes and should be treated as such.

• Type—Type of traffic originating from a router, either Ingress (originating from this
router) or Transit (forwarded through this router).

Disabling LDP Statistics on the Penultimate-Hop Router

Gathering LDP traffic statistics at the penultimate-hop router can consume excessive
system resources, on next-hop routes in particular. This problem is exacerbated if you
have configured the deaggregate statement in addition to the traffic-statistics statement.
For routers reaching their limit of next-hop route usage, we recommend configuring the
no-penultimate-hop option for the traffic-statistics statement:

traffic-statistics {
no-penultimate-hop;
}

For a list of hierarchy levels at which you can configure the traffic-statistics statement,
see the statement summary section for this statement.

NOTE: When you configure the no-penultimate-hop option, no statistics are

available for the FECs that are the penultimate hop for this router.

Whenever you include or remove this option from the configuration, the LDP
sessions are taken down and then restarted.

The following sample output is from an LDP statistics file showing routers on which the
no-penultimate-hop option is configured:

FEC Type Packets Bytes Shared

10.255.245.218/32 Transit 0 0 No
Ingress 4 246 No
10.255.245.221/32 Transit statistics disabled
Ingress statistics disabled
13.1.1.0/24 Transit statistics disabled
Ingress statistics disabled
13.1.3.0/24 Transit statistics disabled
Ingress statistics disabled

LDP Statistics Limitations

The following are issues related to collecting LDP statistics by configuring the
traffic-statistics statement:

• You cannot clear the LDP statistics.

492 Copyright © 2012, Juniper Networks, Inc.

 Chapter 15: LDP Configuration Guidelines

• If you shorten the specified interval, a new LDP statistics request is issued only if the
statistics timer expires later than the new interval.

• A new LDP statistics collection operation cannot start until the previous one has
finished. If the interval is short or if the number of LDP statistics is large, the time gap
between the two statistics collections might be longer than the interval.

When an LSP goes down, the LDP statistics are reset.

Tracing LDP Protocol Traffic

The following sections describe how to configure the trace options to examine LDP
protocol traffic:

• Tracing LDP Protocol Traffic at the Protocol and Routing Instance Levels on page 493
• Tracing LDP Protocol Traffic Within FECs on page 494
• Examples: Tracing LDP Protocol Traffic on page 494

Tracing LDP Protocol Traffic at the Protocol and Routing Instance Levels
To trace LDP protocol traffic, you can specify options in the global traceoptions statement
at the [edit routing-options] hierarchy level, and you can specify LDP-specific options by
including the traceoptions statement:

traceoptions {
file filename <files number> <size size> <world-readable | no-world-readable>;
flag flag <flag-modifier> <disable>;
}

For a list of hierarchy levels at which you can include this statement, see the statement
summary section for this statement.

Use the file statement to specify the name of the file that receives the output of the
tracing operation. All files are placed in the directory /var/log. We recommend that you
place LDP-tracing output in the file ldp-log.

The following trace flags display the operations associated with the sending and receiving
of various LDP messages. Each can carry one or more of the following modifiers:

• address—Trace the operation of address and address withdrawal messages.

• binding—Trace label-binding operations.

• error—Trace error conditions.

• event—Trace protocol events.

• initialization—Trace the operation of initialization messages.

• label—Trace the operation of label request, label map, label withdrawal, and label
release messages.

• notification—Trace the operation of notification messages.

Copyright © 2012, Juniper Networks, Inc. 493

Junos OS 12.1 MPLS Applications Configuration Guide

• packets—Trace the operation of address, address withdrawal, initialization, label

request, label map, label withdrawal, label release, notification, and periodic messages.
This modifier is equivalent to setting the address, initialization, label, notification, and
periodic modifiers.

You can also configure the filter flag modifier with the match-on address sub-option
for the packets flag. This allows you to trace based on the source and destination
addresses of the packets.

• path—Trace label-switched path operations.

• periodic—Trace the operation of hello and keepalive messages.

• route—Trace the operation of route messages.

• state—Trace protocol state transitions.

Tracing LDP Protocol Traffic Within FECs

You can trace LDP protocol traffic within a specific FEC. You can filter LDP trace
statements based on a FEC. The following trace flags are available for this purpose: route,
path, and binding.

The following example illustrates how you might configure the LDP traceoptions statement
to filter LDP trace statements based on a FEC:

[edit protocols ldp traceoptions]

flag route filter match-on fec policy "filter-policy-for-ldp-fec";

This feature has the following limitations:

• The filtering capability is only available for FECs composed of IP version 4 (IPv4)
prefixes.

• Layer 2 circuit FECs cannot be filtered.

• When you configure both route tracing and filtering, MPLS routes are not displayed
(they are blocked by the filter).

• Filtering is determined by the policy and the configured value for the match-on option.
When configuring the policy, be sure that the default behavior is always reject.

• The only match-on option is fec. Consequently, the only type of policy you should
include is a route-filter policy.

Examples: Tracing LDP Protocol Traffic

Trace LDP path messages in detail:

[edit]
protocols {
ldp {
traceoptions {
file ldp size 10m files 5;
flag path;
}

494 Copyright © 2012, Juniper Networks, Inc.

 Chapter 15: LDP Configuration Guidelines

}
}

Trace all LDP outgoing messages:

[edit]
protocols {
ldp {
traceoptions {
file ldp size 10m files 5;
flag packets;
}
}
}

Trace all LDP error conditions:

[edit]
protocols {
ldp {
traceoptions {
file ldp size 10m files 5;
flag error;
}
}
}

Trace all LDP incoming messages and all label-binding operations:

[edit]
protocols {
ldp {
traceoptions {
file ldp size 10m files 5 world-readable;
flag packets receive;
flag binding;
}
interface all {
}
}
}

Configuring Miscellaneous LDP Properties

The following sections describe how to configure a number of miscellaneous LDP

properties:

• Configuring LDP to Use the IGP Route Metric on page 496

• Preventing Addition of Ingress Routes to the inet.0 Routing Table on page 496
• Multiple-Instance LDP and Carrier-of-Carriers VPNs on page 496
• Configuring MPLS and LDP to Pop the Label on the Ultimate-Hop Router on page 496
• Enabling LDP over RSVP-Established LSPs on page 497
• Enabling LDP over RSVP-Established LSPs in Heterogeneous Networks on page 497
• Configuring the TCP MD5 Signature for LDP Sessions on page 498

Copyright © 2012, Juniper Networks, Inc. 495

Junos OS 12.1 MPLS Applications Configuration Guide

• Configuring LDP Session Protection on page 499

• Disabling SNMP Traps for LDP on page 499
• Configuring LDP Synchronization with the IGP on LDP Links on page 499
• Configuring LDP Synchronization with the IGP on the Router on page 500
• Configuring the Label Withdrawal Timer on page 500
• Ignoring the LDP Subnet Check on page 501

Configuring LDP to Use the IGP Route Metric

Use the track-igp-metric statement if you want the interior gateway protocol (IGP) route
metric to be used for the LDP routes instead of the default LDP route metric (the default
LDP route metric is 1).

To use the IGP route metric, include the track-igp-metric statement:

track-igp-metric;

For a list of hierarchy levels at which you can include this statement, see the statement
summary section for this statement.

Preventing Addition of Ingress Routes to the inet.0 Routing Table

By configuring the no-forwarding statement, you can prevent ingress routes from being
added to the inet.0 routing table instead of the inet.3 routing table even if you enabled
the traffic-engineering bgp-igp statement at the [edit protocols mpls] or the [edit
logical-systems logical-system-name protocols mpls] hierarchy level. By default, the
no-forwarding statement is disabled.

To omit ingress routes from the inet.0 routing table, include the no-forwarding statement:

no-forwarding;

For a list of hierarchy levels at which you can include this statement, see the statement
summary section for this statement.

Multiple-Instance LDP and Carrier-of-Carriers VPNs

By configuring multiple LDP routing instances, you can use LDP to advertise labels in a
carrier-of-carriers VPN from a service provider provider edge (PE) router to a customer
carrier customer edge (CE) router. This is especially useful when the carrier customer is
a basic Internet service provider (ISP) and wants to restrict full Internet routes to its PE
routers. By using LDP instead of BGP, the carrier customer shields its other internal routers
from the Internet. Multiple-instance LDP is also useful when a carrier customer wants to
provide Layer 2 or Layer 3 VPN services to its customers.

For an example of how to configure multiple LDP routing instances for carrier-of-carriers
VPNs, see the Multiple Instances for Label Distribution Protocol Feature Guide.

Configuring MPLS and LDP to Pop the Label on the Ultimate-Hop Router
The default advertised label is label 3 (Implicit Null label). If label 3 is advertised, the
penultimate-hop router removes the label and sends the packet to the egress router. If

496 Copyright © 2012, Juniper Networks, Inc.

 Chapter 15: LDP Configuration Guidelines

ultimate-hop popping is enabled, label 0 (IPv4 Explicit Null label) is advertised.

Ultimate-hop popping ensures that any packets traversing an MPLS network include a
label.

To configure ultimate-hop popping, include the explicit-null statement:

explicit-null;

For a list of hierarchy levels at which you can include this statement, see the statement
summary section for this statement.

NOTE: Juniper Networks routers queue packets based on the incoming label.
Routers from other vendors might queue packets differently. Keep this in
mind when working with networks containing routers from multiple vendors.

For more information about labels, see “Label Description” on page 27 and “Label
Allocation” on page 28.

Enabling LDP over RSVP-Established LSPs

You can run LDP over LSPs established by RSVP, effectively tunneling the LDP-established
LSP through the one established by RSVP. To do so, enable LDP on the lo0.0 interface
(see “Enabling and Disabling LDP” on page 472). You must also configure the LSPs over
which you want LDP to operate by including the ldp-tunneling statement at the [edit
protocols mpls label-switched-path lsp-name] hierarchy level:

[edit]
protocols {
mpls {
label-switched-path lsp-name {
from source;
to destination;
ldp-tunneling;
}
}
}

For a list of hierarchy levels at which you can include this statement, see the statement
summary section for this statement.

Related • Tunneling LDP LSPs in RSVP LSPs Overview on page 465

Documentation

Enabling LDP over RSVP-Established LSPs in Heterogeneous Networks

Some other vendors use an OSPF metric of 1 for the loopback address. Juniper Networks
routers use an OSPF metric of 0 for the loopback address. This might require that you
manually configure the RSVP metric when deploying LDP tunneling over RSVP LSPs in
heterogeneous networks.

When a Juniper Networks router is linked to another vendor’s router through an RSVP
tunnel, and LDP tunneling is also enabled, by default the Juniper Networks router might

Copyright © 2012, Juniper Networks, Inc. 497

Junos OS 12.1 MPLS Applications Configuration Guide

not use the RSVP tunnel to route traffic to the LDP destinations downstream of the other
vendor’s egress router if the RSVP path has a metric of 1 larger than the physical OSPF
path.

To ensure that LDP tunneling functions properly in heterogeneous networks, you can
configure OSPF to ignore the RSVP LSP metric by including the ignore-lsp-metrics
statement:

ignore-lsp-metrics;

You can configure this statement at the following hierarchy levels:

• [edit protocols ospf traffic-engineering shortcuts]

• [edit logical-systems logical-system-name protocols ospf traffic-engineering shortcuts]

To enable LDP over RSVP LSPs, you also still need to complete the procedure in “Enabling
LDP over RSVP-Established LSPs” on page 497.

Configuring the TCP MD5 Signature for LDP Sessions

You can configure an MD5 signature for an LDP TCP connection to protect against the
introduction of spoofed TCP segments into LDP session connection streams.

A router using the MD5 signature option is configured with a password for each peer for
which authentication is required. The password is stored encrypted.

LDP hello adjacencies can still be created even when peering interfaces are configured
with different security signatures. However, the TCP session cannot be authenticated
and is never established.

NOTE: If you apply an MD5 signature to an LDP interface with an established

session, it drops the TCP connection and all the associated label bindings to
the FEC entries for that session. The session regenerates the database
information for that session once both interfaces agree on a common security
method and password.

To configure an MD5 signature for an LDP TCP connection, include the session and
authentication-key statement:

session address {
authentication-key md5-authentication-key;
}

For a list of hierarchy levels at which you can include these statements, see the statement
summary section for the session statement.

Use the session statement to configure the address for the remote end of the LDP session.

The md5-authentication-key (password) can be up to 69 characters long. Characters can

include any ASCII strings. If you include spaces, enclose all characters in quotation marks.

498 Copyright © 2012, Juniper Networks, Inc.

 Chapter 15: LDP Configuration Guidelines

Configuring LDP Session Protection

An LDP session is normally created between a pair of routers that are connected by one
or more links. The routers form one hello adjacency for every link that connects them
and associate all the adjacencies with the corresponding LDP session. When the last
hello adjacency for an LDP session goes away, the LDP session is terminated. You might
want to modify this behavior to prevent an LDP session from being unnecessarily
terminated and reestablished.

You can configure the Junos OS to leave the LDP session between two routers up even
if there are no hello adjacencies on the links connecting the two routers by configuring
the session-protection statement. You can optionally specify a time in seconds using the
timeout option. The session remains up for the duration specified as long as the routers
maintain IP network connectivity.

session-protection {
timeout seconds;
}

For a list of hierarchy levels at which you can include this statement, see the statement
summary section.

Disabling SNMP Traps for LDP

Whenever an LDP LSP makes a transition from up to down, or down to up, the router
sends an SNMP trap. However, it is possible to disable the LDP SNMP traps on a router,
logical system, or routing instance.

For information about the LDP SNMP traps and the proprietary LDP MIB, see the Junos
OS Network Management Configuration Guide.

To disable SNMP traps for LDP, specify the trap disable option for the log-updown
statement:

log-updown {
trap disable;
}

For a list of hierarchy levels at which you can include this statement, see the statement
summary section for this statement.

Configuring LDP Synchronization with the IGP on LDP Links

LDP is a protocol for distributing labels in non-traffic-engineered applications. Labels
are distributed along the best path determined by the IGP. If synchronization between
LDP and the IGP is not maintained, the LSP goes down. When LDP is not fully operational
on a given link (a session is not established and labels are not exchanged), the IGP
advertises the link with the maximum cost metric. The link is not preferred but remains
in the network topology.

LDP synchronization is supported only on active point-to-point interfaces and LAN

interfaces configured as point-to-point under the IGP. LDP synchronization is not
supported during graceful restart.

Copyright © 2012, Juniper Networks, Inc. 499

Junos OS 12.1 MPLS Applications Configuration Guide

To advertise the maximum cost metric until LDP is operational for synchronization, include
the ldp-synchronization statement:

ldp-synchronization {
disable;
hold-time seconds;
}

To disable synchronization, include the disable statement. To configure the time period
to advertise the maximum cost metric for a link that is not fully operational, include the
hold-time statement.

For a list of hierarchy levels at which you can configure this statement, see the statement
summary section for this statement.

Configuring LDP Synchronization with the IGP on the Router

You can configure the time the LDP waits before informing the IGP that the LDP neighbor
and session for an interface are operational. For large networks with numerous FECs, you
might need to configure a longer value to allow enough time for the LDP label databases
to be exchanged.

To configure the time the LDP waits before informing the IGP that the LDP neighbor and
session are operational, include the igp-synchronization statement and specify a time in
seconds for the holddown-interval option:

igp-synchronization holddown-interval seconds;

For a list of hierarchy levels at which you can configure this statement, see the statement
summary section for this statement.

Configuring the Label Withdrawal Timer

The label withdrawal timer delays sending a label withdrawal message for a FEC to a
neighbor. When an IGP link to a neighbor fails, the label associated with the FEC has to
be withdrawn from all the upstream routers if the neighbor is the next hop for the FEC.
After the IGP converges and a label is received from a new next hop, the label is
readvertised to all the upstream routers. This is the typical network behavior. By delaying
label withdrawal by a small amount of time (for example, until the IGP converges and
the router receives a new label for the FEC from the downstream next hop), the label
withdrawal and sending a label mapping soon could be avoided. The
label-withdrawal-delay statement allows you to configure this delay time. By default,
the delay is 60 seconds.

If the router receives the new label before the timer runs out, the label withdrawal timer
is canceled. However, if the timer runs out, the label for the FEC is withdrawn from all of
the upstream routers.

By default, LDP waits for 60 seconds before withdrawing labels to avoid resignaling LSPs
multiple times while the IGP is reconverging. To configure the label withdrawal delay
time in seconds, include the label-withdrawal-delay statement:

label-withdrawal-delay seconds;

500 Copyright © 2012, Juniper Networks, Inc.

 Chapter 15: LDP Configuration Guidelines

For a list of hierarchy levels at which you can configure this statement, see the statement
summary section for this statement.

Ignoring the LDP Subnet Check

In Junos OS Release 8.4 and later releases, an LDP source address subnet check is
performed during the neighbor establishment procedure. The source address in the LDP
link hello packet is matched against the interface address. This causes an interoperability
issue with some other vendors’ equipment.

To disable the subnet check, include the allow-subnet-mismatch statement:

allow-subnet-mismatch;

This statement can be included at the following hierarchy levels:

• [edit protocols ldp interface interface-name]

• [edit logical-systems logical-system-name protocols ldp interface interface-name]

Copyright © 2012, Juniper Networks, Inc. 501

Junos OS 12.1 MPLS Applications Configuration Guide

502 Copyright © 2012, Juniper Networks, Inc.

CHAPTER 16

Summary of LDP Configuration

Statements

This chapter provides a reference for each LDP configuration statement. The statements
are organized alphabetically.

allow-subnet-mismatch

Syntax allow-subnet-mismatch;

Hierarchy Level [edit logical-systems logical-system-name protocols ldp interface interface-name],

[edit protocols ldp interface interface-name]

Release Information Statement introduced in Junos OS Release 9.3.

Description Ignore the LDP subnet check. For Junos OS Release 8.4 and later releases, an LDP source
address subnet check was added for the neighbor establishment procedure. The source
address in the LDP link hello packet is matched against the interface address.

Default The source address in the LDP link hello packet is matched against the interface address.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Ignoring the LDP Subnet Check on page 501

Documentation

Copyright © 2012, Juniper Networks, Inc. 503

Junos OS 12.1 MPLS Applications Configuration Guide

authentication-key

Syntax authentication-key md5-authentication-key;

Hierarchy Level [edit logical-systems logical-system-name protocols ldp session address],

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols
ldp session address],
[edit protocols ldp session address],
[edit routing-instances routing-instance-name protocols ldp session address]

Release Information Statement introduced before Junos OS Release 7.4.

Description Configure the MD5 authentication signature. The maximum length of the authentication
signature is 69 characters.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring the TCP MD5 Signature for LDP Sessions on page 498
Documentation

504 Copyright © 2012, Juniper Networks, Inc.

 Chapter 16: Summary of LDP Configuration Statements

bfd-liveness-detection

Syntax bfd-liveness-detection {
detection-time threshold milliseconds;
ecmp;
failure-action {
remove-nexthop;
remove-route;
}
holddown-interval seconds;
minimum-interval milliseconds;
minimum-receive-interval milliseconds;
minimum-transmit-interval milliseconds;
multiplier detection-time-multiplier;
no-adaptation;
transmit-interval {
minimum-interval milliseconds;
threshold milliseconds;
}
}

Hierarchy Level [edit logical-systems logical-system-name protocols ldp oam],

[edit logical-systems logical-system-name protocols ldp oam fec address],
[edit protocols ldp oam],
[edit protocols ldp oam fec address]

Release Information Statement introduced in Junos OS Release 7.6.

Support for the bfd-liveness-detection statement at the [edit protocols ldp oam fec
address] hierarchy level and the ecmp option added in Junos OS Release 9.0.
Support for the failure-action statement with the remove-nexthop and remove-route
options and the holddown-interval statement added in Junos OS Release 9.4.

Description Enable Bidirectional Forwarding Detection (BFD) for all MPLS LSPs or for just a specific
LSP.

Options minimum-interval—Minimum transmit and receive interval.

Range: 50 through 255,000 milliseconds
Default: 50

minimum-receive-interval—Minimum receive interval.

Range: 50 through 255,000 milliseconds
Default: 50

minimum-transmit-interval—Minimum transmit interval.

Range: 50 through 255,000 milliseconds
Default: 50

multiplier—Detection time multiplier.

Range: 50 through 255
Default: 3

Copyright © 2012, Juniper Networks, Inc. 505

Junos OS 12.1 MPLS Applications Configuration Guide

The other options are explained separately.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring BFD for LDP LSPs on page 486

Documentation

deaggregate

Syntax deaggregate | no-deaggregate;

Hierarchy Level [edit logical-systems logical-system-name protocols ldp],

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols
ldp],
[edit protocols ldp],
[edit routing-instances routing-instance-name protocols ldp]

Release Information Statement introduced before Junos OS Release 7.4.

Description Control forwarding equivalence class (FEC) deaggregation on the router.

Default Deaggregation is disabled on the router.

Options deaggregate—Deaggregate FECs.

no-deaggregate—Aggregate FECs.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring FEC Deaggregation on page 484

Documentation

506 Copyright © 2012, Juniper Networks, Inc.

 Chapter 16: Summary of LDP Configuration Statements

disable

Syntax disable;

Hierarchy Level [edit logical-systems logical-system-name protocols ldp graceful-restart],

[edit logical-systems logical-system-name protocols ldp interface interface-name],
[edit logical-systems logical-system-name routing-instances routing-instance-name protocols
ldp interface interface-name],
[edit logical-systems logical-system-name routing-instances routing-instance-name
routing-options graceful-restart],
[edit protocols ldp graceful-restart],
[edit protocols ldp interface interface-name],
[edit routing-instances routing-instance-name protocols ldp interface interface-name],
[edit routing-instances routing-instance-name routing-options graceful-restart]

Release Information Statement introduced before Junos OS Release 7.4.

Description Explicitly disable LDP on an interface, or explicitly disable LDP graceful restart.

Default LDP is enabled on interfaces configured with the LDP interface statement. LDP graceful
restart is automatically enabled when graceful restart is enabled under the [edit
routing-options] hierarchy level.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Enabling and Disabling LDP on page 472

Documentation
• Configuring LDP Graceful Restart on page 476

Copyright © 2012, Juniper Networks, Inc. 507

Junos OS 12.1 MPLS Applications Configuration Guide

ecmp

Syntax ecmp;

Hierarchy Level [edit logical-systems logical-system-name protocols ldp oam bfd-liveness-detection],

[edit logical-systems logical-system-name protocols ldp oam fec address
bfd-liveness-detection],
[edit protocols ldp oam bfd-liveness-detection],
[edit protocols ldp oam fec address bfd-liveness-detection]

Release Information Statement introduced in Junos OS Release 8.5.

Description Allows LDP to establish BFD sessions for all ECMP paths configured for the specified
FEC. If you configure the ecmp statement, you must also configure the periodic-traceroute
statement for the specified FEC. If you do not do so, the commit operation fails. You can
configure the periodic-traceroute statement at the global hierarchy level ([edit protocols
ldp oam]) while only configuring the ecmp statement for a specific FEC ([edit protocols
ldp oam fec address bfd-liveness-detection]).

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring ECMP-Aware BFD for LDP LSPs on page 488

Documentation

egress-policy

Syntax egress-policy [ policy-names ];

Hierarchy Level [edit logical-systems logical-system-name protocols ldp],

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols
ldp],
[edit protocols ldp],
[edit routing-instances routing-instance-name protocols ldp]

Release Information Statement introduced before Junos OS Release 7.4.

Description Control the prefixes advertised into LDP.

Default Only the loopback address is advertised.

Options policy-names—Name of one or more routing policies.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring the Prefixes Advertised into LDP from the Routing Table on page 483
Documentation

508 Copyright © 2012, Juniper Networks, Inc.

 Chapter 16: Summary of LDP Configuration Statements

explicit-null

Syntax explicit-null;

Hierarchy Level [edit logical-systems logical-system-name protocols ldp],

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols
ldp],
[edit protocols ldp],
[edit routing-instances routing-instance-name protocols ldp]

Release Information Statement introduced before Junos OS Release 7.4.

Description Advertise label 0 to the egress router of a label-switched path (LSP).

Default If you do not include the explicit-null statement in the MPLS configuration, label 3 (implicit
null) is advertised.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring MPLS and LDP to Pop the Label on the Ultimate-Hop Router on page 496
Documentation

export

Syntax export [ policy-names ];

Hierarchy Level [edit logical-systems logical-system-name protocols ldp],

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols
ldp],
[edit protocols ldp],
[edit routing-instances routing-instance-name protocols ldp]

Release Information Statement introduced before Junos OS Release 7.4.

Description Apply policy filters to outbound LDP label bindings. Filters are applied to all label bindings
from all neighbors.

Options policy-names—Name of one or more routing policies.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Filtering Outbound LDP Label Bindings on page 480

Documentation

Copyright © 2012, Juniper Networks, Inc. 509

Junos OS 12.1 MPLS Applications Configuration Guide

failure-action

Syntax failure-action {
remove-nexthop;
remove-route;
}

Hierarchy Level [edit logical-systems logical-system-name protocols ldp oam bfd-livenesss-detection],

[edit logical-systems logical-system-name protocols ldp oam fec address
bfd-livenesss-detection],
[edit protocols ldp oam bfd-livenesss-detection],
[edit protocols ldp oam fec address bfd-livenesss-detection]

Release Information Statement introduced in Junos OS Release 9.4.

Description Configure route and next-hop properties in the event of a BFD session failure event on
an LDP LSP. The failure event could be an existing BFD session that has gone down or
could be a BFD session that never came up. LDP adds back the route or next hop when
the relevant BFD session comes back up.

Options remove-nexthop—Remove a route corresponding to a next hop of the LSP’s route at the
ingress node when a BFD session failure event is detected.

remove-route—Remove the route corresponding to an LSP from the appropriate routing

tables when a BFD session failure event is detected. If the LSP is configured with
ECMP and a BFD session corresponding to any path goes down, the route is removed.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring a Failure Action for the BFD Session on an LDP LSP on page 488
Documentation

510 Copyright © 2012, Juniper Networks, Inc.

 Chapter 16: Summary of LDP Configuration Statements

graceful-restart

Syntax graceful-restart {
disable;
helper-disable;
maximum-neighbor-recovery-time value;
reconnect-time seconds;
recovery-time value;
}

Hierarchy Level [edit logical-systems logical-system-name protocols ldp],

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols
ldp],
[edit protocols ldp],
[edit routing-instances routing-instance-name protocols ldp]

Release Information Statement introduced before Junos OS Release 7.4.

Description Enable LDP graceful restart on the LDP master protocol instance or for a specific routing
instance.

NOTE: When you alter the graceful restart configuration at either the [edit
routing-options graceful-restart] or [edit protocols ldp graceful-restart] hierarchy
levels, any running LDP session is automatically restarted to apply the graceful
restart configuration. This behavior mirrors the behavior of BGP when you
alter its graceful restart configuration.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring LDP Graceful Restart on page 476

Documentation

Copyright © 2012, Juniper Networks, Inc. 511

Junos OS 12.1 MPLS Applications Configuration Guide

hello-interval

Syntax hello-interval seconds;

Hierarchy Level [edit logical-systems logical-system-name protocols ldp interface interface-name],

[edit logical-systems logical-system-name protocols ldp targeted-hello],
[edit logical-systems logical-system-name routing-instances routing-instance-name protocols
ldp interface interface-name],
[edit logical-systems logical-system-name routing-instances routing-instance-name protocols
ldp targeted-hello],
[edit protocols ldp interface interface-name],
[edit protocols ldp targeted-hello],
[edit routing-instances routing-instance-name protocols ldp interface interface-name],
[edit routing-instances routing-instance-name protocols ldp targeted-hello]

Release Information Statement introduced before Junos OS Release 7.4.

Support for LDP targeted hellos added in Junos OS Release 9.5.

Description Control the LDP timer that regulates how often hello messages are sent. You can control
the rate both link hello messages and targeted hello messages are sent depending on
the hierarchy level at which you configure the hello-interval statement.

Options seconds—Length of time between transmission of hello packets.

Range: 1 through 65,535 seconds
Default: 5 seconds for link hello messages, 15 seconds for targeted hello messages

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring the LDP Timer for Hello Messages on page 472
Documentation

512 Copyright © 2012, Juniper Networks, Inc.

 Chapter 16: Summary of LDP Configuration Statements

helper-disable

Syntax helper-disable;

Hierarchy Level [edit logical-systems logical-system-name protocols ldp graceful-restart],

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols
ldp graceful-restart],
[edit protocols ldp graceful-restart],
[edit routing-instances routing-instance-name protocols ldp graceful-restart]

Release Information Statement introduced before Junos OS Release 7.4.

Description Disable helper mode for LDP graceful restart. When helper mode is disabled, a router
cannot help a neighboring router that is attempting to restart LDP.

Default Helper mode is enabled by default on all routing protocols (including LDP) that support
graceful restart.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring LDP Graceful Restart on page 476

Documentation

holddown-interval

Syntax holddown-interval holddown-interval;

Hierarchy Level [edit logical-systems logical-system-name protocols ldp oam bfd-livenesss-detection],

[edit logical-systems logical-system-name protocols ldp oam fec address
bfd-livenesss-detection],
[edit protocols ldp oam bfd-livenesss-detection],
[edit protocols ldp oam fec address bfd-livenesss-detection]

Release Information Statement introduced in Junos OS Release 9.4.

Description Specify how long the BFD session should be up before adding the route or next hop.
Specifying a time of 0 seconds causes the route or next hop to be added as soon as the
BFD session comes back up.

Options holddown-interval—Number of seconds the BFD session should remain up before adding
the route or next hop.
Default: 0 seconds
Range: 0 through 65,535 seconds

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring the Holddown Interval for the BFD Session on page 489
Documentation

Copyright © 2012, Juniper Networks, Inc. 513

Junos OS 12.1 MPLS Applications Configuration Guide

hold-time (LDP)

Syntax hold-time seconds;

Hierarchy Level [edit logical-systems logical-system-name protocols ldp interface interface-name],

[edit logical-systems logical-system-name protocols ldp targeted-hello],
[edit logical-systems logical-system-name routing-instances routing-instance-name protocols
ldp interface interface-name],
[edit logical-systems logical-system-name routing-instances routing-instance-name protocols
ldp targeted-hello],
[edit protocols ldp interface interface-name],
[edit protocols ldp targeted-hello],
[edit routing-instances routing-instance-name protocols ldp interface interface-name],
[edit routing-instances routing-instance-name protocols ldp targeted-hello]

Release Information Statement introduced before Junos OS Release 7.4.

Support for LDP targeted hellos added in Junos OS Release 9.5.

Description Specify how long an LDP node should wait for a hello message before declaring a neighbor
to be down. This value is sent as part of a hello message so that each LDP node tells its
neighbors how long to wait. You can specify times for both link hello messages and
targeted hello messages depending on the hierarchy level at which you configure the
hold-time statement.

Options seconds—Hold-time value.

Range: 1 through 65,535 seconds
Default: 15 seconds for link hello messages, 45 seconds for targeted hello messages

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring the Delay Before LDP Neighbors Are Considered Down on page 473
Documentation

514 Copyright © 2012, Juniper Networks, Inc.

 Chapter 16: Summary of LDP Configuration Statements

ignore-lsp-metrics

Syntax ignore-lsp-metrics;

Hierarchy Level [edit logical-systems logical-system-name protocols ospf traffic-engineering shortcuts],

[edit protocols ospf traffic-engineering shortcuts]

Release Information Statement introduced in Junos OS Release 7.5.

Description Cause OSPF to ignore the RSVP LSP metric.

Some other vendors use an OSPF metric of 1 for the loopback address. Juniper Networks
routers use an OSPF metric of 0 for the loopback address. This can cause interoperability
problems when you configure LDP tunneling over RSVP LSPs in heterogeneous networks.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Enabling LDP over RSVP-Established LSPs in Heterogeneous Networks on page 497
Documentation

igp-synchronization

Syntax igp-synchronization holddown-interval seconds;

Hierarchy Level [edit logical-systems logical-system-name protocols ldp],

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols
ldp],
[edit protocols ldp],
[edit routing-instances routing-instance-name protocols ldp]

Release Information Statement introduced in Junos OS Release 9.5.

Description Configure the time the LDP waits before informing the IGP that the LDP neighbor and
session for an interface are operational. For large networks with numerous FECs, you
might need to configure a longer value to allow enough time for the LDP label databases
to be exchanged.

Options holddown-interval seconds—Time the LDP waits before informing the IGP that the LDP
neighbor and session for an interface are operational.
Default: 10 seconds
Range: 10 through 60 seconds

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring LDP Synchronization with the IGP on the Router on page 500
Documentation

Copyright © 2012, Juniper Networks, Inc. 515

Junos OS 12.1 MPLS Applications Configuration Guide

import

Syntax import [ policy-names ];

Hierarchy Level [edit logical-systems logical-system-name protocols ldp],

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols
ldp],
[edit protocols ldp],
[edit routing-instances routing-instance-name protocols ldp]

Release Information Statement introduced before Junos OS Release 7.4.

Description Apply policy filters to received LDP label bindings. Filters are applied to all label bindings
from all neighbors.

Options policy-names—Name of one or more routing policies.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Filtering Inbound LDP Label Bindings on page 478

Documentation

ingress-policy

Syntax ingress-policy [ ingress-policy-names ];

Hierarchy Level [edit logical-system logical-system-name protocols ldp oam],

[edit protocols ldp oam]

Release Information Statement introduced in Junos OS Release 9.4.

Description Configure an Operation, Administration, and Management (OAM) policy to choose which
forwarding equivalence classes (FECs) need to have OAM enabled. If the FEC passes
through the policy or if the FEC is explicitly configured, OAM is enabled for a FEC. For
FECs chosen using a policy, the BFD parameters configured under [edit protocols ldp oam
bfd-liveness-detection] are applied.

Options ingress-policy-names—Specify the names of the ingress policies.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring OAM Ingress Policies for LDP on page 489

Documentation

516 Copyright © 2012, Juniper Networks, Inc.

 Chapter 16: Summary of LDP Configuration Statements

interface

Syntax interface interface-name {

disable;
hello-interval seconds;
hold-time seconds;
transport-address (interface | loopback);
}

Hierarchy Level [edit logical-systems logical-system-name protocols ldp],

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols
ldp],
[edit protocols ldp],
[edit routing-instances routing-instance-name protocols ldp]

Release Information Statement introduced before Junos OS Release 7.4.

Description Enable LDP on one or more router interfaces.

Default LDP is disabled on all interfaces.

Options interface-name—Name of an interface. To configure all interfaces, specify all.

The remaining statements are explained separately.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Enabling and Disabling LDP on page 472

Documentation

Copyright © 2012, Juniper Networks, Inc. 517

Junos OS 12.1 MPLS Applications Configuration Guide

keepalive-interval

Syntax keepalive-interval seconds;

Hierarchy Level [edit logical-systems logical-system-name protocols ldp],

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols
ldp],
[edit protocols ldp],
[edit routing-instances routing-instance-name protocols ldp]

Release Information Statement introduced before Junos OS Release 7.4.

Description Set the keepalive interval value.

Options seconds—Keepalive value.

Range: 1 through 65,535
Default: 10 seconds

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring the Interval for LDP Keepalive Messages on page 475
Documentation

keepalive-timeout

Syntax keepalive-timeout seconds;

Hierarchy Level [edit logical-systems logical-system-name protocols ldp],

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols
ldp],
[edit protocols ldp],
[edit routing-instances routing-instance-name protocols ldp]

Release Information Statement introduced before Junos OS Release 7.4.

Description Set the keepalive timeout value. The keepalive timeout defines the amount of time that
the neighbor LDP node waits before determining that the session has failed.

Options seconds—Keepalive timeout value.

Range: 1 through 65,535
Default: 30 seconds

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring the LDP Keepalive Timeout on page 475

Documentation

518 Copyright © 2012, Juniper Networks, Inc.

 Chapter 16: Summary of LDP Configuration Statements

l2-smart-policy

Syntax l2-smart-policy;

Hierarchy Level [edit logical-systems logical-system-name protocols ldp],

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols
ldp],
[edit protocols ldp],
[edit routing-instances routing-instance-name protocols ldp]

Release Information Statement introduced in Junos OS Release 8.4.

Description Prevent LDP from exporting IPv4 FECs over sessions with Layer 2 neighbors only. IPv4
FECs received over such sessions are filtered out.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring LDP IPv4 FEC Filtering on page 485

Documentation

label-withdrawal-delay

Syntax label-withdrawal-delay seconds;

Hierarchy Level [edit logical-systems logical-system-name protocols ldp],

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols
ldp],
[edit protocols ldp],
[edit routing-instances routing-instance-name protocols ldp]

Release Information Statement introduced in Junos OS Release 9.1.

Description Delay the withdrawal of labels to reduce router workload during IGP convergence.

Options seconds—Configure the number of seconds to wait before withdrawing labels for the
LDP LSPs.
Default: 60 seconds
Range: 0 through 300 seconds

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring the Label Withdrawal Timer on page 500

Documentation

Copyright © 2012, Juniper Networks, Inc. 519

Junos OS 12.1 MPLS Applications Configuration Guide

ldp

Syntax ldp { ... }

Hierarchy Level [edit logical-systems logical-system-name protocols],

[edit logical-systems logical-system-name routing-instances routing-instance-name
protocols],
[edit protocols],
[edit routing-instances routing-instance-name protocols]

Release Information Statement introduced before Junos OS Release 7.4.

Statement introduced in Junos OS Release 11.1 for EX Series switches.

Description Enable LDP routing on the router or switch.

You must include the ldp statement in the configuration to enable LDP on the router or
switch.

Default LDP is disabled on the router.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Minimum LDP Configuration on page 472

Documentation
• Enabling and Disabling LDP on page 472

520 Copyright © 2012, Juniper Networks, Inc.

 Chapter 16: Summary of LDP Configuration Statements

ldp-synchronization

Syntax ldp-synchronization {
disable;
hold-time seconds;
}

Hierarchy Level [edit logical-systems logical-system-name protocols ospf interface interface-name],

[edit logical-systems logical-system-name routing-instances routing-instance-name
protocols ospf interface interface-name],
[edit protocols ospf interface interface-name],
[edit routing-instances routing-instance-name protocols ospf interface interface-name]

Release Information Statement introduced in Junos OS Release 7.5.

Description Enable synchronization by advertising the maximum cost metric until LDP is operational
on the link.

Options The other statements are explained separately.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring LDP Synchronization with the IGP on LDP Links on page 499
Documentation

log-updown

Syntax log-updown {
trap disable;
}

Hierarchy Level [edit logical-systems logical-system-name protocols ldp],

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols
ldp],
[edit protocols ldp],
[edit routing-instances routing-instance-name protocols ldp]

Release Information Statement introduced before Junos OS Release 7.4.

Description Disable LDP traps on the router, logical system, or routing instance.

Options trap disable—Disable LDP traps.

Default: LDP traps are enabled on the router.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Disabling SNMP Traps for LDP on page 499

Documentation

Copyright © 2012, Juniper Networks, Inc. 521

Junos OS 12.1 MPLS Applications Configuration Guide

maximum-neighbor-recovery-time

Syntax maximum-neighbor-recovery-time seconds;

Hierarchy Level [edit logical-systems logical-system-name protocols ldp graceful-restart],

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols
ldp graceful-restart],
[edit protocols ldp graceful-restart],
[edit routing-instances routing-instance-name protocols ldp graceful-restart]

Release Information Statement introduced before Junos OS Release 7.4. Statement changed from
maximum-recovery-time to maximum-neighbor-recovery-time in Junos OS Release 9.1.

Description Specify the maximum amount of time to wait before giving up an attempt to gracefully
restart.

Options seconds—Configure the maximum recovery time, in seconds.

Range: 120 through 1800 seconds
Default: 140 seconds

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring Recovery Time and Maximum Recovery Time on page 478
Documentation

no-deaggregate

See deaggregate.

522 Copyright © 2012, Juniper Networks, Inc.

 Chapter 16: Summary of LDP Configuration Statements

no-forwarding

Syntax no-forwarding;

Hierarchy Level [edit logical-systems logical-system-name protocols ldp],

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols
ldp],
[edit protocols ldp],
[edit routing-instances routing-instance-name protocols ldp]

Release Information Statement introduced before Junos OS Release 7.4.

Description Do not add ingress routes to the inet.0 routing table even if traffic-engineering bgp-igp
(configured at the [edit protocols mpls] hierarchy level) is enabled.

Default The no-forwarding statement is disabled. Ingress routes are added to the inet.0 routing
table instead of the inet.3 routing table when traffic-engineering bgp-igp is enabled.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Preventing Addition of Ingress Routes to the inet.0 Routing Table on page 496
Documentation

Copyright © 2012, Juniper Networks, Inc. 523

Junos OS 12.1 MPLS Applications Configuration Guide

oam

Syntax oam {
bfd-liveness-detection {
detection-time threshold milliseconds;
ecmp;
failure-action {
remove-nexthop;
remove-route;
}
holddown-interval milliseconds;
ingress-policy ingress-policy-name;
minimum-interval milliseconds;
minimum-receive-interval milliseconds;
minimum-transmit-interval milliseconds;
multiplier detection-time-multiplier;
no-adaptation;
transmit-interval {
minimum-interval milliseconds;
threshold milliseconds;
}
}
fec fec-address;
ingress-policy ingress-policy-name;
lsp-ping-interval seconds;
periodic-traceroute {
disable;
exp exp-value;
fanout fanout-value;
frequency minutes;
paths number-of-paths;
retries retry-attempts;
source address;
ttl ttl-value;
wait seconds;
}
}

Hierarchy Level [edit logical-systems logical-system-name protocols ldp]

[edit protocols ldp]

Release Information Statement introduced in Junos OS Release 7.6.

lsp-ping-interval option introduced in Junos OS Release 9.4.

Description Configure Operation, Administration, and Maintenance (OAM) and Bidirectional

Forwarding Detection (BFD) protocol for LDP.

Options fec fec-address—Specify the forwarding equivalence class (FEC) address. You must either
specify a FEC address or configure an OAM ingress policy to ensure that the BFD
session comes up.

lsp-ping-interval seconds—Specify the duration of the LSP ping interval in seconds. To

issue a ping on an LDP-signaled LSP, use the ping mpls ldp command.

524 Copyright © 2012, Juniper Networks, Inc.

 Chapter 16: Summary of LDP Configuration Statements

Default: 60 seconds
Range: 30 through 3,600 seconds

The remaining statements are explained separately.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring BFD for LDP LSPs on page 486

Documentation

p2mp

Syntax p2mp;

Hierarchy Level [edit logical-systems logical-system-name protocols ldp],

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols
ldp],
[edit protocols ldp],
[edit routing-instances routing-instance-name protocols ldp]

Release Information Statement introduced in Junos OS Release 11.2.

Description Enable point-to-multipoint MPLS LSPs in an LDP-signaled LSP.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Example: Configuring Point-to-Multipoint LDP LSPs as the Data Plane for Intra-AS
Documentation MBGP MVPNs

• Point-to-Multipoint LSPs Overview on page 52

Copyright © 2012, Juniper Networks, Inc. 525

Junos OS 12.1 MPLS Applications Configuration Guide

periodic-traceroute

Syntax periodic-traceroute {
disable;
exp exp-value;
fanout fanout-value;
frequency minutes;
paths number-of-paths;
retries retry-attempts;
source address;
ttl ttl-value;
wait seconds;
}

Hierarchy Level [edit logical-systems logical-system-name protocols ldp oam],

[edit logical-systems logical-system-name protocols ldp oam fec fec-address],
[edit protocols ldp oam],
[edit protocols ldp oam fec fec-address]

Release Information Statement introduced in Junos OS Release 8.4.

Support added at the [edit protocols ldp oam] and [edit
logical-systems logical-system-name protocols ldp oam] hierarchy levels in Junos OS
Release 9.0.

Description Enable tracing of forwarding equivalence classes (FECs) for LDP LSPs.

Options disable—(Optional) Disable tracing for a specific FEC. This option is available at the [edit
protocols ldp oam fec fec-address periodic-traceroute] and [edit
logical-systems logical-system-name protocols ldp oam fec fec-address
periodic-traceroute] hierarchy levels only.

exp exp-value—(Optional) Specify the class of service to use when sending probes.
Default: 7
Range: 0 through 7

fanout fanout-value—(Optional) Specify the maximum number of next hops to search

per node.
Default: 16
Range: 1 though 16

frequency minutes—(Optional) Specify the interval between traceroute attempts.

Default: 60 minutes
Range: 15 through 120 minutes

paths number-of-paths—(Optional) Specify the maximum number of paths to search.

Default: 3
Range: 1 through 255

retries retry-attempts—(Optional) Specify the number of attempts to send a probe to a

specific node before giving up.

526 Copyright © 2012, Juniper Networks, Inc.

 Chapter 16: Summary of LDP Configuration Statements

Default: 3
Range: 1 through 9

source address—(Optional) Specify the IPv4 source address to use when sending probes.

ttl value—(Optional) Specify the maximum time-to-live value. Nodes that are beyond
this value are not traced.
Default: 64
Range: 1 through 255

wait seconds—(Optional) Specify the wait interval before resending a probe packet.
Default: 10 seconds
Range: 5 though 15 seconds

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring LDP LSP Traceroute on page 490

Documentation

policing

Syntax policing {
fec fec-address {
ingress-traffic filter-name;
transit-traffic filter-name;
}
}

Hierarchy Level [edit logical-systems logical-system-name protocols ldp],

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols
ldp],
[edit protocols ldp],
[edit routing-instances routing-instance-name protocols ldp]

Release Information Statement introduced before Junos OS Release 7.4.

Description Enable policing of forwarding equivalence classes (FECs) for LDP.

Options fec fec-address—Specify the address for the FEC.

ingress-traffic filter-name—Specify the name of the filter for policing ingress FEC traffic.

transit-traffic filter-name—Specify the name of the filter for policing transit FEC traffic.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring Policers for LDP FECs on page 484

Documentation

Copyright © 2012, Juniper Networks, Inc. 527

Junos OS 12.1 MPLS Applications Configuration Guide

preference

Syntax preference preference;

Hierarchy Level [edit logical-systems logical-system-name protocols ldp],

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols
ldp],
[edit protocols ldp interface interface-name],
[edit routing-instances routing-instance-name protocols ldp interface interface-name]

Release Information Statement introduced before Junos OS Release 7.4.

Description Set the route preference level for LDP routes.

Options preference—Preferred value.

Range: 0 through 255
Default: 9

Required Privilege interface—To view this statement in the configuration.

Level interface-control—To add this statement to the configuration.

Related • Configuring LDP Route Preferences on page 476

Documentation

reconnect-time

Syntax reconnect-time seconds;

Hierarchy Level [edit logical-systems logical-system-name protocols ldp graceful-restart],

[edit protocols ldp graceful-restart],
[edit routing-instances routing-instance-name protocols ldp graceful-restart]

Release Information Statement introduced in Junos OS Release 9.1.

Description Specify the length of time required to reestablish a Label Distribution Protocol (LDP)
session after graceful restart.

Options seconds—Time required for reconnection.

Range: 30 through 300
Default: 60 seconds

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring LDP Graceful Restart on page 476 on LDP Configuration Guide
Documentation
• Configuring Graceful Restart Options for LDP

528 Copyright © 2012, Juniper Networks, Inc.

 Chapter 16: Summary of LDP Configuration Statements

recovery-time

Syntax recovery-time seconds;

Hierarchy Level [edit logical-systems logical-system-name protocols ldp graceful-restart],

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols
ldp graceful-restart],
[edit protocols ldp graceful-restart],
[edit routing-instances routing-instance-name protocols ldp graceful-restart]

Release Information Statement introduced before Junos OS Release 7.4.

Description Specify the amount of time a router waits for LDP to restart gracefully.

Options seconds—Configure the recovery time, in seconds.

Range: 120 through 1800 seconds
Default: 140 seconds

Required Privilege interface—To view this statement in the configuration.

Level interface-control—To add this statement to the configuration.

Related • Configuring Recovery Time and Maximum Recovery Time on page 478
Documentation

session

Syntax session address {

authentication-key authentication-key;
}

Hierarchy Level [edit logical-systems logical-system-name protocols ldp],

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols
ldp],
[edit protocols ldp],
[edit routing-instances routing-instance-name protocols ldp]

Release Information Statement introduced before Junos OS Release 7.4.

Description Specify the LDP session to which you want to attach the Transmission Control Protocol
(TCP) MD5 signature. Configure the address for the remote end of the LDP session.

The remaining statement is explained separately.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring the TCP MD5 Signature for LDP Sessions on page 498
Documentation

Copyright © 2012, Juniper Networks, Inc. 529

Junos OS 12.1 MPLS Applications Configuration Guide

session-protection

Syntax session-protection {
timeout seconds;
}

Hierarchy Level [edit logical-systems logical-system-name protocols ldp],

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols
ldp],
[edit protocols ldp],
[edit routing-instances routing-instance-name protocols ldp]

Description Configure when an LDP session is torn down and resignaled after the router stops receiving
hello messages from a neighboring router. You might want to modify this behavior to
prevent an LDP session from being unnecessarily terminated and reestablished. The LDP
session remains up for the duration specified as long as the routers maintain IP network
connectivity.

Options timeout seconds—Time in seconds before the LDP session is torn down and resignaled.
Range: 1 through 65,535 seconds

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring LDP Session Protection on page 499

Documentation

strict-targeted-hellos

Syntax strict-targeted-hellos;

Hierarchy Level [edit logical-systems logical-system-name protocols ldp],

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols
ldp],
[edit protocols ldp],
[edit routing-instances routing-instance-name protocols ldp]

Release Information Statement introduced before Junos OS Release 7.4.

Description Prevent LDP sessions from being established with remote neighbors that have not been
specifically configured. LDP peers will not respond to targeted hellos coming from a
source that is not one of the configured remote neighbors.

Required Privilege interface—To view this statement in the configuration.

Level interface-control—To add this statement to the configuration.

Related • Enabling Strict Targeted Hello Messages for LDP on page 475
Documentation

530 Copyright © 2012, Juniper Networks, Inc.

 Chapter 16: Summary of LDP Configuration Statements

targeted-hello

Syntax targeted-hello {
hello-interval seconds;
hold-time seconds;
}

Hierarchy Level [edit logical-systems logical-system-name protocols ldp],

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols
ldp],
[edit protocols ldp],
[edit routing-instances routing-instance-name protocols ldp]

Release Information Statement introduced in Junos OS Release 9.5.

Description Specify the LDP timer and LDP hold time for targeted hellos.

Options The remaining statements are explained separately.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring the LDP Timer for Hello Messages on page 472
Documentation
• Configuring the Delay Before LDP Neighbors Are Considered Down on page 473

Copyright © 2012, Juniper Networks, Inc. 531

Junos OS 12.1 MPLS Applications Configuration Guide

traceoptions

Syntax traceoptions {
file filename <files number> <size size> <world-readable | no-world-readable>;
flag flag <flag-modifier> <disable>;
}

Hierarchy Level [edit logical-systems logical-system-name protocols ldp],

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols
ldp],
[edit protocols ldp],
[edit routing-instances routing-instance-name protocols ldp]

Release Information Statement introduced before Junos OS Release 7.4.

match-on address option for the filter flag modifier added in Junos OS Release 10.4.

Description LDP protocol-level trace options.

Default The default LDP protocol-level trace options are inherited from the routing protocols
traceoptions statement included at the [edit routing-options] hierarchy level.

Options disable—(Optional) Disable the tracing operation. You can use this option to disable a
single operation when you have defined a broad group of tracing operations, such
as all.

file filename—Name of the file to receive the output of the tracing operation. Enclose the
name within quotation marks. All files are placed in the directory /var/log. We
recommend that you place LDP tracing output in the file ldp-log.

files number—(Optional) Maximum number of trace files. When a trace file named
trace-file reaches its maximum size, it is renamed trace-file.0, then trace-file.1, and
so on, until the maximum number of trace files is reached. Then the oldest trace file
is overwritten.
Range: 2 through 1000
Default: 2 files

If you specify a maximum number of files, you must also include the size statement to
specify the maximum file size.

flag flag—Tracing operation to perform. To specify more than one tracing operation,
include multiple flag statements.

• address—Operation of address and address withdrawal messages

• binding—Label-binding operations

• error—Error conditions

• event—Protocol events

• initialization—Operation of initialization messages

532 Copyright © 2012, Juniper Networks, Inc.

 Chapter 16: Summary of LDP Configuration Statements

• label—Operation of label request, label map, label withdrawal, and label release
messages

• notification—Operation of notification messages

• packets—Equivalent to setting address, initialization, label, notification, and periodic

flags (see also the filter flag modifier)

• path—Label-switched path operations

• periodic—Operation of hello and keepalive messages

• route—Operation of route messages

• state—Protocol state transitions

flag-modifier—(Optional) Modifier for the tracing flag. You can specify one or more of
these modifiers:

• detail—Provide detailed trace information.

• disable—Disable this trace flag.

• filter—Filter to apply to this flag. The filter flag modifier can be applied only to the route,
path, and binding flags. This flag modifier has the following options:

• match-on—Match on argument specified. The match-on option has the following

suboptions:

• address—Filter based on the source and destination addresses of packets. Available

for the packets flag option only.

• fec—Filter based on the FEC associated with the traced object.

• policy policy-name—Specify the filter policy.

• receive—Packets being received.

• send—Packets being transmitted.

no-world-readable—(Optional) Prevent all users from reading the log file.

size size—(Optional) Maximum size of each trace file, in kilobytes (KB), megabytes (MB),
or gigabytes (GB). When a trace file named trace-file reaches this size, it is renamed
trace-file.0. When the trace-file again reaches this size, trace-file.0 is renamed
trace-file.1 and trace-file is renamed trace-file.0. This renaming scheme continues
until the maximum number of trace files is reached. Then the oldest trace file is
overwritten.
Syntax: xk to specify KB, xm to specify MB, or xg to specify GB
Range: 10 KB through the maximum file size supported on your system
Default: 1 MB

If you specify a maximum file size, you must also include the files statement to specify
the maximum number of files.

world-readable—(Optional) Enable any user to read the log file.

Copyright © 2012, Juniper Networks, Inc. 533

Junos OS 12.1 MPLS Applications Configuration Guide

Required Privilege routing and trace—To view this statement in the configuration.
Level routing-control and trace-control—To add this statement to the configuration.

Related • Tracing LDP Protocol Traffic on page 493

Documentation
• Junos OS Network Management Configuration Guide

track-igp-metric

Syntax track-igp-metric;

Hierarchy Level [edit logical-systems logical-system-name protocols ldp],

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols
ldp],
[edit protocols ldp],
[edit routing-instances routing-instance-name protocols ldp]

Release Information Statement introduced before Junos OS Release 7.4.

Description Cause the IGP route metric to be used for the LDP routes instead of the default LDP route
metric (the default LDP route metric is 1).

Required Privilege interface—To view this statement in the configuration.

Level interface-control—To add this statement to the configuration.

Related • Configuring LDP to Use the IGP Route Metric on page 496
Documentation

534 Copyright © 2012, Juniper Networks, Inc.

 Chapter 16: Summary of LDP Configuration Statements

traffic-statistics

Syntax traffic-statistics {
file filename <files number> <size size> <world-readable | no-world-readable>;
interval seconds;
no-penultimate-hop;
}

Hierarchy Level [edit logical-systems logical-system-name protocols ldp],

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols
ldp],
[edit protocols ldp],
[edit routing-instances routing-instance-name protocols ldp]

Release Information Statement introduced before Junos OS Release 7.4.

Description LDP traffic statistics display the amount of traffic passed through a router for a particular
FEC.

Options file filename—Name of the file to receive the output of the LDP statistics operation.
Enclose the name within quotation marks. All files are placed in the directory /var/log.

files number—(Optional) Maximum number of LDP statistics files. When a statistics file
named ldp-stat reaches its maximum size, it is renamed ldp-stat.0, then ldp-stat.1,
and so on, until the maximum number of LDP statistics files is reached. Then the
oldest file is overwritten.
Range: 2 through 1000
Default: 2 files

If you specify a maximum number of files, you also must include the size statement to
specify the maximum file size.

interval seconds—(Optional) Specify the interval at which the statistics are polled and
written to the file.
Default: 300 seconds (5 minutes)

no-penultimate-hop—(Optional) Do not collect traffic statistics on the penultimate hop

router.

no-world-readable—(Optional) Prevent all users from reading the log file.

size size—(Optional) Maximum size of each statistics file, in kilobytes (KB), megabytes
(MB), or gigabytes (GB). When a statistics file named ldp-stat reaches this size, it is
renamed ldp-stat.0. When ldp-stat again reaches this size, ldp-stat.0 is renamed
ldp-stat.1 and ldp-stat is renamed ldp-stat.0. This renaming scheme continues until
the maximum number of statistics files is reached. Then the oldest statistics file is
overwritten.
Syntax: xk to specify KB, xm to specify MB, or xg to specify GB
Range: 10 KB through the maximum file size supported on your system
Default: 1 MB

Copyright © 2012, Juniper Networks, Inc. 535

Junos OS 12.1 MPLS Applications Configuration Guide

If you specify a maximum file size, you also must also include the files statement to
specify the maximum number of files.

world-readable—(Optional) Enable log file access for all users.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Collecting LDP Statistics on page 491

Documentation

transport-address

Syntax transport-address (interface | router-id);

Hierarchy Level [edit logical-systems logical-system-name protocols ldp],

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols
ldp],
[edit protocols ldp interface interface-name],
[edit routing-instances routing-instance-name protocols ldp interface interface-name]

Release Information Statement introduced before Junos OS Release 7.4.

Description Enable control of the transport address used by LDP.

Default router-id

Options interface—The first IP address on the interface is used as the transport address.

router-id—The router identifier is used as the transport address.

Required Privilege interface—To view this statement in the configuration.

Level interface-control—To add this statement to the configuration.

Related • Specifying the Transport Address Used by LDP on page 482

Documentation

536 Copyright © 2012, Juniper Networks, Inc.

PART 5

CCC and TCC

• CCC and TCC Overview on page 539
• CCC and TCC Configuration Guidelines on page 543
• Summary of CCC and TCC Configuration Statements on page 565

Copyright © 2012, Juniper Networks, Inc. 537

Junos OS 12.1 MPLS Applications Configuration Guide

538 Copyright © 2012, Juniper Networks, Inc.

CHAPTER 17

CCC and TCC Overview

This chapter includes the following sections:

• CCC Overview on page 539

• Transmitting Nonstandard BPDUs on page 540
• TCC Overview on page 540
• CCC and TCC Graceful Restart on page 541

CCC Overview

Circuit cross-connect (CCC) allows you to configure transparent connections between

two circuits, where a circuit can be a Frame Relay data-link connection identifier (DLCI),
an Asynchronous Transfer Mode (ATM) virtual circuit (VC), a Point-to-Point Protocol
(PPP) interface, a Cisco High-Level Data Link Control (HDLC) interface, or an MPLS
label-switched path (LSP). Using CCC, packets from the source circuit are delivered to
the destination circuit with, at most, the Layer 2 address being changed. No other
processing—such as header checksums, time-to-live (TTL) decrementing, or protocol
processing—is done.

CCC circuits fall into two categories: logical interfaces, which include DLCIs, VCs, virtual
local area network (VLAN) IDs, PPP and Cisco HDLC interfaces, and LSPs. The two circuit
categories provide three types of cross-connect:

• Layer 2 switching—Cross-connects between logical interfaces provide what is essentially

Layer 2 switching. The interfaces that you connect must be of the same type.

• MPLS tunneling—Cross-connects between interfaces and LSPs allow you to connect

two distant interface circuits of the same type by creating MPLS tunnels that use LSPs
as the conduit.

• LSP stitching—Cross-connects between LSPs provide a way to “stitch” together two

label-switched paths, including paths that fall in two different traffic engineering
database areas.

For Layer 2 switching and MPLS tunneling, the cross-connect is bidirectional, so packets
received on the first interface are transmitted out the second interface, and those received
on the second interface are transmitted out the first. For LSP stitching, the cross-connect
is unidirectional.

Copyright © 2012, Juniper Networks, Inc. 539

Junos OS 12.1 MPLS Applications Configuration Guide

You can police (control) the amount of traffic flowing over CCC circuits. For more
information, see the Junos OS VPNs Configuration Guide.

It is also possible to use the ping command to check the integrity of CCC LSPs. See
“Pinging CCC LSPs” on page 271 for more information.

Transmitting Nonstandard BPDUs

CCC protocol (and Layer 2 Circuit and Layer 2 VPN) configurations can transmit
nonstandard bridge protocol data units (BPDUs) generated by other vendors’ equipment.
This is the default behavior on all supported PICs and requires no additional configuration.

The following PICs are supported on M320 and T Series routers:

• 1-port Gigabit Ethernet PIC

• 2-port Gigabit Ethernet PIC

• 4-port Gigabit Ethernet PIC

• 10-port Gigabit Ethernet PIC

TCC Overview

Translational cross-connect (TCC) is a switching concept that enables you to establish

interconnections between a variety of Layer 2 protocols or circuits. It is similar to CCC.
However, whereas CCC requires the same Layer 2 encapsulations on each side of a Juniper
Networks router (such as PPP-to-PPP or Frame Relay-to-Frame Relay), TCC enables
you to connect different types of Layer 2 protocols interchangeably. When you use TCC,
combinations such as PPP-to-ATM (see Figure 28 on page 540) and Ethernet-to-Frame
Relay connections are possible.

Figure 28: TCC Example

The Layer 2 circuits and encapsulation types that can be interconnected by TCC are:

• Ethernet

• Extended VLANs

• PPP

• HDLC

• ATM

• Frame Relay

TCC works by removing the Layer 2 header when frames enter the router and adding a
different Layer 2 header on the frames before they leave the router. In Figure 28 on page 540,

540 Copyright © 2012, Juniper Networks, Inc.

 Chapter 17: CCC and TCC Overview

the PPP encapsulation is stripped from the frames arriving at Router B, and the ATM
encapsulation is added before the frames are sent to Router C.

Note that all control traffic is terminated at the interconnecting router (Router B).
Examples of traffic controllers include the Link Control Protocol (LCP) and the Network
Control Protocol (NCP) for PPP, keepalives for HDLC, and Local Management Interface
(LMI) for Frame Relay.

TCC functionality is different from standard Layer 2 switching. TCC only swaps Layer 2
headers. No other processing, such as header checksums, TTL decrementing, or protocol
handling is performed. TCC is supported for IPv4 only.

Address Resolution Protocol (APR) packet policing on TCC Ethernet interfaces is effective
for releases 10.4 and onwards.

You can configure TCC for interface switching and for Layer 2 VPNs. For more information
about using TCC for virtual private networks (VPNs), see the Junos OS VPNs Configuration
Guide.

CCC and TCC Graceful Restart

CCC and TCC graceful restart allows Layer 2 connections between customer edge (CE)
routers to restart gracefully. These Layer 2 connections are configured with the
remote-interface-switch or lsp-switch statements. Because these CCC and TCC
connections have an implicit dependency on RSVP LSPs, graceful restart for CCC and
TCC uses the RSVP graceful restart capabilities.

RSVP graceful restart must be enabled on the PE routers and P routers to enable graceful
restart for CCC and TCC. Also, because RSVP is used as the signaling protocol for signaling
label information, the neighboring router must use helper mode to assist with the RSVP
restart procedures.

Figure 29 on page 541 illustrates how graceful restart might work on a CCC connection
between two CE routers.

Figure 29: Remote Interface Switch Connecting Two CE Routers Using

CCC

PE Router A is the ingress for the transmit LSP from PE Router A to PE Router B and the
egress for the receive LSP from PE Router B to PE Router A. With RSVP graceful restart
enabled on all the PE and P routers, the following occurs when PE router A restarts:

Copyright © 2012, Juniper Networks, Inc. 541

Junos OS 12.1 MPLS Applications Configuration Guide

• PE Router A preserves the forwarding state associated with the CCC routes (those
from CCC to MPLS and from MPLS to CCC).

• Traffic flows without disruption from CE router to CE router.

• After the restart, PE Router A preserves the label for the LSP for which PE Router A is
the egress (the receive LSP, for example). The transmit LSP from PE Router A to PE
Router B can derive new label mappings, but should not cause any traffic disruption.

542 Copyright © 2012, Juniper Networks, Inc.

CHAPTER 18

CCC and TCC Configuration Guidelines

This chapter includes the following sections:

• Configuring Layer 2 Switching Cross-Connects Using CCC on page 543

• Configuring MPLS LSP Tunnel Cross-Connects Using CCC on page 551
• Configuring LSP Stitching Cross-Connects Using CCC on page 555
• Configuring TCC on page 556
• Configuring CCC and TCC Graceful Restart on page 562
• Configuring CCC Switching for Point-to-Multipoint LSPs on page 562

Configuring Layer 2 Switching Cross-Connects Using CCC

Layer 2 switching cross-connects join logical interfaces to form what is essentially Layer 2
switching. The interfaces that you connect must be of the same type.

Figure 30 on page 543 illustrates a Layer 2 switching cross-connect. In this topology,

Router A and Router C have Frame Relay connections to Router B, which is a Juniper
Networks router. Circuit cross-connect (CCC) allows you to configure Router B to act as
a Frame Relay (Layer 2) switch.

To configure Router B to act as a Frame Relay switch, you configure a circuit from Router A
to Router C that passes through Router B, effectively configuring Router B as a Frame
Relay switch with respect to these routers. This configuration allows Router B to
transparently switch packets (frames) between Router A and Router C without regard
to the packets’ contents or the Layer 3 protocols. The only processing that Router B
performs is to translate DLCI 600 to 750.

Figure 30: Layer 2 Switching Cross-Connect

If the Router A–to–Router B and Router B–to–Router C circuits were PPP, for example,
the Link Control Protocol and Network Control Protocol exchanges occur between
Router A and Router C. These messages are handled transparently by Router B, allowing
Router A and Router C to use various PPP options (such as header or address compression

Copyright © 2012, Juniper Networks, Inc. 543

Junos OS 12.1 MPLS Applications Configuration Guide

and authentication) that Router B might not support. Similarly, Router A and Router C
exchange keepalives, providing circuit-to-circuit connectivity status.

You can configure Layer 2 switching cross-connects on PPP, Cisco HDLC, Frame Relay,
Ethernet, and ATM circuits. In a single cross-connect, only like interfaces can be connected.

To configure Layer 2 switching cross-connects, you must configure the following on the
router that is acting as the switch (Router B in Figure 30 on page 543):

• Configuring the CCC Encapsulation for Layer 2 Switching Cross-Connects on page 544
• Configuring the CCC Connection for Layer 2 Switching Cross-Connects on page 548
• Configuring MPLS for Layer 2 Switching Cross-Connects on page 549
• Example: Configuring a Layer 2 Switching Cross-Connect on page 549

Configuring the CCC Encapsulation for Layer 2 Switching Cross-Connects

To configure Layer 2 switching cross-connects, configure the CCC encapsulation on the
router that is acting as the switch (Router B in Figure 30 on page 543).

NOTE: You cannot configure families on CCC interfaces; that is, you cannot
include the family statement at the [edit interfaces interface-name unit
logical-unit-number] hierarchy level.

For instructions for configuring the encapsulation for Layer 2 switching cross-connects,
see the following sections:

• Configuring ATM Encapsulation for Layer 2 Switching Cross-Connects on page 544

• Configuring Ethernet Encapsulation for Layer 2 Switching Cross-Connects on page 545
• Configuring Ethernet VLAN Encapsulation for Layer 2 Switching
Cross-Connects on page 545
• Configuring Aggregated Ethernet Encapsulation for Layer 2 Switching
Cross-Connects on page 546
• Configuring Frame Relay Encapsulation for Layer 2 Switching
Cross-Connects on page 547
• Configuring PPP and Cisco HDLC Encapsulation for Layer 2 Switching
Cross-Connects on page 548

Configuring ATM Encapsulation for Layer 2 Switching Cross-Connects

For ATM circuits, specify the encapsulation when configuring the virtual circuit (VC).
Configure each VC as a circuit or a regular logical interface by including the following
statements:

at-fpc/pic/port {
atm-options {
vpi vpi-identifier maximum-vcs maximum-vcs;
}
unit logical-unit-number {

544 Copyright © 2012, Juniper Networks, Inc.

 Chapter 18: CCC and TCC Configuration Guidelines

point-to-point; # Default interface type

encapsulation encapsulation-type;
vci vpi-identifier.vci-identifier;
}
}

You can include these statements at the following hierarchy levels:

• [edit interfaces]

• [edit logical-systems logical-system-name interfaces]

Configuring Ethernet Encapsulation for Layer 2 Switching Cross-Connects

For Ethernet circuits, specify ethernet-ccc in the encapsulation statement. This statement
configures the entire physical device. For these circuits to work, you must also configure
a logical interface (unit 0).

Ethernet interfaces with standard Tag Protocol Identifier (TPID) tagging can use
Ethernet CCC encapsulation. On M Series Multiservice Edge Routers, except the M320,
one-port Gigabit Ethernet, two-port Gigabit Ethernet, four-port Gigabit Ethernet, and
four-port Fast Ethernet PICs can use Ethernet CCC encapsulation. On T Series Core
Routers and M320 routers, one-port Gigabit Ethernet and two-port Gigabit Ethernet PICs
installed in FPC2 can use Ethernet CCC encapsulation. When you use this encapsulation
type, you can configure the ccc family only.

fe-fpc/pic/port {
encapsulation ethernet-ccc;
unit 0;
}

You can include these statements at the following hierarchy levels:

• [edit interfaces]

• [edit logical-systems logical-system-name interfaces]

Configuring Ethernet VLAN Encapsulation for Layer 2 Switching Cross-Connects

An Ethernet virtual LAN (VLAN) circuit can be configured using either the vlan-ccc or
extended-vlan-ccc encapsulation. If you configure the extended-vlan-ccc encapsulation
on the physical interface, you cannot configure the inet family on the logical interfaces.
Only the ccc family is allowed. If you configure the vlan-ccc encapsulation on the physical
interface, both the inet and ccc families are supported on the logical interfaces. Ethernet
interfaces in VLAN mode can have multiple logical interfaces.

For encapsulation type vlan-ccc, VLAN IDs from 512 through 4094 are reserved for CCC
VLANs. For the extended-vlan-ccc encapsulation type, all VLAN IDs 1 and higher are valid.
VLAN ID 0 is reserved for tagging the priority of frames.

Copyright © 2012, Juniper Networks, Inc. 545

Junos OS 12.1 MPLS Applications Configuration Guide

NOTE: Some vendors use the proprietary TPIDs 0x9100 and 0x9901 to
encapsulate a VLAN-tagged packet into a VLAN-CCC tunnel to interconnect
a geographically separated metro Ethernet network. By configuring the
extended-vlan-ccc encapsulation type, a Juniper Networks router can accept
all three TPIDs (0x8100, 0x9100, and 0x9901).

Configure an Ethernet VLAN circuit with the vlan-ccc encapsulation as follows:

interfaces {
type-fpc/pic/port {
vlan-tagging;
encapsulation vlan-ccc;
unit logical-unit-number {
encapsulation vlan-ccc;
vlan-id vlan-id;
}
}
}

You can configure these statements at the following hierarchy levels:

• [edit interfaces]

• [edit logical-systems logical-system-name interfaces]

Configure an Ethernet VLAN circuit with the extended-vlan-ccc encapsulation statement

as follows:

interfaces {
type-fpc/pic/port {
vlan-tagging;
encapsulation extended-vlan-ccc;
unit logical-unit-number {
vlan-id vlan-id;
family ccc;
}
}
}

You can configure these statements at the following hierarchy levels:

• [edit interfaces]

• [edit logical-systems logical-system-name interfaces]

Whether you configure the encapsulation as vlan-ccc or extended-vlan-ccc, you must

enable VLAN tagging by including the vlan-tagging statement.

Configuring Aggregated Ethernet Encapsulation for Layer 2 Switching

Cross-Connects

You can configure aggregated Ethernet interfaces for CCC connections and for Layer 2
virtual private networks (VPNs).

546 Copyright © 2012, Juniper Networks, Inc.

 Chapter 18: CCC and TCC Configuration Guidelines

Aggregated Ethernet interfaces configured with VLAN tagging can be configured with
multiple logical interfaces. The only encapsulation available for aggregated Ethernet
logical interfaces is vlan-ccc. When you configure the vlan-id statement, you are limited
to VLAN IDs 512 through 4094.

Aggregated Ethernet interfaces configured without VLAN tagging can be configured only
with the ethernet-ccc encapsulation. All untagged Ethernet packets received are forwarded
based on the CCC parameters.

To configure aggregated Ethernet interfaces for CCC connections, include the ae0
statement at the [edit interfaces] hierarchy level:

[edit interfaces]
ae0 {
encapsulation (ethernet-ccc | extended-vlan-ccc | vlan-ccc);
vlan-tagging;
aggregated-ether-options {
minimum-links links;
link-speed speed;
}
unit logical-unit-number {
encapsulation vlan-ccc;
vlan-id identifier;
family ccc;
}
}

Be aware of the following limitations when configuring CCC connections over aggregated
Ethernet interfaces:

• If you configured load balancing between child links, be aware that a different hash
key is used to distribute packets among the child links. Standard aggregated interfaces
have family inet configured. An IP version 4 (IPv4) hash key (based on the Layer 3
information) is used to distribute packets among the child links. A CCC connection
over an aggregated Ethernet interface has family ccc configured instead. Instead of
an IPv4 hash key, an MPLS hash key (based on the destination media access control
[MAC] address) is used to distributed packets among the child links.

• The extended-vlan-ccc encapsulation is not supported on the 12-port Fast Ethernet

PIC and the 48-port Fast Ethernet PIC.

• The Junos OS does not support the Link Aggregation Control Protocol (LACP) when
an aggregated interface is configured as a VLAN (with vlan-ccc encapsulation). LACP
can be configured only when the aggregated interface is configured with the
ethernet-ccc encapsulation.

For more information about how to configure aggregated Ethernet interfaces, see the
Junos OS Network Interfaces Configuration Guide.

Configuring Frame Relay Encapsulation for Layer 2 Switching Cross-Connects

For Frame Relay circuits, specify the encapsulation when configuring the DLCI. Configure
each DLCI as a circuit or a regular logical interface. The DLCI for regular interfaces must
be from 1 through 511. For CCC interfaces, it must be from 512 through 4094.

Copyright © 2012, Juniper Networks, Inc. 547

Junos OS 12.1 MPLS Applications Configuration Guide

interfaces {
type-fpc/pic/port {
unit logical-unit-number {
point-to-point; # Default interface type
encapsulation encapsulation-type;
dlci dlci-identifier;
}
}
}

You can configure these statements at the following hierarchy levels:

• [edit interfaces]

• [edit logical-systems logical-system-name interfaces]

Configuring PPP and Cisco HDLC Encapsulation for Layer 2 Switching

Cross-Connects

For PPP and Cisco HDLC circuits, specify the encapsulation in the encapsulation statement.
This statement configures the entire physical device. For these circuits to work, you must
configure a logical interface (unit 0).

interfaces type-fpc/pic/port {
encapsulation encapsulation-type;
unit 0;
}

You can configure these statements at the following hierarchy levels:

• [edit interfaces type-fpc/pic/port]

• [edit logical-systems logical-system-name interfaces type-fpc/pic/port]

Configuring the CCC Connection for Layer 2 Switching Cross-Connects

To configure Layer 2 switching cross-connects, define the connection between the two
circuits by including the interface-switch statement. You configure this connection on
the router that is acting as the switch (Router B in Figure 30 on page 543). The connection
joins the interface that comes from the circuit’s source to the interface that leads to the
circuit’s destination. When you specify the interface names, include the logical portion
of the name, which corresponds to the logical unit number. The cross-connect is
bidirectional, so packets received on the first interface are transmitted out the second
interface, and those received on the second interface are transmitted out the first.

interface-switch connection-name {
interface interface-name.unit-number;
interface interface-name.unit-number;
}

You can include this statement at the following hierarchy levels:

• [edit protocols connections]

• [edit logical-systems logical-system-name protocols connections]

548 Copyright © 2012, Juniper Networks, Inc.

 Chapter 18: CCC and TCC Configuration Guidelines

Configuring MPLS for Layer 2 Switching Cross-Connects

For Layer 2 switching cross-connects to work, you must enable MPLS on the router by
including at least the following statements. This minimum configuration enables MPLS
on a logical interface for the switching cross-connect.

Include the family mpls statement:

family mpls;

You can configure this statement at the following hierarchy levels:

• [edit interfaces interface-name unit logical-unit-number]

• [edit logical-systems logical-system-name interfaces interface-name unit

logical-unit-number]

You can then specify this logical interface in the MPLS protocol configuration:

mpls {
interface interface-name; # Required to enable MPLS on the interface
}

You can configure these statements at the following hierarchy levels:

• [edit protocols]

• [edit logical-systems logical-system-name protocols]

Example: Configuring a Layer 2 Switching Cross-Connect

Configure a full-duplex Layer 2 switching cross-connect between Router A and Router C,
using a Juniper Networks router, Router B, as the virtual switch. See the topology in Figure
31 on page 549 and Figure 32 on page 550.

Figure 31: Topology of a Frame Relay Layer 2 Switching Cross-Connect

[edit]
interfaces {
so-1/0/0 {
encapsulation frame-relay-ccc;
unit 1 {
point-to-point;
encapsulation frame-relay-ccc;
dlci 600;
}
}
so-2/0/0 {
encapsulation frame-relay-ccc;
unit 2 {

Copyright © 2012, Juniper Networks, Inc. 549

Junos OS 12.1 MPLS Applications Configuration Guide

point-to-point;
encapsulation frame-relay-ccc;
dlci 750;
}
}
}
protocols {
connections {
interface-switch router-a-to-router-c {
interface so-1/0/0.1;
interface so-2/0/0.2;
}
}
mpls {
interface all;
}
}

Figure 32: Sample Topology of a VLAN Layer 2 Switching Cross-Connect

[edit]
interfaces {
ge-2/1/0 {
vlan-tagging;
encapsulation vlan-ccc;
unit 0 {
encapsulation vlan-ccc;
vlan-id 600;
}
}
ge-2/2/0 {
vlan-tagging;
encapsulation vlan-ccc;
unit 0 {
encapsulation vlan-ccc;
vlan-id 600;
}
unit 1 {
family inet {
vlan-id 1;
address 10.9.200.1/24;
}
}
}
}
protocols {
mpls {
interface all;
}
connections {

550 Copyright © 2012, Juniper Networks, Inc.

 Chapter 18: CCC and TCC Configuration Guidelines

interface-switch layer2-sw {
interface ge-2/1/0.0;
interface ge-2/2/0.0;
}
}
}

Configuring MPLS LSP Tunnel Cross-Connects Using CCC

MPLS tunnel cross-connects between interfaces and LSPs allow you to connect two
distant interface circuits of the same type by creating MPLS tunnels that use LSPs as
the conduit. The topology in Figure 33 on page 551 illustrates an MPLS LSP tunnel
cross-connect. In this topology, two separate networks, in this case ATM access networks,
are connected through an IP backbone. CCC allows you to establish an LSP tunnel
between the two domains. With LSP tunneling, you tunnel the ATM traffic from one
network across a SONET backbone to the second network by using an MPLS LSP.

Figure 33: MPLS Tunnel Cross-Connect

ATM access network IP Backbone ATM access network

Juniper LSP Juniper

ATM ATM
A Networks Networks D

g017093
VC 234 router B routerC VC 591

When traffic from Router A (VC 234) reaches Router B, it is encapsulated and placed
into an LSP, which is sent through the backbone to Router C. At Router C, the label is
removed, and the packets are placed onto the ATM permanent virtual circuit (PVC) (VC
591) and sent to Router D. Similarly, traffic from Router D (VC 591) is sent over an LSP
to Router B, then placed on VC 234 to Router A.

You can configure LSP tunnel cross-connect on PPP, Cisco HDLC, Frame Relay, and ATM
circuits. In a single cross-connect, only like interfaces can be connected.

When you use MPLS tunnel cross-connects to support IS-IS, you must ensure that the
LSP’s maximum transmission unit (MTU) can, at a minimum, accommodate a 1492-octet
IS-IS protocol data unit (PDU) in addition to the link-level overhead associated with the
technology being connected.

For the tunnel cross-connects to work, the IS-IS frame size on the edge routers (Routers
A and D in Figure 34 on page 554) must be smaller than the LSP’s MTU.

NOTE: Frame size values do not include the frame check sequence (FCS) or
delimiting flags.

To determine the LSP MTU required to support IS-IS, use the following calculation:

IS-IS MTU (minimum 1492, default 1497) + frame overhead + 4 (MPLS shim header) =
Minimum LSP MTU

Copyright © 2012, Juniper Networks, Inc. 551

Junos OS 12.1 MPLS Applications Configuration Guide

The framing overhead varies based on the encapsulation being used. The following lists
the IS-IS encapsulation overhead values for various encapsulations:

• ATM

• AAL5 multiplex—8 bytes (RFC 1483)

• VC multiplex—0 bytes

• Frame Relay

• Multiprotocol—2 bytes (RFCs 1490 and 2427)

• VC multiplex—0 bytes

• HDLC—4 bytes

• PPP—4 bytes

• VLAN—21 bytes (802.3/LLC)

For IS-IS to work over VLAN-CCC, the LSP’s MTU must be at least 1513 bytes (or 1518 for
1497-byte PDUs). If you increase the size of a Fast Ethernet MTU above the default of
1500 bytes, you might need to explicitly configure jumbo frames on intervening equipment.

To modify the MTU, include the mtu statement when configuring the logical interface
family at the [edit interfaces interface-name unit logical-unit-number encapsulation family]
hierarchy level. For more information about setting the MTU, see the Junos OS Network
Interfaces Configuration Guide.

To configure an LSP tunnel cross-connect, you must configure the following on the
interdomain router (Router B in Figure 34 on page 554):

• Configuring the CCC Encapsulation for LSP Tunnel Cross-Connects on page 552
• Configuring the CCC Connection for LSP Tunnel Cross-Connects on page 553
• Example: Configuring an LSP Tunnel Cross-Connect on page 554

Configuring the CCC Encapsulation for LSP Tunnel Cross-Connects

To configure LSP tunnel cross-connects, you must configure the CCC encapsulation on
the ingress and egress routers (Router B and Router C, respectively, in Figure 34 on
page 554).

NOTE: You cannot configure families on CCC interfaces; that is, you cannot
include the family statement at the [edit interfaces interface-name unit
logical-unit-number] hierarchy level.

For PPP or Cisco HDLC circuits, include the encapsulation statement to configure the
entire physical device. For these circuits to work, you must configure logical unit 0 on the
interface.

type-fpc/pic/port {
encapsulation (ppp-ccc | cisco-hdlc-ccc);

552 Copyright © 2012, Juniper Networks, Inc.

 Chapter 18: CCC and TCC Configuration Guidelines

unit 0;
}

You can include these statements at the following hierarchy levels:

• [edit interfaces]

• [edit logical-systems logical-system-name interfaces]

For ATM circuits, specify the encapsulation when configuring the VC by including the
following statements. For each VC, you configure whether it is a circuit or a regular logical
interface.

at-fpc/pic/port {
atm-options {
vpi vpi-identifier maximum-vcs maximum-vcs;
}
unit logical-unit-number {
point-to-point; # Default interface type
encapsulation atm-ccc-vc-mux;
vci vpi-identifier.vci-identifier;
}
}

You can include these statements at the following hierarchy levels:

• [edit interfaces]

• [edit logical-systems logical-system-name interfaces]

For Frame Relay circuits, include the following statements to specify the encapsulation
when configuring the DLCI. For each DLCI, you configure whether it is a circuit or a regular
logical interface. The DLCI for regular interfaces must be in the range 1 through 511. For
CCC interfaces, it must be in the range 512 through 1022.

type-fpc/pic/port {
encapsulation frame-relay-ccc;
unit logical-unit-number {
point-to-point; # default interface type
encapsulation frame-relay-ccc;
dlci dlci-identifier;
}
}

You can include these statements at the following hierarchy levels:

• [edit interfaces]

• [edit logical-systems logical-system-name interfaces]

For more information about the encapsulation statement, see the Junos OS Network
Interfaces Configuration Guide.

Configuring the CCC Connection for LSP Tunnel Cross-Connects

To configure LSP tunnel cross-connects, include the remote-interface-switch statement
to define the connection between the two circuits on the ingress and egress routers

Copyright © 2012, Juniper Networks, Inc. 553

Junos OS 12.1 MPLS Applications Configuration Guide

(Router B and Router C, respectively, in Figure 34 on page 554). The connection joins the
interface or LSP that comes from the circuit’s source to the interface or LSP that leads
to the circuit’s destination. When you specify the interface name, include the logical
portion of the name, which corresponds to the logical unit number. For the cross-connect
to be bidirectional, you must configure cross-connects on two routers.

remote-interface-switch connection-name {
interface interface-name.unit-number;
transmit-lsp label-switched-path;
receive-lsp label-switched-path;
}

You can include these statements at the following hierarchy levels:

• [edit protocols connections]

• [edit logical-systems logical-system-name protocols connections]

Example: Configuring an LSP Tunnel Cross-Connect

Configure a full-duplex MPLS LSP tunnel cross-connect from Router A to Router D,
passing through Router B and Router C. See the topology in Figure 34 on page 554.

Figure 34: Example Topology of MPLS LSP Tunnel Cross-Connect

On Router B:

[edit]
interfaces {
at-7/1/1 {
atm-options {
vpi 1 maximum-vcs 600;
}
unit 1 {
point-to-point; # default interface type
encapsulation atm-ccc-vc-mux;
vci 1.234;
}
}
}
protocols {
connections {
remote-interface-switch router-b-to-router-c {
interface at-7/1/1.1;
transmit-lsp lsp1;
receive-lsp lsp2;
}
}
}

554 Copyright © 2012, Juniper Networks, Inc.

 Chapter 18: CCC and TCC Configuration Guidelines

On Router C:

[edit]
interfaces {
at-3/0/0 {
atm-options {
vpi 2 maximum-vcs 600;
}
unit 2 {
point-to-point; # default interface type
encapsulation atm-ccc-vc-mux;
vci 2.591;
}
}
}
protocols {
connections {
remote-interface-switch router-b-to-router-c {
interface at-3/0/0.2;
transmit-lsp lsp2;
receive-lsp lsp1;
}
}
}

Configuring LSP Stitching Cross-Connects Using CCC

LSP stitching cross-connects “stitch” together LSPs to join two LSPs. For example, they
stitch together LSPs that fall in two different traffic engineering database areas. The
topology in Figure 35 on page 555 illustrates an LSP stitching cross-connect. In this
topology, the network is divided into two traffic engineering domains. CCC allows you to
establish an LSP between the two domains by stitching together LSPs from the two
domains. For LSP stitching to work, the LSPs must be dynamic LSPs, not static.

Figure 35: LSP Stitching Cross-Connect

Without LSP stitching, a packet traveling from Router A to Router C is encapsulated on

Router A (the ingress router for the first LSP), de-encapsulated on Router B (the egress
router), and then reencapsulated on Router B (the ingress router for the second LSP).
With LSP stitching, you connect LSP1 and LSP2 into a single, stitched LSP, which means
that the packet is encapsulated once (on Router A) and de-encapsulated once (on
Router C).

You can use LSP stitching to create a seamless LSP for LSPs carrying any kind of traffic.

To configure LSP stitching cross-connects, configure the two LSPs that you are stitching
together on the two ingress routers. Then on the interdomain router (Router B in Figure

Copyright © 2012, Juniper Networks, Inc. 555

Junos OS 12.1 MPLS Applications Configuration Guide

35 on page 555), you define the connection between the two LSPs. The connection joins
the LSP that comes from the connection’s source to the LSP that leads to the connection’s
destination.

protocols {
connections {
lsp-switch connection-name {
transmit-lsp label-switched-path;
receive-lsp label-switched-path;
}
}
}

You can configure these statements at the following hierarchy levels:

• [edit protocols connections]

• [edit logical-systems logical-system-name protocols connections]

Example: Configuring an LSP Stitching Cross-Connect

Configure a full-duplex LSP stitching cross-connect between Router A and Router C. To
do this, you configure Router B, which is the interdomain router. See the topology in Figure
36 on page 556.

Figure 36: Example Topology of LSP Stitching Cross-Connect

[edit]
protocols {
connections interface-switch {
lsp-switch router-a-to-router-c {
transmit-lsp lsp2;
receive-lsp lsp1;
}
}
connections {
lsp-switch router-c-to-router-a {
receive-lsp lsp3;
transmit-lsp lsp4;
}
}
}

Configuring TCC

This section describes how to configure translational cross-connect (TCC). Extensive

examples on how to configure TCC for interface switching and for Layer 2.5 VPNs are
available in the Junos OS Feature Guides.

556 Copyright © 2012, Juniper Networks, Inc.

 Chapter 18: CCC and TCC Configuration Guidelines

To configure TCC, you must perform the following tasks on the router that is acting as
the switch:

• Configuring the Encapsulation for Layer 2 Switching TCCs on page 557

• Configuring the Connection for Layer 2 Switching TCCs on page 560
• Configuring MPLS for Layer 2 Switching TCCs on page 561

Configuring the Encapsulation for Layer 2 Switching TCCs

To configure a Layer 2 switching TCC, specify the TCC encapsulation on the desired
interfaces of the router that is acting as the switch.

NOTE: You cannot configure standard protocol families on TCC or CCC

interfaces. Only the CCC family is allowed on CCC interfaces, and only the
TCC family is allowed on TCC interfaces.

For Ethernet circuits and Ethernet extended VLAN circuits, you must also
configure the Address Resolution Protocol (ARP). See “Configuring ARP for
Ethernet and Ethernet Extended VLAN Encapsulations” on page 560.

• Configuring PPP and Cisco HDLC Encapsulation for Layer 2 Switching TCCs on page 557
• Configuring ATM Encapsulation for Layer 2 Switching TCCs on page 558
• Configuring Frame Relay Encapsulation for Layer 2 Switching TCCs on page 558
• Configuring Ethernet Encapsulation for Layer 2 Switching TCCs on page 558
• Configuring Ethernet Extended VLAN Encapsulation for Layer 2 Switching
TCCs on page 559
• Configuring ARP for Ethernet and Ethernet Extended VLAN Encapsulations on page 560

Configuring PPP and Cisco HDLC Encapsulation for Layer 2 Switching TCCs
For PPP and Cisco HDLC circuits, configure the encapsulation type for the entire physical
device by specifying the appropriate value for the encapsulation statement. For these
circuits to work, you must also configure the logical interface unit 0.

encapsulation (ppp-tcc | cisco-hdlc-tcc);

unit 0;
}

You can include these statements at the following hierarchy levels:

• [edit interfaces interface-name]

• [edit logical-systems logical-system-name interfaces interface-name]

Copyright © 2012, Juniper Networks, Inc. 557

Junos OS 12.1 MPLS Applications Configuration Guide

Configuring ATM Encapsulation for Layer 2 Switching TCCs

For ATM circuits, configure the encapsulation type by specifying the appropriate value
for the encapsulation statement in the virtual circuit (VC) configuration. Specify whether
each VC is a circuit or a regular logical interface.

atm-options {
vpi vpi-identifier maximum-vcs maximum-vcs;
}
unit logical-unit-number {
encapsulation (atm-tcc-vc-mux | atm-tcc-snap);
point-to-point;
vci vpi-identifier.vci-identifier;
}

You can include these statements at the following hierarchy levels:

• [edit interfaces at-fpc/pic/port]

• [edit logical-systems logical-system-name interfaces at-fpc/pic/port]

Configuring Frame Relay Encapsulation for Layer 2 Switching TCCs

For Frame Relay circuits, configure the encapsulation type by specifying the value
frame-relay-tcc for the encapsulation statement when configuring the data-link connection
identifier (DLCI). You configure each DLCI as a circuit or a regular logical interface. The
DLCI for regular interfaces must be in the range from 1 through 511, but for TCC and CCC
interfaces it must be in the range from 512 through 1022.

encapsulation frame-relay-tcc;
unit logical-unit-number {
point-to-point;
encapsulation frame-relay-tcc;
dlci dlci-identifier;
}

You can include these statements at the following hierarchy levels:

• [edit interfaces interface-name]

• [edit logical-systems logical-system-name interfaces interface-name]

Configuring Ethernet Encapsulation for Layer 2 Switching TCCs

For Ethernet TCC circuits, configuring the encapsulation type for the entire physical device
by specifying the value ethernet-tcc for the encapsulation statement.

You must also specify static values for a remote address and a proxy address at the [edit
interfaces interface-name unit unit-number family tcc] or [edit logical-systems
logical-system-name interfaces interface-name unit unit-number family tcc] hierarchy level.

The remote address is associated with the TCC switching router’s Ethernet neighbor; in
the remote statement you must specify both the IP address and the media access control
(MAC) address of the Ethernet neighbor. The proxy address is associated with the TCC

558 Copyright © 2012, Juniper Networks, Inc.

 Chapter 18: CCC and TCC Configuration Guidelines

router’s other neighbor connected by the unlike link; in the proxy statement you must
specify the IP address of the non-Ethernet neighbor.

You can configure Ethernet TCC encapsulation for the interfaces on 1-port Gigabit
Ethernet, 2-port Gigabit Ethernet, 4-port Fast Ethernet, and 4-port Gigabit Ethernet PICs.

encapsulation ethernet-tcc;
unit logical-unit-number {
family tcc {
proxy {
inet-address ip-address;
}
remote {
inet-address ip-address;
mac-address mac-address;
}
}
}

You can include these statements at the following hierarchy levels:

• [edit interfaces (fe | ge)-fpc/pic/port]

• [edit logical-systems logical-system-name interfaces (fe | ge)-fpc/pic/port]

NOTE: For Ethernet circuits, you must also configure the Address Resolution
Protocol (ARP). See “Configuring ARP for Ethernet and Ethernet Extended
VLAN Encapsulations” on page 560.

Configuring Ethernet Extended VLAN Encapsulation for Layer 2 Switching TCCs

For Ethernet extended VLAN circuits, configure the encapsulation type for the entire
physical device by specifying the value extended-vlan-tcc for the encapsulation statement.

You must also enable VLAN tagging. Ethernet interfaces in VLAN mode can have multiple
logical interfaces. With encapsulation type extended-vlan-tcc, all VLAN IDs from 0 through
4094 are valid, up to a maximum of 1024 VLANs. As with Ethernet circuits, you must also
specify a proxy address and a remote address at the [edit interfaces interface-name unit
logical-unit-number family tcc] or [edit logical-systems logical-system-name interfaces
interface-name unit unit-number family tcc] hierarchy level (see “Configuring Ethernet
Encapsulation for Layer 2 Switching TCCs” on page 558).

encapsulation extended-vlan-tcc;
vlan-tagging;
unit logical-unit-number {
vlan-id identifier;
family tcc;
proxy {
inet-address ip-address;
}
remote {
inet-address ip-address;
mac-address mac-address;

Copyright © 2012, Juniper Networks, Inc. 559

Junos OS 12.1 MPLS Applications Configuration Guide

}
}

You can configure these statements at the following hierarchy levels:

• [edit interfaces interface-name]

• [edit logical-systems logical-system-name interfaces interface-name]

NOTE: For Ethernet extended VLAN circuits, you must also configure the
Address Resolution Protocol (ARP). See “Configuring ARP for Ethernet and
Ethernet Extended VLAN Encapsulations” on page 560.

Configuring ARP for Ethernet and Ethernet Extended VLAN Encapsulations

For Ethernet and Ethernet extended VLAN circuits with TCC encapsulation, you must
also configure ARP. Because TCC simply removes one Layer 2 header and adds another,
the default form of dynamic ARP is not supported; you must configure static ARP.

Because remote and proxy addresses are specified on the router performing TCC
switching, you must apply the static ARP statement to the Ethernet-type interfaces of
the routers that connect to the TCC-switched router. The arp statement must specify
the IP address and the MAC address of the remotely connected neighbor by use of the
unlike Layer 2 protocol on the far side of the TCC switching router.

arp ip-address mac mac-address;

You can include this statement at the following hierarchy levels:

• [edit interfaces interface-name unit logical-unit-number family inet address ip-address]

• [edit logical-systems logical-system-name interfaces interface-name unit

logical-unit-number family inet address ip-address]

Configuring the Connection for Layer 2 Switching TCCs

You must configure the connection between the two circuits of the Layer 2 switching
TCC on the router acting as the switch. The connection joins the interface coming from
the circuit’s source to the interface leading to the circuit’s destination. When you specify
the interface names, include the logical portion of the name, which corresponds to the
logical unit number. The cross-connect is bidirectional, so packets received on the first
interface are transmitted from the second interface, and those received on the second
interface are transmitted from the first.

To configure a connection for a local interface switch, include the following statements:

interface-switch connection-name {
interface interface-name.unit-number;
}
lsp-switch connection-name {
transmit-lsp lsp-number;
receive-lsp lsp-number;
}

560 Copyright © 2012, Juniper Networks, Inc.

 Chapter 18: CCC and TCC Configuration Guidelines

You can include these statements at the following hierarchy levels:

• [edit protocols connections]

• [edit logical-systems logical-system-name protocols connections]

To configure a connection for a remote interface switch, include the following statements:

remote-interface-switch connection-name {
interface interface-name.unit-number;
interface interface-name.unit-number;
transmit-lsp lsp-number;
receive-lsp lsp-number;
}

You can include these statements at the following hierarchy levels:

• [edit protocols connections]

• [edit logical-systems logical-system-name protocols connections]

Configuring MPLS for Layer 2 Switching TCCs

For a Layer 2 switching TCC to work, you must enable MPLS on the router by including
at least the following statements. This minimum configuration enables MPLS on a logical
interface for the switching cross-connect.

Include the family mpls statement:

family mpls;

You can configure this statement at the following hierarchy levels:

• [edit interfaces interface-name unit logical-unit-number]

• [edit logical-systems logical-system-name interfaces interface-name unit

logical-unit-number]

You can then specify this logical interface in the MPLS protocol configuration:

mpls {
interface interface-name; # Required to enable MPLS on the interface
}

You can configure these statements at the following hierarchy levels:

• [edit protocols]

• [edit logical-systems logical-system-name protocols]

NOTE: MPLS LSP link protection does not support TCC.

Copyright © 2012, Juniper Networks, Inc. 561

Junos OS 12.1 MPLS Applications Configuration Guide

Configuring CCC and TCC Graceful Restart

To enable CCC and TCC graceful restart, include the graceful-restart statement:

graceful-restart;

You can include this statement at the following hierarchy levels:

• [edit routing-options]

• [edit logical-systems logical-system-name routing-options]

The graceful-restart statement enables graceful restart for all protocols supporting this
feature on the router. For more information about graceful restart, see the Junos OS
Routing Protocols Configuration Guide.

CCC and TCC graceful restart depend on RSVP graceful restart. If you disable RSVP
graceful restart, CCC and TCC graceful restart will not work. For more information about
RSVP graceful restart, see “RSVP Graceful Restart” on page 388 and “Configuring RSVP
Graceful Restart” on page 412.

Configuring CCC Switching for Point-to-Multipoint LSPs

You can configure CCC to switch traffic from interfaces to point-to-multipoint LSPs. This
feature is useful for handling multicast or broadcast traffic (for example, a digital video
stream).

To configure CCC switching for point-to-multipoint LSPs, you do the following:

• On the ingress provider edge (PE) router, you configure CCC to switch traffic from an
incoming interface to a point-to-multipoint LSP.

• On the egress PE, you configure CCC to switch traffic from an incoming
point-to-multipoint LSP to an outgoing interface.

The CCC connection for point-to-multipoint LSPs is unidirectional.

For more information on point-to-multipoint LSPs, see “Point-to-Multipoint LSPs

Overview” on page 52.

To configure a CCC connection for a point-to-multipoint LSP, complete the steps in the
following sections:

• Configuring the Point-to-Multipoint LSP Switch on Ingress PE Routers on page 562

• Configuring the Point-to-Multipoint LSP Switch on Egress PE Routers on page 563

Configuring the Point-to-Multipoint LSP Switch on Ingress PE Routers

To configure the ingress PE router with a CCC switch for a point-to-multipoint LSP, include
the p2mp-transmit-switch statement:

p2mp-transmit-switch switch-name {
input-interface input-interface-name.unit-number;

562 Copyright © 2012, Juniper Networks, Inc.

 Chapter 18: CCC and TCC Configuration Guidelines

transmit-p2mp-lsp transmitting-lsp;
}

You can include the p2mp-transmit-switch statement at the following hierarchy levels:

• [edit protocols connections]

• [edit logical-systems logical-system-name protocols connections]

switch-name specifies the name of the ingress CCC switch.

input-interface input-interface-name.unit-number specifies the name of the ingress

interface.

transmit-p2mp-lsp transmitting-lsp specifies the name of the transmitting

point-to-multipoint LSP.

Configuring the Point-to-Multipoint LSP Switch on Egress PE Routers

To configure the CCC switch for a point-to-multipoint LSP on the egress PE router, include
the p2mp-receive-switch statement.

p2mp-receive-switch switch-name {
output-interface [ output-interface-name.unit-number ];
receive-p2mp-lsp receptive-lsp;
}

You can include this statement at the following hierarchy levels:

• [edit protocols connections]

• [edit logical-systems logical-system-name protocols connections]

switch-name specifies the name of the egress CCC switch.

output-interface [ output-interface-name.unit-number ] specifies the name or one or more

egress interfaces.

receive-p2mp-lsp receptive-lsp specifies the name of the receptive point-to-multipoint

LSP.

Copyright © 2012, Juniper Networks, Inc. 563

Junos OS 12.1 MPLS Applications Configuration Guide

564 Copyright © 2012, Juniper Networks, Inc.

CHAPTER 19

Summary of CCC and TCC Configuration

Statements

This chapter provides a reference for each circuit cross-connect (CCC) configuration
statement. The statements are organized alphabetically.

Copyright © 2012, Juniper Networks, Inc. 565

Junos OS 12.1 MPLS Applications Configuration Guide

connections

Syntax connections {
interface-switch connection-name {
interface interface-name.unit-number;
}
lsp-switch connection-name {
transmit-lsp label-switched-path;
receive-lsp label-switched-path;
}
p2mp-receive-switch {
output-interface [ interface-name.unit-number ];
receive-p2mp-lsp receiving-point-to-multipoint-lsp;
}
p2mp-transmit-switch {
input-interface interface-name.unit-number;
transmit-p2mp-lsp transmitting-point-to-multipoint-lsp;
}
remote-interface-switch connection-name {
interface interface-name.unit-number;
receive-lsp label-switched-path;
transmit-lsp label-switched-path;
}
}

Hierarchy Level [edit logical-systems logical-system-name protocols],

[edit protocols]

Release Information Statement introduced before Junos OS Release 7.4.

Description Define the connection between two circuits in a CCC connection.

Options The statements are explained separately.

NOTE: The edit logical-systems hierarchy is not available on QFabric switches.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring Layer 2 Switching Cross-Connects Using CCC on page 543

Documentation
• Configuring MPLS LSP Tunnel Cross-Connects Using CCC on page 551

• Configuring LSP Stitching Cross-Connects Using CCC on page 555

• Configuring TCC on page 556

• Configuring CCC Switching for Point-to-Multipoint LSPs on page 562

566 Copyright © 2012, Juniper Networks, Inc.

 Chapter 19: Summary of CCC and TCC Configuration Statements

encapsulation

See the following sections:

• encapsulation (Logical Interface) on page 568

• encapsulation (Physical Interface) on page 570

Copyright © 2012, Juniper Networks, Inc. 567

Junos OS 12.1 MPLS Applications Configuration Guide

encapsulation (Logical Interface)

Syntax encapsulation (atm-ccc-cell-relay | atm-ccc-vc-mux | atm-tcc-vc-mux | atm-cisco-nlpid |
tm-mlppp-llc | atm-nlpid | atm-ppp-llc | atm-ppp-vc-mux | atm-snap | atm-tcc-snap |
atm-vc-mux | ether-over-atm-llc | ether-vpls-over-atm-llc | frame-relay-ccc |
frame-relay-ppp | frame-relay-tcc | gre-fragmentation | multilink-frame-relay-end-to-end |
multilink-ppp | vlan-ccc | vlan-ccc | vlan-vpls);

Hierarchy Level [edit interfaces interface-name unit logical-unit-number],

[edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number]

Release Information Statement introduced before Junos OS Release 7.4.

Description Logical link-layer encapsulation type.

Options atm-ccc-cell-relay—Use ATM cell-relay encapsulation.

atm-ccc-vc-mux—Use ATM VC multiplex encapsulation on circuit cross-connect (CCC)

circuits. When you use this encapsulation type, you can configure the family ccc only.

atm-cisco-nlpid—Use Cisco ATM NLPID encapsulation. When you use this encapsulation
type, you can configure the family inet only.

atm-mlppp-llc—For ATM2 IQ interfaces only, use Multilink PPP over ATM adaptation
layer 5 (AAL5) logical link control (LLC). For this encapsulation type, your router
must be equipped with a Link Services PIC.

atm-nlpid—Use ATM NLPID encapsulation. When you use this encapsulation type, you
can configure the family inet only.

atm-ppp-llc—For ATM2 IQ interfaces only, use PPP over ATM adaptation layer 5 (AAL5)
logical link control (LLC) encapsulation.

atm-ppp-vc-mux—For ATM2 IQ interfaces only, use PPP over ATM adaptation layer 5
(AAL5) multiplex encapsulation.

atm-snap—Use ATM SNAP encapsulation.

atm-tcc-snap—Use ATM SNAP encapsulation on translational cross-connect (TCC)

circuits.

atm-tcc-vc-mux—Use ATM VC multiplex encapsulation on translational cross-connect

(TCC) circuits. When you use this encapsulation type, you can configure the family
tcc only.

atm-vc-mux—Use ATM VC multiplex encapsulation. When you use this encapsulation

type, you can configure the family inet only.

ether-over-atm-llc—For interfaces that carry IPv4 traffic, use Ethernet over ATM LLC
encapsulation. When you use this encapsulation type, you cannot configure multipoint
interfaces.

568 Copyright © 2012, Juniper Networks, Inc.

 Chapter 19: Summary of CCC and TCC Configuration Statements

ether-vpls-over-atm-llc—For ATM intelligent queuing interfaces only, use the Ethernet

VPLS over ATM LLC encapsulation to bridge Ethernet interfaces and ATM interfaces
over a VPLS routing instance (as described in RFC 2684). Packets from the ATM
interfaces are converted to standard ENET2/802.3 encapsulated Ethernet frames
with the FCS field removed.

frame-relay-ccc—Use Frame Relay encapsulation on CCC circuits. When you use this
encapsulation type, you can configure the family ccc only.

frame-relay-ppp—Use Frame Relay encapsulation on PPP circuits.

frame-relay-tcc—Use Frame Relay encapsulation on TCC circuits for connecting unlike

media. When you use this encapsulation type, you can configure the family tcc only.

gre-fragmentation—For adaptive services interfaces only, use GRE fragmentation

encapsulation to enable fragmentation of IPv4 packets in GRE tunnels. This
encapsulation clears the don’t fragment (DF) bit in the packet header. If the packet’s
size exceeds the tunnel’s maximum transmission unit (MTU) value, the packet is
fragmented before encapsulation.

multilink-frame-relay-end-to-end—Use Multilink Frame Relay (MLFR) FRF.15

encapsulation. This encapsulation is used only on multilink and link services interfaces
and their constituent T1 or E1 interfaces.

multilink-ppp—Use Multilink Point-to-Point Protocol (MLPPP) encapsulation. This

encapsulation is used only on multilink and link services interfaces and their
constituent T1 or E1 interfaces.

vlan-ccc—Use Ethernet virtual local area network (VLAN) encapsulation on CCC circuits.
When you use this encapsulation type, you can configure the family ccc only.

vlan-tcc—Use Ethernet VLAN encapsulation on TCC circuits. When you use this
encapsulation type, you can configure the family tcc only.

vlan-vpls—Use Ethernet VLAN encapsulation on virtual private LAN service (VPLS)

circuits.

Required Privilege interface—To view this statement in the configuration.

Level interface-control—To add this statement to the configuration.

Related • Configuring the CCC Encapsulation for Layer 2 Switching Cross-Connects on page 544
Documentation
• Configuring the CCC Encapsulation for LSP Tunnel Cross-Connects on page 552

• Configuring the Encapsulation for Layer 2 Switching TCCs on page 557

• Junos OS Network Interfaces Configuration Guide

Copyright © 2012, Juniper Networks, Inc. 569

Junos OS 12.1 MPLS Applications Configuration Guide

encapsulation (Physical Interface)

Syntax encapsulation (atm-ccc-cell-relay | atm-pvc | cisco-hdlc | cisco-hdlc-ccc | cisco-hdlc-tcc |
ethernet-ccc | ethernet-over-atm | ethernet-tcc | ethernet-vpls | extended-frame-relay-ccc |
extended-frame-relay-tcc | extended-vlan-ccc | extended-vlan-tcc | extended-vlan-vpls |
flexible-ethernet-services | flexible-frame-relay | frame-relay | frame-relay-ccc |
frame-relay-tcc | frame-relay-port-ccc | multilink-frame-relay-uni-nni | ppp | ppp-ccc |
ppp-tcc | vlan-ccc | vlan-vpls);

Hierarchy Level [edit interfaces interface-name]

Release Information Statement introduced before Junos OS Release 7.4.

Description Physical link-layer encapsulation type.

Default PPP encapsulation.

Options atm-ccc-cell-relay—Use ATM cell-relay encapsulation.

atm-pvc—Use ATM PVC encapsulation.

cisco-hdlc—Use Cisco-compatible HDLC framing.

cisco-hdlc-ccc—Use Cisco-compatible HDLC framing on CCC circuits.

cisco-hdlc-tcc—Use Cisco-compatible HDLC framing on TCC circuits for connecting unlike

media.

ethernet-ccc—Use Ethernet CCC encapsulation on Ethernet interfaces that must accept

packets carrying standard TPID values.

ethernet-over-atm—As defined in RFC 1483, this encapsulation type allows ATM interfaces
to connect to devices that support only bridged-mode protocol data units (PDUs).
The Junos OS does not completely support bridging, but accepts BPDU packets as
a default gateway. If you use the router as an edge device, then the router acts as a
default gateway. It accepts Ethernet LLC/SNAP frames with IP or ARP in the payload
and drops the rest. For packets destined the Ethernet LAN, a route lookup is done
by use of the destination IP address. If the route lookup yields a full address match,
the packet is encapsulated with an LLC/SNAP and MAC header, and the packet is
forwarded to the ATM interface.

ethernet-tcc—For interfaces that carry IPv4 traffic, use Ethernet TCC encapsulation on
interfaces that must accept packets carrying standard Tag Protocol Identifier (TPID)
values. Ethernet TCC is not currently supported on Fast Ethernet 48-port PICs.

ethernet-vpls—Use Ethernet VPLS encapsulation on Ethernet interfaces that have VPLS

enabled and that must accept packets carrying standard TPID values.

extended-frame-relay-ccc—Use Frame Relay encapsulation on CCC circuits. This

encapsulation type allows you to dedicate DLCIs 1 through 1022 to CCC.

570 Copyright © 2012, Juniper Networks, Inc.

 Chapter 19: Summary of CCC and TCC Configuration Statements

extended-frame-relay-tcc—Use Frame Relay encapsulation on TCC circuits to connect

unlike media. This encapsulation type allows you to dedicate DLCIs 1 through 1022
to TCC.

extended-vlan-ccc—Use extended VLAN encapsulation on CCC circuits with Gigabit

Ethernet and 4-port Fast Ethernet interfaces that must accept packets carrying
802.1Q values.

extended-vlan-tcc—For interfaces that carry IPv4 traffic, use extended VLAN encapsulation
on TCC circuits with Gigabit Ethernet interfaces on which you want to use 802.1Q
tagging. Extended Ethernet TCC is not currently supported on Fast Ethernet 48-port
PICs.

extended-vlan-vpls—Use extended VLAN VPLS encapsulation on Ethernet interfaces

that have VLAN 802.1Q tagging and VPLS enabled and that must accept packets
carrying TPIDs 0x8100, 0x9100, and 0x9901.

flexible-ethernet-services—For Gigabit Ethernet intelligent queuing interfaces only, use

flexible Ethernet services encapsulation when you want to configure multiple per-unit
Ethernet encapsulations. This encapsulation type allows you to configure any
combination of routed, TCC, CCC, and VPLS encapsulations on a single physical
port.

flexible-frame-relay—For intelligent queuing interfaces only, use flexible Frame Relay

encapsulation when you want to configure multiple per-unit Frame Relay
encapsulations. This encapsulation type allows you to configure any combination
of TCC, CCC, or standard Frame Relay encapsulations on a single physical port. Also,
each logical interface can have any DLCI value in the range 1 through 1022.

frame-relay—Use Frame Relay encapsulation.

frame-relay-ccc—Use plain Frame Relay encapsulation or Frame Relay encapsulation

on circuit cross-connect (CCC) circuits.

frame-relay-port-ccc—Use Frame Relay port CCC encapsulation to transparently carry

all the DLCIs between two CE routers without explicitly configuring each DLCI on the
two PE routers with Frame Relay transport. When you use this encapsulation type,
you can configure the family ccc only.

frame-relay-tcc—Use Frame Relay encapsulation on TCC circuits to connect unlike media.

multilink-frame-relay-uni-nni—Use MLFR user-to-network (UNI) network-to-network

(NNI) encapsulation. This encapsulation is used only on link services interfaces
functioning as FRF.16 bundles and their constituent T1 or E1 interfaces.

ppp—Use serial PPP encapsulation.

ppp-ccc—Use serial PPP encapsulation on CCC circuits. When you use this encapsulation
type, you can configure the family ccc only.

ppp-tcc—Use serial PPP encapsulation on TCC circuits for connecting unlike media. When
you use this encapsulation type, you can configure the family tcc only.

Copyright © 2012, Juniper Networks, Inc. 571

Junos OS 12.1 MPLS Applications Configuration Guide

vlan-ccc—Use Ethernet VLAN encapsulation on CCC circuits.

vlan-vpls—Use VLAN VPLS encapsulation on Ethernet interfaces with VLAN tagging and
VPLS enabled. Interfaces with VLAN VPLS encapsulation accept packets carrying
standard TPID values only.

Required Privilege interface—To view this statement in the configuration.

Level interface-control—To add this statement to the configuration.

Related • Configuring the CCC Encapsulation for Layer 2 Switching Cross-Connects on page 544
Documentation
• Configuring the CCC Encapsulation for LSP Tunnel Cross-Connects on page 552

• Configuring the Encapsulation for Layer 2 Switching TCCs on page 557

• Junos OS Network Interfaces Configuration Guide

interface-switch

Syntax interface-switch connection-name {

interface interface-name.unit-number;
}

Hierarchy Level [edit logical-systems logical-system-name protocols connections],

[edit protocols connections]

Release Information Statement introduced before Junos OS Release 7.4.

Description Configure Layer 2 switching cross-connects. The cross-connect is bidirectional, so packets

received on the first interface are transmitted out the second interface, and those received
on the second interface are transmitted out the first.

For Layer 2 switching cross-connects to work, you must also configure MPLS.

Options connection-name—Connection name.

interface interface-name.unit-number—Interface name. Include the logical portion of the

name, which corresponds to the logical unit number.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration

Related • Configuring the CCC Connection for Layer 2 Switching Cross-Connects on page 548
Documentation

572 Copyright © 2012, Juniper Networks, Inc.

 Chapter 19: Summary of CCC and TCC Configuration Statements

lsp-switch

Syntax lsp-switch connection-name {

transmit-lsp label-switched-path;
receive-lsp label-switched-path;
}

Hierarchy Level [edit logical-systems logical-system-name protocols connections],

[edit protocols connections]

Release Information Statement introduced before Junos OS Release 7.4.

Description Configure Layer 2 switching cross-connects.

Options connection-name—Connection name.

receive-lsp label-switched-path—Name of the LSP from the connection’s source.

transmit-lsp label-switched-path—Name of the LSP to the connection’s destination.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring LSP Stitching Cross-Connects Using CCC on page 555

Documentation
• Configuring the Connection for Layer 2 Switching TCCs on page 560

Copyright © 2012, Juniper Networks, Inc. 573

Junos OS 12.1 MPLS Applications Configuration Guide

p2mp-receive-switch

Syntax p2mp-receive-switch point-to-multipoint-switch-name {

output-interface [ interface-name.unit-number ];
receive-p2mp-lsp receiving-point-to-multipoint-lsp;
}

Hierarchy Level [edit logical-systems logical-system-name protocols connections],

[edit protocols connections]

Release Information Statement introduced before Junos OS Release 7.4.

Description Configure the CCC switch for a point-to-multipoint LSP on the egress PE router.

Options point-to-multipoint-switch-name—Point-to-multipoint CCC receive switch name.

output-interface interface-name.unit-number—Name of the egress interfaces for the

point-to-multipoint LSP traffic. You can configure multiple output interfaces.

receive-p2mp-lsp receiving-point-to-multipoint-lsp—Name of the point-to-multipoint LSP

that is switched to the output interface.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring the Point-to-Multipoint LSP Switch on Egress PE Routers on page 563
Documentation

574 Copyright © 2012, Juniper Networks, Inc.

 Chapter 19: Summary of CCC and TCC Configuration Statements

p2mp-transmit-switch

Syntax p2mp-transmit-switch point-to-multipoint-transmit-switch-name {

input-interface interface-name.unit-number;
transmit-p2mp-lsp transmitting-point-to-multipoint-lsp;
}

Hierarchy Level [edit logical-systems logical-system-name protocols connections],

[edit protocols connections]

Release Information Statement introduced before Junos OS Release 7.4.

Description Configure the CCC switch for the point-to-multipoint LSP on the ingress PE router.

Options point-to-multipoint-transmit-switch-name—Point-to-multipoint CCC transmit switch

name.

input-interface input-interface-name.unit-number—Specify the name of the interface

carrying incoming traffic to be switched to the point-to-multipoint LSP.

transmit-p2mp-lsp transmitting-point-to-multipoint-lsp—Specify the name of the

point-to-multipoint LSP carrying traffic to the CCC switch on the egress PE router.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring the Point-to-Multipoint LSP Switch on Ingress PE Routers on page 562
Documentation

Copyright © 2012, Juniper Networks, Inc. 575

Junos OS 12.1 MPLS Applications Configuration Guide

remote-interface-switch

Syntax remote-interface-switch connection-name {

interface interface-name.unit-number;
transmit-lsp label-switched-path;
receive-lsp label-switched-path;
}

Hierarchy Level [edit logical-systems logical-system-name protocols connections],

[edit protocols connections]

Release Information Statement introduced before Junos OS Release 7.4.

Description Configure MPLS LSP tunnel cross-connects.

Options connection-name—Connection name.

interface interface-name.unit-number—Interface name. Include the logical portion of the

name, which corresponds to the logical unit number.

receive-lsp label-switched-path—Name of the LSP from the connection’s source.

transmit-lsp label-switched-path—Name of the LSP to the connection’s destination.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring MPLS LSP Tunnel Cross-Connects Using CCC on page 551
Documentation

576 Copyright © 2012, Juniper Networks, Inc.

PART 6

GMPLS
• GMPLS Overview on page 579
• GMPLS Configuration Guidelines on page 585
• Hierarchy of RSVP LSPs Configuration Guidelines on page 601
• Summary of GMPLS Configuration Statements on page 607

Copyright © 2012, Juniper Networks, Inc. 577

Junos OS 12.1 MPLS Applications Configuration Guide

578 Copyright © 2012, Juniper Networks, Inc.

CHAPTER 20

GMPLS Overview

This chapter includes the following topics:

• Supported GMPLS Standards on page 579

• GMPLS Terms and Acronyms on page 580
• Introduction to GMPLS on page 581
• GMPLS Operation on page 582
• GMPLS and OSPF on page 583
• GMPLS and CSPF on page 583
• GMPLS Features on page 584

Supported GMPLS Standards

The Junos OS substantially supports the following RFCs and Internet drafts, which define
standards for Generalized MPLS (GMPLS).

• RFC 3471, Generalized Multi-Protocol [sic] Label Switching (GMPLS) Signaling Functional
Description

Only the following features are supported:

• Bidirectional LSPs (upstream label only)

• Control channel separation

• Generalized label (suggested label only)

• Generalized label request (bandwidth encoding only)

• RFC 3473, Generalized Multi-Protocol [sic] Label Switching (GMPLS) Signaling Resource
ReserVation [sic] Protocol-Traffic Engineering (RSVP-TE) Extensions

Only Section 9, “Fault Handling,” is supported.

• RFC 4206, Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol [sic]
Label Switching (GMPLS) Traffic Engineering (TE)

• Internet draft draft-ietf-ccamp-gmpls-routing-09.txt, Routing Extensions in Support

of Generalized Multi-Protocol [sic] Label Switching

Only interface switching is supported.

Copyright © 2012, Juniper Networks, Inc. 579

Junos OS 12.1 MPLS Applications Configuration Guide

• Internet draft draft-ietf-ccamp-gmpls-rsvp-te-ason-02.txt, Generalized MPLS (GMPLS)

RSVP-TE Signalling in support of Automatically Switched Optical Network (ASON)
(expires January 2005)

• Internet draft draft-ietf-ccamp-gmpls-sonet-sdh-08.txt, Generalized Multi-Protocol

[sic] Label Switching Extensions for SONET and SDH Control

Only S,U,K,L,M-format labels and SONET traffic parameters are supported.

• Internet draft draft-ietf-ccamp-lmp-10.txt, Link Management Protocol (LMP)

• Internet draft draft-ietf-ccamp-ospf-gmpls-extensions-12.txt, OSPF Extensions in

Support of Generalized Multi-Protocol [sic] Label Switching

The following sub-TLV types for the Link type, link, value (TLV) are not supported:

• Link Local/Remote Identifiers (type 11)

• Link Protection Type (type 14)

• Shared Risk Link Group (SRLG) (type 16)

The features described in Section 2 of the draft, “Implications on Graceful Restart,”

are also not supported.

The Interface Switching Capability Descriptor (type 15) sub-TLV type is implemented,
but only for packet switching.

• Internet draft draft-ietf-mpls-bundle-04.txt, Link Bundling in MPLS Traffic Engineering

Related • Supported LDP Standards on page 464

Documentation
• Supported MPLS Standards on page 24

• Supported RSVP Standards on page 376

• Accessing Standards Documents on the Internet

GMPLS Terms and Acronyms

F
Forwarding adjacency A forwarding path for sending data between GMPLS-enabled devices.

G
Generalized MPLS An extension to MPLS that allows data from multiple layers to be switched over label-switched
(GMPLS) paths (LSPs). GMPLS LSP connections are possible between similar Layer 1, Layer 2, and
Layer 3 devices.

GMPLS label Layer 3 identifiers, fiber port, time-division multiplexing (TDM) time slot, or dense
wavelength-division multiplexing (DWDM) wavelength of a GMPLS-enabled device used as
a next-hop identifier.

580 Copyright © 2012, Juniper Networks, Inc.

 Chapter 20: GMPLS Overview

GMPLS LSP types The four types of GMPLS LSPs are:

• Fiber-switched capable (FSC)—LSPs are switched between two fiber-based devices, such
optical cross-connects (OXCs) that operate at the level of individual fibers.

• Lambda-switched capable (LSC)—LSPs are switched between two DWDM devices, such
as such as OXCs that operate at the level of individual wavelengths.

• TDM-switched capable (TDM)—LSPs are switched between two TDM devices, such as
SONET ADMs.

• Packet-switched capable (PSC)—LSPs are switched between two packet-based devices,

such as routers or ATM switches.

L
Link Management A protocol used to define a forwarding adjacency between peers and to maintain and allocate
Protocol resources on the traffic engineering links.

T
Traffic engineering link A logical connection between GMPLS-enabled devices. Traffic engineering links can have
addresses or IDs and are associated with certain resources or interfaces. They also have certain
attributes (encoding-type, switching capability, bandwidth, and so on). The logical addresses
can be routable, although this is not required because they are acting as link identifiers. Each
traffic engineering link represents a forwarding adjacency between a pair of devices.

Introduction to GMPLS

Traditional MPLS is designed to carry Layer 3 IP traffic using established IP-based paths
and associating these paths with arbitrarily assigned labels. These labels can be
configured explicitly by a network administrator, or can be dynamically assigned by means
of a protocol such as LDP or RSVP.

GMPLS generalizes MPLS in that it defines labels for switching varying types of Layer 1,
Layer 2, or Layer 3 traffic. GMPLS nodes can have links with one or more of the following
switching capabilities:

• Fiber-switched capable (FSC)

• Lambda-switched capable (LSC)

• Time-division multiplexing (TDM) switched-capable (TSC)

• Packet-switched capable (PSC)

Label-switched paths (LSPs) must start and end on links with the same switching
capability. For example, routers can establish packet-switched LSPs with other routers.
The LSPs might be carried over a TDM-switched LSP between SONET add/drop
multiplexers (ADMs), which in turn might be carried over a lambda-switched LSP.

The result of this extension of the MPLS protocol is an expansion in the number of devices
that can participate in label switching. Lower-layer devices, such as OXCs and SONET

Copyright © 2012, Juniper Networks, Inc. 581

Junos OS 12.1 MPLS Applications Configuration Guide

ADMs, can now participate in GMPLS signaling and set up paths to transfer data. A router
can participate in signaling optical paths across a transport network.

Two service models determine the visibility that a client node (a router, for example) has
into the optical core or transport network. The first is through a user-to-network interface
(UNI), which is often referred to as the overlay model. The second is known as the peer
model. Juniper Networks supports both models.

NOTE: There is not necessarily a one-to-one correspondence between a

physical interface and a GMPLS interface. If a GMPLS connection uses a
nonchannelized physical connector, the GMPLS label can use the physical
port ID. However, the label for channelized interfaces often is based on a
channel or time slot. Consequently, it is best to refer to GMPLS labels as
identifiers for a resource on a traffic engineering link.

To establish LSPs, GMPLS uses the following mechanisms:

• An out-of-band control channel and a data channel—RSVP messages for LSP setup
are sent over an out-of-band control network. Once the LSP setup is complete and
the path is provisioned, the data channel is up and can be used to carry traffic. The
Link Management Protocol (LMP) is used to define and manage the data channels
between a pair of nodes. You can optionally use LMP to establish and maintain LMP
control channels between peers running the same Junos OS Release.

• RSVP-TE extensions for GMPLS—RSVP-TE is already designed to signal the setup of

packet LSPs. This has been extended for GMPLS to be able to request path setup for
various kinds of LSPs (nonpacket) and request labels like wavelengths, time slots, and
fibers as label objects.

• Bidirectional LSPs—Data can travel both ways between GMPLS devices over a single
path, so nonpacket LSPs are signaled to be bidirectional.

GMPLS Operation

The basic functionality of GMPLS requires close interaction between RSVP and LMP. It
works in the following sequence:

1. LMP notifies RSVP of the new entities:

• Traffic engineering link (forwarding adjacency)

• Resources available for the traffic engineering link

• Control peer

2. GMPLS extracts the LSP attributes from the configuration and requests RSVP to
signal one or more specific paths, which are specified by the traffic engineering link
addresses.

3. RSVP determines the local traffic engineering link, corresponding control adjacency
and active control channel, and transmission parameters (such as IP destination). It

582 Copyright © 2012, Juniper Networks, Inc.

 Chapter 20: GMPLS Overview

requests that LMP allocate a resource from the traffic engineering link with the
specified attributes. If LMP finds a resource matching the attributes, label allocation
succeeds. RSVP sends a PathMsg hop by hop until it reaches the target router.

4. When the target router receives the PathMsg, RSVP again requests that LMP allocate
a resource based on the signaled parameters. If label allocation succeeds, the router
sends back a ResvMsg.

5. If the signaling is successful, a bidirectional optical path is provisioned.

GMPLS and OSPF

You can configure OSPF for GMPLS. OSPF is an interior gateway protocol (IGP) that
routes packets within a single autonomous system (AS). OSPF uses link-state information
to make routing decisions.

GMPLS and CSPF

GMPLS introduces extra constraints for computing paths for GMPLS LSPs that use CSPF.
These additional constraints affect the following link attributes:

• Signal type (minimum LSP bandwidth)

• Encoding type

• Switching type

These new constraints are populated in the traffic engineering database with the exchange
of an interface-switching capability descriptor type, length, value (TLV) through an IGP.

The ignored constraints that are exchanged through the interface switching capability
descriptor include:

• Maximum LSP bandwidth

• Maximum transmission unit (MTU)

The CSPF path computation is the same as in non-GMPLS environments, except that
the links are also limited by GMPLS constraints.

Each link can have multiple interface-switching capability descriptors. All the descriptors
are checked before a link is rejected.

The constraints are checked in the following order:

1. The signal type configured for the GMPLS LSP signifies the amount of bandwidth
requested. If the desired bandwidth is less than the minimum LSP bandwidth, the
interface-switching descriptor is rejected.

2. The encoding type of the link for the ingress and the egress interfaces should match.
The encoding type is selected and stored at the ingress node after all the constraints
are satisfied by the link and is used to select the link on the egress node.

Copyright © 2012, Juniper Networks, Inc. 583

Junos OS 12.1 MPLS Applications Configuration Guide

3. The switching type of the links of the intermediate switches should match that of the
GMPLS LSP specified in the configuration.

GMPLS Features

The Junos OS includes the following GMPLS functionality:

• An out-of-band control plane makes it possible to signal LSP path setup.

• RSVP-TE extensions support additional objects beyond Layer 3 packets, such as ports,
time slots, and wavelengths.

• The LMP protocol creates and maintains a database of traffic engineering links and
peer information. Only the static version of this protocol is supported in the Junos OS.
You can optionally configure LMP to establish and maintain LMP control channels
between peers running the same Junos OS Release.

• Bidirectional LSPs are required between devices.

• Several GMPLS label types that are defined in RFC 3471, Generalized
MPLS—Signaling Functional Description, such as MPLS, Generalized, SONET/SDH,
Suggested, and Upstream, are supported. Generalized labels do not contain a type
field, because the nodes should know from the context of their connection what type
of label to expect.

• Traffic parameters facilitate GMPLS bandwidth encoding and SONET/SDH formatting.

• Other supported attributes include interface identification and errored interface

identification, user-to-network (UNI)-style signaling, and secondary LSP paths.

584 Copyright © 2012, Juniper Networks, Inc.

CHAPTER 21

GMPLS Configuration Guidelines

This chapter describes how to configure GMPLS:

• LMP Configuration Overview on page 585

• Configuring LMP Traffic Engineering Links on page 586
• Configuring LMP Peers on page 588
• Configuring RSVP and OSPF for LMP Peer Interfaces on page 593
• Configuring MPLS Paths for GMPLS on page 594
• Tracing LMP Traffic on page 595
• Configuring MPLS LSPs for GMPLS on page 595
• Gracefully Tearing Down GMPLS LSPs on page 598

LMP Configuration Overview

You need to configure the Link Management Protocol (LMP) to define the data channel
connection and the control channel connection between devices. Include the following
statements at the [edit protocols link-management] hierarchy level:

[edit protocols link-management]

peer peer-name {
address address;
control-channel control-channel-name;
lmp-control-channel control-channel-interface {
remote-address ip-address;
}
lmp-protocol {
hello-dead-interval milliseconds;
hello-interval milliseconds;
retransmission-interval milliseconds;
retry-limit number;
passive;
}
te-link te-link-name;
}
te-link te-link-name {
disable;
interface interface-name {
disable;
local-address ip-address;

Copyright © 2012, Juniper Networks, Inc. 585

Junos OS 12.1 MPLS Applications Configuration Guide

remote-address ip-address;
remote-id id-number;
}
label-switched-path lsp-name;
local-address ip-address;
remote-address ip-address;
remote-id id-number;
}
traceoptions {
file filename <files number> <size size> <world-readable | no-world-readable>;
flag flag <flag-modifier> <disable>;
}

NOTE: Although you can include GMPLS configuration statements at the

[edit logical-systems logical-system-name] hierarchy level, GMPLS is not
supported on logical systems.

For information about configuring LMP, see the following sections:

• Configuring LMP Traffic Engineering Links on page 586

• Configuring LMP Peers on page 588

• Configuring RSVP and OSPF for LMP Peer Interfaces on page 593

• Configuring MPLS Paths for GMPLS on page 594

• Tracing LMP Traffic on page 595

Configuring LMP Traffic Engineering Links

An LMP traffic engineering link acts as a data channel connection between GMPLS
devices.

To configure a traffic engineering link, include the te-link statement at the [edit protocols
link-management] hierarchy level:

[edit protocols link-management]

te-link te-link-name {
disable;
interface interface-name {
local-address ip-address;
remote-address ip-address;
remote-id id-number;
}
label-switched-path lsp-name;
local-address ip-address;
remote-address ip-address;
remote-id id-number;
}

586 Copyright © 2012, Juniper Networks, Inc.

 Chapter 21: GMPLS Configuration Guidelines

Complete the procedures in the following sections to configure an LMP traffic engineering
link:

• Configuring the Local IP Address for Traffic Engineering Links on page 587
• Configuring the Remote IP Address for Traffic Engineering Links on page 587
• Configuring the Remote ID for Traffic Engineering Links on page 588
When you configure a traffic engineering link that contains interfaces for an LMP peer,
you must also configure a control channel. However, no control channel is required for a
traffic engineering link that contains an LSP. For information about configuring control
channels, see “Configuring LMP Peers” on page 588.

Configuring the Local IP Address for Traffic Engineering Links

Use the local-address statement to configure the local IP address associated with the
traffic engineering link.

We recommend that you configure an IP address subnet for your traffic engineering link
addresses that is different from the subnet configured for your physical interfaces. This
configuration enables you to identify which addresses are physical and which addresses
belong to the traffic engineering link.

To configure the local IP address for the traffic engineering link, include the local-address
statement:

te-link te-link-name {
interface interface-name {
local-address ip-address;
}
local-address ip-address;
}

For a list of hierarchy levels at which you can include this statement, see the statement
summary section for this statement.

Configuring the Remote IP Address for Traffic Engineering Links

You need to specify the address of the remote end of the data channel for each traffic
engineering link. Use the remote-address statement to configure the remote IP address.

We recommend that you configure an IP address subnet for your traffic engineering link
addresses that is different from the subnet configured for your physical interfaces. This
enables you to identify which addresses are physical and which addresses belong to the
traffic engineering link.

To configure the remote IP address for the traffic engineering link, include the
remote-address statement:

te-link te-link-name {
interface interface-name {
remote-address ip-address;
}
remote-address ip-address;
}

Copyright © 2012, Juniper Networks, Inc. 587

Junos OS 12.1 MPLS Applications Configuration Guide

For a list of hierarchy levels at which you can include this statement, see the statement
summary section for this statement.

Configuring the Remote ID for Traffic Engineering Links

The local ID for the traffic engineering link is automatically assigned by LMP. The port
identifier and labels for the interfaces (resources) in the traffic engineering link are also
assigned automatically. However, you need to explicitly configure the remote ID for the
traffic engineering link and the remote ID traffic engineering link interface. The remote
ID for the interface must be based on the post-ID assignment of the peer node. The
remote IDs are needed for static mapping of remote labels to local labels.

Before you can obtain the remote IDs for the traffic engineering link and traffic engineering
link interface on the peer node, you must first configure the LMP peer, as described in
“Configuring LMP Peers” on page 588. Once you have configured the LMP peer, you can
obtain the traffic engineering link local ID and interface local ID by issuing the show
link-management te-link command. Once you have these IDs, you can configure them as
the remote IDs on the peer node.

To configure the remote ID for a traffic engineering link and for the traffic engineering link
interface, include the remote-id statement:

te-link te-link-name {
interface interface-name {
remote-id id-number;
}
remote-id id-number;
}

For a list of hierarchy levels at which you can include this statement, see the statement
summary section for this statement.

Configuring LMP Peers

You need to configure network peers for GMPLS. A peer is a network device that your
router communicates with when setting up the control and data channels. The peer is
often an optical cross-connect (OXC).

To configure an LMP peer name, include the peer statement at the [edit protocols
link-management] hierarchy level:

peer peer-name {
address ip-address;
control-channel control-channel-interface;
lmp-control-channel control-channel-interface {
remote-address ip-address;
}
lmp-protocol {
hello-dead-interval milliseconds;
hello-interval milliseconds;
retransmission-interval milliseconds;
retry-limit number;
passive;
}

588 Copyright © 2012, Juniper Networks, Inc.

 Chapter 21: GMPLS Configuration Guidelines

te-link te-link-name;
}

The following sections describe how to configure an LMP peer:

• Configuring the ID for LMP Peers on page 589

• Configuring the Interface for Control Channels Between LMP Peers on page 589
• Configuring the LMP Control Channel Interface for the Peer on page 589
• Configuring the Remote IP Address for LMP Control Channels on page 590
• Configuring Hello Message Intervals for LMP Control Channels on page 590
• Controlling Message Exchange for LMP Control Channels on page 591
• Preventing the Local Peer from Initiating LMP Negotiation on page 592
• Associating Traffic Engineering Links with LMP Peers on page 592
• Disabling the Traffic Engineering Link for LMP Peers on page 592

Configuring the ID for LMP Peers

To configure the LMP peer ID, include the address statement at the [edit protocols
link-management peer peer-name] hierarchy level. The default value for the LMP peer ID
is the loopback address.

[edit protocols link-management peer peer-name]

address ip-address;

Configuring the Interface for Control Channels Between LMP Peers

You must configure one or more control channels between the LMP peers. The control
channels must travel across either a point-to-point link or a tunnel.

To configure the interface for the control channel, include the control-channel statement
at the [edit protocols link-management peer peer-name] hierarchy level:

[edit protocols link-management peer peer-name]

control-channel [ interface-names ];

You can configure a generic routing encapsulation (GRE) interface for the control channel.
This type of interface does not require a Tunnel PIC.

NOTE: You can configure GRE interfaces only for GMPLS control channels.
GRE interfaces are not supported or configurable for other applications. For
more information, see the Junos OS Network Interfaces Configuration Guide.

Configuring the LMP Control Channel Interface for the Peer

In an environment that uses LMP to establish and maintain an LMP control channel
between peers, you can configure a number of attributes associated with LMP. To
configure the interface to be associated with the LMP control channel for the peer, include
the lmp-control-channel statement:

Copyright © 2012, Juniper Networks, Inc. 589

Junos OS 12.1 MPLS Applications Configuration Guide

lmp-control-channel control-channel-interface;

You can configure this statement at the following hierarchy levels:

• [edit protocols link-management peer peer-name]

• [edit logical-systems logical-system-name protocols link-management peer peer-name]

You can configure a GRE interface for the LMP control channel. This type of interface
does not require a Tunnel PIC.

NOTE: You can configure GRE interfaces only for GMPLS control channels.
GRE interfaces are not supported or configurable for other applications. For
more information, see the Junos OS Network Interfaces Configuration Guide.

When this LMP control channel interface comes up, the peers use LMP to negotiate
channel parameters and configure the control channel.

The local peer repeatedly sends a Config message to the remote peer. The Config message
contains the local control channel ID, the local peer’s node ID, a message ID, and a CONFIG
object that includes hello message attributes (the hello interval and the hello dead
interval).

The channel is activated when the remote peer responds with a ConfigAck message. The
remote peer does so only when its own configured hello interval and hello dead interval
match the values in the received Config message or the default values. If these values
do not match, the remote peer responds with a ConfigNack message. The local peer logs
this event and resends the Config message until the message retry limit is reached. When
the message retry limit is reached, the local peer logs that event and restarts the
configuration process.

Configuring the Remote IP Address for LMP Control Channels

You need to specify the address of the remote end of the LMP control channel.

To configure the remote IP address for the LMP control channel, include the
remote-address statement:

remote-address address;

You can configure this statement at the following hierarchy levels:

• [edit protocols link-management peer peer-name lmp-control-channel

control-channel-interface]

• [edit logical-systems logical-system-name protocols link-management peer peer-name

lmp-control-channel control-channel-interface]

Configuring Hello Message Intervals for LMP Control Channels

Hello messages are exchanged between LMP peers to maintain the control channel after
LMP has activated the control channel. The LMP control channel is considered to be up

590 Copyright © 2012, Juniper Networks, Inc.

 Chapter 21: GMPLS Configuration Guidelines

only when the hello negotiation is successful. Successful negotiation consists of the local
peer sending a hello message to the remote peer and receiving a hello message in
response.

The LMP peers continue to exchange hello messages after the LMP control channel is
up in order to maintain the channel.

The hello interval specifies the interval between periodic hello messages. The hello dead
interval specifies how long the local peer waits for a hello response before it declares
the LMP control channel to be down. When the channel goes down, the local peer restarts
the LMP control channel negotiation and configuration process.

You can specify a hello interval from 150 through 300,000 milliseconds. The default
hello interval is 150 milliseconds.

You can specify a hello dead interval from 500 through 300,000 milliseconds. The
default hello dead interval is 500 milliseconds.

To configure the attributes for hello messages exchanged between LMP peers, include
the hello-interval and hello-dead-interval statements:

hello-dead-interval milliseconds;
hello-interval milliseconds;

You can configure these statements at the following hierarchy levels:

• [edit protocols link-management peer peer-name lmp-protocol]

• [edit logical-systems logical-system-name protocols link-management peer peer-name

lmp-protocol]

When an LMP control channel comes up after a successful exchange of hello messages
between LMP peers, LMP uses link property correlation to verify the traffic engineering
and data link information on both sides of a link. To do so, the local peer sends a
LinkSummary message for each traffic engineering link governed by the LMP control
channel. The LinkSummary message contains information that characterizes the traffic
engineering link and each data link in the traffic engineering link.

The local peer continues sending a LinkSummary message for each link until the remote
peer responds with a LinkSummaryAck message or until the message retry limit is reached.
When the message retry limit is reached, the local peer logs that event and restarts the
link property correlation process.

When the remote peer receives a LinkSummary message, it examines its own link
information. If this information agrees with that in the LinkSummary message, the remote
peer responds with a LinkSummaryAck message. If the information is different, the remote
peer responds with a LinkSummaryNack message.

Controlling Message Exchange for LMP Control Channels

You can configure message attributes that control the exchange of LMP Config and
LinkSummary messages. The retransmission interval specifies the interval between

Copyright © 2012, Juniper Networks, Inc. 591

Junos OS 12.1 MPLS Applications Configuration Guide

resubmitted LMP messages. The retry limit specifies how many times LMP sends a
message before restarting the process.

You can specify a retransmission interval from 500 through 300,000 milliseconds. The
default retransmission interval is 500 milliseconds.

You can specify a retry limit from 3 through 1000 attempts. The default number of retry
attempts is three.

To configure attributes governing the exchange of LMP messages between peers, include
the retransmission-interval and retry-limit statements:

retransmission-interval milliseconds;
retry-limit number;

You can configure these statements at the following hierarchy levels:

• [edit protocols link-management peer peer-name lmp-protocol]

• [edit logical-systems logical-system-name protocols link-management peer peer-name

lmp-protocol]

Preventing the Local Peer from Initiating LMP Negotiation

You can specify that the local peer does not initiate LMP negotiation. Instead, the local
peer waits for the remote peer to configure the LMP control channel.

To configure the local peer to wait for the remote peer to configure the LMP control
channel, include the passive statement:

passive;

You can configure this statement at the following hierarchy levels:

• [edit protocols link-management peer peer-name lmp-protocol]

• [edit logical-systems logical-system-name protocols link-management peer peer-name

lmp-protocol]

Associating Traffic Engineering Links with LMP Peers

To specify the name of a traffic engineering link to be associated with this peer, include
the te-link statement at the [edit protocols link-management peer peer-name] hierarchy
level:

[edit protocols link-management peer peer-name]

te-link te-link-name;

For information about how to configure a traffic engineering link, see “Configuring LMP
Traffic Engineering Links” on page 586.

Disabling the Traffic Engineering Link for LMP Peers

To disable a specific traffic engineering link, include the disable statement:

disable;

592 Copyright © 2012, Juniper Networks, Inc.

 Chapter 21: GMPLS Configuration Guidelines

You can configure this statement at the following hierarchy levels:

• [edit protocols link-management te-link te-link-name]

• [edit logical-systems logical-system-name protocols link-management te-link

te-link-name]

Configuring RSVP and OSPF for LMP Peer Interfaces

After you have configured the LMP peers as described in “Configuring LMP Peers” on
page 588, add the peer interfaces to RSVP and OSPF. The peer interface name must match
the peer name configured in LMP. Once the peer interfaces are added to the protocols,
the traffic engineering link local and remote addresses can be signaled and advertised
to peers like any other interface enabled for RSVP and OSPF. These addresses act as
virtual interfaces for GMPLS.

NOTE: When adding the virtual peer interfaces to RSVP and OSPF, do not
configure the corresponding physical control channel interface in either
protocol. If you include the interface all statement, you must disable RSVP
and OSPF protocols manually on the control channel interface.

To configure peer interfaces in RSVP and OSPF, complete the procedures in the following
sections:

• Configuring RSVP Signaling for LMP Peer Interfaces on page 593

• Configuring OSPF Routing for LMP Peer Interfaces on page 593
• Configuring the Hello Interval for LMP Peer Interfaces on page 594

Configuring RSVP Signaling for LMP Peer Interfaces

To configure RSVP signaling for LMP peers, configure the LMP peer interface by including
the peer-interface statement at the [edit protocols rsvp] hierarchy level:

[edit protocols rsvp]

peer-interface peer-interface-name {
(aggregate | no-aggregate);
authentication-key key;
disable;
hello-interval seconds;
(reliable | no-reliable);
}

The statements configured at the [edit protocols rsvp peer-interface peer-interface-name]

hierarchy level have the same functionality as the statements configured at the [edit
protocols rsvp interface interface-name] hierarchy level.

Configuring OSPF Routing for LMP Peer Interfaces

To configure OSPF routing for LMP peers, configure the name of the LMP peer by including
the peer-interface statement at the [edit protocols ospf area area-number] hierarchy level:

Copyright © 2012, Juniper Networks, Inc. 593

Junos OS 12.1 MPLS Applications Configuration Guide

[edit protocols ospf area area-number]

peer-interface peer-interface-name {
dead-interval seconds;
disable;
hello-interval seconds;
retransmit-interval seconds;
transit-delay seconds;
}

For information about how to configure OSPF statements, see the Junos OS Routing
Protocols Configuration Guide.

Configuring the Hello Interval for LMP Peer Interfaces

Hello packets are used to indicate to neighboring routers that the peer interface is still
up and running. The hello interval must be the same for all routers on a shared logical IP
network. You can specify a hello interval from 1 through 255 seconds. The default hello
interval is normally 10 seconds. For nonbroadcast networks, the default hello interval is
120 seconds.

To specify how often the router sends hello packets out the peer interface, configure the
hello-interval statement:

hello-interval seconds;

You can configure this statement at the following hierarchy levels:

• [edit protocols ospf area area-number peer-interface peer-interface-name]

• [edit logical-systems logical-system-name protocols ospf area area-number

peer-interface peer-interface-name]

Configuring MPLS Paths for GMPLS

As part of the configuration for GMPLS, you need to establish an MPLS path for each
unique device connected through GMPLS. Configure the traffic engineering link remote
address as the address at the [edit protocols mpls path path-name] hierarchy level.
Constrained Shortest Path First (CSPF) is supported so you can choose either the strict
or loose option with the address.

See “LMP Configuration Overview” on page 585 for information about how to obtain a
traffic engineering link remote address.

To configure the MPLS path, include the path statement at the [edit protocols mpls]
hierarchy level:

[edit protocols mpls]

path path-name {
next-hop-address (strict | loose);
}

For information about how to configure MPLS paths, see “Creating Named Paths” on
page 56.

594 Copyright © 2012, Juniper Networks, Inc.

 Chapter 21: GMPLS Configuration Guidelines

Tracing LMP Traffic

To trace LMP protocol traffic, include the traceoptions statement at the [edit protocols
link-management] hierarchy level:

[edit protocols link-management]

traceoptions {
file filename <files number> <size size> <world-readable | no-world-readable>;
flag flag <flag-modifier> <disable>;
}

Use the file statement to specify the name of the file that receives the output of the
tracing operation. All files are placed in the directory /var/log.

The following trace flags display the operations associated with the sending and receiving
of various LMP messages:

• all—Trace all available operations

• hello-packets—Trace hello packets on any LMP control channel

• init—Output from the initialization messages

• packets—Trace all packets other than hello packets on any LMP control channel

• parse—Operation of the parser

• process—Operation of the general configuration

• route-socket—Operation of route socket events

• routing—Operation of the routing protocols

• server—Server processing operations

• show—Servicing operations for show commands

• state—Trace state transitions of the LMP control channels and traffic engineering links

Each flag can carry one or more of the following flag modifiers:

• detail—Provide detailed trace information

• receive—Packets being received

• send—Packets being transmitted

Configuring MPLS LSPs for GMPLS

To enable the proper GMPLS switching parameters, configure the label-switched path
(LSP) attributes that are appropriate for your network connection. The default value for
switching-type is psc-1, which is also appropriate for standard MPLS.

To configure the LSP attributes, include the lsp-attributes statement at the [edit protocols
mpls label-switched-path lsp-name] hierarchy level:

[edit protocols mpls label-switched-path lsp-name]

Copyright © 2012, Juniper Networks, Inc. 595

Junos OS 12.1 MPLS Applications Configuration Guide

lsp-attributes {
encoding-type type;
gpid gpid;
signal-bandwidth type;
switching-type type;
}

If you include the no-cspf statement in the label-switched path configuration, you must
also configure primary and secondary paths, or the configuration cannot be committed.

The following sections describe how to configure each of the LSP attributes for a GMPLS
LSP:

• Configuring the Encoding Type on page 596

• Configuring the GPID on page 596
• Configuring the Signal Bandwidth Type on page 597
• Configuring GMPLS Bidirectional LSPs on page 597
• Allowing Nonpacket GMPLS LSPs to Establish Paths Through Routers Running the
Junos OS on page 597

Configuring the Encoding Type

You need to specify the encoding type of the payload carried by the LSP. It can be any
of the following:

• ethernet—Ethernet

• packet—Packet

• pdh—Plesiochronous digital hierarchy (PDH)

• sonet-sdh—SONET/SDH

The default value is packet.

To configure the encoding type, include the encoding-type statement at the [edit protocols
mpls label-switched-path lsp-name lsp-attributes] hierarchy level:

[edit protocols mpls label-switched-path lsp-name lsp-attributes]

encoding-type type;

Configuring the GPID

You need to specify the type of payload carried by the LSP. The payload is the type of
packet underneath the MPLS label. The payload is specified by the generalized payload
identifier (GPID).

You can specify the GPID with any of the following values:

• hdlc—High-Level Data Link Control (HDLC)

• ethernet—Ethernet

• ipv4—IP version 4 (default)

596 Copyright © 2012, Juniper Networks, Inc.

 Chapter 21: GMPLS Configuration Guidelines

• pos-scrambling-crc-16—For interoperability with other vendors’ equipment

• pos-no-scrambling-crc-16—For interoperability with other vendors’ equipment

• pos-scrambling-crc-32—For interoperability with other vendors’ equipment

• pos-no-scrambling-crc-32—For interoperability with other vendors’ equipment

• ppp—Point-to-Point Protocol (PPP)

To configure the GPID, include the gpid statement at the [edit protocols mpls
label-switched-path lsp-name lsp-attributes] hierarchy level:

[edit protocols mpls label-switched-path lsp-name lsp-attributes]

gpid gpid;

Configuring the Signal Bandwidth Type

The signal bandwidth type is the encoding used for path computation and admission
control. To configure the signal bandwidth type, include the signal-bandwidth statement
at the [edit protocols mpls label-switched-path lsp-name lsp-attributes] hierarchy level:

[edit protocols mpls label-switched-path lsp-name lsp-attributes]

signal-bandwidth type;

Configuring GMPLS Bidirectional LSPs

Because MPLS and GMPLS use the same configuration hierarchy for LSPs, it is helpful
to know which LSP attributes control LSP functionality. Standard MPLS packet-switched
LSPs are unidirectional, whereas GMPLS nonpacket LSPs are bidirectional.

If you use the default packet-switching type of psc-1, your LSP becomes unidirectional.
To enable a GMPLS bidirectional LSP, you must select a non-packet-switching type
option, such as lambda, fiber, or ethernet. Include the switching-type statement at the
[edit protocols mpls label-switched-path lsp-name lsp-attributes] hierarchy level:

[edit protocols mpls label-switched-path lsp-name lsp-attributes]

switching-type (lambda | fiber | ethernet);

Allowing Nonpacket GMPLS LSPs to Establish Paths Through Routers Running the Junos OS
By setting the A-bit in the Admin Status object. you can enable nonpacket GMPLS LSPs
to establish paths through routers that run Junos. When an ingress router sends an RSVP
PATH message with the Admin Status A-bit set, an external device (not a router running
the Junos OS) can either perform a Layer 1 path setup test or help bring up an optical
cross-connect.

When set, the A-bit in the Admin Status object indicates the administrative down status
for a GMPLS LSP. This feature is used specifically by nonpacket GMPLS LSPs. It does
not affect control path setup or data forwarding for packet LSPs.

Junos does not distinguish between the control path setup and data path setup. Other
nodes along the network path use RSVP PATH signaling using the A-bit in a meaningful
way.

Copyright © 2012, Juniper Networks, Inc. 597

Junos OS 12.1 MPLS Applications Configuration Guide

To configure the Admin Status object for a GMPLS LSP, include the admin-down
statement:

admin-down;

You can include this statement at the following hierarchy levels:

• [edit protocols mpls label-switched-path lsp-name]

• [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name]

Gracefully Tearing Down GMPLS LSPs

You can gracefully tear down nonpacket GMPLS LSPs. An LSP that is torn down abruptly,
a common process in a packet-switched network, can cause stability problems in
nonpacket-switched networks. To maintain the stability of nonpacket-switched networks,
it might be necessary to tear down LSPs gracefully.

The following sections describe how to tear down GMPLS LSPs gracefully:

• Temporarily Deleting GMPLS LSPs on page 598

• Permanently Deleting GMPLS LSPs on page 598
• Configuring the Graceful Deletion Timeout Interval on page 599

Temporarily Deleting GMPLS LSPs

You can gracefully tear down a GMPLS LSP using the clear rsvp session gracefully
command.

This command gracefully tears down an RSVP session for a nonpacket LSP in two passes.
In the first pass, the Admin Status object is signaled along the path to the endpoint of
the LSP. During the second pass, the LSP is taken down. Using this command, the LSP
is taken down temporarily. After the appropriate interval, the GMPLS LSP is resignaled
and then reestablished.

The clear rsvp session gracefully command has the following properties:

• It only works on the ingress and egress routers of an RSVP session. If used on a transit
router, it has the same behavior as the clear rsvp session command.

• It only works for nonpacket LSPs. If used with packet LSPs, it has the same behavior
as the clear rsvp session command.

For more information, see the Junos OS Routing Protocols and Policies Command Reference.

Permanently Deleting GMPLS LSPs

When you disable an LSP in the configuration, the LSP is permanently deleted. By
configuring the disable statement, you can disable a GMPLS LSP permanently. If the LSP
being disabled is a nonpacket LSP, then the graceful LSP tear-down procedures that use
the Admin Status object are used. If the LSP being disabled is a packet LSP, then the
regular signaling procedures for LSP deletion are used.

598 Copyright © 2012, Juniper Networks, Inc.

 Chapter 21: GMPLS Configuration Guidelines

To disable a GMPLS LSP, include the disable statement at any of the following hierarchy
levels:

• [edit protocols mpls label-switched-path lsp-name]—Disable the LSP.

• [edit protocols link-management te-link te-link-name]—Disable a traffic engineering

link.

• [edit protocols link-management te-link te-link-name interface interface-name]—Disable

an interface used by a traffic engineering link.

Configuring the Graceful Deletion Timeout Interval

The router that initiates the graceful deletion procedure for an RSVP session waits for
the graceful deletion timeout interval to ensure that all routers along the path (especially
the ingress and egress routers) have prepared for the LSP to be taken down.

The ingress router initiates the graceful deletion procedure by sending the Admin Status
object in the path message with the D bit set. The ingress router expects to receive an
Resv message with the D bit set from the egress router. If the ingress router does not
receive this message within the time specified by the graceful deletion timeout interval,
it initiates a forced tear-down of the LSP by sending a PathTear message.

To configure the graceful deletion timeout interval, include the graceful-deletion-timeout

statement at the [edit protocols rsvp] hierarchy level. You can configure a time between
1 through 300 seconds. The default value is 30 seconds.

graceful-deletion-timeout seconds;

You can configure this statement at the following hierarchy levels:

• [edit protocols rsvp]

• [edit logical-systems logical-system-name protocols rsvp]

You can use the show rsvp version command to determine the current value configured
for the graceful deletion timeout.

Copyright © 2012, Juniper Networks, Inc. 599

Junos OS 12.1 MPLS Applications Configuration Guide

600 Copyright © 2012, Juniper Networks, Inc.

CHAPTER 22

Hierarchy of RSVP LSPs Configuration

Guidelines

• Hierarchy of RSVP LSPs Standard on page 601

• Hierarchy of RSVP LSPs Terminology on page 601
• Hierarchy of RSVP LSPs Overview on page 601
• Hierarchy of RSVP LSPs on page 602
• Advertising the Forwarding Adjacency with OSPF on page 602
• Configuring a Hierarchy of RSVP LSPs on page 602

Hierarchy of RSVP LSPs Standard

For more information on how a hierarchy of RSVP LSPs functions, see RFC 4206, Label
Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS)
Traffic Engineering (TE).

Hierarchy of RSVP LSPs Terminology

F
Forwarding adjacency A traffic engineering link created by a forwarding adjacency LSP. You can create a forwarding
adjacency between two routers in a network by configuring a forwarding adjacency LSP.
Forwarding adjacencies can only be statically configured. However, you can configure OSPF
to advertise the forwarding adjacency to other routers. When an RSVP LSP traverses a
forwarding adjacency, existing MPLS features such as fast reroute continue to function.

Forwarding adjacency An RSVP LSP used to tunnel other RSVP LSPs; forms the basis for a forwarding adjacency.
LSP

Hierarchy of RSVP LSPs Overview

This chapter provides overview information and configuration instructions for hierarchies
of RSVP label-switched paths (LSPs), which enable you to tunnel multiple RSVP LSPs
over a single RSVP LSP.

Copyright © 2012, Juniper Networks, Inc. 601

Junos OS 12.1 MPLS Applications Configuration Guide

The following sections provide an overview of how a hierarchy of RSVP LSPs functions:

• Hierarchy of RSVP LSPs on page 602

• Advertising the Forwarding Adjacency with OSPF on page 602

Hierarchy of RSVP LSPs

Forwarding adjacencies are configured and managed as point-to-point traffic engineering

links by including statements at the [edit protocols link-management] hierarchy level.
For the forwarding adjacency to function properly, you also need to make RSVP aware
of the forwarding adjacency by configuring the corresponding peer interface at the [edit
protocols rsvp] hierarchy level.

Although forwarding adjacency LSPs are configured and managed as traffic engineering
links on the local router, it is not necessary to advertise these traffic engineering links to
other routers in the network. However, if you want to automatically forward MPLS traffic
over the forwarding adjacency or want other routers to compute paths over the forwarding
adjacency, you must configure OSPF to advertise the forwarding adjacency to the other
routers in the network and add the forwarding adjacency to the traffic engineering
database. OSPF is the only supported interior gateway protocol (IGP).

Advertising the Forwarding Adjacency with OSPF

Once a forwarding adjacency LSP and the corresponding traffic engineering link you have
configured, you can configure OSPF to advertise the forwarding adjacency. Unlike regular
traffic engineering links, OSPF hellos are not exchanged between the forwarding adjacency
LSP endpoints and therefore no routing adjacency is created between the forwarding
adjacency endpoints. If you issue a show ospf neighbor command on an ingress forwarding
adjacency, the command displays the egress router of the forwarding adjacency LSP as
a neighbor. However, no real OSPF adjacency is established (no OSPF hellos are
exchanged) between the ingress and egress routers. For display purposes only, OSPF
creates a pseudo-neighbor corresponding to the peer.

You can configure forwarding adjacencies over existing MPLS networks. A forwarding
adjacency LSP is signaled as a regular MPLS LSP without generalized MPLS (GMPLS)
extensions. When the forwarding adjacency LSP is advertised as a traffic engineering
link in OSPF, the corresponding traffic engineering link in OSPF is also advertised as a
regular MPLS traffic engineering link without GMPLS extensions.

Configuring a Hierarchy of RSVP LSPs

The following sections describe how to configure a hierarchy of RSVP LSPs:

• Configuring an RSVP LSP on Ingress Routers on page 603

• Configuring Forwarding Adjacencies on page 603
• Configuring RSVP for Forwarding Adjacencies on page 604
• Advertising Forwarding Adjacencies Using OSPF on page 605

602 Copyright © 2012, Juniper Networks, Inc.

 Chapter 22: Hierarchy of RSVP LSPs Configuration Guidelines

Configuring an RSVP LSP on Ingress Routers

To configure a standard RSVP LSP on the ingress router to be used as the forwarding
adjacency LSP, see “LSP Configuration Overview” on page 144. This LSP requires no special
configuration to function as a forwarding adjacency LSP.

Configuring Forwarding Adjacencies

A forwarding adjacency is a type of GMPLS traffic engineering link. It requires that you
configure local and remote addresses to identify the link. A forwarding adjacency is
associated with a specific peer router. You could configure multiple forwarding adjacencies
to the same peer router.

To configure a forwarding adjacency, you need to configure the te-link statement at the
[edit protocols link-management] hierarchy level:

[edit protocols link-management]

te-link te-link-name {
label-switched-path lsp-name;
local-address ip-address;
remote-address ip-address;
}

For more information on how to configure GMPLS traffic engineering links, see “Configuring
LMP Traffic Engineering Links” on page 586.

NOTE: Do not configure the control channel for a forwarding adjacency peer
router. Configuring a control channel causes the commit operation to fail.

The following sections describe how to configure the te-link statement for a forwarding
adjacency:

• Configuring the Local IP Address for Forwarding Adjacencies on page 603

• Configuring the Remote IP Address for Forwarding Adjacencies on page 603
• Configuring the LSP for Forwarding Adjacencies on page 604

Configuring the Local IP Address for Forwarding Adjacencies

To configure the local IP address for the forwarding adjacency, include the local-address
statement:

local-address ip-address;

For a list of hierarchy levels at which you can include this statement, see the statement
summary section for this statement.

Configuring the Remote IP Address for Forwarding Adjacencies

The address of the peer router is the node ID for the forwarding adjacency LSP egress
node. You configure this node ID for the forwarding adjacency using the remote-address
statement:

Copyright © 2012, Juniper Networks, Inc. 603

Junos OS 12.1 MPLS Applications Configuration Guide

remote-address ip-address;

You can include this statement at the following hierarchy levels:

• [edit protocols link-management te-link te-link-name],

• [edit logical-systems logical-system-name protocols link-management te-link

te-link-name]

Configuring the LSP for Forwarding Adjacencies

To configure a router to function as a forwarding adjacency, use the label-switched-path

statement and specify the LSP configured in “Configuring a Hierarchy of RSVP LSPs” on
page 602:

label-switched-path label-switched-path-name;

You can include this statement at the following hierarchy levels:

• [edit protocols link-management te-link te-link-name]

• [edit logical-systems logical-system-name protocols link-management te-link

te-link-name]

Configuring RSVP for Forwarding Adjacencies

For the forwarding adjacency to function properly, RSVP must be made aware of it. Do
this by specifying the name of the peer interface corresponding to the link-management
peer associated with the forwarding adjacency. Including the peer-interface statement
at the [edit protocols rsvp] hierarchy level enables RSVP to use all of the traffic engineering
links configured for that peer. You can also configure RSVP control-plane parameters
such as the hello interval and refresh reduction.

To configure RSVP to recognize a forwarding adjacency, include the peer-interface

statement:

peer-interface peer-interface-name {
disable;
(aggregate | no-aggregate);
authentication-key key;
hello-interval seconds;
(reliable | no-reliable);
}

You can include this statement at the following hierarchy levels:

• [edit protocols rsvp]

• [edit logical-systems logical-system-name protocols rsvp]

For more information on how to configure the peer-interface statement, see “Configuring
RSVP and OSPF for LMP Peer Interfaces” on page 593.

604 Copyright © 2012, Juniper Networks, Inc.

 Chapter 22: Hierarchy of RSVP LSPs Configuration Guidelines

Advertising Forwarding Adjacencies Using OSPF

You can allow other routers to dynamically signal paths over a forwarding adjacency
LSP by configuring OSPF. This configuration is optional.

If you configure OSPF to advertise a forwarding adjacency LSP, the LSP is added to the
traffic engineering database on each router in the traffic engineering domain. Because
the forwarding adjacency LSP is unidirectional, the corresponding traffic engineering link
(forwarding adjacency) is also unidirectional. The forwarding adjacency LSP appears as
a standard traffic engineering database half-link to all routers in the traffic engineering
domain.

Constrained Shortest Path First (CSPF) performs a bidirectional link check to ensure that
traffic can flow in both directions. CSPF checks for a reverse link, either the exact reverse
forwarding adjacency or another reverse link. If there is no reverse link from the forwarding
adjacency LSP egress router to the forwarding adjacency LSP ingress router, the CSPF
check fails.

CSPF might find another parallel reverse link. However, the LSP cannot function properly
over the forwarding adjacency unless you have explicitly configured a corresponding
forwarding adjacency LSP to handle the traffic flowing in the opposite direction on the
forwarding adjacency LSP egress router.

To advertise the traffic engineering properties of a forwarding adjacency to a specific

peer router, include the peer-interface statement:

peer-interface peer-interface-name {
dead-interval seconds;
disable;
hello-interval seconds;
retransmit-interval seconds;
transit-delay seconds;
}

You can configure this statement at the following hierarchy levels:

• [edit protocols ospf area area-name]

• [edit logical-systems logical-system-name protocols ospf area area-name]

For more information on how to configure the peer-interface statement, see “Configuring
RSVP and OSPF for LMP Peer Interfaces” on page 593.

Copyright © 2012, Juniper Networks, Inc. 605

Junos OS 12.1 MPLS Applications Configuration Guide

606 Copyright © 2012, Juniper Networks, Inc.

CHAPTER 23

Summary of GMPLS Configuration

Statements

This chapter provides a reference for each Generalized MPLS (GMPLS) configuration
statement. The statements are organized alphabetically.

address

Syntax address ip-address;

Hierarchy Level [edit logical-systems logical-system-name protocols link-management peer peer-name],

[edit protocols link-management peer peer-name]

Release Information Statement introduced before Junos OS Release 7.4.

Description Specify the ID of the peer.

Default The loopback address is advertised.

Options ip-address—IP address of the peer.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring the ID for LMP Peers on page 589

Documentation

Copyright © 2012, Juniper Networks, Inc. 607

Junos OS 12.1 MPLS Applications Configuration Guide

control-channel

Syntax control-channel control-channel-interface;

Hierarchy Level [edit logical-systems logical-system-name protocols link-management peer peer-name],

[edit protocols link-management peer peer-name]

Release Information Statement introduced before Junos OS Release 7.4.

Description Specify the control channel interface for the peer.

Options control-channel-interface—Name of the control channel interface.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring LMP Peers on page 588

Documentation

dead-interval

Syntax dead-interval seconds;

Hierarchy Level [edit logical-systems logical-system-name protocols ospf area area-number

peer-interface peer-interface-name],
[edit protocols ospf area area-number peer-interface peer-interface-name]

Release Information Statement introduced before Junos OS Release 7.4.

Description Specify how long OSPF and OSPF version 3 (OSPFv3) wait before declaring that a
neighboring router is unavailable. This is an interval during which the router receives no
hello packets from the neighbor.

Options seconds—Interval to wait.

Range: 1 through 65,535
Default: 40 seconds (four times the hello interval)

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring RSVP and OSPF for LMP Peer Interfaces on page 593
Documentation
• hello-interval (OSPF) on page 612

608 Copyright © 2012, Juniper Networks, Inc.

 Chapter 23: Summary of GMPLS Configuration Statements

disable

See the following sections:

• disable (GMPLS) on page 609

• disable (OSPF Peer Interface) on page 609

disable (GMPLS)
Syntax disable;

Hierarchy Level [edit logical-systems logical-system-name protocols link-management te-link te-link-name],

[edit protocols link-management te-link te-link-name]

Release Information Statement introduced before Junos OS Release 7.4.

Description Disable a traffic engineering link.

Default The configured object is enabled (operational) unless explicitly disabled.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Disabling the Traffic Engineering Link for LMP Peers on page 592
Documentation

disable (OSPF Peer Interface)

Syntax disable;

Hierarchy Level [edit logical-systems logical-system-name protocols ospf area area-number

peer-interface peer-interface-name],
[edit protocols ospf area area-number peer-interface peer-interface-name]

Release Information Statement introduced before Junos OS Release 7.4.

Description Disable an OSPF peer interface.

Default The configured object is enabled (operational) unless explicitly disabled.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring RSVP and OSPF for LMP Peer Interfaces on page 593
Documentation

Copyright © 2012, Juniper Networks, Inc. 609

Junos OS 12.1 MPLS Applications Configuration Guide

hello-dead-interval

Syntax hello-dead-interval milliseconds;

Hierarchy Level [edit logical-systems logical-system-name protocols link-management peer peer-name

lmp-protocol],
[edit protocols link-management peer peer-name lmp-protocol]

Release Information Statement introduced in Junos OS Release 8.0.

Description Specify how long the Link Management Protocol (LMP) waits before declaring the control
channel to be dead. This is an interval during which the router receives no LMP hello
packets from the neighbor on a control that is active or up.

Options milliseconds—Interval to wait before declaring the control channel to be dead.

Range: 500 through 300,000
Default: 500 milliseconds (three times the hello interval)

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring Hello Message Intervals for LMP Control Channels on page 590
Documentation
• hello-interval (LMP) on page 611

610 Copyright © 2012, Juniper Networks, Inc.

 Chapter 23: Summary of GMPLS Configuration Statements

hello-interval

See the following sections:

• hello-interval (LMP) on page 611

• hello-interval (OSPF) on page 612

hello-interval (LMP)
Syntax hello-interval milliseconds;

Hierarchy Level [edit logical-systems logical-system-name protocols link-management peer peer-name

lmp-protocol],
[edit protocols link-management peer peer-name lmp-protocol]

Release Information Statement introduced in Junos OS Release 8.1.

Description Specify how often the router sends Link Management Protocol (LMP) hello packets.

Options milliseconds—Length of time between hello packets.

Range: 150 through 300,000
Default: 150 milliseconds

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring Hello Message Intervals for LMP Control Channels on page 590
Documentation
• hello-dead-interval on page 610

Copyright © 2012, Juniper Networks, Inc. 611

Junos OS 12.1 MPLS Applications Configuration Guide

hello-interval (OSPF)
Syntax hello-interval seconds;

Hierarchy Level [edit logical-systems logical-system-name protocols ospf area area-number

peer-interface peer-interface-name],
[edit protocols ospf area area-number peer-interface peer-interface-name]

Release Information Statement introduced before Junos OS Release 7.4.

Description Specify how often the router sends hello packets out the peer interface. The hello interval
must be the same for all routers on a shared logical IP network.

Options seconds—Length of time between hello packets.

Range: 1 through 255
Default: 10 seconds; 120 seconds (nonbroadcast networks)

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring RSVP and OSPF for LMP Peer Interfaces on page 593
Documentation
• dead-interval on page 608

interface

Syntax interface interface-name;

Hierarchy Level [edit logical-systems logical-system-name protocols link-management te-link te-link-name],

[edit protocols link-management te-link te-link-name]

Release Information Statement introduced before Junos OS Release 7.4.

Description Specify the egress router interface.

Options interface-name—Name of the interface to the egress router.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • LMP Configuration Overview on page 585

Documentation

612 Copyright © 2012, Juniper Networks, Inc.

 Chapter 23: Summary of GMPLS Configuration Statements

label-switched-path

Syntax label-switched-path lsp-name;

Hierarchy Level [edit logical-systems logical-system-name protocols link-management te-link te-link-name],

[edit protocols link-management te-link te-link-name]

Release Information Statement introduced in Junos OS Release 7.4.

Description Specify the label-switched path (LSP) to be used by the forwarding adjacency.

Options lsp-name—Name of the LSP.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring Forwarding Adjacencies on page 603

Documentation

link-management

Syntax link-management { ... }

Hierarchy Level [edit logical-systems logical-system-name protocols],

[edit protocols]

Release Information Statement introduced before Junos OS Release 7.4.

Description Enable Link Management Protocol (LMP) on the router.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • LMP Configuration Overview on page 585

Documentation

Copyright © 2012, Juniper Networks, Inc. 613

Junos OS 12.1 MPLS Applications Configuration Guide

lmp-control-channel

Syntax lmp-control-channel control-channel-interface {

remote-address ip-address;
}

Hierarchy Level [edit logical-systems logical-system-name protocols link-management peer peer-name],

[edit protocols link-management peer peer-name]

Release Information Statement introduced in Junos OS Release 8.1.

Description Specify the Link Management Protocol (LMP) control channel interface for the peer.

Options control-channel-interface—Name of the control channel interface.

The remaining statement is described separately in this chapter.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring the LMP Control Channel Interface for the Peer on page 589
Documentation

lmp-protocol

Syntax lmp-protocol {
hello-dead-interval milliseconds;
hello-interval milliseconds;
passive;
retransmission-interval milliseconds;
retry-limit number;
}

Hierarchy Level [edit logical-systems logical-system-name protocols link-management peer peer-name],

[edit protocols link-management peer peer-name]

Release Information Statement introduced in Junos OS Release 8.1.

Description Configure attributes of Link Management Protocol (LMP) to establish and maintain the
LMP control channel for the peer.

Options The statements are described separately in this chapter.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring LMP Peers on page 588

Documentation

614 Copyright © 2012, Juniper Networks, Inc.

 Chapter 23: Summary of GMPLS Configuration Statements

local-address

Syntax local-address ip-address;

Hierarchy Level [edit logical-systems logical-system-name protocols link-management te-link te-link-name],

[edit logical-systems logical-system-name protocols link-management te-link te-link-name
interface interface-name],
[edit protocols link-management te-link te-link-name],
[edit protocols link-management te-link te-link-name interface interface-name]

Release Information Statement introduced before Junos OS Release 7.4.

Description Specify the local IP address associated with the traffic engineering link.

Options local-address—Local IP address of the traffic engineering link.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring the Local IP Address for Traffic Engineering Links on page 587
Documentation
• Configuring the Local IP Address for Forwarding Adjacencies on page 603

passive

Syntax passive;

Hierarchy Level [edit logical-systems logical-system-name protocols link-management peer peer-name

lmp-protocol],
[edit protocols link-management peer peer-name lmp-protocol]

Release Information Statement introduced in Junos OS Release 8.1.

Description Specify that the router not configure the Link Management Protocol (LMP) control
channels but wait for the remote peer to configure the LMP control channels.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Preventing the Local Peer from Initiating LMP Negotiation on page 592
Documentation

Copyright © 2012, Juniper Networks, Inc. 615

Junos OS 12.1 MPLS Applications Configuration Guide

peer

Syntax peer peer-name {

address ip-address;
control-channel control-channel-interface;
lmp-control-channel control-channel-interface;
lmp-protocol {
hello-dead-interval milliseconds;
hello-interval milliseconds;
passive;
retransmission-interval milliseconds;
retry-limit number;
}
te-link te-link-name;
}

Hierarchy Level [edit logical-systems logical-system-name protocols link-management],

[edit protocols link-management]

Release Information Statement introduced before Junos OS Release 7.4.

lmp-protocol statement and substatements added in Junos OS Release 8.1.

Description Configure a network peer.

Options peer-name—Name of the network peer.

The remaining statements are described separately in this chapter.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring LMP Peers on page 588

Documentation

616 Copyright © 2012, Juniper Networks, Inc.

 Chapter 23: Summary of GMPLS Configuration Statements

peer-interface (OSPF)

Syntax peer-interface peer-interface-name {

dead-interval seconds;
disable;
hello-interval seconds;
retransmit-interval seconds;
transit-delay seconds;
}

Hierarchy Level [edit logical-systems logical-system-name protocols ospf area area-id],

[edit protocols ospf area area-id]

Release Information Statement introduced before Junos OS Release 7.4.

Description Configure the control channel. The peer interface name is the same as the peer interface
name configured under LMP.

Options The options are explained separately.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring RSVP and OSPF for LMP Peer Interfaces on page 593
Documentation
• Advertising Forwarding Adjacencies Using OSPF on page 605

• Junos OS Routing Protocols Configuration Guide

Copyright © 2012, Juniper Networks, Inc. 617

Junos OS 12.1 MPLS Applications Configuration Guide

remote-address

See the following sections:

• remote-address (for LMP Control Channel) on page 618

• remote-address (for LMP Traffic Engineering) on page 618

remote-address (for LMP Control Channel)

Syntax remote-address ip-address;

Hierarchy Level [edit logical-systems logical-system-name protocols link-management peer peer-name

lmp-control-channel control-channel-interface],
[edit protocols link-management peer peer-name lmp-control-channel
control-channel-interface]

Release Information Statement introduced in Junos OS Release 8.1.

Description Specify the remote IP address for the Link Management Protocol (LMP) control channel
interface.

Options ip-address—Remote IP address mapped to the LMP control channel interface.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring the Remote IP Address for LMP Control Channels on page 590
Documentation

remote-address (for LMP Traffic Engineering)

Syntax remote-address ip-address;

Hierarchy Level [edit logical-systems logical-system-name protocols link-management te-link te-link-name],

[edit logical-systems logical-system-name protocols link-management te-link te-link-name
interface interface-name],
[edit protocols link-management te-link te-link-name],
[edit protocols link-management te-link te-link-name interface interface-name]

Release Information Statement introduced before Junos OS Release 7.4.

Description Specify the remote IP address for the traffic engineering link.

Options ip-address—Remote IP address mapped to the traffic engineering link.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring the Remote IP Address for Traffic Engineering Links on page 587
Documentation
• Configuring the Remote IP Address for Forwarding Adjacencies on page 603

618 Copyright © 2012, Juniper Networks, Inc.

 Chapter 23: Summary of GMPLS Configuration Statements

remote-id

Syntax remote-id id-number;

Hierarchy Level [edit logical-systems logical-system-name protocols link-management te-link te-link-name],

[edit logical-systems logical-system-name protocols link-management te-link te-link-name
interface interface-name],
[edit protocols link-management te-link te-link-name],
[edit protocols link-management te-link te-link-name interface interface-name]

Release Information Statement introduced before Junos OS Release 7.4.

Description Specify the ID assigned to a traffic engineering link or an interface (resource) on the peer
node.

Options id-number—ID number for the remote device.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring the Remote ID for Traffic Engineering Links on page 588
Documentation

retransmission-interval

Syntax retransmission-interval milliseconds;

Hierarchy Level [edit logical-systems logical-system-name protocols link-management peer peer-name

lmp-protocol],
[edit protocols link-management peer peer-name lmp-protocol]

Release Information Statement introduced in Junos OS Release 8.1.

Description Specify how often Link Management Protocol (LMP) sends Config and LinkSummary
messages on the LMP control channel.

Options milliseconds—Length of time between Config messages.

Range: 500 through 300,000
Default: 500 milliseconds

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • retry-limit on page 620

Documentation
• Controlling Message Exchange for LMP Control Channels on page 591

Copyright © 2012, Juniper Networks, Inc. 619

Junos OS 12.1 MPLS Applications Configuration Guide

retransmit-interval

Syntax retransmit-interval seconds;

Hierarchy Level [edit logical-systems logical-system-name protocols ospf area area-number

peer-interface peer-interface-name],
[edit protocols ospf area area-number peer-interface peer-interface-name]

Release Information Statement introduced before Junos OS Release 7.4.

Description Specify how long the router waits to receive a link-state acknowledgment packet before
retransmitting link-state advertisements to a peer interface’s neighbors.

Options seconds—Interval to wait for a link-state acknowledgment packet.

Range: 1 through 65,535
Default: 5 seconds

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring RSVP and OSPF for LMP Peer Interfaces on page 593
Documentation

retry-limit

Syntax retry-limit number;

Hierarchy Level [edit logical-systems logical-system-name protocols link-management peer peer-name

lmp-protocol],
[edit protocols link-management peer peer-name lmp-protocol]

Release Information Statement introduced in Junos OS Release 8.1.

Description Specify how many times the Link Management Protocol (LMP) sends Config and
LinkSummary messages on the LMP control channel without receiving an appropriate
acknowledgment before it logs a message and restarts the LMP control channel
configuration process.

Options number—Maximum number of times messages are sent without receiving an

acknowledgment.
Range: 3 through 1000
Default: 3

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • retransmission-interval on page 619

Documentation
• Controlling Message Exchange for LMP Control Channels on page 591

620 Copyright © 2012, Juniper Networks, Inc.

 Chapter 23: Summary of GMPLS Configuration Statements

te-link

Syntax te-link te-link-name {

disable;
interface interface-name {
disable;
local-address ip-address;
remote-address ip-address;
remote-id id-number;
}
local-address ip-address;
remote-address ip-address;
remote-id id-number;
}

Hierarchy Level [edit logical-systems logical-system-name protocols link-management],

[edit logical-systems logical-system-name protocols link-management peer peer-name],
[edit protocols link-management],
[edit protocols link-management peer peer-name]

Release Information Statement introduced before Junos OS Release 7.4.

Description Represent a collection of physical ports or time slots. Assign a traffic engineering link to
the specified network peer.

Options te-link-name—Name of the collection of physical ports or the name of the time slots.

disable—Disable the traffic engineering link or an interface to a traffic engineering link.

The other statements are described separately in this chapter.

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring LMP Traffic Engineering Links on page 586

Documentation

Copyright © 2012, Juniper Networks, Inc. 621

Junos OS 12.1 MPLS Applications Configuration Guide

traceoptions

Syntax traceoptions {
file filename <files number> <size size> <world-readable | no-world-readable>;
flag flag <flag-modifier> <disable>;
}

Hierarchy Level [edit logical-systems logical-system-name protocols link-management],

[edit protocols link-management]

Release Information Statement introduced before Junos OS Release 7.4.

Support for hello-packets, packets, and state flags added in Junos OS Release 8.1.

Description Trace options for the LMP protocol.

Options disable—(Optional) Disable the tracing operation. You can use this option to disable a
single operation when you have defined a broad group of tracing operations, such
as all.

filename—Name of the file to receive the output of the tracing operation. Enclose the
name within quotation marks. All files are placed in the directory /var/log.

files number—(Optional) Maximum number of trace files. When a trace file named
trace-file reaches its maximum size, it is renamed trace-file.0, then trace-file.1, and
so on, until the maximum number of trace files is reached. Then the oldest trace file
is overwritten.
Range: 2 through 1000
Default: 2 files

If you specify a maximum number of files, you must also include the size statement to
specify the maximum file size.

flag—Tracing operation to perform. To specify more than one tracing operation, include
multiple flag statements.

• all—Trace all available operations

• hello-packets—Trace hello packets on any LMP control channel

• init—Output from the initialization messages

• packets—Trace all packets other than hello packets on any LMP control channel

• parse—Operation of the parser

• process—Operation of the general configuration

• route-socket—Operation of route socket events

• routing—Operation of the routing protocols

• server—Server processing operations

• show—show command servicing operations

622 Copyright © 2012, Juniper Networks, Inc.

 Chapter 23: Summary of GMPLS Configuration Statements

• state—Trace state transitions of the LMP control channels and traffic engineering links

flag-modifier—(Optional) Modifier for the tracing flag. You can specify one or more of
these modifiers:

• detail—Provide detailed trace information

• receive—Packets being received

• send—Packets being transmitted

no-world-readable—(Optional) Prevent all users from reading the log file.

size size—(Optional) Maximum size of each trace file, in kilobytes (KB), megabytes (MB),
or gigabytes (GB). When a trace file named trace-file reaches this size, it is renamed
trace-file.0. When the trace-file again reaches this size, trace-file.0 is renamed
trace-file.1 and trace-file is renamed trace-file.0. This renaming scheme continues
until the maximum number of trace files is reached. Then the oldest trace file is
overwritten.
Syntax: xk to specify KB, xm to specify MB, or xg to specify GB
Range: 10 KB through the maximum file size supported on your system
Default: 1 MB

If you specify a maximum file size, you must also include the files statement to specify
the maximum number of files.

world-readable—(Optional) Enable log file access for all users.

Required Privilege routing and trace—To view this statement in the configuration.
Level routing-control and trace-control—To add this statement to the configuration.

Related • Tracing LMP Traffic on page 595

Documentation
• Junos OS Network Management Configuration Guide

Copyright © 2012, Juniper Networks, Inc. 623

Junos OS 12.1 MPLS Applications Configuration Guide

transit-delay

Syntax transit-delay seconds;

Hierarchy Level [edit logical-systems logical-system-name protocols ospf area area-number

peer-interface peer-interface-name],
[edit protocols ospf area area-number peer-interface peer-interface-name]

Release Information Statement introduced before Junos OS Release 7.4.

Description Set the estimated time required to transmit a link-state update on the peer interface.
When calculating this time, you should account for transmission and propagation delays.

Options seconds—Estimated time for transmitting the link-state update.

Range: 1 through 65,535
Default: 1 second

Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.

Related • Configuring RSVP and OSPF for LMP Peer Interfaces on page 593
Documentation

624 Copyright © 2012, Juniper Networks, Inc.

PART 7

Indexes
• Index on page 627
• Index of Statements and Commands on page 647

Copyright © 2012, Juniper Networks, Inc. 625

Junos OS 12.1 MPLS Applications Configuration Guide

626 Copyright © 2012, Juniper Networks, Inc.

 admin-groups-extended statement..............................281
usage guidelines............................................................173
admin-groups-extended-range statement...............282
usage guidelines............................................................173
administrative groups
Index admin-groups statement.........................................279
configuration....................................................................171
exclude statement......................................................298
Symbols extended..........................................................................173
#, comments in configuration statements................xxxii fast reroute......................................................................152
( ), in syntax descriptions.................................................xxxii include-all statement.................................................310
< >, in syntax descriptions................................................xxxi include-any statement...............................................312
[ ], in configuration statements.....................................xxxii advertisement messages, LDP......................................468
{ }, in configuration statements.....................................xxxii advertisement-hold-time statement...........................283
| (pipe), in syntax descriptions.......................................xxxii usage guidelines...........................................................186
aggregate statement
A RSVP................................................................................426
adaptive rerouting........................................................178, 273 usage guidelines.................................................395
adaptive statement.............................................................273 aggregated Ethernet interfaces......................................546
usage guidelines............................................................178 aggregated interfaces............................................................41
address (tracing flag).........................................................532 aggregation, RSVP...............................................................426
address statement all (tracing flag)....................................................................368
LMP...................................................................................607 LMP...................................................................................622
usage guidelines.................................................589 RSVP.................................................................................457
addresses allocation of labels.................................................................28
associating with LSPs........................................154, 315 allow-fragmentation statement....................................283
egress router address........................................148, 367 usage guidelines...........................................................418
ingress router........................................................147, 306 allow-subnet-mismatch statement.............................503
adjust-interval statement.................................................274 usage guidelines...........................................................501
usage guidelines...........................................................165 always-mark-connection-protection-tlv
adjust-threshold statement.............................................274 statement...........................................................................284
usage guidelines...........................................................166 usage guidelines..........................................................403
adjust-threshold-overflow-limit statement...............275 ARP configuration...............................................................560
usage guidelines............................................................167 associate-backup-pe-groups statement...................284
adjust-threshold-underflow-limit statement............275 usage guidelines..........................................................226
usage guidelines............................................................167 associate-lsp
Admin Status object, GMPLS..........................................597 usage guidelines...........................................................130
admin-down statement.....................................................276 associate-lsp statement
configuration guidelines............................................597 MPLS-TP........................................................................285
admin-group statement ATM
bypass LSPs..................................................................425 circuits...................................................................544, 552
configuration ATM encapsulation
bypass LSPs.........................................................406 Layer 2 TCC....................................................................558
LSPs..................................................................................278 authentication
MPLS interfaces............................................................277 RSVP.......................................................................398, 427
admin-group-extended statement..............................280
usage guidelines............................................................173
admin-groups statement..................................................279
usage guidelines.............................................................171

Copyright © 2012, Juniper Networks, Inc. 627

Junos OS 12.1 MPLS Applications Configuration Guide

authentication-key statement bandwidth-model statement.........................................290

LDP...................................................................................504 usage guidelines...........................................................194
usage guidelines.................................................498 bandwidth-percent statement........................................291
RSVP.................................................................................427 usage guidelines................................................205, 208
usage guidelines.................................................398 BFD
auto-bandwidth statement.............................................285 ECMP paths..................................................................488
usage guidelines...........................................................165 fast reroute....................................................................268
auto-policing statement...................................................286 LDP LSPs.............................................................486, 488
usage guidelines..........................................................262 revert timer......................................................................351
automatic bandwidth allocation.............................51, 285 RSVP LSPs...........................................................267, 269
bandwidth monitoring...............................................169 bfd-liveness-detection statement
LSPs...................................................................................163 LDP LSPs........................................................................505
manually trigger............................................................169 usage guidelines.................................................486
threshold.........................................................................166 RSVP LSPs.....................................................................292
automatic mesh, RSVP.......................................................415 usage guidelines.................................................268
automatic policers BGP
LSP bandwidth, changing........................................264 destinations......................................................................42
LSPs..................................................................................263 binding (tracing flag)..........................................................532
overview..........................................................................262 braces, in configuration statements............................xxxii
point-to-multipoint LSPs.........................................264 brackets
automatic reoptimization, bypass LSPs......................410 angle, in syntax descriptions...................................xxxi
square, in configuration statements...................xxxii
B branch LSPs............................................................................222
backup paths............................................................................35 bypass LSPs...........................................................................405
backup-pe-group statement...........................................287 administrative groups...............................................406
bandwidth bandwidth......................................................................407
automatic allocation, LSPs......................................163 bandwidth subscription..............................................411
LSP paths........................................................................184 class-of-service...........................................................407
RSVP reservations......................................................456 CSPF, disabling............................................................409
bandwidth model.................................................................194 explicit paths.................................................................410
bandwidth oversubscription hop limit.........................................................................408
overview...........................................................................197 maximum number.....................................................408
bandwidth statement multiple...........................................................................387
fast reroute....................................................................288 node protection, disabling......................................409
usage guidelines...................................................152 optimization interval.................................................409
link protection...............................................................428 priority and preemption..............................................411
usage guidelines.................................................407 switching away from a network node.................403
LSPs types.................................................................................387
usage guidelines.................................................204 bypass statement
MPLS RSVP................................................................................429
usage guidelines...................................................214 static LSP.............................................................293, 430
multiclass LSPs...........................................................288 usage guidelines..........................................................405
usage guidelines..................................................207
RSVP................................................................................428 C
signaled LSPs...............................................................288 CCC
usage guidelines..................................................184 aggregated Ethernet..................................................546
static LSPs.....................................................................289 BPDUs, nonstandard.................................................540
usage guidelines (ingress router)...................211 encapsulation
bandwidth update threshold..........................................399 Ethernet CCC........................................................545

628 Copyright © 2012, Juniper Networks, Inc.

 Index

example configurations........................549, 554, 556 CoS.............................................................................................194

graceful restart Differentiated Services..............................................202
configuration........................................................562 CoS requests using RSVP..................................................376
overview..................................................................541 CoS values................................................................................176
Layer 2 switching cross-connects cross-connect, circuit See CCC
configuration........................................................543 cspf (tracing flag)................................................................368
overview.................................................................539 CSPF algorithm
LSP stitching cross-connects.......................539, 555 fate-sharing.....................................................................60
MPLS tunneling offline path computation.......................................6, 34
cross-connects............................539, 551, 553, 576 online path computation.............................................32
overview..........................................................................539 disabling........................................................170, 329
ping CCC LSPs................................................................271 overview...............................................................................6
point-to-multipoint LSPs......................562, 574, 575 cspf-link (tracing flag).......................................................368
traffic policing...............................................................539 cspf-node (tracing flag)....................................................368
Cisco HDLC circuits.............................................................544 curly braces, in configuration statements..................xxxii
Cisco HDLC encapsulation customer support................................................................xxxii
Layer 2 switching cross-connect...........................557 contacting JTAC..........................................................xxxii
class types
bandwidth subscription.............................................201 D
class-of-service statement damping
bypass LSPs...................................................................431 LSP transitions..............................................................186
usage guidelines.................................................407 dead-interval statement..................................................608
ingress routers..............................................................294 usage guidelines..........................................................593
usage guidelines....................................................211 deaggregate statement....................................................506
signaled LSPs...............................................................294 usage guidelines..........................................................484
usage guidelines...................................................176 description statement
static LSPs.....................................................................294 MPLS................................................................................295
colored links............................................................152, 171, 279 usage guidelines..........................................152, 214
comments, in configuration statements....................xxxii static LSPs
connection (tracing flag)..................................................368 usage guidelines (ingress router)...................211
connection-detail (tracing flag)....................................368 detail (tracing flag modifier)
connections statement.....................................................566 LDP....................................................................................533
complete hierarchy under............................................10 LMP...................................................................................623
TCC RSVP................................................................................458
usage guidelines.................................................560 detours See fast reroute
Constrained Shortest Path First algorithm See CSPF Differentiated Services
algorithm bandwidth model........................................................194
constrained-path LSPs extended MAM..............................................................194
computation interface bandwidth constraints...........................202
CSPF algorithm......................................................32 LSPs..................................................................................190
disabling........................................................170, 329 MAM..................................................................................194
overview....................................................................32 RDM...................................................................................194
example configuration.........................................60, 62 diffserv-te statement.........................................................296
overview..............................................................................31 usage guidelines...........................................................193
scope...................................................................................32 disable (tracing flag modifier)........................................533
control-channel statement.............................................608 disable option to traceoptions statement
usage guidelines..........................................................589 LDP....................................................................................532
conventions LMP...................................................................................622
text and syntax.............................................................xxxi RSVP.................................................................................457

Copyright © 2012, Juniper Networks, Inc. 629

Junos OS 12.1 MPLS Applications Configuration Guide

disable statement error (tracing flag)

GMPLS............................................................................609 LDP....................................................................................532
usage guidelines.................................................592 MPLS................................................................................368
LDP....................................................................................507 RSVP.................................................................................457
usage guidelines..................................................472 ether-pseudowire statement..........................................303
link protection...............................................................432 Ethernet extended VLAN TCC, ARP
usage guidelines.................................................402 configuration.....................................................................560
MPLS................................................................................297 Ethernet TCC
usage guidelines...................................................170 ARP configuration......................................................560
OSPF...............................................................................609 ethernet-ccc encapsulation type...................................545
usage guidelines.................................................593 event (tracing flag)
RSVP.................................................................................432 LDP....................................................................................532
usage guidelines.................................................393 RSVP.................................................................................457
RSVP graceful restart.................................................432 exclude statement..............................................................298
usage guidelines..................................................413 administrative groups
discovery messages, LDP..................................................467 usage guidelines....................................................171
distinct reservations.............................................................381 fast reroute
documentation usage guidelines...................................................152
comments on...............................................................xxxii exclude-srlg
DSCP usage guidelines.............................................85, 90, 110
MPLS-tagged packets..............................................266 exclude-srlg statement.....................................................300
dynamic LSP metric.............................................................156 EXP and IP precedence bits.............................................267
EXP bits............................................................28, 176, 177, 258
E DSCP values..................................................................266
ECMP paths rewrite..............................................................................266
BFD...................................................................................488 EXP rewrite rule.......................................................................177
ecmp statement..................................................................508 expand-loose-hop statement.........................................301
usage guidelines..........................................................488 usage guidelines..........................................................253
egress policy, loopback address....................................483 experimental bits See EXP bits
egress routers Explicit Null label....................................................................28
example configuration...............................................216 Explicit Route object.................................................................7
overview............................................................................30 explicit routes.............................................................................6
signaled LSPs................................................................148 explicit senders, RSVP.........................................................381
static LSPs.............................................................214, 316 explicit-null statement
egress-policy statement...................................................508 LDP...................................................................................509
usage guidelines..........................................................483 usage guidelines.................................................496
empty paths...........................................................................340 MPLS.................................................................................301
encapsulation usage guidelines.................................................249
CCC...................................................................................543 RSVP.................................................................................301
TCC....................................................................................557 usage guidelines..................................................419
encapsulation statement usage guidelines..........................................................249
Layer 2 switching cross-connect...........................567 explicit-path LSPs
usage guidelines.................................................544 computation, disabling....................................170, 329
LSP tunnel cross-connect........................................567 configuring......................................................................218
usage guidelines..................................................552 example configuration..................................................61
TCC....................................................................................567 overview..............................................................................31
usage guidelines..................................................557 scope...................................................................................32
encoding-type statement.................................................297 export statement.................................................................509
usage guidelines..........................................................596 usage guidelines.........................................................480

630 Copyright © 2012, Juniper Networks, Inc.

 Index

extended administrative groups......................................173 forwarding next hop..............................................................44

extended MAM............................................................194, 290 Frame Relay circuits...................................................547, 552
Frame Relay encapsulation
F Layer 2 TCC....................................................................558
facility backup.......................................................................385 from statement
failed LSPs MPLS...............................................................................306
fast reroute..........................................46, 152, 288, 304 usage guidelines...................................................147
standby secondary paths...........................................46
failure-action statement G
LDP LSPs.........................................................................510 Generalized MPLS See GMPLS
usage guidelines.................................................488 GMPLS
RSVP LSPs.....................................................................302 Admin Status object...................................................597
usage guidelines.................................................269 configuration.................................................................585
family mpls statement.......................................................303 configuration statements........................................607
usage guidelines...........................................................158 graceful deletion timeout interval........................599
fast reroute.............................................................................385 graceful LSP teardown.............................................598
BFD...................................................................................268 non-packet LSPs.........................................................597
configuring.....................................................................304 overview..........................................................................579
detours...............................................................................47 permanent LSP deletion..........................................598
multiclass LSPs...........................................................208 RSVP LSP hierarchy....................................................601
overview....................................................................46, 152 supported software standards..............................579
path optimization.........................................................154 temporary LSP deletion...........................................598
path optimization overview.........................................51 gpid statement......................................................................307
PFE fast reroute....................................................152, 414 usage guidelines..........................................................595
soft preemption............................................................162 graceful deletion timeout interval.................................599
traffic-engineered LSPs............................................205 graceful restart
fast-reroute statement......................................................304 LDP......................................................................................511
RSVP................................................................................433 point-to-multipoint LSPs.........................................224
usage guidelines..................................................154 RSVP................................................................................434
fate-sharing graceful teardown, GMPLS LSPs...................................598
CSPF algorithm..............................................................60 graceful-deletion-timeout statement.........................433
example configuration................................................60 usage guidelines..........................................................599
overview.............................................................................35 graceful-restart (tracing flag).........................................369
signaled LSPs........................................................58, 305 graceful-restart statement
fate-sharing statement.....................................................305 LDP......................................................................................511
usage guidelines.............................................................58 usage guidelines..................................................476
FECs................................................................................463, 489 RSVP................................................................................434
FF (reservation style)...........................................................381 usage guidelines..................................................413
filtering received labels.............................................478, 516 GRE tunnels..............................................................................66
fixed-filter reservation style..............................................381 groups
font conventions...................................................................xxxi administrative...................152, 171, 279, 298, 310, 312
forwarding See MPLS
forwarding adjacency H
configuration.................................................................603 headers, MPLS and IPv4....................................................267
LSP...................................................................................604 hello acknowledgments
OSPF configuration....................................................605 RSVP.................................................................................401
peer router address....................................................603 hello interval
RSVP configuration....................................................604 LDP...........................................................................472, 512
forwarding equivalence classes See FECs RSVP......................................................................398, 435

Copyright © 2012, Juniper Networks, Inc. 631

Junos OS 12.1 MPLS Applications Configuration Guide

hello messages.....................................................................467 IGP

interface..........................................................................398 advertising LSPs............................................................40
node ID.............................................................................401 destinations.....................................................................44
hello packets shortcuts
RSVP.................................................................................379 enabling....................................................................38
hello-acknowledgements statement..........................435 LSP metrics...........................................................156
RSVP overview....................................................................37
usage guidelines..................................................401 qualified LSPs........................................................38
hello-dead-interval statement........................................610 routing tables..........................................................39
usage guidelines..........................................................590 uses of.......................................................................39
hello-interval statement IGP synchronization, LDP.................................................500
LDP.....................................................................................512 igp-synchronization statement.......................................515
usage guidelines..................................................472 usage guidelines.........................................................500
LMP.....................................................................................611 Implicit Null label....................................................................28
usage guidelines.................................................590 import statement
OSPF.................................................................................612 LDP....................................................................................516
usage guidelines.................................................594 usage guidelines.................................................478
RSVP................................................................................435 include statement
usage guidelines.................................................398 fast reroute
hello-packets (tracing flag) usage guidelines...................................................152
LMP...................................................................................622 include-all statement..........................................................310
helper-disable statement administrative groups
LDP.....................................................................................513 usage guidelines....................................................171
usage guidelines..................................................476 include-any statement........................................................312
RSVP administrative groups
usage guidelines..................................................413 usage guidelines....................................................171
hold priority..............................................................................179 inet.0 routing table
hold time IGP shortcuts...................................................................39
LDP...........................................................................473, 514 MPLS..................................................................................45
signaled LSPs......................................................186, 283 inet.3 routing table
hold-time statement IGP shortcuts...................................................................39
LDP....................................................................................514 MPLS..................................................................................45
usage guidelines..................................................473 routes, installing............................................................154
holddown-interval statement..........................................513 information distribution, traffic engineering...................5
usage guidelines..........................................................489 ingress routers
hop-limit statement.................................................308, 436 address configuration.......................................147, 306
usage guidelines................................................184, 408 configuring for static LSPs.........................................211
host routes........................................................................42, 154 example configurations..............................................213
hot-standby state.................................................................185 overview............................................................................30
path connection retry
I information............................................155, 349, 350
ICMP ingress statement
message tunneling, MPLS..........................................76 static LSP........................................................................314
icmp-tunneling statement...............................................309 ingress static LSPs.................................................................211
usage guidelines.............................................................76 ingress-policy statement...................................................516
icons defined, notice............................................................xxx usage guidelines..........................................................489
IEEE 802.p rewrite rule.........................................................177 init (tracing flag)
ignore-lsp-metrics statement..........................................515 LMP...................................................................................622
usage guidelines..........................................................497 initialization (tracing flag).................................................532

632 Copyright © 2012, Juniper Networks, Inc.

 Index

install statement L
MPLS.................................................................................315 l2-smart-policy statement................................................519
usage guidelines..................................................154 usage guidelines..........................................................485
static LSPs label (tracing flag)...............................................................533
usage guidelines (ingress router)...................211 Label Distribution Protocol See LDP
Integrity object.......................................................................378 label filtering.................................................................478, 516
inter-area traffic engineering...........................................253 Label object.................................................................................7
Inter-domain point-to-multipoint LSPs......................245 Label Request object...............................................................7
interface (from operator, LDP).......................................478 label-switched paths See LSPs
interface statement label-switched-path statement
LDP.....................................................................................517 GMPLS..............................................................................613
usage guidelines..................................................472 MPLS..................................................................................317
LMP....................................................................................612 usage guidelines..................................................144
usage guidelines.................................................585 MPLS with RSVP...........................................................317
RSVP.................................................................................437 usage guidelines.................................................394
usage guidelines.................................................393 usage guidelines.........................................................604
static LSPs......................................................................316 label-withdrawal-delay statement...............................519
interface-switch statement..............................................572 usage guidelines.........................................................500
Layer 2 switching cross-connects labeled-unicast statement
usage guidelines.................................................548 usage guidelines..........................................................249
usage guidelines..........................................................548 labels
interfaces allocation..........................................................................28
aggregated.........................................................................41 numerical ranges............................................................27
interior gateway protocol See IGP operations..............................................................30, 466
intermediate routers overview......................................................................23, 24
configuring for static LSPs...............................214, 316 properties..........................................................................211
example configurations.............................................215 reserved labels................................................................28
intraregion LSPs......................................................................39 stacks.................................................................................28
IP packets over aggregated interfaces............................41 swapping.............................................................................4
IPv4 Explicit Null label..........................................................28 values..................................................................................27
IPv6 Layer 2 switching
Implicit Null label...........................................................28 MPLS.................................................................................561
tunneling over MPLS.....................................................67 TCC...................................................................................560
ipv6-tunneling statement..................................................316 Layer 2 switching cross-connect
CCC connections.........................................................548
K CCC encapsulation.....................................................544
keep multiplier, RSVP................................................416, 438 configuration.................................................................543
keep-multiplier statement...............................................438 configuring MPLS........................................................549
usage guidelines...........................................................416 example configuration..............................................549
keepalive-interval statement...........................................518 overview..........................................................................539
usage guidelines...........................................................475 TCC encapsulation......................................................557
keepalive-timeout statement..........................................518 Layer 2 VPNs
usage guidelines...........................................................475 aggregated Ethernet..................................................546
keepalives LDP
interval....................................................................475, 518 BFD........................................................................486, 488
timeout...................................................................475, 518 carrier-of-carriers VPNs...........................................496
configuration statements........................................503
configuring.............................................................517, 520
disabling................................................................472, 507

Copyright © 2012, Juniper Networks, Inc. 633

Junos OS 12.1 MPLS Applications Configuration Guide

ECMP-aware BFD.......................................................488 least-fill tie-breaking rule..................................34, 157, 348

egress policy.................................................................483 link attributes considered by CSPF algorithm..............32
enabling...........................................................................472 link coloring.............................................................152, 171, 279
example configuration link hello messages, LDP....................................................512
received label filtering......................................480 link protection.............................................................385, 402
tracing.....................................................................494 bypass LSPs
Explicit Null label...............................................419, 496 administrative groups......................................406
FEC policers..................................................................484 multiple bypass LSPs................................................408
graceful restart...........................................469, 476, 511 RSVP................................................................................386
hello interval..........................................................472, 512 soft preemption............................................................162
hello messages.............................................................467 static LSPs.....................................................................402
hold time................................................................473, 514 switching away from a network node.................403
IGP synchronization...................................................500 link-layer protocols................................................................26
Implicit Null label...............................................419, 496 link-management statement...........................................613
Junos implementation..............................................464 complete hierarchy under............................................12
keepalive usage guidelines..........................................................585
interval...........................................................475, 518 link-protection statement
timeout..........................................................475, 518 MPLS
label operations..........................................................466 usage guidelines...............................214, 223, 402
message types..............................................................467 RSVP................................................................................439
metrics............................................................................496 usage guidelines.................................................404
minimum configuration.............................................472 signaled LSPs...............................................................320
multiple instances......................................................496 static LSPs.......................................................................321
OAM ingress policy.....................................................489 usage guidelines (ingress router)...................211
OAM periodic traceroute..........................................490 LMP
operations......................................................................465 peer network device configuration.......................588
overview..........................................................................463 tracing protocol operations.....................................622
policy filters....................................................................516 tracing protocol traffic..............................................595
received label filtering.......................................478, 516 traffic engineering links.............................................585
route preferences...............................................476, 528 lmp (tracing flag).................................................................457
session protection lmp-control-channel statement.....................................614
configuration........................................................499 usage guidelines..........................................................589
overview................................................................468 lmp-protocol statement....................................................614
supported software standards..............................464 load balancing
synchronization with the IGP.................................499 MPLS LSPs.....................................................................158
targeted hello messages..........................................467 load-balance statement...................................................440
timer.........................................................................472, 512 usage guidelines...........................................................414
tracing operation of..........................................493, 532 local-address statement
tunneling through RSVP LSPs.............319, 465, 497 link management.........................................................615
ultimate-hop popping...........................419, 496, 509 usage guidelines..................................................587
ldp statement........................................................................520 usage guidelines..........................................................603
complete hierarchy under............................................10 log-updown statement
usage guidelines...........................................................472 LDP.....................................................................................521
ldp-synchronization statement.......................................521 usage guidelines.................................................499
usage guidelines..........................................................499 MPLS................................................................................322
ldp-tunneling statement....................................................319 usage guidelines..................................................257
usage guidelines..........................................................497 logical-router See logical-system
least-fill statement.............................................................348 logical-routers See logical-systems
usage guidelines............................................................157 loopback address, egress policy....................................483

634 Copyright © 2012, Juniper Networks, Inc.

 Index

loose explicit routes.........................................................6, 218 intermediate routers...........................................214, 316

LSP graceful teardown......................................................598 intraregion LSPs.............................................................39
LSP metric...............................................................................252 load balancing...............................................................158
lsp-attributes statement...................................................323 metrics....................................................................156, 325
usage guidelines..........................................................595 MPLS routers, configuring..........................................63
lsp-ping-interval statement multiple bypass............................................................387
LDP LSPs........................................................................524 named paths.........................................................56, 340
RSVP LSPs.....................................................................336 OAM configuration......................................................267
lsp-switch statement..........................................................573 overview........................................................................4, 27
usage guidelines..........................................................555 packet traversal...........................................................5, 31
lsping (tracing flag).............................................................369 path
LSPs bandwidth..............................................................184
adaptive rerouting...............................................178, 273 calculation..................................................................3
administrative groups connection retry
admin-group statement...................................277 information....................................155, 349, 350
admin-groups statement................................279 length............................................................184, 308
configuring...............................................................171 smart optimize timer.........................................183
exclude statement.............................................298 pings.................................................................................270
fast reroute.............................................................152 ping interval, LDP................................................487
advertising in IGPs.........................................................40 ping interval, RSVP............................................269
associating addresses.......................................154, 315 policing............................................................................260
attributes considered by CSPF algorithm.............32 preemption............................................................179, 345
automatic bandwidth allocation..........................285 preference levels.................................................175, 343
automatic policers......................................................263 primary...................................................................149, 344
bandwidth priorities..................................................................179, 345
maximum bounds...............................................166 recording routes.............................................................175
minimum bounds................................................166 reoptimization............................................180, 337, 338
BFD configuration........................................................267 router functions..............................................................30
bypass.............................................................................402 routing options...................................................................7
configuration statements.................................144, 317 RSVP-signaled.................................................................31
configuring.....................................................................204 scope of.............................................................................32
constrained-path See constrained-path LSPs secondary..............................................................149, 354
CoS values.......................................................................176 signaled See signaled LSPs
creating............................................................................144 soft preemption............................................................162
damping LSP transitions...........................................186 standby secondary paths...........................................46
description, textual......................................................152 standby state.......................................................185, 359
differentiated service aware....................................190 static See static LSPs
egress routers......................................148, 214, 216, 316 stitching cross-connects................................539, 555
explicit-path See explicit-path LSPs switching away from a network node.................403
failure of............................................................................46 text description............................................................295
fast reroute..........................................46, 152, 288, 304 tie-breaking rules.........................................34, 157, 348
fate-sharing....................................................35, 58, 305 traffic engineering, configuring..............................250
forwarding next hops TTL decrementing, disabling................161, 330, 333
selecting...................................................................44 tunnel cross-connects, MTU....................................551
hold time...............................................................186, 283 tunneling through RSVP LSPs.............319, 465, 497
hop limit...........................................................................184
host routes........................................................................42 M
IGP shortcuts....................................................................37 MAM.................................................................................194, 290
ingress routers.....................................................147, 306

Copyright © 2012, Juniper Networks, Inc. 635

Junos OS 12.1 MPLS Applications Configuration Guide

manuals extended administrative groups.............................173

comments on...............................................................xxxii fast reroute..........................................46, 152, 288, 304
max-bypasses statement.................................................441 firewall filter...................................................................258
usage guidelines.........................................................408 GRE tunnels.....................................................................66
maximum-bandwidth statement..................................323 ICMP, tunneling...............................................................76
usage guidelines...........................................................166 IGP and BGP destinations..........................................44
maximum-labels statement............................................324 Implicit Null label........................................................249
maximum-neighbor-recovery-time IPv4 packet headers...................................................267
statement...........................................................................522 IPv6......................................................................................67
usage guidelines..........................................................478 label range.........................................................................27
maximum-recovery-time statement............................522 Layer 2 switching TCC................................................561
MD5 authentication............................................................398 link-layer protocols supported..................................26
messages load balancing...............................................................158
LDP message types....................................................467 LSP tunnel cross-connects
MPLS system log................................................257, 322 MTU..........................................................................551
Resv, RSVP....................................................................380 LSPs See LSPs
ResvConfirm, RSVP.....................................................381 OAM..................................................................................267
ResvErr, RSVP................................................................381 overview......................................................................23, 24
ResvTear, RSVP............................................................380 packets over aggregated interfaces.........................41
RSVP message types.................................................379 ping
RSVP PathErr...................................................................63 Layer 3 VPNs..........................................................271
RSVP refresh..................................................................416 LSP end points......................................................271
metric statement LSPs.........................................................................270
MPLS................................................................................325 routing tables..................................................................45
usage guidelines..................................................156 RSVP See RSVP
static LSPs signaled LSPs See signaled LSPs
usage guidelines (ingress router)...................211 smart optimize timer..................................................183
metrics SNMP traps...........................................................257, 322
dynamic LSP metric....................................................156 soft preemption............................................................162
LDP tracking IGP.........................................................496 standby secondary paths...........................................46
static LSP metric................................................156, 325 static..........................................................................211, 316
minimum-bandwidth statement...................................325 static LSPs See static LSPs
usage guidelines...........................................................166 statistics..........................................................................164
monitor-bandwidth statement......................................326 statistics output...........................................................256
usage guidelines...........................................................169 supported software standards.................................24
most-fill statement.............................................................348 system log messages........................................257, 322
usage guidelines............................................................157 tracing protocol operations............................271, 368
most-fill tie-breaking rule.................................34, 157, 348 traffic engineering........................................................252
MPLS..............................................................................................3 overview....................................................................27
aggregated interfaces...................................................41 traffic protection............................................................46
automatic bandwidth allocation..........................285 traffic statistics...................................................256, 362
backbones, packet traversal..................................5, 31 tunneling
BFD..........................................................................267, 269 CCC connection.........................................553, 576
BGP destinations...........................................................42 CCC encapsulation.............................................552
configuring........................................................................55 example configurations...................................554
CoS values.......................................................................176
DSCP and EXP values...............................................266
EXP bits...................................................28, 176, 177, 258
Explicit Null label.........................................................249

636 Copyright © 2012, Juniper Networks, Inc.

 Index

IPv6.............................................................................67 no-aggregate statement...................................................426

overview........................................................539, 551 usage guidelines..........................................................395
ultimate-hop popping......................................249, 301 no-cspf statement....................................................329, 444
See also LDP, LSPs, RSVP, traffic engineering usage guidelines.................................................170, 409
database no-decrement-ttl statement..........................................330
mpls statement no-forwarding statement..................................................523
Layer 2 switching cross-connect...........................326 usage guidelines..........................................................496
usage guidelines.................................................549 no-install-to-address statement....................................331
Layer 2 switching TCC................................................561 static LSPs
MPLS................................................................................326 usage guidelines (ingress router)...................211
complete hierarchy under...................................13 usage guidelines...........................................................148
usage guidelines....................................................55 no-interface-hello statement.........................................444
mpls transport profile oam RSVP
overview...........................................................................129 usage guidelines..................................................401
mpls-tp-mode no-local-reversion statement.........................................442
usage guidelines...........................................................130 no-mcast-replication statement....................................331
mpls-tp-mode statement no-neighbor-down-notification statement...............445
MPLS-TP.........................................................................327 usage guidelines..........................................................420
mpls.0 routing table..............................................................45 no-node-id-subobject statement.................................445
MTU signaling, in RSVP......................................................383 usage guidelines..........................................................404
mtu-signaling statement...................................................327 no-node-protection statement
usage guidelines...........................................................418 usage guidelines.........................................................409
multicast no-p2mp-sublsp statement...........................................446
RPF check policy..........................................................224 usage guidelines...........................................................227
multiclass LSPs no-propagate-ttl statement............................................333
bandwidth subscription.............................................201 no-record statement..........................................................349
configuring......................................................................207 usage guidelines............................................................175
fast reroute....................................................................208 no-reliable statement........................................................452
multiple bypass LSPs..........................387, 405, 407, 408 usage guidelines..........................................................395
multiple push (label operation)........................................30 no-trap statement...............................................................334
usage guidelines...........................................................257
N no-world-readable option to traceoptions
named paths statement
empty paths..................................................................340 LDP....................................................................................533
example configuration.................................................58 LMP...................................................................................623
overview............................................................................56 MPLS................................................................................369
neighbor (from operator, LDP).......................................478 RSVP................................................................................458
next hop (from operator, LDP)........................................478 node ID hellos, RSVP...........................................................401
next hops node protection...........................................................385, 387
selecting............................................................................44 soft preemption............................................................162
next-hop bypass LSP..........................................................387 static LSPs.....................................................................402
next-hop statement............................................................328 switching away from a network node.................403
MPLS node-hello statement........................................................443
usage guidelines...................................................214 RSVP
static LSPs usage guidelines..................................................401
usage guidelines (ingress router)...................211 node-link-protection statement....................................446
next-next-hop bypass LSP...............................................387 usage guidelines..........................................................402
no-adjacency-down-notification statement............443
configuration guidelines...........................................420

Copyright © 2012, Juniper Networks, Inc. 637

Junos OS 12.1 MPLS Applications Configuration Guide

node-protection statement p2mp-lsp-next-hop statement......................................339

MPLS RSVP
usage guidelines...................................................214 usage guidelines..................................................227
static LSPs............................................................332, 335 usage guidelines............................................................217
usage guidelines (ingress router)...................211 p2mp-receive-switch statement....................................574
notice icons defined.............................................................xxx usage guidelines..........................................................563
notification (tracing flag)..................................................533 p2mp-transmit-switch statement.................................575
notification messages usage guidelines..........................................................562
LDP...................................................................................468 packet forwarding component
nsr-synchronization (tracing flag).................................369 traffic engineering............................................................4
nsr-synchronization-detail (tracing flag)...................369 packet headers, MPLS and IPv4.....................................267
packet traversal on LSPs..................................................5, 31
O packets (tracing flag)
OAM LDP....................................................................................533
ingress policy for LDP LSPs....................................489 LMP...................................................................................622
OAM periodic traceroute, LDP........................................490 RSVP.................................................................................457
oam statement parentheses, in syntax descriptions.............................xxxii
LDP LSPs........................................................................524 parser (tracing flag)
usage guidelines.................................................486 LMP...................................................................................622
RSVP LSPs.....................................................................336 passive statement................................................................615
usage guidelines.................................................268 usage guidelines..........................................................592
OAM, MPLS.............................................................................267 path
offline path calculation....................................................6, 34 bandwidth, LSP............................................................184
one-to-one backup.............................................................385 calculation
operations on labels..............................................................30 constrained-path computation............170, 329
optimize-aggressive statement......................................337 CSPF algorithm.................................................6, 32
usage guidelines...........................................................180 offline path computation..............................6, 34
optimize-timer statement routing options..........................................................7
bypass LSPs...................................................................447 tie-breaking rules................................34, 157, 348
usage guidelines.................................................409 connection retry information...............155, 349, 350
MPLS................................................................................338 length, LSP...........................................................184, 308
usage guidelines..................................................180 selection component, traffic engineering...............6
optimizing LSPs.................................................180, 337, 338 path (tracing flag)
OSPF LDP....................................................................................533
hello interval...................................................................612 RSVP.................................................................................457
inter-area traffic engineering..................................253 path messages, RSVP........................................................380
link-state path optimization
advertisements...................................................620 fast reroute.....................................................................154
LSP metric advertisement.......................................252 path selection..........................................................................151
router dead interval...................................................608 path statement
outgoing MTU value in RSVP MPLS...............................................................................340
determining...................................................................384 RSVP................................................................................448
usage guidelines..................................................410
P path-mtu statement...................................................341, 418
p2mp statement.........................................................339, 525 PathErr messages..........................................................63, 381
usage guidelines...........................................................222 pathtear (tracing flag)........................................................457
PathTear messages, RSVP...............................................380
peer network device configuration...............................588

638 Copyright © 2012, Juniper Networks, Inc.

 Index

peer statement pop statement

LMP...................................................................................616 MPLS................................................................................342
usage guidelines.................................................588 usage guidelines...................................................214
peer-interface statement PPP circuits
OSPF..................................................................................617 Layer 2 switching cross-connects........................544
usage guidelines.................................................593 preemption
RSVP................................................................................449 LSPs...................................................................................162
usage guidelines.................................................593 RSVP sessions...............................................................417
usage guidelines...............................................604, 605 signaled LSPs.......................................................179, 345
periodic (tracing flag).........................................................533 preemption statement......................................................450
periodic-traceroute statement.......................................526 usage guidelines............................................................417
usage guidelines...............................................488, 490 preference levels
permanent GMPLS LSP deletion..................................598 LDP routes............................................................476, 528
PFE fast reroute............................................................152, 414 signaled LSPs.......................................................175, 343
ping static LSPs........................................................................211
Layer 3 VPNs...................................................................271 preference statement
LSP end point.................................................................271 LDP...................................................................................528
LSPs..................................................................................270 usage guidelines..................................................476
point-to-multipoint LSP...........................................270 signaled LSPs................................................................343
PLP bit........................................................................................176 usage guidelines...................................................175
point-to-multipoint LSPs static LSPs.....................................................................343
automatic policers......................................................264 usage guidelines (ingress router)...................211
branch LSPs...................................................................222 primary LSPs.................................................................149, 344
dynamic..................................................................223 primary paths
static........................................................................223 revert timer.....................................................................150
CCC...................................................................................562 revert timer, BFD...........................................................351
configuration...................................................................221 selection............................................................................151
graceful restart......................................................53, 224 primary statement
GRES...................................................................................53 MPLS................................................................................344
inter-domain.................................................................245 usage guidelines..................................................149
link protection...............................................................223 priorities
overview.............................................................................52 signaled LSPs.......................................................179, 345
RPF check policy..........................................................224 priority statement
static routes.....................................................................217 MPLS................................................................................345
ultimate-hop popping...............................................420 usage guidelines...................................................179
with RSVP signaling....................................................227 RSVP.................................................................................451
policers usage guidelines............................................................411
LDP FECs........................................................................484 process (tracing flag).........................................................622
policing.................................................................260, 262, 539 protection-revert-time statement................................346
policing filter statement push (label operation).........................................................30
usage guidelines..........................................................260 push statement
policing statement......................................................341, 527 MPLS................................................................................347
static LSPs static LSPs
usage guidelines (ingress router)...................211 usage guidelines (ingress router)...................211
usage guidelines................................................262, 484
policy filters, LDP...................................................................516 R
pop (label operation)...........................................................30 random statement..............................................................348
usage guidelines............................................................157
random tie-breaking rule...................................34, 157, 348

Copyright © 2012, Juniper Networks, Inc. 639

Junos OS 12.1 MPLS Applications Configuration Guide

RDM.................................................................................194, 290 retransmission-interval statement................................619

receive (tracing flag modifier) usage guidelines...........................................................591
LDP....................................................................................533 retransmit-interval statement........................................620
LMP...................................................................................623 usage guidelines..........................................................593
RSVP................................................................................458 retry information...............................................155, 349, 350
received label filtering.........................................................516 retry-limit statement................................................349, 620
reconnect-time statement...............................................528 usage guidelines..................................................155, 591
usage guidelines...........................................................477 retry-timer statement........................................................350
Record Route object.............................................................175 usage guidelines...........................................................155
record statement.................................................................349 revert-timer statement.......................................................351
usage guidelines............................................................175 usage guidelines...........................................................150
recording routes......................................................................175 rewrite rules..............................................................................177
recovery-time statement..................................................529 IEEE 802.p and MPLS CoS........................................177
usage guidelines..........................................................478 MPLS and VPNs...........................................................267
refresh messages, RSVP....................................................416 route (tracing flag)..............................................................458
refresh reduction, RSVP.....................................................382 LDP....................................................................................533
refresh time, RSVP................................................................416 route preferences
refresh-time statement.....................................................452 LDP..........................................................................476, 528
usage guidelines...........................................................416 signaled LSPs.......................................................175, 343
reliable statement................................................................452 route-socket (tracing flag)
usage guidelines..........................................................395 LMP...................................................................................622
remote-address statement Router Alert label....................................................................28
control channel management routers
usage guidelines.................................................590 egress See egress routers
LMP control channel..................................................618 ingress See ingress routers
LMP traffic engineering..............................................618 label operations.............................................................30
usage guidelines................................................587, 603 LSP functions..................................................................30
remote-id statement transit.................................................................................30
link management.........................................................619 routes
usage guidelines.................................................588 recording...........................................................................175
remote-interface-switch statement.............................576 route preferences............................175, 343, 476, 528
usage guidelines..........................................................553 routing (tracing flag)...........................................................622
reoptimizing LSPs.............................................180, 337, 338 routing options, traffic engineering.....................................7
requests, CoS.........................................................................376 routing tables
rerouting LSPs host routes, installing.........................................154, 315
adaptive rerouting...............................................178, 273 IGP shortcuts...................................................................39
fast reroute..........................................46, 152, 288, 304 inet.0...........................................................................39, 45
reservation styles..................................................................381 inet.3...................................................................39, 45, 154
reserved labels.........................................................................28 MPLS..................................................................................45
reserving network resources See RSVP mpls.0................................................................................45
resource classes.............................................................152, 171 rpf-check-policy statement.............................................352
Resource Reservation Protocol See RSVP configuration guidelines............................................224
resv (tracing flag).................................................................457 RRO node ID sub-object, disabling...............................404
Resv messages, RSVP.......................................................380 RSVP...............................................................................................3
ResvConfirm messages, RSVP.........................................381 aggregation....................................................................426
ResvErr messages, RSVP...................................................381 authentication....................................................398, 427
resvtear (tracing flag)........................................................458 automatic mesh, configuration...............................415
ResvTear messages, RSVP...............................................380

640 Copyright © 2012, Juniper Networks, Inc.

 Index

bandwidth rsvp statement......................................................................453

reserving................................................................456 complete hierarchy under............................................17
update threshold................................................399 usage guidelines..........................................................393
BFD..........................................................................267, 269 rsvp-error-hold-time statement.....................................353
configuration, minimum...........................................393 usage guidelines.............................................................63
Differentiated Services..............................................202 rsvp-te statement................................................................454
disabling..........................................................................393 usage guidelines...........................................................415
enabling..........................................................................393 Russian dolls bandwidth model....................................200
example configurations..................................395, 422
Explicit Null label.........................................................419 S
for point-to-multipoint LSPs...................................227 scope of LSPs...........................................................................32
graceful restart..................................................388, 434 SE (reservation style)..........................................................381
hello acknowledgments............................................401 secondary
hello interval.......................................................398, 435 LSPs...............................................................149, 185, 354
hello packets.................................................................379 paths...................................................................................46
IGP hello packets.........................................................379 revert timer............................................................150
Implicit Null label.........................................................419 selection...................................................................151
Junos implementation...............................................378 secondary statement.........................................................354
keep multiplier..............................................................438 usage guidelines...........................................................149
link protection...............................................................402 select statement..................................................................355
load balancing...............................................................414 usage guidelines............................................................151
message types..............................................................379 send (tracing flag modifier)
MPLS, configuring with RSVP................................394 LDP....................................................................................533
MTU signaling in..........................................................383 LMP...................................................................................623
node ID hellos................................................................401 RSVP................................................................................458
overview..........................................................................376 server (tracing flag).............................................................622
PathErr messages..........................................................63 session messages, LDP.....................................................468
preemption......................................................................417 session protection, LDP
reservation styles..........................................................381 configuration.................................................................499
sessions..........................................................................394 overview.........................................................................468
setup protection...........................................................412 session statement...............................................................529
signaled LSPs...................................................................31 usage guidelines..........................................................498
signaling extensions.........................................................7 session-protection statement........................................530
supported software standards...............................376 usage guidelines..........................................................499
timers......................................................................416, 452 sessions, RSVP......................................................................394
timers, hello packets..................................................379 setup priority, signaled LSPs.............................................179
tracing protocol traffic......................................421, 457 setup protection, RSVP.......................................................412
tunneling LDP LSPs through RSVP setup-protection statement............................................455
LSPs..........................................................319, 465, 497 usage guidelines...........................................................412
ultimate-hop popping......................................419, 420 shared explicit reservation style......................................381
unnumbered interfaces............................................400 shared reservations..............................................................381
See also LDP shared risk link group
RSVP LSP hierarchy.............................................................601 overview............................................................................36
configuration.................................................................602 show (tracing flag)
overview..........................................................................601 LMP...................................................................................622
RSVP refresh reduction signal-bandwidth statement..........................................355
configuration.................................................................395 usage guidelines..........................................................595
overview..........................................................................382

Copyright © 2012, Juniper Networks, Inc. 641

Junos OS 12.1 MPLS Applications Configuration Guide

signaled LSPs........................................................................340 soft-preemption statement

adaptive rerouting...............................................178, 273 MPLS.................................................................................357
administrative groups usage guidelines..................................................162
admin-group statement...................................277 RSVP................................................................................455
admin-groups statement................................279 usage guidelines..................................................162
configuring...............................................................171 special labels............................................................................28
exclude statement.............................................298 srlg................................................................................................36
fast reroute.............................................................152 excluding, common links, secondary
associating addresses.......................................154, 315 path................................................................85, 90, 110
configuration statements.................................144, 317 overview............................................................................36
constrained-path computation usage guidelines.............................................................76
disabling........................................................170, 329 srlg statement........................................................................357
CoS values.......................................................................176 srlg-cost
creating............................................................................144 usage guidelines.............................................................76
damping LSP transitions...........................................186 srlg-cost statement............................................................358
egress router address........................................148, 367 srlg-value
fast reroute.................................................152, 288, 304 usage guidelines.............................................................76
fate-sharing...........................................................58, 305 srlg-value statement..........................................................358
hold time...............................................................186, 283 stacked labels..........................................................................28
ingress router address......................................147, 306 standby secondary paths....................................................46
metrics....................................................................156, 325 standby state, signaled LSPs.................................185, 359
MPLS routers, configuring..........................................63 standby statement..............................................................359
named paths...................................................................56 usage guidelines...........................................................185
overview....................................................................55, 143 state (tracing flag)
path LDP....................................................................................533
bandwidth..............................................................184 LMP...................................................................................623
connection retry information................155, 349 MPLS................................................................................369
length............................................................184, 308 RSVP................................................................................458
preemption............................................................179, 345 static (tracing flag).............................................................369
preference levels.................................................175, 343 static LSPs
primary...................................................................149, 344 configuring........................................................................211
priorities..................................................................179, 345 egress routers...............................................214, 216, 316
recording routes.............................................................175 ingress routers.................................................................211
reoptimization............................................180, 337, 338 intermediate routers...........................................214, 316
RSVP See RSVP link protection...............................................................402
secondary..............................................................149, 354 node protection...........................................................402
standby state.......................................................185, 359 overview..............................................................................31
tie-breaking rules.........................................34, 157, 348 revert timer............................................................150, 215
TTL decrementing.....................................161, 330, 333 static LSP metric................................................156, 325
signaling component, traffic engineering.........................7 static MPLS...............................................................................211
signaling extensions, RSVP....................................................7 static routes
size option to traceoptions statement point-to-multipoint LSPs...........................................217
LMP...................................................................................623 static-label-switched path statement
smart-optimize-timer statement..................................356 usage guidelines.............................................................211
usage guidelines...........................................................183 static-label-switched-path statement
SNMP traps static LSP.......................................................................360
MPLS.......................................................................257, 322 statistics
MPLS traffic.........................................................256, 362
output file.......................................................................256

642 Copyright © 2012, Juniper Networks, Inc.

 Index

statistics statement............................................................362 timer (tracing flag)

usage guidelines..........................................................256 MPLS................................................................................369
strict explicit routes.........................................................6, 218 timer, LDP........................................................................472, 512
strict-targeted-hellos statement...................................530 timers
usage guidelines...........................................................475 RSVP.......................................................................416, 452
subscribing to bandwidth.................................................456 to statement
subscription statement.....................................................456 MPLS................................................................................367
usage guidelines...........................................................201 usage guidelines..................................................148
summary LSA.........................................................................252 static LSPs
support, technical See technical support usage guidelines (ingress router)...................211
swap (label operation)........................................................30 traceoptions statement
swap and push (label operation).....................................30 LDP....................................................................................532
swap statement usage guidelines.................................................493
MPLS................................................................................363 LMP...................................................................................622
usage guidelines...................................................214 usage guidelines.................................................595
switch-away-lsps statement..........................................364 MPLS................................................................................368
usage guidelines..........................................................403 usage guidelines...................................................271
switching-type statement................................................365 RSVP.................................................................................457
usage guidelines..........................................................595 usage guidelines...................................................421
syntax conventions..............................................................xxxi tracing flag modifiers
system log messages detail
MPLS.......................................................................257, 322 LDP...........................................................................533
LMP..........................................................................623
T RSVP.......................................................................458
targeted hello messages...................................................467 disable.............................................................................533
targeted hello messages, LDP..........................................512 receive
targeted-hello statement...................................................531 LDP...........................................................................533
usage guidelines.................................................473, 474 LMP..........................................................................623
TCC RSVP.......................................................................458
configuration.................................................................556 send
connections..................................................................560 LDP...........................................................................533
encapsulation................................................................557 LMP..........................................................................623
graceful restart RSVP.......................................................................458
configuration........................................................562 tracing flags
overview..................................................................541 address............................................................................532
Layer 2 switching..........................................................557 all.......................................................................................368
overview.........................................................................540 LMP..........................................................................622
te-class-matrix statement...............................................366 RSVP........................................................................457
usage guidelines...........................................................195 binding.............................................................................532
te-link statement...................................................................621 connection.....................................................................368
LMP traffic engineering link connection-detail.......................................................368
usage guidelines.................................................586 cspf...................................................................................368
traffic engineering link associated with peer cspf-link..........................................................................368
usage guidelines.................................................592 cspf-node......................................................................368
usage guidelines..........................................................603 error
technical support LDP...........................................................................532
contacting JTAC..........................................................xxxii MPLS.......................................................................368
temporary GMPLS LSP deletion....................................598 RSVP........................................................................457
tie-breaking rules, path calculation...............34, 157, 348

Copyright © 2012, Juniper Networks, Inc. 643

Junos OS 12.1 MPLS Applications Configuration Guide

event MPLS.......................................................................271, 368

LDP...........................................................................532 RSVP........................................................................421, 457
RSVP........................................................................457 track-igp-metric statement.............................................534
graceful-restart............................................................369 usage guidelines..........................................................496
hello-packets traffic
LMP..........................................................................622 policing............................................................................539
init protection, MPLS...........................................................46
LMP..........................................................................622 statistics................................................................256, 362
initialization....................................................................532 traffic engineering
label..................................................................................533 BGP destinations...........................................................42
lmp....................................................................................457 fate-sharing......................................................................35
lsping................................................................................369 IGP and BGP destinations..........................................44
notification.....................................................................533 IGP shortcuts....................................................................37
nsr-synchronization...................................................369 information distribution component........................5
nsr-synchronization-detail......................................369 inter-area, OSPF..........................................................253
packets links...................................................................................585
LDP...........................................................................533 LSP metric advertisement.......................................252
LMP..........................................................................622 overview.........................................................................3, 27
RSVP........................................................................457 packet-forwarding component...................................4
parse path-selection component..........................................6
LMP..........................................................................622 routing options...................................................................7
path signaling component.......................................................7
LDP...........................................................................533 srlg.......................................................................................36
RSVP........................................................................457 traffic engineering database accuracy..................63
pathtear...........................................................................457 traffic engineering database...............................................32
periodic ...........................................................................533 accuracy............................................................................63
process............................................................................622 bandwidth update threshold.................................399
resv....................................................................................457 traffic-engineered LSPs
resvtear...........................................................................458 fast reroute....................................................................205
route.................................................................................458 traffic-engineering statement
LDP...........................................................................533 bgp-igp option...............................................................251
route-socket bgp-igp-both-ribs option..........................................251
LMP..........................................................................622 MPLS................................................................................370
routing..............................................................................622 usage guidelines.................................................250
server................................................................................622 mpls-forwarding option............................................252
show usage guidelines...........................................................227
LMP..........................................................................622 traffic-statistics statement..............................................535
state usage guidelines...........................................................491
LDP...........................................................................533 transit routers...........................................................................30
LMP..........................................................................623 transit statement
MPLS.......................................................................369 static LSP.......................................................................459
RSVP.......................................................................458 transit-delay statement....................................................624
static................................................................................369 usage guidelines..........................................................593
timer transit-lsp-association
MPLS.......................................................................369 usage guidelines...........................................................130
tracing operations transit-lsp-association statement
LDP..........................................................................493, 532 MPLS-TP..........................................................................371
LMP.........................................................................595, 622

644 Copyright © 2012, Juniper Networks, Inc.

 Index

transitions
advertising............................................................186, 283
damping..........................................................................186
translational cross-connect See TCC
transport-address statement.........................................536
usage guidelines..........................................................482
traps, SNMP See SNMP traps
TTL decrementing
disabling........................................................161, 330, 333
tunnel-services statement..............................................460
usage guidelines..........................................................420
tunneling, MPLS
CCC encapsulation.....................................................552
example configurations............................................554
overview.................................................................539, 551
RSVP LSPs..................................................319, 465, 497
RSVP LSPs, heterogeneous networks.................497

U
ultimate-hop popping........................................................249
point-to-multipoint LSPs.........................................420
unnumbered interfaces, RSVP.......................................400
unstable LSPs
fate-sharing See fate-sharing
update-threshold statement..........................................460
usage guidelines..........................................................399

V
verification
network interfaces......................................................244

W
wildcard filter (WF) reservation style............................381
wildcard senders, RSVP......................................................381
world-readable option to statistics statement
MPLS................................................................................362
world-readable option to traceoptions statement
LDP....................................................................................533
LMP...................................................................................623
MPLS................................................................................369
RSVP................................................................................458

Copyright © 2012, Juniper Networks, Inc. 645

Junos OS 12.1 MPLS Applications Configuration Guide

646 Copyright © 2012, Juniper Networks, Inc.

 bandwidth statement
fast reroute....................................................................288
link protection...............................................................428
multiclass LSPs...........................................................288
RSVP................................................................................428
Index of signaled LSPs...............................................................288
static LSPs.....................................................................289
Statements and bandwidth-model statement.........................................290
bandwidth-percent statement........................................291

Commands bfd-liveness-detection statement

LDP LSPs........................................................................505
RSVP LSPs.....................................................................292
bypass statement
A
RSVP................................................................................429
adaptive statement.............................................................273
static LSP.............................................................293, 430
address statement
LMP...................................................................................607
C
adjust-interval statement.................................................274
class-of-service statement
adjust-threshold statement.............................................274
bypass LSPs...................................................................431
adjust-threshold-overflow-limit statement...............275
ingress routers..............................................................294
adjust-threshold-underflow-limit statement............275
signaled LSPs...............................................................294
admin-down statement.....................................................276
static LSPs.....................................................................294
admin-group statement
connections statement.....................................................566
bypass LSPs..................................................................425
control-channel statement.............................................608
LSPs..................................................................................278
MPLS interfaces............................................................277
D
admin-group-extended statement..............................280
dead-interval statement..................................................608
admin-groups statement..................................................279
deaggregate statement....................................................506
admin-groups-extended statement..............................281
description statement
admin-groups-extended-range statement...............282
MPLS................................................................................295
advertisement-hold-time statement...........................283
diffserv-te statement.........................................................296
aggregate statement
disable statement
RSVP................................................................................426
GMPLS............................................................................609
allow-fragmentation statement....................................283
LDP....................................................................................507
allow-subnet-mismatch statement.............................503
link protection...............................................................432
always-mark-connection-protection-tlv
MPLS................................................................................297
statement...........................................................................284
OSPF...............................................................................609
associate-backup-pe-groups statement...................284
RSVP.................................................................................432
associate-lsp statement
RSVP graceful restart.................................................432
MPLS-TP........................................................................285
authentication-key statement
E
LDP...................................................................................504 ecmp statement..................................................................508
RSVP.................................................................................427 egress-policy statement...................................................508
auto-bandwidth statement.............................................285 encapsulation statement
auto-policing statement...................................................286 Layer 2 switching cross-connect...........................567
LSP tunnel cross-connect........................................567
B TCC....................................................................................567
backup-pe-group statement...........................................287
encoding-type statement.................................................297
ether-pseudowire statement..........................................303

Copyright © 2012, Juniper Networks, Inc. 647

Junos OS 12.1 MPLS Applications Configuration Guide

exclude statement..............................................................298 ingress statement

expand-loose-hop statement.........................................301 static LSP........................................................................314
explicit-null statement ingress-policy statement...................................................516
LDP...................................................................................509 install statement
MPLS.................................................................................301 MPLS.................................................................................315
RSVP.................................................................................301 interface statement
export statement.................................................................509 LDP.....................................................................................517
LMP....................................................................................612
F RSVP.................................................................................437
failure-action statement static LSPs......................................................................316
LDP LSPs.........................................................................510 interface-switch statement..............................................572
RSVP LSPs.....................................................................302 ipv6-tunneling statement..................................................316
family mpls statement.......................................................303
fast-reroute statement......................................................304 K
RSVP................................................................................433 keep-multiplier statement...............................................438
fate-sharing statement.....................................................305 keepalive-interval statement...........................................518
from statement keepalive-timeout statement..........................................518
MPLS...............................................................................306
L
G l2-smart-policy statement................................................519
gpid statement......................................................................307 label-switched-path statement
graceful-deletion-timeout statement.........................433 GMPLS..............................................................................613
graceful-restart statement MPLS..................................................................................317
LDP......................................................................................511 label-withdrawal-delay statement...............................519
RSVP................................................................................434 ldp statement........................................................................520
ldp-synchronization statement.......................................521
H ldp-tunneling statement....................................................319
hello-acknowledgements statement..........................435 least-fill statement.............................................................348
hello-dead-interval statement........................................610 link-management statement...........................................613
hello-interval statement link-protection statement
LDP.....................................................................................512 RSVP................................................................................439
LMP.....................................................................................611 signaled LSPs...............................................................320
OSPF.................................................................................612 static LSPs.......................................................................321
RSVP................................................................................435 lmp-control-channel statement.....................................614
helper-disable statement lmp-protocol statement....................................................614
LDP.....................................................................................513 load-balance statement...................................................440
hold-time statement local-address statement
LDP....................................................................................514 link management.........................................................615
holddown-interval statement..........................................513 log-updown statement
hop-limit statement.................................................308, 436 LDP.....................................................................................521
MPLS................................................................................322
I lsp-attributes statement...................................................323
icmp-tunneling statement...............................................309 lsp-ping-interval statement
ignore-lsp-metrics statement..........................................515 LDP LSPs........................................................................524
igp-synchronization statement.......................................515 RSVP LSPs.....................................................................336
import statement lsp-switch statement..........................................................573
LDP....................................................................................516
include-all statement..........................................................310 M
include-any statement........................................................312 max-bypasses statement.................................................441

648 Copyright © 2012, Juniper Networks, Inc.

 Index of Statements and Commands

maximum-bandwidth statement..................................323 p2mp-receive-switch statement....................................574

maximum-labels statement............................................324 p2mp-transmit-switch statement.................................575
maximum-neighbor-recovery-time passive statement................................................................615
statement...........................................................................522 path statement
maximum-recovery-time statement............................522 MPLS...............................................................................340
metric statement RSVP................................................................................448
MPLS................................................................................325 path-mtu statement...................................................341, 418
minimum-bandwidth statement...................................325 peer statement
monitor-bandwidth statement......................................326 LMP...................................................................................616
most-fill statement.............................................................348 peer-interface statement
mpls statement OSPF..................................................................................617
Layer 2 switching cross-connect...........................326 RSVP................................................................................449
MPLS................................................................................326 periodic-traceroute statement.......................................526
mpls-tp-mode statement policing statement......................................................341, 527
MPLS-TP.........................................................................327 pop statement
mtu-signaling statement...................................................327 MPLS................................................................................342
preemption statement......................................................450
N preference statement
next-hop statement............................................................328 LDP...................................................................................528
no-adjacency-down-notification statement............443 signaled LSPs................................................................343
no-cspf statement....................................................329, 444 static LSPs.....................................................................343
no-decrement-ttl statement..........................................330 primary statement
no-forwarding statement..................................................523 MPLS................................................................................344
no-install-to-address statement....................................331 priority statement
no-interface-hello statement.........................................444 MPLS................................................................................345
no-local-reversion statement.........................................442 RSVP.................................................................................451
no-mcast-replication statement....................................331 protection-revert-time statement................................346
no-neighbor-down-notification statement...............445 push statement
no-node-id-subobject statement.................................445 MPLS................................................................................347
no-p2mp-sublsp statement...........................................446
no-propagate-ttl statement............................................333 R
no-trap statement...............................................................334 random statement..............................................................348
node-hello statement........................................................443 reconnect-time statement...............................................528
node-link-protection statement....................................446 record statement.................................................................349
node-protection statement recovery-time statement..................................................529
static LSPs............................................................332, 335 refresh-time statement.....................................................452
reliable statement................................................................452
O remote-address statement
oam statement LMP control channel..................................................618
LDP LSPs........................................................................524 LMP traffic engineering..............................................618
RSVP LSPs.....................................................................336 remote-id statement
optimize-aggressive statement......................................337 link management.........................................................619
optimize-timer statement remote-interface-switch statement.............................576
bypass LSPs...................................................................447 retransmission-interval statement................................619
MPLS................................................................................338 retransmit-interval statement........................................620
retry-limit statement................................................349, 620
P retry-timer statement........................................................350
p2mp statement.........................................................339, 525 revert-timer statement.......................................................351
p2mp-lsp-next-hop statement......................................339 rpf-check-policy statement.............................................352

Copyright © 2012, Juniper Networks, Inc. 649

Junos OS 12.1 MPLS Applications Configuration Guide

rsvp statement......................................................................453 U
rsvp-error-hold-time statement.....................................353 update-threshold statement..........................................460
rsvp-te statement................................................................454

S
secondary statement.........................................................354
select statement..................................................................355
session statement...............................................................529
session-protection statement........................................530
setup-protection statement............................................455
signal-bandwidth statement..........................................355
smart-optimize-timer statement..................................356
soft-preemption statement
MPLS.................................................................................357
RSVP................................................................................455
standby statement..............................................................359
static-label-switched-path statement
static LSP.......................................................................360
statistics statement............................................................362
strict-targeted-hellos statement...................................530
subscription statement.....................................................456
swap statement
MPLS................................................................................363
switch-away-lsps statement..........................................364
switching-type statement................................................365

T
targeted-hello statement...................................................531
te-class-matrix statement...............................................366
te-link statement...................................................................621
to statement
MPLS................................................................................367
traceoptions statement
LDP....................................................................................532
LMP...................................................................................622
MPLS................................................................................368
RSVP.................................................................................457
track-igp-metric statement.............................................534
traffic-engineering statement
MPLS................................................................................370
traffic-statistics statement..............................................535
transit statement
static LSP.......................................................................459
transit-delay statement....................................................624
transit-lsp-association statement
MPLS-TP..........................................................................371
transport-address statement.........................................536
tunnel-services statement..............................................460

650 Copyright © 2012, Juniper Networks, Inc.