See the Cisco IOS XE Denali 16.2 Migration Guide for Access and Edge Routers document for the full list of supported platforms for the various Cisco IOS XE 16 releases and also the migration strategy for the supported products. This document contains key information and steps that will help ensure a successful migration from extant Cisco IOS XE 3.17S releases to the Cisco IOS XE 16.2 release. It also provides key software differences between this release and the Cisco IOS XE Release 3.17S that must be kept in mind during migration. It is critical that you read the information before you begin migration to ensure that you have completed all of the prerequisites and to make sure that you understand the migration process.

Note

The Feature Information table in the technology configuration guide mentions when a feature was introduced. It may or may not mention when other platforms were supported for that feature. To determine if a particular feature is supported on your platform, look at the technology configuration guides posted on your product landing page. When a technology configuration guide is displayed on your product landing page, it indicates that the feature is supported on that platform.

Segment Routing Configuration Guide

Read Me First

C H A P T E R

Introduction to Segment Routing

Segment Routing (SR) is a flexible, scalable way of doing source routing.

•

Overview of Segment Routing, page 3

•

How Segment Routing Works, page 4

•

Examples for Segment Routing, page 5

•

Benefits of Segment Routing, page 6

•

Segment Routing Global Block, page 8

•

Additional References for Segment Routing, page 10

Overview of Segment Routing

Segment Routing (SR) is a flexible, scalable way of doing source routing. The source chooses a path and encodes it in the packet header as an ordered list of segments. Segments are identifier for any type of instruction.

Each segment is identified by the segment ID (SID) consisting of a flat unsigned 32-bit integer. Segment instruction can be:

• Go to node N using the shortest path

• Go to node N over the shortest path to node M and then follow links Layer 1, Layer 2, and Layer 3

• Apply service S

With segment routing, the network no longer needs to maintain a per-application and per-flow state. Instead, it obeys the forwarding instructions provided in the packet.

Segment Routing relies on a small number of extensions to Cisco Intermediate System-to-Intermediate System

(IS-IS) and Open Shortest Path First (OSPF) protocols. It can operate with an MPLS (Multiprotocol Label

Switching) or an IPv6 data plane, and it 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 can be directly applied to the Multiprotocol Label Switching (MPLS) architecture with no change in the forwarding plane. Segment routing utilizes the network bandwidth more effectively than traditional MPLS networks and offers lower latency. A segment is encoded as an MPLS label. An ordered

Segment Routing Configuration Guide

Introduction to Segment Routing

How Segment Routing Works

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.

Segment routing can be applied to the IPv6 architecture with a new type of routing extension header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing extension header. The segment to process is indicated by a pointer in the routing extension header. The pointer is incremented, after the completion of a segment.

Segment Routing provides automatic traffic protection without any topological restrictions. The network protects traffic against link and node failures without requiring additional signaling in the network. Existing

IP fast re-route (FRR) technology, in combination with the explicit routing capabilities in Segment Routing guarantees full protection coverage with optimum backup paths. Traffic protection does not impose any additional signaling requirements.

How Segment Routing Works

A router in a Segment Routing network is capable of selecting any path to forward traffic, whether it is explicit or Interior Gateway Protocol (IGP) shortest path. Segments represent subpaths that a router can combine to form a complete route to a network destination. Each segment has an identifier (Segment Identifier) that is distributed throughout the network using new IGP extensions. The extensions are equally applicable to IPv4 and IPv6 control planes. Unlike the case for traditional MPLS networks, routers in a Segment Router network do not require Label Distribution Protocol (LDP) and Resource Reservation Protocol - Traffic Engineering

(RSVP-TE) to allocate or signal their segment identifiers and program their forwarding information.

Each router (node) and each link (adjacency) has an associated segment identifier (SID). Node segment identifiers are globally unique and represent the shortest path to a router as determined by the IGP. The network administrator allocates a node ID to each router from a reserved block. On the other hand, an adjacency segment ID is locally significant and represents a specific adjacency, such as egress interface, to a neighboring router. Routers automatically generate adjacency identifiers outside of the reserved block of node IDs. In an

MPLS network, a segment identifier is encoded as an MPLS label stack entry. Segment IDs direct the data along a specified path. There are two kinds of segment IDS:

• Prefix SID— A segment ID that contains an IP address prefix calculated by an IGP in the service provider core network. Prefix SIDs are globally unique. A node SID is a special form of prefix SID that contains the loopback address of the node as the prefix. It is advertised as an index into the node specific

SR Global Block or SRGB.

• Adjacency SID— A segment ID that contains an advertising router’s adjacency to a neighbor. An adjacency SID is a link between two routers. Since the adjacency SID is relative to a specific router, it is locally unique.

Segment Routing Configuration Guide

Introduction to Segment Routing

Examples for Segment Routing

Examples for Segment Routing

The following figure illustrates an MPLS network with five routers using Segment Routing, IS-IS, a label range of 100 to 199 for node IDs, and 200 and higher for adjacency IDs. IS-IS would distribute IP prefix reachability alongside segment ID (the MPLS label) across the network.

Figure 1: An MPLS Network with Five Routers Using Segment Routing

In the previous example, any router sending traffic to router E would push label 103 (router E node segment identifier) to forward traffic using the IS-IS shortest path. The MPLS label-swapping operation at each hop preserves label 103 until the packet arrives at E (Figure 2). On the other hand, adjacency segments behave differently. For example, if a packet arrives at Router D with a top-of-stack MPLS label of 203 (D-to-E adjacency segment identifier), Router D would pop the label and forward the traffic to Router E.

Figure 2: MPLS Label-Swapping Operation

Segment identifiers can be combined as an ordered list to perform traffic engineering. A segment list can contain several adjacency segments, several node segments, or a combination of both depending on the forwarding requirements. In the previous example, Router A could alternatively push label stack (104, 203) to reach Router E using the shortest path and all applicable ECMPs to Router D and then through an explicit interface onto the destination (Figure 3). Router A does not need to signal the new path, and the state information

Segment Routing Configuration Guide

Introduction to Segment Routing

Benefits of Segment Routing

remains constant in the network. Router A ultimately enforces a forwarding policy that determines which flows destined to router E are switched through a particular path.

Figure 3: Router E Destination Path

Benefits of Segment Routing

• Ready for SDN— Segment Routing is a compelling architecture conceived to embrace Software-Defined

Network (SDN) and is the foundation for Application Engineered Routing (AER). It strikes a balance between network-based distributed intelligence, such as automatic link and node protection, and controller-based centralized intelligence, such as traffic optimization. It can provide strict network performance guarantees, efficient use of network resources, and very high scalability for application-based transactions. The network uses minimal state information to meet these requirements. Segment routing can be easily integrated with a controller-based SDN architecture. Below figure illustrates a sample SDN scenario where the controller performs centralized optimization, including bandwidth admission control.

In this scenario, the controller has a complete picture of the network topology and flows. A router can request a path to a destination with certain characteristics, for example, delay, bandwidth, diversity. The controller computes an optimal path and returns the corresponding segment list, such as an MPLS label

Segment Routing Configuration Guide

Introduction to Segment Routing

Benefits of Segment Routing

stack, to the requesting router. At that point, the router can inject traffic with the segment list without any additional signaling in the network.

Figure 4: SDN Controller

• In addition, segment lists allow complete network virtualization without adding any application state to the network. The state is encoded in the packet as a list of segments. Because the network only maintains segment state, it can support a large number - and a higher frequency - of transaction-based application requests without creating any burden on the network.

• Simplified—

◦When applied to the MPLS data plane, Segment Routing offers the ability to tunnel MPLS services

(VPN, VPLS, and VPWS) from an ingress provider edge to an egress provider edge without any other protocol than an IGP (ISIS or OSPF).

◦Simpler operation without separate protocols for label distribution (for example, no LDP or RSVP).

◦No complex LDP or IGP synchronization to troubleshoot.

◦Better utilization of installed infrastructure, for lower capital expenditures (CapEx), with

ECMP-aware shortest path forwarding (using node segment IDs).

• Supports Fast Reroute (FRR)— Deliver automated FRR for any topology. In case of link or node failures in a network, MPLS uses the FRR mechanism for convergence. With segment routing, the convergence time is sub-50-msec.

• Large-scale Data Center-

◦Segment Routing simplifies MPLS-enabled data center designs using Border Gateway Protocol

(BGP) RFC 3107 - IPv4 labeled unicast among Top-of-the-Rack/Leaf/Spine switches.

◦BGP distributes the node segment ID, equivalent to IGP node SID.

◦Any node within the topology allocates the same BGP segment for the same switch.

◦The same benefits are provided as for IGP node SID: ECMP and automated FRR (BGP PIC(Prefix

Independent Convergence).

◦This is a building block for traffic engineering - SR TE data center fabric optimization.

• Scalable—

Segment Routing Configuration Guide

Introduction to Segment Routing

Segment Routing Global Block

◦ Avoid thousands of labels in LDP database.

◦Avoid thousands of MPLS Traffic Engineering LSP's in the network.

◦Avoid thousands of tunnels to configure.

• Dual-plane Networks—

◦Segment Routing provides a simple solution for disjointness enforcement within a so-called

“dual-plane” network, where the route to an edge destination from a given plane stays within the plane unless the plane is partitioned.

◦An additional SID “anycast” segment ID allows the expression of macro policies such as: "Flow

1 injected in node A toward node Z must go via plane 1" and "Flow 2 injected in node A towards node Z must go via plane 2."

• Centralized Traffic Engineering—

◦Controllers and orchestration platforms can interact with Segment Routing traffic engineering for centralized optimization, such as WAN optimization.

◦Network changes such as congestion can trigger an application to optimize (recompute) the placement of segment routing traffic engineering tunnels.

◦Segment Routing tunnels are dynamically programmed onto the network from an orchestrator using southbound protocols like PCE.

◦Agile network programming is possible since Segment Routing tunnels do not require signaling and per-flow state at midpoints and tail end routers.

• Egress Peering Traffic Engineering (EPE)—

◦Segment Routing allows centralized EPE.

◦A controller instructs an ingress provider edge and content source to use a specific egress provider edge and specific external interface to reach a destination.

◦BGP “peering” segment IDs are used to express source-routed inter-domain paths.

◦Controllers learn BGP peering SIDs and the external topology of the egress border router through

BGP Link Status (BGP-LS) EPE routes.

◦Controllers program ingress points with a desired path.

• Plug-and-Play deployment— Segment routing tunnels are interoperable with existing MPLS control and data planes and can be implemented in an existing deployment.

Segment Routing Global Block

Segment Routing Global Block (SRGB) is the range of labels reserved for segment routing. SRGB is local property of an segment routing node. In MPLS, architecture, SRGB is the set of local labels reserved for global segments. In segment routing, each node can be configured with a different SRGB value and hence the absolute SID value associated to an IGP Prefix Segment can change from node to node.

Segment Routing Configuration Guide

Introduction to Segment Routing

Segment Routing Global Block

The SRGB default value is 16000 to 23999. The SRGB can be configured as follows:

Device(config)# router isis 1

Device(config-isis)#segment-routing global-block 45000 55000

The SRGB label value is calculated as follows:

• If the platform supports 1000000 labels or more, the SRGB value is from 900000 to 900000 + 2^16.

• If the platform supports less than 1000000 labels, the SRGB value is the last 2^16 labels.

Restrictions:

• The SRGB size cannot be more than 2^16.

• The SRGB upper bound cannot exceed the platform capability.

• The SRGB cannot be configured to be the same value as the default SRGB. So SRGB cannot be configured for 16000 to 23999.

Segment Routing Global Block

This chapter explains the concept of creating a block of labels reserved for a router using segment routing.

This block of reserved labels is known as the Segment Routing Global Block (SRGB).

Adjacency Segment Identifiers

The Adjacency Segment Identifier (adj-SID) is a local label that points to a specific interface and a next hop out of that interface. No specific configuration is required to enable adj-SIDs. Once segment routing is enabled over IS-IS for an address-family, for any interface that IS-IS runs over, the address-family automatically allocates an adj-SID towards every neighbor out of that interface.

Note

Only IPV4 address-family supports allocating adj-SIDs.

Prefix Segment Identifiers

A prefix segment identifier (SID) identifies a segment routing tunnel leading to the destination represented by a prefix. The maximum prefix SID value is 2^16 - 1.

A prefix SID is allocated from the Segment Routing Global Block (SRGB). The prefix SID value translates to a local MPLS label, whose value is calculated as below:

• If the platform supports 1000000 labels or more, then the MPLS label corresponding to the prefix SID value is 900000 + sid-value.

• If the platform supports less than 1000000 labels, then the MPLS label corresponding to the prefix SID value is maximum-supported-label-value - 2^16 + sid-value.

When a prefix SID value x is configured, the prefix SID translates to a label value equivalent to x + lower boundary of SRGB. For example, in the platform supporting 1000000 MPLS labels or more if the default

Segment Routing Configuration Guide

Introduction to Segment Routing

Additional References for Segment Routing

SRGB is used, configuring a prefix-SID of 10 for interface Loopback 0 with IPv4 address 1.0.0.1/32 results in assigning the label 9000010 16010 to the prefix 1.0.0.1/32.

BGP Prefix Segment Identifiers

Segments associated with a BGP prefix are known as BGP Prefix-SIDs.

• BGP Prefix-SIDs are always global within a Segment Routing or BGP domain

• BGP Prefix-SIDs identifies an instruction to forward the packet over ECMP-aware best path computed by BGP for a given prefix

Segment Routing requires BGP speaker to be configured with a Segment Routing Global block (SRGB).

Generally, SRGB is configured as a range of labels, SRGB = [SR_S, SR_E].

• SR_S = Start of the range

• SR_E = End of the range

Each prefix is assigned with its own unique label index.

In the following example, a BGP route policy, set label index, is defined using the route-policy name command.

Configure the Segment Routing Global Block (SRGB) in BGP. If the route label path has a label-index attribute and SRGB is configured, then local label route is allocated from SRGB. If label-index is added to redistributed routes using route-policy, then BGP presents label-index as an attribute with the route.

segment-routing # default SRGB: 16000-23999 global-block 16000 17000 route-policy setlindex if destination in (192.168.3.2/32) then set label-index 14 endif end-policy interface Loopback3 ipv4 address 192.168.3.2 255.255.255.255

router bgp 2 address-family ipv4 unicast redistribute connected route-policy setlindex

Additional References for Segment Routing

Related Documents

Related Topic

Videos

Document Title

• Introduction to Cisco Segment Routing

(YouTube)

• Introduction to Cisco Segment Routing (CCO)

Segment Routing Configuration Guide

C H A P T E R

Segment Routing—IS-IS v4 node SID

The Segment Routing—ISIS v4 node SID feature provides support for segment routing on Cisco Intermediate

System-to-Intermediate System (IS-IS) networks.

•

Information About Segment Routing IS-IS v4 Node, page 11

•

How to Configure Segment Routing —IS-IS v4 node SID, page 11

•

Configuration Examples for Segment Routing —IS-IS v4 node SID, page 16

•

Additional References, page 17

•

Feature Information for Segment Routing—IS-IS v4 node SID, page 18

Information About Segment Routing IS-IS v4 Node

Segment Routing IS-IS v4 node SID

Segment Routing (SR) is a technique by which the path followed by a packet is encoded in the packet itself.

The path followed by a packet in segment routing is encoded in the packet itself similar to loose or strict source routing. Segment Routing relies on a small number of extensions to Cisco Intermediate

System-to-Intermediate System (IS-IS) and Open Shortest Path First (OSPF) protocols.

How to Configure Segment Routing —IS-IS v4 node SID

Configuring Segment Routing

Before You Begin

Before configuring IS-IS to support segment routing you must first configure the segment routing feature in global configuration mode.

Segment Routing Configuration Guide

Segment Routing—IS-IS v4 node SID

Configuring Segment Routing

SUMMARY STEPS

1. enable

2. configure terminal

3. segment-routing mpls

4. connected-prefix-sid-map

5. address-family ipv4

6. 1.1.1.1/32 100

DETAILED STEPS

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

Command or Action enable

Example:

Device# enable

configure terminal

Purpose

Enables privileged EXEC mode.

• Enter your password if prompted.

Enters global configuration mode.

Example:

Device# configure terminal segment-routing mpls Enables the segment feature using the mpls data plane.

Example:

Device(config-sr)# segment-routing mpls connected-prefix-sid-map Enters a sub-mode where you can configure address-family specific mappings for local prefixes and

SIDs.

Example:

Device(config-srmpls)# connected-prefix-sid-map address-family ipv4 Specifies IP Version 4 address prefixes.

Example:

Device(config-srmpls-conn)# address-family

1.1.1.1/32 100 range 1

1.1.1.1/32 100

Example:

Device(config-srmpls-conn-af)# 1.1.1.1/32 100

Associates SID 100 w the address 1.1.1.1/32.

Segment Routing Configuration Guide

Segment Routing—IS-IS v4 node SID

Configuring Segment Routing on IS-IS Network

Configuring Segment Routing on IS-IS Network

Before You Begin

Before you configure segment routing on IS-IS network, IS-IS must be enabled on your network.

SUMMARY STEPS

1. router isis

2. net network-entity-title

3. metric-style wide

4. segment-routing mpls

5. exit

6. show isis segment-routing state

DETAILED STEPS

Step 1

Step 2

Step 3

Step 4

Step 5

Command or Action

router isis

Purpose

Enables the IS-IS routing protocol and enters router configuration mode.

Example:

Device(config-if)# router isis net network-entity-title Configures network entity titles (NETs) for the routing instance.

Example:

Device(config-router)# net 49.0000.0000.0003.00

metric-style wide

Example:

Configures the device to generate and accept only wide link metrics.

Device(config-router)# metric-style wide

segment-routing mpls Configures segment routing operation state.

Example:

Device(config-router)# segment-routing mpls exit

Example:

Device(config-router)# exit

Exits segment routing mode and returns to the configuration terminal mode.

Segment Routing Configuration Guide

Segment Routing—IS-IS v4 node SID

Configuring Prefix-SID for IS-IS

Step 6

Command or Action

show isis segment-routing state

Example:

Device# show is-is segment-routing state

Purpose

(Optional) Displays the current state of the IS-IS segment routing.

The following example displays output from the show isis segment-routing state command for the segment routing under IS-IS:

Device#

show isis segment-routing

ISIS protocol is registered with MFI

ISIS MFI Client ID:0x63

Tag 1 - Segment-Routing:

SR State:SR_ENABLED

Number of SRGB:1

SRGB Start:16000, Range:8000, srgb_handle:0x4500AED0, srgb_state: created

Address-family IPv4 unicast SR is configured

Operational state:Enabled

Configuring Prefix-SID for IS-IS

This task explains how to configure prefix segment identifier (SID) index under each interface.

Before You Begin

Segment routing must be enabled on the corresponding address family.

SUMMARY STEPS

1. enable

2. configure terminal

3. interface Loopback interface-instanceinterface-type

4. address-family { ipv4 | ipv6 } [ unicast ]

5. prefix-sid index index-value [ n-flag-clearlevel ] [ explicit-null ]

6. exit

DETAILED STEPS

Step 1

Command or Action

enable

Example:

Device# enable

Purpose

Enables privileged EXEC mode.

Segment Routing Configuration Guide

Segment Routing—IS-IS v4 node SID

Configuring Prefix Attribute N-flag-clear

Step 2

Step 3

Step 4

Step 5

Step 6

Command or Action

configure terminal

Example:

Device# configure terminal interface Loopback interface-instanceinterface-type

Example:

Device(config)# interface loopback0 passive address-family { ipv4 | ipv6 } [ unicast ]

Example:

Device(config-if)# address-family ipv4 unicast prefix-sid index index-value [ n-flag-clearlevel ] [ explicit-null ]

Example:

Device(config-if-af)# prefix-sid index 1001

[n-flag-clear] [explicit-null] exit

Example:

Device(config-router)# exit

Purpose

Enters global configuration mode.

Specifies the interface loopback and interface type.

Specifies the IPv4 or IPv6 address family, and enters router address family configuration mode.

Configures the prefix-SID index for the interface.

Exits segment routing mode and returns to the configuration terminal mode.

Configuring Prefix Attribute N-flag-clear

By default, a flag called N-flag is set by IS-IS when advertising a SID which is associated with a loopback address. If you wish to clear this flag add explicit configuration.

SUMMARY STEPS

1. enable

2. configure terminal

3. interface loopback0

4. isis prefix-attributes n-flag-clear {Level-1|Level-2}

Segment Routing Configuration Guide

Segment Routing—IS-IS v4 node SID

Configuration Examples for Segment Routing —IS-IS v4 node SID

DETAILED STEPS

Step 1

Step 2

Step 3

Step 4

Command or Action enable

Example:

Device# enable

configure terminal

Example:

Device# configure terminal interface loopback0

Example:

Device(config)# interface loopback0 isis prefix-attributes n-flag-clear {Level-1|Level-2}

Example:

Device(config-if)# isis prefix-attributes n-flag-clear level-1

Purpose

Enables privileged EXEC mode.

• Enter your password if prompted.

Enters global configuration mode.

Enters interface configuration sub-mode.

Clears the prefix-SID attribute N-flag explicitly.

Configuration Examples for Segment Routing —IS-IS v4 node

SID

Example: Configuring Segment Routing on IS-IS Network

The following example shows how to configure segment routing under non-default SRGB mode: enable configure terminal segment-routing mpls global-block 20000 24999

connected-prefix-sid-map address-family ipv4

1.1.1.1/32 100 range 1

exit-address-family router isis net 49.1111.1111.1111.00

metric-style wide segment-routing mpls

Segment Routing Configuration Guide

Segment Routing—IS-IS v4 node SID

Example: Configuring Prefix Attribute N-Flag-Clear

Example: Configuring Prefix Attribute N-Flag-Clear

The following is an example for configuring prefix attribute n-flag-clear for interface loopback3:

Device(config)#

interface loopback3

Device(config-if)#

isis prefix n-flag-clear Clear N-flag

Device(config-if)#

isis prefix n-flag-clear

Device(config-if)#

isis prefix n-flag-clear

Additional References

Related Documents

Related Topic

Cisco IOS commands

IP Routing ISIS commands

Document Title

Cisco IOS Master Command List, All Releases http:/

/www.cisco.com/c/en/us/td/docs/ios-xml/ios/mcl/ allreleasemcl/all-book.html

Cisco IOS IP Routing ISIS commands http:// www.cisco.com/c/en/us/td/docs/ios-xml/ios/mcl/ allreleasemcl/all-book.html

Technical Assistance

Description Link

The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies.

Access to most tools on the Cisco Support and

Documentation website requires a Cisco.com user ID and password.

http://www.cisco.com/cisco/web/support/index.html

Segment Routing Configuration Guide

Segment Routing—IS-IS v4 node SID

Feature Information for Segment Routing—IS-IS v4 node SID

Feature Information for Segment Routing—IS-IS v4 node SID

Table 1: Feature Information for ISIS Segment Routing

Feature Name Releases

Segment Routing—IS-IS v4 node

SID

Cisco IOS XE Release 3.16S

Feature Information

The Segment Routing—ISIS v4 node SID feature provides support for segment routing on IS-IS networks.

The following commands were introduced or modified: isis

prefix-attributes n-flag-clear, isis segment-routing, show isis segment-routing state

Segment Routing Configuration Guide

C H A P T E R

Segment Routing-OAM Support

The Segment Routing-OAM Support feature provides support for Nil-FEC LSP Ping/Trace functionality.

•

Finding Feature Information, page 19

•

Information About Segment Routing-OAM Support, page 19

•

How to Diagnose Segment Routing with LSP Ping and Trace Route Nil FEC Target, page 20

•

Example: LSP Ping Nil_FEC Target Support, page 21

•

Additional References for Segment Routing-OAM Support, page 23

•

Feature Information for Segment Routing-OAM Support, page 23

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support.

To access Cisco Feature Navigator, go to www.cisco.com/go/cfn . An account on Cisco.com is not required.

Information About Segment Routing-OAM Support

Segment Routing-OAM Support

The Segment Routing-OAM Support feature provides support for Nil-FEC LSP Ping/Trace functionality.

Nil-FEC LSP Ping/Trace functionality support Segment Routing and MPLS Static. It also act 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

Segment Routing Configuration Guide

Segment Routing-OAM Support

LSP Ping Operation for Nil FEC target

• nexthop address

In the case of segment routing, each segment nodal label and adjacent label along the routing path is put into the label stack of an echo request message from initiator Label Switch Router (LSR); MPLS data plane forward this packet to the label stack target, and the label stack target reply the echo message back.

LSP Ping Operation for Nil FEC target

The LSP Ping/Traceroute is used in identifying LSP breakages. The nil-fec target type can be used to test the connectivity for a known label stack. Follow the existing LSP ping procedure (for more information, refer

MPLS LSP Ping/Traceroute ), with the following modifications:

• Build the echo request packet with the given label stack;

• Append explicit null label at the bottom of the label stack;

• Build echo request FTS TLV with target FEC Nil FEC and label value set to the bottom label of the label stack, which is explicit-null.

How to Diagnose Segment Routing with LSP Ping and Trace

Route Nil FEC Target

Use LSP Ping for Nil FEC Target

The Nil-FEC LSP ping and traceroute operation are simply extension of regular MPLS ping and trace route.

nil-fec labels <label, label…> is added to the ping mpls command. This command sends an echo request message with MPLS label stack as specified, and add another explicit null at bottom of the stack.

ping mpls

{{ipv4 <target>/<mask> [fec-type {bgp | generic | ldp}] |

{pseudowire <peer addr> <vc-id> [segment<segment-number>]} |

{traffic-eng {<tunnel interface> |

{p2p <sender> <endpoint>

<tun-id> <ex-tun-id> <lspid>} |

{p2mp <p2mp-id> <sender>

<tun-id><ex-tun-id> <lspid>}} |

{tp <tunnel-tp interface> lsp <working | protect | active>}} |

{mldp {p2mp | mp2mp}

{{ipv4 <source> <group>} |

{ipv6 <source> <group>} |

{vpnv4 <rd> <source> <group>} |

{vpnv6 <rd> <source> <group>} |

{hex <opaque type> <opaque value>} |

{mdt <vpnid> <mdt-num>} |

{static-id <lsp-identifier>} |

{global-id <global-identifier>}}} |

{nil-fec {labels <comma separated labels>}}

[repeat <count>]

[size <size> | sweep <min_size> <max_size> <increment>]

[timeout <seconds>]

[interval <milliseconds>]

[destination <addr_start> [<addr_end> [<addr_incr_mask> | <addr_incr>]]]

[source <addr>]

[exp <exp-value>]

[pad <pattern>]

[ttl <ttl>]

Segment Routing Configuration Guide

Segment Routing-OAM Support

Use LSP Traceroute for Nil FEC Target

[reply [mode [ipv4 | router-alert | no-reply]]

[dscp <dscp-bits>]

[pad-tlv]]

[verbose]

[force-explicit-null]

[force-disposition ra-label]

[output {interface <tx-interface>} [nexthop <nexthop ip addr>]]

[{dsmap | ddmap [l2ecmp]} [hashkey {none | {ipv4 | ipv4-label-set {bitmap <bitmap_size>}}]

[flags {fec | ttl}]

[segment {all | <lower-segment-number> [upper-segment-number]}

[jitter <milliseconds>]

[responder-id <ip addr> | egress <ipaddr>]

NOTE: responder-id for mldp/ egress for p2mp te

[entropy-label <label-value>]

For more information, refer ping mpls .

Use LSP Traceroute for Nil FEC Target

trace mpls

{{ipv4 <target>/<mask> [fec-type {bgp | generic | ldp}]} |

{traffic-eng {<tunnel interface> |

{p2p <sender> <endpoint>

<tun-id> <ex-tun-id> <lspid>} |

{p2mp <p2mp-id> <sender>

<tun-id><ex-tun-id> <lspid>}} |

{mldp {p2mp | mp2mp}

{{ip <source> <group>} |

{vpn <rd> [<source> <group>]} |

{hex <opaque type> <opaque value>} |

{mdt <vpnid> <mdt-num>} |

{static-id <lsp-identifier>} |

{global-id <global-identifier>}}}

{pseudowire <next-pe-address> <pwid> [segment

<segment-number/lower-segment-number>[<upper-segment-limit>]]} |

{tp <tunnel-tp interface> lsp <working | protect | active>}} |

{nil-fec {labels <comma separated labels>}}

[timeout <seconds>]

[destination <addr_start> [<addr_end> [<addr_incr_mask> | <addr_incr>]]]

[source <addr> ]

[exp <exp-value>]

[ttl <ttl-max>]

[reply [mode [ipv4 | router-alert | no-reply]]

[dscp <dscp-bits>]

[pad-tlv]]

[force-explicit-null]

[output {interface <tx-interface>} [nexthop <nexthop ip addr>]]

[flags {fec | ttl}]

[entropy-label <label-value>]

[hashkey ipv4 | ipv4-label-set {bitmap <bitmap_size>}]

For more information, refer to the traceroute mpls .

Example: LSP Ping Nil_FEC Target Support

Node loopback IP address: 1.1.1.3

1.1.1.7

Node label:

Nodes:

16007

--------------- Texas

Interface:

Interface IP address:

Arizona --------------- Utah

Eth1/0

30.1.1.3

1.1.1.4

16004

Eth1/0

30.1.1.4

1.1.1.5

16005

--------------- Wyoming

SR232-utah#sh mpls forwarding-table

Local Outgoing Prefix Bytes Label Outgoing Next Hop

Segment Routing Configuration Guide

Segment Routing-OAM Support

Example: LSP Ping Nil_FEC Target Support

Local

Label

16005

16006

16007

16017

16250

16252

16253

17000

17002

Label

Label or Tunnel Id Switched interface

Pop Label 3333.3333.0000-Et1/0-30.1.1.3

0 Et1/0

Pop Label 5555.5555.5555-Et1/1-90.1.1.5

0 Et1/1

30.1.1.3

90.1.1.5

Pop Label 3333.3333.0253-Et0/2-102.102.102.2

Pop Label 9.9.9.4/32

Pop Label 1.1.1.5/32

Pop Label 1.1.1.3/32 0

Pop Label 16.16.16.16/32 0

Pop Label 16.16.16.17/32 0

Pop Label 17.17.17.17/32 0

20 9.9.9.3/32 0

1.1.1.6/32

1.1.1.2/32

1.1.1.7/32

27 9.9.9.7/32

Pop Label 55.1.1.0/24

Pop Label 19.1.1.0/24

Outgoing Prefix

Label or Tunnel Id

Et0/2

Et1/1

Et1/0

Et1/1

102.102.102.2

90.1.1.5

30.1.1.3

90.1.1.5

Et1/1

90.1.1.5

0 Et1/0 30.1.1.3

Bytes Label Outgoing Next Hop

Switched interface

Pop Label 100.1.1.0/24 0

Pop Label 100.100.100.0/24 0

Pop Label 110.1.1.0/24

28 10.1.1.0/24

101.101.101.0/24 0

65.1.1.0/24 0

104.104.104.0/24 0

103.103.103.0/24 0

Pop Label 1.1.1.5/32

16006 1.1.1.6/32

1782

16007

16017

16250

1.1.1.7/32 0

17.17.17.17/32 0

9.9.9.3/32 0

16252 9.9.9.7/32

Pop Label 9.9.9.4/32

17000

17002

16.16.16.16/32

1.1.1.2/32

Et1/0

Et1/1

Et1/0

Et1/1

Et1/0

Et1/1

Et1/0

Et1/1

Et0/2

Et1/0

Et1/1

30.1.1.3

90.1.1.5

30.1.1.3

90.1.1.5

30.1.1.3

90.1.1.5

30.1.1.3

90.1.1.5

102.102.102.2

30.1.1.3

90.1.1.5

SR231-arizona#ping mpls nil-fec labels 16005,16007 output interface ethernet 1/0 nexthop

30.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,

'l' - Label switched with FEC change, '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

SR231-arizona#traceroute mpls nil-fec labels 16005,16007 output interface ethernet 1/0 nexthop 30.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,

Segment Routing Configuration Guide

Segment Routing-OAM Support

Additional References for Segment Routing-OAM Support

'l' - Label switched with FEC change, 'd' - see DDMAP for return code,

'X' - unknown return code, 'x' - return code 0

Type escape sequence to abort.

0 30.1.1.3 MRU 1500 [Labels: 16005/16007/explicit-null Exp: 0/0/0]

L 1 30.1.1.4 MRU 1500 [Labels: implicit-null/16007/explicit-null Exp: 0/0/0] 1 ms

L 2 90.1.1.5 MRU 1500 [Labels: implicit-null/explicit-null Exp: 0/0] 1 ms

! 3 55.1.1.7 1 ms

Additional References for Segment Routing-OAM Support

Related Documents

Related Topic

Cisco IOS commands

Document Title

Cisco IOS Master Commands List, All Releases

Technical Assistance

Description Link

Access to most tools on the Cisco Support and

Documentation website requires a Cisco.com user ID and password.

http://www.cisco.com/cisco/web/support/index.html

Feature Information for Segment Routing-OAM Support

The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support.

To access Cisco Feature Navigator, go to www.cisco.com/go/cfn . An account on Cisco.com is not required.

Table 2: Feature Information for Segment Routing-OAM Support

Feature Name

Segment Routing-OAM Support

Releases

Cisco IOS XE Release 3.17 S

Feature Information

The Segment Routing-OAM

Support feature provides support for Nil-FEC LSP Ping/Trace functionality.

Segment Routing Configuration Guide

Feature Information for Segment Routing-OAM Support

Segment Routing-OAM Support

Segment Routing Configuration Guide

C H A P T E R

Segment Routing Traffic Engineering

Segment Routing (SR) enables any network node, such as a Server, Provider Edge (PE), Aggregator, or

Provider (P) to engineer an explicit path for each of its traffic classes. Note that this explicit path does not depend on a hop-by-hop signaling technique, such as Label Distribution Protocol (LDP) or Resource

Reservation Protocol (RSVP); it only depends on a set of "segments" that are preprogrammed and advertised by the link-state routing protocol. These segments act as topological sub-paths that can be combined together to form the desired path. In Segment Routing the path is encoded in each packet itself in the form of SR

Segment Identifiers (SIDs).

There are two types of segments—prefix and adjacency.

• A prefix segment represents the shortest path (as computed by IGP) to reach a specific prefix; a node segment is a special prefix segment that is bound to the loopback address of a node.

• An adjacency segment represents a specific adjacency to a neighbor node.

A node segment can be a multi-hop path while an adjacency segment is a one-hop path.

A segment is represented by a 32-bit entity called Segment ID (SID). A prefix-SID is globally unique, and the operator ensures such uniqueness. An adjacency SID is locally unique to the node, and is automatically generated by the node attached to the adjacency if anycast SID solution is used.

The Segment Routing control-plane can be applied to the MPLS data-plane. In this case, the prefix-SID in the MPLS data-plane is represented as an LSP whose path flows along the shortest-path to the prefix, whereas an adjacency-SID is represented as cross-connect entry pointing to a specific egress data-link.

A Traffic Engineered (TE) tunnel is a container of TE LSPs instantiated between the tunnel ingress and the tunnel destination. A TE tunnel can instantiate one or more SR-TE LSPs that are associated with the same tunnel. The SR-TE LSP path may not necessarily follow the same IGP path to a destination node. In this case, the SR-TE path can be specified through either a set of prefix-SIDs, or adjacency-SIDs of nodes, or both, and links to be traversed by the SR-TE LSP.

The head-end imposes the corresponding MPLS label stack on outgoing packets to be carried over the tunnel.

Each transit node along the SR-TE LSP path uses the incoming top label to select the next-hop, pop or swap the label, and forward the packet to the next node with the remainder of the label stack, until the packet reaches the ultimate destination.

The set of hops or segments that define an SR-TE LSP path are provisioned by the operator.

•

Restrictions for Configuring Segment Routing-Traffic Engineering, page 26

•

SR-TE LSP Instantiation, page 33

Segment Routing Configuration Guide

Segment Routing Traffic Engineering

Restrictions for Configuring Segment Routing-Traffic Engineering

•

SR-TE and TI-LFA, page 40

•

Fast Convergence Support in OSPF, page 47

•

SR-TE On Demand LSP, page 47

•

BGP Dynamic Segment Routing Traffic Engineering, page 51

•

Segment Routing-Traffic Engineering On-Demand Next Hop, page 54

•

Additional References for Segment Routing Traffic Engineering, page 66

•

Feature Information for Segment Routing -Traffic Engineering, page 66

Restrictions for Configuring Segment Routing-Traffic

Engineering

• SR-TE is not supported on broadcast interfaces; it is supported only point-to-point interfaces.

• The Cisco ASR routers support only a specific number of labels imposed on an outgoing packet. If the number of labels are greater than the specified number, the SR-TE tunnel creation fails. The Cisco

ASR1000 routers support a maximum of 16 labels.

Configuring a Path Option for a TE Tunnel

The segment-routing keyword indicates that the specified path is programmed as an SR path.

Router(config)#

interface tunnel

100

Router(config-if)#

tunnel mpls traffic-eng path-option

explicit name

foo

segment-routing

Router(config-if)#

tunnel mpls traffic-eng path-option

dynamic segment-routing

Router(config-if)#

tunnel mpls traffic-eng path-option

segment-routing

Note

With IP unnumbered interfaces dynamic path is not supported.

When the path-option type for an operational SR tunnel is changed from SR to non-SR (for example, dynamic), the existing forwarding entry of the tunnel is deleted.

Segment Routing can be enabled or disabled on an existing secondary or an in-use path-option. If the tunnel uses a signaled RSVP-TE explicit path-option and segment routing is enabled on that tunnel, the RSVP-TE

LSP is torn, and the SR-TE LSP is instantiated using the same path-option. Conversely, if segment routing is

Segment Routing Configuration Guide

Segment Routing Traffic Engineering

Configuring SR Explicit Path Hops

disabled on a path-option that is in use by the primary LSP, the tunnel goes down intermittently and a new

RSVP-TE LSP will be signaled using the same explicit path.

If the “segment-routing” path-option is enabled on a secondary path-option (i.e. not in-use by the tunnel’s primary LSP), the tunnel will be checked to evaluate if the newly specified SR-TE LSP path-option is valid and more favorable to use for the tunnel primary LSP.

Configuring SR Explicit Path Hops

Note

When using IP unnumbered interfaces, you cannot specify next hop address as an explicit path index. It should be node address or label.

For intra-area LSPs, the explicit path can be specified as a list of IP addresses:

Router(config)#

ip explicit-path name

foo

Router(config-ip-expl-path)#

index

next-address

1.1.1.1

--> node address

Router(config-ip-expl-path)#

index

next-address

12.12.12.2

--> link address

The explicit path can also be specified as segment-routing SIDs:

(config)#

ip explicit-path name

foo

(config-ip-expl-path)#

index

next-label

The following SR-TE explicit path hops are supported:

• IP addresses.

• MPLS labels

• Mix of IP addresses and MPLS labels

Note

IP addresses cannot be used after using the label in MIXED_PATH.

Segment Routing Configuration Guide

Segment Routing Traffic Engineering

Use Case: Segment Routing Traffic Engineering Basic Configuration

Use Case: Segment Routing Traffic Engineering Basic Configuration

Consider the following topology:

Configuration at the head-end router, R1: interface GigabitEthernet2 ip address 100.101.1.1 255.255.255.0

ip router isis 1 negotiation auto mpls traffic-eng tunnels router isis 1 net 49.0001.0010.0100.1001.00

is-type level-1 ispf level-1 metric-style wide log-adjacency-changes

segment-routing mpls segment-routing prefix-sid-map advertise-local mpls traffic-eng router-id Loopback1 mpls traffic-eng level-1

Configuration at the tail-end router, R6 interface GigabitEthernet2 ip address 100.101.1.1 255.255.255.0

ip router isis 1 negotiation auto mpls traffic-eng tunnels router isis 1 net 49.0001.0060.0600.6006.00

ispf level-1 metric-style wide log-adjacency-changes

segment-routing mpls

segment-routing prefix-sid-map advertise-local

mpls traffic-eng router-id Loopback1 mpls traffic-eng level-1

Segment Routing Configuration Guide

Segment Routing Traffic Engineering

Use Case: Segment Routing Traffic Engineering Basic Configuration

Explicit Path SR-TE Tunnel 1

Consider tunnel 1 based only on IP addresses: ip explicit-path name IP_PATH1 next-address 2.2.2.2

next-address 3.3.3.3

next-address 6.6.6.6

interface Tunnel1 ip unnumbered Loopback1 tunnel mode mpls traffic-eng tunnel destination 6.6.6.6

tunnel mpls traffic-eng autoroute announce tunnel mpls traffic-eng priority 6 6

tunnel mpls traffic-eng path-option 10 explicit name IP_PATH1 segment-routing

tunnel mpls traffic-eng path-selection metric igp tunnel mpls traffic-eng load-share 10 end

Explicit Path SR-TE Tunnel 2

Consider tunnel 2 based on node SIDs ip explicit-path name IA_PATH next-label 114 next-label 115

next-label 116 interface Tunnel2 ip unnumbered Loopback1 tunnel mode mpls traffic-eng tunnel destination 6.6.6.6

tunnel mpls traffic-eng autoroute announce tunnel mpls traffic-eng priority 6 6 tunnel mpls traffic-eng bandwidth 10000 class-type 1

tunnel mpls traffic-eng path-option 10 explicit name NODE_PATH segment-routing

tunnel mpls traffic-eng path-selection metric igp tunnel mpls traffic-eng load-share 10 end

Explicit Path SR-TE Tunnel 3

Consider that tunnel 3 is based on a mix of IP addresses and label ip explicit-path name MIXED_PATH enable next-address 2.2.2.2

next-address 3.3.3.3

next-label 115 next-label 116

interface Tunnel3 ip unnumbered Loopback1 tunnel mode mpls traffic-eng tunnel destination 6.6.6.6

tunnel mpls traffic-eng autoroute announce tunnel mpls traffic-eng priority 6 6

tunnel mpls traffic-eng path-option 10 explicit name MIXED_PATH segment-routing

tunnel mpls traffic-eng path-selection metric igp tunnel mpls traffic-eng load-share 10

Segment Routing Configuration Guide

Segment Routing Traffic Engineering

Verifying Configuration of the SR-TE Tunnels

Note

In the case of mixed path, IP next-hop cannot be used after using Node SIDs in the path. The following path will not be valid: ip explicit-path name MIXED_PATH enable next-label 115 next-label 116 next-address 2.2.2.2

Dynamic Path SR-TE Tunnel 4

Consider that tunnel 4is based on adjacency SIDs interface Tunnel4 ip unnumbered Loopback1 tunnel mode mpls traffic-eng tunnel destination 6.6.6.6

tunnel mpls traffic-eng autoroute announce tunnel mpls traffic-eng priority 6 6 tunnel mpls traffic-eng bandwidth 10000 class-type 1

tunnel mpls traffic-eng path-option 10 dynamic segment-routing

tunnel mpls traffic-eng path-selection metric igp tunnel mpls traffic-eng load-share 10 end

Dynamic Path SR-TE Tunnel 5

Consider that tunnel 5 is based on Node SIDs interface Tunnel5 ip unnumbered Loopback1 tunnel mode mpls traffic-eng tunnel destination 6.6.6.6

tunnel mpls traffic-eng autoroute announce tunnel mpls traffic-eng priority 6 6

tunnel mpls traffic-eng path-option 10 segment-routing

tunnel mpls traffic-eng path-selection metric igp tunnel mpls traffic-eng load-share 10

Verifying Configuration of the SR-TE Tunnels

Use the show mpls traffic-eng tunnels tunnel-number command to verify the configuration of the SR-TE tunnels.

Verifying Tunnel 1

Name: R1_t1

Status:

Admin: up

(Tunnel1) Destination: 6.6.6.6

Oper: up Path: valid Signalling: connected path option 10, (SEGMENT-ROUTING) type explicit IP_PATH (Basis for Setup)

Config Parameters:

Bandwidth: 0 kbps (Global) Priority: 6 6 Affinity: 0x0/0xFFFF

Metric Type: IGP (interface)

Path Selection:

Protection: any (default)

Path-invalidation timeout: 45000 msec (default), Action: Tear

Segment Routing Configuration Guide

Segment Routing Traffic Engineering

Verifying Configuration of the SR-TE Tunnels

AutoRoute: enabled LockDown: disabled Loadshare: 10 [200000000] auto-bw: disabled

Fault-OAM: disabled, Wrap-Protection: disabled, Wrap-Capable: No

Active Path Option Parameters:

State: explicit path option 10 is active

BandwidthOverride: disabled LockDown: disabled Verbatim: disabled

History:

Tunnel:

Time since created: 6 days, 19 hours

Time since path change: 2 seconds

Number of LSP IDs (Tun_Instances) used: 1814

Current LSP: [ID: 1814]

Uptime: 2 seconds

Selection: reoptimization

Prior LSP: [ID: 1813]

ID: path option unknown

Removal Trigger: configuration changed

Tun_Instance: 1814

Segment-Routing Path Info (isis level-1)

Segment0[Node]: 4.4.4.4, Label: 114

Segment1[Node]: 5.5.5.5, Label: 115

Segment2[Node]: 6.6.6.6, Label: 116

Verifying Tunnel 2

Name: R1_t2

Status:

(Tunnel1) Destination: 6.6.6.6

Admin: up Oper: up Path: valid Signalling: connected path option 10, (SEGMENT-ROUTING) type explicit IA_PATH (Basis for Setup)

Config Parameters:

Bandwidth: 0 kbps (Global) Priority: 6 6 Affinity: 0x0/0xFFFF

Metric Type: IGP (interface)

Path Selection:

Protection: any (default)

Path-invalidation timeout: 45000 msec (default), Action: Tear

AutoRoute: enabled LockDown: disabled Loadshare: 10 [200000000] auto-bw: disabled

Fault-OAM: disabled, Wrap-Protection: disabled, Wrap-Capable: No

Active Path Option Parameters:

State: explicit path option 10 is active

BandwidthOverride: disabled LockDown: disabled Verbatim: disabled

History:

Tunnel:

Time since created: 6 days, 19 hours, 1 minutes

Time since path change: 1 seconds

Number of LSP IDs (Tun_Instances) used: 1815

Current LSP: [ID: 1815]

Uptime: 1 seconds

Prior LSP: [ID: 1814]

ID: path option unknown

Removal Trigger: configuration changed

Tun_Instance: 1815

Segment-Routing Path Info (isis level-1)

Segment0[ - ]: Label: 114

Segment1[ - ]: Label: 115

Segment2[ - ]: Label: 116

Verifying Tunnel 3

Name: R1_t3

Status:

(Tunnel1) Destination: 6.6.6.6

Admin: up Oper: up Path: valid Signalling: connected path option 10, (SEGMENT-ROUTING) type explicit MIXED_PATH (Basis for Setup)

Config Parameters:

Bandwidth: 0 kbps (Global) Priority: 6 6 Affinity: 0x0/0xFFFF

Metric Type: IGP (interface)

Segment Routing Configuration Guide

Segment Routing Traffic Engineering

Verifying Configuration of the SR-TE Tunnels

Path Selection:

Protection: any (default)

Path-invalidation timeout: 45000 msec (default), Action: Tear

AutoRoute: enabled LockDown: disabled Loadshare: 10 [200000000] auto-bw: disabled

Fault-OAM: disabled, Wrap-Protection: disabled, Wrap-Capable: No

Active Path Option Parameters:

State: explicit path option 10 is active

BandwidthOverride: disabled LockDown: disabled Verbatim: disabled

History:

Tunnel:

Time since created: 6 days, 19 hours, 2 minutes

Time since path change: 2 seconds

Number of LSP IDs (Tun_Instances) used: 1816

Current LSP: [ID: 1816]

Uptime: 2 seconds

Selection: reoptimization

Prior LSP: [ID: 1815]

ID: path option unknown

Removal Trigger: configuration changed

Tun_Instance: 1816

Segment-Routing Path Info (isis level-1)

Segment0[Node]: 2.2.2.2, Label: 112

Segment1[Node]: 3.3.3.3, Label: 113

Segment2[ - ]: Label: 115

Segment3[ - ]: Label: 116

Verifying Tunnel 4

Name: R1_t4 (Tunnel1) Destination: 6.6.6.6

Status:

Admin: up Oper: up Path: valid Signalling: connected path option 10, (SEGMENT-ROUTING) type dynamic (Basis for Setup, path weight 30)

Config Parameters:

Bandwidth: 0 kbps (Global) Priority: 6 6 Affinity: 0x0/0xFFFF

Metric Type: IGP (interface)

Path Selection:

Protection: any (default)

Path-invalidation timeout: 45000 msec (default), Action: Tear

AutoRoute: enabled LockDown: disabled Loadshare: 10 [200000000] auto-bw: disabled

Fault-OAM: disabled, Wrap-Protection: disabled, Wrap-Capable: No

Active Path Option Parameters:

State: dynamic path option 10 is active

BandwidthOverride: disabled LockDown: disabled Verbatim: disabled

History:

Tunnel:

Time since created: 6 days, 19 hours

Time since path change: 2 seconds

Number of LSP IDs (Tun_Instances) used: 1813

Current LSP: [ID: 1813]

Uptime: 2 seconds

Prior LSP: [ID: 1806]

ID: path option unknown

Removal Trigger: configuration changed

Tun_Instance: 1813

Segment-Routing Path Info (isis level-1)

Segment0[Link]: 192.168.2.1 - 192.168.2.2, Label: 17

Segment1[Link]: 192.168.4.2 - 192.168.4.1, Label: 25

Segment2[Link]: 192.168.8.1 - 192.168.8.2, Label: 300

Verifying Tunnel 5

Name: R1_t5

Status:

Admin: up Oper: up

(Tunnel1) Destination: 6.6.6.6

Path: valid Signalling: connected

Segment Routing Configuration Guide

Segment Routing Traffic Engineering

SR-TE LSP Instantiation

path option 10, type segment-routing (Basis for Setup)

Config Parameters:

Bandwidth: 0 kbps (Global) Priority: 6 6 Affinity: 0x0/0xFFFF

Metric Type: IGP (interface)

Path Selection:

Protection: any (default)

Path-invalidation timeout: 45000 msec (default), Action: Tear

AutoRoute: enabled LockDown: disabled Loadshare: 10 [200000000] auto-bw: disabled

Fault-OAM: disabled, Wrap-Protection: disabled, Wrap-Capable: No

Active Path Option Parameters:

State: segment-routing path option 10 is active

BandwidthOverride: disabled LockDown: disabled Verbatim: disabled

History:

Tunnel:

Time since created: 6 days, 19 hours, 4 minutes

Time since path change: 14 seconds

Number of LSP IDs (Tun_Instances) used: 1817

Current LSP: [ID: 1817]

Uptime: 14 seconds

Selection: reoptimization

Prior LSP: [ID: 1816]

ID: path option unknown

Removal Trigger: configuration changed

Tun_Instance: 1817

Segment-Routing Path Info (isis level-1)

Segment0[Node]: 6.6.6.6, Label: 116

SR-TE LSP Instantiation

A Traffic Engineered (TE) tunnel is a container of one or more instantiated TE LSPs. An SR-TE LSP is instantiated by configuring ‘segment-routing’ on the path-option of the TE tunnel. The traffic mapped to the tunnel is forwarded over the primary SR-TE instantiated LSP.

Multiple path-options can also be configured under the same tunnel. Each path-option is assigned a preference index or a path-option index that is used to determine the more favorable path-option for instantiating the primary LSP—the lower the path-option preference index, the more favorable the path-option. The other less favorable path-options under the same TE tunnel are considered secondary path-options and may be used once the currently used path-option is invalidated (for example, due to a failure on the path.

Note

A forwarding state is maintained for the primary LSP only.

SR-TE LSP Explicit Null

MPLS-TE tunnel head-end does not impose explicit-null at the bottom of the stack. When penultimate hop popping (PHP) is enabled for SR prefix SIDs or when an adjacency SID is the last hop of the SR-TE LSP, the packet may arrive at the tail-end without a transport label. However, in some cases, it is desirable that the packet arrive at the tail-end with explicit-null label, and in such case, the head-end will impose an explicit-null label at the top of the label stack.

SR-TE LSP Path Verification

SR-TE tunnel functionality requires that the head-end perform initial verification of the tunnel path as well as the subsequent tracking of the reachability of the tunnel tail-end and traversed segments.

Segment Routing Configuration Guide

Segment Routing Traffic Engineering

SR-TE LSP Path Verification

Path verification for SR-TE LSP paths is triggered whenever MPLS-TE is notified of any topology changes or SR SID updates.

The SR-TE LSP validation steps consist of the following checks:

Topology Path Validation

The head-end validates the path of an SR-TE LSP for connectivity against the TE topology. MPLS-TE head-end checks if links corresponding to the adjacency SIDs are connected in the TE topology.

For newly-instantiated SR-TE LSPs, if the head-end detects a discontinuity on any link of the SR-TE path, that path is considered invalid and is not used. If the tunnel has other path-options with valid paths, those paths are used to instantiate the tunnel LSP.

For TE tunnels with existing instantiated SR-TE LSP, if the head-end detects a discontinuity on any link, the head-end assumes a fault has occurred on that link. In this case, the local repair protection, such as the IP

FRR, come in to effect. The IGPs continue to sustain the protected adjacency label and associated forwarding after the adjacency is lost for some time. This allows the head-ends enough time to reroute the tunnels onto different paths that are not affected by the same failure. The head-end starts a tunnel invalidation timer once it detects the link failure to attempt to reroute the tunnel onto other available path-options with valid paths.

If the TE tunnel is configured with other path-options that are not affected by the failure and are validated, the head-end uses one of those path-options to reroute (and re-optimize) the tunnel by instantiating a new primary LSP for the tunnel using the unaffected path.

If no other valid path-options exist under the same tunnel, or if the TE tunnel is configured with only one path-option that is affected by the failure, the head-end starts an invalidation timer after which it brings the tunnel state to ‘down’. This action avoids black-holing the traffic flowing over the affected SR-TE LSP, and allows services riding over the tunnel to reroute over different available paths at the head-end. There is an invalidation drop configuration that keeps the tunnel 'up', but drops the traffic when the invalidation timer expires.

For intra-area SR-TE LSPs, the head-end has full visibility over the LSP path, and validates the path to the ultimate LSP destination. However, for inter-area LSPs, the head-end has partial visibility over the LSP path—only up to the first ABR. In this case, the head-end can only validate the path from the ingress to the first ABR. Any failure along the LSP beyond the first ABR node is invisible to the head-end, and other mechanisms to detect such failures, such as BFD over LSP are assumed.

SR SID Validation

SID hops of an SR-TE LSP are used to determine the outgoing MPLS label stack to be imposed on the outgoing packets carried over the SR-TE LSP of a TE tunnel. A database of global and local adjacency-SIDs is populated from the information received from IGPs and maintained in MPLS-TE. Using a SID that is not available in the MPLS TE database invalidates the path-option using the explicit-path. The path-option, in this case, is not used to instantiate the SR TE LSP. Also, withdrawing, adding, or modifying a SID in the MPLS-TE

SID-database, results in the MPLS-TE head-end verifying all tunnels with SR path-options (in-use or secondary) and invokes proper handling.

LSP Egress Interface

When the SR-TE LSP uses an adjacency-SID for the first path hop, TE monitors the interface state and IGP adjacency state associated with the adjacency-SID and the node that the SR-TE LSP egresses on. If the interface

Segment Routing Configuration Guide

Segment Routing Traffic Engineering

SR-TE LSP Path Verification

or adjacency goes down, TE can assume a fault occurred on the SR-TE LSP path and take the same reactive actions described in the previous sections.

Note

When the SR-TE LSP uses a prefix-SID for the first hop, TE cannot directly infer on which interface the tunnel egresses. TE relies on the IP reachability information of the prefix to determine if connectivity to the first hop is maintained.

IP Reachability Validation

MPLS-TE validates that the nodes corresponding to the prefix-SIDs are IP reachable before declaring the SR path valid. MPLS-TE detects path changes for the IP prefixes corresponding to the adjacency or prefix SIDs of the SR-TE LSP path. If the node announcing a specific SID loses IP reachability. due to a link or node failure, MPLS-TE is notified of the path change (no path). MPLS-TE reacts by invalidating the current SR-TE

LSP path, and may use other path-options with a valid path, if any to instantiate a new SR-TE LSP.

Note

Since IP-FRR does not offer protection against failure of a node that is being traversed by an SR-TE LSP

(such as, a prefix-SID failure along the SR-TE LSP path), the head-end immediately reacts to IP route reachability loss for prefix-SID node by setting the tunnel state to ‘down’ and removes the tunnel forwarding entry if there are no other path-options with valid path for the affected tunnel.

Tunnel Path Affinity Validation

The affinity of a tunnel path can be specified using the command tunnel mpls traffic-eng affinity under the tunnel interface.

The head-end validates that the specified SR path is compliant with the configured affinity. This necessitates that the paths of each segment of the SR path be validated against the specified constraint. The path is declared invalid against the configured affinity constraints if at least a single segment of the path does not satisfy the configured affinity.

interface Tunnel1 no ip address tunnel mode mpls traffic-eng tunnel destination 5.5.5.5

tunnel mpls traffic-eng priority 5 5 tunnel mpls traffic-eng bandwidth 100

tunnel mpls traffic-eng affinity 0x1 mask 0xFFFF

tunnel mpls traffic-eng path-option 10 dynamic segment-routing

Router# show tunnel ??

Name: R1_t1 (Tunnel1) Destination: 5.5.5.5

Status:

Admin: up Oper: up Path: valid Signalling: connected path option 10, (SEGMENT-ROUTING) type dynamic (Basis for Setup, path weight 20)

Config Parameters:

Bandwidth: 100 kbps (Global) Priority: 5 5

Affinity: 0x1/0xFFFF

Metric Type: TE (default)

Path Selection:

Protection: any (default)

Path-selection Tiebreaker:

Global: not set Tunnel Specific: not set Effective: min-fill (default)

Hop Limit: disabled

Cost Limit: disabled

Path-invalidation timeout: 10000 msec (default), Action: Tear

AutoRoute: disabled LockDown: disabled Loadshare: 100 [0] bw-based

Segment Routing Configuration Guide

Segment Routing Traffic Engineering

SR-TE LSP Path Verification

auto-bw: disabled

Fault-OAM: disabled, Wrap-Protection: disabled, Wrap-Capable: No

Active Path Option Parameters:

State: dynamic path option 10 is active

BandwidthOverride: disabled LockDown: disabled Verbatim: disabled

Node Hop Count: 2

History:

Tunnel:

Time since created: 10 minutes, 54 seconds

Time since path change: 34 seconds

Number of LSP IDs (Tun_Instances) used: 55

Current LSP: [ID: 55]

Uptime: 34 seconds

Prior LSP: [ID: 49]

ID: path option unknown

Removal Trigger: tunnel shutdown

Tun_Instance: 55

Segment-Routing Path Info (isis level-1)

Segment0[Link]: 192.168.2.1 - 192.168.2.2, Label: 46

Segment1[Link]: 192.168.4.2 - 192.168.4.1, Label: 49

Configuring Affinity on an Interface

interface GigabitEthernet2 ip address 192.168.2.1 255.255.255.0

ip router isis 1 negotiation auto mpls traffic-eng tunnels

mpls traffic-eng attribute-flags 0x1

isis network point-to-point ip rsvp bandwidth

Tunnel Path Resource Avoidance Validation

You can specify a set of addresses to be validated as excluded from being traversed by SR-TE tunnel packets.

To achieve this, the head-end runs the per-segment verification checks and validates that the specified node, prefix or link addresses are indeed excluded from the tunnel in the SR path. The tunnel resource avoidance checks can be enabled per path using the commands below. The list of addresses to be excluded are defined and the name of the list is referenced in the path-option.

interface tunnel100 tunnel mpls traffic-eng path-option 1 explicit name EXCLUDE segment-routing ip explicit-path name EXCLUDE enable exclude-address 192.168.0.2

exclude-address 192.168.0.4

exclude-address 192.168.0.3

Tunnel Path Loop Validation

The SR path is a concatenation of SR segments (combination of prefix and adjacency SIDs). It is possible that any of the traversed segment’s underlying paths may traverse through the ingress of the tunnel. In this case, packets that are mapped on the SR tunnel may loop back again to the head-end. To avoid this sub-optimal path, the head-end detects and invalidates a looping SR path through the ingress node.

Loop path validation is implicitly enabled on SR path. However, it is possible to disable this validation by using the verbatim path-option keyword associated with the tunnel path-option.

Segment Routing Configuration Guide

Segment Routing Traffic Engineering

SR-TE Traffic Load Balancing

The following is an example of the verbatim path-option keyword when IP address 6.6.6.6 is in a different area: interface Tunnel1 tunnel mode mpls traffic-eng tunnel destination 6.6.6.6

tunnel mpls traffic-eng priority 5 5 tunnel mpls traffic-eng bandwidth 100

tunnel mpls traffic-eng path-option 10 explicit name NODE_PATH segment-routing verbatim

Name: R1_t1 (Tunnel1) Destination: 6.6.6.6

Status:

Admin: up Oper: up Path: valid Signalling: connected

path option 10, (SEGMENT-ROUTING) type explicit (verbatim) NODE_PATH (Basis for Setup)

Config Parameters:

Bandwidth: 100 kbps (Global) Priority: 5 5 Affinity: 0x0/0xFFFF

Metric Type: TE (default)

Path Selection:

Protection: any (default)

Path-selection Tiebreaker:

Global: not set Tunnel Specific: not set Effective: min-fill (default)

Hop Limit: disabled [ignore: Verbatim Path Option]

Cost Limit: disabled

Path-invalidation timeout: 10000 msec (default), Action: Tear

AutoRoute: disabled LockDown: disabled Loadshare: 100 [0] bw-based auto-bw: disabled

Fault-OAM: disabled, Wrap-Protection: disabled, Wrap-Capable: No

Active Path Option Parameters:

State: explicit path option 10 is active

BandwidthOverride: disabled LockDown: disabled Verbatim: enabled

History:

Tunnel:

Time since created: 7 minutes, 43 seconds

Time since path change: 0 seconds

Number of LSP IDs (Tun_Instances) used: 49

Current LSP: [ID: 49]

Uptime: 0 seconds

Prior LSP: [ID: 48]

ID: path option unknown

Removal Trigger: signalling shutdown

Tun_Instance: 49

Segment-Routing Path Info (isis level-1)

Segment0[Node]: 2.2.2.2, Label: 20012

Segment1[Node]: 3.3.3.3, Label: 20013

Segment2[ - ]: Label: 20016

SR-TE Traffic Load Balancing

SR-TE tunnels support the following load-balancing options:

Load Balancing on Port Channel TE Links

Port Channel interfaces carry the SR-TE LSP traffic. This traffic load balances over port channel member links as well as over bundle interfaces on the head or mid of an SR-TE LSP.

Load Balancing on ECMPs

While using the equal cost multi path protocol (ECMP), the path to a specific prefix-SID may point to multiple next-hops. And if the SR-TE LSP path traverses one or more prefix-SIDs that have ECMP, the SR-TE LSP traffic load-balances on the ECMP paths of each traversed prefix-SID from the head-end or any midpoint traversed node along the SR-TE LSP path.

Segment Routing Configuration Guide

Segment Routing Traffic Engineering

SR-TE Tunnel Re-optimization

Load Balancing on Multiple Tunnels

Multiple TE tunnels can be used as next-hop paths for routes to specific IP prefixes either by configuring static route on multiple tunnels, or auto-route announcing multiple parallel tunnels to the same destination.

In such cases, the tunnels share the traffic load equally or load balance traffic on multiple parallel tunnels. It is also possible to allow Unequal Load Balance (UELB) with an explicit per tunnel configuration at the tunnel head-end. In this case, the tunnel load-share is passed from MPLS-TE to forwarding plane.

The tunnel load-share feature continues to work for TE tunnels that instantiate the SR-TE LSPs.

SR-TE Tunnel Re-optimization

TE tunnel 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.

Tunnels that instantiate SR-TE LSP can re-optimize without affecting the traffic carried over the tunnel.

Re-optimization can occur because:

• 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

When the head-end detects a failure on a protected SR adjacency-SID that is traversed by an SR-TE LSP, it starts the invalidation timer. If the timer expires and the head-end is still using the failed path because it is unable to reroute on a different path, the tunnel state is brought ‘down’ to avoid black-holing the traffic. Once the tunnel is down, services on the tunnel converge to take a different path.

The following is a sample output of a manual re-optimization example. In this example, the path-option is changed from ‘10’ to ‘20’.

Router#

mpls traffic-eng reoptimize tunnel 1 path-option 20

The targeted path-option is not in lock down mode. Continue? [no]:

yes

Router#

show mpls traffic-eng tunnels tunnel1

Name: R1_t1 (Tunnel1) Destination: 6.6.6.6

Status:

Admin: up Oper: up Path: valid Signalling: connected path option 20, (SEGMENT-ROUTING) type explicit IP_PATH (Basis for Setup) path option 10, (SEGMENT-ROUTING) type dynamic

Config Parameters:

Bandwidth: 0 kbps (Global) Priority: 6 6 Affinity: 0x0/0xFFFF

Metric Type: IGP (interface)

Path Selection:

Protection: any (default)

Path-invalidation timeout: 45000 msec (default), Action: Tear

AutoRoute: enabled LockDown: disabled Loadshare: 10 [200000000] auto-bw: disabled

Fault-OAM: disabled, Wrap-Protection: disabled, Wrap-Capable: No

Active Path Option Parameters:

State: explicit path option 20 is active

BandwidthOverride: disabled LockDown: disabled Verbatim: disabled

History:

Tunnel:

Time since created: 6 days, 19 hours, 9 minutes

Time since path change: 14 seconds

Number of LSP IDs (Tun_Instances) used: 1819

Segment Routing Configuration Guide

Segment Routing Traffic Engineering

SR-TE Tunnel Protection

Current LSP: [ID: 1819]

Uptime: 17 seconds

Selection: reoptimization

Prior LSP: [ID: 1818]

ID: path option unknown

Removal Trigger: reoptimization completed

Tun_Instance: 1819

Segment-Routing Path Info (isis level-1)

Segment0[Node]: 4.4.4.4, Label: 114

Segment1[Node]: 5.5.5.5, Label: 115

Segment2[Node]: 6.6.6.6, Label: 116

SR-TE With lockdown Option

The lockdown option only prevents SR-TE from re-optimizing to a better path. However, it does not prevent signaling the existence of a new path.

interface Tunnel1 ip unnumbered Loopback1 tunnel mode mpls traffic-eng tunnel destination 6.6.6.6

tunnel mpls traffic-eng autoroute announce tunnel mpls traffic-eng priority 6 6

tunnel mpls traffic-eng path-option 10 segment-routing lockdown

tunnel mpls traffic-eng path-selection metric igp tunnel mpls traffic-eng load-share 10

Router#

show mpls traffic-eng tunnels tunnel1

Name: csr551_t1 (Tunnel1) Destination: 6.6.6.6

Status:

Admin: up Oper: up Path: valid Signalling: connected path option 10, (LOCKDOWN) type segment-routing (Basis for Setup)

Config Parameters:

Bandwidth: 0 kbps (Global) Priority: 6 6 Affinity: 0x0/0xFFFF

Metric Type: IGP (interface)

Path Selection:

Protection: any (default)

Path-invalidation timeout: 45000 msec (default), Action: Tear

AutoRoute: enabled LockDown: enabled Loadshare: 10 [200000000] auto-bw: disabled

Fault-OAM: disabled, Wrap-Protection: disabled, Wrap-Capable: No

Active Path Option Parameters:

State: segment-routing path option 10 is active

BandwidthOverride: disabled LockDown: enabled Verbatim: disabled

History:

Tunnel:

Time since created: 6 days, 19 hours, 22 minutes

Time since path change: 1 minutes, 26 seconds

Number of LSP IDs (Tun_Instances) used: 1822

Current LSP: [ID: 1822]

Uptime: 1 minutes, 26 seconds

Selection: reoptimization

Prior LSP: [ID: 1821]

ID: path option unknown

Removal Trigger: configuration changed

Tun_Instance: 1822

Segment-Routing Path Info (isis level-1)

Segment0[Node]: 6.6.6.6, Label: 116

SR-TE Tunnel Protection

Protection for SR TE tunnels can take any of the following alternatives:

Segment Routing Configuration Guide

Segment Routing Traffic Engineering

SR-TE and TI-LFA

IP-FRR Local Repair Protection

On an SR-TE LSP head-end or mid-point node, IP-FRR is used to compute and program the backup protection path for the prefix-SID or adjacency-SID label.

With IP-FRR, backup repair paths are pre-computed and pre-programmed by IGPs before a link or node failure. The failure of a link triggers its immediate withdrawal from the TE topology (link advertisement withdrawal). This allows the head-end to detect the failure of an SR-TE LSP traversing the failed adjacency-SID.

When a protected adjacency-SID fails, the failed adjacency-SID label and associated forwarding are kept functional for a specified period of time (5 to 15 minutes) to allow all SR TE tunnel head-ends to detect and react to the failure. Traffic using the adjacency-SID label continues to be FRR protected even if there are subsequent topology updates that change the backup repair path. In this case, the IGPs update the backup repair path while FRR is active to reroute traffic on the newly-computed backup path.

When the primary path of a protected prefix-SID fails, the PLR reroutes to the backup path. The head-end remains transparent to the failure and continues to use the SR-TE LSP as a valid path.

IP-FRR provides protection for adjacency and prefix-SIDs against link failures only.

Tunnel Path Protection

Path protection is the instantiation of one or more standby LSPs to protect against the failure of the primary

LSP of a single TE tunnel.

Path protection protects against failures by pre-computing and pre-provisioning secondary paths that are failure diverse with the primary path-option under the same tunnel. This protection is achieved by computing a path that excludes prefix-SIDs and adjacency-SIDs traversed by the primary LSP or by computing a path that excludes SRLGs of the primary SR-TE LSP path.

In the event of a failure of the primary SR-TE LSP, at least one standby SR-TE LSP is used for the tunnel.

Multiple secondary path-options can be configured to be used as standby SR-TE LSPs paths.

SR-TE and TI-LFA

Restrictions for Using SR-TE and TI-LFA

• In case of primary and secondary path switchover, a microloop is created between routers. Use the

microloop avoidance rib-update-delay command to bring down the convergence time

Consider the following topology:

Segment Routing Configuration Guide

Segment Routing Traffic Engineering

Restrictions for Using SR-TE and TI-LFA

router isis ipfrr net 49.0001.0120.1201.2012.00

is-type level-2-only ispf level-2 metric-style wide log-adjacency-changes segment-routing mpls segment-routing prefix-sid-map advertise-local fast-reroute per-prefix level-2 all fast-reroute ti-lfa level-2

microloop avoidance rib-update-delay 10000

• Before you configure SR-TE for TI-LFA, you must enable TI-LFA is enabled on all nodes.

mpls traffic-eng tunnels

segment-routing mpls connected-prefix-sid-map address-family ipv4

1.1.1.1/32 index 11 range 1

exit-address-family interface Loopback1 ip address 1.1.1.1 255.255.255.255

ip router isis 1

interface Tunnel1 ip unnumbered Loopback1 tunnel mode mpls traffic-eng tunnel destination 6.6.6.6

tunnel mpls traffic-eng autoroute announce tunnel mpls traffic-eng path-option 10 explicit name IP_PATH segment-routing

interface GigabitEthernet2 ip address 192.168.1.1 255.255.255.0

ip router isis 1 negotiation auto mpls traffic-eng tunnels isis network point-to-point

interface GigabitEthernet3 ip address 192.168.2.1 255.255.255.0

ip router isis 1 negotiation auto mpls traffic-eng tunnels

isis network point-to-point router isis 1 net 49.0001.0010.0100.1001.00

is-type level-1 ispf level-1 metric-style wide log-adjacency-changes segment-routing mpls

fast-reroute per-prefix level-1 all fast-reroute ti-lfa level-1

mpls traffic-eng router-id Loopback1 mpls traffic-eng level-1

Segment Routing Configuration Guide

Segment Routing Traffic Engineering

Verifying the SR-TE With TI_LFA Configuration

ip explicit-path name IP_PATH enable next-address 4.4.4.4

next-address 5.5.5.5

next-address 6.6.6.6

• To reduce or minimize traffic loss after a high availability (HA) switchover, MPLS TE NSR and ISIS

NSF must be enabled.

Use the mpls traffic-eng nsr command in global exec mode.

mpls traffic-eng nsr

Use the nsf command under ISIS or OSPF.

router isis nsf cisco nsf interval 0

Verifying the SR-TE With TI_LFA Configuration

Router#

show mpls traffic-eng tunnels tunnel1

Name: PE1 (Tunnel1) Destination: 6.6.6.6

Status:

Admin: up Oper: up Path: valid Signalling: connected path option 10, (SEGMENT-ROUTING) type explicit IP_PATH (Basis for Setup)

Config Parameters:

Bandwidth: 0 kbps (Global) Priority: 7 7 Affinity: 0x0/0xFFFF

Metric Type: TE (default)

Path Selection:

Protection: any (default)

Path-invalidation timeout: 45000 msec (default), Action: Tear

AutoRoute: enabled LockDown: disabled Loadshare: 0 [0] bw-based auto-bw: disabled

Fault-OAM: disabled, Wrap-Protection: disabled, Wrap-Capable: No

Active Path Option Parameters:

State: explicit path option 10 is active

BandwidthOverride: disabled LockDown: disabled Verbatim: disabled

History:

Tunnel:

Time since created: 4 hours, 25 minutes

Time since path change: 4 hours, 21 minutes

Number of LSP IDs (Tun_Instances) used: 37

Current LSP: [ID: 37]

Uptime: 4 hours, 21 minutes

Tun_Instance: 37

Segment-Routing Path Info (isis level-1)

Segment0[Node]: 4.4.4.4, Label: 16014

Segment1[Node]: 5.5.5.5, Label: 16015

Segment2[Node]: 6.6.6.6, Label: 16016

Router#

show isis fast-reroute ti-lfa tunnel

Tag 1:

Fast-Reroute TI-LFA Tunnels:

Tunnel

MP1

Interface

Gi2

Next Hop

192.168.1.2

End Point

6.6.6.6

Label

16016

End Point Host

SR_R6

MP2 Gi3 192.168.2.2

6.6.6.6

16016 SR_R6

Router#

show frr-manager client client-name ISIS interfaces detail

TunnelI/F : MP1

Type : SR

Next-hop : 192.168.1.2

End-point : 6.6.6.6

OutI/F : Gi2

Adjacency State : 1

Prefix0 : 6.6.6.6(Label : 16016)

TunnelI/F : MP2

Type : SR

Next-hop : 192.168.2.2

Segment Routing Configuration Guide

Segment Routing Traffic Engineering

Verifying the SR-TE With TI_LFA Configuration

End-point : 6.6.6.6

OutI/F : Gi3

Adjacency State : 1

Prefix0 : 6.6.6.6(Label : 16016)

Router#

show ip cef 6.6.6.6 internal

6.6.6.6/32, epoch 2, RIB[I], refcnt 6, per-destination sharing sources: RIB, LTE feature space:

IPRM: 0x00028000

Broker: linked, distributed at 1st priority

LFD: 6.6.6.6/32 1 local label sr local label info: global/16016 [0x1A] contains path extension list sr disposition chain 0x7FC6B0BF2AF0 label implicit-null

IP midchain out of Tunnel1 label 16016

FRR Primary

<primary: label 16015

TAG adj out of GigabitEthernet3, addr 192.168.2.2> sr label switch chain 0x7FC6B0BF2B88 label implicit-null

TAG midchain out of Tunnel1 label 16016

FRR Primary

<primary: label 16015

TAG adj out of GigabitEthernet3, addr 192.168.2.2> ifnums:

Tunnel1(13) path list 7FC6B0BBDDE0, 3 locks, per-destination, flags 0x49 [shble, rif, hwcn] path 7FC7144D4300, share 1/1, type attached nexthop, for IPv4

MPLS short path extensions: [rib | prfmfi | lblmrg | srlbl] MOI flags = 0x3 label implicit-null nexthop 6.6.6.6 Tunnel1, IP midchain out of Tunnel1 7FC6B0BBB440 output chain:

IP midchain out of Tunnel1 7FC6B0BBB440 label [16016|16016]

FRR Primary (0x7FC714515460)

<primary: label 16015

TAG adj out of GigabitEthernet3, addr 192.168.2.2 7FC6B0BBB630>

<repair: label 16015 label 16014

TAG midchain out of MPLS-SR-Tunnel1 7FC6B0BBAA90 label 16016

TAG adj out of GigabitEthernet2, addr 192.168.1.2 7FC6B0BBBA10>

Note

To ensure a less than 50 msec traffic protection with TI-LFA, SR-TE with dynamic path option must use the backup adjacency SID.

To create an SR-TE with dynamic path option, use the following configuration on every router in the topology: router isis 1 fast-reroute per-prefix level-1 all

At the tunnel head-end router: interface Tunnel1 ip unnumbered Loopback1 tunnel mode mpls traffic-eng tunnel destination 6.6.6.6

tunnel mpls traffic-eng autoroute announce tunnel mpls traffic-eng path-option 1 dynamic segment-routing tunnel mpls traffic-eng path-selection segment-routing adjacency protected

Segment Routing Configuration Guide

Configuring TI-LFA With Mapping Server

Configuring TI-LFA With Mapping Server

Consider the following topology:

Segment Routing Traffic Engineering

• IXIA-2 injects ISIS prefixes, and IXIA-1 sends one-way traffic to IXIA-2

• In R1 10,000 prefixes are configured in the segment-routing mapping-server

The configuration on R1 is: conf t segment-routing mpls global-block 16 20016

connected-prefix-sid-map address-family ipv4

11.11.11.11/32 index 11 range 1 exit-address-family

mapping-server

prefix-sid-map address-family ipv4

120.0.0.0/24 index 2 range 1 attach

200.0.0.0/24 index 1 range 1 attach

192.168.0.0/24 index 100 range 10000 attach exit-address-family

interface Loopback0 ip address 11.11.11.11 255.255.255.255

ip router isis ipfrr

interface GigabitEthernet0/1/0 ip address 14.0.0.1 255.255.255.0

ip router isis ipfrr negotiation auto isis network point-to-point

interface GigabitEthernet0/1/2 ip address 11.0.0.1 255.255.255.0

ip router isis ipfrr negotiation auto isis network point-to-point

interface GigabitEthernet0/1/4 ip address 200.0.0.1 255.255.255.0

ip router isis ipfrr negotiation auto isis network point-to-point

router isis ipfrr

Segment Routing Configuration Guide

Segment Routing Traffic Engineering

net 49.0001.0110.1101.1011.00

is-type level-2-only metric-style wide log-adjacency-changes nsf cisco segment-routing mpls segment-routing prefix-sid-map advertise-local fast-reroute per-prefix level-2 all fast-reroute ti-lfa level-2 microloop avoidance rib-update-delay 10000

On R2 the configuration is conf t

segment-routing mpls

connected-prefix-sid-map address-family ipv4

12.12.12.12/32 index 12 range 1 exit-address-family

interface Loopback0 ip address 12.12.12.12 255.255.255.255

ip router isis ipfrr

interface GigabitEthernet0/1/0 ip address 12.0.0.1 255.255.255.0

ip router isis ipfrr negotiation auto isis network point-to-point

interface GigabitEthernet0/1/1 ip address 11.0.0.2 255.255.255.0

ip router isis ipfrr negotiation auto isis network point-to-point

router isis ipfrr net 49.0001.0120.1201.2012.00

On R3 the configuration is conf t

mpls traffic-eng tunnels

segment-routing mpls

connected-prefix-sid-map address-family ipv4

13.13.13.13/32 index 13 range 1 exit-address-family

interface Loopback0 ip address 13.13.13.13 255.255.255.255

ip router isis ipfrr

interface GigabitEthernet0/0/4

Configuring TI-LFA With Mapping Server

Segment Routing Configuration Guide

Configuring TI-LFA With Mapping Server

ip address 13.0.0.1 255.255.255.0

ip router isis ipfrr load-interval 30 speed 1000 no negotiation auto isis network point-to-point

interface GigabitEthernet0/0/5 ip address 12.0.0.2 255.255.255.0

ip router isis ipfrr negotiation auto isis network point-to-point

router isis ipfrr net 49.0001.0130.1301.3013.00

On R4 the configuration is: conf t

mpls traffic-eng tunnels

segment-routing mpls

connected-prefix-sid-map address-family ipv4

14.14.14.14/32 index 14 range 1 exit-address-family

interface Loopback0 ip address 14.14.14.14 255.255.255.255

ip router isis ipfrr

interface GigabitEthernet0/0/0 ip address 14.0.0.2 255.255.255.0

ip router isis ipfrr negotiation auto isis network point-to-point

interface GigabitEthernet0/0/3 ip address 13.0.0.2 255.255.255.0

ip router isis ipfrr speed 1000 no negotiation auto isis network point-to-point

interface GigabitEthernet0/0/5 ip address 120.0.0.1 255.255.255.0

ip router isis ipfrr speed 1000 no negotiation auto isis network point-to-point

router isis ipfrr net 49.0001.0140.1401.4014.00

is-type level-2-only metric-style wide log-adjacency-changes nsf cisco segment-routing mpls segment-routing prefix-sid-map advertise-local

Segment Routing Configuration Guide

Segment Routing Traffic Engineering

Fast Convergence Support in OSPF

fast-reroute per-prefix level-2 all fast-reroute ti-lfa level-2 microloop avoidance rib-update-delay 10000

Fast Convergence Support in OSPF

RIB Support for Route Redistribution

Effective with Cisco IOS XE Everest 16.5.1, a requirement to redistribute labels associated with prefixes is introduced. To support redistribution requirements, the storage of local label per prefix is supported in RIB.

The local label is stored instead of the SID to ease use with different protocols which may use different SRGBs.

The SID assigned by the destination protocol may not be the same as the SID associated with the source protocol.

The prefix reachability advertisement or an SRMS advertisement is the source of the SID. In SRMS advertisement, the destination protocols for redistribution do not advertise the SID in their prefix reachability advertisements, as this alters conflict resolution by indicating on other network nodes that the source of the advertisement was not from SRMS.

RIB Support for On-Demand Next Hop

For On-Demand Next Hop (ODN) requirements, RIB supports a next hop called binding label which is provided by the supporting routing protocol (BGP). The binding label is used by the FIB to dynamically resolve the next hop.

The route producer installs a local binding label which identifies the ODN tunnel path associated with the next hop. The labeled traffic is sent via the tunnel and the label is distinct from the existing outlabel.

The following is the sample output of show ip route command where each next hop is updated to show the binding label.

Device#

show ip route 10.10.10.2

Routing entry for 10.10.10.2/32

Known via "isis", distance 115, metric 10, type level-1

Redistributing via isis

Last update from 200.200.200.2 on Ethernet0/0, 00:00:14 ago

Incoming Label: 16100

Routing Descriptor Blocks:

* 200.200.200.2, from 10.10.10.2, 00:00:14 ago, via Ethernet0/0

Route metric is 10, traffic share count is 1

* Binding Label 4020, from 2.2.2.2, 00:00:14 ago,

Route metric is 10, traffic share count is 1

SR-TE On Demand LSP

Restrictions for SR-TE On Demand LSP

• Segment-Routing auto tunnel static route does not support ECMP.

Segment Routing Configuration Guide

Segment Routing Traffic Engineering

SR-TE: Setup LSP as Static Route

• Metrics for IP explicit path and administrtive distance change for auto tunnel SRTE static route is not supported.

• MPLS Traffic Engineering (TE) Nonstop Routing (NSR) must be configured on the active route processor

(RP) for Stateful Switchover (SSO). This is because, SR static auto tunnel will fail to come up after

SSO, unless the static route auto tunnel configuration is removed and reconfigured.

• IP unnumbered interfaces do not support dynamic path.

• When using IP unnumbered interfaces, you cannot specify next hop address as an explicit path index.

It should be a node address or a label.

SR-TE: Setup LSP as Static Route

Agile Carrier Ethernet (ACE) solution leverages Segment Routing-based transport for consolidated VPN services. In metro rings architecture, the access rings do not share their routing topologies with each other.

The SR TE On demand LSP feature provides the ability to connect Metro access rings via a static route to the destination. The static route is mapped to an explicit path and that will trigger an on demand LSP to the destination. The SR TE On demand LSP feature will be used to transport the VPN services between the Metro access rings.

Figure 5: Inter-Metro LSP in ACE Solution

Inter-Metro LSPs have the following aspects:

• The source packet may not know the IP address of the destination device.

• Existing segment routing features are applicable for LSPs.

The binding SID helps in steering the traffic in the SR-TE tunnel. In other words, ingress MPLS packet with the binding SID will be forwarded through the specific SR-TE tunnel.

Static SRTE over Unnumbered Interfaces

As explained in the previous section, you can set up LSP as static route to create an auto tunnel by specifying an IP explicit path.

Segment Routing Configuration Guide

Segment Routing Traffic Engineering

Configuring LSP as Static Route

The explicit path is a combination of IP addresses (or) IP address and labels. You can also configure the static

SRTE tunnel over unnumbered interfaces. There are few restrictions for unnumbered interfaces against numbered interfaces.

• You must specify the node IP address, not the next hop interface address in the ip-explicit path option.

• You must not specify adjacency SID in the explicit path option. In short, the explicit path option should contain only the node IP address (/32 mask) and prefix SID labels.

Configuring LSP as Static Route

To avoid packet drop after RP switchover with SR TE, it is recommended to use the following command: mpls traffic-eng nsr

If ISIS is configured, use the following command: router isis nsf cisco nsf interval 0

Enabling Segment Routing Auto Tunnel Static Route

Perform this task to configure auto tunnel static route as follows:

• Configure IP explicit path

• Associate the auto tunnel with an IP explicit path with a static route

• Enable peer-to-peer (P2P) auto tunnel service ip explicit-path name path1 index 1 next-label 16002 index 2 next-label 16006 exit ip route 172.16.0.1 255.240.0.0 segment-routing mpls path name path1 mpls traffic-eng auto-tunnel p2p mpls traffic-eng auto-tunnel p2p config unnumbered-interface loopback0 mpls traffic-eng auto-tunnel p2p tunnel-num min 10 max 100

Verifying Segment Routing Auto-Tunnel Static Route

The command show mpls traffic-eng service summary displays all registered TE service clients and statistics that use TE auto tunnel.

Device#

show mpls traffic-eng service summary

Service Clients Summary:

Client: BGP TE

Client ID

Total P2P tunnels

P2P add requests

P2P delete requests

P2P add falis

P2P delete falis

P2P notify falis

P2P notify succs

P2P replays

Client: ipv4static

Client ID

Total P2P tunnels

:12

Segment Routing Configuration Guide

Segment Routing Traffic Engineering

Verifying Segment Routing Auto-Tunnel Static Route

P2P add requests

P2P delete requests

P2P add falis

P2P delete falis

P2P notify falis

P2P notify succs

P2P replays

:85

The command show mpls traffic-eng auto-tunnel p2p displays the peer-to-peer (P2P) auto tunnel configuration and operation status.

Device#

show mpls traffic-eng auto-tunnel p2p

State: Enabled p2p auto-tunnels: 2 (up: 2, down: 0)

Default Tunnel ID Range: 62336 - 64335

Config: unnumbered-interface: Loopback0

Tunnel ID range: 1000

– 2000

The command show mpls traffic-eng tunnel summary displays the status of P2P auto tunnel.

Device#

show mpls traffic-eng tunnel summmary

Signalling Summary:

LSP Tunnels Process:

Passive LSP Listener:

RSVP Process:

Forwarding: auto-tunnel: p2p running running running enabled

Enabled (1), id-range:1000-2000

Periodic reoptimization:

Periodic FRR Promotion:

Periodic auto-bw collection:

SR tunnel max label push: every 3600 seconds, next in 1265 seconds

Not Running every 300 seconds, next in 66 seconds

13 labels

P2P:

Head: 11 interfaces, 5234 active signalling attempts, 1 established

5440 activations, 206 deactivations

1821 failed activations

0 SSO recovery attempts, 0 SSO recovered

Midpoints: 0, Tails: 0

P2MP:

Head: 0 interfaces, 0 active signalling attempts, 0 established

0 sub-LSP activations, 0 sub-LSP deactivations

0 LSP successful activations, 0 LSP deactivations

0 SSO recovery attempts, LSP recovered: 0 full, 0 partial, 0 fail

Midpoints: 0, Tails: 0

Bidirectional Tunnel Summary:

Tunnel Head: 0 total, 0 connected, 0 associated, 0 co-routed

LSPs Head: 0 established, 0 proceeding, 0 associated, 0 standby

LSPs Mid: 0 established, 0 proceeding, 0 associated, 0 standby

LSPs Tail: 0 established, 0 proceeding, 0 associated, 0 standby

AutoTunnel P2P Summary: ipv4static:

Tunnels: 1 created, 1 up, 0 down

Total:

Tunnels: 1 created, 1 up, 0 down

The command show mpls traffic-eng tunnel auto-tunnel only displays TE service auto tunnel.

Device#

show mpls traffic-eng tunnel auto-tunnel detail

P2P TUNNELS/LSPs:

Name: R1_t1000

(auto-tunnel for ipv4static)

Status:

(Tunnel1000) Destination: 0.0.0.0 Ifhandle: 0x17

Admin: up Oper: up Path: valid Signalling: connected path option 1, (SEGMENT-ROUTING) type explicit (verbatim) path202 (Basis for Setup)

Segment Routing Configuration Guide

Segment Routing Traffic Engineering

BGP Dynamic Segment Routing Traffic Engineering

Config Parameters:

Bandwidth: 0 kbps (Global) Priority: 7 7 Affinity: 0x0/0xFFFF

Metric Type: TE (default)

Path Selection:

Protection: any (default)

Path-selection Tiebreaker:

Global: not set Tunnel Specific: not set Effective: min-fill (default)

Hop Limit: disabled [ignore: Verbatim Path Option]

Cost Limit: disabled

Path-invalidation timeout: 10000 msec (default), Action: Tear

AutoRoute: disabled LockDown: disabled Loadshare: 0 [0] bw-based auto-bw: disabled

Fault-OAM: disabled, Wrap-Protection: disabled, Wrap-Capable: No

Active Path Option Parameters:

State: explicit path option 1 is active

BandwidthOverride: disabled LockDown: disabled Verbatim: enabled

History:

Tunnel:

Time since created: 33 days, 20 hours, 29 minutes

Time since path change: 10 days, 19 hours, 45 minutes

Number of LSP IDs (Tun_Instances) used: 1646

Current LSP: [ID: 1646]

Uptime: 10 days, 19 hours, 45 minutes

Prior LSP: [ID: 1645]

ID: path option unknown

Removal Trigger: signalling shutdown

Tun_Instance: 1646

Segment-Routing Path Info (IGP information is not used)

Segment0[First Hop]: 0.0.0.0, Label: 16002

Segment1[ - ]: Label: 16006

The command show mpls traffic-eng tunnel brief displays auto tunnel information.

Device#

show mpls traffic-eng tunnel brief

Signalling Summary:

LSP Tunnels Process:

Passive LSP Listener:

RSVP Process:

Forwarding: auto-tunnel: p2p running running running enabled

Enabled (2), id-range:1000-2000

Periodic reoptimization:

Periodic FRR Promotion:

Periodic auto-bw collection:

SR tunnel max label push: every 3600 seconds, next in 406 seconds

Not Running every 300 seconds, next in 107 seconds

13 labels

P2P TUNNELS/LSPs:

TUNNEL NAME

R1_t1

R1_t2

R1_t3

R1_t10

SBFD tunnel

SBFD Session configured: 1

DESTINATION

66.66.66.66

33.33.33.33

UP IF

SBFD sessions UP: 1

DOWN IF

STATE/PROT up/down up/up up/up up/up up/up

BGP Dynamic Segment Routing Traffic Engineering

Border Gateway Protocol (BGP) has become a popular choice as a routing protocol in Data Center (DC) network. The ability to setup Segment Routing-Traffic Engineering (SR-TE) path initiated by BGP simplifies

DC network operation.

Segment Routing Configuration Guide

Segment Routing Traffic Engineering

Restrictions for Segment Routing –Traffic-Engineering Dynamic BGP

Restrictions for Segment Routing –Traffic-Engineering Dynamic BGP

• For Anycast SID support to work BGP-TE should be configured with the prepend feature.

• In the case of BGP Dynamic SR-TE if SR-TE fails, forwarding gets broken.

Information About Segment Routing –Traffic-Engineering Dynamic BGP

In BGP dynamic SR-TE, the label Switched Path (LSP) is enabled on demand when defined criteria and policies are met and that is the key difference between manually enabled SR-TE and BGP dynamic SR-TE.

Policies, for example, low latency path, minimum cost path, and so on are carried via BGP and matches on a given customer prefix. SR-TE tunnel used for L3VPN or Virtual Private LAN Services (VPLS) using BGP for auto-discovery and signaling is referred to as BGP-TE Dynamic.

BGP SR-TE dynamic assumes the on-demand auto-tunnel resides in single IGP domain. In this case path computation is done via IGP. SR-TE auto-tunnel created based on the request from BGP is a dynamic SR-TE tunnel. In other words, tunnel path information, or label stack, is computed based on the BGP next-hop and

TE attribute configuration. BGP dynamic SR-TE functions to trigger an On-demand LSP (auto-tunnel). The functions include:

• Tag customer prefixes (IPv4 or L3VPN VRF) using communities (community list) via route map configuration.

• Associate each community with a TE attribute-set or profile.

SR-TE profile is locally configured in attribute-set to define certain SR-TE parameters, for example, latency, disjoint path and so on. Once the BGP customer prefixes are mapped to an SR-TE-profile, a tunnel is dynamically created (auto-tunnel or On demand Label Switched Path (LSP)) using the parameters defined in the attribute-set, for each specified BGP next-hop and attribute-set pair associated with the prefixes. A binding

SID is associated with each SR-TE auto-tunnel and passed to BGP. The binding SID or binding label is installed into Routing Information Base (RIB) and Forwarding Information Base (FIB). FIB resolves BGP path via the binding SID or binding label, which forwards over the On demand SR-TE auto-tunnel. The binding-SID is also used to steer the customer traffic over the SR-TE LSP.

It must be noted that BGP only carries the SR-TE policy in this case, while path computation is done via IGP in a single IGP domain. In a single IGP domain the headend node has full visibility of the end to end path and

Segment Routing Configuration Guide

Segment Routing Traffic Engineering

How to Configure TE Label Switched Path Attribute-Set

the topology engineering database (Traffic Engineering Database or TED). Also it is assumed with BGP

Dynamic SR-TE that all the nodes reside within single AS and single IGP domain.

Figure 6: BGP-TE Dynamic Workflow

The above figure depicts the workflow for BGP-TE dynamic using multiple routing domains use case:

Customer premise equipment 2 (CPE) sends BGP update for Prefix-X and adds LL community, for example,

100:333.

AC1 announces a VPN route for prefix X with LL community.

After receiving BGP update of the VPN route matching community LL, ToR1 sends a request to PCE controller for LSP path towards AC1 with low latency TE policy.

Path calculation element (PCE) controller replies with a label stack, for example, 17003, 1600.

ToR1 creates SR-TE auto-tunnel and installs the route for Prefix-X in VRF of this VPN.

TE Label Switched Path Attribute-Set

TE-LSP attribute-set is used to configure the properties of a LSP. It describes TE profile or policy such as bandwidth, affinities inclusion and exclusion, links/nodes/SRLG inclusion and exclusion, metrics, path disjoint degree and group, and so on that are used to create an auto-tunnel.

How to Configure TE Label Switched Path Attribute-Set

Configuring TE Label Switched Path Attribute-Set

You can use the command mpls traffic-eng lsp attribute <name> to configure TE-LSP attribute. The following options are available:

Mpls traffic-eng lsp attribute name affinity Specify attribute flags for links comprising LSP lockdown priority

Lockdown the LSP--disable reoptimization

Specify LSP priority

Segment Routing Configuration Guide

Segment Routing Traffic Engineering

Segment Routing-Traffic Engineering On-Demand Next Hop

TE-LSP attribute command can be extended to support configuration for the two options pce and path-selection.

It can be configured as following: mpls traffic-eng lsp attribute name <test> path-selection metric <te/igp> invalidation <time-out> <drop/tear> segment-routing adjacency <protected/unprotected>

• If pce option is set in the TE attribute the dynamic path is calculated by PCE. Otherwise, the path is calculated locally by TE PCALC (path-calculation) entity. In the later case, IGP has to be configured and the BGP next-hop has to be both advertised by IGP and reachable from the local node over an IGP route.

• The option path-selection metric indicates whether the path calculation is based on TE metrics or IGP metrics. If this option is not configured the global value configured under mpls traffic-eng path-selection metric is used.

• The option path-selection invalidation configures the behavior of how an LSP reacts to soft failure from network. When an LSP path has a protected path from IGP against a link or node failure, the failure to the link or node is considered as soft failure.

• The option path-selection segment-routing adjacency indicates whether to choose an adjacency-SID with or without IGP protection when calculating LSP label stack.

• The option pce disjoint-path indicates the tunnel LSP is a member of disjoint-path group. Any LSPs within the same disjoint-path group do not traverse the same resources, such as links, nodes, or SRLG, in its path. This is used to create two or more tunnel LSPs with disjoint paths.

For BGP-TE Dynamic, a TE attribute name is associated with a BGP route-map set extension as following: route-map <name> match community <name> set attribute-set <name>

BGP uses the attribute-set <name> string together with its BGP next-hop to request a SR-TE auto-tunnel.

Segment Routing-Traffic Engineering On-Demand Next Hop

When redistributing routing information across domains, provisioning of multi-domain services (L2VPN &

L3VPN) has its own complexity and scalability issues. On-Demand Next Hop (ODN) triggers delegation of computation of an end-to-end LSP to a PCE controller including constraints and policies without doing any redistribution. It then installs the replied multi-domain LSP for the duration of the service into the local forwarding information base (FIB).

Restrictions for Segment Routing On Demand Next Hops - L3/L3VPN

• ODN anycast SID is not supported.

• ODN for IPv6 is not supported.

Segment Routing Configuration Guide

Segment Routing Traffic Engineering

Information About Segment Routing On Demand Next Hops - L3/L3VPN

Information About Segment Routing On Demand Next Hops - L3/L3VPN

On Demand Next hop leverages upon BGP Dynamic SR-TE capabilities and adds the path computation (PCE) ability to find and download the end to end path based on the requirements. ODN triggers an SR-TE auto-tunnel based on the defined BGP policy. As shown in the below figure, an end to end path between ToR1 and AC1 can be established from both ends based on low latency or other criteria for VRF (L3VPN) or IPv4 services.

The work-flow for ODN is summarized as follows:

Figure 7: ODN Operation

PCE controller collects topology and SIDs information via BGP Link State (BGP-LS). For more information

BGP-LS, refer BGP Link-State .

If NSO controller is enable, it configures L3VPN VRF or IPv4 prefixes and requests are sent to ToR1 and

AC1.

ToR1 and AC1 checks if a LSP towards each other exists. If not, a request is sent to the PCE controller to compute that SR-TE path that matches SR-TE policy that is carried via BGP.

PCE controller computes the path and replies with a label stack (18001, 18002, 16001, example in ToR1).

ToR1 and AC1 create a SR-TE auto-tunnel and reply back to the NSO controller indicating that the LSP for VRF or IPv4 is up and operational.

Fast Convergence Default Optimize

The fast convergence default optimize feature modifies the default settings of all the protocols to recommended defaults for fast convergence. To revert the defaults to pre-fast-convergence settings for both IS-IS and OSPF,

routing-default-optimize command is used. This command sends signals to IS-IS and OSPF and modifies the default configuration for these protocols.

By default, the fast convergence settings is enabled which means when you upgrade the software, you can automatically see the new behavior. This makes easier integration of the devices in a multi-vendor deployment and reduces support cases for poor convergence.

Segment Routing Configuration Guide

Segment Routing Traffic Engineering

Information About Segment Routing On Demand Next Hops - L3/L3VPN

When default optimize is disabled, existing protocol default configuration is used. When default optimize is enabled, new protocol defaults are used. The show running configurations does not display configuration lines for default settings even when default settings are being used.

A configuration of a protocol overrides the default, but a change to default optimize does not override any configuration.

The following is the sample output of spf-interval command in IS-IS:

Device(config-if)# router isis

Device(config-router)# spf-interval 10 5500 5500

If a non-default value is configured, it will be displayed in show running configuration output:

Device(config-router)# spf-interval 5 50 200

Device(config-router)# do show run | inc spf-interval spf-interval 5 50 200

You can revert to the default values by configuring the default values or by removing the non-default configuration.

Default Optimize Values for IS-IS

The following table summarizes the configuration impacted by default optimize:

IS-IS command

fast-flood

Parameters Default optimize disabled Default optimize enabled

# of lsps flooded back-back

Disabled 10 spf-interval

Initial (milliseconds) 5500

Secondary (milliseconds) 5500 max (seconds) 10

200

5 prc-interval

Initial (milliseconds) max (seconds)

2000

Secondary (milliseconds) 5000

200

5 lsp-gen-interval

Initial (milliseconds) 50

Secondary (milliseconds) 5000

200

Segment Routing Configuration Guide

Segment Routing Traffic Engineering

Information About Segment Routing On Demand Next Hops - L3/L3VPN

IS-IS command

log-adjacency-changes

Parameters

max (seconds)

Default optimize disabled Default optimize enabled

5 5 disabled enabled

Default Optimize Values for OSPF

The following table summarizes the configuration impacted by default optimize for OSPFv2/v3:

OSPF command

timers throttle spf

Parameters Default optimize disabled Default optimize enabled

Initial (milliseconds) max (milliseconds)

5000

Secondary (milliseconds) 10000

200

5 timers throttle lsa all

Initial (milliseconds) max (milliseconds)

Secondary (milliseconds) 5000

200

5 timers lsa arrival milliseconds 1000 100

The following is the sample output of show ip ospf command for OSPFv2 with the default-optimize values.

Device#

show ip ospf

Routing Process "ospf 10" with ID 1.1.1.1

Start time: 00:00:01.471, Time elapsed: 03:00:34.706

Supports only single TOS(TOS0) routes

Supports opaque LSA

Supports Link-local Signaling (LLS)

Supports area transit capability

Supports NSSA (compatible with RFC 3101)

Supports Database Exchange Summary List Optimization (RFC 5243)

Event-log enabled, Maximum number of events: 1000, Mode: cyclic

Router is not originating router-LSAs with maximum metric

Initial SPF schedule delay 50 msecs

Minimum hold time between two consecutive SPFs 200 msecs

Maximum wait time between two consecutive SPFs 5000 msecs

Incremental-SPF disabled

Initial LSA throttle delay 50 msecs

Minimum hold time for LSA throttle 200 msecs

Maximum wait time for LSA throttle 5000 msecs

Minimum LSA arrival 100 msecs

Segment Routing Configuration Guide

Segment Routing Traffic Engineering

Information About Segment Routing On Demand Next Hops - L3/L3VPN

LSA group pacing timer 240 secs

Interface flood pacing timer 33 msecs

Retransmission pacing timer 66 msecs

EXCHANGE/LOADING adjacency limit: initial 300, process maximum 300

Number of external LSA 18. Checksum Sum 0x075EB2

Number of opaque AS LSA 0. Checksum Sum 0x000000

Number of DCbitless external and opaque AS LSA 0

Number of DoNotAge external and opaque AS LSA 0

Number of areas in this router is 1. 1 normal 0 stub 0 nssa

Number of areas transit capable is 0

External flood list length 0

IETF NSF helper support enabled

Cisco NSF helper support enabled

Reference bandwidth unit is 100 mbps

Area BACKBONE(0)

Number of interfaces in this area is 4 (2 loopback)

Area has RRR enabled

Area has no authentication

SPF algorithm last executed 02:27:23.736 ago

SPF algorithm executed 20 times

Area ranges are

Number of LSA 94. Checksum Sum 0x321DCF

Number of opaque link LSA 0. Checksum Sum 0x000000

Number of DCbitless LSA 0

Number of indication LSA 0

Number of DoNotAge LSA 0

Flood list length 0

The following is the sample output of show ospf command for OSPFv3 with the default-optimize values.

Device#

show ospfv3

OSPFv3 10 address-family ipv6

Router ID 11.11.11.11

Supports NSSA (compatible with RFC 3101)

Supports Database Exchange Summary List Optimization (RFC 5243)

Event-log enabled, Maximum number of events: 1000, Mode: cyclic

Router is not originating router-LSAs with maximum metric

Initial SPF schedule delay 50 msecs

Minimum hold time between two consecutive SPFs 200 msecs

Maximum wait time between two consecutive SPFs 5000 msecs

Initial LSA throttle delay 50 msecs

Minimum hold time for LSA throttle 200 msecs

Maximum wait time for LSA throttle 5000 msecs

Minimum LSA arrival 100 msecs

LSA group pacing timer 240 secs

Interface flood pacing timer 33 msecs

Retransmission pacing timer 66 msecs

Retransmission limit dc 24 non-dc 24

EXCHANGE/LOADING adjacency limit: initial 300, process maximum 300

Number of external LSA 0. Checksum Sum 0x000000

Number of areas in this router is 1. 1 normal 0 stub 0 nssa

Graceful restart helper support enabled

Reference bandwidth unit is 100 mbps

RFC1583 compatibility enabled

Area BACKBONE(0)

Number of interfaces in this area is 2

SPF algorithm executed 7 times

Number of LSA 3. Checksum Sum 0x012426

Number of DCbitless LSA 0

Number of indication LSA 0

Number of DoNotAge LSA 0

Flood list length 0

Segment Routing Configuration Guide

Segment Routing Traffic Engineering

How to Configure Segment Routing On Demand Next Hops - L3/L3VPN

How to Configure Segment Routing On Demand Next Hops - L3/L3VPN

Configuring Segment Routing On Demand Next Hops - L3/L3VPN

Perform the following steps to configure on-demand next hop for SR-TE. The below figure is used as a reference to explain the configuration steps.

Figure 8: ODN Auto-Tunnel Setup

Configure the router (R6 tail end) with VRF interface.

interface GigabitEthernet0/2/2 vrf forwarding sr ip address 10.0.0.1 255.0.0.0

negotiation auto interface Loopback0 ip address 192.168.0.1 255.255.0.0

ip router isis 1

Tags VRF prefix with BGP community on R6 (tail end).

route-map BGP_TE_MAP permit 9 match ip address traffic set community 3276850 ip access-list extended traffic permit ip 10.0.0.1 255.255.0.0 any

Enable BGP on R6 (tail end) and R1 (head end) to advertise and receive VRF SR prefix and match on community set on R6 (tail end).

router bgp 100 bgp router-id 172.16.0.1

bgp log-neighbor-changes bgp graceful-restart no bgp default ipv4-unicast neighbor 10.0.0.2 remote-as 100 neighbor 10.0.0.2 update-source Loopback0

Segment Routing Configuration Guide

How to Configure Segment Routing On Demand Next Hops - L3/L3VPN

address-family ipv4 neighbor 10.0.0.2 activate neighbor 10.0.0.2 send-community both neighbor 10.0.0.2 next-hop-self exit-address-family address-family vpnv4 neighbor 10.0.0.2 activate neighbor 10.0.0.2 send-community both neighbor 10.0.0.2 route-map BGP_TE_MAP out exit-address-family address-family link-state link-state neighbor 10.0.0.2 activate exit-address-family address-family ipv4 vrf sr redistribute connected exit-address-family route-map BGP_TE_MAP permit 9 match ip address traffic set community 3276850 ip access-list extended traffic permit ip 10.0.0.1 255.255.0.0 any router bgp 100 bgp router-id 192.168.0.2

bgp log-neighbor-changes bgp graceful-restart no bgp default ipv4-unicast neighbor 10.0.0.2 remote-as 100 neighbor 10.0.0.2 update-source Loopback0 address-family ipv4 neighbor 10.0.0.2 activate neighbor 10.0.0.2 send-community both neighbor 10.0.0.2 next-hop-self exit-address-family address-family vpnv4 neighbor 10.0.0.2 activate neighbor 10.0.0.2 send-community both neighbor 10.0.0.2 route-map BGP_TE_MAP in exit-address-family address-family link-state link-state neighbor 10.0.0.2 activate exit-address-family address-family ipv4 vrf sr redistribute connected exit-address-family route-map BGP_TE_MAP permit 9 match community 1 set attribute-set BGP_TE5555 ip community-list 1 permit 3276850 mpls traffic-eng lsp attributes BGP_TE5555 path-selection metric igp pce

Enable route-map/attribute set on headend (R1).

route-map BGP_TE_MAP permit 9 match community 1

Segment Routing Configuration Guide

Segment Routing Traffic Engineering

How to Configure Segment Routing On Demand Next Hops - L3/L3VPN

set attribute-set BGP_TE5555 ip community-list 1 permit 3276850 mpls traffic-eng lsp attributes BGP_TE5555 path-selection metric igp pce end

Enable PCE and auto-tunnel configurations on R1.

mpls traffic-eng tunnels mpls traffic-eng pcc peer 10.0.0.3 source 10.0.0.4 precedence 255 mpls traffic-eng auto-tunnel p2p tunnel-num min 2000 max 5000

Enable all core links with SR-TE configurations and ensure that they are enabled as point to point interfaces.

mpls traffic-eng tunnels interface GigabitEthernet0/2/0 ip address 101.102.6.1 255.255.255.0

ip router isis 1 mpls traffic-eng tunnels isis network point-to-point interface GigabitEthernet0/3/1 vrf forwarding sr ip address 101.107.3.1 255.255.255.0

negotiation auto end

Enable R3 (RR) to advertise TED to the PCE server via BGP-LS.

router isis 1 net 49.0002.0000.0000.0003.00

ispf level-1-2 metric-style wide nsf cisco nsf interval 0 distribute link-state segment-routing mpls segment-routing prefix-sid-map advertise-local redistribute static ip level-1-2 mpls traffic-eng router-id Loopback0 mpls traffic-eng level-1 mpls traffic-eng level-2 router bgp 100 bgp router-id 10.0.0.2

bgp log-neighbor-changes bgp graceful-restart no bgp default ipv4-unicast neighbor 10.0.0.3 remote-as 100 neighbor 10.0.0.3 update-source Loopback0 address-family ipv4 neighbor 10.0.0.3 activate exit-address-family

Enable PCE server configuration and verify BGP-LS session is properly established with RR.

Device# sh bgp li li summary

BGP router identifier 10.0.0.3, local AS number 100

BGP generic scan interval 60 secs

Non-stop routing is enabled

BGP table state: Active

Table ID: 0x0 RD version: 1436

BGP main routing table version 1436

BGP NSR Initial initsync version 1 (Reached)

BGP NSR/ISSU Sync-Group versions 0/0

Segment Routing Configuration Guide

Segment Routing Traffic Engineering

Verifying Segment Routing On Demand Next Hops - L3/L3VPN

BGP scan interval 60 secs

BGP is operating in STANDALONE mode.

Process

Speaker

RcvTblVer bRIB/RIB LabelVer ImportVer SendTblVer StandbyVer

1436 1436 1436 1436 1436

Neighbor

10.0.0.2

103

Spk

AS MsgRcvd

100 19923

MsgSent

Device# sh pce ipv4 topo | b Node 3

Node 3

TE router ID: 10.0.0.2

Host name: R3

ISIS system ID: 0000.0000.0003 level-1

TblVer

17437

InQ

1436

OutQ Up/Down

0 0

St/PfxRcd

1w2d

ISIS system ID: 0000.0000.0003 level-2

Prefix SID:

Prefix 10.0.0.2, label 20011 (regular)

Verifying Segment Routing On Demand Next Hops - L3/L3VPN

The ODN verifications are based on L3VPN VRF prefixes.

Verify that PCEP session between R1 (headend and PCE server) is established.

Device# sh pce client peer

PCC's peer database:

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

Peer address: 10.0.0.3 (best PCE)

State up

Capabilities: Stateful, Update, Segment-Routing

Verify that PCEP session is established between all the peers (PCCs).

Device# sh pce ipv4 peer

PCE's peer database:

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

Peer address: 10.0.0.4

State: Up

Capabilities: Stateful, Segment-Routing, Update

Peer address: 172.16.0.5

State: Up

Capabilities: Stateful, Segment-Routing, Update

Verify that R1 (headend) has no visibility to R6 loopback address.

Device# sh ip route 192.168.0.1

% Network not in table

Verify that VRF prefix is injected via MP-BGP in R1 VRF SR routing table.

Device# sh ip route vrf sr

Routing Table: sr

Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP

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 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP a - application route

+ - replicated route, % - next hop override, p - overrides from PfR

Gateway of last resort is not set

10.0.0.6/8 is variably subnetted, 2 subnets, 2 masks

10.0.0.7/24 is directly connected, GigabitEthernet0/3/1

10.0.0.7/32 is directly connected, GigabitEthernet0/3/1

10.0.0.8/24 is subnetted, 1 subnets

10.0.0.9 [200/0] via binding label: 865, 4d21h

Segment Routing Configuration Guide

Segment Routing Traffic Engineering

Verifying Segment Routing On Demand Next Hops - L3/L3VPN

Verify that BGP is associating properly the policy and binding SID with the VRF prefix.

Device# sh ip bgp vpnv4 vrf sr 106.107.4.0

BGP routing table entry for 100:100:106.107.4.0/24, version 3011

Paths: (1 available, best #1, table sr)

Not advertised to any peer

Refresh Epoch 4

Local

192.168.0.1 (metric 10) (via default) from 10.0.0.2 (10.0.0.2)

Origin incomplete, metric 0, localpref 100, valid, internal, best

Community: 3276850

Extended Community: RT:100:100

Originator: 192.168.0.1, Cluster list: 10.0.0.2

mpls labels in/out nolabel/1085 binding SID: 865 (BGP_TE5555) rx pathid: 0, tx pathid: 0x0

Verify binding label association with VRF prefix.

Device# sh ip route vrf sr 106.107.4.0

Routing Table: sr

Routing entry for 106.107.4.0/24

Known via "bgp 100", distance 200, metric 0, type internal

Routing Descriptor Blocks:

* Binding Label: 865, from 10.0.0.2, 4d22h ago

Route metric is 0, traffic share count is 1

AS Hops 0

MPLS label: 1085

MPLS Flags: NSF

Verify that VRF prefix is forwarded via ODN auto-tunnel.

Device# sh ip cef label-table

Label Next Hop

865 no route attached

Interface

Tunnel2000

Device# sh ip cef vrf sr 106.107.4.0 detail

10.0.0.8/24, epoch 15, flags [rib defined all labels] recursive via 865 label 1085 attached to Tunnel2000

Verify ODN auto-tunnel status.

Device# sh mpls traffic-eng tunnels

P2P TUNNELS/LSPs:

(Tunnel2000) Destination: 192.168.0.1 Ifhandle: 0x6F5 Name: R1_t2000

(auto-tunnel for BGP TE)

Status:

Admin: up

2000

Oper: up Path: valid Signalling: connected--auto-tunnel path option 1, (SEGMENT-ROUTING) (PCE) type dynamic (Basis for Setup, path weight

10)

Config Parameters:

Bandwidth: 0 kbps (Global) Priority: 7 7 Affinity: 0x0/0xFFFF

Metric Type: IGP (interface)

Path Selection:

Protection: any (default)

Path-selection Tiebreaker:

Global: not set Tunnel Specific: not set Effective: min-fill (default)

Hop Limit: disabled

Cost Limit: disabled

Path-invalidation timeout: 10000 msec (default), Action: Tear

AutoRoute: disabled LockDown: disabled Loadshare: 0 [0] bw-based auto-bw: disabled

Attribute-set: BGP_TE5555--attribute-set

Fault-OAM: disabled, Wrap-Protection: disabled, Wrap-Capable: No

Active Path Option Parameters:

State: dynamic path option 1 is active

BandwidthOverride: disabled LockDown: disabled Verbatim: disabled

PCEP Info:

Delegation state: Working: yes Protect: no

Working Path Info:

Segment Routing Configuration Guide

Segment Routing Traffic Engineering

Verifying Segment Routing On Demand Next Hops - L3/L3VPN

Request status: processed

Created via PCRep message from PCE server: 10.0.0.3-via PCE server

PCE metric: 30, type: IGP

Reported paths:

Tunnel Name: Tunnel2000_w

LSPs:

LSP[0]: source 10.0.0.4, destination 192.168.0.1, tunnel ID 2000, LSP ID 1

State: Admin up, Operation active

Binding SID: 865

Setup type: SR

Bandwidth: requested 0, used 0

LSP object:

PLSP-ID 0x807D0, flags: D:0 S:0 R:0 A:1 O:2

Metric type: IGP, Accumulated Metric 0

ERO:

SID[0]: Adj, Label 2377, NAI: local 101.102.6.1 remote 10.0.0.10

History:

Tunnel:

SID[1]: Unspecified, Label 17, NAI: n/a

SID[2]: Unspecified, Label 20, NAI: n/a

Time since created: 4 days, 22 hours, 21 minutes

Time since path change: 4 days, 22 hours, 21 minutes

Number of LSP IDs (Tun_Instances) used: 1

Current LSP: [ID: 1]

Uptime: 4 days, 22 hours, 21 minutes

Tun_Instance: 1

Segment-Routing Path Info (isis level-1)

Segment0[Link]: 101.102.6.1 - 10.0.0.10, Label: 2377

Segment1[ - ]: Label: 17

Segment2[ - ]: Label: 20

Verify ODN auto-tunnel LSP status on R1 (headend).

Device# sh pce client lsp brief

PCC's tunnel database:

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

Tunnel Name: Tunnel2000_w

LSP ID 1

Tunnel Name: Tunnel2000_p

R1# sh pce client lsp detail

PCC's tunnel database:

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

Tunnel Name: Tunnel2000_w

LSPs:

LSP[0]: source 10.0.0.4, destination 192.168.0.1, tunnel ID 2000, LSP ID 1

State: Admin up, Operation active

Binding SID: 865

Setup type: SR

Bandwidth: requested 0, used 0

LSP object:

PLSP-ID 0x807D0, flags: D:0 S:0 R:0 A:1 O:2

Metric type: IGP, Accumulated Metric 0

ERO:

SID[0]: Adj, Label 2377, NAI: local 101.102.6.1 remote 10.0.0.10

SID[1]: Unspecified, Label 17, NAI: n/a

SID[2]: Unspecified, Label 20, NAI: n/a

Verify ODN LSP status on the PCE server.

Device# sh pce lsp summ

PCE's LSP database summary:

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

All peers:

Number of LSPs:

Operational: Up:

Admin state: Up:

Setup type: RSVP:

1 Down:

0 Segment routing:

Segment Routing Configuration Guide

Segment Routing Traffic Engineering

Verifying Segment Routing On Demand Next Hops - L3/L3VPN

Peer 10.0.0.4:

Number of LSPs:

Operational: Up:

Admin state: Up:

Setup type: RSVP:

1 Down:

0 Segment routing:

Verify detailed LSP information on the PCE server.

Device# sh pce lsp det

PCE's tunnel database:

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

PCC 10.0.0.4:

Tunnel Name: Tunnel2000_w

LSPs:

LSP[0]: source 10.0.0.4, destination 192.168.0.1, tunnel ID 2000, LSP ID 48

State: Admin up, Operation active

Binding SID: 872

PCEP information: plsp-id 526288, flags: D:1 S:0 R:0 A:1 O:2

Reported path:

Metric type: IGP, Accumulated Metric 0

SID[0]: Adj, Label 885, Address: local 10.0.0.9 remote 10.0.0.10

SID[1]: Unknown, Label 17,

SID[2]: Unknown, Label 20,

Computed path:

Computed Time: Tue Dec 20 13:12:57 2016 (00:11:53 ago)

Metric type: IGP, Accumulated Metric 30

SID[0]: Adj, Label 885, Address: local 10.0.0.9 remote 10.0.0.10

SID[1]: Adj, Label 17, Address: local 10.0.0.12 remote 10.0.0.13

SID[2]: Adj, Label 20, Address: local 10.0.0.14 remote 10.0.0.14

Recorded path:

None

Shutdown the interface that is connected to VRF SR so that the prefix is no longer advertised by MP-BGP.

Device# int gig0/2/2

Device(config-if)#shut

Verify that VRF prefix is no longer advertised to R1 (headend) via R6 (tailend).

Device# sh ip route vrf sr

Routing Table: sr

Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

+ - replicated route, % - next hop override, p - overrides from PfR

Gateway of last resort is not set

10.0.0.6/8 is variably subnetted, 2 subnets, 2 masks

10.0.0.7/24 is directly connected, GigabitEthernet0/3/1

10.0.0.8/32 is directly connected, GigabitEthernet0/3/1

Verify that no ODN auto-tunnel exists.

Device# sh mpls traffic-eng tunnels

P2P TUNNELS/LSPs:

P2MP TUNNELS:

P2MP SUB-LSPS:

Segment Routing Configuration Guide

Segment Routing Traffic Engineering

Additional References for Segment Routing Traffic Engineering

Additional References for Segment Routing Traffic Engineering

Related Documents

Related Topic

Cisco IOS Commands

Document Title

Cisco IOS Master Command List, All Releases

Technical Assistance

Description Link

The Cisco Support website provides extensive online resources, including documentation and tools for troubleshooting and resolving technical issues with

Cisco products and technologies.

http://www.cisco.com/cisco/web/support/index.html

To receive security and technical information about your products, you can subscribe to various services, such as the Product Alert Tool (accessed from Field

Notices), the Cisco Technical Services Newsletter, and Really Simple Syndication (RSS) Feeds.

Access to most tools on the Cisco Support website requires a Cisco.com user ID and password.

Feature Information for Segment Routing -Traffic Engineering

Use Cisco Feature Navigator to find information about platform support and Cisco software image support.

To access Cisco Feature Navigator, go to www.cisco.com/go/cfn . An account on Cisco.com is not required.

Table 3: Feature Information for Segment Routing -Traffic Engineering

Feature Name

Segment Routing-Traffic

Engineering

Releases

Cisco IOS XE Everest 16.4.1

Feature Information

The following commands were introduced or modified:

mpls traffic-eng nsr, show mpls

traffic-eng tunnels tunnel1, show

isis fast-reroute ti-lfa tunnel,

show frr-manager client client-name ISIS interfaces

detail, show ip cef 6.6.6.6 internal

Segment Routing Configuration Guide

Segment Routing Traffic Engineering

Feature Information for Segment Routing -Traffic Engineering

Feature Name

Segment Routing

–Traffic-Engineering Dynamic

BGP

Releases

Cisco IOS XE Everest 16.5.1b

Segment Routing On Demand Next

Hops - L3/L3VPN

Cisco IOS XE Everest 16.5.1b

Fast convergence support in

OSPFv2 and OSPFv3

Cisco IOS XE Everest 16.5.1b

Feature Information

In BGP dynamic SR-TE, the label

Switched Path (LSP) is enabled on demand when defined criteria and policies are met.

The following commands were introduced or modified:

mpls traffic-eng lsp attribute

name

On-Demand Next Hop (ODN) triggers delegation of computation of an end-to-end LSP to a PCE controller including constraints and policies without doing any redistribution.

The following commands were introduced or modified:

route-map BGP_TE_MAP

permit, mpls traffic-eng tunnels,

sh bgp li li summary, sh pce

client peer, sh pce ipv4 peer, sh

ip route vrf sr, sh ip bgp vpnv4

vrf sr, sh ip cef label-table, sh

mpls traffic-eng tunnels, sh pce

client lsp brief, sh pce lsp summ,

sh pce lsp det,

routing-default-optimize

The Routing Information Base

(RIB) enhancement supports route redistribution and On-Demand

Nexthop requirements.

No new commands were added or modified.

Segment Routing Configuration Guide

Segment Routing Traffic Engineering

Feature Information for Segment Routing -Traffic Engineering

Feature Name

On Demand LSP

Releases

Cisco IOS XE Everest 16.5.1b

Feature Information

SR TE On demand LSP feature will be used to transport the VPN services between the Metro access rings.

The following command was modified: mpls traffic-eng

auto-tunnel.

Segment Routing Configuration Guide

C H A P T E R

Using Segment Routing with IS-IS

We know that segment routing enables a node to select any path (explicit or derived from the computations of the internal gateway protocol’s shortest path). This path is not dependent on a hop-by-hop signaling technique (through LDP or RSVP), but on a set of segments that are advertised by a routing protocol, such as IS-IS or OSPF. These segments act as topological sub-paths that can be combined to form the desired path.

Segment Routing must be enabled before any IGP, such as IS-IS or OSPF, can configure segment routing functionality. Similarly, when segment routing is disabled, all IGP-related configuration is also disabled.

•

Restrictions for Using Segment Routing with IS-IS, page 69

•

Enabling Segment Routing, page 70

•

Enabling Segment Routing for IGPs, page 70

•

Prefix-SID Received in LSPs from Remote routers, page 71

•

Segment Routing Adjacency SID Advertisement, page 72

•

Segment Routing Mapping Server (SRMS), page 72

•

SRGB Range Changes, page 73

•

MPLS Forwarding on an Interface, page 74

•

Segment Routing and LDP Preference, page 74

•

Segment Routing-TE, page 74

•

RLFA LDP and SR, page 74

•

Topology-Independent LFA, page 75

•

Additional References, page 82

•

Feature Information for Using Segment Routing with IS-IS, page 82

Restrictions for Using Segment Routing with IS-IS

• Segment routing must be configured at the top level before any routing protocol configuration is allowed under its router configuration sub mode.

Segment Routing Configuration Guide

Using Segment Routing with IS-IS

Enabling Segment Routing

• IS-IS protocol SR command is based on per topology (IPv4 address family).

• Effective Cisco IOS-XE Release 3.16, ISIS supports segment routing for IPv4 only.

Enabling Segment Routing

There are two levels of configuration required to enable segment routing for a routing protocol instance. The top level segment routing configuration which is managed by segment routing infrastructure component enables segment routing, whereas, segment routing configuration at the router level enables segment routing for a specific address-family of a routing protocol instance.

There are three segment routing states:

• SR_NOT_CONFIGURED

• SR_DISABLED

• SR_ENABLED

Segment routing configuration under the IGPs is allowed only if the SR state is either SR_DISABLED or

SR_ENABLED. The SR_ENABLED state indicates that there is at least a valid SRGB range reserved through the MFI successfully.

Enabling Segment Routing for IGPs

You can enable segment routing for IGPs under the router configuration sub mode, through commands.

However, IGP segment routing are enabled only after the global SR is configured.

Note

IS-IS protocol SR command is based on per topology (IPv4 address family).

The SR_ENABLED is a necessary state for any protocol to enable SR, however, it is not a sufficient for enabling SR for a protocol instance. The reason being that the IS-IS still does not have any information about segment routing global block (SRGB) information. When the request to receive information about the SRGB is processed successfully, the IS-IS SR operational state is enabled

Segment Routing requires each router to advertise its segment routing data-plane capability and the range of

MPLS label values that are used for segment routing in the case where global SIDs are allocated.

Data-plane capabilities and label ranges are advertised using the SR-capabilities sub-TLV inserted into the

IS-IS Router Capability TLV-242 that is defined in RFC4971.

ISIS SR-capabilities sub TLV includes all reserved SRGB ranges. However, the Cisco implementation supports only one SRGB range.

The supported IPv4 prefix-SID sub TLV are TLV-135 and TLV-235.

Segment Routing Configuration Guide

Using Segment Routing with IS-IS

Configuring Segment Routing on IS-IS

Configuring Segment Routing on IS-IS

This section describes configuring segment routing IPV4 for IS-IS protocol under the router configuration sub mode.

[no] segment-routing mpls

Note

This command is allowed only when segment routing is configured at the top level.

The following is an example of configuring IS-IS segment routing:

segment-routing mpls router isis net

33.0001.0001.0001.00

metric-style wide segment-routing mpls passive-interface

Loopback2

Prefix-SID Received in LSPs from Remote routers

Prefix SIDs received in a label switched path (LSP) with a reachability TLV (TLV 135 and 235) are downloaded to the routing information base (RIB) if all of the following conditions are met:

• Segment routing is enabled for the topology and address-family

• Prefix-SID is valid

• The local label binding to MFI is successful.

For a prefix-SID received with reachability TLVs (TLV 135 and 235), the label is downloaded through RIB the same way as BGP downloads per prefix VPN labels.

If the path is a remote LFA path, ISIS downloads the path the same way it downloads it before adding the segment routing functionality but does not download any label with this path. This behavior ensures that remote LFA functionality is still supported using LDP.

Limitations

• For SIDs that do not fit in the specified SID range, labels are not used when updating the RIB. For cases, where SID does fit in the SID range, but does not fit the next-hop neighbor SID range, remote label associated with that path is not installed.

• Node SIDs received in an LSP with reachability TLVs (TLV 135 and 235) are downloaded to RIB only if segment routing is enabled under the corresponding address-family.

• In case of multiple best next hops, if not all next hops support segment routing, ISIS will treat this instance similar to when mismatched labels are assigned to the same prefix. That is, IS-IS ignores the labels and installs unlabeled paths for all ECMP paths into the global RIB.

Segment Routing Configuration Guide

Using Segment Routing with IS-IS

Segment Routing Adjacency SID Advertisement

Segment Routing Adjacency SID Advertisement

Effective with Cisco IOS-XE Release 3.17, IS-IS supports the advertisement of segment routing Adjacency

SID. An Adjacency Segment Identifier (Adj-SID) represents a router adjacency in Segment Routing.

A segment routing-capable router may allocate an Adj-SID for each of its adjacencies and an Adj-SID sub-TLV is defined to carry this SID in the Adjacency TLVs. IS-IS adjacencies are advertised using one of the

IS-Neighbor TLVs below:

• TLV-22 [RFC5305]

• TLV-23 [RFC5311]

IS-IS allocates the adjacency SID for each IS-IS neighbor only if the IS-IS adjacency state is up and IS-IS segment routing internal operational state is enabled. If an adjacency SID allocation failure is due to out-of-label resource, IS-IS retries to allocate the Adj-SID periodically in a default interval (30 seconds).

Multiple Adjacency-SIDs

Effective with Cisco IOS-XE Release 3.18, multiple adjacency-SIDs are supported. For each protected

P2P/LAN adjacency, IS-IS allocates two Adj-SIDs. The backup Adj-SID is only allocated and advertised when FRR (local LFA) is enabled on the interface. If FRR is disabled, then the backup adjacency-SID is released. The persistence of protected adj-SID in forwarding plane is supported. When the primary link is down, IS-IS delays the release of its backup Adj-SID until the delay timer expires. This allows the forwarding plane to continue to forward the traffic through the backup path until the router is converged.

Cisco IOS-XE Release 3.18, IS-IS Adj-SID is changed to be per level based since the forwarding plane is unaware of protocol-specific levels. The allocated and advertised backup Adj-SIDs can be displayed in the output of show isis neighbor detail and show isis data verbose commands.

Segment Routing Mapping Server (SRMS)

Segment Routing Mapping Server (SRMS) allows configuration and maintenance of the Prefix-SID mapping policy entries. Effective with Cisco IOS-XE Release 3.17, the IGPs use the active policy of the SRMS to determine the SID values when programming the forwarding plane.

The SRMS provides prefixes to SID/Label mapping policy for the network. IGPs, on the other hand, are responsible for advertising prefixes to SID/Label mapping policy through the Prefix-SID/Label Binding TLV.

Active policy information and changes are notified to the IGPs, which use active policy information to update forwarding information.

Connected Prefix SIDs

Sometimes, a router may install a prefix with a SID that is different than what it advertises to the LSP. For example, if more than one protocol or more than one IGP instance is announcing the same prefix with different

SIDs to the SRMS, the SRMS resolves the conflict and announces the winning prefix and SID that may not be the same as the local instance. In that case, the IGP always advertises what it learns from its source LSP although it still tries to install the SID which may be different than what it learns in its LSP. This is done to prevent the IGP from redistributing the SIDs from another protocol or another protocol instance.

Segment Routing Configuration Guide

Using Segment Routing with IS-IS

Configuring IS-IS SRMS

Configuring IS-IS SRMS

The following command enables the IS-IS SRMS and allows IS-IS to advertise local mapping entries. IS-IS does not send remote entries to the SRMS library. However, IS-IS uses the SRMS active policy, which is computed based only on the locally configured mapping entries.

[no] segment-routing prefix-sid-map advertise-local

Configuring IS-IS SRMS Client

By default, the IS-IS SRMS client mode is enabled. IS-IS always sends remote prefix-sid-mapping entries received through LSP, to SRMS. The SRMS active policy is calculated based on both, local and remote mapping entries.

The following command disables the prefix-sid-mapping client functionality.

segment-routing prefix-sid-map receive [disable]

This command is configured on the receiver side.

Configuring ISIS SID Binding TLV Domain Flooding

By default, the IS-IS SRMS server does not flood SID binding entries within the routing domain. In Cisco

IOS-XE Release 3.18, the optional keyword domain-wide in the IS-IS SRMS server mode command to enable the SID and Label binding TLV flooding functionality.

segment-routing prefix-sid-map advertise-local [domain-wide]

The domain-wide keyword enables the IS-IS SRMS server to advertise SID binding TLV across the entire routing domain.

Note

The option is valid only if IS-IS SRMS performs in the SRMS server mode.

SRGB Range Changes

When IS-IS segment routing is configured, IS-IS must request an interaction with the SRGB before IS-IS SR operational state can be enabled. If no SRGB range is created, IS-IS will not be enabled.

When an SRGB change event occurs, IS-IS makes the corresponding changes in its sub-block entries. IS-IS also advertises the newly created or extended SRGB range in SR-capabilities sub-TLV and updates the prefix-sid sub TLV advertisement.

Note

In Cisco IOS-XE Release 3.16 only one SRGB range and SRGB extension for the modification are supported.

Segment Routing Configuration Guide

Using Segment Routing with IS-IS

SRGB Deletion

SRGB Deletion

When IS-IS receives an SRGB deletion event, it looks for an SRGB entry in the IS-IS SRGB queue list. If an

SRGB entry does not exist, IS-IS makes sure that there is no pending SRGB created event. If a pending SRGB creation event is found, then IS-IS removes the SRGB creation event, and completes the SRGB delete processing,

If an SRGB entry is found in the IS-IS SRGB queue, IS-IS locks the SRGB, redistributes the RIBs and un-advertises all prefixed-SIDs that have SID value within the pending delete SRGB range, and un-advertises the SRGB range from SR-capabilities sub TLV. Once IS-IS has completed the SRGB deletion processing, it unlocks the SRGB and deletes the SRGB from its SR sub-block entry.

If there is no valid SRGB after the deletion of the SRGB, IS-IS SR operational state becomes disabled.

MPLS Forwarding on an Interface

MPLS forwarding must be enabled before segment routing can use an interface. IS-IS is responsible for enabling MPLS forwarding on an interface.

When segment routing is enabled for a IS-IS topology, or IS-IS segment routing operational state is enabled,

IS-IS enables MPLS for any interface on which the IS-IS topology is active. Similarly, when segment routing is disabled for a IS-IS topology, IS-IS disables the MPLS forwarding on all interfaces for that topology.

Segment Routing and LDP Preference

In Cisco IOS-XE Release 3.16, the command sr-prefer is used to tell the forwarding interface to prefer using segment routing labels over LDP labels for all prefixes in a topology.

Segment Routing-TE

Segment Routing Traffic Engineering requires the IGP to provide segment routing related information to TE.

The information includes SRGB, Adjacency-SID, Prefix-SID, primary and repair paths for all nodes in the topology.

Enabling and Disabling SR-TE Announcements

IS-IS announces the SR information to TE when it detects that both, IS-IS SR and TE are enabled for at least one level. IS-IS announce only the information that is obtained from the level for which TE is configured.

Similarly, IS-IS instructs TE to delete all announcements when it detects that SR is not enabled or TE is no longer configured on any level.

RLFA LDP and SR

Consider the following topology.

Segment Routing Configuration Guide

Using Segment Routing with IS-IS

Topology-Independent LFA

Ge0/1

A------------------E-------------------------------------------------D (SID1)

| Ge0/0

B------------------(F------------------------C (PQ with SID2)----

The traffic flows from A to D. The primary path is A-E-D and the primary next hop interface is Ge0/1. The secondary path is A-B-F-C-D, and C is the PQ node. The repair tunnel ends at PQ node C. The existing RLFA uses LDP TE tunnel for the repair path. When both LDP and SR are enabled, the LDP tunnel is used for RLFA repair path by default unless the segment routing preferred is configured through the sr-prefer command.

Topology-Independent LFA

When the local LFA and remote LFA are enabled, there is a good coverage of the prefixes to be protected.

However, for some rare topologies that do not have a PQ intersect node, both local and remote LFA will fail to find a release node to protect the failed link. Furthermore, there is no way to prefer a post-convergence path, as the two algorithms have no knowledge of the post-convergence characteristics of the LFA.

To overcome the above limitation, effective Cisco IOS-XE Release 3.18, topology-independent LFA (TI-LFA) is supported on an SR-enabled network.

In Cisco IOS-XE Release 3.18, TI LFA supports the following:

• Link Protection—The LFA provides repair path for failure of the link.

• Local LFA—Whenever a local LFA on the post convergence path is available, it is preferred over TI-LFA because local LFA does not require additional SID for the repair path. That is, the label for the PQ node is not needed for the release node.

• Local LFA for extended P space—For nodes in the extended P space, local LFA is still the most economical method for the repair path. In this case, TI-LFA will not be chosen.

• Tunnel to PQ intersect node—This is similar to remote LFA except that the repair path is guaranteed on the post convergence path using TI-LFA.

• Tunnel to PQ disjoint node—This capability is unique to the TI-LFA in the case when local and remote

LFA cannot find a repair path.

• Tunnel to traverse multiple intersect or disjoint PQ nodes, up to the platform’s maximum supported labels—TI-LFA provides complete coverage of all prefixes.

• P2P interfaces for the protected link—TI-LFA protects P2P interfaces.

• Asymmetrical links—The ISIS metrics between the neighbors are not the same.

• Multi-homed (anycast) prefix protection—The same prefix may be originated by multiple nodes.

• Protected prefix filtering—The route-map includes or excludes a list of prefixes to be protected and the option to limit the maximum repair distance to the release node.

• Tiebreakers—A subset of existing tiebreakers, applicable to TI-LFA, is supported.

Segment Routing Configuration Guide

Using Segment Routing with IS-IS

Tie-breaker

Tie-breaker

Local and remote LFA use default or user-configured heuristics to break the tie when there is more than one path to protect the prefix. The attributes are used to trim down the number of repair paths at the end of the

TI-LFA link protection computation before the load balancing.

Local LFA and remote-LFA support the following tiebreakers:

• linecard-disjoint—Prefers the line card disjoint repair path

• lowest-backup-path-metric—Prefers the repair path with lowest total metric

• node-protecting—Prefers node protecting repair path

• srlg-disjoint—Prefers SRLG disjoint repair path

• load-sharing—Distributes repair paths equally among links and prefixes

For TI-LFA link protection, the following tiebreakers are supported:

• linecard-disjoint—Prefers the line card disjoint repair path.

How it works: When there are two repair paths for a particular prefix, the path that the output port on different line card than that of the primary port is chosen as the repair path.

The following variant of the linecard-disjoint is supported:

• ◦

LC disjoint index—If both the repair paths are on the same line card as that of the primary path, then, both paths are considered as candidates. If one of the path is on a different line card, then that path is chosen as the repair path.

• srlg-disjoint—Prefers the SRLG disjoint repair path

The SRLG ID can be configured for each interface. When there are two repair paths for a prefix, the configured

SRLG ID for the repair path is compared with that of the primary path SRLG ID. If the SRLG IDs for the secondary path is different than that of the primary, that path is chosen as the repair path.

Note

This policy comes into effect only when the primary path is configured with an SRLG ID.

The following variant of the srlg-disjoint is supported:

• ◦ srlg index—If both the repair paths have the same SRLG ID as that of the primary path, then, both the paths are considered as candidates. If one of the path has a different srlg id, then path is chosen as the repair path.

• node-protecting—For TI-LFA node protection, the protected node is removed when computing the post-convergence shortest path. The repair path must direct traffic around the protected node.

It is possible to configure both node and SRLG protection modes for the same interface or the same protocol instance. In that case, an additional TI-LFA node-SRLG combination protection algorithm is run. The TI-LFA node-SRLG combination algorithm removes the protected node and all members of the interface with the same SRLG group when computing the post-convergence SPT.

Segment Routing Configuration Guide

Using Segment Routing with IS-IS

Interface FRR Tiebreakers

For TI-LFA node protection, SRLG protection, and node-SRLG combination protection, it is likely the coverage for the protected prefixes is small. TI-LFA link protection is also run to provide coverage for the prefixes that not yet covered. However, optimization can be achieved when SRLG protection is enabled with no SRLG group on the interface. In that case, SRLG protection produces the same result as link protection and link protection is skipped. Furthermore, if node-protection is also configured in this case, TI-LFA node-SRLG combination protection produces the same result as node-protection and node-protection is skipped.

Interface FRR Tiebreakers

For TI-LFA node and SRLG protection, interface FRR tiebreakers must also be provided. Existing FRR tiebreakers are configured on a per protocol instance. Because FRR tiebreakers are not specific to TI-LFA, interface FRR tiebreakers are available for all FRR types. When both interface and protocol instance FRR tiebreakers are configured, the interface FRR tiebreakers take precedence over the protocol instance. When interface FRR tiebreakers are not configured, the interface inherits the protocol instance FRR tiebreakers. As with the existing tiebreakers, the priority must be unique among the interface and protocol instance for the tiebreakers.

The following interface FRR tiebreaker commands apply only to the particular interface.

isis fast-reroute tie-break

[level-1 | level-2]

linecard-disjoint

priority

isis fast-reroute tie-break

[level-1 | level-2]

lowest-backup-metric

priority

isis fast-reroute tie-break

[level-1 | level-2]

node-protecting

priority

isis fast-reroute tie-break

[level-1 | level-2]

srlg-disjoint

priority

isis fast-reroute tie-break

[level-1 | level-2]

default

Tie-breaker default and explicit tie-breaker on the same interface are mutually exclusive.

The following tie-breakers are enabled by default on all LFAs:

• linecard-disjoint

• lowest-backup-metric

• srlg-disjoint

Effective with Cisco IOS-XE Release 3.18, node-protecting tie-breaker is disabled by default.

Configuring T1 LFA

TI-LFA is disabled by default. There are two methods to enable TI-LFA:

Using protocol enablement—Enable TI-LFA in router isis mode. This enables TI-LFA for all ISIS interfaces.

Optionally, use the interface command to exclude the interfaces on which TI-LFA should be disabled.

For example, to enable TI-LFA for all IS-IS interfaces:

router isis 1 fast-reroute per-prefix {level-1 | level-2}

Segment Routing Configuration Guide

Using Segment Routing with IS-IS

Configuring Interface FRR Tie-breaker fast-reroute ti-lfa {level-1 | level-2} [maximum-metric

value

]

The maximum-metric option specifies the maximum repair distance which a node is still considered eligible as a release node.

To disable TI-LFA on a particular interface:

interface

interface-name

isis fast-reroute ti-lfa protection level-1 disable

Note

The isis fast-reroute protection level-x command enables local LFA and is required to enable TI-LFA.

Using interface enablement—Enable TI-LFA selectively on each interface

interface

interface-name

isis fast-reroute protection {level-1 | level-2} isis fast-reroute ti-lfa protection {level-1 | level-2} [maximum-metric

value

]

When both interface and protocol are TI-LFA enabled, the interface configuration takes precedence over the protocol configuration.

Configuring Interface FRR Tie-breaker

Configuration Example

Example 1: In the following example, local LFA is configured with linecard-disjoint and srlg-disjoint tie-breakers. linecard-disjoint is given preference with a lower priority value (10) than the srlg-disjoint (11).

router isis access net 49.0001.2037.0685.b002.00

metric-style wide fast-flood 10 max-lsp-lifetime 65535 lsp-refresh-interval 65000 spf-interval 5 50 200 prc-interval 5 50 200 lsp-gen-interval 5 5 200 log-adjacency-changes nsf ietf segment-routing mpls fast-reroute per-prefix level-1 all

– configures the local LFA fast-reroute per-prefix level-2 all fast-reroute remote-lfa level-1 mpls-ldp -

enables rLFA (optional)

fast-reroute remote-lfa level-2 mpls-ldp fast-reroute ti-lfa level-1 - enables TI-LFA microloop avoidance rib-update-delay 15000 bfd all-interfaces

Segment Routing Configuration Guide

Using Segment Routing with IS-IS

Verifying the Tie-breaker

Example 2—Enable TI-LFA node-protecting tie-breaker on all ISIS level-2 interfaces with priority 100. All other tie-breakers are disabled.

router isis fast-reroute per-prefix level-2 all fast-reroute ti-lfa level-2 fast-reroute tie-break level-2 node-protecting 100

Example 3—Enable TI-LFA node-protecting tie-breaker with priority 100 and TI-LFA SRLG protection with priority 200 on all IS-IS level-2 interfaces. All other tiebreakers are disabled because the node-protecting tie-breaker is configured.

router isis fast-reroute per-prefix level-2 all fast-reroute ti-lfa level-2 fast-reroute tie-break level-2 node-protecting 100 fast-reroute tie-break level-2 srlg-disjoint 200

Example 3—Enable TI-LFA node-protecting tie-breaker with priority 100 on all ISIS level-2 interfaces except on Ethernet0/0. For those IS-IS interfaces, all other tiebreakers are disabled. Ethernet0/0 overwrites the inheritance and uses the default set of tiebreakers with linecard-disjoint, lowest-backup-path-metric, srlg-disjoint enabled.

router isis fast-reroute per-prefix level-2 all fast-reroute ti-lfa level-2 fast-reroute tie-break level-2 node-protecting 100

interface ethernet0/0 ip router isis isis fast-reroute tie-break level-2 default

Example 4—Enable TI-LFA using the default tiebreaker on all IS-IS interfaces except on Ethernet0/0. On

Ethernet0/0 enable TI-LFA node-protecting with priority 100 and disable all other tiebreakers.

router isis fast-reroute per-prefix level-2 all fast-reroute ti-lfa level-2

interface ethernet0/0 ip router isis isis fast-reroute tie-break level-2 node-protecting 100

Example 5—Enable TI-LFA node-protecting tie-breaker with priority 200 and linecard-disjoint tie-breaker with priority 100 on all ISIS level-2 interfaces. All other tiebreakers are disabled.

router isis fast-reroute per-prefix level-2 all fast-reroute ti-lfa level-2 fast-reroute tie-break level-2 linecard-disjoint 100 fast-reroute tie-break level-2 node-protecting 200

Verifying the Tie-breaker

To view tiebreakers are enabled on the interface:

show running all | section interface interface-name

Similarly, to view the tiebreakers enabled for the router mode:

show running all | section router isis

Segment Routing Configuration Guide

Using Segment Routing with IS-IS

Verifying the Primary and Repair Paths

Verifying the Primary and Repair Paths

In this example, 1.1.1.1 is the protecting neighbor and 4.4.4.4 is the neighbor on the protecting link.

Router# show ip cef 1.1.1.1

1.1.1.1/32 nexthop 1.1.1.1 GigabitEthernet0/2/0 label [explicit-null|explicit-null]() -

slot 2 is primary interface

repair: attached-nexthop 24.0.0.2 TenGigabitEthernet0/3/0 -

slot 3 is repair interface

nexthop 24.0.0.2 TenGigabitEthernet0/3/0 label [explicit-null|explicit-null]() repair: attached-nexthop 1.1.1.1 GigabitEthernet0/2/0

Router# show ip cef 4.4.4.4

4.4.4.4/32 nexthop 4.4.4.4 GigabitEthernet0/2/3 label [explicit-null|16004]() -

slot 2 is primary interface

repair: attached-nexthop 5.5.5.5 MPLS-SR-Tunnel2

Router# show ip cef 4.4.4.4 int

4.4.4.4/32, epoch 3, RIB[I], refcnt 6, per-destination sharing sources: RIB, Adj, LTE feature space:

IPRM: 0x00028000

Broker: linked, distributed at 4th priority

LFD: 4.4.4.4/32 2 local labels dflt local label info: global/877 [0x3] sr local label info: global/16004 [0x1B] contains path extension list dflt disposition chain 0x46654200 label implicit-null

FRR Primary

<primary: IP adj out of GigabitEthernet0/2/3, addr 4.4.4.4> dflt label switch chain 0x46654268 label implicit-null

TAG adj out of GigabitEthernet0/2/3, addr 4.4.4.4

sr disposition chain 0x46654880 label explicit-null

FRR Primary

<primary: TAG adj out of GigabitEthernet0/2/3, addr 4.4.4.4> sr label switch chain 0x46654880 label explicit-null

FRR Primary subblocks:

<primary: TAG adj out of GigabitEthernet0/2/3, addr 4.4.4.4>

Adj source: IP adj out of GigabitEthernet0/2/3, addr 4.4.4.4 464C6620

Dependent covered prefix type adjfib, cover 0.0.0.0/0 ifnums:

GigabitEthernet0/2/3(11): 4.4.4.4

MPLS-SR-Tunnel2(1022) path list 3B1FC930, 15 locks, per-destination, flags 0x4D [shble, hvsh, rif, hwcn] path 3C04D5E0, share 1/1, type attached nexthop, for IPv4, flags [has-rpr]

MPLS short path extensions: [rib | lblmrg | srlbl] MOI flags = 0x21 label explicit-null nexthop 4.4.4.4 GigabitEthernet0/2/3 label [explicit-null|16004](), IP adj out of

GigabitEthernet0/2/3, addr 4.4.4.4 464C6620 repair: attached-nexthop 5.5.5.5 MPLS-SR-Tunnel2 (3C04D6B0) path 3C04D6B0, share 1/1, type attached nexthop, for IPv4, flags [rpr, rpr-only]

MPLS short path extensions: [rib | lblmrg | srlbl] MOI flags = 0x1 label 16004 nexthop 5.5.5.5 MPLS-SR-Tunnel2 label 16004(), repair, IP midchain out of

MPLS-SR-Tunnel2 46CE2440 output chain: label [explicit-null|16004]()

FRR Primary (0x3B209220)

<primary: TAG adj out of GigabitEthernet0/2/3, addr 4.4.4.4 464C6480> -

primary path

<repair: TAG midchain out of MPLS-SR-Tunnel2 46CE22A0 label 16() label 16003()

TAG adj out of TenGigabitEthernet0/3/0, addr 24.0.0.2 46CE25E0> -

repair path

Segment Routing Configuration Guide

Using Segment Routing with IS-IS

Verifying the IS-IS Segment Routing Configuration

Verifying the IS-IS Segment Routing Configuration

Router#

show isis segment-routing

ISIS protocol is registered with MFI

ISIS MFI Client ID:0x63

Tag Null - Segment-Routing:

SR State:SR_ENABLED

Number of SRGB:1

SRGB Start:14000, Range:1001, srgb_handle:0xE0934788, srgb_state: created

Address-family IPv4 unicast SR is configured

Operational state: Enabled

The command with keyword global-block displays the SRGB and the range for LSPs.

Router#

show isis segment-routing global-block

IS-IS Level-1 Segment-routing Global Blocks:

System ID nevada arizona utah

SRGB Base

20000

* 16000

40000

SRGB Range

4001

1000

8000

The show isis segment-routing prefix-sid-map command with keyword advertise displays the prefix-sid maps that the router advertises.

Roouter#

show isis segment-routing prefix-sid-map adv

IS-IS Level-1 advertise prefix-sid maps:

Flags Prefix

16.16.16.16/32

16.16.16.17/32

SID Index

101

102

Range

1 Attached

The show isis segment-routing prefix-sid-map command with keyword receive displays the prefix-sid maps that the router receives.

Router #sh isis segment-routing prefix-sid-map receive

IS-IS Level-1 receive prefix-sid maps:

Host Prefix utah 16.16.16.16/32

16.16.16.17/32

SID Index

101

102

Range

Flags

Attached

To display the connected-SIDs found in the LSPs and passed to the mapping server component, use the show

isis segment-routing connected-sid command.

Router#

show isis segment-routing connected-sid

IS-IS Level-1 connected-sids

Host Prefix nevada * 1.1.1.2/32

SID Index

1002 colorado

2.2.2.2/32

100.1.1.10/32

1.1.1.3/32

1.1.1.6/32

IS-IS Level-2 connected-sids

Host Prefix

SID Index

Range

Flags

Verifying the IS-IS TI-LFA Tunnels

Router# show isis fast-reroute ti-lfa tunnel

Fast-Reroute TI-LFA Tunnels:

Tunnel Interface Next Hop

MP1

MP2

Et1/0

Et0/0

30.1.1.4

19.1.1.6

End Point

1.1.1.2

1.1.1.6

MP3 Et0/0 19.1.1.6

1.1.1.2

1.1.1.6

Label

41002

60006

End Point Host nevada colorado nevada colorado

Segment Routing Configuration Guide

Using Segment Routing with IS-IS

Additional References

1.1.1.2

1.1.1.5

70005 nevada wyoming

Additional References

MIBs

MIB

CISCO-MIB

MIBs Link

To locate and download MIBs for selected platforms,

Cisco software releases, and feature sets, use Cisco

MIB Locator found at the following URL: http://www.cisco.com/go/mibs

RFCs

RFC

RFC4971

RFC5305

RFC6119

Title

Intermediate System to Intermediate System (IS-IS)

Extensions for Advertising Router Information

IS-IS Extensions for Traffic Engineering. Defines the advertisement of router IDs for IPv4.

IPv6 Traffic Engineering in IS-IS. Defines the advertisement of router IDs for IPv6.

Feature Information for Using Segment Routing with IS-IS

Use Cisco Feature Navigator to find information about platform support and Cisco software image support.

To access Cisco Feature Navigator, go to www.cisco.com/go/cfn . An account on Cisco.com is not required.

Table 4: Feature Information for Using Segment Routing with IS-IS

Feature Name Releases

Using Segment Routing with IS-IS Cisco IOS XE Everest 16.4.1

Feature Information

This is a new feature.

Segment Routing Configuration Guide

تبلیغات