Cisco dCloud

Cisco Segment Routing Series 2 – Inter-Domain SRTE

ISIS IOS XE Lab v1
Last Updated: 31-OCTOBER-2017

About This Lab

This guide for the preconfigured Cisco ® Segment Routing Inter-Domain Traffic Engineering lab includes:

• About This Lab

• Requirements

• About This Solution

• Topology

• Get Started

• Scenario 1: Explore Topology

• Scenario 2: Configure SR Policy Explicit Path Using Old CLI

• Scenario 3: Explore XTC

• Scenario 4: Configure SR Dynamic Path Policy

• Scenario 5: Use ODN for Reachability

• Scenario 6: Use ODN with Service Policy

• Scenario 7: Use ODN with Disjoint Service

Limitations
This lab uses CSR1000v and IOS XRv nodes. Some data plane functionality may not work on this platform.

Requirements
The table below outlines the requirements for this preconfigured lab.

Table 1. Requirements

Required Optional

● Router, registered and configured for Cisco dCloud ● Cisco AnyConnect

● Laptop
● Laptop with Cisco AnyConnect®

© 2017 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 1 of 46
 Cisco dCloud

About This Solution

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. Explore the IOS XR-based Path Computation Element (PCE),
XR Transport Controller (XTC) and learn how XTC receives topology and SID information through IGP or BGP-LS and handles
path computations through PCEP. Fundamentally, the XTC deployment model is distributed similarly to BGP 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.

This lab requires familiarity with networking architecture and routing fundamentals. For more information about SR, refer to
www.segment-routing.net.

Topology
Figure 1. dCloud Topology

© 2017 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 2 of 46
 Cisco dCloud

Get Started
BEFORE PRESENTING

Cisco dCloud strongly recommends that you perform the tasks in this document with an active session before presenting in front
of a live audience. This will allow you to become familiar with the structure of the document and content.

It may be necessary to schedule a new session after following this guide in order to reset the environment to its original
configuration.

PREPARATION IS KEY TO A SUCCESSFUL PRESENTATION.

Follow the steps to schedule a session of the content and configure your presentation environment.

1. Initiate your dCloud session. [Show Me How]

NOTE: It may take up to 10 minutes for your session to become active.

2. For best performance, connect to the workstation with Cisco AnyConnect VPN [Show Me How] and the local RDP client on
your laptop [Show Me How]

• Workstation 1: 198.18.133.36, Username: administrator, Password: C1sco12345

Access Routers

NOTE: Throughout the scenarios in this lab, you will log in to several Cisco IOS XRv routers.

1. From the workstation desktop, open the Routers folder.

2. Double-click any router to access the terminal.

3. Log in with Username: cisco, Password: cisco.

NOTE: The login steps and credentials are identical for all 14 routers available in the lab environment.

© 2017 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 3 of 46
 Cisco dCloud

Scenario 1. Explore Topology

This scenario explores the network topology. The network topology consists of three level 2-only Intermediate System to
Intermediate System (IS-IS or ISIS) domains. Domain1 and Domain2 are interconnected with two BGP peering links: one between
xrvr-3 and xrvr-5 and another between xrvr-4 and xrvr-6. Domain2 and Domain3 are interconnected via border nodes xrvr-7 and
csr-8. These border nodes run two ISIS instances, one for each domain. The nodes are a mix of IOS XRv and CSR1000v nodes.
The type of each node is indicated by its name (xrvr-N for IOS XRv, and csr-N for CSR1000v nodes) as well as by its icon in the
network topology of Figure 2.

Each domain has an AS number, as shown in Table 2.

Table 2. Domain AS Numbers

Domain AS Number

Domain1 64001

Domain2 64002

Domain3 64003

Figure 2. Network Topology

© 2017 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 4 of 46
 Cisco dCloud

Addressing Conventions

Loopback0 prefix of node xrvr-X: 1.1.1.X/32

Prefix-SID of node xrvr-X: 16000 + X

Interface address of link xrvr-X  xrvr

-Y: 99.X.Y.X (with X < Y)

NOTE: Some labels and values in this lab are dynamically assigned. Labels and values in your session may differ from those
shown in the example output.

Steps
1. On csr-1, enter the following command to verify reachability of the csr-10 loopback prefix 1.1.1.10/32. The domains are
independent; there is no redistribution between them nor is there BGP route exchange.
csr-1#a1
csr-1#show ip route 1.1.1.10 255.255.255.255

% Subnet not in table

NOTE: Command aliases have been configured (a1, a2, b1, and so forth) to reduce the amount of typing in this lab. Use of these
aliases is not required.

NOTE: Multi-command aliases do not exist in IOS XE. Therefore, an applet “exec” is provided that executes multi-command
aliases. This applet is also used for configuration aliases. To use the applet, simply add the command “exec” before the alias, e.g.
“exec a1”. You can use the applet for each alias, but for the multi-command aliases its use is required if you desire to use the alias.
This is indicated in this document by including the “exec” keyword.

NOTE: IOS XE does not show the command of the alias when executing an alias. Use the “exec” applet to execute the alias to
display the alias command before executing it.

2. On csr-1, enter the following command to verify that segment routing is enabled in all three domains:
csr-1#a2
csr-1#show running | section ^router isis
router isis 1
net 49.0001.0000.0000.0001.00
is-type level-2-only
metric-style wide
distribute link-state instance-id 101
segment-routing mpls
fast-reroute per-prefix level-2 all
fast-reroute ti-lfa level-2
mpls traffic-eng router-id Loopback0
mpls traffic-eng level-2

3. Verify the prefix-SID configuration of csr-1:

csr-1#a3
csr-1#show running | section ^segment-routing
segment-routing mpls
global-block 16000 23999

© 2017 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 5 of 46
 Cisco dCloud

!
connected-prefix-sid-map
address-family ipv4
1.1.1.1/32 absolute 16001 range 1
exit-address-family
!

4. Verify the ISIS prefix-SID table on csr-1:

NOTE: This command is hidden in the current release.

csr-1#a4
csr-1#show isis rib prefix-sid

IS-IS 1 Prefix-SIDs:

EN - Prefix-SID exceeded next hop SRGB range

EL - Prefix-SID exceeded local SRGB range
AL - Label allocation failure from MFI
MS - Prefix-SID is via mapping server

Local SRGB Base: 16000

Type Address SID Index Local Label Source Codes

L2 1.1.1.2/32 2 16002 csr-2.00-00
L2 1.1.1.3/32 3 16003 xrvr-3.00-00
L2 1.1.1.4/32 4 16004 xrvr-4.00-00
4 16004 xrvr-4.00-00

NOTE: In this example, SR is not enabled on nodes xrvr-11, xrvr-12, xrvr-13, and xrvr-14. However, the operator can choose to
enable SR on these nodes as well.

5. MPLS TE is enabled globally and as well as under the IGP on the nodes in each domain to advertise the TE link attributes.
Note that RSVP is not enabled because it is not used for SRTE. In this example, TE is not enabled on nodes xrvr-11, xrvr-12,
xrvr-13, and xrvr-14. However, the operator can choose to enable TE on these nodes as well. MPLS TE configuration on csr-
1:
csr-1#a5
csr-1#show running | section ^router isis
router isis 1
net 49.0001.0000.0000.0001.00
is-type level-2-only
metric-style wide
distribute link-state instance-id 101
segment-routing mpls
fast-reroute per-prefix level-2 all
fast-reroute ti-lfa level-2
mpls traffic-eng router-id Loopback0
mpls traffic-eng level-2

6. Each node feeds its local TE database (TED) with the topology information of its local domain. Verify the information from
node csr-2 in the TED of csr-1:
csr-1#a6
csr-1#show mpls traffic-eng topo 1.1.1.2 brief

© 2017 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 6 of 46
 Cisco dCloud

IGP Id: 0000.0000.0002.00, MPLS TE Id:1.1.1.2 Router Node (isis level-2)

link[0]: Point-to-Point, Nbr IGP Id: 0000.0000.0001.00, nbr_node_id:2, gen:6
frag_id: 0, Intf Address: 99.1.2.2, Nbr Intf Address: 99.1.2.1
TE metric: 10, IGP metric: 10, attribute flags: 0x0
SRLGs: None

link[1]: Point-to-Point, Nbr IGP Id: 0000.0000.0004.00, nbr_node_id:6, gen:6

frag_id: 0, Intf Address: 99.2.4.2, Nbr Intf Address: 99.2.4.4
TE metric: 10, IGP metric: 10, attribute flags: 0x0
SRLGs: None

csr-1#a7
csr-1#show mpls traffic-eng segment-routing 1.1.1.2

IGP Area[1]: isis level-2, Strict SPF Disabled:

Nodes:
IGP Id: 0000.0000.0002.00, MPLS TE Id: 1.1.1.2, ISIS level-2
SRGB[0] - Start: 16000, Size: 8000
Link[0]: Intf Addr: 99.1.2.2, Nbr Intf Addr: 99.1.2.1, Type: Point-to-Point
Nbr IGP Id: 0000.0000.0001.00, Nbr MPLS TE Id: 1.1.1.1
Label: 16, flags: V, L Label: 17, flags: B, V, L
Link[1]: Intf Addr: 99.2.4.2, Nbr Intf Addr: 99.2.4.4, Type: Point-to-Point
Nbr IGP Id: 0000.0000.0004.00, Nbr MPLS TE Id: 1.1.1.4
Label: 18, flags: V, L Label: 19, flags: B, V, L
Prefixes:
1.1.1.2/32, SID index: 2
Adv. router(s)
--------------
0000.0000.0002.00, Backup (Y/N): N, flags: N
Paths
-----
No paths

Node csr-2 advertises prefix 1.1.1.2 with prefix-SID 16002 (index 2 and SRGB [16000-23999]). It has two links: to csr-1 and to xrvr-
4. Both links have TE and IGP metric 10. Two adjacency-SIDs are advertised for each link: one protected and one unprotected.
For the link to csr-1 (link[0]), protected adj-SID 17 and unprotected adj-SID 16.

L3VPN services run between PEs csr-1, csr-2, csr-9, and csr-10. The L3VPN service routes are exchanged between the domains
through service route-reflectors xrvr-12, xrvr-13, and xrvr-14. The loopback prefixes of these RRs are the only prefixes
redistributed between the domains, so the RRs can reach each other.

7. Enter the following command to see the prefix 100.1.1.10/32 in vrf LIVE advertised in csr-10. Csr-1 receives this
advertisement and installs it in RIB, but no traffic is sent to it because there is no MPLS LSP to the BGP next-hop, 1.1.1.10.
csr-1#a8
csr-1#show bgp vrf LIVE 100.1.1.10/32
BGP routing table entry for 1.1.1.1:0:100.1.1.10/32, version 7
Paths: (1 available, best #1, table LIVE)
Not advertised to any peer
Refresh Epoch 1
64003, imported path from 1.1.1.10:0:100.1.1.10/32 (global)
1.1.1.10 (via default) from 1.1.1.12 (1.1.1.12)
Origin IGP, localpref 100, valid, internal, best
Extended Community: RT:1:100

© 2017 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 7 of 46
 Cisco dCloud

mpls labels in/out nolabel/21

rx pathid: 0, tx pathid: 0x0

8. Enter the following command and notice the cef entry of vrf LIVE 100.1.1.10/32 is unresolved because there is no labeled path
to the next-hop. A static route for 1.1.1.0/24 to interface Null0 is configured on csr-1. Prefix 100.1.1.10/32 resolves on this
static route.
csr-1#a9
csr-1#show cef vrf LIVE 100.1.1.10/32
show ip cef vrf LIVE 100.1.1.10 255.255.255.255 detail

100.1.1.10/32, epoch 0, flags [rib defined all labels]

recursive via 1.1.1.10 label 21
recursive via 1.1.1.0/24
attached to Null0

csr-1#a10
csr-1#show mpls forwarding 1.1.1.10 32

Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or Tunnel Id Switched interface
None No Label 1.1.1.10/32 0 punt

© 2017 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 8 of 46
 Cisco dCloud

Scenario 2. Configure SR Policy Explicit Path

This scenario demonstrates how to configure an explicit inter-domain SR policy on csr-1 with an explicit path to csr-10. The path is:
csr-1  xrvr-4  xrvr-6  csr-8  csr-10. The segment used to traverse the peering link between xrvr-4 and xrvr-6 is an EPE
peer-node-SID label. In this software release, this label is dynamically allocated.

NOTE: Some labels and values in this lab are dynamically assigned. Labels and values in your session may differ from those
shown in the example output.

Steps
1. On xrvr-4, enter the following command to collect the currently allocated peer-node-SID label:
RP/0/0/CPU0:xrvr-4#b1
RP/0/0/CPU0:xrvr-4#show bgp egress-engineering

Egress Engineering Peer Set: 99.4.6.6/32 (12632fd4)

Nexthop: 99.4.6.6
Version: 2, rn_version: 2
Flags: 0x00000006
Local ASN: 64001
Remote ASN: 64002
Local RID: 1.1.1.4
Remote RID: 1.1.1.6
First Hop: 99.4.6.6
NHID: 1
IFH: 0x40
Label: 24008, Refcount: 3
rpc_set: 13252f18

NOTE: In this example, peer-node-SID for xrvr-6 on xrvr-4 is 24008.

2. Enter the following commands to configure the explicit path on csr-1. Use the peer-node-SID as collected in the previous
command output.

NOTE: The explicit path expresses the SID-list of the SR Policy path. In this example, the first segment is expressed as an IPv4
address, the loopback address 1.1.1.4 of xrvr-4. The head-end csr-1 maps this IPv4 address to the corresponding prefix-SID label
16004. The subsequent segments are expressed as MPLS label values. These segments are the peer-node-SID and prefix-SIDs
of prefixes in remote domains, which must be expressed as label values.
!! on csr-1
exec b2(24008)

ip explicit-path name SIDLIST1 enable

index 10 next-address 1.1.1.4
index 20 next-label 24008
index 30 next-label 16008
index 40 next-label 16010
end

© 2017 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 9 of 46
 Cisco dCloud

NOTE: Label 24008 is the peer-node-SID label for xrvr-6 on xrvr-4.

3. On csr-1, configure interface tunnel-te 20. The SR policy is instantiated from this interface. The explicit-path SIDLIST1 is
specified as path-option.
!! on csr-1
exec b3

interface Tunnel20
ip unnumbered Loopback0
tunnel mode mpls traffic-eng
tunnel destination 1.1.1.10
tunnel mpls traffic-eng path-option 1 explicit name SIDLIST1 segment-routing
end

4. Enter the following command to verify the status of the SR policy:

csr-1#b4
csr-1#show mpls traffic-eng tunnels tunnel 20

Name: csr-1_t20 (Tunnel20) Destination: 1.1.1.10

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

Config Parameters:

© 2017 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 10 of 46
 Cisco dCloud

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: Explicit Path Option with all Strict Hops]
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: disabled

History:
Tunnel:
Time since created: 1 minutes, 27 seconds
Time since path change: 1 minutes, 27 seconds
Number of LSP IDs (Tun_Instances) used: 1
Current LSP: [ID: 1]
Uptime: 1 minutes, 27 seconds
Tun_Instance: 1
Segment-Routing Path Info (isis level-2)
Segment0[Node]: 1.1.1.4, Label: 16004
Segment1[ - ]: Label: 24008
Segment2[ - ]: Label: 16008
Segment3[ - ]: Label: 16010

NOTE: The segment list is as specified in the explicit path.

5. Enter the following command to find the binding SID for the SR Policy instantiated from tunnel-te 20 on csr-1.

NOTE: The binding SID of an SR policy is dynamically allocated. This is true throughout this guide wherever binding SIDs are
referenced or shown in example output. You must use the binding SID shown in your own environment's output.
csr-1#b5
csr-1#show mpls traffic-eng tunnels tunnel 20 detail | incl Name:|Binding SID:

Name: csr-1_t20 (Tunnel20) Destination: 1.1.1.10

Binding SID: 24

NOTE: In this example, the binding SID is 24.

6. Enter the following command to verify the forwarding entry of the SR policy instantiated from interface tunnel 20 on csr-1. A
forwarding entry is installed for the binding SID, which steer the packets with the binding SID label into the SR policy. Notice
the two outgoing paths: one for each of the equal cost paths of the first segment 16004 via xrvr-3 and csr-2.
csr-1#exec b6(24)
csr-1#show mpls forwarding-table labels 24
show mpls forwarding-table labels 24

Local Outgoing Prefix Bytes Label Outgoing Next Hop

© 2017 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 11 of 46
 Cisco dCloud

Label Label or Tunnel Id Switched interface

24 [T] Pop Label 20/1[TE-Bind] Tu20 point2point
[T] Pop Label 20/1[TE-Bind] Tu20 point2point

[T] Forwarding through a LSP tunnel.

View additional labelling info with the 'detail' option

7. Enter the following command to review the imposed label stack and outgoing interfaces:
csr-1#exec b7(24)
csr-1#show mpls forwarding-table labels 24 detail

Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or Tunnel Id Switched interface
24 Pop Label 20/1[TE-Bind] Tu20 point2point
MAC/Encaps=14/30, MRU=1488, Label Stack{16004 24008 16008 16010}, via Gi3
FA163E61EB02FA163E5F0B118847 03E8400005DC800003E8800003E8A000
No output feature configured
Per-destination load-sharing, slots: 0 2 4 6 8 10 12 14
Pop Label 20/1[TE-Bind] Tu20 point2point
MAC/Encaps=14/30, MRU=1488, Label Stack{16004 24008 16008 16010}, via Gi2
FA163E4ECF2CFA163E1C352A8847 03E8400005DC800003E8800003E8A000
No output feature configured
Per-destination load-sharing, slots: 1 3 5 7 9 11 13 15

8. Enter the following command on csr-1 to steer traffic to 1.1.1.10 into the SR Policy:
!! on csr-1
exec b8

interface Tunnel20
tunnel mpls traffic-eng autoroute destination
end

9. Enter the following command on csr-1 to verify the path to vrf LIVE prefix 100.1.1.10/32:
csr-1#b9
csr-1#traceroute vrf LIVE 100.1.1.10

Type escape sequence to abort.

Tracing the route to 100.1.1.10
VRF info: (vrf in name/id, vrf out name/id)
1 99.1.2.2 [MPLS: Labels 16004/24008/16008/16010/21 Exp 0] 8 msec 7 msec 7 msec
2 99.2.4.4 [MPLS: Labels 24008/16008/16010/21 Exp 0] 6 msec 6 msec 6 msec
3 99.4.6.6 [MPLS: Labels 16008/16010/21 Exp 0] 6 msec 5 msec 5 msec
4 99.5.6.5 [MPLS: Labels 16008/16010/21 Exp 0] 6 msec 5 msec 6 msec
5 99.5.7.7 [MPLS: Labels 16008/16010/21 Exp 0] 6 msec 6 msec 5 msec
6 99.7.8.8 [MPLS: Labels 16010/21 Exp 0] 6 msec 5 msec 5 msec
7 100.1.1.10 6 msec 6 msec 6 msec

NOTE: The packets traverse the path csr-1  csr-2  xrvr-4  xrvr-6  xrvr-5  xrvr-7  csr-8  csr-10, as show in the figure
in step 2.

10. Enter the following command on csr-1 to remove the steering configuration:
!! on csr-1
exec b10

© 2017 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 12 of 46
 Cisco dCloud

interface Tunnel20
no tunnel mpls traffic-eng autoroute destination
end

© 2017 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 13 of 46
 Cisco dCloud

Scenario 3. Explore XTC

XTC PCE functionality is enabled on xrvr-11, xrvr-12, xrvr-13, xrvr-7, and xrvr-14. XTC functionality is fundamentally distributed,
and multiple XTC nodes can be installed in a network. In this example, each domain has one or more XTC nodes. XTC nodes xrvr-
11 and xrvr-12 are used by Path Computation Clients (PCCs) in Domain1; csr-1 and csr-2 in this network. XTC nodes xrvr-7 and
xrvr-14 are used by PCCs in Domain3; csr-9 and csr-10 in this network.

NOTE: Some labels and values in this lab are dynamically assigned. Labels and values in your session may differ from those
shown in the example output.

Steps
1. On xrvr-11, enter the following command to discover the address configured for PCEP. Notice the address is 1.1.1.11.

NOTE: Enabling the XTC server functionality on a node is simple. The only required configuration is the local address used for the
PCEP connections.
RP/0/0/CPU0:xrvr-11#d1
RP/0/0/CPU0:xrvr-11#show running-config pce
pce
address ipv4 1.1.1.11
!

XTC gets its topology information from BGP link-state (BGP-LS) address family. Typically, BGP RRs are used to distribute BGP-LS
information throughout the network. In this example, the service RRs (xrvr-12, xrvr-13, and xrvr-14) are also used to distribute
BGP-LS information. Within each domain, any node can provide the BGP-LS topology feed to the RRs. The XTC nodes then tap
into the RRs to receive the BGP-LS information. In this example, a single node per domain feeds its domain’s ISIS topology to its
domain’s RR; csr-2, xrvr-5, and xrvr-7 are chosen for this task. For redundancy, it is recommended having multiple such nodes per
domain. Also each ASBR with a BGP peering link (xrvr-3, xrvr-4, xrvr-5, and xrvr-6) has a BGP-LS session to its domain’s RR.

2. For example, enter the following command on csr-2 to see the BGP configuration:
csr-2#d2
csr-2#show running | section ^router bgp
router bgp 64001
bgp router-id 1.1.1.2
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor 1.1.1.12 remote-as 64001
neighbor 1.1.1.12 update-source Loopback0
!
address-family vpnv4
neighbor 1.1.1.12 activate
neighbor 1.1.1.12 send-community both
exit-address-family
!
address-family link-state link-state
neighbor 1.1.1.12 activate
exit-address-family
!
address-family ipv4 vrf LIVE
network 100.1.1.2 mask 255.255.255.255

© 2017 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 14 of 46
 Cisco dCloud

exit-address-family

3. On csr-2, enter the following command to see the ISIS configuration to distribute to BGP-LS:
csr-2#d3
csr-2#show running | section ^router isis
router isis 1
net 49.0001.0000.0000.0002.00
is-type level-2-only
metric-style wide
distribute link-state instance-id 101 !! each domain needs its unique instance-id in BGP-LS
segment-routing mpls
fast-reroute per-prefix level-2 all
fast-reroute ti-lfa level-2
mpls traffic-eng router-id Loopback0
mpls traffic-eng level-2

NOTE: Each domain has a unique instance-id, a domain identifier, when distributing the domain’s topology to BGP-LS. For csr-2’s
domain, the instance-id 101 is chosen. The other domains have 102 and 103 as identifiers.

4. XTC xrvr-11 receives the BGP-LS information.

RP/0/0/CPU0:xrvr-11#d4
RP/0/0/CPU0:xrvr-11#show bgp link-state link-state
BGP router identifier 1.1.1.11, local AS number 64001
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0x0 RD version: 125
BGP main routing table version 125
BGP NSR Initial initsync version 1 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs

Status codes: s suppressed, d damped, h history, * valid, > best

i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
Prefix codes: E link, V node, T IP reacheable route, u/U unknown
I Identifier, N local node, R remote node, L link, P prefix
L1/L2 ISIS level-1/level-2, O OSPF, D direct, S static/peer-node
a area-ID, l link-ID, t topology-ID, s ISO-ID,
c confed-ID/ASN, b bgp-identifier, r router-ID,
i if-address, n nbr-address, o OSPF Route-type, p IP-prefix
d designated router address
Network Next Hop Metric LocPrf Weight Path
*>i[V][L2][I0xfa01][N[c64001][b0.0.0.0][s0000.0000.0001.00]]/328
1.1.1.3 100 0 i
*>i[V][L2][I0xfa01][N[c64001][b0.0.0.0][s0000.0000.0002.00]]/328
1.1.1.3 100 0 i
*>i[V][L2][I0xfa01][N[c64001][b0.0.0.0][s0000.0000.0003.00]]/328
1.1.1.3 100 0 i
*>i[V][L2][I0xfa01][N[c64001][b0.0.0.0][s0000.0000.0004.00]]/328
1.1.1.3 100 0 i
--More--

© 2017 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 15 of 46
 Cisco dCloud

5. You can see detailed information of each NLRI by copying and pasting the NLRI in the show bgp link-state command and
adding detail at the end of the command.

NOTE: The legend indicates that [E] indicates a link info NLRI, [V] indicates node info, and [T] indicates IP info.
RP/0/0/CPU0:xrvr-11#d5
RP/0/0/CPU0:xrvr-11#show bgp link-state link-state | incl [V] | incl 0000.0000.0001
*>i[V][L2][I0x65][N[c64001][b0.0.0.0][s0000.0000.0001.00]]/328

RP/0/0/CPU0:xrvr-11#d6
RP/0/0/CPU0:xrvr-11#show bgp link-state link-state
[V][L2][ I0x65][N[c64001][b0.0.0.0][s0000.0000.0001.00]]/328 detail
BGP routing table entry for [V][L2][I0x65][N[c64001][b0.0.0.0][s0000.0000.0001.00]]/328
NLRI Type: Node
Protocol: ISIS L2
Identifier: 0x65
Local Node Descriptor:
AS Number: 64001
BGP Identifier: 0.0.0.0
ISO Node ID: 0000.0000.0001.00

Versions:
Process bRIB/RIB SendTblVer
Speaker 115 115
Flags: 0x00000001+0x00000000;
Last Modified: Mar 8 10:04:28.327 for 23:17:56
Paths: (1 available, best #1)
Not advertised to any peer
Path #1: Received by speaker 0
Flags: 0x4000000001060005, import: 0x20
Not advertised to any peer
Local
1.1.1.2 (metric 20) from 1.1.1.12 (1.1.1.2)
Origin IGP, localpref 100, valid, internal, best, group-best
Received Path ID 0, Local Path ID 0, version 115
Originator: 1.1.1., Cluster list: 1.1.1.12
Link-state: Node-name: csr-1, ISIS area: 49.00.01, Local TE Router-ID:
1.1.1.1 SRGB: 16000:8000 , SR-ALG: 0 SR-ALG: 1

6. Links are advertised as unidirectional inter-connections. For example, the link from csr-1 to xrvr-3 (99.1.3.1 is the interface
address on csr-1)/
RP/0/0/CPU0:xrvr-11#d7
RP/0/0/CPU0:xrvr-11#show bgp link-state link-state | incl [E] | incl 99.1.3.1
*>i[E][L2][I0x65][N[c64001][b0.0.0.0][s0000.0000.0001.00]][R[c64001][b0.0.0.0][s0000.0000.0003.00]][L[i9
9.1.3.1][n99.1.3.3][t0x0000]]/744
*>i[E][L2][I0x65][N[c64001][b0.0.0.0][s0000.0000.0003.00]][R[c64001][b0.0.0.0][s0000.0000.0001.00]][L[i9
9.1.3.3][n99.1.3.1][t0x0000]]/744

RP/0/0/CPU0:xrvr-11#d8
RP/0/0/CPU0:xrvr-11#show bgp link-state link-state
[E][L2][I0x65][N[c64001][b0.0.0.0][s0000.0000.0001.00]][R[c64001][b0.0.0.0][s0000.0000.0003.00]][L[i99.1
.3.1][n99.1.3.3][t0x0000]]/744 detail
BGP routing table entry for
[E][L2][I0x65][N[c64001][b0.0.0.0][s0000.0000.0001.00]][R[c64001][b0.0.0.0][s0000.0000.0003.00]][L[i99.1
.3.1][n99.1.3.3][t0x0000]]/744
NLRI Type: Link

© 2017 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 16 of 46
 Cisco dCloud

Protocol: ISIS L2
Identifier: 0x65
Local Node Descriptor:
AS Number: 64001
BGP Identifier: 0.0.0.0
ISO Node ID: 0000.0000.0001.00
Remote Node Descriptor:
AS Number: 64001
BGP Identifier: 0.0.0.0
ISO Node ID: 0000.0000.0003.00
Link Descriptor:
Local Interface Address IPv4: 99.1.3.1
Neighbor Interface Address IPv4: 99.1.3.3
Multi-Topology: 0x0000

Versions:
Process bRIB/RIB SendTblVer
Speaker 4 4
Flags: 0x00000001+0x00000000;
Last Modified: Aug 10 15:15:09.882 for 17:24:48
Paths: (1 available, best #1)
Not advertised to any peer
Path #1: Received by speaker 0
Flags: 0x4000000001060005, import: 0x20
Not advertised to any peer
Local
1.1.1.2 (metric 30) from 1.1.1.12 (1.1.1.2)
Origin IGP, metric 0, localpref 100, valid, internal, best, group-best
Received Path ID 0, Local Path ID 0, version 4
Originator: 1.1.1.2, Cluster list: 1.1.1.12
Link-state: Local TE Router-ID: 1.1.1.1, Remote TE Router-ID:
1.1.1.3 admin-group: 0x00000000, max-link-bw (kbits/sec): 1000000
max-reserv-link-bw (kbits/sec): 0, max-unreserv-link-bw (kbits/sec):
0 0 0 0 0 0 0 0 TE-default-metric: 10, metric: 10,
ADJ-SID: 18(30) ADJ-SID: 19(70)

7. The IP reachability NLRI for csr-1’s loopback prefix 1.1.1.1/32 also contains its prefix-SID index 1.
RP/0/0/CPU0:xrvr-11#d9
RP/0/0/CPU0:xrvr-11#show bgp link-state link-state | incl [T] | incl 1.1.1.1/32
*>i[T][L2][I0x65][N[c64001][b0.0.0.0][s0000.0000.0001.00]][P[p1.1.1.1/32]]/400

RP/0/0/CPU0:xrvr-11#d10
RP/0/0/CPU0:xrvr-11#show bgp link-state link-state
[T][L2][I0x65][N[c64001][b0.0.0.0][s0000.0000.0001.00]][P[p1.1.1.1/32]]/400 detail
BGP routing table entry for [T][L2][I0x65][N[c64001][b0.0.0.0][s0000.0000.0001.00]][P[p1.1.1.1/32]]/400
NLRI Type: Prefix
Protocol: ISIS L2
Identifier: 0x65
Local Node Descriptor:
AS Number: 64001
BGP Identifier: 0.0.0.0
ISO Node ID: 0000.0000.0001.00
Prefix Descriptor:
Prefix: 1.1.1.1/32

Versions:

© 2017 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 17 of 46
 Cisco dCloud

Process bRIB/RIB SendTblVer

Speaker 26 26
Flags: 0x00000001+0x00000000;
Last Modified: Aug 10 15:15:09.882 for 17:28:30
Paths: (1 available, best #1)
Not advertised to any peer
Path #1: Received by speaker 0
Flags: 0x4000000001060005, import: 0x20
Not advertised to any peer
Local
1.1.1.2 (metric 30) from 1.1.1.12 (1.1.1.2)
Origin IGP, metric 0, localpref 100, valid, internal, best, group-best
Received Path ID 0, Local Path ID 0, version 26
Originator: 1.1.1.2, Cluster list: 1.1.1.12
Link-state: Metric: 10, PFX-SID: 1(40/0)

8. This BGP-LS information is by XTC to feed its SRTE Database (SRTE-DB).

RP/0/0/CPU0:xrvr-11#d11
RP/0/0/CPU0:xrvr-11#show pce ipv4 topology sum

PCE's topology database summary:

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

Topology nodes: 14
Prefixes: 12
Prefix SIDs: 12
Links: 30
Adjacency SIDs: 56
Consistent yes
Update Stats:
Noded added: 21
Noded deleted: 0
Links added: 46
Links deleted: 0
Prefix added: 80
Prefix deleted: 0

9. For example, XTC stores the following information of node csr-1:

RP/0/0/CPU0:xrvr-11#d12
RP/0/0/CPU0:xrvr-11#show pce ipv4 topology 1.1.1.1

PCE's topology database:

------------------------
Node 1
TE router ID: 1.1.1.1
Host name: csr-1
ISIS system ID: 0000.0000.0001 level-2 domain ID: 101
Prefix SID:
Prefix 1.1.1.1, label 16001 (regular), domain ID 101, flags: N
SRGB INFO:
ISIS system ID: 0000.0000.0001 level-2 SRGB Start: 16000 Size: 8000

Link[0]: local address 99.1.2.1, remote address 99.1.2.2

Local node:
ISIS system ID: 0000.0000.0001 level-2 domain ID: 101
Remote node:

© 2017 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 18 of 46
 Cisco dCloud

TE router ID: 1.1.1.2

Host name: csr-2
ISIS system ID: 0000.0000.0002 level-2
Metric: IGP 10, TE 10
Bandwidth: Total link 125000000, Reservable 0
Adj SID: 16 (unprotected) 17 (protected)

Link[1]: local address 99.1.3.1, remote address 99.1.3.3

Local node:
ISIS system ID: 0000.0000.0001 level-2 domain ID: 101
Remote node:
TE router ID: 1.1.1.3
Host name: xrvr-3
ISIS system ID: 0000.0000.0003 level-2
Metric: IGP 10, TE 10
Bandwidth: Total link 125000000, Reservable 0
Adj SID: 18 (unprotected) 19 (protected)

Link[2]: local address 99.1.11.1, remote address 99.1.11.11

Local node:
ISIS system ID: 0000.0000.0001 level-2 domain ID: 101
Remote node:
TE router ID: 1.1.1.11
Host name: xrvr-11
ISIS system ID: 0000.0000.0011 level-2
Metric: IGP 10, TE 10
Bandwidth: Total link 125000000, Reservable 0
Adj SID: 20 (unprotected) 21 (protected)

NOTE: BGP Egress Peer Engineering (EPE) is enabled on the BGP peering sessions between Domain1 and Domain2. EPE
allocates a peer node SID for the BGP session, which steers a packet over the peering link. EPE is enabled on the peering
sessions between xrvr-3 and xrvr-5 and between xrvr-4 and xrvr-6. These peering nodes feed the EPE information via BGP-LS to
their RR.

10. For example, enter the following command on xrvr-3 to see the BGP configuration:
RP/0/0/CPU0:xrvr-3#d13
RP/0/0/CPU0:xrvr-3#show running-config router bgp
router bgp 64001
bgp router-id 1.1.1.3
address-family ipv4 unicast
redistribute isis 1 route-policy RRs_West_to_East
!
address-family link-state link-state
!
neighbor 1.1.1.12
description !! 1.1.1.12 is xrvr-12, Domain1's RR
remote-as 64001
update-source Loopback0
address-family link-state link-state
!
!
neighbor 99.3.5.5
!! peering session to xrvr-5
remote-as 64002

© 2017 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 19 of 46
 Cisco dCloud

egress-engineering
address-family ipv4 unicast
route-policy bgp_in in
route-policy bgp_out out
!
!
!

11. Verify the EPE peer node SID on xrvr-3:

RP/0/0/CPU0:xrvr-3#d14
RP/0/0/CPU0:xrvr-3#show bgp egress-engineering

Egress Engineering Peer Set: 99.3.5.5/32 (12632fd4)

Nexthop: 99.3.5.5
Version: 2, rn_version: 2
Flags: 0x00000006
Local ASN: 64001
Remote ASN: 64002
Local RID: 1.1.1.3
Remote RID: 1.1.1.5
First Hop: 99.3.5.5
NHID: 1
IFH: 0x40
Label: 24010, Refcount: 3
rpc_set: 132d492c

12. Xrvr-3 advertises this information in BGP-LS in a link NLRI, which you can see on xrvr-11 (99.3.5.3 is the interface address on
xrvr-3):
RP/0/0/CPU0:xrvr-11#d15
RP/0/0/CPU0:xrvr-11#show bgp link-state link-state | incl [E] | incl 99.3.5.3
*>i[E][B][I0x0][N[c64001][b0.0.0.0][q1.1.1.3]][R[c64002][b0.0.0.0][q1.1.1.5]][L[i99.3.5.3][n99.3.5.5]]/6
64
*>i[E][B][I0x0][N[c64002][b0.0.0.0][q1.1.1.5]][R[c64001][b0.0.0.0][q1.1.1.3]][L[i99.3.5.5][n99.3.5.3]]/6
64

RP/0/0/CPU0:xrvr-11#d16
RP/0/0/CPU0:xrvr-11#show bgp link-state link-state
[E][B][I0x0][N[c64001][b0.0.0.0][q1.1.1.3]][R[c64002][b0.0.0.0][q1.1.1.5]][L[i99.3.5.3][n99.3.5.5]]/664
detail
BGP routing table entry for
[E][B][I0x0][N[c64001][b0.0.0.0][q1.1.1.3]][R[c64002][b0.0.0.0][q1.1.1.5]][L[i99.3.5.3][n99.3.5.5]]/664
NLRI Type: Link
Protocol: BGP
Identifier: 0x0
Local Node Descriptor:
AS Number: 64001
BGP Identifier: 0.0.0.0
BGP Router Identifier: 1.1.1.3
Remote Node Descriptor:
AS Number: 64002
BGP Identifier: 0.0.0.0
BGP Router Identifier: 1.1.1.5
Link Descriptor:
Local Interface Address IPv4: 99.3.5.3
Neighbor Interface Address IPv4: 99.3.5.5

© 2017 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 20 of 46
 Cisco dCloud

Versions:
Process bRIB/RIB SendTblVer
Speaker 22 22
Flags: 0x00000001+0x00000000;
Last Modified: Aug 10 15:15:09.882 for 17:40:59
Paths: (1 available, best #1)
Not advertised to any peer
Path #1: Received by speaker 0
Flags: 0x4000000001060005, import: 0x20
Not advertised to any peer
Local
1.1.1.3 (metric 20) from 1.1.1.12 (1.1.1.3)
Origin IGP, localpref 100, valid, internal, best, group-best
Received Path ID 0, Local Path ID 0, version 22
Originator: 1.1.1.3, Cluster list: 1.1.1.12
Link-state: Peer-SID: 24010

13. On xrvr-11, enter the following commands to display the BGP peering link between xrvr-3 and xrvr-5 in the XTC SRTE-DB:
RP/0/0/CPU0:xrvr-11#d17
RP/0/0/CPU0:xrvr-11#show pce ipv4 topology 1.1.1.3 | util egrep -A10 "local address 99.3.5.3"
Link[2]: local address 99.3.5.3, remote address 99.3.5.5
Local node:
BGP router ID: 1.1.1.3
Remote node:
TE router ID: 1.1.1.5
Host name: xrvr-5
BGP router ID: 1.1.1.5
Metric: IGP 0, TE 0
Bandwidth: Total link 0, Reservable 0
Adj SID: 24010 (epe)

14. The PCCs are configured to set up PCEP sessions with their XTC nodes. Csr-1 establishes PCEP sessions with XTC xrvr-11
and xrvr-12. Xrvr-11 has a lower precedence value and is therefore the preferred XTC.
csr-1#d18
csr-1#show running | incl ^mpls traffic-eng pcc
mpls traffic-eng pcc peer 1.1.1.11 source 1.1.1.1 precedence 10
mpls traffic-eng pcc peer 1.1.1.12 source 1.1.1.1 precedence 20

15. Enter the following command to establish a PCEP session on both XTC nodes:
csr-1#d19
csr-1#show pce client peer

PCC's peer database:

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

Peer address: 1.1.1.11, Precedence: 10

State up
Capabilities: Stateful, Update, Segment-Routing

Peer address: 1.1.1.12, Precedence: 20

State up
Capabilities: Stateful, Update, Segment-Routing

© 2017 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 21 of 46
 Cisco dCloud

Scenario 4. Configure SR Dynamic Path Policy

This scenario demonstrates how to instantiate an SR policy from a locally configured interface tunnel-te. The SR policy path can be
computed locally on the head-end, or XTC can compute it. Use the latter method inter-domain paths or disjoint paths from distinct
head-ends, for example. In this scenario, XTC computes the inter-domain path.

NOTE: Some labels and values in this lab are dynamically assigned. Labels and values in your session may differ from those
shown in the example output.

Steps
1. On csr-1, enter the following commands to instantiate an SR policy from a tunnel-te 21 interface and configure the tunnel-te
interface to request XTC to compute a path to end-point 1.1.1.10 (csr-10). XTC must optimize the IGP metric for this path.
!! on csr-1
exec e1

config t
interface Tunnel21
ip unnumbered Loopback0
tunnel mode mpls traffic-eng
tunnel destination 1.1.1.10
tunnel mpls traffic-eng path-option 1 dynamic segment-routing pce
tunnel mpls traffic-eng path-selection metric igp
tunnel mpls traffic-eng path-selection segment-routing adjacency protected
end

2. Verify the status of the SR policy on csr-1. The computed path is csr-1  xrvr-3  xrvr-5  xrvr-7  csr-10.
csr-1#e2
csr-1#show mpls traffic-eng tunnels tunnel21 | i Name:|Metric Type|Bind|Segment|SEGMENT
Name: csr-1_t21 (Tunnel21) Destination: 1.1.1.10
path option 1, (SEGMENT-ROUTING) (PCE) type dynamic (Basis for Setup)
Metric Type: IGP (interface)
Tunnel Name: Tunnel21_w
Binding SID: 25
Segment-Routing Path Info (isis level-2)
Segment0[Node]: 1.1.1.3, Label: 16003
Segment1[Link]: 99.3.5.3 - 99.3.5.5, Label: 24010
Segment2[Node]: 1.1.1.7, Label: 16007
Segment3[Node]: 1.1.1.10, Label: 16010

© 2017 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 22 of 46
 Cisco dCloud

NOTE: Csr-1 used PCEP PCRequest and PCReply messages to request and receive the path computation. Then csr-1 sent a
PCReport message to report the SR Policy to both XTC nodes. In the report to its primary XTC xrvr-11, csr-1 sets the delegate (D)
flag to indicate that xrvr-11 can update the path.

3. Enter the following command to show the SR policy information on XTC xrvr-11:
RP/0/0/CPU0:xrvr-11#e3
RP/0/0/CPU0:xrvr-11#show pce lsp detail

PCE's tunnel database:

----------------------
PCC 1.1.1.1:

Tunnel Name: Tunnel21_w

LSPs:
LSP[0]:
source 1.1.1.1, destination 1.1.1.10, tunnel ID 21, LSP ID 1
State: Admin up, Operation active
Binding SID: 25
PCEP information:
plsp-id 524309, flags: D:1 S:0 R:0 A:1 O:2
LSP Role: Single LSP
State-sync PCE: None
PCC: 1.1.1.1
LSP is subdelegated to: None
Reported path:
Metric type: IGP, Accumulated Metric 0

© 2017 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 23 of 46
 Cisco dCloud

SID[0]: Node, Label 16003, Address 1.1.1.3

SID[1]: Adj, Label 24010, Address: local 99.3.5.3 remote 99.3.5.5
SID[2]: Node, Label 16007, Address 1.1.1.7
SID[3]: Node, Label 16010, Address 1.1.1.10
Computed path: (Local PCE)
Computed Time: Fri Aug 11 09:07:35 2017 (00:03:43 ago)
Metric type: IGP, Accumulated Metric 40
SID[0]: Node, Label 16003, Address 1.1.1.3
SID[1]: Adj, Label 24010, Address: local 99.3.5.3 remote 99.3.5.5
SID[2]: Node, Label 16007, Address 1.1.1.7
SID[3]: Node, Label 16010, Address 1.1.1.10
Recorded path:
None
Disjoint Group Information:
None

NOTE: The D-flag is set (D:1), indicating that this SR Policy is delegated to this XTC (xrvr-11).

4. Enter the following command to see SR policy information on XTC xrvr-12:

RP/0/0/CPU0:xrvr-12#e4
RP/0/0/CPU0:xrvr-12#show pce lsp detail

PCE's tunnel database:

----------------------
PCC 1.1.1.1:

Tunnel Name: Tunnel21_w

LSPs:
LSP[0]:
source 1.1.1.1, destination 1.1.1.10, tunnel ID 21, LSP ID 1
State: Admin up, Operation active
Binding SID: 25
PCEP information:
plsp-id 524309, flags: D:0 S:0 R:0 A:1 O:2
LSP Role: Single LSP
State-sync PCE: None
PCC: 1.1.1.1
LSP is subdelegated to: None
Reported path:
Metric type: IGP, Accumulated Metric 0
SID[0]: Node, Label 16003, Address 1.1.1.3
SID[1]: Adj, Label 24010, Address: local 99.3.5.3 remote 99.3.5.5
SID[2]: Node, Label 16007, Address 1.1.1.7
SID[3]: Node, Label 16010, Address 1.1.1.10
Computed path: (Local PCE)
None
Computed Time: Not computed yet
Recorded path:
None
Disjoint Group Information:
None

NOTE: The D-flag is unset (D:0), indicating that this SR Policy is not delegated to this XTC (xrvr-12). Also the empty Computed
path: (Local PCE) field in the output indicates that this XTC (xrvr-12) did not compute the path.

© 2017 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 24 of 46
 Cisco dCloud

NOTE: Because head-end csr-1 delegated the SR policy to XTC xrvr-12, stateful XTC updates the SR policy, if required, following
a topology change.

5. To demonstrate this, we will temporarily shut down the peering link between xrvr-3 and xrvr-5. Configure on xrvr-3:
!! on xrvr-3
configure
e5

interface GigabitEthernet0/0/0/1
shutdown
commit
end

6. On csr-1, enter the following command to verify the SR policy path. Notice the path is modified to csr-1  xrvr-4  xrvr-6 
csr-8  csr-10.
csr-1#e6
csr-1#show mpls traffic-eng tunnels tunnel21 | i Name:|Metric Type|Bind|Segment|SEGMENT
Name: csr-1_t21 (Tunnel21) Destination: 1.1.1.10
path option 1, (SEGMENT-ROUTING) (PCE) type dynamic (Basis for Setup)
Metric Type: IGP (interface)
Tunnel Name: Tunnel21_w
Binding SID: 25
Binding SID: 25
Segment-Routing Path Info (isis level-2)
Segment0[Node]: 1.1.1.4, Label: 16004
Segment1[Link]: 99.4.6.4 - 99.4.6.6, Label: 24008
Segment2[Node]: 1.1.1.7, Label: 16007
Segment3[Node]: 1.1.1.10, Label: 16010

© 2017 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 25 of 46
 Cisco dCloud

7. Enter the following command to show the SR policy information on XTC xrvr-11:
RP/0/0/CPU0:xrvr-11#e7
RP/0/0/CPU0:xrvr-11#show pce lsp detail

PCE's tunnel database:

----------------------
PCC 1.1.1.1:

Tunnel Name: Tunnel21_w

LSPs:
LSP[0]:
source 1.1.1.1, destination 1.1.1.10, tunnel ID 21, LSP ID 3
State: Admin up, Operation active
Binding SID: 25
PCEP information:
plsp-id 524309, flags: D:1 S:0 R:0 A:1 O:2
LSP Role: Single LSP
State-sync PCE: None
PCC: 1.1.1.1
LSP is subdelegated to: None
Reported path:
Metric type: IGP, Accumulated Metric 0
SID[0]: Node, Label 16004, Address 1.1.1.4
SID[1]: Adj, Label 24008, Address: local 99.4.6.4 remote 99.4.6.6
SID[2]: Node, Label 16007, Address 1.1.1.7
SID[3]: Node, Label 16010, Address 1.1.1.10
Computed path: (Local PCE)

© 2017 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 26 of 46
 Cisco dCloud

Computed Time: Fri Aug 11 11:24:39 2017 (00:00:17 ago)

Metric type: IGP, Accumulated Metric 0
SID[0]: Node, Label 16004, Address 1.1.1.4
SID[1]: Adj, Label 24008, Address: local 99.4.6.4 remote 99.4.6.6
SID[2]: Node, Label 16007, Address 1.1.1.7
SID[3]: Node, Label 16010, Address 1.1.1.10
Recorded path:
None
Disjoint Group Information:
None

8. Enter the following command to show the SR policy information on XTC xrvr-12:
RP/0/0/CPU0:xrvr-12#e8
RP/0/0/CPU0:xrvr-12#show pce lsp detail

PCE's tunnel database:

----------------------
PCC 1.1.1.1:

Tunnel Name: Tunnel21_w

LSPs:
LSP[0]:
source 1.1.1.1, destination 1.1.1.10, tunnel ID 21, LSP ID 3
State: Admin up, Operation active
Binding SID: 25
PCEP information:
plsp-id 524309, flags: D:0 S:0 R:0 A:1 O:2
LSP Role: Single LSP
State-sync PCE: None
PCC: 1.1.1.1
LSP is subdelegated to: None
Reported path:
Metric type: IGP, Accumulated Metric 0
SID[0]: Node, Label 16004, Address 1.1.1.4
SID[1]: Adj, Label 24008, Address: local 99.4.6.4 remote 99.4.6.6
SID[2]: Node, Label 16007, Address 1.1.1.7
SID[3]: Node, Label 16010, Address 1.1.1.10
Computed path: (Local PCE)
None
Computed Time: Not computed yet
Recorded path:
None
Disjoint Group Information:
None

9. Enter the following commands on xrvr-3 to restore the peering link between xrvr-3 and xrvr-5:
!! on xrvr-3
configure
e9
interface GigabitEthernet0/0/0/1
no shutdown
commit
end

© 2017 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 27 of 46
 Cisco dCloud

Scenario 5. Use ODN for Reachability

This scenario demonstrates how to use on-demand next-hop (ODN) functionality to automatically provide scalable inter-domain
reachability without any SR policy or traffic steering configuration.

NOTE: Some labels and values in this lab are dynamically assigned. Labels and values in your session may differ from those
shown in the example output.

Steps
1. ODN can automatically provide inter-domain reachability. In this software release, this is achieved by applying an ingress
route-map on csr-1. This route-map indicates that for prefixes with AS 64003 in their AS-path (for example, nodes csr-9 and
csr-10) an SR policy must be instantiated from a template described by attribute-set ODN-IGP.
csr-1#f0
csr-1#show running | section ^ip as-path
ip as-path access-list 1 permit 64003

csr-1#f1
csr-1#show running | section ^route-map ODN_Reachability
route-map ODN_Reachability permit 10
match as-path 1
set attribute-set ODN-IGP

2. The attribute-set indicates that a PCE must compute the path and the path computation must optimize the IGP metric (IGP
shortest path).
csr-1#f2
csr-1#show running | section ^mpls traffic-eng lsp attributes ODN-IGP
mpls traffic-eng lsp attributes ODN-IGP
path-selection metric igp
path-selection segment-routing adjacency protected
pce

3. On csr-1, enter the following commands to apply the route-policy as an ingress policy for neighbor xrvr-12 (1.1.1.12):
!! on csr-1
exec f3

config t
router bgp 64001
address-family vpnv4
neighbor 1.1.1.12 route-map ODN_Reachability in
end

4. Enter the following command to verify that BGP requests an SR policy to 1.1.1.10 with attribute-set ODN-IGP. Notice that the
SR Policy to 1.1.1.10 with attribute-set ODN-IGP has a Binding-SID 26.
csr-1#f4
csr-1#show bgp vrf LIVE

BGP table version is 17, local router ID is 1.1.1.1

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,

© 2017 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 28 of 46
 Cisco dCloud

x best-external, a additional-path, c RIB-compressed,

t secondary path,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path

Route Distinguisher: 1.1.1.1:0 (default for vrf LIVE)
*> 100.1.1.1/32 0.0.0.0 0 32768 i
*>i 100.1.1.10/32 1.1.1.10 100 0 64003 i

csr-1#f5
csr-1#show bgp vrf LIVE binding-sid

Attribute-Set Destination Binding-SID

ODN-IGP 1.1.1.10 26

NOTE: If the show bgp vrf LIVE binding-sid command does not show the binding-sid output, then try again a few 10s of seconds
later.

5. Enter the following command to see that the vrf LIVE 100.1.1.10/32 prefix uses Binding-SID 26 of the SR Policy with attribute-
set ODN-IGP:
csr-1#f6
csr-1#show bgp vrf LIVE 100.1.1.10/32
BGP routing table entry for 1.1.1.1:0:100.1.1.10/32, version 16
Paths: (1 available, best #1, table LIVE)
Not advertised to any peer
Refresh Epoch 1
64003, imported path from 1.1.1.10:0:100.1.1.10/32 (global)
1.1.1.10 (via default) from 1.1.1.12 (1.1.1.12)
Origin IGP, localpref 100, valid, internal, best
Extended Community: RT:1:100
mpls labels in/out nolabel/21
binding SID: 26 (ODN-IGP)
rx pathid: 0, tx pathid: 0x0

NOTE: The binding-SID is dynamically allocated and may have different values. The SR policy is also dynamically instantiated and
the tunnel-te interface number of the SR policy may have different values.

6. Enter the following command to examine the MPLS forwarding table entry for the binding-SID label and find the SR policy.

NOTE: Refer to the binding-SID displayed in the output of the previous command.
csr-1#exec f7(26)
csr-1#show mpls forwarding labels 26

Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or Tunnel Id Switched interface
26 [T] Pop Label 2000/1[TE-Bind] 0 Tu2000 point2point

[T] Forwarding through a LSP tunnel.

View additional labelling info with the 'detail' option

7. Enter the following command to show the details of the SR policy represented by interface tunnel 2000:
csr-1#exec f8(2000)

© 2017 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 29 of 46
 Cisco dCloud

csr-1#show mpls traffic-eng tunnels tunnel 2000

Name: csr-1_t2000 (Tunnel2000) Destination: 1.1.1.10 Ifhandle: 0x14 (auto-tunnel

for BGP TE)
Status:
Admin: up Oper: up Path: valid Signalling: connected
path option 1, (SEGMENT-ROUTING) (PCE) type dynamic (Basis for Setup)

Config Parameters:
Bandwidth: 0 kbps (Global) Priority: 7 7 Affinity: 0x0/0xFFFF
Metric Type: IGP (interface)
Path Selection:
Protection: Protected Adjacency
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: ODN-IGP

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
Delegation peer: 1.1.1.11
Working Path Info:
Request status: processed
Created via PCRep message from PCE server: 1.1.1.11
PCE metric: 40, type: IGP
Reported paths:
Tunnel Name: Tunnel2000_w
LSPs:
LSP[0]:
source 1.1.1.1, destination 1.1.1.10, tunnel ID 2000, LSP ID 1
State: Admin up, Operation active
Binding SID: 26
Setup type: SR
Bandwidth: requested 0, used 0
LSP object:

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

ERO:
SID[0]: Node, Label 16003, NAI: 1.1.1.3
SID[1]: Adj, Label 24013, NAI: local 99.3.5.3 remote 99.3.5.5
SID[2]: Node, Label 16007, NAI: 1.1.1.7
SID[3]: Node, Label 16010, NAI: 1.1.1.10

History:
Tunnel:
Time since created: 17 minutes, 34 seconds
Time since path change: 17 minutes, 34 seconds

© 2017 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 30 of 46
 Cisco dCloud

Number of LSP IDs (Tun_Instances) used: 1

Current LSP: [ID: 1]
Uptime: 17 minutes, 34 seconds
Tun_Instance: 1
Segment-Routing Path Info (isis level-2)
Segment0[Node]: 1.1.1.3, Label: 16003
Segment1[Link]: 99.3.5.3 - 99.3.5.5, Label: 24013
Segment2[Node]: 1.1.1.7, Label: 16007
Segment3[Node]: 1.1.1.10, Label: 16010

NOTE: The computed path is csr-1  xrvr-3  xrvr-5  xvr-7  csr-10. This is due to the high IGP metric (100) of the link
between xrvr-6 and csr-8.

8. Enter the following command on xrvr-11 to verify the SR policy on the XTC:

NOTE: The tunnel interface number is the one that used in the previous command.
RP/0/0/CPU0:xrvr-11#f9(2000)
RP/0/0/CPU0:xrvr-11#show pce lsp pcc ipv4 1.1.1.1 tunnel-id 2000 detail

PCE's tunnel database:

----------------------
PCC 1.1.1.1:

Tunnel Name: Tunnel2000_w

LSPs:
LSP[0]:

© 2017 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 31 of 46
 Cisco dCloud

source 1.1.1.1, destination 1.1.1.10, tunnel ID 2000, LSP ID 1

State: Admin up, Operation active
Binding SID: 26
PCEP information:
plsp-id 526288, flags: D:1 S:0 R:0 A:1 O:2
LSP Role: Single LSP
State-sync PCE: None
PCC: 1.1.1.1
LSP is subdelegated to: None
Reported path:
Metric type: IGP, Accumulated Metric 0
SID[0]: Node, Label 16003, Address 1.1.1.3
SID[1]: Adj, Label 24013, Address: local 99.3.5.3 remote 99.3.5.5
SID[2]: Node, Label 16007, Address 1.1.1.7
SID[3]: Node, Label 16010, Address 1.1.1.10
Computed path: (Local PCE)
Computed Time: Fri Aug 11 11:33:49 2017 (00:20:21 ago)
Metric type: IGP, Accumulated Metric 40
SID[0]: Node, Label 16003, Address 1.1.1.3
SID[1]: Adj, Label 24013, Address: local 99.3.5.3 remote 99.3.5.5
SID[2]: Node, Label 16007, Address 1.1.1.7
SID[3]: Node, Label 16010, Address 1.1.1.10
Recorded path:
None
Disjoint Group Information:
None

NOTE: The prefixes are automatically steered into the instantiated SR policy. In this release, the SR policy is identified by the pair
(BGP next-hop, attribute-set). All prefixes that have the same BGP next-hop and attribute-set share the same SR policy. The
prefixes are steered into the SR policy by resolving on the SR policy’s binding-SID instead of resolving on the BGP next-hop.

9. Enter the following command to verify that the entry resolves on the binding-SID label by looking at the cef entry for the vrf
LIVE prefix 100.1.1.10/32. Notice that the entry resolves on binding-SID label 26 (recursive via). Label 21 in this example, is
the VPN label for vrf LIVE prefix 100.1.1.10/32. You can verify this in the above output of show bgp vrf LIVE 100.1.1.10/32.
csr-1#f10
csr-1#show ip cef vrf LIVE 100.1.1.10 255.255.255.255 detail

100.1.1.10/32, epoch 2, flags [rib defined all labels]

recursive via 26 label 21
attached to Tunnel2000

10. Enter the following command to verify the path from csr-1 to vrf LIVE prefix 100.1.1.10/32. A similar policy is deployed on csr-
10 to provide reachability in the other direction.

NOTE: The label 21 at the bottom of the stack is the VPN label.
csr-1#f11
csr-1#traceroute vrf LIVE 100.1.1.10

Type escape sequence to abort.

Tracing the route to 100.1.1.10
VRF info: (vrf in name/id, vrf out name/id)
1 99.1.3.3 [MPLS: Labels 24013/16007/16010/21 Exp 0] 10 msec 6 msec 7 msec
2 99.3.5.5 [MPLS: Labels 16007/16010/21 Exp 0] 6 msec 6 msec 6 msec

© 2017 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 32 of 46
 Cisco dCloud

3 99.5.7.7 [MPLS: Labels 16010/21 Exp 0] 6 msec 6 msec 5 msec

4 88.7.8.8 [MPLS: Labels 16010/21 Exp 0] 7 msec 6 msec 6 msec
5 100.1.1.10 6 msec 5 msec 6 msec

© 2017 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 33 of 46
 Cisco dCloud

Scenario 6. Use ODN with Service Policy

One-demand next-hop cannot only provide automatic inter-domain reachability, it can also provide the inter-domain reachability
with a service requirement policy, such as low latency. This scenario demonstrates how to use a service requirement policy.

The automatically instantiated inter-domain SR policy can provide a specified treatment, such as low latency. In the current
release, latency of a link can be expressed by the TE metric. You can configure the TE metric for any link. If the TE metric is not
configured, it defaults to the IGP metric of the link.

NOTE: Some labels and values in this lab are dynamically assigned. Labels and values in your session may differ from those
shown in the example output.

Steps
1. In the example topology, the link between xrvr-5 and xrvr-7 has a TE metric 100. The configuration command is admin-weight.

NOTE: Because of the high TE metric link, the low latency path from csr-1 to csr-9 avoids the xrvr-5 to xrvr-7 link.
RP/0/0/CPU0:xrvr-5#g1
RP/0/0/CPU0:xrvr-5#show running-config mpls traffic-eng
mpls traffic-eng
interface GigabitEthernet0/0/0/1
admin-weight 100
!
!

NOTE: The operator provides the default shortest-path reachability to all prefixes in vrf BLUE and a low-latency path for specific
prefixes. The egress PE marks these specific prefixes with a BGP community. In the following step, use community 100:777 to
express low latency.

2. In the example, csr-9 advertises two prefixes in vrf BLUE: 150.1.1.9/32 and 150.2.2.9/32. 150.1.1.9/32 requires a low-latency
path and is therefore tagged with community 0:777. The community is set with a route-map on the network statement.
csr-9#g2
csr-9#show running | section ^route-map OUT_ODN-TE
route-map OUT_ODN-TE permit 10
set community 0:777

3. Csr-9 advertises two prefixes in vrf BLUE: 150.1.1.9/32, with a low latency requirement ,and 150.2.2.9/32, which requires the
shortest path reachability. The route-map OUT_ODN-TE is attached to the network statement of 150.1.1.9/32.
csr-9#g3
csr-9#show running | section ^ address-family ipv4 vrf BLUE
address-family ipv4 vrf BLUE
network 150.1.1.9 mask 255.255.255.255 route-map OUT_ODN-TE
network 150.2.2.9 mask 255.255.255.255

4. On the ingress PE csr-1, an ingress route-map named ODN is used to select the SR policy template (attribute-set) to use for
each prefix.
csr-1#g4
csr-1#show running | section ^route-map ODN permit
route-map ODN permit 10

© 2017 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 34 of 46
 Cisco dCloud

match community ODN-IGP

set attribute-set ODN-IGP
route-map ODN permit 20
match community ODN-TE
set attribute-set ODN-TE
route-map ODN permit 30
match as-path 1
set attribute-set ODN-IGP
route-map ODN permit 40

csr-1#g5
csr-1#show ip community-list ODN-IGP
Named Community standard list ODN-IGP
permit 666

csr-1#g6
csr-1#show ip community-list ODN-TE
Named Community standard list ODN-TE
permit 777

csr-1#g7
csr-1#show ip as-path-access-list 1
AS path access list 1
permit 64003

NOTE: For prefixes matching community 666 (or 0:666), as specified in community-list ODN-IGP, use the attribute-set ODN-IGP.
For prefixes matching community 777 (or 0:777), as specified in community-list ODN-TE, use the attribute-set ODN-TE. For
prefixes with AS 64003 in its AS-path, as specified in as-path-access-list 1, use the attribute-set ODN-IGP. Prefixes that do not
match any of the above criteria, do not set an attribute-set.

5. This route-map specifies that for all prefixes with AS 64003 in its AS-path, the attribute-set ODN-IGP must be used. The
operator may choose to tag all prefixes with a community instead of selecting the attribute-set based on AS-path. Prefixes that
are tagged with community 0:666 use the same attribute-set ODN-IGP. Prefixes tagged with community 0:777 use the
attribute-set ODN-TE. This attribute-set specifies using PCE to compute path and optimize TE metric.
csr-1#g8
csr-1#show running | section ^mpls traffic-eng lsp attributes ODN-TE
mpls traffic-eng lsp attributes ODN-TE
path-selection metric te
path-selection segment-routing adjacency protected
pce

6. On csr-1, apply the route-policy ODN as ingress policy for BGP neighbor 1.1.1.12.
!! on csr-1
exec g9

config t
router bgp 64001
address-family vpnv4
neighbor 1.1.1.12 route-map ODN in
end

7. On csr-9, enter the following commands to un-shut the loopback150 interface to advertise the vrf BLUE prefixes by csr-9.

© 2017 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 35 of 46
 Cisco dCloud

!! on csr-9
exec g10

config t
interface Loopback150
no shutdown
end

8. Enter the following command and notice the vrf BLUE prefixes received on csr-1; attribute-set ODN-TE is applied to
150.1.1.9/32 and attribute-set ODN-IGP is applied to 150.2.2.9/32.

NOTE: The output shows two paths that are transported over an SR policy, as seen from the binding SID entry in the path info.
The SR policies each have an associated attribute-set shown between parentheses after the binding SID.
csr-1#g11
csr-1#show bgp vrf BLUE vpnv4 unicast detail

Route Distinguisher: 1.1.1.1:1 (default for vrf BLUE)

BGP routing table entry for 1.1.1.1:1:150.1.1.1/32, version 3
Paths: (1 available, best #1, table BLUE)
Advertised to update-groups:
1
Refresh Epoch 1
Local
0.0.0.0 (via vrf BLUE) from 0.0.0.0 (1.1.1.1)
Origin IGP, metric 0, localpref 100, weight 32768, valid, sourced, local, best
Extended Community: RT:1:150
mpls labels in/out 23/nolabel(BLUE)
rx pathid: 0, tx pathid: 0x0
BGP routing table entry for 1.1.1.1:1:150.1.1.9/32, version 36
Paths: (1 available, best #1, table BLUE)
Not advertised to any peer
Refresh Epoch 1
64003, imported path from 1.1.1.9:1:150.1.1.9/32 (global)
1.1.1.9 (via default) from 1.1.1.12 (1.1.1.12)
Origin IGP, localpref 100, valid, internal, best

Community: 777
Extended Community: RT:1:150
mpls labels in/out nolabel/21
binding SID: 27 (ODN-TE)
rx pathid: 0, tx pathid: 0x0
BGP routing table entry for 1.1.1.1:1:150.2.2.9/32, version 37
Paths: (1 available, best #1, table BLUE)
Not advertised to any peer
Refresh Epoch 1
64003, imported path from 1.1.1.9:1:150.2.2.9/32 (global)
1.1.1.9 (via default) from 1.1.1.12 (1.1.1.12)
Origin IGP, localpref 100, valid, internal, best
Extended Community: RT:1:150
mpls labels in/out nolabel/22
binding SID: 28 (ODN-IGP)
rx pathid: 0, tx pathid: 0x0

© 2017 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 36 of 46
 Cisco dCloud

9. Enter the following command to discover the SR policies with ODN-TE attribute-set and ODN-IGP attribute-set. The SR policy
with ODN-TE attribute-set has a binding-SID 27, as shown in the output in step 8. The following command shows which tunnel
interface is used to represent the SR policy (tunnel 2001, in this example). Using this tunnel interface number, the SR policy
path can be displayed.
csr-1#exec g12(27)
csr-1#show mpls forwarding labels 27 detail

Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or Tunnel Id Switched interface
27 Pop Label 2001/1[TE-Bind] 0 Tu2001 point2point
MAC/Encaps=14/34, MRU=1484, Label Stack{16004 24008 24000 16010 16009}, via Gi2
FA163E4ECF2CFA163E1C352A8847 03E8400005DC800005DC000003E8A00003E89000
No output feature configured

csr-1#exec g13(2001)
csr-1#show mpls traffic-eng tunnels tunnel 2001 | i Name:|Metric Type|Bind|Segment|SEGMENT
Name: csr-1_t2001 (Tunnel2001) Destination: 1.1.1.9 Ifhandle: 0x15 (auto-tunnel
for BGP TE)
path option 1, (SEGMENT-ROUTING) (PCE) type dynamic (Basis for Setup)
Metric Type: TE (interface)
Tunnel Name: Tunnel2001_w
Binding SID: 27
Segment-Routing Path Info (isis level-2)
Segment0[Node]: 1.1.1.3, Label: 16003
Segment1[Node]: 1.1.1.4, Label: 16004
Segment2[Link]: 99.4.6.4 - 99.4.6.6, Label: 24008
Segment3[Link]: 99.6.8.6 - 99.6.8.8, Label: 24000
Segment4[Node]: 1.1.1.10, Label: 16010
Segment5[Node]: 1.1.1.9, Label: 16009

10. Enter the following command to discover the SR policy with attribute-set ODN-IGP. Use the binding-SID label for the ODN-IGP
SR policy (label 28, in this example). The output of the first command shows the tunnel interface number (2002, in this
example). Use that tunnel interface number in the second command.

csr-1#exec g14(28)
csr-1#show mpls forwarding labels 28 detail

Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or Tunnel Id Switched interface
28 Pop Label 2002/1[TE-Bind] 0 Tu2002 point2point
MAC/Encaps=14/26, MRU=1492, Label Stack{24010 16007 16009}, via Gi2
FA163E4ECF2CFA163E1C352A8847 05DCA00003E8700003E89000
No output feature configured

csr-1#exec g15(2002)
csr-1#show mpls traffic-eng tunnels tunnel 2002 | i Name:|Metric Type|Bind|Segment|SEGMENT
Name: csr-1_t2002 (Tunnel2002) Destination: 1.1.1.9 Ifhandle: 0x16 (auto-tunnel
for BGP TE)
path option 1, (SEGMENT-ROUTING) (PCE) type dynamic (Basis for Setup)
Metric Type: IGP (interface)
Tunnel Name: Tunnel2002_w
Binding SID: 28
Segment-Routing Path Info (isis level-2)
Segment0[Node]: 1.1.1.3, Label: 16003

© 2017 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 37 of 46
 Cisco dCloud

Segment1[Link]: 99.3.5.3 - 99.3.5.5, Label: 24010

Segment2[Node]: 1.1.1.7, Label: 16007
Segment3[Node]: 1.1.1.9, Label: 16009

11. Enter the following command to see how the prefixes take a different path to their destinations. Notice that the low-latency
prefix 150.1.1.9 takes the path csr-1  xrvr-4  xrvr-6  csr-8  csr-10  csr-9.
csr-1#g16
csr-1#traceroute vrf BLUE 150.1.1.9

Type escape sequence to abort.

Tracing the route to 150.1.1.9
VRF info: (vrf in name/id, vrf out name/id)
1 99.1.3.3 [MPLS: Labels 16004/24008/24002/16010/16009/21 Exp 0] 9 msec 6 msec 5 msec
2 99.3.4.4 [MPLS: Labels 24008/24002/16010/16009/21 Exp 0] 6 msec 5 msec 5 msec
3 99.4.6.6 [MPLS: Labels 24002/16010/16009/21 Exp 0] 5 msec 6 msec 6 msec
4 99.6.8.8 [MPLS: Labels 16010/16009/21 Exp 0] 6 msec 7 msec 6 msec
5 99.8.10.10 [MPLS: Labels 16009/21 Exp 0] 7 msec 6 msec 7 msec
6 150.1.1.9 6 msec 7 msec 5 msec

12. Enter the following command and notice that the shortest-path prefix 150.2.2.9 takes the path csr-1 > xrvr-3 > xrvr-5 > xrvr-7 >
csr-9.
csr-1#g17
csr-1#traceroute vrf BLUE 150.2.2.9

Type escape sequence to abort.

Tracing the route to 150.2.2.9
VRF info: (vrf in name/id, vrf out name/id)
1 99.1.3.3 [MPLS: Labels 24013/16007/16009/22 Exp 0] 7 msec 6 msec 5 msec
2 99.3.5.5 [MPLS: Labels 16007/16009/22 Exp 0] 4 msec 6 msec 5 msec
3 99.5.7.7 [MPLS: Labels 16009/22 Exp 0] 6 msec 6 msec 5 msec
4 150.1.1.9 6 msec 6 msec 5 msec

© 2017 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 38 of 46
 Cisco dCloud

© 2017 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 39 of 46
 Cisco dCloud

Scenario 7. Use ODN with Disjoint Service

XTC can compute disjoint inter-domain paths even from two different head-ends to two different end-points. This scenario
demonstrates how disjoint paths between distinct pairs of nodes can be automatically instantiated.

In this scenario, the operator wants to provide disjoint paths for vrf LIVE prefixes. The paths from csr-1 to csr-9 and from csr-2 to
csr-10 must be disjoint and have an optimal IGP metric. Due to the high IGP metric link between xrvr-6 and xrvr-8, both paths
prefer to avoid this link.

To achieve path disjointness, both paths are added to the same node disjointness association group. XTC provides disjointness
between paths that belong to the same disjointness association group. Each disjointness association group can contain maximum
two members.

NOTE: Some labels and values in this lab are dynamically assigned. Labels and values in your session may differ from those
shown in the example output.

Steps
1. Egress nodes csr-9 and csr-10 tag their prefixes, 100.1.1.9/32 and 100.1.1.10/32, respectively. To indicate node disjointness,
csr-9 tags its prefix with community 0:888 and csr-10 uses community 0:999.
csr-9#h1
csr-9#show running-config | section ^route-map OUT_ODN-DISJ
route-map OUT_ODN-DISJ permit 10
set community 0:888

csr-10#h2
csr-10#show running-config route-policy OUT_ODN-DISJ
route-map OUT_ODN-DISJ permit 10
set community 999

2. On ingress nodes csr-1 and csr-2, an ingress route-map ODN_Disjointness applies the disjointness attribute-set for prefixes
tagged with community 0:888 or 0:999, respectively.
csr-1#h3
csr-1#show running-config | section ^route-map ODN_Disjointness
route-map ODN_Disjointness permit 10
match community ODN-DISJ
set attribute-set ODN-DISJ
route-map ODN_Disjointness permit 20

csr-1#h4
csr-1#show running-config | section ^ip community-list standard ODN-DISJ
ip community-list standard ODN-DISJ permit 888

csr-2#h5
csr-2#show running-config | section ^route-map ODN_Disjointness
route-map ODN_Disjointness permit 10
match community ODN-DISJ
set attribute-set ODN-DISJ
route-map ODN_Disjointness permit 20

© 2017 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 40 of 46
 Cisco dCloud

csr-2#h6
csr-2#show running-config | section ^ip community-list standard ODN-DISJ
ip community-list standard ODN-DISJ permit 999

3. The ODN-DISJ attribute-set is the same on nodes csr-1 and csr-2. The pair (source 0.0.0.0, group-id 1) identify the node
disjoint association group.
csr-1#h7
csr-1#show running | section ^mpls traffic-eng lsp attributes ODN-DISJ
mpls traffic-eng lsp attributes ODN-DISJ
path-selection metric igp
path-selection segment-routing adjacency protected
pce disjoint-path source 0.0.0.0 type node group-id 1

4. Enter the following commands to apply the ODN-Disjointness ingress route-policy on csr-1 and csr-2:
!! on csr-1 and csr-2
exec h8

config t
router bgp 64001
address-family vpnv4
neighbor 1.1.1.12 route-map ODN-Disjointness in
end

5. For illustration purposes, first the path from csr-2 to csr-10 is requested. Enter the following commands to advertise the vrf
LIVE prefix on csr-10 with disjointness community:
!! on csr-10
exec h9

config t
router bgp 64003
address-family ipv4 vrf LIVE
network 100.1.1.10 mask 255.255.255.255 route-map OUT_ODN-DISJ
end

6. After a while, the prefix is received on csr-2 with community 999, and the attribute-set ODN-DISJ is applied on the SR policy.

NOTE: It can take some time for the BGP update to propagate. If you don’t see the TE tunnel attribute-set line in the output then
try again few seconds later.
csr-2#h10
csr-2#show bgp vrf LIVE 100.1.1.10/32
BGP routing table entry for 1.1.1.2:0:100.1.1.10/32, version 25
Paths: (1 available, best #1, table LIVE)
Not advertised to any peer
Refresh Epoch 1
64003, imported path from 1.1.1.10:0:100.1.1.10/32 (global)
1.1.1.10 (via default) from 1.1.1.12 (1.1.1.12)
Origin IGP, localpref 100, valid, internal, best
Community: 999
Extended Community: RT:1:100
mpls labels in/out nolabel/21
binding SID: 21 (ODN-DISJ)

© 2017 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 41 of 46
 Cisco dCloud

rx pathid: 0, tx pathid: 0x0

7. Use the binding-SID label 21 to find the SR policy’s tunnel interface. In this example, it is tunnel 2000. Remember this tunnel
interface number, because you will need it later in the scenario.
csr-2#exec h11(21)
csr-2#show mpls forwarding labels 21

Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or Tunnel Id Switched interface
21 [T] Pop Label 2000/1[TE-Bind] Tu2000 point2point
[T] Pop Label 2000/1[TE-Bind] Tu2000 point2point

[T] Forwarding through a LSP tunnel.

View additional labelling info with the 'detail' option

8. Enter the following command to verify the path of the SR policy with tunnel 2000.
csr-2#exec h12(2000)
csr-2#show mpls traffic-eng tunnels tunnel 2000 | begin Segment-Routing Path Info
Segment-Routing Path Info (isis level-2)
Segment0[Node]: 1.1.1.3, Label: 16003
Segment1[Link]: 99.3.5.3 - 99.3.5.5, Label: 24013
Segment2[Node]: 1.1.1.7, Label: 16007
Segment3[Node]: 1.1.1.10, Label: 16010

csr-2#h13
csr-2#traceroute vrf LIVE 100.1.1.10
Type escape sequence to abort.
Tracing the route to 100.1.1.10
VRF info: (vrf in name/id, vrf out name/id)
1 99.2.4.4 [MPLS: Labels 16003/24013/16007/16010/21 Exp 0] 10 msec 7 msec 7 msec
2 99.3.4.3 [MPLS: Labels 24013/16007/16010/21 Exp 0] 7 msec 7 msec 7 msec
3 99.3.5.5 [MPLS: Labels 16007/16010/21 Exp 0] 8 msec 7 msec 8 msec
4 99.5.7.7 [MPLS: Labels 16010/21 Exp 0] 8 msec 8 msec 7 msec
5 99.7.9.9 [MPLS: Labels 16010/21 Exp 0] 8 msec 8 msec 7 msec
6 100.1.1.10 7 msec 8 msec 8 msec

NOTE: The path is csr-2  xrvr-3  xrvr-5  xrvr-7  csr-10. Remember that the link between xrvr-6 and csr-8 have a higher
IGP metric (100).

© 2017 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 42 of 46
 Cisco dCloud

9. Enter the following command to verify the path of the SR policy on XTC. Use the Tunnel interface number of the ODN-DISJ
SR Policy, as was collected in the previous commands. The Tunnel interface number is 2000 in this example.
RP/0/0/CPU0:xrvr-11#h14(2000)
RP/0/0/CPU0:xrvr-11#show pce lsp pcc ipv4 1.1.1.2 tunnel-id 2000 detail

PCE's tunnel database:

----------------------
PCC 1.1.1.2:

Tunnel Name: Tunnel2000_w

LSPs:
LSP[0]:
source 1.1.1.2, destination 1.1.1.10, tunnel ID 2000, LSP ID 1
State: Admin up, Operation active
Binding SID: 21
PCEP information:
plsp-id 526288, flags: D:1 S:0 R:0 A:1 O:2
LSP Role: Single LSP
State-sync PCE: None
PCC: 1.1.1.2
LSP is subdelegated to: None
Reported path:
Metric type: IGP, Accumulated Metric 0
SID[0]: Node, Label 16003, Address 1.1.1.3
SID[1]: Adj, Label 24013, Address: local 99.3.5.3 remote 99.3.5.5
SID[2]: Node, Label 16007, Address 1.1.1.7
SID[3]: Node, Label 16010, Address 1.1.1.10

© 2017 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 43 of 46
 Cisco dCloud

Computed path: (Local PCE)

Computed Time: Fri Aug 11 12:50:49 2017 (00:04:52 ago)
Metric type: IGP, Accumulated Metric 50
SID[0]: Node, Label 16003, Address 1.1.1.3
SID[1]: Adj, Label 24013, Address: local 99.3.5.3 remote 99.3.5.5
SID[2]: Node, Label 16007, Address 1.1.1.7
SID[3]: Node, Label 16010, Address 1.1.1.10
Recorded path:
None
Disjoint Group Information:

10. On csr-9, enter the following command to advertise the vrf LIVE prefix on csr-9 with disjointness community:
!! on csr-9
exec h15

config t
router bgp 64003
address-family ipv4 vrf LIVE
network 100.1.1.9 mask 255.255.255.255 route-map OUT_ODN-DISJ
end

11. After a while, csr-1 receives the prefix with community 888, and instantiates an SR policy with attribute-set ODN-DISJ.

NOTE: It can take some time for the BGP update to propagate to csr-1. If you see the output % Network not in table try again
after a few seconds.
csr-1#h16
csr-1#show bgp vrf LIVE 100.1.1.9/32
BGP routing table entry for 1.1.1.1:0:100.1.1.9/32, version 52
Paths: (1 available, best #1, table LIVE)
Not advertised to any peer
Refresh Epoch 1
64003, imported path from 1.1.1.9:0:100.1.1.9/32 (global)
1.1.1.9 (via default) from 1.1.1.12 (1.1.1.12)
Origin IGP, localpref 100, valid, internal, best
Community: 888
Extended Community: RT:1:100
mpls labels in/out nolabel/23
binding SID: 26 (ODN-DISJ)
rx pathid: 0, tx pathid: 0x0

12. Use the binding-SID label of the previous command (26, in this example; your session may yield a different binding-SID label)
to find the tunnel interface number.
csr-1#exec h17(26)
csr-1#show mpls forwarding labels 26

Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or Tunnel Id Switched interface
26 [T] Pop Label 2000/1[TE-Bind] 0 Tu2000 point2point

[T] Forwarding through a LSP tunnel.

View additional labelling info with the 'detail' option

© 2017 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 44 of 46
 Cisco dCloud

13. Use the tunnel interface number from the previous command output, 2000, in this example. The path is csr-1  xrvr-3  xrvr-
5  xrvr-7  csr-9. This seems to collide with the path from csr-2 to csr-10, which also traversed xrvr-3  xrvr-5  xrvr-7.
csr-1#exec h18(2000)
csr-1#show mpls traffic-eng tunnels tunnel 2000 | begin Segment-Routing Path Info
Segment-Routing Path Info (isis level-2)
Segment0[Node]: 1.1.1.3, Label: 16003
Segment1[Link]: 99.3.5.3 - 99.3.5.5, Label: 24013
Segment2[Node]: 1.1.1.7, Label: 16007
Segment3[Node]: 1.1.1.9, Label: 16009

csr-1#h19
csr-1#traceroute vrf LIVE 100.1.1.9
Type escape sequence to abort.
Tracing the route to 100.1.1.9
VRF info: (vrf in name/id, vrf out name/id)
1 99.1.3.3 [MPLS: Labels 24013/16007/16009/23 Exp 0] 6 msec 6 msec 5 msec
2 99.3.5.5 [MPLS: Labels 16007/16009/23 Exp 0] 4 msec 4 msec 4 msec
3 99.5.7.7 [MPLS: Labels 16009/23 Exp 0] 5 msec 4 msec 4 msec
4 100.1.1.9 5 msec 4 msec 4 msec

14. Verify the csr-2 to csr-10 path again. The tunnel interface number is the same one as before the path from csr-1 to csr-9 was
established, 2000, in the example. If you strictly followed these instructions, you can also simply repeat the last command run
on csr-2. The path is now: csr-2  xrvr-4  xrvr-6  csr-8  csr-10. XTC has updated this path following the request for the
path from csr-1 to csr-9 to achieve node disjointness.
csr-2#exec h20(2000)
csr-2#show mpls traffic-eng tunnels tunnel 2000 | begin Segment-Routing Path Info
show mpls traffic-eng tunnels tunnel 2000 | begin Segment-Routing Path Info
Segment-Routing Path Info (isis level-2)
Segment0[Node]: 1.1.1.4, Label: 16004
Segment1[Link]: 99.4.6.4 - 99.4.6.6, Label: 24008
Segment2[Link]: 99.6.8.6 - 99.6.8.8, Label: 24002
Segment3[Node]: 1.1.1.10, Label: 16010

csr-2#h21
csr-2#traceroute vrf LIVE 100.1.1.10
Type escape sequence to abort.
Tracing the route to 100.1.1.10
VRF info: (vrf in name/id, vrf out name/id)
1 99.2.4.4 [MPLS: Labels 24008/24002/16010/21 Exp 0] 7 msec 5 msec 5 msec
2 99.4.6.6 [MPLS: Labels 24002/16010/21 Exp 0] 5 msec 6 msec 5 msec
3 99.6.8.8 [MPLS: Labels 16010/21 Exp 0] 7 msec 5 msec 5 msec
4 100.1.1.10 6 msec 5 msec 5 msec

© 2017 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 45 of 46
 Cisco dCloud

© 2017 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 46 of 46