Cisco Network Convergence System 560 Series Routers Configuration Guide
Mainos
Mainos
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers,
IOS XR Release 7.6.x
First Published: 2022-03-30
Americas Headquarters
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA http://www.cisco.com
Tel: 408 526-4000
800 553-NETS (6387)
Fax: 408 527-0883
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.
All printed copies and duplicate soft copies of this document are considered uncontrolled. See the current online version for the latest version.
Cisco has more than 200 offices worldwide. Addresses and phone numbers are listed on the Cisco website at www.cisco.com/go/offices.
The documentation set for this product strives to use bias-free language. For purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on standards documentation, or language that is used by a referenced third-party product.
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: https://www.cisco.com/c/en/us/about/legal/trademarks.html
. 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)
© 2022 Cisco Systems, Inc. All rights reserved.
C O N T E N T S
C H A P T E R 1
C H A P T E R 2
Workflow for Deploying Segment Routing 3
Configure Segment Routing over IPv6 (SRv6) 5
Segment Routing over IPv6 Overview 5
SRv6 uSID Allocation Within a uSID Block 12
SRv6 Endpoint Behaviors Associated with uSID 13
SRv6 uSID in Action - Example 13
Usage Guidelines and Limitations 18
Configuring SRv6 under IS-IS 25
Configuring SRv6 Flexible Algorithm under IS-IS 26
Configuring SRv6 Locator Prefix Summarization 28
Configuring TI-LFA with SRv6 IS-IS 28
Configuring SRv6 IS-IS Microloop Avoidance 31
Configuring SRv6 BGP-Based Services 32
SRv6 Services: IPv4 BGP Global 58
SRv6 Services: IPv6 BGP Global 61
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
iii
Contents
C H A P T E R 3
C H A P T E R 4
C H A P T E R 5
SRv6 Services: IPv4 L3VPN Active-Standby Redundancy using Port-Active Mode 67
SRv6 Services for L3VPN Active-Standby Redundancy using Port-Active Mode: Operation 68
Configure SRv6 Services L3VPN Active-Standby Redundancy using Port-Active Mode 68
SRv6 Services: IPv4 L3VPN Active-Active Redundancy 72
SRv6 Services: EVPN VPWS — All-Active Multi-Homing 72
SRv6/MPLS L3 Service Interworking Gateway 76
SRv6/MPLS Dual-Connected PE 80
SRv6 SID Information in BGP-LS Reporting 82
SRv6 OAM — SID Verification 82
DHCPv4 Relay Agent and Proxy Support over SRv6 83
DHCPv6 Relay Agent Support over SRv6 84
Configure Segment Routing Global Block and Segment Routing Local Block 85
About the Segment Routing Global Block 85
About the Segment Routing Local Block 87
Understanding Segment Routing Label Allocation 88
Setup a Non-Default Segment Routing Global Block Range 91
Setup a Non-Default Segment Routing Local Block Range 92
Configure Segment Routing for IS-IS Protocol 95
Enabling Segment Routing for IS-IS Protocol 95
Configuring a Prefix-SID on the IS-IS Enabled Loopback Interface 97
Configuring an Adjacency SID 100
Manually Configure a Layer 2 Adjacency SID 102
Configuring Bandwidth-Based Local UCMP 105
Conditional Prefix Advertisement 107
Segment Routing ECMP-FEC Optimization 108
Configure Segment Routing for OSPF Protocol 111
Enabling Segment Routing for OSPF Protocol 111
Configuring a Prefix-SID on the OSPF-Enabled Loopback Interface 113
iv
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Contents
C H A P T E R 6
C H A P T E R 7
Segment Routing ECMP-FEC Optimization 115
Configure Segment Routing for BGP 117
Configure BGP Prefix Segment Identifiers 118
Segment Routing Egress Peer Engineering 119
Usage Guidelines and Limitations 119
Configure Segment Routing Egress Peer Engineering 119
Configuring Manual BGP-EPE Peering SIDs 121
Use Case: Configuring SR-EPE and BGP-LS 128
Configure BGP Proxy Prefix SID 130
BGP-LU Inter-AS Option-C Interworking with LDP and IGP SR-MPLS using Proxy BGP-SR 132
Usage Guidelines and Limitations 138
Instantiation of an SR Policy 138
On-Demand SR Policy – SR On-Demand Next-Hop 138
SR-ODN Configuration Steps 140
Configuring SR-ODN: Examples 142
Manually Provisioned SR Policy 171
Cumulative Metric Bounds (Delay-Bound Use-Case) 172
SR-TE BGP Soft Next-Hop Validation For ODN Policies 174
Configure SR Policy with Dynamic Path 180
Configure SR-TE Policy with Explicit Path 182
Configuring Explicit Path with Affinity Constraint Validation 184
Configure Explicit Path with Segment Protection-Type Constraint 187
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
v
Contents
C H A P T E R 8
C H A P T E R 9
Path Computation Element Protocol 188
Configure the Head-End Router as PCEP PCC 188
Configure SR-TE PCE Groups 193
Configure BGP SR Policy Address Family at SR-TE Head-End 198
Color-Only Automated Steering 201
Address-Family Agnostic Automated Steering 203
Per-Flow Automated Steering 203
Static Route over Segment Routing Policy 210
Policy-Based Tunnel Selection for SR-TE Policy 214
SR Policy Liveness Monitoring 216
Programming Non-Active Candidate Paths of an SR Policy 216
LDP over Segment Routing Policy 222
SR-TE MPLS Label Imposition Enhancement 225
SR-TE Reoptimization Timers 230
Segment Routing Tree Segment Identifier 233
Configure Segment Routing Tree-SID 237
Multicast VPN: Tree-SID MVPN With TI-LFA 240
Configure Segment Routing Path Computation Element 259
vi
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
C H A P T E R 1 0
C H A P T E R 1 1
C H A P T E R 1 2
Configure the Disjoint Policy (Optional) 263
SR-PCE Flexible Algorithm Multi-Domain Path Computation 266
Example: SR-PCE Flexible Algorithm Multi-Domain Path Computation Use Case 267
ACL Support for PCEP Connection 270
Inter-Domain Path Computation Using Redistributed SID 271
Example: Inter-Domain Path Computation Using Redistributed SID 272
PCE Support for MPLS-TE LSPs 273
Configuring the North-Bound API on SR-PCE 276
Configure Performance Measurement 279
Link Anomaly Detection with IGP Penalty 298
IP Endpoint Delay Measurement and Liveness Monitoring 299
Configuring IP Endpoint Performance Measurement 299
IP Endpoint Performance Measurement Use Cases 303
SR Policy End-to-End Delay Measurement 311
SR Policy Liveness Monitoring 318
Configure Topology-Independent Loop-Free Alternate (TI-LFA) 325
Usage Guidelines and Limitations 327
Configuring TI-LFA for IS-IS 328
Configuring TI-LFA for OSPF 330
TI-LFA Node and SRLG Protection: Examples 331
Configuring Global Weighted SRLG Protection 332
SR-MPLS over GRE as TI-LFA Backup Path 336
Example: SR-MPLS over GRE as TI-LFA Backup Path 339
Unlabeled IPv6 Traffic Protection 347
Configure Segment Routing Microloop Avoidance 351
Contents
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
vii
Contents
C H A P T E R 1 3
C H A P T E R 1 4
About Segment Routing Microloop Avoidance 351
Segment Routing Microloop Avoidance Limitations 351
Configure Segment Routing Microloop Avoidance for IS-IS 351
Configure Segment Routing Microloop Avoidance for OSPF 352
Configure Segment Routing Mapping Server 355
Segment Routing Mapping Server 355
Usage Guidelines and Restrictions 356
Segment Routing and LDP Interoperability 357
Example: Segment Routing LDP Interoperability 357
Configuring Mapping Server 358
Enable Mapping Advertisement 360
Configure Mapping Advertisement for IS-IS 361
Configure Mapping Advertisement for OSPF 362
Enabling Segment Routing Flexible Algorithm 365
Prerequisites for Flexible Algorithm 365
Building Blocks of Segment Routing Flexible Algorithm 365
Flexible Algorithm Definition 365
Flexible Algorithm Membership 366
Flexible Algorithm Definition Advertisement 366
Flexible Algorithm Link Attribute Advertisement 366
Flexible Algorithm Prefix-SID Advertisement 367
Calculation of Flexible Algorithm Path 367
Installation of Forwarding Entries for Flexible Algorithm Paths 368
Flexible Algorithm Prefix-SID Redistribution 368
Flexible Algorithm Prefix Metric 369
Configuring Flexible Algorithm 370
Flexible Algorithm Link Attribute Advertisement Behavior 372
Configuring Strict IS-IS ASLA Link Attribute 374
Configuring Flexible Algorithm-Specific TE Metric 374
Configuring Flexible Algorithm with Exclude SRLG Constraint 375
Example: Configuring IS-IS Flexible Algorithm 377
viii
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
C H A P T E R 1 5
Example: Configuring IS-IS Flexible Algorithm 377
Example: Configuring OSPF Flexible Algorithm 378
Example: Traffic Steering to Flexible Algorithm Paths 379
BGP Routes on PE – Color Based Steering 379
MPLS Ping and Traceroute for BGP and IGP Prefix-SID 387
Examples: MPLS Ping, Traceroute, and Tree Trace for Prefix-SID 388
MPLS LSP Ping and Traceroute Nil FEC Target 390
Examples: LSP Ping and Traceroute for Nil_FEC Target 390
Segment Routing Ping and Traceroute 392
Segment Routing Traceroute 394
Segment Routing Ping and Traceroute for Flexible Algorithm 397
Segment Routing Ping for Flexible Algorithm 397
Segment Routing Traceroute for Flexible Algorithm 398
Segment Routing over IPv6 OAM 398
Contents
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
ix
Contents x
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
C H A P T E R
1
About Segment Routing
This chapter introduces the concept of segment routing and provides a workflow for configuring segment routing.
•
•
•
•
Workflow for Deploying Segment Routing, on page 3
Scope
Segment routing is a method of forwarding packets on the network based on the source routing paradigm.
The source chooses a path and encodes it in the packet header as an ordered list of segments. Segments are an identifier for any type of instruction. For example, topology segments identify the next hop toward a destination. Each segment is identified by the segment ID (SID) consisting of a flat unsigned 20-bit integer.
Segments
Interior gateway protocol (IGP) distributes two types of segments: prefix segments and adjacency segments.
Each router (node) and each link (adjacency) has an associated segment identifier (SID).
• A prefix SID is associated with an IP prefix. The prefix SID is manually configured from the segment routing global block (SRGB) range of labels, and is distributed by IS-IS or OSPF. The prefix segment steers the traffic along the shortest path to its destination. A node SID is a special type of prefix SID that identifies a specific node. It is configured under the loopback interface with the loopback address of the node as the prefix.
A prefix segment is a global segment, so a prefix SID is globally unique within the segment routing domain.
• An adjacency segment is identified by a label called an adjacency SID, which represents a specific adjacency, such as egress interface, to a neighboring router. An adjacency SID can be allocated dynamically from the dynamic label range or configured manually from the segment routing local block (SRLB) range of labels. The adjacency SID is distributed by IS-IS or OSPF. The adjacency segment steers the traffic to a specific adjacency.
An adjacency segment is a local segment, so the adjacency SID is locally unique relative to a specific router.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
1
About Segment Routing
Need
By combining prefix (node) and adjacency segment IDs in an ordered list, any path within a network can be constructed. At each hop, the top segment is used to identify the next hop. Segments are stacked in order at the top of the packet header. When the top segment contains the identity of another node, the receiving node uses equal cost multipaths (ECMP) to move the packet to the next hop. When the identity is that of the receiving node, the node pops the top segment and performs the task required by the next segment.
Dataplane
Segment routing can be directly applied to the Multiprotocol Label Switching (MPLS) architecture with no change in the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. The related label is popped from the stack, after the completion of a segment.
Services
Segment Routing integrates with the rich multi-service capabilities of MPLS, including Layer 3 VPN (L3VPN),
Virtual Private Wire Service (VPWS), Virtual Private LAN Service (VPLS), and Ethernet VPN (EVPN).
Segment Routing for Traffic Engineering
Segment routing for traffic engineering (SR-TE) takes place through a policy between a source and destination pair. Segment routing for traffic engineering 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. The destination is unaware of the presence of the policy.
Need
With segment routing for traffic engineering (SR-TE), the network no longer needs to maintain a per-application and per-flow state. Instead, it simply obeys the forwarding instructions provided in the packet.
SR-TE utilizes network bandwidth more effectively than traditional MPLS-TE networks by using ECMP at every segment level. It uses a single intelligent source and relieves remaining routers from the task of calculating the required path through the network.
Benefits
• Ready for SDN : Segment routing was built for SDN and is the foundation for Application Engineered
Routing (AER). SR prepares networks for business models, where applications can direct network behavior. SR provides the right balance between distributed intelligence and centralized optimization and programming.
• Minimal configuration : Segment routing for TE requires minimal configuration on the source router.
• Load balancing : Unlike in RSVP-TE, load balancing for segment routing can take place in the presence of equal cost multiple paths (ECMPs).
• Supports Fast Reroute (FRR) : Fast reroute enables the activation of a pre-configured backup path within 50 milliseconds of path failure.
2
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
About Segment Routing
Workflow for Deploying Segment Routing
• Plug-and-Play deployment : Segment routing policies are interoperable with existing MPLS control and data planes and can be implemented in an existing deployment.
Workflow for Deploying Segment Routing
Follow this workflow to deploy segment routing.
1.
Configure the Segment Routing Global Block (SRGB)
2.
Enable Segment Routing and Node SID for the IGP
3.
Configure Segment Routing for BGP
4.
Configure the SR-TE Policy
5.
Configure the SR-PCE
6.
Configure TI-LFA and Microloop Avoidance
7.
Configure the Segment Routing Mapping Server
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
3
Workflow for Deploying Segment Routing
About Segment Routing
4
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
C H A P T E R
2
Configure Segment Routing over IPv6 (SRv6)
Segment Routing for IPv6 (SRv6) is the implementation of Segment Routing over the IPv6 dataplane.
•
Segment Routing over IPv6 Overview, on page 5
•
SRv6 Micro-Segment (uSID), on page 10
•
Usage Guidelines and Limitations, on page 18
•
•
Configuring SRv6 under IS-IS, on page 25
•
Configuring SRv6 Flexible Algorithm under IS-IS, on page 26
•
Configuring SRv6 Locator Prefix Summarization, on page 28
•
Configuring TI-LFA with SRv6 IS-IS, on page 28
•
Configuring SRv6 IS-IS Microloop Avoidance, on page 31
•
Configuring SRv6 BGP-Based Services, on page 32
•
SRv6 Services: IPv4 L3VPN Active-Standby Redundancy using Port-Active Mode, on page 67
•
SRv6 Services: IPv4 L3VPN Active-Active Redundancy , on page 72
•
SRv6 Services: EVPN VPWS — All-Active Multi-Homing , on page 72
•
SRv6/MPLS L3 Service Interworking Gateway, on page 76
•
SRv6/MPLS Dual-Connected PE, on page 80
•
SRv6 SID Information in BGP-LS Reporting, on page 82
•
SRv6 OAM — SID Verification, on page 82
•
DHCPv4 Relay Agent and Proxy Support over SRv6, on page 83
•
DHCPv6 Relay Agent Support over SRv6, on page 84
Segment Routing over IPv6 Overview
Segment Routing (SR) can be applied on both MPLS and IPv6 data planes. Segment Routing over IPv6 (SRv6) extends Segment Routing support with IPv6 data plane.
In an SR-MPLS enabled network, an MPLS label represents an instruction. The source nodes programs the path to a destination in the packet header as a stack of labels.
SRv6 introduces the Network Programming framework that enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header. Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier
(SID) in the packet. The SRv6 Network Programming framework is defined in IETF RFC 8986 SRv6 Network
Programming .
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
5
Configure Segment Routing over IPv6 (SRv6)
Segment Routing over IPv6 Overview
In SRv6, an IPv6 address represents an instruction. SRv6 uses a new type of IPv6 Routing Extension Header, called the Segment Routing Header (SRH), in order to encode an ordered list of instructions. The active segment is indicated by the destination address of the packet, and the next segment is indicated by a pointer in the SRH.
Figure 1: Network Program in the Packet Header
The SRv6 SRH is documented in IETF RFC IPv6 Segment Routing Header (SRH) .
The SRH is defined as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Entry | Flags | Tag |
|
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
Segment List[0] (128-bit IPv6 address) |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
...
| |
|
|
|
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Segment List[n] (128-bit IPv6 address)
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
//
//
//
Optional Type Length Value objects (variable)
//
//
//
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following list explains the fields in SRH:
• Next header—Identifies the type of header immediately following the SRH.
• Hdr Ext Len (header extension length)—The length of the SRH in 8-octet units, not including the first
8 octets.
6
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing over IPv6 (SRv6)
Segment Routing over IPv6 Overview
• Segments left—Specifies the number of route segments remaining. That means, the number of explicitly listed intermediate nodes still to be visited before reaching the final destination.
• Last Entry—Contains the index (zero based) of the last element of the segment list.
• Flags— Contains 8 bits of flags.
• Tag—Tag a packet as part of a class or group of packets like packets sharing the same set of properties.
• Segment list—128-bit IPv6 addresses representing the n th segment in the segment list. The segment list encoding starts from the last segment of the SR policy (path). That means the first element of the segment list (Segment list [0]) contains the last segment of the SR policy, the second element contains the penultimate segment of the SR policy and so on.
In SRv6, a SID represents a 128-bit value, consisting of the following three parts:
• Locator: This is the first part of the SID with most significant bits and represents an address of a specific
SRv6 node.
• Function: This is the portion of the SID that is local to the owner node and designates a specific SRv6 function (network instruction) that is executed locally on a particular node, specified by the locator bits.
• Args: This field is optional and represents optional arguments to the function.
The locator part can be further divided into two parts:
• SID Block: This field is the SRv6 network designator and is a fixed or known address space for an SRv6 domain. This is the most significant bit (MSB) portion of a locator subnet.
• Node Id: This field is the node designator in an SRv6 network and is the least significant bit (LSB) portion of a locator subnet.
SRv6 Node Roles
Each node along the SRv6 packet path has a different functionality:
• Source node—A node that can generate an IPv6 packet with an SRH (an SRv6 packet), or an ingress node that can impose an SRH on an IPv6 packet.
• Transit node—A node along the path of the SRv6 packet (IPv6 packet and SRH). The transit node does not inspect the SRH. The destination address of the IPv6 packet does not correspond to the transit node.
• Endpoint node—A node in the SRv6 domain where the SRv6 segment is terminated. The destination address of the IPv6 packet with an SRH corresponds to the end point node. The segment endpoint node executes the function bound to the SID
SRv6 Head-End Behaviors
The SR Headend with Encapsulation behaviors are documented in the IETF RFC 8986 SRv6 Network
Programming .
The SR Headend with Insertion head-end behaviors are documented in the following IETF draft: https://datatracker.ietf.org/doc/draft-filsfils-spring-srv6-net-pgm-insertion/
This section describes a set of SR Policy headend behaviors. The following list summarizes them:
• H.Encaps—SR Headend Behavior with Encapsulation in an SRv6 Policy
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
7
Configure Segment Routing over IPv6 (SRv6)
Segment Routing over IPv6 Overview
• H.Encaps.Red—H.Encaps with Reduced Encapsulation
• H.Insert—SR Headend with insertion of an SRv6 Policy
• H.Insert.Red—H.Insert with reduced insertion
SRv6 Endpoint Behaviors
The SRv6 endpoint behaviors are documented in the IETF RFC 8986 SRv6 Network Programming .
The following is a subset of defined SRv6 endpoint behaviors that can be associated with a SID.
• End—Endpoint function. The SRv6 instantiation of a Prefix SID [ RFC8402 ].
• End.X—Endpoint with Layer-3 cross-connect. The SRv6 instantiation of an Adj SID [ RFC8402 ].
• End.DX6—Endpoint with decapsulation and IPv6 cross-connect (IPv6-L3VPN - equivalent to per-CE
VPN label).
• End.DX4—Endpoint with decapsulation and IPv4 cross-connect (IPv4-L3VPN - equivalent to per-CE
VPN label).
• End.DT6—Endpoint with decapsulation and IPv6 table lookup (IPv6-L3VPN - equivalent to per-VRF
VPN label).
• End.DT4—Endpoint with decapsulation and IPv4 table lookup (IPv4-L3VPN - equivalent to per-VRF
VPN label).
• End.DX2—Endpoint with decapsulation and L2 cross-connect (L2VPN use-case).
• End.B6.Encaps—Endpoint bound to an SRv6 policy with encapsulation. SRv6 instantiation of a Binding
SID.
• End.B6.Encaps.RED—End.B6.Encaps with reduced SRH. SRv6 instantiation of a Binding SID.
SRv6 Endpoint Behavior Variants
Depending on how the SRH is handled, different behavior variants are defined for the End and End.X behaviors.
The End and End.X behaviors can support these variants, either individually or in combinations.
• Penultimate Segment Pop (PSP) of the SRH variant —An SR Segment Endpoint Nodes receive the
IPv6 packet with the Destination Address field of the IPv6 Header equal to its SID address.
A penultimate SR Segment Endpoint Node is one that, as part of the SID processing, copies the last SID from the SRH into the IPv6 Destination Address and decrements the Segments Left value from one to zero.
The PSP operation takes place only at a penultimate SR Segment Endpoint Node and does not happen at non-penultimate endpoint nodes. When a SID of PSP-flavor is processed at a non-penultimate SR
Segment Endpoint Node, the PSP behavior is not performed since Segments Left would not be zero.
The SR Segment Endpoint Nodes advertise the SIDs instantiated on them via control plane protocols. A
PSP-flavored SID is used by the Source SR Node when it needs to instruct the penultimate SR Segment
Endpoint Node listed in the SRH to remove the SRH from the IPv6 header.
• Ultimate Segment Pop (USP) of the SRH variant —The SRH processing of the End and End.X behaviors are modified as follows:
8
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing over IPv6 (SRv6)
Segment Routing over IPv6 Overview
If Segments Left is 0, then:
1.
Update the Next Header field in the preceding header to the Next Header value of the SRH
2.
Decrease the IPv6 header Payload Length by 8*(Hdr Ext Len+1)
3.
Remove the SRH from the IPv6 extension header chain
4.
Proceed to process the next header in the packet
One of the applications of the USP flavor is when a packet with an SRH is destined to an application on hosts with smartNICs implementing SRv6. The USP flavor is used to remove the consumed SRH from the extension header chain before sending the packet to the host.
• Ultimate Segment Decapsulation (USD) variant —The Upper-layer header processing of the End,
End.X and End.T behaviors are modified as follows:
• End behavior: If the Upper-layer Header type is 41 (IPv6), then:
1.
Remove the outer IPv6 Header with all its extension headers
2.
Submit the packet to the egress IPv6 FIB lookup and transmission to the new destination
3.
Else, if the Upper-layer Header type is 4 (IPv4)
4.
Remove the outer IPv6 Header with all its extension headers
5.
Submit the packet to the egress IPv4 FIB lookup and transmission to the new destination
6.
Else, process as per Section 4.1.1 (Upper-Layer Header) of IETF RFC 8986 SRv6 Network
Programming
• End.X
behavior: If the Upper-layer Header type is 41 (IPv6) or 4 (IPv4), then:
1.
Remove the outer IPv6 Header with all its extension headers
2.
Forward the exposed IP packet to the L3 adjacency J
3.
Else, process as per Section 4.1.1 (Upper-Layer Header) of IETF RFC 8986 SRv6 Network
Programming
One of the applications of the USD flavor is the case of TI-LFA in P routers with encapsulation with
H.Encaps. The USD flavor allows the last Segment Endpoint Node in the repair path list to decapsulate the IPv6 header added at the TI-LFA Point of Local Repair and forward the inner packet.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
9
Configure Segment Routing over IPv6 (SRv6)
SRv6 Micro-Segment (uSID)
SRv6 Micro-Segment (uSID)
Table 1: Feature History Table
Feature Name
SRv6 Micro-Segment (uSID)
Release Information
Release 7.3.1
Feature Description
This feature is an extension of the
SRv6 architecture. It leverages the existing SRv6 Network
Programming architecture to encode up to six SRv6 Micro-SID
(uSID) instructions within a single
128-bit SID address. Such a SID address is called a uSID Carrier.
In addition, this feature leverages the existing SRv6 data plane and control plane with no changes. It also provides low MTU overhead; for example, 6 uSIDs per uSID carrier results in 18 source-routing waypoints in only 40 bytes of overhead (in SRH).
The SRv6 micro-segment (uSID) is an extension of the SRv6 architecture. It leverages the SRv6 Network
Programming architecture to encode several SRv6 Micro-SID (uSID) instructions within a single 128-bit SID address. Such a SID address is called a uSID Carrier.
SRv6 uSID is documented in the IETF drafts Network Programming extension: SRv6 uSID instruction and
Compressed SRv6 Segment List Encoding in SRH .
Throughout this chapter, we will refer to SRv6 micro-segment as “uSID”.
The SRv6 uSID provides the following benefits:
• Leverages the SRv6 Network Programming with no change. SRv6 uSID is a new pseudo code in the existing SRv6 network programming framework.
• Leverages the SRv6 data plane (SRH) with no change. Any SID in the destination address or SRH can be an SRv6 uSID carrier.
• Leverages the SRv6 control plane with no change.
• Ultra-Scale—Scalable number of globally unique nodes in the domain, for example:
• 16-bit uSID ID size: 65k uSIDs per domain block
• 32-bit uSID ID size: 4.3M uSIDs per domain block
• Lowest MTU overhead
• 6 uSIDs per uSID carrier
• For example, 18 source-routing waypoints in only 40 bytes of overhead
10
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing over IPv6 (SRv6)
SRv6 uSID Terminology
• Hardware-friendliness:
• Leverages mature hardware capabilities (inline IP Destination Address edit, IP Destination Address longest match).
• Avoids any extra lookup in indexed mapping tables.
• A micro-program with 6 or fewer uSIDs requires only legacy IP-in-IP encapsulation behavior.
• Scalable Control Plane:
• Summarization at area/domain boundary provides massive scaling advantage.
• No routing extension is required, a simple prefix advertisement suffices.
• Seamless Deployment:
• A uSID may be used as a SID (the carrier holds a single uSID).
• The inner structure of an SR Policy can stay opaque to the source. A carrier with uSIDs is just seen as a SID by the policy headend Security.
• Leverages SRv6's native SR domain security.
SRv6 uSID Terminology
The SRv6 Network Programming is extended with the following terms:
• uSID—An identifier that specifies a micro-segment.
A uSID has an associated behavior that is the SRv6 function (for example, a node SID or Adjacency
SID) associated with the given ID. The node at which an uSID is instantiated is called the “Parent” node.
• uSID Carrier—A 128-bit IPv6 address (carried in either in the packet destination address or in the SRH) in the following format:
<uSID-Block><Active-uSID><Next-uSID>...<Last-uSID><End-of-Carrier>...<End-of-Carrier> where:
• uSID Block—An IPv6 prefix that defines a block of SRv6 uSIDs.
• Active uSID—The first uSID that follows the uSID block.
• Next uSID—The next uSID after the Active uSID.
• Last uSID—The last uSID in the carrier before the End-of-Carrier uSID.
• End-of-Carrier —A globally reserved uSID that marks the end of a uSID carrier. The End-of-Carrier
ID is 0000 . All empty uSID carrier positions must be filled with the End-of-Carrier ID; therefore, a uSID carrier can have more than one End-of-Carrier.
The following is an example of an SRH with 3 Micro-SID carriers for a total of up to 18 micro-instructions:
Micro-SID Carrier1: {uInstruction1, uInstruction2… uInstruction6}
Micro-SID Carrier2: {uInstruction7, uInstruction8… uInstruction12}
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
11
Configure Segment Routing over IPv6 (SRv6)
SRv6 uSID Carrier Format
Micro-SID Carrier3: {uInstruction13, uInstruction14… uInstruction18}
SRv6 uSID Carrier Format
The uSID carrier format specifies the type of uSID carrier supported in an SRv6 network. The format specification includes Block size and ID size.
• uSID Block
The uSID block is an IPv6 prefix that defines a block of SRv6 uSIDs. This can be an IPv6 prefix allocated to the provider (for example, /22, /24, and so on.), or it can be any well-known IPv6 address block generally available for private use, such as the ULA space FC/8, as defined in IETF draft RFC4193 .
An SRv6 network may support more than a single uSID block.
The length of block [prefix] is defined in bits. From a hardware-friendliness perspective, it is expected to use sizes on byte boundaries (16, 24, 32, and so on).
• uSID ID
The length of uSID ID is defined in bits. From a hardware-friendliness perspective, it is expected to use sizes on byte boundaries (8, 16, 24, 32, and so on).
The uSID carrier format is specified using the notation "F bbuu " , where “ bb ” is size of block and “ uu ” is size of ID. For example, "F3216" is a format with a 32-bit uSID block and 16-bit uSID IDs.
Note F3216 is the default format, and the only format that is supported in IOS XR 7.3.1 release.
SRv6 uSID Allocation Within a uSID Block
The architecture for uSID specifies both globally scoped and locally scoped uSIDs, where a globally scoped uSID is the type of uSID that provides reachability to the node.
On the other hand, a locally scoped uSID is associated to a local behavior, and therefore must be preceded by a globally scoped uSID of the parent node when relying on routing to forward the packet.
The Global ID block (GIB) is the set of IDs available for globally scoped uSID allocation. The Local ID block
(LIB) is the set of IDs available for locally scoped uSID allocation.
A globally scoped uSID is a uSID from the GIB. A globally scoped uSID typically identifies a shortest path to a node in the SR domain. An IP route (for example, /48) is advertised by the parent node to each of its globally scoped uSIDs, under the associated uSID block. The parent node executes a variant of the END behavior.
The “Nodal” uSID (uN) is an example of a globally scoped behavior defined in uSID architecture.
A node can have multiple globally scoped uSIDs under the same uSID blocks (for example, one per IGP flex-algorithm). Multiple nodes may share the same globally scoped uSID (Anycast).
A locally scoped uSID is a uSID from the LIB. A locally scoped uSID identifies a local micro-instruction on the parent node; for example, it may identify a cross-connect to a direct neighbor over a specific interface or a VPN context. Locally scoped uSIDs are not routeable.
12
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing over IPv6 (SRv6)
SRv6 Endpoint Behaviors Associated with uSID
For example, if N1 and N2 are two different physical nodes of the uSID domain and L is a locally scoped uSID value, then N1 and N2 may bind two different behaviors to L .
The uSIDs are allocated in one of following ways: auto, dynamic, or explicit.
• The request to allocate locally scoped uSIDs comes from SRv6 clients (such as IS-IS or BGP). The request can be to allocate any available ID (dynamic allocation) or to allocate a specific ID (explicit allocation).
SRv6 Endpoint Behaviors Associated with uSID
The SRv6 Network Programming is extended with new types of SRv6 SID endpoint behaviors:
• uN—A short notation for the NEXT-CSID (Compressed SID) End behavior with a pseudocode of shift-and-lookup, and PSP/USD flavors
• uA—A short notation for the NEXT-CSID End.X behavior with a pseudocode of shift-and-xconnect, and PSP/USD flavors
• uDT—A short notation for the NEXT-CSID End.DT behavior with the same pseudocode as
End.DT4/End.DT6/End.DT2U/End.DT2M
• uDX—A short notation for the NEXT-CSID End.DX behavior with the same pseudocode as
End.DX4/End.DX6/End.DX2
SRv6 uSID in Action - Example
This example highlights an integrated VPN and Traffic Engineering use-case leveraging SRv6 uSID.
VPNv4 site A connected to Node 1 sends packets to VPNv4 site B connected to Node 2 alongside a traffic engineered path via Node 8 and Node 7 using a single 128-bit SRv6 SID.
Node 1 is the ingress PE; Node 2 is the egress PE.
Nodes 3, 4, 5, and 6 are classic IPv6 nodes. Traffic received on these nodes use classic IP forwarding without changing the outer DA.
Nodes 1, 8, 7 and 2 are SRv6 capable configured with:
• 32-bit SRv6 block = fcbb:bb01
• 16-bit SRv6 ID
For example:
• Node 7 uN = fcbb:bb01:0700::/48
• Node 8 uN = fcbb:bb01:0800::/48
The following IGP routes are advertised:
• Node 8 advertises the IGP route fcbb:bb01: 0800 ::/48
• Node 7 advertises the IGP route fcbb:bb01: 0700 ::/48
• Node 2 advertises the IGP route fcbb:bb01: 0200 ::/48
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
13
SRv6 uSID in Action - Example
Figure 2: Integrated VPN and Traffic Engineering SRv6 uSID Use-case
Configure Segment Routing over IPv6 (SRv6)
Node 1 encapsulates an IPv4 packet from VPN Site A and sends an IPv6 packet with destination address fcbb:bb01: 0800 : 0700 : 0200 :f001:0000:0000. This is a uSID carrier, with a list of micro-instructions (uSIDs)
(0800, 0700, 0200, f001, and 0000 – indicating the end of the instruction).
uSIDs (uNs) 0800, 0700, 0200 are used to realize the traffic engineering path to Node 2 with way points at
Nodes 8 and 7. uSID f001 is the BGP-signalled instruction (uDT4) advertized by Node 2 for the VPNv4 service
14
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing over IPv6 (SRv6)
Figure 3: Node 1: End.B6.Encaps Behavior
SRv6 uSID in Action - Example
Nodes 4 and 5 simply forward the packet along the shortest path to Node 8, providing seamless deployment through classic IPv6 nodes.
Figure 4: Node 4 and Node 5: Classic IPv6 Nodes
When Node 8 receives the packet, it performs SRv6 uN behavior (shift-and-lookup with PSP/USD). It removes its outer DA (0800) and advances the micro program to the next micro instruction by doing the following:
1.
Pops its own uSID (0800)
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
15
Configure Segment Routing over IPv6 (SRv6)
SRv6 uSID in Action - Example
2. Shifts the remaining DA by 16-bits to the left
3.
Fills the remaining bits with 0000 (End-of-Carrier)
4.
Performs a lookup for the shortest path to the next DA (fcbb:bb01: 0700::/48 )
5.
Forwards it using the new DA fcbb:bb01: 0700 :0200:f001:0000:0000:0000
Figure 5: Node 8: SRv6 uN Behavior (Shift and Forward)
When Node 7 receives the packet, it performs the same SRv6 uN behavior (shift-and-lookup with PSP/USD), forwarding it using the new DA fcbb:bb01: 0200 :f001:0000:0000:0000:0000
Figure 6: Node 7: SRv6 uN Behavior (Shift and Forward)
16
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing over IPv6 (SRv6)
SRv6 uSID in Action - Example
Nodes 6 and 3 simply forward the packet along the shortest path to Node 2, providing seamless deployment through classic IPv6 nodes.
Figure 7: Node 6 and Node 3: Classic IPv6 Nodes
When Node 2 receives the packet, it performs an SRv6 uDT4 behavior (End.DT4—Endpoint with decapsulation and IPv4 table lookup) to VPNv4 Site B.
Figure 8: Node 2: SRv6 uDT4 Behavior
To recap, this example showed an integrated VPN and Traffic Engineering use-case, where VPNv4 site A connected to Node 1 sent packets to VPNv4 site B connected to Node 2 alongside a traffic engineered path via Node 8 and Node 7 using a single 128-bit SRv6 SID:
• @1: inner packet P encapsulated with outer DA fcbb:bb01: 0800 : 0700 : 0200 :f001:0000:0000
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
17
Configure Segment Routing over IPv6 (SRv6)
Usage Guidelines and Limitations
• @4 & @5: classic IP forwarding, outer DA unchanged
• @8: SRv6 uN behavior: shift and lookup, outer DA becomes fcbb:bb01: 0700 : 0200 :f001:0000:0000:0000
• @7: SRv6 uN behavior: shift and lookup, outer DA becomes fcbb:bb01: 0200 :f001:0000:0000:0000:0000
• @6 & @3: classic IP forwarding, outer DA unchanged
• @2: SRv6 End.DT4: Decapsulate and IPv4 table lookup
Usage Guidelines and Limitations
General Guidelines and Limitations
• Cisco IOS XR supports uSIDs with 32-bit uSID block and 16-bit uSID IDs (3216).
A single UCF format must be used for uSID locators in a SRv6 uSID domain.
• Cisco IOS XR supports up to 8 uSID locator prefixes.
Multiple locator prefixes are used when configuring Anycast locators or SRv6 Flexible Algorithm instances, for example.
• Cisco IOS XR supports uSID locator prefixes from different uSID blocks.
Up to 64 uSID blocks can be used across all uSID locators in the network.
• Cisco IOS XR Release 7.3.1 and later supports the following SRv6 uSID behaviors and variants:
• uN with PSP/USD
• uA with PSP/USD
• uDT4
• uDT6
• SRv6 Underlay support includes:
• IGP redistribution/leaking between levels
• Prefix Summarization on ABR routers
• IS-IS TI-LFA
• Microloop Avoidance
• Flex-algo
• SRv6 over GRE interface is not supported
• SRv6 over BVI interface is not supported uSID Allocation Recommendation
We recommend that the uSID block allocation is made from the IPv6 Unique Local Address (ULA) range.
18
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing over IPv6 (SRv6)
Configuring SRv6
Note Allocation from the public Global Unicast Addresses (GUA) range is also supported.
• Use ULA /24 base from FC00::/8 space
• FC BB : BB /24, with B indicating a nibble value picked by operator
• 256 uSID blocks possible from this allocation
• In this release, 64 uSID blocks are supported
• FC BB : BBVV /32, with VV two variable nibbles. The supported values for VV in Cisco IOS XR
Release 7.3.1 are 0x00 to 0x3F.
For example:
• ULA /24 base = FC00:01/24
• uSID block space = 64 uSID blocks (from FC00:01 00 /32 to FC00:01 3F /32)
Configuring SRv6
Enabling SRv6 involves the following high-level configuration steps:
• Enable SRv6 on the platform
• Configure SRv6 locator(s)
• Enable SRv6 under IS-IS
• Enable SRv6 Services under BGP
Enable SRv6 on the Platform
Before configuring SRv6 on Cisco NCS 560 Series Routers, you must first use the following command:
• hw-module profile segment-routing srv6 mode micro-segment format f3216
Note You must reload the line card after enabling this command.
(Optional) Configure Network Role
By default, after enabling SRv6 on the platform, the node can serve as both edge (services) and core roles.
Optionally, you can customize the node role as "core-only" using the following command:
• hw-module profile network-role core-only
Note You must reload the line card after enabling this command.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
19
Configure Segment Routing over IPv6 (SRv6)
Configuring SRv6
Given that there is different budget for underlay SID encap based on the node role in the network (P-only vs
Edge), an operator can use this configuration to provide a hint to the platform and control plane to use a larger
SID encap budget when operating as a P-only node.
(Optional) Configure Merge Overlay/Underlay SID Mode
One of the main benefits of SRv6 uSID is compression (or packing) of multiple uSIDs into a uSID carrier.
This is possible when they share the same uSID block and when there is enough space in the carrier.
The underlay SIDs are always programmed in compressed form, if possible. The overlay SID is programmed separately.
When there is a need to send overlay traffic, the data path implementation attempts to merge the underlay
SIDs and overlay SIDs into a single carrier, if possible. With H.Encaps.Red encapsulation, this yields a packet with no SRH.
Note If the overlay and underlay use different uSID blocks, this merge is not possible.
By default, the Cisco NCS platform does not automatically merge the overlay/underlay SIDs.
To enable the platform to merge overlay/underlay SIDs, use the following command:
• segment-routing srv6 micro-segment merge-overlay-underlay-sids
Caution This command should only be enabled when a single block is required.
After you enable this command, this CLI will modify the behavior for all new overlay routes being programmed afterwards.
If you enable this command after SRv6 overlay routes are already programmed, we recommend that you clear the SRv6 overlay routes (using the clear route [ vrf WORD ] command) in order to trigger the re-programming in the “merge” mode.
If you do not to clear the overlay routes, those routes would continue to be programmed in the “non-merge” mode.
(Optional) Customize SRv6 Encapsulation Parameters
You can configure the traffic-class field settings on the IPv6 header using the following command:
• hw-module profile segment-routing srv6 mode micro-segment format f3216 encapsulation traffic-class { value | propagate }
Specify the value (as 2 hexadecimal nibbles) for traffic class; valid values are from 0x0 to 0xff. Use propagate to set the traffic-class value by propagation (from incoming packet/frame).
Note You must reload the line card after enabling this command.
20
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing over IPv6 (SRv6)
Configuring SRv6
Configure SRv6 Locator Name, Prefix, and uSID-Related Parameters
This section shows how to globally enable SRv6 and configure locator.
• segment-routing srv6 locators locator locator —Globally enable SRv6 and configure the locator.
• segment-routing srv6 locators locator locator prefix ipv6_prefix / length —Configure the locator prefix value.
• segment-routing srv6 locators locator locator micro-segment behavior unode psp-usd —Specifies the locator as a micro-segment (uSID) locator as well as specifies that IGP underlay uSID (uN/uA) variant is PSP-USD for this locator.
(Optional) Configure Algorithm Associated with Locator
• segment-routing srv6 locators locator locator algorithm algo —(Optional) Configure Algorithm associated with the locator. Valid values for algo are from 128 to 255.
For additional information about SRv6 Flexible Algorithm, see
Configuring SRv6 Flexible Algorithm under IS-IS, on page 26 .
For detailed information about Flexible Algorithm, see
Enabling Segment Routing Flexible Algorithm, on page 365
.
(Optional) Configure Anycast Locator
An SRv6 Anycast locator is a type of locator that identifies a set of nodes (uN SIDs). SRv6 Anycast Locators and their associated uN SIDs may be provisioned at multiple places in a topology.
The set of nodes (Anycast group) is configured to advertise a shared Anycast locator and uN SID. Anycast routing enables the steering of traffic toward multiple advertising nodes. Packets addressed to an Anycast address are forwarded to the topologically nearest nodes.
One use case is to advertise Anycast uN SIDs at exit points from an SRv6 network. Any of the nodes that advertise the common uN SID could be used to forward traffic out of the SRv6 portion of the network to the topologically nearest node.
The following behaviors apply to Anycast Locator:
• Unlike a normal locator, IS-IS does not program or advertise uA SIDs associated with an Anycast locator.
• uN SIDs allocated from Anycast locators will not be used in constructing TI-LFA backup paths or
Microloop Avoidance primary paths. TI-LFA backup and Microloop Avoidance paths for an Anycast locator prefix may terminate on any node advertising that locator, which may be different from the node terminating the original primary path.
• SRv6 anycast locators may have non-zero algorithm (Flexible Algorithm) values.
Use the following commands to configure the Anycast locator and advertise Anycast prefixes associated with an interface.
• segment-routing srv6 locators locator locator anycast —Configure the Anycast locator
• router isis instance-id interface Loopback instance prefix-attributes anycast level level —Advertise the Anycast prefixes associated with an interface.
Example 1:
The following example shows how to globally enable SRv6 and configure a locator.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
21
Configuring SRv6
Configure Segment Routing over IPv6 (SRv6)
Router(config)# segment-routing srv6
Router(config-srv6)# locators
Router(config-srv6-locators)# locator myLoc1
Router(config-srv6-locator)# micro-segment behavior unode psp-usd
Router(config-srv6-locator)# prefix 2001:0:8::/48
Example 2:
The following example shows how to configure Flexible Algorithm associated with locator.
Router(config)# segment-routing srv6
Router(config-srv6)# locators
Router(config-srv6-locators)# locator myLocAlgo128
Router(config-srv6-locator)# algorithm 128
Router(config-srv6-locator)# micro-segment behavior unode psp-usd
Router(config-srv6-locator)# prefix 2001:0:88::/48
Example 3:
The following example shows how to configure Anycast locator.
Router(config)# segment-routing srv6
Router(config-srv6)# locators
Router(config-srv6-locators)# locator myLocAnycast
Router(config-srv6-locator)# anycast
Router(config-srv6-locator)# micro-segment behavior unode psp-usd
Router(config-srv6-locator)# prefix 2001:0:100::/48
The following example shows how to advertise the Anycast prefixes associated with an interface.
Router(config)# router isis core
Router(config-isis)# interface Loopback100
Router(config-isis-if)# prefix-attributes anycast level 1
(Optional) Customize SRv6 Encapsulation Parameters
This section desribes the configurable SRv6 encapsulation parameters. These optional parameters include:
• segment-routing srv6 encapsulation source-address ipv6-addr —Source Address of outer encapsulating
IPv6 header. The default source address for encapsulation is one of the loopback addresses.
• segment-routing srv6 encapsulation hop-limit count —The hop limit of outer-encapsulating IPv6 header. The range for count is from 1 to 254; the default value for hop-limit is 254.
• segment-routing srv6 encapsulation evpn next-header protocol-number —The protocol number to use in the Next-header field of the IPv6 or SRH header. The range for protocol-number is from 59 to
252.
(Optional) Customize SRv6 Logging for Locator Status Changes
• segment-routing srv6 logging locator status —Enable the logging of locator status.
(Optional) Customize SRv6 SID Parameters
• segment-routing srv6 sid holdtime minutes —The holdtime for a stale or freed SID. The range of minutes is from 0 (disabled) to 60 minutes.
22
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing over IPv6 (SRv6)
Configuring SRv6
Example 4:
The following example shows how to configure optional SRv6 parameters:
RP/0/RSP0/CPU0:Node1(config)# segment-routing srv6 encapsulation
RP/0/RSP0/CPU0:Node1(config-srv6-encap)# source-address 1::1
RP/0/RSP0/CPU0:Node1(config-srv6-encap)# hop-limit 60
RP/0/RSP0/CPU0:Node1(config-srv6-encap)# evpn next-header 65
RP/0/RSP0/CPU0:Node1(config-srv6-encap)# exit
RP/0/RSP0/CPU0:Node1(config-srv6)# logging locator status
RP/0/RSP0/CPU0:Node1(config-srv6)# sid holdtime 10
RP/0/RSP0/CPU0:Node1(config-srv6)# micro-segment merge-overlay-underlay-sids
This config applies to only new SRv6 micro-segment overlay routes and does not update already programmed routes.
Please flap any existing SRv6 micro-segment overlay routes after making this configuration change.
RP/0/RSP0/CPU0:Node1(config-srv6)#
Verifying SRv6 Manager
This example shows how to verify the overall SRv6 state from SRv6 Manager point of view. The output displays parameters in use, summary information, and platform specific capabilities.
Router# show segment-routing srv6 manager
Parameters:
SRv6 Enabled: Yes
SRv6 Operational Mode:
Micro-segment:
SID Base Block: 2001::/24
Encapsulation:
Source Address:
Configured: ::
Default: ::
Hop-Limit: Default
Traffic-class: Default
Summary:
Number of Locators: 3 (3 operational)
Number of SIDs: 3 (0 stale)
Max SIDs: 64000
OOR:
Thresholds: Green 3200, Warning 1920
Status: Resource Available
History: (0 cleared, 0 warnings, 0 full)
Block 2001::/32:
Number of SIDs free: 7680
Max SIDs: 7680
Thresholds: Green 384, Warning 231
Status: Resource Available
History: (0 cleared, 0 warnings, 0 full)
Platform Capabilities:
SRv6: Yes
TILFA: Yes
Microloop-Avoidance: Yes
Endpoint behaviors:
End (PSP)
End.X (PSP)
End.DX6
End.DX4
End.DT6
End.DT4
End.OP
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
23
Configuring SRv6
Configure Segment Routing over IPv6 (SRv6) uN (PSP/USD) uA (PSP/USD) uDT6 uDT4 uDX2 uB6 (Insert.Red)
Headend behaviors:
T
H.Insert.Red
H.Encaps.Red
Security rules:
SEC-1
SEC-2
SEC-3
Counters:
CNT-1
CNT-3
Signaled parameters:
Max-SL : 3
Max-End-Pop-SRH : 3
Max-H-Insert : 3 sids
Max-H-Encap : 3 sids
Max-End-D : 4
Configurable parameters (under srv6):
Encapsulation:
Source Address: Yes
Hop-Limit : value=Yes, propagate=No
Traffic-class : value=Yes, propagate=Yes
Max SIDs: 64000
SID Holdtime: 3 mins
Verifying SRv6 Locator
This example shows how to verify the locator configuration and its operational status.
Router# show segment-routing srv6 locator myLoc1 detail
Name ID Algo Prefix Status Flags
----------------------------------------------------------------myLoc1 3 0 2001:0:8::/48 Up U
(U): Micro-segment (behavior: uN (PSP/USD))
Interface:
Name: srv6-myLoc1
IFH : 0x02000120
IPv6 address: 2001:0:8::/48
Number of SIDs: 1
Created: Dec 10 21:26:54.407 (02:52:26 ago)
Verifying SRv6 SIDs
This example shows how to verify the allocation of SRv6 local SIDs off locator(s).
Router# show segment-routing srv6 locator myLoc1 sid
SID Behavior Context
State RW
----------------------------------------------------------------------
-----------------------
2001:0:8:: uN (PSP/USD)
InUse Y
'default':1
Owner sidmgr
24
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing over IPv6 (SRv6)
Configuring SRv6 under IS-IS
The following example shows how to display detail information regarding an allocated SRv6 local SID.
Router# show segment-routing srv6 locator myLoc1 sid 2001:0:8:: detail
SID Behavior Context
State RW
----------------------------------------------------------------------
-----------------------
2001:0:8:: uN (PSP/USD) 'default':8
InUse Y
SID Function: 0x8
SID context: { table-id=0xe0800000 ('default':IPv6/Unicast), opaque-id=8 }
Locator: 'myLoc1'
Allocation type: Dynamic
Created: Dec 10 22:10:51.596 (02:10:05 ago)
Owner sidmgr
Similarly, you can display SID information across locators by using the show segment-routing srv6 sid command.
Configuring SRv6 under IS-IS
Intermediate System-to-Intermediate System (IS-IS) protocol already supports segment routing with MPLS dataplane (SR-MPLS). This feature enables extensions in IS-IS to support Segment Routing with IPv6 data plane (SRv6). The extensions include advertising the SRv6 capabilities of nodes and node and adjacency segments as SRv6 SIDs.
SRv6 IS-IS performs the following functionalities:
1.
Interacts with SID Manager to learn local locator prefixes and announces the locator prefixes in the IGP domain.
2.
Learns remote locator prefixes from other IS-IS neighbor routers and installs the learned remote locator
IPv6 prefix in RIB or FIB.
3.
Allocate or learn prefix SID and adjacency SIDs, create local SID entries, and advertise them in the IGP domain.
Usage Guidelines and Restrictions
The following usage guidelines and restrictions apply for SRv6 IS-IS:
• An IS-IS address-family can support either SR-MPLS or SRv6, but both at the same time is not supported.
Configuring SRv6 under IS-IS
To configure SRv6 IS-IS, use the following command:
• router isis instance address-family ipv6 unicast segment-routing srv6 locator locator [ level { 1 |
2 }]—Enable SRv6 under the IS-IS IPv6 address-family and assign SRv6 locator(s) to it. Use the level
{ 1 | 2 } keywords to advertise the locator only in the specified IS-IS level.
The following example shows how to configure SRv6 under IS-IS.
Router(config)# router isis core
Router(config-isis)# address-family ipv6 unicast
Router(config-isis-af)# segment-routing srv6
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
25
Configure Segment Routing over IPv6 (SRv6)
Configuring SRv6 Flexible Algorithm under IS-IS
Router(config-isis-srv6)# locator myLoc1 level 1
Router(config-isis-srv6-loc)# exit
For more information about configuring IS-IS, refer to the " Implemeting IS-ISImplemeting IS-IS " chapter in the Routing Configuration Guide for Cisco NCS 560 .
Configuring SRv6 Flexible Algorithm under IS-IS
This feature introduces support for implementing Flexible Algorithm using IS-IS SRv6.
SRv6 Flexible Algorithm allows operators to customize IGP shortest path computation according to their own needs. An operator can assign custom SR prefix-SIDs to realize forwarding beyond link-cost-based SPF. As a result, Flexible Algorithm provides a traffic engineered path automatically computed by the IGP to any destination reachable by the IGP.
For detailed information about Flexible Algorithm, see
Enabling Segment Routing Flexible Algorithm, on page 365 .
Usage Guidelines and Restrictions
Observe the following usage guidelines and restrictions:
• You can configure up to 8 locators to support SRv6 Flexible Algorithm.
• The Flexible Algorithm locator prefix follows the same usage guidelines and restrictions of algo-0 locator prefixes. See
Usage Guidelines and Limitations, on page 18 .
• The Locator Algorithm value range is 128 to 255.
Configuring SRv6 Flexible Algorithm under IS-IS
The following sections show you the steps to enable SRv6 Flexible Algorithm. The example highlights a delay-based Flexible Algorithm instance.
1.
Configure SRv6 locators
2.
Assign SRv6 locators under IS-IS
3.
Configure Flexible Algorithm definition and associated metric (for example, delay)
4.
Configure the delay probe under the interface. For more information on SR performance measurement, see
Configure Performance Measurement, on page 279
.
The following section shows how to configure two SRv6 locators: one associated with Algo 0, and the other associated with Algo 128.
Router(config)# segment-routing srv6
Router(config-srv6)# locators
Router(config-srv6-locators)# locator myLocBestEffort // best-effort locator
Router(config-srv6-locator)# micro-segment behavior unode psp-usd
Router(config-srv6-locator)# prefix 2001:0:1::/48
Router(config-srv6-locator)# exit
Router(config-srv6-locators)# locator myLocLowLat // low-latency (flex algo 128) locator
Router(config-srv6-locator)# micro-segment behavior unode psp-usd
26
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing over IPv6 (SRv6)
Configuring SRv6 Flexible Algorithm under IS-IS
Router(config-srv6-locator)# prefix 2001:0:2::/48
Router(config-srv6-locator)# algorithm 128
Router(config-srv6-locator)# exit
Router(config-srv6)# exit
The following section shows how to assign multiple SRv6 locators under IS-IS.
Router(config)# router isis core
Router(config-isis)# address-family ipv6 unicast
Router(config-isis-af)# segment-routing srv6
Router(config-isis-srv6)# locator myLocBestEffort
Router(config-isis-srv6-loc)# exit
Router(config-isis-srv6)# locator myLocLowLat
Router(config-isis-srv6-loc)# exit
The following section shows how to configure the Flexible Algorithm definition.
Router(config)# router isis core
Router(config-isis)# flex-algo 128
Router(config-isis-flex-algo)# metric-type delay
Router(config-isis-flex-algo)# exit
Router(config-isis)# interface GigabitEthernet0/0/0/0
Router(config-isis-if)# address-family ipv6 unicast
The following section shows how to configure the delay probe under the interface.
Router(config)# performance-measurement
Router(config-perf-meas)# interface GigabitEthernet0/0/0/0
Router(config-pm-intf)# delay-measurement
Router(config-pm-intf-dm)# commit
Verification
Router# show segment-routing srv6 locator
Name ID Algo Prefix Status Flags
----------------------------------------------------------------myLoc1 3 0 2001:0:8::/48 Up U myLocBestEffort 5 0 2001:0:1::/48 Up U myLocLowLat 4 128 2001:0:2::/48 Up U
Router# show isis flex-algo 128
IS-IS core Flex-Algo Database
Flex-Algo 128:
Level-2:
Definition Priority: 128
Definition Source: Router.00, (Local)
Definition Equal to Local: Yes
Disabled: No
Level-1:
Definition Priority: 128
Definition Source: Router.00, (Local)
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
27
Configure Segment Routing over IPv6 (SRv6)
Configuring SRv6 Locator Prefix Summarization
Definition Equal to Local: Yes
Disabled: No
Local Priority: 128
FRR Disabled: No
Microloop Avoidance Disabled: No
Configuring SRv6 Locator Prefix Summarization
SRv6 leverages longest-prefix-match IP forwarding. Massive-scale reachability can be achieved by summarizing locators at ABRs and ASBRs.
Use the summary-prefix locator [ algorithm algo ] [ explicit ] command in IS-IS address-family configuration mode to specify that only locators from the specified algorithm contribute to the summary. The explicit keyword limits the contributing prefixes to only those belonging to the same algorithm.
The following example shows how to configure SRv6 IS-IS Algorithm Summarization for regular algorithm and Flexible Algorithm (128).
Router(config)# router isis core
Router(config-isis)# address-family ipv6 unicast
Router(config-isis-af)# summary-prefix 2001:0:1::/48
Router(config-isis-af)# summary-prefix 2001:0:2::/48 algorithm 128 explicit
Configuring TI-LFA with SRv6 IS-IS
This feature introduces support for implementing Topology-Independent Loop-Free Alternate (TI-LFA) using
SRv6 IS-IS.
TI-LFA provides link protection in topologies where other fast reroute techniques cannot provide protection.
The goal of TI-LFA is to reduce the packet loss that results while routers converge after a topology change due to a link failure. TI-LFA leverages the post-convergence path which is planned to carry the traffic and ensures link and node protection within 50 milliseconds. TI-LFA with IS-IS SR-MPLS is already supported.
TI-LFA provides link, node, and Shared Risk Link Groups (SRLG) protection in any topology.
For more information, see
Configure Topology-Independent Loop-Free Alternate (TI-LFA), on page 325 .
Usage Guidelines and Limitations
The following usage guidelines and limitations apply:
• TI-LFA provides link protection by default. Additional tiebreaker configuration is required to enable node or SRLG protection.
• Usage guidelines for node and SRLG protection:
• TI-LFA node protection functionality provides protection from node failures. The neighbor node is excluded during the post convergence backup path calculation.
• Shared Risk Link Groups (SRLG) refer to situations in which links in a network share a common fiber (or a common physical attribute). These links have a shared risk: when one link fails, other
28
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing over IPv6 (SRv6)
Configuring TI-LFA with SRv6 IS-IS links in the group might also fail. TI-LFA SRLG protection attempts to find the post-convergence backup path that excludes the SRLG of the protected link. All local links that share any SRLG with the protecting link are excluded.
• When you enable link protection, you can also enable node protection, SRLG protection, or both, and specify a tiebreaker priority in case there are multiple LFAs.
• Valid priority values are from 1 to 255. The lower the priority value, the higher the priority of the rule. Link protection always has a lower priority than node or SRLG protection.
Configuring SRv6 IS-IS TI-LFA
The following example shows how to configure different types of TI-LFA protection for SRv6 IS-IS.
Router(config)# router isis core
Router(config-isis)# interface bundle-ether 1201
Router(config-isis-if)# address-family ipv6 unicast
Router(config-isis-if-af)# fast-reroute per-prefix
Router(config-isis-if-af)# fast-reroute per-prefix ti-lfa
Router(config-isis-if-af)# exit
Router(config-isis-if)# exit
Router(config-isis)# interface bundle-ether 1301
Router(config-isis-if)# address-family ipv6 unicast
Router(config-isis-if-af)# fast-reroute per-prefix
Router(config-isis-if-af)# fast-reroute per-prefix ti-lfa
Router(config-isis-if-af)# fast-reroute per-prefix tiebreaker node-protecting index 100
Router(config-isis-if-af)# fast-reroute per-prefix tiebreaker srlg-disjoint index 200
Router(config-isis-if-af)# exit
Configuring SRv6 IS-IS TI-LFA with Flexible Algorithm
TI-LFA backup paths for particular Flexible Algorithm are computed using the same constraints as the calculation of the primary paths for such Flexible Algorithm. These paths use the locator prefix advertised specifically for such Flexible Algorithm in order to enforce a backup path.
By default, LFA/TI-LFA for SRv6 Flexible Algorithm uses the LFA/TI-LFA configuration of Algo 0.
Use the fast-reroute disable command to disable the LFA/TI-LFA calculation on a per-algorithm basis:
Router(config)# router isis core
Router(config-isis)# flex-algo 128
Router(config-isis-flex-algo)# fast-reroute disable
Verification
This example shows how to verify the SRv6 IS-IS TI-LFA configuration using the show isis ipv6 fast-reroute
ipv6-prefix detail command.
Router# show isis ipv6 fast-reroute cafe:0:2::2/128 detail
L2 cafe:0:2::2/128 [20/115] Label: None, medium priority via fe80::e00:ff:fe3a:c700, HundredGigE0/0/0/0, Node2, Weight: 0
Backup path: TI-LFA (link), via fe80::1600:ff:feec:fe00, HundredGigE0/0/0/1 Node3,
Weight: 0, Metric: 40
P node: Node4.00 [cafe:0:4::4], SRv6 SID: cafe:0:4:: uN (PSP/USD)
Backup-src: Node2.00
P: No, TM: 40, LC: No, NP: No, D: No, SRLG: Yes
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
29
Configure Segment Routing over IPv6 (SRv6)
Configuring TI-LFA with SRv6 IS-IS src Node2.00-00, cafe:0:2::2
This example shows how to verify the SRv6 IS-IS TI-LFA configuration using the show route ipv6 ipv6-prefix detail command.
Router# show route ipv6 cafe:0:2::2/128 detail
Tue Feb 23 23:08:48.151 UTC
Routing entry for cafe:0:2::2/128
Known via "isis 1", distance 115, metric 20, type level-2
Installed Feb 23 22:57:38.900 for 00:11:09
Routing Descriptor Blocks fe80::1600:ff:feec:fe00, from cafe:0:2::2, via HundredGigE0/0/0/1, Backup (TI-LFA)
Repair Node(s): cafe:0:4::4
Route metric is 40
Label: None
Tunnel ID: None
Binding Label: None
Extended communities count: 0
Path id:65 Path ref count:1
NHID:0x20002(Ref:19)
SRv6 Headend: H.Insert.Red [f3216], SID-list {cafe:0:4::} fe80::e00:ff:fe3a:c700, from cafe:0:2::2, via HundredGigE0/0/0/0, Protected
Route metric is 20
Label: None
Tunnel ID: None
Binding Label: None
Extended communities count: 0
Path id:1 Path ref count:0
NHID:0x20001(Ref:19)
Backup path id:65
Route version is 0x4 (4)
No local label
IP Precedence: Not Set
QoS Group ID: Not Set
Flow-tag: Not Set
Fwd-class: Not Set
Route Priority: RIB_PRIORITY_NON_RECURSIVE_MEDIUM (7) SVD Type RIB_SVD_TYPE_LOCAL
Download Priority 1, Download Version 66
No advertising protos.
This example shows how to verify the SRv6 IS-IS TI-LFA configuration using the show cef ipv6 ipv6-prefix
detail location location command.
Router# show cef ipv6 cafe:0:2::2/128 detail location 0/0/cpu0
Tue Feb 23 23:09:07.719 UTC cafe:0:2::2/128, version 66, SRv6 Headend, internal 0x1000001 0x210 (ptr 0x8e96fd2c) [1],
0x0 (0x8e93fae0), 0x0 (0x8f7510a8)
Updated Feb 23 22:57:38.904
local adjacency to HundredGigE0/0/0/0
Prefix Len 128, traffic index 0, precedence n/a, priority 1 gateway array (0x8e7b5c78) reference count 1, flags 0x500000, source rib (7), 0 backups
[2 type 3 flags 0x8401 (0x8e86ea40) ext 0x0 (0x0)]
LW-LDI[type=3, refc=1, ptr=0x8e93fae0, sh-ldi=0x8e86ea40] gateway array update type-time 1 Feb 23 22:57:38.904
LDI Update time Feb 23 22:57:38.913
LW-LDI-TS Feb 23 22:57:38.913
via fe80::1600:ff:feec:fe00/128, HundredGigE0/0/0/1, 9 dependencies, weight 0, class 0, backup (TI-LFA) [flags 0xb00] path-idx 0 NHID 0x20002 [0x8f5850b0 0x0] next hop fe80::1600:ff:feec:fe00/128, Repair Node(s): cafe:0:4::4 local adjacency
30
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing over IPv6 (SRv6)
Configuring SRv6 IS-IS Microloop Avoidance
SRv6 H.Insert.Red SID-list {cafe:0:4::} via fe80::e00:ff:fe3a:c700/128, HundredGigE0/0/0/0, 6 dependencies, weight 0, class 0, protected [flags 0x400] path-idx 1 bkup-idx 0 NHID 0x20001 [0x8f8420b0 0x0] next hop fe80::e00:ff:fe3a:c700/128
Load distribution: 0 (refcount 2)
Hash OK Interface
0 Y HundredGigE0/0/0/0
Address fe80::e00:ff:fe3a:c700
Configuring SRv6 IS-IS Microloop Avoidance
This feature introduces support for implementing microloop avoidance using IS-IS SRv6.
Microloops are brief packet loops that occur in the network following a topology change (link down, link up, or metric change events). Microloops are caused by the non-simultaneous convergence of different nodes in the network. If nodes converge and send traffic to a neighbor node that has not converged yet, traffic may be looped between these two nodes, resulting in packet loss, jitter, and out-of-order packets.
The SRv6 Microloop Avoidance feature detects if microloops are possible following a topology change. If a node computes that a microloop could occur on the new topology, the node creates a loop-free SR-TE policy path to the destination using a list of segments. After the RIB update delay timer expires, the SR-TE policy is replaced with regular forwarding paths.
Usage Guidelines and Limitations
The following usage guidelines and limitations apply:
• The Routing Information Base (RIB) update delay value specifies the amount of time the node uses the microloop avoidance policy before updating its forwarding table. The delay-time range is from 1 to 60000 milliseconds; the default value is 5000.
Configuring SRv6 IS-IS Microloop Avoidance
The following example shows how to configure SRv6 IS-IS Microloop Avoidance and set the Routing
Information Base (RIB) update delay value.
Note Complete the
before performing these steps.
Router(config)# router isis test-igp
Router(config-isis)# address-family ipv6 unicast
Router(config-isis-af)# microloop avoidance segment-routing
Router(config-isis-af)# microloop avoidance rib-update-delay 2000
Router(config-isis-af)# commit
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
31
Configure Segment Routing over IPv6 (SRv6)
Configuring SRv6 BGP-Based Services
Configuring SRv6 IS-IS Microloop Avoidance with Flexible Algorithm
Microloop Avoidance paths for particular Flexible Algorithm are computed using the same constraints as the calculation of the primary paths for such Flexible Algorithm. These paths use the Locator prefix advertised specifically for such Flexible Algorithm in order to enforce a microloop avoidance path.
By default, Microloop Avoidance for SRv6 Flexible Algorithm uses the Microloop Avoidance configuration of Algo 0.
Use the microloop avoidance disable command to disable the microloop calculation on a per-algorithm basis:
Router(config)# router isis test-tilfa
Router(config-isis)# flex-algo 128
Router(config-isis-flex-algo)# microloop avoidance disable
Configuring SRv6 BGP-Based Services
Building on the messages and procedures defined in IETF draft " BGP/MPLS IP Virtual Private Networks
(VPNs) ", BGP has been extended to provide services over an SRv6 network, such as:
• IPv4 Layer-3 VPNs
• IPv6 Layer-3 VPNs
• IPv4 BGP global
• IPv6 BGP global
• Layer-2 VPNs - Ethernet VPNs (EVPN)
For more information about BGP, refer to the BGP Configuration Guide for Cisco NCS 560 Series Routers .
In SRv6-based services, the egress PE signals an SRv6 Service SID with the BGP service route. The ingress
PE encapsulates the payload in an outer IPv6 header where the destination address is the SRv6 Service SID advertised by the egress PE. BGP messages between PEs carry SRv6 Service SIDs as a means to interconnect
PEs and form VPNs. SRv6 Service SID refers to a segment identifier associated with one of the SRv6 service-specific behaviors advertised by the egress PE router, such as:
• uDT4 (Endpoint with decapsulation and IPv4 table lookup)
• uDT6 (Endpoint with decapsulation and IPv6 table lookup)
• uDX4 (Endpoint with decapsulation and IPv4 cross-connect)
• uDX6 (Endpoint with decapsulation and IPv6 cross-connect)
Based on the messages and procedures defined in IETF draft " SRv6 BGP based Overlay services ", BGP encodes the SRv6 Service SID in the prefix-SID attribute of the corresponding BGP Network Layer Reachability
Information (NLRI) and advertises it to its IPv6 BGP peers.
Usage Guidelines and Restrictions
• The following SRv6 BGP-based services are supported:
•
•
32
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing over IPv6 (SRv6)
Configuring SRv6 BGP-Based Services
•
SRv6 Services: IPv4 BGP Global
•
SRv6 Services: IPv6 BGP Global
• uDT4 and uDT6 for L3VPN and BGP global are supported.
• Dual-Stack L3 Services (IPv4 L3VPN, IPv6 L3VPN, IPv4 BGP global, IPv6 BGP global) are supported.
SRv6 Locator Inheritance Rules
SRv6 locators can be assigned at different levels inside the BGP routing process. BGP allocates SRv6 Service
SIDs from configured locator spaces according to the following inheritance rules:
1.
Use the locator as defined under the service.
If not defined under the specific service, then:
2.
Use the locator as defined under the corresponding address-family.
If not defined under the corresponding address-family, then:
3.
Use the locator as defined globally under BGP.
Enabling SRv6 Globally under BGP
Use the router bgp as-number segment-routing srv6 command to enable SRv6 globally under the BGP routing process. The as-number is from 1-65535.
RP/0/0/CPU0:Node1(config)# router bgp 100 segment-routing srv6
Assigning SRv6 Locator Globally under BGP
Use the router bgp as-number segment-routing srv6 locator WORD command to assign an SRv6 locator globally under the BGP routing process. The as-number is from 1-65535.
This example shows how to assign a locator:
RP/0/0/CPU0:Node1(config)# router bgp 100 segment-routing srv6 locator Node1-locator
For more information on how to configure an SRv6 locator, see
Configuring SRv6, on page 19 .
For more information on how to assign an SRv6 locator under the BGP service or BGP address-family, see the following SRv6 Services sections.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
33
Configure Segment Routing over IPv6 (SRv6)
SRv6 Services: IPv4 L3VPN
SRv6 Services: IPv4 L3VPN
Table 2: Feature History Table
Feature Name
Per-Prefix SRv6 Locator
Assignment
Support for iBGP as PE-CE protocol
BGP Route Leaking
Release
Release 7.5.1
Release 7.5.1
Release 7.5.1
Description
This feature provides the ability to assign a specific SRv6 locator for a given prefix or a set of prefixes
(IPv4/IPv6 GRT, IPv4/IPv6 VPN).
The egress PE advertises the prefix with the specified locator. This allows for per-prefix steering into desired transport behaviors, such as Flex Algo.
This feature introduces support for iBGP as PE-CE protocol.
This feature adds support for importing routes from default-VRF to non-default VRF and routes from non-default VRF to default VRF.
This feature provides IPv4 L3VPNs (VPNv4) over an SRv6 network.
Usage Guidelines and Limitations
• SRv6 locator can be assigned globally, for all VRFs, or for an individual VRF.
SRv6 locator can be assigned globally, for all VRFs, for an individual VRF, or per-prefix.
• Per-VRF allocation mode is supported (uDT4 behavior)
• Dual-Stack L3VPN Services (IPv4, IPv6) are supported
• Equal-Cost Multi-path (ECMP) and Unequal Cost Multipath (UCMP) are supported.
• eBGP, OSPF, Static are supported as PE-CE protocol.
BGP (iBGP, eBGP), OSPF, Static are supported as PE-CE protocol.
• BGP route leaking between BGP Global and L3VPN is supported.
• Per-CE allocation mode is not supported (uDX4 behavior)
• iBGP is not supported as PE-CE protocol
• BGP route leaking is not supported
Configuring SRv6 based IPv4 L3VPN
To enable SRv6-based L3VPN, you need to enable SRv6 under BGP, specify the locator, and configure the
SID allocation mode. The assignment of the locator can be done in different places under the router bgp configuration. See
SRv6 Locator Inheritance Rules, on page 33 .
34
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing over IPv6 (SRv6)
SRv6 Services: IPv4 L3VPN
Use Case 1: Assigning SRv6 Locator Globally
This example shows how to enable SRv6 and configure the SRv6 locator name under BGP Global:
Node1(config)# router bgp 100
Node1(config-bgp)# segment-routing srv6
Node1(config-bgp-gbl-srv6)# locator Node1-locator
Node1(config-bgp-gbl-srv6)# exit
Node1(config-bgp)# address-family vpnv4 unicast
Node1(config-bgp-af)# exit
Node1(config-bgp)# neighbor 3001::1:1:1:4
Node1(config-bgp-nbr)# remote-as 100
Node1(config-bgp-nbr)# address-family vpnv4 unicast
Node1(config-bgp-nbr-af)# exit
Node1(config-bgp-nbr)# exit
Node1(config-bgp)# vrf vrf_cust1
Node1(config-bgp-vrf)# rd 100:1
Node1(config-bgp-vrf)# address-family ipv4 unicast
Node1(config-bgp-vrf-af)# commit
Running Config router bgp 100 segment-routing srv6 locator Node1-locator
!
address-family vpnv4 unicast
!
neighbor 3001::1:1:1:4 remote-as 100 address-family vpnv4 unicast
!
!
vrf vrf_cust1 rd 100:1 address-family ipv4 unicast
!
!
!
end
Use Case 2: Assigning SRv6 Locator for All VRFs
To configure the SRv6 locator for all VRFs under VPNv4 Address Family and specify the allocation mode, use the following commands:
• router bgp as-number address-family vpnv4 unicast vrf all segment-routing srv6 : Enable SRv6
• router bgp as-number address-family vpnv4 unicast vrf all segment-routing srv6 alloc mode
{ per-vrf }: Specify the SID behavior (allocation mode)
• Use the per-vrf keyword to specify that the same service SID (uDT4 behavior) be used for all the routes advertised from a unique VRF.
• router bgp as-number address-family vpnv4 unicast vrf all segment-routing srv6 locator WORD :
Specify the locator
This example shows how to enable SRv6 and configure the SRv6 locator for all VRFs under VPNv4 Address
Family, with per-VRF label allocation mode:
Node1(config)# router bgp 100
Node1(config-bgp)# address-family vpnv4 unicast
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
35
Configure Segment Routing over IPv6 (SRv6)
SRv6 Services: IPv4 L3VPN
Node1(config-bgp-af)# vrf all
Node1(config-bgp-af-vrfall)# segment-routing srv6
Node1(config-bgp-af-vrfall-srv6)# locator Node1-locator
Node1(config-bgp-af-vrfall-srv6)# alloc mode per-vrf
Node1(config-bgp-af-vrfall-srv6)# exit
Node1(config-bgp-af-vrfall)# exit
Node1(config-bgp-af)# exit
Node1(config-bgp)# neighbor 3001::1:1:1:4
Node1(config-bgp-nbr)# remote-as 100
Node1(config-bgp-nbr)# address-family vpnv4 unicast
Node1(config-bgp-nbr-af)# exit
Node1(config-bgp-nbr)# exit
Node1(config-bgp)# vrf vrf_cust1
Node1(config-bgp-vrf)# rd 100:1
Node1(config-bgp-vrf)# address-family ipv4 unicast
Node1(config-bgp-vrf-af)# commit
Running Config router bgp 100 address-family vpnv4 unicast vrf all segment-routing srv6 locator Node1-locator alloc mode per-vrf
!
!
!
neighbor 3001::1:1:1:4 remote-as 100 address-family vpnv4 unicast
!
!
vrf vrf_cust1
!
!
!
end rd 100:1 address-family ipv4 unicast
Use Case 3: Assigning SRv6 Locator for a specific VRF
To configure the SRv6 locator for a specific VRF under IPv4 Address Family and specify the allocation mode, use the following commands:
• router bgp as-number vrf WORD address-family ipv4 unicast segment-routing srv6 : Enable SRv6
• router bgp as-number vrf WORD address-family ipv4 unicast segment-routing srv6 alloc mode { per-vrf }: Specify the SID behavior (allocation mode)
• Use the per-vrf keyword to specify that the same service SID (uDT4 behavior) be used for all the routes advertised from a unique VRF.
• router bgp as-number vrf WORD address-family ipv4 unicast segment-routing srv6 locator WORD :
Specify the locator
This example shows how to configure the SRv6 locator for an individual VRF, with per-VRF label allocation mode:
36
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing over IPv6 (SRv6)
SRv6 Services: IPv4 L3VPN
Node1(config)# router bgp 100
Node1(config-bgp)# address-family vpnv4 unicast
Node1(config-bgp-af)# exit
Node1(config-bgp)# neighbor 3001::1:1:1:4
Node1(config-bgp-nbr)# remote-as 100
Node1(config-bgp-nbr)# address-family vpnv4 unicast
Node1(config-bgp-nbr-af)# exit
Node1(config-bgp-nbr)# exit
Node1(config-bgp)# vrf vrf_cust1
Node1(config-bgp-vrf)# rd 100:1
Node1(config-bgp-vrf)# address-family ipv4 unicast
Node1(config-bgp-vrf-af)# segment-routing srv6
Node1(config-bgp-vrf-af-srv6)# locator Node1-locator
Node1(config-bgp-vrf-af-srv6)# alloc mode per-vrf
Node1(config-bgp-vrf-af-srv6)# commit
Running Config router bgp 100 address-family vpnv4 unicast
!
neighbor 3001::1:1:1:4 remote-as 100 address-family vpnv4 unicast
!
!
vrf vrf_cust1 rd 100:1 address-family ipv4 unicast segment-routing srv6 locator Node1-locator
!
!
!
end
!
alloc mode per-vrf
Use Case 4: Assigning SRv6 Locator for a Specific Prefix
This use case provides the ability to assign a specific SRv6 locator for a given prefix or a set of prefixes. The egress PE advertises the prefix with the specified locator. This allows for per-prefix steering into desired transport behaviors, such as Flex Algo.
To assign an SRv6 locator for a specific prefix, configure a route policy to specify the SID allocation mode based on match criteria. Examples of match criteria are destination-based match or community-based match.
• Supported SID allocation modes are per-VRF and per-CE.
• For per-VRF allocation mode, you can also specify the SRv6 locator.
• If an SRv6 locator is specified in the route policy, BGP will use that to allocate per-VRF SID. If the specified locator is invalid, the SID will not be allocated.
• If an SRv6 locator is not specified in the route policy, the default locator configured under BGP is used to allocate the SID. If the default locator is not configured, then the SID will not be allocated.
• Per-CE allocation mode always uses the default locator configured under BGP to allocate the SID.
For more information on configuring routing policies, refer to the "Implementing Routing Policy" chapter in the Routing Configuration Guide for Cisco NCS 560 Series Routers .
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
37
Configure Segment Routing over IPv6 (SRv6)
SRv6 Services: IPv4 L3VPN
The following example shows a route policy specifying the SID allocation mode with destination-based match:
Node1(config)# route-policy set_per_prefix_locator_rpl
Node1(config-rpl)# if destination in (1.1.1.0/24) then
Node1(config-rpl-if)# set srv6-alloc-mode per-vrf locator locator1
Node1(config-rpl-if)# elseif destination in (2.2.2.0/24) then
Node1(config-rpl-elseif)# set srv6-alloc-mode per-vrf locator locator2
Node1(config-rpl-elseif)# elseif destination in (3.3.3.0/24) then
Node1(config-rpl-elseif)# set srv6-alloc-mode per-vrf
Node1(config-rpl-elseif)# elseif destination in (4.4.4.0/24) then
Node1(config-rpl-elseif)# set srv6-alloc-mode per-ce
Node1(config-rpl-elseif)# else
Node1(config-rpl-else)# drop
Node1(config-rpl-else)# endif
Node1(config-rpl)# end-policy
Node1(config)#
To specify per-prefix allocation mode for a specific VRF under IPv4 address family, use the following command:
• router bgp as-number vrf WORD address-family ipv4 unicast segment-routing srv6 alloc mode
route-policy policy_name
This example shows how to configure per-prefix allocation mode for a specific VRF (vrf_cust1) under IPv4 address family
Node1(config)# router bgp 100
Node1(config-bgp)# vrf vrf_cust1
Node1(config-bgp-vrf)# address-family ipv4 unicast
Node1(config-bgp-vrf-af)# segment-routing srv6
Node1(config-bgp-vrf-af-srv6)# alloc mode route-policy set_per_prefix_locator_rpl
Running Configuration route-policy set_per_prefix_locator_rpl if destination in ( 1.1.1.0/24 ) then set srv6-alloc-mode per-vrf locator locator1 elseif destination in ( 2.2.2.0/24 ) then set srv6-alloc-mode per-vrf locator locator2 elseif destination in ( 3.3.3.0/24 ) then set srv6-alloc-mode per-vrf elseif destination in ( 4.4.4.0/24 ) then set srv6-alloc-mode per-ce else drop endif end-policy
!
router bgp 100 vrf vrf_cust1 address-family ipv6 unicast
!
!
!
!
segment-routing srv6 alloc mode route-policy set_per_prefix_locator_rpl
Verify that the local and received SIDs have been correctly allocated under VPNv4 and specific VRF
(vrf_cust1):
38
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing over IPv6 (SRv6)
SRv6 Services: IPv4 L3VPN
Node1# show bgp vpnv4 unicast local-sids
BGP router identifier 1.1.1.1, local AS number 100
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0x0 RD version: 0
BGP main routing table version 50
BGP NSR Initial initsync version 18 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs
Status codes: s suppressed, d damped, h history, * valid, > best i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Local Sid
Route Distinguisher: 8:8
*>i8.8.8.8/32
* i
NO SRv6 Sid
NO SRv6 Sid
Alloc mode
-
-
Locator
-
-
Route Distinguisher: 1.1.1.1:0 (default for vrf vrf_cust1)
*> 1.1.1.0/24 fc00:0:1:40::
*> 2.2.2.0/24 fc00:8:1:40::
*> 3.3.3.0/24
*> 4.4.4.0/24 fc00:9:1:40:: fc00:9:1:41::
*> 1.1.1.5/32
*> 3.3.3.3/32
*>i8.8.8.8/32
NO SRv6 Sid
NO SRv6 Sid
NO SRv6 Sid per-vrf per-vrf per-vrf per-ce
-
-
locator1 locator2 locator4 locator4
-
-
-
Node1# show bgp vpnv4 unicast received-sids
BGP router identifier 1.1.1.1, local AS number 100
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0x0 RD version: 0
BGP main routing table version 50
BGP NSR Initial initsync version 18 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs
Status codes: s suppressed, d damped, h history, * valid, > best i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Received Sid
Route Distinguisher: 8:8
*>i8.8.8.8/32 10.1.1.2
fc00:0:2:42::
* i 2400:2020:42:2fff::1
Route Distinguisher: 1.1.1.1:0 (default for vrf vrf_cust1) fc00:0:2:42::
*> 1.1.1.0/24
*> 2.2.2.0/24
11.1.1.2
11.1.1.2
NO SRv6 Sid
NO SRv6 Sid
*> 3.3.3.0/24
*> 4.4.4.0/24
*> 1.1.1.5/32
*> 3.3.3.3/32
*>i8.8.8.8/32
11.1.1.2
11.1.1.2
11.1.1.2
13.2.2.2
10.1.1.2
NO SRv6 Sid
NO SRv6 Sid
NO SRv6 Sid
NO SRv6 Sid fc00:0:2:42::
Node1# show bgp vrf vrf_cust1 local-sids
BGP VRF vrf_cust1, state: Active
BGP Route Distinguisher: 1.1.1.1:0
VRF ID: 0x60000004
BGP router identifier 1.1.1.1, local AS number 1
Non-stop routing is enabled
BGP table state: Active
Table ID: 0xe0000013 RD version: 37
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
39
Configure Segment Routing over IPv6 (SRv6)
SRv6 Services: IPv4 L3VPN
BGP main routing table version 37
BGP NSR Initial initsync version 18 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
Status codes: s suppressed, d damped, h history, * valid, > best i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Local Sid
Route Distinguisher: 1.1.1.1:0 (default for vrf vrf_cust1)
Alloc mode Locator
*> 1.1.1.0/24
*> 2.2.2.0/24
*> 3.3.3.0/24
*> 4.4.4.0/24
*> 1.1.1.5/32
*> 3.3.3.3/32
*>i8.8.8.8/32 fc00:0:1:40:: fc00:8:1:40:: fc00:9:1:40:: fc00:9:1:41::
NO SRv6 Sid
NO SRv6 Sid
NO SRv6 Sid per-vrf per-vrf per-vrf per-ce
-
-
locator1 locator2 locator4 locator4
-
-
-
Node1# show bgp vrf vrf_cust1 received-sids
BGP VRF vrf_cust1, state: Active
BGP Route Distinguisher: 1.1.1.1:0
VRF ID: 0x60000004
BGP router identifier 1.1.1.1, local AS number 1
Non-stop routing is enabled
BGP table state: Active
Table ID: 0xe0000013 RD version: 37
BGP main routing table version 37
BGP NSR Initial initsync version 18 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
Status codes: s suppressed, d damped, h history, * valid, > best i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Received Sid
Route Distinguisher: 1.1.1.1:0 (default for vrf vrf_cust1)
*> 1.1.1.0/24 11.1.1.2
NO SRv6 Sid
*> 2.2.2.0/24 11.1.1.2
NO SRv6 Sid
*> 3.3.3.0/24
*> 4.4.4.0/24
11.1.1.2
11.1.1.2
NO SRv6 Sid
NO SRv6 Sid
*> 1.1.1.5/32
*> 3.3.3.3/32
*>i8.8.8.8/32
11.1.1.2
13.2.2.2
10.1.1.2
NO SRv6 Sid
NO SRv6 Sid fc00:0:2:42::
Verification
The following figure shows a VPNv4 scenario. The sequence of commands included correspond to router
Node1 acting as Ingress PE, and routers Node4 and Node5 acting as Egress PEs.
40
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing over IPv6 (SRv6)
SRv6 Services: IPv4 L3VPN
The following example shows how to verify the SRv6 based L3VPN configuration using the show segment-routing srv6 sid command.
In this example, we can observe the uDT4 SIDs associated with the IPv4 L3VPN; where uDT4 behavior represents Endpoint with decapsulation and IPv4 table lookup.
Node1# show segment-routing srv6 sid
*** Locator: 'Node1-locator' ***
SID Behavior Context
State RW
----------------------------------------------------------------------
----------------------cafe:0:1:: uN (PSP/USD) 'default':1
InUse Y cafe:0:1:e000::
InUse Y cafe:0:1:e001::
InUse Y cafe:0:1:e002:: uA (PSP/USD) uA (PSP/USD) uDT4
[Hu0/0/0/0, Link-Local]:0
[Hu0/0/0/1, Link-Local]:0
' vrf_cust1 '
InUse Y cafe:0:1:e003::
InUse Y cafe:0:1:e004::
InUse Y cafe:0:1:e005::
InUse Y cafe:0:1:e006::
InUse Y uDT4 uDT4 uDT4 uDT4
'vrf_cust2'
'vrf_cust3'
'vrf_cust4'
'vrf_cust5'
Owner sidmgr isis-1 isis-1 bgp-100 bgp-100 bgp-100 bgp-100 bgp-100
The following example shows how to verify the SRv6 based L3VPN configuration using the show
segment-routing srv6SID-prefixdetail command.
Node1# show segment-routing srv6 sid cafe:0:1:e002:: detail
Tue Feb 9 17:50:40.621 UTC
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
41
Configure Segment Routing over IPv6 (SRv6)
SRv6 Services: IPv4 L3VPN
*** Locator: 'Node1-locator' ***
SID Behavior Context
State RW
----------------------------------------------------------------------
----------------------cafe:0:1:e002:: uDT4 'vrf_cust1'
InUse Y
SID Function: 0xe002
SID context: { table-id=0xe0000011 ('vrf_cust1':IPv4/Unicast) }
Locator: 'Node1-locator'
Allocation type: Dynamic
Created: Feb 9 17:41:07.475 (00:09:33 ago)
Owner bgp-100
The following example shows how to verify the SRv6 based L3VPN configuration using the show bgp vpnv4 unicast commands on Egress PE.
Node1# show bgp vpnv4 unicast summary
BGP router identifier 1.1.1.1, local AS number 100
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0x0 RD version: 0
BGP main routing table version 36
BGP NSR Initial initsync version 16 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs
BGP is operating in STANDALONE mode.
Process
Speaker
Neighbor cafe:0:4::4 cafe:0:5::5
RcvTblVer bRIB/RIB LabelVer ImportVer SendTblVer StandbyVer
36 36 36 36 36 0
Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd
0 100
0 100
47
47
48
47
36
36
0
0
0 00:40:05
0 00:39:56
5
5
Node1# show bgp vpnv4 unicast rd 100:1
BGP router identifier 1.1.1.1, local AS number 100
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0x0 RD version: 0
BGP main routing table version 36
BGP NSR Initial initsync version 16 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs
Status codes: s suppressed, d damped, h history, * valid, > best i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 100:1 (default for vrf vrf_cust1)
*> 12.1.1.1/32
*>i12.4.4.4/32
*>i12.5.5.5/32
0.0.0.0
cafe:0:4::4 cafe:0:5::5
0
0
0
100
100
32768 ?
0 ?
0 ?
Processed 3 prefixes, 3 paths
42
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing over IPv6 (SRv6)
SRv6 Services: IPv4 L3VPN
Node1# show bgp vpnv4 unicast rd 100:1 12.4.4.4/32
BGP routing table entry for 12.4.4.4/32, Route Distinguisher: 100:1
Versions:
Process
Speaker bRIB/RIB
22
SendTblVer
22
Last Modified: Feb 23 22:57:56.756 for 00:40:08
Paths: (1 available, best #1)
Not advertised to any peer
Path #1: Received by speaker 0
Not advertised to any peer
Local, (received & used) cafe:0:4::4 (metric 30) from cafe:0:4::4 (1.1.1.4)
Received Label 0xe00400
Origin incomplete, metric 0, localpref 100, valid, internal, best, group-best, import-candidate, imported
Received Path ID 0, Local Path ID 1, version 22
Extended community: RT:1:1 RT:100:1
PSID-Type:L3, SubTLV Count:1
SubTLV:
T:1(Sid information), Sid:cafe:0:4::, Behavior:63, SS-TLV Count:1
SubSubTLV:
T:1(Sid structure):
Source AFI: VPNv4 Unicast, Source VRF: vrf_cust1, Source Route Distinguisher: 100:1
The following examples show how to verify the BGP prefix information for VRF instances using the show bgp vrf commands:
Node1# show bgp vrf vrf_cust1 ipv4 unicast
BGP VRF vrf_cust1, state: Active
BGP Route Distinguisher: 100:1
VRF ID: 0x60000002
BGP router identifier 1.1.1.1, local AS number 100
Non-stop routing is enabled
BGP table state: Active
Table ID: 0xe0000011 RD version: 32
BGP main routing table version 36
BGP NSR Initial initsync version 16 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
Status codes: s suppressed, d damped, h history, * valid, > best i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 100:1 (default for vrf vrf_cust1)
*> 12.1.1.1/32 0.0.0.0
0
*>i12.4.4.4/32
*>i12.5.5.5/32 cafe:0:4::4 cafe:0:5::5
0
0
100
100
32768 ?
0 ?
0 ?
Processed 3 prefixes, 3 paths
Node1# show bgp vrf vrf_cust1 ipv4 unicast 12.4.4.4/32
Tue Feb 23 23:39:57.499 UTC
BGP routing table entry for 12.4.4.4/32, Route Distinguisher: 100:1
Versions:
Process
Speaker bRIB/RIB SendTblVer
22 22
Last Modified: Feb 23 22:57:56.756 for 00:42:01
Paths: (1 available, best #1)
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
43
Configure Segment Routing over IPv6 (SRv6)
SRv6 Services: IPv4 L3VPN
Not advertised to any peer
Path #1: Received by speaker 0
Not advertised to any peer
Local, (received & used) cafe:0:4::4 (metric 30) from cafe:0:4::4 (1.1.1.4)
Received Label 0xe00400
Origin incomplete, metric 0, localpref 100, valid, internal, best, group-best, import-candidate, imported
Received Path ID 0, Local Path ID 1, version 22
Extended community: RT:1:1 RT:100:1
PSID-Type:L3, SubTLV Count:1
SubTLV:
T:1(Sid information), Sid:cafe:0:4::, Behavior:63, SS-TLV Count:1
SubSubTLV:
T:1(Sid structure):
Source AFI: VPNv4 Unicast, Source VRF: vrf_cust1, Source Route Distinguisher: 100:1
The following example shows how to verify the SRv6 based L3VPN configuration using the show route vrf commands.
Node1# show route vrf vrf_cust1
Codes: C - connected, S - static, R - RIP, B - BGP, (>) - Diversion path
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - ISIS, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, su - IS-IS summary null, * - candidate default
U - per-user static route, o - ODR, L - local, G - DAGR, l - LISP
A - access/subscriber, a - Application route
M - mobile route, r - RPL, t - Traffic Engineering, (!) - FRR Backup path
Gateway of last resort is not set
L
B
B
12.1.1.1/32 is directly connected, 00:44:43, Loopback100
12.4.4.4/32 [200/0] via cafe:0:4::4 (nexthop in vrf default), 00:42:45
12.5.5.5/32 [200/0] via cafe:0:5::5 (nexthop in vrf default), 00:42:45
Node1# show route vrf vrf_cust1 12.4.4.4/32
Routing entry for 12.4.4.4/32
Known via "bgp 100", distance 200, metric 0, type internal
Installed Feb 23 22:57:56.746 for 00:43:12
Routing Descriptor Blocks cafe:0:4::4, from cafe:0:4::4
Nexthop in Vrf: "default", Table: "default", IPv6 Unicast, Table Id: 0xe0800000
Route metric is 0
No advertising protos.
Node1# show route vrf vrf_cust1 12.4.4.4/32 detail
Routing entry for 12.4.4.4/32
Known via "bgp 100", distance 200, metric 0, type internal
Installed Feb 23 22:57:56.746 for 00:43:37
Routing Descriptor Blocks cafe:0:4::4, from cafe:0:4::4
Nexthop in Vrf: "default", Table: "default", IPv6 Unicast, Table Id: 0xe0800000
Route metric is 0
Label: None
Tunnel ID: None
Binding Label: None
44
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing over IPv6 (SRv6)
SRv6 Services: IPv4 L3VPN
Extended communities count: 0
Source RD attributes: 0x0000:100:1
NHID:0x0(Ref:0)
SRv6 Headend: H.Encaps.Red [f3216], SID-list {cafe:0:4:e004::}
Route version is 0x1 (1)
No local label
IP Precedence: Not Set
QoS Group ID: Not Set
Flow-tag: Not Set
Fwd-class: Not Set
Route Priority: RIB_PRIORITY_RECURSIVE (12) SVD Type RIB_SVD_TYPE_REMOTE
Download Priority 3, Download Version 3
No advertising protos.
The following example shows how to verify the SRv6 based L3VPN configuration using the show cef vrf commands.
Node1# show cef vrf vrf_cust1
Prefix Next Hop Interface
------------------- ------------------- ------------------
0.0.0.0/0 drop default handler
0.0.0.0/32
12.1.1.1/32
12.4.4.4/32 broadcast receive cafe:0:4::/128
Loopback100
<recursive>
<recursive> 12.5.5.5/32
224.0.0.0/4 cafe:0:5::/128
0.0.0.0/32
224.0.0.0/24 receive
255.255.255.255/32 broadcast
Node1# show cef vrf vrf_cust1 12.4.4.4/32
12.4.4.4/32, version 3, SRv6 Headend, internal 0x5000001 0x30 (ptr 0x78b9a61c) [1], 0x0
(0x0), 0x0 (0x88873720)
Updated Feb 23 22:57:56.749
Prefix Len 32, traffic index 0, precedence n/a, priority 3 via cafe:0:4::/128, 3 dependencies, recursive [flags 0x6000] path-idx 0 NHID 0x0 [0x78e2da14 0x0] next hop VRF - 'default', table - 0xe0800000 next hop cafe:0:4::/128 via cafe:0:4::/48
SRv6 H.Encaps.Red SID-list {cafe:0:4:e004::}
Node1# show cef vrf vrf_cust1 12.4.4.4/32 detail
12.4.4.4/32, version 3, SRv6 Headend, internal 0x5000001 0x30 (ptr 0x78b9a61c) [1], 0x0
(0x0), 0x0 (0x88873720)
Updated Feb 23 22:57:56.749
Prefix Len 32, traffic index 0, precedence n/a, priority 3 gateway array (0x88a740a8) reference count 5, flags 0x2010, source rib (7), 0 backups
[1 type 3 flags 0x48441 (0x789cbcc8) ext 0x0 (0x0)]
LW-LDI[type=0, refc=0, ptr=0x0, sh-ldi=0x0] gateway array update type-time 1 Feb 23 22:57:56.749
LDI Update time Feb 23 22:57:56.754
Level 1 - Load distribution: 0
[0] via cafe:0:4::/128, recursive via cafe:0:4::/128, 3 dependencies, recursive [flags 0x6000] path-idx 0 NHID 0x0 [0x78e2da14 0x0] next hop VRF - 'default', table - 0xe0800000 next hop cafe:0:4::/128 via cafe:0:4::/48
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
45
Configure Segment Routing over IPv6 (SRv6)
SRv6 Services: IPv6 L3VPN
SRv6 H.Encaps.Red SID-list {cafe:0:4:e004::}
Load distribution: 0 1 (refcount 1)
Hash OK Interface
0 Y HundredGigE0/0/0/1
1 Y HundredGigE0/0/0/0
Address remote remote
SRv6 Services: IPv6 L3VPN
Table 3: Feature History Table
Feature Name
SRv6 Services: IPv6 L3VPN
Release Information
Release 7.3.1
Feature Description
With this feature, the egress PE can signal an SRv6 Service SID with the BGP overlay service route. The ingress PE encapsulates the
IPv4/IPv6 payload in an outer IPv6 header where the destination address is the SRv6 Service SID provided by the egress PE. BGP messages between PEs carry SRv6
Service SIDs as a means to interconnect PEs and form VPNs.
This feature provides IPv6 L3VPNs (VPNv6) over an SRv6 network.
Usage Guidelines and Limitations
• SRv6 locator can be assigned globally, for all VRFs, or for an individual VRF.
SRv6 locator can be assigned globally, for all VRFs, for an individual VRF, or per-prefix.
• Per-VRF allocation mode is supported (uDT6 behavior)
• Dual-Stack L3VPN Services (IPv4, IPv6) are supported
• Equal-Cost Multi-path (ECMP) and Unequal Cost Multipath (UCMP) are supported.
• eBGP, OSPF, Static are supported as PE-CE protocol.
BGP (iBGP, eBGP), OSPF, Static are supported as PE-CE protocol.
• BGP route leaking between BGP Global and L3VPN is supported.
• Per-CE allocation mode is not supported (uDX6 behavior)
• iBGP is not supported as PE-CE protocol
• BGP route leaking is not supported
46
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing over IPv6 (SRv6)
SRv6 Services: IPv6 L3VPN
Configuring SRv6-based IPv6 L3VPN
To enable SRv6-based L3VPN, you need to enable SRv6 under BGP, specify the locator, and configure the
SID allocation mode. The assignment of the locator can be done in different places under the router bgp configuration. See
SRv6 Locator Inheritance Rules, on page 33 .
Use Case 1: Assigning SRv6 Locator Globally
This example shows how to configure the SRv6 locator name under BGP Global:
Node1(config)# router bgp 100
Node1(config-bgp)# segment-routing srv6
Node1(config-bgp-gbl-srv6)# locator Node1-locator
Node1(config-bgp-gbl-srv6)# exit
Node1(config-bgp)# address-family vpnv6 unicast
Node1(config-bgp-af)# exit
Node1(config-bgp)# neighbor 3001::12:1:1:4
Node1(config-bgp-nbr)# remote-as 100
Node1(config-bgp-nbr)# address-family vpnv6 unicast
Node1(config-bgp-nbr-af)# exit
Node1(config-bgp-nbr)# exit
Node1(config-bgp)# vrf vrf_cust6
Node1(config-bgp-vrf)# rd 100:6
Node1(config-bgp-vrf)# address-family ipv6 unicast
Node1(config-bgp-vrf-af)# commit
Running Configuration router bgp 100 segment-routing srv6
!
locator Node1-locator address-family vpnv6 unicast
!
neighbor 3001::12:1:1:4 remote-as 100 address-family vpnv6 unicast
!
!
!
end
!
!
vrf vrf_cust6 rd 100:6 address-family ipv6 unicast
Use Case 2: Assigning SRv6 Locator for All VRFs
To configure the SRv6 locator for all VRFs under VPNv6 Address Family and specify the allocation mode, use the following commands:
• router bgp as-number address-family vpnv6 unicast vrf all segment-routing srv6 : Enable SRv6
• router bgp as-number address-family vpnv6 unicast vrf all segment-routing srv6 alloc mode
{ per-vrf }: Specify the SID behavior (allocation mode)
• Use the per-vrf keyword to specify that the same service SID (uDT6 behavior) be used for all the routes advertised from a unique VRF.
• router bgp as-number address-family vpnv6 unicast vrf all segment-routing srv6 locator WORD :
Specify the locator
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
47
Configure Segment Routing over IPv6 (SRv6)
SRv6 Services: IPv6 L3VPN
This example shows how to configure the SRv6 locator for all VRFs under VPNv6 Address Family, with per-VRF label allocation mode:
Node1(config)# router bgp 100
Node1(config-bgp)# address-family vpnv6 unicast
Node1(config-bgp-af)# vrf all
Node1(config-bgp-af-vrfall)# segment-routing srv6
Node1(config-bgp-af-vrfall-srv6)# locator Node1-locator
Node1(config-bgp-af-vrfall-srv6)# alloc mode per-vrf
Node1(config-bgp-af-vrfall-srv6)# exit
Node1(config-bgp-af-vrfall)# exit
Node1(config-bgp-af)# exit
Node1(config-bgp)# neighbor 3001::12:1:1:4
Node1(config-bgp-nbr)# remote-as 100
Node1(config-bgp-nbr)# address-family vpnv6 unicast
Node1(config-bgp-nbr-af)# exit
Node1(config-bgp-nbr)# exit
Node1(config-bgp)# vrf vrf_cust6
Node1(config-bgp-vrf)# rd 100:6
Node1(config-bgp-vrf)# address-family ipv6 unicast
Node1(config-bgp-vrf-af)# commit
Running Configuration router bgp 100 address-family vpnv6 unicast vrf all segment-routing srv6 locator Node1-locator
!
!
alloc mode per-vrf
!
neighbor 3001::12:1:1:4 remote-as 100
!
!
!
end address-family vpnv6 unicast
!
!
vrf vrf_cust6 rd 100:6 address-family ipv6 unicast
Use Case 3: Assigning SRv6 Locator for a specific VRF
To configure the SRv6 locator for a specific VRF under IPv6 Address Family and specify the allocation mode, use the following commands:
• router bgp as-number vrf WORD address-family ipv6 unicast segment-routing srv6 : Enable SRv6
• router bgp as-number vrf WORD address-family ipv6 unicast segment-routing srv6 alloc mode { per-vrf }: Specify the SID behavior (allocation mode)
• Use the per-vrf keyword to specify that the same service SID (uDT6 behavior) be used for all the routes advertised from a unique VRF.
• router bgp as-number vrf WORD address-family ipv6 unicast segment-routing srv6 locator WORD :
Specify the locator
48
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing over IPv6 (SRv6)
SRv6 Services: IPv6 L3VPN
This example shows how to configure the SRv6 locator for an individual VRF, with per-VRF label allocation mode:
Node1(config)# router bgp 100
Node1(config-bgp)# address-family vpnv6 unicast
Node1(config-bgp-af)# exit
Node1(config-bgp)# neighbor 3001::12:1:1:4
Node1(config-bgp-nbr)# remote-as 100
Node1(config-bgp-nbr)# address-family vpnv6 unicast
Node1(config-bgp-nbr-af)# exit
Node1(config-bgp-nbr)# exit
Node1(config-bgp)# vrf vrf_cust6
Node1(config-bgp-vrf)# rd 100:6
Node1(config-bgp-vrf)# address-family ipv6 unicast
Node1(config-bgp-vrf-af)# segment-routing srv6
Node1(config-bgp-vrf-af-srv6)# locator Node1-locator
Node1(config-bgp-vrf-af-srv6)# alloc mode per-vrf
Node1(config-bgp-vrf-af-srv6)# commit
Running Configuration router bgp 100 address-family vpnv6 unicast
!
neighbor 3001::12:1:1:4 remote-as 100 address-family vpnv6 unicast
!
!
vrf vrf_cust6 rd 100:6 address-family ipv6 unicast segment-routing srv6
!
!
!
end
!
locator Node1-locator alloc mode per-vrf
Use Case 4: Assigning SRv6 Locator for a Specific Prefix
This use case provides the ability to assign a specific SRv6 locator for a given prefix or a set of prefixes. The egress PE advertises the prefix with the specified locator. This allows for per-prefix steering into desired transport behaviors, such as Flex Algo.
To assign an SRv6 locator for a specific prefix, configure a route policy to specify the SID allocation mode based on match criteria. Examples of match criteria are destination-based match or community-based match.
• Supported SID allocation modes are per-VRF and per-CE.
• For per-VRF allocation mode, you can also specify the SRv6 locator.
• If an SRv6 locator is specified in the route policy, BGP will use that to allocate per-VRF SID. If the specified locator is invalid, the SID will not be allocated.
• If an SRv6 locator is not specified in the route policy, the default locator is used to allocate the SID.
If the default locator is not configured in BGP, then the SID will not be allocated.
• Per-CE allocation mode always uses the default locator configured under BGP to allocate the SID.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
49
Configure Segment Routing over IPv6 (SRv6)
SRv6 Services: IPv6 L3VPN
For more information on configuring routing policies, refer to the "Implementing Routing Policy" chapter in the Routing Configuration Guide for Cisco NCS 560 Series Routers .
The following example shows a route policy specifying the SID allocation mode with destination-based match:
Node1(config)# route-policy set_per_prefix_locator_rpl
Node1(config-rpl)# if destination in (3001::1:1:1:1/128) then
Node1(config-rpl-if)# set srv6-alloc-mode per-vrf locator locator1
Node1(config-rpl-if)# elseif destination in (3001::2:2:2:2/128) then
Node1(config-rpl-elseif)# set srv6-alloc-mode per-vrf locator locator2
Node1(config-rpl-elseif)# elseif destination in (3001::3:3:3:3/128) then
Node1(config-rpl-elseif)# set srv6-alloc-mode per-vrf
Node1(config-rpl-elseif)# elseif destination in (3001::4:4:4:4/128) then
Node1(config-rpl-elseif)# set srv6-alloc-mode per-ce
Node1(config-rpl-elseif)# else
Node1(config-rpl-else)# drop
Node1(config-rpl-else)# endif
Node1(config-rpl)# end-policy
To specify per-prefix allocation mode for a specific VRF under IPv6 Address Family, use the following command:
• router bgp as-number vrf WORD address-family ipv6 unicast segment-routing srv6 alloc mode
route-policy policy_name
This example shows how to specify per-prefix allocation mode for a specific VRF (vrf_cust6) under the IPv6 address family:
Node1(config)# router bgp 100
Node1(config-bgp)# vrf vrf_cust6
Node1(config-bgp-vrf)# address-family ipv6 unicast
Node1(config-bgp-vrf-af)# segment-routing srv6
Node1(config-bgp-vrf-af-srv6)# alloc mode route-policy set_per_prefix_locator_rpl
Running Configuration route-policy set_per_prefix_locator_rpl if destination in ( 3001::1:1:1:1/128 ) then set srv6-alloc-mode per-vrf locator locator1 elseif destination in ( 3001::2:2:2:2/128 ) then set srv6-alloc-mode per-vrf locator locator2 elseif destination in ( 3001::3:3:3:3/128 ) then set srv6-alloc-mode per-vrf elseif destination in ( 3001::4:4:4:4/128 ) then set srv6-alloc-mode per-ce else drop endif end-policy
!
router bgp 100 vrf vrf_cust6 address-family ipv6 unicast
!
!
!
segment-routing srv6 alloc mode route-policy set_per_prefix_locator_rpl
!
50
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing over IPv6 (SRv6)
SRv6 Services: IPv6 L3VPN
Verify that the local and received SIDs have been correctly allocated under VPNv6 and specific VRF
(vrf_cust6):
Node1# show bgp vpnv6 unicast local-sids
BGP router identifier 1.1.1.1, local AS number 1
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0x0 RD version: 0
BGP main routing table version 50
BGP NSR Initial initsync version 18 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs
Status codes: s suppressed, d damped, h history, * valid, > best i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Local Sid Alloc mode Locator
Route Distinguisher: 8:8
*>i3008::8:8:8:8/128 NO SRv6 Sid -
* i NO SRv6 Sid
Route Distinguisher: 100:6 (default for vrf vrf_cust6)
*> 3001::1:1:1:1/128 fc00:0:1:40::
-
-
*> 3001::2:2:2:2/128
*> 3001::3:3:3:3/128 fc00:8:1:40:: fc00:9:1:40:: per-vrf per-vrf per-vrf locator1 locator2 locator4
*> 3001::4:4:4:4/128 fc00:9:1:41::
*> 3001::5:5:5:5/128 NO SRv6 Sid
*> 3001::12:1:1:5/128 NO SRv6 Sid
*>i3008::8:8:8:8/128 NO SRv6 Sid per-ce
-
-
locator4
-
-
-
Node1# show bgp vpnv6 unicast received-sids
BGP router identifier 1.1.1.1, local AS number 1
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0x0 RD version: 0
BGP main routing table version 50
BGP NSR Initial initsync version 18 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs
Status codes: s suppressed, d damped, h history, * valid, > best i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Received Sid
Route Distinguisher: 8:8
*>i3008::8:8:8:8/128 10.1.1.2
* i 2400:2020:42:2fff::1 fc00:0:2:42:: fc00:0:2:42::
Route Distinguisher: 100:6 (default for vrf vrf_cust6)
*> 3001::1:1:1:1/128 11.1.1.2
*> 3001::2:2:2:2/128 11.1.1.2
*> 3001::3:3:3:3/128 11.1.1.2
*> 3001::4:4:4:4/128 11.1.1.2
*> 3001::5:5:5:5/128 11.1.1.2
*> 3001::12:1:1:5/128 13.2.2.2
*>i3008::8:8:8:8/128 10.1.1.2
NO SRv6 Sid
NO SRv6 Sid
NO SRv6 Sid
NO SRv6 Sid
NO SRv6 Sid
NO SRv6 Sid fc00:0:2:42::
Node1# show bgp vrf vrf_cust6 local-sids
BGP VRF vrf_cust6, state: Active
BGP Route Distinguisher: 1.1.1.1:0
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
51
Configure Segment Routing over IPv6 (SRv6)
SRv6 Services: IPv6 L3VPN
VRF ID: 0x60000004
BGP router identifier 1.1.1.1, local AS number 1
Non-stop routing is enabled
BGP table state: Active
Table ID: 0xe0000013 RD version: 37
BGP main routing table version 37
BGP NSR Initial initsync version 18 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
Status codes: s suppressed, d damped, h history, * valid, > best i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Local Sid
Route Distinguisher: 8:8
Alloc mode Locator
*>i3008::8:8:8:8/128
* i
NO SRv6 Sid
NO SRv6 Sid
Route Distinguisher: 100:6 (default for vrf vrf_cust6)
*> 3001::1:1:1:1/128 fc00:0:1:40::
*> 3001::2:2:2:2/128 fc00:8:1:40::
-
-
-
-
*> 3001::3:3:3:3/128
*> 3001::4:4:4:4/128
*> 3001::5:5:5:5/128 fc00:9:1:40:: fc00:9:1:41::
NO SRv6 Sid
*> 3001::12:1:1:5/128 NO SRv6 Sid
*>i3008::8:8:8:8/128 NO SRv6 Sid
-
per-vrf per-vrf per-vrf per-ce
-
-
locator1 locator2 locator4 locator4
-
Node1# show bgp vrf vrf_cust6 received-sids
BGP VRF vrf_cust6, state: Active
BGP Route Distinguisher: 100:6
VRF ID: 0x60000004
BGP router identifier 1.1.1.1, local AS number 1
Non-stop routing is enabled
BGP table state: Active
Table ID: 0xe0000013 RD version: 37
BGP main routing table version 37
BGP NSR Initial initsync version 18 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
Status codes: s suppressed, d damped, h history, * valid, > best i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Received Sid
Route Distinguisher: 100:6 (default for vrf vrf_cust6)
*> 3001::1:1:1:1/128 11.1.1.2
NO SRv6 Sid
*> 3001::2:2:2:2/128 11.1.1.2
*> 3001::3:3:3:3/128 11.1.1.2
*> 3001::4:4:4:4/128 11.1.1.2
*> 3001::5:5:5:5/128 11.1.1.2
*> 3001::12:1:1:5/128 13.2.2.2
*>i3008::8:8:8:8/128 10.1.1.2
NO SRv6 Sid
NO SRv6 Sid
NO SRv6 Sid
NO SRv6 Sid
NO SRv6 Sid fc00:0:2:42::
Verification
The following figure shows a VPNv6 scenario. The sequence of commands included correspond to router
Node1 acting as Ingress PE, and routers Node4 and Node5 acting as Egress PEs.
52
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing over IPv6 (SRv6)
SRv6 Services: IPv6 L3VPN
The following examples shows how to verify the SRv6 based L3VPN configurations for an Individual VRF with per VRF label allocation mode.
In this example, we can observe the uDT6 SID associated with the IPv6 L3VPN, where uDT6 behavior represents Endpoint with decapsulation and IPv6 table lookup.
Node1# show segment-routing srv6 sid
Fri Jan 29 19:31:53.293 UTC
*** Locator: 'Node1-locator' ***
SID cafe:0:1::
InUse Y
Behavior Context
State RW
----------------------------------------------------------------------
----------------------uN (PSP/USD) 'default':1 uA (PSP/USD) [Hu0/0/0/0, Link-Local]:0 cafe:0:1:e000::
InUse Y cafe:0:1:e001::
InUse Y cafe:0:1:e002:: uA (PSP/USD) uDT4
[Hu0/0/0/1, Link-Local]:0
'vrf_cust1'
InUse Y cafe:0:1:e003::
InUse Y cafe:0:1:e004::
InUse Y cafe:0:1:e005::
InUse Y cafe:0:1:e006::
InUse Y cafe:0:1:e007::
InUse Y cafe:0:1:e008::
InUse Y cafe:0:1:e009::
InUse Y cafe:0:1:e00a:: uDT4 uDT4 uDT4 uDT4 uA (PSP/USD) uA (PSP/USD) uDT6 uDT6
'vrf_cust2'
'vrf_cust3'
'vrf_cust4'
'vrf_cust5'
[Hu0/0/0/0, Link-Local]:0:P
[Hu0/0/0/1, Link-Local]:0:P
'default'
'vrf_cust6'
Owner sidmgr isis-1 isis-1 bgp-100 bgp-100 bgp-100 bgp-100 bgp-100 isis-1 isis-1 bgp-100 bgp-100
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
53
Configure Segment Routing over IPv6 (SRv6)
SRv6 Services: IPv6 L3VPN
InUse Y
The following examples show how to verify the SRv6 based L3VPN configuration using the show bgp vpnv6 unicast commands on the Ingress PE.
Node1# show bgp vpnv6 unicast summary
Fri Jan 29 19:33:01.177 UTC
BGP router identifier 1.1.1.1, local AS number 100
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0x0 RD version: 0
BGP main routing table version 6
BGP NSR Initial initsync version 4 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs
BGP is operating in STANDALONE mode.
Process
Speaker
Neighbor cafe:0:4::4 cafe:0:5::5
RcvTblVer bRIB/RIB LabelVer ImportVer SendTblVer StandbyVer
6 6 6 6 6 0
Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd
0 100 122 123 6 0 0 00:20:05 1
0 100 111 111 0 0 0 00:49:46 1
Node1# show bgp vpnv6 unicast rd 100:6
Fri Jan 29 19:41:01.334 UTC
BGP router identifier 1.1.1.1, local AS number 100
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0x0 RD version: 0
BGP main routing table version 8
BGP NSR Initial initsync version 4 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs
Status codes: s suppressed, d damped, h history, * valid, > best i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 100:6 (default for vrf vrf_cust6)
*> 3001::12:1:1:1/128 :: 0 32768 ?
*>i3001::12:1:1:4/128 cafe:0:4::4
*>i3001::12:1:1:5/128 cafe:0:5::5
0
0
100
100
0 ?
0 ?
Processed 3 prefixes, 3 paths
Node1# show bgp vpnv6 unicast rd 100:6 3001::12:1:1:4/128
Fri Jan 29 19:41:42.008 UTC
BGP routing table entry for 3001::12:1:1:4/128, Route Distinguisher: 100:6
Versions:
Process bRIB/RIB SendTblVer
Speaker 6 6
Last Modified: Jan 29 19:29:35.858 for 00:12:06
Paths: (1 available, best #1)
Not advertised to any peer
Path #1: Received by speaker 0
Not advertised to any peer
Local, (received & used) cafe:0:4::4 (metric 30) from cafe:0:4::4 (1.1.1.4)
54
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing over IPv6 (SRv6)
SRv6 Services: IPv6 L3VPN
Received Label 0xe00a00
Origin incomplete, metric 0, localpref 100, valid, internal, best, group-best, import-candidate, imported
Received Path ID 0, Local Path ID 1, version 6
Extended community: RT:100:6
PSID-Type:L3, SubTLV Count:1
SubTLV:
T:1(Sid information), Sid:cafe:0:4::, Behavior:62, SS-TLV Count:1
SubSubTLV:
T:1(Sid structure):
Source AFI: VPNv6 Unicast, Source VRF: vrf_cust6, Source Route Distinguisher: 100:6
The following examples show how to verify the BGP prefix information for VRF instances:
Node1# show bgp vrf vrf_cust6 ipv6 unicast
Fri Jan 29 19:42:05.675 UTC
BGP VRF vrf_cust6, state: Active
BGP Route Distinguisher: 100:6
VRF ID: 0x60000007
BGP router identifier 1.1.1.1, local AS number 100
Non-stop routing is enabled
BGP table state: Active
Table ID: 0xe0800016 RD version: 8
BGP main routing table version 8
BGP NSR Initial initsync version 4 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
Status codes: s suppressed, d damped, h history, * valid, > best i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 100:6 (default for vrf vrf_cust6)
*> 3001::12:1:1:1/128 :: 0 32768 ?
*>i3001::12:1:1:4/128 cafe:0:4::4
*>i3001::12:1:1:5/128 cafe:0:5::5
0
0
100
100
0 ?
0 ?
Processed 3 prefixes, 3 paths
Node1# show bgp vrf vrf_cust6 ipv6 unicast 3001::12:1:1:4/128
BGP routing table entry for 3001::12:1:1:4/128, Route Distinguisher: 100:6
Versions:
Process bRIB/RIB SendTblVer
Speaker 17 17
Last Modified: Jan 15 16:50:44.032 for 01:48:21
Paths: (1 available, best #1)
Not advertised to any peer
Path #1: Received by speaker 0
Not advertised to any peer
Local, (received & used) cafe:0:4::4 (metric 30) from cafe:0:4::4 (1.1.1.4)
Received Label 0xe00a00
Origin incomplete, metric 0, localpref 100, valid, internal, best, group-best, import-candidate, imported
Received Path ID 0, Local Path ID 1, version 17
Extended community: RT:100:6
PSID-Type:L3, SubTLV Count:1
SubTLV:
T:1(Sid information), Sid:cafe:0:4::, Behavior:62, SS-TLV Count:1
SubSubTLV:
T:1(Sid structure):
Source AFI: VPNv6 Unicast, Source VRF: vrf_cust6, Source Route Distinguisher: 100:6
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
55
Configure Segment Routing over IPv6 (SRv6)
SRv6 Services: IPv6 L3VPN
The following examples show how to verify the current routes in the Routing Information Base (RIB):
Node1# show route vrf vrf_cust6 ipv6 unicast
Fri Jan 29 19:43:28.067 UTC
Codes: C - connected, S - static, R - RIP, B - BGP, (>) - Diversion path
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - ISIS, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, su - IS-IS summary null, * - candidate default
U - per-user static route, o - ODR, L - local, G - DAGR, l - LISP
A - access/subscriber, a - Application route
M - mobile route, r - RPL, t - Traffic Engineering, (!) - FRR Backup path
Gateway of last resort is not set
L
B
B
3001::12:1:1:1/128 is directly connected,
01:01:23, Loopback105
3001::12:1:1:4/128
[200/0] via cafe:0:4::4 (nexthop in vrf default), 00:13:52
3001::12:1:1:5/128
[200/0] via cafe:0:5::5 (nexthop in vrf default), 00:05:53
Node1# show route vrf vrf_cust6 ipv6 unicast 3001::12:1:1:4/128
Fri Jan 29 19:43:55.645 UTC
Routing entry for 3001::12:1:1:4/128
Known via "bgp 100", distance 200, metric 0, type internal
Installed Jan 29 19:29:35.696 for 00:14:20
Routing Descriptor Blocks cafe:0:4::4, from cafe:0:4::4
Nexthop in Vrf: "default", Table: "default", IPv6 Unicast, Table Id: 0xe0800000
Route metric is 0
No advertising protos.
Node1# show route vrf vrf_cust6 ipv6 unicast 3001::12:1:1:4/128 detail
Fri Jan 29 19:44:17.914 UTC
Routing entry for 3001::12:1:1:4/128
Known via "bgp 100", distance 200, metric 0, type internal
Installed Jan 29 19:29:35.696 for 00:14:42
Routing Descriptor Blocks cafe:0:4::4, from cafe:0:4::4
Nexthop in Vrf: "default", Table: "default", IPv6 Unicast, Table Id: 0xe0800000
Route metric is 0
Label: None
Tunnel ID: None
Binding Label: None
Extended communities count: 0
Source RD attributes: 0x0000:100:6
NHID:0x0(Ref:0)
SRv6 Headend: H.Encaps.Red [f3216], SID-list {cafe:0:4:e00a::}
Route version is 0x1 (1)
No local label
IP Precedence: Not Set
QoS Group ID: Not Set
Flow-tag: Not Set
Fwd-class: Not Set
Route Priority: RIB_PRIORITY_RECURSIVE (12) SVD Type RIB_SVD_TYPE_REMOTE
Download Priority 3, Download Version 3
No advertising protos.
56
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing over IPv6 (SRv6)
SRv6 Services: IPv6 L3VPN
The following examples show how to verify the current IPv6 Cisco Express Forwarding (CEF) table:
Node1# show cef vrf vrf_cust6 ipv6
Fri Jan 29 19:44:56.888 UTC
::/0 drop default handler
3001::12:1:1:1/128 receive Loopback105
3001::12:1:1:4/128 recursive cafe:0:4::/128
3001::12:1:1:5/128 recursive cafe:0:5::/128 fe80::/10 receive ff02::/16 receive ff02::2/128 receive ff02::1:ff00:0/104 receive ff05::/16 receive ff12::/16 receive
Node1# show cef vrf vrf_cust6 ipv6 3001::12:1:1:4/128
Fri Jan 29 19:45:23.607 UTC
3001::12:1:1:4/128, version 3, SRv6 Headend, internal 0x5000001 0x30 (ptr 0x78f2e0e0) [1],
0x0 (0x0), 0x0 (0x888a3ac8)
Updated Jan 29 19:29:35.700
Prefix Len 128, traffic index 0, precedence n/a, priority 3 via cafe:0:4::/128, 7 dependencies, recursive [flags 0x6000] path-idx 0 NHID 0x0 [0x78cd2a14 0x0] next hop VRF - 'default', table - 0xe0800000 next hop cafe:0:4::/128 via cafe:0:4::/48
SRv6 H.Encaps.Red SID-list {cafe:0:4:e00a::}
Node1# show cef vrf vrf_cust6 ipv6 3001::12:1:1:4/128 detail
Fri Jan 29 19:45:55.847 UTC
3001::12:1:1:4/128, version 3, SRv6 Headend, internal 0x5000001 0x30 (ptr 0x78f2e0e0) [1],
0x0 (0x0), 0x0 (0x888a3ac8)
Updated Jan 29 19:29:35.700
Prefix Len 128, traffic index 0, precedence n/a, priority 3 gateway array (0x78afe238) reference count 1, flags 0x2010, source rib (7), 0 backups
[1 type 3 flags 0x48441 (0x78ba9a60) ext 0x0 (0x0)]
LW-LDI[type=0, refc=0, ptr=0x0, sh-ldi=0x0] gateway array update type-time 1 Jan 29 19:29:35.699
LDI Update time Jan 29 19:29:35.701
Level 1 - Load distribution: 0
[0] via cafe:0:4::/128, recursive via cafe:0:4::/128, 7 dependencies, recursive [flags 0x6000] path-idx 0 NHID 0x0 [0x78cd2a14 0x0] next hop VRF - 'default', table - 0xe0800000 next hop cafe:0:4::/128 via cafe:0:4::/48
SRv6 H.Encaps.Red SID-list {cafe:0:4:e00a::}
Load distribution: 0 1 (refcount 1)
Hash OK Interface
0 Y HundredGigE0/0/0/0
Address remote
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
57
Configure Segment Routing over IPv6 (SRv6)
SRv6 Services: IPv4 BGP Global
1 Y HundredGigE0/0/0/1 remote
SRv6 Services: IPv4 BGP Global
This feature extends support of SRv6-based BGP services to include IPv4 global BGP by implementing uDT4
SRv6 functions at the PE node ( draft-ietf-bess-srv6-services ).
Usage Guidelines and Limitations
• SRv6 locator can be assigned globally or under IPv4 unicast address family
• Equal-Cost Multi-path (ECMP) and Unequal Cost Multipath (UCMP) are supported.
• BGP, OSPF, Static are supported as PE-CE protocol.
• BGP route leaking between BGP Global and L3VPN is supported.
BGP Global IPv4 Over SRv6 with Per-AFI SID Allocation Mode (uDT4)
To configure BGP global IPv4 over SRv6, use the following commands:
• router bgp as-number address-family ipv4 unicast segment-routing srv6 : Enable SRv6
• router bgp as-number address-family ipv4 unicast segment-routing srv6 alloc mode per-vrf : Specify the SID behavior (allocation mode).
The per-vrf keyword specifies that the same label is be used for all the routes advertised from a unique
VRF.
• router bgp as-number address-family ipv4 unicast segment-routing srv6 alloc mode { per-vrf |
route-policy policy_name }: Specify the SID behavior (allocation mode).
• per-vrf : Specifies that the same label is be used for all the routes advertised from a unique VRF.
• route-policy policy_name : Uses a route policy to determine the SID allocation mode and locator
(if provided) for given prefix.
• router bgp as-number address-family ipv4 unicast segment-routing srv6 locator WORD : Specify the locator
• router bgp as-number { af-group WORD | neighbor-group WORD | neighbor ipv6-addr } address-family ipv4 unicast encapsulation-type srv6 : Specify the encapuslation type for SRv6.
• Use af-group WORD to apply the SRv6 encapsulation type to the address family group for BGP neighbors.
• Use neighbor-group WORD to apply the SRv6 encapsulation type to the neighbor group for BGP neighbors.
• Use neighbor ipv6-addr to apply the SRv6 encapsulation type to the specific BGP neighbor.
Use Case 1: BGP Global IPv4 over SRv6 with Per-AFI SID Allocation
The following example shows how to configure BGP global IPv4 over SRv6 with per-AFI SID allocation.
58
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing over IPv6 (SRv6)
SRv6 Services: IPv4 BGP Global
Node1(config)# router bgp 1
Node1(config-bgp)# bgp router-id 10.1.0.1
Node1(config-bgp)# address-family ipv4 unicast
Node1(config-bgp-af)# segment-routing srv6
Node1(config-bgp-af-srv6)# locator Node1
Node1(config-bgp-af-srv6)# alloc mode per-vrf
Node1(config-bgp-af-srv6)# exit
Node1(config-bgp-af)# exit
Node1(config-bgp)# neighbor 60::2
Node1(config-bgp-nbr)# remote-as 1
Node1(config-bgp-nbr)# update-source Loopback1
Node1(config-bgp-nbr)# address-family ipv4 unicast
Node1(config-bgp-nbr-af)# encapsulation-type srv6
Node1(config-bgp-nbr-af)# exit
Node1(config-bgp-nbr)# exit
Node1(config-bgp)# neighbor 52.52.52.1
Node1(config-bgp-nbr)# remote-as 3
Node1(config-bgp-nbr)# address-family ipv4 unicast
Node1(config-bgp-nbr-af)# route-policy passall in
Node1(config-bgp-nbr-af)# route-policy passall out
Node1(config-bgp-nbr-af)# commit
Running Configuration router bgp 1 bgp router-id 10.1.0.1
address-family ipv4 unicast segment-routing srv6 locator Node1 alloc mode per-vrf
!
!
neighbor 60::2 remote-as 1 update-source Loopback1 address-family ipv4 unicast encapsulation-type srv6
!
!
neighbor 52.52.52.1
remote-as 3 address-family ipv4 unicast route-policy passall in
!
!
!
route-policy passall out
Use Case 2: BGP Global IPv4 over SRv6 with Per-Prefix SID Allocation
This use case provides the ability to assign a specific SRv6 locator for a given prefix or a set of prefixes. The egress PE advertises the prefix with the specified locator. This allows for per-prefix steering into desired transport behaviors, such as Flex Algo.
To assign an SRv6 locator for a specific prefix, configure a route policy to specify the SID allocation mode based on match criteria. Examples of match criteria are destination-based match or community-based match.
• Supported SID allocation modes are per-VRF and per-CE.
• For per-VRF allocation mode, you can also specify the SRv6 locator.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
59
Configure Segment Routing over IPv6 (SRv6)
SRv6 Services: IPv4 BGP Global
• If an SRv6 locator is specified in the route policy, BGP will use that to allocate per-VRF SID. If the specified locator is invalid, the SID will not be allocated.
• If an SRv6 locator is not specified in the route policy, the default locator is used to allocate the SID.
If the default locator is not configured in BGP, then the SID will not be allocated.
• Per-CE allocation mode always uses the default locator to allocate the SID.
For more information on configuring routing policies, refer to the "Implementing Routing Policy" chapter in the Routing Configuration Guide for Cisco NCS 560 Series Routers .
The following example shows a route policy specifying the SID allocation mode with destination-based match:
Node1(config)# route-policy set_per_prefix_locator_rpl
Node1(config-rpl)# if destination in (1.1.1.0/24) then
Node1(config-rpl-if)# set srv6-alloc-mode per-vrf locator locator1
Node1(config-rpl-if)# elseif destination in (2.2.2.0/24) then
Node1(config-rpl-elseif)# set srv6-alloc-mode per-vrf locator locator2
Node1(config-rpl-elseif)# elseif destination in (3.3.3.0/24) then
Node1(config-rpl-elseif)# set srv6-alloc-mode per-vrf
Node1(config-rpl-elseif)# elseif destination in (4.4.4.0/24) then
Node1(config-rpl-elseif)# set srv6-alloc-mode per-ce
Node1(config-rpl-elseif)# else
Node1(config-rpl-else)# drop
Node1(config-rpl-else)# endif
Node1(config-rpl)# end-policy
Node1(config)#
The following example shows how to configure BGP global IPv4 over SRv6 with a route policy to determine the SID allocation mode for given prefix.
Node1(config)# router bgp 100
Node1(config-bgp)# address-family ipv4 unicast
Node1(config-bgp-af)# segment-routing srv6
Node1(config-bgp-af-srv6)# alloc mode route-policy set_per_prefix_locator_rpl
Running Configuration route-policy set_per_prefix_locator_rpl if destination in ( 1.1.1.0/24 ) then set srv6-alloc-mode per-vrf locator locator1 elseif destination in ( 2.2.2.0/24 ) then set srv6-alloc-mode per-vrf locator locator2 elseif destination in ( 3.3.3.0/24 ) then set srv6-alloc-mode per-vrf elseif destination in ( 4.4.4.0/24 ) then set srv6-alloc-mode per-ce else drop endif end-policy
!
router bgp 100 address-family ipv4 unicast
!
!
segment-routing srv6 alloc mode route-policy set_per_prefix_locator_rpl
!
60
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing over IPv6 (SRv6)
SRv6 Services: IPv6 BGP Global
Verify that the local and received SIDs have been correctly allocated under BGP IPv4 address family:
Node1# show bgp ipv4 unicast local-sids
…
Status codes: s suppressed, d damped, h history, * valid, > best i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Local Sid Alloc mode Locator
*> 1.1.1.0/24
*> 2.2.2.0/24 fc00:8:1:41:: fc00:0:1:41:: per-vrf per-vrf locator2 locator1
*> 3.3.3.0/24
*> 4.4.4.0/24
*> 1.1.1.5/32
* i8.8.8.8/32 fc00:9:1:42:: fc00:9:1:43::
NO SRv6 Sid
NO SRv6 Sid per-vrf per-ce
-
locator4 locator4
-
-
Node1# show bgp ipv4 unicast received-sids
…
Status codes: s suppressed, d damped, h history, * valid, > best i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Received Sid
*> 1.1.1.0/24
*> 2.2.2.0/24
*> 3.3.3.0/24
*> 4.4.4.0/24
*> 1.1.1.5/32
* i8.8.8.8/32
66.2.2.2
66.2.2.2
66.2.2.2
66.2.2.2
66.2.2.2
77.1.1.2
NO SRv6 Sid
NO SRv6 Sid
NO SRv6 Sid
NO SRv6 Sid
NO SRv6 Sid fc00:0:2:41::
SRv6 Services: IPv6 BGP Global
Table 4: Feature History Table
Feature Name
SRv6 Services: BGP Global IPv6
Release Information
Release 7.3.1
Feature Description
With this feature, the egress PE can signal an SRv6 Service SID with the BGP global route. The ingress
PE encapsulates the IPv4/IPv6 payload in an outer IPv6 header where the destination address is the
SRv6 Service SID provided by the egress PE. BGP messages between
PEs carry SRv6 Service SIDs as a means to interconnect PEs.
This feature extends support of SRv6-based BGP services to include IPv6 global BGP by implementing uDT6
SRv6 functions at the PE node ( draft-ietf-bess-srv6-services ).
Usage Guidelines and Limitations
• SRv6 locator can be assigned globally or under IPv6 unicast address family
• Equal-Cost Multi-path (ECMP) and Unequal Cost Multipath (UCMP) are supported.
• BGP, OSPF, Static are supported as PE-CE protocol.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
61
Configure Segment Routing over IPv6 (SRv6)
SRv6 Services: IPv6 BGP Global
• BGP route leaking between BGP Global and L3VPN is supported.
BGP Global IPv6 Over SRv6 with Per-AFI SID Allocation Mode (uDT6)
To configure BGP global IPv6 over SRv6, use the following commands:
• router bgp as-number address-family ipv6 unicast segment-routing srv6 : Enable SRv6
• router bgp as-number address-family ipv6 unicast segment-routing srv6 alloc mode per-vrf : Specify the SID behavior (allocation mode).
The per-vrf keyword specifies that the same label is be used for all the routes advertised from a unique
VRF.
• router bgp as-number address-family ipv6 unicast segment-routing srv6 alloc mode { per-vrf |
route-policy policy_name }: Specify the SID behavior (allocation mode).
• per-vrf : Specifies that the same label is be used for all the routes advertised from a unique VRF.
• route-policy policy_name : Uses a route policy to determine the SID allocation mode and locator
(if provided) for given prefix.
• router bgp as-number address-family ipv6 unicast segment-routing srv6 locator WORD : Specify the locator
• router bgp as-number { af-group WORD | neighbor-group WORD | neighbor ipv6-addr } address-family ipv6 unicast encapsulation-type srv6 : Specify the encapuslation type for SRv6.
• Use af-group WORD to apply the SRv6 encapsulation type to the address family group for BGP neighbors.
• Use neighbor-group WORD to apply the SRv6 encapsulation type to the neighbor group for Border
Gateway Protocol (BGP) neighbors.
• Use neighbor ipv6-addr to apply the SRv6 encapsulation type to the specific BGP neighbor.
Use Case 1: BGP Global IPv6 over SRv6 with Per-AFI SID Allocation
The following example shows how to configure BGP global IPv6 over SRv6 with per-AFI SID allocation.
Node1(config)# router bgp 100
Node1(config-bgp)# bgp router-id 1.1.1.1
Node1(config-bgp)# segment-routing srv6
Node1(config-bgp-gbl-srv6)# locator Node1
Node1(config-bgp-gbl-srv6)# exit
Node1(config-bgp)# address-family ipv6 unicast
Node1(config-bgp-af)# segment-routing srv6
Node1(config-bgp-af-srv6)# locator Node1
Node1(config-bgp-af-srv6)# alloc mode per-vrf
Node1(config-bgp-af-srv6)# exit
Node1(config-bgp-af)# exit
Node1(config-bgp)# neighbor cafe:0:4::4
Node1(config-bgp-nbr)# address-family ipv6 unicast
Node1(config-bgp-nbr-af)# encapsulation-type srv6
Node1(config-bgp-nbr-af)# exit
Node1(config-bgp-nbr)# exit
Node1(config-bgp)# neighbor cafe:0:5::5
Node1(config-bgp-nbr)# address-family ipv6 unicast
Node1(config-bgp-nbr-af)# encapsulation-type srv6
62
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing over IPv6 (SRv6)
SRv6 Services: IPv6 BGP Global
Node1(config-bgp-nbr-af)# commit
Running Configuration router bgp 100 bgp router-id 1.1.1.1
segment-routing srv6
!
locator Node1 address-family ipv6 unicast segment-routing srv6 locator Node1 alloc mode per-vrf
!
!
neighbor cafe:0:4::4 address-family ipv6 unicast encapsulation-type srv6
!
!
neighbor cafe:0:5::5 address-family ipv6 unicast encapsulation-type srv6
Use Case 2: BGP Global IPv6 over SRv6 with Per-Prefix SID Allocation
This use case provides the ability to assign a specific SRv6 locator for a given prefix or a set of prefixes. The egress PE advertises the prefix with the specified locator. This allows for per-prefix steering into desired transport behaviors, such as Flex Algo.
To assign an SRv6 locator for a specific prefix, configure a route policy to specify the SID allocation mode based on match criteria. Examples of match criteria are destination-based match or community-based match.
• Supported SID allocation modes are per-VRF and per-CE.
• For per-VRF allocation mode, you can also specify the SRv6 locator.
• If an SRv6 locator is specified in the route policy, BGP will use that to allocate per-VRF SID. If the specified locator is invalid, the SID will not be allocated.
• If an SRv6 locator is not specified in the route policy, the default locator is used to allocate the SID.
If the default locator is not configured in BGP, then the SID will not be allocated.
• Per-CE allocation mode always uses the default locator to allocate the SID.
For more information on configuring routing policies, refer to the "Implementing Routing Policy" chapter in the Routing Configuration Guide for Cisco NCS 560 Series Routers .
The following example shows a route policy specifying the SID allocation mode with destination-based match:
Node1(config)# route-policy set_per_prefix_locator_rpl
Node1(config-rpl)# if destination in (3001::1:1:1:1/128) then
Node1(config-rpl-if)# set srv6-alloc-mode per-vrf locator locator1
Node1(config-rpl-if)# elseif destination in (3001::2:2:2:2/128) then
Node1(config-rpl-elseif)# set srv6-alloc-mode per-vrf locator locator2
Node1(config-rpl-elseif)# elseif destination in (3001::3:3:3:3/128) then
Node1(config-rpl-elseif)# set srv6-alloc-mode per-vrf
Node1(config-rpl-elseif)# elseif destination in (3001::4:4:4:4/128) then
Node1(config-rpl-elseif)# set srv6-alloc-mode per-ce
Node1(config-rpl-elseif)# else
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
63
Configure Segment Routing over IPv6 (SRv6)
SRv6 Services: IPv6 BGP Global
Node1(config-rpl-else)# drop
Node1(config-rpl-else)# endif
Node1(config-rpl)# end-policy
The following example shows how to configure BGP global IPv6 over SRv6 with a route policy to determine the SID allocation mode for given prefix.
Node1(config)# router bgp 100
Node1(config-bgp)# address-family ipv6 unicast
Node1(config-bgp-af)# segment-routing srv6
Node1(config-bgp-af-srv6)# alloc mode route-policy set_per_prefix_locator_rpl
Running Configuration route-policy set_per_prefix_locator_rpl if destination in ( 3001::1:1:1:1/128 ) then set srv6-alloc-mode per-vrf locator locator1 elseif destination in ( 3001::2:2:2:2/128 ) then set srv6-alloc-mode per-vrf locator locator2 elseif destination in ( 3001::3:3:3:3/128 ) then set srv6-alloc-mode per-vrf elseif destination in ( 3001::4:4:4:4/128 ) then set srv6-alloc-mode per-ce else drop endif end-policy
!
router bgp 100 address-family ipv6 unicast segment-routing srv6
!
!
alloc mode route-policy set_per_prefix_locator_rpl
Verify that the local and received SIDs have been correctly allocated under BGP IPv6 address family:
Node1# show bgp ipv6 unicast local-sids
…
Status codes: s suppressed, d damped, h history, * valid, > best i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Local Sid
*> 3001::1:1:1:1/128 fc00:8:1:41::
Alloc mode Locator per-vrf locator2
*> 3001::2:2:2:2/128 fc00:0:1:41::
*> 3001::3:3:3:3/128 fc00:9:1:42::
*> 3001::4:4:4:4/128 fc00:9:1:43::
*> 3001::5:5:5:5/128 NO SRv6 Sid
* i3008::8:8:8:8/128 NO SRv6 Sid per-vrf per-vrf per-ce
-
locator1 locator4 locator4
-
-
Node1# show bgp ipv6 unicast received-sids
…
Status codes: s suppressed, d damped, h history, * valid, > best i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop
*> 3001::1:1:1:1/128 66.2.2.2
*> 3001::2:2:2:2/128 66.2.2.2
Received Sid
NO SRv6 Sid
NO SRv6 Sid
*> 3001::3:3:3:3/128 66.2.2.2
*> 3001::4:4:4:4/128 66.2.2.2
*> 3001::5:5:5:5/128 66.2.2.2
NO SRv6 Sid
NO SRv6 Sid
NO SRv6 Sid
64
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing over IPv6 (SRv6)
SRv6 Services: IPv6 BGP Global
* i3008::8:8:8:8/128 77.1.1.2
fc00:0:2:41::
Verification
The following figure shows a IPv6 BGP global scenario. The sequence of commands included correspond to router Node1 acting as Ingress PE, and routers Node4 and Node5 acting as Egress PEs.
The following examples show how to verify the BGP global IPv6 configuration using the show bgp ipv6 unicast commands.
Node1# show bgp ipv6 unicast summary
Fri Jan 29 19:48:23.255 UTC
BGP router identifier 1.1.1.1, local AS number 100
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0xe0800000 RD version: 4
BGP main routing table version 4
BGP NSR Initial initsync version 2 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs
BGP is operating in STANDALONE mode.
Process
Speaker
Neighbor cafe:0:4::4 cafe:0:5::5
RcvTblVer
4 bRIB/RIB
4
LabelVer
4
ImportVer
Node1# show bgp ipv6 unicast
Fri Jan 29 19:49:05.688 UTC
BGP router identifier 1.1.1.1, local AS number 100
BGP generic scan interval 60 secs
Non-stop routing is enabled
4
SendTblVer
4
StandbyVer
0
Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd
0 100 137 138 4 0 0 00:35:27 1
0 100 138 137 4 0 0 00:10:54 1
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
65
Configure Segment Routing over IPv6 (SRv6)
SRv6 Services: IPv6 BGP Global
BGP table state: Active
Table ID: 0xe0800000 RD version: 4
BGP main routing table version 4
BGP NSR Initial initsync version 2 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs
Status codes: s suppressed, d damped, h history, * valid, > best i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 3001::13:1:1:1/128 :: 0 32768 i
*>i3001::13:1:1:4/128 cafe:0:4::4
*>i3001::13:1:1:5/128 cafe:0:5::5
0
0
100
100
0 i
0 i
Processed 3 prefixes, 3 paths
Node1# show bgp ipv6 unicast 3001::13:1:1:4/128
Fri Jan 29 19:49:22.067 UTC
BGP routing table entry for 3001::13:1:1:4/128
Versions:
Process bRIB/RIB SendTblVer
Speaker 3 3
Last Modified: Jan 29 19:14:13.858 for 00:35:08
Paths: (1 available, best #1)
Not advertised to any peer
Path #1: Received by speaker 0
Not advertised to any peer
Local cafe:0:4::4 (metric 30) from cafe:0:4::4 (1.1.1.4)
Origin IGP, metric 0, localpref 100, valid, internal, best, group-best
Received Path ID 0, Local Path ID 1, version 3
PSID-Type:L3, SubTLV Count:1
SubTLV:
T:1(Sid information), Sid:cafe:0:4:e009::, Behavior:62, SS-TLV Count:1
SubSubTLV:
T:1(Sid structure):
The following examples show how to verify the current routes in the Routing Information Base (RIB):
Node1# show route ipv6 3001::13:1:1:4/128
Fri Jan 29 19:53:26.839 UTC
Routing entry for 3001::13:1:1:4/128
Known via "bgp 100", distance 200, metric 0, type internal
Installed Jan 29 19:14:13.397 for 00:35:28
Routing Descriptor Blocks cafe:0:4::4, from cafe:0:4::4
Route metric is 0
No advertising protos.
Node1# show route ipv6 3001::13:1:1:4/128 detail
Fri Jan 29 19:50:08.601 UTC
Routing entry for 3001::13:1:1:4/128
Known via "bgp 100", distance 200, metric 0, type internal
Installed Jan 29 19:14:13.397 for 00:35:55
Routing Descriptor Blocks cafe:0:4::4, from cafe:0:4::4
Route metric is 0
Label: None
Tunnel ID: None
Binding Label: None
66
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing over IPv6 (SRv6)
SRv6 Services: IPv4 L3VPN Active-Standby Redundancy using Port-Active Mode
Extended communities count: 0
NHID:0x0(Ref:0)
SRv6 Headend: H.Encaps.Red [f3216], SID-list {cafe:0:4:e009::}
Route version is 0x1 (1)
No local label
IP Precedence: Not Set
QoS Group ID: Not Set
Flow-tag: Not Set
Fwd-class: Not Set
Route Priority: RIB_PRIORITY_RECURSIVE (12) SVD Type RIB_SVD_TYPE_LOCAL
Download Priority 4, Download Version 106
No advertising protos.
The following examples show how to verify the current IPv6 Cisco Express Forwarding (CEF) table:
Node1# show cef ipv6 3001::13:1:1:4/128
Fri Jan 29 19:50:29.149 UTC
3001::13:1:1:4/128, version 106, SRv6 Headend, internal 0x5000001 0x40 (ptr 0x78
[1], 0x0 (0x0), 0x0 (0x888a3a80)
Updated Jan 29 19:14:13.401
Prefix Len 128, traffic index 0, precedence n/a, priority 4 via cafe:0:4::/128, 7 dependencies, recursive [flags 0x6000] path-idx 0 NHID 0x0 [0x78cd2a14 0x0] next hop cafe:0:4::/128 via cafe:0:4::/48
SRv6 H.Encaps.Red SID-list {cafe:0:4:e009::} cd3944)
Node1# show cef ipv6 3001::13:1:1:4/128 detail
Fri Jan 29 19:51:00.920 UTC
3001::13:1:1:4/128, version 106, SRv6 Headend, internal 0x5000001 0x40 (ptr 0x78cd3944)
[1], 0x0 (0x0), 0x0 (0x888a3a80)
Updated Jan 29 19:14:13.401
Prefix Len 128, traffic index 0, precedence n/a, priority 4 gateway array (0x78afe150) reference count 1, flags 0x2010, source rib (7), 0 backups
[1 type 3 flags 0x48441 (0x78ba99e8) ext 0x0 (0x0)]
LW-LDI[type=0, refc=0, ptr=0x0, sh-ldi=0x0] gateway array update type-time 1 Jan 29 19:14:13.401
LDI Update time Jan 29 19:14:13.401
Level 1 - Load distribution: 0
[0] via cafe:0:4::/128, recursive via cafe:0:4::/128, 7 dependencies, recursive [flags 0x6000] path-idx 0 NHID 0x0 [0x78cd2a14 0x0] next hop cafe:0:4::/128 via cafe:0:4::/48
SRv6 H.Encaps.Red SID-list {cafe:0:4:e009::}
Load distribution: 0 1 (refcount 1)
Hash OK Interface
0 Y HundredGigE0/0/0/0
1 Y HundredGigE0/0/0/1
Address remote remote
SRv6 Services: IPv4 L3VPN Active-Standby Redundancy using
Port-Active Mode
The Segment Routing IPv6 (SRv6) Services: IPv4 L3VPN Active-Standby Redundancy using Port-Active
Mode feature provides all-active per-port load balancing for multihoming. The forwarding of traffic is determined based on a specific interface rather than per-flow across multiple Provider Edge routers. This
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
67
Configure Segment Routing over IPv6 (SRv6)
SRv6 Services for L3VPN Active-Standby Redundancy using Port-Active Mode: Operation feature enables efficient load-balancing and provides faster convergence. In an active-standby scenario, the active PE router is detected using designated forwarder (DF) election by modulo calculation and the interface of the standby PE router brought down. For Modulo calculation, byte 10 of the Ethernet Segment Identifier
(ESI) is used.
Usage Guidelines and Restrictions
• This feature can only be configured for bundle interfaces.
• When an EVPN Ethernet Segment (ES) is configured with port-active load-balancing mode, you cannot configure ACs of that bundle on bridge-domains with a configured EVPN instance (EVI). EVPN Layer
2 bridging service is not compatible with port-active load-balancing.
SRv6 Services for L3VPN Active-Standby Redundancy using Port-Active Mode:
Operation
Under port-active operational mode, EVPN Ethernet Segment (ES) routes are exchanged across BGP for the routers servicing the multihomed ES. Each PE router then builds an ordered list of the IP addresses of all PEs connected to the ES, including itself, and assigns itself an ordinal for its position in the list. The ordinals are used with the modulo calculation to determine which PE will be the Designated Forwarder (DF) for a given
ES. All non-DF PEs will take the respective bundles out of service.
In the case of link or port failure, the active DF PE withdraws its ES route. This re-triggers DF election for all PEs that service the ES and a new PE is elected as DF.
Configure SRv6 Services L3VPN Active-Standby Redundancy using Port-Active
Mode
This section describes how you can configure SRv6 services L3VPN active-standby redundancy using port-active mode under an Ethernet Segment (ES).
Configuration Example
/* Configure Ethernet Link Bundles */
Router# configure
Router(config)# interface Bundle-Ether10
Router(config-if)# ipv4 address 10.0.0.2 255.255.255.0
Router(config-if)# ipv6 address 2001:DB8::1
Router(config-if)# lacp period short
Router(config-if)# mac-address 1.2.3
Router(config-if)# bundle wait-while 0
Router(config-if)# exit
Router(config)# interface GigabitEthernet 0/2/0/5
Router(config-if)# bundle id 14 mode active
Router(config-if)# commit
/* Configure load balancing. */
Router# configure
Router(config)# evpn
Router(config-evpn)# interface Bundle-Ether10
Router(config-evpn-ac)# ethernet-segment
Router(config-evpn-ac-es)# identifier type 0 11.11.11.11.11.11.11.11.14
68
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing over IPv6 (SRv6)
Running Configuration
Router(config-evpn-ac-es)# load-balancing-mode port-active
Router(config-evpn-ac-es)# commit
!
/* Configure address family session in BGP. */
Router# configure
Router(config)# router bgp 100
Router(config-bgp)# bgp router-id 192.168.0.2
Router(config-bgp)# address-family l2vpn evpn
Router(config-bgp)# neighbor 192.168.0.3
Router(config-bgp-nbr)# remote-as 200
Router(config-bgp-nbr)# update-source Loopback 0
Router(config-bgp-nbr)# address-family l2vpn evpn
Router(config-bgp-nbr)# commit
Running Configuration
interface Bundle-Ether14 ipv4 address 14.0.0.2 255.255.255.0
ipv6 address 14::2/64 lacp period short mac-address 1.2.3
bundle wait-while 0
!
interface GigabitEthernet0/2/0/5 bundle id 14 mode active
!
evpn interface Bundle-Ether14 ethernet-segment identifier type 0 11.11.11.11.11.11.11.11.14
!
load-balancing-mode port-active
!
!
router bgp 100 bgp router-id 192.168.0.2
address-family l2vpn evpn
!
neighbor 192.168.0.3
remote-as 100 update-source Loopback0 address-family l2vpn evpn
!
!
!
Verification
Verify the SRv6 services L3VPN active-standby redundancy using port-active mode configuration.
/* Verify ethernet-segment details on active DF router */
Router# show evpn ethernet-segment interface Bundle-Ether14 detail
Ethernet Segment Id Interface Nexthops
------------------------ ---------------------------------- --------------------
0011.1111.1111.1111.1114 BE14 192.168.0.2
192.168.0.3
ES to BGP Gates : Ready
ES to L2FIB Gates : Ready
Main port :
Interface name : Bundle-Ether14
Interface MAC : 0001.0002.0003
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
69
Configure Segment Routing over IPv6 (SRv6)
Verification
IfHandle
State
Redundancy
ESI type
Value
ES Import RT
Source MAC
Topology
Operational
: 0x000041d0
: Up
: Not Defined
: 0
: 11.1111.1111.1111.1114
: 1111.1111.1111 (from ESI)
: 0000.0000.0000 (N/A)
:
: MH
Configured : Port-Active
Service Carving : Auto-selection
Multicast : Disabled
Peering Details :
192.168.0.2 [MOD:P:00]
192.168.0.3 [MOD:P:00]
Service Carving Results:
Forwarders
Permanent
: 0
: 0
Elected
Not Elected
: 0
: 0
MAC Flushing mode : STP-TCN
Peering timer
Recovery timer
: 3 sec [not running]
: 30 sec [not running]
Carving timer : 0 sec [not running]
Local SHG label : None
Remote SHG labels : 0
/* Verify bundle Ethernet configuration on active DF router */
Router# show bundle bundle-ether 14
Bundle-Ether14
Status: Up
Local links <active/standby/configured>: 1 / 0 / 1
Local bandwidth <effective/available>: 1000000 (1000000) kbps
MAC address (source): 0001.0002.0003 (Configured)
Inter-chassis link:
Minimum active links / bandwidth:
Maximum active links:
Wait while timer:
Load balancing:
No
1 / 1 kbps
64
Off
Link order signaling:
Hash type:
Locality threshold:
LACP:
Flap suppression timer:
Cisco extensions:
Non-revertive: mLACP:
IPv4 BFD:
IPv6 BFD:
Not configured
Default
None
Operational
Off
Disabled
Disabled
Not configured
Not configured
Not configured
Port Device State Port ID B/W, kbps
------------------------------------------------------------------
Gi0/2/0/5 Local Active 0x8000, 0x0003 1000000
Link is Active
/* Verify ethernet-segment details on standby DF router */
Router# show evpn ethernet-segment interface bundle-ether 10 detail
Router# show evpn ethernet-segment interface Bundle-Ether24 detail
Ethernet Segment Id Interface Nexthops
70
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing over IPv6 (SRv6)
Verification
------------------------ ---------------------------------- --------------------
0011.1111.1111.1111.1114 BE24 192.168.0.2
192.168.0.3
ES to BGP Gates : Ready
ES to L2FIB Gates : Ready
Main port :
Interface name : Bundle-Ether24
Interface MAC : 0001.0002.0003
IfHandle : 0x000041b0
State
Redundancy
ESI type
Value
ES Import RT
: Standby
: Not Defined
: 0
: 11.1111.1111.1111.1114
: 1111.1111.1111 (from ESI)
Source MAC
Topology
Operational
: 0000.0000.0000 (N/A)
:
: MH
Configured : Port-Active
Service Carving : Auto-selection
Multicast : Disabled
Peering Details :
192.168.0.2 [MOD:P:00]
192.168.0.3 [MOD:P:00]
Service Carving Results:
Forwarders : 0
Permanent : 0
Elected
Not Elected
: 0
: 0
MAC Flushing mode : STP-TCN
Peering timer : 3 sec [not running]
Recovery timer : 30 sec [not running]
Carving timer : 0 sec [not running]
Local SHG label : None
Remote SHG labels : 0
/* Verify bundle configuration on standby DF router */
Router# show bundle bundle-ether 24
Bundle-Ether24
Status: LACP OOS (out of service)
Local links <active/standby/configured>: 0 / 1 / 1
Local bandwidth <effective/available>: 0 (0) kbps
MAC address (source):
Inter-chassis link:
Minimum active links / bandwidth:
Maximum active links:
Wait while timer:
0001.0002.0003 (Configured)
No
1 / 1 kbps
64
Off
Load balancing:
Link order signaling:
Hash type:
Locality threshold:
LACP:
Flap suppression timer:
Cisco extensions:
Non-revertive: mLACP:
IPv4 BFD:
IPv6 BFD:
Not configured
Default
None
Operational
Off
Disabled
Disabled
Not configured
Not configured
Not configured
Port Device State Port ID B/W, kbps
------------------------------------------------------------------
Gi0/0/0/4 Local Standby 0x8000, 0x0002 1000000
Link is in standby due to bundle out of service state
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
71
Configure Segment Routing over IPv6 (SRv6)
SRv6 Services: IPv4 L3VPN Active-Active Redundancy
SRv6 Services: IPv4 L3VPN Active-Active Redundancy
This feature provides active-active connectivity to a CE device in a L3VPN deployment. The CE device can be Layer-2 or Layer-3 device connecting to the redundant PEs over a single LACP LAG port.
Depending on the bundle hashing, an ARP or IPv6 Network Discovery (ND) packet can be sent to any of the redundant routers. As a result, not all entries will exist on a given PE. In order to provide complete awareness,
Layer-3 local route learning is augmented with remote route-synchronization programming.
Route synchronization between service PEs is required in order to provide minimum interruption to unicast and multicast services after failure on a redundant service PE. The following EVPN route-types are used for
Layer-3 route synchronization:
• EVPN route-type 2 for synchronizing ARP tables
• EVPN route-type 7/8 for synchronizing IGMP JOINS/LEAVES
In a Layer-3 CE scenario, the router that connects to the redundant PEs may establish an IGP adjacency on the bundle port. In this case, the adjacency will be formed to one of the redundant PEs, and IGP customer routes will only be present on that PE. To synchronize Layer-3 customer subnet routes (IP Prefixes), the EVPN route-type 5 is used to carry the ESI and ETAG as well as the gateway address (prefix next-hop address).
Note Gratuitous ARP (GARP) or IPv6 Network Advertisement (NA) replay is not needed for CEs connected to the redundant PEs over a single LAG port.
The below configuration enables Layer-3 route synchronization for routes learned on the Ethernet-segment main-port or any of its sub-interfaces.
evpn route-sync vrf default
!
vrf RED evi route-sync 10
!
vrf BLUE evi route-sync 20
!
SRv6 Services: EVPN VPWS — All-Active Multi-Homing
Table 5: Feature History Table
EVPN VPWS All-Active Multi-Homing over SRv6 provides an ELINE (P2P) service with all-active multihoming capability over an SRv6 network.
All-Active Multi-Homing enables an operator to connect a customer edge (CE) device to two or more provider edge (PE) devices to provide load balancing and redundant connectivity. With All-Active Multi-Homing, all the PEs can forward traffic to and from the multi-homed device.
72
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing over IPv6 (SRv6)
SRv6 Services: EVPN VPWS — All-Active Multi-Homing
Note For information about EVPN VPWS, refer to the "EVPN Virtual Private Wire Service (VPWS)" chapter in the L2VPN and Ethernet Services Configuration Guide for Cisco NCS 560 Series Routers .
Configuring EVPN VPWS over SRv6
Note Complete the steps in
before performing these steps.
An SRv6 Locator for an EVPN VPWS service can be configured at 3 different levels independently:
• global_locator is the default locator for all EVPN-VPWS services
• evi_locator is applied to all EVPN-VPWS services for the specific EVI
• evi_service_locator is applied to an individual EVI service
When locators are configured at different levels at the same time, the following priority is implemented:
1.
evi_service_locator
2.
evi_locator
3.
global_locator
This example shows how to configure an EVPN VPWS over SRv6 using a global locator for EVPN: evpn segment-routing srv6 locator sample_global_loc l2vpn xconnect group sample_xcg p2p sample-vpws-12001-2002 interface Bundle-Ether12001.2002
neighbor evpn evi 12001 service 2002 segment-routing srv6
This example shows how to configure EVPN VPWS over SRv6 using specific EVI locator: evpn evi 11001 segment-routing srv6 locator sample_evi_loc l2vpn xconnect group sample_xcg p2p sample-vpws-11001-2002 interface Bundle-Ether11001.2002
neighbor evpn evi 11001 service 2002 segment-routing srv6
This example shows how to configure an EVPN VPWS over SRv6 using a locator for an individual EVI service: l2vpn xconnect group sample_xcg p2p sample-vpws-11001-2001 interface Bundle-Ether11001.2001
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
73
Configure Segment Routing over IPv6 (SRv6)
SRv6 Services: EVPN VPWS — All-Active Multi-Homing neighbor evpn evi 11001 service 2001 segment-routing srv6 locator sample_evi_service_loc
Verification
Router# show segment-routing srv6 locator
Name ID Algo Prefix Status Flags
----------------------------------------------------------------sample_evi_loc sample_global_loc
1
2
128
0
2001:0:8::/48
2001:0:1::/48
Up
Up
U
U
Router# show segment-routing srv6 sid
*** Locator: 'sample_evi_loc' ***
SID Behavior Context
State RW
----------------------------------------------------------------------
-----------------------
2001:0:8:: uN (PSP/USD)
InUse Y
2001:0:8:e000::
InUse Y uDX2 uA (PSP/USD)
'default':8
11001:2002
[BE11, Link-Local]:128 2001:0:8:e002::
InUse Y
2001:0:8:e004::
InUse Y
2001:0:8:e006::
InUse Y uA (PSP/USD) uA (PSP/USD)
[BE60, Link-Local]:128
[BE30, Link-Local]:128
*** Locator: 'sample_global_loc' ***
2001:0:1::
InUse Y
2001:0:1:e001::
InUse Y
2001:0:1:e003::
InUse Y
2001:0:1:e005::
InUse Y
2001:0:1:e007::
InUse Y uN (PSP/USD) uDX2 uA (PSP/USD) uA (PSP/USD) uA (PSP/USD)
'default':1
12001:2002
[BE11, Link-Local]:0
[BE60, Link-Local]:0
[BE30, Link-Local]:0
Owner sidmgr l2vpn_srv6 isis-20 isis-20 isis-20 sidmgr l2vpn_srv6 isis-20 isis-20 isis-20
Router# show evpn segment-routing srv6 detail
Configured default locator: sample_global_loc
EVIs with unknown locator config: 0
VPWS with unknown locator config: 0
Locator name
-----------sample_evi_loc
Prefix
------
2001:0:8::/48
Configured on EVIs <evi>: 11001 sample_global_loc 2001:0:1::/48
Default locator
OOR
---
False
False
Router# show l2vpn xconnect group sample_xcg detail
Thu Sep 2 14:39:22.575 UTC
Service count
-------------
1
1
SID count
---------
1
1
74
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing over IPv6 (SRv6)
SRv6 Services: EVPN VPWS — All-Active Multi-Homing
Group sample_xcg, XC sample-vpws-11001-2002, state is up; Interworking none
AC: Bundle-Ether11001.2002, state is up
Type VLAN; Num Ranges: 1
Rewrite Tags: []
VLAN ranges: [2002, 2002]
MTU 1504; XC ID 0xc0002ee8; interworking none
Statistics: packets: received 0, sent 0 bytes: received 0, sent 0 drops: illegal VLAN 0, illegal length 0
EVPN: neighbor ::ffff:10.0.0.1, PW ID: evi 11001, ac-id 2002, state is up ( established
)
XC ID 0xa0001f47
Encapsulation SRv6
Encap type Ethernet
Ignore MTU mismatch: Enabled
Transmit MTU zero: Disabled
Reachability: Up
SRv6 Local Remote
------------------------------------------- -------------------------uDX2 2001:0:8:e000:: 2001:0:3:e000::
AC ID
MTU
2002
1518
Locator sample_evi_loc
Locator Resolved Yes
SRv6 Headend H.Encaps.L2.Red
Statistics: packets: received 0, sent 0 bytes: received 0, sent 0
2002
1518
N/A
N/A
N/A
Group sample_xcg, XC sample-vpws-12001-2002, state is up; Interworking none
AC: Bundle-Ether12001.2002, state is up
Type VLAN; Num Ranges: 1
Rewrite Tags: []
VLAN ranges: [2002, 2002]
MTU 1504; XC ID 0xc0002eea; interworking none
Statistics: packets: received 0, sent 0 bytes: received 0, sent 0 drops: illegal VLAN 0, illegal length 0
EVPN: neighbor ::ffff:10.0.0.2, PW ID: evi 12001, ac-id 2002, state is up ( established
)
XC ID 0xa0001f49
Encapsulation SRv6
Encap type Ethernet
Ignore MTU mismatch: Enabled
Transmit MTU zero: Disabled
Reachability: Up
SRv6 Local Remote
------------------------------------------- -------------------------uDX2 2001:0:1:e001:: 2001:0:2:e001::
AC ID
MTU
2002
1518
2002
1518
Locator
Locator Resolved sample_global_loc
Yes
SRv6 Headend H.Encaps.L2.Red
Statistics: packets: received 0, sent 0 bytes: received 0, sent 0
N/A
N/A
N/A
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
75
Configure Segment Routing over IPv6 (SRv6)
SRv6/MPLS L3 Service Interworking Gateway
SRv6/MPLS L3 Service Interworking Gateway
Table 6: Feature History Table
Feature Name
SRv6/MPLS L3 Service
Interworking Gateway (SRv6
Micro-SID)
Release
Release 7.3.2
Description
This feature enables you to extend
L3 services between MPLS and
SRv6 domains by providing service continuity on the control plane and data plane.
This feature allows for SRv6
L3VPN domains to interwork with existing MPLS L3VPN domains.
The feature also allows a way to migrate from MPLS L3VPN to
SRv6 L3VPN.
SRv6/MPLS L3 Service Interworking Gateway enables you to extend L3 services between MPLS and SRv6 domains by providing service continuity on the control plane and data plane.
This feature allows for SRv6 L3VPN domains to interwork with existing MPLS L3VPN domains. The feature also allows a way to migrate from MPLS L3VPN to SRv6 L3VPN.
The SRv6/MPLS L3 Service Interworking Gateway provides both transport and service termination at the gateway node. The gateway generates both SRv6 VPN SIDs and MPLS VPN labels for all prefixes under the
VRF configured for re-origination. The gateway supports traffic forwarding from MPLS domain to SRv6 domain by popping the MPLS VPN label, looking up the destination prefix, and pushing the appropriate SRv6 encapsulation. From SRv6 domain to MPLS domain, the gateway removes the outer IPv6 header, looks up the destination prefix, and pushes the VPN and next-hop MPLS labels.
VRFs on the gateway node are configured with 2 sets of route targets (RTs):
• MPLS L3VPN RTs
• SRv6 L3VPN RTs (called stitching RTs )
The gateway performs the following actions:
• Imports service routes received from one domain (MPLS or SRv6)
• Re-advertises exported service routes to the other domain (next-hop-self)
• Stitches the service on the data plane (uDT4/H.Encaps.Red ↔ service label)
SRv6/MPLS L3 Service Interworking Gateway Scenarios
The following scenario is used to describe the gateway functionality:
• Node 1 is an L3VPN PE in the MPLS domain with an SR prefix SID label of 16001 for its Loopback interface 1.1.1.1/32.
76
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing over IPv6 (SRv6)
SRv6/MPLS L3 Service Interworking Gateway
• Node 2 is the SRv6/MPLS L3 Service Interworking Gateway. In the MPLS domain, it has an SR prefix
SID label of 16002 for its Loopback interface 1.1.1.2/32. In the SRv6 domain, it has an SRv6 locator of
B:0:2::/48 and Loopback interface B:0:2::2/128.
• Node 3 is an L3VPN PE in the SRv6 domain with SRv6 locator of B:0:3::/48 and Loopback interface
B:0:3::3/128.
Scenario 1: SRv6-to-MPLS Control-Plane Direction/MPLS-to-SRv6 Data-Plane Direction
The figure below describes the associated control-plane behaviors in the SRv6-to-MPLS direction for traffic in the MPLS-to-SRv6 data-plane direction.
A . Node 3 advertises a BGP L3VPN update for prefix B.0.0.0/8 with RD corresponding to VRFA, including the SRv6 VPN SID (B:0:3:V9::) assigned to this VRF, in the SRv6 domain.
Note SRv6 uDT4 function value "V9" is not a valid hex number, however it is used for illustration purposes to remind you of its connection to a VRF.
B . Node 2 (gateway) imports the BGP L3VPN update and programs its FIB:
• MPLS label 24010 is allocated for VRFA
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
77
Configure Segment Routing over IPv6 (SRv6)
SRv6/MPLS L3 Service Interworking Gateway
• Prefix B.0.0.0/8 is programmed with an "SR Headend Behavior with Reduced Encapsulation in an SR
Policy" function (H.Encaps.Red) of B:0:3:V9::
Note The gateway follows per-VRF label and per-VRF SID allocation methods.
C . Node 2 re-originates a BGP L3VPN update for the same prefix, including the MPLS VPN label (24010) allocated for the VRF, in the MPLS domain.
D . Site A sends traffic to an IPv4 prefix (B.B.B.B) of Site B
E . Node 1 encapsulates incoming traffic with the MPLS VPN label (24010) and the prefix SID MPLS label
(16002) of the BGP next-hop (Node 2).
F . Node 2 performs the following actions:
• Pops the MPLS VPN label and looks up the destination prefix
• Encapsulates the payload in an outer IPv6 header with destination address (DA) equal to the H.Encaps.Red
function (B:0:3:V9::)
G . Node 3 removes the outer IPv6 header, looks up the payload destination address (B.B.B.B), and forwards to Site B.
Scenario 2: MPLS-to-SRv6 Control-Plane Direction/SRv6-to-MPLS Data-Plane Direction
The figure below describes the associated control-plane behaviors in the MPLS-to-SRv6 direction for traffic in the SRv6-to-MPLS data-plane direction.
A . Node 1 advertises a BGP L3VPN update for prefix A.0.0.0/8 with RD corresponding to VRFA, including the MPLS VPN label (24055) assigned to this VRF, in the MPLS domain.
B . Node 2 (gateway) imports the BGP L3VPN update and programs its FIB:
78
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing over IPv6 (SRv6)
SRv6/MPLS L3 Service Interworking Gateway
• Prefix A.0.0.0/8 is programmed to impose an MPLS VPN label (24055) and the prefix SID MPLS label
(16001) of the BGP next-hop (Node 1)
• "Endpoint with decapsulation and IPv4 table lookup" function (uDT4) of B:0:2:V8:: is allocated to VRFA
Note SRv6 uDT4 function value "V8" is not a valid hex number, however it is used for illustration purposes to remind you of its connection to a VRF.
Note The gateway follows per-VRF label and per-VRF SID allocation methods.
C . Node 2 re-originates a BGP L3VPN update for the same prefix, including the uDT4 function (B:0:2:V8::) allocated for the VRF, in the SRv6 domain.
D . Site B sends traffic to an IPv4 prefix (A.A.A.A) of Site A.
E . Node 3 Encapsulates the payload in an outer IPv6 header with destination address (DA) equal to the uDT4 function (B:0:2:V8::).
F . Node 2 performs the following actions:
• Removes the outer IPv6 header and looks up the destination prefix
• Pushes the MPLS VPN label (24055) and the prefix SID MPLS label (16001) of the BGP next-hop (Node
1)
G . Node 1 pops the MPLS VPN label, looks up the payload destination address (A.A.A.A), and forwards to
Site A.
Example
Leveraging the topology described in the above use-case, this example shows the SRv6/MPLS L3 Service
Interworking Gateway configuration required at Node 2.
The following configuration shows how to enable SRv6 with locator and configure encapsulation parameters: segment-routing srv6 encapsulation
!
source-address B:0:2::2 locators locator LOC1 prefix B:0:2::/48
!
!
!
!
The following configuration shows how to configure a VPNv4 VRF with the following route targets (RTs):
• 1111:1, RT used for MPLS L3VPN
• 2222:1, RT used for SRv6 L3VPN (stitching RT)
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
79
Configure Segment Routing over IPv6 (SRv6)
SRv6/MPLS Dual-Connected PE vrf ACME address-family ipv4 unicast import route-target
1111:1
!
2222:1 stitching export route-target
!
!
!
1111:1
22222:1 stitching
The following configuration shows how to configure SRv6/SRv6 VPNs under BGP: router bgp 100 segment-routing srv6
!
locator LOC1 neighbor 1.1.1.1
address-family vpnv4 unicast import re-originate stitching-rt route-reflector-client advertise vpnv4 unicast re-originated
!
neighbor B:0:3::1 address-family vpnv4 unicast import stitching-rt re-originate route-reflector-client encapsulation-type srv6 advertise vpnv4 unicast re-originated stitching-rt
!
vrf ACME address-family ipv4 unicast enable label-mode segment-routing srv6
SRv6/MPLS Dual-Connected PE
Table 7: Feature History Table
Feature Name
SRv6/MPLS Dual-Connected PE
(SRv6 Micro SID)
Release
Release 7.3.2
Description
This feature allows a PE router to support IPv4 L3VPN services for a given VRF with both MPLS and
SRv6. This is MPLS and SRv6
L3VPNv4 co-existence scenario and is sometimes referred to as dual-connected PE.
A PE router can support IPv4 L3VPN service for a given VRF with both MPLS and SRv6. This is MPLS and
SRv6 L3VPNv4 co-existence scenario and is sometimes referred to as dual-connected PE.
In the figure below, node 2 is a dual-connected PE to Site C, providing:
• MPLS/IPv4 L3VPN between Site A and Site C
• SRv6/IPv4 L3VPN between Site B and Site C
80
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing over IPv6 (SRv6)
SRv6/MPLS Dual-Connected PE
Configure BGP to Support Dual-Mode
Enable MPLS Label Allocation
Use the router bgp as-number vrf WORD address-family ipv4 unicast mpls alloc enable command under the VRF address-family to enable per-prefix mode for MPLS labels. Additionally, use the router bgp as-number
vrf WORD address-family ipv4 unicast label mode { per-ce | per-vrf } command to choose the type of label allocation.
Router(config)# router bgp 100
Router(config-bgp)# vrf blue
Router(config-bgp-vrf)# rd 1:10
Router(config-bgp-vrf)# address-family ipv4 unicast
Router(config-bgp-vrf-af)# mpls alloc enable
Router(config-bgp-vrf-af)# label mode per-ce
Router(config-bgp-vrf-af)# segment-routing srv6
Router(config-bgp-vrf-af-srv6)# alloc mode per-ce
Router(config-bgp-vrf-af-srv6)# exit
Router(config-bgp-vrf-af)# exit
Router(config-bgp-vrf)# exit
Router(config-bgp)#
Configure Encaps on Neighbor to Send the SRv6 SID Toward the SRv6 Dataplane
By default, if a VRF prefix has both an MPLS label and an SRv6 SID, the MPLS label is sent when advertising the prefix to the PE. To advertise a VRF prefix with an SRv6 SID to an SRv6 session, use the encapsulation-type srv6 command under the neighbor VPN address-family.
Router(config-bgp)# neighbor 192::6
Router(config-bgp-nbr)# remote-as 1
Router(config-bgp-nbr)# address-family ipv4 unicast
Router(config-bgp-nbr-af)# encapsulation-type srv6
Router(config-bgp-nbr-af)# exit
Running Config router bgp 100 neighbor 192::6 remote-as 1 address-family ipv4 unicast encapsulation-type srv6
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
81
Configure Segment Routing over IPv6 (SRv6)
SRv6 SID Information in BGP-LS Reporting
!
!
vrf blue rd 1:10 address-family ipv4 unicast mpls alloc enable label mode per-ce segment-routing srv6
!
!
!
!
alloc mode per-ce
SRv6 SID Information in BGP-LS Reporting
BGP Link-State (BGP-LS) is used to report the topology of the domain using nodes, links, and prefixes. This feature adds the capability to report SRv6 Segment Identifier (SID) Network Layer Reachability Information
(NLRI).
The following NLRI has been added to the BGP-LS protocol to support SRv6:
• Node NLRI: SRv6 Capabilities, SRv6 MSD types
• Link NLRI: End.X, LAN End.X, and SRv6 MSD types
• Prefix NLRI: SRv6 Locator
• SRv6 SID NLRI (for SIDs associated with the node): Endpoint Function, BGP-EPE Peer Node/Set
This example shows how to distribute IS-IS SRv6 link-state data using BGP-LS:
Router(config)# router isis 200
Router(config-isis)# distribute link-state instance-id 200
SRv6 OAM — SID Verification
This feature provides enhanced Operations, Administration, and Maintenance (OAM) in Segment Routing
Networks with IPv6 Data plane (SRv6).
Existing OAM mechanisms to ping and trace a remote IPv6 prefix, along the shortest path, continue to work without any modification in an SRv6 network.
Use the following commands to performs SRv6 ping and traceroute:
ping B : k : F ::
traceroute B : k : F ::
Where B : k : F :: is the target SID at node k with locator block B and function F .
Ping/Traceroute to SID Without OAM SID
The user can issue ping or traceroute to an SRv6 SID using the classic CLI. In this case, and as usual, the packet is pre-routed as an ICMP echo request or UDP packet.
82
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing over IPv6 (SRv6)
DHCPv4 Relay Agent and Proxy Support over SRv6
Configuration Examples
The following example shows using ping to a SID without OAM SID.
Router# ping ipv6 cafe:0:4::4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to cafe:0:4::4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 7/9/17 ms
The following example shows using traceroute to a SID without OAM SID.
Router# traceroute ipv6 cafe:0:4::4
Type escape sequence to abort.
Tracing the route to cafe:0:4::4
1 3001::10:1:3:3 15 msec
3001::10:1:2:2 11 msec 5 msec
2 cafe:0:4::4 27 msec 14 msec 18 msec
DHCPv4 Relay Agent and Proxy Support over SRv6
This feature introduces support for DHCPv4 Relay Agent and Proxy over SRv6.
An IOS XR router can act as a DHCPv4 relay agent/proxy with a DHCPv4 server connected over an SRv6 network.
The following functionality is supported:
• DHCPv4 relay agent/proxy over SRv6 with DHCPv4 server (helper-address) located in default VRF
(global)
• DHCPv4 relay agent/proxy over SRv6 with DHCPv4 server (helper-address) located in non-default VRF
• DHCPv4 relay agent/proxy on interfaces associated with a default VRF (global)
• DHCPv4 relay agent/proxy on interfaces associated with a non-default VRF
• DHCPv4 relay agent/proxy on Ethernet physical interfaces
• DHCPv4 relay agent/proxy on Ethernet bundle interfaces
For information on configuring DHCPv4 relay agent and proxy, refer to the “Implementing the Dynamic Host
Configuration Protocol” chapter in the IP Addresses and Services Configuration Guide for Cisco NCS 5500
Series Routers.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
83
Configure Segment Routing over IPv6 (SRv6)
DHCPv6 Relay Agent Support over SRv6
DHCPv6 Relay Agent Support over SRv6
Table 8: Feature History Table
Feature Name
DHCPv6 Relay Agent Support on
SRv6
Release Information
Release 7.2.2
Feature Description
An IOS XR router can act as a
DHCPv6 relay agent with a
DHCPv6 server connected over an
SRv6 network.
A DHCP relay agent is a host that forwards DHCP packets between clients and servers that do not reside on a shared physical subnet.
This feature introduces support for DHCPv6 Relay Agent over SRv6.
An IOS XR router can act as a DHCPv6 relay agent with a DHCPv6 server connected over an SRv6 network.
The following functionality is supported:
• DHCPv6 relay agent over SRv6 with DHCPv6 server (helper-address) located in default VRF (global)
• DHCPv6 relay agent over SRv6 with DHCPv6 server (helper-address) located in non-default VRF
• DHCPv6 relay agent on interfaces associated with a default VRF (global)
• DHCPv6 relay agent on interfaces associated with a non-default VRF
• DHCPv6 relay agent on Ethernet physical interfaces
• DHCPv6 relay agent on Ethernet bundle interfaces
For information on configuring DHCPv6 relay agent, refer to the “Implementing the Dynamic Host
Configuration Protocol” chapter in the IP Addresses and Services Configuration Guide for Cisco NCS 5500
Series Routers .
84
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
C H A P T E R
3
Configure Segment Routing Global Block and
Segment Routing Local Block
Local label allocation is managed by the label switching database (LSD). The Segment Routing Global Block
(SRGB) and Segment Routing Local Block (SRLB) are label values preserved for segment routing in the
LSD.
•
About the Segment Routing Global Block, on page 85
•
About the Segment Routing Local Block, on page 87
•
Understanding Segment Routing Label Allocation, on page 88
•
Setup a Non-Default Segment Routing Global Block Range, on page 91
•
Setup a Non-Default Segment Routing Local Block Range, on page 92
About the Segment Routing Global Block
The Segment Routing Global Block (SRGB) is a range of labels reserved for Segment Routing global segments.
A prefix-SID is advertised as a domain-wide unique index. The prefix-SID index points to a unique label within the SRGB range. The index is zero-based, meaning that the first index is 0. The MPLS label assigned to a prefix is derived from the Prefix-SID index plus the SRGB base. For example, considering an SRGB range of 16,000 to 23,999, a prefix 1.1.1.65/32 with prefix-SID index of 65 is assigned the label value of
16065 .
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
85
About the Segment Routing Global Block
Configure Segment Routing Global Block and Segment Routing Local Block
To keep the configuration simple and straightforward, we strongly recommended that you use a homogenous
SRGB (meaning, the same SRGB range across all nodes). Using a heterogenous SRGB (meaning, a different
SRGB range of the same size across nodes) is also supported but is not recommended.
Behaviors and Limitations
• The default SRGB in IOS XR has a size of 8000 starting from label value 16000. The default range is
16000 to 23,999. With this size, and assuming one loopback prefix per router, an operator can assign prefix SIDs to a network with 8000 routers.
• There are instances when you might need to define a different SRGB range. For example:
• Non-IOS XR nodes with a SRGB range that is different than the default IOS XR SRGB range.
• The default SRGB range is not large enough to accommodate all required prefix SIDs.
• A non-default SRGB can be configured following these guidelines:
• The SRGB starting value can be configured anywhere in the dynamic label range space (16,000 to
1,048,575).
• In Cisco IOS XR release earlier than 6.6.3, the SRGB can have a maximum configurable size of
262,143.
• In Cisco IOS XR release 6.6.3 and later, the SRGB can be configured to any size value that fits within the dynamic label range space.
• Allocating an SRGB label range does not mean that all the labels in this range are programmed in the forwarding table. The label range is just reserved for SR and not available for other purposes. Furthermore, a platform may limit the number of local labels that can be programmed.
• We recommend that the non-default SRGB be configured under the segment-routing global configuration mode. By default, all IGP instances and BGP use this SRGB.
86
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing Global Block and Segment Routing Local Block
About the Segment Routing Local Block
• You can also configure a non-default SRGB under the IGP, but it is not recommended.
SRGB Label Conflicts
When you define a non-default SRGB range, there might be a label conflict (for example, if labels are already allocated, statically or dynamically, in the new SRGB range). The following system log message indicates a label conflict:
%ROUTING-ISIS-4-SRGB_ALLOC_FAIL : SRGB allocation failed: 'SRGB reservation not successful for [16000,80000], SRGB (16000 80000, SRGB_ALLOC_CONFIG_PENDING, 0x2)
(So far 16 attempts). Make sure label range is free'
To remove this conflict, you must reload the router to release the currently allocated labels and to allocate the new SRGB.
After the system reloads, LSD does not accept any dynamic label allocation before IS-IS/OSPF/BGP have registered with LSD. Upon IS-IS/OSPF/BGP registration, LSD allocates the requested SRGB (either the default range or the customized range).
After IS-IS/OSPF/BGP have registered and their SRGB is allocated, LSD starts serving dynamic label requests from other clients.
Note To avoid a potential router reload due to label conflicts, and assuming that the default SRGB size is large enough, we recommend that you use the default IOS XR SRGB range.
Note Allocating a non-default SRGB in the upper part of the MPLS label space increases the chance that the labels are available and a reload can be avoided.
Caution Modifying a SRGB configuration is disruptive for traffic and may require a reboot if the new SRGB is not available entirely.
About the Segment Routing Local Block
A local segment is automatically assigned an MPLS label from the dynamic label range. In most cases, such as TI-LFA backup paths and SR-TE explicit paths defined with IP addresses, this dynamic label allocation is sufficient. However, in some scenarios, it could be beneficial to allocate manually local segment label values to maintain label persistency. For example, an SR-TE policy with a manual binding SID that is performing traffic steering based on incoming label traffic with the binding SID.
The Segment Routing Local Block (SRLB) is a range of label values preserved for the manual allocation of local segments, such as adjacency segment identifiers (adj-SIDs) , Layer 2 adj-SIDs, binding SIDs (BSIDs), and BGP peering SIDs. These labels are locally significant and are only valid on the nodes that allocate the labels.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
87
Configure Segment Routing Global Block and Segment Routing Local Block
Understanding Segment Routing Label Allocation
Behaviors and Limitations
• The default SRLB has a size of 1000 starting from label value 15000; therefore, the default SRLB range goes from 15000 to 15,999.
• A non-default SRLB can be configured following these guidelines:
• The SRLB starting value can be configured anywhere in the dynamic label range space (16,000 to
1,048,575).
• In Cisco IOS XR release earlier than 6.6.3, the SRLB can have a maximum configurable size of
262,143.
• In Cisco IOS XR release 6.6.3 and later, the SRLB can be configured to any size value that fits within the dynamic label range space.
SRLB Label Conflicts
When you define a non-default SRLB range, there might be a label conflict (for example, if labels are already allocated, statically or dynamically, in the new SRLB range). In this case, the new SRLB range will be accepted, but not applied (pending state). The previous SRLB range (active) will continue to be in use.
To remove this conflict, you must reload the router to release the currently allocated labels and to allocate the new SRLB.
Caution You can use the clear segment-routing local-block discrepancy all command to clear label conflicts.
However, using this command is disruptive for traffic since it forces all other MPLS applications with conflicting labels to allocate new labels.
Note To avoid a potential router reload due to label conflicts, and assuming that the default SRGB size is large enough, we recommend that you use the default IOS XR SRLB range.
Note Allocating a non-default SRLB in the upper part of the MPLS label space increases the chance that the labels are available and a reload can be avoided.
Understanding Segment Routing Label Allocation
In IOS XR, local label allocation is managed by the Label Switching Database (LSD). MPLS applications must register as a client with the LSD to allocate labels. Most MPLS applications (for example: LDP, RSVP,
L2VPN, BGP [LU, VPN], IS-IS and OSPF [Adj-SID], SR-TE [Binding-SID]) use labels allocated dynamically by LSD.
With Segment Routing-capable IOS XR software releases, the LSD preserves the default SRLB label range
(15,000 to 15,999) and default SRGB label range (16,000 to 23,999), even if Segment Routing is not enabled.
88
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing Global Block and Segment Routing Local Block
Understanding Segment Routing Label Allocation
This preservation of the default SRLB/SRGB label range makes future Segment Routing activation possible without a reboot. No labels are allocated from this preserved range. When you enable Segment Routing with the default SRLB/SRGB in the future, these label ranges will be available and ready for use.
The LSD allocates dynamic labels starting from 24,000.
Note If an MPLS label range is configured and it overlaps with the default SRLB/SRGB label ranges (for example, mpls label range 15000 1048575 ), then the default SRLB/SRGB preservation is disabled.
Example 1: LSD Label Allocation When SR is not Configured
• Special use: 0-15
• MPLS static: 16 to 14,999
• SRLB (preserved): 15,000 to 15,999
• SRGB (preserved): 16,000 to 23,999
• Dynamic: 24,000 to max
Example 2: LSD Label Allocation When SR is Configured with Default SRGB and Default SRLB
• Special use: 0-15
• MPLS static: 16 to 14,999
• SRLB (reserved): 15,000 to 15,999
• SRGB (reserved): 16,000 to 23,999
• Dynamic: 24,000 to max
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
89
Understanding Segment Routing Label Allocation
Configure Segment Routing Global Block and Segment Routing Local Block
Example 3: LSD Label Allocation When SR is Configured with Non-default SRGB and Non-default SRLB
• Special use: 0-15
• MPLS static: 16 to 14,999
• SRLB (preserved): 15,000 to 15,999
• SRGB (preserved): 16,000 to 23,999
• Dynamic: 24000 to 28,999
• SRLB (reserved): 29,000 to 29,999
• SRGB (reserved): 30,000 to 39,999
• Dynamic: 40,000 to max
90
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing Global Block and Segment Routing Local Block
Setup a Non-Default Segment Routing Global Block Range
Setup a Non-Default Segment Routing Global Block Range
This task explains how to configure a non-default SRGB range.
Procedure
Step 1
Step 2
Command or Action configure
Example:
Purpose
Enters mode.
RP/0/RP0/CPU0:router# configure
segment-routing global-block starting_value ending_value
Example:
Enter the lowest value that you want the SRGB range to include as the starting value. Enter the highest value that you want the SRGB range to include as the ending value.
RP/0/RP0/CPU0:router(config)# segment-routing global-block 16000 80000
Step 3 Use the commit or end command.
commit —Saves the configuration changes and remains within the configuration session.
end —Prompts user to take one of these actions:
• Yes — Saves configuration changes and exits the configuration session.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
91
Configure Segment Routing Global Block and Segment Routing Local Block
Setup a Non-Default Segment Routing Local Block Range
Command or Action Purpose
• No —Exits the configuration session without committing the configuration changes.
• Cancel —Remains in the configuration session, without committing the configuration changes.
Use the show mpls label table [ label label-value ] command to verify the SRGB configuration:
Router# show mpls label table label 16000 detail
Table Label Owner State Rewrite
----- ------- ------------------------------- ------ -------
0 16000 ISIS(A):1 InUse No
(Lbl-blk SRGB, vers:0, (start_label=16000, size=64001)
What to do next
Configure prefix SIDs and enable segment routing.
Setup a Non-Default Segment Routing Local Block Range
This task explains how to configure a non-default SRLB range.
Procedure
Step 1
Step 2
Command or Action configure
Example:
Purpose
Enters mode.
RP/0/RP0/CPU0:router# configure
segment-routing local-block starting_value ending_value
Example:
Enter the lowest value that you want the SRLB range to include as the starting value. Enter the highest value that you want the SRLB range to include as the ending value.
RP/0/RP0/CPU0:router(config)# segment-routing local-block 30000 30999
Step 3 Use the commit or end command.
commit —Saves the configuration changes and remains within the configuration session.
end —Prompts user to take one of these actions:
• Yes — Saves configuration changes and exits the configuration session.
92
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing Global Block and Segment Routing Local Block
Setup a Non-Default Segment Routing Local Block Range
Command or Action Purpose
• No —Exits the configuration session without committing the configuration changes.
• Cancel —Remains in the configuration session, without committing the configuration changes.
Use the show mpls label table [ label label-value ] [ detail ] command to verify the SRLB configuration:
Router# show mpls label table label 30000 detail
Table Label Owner State Rewrite
----- ------- ------------------------------- ------ -------
0 30000 LSD(A) InUse No
( Lbl-blk SRLB , vers:0, (start_label= 30000 , size= 1000 , app_notify=0)
Router# show segment-routing local-block inconsistencies
No inconsistencies
The following example shows an SRLB label conflict in the range of 30000 and 30999. Note that the default
SRLB is active and the configured SRLB is pending:
Router(config)# segment-routing local-block 30000 30999
%ROUTING-MPLS_LSD-3-ERR_SRLB_RANGE : SRLB allocation failed: 'SRLB reservation not successfull for [30000,30999]. Use with caution 'clear segment-routing local-block discrepancy all' command to force srlb allocation'
Caution You can use the clear segment-routing local-block discrepancy all command to clear label conflicts.
However, using this command is disruptive for traffic since it forces all other MPLS applications with conflicting labels to allocate new labels.
Router# show mpls label table label 30000 detail
Table Label Owner State Rewrite
----- ------- ------------------------------- ------ -------
0 30000 LSD(A) InUse No
(Lbl-blk SRLB, vers:0, (start_label=30000, size=1000, app_notify=0)
Router# show segment-routing local-block inconsistencies
SRLB inconsistencies range: Start/End: 30000/30999
Router# show mpls lsd private | i SRLB
SRLB Lbl Mgr:
Current Active SRLB block = [15000, 15999]
Configured Pending SRLB block = [30000, 30999]
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
93
Configure Segment Routing Global Block and Segment Routing Local Block
Setup a Non-Default Segment Routing Local Block Range
Reload the router to release the currently allocated labels and to allocate the new SRLB:
Router# reload
Proceed with reload? [confirm] yes
After the system is brought back up, verify that there are no label conflicts with the SRLB configuration:
Router# show mpls lsd private | i SRLB
SRLB Lbl Mgr:
Current Active SRLB block = [30000, 30999]
Configured Pending SRLB block = [0, 0]
Router# show segment-routing local-block inconsistencies
No inconsistencies
What to do next
Configure adjacency SIDs and enable segment routing.
94
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
C H A P T E R
4
Configure Segment Routing for IS-IS Protocol
Integrated Intermediate System-to-Intermediate System (IS-IS), Internet Protocol Version 4 (IPv4), is a standards-based Interior Gateway Protocol (IGP). The Cisco IOS XR software implements the IP routing capabilities described in International Organization for Standardization (ISO)/International Engineering
Consortium (IEC) 10589 and RFC 1995, and adds the standard extensions for single topology and multitopology
IS-IS for IP Version 6 (IPv6).
This module provides the configuration information used to enable segment routing for IS-IS.
•
Enabling Segment Routing for IS-IS Protocol, on page 95
•
Configuring a Prefix-SID on the IS-IS Enabled Loopback Interface, on page 97
•
Configuring an Adjacency SID, on page 100
•
Configuring Bandwidth-Based Local UCMP, on page 105
•
Conditional Prefix Advertisement, on page 107
•
Segment Routing ECMP-FEC Optimization, on page 108
Enabling Segment Routing for IS-IS Protocol
Segment routing on the IS-IS control plane supports the following:
• IPv4 and IPv6 control plane
• Level 1, level 2, and multi-level routing
• Prefix SIDs for host prefixes on loopback interfaces
• Adjacency SIDs for adjacencies
• MPLS penultimate hop popping (PHP) and explicit-null signaling
This task explains how to enable segment routing for IS-IS.
Before you begin
Your network must support the MPLS Cisco IOS XR software feature before you enable segment routing for
IS-IS on your router.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
95
Configure Segment Routing for IS-IS Protocol
Enabling Segment Routing for IS-IS Protocol
Note You must enter the commands in the following task list on every IS-IS router in the traffic-engineered portion of your network.
Procedure
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Command or Action configure
Example:
Purpose
Enters mode.
RP/0/RP0/CPU0:router# configure
router isis instance-id
Example:
Enables IS-IS routing for the specified routing instance, and places the router in router configuration mode.
RP/0/RP0/CPU0:router(config)# router isis
Note isp
You can change the level of routing to be performed by a particular routing instance by using the is-type router configuration command.
address-family { ipv4 | ipv6 } [ unicast ]
Example:
Specifies the IPv4 or IPv6 address family, and enters router address family configuration mode.
RP/0/RP0/CPU0:router(config-isis)# address-family ipv4 unicast metric-style wide [ level { 1 | 2 }]
Example:
Configures a router to generate and accept only wide link metrics in the Level 1 area.
RP/0/RP0/CPU0:router(config-isis-af)# metric-style wide level 1
router-id loopback loopback interface used for prefix-sid
Configures router ID for each address-family
(IPv4/IPv6).
Example:
RP/0/RP0/CPU0:router(config-isis-af)#router-id loopback0
IS-IS advertises the router ID in TLVs 134 (for
IPv4 address family) and 140 (for IPv6 address family). Required when traffic engineering is used.
segment-routing mpls
Example:
RP/0/RP0/CPU0:router(config-isis-af)# segment-routing mpls
Segment routing is enabled by the following actions:
• MPLS forwarding is enabled on all interfaces where IS-IS is active.
• All known prefix-SIDs in the forwarding plain are programmed, with the prefix-SIDs advertised by remote routers
96
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing for IS-IS Protocol
Configuring a Prefix-SID on the IS-IS Enabled Loopback Interface
Step 7
Step 8
Command or Action Purpose or learned through local or remote mapping server.
• The prefix-SIDs locally configured are advertised.
exit
Example:
RP/0/RP0/CPU0:router(config-isis-af)# exit
RP/0/RP0/CPU0:router(config-isis)# exit
Use the commit or end command.
commit —Saves the configuration changes and remains within the configuration session.
end —Prompts user to take one of these actions:
• Yes — Saves configuration changes and exits the configuration session.
• No —Exits the configuration session without committing the configuration changes.
• Cancel —Remains in the configuration session, without committing the configuration changes.
What to do next
Configure the prefix SID.
Configuring a Prefix-SID on the IS-IS Enabled Loopback
Interface
A prefix segment identifier (SID) is associated with an IP prefix. The prefix SID is manually configured from the segment routing global block (SRGB) range of labels. A prefix SID is configured under the loopback interface with the loopback address of the node as the prefix. The prefix segment steers the traffic along the shortest path to its destination.
A prefix SID can be a node SID or an Anycast SID. A node SID is a type of prefix SID that identifies a specific node. An Anycast SID is a type of prefix SID that identifies a set of nodes, and is configured with n-flag clear.
The set of nodes (Anycast group) is configured to advertise a shared prefix address and prefix SID. Anycast routing enables the steering of traffic toward multiple advertising nodes. Packets addressed to an Anycast address are forwarded to the topologically nearest nodes.
The prefix SID is globally unique within the segment routing domain.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
97
Configure Segment Routing for IS-IS Protocol
Configuring a Prefix-SID on the IS-IS Enabled Loopback Interface
This task explains how to configure prefix segment identifier (SID) index or absolute value on the IS-IS enabled Loopback interface.
Before you begin
Ensure that segment routing is enabled on the corresponding address family.
Procedure
Step 1
Step 2
Step 3
Step 4
Command or Action configure
Example:
Purpose
Enters mode.
RP/0/RP0/CPU0:router# configure
router isis instance-id
Example:
RP/0/RP0/CPU0:router(config)# router isis
1
Enables IS-IS routing for the specified routing instance, and places the router in router configuration mode.
• You can change the level of routing to be performed by a particular routing instance by using the is-type router configuration command.
interface Loopback instance
Example:
Specifies the loopback interface and instance.
RP/0/RP0/CPU0:router(config-isis)# interface Loopback0 address-family { ipv4 | ipv6 } [ unicast ]
Example:
The following is an example for ipv4 address family:
Specifies the IPv4 or IPv6 address family, and enters router address family configuration mode.
Step 5
RP/0/RP0/CPU0:router(config-isis-if)# address-family ipv4 unicast prefix-sid [ algorithm algorithm-number ]
{ index SID-index | absolute SID-value }
[ n-flag-clear ] [ explicit-null ]
Configures the prefix-SID index or absolute value for the interface.
Example:
RP/0/RP0/CPU0:router(config-isis-if-af)# prefix-sid index 1001
Specify algorithm algorithm-number to configure SR Flexible Algorithm. See
Segment Routing Flexible Algorithm, on page
Specify index SID-index for each node to create a prefix SID based on the lower boundary of the SRGB + the index.
RP/0/RP0/CPU0:router(config-isis-if-af)# prefix-sid absolute 17001
Specify absolute SID-value for each node to create a specific prefix SID within the SRGB.
98
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing for IS-IS Protocol
Configuring a Prefix-SID on the IS-IS Enabled Loopback Interface
Step 6
Command or Action
Use the commit or end command.
Purpose
By default, the n-flag is set on the prefix-SID, indicating that it is a node SID. For specific prefix-SID (for example, Anycast prefix-SID), enter the n-flag-clear keyword. IS-IS does not set the
N flag in the prefix-SID sub Type
Length Value (TLV).
To disable penultimate-hop-popping (PHP) and add explicit-Null label, enter explicit-null keyword. IS-IS sets the
E flag in the prefix-SID sub TLV.
commit —Saves the configuration changes and remains within the configuration session.
end —Prompts user to take one of these actions:
• Yes — Saves configuration changes and exits the configuration session.
• No —Exits the configuration session without committing the configuration changes.
• Cancel —Remains in the configuration session, without committing the configuration changes.
Verify the prefix-SID configuration:
RP/0/RP0/CPU0:router# show isis database verbose
IS-IS 1 (Level-2) Link State Database
LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL router.00-00 * 0x0000039b
Area Address: 49.0001
0xfc27 1079 0/0/0
NLPID:
NLPID:
MT:
MT:
Hostname:
0xcc
0x8e
Standard (IPv4 Unicast)
IPv6 Unicast router
0/0/0
IP Address: 10.0.0.1
IPv6 Address: 2001:0db8:1234::0a00:0001
Router Cap: 10.0.0.1, D:0, S:0
Segment Routing: I:1 V:1, SRGB Base: 16000 Range: 8000
SR Algorithm:
Algorithm: 0
<...>
Metric: 0 IP-Extended 10.0.0.1/32
Prefix-SID Index: 1001, Algorithm:0 , R:0 N:1 P:0 E:0 V:0 L:0
<...>
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
99
Configure Segment Routing for IS-IS Protocol
Configuring an Adjacency SID
What to do next
Configure the SR-TE policy.
Configuring an Adjacency SID
An adjacency SID (Adj-SID) is associated with an adjacency to a neighboring node. The adjacency SID steers the traffic to a specific adjacency. Adjacency SIDs have local significance and are only valid on the node that allocates them.
An adjacency SID can be allocated dynamically from the dynamic label range or configured manually from the segment routing local block (SRLB) range of labels.
Adjacency SIDs that are dynamically allocated do not require any special configuration, however there are some limitations:
• A dynamically allocated Adj-SID value is not known until it has been allocated, and a controller will not know the Adj-SID value until the information is flooded by the IGP.
• Dynamically allocated Adj-SIDs are not persistent and can be reallocated after a reload or a process restart.
• Each link is allocated a unique Adj-SID, so the same Adj-SID cannot be shared by multiple links.
Manually allocated Adj-SIDs are persistent over reloads and restarts. They can be provisioned for multiple adjacencies to the same neighbor or to different neighbors. You can specify that the Adj-SID is protected. If the Adj-SID is protected on the primary interface and a backup path is available, a backup path is installed.
By default, manual Adj-SIDs are not protected.
Adjacency SIDs are advertised using the existing IS-IS Adj-SID sub-TLV. The S and P flags are defined for manually allocated Adj-SIDs.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|F|B|V|L| S | P | |
+-+-+-+-+-+-+-+-+
Table 9: Adjacency Segment Identifier (Adj-SID) Flags Sub-TLV Fields
Field
S (Set)
Description
This flag is set if the same Adj-SID value has been provisioned on multiple interfaces.
This flag is set if the Adj-SID is persistent (manually allocated).
P (Persistent)
Manually allocated Adj-SIDs are supported on point-to-point (P2P) interfaces.
This task explains how to configure an Adj-SID on an interface.
Before you begin
Ensure that segment routing is enabled on the corresponding address family.
Use the show mpls label table detail command to verify the SRLB range.
100
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing for IS-IS Protocol
Configuring an Adjacency SID
Procedure
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Command or Action configure
Example:
Purpose
Enters mode.
RP/0/RP0/CPU0:router# configure
router isis instance-id
Example:
RP/0/RP0/CPU0:router(config)# router isis
1
Enables IS-IS routing for the specified routing instance, and places the router in router configuration mode.
• You can change the level of routing to be performed by a particular routing instance by using the is-type router configuration command.
interface type interface-path-id
Example:
RP/0/RP0/CPU0:router(config-isis)# interface GigabitEthernet0/0/0/7 point-to-point
Example:
Specifies the interface and enters interface configuration mode.
Specifies the interface is a point-to-point interface.
RP/0/RP0/CPU0:router(config-isis-if)# point-to-point address-family { ipv4 | ipv6 } [ unicast ]
Example:
The following is an example for ipv4 address family:
Specifies the IPv4 or IPv6 address family, and enters router address family configuration mode.
RP/0/RP0/CPU0:router(config-isis-if)# address-family ipv4 unicast adjacency-sid { index adj-SID-index | absolute adj-SID-value } [ protected ]
Configures the Adj-SID index or absolute value for the interface.
Example: Specify index adj-SID-index for each link to create an Ajd-SID based on the lower boundary of the SRLB + the index.
RP/0/RP0/CPU0:router(config-isis-if-af)# adjacency-sid index 10
Specify absolute adj-SID-value for each link to create a specific Ajd-SID within the SRLB.
RP/0/RP0/CPU0:router(config-isis-if-af)# adjacency-sid absolute 15010
Specify if the Adj-SID is protected . For each primary path, if the Adj-SID is protected on the primary interface and a backup path is available, a backup path is installed. By default, manual
Adj-SIDs are not protected.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
101
Configure Segment Routing for IS-IS Protocol
Manually Configure a Layer 2 Adjacency SID
Step 7
Command or Action
Use the commit or end command.
Purpose commit —Saves the configuration changes and remains within the configuration session.
end —Prompts user to take one of these actions:
• Yes — Saves configuration changes and exits the configuration session.
• No —Exits the configuration session without committing the configuration changes.
• Cancel —Remains in the configuration session, without committing the configuration changes.
Verify the Adj-SID configuration:
RP/0/RP0/CPU0:router# show isis segment-routing label adjacency persistent
Mon Jun 12 02:44:07.085 PDT
IS-IS 1 Manual Adjacency SID Table
15010 AF IPv4
GigabitEthernet0/0/0/3: IPv4, Protected 1/65/N, Active
GigabitEthernet0/0/0/7: IPv4, Protected 2/66/N, Active
15100 AF IPv6
GigabitEthernet0/0/0/3: IPv6, Not protected 255/255/N, Active
Verify the labels are added to the MPLS Forwarding Information Base (LFIB):
RP/0/RP0/CPU0:router# show mpls forwarding labels 15010
Mon Jun 12 02:50:12.172 PDT
Local Outgoing
Label Label
Prefix or ID
Outgoing
Interface
Next Hop Bytes
Switched
------ ----------- ------------------ ------------ --------------- ------------
15010 Pop SRLB (idx 10) Gi0/0/0/3 10.0.3.3
0
Pop SRLB (idx 10) Gi0/0/0/7 10.1.0.5
0
16004
16004
SRLB (idx 10)
SRLB (idx 10)
Gi0/0/0/7
Gi0/0/0/3
10.1.0.5
10.0.3.3
0
0
(!)
(!)
What to do next
Configure the SR-TE policy.
Manually Configure a Layer 2 Adjacency SID
Typically, an adjacency SID (Adj-SID) is associated with a Layer 3 adjacency to a neighboring node, to steer the traffic to a specific adjacency. If you have Layer 3 bundle interfaces, where multiple physical interfaces
102
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing for IS-IS Protocol
Manually Configure a Layer 2 Adjacency SID form a bundle interface, the individual Layer 2 bundle members are not visible to IGP; only the bundle interface is visible.
You can configure a Layer 2 Adj-SID for the individual Layer 2 bundle interfaces. This configuration allows you to track the availability of individual bundle member links and to verify the segment routing forwarding over the individual bundle member links, for Operational Administration and Maintenance (OAM) purposes.
A Layer 2 Adj-SID can be allocated dynamically or configured manually.
• IGP dynamically allocates Layer 2 Adj-SIDs from the dynamic label range for each Layer 2 bundle member. A dynamic Layer 2 Adj-SID is not persistent and can be reallocated as the Layer 3 bundle link goes up and down.
• Manually configured Layer 2 Adj-SIDs are persistent if the Layer 3 bundle link goes up and down. Layer
2 Adj-SIDs are allocated from the Segment Routing Local Block (SRLB) range of labels. However, if the configured value of Layer 2 Adj-SID does not fall within the available SRLB, a Layer 2 Adj-SID will not be programmed into forwarding information base (FIB).
Restrictions
• Adj-SID forwarding requires a next-hop, which can be either an IPv4 address or an IPv6 address, but not both. Therefore, manually configured Layer 2 Adj-SIDs are configured per address-family.
• Manually configured Layer 2 Adj-SID can be associated with only one Layer 2 bundle member link.
• A SID value used for Layer 2 Adj-SID cannot be shared with Layer 3 Adj-SID.
• SR-TE using Layer 2 Adj-SID is not supported.
This task explains how to configure a Layer 2 Adj-SID on an interface.
Before you begin
Ensure that segment routing is enabled on the corresponding address family.
Use the show mpls label table detail command to verify the SRLB range.
Procedure
Step 1
Step 2
Command or Action configure
Example:
RP/0/RP0/CPU0:router# configure segment-routing
Example:
RP/0/RP0/CPU0:Router(config)# segment-routing
Purpose
Enters mode.
Enters segment routing configuration mode.
Step 3 adjacency-sid
Example:
Enters adjacency SID configuration mode.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
103
Configure Segment Routing for IS-IS Protocol
Manually Configure a Layer 2 Adjacency SID
Step 4
Step 5
Step 6
Step 7
Step 8
Command or Action
RP/0/RP0/CPU0:Router(config-sr)# adjacency-sid
interface type interface-path-id
Example:
RP/0/RP0/CPU0:Router(config-sr-adj)# interface GigabitEthernet0/0/0/3
Purpose
Specifies the interface and enters interface configuration mode.
address-family { ipv4 | ipv6 } [ unicast ]
Example:
Specifies the IPv4 or IPv6 address family, and enters router address family configuration mode.
RP/0/RP0/CPU0:Router(config-sr-adj-intf)# address-family ipv4 unicast l2-adjacency sid { index adj-SID-index |
absolute adj-SID-value } [ next-hop
{ ipv4_address | ipv6_address } ]
Configures the Adj-SID index or absolute value for the interface.
Example:
Specify index adj-SID-index for each link to create an Ajd-SID based on the lower boundary of the SRLB + the index.
RP/0/RP0/CPU0:Router(config-sr-adj-intf-af)# l2-adjacency sid absolute 15015 next-hop 10.1.1.4
Specify absolute adj-SID-value for each link to create a specific Ajd-SID within the SRLB.
For point-to-point interfaces, you are not required to specify a next-hop. However, if you do specify the next-hop, the Layer 2
Adj-SID will be used only if the specified next-hop matches the neighbor address.
For LAN interfaces, you must configure the next-hop IPv4 or IPv6 address. If you do not configure the next-hop, the Layer 2 Adj-SID will not be used for LAN interface.
Use the commit or end command.
commit —Saves the configuration changes and remains within the configuration session.
end —Prompts user to take one of these actions:
• Yes — Saves configuration changes and exits the configuration session.
• No —Exits the configuration session without committing the configuration changes.
• Cancel —Remains in the configuration session, without committing the configuration changes.
end
104
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing for IS-IS Protocol
Configuring Bandwidth-Based Local UCMP
Step 9
Command or Action
router isis instance-id
Example:
RP/0/RP0/CPU0:Router(config)# router isis isp
Purpose
Enables IS-IS routing for the specified routing instance, and places the router in router configuration mode.
Step 10 address-family { ipv4 | ipv6 } [ unicast ]
Example:
Specifies the IPv4 or IPv6 address family, and enters router address family configuration mode.
RP/0/RP0/CPU0:Router(config-isis)# address-family ipv4 unicast
Step 11 segment-routing bundle-member-adj-sid
Example:
RP/0/RP0/CPU0:Router(config-isis-af)# segment-routing bundle-member-adj-sid
Programs the dynamic Layer 2 Adj-SIDs, and advertises both manual and dynamic Layer 2
Adj-SIDs.
Note This command is not required to program manual L2 Adj-SID, but is required to program the dynamic
Layer 2 Adj-SIDs and to advertise both manual and dynamic Layer 2
Adj-SIDs.
Verify the configuration:
Router# show mpls forwarding detail | i "Pop|Outgoing Interface|Physical Interface"
Tue Jun 20 06:53:51.876 PDT
. . .
15001 Pop SRLB (idx 1) BE1 10.1.1.4
0
Outgoing Interface: Bundle-Ether1 (ifhandle 0x000000b0)
Physical Interface: GigabitEthernet0/0/0/3 (ifhandle 0x000000b0)
Router# show running-config segment-routing
Tue Jun 20 07:14:25.815 PDT segment-routing adjacency-sid
!
!
!
interface GigabitEthernet0/0/0/3 address-family ipv4 unicast
!
l2-adjacency-sid absolute 15015
Configuring Bandwidth-Based Local UCMP
Bandwidth-based local Unequal Cost Multipath (UCMP) allows you to enable UCMP functionality locally between Equal Cost Multipath (ECMP) paths based on the bandwidth of the local links.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
105
Configure Segment Routing for IS-IS Protocol
Configuring Bandwidth-Based Local UCMP
Bandwidth-based local UCMP is performed for prefixes, segment routing Adjacency SIDs, and Segment
Routing label cross-connects installed by IS-IS, and is supported on any physical or virtual interface that has a valid bandwidth.
For example, if the capacity of a bundle interface changes due to the link or line card up/down event, traffic continues to use the affected bundle interface regardless of the available provisioned bundle members. If some bundle members were not available due to the failure, this behavior could cause the traffic to overload the bundle interface. To address the bundle capacity changes, bandwidth-based local UCMP uses the bandwidth of the local links to load balance traffic when bundle capacity changes.
Before you begin
Procedure
Step 1
Step 2
Step 3
Command or Action configure
Example:
Purpose
Enters mode.
RP/0/RP0/CPU0:router# configure
router isis instance-id
Example:
Enables IS-IS routing for the specified routing instance, and places the router in router configuration mode.
RP/0/RP0/CPU0:router(config)# router isis
1
You can change the level of routing to be performed by a particular routing instance by using the is-type router configuration command.
address-family { ipv4 | ipv6 } [ unicast ]
Example:
The following is an example for ipv4 address family:
Specifies the IPv4 or IPv6 address family, and enters IS-IS address family configuration mode.
Step 4
Step 5
RP/0/RP0/CPU0:router(config-isis)# address-family ipv4 unicast apply-weight ecmp-only bandwidth
Example:
Enables UCMP functionality locally between
ECMP paths based on the bandwidth of the local links.
RP/0/RP0/CPU0:router(config-isis-af)# apply-weight ecmp-only bandwidth
Use the commit or end command.
commit —Saves the configuration changes and remains within the configuration session.
end —Prompts user to take one of these actions:
• Yes — Saves configuration changes and exits the configuration session.
106
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing for IS-IS Protocol
Conditional Prefix Advertisement
Command or Action Purpose
• No —Exits the configuration session without committing the configuration changes.
• Cancel —Remains in the configuration session, without committing the configuration changes.
Conditional Prefix Advertisement
In some situations, it’s beneficial to make the IS-IS prefix advertisement conditional. For example, an Area
Border Router (ABR) or Autonomous System Boundary Router (ASBR) that has lost its connection to one of the areas or autonomous systems (AS) might keep advertising a prefix. If an ABR or ASBR advertises the
Segment Routing (SR) SID with this prefix, the label stack of the traffic routed toward the disconnected area or AS might use this SID, which would result in dropped traffic at the ABR or ASBR.
ABRs or ASBRs are often deployed in pairs for redundancy and advertise a shared Anycast prefix SID.
Conditional Prefix Advertisement allows an ABR or an ASBR to advertise its Anycast SID only when connected to a specific area or domain. If an ABR or ASBR becomes disconnected from the particular area or AS, it stops advertising the address for a specified interface (for example, Loopback).
Configure the conditional prefix advertisement under a specific interface. The prefix advertisement on this interface is associated with the route-policy that tracks the presence of a set of prefixes (prefix-set) in the
Routing Information Base (RIB).
For faster convergence, the route-policy used for conditional prefix advertisement uses the new event-based rib-has-route async condition to notify IS-IS of the following situations:
• When the last prefix from the prefix-set is removed from the RIB.
• When the first prefix from the prefix-set is added to the RIB.
Configuration
To use the conditional prefix advertisement in IS-IS, create a prefix-set to be tracked. Then create a route policy that uses the prefix-set.
Router(config)# prefix-set prefix-set-name
Router(config-pfx)# prefix-address-1 /length [ , prefix-address-2/length ,,, prefix-address-16 /length ]
Router(config-pfx)# end-set
Router(config)# route-policy rpl-name
Router(config-rpl)# if rib-has-route async prefix-set-name then
Router(config-rpl-if)# pass
Router(config-rpl-if)# endif
Router(config-rpl)# end-policy
To advertise the loopback address in IS-IS conditionally, use the advertise prefix route-policy command under IS-IS interface address-family configuration sub-mode.
Router(config)# router isis 1
Router(config-isis)# interface Loopback0
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
107
Configure Segment Routing for IS-IS Protocol
Segment Routing ECMP-FEC Optimization
Router(config-isis-if)# address-family ipv4 unicast
Router(config-isis-if-af)# advertise prefix route-policy rpl-name
Router(config-isis-if-af)# commit
Example
Router(config)# prefix-set domain_2
Router(config-pfx)# 2.3.3.3/32, 2.4.4.4/32
Router(config-pfx)# end-set
Router(config)# route-policy track_domain_2
Router(config-rpl)# if rib-has-route async domain_2 then
Router(config-rpl-if)# pass
Router(config-rpl-if)# endif
Router(config-rpl)# end-policy
Router(config)# router isis 1
Router(config-isis)# interface Loopback0
Router(config-isis-if)# address-family ipv4 unicast
Router(config-isis-if-af)# advertise prefix route-policy track_domain-2
Router(config-isis-if-af)# commit
Running Configuration prefix-set domain_2
2.3.3.3/32,
2.4.4.4/32 end-set
!
route-policy track_domain_2 if rib-has-route async domain_2 then pass endif end-policy
!
router isis 1 interface Loopback0 address-family ipv4 unicast
!
!
advertise prefix route-policy track_domain_2
!
Segment Routing ECMP-FEC Optimization
Table 10: Feature History Table
Feature Name Release Information
SR ECMP-FEC Optimization L2 and L3 Recursive Services
Release 7.4.1
Feature Description
This feature adds support for
L2VPN service Label Edge Router
(LER) and BGP PIC for Layer 3
BGP services when SR ECMP-FEC
Optimization is enabled.
108
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing for IS-IS Protocol
Segment Routing ECMP-FEC Optimization
ECMP-FECs are used for any ECMP programming on the system, such as MPLS LSP ECMP, VPN multipath, and EVPN multi-homing .
The SR ECMP-FEC optimization solution minimizes ECMP-FEC resource consumption during underlay programming for an SR-MPLS network. This feature supports sharing the same ECMP-FEC, regular FEC, and Egress Encapsulation DB (EEDB) entries for all /32 IPv4 Segment Routing prefixes with the same set of next hops. ECMP-FEC optimization is triggered when all the out_labels associated with the ECMP paths for a given prefix have the same value. If this rule is not met, then the prefix is programmed with a dedicated
ECMP-FEC. Other prefixes that meet the rule are candidates for optimization.
Segment Routing Label Edge Router (LER) ECMP-FEC Optimization enables ECMP-FEC optimization originally developed for Label Switched Router (LSR) nodes (MPLS P) to be enabled on LER (Layer 3 MPLS
PE) routers.
Usage Guidelines and Limitations
• SR ECMP-FEC Optimization is not supported on NCS-55A1-36H-SE-S router or NC55-36X100G-A-SE line card.
• For prefixes with LFA backup paths, the SR ECMP-FEC Optimization is possible since these backup paths do not require an extra label to be pushed; all paths associated with the prefix (primary and backup) have the same outgoing label value.
• For prefixes with TI-LFA backup paths requiring extra labels to be pushed on to the backup, the SR
ECMP-FEC Optimization is not possible since all the paths associated with the prefix do not have the same outgoing label value.
• For the duration of time that prefixes are programmed to avoid microloops (when SR MicroLoop
Avoidance is triggered), SR ECMP-FEC Optimization is not possible since all the paths associated with the prefix do not have the same outgoing label value. After removal of the microloop-avoidance programming, the SR ECMP-FEC Optimization might be possible again.
• For scenarios with prefixes where the SR ECMP-FEC Optimization is not possible, dedicated ECMP-FEC is allocated per prefix. This could potentially lead to ECMP FEC out-of-resource (OOR) considering the baseline usage of ECMP FEC resources at steady state. During ECMP-FEC OOR, prefixes with multiple paths are programmed with a single path in order to avoid traffic disruption.
• SR ECMP-FEC optimization is applicable in the following instances:
• Label Switched Router (LSR) nodes (MPLS P)
• L3VPN Label Edge Router (LER) nodes
• L2VPN LER nodes
• ASBR node with BGP-LU swap
• BGP PIC is supported
• SR ECMP-FEC optimization should not be enabled in the following instances:
• L2VPN/L3VPN LER nodes with VPN over BGP-LU over SR
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
109
Configure Segment Routing for IS-IS Protocol
Segment Routing ECMP-FEC Optimization
Enable SR ECMP-FEC Optimization
To enable SR ECMP-FEC optimization, use the hw-module fib mpls label lsr-optimized command in global configuration mode. After enabling this feature, reload the line card.
Router(config)# hw-module fib mpls label lsr-optimized
Router(config)# commit
LC/0/0/CPU0:Oct 11 20:19:12.540 UTC: fia_driver[185]:
%FABRIC-FIA_DRVR-4-MPLS_HW_PROFILE_MISMATCH :
Mismatch found, reload LC to activate the new mpls profile
Router# reload location 0/0/CPU0
Proceed with reload? [ confirm ]
Reloading node 0/0/CPU0
Verification
The following example shows NPU usage before enabling SR ECMP-FEC optimization.
Router# show controllers npu resources ecmpfec location all
HW Resource Information For Location: 0/0/CPU0
HW Resource Information
Name : ecmp_fec
OOR Information
NPU-0
Estimated Max Entries
Red Threshold
Yellow Threshold
OOR State
: 4096
: 95
: 80
: Green
Current Usage
NPU-0
Total In-Use ipnhgroup ip6nhgroup
: 1001
: 1001
: 0
(24 %)
(24 %)
(0 %)
The following example shows NPU usage after enabling SR ECMP-FEC optimization.
Router# show controllers npu resources ecmpfec location all
HW Resource Information For Location: 0/0/CPU0
HW Resource Information
Name : ecmp_fec
OOR Information
NPU-0
Estimated Max Entries
Red Threshold
Yellow Threshold
OOR State
Current Usage
NPU-0
Total In-Use ipnhgroup ip6nhgroup
: 4096
: 95
: 80
: Green
: 7
: 7
: 0
(0 %)
(0 %)
(0 %)
110
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
C H A P T E R
5
Configure Segment Routing for OSPF Protocol
Open Shortest Path First (OSPF) is an Interior Gateway Protocol (IGP) developed by the OSPF working group of the Internet Engineering Task Force (IETF). Designed expressly for IP networks, OSPF supports IP subnetting and tagging of externally derived routing information. OSPF also allows packet authentication and uses IP multicast when sending and receiving packets.
This module provides the configuration information to enable segment routing for OSPF.
Note For additional information on implementing OSPF on your , see the Implementing OSPF module in the .
•
Enabling Segment Routing for OSPF Protocol, on page 111
•
Configuring a Prefix-SID on the OSPF-Enabled Loopback Interface, on page 113
•
Segment Routing ECMP-FEC Optimization, on page 115
Enabling Segment Routing for OSPF Protocol
Segment routing on the OSPF control plane supports the following:
• OSPFv2 control plane
• Multi-area
• IPv4 prefix SIDs for host prefixes on loopback interfaces
• Adjacency SIDs for adjacencies
• MPLS penultimate hop popping (PHP) and explicit-null signaling
This section describes how to enable segment routing MPLS and MPLS forwarding in OSPF. Segment routing can be configured at the instance, area, or interface level.
Before you begin
Your network must support the MPLS Cisco IOS XR software feature before you enable segment routing for
OSPF on your router.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
111
Configure Segment Routing for OSPF Protocol
Enabling Segment Routing for OSPF Protocol
Note You must enter the commands in the following task list on every OSPF router in the traffic-engineered portion of your network.
Procedure
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Command or Action configure
Example:
Purpose
Enters mode.
RP/0/RP0/CPU0:router# configure
router ospf process-name
Example:
Enables OSPF routing for the specified routing process and places the router in router configuration mode.
RP/0/RP0/CPU0:router(config)# router ospf
1 segment-routing mpls
Example:
RP/0/RP0/CPU0:router(config-ospf)# segment-routing mpls segment-routing mpls
Example:
RP/0/RP0/CPU0:router(config-ospf-ar)# segment-routing mpls
Enables segment routing using the MPLS data plane on the routing process and all areas and interfaces in the routing process.
Enables segment routing fowarding on all interfaces in the routing process and installs the
SIDs received by OSPF in the forwarding table.
area area
Example:
RP/0/RP0/CPU0:router(config-ospf)# area
0
Enters area configuration mode.
(Optional) Enables segment routing using the
MPLS data plane on the area and all interfaces in the area. Enables segment routing fowarding on all interfaces in the area and installs the SIDs received by OSPF in the forwarding table.
exit
Example:
RP/0/RP0/CPU0:router(config-ospf-ar)# exit
RP/0/RP0/CPU0:router(config-ospf)# exit
Use the commit or end command.
commit —Saves the configuration changes and remains within the configuration session.
end —Prompts user to take one of these actions:
112
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing for OSPF Protocol
Configuring a Prefix-SID on the OSPF-Enabled Loopback Interface
Command or Action Purpose
• Yes — Saves configuration changes and exits the configuration session.
• No —Exits the configuration session without committing the configuration changes.
• Cancel —Remains in the configuration session, without committing the configuration changes.
What to do next
Configure the prefix SID.
Configuring a Prefix-SID on the OSPF-Enabled Loopback
Interface
A prefix segment identifier (SID) is associated with an IP prefix. The prefix SID is manually configured from the segment routing global block (SRGB) range of labels. A prefix SID is configured under the loopback interface with the loopback address of the node as the prefix. The prefix segment steers the traffic along the shortest path to its destination.
A prefix SID can be a node SID or an Anycast SID. A node SID is a type of prefix SID that identifies a specific node. An Anycast SID is a type of prefix SID that identifies a set of nodes, and is configured with n-flag clear.
The set of nodes (Anycast group) is configured to advertise a shared prefix address and prefix SID. Anycast routing enables the steering of traffic toward multiple advertising nodes. Packets addressed to an Anycast address are forwarded to the topologically nearest nodes.
The prefix SID is globally unique within the segment routing domain.
This task describes how to configure prefix segment identifier (SID) index or absolute value on the
OSPF-enabled Loopback interface.
Before you begin
Ensure that segment routing is enabled on an instance, area, or interface.
Procedure
Step 1
Command or Action configure
Example:
RP/0/RP0/CPU0:router# configure
Purpose
Enters mode.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
113
Configure Segment Routing for OSPF Protocol
Configuring a Prefix-SID on the OSPF-Enabled Loopback Interface
Step 2
Step 3
Step 4
Step 5
Step 6
Command or Action
router ospf process-name
Example:
Purpose
Enables OSPF routing for the specified routing process, and places the router in router configuration mode.
RP/0/RP0/CPU0:router(config)# router ospf
1
area value
Example:
Enters area configuration mode.
RP/0/RP0/CPU0:router(config-ospf)# area
0
interface Loopback interface-instance
Example:
RP/0/RP0/CPU0:router(config-ospf-ar)# interface loopback 0 prefix-sid { index SID-index | absolute
SID-value } [ n-flag-clear ] [ explicit-null ]
Example:
RP/0/RP0/CPU0:router(config-ospf-ar)# prefix-sid index 1001
RP/0/RP0/CPU0:router(config-ospf-ar)# prefix-sid absolute 17001
Use the commit or end command.
Specifies the loopback interface and instance.
Configures the prefix-SID index or absolute value for the interface.
Specify index SID-index for each node to create a prefix SID based on the lower boundary of the SRGB + the index.
Specify absolute SID-value for each node to create a specific prefix SID within the SRGB.
By default, the n-flag is set on the prefix-SID, indicating that it is a node SID. For specific prefix-SID (for example, Anycast prefix-SID), enter the n-flag-clear keyword. OSPF does not set the
N flag in the prefix-SID sub Type
Length Value (TLV).
To disable penultimate-hop-popping (PHP) and add an explicit-Null label, enter the explicit-null keyword. OSPF sets the
E flag in the prefix-SID sub TLV.
commit —Saves the configuration changes and remains within the configuration session.
end —Prompts user to take one of these actions:
• Yes — Saves configuration changes and exits the configuration session.
• No —Exits the configuration session without committing the configuration changes.
114
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing for OSPF Protocol
Segment Routing ECMP-FEC Optimization
Command or Action Purpose
• Cancel —Remains in the configuration session, without committing the configuration changes.
Verify the prefix-SID configuration:
RP/0/RP0/CPU0:router# show ospf database opaque-area 7.0.0.1 self-originate
OSPF Router with ID (10.0.0.1) (Process ID 1)
Type-10 Opaque Link Area Link States (Area 0)
<...>
Extended Prefix TLV: Length: 20
Route-type: 1
AF
Flags
Prefix
: 0
: 0x40
: 10.0.0.1/32
SID sub-TLV: Length: 8
Flags
MTID
Algo
: 0x0
: 0
: 0
SID Index : 1001
Segment Routing ECMP-FEC Optimization
ECMP-FECs are used for any ECMP programming on the system, such as MPLS LSP ECMP, VPN multipath, and EVPN multi-homing .
The SR ECMP-FEC optimization solution minimizes ECMP-FEC resource consumption during underlay programming for an SR-MPLS network. This feature supports sharing the same ECMP-FEC, regular FEC, and Egress Encapsulation DB (EEDB) entries for all /32 IPv4 Segment Routing prefixes with the same set of next hops. ECMP-FEC optimization is triggered when all the out_labels associated with the ECMP paths for a given prefix have the same value. If this rule is not met, then the prefix is programmed with a dedicated
ECMP-FEC. Other prefixes that meet the rule are candidates for optimization.
Segment Routing Label Edge Router (LER) ECMP-FEC Optimization enables ECMP-FEC optimization originally developed for Label Switched Router (LSR) nodes (MPLS P) to be enabled on LER (Layer 3 MPLS
PE) routers.
For usage guidelines, limitations, and configuration options, see
Segment Routing ECMP-FEC Optimization, on page 108
.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
115
Segment Routing ECMP-FEC Optimization
Configure Segment Routing for OSPF Protocol
116
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
C H A P T E R
6
Configure Segment Routing for BGP
Border Gateway Protocol (BGP) is an Exterior Gateway Protocol (EGP) that allows you to create loop-free inter-domain routing between autonomous systems. An autonomous system is a set of routers under a single technical administration. Routers in an autonomous system can use multiple Interior Gateway Protocols (IGPs) to exchange routing information inside the autonomous system and an EGP to route packets outside the autonomous system.
This module provides the configuration information used to enable Segment Routing for BGP.
Note For additional information on implementing BGP on your router , see the Implementing BGP module in the
Routing Configuration Guide for Cisco NCS 560 Series Routers .
•
Segment Routing for BGP, on page 117
•
Configure BGP Prefix Segment Identifiers, on page 118
•
Segment Routing Egress Peer Engineering, on page 119
•
Configure BGP Link-State, on page 123
•
Use Case: Configuring SR-EPE and BGP-LS, on page 128
•
Configure BGP Proxy Prefix SID, on page 130
Segment Routing for BGP
In a traditional BGP-based data center (DC) fabric, packets are forwarded hop-by-hop to each node in the autonomous system. Traffic is directed only along the external BGP (eBGP) multipath ECMP. No traffic engineering is possible.
In an MPLS-based DC fabric, the eBGP sessions between the nodes exchange BGP labeled unicast (BGP-LU) network layer reachability information (NLRI). An MPLS-based DC fabric allows any leaf (top-of-rack or border router) in the fabric to communicate with any other leaf using a single label, which results in higher packet forwarding performance and lower encapsulation overhead than traditional BGP-based DC fabric.
However, since each label value might be different for each hop, an MPLS-based DC fabric is more difficult to troubleshoot and more complex to configure.
BGP has been extended to carry segment routing prefix-SID index. BGP-LU helps each node learn BGP prefix SIDs of other leaf nodes and can use ECMP between source and destination. Segment routing for BGP simplifies the configuration, operation, and troubleshooting of the fabric. With segment routing for BGP, you can enable traffic steering capabilities in the data center using a BGP prefix SID.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
117
Configure Segment Routing for BGP
Configure BGP Prefix Segment Identifiers
Configure BGP Prefix Segment Identifiers
Segments associated with a BGP prefix are known as BGP prefix SIDs. The BGP prefix SID is global within a segment routing or BGP domain. It identifies an instruction to forward the packet over the ECMP-aware best-path computed by BGP to the related prefix. The BGP prefix SID is manually configured from the segment routing global block (SRGB) range of labels.
Each BGP speaker must be configured with an SRGB using the segment-routing global-block command.
See the
About the Segment Routing Global Block
section for information about the SRGB.
Note Because the values assigned from the range have domain-wide significance, we recommend that all routers within the domain be configured with the same range of values.
To assign a BGP prefix SID, first create a routing policy using the set label-index index attribute, then associate the index to the node.
Example
The following example shows how to configure the SRGB, create a BGP route policy using a $SID parameter and set label-index attribute, and then associate the prefix-SID index to the node.
RP/0/RP0/CPU0:router(config)# segment-routing global-block 16000 23999
RP/0/RP0/CPU0:router(config)# route-policy SID($SID)
RP/0/RP0/CPU0:router(config-rpl)# set label-index $SID
RP/0/RP0/CPU0:router(config-rpl)# end policy
RP/0/RP0/CPU0:router(config)# router bgp 1
RP/0/RP0/CPU0:router(config-bgp)# bgp router-id 1.1.1.1
RP/0/RP0/CPU0:router(config-bgp)# address-family ipv4 unicast
RP/0/RP0/CPU0:router(config-bgp-af)# network 1.1.1.3/32 route-policy SID(3)
RP/0/RP0/CPU0:router(config-bgp-af)# allocate-label all
RP/0/RP0/CPU0:router(config-bgp-af)# commit
RP/0/RP0/CPU0:router(config-bgp-af)# end
RP/0/RP0/CPU0:router# show bgp 1.1.1.3/32
BGP routing table entry for 1.1.1.3/32
Versions:
Process bRIB/RIB SendTblVer
Speaker
Local Label: 16003
74 74
Last Modified: Sep 29 19:52:18.155 for 00:07:22
Paths: (1 available, best #1)
Advertised to update-groups (with more than one peer):
0.2
Path #1: Received by speaker 0
Advertised to update-groups (with more than one peer):
0.2
3
99.3.21.3 from 99.3.21.3 (1.1.1.3)
Received Label 3
Origin IGP, metric 0, localpref 100, valid, external, best, group-best
Received Path ID 0, Local Path ID 1, version 74
Origin-AS validity: not-found
118
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing for BGP
Segment Routing Egress Peer Engineering
Label Index: 3
Segment Routing Egress Peer Engineering
Segment routing egress peer engineering (EPE) uses a controller to instruct an ingress provider edge, or a content source (node) within the segment routing domain, to use a specific egress provider edge (node) and a specific external interface to reach a destination. BGP peer SIDs are used to express source-routed inter-domain paths.
Below are the BGP-EPE peering SID types:
• PeerNode SID—To an eBGP peer. Pops the label and forwards the traffic on any interface to the peer.
• PeerAdjacency SID—To an eBGP peer via interface. Pops the label and forwards the traffic on the related interface.
• PeerSet SID—To a set of eBGP peers. Pops the label and forwards the traffic on any interface to the set of peers. All the peers in a set might not be in the same AS.
Multiple PeerSet SIDs can be associated with any combination of PeerNode SIDs or PeerAdjacency
SIDs.
The controller learns the BGP peer SIDs and the external topology of the egress border router through BGP-LS
EPE routes. The controller can program an ingress node to steer traffic to a destination through the egress node and peer node using BGP labeled unicast (BGP-LU).
EPE functionality is only required at the EPE egress border router and the EPE controller.
Usage Guidelines and Limitations
When enabling BGP EPE, you must enable MPLS encapsulation on the egress interface connecting to the eBGP peer. This can be done by enabling either MPLS static or BGP labeled unicast (BGP-LU) address family for the eBGP peer.
For information about MPLS static, refer to the “Implementing MPLS Static Labeling” chapter in the MPLS
Configuration Guide for Cisco ASR 9000 NCS 5500 NCS 5000 NCS 560 NCS 540 Series Routers .
For information about BGP-LU, refer to the “Implementing BGP” chapter in the Routing Configuration Guide for Cisco ASR 9000 NCS 6000 Series RoutersBGP Configuration Guide for Cisco NCS 5500 NCS 5000 NCS
560 NCS 540 Series Routers .
Configure Segment Routing Egress Peer Engineering
This task explains how to configure segment routing EPE on the EPE egress node.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
119
Configure Segment Routing for BGP
Configure Segment Routing Egress Peer Engineering
Procedure
Step 1
Command or Action
router bgp as-number
Example:
RP/0/RP0/CPU0:router(config)# router bgp
1
Purpose
Specifies the BGP AS number and enters the
BGP configuration mode, allowing you to configure the BGP routing process.
Step 2
Step 3
neighbor ip-address
Example:
RP/0/RP0/CPU0:router(config-bgp)# neighbor 192.168.1.3
Places the router in neighbor configuration mode for BGP routing and configures the neighbor IP address as a BGP peer.
remote-as as-number
Example:
RP/0/RP0/CPU0:router(config-bgp-nbr)# remote-as 3
Creates a neighbor and assigns a remote autonomous system number to it.
Step 4
Step 5
Step 6 egress-engineering
Example:
RP/0/RP0/CPU0:router(config-bgp-nbr)# egress-engineering
Configures the egress node with EPE for the eBGP peer.
exit
Example:
RP/0/RP0/CPU0:router(config-bgp-nbr)# exit
RP/0/RP0/CPU0:router(config-bgp)# exit
RP/0/RP0/CPU0:router(config)# mpls static
Example:
RP/0/RP0/CPU0:router(config)# mpls static
Configure MPLS static on the egress interface connecting to the eBGP peer.
Step 7 interface type interface-path-id
Example:
RP/0/RP0/CPU0:router(config-mpls-static)#
Specifies the egress interface connecting to the eBGP peer.
120
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing for BGP
Configuring Manual BGP-EPE Peering SIDs
Command or Action interface GigabitEthernet0/0/1/2
Step 8 Use the commit or end command.
Purpose commit —Saves the configuration changes and remains within the configuration session.
end —Prompts user to take one of these actions:
• Yes — Saves configuration changes and exits the configuration session.
• No —Exits the configuration session without committing the configuration changes.
• Cancel —Remains in the configuration session, without committing the configuration changes.
Example
Running Config: router bgp 1 neighbor 192.168.1.3
remote-as 3
!
egress-engineering
!
mpls static interface GigabitEthernet0/0/1/2
!
!
Configuring Manual BGP-EPE Peering SIDs
Configuring manual BGP-EPE Peer SIDs allows for persistent EPE label values. Manual BGP-EPE SIDs are advertised through BGP-LS and are allocated from the Segment Routing Local Block (SRLB). See
Segment Routing Global Block and Segment Routing Local Block, on page 85
for information about the
SRLB.
Each PeerNode SID, PeerAdjacency SID, and PeerSet SID is configured with an index value. This index serves as an offset from the configured SRLB start value and the resulting MPLS label (SRLB start label + index) is assigned to these SIDs. This label is used by CEF to perform load balancing across the individual
BGP PeerSet SIDs, BGP PeerNode SID, or ultimately across each first-hop adjacency associated with that
BGP PeerNode SID or BGP PeerSet SID.
Configuring Manual PeerNode SID
Each eBGP peer will be associated with a PeerNode SID index that is configuration driven.
RP/0/0/CPU0:PE1(config)# router bgp 10
RP/0/0/CPU0:PE1(config-bgp)# neighbor 10.10.10.2
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
121
Configure Segment Routing for BGP
Configuring Manual BGP-EPE Peering SIDs
RP/0/0/CPU0:PE1(config-bgp-nbr)# remote-as 20
RP/0/0/CPU0:PE1(config-bgp-nbr)# egress-engineering
RP/0/0/CPU0:PE1(config-bgp-nbr)# peer-node-sid index 600
Configuring Manual PeerAdjacency SID
Any first-hop for which an adjacency SID is configured needs to be in the resolution chain of at least one eBGP peer that is configured for egress-peer engineering. Otherwise such a kind of “orphan” first-hop with regards to BGP has no effect on this feature. This is because BGP only understands next-hops learnt by the
BGP protocol itself and in addition only the resolving IGP next-hops for those BGP next-hops.
RP/0/0/CPU0:PE1(config)# router bgp 10
RP/0/0/CPU0:PE1(config-bgp)# adjacencies
RP/0/0/CPU0:PE1(config-bgp-adj)# 1.1.1.2
RP/0/0/CPU0:PE1(config-bgp-adj)# adjacency-sid index 500
Configuring Manual PeerSet SID
The PeerSet SID is configured under global Address Family. This configuration results in the creation of a
Peer-Set SID EPE object.
RP/0/0/CPU0:PE1(config)# router bgp 10
RP/0/0/CPU0:PE1(config-bgp)# address-family ipv4 unicast
RP/0/0/CPU0:PE1(config-bgp-afi)# peer-set-id 1
RP/0/0/CPU0:PE1(config-bgp-peer-set)# peer-set-sid 300
Example
Topology
The example in this section uses the following topology.
In this example, BGP-EPE peer SIDs are allocated from the default SRLB label range (15000 – 15999). The
BGP-EPE peer SIDs are configured as follows:
• PeerNode SIDs to 10.10.10.2 with index 600 (label 15600), and for 20.10.10.2 with index 700 (label
15700)
122
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing for BGP
Configure BGP Link-State
• PeerAdj SID to link 1.1.1.2 with index 500 (label 15500)
• PeerSet SID 1 to load balance over BGP neighbors 10.10.10.1 and 20.10.10.2 with SID index 300 (label
15300)
• PeerSet SID 2 to load balance over BGP neighbor 20.10.10.2 and link 1.1.1.2 with SID index 400 (label
15400)
Configuration on R1 router bgp 10 address-family ipv4 unicast peer-set-id 1 peer-set-sid index 300
!
peer-set-id 2 peer-set-sid index 400
!
!
adjacencies
1.1.1.2
adjacency-sid index 500 peer-set 2
!
!
neighbor 10.10.10.2
remote-as 20 egress-engineering peer-node-sid index 600
!
peer-set 1 neighbor 20.10.10.2
egress-engineering peer-node-sid index 700
!
peer-set 1 peer-set 2
To further show the load balancing of this example:
• 15600 is load balanced over {1.1.1.1 and 2.1.1.1}
• 15700 is load balanced over {3.1.1.1 and 4.1.1.1}
• 15500 is load balanced over {1.1.1.1}
• 15300 is load balanced over {1.1.1.1, 2.1.1.1, 3.1.1.1 and 4.1.1.1}
• 15400 is load balanced over {1.1.1.1, 3.1.1.1 and 4.1.1.1}
Configure BGP Link-State
BGP Link-State (LS) is an Address Family Identifier (AFI) and Sub-address Family Identifier (SAFI) originally defined to carry interior gateway protocol (IGP) link-state information through BGP. The BGP Network Layer
Reachability Information (NLRI) encoding format for BGP-LS and a new BGP Path Attribute called the
BGP-LS attribute are defined in RFC7752 . The identifying key of each Link-State object, namely a node, link, or prefix, is encoded in the NLRI and the properties of the object are encoded in the BGP-LS attribute.
The BGP-LS Extensions for Segment Routing are documented in RFC9085 .
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
123
Configure Segment Routing for BGP
Configure BGP Link-State
BGP-LS applications like an SR Path Computation Engine (SR-PCE) can learn the SR capabilities of the nodes in the topology and the mapping of SR segments to those nodes. This can enable the SR-PCE to perform path computations based on SR-TE and to steer traffic on paths different from the underlying IGP-based distributed best-path computation.
The following figure shows a typical deployment scenario. In each IGP area, one or more nodes (BGP speakers) are configured with BGP-LS. These BGP speakers form an iBGP mesh by connecting to one or more route-reflectors. This way, all BGP speakers (specifically the route-reflectors) obtain Link-State information from all IGP areas (and from other ASes from eBGP peers).
Usage Guidelines and Limitations
• BGP-LS supports IS-IS and OSPFv2.
• The identifier field of BGP-LS (referred to as the Instance-ID) identifies the IGP routing domain where the NLRI belongs. The NLRIs representing link-state objects (nodes, links, or prefixes) from the same
IGP routing instance must use the same Instance-ID value.
• When there is only a single protocol instance in the network where BGP-LS is operational, we recommend configuring the Instance-ID value to 0 .
• Assign consistent BGP-LS Instance-ID values on all BGP-LS Producers within a given IGP domain.
• NLRIs with different Instance-ID values are considered to be from different IGP routing instances.
• Unique Instance-ID values must be assigned to routing protocol instances operating in different IGP domains. This allows the BGP-LS Consumer (for example, SR-PCE) to build an accurate segregated
124
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing for BGP
Configure BGP Link-State multi-domain topology based on the Instance-ID values, even when the topology is advertised via BGP-LS by multiple BGP-LS Producers in the network.
• If the BGP-LS Instance-ID configuration guidelines are not followed, a BGP-LS Consumer may see duplicate link-state objects for the same node, link, or prefix when there are multiple BGP-LS Producers deployed. This may also result in the BGP-LS Consumers getting an inaccurate network-wide topology.
• The following table defines the supported extensions to the BGP-LS address family for carrying IGP topology information (including SR information) via BGP. For more information on the BGP-LS TLVs, refer to Border Gateway Protocol - Link State (BGP-LS) Parameters .
514
515
516
517
266
267
512
513
262
263
264
265
256
257
258
259
260
261
1024
1026
1027
1028
1029
1030
Table 11: IOS XR Supported BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs
TLV Code Point Description
Local Node Descriptors
Remote Node Descriptors
Link Local/Remote Identifiers
IPv4 interface address
IPv4 neighbor address
IPv6 interface address
IPv6 neighbor address
Multi-Topology ID
OSPF Route Type
IP Reachability Information
Node MSD TLV
Link MSD TLV
Autonomous System
BGP-LS Identifier
OSPF Area-ID
IGP Router-ID
BGP Router-ID TLV
BGP Confederation Member TLV
Node Flag Bits
Node Name
IS-IS Area Identifier
IPv4 Router-ID of Local Node
IPv6 Router-ID of Local Node
IPv4 Router-ID of Remote Node
X
X
—
—
X
X
—
—
—
—
—
X
X
X
X
—
X
—
X
X
X
—
—
X
X
—
X
X
X
X
X
Produced by
IS-IS
X
X
X
X
X
X
X
X
—
X
—
—
X
X
Produced by
OSPFv2
X
X
X
X
—
—
X
X
—
—
—
—
—
—
—
—
—
—
—
—
—
Produced by
BGP
—
—
—
—
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
125
Configure Segment Routing for BGP
Configure BGP Link-State
1120
1122
1152
1153
1154
1116
1117
1118
1119
1102
1103
1114
1115
1088
1089
1090
1091
1092
1093
1094
1095
TLV Code Point
1031
1034
1035
1036
1039
1044
1096
1099
1100
1101
Description
IPv6 Router-ID of Remote Node
SR Capabilities TLV
SR Algorithm TLV
SR Local Block TLV
Flex Algo Definition (FAD) TLV
Flex Algorithm Prefix Metric (FAPM)
TLV
Administrative group (color)
Maximum link bandwidth
Max. reservable link bandwidth
Unreserved bandwidth
TE Default Metric
Link Protection Type
MPLS Protocol Mask
IGP Metric
Shared Risk Link Group
Adjacency SID TLV
LAN Adjacency SID TLV
PeerNode SID TLV
PeerAdj SID TLV
PeerSet SID TLV
Unidirectional Link Delay TLV X
Min/Max Unidirectional Link Delay TLV X
—
—
X
X
X
—
X
X
X
X
X
X
X
X
X
X
X
X
Produced by
IS-IS
X
X
Unidirectional Delay Variation TLV
Unidirectional Link Loss
Unidirectional Residual Bandwidth
Unidirectional Available Bandwidth
Unidirectional Utilized Bandwidth X
Application-Specific Link Attribute TLV X
IGP Flags
IGP Route Tag
IGP Extended Route Tag
X
X
X
X
X
X
X
X
X
—
—
X
X
X
—
X
X
X
X
X
X
X
X
X
X
X
X
—
X
X
X
X
X
X
X
X
Produced by
OSPFv2
—
X
—
—
—
—
Produced by
BGP
—
—
X
X
—
—
—
—
—
X
—
—
—
—
—
—
—
—
—
—
—
—
—
—
—
—
—
126
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing for BGP
Configure BGP Link-State
TLV Code Point
1155
1156
1158
1159
1161
1170
1171
1172
1173
Description
Prefix Metric
OSPF Forwarding Address
Prefix-SID
Range
SID/Label TLV
Prefix Attribute Flags
Source Router Identifier
L2 Bundle Member Attributes TLV
Extended Administrative Group
X
X
X
X
X
X
X
Produced by
IS-IS
X
—
—
—
X
X
X
X
X
Produced by
OSPFv2
X
X
—
—
—
—
—
—
—
Produced by
BGP
—
—
Exchange Link State Information with BGP Neighbor
The following example shows how to exchange link-state information with a BGP neighbor:
Router# configure
Router(config)# router bgp 1
Router(config-bgp)# neighbor 10.0.0.2
Router(config-bgp-nbr)# remote-as 1
Router(config-bgp-nbr)# address-family link-state link-state
Router(config-bgp-nbr-af)# exit
IGP Link-State Database Distribution
A given BGP node may have connections to multiple, independent routing domains. IGP link-state database distribution into BGP-LS is supported for both OSPF and IS-IS protocols in order to distribute this information on to controllers or applications that desire to build paths spanning or including these multiple domains.
To distribute IS-IS link-state data using BGP-LS, use the distribute link-state command in router configuration mode.
Router# configure
Router(config)# router isis isp
Router(config-isis)# distribute link-state instance-id 32
To distribute OSPFv2 link-state data using BGP-LS, use the distribute link-state command in router configuration mode.
Router# configure
Router(config)# router ospf 100
Router(config-ospf)# distribute link-state instance-id 32
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
127
Configure Segment Routing for BGP
Use Case: Configuring SR-EPE and BGP-LS
Use Case: Configuring SR-EPE and BGP-LS
In the following figure, segment routing is enabled on autonomous system AS1 with ingress node A and egress nodes B and C. In this example, we configure EPE on egress node C.
Figure 9: Topology
Procedure
Step 1
Step 2
Configure node C with EPE for eBGP peers D and E.
Example:
RP/0/RP0/CPU0:router_C(config)# router bgp 1
RP/0/RP0/CPU0:router_C(config-bgp)# neighbor 192.168.1.3
RP/0/RP0/CPU0:router_C(config-bgp-nbr)# remote-as 3
RP/0/RP0/CPU0:router_C(config-bgp-nbr)# description to E
RP/0/RP0/CPU0:router_C(config-bgp-nbr)# egress-engineering
RP/0/RP0/CPU0:router_C(config-bgp-nbr)# address-family ipv4 unicast
RP/0/RP0/CPU0:router_C(config-bgp-nbr-af)# route-policy bgp_in in
RP/0/RP0/CPU0:router_C(config-bgp-nbr-af)# route-policy bgp_out out
RP/0/RP0/CPU0:router_C(config-bgp-nbr-af)# exit
RP/0/RP0/CPU0:router_C(config-bgp-nbr)# exit
RP/0/RP0/CPU0:router_C(config-bgp)# neighbor 192.168.1.2
RP/0/RP0/CPU0:router_C(config-bgp-nbr)# remote-as 2
RP/0/RP0/CPU0:router_C(config-bgp-nbr)# description to D
RP/0/RP0/CPU0:router_C(config-bgp-nbr)# egress-engineering
RP/0/RP0/CPU0:router_C(config-bgp-nbr)# address-family ipv4 unicast
RP/0/RP0/CPU0:router_C(config-bgp-nbr-af)# route-policy bgp_in in
RP/0/RP0/CPU0:router_C(config-bgp-nbr-af)# route-policy bgp_out out
RP/0/RP0/CPU0:router_C(config-bgp-nbr-af)# exit
RP/0/RP0/CPU0:router_C(config-bgp-nbr)# exit
Configure node C to advertise peer node SIDs to the controller using BGP-LS.
Example:
RP/0/RP0/CPU0:router_C(config-bgp)# neighbor 172.29.50.71
RP/0/RP0/CPU0:router_C(config-bgp-nbr)# remote-as 1
RP/0/RP0/CPU0:router_C(config-bgp-nbr)# description to EPE_controller
RP/0/RP0/CPU0:router_C(config-bgp-nbr)# address-family link-state link-state
RP/0/RP0/CPU0:router_C(config-bgp-nbr)# exit
RP/0/RP0/CPU0:router_C(config-bgp)# exit
128
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing for BGP
Use Case: Configuring SR-EPE and BGP-LS
Step 3
Step 4
Step 5
Configure MPLS static on the egress interfaces connecting to the eBGP peer.
Example:
RP/0/RP0/CPU0:router_C(config)# mpls static
RP/0/RP0/CPU0:router_C(config-mpls-static)# interface TenGigE 0/3/0/0
RP/0/RP0/CPU0:router_C(config-mpls-static)# interface TenGigE 0/1/0/0
RP/0/RP0/CPU0:router_C(config-mpls-static)# exit
Commit the configuration.
Example:
RP/0/RP0/CPU0:router_C(config)# commit
Verify the configuration.
Example:
RP/0/RP0/CPU0:router_C# show bgp egress-engineering
Egress Engineering Peer Set: 192.168.1.2/32 (10b87210)
Nexthop: 192.168.1.2
Version: 2, rn_version: 2
Flags: 0x00000002
Local ASN: 1
Remote ASN: 2
Local RID: 1.1.1.3
Remote RID: 1.1.1.4
First Hop: 192.168.1.2
NHID: 3
Label: 24002 , Refcount: 3 rpc_set: 10b9d408
Egress Engineering Peer Set: 192.168.1.3/32 (10be61d4)
Nexthop: 192.168.1.3
Version: 3, rn_version: 3
Flags: 0x00000002
Local ASN: 1
Remote ASN: 3
Local RID: 1.1.1.3
Remote RID: 1.1.1.5
First Hop: 192.168.1.3
NHID: 4
Label: 24003 , Refcount: 3 rpc_set: 10be6250
The output shows that node C has allocated peer SIDs for each eBGP peer.
Example:
RP/0/RP0/CPU0:router_C# show mpls forwarding labels 24002 24003
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
24002 Pop No ID Te0/0/0/1 192.168.1.2
0
24003 Pop No ID Te0/0/0/2 192.168.1.3
0
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
129
Configure Segment Routing for BGP
Configure BGP Proxy Prefix SID
The output shows that node C installed peer node SIDs in the Forwarding Information Base (FIB).
Configure BGP Proxy Prefix SID
To support segment routing, Border Gateway Protocol (BGP) requires the ability to advertise a segment identifier (SID) for a BGP prefix. A BGP-Prefix-SID is the segment identifier of the BGP prefix segment in a segment routing network. BGP prefix SID attribute is a BGP extension to signal BGP prefix-SIDs. However, there may be routers which do not support BGP extension for segment routing. Hence, those routers also do not support BGP prefix SID attribute and an alternate approach is required.
BGP proxy prefix SID feature allows you to attach BGP prefix SID attributes for remote prefixes learnt from
BGP labeled unicast (LU) neighbours which are not SR-capable and propagate them as SR prefixes. This allows an LSP towards non SR endpoints to use segment routing global block in a SR domain. Since BGP proxy prefix SID uses global label values it minimizes the use of limited resources such as ECMP-FEC and provides more scalability for the networks.
BGP proxy prefix SID feature is implemented using the segment routing mapping server (SRMS). SRMS allows the user to configure SID mapping entries to specify the prefix-SIDs for the prefixes. The mapping server advertises the local SID-mapping policy to the mapping clients. BGP acts as a client of the SRMS and uses the mapping policy to calculate the prefix-SIDs.
Configuration Example:
This example shows how to configure the BGP proxy prefix SID feature for the segment routing mapping server.
RP/0/RSP0/CPU0:router(config)# segment-routing
RP/0/RSP0/CPU0:router(config-sr)# mapping-server
RP/0/RSP0/CPU0:router(config-sr-ms)# prefix-sid-map
RP/0/RSP0/CPU0:router(config-sr-ms-map)# address-family ipv4
RP/0/RSP0/CPU0:router(config-sr-ms-map-af)# 1.1.1.1/32 10 range 200
RP/0/RSP0/CPU0:router(config-sr-ms-map-af)# 192.168.64.1/32 400 range 300
This example shows how to configure the BGP proxy prefix SID feature for the segment-routing mapping client.
RP/0/RSP0/CPU0:router(config)# router bgp 1
RP/0/RSP0/CPU0:router(config-bgp)# address-family ip4 unicast
RP/0/RSP0/CPU0:router(config-bgp-af)# segment-routing prefix-sid-map
Verification
These examples show how to verify the BGP proxy prefix SID feature.
RP/0/RSP0/CPU0:router# show segment-routing mapping-server prefix-sid-map ipv4 detail
Prefix
1.1.1.1/32
SID Index:
Range:
Last Prefix: 1.1.1.200/32
Last SID Index: 209
Flags:
10
200
130
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing for BGP
Configure BGP Proxy Prefix SID
Number of mapping entries: 1
RP/0/RSP0/CPU0:router# show bgp ipv4 labeled-unicast 192.168.64.1/32
BGP routing table entry for 192.168.64.1/32
Versions:
Process
Speaker bRIB/RIB
117
SendTblVer
117
Local Label: 16400
Last Modified: Oct 25 01:02:28.562 for 00:11:45Paths: (2 available, best #1)
Advertised to peers (in unique update groups):
201.1.1.1
Path #1: Received by speaker 0 Advertised to peers (in unique update groups):
201.1.1.1
Local
20.0.101.1 from 20.0.101.1 (20.0.101.1) Received Label 61
Origin IGP, localpref 100, valid, internal, best, group-best, multipath, labeled-unicast
Received Path ID 0, Local Path ID 0, version 117
Prefix SID Attribute Size: 7
Label Index: 1
RP/0/RSP0/CPU0:router# show route ipv4 unicast 192.68.64.1/32 detail
Routing entry for 192.168.64.1/32
Known via "bgp 65000", distance 200, metric 0, [ei]-bgp, labeled SR, type internal
Installed Oct 25 01:02:28.583 for 00:20:09
Routing Descriptor Blocks
20.0.101.1, from 20.0.101.1, BGP multi path
Route metric is 0
Label: 0x3d (61)
Tunnel ID: None
Binding Label: None
Extended communities count: 0
NHID:0x0(Ref:0)
Route version is 0x6 (6)
Local Label: 0x3e81 (16400)
IP Precedence: Not Set
QoS Group ID: Not Set
Flow-tag: Not Set
Fwd-class: Not Set
Route Priority: RIB_PRIORITY_RECURSIVE (12) SVD Type RIB_SVD_TYPE_LOCAL
Download Priority 4, Download Version 242
No advertising protos.
RP/0/RSP0/CPU0:router# show cef ipv4 192.168.64.1/32 detail
192.168.64.1/32, version 476, labeled SR, drop adjacency, internal 0x5000001 0x80 (ptr
0x71c42b40) [1], 0x0 (0x71c11590), 0x808 (0x722b91e0)
Updated Oct 31 23:23:48.733
Prefix Len 32, traffic index 0, precedence n/a, priority 4
Extensions: context-label:16400 gateway array (0x71ae7e78) reference count 3, flags 0x7a, source rib (7), 0 backups
[2 type 5 flags 0x88401 (0x722eb450) ext 0x0 (0x0)]
LW-LDI[type=5, refc=3, ptr=0x71c11590, sh-ldi=0x722eb450] gateway array update type-time 3 Oct 31 23:49:11.720
LDI Update time Oct 31 23:23:48.733
LW-LDI-TS Oct 31 23:23:48.733
via 20.0.101.1/32, 0 dependencies, recursive, bgp-ext [flags 0x6020] path-idx 0 NHID 0x0 [0x7129a294 0x0] recursion-via-/32 unresolved local label 16400
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
131
Configure Segment Routing for BGP
BGP-LU Inter-AS Option-C Interworking with LDP and IGP SR-MPLS using Proxy BGP-SR labels imposed {ExpNullv6}
RP/0/RSP0/CPU0:router# show bgp labels
BGP router identifier 2.1.1.1, local AS number 65000
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0xe0000000 RD version: 245
BGP main routing table version 245
BGP NSR Initial initsync version 16 (Reached)
BGP NSR/ISSU Sync-Group versions 245/0
BGP scan interval 60 secs
Status codes: s suppressed, d damped, h history, * valid, > best i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Rcvd Label Local Label
*>i1.1.1.1/32
*> 2.1.1.1/32
*> 192.68.64.1/32
*> 192.68.64.2/32
1.1.1.1
0.0.0.0
20.0.101.1
20.0.101.1
3 nolabel
2
2
16010
3
16400
16401
BGP-LU Inter-AS Option-C Interworking with LDP and IGP SR-MPLS using
Proxy BGP-SR
Table 12: Feature History Table
Feature Name
BGP-LU Inter-AS Option-C
Interworking with LDP and IGP
SR-MPLS using Proxy BGP-SR
Release
Release 7.3.2
Description
This feature extends the current
Proxy BGP-SR functionality by allowing the BGP-LU ASBR router with Proxy BGP-SR configured to also interconnect attached LDP domains.
The Proxy BGP-SR feature allows interconnection of IGP SR-MPLS domains and legacy domains via
BGP-LU Inter-AS option-C. It provides a prefix-to-SID mapping for BGP-LU prefixes that are learned without a Prefix-SID.
The Proxy BGP-SR feature allows interconnection of IGP SR-MPLS domains and legacy domains via BGP-LU
Inter-AS option-C. It provides a prefix-to-SID mapping for BGP-LU prefixes that are learned without a
Prefix-SID. This new feature extends the current functionality by allowing the BGP-LU ASBR router
(configured with Proxy BGP-SR) to also interconnect attached LDP domains.
With this enhancement, when performing redistribution from BGP into IGP, LDP would use the same local label assigned by BGP for a prefix learned by BGP-LU. The local label value is based on the SR mapping server configuration (Proxy-BGP SR feature). This behavior allows incoming LDP traffic destined to a redistributed prefix to be switched over to the BGP-LU Inter-AS LSP.
132
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing for BGP
BGP-LU Inter-AS Option-C Interworking with LDP and IGP SR-MPLS using Proxy BGP-SR
Use Case
In the following figure, Router A does the following:
• Is an ASBR for BGP AS 100 running BGP-LU with BGP AS 200
• Interconnects two IS-IS processes: one running LDP and another running Segment Routing
• Redistributes prefixes learned by BGP-LU from AS 200 into both IS-IS instances
• Runs SR Mapping Server (SRMS) in order to assign mappings to prefixes learned by BGP LU from AS
200 without a prefix SID (proxy BGP-SR) and prefixes learned from the LDP domain
Configuration on Router A - ASBR for AS100 prefix-set pfxset-bgplu
100.1.1.8/32 // The Prefix under test end-set
!
prefix-set LOOPBACKS
192.168.0.1,
192.168.0.2,
192.168.0.3,
192.168.0.4,
192.168.0.8
end-set
!
route-policy Pass pass end-policy
!
route-policy rpl-bgplu if destination in pfxset-bgplu then pass else
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
133
Configure Segment Routing for BGP
BGP-LU Inter-AS Option-C Interworking with LDP and IGP SR-MPLS using Proxy BGP-SR drop endif end-policy
!
route-policy MATCH_LOOPBACKS if destination in LOOPBACKS then pass else drop endif end-policy
!
router static address-family ipv4 unicast
!
!
10.10.10.2/32 GigabitEthernet0/2/0/0 router isis 50 is-type level-2-only net 49.0001.0000.0000.0001.00
address-family ipv4 unicast metric-style wide redistribute bgp 100 route-policy rpl-bgplu // Redistribute prefixes learned by BGP-LU into IS-IS LDP domain
!
interface Loopback0 passive address-family ipv4 unicast
!
!
interface GigabitEthernet0/2/0/1 address-family ipv4 unicast
!
!
!
router isis 100 is-type level-2-only net 49.0001.0000.0000.0011.00
distribute link-state address-family ipv4 unicast metric-style wide mpls traffic-eng level-2-only mpls traffic-eng router-id Loopback0 redistribute bgp 100 route-policy rpl-bgplu // Redistribute prefixes learned by BGP-LU into IS-IS SR domain segment-routing mpls segment-routing prefix-sid-map advertise-local
!
interface Loopback0 passive address-family ipv4 unicast
!
prefix-sid index 1
!
interface GigabitEthernet0/2/0/2 address-family ipv4 unicast
!
!
!
router bgp 100 bgp router-id 192.168.0.1
address-family ipv4 unicast segment-routing prefix-sid-map // SR Proxy SID Configuration network 192.168.0.1/32
134
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing for BGP
BGP-LU Inter-AS Option-C Interworking with LDP and IGP SR-MPLS using Proxy BGP-SR redistribute isis 50 route-policy MATCH_LOOPBACKS redistribute isis 100 route-policy MATCH_LOOPBACKS
!
allocate-label all neighbor 10.10.10.2
remote-as 200 address-family ipv4 labeled-unicast route-policy Pass in route-policy Pass out
!
!
!
mpls ldp router-id 192.168.0.1
!
interface GigabitEthernet0/2/0/1
!
segment-routing global-block 16000 23999 mapping-server prefix-sid-map // SRMS configuration address-family ipv4
3
100.1.1.8/32 108 range 1 // SRMS mapping - LU prefix 100.1.1.8/32 assigned prefix index
108
192.168.0.3/32 3 range 1 // SRMS mapping - LDP prefix Router C assigned prefix index
!
!
!
!
Configuration on Router B - ASBR for AS200 route-policy Pass pass end-policy
!
router static address-family ipv4 unicast
!
10.10.10.1/32 GigabitEthernet0/0/0/0
!
router bgp 200 bgp router-id 192.168.0.2
address-family ipv4 unicast network 100.1.1.8/32 // Import/Inject route into BGP network 192.168.0.2/32
!
allocate-label all neighbor 10.10.10.1
!
!
remote-as 100 address-family ipv4 labeled-unicast
!
route-policy Pass in route-policy Pass out
Configuration on Router C in the LDP Domain router isis 50 is-type level-2-only net 49.0001.0000.0000.0003.00
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
135
BGP-LU Inter-AS Option-C Interworking with LDP and IGP SR-MPLS using Proxy BGP-SR
!
address-family ipv4 unicast
!
!
mpls ldp router-id 192.168.0.3
interface GigabitEthernet0/0/0/0
!
!
address-family ipv4 unicast metric-style wide
!
interface Loopback0 passive address-family ipv4 unicast
!
!
interface GigabitEthernet0/0/0/0
Configuration on Router D in the SR IS-IS Domain router isis 100 is-type level-2-only net 49.0001.0000.0000.0004.00
address-family ipv4 unicast metric-style wide mpls traffic-eng level-2-only mpls traffic-eng router-id Loopback0 segment-routing mpls
!
interface Loopback0
!
!
passive address-family ipv4 unicast prefix-sid index 4
!
!
interface GigabitEthernet0/0/0/0 address-family ipv4 unicast
!
segment-routing
!
Configure Segment Routing for BGP
136
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure SR-TE Policies
C H A P T E R
7
This module provides information about segment routing for traffic engineering (SR-TE) policies, how to configure SR-TE policies, and how to steer traffic into an SR-TE policy.
•
SR-TE Policy Overview, on page 137
•
Usage Guidelines and Limitations, on page 138
•
Instantiation of an SR Policy, on page 138
•
SR-TE Policy Path Types, on page 175
•
•
•
SR-TE Policy Overview
Segment routing for traffic engineering (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.
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 following 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.
An SR-TE policy is identified as an ordered list (head-end, color, end-point):
• Head-end – Where the SR-TE policy is instantiated
• Color – A numerical value that distinguishes between two or more policies to the same node pairs
(Head-end – End point)
• End-point – The destination of the SR-TE policy
Every SR-TE policy has a color value. Every policy between the same node pairs requires a unique color value.
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 (for weighted equal cost multi-path [WECMP]). A candidate path is either dynamic or explicit. See SR-TE Policy Path Types section for more information.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
137
Configure SR-TE Policies
Usage Guidelines and Limitations
Usage Guidelines and Limitations
Observe the following guidelines and limitations for the platform.
• L3VPN BGP PIC over SR-TE is supported.
BGP PIC over SR-TE is supported when both primary and backup paths each resolve into the BSID of an SR policy. BGP PIC over SR-TE is not supported when primary and backup paths are of different resolution types. For example, when a primary path resolves into the BSID of an SR policy, the backup path cannot point to a native LSP. When this happens, the backup path will not be programmed. For information about BGP PIC, refer to the BGP PIC chapter in the BGP Configuration Guide for Cisco
NCS 560 Series Routers .
• SR-TE over BVI is not supported. An SR-TE policy cannot be resolved over an MPLS-enabled BVI interface.
• Counter implications when BVI and SR-TE co-exist in same NPU—Counters for a BVI's logical interface are not allocated when the same NPU hosts layer-2 (sub)interface(s) associated with the BVI alongside other port(s) used as egress interface(s) for an SR policy
• GRE tunnel as primary interface for an SR policy is not supported.
• GRE tunnel as backup interface for an SR policy with TI-LFA protection is not supported.
• Head-end computed inter-domain SR policy with Flex Algo constraint and IGP redistribution is not supported. This is supported with Flex Algo-aware path computation at SR-PCE, with or without IGP redistribution. See
SR-PCE Flexible Algorithm Multi-Domain Path Computation, on page 266
.
Instantiation of an SR Policy
An SR policy is instantiated, or implemented, at the head-end router.
The following sections provide details on the SR policy instantiation methods:
•
On-Demand SR Policy – SR On-Demand Next-Hop , on page 138
•
Manually Provisioned SR Policy, on page 171
•
PCE-Initiated SR Policy, on page 171
On-Demand SR Policy – SR On-Demand Next-Hop
Segment Routing On-Demand Next Hop (SR-ODN) allows a service head-end router to automatically instantiate an SR policy to a BGP next-hop when required (on-demand). Its key benefits include:
• SLA-aware BGP service – Provides per-destination steering behaviors where a prefix, a set of prefixes, or all prefixes from a service can be associated with a desired underlay SLA. The functionality applies equally to single-domain and multi-domain networks.
• Simplicity – No prior SR Policy configuration needs to be configured and maintained. Instead, operator simply configures a small set of common intent-based optimization templates throughout the network.
138
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure SR-TE Policies
On-Demand SR Policy – SR On-Demand Next-Hop
• Scalability – Device resources at the head-end router are used only when required, based on service or
SLA connectivity needs.
The following example shows how SR-ODN works:
1.
An egress PE (node H) advertises a BGP route for prefix T/t. This advertisement includes an SLA intent encoded with a BGP color extended community. In this example, the operator assigns color purple (example value = 100) to prefixes that should traverse the network over the delay-optimized path.
2.
The route reflector receives the advertised route and advertises it to other PE nodes.
3.
Ingress PEs in the network (such as node F) are pre-configured with an ODN template for color purple that provides the node with the steps to follow in case a route with the intended color appears, for example:
• Contact SR-PCE and request computation for a path toward node H that does not share any nodes with another LSP in the same disjointness group.
• At the head-end router, compute a path towards node H that minimizes cumulative delay.
4.
In this example, the head-end router contacts the SR-PCE and requests computation for a path toward node H that minimizes cumulative delay.
5.
After SR-PCE provides the compute path, an intent-driven SR policy is instantiated at the head-end router.
Other prefixes with the same intent (color) and destined to the same egress PE can share the same on-demand SR policy. When the last prefix associated with a given [intent, egress PE] pair is withdrawn, the on-demand SR policy is deleted, and resources are freed from the head-end router.
An on-demand SR policy is created dynamically for BGP global or VPN (service) routes. The following services are supported with SR-ODN:
• EVPN-VPWS (single-homing)
• EVPN-VPWS (multi-homing)
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
139
Configure SR-TE Policies
SR-ODN Configuration Steps
• EVPN (single-homing/multi-homing)
Note For EVPN single-homing, you must configure an EVPN Ethernet
Segment Identifier (ESI) with a non-zero value.
Note Colored per-ESI/per-EVI EVPN Ethernet Auto-Discovery route (route-type 1) and Inclusive Multicast Route
(route-type 3) are used to trigger instantiation of ODN SR-TE policies.
Note The following scenarios involving virtual Ethernet Segments (vES) are also supported with EVPN ODN:
• VPLS VFI as vES for single-active Multi-Homing to EVPN
• Active/backup Pseudo-wire (PW) as vES for Single-Homing to EVPN
• Static Pseudo-wire (PW) as vES for active-active Multi-Homing to EVPN
SR-ODN Configuration Steps
To configure SR-ODN, complete the following configurations:
1.
Define the SR-ODN template on the SR-TE head-end router.
(Optional) If using Segment Routing Path Computation Element (SR-PCE) for path computation: a.
Configure SR-PCE. For detailed SR-PCE configuration information, see
b.
Configure the head-end router as Path Computation Element Protocol (PCEP) Path Computation
Client (PCC). For detailed PCEP PCC configuration information, see
Configure the Head-End Router as PCEP PCC .
2.
Define BGP color extended communities. Refer to the "Implementing BGP" chapter in the BGP
Configuration Guide for Cisco NCS 560 Series Routers .
3.
Define routing policies (using routing policy language [RPL]) to set BGP color extended communities.
Refer to the "Implementing Routing Policy" chapter in the Routing Configuration Guide for Cisco NCS
560 Series Routers .
The following RPL attach-points for setting/matching BGP color extended communities are supported:
Note The following table shows the supported RPL match operations; however, routing policies are required primarily to set BGP color extended community. Matching based on BGP color extended communities is performed automatically by ODN's on-demand color template.
140
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure SR-TE Policies
SR-ODN Configuration Steps
Attach Point
VRF export
VRF import
Neighbor-in
Neighbor-out
Inter-AFI export
Inter-AFI import
Default-originate
Set
X
–
X
X
–
–
X
X
X
X
X
Match
X
X
–
4.
Apply routing policies to a service. Refer to the "Implementing Routing Policy" chapter in the Routing
Configuration Guide for Cisco NCS 560 Series Routers .
Configure On-Demand Color Template
• Use the on-demand color color command to create an ODN template for the specified color value. The head-end router automatically follows the actions defined in the template upon arrival of BGP global or
VPN routes with a BGP color extended community that matches the color value specified in the template.
The color range is from 1 to 4294967295.
Router(config)# segment-routing traffic-eng
Router(config-sr-te)# on-demand color 10
Note Matching based on BGP color extended communities is performed automatically via ODN's on-demand color template. RPL routing policies are not required.
• Use the on-demand color color dynamic command to associate the template with on-demand SR policies with a locally computed dynamic path (by SR-TE head-end router utilizing its TE topology database) or centrally (by SR-PCE). The head-end router will first attempt to install the locally computed path; otherwise, it will use the path computed by the SR-PCE.
Router(config)# segment-routing traffic-eng
Router(config-sr-te)# on-demand color 10 dynamic
• Use the on-demand color color dynamic pcep command to indicate that only the path computed by
SR-PCE should be associated with the on-demand SR policy. With this configuration, local path computation is not attempted; instead the head-end router will only instantiate the path computed by the
SR-PCE.
Router(config-sr-te)# on-demand color 10 dynamic pcep
Configure Dynamic Path Optimization Objectives
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
141
Configure SR-TE Policies
Configuring SR-ODN: Examples
• Use the metric type { igp | te | latency } command to configure the metric for use in path computation.
Router(config-sr-te-color-dyn)# metric type te
• Use the metric margin { absolute value | relative percent } command to configure the On-Demand dynamic path metric margin. The range for value and percent is from 0 to 2147483647.
Router(config-sr-te-color-dyn)# metric margin absolute 5
Configure Dynamic Path Constraints
• Use the disjoint-path group-id group-id type { link | node | srlg | srlg-node } [ sub-id sub-id ] command to configure the disjoint-path constraints. The group-id and sub-id range is from 1 to 65535.
Router(config-sr-te-color-dyn)# disjoint-path group-id 775 type link
• Use the affinity { include-any | include-all | exclude-any } { name WORD } command to configure the affinity constraints.
Router(config-sr-te-color-dyn)# affinity exclude-any name CROSS
• Use the maximum-sid-depth value command to customize the maximum SID depth (MSD) constraints advertised by the router.
The default MSD value is equal to the maximum MSD supported by the platform (12).
Router(config-sr-te-color)# maximum-sid-depth 5
See
Customize MSD Value at PCC, on page 190
for information about SR-TE label imposition capabilities.
• Use the constraints segments sid-algorithm algorithm-number command to configure the SR Flexible
Algorithm constraints. The algorithm-number range is from 128 to 255.
Router(config-sr-te-color)# constraints segments sid-algorithm 128
• Use the constraints segments protection { protected-only | protected-preferred | unprotected-only
| unprotected-preferred } command to configure the Adj-SID protection behavior constraints.
Router(config-sr-te-color)# constraints segments protection protected-only
See
Segment Protection-Type Constraint, on page 178
for information about Adj-SID protection behavior.
Configuring SR-ODN: Examples
Configuring SR-ODN: Layer-3 Services Examples
The following examples show end-to-end configurations used in implementing SR-ODN on the head-end router.
Configuring ODN Color Templates: Example
Configure ODN color templates on routers acting as SR-TE head-end nodes. The following example shows various ODN color templates:
• color 10: minimization objective = te-metric
142
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure SR-TE Policies
Configuring SR-ODN: Layer-3 Services Examples
• color 20: minimization objective = igp-metric
• color 21: minimization objective = igp-metric; constraints = affinity
• color 22: minimization objective = te-metric; path computation at SR-PCE; constraints = affinity segment-routing traffic-eng on-demand color 10 dynamic metric type te
!
!
!
on-demand color 20 dynamic
!
!
!
metric type igp on-demand color 21 dynamic metric type igp
!
!
!
!
affinity exclude-any name CROSS on-demand color 22 dynamic pcep
!
metric
!
type te
!
!
affinity exclude-any name CROSS
!
!
!
!
end
!
on-demand color 128 constraints segments sid-algorithm 128
Configuring BGP Color Extended Community Set: Example
The following example shows how to configure BGP color extended communities that are later applied to
BGP service routes via route-policies.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
143
Configure SR-TE Policies
Configuring SR-ODN: Layer-3 Services Examples
Note In most common scenarios, egress PE routers that advertise BGP service routes apply (set) BGP color extended communities. However, color can also be set at the ingress PE router.
extcommunity-set opaque color10-te
10 end-set
!
extcommunity-set opaque color20-igp
20 end-set
!
extcommunity-set opaque color21-igp-excl-cross
21 end-set
!
Configuring RPL to Set BGP Color (Layer-3 Services): Examples
The following example shows various representative RPL definitions that set BGP color community.
The examples include the set color action only. The last RPL example performs the set color action for selected destinations based on a prefix-set.
route-policy SET_COLOR_LOW_LATENCY_TE set extcommunity color color10-te pass end-policy
!
route-policy SET_COLOR_HI_BW set extcommunity color color20-igp pass end-policy
!
prefix-set sample-set
88.1.0.0/24 end-set
!
route-policy SET_COLOR_GLOBAL if destination in sample-set then set extcommunity color color10-te else pass endif end-policy
Applying RPL to BGP Services (Layer-3 Services): Example
The following example shows various RPLs that set BGP color community being applied to BGP Layer-3
VPN services (VPNv4/VPNv6) and BGP global.
• The L3VPN examples show the RPL applied at the VRF export attach-point.
• The BGP global example shows the RPL applied at the BGP neighbor-out attach-point.
vrf vrf_cust1 address-family ipv4 unicast export route-policy SET_COLOR_LOW_LATENCY_TE
144
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure SR-TE Policies
Configuring SR-ODN: Layer-3 Services Examples
!
address-family ipv6 unicast
!
export route-policy SET_COLOR_LOW_LATENCY_TE
!
vrf vrf_cust2 address-family ipv4 unicast
!
export route-policy SET_COLOR_HI_BW
!
address-family ipv6 unicast export route-policy SET_COLOR_HI_BW
!
router bgp 100 neighbor-group BR-TO-RR address-family ipv4 unicast
!
route-policy SET_COLOR_GLOBAL out
!
!
end
Verifying BGP VRF Information
Use the show bgp vrf command to display BGP prefix information for VRF instances. The following output shows the BGP VRF table including a prefix (88.1.1.0/24) with color 10 advertised by router 1.1.1.8.
RP/0/RP0/CPU0:R4# show bgp vrf vrf_cust1
BGP VRF vrf_cust1, state: Active
BGP Route Distinguisher: 1.1.1.4:101
VRF ID: 0x60000007
BGP router identifier 1.1.1.4, local AS number 100
Non-stop routing is enabled
BGP table state: Active
Table ID: 0xe0000007 RD version: 282
BGP main routing table version 287
BGP NSR Initial initsync version 31 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
Status codes: s suppressed, d damped, h history, * valid, > best i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 1.1.1.4:101 (default for vrf vrf_cust1)
*> 44.1.1.0/24 40.4.101.11
*>i55.1.1.0/24 1.1.1.5
100
*>i88.1.1.0/24
*>i99.1.1.0/24
1.1.1.8 C:10
1.1.1.9
100
100
0 400 {1} i
0 500 {1} i
0 800 {1} i
0 800 {1} i
Processed 4 prefixes, 4 paths
The following output displays the details for prefix 88.1.1.0/24. Note the presence of BGP extended color community 10, and that the prefix is associated with an SR policy with color 10 and BSID value of 24036.
RP/0/RP0/CPU0:R4# show bgp vrf vrf_cust1 88.1.1.0/24
BGP routing table entry for 88.1.1.0/24, Route Distinguisher: 1.1.1.4:101
Versions:
Process bRIB/RIB SendTblVer
Speaker 282 282
Last Modified: May 20 09:23:34.112 for 00:06:03
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
145
Configure SR-TE Policies
Configuring SR-ODN: Layer-3 Services Examples
Paths: (1 available, best #1)
Advertised to CE peers (in unique update groups):
40.4.101.11
Path #1: Received by speaker 0
Advertised to CE peers (in unique update groups):
40.4.101.11
800 {1}
1.1.1.8 C:10 (bsid:24036) (metric 20) from 1.1.1.55 (1.1.1.8)
Received Label 24012
Origin IGP, localpref 100, valid, internal, best, group-best, import-candidate, imported
Received Path ID 0, Local Path ID 1, version 273
Extended community: Color:10 RT:100:1
Originator: 1.1.1.8, Cluster list: 1.1.1.55
SR policy color 10, up, registered, bsid 24036, if-handle 0x08000024
Source AFI: VPNv4 Unicast, Source VRF: default, Source Route Distinguisher: 1.1.1.8:101
Verifying Forwarding (CEF) Table
Use the show cef vrf command to display the contents of the CEF table for the VRF instance. Note that prefix
88.1.1.0/24 points to the BSID label corresponding to an SR policy. Other non-colored prefixes, such as
55.1.1.0/24, point to BGP next-hop.
RP/0/RP0/CPU0:R4# show cef vrf vrf_cust1
Prefix Next Hop Interface
------------------- ------------------- ------------------
0.0.0.0/0 drop default handler
0.0.0.0/32
40.4.101.0/24 broadcast attached TenGigE0/0/0/0.101
40.4.101.0/32
40.4.101.4/32
40.4.101.11/32 broadcast receive
40.4.101.11/32
TenGigE0/0/0/0.101
TenGigE0/0/0/0.101
TenGigE0/0/0/0.101
40.4.101.255/32
44.1.1.0/24
55.1.1.0/24
88.1.1.0/24
99.1.1.0/24
224.0.0.0/4 broadcast
40.4.101.11/32
1.1.1.9/32
0.0.0.0/32
224.0.0.0/24 receive
255.255.255.255/32 broadcast
TenGigE0/0/0/0.101
<recursive>
1.1.1.5/32 <recursive>
24036 (via-label) <recursive>
<recursive>
The following output displays CEF details for prefix 88.1.1.0/24. Note that the prefix is associated with an
SR policy with BSID value of 24036.
RP/0/RP0/CPU0:R4# show cef vrf vrf_cust1 88.1.1.0/24
88.1.1.0/24, version 51, internal 0x5000001 0x0 (ptr 0x98c60ddc) [1], 0x0 (0x0), 0x208
(0x98425268)
Updated May 20 09:23:34.216
Prefix Len 24, traffic index 0, precedence n/a, priority 3 via local-label 24036, 5 dependencies, recursive [flags 0x6000] path-idx 0 NHID 0x0 [0x97091ec0 0x0] recursion-via-label next hop VRF - 'default', table - 0xe0000000 next hop via 24036/0/21 next hop srte_c_10_ep labels imposed {ImplNull 24012}
146
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure SR-TE Policies
Configuring SR-ODN: Layer-3 Services Examples
Verifying SR Policy
Use the show segment-routing traffic-eng policy command to display SR policy information.
The following outputs show the details of an on-demand SR policy that was triggered by prefixes with color
10 advertised by node 1.1.1.8.
RP/0/RP0/CPU0:R4# show segment-routing traffic-eng policy color 10 tabular
Color Endpoint Admin Oper Binding
State State SID
------ -------------------- ------ ------ --------------------
10 1.1.1.8
up up 24036
The following outputs show the details of the on-demand SR policy for BSID 24036.
Note There are 2 candidate paths associated with this SR policy: the path that is computed by the head-end router
(with preference 200), and the path that is computed by the SR-PCE (with preference 100). The candidate path with the highest preference is the active candidate path (highlighted below) and is installed in forwarding.
RP/0/RP0/CPU0:R4# show segment-routing traffic-eng policy binding-sid 24036
SR-TE policy database
---------------------
Color: 10, End-point: 1.1.1.8
Name: srte_c_10_ep_1.1.1.8
Status:
Admin: up Operational: up for 4d14h (since Jul 3 20:28:57.840)
Candidate-paths:
Preference: 200 (BGP ODN) (active)
Requested BSID: dynamic
PCC info:
Symbolic name: bgp_c_10_ep_1.1.1.8_discr_200
PLSP-ID: 12
Dynamic (valid)
Metric Type: TE, Path Accumulated Metric: 30
16009 [Prefix-SID, 1.1.1.9]
16008 [Prefix-SID, 1.1.1.8]
Preference: 100 (BGP ODN)
Requested BSID: dynamic
PCC info:
Symbolic name: bgp_c_10_ep_1.1.1.8_discr_100
PLSP-ID: 11
Dynamic (pce 1.1.1.57) (valid)
Metric Type: TE, Path Accumulated Metric: 30
16009 [Prefix-SID, 1.1.1.9]
16008 [Prefix-SID, 1.1.1.8]
Attributes:
Binding SID: 24036
Forward Class: 0
Steering BGP disabled: no
IPv6 caps enable: yes
Verifying SR Policy Forwarding
Use the show segment-routing traffic-eng forwarding policy command to display the SR policy forwarding information.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
147
Configure SR-TE Policies
Configuring SR-ODN: EVPN Services Examples
The following outputs show the forwarding details for an on-demand SR policy that was triggered by prefixes with color 10 advertised by node 1.1.1.8.
RP/0/RP0/CPU0:R4# show segment-routing traffic-eng forwarding policy binding-sid 24036 tabular
Color Endpoint Segment Outgoing Outgoing Next Hop Bytes Pure
List Label Interface Switched Backup
----- --------------- ------------ -------- ------------ ------------ ------------ ------
10 1.1.1.8
dynamic 16009 Gi0/0/0/4 10.4.5.5
0
16001 Gi0/0/0/5 11.4.8.8
0 Yes
RP/0/RP0/CPU0:R4# show segment-routing traffic-eng forwarding policy binding-sid 24036 detail
Mon Jul 8 11:56:46.887 PST
SR-TE Policy Forwarding database
--------------------------------
Color: 10, End-point: 1.1.1.8
Name: srte_c_10_ep_1.1.1.8
Binding SID: 24036
Segment Lists:
SL[0]:
Name: dynamic
Paths:
Path[0]:
Outgoing Label: 16009
Outgoing Interface: GigabitEthernet0/0/0/4
Next Hop: 10.4.5.5
Switched Packets/Bytes: 0/0
FRR Pure Backup: No
Label Stack (Top -> Bottom): { 16009, 16008 }
Path-id: 1 (Protected), Backup-path-id: 2, Weight: 64
Path[1]:
Outgoing Label: 16001
Outgoing Interface: GigabitEthernet0/0/0/5
Next Hop: 11.4.8.8
Switched Packets/Bytes: 0/0
FRR Pure Backup: Yes
Label Stack (Top -> Bottom): { 16001, 16009, 16008 }
Path-id: 2 (Pure-Backup), Weight: 64
Policy Packets/Bytes Switched: 0/0
Local label: 80013
Configuring SR-ODN: EVPN Services Examples
Configuring BGP Color Extended Community Set: Example
The following example shows how to configure BGP color extended communities that are later applied to
BGP service routes via route-policies.
extcommunity-set opaque color-44
44 end-set extcommunity-set opaque color-55
55 end-set extcommunity-set opaque color-77
77
148
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure SR-TE Policies
Configuring SR-ODN: EVPN Services Examples end-set extcommunity-set opaque color-88
88 end-set
Configuring RPL to Set BGP Color (EVPN Services): Examples
The following examples shows various representative RPL definitions that set BGP color community.
The following RPL examples match on EVPN route-types and then set the BGP color extended community.
route-policy sample-export-rpl if evpn-route-type is 1 then set extcommunity color color-44 endif if evpn-route-type is 3 then set extcommunity color color-55 endif end-policy route-policy sample-import-rpl if evpn-route-type is 1 then set extcommunity color color-77 elseif evpn-route-type is 3 then set extcommunity color color-88 else pass endif end-policy
The following RPL example sets BGP color extended community while matching on the following:
• Route Distinguisher (RD)
• Ethernet Segment Identifier (ESI)
• Ethernet Tag (ETAG)
• EVPN route-types route-policy sample-bgpneighbor-rpl if rd in (1.1.1.1:3504) then set extcommunity color color3504 elseif rd in (1.1.1.1:3505) then set extcommunity color color3505 elseif rd in (1.1.1.1:3506) then set extcommunity color color99996 elseif esi in (0010.0000.0000.0000.1201) and rd in (1.1.1.1:3508) then set extcommunity color color3508 elseif etag in (30509) and rd in (1.1.1.1:3509) then set extcommunity color color3509 elseif etag in (0) and rd in (1.1.1.1:2001) and evpn-route-type is 1 then set extcommunity color color82001 elseif etag in (0) and rd in (1.1.1.1:2001) and evpn-route-type is 3 then set extcommunity color color92001 endif pass end-policy
Applying RPL to BGP Services (EVPN Services): Example
The following examples show various RPLs that set BGP color community being applied to EVPN services.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
149
Configure SR-TE Policies
Configuring SR-ODN: EVPN Services Examples
The following 2 examples show the RPL applied at the EVI export and import attach-points.
Note RPLs applied under EVI import or export attach-point also support matching on the following:
• Ethernet Segment Identifier (ESI)
• Ethernet Tag (ETAG)
• EVPN-Originator evpn evi 101 bgp route-target 101:1 route-target import 100:1 route-target export 101:1 route-policy import sample-import-rpl
!
advertise-mac
!
!
evi 102 bgp route-target 102:1 route-target import 100:2 route-target export 102:1 route-policy export sample-export-rpl
!
!
!
!
advertise-mac
The following example shows the RPL applied at the BGP neighbor-out attach-point.
Note RPLs defined under BGP neighbor-out attach-point also support matching on the following:
• EVPN-Originator router bgp 100 bgp router-id 1.1.1.1
address-family l2vpn evpn
!
neighbor-group evpn-rr remote-as 100 update-source Loopback0 address-family l2vpn evpn
!
neighbor 10.10.10.10
use neighbor-group evpn-rr address-family l2vpn evpn route-policy sample-bgpneighbor-rpl out
150
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure SR-TE Policies
Configuring SR-ODN for EVPN-VPWS: Use Case
Configuring SR-ODN for EVPN-VPWS: Use Case
This use case shows how to set up a pair of ELINE services using EVPN-VPWS between two sites. Services are carried over SR policies that must not share any common links along their paths (link-disjoint). The SR policies are triggered on-demand based on ODN principles. An SR-PCE computes the disjoint paths.
This use case uses the following topology with 2 sites: Site 1 with nodes A and B, and Site 2 with nodes C and D.
Figure 10: Topology for Use Case: SR-ODN for EVPN-VPWS
Table 13: Use Case Parameters
IP Addresses of
Loopback0 (Lo0)
Interfaces
SR-PCE Lo0: 1.1.1.207
Site 1:
• Node A Lo0: 1.1.1.5
• Node B Lo0: 1.1.1.6
Site 2:
• Node C Lo0: 1.1.1.2
• Node D Lo0: 1.1.1.4
EVPN-VPWS Service
Parameters
ODN BGP Color Extended
Communities
Site 1 routers (Nodes A and B):
• set color 10000
• match color 11000
Note
ELINE-1:
• EVPN-VPWS EVI 100
• Node A: AC-ID = 11
• Node C: AC-ID = 21
ELINE-2:
• EVPN-VPWS EVI 101
• Node B: AC-ID = 12
• Node D: AC-ID = 22
Site 2 routers (Nodes C and D):
• set color 11000
• match color 10000
These colors are associated with the EVPN route-type 1 routes of the EVPN-VPWS services.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
151
Configure SR-TE Policies
Configuring SR-ODN for EVPN-VPWS: Use Case
PCEP LSP Disjoint-Path
Association Group ID
Site 1 to Site 2 LSPs (from Node A to Node C/from
Node B to Node D):
Site 2 to Site 1 LSPs (from Node C to Node A/from
Node D to Node B):
• group-id = 775 • group-id = 776
The use case provides configuration and verification outputs for all devices.
Configuration Verification
Configuration: SR-PCE, on page 152
Verification: SR-PCE, on page 156
Configuration: Site 1 Node A, on page 152
Configuration: Site 1 Node B, on page 153
Configuration: Site 2 Node C, on page 154
Configuration: Site 2 Node D, on page 155
Verification: Site 1 Node A, on page 160
Verification: Site 1 Node B, on page 163
Verification: Site 2 Node C, on page 166
Verification: Site 2 Node D, on page 168
Configuration: SR-PCE
For cases when PCC nodes support, or signal, PCEP association-group object to indicate the pair of LSPs in a disjoint set, there is no extra configuration required at the SR-PCE to trigger disjoint-path computation.
Note SR-PCE also supports disjoint-path computation for cases when PCC nodes do not support PCEP association-group object. See
Configure the Disjoint Policy (Optional), on page 263
for more information.
Configuration: Site 1 Node A
This section depicts relevant configuration of Node A at Site 1. It includes service configuration, BGP color extended community, and RPL. It also includes the corresponding ODN template required to achieve the disjointness SLA.
Nodes in Site 1 are configured to set color 10000 on originating EVPN routes, while matching color 11000 on incoming EVPN routes from routers located at Site 2.
Since both nodes in Site 1 request path computation from SR-PCE using the same disjoint-path group-id
(775), the PCE will attempt to compute disjointness for the pair of LSPs originating from Site 1 toward Site
2.
/* EVPN-VPWS configuration */ interface GigabitEthernet0/0/0/3.2500 l2transport encapsulation dot1q 2500 rewrite ingress tag pop 1 symmetric
!
l2vpn xconnect group evpn_vpws_group p2p evpn_vpws_100 interface GigabitEthernet0/0/0/3.2500
neighbor evpn evi 100 target 21 source 11
!
!
!
152
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure SR-TE Policies
Configuring SR-ODN for EVPN-VPWS: Use Case
!
/* BGP color community and RPL configuration */ extcommunity-set opaque color-10000
10000 end-set
!
route-policy SET_COLOR_EVPN_VPWS if evpn-route-type is 1 and rd in (ios-regex '.*..*..*..*:( 100 )') then set extcommunity color color-10000 endif pass end-policy
!
router bgp 65000 neighbor 1.1.1.253
address-family l2vpn evpn route-policy SET_COLOR_EVPN_VPWS out
!
!
!
/* ODN template configuration */ segment-routing traffic-eng on-demand color 11000 dynamic pcep
!
metric
!
!
type igp disjoint-path group-id 775 type link
!
!
!
Configuration: Site 1 Node B
This section depicts relevant configuration of Node B at Site 1.
/* EVPN-VPWS configuration */ interface TenGigE0/3/0/0/8.2500 l2transport
!
encapsulation dot1q 2500 rewrite ingress tag pop 1 symmetric l2vpn xconnect group evpn_vpws_group
!
!
!
p2p evpn_vpws_101 interface TenGigE0/3/0/0/8.2500
neighbor evpn evi 101 target 22 source 12
!
/* BGP color community and RPL configuration */ extcommunity-set opaque color-10000
10000
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
153
Configure SR-TE Policies
Configuring SR-ODN for EVPN-VPWS: Use Case end-set
!
route-policy SET_COLOR_EVPN_VPWS if evpn-route-type is 1 and rd in (ios-regex '.*..*..*..*:( 101 )') then set extcommunity color color-10000 endif pass end-policy
!
router bgp 65000 neighbor 1.1.1.253
address-family l2vpn evpn route-policy SET_COLOR_EVPN_VPWS out
!
!
!
/* ODN template configuration */ segment-routing traffic-eng on-demand color 11000 dynamic
!
!
!
pcep
!
metric
!
type igp disjoint-path group-id 775 type link
!
Configuration: Site 2 Node C
This section depicts relevant configuration of Node C at Site 2. It includes service configuration, BGP color extended community, and RPL. It also includes the corresponding ODN template required to achieve the disjointness SLA.
Nodes in Site 2 are configured to set color 11000 on originating EVPN routes, while matching color 10000 on incoming EVPN routes from routers located at Site 1.
Since both nodes on Site 2 request path computation from SR-PCE using the same disjoint-path group-id
(776), the PCE will attempt to compute disjointness for the pair of LSPs originating from Site 2 toward Site
1.
/* EVPN-VPWS configuration */ interface GigabitEthernet0/0/0/3.2500 l2transport encapsulation dot1q 2500 rewrite ingress tag pop 1 symmetric
!
l2vpn xconnect group evpn_vpws_group
!
!
p2p evpn_vpws_100 interface GigabitEthernet0/0/0/3.2500
neighbor evpn evi 100 target 11 source 21
!
!
154
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure SR-TE Policies
Configuring SR-ODN for EVPN-VPWS: Use Case
/* BGP color community and RPL configuration */ extcommunity-set opaque color-11000
11000 end-set
!
route-policy SET_COLOR_EVPN_VPWS if evpn-route-type is 1 and rd in (ios-regex '.*..*..*..*:( 100 )') then set extcommunity color color-11000 endif pass end-policy
!
router bgp 65000 neighbor 1.1.1.253
address-family l2vpn evpn route-policy SET_COLOR_EVPN_VPWS out
!
!
!
/* ODN template configuration */ segment-routing traffic-eng on-demand color 10000 dynamic pcep
!
metric type igp
!
disjoint-path group-id 776 type link
!
!
!
!
Configuration: Site 2 Node D
This section depicts relevant configuration of Node D at Site 2.
/* EVPN-VPWS configuration */ interface GigabitEthernet0/0/0/1.2500 l2transport encapsulation dot1q 2500
!
rewrite ingress tag pop 1 symmetric l2vpn xconnect group evpn_vpws_group p2p evpn_vpws_101 interface GigabitEthernet0/0/0/1.2500
neighbor evpn evi 101 target 12 source 22
!
!
!
!
/* BGP color community and RPL configuration */ extcommunity-set opaque color-11000
11000 end-set
!
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
155
Configure SR-TE Policies
Configuring SR-ODN for EVPN-VPWS: Use Case route-policy SET_COLOR_EVPN_VPWS if evpn-route-type is 1 and rd in (ios-regex '.*..*..*..*:( 101 )') then set extcommunity color color-11000 endif pass end-policy
!
router bgp 65000
!
!
neighbor 1.1.1.253
address-family l2vpn evpn
!
route-policy SET_COLOR_EVPN_VPWS out
/* ODN template configuration */ segment-routing traffic-eng on-demand color 10000 dynamic pcep
!
metric type igp
!
!
!
!
!
disjoint-path group-id 776 type link
Verification: SR-PCE
Use the show pce ipv4 peer command to display the SR-PCE’s PCEP peers and session status. SR-PCE performs path computation for the 4 nodes depicted in the use-case.
RP/0/0/CPU0:SR-PCE# show pce ipv4 peer
Mon Jul 15 19:41:43.622 UTC
PCE's peer database:
--------------------
Peer address: 1.1.1.2
State: Up
Capabilities: Stateful, Segment-Routing, Update, Instantiation
Peer address: 1.1.1.4
State: Up
Capabilities: Stateful, Segment-Routing, Update, Instantiation
Peer address: 1.1.1.5
State: Up
Capabilities: Stateful, Segment-Routing, Update, Instantiation
Peer address: 1.1.1.6
State: Up
Capabilities: Stateful, Segment-Routing, Update, Instantiation
Use the show pce association group-id command to display information for the pair of LSPs assigned to a given association group-id value.
156
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure SR-TE Policies
Configuring SR-ODN for EVPN-VPWS: Use Case
Based on the goals of this use case, SR-PCE computes link-disjoint paths for the SR policies associated with a pair of ELINE services between site 1 and site 2. In particular, disjoint LSPs from site 1 to site 2 are identified by association group-id 775. The output includes high-level information for LSPs associated to this group-id:
• At Node A (1.1.1.5): LSP symbolic name = bgp_c_11000_ep_1.1.1.2_discr_100
• At Node B (1.1.1.6): LSP symbolic name = bgp_c_11000_ep_1.1.1.4_discr_100
In this case, the SR-PCE was able to achieve the desired disjointness level; therefore the Status is shown as
"Satisfied".
RP/0/0/CPU0:SR-PCE# show pce association group-id 775
Thu Jul 11 03:52:20.770 UTC
PCE's association database:
----------------------
Association: Type Link-Disjoint, Group 775 , Not Strict
Associated LSPs:
LSP[0]:
PCC 1.1.1.6, tunnel name bgp_c_11000_ep_1.1.1.4_discr_100
, PLSP ID 18, tunnel ID 17,
LSP ID 3, Configured on PCC
LSP[1]:
PCC 1.1.1.5, tunnel name bgp_c_11000_ep_1.1.1.2_discr_100
, PLSP ID 18, tunnel ID 18,
LSP ID 3, Configured on PCC
Status: Satisfied
Use the show pce lsp command to display detailed information of an LSP present in the PCE's LSP database.
This output shows details for the LSP at Node A (1.1.1.5) that is used to carry traffic of EVPN VPWS EVI
100 towards node C (1.1.1.2).
RP/0/0/CPU0:SR-PCE# show pce lsp pcc ipv4 1.1.1.5 name bgp_c_11000_ep_1.1.1.2_discr_100
Thu Jul 11 03:58:45.903 UTC
PCE's tunnel database:
----------------------
PCC 1.1.1.5:
Tunnel Name: bgp_c_11000_ep_1.1.1.2_discr_100
Color: 11000
Interface Name: srte_c_11000_ep_1.1.1.2
LSPs:
LSP[0]: source 1.1.1.5, destination 1.1.1.2, tunnel ID 18, LSP ID 3
State: Admin up, Operation up
Setup type: Segment Routing
Binding SID: 80037
Maximum SID Depth: 10
Absolute Metric Margin: 0
Relative Metric Margin: 0%
Preference: 100
Bandwidth: signaled 0 kbps, applied 0 kbps
PCEP information:
PLSP-ID 0x12, flags: D:1 S:0 R:0 A:1 O:1 C:0
LSP Role: Exclude LSP
State-sync PCE: None
PCC: 1.1.1.5
LSP is subdelegated to: None
Reported path:
Metric type: IGP, Accumulated Metric 40
SID[0]: Adj, Label 80003, Address: local 11.5.8.5 remote 11.5.8.8
SID[1]: Node, Label 16007, Address 1.1.1.7
SID[2]: Node, Label 16002, Address 1.1.1.2
Computed path: (Local PCE)
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
157
Configure SR-TE Policies
Configuring SR-ODN for EVPN-VPWS: Use Case
Computed Time: Thu Jul 11 03:49:48 UTC 2019 (00:08:58 ago)
Metric type: IGP, Accumulated Metric 40
SID[0]: Adj, Label 80003, Address: local 11.5.8.5 remote 11.5.8.8
SID[1]: Node, Label 16007, Address 1.1.1.7
SID[2]: Node, Label 16002, Address 1.1.1.2
Recorded path:
None
Disjoint Group Information :
Type Link-Disjoint, Group 775
This output shows details for the LSP at Node B (1.1.1.6) that is used to carry traffic of EVPN VPWS EVI
101 towards node D (1.1.1.4).
RP/0/0/CPU0:SR-PCE# show pce lsp pcc ipv4 1.1.1.6 name bgp_c_11000_ep_1.1.1.4_discr_100
Thu Jul 11 03:58:56.812 UTC
PCE's tunnel database:
----------------------
PCC 1.1.1.6:
Tunnel Name: bgp_c_11000_ep_1.1.1.4_discr_100
Color: 11000
Interface Name: srte_c_11000_ep_1.1.1.4
LSPs:
LSP[0]: source 1.1.1.6, destination 1.1.1.4, tunnel ID 17, LSP ID 3
State: Admin up, Operation up
Setup type: Segment Routing
Binding SID: 80061
Maximum SID Depth: 10
Absolute Metric Margin: 0
Relative Metric Margin: 0%
Preference: 100
Bandwidth: signaled 0 kbps, applied 0 kbps
PCEP information:
PLSP-ID 0x12, flags: D:1 S:0 R:0 A:1 O:1 C:0
LSP Role: Disjoint LSP
State-sync PCE: None
PCC: 1.1.1.6
LSP is subdelegated to: None
Reported path:
Metric type: IGP, Accumulated Metric 40
SID[0]: Node, Label 16001, Address 1.1.1.1
SID[1]: Node, Label 16004, Address 1.1.1.4
Computed path: (Local PCE)
Computed Time: Thu Jul 11 03:49:48 UTC 2019 (00:09:08 ago)
Metric type: IGP, Accumulated Metric 40
SID[0]: Node, Label 16001, Address 1.1.1.1
SID[1]: Node, Label 16004, Address 1.1.1.4
Recorded path:
None
Disjoint Group Information :
Type Link-Disjoint, Group 775
Based on the goals of this use case, SR-PCE computes link-disjoint paths for the SR policies associated with a pair of ELINE services between site 1 and site 2. In particular, disjoint LSPs from site 2 to site 1 are identified by association group-id 776. The output includes high-level information for LSPs associated to this group-id:
• At Node C (1.1.1.2): LSP symbolic name = bgp_c_10000_ep_1.1.1.5_discr_100
• At Node D (1.1.1.4): LSP symbolic name = bgp_c_10000_ep_1.1.1.6_discr_100
158
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure SR-TE Policies
Configuring SR-ODN for EVPN-VPWS: Use Case
In this case, the SR-PCE was able to achieve the desired disjointness level; therefore, the Status is shown as
"Satisfied".
RP/0/0/CPU0:SR-PCE# show pce association group-id 776
Thu Jul 11 03:52:24.370 UTC
PCE's association database:
----------------------
Association: Type Link-Disjoint, Group 776 , Not Strict
Associated LSPs:
LSP[0]:
PCC 1.1.1.4, tunnel name bgp_c_10000_ep_1.1.1.6_discr_100
, PLSP ID 16, tunnel ID 14,
LSP ID 1, Configured on PCC
LSP[1]:
PCC 1.1.1.2, tunnel name bgp_c_10000_ep_1.1.1.5_discr_100
, PLSP ID 6, tunnel ID 21, LSP
ID 3, Configured on PCC
Status: Satisfied
Use the show pce lsp command to display detailed information of an LSP present in the PCE's LSP database.
This output shows details for the LSP at Node C (1.1.1.2) that is used to carry traffic of EVPN VPWS EVI
100 towards node A (1.1.1.5).
RP/0/0/CPU0:SR-PCE# show pce lsp pcc ipv4 1.1.1.2 name bgp_c_10000_ep_1.1.1.5_discr_100
Thu Jul 11 03:55:21.706 UTC
PCE's tunnel database:
----------------------
PCC 1.1.1.2:
Tunnel Name: bgp_c_10000_ep_1.1.1.5_discr_100
Color: 10000
Interface Name: srte_c_10000_ep_1.1.1.5
LSPs:
LSP[0]: source 1.1.1.2, destination 1.1.1.5, tunnel ID 21, LSP ID 3
State: Admin up, Operation up
Setup type: Segment Routing
Binding SID: 80052
Maximum SID Depth: 10
Absolute Metric Margin: 0
Relative Metric Margin: 0%
Preference: 100
Bandwidth: signaled 0 kbps, applied 0 kbps
PCEP information:
PLSP-ID 0x6, flags: D:1 S:0 R:0 A:1 O:1 C:0
LSP Role: Exclude LSP
State-sync PCE: None
PCC: 1.1.1.2
LSP is subdelegated to: None
Reported path:
Metric type: IGP, Accumulated Metric 40
SID[0]: Node, Label 16007, Address 1.1.1.7
SID[1]: Node, Label 16008, Address 1.1.1.8
SID[2]: Adj, Label 80005, Address: local 11.5.8.8 remote 11.5.8.5
Computed path: (Local PCE)
Computed Time: Thu Jul 11 03:50:03 UTC 2019 (00:05:18 ago)
Metric type: IGP, Accumulated Metric 40
SID[0]: Node, Label 16007, Address 1.1.1.7
SID[1]: Node, Label 16008, Address 1.1.1.8
SID[2]: Adj, Label 80005, Address: local 11.5.8.8 remote 11.5.8.5
Recorded path:
None
Disjoint Group Information :
Type Link-Disjoint, Group 776
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
159
Configure SR-TE Policies
Configuring SR-ODN for EVPN-VPWS: Use Case
This output shows details for the LSP at Node D (1.1.1.4) used to carry traffic of EVPN VPWS EVI 101 towards node B (1.1.1.6).
RP/0/0/CPU0:SR-PCE# show pce lsp pcc ipv4 1.1.1.4 name bgp_c_10000_ep_1.1.1.6_discr_100
Thu Jul 11 03:55:23.296 UTC
PCE's tunnel database:
----------------------
PCC 1.1.1.4:
Tunnel Name: bgp_c_10000_ep_1.1.1.6_discr_100
Color: 10000
Interface Name: srte_c_10000_ep_1.1.1.6
LSPs:
LSP[0]: source 1.1.1.4, destination 1.1.1.6, tunnel ID 14, LSP ID 1
State: Admin up, Operation up
Setup type: Segment Routing
Binding SID: 80047
Maximum SID Depth: 10
Absolute Metric Margin: 0
Relative Metric Margin: 0%
Preference: 100
Bandwidth: signaled 0 kbps, applied 0 kbps
PCEP information:
PLSP-ID 0x10, flags: D:1 S:0 R:0 A:1 O:1 C:0
LSP Role: Disjoint LSP
State-sync PCE: None
PCC: 1.1.1.4
LSP is subdelegated to: None
Reported path:
Metric type: IGP, Accumulated Metric 40
SID[0]: Node, Label 16001, Address 1.1.1.1
SID[1]: Node, Label 16006, Address 1.1.1.6
Computed path: (Local PCE)
Computed Time: Thu Jul 11 03:50:03 UTC 2019 (00:05:20 ago)
Metric type: IGP, Accumulated Metric 40
SID[0]: Node, Label 16001, Address 1.1.1.1
SID[1]: Node, Label 16006, Address 1.1.1.6
Recorded path:
None
Disjoint Group Information :
Type Link-Disjoint, Group 776
Verification: Site 1 Node A
This section depicts verification steps at Node A.
Use the show bgp l2vpn evpn command to display BGP prefix information for EVPN-VPWS EVI 100 (rd
1.1.1.5:100). The output includes an EVPN route-type 1 route with color 11000 originated at Node C (1.1.1.2).
RP/0/RSP0/CPU0:Node-A# show bgp l2vpn evpn rd 1.1.1.5:100
Wed Jul 10 18:57:57.704 PST
BGP router identifier 1.1.1.5, local AS number 65000
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0x0 RD version: 0
BGP main routing table version 360
BGP NSR Initial initsync version 1 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs
Status codes: s suppressed, d damped, h history, * valid, > best
160
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure SR-TE Policies
Configuring SR-ODN for EVPN-VPWS: Use Case i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 1.1.1.5:100 (default for vrf VPWS:100)
*> [1][0000.0000.0000.0000.0000][11]/120
0.0.0.0
*>i[1][0000.0000.0000.0000.0000][21]/120
1.1.1.2 C:11000 100
0 i
0 i
The following output displays the details for the incoming EVPN RT1. Note the presence of BGP extended color community 11000, and that the prefix is associated with an SR policy with color 11000 and BSID value of 80044.
RP/0/RSP0/CPU0:Node-A# show bgp l2vpn evpn rd 1.1.1.5:100
[1][0000.0000.0000.0000.0000][21]/120
Wed Jul 10 18:57:58.107 PST
BGP routing table entry for [1][0000.0000.0000.0000.0000][21]/120, Route Distinguisher:
1.1.1.5:100
Versions:
Process bRIB/RIB SendTblVer
Speaker 360 360
Last Modified: Jul 10 18:36:18.369 for 00:21:40
Paths: (1 available, best #1)
Not advertised to any peer
Path #1: Received by speaker 0
Not advertised to any peer
Local
1.1.1.2 C:11000 (bsid:80044) (metric 40) from 1.1.1.253 (1.1.1.2)
Received Label 80056
Origin IGP, localpref 100, valid, internal, best, group-best, import-candidate, imported, rib-install
Received Path ID 0, Local Path ID 1, version 358
Extended community: Color:11000 RT:65000:100
Originator: 1.1.1.2, Cluster list: 1.1.1.253
SR policy color 11000, up, registered, bsid 80044 , if-handle 0x00001b20
Source AFI: L2VPN EVPN, Source VRF: default, Source Route Distinguisher: 1.1.1.2:100
Use the show l2vpn xconnect command to display the state associated with EVPN-VPWS EVI 100 service.
RP/0/RSP0/CPU0:Node-A# show l2vpn xconnect group evpn_vpws_group
Wed Jul 10 18:58:02.333 PST
Legend: ST = State, UP = Up, DN = Down, AD = Admin Down, UR = Unresolved,
SB = Standby, SR = Standby Ready, (PP) = Partially Programmed
XConnect
Group Name
Segment 1
ST Description ST ST
-------------------------------------------------------------------------------evpn_vpws_group evpn_vpws_100
Segment 2
Description
UP Gi0/0/0/3.2500
UP EVPN 100,21,1.1.1.2
UP
----------------------------------------------------------------------------------------
The following output shows the details for the service. Note that the service is associated with the on-demand
SR policy with color 11000 and end-point 1.1.1.2 (node C).
RP/0/RSP0/CPU0:Node-A# show l2vpn xconnect group evpn_vpws_group xc-name evpn_vpws_100 detail
Wed Jul 10 18:58:02.755 PST
Group evpn_vpws_group, XC evpn_vpws_100, state is up; Interworking none
AC: GigabitEthernet0/0/0/3.2500, state is up
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
161
Configure SR-TE Policies
Configuring SR-ODN for EVPN-VPWS: Use Case
Type VLAN; Num Ranges: 1
Rewrite Tags: []
VLAN ranges: [2500, 2500]
MTU 1500; XC ID 0x120000c; interworking none
Statistics: packets: received 0, sent 0 bytes: received 0, sent 0 drops: illegal VLAN 0, illegal length 0
EVPN: neighbor 1.1.1.2, PW ID: evi 100, ac-id 21, state is up ( established )
XC ID 0xa0000007
Encapsulation MPLS
Source address 1.1.1.5
Encap type Ethernet, control word enabled
Sequencing not set
Preferred path Active : SR TE srte_c_11000_ep_1.1.1.2, On-Demand , fallback enabled
Tunnel : Up
Load Balance Hashing: src-dst-mac
EVPN Local Remote
------------ ------------------------------ -----------------------------
Label 80040 80056
MTU 1500
Control word enabled
AC ID
EVPN type
11
Ethernet
1500 enabled
21
Ethernet
------------ ------------------------------ -----------------------------
Create time: 10/07/2019 18:31:30 (1d17h ago)
Last time status changed: 10/07/2019 19:42:00 (1d16h ago)
Last time PW went down: 10/07/2019 19:40:55 (1d16h ago)
Statistics: packets: received 0, sent 0 bytes: received 0, sent 0
Use the show segment-routing traffic-eng policy command with tabular option to display SR policy summary information.
The following output shows the on-demand SR policy with BSID 80044 that was triggered by EVPN RT1 prefix with color 11000 advertised by node C (1.1.1.2).
RP/0/RSP0/CPU0:Node-A# show segment-routing traffic-eng policy color 11000 tabular
Wed Jul 10 18:58:00.732 PST
Color Endpoint Admin Oper
State State
Binding
SID
------ -------------------- ------ ------ --------------------
11000 1.1.1.2
up up 80044
The following output shows the details for the on-demand SR policy. Note that the SR policy's active candidate path (preference 100) is computed by SR-PCE (1.1.1.207).
Based on the goals of this use case, SR-PCE computes link-disjoint paths for the SR policies associated with a pair of ELINE services between site 1 and site 2. Specifically, from site 1 to site 2, LSP at Node A
(srte_c_11000_ep_1.1.1.2) is link-disjoint from LSP at Node B (srte_c_11000_ep_1.1.1.4).
RP/0/RSP0/CPU0:Node-A# show segment-routing traffic-eng policy color 11000
Wed Jul 10 19:15:47.217 PST
SR-TE policy database
---------------------
Color: 11000, End-point: 1.1.1.2
162
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure SR-TE Policies
Configuring SR-ODN for EVPN-VPWS: Use Case
Name: srte_c_11000_ep_1.1.1.2
Status:
Admin: up Operational: up for 00:39:31 (since Jul 10 18:36:00.471)
Candidate-paths:
Preference: 200 (BGP ODN) (shutdown)
Requested BSID: dynamic
PCC info:
Symbolic name: bgp_c_11000_ep_1.1.1.2_discr_200
PLSP-ID: 19
Dynamic (invalid)
Preference: 100 (BGP ODN) (active)
Requested BSID: dynamic
PCC info:
Symbolic name: bgp_c_11000_ep_1.1.1.2_discr_100
PLSP-ID: 18
Dynamic (pce 1.1.1.207) (valid)
Metric Type: IGP, Path Accumulated Metric: 40
80003 [Adjacency-SID, 11.5.8.5 - 11.5.8.8]
16007 [Prefix-SID, 1.1.1.7]
16002 [Prefix-SID, 1.1.1.2]
Attributes:
Binding SID: 80044
Forward Class: 0
Steering BGP disabled: no
IPv6 caps enable: yes
Verification: Site 1 Node B
This section depicts verification steps at Node B.
Use the show bgp l2vpn evpn command to display BGP prefix information for EVPN-VPWS EVI 101 (rd
1.1.1.6:101). The output includes an EVPN route-type 1 route with color 11000 originated at Node D (1.1.1.4).
RP/0/RSP0/CPU0:Node-B# show bgp l2vpn evpn rd 1.1.1.6:101
Wed Jul 10 19:08:54.964 PST
BGP router identifier 1.1.1.6, local AS number 65000
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0x0 RD version: 0
BGP main routing table version 322
BGP NSR Initial initsync version 7 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs
Status codes: s suppressed, d damped, h history, * valid, > best i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 1.1.1.6:101 (default for vrf VPWS:101)
*> [1][0000.0000.0000.0000.0000][12]/120
0.0.0.0
*>i[1][0000.0000.0000.0000.0000][22]/120
1.1.1.4 C:11000 100
0 i
0 i
Processed 2 prefixes, 2 paths
The following output displays the details for the incoming EVPN RT1. Note the presence of BGP extended color community 11000, and that the prefix is associated with an SR policy with color 11000 and BSID value of 80061.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
163
Configure SR-TE Policies
Configuring SR-ODN for EVPN-VPWS: Use Case
RP/0/RSP0/CPU0:Node-B# show bgp l2vpn evpn rd 1.1.1.6:101
[1][0000.0000.0000.0000.0000][22]/120
Wed Jul 10 19:08:55.039 PST
BGP routing table entry for [1][0000.0000.0000.0000.0000][22]/120, Route Distinguisher:
1.1.1.6:101
Versions:
Process bRIB/RIB SendTblVer
Speaker 322 322
Last Modified: Jul 10 18:42:10.408 for 00:26:44
Paths: (1 available, best #1)
Not advertised to any peer
Path #1: Received by speaker 0
Not advertised to any peer
Local
1.1.1.4 C:11000 (bsid:80061) (metric 40) from 1.1.1.253 (1.1.1.4)
Received Label 80045
Origin IGP, localpref 100, valid, internal, best, group-best, import-candidate, imported, rib-install
Received Path ID 0, Local Path ID 1, version 319
Extended community: Color:11000 RT:65000:101
Originator: 1.1.1.4, Cluster list: 1.1.1.253
SR policy color 11000, up, registered, bsid 80061 , if-handle 0x00000560
Source AFI: L2VPN EVPN, Source VRF: default, Source Route Distinguisher: 1.1.1.4:101
Use the show l2vpn xconnect command to display the state associated with EVPN-VPWS EVI 101 service.
RP/0/RSP0/CPU0:Node-B# show l2vpn xconnect group evpn_vpws_group
Wed Jul 10 19:08:56.388 PST
Legend: ST = State, UP = Up, DN = Down, AD = Admin Down, UR = Unresolved,
SB = Standby, SR = Standby Ready, (PP) = Partially Programmed
XConnect
Group Name
Segment 1
ST Description ST
Segment 2
Description ST
-------------------------------------------------------------------------------evpn_vpws_group evpn_vpws_101
UP Te0/3/0/0/8.2500
UP EVPN 101,22,1.1.1.4
UP
----------------------------------------------------------------------------------------
The following output shows the details for the service. Note that the service is associated with the on-demand
SR policy with color 11000 and end-point 1.1.1.4 (node D).
RP/0/RSP0/CPU0:Node-B# show l2vpn xconnect group evpn_vpws_group xc-name evpn_vpws_101
Wed Jul 10 19:08:56.511 PST
Group evpn_vpws_group, XC evpn_vpws_101, state is up; Interworking none
AC: TenGigE0/3/0/0/8.2500, state is up
Type VLAN; Num Ranges: 1
Rewrite Tags: []
VLAN ranges: [2500, 2500]
MTU 1500; XC ID 0x2a0000e; interworking none
Statistics: packets: received 0, sent 0 bytes: received 0, sent 0 drops: illegal VLAN 0, illegal length 0
EVPN: neighbor 1.1.1.4, PW ID: evi 101, ac-id 22, state is up ( established )
XC ID 0xa0000009
Encapsulation MPLS
Source address 1.1.1.6
Encap type Ethernet, control word enabled
Sequencing not set
Preferred path Active : SR TE srte_c_11000_ep_1.1.1.4, On-Demand , fallback enabled
164
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure SR-TE Policies
Configuring SR-ODN for EVPN-VPWS: Use Case
Tunnel : Up
Load Balance Hashing: src-dst-mac
EVPN Local Remote
------------ ------------------------------ -----------------------------
Label 80060 80045
MTU 1500 1500
Control word enabled
AC ID 12
EVPN type Ethernet enabled
22
Ethernet
------------ ------------------------------ -----------------------------
Create time: 10/07/2019 18:32:49 (00:36:06 ago)
Last time status changed: 10/07/2019 18:42:07 (00:26:49 ago)
Statistics: packets: received 0, sent 0 bytes: received 0, sent 0
Use the show segment-routing traffic-eng policy command with tabular option to display SR policy summary information.
The following output shows the on-demand SR policy with BSID 80061 that was triggered by EVPN RT1 prefix with color 11000 advertised by node D (1.1.1.4).
RP/0/RSP0/CPU0:Node-B# show segment-routing traffic-eng policy color 11000 tabular
Wed Jul 10 19:08:56.146 PST
Color Endpoint Admin Oper
State State
Binding
SID
------ -------------------- ------ ------ --------------------
11000 1.1.1.4
up up 80061
The following output shows the details for the on-demand SR policy. Note that the SR policy's active candidate path (preference 100) is computed by SR-PCE (1.1.1.207).
Based on the goals of this use case, SR-PCE computes link-disjoint paths for the SR policies associated with a pair of ELINE services between site 1 and site 2. Specifically, from site 1 to site 2, LSP at Node B
(srte_c_11000_ep_1.1.1.4) is link-disjoint from LSP at Node A (srte_c_11000_ep_1.1.1.2).
RP/0/RSP0/CPU0:Node-B# show segment-routing traffic-eng policy color 11000
Wed Jul 10 19:08:56.207 PST
SR-TE policy database
---------------------
Color: 11000, End-point: 1.1.1.4
Name: srte_c_11000_ep_1.1.1.4
Status:
Admin: up Operational: up for 00:26:47 (since Jul 10 18:40:05.868)
Candidate-paths:
Preference: 200 (BGP ODN) (shutdown)
Requested BSID: dynamic
PCC info:
Symbolic name: bgp_c_11000_ep_1.1.1.4_discr_200
PLSP-ID: 19
Dynamic (invalid)
Preference: 100 (BGP ODN) (active)
Requested BSID: dynamic
PCC info:
Symbolic name: bgp_c_11000_ep_1.1.1.4_discr_100
PLSP-ID: 18
Dynamic (pce 1.1.1.207) (valid)
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
165
Configure SR-TE Policies
Configuring SR-ODN for EVPN-VPWS: Use Case
Metric Type: IGP, Path Accumulated Metric: 40
16001 [Prefix-SID, 1.1.1.1]
16004 [Prefix-SID, 1.1.1.4]
Attributes:
Binding SID: 80061
Forward Class: 0
Steering BGP disabled: no
IPv6 caps enable: yes
Verification: Site 2 Node C
This section depicts verification steps at Node C.
Use the show bgp l2vpn evpn command to display BGP prefix information for EVPN-VPWS EVI 100 (rd
1.1.1.2:100). The output includes an EVPN route-type 1 route with color 10000 originated at Node A (1.1.1.5).
RP/0/RSP0/CPU0:Node-C# show bgp l2vpn evpn rd 1.1.1.2:100
BGP router identifier 1.1.1.2, local AS number 65000
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0x0 RD version: 0
BGP main routing table version 21
BGP NSR Initial initsync version 1 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs
Status codes: s suppressed, d damped, h history, * valid, > best i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 1.1.1.2:100 (default for vrf VPWS:100)
*>i[1][0000.0000.0000.0000.0000][11]/120
1.1.1.5 C:10000 100 0 i
*> [1][0000.0000.0000.0000.0000][21]/120
0.0.0.0
0 i
The following output displays the details for the incoming EVPN RT1. Note the presence of BGP extended color community 10000, and that the prefix is associated with an SR policy with color 10000 and BSID value of 80058.
RP/0/RSP0/CPU0:Node-C# show bgp l2vpn evpn rd 1.1.1.2:100
[1][0000.0000.0000.0000.0000][11]/120
BGP routing table entry for [1][0000.0000.0000.0000.0000][11]/120, Route Distinguisher:
1.1.1.2:100
Versions:
Process
Speaker bRIB/RIB
20
SendTblVer
20
Last Modified: Jul 10 18:36:20.503 for 00:45:21
Paths: (1 available, best #1)
Not advertised to any peer
Path #1: Received by speaker 0
Not advertised to any peer
Local
1.1.1.5 C:10000 (bsid:80058) (metric 40) from 1.1.1.253 (1.1.1.5)
Received Label 80040
Origin IGP, localpref 100, valid, internal, best, group-best, import-candidate, imported, rib-install
Received Path ID 0, Local Path ID 1, version 18
Extended community: Color:10000 RT:65000:100
Originator: 1.1.1.5, Cluster list: 1.1.1.253
SR policy color 10000, up, registered, bsid 80058 , if-handle 0x000006a0
166
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure SR-TE Policies
Configuring SR-ODN for EVPN-VPWS: Use Case
Source AFI: L2VPN EVPN, Source VRF: default, Source Route Distinguisher: 1.1.1.5:100
Use the show l2vpn xconnect command to display the state associated with EVPN-VPWS EVI 100 service.
RP/0/RSP0/CPU0:Node-C# show l2vpn xconnect group evpn_vpws_group
Legend: ST = State, UP = Up, DN = Down, AD = Admin Down, UR = Unresolved,
SB = Standby, SR = Standby Ready, (PP) = Partially Programmed
XConnect Segment 1 Segment 2
Group Name ST Description ST Description ST
-------------------------------------------------------------------------------evpn_vpws_group evpn_vpws_100
UP Gi0/0/0/3.2500
UP EVPN 100,11,1.1.1.5
UP
----------------------------------------------------------------------------------------
The following output shows the details for the service. Note that the service is associated with the on-demand
SR policy with color 10000 and end-point 1.1.1.5 (node A).
RP/0/RSP0/CPU0:Node-C# show l2vpn xconnect group evpn_vpws_group xc-name evpn_vpws_100
Group evpn_vpws_group, XC evpn_vpws_100, state is up; Interworking none
AC: GigabitEthernet0/0/0/3.2500, state is up
Type VLAN; Num Ranges: 1
Rewrite Tags: []
VLAN ranges: [2500, 2500]
MTU 1500; XC ID 0x1200008; interworking none
Statistics: packets: received 0, sent 0 bytes: received 0, sent 0 drops: illegal VLAN 0, illegal length 0
EVPN: neighbor 1.1.1.5, PW ID: evi 100, ac-id 11, state is up ( established )
XC ID 0xa0000003
Encapsulation MPLS
Source address 1.1.1.2
Encap type Ethernet, control word enabled
Sequencing not set
Preferred path Active : SR TE srte_c_10000_ep_1.1.1.5, On-Demand , fallback enabled
Tunnel : Up
Load Balance Hashing: src-dst-mac
EVPN Local Remote
------------ ------------------------------ -----------------------------
Label 80056 80040
MTU 1500 1500
Control word enabled
AC ID 21
EVPN type Ethernet enabled
11
Ethernet
------------ ------------------------------ -----------------------------
Create time: 10/07/2019 18:36:16 (1d19h ago)
Last time status changed: 10/07/2019 19:41:59 (1d18h ago)
Last time PW went down: 10/07/2019 19:40:54 (1d18h ago)
Statistics: packets: received 0, sent 0 bytes: received 0, sent 0
Use the show segment-routing traffic-eng policy command with tabular option to display SR policy summary information.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
167
Configure SR-TE Policies
Configuring SR-ODN for EVPN-VPWS: Use Case
The following output shows the on-demand SR policy with BSID 80058 that was triggered by EVPN RT1 prefix with color 10000 advertised by node A (1.1.1.5).
RP/0/RSP0/CPU0:Node-C# show segment-routing traffic-eng policy color 10000 tabular
Color Endpoint Admin Oper Binding
State State SID
------ -------------------- ------ ------ --------------------
10000 1.1.1.5
up up 80058
The following output shows the details for the on-demand SR policy. Note that the SR policy's active candidate path (preference 100) is computed by SR-PCE (1.1.1.207).
Based on the goals of this use case, SR-PCE computes link-disjoint paths for the SR policies associated with a pair of ELINE services between site 1 and site 2. Specifically, from site 2 to site 1, LSP at Node C
(srte_c_10000_ep_1.1.1.5) is link-disjoint from LSP at Node D (srte_c_10000_ep_1.1.1.6).
RP/0/RSP0/CPU0:Node-C# show segment-routing traffic-eng policy color 10000
SR-TE policy database
---------------------
Color: 10000, End-point: 1.1.1.5
Name: srte_c_10000_ep_1.1.1.5
Status:
Admin: up Operational: up for 00:12:35 (since Jul 10 19:49:21.890)
Candidate-paths:
Preference: 200 (BGP ODN) (shutdown)
Requested BSID: dynamic
PCC info:
Symbolic name: bgp_c_10000_ep_1.1.1.5_discr_200
PLSP-ID: 7
Dynamic (invalid)
Preference: 100 (BGP ODN) (active)
Requested BSID: dynamic
PCC info:
Symbolic name: bgp_c_10000_ep_1.1.1.5_discr_100
PLSP-ID: 6
Dynamic (pce 1.1.1.207) (valid)
Metric Type: IGP, Path Accumulated Metric: 40
16007 [Prefix-SID, 1.1.1.7]
16008 [Prefix-SID, 1.1.1.8]
80005 [Adjacency-SID, 11.5.8.8 - 11.5.8.5]
Attributes:
Binding SID: 80058
Forward Class: 0
Steering BGP disabled: no
IPv6 caps enable: yes
Verification: Site 2 Node D
This section depicts verification steps at Node D.
Use the show bgp l2vpn evpn command to display BGP prefix information for EVPN-VPWS EVI 101 (rd
1.1.1.4:101). The output includes an EVPN route-type 1 route with color 10000 originated at Node B (1.1.1.6).
RP/0/RSP0/CPU0:Node-D# show bgp l2vpn evpn rd 1.1.1.4:101
BGP router identifier 1.1.1.4, local AS number 65000
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0x0 RD version: 0
168
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure SR-TE Policies
Configuring SR-ODN for EVPN-VPWS: Use Case
BGP main routing table version 570
BGP NSR Initial initsync version 1 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs
Status codes: s suppressed, d damped, h history, * valid, > best i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 1.1.1.4:101 (default for vrf VPWS:101)
*>i[1][0000.0000.0000.0000.0000][12]/120
1.1.1.6 C:10000 100
*> [1][0000.0000.0000.0000.0000][22]/120
0.0.0.0
0 i
0 i
Processed 2 prefixes, 2 paths
The following output displays the details for the incoming EVPN RT1. Note the presence of BGP extended color community 10000, and that the prefix is associated with an SR policy with color 10000 and BSID value of 80047.
RP/0/RSP0/CPU0:Node-D# show bgp l2vpn evpn rd 1.1.1.4:101
[1][0000.0000.0000.0000.0000][12]/120
BGP routing table entry for [1][0000.0000.0000.0000.0000][12]/120, Route Distinguisher:
1.1.1.4:101
Versions:
Process
Speaker bRIB/RIB SendTblVer
569 569
Last Modified: Jul 10 18:42:12.455 for 00:45:38
Paths: (1 available, best #1)
Not advertised to any peer
Path #1: Received by speaker 0
Not advertised to any peer
Local
1.1.1.6 C:10000 (bsid:80047) (metric 40) from 1.1.1.253 (1.1.1.6)
Received Label 80060
Origin IGP, localpref 100, valid, internal, best, group-best, import-candidate, imported, rib-install
Received Path ID 0, Local Path ID 1, version 568
Extended community: Color:10000 RT:65000:101
Originator: 1.1.1.6, Cluster list: 1.1.1.253
SR policy color 10000, up, registered, bsid 80047 , if-handle 0x00001720
Source AFI: L2VPN EVPN, Source VRF: default, Source Route Distinguisher: 1.1.1.6:101
Use the show l2vpn xconnect command to display the state associated with EVPN-VPWS EVI 101 service.
RP/0/RSP0/CPU0:Node-D# show l2vpn xconnect group evpn_vpws_group
Legend: ST = State, UP = Up, DN = Down, AD = Admin Down, UR = Unresolved,
SB = Standby, SR = Standby Ready, (PP) = Partially Programmed
XConnect
Group Name
Segment 1
ST Description ST
Segment 2
Description ST
-------------------------------------------------------------------------------evpn_vpws_group evpn_vpws_101
UP Gi0/0/0/1.2500
UP EVPN 101,12,1.1.1.6
UP
----------------------------------------------------------------------------------------
The following output shows the details for the service. Note that the service is associated with the on-demand
SR policy with color 10000 and end-point 1.1.1.6 (node B).
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
169
Configure SR-TE Policies
Configuring SR-ODN for EVPN-VPWS: Use Case
RP/0/RSP0/CPU0:Node-D# show l2vpn xconnect group evpn_vpws_group xc-name evpn_vpws_101
Group evpn_vpws_group, XC evpn_vpws_101, state is up; Interworking none
AC: GigabitEthernet0/0/0/1.2500, state is up
Type VLAN; Num Ranges: 1
Rewrite Tags: []
VLAN ranges: [2500, 2500]
MTU 1500; XC ID 0x120000c; interworking none
Statistics: packets: received 0, sent 0 bytes: received 0, sent 0 drops: illegal VLAN 0, illegal length 0
EVPN: neighbor 1.1.1.6, PW ID: evi 101, ac-id 12, state is up ( established )
XC ID 0xa000000d
Encapsulation MPLS
Source address 1.1.1.4
Encap type Ethernet, control word enabled
Sequencing not set
Preferred path Active : SR TE srte_c_10000_ep_1.1.1.6, On-Demand , fallback enabled
Tunnel : Up
Load Balance Hashing: src-dst-mac
EVPN Local Remote
------------ ------------------------------ -----------------------------
Label
MTU
80045
1500
Control word enabled
AC ID
EVPN type
22
Ethernet
80060
1500 enabled
12
Ethernet
------------ ------------------------------ -----------------------------
Create time: 10/07/2019 18:42:07 (00:45:49 ago)
Last time status changed: 10/07/2019 18:42:09 (00:45:47 ago)
Statistics: packets: received 0, sent 0 bytes: received 0, sent 0
Use the show segment-routing traffic-eng policy command with tabular option to display SR policy summary information.
The following output shows the on-demand SR policy with BSID 80047 that was triggered by EVPN RT1 prefix with color 10000 advertised by node B (1.1.1.6).
RP/0/RSP0/CPU0:Node-D# show segment-routing traffic-eng policy color 10000 tabular
Color Endpoint Admin Oper Binding
State State SID
------ -------------------- ------ ------ --------------------
10000 1.1.1.6
up up 80047
The following output shows the details for the on-demand SR policy. Note that the SR policy's active candidate path (preference 100) is computed by SR-PCE (1.1.1.207).
Based on the goals of this use case, SR-PCE computes link-disjoint paths for the SR policies associated with a pair of ELINE services between site 1 and site 2. Specifically, from site 2 to site 1, LSP at Node D
(srte_c_10000_ep_1.1.1.6) is link-disjoint from LSP at Node C (srte_c_10000_ep_1.1.1.5).
RP/0/RSP0/CPU0:Node-D# show segment-routing traffic-eng policy color 10000
SR-TE policy database
---------------------
170
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure SR-TE Policies
Manually Provisioned SR Policy
Color: 10000, End-point: 1.1.1.6
Name: srte_c_10000_ep_1.1.1.6
Status:
Admin: up Operational: up for 01:23:04 (since Jul 10 18:42:07.350)
Candidate-paths:
Preference: 200 (BGP ODN) (shutdown)
Requested BSID: dynamic
PCC info:
Symbolic name: bgp_c_10000_ep_1.1.1.6_discr_200
PLSP-ID: 17
Dynamic (invalid)
Preference: 100 (BGP ODN) (active)
Requested BSID: dynamic
PCC info:
Symbolic name: bgp_c_10000_ep_1.1.1.6_discr_100
PLSP-ID: 16
Dynamic (pce 1.1.1.207) (valid)
Metric Type: IGP, Path Accumulated Metric: 40
16001 [Prefix-SID, 1.1.1.1]
16006 [Prefix-SID, 1.1.1.6]
Attributes:
Binding SID: 80047
Forward Class: 0
Steering BGP disabled: no
IPv6 caps enable: yes
Manually Provisioned SR Policy
Manually provisioned SR policies are configured on the head-end router. These policies can use dynamic paths or explicit paths. See the
SR-TE Policy Path Types, on page 175
section for information on manually provisioning an SR policy using dynamic or explicit paths.
PCE-Initiated SR Policy
An SR-TE policy can be configured on the path computation element (PCE) to reduce link congestion or to minimize the number of network touch points.
The PCE collects network information, such as traffic demand and link utilization. When the PCE determines that a link is congested, it identifies one or more flows that are causing the congestion. The PCE finds a suitable path and deploys an SR-TE policy to divert those flows, without moving the congestion to another part of the network. When there is no more link congestion, the policy is removed.
To minimize the number of network touch points, an application, such as a Network Services Orchestrator
(NSO), can request the PCE to create an SR-TE policy. PCE deploys the SR-TE policy using PCC-PCE communication protocol (PCEP).
For more information, see the
PCE-Initiated SR Policies, on page 264
section.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
171
Configure SR-TE Policies
Cumulative Metric Bounds (Delay-Bound Use-Case)
Cumulative Metric Bounds (Delay-Bound Use-Case)
Table 14: Feature History Table
Feature Name Release
Information
Feature Description
Cumulative Metric
Bounds (Delay-Bound use-case)
Release
7.3.1
With this feature, SRTE calculates a shortest path that satisfies multiple metric bounds.
This feature provides flexibility for finding paths within metric bounds, for parameters such as latency, hop count, IGP and TE.
SRTE can calculate a shortest path with cumulative metric bounds. For example, consider these metric bounds:
• IGP metric <= 10
• TE metric <= 60
• Hop count <= 4
• Latency <= 55
When an SR policy is configured on a head-end node with these metric bounds, a path is finalized towards the specified destination only if it meets each of these criteria.
You can set the maximum number of attempts for computing a shortest path that satisfies the cumulative metric bounds criteria, by using the kshortest-paths command in SR-TE configuration mode.
Restrictions
• PCE-based cumulative metric bounds computations are not supported. You must use non-PCE (SR-TE topology) based configuration for path calculation, for cumulative bounds.
• If you use PCE dynamic computation configuration with cumulative bounds, the PCE computes a path and validates against cumulative bounds. If it is valid, then the policy is created with this path on PCC.
If the initial path doesn't respect the bounds, then the path is not considered, and no further K-shortest path algorithm is executed to find the path.
Configuring SRTE Shortest Path Calculation For Cumulative Metric Bounds
You can enable this feature for SR, and ODN SR policy configurations, as shown below.
SR Policy
SR Policy - A policy called fromAtoB_XTC is created towards destination IP address 192.168.0.2. Also, the candidate-paths preference, and other attributes are enabled.
Router# configure terminal
Router(config)# segment-routing traffic-eng policy fromAtoB_XTC
Router(config-sr-te-policy)# color 2 end-point ipv4 192.168.0.2
Router(config-sr-te-policy)# candidate-paths preference 100
Router(config-sr-te-policy-path-pref)# dynamic metric type te
Cumulative Metric bounds – IGP, TE, hop count, and latency metric bounds are set. SRTE calculates paths only when each criterion is satisfied.
172
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure SR-TE Policies
Cumulative Metric Bounds (Delay-Bound Use-Case)
Router(config-sr-te-policy-path-pref)# constraints bounds cumulative
Router(config-sr-te-pref-const-bounds-type)# type igp 10
Router(config-sr-te-pref-const-bounds-type)# type te 60
Router(config-sr-te-pref-const-bounds-type)# type hopcount 4
Router(config-sr-te-pref-const-bounds-type)# type latency 55
Router(config-sr-te-pref-const-bounds-type)# commit
ODN SR Policy
SR ODN Policy – An SR ODN policy with color 1000 is created. Also, the candidate-paths value is on-demand.
Router# configure terminal
Router(config)# segment-routing traffic-eng
Router(config-sr-te)# on-demand color 1000 dynamic metric type te
Router(config-sr-te)# candidate-paths on-demand
Router(config-sr-te-candidate-path-type)# exit
Router(config-sr-te-candidate-path)# exit
Cumulative Metric bounds – IGP, TE, hop count, and latency metric bounds are set for the policy. SRTE calculates paths, only when each criterion is satisfied.
Router(config-sr-te)# on-demand color 1000 dynamic bounds cumulative
Router(config-sr-te-odc-bounds-type)# type igp 100
Router(config-sr-te-odc-bounds-type)# type te 60
Router(config-sr-te-odc-bounds-type)# type hopcount 6
Router(config-sr-te-odc-bounds-type)# type latency 1000
Router(config-sr-te-odc-bounds-type)# commit
To set the maximum number of attempts for computing paths that satisfy the cumulative metric bounds criteria, use the kshortest-paths command.
Router# configure terminal
Router(config)# segment-routing traffic-eng
Router(config-sr-te)# kshortest-paths 120
Router(config-sr-te)# commit
Verification
Use this command to view SR policy configuration details. Pointers:
• The Number of K-shortest-paths field displays 4. It means that the K-shortest path algorithm took 4 computations to find the right path. The 4 shortest paths that are computed using K-shortest path algorithm did not respect the cumulative bounds. The fifth shortest path is valid against the bounds.
• The values for the metrics of the actual path ( TE , IGP , Cumulative Latency and Hop count values in the Dynamic section) are within the configured cumulative metric bounds.
Router# show segment-routing traffic-eng policy color 2
Color: 2, End-point: 192.168.0.2
Name: srte_c_2_ep_192.168.0.2
Status:
Admin: up Operational: up for 3d02h (since Dec 15 12:13:21.993)
Candidate-paths:
Preference: 100 (configuration) (active)
Name: fromAtoB_XTC
Requested BSID: dynamic
Constraints:
Protection Type: protected-preferred
Affinity:
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
173
Configure SR-TE Policies
SR-TE BGP Soft Next-Hop Validation For ODN Policies exclude-any: red
Maximum SID Depth: 10
IGP Metric Bound: 10
TE Metric Bound: 60
Latency Metric Bound: 55
Hopcount Metric Bound: 4
Dynamic (valid)
Metric Type: TE, Path Accumulated Metric: 52
Number of K-shortest-paths: 4
TE Cumulative Metric: 52
IGP Cumulative Metric: 3
Cumulative Latency: 52
Hop count: 3
16004 [Prefix-SID, 192.168.0.4]
24003 [Adjacency-SID, 16.16.16.2 - 16.16.16.5]
24001 [Adjacency-SID, 14.14.14.5 - 14.14.14.4]
Attributes:
Binding SID: 24011
Forward Class: Not Configured
Steering labeled-services disabled: no
Steering BGP disabled: no
IPv6 caps enable: yes
Invalidation drop enabled: no
SR-TE BGP Soft Next-Hop Validation For ODN Policies
Table 15: Feature History Table
Feature Name
SR-TE BGP Soft Next-Hop
Validation For ODN Policies
Release Information
Release 7.3.2
Feature Description
This feature addresses BGP
Next-Hop reachability issues through BGP Next-Hop soft validation, and also enhances BGP best path selection.
New commands:
• nexthop validation color-extcomm disable
• nexthop validation color-extcomm sr-policy
• bgp bestpath igp-metric sr-policy
174
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure SR-TE Policies
SR-TE Policy Path Types
SR-TE Policy Path Types
A dynamic path is based on an optimization objective and a set of constraints. The head-end computes a solution, resulting in a SID-list or a set of SID-lists. When the topology changes, a new path is computed. If the head-end does not have enough information about the topology, the head-end might delegate the computation to a Segment Routing Path Computation Element (SR-PCE). For information on configuring SR-PCE, see
Configure Segment Routing Path Computation Element chapter.
An explicit path is a specified SID-list or set of SID-lists.
An SR-TE policy initiates a single (selected) path in RIB/FIB. This is the preferred valid candidate path.
A candidate path has the following characteristics:
• It has a preference – If two policies have same {color, endpoint} but different preferences, the policy with the highest preference is selected.
• It is associated with a single binding SID (BSID) – A BSID conflict occurs when there are different SR policies with the same BSID. In this case, the policy that is installed first gets the BSID and is selected.
• It is valid if it is usable.
A path is selected when the path is valid and its preference is the best among all candidate paths for that policy.
Note The protocol of the source is not relevant in the path selection logic.
Dynamic Paths
Behaviors and Limitations
For a dynamic path that traverses a specific interface between nodes (segment), the algorithm may encode this segment using an Adj-SID. The SR-TE process prefers the protected Adj-SID of the link, if one is available.
In addition, the SR-TE process prefers a manual protected Adj-SID over a dynamic protected Adj-SID.
You can configure the path to prefer the protected or unprotected Adj-SID, or to use only protected or unprotected Adj-SID. See
Segment Protection-Type Constraint, on page 178 .
Optimization Objectives
Optimization objectives allow the head-end router to compute a SID-list that expresses the shortest dynamic path according to the selected metric type:
• IGP metric — Refer to the "Implementing IS-IS" and "Implementing OSPF" chapters in the Routing
Configuration Guide for Series Routers .
• TE metric — See the
Configure Interface TE Metrics, on page 176
section for information about configuring
TE metrics.
This example shows a dynamic path from head-end router 1 to end-point router 3 that minimizes IGP or TE metric:
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
175
Configure SR-TE Policies
Configure Interface TE Metrics
• The blue path uses the minimum IGP metric: Min-Metric (1
→
3, IGP) = SID-list <16003>; cumulative
IGP metric: 20
• The green path uses the minimum TE metric: Min-Metric (1 → 3, TE) = SID-list <16005, 16004, 16003>; cumulative TE metric: 23
Configure Interface TE Metrics
Use the metric value command in SR-TE interface submode to configure the TE metric for interfaces. The value range is from 0 to 2147483647.
Router# configure
Router(config)# segment-routing
Router(config-sr)# traffic-eng
Router(config-sr-te)# interface type interface-path-id
Router(config-sr-te-if)# metric value
Configuring TE Metric: Example
The following configuration example shows how to set the TE metric for various interfaces: segment-routing traffic-eng interface TenGigE0/0/0/0
!
metric 100
!
!
end interface TenGigE0/0/0/1 metric 1000
!
interface TenGigE0/0/2/0 metric 50
Constraints
Constraints allow the head-end router to compute a dynamic path according to the selected metric type:
• Affinity — You can apply a color or name to links or interfaces by assigning affinity bit-maps to them.
You can then specify an affinity (or relationship) between an SR policy path and link colors. SR-TE computes a path that includes or excludes links that have specific colors,or combinations of colors. See
176
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure SR-TE Policies
Named Interface Link Admin Groups and SR-TE Affinity Maps the
Named Interface Link Admin Groups and SR-TE Affinity Maps, on page 177
section for information on named interface link admin groups and SR-TE Affinity Maps.
• Disjoint — SR-TE computes a path that is disjoint from another path in the same disjoint-group. Disjoint paths do not share network resources. Path disjointness may be required for paths between the same pair of nodes, between different pairs of nodes, or a combination (only same head-end or only same end-point).
• Flexible Algorithm — Flexible Algorithm allows for user-defined algorithms where the IGP computes paths based on a user-defined combination of metric type and constraint.
• Protection type — For a dynamic path that traverses a specific interface between nodes (segment), or for an explicit path using IP addresses of intermediate links, the algorithm may encode this segment using an Adj-SID. You can specify the path to prefer protected or unprotected Adj-SIDs, or to use only protected or unprotected Adj-SIDs. See
Segment Protection-Type Constraint, on page 178
for information about configuring the protection type.
Named Interface Link Admin Groups and SR-TE Affinity Maps
Named Interface Link Admin Groups and SR-TE Affinity Maps provide a simplified and more flexible means of configuring link attributes and path affinities to compute paths for SR-TE policies.
In the traditional TE scheme, links are configured with attribute-flags that are flooded with TE link-state parameters using Interior Gateway Protocols (IGPs), such as Open Shortest Path First (OSPF).
Named Interface Link Admin Groups and SR-TE Affinity Maps let you assign, or map, up to 256 color names for affinity and attribute-flag attributes instead of 32-bit hexadecimal numbers. After mappings are defined, the attributes can be referred to by the corresponding color name in the CLI. Furthermore, you can define constraints using include-any , include-all , and exclude-any arguments, where each statement can contain up to 10 colors.
Note You can configure affinity constraints using attribute flags or the Flexible Name Based Policy Constraints scheme; however, when configurations for both schemes exist, only the configuration pertaining to the new scheme is applied.
Configure Named Interface Link Admin Groups and SR-TE Affinity Maps
Use the affinity name NAME command in SR-TE interface submode to assign affinity to interfaces. Configure this on routers with interfaces that have an associated admin group attribute.
Router# configure
Router(config)# segment-routing
Router(config-sr)# traffic-eng
Router(config-sr-te)# interface TenGigE0/0/1/2
Router(config-sr-if)# affinity
Router(config-sr-if-affinity)# name RED
Use the affinity-map name NAME bit-position bit-position command in SR-TE sub-mode to define affinity maps. The bit-position range is from 0 to 255.
Configure affinity maps on the following routers:
• Routers with interfaces that have an associated admin group attribute.
• Routers that act as SR-TE head-ends for SR policies that include affinity constraints.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
177
Configure SR-TE Policies
Segment Protection-Type Constraint
Router# configure
Router(config)# segment-routing
Router(config-sr)# traffic-eng
Router(config-sr-te)# affinity-map
Router(config-sr-te-affinity-map)# name RED bit-position 23
Configuring Link Admin Group: Example
The following example shows how to assign affinity to interfaces and to define affinity maps. This configuration is applicable to any router (SR-TE head-end or transit node) with colored interfaces.
segment-routing traffic-eng interface TenGigE0/0/1/1
!
!
affinity name CROSS name RED interface TenGigE0/0/1/2 affinity name RED
!
!
interface TenGigE0/0/2/0 affinity name BLUE
!
!
affinity-map name RED bit-position 23 name BLUE bit-position 24
!
name CROSS bit-position 25 end
Segment Protection-Type Constraint
Table 16: Feature History Table
Feature Name
Segment Protection-Type
Constraint
Release Information
Release 7.4.1
Feature Description
This feature introduces the ability to control whether protected or unprotected segments are used when encoding the SID-list of an
SR policy candidate path.
The types of segments that could be used when building a SID-list include prefix SIDs and adjacency
SIDs.
This feature introduces the ability to control whether protected or unprotected segments are used when encoding the SID-list of an SR policy candidate path. The types of segments that could be used when building a SID-list include prefix SIDs and adjacency SIDs.
178
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure SR-TE Policies
Segment Protection-Type Constraint
A prefix SID is a global segment representing a prefix that identifies a specific node. A prefix SID is programmed with a backup path computed by the IGP using TI-LFA.
An adjacency SID is a local segment representing an IGP adjacency. An adjacency SID can be programmed with or without protection. Protected adjacency SIDs are programmed with a link-protectant backup path computed by the IGP (TI-LFA) and are used if the link associated with the IGP adjacency fails.
Prefix SIDs and adjacency SIDs can be leveraged as segments in a SID-list in order to forward a packet along a path traversing specific nodes and/or over specific interfaces between nodes. The type of segment used when encoding the SID-list will determine whether failures along the path would be protected by TI-LFA. Depending on the offering, an operator may want to offer either unprotected or protected services over traffic engineered paths.
The following behaviors are available with the segment protection-type constraint:
• protected-only — The SID-list must be encoded using protected segments.
• protected-preferred — The SID-list should be encoded using protected segments if available; otherwise, the SID-list may be encoded using unprotected Adj-SIDs. This is the default behavior when no segment protection-type constraint is specified.
• unprotected-only — The SID-list must be encoded using unprotected Adj-SID.
• unprotected-preferred — The SID-list should be encoded using unprotected Adj-SID if available, otherwise SID-list may be encoded using protected segments.
Usage Guidelines and Limitations
Observe the following guidelines and limitations for the platform:
• This constraint applies to candidate-paths of manual SR policies with either dynamically computed paths or explicit paths.
• This constraint applies to On-Demand SR policy candidate-paths.
• PCEP has been augmented (vendor-specific object) to allow a PCC to indicate the segment protection-type constraint to the PCE.
• When the segment protection type constraint is protected-only or unprotected-only, the path computation must adhere to the constraint. If the constraint is not satisfied, the SR policy will not come up on such candidate path.
• When the segment protection-type constraint is unprotected-only, the entire SID-list must be encoded with unprotected Adj-SIDs.
• When the segment protection-type constraint is protected-only, the entire SID-list must be encoded with protected Adj-SIDs or Prefix SIDs.
Configuring Segment Protection-Type Constraint
Use the constraints segments protection { protected-only | protected-preferred | unprotected-only | unprotected-preferred } command to configure the segment protection-type behavior.
The following example shows how to configure the policy with a SID-list that must be encoded using protected segments:
Router(config-sr-te)# policy POLICY1
Router(config-sr-te-policy)# color 10 end-point ipv4 1.1.1.4
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
179
Configure SR-TE Policies
Configure SR Policy with Dynamic Path
Router(config-sr-te-policy)# candidate-paths
Router(config-sr-te-policy-path)# preference 100
Router(config-sr-te-policy-path-pref)# constraints
Router(config-sr-te-path-pref-const)# segments
Router(config-sr-te-path-pref-const-seg)# protection protected-only
Configure SR Policy with Dynamic Path
To configure a SR-TE policy with a dynamic path, optimization objectives, and affinity constraints, complete the following configurations:
1.
Define the optimization objectives. See the
Optimization Objectives, on page 175
section.
2.
Define the constraints. See the
section.
3.
Create the policy.
Behaviors and Limitations
You can configure the path to prefer protected or unprotected segments, or to use only protected or unprotected segments.
Examples
The following example shows a configuration of an SR policy at an SR-TE head-end router. The policy has a dynamic path with optimization objectives and affinity constraints computed by the head-end router.
segment-routing traffic-eng policy foo color 100 end-point ipv4 1.1.1.2
candidate-paths preference 100 dynamic metric type te
!
!
constraints affinity exclude-any
!
!
!
!
!
!
name RED
The following example shows a configuration of an SR policy at an SR-TE head-end router. The policy has a dynamic path with optimization objectives and affinity constraints computed by the SR-PCE.
segment-routing traffic-eng policy baa color 101 end-point ipv4 1.1.1.2
candidate-paths preference 100 dynamic pcep
!
180
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure SR-TE Policies
Configure SR Policy with Dynamic Path
!
!
!
!
!
!
metric type te
!
!
constraints affinity exclude-any name BLUE
The following example shows a configuration of an SR policy at an SR-TE head-end router. The policy has a dynamic path with optimization objective and segment protection-type constraint computed by the head-end router.
segment-routing traffic-eng policy baa color 101 end-point ipv4 1.1.1.2
candidate-paths preference 100 dynamic metric type te
!
!
constraints
!
!
segments protection protected-only
!
!
!
!
The following example shows a configuration of an SR policy at an SR-TE head-end router. The policy has a dynamic path with optimization objective and segment protection-type constraint computed by the SR-PCE.
segment-routing traffic-eng policy baa color 101 end-point ipv4 1.1.1.2
candidate-paths preference 100 dynamic pcep
!
metric
!
type te
!
constraints segments protection protected-only
!
!
!
!
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
181
Configure SR-TE Policies
Explicit Paths
!
!
Explicit Paths
Configure SR-TE Policy with Explicit Path
To configure an SR-TE policy with an explicit path, complete the following configurations:
1.
Create the segment lists.
2.
Create the SR-TE policy.
Behaviors and Limitations
A segment list can use IP addresses or MPLS labels, or a combination of both.
• The IP address can be link or a Loopback address.
• Once you enter an MPLS label, you cannot enter an IP address.
You can configure the path to prefer the protected or unprotected Adj-SID, or to use only protected or unprotected Adj-SID. See
Segment Protection-Type Constraint, on page 178 .
Configure Local SR-TE Policy Using Explicit Paths
Create a segment list with IP addresses:
Router# configure
Router(config)# segment-routing
Router(config-sr)# traffic-eng
Router(config-sr-te)# segment-list name SIDLIST1
Router(config-sr-te-sl)# index 10 mpls adjacency 1.1.1.2
Router(config-sr-te-sl)# index 20 mpls adjacency 1.1.1.3
Router(config-sr-te-sl)# index 30 mpls adjacency 1.1.1.4
Router(config-sr-te-sl)# exit
Create a segment list with MPLS labels:
Router(config-sr-te)# segment-list name SIDLIST2
Router(config-sr-te-sl)# index 10 mpls label 16002
Router(config-sr-te-sl)# index 20 mpls label 16003
Router(config-sr-te-sl)# index 30 mpls label 16004
Router(config-sr-te-sl)# exit
Create a segment list with invalid MPLS label:
Router(config-sr-te)# segment-list name SIDLIST4
Router(config-sr-te-sl)# index 10 mpls label 16009
Router(config-sr-te-sl)# index 20 mpls label 16003
Router(config-sr-te-sl)# index 30 mpls label 16004
Router(config-sr-te-sl)# exit
Create a segment list with IP addresses and MPLS labels:
Router(config-sr-te)# segment-list name SIDLIST3
Router(config-sr-te-sl)# index 10 mpls adjacency 1.1.1.2
Router(config-sr-te-sl)# index 20 mpls label 16003
182
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure SR-TE Policies
Configure SR-TE Policy with Explicit Path
Router(config-sr-te-sl)# index 30 mpls label 16004
Router(config-sr-te-sl)# exit
Create the SR-TE policy:
Router(config-sr-te)# policy POLICY2
Router(config-sr-te-policy)# color 20 end-point ipv4 1.1.1.4
Router(config-sr-te-policy)# candidate-paths
Router(config-sr-te-policy-path)# preference 100
Router(config-sr-te-policy-path-pref)# explicit segment-list SIDLIST2
Router(config-sr-te-pp-info)# exit
Router(config-sr-te-policy-path-pref)# exit
Router(config-sr-te-policy-path)# preference 200
Router(config-sr-te-policy-path-pref)# explicit segment-list SIDLIST1
Router(config-sr-te-pp-info)# exit
Router(config-sr-te-policy-path-pref)# explicit segment-list SIDLIST4
Router(config-sr-te-pp-info)# exit
Router(config-sr-te-policy-path-pref)# exit
Running Configuration
Router# show running-configuration segment-routing traffic-eng segment-list SIDLIST1 index 10 address ipv4 1.1.1.2
index 20 address ipv4 1.1.1.3
index 30 address ipv4 1.1.1.4
!
segment-list SIDLIST2 index 10 mpls label 16002 index 20 mpls label 16003 index 30 mpls label 16004
!
segment-list SIDLIST3 index 10 address ipv4 1.1.1.2
index 20 mpls label 16003 index 30 mpls label 16004
!
segment-list SIDLIST4 index 10 mpls label 16009 index 20 mpls label 16003 index 30 mpls label 16004
!
policy POLICY1 color 10 end-point ipv4 1.1.1.4
candidate-paths
!
!
preference 100 explicit segment-list SIDLIST1
!
!
policy POLICY2 color 20 end-point ipv4 1.1.1.4
candidate-paths preference 100
!
explicit segment-list SIDLIST1
!
preference 200 explicit segment-list SIDLIST2
!
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
183
Configure SR-TE Policies
Configuring Explicit Path with Affinity Constraint Validation
!
!
!
!
explicit segment-list SIDLIST4
!
!
policy POLICY3 color 30 end-point ipv4 1.1.1.4
candidate-paths preference 100
!
!
!
explicit segment-list SIDLIST3
!
Verification
Verify the SR-TE policy configuration using:
Router# show segment-routing traffic-eng policy name srte_c_20_ep_1.1.1.4
SR-TE policy database
---------------------
Color: 20, End-point: 1.1.1.4
Name: srte_c_20_ep_1.1.1.4
Status:
Admin: up Operational: up for 00:00:15 (since Jul 14 00:53:10.615)
Candidate-paths:
Preference: 200 (configuration) (active)
Name: POLICY2
Requested BSID: dynamic
Protection Type: protected-preferred
Maximum SID Depth: 8
Explicit: segment-list SIDLIST2 (active)
Weight: 1, Metric Type: TE
16002
16003
16004
Attributes:
Binding SID: 51301
Forward Class: Not Configured
Steering labeled-services disabled: no
Steering BGP disabled: no
IPv6 caps enable: yes
Invalidation drop enabled: no
Configuring Explicit Path with Affinity Constraint Validation
To fully configure SR-TE flexible name-based policy constraints, you must complete these high-level tasks in order:
1.
Assign Color Names to Numeric Values
2.
Associate Affinity-Names with SR-TE Links
3.
Associate Affinity Constraints for SR-TE Policies
184
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure SR-TE Policies
Configuring Explicit Path with Affinity Constraint Validation
/* Enter the global configuration mode and assign color names to numeric values
Router# configure
Router(config)# segment-routing
Router(config-sr)# traffic-eng
Router(config-sr-te)# affinity-map
Router(config-sr-te-affinity-map)# blue bit-position 0
Router(config-sr-te-affinity-map)# green bit-position 1
Router(config-sr-te-affinity-map)# red bit-position 2
Router(config-sr-te-affinity-map)# exit
/* Associate affinity-names with SR-TE links
Router(config-sr-te)# interface Gi0/0/0/0
Router(config-sr-te-if)# affinity
Router(config-sr-te-if-affinity)# blue
Router(config-sr-te-if-affinity)# exit
Router(config-sr-te-if)# exit
Router(config-sr-te)# interface Gi0/0/0/1
Router(config-sr-te-if)# affinity
Router(config-sr-te-if-affinity)# blue
Router(config-sr-te-if-affinity)# green
Router(config-sr-te-if-affinity)# exit
Router(config-sr-te-if)# exit
Router(config-sr-te)#
/* Associate affinity constraints for SR-TE policies
Router(config-sr-te)# segment-list name SIDLIST1
Router(config-sr-te-sl)# index 10 mpls adjacency 1.1.1.2
Router(config-sr-te-sl)# index 20 mpls adjacency 2.2.2.23
Router(config-sr-te-sl)# index 30 mpls adjacency 1.1.1.4
Router(config-sr-te-sl)# exit
Router(config-sr-te)# segment-list name SIDLIST2
Router(config-sr-te-sl)# index 10 mpls adjacency 1.1.1.2
Router(config-sr-te-sl)# index 30 mpls adjacency 1.1.1.4
Router(config-sr-te-sl)# exit
Router(config-sr-te)# segment-list name SIDLIST3
Router(config-sr-te-sl)# index 10 mpls adjacency 1.1.1.5
Router(config-sr-te-sl)# index 30 mpls adjacency 1.1.1.4
Router(config-sr-te-sl)# exit
Router(config-sr-te)# policy POLICY1
Router(config-sr-te-policy)# color 20 end-point ipv4 1.1.1.4
Router(config-sr-te-policy)# binding-sid mpls 1000
Router(config-sr-te-policy)# candidate-paths
Router(config-sr-te-policy-path)# preference 200
Router(config-sr-te-policy-path-pref)# constraints affinity exclude-any red
Router(config-sr-te-policy-path-pref)# explicit segment-list SIDLIST1
Router(config-sr-te-pp-info)# exit
Router(config-sr-te-policy-path-pref)# explicit segment-list SIDLIST2
Router(config-sr-te-pp-info)# exit
Router(config-sr-te-policy-path-pref)# exit
Router(config-sr-te-policy-path)# preference 100
Router(config-sr-te-policy-path-pref)# explicit segment-list SIDLIST3
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
185
Configuring Explicit Path with Affinity Constraint Validation
Running Configuration
Router# show running-configuration segment-routing traffic-eng interface GigabitEthernet0/0/0/0 affinity
!
blue
!
interface GigabitEthernet0/0/0/1 affinity
!
!
blue green segment-list name SIDLIST1 index 10 mpls adjacency 1.1.1.2
index 20 mpls adjacency 2.2.2.23
index 30 mpls adjacency 1.1.1.4
!
segment-list name SIDLIST2
!
index 10 mpls adjacency 1.1.1.2
index 30 mpls adjacency 1.1.1.4
segment-list name SIDLIST3 index 10 mpls adjacency 1.1.1.5
!
index 30 mpls adjacency 1.1.1.4
policy POLICY1 binding-sid mpls 1000 color 20 end-point ipv4 1.1.1.4
candidate-paths preference 100 explicit segment-list SIDLIST3
!
!
preference 200 explicit segment-list SIDLIST1
!
explicit segment-list SIDLIST2
!
!
!
!
!
constraints affinity exclude-any
!
!
red
!
!
affinity-map blue bit-position 0 green bit-position 1
!
red bit-position 2
186
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure SR-TE Policies
Configure SR-TE Policies
Configure Explicit Path with Segment Protection-Type Constraint
Configure Explicit Path with Segment Protection-Type Constraint
For an SR policy with an explicit path that includes IP addresses of links, the SR-TE process encodes these segments using the corresponding adjacency SID (Adj-SID) for each link. The type of Adj-SID used (protected or unprotected) is determined by the segment protection-type constraint configured under the SR policy. See the
Segment Protection-Type Constraint, on page 178 .
Configure Local SR-TE Policy Using Explicit Paths
Create a segment list with IP addresses:
Router# configure
Router(config)# segment-routing
Router(config-sr)# traffic-eng
Router(config-sr-te)# segment-list name SIDLIST1
Router(config-sr-te-sl)# index 10 mpls adjacency 1.1.1.2
Router(config-sr-te-sl)# index 20 mpls adjacency 1.1.1.3
Router(config-sr-te-sl)# index 30 mpls adjacency 1.1.1.4
Router(config-sr-te-sl)# exit
Create the SR-TE policy with segment protection-type constraint:
Router(config-sr-te)# policy POLICY1
Router(config-sr-te-policy)# color 20 end-point ipv4 1.1.1.4
Router(config-sr-te-policy)# candidate-paths
Router(config-sr-te-policy-path)# preference 100
Router(config-sr-te-policy-path-pref)# explicit segment-list SIDLIST1
Router(config-sr-te-pp-info)# exit
Router(config-sr-te-policy-path-pref)# constraints
Router(config-sr-te-path-pref-const)# segments
Router(config-sr-te-path-pref-const-seg)# protection protected-only
Router(config-sr-te-path-pref-const-seg)# commit
Running Configuration
Router# show running-configuration segment-routing traffic-eng segment-list SIDLIST1 index 10 mpls adjacency 1.1.1.2
index 20 mpls adjacency 1.1.1.3
!
index 30 mpls adjacency 1.1.1.4
policy POLICY1 color 10 end-point ipv4 1.1.1.4
candidate-paths preference 100 explicit segment-list SIDLIST1
!
constraints
!
!
segments protection protected-only
!
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
187
Configure SR-TE Policies
Protocols
Protocols
Path Computation Element Protocol
The path computation element protocol (PCEP) describes a set of procedures by which a path computation client (PCC) can report and delegate control of head-end label switched paths (LSPs) sourced from the PCC to a PCE peer. The PCE can request the PCC to update and modify parameters of LSPs it controls. The stateful model also enables a PCC to allow the PCE to initiate computations allowing the PCE to perform network-wide orchestration.
Configure the Head-End Router as PCEP PCC
Configure the head-end router as PCEP Path Computation Client (PCC) to establish a connection to the PCE.
The PCC and PCE addresses must be routable so that TCP connection (to exchange PCEP messages) can be established between PCC and PCE.
Configure the PCC to Establish a Connection to the PCE
Use the segment-routing traffic-eng pcc command to configure the PCC source address, the SR-PCE address, and SR-PCE options.
A PCE can be given an optional precedence. If a PCC is connected to multiple PCEs, the PCC selects a PCE with the lowest precedence value. If there is a tie, a PCE with the highest IP address is chosen for computing path. The precedence value range is from 0 to 255.
Router(config)# segment-routing
Router(config-sr)# traffic-eng
Router(config-sr-te)# pcc
Router(config-sr-te-pcc)# source-address ipv4 local-source-address
Router(config-sr-te-pcc)# pce address ipv4 PCE-address [ precedence value ]
Router(config-sr-te-pcc)# pce address ipv4 PCE-address [ keychain WORD ]
Configure PCEP Authentication
TCP Message Digest 5 (MD5) authentication has been used for authenticating PCEP (TCP) sessions by using a clear text or encrypted password. This feature introduces support for TCP Authentication Option (TCP-AO), which replaces the TCP MD5 option.
TCP-AO uses Message Authentication Codes (MACs), which provides the following:
• Protection against replays for long-lived TCP connections
• More details on the security association with TCP connections than TCP MD5
• A larger set of MACs with minimal system and operational changes
TCP-AO is compatible with Master Key Tuple (MKT) configuration. TCP-AO also protects connections when using the same MKT across repeated instances of a connection. TCP-AO protects the connections by using traffic key that are derived from the MKT, and then coordinates changes between the endpoints.
188
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure SR-TE Policies
Configure the Head-End Router as PCEP PCC
Note TCP-AO and TCP MD5 are never permitted to be used simultaneously. TCP-AO supports IPv6, and is fully compatible with the proposed requirements for the replacement of TCP MD5.
TCP Message Digest 5 (MD5) Authentication
Use the password { clear | encrypted } LINE command to enable TCP MD5 authentication for all PCEP peers.
Any TCP segment coming from the PCC that does not contain a MAC matching the configured password will be rejected. Specify if the password is encrypted or clear text
Router(config-sr-te-pcc)# pce address ipv4 PCE-address [ password {clear | encrypted} LINE ]
TCP Authentication Option (TCP-AO)
Use the tcp-ao key-chain [ include-tcp-options ] command to enable TCP Authentication Option (TCP-AO) authentication for all PCEP peers. Any TCP segment coming from the PCC that does not contain a MAC matching the configured key chain will be rejected. Use the include-tcp-options keyword to include other
TCP options in the header for MAC calculation.
Router(config-sr-te-pcc)# pce address ipv4 PCE-address tcp-ao key-chain [ include-tcp-options ]
Configure PCEP-Related Timers
Use the timers keepalive command to specify how often keepalive messages are sent from PCC to its peers.
The range is from 0 to 255 seconds; the default value is 30.
Router(config-sr-te-pcc)# timers keepalive seconds
Use the timers deadtimer command to specify how long the remote peers wait before bringing down the
PCEP session if no PCEP messages are received from this PCC. The range is from 1 to 255 seconds; the default value is 120.
Router(config-sr-te-pcc)# timers deadtimer seconds
Use the timers delegation-timeout command to specify how long a delegated SR policy can remain up without an active connection to a PCE. The range is from 0 to 3600 seconds; the default value is 60.
Router(config-sr-te-pcc)# timers delegation-timeout seconds
PCE-Initiated SR Policy Timers
Use the timers initiated orphans command to specify the amount of time that a PCE-initiated SR policy will remain delegated to a PCE peer that is no longer reachable by the PCC. The range is from 10 to 180 seconds; the default value is 180.
Router(config-sr-te-pcc)# timers initiated orphans seconds
Use the timers initiated state command to specify the amount of time that a PCE-initiated SR policy will remain programmed while not being delegated to any PCE. The range is from 15 to 14440 seconds (24 hours); the default value is 600.
Router(config-sr-te-pcc)# timers initiated state seconds
To better understand how the PCE-initiated SR policy timers operate, consider the following example:
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
189
Configure SR-TE Policies
Configure the Head-End Router as PCEP PCC
• PCE A instantiates SR policy P at head-end N.
• Head-end N delegates SR policy P to PCE A and programs it in forwarding.
• If head-end N detects that PCE A is no longer reachable, then head-end N starts the PCE-initiated orphan and state timers for SR policy P.
• If PCE A reconnects before the orphan timer expires, then SR policy P is automatically delegated back to its original PCE (PCE A).
• After the orphan timer expires, SR policy P will be eligible for delegation to any other surviving PCE(s).
• If SR policy P is not delegated to another PCE before the state timer expires, then head-end N will remove SR policy P from its forwarding.
Enable SR-TE SYSLOG Alarms
Use the logging policy status command to enable SR-TE related SYSLOG alarms.
Router(config-sr-te)# logging policy status
Enable PCEP Reports to SR-PCE
Use the report-all command to enable the PCC to report all SR policies in its database to the PCE.
Router(config-sr-te-pcc)# report-all
Customize MSD Value at PCC
Use the maximum-sid-depth value command to customize the Maximum SID Depth (MSD) signaled by
PCC during PCEP session establishment.
The default MSD value is equal to the maximum MSD supported by the platform (12).
Router(config-sr-te)# maximum-sid-depth value
Note The platform's SR-TE label imposition capabilities are as follows:
• Up to 12 transport labels when no service labels are imposed
• Up to 9 transport labels when service labels are imposed
For cases with path computation at PCE, a PCC can signal its MSD to the PCE in the following ways:
• During PCEP session establishment – The signaled MSD is treated as a node-wide property.
• MSD is configured under segment-routing traffic-eng maximum-sid-depth value command
• During PCEP LSP path request – The signaled MSD is treated as an LSP property.
• On-demand (ODN) SR Policy: MSD is configured using the segment-routing traffic-eng
on-demand color color maximum-sid-depth value command
• Local SR Policy: MSD is configured using the segment-routing traffic-eng policy WORD
candidate-paths preference preference dynamic metric sid-limit value command.
190
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure SR-TE Policies
Configure the Head-End Router as PCEP PCC
Note If the configured MSD values are different, the per-LSP MSD takes precedence over the per-node MSD.
After path computation, the resulting label stack size is verified against the MSD requirement.
• If the label stack size is larger than the MSD and path computation is performed by PCE, then the PCE returns a "no path" response to the PCC.
• If the label stack size is larger than the MSD and path computation is performed by PCC, then the PCC will not install the path.
Note A sub-optimal path (if one exists) that satisfies the MSD constraint could be computed in the following cases:
• For a dynamic path with TE metric, when the PCE is configured with the pce segment-routing te-latency command or the PCC is configured with the segment-routing traffic-eng te-latency command.
• For a dynamic path with LATENCY metric
• For a dynamic path with affinity constraints
For example, if the PCC MSD is 4 and the optimal path (with an accumulated metric of 100) requires 5 labels, but a sub-optimal path exists (with accumulated metric of 110) requiring 4 labels, then the sub-optimal path is installed.
Customize the SR-TE Path Calculation
Use the te-latency command to enable ECMP-aware path computation for TE metric.
Router(config-sr-te)# te-latency
Note ECMP-aware path computation is enabled by default for IGP and LATENCY metrics.
Configure PCEP Redundancy Type
Use the redundancy pcc-centric command to enable PCC-centric high-availability model. The PCC-centric model changes the default PCC delegation behavior to the following:
• After LSP creation, LSP is automatically delegated to the PCE that computed it.
• If this PCE is disconnected, then the LSP is redelegated to another PCE.
• If the original PCE is reconnected, then the delegation fallback timer is started. When the timer expires, the LSP is redelegated back to the original PCE, even if it has worse preference than the current PCE.
Router(config-sr-te-pcc)# redundancy pcc-centric
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
191
Configure SR-TE Policies
Configure the Head-End Router as PCEP PCC
Configuring Head-End Router as PCEP PCC and Customizing SR-TE Related Options: Example
The following example shows how to configure an SR-TE head-end router with the following functionality:
• Enable the SR-TE head-end router as a PCEP client (PCC) with 3 PCEP servers (PCE) with different precedence values. The PCE with IP address 1.1.1.57 is selected as BEST.
• Enable SR-TE related syslogs.
• Set the Maximum SID Depth (MSD) signaled during PCEP session establishment to 5.
• Enable PCEP reporting for all policies in the node.
segment-routing traffic-eng pcc source-address ipv4 1.1.1.2
pce address ipv4 1.1.1.57
precedence 150 password clear <password>
!
pce address ipv4 1.1.1.58
precedence 200
!
password clear <password>
!
!
pce address ipv4 1.1.1.59
precedence 250 password clear <password> logging policy status
!
maximum-sid-depth 5 pcc
!
!
report-all
!
end
Verification
RP/0/RSP0/CPU0:Router# show segment-routing traffic-eng pcc ipv4 peer
PCC's peer database:
--------------------
Peer address: 1.1.1.57
, Precedence: 150 , ( best PCE )
State up
Capabilities: Stateful, Update, Segment-Routing, Instantiation
Peer address: 1.1.1.58
, Precedence: 200
State up
Capabilities: Stateful, Update, Segment-Routing, Instantiation
Peer address: 1.1.1.59
, Precedence: 250
State up
Capabilities: Stateful, Update, Segment-Routing, Instantiation
192
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure SR-TE Policies
Configure SR-TE PCE Groups
Configure SR-TE PCE Groups
Table 17: Feature History Table
Feature Name
SR-TE PCE Groups
Release
Release 7.3.2
Description
This feature allows an SR policy to be delegated to a set of PCE servers configured under a PCE group.
Multiple PCE groups can be configured to allow SR policies on the same head-end to be delegated to different sets of PCEs.
With this functionality, an operator can designate sets of PCEs for various purposes, such as
PCE-per-service-type or
PCE-per-wholesale-customers.
This feature allows an SR policy to be delegated or reported to a set of PCE servers configured under a PCE group. Multiple PCE groups can be configured to allow different SR policies on the same head-end to be delegated or reported to different sets of PCEs.
With this functionality, an operator can designate sets of PCEs for various purposes, such as
PCE-per-service-type or PCE-per-wholesale-customer.
In the figure below, Router A has a PCEP session with 5 PCEs. The PCEs are configured over 3 PCE groups.
PCE1 is in the “default” group. PCE2 and PCE3 are in the RED group. PCE4 and PCE5 are in the BLUE group.
Figure 11: Example: PCE Groups
In case of PCE failure, each candidate path is re-delegated to the next-best PCE within the same PCE group.
For example, if the best PCE in the RED group (PCE2) fails, then all candidate paths in the RED group fallback to the secondary PCE in the RED group (PCE3). If all the PCEs in the RED group fail, then all candidate paths in the RED group become undelegated; they are not delegated to the PCEs in the BLUE group. If there
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
193
Configure SR-TE Policies
Configure SR-TE PCE Groups are no more available PCEs in the given PCE group, then the outcome is the same as when there are no available PCEs.
Configure PCE Groups
Use the segment-routing traffic-eng pcc pce address { ipv4 ipv4_addr | ipv6 ipv6_addr } pce-group WORD command to configure the PCE groups.
The following example shows how to configure the PCE groups
• PCE1 in the “default” group
• PCE2 and PCE3 in the “red” group
• PCE4 and PCE5 in the “blue” group
Router(config)# segment-routing traffic-eng pcc
Router(config-sr-te-pcc)# pce address ipv4 1.1.1.1
Router(config-pcc-pce)# precedence 10
Router(config-pcc-pce)# exit
Router(config-sr-te-pcc)# pce address ipv4 2.2.2.2
Router(config-pcc-pce)# precedence 20
Router(config-pcc-pce)# pce-group red
Router(config-pcc-pce)# exit
Router(config-sr-te-pcc)# pce address ipv4 3.3.3.3
Router(config-pcc-pce)# precedence 30
Router(config-pcc-pce)# pce-group red
Router(config-pcc-pce)# exit
Router(config-sr-te-pcc)# pce address ipv4 4.4.4.4
Router(config-pcc-pce)# precedence 40
Router(config-pcc-pce)# pce-group blue
Router(config-pcc-pce)# exit
Router(config-sr-te-pcc)# pce address ipv4 5.5.5.5
Router(config-pcc-pce)# precedence 50
Router(config-pcc-pce)# pce-group blue
Router(config-pcc-pce)# exit
Verification segment-routing traffic-eng pcc pce address ipv4 1.1.1.1
precedence 10
!
pce address ipv4 2.2.2.2
precedence 20 pce-group red
!
pce address ipv4 3.3.3.3
precedence 30 pce-group red
!
pce address ipv4 4.4.4.4
precedence 40 pce-group blue
194
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure SR-TE Policies
Configure SR-TE PCE Groups
!
!
!
!
!
pce address ipv4 5.5.5.5
precedence 50 pce-group blue
Assign PCE Group to a Candidate Path or ODN Template
Use the segment-routing traffic-eng policy policy pce-group WORD command to assign the PCE group to all candidate paths of an SR policy.
Use the segment-routing traffic-eng policy policy candidate-paths preference pref pce-group WORD command to assign the PCE group to a specific candidate path of an SR policy.
Use the segment-routing traffic-eng on-demand color color pce-group WORD command to assign the
PCE group to on-demand candidate paths triggered by an ODN template.
Note Only one PCE group can be attached to a given SR policy candidate path.
The following example shows how to configure a policy with all candidate paths delegated/reported to PCEs in the default group:
Router(config)# segment-routing traffic-eng
Router(config-sr-te)# policy A
Router(config-sr-te-policy)# color 100 end-point ipv4 192.168.0.2
Router(config-sr-te-policy)# candidate-paths
Router(config-sr-te-policy-path)# preference 100
Router(config-sr-te-policy-path-pref)# dynamic
Router(config-sr-te-pp-info)# pcep
Router(config-sr-te-path-pcep)# exit
Router(config-sr-te-pp-info)# exit
Router(config-sr-te-policy-path-pref)# exit
Router(config-sr-te-policy-path)# exit
Router(config-sr-te-policy)# exit
The following example shows how to configure a policy with all candidate paths delegated/reported to PCEs in the red group:
Router(config-sr-te)# policy B
Router(config-sr-te-policy)# color 100 end-point ipv4 192.168.0.3
Router(config-sr-te-policy)# pce-group red
Router(config-sr-te-policy)# candidate-paths
Router(config-sr-te-policy-path)# preference 100
Router(config-sr-te-policy-path-pref)# dynamic
Router(config-sr-te-pp-info)# pcep
Router(config-sr-te-path-pcep)# exit
Router(config-sr-te-pp-info)# exit
Router(config-sr-te-policy-path-pref)# exit
Router(config-sr-te-policy-path)# exit
Router(config-sr-te-policy)# exit
The following example shows how to configure a policy with a specific candidate path (explicit path) reported to PCEs in the blue group:
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
195
Configure SR-TE Policies
Configure SR-TE PCE Groups
Router(config-sr-te)# policy C
Router(config-sr-te-policy)# color 100 end-point ipv4 192.168.0.4
Router(config-sr-te-policy)# candidate-paths
Router(config-sr-te-policy-path)# preference 100
Router(config-sr-te-policy-path-pref)# pce-group blue
Router(config-sr-te-policy-path-pref)# explicit segment-list SLA
Router(config-sr-te-pp-info)# exit
Router(config-sr-te-policy-path-pref)# exit
Router(config-sr-te-policy-path)# exit
Router(config-sr-te-policy)# exit
The following example shows how to configure an ODN template with on-demand candidate paths delegated/reported to PCEs in the blue group:
Router(config-sr-te)# on-demand color 10
Router(config-sr-te-color)# pce-group blue
Router(config-sr-te-color)# dynamic
Router(config-sr-te-color-dyn)# pcep
Router(config-sr-te-color-dyn-pce)#
Running Config segment-routing traffic-eng on-demand color 10 dynamic pcep
!
!
!
pce-group blue policy A color 100 end-point ipv4 192.168.0.2
candidate-paths preference 100 dynamic pcep
!
!
!
!
!
policy B color 100 end-point ipv4 192.168.0.3
pce-group red candidate-paths preference 100 dynamic
!
pcep
!
!
!
!
policy C color 100 end-point ipv4 192.168.0.4
candidate-paths preference 100 explicit segment-list SLA
!
!
pce-group blue
196
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure SR-TE Policies
Configure SR-TE PCE Groups
!
!
!
!
end
Verification
Router# show segment-routing traffic-eng pcc ipv4 peer
PCC's peer database:
--------------------
Peer address: 1.1.1.1
Precedence: 10 (best PCE)
State up
Capabilities: Stateful, Update, Segment-Routing, Instantiation
Peer address: 2.2.2.2
Group: red, Precedence 20
State up
Capabilities: Stateful, Update, Segment-Routing, Instantiation
Peer address: 3.3.3.3
Group: red, Precedence 30
State up
Capabilities: Stateful, Update, Segment-Routing, Instantiation
Peer address: 4.4.4.4
Group: blue, Precedence 40
State up
Capabilities: Stateful, Update, Segment-Routing, Instantiation
Peer address: 5.5.5.5
Group: blue, Precedence 50
State up
Capabilities: Stateful, Update, Segment-Routing, Instantiation
Router# show segment-routing traffic-eng policy name srte_c_100_ep_192.168.0.3
SR-TE policy database
---------------------
Color: 100, End-point: 192.168.0.3
Name: srte_c_100_ep_192.168.0.3
Status:
Admin: up Operational: up for 00:13:26 (since Sep 17 22:52:48.365)
Candidate-paths:
Preference: 100 (configuration)
Name: B
Requested BSID: dynamic
PCC info:
Symbolic name: cfg_B_discr_100
PLSP-ID: 2
Protection Type: protected-preferred
Maximum SID Depth: 10
PCE Group: red
Dynamic (pce 192.168.1.4) (valid)
Metric Type: TE, Path Accumulated Metric: 10
Attributes:
Forward Class: 0
Steering labeled-services disabled: no
Steering BGP disabled: no
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
197
Configure SR-TE Policies
BGP SR-TE
IPv6 caps enable: no
Invalidation drop enabled: no
BGP SR-TE
BGP may be used to distribute SR Policy candidate paths to an SR-TE head-end. Dedicated BGP SAFI and
NLRI have been defined to advertise a candidate path of an SR Policy. The advertisement of Segment Routing policies in BGP is documented in the IETF draft https://datatracker.ietf.org/doc/ draft-ietf-idr-segment-routing-te-policy/
SR policies with IPv4 and IPv6 end-points can be advertised over BGPv4 or BGPv6 sessions between the
SR-TE controller and the SR-TE headend.
The Cisco IOS-XR implementation supports the following combinations:
• IPv4 SR policy advertised over BGPv4 session
• IPv6 SR policy advertised over BGPv4 session
• IPv6 SR policy advertised over BGPv6 session
Configure BGP SR Policy Address Family at SR-TE Head-End
Perform this task to configure BGP SR policy address family at SR-TE head-end:
Procedure
Step 1
Step 2
Command or Action configure
router bgp as-number
Example:
RP/0/RP0/CPU0:router(config)# router bgp
65000
Purpose
Specifies the BGP AS number and enters the
BGP configuration mode, allowing you to configure the BGP routing process.
Step 3 bgp router-id ip-address
Example:
RP/0/RP0/CPU0:router(config-bgp)# bgp router-id 1.1.1.1
Configures the local router with a specified router ID.
Step 4 address-family { ipv4 | ipv6 } sr-policy
Example:
RP/0/RP0/CPU0:router(config-bgp)# address-family ipv4 sr-policy
Specifies either the IPv4 or IPv6 address family and enters address family configuration submode.
Step 5 exit
198
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure SR-TE Policies
Configure BGP SR Policy Address Family at SR-TE Head-End
Step 6
Step 7
Command or Action
neighbor ip-address
Example:
RP/0/RP0/CPU0:router(config-bgp)# neighbor 10.10.0.1
Purpose
Places the router in neighbor configuration mode for BGP routing and configures the neighbor IP address as a BGP peer.
remote-as as-number
Example:
RP/0/RP0/CPU0:router(config-bgp-nbr)# remote-as 1
Creates a neighbor and assigns a remote autonomous system number to it.
Step 8
Step 9 address-family { ipv4 | ipv6 } sr-policy
Example:
RP/0/RP0/CPU0:router(config-bgp-nbr)# address-family ipv4 sr-policy
Specifies either the IPv4 or IPv6 address family and enters address family configuration submode.
route-policy route-policy-name { in | out } Applies the specified policy to IPv4 or IPv6 unicast routes.
Example:
RP/0/RP0/CPU0:router(config-bgp-nbr-af)# route-policy pass out
Example: BGP SR-TE with BGPv4 Neighbor to BGP SR-TE Controller
The following configuration shows the an SR-TE head-end with a BGPv4 session towards a BGP SR-TE controller. This BGP session is used to signal both IPv4 and IPv6 SR policies.
router bgp 65000 bgp router-id 1.1.1.1
!
address-family ipv4 sr-policy
!
address-family ipv6 sr-policy
!
neighbor 10.1.3.1
remote-as 10 description *** eBGP session to BGP SRTE controller *** address-family ipv4 sr-policy route-policy pass in
!
!
!
route-policy pass out
!
address-family ipv6 sr-policy route-policy pass in route-policy pass out
Example: BGP SR-TE with BGPv6 Neighbor to BGP SR-TE Controller
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
199
Configure SR-TE Policies
Traffic Steering
The following configuration shows an SR-TE head-end with a BGPv6 session towards a BGP SR-TE controller.
This BGP session is used to signal both IPv4 and IPv6 SR policies.
router bgp 65000 bgp router-id 1.1.1.1
address-family ipv4 sr-policy
!
address-family ipv6 sr-policy
!
neighbor 3001::10:1:3:1 remote-as 10 description *** eBGP session to BGP SRTE controller *** address-family ipv4 sr-policy route-policy pass in route-policy pass out
!
address-family ipv6 sr-policy
!
!
!
route-policy pass in route-policy pass out
Traffic Steering
Automated Steering
Automated steering (AS) allows service traffic to be automatically steered onto the required transport SLA path programmed by an SR policy.
With AS, BGP automatically steers traffic onto an SR Policy based on the next-hop and color of a BGP service route. The color of a BGP service route is specified by a color extended community attribute. This color is used as a transport SLA indicator, such as min-delay or min-cost.
When the next-hop and color of a BGP service route matches the end-point and color of an SR Policy, BGP automatically installs the route resolving onto the BSID of the matching SR Policy. Recall that an SR Policy on a head-end is uniquely identified by an end-point and color.
When a BGP route has multiple extended-color communities, each with a valid SR Policy, the BGP process installs the route on the SR Policy giving preference to the color with the highest numerical value.
The granularity of AS behaviors can be applied at multiple levels, for example:
200
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure SR-TE Policies
Color-Only Automated Steering
• At a service level—When traffic destined to all prefixes in a given service is associated to the same transport path type. All prefixes share the same color.
• At a destination/prefix level—When traffic destined to a prefix in a given service is associated to a specific transport path type. Each prefix could be assigned a different color.
• At a flow level—When flows destined to the same prefix are associated with different transport path types
AS behaviors apply regardless of the instantiation method of the SR policy, including:
• On-demand SR policy
• Manually provisioned SR policy
• PCE-initiated SR policy
See the
Verifying BGP VRF Information, on page 145
and
Verifying Forwarding (CEF) Table, on page 146
sections for sample output that shows AS implementation.
Color-Only Automated Steering
Color-only steering is a traffic steering mechanism where a policy is created with given color, regardless of the endpoint.
You can create an SR-TE policy for a specific color that uses a NULL end-point (0.0.0.0 for IPv4 NULL, and
::0 for IPv6 NULL end-point). This means that you can have a single policy that can steer traffic that is based on that color and a NULL endpoint for routes with a particular color extended community, but different destinations (next-hop).
Note Every SR-TE policy with a NULL end-point must have an explicit path-option. The policy cannot have a dynamic path-option (where the path is computed by the head-end or PCE) since there is no destination for the policy.
You can also specify a color-only (CO) flag in the color extended community for overlay routes. The CO flag allows the selection of an SR-policy with a matching color, regardless of endpoint Sub-address Family Identifier
(SAFI) (IPv4 or IPv6). See
Setting CO Flag, on page 202 .
Configure Color-Only Steering
Router# configure
Router(config)# segment-routing
Router(config-sr)# traffic-eng
Router(config-sr-te)# policy P1
Router(config-sr-te-policy)# color 1 end-point ipv4 0.0.0.0
Router# configure
Router(config)# segment-routing
Router(config-sr)# traffic-eng
Router(config-sr-te)# policy P2
Router(config-sr-te-policy)# color 2 end-point ipv6 ::0
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
201
Configure SR-TE Policies
Setting CO Flag
Router# show running-configuration segment-routing traffic-eng policy P1
!
color 1 end-point ipv4 0.0.0.0
!
!
policy P2 color 2 end-point ipv6 ::
!
end
Setting CO Flag
The BGP-based steering mechanism matches BGP color and next-hop with that of an SR-TE policy. If the policy does not exist, BGP requests SR-PCE to create an SR-TE policy with the associated color, end-point, and explicit paths. For color-only steering (NULL end-point), you can configure a color-only (CO) flag as part of the color extended community in BGP.
Note See
Color-Only Automated Steering, on page 201
for information about color-only steering (NULL end-point).
The behavior of the steering mechanism is based on the following values of the CO flags: co-flag 00 1.
The BGP next-hop and color <N, C> is matched with an SR-TE policy of same
<N, C>.
2.
If a policy does not exist, then IGP path for the next-hop N is chosen.
co-flag 01 1.
The BGP next-hop and color <N, C> is matched with an SR-TE policy of same
<N, C>.
2.
If a policy does not exist, then an SR-TE policy with NULL end-point with the same address-family as N and color C is chosen.
3.
If a policy with NULL end-point with same address-family as N does not exist, then an SR-TE policy with any NULL end-point and color C is chosen.
4.
If no match is found, then IGP path for the next-hop N is chosen.
Configuration Example
Router(config)# extcommunity-set opaque overlay-color
Router(config-ext)# 1 co-flag 01
Router(config-ext)# end-set
Router(config)#
Router(config)# route-policy color
Router(config-rpl)# if destination in (5.5.5.1/32) then
Router(config-rpl-if)# set extcommunity color overlay-color
Router(config-rpl-if)# endif
Router(config-rpl)# pass
Router(config-rpl)# end-policy
202
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure SR-TE Policies
Address-Family Agnostic Automated Steering
Router(config)#
Address-Family Agnostic Automated Steering
Address-family agnostic steering uses an SR-TE policy to steer both labeled and unlabeled IPv4 and IPv6 traffic. This feature requires support of IPv6 encapsulation (IPv6 caps) over IPV4 endpoint policy.
IPv6 caps for IPv4 NULL end-point is enabled automatically when the policy is created in Segment Routing
Path Computation Element (SR-PCE). The binding SID (BSID) state notification for each policy contains an
"ipv6_caps" flag that notifies SR-PCE clients (PCC) of the status of IPv6 caps (enabled or disabled).
An SR-TE policy with a given color and IPv4 NULL end-point could have more than one candidate path. If any of the candidate paths has IPv6 caps enabled, then all of the remaining candidate paths need IPv6 caps enabled. If IPv6 caps is not enabled on all candidate paths of same color and end-point, traffic drops can occur.
You can disable IPv6 caps for a particular color and IPv4 NULL end-point using the ipv6 disable command on the local policy. This command disables IPv6 caps on all candidate paths that share the same color and
IPv4 NULL end-point.
Disable IPv6 Encapsulation
Router# configure
Router(config)# segment-routing
Router(config-sr)# traffic-eng
Router(config-sr-te)# policy P1
Router(config-sr-te-policy)# color 1 end-point ipv4 0.0.0.0
Router(config-sr-te-policy)# ipv6 disable
Per-Flow Automated Steering
Table 18: Feature History Table
Feature Name
Per-Flow Automated Steering: L3
/ L2 BGP Services + BSID Steering
Release Information
Release 7.4.1
Feature Description
This feature introduces support for
BGP VPNv6 (6VPE) and BGP
EVPN (single-home/multi-homed) over PFP, labeled traffic (Binding
SID as top-most label in the stack) steering over per-flow policy (PFP).
An ingress QoS policy applied to an input interface is used to classify flows and set corresponding MPLS experimental values.
The steering of traffic through a Segment Routing (SR) policy is based on the candidate paths of that policy.
For a given policy, a candidate path specifies the path to be used to steer traffic to the policy’s destination.
The policy determines which candidate path to use based on the candidate path’s preference and state. The candidate path that is valid and has the highest preference is used to steer all traffic using the given policy.
This type of policy is called a Per-Destination Policy (PDP).
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
203
Configure SR-TE Policies
Per-Flow Automated Steering
Per-Flow Automated Traffic Steering using SR-TE Policies introduces a way to steer traffic on an SR policy based on the attributes of the incoming packets, called a Per-Flow Policy (PFP).
A PFP provides up to 8 "ways" or options to the endpoint. With a PFP, packets are classified by a classification policy and marked using internal tags called forward classes (FCs). The FC setting of the packet selects the
“way”. For example, this “way” can be a traffic-engineered SR path, using a low-delay path to the endpoint.
The FC is represented as a numeral with a value of 0 to 7.
A PFP defines an array of FC-to-PDP mappings. A PFP can then be used to steer traffic into a given PDP based on the FC assigned to a packet.
As with PDPs, PFPs are identified by a {headend, color, endpoint} tuple. The color associated with a given
FC corresponds to a valid PDP policy of that color and same endpoint as the parent PFP. So PFP policies contain mappings of different FCs to valid PDP policies of different colors. Every PFP has an FC designated as its default FC. The default FC is associated to packets with a FC undefined under the PFP or for packets with a FC with no valid PDP policy.
The following example shows a per-flow policy from Node1 to Node4:
Figure 12: PFP Example
• FC=0 -> shortest path to Node4
• IGP shortest path = 16004
• FC=1 -> Min-delay path to Node4
• SID list = {16002,16004}
The same on-demand instantiation behaviors of PDPs apply to PFPs. For example, an edge node automatically
(on demand) instantiates Per-Flow SR Policy paths to an endpoint by service route signaling. Automated
Steering steers the service route in the matching SR Policy.
Figure 13: PFP with ODN Example
Like PDPs, PFPs have a binding SID (BSID). Existing SR-TE automated steering (AS) mechanisms for labeled traffic (via BSID) and unlabeled traffic (via BGP) onto a PFP is similar to that of a PDP. For example, a packet having the BSID of a PFP as the top label is steered onto that PFP. The classification policy on the
204
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure SR-TE Policies
Per-Flow Automated Steering ingress interface marks the packet with an FC based on the configured class-map. The packet is then steered to the PDP that corresponds to that FC.
Usage Guidelines and Limitations
The following guidelines and limitations apply to the platform when acting as a head-end of a PFP policy:
• BGP IPv4 unicast over PFP (steered via ODN/AS) is supported
• BGP IPv6 unicast (with IPv4 next-hop [6PE]) over PFP (steered via ODN/AS) is supported
• BGP IPv6 unicast (with IPv6 next-hop) over PFP (steered via ODN/AS) is supported
• BGP VPNv4 over PFP (steered via ODN/AS) is supported
• BGP VPNv6 (6VPE) over PFP (steered via ODN/AS) is supported
• BGP EVPN (single-home/multi-homed) over PFP (steered via ODN/AS) is supported
• Pseudowire and VPLS over PFP (steered with preferred-path) are supported
• BGP multipath is supported
• BGP PIC is not supported
• Labeled traffic (Binding SID as top-most label in the stack) steered over PFP is supported
• When not explicitly configured, FC 0 is the default FC.
• A PFP is considered valid as long as its default FC has a valid PDP.
• An ingress QoS policy applied to an input interface is used to classify flows and set corresponding MPLS experimental values.
• PFP implementation is accomplished with a double-pass through the ASIC (recirculation).
• In the first pass, an ingress QoS policy applied to an input interface is used to classify flows and set
MPLS EXP values, alongside push of service label and PFP Binding SID label.
• In the absence of any ingress QoS policy, the default behavior is to copy PREC/DSCP/EXP to PFP
BSID MPLS EXP.
• In the second pass, a forwarding lookup based on PFP Binding SID label plus MPLS EXP is used to resolve to a given PFP’s PDP.
• The PFP’s BSID is allocated from a user-configured MPLS label block; see
.
• The following counters are supported:
• PFP’s BSID counter (packet, bytes)
• Per-FC counters (packet, byte)
• Collected from the PDP’s segment-list-per-path egress counters
• If an SR policy is used for more than one purpose (as a regular policy as well as a PDP under one or more PFPs), then the collected counters will represent the aggregate of all contributions.
To preserve independent counters, it is recommended that an SR policy be used only for one purpose.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
205
Configure SR-TE Policies
Per-Flow Automated Steering
• Inbound packet classification, based on the following fields, is supported:
• IP precedence
• IP DSCP
• L3 ACL-based (L3 source/destination IP; L4 source/destination port)
• MPLS EXP
• Layer 2 CoS
• MAC ACL
• A color associated with a PFP SR policy cannot be used by a non-PFP SR policy. For example, if a per-flow ODN template for color 100 is configured, then the system will reject the configuration of any non-PFP SR policy using the same color. You must assign different color value ranges for PFP and non-PFP SR policies.
Configuring PFP BSID Label Block
Implementation on NCS platforms requires that the BSID assigned to a PFP be allocated from a preconfigured label block. The BSID is a local segment.
This label range cannot overlap with the existing SRLB or SRGB ranges allocated on the platform.
To configure the MPLS label block for PFP BSID allocation, use the block name name type pfp start starting-value { end ending-value | size size } [ client word ] command.
This example shows how to allocate a block of labels based on the size of the block:
Router(config)# mpls label blocks
Router(config-mpls-lbl-blks)# block name sample-pfp-bsid-block type pfp start 40000 size
1000 client any
This example shows how to allocate a block of labels based on specific starting and ending values:
Router(config)# mpls label blocks
Router(config-mpls-lbl-blks)# block name sample-pfp-bsid-block type pfp start 40000 end
41000 client any
Configuring ODN Template for PFP Policies: Example
The following example depicts an ODN template for PFP policies that includes three FCs.
The example also includes the corresponding ODN templates for PDPs as follows:
• FC0 (default FC) mapped to color 10 = Min IGP path
• FC1 mapped to color 20 = Flex Algo 128 path
• FC2 mapped to color 30 = Flex Algo 129 path segment-routing traffic-eng on-demand color 10 dynamic
206
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure SR-TE Policies
Per-Flow Automated Steering
!
!
metric type igp
!
on-demand color 20 constraints segments
!
!
sid-algorithm 128
!
on-demand color 30 constraints
!
!
segments sid-algorithm 129
!
on-demand color 1000 per-flow forward-class 0 color 10 forward-class 1 color 20 forward-class 2 color 30
Manually Configuring a PFP and PDPs: Example
The following example depicts a manually defined PFP that includes three FCs and corresponding manually defined PDPs.
The example also includes the corresponding PDPs as follows:
• FC0 (default FC) mapped to color 10 = Min IGP path
• FC1 mapped to color 20 = Min TE path
• FC2 mapped to color 30 = Min delay path mpls label blocks block name sample-pfp-bsid-block type pfp start 400000 size 1000 client any
!
!
segment-routing traffic-eng policy MyPerFlow color 1000 end-point ipv4 1.1.1.4
candidate-paths preference 100 per-flow forward-class 0 color 10 forward-class 1 color 20 forward-class 2 color 30
!
policy MyLowIGP color 10 end-point ipv4 1.1.1.4
candidate-paths preference 100 dynamic metric type igp
!
policy MyLowTE color 20 end-point ipv4 1.1.1.4
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
207
Configure SR-TE Policies
Per-Flow Automated Steering candidate-paths preference 100 dynamic metric type te
!
policy MyLowDelay color 30 end-point ipv4 1.1.1.4
candidate-paths preference 100 dynamic metric type delay
Configuring Ingress Classification: Example
An MQC QoS policy is used to classify and mark traffic to a corresponding MPLS experimental value.
The following shows an example of such ingress classification policy: class-map match-any MinDelay match dscp 46 end-class-map
!
class-map match-any PremiumHosts
!
match access-group ipv4 PrioHosts end-class-map
!
policy-map MyPerFlowClassificationPolicy class MinDelay set mpls experimental imposition 2
!
class PremiumHosts set mpls experimental imposition 1
!
class class-default
!
end-policy-map
!
interface GigabitEthernet0/0/0/0 description PE_Ingress_Interface service-policy input MyPerFlowClassificationPolicy
!
Determining Per-Flow Policy State
A PFP is brought down for the following reasons:
• The PDP associated with the default FC is in a down state.
• All FCs are associated with PDPs in a down state.
• The FC assigned as the default FC is missing in the forward class mapping.
Scenario 1—FC 0 (default FC) is not configured in the FC mappings below: policy foo color 1 end-point ipv4 1.1.1.1
per-flow forward-class 1 color 10 forward-class 2 color 20
208
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure SR-TE Policies
Using Binding Segments
Scenario 2—FC 1 is configured as the default FC, however it is not present in the FC mappings: policy foo color 1 end-point ipv4 1.1.1.1
per-flow forward-class 0 color 10 forward-class 2 color 20 forward-class default 1
Using Binding Segments
The binding segment is a local segment identifying an SR-TE policy. Each SR-TE policy is associated with a binding segment ID (BSID). The BSID is a local label that is automatically allocated for each SR-TE policy when the SR-TE policy is instantiated.
BSID can be used to steer traffic into the SR-TE policy and across domain borders, creating seamless end-to-end inter-domain SR-TE policies. Each domain controls its local SR-TE policies; local SR-TE policies can be validated and rerouted if needed, independent from the remote domain’s head-end. Using binding segments isolates the head-end from topology changes in the remote domain.
Packets received with a BSID as top label are steered into the SR-TE policy associated with the BSID. When the BSID label is popped, the SR-TE policy’s SID list is pushed.
BSID can be used in the following cases:
• Multi-Domain (inter-domain, inter-autonomous system)—BSIDs can be used to steer traffic across domain borders, creating seamless end-to-end inter-domain SR-TE policies.
• Large-Scale within a single domain—The head-end can use hierarchical SR-TE policies by nesting the end-to-end (edge-to-edge) SR-TE policy within another layer of SR-TE policies
(aggregation-to-aggregation). The SR-TE policies are nested within another layer of policies using the
BSIDs, resulting in seamless end-to-end SR-TE policies.
• Label stack compression—If the label-stack size required for an SR-TE policy exceeds the platform capability, the SR-TE policy can be seamlessly stitched to, or nested within, other SR-TE policies using a binding segment.
• BGP SR-TE Dynamic—The head-end steers the packet into a BGP-based FIB entry whose next hop is a binding-SID.
L2VPN Preferred Path
EVPN VPWS Preferred Path over SR-TE Policy feature allows you to set the preferred path between the two end-points for EVPN VPWS pseudowire (PW) using SR-TE policy.
L2VPN VPLS or VPWS Preferred Path over SR-TE Policy feature allows you to set the preferred path between the two end-points for L2VPN Virtual Private LAN Service (VPLS) or Virtual Private Wire Service (VPWS) using SR-TE policy.
Refer to the EVPN VPWS Preferred Path over SR-TE Policy and L2VPN VPLS or VPWS Preferred Path over SR-TE Policy sections in the "L2VPN Services over Segment Routing for Traffic Engineering Policy" chapter of the L2VPN and Ethernet Services Configuration Guide .
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
209
Configure SR-TE Policies
Static Route over Segment Routing Policy
Static Route over Segment Routing Policy
This feature allows you to specify a Segment Routing (SR) policy as an interface type when configuring static routes for MPLS data planes.
For information on configuring static routes, see the "Implementing Static Routes" chapter in the Routing
Configuration Guide for Cisco NCS 560 Series Routers .
Configuration Example
The following example depicts a configuration of a static route for an IPv4 destination over an SR policy according to following parameters:
• Target SR policy:
• Color = 200
• End-point = 1.1.1.4
• Auto-generated SR policy name = srte_c_200_ep_1.1.1.4
Note Use the auto-generated SR-TE policy name to attach the SR policy to the static route. Auto-generated SR policy names use the following naming convention:
srte_c_color_val_ep_endpoint-address .
Use the show segment-routing traffic-eng policy color
<color_val> endpoint ipv4 <ip_addr> command to display the auto-generated policy name.
• Admin distance = 40
• Load metric = 150
• Install the route in RIB regardless of reachability
Router(config)# router static
Router(config-static)# address-family ipv4 unicast
Router(config-static-afi)# 1.1.1.4/32 sr-policy srte_c_200_ep_1.1.1.4 40 permanent metric
150
Running Configuration router static address-family ipv4 unicast
!
1.1.1.4/32 sr-policy srte_c_200_ep_1.1.1.4 40 permanent metric 150
!
Verification
RP/0/RP0/CPU0:RTR-1# show run segment-routing traffic-eng policy sample-policy-foo
Tue Feb 16 17:40:16.759 PST
210
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure SR-TE Policies
Static Route over Segment Routing Policy segment-routing traffic-eng policy sample-policy-foo color 200 end-point ipv4 1.1.1.4
candidate-paths preference 100 dynamic metric
!
!
!
!
type te
!
!
!
RP/0/RP0/CPU0:RTR-1# show segment-routing traffic-eng policy color 200 endpoint ipv4 1.1.1.4
Tue Feb 16 17:17:45.724 PST
SR-TE policy database
---------------------
Color: 200, End-point: 1.1.1.4
Name: srte_c_200_ep_1.1.1.4
Status:
Admin: up Operational: up for 5d04h (since Feb 11 12:22:59.054)
Candidate-paths:
Preference: 100 (configuration) (active)
Name: sample-policy-foo
Requested BSID: dynamic
Protection Type: protected-preferred
Maximum SID Depth: 10
Dynamic (valid)
Metric Type: TE, Path Accumulated Metric: 14
16005 [Prefix-SID, 1.1.1.5]
16004 [Prefix-SID, 1.1.1.4]
Attributes:
Binding SID: 24014
Forward Class: Not Configured
Steering labeled-services disabled: no
Steering BGP disabled: no
IPv6 caps enable: yes
Invalidation drop enabled: no
RP/0/RP0/CPU0:RTR-1# show static sr-policy srte_c_200_ep_1.1.1.4
Tue Feb 16 17:50:19.932 PST
Paths
1.1.1.4/32
Interface VRF State srte_c_200_ep_1.1.1.4
default Up
Reference Count(in path with both intf<-->NH):0
Last IM notification was Up at Feb 16 17:09:08.325
Global ifh
IM state
RSI registration
Table IDs
: 0x0000007c
: up
: Yes
: 0xe0000000
Address Info:
1.1.1.1/32
Route tag: 0x00000000 Flags: 0x00000000 Prefix SID: False [Active]
IP-STATIC-IDB-CLASS
Total entries : 1
Interface : sr-srte_c_200_ep_1.1.1.4
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
211
Configure SR-TE Policies
Static Route over Segment Routing Policy
| Event Name
| idb-create
| Time Stamp | S, M
| Feb 16 17:09:08.352
| 0, 0
RP/0/RP0/CPU0:RTR-1# show route 1.1.1.4/32
Tue Feb 16 17:09:21.164 PST
Routing entry for 1.1.1.4/32
Known via "static", distance 40, metric 0 (connected)
Installed Feb 16 17:09:08.325 for 00:00:13
Routing Descriptor Blocks directly connected, via srte_c_200_ep_1.1.1.4
, permanent
Route metric is 0, Wt is 150
No advertising protos.
RP/0/RP0/CPU0:RTR-1# show route 1.1.1.4/32 detail
Tue Feb 16 17:09:36.718 PST
Routing entry for 1.1.1.4/32
Known via "static", distance 40, metric 0 (connected)
Installed Feb 16 17:09:08.325 for 00:00:28
Routing Descriptor Blocks directly connected, via srte_c_200_ep_1.1.1.4
, permanent
Route metric is 0, Wt is 150
Label: None
Tunnel ID: None
Binding Label: None
Extended communities count: 0
NHID:0x0(Ref:0)
Route version is 0x4a (74)
Local Label: 0x3e84 (16004)
IP Precedence: Not Set
QoS Group ID: Not Set
Flow-tag: Not Set
Fwd-class: Not Set
Route Priority: RIB_PRIORITY_RECURSIVE (9) SVD Type RIB_SVD_TYPE_LOCAL
Download Priority 3, Download Version 258
No advertising protos.
RP/0/RP0/CPU0:RTR-1# show cef 1.1.1.4/32 detail
Tue Feb 16 17:10:06.956 PST
1.1.1.4/32, version 258, attached, internal 0x1000441 0x30 (ptr 0xd3f0d30) [1], 0x0
(0xe46f960), 0xa20 (0xe9694e0)
Updated Feb 16 17:09:08.328
Prefix Len 32, traffic index 0, precedence n/a, priority 3 gateway array (0xe2d9a08) reference count 2, flags 0x8068, source rib (7), 0 backups
[3 type 4 flags 0x108401 (0xe9aeb98) ext 0x0 (0x0)]
LW-LDI[type=1, refc=1, ptr=0xe46f960, sh-ldi=0xe9aeb98] gateway array update type-time 1 Feb 16 17:07:59.946
LDI Update time Feb 16 17:07:59.946
LW-LDI-TS Feb 16 17:07:59.946
via srte_c_200_ep_1.1.1.4, 5 dependencies, weight 0, class 0 [flags 0xc] path-idx 0 NHID 0x0 [0xf3b1a30 0x0] local adjacency local label 16004 labels imposed {None}
Load distribution: 0 (refcount 3)
Hash OK Interface
0 Y srte_c_200_ep_1.1.1.4
Address point2point
RP/0/RP0/CPU0:RTR-1# show mpls forwarding labels 16004 detail
Tue Feb 16 17:27:59.831 PST
212
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure SR-TE Policies
Autoroute Include
Local Outgoing
Label Label
Prefix or ID
Outgoing
Interface
Next Hop Bytes
Switched
------ ----------- ------------------ ------------ --------------- ------------
16004 Unlabelled SR Pfx (idx 4) srte_c_200_e point2point 990
Updated: Feb 16 17:07:59.945
Path Flags: 0xc [ ]
Version: 258, Priority: 3
Label Stack (Top -> Bottom): { Unlabelled Unlabelled }
NHID: 0x0, Encap-ID: N/A, Path idx: 0, Backup path idx: 0, Weight: 0
MAC/Encaps: 0/0, MTU: 0
Outgoing Interface: srte_c_200_ep_1.1.1.4
(ifhandle 0x0000007c)
Packets Switched: 20
Autoroute Include
Table 19: Feature History Table
Feature Name
Autoroute Include
Release
Release 7.3.2
Description
This feature allows you to steer specific IGP (IS-IS, OSPF) prefixes, or all prefixes, over non-shortest paths and to divert the traffic for those prefixes on to an
SR-TE policy.
You can configure SR-TE policies with Autoroute Include to steer specific IGP (IS-IS, OSPF) prefixes, or all prefixes, over non-shortest paths and to divert the traffic for those prefixes on to the SR-TE policy.
The autoroute include all option applies Autoroute Announce functionality for all destinations or prefixes.
The autoroute include ipv4 address option applies Autoroute Destination functionality for the specified destinations or prefixes. This option is supported for IS-IS only; it is not supported for OSPF.
The Autoroute SR-TE policy adds the prefixes into the IGP, which determines if the prefixes on the endpoint or downstream of the endpoint are eligible to use the SR-TE policy. If a prefix is eligible, then the IGP checks if the prefix is listed in the Autoroute Include configuration. If the prefix is included, then the IGP downloads the prefix route with the SR-TE policy as the outgoing path.
Usage Guidelines and Limitations
• Autoroute Include supports three metric types:
• Default (no metric): The path over the SR-TE policy inherits the shortest path metric.
• Absolute (constant) metric: The shortest path metric to the policy endpoint is replaced with the configured absolute metric. The metric to any prefix that is Autoroute Included is modified to the absolute metric. Use the autoroute metric constant constant-metric command, where constant-metric is from 1 to 2147483647.
• Relative metric: The shortest path metric to the policy endpoint is modified with the relative value configured (plus or minus). Use the autoroute metric relative relative-metric command, where relative-metric is from -10 to +10.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
213
Configure SR-TE Policies
Policy-Based Tunnel Selection for SR-TE Policy
Note To prevent load-balancing over IGP paths, you can specify a metric that is lower than the value that IGP takes into account for autorouted destinations (for example, autoroute metric relative -1 ).
• LDP over SR-TE not supported.
• Static route over SR-TE is not supported.
Configuration Examples
The following example shows how to configure autoroute include for all prefixes:
Router# configure
Router(config)# segment-routing
Router(config-sr)# traffic-eng
Router(config-sr-te)# policy P1
Router(config-sr-te-policy)# color 20 end-point ipv4 1.1.1.2
Router(config-sr-te-policy)# autoroute include all
Router(config-sr-te-policy)# candidate-paths
Router(config-sr-te-policy-path)# preference 100
Router(config-sr-te-pp-index)# explicit segment-list Plist-1
The following example shows how to configure autoroute include for the specified IPv4 prefixes:
Note This option is supported for IS-IS only; it is not supported for OSPF.
Router# configure
Router(config)# segment-routing
Router(config-sr)# traffic-eng
Router(config-sr-te)# policy P1
Router(config-sr-te-policy)# color 20 end-point ipv4 1.1.1.2
Router(config-sr-te-policy)# autoroute include ipv4 1.1.1.21/32
Router(config-sr-te-policy)# autoroute include ipv4 1.1.1.23/32
Router(config-sr-te-policy)# autoroute metric constant 1
Router(config-sr-te-policy)# candidate-paths
Router(config-sr-te-policy-path)# preference 100
Router(config-sr-te-pp-index)# explicit segment-list Plist-1
Policy-Based Tunnel Selection for SR-TE Policy
Policy-Based Tunnel Selection (PBTS) is a mechanism that lets you direct traffic into specific SR-TE policies based on different classification criteria. PBTS benefits Internet service providers (ISPs) that carry voice and data traffic through their networks, who want to route this traffic to provide optimized voice service.
PBTS works by selecting SR-TE policies based on the classification criteria of the incoming packets, which are based on the IP precedence, experimental (EXP), differentiated services code point (DSCP), or type of service (ToS) field in the packet. Default-class configured for paths is always zero (0). If there is no TE for
214
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure SR-TE Policies
Policy-Based Tunnel Selection for SR-TE Policy a given forward-class, then the default-class (0) will be tried. If there is no default-class, then the packet is dropped. PBTS supports up to seven (exp 1 - 7) EXP values associated with a single SR-TE policy.
For more information about PBTS, refer to the "Policy-Based Tunnel Selection" section in the MPLS
Configuration Guide for Cisco NCS 560 Series Routers .
Configure Policy-Based Tunnel Selection for SR-TE Policies
The following section lists the steps to configure PBTS for an SR-TE policy.
Note Steps 1 through 4 are detailed in the "Implementing MPLS Traffic Engineering" chapter of the MPLS
Configuration Guide for Cisco NCS 560 Series Routers .
1.
Define a class-map based on a classification criteria.
2.
Define a policy-map by creating rules for the classified traffic.
3.
Associate a forward-class to each type of ingress traffic.
4.
Enable PBTS on the ingress interface, by applying this service-policy.
5.
Create one or more egress SR-TE policies (to carry packets based on priority) to the destination and associate the egress SR-TE policy to a forward-class.
Configuration Example
Router(config)# segment-routing traffic-eng
Router(config-sr-te)# policy POLICY-PBTS
Router(config-sr-te-policy)# color 1001 end-point ipv4 1.1.1.20
Router(config-sr-te-policy)# autoroute
Router(config-sr-te-policy-autoroute)# include all
Router(config-sr-te-policy-autoroute)# forward-class 1
Router(config-sr-te-policy-autoroute)# exit
Router(config-sr-te-policy)# candidate-paths
Router(config-sr-te-policy-path)# preference 1
Router(config-sr-te-policy-path-pref)# explicit segment-list SIDLIST1
Router(config-sr-te-policy-path-pref)# exit
Router(config-sr-te-pp-info)# exit
Router(config-sr-te-policy-path-pref)# exit
Router(config-sr-te-policy-path)# preference 2
Router(config-sr-te-policy-path-pref)# dynamic
Router(config-sr-te-pp-info)# metric
Router(config-sr-te-path-metric)# type te
Router(config-sr-te-path-metric)# commit
Running Configuration segment-routing traffic-eng policy POLICY-PBTS color 1001 end-point ipv4 1.1.1.20
autoroute include all forward-class 1
!
candidate-paths
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
215
Configure SR-TE Policies
Miscellaneous preference 1 explicit segment-list SIDLIST1
!
!
preference 2 dynamic metric type te
Miscellaneous
SR Policy Liveness Monitoring
SR Policy liveness monitoring allows you to verify end-to-end traffic forwarding over an SR Policy candidate path by periodically sending performance monitoring (PM) packets. The head-end router sends PM packets to the SR policy's endpoint router, which sends them back to the head-end without any control-plane dependency on the endpoint router.
For more information about this feature, see
SR Policy Liveness Monitoring, on page 318 .
Programming Non-Active Candidate Paths of an SR Policy
Table 20: Feature History Table
Feature Name
Programming Non-Active
Candidate Paths of an SR Policy
Release Information
Release 7.6.1
Feature Description
By programming non-active candidate paths (CPs) in the forwarding plane, you ensure that if the existing active CP is unavailable, the traffic switches quickly to the new CP, thus minimizing loss of traffic flow.
In earlier releases, instantiating a non-active CP to the forwarding plane after the unavailability of the active CP could take a few seconds, resulting in potential loss of traffic flow.
This feature introduces the following command:
• max-install-standby-cpaths
An SR Policy is associated with one or more candidate paths (CP). A CP is selected as the active CP when it is valid and it has the highest preference value among all the valid CPs of the SR Policy. By default, only the active CP is programmed in the forwarding plane.
216
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure SR-TE Policies
Programming Non-Active Candidate Paths of an SR Policy
This feature allows the programming of multiple CPs of an SR policy in the forwarding plane. This minimizes traffic loss when a new CP is selected as active.
Usage Guidelines and Limitations
Observe the following usage guidelines and limitations:
• Up to three non-active CPs can be programmed in the forwarding plane.
• Manually configured CPs are supported. This includes CPs with explicit paths or dynamic (head-end computed or PCE-delegated) paths.
• On-Demand instantiated CPs (ODN) are supported.
By default, two ODN CPs are created: PCE-delegated with preference 200 and head-end computed with preference 100. You can use the max-install-standby-cpaths 1 command to program the non-active CP in forwarding. If programming of non-active CPs is enabled for all SR policies (global), you can disable programming of non-active CPs on ODN template using the max-install-standby-cpaths 0 command.
• BGP-initiated CPs are supported.
• PCE-initiated CPs via PCEP are not supported.
• Programming of non-active CPs is not supported with SRv6-TE policies, Per-Flow Policies (PFP), or point-to-multipoint SR policies (Tree-SID)
• PCEP reporting of additional CPs is supported, but the PCEP reporting does not distinguish between active and non-active CPs.
• Programming of non-active CPs can be enabled for all SR policies (global), for a specific policy (local), or ODN template.
If enabled globally and locally or on ODN template, the local or ODN configuration takes precedence over the global configuration.
• The number of policies supported could be impacted by the number of non-active CPs per policy.
Programming non-active CPs in the forwarding plane consumes hardware resources (such as local label and ECMP FEC) when more candidate paths are pre-programmed in forwarding than are actually carrying traffic.
• The active CP will be in programmed state. The remaining CPs will be in standby programmed state.
• We recommend that you create separate PM sessions for active and standby candidate paths to monitor the health of the paths end-to-end.
• The protected paths for each CP is programmed in the respective LSPs. The protected paths of active
CPs are programmed in the active LSP, and the protected paths of standby CPs are programmed in the standby LSP.
• If a candidate path with higher preference becomes available, the traffic will switch to it in
Make-Before-Break (MBB) behavior.
Configuration
Programming of non-active CPs can be enabled for all SR policies (global), for a specific policy (local), or
ODN template.
If enabled globally, the local or ODN configuration takes precedence over the global configuration.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
217
Configure SR-TE Policies
Programming Non-Active Candidate Paths of an SR Policy
Use the max-install-standby-cpaths value command to configure standby candidate paths for all SR policies, for a specific policy, or for an ODN template. The range for value is from 0 (disable) to 3.
The following example shows how to configure standby candidate paths globally:
Router(config)# segment-routing traffic-eng
Router(config-sr-te)# max-install-standby-cpaths 2
Router(config-sr-te)#
Running Config segment-routing traffic-eng max-install-standby-cpaths 2
The following example shows how to configure standby candidate paths for a specific SR policy:
Router(config)# segment-routing traffic-eng
Router(config-sr-te)# policy MyBackupPolicy
Router(config-sr-te-policy)# max-install-standby-cpaths 2
Router(config-sr-te-policy)#
Running Config segment-routing traffic-eng policy MyBackupPolicy max-install-standby-cpaths 2
By default, when you create an ODN template, two CPs are created: PCE-delegated with preference 200 and head-end computed with preference 100. You can use the max-install-standby-cpaths 1 command to program the non-active CP in forwarding.
Note If programming of non-active CPs is enabled for all SR policies (global), you can disable programming of non-active CPs on ODN template using the max-install-standby-cpaths 0 command.
The following example shows how to configure standby candidate paths for an SR ODN template:
Router(config)# segment-routing traffic-eng
Router(config-sr-te)# on-demand color 10
Router(config-sr-te-color)# max-install-standby-cpaths 1
Router(config-sr-te-color)#
Running Config segment-routing traffic-eng on-demand color 10 max-install-standby-cpaths 1
The following example shows how to enable three standby CPs globally and disable standby CPs on SR policy and ODN template:
218
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure SR-TE Policies
Programming Non-Active Candidate Paths of an SR Policy
Router(config)# segment-routing traffic-eng
Router(config-sr-te)# max-install-standby-cpaths 3
Router(config-sr-te)# policy MyBackupPolicy
Router(config-sr-te-policy)# max-install-standby-cpaths 0
Router(config-sr-te-policy)# exit
Router(config-sr-te)# on-demand color 10
Router(config-sr-te-color)# max-install-standby-cpaths 0
Router(config-sr-te-color)#
Verification
The following output shows the status of active and backup CPs:
Router# show segment-routing traffic-eng policy
SR-TE policy database
---------------------
Color: 50, End-point: 1.1.1.4
Name: srte_c_50_ep_1.1.1.4
Status:
Admin: up Operational: up for 08:17:32 (since Sep 9 13:16:02.818)
Candidate-paths:
Preference: 100 (configuration) ( active )
Name: NCP_STATIC
Requested BSID: 5000
PCC info:
Symbolic name: cfg_NCP_STATIC_discr_100
PLSP-ID: 2
Protection Type: protected-preferred
Maximum SID Depth: 10
Explicit: segment-list WORKING (valid)
Reverse: segment-list REVERSE_WORKING
Weight: 1, Metric Type: TE
24010
24012
Preference: 80 (configuration) ( standby )
Name: NCP_STATIC
Requested BSID: 5000
PCC info:
Symbolic name: cfg_NCP_STATIC_discr_80
PLSP-ID: 3
Protection Type: protected-preferred
Maximum SID Depth: 10
Explicit: segment-list STANDBY1 (valid)
Reverse: segment-list REVERSE_STANDBY1
Weight: 1, Metric Type: TE
24018
24010
Preference: 60 (configuration) ( standby )
Name: NCP_STATIC
Requested BSID: 5000
PCC info:
Symbolic name: cfg_NCP_STATIC_discr_60
PLSP-ID: 4
Protection Type: protected-preferred
Maximum SID Depth: 10
Explicit: segment-list STANDBY2 (valid)
Reverse: segment-list REVERSE_STANDBY2
Weight: 1, Metric Type: TE
24014
Preference: 40 (configuration)
Name: NCP_STATIC
Requested BSID: 5000
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
219
Programming Non-Active Candidate Paths of an SR Policy
PCC info:
Symbolic name: cfg_NCP_STATIC_discr_40
PLSP-ID: 5
Protection Type: protected-preferred
Maximum SID Depth: 10
Dynamic (valid)
Metric Type: TE, Path Accumulated Metric: 10
24005 [Adjacency-SID, 13.13.13.1 - 13.13.13.4]
Preference: 30 (configuration)
Name: NCP_STATIC
Requested BSID: 5000
PCC info:
Symbolic name: cfg_NCP_STATIC_discr_30
PLSP-ID: 1
Protection Type: protected-preferred
Maximum SID Depth: 10
Dynamic (pce 1.1.1.4) (valid)
Metric Type: TE, Path Accumulated Metric: 10
24015 [Adjacency-SID, 13.13.13.1 - 13.13.13.4]
Preference: 20 (configuration)
Name: NCP_STATIC
Requested BSID: 5000
PCC info:
Symbolic name: cfg_NCP_STATIC_discr_20
PLSP-ID: 6
Protection Type: protected-preferred
Maximum SID Depth: 10
Explicit: segment-list WORKING2 (valid)
Reverse: segment-list REVERSE_WORKING2
Weight: 1, Metric Type: TE
24012
24012
Preference: 10 (configuration)
Name: NCP_STATIC
Requested BSID: 5000
PCC info:
Symbolic name: cfg_NCP_STATIC_discr_10
PLSP-ID: 7
Protection Type: protected-preferred
Maximum SID Depth: 10
Explicit: segment-list WORKING3 (valid)
Reverse: segment-list REVERSE_WORKING3
Weight: 1, Metric Type: TE
24010
24014
24010
Attributes:
Binding SID: 5000
Forward Class: Not Configured
Steering labeled-services disabled: no
Steering BGP disabled: no
IPv6 caps enable: yes
Invalidation drop enabled: no
Max Install Standby CPaths: 2
Router# show segment-routing traffic-eng forwarding policy
SR-TE Policy Forwarding database
--------------------------------
Color: 50, End-point: 1.1.1.4
Name: srte_c_50_ep_1.1.1.4
Binding SID: 5000
220
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure SR-TE Policies
Configure SR-TE Policies
Programming Non-Active Candidate Paths of an SR Policy
Active LSP:
Candidate path:
Preference: 100 (configuration)
Name: NCP_STATIC
Local label: 24021
Segment lists:
SL[0]:
Name: WORKING
Switched Packets/Bytes: 0/0
Paths:
Path[0]:
Outgoing Label: 24012
Outgoing Interfaces: GigabitEthernet0/0/0/0
Next Hop: 10.10.10.2
Switched Packets/Bytes: 0/0
FRR Pure Backup: No
ECMP/LFA Backup: No
Internal Recursive Label: Unlabelled (recursive)
Label Stack (Top -> Bottom): { 24012 }
Standby LSP(s):
LSP[0]:
Candidate path:
Preference: 80 (configuration)
Name: NCP_STATIC
Local label: 24024
Segment lists:
SL[0]:
Name: STANDBY1
Switched Packets/Bytes: 0/0
Paths:
Path[0]:
Outgoing Label: 24010
Outgoing Interfaces: GigabitEthernet0/0/0/2
Next Hop: 12.12.12.3
Switched Packets/Bytes: 0/0
FRR Pure Backup: No
ECMP/LFA Backup: No
Internal Recursive Label: Unlabelled (recursive)
Label Stack (Top -> Bottom): { 24010 }
LSP[1]:
Candidate path:
Preference: 60 (configuration)
Name: NCP_STATIC
Local label: 24025
Segment lists:
SL[0]:
Name: STANDBY2
Switched Packets/Bytes: 0/0
Paths:
Path[0]:
Outgoing Label: Pop
Outgoing Interfaces: GigabitEthernet0/0/0/3
Next Hop: 13.13.13.4
Switched Packets/Bytes: 0/0
FRR Pure Backup: No
ECMP/LFA Backup: No
Internal Recursive Label: Unlabelled (recursive)
Label Stack (Top -> Bottom): { Pop }
Policy Packets/Bytes Switched: 2/136
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
221
Configure SR-TE Policies
LDP over Segment Routing Policy
LDP over Segment Routing Policy
The LDP over Segment Routing Policy feature enables an LDP-targeted adjacency over a Segment Routing
(SR) policy between two routers. This feature extends the existing MPLS LDP address family neighbor configuration to specify an SR policy as the targeted end-point.
LDP over SR policy is supported for locally configured SR policies with IPv4 end-points.
For more information about MPLS LDP, see the "Implementing MPLS Label Distribution Protocol" chapter in the MPLS Configuration Guide .
For more information about Autoroute, see the Autoroute Announce for SR-TE section.
Note Before you configure an LDP targeted adjacency over SR policy name, you need to create the SR policy under
Segment Routing configuration. The SR policy interface names are created internally based on the color and endpoint of the policy. LDP is non-operational if SR policy name is unknown.
The following functionality applies:
1.
Configure the SR policy – LDP receives the associated end-point address from the interface manager (IM) and stores it in the LDP interface database (IDB) for the configured SR policy.
2.
Configure the SR policy name under LDP – LDP retrieves the stored end-point address from the IDB and uses it. Use the auto-generated SR policy name assigned by the router when creating an LDP targeted adjacency over an SR policy. Auto-generated SR policy names use the following naming convention:
srte_c_color_val_ep_endpoint-address . For example, srte_c_1000_ep_1.1.1.2
Configuration Example
/* Enter the SR-TE configuration mode and create the SR policy. This example corresponds to a local SR policy with an explicit path. */
Router(config)# segment-routing
Router(config-sr)# traffic-eng
Router(config-sr-te)# segment-list sample-sid-list
Router(config-sr-te-sl)# index 10 address ipv4 1.1.1.7
Router(config-sr-te-sl)# index 20 address ipv4 1.1.1.2
Router(config-sr-te-sl)# exit
Router(config-sr-te)# policy sample_policy
Router(config-sr-te-policy)# color 1000 end-point ipv4 1.1.1.2
Router(config-sr-te-policy)# candidate-paths
Router(config-sr-te-policy-path)# preference 100
Router(config-sr-te-policy-path-pref)# explicit segment-list sample-sid-list
Router(config-sr-te-pp-info)# end
/* Configure LDP over an SR policy */
Router(config)# mpls ldp
Router(config-ldp)# address-family ipv4
Router(config-ldp-af)# neighbor sr-policy srte_c_1000_ep_1.1.1.2 targeted
Router(config-ldp-af)#
222
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure SR-TE Policies
LDP over Segment Routing Policy
Note Do one of the following to configure LDP discovery for targeted hellos:
• Active targeted hellos (SR policy head end): mpls ldp interface GigabitEthernet0/0/0/0
!
!
• Passive targeted hellos (SR policy end-point): mpls ldp address-family ipv4 discovery targeted-hello accept
!
!
Running Configuration segment-routing traffic-eng segment-list sample-sid-list index 10 address ipv4 1.1.1.7
index 20 address ipv4 1.1.1.2
!
policy sample_policy
!
!
color 1000 end-point ipv4 1.1.1.2
candidate-paths preference 100
!
!
!
explicit segment-list sample-sid-list
!
mpls ldp address-family ipv4 neighbor sr-policy srte_c_1000_ep_1.1.1.2 targeted discovery targeted-hello accept
!
!
Verification
Router# show mpls ldp interface brief
Interface VRF Name Config Enabled IGP-Auto-Cfg TE-Mesh-Grp cfg
--------------- ------------------- ------ ------- ------------ ---------------
Te0/3/0/0/3 default Y Y 0 N/A
Te0/3/0/0/6
Te0/3/0/0/7
Te0/3/0/0/8
Te0/3/0/0/9 srte_c_1000_ default default default default default
Y
Y
N
N
Y
Y
Y
N
N
Y
0
0
0
0
0
N/A
N/A
N/A
N/A
N/A
Router# show mpls ldp interface
Interface TenGigE0/3/0/0/3 (0xa000340)
VRF: 'default' (0x60000000)
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
223
LDP over Segment Routing Policy
Enabled via config: LDP interface
Interface TenGigE0/3/0/0/6 (0xa000400)
VRF: 'default' (0x60000000)
Enabled via config: LDP interface
Interface TenGigE0/3/0/0/7 (0xa000440)
VRF: 'default' (0x60000000)
Enabled via config: LDP interface
Interface TenGigE0/3/0/0/8 (0xa000480)
VRF: 'default' (0x60000000)
Disabled:
Interface TenGigE0/3/0/0/9 (0xa0004c0)
VRF: 'default' (0x60000000)
Disabled:
Interface srte_c_1000_ep_1.1.1.2 (0x520)
VRF: 'default' (0x60000000)
Enabled via config: LDP interface
Router# show segment-routing traffic-eng policy color 1000
SR-TE policy database
---------------------
Color: 1000, End-point: 1.1.1.2
Name: srte_c_1000_ep_1.1.1.2
Status:
Admin: up Operational: up for 00:02:00 (since Jul 2 22:39:06.663)
Candidate-paths:
Preference: 100 (configuration) (active)
Name: sample_policy
Requested BSID: dynamic
PCC info:
Symbolic name: cfg_sample_policy_discr_100
PLSP-ID: 17
Explicit: segment-list sample-sid-list (valid)
Weight: 1, Metric Type: TE
16007 [Prefix-SID, 1.1.1.7]
16002 [Prefix-SID, 1.1.1.2]
Attributes:
Binding SID: 80011
Forward Class: 0
Steering BGP disabled: no
IPv6 caps enable: yes
Router# show mpls ldp neighbor 1.1.1.2 detail
Peer LDP Identifier: 1.1.1.2:0
TCP connection: 1.1.1.2:646 - 1.1.1.6:57473
Graceful Restart: No
Session Holdtime: 180 sec
State: Oper; Msgs sent/rcvd: 421/423; Downstream-Unsolicited
Up time: 05:22:02
LDP Discovery Sources:
IPv4: (1)
Targeted Hello (1.1.1.6 -> 1.1.1.2, active/passive)
IPv6: (0)
Addresses bound to this peer:
IPv4: (9)
1.1.1.2
10.2.4.2
2.2.2.99
10.2.22.2
10.1.2.2
10.2.222.2
10.2.3.2
10.30.110.132
11.2.9.2
IPv6: (0)
Peer holdtime: 180 sec; KA interval: 60 sec; Peer state: Estab
Configure SR-TE Policies
224
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure SR-TE Policies
SR-TE MPLS Label Imposition Enhancement
NSR: Disabled
Clients: LDP over SR Policy
Capabilities:
Sent:
0x508 (MP: Point-to-Multipoint (P2MP))
0x509 (MP: Multipoint-to-Multipoint (MP2MP))
0x50a (MP: Make-Before-Break (MBB))
0x50b (Typed Wildcard FEC)
Received:
0x508 (MP: Point-to-Multipoint (P2MP))
0x509 (MP: Multipoint-to-Multipoint (MP2MP))
0x50a (MP: Make-Before-Break (MBB))
0x50b (Typed Wildcard FEC)
SR-TE MPLS Label Imposition Enhancement
The SR-TE MPLS Label Imposition Enhancement feature increases the maximum label imposition capabilities of the platform.
In previous releases, the platform supported:
• Up to 5 MPLS transport labels when no MPLS service labels are imposed
• Up to 3 MPLS transport labels when MPLS service labels are imposed
With the SR-TE MPLS Label Imposition Enhancement feature, the platform supports the following:
• Up to 12 MPLS transport labels when no MPLS service labels are imposed
• Up to 9 MPLS transport labels when MPLS service labels are imposed
This enhancement is enabled and disabled dynamically, as the label count changes. For example, if a path requires only 3 MPLS transport labels, the MPLS Label Imposition Enhancement feature is not enabled.
You can disable labeled services for SR-TE policies. The label switching database (LSD) needs to know if labeled services are disabled on top of an SR-TE policy to perform proper label stack splitting.
Disable Labeled Services per Local Policy
Use the labeled-services disable command to disable steering for labeled services for a configured policy.
This configuration applies per policy.
segment-routing traffic-eng policy policy name steering labeled-services disable
Disable Labeled Services per ODN color
Use the labeled-services disable command to disable steering of labeled-services for on-demand color policies.
This configuration applies for a specific ODN color.
segment-routing traffic-eng on-demand color color steering labeled-services disable
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
225
Configure SR-TE Policies
SR-TE MPLS Label Imposition Enhancement
Disable Labeled Services per Policy Type
Use the labeled-services disable command to disable steering of labeled services for all policies for the following policy types:
• all — all policies
• local — all locally configured policies
• on-demand — all BGP on-demand color policies
• bgp-srte — all controller-initiated BGP SR-TE policies
• pcep — all PCE-initiated policies
Note You can specify more than one policy type.
segment-routing traffic-eng steering labeled-services disable { all | local | on-demand | bgp-srte | pcep }
Verification
Use the show segment-routing traffic-eng policy command to display SR policy information. The following output shows that steering of labeled services for the on-demand SR policy are disabled.
Router# show segment-routing traffic-eng policy color 10
Thu Jul 18 11:35:25.124 PDT
SR-TE policy database
---------------------
Color: 10, End-point: 1.1.1.8
Name: srte_c_10_ep_1.1.1.8
Status:
Admin: up Operational: up for 00:00:06 (since Jul 18 11:35:19.350)
Candidate-paths:
Preference: 1 (configuration) (active)
Name: test_pol_2
Requested BSID: dynamic
Dynamic (valid)
Metric Type: TE, Path Accumulated Metric: 10
24004 [Adjacency-SID, 1.1.1.1 - 1.1.1.2]
Attributes:
Binding SID: 24011
Forward Class: 0
Steering labeled-services disabled: yes
Steering BGP disabled: no
IPv6 caps enable: yes
226
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure SR-TE Policies
Path Invalidation Drop
Path Invalidation Drop
Table 21: Feature History Table
Feature Name
Path Invalidation Drop
Release Information
Release 7.4.1
Feature Description
By default, if an SR Policy becomes invalid (for example, if there is no valid candidate path available), traffic falls back to the native SR forwarding path. In some scenarios, a network operator may require that certain traffic be only carried over the path associated with an SR policy and never allow the native SR LSP to be used.
This feature allows the SR policy to stay up in the control plane (to prevent prefixes mapped to the SR policy from falling back to the native SR LSP) but drop the traffic sent on the SR policy.
By default, if an SR Policy becomes invalid, traffic would fall back to the native SR forwarding path.
In some scenarios, a network operator may require that certain traffic be only carried over the path associated with an SR policy and never allow the native SR LSP to be used. The SR-TE Path Invalidation Drop feature is introduced to meet this requirement.
With the Path Invalidation Drop feature enabled, an SR policy that would become invalid (for example, no valid candidate path available) is programmed to drop traffic. At the same time, the SR policy stays up in the control plane to prevent prefixes mapped to the SR policy from falling back to the native SR LSP.
When the SR policy becomes valid again, forwarding over the SR policy resumes.
Note This feature takes effect when an SR policy transitions from valid to invalid; it does not take effect when an
SR policy has never been declared valid.
Enable Path Invalidation Drop for Manual SR Policy
Use the segment-routing traffic-eng policy name steering path-invalidation drop command to enable the dropping of traffic when an SR Policy becomes invalid.
segment-routing traffic-eng policy foo steering path-invalidation drop
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
227
Configure SR-TE Policies
Path Invalidation Drop
Enable Path Invalidation Drop for On-Demand SR Policy
Use the segment-routing traffic-eng on-demand color color steering path-invalidation drop command
(where color is from 1 to 4294967295) to enable the dropping of traffic when an On-Demand SR Policy becomes invalid.
segment-routing traffic-eng on-demand color 10 steering path-invalidation drop
Enable Path Invalidation Drop for PCE-Initiated SR Policy
Use the segment-routing traffic-eng pcc profile profile steering path-invalidation drop command (where profile is from 1 to 65534) to enable the dropping of traffic when a PCE-Initiated SR Policy becomes invalid.
segment-routing traffic-eng pcc profile 7 steering path-invalidation drop
Verification
Use the show segment-routing traffic-eng policy command to display SR policy information.
The following output shows an SR policy in the Up state with path-invalidation drop:
Router# show segment-routing traffic-eng policy
SR-TE policy database
-------------------------
Color: 4, End-point: 1.1.1.4
Name: srte_c_4_ep_1.1.1.4
Status:
Admin: up Operational: up(path-invalidation drop) for 00:09:02 (since May 19
12:07:14.526)
Candidate-paths:
Preference: 200 (BGP ODN) (shutdown)
Requested BSID: dynamic
Protection Type: protected-preferred
Maximum SID Depth: 10
Dynamic (invalid)
Metric Type: TE, Path Accumulated Metric: 0
Preference: 100 (BGP ODN) (active)
Requested BSID: dynamic
PCC info:
Symbolic name: bgp_c_4_ep_1.1.1.4_discr_100
PLSP-ID: 1
Protection Type: protected-preferred
Maximum SID Depth: 10
Dynamic (pce) (invalid)
Last error: No path
Metric Type: TE, Path Accumulated Metric: 40
Attributes:
Binding SID: 24015
Forward Class: Not Configured
Steering labeled-services disabled: no
228
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure SR-TE Policies
Path Invalidation Drop
Steering BGP disabled: no
IPv6 caps enable: yes
Invalidation drop enabled: yes
Router# show segment-routing traffic-eng policy detail
SR-TE policy database
---------------------
Color: 4, End-point: 1.1.1.4
Name: srte_c_4_ep_1.1.1.4
Status:
Admin: up Operational: up for 00:09:02 (since May 19 12:07:14.526)
Candidate-paths:
Preference: 100 (BGP ODN) (active)
Name: test1
Requested BSID: dynamic
Protection Type: protected-only
Maximum SID Depth: 10
Explicit: segment-list list1 (invalid)
Last error: No path
Weight: 1, Metric Type: TE
LSPs:
LSP[0]:
LSP-ID: 4 policy ID: 2 (active)
Local label: 24025
State: Invalidated traffic dropped
Binding SID: 24029
Attributes:
Binding SID: 24015
Forward Class: Not Configured
Steering labeled-services disabled: no
Steering BGP disabled: no
IPv6 caps enable: yes
Invalidation drop enabled: yes
When the policy is in "Invalidated traffic dropped" state, as observed in the output above, use the show mpls forwarding tunnels detail command to display the forwarding information. The following output shows that the traffic is dropped with forwarding output indicating "Control plane programmed to drop".
Router# show mpls forwarding tunnels detail
Tunnel
Name
Outgoing
Label
Outgoing
Interface
Next Hop Bytes
Switched
-------------------------- ----------- ------------ --------------- -----------srte_c_4_ep_1.1.1.4(SR) ?
?
?
?
Tunnel resolution: Incomplete (Control plane programmed to drop)
Interface:
Name: srte_c_4_ep_1.1.1.4 (ifhandle 0x000040f0)
Local Label: 24025, Forwarding Class: 0, Weight: 0
Packets/Bytes Switched: 0/0
Configuring Path Invalidation Drop with Performance Measurement Liveness Detection
The Path Invalidation Drop feature can work alongside the invalidation-action down configuration in the
Performance Measurement Liveness Detection feature. The Performance Measurement Liveness Detection feature enables end-to-end SR policy liveness detection for all segment lists of the active and standby candidate paths that are in the forwarding table. When invalidation-action down is configured and a candidate path becomes invalid, the candidate path is immediately operationally brought down and becomes invalid.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
229
Configure SR-TE Policies
SR-TE Reoptimization Timers
See
SR Policy Liveness Monitoring, on page 318
for information about configuring liveness detection and the invalidation action.
When both path-invalidation drop and performance-measurement liveness-detection invalidation-action down are enabled, the following behavior is observed:
1.
If the PM liveness session goes down, the candidate path becomes invalid and is immediately operationally brought down.
2.
SR-TE path re-optimization occurs to find a new valid candidate path.
3.
If no valid candidate path is found, the SR policy is kept UP in the control plane, but the traffic sent on the SR policy is dropped.
SR-TE Reoptimization Timers
SR-TE path re-optimization occurs when the head-end determines that there is a more optimal path available than the one currently used. For example, in case of a failure along the SR-TE LSP path, the head-end could detect and revert to a more optimal path by triggering re-optimization.
Re-optimization can occur due to the following events:
• The explicit path hops used by the primary SR-TE LSP explicit path are modified
• The head-end determines the currently used path-option are invalid due to either a topology path disconnect, or a missing SID in the SID database that is specified in the explicit-path
• A more favorable path-option (lower index) becomes available
For event-based re-optimization, you can specify various delay timers for path re-optimization. For example, you can specify how long to wait before switching to a reoptimized path
Additionally, you can configure a timer to specify how often to perform reoptimization of policies. You can also trigger an immediate reoptimization for a specific policy or for all policies.
SR-TE Reoptimization
To trigger an immediate SR-TE reoptimization, use the segment-routing traffic-eng reoptimization command in Exec mode:
Router# segment-routing traffic-eng reoptimization { all | name policy }
Use the all option to trigger an immediate reoptimization for all policies. Use the name policy option to trigger an immediate reoptimization for a specific policy.
Configuring SR-TE Reoptimization Timers
Use these commands in SR-TE configuration mode to configure SR-TE reoptimization timers:
• timers candidate-path cleanup-delay seconds —Specifies the delay before cleaning up candidate paths, in seconds. The range is from 0 (immediate clean-up) to 86400; the default value is 120
• timers cleanup-delay seconds —Specifies the delay before cleaning up previous path, in seconds. The range is from 0 (immediate clean-up) to 300; the default value is 10.
230
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure SR-TE Policies
SR-TE Reoptimization Timers
• timers init-verify-restart seconds —Specifies the delay for topology convergence after the topology starts populating due to a restart, in seconds. The range is from 10 to 10000; the default is 40.
• timers init-verify-startup seconds —Specifies the delay for topology convergence after topology starts populating for due to startup, in seconds. The range is from 10 to 10000; the default is 300
• timers init-verify-switchover seconds —Specifies the delay for topology convergence after topology starts populating due to a switchover, in seconds. The range is from 10 to 10000; the default is 60.
• timers install-delay seconds —Specifies the delay before switching to a reoptimized path, in seconds.
The range is from 0 (immediate installation of new path) to 300; the default is 10.
• timers periodic-reoptimization seconds —Specifies how often to perform periodic reoptimization of policies, in seconds. The range is from 0 to 86400; the default is 600.
Example Configuration
Router(config)# segment-routing traffic-eng
Router(config-sr-te)# timers
Router(config-sr-te-timers)# candidate-path cleanup-delay 600
Router(config-sr-te-timers)# cleanup-delay 60
Router(config-sr-te-timers)# init-verify-restart 120
Router(config-sr-te-timers)# init-verify-startup 600
Router(config-sr-te-timers)# init-verify-switchover 30
Router(config-sr-te-timers)# install-delay 60
Router(config-sr-te-timers)# periodic-reoptimization 3000
Running Config segment-routing traffic-eng timers install-delay 60 periodic-reoptimization 3000 cleanup-delay 60 candidate-path cleanup-delay 600
!
!
!
init-verify-restart 120 init-verify-startup 600 init-verify-switchover 30
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
231
SR-TE Reoptimization Timers
Configure SR-TE Policies
232
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
C H A P T E R
8
Segment Routing Tree Segment Identifier
Tree Segment Identifier (Tree-SID) is a tree-building solution that uses a Segment Routing Path Computation
Element (SR-PCE) using path computation element protocol (PCEP) to calculate the point-to-multipoint
(P2MP) tree using SR policies. Tree-SID uses a single MPLS label for building a multicast replication tree in an SR network. Tree-SID does not require multicast control protocols such as RSVP, mLDP, and PIM.
A P2MP SR policy provides an SR-based TE solution for transporting multicast traffic. It works on existing data-plane (MPLS and IP) and supports TE capabilities and single/multi routing domains. At each node of the tree, the forwarding state is represented by the same segment (using a global Tree-SID specified from the
SRLB range of labels). P2MP SR policy prevents transient loop and packet loss when updating the path of a
P2MP SR policy.
A P2MP SR policy request contains the following:
• Policy name
• SID for the P2MP Tree (Tree-SID)
• Address of the root node
• Addresses of the leaf nodes
• Optimization objectives (TE, IGP metric)
• Constraints (affinity)
Tree SID Workflow Overview
This sections shows a basic workflow using a Tree SID policy:
1.
User creates a Tree-SID policy.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
233
2.
SR-PCE computes the P2MP Tree.
234
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Segment Routing Tree Segment Identifier
Segment Routing Tree Segment Identifier
3.
SR-PCE instantiates the Tree-SID state at each node in the tree.
4.
The Root node encapsulates the multicast traffic, replicates it, and forwards it to the Transit nodes.
5.
The Transit nodes replicate the multicast traffic and forward it to the Leaf nodes.
6.
The Leaf nodes decapsulate the multicast traffic and forward it to the multicast receivers.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
235
Bud Node Support
Segment Routing Tree Segment Identifier
•
•
Configure Segment Routing Tree-SID, on page 237
•
•
Multicast VPN: Tree-SID MVPN With TI-LFA, on page 240
Bud Node Support
In a multicast distribution tree, a Bud node is a node that acts as a leaf (egress) node as well as a mid-point
(transit) node toward the downstream sub-tree.
In the below multicast distribution tree topology with Root node {A} and Leaf nodes set {B, C, D}, node D is a Bud node. Similarly, if node E is later added to the Leaf set, it would also become a Bud node.
236
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Segment Routing Tree Segment Identifier
Configure Segment Routing Tree-SID
The tree computation algorithm on SR-PCE has been enhanced to detect a Bud node based on knowledge of the Leaf set, and to handle Leaf/Transit node transitions to Bud node. The role of the Bud node is also explicitly signaled in PCEP.
Configure Segment Routing Tree-SID
To configure Segment Routing Tree-SID for Point-to-Multipoint (P2MP) SR policies, complete the following configurations:
1.
Configure Path Computation Element Protocol (PCEP) Path Computation Client (PCC) on all nodes involved in the Tree-SID path (root, mid-point, leaf)
2.
Configure Affinity Maps on the SR-PCE
3.
Configure P2MP SR Policy on SR-PCE
4.
Configure Multicast on the Root and Leaf Nodes
Configure PCEP PCC on All Nodes in Tree-SID Path
Configure all nodes involved in the Tree-SID path (root, mid-point, leaf) as PCEP PCC. For detailed PCEP
PCC configuration information, see
Configure the Head-End Router as PCEP PCC, on page 188
.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
237
Segment Routing Tree Segment Identifier
Configure Segment Routing Tree-SID
Configure Affinity Maps on the SR-PCE
Use the affinity bit-map COLOR bit-position command in PCE SR-TE sub-mode to define affinity maps.
The bit-position range is from 0 to 255.
Router# configure
Router(config)# pce
Router(config-pce)# segment-routing traffic-eng
Router(config-pce-sr-te)# affinity bit-map RED 23
Router(config-pce-sr-te)# affinity bit-map BLUE 24
Router(config-pce-sr-te)# affinity bit-map CROSS 25
Router(config-pce-sr-te)#
Configure P2MP SR Policy on SR-PCE
Configure the end-point name and addresses, Tree-SID label, and constraints for the P2MP policy.
Use the endpoint-set NAME command in SR-PCE P2MP sub-mode to enter the name of the end-point set and to define the set of end-point addresses.
Router(config-pce-sr-te)# p2mp
Router(config-pce-sr-te-p2mp)# endpoint-set BAR
Router(config-pce-p2mp-ep-set)# ipv4 1.1.1.2
Router(config-pce-p2mp-ep-set)# ipv4 1.1.1.3
Router(config-pce-p2mp-ep-set)# ipv4 1.1.1.4
Router(config-pce-p2mp-ep-set)# exit
Router(config-pce-sr-te-p2mp)#
Use the policy policy command to configure the P2MP policy name and enter P2MP Policy sub-mode.
Configure the source address, endpoint-set color, Tree-SID label, affinity constraints, and metric type.
Router(config-pce-sr-te-p2mp)# policy FOO
Router(config-pce-p2mp-policy)# source ipv4 1.1.1.6
Router(config-pce-p2mp-policy)# color 10 endpoint-set BAR
Router(config-pce-p2mp-policy)# treesid mpls 15200
Router(config-pce-p2mp-policy)# candidate-paths
Router(config-pce-p2mp-policy-path)# constraints
Router(config-pce-p2mp-path-const)# affinity
Router(config-pce-p2mp-path-affinity)# exclude BLUE
Router(config-pce-p2mp-path-affinity)# exit
Router(config-pce-p2mp-path-const)# exit
Router(config-pce-p2mp-policy-path)# preference 100
Router(config-pce-p2mp-policy-path-preference)# dynamic
Router(config-pce-p2mp-path-info)# metric type te
Router(config-pce-p2mp-path-info)# root
Router(config)#
Configure Multicast on the Root and Leaf Nodes
On the root node of the SR P2MP segment, use the router pim command to enter Protocol Independent
Multicast (PIM) configuration mode to statically steer multicast flows into an SR P2MP policy.
Note Enter this configuration only on an SR P2MP segment. Multicast traffic cannot be steered into a P2P policy.
Router(config)# router pim
Router(config-pim)# vrf name
Router(config-pim-name)# address-family ipv4
Router(config-pim-name-ipv4)# sr-p2mp-policy FOO
238
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Segment Routing Tree Segment Identifier
Running Config
Router(config-pim-name-ipv4-srp2mp)# static-group 235.1.1.5 1.1.1.6
Router(config-pim-name-ipv4-srp2mp)# root
Router(config)#
On the root and leaf nodes of the SR P2MP tree, use the mdt static segment-routing command to configure the multicast distribution tree (MDT) core as Tree-SID from the multicast VRF configuration submode.
Router(config)# multicast-routing
Router(config-mcast)# vrf TEST
Router(config-mcast-TEST)# address-family ipv4
Router(config-mcast-TEST-ipv4)# mdt static segment-routing
On the leaf nodes of an SR P2MP segment, use the static sr-policy p2mp-policy command to configure the static SR P2MP Policy from the multicast VRF configuration submode to statically decapsulate multicast flows.
Router(config)# multicast-routing
Router(config-mcast)# vrf TEST
Router(config-mcast-TEST)# address-family ipv4
Router(config-mcast-TEST-ipv4)# static sr-policy FOO
Running Config
The following example shows how to configure the end point addresses and P2MP SR policy with affinity constraints on SR-PCE.
pce segment-routing traffic-eng affinity bit-map
RED 23
BLUE 24
!
CROSS 25 p2mp endpoint-set BAR ipv4 1.1.1.2
!
ipv4 1.1.1.3
ipv4 1.1.1.4
policy FOO source ipv4 1.1.1.6
color 10 endpoint-set BAR treesid mpls 15200 candidate-paths preference 100 dynamic metric type te
!
!
!
constraints affinity exclude
!
BLUE
!
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
239
Segment Routing Tree Segment Identifier
Multicast VPN: Tree-SID MVPN With TI-LFA
!
!
!
!
!
!
!
The following example shows how to statically decapsulate multicast flows on the leaf nodes.
multicast-routing vrf TEST address-family ipv4 static sr-policy FOO
!
!
!
The following example shows to configure the multicast distribution tree (MDT) core as Tree-SID on the root and leaf nodes.
multicast-routing vrf TEST address-family ipv4
!
mdt static segment-routing
!
!
The following example shows how to steer traffic to the SR P2MP policy on the root node.
router pim vrf TEST address-family ipv4
!
!
sr-p2mp-policy FOO static-group 232.1.1.5 1.1.1.6
!
!
Multicast VPN: Tree-SID MVPN With TI-LFA
Table 22: Feature History Table
Feature Name Release
Information
Feature Description
Multicast VPN:
Tree-SID MVPN With
TI-LFA
Release
7.3.1
With this feature, you can use SR and MVPN for optimally transporting IP VPN multicast traffic over the SP network, using
SR-PCE as a controller.
With SR’s minimal source router configuration requirement, its ability to implement policies with specific optimization objectives and constraints, protect against network failures using TI-LFA FRR mechanism, and use SR-PCE to dynamically generate optimal multicast trees (including when topology changes occur in the multicast tree), the SR-enabled SP network can transport IP multicast traffic efficiently.
240
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Segment Routing Tree Segment Identifier
Multicast VPN: Tree-SID MVPN With TI-LFA
Prerequisites for Multicast VPN: Tree-SID MVPN With TI-LFA
• The underlay OSPF/IS-IS network is configured, and OSPF/IS-IS adjacency is formed between routers, across the network.
• BGP is configured for the network, and BGP adjacency is formed between routers. BGP MVPN configuration information is provided in this feature document.
• To understand the benefits, know-how, and configuration of SR and SR-TE policies, see About Segment
Routing and Configure SR-TE Policies.
Information About Multicast VPN: Tree-SID MVPN With TI-LFA
Typically, a customer’s IP VPN is spread across VPN sites. IP VPN customer traffic is sent from one site to another over a VPN Service Provider (SP) network.
When IP multicast traffic within a (BGP/MPLS) IP VPN is transported over an SP network (say, from
VPN1-Site-A to VPN1-Site-B , as shown in the image), the SP network requires protocols and procedures to optimally transport multicast traffic from a multicast sender in Site-A to multicast receivers in Site-B.
This use case explains how to enable SR multicast for an SP network, and efficiently transport IP VPN multicast traffic (sent from VPN1-Site-A and) received at PE router A, through to PE routers D and E, towards receivers in sites VPN1-Site-B and VPN1-Site-C .
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
241
Multicast VPN: Tree-SID MVPN With TI-LFA
Figure 14: IP VPN Multicast Traffic Flow Over An SP Network
Segment Routing Tree Segment Identifier
To enable the Multicast VPN: Tree-SID MVPN With TI-LFA feature, the following protocols and software applications are used.
OSPF/IS-IS - The underlay network is created with OSPF/IS-IS routing protocol, and reachability is established across the network. See Configure Segment Routing for IS-IS Protocol or Configure Segment Routing for
OSPF Protocol chapter for details.
BGP Multicast VPN (MVPN) – The PE routers (A, D, and E) are IP VPN end-points for IP multicast traffic arriving at the SP network (at PE router A) and exiting the SP network (at PE routers D and E). So, BGP
MVPN is enabled on the PE routers. NSO is used to configure BGP MVPN on the PE routers.
BGP Auto-Discovery (AD) - To enable distributed VPN end-point discovery and C-multicast flow mapping and signalling, BGP AD function is configured on the PE routers. A BGP Auto-Discovery route contains multicast router (loopback IP address) and tree identity (segment ID) information. It carries the information in the Provider Multicast Service Interface (PMSI) Tunnel Attribute (PTA).
C-multicast states are signaled using BGP.
242
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Segment Routing Tree Segment Identifier
Multicast VPN: Tree-SID MVPN With TI-LFA
SR - To transport IP multicast traffic between the VPN end-points (PE routers A, D, and E), Provider (or P-) tunnels are used. In a P-tunnel, the PE devices are the tunnel end-points. P-tunnels can be generated using different technologies (RSVP-TE, P2MP LSPs, PIM trees, mLDP P2MP LSPs, and mLDP MP2MP LSPs).
In this use case, Segment Routing (SR) is used for its benefits that were noted earlier.
With SR and SR-PCE, a Tree-SID Point-to-Multipoint (P2MP) segment is used to create P-Tunnels for MVPN.
You can specify SR policy optimization objectives (such as metrics ) and constraints (such as affinity ) in an
SR policy and send it to the SR-PCE controller, so that it can dynamically create SR multicast trees for traffic flow.
SR-PCE - This is a controller which, based on the provided SR policy information, computes optimal paths for a multicast tree, and deploys the tree forwarding state on the multicast routers. When a topology change occurs, SR-PCE automatically computes a new, optimal multicast tree, and deploys the new tree forwarding state on the multicast routers.
TI-LFA - In SR-TE, Topology-Independent Loop-Free Alternate (TI-LFA) fast reroute (FRR) function is used to reduce link and node failure reaction time. When the primary next-hop (router link) fails, a pre-computed alternate next hop is used to send traffic. TI-LFA FRR is used when transporting IP VPN multicast traffic.
Overview of Multicast VPN: Tree-SID MVPN With TI-LFA
The following sections provide an overview of Tree-SID MVPN and TI-LFA. The topology remains the same, with PE routers A, D, and E acting as VPN end-points for carrying IP VPN multicast traffic.
Tree-SID MVPN Overview
1.
For SR, A is designated as the SR head-end router, and D and E are designated as the SR end-points.
For multicast traffic, A is the root of the SR multicast tree, and D and E are leaf routers of the tree. B and
C are the other multicast routers. The objective is to send the IP multicast traffic arriving at A to D and
E, as needed
Figure 15: Multicast Tree
2.
A discovers leaf routers’ information through BGP MVPN.
3.
Path Computation Element Protocol (PCEP) is used for the SR multicast policy communication between
A and the SR-PCE server, and communication between PE routers and the SR-PCE server.
4.
When the head-end router SR policy is created on A, and PCEP configurations are enabled on the SR-PCE server and all multicast routers, SR-PCE receives the SR policy and leaf router identity information from
A.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
243
Segment Routing Tree Segment Identifier
Multicast VPN: Tree-SID MVPN With TI-LFA
5.
Based on the policy information it receives, including TE objectives and constraints, SR-PCE builds multicast distribution trees in the underlay for efficient VPN traffic delivery.
6.
SR-PCE assigns an SID for the SR multicast tree policy, and deploys the multicast tree forwarding state on the multicast routers.
7.
When IP multicast traffic is sent from VPN1-SiteA to PE router A, it steers it into the SR policy, and sends it towards D and E, which forward it to multicast traffic receivers in the sites VPN1-SiteB and
VPN1-SiteC.
8.
When a leaf/multicast router is added or removed, PE router A updates the SR multicast policy and sends it to SR-PCE. SR-PCE computes new multicast routes, and deploys the multicast tree forwarding state information on the multicast routers.
244
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Segment Routing Tree Segment Identifier
Multicast VPN: Tree-SID MVPN With TI-LFA
TI-LFA FRR Overview
High-level TI-LFA FRR function is depicted in these steps:
1.
Tree-SID FRR state information.
• The link from A to B is protected.
• SID 16002 is the node SID of B.
• A programs a backup path to B, through C.
2.
IP multicast traffic arrives at A which steers the flow onto the tree.
3.
A encapsulates and replicates to B, but the link to B is down.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
245
Multicast VPN: Tree-SID MVPN With TI-LFA
Segment Routing Tree Segment Identifier
4.
A sends the traffic on the backup path, to C.
5.
C sends the traffic to B where normal traffic processing resumes.
SR Multicast Tree Types
This is an overview of the types of SR multicast trees you can configure, depending on your requirement.
You can create a full mesh, on-demand, or optimal multicast tree for IP VPN multicast flow in the SP network.
246
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Segment Routing Tree Segment Identifier
Figure 16: Full Mesh Multicast Tree
Multicast VPN: Tree-SID MVPN With TI-LFA
1.
A assigns Tree-ID 10 and invokes a Create an SR multicast tree request by sending the multicast router and tree ID information (A, 10) towards SR-PCE.
2.
A announces BGP AD Inclusive PMSI (I-PMSI) route with the PTA (A, 10). Inclusive PMSI - Traffic that is multicast by a PE router on an I-PMSI is received by all other PEs in the MVPN. I-PMSIs are generated by Inclusive P-tunnels .
3.
A discovers VPN endpoints D and E from their BGP AD Type I-PMSI route messages.
4.
A invokes an Add SR multicast leaf router request (for D and E) to SR-PCE.
5.
SR-PCE computes and generates the multicast tree forwarding state information on all the routers that are part of the tree.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
247
Multicast VPN: Tree-SID MVPN With TI-LFA
Figure 17: On-Demand SR Multicast Tree
Segment Routing Tree Segment Identifier
1.
A assigns Tree-ID 20 and invokes a Create an SR multicast tree request by sending the multicast router and tree ID information (A, 20) towards SR-PCE.
2.
A announces BGP AD Selective PMSI (or S-PMSI) route with PTA (A, 20). A sets the leaf-info-required to discover endpoint interest set.
Selective PMSI - Traffic multicast by a PE on an S-PMSI is received by some PEs in the MVPN. S-PMSIs are generated by Selective P-tunnels.
3.
E has a receiver behind it, and announces a BGP-AD leaf route towards A. A discovers service endpoint
E for the on-demand tree.
4.
A invokes an Add SR multicast leaf router request (for E) to SR-PCE.
5.
SR-PCE computes and generates the multicast tree information for all the routers that are part of the tree.
248
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Segment Routing Tree Segment Identifier
Figure 18: Optimal Multicast Tree
Multicast VPN: Tree-SID MVPN With TI-LFA
1.
A decides to optimize a flow and assigns Tree-ID 30 and invokes a Create an SR multicast tree request by sending the multicast router and tree ID information (A, 30) towards SR-PCE.
2.
A announces BGP AD I-PMSI route with PTA (A,30). A sets the leaf-info-required to discover endpoint interest set.
3.
D has a receiver behind it, and announces a BGP-AD leaf route towards A. A discovers service endpoint
D for optimized flow.
4.
A invokes an Add SR multicast leaf router request (for D) to SR-PCE.
5.
SR-PCE computes and generates the multicast tree information for all the routers that are part of the tree.
Configurations
Head End Router Configuration (Router A) - The following configuration is specific to the head end router.
Configure TE Constraints and Optimization Parameters
Router# configure terminal
Router(config)# segment-routing traffic-engineering
An affinity bit-map is created so that it can be applied to a link or interface.
Router(config-sr-te)# affinity-map name 10 bit-position 24
Router(config-sr-te)# commit
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
249
Segment Routing Tree Segment Identifier
Multicast VPN: Tree-SID MVPN With TI-LFA
An affinity (or relationship) is created between the SR policy path and the link color so that SR-TE computes a path that includes or excludes links, as specified. The head-end router automatically follows the actions defined in the ODN template (for color 10) upon the arrival of VPN routes with a BGP color extended community that matches color 10.
Router(config)# segment-routing traffic-engineering
Router(config-sr-te)# on-demand color 10 dynamic
Router(config-sr-te-color-dyn)# affinity include-all name red
Router(config-sr-te-color-dyn)# affinity include-any name blue
Router(config-sr-te-color-dyn)# affinity exclude-any name green
Router(config-sr-te-color-dyn)# metric type te
Router(config-sr-te-color-dyn)# commit
The SR policy configuration on the head-end router A will be sent to the SR-PCE server, after a connection is established between A and SR-PCE.
Multicast Router Configuration
Configure PCEP Client on Multicast Routers
Associate each multicast router as a client of the SR-PCE server. The pce address ipv4 command specifies the SR-PCE server’s IP address.
Router# configure terminal
Router(config)# segment-routing traffic-engineering
Router(config-sr-te)# pcc pce address ipv4 3.3.3.3
Router(config-pcc-pce)# commit
SR PCE Server Configuration
Configure Label Range for Multicast Trees
Configure the label range to be used for transporting IP multicast traffic in SP network.
Router(config)# pce segment-routing traffic-eng p2mp label-range min 30000 max 60000
Router(config)# commit
Configure FRR
The following configurations enable FRR for all SR multicast (P2MP) trees, including dynamic and static implementations.
The lfa keyword enables LFA FRR on the PCE server.
Router(config)# pce segment-routing traffic-eng p2mp fast-reroute lfa
Router(config)# commit
Alternatively, you can configure FRR for each individual tree using the following configuration. The lfa keyword under a specific multicast policy ( tree1 in this example) enables LFA FRR function for the specified
SR multicast P2MP tree.
For dynamic trees, L-flag in LSP Attributes PCEP object controls FRR on a tree.
Router(config)# pce
Router(config-pce)# address ipv4 192.168.0.5
Router(config-pce)# segment-routing traffic-eng p2mp policy tree1 fast-reroute lfa
Router(config-pce)# commit
The frr-node-set from ipv4 address and frr-node-set to ipv4 address commands specify the from and to paths on a multicast router that requires FRR protection. In this configuration, the PCE server is configured to manage the FRR function for traffic from 192.168.0.3 sent towards 192.168.0.4 and 192.168.0.5.
Router(config)# pce
Router(config-pce)# address ipv4 192.168.0.5
Router(config-pce)# segment-routing traffic-eng p2mp frr-node-set from ipv4 192.168.0.3
250
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Segment Routing Tree Segment Identifier
Multicast VPN: Tree-SID MVPN With TI-LFA
Router(config-pce)# commit
Router(config)# pce
Router(config-pce)# address ipv4 192.168.0.5
Router(config-pce)# segment-routing traffic-eng p2mp frr-node-set to ipv4 192.168.0.4
Router(config-pce)# segment-routing traffic-eng p2mp frr-node-set to ipv4 192.168.0.5
Router(config-pce)# commit
Disable ECMP load splitting
To disable ECMP load splitting of different trees on the SR-PCE server, configure the multipath-disable command.
Router(config)# pce segment-routing traffic-eng p2mp multipath-disable
Router(config)# commit
Multicast Routing Configuration On PE Routers
The following MVPN configurations are required for VPN end-points, the 3 PE routers.
Configure Default MDT SR P2MP MVPN Profile
In this configuration, an MDT profile of the type default is created, and the SR multicast policy with color
10 will be used to send IP multicast traffic, as per the constraints and optimizations of the policy, through the multicast tree.
You can also specify the FRR LFA function with the mdt default segment-routing mpls fast-reroute lfa command.
Router(config)# multicast-routing vrf cust1
Router(config-mcast-cust1)# address-family ipv4
Router(config-mcast-cust1-ipv4)# mdt default segment-routing mpls color 10
Router(config-mcast-cust1-ipv4)# commit
Configure Partitioned MDT SR P2MP MVPN Profile
In this configuration, an MDT profile of the type partitioned is created, and the SR multicast policy with color
10 will be used to send IP multicast traffic, as per the constraints and optimizations of the policy, through the multicast tree.
You can also specify the FRR LFA function with the mdt partitioned segment-routing mpls fast-reroute lfa command.
Router(config)# multicast-routing vrf cust1
Router(config-mcast-cust1)# address-family ipv4
Router(config-mcast-cust1-ipv4)# mdt partitioned segment-routing mpls color 10
Router(config-mcast-cust1-ipv4)# commit
The following Data MVPN configuration is required at the Ingress PE (router A) where the multicast flows need to be steered onto the data MDT for SR multicast traffic flow.
Note Data MDT can be configured for Default and Partitioned profiles.
Configure Data MDT for SR P2MP MVPN
In this configuration, an MDT profile of the type data is created, and the SR multicast policy with color 10 will be used to send IP multicast traffic, as per the constraints and optimizations of the policy, through the multicast tree.
• You can enable the FRR LFA function with the mdt data segment-routing mpls fast-reroute lfa command. This enables LFA FRR for SR multicast trees created for all data MDT profiles.
• As an alternative to the color keyword, you can specify a route policy in the route-policy command, and define the route policy separately (as mentioned in the next configuration).
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
251
Segment Routing Tree Segment Identifier
Multicast VPN: Tree-SID MVPN With TI-LFA
• The threshold command specifies the threshold above which a multicast flow is switched onto the data
MDT. The immediate-switch keyword enables an immediate switch of a multicast flow to the data
MDT, without waiting for threshold limit to be crossed.
• The customer-route-acl keyword specifies an ACL to enable specific multicast flows to be put on to the data MDT.
• color and fast-reroute lfa keywords are mutually exclusive with the route-policy configuration. The objective is to apply constraints (through color ) or FRR (through LFA protection) to either all data MDTs, or apply them selectively per data MDT, using the set on-demand-color and set fast-reroute lfa options in the route policy (configured in the mdt data configuration).
Router(config)# multicast-routing vrf cust1
Router(config-mcast-cust1)# address-family ipv4
Router(config-mcast-cust1-ipv4)# mdt data segment-routing mpls 2 color 10
Router(config-mcast-cust1-ipv4)# commit
Route Policy Example
The route policy designates multicast flow-to-SR multicast policy mapping, with different colors.
• With this configuration, IP multicast flows for the 232.0.0.1 multicast group are steered into the SR multicast policy created with the on-demand color 10, while flows for 232.0.0.2 are steered into the policy created with color 20.
• The data MDT SR multicast tree created for the 232.0.0.2 multicast group is enabled with FRR LFA protection.
• Route policies can also be used to match other parameters, such as source address.
Router(config)# route-policy TSID-DATA
Router(config-rpl)# if destination in (232.0.0.1) then
Router(config-rpl-if)# set on-demand-color 10
Router(config-rpl-if)# pass
Router(config-rpl-if)# elseif destination in (232.0.0.2) then
Router(config-rpl-elseif)# set on-demand-color 20
Router(config-rpl-elseif)# set fast-reroute lfa
Router(config-rpl-elseif)# pass
Router(config-rpl-elseif)# endif
Router(config-rpl)# end-policy
Router(config)# commit
Configure MVPN BGP Auto-Discovery for SR P2MP
The following configuration is required on all PE routers, and is mandatory for default MDT, partitioned
MDT, and data MDT.
Configure the BGP Auto-Discovery function for transporting IP multicast traffic.
Router(config)# multicast-routing vrf cust1
Router(config-mcast-cust1)# address-family ipv4
Router(config-mcast-cust1-ipv4)# bgp auto-discovery segment-routing
Router(config-mcast-cust1-ipv4-bgp-ad)# commit
Verification
View MVPN Context Information - You can view MVPN VRF context information with these commands.
View Default MDT Configuration
252
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Segment Routing Tree Segment Identifier
Multicast VPN: Tree-SID MVPN With TI-LFA
This command displays SR multicast tree information, including the MDT details (of default type, etc), and customer VRF information (route target, route distinguisher, etc).
Router# show mvpn vrf vpn1 context
MVPN context information for VRF vpn1 (0x9541cf0)
RD: 1:10 (Valid, IID 0x1), VPN-ID: 0:0
Import Route-targets : 2
RT:192.168.0.4:0, BGP-AD
RT:192.168.0.4:17, BGP-AD
BGP Auto-Discovery Enabled (I-PMSI added)
SR P2MP Core-tree data:
MDT Name: TRmdtvpn1, Handle: 0x4150, idb: 0x956fc30
MTU: 1376, MaxAggr: 255, SW_Int: 30, AN_Int: 60
RPF-ID: 3, C:0, O:1, D:0, CP:0
Static Type : - / -
Def MDT ID: 524289 (0x93993f0), added: 1, HLI: 0x80001, Cfg: 1/0
Part MDT ID: 0 (0x0), added: 0, HLI: 0x00000, Cfg: 0/0
Ctrl Trees : 0/0/0, Ctrl ID: 0 (0x0), Ctrl HLI: 0x00000
View Partitioned MDT Configuration
This command displays SR multicast tree information, including the MDT details (of partitioned type, etc), and customer VRF information (route target, route distinguisher, etc).
Router# show mvpn vrf vpn1 context
MVPN context information for VRF vpn1 (0x9541cf0)
RD: 1:10 (Valid, IID 0x1), VPN-ID: 0:0
Import Route-targets : 2
RT:192.168.0.4:0, BGP-AD
RT:192.168.0.4:17, BGP-AD
BGP Auto-Discovery Enabled (I-PMSI added) , MS-PMSI sent
SR P2MP Core-tree data:
MDT Name: TRmdtvpn1, Handle: 0x4210, idb: 0x956fc30
MTU: 1376, MaxAggr: 255, SW_Int: 30, AN_Int: 60
RPF-ID: 1, C:0, O:1, D:0, CP:0
Static Type : - / -
Def MDT ID: 0 (0x0), added: 0, HLI: 0x00000, Cfg: 0/0
Part MDT ID: 524292 (0x9399318), added: 1, HLI: 0x80004, Cfg: 1/0
Ctrl Trees : 0/0/0, Ctrl ID: 0 (0x0), Ctrl HLI: 0x00000
View Partitioned MDT Ingress PE Configuration
This command displays SR multicast tree information on the PE router that receives the multicast traffic on the SP network. The information includes PE router details, MDT details, Tree-SID details, and the specified customer VRF information.
Router# show mvpn vrf vpn1 pe
MVPN Provider Edge Router information
VRF : vpn1
PE Address : 192.168.0.3 (0x9570240)
RD: 0:0:0 (null), RIB_HLI 0, RPF-ID 13, Remote RPF-ID 0, State: 0, S-PMSI: 2
PPMP_LABEL: 0, MS_PMSI_HLI: 0x00000, Bidir_PMSI_HLI: 0x00000, MLDP-added: [RD 0, ID 0,
Bidir ID 0, Remote Bidir ID 0], Counts(SHR/SRC/DM/DEF-MD): 0, 0, 0, 0, Bidir: GRE RP Count
0, MPLS RP Count 0RSVP-TE added: [Leg 0, Ctrl Leg 0, Part tail 0 Def Tail 0, IR added:
[Def Leg 0, Ctrl Leg 0, Part Leg 0, Part tail 0, Part IR Tail Label 0
Tree-SID Added: [Def/Part Leaf 1, Def Egress 0, Part Egress 0, Ctrl Leaf 0] bgp_i_pmsi: 1,0/0 , bgp_ms_pmsi/Leaf-ad: 1/1, bgp_bidir_pmsi: 0, remote_bgp_bidir_pmsi:
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
253
Segment Routing Tree Segment Identifier
Multicast VPN: Tree-SID MVPN With TI-LFA
0, PMSIs: I 0x9570378, 0x0, MS 0x94e29d0, Bidir Local: 0x0, Remote: 0x0, BSR/Leaf-ad 0x0/0,
Autorp-disc/Leaf-ad 0x0/0, Autorp-ann/Leaf-ad 0x0/0
IIDs: I/6: 0x1/0x0, B/R: 0x0/0x0, MS: 0x1, B/A/A: 0x0/0x0/0x0
Bidir RPF-ID: 14, Remote Bidir RPF-ID: 0
I-PMSI: Unknown/None (0x9570378)
I-PMSI rem: (0x0)
MS-PMSI: Tree-SID [524290, 192.168.0.3] (0x94e29d0)
Bidir-PMSI: (0x0)
Remote Bidir-PMSI: (0x0)
BSR-PMSI: (0x0)
A-Disc-PMSI: (0x0)
A-Ann-PMSI: (0x0)
RIB Dependency List: 0x0
Bidir RIB Dependency List: 0x0
Sources: 0, RPs: 0, Bidir RPs: 0
View Partitioned MDT Egress PE Configuration
This command displays SR multicast tree information on the MVPN egress PE router that sends multicast traffic from the SP network towards multicast receivers in the destination sites. The information includes PE router, Tree-SID, MDT, and the specified customer VRF details.
Router# show mvpn vrf vpn1 pe
MVPN Provider Edge Router information
PE Address : 192.168.0.4 (0x9fa38f8)
RD: 1:10 (valid), RIB_HLI 0, RPF-ID 15, Remote RPF-ID 0, State: 1, S-PMSI: 2
PPMP_LABEL: 0, MS_PMSI_HLI: 0x00000, Bidir_PMSI_HLI: 0x00000, MLDP-added: [RD 0, ID 0,
Bidir ID 0, Remote Bidir ID 0], Counts(SHR/SRC/DM/DEF-MD): 1, 1, 0, 0, Bidir: GRE RP Count
0, MPLS RP Count 0RSVP-TE added: [Leg 0, Ctrl Leg 0, Part tail 0 Def Tail 0, IR added:
[Def Leg 0, Ctrl Leg 0, Part Leg 0, Part tail 0, Part IR Tail Label 0
Tree-SID Added: [Def/Part Leaf 0, Def Egress 0, Part Egress 1, Ctrl Leaf 0] bgp_i_pmsi: 1,0/0 , bgp_ms_pmsi/Leaf-ad: 1/0, bgp_bidir_pmsi: 0, remote_bgp_bidir_pmsi:
0, PMSIs: I 0x9f77388, 0x0, MS 0x9fa2f98, Bidir Local: 0x0, Remote: 0x0, BSR/Leaf-ad 0x0/0,
Autorp-disc/Leaf-ad 0x0/0, Autorp-ann/Leaf-ad 0x0/0
IIDs: I/6: 0x1/0x0, B/R: 0x0/0x0, MS: 0x1, B/A/A: 0x0/0x0/0x0
Bidir RPF-ID: 16, Remote Bidir RPF-ID: 0
I-PMSI: Unknown/None (0x9f77388)
I-PMSI rem: (0x0)
MS-PMSI: Tree-SID [524292, 192.168.0.4] (0x9fa2f98)
Bidir-PMSI: (0x0)
Remote Bidir-PMSI: (0x0)
BSR-PMSI: (0x0)
A-Disc-PMSI: (0x0)
A-Ann-PMSI: (0x0)
RIB Dependency List: 0x9f81370
Bidir RIB Dependency List: 0x0
Sources: 1, RPs: 1, Bidir RPs: 0
View Data MDT Information
The commands in this section displays SR multicast tree information for data MDTs. The information includes cache, router-local, and remote MDT information.
View Data MDT Cache Information
Router# show pim vrf vpn1 mdt cache
Core Source Cust (Source, Group)
192.168.0.3
(26.3.233.1, 232.0.0.1)
Core Data Expires
[tree-id 524292] never
192.168.0.4
(27.3.233.6, 232.0.0.1) [tree-id 524290] never
254
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Segment Routing Tree Segment Identifier
Multicast VPN: Tree-SID MVPN With TI-LFA
Leaf AD: 192.168.0.3
View Local MDTs Information
Router# show pim vrf vpn1 mdt sr-p2mp local
Tree
Identifier
[tree-id 524290 (0x80002)]
Tree-SID Leaf: 192.168.0.3
MDT
Source
192.168.0.4
View Remote MDTs Information
Router # show pim vrf vpn1 mdt sr-p2mp remote
Cache DIP Local VRF Routes On-demand
Count
1 N
Entry Using Cache Color
Y 1 10
Tree
Identifier
[tree-id 524290 (0x80002)]
MDT
Source
192.168.0.4
View MRIB MPLS Forwarding Information
This command displays labels used for transporting IP multicast traffic, on a specified router.
Router# show mrib mpls forwarding
Cache DIP Local VRF Routes On-demand
Count
1 N
Entry Using Cache Color
N 1 0
LSP information (XTC) :
LSM-ID: 0x00000, Role: Head, Head LSM-ID: 0x80002
Incoming Label : (18000)
Transported Protocol : <unknown>
Explicit Null : None
IP lookup : disabled
Outsegment Info #1 [H/Push, Recursive]:
OutLabel: 18000, NH: 192.168.0.3, Sel IF: GigabitEthernet0/2/0/0
LSP information (XTC) :
LSM-ID: 0x00000, Role: Tail, Peek
RPF-ID: 0x00011, Assoc-TIDs: 0xe0000011/0x0, MDT: TRmdtvpn1
Incoming Label : 18001
Transported Protocol : <unknown>
Explicit Null
IP lookup
: None
: enabled
Outsegment Info #1 [T/Pop]:
No info.
SR-PCE Show Commands
View Tree Information On PCE Server
This command displays SR multicast tree information on the SR-PCE server.
Router# show pce lsp p2mp
Tree: sr_p2mp_root_192.168.0.1_tree_id_524290
Label: 18000
Metric Type: TE
Transition count: 3
Operational: up Admin: up
Uptime: 00:00:03 (since Fri Jan 24 14:57:51 PST 2020)
Source: 192.168.0.1
Destinations: 192.168.0.4
Nodes:
Node[0]: 192.168.0.2 (rtrM)
Role: Transit
Hops:
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
255
Segment Routing Tree Segment Identifier
Multicast VPN: Tree-SID MVPN With TI-LFA
Incoming: 18000 CC-ID: 4
Outgoing: 18000 CC-ID: 4 (17.17.17.4) [rtrR]
Node[1]: 192.168.0.1 (rtrL1)
Role: Ingress
Hops:
Incoming: 18000 CC-ID: 5
Outgoing: 18000 CC-ID: 5 (12.12.12.2) [rtrM]
Node[2]: 192.168.0.4 (rtrR)
Role: Egress
Hops:
Incoming: 18000 CC-ID: 6
For dynamic SR multicast trees created for MVPN, the show command has filters to view root multicast router and Tree-ID information. When the root router is specified, all multicast trees from that root are displayed. When root and Tree-ID are specified, only the specified tree information is displayed.
Router# show pce lsp p2mp root ipv4 1.1.1.1 524289
Tree: sr_p2mp_root_1.1.1.1_tree_id_524289, Root: 1.1.1.1 ID: 524289
Label: 20000 Operational: up Admin: up
PCC: 1.1.1.1
Local LFA FRR: Disabled
Metric Type: TE
Transition count: 11
Uptime: 00:03:37 (since Mon May 11 12:53:33 PDT 2020)
Destinations: 1.1.1.3, 1.1.1.4, 1.1.1.5
Nodes:
Node[0]: 1.1.1.1 (root1)
Role: Ingress
Hops:
Incoming: 20000 CC-ID: 26
Outgoing: 20000 CC-ID: 26 (192.168.114.4) [mid-4]
Outgoing: 20000 CC-ID: 26 (192.168.112.2) [mid-2]
Node[1]: 1.1.1.4 (mid-4)
Role: Egress
Hops:
Incoming: 20000 CC-ID: 27
Node[2]: 1.1.1.2 (mid-2)
Role: Transit
Hops:
Incoming: 20000 CC-ID: 28
Outgoing: 20000 CC-ID: 28 (192.168.123.3) [leaf-3]
Outgoing: 20000 CC-ID: 28 (192.168.125.5) [leaf-5]
Node[3]: 1.1.1.3 (leaf-3)
Role: Egress
Hops:
Incoming: 20000 CC-ID: 29
Node[4]: 1.1.1.5 (leaf-5)
Role: Egress
Hops:
Incoming: 20000 CC-ID: 30
The following output shows that LFA FRR is enabled on the hop from rtrR to rtrM. Unlike typical multicast replication where the address displayed is the remote address on the link to a downstream router, the IP address
192.168.0.3 (displayed with an exclamation mark) is the router-ID of the downstream router rtrM. The output also displays the LFA FRR state for the multicast tree.
Router# show pce lsp p2mp
Tree: sr_p2mp_root_192.168.0.4_tree_id_524290
Label: 18000 Operational: up Admin: up
LFA FRR: Enabled
Metric Type: TE
256
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Segment Routing Tree Segment Identifier
Multicast VPN: Tree-SID MVPN With TI-LFA
Transition count: 1
Uptime: 3d19h (since Thu Feb 13 13:43:40 PST 2020)
Source: 192.168.0.4
Destinations: 192.168.0.1, 192.168.0.2
Nodes:
Node[0]: 192.168.0.3 (rtrM)
Role: Transit
Hops:
Incoming: 18000 CC-ID: 1
Outgoing: 18000 CC-ID: 1 (12.12.12.1) [rtrL1]
Outgoing: 18000 CC-ID: 1 (15.15.15.2) [rtrL2]
Node[1]: 192.168.0.4 (rtrR)
Role: Ingress
Hops:
Incoming: 18000 CC-ID: 2
Outgoing: 18000 CC-ID: 2 (192.168.0.3!) [rtrM]
Node[2]: 192.168.0.1 (rtrL1)
Role: Egress
Hops:
Incoming: 18000 CC-ID: 3
Node[3]: 192.168.0.2 (rtrL2)
Role: Egress
Hops:
Incoming: 18000 CC-ID: 4
Multicast Tree Information on Routers
Router# show segment-routing traffic-eng p2mp policy
SR-TE P2MP policy database:
----------------------
! - Replications with Fast Re-route
Policy: sr_p2mp_root_192.168.0.1_tree_id_524290
LSM-ID: 0x2
Role: Leaf
Replication:
Incoming label: 18001 CC-ID: 6
Policy: sr_p2mp_root_192.168.0.4_tree_id_524290
LSM-ID: 0x80002 (PCC-initiated)
Color: 0
LFA FRR: Disabled
Role: Root
Replication:
Incoming label: 18000 CC-ID: 2
Interface: None [192.168.0.3!] Outgoing label: 18000 CC-ID: 2
Endpoints:
192.168.0.1, 192.168.0.2
For SR multicast policies originated locally on the router (root router of a dynamic MVPN multicast policy) additional policy information is displayed. The information includes color, end points, and whether LFA FRR is requested by the local application. When the SR-PCE server enables LFA FRR on a specific hop, the outgoing information shows the address of the next router with an exclamation mark and None is displayed for the outgoing interface.
For dynamic SR multicast trees created for MVPN, the show command has filters for displaying root multicast router and Tree-ID information. When the root router is specified, all multicast trees for that root are displayed.
When root and Tree-ID are specified, only the specified tree information is displayed.
Router# show segment-routing traffic-eng p2mp policy root ipv4 1.1$
SR-TE P2MP policy database:
----------------------
! - Replications with Fast Re-route, * - Stale dynamic policies/endpoints
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
257
Segment Routing Tree Segment Identifier
Multicast VPN: Tree-SID MVPN With TI-LFA
Policy: sr_p2mp_root_1.1.1.1_tree_id_524289
LSM-ID: 0x691
Root: 1.1.1.1, ID: 524289
Role: Transit
Replication:
Incoming label: 20000 CC-ID: 28
Interface: Bundle-Ether23 [192.168.123.3] Outgoing label: 20000 CC-ID: 28
Interface: Bundle-Ether25 [192.168.125.5] Outgoing label: 20000 CC-ID: 28
Policy: sr_p2mp_root_1.1.1.1_tree_id_524290
LSM-ID: 0x692
Root: 1.1.1.1, ID: 524290
Role: Transit
Replication:
Incoming label: 19999 CC-ID: 28
Interface: Bundle-Ether23 [192.168.123.3] Outgoing label: 19999 CC-ID: 28
Interface: Bundle-Ether25 [192.168.125.5] Outgoing label: 19999 CC-ID: 28
258
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
C H A P T E R
9
Configure Segment Routing Path Computation
Element
The Segment Routing Path Computation Element (SR-PCE) provides stateful PCE functionality by extending the existing IOS-XR PCEP functionality with additional capabilities. SR-PCE is supported on the MPLS data plane and IPv4 control plane.
Note The Cisco IOS XRv 9000 is the recommended platform to act as the SR-PCE. Refer to the Cisco IOS XRv
9000 Router Installation and Configuration Guide for more information.
Table 23: Feature History Table
Feature Name
SR-PCE: Single PCE scale enhancement
Release Information
Release 7.5.1
Feature Description
With this feature, support for a single PCE is enhanced to 50000 nodes, 100000 LSPs, 500000 links, and 2000 PCEP sessions.
•
•
•
PCE-Initiated SR Policies, on page 264
•
SR-PCE Flexible Algorithm Multi-Domain Path Computation, on page 266
•
ACL Support for PCEP Connection, on page 270
•
Inter-Domain Path Computation Using Redistributed SID, on page 271
•
PCE Support for MPLS-TE LSPs, on page 273
•
Configuring the North-Bound API on SR-PCE, on page 276
About SR-PCE
The path computation element protocol (PCEP) describes a set of procedures by which a path computation client (PCC) can report and delegate control of head-end label switched paths (LSPs) sourced from the PCC to a PCE peer. The PCE can request the PCC to update and modify parameters of LSPs it controls. The stateful
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
259
Configure Segment Routing Path Computation Element
About SR-PCE model also enables a PCC to allow the PCE to initiate computations allowing the PCE to perform network-wide orchestration.
SR-PCE learns topology information by way of IGP (OSPF or IS-IS) or through BGP Link-State (BGP-LS).
SR-PCE is capable of computing paths using the following methods:
• TE metric—SR-PCE uses the TE metric in its path calculations to optimize cumulative TE metric.
• IGP metric—SR-PCE uses the IGP metric in its path calculations to optimize reachability.
• LSP Disjointness—SR-PCE uses the path computation algorithms to compute a pair of disjoint LSPs.
The disjoint paths can originate from the same head-end or different head-ends. Disjoint level refers to the type of resources that should not be shared by the two computed paths. SR-PCE supports the following disjoint path computations:
• Link – Specifies that links are not shared on the computed paths.
• Node – Specifies that nodes are not shared on the computed paths.
• SRLG – Specifies that links with the same SRLG value are not shared on the computed paths.
• SRLG-node – Specifies that SRLG and nodes are not shared on the computed paths.
When the first request is received with a given disjoint-group ID, the first LSP is computed, encoding the shortest path from the first source to the first destination. When the second LSP request is received with the same disjoint-group ID, information received in both requests is used to compute two disjoint paths: one path from the first source to the first destination, and another path from the second source to the second destination. Both paths are computed at the same time.
TCP Authentication Option
TCP Message Digest 5 (MD5) authentication has been used for authenticating PCEP (TCP) sessions by using a clear text or encrypted password. This feature introduces support for TCP Authentication Option (TCP-AO), which replaces the TCP MD5 option.
TCP-AO uses Message Authentication Codes (MACs), which provides the following:
• Protection against replays for long-lived TCP connections
• More details on the security association with TCP connections than TCP MD5
• A larger set of MACs with minimal system and operational changes
TCP-AO is compatible with Master Key Tuple (MKT) configuration. TCP-AO also protects connections when using the same MKT across repeated instances of a connection. TCP-AO protects the connections by using traffic key that are derived from the MKT, and then coordinates changes between the endpoints.
Note TCP-AO and TCP MD5 are never permitted to be used simultaneously. TCP-AO supports IPv6, and is fully compatible with the proposed requirements for the replacement of TCP MD5.
260
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing Path Computation Element
Configure SR-PCE
Configure SR-PCE
This task explains how to configure SR-PCE.
Before you begin
The Cisco IOS XRv 9000 is the recommended platform to act as the SR-PCE.
Procedure
Step 1
Step 2
Command or Action configure
Example:
RP/0/RP0/CPU0:router# configure pce
Example:
RP/0/RP0/CPU0:router(config)# pce
Purpose
Enters mode.
Enables PCE and enters PCE configuration mode.
Step 3
Step 4
Step 5
Step 6
address ipv4 address
Example:
RP/0/RP0/CPU0:router(config-pce)# address ipv4 192.168.0.1
state-sync ipv4 address
Example:
RP/0/RP0/CPU0:router(config-pce)# state-sync ipv4 192.168.0.3
Configures a PCE IPv4 address.
Configures the remote peer for state synchronization.
tcp-buffer size size
Example:
RP/0/RP0/CPU0:router(config-pce)# tcp-buffer size 1024000
Configures the transmit and receive TCP buffer size for each PCEP session, in bytes. The default buffer size is 256000. The valid range is from 204800 to 1024000.
password { clear | encrypted } password
Example:
RP/0/RP0/CPU0:router(config-pce)# password encrypted pwd1
Enables TCP MD5 authentication for all PCEP peers. Any TCP segment coming from the PCC that does not contain a MAC matching the configured password will be rejected. Specify if the password is encrypted or clear text.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
261
Configure SR-PCE
Configure Segment Routing Path Computation Element
Step 7
Step 8
Step 9
Command or Action Purpose
Note TCP-AO and TCP MD5 are never permitted to be used simultaneously.
tcp-ao key-chain
[
Example:
[ include-tcp-options accept-ao-mismatch-connection ]
]
RP/0/RP0/CPU0:router(config-pce)# tcp-ao pce_tcp_ao include-tcp-options
Enables TCP Authentication Option (TCP-AO) authentication for all PCEP peers. Any TCP segment coming from the PCC that does not contain a MAC matching the configured key chain will be rejected.
• include-tcp-options —Includes other TCP options in the header for MAC calculation.
• accept-ao-mismatch-connection —Accepts connection even if there is a mismatch of
AO options between peers.
segment-routing te-latency
Example:
}
{ strict-sid-only |
RP/0/RP0/CPU0:router(config-pce)# segment-routing strict-sid-only
Note TCP-AO and TCP MD5 are never permitted to be used simultaneously.
Configures the segment routing algorithm to use strict SID or TE latency.
Note This setting is global and applies to all LSPs that request a path from this controller.
timers
Example:
RP/0/RP0/CPU0:router(config-pce)# timers
Enters timer configuration mode.
Step 10
Step 11
keepalive time
Example:
RP/0/RP0/CPU0:router(config-pce-timers)# keepalive 60
Configures the timer value for locally generated keep-alive messages. The default time is 30 seconds.
minimum-peer-keepalive time
Example:
RP/0/RP0/CPU0:router(config-pce-timers)# minimum-peer-keepalive 30
Configures the minimum acceptable keep-alive timer that the remote peer may propose in the
PCEP OPEN message during session establishment. The default time is 20 seconds.
262
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing Path Computation Element
Configure the Disjoint Policy (Optional)
Step 12
Step 13
Command or Action
reoptimization time
Example:
RP/0/RP0/CPU0:router(config-pce-timers)# reoptimization 600
Purpose
Configures the re-optimization timer. The default timer is 1800 seconds.
exit
Example:
RP/0/RP0/CPU0:router(config-pce-timers)# exit
Exits timer configuration mode and returns to
PCE configuration mode.
Configure the Disjoint Policy (Optional)
This task explains how to configure the SR-PCE to compute disjointness for a pair of LSPs signaled by PCCs that do not include the PCEP association group-ID object in their PCEP request. This can be beneficial for deployments where PCCs do not support this PCEP object or when the network operator prefers to manage the LSP disjoint configuration centrally.
Procedure
Step 1
Command or Action disjoint-path
Example:
RP/0/RP0/CPU0:router(config-pce)# disjoint-path
Purpose
Enters disjoint configuration mode.
Step 2 group-id value type { link | node | srlg
| srlg-node } [ sub-id value ]
Example:
Configures the disjoint group ID and defines the preferred level of disjointness (the type of resources that should not be shared by the two paths):
RP/0/RP0/CPU0:router(config-pce-disjoint)# group-id 1 type node sub-id 1
• link —Specifies that links are not shared on the computed paths.
• node —Specifies that nodes are not shared on the computed paths.
• srlg —Specifies that links with the same
SRLG value are not shared on the computed paths.
• srlg-node —Specifies that SRLG and nodes are not shared on the computed paths.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
263
Configure Segment Routing Path Computation Element
PCE-Initiated SR Policies
Step 3
Step 4
Command or Action Purpose
If a pair of paths that meet the requested disjointness level cannot be found, then the paths will automatically fallback to a lower level:
• If the requested disjointness level is SRLG or node, then link-disjoint paths will be computed.
• If the requested disjointness level was link, or if the first fallback from SRLG or node disjointness failed, then the lists of segments encoding two shortest paths, without any disjointness constraint, will be computed.
strict
Example:
RP/0/RP0/CPU0:router(config-pce-disjoint)# strict
(Optional) Prevents the automatic fallback behavior of the preferred level of disjointness.
If a pair of paths that meet the requested disjointness level cannot be found, the disjoint calculation terminates and no new path is provided. The existing path is not modified.
lsp { 1 | 2 } pcc ipv4 address lsp-name lsp_name [ shortest-path ]
Adds LSPs to the disjoint group.
Example:
RP/0/RP0/CPU0:router(config-pce-disjoint)# lsp 1 pcc ipv4 192.168.0.1 lsp-name rtrA_t1 shortest-path
RP/0/RP0/CPU0:router(config-pce-disjoint)# lsp 2 pcc ipv4 192.168.0.5 lsp-name rtrE_t2
The shortest-path keyword forces one of the disjoint paths to follow the shortest path from the source to the destination. This option can only be applied to the the first LSP specified.
PCE-Initiated SR Policies
An SR-TE policy can be configured on the path computation element (PCE) to reduce link congestion or to minimize the number of network touch points.
Note The PCE-initiated SR-TE policies are entered in PCE configuration mode. For more information on configuring
SR-TE policies, see the
SR-TE Policy Overview, on page 137
.
To minimize the number of network touch points, an application, such as a Network Services Orchestrator
(NSO), can request the PCE to create an SR-TE policy. PCE deploys the SR-TE policy using PCC-PCE communication protocol (PCEP).
1.
PCE sends a PCInitiate message to the PCC.
264
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing Path Computation Element
PCE-Initiated SR Policies
2.
If the PCInitiate message is valid, the PCC sends a PCRpt message; otherwise, it sends PCErr message.
3.
If the PCInitiate message is accepted, the PCE updates the SR-TE policy by sending PCUpd message.
You can achieve high-availability by configuring multiple PCEs with SR-TE policies. If the head-end (PCC) loses connectivity with one PCE, another PCE can assume control of the SR-TE policy.
Configuration Example: PCE-Initiated SR Policy with Explicit SID List
To configure a PCE-initiated SR-TE policy, you must complete the following configurations:
1.
Enter PCE configuration mode.
2.
Create the segment list.
Note When configuring an explicit path using IP addresses of intermediate links, the SR-TE process prefers the protected Adj-SID of the link, if one is available.
3.
Create the policy.
/* Enter PCE configuration mode and create the SR-TE segment lists */
Router# configure
Router(config)# pce
/* Create the SR-TE segment lists */
Router(config-pce)# segment-routing
Router(config-pce-sr)# traffic-eng
Router(config-pce-sr-te)# segment-list name addr2a
Router(config-pce-sr-te-sl)# index 10 address ipv4 1.1.1.2
Router(config-pce-sr-te-sl)# index 20 address ipv4 10.2.3.2
Router(config-pce-sr-te-sl)# index 30 address ipv4 1.1.1.4
Router(config-pce-sr-te-sl)# exit
/* Create the SR-TE policy */
Router(config-pce-sr-te)# peer ipv4 1.1.1.1
Router(config-pce-sr-te)# policy P1
Router(config-pce-sr-te-policy)# color 2 end-point ipv4 2.2.2.2
Router(config-pce-sr-te-policy)# candidate-paths
Router(config-pce-sr-te-policy-path)# preference 50
Router(config-pce-sr-te-policy-path-preference)# explicit segment-list addr2a
Router(config-pce-sr-te-pp-info)# commit
Router(config-pce-sr-te-pp-info)# end
Router(config)#
Running Config pce segment-routing traffic-eng segment-list name addr2a
!
index 1 address ipv4 14.14.14.4
peer ipv4 1.1.1.1
policy P1 color 2 end-point ipv4 2.2.2.2
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
265
Configure Segment Routing Path Computation Element
SR-PCE Flexible Algorithm Multi-Domain Path Computation candidate-paths preference 50
!
explicit segment-list addr2a
!
SR-PCE Flexible Algorithm Multi-Domain Path Computation
Flexible Algorithm provides a traffic engineered path automatically computed by the IGP to any destination reachable by the IGP. With the SR-PCE Flexible Algorithm Multi-Domain Path Computation feature, SR-PCE can use Flexible Algorithms to compute multi-domain paths. See the
Enabling Segment Routing Flexible
chapter for information about Segment Routing Flexible Algorithm.
The SR-PCE Flexible Algorithm Multi-Domain Path Computation feature incorporates the following functionality:
• BGP-LS has been augmented to allow selected nodes to advertise the Flexible Algorithm definition
(FAD) to the SR-PCE
• PCEP has been augmented (vendor-specific object) to allow a PCC to indicate SR policy constraint based on the Flexible Algorithm instance number
• SR-PCE algorithms have been augmented to compute paths based on a Flexible Algorithm constraint
The SR-PCE Flexible Algorithm multi-domain path computation requires the following:
• The same Flexible Algorithm instance ID is used across domains.
• The metric for those Flexible Algorithm instances must be the same across domains.
• The affinity constraints for those Flexible Algorithm instances may be different across domains.
• Multiple Flexible Algorithms can exist in a domain.
For example, considering a multi-domain topology (Domain 1 and Domain 2), the following scenarios meet the requirements listed above:
Scenario
Scenario 1
Domain 1
Flexible Algorithm 128, metric delay
Domain 2
Flexible Algorithm 128, metric delay
Scenario 2
Scenario 3
Scenario 4
Flexible Algorithm 128, metric delay Flexible Algorithm 128, metric delay, exclude affinity blue
Flexible Algorithm 128, metric delay, exclude affinity yellow
Flexible Algorithm 128, metric delay, exclude affinity blue
Flexible Algorithm 128, metric delay
Flexible Algorithm 129, metric IGP
Flexible Algorithm 128, metric delay
Flexible Algorithm 129, metric IGP
266
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing Path Computation Element
Example: SR-PCE Flexible Algorithm Multi-Domain Path Computation Use Case
Note The use of a Flexible Algorithm constraint in a multi-domain SR topology does not preclude the use of an
SR policy that are optimized for a particular metric type. For example, a policy can request a PCE for a Multi
Domain policy based on metric delay. SR-PCE computes the path and encodes it with regular prefix SIDs and Adj-SIDs as required. Alternatively, a policy can request to have a constraint for a Flexible Algorithm instance X, which is defined in multiple domains and it minimizes based on metric delay. In this case, the
SR-PCE computes the multi-domain path and encodes it using only Flexible Algorithm prefix SIDs. This case benefits from the optimized label stack size that Flexible Algorithm provides (1 label per domain).
Example: SR-PCE Flexible Algorithm Multi-Domain Path Computation Use
Case
The following use case depicts a multi-domain topology with two IS-IS processes, each with a Flexible
Algorithm instance of 128 that minimizes metric delay. A multi-domain SR policy programmed at Node 1 leverages a Flexible Algorithm 128 path computed by the SR-PCE toward Node 8.
Figure 19: Multi-Domain Topology
Configuration on Node 8
IS-IS and Flexible Algorithm Configuration router isis 2 is-type level-2-only net 49.0002.0000.0000.0008.00
distribute link-state flex-algo 128 metric-type delay advertise-definition address-family ipv4 unicast metric-style wide router-id 1.1.1.8
segment-routing mpls
!
interface Loopback0 passive
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
267
Example: SR-PCE Flexible Algorithm Multi-Domain Path Computation Use Case
!
address-family ipv4 unicast prefix-sid absolute 16008 prefix-sid algorithm 128 absolute 16808
Configuration on Node 4 (ABR/ASBR)
IS-IS and Flexible Algorithm Configuration router isis 1 is-type level-2-only net 49.0001.0000.0000.0004.00
distribute link-state instance-id 100 flex-algo 128 metric-type delay advertise-definition address-family ipv4 unicast metric-style wide router-id 1.1.1.4
segment-routing mpls
!
interface Loopback0 passive address-family ipv4 unicast prefix-sid absolute 16004 prefix-sid algorithm 128 absolute 16804
!
router isis 2 is-type level-2-only net 49.0002.0000.0000.0004.00
distribute link-state instance-id 200 flex-algo 128 metric-type delay advertise-definition address-family ipv4 unicast metric-style wide router-id 1.1.1.4
segment-routing mpls
!
interface Loopback0 passive address-family ipv4 unicast prefix-sid absolute 16004 prefix-sid algorithm 128 absolute 16804
!
BGP-LS Configuration router bgp 65000 bgp router-id 1.1.1.4
address-family link-state link-state
!
neighbor-group AS65000-LS-group remote-as 65000
!
!
update-source Loopback0 address-family link-state link-state neighbor 1.1.1.10
use neighbor-group AS65000-LS-group
Configure Segment Routing Path Computation Element
268
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing Path Computation Element
Example: SR-PCE Flexible Algorithm Multi-Domain Path Computation Use Case
!
!
description *** To SR-PCE ***
!
Configuration on Node 1
IS-IS and Flexible Algorithm Configuration router isis 1 is-type level-2-only net 49.0001.0000.0000.0001.00
distribute link-state flex-algo 128 metric-type delay advertise-definition address-family ipv4 unicast metric-style wide router-id 1.1.1.1
segment-routing mpls
!
interface Loopback0 passive address-family ipv4 unicast prefix-sid absolute 16001 prefix-sid algorithm 128 absolute 16801
!
SR Policy Configuration segment-routing traffic-eng policy FOO color 100 end-point ipv4 1.1.1.8
candidate-paths preference 100 dynamic pcep
!
!
constraints segments sid-algorithm 128
!
!
!
!
!
!
!
PCC Configuration segment-routing traffic-eng pcc source-address ipv4 1.1.1.1
pce address ipv4 1.1.1.10
precedence 10
!
!
report-all
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
269
Configure Segment Routing Path Computation Element
ACL Support for PCEP Connection
!
!
Configuration on PCE pce address ipv4 1.1.1.10
!
rest
!
router bgp 65000 bgp router-id 1.1.1.10
address-family link-state link-state
!
neighbor-group AS65000-LS-group remote-as 65000 update-source Loopback0 address-family link-state link-state
!
!
neighbor 1.1.1.4
use neighbor-group AS65000-LS-group
!
description *** To Node-4 ***
!
neighbor 1.1.1.5
use neighbor-group AS65000-LS-group
!
description *** To Node-5 ***
!
!
ACL Support for PCEP Connection
PCE protocol (PCEP) (RFC5440) is a client-server model running over TCP/IP, where the server (PCE) opens a port and the clients (PCC) initiate connections. After the peers establish a TCP connection, they create a
PCE session on top of it.
The ACL Support for PCEP Connection feature provides a way to protect a PCE server using an Access
Control List (ACL) to restrict IPv4 PCC peers at the time the TCP connection is created based on the source address of a client. When a client initiates the TCP connection, the ACL is referenced, and the client source address is compared. The ACL can either permit or deny the address and the TCP connection will proceed or not.
Refer to the Implementing Access Lists and Prefix Lists chapter in the IP Addresses and Services Configuration
Guide for Cisco NCS 560 Series Routers for detailed ACL configuration information.
To apply an ACL to the PCE, use the pce peer-filter ipv4 access-list acl_name command.
The following example shows how to configure an ACL and apply it to the PCE: pce address ipv4 1.1.1.5
!
peer-filter ipv4 access-list sample-peer-filter ipv4 access-list sample-peer-filter
10 permit ipv4 host 1.1.1.6 any
20 permit ipv4 host 1.1.1.7 any
270
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing Path Computation Element
Inter-Domain Path Computation Using Redistributed SID
!
30 deny ipv4 any any
Inter-Domain Path Computation Using Redistributed SID
A Path Computation Element (PCE) computes SR-TE paths based on SR topology database that stores connectivity, state, and TE attributes of SR network nodes and links. BGP Labeled Unicast (BGP-LU) provides
MPLS transport across IGP boundaries by advertising loopbacks and label binding of impact edge and border routers across IGP boundaries.
This feature adds new functionality to the SR-PCE that enables it to compute a path for remote non-SR end-point device distributed by BGP-LU.
The remote end-point device in the BGP-LU domain is unknown to the SR-PCE. For the SR-PCE to know about the end-point device, the gateway ABR/ASBR learns the end-point prefix via BGP-LU. The prefix is then redistributed to SR-PCE topology database from the gateway ABR/ASBR. SR-PCE then can compute the best path from the head-end device to the selected gateway router.
The following topology shows an SR domain and a BGP-LU domain, with a gateway ABR/ASBR between the two domains.
1.
The gateway ABR/ASBR is configured with BGP/IGP helper to learn the remote prefix through BGP-LU and redistribute the remote prefix to the IGP helper, then to SR-PCE.
2.
The SR-PCE selects the best gateway node to BGP-LU domain and computes the path to reach the remote prefix through the gateway node.
3.
The head-end device in the SR domain requests a path to the remote destination and signals the SR profile interworking with the BGP-LU domain.
The BGP-LU prefix advertisement to SR-PCE Traffic Engineer Database (TED) is done by creating an IGP helper on the ABR/ASBR to redistribute BGP-LU prefix information to IGP. IGP then sends the prefix information to the SR-PCE via BGP-LS.
If there are multiple ABR/ASBRs advertising the same remote BGP-LU prefix, the SR-PCE selects the best gateway node to the BGP-LU domain using the accumulative metric from the head-end device to the gateway and the advertised metric from the gateway to the destination.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
271
Example: Inter-Domain Path Computation Using Redistributed SID
Configure Segment Routing Path Computation Element
Example: Inter-Domain Path Computation Using Redistributed SID
The following examples show the configurations for the IGP helper, BGP-LU, and proxy BGP-SR:
Configuration on the End-Point Device
Configure the end-point device to allocate a label for the BGP-LU prefix on the end-point device: router bgp 3107 bgp router-id 1.0.0.8
address-family ipv4 unicast network 1.0.0.8/32 route-policy bgplu-com allocate-label all route-policy bgplu-com set community (65002:999) end-policy
Configuration on the Gateway ABR/ASBR
1. Configure the remote prefix set and create the route policy for the BGP-LU domain: prefix-set bgplu
1.0.0.7/32,
1.0.0.8/32 ,
1.0.0.101/32,
1.0.0.102/32 end-set
!
route-policy bgp2isis if destination in bgplu then pass else drop endif
272
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing Path Computation Element
PCE Support for MPLS-TE LSPs end-policy
!
end
2. Configure the helper IGP instance on the Loopback interface: router isis 101 is-type level-2-only net 49.0001.0000.1010.1010.00
distribute link-state instance-id 9999 nsf cisco nsf lifetime 120 address-family ipv4 unicast metric-style wide maximum-paths 64 router-id Loopback10 redistribute bgp 3107 metric 200 route-policy bgp2isis segment-routing mpls sr-prefer
!
interface Loopback10 >>> this loopback is for gateway SR-TE node-id passive address-family ipv4 unicast prefix-sid index 2001 explicit-null
3. Configure the gateway proxy BGP-SR and SR Mapping Server to allocate SR labels: router bgp 3107 address-family ipv4 unicast segment-routing prefix-sid-map allocate-label all segment-routing global-block 16000 23999 mapping-server prefix-sid-map address-family ipv4
1.0.0.7/32 2007
1.0.0.8/32 2008
1.0.0.101/32 2101
1.0.0.102/32 2102
PCE Support for MPLS-TE LSPs
This feature allows Cisco's SR-PCE to act as a Path Computation Element (PCE) for MPLS Traffic Engineering
Label Switched Paths (MPLS-TE LSPs).
Note For more information about MPLS-TE, refer to the "Implementing MPLS Traffic Engineering" chapter in the
MPLS Configuration Guide for Cisco NCS 560 Series Routers .
The supported functionality is summarized below:
• PCE type: Active Stateful PCE
• MPLS-TE LSP initiation methods:
• PCE Initiated—An active stateful PCE initiates an LSP and maintains the responsibility of updating the LSP.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
273
Configure Segment Routing Path Computation Element
PCE Support for MPLS-TE LSPs
• PCC Initiated—A PCC initiates the LSP and may delegate the control later to the Active stateful
PCE.
• MPLS-TE LSP metric—Metric optimized by the path computation algorithm:
• IGP metric
• TE metric
• Latency metric
• MPLS-TE LSP constraints—TE LSP attributes to be taken into account by the PCE during path computation:
• Resource Affinities
• Path Disjointness
• MPLS-TE LSP parameters:
• Setup priority—The priority of the TE LSP with respect to taking resources
• Hold priority—The priority of the TE LSP with respect to holding resources
• FRR L flag—The "Local Protection Desired" bit. Can be set from an application instantiating an
MPLS-TE LSP via SR-PCE. SR-PCE passes this flag to the PCC, and the PCC will enable FRR for that LSP.
• Signaled Bandwidth—This value can be set from an application instantiating an MPLS-TE LSP via
SR-PCE. SR-PCE passes this value to the PCC.
• Binding SID—A segment identifier (SID) that a headend binds to an MPLS-TE LSP. When the headend receives a packet with active segment (top MPLS label) matching the BSID of a local
MPLS-TE LSP, the headend steers the packet into the associated MPLS-TE LSP.
Cisco Crosswork Optimization Engine is an application that leverages the SR-PCE in order to visualize and instantiate MPLS-TE LSPs. For more information, refer to the Visualize SR Policies and RSVP-TE Tunnels chapter in the Cisco Crosswork Optimization Engine 1.2.1 User Guide .
Note No extra configuration is required to enable MPLS-TE support at SR-PCE.
Example: Configuring a PCEP Session (Stateful Mode) on MPLS-TE PCC
The following example shows the configuration for an MPLS-TE PCC to establish a PCEP session with a
PCE (IPv4 address 1.1.1.100).
Note MPLS-TE PCC must operate in the stateful PCEP mode when connecting to SR-PCE.
The instantiation keyword enables the PCC to support MPLS-TE LSP instantiation by PCE (PCE-initiated).
The report keyword enables the PCC to report all the MPLS-TE LSPs configured on that node.
274
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing Path Computation Element
PCE Support for MPLS-TE LSPs
Note PCE-initiated LSPs are automatically reported to all configured PCEs.
The autoroute-announce keyword enables autoroute-announce globally for all PCE-initiated LSPs on the
PCC.
The redundancy pcc-centric keywords enable PCC-centric high-availability model for PCE-initiated LSPs.
The PCC-centric model changes the default PCC delegation behavior to the following:
• After LSP creation, LSP is automatically delegated to the PCE that computed it.
• If this PCE is disconnected, then the LSP is redelegated to another PCE.
• If the original PCE is reconnected, then the delegation fallback timer is started. When the timer expires, the LSP is redelegated back to the original PCE, even if it has worse preference than the current PCE.
mpls traffic-eng pce peer ipv4 1.1.1.100
!
stateful-client instantiation
!
!
!
end report autoroute-announce redundancy pcc-centric
Example: Configuring Multiple PCEP Sessions from a PCC Acting as MPLS-TE and SR-TE Headend Toward a Common PCE
The following example shows the configuration for a PCC (IPv4 addresses 1.1.1.1 and 1.1.1.2) to establish two PCEP sessions with a common PCE (IPv4 address 1.1.1.100). One session is configured under MPLS-TE, and the other under SR-TE.
Note The two PCEP sessions must use a different source address on the PCC when connecting to the same PCE.
For more information regarding PCEP configuration at SR-TE PCC, see the Configure the Head-End Router as PCEP PCC topic.
mpls traffic-eng pce peer source ipv4 1.1.1.1
peer ipv4 1.1.1.100
!
!
!
end segment-routing traffic-eng
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
275
Configure Segment Routing Path Computation Element
Configuring the North-Bound API on SR-PCE
!
!
!
end pcc source-address ipv4 1.1.1.2
pce address ipv4 1.1.1.100
!
Configuring the North-Bound API on SR-PCE
Table 24: Feature History Table
Feature Name Release Information
SR-PCE: Stateful North-Bound API for Tree-SID
Release 7.5.1
Feature Description
The SR-PCE provides a north-bound HTTP-based API to allow communication between
SR-PCE and external clients and applications. The Cisco Crosswork
Optimization Engine is one of the applications that leverage the
SR-PCE.
This release adds stateful north-bound APIs to support real-time monitoring of Tree-SID states on the SR-PCE using a subscription model.
276
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing Path Computation Element
Configuring the North-Bound API on SR-PCE
Table 25: Feature History Table
Feature Name
SR-PCE: North-Bound API for
SRv6 and Flexible Algorithm in
Cisco Optimization Engine (COE) v3.0 release
Release Information
Release 7.3.2
Feature Description
The SR-PCE provides a north-bound HTTP-based API to allow communication between
SR-PCE and external clients and applications. The Cisco Crosswork
Optimization Engine is an application that leverages the
SR-PCE.
This release adds support for the following:
• Reporting of Flexible
Algorithm participation and definitions
• SRv6 topology information
(nodes, links, Node uSIDs and
Adj uSIDs)
• SRv6 uSID list and uB6 SIDs allocated for a policy
The SR-PCE provides a north-bound HTTP-based API to allow communication between SR-PCE and external clients and applications.
Over this API, an external application can leverage the SR-PCE for topology discovery, SR policy discovery, and SR policy instantiation.
The Cisco Crosswork Optimization Engine is an application that leverages the SR-PCE. For more information, refer to the Cisco Crosswork Optimization Engine User Guides .
Use the following commands under PCE configuration mode to configure the API to allow communication between SR-PCE and external clients or applications.
Command Description
.
For more information, refer to the
Cisco Crosswork Optimization
Engine User Guides api authentication { basic | digest } Specify the type of authentication:
• basic – Use HTTP Basic authentication
(plaintext)
• digest – Use HTTP Digest authentication (MD5)
api username password { clear | encrypted } password
Add credentials when connecting to API.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
277
Configure Segment Routing Path Computation Element
Configuring the North-Bound API on SR-PCE
Command
api sibling ipv4 address
Description
Opens a synchronization channel to another PCE in the same high availability (HA) pair.
Note For more information regarding SR-PCE
HA pairs, refer to the Multiple Cisco
SR-PCE HA Pairs chapter of the Cisco
Crosswork Optimization Engine 1.2.1 User
Guide .
Example: Configuring API on SR-PCE pce address ipv4 1.1.1.100
api user admin password encrypted 1304131F0202
!
authentication digest
!
sibling ipv4 1.1.1.200
!
end
The following example shows the current active connections:
RP/0/0/CPU0:pce1# show tcp brief | i 8080
Thu Aug 6 00:40:15.408 PDT
0xe9806fb8 0x60000000 0
0xe94023b8 0x60000000 0
0
0
:::8080
1.1.1.100:50487
0xeb20bb40 0x60000000
0xe98031a0 0x60000000
0
0
0 1.1.1.100:8080
0 0.0.0.0:8080
:::0
1.1.1.200:8080
1.1.1.200:44401
0.0.0.0:0
LISTEN
ESTAB
ESTAB
LISTEN
The first and fourth entries show the API server listening for IPv4 and IPv6 connections.
The second and third entries show the established sibling connection between PCE1 (1.1.1.100) and PCE2
(1.1.1.200).
278
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
C H A P T E R
10
Configure Performance Measurement
Network performance metrics is a critical measure for traffic engineering (TE) in service provider networks.
Network performance metrics include the following:
• Packet loss
• Delay
• Delay variation
• Bandwidth utilization
These network performance metrics provide network operators information about the performance characteristics of their networks for performance evaluation and help to ensure compliance with service level agreements.
The service-level agreements (SLAs) of service providers depend on the ability to measure and monitor these network performance metrics. Network operators can use performance measurement (PM) feature to monitor the network metrics for links and end-to-end TE label switched paths (LSPs).
The following table explains the functionalities supported by performance measurement feature for measuring delay for links or SR policies.
Table 26: Performance Measurement Functionalities
Functionality Details
Profiles You can configure different profiles for different types of delay measurements.
Use the "interfaces" delay profile type for link-delay measurement. The "sr-policy" delay profile type is used for SR policy delay measurements. Delay profile allows you to schedule probe and configure metric advertisement parameters for delay measurement.
Protocols
Probe and burst scheduling
Two-Way Active Measurement Protocol (TWAMP) Light (using RFC 5357 with
IP/UDP encap).
Schedule probes and configure metric advertisement parameters for delay measurement.
Metric advertisements Advertise measured metrics periodically using configured thresholds. Also supports accelerated advertisements using configured thresholds.
Measurement history and counters
Maintain packet delay and loss measurement history, session counters, and packet advertisement counters.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
279
Configure Performance Measurement
Measurement Modes
•
Measurement Modes, on page 280
•
Link Delay Measurement, on page 282
•
Delay Normalization, on page 295
•
Link Anomaly Detection with IGP Penalty, on page 298
•
IP Endpoint Delay Measurement and Liveness Monitoring, on page 299
•
SR Policy End-to-End Delay Measurement , on page 311
•
SR Policy Liveness Monitoring, on page 318
Measurement Modes
The following table compares the different hardware and timing requirements for the measurement modes supported in SR PM.
Table 27: Measurement Mode Requirements
Measurement Mode PTP Clock Synchronization between Sender and Reflector
One-way
Two-way
Loopback
Sender:
PTP-Capable HW and HW
Timestamping
Required
Required
Required
Reflector:
PTP-Capable HW and HW
Timestamping
Required
Required
Not Required
Required
Not Required
Not Required
One-Way
One-way measurement mode provides the most precise form of one-way delay measurement. PTP-capable hardware and hardware timestamping are required on both Sender and Reflector, with PTP Clock
Synchronization between Sender and Reflector.
Delay measurement in one-way mode is calculated as (T2 – T1).
Figure 20: One-Way
The PM query and response for one-way delay measurement can be described in the following steps:
280
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Performance Measurement
Measurement Modes
1.
The local-end router sends PM query packets periodically to the remote side once the egress line card on the router applies timestamps on packets.
2.
The ingress line card on the remote-end router applies time-stamps on packets as soon as they are received.
3.
The remote-end router sends the PM packets containing time-stamps back to the local-end router.
4.
One-way delay is measured using the time-stamp values in the PM packet.
Two-Way
Two-way meaurement mode provides two-way measurements. PTP-capable hardware and hardware timestamping are required on both Sender and Reflector, but PTP clock synchronization between Sender and
Reflector is not required.
Delay measurements in two-way mode are calculated as follows:
• Two-Way Delay = (T4 – T1) – (T3 – T2)
• One-Way Delay = Two-Way Delay/2
Figure 21: Two-Way
The PM query and response for two-way delay measurement can be described in the following steps:
1.
The local-end router sends PM query packets periodically to the remote side once the egress line card on the router applies timestamps on packets.
2.
Ingress line card on the remote-end router applies time-stamps on packets as soon as they are received.
3.
The remote-end router sends the PM packets containing time-stamps back to the local-end router. The remote-end router time-stamps the packet just before sending it for two-way measurement.
4.
The local-end router time-stamps the packet as soon as the packet is received for two-way measurement.
5.
One-way delay and optionally two-way delay is measured using the time-stamp values in the PM packet.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
281
Configure Performance Measurement
Link Delay Measurement
Loopback
Loopback meaurement mode provides two-way and one-way measurements. PTP-capable hardware and hardware timestamping are required on the Sender, but are not required on the Reflector.
Delay measurements in Loopback mode are calculated as follows:
• Round-Trip Delay = (T4 – T1)
• One-Way Delay = Round-Trip Delay/2
Figure 22: Loopback
The PM query and response for Loopback delay measurement can be described in the following steps:
1.
The local-end router sends PM probe packets periodically on the SR Policy.
2.
The probe packets are loopback on the endpoint node (not punted), with no timestamping on endpoint node.
3.
Round-trip Delay = T4 – T1.
Link Delay Measurement
Table 28: Feature History Table
Feature Name Release Information
Link Delay Measurement with IPv6
Link Local Address
Release 7.3.1
Feature Description
The performance measurement for link delay determines the source and destination IP addresses used in the OAM packet based on the IP address of the interface, where the delay measurement operation is enabled. This feature enables using the IPv6 link-local address as the
OAM packet source IP address, when no IPv4 or IPv6 address is configured in the interface.
282
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Performance Measurement
Link Delay Measurement
Feature Name
SR Performance Measurement
Named Profiles
Release Information
Release 7.3.1
Feature Description
You can use this feature to create specific performance measurement delay and liveness profiles, and associate it with an SR policy.
This way, a delay or liveness profile can be associated with a policy for which the performance measurement probes are enabled, and performance measurement is precise, and enhanced.
The performance-measurement delay-profile sr-policy command was updated with the name profile keyword-argument combination.
The performance-measurement liveness-profile sr-policy command was updated with the
name profile keyword-argument combination.
The performance-measurement delay-measurement command was updated with delay-profile name profile .
The performance-measurement liveness-detection command was updated with liveness-profile name profile
The PM for link delay uses the IP/UDP packet format defined in RFC 5357 (TWAMP-Light) for probes.
Two-Way Active Measurement Protocol (TWAMP) adds two-way or round-trip measurement capabilities.
TWAMP employs time stamps applied at the echo destination (reflector) to enable greater accuracy. In the case of TWAMP Light, the Session-Reflector doesn’t necessarily know about the session state. The
Session-Reflector simply copies the Sequence Number of the received packet to the Sequence Number field of the reflected packet. The controller receives the reflected test packets and collects two-way metrics. This architecture allows for collection of two-way metrics.
Usage Guidelines and Restrictions for PM for Link Delay
The following restrictions and guidelines apply for the PM for link delay feature for different links.
• For broadcast links, only point-to-point (P2P) links are supported. P2P configuration on IGP is required for flooding the value.
• For link bundles, the hashing function may select a member link for forwarding but the reply may come from the remote line card on a different member link of the bundle.
• For one-way delay measurement, clocks should be synchronized on two end-point nodes of the link using
PTP.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
283
Configure Performance Measurement
Link Delay Measurement
• Link delay measurement is supported on IPv4 unnumbered interfaces. An IPv4 unnumbered interface is identified by a node ID (a loopback address) and the local SNMP index assigned to the interface. Note that the reply messages could be received on any interface, since the packets are routed at the responder based on the loopback address used to identify the link.
Configuration Example: PM for Link Delay
This example shows how to configure performance-measurement functionalities for link delay as a global default profile. The default values for the different parameters in the PM for link delay is given as follows:
• probe measurement mode : The default measurement mode for probe is two-way delay measurement.
If you are configuring one-way delay measurement, hardware clocks must be synchronized between the local-end and remote-end routers using precision time protocol (PTP). See
for more information.
• protocol : Interface delay measurement using RFC 5357 with IP/UDP encap (TWAMP-Light).
• burst interval : Interval for sending probe packet. The default value is 3000 milliseconds and the range is from 30 to 15000 milliseconds.
• computation interval : Interval for metric computation. Default is 30 seconds; range is 1 to 3600 seconds.
• periodic advertisement : Periodic advertisement is enabled by default.
• periodic-advertisement interval : The default value is 120 seconds and the interval range is from 30 to
3600 seconds.
• periodic-advertisement threshold : Checks the minimum-delay metric change for threshold crossing for periodic advertisement. The default value is 10 percent and the range is from 0 to 100 percent.
• periodic-advertisement minimum change : The default value is 1000 microseconds (usec) and the range is from 0 to 100000 microseconds.
• accelerated advertisement : Accelerated advertisement is disabled by default.
• accelerated-advertisement threshold : Checks the minimum-delay metric change for threshold crossing for accelerated advertisement. The default value is 20 percent and the range is from 0 to 100 percent.
• accelerated-advertisement minimum change : The default value is 500 microseconds and the range is from 0 to 100000 microseconds.
RP/0/0/CPU0:router(config)# performance-measurement delay-profile interfaces
RP/0/0/CPU0:router(config-pm-dm-intf)# probe
RP/0/0/CPU0:router(config-pm-dm-intf-probe)# measurement-mode one-way
RP/0/0/CPU0:router(config-pm-dm-intf-probe)# burst-interval 60
RP/0/0/CPU0:router(config-pm-dm-intf-probe)# computation-interval 60
RP/0/0/CPU0:router(config-pm-dm-intf-probe)# exit
RP/0/0/CPU0:router(config-pm-dm-intf)# advertisement periodic
RP/0/0/CPU0:router(config-pm-dm-intf-adv-per)# interval 120
RP/0/0/CPU0:router(config-pm-dm-intf-adv-per)# threshold 20
RP/0/0/CPU0:router(config-pm-dm-intf-adv-per)# minimum-change 1000
RP/0/0/CPU0:router(config-pm-dm-intf-adv-per)# exit
RP/0/0/CPU0:router(config-pm-dm-intf)# advertisement accelerated
RP/0/0/CPU0:router(config-pm-dm-intf-adv-acc)# threshold 30
RP/0/0/CPU0:router(config-pm-dm-intf-adv-acc)# minimum-change 1000
284
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Performance Measurement
Link Delay Measurement
RP/0/0/CPU0:router(config-pm-dm-intf-adv-per)# exit
Configure the UDP Destination Port
Configuring the UDP port for TWAMP-Light protocol is optional. By default, PM uses port 862 as the
TWAMP-reserved UDP destination port for delay.
The UDP port is configured for each PM measurement probe type (delay, loss, protocol, authentication mode, etc.) on querier and responder nodes. If you configure a different UDP port, the UDP port for each PM measurement probe type must match on the querier and the responder nodes.
Note The same UDP destination port is used for delay measurement for links and SR Policy.
This example shows how to configure the UDP destination port for delay.
Router(config)# performance-measurement
Router(config-perf-meas)# protocol twamp-light
Router(config-pm-protocol)# measurement delay unauthenticated
Router(config-pm-proto-mode)# querier-dst-port 12000
Enable PM for Link Delay Over an Interface
This example shows how to enable PM for link delay over an interface.
RP/0/0/CPU0:router(config)# performance-measurement
RP/0/0/CPU0:router(config-perf-meas)# interface TenGigE0/0/0/0
RP/0/0/CPU0:router(config-pm-intf)# next-hop ipv4 10.10.10.2
// Optional IPv4 or IPv6 next-hop address
RP/0/0/CPU0:router(config-pm-intf)# delay-measurement
RP/0/0/CPU0:router(config-pm-intf-dm)# exit
The source and destination IP addresses used in the OAM packet are determined by the IP address present on the interface where the delay-measurement operation is enabled and the setting of the optional next-hop address.
When the next-hop address is not specified, the following rules apply to determine the source and destination
IP addresses used in the OAM packet:
• If an IPv4 address is configured under the interface, then:
• OAM packet source IP address = Interface's IPv4 address
• OAM packet destination IP address = 127.0.0.0
• Else, if an IPv6 global address is configured under the interface, then:
• OAM packet source IP address = Interface's IPv6 global address
• OAM packet destination IP address = 0::ff:127.0.0.0
• Else, if an IPv6 link-local address is assigned to the interface, then:
• OAM packet source IP address = Interface's IPv6 link-local address
• OAM packet destination IP address = 0::ff:127.0.0.0
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
285
Configure Performance Measurement
Link Delay Measurement
When the next-hop { ipv4 | ipv6 } address is configured, the following rules apply to determine the source and destination IP addresses used in the OAM packet:
• If a next-hop IPv4 address is configured, then:
• OAM packet source IP address = Interface's IPv4 address
• OAM packet destination IP address = Configured next-hop IPv4 address
Note If there is no IPv4 address configured under the interface, then the delay-measurement probe does not send OAM packets.
• If a next-hop IPv6 address is configured, then:
• OAM packet source IP address = Interface's IPv6 global address
• OAM packet destination IP address = Configured next-hop IPv6 address
Note If there is no IPv6 global address configured under the interface, then the delay-measurement probe does not send OAM packets.
This example shows how to enable PM for link delay over an interface with IPv4 address configured: interface TenGigE0/0/0/0 ipv4 address 10.10.10.1 255.255.255.0
performance-measurement interface TenGigE0/0/0/0 delay-measurement
This example shows how to enable PM for link delay over an interface IPv6 address configured: interface TenGigE0/0/0/0 ipv6 address 10:10:10::1/64 performance-measurement interface TenGigE0/0/0/0 delay-measurement
This example shows how to enable PM for link delay over an interface with a specified next-hop IPv4 address: interface TenGigE0/0/0/0 ipv4 address 10.10.10.1 255.255.255.0
performance-measurement interface TenGigE0/0/0/0 next-hop ipv4 10.10.10.2
delay-measurement
This example shows how to enable PM for link delay over an interface with a specified next-hop IPv6 address:
286
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Performance Measurement
Link Delay Measurement interface TenGigE0/0/0/0 ipv6 address 10:10:10::1/64 performance-measurement interface TenGigE0/0/0/0 next-hop ipv6 10:10:10::2 delay-measurement
This example shows how to enable PM for link delay over an interface with only IPv6 link-local address: interface TenGigE0/0/0/0 ipv6 enable performance-measurement interface TenGigE0/0/0/0 delay-measurement
Verification
RP/0/0/CPU0:router# show performance-measurement profile interface
Thu Dec 12 14:13:16.029 PST
-------------------------------------------------------------------------------
0/0/CPU0
-------------------------------------------------------------------------------
Interface Delay-Measurement:
Profile configuration:
Measurement Type
Probe computation interval
Type of services
Burst interval
: Two-Way
: 30 (effective: 30) seconds
: Traffic Class: 6, DSCP: 48
: 3000 (effective: 3000) mSec
Burst count
Encap mode
Payload Type
Destination sweeping mode
Periodic advertisement
Interval
Threshold
Minimum-Change
Advertisement accelerated
Threshold crossing check
: 10 packets
: UDP
: TWAMP-light
: Disabled
: Enabled
: 120 (effective: 120) sec
: 10%
: 500 uSec
: Disabled
: Minimum-delay
RP/0/0/CPU0:router# show performance-measurement summary detail location 0/2/CPU0
Thu Dec 12 14:09:59.162 PST
-------------------------------------------------------------------------------
0/2/CPU0
-------------------------------------------------------------------------------
Total interfaces : 1
Total SR Policies
Total RSVP-TE tunnels
Total Maximum PPS
Total Interfaces PPS
Maximum Allowed Multi-hop PPS
Multi Hop Requested PPS
Dampened Multi Hop Requested PPS
Inuse Burst Interval Adjustment Factor
: 0
: 0
: 2000 pkts/sec
: 0 pkts/sec
: 2000 pkts/sec
: 0 pkts/sec (0% of max allowed)
: 0% of max allowed
: 100% of configuration
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
287
Link Delay Measurement
Interface Delay-Measurement:
Total active sessions
Counters:
Packets:
Total sent
Total received
Errors:
TX:
Reason interface down
Reason no MPLS caps
Reason no IP address
Reason other
RX:
Reason negative delay
Reason delay threshold exceeded
Reason missing TX timestamp
Reason missing RX timestamp
Reason probe full
Reason probe not started
Reason control code error
Reason control code notif
Probes:
Total started
Total completed
Total incomplete
Total advertisements
SR Policy Delay-Measurement:
Total active sessions
Counters:
Packets:
Total sent
Total received
Errors:
TX:
Reason interface down
Reason no MPLS caps
Reason no IP address
Reason other
RX:
Reason negative delay
Reason delay threshold exceeded
Reason missing TX timestamp
Reason missing RX timestamp
Reason probe full
Reason probe not started
Reason control code error
Reason control code notif
Probes:
Total started
Total completed
Total incomplete
Total advertisements
RSVP-TE Delay-Measurement:
Total active sessions
Counters:
Packets:
Total sent
Total received
Errors:
TX:
Reason interface down
Reason no MPLS caps
: 1
: 0
: 0
: 0
: 0
: 0
: 0
: 0
: 0
: 0
: 0
: 0
: 0
: 0
: 0
: 0
: 0
: 0
: 0
: 0
: 0
: 0
: 0
: 0
: 0
: 26
: 26
: 0
: 0
: 0
: 0
: 0
: 0
: 0
: 0
: 0
: 0
: 0
: 0
: 3
: 2
: 0
: 0
288
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Performance Measurement
Configure Performance Measurement
Link Delay Measurement
Reason no IP address
Reason other
RX:
Reason negative delay
Reason delay threshold exceeded
Reason missing TX timestamp
Reason missing RX timestamp
Reason probe full
Reason probe not started
Reason control code error
Reason control code notif
Probes:
Total started
Total completed
Total incomplete
Total advertisements
: 0
: 0
: 0
: 0
: 0
: 0
: 0
: 0
: 0
: 0
: 0
: 0
: 0
: 0
Global Delay Counters:
Total packets sent
Total query packets received
Total invalid session id
Total missing session
: 26
: 26
: 0
: 0
RP/0/0/CPU0:router# show performance-measurement interfaces detail
Thu Dec 12 14:16:09.692 PST
-------------------------------------------------------------------------------
0/0/CPU0
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
0/2/CPU0
-------------------------------------------------------------------------------
Interface Name: GigabitEthernet0/2/0/0 (ifh: 0x1004060)
Delay-Measurement : Enabled
Loss-Measurement : Disabled
Configured IPv4 Address
Configured IPv6 Address
: 10.10.10.2
: 10:10:10::2
Link Local IPv6 Address
Configured Next-hop Address
Local MAC Address
Next-hop MAC Address
Primary VLAN Tag
Secondary VLAN Tag
State
: fe80::3a:6fff:fec9:cd6b
: Unknown
: 023a.6fc9.cd6b
: 0291.e460.6707
: None
: None
: Up
Delay Measurement session:
Session ID : 1
Last advertisement:
Advertised at: Dec 12 2019 14:10:43.138 (326.782 seconds ago)
Advertised reason: First advertisement
Advertised delays (uSec): avg: 839, min: 587, max: 8209, variance: 297
Next advertisement:
Threshold check scheduled in 1 more probe (roughly every 120 seconds)
Aggregated delays (uSec): avg: 751, min: 589, max: 905, variance: 112
Rolling average (uSec): 756
Current Probe:
Started at Dec 12 2019 14:15:43.154 (26.766 seconds ago)
Packets Sent: 9, received: 9
Measured delays (uSec): avg: 795, min: 631, max: 1199, variance: 164
Next probe scheduled at Dec 12 2019 14:16:13.132 (in 3.212 seconds)
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
289
Configure Performance Measurement
Link Delay Measurement
Next burst packet will be sent in 0.212 seconds
Burst packet sent every 3.0 seconds
Probe samples:
Packet Rx Timestamp Measured Delay (nsec)
Dec 12 2019 14:15:43.156
Dec 12 2019 14:15:46.156
Dec 12 2019 14:15:49.156
Dec 12 2019 14:15:52.157
Dec 12 2019 14:15:55.156
689223
876561
913548
1199620
794008
Dec 12 2019 14:15:58.156
Dec 12 2019 14:16:01.157
Dec 12 2019 14:16:04.157
Dec 12 2019 14:16:07.157
631437
656440
658267
736880
You can also use the following commands for verifying the PM for link delay on the local-end router.
Command show performance-measurement history probe interfaces [ interface ] show performance-measurement history aggregated interfaces [ interface ] show performance-measurement history advertisement interfaces [ interface ]
Description
Displays the PM link-delay probe history for interfaces.
Displays the PM link-delay aggregated history for interfaces.
Displays the PM link-delay advertisement history for interfaces.
show performance-measurement counters [interface interface ] [location location-name ]
Displays the PM link-delay session counters.
You can also use the following commands for verifying the PM for link-delay configuration on the remote-end router.
Command Description show performance-measurement responder summary [ location location-name ] show performance-measurement responder interfaces [ interface ] show performance-measurement responder counters [ interface interface location-name ]
] [ location
Displays the PM for link-delay summary on the remote-end router (responder).
Displays PM for link-delay for interfaces on the remote-end router.
Displays the PM link-delay session counters on the remote-end router.
Configure a Static Delay Value on an Interface
You can configure an interface to advertise a static delay value, instead of the measured delay value. When you configure a static delay value, the advertisement is triggered immediately. The average, minimum, and maximum advertised values will use the static delay value, with a variance of 0.
Scheduled probes will continue, and measured delay metrics will be aggregated and stored in history buffer.
However, advertisement threshold checks are suppressed so that there are no advertisements of the actual measured delay values. If the configured static delay value is removed, the next scheduled advertisement threshold check will update the advertised measured delay values.
The static delay value can be configured from 1 to 16777215 microseconds (16.7 seconds).
290
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Performance Measurement
Link Delay Measurement
This example shows how to configure a static delay of 1000 microseconds:
RP/0/0/CPU0:router(config)# performance-measurement
RP/0/0/CPU0:router(config-perf-meas)# interface TenGigE0/0/0/0
RP/0/0/CPU0:router(config-pm-intf)# delay-measurement
RP/0/0/CPU0:router(config-pm-intf-dm)# advertise-delay 1000
Running Configuration performance-measurement interface GigabitEthernet0/0/0/0 delay-measurement advertise-delay 1000
!
!
!
Verification
RP/0/RSP0/CPU0:ios# show performance-measurement interfaces detail
--------------------------------------------------------------------------------
0/0/CPU0
--------------------------------------------------------------------------------
Interface Name: GigabitEthernet0/0/0/0 (ifh: 0x0)
Delay-Measurement : Enabled
. . .
Last advertisement:
Advertised at: Nov 29 2021 21:53:00.656 (7.940 seconds ago)
Advertised reason: Advertise delay config
Advertised delays (uSec): avg: 1000, min: 1000, max: 1000, variance: 0
. . .
SR Performance Measurement Named Profiles
You can create a named performance measurement profile for delay or liveness.
Delay Profile
This example shows how to create a named SR performance measurement delay profile.
Router(config)# performance-measurement delay-profile sr-policy name profile2
Router(config-pm-dm-srpolicy)# probe
Router(config-pm-dm-srpolicy-probe)# burst-interval 60
Router(config-pm-dm-srpolicy-probe)# computation-interval 60
Router(config-pm-dm-srpolicy-probe)# protocol twamp-light
Router(config-pm-dm-srpolicy-probe)# tos dscp 63
Router(config-pm-dm-srpolicy)# advertisement
Router(config-pm-dm-srpolicy-adv)# periodic
Router(config-pm-dm-srpolicy-adv-per)# interval 60
Router(config-pm-dm-srpolicy-adv-per)# minimum-change 1000
Router(config-pm-dm-srpolicy-adv-per)# threshold 20
Router(config-pm-dm-srpolicy-adv-per)# commit
Apply the delay profile for an SR Policy.
Router(config)# segment-routing traffic-eng
Router(config-sr-te)# policy TEST
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
291
Configure Performance Measurement
Link Delay Measurement
Router(config-sr-te-policy)# color 4 end-point ipv4 10.10.10.10
Router(config-sr-te-policy)# performance-measurement
Router(config-sr-te-policy-perf-meas)# delay-measurement delay-profile name profile2
Router(config-sr-te-policy)#candidate-paths
Router(config-sr-te-policy-path)#preference 100
Router(config-sr-te-policy-path-pref)#explicit segment-list LIST1
Router(config-sr-te-pp-info)#weight 2
Router(config-sr-te-policy-path-pref)#explicit segment-list LIST2
Router(config-sr-te-pp-info)#weight 3
Running Configuration
Router# show run segment-routing traffic-eng policy TEST segment-routing traffic-eng policy TEST color 4 end-point ipv4 10.10.10.10
candidate-paths preference 100 explicit segment-list LIST1 weight 2
!
explicit segment-list LIST2
!
weight 3
!
!
performance-measurement delay-measurement delay-profile name profile2
Verification
Router# show performance-measurement profile named-profile delay sr-policy name profile2
----------------------------
0/RSP0/CPU0
----------------------------
SR Policy Delay Measurement Profile Name: profile2
Profile configuration:
Measurement mode
Protocol type
Encap mode
Type of service:
: One-way
: TWAMP-light
: UDP
PM-MPLS traffic class
TWAMP-light DSCP
Probe computation interval
Burst interval
Packets per computation interval
Periodic advertisement
Interval
Threshold
Minimum-change
Advertisement accelerated
: 6
: 63
: 60 (effective: 60) seconds
: 60 (effective: 60) mSec
: 1000
: Enabled
: 60 (effective: 60) sec
: 20%
: 1000 uSec
: Disabled
Advertisement logging:
Delay exceeded
Threshold crossing check
Router alert
Destination sweeping mode
Liveness detection parameters:
Multiplier
Logging state change
: Disabled (default)
: Maximum-delay
: Disabled (default)
: Disabled
: 3
: Disabled
292
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Performance Measurement
Link Delay Measurement
On-Demand SR Policy
Router(config-sr-te)# on-demand color 20
Router(config-sr-te-color)# performance-measurement delay-measurement
Router(config-sr-te-color-delay-meas)# delay-profile name profile2
Router(config-sr-te-color-delay-meas)# commit
Running Configuration
Router# show run segment-routing traffic-eng on-demand color 20 segment-routing traffic-eng on-demand color 20 performance-measurement delay-measurement delay-profile name profile2
Liveness Profile
This example shows how to create a named SR performance measurement liveness profile.
Router(config)# performance-measurement liveness-profile sr-policy name profile3
Router(config-pm-ld-srpolicy)# probe
Router(config-pm-ld-srpolicy-probe)# burst-interval 60
Router(config-pm-ld-srpolicy-probe)# measurement-mode loopback
Router(config-pm-ld-srpolicy-probe)# tos dscp 10
Router(config-pm-ld-srpolicy-probe)# liveness-detection
Router(config-pm-ld-srpolicy-probe)# multiplier 5
Router(config-pm-ld-srpolicy-probe)# commit
Apply the liveness profile for the SR policy
This example shows how to enable PM for SR policy liveness for a specific policy.
For the same policy, you cannot enable delay-measurement (delay-profile) and liveness-detection
(liveness-profile) at the same time. For example, if delay measurement is enabled, use the no delay-measurement command to disable it, and then enable the following command for enabling liveness detection.
Router(config)# segment-routing traffic-eng
Router(config-sr-te)# policy TRST2
Router(config-sr-te-policy)# color 40 end-point ipv4 20.20.20.20
Router(config-sr-te-policy)#candidate-paths
Router(config-sr-te-policy-path)#preference 50
Router(config-sr-te-policy-path-pref)#explicit segment-list LIST3
Router(config-sr-te-pp-info)#weight 2
Router(config-sr-te-policy-path-pref)#explicit segment-list LIST4
Router(config-sr-te-pp-info)#weight 3
Router(config-sr-te-policy)# performance-measurement
Router(config-sr-te-policy-perf-meas)# liveness-detection liveness-profile name profile3
Running Configuration
Router# show run segment-routing traffic-eng policy TRST2 segment-routing traffic-eng policy TRST2 color 40 end-point ipv4 20.20.20.20
candidate-paths preference 50 explicit segment-list LIST3
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
293
Configure Performance Measurement
Link Delay Measurement
!
weight 2
!
!
!
explicit segment-list LIST4 weight 3 performance-measurement liveness-detection
!
liveness-profile name profile3
Verification
Router# show performance-measurement profile named-profile delay sr-policy name profile3
-----------
0/RSP0/CPU0
-----------
SR Policy Liveness Detection Profile Name: profile1
Profile configuration:
Measurement mode : Loopback
: TWAMP-light Protocol type
Type of service:
TWAMP-light DSCP : 10
Burst interval
Destination sweeping mode
Liveness detection parameters:
Multiplier
Logging state change
: 60 (effective: 60) mSec
: Disabled
: 3
: Disabled
SR Policy Liveness Detection Profile Name: profile3
Profile configuration:
Measurement mode
Protocol type
Type of service:
TWAMP-light DSCP
: Loopback
: TWAMP-light
Burst interval
Destination sweeping mode
Liveness detection parameters:
: 10
: 60 (effective: 60) mSec
: Disabled
Multiplier
Logging state change
: 3
: Disabled
On-Demand SR Policy
For the same policy, you cannot enable delay-measurement (delay-profile) and liveness-detection
(liveness-profile) at the same time. For example, to disable delay measurement, use the no delay-measurement command, and then enable the following command for enabling liveness detection.
Router(config-sr-te)#on-demand color 30
Router(config-sr-te-color)#performance-measurement
Router(config-sr-te-color-pm)# liveness-detection liveness-profile name profile1
Router(config-sr-te-color-delay-meas)# commit
Running Configuration
Router# show run segment-routing traffic-eng on-demand color 30 segment-routing traffic-eng on-demand color 30 performance-measurement liveness-detection
294
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Performance Measurement
Delay Normalization
!
liveness-profile name profile3
Verification
Router# show performance-measurement profile named-profile liveness sr-policy name profile3
--------------------
0/RSP0/CPU0
--------------------
SR Policy Liveness Detection Profile Name: profile3
Profile configuration:
Measurement mode : Loopback
: TWAMP-light Protocol type
Type of service:
TWAMP-light DSCP
Burst interval
Destination sweeping mode
: 10
: 60 (effective: 60) mSec
: Disabled
Liveness detection parameters:
Multiplier
Logging state change
: 3
: Disabled
Delay Normalization
Table 29: Feature History Table
Feature Name
SR-TE Delay Normalization for
OSPF
Release Information
Release 7.3.1
Feature Description
This feature extends the current
Delay Normalization feature to support OSPF.
Performance measurement (PM) measures various link characteristics like packet loss and delay. Such characteristics can be used by IS-IS as a metric for Flexible Algorithm computation. Low latency routing using dynamic delay measurement is one of the primary use cases for Flexible Algorithm technology.
Delay is measured in microseconds. If delay values are taken as measured and used as link metrics during the
IS-IS topology computation, some valid ECMP paths might be unused because of the negligible difference in the link delay.
The Delay Normalization feature computes a normalized delay value and uses the normalized value instead.
This value is advertised and used as a metric during the Flexible Algorithm computation.
The normalization is performed when the delay is received from the delay measurement component. When the next value is received, it is normalized and compared to the previous saved normalized value. If the values are different, then the LSP generation is triggered.
The following formula is used to calculate the normalized value:
• Dm – measured Delay
• Int – configured normalized Interval
• Off – configured normalized Offset (must be less than the normalized interval Int)
• Dn – normalized Delay
• a = Dm / Int (rounded down)
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
295
Configure Performance Measurement
Delay Normalization
• b = a * Int + Off
If the measured delay (Dm) is less than or equal to b , then the normalized delay (Dn) is equal to b . Otherwise,
Dn is b + Int .
Example
The following example shows a low-latency service. The intent is to avoid high-latency links (1-6, 5-2). Links
1-2 and 5-6 are both low-latency links. The measured latency is not equal, but the difference is insignificant.
We can normalize the measured latency before it is advertised and used by IS-IS. Consider a scenario with the following:
• Interval = 10
• Offset = 3
The measured delays will be normalized as follows:
• Dm = 29 a = 29 / 10 = 2 (2.9, rounded down to 2) b = 2 * 10 + 3 = 23
In this case, Dm (29) is greater than b (23); so Dn is equal to b + I (23 + 10) = 33
• Dm = 31 a = 31 / 10 = 3 (3.1, rounded down to 3) b = 3 * 10 + 3 = 33
In this case, Dm (31) is less than b (33); so Dn is b = 33
296
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Performance Measurement
Delay Normalization
The link delay between 1-2 and 5-6 is normalized to 33.
Configuration
Delay normalization is disabled by default. To enable and configure delay normalization, use the delay
normalize interval interval [ offset offset ] command.
• interval – The value of the normalize interval in microseconds.
• offset – The value of the normalized offset in microseconds. This value must be smaller than the value of normalized interval.
IS-IS Configuration router isis 1 interface GigEth 0/0/0/0 delay normalize interval 10 offset 3 address-family ipv4 unicast metric 77
OSPF Configuration router ospf 1 area 0 interface GigabitEthernet0/0/0/0 delay normalize interval 10 offset 3
!
!
!
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
297
Configure Performance Measurement
Link Anomaly Detection with IGP Penalty
Link Anomaly Detection with IGP Penalty
Table 30: Feature History Table
Feature Name
Link Anomaly Detection with
IGP Penalty
Release Information
Release 7.4.1
Feature Description
This feature allows you to define thresholds above the measured delay that is considered
“anomalous” or unusual. When this threshold is exceeded, an anomaly
(A) bit/flag is set along with link delay attribute that is sent to clients.
Customers might experience performance degradation issues, such as increased latency or packet loss on a link. Degraded links might be difficult to troubleshoot and can affect applications, especially in cases where traffic is sent over multiple ECMP paths where one of those paths is degraded.
The Anomaly Detection feature allows you to define a delay anomaly threshold to identify unacceptable link delays. Nodes monitor link performance using link delay monitoring probes. The measured value is compared against the delay anomaly threshold values. When the upper bound threshold is exceeded, the link is declared
“abnormal”, and performance measurement sets an anomaly bit (A-bit). When IGP receives the A-bit, IGP can automatically increase the IGP metric of the link by a user-defined amount to make this link undesirable or unusable. When the link recovers (lower bound threshold), PM resets the A-bit.
For information on IGP penality, see
Usage Guidelines and Limitations
This feature is not active when narrow metrics are configured because the performance measurement advertisement requires the “wide” metric type length values.
Configuration Example
The following example shows how to configure the upper and lower anomoly thresholds. The range for upper_bound and lower_bound is from 1 to 200,000 microseconds. The lower_bound value must be less than the upper_bound value.
RP/0/0/CPU0:router(config)# performance-measurement delay-profile interfaces default
RP/0/0/CPU0:router(config-pm-dm-intf)# advertisement
RP/0/0/CPU0:router(config-pm-dm-intf-adv)# anomaly-check upper-bound 5000 lower-bound 1000
RP/0/0/CPU0:router(config-pm-dm-intf-adv)# commit
Running Configuration performance-measurement delay-profile interfaces default advertisement anomaly-check
!
!
!
!
upper-bound 5000 lower-bound 1000 end
298
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Performance Measurement
IP Endpoint Delay Measurement and Liveness Monitoring
IP Endpoint Delay Measurement and Liveness Monitoring
Table 31: Feature History Table
Feature Name
IP Endpoint Delay Measurement and Liveness Monitoring
Release Information
Release 7.4.1
Feature Description
This feature measures the end-to-end delay and monitors liveness of a specified IP endpoint node, including VRF-aware
(awareness of multiple customers belonging to different VRFs).
This feature is supported on IPv4,
IPv6, and MPLS data planes.
The Segment Routing Performance Measurement for IP Endpoint feature dynamically measures the end-to-end delay and liveness towards a specified IP endpoint. IP endpoints can be located in default or non-default VRFs.
The following are benefits of this feature:
• Performance values (delay metrics and liveness states) are computed using TWAMP light, which is a commonly supported protocol.
• Performance values, including Histograms, are sent out using Streaming Telemetry, which is a push-based data collection technique, rather than a manual data collection technique.
• The feature is applicable to multiple data plane types (e.g. IPv4, IPv6, and MPLS).
Configuring IP Endpoint Performance Measurement
Configuring Probe Endpoint Source and Destination Addresses
Observe the following usage guidelines and limitations:
• The endpoint of a probe is specified with an IP address. IPv4 and IPv6 endpoint addresses are supported.
• The endpoint of a probe can be any IP address reachable by the sender. For example, a local interface or a remote node or host located within an operator's network or reachable through a VRF.
• The endpoint's IP address can be located in the global routing table or under a user-specified VRF routing table.
• VRF-awareness allows operators to deploy probes in the following scenarios:
• Managed Customer Equipment (CE) scenarios:
• PE to CE probes
• CE to CE probes
• Unmanaged Customer Equipment (CE) scenarios:
• PE to PE probes
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
299
Configure Performance Measurement
Configuring IP Endpoint Performance Measurement
• PE to PE (source from PE-CE interface) probes
• SRv6 locator prefix and VRF SRv6 locator/function (uDT4/uDT6) as IPv6 endpoint of a probe is not supported.
• The endpoint's IP address can be reached through an IP path, MPLS LSP, or IP tunnel (GRE).
• When the endpoint is reachable using an MPLS LSP (for example, SR, LDP, RSVP-TE, SR Policy), the forwarding stage imposes the corresponding MPLS transport labels.
• When the endpoint is reachable via a GRE tunnel, the forwarding stage imposes the corresponding GRE header.
• PM probe over GREv4 is supported.
• When the endpoint is reachable via a VRF in an MPLS network, the forwarding stage imposes the corresponding MPLS service labels. In the forward path, sender node uses the configured VRF for the endpoint address. In the return path, reflector node derives the VRF based on which incoming VRF label the probe packet is received with.
Use the performance-measurement endpoint { ipv4 | ipv6 } ip_addr [ vrf WORD ] source-address { ipv4 | ipv6 } ip_addr command to configure a probe endpoint source and destination addresses on a sender node.
Example:
Router(config)# performance-measurement endpoint ipv4 1.1.1.5 source-address ipv4 1.1.1.1
Router(config)# performance-measurement endpoint ipv4 10.10.10.100 vrf green source-address ipv4 1.1.1.1
Configuring Probe Description
Use the performance-measurement endpoint { ipv4 | ipv6 } ip_addr [ vrf WORD ] description LINE command to configure a probe description.
Example:
Router(config)# performance-measurement endpoint ipv4 1.1.1.5 description Probe to 1.1.1.5
Router(config)# performance-measurement endpoint ipv4 10.10.10.100 vrf green description
Probe to 10.10.10.100
Configuring Probe Segment-lists
Observe the following usage guidelines and limitations:
• You can specify a custom labeled path via one or more user-configured segment-list. User-configured segment-list represents the forwarding path from sender to reflector when probe configured in delay-measurement mode.
• User-configured segment-list can also represent the reverse path (reflector to sender) when probe configured in livenes-detection mode.
• Up to 128 segment-lists can be configured under a probe.
• An additional PM session is created for each segment-list.
300
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Performance Measurement
Configuring IP Endpoint Performance Measurement
• Examples of the custom segment-list include:
• Probe in delay-measurement mode with segment-list that includes Flex-Algo prefix SID of the end-point
• Probe in liveness-detection mode with segment-list that includes both Flex-Algo prefix SID of the end-point and the sender
• Probe in delay-measurement mode with segment-list that includes SID-list with labels to reach the end-point or the sender (forward direction)
• Probe in liveness-detection mode with segment-list that includes SID-list with labels to reach the end-point and then back to sender (forward and reverse directions, respectively)
• Probe in delay-measurement mode with segment-list that includes BSID associated with SR policy to reach the end-point
• Endpoint segment list configuration not supported under non-default VRF.
Segment-lists are configured under segment-routing traffic-eng segment-list submode. See
Policy with Explicit Path, on page 182
for details about configuring segment lists.
Use the performance-measurement endpoint { ipv4 | ipv6 } ip_addr [ vrf WORD ] segment-list name WORD command to configure probe segment-lists.
Example:
Router(config)# performance-measurement endpoint ipv4 1.1.1.5 segment-list name SIDLIST1
Router(config)# performance-measurement endpoint ipv4 10.10.10.100 vrf green segment-list name SIDLIST1
Enabling Delay Measurement
Observe the following usage guidelines and limitations:
• Probe dynamically measures end-to-end performance delay values of an IP endpoint.
• Probe can be configured in either liveness-monitoring or delay-measurement modes; not both concurrently.
Use the performance-measurement endpoint { ipv4 | ipv6 } ip_addr [ vrf WORD ] delay-measurement command to enable delay measurement.
Example:
Router(config)# performance-measurement endpoint ipv4 1.1.1.5 delay-measurement
Router(config)# performance-measurement endpoint ipv4 10.10.10.100 vrf green delay-measurement
Assigning a Delay-Profile to the Probe
Use the performance-measurement endpoint { ipv4 | ipv6 } ip_addr [ vrf WORD ] delay-measurement
delay-profile name WORD command to assign a delay-profile associated with the probe.
Example:
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
301
Configure Performance Measurement
Configuring IP Endpoint Performance Measurement
Router(config)# performance-measurement endpoint ipv4 1.1.1.5 delay-measurement delay-profile name PROFILE1
Router(config)# performance-measurement endpoint ipv4 10.10.10.100 vrf green delay-measurement delay-profile name PROFILE1
Enabling Liveness Detection
Observe the following usage guidelines and limitations:
• Probe dynamically monitors liveness of an IP endpoint.
• Liveness monitoring uses "self-addressed" PM IP packets crafted by the sender (where IP DA = sender's own IP address); this mode of operation is referred as "loopback mode".
• Liveness monitoring applies to endpoints reachable through MPLS LSP or IP tunnel.
• Liveness monitoring does not apply to endpoints reachable through IP path since sender's self-addressed
PM IP packets would not be able to reach the intended endpoint destination.
• Probe can be configured in either liveness-monitoring or delay-measurement modes; not both concurrently.
Use the performance-measurement endpoint { ipv4 | ipv6 } ip_addr [ vrf WORD ] liveness-detection command to enable liveness detection.
Example:
Router(config)# performance-measurement endpoint ipv4 1.1.1.5 liveness-detection
Router(config)# performance-measurement endpoint ipv4 10.10.10.100 vrf green liveness-detection
Assigning Liveness-Profile to the Probe
Use the performance-measurement endpoint { ipv4 | ipv6 } ip_addr [ vrf WORD ] liveness-detection
liveness-profile name WORD command to configure the liveness-profile associated with the probe.
Example:
Router(config)# performance-measurement endpoint ipv4 1.1.1.5 liveness-detection liveness-profile name PROFILE3
Router(config)# performance-measurement endpoint ipv4 10.10.10.100 vrf green liveness-detection liveness-profile name PROFILE3
Collecting IP Endpoint Probe Statistics
• Statistics associated with the probe (computed delay metrics and liveness state) are available via Histogram and Streaming Telemetry.
• Model Driven Telemetry (MDT) is supported for the following data:
• Summary, endpoint, session, and counter show command bags
• History buffers data
302
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Performance Measurement
IP Endpoint Performance Measurement Use Cases
• Model Driven Telemetry (MDT) and Event Driven Telemetry (EDT) are supported for the following data:
• Delay metrics computed in the last probe computation-interval (event: probe-completed)
• Delay metrics computed in the last aggregation-interval; i.e. end of the periodic advertisement-interval
(event: advertisement-interval expired)
• Delay metrics last notified (event: notification-triggered)
• The following xpaths for MDT/EDT are supported:
• Cisco-IOS-XR-perf-meas-oper:performance-measurement/nodes/node/endpoints/ endpoint-delay/endpoint-last-probes
• Cisco-IOS-XR-perf-meas-oper:performance-measurement/nodes/node/endpoints/ endpoint-delay/endpoint-last-aggregations
• Cisco-IOS-XR-perf-meas-oper:performance-measurement/nodes/node/endpoints/ endpoint-delay/endpoint-last-advertisements
IP Endpoint Performance Measurement Use Cases
The following use-cases show different ways to deploy delay measurement and liveness detection for IP endpoints.
Use-Case 1: Delay Measurement Probe Toward an IP Endpoint Reachable in the Global Routing Table
The following figure illustrates a delay measurement probe toward an IP endpoint reachable in the global routing table. The network interconnecting the sender and the reflector provides plain IP connectivity.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
303
Configure Performance Measurement
IP Endpoint Performance Measurement Use Cases
Figure 23: Delay Measurement Probe Toward an IP Endpoint Reachable in the Global Routing Table
Configuration
RouterA(config)# performance-measurement
RouterA(config-perf-meas)# endpoint ipv4 1.1.1.5
RouterA(config-pm-ep)# source-address ipv4 1.1.1.1
RouterA(config-pm-ep)# delay-measurement
RouterA(config-pm-ep-dm)# exit
RouterA(config-pm-ep)# exit
RouterA(config-perf-meas)# delay-profile endpoint default
RouterA(config-pm-dm-ep)# probe
RouterA(config-pm-dm-ep-probe)# measurement-mode one-way
Running Configuration performance-measurement endpoint ipv4 1.1.1.5
source-address ipv4 1.1.1.1
delay-measurement
!
!
delay-profile endpoint default
!
!
probe measurement-mode one-way
!
Verification
RouterA# show performance-measurement endpoint ipv4 1.1.1.5
----------------------------------------------------------------------------------------------------------------------------------------------------------------
304
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Performance Measurement
IP Endpoint Performance Measurement Use Cases
0/RSP0/CPU0
----------------------------------------------------------------------------------------------------------------------------------------------------------------
Endpoint name: IPv4-1.1.1.5-vrf-default
Source address : 1.1.1.1
VRF name
Delay-measurement
Description
: default
: Enabled
: Not set
Profile Keys:
Profile name
Profile type
: default
: Endpoint Delay Measurement
Segment-list : None
Delay Measurement session:
Session ID : 33554433
Last advertisement:
No advertisements have occured
Next advertisement:
Threshold check scheduled in 4 more probes (roughly every 120 seconds)
No probes completed
Current computation:
Started at: Jul 19 2021 16:28:06.723 (17.788 seconds ago)
Packets Sent: 6, received: 0
Measured delays (uSec): avg: 0, min: 0, max: 0, variance: 0
Next probe scheduled at: Jul 19 2021 16:28:36.718 (in 12.207 seconds)
Next burst packet will be sent in 0.207 seconds
Burst packet sent every 3.0 seconds
Use-Case 2: Delay Measurement Probe Toward an IP Endpoint Reachable in a User-Specified VRF
The following figure illustrates a delay measurement probe toward an IP endpoint reachable in a user-specified
L3VPN's VRF routing table. The L3VPN ingress PE (Router A) acts as the sender. The reflector is located in a CE device behind the L3VPN egress PE (Router E). The network interconnecting the L3VPN PEs provides
MPLS connectivity with Segment Routing.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
305
Configure Performance Measurement
IP Endpoint Performance Measurement Use Cases
Figure 24: Delay Measurement Probe Toward an IP Endpoint Reachable in a User-Specified VRF
Configuration
RouterA(config)# performance-measurement
RouterA(config-perf-meas)# endpoint ipv4 10.10.10.100 vrf green
RouterA(config-pm-ep)# source-address ipv4 1.1.1.1
RouterA(config-pm-ep)# delay-measurement
RouterA(config-pm-ep-dm)# exit
RouterA(config-pm-ep)# exit
RouterA(config-perf-meas)# delay-profile endpoint default
RouterA(config-pm-dm-ep)# probe
RouterA(config-pm-dm-ep-probe)# measurement-mode one-way
Running Configuration performance-measurement endpoint ipv4 10.10.10.100 vrf green source-address ipv4 1.1.1.1
delay-measurement
!
!
delay-profile endpoint default probe measurement-mode one-way
306
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Performance Measurement
IP Endpoint Performance Measurement Use Cases
!
!
!
Verification
RouterA# show performance-measurement endpoint vrf green
----------------------------------------------------------------------------------------------------------------------------------------------------------------
0/RSP0/CPU0
----------------------------------------------------------------------------------------------------------------------------------------------------------------
Endpoint name: IPv4-10.10.10.100-vrf-green
Source address : 1.1.1.1
VRF name
Delay-measurement
:
: green
Enabled
Description
Profile Keys:
Profile name
Profile type
: Not set
: default
: Endpoint Delay Measurement
Segment-list
Delay Measurement session:
Session ID
: None
: 33554434
Last advertisement:
No advertisements have occured
Next advertisement:
Advertisement not scheduled as the probe is not running
Current computation:
Not running: Unable to resolve (non-existing) vrf
Use Case 3: Delay Measurement Probe Toward an IP Endpoint Using Custom Labeled Paths
The following figure illustrates a delay measurement probe toward an IP endpoint learned by the IGP. The network interconnecting the sender and reflector provides MPLS connectivity with Segment Routing.
The IP endpoint is advertised with multiple SR algorithms (Algo 0 and Flex Algo 128). The probe is configured with two custom-labeled paths in order to monitor the LSP for each algorithm separately.
Figure 25: Delay Measurement Probe Toward an IP Endpoint Using Custom Labeled Paths
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
307
IP Endpoint Performance Measurement Use Cases
Note The probe response messages are not shown in the above figure.
Configuration
RouterA(config)# segment-routing
RouterA(config-sr)# traffic-eng
RouterA(config-sr-te)# segment-list name SIDLIST1-Algo0
RouterA(config-sr-te-sl)# index 10 mpls label 16005
RouterA(config-sr-te-sl)# exit
RouterA(config-sr-te)# segment-list name SIDLIST2-FlexAlgo128
RouterA(config-sr-te-sl)# index 10 mpls label 16085
RouterA(config-sr-te-sl)# exit
RouterA(config-sr-te)# exit
RouterA(config-sr)# exit
RouterA(config)# performance-measurement
RouterA(config-perf-meas)# endpoint ipv4 1.1.1.5
RouterA(config-pm-ep)# source-address ipv4 1.1.1.1
RouterA(config-pm-ep)# segment-list name SIDLIST1-Algo0
RouterA(config-pm-ep-sl)# exit
RouterA(config-pm-ep)# segment-list name SIDLIST2-FlexAlgo128
RouterA(config-pm-ep-sl)# exit
RouterA(config-pm-ep)# delay-measurement
RouterA(config-pm-ep-dm)# exit
RouterA(config-pm-ep)# exit
RouterA(config-perf-meas)# delay-profile endpoint default
RouterA(config-pm-dm-ep)# probe
RouterA(config-pm-dm-ep-probe)# measurement-mode one-way
Running Configuration segment-routing traffic-eng segment-list SIDLIST1-Algo0 index 10 mpls label 16005
!
segment-list SIDLIST2-FlexAlgo128 index 10 mpls label 16085
!
!
!
!
performance-measurement endpoint ipv4 1.1.1.5
segment-list name SIDLIST1-Algo0
!
segment-list name SIDLIST2-FlexAlgo128
!
source-address ipv4 1.1.1.1
delay-measurement
!
!
delay-profile endpoint default
!
!
!
probe measurement-mode one-way
Verification
308
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Performance Measurement
Configure Performance Measurement
IP Endpoint Performance Measurement Use Cases
RouterA# show performance-measurement endpoint ipv4 1.1.1.5
----------------------------------------------------------------------------------------------------------------------------------------------------------------
0/RSP0/CPU0
----------------------------------------------------------------------------------------------------------------------------------------------------------------
Endpoint name: IPv4-1.1.1.5-vrf-default
Source address : 1.1.1.1
VRF name
Delay-measurement
Description
Profile Keys:
: default
: Enabled
: Not set
Profile name
Profile type
: default
: Endpoint Delay Measurement
Segment-list : None
Delay Measurement session:
Session ID : 33554433
Last advertisement:
No advertisements have occured
Next advertisement:
Threshold check scheduled in 4 more probes (roughly every 120 seconds)
No probes completed
Current computation:
Started at: Jul 19 2021 16:31:53.827 (15.844 seconds ago)
Packets Sent: 6, received: 0
Measured delays (uSec): avg: 0, min: 0, max: 0, variance: 0
Next probe scheduled at: Jul 19 2021 16:32:22.957 (in 13.286 seconds)
Next burst packet will be sent in 1.286 seconds
Burst packet sent every 3.0 seconds
Segment-list
Delay Measurement session:
Session ID
Last advertisement:
: SIDLIST1-Algo0
: 33554435
No advertisements have occured
Next advertisement:
Threshold check scheduled in 4 more probes (roughly every 120 seconds)
No probes completed
Current computation:
Started at: Jul 19 2021 16:31:53.827 (15.844 seconds ago)
Packets Sent: 4, received: 0
Measured delays (uSec): avg: 0, min: 0, max: 0, variance: 0
Next probe scheduled at: Jul 19 2021 16:32:22.957 (in 13.286 seconds)
Next burst packet will be sent in 2.940 seconds
Burst packet sent every 3.0 seconds
Segment-list : SIDLIST2-FlexAlgo128
Delay Measurement session:
Session ID : 33554436
Last advertisement:
No advertisements have occured
Next advertisement:
Threshold check scheduled in 4 more probes (roughly every 120 seconds)
No probes completed
Current computation:
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
309
Configure Performance Measurement
IP Endpoint Performance Measurement Use Cases
Started at: Jul 19 2021 16:31:53.827 (15.844 seconds ago)
Packets Sent: 4, received: 0
Measured delays (uSec): avg: 0, min: 0, max: 0, variance: 0
Next probe scheduled at: Jul 19 2021 16:32:22.957 (in 13.286 seconds)
Next burst packet will be sent in 2.940 seconds
Burst packet sent every 3.0 seconds
Use-Case 4: Liveness Detection Probe Toward an IP Endpoint
IP endpoint liveness detection leverages the loopback measurement-mode. The following workflow describes the sequence of events.
1.
The sender creates and transmits the PM probe packets.
The IP destination address (DA) on the probe packets is set to the loopback value of the sender itself.
The transmit timestamp (T1) is added to the payload.
The probe packet is encapsulated with the label corresponding to the endpoint.
2.
The network delivers the PM probe packets following the LSP toward the endpoint.
3.
The end-point receives the PM probe packets.
Packets are forwarded back to the sender based on the forwarding entry associated with the IP DA of the
PM probe packet. If an LSP exists, the probe packet is encapsulated with the label of the sender.
4.
The sender node receives the PM probe packets.
The received timestamp (T4) stored.
If the sender node doesn't receive the specified number of probe packets (based on the configured multiplier), the sender node declares the PM session as down.
The following figure illustrates a liveness detection probe toward an IP endpoint learned by the IGP. The network interconnecting the sender and reflector provides MPLS connectivity with Segment Routing.
The liveness detection multiplier is set to 5 to specify the number of consecutive missed probe packets before the PM session is declared as down.
Figure 26: IP Endpoint Liveness Detection
310
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Performance Measurement
SR Policy End-to-End Delay Measurement
Configuration
RouterA(config)# performance-measurement
RouterA(config-perf-meas)# endpoint ipv4 1.1.1.5
RouterA(config-pm-ep)# source-address ipv4 1.1.1.1
RouterA(config-pm-ep)# liveness-detection
RouterA(config-pm-ep-ld)# exit
RouterA(config-pm-ep)# exit
RouterA(config-perf-meas)# liveness-profile endpoint default
RouterA(config-pm-ld-ep)# liveness-detection
RouterA(config-pm-ld-ep-ld)# multiplier 5
RouterA(config-pm-ld-ep-ld)# exit
RouterA(config-pm-ld-ep)# probe
RouterA(config-pm-ld-ep-probe)# measurement-mode loopback
Running Configuration performance-measurement endpoint ipv4 1.1.1.5
source-address ipv4 1.1.1.1
liveness-detection
!
!
liveness-profile endpoint default liveness-detection
!
!
!
end multiplier 5
!
probe measurement-mode loopback
Verification
RouterA# show performance-measurement endpoint ipv4 1.1.1.5
--------------------------------------------------------------------------------
0/RSP0/CPU0
--------------------------------------------------------------------------------
Endpoint name: IPv4-1.1.1.5-vrf-default
Source address
VRF name
Liveness Detection
Profile Keys:
: 1.1.1.1
: default
: Enabled
Profile name
Profile type
: default
: Endpoint Liveness Detection
Segment-list
Session State: Down
Missed count: 0
: None
SR Policy End-to-End Delay Measurement
The PM for SR Policy uses the IP/UDP packet format defined in RFC 5357 (TWAMP-Light) for probes.
Two-Way Active Measurement Protocol (TWAMP) adds two-way or round-trip measurement capabilities.
TWAMP employs time stamps applied at the echo destination (reflector) to enable greater accuracy. In the case of TWAMP Light, the Session-Reflector doesn’t necessarily know about the session state. The
Session-Reflector simply copies the Sequence Number of the received packet to the Sequence Number field
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
311
Configure Performance Measurement
SR Policy End-to-End Delay Measurement of the reflected packet. The controller receives the reflected test packets and collects two-way metrics. This architecture allows for collection of two-way metrics.
The extended TE link delay metric (minimum-delay value) can be used to compute paths for SR policies as an optimization metric or as an accumulated delay bound.
There is a need to monitor the end-to-end delay experienced by the traffic sent over an SR policy to ensure that the delay does not exceed the requested “upper-bound” and violate SLAs. You can verify the end-to-end delay values before activating the candidate-path or the segment lists of the SR policy in forwarding table, or to deactivate the active candidate-path or the segment lists of the SR policy in forwarding table.
Note The end-to-end delay value of an SR policy will be different than the path computation result (for example, the sum of TE link delay metrics) due to several factors, such as queuing delay within the routers.
Restrictions and Usage Guidelines for PM for SR Policy Delay
Hardware clocks must be synchronized between the querier and the responder nodes of the link using PTP for one-way delay measurement.
Configuring Performance Measurement Parameters
This example shows how to configure performance-measurement parameters for SR policy delay as a global default profile. The default values for the different parameters in the PM for SR policy delay is given as follows:
• probe : The default mode for probe is one-way delay measurement. Two-way delay and loopback modes are supported. See
Measurement Modes, on page 280
for more information.
• burst interval : Interval for sending probe packet. The default value is 3000 milliseconds and the range is from 30 to 15000 milliseconds.
• computation interval : Interval for metric computation. Default is 30 seconds; range is 1 to 3600 seconds.
• protocol :
• twamp-light : SR Policy delay measurement using RFC 5357 with IP/UDP encap. This is the default protocol.
• tos : Type of Service
• dscp value : The default value is 48 and the range is from 0 to 63.
• traffic-class value : The default value is 6 and the range is from 0 to 7.
• advertisement threshold-check : minimum-delay/maximum-delay - The default value of periodic advertisement threshold-check is maximum-delay.
• periodic advertisement : Periodic advertisement is enabled by default.
• periodic-advertisement interval : The default value is 120 seconds and the interval range is from 30 to
3600 seconds.
• periodic-advertisement threshold : Checks the minimum-delay metric change for threshold crossing for periodic advertisement. The default value is 10 percent and the range is from 0 to 100 percent.
312
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Performance Measurement
SR Policy End-to-End Delay Measurement
• periodic-advertisement minimum-change : The default value is 500 microseconds (usec) and the range is from 0 to 100000 microseconds.
• accelerated advertisement : Accelerated advertisement is disabled by default.
• accelerated-advertisement threshold : Checks the minimum-delay metric change for threshold crossing for accelerated advertisement. The default value is 20 percent and the range is from 0 to 100 percent.
• accelerated-advertisement minimum : The default value is 500 microseconds and the range is from 1 to 100000 microseconds.
Router(config)# performance-measurement delay-profile sr-policy
Router(config-pm-dm-srpolicy)# probe
Router(config-pm-dm-srpolicy-probe)# burst-interval 60
Router(config-pm-dm-srpolicy-probe)# computation-interval 60
Router(config-pm-dm-srpolicy-probe)# protocol twamp-light
Router(config-pm-dm-srpolicy-probe)# tos dscp 63
Router(config-pm-dm-srpolicy-probe)# exit
Router(config-pm-dm-srpolicy)# advertisement
Router(config-pm-dm-srpolicy-adv)# periodic
Router(config-pm-dm-srpolicy-adv-per)# interval 60
Router(config-pm-dm-srpolicy-adv-per)# minimum-change 1000
Router(config-pm-dm-srpolicy-adv-per)# threshold 20
Router(config-pm-dm-srpolicy-adv-per)# exit
Router(config-pm-dm-srpolicy-adv)# accelerated
Router(config-pm-dm-srpolicy-adv-acc)# minimum-change 1000
Router(config-pm-dm-srpolicy-adv-acc)# threshold 10
Router(config-pm-dm-srpolicy-adv-acc)# exit
Router(config-pm-dm-srpolicy-adv)# threshold-check minimum-delay
Router(config-pm-dm-srpolicy-adv)# exit
Router(config-pm-dm-srpolicy)#
Configure the UDP Destination Port
Configuring the UDP port for TWAMP-Light protocol is optional. By default, PM uses port 862 as the
TWAMP-reserved UDP destination port for delay.
The UDP port is configured for each PM measurement probe type (delay, loss, protocol, authentication mode, etc.) on querier and responder nodes. If you configure a different UDP port, the UDP port for each PM measurement probe type must match on the querier and the responder nodes.
Note The same UDP destination port is used for delay measurement for links and SR Policy.
This example shows how to configure the UDP destination port for delay.
Router(config)# performance-measurement
Router(config-perf-meas)# protocol twamp-light
Router(config-pm-protocol)# measurement delay unauthenticated
Router(config-pm-proto-mode)# querier-dst-port 12000
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
313
Configure Performance Measurement
SR Policy End-to-End Delay Measurement
Enable Performance Measurement for SR Policy
This example shows how to enable PM for SR policy delay for a specific policy.
Router(config)# segment-routing traffic-eng
Router(config-sr-te)# policy foo
Router(config-sr-te-policy)# performance-measurement
Router(config-sr-te-policy-perf-meas)# delay-measurement
SR Policy Probe IP/UDP ECMP Hashing Configuration
This example shows how to configure SR Policy ECMP IP-hashing mode.
• The destination IPv4 address 127.x.x.x – 127.y.y.y is used in the Probe messages to take advantages of
3-tuple IP hashing (source-address, destination-address, and local router ID) for ECMP paths of SR-MPLS
Policy.
Note The destination IPv4 address must be 127/8 range (loopback), otherwise it will be rejected.
• One PM session is always created for the actual endpoint address of the SR Policy.
• You can specify the number of IP addresses to sweep. The range is from 0 (default, no sweeping) to 128.
• Platforms may have a limitation for large label stack size to not check IP address for hashing.
Router(config)# performance-measurement delay-profile sr-policy
Router(config-pm-dm-srpolicy)# probe
Router(config-pm-dm-srpolicy-probe)# sweep
Router(config-pm-dm-srpolicy-probe-sweep)# destination ipv4 127.0.0.1 range 28
Verification
Router# show performance-measurement sr-policy brief
Mon Jan 20 18:48:41.002 PST
-------------------------------------------------------------------------------
0/0/CPU0
-------------------------------------------------------------------------------
Policy Name LSP ID Tx/Rx Avg/Min/Max/Variance
----------------------------------------------------------------------------srte_c_10_ep_192.168.0.4
2 6/6 27012/26906/27203/106
Router# show performance-measurement sr-policy name srte_c_10_ep_192.168.0.4 detail verbose
Mon Jan 20 18:44:22.400 PST
-------------------------------------------------------------------------------
0/0/CPU0
-------------------------------------------------------------------------------
SR Policy name: srte_c_10_ep_192.168.0.4
Color : 10
Endpoint : 192.168.0.4
Number of candidate-paths : 1
Candidate-Path:
314
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Performance Measurement
SR Policy End-to-End Delay Measurement
Instance
Preference
Protocol-origin
Discriminator
: 2
: 100
: Configured
: 100
Source address
Reverse path label
: 192.168.0.2
: Not configured
Number of segment-lists : 1
Last advertisement:
No advertisements have occured
Next advertisement:
Check scheduled at the end of the current probe (roughly every 30 seconds)
Aggregated delays (uSec): avg: 45218, min: 26512, max: 82600, variance: 18706
Rolling average (uSec): 45218
Last probe:
Packets Sent: 9, received: 9
Measured delays (uSec): avg: 45218, min: 26512, max: 82600, variance: 18706
Current Probe:
Started at Jan 20 2020 18:44:19.170 (3.453 seconds ago)
Packets Sent: 3, received: 3
Measured delays (uSec): avg: 26588, min: 26558, max: 26630, variance: 30
Next probe scheduled at Jan 20 2020 18:44:34.166 (in 11.543 seconds)
Next burst packet will be sent in 1.543 seconds
Burst packet sent every 5.0 seconds
Liveness Detection: Disabled
Segment-List
16004
: R4
Number of atomic paths : 3
Last advertisement:
No advertisements have occured
Next advertisement:
Aggregated delays (uSec): avg: 45218, min: 26512, max: 82600, variance: 18706
Rolling average (uSec): 45218
Last probe:
Packets Sent: 9, received: 9
Measured delays (uSec): avg: 45218, min: 26512, max: 82600, variance: 18706
Current probe:
Packets Sent: 3, received: 3
Measured delays (uSec): avg: 26588, min: 26558, max: 26630, variance: 30
Liveness Detection: Disabled
Atomic path:
Hops
Session ID
: 127.0.0.0
: 33554434
Last advertisement:
No advertisements have occured
Next advertisement:
Aggregated delays (uSec): avg: 45407, min: 26629, max: 82600, variance: 18778
Rolling average (uSec): 45407
Last Probe:
Packets Sent: 3, received: 3
Measured delays (uSec): avg: 45407, min: 26629, max: 82600, variance: 18778
Current Probe:
Packets Sent: 1, received: 1
Measured delays (uSec): avg: 26630, min: 26630, max: 26630, variance: 0
Probe samples:
Packet Rx Timestamp Measured Delay (nsec)
Jan 20 2020 18:44:19.198
Liveness Detection: Disabled
26630730
Atomic path:
Hops
Session ID
Last advertisement:
: 127.0.0.1
: 33554435
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
315
Configure Performance Measurement
SR Policy End-to-End Delay Measurement
No advertisements have occured
Next advertisement:
Aggregated delays (uSec): avg: 45128, min: 26521, max: 81961, variance: 18607
Rolling average (uSec): 45128
Last Probe:
Packets Sent: 3, received: 3
Measured delays (uSec): avg: 45128, min: 26521, max: 81961, variance: 18607
Current Probe:
Packets Sent: 1, received: 1
Measured delays (uSec): avg: 26576, min: 26576, max: 26576, variance: 0
Probe samples:
Packet Rx Timestamp Measured Delay (nsec)
Jan 20 2020 18:44:19.198
Liveness Detection: Disabled
26576938
Atomic path:
Hops
Session ID
Last advertisement:
: 192.168.0.4
: 33554433
No advertisements have occured
Next advertisement:
Aggregated delays (uSec): avg: 45119, min: 26512, max: 81956, variance: 18607
Rolling average (uSec): 45119
Last Probe:
Packets Sent: 3, received: 3
Measured delays (uSec): avg: 45119, min: 26512, max: 81956, variance: 18607
Current Probe:
Packets Sent: 1, received: 1
Measured delays (uSec): avg: 26558, min: 26558, max: 26558, variance: 0
Probe samples:
Packet Rx Timestamp
Jan 20 2020 18:44:19.198
Liveness Detection: Disabled
Measured Delay (nsec)
26558375
Router# show performance-measurement history probe sr-policy
Mon Jan 20 18:46:55.445 PST
-------------------------------------------------------------------------------
0/0/CPU0
-------------------------------------------------------------------------------
SR Policy name: srte_c_10_ep_192.168.0.4
Color : 10
Endpoint : 192.168.0.4
Candidate-Path:
Preference
Protocol-origin
: 100
: Configured
Discriminator : 100
Delay-Measurement history (uSec):
Probe Start Timestamp Pkt(TX/RX) Average
Jan 20 2020 18:46:34.174
Jan 20 2020 18:46:19.174
9/9
9/9
26880
26899
Jan 20 2020 18:46:04.173
Jan 20 2020 18:45:49.172
Jan 20 2020 18:45:34.172
Jan 20 2020 18:45:19.171
Jan 20 2020 18:45:04.171
9/9
9/9
9/9
9/9
9/9
26813
26985
26744
26740
27115
Jan 20 2020 18:44:49.171
Jan 20 2020 18:44:34.171
Jan 20 2020 18:44:19.170
Jan 20 2020 18:44:06.543
9/9
9/9
9/9
9/9
26878
26824
26944
45218
Segment-List : R4
Min
26684
26822
26571
26713
26557
26435
26938
26539
26562
26558
26512
Max
27070
27004
27164
27293
27005
27093
27591
27143
27265
27422
82600
316
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Performance Measurement
SR Policy End-to-End Delay Measurement
16004
Delay-Measurement history (uSec):
Probe Start Timestamp
Jan 20 2020 18:46:34.174
Pkt(TX/RX)
9/9
Average
26880
Jan 20 2020 18:46:19.174
Jan 20 2020 18:46:04.173
Jan 20 2020 18:45:49.172
Jan 20 2020 18:45:34.172
Jan 20 2020 18:45:19.171
9/9
9/9
9/9
9/9
9/9
26899
26813
26985
26744
26740
Jan 20 2020 18:45:04.171
Jan 20 2020 18:44:49.171
Jan 20 2020 18:44:34.171
Jan 20 2020 18:44:19.170
Jan 20 2020 18:44:06.543
9/9
9/9
9/9
9/9
9/9
27115
26878
26824
26944
45218
Atomic path:
Hops : 127.0.0.0
Delay-Measurement history (uSec):
Probe Start Timestamp Pkt(TX/RX) Average
Jan 20 2020 18:46:34.174
Jan 20 2020 18:46:19.174
Jan 20 2020 18:46:04.173
Jan 20 2020 18:45:49.172
Jan 20 2020 18:45:34.172
3/3
3/3
3/3
3/3
3/3
26927
26982
26895
27054
26801
Jan 20 2020 18:45:19.171
Jan 20 2020 18:45:04.171
Jan 20 2020 18:44:49.171
Jan 20 2020 18:44:34.171
Jan 20 2020 18:44:19.170
Jan 20 2020 18:44:06.543
3/3
3/3
3/3
3/3
3/3
3/3
26807
27226
26976
26880
26994
45407
Atomic path:
Hops : 127.0.0.1
Delay-Measurement history (uSec):
Probe Start Timestamp
Jan 20 2020 18:46:34.174
Jan 20 2020 18:46:19.174
Jan 20 2020 18:46:04.173
Jan 20 2020 18:45:49.172
Pkt(TX/RX)
3/3
3/3
3/3
3/3
Average
26865
26846
26787
26954
Jan 20 2020 18:45:34.172
Jan 20 2020 18:45:19.171
Jan 20 2020 18:45:04.171
Jan 20 2020 18:44:49.171
Jan 20 2020 18:44:34.171
Jan 20 2020 18:44:19.170
Jan 20 2020 18:44:06.543
3/3
3/3
3/3
3/3
3/3
3/3
3/3
26724
26705
27043
26848
26800
26927
45128
Atomic path:
Hops : 192.168.0.4
Delay-Measurement history (uSec):
Probe Start Timestamp Pkt(TX/RX) Average
Jan 20 2020 18:46:34.174
3/3 26848
Jan 20 2020 18:46:19.174
Jan 20 2020 18:46:04.173
3/3
3/3
26871
26759
Jan 20 2020 18:45:49.172
Jan 20 2020 18:45:34.172
Jan 20 2020 18:45:19.171
Jan 20 2020 18:45:04.171
Jan 20 2020 18:44:49.171
Jan 20 2020 18:44:34.171
Jan 20 2020 18:44:19.170
Jan 20 2020 18:44:06.543
3/3
3/3
3/3
3/3
3/3
3/3
3/3
3/3
26947
26708
26708
27078
26812
26793
26911
45119
Min
26684
26822
26571
26713
26557
26435
26938
26539
26562
26558
26512
Min
26684
26833
26571
26713
26557
26435
27016
26539
26582
26558
26512
Min
26747
26970
26647
26764
26694
26524
26938
26644
26679
26630
26629
Min
26705
26822
26581
26728
26577
26452
26972
26550
26562
26576
26521
Max
27070
27004
27164
27293
27005
27093
27591
27143
27265
27422
82600
Max
26967
26913
26876
27163
26939
27075
27138
27043
27181
27308
81956
Max
27070
27004
27164
27293
27005
27093
27591
27143
27265
27422
82600
Max
26988
26881
26939
27180
26957
27032
27124
27062
27204
27327
81961
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
317
Configure Performance Measurement
SR Policy Liveness Monitoring
Router# show performance-measurement counters sr-policy name srte_c_10_ep_192.168.0.4
Mon Jan 20 18:47:55.499 PST
-------------------------------------------------------------------------------
0/0/CPU0
-------------------------------------------------------------------------------
SR Policy name: srte_c_10_ep_192.168.0.4
Candidate-Path:
Instance
Preference
Protocol-origin
Discriminator
Packets:
: 2
: 100
: Configured
: 100
: 141
: 141
Total sent
Total received
Errors:
Total sent errors
Total received errors
Probes:
Total started
Total completed
Total incomplete
Total advertisements
: 0
: 0
: 16
: 15
: 0
: 2
Segment-List
16004
Packets:
Total sent
Total received
Errors:
Total sent errors
Total received errors
Probes:
Total started
Total completed
Total incomplete
Total advertisements
: R4
: 141
: 141
: 0
: 0
: 16
: 15
: 0
: 2
SR Policy Liveness Monitoring
Table 32: Feature History Table
Feature Name
SR Policy Liveness Monitoring
Release Information
Release 7.3.1
Feature Description
This feature allows you to verify end-to-end traffic forwarding over an SR Policy candidate path by periodically sending performance monitoring packets.
SR Policy liveness monitoring allows you to verify end-to-end traffic forwarding over an SR Policy candidate path by periodically sending performance monitoring (PM) packets. The head-end router sends PM packets to the SR policy's endpoint router, which sends them back to the head-end without any control-plane dependency on the endpoint router.
The following are benefits to using SR-PM liveness monitoring:
318
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Performance Measurement
SR Policy Liveness Monitoring
• Allows both liveness monitoring and delay measurement using a single-set of PM packets as opposed to running separate monitoring sessions for each purpose. This improves the overall scale by reducing the number of PM sessions required.
• Eliminates network and device complexity by reducing the number of monitoring protocols on the network
(for example, no need for Bidirectional Failure Detection [BFD]). It also simplifies the network and device operations by not requiring any signaling to bootstrap the performance monitoring session.
• Improves interoperability with third-party nodes because signaling protocols aren't required. In addition, it leverages the commonly supported TWAMP protocol for packet encoding.
• Improves liveness detection time because PM packets aren't punted on remote nodes
• Provides a common solution that applies to data-planes besides MPLS, including IPv4, IPv6, and SRv6.
The workflow associated with liveness detection over SR policy is described in the following sequence.
Consider an SR policy programmed at head-end node router 1 towards end-point node router 5. This SR policy is enabled for liveness detection using the loopback measurement-mode.
• A : The head-end node creates and transmits the PM probe packets.
The IP destination address (DA) on the probe packets is set to the loopback value of the head-end node itself.
A transmit (Tx) timestamp is added to the payload.
Optionally, the head-end node may also insert extra encapsulation (labels) to enforce the reverse path at the endpoint node.
Finally, the packet is injected into the data-plane using the same encapsulation (label stack) of that of the SR policy being monitored.
• B : The network delivers the PM probe packets as it would user traffic over the SR policy.
• C : The end-point node receives the PM probe packets.
Packets are switched back based on the forwarding entry associated with the IP DA of the packet. This would typically translate to the end-point node pushing the prefix SID label associated with the head-end node.
If the head-end node inserted label(s) for the reverse path, then the packets are switched back at the end-point node based on the forwarding entry associated with the top-most reverse path label.
• D : Headend node receives the PM probe packets.
A received (Rx) timestamp stored.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
319
Configure Performance Measurement
SR Policy Liveness Monitoring
If the head-end node receives the PM probe packets, the head-end node assume that the SR policy active candidate path is up and working.
If the head-end node doesn't receive the specified number of probe packets (based on configured multiplier), the head-end node assumes the candidate path is down and a configured action is trigerred.
Usage Guidelines and Limitations
The following usage guidelines and limitations apply:
• Liveness-detection and delay-measurement aren't supported together
• When liveness-profile isn't configured, SR Policies use the default values for the liveness-detection profile parameters.
Configuring SR Policy Liveness Monitoring
Configuring SR Policy liveness monitoring involves the following steps:
• Configuring a performance measurement liveness profile to customize generic probe parameters
• Enabling liveness monitoring under SR Policy by associating a liveness profile, and customizing SR policy-specific probe parameters
Configuring Performance Measurement Liveness Profile
Liveness monitoring parameters are configured under performance-measurement liveness-profile sub-mode.
The following parameters are configurable:
• liveness-profile sr-policy {default | name name }
Parameters defined under the default liveneness-profile sr-policy apply to any SR policy with liveness monitoring enabled and that does not reference a non-default liveneness-profile sr-policy.
320
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Performance Measurement
SR Policy Liveness Monitoring
• probe : Configure the probe parameters.
• measurement-mode : Liveness detection must use loopback mode (see
).
• burst-interval : Interval for sending probe packet. The default value is 3000 milliseconds and the range is from 30 to 15000 milliseconds.
• tos dscp value : The default value is 48 and the range is from 0 to 63
• sweep : Configure SR Policy ECMP IP-hashing mode.
• destination ipv4 127.x.x.x range range : Specifies the number of IP addresses to sweep. The range is from 0 (default, no sweeping) to 128.
Note The destination IPv4 address 127.x.x.x – 127.y.y.y is used in the
Probe messages to take advantages of 3-tuple IP hashing
(source-address, destination-address, and local router ID) for ECMP paths of SR-MPLS Policy.
The destination IPv4 address must be 127/8 range (loopback), otherwise it will be rejected.
Note One PM session is always created for the actual endpoint address of the SR Policy.
• liveness-detection : Configure the liveness-detection parameters:
• multiplier : Number of consecutive missed probe packets before the PM session is declared as down.
The range is from 2 to 10, and the default is 3.
Note The detection-interval is equal to (burst-interval * multiplier).
Enabling Liveness Monitoring under SR Policy
Enable liveness monitoring under SR Policy, associate a liveness-profile, and configure SR Policy-specific probe parameters under the segment-routing traffic-eng policy performance-measurement sub-mode. The following parameters are configurable:
• liveness-detection : Enables end-to-end SR Policy Liveness Detection for all segment-lists of the active and standby candidate-path that are in the forwarding table.
• liveness-profile name name : Specifies the profile name for named profiles.
• invalidation-action {down | none} :
• Down (default) : When the PM liveness session goes down, the candidate path is immediately operationally brought down.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
321
Configure Performance Measurement
SR Policy Liveness Monitoring
• None : When the PM liveness session goes down, no action is taken. If logging is enabled, the failure is logged but the SR Policy operational state is not modified.
• logging session-state-change : Enables Syslog messages when the session state changes.
• reverse-path label { BSID-value | NODE-SID-value }: Specifies the MPLS label to be used for the reverse path for the reply. If you configured liveness detection with ECMP hashing, you must specify the reverse path. The default reverse path uses IP Reply.
• BSID-value : The Binding SID (BSID) label for the reverse SR Policy. (This is practical for manual
SR policies with a manual BSID.)
• NODE-SID-value : The absolute SID label of the (local) Sender Node to be used for the reverse path for the reply.
Configuration Examples
Configure a Default SR-Policy PM Liveness-Profile
The following example shows a default sr-policy liveness-profile:
RP/0/RSP0/CPU0:ios(config)# performance-measurement
RP/0/RSP0/CPU0:ios(config-perf-meas)# liveness-profile sr-policy default
RP/0/RSP0/CPU0:ios(config-pm-ld-srpolicy)# probe
RP/0/RSP0/CPU0:ios(config-pm-ld-srpolicy-probe)# measurement-mode loopback
RP/0/RSP0/CPU0:ios(config-pm-ld-srpolicy-probe)# burst-interval 1500
RP/0/RSP0/CPU0:ios(config-pm-ld-srpolicy-probe)# tos dscp 52
RP/0/RSP0/CPU0:ios(config-pm-ld-srpolicy-probe)# exit
RP/0/RSP0/CPU0:ios(config-pm-ld-srpolicy)# liveness-detection
RP/0/RSP0/CPU0:ios(config-pm-ld-srpolicy-ld)# multiplier 5
Running Configuration: performance-measurement liveness-profile sr-policy default liveness-detection multiplier 5
!
!
!
end
!
probe tos dscp 52 measurement-mode loopback burst-interval 1500
Configure a Named (Non-Default) SR-Policy PM Liveness-Profile
The following example shows a named sr-policy liveness-profile:
RP/0/RSP0/CPU0:ios(config)# performance-measurement
RP/0/RSP0/CPU0:ios(config-perf-meas)# liveness-profile sr-policy name sample-profile
RP/0/RSP0/CPU0:ios(config-pm-ld-srpolicy)# probe
RP/0/RSP0/CPU0:ios(config-pm-ld-srpolicy-probe)# measurement-mode loopback
RP/0/RSP0/CPU0:ios(config-pm-ld-srpolicy-probe)# burst-interval 1500
RP/0/RSP0/CPU0:ios(config-pm-ld-srpolicy-probe)# tos dscp 52
RP/0/RSP0/CPU0:ios(config-pm-ld-srpolicy-probe)# exit
RP/0/RSP0/CPU0:ios(config-pm-ld-srpolicy)# liveness-detection
322
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Performance Measurement
SR Policy Liveness Monitoring
RP/0/RSP0/CPU0:ios(config-pm-ld-srpolicy-ld)# multiplier 5
Running Configuration: performance-measurement liveness-profile sr-policy name sample-profile liveness-detection multiplier 5
!
probe
!
!
!
end tos dscp 52 measurement-mode loopback burst-interval 1500
Configure a SR-Policy PM Liveness-Profile with Sweep Parameters
The following example shows a named sr-policy liveness-profile with sweep parameters:
RP/0/RSP0/CPU0:ios(config)# performance-measurement
RP/0/RSP0/CPU0:ios(config-perf-meas)# liveness-profile sr-policy name sample-profile
RP/0/RSP0/CPU0:ios(config-pm-ld-srpolicy)# probe
RP/0/RSP0/CPU0:ios(config-pm-ld-srpolicy-probe)# measurement-mode loopback
RP/0/RSP0/CPU0:ios(config-pm-ld-srpolicy-probe)# burst-interval 1500
RP/0/RSP0/CPU0:ios(config-pm-ld-srpolicy-probe)# tos dscp 52
RP/0/RSP0/CPU0:ios(config-pm-ld-srpolicy-probe)# sweep
RP/0/RSP0/CPU0:ios(config-pm-ld-srpolicy-probe-sweep)# destination ipv4 127.0.0.1 range 25
RP/0/RSP0/CPU0:ios(config-pm-ld-srpolicy-probe-sweep)# exit
RP/0/RSP0/CPU0:ios(config-pm-ld-srpolicy-probe)# exit
RP/0/RSP0/CPU0:ios(config-pm-ld-srpolicy)# liveness-detection
RP/0/RSP0/CPU0:ios(config-pm-ld-srpolicy-ld)# multiplier 5
Running Configuration performance-measurement liveness-profile sr-policy name sample-profile liveness-detection multiplier 5
!
probe tos dscp 52 sweep destination ipv4 127.0.0.1 range 25
!
!
!
end
!
measurement-mode loopback burst-interval 1500
Enable Liveness Monitoring Under SR Policy
The following example shows how to enable liveness monitoring under SR Policy, associate a liveness-profile, and configure the invalidation action:
RP/0/RSP0/CPU0:ios(config)# segment-routing traffic-eng
RP/0/RSP0/CPU0:ios(config-sr-te)# policy FOO
RP/0/RSP0/CPU0:ios(config-sr-te-policy)# performance-measurement
RP/0/RSP0/CPU0:ios(config-sr-te-policy-perf-meas)# liveness-detection
RP/0/RSP0/CPU0:ios(config-sr-te-policy-live-detect)# liveness-profile name sample-profile
RP/0/RSP0/CPU0:ios(config-sr-te-policy-live-detect)# invalidation-action none
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
323
Configure Performance Measurement
SR Policy Liveness Monitoring
Running Config segment-routing traffic-eng policy FOO performance-measurement
!
!
!
end
!
!
liveness-detection liveness-profile name sample-profile invalidation-action none
Enable Liveness Monitoring under SR Policy with Optional Parameters
The following example shows how to enable liveness monitoring under SR Policy, associate a liveness-profile, and configure reverse path label and session logging:
RP/0/RSP0/CPU0:ios(config)# segment-routing traffic-eng
RP/0/RSP0/CPU0:ios(config-sr-te)# policy BAA
RP/0/RSP0/CPU0:ios(config-sr-te-policy)# performance-measurement
RP/0/RSP0/CPU0:ios(config-sr-te-policy-perf-meas)# liveness-detection
RP/0/RSP0/CPU0:ios(config-sr-te-policy-live-detect)# liveness-profile name sample-profile
RP/0/RSP0/CPU0:ios(config-sr-te-policy-live-detect)# invalidation-action down
RP/0/RSP0/CPU0:ios(config-sr-te-policy-live-detect)# logging session-state-change
RP/0/RSP0/CPU0:ios(config-sr-te-policy-live-detect)# exit
RP/0/RSP0/CPU0:ios(config-sr-te-policy-perf-meas)# reverse-path label 16001
Running Config segment-routing traffic-eng policy BAA performance-measurement liveness-detection logging session-state-change
!
liveness-profile name sample-profile
!
invalidation-action down
!
!
end
!
!
reverse-path label 16001
!
324
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
C H A P T E R
11
Configure Topology-Independent Loop-Free
Alternate (TI-LFA)
Topology-Independent Loop-Free Alternate (TI-LFA) uses segment routing to provide link, node, and Shared
Risk Link Groups (SRLG) protection in topologies where other fast reroute techniques cannot provide protection.
• Classic Loop-Free Alternate (LFA) is topology dependent, and therefore cannot protect all destinations in all networks. A limitation of LFA is that, even if one or more LFAs exist, the optimal LFA may not always be provided.
• Remote LFA (RLFA) extends the coverage to 90-95% of the destinations, but it also does not always provide the most desired repair path. RLFA also adds more operational complexity by requiring a targeted
LDP session to the RLFAs to protect LDP traffic.
TI-LFA provides a solution to these limitations while maintaining the simplicity of the IPFRR solution.
The goal of TI-LFA is to reduce the packet loss that results while routers converge after a topology change due to a link or node failure. Rapid failure repair (< 50 msec) is achieved through the use of pre-calculated backup paths that are loop-free and safe to use until the distributed network convergence process is completed.
The optimal repair path is the path that the traffic will eventually follow after the IGP has converged. This is called the post-convergence path. This path is preferred for the following reasons:
• Optimal for capacity planning — During the capacity-planning phase of the network, the capacity of a link is provisioned while taking into consideration that such link with be used when other links fail.
• Simple to operate — There is no need to perform a case-by-case adjustments to select the best LFA among multiple candidate LFAs.
• Fewer traffic transitions — Since the repair path is equal to the post-convergence path, the traffic switches paths only once.
The following topology illustrates the optimal and automatic selection of the TI-LFA repair path.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
325
Figure 27: TI-LFA Repair Path
Configure Topology-Independent Loop-Free Alternate (TI-LFA)
Node 2 protects traffic to destination Node 5.
With classic LFA, traffic would be steered to Node 4 after a failure of the protected link. This path is not optimal, since traffic is routed over edge node Node 4 that is connected to lower capacity links.
TI-LFA calculates a post-convergence path and derives the segment list required to steer packets along the post-convergence path without looping back.
In this example, if the protected link fails, the shortest path from Node2 to Node5 would be:
Node2
→
Node6
→
Node7
→
Node3
→
Node5
Node7 is the PQ-node for destination Node5. TI-LFA encodes a single segment (prefix SID of Node7) in the header of the packets on the repair path.
TI-LFA Protection Types
TI-LFA supports the following protection:
• Link protection — The link is excluded during the post-convergence backup path calculation.
• Node protection — The neighbor node is excluded during the post convergence backup path calculation.
• Shared Risk Link Groups (SRLG) protection — SRLG refer to situations in which links in a network share a common fiber (or a common physical attribute). These links have a shared risk: when one link fails, other links in the group might also fail. TI-LFA SRLG protection attempts to find the post-convergence backup path that excludes the SRLG of the protected link. All local links that share any SRLG with the protecting link are excluded.
326
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Topology-Independent Loop-Free Alternate (TI-LFA)
Limitations
When you enable link protection, you can also enable node protection, SRLG protection, or both, and specify a tiebreaker priority in case there are multiple LFAs.
The following example illustrates the link, node, and SRLG protection types. In this topology, Node2 applies different protection models to protect traffic to Node7.
Figure 28: TI-LFA Protection Types
•
•
Usage Guidelines and Limitations, on page 327
•
Configuring TI-LFA for IS-IS, on page 328
•
Configuring TI-LFA for OSPF, on page 330
•
TI-LFA Node and SRLG Protection: Examples, on page 331
•
Configuring Global Weighted SRLG Protection, on page 332
•
SR-MPLS over GRE as TI-LFA Backup Path, on page 336
•
Unlabeled IPv6 Traffic Protection, on page 347
Limitations
Only two backup labels are supported.
Usage Guidelines and Limitations
The TI-LFA guidelines and limitations are listed below:
TI-LFA Functionality IS-IS
Protected Traffic Types
OSPFv2
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
327
Configure Topology-Independent Loop-Free Alternate (TI-LFA)
Configuring TI-LFA for IS-IS
TI-LFA Functionality
Protection for SR labeled traffic
Protection of IPv4 unlabeled traffic
Protection of IPv6 unlabeled traffic
IS-IS
Supported
Supported
(IS-ISv4)
Supported
(IS-ISv6)
Protection Types
Link Protection
Node Protection
Local SRLG Protection
Weighted Remote SRLG Protection
Line Card Disjoint Protection
Supported
Supported
Supported
Supported
Supported
Interface Types
Ethernet Interfaces
Ethernet Bundle Interfaces
Supported
Supported
TI-LFA over GRE Tunnel as Protecting Interface Supported
Additional Functionality
BFD-triggered
BFDv6-triggered
Prefer backup path with lowest total metric
Supported
Supported
Supported
Prefer backup path from ECMP set
Prefer backup path from non-ECMP set
Supported
Supported
Load share prefixes across multiple backups paths Supported
Limit backup computation up to the prefix priority Supported
1
Unless specified, IS-IS support is IS-ISv4 and IS-ISv6
OSPFv2
Supported
Supported
N/A
Supported
Supported
Supported
Supported
Unsupported
Supported
Supported
Supported
Supported
N/A
Supported
Supported
Supported
Supported
Supported
Configuring TI-LFA for IS-IS
This task describes how to enable per-prefix Topology Independent Loop-Free Alternate (TI-LFA) computation to converge traffic flows around link, node, and SRLG failures.
Before you begin
Ensure that the following topology requirements are met:
• Router interfaces are configured as per the topology.
328
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Topology-Independent Loop-Free Alternate (TI-LFA)
Configuring TI-LFA for IS-IS
• Routers are configured with IS-IS.
• Segment routing for IS-IS is configured. See
Enabling Segment Routing for IS-IS Protocol, on page 95
.
Procedure
Step 1
Step 2
Step 3
Command or Action configure
Example:
Purpose
Enters mode.
RP/0/RP0/CPU0:router# configure
router isis instance-id
Example:
Enables IS-IS routing for the specified routing instance, and places the router in router configuration mode.
RP/0/RP0/CPU0:router(config)# router isis
1
Note You can change the level of routing to be performed by a particular routing instance by using the is-type router configuration command.
interface type interface-path-id
Example:
Enters interface configuration mode.
RP/0/RP0/CPU0:router(config-isis)# interface GigabitEthernet0/0/0/1
Step 4
Step 5 address-family ipv4 [ unicast ]
Example:
RP/0/RP0/CPU0:router(config-isis-if)# address-family ipv4 unicast
Specifies the IPv4 address family, and enters router address family configuration mode.
fast-reroute per-prefix
Example:
RP/0/RP0/CPU0:router(config-isis-if-af)# fast-reroute per-prefix
Enables per-prefix fast reroute.
Step 6
Step 7 fast-reroute per-prefix ti-lfa
Example:
RP/0/RP0/CPU0:router(config-isis-if-af)# fast-reroute per-prefix ti-lfa
Enables per-prefix TI-LFA fast reroute link protection.
fast-reroute per-prefix tiebreaker
{ node-protecting | srlg-disjoint } index priority
Enables TI-LFA node or SRLG protection and specifies the tiebreaker priority. Valid priority values are from 1 to 255. The lower the priority
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
329
Configure Topology-Independent Loop-Free Alternate (TI-LFA)
Configuring TI-LFA for OSPF
Command or Action Purpose
Example: value, the higher the priority of the rule. Link protection always has a lower priority than node or SRLG protection.
RP/0/RP0/CPU0:router(config-isis-if-af)# fast-reroute per-prefix tie-breaker srlg-disjoint index 100
Note The same attribute cannot be configured more than once on an interface.
Note For IS-IS, TI-LFA node protection and SRLG protection can be configured on the interface or the instance.
TI-LFA has been successfully configured for segment routing.
Configuring TI-LFA for OSPF
This task describes how to enable per-prefix Topology Independent Loop-Free Alternate (TI-LFA) computation to converge traffic flows around link, node, and SRLG failures.
Note TI-LFA can be configured on the instance, area, or interface. When configured on the instance or area, all interfaces in the instance or area inherit the configuration.
Before you begin
Ensure that the following topology requirements are met:
• Router interfaces are configured as per the topology.
• Routers are configured with OSPF.
• Segment routing for OSPF is configured. See
Enabling Segment Routing for OSPF Protocol, on page
Procedure
Step 1
Command or Action configure
Example:
RP/0/RP0/CPU0:router# configure
Purpose
Enters mode.
330
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Topology-Independent Loop-Free Alternate (TI-LFA)
TI-LFA Node and SRLG Protection: Examples
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Command or Action
router ospf process-name
Example:
Purpose
Enables OSPF routing for the specified routing process, and places the router in router configuration mode.
RP/0/RP0/CPU0:router(config)# router ospf
1
area area-id
Example:
Enters area configuration mode.
RP/0/RP0/CPU0:router(config-ospf)# area
1
interface type interface-path-id
Example:
Enters interface configuration mode.
RP/0/RP0/CPU0:router(config-ospf-ar)# interface GigabitEthernet0/0/0/1 fast-reroute per-prefix
Example:
Enables per-prefix fast reroute.
RP/0/RP0/CPU0:router(config-ospf-ar-if)# fast-reroute per-prefix fast-reroute per-prefix ti-lfa
Example:
Enables per-prefix TI-LFA fast reroute link protection.
RP/0/RP0/CPU0:router(config-ospf-ar-if)# fast-reroute per-prefix ti-lfa fast-reroute per-prefix tiebreaker
{ node-protecting priority
Example:
| srlg-disjoint } index
Enables TI-LFA node or SRLG protection and specifies the tiebreaker priority. Valid priority values are from 1 to 255. The lower the priority value, the higher the priority of the rule. Link protection always has a lower priority than node or SRLG protection.
RP/0/RP0/CPU0:router(config-ospf-ar-if)# fast-reroute per-prefix tie-breaker srlg-disjoint index 100
Note The same attribute cannot be configured more than once on an interface.
TI-LFA has been successfully configured for segment routing.
TI-LFA Node and SRLG Protection: Examples
The following examples show the configuration of the tiebreaker priority for TI-LFA node and SRLG protection, and the behavior of post-convergence backup-path. These examples use OSPF, but the same configuration and behavior applies to IS-IS.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
331
Configure Topology-Independent Loop-Free Alternate (TI-LFA)
Configuring Global Weighted SRLG Protection
Example: Enable link-protecting and node-protecting TI-LFA router ospf 1 area 1 interface GigabitEthernet0/0/2/1 fast-reroute per-prefix fast-reroute per-prefix ti-lfa fast-reroute per-prefix tiebreaker node-protecting index 100
Both link-protecting and node-protecting TI-LFA backup paths will be computed. If the priority associated with the node-protecting tiebreaker is higher than any other tiebreakers, then node-protecting post-convergence backup paths will be selected, if it is available.
Example: Enable link-protecting and SRLG-protecting TI-LFA router ospf 1 area 1 interface GigabitEthernet0/0/2/1 fast-reroute per-prefix fast-reroute per-prefix ti-lfa fast-reroute per-prefix tiebreaker srlg-disjoint index 100
Both link-protecting and SRLG-protecting TI-LFA backup paths will be computed. If the priority associated with the SRLG-protecting tiebreaker is higher than any other tiebreakers, then SRLG-protecting post-convergence backup paths will be selected, if it is available.
Example: Enable link-protecting, node-protecting and SRLG-protecting TI-LFA router ospf 1 area 1 interface GigabitEthernet0/0/2/1 fast-reroute per-prefix fast-reroute per-prefix ti-lfa fast-reroute per-prefix tiebreaker node-protecting index 100 fast-reroute per-prefix tiebreaker srlg-disjoint index 200
Link-protecting, node-protecting, and SRLG-protecting TI-LFA backup paths will be computed. If the priority associated with the node-protecting tiebreaker is highest from all tiebreakers, then node-protecting post-convergence backup paths will be selected, if it is available. If the node-protecting backup path is not available, SRLG-protecting post-convergence backup path will be used, if it is available.
Configuring Global Weighted SRLG Protection
A shared risk link group (SRLG) is a set of links sharing a common resource and thus shares the same risk of failure. The existing loop-free alternate (LFA) implementations in interior gateway protocols (IGPs) support
SRLG protection. However, the existing implementation considers only the directly connected links while computing the backup path. Hence, SRLG protection may fail if a link that is not directly connected but shares the same SRLG is included while computing the backup path. Global weighted SRLG protection feature provides better path selection for the SRLG by associating a weight with the SRLG value and using the weights of the SRLG values while computing the backup path.
332
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Topology-Independent Loop-Free Alternate (TI-LFA)
Configuring Global Weighted SRLG Protection
To support global weighted SRLG protection, you need information about SRLGs on all links in the area topology. For IS-IS, you can flood SRLGs for remote links or manually configuring SRLGs on remote links.
For OSPF, the SRLG values are advertised in the Extended Link LSA when SRLG is configured for that interface and Segment Routing is enabled.
The administrative weight (cost) of the SRLG can be configured using the admin-weight command. This command can be applied for all SRLG (global), or for a specific (named) SRLG. The default (global) admin-weight value is 1 for IS-IS, and 1000 for OSPF.
Configuration Examples: Global Weighted SRLG Protection for IS-IS
There are three types of configurations that are supported for the global weighted SRLG protection feature for IS-IS:
• Local SRLG with global weighted SRLG protection
• Remote SRLG flooding
• Remote SRLG static provisioning
This example shows how to configure the local SRLG with global weighted SRLG protection feature.
RP/0/RP0/CPU0:router(config)# srlg
RP/0/RP0/CPU0:router(config-srlg)# interface TenGigE0/0/0/0
RP/0/RP0/CPU0:router(config-srlg-if)# name group1
RP/0/RP0/CPU0:router(config-srlg-if)# exit
RP/0/RP0/CPU0:router(config-srlg)# interface TenGigE0/0/0/1
RP/0/RP0/CPU0:router(config-srlg-if)# name group1
RP/0/RP0/CPU0:router(config-srlg)# exit
RP/0/RP0/CPU0:router(config-srlg)# name group1 value 100
RP/0/RP0/CPU0:router(config-srlg)# exit
RP/0/RP0/CPU0:router(config)# router isis 1
RP/0/RP0/CPU0:router(config-isis)# address-family ipv4 unicast
RP/0/RP0/CPU0:router(config-isis-af)# fast-reroute per-prefix srlg-protection weighted-global
RP/0/RP0/CPU0:router(config-isis-af)# fast-reroute per-prefix tiebreaker srlg-disjoint index
1
RP/0/RP0/CPU0:router(config-isis-af)# exit
RP/0/RP0/CPU0:router(config-isis)# interface TenGigE0/0/0/0
RP/0/RP0/CPU0:router(config-isis-if)# point-to-point
RP/0/RP0/CPU0:router(config-isis-if)# address-family ipv4 unicast
RP/0/RP0/CPU0:router(config-isis-if-af)# fast-reroute per-prefix
RP/0/RP0/CPU0:router(config-isis-if-af)# fast-reroute per-prefix ti-lfa
RP/0/RP0/CPU0:router(config-isis-if-af)# exit
RP/0/RP0/CPU0:router(config-isis-if)# exit
RP/0/RP0/CPU0:router(config-isis)# srlg
RP/0/RP0/CPU0:router(config-isis-srlg)# name group1
RP/0/RP0/CPU0:router(config-isis-srlg-name)# admin-weight 5000
This example shows how to configure the global weighted SRLG protection feature with remote SRLG flooding. The configuration includes local and remote router configuration. On the local router, the global weighted SRLG protection is enabled by using the fast-reroute per-prefix srlg-protection weighted-global command. In the remote router configuration, you can control the SRLG value flooding by using the advertise application lfa link-attributes srlg command. You should also globally configure SRLG on the remote router.
The local router configuration for global weighted SRLG protection with remote SRLG flooding is as follows:
RP/0/RP0/CPU0:router(config)# router isis 1
RP/0/RP0/CPU0:router(config-isis)# address-family ipv4 unicast
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
333
Configure Topology-Independent Loop-Free Alternate (TI-LFA)
Configuring Global Weighted SRLG Protection
RP/0/RP0/CPU0:router(config-isis-af)# fast-reroute per-prefix srlg-protection weighted-global
RP/0/RP0/CPU0:router(config-isis-af)# fast-reroute per-prefix tiebreaker srlg-disjoint index
1
RP/0/RP0/CPU0:router(config-isis-af)# exit
RP/0/RP0/CPU0:router(config-isis)# interface TenGigE0/0/0/0
RP/0/RP0/CPU0:router(config-isis-if)# point-to-point
RP/0/RP0/CPU0:router(config-isis-if)# address-family ipv4 unicast
RP/0/RP0/CPU0:router(config-isis-if-af)# fast-reroute per-prefix
RP/0/RP0/CPU0:router(config-isis-if-af)# fast-reroute per-prefix ti-lfa
RP/0/RP0/CPU0:router(config-isis-if-af)# exit
RP/0/RP0/CPU0:router(config-isis-if)# exit
RP/0/RP0/CPU0:router(config-isis)# srlg
RP/0/RP0/CPU0:router(config-isis-srlg)# name group1
RP/0/RP0/CPU0:router(config-isis-srlg-name)# admin-weight 5000
The remote router configuration for global weighted SRLG protection with remote SRLG flooding is as follows:
RP/0/RP0/CPU0:router(config)# srlg
RP/0/RP0/CPU0:router(config-srlg)# interface TenGigE0/0/0/0
RP/0/RP0/CPU0:router(config-srlg-if)# name group1
RP/0/RP0/CPU0:router(config-srlg-if)# exit
RP/0/RP0/CPU0:router(config-srlg)# interface TenGigE0/0/0/1
RP/0/RP0/CPU0:router(config-srlg-if)# name group1
RP/0/RP0/CPU0:router(config-srlg-if)# exit
RP/0/RP0/CPU0:router(config-srlg)# name group1 value 100
RP/0/RP0/CPU0:router(config-srlg)# exit
RP/0/RP0/CPU0:router(config)# router isis 1
RP/0/RP0/CPU0:router(config-isis)# address-family ipv4 unicast
RP/0/RP0/CPU0:router(config-isis-af)# advertise application lfa link-attributes srlg
This example shows configuring the global weighted SRLG protection feature with static provisioning of
SRLG values for remote links. You should perform these configurations on the local router.
RP/0/RP0/CPU0:router(config)# srlg
RP/0/RP0/CPU0:router(config-srlg)# interface TenGigE0/0/0/0
RP/0/RP0/CPU0:router(config-srlg-if)# name group1
RP/0/RP0/CPU0:router(config-srlg-if)# exit
RP/0/RP0/CPU0:router(config-srlg)# interface TenGigE0/0/0/1
RP/0/RP0/CPU0:router(config-srlg-if)# name group1
RP/0/RP0/CPU0:router(config-srlg-if)# exit
RP/0/RP0/CPU0:router(config-srlg)# name group1 value 100
RP/0/RP0/CPU0:router(config-srlg)# exit
RP/0/RP0/CPU0:router(config)# router isis 1
RP/0/RP0/CPU0:router(config-isis)# address-family ipv4 unicast
RP/0/RP0/CPU0:router(config-isis-af)# fast-reroute per-prefix srlg-protection weighted-global
RP/0/RP0/CPU0:router(config-isis-af)# fast-reroute per-prefix tiebreaker srlg-disjoint index
1
RP/0/RP0/CPU0:router(config-isis-af)# exit
RP/0/RP0/CPU0:router(config-isis)# interface TenGigE0/0/0/0
RP/0/RP0/CPU0:router(config-isis-if)# point-to-point
RP/0/RP0/CPU0:router(config-isis-if)# address-family ipv4 unicast
RP/0/RP0/CPU0:router(config-isis-if-af)# fast-reroute per-prefix
RP/0/RP0/CPU0:router(config-isis-if-af)# fast-reroute per-prefix ti-lfa
RP/0/RP0/CPU0:router(config-isis-if-af)# exit
RP/0/RP0/CPU0:router(config-isis-if)# exit
RP/0/RP0/CPU0:router(config-isis)# srlg
RP/0/RP0/CPU0:router(config-isis-srlg)# name group1
RP/0/RP0/CPU0:router(config-isis-srlg-name)# admin-weight 5000
RP/0/RP0/CPU0:router(config-isis-srlg-name)# static ipv4 address 10.0.4.1 next-hop ipv4
334
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Topology-Independent Loop-Free Alternate (TI-LFA)
Configuring Global Weighted SRLG Protection address 10.0.4.2
RP/0/RP0/CPU0:router(config-isis-srlg-name)# static ipv4 address 10.0.4.2 next-hop ipv4 address 10.0.4.1
Configuration Examples: Global Weighted SRLG Protection for OSPF
There are two types of configurations that are supported for the global weighted SRLG protection feature for
OSPF:
• Local SRLG with global weighted SRLG protection
• Remote SRLG static provisioning
Note There is no specific configuration to enable SRLG flooding in OSPF. The SRLG values are advertised in the
Extended Link LSA if SRLG is configured for that interface and Segment Routing is enabled.
This example shows how to configure the local SRLG with global weighted SRLG protection feature.
Router(config)# srlg
Router(config-srlg)# interface hundredGigE 0/0/0/0
Router(config-srlg-if)# name group1
Router(config-srlg-if)# exit
Router(config-srlg)# interface hundredGigE 0/0/0/1
Router(config-srlg-if)# name group1
Router(config-srlg-if)# exit
Router(config-srlg)# name group1 value 100
Router(config-srlg)# exit
Router(config)# router ospf 1
Router(config-ospf)# fast-reroute per-prefix srlg-protection weighted-global
Router(config-ospf)# fast-reroute per-prefix tiebreaker srlg-disjoint index 1
Router(config-ospf-ar)# interface hundredGigE 0/0/0/0
Router(config-ospf-ar-if)# fast-reroute per-prefix
Router(config-ospf-ar-if)# fast-reroute per-prefix ti-lfa
Router(config-ospf-ar-if)# exit
Router(config-ospf-ar)# exit
Router(config-ospf)# srlg
Router(config-ospf-srlg)# admin-weight 3000
Router(config-ospf-srlg)# name group1
Router(config-ospf-srlg-name)# admin-weight 5000
This example shows configuring the global weighted SRLG protection feature with static provisioning of
SRLG values for remote links. You should perform these configurations on the remote router.
Router(config)# srlg
Router(config-srlg)# interface hundredGigE 0/0/0/0
Router(config-srlg-if)# name group1
Router(config-srlg-if)# exit
Router(config-srlg)# interface hundredGigE 0/0/0/1
Router(config-srlg-if)# name group1
Router(config-srlg-if)# exit
Router(config-srlg)# name group1 value 100
Router(config-srlg)# exit
Router(config)# router ospf 1
Router(config-ospf)# area 1
Router(config-ospf-ar)# interface hundredGigE 0/0/0/0
Router(config-ospf-ar-if)# exit
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
335
Configure Topology-Independent Loop-Free Alternate (TI-LFA)
SR-MPLS over GRE as TI-LFA Backup Path
Router(config-ospf-ar)# exit
SR-MPLS over GRE as TI-LFA Backup Path
This feature allows the router (as ABR) to program a Generic Routing Encapsulation (GRE) tunnel as an outgoing interface for TI-LFA backup paths computed by the IGP in a Segment Routing network.
Single-segment TI-LFA scenario is supported. In this scenario, the router pushes one extra label when programming the backup path.
Note GRE is a tunneling protocol that provides a simple generic approach to transport packets of one protocol over another protocol by means of encapsulation. See the Configuring GRE Tunnels chapter in the Interface and
Hardware Component Configuration Guide for Cisco NCS 560 Series Routers .
Multi-Level Network Topology
The following example shows a multi-level network topology with interconnecting links between ABRs.
Note This could also be a multi-instance network topology.
Two links between ABR 2 and ABR 3 are required, one in each IS-IS level. These links provide protection in each direction and ensure that there is always an alternate path inside the IGP domain.
Note Alternatively, a single link with two logical sub-interfaces could be used between the ABRs.
336
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Topology-Independent Loop-Free Alternate (TI-LFA)
SR-MPLS over GRE as TI-LFA Backup Path
TI-LFA performs the backup path calculation inside the domain (process, level, or area) of the failed link.
For example, if the link between nodes 2 and 5 failed, the link between ABR 2 and 3 would create a TI-LFA path in L1 IS-IS level. If the link between nodes 1 and 2 failed, the link between ABR 2 and 3 would create a TI-LFA path in L2 IS-IS level.
However, if the interconnecting link between ABRs are in the same Shared Risk Link Groups (SRLG) as other links inside the domain (for example, the link between Nodes 2 and 3 are in the same SRLG as link between Nodes 2 and 5), TI-LFA with local SRLG protection would not find an alternate path.
In cases where it is not feasible to provide interconnecting links between ABRs (for example, the ABR nodes might be in different locations with no connectivity options), TI-LFA will not be able to compute backup paths for all of the prefixes.
To address these issues, you can create a GRE tunnel in each domain, between the ABRs, which can be used as TI-LFA backup paths.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
337
SR-MPLS over GRE as TI-LFA Backup Path
Configure Topology-Independent Loop-Free Alternate (TI-LFA)
Now, if a link failure occurs in either IS-IS level (for example, between nodes 1 and 2 or between nodes 2 and 5), the path is protected by the GRE tunnel.
Backup Path for Link Failure Between Nodes 2 and 5
Traffic from node 1 is rerouted over the GRE tunnel TI-LFA backup path between ABR nodes 2 and 3.
Traffic flowing in the opposite direction, from node 5 to node 1, is simply routed over nodes 6-3-4 to node
1.
338
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Topology-Independent Loop-Free Alternate (TI-LFA)
Limitations
Limitations
The following behaviors and limitations apply to the router when a GRE tunnel is programmed as backup interface for TI-LFA:
• The MPLS label of a protected prefix must be the same in the primary and backup paths (SWAP scenario)
• Single-segment TI-LFA is supported. In this scenario, the router pushes one extra label when programming the backup path. The total label stack is 2, including the primary label and backup label.
• Double-segment (or more) TI-LFA is not supported. In this scenario, the router pushes two or more extra labels when programming the backup path.
• GRE tunnel as a primary or backup path for an SR policy with TI-LFA protection is not supported.
Example: SR-MPLS over GRE as TI-LFA Backup Path
The examples in this section use the following network topology:
Configurations Without Interconnecting ABR Links
The following sample configurations show OSPF configurations for nodes 2, 3 and 5. Nodes 2 and 3 are ABRs between Area 0 and Area 100. There is no connection between the ABRs.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
339
Configure Topology-Independent Loop-Free Alternate (TI-LFA)
Example: SR-MPLS over GRE as TI-LFA Backup Path
Configuration on ABR 2 for Area 0 and Area 100 router ospf 100 router-id 2.2.2.2
segment-routing mpls segment-routing forwarding mpls fast-reroute per-prefix fast-reroute per-prefix ti-lfa enable segment-routing sr-prefer area 0 interface Loopback0
!
prefix-sid index 2
!
interface TenGigE0/0/1/10 network point-to-point
!
!
area 100 interface TenGigE0/0/1/11 network point-to-point
RP/0/RSP0/CPU0:ABR2# show ospf neighbor area-sorted
Fri Jul 19 09:43:59.328 UTC
Neighbors for OSPF 100
Area 0
Neighbor ID
1.1.1.1
Pri State Dead Time Address
1 FULL/ - 00:00:35 10.1.2.1
Total neighbor count: 1
Area 100
Neighbor ID
5.5.5.5
Pri State Dead Time Address
1 FULL/ - 00:00:33 10.2.5.5
Total neighbor count: 1
Configuration on ABR 3 for Area 0 and Area 100 router ospf 100 router-id 3.3.3.3
segment-routing mpls segment-routing forwarding mpls fast-reroute per-prefix fast-reroute per-prefix ti-lfa enable segment-routing sr-prefer area 0 interface Loopback0 prefix-sid index 3
!
interface TenGigE0/0/0/9 network point-to-point
!
!
area 100 interface TenGigE0/0/0/3
!
network point-to-point
RP/0/RSP0/CPU0:ABR3# show ospf neighbor area-sorted
Fri Jul 19 09:33:35.816 UTC
Up Time Interface
1d20h Te0/0/1/10
Up Time Interface
1d20h Te0/0/1/11
340
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Topology-Independent Loop-Free Alternate (TI-LFA)
Example: SR-MPLS over GRE as TI-LFA Backup Path
Neighbors for OSPF 100
Area 0
Neighbor ID
4.4.4.4
Pri State Dead Time Address
1 FULL/ - 00:00:36 10.3.4.4
Total neighbor count: 1
Area 100
Neighbor ID
6.6.6.6
Pri State Dead Time Address
1 FULL/ - 00:00:36 10.3.6.6
Total neighbor count: 1
Configuration on Node 5 segment-routing mpls
!
set-attributes address-family ipv4 sr-label-preferred
!
connected-prefix-sid-map address-family ipv4
5.5.5.5/32 index 5 range 1
!
interface TenGigabitEthernet0/0/26 description *** Connected to ABR 2 ip address 10.2.5.5 255.255.255.0
ip ospf network point-to-point cdp enable
!
interface TenGigabitEthernet0/0/27 description *** Connected to Node 6 ip address 10.5.6.5 255.255.255.0
ip ospf network point-to-point cdp enable router ospf 100 router-id 5.5.5.5
segment-routing area 100 mpls segment-routing mpls fast-reroute per-prefix enable prefix-priority low fast-reroute per-prefix ti-lfa fast-reroute per-prefix ti-lfa area 100 passive-interface default no passive-interface TenGigabitEthernet0/0/26 no passive-interface TenGigabitEthernet0/0/27 network 10.2.5.0 0.0.0.255 area 100 network 10.5.5.0 0.0.0.255 area 100 network 10.5.6.0 0.0.0.255 area 100 network 5.5.5.5 0.0.0.0 area 100
Up Time Interface
2d17h Te0/0/0/9
Up Time Interface
2d19h Te0/0/0/3
RP/0/RSP0/CPU0:Node5# show ip ospf neighbor
Load for five secs: 4%/1%; one minute: 4%; five minutes: 4%
Time source is NTP, 09:50:51.417 UTC Fri Jul 19 2019
Neighbor ID Pri State
6.6.6.6
2.2.2.2
0
0
FULL/
FULL/
-
-
Dead Time
00:00:32
00:00:36
Address
10.5.6.6
10.5.2.5
Interface
TenGigabitEthernet0/0/27
TenGigabitEthernet0/0/26
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
341
Configure Topology-Independent Loop-Free Alternate (TI-LFA)
Example: SR-MPLS over GRE as TI-LFA Backup Path
TI-LFA Fast Reroute Coverage on Node 5
The following output shows that this configuration provides only 52% TI-LFA fast reroute coverage on Node
5:
RP/0/RSP0/CPU0:Node5# show ip ospf fast-reroute prefix-summary
Load for five secs: 4%/1%; one minute: 4%; five minutes: 4%
Time source is NTP, 10:32:20.236 UTC Fri Jul 19 2019
OSPF Router with ID (5.5.5.5) (Process ID 100)
Base Topology (MTID 0)
Area 100:
Interface Protected
Lo0
Te0/0/27
Te0/0/26
Yes
Yes
Yes
Primary paths Protected paths Percent protected
All High Low All High Low All High Low
0
7
10
0
4
5
0
3
5
0
1
8
0
1
4
0
0
4
0%
14%
80%
0%
25%
80%
0%
0%
80%
Area total: 17 9 8 9 5 4 52% 55% 50%
Process total: 17 9 8 9 5 4 52% 55% 50%
GRE Tunnel Configuration
The following examples show how to configure GRE tunnels between the ABRs in each area to provide
TI-LFA backup paths for the Segment Routing network.
GRE BLU is configured in Area 0 using Loopback50 (on ABR2) and Loopback 60 (on ABR 3). These loopbacks are advertised in Area 100:
Figure 29: GRE BLU
GRE RED is configured in Area 100 using Loopback55 (on ABR2) and Loopback 66 (on ABR3). These loopbacks are advertised in Area 0:
342
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Topology-Independent Loop-Free Alternate (TI-LFA)
Figure 30: GRE RED
Example: SR-MPLS over GRE as TI-LFA Backup Path
Configuration on ABR 2 interface Loopback0 ipv4 address 2.2.2.2 255.255.255.255
!
interface Loopback50 description Lo for GRE BLU ipv4 address 50.0.0.50
255.255.255.0
!
interface Loopback55 description Lo for GRE RED ipv4 address 55.55.55.55
255.255.255.255
!
interface tunnel-ip5060 description GRE virtual link for Area 0 BLU ipv4 address 66.3.2.2 255.255.255.0
tunnel source Loopback50 tunnel destination 60.0.0.60
!
interface tunnel-ip5566 description GRE virtual link for Area 100 RED ipv4 address 100.3.2.2 255.255.255.0
tunnel source Loopback55 tunnel destination 66.66.66.66
router ospf 100 router-id 2.2.2.2
segment-routing mpls segment-routing forwarding mpls fast-reroute per-prefix fast-reroute per-prefix ti-lfa enable segment-routing sr-prefer area 0 interface Loopback0
!
prefix-sid index 2 interface Loopback55 passive enable
!
interface tunnel-ip5060 cost 1000
!
interface TenGigE0/0/1/10
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
343
Configure Topology-Independent Loop-Free Alternate (TI-LFA)
Example: SR-MPLS over GRE as TI-LFA Backup Path
!
network point-to-point
!
area 100 interface Loopback50
!
passive enable interface tunnel-ip5566 cost 1000
!
interface TenGigE0/0/1/11 network point-to-point
Note In the above configuration, GRE tunnel-ip5060 belongs to area 0, but its source and destination addresses are advertised in area 100. This ensures disjointness between the GRE tunnel and the links in area 0 that it protects.
The same applies to GRE tunnel-ip5566 which belongs to area 100 and its source and destination addresses are advertised in area 0.
A high cost is applied to the GRE tunnel interfaces so that they are used only as a backup path.
Configuration on ABR 3 interface Loopback0 ipv4 address 3.3.3.3 255.255.255.255
!
interface Loopback60 description Lo for GRE BLU ipv4 address 60.0.0.60
255.255.255.0
!
interface Loopback66 description Lo for GRE RED ipv4 address 66.66.66.66
255.255.255.255
!
interface tunnel-ip5060 description GRE virtual link for Area 0 BLU ipv4 address 66.3.2.3 255.255.255.0
tunnel source Loopback60
!
tunnel destination 50.0.0.50
interface tunnel-ip5566 description GRE virtual link for Area 100 RED ipv4 address 100.3.2.3 255.255.255.0
tunnel source Loopback66 tunnel destination 55.55.55.55
router ospf 100 router-id 3.3.3.3
segment-routing mpls segment-routing forwarding mpls fast-reroute per-prefix fast-reroute per-prefix ti-lfa enable segment-routing sr-prefer area 0 interface Loopback0
!
prefix-sid index 3 interface TenGigE0/0/0/9 network point-to-point
!
interface Loopback66
344
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Topology-Independent Loop-Free Alternate (TI-LFA)
Example: SR-MPLS over GRE as TI-LFA Backup Path
!
passive enable interface tunnel-ip5060 cost 1000
!
area 100 interface TenGigE0/0/0/3 network point-to-point
!
interface Loopback60
!
passive enable interface tunnel-ip5566 cost 1000
Note In the above configuration, GRE tunnel-ip5060 belongs to area 0, but its source and destination addresses are advertised in area 100. This ensures disjointness between the GRE tunnel and the links in area 0 that it protects.
The same applies to GRE tunnel-ip5566 which belongs to area 100 and its source and destination addresses are advertised in area 0.
A high cost is applied to the GRE tunnel interfaces so that they are used only as a backup path.
TI-LFA Fast Reroute Coverage on Node 5 After GRE Tunnel Configuration
The following output shows that this configuration provides 100% TI-LFA fast reroute coverage on Node 5:
RP/0/RSP0/CPU0:Node5# show ip ospf fast-reroute prefix-summary
Load for five secs: 5%/1%; one minute: 4%; five minutes: 4%
Time source is NTP, 11:20:31.743 UTC Fri Jul 19 2019
OSPF Router with ID (5.5.5.5) (Process ID 100)
Base Topology (MTID 0)
Area 100:
Interface Protected Primary paths Protected paths Percent protected
Lo0
Te0/0/27
Te0/0/26
Yes
Yes
Yes
All High Low All High Low
0 0 0 0 0 0
9
11
6
6
3
5
9
11
6
6
3
5
All High
0% 0%
Low
0%
100% 100% 100%
100% 100% 100%
Area total:
Process total:
20
20
12
12
8
8
20
20
12
12
8 100% 100% 100%
8 100% 100% 100%
Traffic Flow with GRE Tunnel as TI-LFA Backup
With a link failure between Node 1 and ABR 2, traffic flowing from Node 1 to Node 5 is simply routed through
Nodes 4-3-6 to Node 5.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
345
Example: SR-MPLS over GRE as TI-LFA Backup Path
Configure Topology-Independent Loop-Free Alternate (TI-LFA)
With GRE tunnel as TI-LFA backup, traffic flowing from Node 5 to Node 1 will be encapsulated at ABR2 and routing over the GRE tunnel.
With a link failure between Node 5 and ABR 2, traffic flowing from Node 5 to Node 1 is simply routed through
Nodes 6-3-4 to Node 1.
With GRE tunnel as TI-LFA backup, traffic flowing from Node 1 to Node 5 will be encapsulated at ABR2 and routing over the GRE tunnel.
346
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Topology-Independent Loop-Free Alternate (TI-LFA)
Unlabeled IPv6 Traffic Protection
Unlabeled IPv6 Traffic Protection
Table 33: Feature History Table
Feature Name
IPv6 Unlabeled Traffic protection with TI-LFA
Release Information
Release 7.3.1
Feature Description
TI-LFA provides protection for
SR-labeled traffic (IPv4 and IPv6 prefixes associated with a prefix
SID) and for other unlabeled IPv4 prefixes.
This feature introduces support for protecting unlabeled IPv6 prefixes.
This feature introduces support for protecting unlabeled IPv6 prefixes. IS-IS can calculate and install TI-LFA backup paths for unlabeled IPv6 prefixes.
By default, all IPv6 prefixes without a prefix SID are eligible to have a dynamic local label assigned to them.
This behavior provides the greatest degree of protection, but in some deployments, it may consume too many
MPLS labels. This feature provides the ability to disable local label allocation or to restrict local label allocation to a subset of prefixes based on a prefix list or route policy.
Use the following commands in IS-IS IPv6 address family configuration mode to specify the local label allocation behavior:
• segment-routing mpls unlabeled protection disable —Disable local label allocation.
• segment-routing mpls unlabeled protection prefix-list sample_prefix_list —Restricts local label allocation to the prefixes based on a prefix list.
• segment-routing mpls unlabeled protection route-policy sample_rpl —Restricts local label allocation to the prefixes based a route policy.
Configuration
The following example shows how to disable local label allocation:
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
347
Configure Topology-Independent Loop-Free Alternate (TI-LFA)
Unlabeled IPv6 Traffic Protection
Router(config)# router isis 1
Router(config-isis)# address-family ipv6 unicast
Router(config-isis-af)# segment-routing mpls unlabeled protection disable
Router(config-isis-af)#
The following example shows how to enable local label allocation for prefixes in a prefix list:
Router(config)# ipv6 prefix-list sample_prefix_list
Router(config-ipv6-pfx)# 10 permit 333::333:0:0/96 ge 112
Router(config-ipv6-pfx)# 20 permit 666::666:0:0/96 ge 112
Router(config-ipv6-pfx)# exit
Router(config)#
Router(config)# router isis 1
Router(config-isis)# address-family ipv6 unicast
Router(config-isis-af)# segment-routing mpls unlabeled protection prefix-list sample_prefix_list
Router(config-isis-af)# commit
The following example shows how to enable local label allocation for prefixes in a route policy:
Router(config)# prefix-set sample_prefix_set
Router(config-pfx)# 333::333:1:0/112
Router(config-pfx)# end-set
Router(config)# route-policy sample_rpl
Router(config-rpl)# if destination in sample_prefix_set then
Router(config-rpl-if)# pass
Router(config-rpl-if)# else drop endif
Router(config-rpl)# end-policy
Router(config)#
Router(config)# router isis 1
Router(config-isis)# address-family ipv6 unicast
Router(config-isis-af)# segment-routing mpls unlabeled protection route-policy sample_rpl
Router(config-isis-af)# commit
Verification
In the following show command output, 24103 is the local label used to program the prefix with a TI-LFA backup.
Router# show isis ipv6 unicast route 333::333:1:0/112 detail
L2 333::333:1:0/112 [120/115] Label: 24103 , low priority via fe80::28a:96ff:fef4:5403, TenGigE0/1/0/3/5, r6, SRGB Base: 16000, Weight: 0 src R1.00-01, 1:1:1::1
Router# show isis ipv6 fast-reroute 333::333:1:0/112 detail
L2 333::333:1:0/112 [120/115] Label: 24103 , low priority via fe80::28a:96ff:fef4:5403, TenGigE0/1/0/3/5, R6, SRGB Base: 16000, Weight: 0
Backup path: TI-LFA (link) , via fe80::2c1:64ff:fe60:39b9, TenGigE0/1/0/3/0 R4, SRGB
Base: 16000, Weight: 0, Metric: 140
P node: R3.00 [3:3:3::3], Label: 16333
Prefix label: None
Backup-src: R1.00
P: No, TM: 140, LC: No, NP: No, D: No, SRLG: Yes src R1.00-a9, 1:1:1::1
Router# show route ipv6 333::333:1:0/112 detail
Routing entry for 333::333:1:0/112
Known via "isis 1" , distance 115, metric 120, type level-2
Installed Jul 26 19:11:58.840 for 00:00:47
Routing Descriptor Blocks fe80::2c1:64ff:fe60:39b9, from 1:1:1::1, via TenGigE0/1/0/3/0, Backup (TI-LFA)
Repair Node(s): 3:3:3::3
348
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Topology-Independent Loop-Free Alternate (TI-LFA)
Unlabeled IPv6 Traffic Protection
Route metric is 140
Label: 0x3fcd (16333)
Tunnel ID: None
Binding Label: None
Extended communities count: 0
Path id:65 Path ref count:1
NHID:0x20008(Ref:20026) fe80::28a:96ff:fef4:5403, from 1:1:1::1, via TenGigE0/1/0/3/5, Protected
Route metric is 120
Label: None
Tunnel ID: None
Binding Label: None
Extended communities count: 0
Path id:1 Path ref count:0
NHID:0x20009(Ref:20021)
Backup path id:65
Route version is 0x1e (30)
Local Label: 0x5e27 (24103)
IP Precedence: Not Set
QoS Group ID: Not Set
Flow-tag: Not Set
Fwd-class: Not Set
Route Priority: RIB_PRIORITY_NON_RECURSIVE_LOW (8) SVD Type RIB_SVD_TYPE_LOCAL
Download Priority 2, Download Version 4200135
No advertising protos.
Router# show mpls forwarding labels 24103
Local Outgoing
Label Label
Prefix or ID
Outgoing
Interface
Next Hop Bytes
Switched
------ ----------- ------------------ ------------ --------------- ------------
24103 Unlabelled 333::333:1:0/112 Te0/1/0/3/5 fe80::28a:96ff:fef4:5403 \
16333
0
333::333:1:0/112 Te0/1/0/3/0 fe80::2c1:64ff:fe60:39b9 \
0 (!)
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
349
Unlabeled IPv6 Traffic Protection
Configure Topology-Independent Loop-Free Alternate (TI-LFA)
350
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
C H A P T E R
12
Configure Segment Routing Microloop Avoidance
The Segment Routing Microloop Avoidance feature enables link-state routing protocols, such as IS-IS and
OSPF, to prevent or avoid microloops during network convergence after a topology change.
•
About Segment Routing Microloop Avoidance, on page 351
•
Segment Routing Microloop Avoidance Limitations, on page 351
•
Configure Segment Routing Microloop Avoidance for IS-IS, on page 351
•
Configure Segment Routing Microloop Avoidance for OSPF, on page 352
About Segment Routing Microloop Avoidance
Microloops are brief packet loops that occur in the network following a topology change (link down, link up, or metric change events). Microloops are caused by the non-simultaneous convergence of different nodes in the network. If nodes converge and send traffic to a neighbor node that has not converged yet, traffic may be looped between these two nodes, resulting in packet loss, jitter, and out-of-order packets.
The Segment Routing Microloop Avoidance feature detects if microloops are possible following a topology change. If a node computes that a microloop could occur on the new topology, the node creates a loop-free
SR-TE policy path to the destination using a list of segments. After the RIB update delay timer expires, the
SR-TE policy is replaced with regular forwarding paths.
Segment Routing Microloop Avoidance Limitations
For IS-IS, Segment Routing Microloop Avoidance is not supported when incremental shortest path first (ISPF) is configured.
Configure Segment Routing Microloop Avoidance for IS-IS
This task describes how to enable Segment Routing Microloop Avoidance and set the Routing Information
Base (RIB) update delay value for IS-IS.
Before you begin
Ensure that the following topology requirements are met:
• Router interfaces are configured as per the topology.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
351
Configure Segment Routing Microloop Avoidance
Configure Segment Routing Microloop Avoidance for OSPF
• Routers are configured with IS-IS.
• Segment routing for IS-IS is configured. See
Enabling Segment Routing for IS-IS Protocol, on page 95 .
Procedure
Step 1
Step 2
Step 3
Step 4
Step 5
Command or Action configure
Example:
Purpose
Enters mode.
RP/0/RP0/CPU0:router# configure
router isis instance-id
Example:
Enables IS-IS routing for the specified routing instance, and places the router in router configuration mode.
RP/0/RP0/CPU0:router(config)# router isis
1
You can change the level of routing to be performed by a particular routing instance by using the is-type router configuration command.
address-family ipv4 [ unicast ]
Example:
Specifies the IPv4 address family and enters router address family configuration mode.
RP/0/RP0/CPU0:router(config-isis)# address-family ipv4 unicast microloop avoidance segment-routing
Example:
Enables Segment Routing Microloop
Avoidance.
RP/0/RP0/CPU0:router(config-isis-af)# microloop avoidance segment-routing microloop avoidance rib-update-delay delay-time
Example:
RP/0/RP0/CPU0:router(config-isis-af)# microloop avoidance rib-update-delay 3000
Specifies the amount of time the node uses the microloop avoidance policy before updating its forwarding table. The delay-time is in milliseconds. The range is from 1-60000. The default value is 5000.
Configure Segment Routing Microloop Avoidance for OSPF
This task describes how to enable Segment Routing Microloop Avoidance and set the Routing Information
Base (RIB) update delay value for OSPF.
Before you begin
Ensure that the following topology requirements are met:
• Router interfaces are configured as per the topology.
352
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing Microloop Avoidance
Configure Segment Routing Microloop Avoidance for OSPF
• Routers are configured with OSPF.
• Segment routing for OSPF is configured. See
Enabling Segment Routing for OSPF Protocol, on page
.
Procedure
Step 1
Step 2
Step 3
Step 4
Command or Action configure
Example:
Purpose
Enters mode.
RP/0/RP0/CPU0:router# configure
router ospf process-name
Example:
Enables OSPF routing for the specified routing process, and places the router in router configuration mode.
RP/0/RP0/CPU0:router(config)# router ospf
1 microloop avoidance segment-routing
Example:
Enables Segment Routing Microloop
Avoidance.
RP/0/RP0/CPU0:router(config-ospf)# microloop avoidance segment-routing microloop avoidance rib-update-delay delay-time
Example:
RP/0/RP0/CPU0:router(config-ospf)# microloop avoidance rib-update-delay 3000
Specifies the amount of time the node uses the microloop avoidance policy before updating its forwarding table. The delay-time is in milliseconds. The range is from 1-60000. The default value is 5000.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
353
Configure Segment Routing Microloop Avoidance for OSPF
Configure Segment Routing Microloop Avoidance
354
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
C H A P T E R
13
Configure Segment Routing Mapping Server
The mapping server is a key component of the interworking between LDP and segment routing. It enables
SR-capable nodes to interwork with LDP nodes. The mapping server advertises Prefix-to-SID mappings in
IGP on behalf of other non-SR-capable nodes.
•
Segment Routing Mapping Server, on page 355
•
Segment Routing and LDP Interoperability, on page 357
•
Configuring Mapping Server, on page 358
•
Enable Mapping Advertisement, on page 360
•
Enable Mapping Client, on page 363
Segment Routing Mapping Server
The mapping server functionality in Cisco IOS XR segment routing centrally assigns prefix-SIDs for some or all of the known prefixes. A router must be able to act as a mapping server, a mapping client, or both.
• A router that acts as a mapping server allows the user to configure SID mapping entries to specify the prefix-SIDs for some or all prefixes. This creates the local SID-mapping policy. The local SID-mapping policy contains non-overlapping SID-mapping entries. The mapping server advertises the local
SID-mapping policy to the mapping clients.
• A router that acts as a mapping client receives and parses remotely received SIDs from the mapping server to create remote SID-mapping entries.
• A router that acts as a mapping server and mapping client uses the remotely learnt and locally configured mapping entries to construct the non-overlapping consistent active mapping policy. IGP instance uses the active mapping policy to calculate the prefix-SIDs of some or all prefixes.
The mapping server automatically manages the insertions and deletions of mapping entries to always yield an active mapping policy that contains non-overlapping consistent SID-mapping entries.
• Locally configured mapping entries must not overlap each other.
• The mapping server takes the locally configured mapping policy, as well as remotely learned mapping entries from a particular IGP instance, as input, and selects a single mapping entry among overlapping mapping entries according to the preference rules for that IGP instance. The result is an active mapping policy that consists of non-overlapping consistent mapping entries.
• At steady state, all routers, at least in the same area or level, must have identical active mapping policies.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
355
Configure Segment Routing Mapping Server
Usage Guidelines and Restrictions
Usage Guidelines and Restrictions
Table 34: Feature History Table
Feature Name
Advertisement of SID-Mapping
Entries Between IS-IS Levels
Release Information
Release 7.3.1
Feature Description
The Segment Routing Mapping
Server (SRMS) is a key component of the interworking between LDP and segment routing, enabling
SR-capable nodes to interwork with
LDP nodes.
This release introduces support for
SRMS SID-mapping entries to be advertised between IS-IS levels (for example, from Level 1 to Level
2-only and from Level 2 to Level
1), where previously, the mappings were advertised only within the same IS-IS level, but not between
IS-IS levels. This feature simplifies and centralizes the deployment of
SRMS by removing the requirement of having a mapping server for each IS-IS area.
• The position of the mapping server in the network is not important. However, since the mapping advertisements are distributed in IGP using the regular IGP advertisement mechanism, the mapping server needs an IGP adjacency to the network.
• The role of the mapping server is crucial. For redundancy purposes, you should configure multiple mapping servers in the networks.
• The mapping server functionality supports the advertisement of SID-mapping entries between IS-IS levels (for example, from L1 to L2-only and from L2 to L1). A mapping server is not required for each
IS-IS area.
For example, mapping entries learned from IS-IS Type Level-1 (intra-area) routers can be used to calculate prefix-SIDs for prefixes learned or advertised by IS-IS Type Level-2-only (backbone) routers.
Use the domain-wide option to advertise the prefix-SID mappings between Level 1 and Level 2 IS-IS routers.
• The mapping server functionality does not support a scenario where SID-mapping entries learned through one IS-IS instance are used by another IS-IS instance to determine the prefix-SID of a prefix. For example, mapping entries learnt from remote routers by 'router isis 1' cannot be used to calculate prefix-SIDs for prefixes learnt, advertised, or downloaded to FIB by 'router isis 2'. A mapping server is required for each
IS-IS instance.
• Segment Routing Mapping Server does not support Virtual Routing and Forwarding (VRF) currently.
356
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing Mapping Server
Segment Routing and LDP Interoperability
Segment Routing and LDP Interoperability
IGP provides mechanisms through which segment routing (SR) interoperate with label distribution protocol
(LDP). The control plane of segment routing co-exists with LDP.
The Segment Routing Mapping Server (SRMS) functionality in SR is used to advertise SIDs for destinations, in the LDP part of the network, that do not support SR. SRMS maintains and advertises segment identifier
(SID) mapping entries for such destinations. IGP propagates the SRMS mapping entries and interacts with
SRMS to determine the SID value when programming the forwarding plane. IGP installs prefixes and corresponding labels, into routing information base (RIB), that are used to program the forwarding information base (FIB).
Example: Segment Routing LDP Interoperability
Consider a network with a mix of segment routing (SR) and label distribution protocol (LDP). A continuous multiprotocol label switching (MPLS) LSP (Labeled Switched Path) can be established by facilitating interoperability. One or more nodes in the SR domain act as segment routing mapping server (SRMS). SRMS advertises SID mappings on behalf of non-SR capable nodes. Each SR-capable node learns about SID assigned to non-SR capable nodes without explicitly configuring individual nodes.
Consider a network as shown in the following image. This network is a mix of both LDP and SR-capable nodes.
In this mixed network:
• Nodes P6, P7, P8, PE4 and PE3 are LDP-capable
• Nodes PE1, PE2, P5 and P6 are SR-capable
• Nodes PE1, PE2, P5 and P6 are configured with segment routing global block (SRGB) of (100, 200)
• Nodes PE1, PE2, P5 and P6 are configured with node segments of 101, 102, 105 and 106 respectively
A service flow must be established from PE1 to PE3 over a continuous MPLS tunnel. This requires SR and
LDP to interoperate.
LDP to SR
The traffic flow from LDP to SR (right to left) involves:
1.
PE3 learns a service route whose nhop is PE1. PE3 has an LDP label binding from the nhop P8 for the
FEC PE1. PE3 forwards the packet P8.
2.
P8 has an LDP label binding from its nhop P7 for the FEC PE1. P8 forwards the packet to P7.
3.
P7 has an LDP label binding from its nhop P6 for the FEC PE1. P7 forwards the packet to P6.
4.
P6 does not have an LDP binding from its nhop P5 for the FEC PE1. But P6 has an SR node segment to the IGP route PE1. P6 forwards the packet to P5 and swaps its local LDP label for FEC PE1 by the equivalent node segment 101. This process is called label merging.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
357
Configure Segment Routing Mapping Server
Configuring Mapping Server
5.
P5 pops 101, assuming PE1 has advertised its node segment 101 with the penultimate-pop flag set and forwards to PE1.
6.
PE1 receives the tunneled packet and processes the service label.
The end-to-end MPLS tunnel is established from an LDP LSP from PE3 to P6 and the related node segment from P6 to PE1.
SR to LDP
Suppose that the operator configures P5 as a Segment Routing Mapping Server (SRMS) and advertises the mappings (P7, 107), (P8, 108), (PE3, 103) and (PE4, 104). If PE3 was SR-capable, the operator may have configured PE3 with node segment 103. Because PE3 is non-SR capable, the operator configures that policy at the SRMS; the SRMS advertises the mapping on behalf of the non-SR capable nodes. Multiple SRMS servers can be provisioned in a network for redundancy. The mapping server advertisements are only understood by the SR-capable nodes. The SR capable routers install the related node segments in the MPLS data plane in exactly the same manner if node segments were advertised by the nodes themselves.
The traffic flow from SR to LDP (left to right) involves:
1.
PE1 installs the node segment 103 with nhop P5 in exactly the same manner if PE3 had advertised node segment 103.
2.
P5 swaps 103 for 103 and forwards to P6.
3.
The nhop for P6 for the IGP route PE3 is non-SR capable. (P7 does not advertise the SR capability.)
However, P6 has an LDP label binding from that nhop for the same FEC. (For example, LDP label 103.)
P6 swaps 103 for 103 and forwards to P7. We refer to this process as label merging.
4.
P7 swaps this label with the LDP label received from P8 and forwards to P8.
5.
P8 pops the LDP label and forwards to PE3.
6.
PE3 receives the packet and processes as required.
The end-to-end MPLS LSP is established from an SR node segment from PE1 to P6 and an LDP LSP from
P6 to PE3.
Configuring Mapping Server
Perform these tasks to configure the mapping server and to add prefix-SID mapping entries in the active local mapping policy.
Procedure
Step 1
Command or Action configure
Example:
RP/0/RP0/CPU0:router# configure
Purpose
Enters mode.
358
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing Mapping Server
Configuring Mapping Server
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Command or Action segment-routing
Example:
RP/0/RP0/CPU0:router(config)# segment-routing
Purpose
Enables segment routing.
mapping-server
Example:
RP/0/RP0/CPU0:router(config-sr)# mapping-server prefix-sid-map
Example:
RP/0/RP0/CPU0:router(config-sr-ms)# prefix-sid-map address-family ipv4 | ipv6
Example:
This example shows the address-family for ipv4:
RP/0/RP0/CPU0:router(config-sr-ms-map)# address-family ipv4
This example shows the address-family for ipv6:
Enables mapping server configuration mode.
Enables prefix-SID mapping configuration mode.
Note Two-way prefix SID can be enabled directly under IS-IS or through a mapping server.
Configures address-family for IS-IS.
RP/0/RP0/CPU0:router(config-sr-ms-map)# address-family ipv6 ip-address
Example:
/ prefix-length first-SID-value
range range
RP/0/RP0/CPU0:router(config-sr-ms-map-af)#
10.1.1.1/32 10 range 200
RP/0/RP0/CPU0:router(config-sr-ms-map-af)#
20.1.0.0/16 400 range 300
Adds SID-mapping entries in the active local mapping policy. In the configured example:
• Prefix 10.1.1.1/32 is assigned prefix-SID
10, prefix 10.1.1.2/32 is assigned prefix-SID 11,…, prefix 10.1.1.199/32 is assigned prefix-SID 200
• Prefix 20.1.0.0/16 is assigned prefix-SID
400, prefix 20.2.0.0/16 is assigned prefix-SID 401,…, and so on.
Use the commit or end command.
commit —Saves the configuration changes and remains within the configuration session.
end —Prompts user to take one of these actions:
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
359
Configure Segment Routing Mapping Server
Enable Mapping Advertisement
Command or Action Purpose
• Yes — Saves configuration changes and exits the configuration session.
• No —Exits the configuration session without committing the configuration changes.
• Cancel —Remains in the configuration session, without committing the configuration changes.
Verify information about the locally configured prefix-to-SID mappings.
Note Specify the address family for IS-IS.
RP/0/RP0/CPU0:router# show segment-routing mapping-server prefix-sid-map ipv4
Prefix
20.1.1.0/24
SID Index
400
Range
300
Flags
10.1.1.1/32 10 200
Number of mapping entries: 2
RP/0/RP0/CPU0:router# show segment-routing mapping-server prefix-sid-map ipv4 detail
Prefix
20.1.1.0/24
SID Index:
Range:
Last Prefix:
400
300
20.2.44.0/24
Last SID Index: 699
Flags:
10.1.1.1/32
SID Index:
Range:
10
200
Last Prefix: 10.1.1.200/32
Last SID Index: 209
Flags:
Number of mapping entries: 2
What to do next
Enable the advertisement of the local SID-mapping policy in the IGP.
Enable Mapping Advertisement
In addition to configuring the static mapping policy, you must enable the advertisement of the mappings in the IGP.
Perform these steps to enable the IGP to advertise the locally configured prefix-SID mapping.
360
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing Mapping Server
Configure Mapping Advertisement for IS-IS
Configure Mapping Advertisement for IS-IS
Procedure
Step 1
Step 2
Step 3
Step 4
Command or Action Purpose
router isis instance-id
Example:
RP/0/RP0/CPU0:router(config)# router isis
1
Enables IS-IS routing for the specified routing instance, and places the router in router configuration mode.
• You can change the level of routing to be performed by a particular routing instance by using the is-type router configuration command.
address-family { ipv4 | ipv6 } [ unicast ]
Example:
The following is an example for ipv4 address family:
Specifies the IPv4 or IPv6 address family, and enters router address family configuration mode.
RP/0/RP0/CPU0:router(config-isis)# address-family ipv4 unicast segment-routing prefix-sid-map advertise-local [ domain-wide ]
Example:
RP/0/RP0/CPU0:router(config-isis-af)# segment-routing prefix-sid-map advertise-local
Configures IS-IS to advertise locally configured prefix-SID mappings. Use the domain-wide option to advertise the prefix-SID mappings between IS-IS Level 1 and Level 2 routers.
RP/0/RP0/CPU0:router(config-isis-af)# segment-routing prefix-sid-map advertise-local domain-wide
Use the commit or end command.
commit —Saves the configuration changes and remains within the configuration session.
end —Prompts user to take one of these actions:
• Yes — Saves configuration changes and exits the configuration session.
• No —Exits the configuration session without committing the configuration changes.
• Cancel —Remains in the configuration session, without committing the configuration changes.
Verify IS-IS prefix-SID mapping advertisement and TLV.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
361
Configure Segment Routing Mapping Server
Configure Mapping Advertisement for OSPF
RP/0/RP0/CPU0:router# show isis database verbose
<...removed...>
SID Binding: 10.1.1.1/32 F:0 M:0 S:0 D:0 A:0 Weight:0 Range:200
SID: Start:10 , Algorithm:0, R:0 N:0 P:0 E:0 V:0 L:0
SID Binding: 20.1.1.0/24 F:0 M:0 S:0 D:0 A:0 Weight:0 Range:300
SID: Start:400 , Algorithm:0, R:0 N:0 P:0 E:0 V:0 L:0
Configure Mapping Advertisement for OSPF
Procedure
Step 1
Step 2
Step 3
Command or Action
router ospf process-name
Example:
Purpose
Enables OSPF routing for the specified routing instance, and places the router in router configuration mode.
RP/0/RP0/CPU0:router(config)# router ospf
1 segment-routing prefix-sid-map advertise-local
Example:
Configures OSPF to advertise locally configured prefix-SID mappings.
RP/0/RP0/CPU0:router(config-ospf)# segment-routing prefix-sid-map advertise-local
Use the commit or end command.
commit —Saves the configuration changes and remains within the configuration session.
end —Prompts user to take one of these actions:
• Yes — Saves configuration changes and exits the configuration session.
• No —Exits the configuration session without committing the configuration changes.
• Cancel —Remains in the configuration session, without committing the configuration changes.
Verify OSP prefix-SID mapping advertisement and TLV.
RP/0/RP0/CPU0:router# show ospf database opaque-area
<...removed...>
Extended Prefix Range TLV: Length: 24
362
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Configure Segment Routing Mapping Server
Enable Mapping Client
AF
Prefix
: 0
: 10.1.1.1/32
Range Size: 200
Flags : 0x0
SID sub-TLV: Length: 8
Flags
MTID
: 0x60
: 0
Algo : 0
SID Index : 10
Enable Mapping Client
By default, mapping client functionality is enabled.
You can disable the mapping client functionality by using the segment-routing prefix-sid-map receive disable command.
You can re-enable the mapping client functionality by using the segment-routing prefix-sid-map receive command.
The following example shows how to enable the mapping client for IS-IS:
RP/0/RP0/CPU0:router(config)# router isis 1
RP/0/RP0/CPU0:router(config-isis)# address-family ipv4 unicast
RP/0/RP0/CPU0:router(config-isis-af)# segment-routing prefix-sid-map receive
The following example shows how to enable the mapping client for OSPF:
RP/0/RP0/CPU0:router(config)# router ospf 1
RP/0/RP0/CPU0:router(config-ospf)# segment-routing prefix-sid-map receive disable
RP/0/RP0/CPU0:router(config-ospf)# commit
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
363
Enable Mapping Client
Configure Segment Routing Mapping Server
364
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
C H A P T E R
14
Enabling Segment Routing Flexible Algorithm
Segment Routing Flexible Algorithm allows operators to customize IGP shortest path computation according to their own needs. An operator can assign custom SR prefix-SIDs to realize forwarding beyond link-cost-based
SPF. As a result, Flexible Algorithm provides a traffic engineered path automatically computed by the IGP to any destination reachable by the IGP.
The SR architecture associates prefix-SIDs to an algorithm which defines how the path is computed. Flexible
Algorithm allows for user-defined algorithms where the IGP computes paths based on a user-defined combination of metric type and constraint.
This document describes the IS-IS and OSPF extensions to support Segment Routing Flexible Algorithm on an MPLS data-plane.
•
Prerequisites for Flexible Algorithm, on page 365
•
Building Blocks of Segment Routing Flexible Algorithm, on page 365
•
Configuring Flexible Algorithm, on page 370
•
Example: Configuring IS-IS Flexible Algorithm, on page 377
•
Example: Configuring IS-IS Flexible Algorithm, on page 377
•
Example: Configuring OSPF Flexible Algorithm, on page 378
•
Example: Traffic Steering to Flexible Algorithm Paths, on page 379
•
Delay Normalization, on page 382
Prerequisites for Flexible Algorithm
Segment routing must be enabled on the router before the Flexible Algorithm functionality is activated.
Building Blocks of Segment Routing Flexible Algorithm
This section describes the building blocks that are required to support the SR Flexible Algorithm functionality in IS-IS and OSPF.
Flexible Algorithm Definition
Many possible constraints may be used to compute a path over a network. Some networks are deployed with multiple planes. A simple form of constraint may be to use a particular plane. A more sophisticated form of constraint can include some extended metric, like delay, as described in [RFC7810]. Even more advanced
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
365
Enabling Segment Routing Flexible Algorithm
Flexible Algorithm Membership case could be to restrict the path and avoid links with certain affinities. Combinations of these are also possible.
To provide a maximum flexibility, the mapping between the algorithm value and its meaning can be defined by the user. When all the routers in the domain have the common understanding what the particular algorithm value represents, the computation for such algorithm is consistent and the traffic is not subject to looping.
Here, since the meaning of the algorithm is not defined by any standard, but is defined by the user, it is called a Flexible Algorithm.
Flexible Algorithm Membership
An algorithm defines how the best path is computed by IGP. Routers advertise the support for the algorithm as a node capability. Prefix-SIDs are also advertised with an algorithm value and are tightly coupled with the algorithm itself.
An algorithm is a one octet value. Values from 128 to 255 are reserved for user defined values and are used for Flexible Algorithm representation.
Flexible Algorithm Definition Advertisement
To guarantee the loop free forwarding for paths computed for a particular Flexible Algorithm, all routers in the network must share the same definition of the Flexible Algorithm. This is achieved by dedicated router(s) advertising the definition of each Flexible Algorithm. Such advertisement is associated with the priority to make sure that all routers will agree on a single and consistent definition for each Flexible Algorithm.
Definition of Flexible Algorithm includes:
• Metric type
• Affinity constraints
• Exclude SRLG constraint
To enable the router to advertise the definition for the particular Flexible Algorithm, advertise-definition command is used. At least one router in the area, preferably two for redundancy, must advertise the Flexible
Algorithm definition. Without the valid definition being advertised, the Flexible Algorithm will not be functional.
Flexible Algorithm Link Attribute Advertisement
Various link attributes may be used during the Flexible Algorithm path calculation. For example, include or exclude rules based on link affinities can be part of the Flexible Algorithm definition, as defined in IETF draft draft-ietf-lsr-flex-algo .
Link attribute advertisements used during Flexible Algorithm calculation must use the Application-Specific
Link Attribute (ASLA) advertisements, as defined in RFC8919 (IS-IS) and RFC8920 (OSPF). In the case of
IS-IS, if the L-Flag is set in the ASLA advertisement, then legacy advertisements (IS-IS Extended Reachability
TLV) are used instead.
The mandatory use of ASLA advertisements applies to the following link attributes:
• Minimum Unidirectional Link Delay
• TE Default Metric
• Administrative Group
366
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Enabling Segment Routing Flexible Algorithm
Flexible Algorithm Prefix-SID Advertisement
• Extended Administrative Group
• Shared Risk Link Group
Flexible Algorithm Prefix-SID Advertisement
To be able to forward traffic on a Flexible Algorithm specific path, all routers participating in the Flexible
Algorithm will install a MPLS labeled path for the Flexible Algorithm specific SID that is advertised for the prefix. Only prefixes for which the Flexible Algorithm specific Prefix-SID is advertised is subject to Flexible
Algorithm specific forwarding.
Calculation of Flexible Algorithm Path
Table 35: Feature History Table
Feature Name
OSPF: Microloop Avoidance for
Flexible Algorithm
Release Information
Release 7.3.2
OSPF: TI-LFA for Flexible
Algorithm
Release 7.3.1
Feature Description
This feature extends the current
OSPF Flexible Algorithm functionality to support Microloop
Avoidance.
This feature extends the current
OSPF Flexible Algorithm functionality to support TI-LFA.
Table 36: Feature History Table
Feature Name
OSPF: Microloop Avoidance for
Flexible Algorithm
Release Information
Release 7.4.1
Feature Description
This feature extends the current
OSPF Flexible Algorithm functionality to support Microloop
Avoidance.
A router may compute path for multiple Flexible Algorithms. A router must be configured to support particular
Flexible Algorithm before it can compute any path for such Flexible Algorithm. A router must have a valid definition of the Flexible Algorithm before Flexible Algorithm is used.
When computing the shortest path tree for particular Flexible Algorithm:
• All nodes that don't advertise support for Flexible Algorithm are pruned from the topology.
• If the Flexible Algorithm definition includes affinities that are excluded, then all links for which any of such affinities are advertised will be pruned from the topology.
• If the Flexible Algorithm definition includes an "exclude SRLG" rule, then all links that are part of such
SRLG are pruned from the topology.
• Router uses the metric that is part of the Flexible Algorithm definition. If the metric isn't advertised for the particular link, the link is pruned from the topology.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
367
Enabling Segment Routing Flexible Algorithm
Installation of Forwarding Entries for Flexible Algorithm Paths
Loop Free Alternate (LFA) paths, TI-LFA backup paths, and Microloop Avoidance paths for particular Flexible
Algorithm are computed using the same constraints as the calculation of the primary paths for such Flexible
Algorithm. These paths use Prefix-SIDs advertised specifically for such Flexible Algorithm in order to enforce a backup or microloop avoidance path.
Configuring Microloop Avoidance for Flexible Algorithm
By default, Microloop Avoidance per Flexible Algorithm instance follows Microloop Avoidance configuration for algo-0. For information about configuring Microloop Avoidance, see
Configure Segment Routing Microloop
You can disable Microloop Avoidance for Flexible Algorithm using the following commands:
router isis instance flex-algo algo microloop avoidance disable
router ospf process flex-algo algo microloop avoidance disable
Configuring LFA / TI-LFA for Flexible Algorithm
By default, LFA/TI-LFA per Flexible Algorithm instance follows LFA/TI-LFA configuration for algo-0. For information about configuring TI-LFA, see
Configure Topology-Independent Loop-Free Alternate (TI-LFA), on page 325 .
You can disable TI-LFA for Flexible Algorithm using the following commands:
router isis instance flex-algo algo fast-reroute disable
router ospf process flex-algo algo fast-reroute disable
Installation of Forwarding Entries for Flexible Algorithm Paths
Flexible Algorithm path to any prefix must be installed in the forwarding using the Prefix-SID that was advertised for such Flexible Algorithm. If the Prefix-SID for Flexible Algorithm is not known, such Flexible
Algorithm path is not installed in forwarding for such prefix..
Only MPLS to MPLS entries are installed for a Flexible Algorithm path. No IP to IP or IP to MPLS entries are installed. These follow the native IPG paths computed based on the default algorithm and regular IGP metrics.
Flexible Algorithm Prefix-SID Redistribution
Previously, prefix redistribution from IS-IS to another IS-IS instance or protocol was limited to SR algorithm
0 (regular SPF) prefix SIDs; SR algorithm 1 (Strict SPF) and SR algorithms 128-255 (Flexible Algorithm) prefix SIDs were not redistributed along with the prefix. The Segment Routing IS-IS Flexible Algorithm
Prefix SID Redistribution feature allows redistribution of strict and flexible algorithms prefix SIDs from IS-IS to another IS-IS instance or protocols. This feature is enabled automatically when you configure redistribution of IS-IS Routes with strict or Flexible Algorithm SIDs.
368
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Enabling Segment Routing Flexible Algorithm
Flexible Algorithm Prefix Metric
Flexible Algorithm Prefix Metric
Table 37: Feature History Table
Feature Name
Prefix Metric support for OSPF
Flexible Algorithm
Release Information
Release 7.5.1
Feature Description
This feature extends the current
OSPF Flexible Algorithm functionality to introduce a Flexible
Algorithm-specific prefix-metric in the OSPF prefix advertisement. The prefix-metric provides a way to compute the best end-to-end
Flexible Algorithm optimized paths across multiple areas or domains.
A limitation of the existing Flexible Algorithm functionality in IS-IS and OSPF is the inability to compute the best path to a prefix in a remote area or remote IGP domain. Prefixes are advertised between IS-IS areas,
OSPF processes, or between protocol domains, but the existing prefix metric does not reflect any of the constraints used for Flexible Algorithm path. Although the best Flexible Algorithm path can be computed to the inter-area or redistributed prefix inside the area, the path may not represent the overall best path through multiple areas or IGP domains.
The Flexible Algorithm Prefix Metric feature introduces a Flexible Algorithm-specific prefix-metric in the
IS-IS and OSPF prefix advertisement. The prefix-metric provides a way to compute the best end-to-end
Flexible Algorithm optimized paths across multiple areas or domains.
Note The Flexible Algorithm definition must be consistent between domains or areas. Refer to section 8 and section
9 in IETF draft https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/ .
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
369
Enabling Segment Routing Flexible Algorithm
Configuring Flexible Algorithm
Configuring Flexible Algorithm
Table 38: Feature History Table
Feature Name
TE Metric Support for IS-IS Flex
Algo
Release Information
Release 7.4.1
Feature Description
Flexible Algorithm allows for user-defined algorithms where the
IGP computes paths based on a user-defined combination of metric type (path optimization objective) and constraint.
This feature add support for TE metric as a metric type for IS-IS
Flexible Algorithm. This allows the
TE metric, along with IGP and delay metrics, to be used when running shortest path computations.
The following ISIS and OSPF configuration sub-mode is used to configure Flexible Algorithm:
router isis instance flex-algo algo
router ospf process flex-algo algo algo —value from 128 to 255
Configuring Flexible Algorithm Definitions
The following commands are used to configure Flexible Algorithm definition under the flex-algo sub-mode:
•
router isis instance flex-algo algo metric-type { delay | te }
router ospf process flex-algo algo metric-type { delay | te-metric }
Note
By default the IGP metric is used. If delay or TE metric is enabled, the advertised delay or TE metric on the link is used as a metric for
Flexible Algorithm computation.
Note
See
Flexible Algorithm Link Attribute Advertisement Behavior, on page 372
for TE metric behaviors.
•
router isis instance flex-algo algo affinity { include-any | include-all | exclude-any } name1, name2, …
router ospf process flex-algo algo affinity { include-any | include-all | exclude-any } name1, name2, …
370
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Enabling Segment Routing Flexible Algorithm
Configuring Flexible Algorithm name —name of the affinity map
•
router isis instance flex-algo algo priority priority value
router ospf process flex-algo algo priority priority value priority value —priority used during the Flexible Algorithm definition election.
The following command is used to to include the Flexible Algorithm prefix metric in the advertised Flexible
Algorithm definition in IS-IS and OSPF :
router isis instance flex-algo algo prefix-metric
router ospf process flex-algo algo prefix-metric
The following command is used to enable advertisement of the Flexible Algorithm definition in IS-IS:
router isis instance flex-algo algo advertise-definition
Configuring Affinity
The following command is used for defining the affinity-map. Affinity-map associates the name with the particular bit positions in the Extended Admin Group bitmask.
router isis instance flex-algo algo affinity-map name bit-position bit number
router ospf process flex-algo algo affinity-map name bit-position bit number
• name —name of the affinity-map.
• bit number —bit position in the Extended Admin Group bitmask.
The following command is used to associate the affinity with an interface:
router isis instance interface type interface-path-id affinity flex-algo name 1, name 2, …
router ospf process area area interface type interface-path-id affinity flex-algo name 1, name 2, … name —name of the affinity-map
Configuring Prefix-SID Advertisement
The following command is used to advertise prefix-SID for default and strict-SPF algorithm:
router isis instance interface type interface-path-id address-family { ipv4 | ipv6 } [ unicast ] prefix-sid [ strict-spf | algorithm algorithm-number ] [ index | absolute ] sid value
router ospf process area area interface Loopback interface-instance prefix-sid [ strict-spf
| algorithm algorithm-number ] [ index | absolute ] sid value
• algorithm-number —Flexible Algorithm number
• sid value —SID value
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
371
Enabling Segment Routing Flexible Algorithm
Flexible Algorithm Link Attribute Advertisement Behavior
Flexible Algorithm Link Attribute Advertisement Behavior
Table 39: Feature History Table
Feature Name
Advertisement of Link Attributes for IS-IS Flexible Algorithm
Release Information
Release 7.4.1
Feature Description
Link attribute advertisements used during Flexible Algorithm path calculation must use the
Application-Specific Link Attribute
(ASLA) advertisements, as defined in IETF draft draft-ietf-lsr-flex-algo .
This feature introduces support for
ASLA advertisements during IS-IS
Flexible Algorithm path calculation.
The following tables explain the behaviors for advertising (transmitting) and processing (receiving) Flexible
Algorithm link attributes.
Table 40: OSPF
Link Attribute
Link Delay Metric
Link TE Metric
Transmit Receive
IOS XR OSPF Flex Algo implementation advertises the link delay metric value using the OSPF
ASLA sub-TLV with the F-bit set.
IOS XR OSPF only uses the link delay metric advertised in the
ASLA sub-TLV for Flex Algo.
ASLA sub-TLV is supported with non-zero-length or with zero-length
Application Identifier Bit Masks.
IOS XR OSPF Flex Algo implementation advertises the link
TE metric value using the OSPF
ASLA sub-TLV with the F-bit set.
The link TE metric values advertised are configured under
SR-TE.
IOS XR OSPF only uses the TE metric advertised in the ASLA sub-TLV for Flex Algo.
ASLA sub-TLV is supported with non-zero-length or with zero-length
Application Identifier Bit Masks.
372
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Enabling Segment Routing Flexible Algorithm
Flexible Algorithm Link Attribute Advertisement Behavior
Link Attribute
Link Admin Group/Extended
Admin Group
Transmit Receive
IOS XR OSPF Flex Algo implementation advertises the link admin group value using both link admin group (AG) and link extended admin group (EAG) encoding using the OSPF ASLA sub-TLV with the F-bit set.
IOS XR OSPF only uses the
AG/EAG (either one or both) advertised in the ASLA sub-TLV for Flex Algo.
ASLA sub-TLV is supported with non-zero-length or with zero-length
Application Identifier Bit Masks.
The link admin group values advertised can be configured directly under the IGP and are therefore FA-specific. Otherwise, they will be derived from the link admin group values configured under SR-TE.
Table 41: IS-IS
Link Attribute
Link Delay
Metric
Transmit Receive
IOS XR IS-IS Flex Algo implementation advertises the link delay metric value using both the IS-IS
Extended Reachability TLV and the
IS-IS ASLA.
By default, IOS XR IS-IS Flex Algo implementation prefers the link delay metric value received in the IS-IS ASLA. Otherwise, it will use link delay metric value received in the IS-IS
Extended Reachability TLV.
ASLA sub-TLV is supported with non-zero-length or with zero-length Application Identifier Bit
Masks.
If the incoming ASLA includes the L-Flag, implementation derives the link delay metric value from the IS-IS Extended Reachability TLV.
You can configure the IOS XR IS-IS Flex Algo implementation to strictly use the link delay metric value received in the IS-IS ASLA. See
Strict IS-IS ASLA Link Attribute, on page 374
.
Link TE Metric IOS XR IS-IS Flex Algo implementation advertises the link TE metric value using the IS-IS ASLA.
IOS XR IS-IS Flex Algo implementation processes the link TE metric value received in the IS-IS
ASLA.
The link TE metric values advertised can be configured directly under the IGP and are therefore FA-specific.
Otherwise, they will be derived from the link TE metric values configured under SR-TE.
ASLA sub-TLV is supported with non-zero-length or with zero-length Application Identifier Bit
Masks.
If incoming ASLA includes the L-Flag, implementation derives the link TE metric value from the IS-IS Extended Reachability TLV.
See
Algorithm-Specific TE Metric, on page
.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
373
Enabling Segment Routing Flexible Algorithm
Configuring Strict IS-IS ASLA Link Attribute
Link Attribute Transmit Receive
Link Admin
Group/Extended
Admin Group
IOS XR IS-IS Flex Algo implementation advertises the affinity value as both the link admin group (AG)
TLV and the link extended admin group
(EAG) TLV using the IS-IS ASLA when its value falls within the first 32 bits. Otherwise, the affinity value is advertised only as link EAG TLV using the IS-IS ASLA.
The admin group values advertised are configured directly under the IGP and are therefore FA-specific.
IOS XR IS-IS Flex Algo implementation processes the affinity value received as either the link admin group TLV or link extended admin group TLV in the IS-IS ASLA.
ASLA sub-TLV is supported with non-zero-length or with zero-length Application Identifier Bit
Masks.
If incoming ASLA includes the L-Flag, implementation derives the affinity value from the
IS-IS Extended Reachability TLV.
Link SRLG IOS XR IS-IS LFA implementation advertises the link SRLG value in the
IS-IS ASLA.
IOS XR IS-IS LFA implementation processes the link SRLG value received in the IS-IS ASLA.
If incoming ASLA includes the L-Flag, implementation derives the link SRLG value from the IS-IS Extended Reachability TLV.
Configuring Strict IS-IS ASLA Link Attribute
Use the following command to configure the IOS XR IS-IS Flex Algo implementation to strictly use the link delay metric value received in the IS-IS ASLA:
router isis instance-id receive application flex-algo delay app-only
Configuring Flexible Algorithm-Specific TE Metric
Use the following command to configure the Flexible Algorithm-specific TE metric value under IS-IS, where metric_value is from 1 to 16777214:
router isis instance interface type interface-path-id address-family { ipv4 | ipv6 } [ unicast ]
te-metric flex-algo metric_value [ level { 1 | 2 }]
The following example shows how to configure the Flexible Algorithm-specific TE metric value to 50:
Router(config)# router isis 1
Router(config-isis)# interface HundredGigE 0/0/0/2
Router(config-isis-if)# address-family ipv4 unicast
Router(config-isis-if-af)# te-metric flex-algo 50
374
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Enabling Segment Routing Flexible Algorithm
Configuring Flexible Algorithm with Exclude SRLG Constraint
Configuring Flexible Algorithm with Exclude SRLG Constraint
Table 42: Feature History Table
Feature Name
IS-IS Flexible Algorithm:
Exclude-SRLG Constraint
Release Information
Release 7.5.1
Feature Description
This feature allows the Flexible
Algorithm definition to specify
Shared Risk Link Groups (SRLGs) that the operator wants to exclude during the Flex-Algorithm path computation. The ability to exclude the at-risk links ensures that the rest of the links in the network remain unaffected.
This allows the setup of disjoint paths between two or more Flex
Algos by leveraging deployed
SRLG configurations.
This feature allows the Flexible Algorithm definition to specify Shared Risk Link Groups (SRLGs) that the operator wants to exclude during the Flex-Algorithm path computation. A set of links that share a resource whose failure can affect all links in the set constitute a SRLG. An SRLG provides an indication of which links in the network might be at risk from the same failure.
This allows the setup of disjoint paths between two or more Flex Algos by leveraging deployed SRLG configurations. For example, multiple Flex Algos could be defined by excluding all SRLGs except one. Each
FA will prune the links belonging to the excluded SRLGs from its topology on which it computes its paths.
This provides a new alternative to creating disjoint paths with FA, in addition to leveraging FA with link admin group (affinity) constraints.
The Flexible Algorithm definition (FAD) can advertise SRLGs that you want to exclude during the Flexible
Algorithm path computation. The IS-IS Flexible Algorithm Exclude SRLG Sub-TLV (FAESRLG) is used to advertise the exclude rule that is used during the Flexible Algorithm path calculation, as specified in IETF draft https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/
The Flexible Algorithm path computation checks if an “exclude SRLG” rule is part of the FAD. If an “exclude
SRLG” rule exists, it then checks if the link is part of an SRLG that is also part of the “exclude SRLG” rule.
If the link is part of an excluded SRLG, the link is pruned from the path computation.
The figure below shows a topology configured with the following flex algos:
• Flex algo 128: metric IGP and exclude SRLG X constraint
• Flex algo 129: metric IGP and exclude SRLG Y constraint
The horizontal links between nodes 3 and 4 and between 2 and 5 are part of SRLG group X. The diagonal links between nodes 3 and 5 and between 2 and 4 are part of SRLG group Y. As a result, traffic from node 1 to node 6's FA 128 prefix SID (16806) avoids interfaces part of SRLG X. While traffic from node 1 to node
6's FA 129 prefix SID (16906) avoids interfaces part of SRLG Y.
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
375
Enabling Segment Routing Flexible Algorithm
Configuring Flexible Algorithm with Exclude SRLG Constraint
Note See
section in the Configure SR-TE Policies chapter for information about configuring
SR policies with Flex-Algo constraints.
Figure 31: Flex Algo with Exclude SRLG Constraint
Configuration
Use the router isis instance address-family ipv4 unicast advertise application flex-algo link-attributes srlg command to enable the Flexible Algorithm ASLA-specific advertisement of SRLGs.
Use the router isis instance flex-algo algo srlg exclude-any srlg-name . . .
srlg-name command to configure the SRLG constraint which is advertised in the Flexible Algorithm definition (FAD) if the FAD advertisement is enabled under the flex-algo sub-mode. You can specify up to 32 SRLG names.
The SRLG configuration (value and port mapping) is performed under the global SRLG sub-mode. Refer to
MPLS Traffic Engineering Shared Risk Link Groups for more information.
Example
The following example shows how to enable the Flexible Algorithm ASLA-specific advertisement of SRLGs and to exclude SRLG groups from Flexible Algorithm path computation:
RP/0/RP0/CPU0:router(config)# srlg
RP/0/RP0/CPU0:router(config-srlg)# interface HunGigE0/0/0/0
RP/0/RP0/CPU0:router(config-srlg-if)# name groupX
RP/0/RP0/CPU0:router(config-srlg-if)# exit
RP/0/RP0/CPU0:router(config-srlg)# interface TenGigE0/0/0/1
RP/0/RP0/CPU0:router(config-srlg-if)# name groupX
RP/0/RP0/CPU0:router(config-srlg-if)# exit
RP/0/RP0/CPU0:router(config-srlg)# interface HunGigE0/0/1/0
RP/0/RP0/CPU0:router(config-srlg-if)# name groupY
RP/0/RP0/CPU0:router(config-srlg-if)# exit
RP/0/RP0/CPU0:router(config-srlg)# interface TenGigE0/0/1/1
RP/0/RP0/CPU0:router(config-srlg-if)# name groupY
RP/0/RP0/CPU0:router(config-srlg-if)# exit
RP/0/RP0/CPU0:router(config-srlg)# name groupX value 100
376
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Enabling Segment Routing Flexible Algorithm
Example: Configuring IS-IS Flexible Algorithm
RP/0/RP0/CPU0:router(config-srlg)# name groupY value 200
RP/0/RP0/CPU0:router(config-srlg)# exit
RP/0/RP0/CPU0:router(config)# router isis 1
RP/0/RP0/CPU0:router(config-isis)# address-family ipv4 unicast
RP/0/RP0/CPU0:router(config-isis-af)# advertise application flex-algo link-attributes srlg
RP/0/RP0/CPU0:router(config-isis-af)# exit
RP/0/RP0/CPU0:router(config-isis)# flex-algo 128
RP/0/RP0/CPU0:router(config-isis-flex-algo)# advertise-definition
RP/0/RP0/CPU0:router(config-isis-flex-algo)# srlg exclude-any groupX
RP/0/RP0/CPU0:router(config-isis-flex-algo)# exit
RP/0/RP0/CPU0:router(config-isis)# flex-algo 129
RP/0/RP0/CPU0:router(config-isis-flex-algo)# advertise-definition
RP/0/RP0/CPU0:router(config-isis-flex-algo)# srlg exclude-any groupY
RP/0/RP0/CPU0:router(config-isis-flex-algo)# exit
RP/0/RP0/CPU0:router(config-isis)#
Example: Configuring IS-IS Flexible Algorithm
router isis 1 affinity-map red bit-position 65 affinity-map blue bit-position 8 affinity-map green bit-position 201 flex-algo 128 advertise-definition affinity exclude-any red affinity include-any blue
!
flex-algo 129
!
!
affinity exclude-any green address-family ipv4 unicast segment-routing mpls
!
interface Loopback0 address-family ipv4 unicast prefix-sid algorithm 128 index 100 prefix-sid algorithm 129 index 101
!
!
interface GigabitEthernet0/0/0/0
!
affinity flex-algo red interface GigabitEthernet0/0/0/1 affinity flex-algo blue red
!
interface GigabitEthernet0/0/0/2 affinity flex-algo blue
!
Example: Configuring IS-IS Flexible Algorithm
router isis 1 affinity-map red bit-position 65 affinity-map blue bit-position 8 affinity-map green bit-position 201
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
377
Enabling Segment Routing Flexible Algorithm
Example: Configuring OSPF Flexible Algorithm flex-algo 128 advertise-definition affinity exclude-any red
!
affinity include-any blue flex-algo 129
!
affinity exclude-any green
!
address-family ipv4 unicast segment-routing mpls
!
interface Loopback0 address-family ipv4 unicast prefix-sid algorithm 128 index 100 prefix-sid algorithm 129 index 101
!
!
interface GigabitEthernet0/0/0/0 affinity flex-algo red
!
interface GigabitEthernet0/0/0/1 affinity flex-algo blue red
!
interface GigabitEthernet0/0/0/2 affinity flex-algo blue
!
Example: Configuring OSPF Flexible Algorithm
router ospf 1 flex-algo 130 priority 200 affinity exclude-any red
!
blue metric-type delay
!
flex-algo 140 affinity include-all green
!
!
!
affinity include-any red interface Loopback0 prefix-sid index 10 prefix-sid strict-spf index 40 prefix-sid algorithm 128 absolute 16128 prefix-sid algorithm 129 index 129
!
!
prefix-sid algorithm 200 index 20 prefix-sid algorithm 210 index 30 interface GigabitEthernet0/0/0/0 flex-algo affinity color red
378
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Enabling Segment Routing Flexible Algorithm
Example: Traffic Steering to Flexible Algorithm Paths
!
!
color blue affinity-map color red bit-position 10 color blue bit-position 11
!
Example: Traffic Steering to Flexible Algorithm Paths
BGP Routes on PE – Color Based Steering
SR-TE On Demand Next-Hop (ODN) feature can be used to steer the BGP traffic towards the Flexible
Algorithm paths.
The following example configuration shows how to setup BGP steering local policy, assuming two router:
R1 (2.2.2.2) and R2 (4.4.4.4), in the topology.
Configuration on router R1: vrf Test address-family ipv4 unicast import route-target
1:150
!
export route-policy SET_COLOR_RED_HI_BW export route-target
!
1:150
!
!
interface Loopback0 ipv4 address 2.2.2.2 255.255.255.255
!
interface Loopback150 vrf Test ipv4 address 2.2.2.222 255.255.255.255
!
interface TenGigE0/1/0/3/0 description exr1 to cxr1 ipv4 address 10.0.20.2 255.255.255.0
!
extcommunity-set opaque color129-red-igp
129 end-set
!
route-policy PASS pass end-policy
!
route-policy SET_COLOR_RED_HI_BW set extcommunity color color129-red-igp pass end-policy
!
router isis 1 is-type level-2-only net 49.0001.0000.0000.0002.00
log adjacency changes
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
379
Enabling Segment Routing Flexible Algorithm
BGP Routes on PE – Color Based Steering affinity-map RED bit-position 28 flex-algo 128 priority 228
!
address-family ipv4 unicast metric-style wide advertise link attributes router-id 2.2.2.2
segment-routing mpls
!
interface Loopback0 address-family ipv4 unicast prefix-sid index 2 prefix-sid algorithm 128 index 282
!
!
interface TenGigE0/1/0/3/0 point-to-point address-family ipv4 unicast
!
!
!
router bgp 65000 bgp router-id 2.2.2.2
address-family ipv4 unicast
!
address-family vpnv4 unicast retain route-target all
!
neighbor-group RR-services-group remote-as 65000 update-source Loopback0 address-family ipv4 unicast
!
address-family vpnv4 unicast
!
!
neighbor 4.4.4.4
use neighbor-group RR-services-group
!
vrf Test rd auto address-family ipv4 unicast redistribute connected
!
segment-routing traffic-eng logging policy status
!
segment-list sl-cxr1 index 10 mpls label 16294
!
policy pol-foo color 129 end-point ipv4 4.4.4.4
candidate-paths preference 100 explicit segment-list sl-cxr1
!
!
!
!
!
380
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Enabling Segment Routing Flexible Algorithm
BGP Routes on PE – Color Based Steering
!
Configuration on router R2: vrf Test address-family ipv4 unicast import route-target
1:150
!
export route-policy SET_COLOR_RED_HI_BW export route-target
!
1:150
!
!
interface TenGigE0/1/0/1 description cxr1 to exr1 ipv4 address 10.0.20.1 255.255.255.0
!
extcommunity-set opaque color129-red-igp
129 end-set
!
route-policy PASS pass end-policy
!
route-policy SET_COLOR_RED_HI_BW set extcommunity color color129-red-igp pass end-policy
!
router isis 1 is-type level-2-only net 49.0001.0000.0000.0004.00
log adjacency changes affinity-map RED bit-position 28 affinity-map BLUE bit-position 29 affinity-map GREEN bit-position 30 flex-algo 128 priority 228
!
flex-algo 129 priority 229
!
flex-algo 130 priority 230
!
address-family ipv4 unicast metric-style wide advertise link attributes router-id 4.4.4.4
segment-routing mpls
!
interface Loopback0 address-family ipv4 unicast prefix-sid index 4 prefix-sid algorithm 128 index 284 prefix-sid algorithm 129 index 294
!
prefix-sid algorithm 130 index 304
!
interface GigabitEthernet0/0/0/0 point-to-point
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
381
Delay Normalization address-family ipv4 unicast
!
!
interface TenGigE0/1/0/1 point-to-point address-family ipv4 unicast
!
!
router bgp 65000 bgp router-id 4.4.4.4
address-family ipv4 unicast
!
address-family vpnv4 unicast
!
neighbor-group RR-services-group remote-as 65000 update-source Loopback0 address-family ipv4 unicast
!
address-family vpnv4 unicast
!
!
neighbor 1.1.1.1
use neighbor-group RR-services-group
!
neighbor 2.2.2.2
use neighbor-group RR-services-group
!
vrf Test rd auto address-family ipv4 unicast redistribute connected
!
neighbor 25.1.1.2
remote-as 4 address-family ipv4 unicast route-policy PASS in
!
!
route-policy PASS out
!
!
segment-routing
!
end
Delay Normalization
Table 43: Feature History Table
Feature Name
SR-TE Delay Normalization for
OSPF
Release Information
Release 7.3.1
Enabling Segment Routing Flexible Algorithm
Feature Description
This feature extends the current
Delay Normalization feature to support OSPF.
382
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Enabling Segment Routing Flexible Algorithm
Delay Normalization
Performance measurement (PM) measures various link characteristics like packet loss and delay. Such characteristics can be used by IS-IS as a metric for Flexible Algorithm computation. Low latency routing using dynamic delay measurement is one of the primary use cases for Flexible Algorithm technology.
Delay is measured in microseconds. If delay values are taken as measured and used as link metrics during the
IS-IS topology computation, some valid ECMP paths might be unused because of the negligible difference in the link delay.
The Delay Normalization feature computes a normalized delay value and uses the normalized value instead.
This value is advertised and used as a metric during the Flexible Algorithm computation.
The normalization is performed when the delay is received from the delay measurement component. When the next value is received, it is normalized and compared to the previous saved normalized value. If the values are different, then the LSP generation is triggered.
The following formula is used to calculate the normalized value:
• Dm – measured Delay
• Int – configured normalized Interval
• Off – configured normalized Offset (must be less than the normalized interval Int)
• Dn – normalized Delay
• a = Dm / Int (rounded down)
• b = a * Int + Off
If the measured delay (Dm) is less than or equal to b , then the normalized delay (Dn) is equal to b . Otherwise,
Dn is b + Int .
Example
The following example shows a low-latency service. The intent is to avoid high-latency links (1-6, 5-2). Links
1-2 and 5-6 are both low-latency links. The measured latency is not equal, but the difference is insignificant.
We can normalize the measured latency before it is advertised and used by IS-IS. Consider a scenario with the following:
• Interval = 10
• Offset = 3
The measured delays will be normalized as follows:
• Dm = 29 a = 29 / 10 = 2 (2.9, rounded down to 2)
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
383
Delay Normalization
Enabling Segment Routing Flexible Algorithm b = 2 * 10 + 3 = 23
In this case, Dm (29) is greater than b (23); so Dn is equal to b + I (23 + 10) = 33
• Dm = 31 a = 31 / 10 = 3 (3.1, rounded down to 3) b = 3 * 10 + 3 = 33
In this case, Dm (31) is less than b (33); so Dn is b = 33
The link delay between 1-2 and 5-6 is normalized to 33.
Configuration
Delay normalization is disabled by default. To enable and configure delay normalization, use the delay
normalize interval interval [ offset offset ] command.
• interval – The value of the normalize interval in microseconds.
384
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Enabling Segment Routing Flexible Algorithm
Delay Normalization
• offset – The value of the normalized offset in microseconds. This value must be smaller than the value of normalized interval.
IS-IS Configuration router isis 1 interface GigEth 0/0/0/0 delay normalize interval 10 offset 3 address-family ipv4 unicast metric 77
OSPF Configuration router ospf 1 area 0 interface GigabitEthernet0/0/0/0 delay normalize interval 10 offset 3
!
!
!
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
385
Delay Normalization
Enabling Segment Routing Flexible Algorithm
386
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
C H A P T E R
15
Using Segment Routing OAM
Segment Routing Operations, Administration, and Maintenance (OAM) helps service providers to monitor label-switched paths (LSPs) and quickly isolate forwarding problems to assist with fault detection and troubleshooting in the network. The Segment Routing OAM feature provides support for BGP prefix SIDs,
IGP prefix SIDs, and Nil-FEC (forwarding equivalence classes) LSP Ping and Traceroute functionality.
•
MPLS Ping and Traceroute for BGP and IGP Prefix-SID, on page 387
•
Examples: MPLS Ping, Traceroute, and Tree Trace for Prefix-SID, on page 388
•
MPLS LSP Ping and Traceroute Nil FEC Target, on page 390
•
Examples: LSP Ping and Traceroute for Nil_FEC Target , on page 390
•
Segment Routing Ping and Traceroute, on page 392
•
Segment Routing Ping and Traceroute for Flexible Algorithm, on page 397
•
Segment Routing over IPv6 OAM, on page 398
MPLS Ping and Traceroute for BGP and IGP Prefix-SID
MPLS Ping and Traceroute operations for Prefix SID are supported for various BGP and IGP scenarios, for example:
• Within an IS-IS level or OSPF area
• Across IS-IS levels or OSPF areas
• Route redistribution from IS-IS to OSPF and from OSPF to IS-IS
• Anycast Prefix SID
• Combinations of BGP and LDP signaled LSPs
The MPLS LSP Ping feature is used to check the connectivity between ingress Label Switch Routers (LSRs) and egress LSRs along an LSP. MPLS LSP ping uses MPLS echo request and reply messages, similar to
Internet Control Message Protocol (ICMP) echo request and reply messages, to validate an LSP. The destination
IP address of the MPLS echo request packet is different from the address used to select the label stack. The destination IP address is defined as a 127.x.y.z/8 address and it prevents the IP packet from being IP switched to its destination, if the LSP is broken.
The MPLS LSP Traceroute feature is used to isolate the failure point of an LSP. It is used for hop-by-hop fault localization and path tracing. The MPLS LSP Traceroute feature relies on the expiration of the Time to
Live (TTL) value of the packet that carries the echo request. When the MPLS echo request message hits a
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
387
Using Segment Routing OAM
Examples: MPLS Ping, Traceroute, and Tree Trace for Prefix-SID transit node, it checks the TTL value and if it is expired, the packet is passed to the control plane, else the message is forwarded. If the echo message is passed to the control plane, a reply message is generated based on the contents of the request message.
The MPLS LSP Tree Trace (traceroute multipath) operation is also supported for BGP and IGP Prefix SID.
MPLS LSP Tree Trace provides the means to discover all possible equal-cost multipath (ECMP) routing paths of an LSP to reach a destination Prefix SID. It uses multipath data encoded in echo request packets to query for the load-balancing information that may allow the originator to exercise each ECMP. When the packet
TTL expires at the responding node, the node returns the list of downstream paths, as well as the multipath information that can lead the operator to exercise each path in the MPLS echo reply. This operation is performed repeatedly for each hop of each path with increasing TTL values until all ECMP are discovered and validated.
MPLS echo request packets carry Target FEC Stack sub-TLVs. The Target FEC sub-TLVs are used by the responder for FEC validation. The BGP and IGP IPv4 prefix sub-TLV has been added to the Target FEC
Stack sub-TLV. The IGP IPv4 prefix sub-TLV contains the prefix SID, the prefix length, and the protocol
(IS-IS or OSPF). The BGP IPv4 prefix sub-TLV contains the prefix SID and the prefix length.
Examples: MPLS Ping, Traceroute, and Tree Trace for Prefix-SID
These examples use the following topology:
MPLS Ping for Prefix-SID
RP/0/RP0/CPU0:router-arizona# ping mpls ipv4 1.1.1.4/32
Thu Dec 17 01:01:42.301 PST
Sending 5, 100-byte MPLS Echos to 1.1.1.4, timeout is 2 seconds, send interval is 0 msec:
Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
'L' - labeled output interface, 'B' - unlabeled output interface,
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no rx label,
'P' - no rx intf label prot, 'p' - premature termination of LSP,
'R' - transit router, 'I' - unknown upstream index,
'X' - unknown return code, 'x' - return code 0
Type escape sequence to abort.
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 2/2/3 ms
388
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Using Segment Routing OAM
Examples: MPLS Ping, Traceroute, and Tree Trace for Prefix-SID
MPLS Traceroute for Prefix-SID
RP/0/RP0/CPU0:router-arizona# traceroute mpls ipv4 1.1.1.4/32
Thu Dec 17 14:45:05.563 PST
Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
'L' - labeled output interface, 'B' - unlabeled output interface,
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no rx label,
'P' - no rx intf label prot, 'p' - premature termination of LSP,
'R' - transit router, 'I' - unknown upstream index,
'X' - unknown return code, 'x' - return code 0
Type escape sequence to abort.
0 12.12.12.1 MRU 4470 [Labels: 16004 Exp: 0]
L 1 12.12.12.2 MRU 4470 [Labels: 16004 Exp: 0] 3 ms
L 2 23.23.23.3 MRU 4470 [Labels: implicit-null Exp: 0] 3 ms
! 3 34.34.34.4 11 ms
MPLS Tree Trace for Prefix-SID
RP/0/RP0/CPU0:router-arizona# traceroute mpls multipath ipv4 1.1.1.4/32
Thu Dec 17 14:55:46.549 PST
Starting LSP Path Discovery for 1.1.1.4/32
Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
'L' - labeled output interface, 'B' - unlabeled output interface,
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no rx label,
'P' - no rx intf label prot, 'p' - premature termination of LSP,
'R' - transit router, 'I' - unknown upstream index,
'X' - unknown return code, 'x' - return code 0
Type escape sequence to abort.
LL!
Path 0 found, output interface TenGigE0/0/0/0 nexthop 12.12.12.2
source 12.12.12.1 destination 127.0.0.0
L!
Path 1 found, output interface TenGigE0/0/0/0 nexthop 12.12.12.2
source 12.12.12.1 destination 127.0.0.2
LL!
Path 2 found, output interface TenGigE0/0/0/1 nexthop 15.15.15.5
source 15.15.15.1 destination 127.0.0.1
L!
Path 3 found, output interface TenGigE0/0/0/1 nexthop 15.15.15.5
source 15.15.15.1 destination 127.0.0.0
Paths (found/broken/unexplored) (4/0/0)
Echo Request (sent/fail) (10/0)
Echo Reply (received/timeout) (10/0)
Total Time Elapsed 53 ms
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
389
Using Segment Routing OAM
MPLS LSP Ping and Traceroute Nil FEC Target
MPLS LSP Ping and Traceroute Nil FEC Target
The Nil-FEC LSP ping and traceroute operations are extensions of regular MPLS ping and traceroute.
Nil-FEC LSP Ping/Traceroute functionality supports segment routing and MPLS Static. It also acts as an additional diagnostic tool for all other LSP types. This feature allows operators to provide the ability to freely test any label stack by allowing them to specify the following:
• label stack
• outgoing interface
• nexthop address
In the case of segment routing, each segment nodal label and adjacency label along the routing path is put into the label stack of an echo request message from the initiator Label Switch Router (LSR); MPLS data plane forwards this packet to the label stack target, and the label stack target sends the echo message back.
The following table shows the syntax for the ping and traceroute commands.
Table 44: LSP Ping and Traceroute Nil FEC Commands
Command Syntax ping mpls nil-fec labels { label [ ,label ]} [ output { interface tx-interface } [ nexthop nexthop-ip-addr ]] traceroute mpls nil-fec labels { label [ ,label ]} [ output { interface tx-interface } [ nexthop nexthop-ip-addr ]]
Examples: LSP Ping and Traceroute for Nil_FEC Target
These examples use the following topology:
Node loopback IP address: 172.18.1.3
172.18.1.4
172.18.1.5
172.18.1.7
Node label: 16004 16005 16007
Nodes: Arizona ---- Utah ------- Wyoming ---- Texas
Interface:
Interface IP address:
GigabitEthernet0/0/0/1 GigabitEthernet0/0/0/1
10.1.1.3
10.1.1.4
RP/0/RP0/CPU0:router-utah# show mpls forwarding
Tue Jul 5 13:44:31.999 EDT
Local Outgoing
Label Label
Prefix or ID
Outgoing
Interface
Next Hop Bytes
Switched
------ ----------- ------------------ ------------ --------------- ------------
16004 Pop
Pop
No ID
No ID
Gi0/0/0/1
Gi0/0/0/2
10.1.1.4
10.1.2.2
1392
0
16005 16005
16005
16007 16007
16007
24000 Pop
24001 Pop
No ID
No ID
No ID
No ID
SR Adj (idx 0)
SR Adj (idx 2)
Gi0/0/0/0
Gi0/0/0/1
Gi0/0/0/0
Gi0/0/0/1
Gi0/0/0/0
Gi0/0/0/0
10.1.1.4
10.1.2.2
10.1.1.4
10.1.2.2
10.1.1.4
10.1.1.4
0
0
4752
0
0
0
390
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Using Segment Routing OAM
Examples: LSP Ping and Traceroute for Nil_FEC Target
24002 Pop
24003 Pop
24004 Pop
24005 Pop
24006 Pop
24007 Pop
24008 Pop
SR Adj (idx 0)
SR Adj (idx 2)
No ID
No ID
No ID
No ID
No ID
Gi0/0/0/1
Gi0/0/0/1 tt10 tt11 tt12 tt13 tt30
10.1.2.2
10.1.2.2
point2point point2point point2point point2point point2point
0
0
0
0
0
0
0
Ping Nil FEC Target
RP/0/RP0/CPU0:router-arizona# ping mpls nil-fec labels 16005,16007 output interface
GigabitEthernet 0/0/0/1 nexthop 10.1.1.4 repeat 1
Sending 1, 72-byte MPLS Echos with Nil FEC labels 16005,16007, timeout is 2 seconds, send interval is 0 msec:
Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
'L' - labeled output interface, 'B' - unlabeled output interface,
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry,
'P' - no rx intf label prot, 'p' - premature termination of LSP,
'R' - transit router, 'I' - unknown upstream index,
'd' - see DDMAP for return code,
'X' - unknown return code, 'x' - return code 0
Type escape sequence to abort.
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 1/1/1 ms
Total Time Elapsed 0 ms
Traceroute Nil FEC Target
RP/0/RP0/CPU0:router-arizona# traceroute mpls nil-fec labels 16005,16007 output interface
GigabitEthernet 0/0/0/1 nexthop 10.1.1.4
Tracing MPLS Label Switched Path with Nil FEC labels 16005,16007, timeout is 2 seconds
Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
'L' - labeled output interface, 'B' - unlabeled output interface,
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry,
'P' - no rx intf label prot, 'p' - premature termination of LSP,
'R' - transit router, 'I' - unknown upstream index,
'd' - see DDMAP for return code,
'X' - unknown return code, 'x' - return code 0
Type escape sequence to abort.
0 10.1.1.3 MRU 1500 [Labels: 16005/16007/explicit-null Exp: 0/0/0]
L 1 10.1.1.4 MRU 1500 [Labels: implicit-null/16007/explicit-null Exp: 0/0/0] 1 ms
L 2 10.1.1.5 MRU 1500 [Labels: implicit-null/explicit-null Exp: 0/0] 1 ms
! 3 10.1.1.7 1 ms
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
391
Using Segment Routing OAM
Segment Routing Ping and Traceroute
Segment Routing Ping and Traceroute
Table 45: Feature History Table
Feature Name Release
Information
Feature Description
SR OAM for SR Policy
(Policy Name / Binding
SID / Custom label stack)
Release
7.3.1
This feature extends SR OAM ping and traceroute function for an SR policy (or binding SID)-LSP end-point combination.
This addresses the limitations of the Nil-FEC LSP Ping and Traceroute function which cannot perform a ping operation to a segment list that is not associated with an installed SR policy. Also, it cannot validate egress device-specific SR policies.
Segment Routing Ping
The MPLS LSP ping feature is used to check the connectivity between ingress and egress of LSP. MPLS LSP ping uses MPLS echo request and reply messages, similar to Internet Control Message Protocol (ICMP) echo request and reply messages, to validate an LSP. Segment routing ping is an extension of the MPLS LSP ping to perform the connectivity verification on the segment routing control plane.
Note Segment routing ping can only be used when the originating device is running segment routing.
You can initiate the segment routing ping operation only when Segment Routing control plane is available at the originator, even if it is not preferred. This allows you to validate the SR path before directing traffic over the path. Segment Routing ping can use either generic FEC type or SR control-plane FEC type (SR-OSPF,
SR-ISIS). In mixed networks, where some devices are running MPLS control plane (for example, LDP) or do not understand SR FEC, generic FEC type allows the device to successfully process and respond to the echo request. By default, generic FEC type is used in the target FEC stack of segment routing ping echo request. Generic FEC is not coupled to a particular control plane; it allows path verification when the advertising protocol is unknown or might change during the path of the echo request. If you need to specify the target
FEC, you can select the FEC type as OSPF, IS-IS, or BGP. This ensures that only devices that are running segment routing control plane, and can therefore understand the segment routing IGP FEC, respond to the echo request.
Configuration Examples
These examples show how to use segment routing ping to test the connectivity of a segment routing control plane. In the first example, FEC type is not specified. You can also specify the FEC type as shown in the other examples.
RP/0/RP0/CPU0:router# ping sr-mpls 10.1.1.2/32
Sending 5, 100-byte MPLS Echos to 10.1.1.2/32, timeout is 2 seconds, send interval is 0 msec:
Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
'L' - labeled output interface, 'B' - unlabeled output interface,
392
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Using Segment Routing OAM
Segment Routing Ping
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no rx label,
'P' - no rx intf label prot, 'p' - premature termination of LSP,
'R' - transit router, 'I' - unknown upstream index,
'X' - unknown return code, 'x' - return code 0
Type escape sequence to abort.
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/5 ms
RP/0/RP0/CPU0:router# ping sr-mpls 10.1.1.2/32 fec-type generic
Sending 5, 100-byte MPLS Echos to 10.1.1.2/32, timeout is 2 seconds, send interval is 0 msec:
Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
'L' - labeled output interface, 'B' - unlabeled output interface,
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no rx label,
'P' - no rx intf label prot, 'p' - premature termination of LSP,
'R' - transit router, 'I' - unknown upstream index,
'X' - unknown return code, 'x' - return code 0
Type escape sequence to abort.
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
RP/0/RP0/CPU0:router# ping sr-mpls 10.1.1.2/32 fec-type igp ospf
Sending 5, 100-byte MPLS Echos to 10.1.1.2/32, timeout is 2 seconds, send interval is 0 msec:
Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
'L' - labeled output interface, 'B' - unlabeled output interface,
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no rx label,
'P' - no rx intf label prot, 'p' - premature termination of LSP,
'R' - transit router, 'I' - unknown upstream index,
'X' - unknown return code, 'x' - return code 0
Type escape sequence to abort.
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
RP/0/RP0/CPU0:router# ping sr-mpls 10.1.1.2/32 fec-type igp isis
Sending 5, 100-byte MPLS Echos to 10.1.1.2/32, timeout is 2 seconds, send interval is 0 msec:
Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
'L' - labeled output interface, 'B' - unlabeled output interface,
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no rx label,
'P' - no rx intf label prot, 'p' - premature termination of LSP,
'R' - transit router, 'I' - unknown upstream index,
'X' - unknown return code, 'x' - return code 0
Type escape sequence to abort.
!!!!!
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
393
Using Segment Routing OAM
Segment Routing Traceroute
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
RP/0/RP0/CPU0:router# ping sr-mpls 10.1.1.2/32 fec-type bgp
Sending 5, 100-byte MPLS Echos to 10.1.1.2/32, timeout is 2 seconds, send interval is 0 msec:
Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
'L' - labeled output interface, 'B' - unlabeled output interface,
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no rx label,
'P' - no rx intf label prot, 'p' - premature termination of LSP,
'R' - transit router, 'I' - unknown upstream index,
'X' - unknown return code, 'x' - return code 0
Type escape sequence to abort.
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
Ping for SR Policy
You can perform the ping operation for an SR policy (or binding SID), and LSP end-point combination. Use the ping command’s policy name lsp-end-point and policy binding-sid lsp-end-point options to perform this task. You can instantiate the policy through the CLI, Netconf, PCEP or BGP-TE process.
IPv6 policies are not supported for SR OAM function.
Note As a prerequisite, you must enable the MPLS OAM function.
Router(config)# mpls oam
Router(config)# commit
Router# ping sr-mpls policy name srte_c_4_ep_10.0.0.1 lsp-end-point 209.165.201.1
Router# ping sr-mpls policy binding-sid 1000 lsp-end-point 209.165.201.1
Segment Routing Traceroute
The MPLS LSP traceroute is used to isolate the failure point of an LSP. It is used for hop-by-hop fault localization and path tracing. The MPLS LSP traceroute feature relies on the expiration of the Time to Live
(TTL) value of the packet that carries the echo request. When the MPLS echo request message hits a transit node, it checks the TTL value and if it is expired, the packet is passed to the control plane, else the message is forwarded. If the echo message is passed to the control plane, a reply message is generated based on the contents of the request message. Segment routing traceroute feature extends the MPLS LSP traceroute functionality to segment routing networks.
Similar to segment routing ping, you can initiate the segment routing traceroute operation only when Segment
Routing control plane is available at the originator, even if it is not preferred. Segment Routing traceroute can use either generic FEC type or SR control-plane FEC type (SR-OSPF, SR-ISIS). By default, generic FEC type is used in the target FEC stack of segment routing traceroute echo request. If you need to specify the target FEC, you can select the FEC type as OSPF, IS-IS, or BGP. This ensures that only devices that are running segment routing control plane, and can therefore understand the segment routing IGP FEC, respond to the echo request.
394
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Using Segment Routing OAM
Segment Routing Traceroute
The existence of load balancing at routers in an MPLS network provides alternate paths for carrying MPLS traffic to a target router. The multipath segment routing traceroute feature provides a means to discover all possible paths of an LSP between the ingress and egress routers.
Configuration Examples
These examples show how to use segment routing traceroute to trace the LSP for a specified IPv4 prefix SID address. In the first example, FEC type is not specified. You can also specify the FEC type as shown in the other examples.
RP/0/RP0/CPU0:router# traceroute sr-mpls 10.1.1.2/32
Tracing MPLS Label Switched Path to 10.1.1.2/32, timeout is 2 seconds
Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
'L' - labeled output interface, 'B' - unlabeled output interface,
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no rx label,
'P' - no rx intf label prot, 'p' - premature termination of LSP,
'R' - transit router, 'I' - unknown upstream index,
'X' - unknown return code, 'x' - return code 0
Type escape sequence to abort.
0 10.12.12.1 MRU 1500 [Labels: implicit-null Exp: 0]
! 1 10.12.12.2 3 ms
RP/0/RP0/CPU0:router# traceroute sr-mpls 10.1.1.2/32 fec-type generic
Tracing MPLS Label Switched Path to 10.1.1.2/32, timeout is 2 seconds
Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
'L' - labeled output interface, 'B' - unlabeled output interface,
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no rx label,
'P' - no rx intf label prot, 'p' - premature termination of LSP,
'R' - transit router, 'I' - unknown upstream index,
'X' - unknown return code, 'x' - return code 0
Type escape sequence to abort.
0 10.12.12.1 MRU 1500 [Labels: implicit-null Exp: 0]
! 1 10.12.12.2 2 ms
RP/0/RP0/CPU0:router# traceroute sr-mpls 10.1.1.2/32 fec-type igp ospf
Tracing MPLS Label Switched Path to 10.1.1.2/32, timeout is 2 seconds
Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
'L' - labeled output interface, 'B' - unlabeled output interface,
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no rx label,
'P' - no rx intf label prot, 'p' - premature termination of LSP,
'R' - transit router, 'I' - unknown upstream index,
'X' - unknown return code, 'x' - return code 0
Type escape sequence to abort.
0 10.12.12.1 MRU 1500 [Labels: implicit-null Exp: 0]
! 1 10.12.12.2 2 ms
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
395
Using Segment Routing OAM
Segment Routing Traceroute
RP/0/RP0/CPU0:router# traceroute sr-mpls 10.1.1.2/32 fec-type igp isis
Tracing MPLS Label Switched Path to 10.1.1.2/32, timeout is 2 seconds
Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
'L' - labeled output interface, 'B' - unlabeled output interface,
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no rx label,
'P' - no rx intf label prot, 'p' - premature termination of LSP,
'R' - transit router, 'I' - unknown upstream index,
'X' - unknown return code, 'x' - return code 0
Type escape sequence to abort.
0 10.12.12.1 MRU 1500 [Labels: implicit-null Exp: 0]
! 1 10.12.12.2 2 ms
RP/0/RP0/CPU0:router# traceroute sr-mpls 10.1.1.2/32 fec-type bgp
Tracing MPLS Label Switched Path to 10.1.1.2/32, timeout is 2 seconds
Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
'L' - labeled output interface, 'B' - unlabeled output interface,
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no rx label,
'P' - no rx intf label prot, 'p' - premature termination of LSP,
'R' - transit router, 'I' - unknown upstream index,
'X' - unknown return code, 'x' - return code 0
Type escape sequence to abort.
0 10.12.12.1 MRU 1500 [Labels: implicit-null/implicit-null Exp: 0/0]
! 1 10.12.12.2 2 ms
This example shows how to use multipath traceroute to discover all the possible paths for a IPv4 prefix SID.
RP/0/RP0/CPU0:router# traceroute sr-mpls multipath 10.1.1.2/32
Starting LSP Path Discovery for 10.1.1.2/32
Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
'L' - labeled output interface, 'B' - unlabeled output interface,
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no rx label,
'P' - no rx intf label prot, 'p' - premature termination of LSP,
'R' - transit router, 'I' - unknown upstream index,
'X' - unknown return code, 'x' - return code 0
Type escape sequence to abort.
!
Path 0 found, output interface GigabitEthernet0/0/0/2 nexthop 10.13.13.2
source 10.13.13.1 destination 127.0.0.0
!
Path 1 found, output interface Bundle-Ether1 nexthop 10.12.12.2
source 10.12.12.1 destination 127.0.0.0
Paths (found/broken/unexplored) (2/0/0)
Echo Request (sent/fail) (2/0)
396
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Using Segment Routing OAM
Segment Routing Ping and Traceroute for Flexible Algorithm
Echo Reply (received/timeout) (2/0)
Total Time Elapsed 14 ms
Traceroute for SR Policy
You can perform the traceroute operation for an SR policy (or binding SID), and LSP end-point combination.
Use the traceroute command’s policy name lsp-end-point and policy binding-sid lsp-end-point options to perform this task. You can instantiate the policy through the CLI, Netconf, PCEP or BGP-TE process.
IPv6 policies are not supported for SR OAM function.
Note As a prerequisite, you must enable the MPLS OAM function.
Router(config)# mpls oam
Router(config)# commit
Router# traceroute sr-mpls policy name srte_c_4_ep_10.0.0.1 lsp-end-point 209.165.201.1
Router# traceroute sr-mpls policy binding-sid 1000 lsp-end-point 209.165.201.1
Segment Routing Ping and Traceroute for Flexible Algorithm
Table 46: Feature History Table
Flexible Algorithm validation method is based on segment identifier (SID) label and label switched path (LSP) destination, instead of being based on IP address. The assigner is validated against the topology prefix information provided by SR-PCE database. If the assigner is valid, then the label given is also validated against the SR-PCE database. On the egress side, the destination label is contained in a new SR Label sub-TLV. This label is verified against a SID list provided by SR-PCE.
Note Observe the following guidelines and restrictions:
• All routers within an area must share the same Flexible Algorithm definition for a Flexible Algorithm to be valid.
• All routers within the domain must be configured with the same SRGB range of values.
• BGP-LS must be enabled.
• Only prefix SIDs and Flexible Algorithm SIDs are supported.
• Only single label stack is supported.
Segment Routing Ping for Flexible Algorithm
Router# ping sr-mpls labels 16131 lsp-end-point 1.1.1.5
Fri Dec 13 19:26:29.517 IST
Sending 5, 100-byte MPLS Echos with SR Label FEC with lsp end point 1.1.1.5, SID Label(s)
[16131], timeout is 2 seconds, send interval is 0 msec:
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
397
Using Segment Routing OAM
Segment Routing Traceroute for Flexible Algorithm
Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
'L' - labeled output interface, 'B' - unlabeled output interface,
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no rx label,
'P' - no rx intf label prot, 'p' - premature termination of LSP,
'R' - transit router, 'I' - unknown upstream index,
'X' - unknown return code, 'x' - return code 0
Type escape sequence to abort.
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/6 ms
Segment Routing Traceroute for Flexible Algorithm
Router# traceroute sr-mpls labels 16130 lsp-end-point 1.1.1.5
Fri Dec 13 19:26:59.368 IST
Tracing MPLS Label Switched Path to SR Label FEC with lsp end point 1.1.1.5, SID Label(s)
[16130], timeout is 2 seconds
Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
'L' - labeled output interface, 'B' - unlabeled output interface,
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no rx label,
'P' - no rx intf label prot, 'p' - premature termination of LSP,
'R' - transit router, 'I' - unknown upstream index,
'X' - unknown return code, 'x' - return code 0
Type escape sequence to abort.
0 13.13.13.1 MRU 1500 [Labels: 16130 Exp: 0]
L 1 13.13.13.3 MRU 1500 [Labels: 16130 Exp: 0] 5 ms
L 2 16.16.16.4 MRU 1500 [Labels: implicit-null Exp: 0] 4 ms
! 3 18.18.18.5 4 ms
Segment Routing over IPv6 OAM
Segment Routing over IPv6 data plane (SRv6) implementation adds a new type of routing extension header.
Hence, the existing ICMPv6 mechanisms including ping and traceroute can be used in the SRv6 network.
There is no change in the way ping and traceroute operations work for IPv6- or SRv6-capable nodes in an
SRv6 network.
Restrictions and Usage Guidelines
The following restriction applies for SRv6 OAM:
• Ping to an SRv6 SID is not supported.
Examples: SRv6 OAM
The following example shows using ping in an SRv6 network.
RP/0/RP0/CPU0:Router# ping ipv6 2001::33:33:33:33
Mon Sep 17 20:04:10.068 UTC
398
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Using Segment Routing OAM
Segment Routing over IPv6 OAM
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001::33:33:33:33, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms
The following example shows using traceroute in an SRv6 network.
RP/0/RP0/CPU0:Router# traceroute ipv6 2001::33:33:33:33 probe 1 timeout 0 srv6
Fri Sep 14 15:59:25.170 UTC
Type escape sequence to abort.
Tracing the route to 2001::33:33:33:33
1 2001::22:22:22:22[IP tunnel: DA=cafe:0:0:a4:1:::: SRH =(2001::33:33:33:33 ,SL=1)] 2 msec
2 2001::2:2:2:2[IP tunnel: DA=cafe:0:0:a4:1:::: SRH =(2001::33:33:33:33 ,SL=1)] 2 msec
3 2001::44:44:44:44 2 msec
4 2001::33:33:33:33 3 msec
The following example shows using traceroute in an SRv6 network without an SRH.
RP/0/RSP1/CPU0:Router# traceroute ipv6 2001::44:44:44:44 srv6
Wed Jan 16 14:35:27.511 UTC
Type escape sequence to abort.
Tracing the route to 2001::44:44:44:44
1 2001::2:2:2:2 3 msec 2 msec 2 msec
2 2001::44:44:44:44 3 msec 3 msec 3 msec
The following example shows using ping for a specified IP address in the VRF.
RP/0/RP0/CPU0:Router# ping 10.15.15.1 vrf red
Mon Sep 17 20:07:10.085 UTC
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.15.15.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
The following example shows using traceroute for a specified IP address in the VRF.
RP/0/RP0/CPU0:Router# traceroute 10.15.15.1 vrf red
Mon Sep 17 20:07:18.478 UTC
Type escape sequence to abort.
Tracing the route to 10.15.15.1
1 10.15.15.1 3 msec 2 msec 2 msec
The following example shows using traceroute for CE1 (4.4.4.5) to CE2 (5.5.5.5) in the VRF:
RP/0/RP0/CPU0:Router# traceroute 5.5.5.5 vrf a
Wed Jan 16 15:08:46.264 UTC
Type escape sequence to abort.
Tracing the route to 5.5.5.5
1 14.14.14.1 5 msec 1 msec 1 msec
2 15.15.15.1 3 msec 2 msec 2 msec
3 15.15.15.2 2 msec * 3 msec
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
399
Segment Routing over IPv6 OAM
Using Segment Routing OAM
400
Segment Routing Configuration Guide for Cisco NCS 560 Series Routers, IOS XR Release 7.6.x
Lataa
Julkinen linkki päivitetty
Chattisi julkinen linkki on päivitetty. You may view and manage your chat links after registration here.
Dokumentin julkinen linkki
Mainos