cisco nso transport sdn function pack bundle 1.0 …...applicable to t-sdn fp bundle version 1.0.0....

May 2020

Cisco NSO Transport SDN Function Pack Bundle User Guide

Version 1.0.0

THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.

THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.

The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB’s public domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.

NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS” WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.

IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1721R)

Copyright

© 2020 Cisco Systems, Inc. All rights reserved.

Cisco has more than 200 offices worldwide. Addresses, phone numbers, and fax numbers are listed on the Cisco Website at www.cisco.com/go/offices.

Cisco NSO Transport SDN Function Pack Bundle - User Guide Total page: 186

Contents

Rev. 1.0.0


1 Contents 1 Contents ....................................................................................... iii 2 Preface ........................................................................................... 6

3 Getting Started ............................................................................... 7 3.1 Cisco Network Services Orchestrator - Overview ................................. 7 3.2 Cisco NSO Transport SDN Function Pack Bundle - Overview ............... 9 3.3 T-SDN Function Packs Bundle Architecture ........................................ 10

4 SR-TE Core Function Pack ............................................................. 13 4.1 SR-TE ODN........................................................................................... 13 4.2 SR-Policy ............................................................................................. 13

5 Example Function Packs ............................................................... 15 5.1 SR-Settings .......................................................................................... 15 5.2 SR-PCE ................................................................................................. 15 5.3 L2VPN .................................................................................................. 15 5.4 L3VPN .................................................................................................. 16

6 Configuration ............................................................................... 17 6.1 Creating SR-TE Services ...................................................................... 17

6.1.1 Creating SR-ODN ................................................................. 17 6.1.2 Creating SR-Policies ............................................................. 19

6.2 Creating SR-Settings Services ............................................................. 20 6.2.1 Allocating Resources by Using Resource Pools ................... 22

6.3 Creating SR-PCE Services .................................................................... 30 6.4 Creating Flat L2VPN Services with the L2VPN Example Function Pack

............................................................................................................ 32 6.4.1 Creating Flat L2VPN-P2P ..................................................... 32 6.4.2 Creating Flat L2VPN – EVPN ................................................ 34

6.5 Creating Flat L3VPN Services with the L3VPN Example Function Pack ............................................................................................................ 39 6.5.1 Creating Flat L3VPN ............................................................. 39 6.5.2 Creating L3VPN SR-TE ODN ................................................. 41 6.5.3 Creating BVI L3VPN ............................................................. 44

7 Working with Action Commands .................................................. 46 7.1 Service Cleanup Actions ...................................................................... 46

7.1.1 SR-ODN ................................................................................ 47 7.1.2 SR-Policy .............................................................................. 48 7.1.3 SR-Settings ........................................................................... 48 7.1.4 SR-PCE ................................................................................. 49 7.1.5 L2VPN Example Services ..................................................... 50 7.1.6 L3VPN Example Services ..................................................... 51

7.2 Auto Cleanup ...................................................................................... 51 7.3 get-modifications Action .................................................................... 53

7.3.1 SR-ODN ................................................................................ 53 7.3.2 SR-Policy .............................................................................. 55 7.3.3 SR-Settings ........................................................................... 55

Contents

Rev. 1.0.0


7.3.4 SR-PCE ................................................................................. 58 7.3.5 L2VPN Example Services ..................................................... 60 7.3.6 L3VPN Example Services ..................................................... 64

7.4 Service Redeploy Action ..................................................................... 71 7.4.1 SR-ODN ................................................................................ 71 7.4.2 SR-Policy .............................................................................. 72 7.4.3 SR-Settings ........................................................................... 73 7.4.4 SR-PCE ................................................................................. 74 7.4.5 L2VPN Example Services ..................................................... 75 7.4.6 L3VPN Example Services ..................................................... 76

8 Using Custom-Templates .............................................................. 78 8.1 Turning Custom-Templates On/Off .................................................... 78

9 Supporting Multi-Vendor Services ................................................ 79

10 Deleting Services .......................................................................... 80

11 Notifications ................................................................................ 81 11.1 SR-ODN Notifications .......................................................................... 81 11.2 SR-Policies Notifications ..................................................................... 83

11.2.1 SR-TE Policy with Static Explicit Route Object ..................... 83 11.3 SR-Settings Notifications .................................................................... 85

11.3.1 SR-Settings Notifications ..................................................... 85 11.3.2 SR Flex Algo Notifications .................................................... 87

11.4 SR-PCE Notifications ........................................................................... 88 11.5 Flat L2VPN Example Notifications ...................................................... 90

11.5.1 Flat L2VPN P2P Notifications ............................................... 90 11.5.2 Flat L2VPN VPWS Notifications ........................................... 92 11.5.3 L2VPN SR-TE – Preferred Path Notifications ....................... 94 11.5.4 L2VPN SR-TE – ODN ............................................................. 96

11.6 Flat L3VPN Example Notifications ...................................................... 98 11.6.1 Flat L3VPN Notifications ...................................................... 98 11.6.2 Flat -L3VPN SR TE Color ..................................................... 100

12 Handling Zombies ....................................................................... 102

13 Appendix A: Package Categories and Packages ........................... 104

14 Appendix B - Yang Models .......................................................... 105 14.1 Cisco SR-TE-CFP-ODN ........................................................................ 105 14.2 Cisco SR-TE-CFP-POLICY .................................................................... 106 14.3 SR-Setting Function Pack .................................................................. 108 14.4 SR-PCE Function Pack ....................................................................... 112 14.5 Flat-L2VPN Function Pack ................................................................. 114 14.6 Flat-L3VPN Function Pack ................................................................. 118

15 Appendix C - Payloads and XML Outputs .................................... 120 15.1 Custom-Template Payloads .............................................................. 120

15.1.1 SR-ODN .............................................................................. 120 15.1.2 SR-Policy ............................................................................ 121 15.1.3 SR-Settings ......................................................................... 121 15.1.4 SR-PCE ............................................................................... 123

Contents

Rev. 1.0.0


15.1.5 L2VPN Example Services ................................................... 124 15.1.6 L3VPN Example Services ................................................... 125

15.2 XML Output – get-modifications Action ........................................... 127 15.2.1 SR-ODN .............................................................................. 127 15.2.2 SR-Policy ............................................................................ 129 15.2.3 SR-Settings ......................................................................... 130 15.2.4 SR-PCE ............................................................................... 133 15.2.5 L2VPN Example Services ................................................... 135 15.2.6 L3VPN Example Services ................................................... 139

16 Appendix D: Use Cases ............................................................... 147 16.1 Use Cases .......................................................................................... 150

16.1.1 Use Case 1: Instantiating Example L3VPN over SR-TE for Color 30 ............................................................................. 150

16.1.2 Use Case 2: Flat- L3VPN Route Policy for Color 20 by Using SR ODN with Flex Algo ....................................................... 156

16.1.3 Use Case 3: Instantiating L2VPN over SR-TE for Color 40 . 169 16.1.4 Instantiating SR-Policy with SR-PCE for Color 50 .............. 177

Preface

Cisco Transport SDN Function Pack Bundle User Guide

2 Preface

Abstract

This document serves as the documentation reference and user guide for the NSO Transport SDN Function Pack (T-SDN FP) Bundle. This document is applicable to T-SDN FP Bundle version 1.0.0.

Audience

This document describes how to configure and use the T-SDN function packs. This document is intended for Cisco Advanced Services developers, network

engineers, and system engineers who install, configure, and deliver the T-SDN

automation functionalities to Cisco customers.

Additional Documentation

This documentation requires the reader to have a good understanding of Cisco NSO and its usage as described in the Cisco NSO documentation. For documentation on additional Cisco products, see the Cisco documentation website.

Sl. No. Documentation

1. Cisco NSO Transport SDN FP Bundle Installation Guide

2. Cisco NSO Installation Guide

3. Cisco NSO User Guide

Getting Started


3 Getting Started This topic provides an overview of Cisco Network Services Orchestration (NSO) and an understanding of Cisco Transport SDN function packs.

3.1 Cisco Network Services Orchestrator - Overview

This section gives a brief overview of Cisco NSO.

Network engineers use NSO as a central point of management for the entire network by using a network command line interface (CLI). NSO enables service providers to dynamically adopt their orchestration solution with changes in the offered service portfolio. NSO is built on a Model-Driven Architecture which supports the dynamic addition and modification of service definitions. The service models are written in the YANG modeling language (RFC 6020).

You can also upload the configuration information to NSO by using the payloads. These payloads contain the desired service configurations in an XML format. Each service can have a single file or multiple files. Deploy the configuration information by using payloads through the NSO CLI or by invoking the Northbound interface to create and modify service configurations. This documentation uses both network CLI and sample XML payloads.

From a Linux console, invoke the Network Configuration Protocol NETCONF NBI command to push or load the XML payload into NSO.

Getting Started


# netconf-console --port=[port_number]--host=[host_IP_address] -u [username] -p [password] --edit-config payload.xml

Example

# netconf-console --port=830 --host=127.0.0.1 -u admin -p Fr3eB!rd$ --edit-config payload.xml

Run the following command to get the configuration details from the configuration database in the NSO. For more information about NETCONF, see Cisco Networking Services Configuration Guide.

# netconf-console --port=[port_number]--host=[host_IP_address] -u [host_username] -p [host_password] –get get-config

Example

# netconf-console --port=830 --host=127.0.0.1 -u admin -p Fr3eB!rd$ –get get-config

NETCONF supports the following operations:

• <get-config>

• <edit-config> (operation="create")

• <edit-config> (operation="replace")

• <edit-config> (operation="merge")

• <edit-config> (operation="delete")

The typical workflow when using the network CLI in NSO is as follows:

• All changes are initially made to a (logical) copy of the NSO database of configurations.

• You can view and verify the changes prior to committing them.

• The changes are committed, meaning that the changes are copied to the NSO database and pushed out to the network. Changes that violate integrity constraints or network policies are not committed. The changes to the devices are done in a holistic distributed atomic transaction, across all devices in parallel.

Changes either succeed and remain committed or fail and are rolled back as a whole, returning the entire network to the uncommitted state.

Getting Started


3.2 Cisco NSO Transport SDN Function Pack Bundle - Overview

The NSO T-SDN FP Bundle is part of the Cisco Crosswork Network Controller solution, or can be used as part of a customer solution. NSO T-SDN FP Bundle is based on the SDN architecture to control and manage the transport networks in a multi-layer and multi-vendor environment. Cisco SDN provides choice in automation and programmability across data centers, campuses, and wide-area networks. Use Cisco software-defined solutions to build intent based networks (IBN).

IBN transforms a hardware-centric, manual network into a controller-led network that captures business intent and translates it into policies that can be automated and applied consistently across the network. The goal is for the network to continuously monitor and adjust network performance to help assure desired business outcomes.

The NSO T-SDN FPs forms an extension of SDN, which allows the higher level network controllers to reroute the network traffic. The NSO T-SDN FPs extend the Cisco Crosswork solution, which is designed to help service providers gain the mass awareness, augmented intelligence, and proactive control for a comprehensive data-driven, intent-based automated network.

The NSO T-SDN FPs are installed on the NSO platform. The NSO T-SDN FPs use orchestration to push services and network configurations. The NSO T-SDN FPs utilize NSO Reactive FastMap (RFM) nano services to manage the full life-cycle of a service.

The NSO T-SDN FP Bundle consists of:

1. SR-TE Core Function Pack (CFP) – a productized and supported implementation of SR-TE automation

2. Example function packs for Layer 2 and Layer 3 VPNs, intended to be customized for each customer deployment by Cisco Customer Experience (CX).

Without having to modify the SR-TE CFP, it allows you to add additional configurations into a device by using custom-templates.

SR-TE CFP comprises the following modules/services:

➢ SR-TE on-Demand-Network (ODN)

➢ SR-TE Policies

SR policy path computation of SR-TE CFP supports service specific constraints, such as bandwidth, latency, path diversity, and traffic engineering constraints, such as affinity, bandwidth, cost, latency coming from the network.

Getting Started


SR-TE CFP configures the SR-TE policies and instantiates services. Using the network topology and inventory collected, SR-TE CFP solution supports the example function packs SR-Settings and SR-PCE. L3VPN and L2VPN services can then be provisioned with specified segment routing policy. These example function packs utilize SR-TE policies for service instantiation.

3.3 T-SDN Function Packs Bundle Architecture

The following diagram shows the architecture of the T-SDN function packs.

NSO provides Service Provisioning functionality of T-SDN FPs by:

• Provisioning SR-Policy

• Provisioning SR-Settings, SR-PCE, L2VPN, and L3VPN over an existing SR-Policy (ODN or Preferred Path option)

T-SDN FPs are implemented by using the SR-TE CFP and the example function packs – SR-Settings, SR-PCE, L2VPN, and L3VPN.

A router in a SR network is capable of selecting any path to forward traffic, whether it is explicit or Interior Gateway Protocol (IGP) shortest path.

Each segment is an end-to-end path from the source to the destination, and instructs the routers in the provider core network to follow the specified path instead of the shortest path calculated by the IGP. Segments represent subpaths that a router can combine to form a complete route to a network destination.

Getting Started


SR-TE CFP provides the SR-TE policies and SR-ODN services. T-SDN FPs configure the SR-TE policies and instantiates services, such as the SR-Settings, SR-PCE, L2VPN and/or L3VPN function packs that utilize these SR-TE policies.

Note: The example function packs can be used for reference implementations.

SR-TE Settings allows you to configure the following on the head-end:

➢ Affinity

➢ Interface affinity

➢ PCC

➢ Flex-algo

➢ SRLG

➢ Performance Measurement

➢ IGP Metric

SR-PCE service helps configure path computation element related configuration on nodes.

L2VPN allows you to configure point-to-point pseudowire (PW):

➢ Static PW or Ethernet VPN Virtual Private Wire Service (EVPN VPWS)

➢ Association of SR-TE Policy

The following diagram shows the workflow to instantiate the L2VPN EPVN VPWS. It represents the logical flow of deployment, which can be deployed either separately or in a single commit.

L3VPN allows you to configure:

➢ VPN

Getting Started


➢ Interface

➢ BGP Neighbor

➢ Association of SR-TE Policy The following diagram shows the workflow to instantiate the L3VPN over SR-TE. It represents the logical flow of deployment, which can be deployed either separately or in a single commit.

SR-TE Core Function Pack


4 SR-TE Core Function Pack Segment Routing prepares networks for business models, where applications can direct network behavior. SR provides the right balance between distributed intelligence and centralized optimization and programming.

SR-TE takes place between a source and destination pair. SR-TE uses the concept of source routing, where the source calculates the path and encodes it in the packet header as a segment. Each segment is an end-to-end path from the source to the destination, and instructs the routers in the provider core network to follow the specified path instead of the shortest path calculated by the IGP.

SR-TE requires minimal configuration on the source router. The SR-TE CFP provides the SR-TE policies and SR-TE ODN. This chapter discusses each of these SR-TE CFP services.

For information about yang models and payloads, see Appendix B - Yang Models and Appendix C - Payloads and XML Outputs respectively in this documentation. For information on how to create SR-Policy, see chapter Configuration in this documentation.

4.1 SR-TE ODN

SR-TE ODN service helps configure an SR Policy template for each color for which on-demand SR Policy instantiation is desired.

4.2 SR-Policy

SR-TE uses a policy to steer traffic through the network. An SR-TE policy path is expressed as a list of segments that specifies the path, called a segment ID (SID) list.

An SR-TE policy uses one or more candidate paths. A candidate path is a single segment list (SID-list) or a set of weighted SID-lists. If a packet is steered into an SR-TE policy, the SID list is pushed on the packet by the head-end. The rest of the network executes the instructions embedded in the SID list.

Each segment is an end-to-end path from the source to the destination, and instructs the routers in the network to follow the specified path instead of the shortest path calculated by the IGP.

An SR policy is uniquely identified by a tuple - head-end, color, and end-point. The head-end is where the SR policy is instantiated or implemented. At a given head-end, an SR policy is uniquely identified by a tuple (color, end-point).

SR-TE Core Function Pack


There are two types of SR-TE policies:

➢ Local Dynamic SR-TE policy: When you configure local dynamic SR-TE policy, the head-end locally calculates the path to the destination address. Dynamic path calculation results in a list of interface IP addresses that traffic engineering maps to adj-SID labels. Routes are learned by way of forwarding adjacencies over the TE tunnel.

➢ Explicit SR-TE policy: An explicit path is a list of IP addresses or labels, each representing a node or link in the explicit path. This feature is enabled through the explicit-path command that allows you to create an explicit path and enter a configuration submode to specify the path.

Example Function Packs


5 Example Function Packs SR-Settings, SR-PCE, L2VPN, and L3VPN are example function packs to illustrate how SR-TE policies are used to instantiate a service with T-SDN FPs. It is optional to install/use these example function packs.

For more information on how to install these function packs, see the Cisco NSO Transport SDN Function Pack Bundle Installation Guide.

For information about the yang models and payloads, see Appendix B - Yang Models and Appendix C - Payloads and XML Outputs respectively in this documentation.

For information on how to create these services, see chapter Configuration in this documentation.

5.1 SR-Settings

Set the segment routing parameters to define the routing path/direction for the segments.

In this service, you can use resource pools to logically allocate or share an available set of resources. Resource pools provide the flexibility to manage the existing resources and adjust the services to the needs of the customer.

For information on how to create SR-Settings and how to allocate resource pools, see chapter Configuration in this documentation.

5.2 SR-PCE

SR-PCE describes a set of procedures by which a Path Computation Client (PCC) can report and delegate control of a policy head-end.

For information on how to create SR-PCE, see chapter Configuration in this documentation.

5.3 L2VPN

L2 Virtual Private Network (L2VPN) establishes an end-to-end layer 2 connection. L2VPN allows disparate systems to be connected in a way that it appears as if they are connected by using a single physical connection, or are using the same LAN.

L2VPNs employ L2 services over MPLS in order to build a topology of point-to-point connections that connect end customer sites in a VPN.



5.4 L3VPN

L3VPN uses virtual routing and forwarding techniques to forward VPN traffic over a network. For every endpoint, e-bgp can be configured to ODN.

The L3VPN service allows you to configure:

• VPN

• Interface

• BGP Neighbor

• Association of SR-TE Policy

Configuration


6 Configuration The topics in this chapter provide information on how to configure the services by using the T-SDN FPs. T-SDN FPs comprise SR-TE CFP. The SR-TE CFP consists of SR-TE ODN services and SR-TE Policy.

Segment Routing integrates with multi-service capabilities of MPLS, including Layer 3 VPN (L3VPN), Virtual Private Wire Service (VPWS), Virtual Private LAN Service (VPLS), and Ethernet VPN (EVPN).

SR-Settings, SR-Policy, L2VPN, and L3VPN are example function packs used to demonstrate SR-TE CFP. You can choose to install the required packages for these function packs during or after T-SDN FPs installation.

For more information on the list of packages extracted during T-SDN FP installation, see Appendix A: Package Categories and Packages in this documentation. For more information on how to install the packages, see the Cisco NSO Transport SDN Function Pack Bundle Installation Guide.

6.1 Creating SR-TE Services

SR-TE takes place through a tunnel between a source and destination pair. In SR-TE, the source calculates the path and encodes it in the packet header as a segment.

SR-TE CFP comprises the SR-ODN and SR-Policy modules to allow you to configure the SR-TE policy at different stages.

6.1.1 Creating SR-ODN

SR-TE ODN service helps to configure an ODN template for a color for which to instantiate the on-demand SR Policy.

To create SR-ODN:

1. The following sample payload shows how to create the SR-ODN service. For the yang model, see Appendix B - Yang Models in this documentation. <config xmlns="http://tail-f.com/ns/config/1.0"> <sr-te xmlns="http://cisco.com/ns/nso/cfp/cisco-tsdn-sr-te"> <odn xmlns="http://cisco.com/ns/nso/cfp/cisco-tsdn-sr-te-sr-odn"> <odn-template> <name>SR-ODN</name> <head-end> <name>P-0</name> </head-end> <head-end> <name>PIOSXR-0</name> </head-end> <maximum-sid-depth>6</maximum-sid-depth>

Configuration


<color>300</color> <bandwidth>200</bandwidth> <dynamic> <metric-type>igp</metric-type> <pce/> <flex-alg>200</flex-alg> <disjoint-path> <type>node</type> <group-id>10</group-id> <sub-id>5</sub-id> </disjoint-path> <affinity> <rule> <action>exclude-any</action> <color>BLUE</color> </rule> </affinity> </dynamic> </odn-template> </odn> </sr-te> </config>

2. Display the plan to view the status of the service. The following table discusses certain plan components unique to this service. For a detailed description of plan components, see NSO documentation.

Plan Component

Value Description

Type cisco-sr-te-cfp-sr-odn-nano-plan-services:head-end

Represents the connected node(device) of the nano plan of a service.

State cisco-sr-te-cfp-sr-odn-nano-plan-services:config-apply

Represents acceptance of service intent and respective configuration application on device

admin@ncs% run show sr-te cisco-sr-te-cfp-sr-odn:odn odn-template-plan POST BACK STATUS ACTION TYPE NAME TRACK GOAL CODE STATE STATUS WHEN ref STATUS ------------------------------------------------------------------------------------------ self self false - - init reached 2020-04-22T21:26:01 - - ready reached 2020-04-22T21:27:44 - - cisco-sr-te-cfp-sr-odn-nano-plan-services:head-end P-0 false - - init reached 2020-04-22T21:26:01 - - cisco-sr-te-cfp-sr-odn-nano-plan-services:config-apply reached 2020-04-22T21:27:44 - - ready reached 2020-04-22T21:27:44 - - cisco-sr-te-cfp-sr-odn-nano-plan-services:head-end PIOSXR-0 false - - init reached 2020-04-22T21:26:01 - - cisco-sr-te-cfp-sr-odn-nano-plan-services:config-apply reached 2020-04-22T21:27:44 - - ready reached 2020-04-22T21:27:44 - -

Configuration


6.1.2 Creating SR-Policies

Use SR-Policies to instruct the routers in the network to follow a specified path instead of the shortest path calculated by the IGP. If a packet is steered into an SR-TE policy, the SID list is pushed on the packet by the head-end. The rest of the network executes the instructions embedded in the SID list.

To create SR-policies:

1. The following is a sample payload to create the SR-Policies service. For the yang model, see Appendix B - Yang Models in this documentation. <config xmlns="http://tail-f.com/ns/config/1.0"> <sr-te xmlns="http://cisco.com/ns/nso/cfp/cisco-tsdn-sr-te"> <policies xmlns="http://cisco.com/ns/nso/cfp/cisco-tsdn-sr-te-sr-policies"> <policy> <name>SR-CLI-DYNAMIC</name> <head-end> <name>PIOSXR-0</name> </head-end> <tail-end>1.1.1.1</tail-end> <color>111</color> <path> <preference>111</preference> <dynamic> <metric-type>te</metric-type> <constraints> <affinity> <rule> <action>include-all</action> <color>GREEN</color> <color>RED</color> </rule> </affinity> <segments> <sid-algorithm>128</sid-algorithm> </segments> </constraints> </dynamic> </path> </policy> </policies> </sr-te> </config>


Configuration


Plan Component

Value Description

Type head-end Represents a connected node (device) of the nano plan of a service.

State cisco-sr-te-cfp-sr-policies-nano-plan-services:config-apply

Represents acceptance of service intent and respective config application on device.

admin@ncs% run show sr-te cisco-sr-te-cfp-sr-policies:policies policy-plan SR-CLI-DYNAMIC plan POST BACK ACTION TYPE NAME TRACK GOAL STATE STATUS WHEN ref STATUS ---------------------------------------------------------------------- self self false - init reached 2020-04-03T19:46:14 - - ready reached 2020-04-03T19:48:57 - - cisco-sr-te-cfp-sr-policies-nano-plan-services:head-end PIOSXR-0 false - init reached 2020-04-03T19:46:14 - - cisco-sr-te-cfp-sr-policies-nano-plan-services:config-apply reached 2020-04-03T19:48:57 - - ready reached 2020-04-03T19:48:57 - -

6.2 Creating SR-Settings Services

SR-TE Settings service allows you to configure the following on the head-end:

• Affinity

• Interface affinity

• PCC

• Flex-algo

• SRLG

• Performance Measurement

• IGP Metric

To create SR-Settings service:

1. The following is a sample payload to create the SR-Settings service. For the yang model, see Appendix B - Yang Models in this documentation. <config xmlns="http://tail-f.com/ns/config/1.0"> <sr-setting xmlns="http://cisco.com/ns/nso/fp/examples/cisco-tsdn-sr-te-settings"> <name>SETTING-1</name> <maximum-sid-depth>100</maximum-sid-depth> <affinity-map-te> <color> <name>BLUE</name>

Configuration


<bit-position>1</bit-position> </color> <color> <name>GREEN</name> <bit-position>2</bit-position> </color> <color> <name>RED</name> <bit-position>0</bit-position> </color> </affinity-map-te> <pcc> <pce> <address> <ipv4> <address>1.1.1.1</address> <precedence>128</precedence> </ipv4> <ipv4> <address>2.2.2.2</address> </ipv4> </address> </pce> </pcc> <node> <name>PIOSXR-0</name> <interface> <if-type>GigabitEthernet</if-type> <if-id>5</if-id> <te> <affinity> <color> <name>GREEN</name> </color> </affinity> <metric>2</metric> </te> </interface> <pcc> <source-address>192.168.2.1</source-address> </pcc> </node> <node> <name>PIOSXR-1</name> <interface> <if-type>GigabitEthernet</if-type> <if-id>7</if-id> <te> <affinity> <color> <name>BLUE</name> </color> </affinity> <metric>2</metric> </te> </interface> <pcc> <disable/> </pcc> </node> </sr-setting> </config>

Configuration



Plan Component

Value Description

Type cisco-sr-te-settings-

fp-nano-plan-services:node

Represents a connected node (device) of the nano plan of a service.

State cisco-sr-te-settings-fp-nano-plan-services:config-apply

Represents acceptance of service intent and respective configuration application on device.

admin@ncs% run show sr-setting-plan POST BACK STATUS ACTION TYPE NAME TRACK GOAL CODE STATE STATUS WHEN ref STATUS ---------------------------------------------------------------------- self self false - - init reached 2020-04-22T22:17:08 - - ready reached 2020-04-22T22:17:12 - - cisco-sr-te-settings-fp-nano-plan-services:node PIOSXR-0 false - - init reached 2020-04-22T22:17:08 - - cisco-sr-te-settings-fp-nano-plan-services:config-apply reached 2020-04-22T22:17:12 - - ready reached 2020-04-22T22:17:12 - - cisco-sr-te-settings-fp-nano-plan-services:node PIOSXR-1 false - - init reached 2020-04-22T22:17:08 - - cisco-sr-te-settings-fp-nano-plan-services:config-apply reached 2020-04-22T22:17:12 - - ready reached 2020-04-22T22:17:12 - -

6.2.1 Allocating Resources by Using Resource Pools

Use resource pools to logically allocate or share an available set of resources. You can add a range of resource values to the pool. You can allocate flex-algo absolute and index values from the pool.

To allocate resources:

Run the following commands: admin@ncs% set resource-pools id-pool SRGB_POOL range start 18000 end 18010 admin@ncs% commit Commit complete.

Configuration


Sample Payloads – Resource Pools

In the following example, the first payload shows a service deployment. The second payload shows an update to the service deployment payload (first payload) with auto-assign-absolute and auto-assign-index features.

Service deployment payload <config xmlns="http://tail-f.com/ns/config/1.0"> <sr-te xmlns="http://cisco.com/ns/nso/cfp/cisco-tsdn-sr-te"> <settings xmlns="http://cisco.com/ns/nso/cfp/cisco-tsdn-sr-te-sr-settings"> <setting> <name>SETTING-1</name> <node> <name>P-0</name> <interface> <if-type>GigabitEthernet</if-type> <if-id>5</if-id> <te> <affinity> <color> <name>BLUE</name> </color> <color> <name>RED</name> </color> </affinity> </te> </interface> <pcc> <source-address>192.168.2.2</source-address> </pcc> </node> <node> <name>P-1</name> <interface> <if-type>GigabitEthernet</if-type> <if-id>3</if-id> <te> <affinity> <color> <name>GREEN</name> </color> <color> <name>RED</name> </color> </affinity> </te> </interface> <pcc> <disable/> </pcc> </node> <node> <name>PIOSXR-0</name>

Configuration


<interface> <if-type>GigabitEthernet</if-type> <if-id>5</if-id> <te> <affinity> <color> <name>GREEN</name> </color> </affinity> <metric>2</metric> </te> </interface> <pcc> <source-address>192.168.2.1</source-address> </pcc> </node> <node> <name>PIOSXR-1</name> <interface> <if-type>GigabitEthernet</if-type> <if-id>7</if-id> <te> <affinity> <color> <name>BLUE</name> </color> </affinity> <metric>2</metric> </te> </interface> <pcc> <disable/> </pcc> </node> <maximum-sid-depth>100</maximum-sid-depth> <affinity-map-te> <color> <name>BLUE</name> <bit-position>1</bit-position> </color> <color> <name>GREEN</name> <bit-position>2</bit-position> </color> <color> <name>RED</name> <bit-position>0</bit-position> </color> </affinity-map-te> <pcc> <pce> <address> <ipv4> <address>1.1.1.1</address> <precedence>128</precedence> </ipv4> <ipv4> <address>2.2.2.2</address> </ipv4> </address> </pce>

Configuration


</pcc> </setting> </settings> </sr-te> </config>

The following payload shows an update to the service deployment payload with the auto-assign-absolute and auto-assign-index features. <config xmlns="http://tail-f.com/ns/config/1.0"> <sr-te xmlns="http://cisco.com/ns/nso/cfp/cisco-tsdn-sr-te"> <settings xmlns="http://cisco.com/ns/nso/cfp/cisco-tsdn-sr-te-sr-settings"> <setting> <name>SETTING-1</name> <sr-global-block> <sr-pool> <sr-pool-name>SRGB_POOL</sr-pool-name> </sr-pool> </sr-global-block> <igp-metric> <metric>1001</metric> <metric-level> <metric> <level>1</level> <value>1002</value> </metric> </metric-level> </igp-metric> <interface-igp-metric> <metric>1007</metric> <metric-level> <metric> <level>1</level> <value>1008</value> </metric> </metric-level> </interface-igp-metric> <slice> <flex-algo> <name>128</name> <affinity-exclude-any>RED</affinity-exclude-any> <affinity-exclude-any>BLUE</affinity-exclude-any> <metric-type>delay</metric-type> <priority>100</priority> </flex-algo> <flex-algo> <name>129</name> <affinity-exclude-any>GREEN</affinity-exclude-any> </flex-algo> <isis> <instance-name>CORE</instance-name> <node> <name>PIOSXR-0</name> <flex-algo> <name>128</name> <algorithm-prefix-sid> <auto-assign-absolute/> </algorithm-prefix-sid> </flex-algo>

Configuration


<flex-algo> <name>129</name> <algorithm-prefix-sid> <index>4</index> </algorithm-prefix-sid> </flex-algo> <loopback> <id>1</id> <flex-algo> <name>128</name> </flex-algo> <flex-algo-enabled-flag>select</flex-algo-enabled-flag> </loopback> <loopback> <id>2</id> <flex-algo> <name>129</name> </flex-algo> <flex-algo-enabled-flag>select</flex-algo-enabled-flag> </loopback> </node> <address-family>both</address-family> <igp-metric> <metric>1004</metric> <metric-level> <metric> <level>1</level> <value>1005</value> </metric> </metric-level> </igp-metric> <mpls-preference>sr-prefer</mpls-preference> </isis> <isis> <instance-name>CORE-2</instance-name> <node> <name>PIOSXR-0</name> <flex-algo> <name>128</name> <algorithm-prefix-sid> <absolute>18006</absolute> </algorithm-prefix-sid> </flex-algo> <flex-algo> <name>129</name> <algorithm-prefix-sid> <auto-assign-index/> </algorithm-prefix-sid> </flex-algo> <loopback> <id>3</id> </loopback> </node> <node> <name>P-0</name> <flex-algo> <name>128</name> <algorithm-prefix-sid> <absolute>18009</absolute>

Configuration


</algorithm-prefix-sid> </flex-algo> <flex-algo> <name>129</name> <algorithm-prefix-sid> <index>7</index> </algorithm-prefix-sid> </flex-algo> <loopback> <id>3</id> </loopback> </node> <address-family>both</address-family> <mpls-preference>sr-prefer</mpls-preference> </isis> </slice> <node> <name>PIOSXR-0</name> <isis> <instance-name>CORE</instance-name> <loopback> <id>1</id> <prefix-sid> <auto-assign-index/> <n-flag-clear/> </prefix-sid> </loopback> <loopback> <id>2</id> <prefix-sid> <index>10</index> </prefix-sid> </loopback> <address-family>both</address-family> </isis> <isis> <instance-name>CORE-2</instance-name> <loopback> <id>3</id> <prefix-sid> <index>8</index> </prefix-sid> </loopback> <address-family>both</address-family> <mpls-preference>sr-prefer</mpls-preference> </isis> <interface> <if-type>GigabitEthernet</if-type> <if-id>5</if-id> <isis> <instance-name>CORE-2</instance-name> <interface-igp-metric> <metric>1009</metric> </interface-igp-metric> </isis> </interface> <interface> <if-type>GigabitEthernet</if-type> <if-id>7</if-id> <isis> <instance-name>CORE</instance-name>

Configuration


<affinity> <color> <name>BLUE</name> </color> <color> <name>RED</name> </color> </affinity> <interface-igp-metric> <metric-level> <metric> <level>2</level> <value>1006</value> </metric> </metric-level> </interface-igp-metric> </isis> </interface> </node> <node> <name>P-0</name> <isis> <instance-name>CORE-2</instance-name> <loopback> <id>3</id> <prefix-sid> <auto-assign-absolute/> </prefix-sid> </loopback> <address-family>both</address-family> <mpls-preference>sr-prefer</mpls-preference> </isis> <interface> <if-type>GigabitEthernet</if-type> <if-id>5</if-id> <isis> <instance-name>CORE-2</instance-name> <interface-igp-metric> <metric>1009</metric> </interface-igp-metric> </isis> </interface> </node> <affinity-map-isis> <color> <name>BLUE</name> <bit-position>1</bit-position> </color> <color> <name>GREEN</name> <bit-position>2</bit-position> </color> <color> <name>RED</name> <bit-position>0</bit-position> </color> </affinity-map-isis> </setting> </settings> </sr-te> </config>

Configuration


6.2.1.1 Verifying Allocation

Verify the allocation status from NSO. admin@ncs% run show sr-setting-prefix-sid-allocation ISIS ALGO NODE INSTANCE LOOPBACK PREFIX PREFIX NAME NAME NODE NAME ID SID NAME SID ------------------------------------------------------------------------- SETTING-1 P-0 P-0 CORE-2 3 18000 128 18009 129 7 SETTING-1 PIOSXR-0 PIOSXR-0 CORE 1 2 128 18001 2 10 129 4 CORE-2 3 8 128 18006 129 3

The following plan displays a successful allocation. admin@ncs% run show sr-setting-plan POST BACK STATUS ACTION TYPE NAME TRACK GOAL CODE STATE STATUS WHEN ref STATUS ------------------------------------------------------------------------------------------ self self false - - init reached 2020-04-22T23:29:25 - - ready reached 2020-04-22T23:31:02 - - cisco-sr-te-settings-fp-nano-plan-services:node P-0 false - - init reached 2020-04-22T23:29:25 - - cisco-sr-te-settings-fp-nano-plan-services:config-apply reached 2020-04-22T23:31:02 - - ready reached 2020-04-22T23:31:02 - - cisco-sr-te-settings-fp-nano-plan-services:node P-1 false - - init reached 2020-04-22T23:29:25 - - cisco-sr-te-settings-fp-nano-plan-services:config-apply reached 2020-04-22T23:30:59 - - ready reached 2020-04-22T23:30:59 - - cisco-sr-te-settings-fp-nano-plan-services:node PIOSXR-0 false - - init reached 2020-04-22T23:29:25 - - cisco-sr-te-settings-fp-nano-plan-services:config-apply reached 2020-04-22T23:31:02 - - ready reached 2020-04-22T23:31:02 - - cisco-sr-te-settings-fp-nano-plan-services:node PIOSXR-1 false - - init reached 2020-04-22T23:29:25 - - cisco-sr-te-settings-fp-nano-plan-services:config-apply reached 2020-04-22T23:30:59 - - ready reached 2020-04-22T23:30:59 - -

6.2.1.2 Adding Resources to the Pool

The following commands show how to add resources to a resource pool. admin@ncs% set sr-setting SETTING-1 node PIOSXR-0 isis CORE-2 loopback 3 prefix-sid auto-assign-index n-flag-clear admin@ncs% set sr-setting SETTING-1 node PIOSXR-0 isis CORE-2 loopback 4 prefix-sid auto-assign-index n-flag-clear admin@ncs% set sr-setting SETTING-1 node PIOSXR-0 isis CORE-2 loopback 5 prefix-sid auto-assign-index n-flag-clear admin@ncs% commit Commit complete.

Configuration


If you add resources to a resource pool beyond a specified range, the plan fails with an error message.

admin@ncs% run show sr-setting-plan POST BACK STATUS ACTION TYPE NAME TRACK GOAL CODE STATE STATUS WHEN ref STATUS ------------------------------------------------------------------------------------------ self self false - - init reached 2020-04-22T23:29:25 - - ready failed 2020-04-22T23:33:20 - - cisco-sr-te-settings-fp-nano-plan-services:node P-0 false - - init reached 2020-04-22T23:29:25 - - cisco-sr-te-settings-fp-nano-plan-services:config-apply reached 2020-04-22T23:31:02 - - ready reached 2020-04-22T23:31:02 - - cisco-sr-te-settings-fp-nano-plan-services:node P-1 false - - init reached 2020-04-22T23:29:25 - - cisco-sr-te-settings-fp-nano-plan-services:config-apply reached 2020-04-22T23:30:59 - - ready reached 2020-04-22T23:30:59 - - cisco-sr-te-settings-fp-nano-plan-services:node PIOSXR-0 false - - init reached 2020-04-22T23:29:25 - - cisco-sr-te-settings-fp-nano-plan-services:config-apply failed 2020-04-22T23:33:20 - - ready not-reached - - - cisco-sr-te-settings-fp-nano-plan-services:node PIOSXR-1 false - - init reached 2020-04-22T23:29:25 - - cisco-sr-te-settings-fp-nano-plan-services:config-apply reached 2020-04-22T23:30:59 - - ready reached 2020-04-22T23:30:59 - - plan failed plan error-info message "com.tailf.pkg.idpool.exceptions.PoolExhaustedException: ID pool SRGB_POOL exhausted"

6.3 Creating SR-PCE Services

SR-PCE service helps set up path computation element related configuration information on devices.

To create SR-PCE service:

1. The following is a sample payload to create the SR-PCE service. For the yang model, see Appendix B - Yang Models in this documentation. <config xmlns="http://tail-f.com/ns/config/1.0"> <sr-pce xmlns="http://cisco.com/ns/nso/fp/examples/cisco-tsdn-sr-te-pce"> <name>PCE-0</name> <node> <name>PIOSXR-0</name> <pce> <address>100.1.1.1</address> <disjoint-path> <group-id> <id>60000</id>

Configuration


<type>srlg</type> <strict/> <lsp> <id>1</id> <pcc-address>2.2.2.2</pcc-address> <lsp-name>LSP-NAME</lsp-name> <shortest-path/> </lsp> </group-id> </disjoint-path> <timers> <reoptimization>600</reoptimization> <keepalive>20</keepalive> <minimum-peer-keepalive>21</minimum-peer-keepalive> </timers> <state-sync> <ipv4> <address>3.3.3.3</address> </ipv4> </state-sync> <password> <type>clear</type> <secret>password123</secret> </password> <backoff> <ratio>11</ratio> <difference>10</difference> <threshold>12</threshold> </backoff> <segment-routing> <strict-sid-only/> <te-latency/> </segment-routing> </pce> </node> </sr-pce> </config>


Plan Component

Value Description

Type cisco-sr-te-sr-pce-

nano-plan-services:node

Represents a connected node (device) of the nano plan of a service.

State cisco-sr-te-sr-pce-nano-plan-services:config-apply

Represents acceptance of service intent and respective configuration application on device.

admin@ncs% run show sr-pce-plan

Configuration


POST BACK STATUS ACTION TYPE NAME TRACK GOAL CODE STATE STATUS WHEN ref STATUS ------------------------------------------------------------------------------------ self self false - - init reached 2020-04-22T16:57:54 - - ready reached 2020-04-22T16:57:57 - - cisco-sr-te-pce-fp-nano-plan-services:node PIOSXR-0 false - - init reached 2020-04-22T16:57:54 - - cisco-sr-te-pce-fp-nano-plan-services:config-apply reached 2020-04-22T16:57:57 - - ready reached 2020-04-22T16:57:57 - -

6.4 Creating Flat L2VPN Services with the L2VPN Example Function Pack

You can implement a custom L2VPN function pack to meet specific requirements. Use the example function pack as a starting point or for design patterns.

There are two types of example L2VPN services: L2VPN P2P and L2VPN EVPN VPWS. Each service requires a mandatory Local Site and an optional Remote Site to create the service.

For the Flat L2VPN yang model, see Appendix B - Yang Models in this documentation.

6.4.1 Creating Flat L2VPN-P2P

To create the Flat L2VPN-P2P service:

1. The following is a sample payload to create a Flat L2VPN-P2P service. <config xmlns="http://tail-f.com/ns/config/1.0"> <flat-L2vpn xmlns="http://cisco.com/ns/nso/fp/examples/cisco-tsdn-flat-L2vpn"> <name>P2P-DOT1Q</name> <service-type>p2p</service-type> <flat-L2vpn-p2p> <pw-id>100</pw-id> <local-site> <pe>PIOSXR-0</pe> <if-type>HundredGigE</if-type> <if-id>0/0/0/8</if-id> <if-encap>dot1q</if-encap> <vlan-id>100</vlan-id> <sub-if-id>100</sub-if-id> <rewrite> <ingress> <translate>1-to-1</translate> <dot1q>123</dot1q> <mode>symmetric</mode> </ingress> </rewrite> <xconnect-group-name>P2P-DOT1Q</xconnect-group-name>

Configuration


<xconnect-encapsulation>mpls</xconnect-encapsulation> <p2p-name>P2P-DOT1Q</p2p-name> <control-word>no</control-word> <pw-class>P2P-DOT1Q</pw-class> <xconnect-local-ip>12.0.0.0</xconnect-local-ip> <xconnect-remote-ip>14.0.0.0</xconnect-remote-ip> <mpls-local-label>101</mpls-local-label> <mpls-remote-label>202</mpls-remote-label> </local-site> <remote-site> <pe>PIOSXR-1</pe> <if-type>HundredGigE</if-type> <if-id>0/0/0/8</if-id> <if-encap>dot1q</if-encap> <vlan-id>100</vlan-id> <sub-if-id>100</sub-if-id> <rewrite> <ingress> <translate>1-to-1</translate> <dot1q>123</dot1q> <mode>symmetric</mode> </ingress> </rewrite> <xconnect-group-name>P2P-DOT1Q</xconnect-group-name> <p2p-name>P2P-DOT1Q</p2p-name> <pw-class>P2P-DOT1Q</pw-class> </remote-site> </flat-L2vpn-p2p> </flat-L2vpn> </config>

2. Display the plan to view the status of the service. For detailed service-state-changes notifications, see chapter Notifications in this documentation.

The following table discusses certain plan components unique to this service. For a detailed description of plan components, see NSO documentation.

Plan Component

Value Description

Type

local-site This represents the Local-site (mandatory site) of the L2VPN service.

remote-site This represents the remote-site (optional site) of the L2VPN service.

State

cisco-flat-L2vpn-fp-nano-plan-services:config-apply

This represents the device configuration state in the nano-plan of a service.

Configuration


admin@ncs% run show flat-L2vpn-plan L2vpn-p2p-1 plan BACK POST ACTION TYPE NAME TRACK GOAL STATE STATUS WHEN ref STATUS -------------------------------------------------------------------------------------- self self false - init reached 2020-03-03T22:06:26 - - ready reached 2020-03-03T22:07:01 - - local-site PIOSXR-0 false - init reached 2020-03-03T22:06:26 - - cisco-flat-L2vpn-fp-nano-plan-services:config-apply reached 2020-03-03T22:06:30 - - ready reached 2020-03-03T22:06:30 - - remote-site PIOSXR-1 false - init reached 2020-03-03T22:06:26 - - cisco-flat-L2vpn-fp-nano-plan-services:config-apply reached 2020-03-03T22:06:30 ready reached 2020-03-03T22:06:30 - -

6.4.2 Creating Flat L2VPN – EVPN

Virtual Private Wire Service is the EVPN service provisioned by L2VPN.

For every site (local/remote), you can configure BGP in EVPN service. SR-ODN allows a service head-end router to automatically instantiate an SR-policy to a BGP next-hop when required for EVPN service.

Note: You must create the L2VPN-EVPN service to create the L2VPN SR-TE preferred path service and the L2VPN SR-TE-ODN service.

To create the Flat L2VPN –EVPN-VPWS:

1. The following is a sample payload to create the service. <flat-L2vpn xmlns="http://cisco.com/ns/nso/fp/examples/cisco-tsdn-flat-L2vpn"> <name>L2vpn-dynamic-02</name> <service-type>evpn-vpws</service-type> <flat-L2vpn-evpn-vpws> <evi-id>1000</evi-id> <local-site> <pe>PIOSXR-0</pe> <if-type>HundredGigE</if-type> <if-id>0/0/1/0</if-id> <if-description>L2VPN-Dynamic-02</if-description> <if-encap>untagged</if-encap> <sub-if-id>23</sub-if-id> <xconnect-group-name>evpn_vpws_nso</xconnect-group-name> <p2p-name>EVPN-PIOSXR-0</p2p-name> <evi-source>1</evi-source> <evi-target>2</evi-target> </local-site> <remote-site>

Configuration


<pe>PIOSXR-1</pe> <if-type>TenGigE</if-type> <if-id>0/0/0/35</if-id> <if-description>L2VPN-Dynamic-02</if-description> <if-encap>untagged</if-encap> <sub-if-id>40</sub-if-id> <xconnect-group-name>evpn_vpws_nso</xconnect-group-name> <p2p-name>EVPN-PIOSXR-1</p2p-name> </remote-site> </flat-L2vpn-evpn-vpws> </flat-L2vpn> </config>


The following table discusses certain plan components unique to this service. For a detailed description of plan components, see NSO documentation.

Plan Component

Value Description

Type

local-site This represents the Local-site (mandatory site) of the L2VPN service.

remote-site This represents the remote-site (optional site) of the L2VPN service.

State cisco-flat-L2vpn-fp-nano-plan-services:config-apply


admin@ncs% run show flat-L2vpn-plan L2vpn-dynamic-02 plan component BACK POST ACTION TYPE NAME TRACK GOAL STATE STATUS WHEN ref STATUS -------------------------------------------------------------------------------------- self self false - init reached 2020-01-15T00:53:46 - - ready reached 2020-01-15T00:53:51 - - local-site PIOSXR-0 false - init reached 2020-01-15T00:53:46 - - cisco-flat-L2vpn-fp-nano-plan-services:config-apply reached 2020-01-15T00:53:50 - - ready reached 2020-01-15T00:53:50 - - remote-site PIOSXR-1 false - init reached 2020-01-15T00:53:46 - -

Configuration


cisco-flat-L2vpn-fp-nano-plan-services:config-apply reached 2020-01-15T00:53:50 - - ready reached 2020-01-15T00:53:50 - -

6.4.2.1 Creating L2VPN SR-TE ODN

On-Demand Next Hop (ODN) for L2VPN creates a SR-TE auto-tunnel and uses the auto-tunnel for pseudowire dataplane. You must create the L2VPN route policy to use the SR-TE ODN service. For more information, see section Creating Flat L2VPN – EVPN in this documentation.

To create L2VPN SR-TE ODN:

1. The following is a sample payload to create the route-policy. <config xmlns="http://tail-f.com/ns/config/1.0"> <l2vpn-route-policy xmlns="http://cisco.com/ns/nso/fp/examples/cisco-tsdn-flat-L2vpn"> <name>L2-RP-local</name> <color> <id>100</id> <ipv4> <rd>1.1.1.1:1</rd> <rd>1.1.1.2:1</rd> </ipv4> </color> <color> <id>101</id> <ipv4> <rd>2.1.1.1:1</rd> <rd>2.1.1.2:1</rd> </ipv4> </color> </l2vpn-route-policy> <l2vpn-route-policy xmlns="http://cisco.com/ns/nso/fp/examples/cisco-tsdn-flat-L2vpn"> <name>L2-RP-remote</name> <color> <id>100</id> <ipv4> <rd>3.1.1.1:1</rd> <rd>3.1.1.2:1</rd> </ipv4> </color> <color> <id>101</id> <ipv4> <rd>4.1.1.1:1</rd> <rd>4.1.1.2:1</rd> </ipv4> </color> </l2vpn-route-policy> </config>

Configuration


2. The following is a sample payload to create the service. <flat-L2vpn xmlns="http://cisco.com/ns/nso/fp/examples/cisco-tsdn-flat-L2vpn"> <name>L2vpn-dynamic-02</name> <service-type>evpn-vpws</service-type> <flat-L2vpn-evpn-vpws> <evi-id>1000</evi-id> <local-site> <pe>PIOSXR-0</pe> <if-type>HundredGigE</if-type> <if-id>0/0/1/0</if-id> <if-description>L2VPN-Dynamic-02</if-description> <if-encap>untagged</if-encap> <xconnect-group-name>evpn_vpws_nso</xconnect-group-name> <p2p-name>EVPN-PIOSXR-0</p2p-name> <bgp> <as-no>65001</as-no> <remote-as-no>2</remote-as-no> <neighbor-ipv4>9.9.9.9</neighbor-ipv4> <update-source> <if-type>Loopback</if-type> <if-id>3</if-id> </update-source> </bgp> <sr-te> <odn> <route-policy>L2-RP-local</route-policy> </odn> </sr-te> <evi-source>1</evi-source> <evi-target>2</evi-target> </local-site> <remote-site> <pe>PIOSXR-1</pe> <if-type>TenGigE</if-type> <if-id>0/0/0/35</if-id> <if-description>L2VPN-Dynamic-02</if-description> <if-encap>untagged</if-encap> <xconnect-group-name>evpn_vpws_nso</xconnect-group-name> <p2p-name>EVPN-PIOSXR-1</p2p-name> <bgp> <as-no>65001</as-no> <remote-as-no>2</remote-as-no> <neighbor-ipv4>10.10.10.10</neighbor-ipv4> <update-source> <if-type>Loopback</if-type> <if-id>3</if-id> </update-source> </bgp> <sr-te> <odn> <route-policy>L2-RP-remote</route-policy> </odn> </sr-te> </remote-site> </flat-L2vpn-evpn-vpws> </flat-L2vpn> </config>

3. Display the plan to view the status of the service.

Configuration


6.4.2.2 Creating L2VPN SR-TE Preferred Path

A candidate path has a preference. If two policies have same {color, endpoint} but different preferences, the policy with the highest preference is selected. An SR-TE policy initiates a single (selected) path, which is the preferred valid candidate path.

You must create the L2VPN SR-TE preferred path service on top of the L2VPN-EVPN-VPWS service. For more information, see section Creating Flat L2VPN – EVPN in this documentation.

To create L2VPN SR-TE preferred path:

1. The following is a sample payload to create the SR-TE preferred path. <config xmlns="http://tail-f.com/ns/config/1.0"> <flat-L2vpn xmlns="http://cisco.com/ns/nso/fp/examples/cisco-tsdn-flat-L2vpn"> <name>L2vpn-dynamic-02</name> <service-type>evpn-vpws</service-type> <flat-L2vpn-evpn-vpws> <evi-id>1000</evi-id> <local-site> <pe>PIOSXR-0</pe> <if-type>HundredGigE</if-type> <if-id>0/0/1/0</if-id> <if-description>L2VPN-Dynamic-02</if-description> <if-encap>untagged</if-encap> <xconnect-group-name>evpn_vpws_nso</xconnect-group-name> <p2p-name>EVPN-PIOSXR-0</p2p-name> <sr-te> <preferred-path> <policy>SR-CLI-ERO-VPWS-PIOSXR-0</policy> </preferred-path> </sr-te> <pw-class>ero-nso</pw-class> <evi-source>1</evi-source> <evi-target>2</evi-target> </local-site> <remote-site> <pe>PIOSXR-1</pe> <if-type>TenGigE</if-type> <if-id>0/0/0/35</if-id> <if-description>L2VPN-Dynamic-02</if-description> <if-encap>untagged</if-encap> <xconnect-group-name>evpn_vpws_nso</xconnect-group-name> <p2p-name>EVPN-PIOSXR-1</p2p-name> <sr-te> <preferred-path> <policy>SR-CLI-ERO-VPWS-PIOSXR-1</policy> </preferred-path> </sr-te> <pw-class>ero-nso</pw-class> </remote-site> </flat-L2vpn-evpn-vpws> </flat-L2vpn> </config>

3. Verify the configuration on the device by running the sh run l2vpn command.

Configuration


6.5 Creating Flat L3VPN Services with the L3VPN Example Function Pack

You can implement a custom L3VPN function pack to meet specific requirements. Use the example function pack as a starting point or for design patterns.

The example Flat L3VPN service allows you to configure:

• VPN

• Interface

• BGP Neighbor

• Association of SR-TE Policy

The following table describes the L3VPN plan components.

Plan Component

Value Description

Type endpoint This component represents one of the endpoints of L3VPN service.

State cisco-flat-L3vpn-fp-nano-plan-services:config-apply


6.5.1 Creating Flat L3VPN

1. The following is a sample payload to create the Flat L3VPN service. For the yang model, see Appendix B - Yang Models in this documentation. <config xmlns="http://tail-f.com/ns/config/1.0"> <flat-L3vpn xmlns="http://cisco.com/ns/nso/fp/examples/cisco-tsdn-flat-L3vpn"> <name>L3-NC</name> <endpoint> <endpoint-name>nc-0</endpoint-name> <access-pe>PIOSXR-0</access-pe> <if-type>BVI</if-type> <if-id>168</if-id> <pe-ip-addr>169.1.1.1/28</pe-ip-addr> <as-no>65001</as-no> <ce-pe-prot> <e-bgp> <neighbor-ipv4>169.1.1.2</neighbor-ipv4> <remote-as-ipv4>65002</remote-as-ipv4> </e-bgp> </ce-pe-prot> <vrf> <vrf-definition>L3VPN-0</vrf-definition> <route-distinguisher>1:2</route-distinguisher> <address-family>

Configuration


<address-family>ipv4</address-family> <vpn-target> <rt-value>100:101</rt-value> <rt-type>export</rt-type> </vpn-target> <vpn-target> <rt-value>100:102</rt-value> <rt-type>import</rt-type> </vpn-target> <vpn-target> <rt-value>200:100</rt-value> <rt-type>both</rt-type> </vpn-target> </address-family> </vrf> <sr-te> <route-policy>L3-RP-EP1</route-policy> </sr-te> <l2-attachment-circuit> <name>AC1</name> <if-type>GigabitEthernet</if-type> <if-id>0/0/0/6</if-id> <vlan-id>100</vlan-id> <rewrite> <ingress> <push/> <dot1q>123</dot1q> </ingress> </rewrite> </l2-attachment-circuit> <l2-attachment-circuit> <name>AC2</name> <if-type>GigabitEthernet</if-type> <if-id>0/0/0/5</if-id> <vlan-id>200</vlan-id> <rewrite> <ingress> <pop>1</pop> <mode>symmetric</mode> </ingress> </rewrite> </l2-attachment-circuit> </endpoint> </flat-L3vpn> <l3vpn-route-policy xmlns="http://cisco.com/ns/nso/fp/examples/cisco-tsdn-flat-L3vpn"> <name>L3-RP-EP1</name> <color> <id>100</id> <ipv4> <prefix>1.1.1.1/32</prefix> <prefix>1.1.1.2/32</prefix> </ipv4> </color> <color> <id>101</id> <ipv4> <prefix>2.1.1.1/32</prefix> <prefix>2.1.1.2/32</prefix> </ipv4> </color>

Configuration


</l3vpn-route-policy> <l3vpn-route-policy xmlns="http://cisco.com/ns/nso/fp/examples/cisco-tsdn-flat-L3vpn"> <name>L3-RP-EP2</name> <color> <id>100</id> <ipv4> <prefix>3.1.1.1/32</prefix> <prefix>3.1.1.2/32</prefix> </ipv4> </color> <color> <id>101</id> <ipv4> <prefix>4.1.1.1/32</prefix> <prefix>4.1.1.2/32</prefix> </ipv4> </color> </l3vpn-route-policy> </config>


admin@ncs% run show flat-L3vpn-plan POST BACK STATUS ACTION TYPE NAME TRACK GOAL CODE STATE STATUS WHEN ref STATUS ------------------------------------------------------------------------------------------ self self false - - init reached 2020-05-02T00:45:30 - - ready reached 2020-05-02T00:45:33 - - endpoint nc-0 false - - init reached 2020-05-02T00:45:30 - - cisco-flat-L3vpn-fp-nano-plan-services:config-apply reached 2020-05-02T00:45:33 - - ready reached 2020-05-02T00:45:33 - -

6.5.2 Creating L3VPN SR-TE ODN

On-Demand Next Hop (ODN) for L2VPN creates a SR-TE auto-tunnel and uses the auto-tunnel for pseudowire dataplane.

To create L3VPN SR-TE ODN:

1. Use the following payload to create the route-policy. You must create the L3VPN route-policy to use SR-TE ODN in L3VPN service. <config xmlns="http://tail-f.com/ns/config/1.0"> <l3vpn-route-policy xmlns="http://cisco.com/ns/nso/fp/examples/cisco-tsdn-flat-L3vpn"> <name>L3-RP-EP1</name> <color> <id>100</id> <ipv4>

Configuration


<prefix>1.1.1.1/32</prefix> <prefix>1.1.1.2/32</prefix> </ipv4> </color> <color> <id>101</id> <ipv4> <prefix>2.1.1.1/32</prefix> <prefix>2.1.1.2/32</prefix> </ipv4> </color> </l3vpn-route-policy> <l3vpn-route-policy xmlns="http://cisco.com/ns/nso/fp/examples/cisco-tsdn-flat-L3vpn"> <name>L3-RP-EP2</name> <color> <id>100</id> <ipv4> <prefix>3.1.1.1/32</prefix> <prefix>3.1.1.2/32</prefix> </ipv4> </color> <color> <id>101</id> <ipv4> <prefix>4.1.1.1/32</prefix> <prefix>4.1.1.2/32</prefix> </ipv4> </color> </l3vpn-route-policy> </config>

2. The following is a sample payload to create the SR-ODN service for L3VPN. <config xmlns="http://tail-f.com/ns/config/1.0"> <flat-L3vpn xmlns="http://cisco.com/ns/nso/fp/examples/cisco-tsdn-flat-L3vpn"> <name>L3</name> <endpoint> <endpoint-name>nc-0</endpoint-name> <access-pe>P-0</access-pe> <if-type>Loopback</if-type> <if-id>3</if-id> <pe-ip-addr>169.1.1.1/32</pe-ip-addr> <as-no>65001</as-no> <ce-pe-prot> <e-bgp> <neighbor-ipv4>169.1.1.2</neighbor-ipv4> <remote-as-ipv4>65002</remote-as-ipv4> </e-bgp> </ce-pe-prot> <vrf> <vrf-definition>L3VPN</vrf-definition> <route-distinguisher>1:2</route-distinguisher> <vpn-id>11:13</vpn-id> <address-family> <address-family>ipv4</address-family> <vpn-target> <rt-value>100:101</rt-value> <rt-type>export</rt-type>

Configuration


</vpn-target> <vpn-target> <rt-value>100:102</rt-value> <rt-type>import</rt-type> </vpn-target> <vpn-target> <rt-value>200:100</rt-value> <rt-type>both</rt-type> </vpn-target> </address-family> </vrf> <sr-te> <route-policy>L3-RP-EP2</route-policy> </sr-te> </endpoint> <endpoint> <endpoint-name>nc-1</endpoint-name> <access-pe>P-1</access-pe> <if-type>Loopback</if-type> <if-id>3</if-id> <pe-ip-addr>169.1.1.1/32</pe-ip-addr> <as-no>65001</as-no> <ce-pe-prot> <e-bgp> <neighbor-ipv4>169.1.1.2</neighbor-ipv4> <remote-as-ipv4>65002</remote-as-ipv4> </e-bgp> </ce-pe-prot> <vrf> <vrf-definition>L3VPN</vrf-definition> <route-distinguisher>1:2</route-distinguisher> <address-family> <address-family>ipv4</address-family> <vpn-target> <rt-value>100:101</rt-value> <rt-type>export</rt-type> </vpn-target> <vpn-target> <rt-value>100:102</rt-value> <rt-type>import</rt-type> </vpn-target> <vpn-target> <rt-value>200:100</rt-value> <rt-type>both</rt-type> </vpn-target> </address-family> </vrf> </endpoint> </flat-L3vpn> </config>

3. To verify the configuration:

a. Display and verify the plan is in the reached state.

b. Log in to the device and verify the route-policy is pushed to the device.

c. Verify the VPN is created under the BGP router.

Configuration


6.5.3 Creating BVI L3VPN

A Bridge Virtual Interface (BVI) is a virtual interface within the router that acts like a normal routed interface that does not support bridging, but represents the comparable bridge group to routed interfaces within the router. When you configure and enable routing on the BVI, packets that come in on a routed interface, which are destined for a host on a segment in a bridge group, are routed to the BVI. From BVI, the packet is forwarded to the bridging engine, which forwards it through a bridged interface. Essentially, a BVI acts as the routed interface for the merged interfaces that are actually bridged.

You can configure a BVI interface as a routing interface for the bridge domain for a L3VPN service.

To create BVI L3VPN:

1. The following is a sample payload to create the BVI interface for L3VPN. <config xmlns="http://tail-f.com/ns/config/1.0"> <flat-L3vpn xmlns="http://cisco.com/ns/nso/fp/examples/cisco-tsdn-flat-L3vpn"> <name>L3-CLI</name> <endpoint> <endpoint-name>nc-0</endpoint-name> <access-pe>PIOSXR-0</access-pe> <if-type>BVI</if-type> <if-id>168</if-id> <pe-ip-addr>169.1.1.1/28</pe-ip-addr> <as-no>65001</as-no> <ce-pe-prot> <e-bgp> <neighbor-ipv4>169.1.1.2</neighbor-ipv4> <remote-as-ipv4>65002</remote-as-ipv4> </e-bgp> </ce-pe-prot> <vrf> <vrf-definition>L3VPN-0</vrf-definition> <route-distinguisher>1:2</route-distinguisher> <address-family> <address-family>ipv4</address-family> <vpn-target> <rt-value>200:100</rt-value> <rt-type>both</rt-type> </vpn-target> <vpn-target> <rt-value>100:101</rt-value> <rt-type>export</rt-type> </vpn-target> <vpn-target> <rt-value>100:102</rt-value> <rt-type>import</rt-type> </vpn-target> </address-family> </vrf> <l2-attachment-circuit> <name>AC1</name> <if-type>GigabitEthernet</if-type>

Configuration


<if-id>0/0/0/6</if-id> <vlan-id>100</vlan-id> <rewrite> <ingress> <push/> <dot1q>123</dot1q> </ingress> </rewrite> </l2-attachment-circuit> <l2-attachment-circuit> <name>AC2</name> <if-type>GigabitEthernet</if-type> <if-id>0/0/0/5</if-id> <vlan-id>200</vlan-id> <rewrite> <ingress> <pop>1</pop> <mode>symmetric</mode> </ingress> </rewrite> </l2-attachment-circuit> </endpoint> </flat-L3vpn> </config>

2. Log in to the device and verify the configuration. admin@ncs% show cisco-flat-L3vpn-fp:flat-L3vpn VPN

Working with Action Commands


7 Working with Action Commands Use the action commands to perform specific tasks on services, such as service cleanup, to get the latest service modifications, and to redeploy services.

7.1 Service Cleanup Actions

When you try to perform a regular service deletion, it may fail for various factors, such as the device being unreachable. This leaves the internal CDB with stale entries of the service and the plan may reflect the failures. When the regular service deletion fails to delete the service elements, use the Cleanup action to clean up all the data created by the service.

Note: You must use the Cleanup action only if the regular service deletion fails and no other recovery mechanisms are available.

The following table discusses the command arguments for the various services.

Arguments Description

service-type This is the type of the service, such as SR-TE ODN.

service This is the name of the service to clean.

device This is the name of the device to clean under a given service. This parameter is optional. If you do not provide the device name, it cleans up the entire service.

service-name This is the name of the service to clean.

local-site-only This can point to an unreachable local-site that is replaced by another reachable local site device in the service.

remote-site-only This can point to an unreachable remote-site that is removed from the service.

endpoint This is the endpoint name in the service. If you do not provide any other parameter, it cleans up the entire service.

No-networking This flag indicates if NSO must delete the service components from network devices. By default, it is set to true.

When true, NSO cleanup does not remove configuration from network devices. When false, NSO cleansup the device configuration



7.1.1 SR-ODN

Perform the Cleanup action to clean up either a specific device in the service or the entire service. Cleaning up the entire service cleans up all the devices in the service. To clean up SR-ODN service per device

The following command shows how to clean up the SR-ODN service for a device. admin@ncs% request sr-te cleanup service-type sr-odn service SR-ODN device PIOSXR-0 no-networking true success true detail Cleaning up SR TE service: SR-ODN Removed all plan components Removing service /cisco-sr-te-cfp:sr-te/cisco-sr-te-cfp-sr-odn:odn/cisco-sr-te-cfp-sr-odn:odn-template{SR-ODN} Removed service /cisco-sr-te-cfp:sr-te/cisco-sr-te-cfp-sr-odn:odn/cisco-sr-te-cfp-sr-odn:odn-template{SR-ODN} Removing service /cisco-sr-te-cfp:sr-te/cisco-sr-te-cfp-sr-odn-internal:odn/cisco-sr-te-cfp-sr-odn-internal:odn-template{SR-ODN P-0} Removed service /cisco-sr-te-cfp:sr-te/cisco-sr-te-cfp-sr-odn-internal:odn/cisco-sr-te-cfp-sr-odn-internal:odn-template{SR-ODN P-0} Removing service /cisco-sr-te-cfp:sr-te/cisco-sr-te-cfp-sr-odn-internal:odn/cisco-sr-te-cfp-sr-odn-internal:odn-template{SR-ODN PIOSXR-0} Removed service /cisco-sr-te-cfp:sr-te/cisco-sr-te-cfp-sr-odn-internal:odn/cisco-sr-te-cfp-sr-odn-internal:odn-template{SR-ODN PIOSXR-0} Removing service oper: /cisco-sr-te-cfp:sr-te/cisco-sr-te-cfp-sr-odn-internal:odn/odn-template-oper-data{SR-ODN P-0 service-commit} Removing service oper: /cisco-sr-te-cfp:sr-te/cisco-sr-te-cfp-sr-odn-internal:odn/odn-template-oper-data{SR-ODN PIOSXR-0 service-commit} Removed service oper Removed side-effects Removed side-effects Removed side-effects Removed kickers Removed kickers Removed kickers Cleanup Successful

To clean up the SR-ODN service

The following command cleans up all the devices in the entire service. admin@ncs% request sr-te cleanup service-type sr-odn service SR-ODN no-networking true success true detail Cleaning up SR TE service: SR-ODN Removed all plan components Removed service oper Removed side-effects Removed side-effects Removed kickers Removed kickers Cleanup Successful



7.1.2 SR-Policy

A policy service can have only one head-end. Therefore, you can clean up only the service, even if you provide a device name.

The following action command shows how to clean up the service. admin@ncs% request sr-te cleanup service-type sr-policy service SR-CLI-DYNAMIC no-networking true success true detail Cleaning up SR TE service: SR-CLI-DYNAMIC Removed all plan components Removed service oper Removing service /cisco-sr-te-cfp:sr-te/cisco-sr-te-cfp-sr-policies:policies/cisco-sr-te-cfp-sr-policies:policy{SR-CLI-DYNAMIC} Removed service /cisco-sr-te-cfp:sr-te/cisco-sr-te-cfp-sr-policies:policies/cisco-sr-te-cfp-sr-policies:policy{SR-CLI-DYNAMIC} Removed side-effects Removed side-effects Removed kickers Removed kickers Cleanup Successful

7.1.3 SR-Settings

Perform the Cleanup action either on a specific device or on the entire service. Cleaning up the entire service cleans up all the devices in the service.

To clean up SR-Settings service per device admin@ncs% request sr-setting-action cleanup service SETTING-1 device PIOSXR-1 no-networking true success true detail Cleaning up SR TE service: SETTING-1 Removed all plan components Removing service oper: /cisco-sr-te-settings-fp-internal:sr-setting-internal/sr-setting-oper-data{SETTING-1 PIOSXR-1} Removed service oper Removed side-effects Removed side-effects Removed kickers Removing kicker: /kickers/data-kicker{"pre-condition: /cisco-sr-te-settings-fp-internal:sr-setting-internal/sr-setting-plan{SETTING-1 PIOSXR-1}/plan/component{ncs:self self}/state{cisco-sr-te-settings-fp-nano-services:config-apply}"} Removed kickers Cleanup Successful

To clean up the SR-Settings service admin@ncs% request sr-setting-action cleanup service SETTING-1 no-networking true success true detail Cleaning up SR TE service: SETTING-1 Removed all plan components Removing service oper: /cisco-sr-te-settings-fp-internal:sr-setting-internal/sr-setting-oper-data{SETTING-1 PIOSXR-1} Removed service oper Removed side-effects



Removed side-effects Removed kickers Removing kicker: /kickers/data-kicker{"pre-condition: /cisco-sr-te-settings-fp-internal:sr-setting-internal/sr-setting-plan{SETTING-1 PIOSXR-1}/plan/component{ncs:self self}/state{cisco-sr-te-settings-fp-nano-services:config-apply}"} Removed kickers Cleanup Successful

7.1.4 SR-PCE

Perform the Cleanup action either on a specific device or on the entire service. Cleaning up the entire service cleans up all the devices in the service.

To clean up SR-PCE service per device admin@ncs% request sr-te cleanup service-type sr-pce service PCE-0 device PIOSXR-0 no-networking true admin@ncs% request sr-pce-action cleanup service PCE-0 no-networking true success true detail Cleaning up SR TE service: PCE-0 Removed all plan components Removing service /cisco-sr-te-pce-fp:sr-pce{PCE-0} Removed service /cisco-sr-te-pce-fp:sr-pce{PCE-0} Removing service /cisco-sr-te-pce-fp-internal:sr-pce{PCE-0 PIOSXR-0} Removed service /cisco-sr-te-pce-fp-internal:sr-pce{PCE-0 PIOSXR-0} Removing service oper: /cisco-sr-te-pce-fp-internal:sr-pce-internal/sr-pce-oper-data{PCE-0 PIOSXR-0} Removed service oper Removed side-effects Removed side-effects Removed kickers Removed kickers Cleanup Successful

To clean up the SR-Settings service admin@ncs% request sr-pce-action cleanup service PCE-0 no-networking true success true detail Cleaning up SR TE service: PCE-0 Removed all plan components Removing service /cisco-sr-te-pce-fp:sr-pce{PCE-0} Removed service /cisco-sr-te-pce-fp:sr-pce{PCE-0} Removing service /cisco-sr-te-pce-fp-internal:sr-pce{PCE-0 PIOSXR-0} Removed service /cisco-sr-te-pce-fp-internal:sr-pce{PCE-0 PIOSXR-0} Removing service oper: /cisco-sr-te-pce-fp-internal:sr-pce-internal/sr-pce-oper-data{PCE-0 PIOSXR-0} Removed service oper Removed side-effects Removed side-effects Removed kickers Removed kickers Cleanup Successful



7.1.5 L2VPN Example Services

You can clean up the service only for a remote site. You cannot clean up the local site since it is a mandatory entity for the existence of L2VPN service.

You can clean up a specific remote site in the service or clean up the entire service. Cleaning up the entire service cleans up all the remote sites and local sites in the service.

To cleanup the service for a specific remote site admin@ncs% request flat-L2vpn-actions cleanup service P2P-DOT1Q remote-site-only PIOSXR-1 success true detail Cleaning up L2vpn service: P2P-DOT1Q Removed all plan components Removing service /cisco-flat-L2vpn-fp:flat-L2vpn{P2P-DOT1Q}/flat-L2vpn-p2p/remote-site Removed service /cisco-flat-L2vpn-fp:flat-L2vpn{P2P-DOT1Q}/flat-L2vpn-p2p/remote-site Removing service /cisco-flat-L2vpn-fp-internal-remote-site:flat-L2vpn-internal-remote-site-service{P2P-DOT1Q PIOSXR-1} Removed service /cisco-flat-L2vpn-fp-internal-remote-site:flat-L2vpn-internal-remote-site-service{P2P-DOT1Q PIOSXR-1} Removing service oper: /cisco-flat-L2vpn-fp-internal-remote-site:flat-L2vpn-internal-remote-site/flat-L2vpn-oper-data{P2P-DOT1Q PIOSXR-1} Removed service oper Removed side-effects Removed side-effects Removed kickers Cleanup Successful

To cleanup the entire L2VPN service

The following command shows how to clean up the service. admin@ncs% request flat-L2vpn-actions cleanup service P2P-DOT1Q no-networking true success true detail Cleaning up L2vpn service: P2P-DOT1Q Removed all plan components Removed service oper Removed side-effects Removed side-effects Removed kickers Cleanup Successful




Perform the Cleanup action to clean up a specific endpoint or the entire service. Cleaning up the entire service cleans up all the endpoints in the service.

To clean up the service for a specific endpoint admin@ncs% request flat-L3vpn-actions cleanup service L3 device nc-0 no-networking true success true detail Cleaning up L3vpn service: L3 Removed all plan components Removing service oper: /cisco-flat-L3vpn-fp-internal:flat-L3vpn-internal/flat-L3vpn-oper-data{L3 nc-0} Removed service oper Removed side-effects Removed side-effects Removed kickers Removing kicker: /kickers/data-kicker{"pre-condition: /cisco-flat-L3vpn-fp-internal:flat-L3vpn-internal/flat-L3vpn-plan{L3 nc-0}/plan/component{ncs:self self}/state{cisco-flat-L3vpn-fp-nano-services:config-apply}"} Removed kickers Cleanup Successful

To clean up the L3VPN service admin@ncs% run request flat-L3vpn-actions cleanup service L3 no-networking true success true detail Cleaning up L3vpn service: L3 Removed all plan components Removed service oper Removed side-effects Removed kickers Cleanup Successful

7.2 Auto Cleanup

You must use the Cleanup action only if the regular service deletion fails and no other recovery mechanisms are available.

Note: Use the auto-cleanup action only after you have tried the manual service cleanup operation discussed in section Service Cleanup Actions.

With the auto-cleanup action, you can automatically clean up the device related configuration from NSO when the device is not reachable. Set the auto-cleanup flag to true as follows to use this feature. By default, this flag is set to false.



After the clean up is complete, depending on whether the NSO or the device holds the correct configuration, perform a sync-to or sync-from to synchronize NSO and the device, when the device is active.

This topic contains information for the following services in the order listed.

➢ SR-TE CFP

➢ Example Function Packs

SR-TE CFP admin@ncs% set cisco-sr-te-cfp:cfp-configurations auto-cleanup true admin@ncs% commit Commit complete.


SR-Settings admin@ncs% set cisco-sr-te-settings-fp:cfp-configurations auto-cleanup true admin@ncs% commit Commit complete.

SR-PCE admin@ncs% set cisco-sr-te-pce-fp:cfp-configurations auto-cleanup true admin@ncs% commit Commit complete.

L2VPN admin@ncs% set cisco-flat-L2vpn-fp:cfp-configurations auto-cleanup true admin@ncs% commit Commit complete.

L3VPN

admin@ncs% set cisco-flat-L3vpn-fp:cfp-configurations auto-cleanup true admin@ncs% commit Commit complete.



7.3 get-modifications Action

The get-modifications action is similar to the service get-modifications action. You can perform this action either at the service level or at the device level.

This action returns the data the service modified in the CDB (whether it is device configuration or internal data), either in the CLI curly bracket format or NETCONF XML edit configuration format. By default, the output format is CLI.

This data is available only if the parameter /services/global-settings/collect-forward-diff is set to true as follows before you create the service. admin@ncs% show services global-settings collect-forward-diff collect-forward-diff true;

Note: Setting this parameter to true can have severe performance implications. For more information about this parameter, see the NSO User Guide.

This section provides the output in CLI format, which is the default format for the SR-TE CFP services. To view the XML format of the output, see Appendix C - Payloads and XML Outputs in this documentation.

7.3.1 SR-ODN

Perform the get-modifications action either at the service level or at the device level.

get-modifications action for the service admin@ncs% request sr-te cisco-sr-te-cfp-sr-odn:odn odn-template SR-ODN action get-modifications outformat cli message devices { device P-0 { config { segment-routing-ms-cfg:sr { traffic-engineering { on-demand-colors { + on-demand-color 300 { + on-demand-color-dyn-mpls { + on-demand-color-dyn-mpls-metric { + metric-type igp; + enable; + } + on-demand-color-dyn-mpls-pce { + enable; + } + disjoint-path { + group-id 10; + disjointness-type node; + sub-id 5; + } + on-demand-color-dyn-mpls-flex-algorithm 200; + enable; + affinity-rules {



+ affinity-rule affinity-exclude-any { + affinity-name BLUE; + } + } + } + bandwidth 200; + maximum-sid-depth 6; + enable; + } } } } } } }

get-modifications action per device admin@ncs% request sr-te cisco-sr-te-cfp-sr-odn:odn odn-template SR-ODN action get-modifications device P-0 outformat cli message devices { device P-0 { config { segment-routing-ms-cfg:sr { traffic-engineering { on-demand-colors { + on-demand-color 300 { + on-demand-color-dyn-mpls { + on-demand-color-dyn-mpls-metric { + metric-type igp; + enable; + } + on-demand-color-dyn-mpls-pce { + enable; + } + disjoint-path { + group-id 10; + disjointness-type node; + sub-id 5; + } + on-demand-color-dyn-mpls-flex-algorithm 200; + enable; + affinity-rules { + affinity-rule affinity-exclude-any { + affinity-name BLUE; + } + } + } + bandwidth 200; + maximum-sid-depth 6; + enable; + } } } } } } }



7.3.2 SR-Policy

get-modifications action for service admin@ncs% request sr-te cisco-sr-te-cfp-sr-policies:policies policy SR-CLI-DYNAMIC action get-modifications outformat cli devices { device PIOSXR-0 { config { cisco-ios-xr:segment-routing { traffic-eng { + segment-list mysidlist { + index 1 { + mpls { + label 17001; + } + } + index 2 { + mpls { + label 18001; + } + } + } policy SR-CLI-DYNAMIC { color { end-point { - ipv4 127.0.0.1; + ipv4 1.1.1.1; } } candidate-paths { + preference 200 { + explicit { + segment-list mysidlist { + weight 10; + } + } + } } } } } } } }

7.3.3 SR-Settings


get-modifications action for a service admin@ncs% request sr-setting SETTING-1 action get-modifications outformat cli message devices { device PIOSXR-0 { config { + cisco-ios-xr:segment-routing {



+ traffic-eng { + interface GigabitEthernet5 { + affinity { + color GREEN; + } + metric 2; + } + maximum-sid-depth 100; + affinity-map { + color BLUE { + prefix name; + bit-position 1; + } + color GREEN { + prefix name; + bit-position 2; + } + color RED { + prefix name; + bit-position 0; + } + } + pcc { + source-address { + ipv4 192.168.2.1; + } + pce { + address { + ipv4 1.1.1.1 { + precedence 128; + } + ipv4 2.2.2.2 { + precedence 255; + } + } + } + } + } + } } } } devices { device PIOSXR-1 { config { + cisco-ios-xr:segment-routing { + traffic-eng { + interface GigabitEthernet7 { + affinity { + color BLUE; + } + metric 2; + } + maximum-sid-depth 100; + affinity-map { + color BLUE { + prefix name; + bit-position 1; + } + color GREEN { + prefix name;



+ bit-position 2; + } + color RED { + prefix name; + bit-position 0; + } + } + } + } } } }

get-modifications action for a device admin@ncs% request sr-setting SETTING-1 action get-modifications device PIOSXR-0 outformat cli message devices { device PIOSXR-0 { config { + cisco-ios-xr:segment-routing { + traffic-eng { + interface GigabitEthernet5 { + affinity { + color GREEN; + } + metric 2; + } + maximum-sid-depth 100; + affinity-map { + color BLUE { + prefix name; + bit-position 1; + } + color GREEN { + prefix name; + bit-position 2; + } + color RED { + prefix name; + bit-position 0; + } + } + pcc { + source-address { + ipv4 192.168.2.1; + } + pce { + address { + ipv4 1.1.1.1 { + precedence 128; + } + ipv4 2.2.2.2 { + precedence 255; + } + } + } + } + } + } } } }



7.3.4 SR-PCE


get-modifications action for a service admin@ncs% request sr-pce PCE-0 action get-modifications outformat cli message devices { device PIOSXR-0 { config { + cisco-ios-xr:pce { + address { + ipv4 100.1.1.1; + } + disjoint-path { + group-id 60000 srlg { + sub-id 1; + strict; + lsp 1 { + pcc { + ipv4 2.2.2.2; + } + lsp-name LSP-NAME; + shortest-path; + } + } + } + timers { + reoptimization 600; + keepalive 20; + minimum-peer-keepalive 21; + } + state-sync { + ipv4 3.3.3.3; + } + password { + type clear; + secret password123; + } + backoff { + ratio 11; + difference 10; + threshold 12; + } + segment-routing { + strict-sid-only; + te-latency; + } + } } } }



Get-modifications action for a device admin@ncs% request sr-pce PCE-0 action get-modifications device PIOSXR-0 outformat cli message devices { device PIOSXR-0 { config { + cisco-ios-xr:pce { + address { + ipv4 100.1.1.1; + } + disjoint-path { + group-id 60000 srlg { + sub-id 1; + strict; + lsp 1 { + pcc { + ipv4 2.2.2.2; + } + lsp-name LSP-NAME; + shortest-path; + } + } + } + timers { + reoptimization 600; + keepalive 20; + minimum-peer-keepalive 21; + } + state-sync { + ipv4 3.3.3.3; + } + password { + type clear; + secret password123; + } + backoff { + ratio 11; + difference 10; + threshold 12; + } + segment-routing { + strict-sid-only; + te-latency; + } + } } } }




In L2VPN, perform the get-modifications action at the service/site level.

get-modifications action for a service admin@ncs% request flat-L2vpn P2P-DOT1Q action get-modifications outformat cli message devices { device PIOSXR-0 { config { cisco-ios-xr:interface { + HundredGigE 0/0/0/8 { + description "T-SDN Interface"; + } HundredGigE-subinterface { + HundredGigE 0/0/0/8.100 { + mode l2transport; + description "T-SDN Interface"; + encapsulation { + dot1q { + vlan-id 100; + } + } + rewrite { + ingress { + tag { + translate 1-to-1; + dot1q 123; + mode symmetric; + } + } + } + } } } + cisco-ios-xr:l2vpn { + pw-class P2P-DOT1Q { + encapsulation { + mpls { + } + } + } + xconnect { + group P2P-DOT1Q { + p2p P2P-DOT1Q { + interface HundredGigE0/0/0/8.100; + neighbor 14.0.0.0 100 { + ip-version ipv4; + mpls { + static { + label { + local 101; + remote 202; + } + } + } + pw-class P2P-DOT1Q; + } + } + }



+ } + } } } } devices { device PIOSXR-1 { config { cisco-ios-xr:interface { + HundredGigE 0/0/0/8 { + description "T-SDN Interface"; + } HundredGigE-subinterface { + HundredGigE 0/0/0/8.100 { + mode l2transport; + description "T-SDN Interface"; + encapsulation { + dot1q { + vlan-id 100; + } + } + rewrite { + ingress { + tag { + translate 1-to-1; + dot1q 123; + mode symmetric; + } + } + } + } } } + cisco-ios-xr:l2vpn { + pw-class P2P-DOT1Q { + encapsulation { + mpls { + } + } + } + xconnect { + group P2P-DOT1Q { + p2p P2P-DOT1Q { + interface HundredGigE0/0/0/8.100; + neighbor 12.0.0.0 100 { + ip-version ipv4; + mpls { + static { + label { + local 202; + remote 101; + } + } + } + pw-class P2P-DOT1Q; + } + } + } + } + } } } }



get-modifications action for a remote-site admin@ncs% request flat-L2vpn P2P-DOT1Q action get-modifications outformat cli site-type remote message devices { device PIOSXR-1 { config { cisco-ios-xr:interface { + HundredGigE 0/0/0/8 { + description "T-SDN Interface"; + } HundredGigE-subinterface { + HundredGigE 0/0/0/8.100 { + mode l2transport; + description "T-SDN Interface"; + encapsulation { + dot1q { + vlan-id 100; + } + } + rewrite { + ingress { + tag { + translate 1-to-1; + dot1q 123; + mode symmetric; + } + } + } + } } } + cisco-ios-xr:l2vpn { + pw-class P2P-DOT1Q { + encapsulation { + mpls { + } + } + } + xconnect { + group P2P-DOT1Q { + p2p P2P-DOT1Q { + interface HundredGigE0/0/0/8.100; + neighbor 12.0.0.0 100 { + ip-version ipv4; + mpls { + static { + label { + local 202; + remote 101; + } + } + } + pw-class P2P-DOT1Q; + } + } + } + } + } } } }



get-modifications action for a local-site admin@ncs% request flat-L2vpn P2P-DOT1Q action get-modifications outformat cli site-type local message devices { device PIOSXR-0 { config { cisco-ios-xr:interface { + HundredGigE 0/0/0/8 { + description "T-SDN Interface"; + } HundredGigE-subinterface { + HundredGigE 0/0/0/8.100 { + mode l2transport; + description "T-SDN Interface"; + encapsulation { + dot1q { + vlan-id 100; + } + } + rewrite { + ingress { + tag { + translate 1-to-1; + dot1q 123; + mode symmetric; + } + } + } + } } } + cisco-ios-xr:l2vpn { + pw-class P2P-DOT1Q { + encapsulation { + mpls { + } + } + } + xconnect { + group P2P-DOT1Q { + p2p P2P-DOT1Q { + interface HundredGigE0/0/0/8.100; + neighbor 14.0.0.0 100 { + ip-version ipv4; + mpls { + static { + label { + local 101; + remote 202; + } + } + } + pw-class P2P-DOT1Q; + } + } + } + } + } } } }




In L3VPN, perform the get-modifications action at the service level or at the endpoint level.

get-modifications action for a service admin@ncs% request flat-L3vpn L3 action get-modifications outformat cli message devices { device P-0 { config { ifmgr-cfg:interface-configurations { + interface-configuration act Loopback3 { + interface-virtual; + vrf L3VPN; + ipv4-network { + addresses { + primary { + address 169.1.1.1; + netmask 255.255.255.255; + } + } + } + } } infra-rsi-cfg:vrfs { + vrf L3VPN { + create; + afs { + af ipv4 unicast default { + create; + bgp { + import-route-targets { + route-targets { + route-target as { + as-or-four-byte-as 0 100 102 0; + as-or-four-byte-as 0 200 100 0; + } + } + } + export-route-targets { + route-targets { + route-target as { + as-or-four-byte-as 0 100 101 0; + as-or-four-byte-as 0 200 100 0; + } + } + } + } + } + } + } } ipv4-bgp-cfg:bgp { + instance default {



+ instance-as 0 { + four-byte-as 65001 { + vrfs { + vrf L3VPN { + vrf-global { + route-distinguisher { + type as; + as-xx 0; + as 1; + as-index 2; + } + vrf-global-afs { + vrf-global-af ipv4-unicast { + enable; + } + } + exists; + } + vrf-neighbors { + vrf-neighbor 169.1.1.2 { + vrf-neighbor-afs { + vrf-neighbor-af ipv4-unicast { + activate; + route-policy-in PASS_ALL; + route-policy-out PASS_ALL; + } + } + remote-as { + as-xx 0; + as-yy 65002; + } + } + } + } + } + bgp-running; + } + } + } } policy-repository-cfg:routing-policy { route-policies { + route-policy PASS_ALL { + rpl-route-policy "route-policy PASS_ALL\n pass\n end-policy\n "; + } } } } } } devices { device P-1 { config { ifmgr-cfg:interface-configurations { + interface-configuration act Loopback3 { + interface-virtual;



+ vrf L3VPN; + ipv4-network { + addresses { + primary { + address 169.1.1.1; + netmask 255.255.255.255; + } + } + } + } } infra-rsi-cfg:vrfs { + vrf L3VPN { + create; + afs { + af ipv4 unicast default { + create; + bgp { + import-route-targets { + route-targets { + route-target as { + as-or-four-byte-as 0 100 102 0; + as-or-four-byte-as 0 200 100 0; + } + } + } + export-route-targets { + route-targets { + route-target as { + as-or-four-byte-as 0 100 101 0; + as-or-four-byte-as 0 200 100 0; + } + } + } + } + } + } + } } ipv4-bgp-cfg:bgp { + instance default { + instance-as 0 { + four-byte-as 65001 { + vrfs { + vrf L3VPN { + vrf-global { + route-distinguisher { + type as; + as-xx 0; + as 1; + as-index 2; + } + vrf-global-afs { + vrf-global-af ipv4-unicast { + enable; + }



+ } + exists; + } + vrf-neighbors { + vrf-neighbor 169.1.1.2 { + vrf-neighbor-afs { + vrf-neighbor-af ipv4-unicast { + activate; + route-policy-in PASS_ALL; + route-policy-out PASS_ALL; + } + } + remote-as { + as-xx 0; + as-yy 65002; + } + } + } + } + } + bgp-running; + } + } + } } policy-repository-cfg:routing-policy { route-policies { + route-policy PASS_ALL { + rpl-route-policy "route-policy PASS_ALL\n pass\n end-policy\n "; + } } } } } }

get-modifications action for an endpoint admin@ncs% request flat-L3vpn L3 action get-modifications endpoint nc-0 outformat cli message devices { device P-0 { config { ifmgr-cfg:interface-configurations { + interface-configuration act Loopback3 { + interface-virtual; + vrf L3VPN; + ipv4-network { + addresses { + primary { + address 169.1.1.1; + netmask 255.255.255.255; + } + } + } + }



} infra-rsi-cfg:vrfs { + vrf L3VPN { + create; + afs { + af ipv4 unicast default { + create; + bgp { + import-route-targets { + route-targets { + route-target as { + as-or-four-byte-as 0 100 102 0; + as-or-four-byte-as 0 200 100 0; + } + } + } + export-route-targets { + route-targets { + route-target as { + as-or-four-byte-as 0 100 101 0; + as-or-four-byte-as 0 200 100 0; + } + } + } + } + } + } + } } ipv4-bgp-cfg:bgp { + instance default { + instance-as 0 { + four-byte-as 65001 { + vrfs { + vrf L3VPN { + vrf-global { + route-distinguisher { + type as; + as-xx 0; + as 1; + as-index 2; + } + vrf-global-afs { + vrf-global-af ipv4-unicast { + enable; + } + } + exists; + } + vrf-neighbors { + vrf-neighbor 169.1.1.2 { + vrf-neighbor-afs { + vrf-neighbor-af ipv4-unicast { + activate;



+ route-policy-in PASS_ALL; + route-policy-out PASS_ALL; + } + } + remote-as { + as-xx 0; + as-yy 65002; + } + } + } + } + } + bgp-running; + } + } + } } policy-repository-cfg:routing-policy { route-policies { + route-policy PASS_ALL { + rpl-route-policy "route-policy PASS_ALL\n pass\n end-policy\n "; + } } } } } }

get-modifications action per device admin@ncs% request flat-L3vpn L3 action get-modifications endpoint nc-0 outformat cli message devices { device P-0 { config { ifmgr-cfg:interface-configurations { + interface-configuration act Loopback3 { + interface-virtual; + vrf L3VPN; + ipv4-network { + addresses { + primary { + address 169.1.1.1; + netmask 255.255.255.255; + } + } + } + } } infra-rsi-cfg:vrfs { + vrf L3VPN { + create; + afs { + af ipv4 unicast default { + create; + bgp { + import-route-targets {



+ route-targets { + route-target as { + as-or-four-byte-as 0 100 102 0; + as-or-four-byte-as 0 200 100 0; + } + } + } + export-route-targets { + route-targets { + route-target as { + as-or-four-byte-as 0 100 101 0; + as-or-four-byte-as 0 200 100 0; + } + } + } + } + } + } + } } ipv4-bgp-cfg:bgp { + instance default { + instance-as 0 { + four-byte-as 65001 { + vrfs { + vrf L3VPN { + vrf-global { + route-distinguisher { + type as; + as-xx 0; + as 1; + as-index 2; + } + vrf-global-afs { + vrf-global-af ipv4-unicast { + enable; + } + } + exists; + } + vrf-neighbors { + vrf-neighbor 169.1.1.2 { + vrf-neighbor-afs { + vrf-neighbor-af ipv4-unicast { + activate; + route-policy-in PASS_ALL; + route-policy-out PASS_ALL; + } + } + remote-as { + as-xx 0; + as-yy 65002; + } + } + }



+ } + } + bgp-running; + } + } + } } policy-repository-cfg:routing-policy { route-policies { + route-policy PASS_ALL { + rpl-route-policy "route-policy PASS_ALL\n pass\n end-policy\n "; + } } } } } }

7.4 Service Redeploy Action

Use the service redeploy action to re-run the service when a device comes back up after going down during the inital service creation. Use this action to enable redeploying a service, a device, a site, or an endpoint.

Redeploying a service redeploys all the devices/sites/endpoints in the service. Redeploying a device/site/endpoint redeploys the service only on the requested device/site/endpoint.

When the device is not-reachable and the plan fails, run the redeploy action for a specific device to push the configuration again when the device is up.

7.4.1 SR-ODN

Redeploying a service redeploys all the devices in the service. Redeploying a device redeploys the service only on the requested device. When the device is not-reachable and the plan fails, run the redeploy action for a specific device to push the configuration again when the device is up.

Redeploying at service level

The following command shows how to redeploy a service.

admin@ncs% request sr-te cisco-sr-te-cfp-sr-odn:odn odn-template SR-ODN action redeploy

status SUCCESS

message Service Redeployed.

View the plan and observe the timestamp to verify the service redeployment. admin@ncs% run show sr-te cisco-sr-te-cfp-sr-odn:odn odn-template-plan



POST BACK STATUS ACTION TYPE NAME TRACK GOAL CODE STATE STATUS WHEN ref STATUS ------------------------------------------------------------------------------------------ self self false - - init reached 2020-04-22T21:26:01 - - ready reached 2020-04-22T21:33:38 - - cisco-sr-te-cfp-sr-odn-nano-plan-services:head-end P-0 false - - init reached 2020-04-22T21:26:01 - - cisco-sr-te-cfp-sr-odn-nano-plan-services:config-apply reached 2020-04-22T21:33:38 - - ready reached 2020-04-22T21:33:38 - - cisco-sr-te-cfp-sr-odn-nano-plan-services:head-end PIOSXR-0 false - - init reached 2020-04-22T21:26:01 - - cisco-sr-te-cfp-sr-odn-nano-plan-services:config-apply reached 2020-04-22T21:33:38 - - ready reached 2020-04-22T21:33:38 - -

Redeploying service for a given device

The following command redeploys a device in a service.

admin@ncs% request sr-te cisco-sr-te-cfp-sr-odn:odn odn-template SR-ODN head-end P-0 action redeploy

status SUCCESS

message Service Redeployed.

View the plan and observe the timestamp to verify the device redeployment.

admin@ncs% run show sr-te cisco-sr-te-cfp-sr-odn:odn odn-template-plan POST BACK STATUS ACTION TYPE NAME TRACK GOAL CODE STATE STATUS WHEN ref STATUS ------------------------------------------------------------------------------------------ self self false - - init reached 2020-04-22T21:26:01 - - ready reached 2020-04-22T21:34:46 - - cisco-sr-te-cfp-sr-odn-nano-plan-services:head-end P-0 false - - init reached 2020-04-22T21:26:01 - - cisco-sr-te-cfp-sr-odn-nano-plan-services:config-apply reached 2020-04-22T21:34:46 - - ready reached 2020-04-22T21:34:46 - - cisco-sr-te-cfp-sr-odn-nano-plan-services:head-end PIOSXR-0 false - - init reached 2020-04-22T21:26:01 - - cisco-sr-te-cfp-sr-odn-nano-plan-services:config-apply reached 2020-04-22T21:33:38 - - ready reached 2020-04-22T21:33:38 - -

7.4.2 SR-Policy


The following command shows how to redeploy a service. admin@ncs% request sr-te cisco-sr-te-cfp-sr-policies:policies policy SR-CLI-DYNAMIC action redeploy status SUCCESS message Service Redeployed.



View the plan and observe the timestamp to verify the service redeployment. admin@ncs% run show sr-te cisco-sr-te-cfp-sr-policies:policies policy-plan POST BACK ACTION TYPE NAME TRACK GOAL STATE STATUS WHEN ref STATUS ---------------------------------------------------------------------- self self false - init reached 2020-02-11T22:30:16 - - ready reached 2020-02-11T22:31:52 - - head-end PIOSXR-0 false - init reached 2020-02-11T22:30:16 - - cisco-sr-te-cfp-sr-policies-nano-plan-services:config-apply reached 2020-02-11T22:31:22 - - ready reached 2020-02-11T22:31:52 - -

7.4.3 SR-Settings


The following command shows how to redeploy a service. admin@ncs% request sr-setting SETTING-1 action redeploy status SUCCESS message Service Redeployed. View the plan and observe the timestamp to verify the service redeployment. admin@ncs% run show sr-setting-plan POST BACK STATUS ACTION TYPE NAME TRACK GOAL CODE STATE STATUS WHEN ref STATUS ---------------------------------------------------------------------- self self false - - init reached 2020-04-22T22:41:07 - - ready reached 2020-04-22T22:47:10 - - cisco-sr-te-settings-fp-nano-plan-services:node PIOSXR-0 false - - init reached 2020-04-22T22:41:07 - - cisco-sr-te-settings-fp-nano-plan-services:config-apply reached 2020-04-22T22:47:10 - - ready reached 2020-04-22T22:47:10 - - cisco-sr-te-settings-fp-nano-plan-services:node PIOSXR-1 false - - init reached 2020-04-22T22:41:07 - - cisco-sr-te-settings-fp-nano-plan-services:config-apply reached 2020-04-22T22:47:10 - - ready reached 2020-04-22T22:47:10 - -


The following command redeploys a device in a service. admin@ncs% request sr-setting SETTING-1 node PIOSXR-0 action redeploy status SUCCESS message Service Redeployed.

View the plan and observe the timestamp to verify the device redeployment.



admin@ncs% run show sr-setting-plan POST BACK STATUS ACTION TYPE NAME TRACK GOAL CODE STATE STATUS WHEN ref STATUS ---------------------------------------------------------------------- self self false - - init reached 2020-04-22T22:41:07 - - ready reached 2020-04-22T22:48:25 - - cisco-sr-te-settings-fp-nano-plan-services:node PIOSXR-0 false - - init reached 2020-04-22T22:41:07 - - cisco-sr-te-settings-fp-nano-plan-services:config-apply reached 2020-04-22T22:48:25 - - ready reached 2020-04-22T22:48:25 - - cisco-sr-te-settings-fp-nano-plan-services:node PIOSXR-1 false - - init reached 2020-04-22T22:41:07 - - cisco-sr-te-settings-fp-nano-plan-services:config-apply reached 2020-04-22T22:47:10 - - ready reached 2020-04-22T22:47:10 - -

7.4.4 SR-PCE


The following command shows how to redeploy a service. admin@ncs% request sr-pce PCE-0 action redeploy status SUCCESS message Service Redeployed. View the plan and observe the timestamp to verify the service redeployment. admin@ncs% run show sr-pce-plan PCE-0 plan component POST BACK STATUS ACTION TYPE NAME TRACK GOAL CODE STATE STATUS WHEN ref STATUS ---------------------------------------------------------------------- self self false - - init reached 2020-04-22T17:50:05 - - ready reached 2020-04-22T17:59:46 - - cisco-sr-te-pce-fp-nano-plan-services:node PIOSXR-0 false - - init reached 2020-04-22T17:50:05 - - cisco-sr-te-pce-fp-nano-plan-services:config-apply reached 2020-04-22T17:59:46 - - ready reached 2020-04-22T17:59:46 - -


The following command redeploys a device in a service. admin@ncs% request sr-pce PCE-0 node PIOSXR-0 action redeploy status SUCCESS message Service Redeployed.

View the plan and observe the timestamp to verify the device redeployment. admin@ncs% run show sr-pce-plan PCE-0 plan component POST



BACK STATUS ACTION TYPE NAME TRACK GOAL CODE STATE STATUS WHEN ref STATUS ---------------------------------------------------------------------- self self false - - init reached 2020-04-22T17:50:05 - - ready reached 2020-04-22T18:04:02 - - cisco-sr-te-pce-fp-nano-plan-services:node PIOSXR-0 false - - init reached 2020-04-22T17:50:05 - - cisco-sr-te-pce-fp-nano-plan-services:config-apply reached 2020-04-22T18:04:02 - - ready reached 2020-04-22T18:04:02 - -


In L2VPN, the service redeploy action enables service/site redeployment. The following custom actions enable service / site redeployment.

Redeploying services redeploys all the sites in the service.

Redeploying sites redeploys only the requested sites in the service. When the site is not-reachable and the plan fails, run the redeploy action to push the configuration again when the site is Up.


The following command shows how to redeploy a service on all the sites. admin@ncs% request flat-L2vpn L2vpn01 action redeploy status SUCCESS message Service Redeployed.

View the plan to verify the service redeployment. admin@ncs% run show flat-L2vpn-plan BACK POST ACTION TYPE NAME TRACK GOAL STATE STATUS WHEN ref STATUS ------------------------------------------------------------------------------------------ self self false - init reached 2020-02-11T22:10:06 - - ready reached 2020-02-11T22:12:43 - - local-site PIOSXR-0 false - init reached 2020-02-11T22:10:06 - - cisco-flat-L2vpn-fp-nano-plan-services:config-apply reached 2020-02-11T22:12:11 - - ready reached 2020-02-11T22:12:11 - - remote-site PIOSXR-1 false - init reached 2020-02-11T22:10:06 - - cisco-flat-L2vpn-fp-nano-plan-services:config-apply reached 2020-02-11T22:12:11 - - ready reached 2020-02-11T22:12:11 - -



To redeploy a local site/remote site: admin@ncs% request flat-L2vpn L2vpn01 flat-L2vpn-p2p local-site action redeploy status SUCCESS message Service Redeployed. admin@ncs% request flat-L2vpn L2vpn01 flat-L2vpn-p2p remote-site action redeploy status SUCCESS message Service Redeployed.

View the plan to verify the site redeployment. The following displays a plan for a local-site redeployment. admin@ncs% run show flat-L2vpn-plan BACK

POST ACTION TYPE NAME TRACK GOAL STATE STATUS WHEN ref STATUS ------------------------------------------------------------------------------------------ self self false - init reached 2020-02-11T22:10:06 - - ready reached 2020-02-11T22:20:01 - - local-site PIOSXR-0 false - init reached 2020-02-11T22:10:06 - - cisco-flat-L2vpn-fp-nano-plan-services:config-apply reached 2020-02-11T22:19:29 - - ready reached 2020-02-11T22:19:29 - - remote-site PIOSXR-1 false - init reached 2020-02-11T22:10:06 - - cisco-flat-L2vpn-fp-nano-plan-services:config-apply reached 2020-02-11T22:12:11 - - ready reached 2020-02-11T22:12:11 - -


In L3VPN, the service redeploy action enables service/endpoint redeployment. Redeploying services redeploys or reconfigures all the endpoints in the service. Redeploying endpoints redeploys only the requested endpoints in the service. When the service is not-reachable and the plan fails, run the redeploy action to push the configuration again when the service is up.


The following command shows how to redeploy a requested service. admin@ncs% request flat-L3vpn L3 action redeploy status SUCCESS message Service Redeployed.

View the plan to verify the endpoint redeployment. The following displays a plan for an endpoint redeployment.



admin@ncs% run show flat-L3vpn-plan BACK POST ACTION TYPE NAME TRACK GOAL STATE STATUS WHEN ref STATUS ------------------------------------------------------------------------------------------ self self false - init reached 2020-02-20T02:40:26 - - ready reached 2020-02-20T02:45:14 - - endpoint nc-0 false - init reached 2020-02-20T02:40:26 - - cisco-flat-L3vpn-fp-nano-plan-services:config-apply reached 2020-02-20T02:45:13 - - ready reached 2020-02-20T02:45:13 - - endpoint nc-1 false - init reached 2020-02-20T02:40:26 - - cisco-flat-L3vpn-fp-nano-plan-services:config-apply reached 2020-02-20T02:40:28 - - ready reached 2020-02-20T02:40:28 - -

Redeploying service for a given endpoint

The following command shows how to redeploy an endpoint in a service. admin@ncs% request flat-L3vpn L3 endpoint nc-0 action redeploy status SUCCESS message Service Redeployed.

View the plan to verify the service redeployment. admin@ncs% run show flat-L3vpn-plan

BACK

POST ACTION

TYPE NAME TRACK GOAL STATE

STATUS WHEN ref STATUS

------------------------------------------------------------------------------------------ self self false - init reached 2020-02-21T00:36:11 - - ready reached 2020-02-21T02:18:25 - - endpoint nc-0 false - init reached 2020-02-21T00:36:11 - - cisco-flat-L3vpn-fp-nano-plan-services:config-apply reached 2020-02-21T02:18:23 - - ready reached 2020-02-21T02:18:23 - - endpoint nc-1 false - init reached 2020-02-21T00:36:11 - - cisco-flat-L3vpn-fp-nano-plan-services:config-apply reached 2020-02-21T02:17:55 - - ready reached 2020-02-21T02:17:55 - -

Using Custom-Templates


8 Using Custom-Templates You can configure the devices directly by using custom-templates. With custom-templates, you can also apply additional configurations that are not supported by SR-TE CFP.

To use this feature, the apply-custom-template flag must be set to true. By default, this flag is set to true. The plan for the service displays the status of the custom-templates.

You can also turn this feature on/off. For more information on turning this flag on/off, see section Turning Custom-Templates On/Off in this chapter.

While installing the CFP packages, the installer extracts and saves the custom-templates-utils package in the /var/opt/ncs/packages directory.

If the custom-templates-utils package is not saved in the /var/opt/ncs/packages directory, do the following:

1. Download the ncs-5.2.1-custom-template-utils-1.2.0-e5f4603.tar.gz file from Cisco website.

2. Copy the file to the /var/opt/ncs/packages directory and extract the file.

3. Load the custom-templates packages to ncs in any of the following ways as required.

a. If ncs is stopped, start ncs with the package reload option. b. If ncs is running, execute request packages reload in ncs_cli.

Custom-templates must adhere to a naming convention. The custom-templates name must start with either ct- or CT-. The device name variable in configuration templates must be either DEVICE_NAME or DEVICE. These variable names are reserved only for the device name in templates and hence must not be used for anything else in a template.

For sample custom-templates for each service, see section Custom-Template Payloads in this documentation.

8.1 Turning Custom-Templates On/Off

You can turn the custom-templates feature on/off at any time and custom redeploy the service for the change to take effect.

To turn off the custom-template feature:

Set the apply-custom-template flag to false to turn off the custom-template feature. The default value is true. admin@ncs% set apply-custom-template false commit

Supporting Multi-Vendor Services


9 Supporting Multi-Vendor Services SR-TE CFP is an extendable CFP, which allows you to write your own extension package and hook it to the CFP. This allows you to map the CFP service models to device configurations for the NED packages and/or the device versions not supported by CFP. This concept of Multi-Vendor Support Services (MVSS) thus allows you to provide services to the devices or NED packages you already have.

For more information, contact your Cisco representative.

Deleting Services


10 Deleting Services You may want to delete a service when the devices in the service are down or when there is policy discrepancies. Use the following commands to delete the services.

SR-ODN delete sr-te cisco-sr-te-cfp-sr-odn:odn odn-template <service-name>

SR-Policy

delete sr-te cisco-sr-te-cfp-sr-policies:policies policy <service-name>

SR-Settings

delete sr-setting <service-name>

SR-PCE

delete sr-pce <service-name>

L2VPN

delete flat-L2vpn <service-name>

L3VPN

delete flat-L3vpn <service-name>

Notifications


11 Notifications SR-TE CFP generates the following notifications that communicate important information about the various events. Use this information to modify and examine the payload content for a specific event.

11.1 SR-ODN Notifications

This topic includes the create and delete notifications for the SR-ODN service.

Create Notification notification { eventTime 2020-04-24T17:26:51.198717+00:00 plan-state-change { service /sr-te/cisco-sr-te-cfp-sr-odn:odn/odn-template[name='SR-ODN'] component PIOSXR-0 state cisco-sr-te-cfp-sr-odn-nano-plan-services:config-apply operation created status not-reached } } notification { eventTime 2020-04-24T17:26:51.198761+00:00 plan-state-change { service /sr-te/cisco-sr-te-cfp-sr-odn:odn/odn-template[name='SR-ODN'] component PIOSXR-0 state ready operation created status not-reached } } notification { eventTime 2020-04-24T17:26:54.428729+00:00 plan-state-change { service /sr-te/cisco-sr-te-cfp-sr-odn:odn/odn-template[name='SR-ODN'] component self state ready operation modified status reached } } notification { eventTime 2020-04-24T17:26:54.428848+00:00 plan-state-change { service /sr-te/cisco-sr-te-cfp-sr-odn:odn/odn-template[name='SR-ODN'] component P-0 state cisco-sr-te-cfp-sr-odn-nano-plan-services:config-apply operation modified status reached } }

Notifications


notification { eventTime 2020-04-24T17:26:54.428909+00:00 plan-state-change { service /sr-te/cisco-sr-te-cfp-sr-odn:odn/odn-template[name='SR-ODN'] component P-0 state ready operation modified status reached } } notification { eventTime 2020-04-24T17:26:54.429021+00:00 plan-state-change { service /sr-te/cisco-sr-te-cfp-sr-odn:odn/odn-template[name='SR-ODN'] component PIOSXR-0 state cisco-sr-te-cfp-sr-odn-nano-plan-services:config-apply operation modified status reached } } notification { eventTime 2020-04-24T17:26:54.429094+00:00 plan-state-change { service /sr-te/cisco-sr-te-cfp-sr-odn:odn/odn-template[name='SR-ODN'] component PIOSXR-0 state ready operation modified status reached } }

Delete Notifications notification { eventTime 2020-04-24T17:27:58.800174+00:00 plan-state-change { service /sr-te/cisco-sr-te-cfp-sr-odn:odn/odn-template[name='SR-ODN'] operation deleted } }

The following notification displays if the delete operation fails. notification { eventTime 2020-04-24T17:28:47.18566+00:00 plan-state-change { service /sr-te/cisco-sr-te-cfp-sr-odn:odn/odn-template[name='SR-ODN'] operation deleted status failed } }

Notifications


11.2 SR-Policies Notifications

This topic includes the create and delete notifications for SR-policies.

11.2.1 SR-TE Policy with Static Explicit Route Object

Create Notification notification { eventTime 2020-04-26T20:25:10.00268+00:00 plan-state-change { service /sr-te/cisco-sr-te-cfp-sr-policies:policies/policy[name='SR-CLI-DYNAMIC'] component self state ready operation created status not-reached } } notification { eventTime 2020-04-26T20:25:10.002815+00:00 plan-state-change { service /sr-te/cisco-sr-te-cfp-sr-policies:policies/policy[name='SR-CLI-DYNAMIC'] component PIOSXR-0 state init operation created status reached } } notification { eventTime 2020-04-26T20:25:10.00292+00:00 plan-state-change { service /sr-te/cisco-sr-te-cfp-sr-policies:policies/policy[name='SR-CLI-DYNAMIC'] component PIOSXR-0 state cisco-sr-te-cfp-sr-policies-nano-plan-services:config-apply operation created status not-reached } } notification { eventTime 2020-04-26T20:25:10.002985+00:00 plan-state-change { service /sr-te/cisco-sr-te-cfp-sr-policies:policies/policy[name='SR-CLI-DYNAMIC'] component PIOSXR-0 state ready operation created status not-reached } } notification { eventTime 2020-04-26T20:25:12.262296+00:00 plan-state-change { service /sr-te/cisco-sr-te-cfp-sr-policies:policies/policy[name='SR-CLI-DYNAMIC'] component self

Notifications


state ready operation modified status reached } } notification { eventTime 2020-04-26T20:25:12.262427+00:00 plan-state-change { service /sr-te/cisco-sr-te-cfp-sr-policies:policies/policy[name='SR-CLI-DYNAMIC'] component PIOSXR-0 state cisco-sr-te-cfp-sr-policies-nano-plan-services:config-apply operation modified status reached } } notification { eventTime 2020-04-26T20:25:12.262501+00:00 plan-state-change { service /sr-te/cisco-sr-te-cfp-sr-policies:policies/policy[name='SR-CLI-DYNAMIC'] component PIOSXR-0 state ready operation modified status reached } }

Delete Notifications notification { eventTime 2020-04-26T13:27:18.478531+00:00 plan-state-change { service /sr-te/cisco-sr-te-cfp-sr-policies:policies/policy[name='SR-CLI-DYNAMIC'] operation deleted } }

The following notification displays if the delete operation fails. notification { eventTime 2020-04-26T13:28:04.550181+00:00 plan-state-change { service /sr-te/cisco-sr-te-cfp-sr-policies:policies/policy[name='SR-CLI-DYNAMIC'] operation deleted status failed } }

Notifications


11.3 SR-Settings Notifications

This topic includes the create and delete notifications for SR-Settings and SR-Flex Algo.

11.3.1 SR-Settings Notifications

Create Notification

notification { eventTime 2020-04-24T22:23:49.485567+00:00 plan-state-change { service /cisco-sr-te-settings-fp:sr-setting[name='SETTING-1'] component P-1 state ready operation created status not-reached } } notification { eventTime 2020-04-24T22:23:49.485695+00:00 plan-state-change { service /cisco-sr-te-settings-fp:sr-setting[name='SETTING-1'] component PIOSXR-0 state init operation created status reached } } notification { eventTime 2020-04-24T22:23:49.485746+00:00 plan-state-change { service /cisco-sr-te-settings-fp:sr-setting[name='SETTING-1'] component PIOSXR-0 state cisco-sr-te-settings-fp-nano-plan-services:config-apply operation created status not-reached } } notification { eventTime 2020-04-24T22:23:49.48579+00:00 plan-state-change { service /cisco-sr-te-settings-fp:sr-setting[name='SETTING-1'] component PIOSXR-0 state ready operation created status not-reached } } notification { eventTime 2020-04-24T22:23:49.485919+00:00 plan-state-change { service /cisco-sr-te-settings-fp:sr-setting[name='SETTING-1'] component PIOSXR-1 state init operation created status reached }

Notifications


} notification { eventTime 2020-04-24T22:23:49.485967+00:00 plan-state-change { service /cisco-sr-te-settings-fp:sr-setting[name='SETTING-1'] component PIOSXR-1 state cisco-sr-te-settings-fp-nano-plan-services:config-apply operation created status not-reached } } notification { eventTime 2020-04-24T22:23:49.486011+00:00 plan-state-change { service /cisco-sr-te-settings-fp:sr-setting[name='SETTING-1'] component PIOSXR-1 state ready operation created status not-reached } }

Delete Notifications notification { eventTime 2020-04-24T15:24:31.965713+00:00 plan-state-change { service /cisco-sr-te-settings-fp:sr-setting[name='SETTING-1'] operation deleted } }

The following notification displays if the delete operation fails.

notification { eventTime 2020-04-24T15:29:06.636872+00:00 plan-state-change { service /cisco-sr-te-settings-fp:sr-setting[name='SETTING-1'] operation deleted status failed } }

Notifications


11.3.2 SR Flex Algo Notifications

This topic includes notifications for SR Flex Algo create and delete operations.

Create Notification notification { eventTime 2020-04-24T20:57:47.97983+00:00 plan-state-change { service /cisco-sr-te-settings-fp:sr-setting[name='ALGO-1'] component self state ready operation created status not-reached } } notification { eventTime 2020-04-24T20:57:47.979971+00:00 plan-state-change { service /cisco-sr-te-settings-fp:sr-setting[name='ALGO-1'] component PIOSXR-0 state init operation created status reached } } notification { eventTime 2020-04-24T20:57:47.980017+00:00 plan-state-change { service /cisco-sr-te-settings-fp:sr-setting[name='ALGO-1'] component PIOSXR-0 state cisco-sr-te-settings-fp-nano-plan-services:config-apply operation created status not-reached } } notification { eventTime 2020-04-24T20:57:47.98006+00:00 plan-state-change { service /cisco-sr-te-settings-fp:sr-setting[name='ALGO-1'] component PIOSXR-0 state ready operation created status not-reached } } notification { eventTime 2020-04-24T20:57:50.587655+00:00 plan-state-change { service /cisco-sr-te-settings-fp:sr-setting[name='ALGO-1'] component self state ready operation modified status reached } } notification { eventTime 2020-04-24T20:57:50.587769+00:00 plan-state-change { service /cisco-sr-te-settings-fp:sr-setting[name='ALGO-1'] component PIOSXR-0 state cisco-sr-te-settings-fp-nano-plan-services:config-apply

Notifications


operation modified status reached } } notification { eventTime 2020-04-24T20:57:50.587842+00:00 plan-state-change { service /cisco-sr-te-settings-fp:sr-setting[name='ALGO-1'] component PIOSXR-0 state ready

Delete Notifications notification { eventTime 2020-04-24T20:59:56.64972+00:00 plan-state-change { service /cisco-sr-te-settings-fp:sr-setting[name='ALGO-1'] operation deleted } }

11.4 SR-PCE Notifications

This section includes the create and delete notifications for SR-PCE.

Create Notification notification { eventTime 2020-04-27T23:13:43.877658+00:00 plan-state-change { service /cisco-sr-te-pce-fp:sr-pce[name='PCE-0'] component self state ready operation created status not-reached } } notification { eventTime 2020-04-27T23:13:43.877775+00:00 plan-state-change { service /cisco-sr-te-pce-fp:sr-pce[name='PCE-0'] component P-0 state init operation created status reached } } notification { eventTime 2020-04-27T23:13:43.877816+00:00 plan-state-change { service /cisco-sr-te-pce-fp:sr-pce[name='PCE-0'] component P-0 state cisco-sr-te-pce-fp-nano-plan-services:config-apply operation created status not-reached } } notification {

Notifications


eventTime 2020-04-27T23:13:43.877877+00:00 plan-state-change { service /cisco-sr-te-pce-fp:sr-pce[name='PCE-0'] component P-0 state ready operation created status not-reached } } notification { eventTime 2020-04-27T23:13:45.198269+00:00 plan-state-change { service /cisco-sr-te-pce-fp:sr-pce[name='PCE-0'] component self state ready operation modified status reached } } notification { eventTime 2020-04-27T23:13:45.19838+00:00 plan-state-change { service /cisco-sr-te-pce-fp:sr-pce[name='PCE-0'] component P-0 state cisco-sr-te-pce-fp-nano-plan-services:config-apply operation modified status reached } } notification { eventTime 2020-04-27T23:13:45.198445+00:00 plan-state-change { service /cisco-sr-te-pce-fp:sr-pce[name='PCE-0'] component P-0 state ready operation modified status reached } } Delete Notifications notification { eventTime 2020-04-27T16:17:18.761193+00:00 plan-state-change { service /cisco-sr-te-pce-fp:sr-pce[name='PCE-0'] operation deleted } }

The following notification displays if the delete operation fails. notification { eventTime 2020-04-27T16:19:55.017591+00:00 plan-state-change { service /cisco-sr-te-pce-fp:sr-pce[name='PCE-0'] operation deleted status failed } }

Notifications


11.5 Flat L2VPN Example Notifications

This topic includes the create and delete notifications for L2VPN P2P, and L2VPN VPWS.

11.5.1 Flat L2VPN P2P Notifications

This topic discusses the notifications for the create and delete operations for L2VPN P2P.

Create Notification notification { eventTime 2020-04-24T18:46:03.713054+00:00 plan-state-change { service /flat-L2vpn[name='L2vpn01-nc'] component P-1 state cisco-flat-L2vpn-fp-nano-plan-services:config-apply operation created status not-reached } } notification { eventTime 2020-04-24T18:46:03.7131+00:00 plan-state-change { service /flat-L2vpn[name='L2vpn01-nc'] component P-1 state ready operation created status not-reached } } notification { eventTime 2020-04-24T18:46:07.027717+00:00 plan-state-change { service /flat-L2vpn[name='L2vpn01-nc'] component self state ready operation modified status reached } } notification { eventTime 2020-04-24T18:46:07.027856+00:00 plan-state-change { service /flat-L2vpn[name='L2vpn01-nc'] component P-0 state cisco-flat-L2vpn-fp-nano-plan-services:config-apply operation modified status reached } } notification { eventTime 2020-04-24T18:46:07.027971+00:00 plan-state-change { service /flat-L2vpn[name='L2vpn01-nc']

Notifications


component P-0 state ready operation modified status reached } } notification { eventTime 2020-04-24T18:46:07.028137+00:00 plan-state-change { service /flat-L2vpn[name='L2vpn01-nc'] component P-1 state cisco-flat-L2vpn-fp-nano-plan-services:config-apply operation modified status reached } } notification { eventTime 2020-04-24T18:46:07.028216+00:00 plan-state-change { service /flat-L2vpn[name='L2vpn01-nc'] component P-1 state ready operation modified status reached } }

Delete Notifications notification { eventTime 2020-04-24T11:48:54.258083+00:00 plan-state-change { service /flat-L2vpn[name='L2vpn01-nc'] operation deleted } }

The following notification displays if the delete operation fails. notification { eventTime 2020-04-24T11:52:25.590248+00:00 plan-state-change { service /flat-L2vpn[name='L2vpn01-nc'] operation deleted status failed } }

Notifications


11.5.2 Flat L2VPN VPWS Notifications

This topic discusses the notifications for the create and delete operations for L2VPN VPWS.

Create Notification notification { eventTime 2020-04-24T19:04:38.620857+00:00 plan-state-change { service /flat-L2vpn[name='L2vpn-dynamic-02-nc'] component P-1 state cisco-flat-L2vpn-fp-nano-plan-services:config-apply operation created status not-reached } } notification { eventTime 2020-04-24T19:04:38.620913+00:00 plan-state-change { service /flat-L2vpn[name='L2vpn-dynamic-02-nc'] component P-1 state ready operation created status not-reached } } notification { eventTime 2020-04-24T19:04:40.766288+00:00 plan-state-change { service /flat-L2vpn[name='L2vpn-dynamic-02-nc'] component self state ready operation modified status reached } } notification { eventTime 2020-04-24T19:04:40.766411+00:00 plan-state-change { service /flat-L2vpn[name='L2vpn-dynamic-02-nc'] component P-0 state cisco-flat-L2vpn-fp-nano-plan-services:config-apply operation modified status reached } } notification { eventTime 2020-04-24T19:04:40.766538+00:00 plan-state-change { service /flat-L2vpn[name='L2vpn-dynamic-02-nc'] component P-0 state ready operation modified status reached } } notification {

Notifications


eventTime 2020-04-24T19:04:40.76666+00:00 plan-state-change { service /flat-L2vpn[name='L2vpn-dynamic-02-nc'] component P-1 state cisco-flat-L2vpn-fp-nano-plan-services:config-apply operation modified status reached } } notification { eventTime 2020-04-24T19:04:40.766727+00:00 plan-state-change { service /flat-L2vpn[name='L2vpn-dynamic-02-nc'] component P-1 state ready operation modified status reached } }

Delete Notifications notification { eventTime 2020-04-24T12:16:07.883587+00:00 plan-state-change { service /flat-L2vpn[name='L2vpn-dynamic-02-nc'] operation deleted } }

The following notification displays if the delete operation fails. notification { eventTime 2020-04-24T12:07:52.33263+00:00 plan-state-change { service /flat-L2vpn[name='L2vpn-dynamic-02-nc'] operation deleted status failed } }

Notifications


11.5.3 L2VPN SR-TE – Preferred Path Notifications

This topic discusses the notifications for the create and delete operations for L2VPN SR-TE – preferred path.

Create Notification notification { eventTime 2020-04-24T19:17:23.181496+00:00 plan-state-change { service /flat-L2vpn[name='L2vpn-dynamic-02-nc'] component P-1 state cisco-flat-L2vpn-fp-nano-plan-services:config-apply operation modified

status not-reached

}

} notification { eventTime 2020-04-24T19:17:23.181557+00:00 plan-state-change { service /flat-L2vpn[name='L2vpn-dynamic-02-nc'] component P-1 state ready operation modified

status not-reached

}

} notification { eventTime 2020-04-24T19:17:24.918581+00:00 plan-state-change { service /flat-L2vpn[name='L2vpn-dynamic-02-nc'] component self state ready operation modified

status reached

}

} notification { eventTime 2020-04-24T19:17:24.918739+00:00 plan-state-change { service /flat-L2vpn[name='L2vpn-dynamic-02-nc'] component P-0 state cisco-flat-L2vpn-fp-nano-plan-services:config-apply operation modified

status reached

}


status reached

Notifications


}


status reached

}


status reached

}

}

Delete Notifications notification { eventTime 2020-04-24T12:18:30.345774+00:00 plan-state-change { service /flat-L2vpn[name='L2vpn-dynamic-02-nc']

operation deleted

}

}

The following notification displays if the delete operation fails. notification { eventTime 2020-04-24T12:19:22.056673+00:00 plan-state-change { service /flat-L2vpn[name='L2vpn-dynamic-02-nc'] operation deleted

status failed

}

}

Notifications


11.5.4 L2VPN SR-TE – ODN

This topic discusses the notifications for the create and delete operations for L2VPN SR-TE – ODN.

Create Notification notification { eventTime 2020-04-24T19:46:34.412326+00:00 plan-state-change { service /flat-L2vpn[name='L2vpn-dynamic-02-nc'] component P-1 state cisco-flat-L2vpn-fp-nano-plan-services:config-apply operation modified

status not-reached

}


status not-reached

}

} notification { eventTime 2020-04-24T19:46:36.2144+00:00 plan-state-change { service /flat-L2vpn[name='L2vpn-dynamic-02-nc'] component self state ready operation modified

status reached

}


status reached

}


status reached

Notifications


}


status reached

}


status reached

}

}

Delete Notifications notification { eventTime 2020-04-24T12:47:30.237791+00:00 plan-state-change { service /flat-L2vpn[name='L2vpn-dynamic-02-nc']

operation deleted

}

} The following notification displays if the delete operation fails. notification { eventTime 2020-04-24T12:48:54.139273+00:00 plan-state-change { service /flat-L2vpn[name='L2vpn-dynamic-02-nc'] operation deleted

status failed

}

}

Notifications


11.6 Flat L3VPN Example Notifications

This topic includes the create and delete notifications for L3VPN service.

11.6.1 Flat L3VPN Notifications

Create Notification notification { eventTime 2020-04-24T19:53:26.07081+00:00 plan-state-change { service /cisco-flat-L3vpn-fp:flat-L3vpn[name='L3'] component nc-1 state cisco-flat-L3vpn-fp-nano-plan-services:config-apply operation created status not-reached } } notification { eventTime 2020-04-24T19:53:26.070852+00:00 plan-state-change { service /cisco-flat-L3vpn-fp:flat-L3vpn[name='L3'] component nc-1 state ready operation created status not-reached } } notification { eventTime 2020-04-24T19:53:28.989988+00:00 plan-state-change { service /cisco-flat-L3vpn-fp:flat-L3vpn[name='L3'] component self state ready operation modified status reached } } notification { eventTime 2020-04-24T19:53:28.990111+00:00 plan-state-change { service /cisco-flat-L3vpn-fp:flat-L3vpn[name='L3'] component nc-0 state cisco-flat-L3vpn-fp-nano-plan-services:config-apply operation modified status reached } } notification { eventTime 2020-04-24T19:53:28.990186+00:00 plan-state-change { service /cisco-flat-L3vpn-fp:flat-L3vpn[name='L3'] component nc-0 state ready operation modified status reached } }

Notifications


notification { eventTime 2020-04-24T19:53:28.990296+00:00 plan-state-change { service /cisco-flat-L3vpn-fp:flat-L3vpn[name='L3'] component nc-1 state cisco-flat-L3vpn-fp-nano-plan-services:config-apply operation modified

status reached

}

} notification { eventTime 2020-04-24T19:53:28.99036+00:00 plan-state-change { service /cisco-flat-L3vpn-fp:flat-L3vpn[name='L3'] component nc-1 state ready operation modified status reached

}

}

Delete Notifications notification { eventTime 2020-04-24T15:05:57.4621+00:00 plan-state-change { service /cisco-flat-L3vpn-fp:flat-L3vpn[name='L3']

operation deleted

}

}

The following notification displays if the delete operation fails. notification { eventTime 2020-04-24T15:06:55.885785+00:00 plan-state-change { service /cisco-flat-L3vpn-fp:flat-L3vpn[name='L3'] operation deleted

status failed

}

}

Notifications


11.6.2 Flat -L3VPN SR TE Color

Create SR-TE Tunnel-Static notification { eventTime 2020-04-24T22:13:36.980087+00:00 plan-state-change { service /cisco-flat-L3vpn-fp:flat-L3vpn[name='L3'] component nc-1 state ready operation modified status reached } } notification { eventTime 2020-04-24T22:13:38.95747+00:00 plan-state-change { service /cisco-flat-L3vpn-fp:flat-L3vpn[name='L3'] component self state ready operation modified status not-reached } } notification { eventTime 2020-04-24T22:13:38.957614+00:00 plan-state-change { service /cisco-flat-L3vpn-fp:flat-L3vpn[name='L3'] component nc-0 state cisco-flat-L3vpn-fp-nano-plan-services:config-apply operation modified status not-reached } } notification { eventTime 2020-04-24T22:13:38.957685+00:00 plan-state-change { service /cisco-flat-L3vpn-fp:flat-L3vpn[name='L3'] component nc-0 state ready operation modified status not-reached } } notification { eventTime 2020-04-24T22:13:40.075873+00:00 plan-state-change { service /cisco-flat-L3vpn-fp:flat-L3vpn[name='L3'] component self state ready operation modified status reached } } notification { eventTime 2020-04-24T22:13:40.075993+00:00 plan-state-change { service /cisco-flat-L3vpn-fp:flat-L3vpn[name='L3'] component nc-0 state cisco-flat-L3vpn-fp-nano-plan-services:config-apply operation modified

Notifications


status reached } } notification { eventTime 2020-04-24T22:13:40.076062+00:00 plan-state-change { service /cisco-flat-L3vpn-fp:flat-L3vpn[name='L3'] component nc-0 state ready operation modified status reached } }

Delete Notifications notification { eventTime 2020-04-24T15:15:13.831081+00:00 plan-state-change { service /cisco-flat-L3vpn-fp:flat-L3vpn[name='L3'] operation deleted } }

The following notification displays if the delete operation fails. notification { eventTime 2020-04-24T15:15:49.773008+00:00 plan-state-change { service /cisco-flat-L3vpn-fp:flat-L3vpn[name='L3'] operation deleted status failed } }

Handling Zombies


12 Handling Zombies Zombies are the internal operational data model in NSO to store deleted service data. Zombies are helpful when performing staged deletions and RFM. RFM is the NSO version of eventual consistency.

When a service deletion is triggered, NSO maintains references of the deleted services (zombies) in operational data. The zombies are deleted from CDB when all the configurations for the service are removed from the devices.

Zombies inform the Northbound the progress of a service deletion. It also informs the stage it is waiting on, which helps to point to the problematic area. For more information on nano-services and zombies, see NSO Developer Guide.

In T-SDN FPs, you trigger a deletion to clean up the configuration on all the endpoints/nodes in a service. However, depending on the number of nodes or endpoints in a service, deleting the configuration at once may lock down the database until the time the slowest device removes the configuration. It is, therefore, recommended to delete the configurations in separate transactions, such as per device.

Once the configuration is successfully removed from all the devices in the service, continue to update the plan state to communicate the progress of deletion to Nortbound. When the last device configuration is removed, remove the plan, zombies, and all the service-related operational data from CDB.

Sometimes, zombies are not deleted in the following scenarios even after deleting the last device configuration. Some failures may require manual intervention to delete configuration references from the devices. In such cases, run the Cleanup action on the device and then run the service cleanup action on T-SDN FPs. For more information on the Cleanup actions, see chapter Working with Action Commands in this documentation.

1. Device is not reachable during deletion.

2. Device is reachable, but the configuration removal fails on the device for other reasons.

To recreate a service with the same name as a deleted service, wait for the service plan to be deleted. If the Northbound system tries to recreate the service instance before the zombie/delete is fully processed, the following error displays, which indicates the deletion process is still in progress.

"Aborted: Operation failed because: Service still in zombie state: 'YYY'".

Note: T-SDN FPs do not support zombie resurrect and redeploy options.

Handling Zombies


The following are some sample zombies for the SR-ODN service. admin@ncs% run show zombies ::::::::::::::::::::::::::::INTERNAL ZOMBIE::::::::::::::::::::::::::::

zombies service /sr-te/cisco-sr-te-cfp-sr-odn-internal:odn/odn-template[name='SR-

ODN'][head-end='PIOSXR-0']

delete-path /sr-te/cisco-sr-te-cfp-sr-odn-internal:odn/odn-template[name='SR-ODN'][head-

end='PIOSXR-0'] POST BACK ACTION TYPE NAME TRACK GOAL STATE STATUS WHEN ref STATUS ------------------------------------------------------------------------------- self self true - init reached - - - cisco-sr-te-cfp-sr-odn-nano-services:config-apply reached - - - ready not-reached - - - plan failed

plan error-info message "Failed to connect to device PIOSXR-0: connection refused: NEDCOM

CONNECT: Connection refused (Connection refused) in new state"

plan error-info log-entry "/zombies/service[service-path=\"/sr-te/cisco-sr-te-cfp-sr-odn-

internal:odn/odn-template[name='SR-ODN'][head-end='PIOSXR-0']\"]/log/log-entry[when='2020-

03-26T23:34:12.992768+00:00']"

WHEN TYPE LEVEL MESSAGE

-------------------------------------------------------------------------------

2020-03-26T23:34:12.992768+00:00 service-modified error Failed to connect to device

PIOSXR-0: connection refused: NEDCOM CONNECT: Connection refused (Connection refused) in

new state

::::::::::::::::::::::::::::EXTERNAL ZOMBIE::::::::::::::::::::::::::::

zombies service /sr-te/cisco-sr-te-cfp-sr-odn:odn/odn-template[name='SR-ODN']

delete-path /sr-te/cisco-sr-te-cfp-sr-odn:odn/odn-template[name='SR-ODN'] POST BACK ACTION TYPE NAME TRACK GOAL STATE STATUS WHEN ref STATUS ------------------------------------------------------------------------------- self self true - init not-reached - - - ready not-reached - - - cisco-sr-te-cfp-sr-odn-nano-plan-services:head-end PIOSXR-0 true - init reached - - - cisco-sr-te-cfp-sr-odn-nano-plan-services:config-apply failed - - - ready not-reached - - - plan failed

Appendix A: Package Categories and Packages


13 Appendix A: Package Categories and Packages This section provides the list of packages that are extracted during the T-SDN FP Bundle installation. Different packages from this list are used to install the T-SDN FPs. For more information on how to extract and copy these packages, see the Cisco NSO Transport SDN Function Pack Bundle Installation Guide.

Group Package Category Packages

Core Function Pack Packages

SR-TE CFP Packages ncs-5.2.2-cisco-sr-te-cfp-1.0.0.tar.gz

T-SDN FP Common Packages

ncs-5.2.1-core-fp-plan-notif-generator-1.0.0.tar.gz

ncs-5.2.1-custom-template-utils-2.0.0.tar.gz

ncs-5.2.1-core-fp-common-1.8.0.tar.gz

NEDs CLI NED ncs-5.2.2-cisco-iosxr-7.24.tar.gz

Example Packages

L2VPN Example Package ncs-5.2.2-cisco-flat-L2vpn-fp-EXAMPLE-1.0.0.tar.gz

L3VPN Example Package ncs-5.2.2-cisco-flat-L3vpn-fp-EXAMPLE-1.0.0.tar.gz

SR-Settings Example Package

ncs-5.2.2-cisco-sr-te-settings-fp-EXAMPLE-1.0.0.tar.gz

SR-PCE Example Package

ncs-5.2.2-cisco-sr-te-pce-fp-EXAMPLE-1.0.0.tar.gz

Resource Manager for SR-Settings

ncs-5.2.1-resource-manager-3.4.0.tar.gz

Shared Delete Handler Package for L2/L3 Interfaces

ncs-5.2.2-core-fp-delete-tag-service-EXAMPLE-1.0.0.tar.gz

Appendix C - Payloads and XML Outputs


15 Appendix C - Payloads and XML Outputs

15.1 Custom-Template Payloads

This topic contains sample custom-template payloads for the device templates mentioned in the chapter Using Custom-Templates in this documentation.

15.1.1 SR-ODN

Custom-template for all head-ends <config xmlns="http://tail-f.com/ns/config/1.0"> <sr-te xmlns="http://cisco.com/ns/nso/cfp/cisco-tsdn-sr-te"> <odn xmlns="http://cisco.com/ns/nso/cfp/cisco-tsdn-sr-te-sr-odn"> <odn-template> <name>SR-CLI-ODN-300</name> <custom-template> =============================================================> APPLYING CUSTOM TEMPLATE AT GLOBAL LEVEL FOR ALL HEAD-ENDs <name>CT-CLI-banner</name> <variable> <name>BANNER_TEXT</name> <value>Welcome</value> </variable> </custom-template> <head-end> <name>PIOSXR-0</name> </head-end> ... </odn-template> </odn> </sr-te> </config> Custom-template per head-end <config xmlns="http://tail-f.com/ns/config/1.0"> <sr-te xmlns="http://cisco.com/ns/nso/cfp/cisco-tsdn-sr-te"> <odn xmlns="http://cisco.com/ns/nso/cfp/cisco-tsdn-sr-te-sr-odn"> <odn-template> <name>SR-CLI-ODN-300</name> <head-end> <name>PIOSXR-0</name> <custom-template> =============================================================> APPLYING CUSTOM TEMPLATE AT LOCAL LEVEL FOR GIVEN HEAD-END <name>CT-CLI-banner</name> <variable> <name>BANNER_TEXT</name> <value>Welcome</value> </variable> </custom-template> </head-end> </odn-template> </odn> </sr-te> </config>



15.1.2 SR-Policy

Sample service payload using custom-template <config xmlns="http://tail-f.com/ns/config/1.0"> <sr-te xmlns="http://cisco.com/ns/nso/cfp/cisco-tsdn-sr-te"> <policies xmlns="http://cisco.com/ns/nso/cfp/cisco-tsdn-sr-te-sr-policies"> <policy> <name>SR-CLI-DYNAMIC</name> =================================================== CUSTOM TEMPLATE CONFIG FOR SR-POLICY <custom-template> <name>CT-CLI-logging</name> </custom-template> ... </policy> </policies> </sr-te> </config>

15.1.3 SR-Settings

Custom-templates for all nodes or per node <config xmlns="http://tail-f.com/ns/config/1.0"> <sr-setting xmlns="http://cisco.com/ns/nso/fp/examples/cisco-tsdn-sr-te-settings"> <name>SETTING-1</name> <custom-template> =====================================================> APPLYING CT AT GLOBAL LEVEL FOR ALL THE DEVICES IN A SERVICE <name>CT-CLI-logging</name> </custom-template> <maximum-sid-depth>100</maximum-sid-depth> <affinity-map-te> <color> <name>BLUE</name> <bit-position>1</bit-position> </color> <color> <name>GREEN</name> <bit-position>2</bit-position> </color> <color> <name>RED</name> <bit-position>0</bit-position> </color> </affinity-map-te> <pcc> <pce> <address> <ipv4> <address>1.1.1.1</address> <precedence>128</precedence> </ipv4> <ipv4> <address>2.2.2.2</address>



</ipv4> </address> </pce> </pcc> <node> <name>PIOSXR-0</name> <custom-template> =====================================================> APPLYING CT AT LOCAL LEVEL FOR GIVEN THE DEVICE IN A SERVICE <name>CT-CLI-banner</name> <variable> <name>BANNER_TEXT</name> <value>Welcome</value> </variable> </custom-template> <interface> <if-type>GigabitEthernet</if-type> <if-id>5</if-id> <te> <affinity> <color> <name>GREEN</name> </color> </affinity> <metric>2</metric> </te> </interface> <pcc> <source-address>192.168.2.1</source-address> </pcc> </node> <node> <name>PIOSXR-1</name> <interface> <if-type>GigabitEthernet</if-type> <if-id>7</if-id> <te> <affinity> <color> <name>BLUE</name> </color> </affinity> <metric>2</metric> </te> </interface> <pcc> <disable/> </pcc> </node> </sr-setting> </config>



15.1.4 SR-PCE

Custom-template for all nodes or per node <config xmlns="http://tail-f.com/ns/config/1.0"> <sr-pce xmlns="http://cisco.com/ns/nso/fp/examples/cisco-tsdn-sr-te-pce"> <name>PCE-0</name> <custom-template> ==========================================> APPLYING CUSTOM TEMPLATE AT GLOBAL LEVEL FOR ALL NODES <name>CT-CLI-logging</name> </custom-template> <node> <name>PIOSXR-0</name> <custom-template> ==========================================> APPLYING CUSTOM TEMPLATE AT LOCAL LEVEL FOR GIVEN NODE <name>CT-CLI-banner</name> <variable> <name>BANNER_TEXT</name> <value>Welcome</value> </variable> </custom-template> <pce> <address>100.1.1.1</address> <disjoint-path> <group-id> <id>60000</id> <type>srlg</type> <strict/> <lsp> <id>1</id> <pcc-address>2.2.2.2</pcc-address> <lsp-name>LSP-NAME</lsp-name> <shortest-path/> </lsp> </group-id> </disjoint-path> <timers> <reoptimization>600</reoptimization> <keepalive>20</keepalive> <minimum-peer-keepalive>21</minimum-peer-keepalive> </timers> <state-sync> <ipv4> <address>3.3.3.3</address> </ipv4> </state-sync> <password> <type>clear</type> <secret>password123</secret> </password> <backoff> <ratio>11</ratio> <difference>10</difference> <threshold>12</threshold> </backoff> <segment-routing> <strict-sid-only/> <te-latency/> </segment-routing> </pce> </node> </sr-pce> </config>




Sample service payload using custom-template <config xmlns="http://tail-f.com/ns/config/1.0"> <flat-L2vpn xmlns="http://cisco.com/ns/nso/fp/examples/cisco-tsdn-flat-L2vpn"> <name>L2vpn-dynamic-02</name> <service-type>evpn-vpws</service-type> <custom-template> ============================================================================> APPLYING CUSTOM TEMPLATE AT GLOBAL LEVEL FOR ALL SITES <name>CT-CLI-logging</name> </custom-template> <flat-L2vpn-evpn-vpws> <evi-id>1000</evi-id> <local-site> <pe>PIOSXR-0</pe> <custom-template> ============================================================================> APPLYING CUSTOM TEMPLATE AT LOCAL LEVEL FOR LOCAL SITE <name>CT-CLI-banner</name> <variable> <name>BANNER_TEXT</name> <value>Welcome</value> </variable> </custom-template> <if-type>GigabitEthernet</if-type> <if-id>1000</if-id> <if-description>L2VPN-Dynamic-02</if-description> <if-encap>dot1q</if-encap> <vlan-id>2</vlan-id> <sub-if-id>3</sub-if-id> <xconnect-group-name>evpn_vpws_nso</xconnect-group-name> <p2p-name>c</p2p-name> <evi-source>2</evi-source> <evi-target>6</evi-target> </local-site> <remote-site> <pe>PIOSXR-1</pe> <custom-template> ============================================================================> APPLYING CUSTOM TEMPLATE AT LOCAL LEVEL FOR REMOTE SITE <name>CT-CLI-banner</name> <variable> <name>BANNER_TEXT</name> <value>Welcome</value> </variable> </custom-template> <if-type>FortyGigE</if-type> <if-id>12</if-id> <if-description>L2VPN-Dynamic-02</if-description> <if-encap>untagged</if-encap> <xconnect-group-name>evpn_vpws_nso</xconnect-group-name> <p2p-name>EVPN-PIOSXR-1</p2p-name> </remote-site> </flat-L2vpn-evpn-vpws> </flat-L2vpn> </config>




Sample service payload using custom-template

<config xmlns="http://tail-f.com/ns/config/1.0">

<flat-L3vpn xmlns="http://cisco.com/ns/nso/fp/examples/cisco-tsdn-

flat-L3vpn">

<name>L3</name>

<custom-template>==============================================

==> APPLYING CUSTOM TEMPLATE AT GLOBAL LEVEL FOR ALL ENDPOINTS

<name>CT-NETCONF-logging</name>

</custom-template>

<endpoint>

<endpoint-name>nc-0</endpoint-name>

<access-pe>P-0</access-pe>

<if-type>Loopback</if-type>

<if-id>3</if-id>

<pe-ip-addr>169.1.1.1/32</pe-ip-addr>

<as-no>65001</as-no>

<custom-template>============================================

==> APPLYING CUSTOM TEMPLATE AT LOCAL LEVEL FOR SINGLE ENDPOINT

<name>CT-NETCONF-banner-iteration</name>

<iteration>

<number>1</number>

<variable>

<name>BANNER_NAME</name>

<value>login</value>

</variable>

<variable>

<name>BANNER_TEXT</name>

<value>Welcome to Netconf P-0</value>

</variable>

</iteration>

<iteration>

<number>2</number>

<variable>

<name>BANNER_NAME</name>

<value>prompt-timeout</value>

</variable>

<variable>

<name>BANNER_TEXT</name>

<value>TimedOut</value>

</variable>

</iteration>

</custom-template>

<vrf>

<vrf-definition>L3VPN</vrf-definition>

<route-distinguisher>1:2</route-distinguisher>

<address-family>

<address-family>ipv4</address-family>

<vpn-target>



<rt-value>200:100</rt-value>

<rt-type>both</rt-type>

</vpn-target>

<vpn-target>


<rt-type>export</rt-type>

</vpn-target>

<vpn-target>


<rt-type>import</rt-type>

</vpn-target>

</address-family>

</vrf>

<ce-pe-prot>

<e-bgp>

<neighbor-ipv4>169.1.1.2</neighbor-ipv4>

<remote-as-ipv4>65002</remote-as-ipv4>

</e-bgp>

</ce-pe-prot>

<sr-te>

<color>

<id>3000</id>

<ipv4>

</ipv4>

</color>

<color>

<id>3001</id>

<ipv4>

<prefix>10.1.1.1/32</prefix>

<prefix>20.1.1.1/32</prefix>

</ipv4>

</color>

</sr-te>

</endpoint>

...

</flat-L3vpn>

</config>



15.2 XML Output – get-modifications Action

This topic contains the XML output for the get-modifications action. For the corresponding CLI outputs, see chapter Working with Action Commands in this documentation.

15.2.1 SR-ODN

get-modifications action for a service admin@ncs% request sr-te cisco-sr-te-cfp-sr-odn:odn odn-template SR-ODN action get-modifications outformat xml message <devices xmlns="http://tail-f.com/ns/ncs"> <device> <name>P-0</name> <config> <sr xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-segment-routing-ms-cfg"> <traffic-engineering xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-infra-xtc-agent-cfg"> <on-demand-colors> <on-demand-color> <color>300</color> <on-demand-color-dyn-mpls> <on-demand-color-dyn-mpls-metric> <metric-type>igp</metric-type> <enable/> </on-demand-color-dyn-mpls-metric> <on-demand-color-dyn-mpls-pce> <enable/> </on-demand-color-dyn-mpls-pce> <disjoint-path> <group-id>10</group-id> <disjointness-type>node</disjointness-type> <sub-id>5</sub-id> </disjoint-path> <on-demand-color-dyn-mpls-flex-algorithm>200</on-demand-color-dyn-mpls-flex-algorithm> <enable/> <affinity-rules> <affinity-rule> <rule>affinity-exclude-any</rule> <affinity-name> <affinity-name>BLUE</affinity-name> </affinity-name> </affinity-rule> </affinity-rules> </on-demand-color-dyn-mpls> <bandwidth>200</bandwidth> <maximum-sid-depth>6</maximum-sid-depth> <enable/> </on-demand-color> </on-demand-colors> </traffic-engineering> </sr> </config> </device> </devices>



get-modifications action per device admin@ncs% request sr-te cisco-sr-te-cfp-sr-odn:odn odn-template SR-ODN action get-modifications device P-0 outformat xml message <devices xmlns="http://tail-f.com/ns/ncs"> <device> <name>P-0</name> <config> <sr xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-segment-routing-ms-cfg"> <traffic-engineering xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-infra-xtc-agent-cfg"> <on-demand-colors> <on-demand-color> <color>300</color> <on-demand-color-dyn-mpls> <on-demand-color-dyn-mpls-metric> <metric-type>igp</metric-type> <enable/> </on-demand-color-dyn-mpls-metric> <on-demand-color-dyn-mpls-pce> <enable/> </on-demand-color-dyn-mpls-pce> <disjoint-path> <group-id>10</group-id> <disjointness-type>node</disjointness-type> <sub-id>5</sub-id> </disjoint-path> <on-demand-color-dyn-mpls-flex-algorithm>200</on-demand-color-dyn-mpls-flex-algorithm> <enable/> <affinity-rules> <affinity-rule> <rule>affinity-exclude-any</rule> <affinity-name> <affinity-name>BLUE</affinity-name> </affinity-name> </affinity-rule> </affinity-rules> </on-demand-color-dyn-mpls> <bandwidth>200</bandwidth> <maximum-sid-depth>6</maximum-sid-depth> <enable/> </on-demand-color> </on-demand-colors> </traffic-engineering> </sr> </config> </device> </devices>



15.2.2 SR-Policy

get-modifications action for service admin@ncs% request sr-te cisco-sr-te-cfp-sr-policies:policies policy SR-CLI-DYNAMIC action get-modifications outformat xml message <devices xmlns="http://tail-f.com/ns/ncs"> <device> <name>PIOSXR-0</name> <config> <segment-routing xmlns="http://tail-f.com/ned/cisco-ios-xr"> <traffic-eng> <segment-list> <name>mysidlist</name> <index> <id>1</id> <mpls> <label>17001</label> </mpls> </index> <index> <id>2</id> <mpls> <label>18001</label> </mpls> </index> </segment-list> <policy> <name>SR-CLI-DYNAMIC</name> <color> <end-point> <ipv4>1.1.1.1</ipv4> </end-point> </color> <candidate-paths> <preference> <id>200</id> <explicit> <segment-list> <name>mysidlist</name> <weight>10</weight> </segment-list> </explicit> </preference> </candidate-paths> </policy> </traffic-eng> </segment-routing> </config> </device> </devices>



15.2.3 SR-Settings

get-modifications action for a service admin@ncs% request sr-setting SETTING-1 action get-modifications outformat xml message <devices xmlns="http://tail-f.com/ns/ncs"> <device> <name>PIOSXR-0</name> <config> <segment-routing xmlns="http://tail-f.com/ned/cisco-ios-xr"> <traffic-eng> <interface> <name>GigabitEthernet5</name> <affinity> <color> <name>GREEN</name> </color> </affinity> <metric>2</metric> </interface> <maximum-sid-depth>100</maximum-sid-depth> <affinity-map> <color> <name>BLUE</name> <prefix>name</prefix> <bit-position>1</bit-position> </color> <color> <name>GREEN</name> <prefix>name</prefix> <bit-position>2</bit-position> </color> <color> <name>RED</name> <prefix>name</prefix> <bit-position>0</bit-position> </color> </affinity-map> <pcc> <source-address> <ipv4>192.168.2.1</ipv4> </source-address> <pce> <address> <ipv4> <address>1.1.1.1</address> <precedence>128</precedence> </ipv4> <ipv4> <address>2.2.2.2</address> <precedence>255</precedence> </ipv4> </address> </pce>



</pcc> </traffic-eng> </segment-routing> </config> </device> </devices> <devices xmlns="http://tail-f.com/ns/ncs"> <device> <name>PIOSXR-1</name> <config> <segment-routing xmlns="http://tail-f.com/ned/cisco-ios-xr"> <traffic-eng> <interface> <name>GigabitEthernet7</name> <affinity> <color> <name>BLUE</name> </color> </affinity> <metric>2</metric> </interface> <maximum-sid-depth>100</maximum-sid-depth> <affinity-map> <color> <name>BLUE</name> <prefix>name</prefix> <bit-position>1</bit-position> </color> <color> <name>GREEN</name> <prefix>name</prefix> <bit-position>2</bit-position> </color> <color> <name>RED</name> <prefix>name</prefix> <bit-position>0</bit-position> </color> </affinity-map> </traffic-eng> </segment-routing> </config> </device> </devices> get-modifications action per device admin@ncs% request sr-setting SETTING-1 action get-modifications device PIOSXR-0 outformat xml message <devices xmlns="http://tail-f.com/ns/ncs"> <device> <name>PIOSXR-0</name> <config> <segment-routing xmlns="http://tail-f.com/ned/cisco-ios-xr"> <traffic-eng>



<interface> <name>GigabitEthernet5</name> <affinity> <color> <name>GREEN</name> </color> </affinity> <metric>2</metric> </interface> <maximum-sid-depth>100</maximum-sid-depth> <affinity-map> <color> <name>BLUE</name> <prefix>name</prefix> <bit-position>1</bit-position> </color> <color> <name>GREEN</name> <prefix>name</prefix> <bit-position>2</bit-position> </color> <color> <name>RED</name> <prefix>name</prefix> <bit-position>0</bit-position> </color> </affinity-map> <pcc> <source-address> <ipv4>192.168.2.1</ipv4> </source-address> <pce> <address> <ipv4> <address>1.1.1.1</address> <precedence>128</precedence> </ipv4> <ipv4> <address>2.2.2.2</address> <precedence>255</precedence> </ipv4> </address> </pce> </pcc> </traffic-eng> </segment-routing> </config> </device> </devices>



15.2.4 SR-PCE

get-modifications action for a service admin@ncs% request sr-pce PCE-0 action get-modifications outformat xml message <devices xmlns="http://tail-f.com/ns/ncs"> <device> <name>PIOSXR-0</name> <config> <pce xmlns="http://tail-f.com/ned/cisco-ios-xr"> <address> <ipv4>100.1.1.1</ipv4> </address> <disjoint-path> <group-id> <id>60000</id> <type>srlg</type> <sub-id>1</sub-id> <strict/> <lsp> <id>1</id> <pcc> <ipv4>2.2.2.2</ipv4> </pcc> <lsp-name>LSP-NAME</lsp-name> <shortest-path/> </lsp> </group-id> </disjoint-path> <timers> <reoptimization>600</reoptimization> <keepalive>20</keepalive> <minimum-peer-keepalive>21</minimum-peer-keepalive> </timers> <state-sync> <ipv4> <address>3.3.3.3</address> </ipv4> </state-sync> <password> <type>clear</type> <secret>password123</secret> </password> <backoff> <ratio>11</ratio> <difference>10</difference> <threshold>12</threshold> </backoff> <segment-routing> <strict-sid-only/> <te-latency/> </segment-routing> </pce> </config> </device> </devices>



get-modifications action for a device admin@ncs% request sr-pce PCE-0 action get-modifications device PIOSXR-0 outformat xml message <devices xmlns="http://tail-f.com/ns/ncs"> <device> <name>PIOSXR-0</name> <config> <pce xmlns="http://tail-f.com/ned/cisco-ios-xr"> <address> <ipv4>100.1.1.1</ipv4> </address> <disjoint-path> <group-id> <id>60000</id> <type>srlg</type> <sub-id>1</sub-id> <strict/> <lsp> <id>1</id> <pcc> <ipv4>2.2.2.2</ipv4> </pcc> <lsp-name>LSP-NAME</lsp-name> <shortest-path/> </lsp> </group-id> </disjoint-path> <timers> <reoptimization>600</reoptimization> <keepalive>20</keepalive> <minimum-peer-keepalive>21</minimum-peer-keepalive> </timers> <state-sync> <ipv4> <address>3.3.3.3</address> </ipv4> </state-sync> <password> <type>clear</type> <secret>password123</secret> </password> <backoff> <ratio>11</ratio> <difference>10</difference> <threshold>12</threshold> </backoff> <segment-routing> <strict-sid-only/> <te-latency/> </segment-routing> </pce> </config> </device> </devices>




get-modifications action for a service admin@ncs% request flat-L2vpn P2P-DOT1Q action get-modifications outformat xml message <devices xmlns="http://tail-f.com/ns/ncs"> <device> <name>PIOSXR-0</name> <config> <interface xmlns="http://tail-f.com/ned/cisco-ios-xr"> <HundredGigE> <id>0/0/0/8</id> <description>T-SDN Interface</description> </HundredGigE> <HundredGigE-subinterface> <HundredGigE> <id>0/0/0/8.100</id> <mode>l2transport</mode> <description>T-SDN Interface</description> <encapsulation> <dot1q> <vlan-id>100</vlan-id> </dot1q> </encapsulation> <rewrite> <ingress> <tag> <translate>1-to-1</translate> <dot1q>123</dot1q> <mode>symmetric</mode> </tag> </ingress> </rewrite> </HundredGigE> </HundredGigE-subinterface> </interface> <l2vpn xmlns="http://tail-f.com/ned/cisco-ios-xr"> <pw-class> <name>P2P-DOT1Q</name> <encapsulation> <mpls/> </encapsulation> </pw-class> <xconnect> <group> <name>P2P-DOT1Q</name> <p2p> <name>P2P-DOT1Q</name> <interface> <name>HundredGigE0/0/0/8.100</name> </interface> <neighbor> <address>14.0.0.0</address> <pw-id>100</pw-id>



<ip-version>ipv4</ip-version> <mpls> <static> <label> <local>101</local> <remote>202</remote> </label> </static> </mpls> <pw-class>P2P-DOT1Q</pw-class> </neighbor> </p2p> </group> </xconnect> </l2vpn> </config> </device> </devices> <devices xmlns="http://tail-f.com/ns/ncs"> <device> <name>PIOSXR-1</name> <config> <interface xmlns="http://tail-f.com/ned/cisco-ios-xr"> <HundredGigE> <id>0/0/0/8</id> <description>T-SDN Interface</description> </HundredGigE> <HundredGigE-subinterface> <HundredGigE> <id>0/0/0/8.100</id> <mode>l2transport</mode> <description>T-SDN Interface</description> <encapsulation> <dot1q> <vlan-id>100</vlan-id> </dot1q> </encapsulation> <rewrite> <ingress> <tag> <translate>1-to-1</translate> <dot1q>123</dot1q> <mode>symmetric</mode> </tag> </ingress> </rewrite> </HundredGigE> </HundredGigE-subinterface> </interface> <l2vpn xmlns="http://tail-f.com/ned/cisco-ios-xr"> <pw-class> <name>P2P-DOT1Q</name> <encapsulation> <mpls/> </encapsulation> </pw-class>



<xconnect> <group> <name>P2P-DOT1Q</name> <p2p> <name>P2P-DOT1Q</name> <interface> <name>HundredGigE0/0/0/8.100</name> </interface> <neighbor> <address>12.0.0.0</address> <pw-id>100</pw-id> <ip-version>ipv4</ip-version> <mpls> <static> <label> <local>202</local> <remote>101</remote> </label> </static> </mpls> <pw-class>P2P-DOT1Q</pw-class> </neighbor> </p2p> </group> </xconnect> </l2vpn> </config> </device> </devices>

get-modifications action for a remote-site

admin@ncs% request flat-L2vpn L2vpn01 action get-modifications site-type remote outformat xml message <devices xmlns="http://tail-f.com/ns/ncs"> <device> <name>PIOSXR-1</name> <config> <interface xmlns="http://tail-f.com/ned/cisco-ios-xr"> <TenGigE> <id>0/0/0/7</id> </TenGigE> <TenGigE-subinterface> <TenGigE> <id>0/0/0/7.200</id> <mode>l2transport</mode> <description>l2vpn-static-01</description> <encapsulation> <dot1q> <vlan-id>200</vlan-id> </dot1q> </encapsulation> </TenGigE> </TenGigE-subinterface>



</interface> <l2vpn xmlns="http://tail-f.com/ned/cisco-ios-xr"> <pw-class> <name>mpls-nso</name> <encapsulation> <mpls/> </encapsulation> </pw-class> <xconnect> <group> <name>p2p-nso</name> <p2p> <name>STATIC-PIOSXR-1</name> <interface> <name>TenGigE0/0/0/7.200</name> </interface> <neighbor> <address>12.0.0.0</address> <pw-id>100</pw-id> <ip-version>ipv4</ip-version> <mpls> <static> <label> <local>202</local> <remote>101</remote> </label> </static> </mpls> <pw-class>mpls-nso</pw-class> </neighbor> </p2p> </group> </xconnect> </l2vpn> </config> </device> </devices>




get-modifications action for a service admin@ncs% request flat-L3vpn L3 action get-modifications outformat xml message <devices xmlns="http://tail-f.com/ns/ncs"> <device> <name>P-0</name> <config> <interface-configurations xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-ifmgr-cfg"> <interface-configuration> <active>act</active> <interface-name>Loopback3</interface-name> <interface-virtual/> <vrf xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-infra-rsi-cfg">L3VPN</vrf> <ipv4-network xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-ipv4-io-cfg"> <addresses> <primary> <address>169.1.1.1</address> <netmask>255.255.255.255</netmask> </primary> </addresses> </ipv4-network> </interface-configuration> </interface-configurations> <vrfs xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-infra-rsi-cfg"> <vrf> <vrf-name>L3VPN</vrf-name> <create/> <afs> <af> <af-name>ipv4</af-name> <saf-name>unicast</saf-name> <topology-name>default</topology-name> <create/> <bgp xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-ipv4-bgp-cfg"> <import-route-targets> <route-targets> <route-target> <type>as</type> <as-or-four-byte-as> <as-xx>0</as-xx> <as>100</as> <as-index>102</as-index> <stitching-rt>0</stitching-rt> </as-or-four-byte-as> <as-or-four-byte-as> <as-xx>0</as-xx> <as>200</as>



<as-index>100</as-index> <stitching-rt>0</stitching-rt> </as-or-four-byte-as> </route-target> </route-targets> </import-route-targets> <export-route-targets> <route-targets> <route-target> <type>as</type> <as-or-four-byte-as> <as-xx>0</as-xx> <as>100</as> <as-index>101</as-index> <stitching-rt>0</stitching-rt> </as-or-four-byte-as> <as-or-four-byte-as> <as-xx>0</as-xx> <as>200</as> <as-index>100</as-index> <stitching-rt>0</stitching-rt> </as-or-four-byte-as> </route-target> </route-targets> </export-route-targets> </bgp> </af> </afs> </vrf> </vrfs> <bgp xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-ipv4-bgp-cfg"> <instance> <instance-name>default</instance-name> <instance-as> <as>0</as> <four-byte-as> <as>65001</as> <vrfs> <vrf> <vrf-name>L3VPN</vrf-name> <vrf-global> <route-distinguisher> <type>as</type> <as-xx>0</as-xx> <as>1</as> <as-index>2</as-index> </route-distinguisher> <vrf-global-afs> <vrf-global-af> <af-name>ipv4-unicast</af-name> <enable/> </vrf-global-af> </vrf-global-afs> <exists/> </vrf-global> <vrf-neighbors>



<vrf-neighbor> <neighbor-address>169.1.1.2</neighbor-address> <vrf-neighbor-afs> <vrf-neighbor-af> <af-name>ipv4-unicast</af-name> <activate/> <route-policy-in>PASS_ALL</route-policy-in> <route-policy-out>PASS_ALL</route-policy-out> </vrf-neighbor-af> </vrf-neighbor-afs> <remote-as> <as-xx>0</as-xx> <as-yy>65002</as-yy> </remote-as> </vrf-neighbor> </vrf-neighbors> </vrf> </vrfs> <bgp-running/> </four-byte-as> </instance-as> </instance> </bgp> <routing-policy xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-policy-repository-cfg"> <route-policies> <route-policy> <route-policy-name>PASS_ALL</route-policy-name> <rpl-route-policy>route-policy PASS_ALL pass end-policy </rpl-route-policy> </route-policy> </route-policies> </routing-policy> </config> </device> </devices> <devices xmlns="http://tail-f.com/ns/ncs"> <device> <name>P-1</name> <config> <interface-configurations xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-ifmgr-cfg"> <interface-configuration> <active>act</active> <interface-name>Loopback3</interface-name> <interface-virtual/> <vrf xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-infra-rsi-cfg">L3VPN</vrf> <ipv4-network xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-ipv4-io-cfg"> <addresses> <primary> <address>169.1.1.1</address>



<netmask>255.255.255.255</netmask> </primary> </addresses> </ipv4-network> </interface-configuration> </interface-configurations> <vrfs xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-infra-rsi-cfg"> <vrf> <vrf-name>L3VPN</vrf-name> <create/> <afs> <af> <af-name>ipv4</af-name> <saf-name>unicast</saf-name> <topology-name>default</topology-name> <create/> <bgp xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-ipv4-bgp-cfg"> <import-route-targets> <route-targets> <route-target> <type>as</type> <as-or-four-byte-as> <as-xx>0</as-xx> <as>100</as> <as-index>102</as-index> <stitching-rt>0</stitching-rt> </as-or-four-byte-as> <as-or-four-byte-as> <as-xx>0</as-xx> <as>200</as> <as-index>100</as-index> <stitching-rt>0</stitching-rt> </as-or-four-byte-as> </route-target> </route-targets> </import-route-targets> <export-route-targets> <route-targets> <route-target> <type>as</type> <as-or-four-byte-as> <as-xx>0</as-xx> <as>100</as> <as-index>101</as-index> <stitching-rt>0</stitching-rt> </as-or-four-byte-as> <as-or-four-byte-as> <as-xx>0</as-xx> <as>200</as> <as-index>100</as-index> <stitching-rt>0</stitching-rt> </as-or-four-byte-as> </route-target> </route-targets>



</export-route-targets> </bgp> </af> </afs> </vrf> </vrfs> <bgp xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-ipv4-bgp-cfg"> <instance> <instance-name>default</instance-name> <instance-as> <as>0</as> <four-byte-as> <as>65001</as> <vrfs> <vrf> <vrf-name>L3VPN</vrf-name> <vrf-global> <route-distinguisher> <type>as</type> <as-xx>0</as-xx> <as>1</as> <as-index>2</as-index> </route-distinguisher> <vrf-global-afs> <vrf-global-af> <af-name>ipv4-unicast</af-name> <enable/> </vrf-global-af> </vrf-global-afs> <exists/> </vrf-global> <vrf-neighbors> <vrf-neighbor> <neighbor-address>169.1.1.2</neighbor-address> <vrf-neighbor-afs> <vrf-neighbor-af> <af-name>ipv4-unicast</af-name> <activate/> <route-policy-in>PASS_ALL</route-policy-in> <route-policy-out>PASS_ALL</route-policy-out> </vrf-neighbor-af> </vrf-neighbor-afs> <remote-as> <as-xx>0</as-xx> <as-yy>65002</as-yy> </remote-as> </vrf-neighbor> </vrf-neighbors> </vrf> </vrfs> <bgp-running/> </four-byte-as> </instance-as> </instance> </bgp>



<routing-policy xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-policy-repository-cfg"> <route-policies> <route-policy> <route-policy-name>PASS_ALL</route-policy-name> <rpl-route-policy>route-policy PASS_ALL pass end-policy </rpl-route-policy> </route-policy> </route-policies> </routing-policy> </config> </device> </devices>

get-modifications action for an endpoint admin@ncs% request flat-L3vpn L3 action get-modifications endpoint nc-0 outformat xml message <devices xmlns="http://tail-f.com/ns/ncs"> <device> <name>P-0</name> <config> <interface-configurations xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-ifmgr-cfg"> <interface-configuration> <active>act</active> <interface-name>Loopback3</interface-name> <interface-virtual/> <vrf xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-infra-rsi-cfg">L3VPN</vrf> <ipv4-network xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-ipv4-io-cfg"> <addresses> <primary> <address>169.1.1.1</address> <netmask>255.255.255.255</netmask> </primary> </addresses> </ipv4-network> </interface-configuration> </interface-configurations> <vrfs xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-infra-rsi-cfg"> <vrf> <vrf-name>L3VPN</vrf-name> <create/> <afs> <af> <af-name>ipv4</af-name> <saf-name>unicast</saf-name> <topology-name>default</topology-name> <create/>



<bgp xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-ipv4-bgp-cfg"> <import-route-targets> <route-targets> <route-target> <type>as</type> <as-or-four-byte-as> <as-xx>0</as-xx> <as>100</as> <as-index>102</as-index> <stitching-rt>0</stitching-rt> </as-or-four-byte-as> <as-or-four-byte-as> <as-xx>0</as-xx> <as>200</as> <as-index>100</as-index> <stitching-rt>0</stitching-rt> </as-or-four-byte-as> </route-target> </route-targets> </import-route-targets> <export-route-targets> <route-targets> <route-target> <type>as</type> <as-or-four-byte-as> <as-xx>0</as-xx> <as>100</as> <as-index>101</as-index> <stitching-rt>0</stitching-rt> </as-or-four-byte-as> <as-or-four-byte-as> <as-xx>0</as-xx> <as>200</as> <as-index>100</as-index> <stitching-rt>0</stitching-rt> </as-or-four-byte-as> </route-target> </route-targets> </export-route-targets> </bgp> </af> </afs> </vrf> </vrfs> <bgp xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-ipv4-bgp-cfg"> <instance> <instance-name>default</instance-name> <instance-as> <as>0</as> <four-byte-as> <as>65001</as> <vrfs> <vrf> <vrf-name>L3VPN</vrf-name> <vrf-global>



<route-distinguisher> <type>as</type> <as-xx>0</as-xx> <as>1</as> <as-index>2</as-index> </route-distinguisher> <vrf-global-afs> <vrf-global-af> <af-name>ipv4-unicast</af-name> <enable/> </vrf-global-af> </vrf-global-afs> <exists/> </vrf-global> <vrf-neighbors> <vrf-neighbor> <neighbor-address>169.1.1.2</neighbor-address> <vrf-neighbor-afs> <vrf-neighbor-af> <af-name>ipv4-unicast</af-name> <activate/> <route-policy-in>PASS_ALL</route-policy-in> <route-policy-out>PASS_ALL</route-policy-out> </vrf-neighbor-af> </vrf-neighbor-afs> <remote-as> <as-xx>0</as-xx> <as-yy>65002</as-yy> </remote-as> </vrf-neighbor> </vrf-neighbors> </vrf> </vrfs> <bgp-running/> </four-byte-as> </instance-as> </instance> </bgp> <routing-policy xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-policy-repository-cfg"> <route-policies> <route-policy> <route-policy-name>PASS_ALL</route-policy-name> <rpl-route-policy>route-policy PASS_ALL pass end-policy </rpl-route-policy> </route-policy> </route-policies> </routing-policy> </config> </device> </devices>

Appendix D: Use Cases


16 Appendix D: Use Cases The use cases in this section provide an insight to the T-SDN FPs workflow. These use cases provide complete functional solution and thus help to understand and implement the various service models in the CFP.

To explain these use cases, the network orchestration and virtualization platform Virtual Internet Routing Lab (VIRL) is used to design the network topology, configure the virtual machines, and instantiate the network.

The following criteria was considered to design the topology and configure the virtual machines.

1. Install T-SDN FPs with the required NED packages. For more information on the installation, see the Cisco NSO Transport SDN Function Pack Bundle Installation Guide.

2. Use image versions 6.5.3 or 6.6.3 in the topology.

3. Copy the IOSXRv9000 image version 6.5.3.

4. Create flavor before starting the simulation on VIRL (Flavor - 16384 MB, 4 CPUs, and 80 GB Disk)

5. Start the VIRL simulation with the topology configuration. The topology configuration is available at TSDN-0_0_11.virl.

6. Configure the network topology with Intermediate System to Intermediate System (isis), BGP protocol, and Segment Routing infrastructure setup. The reference topology appears as follows:

7. Ensure NSO VM is reachable to IOSXRV9000 spun in VIRL setup. Verify the configuration of the devices in the topology. Make sure the segment routing label table on isis is listing the devices connected in the topology.



Device Verification

IOSXRv9000-1 (Core-R1)

RP/0/RP0/CPU0:Core-R1#show isis segment-routing label table Tue May 5 19:47:57.076 UTC IS-IS 1 IS Label Table Label Prefix/Interface ---------- ---------------- 17001 Loopback0 18001 100.100.100.2/32 19001 100.100.100.3/32 20001 100.100.100.4/32 21001 100.100.100.5/32 22001 100.100.100.6/32


RP/0/RP0/CPU0:Core-R2#show isis segment-routing label table Tue May 5 19:48:17.641 UTC IS-IS 1 IS Label Table Label Prefix/Interface ---------- ---------------- 17001 100.100.100.1/32 18001 Loopback0 19001 100.100.100.3/32 20001 100.100.100.4/32 21001 100.100.100.5/32 22001 100.100.100.6/32


RP/0/RP0/CPU0:Core-R3#show isis segment-routing label table Tue May 5 19:48:27.695 UTC IS-IS 1 IS Label Table Label Prefix/Interface ---------- ---------------- 17001 100.100.100.1/32 18001 100.100.100.2/32 19001 Loopback0 20001 100.100.100.4/32 21001 100.100.100.5/32 22001 100.100.100.6/32


RP/0/RP0/CPU0:Core-R4#show isis segment-routing label table Tue May 5 19:48:46.989 UTC IS-IS 1 IS Label Table Label Prefix/Interface ---------- ---------------- 17001 100.100.100.1/32 18001 100.100.100.2/32 19001 100.100.100.3/32 20001 Loopback0 21001 100.100.100.5/32 22001 100.100.100.6/32

IOSXRv9000-5 (PE-R5)

RP/0/RP0/CPU0:PE-R5#show isis segment-routing label table Tue May 5 19:50:06.116 UTC IS-IS 1 IS Label Table Label Prefix/Interface ---------- ----------------



17001 100.100.100.1/32 18001 100.100.100.2/32 19001 100.100.100.3/32 20001 100.100.100.4/32 21001 Loopback0 22001 100.100.100.6/32

IOSXRv9000-6 (PE-R6)

RP/0/RP0/CPU0:PE-R6#show isis segment-routing label table Tue May 5 19:50:09.317 UTC IS-IS 1 IS Label Table Label Prefix/Interface ---------- ---------------- 17001 100.100.100.1/32 18001 100.100.100.2/32 19001 100.100.100.3/32 20001 100.100.100.4/32 21001 100.100.100.5/32 22001 Loopback0

8. Add the devices configured in the VIRL topology (TSDN-0_0_11.virl) to the NSO device tree. The IOSXR9000v devices are added as CLI type devices. configure set devices authgroups group iosxr_authgroup default-map remote-name admin remote-password cisco set devices device Core-R1 authgroup iosxr_authgroup address 172.16.1.31 port 22 state admin-state unlocked set devices device Core-R1 device-type cli ned-id cisco-iosxr-cli-7.24 set devices device Core-R1 trace raw set devices device Core-R2 authgroup iosxr_authgroup address 172.16.1.32 port 830 state admin-state unlocked set devices device Core-R2 device-type cli ned-id cisco-iosxr-cli-7.24 set devices device Core-R2 trace raw set devices device Core-R3 authgroup iosxr_authgroup address 172.16.1.33 port 830 state admin-state unlocked set devices device Core-R3 device-type cli ned-id cisco-iosxr-cli-7.24 set devices device Core-R3 trace raw set devices device Core-R4 authgroup iosxr_authgroup address 172.16.1.34 port 830 state admin-state unlocked set devices device Core-R4 device-type cli ned-id cisco-iosxr-cli-7.24 set devices device Core-R4 trace raw set devices device PIOSXR-0 authgroup iosxr_authgroup address 172.16.1.35 port 830 state admin-state unlocked set devices device PIOSXR-0 device-type cli ned-id cisco-iosxr-cli-7.24 set devices device PIOSXR-0 trace raw set devices device PIOSXR-1 authgroup iosxr_authgroup address 172.16.1.36 port 22 state admin-state unlocked set devices device PIOSXR-1 device-type cli ned-id cisco-iosxr-cli-7.24 set devices device PIOSXR-1 trace raw commit



Run the following commands: request devices fetch-ssh-host-keys request devices connect request devices sync-from

16.1 Use Cases

This section covers use cases for the various models and their implementations in T-SDN FPs.

16.1.1 Use Case 1: Instantiating Example L3VPN over SR-TE for Color 30

L3VPN allows you to associate a SR-TE policy to instantiate the service. Define and set the path for the color in the policy. For more information about creating Flat L3VPN service and creating SR-Policies, see chapter Configuration in this documentation.

This use case shows the end-to-end workflow to instantiate a Flat-L3VPN service over SR-TE for color 30. The following diagram shows the required tasks for this use case.

The detailed workflow includes:

1. Create and verify SR-Policy with Metric-TE for color 30.

2. Create and verify L3VPN-Route-policy for color 30.

3. Create and verify Flat-L3VPN service.

4. Associate Route Policy to L3VPN service and verify the same.

The following procedure shows how to instantiate L3VPN over SR-TE for color 30.



To instantiate example L3VPN over SR-TE for color 30:

1. Create a SR-policy with metric TE for color 30.

<config xmlns="http://tail-f.com/ns/config/1.0"> <sr-te xmlns="http://cisco.com/ns/nso/cfp/cisco-tsdn-sr-te"> <policies xmlns="http://cisco.com/ns/nso/cfp/cisco-tsdn-sr-te-sr-policies"> <policy> <name>sr-flex</name> <head-end> <name>PE-R5</name> </head-end> <tail-end>100.100.100.6</tail-end> <color>30</color> <binding-sid>169001</binding-sid> <path> <preference>1</preference> <dynamic> <metric-type>te</metric-type> </dynamic> </path> </policy> </policies> </sr-te> </config>

2. Display the plan and verify the policy is in the ready-reached state.

3. Get modifications for the policy to view if the configuration is pushed to the device. For more information on the get-modifications action, see chapter Working with Action Commands in this documentation.

admin@ncs# sr-te cisco-sr-te-cfp-sr-policies:policies policy sr-flex action get-modifications outformat cli message devices { device PE-R5 { config { cisco-ios-xr:segment-routing { traffic-eng { + policy srte_c_30_ep_100.100.100.6 { + binding-sid { + mpls 169001; + } + color { + value 30; + end-point { + ipv4 100.100.100.6; + } + }



+ candidate-paths { + preference 1 { + dynamic { + metric { + type te; + } + } + } + } + } } } } } }

4. Create L3VPN route policy for color 30. <l3vpn-route-policy xmlns="http://cisco.com/ns/nso/fp/examples/cisco-tsdn-flat-L3vpn"> <name>L3-color-30</name> <color> <id>30</id> <ipv4> <prefix>122.122.122.1/32</prefix> *** Loopback interface on PE-R5, created as part of L3VPN *** </ipv4> </color> </l3vpn-route-policy>

5. Create the flat-L3VPN service. <flat-L3vpn xmlns="http://cisco.com/ns/nso/fp/examples/cisco-tsdn-flat-L3vpn"> <name>L3vpn-flex</name> <endpoint> <endpoint-name>PE-R5</endpoint-name> <access-pe>PE-R5</access-pe> <if-type>Loopback</if-type> <if-id>4</if-id> <pe-ip-addr>122.122.122.1/32</pe-ip-addr> <as-no>1</as-no> <ce-pe-prot> <e-bgp> <neighbor-ipv4>123.123.123.2</neighbor-ipv4> <remote-as-ipv4>65009</remote-as-ipv4> </e-bgp> </ce-pe-prot> <vrf> <vrf-definition>L3VPN-flex</vrf-definition> <route-distinguisher>11:11</route-distinguisher> <address-family> <address-family>ipv4</address-family> <vpn-target> <rt-value>200:200</rt-value> <rt-type>both</rt-type>



</vpn-target> <vpn-target> <rt-value>200:201</rt-value> <rt-type>export</rt-type> </vpn-target> <vpn-target> <rt-value>200:202</rt-value> <rt-type>import</rt-type> </vpn-target> </address-family> </vrf> </endpoint> </flat-L3vpn>

6. Associate the route policy to the L3VPN service. This configuration data is deployed on the device when the flat-L3VPN service is applied with this route policy.

<flat-L3vpn xmlns="http://cisco.com/ns/nso/fp/examples/cisco-tsdn-flat-L3vpn"> <name>L3vpn-flex</name> <endpoint> <endpoint-name>PE-R5</endpoint-name> <sr-te> <route-policy>L3-color-30</route-policy> </sr-te> </endpoint> </flat-L3vpn>

7. Display the plan status for the L3VPN service and verify the service is successfully deployed.

8. Get modifications for the L3VPN service and verify the route policy is applied to the device PE-R5. admin@ncs# flat-L3vpn L3vpn-flex action get-modifications outformat cli message devices { device PE-R5 { config { cisco-ios-xr:vrf { + vrf-list L3VPN-flex { + address-family {



+ ipv4 { + unicast { + import { + route-target { + address-list 200:200; + address-list 200:202; + } + } + export { + route-policy SET_COLORv4_L3-color-30; + route-target { + address-list 200:200; + address-list 200:201; + } + } + } + } + } + } } cisco-ios-xr:interface { + Loopback 4 { + description "T-SDN Interface"; + vrf L3VPN-flex; + ipv4 { + address { + ip 122.122.122.1; + mask 255.255.255.255; + } + } + } } cisco-ios-xr:extcommunity-set { + opaque COLOR_30 { + set 30; + } } cisco-ios-xr:route-policy PASS_ALL { - value " pass\r\n"; + value pass; } + cisco-ios-xr:route-policy SET_COLORv4_L3-color-30 { + value " if destination in (122.122.122.1/32) then\r\n set extcommunity color COLOR_30\r\n endif\r\n"; + } cisco-ios-xr:router { bgp { bgp-no-instance 1 { + vrf L3VPN-flex { + rd 11:11; + address-family { + ipv4 { + unicast { + } + }



+ } + neighbor 123.123.123.2 { + remote-as 65009; + address-family { + ipv4 { + unicast { + route-policy in { + name PASS_ALL; + } + route-policy out { + name PASS_ALL; + } + } + } + } + } + } } } } }

9. Verify the status of Segment Routing Traffic Engineering-Policy Admin and Operational are up. This indicates the successful instantiation of example L3VPN service over SR-TE for color 30. admin@ncs# devices device PE-R5 live-status exec show segment-routing traffic-eng policy result Tue May 5 23:23:07.909 UTC SR-TE policy database --------------------- Color: 30, End-point: 100.100.100.6 Name: srte_c_30_ep_100.100.100.6 Status: Admin: up Operational: up for 02:45:29 (since May 5 20:37:38.468) Candidate-paths: Preference: 1 (configuration) (active) Name: srte_c_30_ep_100.100.100.6 Requested BSID: 169001 Dynamic (valid) Metric Type: TE, Path Accumulated Metric: 30 24005 [Adjacency-SID, 20.20.10.5 - 20.20.10.6] 24003 [Adjacency-SID, 20.20.10.17 - 20.20.10.18] 24005 [Adjacency-SID, 20.20.10.30 - 20.20.10.29] Attributes: Binding SID: 169001 Forward Class: 0 Steering BGP disabled: no IPv6 caps enable: yes RP/0/RP0/CPU0:PE-R5#



16.1.2 Use Case 2: Flat- L3VPN Route Policy for Color 20 by Using SR ODN with Flex Algo

This use case discusses how to create and instantiate L3VPN service between two devices for color 20. It discusses how to use the SR-ODN template for the color for which an on-demand policy instantiation is desired.

The following diagram helps to understand the use case. The two devices - device 5 and device 6 use two loopback interfaces for each device with IP addresses 122.122.122.1 and 123.123.123.1 respectively on the same VIRL L3VPN-T-SDN. Configure an ODN template for the color 20 for which to instantiate the on-demand policy. Flex algo slices the network to define the paths for the source and the destination traffic. For the color 20, flex algo assigns the path 128 from device 5 and path 129 from device 6.

For more information about creating L3VPN service and SR-ODN service, see chapter Configuration in this documentation. The following diagram shows the required tasks for this use case.




1. Create and verify SR-Settings service to set up Flex Algo on the core and PE devices.

2. Create and verify SR-ODN service.

3. Create L3VPN route policy.

4. Create Flat-L3VPN service.


6. Perform a self-test on L3VPN service.

To create a flat L3VPN route policy for color 20 by using SR-ODN with Flex Algo:

1. Create SR-Settings service to setup Flex Algo on core and PE devices. <config xmlns="http://tail-f.com/ns/config/1.0"> <sr-setting xmlns="http://cisco.com/ns/nso/fp/examples/cisco-tsdn-sr-te-settings"> <name>SR-SET-Flex-ALGO-ALL</name> <node> <name>Core-R1</name> <isis> <instance-name>1</instance-name> <loopback> <id>0</id> <prefix-sid> <absolute>16001</absolute> </prefix-sid> </loopback> <flex-algo> <name>128</name> <advertise-definition/> <algorithm-prefix-sid> <absolute>16801</absolute> </algorithm-prefix-sid> </flex-algo> </isis> </node> <node> <name>Core-R2</name> <isis> <instance-name>1</instance-name> <loopback> <id>0</id> <prefix-sid> <absolute>16002</absolute> </prefix-sid> </loopback> <flex-algo> <name>128</name> <advertise-definition/> <algorithm-prefix-sid> <absolute>16802</absolute>



</algorithm-prefix-sid> </flex-algo> </isis> </node> <node> <name>Core-R3</name> <isis> <instance-name>1</instance-name> <loopback> <id>0</id> <prefix-sid> <absolute>16003</absolute> </prefix-sid> </loopback> <flex-algo> <name>129</name> <advertise-definition/> <algorithm-prefix-sid> <absolute>16903</absolute> </algorithm-prefix-sid> </flex-algo> </isis> </node> <node> <name>Core-R4</name> <isis> <instance-name>1</instance-name> <loopback> <id>0</id> <prefix-sid> <absolute>16004</absolute> </prefix-sid> </loopback> <flex-algo> <name>129</name> <advertise-definition/> <algorithm-prefix-sid> <absolute>16904</absolute> </algorithm-prefix-sid> </flex-algo> </isis> </node> <node> <name>PE-R5</name> <isis> <instance-name>1</instance-name> <loopback> <id>0</id> <prefix-sid> <absolute>16005</absolute> </prefix-sid> </loopback> <flex-algo> <name>128</name> <advertise-definition/> <algorithm-prefix-sid> <absolute>16805</absolute> </algorithm-prefix-sid> </flex-algo> <flex-algo> <name>129</name>



<advertise-definition/> <algorithm-prefix-sid> <absolute>16905</absolute> </algorithm-prefix-sid> </flex-algo> </isis> </node> <node> <name>PE-R6</name> <isis> <instance-name>1</instance-name> <loopback> <id>0</id> <prefix-sid> <absolute>16006</absolute> </prefix-sid> </loopback> <flex-algo> <name>128</name> <advertise-definition/> <algorithm-prefix-sid> <absolute>16806</absolute> </algorithm-prefix-sid> </flex-algo> <flex-algo> <name>129</name> <advertise-definition/> <algorithm-prefix-sid> <absolute>16906</absolute> </algorithm-prefix-sid> </flex-algo> </isis> </node> </sr-setting> </config>

2. Display the plan for the SR-Settings service and verify the service is deployed.

3. Get modifications for the SR-Settings service and verify the configuration is pushed to the core and PE devices. admin@ncs# sr-setting SR-SET-Flex-ALGO-ALL action get-modifications outformat cli



message devices { device Core-R1 { config { cisco-ios-xr:router { isis { tag 1 { + flex-algo 128 { + advertise-definition; + } interface Loopback0 { address-family { ipv4 { unicast { prefix-sid { + absolute 16001; - index 1001; } } } } } } } } } } } devices { device Core-R2 { config { cisco-ios-xr:router { isis { tag 1 { + flex-algo 128 { + advertise-definition; + } interface Loopback0 { address-family { ipv4 { unicast { prefix-sid { + absolute 16002; - index 2001; } } } } } } } } } } } devices { device Core-R3 { config { cisco-ios-xr:router { isis { tag 1 { + flex-algo 129 { + advertise-definition; + } interface Loopback0 { address-family {



ipv4 { unicast { prefix-sid { + absolute 16003; - index 3001; } } } } } } } } } } } devices { device Core-R4 { config { cisco-ios-xr:router { isis { tag 1 { + flex-algo 129 { + advertise-definition; + } interface Loopback0 { address-family { ipv4 { unicast { prefix-sid { + absolute 16004; - index 4001; } } } } } } } } } } } devices { device PE-R5 { config { cisco-ios-xr:router { isis { tag 1 { + flex-algo 128 { + advertise-definition; + } + flex-algo 129 { + advertise-definition; + } interface Loopback0 { address-family { ipv4 { unicast { prefix-sid { + absolute 16005; - index 5001; } } } } }



} } } } } } devices { device PE-R6 { config { cisco-ios-xr:router { isis { tag 1 { + flex-algo 128 { + advertise-definition; + } + flex-algo 129 { + advertise-definition; + } interface Loopback0 { address-family { ipv4 { unicast { prefix-sid { + absolute 16006; - index 6001; } } } } } } } } } } }

4. Create and apply the SR-ODN template to assign color 20 the path 128 on PE-R5 and the path 129 on PE-R6. <config xmlns="http://tail-f.com/ns/config/1.0"> <sr-te xmlns="http://cisco.com/ns/nso/cfp/cisco-tsdn-sr-te"> <odn xmlns="http://cisco.com/ns/nso/cfp/cisco-tsdn-sr-te-

sr-odn"> <odn-template> <name>SR-Flex-Algo-PE-R5</name> <head-end> <name>PE-R5</name> </head-end> <color>20</color> <dynamic> <metric-type>igp</metric-type> <flex-alg>128</flex-alg> </dynamic> </odn-template> <odn-template> <name>SR-Flex-Algo-PE-R6</name> <head-end> <name>PE-R6</name> </head-end> <color>20</color> <dynamic> <metric-type>igp</metric-type> <flex-alg>129</flex-alg>



</dynamic> </odn-template> </odn> </sr-te> </config>

5. Display the SR ODN template plan to verify if the configuration is applied to the devices PE-R5 and PE-R6.

6. Get modifications for the SR ODN template and verify if the configuration is pushed to devices PE-R5 and PE-R6.

admin@ncs# sr-te cisco-sr-te-cfp-sr-odn:odn odn-template SR-Flex-Algo-PE-R5 action get-modifications message devices { device PE-R5 { config { cisco-ios-xr:segment-routing { traffic-eng { on-demand { + color 20 { + dynamic { + metric { + type igp; + } + sid-algorithm 128; + } + } } } } } } } admin@ncs# sr-te cisco-sr-te-cfp-sr-odn:odn odn-template SR-Flex-Algo-PE-R6 action get-modifications message devices { device PE-R6 { config { cisco-ios-xr:segment-routing { traffic-eng { on-demand { + color 20 {



+ dynamic { + metric { + type igp; + } + sid-algorithm 129; + } + } } } } } }

7. Create the L3VPN route policy for color 20 on devices PE-R5 and PE-R6. This configuration data is deployed on the device when flat L3VPN service is applied with this route policy. <config xmlns="http://tail-f.com/ns/config/1.0"> <l3vpn-route-policy xmlns="http://cisco.com/ns/nso/fp/examples/cisco-tsdn-flat-L3vpn"> <name>L3-color-20-PE-R5</name> <color> <id>20</id> <ipv4> <prefix>122.122.122.1/32</prefix> </ipv4> </color> </l3vpn-route-policy> <l3vpn-route-policy xmlns="http://cisco.com/ns/nso/fp/examples/cisco-tsdn-flat-L3vpn"> <name>L3-color-20-PE-R6</name> <color> <id>20</id> <ipv4> <prefix>123.123.123.1/32</prefix> </ipv4> </color> </l3vpn-route-policy> </config>

8. Create L3VPN service on devices PE-R5 and PE-R6. <config xmlns="http://tail-f.com/ns/config/1.0"> <flat-L3vpn xmlns="http://cisco.com/ns/nso/fp/examples/cisco-tsdn-flat-L3vpn"> <name>L3VPN-TSDN</name> <endpoint> <endpoint-name>PE-R5</endpoint-name> <access-pe>PE-R5</access-pe> <if-type>Loopback</if-type> <if-id>4</if-id> <pe-ip-addr>122.122.122.1/24</pe-ip-addr> <as-no>1</as-no> <ce-pe-prot> <e-bgp> <neighbor-ipv4>122.122.122.2</neighbor-ipv4> <remote-as-ipv4>65002</remote-as-ipv4> <update-source> <if-type>Loopback</if-type> <if-id>4</if-id> </update-source>



</e-bgp> </ce-pe-prot> <vrf> <vrf-definition>L3VPN-T-SDN</vrf-definition> <route-distinguisher>10:10</route-distinguisher> <address-family> <address-family>ipv4</address-family> <redistribute-connected/> <metric>2</metric> <vpn-target> <rt-value>110:110</rt-value> <rt-type>both</rt-type> </vpn-target> </address-family> </vrf> <sr-te> <route-policy>L3-color-20-PE-R5</route-policy> </sr-te> </endpoint> <endpoint> <endpoint-name>PE-R6</endpoint-name> <access-pe>PE-R6</access-pe> <if-type>Loopback</if-type> <if-id>4</if-id> <pe-ip-addr>123.123.123.1/24</pe-ip-addr> <as-no>1</as-no> <ce-pe-prot> <e-bgp> <neighbor-ipv4>123.123.123.2</neighbor-ipv4> <remote-as-ipv4>65003</remote-as-ipv4> <update-source> <if-type>Loopback</if-type> <if-id>4</if-id> </update-source> </e-bgp> </ce-pe-prot> <vrf> <vrf-definition>L3VPN-T-SDN</vrf-definition> <route-distinguisher>10:10</route-distinguisher> <address-family> <address-family>ipv4</address-family> <redistribute-connected/> <metric>2</metric> <vpn-target> <rt-value>110:110</rt-value> <rt-type>both</rt-type> </vpn-target> </address-family> </vrf> <sr-te> <route-policy>L3-color-20-PE-R6</route-policy> </sr-te> </endpoint> </flat-L3vpn> </config>

9. Associate the route policy to the L3VPN service on the devices PE-R5 and PE-R6. <config xmlns="http://tail-f.com/ns/config/1.0">



<flat-L3vpn xmlns="http://cisco.com/ns/nso/fp/examples/cisco-tsdn-flat-L3vpn"> <name>L3VPN-TSDN</name> <endpoint> <endpoint-name>PE-R5</endpoint-name> <sr-te> <route-policy>L3-color-20-PE-R5</route-policy> </sr-te> </endpoint> <endpoint> <endpoint-name>PE-R6</endpoint-name> <access-pe>PE-R6</access-pe> <sr-te> <route-policy>L3-color-20-PE-R6</route-policy> </sr-te> </endpoint> </flat-L3vpn> </config>

10. Verify the plan for L3VPN service. Make sure the services are ready reached and type-self state-ready is in reached status.

11. Get modifications on the L3VPN service to verify the configuration is applied on devices PE-R5 and PE-R6.

admin@ncs# flat-L3vpn L3VPN-TSDN action get-modifications outformat cli message devices { device PE-R5 { config { cisco-ios-xr:vrf { + vrf-list L3VPN-T-SDN { + address-family { + ipv4 { + unicast { + import { + route-target { + address-list 110:110; + } + } + export { + route-policy SET_COLORv4_L3-color-20-PE-R5; + route-target { + address-list 110:110; + } + } + } + } + } + }



} cisco-ios-xr:interface { + Loopback 4 { + description "T-SDN Interface"; + vrf L3VPN-T-SDN; + ipv4 { + address { + ip 122.122.122.1; + mask 255.255.255.0; + } + } + } } cisco-ios-xr:extcommunity-set { + opaque COLOR_20 { + set 20; + } } + cisco-ios-xr:route-policy PASS_ALL { + value pass; + } + cisco-ios-xr:route-policy SET_COLORv4_L3-color-20-PE-R5 { + value " if destination in (122.122.122.1/32) then\r\n set extcommunity color COLOR_20\r\n endif\r\n"; + } cisco-ios-xr:router { bgp { bgp-no-instance 1 { + vrf L3VPN-T-SDN { + rd 10:10; + address-family { + ipv4 { + unicast { + redistribute { + connected { + metric 2; + } + } + } + } + } + neighbor 122.122.122.2 { + remote-as 65002; + update-source { + Loopback 4; + } + address-family { + ipv4 { + unicast { + route-policy in { + name PASS_ALL; + } + route-policy out { + name PASS_ALL; + } + } + } + } + } + } } } } } } }



devices { device PE-R6 { config { cisco-ios-xr:vrf { + vrf-list L3VPN-T-SDN { + address-family { + ipv4 { + unicast { + import { + route-target { + address-list 110:110; + } + } + export { + route-policy SET_COLORv4_L3-color-20-PE-R6; + route-target { + address-list 110:110; + } + } + } + } + } + } } cisco-ios-xr:interface { + Loopback 4 { + description "T-SDN Interface"; + vrf L3VPN-T-SDN; + ipv4 { + address { + ip 123.123.123.1; + mask 255.255.255.0; + } + } + } } cisco-ios-xr:extcommunity-set { + opaque COLOR_20 { + set 20; + } } + cisco-ios-xr:route-policy PASS_ALL { + value pass; + } + cisco-ios-xr:route-policy SET_COLORv4_L3-color-20-PE-R6 { + value " if destination in (123.123.123.1/32) then\r\n set extcommunity color COLOR_20\r\n endif\r\n"; + } cisco-ios-xr:router { bgp { bgp-no-instance 1 { + vrf L3VPN-T-SDN { + rd 10:10; + address-family { + ipv4 { + unicast { + redistribute { + connected { + metric 2; + } + } + } + } + } + neighbor 123.123.123.2 {



+ remote-as 65003; + update-source { + Loopback 4; + } + address-family { + ipv4 { + unicast { + route-policy in { + name PASS_ALL; + } + route-policy out { + name PASS_ALL; + } + } + } + } + } + } } } } } } }

12. Perform self-test on L3VPN service to ensure the service is set up and both the PE devices are able to ping on the loopback interfaces (Loopback-4) created in L3VPN service. admin@ncs# flat-L3vpn L3VPN-TSDN action self-test status success message [('PE-R6', 'PE-R5', 'success', 'Success rate is 100 percent (5/5)'), ('PE-R5', 'PE-R6', 'success', 'Success rate is 100 percent (5/5)')] admin@ncs#

16.1.3 Use Case 3: Instantiating L2VPN over SR-TE for Color 40

L2VPN allows dissimilar systems to be connected in a way that it appears as if they are connected to a common LAN segment. For more information about how to create L2VPN service, see chapter Configuration in this documentation.

This use case discusses how to instantiate L2VPN over SR-TE for color 40. The following diagram shows the required tasks for this use case.




1. Create and verify SR-Policy.

2. Create L2VPN route policy.

3. Create Flat-L2VPN service.


5. Perform a self-test on the L2VPN service.

To instantiate L2VPN over SR-TE for color 40:

1. Create SR-policy with metric-latency for color 40 on devices PE-R5 and PE-R6. <config xmlns="http://tail-f.com/ns/config/1.0"> <sr-te xmlns="http://cisco.com/ns/nso/cfp/cisco-tsdn-sr-te"> <policies xmlns="http://cisco.com/ns/nso/cfp/cisco-tsdn-sr-te-sr-policies"> <policy> <name>sr-policy-color-40-PE-R5</name> <head-end> <name>PE-R5</name> </head-end> <tail-end>100.100.100.6</tail-end> <color>40</color> <binding-sid>40</binding-sid> <path> <preference>2</preference> <dynamic> <metric-type>latency</metric-type> </dynamic> </path> </policy> <policy> <name>sr-policy-color-40-PE-R6</name> <head-end> <name>PE-R6</name> </head-end> <tail-end>100.100.100.5</tail-end> <color>40</color> <binding-sid>40</binding-sid> <path> <preference>2</preference> <dynamic> <metric-type>latency</metric-type> </dynamic> </path> </policy> </policies> </sr-te> </config>



2. Display the plan for the policy and verify the policy status is reached.

3. Get modifications for the SR-TE policy and verify the configuration is pushed to the devices.

admin@ncs#admin@ncs# sr-te cisco-sr-te-cfp-sr-policies:policies policy sr-policy-color-40-PE-R5 action get-modifications outformat cli message devices { device PE-R5 { config { cisco-ios-xr:segment-routing { traffic-eng { + policy srte_c_40_ep_100.100.100.6 { + binding-sid { + mpls 40; + } + color { + value 40; + end-point { + ipv4 100.100.100.6; + } + } + candidate-paths { + preference 2 { + dynamic { + metric { + type latency; + } + } + } + } + } } } } } } admin@ncs# sr-te cisco-sr-te-cfp-sr-policies:policies policy sr-policy-color-40-PE-R6 action get-modifications outformat cli message devices { device PE-R6 { config {



cisco-ios-xr:segment-routing { traffic-eng { + policy srte_c_40_ep_100.100.100.5 { + binding-sid { + mpls 40; + } + color { + value 40; + end-point { + ipv4 100.100.100.5; + } + } + candidate-paths { + preference 2 { + dynamic { + metric { + type latency; + } + } + } + } + } } } } } }

4. Create L2VPN route policy for color 40. <config xmlns="http://tail-f.com/ns/config/1.0"> <l2vpn-route-policy xmlns="http://cisco.com/ns/nso/fp/examples/cisco-tsdn-flat-L2vpn"> <name>Local_RP-Color-40</name> <color> <id>40</id> <ipv4> <rd>100.100.100.5:3</rd> *** Loopback0 ip on PE-R5 *** <rd>100.100.100.6:3</rd> *** Loopback0 ip on PE-R6 *** </ipv4> </color> </l2vpn-route-policy> <l2vpn-route-policy xmlns="http://cisco.com/ns/nso/fp/examples/cisco-tsdn-flat-L2vpn"> <name>Remote_RP-Color-40</name> <color> <id>40</id> <ipv4> <rd>100.100.100.5:3</rd> <rd>100.100.100.6:3</rd> </ipv4> </color> </l2vpn-route-policy> </config>

5. Create flat L2VPN service. <config xmlns="http://tail-f.com/ns/config/1.0"> <flat-L2vpn xmlns="http://cisco.com/ns/nso/fp/examples/cisco-tsdn-flat-L2vpn">



<name>L2VPN-Service</name> <service-type>p2p</service-type> <flat-L2vpn-p2p> <pw-id>100</pw-id> <local-site> <pe>PE-R5</pe> <if-type>GigabitEthernet</if-type> <if-id>0/0/0/2</if-id> <if-description>L2vpn-p2p-flat-remote</if-description> <if-encap>dot1q</if-encap> <vlan-id>100</vlan-id> <sub-if-id>100</sub-if-id> <xconnect-group-name>TSDN-L2vpn</xconnect-group-name> <xconnect-encapsulation>mpls</xconnect-encapsulation> <p2p-name>p2p-flat</p2p-name> <control-word>no</control-word> <pw-class>TSDN-L2vpn-p2p</pw-class> <xconnect-local-ip>100.100.100.5</xconnect-local-ip> <xconnect-remote-ip>100.100.100.6</xconnect-remote-ip> <mpls-local-label>101</mpls-local-label> <mpls-remote-label>202</mpls-remote-label> </local-site> <remote-site> <pe>PE-R6</pe> <if-type>GigabitEthernet</if-type> <if-id>0/0/0/1</if-id> <if-description>L2vpn-p2p-flat-remote</if-description> <if-encap>dot1q</if-encap> <vlan-id>100</vlan-id> <sub-if-id>100</sub-if-id> <xconnect-group-name>TSDN-L2vpn</xconnect-group-name> <p2p-name>p2p-flat</p2p-name> <pw-class>TSDN-L2vpn-p2p</pw-class> </remote-site> </flat-L2vpn-p2p> </flat-L2vpn> </config>

6. Associate the route policy to L2VPN service. <flat-L2vpn xmlns="http://cisco.com/ns/nso/fp/examples/cisco-tsdn-flat-L2vpn"> <name>L2VPN-Service</name> <flat-L2vpn-p2p> <local-site> <sr-te> <preferred-path> <policy>Local_RP-Color-40</policy> </preferred-path> </sr-te> </local-site> <remote-site> <sr-te> <preferred-path> <policy>Remote_RP-Color-40</policy> </preferred-path> </sr-te> </remote-site> </flat-L2vpn-p2p> </flat-L2vpn>



7. Verify the plan status for L2VPN service and verify the service is successfully deployed.

8. Get modifications for the L2VPN service verify the route policy is applied to the devices. admin@ncs# flat-L2vpn L2VPN-Service action get-modifications

message devices { device PE-R5 { config { cisco-ios-xr:interface { GigabitEthernet-subinterface { + GigabitEthernet 0/0/0/2.100 { + mode l2transport; + description L2vpn-p2p-flat-remote; + encapsulation { + dot1q { + vlan-id 100; + } + } + } } } cisco-ios-xr:l2vpn { + pw-class TSDN-L2vpn-p2p { + encapsulation { + mpls { + preferred-path { + sr-te { + policy Local_RP-Color-40; + } + } + } + } + } xconnect { + group TSDN-L2vpn { + p2p p2p-flat { + interface GigabitEthernet0/0/0/2.100; + neighbor 100.100.100.6 100 { + ip-version ipv4; + mpls { + static { + label { + local 101; + remote 202; + }



+ } + } + pw-class TSDN-L2vpn-p2p; + } + } + } } } } } } devices { device PE-R6 { config { cisco-ios-xr:interface { GigabitEthernet-subinterface { + GigabitEthernet 0/0/0/1.100 { + mode l2transport; + description L2vpn-p2p-flat-remote; + encapsulation { + dot1q { + vlan-id 100; + } + } + } } } + cisco-ios-xr:l2vpn { + pw-class TSDN-L2vpn-p2p { + encapsulation { + mpls { + preferred-path { + sr-te { + policy Remote_RP-Color-40; + } + } + } + } + } + xconnect { + group TSDN-L2vpn { + p2p p2p-flat { + interface GigabitEthernet0/0/0/1.100; + neighbor 100.100.100.5 100 { + ip-version ipv4; + mpls { + static { + label { + local 202; + remote 101; + } + } + } + pw-class TSDN-L2vpn-p2p; + } + } + } + } + } } } }



9. Perform self-test on L2VPN service to ensure the service is set up on both the PE devices. admin@ncs# flat-L3vpn flat-L2vpn L2VPN-Service action self-test status success message local-site: success. remote-site: success

10. Verify the status of Segment Routing Traffic Engineering-Policy Admin and Operational are up on both the devices. This indicates the successful instantiation of L2VPN service over SR-TE for color 40.

On PE-R5 admin@ncs# devices device PE-R5 live-status exec show segment-routing traffic-eng policy result Thu May 7 22:51:16.950 UTC SR-TE policy database --------------------- Color: 40, End-point: 100.100.100.6 Name: srte_c_40_ep_100.100.100.6 Status: Admin: up Operational: up for 00:46:56 (since May 7 22:04:20.933) Candidate-paths: Preference: 2 (configuration) (active) Name: srte_c_40_ep_100.100.100.6 Requested BSID: 40 Dynamic (valid) Metric Type: LATENCY, Path Accumulated Metric: 30 16006 [Prefix-SID, 100.100.100.6] Attributes: Binding SID: 40 Forward Class: 0 Steering BGP disabled: no IPv6 caps enable: yes RP/0/RP0/CPU0:PE-R5#

On PE-R6 admin@ncs# devices device PE-R5 live-status exec show segment-routing traffic-eng policy Thu May 7 22:52:22.823 UTC SR-TE policy database --------------------- Color: 40, End-point: 100.100.100.5 Name: srte_c_40_ep_100.100.100.5 Status: Admin: up Operational: up for 00:47:48 (since May 7 22:04:34.231) Candidate-paths:



Preference: 2 (configuration) (active) Name: srte_c_40_ep_100.100.100.5 Requested BSID: 40 Dynamic (valid) Metric Type: LATENCY, Path Accumulated Metric: 30 16005 [Prefix-SID, 100.100.100.5] Attributes: Binding SID: 40 Forward Class: 0 Steering BGP disabled: no IPv6 caps enable: yes

16.1.4 Instantiating SR-Policy with SR-PCE for Color 50

SR-PCE service helps set up path computation element related configuration information on devices. SR-PCE describes a set of procedures by which a Path Computation Client (PCC) can report and delegate control of a policy head-end. This use case discusses how to instantiate SR-PCE for color 50 on PE-R5 device. For more information on SR-PCE service, see chapter Configuration in this documentation.

SR-PCE is set up on the Core R2 device. Configure SR-Settings to enable PCC on all the devices in the network. The policy uses the metric IGP to instantiate the service. The head-end for the policy is device PE-R5 and the tail-end is PE-R6.



The following graphic shows the required tasks you must perform for this use case.


1. Create and verify SR-PCE service on the device.

2. Create and verify SR-Settings to enable PCC settings on all the devices.

3. Create and verify SR-policy with metric IGP for color 50.

4. Verify the policy operations and the path computed by PCE for color 50.

To instantiate SR-policy with SR-PCE for color 50:

1. Create SR-PCE service on core-R2 device. <config xmlns="http://tail-f.com/ns/config/1.0"> <sr-pce xmlns="http://cisco.com/ns/nso/fp/examples/cisco-tsdn-sr-te-pce"> <name>PCE-Core-R2</name> <node> <name>Core-R2</name> <pce> <address>100.100.100.2</address> <disjoint-path/> <timers> <reoptimization>600</reoptimization> <keepalive>20</keepalive> <minimum-peer-keepalive>21</minimum-peer-keepalive> </timers> <state-sync> <ipv4> <address>100.100.100.2</address> </ipv4> </state-sync> <backoff> <ratio>11</ratio> <difference>10</difference>



<threshold>12</threshold> </backoff> <segment-routing> <strict-sid-only/> <te-latency/> </segment-routing> </pce> </node> </sr-pce> </config>

2. Display the plan for the SR-PCE service and verify the service is in the reached status.

3. Get modifications for the SR-PCE service and verify the configuration is pushed to the core-R2 device. sr-pce PCE-Core-R2 action get-modifications outformat cli message devices { device Core-R2 { config { + cisco-ios-xr:pce { + address { + ipv4 100.100.100.2; + } + disjoint-path { + } + timers { + reoptimization 600; + keepalive 20; + minimum-peer-keepalive 21; + } + state-sync { + ipv4 100.100.100.2; + } + backoff { + ratio 11; + difference 10; + threshold 12; + } + segment-routing { + strict-sid-only; + te-latency; + } + } } } }



4. Create SR-Settings to enable PCC settings on all the devices. <config xmlns="http://tail-f.com/ns/config/1.0"> <sr-setting xmlns="http://cisco.com/ns/nso/fp/examples/cisco-tsdn-sr-te-settings"> <name>PCC_SETTINGS</name> <pcc> <pce> <address> <ipv4> <address>100.100.100.2</address> <precedence>1</precedence> </ipv4> </address> </pce> <report-all/> </pcc> <node> <name>Core-R1</name> </node> <node> <name>Core-R2</name> </node> <node> <name>Core-R3</name> </node> <node> <name>Core-R4</name> </node> <node> <name>PE-R5</name> </node> <node> <name>PE-R6</name> </node> </sr-setting> </config>

5. Display the plan for SR-Settings and verify the status is reached for all the devices.

6. Get modifications for SR-Settings to verify the PCC settings is pushed to the devices.



sr-setting PCC_SETTINGS action get-modifications message devices { device Core-R1 { config { cisco-ios-xr:segment-routing { traffic-eng { + pcc { + pce { + address { + ipv4 100.100.100.2 { + precedence 1; + } + } + } + report-all; + } } } } } } devices { device Core-R2 { config { cisco-ios-xr:segment-routing { traffic-eng { + pcc { + pce { + address { + ipv4 100.100.100.2 { + precedence 1; + } + } + } + report-all; + } } } } } } devices { device Core-R3 { config { cisco-ios-xr:segment-routing { traffic-eng { + pcc { + pce { + address { + ipv4 100.100.100.2 { + precedence 1; + } + } + } + report-all; + } } } } }



} devices { device Core-R4 { config { cisco-ios-xr:segment-routing { traffic-eng { pcc { pce { address { ipv4 100.100.100.2 { + precedence 1; } } } } } } } } } devices { device PE-R5 { config { cisco-ios-xr:segment-routing { traffic-eng { + pcc { + pce { + address { + ipv4 100.100.100.2 { + precedence 1; + } + } + } + report-all; + } } } } } } devices { device PE-R6 { config { cisco-ios-xr:segment-routing { traffic-eng { + pcc { + pce { + address { + ipv4 100.100.100.2 { + precedence 1; + } + } + } + report-all; + } } } } } }



7. Verify the PCE peer database to ensure PCC is enabled on all the devices in the network.

admin@ncs# devices device Core-R2 live-status exec show pce ipv4 peer result Fri May 8 00:08:52.700 UTC PCE's peer database: -------------------- Peer address: 100.100.100.1 State: Up Capabilities: Stateful, Segment-Routing, Update, Instantiation Peer address: 100.100.100.2 State: Up Capabilities: Stateful, Segment-Routing Peer address: 100.100.100.3 State: Up Capabilities: Stateful, Segment-Routing, Update, Instantiation Peer address: 100.100.100.4 State: Up Capabilities: Stateful, Segment-Routing, Update, Instantiation Peer address: 100.100.100.5 State: Up Capabilities: Stateful, Segment-Routing, Update, Instantiation Peer address: 100.100.100.6 State: Up Capabilities: Stateful, Segment-Routing, Update, Instantiation RP/0/RP0/CPU0:Core-R2# admin@ncs#

8. Create the SR-policy with metric IGP for color 50 on the PE-R5 device. <config xmlns="http://tail-f.com/ns/config/1.0"> <sr-te xmlns="http://cisco.com/ns/nso/cfp/cisco-tsdn-sr-te"> <policies xmlns="http://cisco.com/ns/nso/cfp/cisco-tsdn-sr-te-sr-policies"> <policy> <name>SR-Policy-PCE</name> <head-end> <name>PE-R5</name> </head-end> <tail-end>100.100.100.6</tail-end> <color>50</color> <binding-sid>25601</binding-sid> <path> <preference>100</preference> <dynamic> <metric-type>igp</metric-type> <pce/> </dynamic> </path> </policy> </policies> </sr-te> </config>



9. Display the plan status for the SR-TE policy and verify the policy is deployed. successfully.

10. Get modifications for the SR-policy with PCE for color 50 to verify the policy is enforced on the device PE-R5. sr-te cisco-sr-te-cfp-sr-policies:policies policy SR-Policy-PCE action get-modifications message devices { device PE-R5 { config { cisco-ios-xr:segment-routing { traffic-eng { + policy srte_c_50_ep_100.100.100.6 { + binding-sid { + mpls 25601; + } + color { + value 50; + end-point { + ipv4 100.100.100.6; + } + } + candidate-paths { + preference 100 { + dynamic { + pcep { + } + metric { + type igp; + } + } + } + } + } } } } } }

11. Verify the SR-TE policy operations. The status of Segment Routing Traffic Engineering-Policy Admin and Operational must be up. This indicates the successful instantiation of SR-PCE for color 50. admin@ncs# devices device Core-R2 live-status exec show pce lsp detail result Fri May 8 00:11:26.400 UTC PCE's tunnel database:



---------------------- PCC 100.100.100.5: Tunnel Name: cfg_srte_c_50_ep_100.100.100.6_discr_100 LSPs: LSP[0]: source 100.100.100.5, destination 100.100.100.6, tunnel ID 3, LSP ID 1 State: Admin up, Operation up Setup type: Segment Routing Binding SID: 25601 Maximum SID Depth: 10 Absolute Metric Margin: 0 Relative Metric Margin: 0% Bandwidth: signaled 0 kbps, applied 0 kbps PCEP information: PLSP-ID 0x3, flags: D:1 S:0 R:0 A:1 O:1 C:0 LSP Role: Single LSP State-sync PCE: None PCC: 100.100.100.5 LSP is subdelegated to: None Reported path: Metric type: IGP, Accumulated Metric 30 SID[0]: Adj, Label 24003, Address: local 20.20.10.1 remote 20.20.10.2 SID[1]: Adj, Label 24003, Address: local 20.20.10.13 remote 20.20.10.14 SID[2]: Adj, Label 24005, Address: local 20.20.10.25 remote 20.20.10.26 Computed path: (Local PCE) ---------------> Sent to PE-R5. Computed Time: Fri May 08 00:08:22 UTC 2020 (00:03:04 ago) Metric type: IGP, Accumulated Metric 30 SID[0]: Adj, Label 24003, Address: local 20.20.10.1 remote 20.20.10.2 SID[1]: Adj, Label 24003, Address: local 20.20.10.13 remote 20.20.10.14 SID[2]: Adj, Label 24005, Address: local 20.20.10.25 remote 20.20.10.26 Recorded path: None Disjoint Group Information: None RP/0/RP0/CPU0:Core-R2#

12. Verify the path computed by PCE for color 50 on the device PE-R5.

admin@ncs# devices device PE-R5 live-status exec show segment-routing traffic-eng policy color 50 result Fri May 8 00:13:26.922 UTC SR-TE policy database --------------------- Color: 50, End-point: 100.100.100.6 Name: srte_c_50_ep_100.100.100.6 Status: Admin: up Operational: up for 00:17:50 (since May 7 23:55:36.110)



Candidate-paths: Preference: 100 (configuration) (active) Name: srte_c_50_ep_100.100.100.6 Requested BSID: 25601 PCC info: Symbolic name: cfg_srte_c_50_ep_100.100.100.6_discr_100 PLSP-ID: 3 Dynamic (pce 100.100.100.2) (valid) ---------------> Learnt by PCE Metric Type: IGP, Path Accumulated Metric: 30 24003 [Adjacency-SID, 20.20.10.1 - 20.20.10.2] 24003 [Adjacency-SID, 20.20.10.13 - 20.20.10.14] 24005 [Adjacency-SID, 20.20.10.25 - 20.20.10.26] Attributes: Binding SID: 25601 Forward Class: 0 Steering BGP disabled: no IPv6 caps enable: yes RP/0/RP0/CPU0:PE-R5# admin@ncs#

cisco nso transport sdn function pack bundle 1.0 …...applicable to t-sdn fp bundle version 1.0.0....

Documents