NorthStar Controller Feature Guide
Release
1.0.0
Published: 2015-04-19
Copyright © 2015, Juniper Networks, Inc.
Juniper Networks, Inc.
1133 Innovation Way
Sunnyvale, California 94089
USA
408-745-2000
www.juniper.net
Copyright © 2015, Juniper Networks, Inc. All rights reserved.
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.
NorthStar Controller Feature Guide
1.0.0
Copyright © 2015, Juniper Networks, Inc.
All rights reserved.
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 © 2015, Juniper Networks, Inc.
Table of Contents
About the Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Documentation and Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Documentation Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Documentation Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Requesting Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
Self-Help Online Tools and Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
Opening a Case with JTAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
Chapter 1
Architecture and Features of the NorthStar Controller . . . . . . . . . . . . . . . . . 15
Understanding the NorthStar Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Architecture and Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Interaction Between PCC and PCE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Dynamic Path Provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Understanding Network Topology Acquisition on the NorthStar Controller . . . . . 18
NorthStar Controller Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Chapter 2
Creating Label-Switched Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Understanding Label-Switched Paths on the NorthStar Controller . . . . . . . . . . . 23
Understanding Administrative Status for Label-Switched Paths . . . . . . . . . . . . . 24
Creating a Label-Switched Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Creating Label-Switched Paths That Are Diverse to Each Other . . . . . . . . . . . . . . 29
Creating Secondary and Standby Label-Switched Paths . . . . . . . . . . . . . . . . . . . . 31
Creating a Secondary or Standby LSP from the Add Tunnel Window . . . . . . . 31
Creating Multiple Secondary or Standby LSPs from the Diverse Path Design
Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Configuring Multiple Label-Switched Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Chapter 3
Scheduling Label-Switched Paths Over Time . . . . . . . . . . . . . . . . . . . . . . . . . 41
Understanding Time-Based Calendaring for Label-Switched Paths . . . . . . . . . . . 41
Using Time-Based Calendaring to Schedule Label-Switched Paths as a One-Time
or Daily Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Example: Using Time-Based Calendaring to Schedule Primary, Secondary, and
Standby Label-Switched Paths As MultiPeriod Daily Events . . . . . . . . . . . . . 47
Configuring a Primary and Secondary LSP for the First Scheduled Period . . 48
Configuring a Primary LSP for the Second Period . . . . . . . . . . . . . . . . . . . . . . 51
Configuring a Primary and Standby LSP for the Third Scheduled Period . . . . 53
Provisioning a Multiperiod Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Chapter 4
Managing and Optimizing Label-Switched Paths . . . . . . . . . . . . . . . . . . . . . . 57
Using Delta Provisioning to Modify an Existing Label-Switched Path . . . . . . . . . . 58
Optimizing a Label-Switched Path with Path Analysis . . . . . . . . . . . . . . . . . . . . . 59
Copyright © 2015, Juniper Networks, Inc.
iii
NorthStar Controller Feature Guide
Reoptimizing Label-Switched Paths with the Path Optimization Feature . . . . . . . 61
Understanding TE++ Label-Switched Paths on the NorthStar Controller . . . . . . 63
Viewing Label-Switched Path Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Disabling Provisioning of Label-Switched Paths from the NorthStar Controller
CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Disabling Provisioning of Label-Switched Paths from the NorthStar Controller
User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Chapter 5
Viewing Node Event and Link Event Changes . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Viewing Link Event Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Viewing Node Event Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Chapter 6
Managing Delegated Label-Switched Paths . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Understanding the Behavior of Delegated Label-Switched Paths . . . . . . . . . . . . . 77
Behavior of Delegated LSPs That Are Returned to Local PCC Control . . . . . . 77
Modifying Attributes of Delegated LSPs on the NorthStar Controller . . . . . . 79
Returning Delegation of Externally Controlled Label-Switched Paths Back to
Local PCC Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Chapter 7
Creating Templates to Apply Attributes to Label-Switched Paths . . . . . . . 83
Creating Templates to Apply Attributes to PCE-Initiated Label-Switched
Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Creating Templates with Junos OS Groups to Apply Attributes to PCE-Initiated
Label-Switched Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Chapter 8
Scheduling Maintenance on Network Devices . . . . . . . . . . . . . . . . . . . . . . . . 89
Scheduling a Maintenance Event on Network Elements . . . . . . . . . . . . . . . . . . . . 89
Managing Planned Maintenance Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Modifying a Planned Maintenance Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Canceling Scheduled Maintenance Events . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Deleting Planned or Canceled Maintenance Events . . . . . . . . . . . . . . . . . . . . 94
Viewing Maintenance Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Chapter 9
Managing Simulation Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Running Simulations for Scheduled Maintenance Events . . . . . . . . . . . . . . . . . . . 99
Viewing Failure Simulation Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Chapter 10
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
iv
Copyright © 2015, Juniper Networks, Inc.
List of Figures
Chapter 1
Architecture and Features of the NorthStar Controller . . . . . . . . . . . . . . . . . 15
Figure 1: PCCD Is Relay/Message Translator Between PCE and RPD . . . . . . . . . . . 17
Chapter 2
Creating Label-Switched Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Figure 2: Add Tunnel Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Figure 3: Add Diverse Tunnel Pair Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Figure 4: Paths Tab from Add Tunnel Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Figure 5: Enabling the Map Selection Option to Select a Path . . . . . . . . . . . . . . . . 32
Figure 6: Selecting the Tunnel Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Figure 7: Selecting “PCEP =True” to Create a Full Mesh Between PCEP Neighbor
Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Figure 8: Specifying Path Options for Primary and Backup Paths . . . . . . . . . . . . . 35
Figure 9: Add Multiple Tunnels Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Chapter 3
Scheduling Label-Switched Paths Over Time . . . . . . . . . . . . . . . . . . . . . . . . . 41
Figure 10: Add Tunnel Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Figure 11: Scheduling Window with MultiPeriod Enabled . . . . . . . . . . . . . . . . . . . . 45
Figure 12: Display of Provisioned MultiPeriod Tunnel . . . . . . . . . . . . . . . . . . . . . . . 46
Figure 13: Properties Tab for Add Tunnel Dialog Box . . . . . . . . . . . . . . . . . . . . . . . 49
Figure 14: Paths Tab from Add Tunnel Window . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Figure 15: Enabling the Map Selection Option to Select an Explicit Path . . . . . . . 50
Figure 16: Selecting a Secondary Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Figure 17: Scheduling the First Period During Which the Primary and Secondary
Tunnels Are Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Figure 18: Scheduling Window with MultiPeriod Enabled for Second Period . . . . 52
Figure 19: Paths Tab from Add Tunnel Window . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Figure 20: Enabling the Map Selection Option to Select an Explicit Path . . . . . . . 54
Figure 21: Selecting the Standby Tunnel Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Figure 22: Scheduling Window with MultiPeriod Enabled for Third Period . . . . . . 55
Figure 23: Admin Status for MultiPeriod Tunnels After Provisioning the Configured
MultiPeriod Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Chapter 4
Managing and Optimizing Label-Switched Paths . . . . . . . . . . . . . . . . . . . . . . 57
Figure 24: Delta Provisioning Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Figure 25: Original and Optimal Paths Displayed in Path Analysis . . . . . . . . . . . . 60
Figure 26: Path Optimization Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Figure 27: Selecting a Time Range to View LSP Events . . . . . . . . . . . . . . . . . . . . . 65
Figure 28: Selecting the DIsable Provisioning Check Box . . . . . . . . . . . . . . . . . . . . 68
Figure 29: Selecting the DIsable Provisioning Check Box . . . . . . . . . . . . . . . . . . . . 69
Chapter 5
Viewing Node Event and Link Event Changes . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Figure 30: Selecting a Time Range to View Link Events . . . . . . . . . . . . . . . . . . . . . 72
Copyright © 2015, Juniper Networks, Inc.
v
NorthStar Controller Feature Guide
Figure 31: Selecting a Time Range to View Node Events . . . . . . . . . . . . . . . . . . . . . 74
Chapter 6
Managing Delegated Label-Switched Paths . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Figure 32: Returning LSP Delegation to PCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Chapter 9
Managing Simulation Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Figure 33: Maintenance Event Simulation Dialog Box Displays Elements for
Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
vi
Copyright © 2015, Juniper Networks, Inc.
List of Tables
About the Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Table 1: Notice Icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x
Table 2: Text and Syntax Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x
Chapter 2
Creating Label-Switched Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Table 3: NorthStar Controller Admin Status Values for LSPs . . . . . . . . . . . . . . . . . 24
Table 4: NorthStar Controller Admin Status Values for Maintenance Events . . . . 26
Table 5: Common Path Design Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Chapter 4
Managing and Optimizing Label-Switched Paths . . . . . . . . . . . . . . . . . . . . . . 57
Table 6: Default Fields Displayed for LSP Events . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Chapter 5
Viewing Node Event and Link Event Changes . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Table 7: Default Fields Displayed for Link Events . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Table 8: Default Fields Displayed for Node Events . . . . . . . . . . . . . . . . . . . . . . . . . 74
Chapter 6
Managing Delegated Label-Switched Paths . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Table 9: Behavior of LSP Configurations Initiated from PCC . . . . . . . . . . . . . . . . . 78
Chapter 8
Scheduling Maintenance on Network Devices . . . . . . . . . . . . . . . . . . . . . . . . 89
Table 10: Elements for Maintenance Event Window . . . . . . . . . . . . . . . . . . . . . . . 92
Table 11: Default Fields Displayed from Network Info > Maintenance Table . . . . . 96
Copyright © 2015, Juniper Networks, Inc.
vii
NorthStar Controller Feature Guide
viii
Copyright © 2015, Juniper Networks, Inc.
About the Documentation
•
Documentation and Release Notes on page ix
•
Documentation Conventions on page ix
•
Documentation Feedback on page xi
•
Requesting Technical Support on page xii
Documentation and 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/.
If the information in the latest release notes differs from the information in the
documentation, follow the product Release Notes.
Juniper Networks Books publishes books by Juniper Networks engineers and subject
matter experts. These books go beyond the technical documentation to explore the
nuances of network architecture, deployment, and administration. The current list can
be viewed at http://www.juniper.net/books.
Documentation Conventions
Table 1 on page x defines notice icons used in this guide.
Copyright © 2015, Juniper Networks, Inc.
ix
NorthStar Controller Feature 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.
Tip
Indicates helpful information.
Best practice
Alerts you to a recommended use or implementation.
Table 2 on page x 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
Italic text like this
Italic text like this
x
Represents output that appears on the
terminal screen.
user@host> show chassis alarms
•
Introduces or emphasizes important
new terms.
•
•
Identifies guide names.
A policy term is a named structure
that defines match conditions and
actions.
•
Identifies RFC and Internet draft titles.
•
Junos OS CLI User Guide
•
RFC 1997, BGP Communities Attribute
Represents variables (options for which
you substitute a value) in commands or
configuration statements.
No alarms currently active
Configure the machine’s domain name:
[edit]
root@# set system domain-name
domain-name
Copyright © 2015, Juniper Networks, Inc.
About the Documentation
Table 2: Text and Syntax Conventions (continued)
Convention
Description
Examples
Text like this
Represents names of configuration
statements, commands, files, and
directories; configuration hierarchy levels;
or labels on routing platform
components.
•
To configure a stub area, include the
stub statement at the [edit protocols
ospf area area-id] hierarchy level.
•
The console port is labeled CONSOLE.
< > (angle brackets)
Encloses optional keywords or variables.
stub <default-metric metric>;
| (pipe symbol)
Indicates a choice between the mutually
exclusive keywords or variables on either
side of the symbol. The set of choices is
often enclosed in parentheses for clarity.
broadcast | multicast
# (pound sign)
Indicates a comment specified on the
same line as the configuration statement
to which it applies.
rsvp { # Required for dynamic MPLS only
[ ] (square brackets)
Encloses a variable for which you can
substitute one or more values.
community name members [
community-ids ]
Indention and braces ( { } )
Identifies a level in the configuration
hierarchy.
; (semicolon)
Identifies a leaf statement at a
configuration hierarchy level.
(string1 | string2 | string3)
[edit]
routing-options {
static {
route default {
nexthop address;
retain;
}
}
}
GUI Conventions
Bold text like this
Represents graphical user interface (GUI)
items you click or select.
> (bold right angle bracket)
Separates levels in a hierarchy of menu
selections.
•
In the Logical Interfaces box, select
All Interfaces.
•
To cancel the configuration, click
Cancel.
In the configuration editor hierarchy,
select Protocols>Ospf.
Documentation Feedback
We encourage you to provide feedback, comments, and suggestions so that we can
improve the documentation. You can provide feedback by using either of the following
methods:
•
Online feedback rating system—On any page at the Juniper Networks Technical
Documentation site at http://www.juniper.net/techpubs/index.html, simply click the
stars to rate the content, and use the pop-up form to provide us with information about
your experience. Alternately, you can use the online feedback form at
https://www.juniper.net/cgi-bin/docbugreport/.
Copyright © 2015, Juniper Networks, Inc.
xi
NorthStar Controller Feature Guide
•
E-mail—Send your comments to [email protected]. Include the document
or topic name, URL or page number, and software 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,
or are covered under warranty, and need post-sales 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/
•
Search for known bugs: http://www2.juniper.net/kb/
•
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:
http://kb.juniper.net/InfoCenter/
•
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.
xii
•
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).
Copyright © 2015, Juniper Networks, Inc.
About the Documentation
For international or direct-dial options in countries without toll-free numbers, see
http://www.juniper.net/support/requesting-support.html.
Copyright © 2015, Juniper Networks, Inc.
xiii
NorthStar Controller Feature Guide
xiv
Copyright © 2015, Juniper Networks, Inc.
CHAPTER 1
Architecture and Features of the
NorthStar Controller
•
Understanding the NorthStar Controller on page 15
•
Understanding Network Topology Acquisition on the NorthStar Controller on page 18
•
NorthStar Controller Features on page 19
Understanding the NorthStar Controller
The Juniper Networks NorthStar Controller is an SDN network controller that enables
granular visibility and control of IP/MPLS flows in large service provider and enterprise
networks. Network operators can use the NorthStar Controller to optimize their network
infrastructure through proactive monitoring, planning, and explicit routing of large traffic
loads dynamically based on user-defined constraints.
The NorthStar Controller provides network managers with a powerful and flexible traffic
engineering solution and the following features:
•
Complex inter-domain path computation and network optimization
•
Comprehensive network planning, capacity, and topology analysis
•
Ability to address multilayer optimization with multiple user-defined constraints
•
Specific ordering and synchronization of paths signaled across routed network elements
•
Global view of the network state for monitoring, management, and proactive planning
The NorthStar Controller relies on PCEP to instigate a path between the PCC routers.
The path setup itself is performed through RSVP-TE signaling, which is enabled in the
network and allows labels to be assigned from an ingress router to the egress router.
Signaling is triggered by ingress routers in the core of the network. The PCE client runs
®
on the routers by using a version of the Junos operating system (Junos OS) that supports
PCE.
The NorthStar Controller provisions PCEP in all PE devices (PCCs) and uses PCEP to
retrieve the current status of the existing tunnels (LSPs) that run in the network. By
providing a view of the global network state and bandwidth demand in the network, the
NorthStar Controller is able to compute optimal paths and provide the attributes that
the PCC uses to resignal the LSP.
Copyright © 2015, Juniper Networks, Inc.
15
NorthStar Controller Feature Guide
The following sections describe the architecture, components, and functionality of the
NorthStar Controller:
•
Architecture and Components on page 16
•
Interaction Between PCC and PCE on page 17
•
Dynamic Path Provisioning on page 17
Architecture and Components
Based on the Path Computation Element (PCE) architecture as defined in RFC 5440,
the NorthStar Controller provides a stateful PCE that computes the network paths or
routes based on a network graph and applies computational constraints. A Path
Computation Client (PCC) is a client application that requests the PCE perform path
computations for the PCC’s external label-switched paths (LSPs). The Path Computation
Element Protocol (PCEP) enables communication between a PCC and the NorthStar
Controller to learn about the network and LSP path state and communicate with the
PCCs. The PCE entity in the NorthStar Controller calculates paths in the network on
behalf of the PCCs, which request path computation services. The PCCs receive and then
apply the paths in the network.
The stateful PCE implementation in the NorthStar Controller provides the following
functions:
•
Allows offline LSP path computation
•
Triggers LSP reroute when there is a need to reoptimize the network
•
Changes LSP bandwidth when an application demands an increase in bandwidth
•
Modifies other LSP attributes on the router, such as explicit route object (ERO), setup
priority, and hold priority
A TCP-based PCEP session connects a PCC to an external PCE. The PCC initiates the
PCEP session and stays connected to the PCE for the duration of the PCEP session.
During the PCEP session, the PCC requests LSP parameters from the stateful PCE. When
receiving one or more LSP parameters from the PCE, the PCC resignals the TE LSP. When
the PCEP session is terminated, the underlying TCP connection is closed immediately,
and the PCC attempts to reestablish the PCEP session.
The PCEP functions include the following:
16
•
LSP tunnel state synchronization between a PCC and a stateful PCE— When an active
stateful PCE connection is detected, a PCC synchronizes an LSP state with the PCE.
PCEP enables a fast and timely synchronization of the LSP state to the PCE.
•
Delegation of control over LSP tunnels to a stateful PCE—An active stateful PCE
controls one or more LSP attributes for computing paths, such as bandwidth, path
(ERO), and priority (setup and hold). PCEP enables such delegation of LSPs for path
computation.
•
Stateful PCE control of timing and sequence of path computations within and across
PCEP sessions—An active stateful PCE modifies one or more LSP attributes, such as
bandwidth, path (ERO), and priority (setup and hold). PCEP communicates these new
Copyright © 2015, Juniper Networks, Inc.
Chapter 1: Architecture and Features of the NorthStar Controller
LSP attributes from the PCE to the PCC, after which the PCC re-signals the LSP in the
specified path.
Interaction Between PCC and PCE
For the NorthStar Controller, the PCC runs in a new Junos OS daemon, the path
computation client process (PCCD), which interacts with the PCE and with the routing
protocol process (RPD) through an internal Junos OS IPC mechanism. Figure 1 on page 17
shows the interaction between the PCE, PCCD, and RPD.
Figure 1: PCCD Is Relay/Message Translator Between PCE and RPD
The PCCD is stateless so it does not keep any state other than current outstanding
requests, and does not remember any state for established LSPs. The PCCD requests
the state after the response comes back from the PCE and then forwards the response
to the RPD. Because the PCCD is stateless, the RPD only needs to communicate with
the PCCD when the LSP is first created. After the RPD receives the results from the PCCD,
the results are stored (even across RPD restarts), and the RPD does not need to
communicate with the PCCD again until the LSP is rerouted (when the LSP configuration
is changed or the LSP fails).
Dynamic Path Provisioning
To provide dynamic path provisioning, each ingress label-edge router (LER) must be
configured as a Path Computation Client (PCC). Through PCEP, each PCC informs the
NorthStar Controller (PCE server) asynchronously about the state of LSPs, including LSP
operational state, admin state, and protection in-use events. The LSP state update and
LSP provisioning depend on the TCP/PCEP connection state. If the TCP connection goes
down as a result of connection flaps or PCC failure, the NorthStar Controller waits
approximately 60 seconds for PCC reconnection then removes the LSP state.
Related
Documentation
•
Understanding Network Topology Acquisition on the NorthStar Controller on page 18
•
NorthStar Controller Features on page 19
Copyright © 2015, Juniper Networks, Inc.
17
NorthStar Controller Feature Guide
Understanding Network Topology Acquisition on the NorthStar Controller
After you use BGP-LS to establish BGP peering between the NorthStar Controller and a
Path Computation Client (PCC) in the network, the NorthStar Controller acquires real-time
topology changes, which are recorded in the traffic engineering database (TED). To
compute optimal paths through the network, the NorthStar Controller requires a
consolidated view of the network topology. This routing view of the network includes the
nodes, links, and their attributes (metric, link utilization bandwidth, and so forth) that
comprise the network topology. Thus, any router CLI configuration changes to IGP metric,
RSVP bandwidth, Priority/Hold values, and so forth are instantly available from the
NorthStar Controller user interface topology view.
To provide a network view, the NorthStar Controller runs Junos in a virtual machine
(JunosVM) that uses routing protocols to communicate with the network and dynamically
learn the network topology. To provide real-time updates of the network topology, the
JunosVM, which is based on a virtual Route Reflector (vRR), establishes a BGP-LS peering
session with one or more routers from the existing MPLS TE backbone network. A router
from the MPLS TE backbone advertises its traffic engineering database (TED) in BGP-LS.
The NorthStar Controller JunosVM receives real-time BGP-LS updates and forwards this
topology data into the Network Topology Abstractor Daemon (NTAD), which is a server
daemon that runs in the JunosVM.
The NorthStar Controller stores network topology data in the following routing tables:
•
lsdist.0—stores the network topology from TED
•
lsdist.1—stores the network topology from IGP database
NTAD then forwards a copy of the updated topology information to the Path Computation
Server (PCS), which displays the live topology update from the NorthStar Controller user
interface.
To provide a real-time topology update of the network, you can configure direct ISIS/OSPF
adjacency between NorthStar Controller and an existing MPLS TE backbone router, but
Juniper recommends that you use BGP-LS rather than direct IGP adjacency or IGP
adjacency over GRE.
18
Copyright © 2015, Juniper Networks, Inc.
Chapter 1: Architecture and Features of the NorthStar Controller
NOTE:
The current BGP-LS implementation only considers TED information, and
some IGP-specific attributes might not be forwarded during topology
acquisition. The following IGP attributes are not forwarded:
•
ISIS area
•
ISIS host name
•
Link net mask
•
IGP metric (TED provides TE metric only).
In some cases, using ISIS or OSPF adjacency instead of BGP-LS might produce
stale data because ISIS and OSPF have a database lifetime period that is
not automatically cleared when the adjacency is down. In this case, NTAD
will export all information in the OSPF or ISIS database to the NorthStar Path
Computation Server (PCS), so the NorthStar Controller might show incorrect
topology.
Related
Documentation
•
Understanding the NorthStar Controller on page 15
•
Configuring Connectivity for BGP-LS Topology Acquisition
•
Configuring Connectivity for IS-IS Topology Acquisition
•
Configuring PCEP on a PE Router (from CLI)
•
Configuring Connectivity for OSPF Topology Acquisition
NorthStar Controller Features
The NorthStar Controller software provides traffic-engineering based solutions for WAN
and Edge (data center edge and WAN edge) networks. After the NorthStar Controller
has connected to the network and dynamic topology acquisition is performed to provide
a real-time routing view of the network topology, you can view the network model from
the NorthStar Controller user interface. You can then plan, analyze, and assess the impact
of network changes you want to make before implementing them.
The NorthStar Controller supports the following use cases and features:
•
Dynamic topology acquisition—Use routing protocols (IS-IS, OSPF, and BGP-LS) to
obtain real-time topology updates.
•
Label-switched path (LSP) reporting—Label edge routers (LERs) use PCEP reports to
report all types of LSPs (PCC_controlled, PCC_delegated, and PCE_initiated) to the
NorthStar Controller.
•
LSP provisioning—Create LSPs from the NorthStar Controller or update LSPs that have
been delegated to the NorthStar Controller.
Copyright © 2015, Juniper Networks, Inc.
19
NorthStar Controller Feature Guide
•
Bidirectional LSPs—Design a pair of LSPs so that the LSP from the ingress LER to the
egress LER follows the same path as the LSP from the egress LER to the ingress LER.
•
Diverse LSPs—From the NorthStar Controller user interface, design two LSPs so that
the paths are either node, link, or SRLG diverse from each other.
NOTE: The NorthStar Controller supports diverse point-to-point diverse
LSPs. The provisioning of diverse point-to-multipoint diverse LSPs is not
supported.
•
Standby and secondary LSPs—Provide an alternate route in the event the primary
route fails. The tunnel ID, from node, to node, and IP address of a secondary or standby
LSP are identical to that of the primary LSP. However, secondary and standby LSPs
have the following differences:
•
A secondary LSP is not signaled until the primary LSP fails.
•
A standby LSP is signaled regardless of the status of the primary LSP.
•
Time-based LSP scheduling—Schedule the creation of LSPs based on future
requirements by using time-based calendaring. You can schedule an LSP as a one-time
event or recurring daily event for a specified period of time to schedule setup,
modification, and tear down of LSPs based on the traffic load, bandwidth, and setup
and hold priority requirements of your network over time. The scheduling of an LSP is
configured on the primary path, and the scheduled time applies to all paths (primary,
secondary, and standby).
•
LSP templates—Create LSP templates to define a set of LSP attributes to apply to all
PCE-initiated LSPs that provide a name match with the regular expression (regex)
name specified in the template. By associating LSPs (through regex name matching)
with an LSP template, you can automatically enable or disable LSP attributes across
any LSPs that provide a name match with the regex name that is specified in the
template.
•
Auto-bandwidth LSPs—Auto-bandwidth support for Path Computation Element
(PCE)-controlled (PCE-initiated or PCC-delegated) LSPs—Path Computation Clients
(PCCs) can automatically adjust the required bandwidth based on the traffic load on
the LSP. Auto-bandwidth parameters must be configured from the PCC, even when
the LSP has been delegated to the NorthStar Controller. However, you can enable
auto-bandwidth parameters by way of a template so that any PCE-controlled LSP
that provides a name match with a regular expression (regex) name defined in a
template inherits the LSP attributes specifed in that template.
Auto-bandwidth behavior varies depending on the LSP type:
20
•
Router-controlled LSPs—The NorthStar Controller must learn about router-controlled
LSPs. The PCC performs statistical accounting of LSP bandwidth and LSP resizing
is driven by bandwidth threshold triggers. The NorthStar Controller is updated
accordingly.
•
NorthStar Controller managed (Delegated) LSPs —The PCC performs bandwidth
accounting for these LSPs. When bandwidth thresholds are reached, a PCReq
Copyright © 2015, Juniper Networks, Inc.
Chapter 1: Architecture and Features of the NorthStar Controller
message is sent to the NorthStar Controller’s Path Computation Server (PCS) to
compute the Explicit Route Object (ERO). The PCC determines how to resize the
LSP while the PCS provides the ERO that meets the constraints. These LSPs are
delegated as usual, and PCRpt messages are sent with the Delegation bit set.
When bandwidth threshold triggers are reached on the PCC, a PCReq message is
sent to the PCE to request a path with new bandwidth. The following conditions
apply:
•
•
If a new path is available, make-before-break (MBB) signaling is attempted and
a new path is signaled. The PCRpt message from the PCC to PCE reports the
updated path.
•
If a new path is not found, the process described above is repeated whenever the
adjust interval timer is triggered.
NorthStar Controller created LSPs—When an LSP is created from the NorthStar
Controller user interface, a template defines the autobandwidth attributes associated
with the LSP, which allows the PCC to treat the LSP as an auto-bandwidth LSP. All
other LSP behavior is the same as the NorthStar Controller managed LSP (as
described above).
•
LSP optimization—Analyze and optimize LSPs that have been delegated to the
NorthStar Controller. You can use the Path Analysis feature to manually trigger path
optimization from the NorthStar Controller user interface or use the Path Optimization
feature to automatically optimize paths based on user-defined time intervals.
•
Enable and disable LSP provisioning from the NorthStar Controller— You can enable
passive monitor mode from the NorthStar Controller CLI to globally disable provisioning
of LSPs for all NorthStar Controller users. You can also enable and disable LSP
provisioning (locally or globally) from the NorthStar Controller user interface. A
NorthStar Controller administrator can disable provisioning of LSPs for all users by
navigating to the Tools > Options menu and selecting the Disable Provisioning check
box. A NorthStar Controller user with full access privileges can also disable provisioning
(for local user only) by navigating to the Tools > Options menu and selecting the Disable
Provisioning check box.
•
Schedule maintenance events—Select nodes and links for maintenance. When you
schedule a maintenance event on nodes or links, the NorthStar Controller routes
delegated LSPs around those nodes and links that are scheduled for maintenance.
After completion of the maintenance event, delegated LSPs are reverted back to
optimal paths.
•
Run simulations for scheduled maintenance events—Run simulations from the
NorthStar Controller on scheduled maintenance events for different failure scenarios
to test the resilience of your network, or run simulations before the event occurs.
Network simulation is based on the current network state for the selected maintenance
events at the time the simulation is initiated. Simulation does not simulate the
maintenance event for a future network state or simulate elements from other
concurrent maintenance events. You can run network simulations based on selected
Copyright © 2015, Juniper Networks, Inc.
21
NorthStar Controller Feature Guide
elements for maintenance or extended failure simulations, with the option to include
exhaustive failures.
•
TE++ LSPs—A TE++ LSP includes a set of paths that are configured as a specific
container statement and individual LSP statements, called sub-LSPs, which all have
equal bandwidth.
For TE++ LSPs, a normalization process occurs that resizes the LSP when either of the
following two triggers initiates the normalization process:
•
A periodic timer
•
Bandwidth thresholds are met
When either of the preceding triggers are fired, one of the following events can occur:
•
No change is required
•
LSP splitting—add another LSP and distribute bandwidth across all the LSPs
•
LSP merging—delete an LSP and distribute bandwidth across all the LSPs
For a TE++ LSP, the NorthStar Controller displays a single LSP with a set of paths, and
the LSP name is based on the matching prefix name of all members. The correlation
between TE-LSPs is based on association, and the LSP is deleted when there is no
remaining TE LSP.
NOTE: TE++ is supported on PCC (router) controlled LSPs and delegated
LSPs, but TE++ LSPs cannot be created on the NorthStar Controller.
Related
Documentation
22
•
Understanding the NorthStar Controller on page 15
•
Understanding Network Topology Acquisition on the NorthStar Controller on page 18
Copyright © 2015, Juniper Networks, Inc.
CHAPTER 2
Creating Label-Switched Paths
•
Understanding Label-Switched Paths on the NorthStar Controller on page 23
•
Understanding Administrative Status for Label-Switched Paths on page 24
•
Creating a Label-Switched Path on page 26
•
Creating Label-Switched Paths That Are Diverse to Each Other on page 29
•
Creating Secondary and Standby Label-Switched Paths on page 31
•
Configuring Multiple Label-Switched Paths on page 38
Understanding Label-Switched Paths on the NorthStar Controller
The Northstar Controller uses PCEP to learn about LSPs in the discovered network
topology, and all LSPs and their attributes can be viewed from the NorthStar Controller
user interface. However, the LSP type determines whether the Path Computation Client
(PCC) or NorthStar Controller maintains the operational and configuration states.
The following LSP types are supported on the NorthStar Controller:
•
Router-controlled LSP: The LSP is configured locally on the router, and the router
maintains both the operational state and configuration state of the LSP. The NorthStar
Controller learns these LSPs for the purpose of visualization and comprehensive path
computation, but cannot change any attribute on these LSPs.
•
Delegated LSP: The LSP is provisioned on the PCC (router) and has been delegated
to the NorthStar Controller for subsequent management. The operational state and
configuration state of the LSP is stored in the PCC. For delegated LSPs, the ERO,
bandwidth, LSP metric, and priority fields can be changed from the Northstar Controller
user interface. However, the NorthStar Controller can return delegation back to the
PCC, in which case, the LSP is reclassified as router controlled.
•
Controller-initiated LSP: The LSP is provisioned from the NorthStar Controller UI. For
these LSPs, only the operational state is maintained in the router, and only NorthStar
can update the LSP attributes.
The NorthStar Controller supports the discovery, control, and creation of protection LSPs
(standby and secondary LSPs). For protection LSPs, the primary, secondary, and standby
LSP must be of the same type (router-controlled, delegated, or controller-initiated).
Each LSP can have its own specific bandwidth, setup priority, and hold priority or can use
Copyright © 2015, Juniper Networks, Inc.
23
NorthStar Controller Feature Guide
the values of the primary LSP (the default). A primary LSP must always be present for
controller-initiated LSPs.
Related
Documentation
•
Understanding the NorthStar Controller on page 15
•
Understanding the Behavior of Delegated Label-Switched Paths on page 77
•
Understanding Administrative Status for Label-Switched Paths on page 24
•
Understanding TE++ Label-Switched Paths on the NorthStar Controller on page 63
Understanding Administrative Status for Label-Switched Paths
To view the administrative status of a label-switched path (LSP) from the NorthStar
Controller user interface, navigate to the Network Info screen and select the Tunnels tab.
The Admin_Status column shows the current provisioning status or scheduled task for
each tunnel configured on the NorthStar Controller. The provisioning status shows the
current provisioned action in uppercase letters.
Table 3 on page 24 lists the Admin column values that identify the provisioning status
and scheduling status for LSPs.
Table 3: NorthStar Controller Admin Status Values for LSPs
Admin Status
Description
Callsetup_Scheduled
For timed LSPs, the LSP is now disconnected and a call setup
is scheduled for a later time.
Candidate_ReOptimization
When path analysis is performed on LSPs, any LSP for which
a better path is available is identified as a candidate for
reoptimization, and the status of the LSP displays
“Candidate_ReOptimization” in the Tunnel table view. A user
can then choose to provision the LSP with the better path, or
disregard the proposed better path and use the existing path.
DELETE_*
LSP will be deleted from the live network and model.
PLANNED_DELETE
User has requested LSP deletion from the database, but LSP
deletion is not scheduled.
DISCONNECT_*
The LSP is going to be deleted from the live network but not
removed from the database.
DISCONNECT_Planned
For “timed” LSPs. Disconnect means delete from the live
network. But deletion for this LSP is not scheduled by the user.
Disconnect_Scheduled
LSP is currently set up, and call disconnect is scheduled.
24
Copyright © 2015, Juniper Networks, Inc.
Chapter 2: Creating Label-Switched Paths
Table 3: NorthStar Controller Admin Status Values for LSPs (continued)
FAIL
Path Computation Server (PCS) failed to push the LSP to the
Path Computation Element (PCE) server.
Check status for the following:
•
Is PCE_SERVER status shown as Connected in the GUI?
NOTE: If not, verify that PCE server is running.
•
If PCE server is running, and PCE server has PCEP session
established from the server, check that rabbitmq-server is
running.
•
If rabittmq-server is not running, perform the following steps:
1.
Run service rabbitmq-server restart from the NorthStar
JunosVM CLI.
2. Run service jnc restart from the NorthStar JunosVM CLI.
FAILED
Failed to send LSP provisioning order.
FAILED_Routing_failed
Path Computation Server (PCS) failed to find the route to
provision. This status is similar to NoRoute_Rescheduled.
PCC_PENDING
Waiting for UP/DOWN confirmation from the Path
Computation Client (PCC).
PENDING
Provision order is issued, but waiting for response from the
NorthStar Controller (PCE server).
PENDING_DELETED
LSP deletion order is issued, but waiting for response from the
NorthStar Controller (PCE server).
PLANNED
LSPs are created or modified by user but are not yet scheduled.
PLANNED_DELETE
LSP will be deleted.
PLANNED_DISCONNECT
LSP disconnect to be provisioned for timed LSPs.
NoRoute_Rescheduled
Failed to find route, schedule for reroute (will put in future
queues).
NotActive
LSP is disabled from rtserver, which typically occurs when the
end nodes are the same.
SCHEDULED
LSP provisioning is scheduled.
SCHEDULED_DELETE
LSP deletion is scheduled.
SCHEDULED_DISCONNECTED
LSP is currently set up, and call disconnect is scheduled.
(Displays empty string)
Live_Status column displays UP or DOWN.
Copyright © 2015, Juniper Networks, Inc.
25
NorthStar Controller Feature Guide
Table 4 on page 26 lists the Admin column values that identify the Admin status for LSPs
affected by maintenance events.
Table 4: NorthStar Controller Admin Status Values for Maintenance Events
Admin Status
Description
Maint_Node_Down
LSPs are originated or terminated at the nodes being serviced.
Rerouted_for_Maintenance
LSPs are rerouted around maintenance elements.
Maint_failed_to_reroute
The LSP cannot be rerouted away from the maintenance elements.
Maint_reroutable
The PCC-controlled LSPs can be rerouted away from maintenance elements
and provisioning is not scheduled.
Related
Documentation
•
Understanding the Behavior of Delegated Label-Switched Paths on page 77
•
Understanding Label-Switched Paths on the NorthStar Controller on page 23
Creating a Label-Switched Path
When creating a route between two sites, at minimum, you must create a single
label-switched path (LSP) to send traffic from one site to another. By default, the first
tunnel you create between two specific sites functions as the primary tunnel.
To add a tunnel in the network topology:
1.
From the Network Info window, select Add > One Tunnel.
The Add Tunnel dialog box is displayed, as shown in Figure 2 on page 26.
2. From the Properties tab, provide the following information for each tunnel you want
to create:
26
Copyright © 2015, Juniper Networks, Inc.
Chapter 2: Creating Label-Switched Paths
a. In the Tunnel ID field, enter a user-defined name for the tunnel.
The name must be unique for a given ingress node (NodeA), and the name cannot
contain spaces.
NOTE: If a user-defined name is not provided for the tunnel, the PCE
automatically generates a unique name.
b. Select node addresses for the Node A and Node Z fields to define the endpoint
nodes for the tunnel.
NOTE: You can optionally select Auto Add on Mouse Clicks and then
select Node A and Node Z directly from the topology map view to
immediately create the tunnel. However, if you choose this option, you
must set Bandwidth, Priority, and Hold values from the Add Tunnel
dialog box beforehand.
c. (Optional) To create a bidirectional tunnel, select the Create identical tunnel(s) on
the same path in opposite direction check box.
d. In the Bandwidth field, specify the bandwidth for the tunnel traffic (bandwidth
applies for each direction).
The default bandwidth value is 0.
e. In the Priority, Hold field, specify the RSVP support priorities (setup priority and
hold priority) for the tunnel traffic.
The default is priority 07 and hold 07, which is the standard MPLS LSP definition
in Junos OS.
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 the setup priority of the existing LSP. In addition, the act of
preempting the existing LSP must provide sufficient bandwidth to support the new
LSP. Therefore, preemption occurs only if the new LSP can be set up successfully.
You can configure each LSP with a setup priority and hold priority to provide a
preemption strategy whereby a new LSP can claim resources from an existing LSP.
Each LSP can claim resources from an existing LSP. Priority levels range from 0
(highest priority) through 7 (lowest priority).
If traffic engineering admission control determines that there are insufficient
resources available to accept a request to set up a new LSP, the setup priority is
evaluated against the hold priority of the existing LSPs (per standard Junos OS
behavior). An LSP with a hold priority lower than the setup priority of the new LSP
can be preempted. The existing LSP is terminated to make resources available for
the new LSP.
Copyright © 2015, Juniper Networks, Inc.
27
NorthStar Controller Feature Guide
NOTE: You must assign priorities according to network policies to
prevent resource poaching and LSP thrashing.
NOTE: The hold priority values should be less than or equal to the setup
priority value.
f. (Optional) In the Comment field, provide information that describes the tunnel.
g. (Optional) To schedule LSP creation at some time in the future, select the
Scheduling tab from the Add Tunnel window, schedule a Start Time and an End
Time, and schedule either once or recurring daily.
NOTE: The scheduling time is based on the server time zone rather
than the client time zone.
3. (Optional) Click Display Path to highlight each of the paths that NorthStar calculates
and display the LSP metrics for each path.
4. Click Add to add the tunnel to the network.
The tunnel is now in the planning stage on the network.
5. In the Tunnels table in the Network Info window, select the newly added tunnel and
right-click Provision to provision to the live network.
The Message window displays "Tunnel(s) were successfully pushed."
NOTE: The provisioned tunnels shown in the Network Info table briefly
display “Down” in the Live Status column for a few seconds because it
takes some time to provision the path on the PCC routers through the
RSVP protocol.
You can execute the following commands on the PCC routers to verify that the tunnel
is provisioned.
lab@PE2> show mpls lsp externally-provisioned
lab@PE2> show path-computation-client lsp
Related
Documentation
28
•
Creating Secondary and Standby Label-Switched Paths on page 31
•
Creating Label-Switched Paths That Are Diverse to Each Other on page 29
•
Reoptimizing Label-Switched Paths with the Path Optimization Feature on page 61
•
Optimizing a Label-Switched Path with Path Analysis on page 59
•
Understanding Administrative Status for Label-Switched Paths on page 24
Copyright © 2015, Juniper Networks, Inc.
Chapter 2: Creating Label-Switched Paths
Creating Label-Switched Paths That Are Diverse to Each Other
When creating a route between two sites, you might not want to rely on a single
label-switched path (LSP) to send traffic from one site to another. By creating a second
LSP routing path between the two sites, you can protect against failures and balance
the network load. NorthStar supports site (router), link, and shared link risk group (SLRG)
path diversity.
NOTE: NorthStar calculates the best available diverse path. A group of diverse
LSPs can be added and provisioned even when the paths are not fully disjoint.
In this case, the display path indicates that no path can be found, but the
LSPs can be added and deployed because at this point in time, the diverse
path calculation represents the best available diverse path.
To configure diverse paths in the network topology:
1.
From the Network Info screen, select Add > Diverse Tunnel Pair.
The Add Diverse Tunnel Pair dialog box is displayed, as shown in Figure 3 on page 29.
Figure 3: Add Diverse Tunnel Pair Dialog Box
2. Provide the following information for each tunnel you want to create:
a. In the Tunnel ID field, provide a user-defined name for the tunnel.
The name must be unique for a given ingress node (NodeA), and the name cannot
contain spaces.
NOTE: If a user-defined name is not provided for the tunnel, the PCE
automatically generates a unique name.
b. Select node addresses for the Node A and Node Z fields to define the endpoint
nodes for the tunnel.
Copyright © 2015, Juniper Networks, Inc.
29
NorthStar Controller Feature Guide
NOTE: Tunnel 1 and 2 can use the same source and destination.
c. (Optional) To create a bidirectional tunnel, select the Create identical tunnel(s) on
the same path in opposite direction check box.
d. In the Bandwidth field, specify the bandwidth for the tunnel traffic (bandwidth
applies to each direction).
e. In the Priority, Hold field, specify the RSVP support priorities (setup priority and
hold priority) for the tunnel traffic.
NOTE: The hold priority values should be less than or equal to the setup
priority value.
f. (Optional) In the Comment field, provide information that describes the tunnel.
3. (Optional) Click Display Path to highlight each of the paths that NorthStar calculates
and display the LSP metrics for each path.
4. Click Add to add the paths to the network.
The diverse tunnels are now in the planning stage on the network.
5. Select the tunnels just added from the Tunnel table in the Network Info window and
right-click Provision to provision to the live network.
NOTE: The provisioned tunnels shown in the Network Info > Tunnels table
displays “Down” in the Live Status column for a few seconds because it
takes some time to provision the path on the PCC routers through the
RSVP protocol. The status displays “Up” when the tunnel becomes active
in the network.
6. To view the provisioned tunnels, click Show Path at the bottom of the Network Info
window.
You can also run the following command on the PCC routers to verify that the diverse
tunnels have been provisioned:
lab@PE2> show path-computation-client lsp
To provide more detail about the configured LSPs, run the following command on the
PCC routers:
lab@PE2> show mpls lsp externally-provisioned
Related
Documentation
30
•
Creating a Label-Switched Path on page 26
•
Reoptimizing Label-Switched Paths with the Path Optimization Feature on page 61
•
Optimizing a Label-Switched Path with Path Analysis on page 59
•
Configuring Multiple Label-Switched Paths on page 38
Copyright © 2015, Juniper Networks, Inc.
Chapter 2: Creating Label-Switched Paths
•
Understanding Administrative Status for Label-Switched Paths on page 24
Creating Secondary and Standby Label-Switched Paths
For MPLS-enabled networks, after you configure a label-switched path (LSP), you should
also configure a standby or secondary LSP to provide an alternate route in the event the
primary route fails. The tunnel ID, from node, to node, and IP address of a secondary or
standby tunnel should be identical to that of the primary tunnel. However, secondary
and standby tunnels have the following differences:
•
A secondary tunnel is not routed until the primary tunnel fails.
•
A standby tunnel is routed while the primary tunnel is up.
The following sections describe how to configure standby or secondary LSPs to provide
an alternate route in the event the primary route fails:
•
Creating a Secondary or Standby LSP from the Add Tunnel Window on page 31
•
Creating Multiple Secondary or Standby LSPs from the Diverse Path Design
Window on page 33
Creating a Secondary or Standby LSP from the Add Tunnel Window
After you create a (primary) LSP, you can configure secondary or standby LSP.
To configure a secondary or standby LSP:
1.
From the NorthStar Controller Network Info view, select Add > One Tunnel.
The Add Tunnel dialog box displays the Properties tab.
2. To define an alternate route between the source (Node A) and destination (Node Z)
nodes that is diverse from the path specified in the primary tunnel:
a. From the Paths tab in the Add Tunnel window, click Add Row.
Figure 4: Paths Tab from Add Tunnel Window
b. For explicit routing, from the Map view, click the links/nodes to define an alternate
route between the source (Node A) and destination (Node Z) nodes to provide a
path that is diverse from the path specified in the primary tunnel.
Copyright © 2015, Juniper Networks, Inc.
31
NorthStar Controller Feature Guide
c. From the Paths tab in the Add Tunnel window, right-click the new (empty) row,
and select Use Map Sel’n to show the path (now highlighted) in the Map view.
Figure 5: Enabling the Map Selection Option to Select a Path
The new tunnel is added to a row in the Paths table.
3. To specify the tunnel type:
a. From the Paths table, right-click the row for the new path, and select Edit Type.
The Tunnel Type Parameter Generation dialog box displays the Tunnel Options
from the General tab, as shown in Figure 6 on page 32.
Figure 6: Selecting the Tunnel Type
b. Under Tunnel Option, select Secondary or Standby to specify the tunnel type.
NOTE: The default tunnel type is Primary.
4. Click OK to create the new secondary or standby tunnel.
32
Copyright © 2015, Juniper Networks, Inc.
Chapter 2: Creating Label-Switched Paths
NOTE: From the Network Info > Tunnels table, the Admin_Status column
displays “Planned” in the row that shows the new tunnel.
NOTE: If not explicitly set, the secondary or standby LSP inherits the
parameters (priority/hold/bandwidth) of the primary LSP.
5. Select the row that shows the new tunnel to highlight the tunnel in the Tunnels table
and click Provision > Selected.
A confirmation message “Tunnels were successfully pushed” is displayed.
6. Click OK to close the confirmation message window.
Creating Multiple Secondary or Standby LSPs from the Diverse Path Design Window
When you want to create multiple tunnels to add a mesh of tunnels between two sets
of nodes, you can also create the corresponding secondary or standby tunnels, all at the
same time.
To configure secondary or standby tunnels for a mesh of tunnels:
1.
From the NorthStar Controller Network Info view, select Add > Multiple Tunnels.
The Add Multiple Tunnels dialog box displays the Properties tab.
2. To define the mesh of paths between the source (Node A) and destination (Node Z)
nodes:
a. Click Filter located to the right of the Node A column.
The Find Nodes dialog box displays the Properties tab.
b. In the PCEP field, select true from the drop-down list, as shown in
Figure 7 on page 34.
Copyright © 2015, Juniper Networks, Inc.
33
NorthStar Controller Feature Guide
Figure 7: Selecting “PCEP =True” to Create a Full Mesh Between PCEP
Neighbor Routers
NOTE: Because there are not path options to specify the multiple
tunnels for a full mesh, and it is too complicated to perform from the
Map view, you can specify “PCEP = true” to create a full mesh between
all the PCEP neighbor routers in the topology.
c. Click OK.
All source nodes in the mesh now appear under the Node A column.
d. From the Add Multiple Tunnels dialog box, select Copy A->Z (from lower right area
of the dialog box).
All selected (destination) nodes now also appear under the Node Z column.
3. From the Add Multiple Tunnels window, select Add to add the full mesh of tunnels.
The “Add xx tunnels?” window is displayed.
4. Click Yes to add the full mesh of tunnels.
All tunnels are now created, but at this point none of the tunnels have a corresponding
standby or secondary path.
5. From the NorthStar Controller Main Menu toolbar, select Application > Path Design.
The Diverse Path Design window shows all existing and new paths in table format.
6. From the Diverse Path Design window, select each of the newly created tunnels.
All of the selected tunnels are highlighted in the table.
7. At the bottom of the Diverse Path Design window, select Tune > Selected Paths.
34
Copyright © 2015, Juniper Networks, Inc.
Chapter 2: Creating Label-Switched Paths
The Tuning Tunnels window, shown in Figure 8 on page 35, shows the path options
you can configure to provide primary and backup paths for a tunnel.
Figure 8: Specifying Path Options for Primary and Backup Paths
8. For each of the selected paths, select options for the Primary Path, Backup Path #1,
and Backup Path #2.
Table 5 on page 35 shows some common path design scenarios.
Table 5: Common Path Design Scenarios
Path Type
Common Path Design Settings
Dynamic Primary Path
Use the following settings to configure only a dynamic primary path:
•
Primary Path: “Dynamic”
•
Backup Path #1 and/or Backup Path #2: Select “Change only existing backup” to avoid
creating a backup path.
NOTE: Existing backup paths cannot be removed from this window. To remove existing
backup paths, select Modify > Selected Paths and set Max # Backup Paths to 0.
Explicit Primary Path with
Dynamic Secondary Path
Use the following settings to configure an explicit (nailed down) primary path with a dynamic
secondary path:
•
Primary Path: “Explicit”
•
Backup Path #1: “Dynamic” “Secondary” “Add if missing”
•
Backup Path #2: “Change only existing backup” to avoid creating a tertiary path.
NOTE: Existing backup paths cannot be removed from this window. To remove existing
backup paths, deselect Preserve standby/secondary settings of existing tunnels.
Copyright © 2015, Juniper Networks, Inc.
35
NorthStar Controller Feature Guide
Table 5: Common Path Design Scenarios (continued)
Explicit Primary and Explicit
Standby Path
Use the following settings to configure an explicit primary and explicit standby backup path:
•
Primary Path: “Explicit”
•
Backup Path #1: “Explicit” “Standby” “Add if missing”
•
Backup Path #2: “Change only existing backup” to avoid creating a tertiary path.
NOTE: Note: Existing backup paths cannot be removed from this window. To remove
existing backup paths, deselect Preserve standby/secondary settings of existing tunnels.
Explicit Primary and Explicit
Standby Path with Dynamic
Tertiary Path
Use the following settings to configure an explicit primary and standby backup path and
dynamic tertiary path.
•
Primary Path: “Explicit”
•
Backup Path #1: “Explicit” “Standby” “Add if missing”
•
Backup Path #2: “Explicit” “Secondary” “Add if missing”
NOTE: You can specify one standby path, or any number of secondary
paths, but you cannot configure both secondary and standby paths.
9. Select the default level of path diversity you want to include.
The available options are SRLG/Facility, Link, or Site (“divgrouplevel” in the dparam
file). The default is Site diversity.
NOTE: For IP/MPLS networks, you can set the targeted diversity level on
a per-tunnel basis by modifying the Tunnel Type Parameter window
Diversity tab to override the default for the specified tunnels.
10. Select one of the following options from the Evaluate/Tune Options:
•
Evaluate: Evaluate diverse level without any path design/modification
•
Incremental: Paths that already have explicit routes are not calculated
•
Redesign: Paths that already have explicit routes are recalculated (default)
11. Click OK to activate the configuration settings that you specified in the Basic Options
dialog box.
12. Select the rows that display the new tunnels to highlight the tunnels in the Tunnels
table, and select Provision > Selected to provision to the live network.
A “Tunnels were successfully pushed” confirmation message is displayed.
13. Click OK to close the confirmation message window.
14. To view the provisioned tunnels, select Show Path at the bottom of the Network Info
window.
You can also run the following command on the PCC routers to verify that the tunnels
have been provisioned:
36
Copyright © 2015, Juniper Networks, Inc.
Chapter 2: Creating Label-Switched Paths
lab@PE2> show path-computation-client lsp
To provide more details about the configured LSPs, you can run the following command
on the PCC routers:
lab@PE2> show mpls lsp externally-provisioned
Related
Documentation
•
Creating a Label-Switched Path on page 26
•
Creating Label-Switched Paths That Are Diverse to Each Other on page 29
•
Configuring Multiple Label-Switched Paths on page 38
•
Reoptimizing Label-Switched Paths with the Path Optimization Feature on page 61
•
Optimizing a Label-Switched Path with Path Analysis on page 59
•
Understanding Administrative Status for Label-Switched Paths on page 24
Copyright © 2015, Juniper Networks, Inc.
37
NorthStar Controller Feature Guide
Configuring Multiple Label-Switched Paths
You can quickly configure multiple label-switched paths (LSPs) in the network topology
by selecting Add > Multiple Tunnels. The following example configuration shows how to
create a full mesh of LSPs.
To configure a full mesh of LSPs:
1.
From the Network Info screen, select Add > Multiple Tunnels.
The Add Multiple Tunnels dialog box is displayed, as shown in Figure 9 on page 38.
Figure 9: Add Multiple Tunnels Dialog Box
2. From the Properties tab, provide the following information for the tunnel you want to
create:
•
(Optional) Specify a user-defined name (ID) for the tunnel.
A default tunnel ID is automatically created if not specified by the user.
•
(Optional) Specify a value for the Count field.
Count indicates the number of copies of tunnels to create. The default count value
is 1. If count is 2, all tunnels are created twice.
38
Copyright © 2015, Juniper Networks, Inc.
Chapter 2: Creating Label-Switched Paths
•
Specify the bandwidth for the tunnels.
•
(Optional) Specify the Priority and Hold settings for traffic in each direction.
3. From the Map view, select the source PCC routers in the network to capture the full
mesh topology.
Each of the selected nodes should be highlighted in the Map view.
4. Click Filter from Map.
All the PE routers highlighted in the Map view will appear under the Node A column.
5. Click Copy A->Z.
All the PCC routers will also appear under the Node Z column, which defines the PCC
routers as the destination.
By defining all the PCC routers as both source and destination, you define a full mesh
topology.
6. Select the Scheduling tab.
7. Select the option button Once to specify a one-time event.
8. Under Scheduler, specify the Start and End dates and times for some time in the
future.
NOTE: The time is based on server time zone.
9. Click Add.
A “Tunnels added” message is displayed.
10. Click OK.
From the Network Info screen, the tunnels table shows the newly added tunnels with
the Admin_Status column showing “Planned”.
11. Click Close to close the Add Multiple Tunnels window.
12. Click Add to add the paths to the network.
The full mesh tunnels added are now in the planning stage on the network.
13. In the Tunnels table in the Network Info window, select the tunnels just added, and
right-click Provision to provision to the live network.
NOTE: The provisioned tunnels shown in the Network Info > Tunnels table
will briefly display “Down” in the Live Status column for a few seconds
because it takes some time to provision the path on the PCC routers
through the RSVP protocol. The status will display “Up” when the tunnel
becomes active in the network.
14. (Optional) You can also run the following command on the PCC routers to verify that
the tunnels have been provisioned:
Copyright © 2015, Juniper Networks, Inc.
39
NorthStar Controller Feature Guide
lab@PE2> show path-computation-client lsp
To view more details about the configured LSPs, you can run the following command
on the PCC routers:
user@PE2> show mpls lsp externally-provisioned
Related
Documentation
40
•
Creating Secondary and Standby Label-Switched Paths on page 31
•
Creating Label-Switched Paths That Are Diverse to Each Other on page 29
•
Example: Using Time-Based Calendaring to Schedule Primary, Secondary, and Standby
Label-Switched Paths As MultiPeriod Daily Events on page 47
•
Reoptimizing Label-Switched Paths with the Path Optimization Feature on page 61
•
Understanding Administrative Status for Label-Switched Paths on page 24
Copyright © 2015, Juniper Networks, Inc.
CHAPTER 3
Scheduling Label-Switched Paths Over
Time
•
Understanding Time-Based Calendaring for Label-Switched Paths on page 41
•
Using Time-Based Calendaring to Schedule Label-Switched Paths as a One-Time or
Daily Event on page 43
•
Example: Using Time-Based Calendaring to Schedule Primary, Secondary, and Standby
Label-Switched Paths As MultiPeriod Daily Events on page 47
Understanding Time-Based Calendaring for Label-Switched Paths
You can use time-based calendaring to schedule the setup, modification, and tear down
of label-switched paths (LSPs) based on anticipated changes in LSP requirements over
time. You can schedule an LSP as a one-time event or recurring daily event for a specified
period of time to schedule setup, modification, and tear down of LSPs based on the
traffic load, bandwidth, and setup and hold priority requirements of your network over
time, where the time reference is the server time. The scheduling of an LSP is configured
on the primary path, and the scheduled time applies to all paths (primary, secondary,
and standby).
The following restrictions apply when using time-based calendaring to create, modify,
and tear down LSPs:
•
You can use time-based calendaring to schedule LSP changes on PCE-initiated and
PCC-delegated LSPs, but not on PCC controlled LSPs. When using time-based
calendaring on PCC-delegated LSPs, the LSP is never deleted, but when the LSP’s
time period expires, the bandwidth is set to 0, and no additional parameters are applied.
•
When using time-based calendaring to schedule LSP changes, you cannot change the
LSP (tunnel) name, endpoints, or both the LSP name and endpoints.
Copyright © 2015, Juniper Networks, Inc.
41
NorthStar Controller Feature Guide
NOTE:
The following restrictions apply to explicit route path parameters:
•
You cannot change the explicit route or dynamic route of the primary path,
secondary path, or standby path.
•
To create a different explicit path for the secondary or standby LSP, you
must specify a different name for the LSP.
The following options are supported for time-based calendaring of LSPs:
•
One-time not scheduled (Scheduled: No)—The LSP is created.
•
One-time scheduling (Scheduled: Once)—The LSP is created at the specified Start
Time and deleted at the specified End Time.
•
Daily scheduling (Scheduled: Daily)—On each day, between the Start date and End
date, the LSP is created at the Start Time and deleted at the End Time.
•
Multiple single scheduling (Scheduled : Once + Multiperiod)—The LSP is created at
the Start Time and deleted at the End Time. With multiperiod enabled, multiple entries
with different Start Time, End Time, and LSP parameters are allowed.
•
Multiple daily scheduling (Scheduled : Daily + Multiperiod)— On each day, between
the Start Date and End Date, the LSP is created at Start Time and deleted at End Time.
Several entries with different Start Date, End Date, Start Time, End Time, and Path
parameters are allowed.
With multiperiod scheduling, you can configure overlapping time periods for a given path,
in which case the following behaviors apply:
Related
Documentation
42
•
The primary path is modified but not deleted.
•
The secondary and standby paths are modified if they have the same path name;
otherwise, they are deleted or added.
•
The End Time used is the time specified in the last scheduled time that started. For
example, if the first tunnel is scheduled from 10:00 AM–3:00 PM and a second tunnel
is scheduled from 11:00 AM–2:00 PM, the End Time for the multiperiod is 2:00 PM.
•
Using Time-Based Calendaring to Schedule Label-Switched Paths as a One-Time or
Daily Event on page 43
Copyright © 2015, Juniper Networks, Inc.
Chapter 3: Scheduling Label-Switched Paths Over Time
Using Time-Based Calendaring to Schedule Label-Switched Paths as a One-Time or
Daily Event
The following example shows how you can use time-based calendaring to create and
schedule the setup, modification, and tear down of a label-switched path (LSP). The
scheduling of an LSP is configured on the primary path, and the scheduled time applies
to all paths (primary, secondary, and standby).
NOTE: When using time-based calendaring to schedule LSP changes, you
cannot change the LSP (tunnel) name and/or endpoints.
To use time-based LSP scheduling to add a tunnel in the network topology:
Copyright © 2015, Juniper Networks, Inc.
43
NorthStar Controller Feature Guide
1.
From the Network Info window, select Add > One Tunnel.
The Add Tunnel dialog box displays the Properties tab, as shown in
Figure 10 on page 44.
Figure 10: Add Tunnel Dialog Box
From the Properties tab, provide the following information for the tunnel you want to
create:
a. In the Tunnel ID field, provide a user-defined name for the tunnel.
The name must be unique for a given ingress node (NodeA), and the name cannot
contain spaces.
NOTE: For a multiperiod tunnel, you specify only one Tunnel ID, even
though each period will have different start and end times and can
include different properties (Bandwidth, Priority, Hold, and so forth).
b. Select node addresses for the Node A and Node Z fields to define the endpoint
nodes for the tunnel.
TIP: (Optional) An alternate way to add node addresses for Node A
and Node Z is to select the Auto Add on Mouse Clicks check box, go to
the Map view, and click the nodes to automatically add endpoint nodes
(Node A and Node Z) to generate the tunnel, which is displayed with
the Admin_Status column showing “Planned” from the Network Info
screen. If you choose this option, you can then select the tunnel from
the Tunnel table in the Network Info window, and right-click Modify to
change other settings for the tunnel including Bandwidth, Priority and
Hold settings, and scheduling options.
c. (Optional) To create a bidirectional tunnel, select the Create identical tunnel(s) on
same path in opposite direction check box.
d. In the Bandwidth field, specify the bandwidth for the tunnel traffic (bandwidth
applies for each direction).
44
Copyright © 2015, Juniper Networks, Inc.
Chapter 3: Scheduling Label-Switched Paths Over Time
e. In the Priority, Hold field, specify the RSVP support priorities (setup priority and
hold priority) for the tunnel traffic.
NOTE: The hold priority values should be less than or equal to the setup
priority value.
f. (Optional) In the Comment field, provide information that describes the tunnel.
2. Select the Scheduling tab.
3. Click the option button Daily to create the tunnel as a daily (as opposed to a one-time)
event.
4. To configure a multiperiod LSP that allows you to schedule multiple start and end
times for the LSP, complete the following steps:
a. Select the MultiPeriod checkbox.
The Scheduling window displays the scheduler for the Start and End dates and
times, as shown in Figure 11 on page 45.
Figure 11: Scheduling Window with MultiPeriod Enabled
b. Under Daily Scheduler, specify the Start and End dates and times for the first tunnel
period.
c. Click Add (from the Scheduling tab).
A “Tunnel added” message is displayed.
d. Click OK.
From the Network Info screen, the tunnels table displays the scheduled tunnel with
the Admin_Status column showing “Planned”.
NOTE: Steps 5 and 6 below describe how to specify a second tunnel period
for this daily, multiperiod tunnel configuration.
Copyright © 2015, Juniper Networks, Inc.
45
NorthStar Controller Feature Guide
5. Select the Properties tab to specify the tunnel attributes to apply during the specified
tunnel (period):
a. (Optional) To create a bidirectional tunnel, select the Create identical tunnel(s) on
same path in opposite direction check box.
b. In the Bandwidth field, specify the bandwidth for the tunnel traffic.
c. In the Priority, Hold field, specify the setup priority and hold priority for the tunnel
traffic.
NOTE: The hold priority value should be less than or equal to the setup
priority value.
6. Select the Scheduling tab to schedule the time during which the tunnel period will be
active:
a. Specify the Start and End dates and times during which time the tunnel will be
active.
b. Click Add (from the Tunneling tab).
A “Tunnel added” message is displayed.
c. Click OK.
From the Network Info screen, the tunnels table displays the scheduled tunnel with
the Admin_Status column showing “Planned”.
NOTE: Repeat Step 5 and Step 6 for each additional tunnel period that
will run as a one-time event to define the tunnel properties and the Start
and End dates and times during which the tunnel will run.
7. From Tunnel table in the Network Info window, select the first entry for the time-based
tunnel that you added, and right-click Provision.
After provisioning a time-based multiperiod tunnel, for each tunnel period you specified
in the preceding steps, a tunnel will be created with the defined tunnel properties at
the specified Start Time. The tear-down of the LSP will occur after the last End Time
that you specified. Figure 12 on page 46 shows the display of a multiperiod tunnel after
provisioning.
Figure 12: Display of Provisioned MultiPeriod Tunnel
46
Copyright © 2015, Juniper Networks, Inc.
Chapter 3: Scheduling Label-Switched Paths Over Time
NOTE: The provisioned tunnel shown in the Network Info table will briefly
display “Down” in the Live Status column for a few seconds because it
takes some time to provision the path on the PCC routers through the
RSVP protocol.
You can execute the following commands on the PCC routers to verify that the tunnel
is provisioned.
lab@PE2> show mpls lsp externally-provisioned
lab@PE2> show path-computation-client lsp
Related
Documentation
•
Understanding Time-Based Calendaring for Label-Switched Paths on page 41
•
Example: Using Time-Based Calendaring to Schedule Primary, Secondary, and Standby
Label-Switched Paths As MultiPeriod Daily Events on page 47
•
Creating Label-Switched Paths That Are Diverse to Each Other on page 29
•
Reoptimizing Label-Switched Paths with the Path Optimization Feature on page 61
•
Configuring Multiple Label-Switched Paths on page 38
•
Understanding Administrative Status for Label-Switched Paths on page 24
Example: Using Time-Based Calendaring to Schedule Primary, Secondary, and Standby
Label-Switched Paths As MultiPeriod Daily Events
This example shows how to use time-based calendaring to create and schedule the
setup, modification, and tear down of primary, standby, and secondary LSPs; and to
adjust the bandwidth, priority and hold settings, and path to address changes in network
demand and requirements over time. To schedule the LSPs for each consecutive time
period, you must start by creating the first primary tunnel as a multiperiod tunnel, and
then add additional periods during which each additional tunnel (with its own type,
properties, bandwidth, schedule, and so forth) will run. The scheduled time applies to
all tunnel types (primary, secondary, and standby) configured for that particular time
period.
NOTE: When using time-based calendaring to schedule LSP changes over
time, you cannot change the tunnel ID or tunnel endpoints. Each tunnel
included in a multiperiod configuration must have the same tunnel ID and
tunnel (node) endpoints.
The configuration steps that follow are intended as an example to illustrate the key steps
required to schedule daily multiperiod LSPs over a period of 1 month with the following
constraints:
•
First period: Daily from 8:00 AM–11:00 AM, schedule primary and secondary LSPs to
handle high priority traffic with medium/high volume IP/MPLS flows in the network.
Copyright © 2015, Juniper Networks, Inc.
47
NorthStar Controller Feature Guide
•
Second period: Daily from 11:00 AM–2:00 PM, schedule a primary LSP to handle lower
priority traffic with low to moderate volume IP/MPLS flows in the network.
•
Third period: Daily from 2:00 PM–5:00 PM, schedule primary and standby LSPs to
handle high priority traffic with high volume IP/MPLS flows in the network.
The following sections show how to use time-based calendaring to create and schedule
the setup, modification, and tear down of primary, standby, and secondary LSPs; and
adjust the bandwidth, priority and hold settings, and path to address changes in network
demand and requirements over time:
•
Configuring a Primary and Secondary LSP for the First Scheduled Period on page 48
•
Configuring a Primary LSP for the Second Period on page 51
•
Configuring a Primary and Standby LSP for the Third Scheduled Period on page 53
•
Provisioning a Multiperiod Tunnel on page 56
Configuring a Primary and Secondary LSP for the First Scheduled Period
To use time-based label-switched path (LSP) scheduling to add a primary and secondary
tunnel in the network topology:
1.
From the Network Info window, select Add > One Tunnel.
The Add Tunnel dialog box is displayed.
2. From the Properties tab, provide the following information for the tunnel you want to
create:
a. In the Tunnel ID field, provide a user-defined name for the tunnel.
The name must be unique for a given ingress node (Node A) and not contain spaces.
b. Select node addresses for the Node A and Node Z fields to define the endpoint
nodes for the primary tunnel, and create a dynamic path.
c. In the Bandwidth field, specify 100 mbps as the bandwidth for the tunnel traffic.
d. In the Priority, Hold field, specify the RSVP support priorities 07,07 for the tunnel
traffic.
NOTE: The hold priority values should be less than or equal to the setup
priority value.
Figure 13 on page 49 shows the configured Add Tunnel > Properties tab dialog box.
48
Copyright © 2015, Juniper Networks, Inc.
Chapter 3: Scheduling Label-Switched Paths Over Time
Figure 13: Properties Tab for Add Tunnel Dialog Box
3. To add a secondary tunnel, click the Paths tab.
4. To add a secondary path with an explicit route between the source (Node A) and
destination (Node Z) nodes:
a. From the Paths tab in the Add Tunnel window, click Add Row, as shown in
Figure 14 on page 49.
Figure 14: Paths Tab from Add Tunnel Window
b. For explicit routing, from the Map view, click the links/nodes to define an alternate
route between the source (Node A) and destination (Node Z) nodes to provide a
path that is diverse from the path specified in the primary tunnel.
NOTE: The explicit path you select should be highlighted in the Map
view.
c. From the Paths tab in the Add Tunnel window, right-click the new (empty) row,
and select Use Map Sel’n, as shown in Figure 15 on page 50 to show the path (now
highlighted) in the Map view.
Copyright © 2015, Juniper Networks, Inc.
49
NorthStar Controller Feature Guide
Figure 15: Enabling the Map Selection Option to Select an Explicit Path
The new tunnel is added to a row in the Paths table.
d. From the Paths table, right-click the row for the new path, and select Edit Type.
The Tunnel Type Parameter Generation dialog box is displayed.
e. From the General tab, select the Tunnel Option Secondary to specify the tunnel
type, as shown in Figure 16 on page 50.
Figure 16: Selecting a Secondary Tunnel
f. Click OK to add the secondary tunnel.
5. To configure a multiperiod LSP that allows you to schedule multiple start and end
dates and times for the LSPs:
a. Select the Scheduling tab.
The scheduling window is displayed.
b. Click the option button Daily to create the tunnel as a daily scheduled event.
c. Select the MultiPeriod checkbox.
50
Copyright © 2015, Juniper Networks, Inc.
Chapter 3: Scheduling Label-Switched Paths Over Time
The Scheduling window displays the scheduler for the Start and End dates and
times.
d. Under Daily Scheduler, specify the Start and End dates (2/15/15 to 3/15/15) and
times (8:00 AM—11:00 AM) during which the first tunnel period will be active, as
shown in Figure 17 on page 51.
Figure 17: Scheduling the First Period During Which the Primary and
Secondary Tunnels Are Up
e. Click Add (from the Scheduling tab).
A “Tunnel added” message is displayed.
f. Click OK.
From the Network Info screen, the tunnels table displays the scheduled tunnel with
the Admin_Status column showing “Planned”.
NOTE: If you select the Properties tab from the Add Tunnel dialog box,
the Tunnel ID, Node A and Node Z, and all the settings you configured
when creating the primary tunnel are still displayed.
Configuring a Primary LSP for the Second Period
To use time-based label-switched path (LSP) scheduling to create a primary tunnel in
the network topology to run during the second scheduled period:
1.
From the Network Info window, select Add > One Tunnel.
The Add Tunnel dialog box is displayed.
2. From the Properties tab, provide the following information for the tunnel you want to
create:
a. In the Tunnel ID field, provide the same name for the tunnel that you specified for
the first tunnel period.
b. Select the same node endpoints for the Node A and Node Z fields that you specified
to define the endpoint nodes for the first tunnel period.
Copyright © 2015, Juniper Networks, Inc.
51
NorthStar Controller Feature Guide
c. In the Bandwidth field, specify 50 mbps as the bandwidth for the primary tunnel
traffic.
d. In the Priority, Hold field, specify the RSVP support priorities 06,06 for the tunnel
traffic.
NOTE: The hold priority value should be less than or equal to the setup
priority value.
3. Configure a multiperiod LSP to schedule the daily start and end times for the LSP.
a. Click the option button Daily to create the tunnel as a daily scheduled event.
b. Select the MultiPeriod checkbox.
The Scheduling window displays the scheduler for the Start and End dates and
times.
c. Under Daily Scheduler, specify the same Start and End date for the second tunnel
period that you specified for the first tunnel period, but add new Start and End
times (11:00 AM to 14:00 PM), as shown in Figure 18 on page 52.
Figure 18: Scheduling Window with MultiPeriod Enabled for Second Period
d. Click Add from the Scheduling tab).
A “Tunnel added” message is displayed.
e. Click OK.
From the Network Info screen, the tunnels table displays the scheduled tunnel with
the Admin_Status column showing “Planned” and the Type column showing “R,
MultiPeriod”.
NOTE: Do not close the Add Tunnel screen, which is still displayed after
you add the first (primary) tunnel. The following steps describe how to
add a secondary tunnel based on the primary tunnel and the daily
multiperiod tunnel.
52
Copyright © 2015, Juniper Networks, Inc.
Chapter 3: Scheduling Label-Switched Paths Over Time
NOTE: If you select the Properties tab from the Add Tunnel dialog box,
the Tunnel ID, Node A and Node Z, and all the other settings you added
when creating the primary tunnel are still displayed.
Configuring a Primary and Standby LSP for the Third Scheduled Period
To use time-based label-switched path (LSP) scheduling to add a primary and standby
tunnel in the network topology:
1.
From the Network Info window, select Add > One Tunnel.
The Add Tunnel dialog box is displayed.
2. From the Properties tab, provide the following information for the tunnel you want to
create:
a. In the Tunnel ID field, provide the same name for the tunnel that you specified for
the first tunnel period.
b. Select the same node endpoints for the Node A and Node Z fields that you specified
to define the endpoint nodes for the first tunnel period.
c. In the Bandwidth field, specify 200 mbps as the bandwidth for the primary tunnel
traffic.
d. In the Priority, Hold field, specify the RSVP support priorities 09,09 for the tunnel
traffic.
NOTE: The hold priority values should be less than or equal to the setup
priority value.
3. Select the Scheduling tab.
4. To add a standby tunnel, click the Paths tab.
Copyright © 2015, Juniper Networks, Inc.
53
NorthStar Controller Feature Guide
5. To define a standby path with an explicit route between the source (Node A) and
destination (Node Z) nodes:
a. From the Paths tab in the Add Tunnel window, click Add Row.
Figure 19: Paths Tab from Add Tunnel Window
b. For explicit routing, from the Map view, click the links/nodes to define an alternate
route between the source (Node A) and destination (Node Z) nodes to provide a
path that is diverse from the path specified in the primary tunnel.
NOTE: The explicit path you select should be highlighted in the Map
view.
c. From the Paths tab in the Add Tunnel window, right-click the new (empty) row,
and select Use Map Sel’n to show the path (now highlighted) in the Map view.
Figure 20: Enabling the Map Selection Option to Select an Explicit Path
The new tunnel is added to a row in the Paths table.
d. From the Paths table, right-click the row for the new path, and select Edit Type.
The Tunnel Type Parameter Generation dialog box displays the Tunnel Options
from the General tab
e. Under Tunnel Option, select Standby to specify the tunnel type, as shown in
Figure 21 on page 55.
54
Copyright © 2015, Juniper Networks, Inc.
Chapter 3: Scheduling Label-Switched Paths Over Time
Figure 21: Selecting the Standby Tunnel Type
f. Click OK to create a standby tunnel.
6. To configure a multiperiod tunnel that runs from 2:00 PM to 5:00 PM daily, complete
the following steps:
a. Click the option button Daily to create the tunnel as a daily scheduled event.
b. Select the MultiPeriod checkbox.
The Scheduling window displays the scheduler for Start Date, End Date, Start
Time, and End Time.
c. Under Daily Scheduler, specify the same start and end date for the third tunnel
period that you specified for the first and second tunnel periods, but add a new
Start Time and End Time (14:00 PM to 17:00 PM), as shown in Figure 22 on page 55.
Figure 22: Scheduling Window with MultiPeriod Enabled for Third Period
d. Click Add (from the Scheduling tab).
A “Tunnel added” message is displayed.
e. Click OK.
Copyright © 2015, Juniper Networks, Inc.
55
NorthStar Controller Feature Guide
From the Network Info screen, the tunnels table displays the scheduled tunnel. In
the Admin_Status column the tunnel row should display “Period_Not_Active”, and
the Type column should display “R, STANDBY”.
Provisioning a Multiperiod Tunnel
The Admin_Status column will display “Planned” for first tunnel entry that you configured
for a multiperiod tunnel configuration. For all other scheduled tunnel periods in the
multiperiod, the Admin_Status column displays "Period_Not_Active".
To provision a multiperiod tunnel:
1.
From the Tunnel table in the Network Info window, select the first tunnel entry for a
time-based multiperiod tunnel, and right-click Provision.
After provisioning a multiperiod tunnel, the Admin_Status column displays
“Callsetup_Scheduled” as shown in Figure 23 on page 56. Each tunnel in the multiperiod
will be created at the Start Time that you specified, and the tear-down of the tunnel
will be at the End Time that you specified.
Figure 23: Admin Status for MultiPeriod Tunnels After Provisioning the
Configured MultiPeriod Tunnels
To verify that the multiperiod tunnels are provisioned during the scheduled times, you
can execute the following commands on the PCC routers:
lab@PE2> show mpls lsp externally-provisioned
lab@PE2> show path-computation-client lsp
Related
Documentation
56
•
Understanding Time-Based Calendaring for Label-Switched Paths on page 41
•
Using Time-Based Calendaring to Schedule Label-Switched Paths as a One-Time or
Daily Event on page 43
•
Creating Label-Switched Paths That Are Diverse to Each Other on page 29
•
Reoptimizing Label-Switched Paths with the Path Optimization Feature on page 61
•
Configuring Multiple Label-Switched Paths on page 38
•
Understanding Administrative Status for Label-Switched Paths on page 24
Copyright © 2015, Juniper Networks, Inc.
CHAPTER 4
Managing and Optimizing Label-Switched
Paths
•
Using Delta Provisioning to Modify an Existing Label-Switched Path on page 58
•
Optimizing a Label-Switched Path with Path Analysis on page 59
•
Reoptimizing Label-Switched Paths with the Path Optimization Feature on page 61
•
Understanding TE++ Label-Switched Paths on the NorthStar Controller on page 63
•
Viewing Label-Switched Path Changes on page 65
•
Disabling Provisioning of Label-Switched Paths from the NorthStar Controller
CLI on page 66
•
Disabling Provisioning of Label-Switched Paths from the NorthStar Controller User
Interface on page 68
Copyright © 2015, Juniper Networks, Inc.
57
NorthStar Controller Feature Guide
Using Delta Provisioning to Modify an Existing Label-Switched Path
The delta provisioning feature shows the list of LSP changes between the planned state
(from path optimization, user changes, and so forth) and allows you to select changes
to be applied or to revert to current LSP state. You can also schedule the provisioning of
LSPs all at once or at some future date and time.
LSPs in any of the following states are remembered and displayed in the Delta Provisioning
window:
•
New LSPs that are scheduled for provisioning
•
Existing LSPs that are scheduled for modification
•
Existing LSPs that are scheduled for deletion
•
LSPs that are down in the network
You can access the Delta Provisioning window to manage pending LSP changes in the
network and perform the following tasks:
•
Select one or more LSPs that you want to commit for provisioning in the NorthStar
Controller. You can commit changes for new, modified, deleted, or live-down LSPs.
•
Revert an LSP back to its previous state before the planned configuration changes.
After an LSP is provisioned, it is removed from the Delta Provisioning window.
To use Delta Provisioning to provision any number of planned LSPs (new, modified,
deleted, or live-down):
1.
From the Network Info screen, select the Tunnels tab to display the LSPs.
2. Select Provision > Delta Provisioning to show the LSPs that have been added, modified,
deleted, and brought down.
Figure 24 on page 58 shows the Delta Provisioning window.
Figure 24: Delta Provisioning Window
3. Select the tab (New Tunnels, Modified Tunnels, Deleted Tunnels, or Live/Down Tunnels)
that displays the LSPs that you want to view and possibly provision.
58
Copyright © 2015, Juniper Networks, Inc.
Chapter 4: Managing and Optimizing Label-Switched Paths
NOTE: When the NorthStar Controller Path Computation Server (PCS)
detects that an LSP is down, the down LSP will appear in the Live/Down
Tunnel list. The PCS will attempt to provision the LSP immediately after
it goes down and then again after 1 minute, and then every X minutes up
to 15 minutes max. After the 15 minute max delay is reached, the PCS will
continue to try to find a route for the LSP every 15 minutes. If the LSP
comes back up after a short period of time, the LSP is re-initialized and
automatically removed from the Live-Down Tunnel list. If the LSP does
not come back up and remains in the list, you can try to manually provision
the LSP from the Delta Provisioning window.
NOTE: To check when the PCS will again attempt to calculate/provision
the LSP, you can view the next scheduled time in the Admin_Status column
from the Network Info > Tunnels window.
4. Select the check box in the Provision or Revert column for each LSP that you want to
provision or revert back to its previous state.
5. Click Execute to provision a tunnel or to revert an LSP back to its previous state.
NOTE: After an LSP is provisioned or reverted back to its previous state,
it no longer appears in the Delta Provisioning window.
Related
Documentation
•
Reoptimizing Label-Switched Paths with the Path Optimization Feature on page 61
•
Creating a Label-Switched Path on page 26
•
Creating Label-Switched Paths That Are Diverse to Each Other on page 29
•
Configuring Multiple Label-Switched Paths on page 38
•
Understanding Administrative Status for Label-Switched Paths on page 24
Optimizing a Label-Switched Path with Path Analysis
You can use Path Analysis to improve path placement by using available bandwidth.
Path Analysis will try those paths that indicate the best possible improvements first, but
does not support preemption. Path Analysis allows you to view the recommended new
path changes, and then prompts you to provision or undo the new path changes from
the Path Analysis window. Path Analysis computes a Best Path and New Path. The Best
Path ignores bandwidth that is used by other path. The New Path takes into consideration
bandwidth that is used by other LSPs. When prompted to provision a path, the provisioned
path will use the recommended New Path.
Copyright © 2015, Juniper Networks, Inc.
59
NorthStar Controller Feature Guide
You can use Path Analysis to perform the following tasks:
•
Verify that a path is on its best possible path, which is displayed in the Best Path column.
The best path assumes no other LSP is in the network.
•
Perform optimization to find a better path, which is displayed in the New Path column.
•
Provision LSPs from the New Path column to provision better paths that have not been
executed.
•
Determine which paths to Provision and which paths to revert back to live routes (by
using the Undo option).
NOTE: When you use Path Analysis to provision paths, those paths with the
best potential improvement are routed first. However, any LSP that has a
"required" or "select" configured path setting is ignored and not a constraint
for path calculation using Path Analysis.
To use Path Analysis to view LSPs and perform path optimization for any LSPs that are
not currently optimal paths:
1.
From the NorthStar Controller main window menu options, select Application > Path
Analysis to view LSPs in the network that are not on the best possible path.
Figure 25 on page 60 shows the Path Analysis window.
Figure 25: Original and Optimal Paths Displayed in Path Analysis
For each non-optimal LSP, the Path Analysis window displays a column that shows
the current (Orig Path) and the Best Path.
2. Select a non-optimal LSP from the Path Analysis table and click View Paths.
From the Paths window, you can view details about the Original Path and Best Path
before optimizing the LSP.
3. To optimize LSPs, use one of the following Optimize options:
60
•
To optimize all LSPs displayed in the Path Analysis table, click Optimize > All.
•
To optimize selected LSPs, highlight the LSPs from the Path Analysis window and
click Optimize > Selected.
Copyright © 2015, Juniper Networks, Inc.
Chapter 4: Managing and Optimizing Label-Switched Paths
NOTE: To optimize an LSP from the NorthStar Controller, the LSP Type
must be "PCE_INITIATED“ or “PCC_DELEGATED”.
4. Select the optimized LSP from the Path Analysis table and click View Paths.
5. Close the Path Analysis window.
You will receive a prompt to Undo or Provision the suggested path changes.
6. Undo or Provision the path changes.
Related
Documentation
•
Reoptimizing Label-Switched Paths with the Path Optimization Feature on page 61
•
Using Delta Provisioning to Modify an Existing Label-Switched Path on page 58
•
Understanding Administrative Status for Label-Switched Paths on page 24
Reoptimizing Label-Switched Paths with the Path Optimization Feature
In most cases, the label-switched paths (LSPs) configured on the NorthStar Controller
are optimal paths. However, you can perform path optimization to route LSPs according
to the order you specify (the default is high priority, high bandwidth first). If better routes
are found using the bandwidth available to the priority level of the LSP, a new route is
chosen. If an LSP’s path is taken by another higher priority LSP, it is rerouted. At the end
of path optimization, all the changes are provisioned. Path optimization follows the setup
and hold priority requirements that a user specifies to determine the order of path tuning.
A priority LSP can take bandwidth from an LSP that has a lower hoId priority. If a better
path is available, LSP provisioning is immediately scheduled.
If diversity group or symmetric group constraints are assigned to LSPs, the optimization
subroutine routes the paths by following the diversity and symmetric requirements. When
you use path optimization, high priority LSPs have shorter paths than lower priority LSPs,
and to some extent, path optimization improves the path based on the user’s setup and
hold priority requirements.
To automatically reoptimize all LSPs that require path optimization:
1.
Select Application > Path Optimization.
The Path Optimization dialog box is displayed, as shown in Figure 26 on page 61.
Figure 26: Path Optimization Dialog Box
Copyright © 2015, Juniper Networks, Inc.
61
NorthStar Controller Feature Guide
2. Schedule recurrent path optimization or initiate a one-time path optimization event.
•
To schedule recurrent path optimization:
a. In the Time Interval field, specify the time interval in minutes between path
optimization events.
For example, to schedule path optimization every hour, enter 60; to schedule
path optimization every 8 hours, enter 480.
b. Select Schedule Task.
Path Optimization automatically reoccurs based on the time interval you specified
and optimizes all tunnels that require optimization.
NOTE: You can check the scheduled path optimization time interval
from the Server Status tab on the Console.
•
To schedule one-time path optimization, select Optimize Now.
Path Optimization is initiated on all tunnels that require optimization.
NOTE: To disable path optimization, enter 0 in the Time Interval field and
select Schedule Task.
Related
Documentation
62
•
Optimizing a Label-Switched Path with Path Analysis on page 59
•
Creating a Label-Switched Path on page 26
•
Creating Label-Switched Paths That Are Diverse to Each Other on page 29
•
Configuring Multiple Label-Switched Paths on page 38
•
Using Delta Provisioning to Modify an Existing Label-Switched Path on page 58
Copyright © 2015, Juniper Networks, Inc.
Chapter 4: Managing and Optimizing Label-Switched Paths
Understanding TE++ Label-Switched Paths on the NorthStar Controller
A TE++ tunnel includes a set of paths that are configured as a specific container statement
and individual label-switched path (LSP) statements that are called sub-LSPs. A TE++
tunnel enables load balancing across multiple point-to-point member LSPs between
the same ingress and egress routers. When the path bandwidth is sufficient, the member
LSPs, each of which has equal bandwidth, will take the same best path. However, if the
bandwidth is overloaded on the original path, some member LSPs will take an alternate
path.
Based on the configuration and aggregate traffic, a container LSP provides support for
dynamic bandwidth management by enabling the ingress router to dynamically add and
remove member LSPs through a process called LSP splitting and LSP merging,
respectively. Member LSPs can also be re-optimized with different bandwidth values in
a make-before-break way.
NOTE: TE++ functionality is supported only on Juniper Network routers.
A process called normalization occurs when the following two triggers are initiated that
will cause an LSP to be resized:
•
A periodic retry timer— When this fires, the container LSP is checked to see if it came
up with the last normalization result (the number of members, per member bandwidth)
If not, the number of members is incremented and retried. When the retry limit is
reached, the work-in-progress member LSP that is set from the last retry is accepted
for forwarding, if it improves routing of LSPs compared to the current member-set
contributing to the next hop (in incremental normalization mode). If the mode is set
to no-incremental and the retry limit is reached, the current set is retained and the
intermediate set of signaled members is reverted. Normalization retry duration is greater
than the regular LSP retry duration.
•
Bandwidth thresholds are reached.
When these triggers are initiated, one of the following events occur:
•
The LSP requires no change.
•
LSP splitting—An LSP is added and bandwidth is redistributed across all LSPs.
•
LSP merging—An LSP is deleted and bandwidth is redistributed across all remaining
LSPs.
TE++ is supported on the following types of LSPs:
•
Router controlled TE++ LSP—For these LSPs, the controller’s objective is to learn the
sub-LSPs. The association object is used to report the LSP container and the sub-LSPs.
Statistical accounting for bandwidth for the sub-LSPs is performed at the PCC and
based on the bandwidth threshold triggers, the resizing of LSPs is performed from the
PCC, and the NorthStar Controller is updated accordingly.
Copyright © 2015, Juniper Networks, Inc.
63
NorthStar Controller Feature Guide
•
Delegated TE++ LSP—Like auto-bandwidth, the bandwidth accounting for these LSPs
is performed at the PCC. When the thresholds are reached, the PCC determines how
to resize the sub-LSPs and issues LSPs a PCReq message to the PCS server to compute
the Explicit Route Object (ERO). The PCS server responds by sending a new ERO and
bandwidth to the PCC, which the PCC will apply to the TE++ LSP. Each sub-LSP is
delegated by sending PCRpt messages, which are sent with the Delegation bit set. The
association object carried in the PCRpt message binds the sub-LSPs to a TE++
container.
NOTE: As is also true for LSPs with auto-bandwidth enabled, to avoid the
potential multiple writer issue, the Northstar Controller is not allowed to
modify the bandwidth of a TE++ LSP that has auto-bandwidth enabled,
but unlike auto-bandwidth LSPs, where a PCC sends an error back when
bandwidth is changed on the controller, the controller is aware of the
presence of TE++ LSPs, so the Path Computation Server (PCS) does not
allow changing the bandwidth for TE++ LSPs on the NorthStar Controller.
NOTE: The NorthStar Controller does not support controller-created TE++
LSPs.
When a TE++ LSP is configured as externally controlled, local path computation is
disabled, and an association object is created. Any time a TE++ LSP is configured, the
sub-LSPs operational state will be down because the PCC expects the PCE (NorthStar
Controller) to send an ERO . To trigger this operation, the PCC sends a PCReq (request)
message. In turn, the NorthStar Controller sends a PCRep (response) message with the
ERO to the PCC, which is signaled with RSVP-TE. The signaled state of the LSP is then
reported using a PCRpt message to the NorthStar Controller. The PCRpt message carries
the association object that binds the sub-LSPs to a container. This same mechanism is
applied any time existing TE++ LSPs are delegated.
For TE++ LSPs, path computation for all the sub-LSPs is a dependent, collective operation
that cannot be performed individually. For example, if only 25 mbps of available bandwidth
is available and the PCC requests six LSPs of 5 Mbps each, the setup of the TE++ LSP
should fail. If each path is computed independently, the result is five paths of 5 Mbps
each. Because TE++ path computation is for all TE++ LSPs (or no TE++ LSPs), path
computation must be performed collectively.
The synchronization of a set of path computation requests is achieved by using the
Synchronization VECtor (SVEC) object, defined in RFC 5440, which allows a PCC to
request the synchronization of a set of dependent or independent path computation
requests.
Related
Documentation
64
•
Understanding the NorthStar Controller on page 15
•
Understanding Label-Switched Paths on the NorthStar Controller on page 23
Copyright © 2015, Juniper Networks, Inc.
Chapter 4: Managing and Optimizing Label-Switched Paths
Viewing Label-Switched Path Changes
To identify the root cause of customer issues on service level agreement (SLA) violations,
you can view changes to the label-switched path (LSP) carrying customer traffic that
occurred during the time period in which the violation occurred. The NorthStar Controller
records all LSP events, allowing users to query on those LSP changes, such as path and
bandwidth changes, over any specified time period.
To view LSP change events from the NorthStar Controller user interface:
1.
Select a tunnel entry from the Network Information > Tunnel window, and right-click
View LSP Events.
The Retrieving LSP Events dialog box is displayed, as shown in Figure 27 on page 65.
Figure 27: Selecting a Time Range to View LSP Events
NOTE: The End Time automatically uses the current server time.
2. Select the start date and time from the Start Time field to identify the start date and
time of the LSP events you want to view.
3. Select the end date and time from the End Time field to identify the end date and
time of the LSP events you want to view.
4. Click OK.
All LSP events that trigger actual LSP changes are displayed in table format.
Table 6 on page 65 describes the fields displayed in the LSP Events table.
Table 6: Default Fields Displayed for LSP Events
Field
Description
Time Stamp
The PCS event time stamp in the database.
Action
The action that triggered the tunnel change.
PCS Event
The description of the event.
Copyright © 2015, Juniper Networks, Inc.
65
NorthStar Controller Feature Guide
Table 6: Default Fields Displayed for LSP Events (continued)
LSP Type
The LSP type—PCC Delegated, PCC Initiated, or Blank field, which indicates PCC
Controlled.
Name
The name of the LSP.
NodeA.ID
The node ID of the LSP head end.
NodeZ.ID
The node ID of the LSP tail end.
Bandwidth
The LSP bandwidth.
Priority
The LSP priority.
Hold
The LSP hold.
Path Name
The LSP path name.
Configured Path
The Explicit Route Object (ERO).
Current Path
The Record Route Object (RRO).
Type
NorthStar Controller informational fields.
The LSP Events window also supports the following functionality:
•
Show Path—Highlights the LSP path in the topology map window. The path
highlighted uses the current path (RRO).
•
Filter—Filters the entry results in the LSP Events table by using string matching.
•
Export—Exports the table to a text file.
•
Animate—Steps through the entries in the table and displays the current path of
the event in the topology window.
Related
Documentation
•
Viewing Link Event Changes on page 71
•
Viewing Node Event Changes on page 73
Disabling Provisioning of Label-Switched Paths from the NorthStar Controller CLI
You can disable provisioning of LSPs from the NorthStar Controller CLI to allow all users
to view the live network from the NorthStar Controller and plan network changes (such
as adding or deleting tunnels) without actually provisioning any of those changes to the
live network. A NorthStar Controller administrator can disable provisioning of
label-switched paths (LSPs) for all users of the NorthStar Controller user interface.
66
Copyright © 2015, Juniper Networks, Inc.
Chapter 4: Managing and Optimizing Label-Switched Paths
NOTE: When provisioning of LSPs is disabled, any planned LSP changes
initiated from the NorthStar Controller user interface while passive monitor
mode is enabled will be lost when passive monitor mode is disabled (and
provisioning of LSPs is again enabled).
To enable passive monitor mode on the NorthStar Controller user interface:
1.
From the CLI, log in to the NorthStar Controller Path Computation Server (PCS) and
enter the username root and password northstar, for example:
[northstar_manager-bash-4.1]$ ssh [email protected]
2. Bring down the PCS service on the NorthStar Controller.
[root@pcs~]# service pcs stop
3. Navigate to the data directory.
[root@pcs~]# cd /u/wandl/data
4. Navigate to the .network directory, which contains the network modeling files.
[root@pcs data]# cd .network
5. Using a text editor, open the dparam.x control file.
[root@pcs .network]# vi dparam.x
6. To enable passive monitor mode on the NorthStar Controller, from the dparam.x
control file, search for pcsmonitor and set pcsmonitor=1.
NOTE: If pcsmonitor is not included in the dparam.x file, you can insert it.
Juniper Networks recommends that you add pcsmonitor under the ###
Misc section.
7. Restart the PCS service on the NorthStar Controller.
[root@pcs~]# service pcs start
When passive monitor mode is enabled, the Provision option is disabled from the
Network Info > Tunnels window in the NorthStar Controller user interface. The Provision
option is also disabled from the menu of options that display when you right-click on
a Planned tunnel from the Network Info > Tunnels window.
NOTE: To disable passive monitor mode at any time, you can perform the
steps above to open the dparam.x file and setting pcsmonitor=0.
Copyright © 2015, Juniper Networks, Inc.
67
NorthStar Controller Feature Guide
Related
Documentation
•
Disabling Provisioning of Label-Switched Paths from the NorthStar Controller User
Interface on page 68
Disabling Provisioning of Label-Switched Paths from the NorthStar Controller User
Interface
You can disable provisioning from the NorthStar Controller user interface to allow all
users to view the live network from the NorthStar Controller and plan network changes
(such as adding or deleting tunnels) but without provisioning any of those changes to
the live network.
NOTE: When a NorthStar Controller administrator disables provisioning of
label-switched paths for all NorthStar Controller users, any LSPs that are in
the Planned state, will remain in that Planned state even after provisioning
is disabled for some period of time and then enabled again.
To disable provisioning of LSPs for all NorthStar Controller users, a NorthStar Controller
Administrator can perform the following steps:
1.
From the NorthStar Controller user interface, navigate to the Tools > Options menu.
2. From the General tab, select the check box Disable Provisioning, as shown in
Figure 28 on page 68.
Figure 28: Selecting the DIsable Provisioning Check Box
3. Click OK.
The Provision option is now disabled from the Network Info > Tunnels window in the
NorthStar Controller user interface and is also disabled from the menu options that
68
Copyright © 2015, Juniper Networks, Inc.
Chapter 4: Managing and Optimizing Label-Switched Paths
display when you right-click on a Planned tunnel from the Network Info > Tunnels
window.
To disable provisioning of LSPs on the NorthStar Controller for a local user, a NorthStar
Controller user with Full Access privileges can perform the following steps:
1.
From the NorthStar Controller user interface, navigate to the Tools > Options menu.
2. From the General tab, select the check box Disable Provisioning, as shown in
Figure 29 on page 69.
Figure 29: Selecting the DIsable Provisioning Check Box
3. Click OK.
For the local user only, the Provision option is now disabled from the Network Info >
Tunnels window in the NorthStar Controller user interface and is also disabled from
the menu options that display when the local user right-clicks on a Planned tunnel
from the Network Info > Tunnels window.
Related
Documentation
•
Disabling Provisioning of Label-Switched Paths from the NorthStar Controller CLI on
page 66
Copyright © 2015, Juniper Networks, Inc.
69
NorthStar Controller Feature Guide
70
Copyright © 2015, Juniper Networks, Inc.
CHAPTER 5
Viewing Node Event and Link Event
Changes
•
Viewing Link Event Changes on page 71
•
Viewing Node Event Changes on page 73
Viewing Link Event Changes
To identify the root cause of frequent LSP changes or flaps, you can view changes to the
link that the LSP traverses that occurred during the time period of the LSP changes. The
NorthStar Controller records all the link events and allows you to query on those link
changes (such as operational status and bandwidth) over any specified time period.
All link events are stored in the database. However, to display all raw events would result
in an excess of unnecessary information for NorthStar Controller users. To avoid this
situation, the Path Computation Server (PCS) processes the link events and displays
only the events that trigger actual link changes. You can view these link change entries
from a pop-up window that displays the data in table format.
Copyright © 2015, Juniper Networks, Inc.
71
NorthStar Controller Feature Guide
To view link change events from the NorthStar Controller user interface:
1.
Select a link entry from the Network Information > Link window, and right-click View
Link Events.
The Retrieving Link Events dialog box is displayed, as shown in Figure 30 on page 72.
Figure 30: Selecting a Time Range to View Link Events
NOTE: The End Time automatically uses the current Server time.
2. Select the start date and time from the Start Time field to identify the start date and
time of the link events you want to view.
3. Select the end date and time from the End Time field to identify the end date and
time of the link events you want to view.
4. Click OK.
All link events that trigger actual link changes are displayed in table format.
Table 7 on page 72 describes the fields displayed in the Link Events table.
Table 7: Default Fields Displayed for Link Events
Field
Description
Time Stamp
The PCS event time stamp in the database.
Action
The action that triggered the link change.
Name
The link name.
NodeA.ID
The node ID of the link A end.
NodeZ.ID
The node ID of the link Z end.
IP_A
The node IP address of the link A end.
IP_Z
The node IP address of the link Z end.
Bandwidth_AZ
The bandwidth from the link A end.
72
Copyright © 2015, Juniper Networks, Inc.
Chapter 5: Viewing Node Event and Link Event Changes
Table 7: Default Fields Displayed for Link Events (continued)
Bandwidth_ZA
The bandwidth from the link Z end.
RSVP_BW_AZ
The RSVP bandwidth from the link A end.
RSVP_BW_ZA
The RSVP bandwidth from the link Z end.
Status
The link status ("Up" or "Down").
TE_Metric_AZ
The tunnel metric from the link A end.
TE_Metric_ZA
The tunnel metric from the link Z end.
The Link Events window also supports the following functionality:
Related
Documentation
•
Filter—Filters the entry results in the table by using string matching.
•
Export—Exports the table to a text file.
•
Viewing Label-Switched Path Changes on page 65
•
Viewing Node Event Changes on page 73
Viewing Node Event Changes
All node events are stored in the database, allowing users to query on those events. To
view node event changes from the NorthStar Controller user interface, you can specify
a date range query for the node events you wish to view. Node events that trigger node
changes are displayed in a pop-up window in table format.
Copyright © 2015, Juniper Networks, Inc.
73
NorthStar Controller Feature Guide
To view node change events from the NorthStar Controller user interface:
1.
Select a node entry from the Network Information > Node window, and right-click
View Node Events.
The Retrieving Node Events dialog box is displayed, as shown in Figure 31 on page 74.
Figure 31: Selecting a Time Range to View Node Events
NOTE: The End Time automatically uses the current Server time.
2. Select the start date and time from the Start Time field to identify the start date and
time of the node events you want to view.
3. Select the end date and time from the End Time field to identify the end date and
time of the node events you want to view.
4. Click OK.
All node events that trigger actual node changes are displayed in table format.
Table 8 on page 74 describes the fields displayed in the Node Events table.
Table 8: Default Fields Displayed for Node Events
Field
Description
Time Stamp
The PCS event time stamp in the database.
Action
The action that triggered the node event.
Name
The node name.
Hostname
The node hostname.
Protocols
The protocols enabled on the node.
IS-IS Area
The ISIS area of the node.
AS
The AS number of the node.
74
Copyright © 2015, Juniper Networks, Inc.
Chapter 5: Viewing Node Event and Link Event Changes
The Node Event window also supports the following functionality:
Related
Documentation
•
Filter—Filters the entry results in the table by using string matching.
•
Export—Exports the table to a text file.
•
Viewing Label-Switched Path Changes on page 65
•
Viewing Link Event Changes on page 71
Copyright © 2015, Juniper Networks, Inc.
75
NorthStar Controller Feature Guide
76
Copyright © 2015, Juniper Networks, Inc.
CHAPTER 6
Managing Delegated Label-Switched
Paths
•
Understanding the Behavior of Delegated Label-Switched Paths on page 77
•
Returning Delegation of Externally Controlled Label-Switched Paths Back to Local
PCC Control on page 79
Understanding the Behavior of Delegated Label-Switched Paths
You can delegate the management of a router-configured label-switched path (LSP)
to the NorthStar Controller by configuring the LSP from the router to be externally
controlled. Any router-controlled LSP on the PCC can be delegated to the NorthStar
Controller.
When an LSP is externally controlled, the controller manages the following LSP attributes:
•
Bandwidth
•
Setup and Hold priorities
•
LSP metric
•
ERO
Any configuration changes to the preceding attributes performed from the router are
overridden by the values configured from the controller. Changes made to these attributes
from the PCC do not take effect as long as the LSP is externally controlled. Any
configuration changes made from the PCC take effect only when the LSP becomes locally
or router controlled.
•
Behavior of Delegated LSPs That Are Returned to Local PCC Control on page 77
•
Modifying Attributes of Delegated LSPs on the NorthStar Controller on page 79
Behavior of Delegated LSPs That Are Returned to Local PCC Control
When an LSP is externally controlled, any attempt to change the configuration of the
LSP from the PCC (except for auto-bandwidth parameters) results in the display of a
warning message from the router CLI. For delegated LSPs, any parameters configured
from the PCC take effect only after the LSP is returned to local (PCC) control. When the
LSP is returned to local control, the PCEP report messages report the state to the
Copyright © 2015, Juniper Networks, Inc.
77
NorthStar Controller Feature Guide
NorthStar Controller. If the NorthStar Controller is not available when the PCC
configuration is changed locally, but becomes available some time after the configuration
changes are made, the LSP is delegated with the reports carrying the latest state. When
an LSP is externally controlled, configuration changes to bandwidth, setup and hold
priorities, LSP metric, and ERO are overridden by the controller. Any configuration changes
to these attributes made from the PCC do not take effect as long as the LSP is externally
controlled. Only after the LSP becomes locally or router controlled will any configuration
changes made from the PCC take effect. Table 9 on page 78 shows the LSP parameters
that can and cannot be configured from the PCC.
Table 9: Behavior of LSP Configurations Initiated from PCC
Configuration Statement
Description
admin-down
Not applicable to packet LSP.
admin-group
Results in an MBB. The new LSP is reported; the old LSP is reported with the R-bit set.
auto-bandwidth
PCC automatically adjusts bandwidth based on the traffic on the tunnel. Supported on Juniper
Networks routers only.
bandwidth
Results in an MBB. The new LSP is reported; the old LSP is reported with the R-bit set.
bandwidth ct0
Results in an MBB. The new LSP is reported; the old LSP is reported with the R-bit set.
class-of-service
No change reported from PCE.
description
No change reported from PCE.
disable
LSP is deleted on the router. The PCRpt message is sent with R-bit.
entropy-label
No change reported from PCE.
fast-reroute
Results in detour path setup; the detours are not reported to the controller.
from
LSP name change results in a new LSP being signaled, and the old LSP is deleted. The new
LSP is reported through PCRpt message with D-bit. The old LSP is removed.
install
The prefix is applied locally and is not reflected to the PCE.
metric
Results in an MBB. The new LSP is reported, and the old LSP is reported with the R-bit set.
name
LSP name change results in a new LSP being signaled, and the old LSP is deleted. The new
LSP is reported through PCRpt message with D-bit. The old LSP is removed.
node-link-protection
No change is reported from PCE. The LSP is brought down and then brought back up again.
This sequence does not use an MBB.
priority
Results in an MBB. The new LSP is reported; the old LSP is reported with the R-bit set.
standby
Implementation of stateful path protection draft along with association object; see section
5.2.
78
Copyright © 2015, Juniper Networks, Inc.
Chapter 6: Managing Delegated Label-Switched Paths
Table 9: Behavior of LSP Configurations Initiated from PCC (continued)
LSP name change results in a new LSP being signaled, and the old LSP is deleted.
to
Modifying Attributes of Delegated LSPs on the NorthStar Controller
When an LSP is externally controlled, local path computation is disabled, and you can
modify the following attributes for the delegated LSP from the NorthStar Controller:
Related
Documentation
•
priority—Modifying this attribute results in a make-before-break (MBB) operation.
•
admin-group—Modifying this attribute results in an MBB operation.
•
ERO—Modifying this attribute results in an MBB operation. The new LSP state is
reported, and the old state is deleted.
•
Understanding Administrative Status for Label-Switched Paths on page 24
•
Understanding Label-Switched Paths on the NorthStar Controller on page 23
•
Returning Delegation of Externally Controlled Label-Switched Paths Back to Local
PCC Control on page 79
Returning Delegation of Externally Controlled Label-Switched Paths Back to Local
PCC Control
You can delegate the management of a router-configured LSP to the NorthStar Controller
by configuring the LSP as an externally controlled LSP from the router. You can delegate
any router- controlled LSP on the PCC to the NorthStar Controller. The control of a
delegated LSP can be returned to the router (PCC) by returning the delegation of the
LSP from the NorthStar Controller. When an LSP is externally controlled, configuration
changes to bandwidth, setup and hold priorities, LSP metric, and ERO are overridden by
the NorthStar Controller. Any configuration changes made on the router (PCC) to these
LSP attributes do not take effect as long as the LSP is externally controlled. The
configuration changes take effect only when the LSP is under local (router) control.
NOTE: By default, Junos OS router behavior re-delegates the LSP to the PCE
after 1 minute. This can be important in cases where multiple PCEs are
configured on the PCC router. After a PCE failure, the LSP is delegated to
another PCE, and it is important that the LSP goes back to the first PCE.
Copyright © 2015, Juniper Networks, Inc.
79
NorthStar Controller Feature Guide
NOTE: After delegation is returned to the PCC, the LSP is re-delegated back
to the controller after the lsp-retry-delegation-timer expires on the router
(PCC). This can be important in cases where multiple PCEs are configured
on the PCC router. After a PCE failure, the LSP is delegated to another PCE
and it is important that the LSP goes back to the first PCE. By default, the
lsp-retry-delegation-timer is set to 1 hour. To modify this value, use the
following command:
set protocol pcep pce pce-name lsp-retry-delegation-timer <value>
To return delegation of an externally controlled LSP back to the PCC router:
1.
From the Network Info screen, select the Tunnels tab.
All tunnels are displayed in table format and listed by Node ID.
2. Select one or more delegated LSPs that you want to return back to local PCC control,
and then right-click.
The drop-down menu displays the LSP options shown in Figure 32 on page 80.
Figure 32: Returning LSP Delegation to PCC
3. From the drop-down menu, select Return Delegation to PCC.
A “Redelegation order is successfully sent” message displays, when re-delegation is
successful.
4. Select OK to close the re-delegation message window.
NOTE: When a request to Return Delegation to PCC is initiated on an LSP
with standby or secondary LSPs, all the associated LSPs are marked as
locally controlled (from externally controlled).
5. To verify that the LSP has been delegated back to the PCC, run the show mpls lsp
command, for example:
user@vmx101-74> show mpls lsp name LSP_VMX101_VMX104 detail
80
Copyright © 2015, Juniper Networks, Inc.
Chapter 6: Managing Delegated Label-Switched Paths
Related
Documentation
•
Understanding the Behavior of Delegated Label-Switched Paths on page 77
Copyright © 2015, Juniper Networks, Inc.
81
NorthStar Controller Feature Guide
82
Copyright © 2015, Juniper Networks, Inc.
CHAPTER 7
Creating Templates to Apply Attributes
to Label-Switched Paths
•
Creating Templates to Apply Attributes to PCE-Initiated Label-Switched
Paths on page 83
•
Creating Templates with Junos OS Groups to Apply Attributes to PCE-Initiated
Label-Switched Paths on page 85
Creating Templates to Apply Attributes to PCE-Initiated Label-Switched Paths
From a PCC router’s CLI, you can create LSP templates to define a set of LSP attributes
to apply to PCE-initiated LSPs. Any PCE-initiated LSPs that provide a name match with
the regular expression (regex) name specified in the template automatically inherit the
LSP attributes that are defined in the template. By associating LSPs (through regex name
matching) with a specific user-defined LSP template, you can automatically turn on (or
turn off) LSP attributes across all LSPs that provide a name match with the regex name
specified in the template.
When auto-bandwidth is enabled, LSP auto-bandwidth parameters must be configured
from the router, even when the LSP has been delegated. Under no circumstances can
the NorthStar Controller modify the bandwidth of an externally-controlled LSP when
auto-bandwidth is enabled. The PCC enforces this behavior by returning an error if it
receives an LSP update for an LSP that has auto-bandwidth enabled. Currently, there is
no way to signal through PCEP when auto-bandwidth is enabled, so the NorthStar
Controller cannot know in advance that an LSP has auto-bandwidth enabled. However,
when auto-bandwidth is enabled by way of a template, then the NorthStar Controller
knows that the LSP has auto-bandwidth enabled and disallows modification of
bandwidth.
The following configuration example shows how to define the regex-based LSP name
for a set of LSP “container” templates that you can deploy to apply specific attributes
to any LSPs on the network that provide a matching LSP name.
Copyright © 2015, Juniper Networks, Inc.
83
NorthStar Controller Feature Guide
Create the templates under the lsp-external-controller-pccd hierarchy to specify the
regex-based character string to be used to identify the LSPs whose attributes you want
to update.
1.
Create a name matching scheme to identify the NorthStar Controller provisioned
(PCE-initiated) LSPs to which you want to apply specific link protection attributes.
a. To specify that any PCE-initiated LSP that provides a name match with the prefix
PCE-LP-* will inherit the LSP link-protection attributes defined in the
LINK-PROTECT-TEMPLATE template, configure the following statement from the
PCC router CLI:
[edit protocols mpls lsp-external-controller pccd]
user@PE1# set pce-controlled-lsp PCE-LP-* label-switched-path-template
LINK-PROTECT-TEMPLATE
b. To specify that any PCE-initiated LSP that provides a name match with the prefix
PCE-AUTOBW-* will inherit the LSP auto-bandwidth attributes defined in the
AUTO-BW-TEMPLATE template, configure the following statement from the PCC
router CLI:
[edit protocols mpls lsp-external-controller pccd]
user@PE1# set pce-controlled-lsp PCE-AUTOBW-* label-switched-path-template
AUTO-BW-TEMPLATE
2. Create the templates that define the attributes you want to apply to all PCE-initiated
LSPs that provide a name match.
a. Define link-protection attributes for the LINK-PROTECT-TEMPLATE template.
[edit protocols mpls ]
user@PE1# set label-switched-path-template LINK-PROTECT-TEMPLATE template
user@PE1# set label-switched-path-template LINK-PROTECT-TEMPLATE hop-limit
3
user@PE1# set label-switched-path-template LINK-PROTECT-TEMPLATE
link-protection
b. Define auto-bandwidth attributes for the AUTO-BW-TEMPLATE template.
[edit protocols mpls ]
user@PE1# set label-switched-path-template AUTO-BW-TEMPLATE template
user@PE1# set label-switched-path-template AUTO-BW-TEMPLATE
auto-bandwidth adjust-interval 300
user@PE1# set label-switched-path-template AUTO-BW-TEMPLATE
auto-bandwidth adjust-threshold 20
user@PE1# set label-switched-path-template AUTO-BW-TEMPLATE
auto-bandwidth minimum-bandwidth 10m
user@PE1# set label-switched-path-template AUTO-BW-TEMPLATE
auto-bandwidth maximum-bandwidth 100m
user@PE1# set label-switched-path-template AUTO-BW-TEMPLATE
auto-bandwidth adjust-threshold-overflow-limit 5
user@PE1# set label-switched-path-template AUTO-BW-TEMPLATE
auto-bandwidth adjust-threshold-underflow-limit 5
3. Apply the auto-bandwidth and link-protection templates to configure the
auto-bandwidth and link-protection attributes to any LSPs that match the
corresponding regex-based character string.
84
Copyright © 2015, Juniper Networks, Inc.
Chapter 7: Creating Templates to Apply Attributes to Label-Switched Paths
[edit protocols mpls lsp-external-controller pccd]
user@PE1# set pce-controlled-lsp PCE-AUTOBW-* label-switched-path-template
AUTO-BW-TEMPLATE
user@PE1# set pce-controlled-lsp PCE-LP-* label-switched-path-template
LINK-PROTECT-TEMPLATE
4. Create LSPs in NorthStar by specifying LSP names based on the regex-based name
defined in Step 1 above.
5. Verify the LSP configuration on the PCC router.
user@PE1> show mpls lsp detail
Related
Documentation
•
Creating Templates with Junos OS Groups to Apply Attributes to PCE-Initiated
Label-Switched Paths on page 85
•
Creating a Label-Switched Path on page 26
Creating Templates with Junos OS Groups to Apply Attributes to PCE-Initiated
Label-Switched Paths
From the Path Computation Client (PCC) router’s command line interface, you can use
the Junos OS groups statement with label-switched path (LSP) templates to define a
set of LSP attributes to apply to PCE-initiated LSPs. Any PCE-initiated LSP that provides
a name match with the regular expression (regex) name that is specified in the template
automatically inherits the LSP attributes that are specified in the template. Thus, by
associating PCE-initiated LSPs with a user-defined LSP template, you can automatically
turn on (or turn off) LSP attributes across all LSPs that provide a name match with the
regex name that is specified in the template.
The following example show how you can use templates to apply auto-bandwidth and
link-protection attributes to LSPs. For example, when auto-bandwidth is enabled, LSP
auto-bandwidth parameters must be configured from the router, even when the LSP has
been delegated. Under no circumstances can the NorthStar Controller modify the
bandwidth of an externally controlled LSP when auto-bandwidth is enabled. A PCC
enforces this behavior by returning an error if it receives an LSP update for an LSP that
has auto-bandwidth enabled. Currently, there is no way to signal through PCEP when
auto-bandwidth is enabled, so the NorthStar Controller cannot know in advance that
the LSP has auto-bandwidth enabled. However, if auto-bandwidth is enabled by way of
a template, the NorthStar Controller knows that the LSP has auto-bandwidth enabled
and disallows modification of bandwidth.
Copyright © 2015, Juniper Networks, Inc.
85
NorthStar Controller Feature Guide
To configure and apply groups to assign auto-bandwidth and link protection attributes
to label-switched paths:
1.
From the PCC router CLI, configure groups to specify that any PCE-initiated LSP that
provides a name match with the specified prefix will inherit the LSP attributes defined
in the template:
a. Configure a group to specify that an LSP that provides a name match with the
prefix AUTO-BW-* will inherit the LSP auto-bandwidth attributes defined in the
AUTO-BW-TEMPLATE template.
[edit groups AUTO-BW-GROUP]
user@PE1# set protocols mpls label-switched-path AUTO-BW-* autobandwidth
adjust-interval 300
user@PE1# set protocols mpls label-switched-path AUTO-BW-* autobandwidth
adjust-threshold 20
user@PE1# set protocols mpls label-switched-path AUTO-BW-* autobandwidth
minimum-bandwidth 10m
user@PE1# set protocols mpls label-switched-path AUTO-BW-* autobandwidth
maximum-bandwidth 100m
user@PE1# set protocols mpls label-switched-path AUTO-BW-* autobandwidth
adjust-threshold-overflow-limit 5
user@PE1# set protocols mpls label-switched-path AUTO-BW-* autobandwidth
adjust-threshold-underflow-limit 5
b. Configure a group to specify that any LSP that provides a name match with the
prefix LINK-PROTECT-* will inherit the LSP link-protection attributes defined in
the LINK-PROTECT-TEMPLATE template.
[edit groups LINK-PROTECT-GROUP]
user@PE1# set protocols mpls label-switched-path LINK-PROTECT-* hop-limit 5
user@PE1# set protocols mpls label-switched-path LINK-PROTECT-* link-protection
user@PE1# set protocols mpls label-switched-path LINK-PROTECT-* adaptive
2. Configure the templates to apply the attributes defined for the two groups in the
previous step.
[edit protocols mpls]
user@PE1# set label-switched-path AUTO-BW-TEMPLATE apply-groups
AUTO-BW-GROUP
user@PE1# set label-switched-path AUTO-BW-TEMPLATE template
user@PE1# set label-switched-path LINK-PROTECT-TEMPLATE apply-groups
LINK-PROTECT-GROUP
user@PE1# set label-switched-path LINK-PROTECT-TEMPLATE template
3. Apply the auto-bandwidth and link-protection templates to assign the auto-bandwidth
and link-protection attributes to any LSPs that match the corresponding regex-based
character-string.
[edit protocols mpls lsp-external-controller pccd]
user@PE1# set pce-controlled-lsp AUTO-BW-* label-switched-path-template
AUTO-BW-TEMPLATE
user@PE1# set pce-controlled-lsp LINK-PROTECT-* label-switched-path-template
LINK-PROTECT-TEMPLATE
4. Create LSPs from the NorthStar Controller by specifying LSP names based on the
regex-based name defined in Step 1.
86
Copyright © 2015, Juniper Networks, Inc.
Chapter 7: Creating Templates to Apply Attributes to Label-Switched Paths
5. Verify the LSP configuration on the PCC router.
user@PE1> show mpls lsp detail
Related
Documentation
•
Creating Templates to Apply Attributes to PCE-Initiated Label-Switched Paths on
page 83
•
Creating a Label-Switched Path on page 26
Copyright © 2015, Juniper Networks, Inc.
87
NorthStar Controller Feature Guide
88
Copyright © 2015, Juniper Networks, Inc.
CHAPTER 8
Scheduling Maintenance on Network
Devices
•
Scheduling a Maintenance Event on Network Elements on page 89
•
Managing Planned Maintenance Events on page 92
•
Viewing Maintenance Events on page 95
Scheduling a Maintenance Event on Network Elements
Before you bring down devices in your managed network to perform updates or other
configuration tasks, you can schedule a maintenance event from the NorthStar Controller
so that selected nodes, links, or Shared Risk Link Groups (SRLGs) will be brought down
during a specified period of time. During the maintenance event, NorthStar will reroute
the affected LSPs around the down elements before initiating the maintenance event.
NOTE: When you run simulation on a maintenance event, the NorthStar
Controller takes the current network state into consideration, including any
other network elements that are currently down. However, any network
elements that are “down” as a result of other maintenance events are not
taken into consideration. So if you simulate Event B while another simulation
event (Event A) is in progress, the logically down elements from Event A are
not taken into consideration when you run Event B simulation.
This topic describes the steps required to create and schedule a maintenance event on
selected nodes, links, SRLGs, or interfaces.
To schedule a maintenance event on selected network elements:
1.
From the Network Info window, select Maintenance > Add.
The Add Maintenance Event window is displayed.
2. In the Maintenance Event Name field, enter a name for the maintenance event.
This field is required.
Copyright © 2015, Juniper Networks, Inc.
89
NorthStar Controller Feature Guide
NOTE: The name you specify can also be used for the file extension name
for generating reports.
3. In the Owner field, type admin for the owner.
4. In the Comment field, enter a name for the maintenance event you are creating.
5. In the Start Time field, click the calendar icon on the right and select the date and
time to initiate the maintenance event (at least a few minutes after the current server
time).
This field is required.
6. In the End Time field, click the calendar icon on the right and specify the estimated
date and time the maintenance event ends.
The default end time is 60 minutes after the current server time. This field is required.
NOTE: The minimum duration for a maintenance event is 5 minutes.
NOTE: The NorthStar Controller displays the estimated time but does not
impose an end time for a maintenance event.
7. Select the Autocomplete option to automatically complete the maintenance event
at the specified end time.
Otherwise, you must select the Change Status to Completed option to manually
complete the maintenance event, after it finishes.
NOTE: The Autocomplete option should be used only when you are certain
that the maintenance event will finish on time. Maintenance events that
are in progress require the user to manually change the operation status
to “Complete” in order to signal the end of the maintenance event.
Manually ending the event can be done at any time. Note that the
maintenance event will not stop at the specified end time until the user
manually intervenes by changing the status. When you select the
Autocomplete option, the NorthStar Controller automatically signals the
end of the maintenance event at the specified end time, without user
intervention.
8. To select the elements to include in the maintenance event:
a. In the Elements for Maintenance window, select <Click to Select Elements for
Maintenance Event>.
The Elements for Maintenance Event window is displayed.
90
Copyright © 2015, Juniper Networks, Inc.
Chapter 8: Scheduling Maintenance on Network Devices
b. Using the Node, Link, SRLG, and/or Interface tabs, select the nodes, links, SRLGs,
and/or interfaces that you want to include in the maintenance event.
c. In the Elements for Maintenance Event window, click OK.
The Add Maintenance Event window appears again.
9. From the Add Maintenance Event dialog box, click OK to schedule the maintenance
event on the NorthStar Controller.
All scheduled maintenance events appear in the Maintenance table.
10. To schedule the maintenance event, click OK in the Elements for Maintenance Event
dialog box.
To view Information about scheduled maintenance events, select Network Info >
Maintenance.
When the maintenance event is initiated, the Operational Status field displays
“In_Progress” for the duration of the scheduled maintenance event, the active
maintenance is displayed from the top of the window, and any tunnels that might use
those down elements are automatically rerouted for the duration of the event. From
the Map view, any links affected by a maintenance event are marked with a red “M”.
NOTE: When you use the NorthStar Controller to schedule a router to go
into maintenance mode, the NorthStar Controller does not put the router
into maintenance mode, but only acts to reroute the tunnel around the
selected router. If you select the Tunnels tab view, the Admin_Status
column for each affected tunnel displays “Maint_Rerouted”.
11. When the scheduled maintenance event completes (and the Autocomplete option
is not selected), manually change the Operation Status from the Maintenance tab by
right-clicking Change Status to Completed on the selected maintenance event.
NOTE: If its operational status is not changed upon completion of the
maintenance event, the maintenance will never end, and those elements
under maintenance will be considered “down”.
NOTE: When maintenance events complete, tunnels are routed to the
optimal path of the current network state, but that path is not necessarily
the original path.
Related
Documentation
•
Managing Planned Maintenance Events on page 92
•
Viewing Maintenance Events on page 95
•
Understanding Administrative Status for Label-Switched Paths on page 24
•
Running Simulations for Scheduled Maintenance Events on page 99
Copyright © 2015, Juniper Networks, Inc.
91
NorthStar Controller Feature Guide
Managing Planned Maintenance Events
You can modify, cancel, or delete scheduled maintenance events from the NorthStar
Controller user interface by using the following procedures.
•
Modifying a Planned Maintenance Event on page 92
•
Canceling Scheduled Maintenance Events on page 93
•
Deleting Planned or Canceled Maintenance Events on page 94
Modifying a Planned Maintenance Event
To modify a planned maintenance event from the NorthStar Controller user interface:
1.
In the Application menu, select Maintenance.
The Maintenance tab appears in the Network Info window.
2. In the Maintenance table, select the maintenance event that you want to modify.
3. At the bottom of the Network Info screen, click Modify.
The Modify Maintenance Event window is displayed.
4. In the Modify Maintenance Event window, modify any of the fields as shown in
Table 10 on page 92.
Table 10: Elements for Maintenance Event Window
Field
Description
Maintenance Event Name
The name for the maintenance event you are creating. This field must be completed.
Owner
Current login owner is specified by default.
Comment
Comments about the maintenance event.
Start Time
Specify the date and time the maintenance event begins. This field must be completed.
The default start time is the current server time.
NOTE: The time is based on server time zone.
End Time
Specify the estimated date and time the maintenance event ends. This field must be completed.
The default end time is 60 minutes after the current server time.
NOTE: The NorthStar Controller shows the estimated time but will not impose an end time for
a maintenance event unless the Autocomplete option is selected.
Duration
92
This field is automatically calculated based on the difference between values specified for the
Start Time and End Time fields.
Copyright © 2015, Juniper Networks, Inc.
Chapter 8: Scheduling Maintenance on Network Devices
Table 10: Elements for Maintenance Event Window (continued)
Autocomplete
When selected, the Operation Status for the event is automatically set to “Completed at End
Time”.
Autocomplete automatically signals the end of the maintenance event at the specified time.
Otherwise, the user must manually end the event.
Elements for Maintenance
Click in the <Click to Select Elements for Maintenance Events> field to open a filter window from
which you can select nodes, links, and SRLGs scheduled for maintenance.
5. To schedule the modified maintenance event, click OK in the Modify Maintenance
Event dialog box.
The updates you made for the specified maintenance event are reflected in the
corresponding row in the Maintenance window.
6. When the scheduled maintenance event completes, manually change the Operation
Status from the Maintenance tab by right-clicking Change Status to Completed on the
selected maintenance event.
NOTE: If its operational status is not changed upon completion of the
maintenance event, the maintenance will never end, and those elements
under maintenance will be considered “down”.
NOTE: After you have manually changed the maintenance event to
“Completed” status as described in this step, any tunnel paths that were
rerouted as a consequence of a router going into maintenance mode will
be rerouted to back to their optimal path but this optimal path is not
necessarily the original path.
Canceling Scheduled Maintenance Events
To cancel a scheduled maintenance event from the NorthStar Controller user interface:
1.
From the Application menu, select Maintenance.
The Maintenance tab appears in the Network Info window.
2. In the Maintenance table, select the maintenance event that you want to cancel.
The selected row for the Maintenance event is highlighted in the Maintenance window.
3. Right-click the selected maintenance event row, and click Cancel Maintenance Event.
The Maintenance event appears in the maintenance event row, but the Operation
Status field changes from Planned to Canceled.
Copyright © 2015, Juniper Networks, Inc.
93
NorthStar Controller Feature Guide
Deleting Planned or Canceled Maintenance Events
To delete a planned or canceled maintenance event from the NorthStar Controller user
interface:
1.
From the Application menu, select Maintenance.
The Maintenance tab appears in the Network Info window.
2. In the Maintenance table, select the maintenance event that you want to delete.
The selected row for the Maintenance event is highlighted in the Maintenance window.
NOTE: You cannot delete a maintenance event that is in progress.
3. Click Delete.
The Delete Maintenance Event(s) window is displayed.
4. Click Yes.
The selected maintenance event is deleted from the Maintenance window and the
NorthStar Controller.
Related
Documentation
94
•
Viewing Maintenance Events on page 95
Copyright © 2015, Juniper Networks, Inc.
Chapter 8: Scheduling Maintenance on Network Devices
Viewing Maintenance Events
You can view all Planned, In Progress, Completed, and Canceled maintenance events
for network elements from the NorthStar Controller user interface. When a maintenance
event is in progress, all nodes, links, SRLGs, and interfaces affected by that maintenance
event are unavailable on the network until the maintenance event has completed.
To view scheduled maintenance events on the NorthStar Controller:
Copyright © 2015, Juniper Networks, Inc.
95
NorthStar Controller Feature Guide
1.
From the Network Info window, select the Maintenance tab.
All planned, in progress, and completed maintenance events are displayed in table
format. Table 11 on page 96 describes the fields displayed in the Maintenance table.
Table 11: Default Fields Displayed from Network Info > Maintenance Table
Field
Description
Name
Name assigned to the scheduled maintenance event.
NOTE: The name specified for the maintenance event is also used to name the subfolder for
reports in the Report Manager.
Num Links
Number of links scheduled for maintenance.
Num Nodes
Number of nodes scheduled for maintenance.
Num SRLGs
Number of SRLGs scheduled for maintenance.
Num Interfaces
Number of Interfaces scheduled for maintenance.
Start Time
Start time for the maintenance event.
End Time
End time for the maintenance event.
Estimated Duration
Estimated duration for the maintenance event, which is calculated as the duration between the
Start Time and End Time in the Maintenance Scheduler window.
Owner
Owner of the maintenance event.
Last Modified
Last time the event was modified.
Operation Status
Tracking status for maintenance management:
•
Planned—Event scheduled some time in the future.
•
In Progress—Event is in progress.
•
Canceled—The scheduled event has been canceled. A canceled event is different from a deleted
event. Canceled events can be events that were rescheduled or postponed but remain in the
maintenance table for tracking purposes. Deleted events are removed from the Maintenance
table.
•
Completed—Event finished in the past.
Comment
Comments entered from the Maintenance Scheduler window.
Autocomplete
When selected, NorthStar automatically sets the event’s Operation Status to Completed at the
specified End Time.
Simulation Status
Status for tracking report generation:
96
•
Blank—No reports have been generated yet.
•
In Progress—Simulation is in progress.
•
Incomplete—Simulation reports failed to generate.
•
Completed-Pass—Simulation finished and LSPs were successfully rerouted.
•
Completed-Fail—Simulation finished and LSPs failed to reroute.
Copyright © 2015, Juniper Networks, Inc.
Chapter 8: Scheduling Maintenance on Network Devices
Table 11: Default Fields Displayed from Network Info > Maintenance Table (continued)
Simulation Time
Indicates the last time the simulation was run. A timestamp indicates the network state of
simulation. Rerun simulation overwrites the report and uses current time for the network state.
Exhaustive Simulation
Exhaustive simulation scenarios in addition to the element for maintenance:
•
None—No additional exhaustive elements.
•
Link + Node + SRLG—Additional exhaustive elements for Link, Node, SRLG, or all types.
Add
Button that opens the Maintenance Scheduler window so you can add new maintenance events.
Modify
Button to use to edit existing events. It opens the Maintenance Scheduler window with its fields
pre-populated.
Delete
Button to use to delete the event. Button is inactive (grey) when a selected event is in progress.
Right-click
Supports the following actions:
Related
Documentation
•
Auto-highlight—Highlights the elements for maintenance on the map.
•
Simulate Maintenance Event—Performs maintenance event failure simulation with option to
include exhaustive failures.
•
Interactively Simulate Maintenance Event—Performs maintenance event interactive failure
simulation.
•
View Simulation Report—Opens simulation reports in Report Viewer, if available.
•
Cancel Maintenance Event—Sets status to Canceled. The Path Computation Server does not
perform any rerouting.
•
Change Status to Complete—Sets status to Completed. This function is performed after the
scheduled maintenance event is complete, and the tunnels will be optimized and rerouted.
•
Managing Planned Maintenance Events on page 92
•
Scheduling a Maintenance Event on Network Elements on page 89
Copyright © 2015, Juniper Networks, Inc.
97
NorthStar Controller Feature Guide
98
Copyright © 2015, Juniper Networks, Inc.
CHAPTER 9
Managing Simulation Reports
•
Running Simulations for Scheduled Maintenance Events on page 99
•
Viewing Failure Simulation Reports on page 101
Running Simulations for Scheduled Maintenance Events
You can run simulations from the NorthStar Controller during scheduled maintenance
events to run different failure scenarios to test the resilience of your network. Network
simulation is based on the current network state for the selected maintenance events
at the time the simulation is initiated. Simulation does not simulate the maintenance
event for a future network state or simulate elements from other concurrent network
events. You can run network simulations based on selected elements for maintenance,
extended failure simulations, or interactive failure simulations, with the option to include
exhaustive failures. For failure simulation, all the Elements for Maintenance are considered
concurrently down or in a Fail state for the duration of the failure simulation. If any
Extended Failure Simulations are selected, these extended elements and the Elements
for Maintenance are considered concurrently down or in a Fail state during the failure
simulation.
To perform failure simulation for a scheduled maintenance event:
1.
From the Network Info window, select the Maintenance tab.
A list of all scheduled, canceled, and completed maintenance events is displayed in
a table format.
2. Right-click the maintenance event on which you want to perform failure simulation,
and from the drop-down menu, select Simulate Maintenance Event.
The Maintenance Event Simulation dialog box displays the elements to be included
in the failure simulation. Figure 33 on page 100 shows an example of the elements for
maintenance.
Copyright © 2015, Juniper Networks, Inc.
99
NorthStar Controller Feature Guide
Figure 33: Maintenance Event Simulation Dialog Box Displays Elements
for Maintenance
3. (Optional) To include extended failure simulations to exhaustively fail selected
elements, select the check box for Nodes, Links, or SRLGs, or select all of the check
boxes.
For example, if Elements for Maintenance is Node 7.0.0.1, and under Extended Failure
Simulations you select the Links check box, the failure simulation is performed in the
following sequence:
1.
NorthStar fails Node 7.0.0.1 and the first link concurrently.
2. NorthStar brings the first link back up.
3. For all links, the link is considered as failed, the failure is simulated, and then the
link is marked up.
4. After a failure simulation has completed, six reports are available by right-clicking the
maintenance event and selecting the corresponding report to view.
NOTE: If you rerun failure simulation, the Northstar Controller uses the
current time for the network state and overwrites the existing simulation
report.
NOTE: When you delete a maintenance event, any simulation reports that
are associated with the maintenance event are also deleted from the
server.
Related
Documentation
100
•
Scheduling a Maintenance Event on Network Elements on page 89
•
Viewing Failure Simulation Reports on page 101
Copyright © 2015, Juniper Networks, Inc.
Chapter 9: Managing Simulation Reports
Viewing Failure Simulation Reports
After you run failure simulations for scheduled maintenance events to test the resilience
of your network, you can view the failure simulation reports for those maintenance events.
The reports are stored on the NorthStar Controller server until the user deletes the
Maintenance event from the user interface. When a report is deleted, any associated
reports are also deleted.
To access and view failure simulation reports for maintenance events:
1.
In the Network Info window, select the Maintenance tab.
A list of all scheduled, canceled, and completed maintenance events is displayed in
a table format.
2. Select the maintenance event for which you want to view simulation reports, and
right-click to display the list of options available from the drop-down menu.
You can select and view any of the following reports and information:
Related
Documentation
•
Tunnel Path Changes—Show changes to the tunnels’ path, number of hops, path
cost, and delay.
•
Link Utilization Changes—Show changes to the links’ utilization and RSVP utilization.
•
Link Peak Utilization Report—For each link, this report shows the peak utilization
encountered from one or more elements that failed.
•
Path Delay Information Report—Shows the worst path delay and distance experience
by each tunnel and the associated failure event that caused the worst-case scenario.
•
Simulation Stat Summary—Shows the summary view of the count, bandwidth, and
hops of the impacted and failed tunnels.
•
Tunnel Failure Info—Shows the tunnels that failed to reroute.
•
Running Simulations for Scheduled Maintenance Events on page 99
•
Scheduling a Maintenance Event on Network Elements on page 89
Copyright © 2015, Juniper Networks, Inc.
101
NorthStar Controller Feature Guide
102
Copyright © 2015, Juniper Networks, Inc.
CHAPTER 10
Index
•
Index on page 105
Copyright © 2015, Juniper Networks, Inc.
103
NorthStar Controller Feature Guide
104
Copyright © 2015, Juniper Networks, Inc.
L
Index
Symbols
#, comments in configuration statements.....................xi
( ), in syntax descriptions.......................................................xi
< >, in syntax descriptions.....................................................xi
[ ], in configuration statements...........................................xi
{ }, in configuration statements..........................................xi
| (pipe), in syntax descriptions............................................xi
overview.............................................................................23
A
admin status
for LSP................................................................................24
B
braces, in configuration statements..................................xi
brackets
angle, in syntax descriptions........................................xi
square, in configuration statements.........................xi
C
comments, in configuration statements.........................xi
conventions
text and syntax...................................................................x
curly braces, in configuration statements.......................xi
customer support....................................................................xii
contacting JTAC...............................................................xii
D
delegated label-switched-path
returning to local control.............................................79
delta provisioning See label-switched path (LSP)
diverse label-switched path
creating..............................................................................29
documentation
comments on....................................................................xi
F
font conventions........................................................................x
Copyright © 2015, Juniper Networks, Inc.
label-switched path (LSP)
admin status....................................................................24
auto-bandwidth parameters, enabling from a
template.......................................................................20
bidirectional.....................................................................20
configuring autobandwidth parameters
for delegated LSPs...............................................83
for PCE-initiated LSPs.........................................83
creating..............................................................................26
creating diverse LSPs...................................................29
creating mulitple secondary LSPs...........................33
creating mulitple standby LSPs................................33
creating multiple LSPs.................................................38
creating secondary LSPs..............................................31
creating standby LSPs..................................................31
creating templates to apply attributes to
PCE-initiated or delegated LSPs.........................83
creating time-based scheduling,
example...........................................................48, 51, 53
creating with time-based scheduling....................43
delegated, returning to local PCC control.............79
diverse................................................................................20
enabling attributes from templates.......................20
events, viewing...............................................................65
optimizing...........................................................................21
optimizing with Path Analysis...................................59
path setup between routers.......................................23
provisioning
disabling.....................................................................21
enabling.....................................................................21
re-optimizing with Path Optimization
feature.............................................................................61
reporting.............................................................................19
secondary.........................................................................20
standby..............................................................................20
time-based scheduling................................................20
using delta provisioning to modify LSPs...............58
link events
viewing................................................................................72
LSP See label-switched path
LSP connection state See Path Computation Client
(PCC)
LSP events
viewing...............................................................................65
LSP provisioning
disabling on the NorthStar Controller user
interface........................................................................66
105
NorthStar Controller Feature Guide
M
R
maintenance events
modifying..........................................................................92
running simulations for scheduled events.............21
maintenance mode
configuring.......................................................................89
viewing scheduled events..........................................95
manuals
comments on....................................................................xi
monitor mode
enabling on the NorthStar Controller user
interface................................................................66, 68
multiple label-switched paths
creating..............................................................................38
re-optimizing LSP
with Path Optimization feature.................................61
router
maintenance mode......................................................89
RSVP-TE signaling..................................................................15
S
simulations
running for scheduled maintenance events.........21
standby label-switched path
creating...............................................................................31
stateful PCE...............................................................................16
support, technical See technical support
syntax conventions...................................................................x
N
network topology abstractor daemon (NTAD)............18
network topology discovery
overview.............................................................................18
node
events, viewing................................................................74
node events
viewing................................................................................73
NorthStar Controller
features...............................................................................19
overview..............................................................................15
NorthStar Controller user interface
monitor mode, enabling......................................66, 68
P
parentheses, in syntax descriptions..................................xi
path computation
overview.............................................................................16
Path Computation Client (PCC)
LSP connection state.....................................................17
path setup between routers.......................................15
Path Computation Client daemon (PCCD)
interaction with Path Computation Element
(PCE)...............................................................................17
Path Computation Element (PCE)
architecture.................................................................15, 16
delegation of control over LSPs................................16
functions in the NorthStar Controller.....................16
stateful................................................................................16
Path Computation Element Protocol (PCEP)
establishing a path between PCC routers.............16
role in client-side implementation of stateful
PCE architecture.........................................................16
106
T
technical support
contacting JTAC...............................................................xii
templates
enabling LSP attributes...............................................20
templates, creating
to apply attributes to PCE-initiated or
delegated LSPs
......................................................................................83
time-based scheduling See label-switched path
(LSP)
time-based scheduling for label-switched
paths.......................................................................................43
example...............................................................48, 51, 53
topology See network topology discovery
tunnel See label-switched path (LSP)
Copyright © 2015, Juniper Networks, Inc.