Cisco MPLS Segment Routing Introduction v2 1

MPLS Segment Routing Introduction Lab
SP Partner VT Lab
MPLS Segment Routing Introduction v2
Powered by
dCloud: The Cisco Demo Cloud
08-24-2018, Version 2.0
© 2018 Cisco and/or its affiliates. All rights reserved. Page 1 of 50

IMPORTANT: This content includes pre-release software, and you may experience issues with some features. The included
documentation was not created or verified by dCloud. Check Cisco dCloud regularly for new releases!
Segment Routing Introduction:

Segment routing is a network technology that provides enhanced packet-forwarding behavior
while minimizing the need for maintaining awareness of mass volumes of network state. The
following is an extract from the IETF draft defining Segment Routing (“draft-ietf-spring-segment-
routing-15”):
“Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through
an ordered list of instructions, called segments. A segment can represent any instruction,
topological or service-based. A segment can have a local semantic to an SR node or global within
an SR domain. Segment routing allows you to enforce a flow through any topological path and
service chain while maintaining per-flow state only at the ingress node to the SR domain.
Segment routing can be directly applied to the MPLS architecture with no change on the
forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is
encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion
of a segment, the related label is popped from the stack. Segment routing re-uses MPLS
dataplane without any changes. All the segments are represented as MPLS label. It is applicable
to both IPv4 and IPv6 dataplane
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. Upon completion of a segment, the pointer
is incremented.”
There are two types of Segment IDs for Segment Routing:
Global Segment: Any node in the segment-routing domain understands the instruction
associated with a global segment. Any node in the domain installs the related instruction in its
Forwarding Information Base (FIB). Global segments fall in a subspace of the segment (or label)
space called the Segment Routing Global Block (SRGB). The SRGB is usually defined as the
range 16000 to 23999, and all the nodes in a network are allocated the same SRGB; this
stipulation is important to fulfill the requirement for operational simplification. Note that the use of a
common SRGB in all nodes is not a requirement; a different SRGB at every node can be used, if
needed.  
Local Segment: The instruction associated with a local segment is supported by only the node
originating it. No other node installs a remote local segment in its FIB.   For example: If node N
allocates segment 29001 to the local forwarding instruction “complete the segment and forward
the packet onto interface I”, then it advertises this local instruction with absolute value 29001. No
other node installs that segment in its segment-routing FIB and hence no conflict can arise
Node and prefix segment are example of Global SID and Adjacency Segment are example of
local SID:
Node Segment: A node segment (or node SID, or N-SID) is associated with a node in
the SR network, and is a globally known within the network. It represents the ECMP-aware
shortest path to the node. A prefix-SID (or P-SID) represents the ECMP-aware IGP shortest path
to the prefix (which is attached to one or more nodes in the network). A node segment is a
segment allocated to a loopback that identifies a specific node.   In following picture, 16005 is the
node segment of router 5, in other words, it’s a segment allocated to a loopback of router 5, so a

packet injected anywhere in the network with top segment 16005 will reach 5 by the shortest-path.
The imposition of the segment happens on the ingress router, at Router 1.  
Node Segment Imposition
Adjacency Segment: An adjacency segment (or Adj-SID, or A-SID) is associated with an

adjacency on a router. It is locally significant, is a local segment signaled by IS-IS or OSPF; it
is used to steer traffic onto an adjacency or a set of adjacencies. Packets with such SID are
forced to be sent over that adjacency (regardless any existing IGP paths). In the picture below,
node 5 allocates a local segment 29057 and maps it to the instruction “complete the segment
and forward along the interface 57”. Node 5 advertises the adjacency segment in IGP. Node 5
is the only node to install the adjacency segment in FIB. A packet received by node 5 with
segment 29057 is forced through link 57.
Adjacency Segment
Segment-Routing Control Plane: The job of the SR control plane is to set up the MPLS
forwarding table on each router in such a way to allow this to happen. Extensions to both IS-IS
and OSPF protocols have been made to support segment routing. IS-IS TLV extensions have
been implemented for segment-routing support in IS-IS. The implementation is based on the IETF
draft “draft-ietf-IS-IS-segment-routing-extensions” via new Sub TLV for SR carried in current IP
and IS-IS reachability TLV on LSP. OSPF extensions have been implemented to support segment

routing. The implementation is based on the “draft-ietf-ospf-segment-routing-extensions” via new

Opaque LSA can be used to advertise any additional attributes associated with a prefix or link
using new TLV and Sub TLV for SR.
Segment Routing Advantages
Segment Routing (SR) enables a unified, end-to-end, policy-aware network architecture from
servers in the data center, through the WAN, and up to the aggregation. Benefits of SR are
related to operational simplicity, better scale (the SR policy is in the packet), and better utilization
of the installed infrastructure (lower capex)
. Simplify the Transport by having few protocols to operate

. IGP + LDP vs IGP (ISIS & OSPF) with SR extension
. Remove one protocol: LDP, RSVP
. Fewer protocols interations to troubleshoot
. No LDP and IGP interaction, ex. no IGP-LDP sync required
. Less state to maintain by routers
. No RSVP state on the Routers, a much simple and scalable solution
. Re-uses MPLS data plane without any change
. Recover MPLS TE with a simpler control plane
. RSVP-TE traffic engineering vs SR traffic engineering (SR TE)
. Topology independent sub millisecond FRR
. RSVP-TE FRR, IP FRR vs SR FRR
SR is designed for SDN because it seeks the proper balance between distributed intelligence,
centralized optimization, and application-based policy creation.  

Lab Overview
This lab introduces Segment Routing (SR) with MPLS dataplane and traffic engineering with a
manual SRTE tunnel. This lab will provide all attendees first hand experience on how to use
MPLS data plane with no MPLS configuration to use labels r and steer traffic using segment
routing. Attendees will be able to see how SRTE (segment routing traffic engineering) tunnels are
created and traffic is steered.
The student will use XRv to implement segment routing over the MPLS dataplane. Upon
completion of this lab, the student will be able to:
Configure segment routing  
Verify segment routing labels  
Steer traffic using SRTE  
The main objective of this lab is to provide participants exposure to segment routing technology
 Participants will configure segment routing on all the nodes
 Segment routing labels will be created
 Traffic will be preferred using segment routing
 MPLS configuration will be removed
 Traffic will still continue to have labels via segment routing

 Segment routing traffic engineering tunnel is built on XR1

 Traffic will be steered explicitly via ASAv to show first-hand how traffic steering happens
Lab Topology:
XRv-2 XRv-5
Gi 0/0/0/1 Gi 0/0/0/0
10.10.2.2 10.10.5.5
10.10.6.6
10.10.1.1
XRv-1 XRv-6
172.16.8.6
Gi 0/0/0/2
Gi 0/1
10.10.3.3 10.10.4.4
Gi 0/0/0/1 Gi 0/0/0/0 172.16.8.4

Gi 0/0/0/2 Gi 0/0
XRv-3 XRv-4 ASAv-1
Components
 VIRL
 IOS XRv
 Anyconnect
Features
VIRL  Virtual environment for building network topologies
 Simulation of networking components
 Capable of running a range of virtual machines (VMs) running Cisco operating systems (IOS-XE, IOS
Classic, IOS-XR, and NX-OS)
 Support for third-party VMs
 Capture and analyze network traffic at any node
 Validate configurations prior to physical deployment

Segment  Segment Routing (SR) enables a unified, end-to-end, policy-aware network architecture from servers
Routing in the data center, through the WAN, and up to the aggregation.
 SR is designed for SDN because it seeks the proper balance between distributed intelligence,
centralized optimization, and application-based policy creation.
 Other benefits of SR are related to operational simplicity, better scale (the SR policy is in the packet),
and better utilization of the installed infrastructure (lower capex)
Requirements
 A Laptop computer with access to the Internet
 A valid CCO user to log into dCloud
 Anyconnect, VPN software used to connect your desktop into the Virtual Lab
 Microsoft Remote Desktop, used to connect into the virtual Lab Desktop
Lab Access
Each participant will have an individual POD to work on. Each POD is dedicated to an individual user, so
there is no impact to other PODs when making changes. You will receive a PoD already started for you
Follow step by step instructions to login into your PoD and complete the lab
Step 1: Go into dCloud to access the Lab session being assigned to you. Click on View Session
Step 2: Look into Session details and scroll down to find out your credentials for VPN Anyconnect

Step 3: Connect to anyconnect VPN dcloud-sjc-anyconnect.cisco.com with the username and password
provided on session details information window
Below is an example of user logging into POD1

Hit accept when the prompt appears to accept the VPN connection login
Step 4:
 Once, the vpn is connected. Use Remote Desktop to connect to the respective POD.
 If the RDP icon is not present on the desktop, go to RUN  type mstsc to get the remote
desktop screen.
 Enter the ip address provided for the POD to connect to the remote client

 Enter the credentials Administrator / C1sco12345 to login to your POD
 Accept the connection certificate to login to the Virtual Lab Windows Desktop.

Step 5: Once logged into the Windows desktop, you will see a browser with the Lab Launch Progress.
Verify all 4 steps (1 – 2 – 3 – 4) shown green (status ok). Don´t click on any Launch Control Center or
Command Group !
Step 6: Minimize the browser and click on the MTPuTTY icon to open connections to all devices.
Access all devices by double clicking the device name from the Servers panel on the left-hand
side of the MTPuTTY start page. Username is cisco and password is cisco for all
devices.  

The table below contains details on preconfigured devides available for your virtual lab environment
Component Access options Credentials
XR1 198.18.1.31 cisco/cisco

ASAv (transparent) 198.18.1.37 cisco/cisco
Here is your topology and summary of IP address used at Virtual Lab network

XRv-2 XRv-5
Gi 0/0/0/1 Gi 0/0/0/0
XRv-1 XRv-6
Gi 0/0/0/2
Gi 0/1
Gi 0/0/0/1 Gi 0/0/0/0
Gi 0/0/0/2 Gi 0/0
XRv-3 XRv-4 ASAv-1
Router Name IP Address

XR1: Loopback 0 10.10.1.1/32
XR2: Loopback 0 10.10.2.2/32
XR3: Loopback 0 10.10.3.3/32
XR4: Loopback 0 10.10.4.4/32
XR5: Loopback 0 10.10.5.5/32
XR6: Loopback 0 10.10.6.6/32
XR1 to XR2 172.16.1.1/24
XR1 to XR3 172.16.3.1/24
XR2 to XR1 172.16.1.2/24
XR2 to XR5 172.16.2.2/24
XR3 to XR1 172.16.3.3/24
XR3 to XR4 172.16.4.3/24
XR4 to XR3 172.16.4.4/24
XR4 to XR6 172.16.6.4/24
XR4 to ASAv 172.16.8.4/24
XR5 to XR2 172.16.2.5/24
XR5 to XR6 172.16.5.5/24
XR6 to XR4 172.16.6.6/24
XR6 to XR5 172.16.5.6/24
XR6 to ASAv 172.16.8.6/24
Step 7: Log into each of your XRv devices with credentials cisco/cisco on all the XR routers (XR1, XR2,
XR3, XR4, XR5, XR6)


Lab verification
Step 1: Explore your virtual devices. Each one is pre-configured with basic configuration
 Run the below command to check the XR version running on virtual routers
RP/0/0/CPU0:XR1#show ver brief
Cisco IOS XR Software, Version 6.1.3[Default]
Copyright (c) 2017 by Cisco Systems, Inc.
ROM: GRUB, Version 1.99(0), DEV RELEASE
XR1 uptime is 23 minutes

System image file is "bootflash:disk0/xrvr-os-mbi-6.1.3/mbixrvr-rp.vm"
cisco IOS XRv Series (Intel 686 F6M15S2) processor with 3169791K bytes of memory.
Intel 686 F6M15S2 processor at 2476MHz, Revision 2.174
IOS XRv Chassis
1 Management Ethernet
2 GigabitEthernet
97070k bytes of non-volatile configuration memory.
866M bytes of hard disk.
2321392k bytes of disk0: (Sector size 512 bytes).Verify that OSPF neighbour is
established on all the routers
RP/0/0/CPU0:XR1#show platform
Node Type PLIM State Config State

-----------------------------------------------------------------------------
0/0/CPU0 RP(Active) N/A IOS XR RUN PWR,NSHUT,MON
 Look into the vRouter interfaces and cdp neighbors. Compare with your topology
RP/0/0/CPU0:XR1#sh int brief
Intf Intf LineP Encap MTU BW

Name State State Type (byte) (Kbps)
--------------------------------------------------------------------------------
Lo0 up up Loopback 1500 0

Nu0 up up Null 1500 0

Mg0/0/CPU0/0 up up ARPA 1514 1000000
Gi0/0/0/0 up up ARPA 1514 1000000
Gi0/0/0/1 up up ARPA 1514 1000000
RP/0/0/CPU0:XR1#show cdp neighbor
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge

S - Switch, H - Host, I - IGMP, r - Repeater
Device ID Local Intrfce Holdtme Capability Platform Port ID

XR2 Gi0/0/0/0 134 R IOS XRv S Gi0/0/0/0
XR3 Gi0/0/0/1 139 R IOS XRv S Gi0/0/0/0
 Look into the running configuration

RP/0/0/CPU0:XR1#show run
 Once, the configuration is verified, you may proceed to the next task
Step 2: Verify all routers have OSPF enabled in their interfaces and neighbors are up. Run the below
command to check:
RP/0/0/CPU0:XR1#show ospf interfaces (brief)

RP/0/0/CPU0:XR1#show ospf interface brief
* Indicates MADJ interface, (P) Indicates fast detect hold down state
Interfaces for OSPF 100
Interface PID Area IP Address/Mask Cost State Nbrs F/C

Lo0 100 0 10.10.1.1/32 1 LOOP 0/0
Gi0/0/0/0 100 0 172.16.1.1/24 1 P2P 1/1
Gi0/0/0/1 100 0 172.16.3.1/24 1 P2P 1/1
 Verify that OSPF neighbour is established on all the routers

RP/0/0/CPU0:XR1#show ospf neighbor
* Indicates MADJ interface

# Indicates Neighbor awaiting BFD session up
Neighbors for OSPF 100
Neighbor ID Pri State Dead Time Address Interface

10.10.2.2 1 FULL/ - 00:00:36 172.16.1.2
GigabitEthernet0/0/0/0

Neighbor is up for 22:16:51

10.10.3.3 1 FULL/ - 00:00:32 172.16.3.3
GigabitEthernet0/0/0/1
Total neighbor count: 2
Step 3: Verify all prefixes (loopbacks) are learnt and installed at routing table
RP/0/0/CPU0:XR1#show route (ospf)
RP/0/0/CPU0:XR1#sh route ospf
O 10.10.2.2/32 [110/2] via 172.16.1.2, 00:37:37, GigabitEthernet0/0/0/0

[110/4] via 172.16.1.2, 00:37:37, GigabitEthernet0/0/0/0
RP/0/0/CPU0:XR1#sh ospf route (detail)
 How many routes do you have ? What kind ?
Step 4: Verify all routers have MPLS enabled.Use the below command to verify MPLS interface
RP/0/0/CPU0:XR1#show mpls interfaces

RP/0/0/CPU0:XR1#show mpls interface
Interface LDP Tunnel Static Enabled

-------------------------- -------- -------- -------- --------
GigabitEthernet0/0/0/0 Yes No No Yes
GigabitEthernet0/0/0/1 Yes No No Yes

Use the following command to verify your LDP neighbors

RP/0/0/CPU0:XR1#show mpls ldp neighbors (brief)
Peer GR NSR Up Time Discovery Addresses Labels

ipv4 ipv6 ipv4 ipv6 ipv4 ipv6
----------------- -- --- ---------- ---------- ---------- ------------
10.10.3.3:0 N N 00:40:30 1 0 3 0 13 0
10.10.2.2:0 N N 00:40:19 1 0 3 0 13 0
 How many Labels did you receive from each neighbor ? check using “
RP/0/0/CPU0:XR1#show mpls ldp bindings (brief)

RP/0/0/CPU0:XR1#show mpls ldp bindings brief
Prefix Local Advertised Remote Bindings

Label (peers) (peers)
------------------ --------- ---------- ---------------
10.10.1.1/32 ImpNull 2 2
10.10.2.2/32 24005 2 2
10.10.3.3/32 24000 2 2
10.10.4.4/32 24001 2 2
10.10.5.5/32 24006 2 2
10.10.6.6/32 24007 2 2
172.16.1.0/24 ImpNull 2 2
172.16.2.0/24 24008 2 2
172.16.3.0/24 ImpNull 2 2
172.16.4.0/24 24002 2 2
172.16.5.0/24 24009 2 2
172.16.6.0/24 24003 2 2
172.16.8.0/24 24004 2 2
 Why there are some prefixes with “ImpNull” ? What MPLS Label number is it ? What MPLS
operation is associated to this label received from a peer ?
 Check the MPLS forwarding table into your local vRouter

RP/0/0/CPU0:XR1#show mpls forwarding
Local Outgoing Prefix Outgoing Next Hop Bytes

Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
24000 Pop 10.10.3.3/32 Gi0/0/0/1 172.16.3.3 5743
24001 24000 10.10.4.4/32 Gi0/0/0/1 172.16.3.3 0
24002 Pop 172.16.4.0/24 Gi0/0/0/1 172.16.3.3 0
24003 24001 172.16.6.0/24 Gi0/0/0/1 172.16.3.3 0
24004 24002 172.16.8.0/24 Gi0/0/0/1 172.16.3.3 0
24005 Pop 10.10.2.2/32 Gi0/0/0/0 172.16.1.2 5318
24006 24000 10.10.5.5/32 Gi0/0/0/0 172.16.1.2 0
24007 24006 10.10.6.6/32 Gi0/0/0/0 172.16.1.2 0
24007 10.10.6.6/32 Gi0/0/0/1 172.16.3.3 0
24008 Pop 172.16.2.0/24 Gi0/0/0/0 172.16.1.2 0
perform a traceroute to verify the MPLS Dataplane operation
RP/0/0/CPU0:XR1#traceroute 10.10.6.6
Type escape sequence to abort.

Tracing the route to 10.10.6.6
1 172.16.3.3 [MPLS: Label 24007 Exp 0] 19 msec 19 msec 9 msec

3 172.16.6.6 9 msec * 19 msec
Step 5: Repeat using MPLS ping
RP/0/0/CPU0:XR1#traceroute mpls multipath ipv4 10.10.6.6/32 ver

Fri May 25 01:53:45.060 UTC
Starting LSP Path Discovery for 10.10.6.6/32
Codes: '!' - success, 'Q' - request not sent, '.' - timeout,

'L' - labeled output interface, 'B' - unlabeled output interface,
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no rx label,
'P' - no rx intf label prot, 'p' - premature termination of LSP,
'R' - transit router, 'I' - unknown upstream index,
'X' - unknown return code, 'x' - return code 0
LL!

Path 0 found,
output interface GigabitEthernet0/0/0/0 nexthop 172.16.1.2
source 172.16.1.1 destination 127.0.0.0
0 172.16.1.1 172.16.1.2 MRU 1500 [Labels: 24006 Exp: 0] multipaths 0
L 1 172.16.1.2 172.16.2.5 MRU 1500 [Labels: 24002 Exp: 0] ret code 8 multipaths 1
L 2 172.16.2.5 172.16.5.6 MRU 1500 [Labels: implicit-null Exp: 0] ret code 8 multipaths 1
! 3 172.16.5.6, ret code 3 multipaths 0
L...
Path 1 Unexplorable,
output interface GigabitEthernet0/0/0/1 nexthop 172.16.3.3
source 172.16.3.1 destination 127.0.0.0
0 172.16.3.1 172.16.3.3 MRU 1500 [Labels: 24007 Exp: 0] multipaths 0
L 1 172.16.3.3 172.16.4.4 MRU 1500 [Labels: 24006 Exp: 0] ret code 8 multipaths 1
Paths (found/broken/unexplored) (1/0/1)

Echo Request (sent/fail) (7/0)
Echo Reply (received/timeout) (4/3)
Total Time Elapsed 5 seconds 969 ms
 What is the difference with plain IP Traceroute ? why it doesn´t work ? Enable MPLS OAM !
RP/0/0/CPU0:XR6#conf t
RP/0/0/CPU0:XR6(config)#mpls oam

Segment Routing Configuration

In this section, segment routing configuration will be added to the XRv routers.
There are 2 options to add segment routing in OSPF
 Global OSPF configuration mode
 Under specific area
We are going to add MPLS segment routing configuration under OSPF instance.
Step 1: Configure segment routing on all the XR routers under OSPF instance 100 using the below
configuration. We are showing XR1 configuration only, apply the same configuration to XR2, XR3,
XR4, XR4, XR5 and XR6.
router ospf 100

segment-routing mpls
segment-routing forwarding mpls
 Use the below command to check for SR global block in use ( default SR block value is from
16,000 – 23,999)
RP/0/0/CPU0:XR1#show mpls label table ( detail )
RP/0/0/CPU0:XR6#show mpls label table
Table Label Owner State Rewrite

----- ------- ------------------------------- ------ -------
0 0 LSD(A) InUse Yes
0 16000 OSPF(A):ospf-100 InUse No
0 24000 LDP(A) InUse Yes
0 24010 OSPF(A):ospf-100 InUse Yes

RP/0/0/CPU0:XR1#show mpls label table detail

Table Label Owner State Rewrite
----- ------- ------------------------------- ------ -------
0 16000 OSPF(A):ospf-100 InUse No
(Lbl-blk SRGB, vers:0, (start_label=16000, size=8000)
(SR Adj Segment IPv4, vers:0, index=0, type=1, intf=Gi0/0/0/0, nh=172.16.1.2)
(SR Adj Segment IPv4, vers:0, index=0, type=2, intf=Gi0/0/0/1,
nh=172.16.3.3)24007 24005 172.16.5.0/24 Gi0/0/0/0 172.16.1.2
0
Notes
• SR label range can NOT start below 16,000
• The default SR global block is : 16,000 - 24,000. Its soft reserved, once we reach OOR LSD can start
using this range 16k-24k for dynamic label allocation
• SRGB configuration is NOT address-family specific because the “SR-Capabilities Sub-TLV” of router
capability TLV defined in is not address-family specific
• If CLI results in enlarging or moving the default SRGB, then it is OK to require a reload but only if there
are clients who have labels in the new range
Before configuring SRGB, administrator needs to make sure that portion of the label base that is being
configured for Segment-Routing is free and is not being used by any other MPLS LSD clients
Step 2: Adj-SID, What SID has been already assigned ? How many ADJ-SID per link ? Check by looking
into
RP/0/0/CPU0:XR1#show ospf neighbor det

Neighbor 10.10.2.2, interface address 172.16.1.2

In the area 0 via interface GigabitEthernet0/0/0/0
Neighbor priority is 1, State is FULL, 6 state changes
DR is 0.0.0.0 BDR is 0.0.0.0
Options is 0x52
LLS Options is 0x1 (LR)
Dead timer due in 00:00:32


Number of DBD retrans during last exchange 0
Index 2/2, retransmission queue length 0, number of retransmission 4
First 0(0)/0(0) Next 0(0)/0(0)
Last retransmission scan length is 3, maximum is 3
Last retransmission scan time is 0 msec, maximum is 0 msec
LS Ack list: NSR-sync pending 0, high water mark 0
Adjacency SID Label: 24010
Unprotected Adjacency SID Label: 24011

DR is 0.0.0.0 BDR is 0.0.0.0
Options is 0x52
First 0(0)/0(0) Next 0(0)/0(0)
Adjacency SID Label: 24012
What is the difference between Adj-SID and Unprotected Adj-SID ?
NOTE: Protected and unprotected adjacency-SIDs are allocated for both address families, but the
protected adjacency-SIDs are not actually protected because TI-LFA is not enabled yet. Protected
adjacency-SIDs with active protection are marked with the indication (protected).
Step 3: Node-SID, Now, we are going to assign the node-id to the loopback. We are only going to
show XR1 here. Below are the node-ids for all the XR routers
o XR1 = prefix-sid index 1


router ospf 100

area 0
int loopback0
prefix-sid index 1 <<< Use right value depending of Router
 Prefix-sid-index value is used on all the routers (configured under the loopback addresses). The actual
label value as seen below is (SRGB base + prefix-sid-index). For example label allocated for Router A
loopback address is 16000 +1 i.e 16001. Alternatively “prefix-sid absolute 16001” can be used.
Verify the Router is disseminating information related to Segment Routing via OSPF by looking at
RP/0/0/CPU0:XR1#show ospf database opaque-area self-originate
OSPF Router with ID (10.10.1.1) (Process ID 100)
Type-10 Opaque Link Area Link States (Area 0)
LS age: 1422
Options: (No TOS-capability, DC)
LS Type: Opaque Area Link
Link State ID: 4.0.0.0
Opaque Type: 4
Opaque ID: 0
Advertising Router: 10.10.1.1
LS Seq Number: 80000001
Checksum: 0x92cb
Length: 52
Router Information TLV: Length: 4

Capabilities:
Graceful Restart Helper Capable
Stub Router Capable
All capability bits: 0x60000000
Segment Routing Algorithm TLV: Length: 2

Algorithm: 0
Algorithm: 1
Segment Routing Range TLV: Length: 12

Range Size: 8000
SID sub-TLV: Length 3

Label: 16000
LS age: 171


Opaque Type: 7
Opaque ID: 1
Checksum: 0x1c56
Length: 44
Extended Prefix TLV: Length: 20

Route-type: 1
AF : 0
Flags : 0x40
Prefix : 10.10.1.1/32
SID sub-TLV: Length: 8

Flags : 0x0
MTID : 0
Algo : 0
SID Index : 1
LS age: 1422
Opaque Type: 8
Opaque ID: 4
Checksum: 0x16e8
Length: 68
Extended Link TLV: Length: 44

Link-type : 1
Link ID : 10.10.2.2
Link Data : 172.16.1.1
Adj sub-TLV: Length: 7

Flags : 0xe0
MTID : 0
Weight : 0
Label : 24010

Flags : 0x60
MTID : 0
Weight : 0
Label : 24011
Remote If Address sub-TLV: Length: 4

Neighbor Address: 172.16.1.2

LS age: 1422
Opaque Type: 8
Opaque ID: 5
Checksum: 0x6a88
Length: 68
Extended Link TLV: Length: 44

Link-type : 1
Link ID : 10.10.3.3
Link Data : 172.16.3.1

Flags : 0xe0
MTID : 0
Weight : 0
Label : 24012

Flags : 0x60
MTID : 0
Weight : 0
Label : 24013
Remote If Address sub-TLV: Length: 4

Neighbor Address: 172.16.3.3
Note: OSPF uses 3 new type (4, 7 and 8) of Opaque LSA to propagate SR information
LSA type 4:
SR-Algorithm TLV (8)
SID/Label Range TLV (9)
LSA type 7 and 8 to advertise SIDs
OSPFv2 Extended Prefix Opaque LSA (type 7)
OSPFv2 Extended Prefix TLV (1)
Prefix SID Sub-TLV (2)
OSPFv2 Extended Link Opaque LSA (type 8)
OSPFv2 Extended Link TLV (1)
Adj-SID Sub-TLV (2)
LAN Adj-SID Sub-TLV (3)
Flag for Extended prefix TLV (embedded in Type 7 opaque LSA) codes ANxxxxxx, A=Attach bit for ABR
and N=Node bit. So what does 0x40 mean for 10.10.1.1 ?

Flag for Prefix SID Sub-TLV from Extended Prefis TLV (embedded in Type 7 opaque LSA) codes
xNMEVLxx, N=no-PHP, M=MappServer, E=ExpNull, V=value, L=local. So what does 0x00 mean ?
Flag for Adj-SID Sub-TLV in extended Link TLV (embedded in Type 8 opaque LSA) codes BVLSxxx,
B=backup, V=value, L=local, S=adj-set. So what does 0xe0 and 0x60 mean ?
Look into the rest of Opaque LSA via
RP/0/0/CPU0:XR1#show ospf database opaque-area (adv-router 10.10.6.6)
Step 4: Verify, SR prefix has assigned the appropriate Ids in the MPLS table with the below command

------ ----------- ------------------ ------------ --------------- ------------
16002 Pop SR Pfx (idx 2) Gi0/0/0/0 172.16.1.2 0
16003 Pop SR Pfx (idx 3) Gi0/0/0/1 172.16.3.3 0
16004 16004 SR Pfx (idx 4) Gi0/0/0/1 172.16.3.3 0
16005 16005 SR Pfx (idx 5) Gi0/0/0/0 172.16.1.2 0
16006 16006 SR Pfx (idx 6) Gi0/0/0/0 172.16.1.2 0
16006 SR Pfx (idx 6) Gi0/0/0/1 172.16.3.3 0
24000 Pop 10.10.3.3/32 Gi0/0/0/1 172.16.3.3 11739
24001 24000 10.10.4.4/32 Gi0/0/0/1 172.16.3.3 0
24002 Pop 172.16.4.0/24 Gi0/0/0/1 172.16.3.3 0
24003 24001 172.16.6.0/24 Gi0/0/0/1 172.16.3.3 0
24004 24002 172.16.8.0/24 Gi0/0/0/1 172.16.3.3 0
24005 Pop 10.10.2.2/32 Gi0/0/0/0 172.16.1.2 11256
24006 24000 10.10.5.5/32 Gi0/0/0/0 172.16.1.2 0
24007 24006 10.10.6.6/32 Gi0/0/0/0 172.16.1.2 0
24007 10.10.6.6/32 Gi0/0/0/1 172.16.3.3 576
24008 Pop 172.16.2.0/24 Gi0/0/0/0 172.16.1.2 0
24009 24001 172.16.5.0/24 Gi0/0/0/0 172.16.1.2 0
24010 Pop SR Adj (idx 0) Gi0/0/0/0 172.16.1.2 0
24011 Pop SR Adj (idx 0) Gi0/0/0/0 172.16.1.2 0
24012 Pop SR Adj (idx 0) Gi0/0/0/1 172.16.3.3 0
Identify from above MPLS labels which are being used by SR. Which one as Prefix/Node SID and which
one as Adjacency SID ?
Step 5: Redo the traceroute operation from XR1 to XR6 to test Segment Routing MPLS data plane

Note the label values carefully in the below output. It will change after step 3. Label values
can very for each POD


3 172.16.6.6 9 msec * 19 msec
Why it is still using Labels assigned by LDP and not the SID ?
 When LDP and SR both are present LDP LSP is preferred over SR. This is to help migration
from LDP to SR. Command “segment-routing mpls sr-prefer” overrides the default behavior i.e
segment-routing LSPs are preferred even if LDP lsps are present. Please find more details about
SR LDP preference in the following section.
Step6: Now, prefer segment routing over MPLS and assign prefix-sid ( segment id) to the loopback. This is
equivalent to assigning an identifier to a node or a router-id for that node
 First, we are going to add configuration to start preferring SR over MPLS. This has to be
added on all the XR routers XR2, XR3, XR4, XR5, XR6
router ospf 100

segment-routing sr-prefer
 We would notice if we trace 10.10.6.6 again, that it is preferring the SR label instead of
MPLS label. Trace 10.10.6.6 to observe the output



3 172.16.6.6 0 msec * 0 msec
Question: is it required to configure “sr-prefer” in all routers in order to see this behavior at XR-1 ??
Repeat using MPLS ping operation. Why it doesn´t work ?
Step 7: Explore the options available for “segment-routing” under the “ospf router” configuration group as
well as the new “segment-routing” configuration group
RP/0/0/CPU0:XR1(config)#router ospf 100

RP/0/0/CPU0:XR1(config-ospf)#segment-routing ?
disable Disable Segment Routing
forwarding Enable Segment-routing forwarding on interfaces
global-block MPLS label range for SID allocation
mpls SR using MPLS dataplane
prefix-sid-map Configuring segment routing mapping server
sr-prefer Prefer segment routing labels over LDP labels
RP/0/0/CPU0:XR1(config-ospf)#exit
RP/0/0/CPU0:XR1(config)#segment-routing
RP/0/0/CPU0:XR1(config-sr)#?
apply-group Apply configuration from a group
apply-group-append Append apply-group configuration from a group
apply-group-remove Remove a group from apply-group configuration
clear Clear the uncommitted configuration
commit Commit the configuration changes to running
describe Describe a command without taking real actions
do Run an exec command
exclude-group Exclude apply-group configuration from a group
exclude-item Negate a command or set its defaults
exit Exit from this submode
global-block Prefix-SID Global label Block (SRGB)
mapping-server Segment Routing Mapping Server (SRMS)
no Negate a command or set its defaults
pwd Commands used to reach current submode
root Exit to the global configuration mode
show Show contents of configuration
What is the mapping-server and prefix-sid-map used for ?

LDP Configuration Removal

In this section, mpls configuration will be removed. It is expected, traffic will continue to use MPLS
dataplane and will be forwarded using segment routing.
Step 1: we are going to remove mpls ldp auto-config and mpls LDP from al the IOS-XR routers XR1, XR2,
XR3, XR4, XR5, XR6.
We are only showing the steps for XR1 below. The same steps need to be repeated on the other
routers also
no mpls ldp
router ospf 100
area 0
no mpls ldp auto-config
Step 2: After removal of MPLS configurationfrm all the routers, verify, if MPLS is still enabled on the
interfaces although there is no LDP enabled on the interfaces.
 Run “show mpls interface” to verify if the interfaces are still enabled for MPLS
RP/0/0/CPU0:XR1#show mpls interfaces
Interface LDP Tunnel Static Enabled

-------------------------- -------- -------- -------- --------
GigabitEthernet0/0/0/0 No No No Yes
GigabitEthernet0/0/0/1 No No No Yes
Why is MPLS enabled still on these interfaces ?
 Perform another traceroute to 10.10.6.6 and check if the labels are still being used


3 172.16.6.6 0 msec * 0 msec

 Check MPLS forwarding table to observe SR labels and SR prefix IDs with the below
command
------ ----------- ------------------ ------------ --------------- ------------
16002 Pop SR Pfx (idx 2) Gi0/0/0/0 172.16.1.2 72832
16003 Pop SR Pfx (idx 3) Gi0/0/0/1 172.16.3.3 71710
16004 16004 SR Pfx (idx 4) Gi0/0/0/1 172.16.3.3 0
16005 16005 SR Pfx (idx 5) Gi0/0/0/0 172.16.1.2 0
16006 16006 SR Pfx (idx 6) Gi0/0/0/0 172.16.1.2 0
16006 SR Pfx (idx 6) Gi0/0/0/1 172.16.3.3 106312
24001 Pop SR Adj (idx 0) Gi0/0/0/0 172.16.1.2 0
24002 Pop SR Adj (idx 0) Gi0/0/0/0 172.16.1.2 0
24003 Pop SR Adj (idx 0) Gi0/0/0/1 172.16.3.3 0
24004 Pop SR Adj (idx 0) Gi0/0/0/1 172.16.3.3 0
What types of MPLS labels are installed ?

Segment Routing Traffic Engineering Configuration

Segment routing enables you to steer the traffic in any arbitrary manner within the network, just
inserting the appropriate set of Node or Adj SID in the packet to express any deterministic paths.
In this section, we are going to configure traffic steering via segment routing. We are going to make traffic
go over XR1 – XR3 – XR4 – ASAv – XR6. We are not going to enable MPLS, rather, we will make use of
the segment routing for traffic steering.
XRv-2 XRv-5
Gi 0/0/0/1 Gi 0/0/0/0
10.10.2.2 10.10.5.5
10.10.6.6
10.10.1.1
XRv-1 XRv-6
172.16.8.6
Gi 0/0/0/2
Gi 0/1
10.10.3.3 10.10.4.4
Gi 0/0/0/1 Gi 0/0/0/0 172.16.8.4

Gi 0/0/0/2 Gi 0/0
XRv-3 XRv-4 ASAv-1
Traffic over the tunnel can be steered either dynamically or explicitly. Since, we are showing, how we can
use Segment Routing Traffic Engineering to steer the traffic, we will be using the explicit path
Note: On this Lab you are going to use the old way to configure a SR-TE path, by using a Tunnel-TE
interface. On recent releases (6.3) SR-TE path will be referered as SR-Policy paths (aligned with draft-
filsfils-spring-segment-routing-policy) and will be configured by using a new SR CLI (“traffic-engineer”
under “segment-routing” configuration group)
https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k-r6-3/segment-
routing/configuration/guide/b-segment-routing-cg-asr9000-63x/b-segment-routing-cg-asr9000-
63x_chapter_01110.html

Step 1: we are going to enable MPLS traffic engineering on all the routers XR1, XR2, XR3, XR4, XR5,
XR6
This is a important step. If traffic engineering process is not enabled on any of the
routers, TE-Tunnel wouldn’t come up
mpls traffic-eng
router ospf 100
mpls traffic-eng router-id loopback 0
area 0
mpls traffic-eng
Step 2: Check that mpls traffic engineering is enabled on every router and segment routing is in use. Use
“show mpls traffic-eng segment routing summary” to validate the status of the output.
o We should see all the loopback listed as well as the SR index values we configured in
section 2
RP/0/0/CPU0:XR1#show mpls traffic-eng segment-routing (summary)

RP/0/0/CPU0:XR1#show mpls traffic-eng segment-routing summary
IGP[0]:: OSPF 100 area 0 , Strict SPF Disabled

Nodes:
IGP Id: 10.10.1.1, MPLS TE Id: 10.10.1.1
Num of links with sr adj SID : 2
Total number of links : 2
IGP Id: 10.10.2.2, MPLS TE Id: 10.10.2.2

IGP Id: 10.10.3.3, MPLS TE Id: 10.10.3.3

IGP Id: 10.10.4.4, MPLS TE Id: 10.10.4.4

IGP Id: 10.10.5.5, MPLS TE Id: 10.10.5.5

IGP Id: 10.10.6.6, MPLS TE Id: 10.10.6.6


Prefix Information:
10.10.1.1/32, SID index: 1, flags: N
10.10.2.2/32, SID index: 2, flags: N
10.10.3.3/32, SID index: 3, flags: N
10.10.4.4/32, SID index: 4, flags: N
10.10.5.5/32, SID index: 5, flags: N
10.10.6.6/32, SID index: 6, flags: N
Total: IGP[0]:: OSPF 100 area 0 , Strict SPF Disabled

Node Count : 6
Adjacency-SID Count: 28
Prefix-SID Count : 6
Grand Total::
Node Count : 6
Adjacency-SID Count: 28
Prefix-SID Count : 6
IGP Areas Count : 1
RP/0/0/CPU0:XR1#show mpls traffic-eng segment-routing
IGP[0]:: OSPF 100 area 0 , Strict SPF Disabled

Nodes:
IGP Id: 10.10.1.1, MPLS TE Id: 10.10.1.1
Segment-Routing:
TE Node-SID Index: 1
SRGB Info: Start 16000, Size 8000
Link[0]:Point-to-Point, Nbr IGP Id:10.10.2.2, Nbr Node Id:1, gen:162

Frag Id:4, Intf Address:172.16.1.1, Intf Id:0
Segment-Routing Adjacency-SIDs: 2
Adjacency-SID[0]: 24011, Flags: V, L to Nbr:: IGP Id: 10.10.2.2, MPLS TE
Id: 10.10.2.2
Adjacency-SID[1]: 24010, Flags: B, V, L to Nbr:: IGP Id: 10.10.2.2, MPLS TE
Id: 10.10.2.2
Nbr Intf Address:172.16.1.2, Nbr Intf Id:0
TE Metric:1, IGP Metric:1
Ext Admin Group:
Length: 256 bits
Value : 0x::
Attribute Names:
Link[1]:Point-to-Point, Nbr IGP Id:10.10.3.3, Nbr Node Id:2, gen:163
Frag Id:5, Intf Address:172.16.3.1, Intf Id:0
Segment-Routing Adjacency-SIDs: 2
Adjacency-SID[0]: 24013, Flags: V, L to Nbr:: IGP Id: 10.10.3.3, MPLS TE
Id: 10.10.3.3

Adjacency-SID[1]: 24012, Flags: B, V, L to Nbr:: IGP Id: 10.10.3.3, MPLS TE

Id: 10.10.3.3
Nbr Intf Address:172.16.3.3, Nbr Intf Id:0
TE Metric:1, IGP Metric:1
Ext Admin Group:
Length: 256 bits
Value : 0x::
Attribute Names:
Step 3: In this step, explicit path will be defined to steer traffic through the desired path ( XR1 – XR3 –
XR4 – ASAv – XR6).
 Use the below steps to define explicit path for the traffic engineering tunnel at XR1. Verify
we are using the right IPs
explicit-path name SRTE
index 10 next-address strict ipv4 unicast 10.10.3.3
What other option is available for setting the MPLS/SR path ?
Step 4: After explicit path is defined, next step is to create the tunnel at XR-1 and attach the explicit path to
this tunnel destined to XR-6
int tunnel-te 16
ipv4 unnumbered loopback 0
destination 10.10.6.6
path-option 1 explicit name SRTE segment-routing
autoroute announce
What is the “autoroute tunnel” option ?
Step 5: Verify the tunnel is up with “show int tunnel-te 16”
RP/0/0/CPU0:XR1#sh int tunnel-te 16

tunnel-te16 is up, line protocol is up
Interface state transitions: 1
Hardware is Tunnel-TE
Internet address is 10.10.1.1/32
 Check the TE tunnel status to make sure path is valid. It should have a field “Binding SID”.
RP/0/0/CPU0:XR1#show mpls traffic-eng tunne segment-routing detail

Name: tunnel-te16 Destination: 10.10.6.6 Ifhandle:0xb0

Signalled-Name: XR1_t16
Status:
Admin: up Oper: up Path: valid Signalling: connected
path option 1, (Segment-Routing) type explicit SRTE (Basis for Setup)

G-PID: 0x0800 (derived from egress interface properties)
Bandwidth Requested: 0 kbps CT0
Creation Time: Fri May 25 03:16:48 2018 (00:21:49 ago)
Config Parameters:
Bandwidth: 0 kbps (CT0) Priority: 7 7 Affinity: 0x0/0xffff
Metric Type: TE (global)
Path Selection:
Tiebreaker: Min-fill (default)
Protection: any (default)
Hop-limit: disabled
Cost-limit: disabled
Path-invalidation timeout: 10000 msec (default), Action: Tear (default)
AutoRoute: enabled LockDown: disabled Policy class: not set
Forward class: 0 (default)
Forwarding-Adjacency: disabled
Autoroute Destinations: 0
Loadshare: 0 equal loadshares
Auto-bw: disabled
Path Protection: Not Enabled
BFD Fast Detection: Disabled
Reoptimization after affinity failure: Enabled
SRLG discovery: Disabled
SNMP Index: 9
Binding SID: 24014
History:
Tunnel has been up for: 00:18:42 (since Fri May 25 03:19:55 UTC 2018)
Current LSP:
Uptime: 00:18:42 (since Fri May 25 03:19:55 UTC 2018)
Current LSP Info:
Instance: 2, Signaling Area: OSPF 100 area 0
Uptime: 00:18:42 (since Fri May 25 03:19:55 UTC 2018)
Soft Preemption: None
SRLGs: not collected
Path Info:
Segment-Routing Path Info (OSPF 100 area 0)
Segment0[Node]: 10.10.3.3, Label: 16003
Segment1[Node]: 10.10.4.4, Label: 16004
Segment2[Link]: 172.16.8.4 - 172.16.8.6, Label: 24014
Persistent Forwarding Statistics:

Out Bytes: 0
Out Packets: 0
Displayed 1 (of 1) heads, 0 (of 0) midpoints, 0 (of 0) tails
Displayed 1 up, 0 down, 0 recovering, 0 recovered heads

What type of Adj SID was selected for the path between XR-4 and XR-6 ? protected or unprotected ?
Step 6: Force the SR-TE Path to use a protected Adj-SI between XR-4 and XR-6, and check again
RP/0/RSP1/CPU0:XR-1(config)#int tunnel-te 16
RP/0/RSP1/CPU0:XR-1(config-if)#path-selection segment-routing adjacency ?
protected Use only protected adjacencies
unprotected Use only unprotected adjacencies
Step 7 Binding SID: Router allocates a locally significant binding SID label (static/dynamic) for each
RSVP/SR TE tunnel interface, which can be used to enforce traffic engineering (TE) policy using RSVP-TE
or SR-TE label switching path (LSP) tunnel. If the topmost label of an incoming packet is the binding SID,
the packet is steered to the appropriate LSP tunnel. As such, a SID can be used by an upstream router to
steer traffic originating from a downstream router into the appropriate TE path.
 This field should match with the outgoing mpls-te tunnel interface 16. Run the below commands
to validate this behavior
RP/0/0/CPU0:XR1#show mpls forwarding (detail)

------ ----------- ------------------ ------------ --------------- ------------
16002 Pop SR Pfx (idx 2) Gi0/0/0/0 172.16.1.2 80
16003 Pop SR Pfx (idx 3) Gi0/0/0/1 172.16.3.3 80
16004 16004 SR Pfx (idx 4) Gi0/0/0/1 172.16.3.3 0
16005 16005 SR Pfx (idx 5) Gi0/0/0/0 172.16.1.2 0

16006 16006 SR Pfx (idx 6) Gi0/0/0/1 172.16.3.3 0

16006 SR Pfx (idx 6) Gi0/0/0/0 172.16.1.2 0
24010 Pop SR Adj (idx 0) Gi0/0/0/0 172.16.1.2 0
24011 Pop SR Adj (idx 0) Gi0/0/0/0 172.16.1.2 0
24012 Pop SR Adj (idx 0) Gi0/0/0/1 172.16.3.3 0
24013 Pop SR Adj (idx 0) Gi0/0/0/1 172.16.3.3 0
24014 Pop No ID tt16 point2point 0
Step 8: Verify the routing table on XR1 is using TE16 as next hop for 10.10.6.6
RP/0/0/CPU0:XR1#show route 10.10.6.6
Routing entry for 10.10.6.6/32

Known via "ospf 100", distance 110, metric 4, labeled SR, type
intra area
Installed May 25 03:19:55.946 for 00:30:54
Routing Descriptor Blocks
10.10.6.6, from 10.10.6.6, via tunnel-te16
Route metric is 4
No advertising protos.
RP/0/0/CPU0:XR1#show cef 10.10.6.6/32
10.10.6.6/32, version 51, internal 0x1000001 0x83 (ptr 0xa14223f4)

[1], 0x0 (0xa13edcb0), 0xa20 (0xa15132d0)
Updated Mar 27 20:46:47.696
Prefix Len 32, traffic index 0, precedence n/a, priority 1
via 10.10.6.6/32, tunnel-te16, 7 dependencies, weight 0, class 0
[flags 0x0]
path-idx 0 NHID 0x0 [0xa0f695ec 0x0]
next hop 10.10.6.6/32
local adjacency
labels imposed {None}
Why it shows as there is no label imposition ?
Step 9: Now, if we do the trace again, we expect traffic to pass via XR1 – XR3 – XR4 – ASAv – XR6.

1 * * *
2 * * *
3 172.16.8.6 0 msec * 0 msec

 172.16.8.6 is the interface ip of the XR4 interface (gig0/0/0/2) connected to ASAv.
SR TI-LFA Protection
This lab explores the Segment Routing (SR) Topology Independent Loop-Free Alternative (TI-
LFA) functionality. The lab illustrates that TI-LFA can protect traffic flows against link failure This
scenario demonstrates how to configure TI-LFA link protection and verify the TI-LFA backup path.
During the lab, the protection of a traffic flow is examined hop by hop. Using this method, multiple
types of TI-LFA repair paths are encountered.
TI-LFA computes backup paths for all destinations. TI-LFA not only protects SR carried traffic, but
also plain IP traffic can be protected, only imposing a SR label stack when a failure occurs. TI-LFA
protects LDP-carried traffic as well, but that is outside of the scope of this lab.
Step 1: Enable TI-LFA on all nodes in this environment. It can be done per OSPF Area or per
interface,
router ospf 100

area 0
fast-reroute per-prefix
fast-reroute per-prefix ti-lfa enable
This configuration enables TI-LFA for both address families. TI-LFA computes backup paths for all
destinations (per-prefix). TI-LFA calculates the loop-free post-convergence path to each
destination and install on forwarding table to use in case of link failure.
Step 2: Verify backup path in RIB. OSPF installs the backup path in RIB to reach each
destination marked as. RIB contains the primary path (Protected) and backup path
(Backup) marked as (!)
RP/0/0/CPU0:XR1#show route
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - ISIS, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, su - IS-IS summary null, * - candidate default
U - per-user static route, o - ODR, L - local, G - DAGR, l - LISP
A - access/subscriber, a - Application route

M - mobile route, r - RPL, (!) - FRR Backup path
Gateway of last resort is not set
L 10.10.1.1/32 is directly connected, 11:13:59, Loopback0

[110/0] via 172.16.3.3, 00:29:31, GigabitEthernet0/0/0/1 (!)
O 10.10.3.3/32 [110/0] via 172.16.1.2, 00:29:31, GigabitEthernet0/0/0/0 (!)
L 127.0.0.0/8 [0/0] via 0.0.0.0, 10:16:23
C 172.16.1.0/24 is directly connected, 11:13:59, GigabitEthernet0/0/0/0
L 172.16.1.1/32 is directly connected, 11:13:59, GigabitEthernet0/0/0/0
C 172.16.3.0/24 is directly connected, 05:59:14, GigabitEthernet0/0/0/1
L 172.16.3.1/32 is directly connected, 05:59:14, GigabitEthernet0/0/0/1
Notice that the output of the show route 10.10.2.2 command displays the backup path for
10.10.2.2/32 as FRR backup. Traffic is steered towards XRv-3 (Gi0/0/0/1).  
RP/0/0/CPU0:XR1#show route 10.10.2.2
Routing entry for 10.10.2.2/32

Known via "ospf 100", distance 110, metric 2, labeled SR, type intra area
Installed May 27 02:03:28.771 for 00:30:03
Routing Descriptor Blocks
172.16.1.2, from 10.10.2.2, via GigabitEthernet0/0/0/0, Protected
Route metric is 2
172.16.3.3, from 10.10.2.2, via GigabitEthernet0/0/0/1, Backup (remote)
Remote LFA is 10.10.6.6
Route metric is 0
No advertising protos.

XRv-1, for a failure of the link to XRv2, goes via Xrv-3. XRv-3 provides a Loop-Free Alternate
(LFA) path to destination XRv-2.
XRv-2 XRv-5
Gi 0/0/0/1 Gi 0/0/0/0
10.10.2.2 10.10.5.5 16002
10.10.6.6
10.10.1.1
XRv-1 XRv-6
172.16.8.6
Gi 0/0/0/2
Gi 0/1
10.10.3.3 10.10.4.4
Gi 0/0/0/1 Gi 0/0/0/0 172.16.8.4

16006 Gi 0/0/0/2 Gi 0/0
16002 XRv-3 XRv-4 ASAv-1
TI-LFA computes the post-convergence path on XRv-1 for destination Xrv-2 by computing the IGP
shortest path to Xrv-2 on the topology with the link XRv-1 to XRv-2 removed. TI-LFA then
computes the segment-list required to steer the packets on that backup path and finds that one
intermediate nodes is needed: xrvr-6 (the PQ-node). So ther TI-LFA computation on XRFv-1 for
destination Xrv-2 (post-convergence path) results in two additional labels to be imposed on
protected packets. steered on the backup path:
 Label 16006 to XRv-6 (PQ Node)

 Label 16002 to final destination. , xrvr-11 simply forwards them to xrvr-5.
RP/0/0/CPU0:XR1#sh cef 10.10.2.2/32 det
10.10.2.2/32, version 87, internal 0x1000001 0x81 (ptr 0xa1421ef4) [1], 0x0
(0xa13ed4f4), 0xa28 (0xa17b80d4)
Updated May 27 02:03:28.792
local adjacency 172.16.1.2
Prefix Len 32, traffic index 0, precedence n/a, priority 1

gateway array (0xa12b6fcc) reference count 3, flags 0x1400068, source rib (7), 0
backups
[3 type 4 flags 0x8401 (0xa159d500) ext 0x0 (0x0)]
LW-LDI[type=1, refc=1, ptr=0xa13ed4f4, sh-ldi=0xa159d500]
gateway array update type-time 1 May 27 02:03:28.792
LDI Update time May 27 02:03:28.792
LW-LDI-TS May 27 02:03:28.792
via 172.16.1.2/32, GigabitEthernet0/0/0/0, 10 dependencies, weight 0, class 0,
protected [flags 0x400]
path-idx 0 bkup-idx 1 NHID 0x0 [0xa0c9c6b0 0xa0c9c5c8]
next hop 172.16.1.2/32
local label 16002 labels imposed {ImplNull}
via 172.16.3.3/32, GigabitEthernet0/0/0/1, 10 dependencies, weight 0, class 0, backup
(remote) [flags 0x8300]
path-idx 1 NHID 0x0 [0xa10e449c 0x0]
next hop 172.16.3.3/32, PQ-node 10.10.6.6
local adjacency
local label 16002 labels imposed {16006 16002}
Load distribution: 0 (refcount 3)
Hash OK Interface Address

0 Y GigabitEthernet0/0/0/0 172.16.1.2
Notice that not only incoming unlabeled IP traffic is protected (as shown in the CEF entry)
but also incoming labeled traffic. The output of show mpls forwarding displays the
primary path and backup path for packets with the prefix-SID label of xrvr-2, 16002
RP/0/0/CPU0:XR1#show mpls for labels 16002 det
Step 3 Protected Adj-SID: By enabling TI-LFA on a link, the adjacency-SIDs of that link are also
protected.
RP/0/0/CPU0:XR1#show ospf ne det


DR is 0.0.0.0 BDR is 0.0.0.0

Options is 0x52
First 0(0)/0(0) Next 0(0)/0(0)
Adjacency SID Label: 24010, Protected

DR is 0.0.0.0 BDR is 0.0.0.0
Options is 0x52
First 0(0)/0(0) Next 0(0)/0(0)
Adjacency SID Label: 24012, Protected
Total neighbor count:
The adjacency-SID for the adjacency of Xrv-1 to XRv-2 (24010) is protected via the link to
XRv-3. Verify the backup path in the MPLS forwarding table.The backup path goes via PQ-
node XRv-6. Verify adjacency protection in the MPLS forwarding table.
RP/0/0/CPU0:XR1#show mpls for labels 24010 det

------ ----------- ------------------ ------------ --------------- ------------
24010 Pop SR Adj (idx 0) Gi0/0/0/0 172.16.1.2 0
Updated: May 27 02:03:28.792
Path Flags: 0x400 [ BKUP-IDX:1 (0xa0c9c6b0) ]
Version: 74, Priority: 1
Label Stack (Top -> Bottom): { Imp-Null }
NHID: 0x0, Encap-ID: N/A, Path idx: 0, Backup path idx: 1, Weight: 1
MAC/Encaps: 14/14, MTU: 1500

Packets Switched: 0
16006 SR Adj (idx 0) Gi0/0/0/1 172.16.3.3 0 (!)

Updated: May 27 02:03:28.792
Path Flags: 0x100 [ BKUP, NoFwd ]
Version: 74, Priority: 1
Label Stack (Top -> Bottom): { 16006 16002 }
NHID: 0x0, Encap-ID: N/A, Path idx: 1, Backup path idx: 0, Weight: 6
MAC/Encaps: 14/22, MTU: 1500
Packets Switched: 0
The IPv4 protected adjacency-SID for the adjacency to XRv-2 is 24010 in the output.
Notice that the MPLS forwarding entry of the adjacency-SID shows the primary path and
the backup path. The backup path for an adjacency-SID steers the traffic to the remote end
of the link. In this case, XRv-1 imposes the prefix-SID of XRv-6 y XRv-2 on protected
packets.
NOTE: Only the protected adjacency-SID is protected; the non-protected or non-FRR

adjacency-SID stays unprotected. The protected IPv4 adjacency-SID is 24010 in this
example. Because the label is dynamically allocated, the label value may vary.

References
Learn more about Segment Routing by doing extra vLabs at dCloud !
Cisco Segment Routing v3

https://dcloud2-sjc.cisco.com/content/demo/565
 Cisco Segment Routing (SR) is a network technology that provides enhanced packet-
forwarding behavior while minimizing the need for maintaining awareness of mass volumes
of network state. This technology is currently running on the VIRL 293 Sandbox. This
demonstration, Cisco Segment Routing v3, showcases some of the functionality of Cisco
SR.
 Demonstrate the use of Segment Routing in IOS XR (lab) - Show the configuration and
verification of Segment Routing using IS-IS as the control plane and MPLS as the data
plane.
 Demonstrate the use of segment routing in a VPNv4/VPNv6 over IPv4/MPLS network
with IS-IS - Show how MPLS services can be carried over a Segment Routing Network
with IS-IS. Show the simplicity of Segment Routing technology.
 Demonstrate how segment routing can coexist and interwork with LDP - Show how
Segment Routing can be introduced in legacy networks using LDP. Show how legacy LDP
devices can be integrated in a Segment Routing network.
 Demonstrate the use of ISIS unicast multi-topology applied to segment routing as a
Traffic Engineering tool - Show how Segment Routing combined with ISIS multi-topology
for unicast can help to solve specific use-cases: CoS-based routing and Path disjointness.
For Cos-based routing, separate paths can be established for different traffic classes using
Segment Routing. Path disjointness enables routing devices to steer traffic along disjoint
paths using Segment Routing. Notice: The ISIS multi-topology unicast with Segment
Routing feature is a prototype and is not committed to any release.
 Demonstrate the use of segment routing in a VPNv4/VPNv6 over IPv4/MPLS network
with OSPF - Show how MPLS services can be carried over a Segment Routing Network
with OSPF. Show the simplicity of Segment Routing technology.
 Demonstrate the functionality of Topology Independent LFA using segment routing -
Show how Segment Routing provides a simple automated method to provide fast-reroute
protection for link failures in any topology. The SR/LDP interworking functionality allows
users to introduce TI-LFA in a network that contains legacy LDP devices

Cisco Service Provider SDN Segment Routing in Action Sandbox v2

The Cisco® Service Provider SDN Segment Routing in Action sandbox explores the following
concepts and exercises:
 Segment Routing (SR) configuration in IOS-XR and IOS-XE

 LDP to SR migration steps
 SR verification and monitoring
 Topology-Independent Loop Free Alternate (TI-LFA) configuration and verification
 SR On-Demand Next-Hop (ODN) for on-demand instantiation of SR policies
 Automatic traffic steering onto SR policies without performance degradation
 Cisco® IOS XR - XR Transport Controller (XTC) acting as stateful SR PCE for multi-
domain SR-TE policies
 IOS XR (XTC) as controller relying on BGP to distribute SR policy to a head end
 New SR-TE infra for IOS-XR head-end nodes
 New BGP SAFI/NLRI to distribute SR policies to head-end nodes
 Cisco WAN Automation Engine (WAE) for multi-domain Network / LSP discovery and
automation leveraging northbound APIs on XTC
 Cisco Network Services Orchestrator (NSO) for faster and more reliable service
orchestration
Cisco Segment Routing Inter-Domain SRTE ISIS Lab v1

This lab provides information about Segment Routing Traffic Engineering (SRTE) and
demonstrates how SRTE leverages Segment Routing (SR) functionality to provide end-to-end,
inter-domain traffic steering.
In this lab, you will learn how to specify inter-domain explicit paths using both old configuration
commands and new SRTE-specific configuration commands. Explore the IOS XR-based Path
Computation Element (PCE) XR Transport Controller (XTC). Learn how XTC receives topology
and SID information through IGP or BGP link-state (BGP-LS) and handles path computations
through PCEP. Fundamentally, the XTC deployment model is distributed similarly to BGP route
reflector (RR) deployments. You can also use XTC to compute dynamic paths for locally
configured SR policies.
This lab also shows how to automatically instantiate SR policies for services by attaching a BGP
community to the service prefixes by using on-demand next-hop (ODN). The service in this lab is
a VPNv4 service. These SR policies can be instantiated to provide scalable inter-domain, best-
effort reachability or provide a policy-aware, end-to-end inter-domain path for the service traffic.

XTC also computes inter-domain disjoint paths, even from distinct head-ends, by simply indicating
which paths must be disjoint.
Cisco Segment Routing Series 2 - Inter-Domain SRTE ISIS IOS XE

Lab v1
This lab provides information about Segment Routing Traffic Engineering (SRTE) and
demonstrates how SRTE leverages Segment Routing (SR) functionality to provide end-to-end,
inter-domain traffic steering.
In this lab, you will learn how to specify inter-domain explicit paths using both old configuration
commands and new SRTE-specific configuration commands. Explore the IOS XR-based Path
Computation Element (PCE) XR Transport Controller (XTC). Learn how XTC receives topology
and SID information through IGP or BGP link-state (BGP-LS) and handles path computations
through PCEP. Fundamentally, the XTC deployment model is distributed similarly to BGP route
reflector (RR) deployments. You can also use XTC to compute dynamic paths for locally
configured SR policies.
This lab also shows how to automatically instantiate SR policies for services by attaching a BGP
community to the service prefixes by using on-demand next-hop (ODN). The service in this lab is
a VPNv4 service. These SR policies can be instantiated to provide scalable inter-domain, best-
effort reachability or provide a policy-aware, end-to-end inter-domain path for the service traffic.
XTC also computes inter-domain disjoint paths, even from distinct head-ends, by simply indicating
which paths must be disjoint.
Cisco Segment Routing VPNv4 and VPNv6 over IPv4 ISIS SR MPLS
Lab v1
This lab demonstrates how to use Segment Routing (SR) in a VPNv4/VPNv6 over IPv4/MPLS
network. The VPN prefixes automatically leverage the SR information of their BGP next hop. SR
applied to the MPLS data plane enables the ability to tunnel services, such as VPN, VPLS, and
VPWS, from an ingress Provider Edge (PE) to an egress PE, without any protocol other than ISIS
or OSPF. LDP and RSVP-TE signaling protocols are not required. By allocating one prefix
segment per PE, the SR IGP control plane automatically builds the required MPLS forwarding
constructs from any PE to any PE.

Cisco Segment Routing Series 2 - VPNv4 and VPNv6 over IPv4-MPLS

ISIS IOS XE Lab v1
This lab demonstrates how to use Segment Routing (SR) in a VPNv4/VPNv6 over IPv4/MPLS
network. The VPN prefixes automatically leverage the SR information of their BGP next hop. SR
applied to the MPLS data plane enables the ability to tunnel services, such as VPN, VPLS, and
VPWS, from an ingress Provider Edge (PE) to an egress PE, without any protocol other than ISIS
or OSPF. LDP and RSVP-TE signaling protocols are not required. By allocating one prefix
segment per PE, the SR IGP control plane automatically builds the required MPLS forwarding
constructs from any PE to any PE.
Segment Routing Traffic Engineering Lab v1

This lab provides hands-on experience with segment routing traffic engineering (SR-TE)
configuration and operation. The OpenDaylight (ODL) SDN controller is used with northbound
REST APIs. Basic knowledge of segment routing (SR) or MPLS, traffic engineering (TE), and IS-
IS and familiarity with Cisco® IOS XR configuration are required.
Cisco Segment Routing Topology Independent Loop-Free Alternate

Lab v1
This lab explores the Segment Routing (SR) Topology Independent Loop-Free Alternative (TI-
LFA) functionality. During the demonstration, the protection of a traffic flow is examined hop by
hop. Using this method, multiple types of TI-LFA repair paths are encountered.
TI-LFA not only protects SR-carried traffic, but it also protects plain IP traffic, only imposing an SR
label stack when a failure occurs. TI-LFA protects LDP-carried traffic as well, but that is outside of
the scope of this demonstration.
The demonstration illustrates that TI-LFA can protect traffic flows against link failures, but also
against node failures and local Shared Risk Link Groups (SRLG) failures.
Cisco Segment Routing BGP Prefix-SID in Inter-AS Network Lab v1

This lab explores the use of BGP prefix-SIDs in an inter-AS setup. L3VPN inter-AS option C is
used in the setup. BGP prefix-SIDs provide inter-AS connectivity between the Provider Edges
(PEs) as well as between the route reflectors (RR s) in the different autonomous systems (AS).

The classical L3VPN inter-AS option C functionality is then applied to the network. BGP prefix-SID
functionality automatically interworks between a Segment Routing (SR) enabled and a non-SR
enabled AS.
Cisco Segment Routing LDP Coexistence Internetworking Lab v1

This lab requires familiarity with the Cisco® networking architecture and routing fundamentals.
This lab explores how to use Segment Routing (SR) in an LDP coexistence-internetworking
environment and how to migrate an LDP-based network to an SR-based network.
Cisco WAN Automation Engine 7.1 - Segment Routing and XTC

Sandbox v1
The Cisco WAN Automation Engine (WAE) is a powerful, flexible, software-defined networking
(SDN) platform. It abstracts and simplifies your WAN environment while making it fully open and
programmable. WAE network-modeling technology enables real-time analysis of traffic needs and
traffic placement in complex WAN topologies.
This is a sandbox intended for self-study, and it provides a variety of scenarios that interact with
numerous components of WAE. You will interact with the WAE platform across a set of APIs and
technologies, including Cisco Network Services Orchestrator (NSO), Segment Routing, MPLS,
PCEP, and BGP-LS.

Cisco MPLS Segment Routing Introduction v2 1

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cisco MPLS Segment Routing Introduction v2 1

Uploaded by

Copyright:

Available Formats

MPLS Segment Routing Introduction Lab

MPLS Segment Routing Introduction v2

dCloud: The Cisco Demo Cloud

08-24-2018, Version 2.0

© 2018 Cisco and/or its affiliates. All rights reserved. Page 1 of 50

Segment Routing Introduction:

© 2018 Cisco and/or its affiliates. All rights reserved. Page 2 of 50

There are two types of Segment IDs for Segment Routing:

© 2018 Cisco and/or its affiliates. All rights reserved. Page 3 of 50

Node Segment Imposition

Adjacency Segment: An adjacency segment (or Adj-SID, or A-SID) is associated with an

© 2018 Cisco and/or its affiliates. All rights reserved. Page 4 of 50

routing. The implementation is based on the “draft-ietf-ospf-segment-routing-extensions” via new

Segment Routing Advantages

. Simplify the Transport by having few protocols to operate

© 2018 Cisco and/or its affiliates. All rights reserved. Page 5 of 50

Configure segment routing

Verify segment routing labels

Steer traffic using SRTE

© 2018 Cisco and/or its affiliates. All rights reserved. Page 6 of 50

 Segment routing traffic engineering tunnel is built on XR1

Gi 0/0/0/1 Gi 0/0/0/0 172.16.8.4

XRv-3 XRv-4 ASAv-1

VIRL  Virtual environment for building network topologies

 Simulation of networking components

 Support for third-party VMs

 Capture and analyze network traffic at any node

 Validate configurations prior to physical deployment

© 2018 Cisco and/or its affiliates. All rights reserved. Page 7 of 50

 A valid CCO user to log into dCloud

© 2018 Cisco and/or its affiliates. All rights reserved. Page 8 of 50

Below is an example of user logging into POD1

© 2018 Cisco and/or its affiliates. All rights reserved. Page 9 of 50

© 2018 Cisco and/or its affiliates. All rights reserved. Page 10 of 50

 Enter the credentials Administrator / C1sco12345 to login to your POD

© 2018 Cisco and/or its affiliates. All rights reserved. Page 11 of 50

© 2018 Cisco and/or its affiliates. All rights reserved. Page 12 of 50

Component Access options Credentials

XR1 198.18.1.31 cisco/cisco

© 2018 Cisco and/or its affiliates. All rights reserved. Page 13 of 50

XRv-3 XRv-4 ASAv-1

Router Name IP Address

© 2018 Cisco and/or its affiliates. All rights reserved. Page 14 of 50

© 2018 Cisco and/or its affiliates. All rights reserved. Page 15 of 50

ROM: GRUB, Version 1.99(0), DEV RELEASE

XR1 uptime is 23 minutes

Node Type PLIM State Config State

RP/0/0/CPU0:XR1#sh int brief

Intf Intf LineP Encap MTU BW

© 2018 Cisco and/or its affiliates. All rights reserved. Page 16 of 50

Nu0 up up Null 1500 0

RP/0/0/CPU0:XR1#show cdp neighbor

Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge

Device ID Local Intrfce Holdtme Capability Platform Port ID

 Look into the running configuration

RP/0/0/CPU0:XR1#show ospf interfaces (brief)

Interfaces for OSPF 100

Interface PID Area IP Address/Mask Cost State Nbrs F/C

 Verify that OSPF neighbour is established on all the routers

* Indicates MADJ interface

Neighbors for OSPF 100

Neighbor ID Pri State Dead Time Address Interface

© 2018 Cisco and/or its affiliates. All rights reserved. Page 17 of 50

Neighbor is up for 22:16:51

Configure segment routing  

Verify segment routing labels  

Steer traffic using SRTE  