Segment Routing Traffic Eng v1

Cisco dCloud
Segment Routing Traffic Engineering Lab v1

Last Updated: 30-NOVEMBER-2016
About This Lab

This preconfigured Segment Routing for Traffic Engineering lab includes:
• About This Lab
• Requirements
• About This Solution
• Topology
• Get Started
• Scenario 1: Configure Segment Routing Traffic Engineering
• Scenario 2: Configure SR-TE Paths
• Scenario 3: Explore SR-TE with Path Control Delegation to a PCE
• Scenario 4: Explore SR-TE with PCE-Initiated Paths
• Scenario 5: Explore BGP SR-TE Dynamic
Requirements
Table 1. Requirements
Required Optional
● Laptop ● Cisco AnyConnect®
About This Solution

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. Theory sessions on SR are
recommended to deepen understanding.
IMPORTANT: You must enter conf t to access configuration mode and commit to make the changes effective.
The lab is pre-configured with a functioning IP unicast L3 configuration. Integrated IS-IS is enabled with a single, L2-only IS-IS
setup on all routers. All base addressing and routing functionality is pre-configured.
© 2016 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 1 of 58
Cisco dCloud
Topology
This content includes preconfigured users and components to illustrate the scripted scenarios and features of the solution. Most
components are fully configurable with predefined administrative user accounts. You can see the IP address and user account
credentials to use to access a component by clicking the component icon in the Topology menu of your active session and in the
scenario steps that require their use.
Figure 1. dCloud Topology
Cisco dCloud
Figure 2. Logical Topology
 Directly connected interfaces but no carrier detection

 Last octet of the IP address is a device number
 /24 addressing on Ethernet subnets
10.1.24/24
G0/0/0/1 G0/0/0/0
G0/0/0/0 R2p R4p G0/0/0/1
G0/0/0/2 G0/0/0/2
10.1.12/24 10.1.46/24
G0/0/0/0 G0/0/0/0
10.1.23/24 10.1.45/24
R1pe R6pe
G0/0/0/1 G0/0/0/1
10.1.13/24 10.1.56/24
G0/0/0/2 G0/0/0/2 G0/0/0/1

G0/0/0/0
G0/0/0/1 G0/0/0/0
R11pe R3p R5p
10.1.35/24
Loopbacks list:
R1 Lo0: 1.1.1.1/32
R2 Lo0: 2.2.2.2/32
R3 Lo0: 3.3.3.3/32
R4 Lo0: 4.4.4.4/32
R5 Lo0: 5.5.5.5/32
R6 Lo0: 6.6.6.6/32
R2p, R3p, R4p, R5p – provider core (P) routers
R1pe, R6pe – provider edge (PE) routers
Table 2. Preconfigured User Information
Nodes Username Password
Routers cisco cisco
OpenDaylight ubuntu ubuntu
Cisco dCloud
Get Started
BEFORE PRESENTING
We strongly recommend that you go through this document and work 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.
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.252, Username: administrator, Password: C1sco12345
3. From the workstation desktop, double-click the VM Maestro icon to access the LABRST-2022-SRTE-dcloud sample topology.
4. Click the Launch Simulation icon to start the simulation.
Figure 3. Launch Simulation
5. Wait for all nodes to become ACTIVE.
Cisco dCloud
6. From the Simulations pane, right-click LABRST-2022-SRTE-dcloud and select Telnet > To All 7 Available Console Ports.
Figure 4. Telnet to Console Ports
7. Press Enter in each console terminal to access the CLI and log in by using the credentials described in Table 2.
Cisco dCloud
Scenario 1. Configure Segment Routing Traffic Engineering

This scenario demonstrates how to configure basic segment routing and how to enable SR-TE. Using this scenario, you will do the
following:
• Enable IS-IS wide metric.
• Enable segment routing with MPLS data plane for IPv4 unicast address family under IS-IS.
• Enable IS-IS traffic engineering extensions in level-2 area and use Loopback0 as TE router id.
• Advertise prefix (node) segment ID (SID) for Loopback0 interfaces.
Steps
Perform Initial Configuration
1. Configure the following commands on all routers:
NOTE: In the following commands, replace <index> with the router number. Use 1 for R1, use 2 for R2, and so forth.
mpls traffic-eng
router isis main

address-family ipv4 unicast
metric-style wide
segment-routing mpls
mpls traffic-eng level-2-only
mpls traffic-eng router-id Loopback0
interface Loopback0
prefix-sid index <index>
NOTE: You can specify prefix-sid with an index value, as shown in the example, or with an absolute value by using this command:
prefix-sid absolute <value>. Because the default Segment Routing Global Block (SRGB) of 16000-23999 is used, and prefix
segment IDs (SIDs) for loopbacks are specified with an index value equal to the router number, the actual values of the prefix SIDs
for loopbacks will be 16000+<index> = 16001, 16002, and so forth.
Cisco dCloud
Verify Interfaces
1. Enter the following command to verify the interfaces enabled for MPLS. Notice that all interfaces are enabled for MPLS
forwarding because of SR and MPLS TE configuration.
RP/0/0/CPU0:R2p#show mpls interfaces
Interface LDP Tunnel Static Enabled
-------------------------- -------- -------- -------- --------
GigabitEthernet0/0/0/0 No Yes No Yes
2. Enter the following command to verify the MPLS labels owned by IS-IS. IS-IS owns Segment Routing Global Block (SRGB)
with a starting label of 16000 and size of 8000 (SRBG is 16000-23999). Notice that six labels from the dynamic label pool,
which starts at 24000, are allocated for six SR adjacency segments.
RP/0/0/CPU0:r2p#sh mpls label table application isis detail
Thu Jan 1 13:46:50.220 UTC
0 16000 ISIS(A):main InUse No
(Lbl-blk SRGB, vers:0, (start_label=16000, size=8000)
0 24000 ISIS(A):main InUse Yes
(SR Adj Segment IPv4, vers:0, index=1, type=0, intf=Gi0/0/0/1, nh=10.1.24.4)
3. Enter the following command to review IS-IS adjacency information on r2pe. Notice that two adjacency SIDs are allocated for
each interface, the first of which is protected by FRR; the second is not protected by FRR.
RP/0/0/CPU0:r2p#sh isis adjacency detail
Thu Jan 1 12:36:17.670 UTC
IS-IS main Level-2 adjacencies:

System Id Interface SNPA State Hold Changed NSF IPv4 IPv6
BFD BFD
r4p Gi0/0/0/1 *PtoP* Up 28 01:10:00 Yes None None
Area Address: 49
Neighbor IPv4 Address: 10.1.24.4*
Adjacency SID: 24000
Non-FRR Adjacency SID: 24001
Topology: IPv4 Unicast
r1pe Gi0/0/0/0 *PtoP* Up 23 01:10:00 Yes None None
Area Address: 49
Area Address: 49
Cisco dCloud

Total adjacency count: 3

RP/0/0/CPU0:r2p#
4. Enter the following command to review IS-IS adjacency information on r1pe. Notice in the output on both r1pe and r2pe,
adjacency SIDs start at 24000 and they overlap; the SID is locally significant.
RP/0/0/CPU0:r1pe#sh isis adjacency detail
Thu Jan 1 12:37:32.363 UTC
IS-IS main Level-1 adjacencies:

System Id Interface SNPA State Hold Changed NSF IPv4 IPv6
BFD BFD
Area Address: 49
Area Address: 49
Total adjacency count: 2

RP/0/0/CPU0:r10pe#s
5. Enter the following command to review the IS-IS database for the r1pe (Link State Packet) LSP to observe IS-IS extensions
for segment routing and traffic engineering:
RP/0/0/CPU0:r2p#sh isis database verbose r1pe
Tue Jan 1 00:14:03.863 UTC
IS-IS main (Level-2) Link State Database

LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL
r1pe.00-00 0x0000000e 0xd02d 483 0/0/0
Area Address: 49
NLPID: 0xcc
Hostname: r1pe
IP Address: 1.1.1.1
Router Cap: 1.1.1.1, D:0, S:0
Segment Routing: I:1 V:0, SRGB Base: 16000 Range: 8000
Router ID: 1.1.1.1
Metric: 100 IS-Extended r2p.00
ADJ-SID: F:0 B:1 V:1 L:1 S:0 weight:0 Adjacency-sid:24000
Affinity: 0x00000000
Interface IP Address: 10.1.12.1
Neighbor IP Address: 10.1.12.2
Physical BW: 1000000 kbits/sec
Cisco dCloud
Reservable Global pool BW: 0 kbits/sec

Global Pool BW Unreserved:
[0]: 0 kbits/sec [1]: 0 kbits/sec
Admin. Weight: 100
Ext Admin Group: Length: 32
0x00000000 0x00000000
0x00000000 0x00000000
0x00000000 0x00000000
0x00000000 0x00000000
Metric: 100 IS-Extended r3p.00
Affinity: 0x00000000
Interface IP Address: 10.1.13.1
Neighbor IP Address: 10.1.13.3
Physical BW: 1000000 kbits/sec
Reservable Global pool BW: 0 kbits/sec
Global Pool BW Unreserved:
Admin. Weight: 100
Ext Admin Group: Length: 32
0x00000000 0x00000000
0x00000000 0x00000000
0x00000000 0x00000000
0x00000000 0x00000000
Metric: 0 IP-Extended 1.1.1.1/32
Prefix-SID Index: 1, Algorithm:0, R:0 N:1 P:0 E:0 V:0 L:0
Total Level-2 LSP count: 1 Local Level-2 LSP count: 0

RP/0/0/CPU0:r2p#
From the output, notice the new TLVs added after enabling enabled segment routing in the initial configuration, specifically:
• Router capability TLV with segment routing capability sub-TLV under it, specifying:
o The router has segment routing data plane capability.
o The router is IPv4 capable on all interfaces (I:1) without IPv6 (V:0).
o The parameters of SRGB: 16000 starting value (SRGB base: 16000) and a label range of 8000 (SRBG is 16000-23999).
• Two IS-extended reachability TLVs (TLV22) for two neighbors of r1pe (r2p and r3p), each with two ADJ-SID sub-TLVs that
describe two adjacency segments associated with a neighbor. For example, the r2p neighbor has two adjacency SIDs, each
with IPv4 outgoing encapsulation (F:0) and locally significant (L:1) value (V:1) of 24000 (or 24001). One of two ADJ-SIDs is
eligible for FRR protection (B:1), but the another is not (B:0).
Cisco dCloud
• Under ADJ-SIDs sub-TLV, notice all sub-TLVs for IS-IS traffic engineering extensions: affinity, interface IP Address, neighbor
IP address, physical bandwidth, and so forth.
• One IP-extended reachability TLV (TLV135) for Loopback0 prefix 1.1.1.1/32 with prefix-SID sub-TLV under it that describes
the prefix segment associated with it. The prefix segment has the following properties:
o It is a node-SID (N:1). That is, it’s allocated to a loopback that identifies a node.
o It has a globally significant (L:0) index (V:0) value of 1.
o No-PHP flag is clear (P:0). That is, the penultimate hop must pop the prefix-SID before forwarding the packet.
o The explicit-null flag is clear (E:0). That is, the penultimate hop must not replace prefix-SID with explicit-null label.
o The re-advertisement flag is clear (R:0). That is, it has not been re-advertised from another protocol or another IS-IS level.
6. Enter the following commands to review the RIB for 6.6.6.6/32 prefix on r1pe:
sh ip route 6.6.6.6/32 detail
sh isis route detail
7. Notice the local and remote labels received from IS-IS: Both are equal to the prefix-SID of 16006. Also, there are two paths
with equal costs from R1 to 6.6.6.6 through R2 (R1>R2>R4> R6) and through R3 (R1>R3>R5>R6).
RP/0/0/CPU0:r1pe#sh ip route 6.6.6.6/32 detail
Fri Jan 1 11:17:50.152 UTC
Routing entry for 6.6.6.6/32

Known via "isis main", distance 115, metric 300
Tag 2, type level-2
Installed Jan 9 11:11:41.397 for 00:06:08
Routing Descriptor Blocks
10.1.12.2, from 6.6.6.6, via GigabitEthernet0/0/0/0
Route metric is 300
Label: 0x3e86 (16006)
Tunnel ID: None
Extended communities count: 0
Path id:2 Path ref count:0
NHID:0x1(Ref:6)
10.1.13.3, from 6.6.6.6, via GigabitEthernet0/0/0/1
Route metric is 300
Label: 0x3e86 (16006)
Tunnel ID: None
Extended communities count: 0
Path id:1 Path ref count:0
NHID:0x2(Ref:6)
Route version is 0x15 (21)
Local Label: 0x3e86 (16006)
IP Precedence: Not Set
QoS Group ID: Not Set
Flow-tag: Not Set
Route Priority: RIB_PRIORITY_NON_RECURSIVE_MEDIUM (7) SVD Type RIB_SVD_TYPE_LOCAL
Download Priority 1, Download Version 643
No advertising protos.
RP/0/0/CPU0:r1pe#
RP/0/0/CPU0:r1pe#sh isis route detail
Mon Jan 25 22:15:50.818 UTC
Cisco dCloud
IS-IS main IPv4 Unicast routes
Codes: L1 - level 1, L2 - level 2, ia - interarea (leaked into level 1)

df - level 1 default (closest attached router), su - summary null
C - connected, S - static, R - RIP, B - BGP, O - OSPF
E - EIGRP, A - access/subscriber, M - mobile, a - application
i - IS-IS (redistributed from another instance)
Maximum parallel path count: 8
C 1.1.1.1/32
is directly connected, Loopback0
L2 adv [0] IS-IS interface, prefix-SID index 1, R:0 N:1 P:0 E:0 V:0 L:0
L2 2.2.2.2/32 [100/115] medium priority
via 10.1.12.2, GigabitEthernet0/0/0/0, r2p, SRGB Base: 16000, Weight: 0
src r2p.00-00, 2.2.2.2, prefix-SID index 2, R:0 N:1 P:0 E:0 V:0 L:0
src r6pe.00-00, 6.6.6.6, prefix-SID index 6, R:0 N:1 P:0 E:0 V:0 L:0
C 10.1.12.0/24
is directly connected, GigabitEthernet0/0/0/0
L2 adv [100] IS-IS interface
C 10.1.13.0/24
is directly connected, GigabitEthernet0/0/0/1
L2 adv [100] IS-IS interface
L2 10.1.23.0/24 [200/115] low priority
src r3p.00-00, 3.3.3.3
src r2p.00-00, 2.2.2.2
L2 10.1.24.0/24 [200/115] low priority
src r2p.00-00, 2.2.2.2
L2 10.1.35.0/24 [200/115] low priority
src r3p.00-00, 3.3.3.3
L2 10.1.45.0/24 [300/115] low priority
src r5p.00-00, 5.5.5.5
src r4p.00-00, 4.4.4.4
L2 10.1.46.0/24 [300/115] low priority
src r4p.00-00, 4.4.4.4
Cisco dCloud
L2 10.1.56.0/24 [300/115] low priority

src r5p.00-00, 5.5.5.5
RP/0/0/CPU0:r1pe#
8. Enter the following command to review the FIB for 6.6.6.6/32 prefix on r1pe. Notice the same label imposed on both paths.
RP/0/0/CPU0:r1pe#sh cef 6.6.6.6/32
Fri Jan 1 11:19:05.057 UTC
6.6.6.6/32, version 643, internal 0x1000001 0x1 (ptr 0xa135b3f4) [1], 0x0 (0xa13406c8), 0xa28 (0xa16a3050)
Updated Jan 9 11:11:41.417
local adjacency 10.1.12.2
Prefix Len 32, traffic index 0, precedence n/a, priority 1
via 10.1.12.2, GigabitEthernet0/0/0/0, 9 dependencies, weight 0, class 0 [flags 0x0]
path-idx 0 NHID 0x0 [0xa0ec50bc 0x0]
next hop 10.1.12.2
local adjacency
local label 16006 labels imposed {16006}
via 10.1.13.3, GigabitEthernet0/0/0/1, 9 dependencies, weight 0, class 0 [flags 0x0]
path-idx 1 NHID 0x0 [0xa0ec5184 0x0]
next hop 10.1.13.3
local adjacency
local label 16006 labels imposed {16006}
RP/0/0/CPU0:r1pe#
9. Enter the following command to review the MPLS forwarding table. Notice the prefix-SIDs of all other IS-IS routers and local
adjacency-SIDs.
RP/0/0/CPU0:r1pe#sh mpls forwarding
Fri Jan 9 11:19:45.464 UTC
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
16002 Pop SR Pfx (idx 2) Gi0/0/0/0 10.1.12.2 0
16003 Pop SR Pfx (idx 3) Gi0/0/0/1 10.1.13.3 0
16004 16004 SR Pfx (idx 4) Gi0/0/0/0 10.1.12.2 0
16005 16005 SR Pfx (idx 5) Gi0/0/0/1 10.1.13.3 0
16006 16006 SR Pfx (idx 6) Gi0/0/0/0 10.1.12.2 0
16006 SR Pfx (idx 6) Gi0/0/0/1 10.1.13.3 0
24000 Pop SR Adj (idx 1) Gi0/0/0/0 10.1.12.2 0
24001 Pop SR Adj (idx 3) Gi0/0/0/0 10.1.12.2 0
24002 Pop SR Adj (idx 1) Gi0/0/0/1 10.1.13.3 0
24003 Pop SR Adj (idx 3) Gi0/0/0/1 10.1.13.3 0
RP/0/0/CPU0:r1pe#
10. Enter the following command to review the MPLS SR-TE topology for r1pe. Notice the adjacency-SIDs and other MPLS TE
information.
RP/0/0/CPU0:r1pe#sh mpls traffic-eng topology segment-routing 1.1.1.1
Mon Jan 25 22:26:31.604 UTC
IGP Id: 0010.0100.1001.00, MPLS TE Id: 1.1.1.1 Router Node (IS-IS main level-2)
Segment-Routing:
TE Node-SID Index: 0
SRGB Start: 16000
Cisco dCloud
SRGB Size: 8000
Link[0]:Point-to-Point, Nbr IGP Id:0020.0200.2002.00, Nbr Node Id:8, gen:4850

Frag Id:0, Intf Address:10.1.12.1, Intf Id:0
Segment-Routing Adjacency-SIDs: 2
Adjacency-SID[0]: 24001, Flags: V, L to Nbr:: IGP Id: 0020.0200.2002.00, MPLS TE Id: 2.2.2.2
Adjacency-SID[1]: 24000, Flags: B, V, L to Nbr:: IGP Id: 0020.0200.2002.00, MPLS TE Id: 2.2.2.2
Nbr Intf Address:10.1.12.2, Nbr Intf Id:0
TE Metric:100, IGP Metric:100
Attribute Flags: 0x0
Ext Admin Group:
Length: 256 bits
Value : 0x::
Attribute Names:
Switching Capability:None, Encoding:unassigned
BC Model ID:RDM
Physical BW:1000000 (kbps), Max Reservable BW Global:0 (kbps)
Max Reservable BW Sub:0 (kbps)
Global Pool Sub Pool
Total Allocated Reservable Reservable
BW (kbps) BW (kbps) BW (kbps)
--------------- ----------- ----------
bw[0]: 0 0 0
bw[1]: 0 0 0
bw[2]: 0 0 0
bw[3]: 0 0 0
bw[4]: 0 0 0
bw[5]: 0 0 0
bw[6]: 0 0 0
bw[7]: 0 0 0
Link[1]:Point-to-Point, Nbr IGP Id:0030.0300.3003.00, Nbr Node Id:9, gen:4851

Frag Id:0, Intf Address:10.1.13.1, Intf Id:0
Segment-Routing Adjacency-SIDs: 2
Adjacency-SID[0]: 24003, Flags: V, L to Nbr:: IGP Id: 0030.0300.3003.00, MPLS TE Id: 3.3.3.3
Adjacency-SID[1]: 24002, Flags: B, V, L to Nbr:: IGP Id: 0030.0300.3003.00, MPLS TE Id: 3.3.3.3
Nbr Intf Address:10.1.13.3, Nbr Intf Id:0
TE Metric:100, IGP Metric:100
Attribute Flags: 0x0
Ext Admin Group:
Length: 256 bits
Value : 0x::
Attribute Names:
Switching Capability:None, Encoding:unassigned
BC Model ID:RDM
Physical BW:1000000 (kbps), Max Reservable BW Global:0 (kbps)
Max Reservable BW Sub:0 (kbps)
Global Pool Sub Pool
Total Allocated Reservable Reservable
BW (kbps) BW (kbps) BW (kbps)
--------------- ----------- ----------
bw[0]: 0 0 0
bw[1]: 0 0 0
bw[2]: 0 0 0
bw[3]: 0 0 0
Cisco dCloud
bw[4]: 0 0 0
bw[5]: 0 0 0
bw[6]: 0 0 0
bw[7]: 0 0 0
Verify Data Plane Verification
NOTE: At this point, no SR-TE tunnels are configured. Therefore, this optional procedure only verifies basic segment routing with
MPLS data plane.
1. Enter the following command to ping r6pe loopback 6.6.6.6 from r1pe loopback 1.1.1.1:
RP/0/0/CPU0:r1pe#ping 6.6.6.6 source 1.1.1.1
Fri Jan 9 11:55:07.019 UTC
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 79/81/89 ms
RP/0/0/CPU0:r1pe#
2. Enter the following commands on the specific routers to review the MPLS forwarding tables. Notice that the traffic was label-
switched end-to-end and took the R1>R3>R5>R6 path (due to hash). The return traffic, destined towards 1.1.1.1 and the
prefix-SID of 16001, was also label-switched and took the R6>R4>R2>R1 path (due to hash).
From r1pe:
Fri Jan 9 11:19:45.464 UTC
------ ----------- ------------------ ------------ --------------- ------------
16002 Pop SR Pfx (idx 2) Gi0/0/0/0 10.1.12.2 0
16003 Pop SR Pfx (idx 3) Gi0/0/0/1 10.1.13.3 0
16004 16004 SR Pfx (idx 4) Gi0/0/0/0 10.1.12.2 0
16005 16005 SR Pfx (idx 5) Gi0/0/0/1 10.1.13.3 0
16006 16006 SR Pfx (idx 6) Gi0/0/0/0 10.1.12.2 0
16006 SR Pfx (idx 6) Gi0/0/0/1 10.1.13.3 520
24000 Pop SR Adj (idx 1) Gi0/0/0/0 10.1.12.2 0
24001 Pop SR Adj (idx 3) Gi0/0/0/0 10.1.12.2 0
24002 Pop SR Adj (idx 1) Gi0/0/0/1 10.1.13.3 0
24003 Pop SR Adj (idx 3) Gi0/0/0/1 10.1.13.3 0
RP/0/0/CPU0:r1pe#
From r2p:
RP/0/0/CPU0:r2p#sh mpls forwarding labels 16001
Fri Jan 9 11:57:22.131 UTC
------ ----------- ------------------ ------------ --------------- ------------
16001 Pop SR Pfx (idx 1) Gi0/0/0/0 10.1.12.1 520
RP/0/0/CPU0:r2p#
Fri Jan 9 11:28:53.068 UTC
Cisco dCloud

------ ----------- ------------------ ------------ --------------- ------------
16006 16006 SR Pfx (idx 6) Gi0/0/0/1 10.1.24.4 0
RP/0/0/CPU0:r2p#
From r3p:
Fri Jan 9 11:57:09.732 UTC
------ ----------- ------------------ ------------ --------------- ------------
16001 Pop SR Pfx (idx 1) Gi0/0/0/0 10.1.13.1 0
RP/0/0/CPU0:r3p#
Fri Jan 9 11:26:39.857 UTC
------ ----------- ------------------ ------------ --------------- ------------
16006 16006 SR Pfx (idx 6) Gi0/0/0/1 10.1.35.5 520
RP/0/0/CPU0:r3p#
From r4p:
Fri Jan 9 12:00:47.246 UTC
------ ----------- ------------------ ------------ --------------- ------------
16001 16001 SR Pfx (idx 1) Gi0/0/0/0 10.1.24.2 520
RP/0/0/CPU0:r4p#
Fri Jan 9 12:07:09.100 UTC
------ ----------- ------------------ ------------ --------------- ------------
16006 Pop SR Pfx (idx 6) Gi0/0/0/1 10.1.46.6 0
RP/0/0/CPU0:r4p#
From r5p:
Fri Jan 9 12:00:39.187 UTC
------ ----------- ------------------ ------------ --------------- ------------
16001 16001 SR Pfx (idx 1) Gi0/0/0/0 10.1.35.3 0
RP/0/0/CPU0:r5p#
Fri Jan 9 12:02:00.122 UTC
------ ----------- ------------------ ------------ --------------- ------------
16006 Pop SR Pfx (idx 6) Gi0/0/0/1 10.1.56.6 520
RP/0/0/CPU0:r5p#
Cisco dCloud
From r6pe:
Fri Jan 9 11:27:39.632 UTC
------ ----------- ------------------ ------------ --------------- ------------
16001 16001 SR Pfx (idx 1) Gi0/0/0/0 10.1.46.4 520
16001 SR Pfx (idx 1) Gi0/0/0/1 10.1.56.5 0
16002 16002 SR Pfx (idx 2) Gi0/0/0/0 10.1.46.4 0
16003 16003 SR Pfx (idx 3) Gi0/0/0/1 10.1.56.5 0
16004 Pop SR Pfx (idx 4) Gi0/0/0/0 10.1.46.4 0
16005 Pop SR Pfx (idx 5) Gi0/0/0/1 10.1.56.5 0
24000 Pop SR Adj (idx 1) Gi0/0/0/0 10.1.46.4 0
24001 Pop SR Adj (idx 3) Gi0/0/0/0 10.1.46.4 0
24002 Pop SR Adj (idx 1) Gi0/0/0/1 10.1.56.5 0
24003 Pop SR Adj (idx 3) Gi0/0/0/1 10.1.56.5 0
RP/0/0/CPU0:r6pe#
NOTE: Alternatively, you can review the paths and labels by entering traceroute commands.
Cisco dCloud
Scenario 2. Configure SR-TE Paths

This scenario demonstrates how to add a manually configured SR-TE tunnel into the topology. Using this scenario, you will do the
following on r1pe:
• Create three explicit SR-TE paths from r1pe to r6pe.
o The first path uses SIDs 16002, 24000, and 16006.
o The second path uses SIDs 16003 and 16006.
o The third path uses SID 16006.
• Create an SR-TE tunnel with three path options using the defined SR-TE paths.
o The first path goes through the best IGP path from R1 to R2 (using 16002), and it takes the link between R2 and R4
(specified with R2’s ADJ-SID 24000). Then it goes through the best IGP path from R4 to R6 (using 16006).
o The second path goes through the best IGP path from R1 to R3 (using 16003), and it takes the best IGP path from R3 to
R6 (using 16006), which will ultimately be through R5.
o The third path goes through the best IGP path from R1 to R6 (using 16006), which will ultimately be through two equal
cost paths R1-R2-R4-R6 and R1-R3-R5-R6.
Steps
1. Configure the following commands on r1pe:
explicit-path name r1-r2-r4-r6
index 10 next-label 16002
explicit-path name r1-r3-r6

explicit-path name r1-r6

interface tunnel-te10
ipv4 unnumbered Loopback0
signalled-name r1-r6-tunnel
autoroute announce
destination 6.6.6.6
path-option 10 explicit name r1-r2-r4-r6 segment-routing
path-option 20 explicit name r1-r3-r6 segment-routing
path-option 30 explicit name r1-r6 segment-routing
Cisco dCloud
Verify SR-TE Path
1. Enter the following commands to verify the SR-TE path on r1pe. Notice that the tunnel is up, and the first path option is in use,
binding the SID associated with the tunnel and the details of SR path information for the current LSP (label-switched path).
RP/0/0/CPU0:r1pe#sh mpls traffic-eng tunnels segment-routing brief
Wed Jan 27 18:53:36.937 UTC
TUNNEL NAME DESTINATION STATUS STATE

tunnel-te10 6.6.6.6 up up
Displayed 1 (of 1) heads, 0 (of 0) midpoints, 0 (of 0) tails
Displayed 1 up, 0 down, 0 recovering, 0 recovered heads
RP/0/0/CPU0:r1pe#
RP/0/0/CPU0:r1pe#sh mpls traffic-eng tunnels segment-routing detail
Wed Jan 27 18:54:01.455 UTC
Name: tunnel-te10 Destination: 6.6.6.6 Ifhandle:0x580

Signalled-Name: r1-r6-tunnel
Status:
Admin: up Oper: up Path: valid Signalling: connected
path option 10, (Segment-Routing) type explicit r1-r2-r4-r6 (Basis for Setup)
Protected-by PO index: none
path option 20, (Segment-Routing) type explicit r1-r3-r6
path option 30, (Segment-Routing) type explicit r1-r6
G-PID: 0x0800 (derived from egress interface properties)
Bandwidth Requested: 0 kbps CT0
Creation Time: Wed Jan 27 18:51:15 2016 (00:02:46 ago)
Config Parameters:
Bandwidth: 0 kbps (CT0) Priority: 7 7 Affinity: 0x0/0xffff
Metric Type: TE (default)
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
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: 10
Binding SID: 24004
History:
Tunnel has been up for: 00:02:45 (since Wed Jan 27 18:51:16 UTC 2016)
Current LSP:
Uptime: 00:02:45 (since Wed Jan 27 18:51:16 UTC 2016)
Cisco dCloud
Prior LSP:
ID: 3 Path Option: 10
Removal Trigger: path tear
Current LSP Info:
Instance: 4, Signaling Area: IS-IS main level-2
Soft Preemption: None
SRLGs: not collected
Path Info:
Segment-Routing Path Info (IS-IS main level-2)
Segment0[ - ]: Label: 16002

RP/0/0/CPU0:r1pe#
2. Enter the following commands to review the MPLS data plane and see SR labels for the tunnel.
In the output, notice the bottom label 24000, the output interface tt10, and the labels 24000 and 16006 imposed on the
tunneled traffic. There are only two labels imposed: the ADJ-SID for the P1>P2 link and the prefix-SID for R6. The prefix-SID
of R2 (16002), specified as first SID in the path, directs traffic from R1 to R2. However, the label itself is not imposed due to
penultimate-hop popping, which is signaled for prefix-SID by default, as shown in Scenario 1. Looking at MPLS forwarding
tables on the routers in the path of the tunnel, notice the corresponding increase in the label-switched bytes counters for the
used labels.
NOTE: The binding SID 24004, associated with the tunnel, is the local label directing the traffic into the tunnel.
RP/0/0/CPU0:r1pe#ping 6.6.6.6
Fri Jan 9 11:55:07.019 UTC
!!!!!
RP/0/0/CPU0:r1pe#
RP/0/0/CPU0:r1pe#sh mpls forwarding tunnels
Wed Jan 27 19:10:18.578 UTC
Tunnel Outgoing Outgoing Next Hop Bytes
Name Label Interface Switched
------------- ----------- ------------ --------------- ------------
tt10 (SR) 24000 Gi0/0/0/0 10.1.12.2 520
RP/0/0/CPU0:r1pe#sh mpls forwarding tunnels detail
Wed Jan 27 19:10:26.398 UTC
------------- ----------- ------------ --------------- ------------
tt10 (SR) 24000 Gi0/0/0/0 10.1.12.2 520
Updated: Jan 27 18:51:16.057
Version: 11, Priority: 2
Label Stack (Top -> Bottom): { 24000 16006 }
NHID: 0x0, Encap-ID: N/A, Path idx: 0, Backup path idx: 0, Weight: 0
MAC/Encaps: 14/22, MTU: 1500
Packets Switched: 5
Cisco dCloud
Interface Handle: 0x00000580, Local Label: 24007

Forwarding Class: 0, Weight: 0
Packets/Bytes Switched: 5/500
RP/0/0/CPU0:r1pe#
Wed Jan 27 19:15:04.389 UTC
------ ----------- ------------------ ------------ --------------- ------------
16002 Pop SR Pfx (idx 2) Gi0/0/0/0 10.1.12.2 0
16003 Pop SR Pfx (idx 3) Gi0/0/0/1 10.1.13.3 0
16004 16004 SR Pfx (idx 4) Gi0/0/0/0 10.1.12.2 0
16005 16005 SR Pfx (idx 5) Gi0/0/0/1 10.1.13.3 0
16006 16006 SR Pfx (idx 6) Gi0/0/0/0 10.1.12.2 0
16006 SR Pfx (idx 6) Gi0/0/0/1 10.1.13.3 0
24000 Pop SR Adj (idx 1) Gi0/0/0/0 10.1.12.2 0
24001 Pop SR Adj (idx 3) Gi0/0/0/0 10.1.12.2 0
24002 Pop SR Adj (idx 1) Gi0/0/0/1 10.1.13.3 0
24003 Pop SR Adj (idx 3) Gi0/0/0/1 10.1.13.3 0
24004 Pop No ID tt10 point2point 0
RP/0/0/CPU0:r1pe#
3. Enter the following commands to review the second path option and observe the changes with the previously used
commands.
RP/0/0/CPU0:r1pe#mpls traffic-eng switchover tunnel-te 10 path-option 20
Wed Jan 27 19:30:49.134 UTC
Wed Jan 27 19:30:52.324 UTC

Status:
path option 20, (Segment-Routing) type explicit r1-r3-r6 (Basis for Setup)
path option 10, (Segment-Routing) type explicit r1-r2-r4-r6
path option 30, (Segment-Routing) type explicit r1-r6
Config Parameters:
Path Selection:
Hop-limit: disabled
Cisco dCloud

Auto-bw: disabled
SNMP Index: 10
Binding SID: 24004
History:
Current LSP:
Reopt. LSP:
Last Failure:
LSP not signalled, identical to the [CURRENT] LSP
Date/Time: Wed Jan 27 19:29:19 UTC 2016 [00:01:33 ago]
Prior LSP:
Removal Trigger: reoptimization completed
Current LSP Info:
Path Info:
Cleaned LSP Info (Cleanup Timer Remaining 17 Seconds):

Outgoing Interface: none, Outgoing Label: no label
Path Info:

RP/0/0/CPU0:r1pe#
Wed Jan 27 19:32:35.897 UTC
------------- ----------- ------------ --------------- ------------
tt10 (SR) 16006 Gi0/0/0/1 10.1.13.3 0
Wed Jan 27 19:32:40.896 UTC
Cisco dCloud
------------- ----------- ------------ --------------- ------------

tt10 (SR) 16006 Gi0/0/0/1 10.1.13.3 0
Updated: Jan 27 19:30:49.914
Label Stack (Top -> Bottom): { 16006 }
Packets Switched: 0

RP/0/0/CPU0:r1pe#
NOTE: Optionally, using the same verification process, switch to the third path option to see the equal cost multipath used for the
tunnel.
Configure SR-TE Stitching
This procedure demonstrates how to configure SR-TE stitching. On R4, you must create an explicit SR-TE path from R4 to R6
through R5 SIDs 16005, 16006, and create an SR-TE tunnel with the defined path option and explicitly configured binding SID of
4000. On r1pe, you must create an additional explicit SR-TE path from R1 to R4 and further into the SR-TE tunnel, and add an
additional third path option to the existing SR-TE tunnel on R1 using the defined SR-TE path.
1. On r4p, configure the following commands:

explicit-path name r4-r5-r6
ipv4 unnumbered Loopback0
signalled-name r4-r6-tunnel
destination 6.6.6.6
binding-sid mpls label 4000
path-option 10 explicit name r4-r5-r6 segment-routing
2. On r1pe, configure the following commands:

explicit-path name r1-r4-tunnel40
path-option 40 explicit name r1-r4-tunnel40 segment-routing
Verify SR-TE Stitching
1. Enter the following commands to switch to the new path on R1 and observe the changes. Notice that the tunnel takes the new
path.
RP/0/0/CPU0:r1pe#mpls traffic-eng switchover tunnel-te 10 path-option 40
Cisco dCloud
Wed Jan 27 19:42:55.724 UTC

RP/0/0/CPU0:r1pe#ping 6.6.6.6
Wed Jan 27 19:43:12.513 UTC
!!!!!
RP/0/0/CPU0:r1pe#
Wed Jan 27 19:45:40.993 UTC
------------- ----------- ------------ --------------- ------------
tt10 (SR) 16004 Gi0/0/0/0 10.1.12.2 520
Updated: Jan 27 19:42:56.495
Packets Switched: 5

RP/0/0/CPU0:r1pe#
2. On r4p, enter the following command to verify that the traffic went into the configured tunnel by way of stitching with a binding
SID.
RP/0/0/CPU0:r4p#sh mpls traffic-eng tunnels segment-routing detail
Wed Jan 27 19:45:01.665 UTC
Status:
path option 10, (Segment-Routing) type explicit r4-r5-r6 (Basis for Setup)
Config Parameters:
Path Selection:
Hop-limit: disabled
AutoRoute: disabled LockDown: disabled Policy class: not set
Auto-bw: disabled
Cisco dCloud

SNMP Index: 10
Binding SID: 4000
History:
Current LSP:
Current LSP Info:
Path Info:

RP/0/0/CPU0:r4p#sh mpls forwarding tunnel detail
Wed Jan 27 19:45:07.805 UTC
------------- ----------- ------------ --------------- ------------
tt40 (SR) 16006 Gi0/0/0/2 10.1.45.5 520
Updated: Jan 27 19:42:24.736
Label Stack (Top -> Bottom): { 16006 }
Packets Switched: 5

RP/0/0/CPU0:r4p#
3. Enter the following commands to re-optimize and revert to the first path option on R1:
RP/0/0/CPU0:r1pe#mpls traffic-eng reoptimize
Wed Jan 27 19:45:01.665 UTC
RP/0/0/CPU0:r1pe#
Cisco dCloud
Scenario 3. Explore SR-TE with Path Control Delegation to a PCE

This scenario explores SR-TE working with the Path Computation Element (PCE). A PCE is an element, most likely residing on a
server, responsible for doing path computation based on the constraints provided and signaling that path to the Path Computation
Client (PCC, typically a router). PCE Protocol (PCEP) is the standard TCP-based protocol used between PCE and PCC for
communication.
Stateful PCE monitors all previously established LSPs and the available resources. Active stateful PCE can initiate LSP path setup
and maintain the responsibility of updating the LSP. Alternatively, a PCC can initiate the LSP itself and delegate the control of it to
the PCE.
In SR networks, an ingress node of an SR-TE LSP appends all outgoing packets with an SR header consisting of a list of SIDs.
This header has all necessary information to guide the packets from the ingress node to the egress node of the path. To support
SR-TE, PCEP protocol extends to support sending the necessary segment routing information (http://tools.ietf.org/html/draft-ietf-
pce-segment-routing-06).
This scenario demonstrates SR-TE with PCE-based architecture (RFC 4655) in a basic SDN setup.
There are three layers in the SDN architecture:
• Application layer
• Control plane layer
• Data plane layer
The application layer consists of SDN applications for network automation, flexibility, and programmability that communicate with
the control layer, represented by SDN controller. Applications may run on the controller hardware itself.
The control plane layer includes an SDN controller, which maintains a global view of the network. It takes requests through
northbound APIs from the application layer and controls and monitors network devices via standard southbound protocols.
The data plane layer includes the network devices.
There is no actual SDN application to do intelligent path computation as PCE in this demonstration environment. Such an
application would typically interact with the controller using northbound APIs, and this scenario demonstrates the use of those with
basic scripts. The scripts use northbound RESTCONF APIs of the ODL SDN controller. The southbound protocol between the ODL
and the network is PCEP with the aforementioned SR-TE extensions.
With REST, you can retrieve information from the controller by sending HTTP GET requests and instruct the controller to perform
some action using HTTP POST, PUT, or DELETE requests.
The scripts are based on an open source REST command line client (newman), installed on the ODL server.
The client is pre-configured with collections of ODL’s northbound RESTCONF API calls for SR-TE PCEP to use in the lab. The
collections and accompanying data are described in JSON (JavaScript Object Notation) format.
Basic newman calls are wrapped around with few lines of simple UNIX shell scripts to make the process faster and the results
easier to read, for example:
newman -c collection-file.json -d data-file.json -O output-file.txt
This scenario demonstrates how to add a stateful PCE for SR-TE, based on the ODL SDN controller by doing the following:
• Establish a PCEP session between the R1 router and the stateful PCE on the ODL controller.
Cisco dCloud
• Delegate control over existing paths configured on the R1 router to the PCE.
• Update the path from the PCE.
Steps
1. On r1pe, configure the following commands to set up a PCEP session:
mpls traffic-eng
pce
peer ipv4 10.10.10.10
!
segment-routing
stateful-client
2. Enter the following commands to verify the state of the PCEP session on the router. Notice that the PCEP session between
the router and the ODL is operational and that the session has update and SR capabilities.
RP/0/0/CPU0:r1pe#sh mpls traffic-eng pce peer
Wed Jan 27 19:58:12.551 UTC
Address Precedence State Learned From
--------------- ------------ ------------ --------------------
10.10.10.10 255 Up Static config
RP/0/0/CPU0:r1pe#sh mpls traffic-eng pce peer all
Wed Jan 27 19:58:26.091 UTC
PCE Address 10.10.10.10

State Up
PCEP has been up for: 00:00:42
Precedence 255
Learned through:
Static Config
Sending KA every 30 s
Time out peer if no KA received for 120 s
Tolerance: Minimum KA 10 s
Stateful
Update capability
Segment Routing capability
KA messages rxed 2 txed 2

PCEReq messages rxed 0, txed 0
PCERep messages rxed 0, txed 0
PCEErr messages rxed 0, txed 0
Last error received: None
Last error sent: None
PCE OPEN messages: rxed 1, txed 1
PCERpt messages rxed 0, txed 1
PCEUpd messages rxed 0, txed 0
PCEInit messages rxed 0, txed 0
PCEP session ID: local 0, remote 0
Average reply time from peer: 0 ms
Cisco dCloud
Minimum reply time from peer: 0 ms

Maximum reply time from peer: 0 ms
0 requests timed out with this peer
RP/0/0/CPU0:r1pe#
3. From the ODL server, enter the following command to request the PCEP topology from the ODL by using the northbound
REST API interface of the controller. Notice that the script sends an HTTP GET request to the corresponding REST API URL
with certain headers and receives a response with JSON-formatted topology information in the response body.
ubuntu@odl-server:~$ ./get-pcep-topology.sh
-------------------------------------------------------------------------------------------
200 515ms Get PCE-P Topology [GET] http://localhost:8181/restconf/operational/network-topology:network-
topology/topology/pcep-topology
------------------------------------------------------------
Request headers:
{
"accept": "application/json",
"content-type": "application/xml",
"authorization": "Basic YWRtaW46YWRtaW4=",
"host": "localhost:8181",
"accept-encoding": "gzip"
}
Request data:
{}
------------------------------------------------------------
Response headers:
{
"content-type": "application/json",
"content-encoding": "gzip",
"vary": "Accept-Encoding, User-Agent",
"connection": "close",
"server": "Jetty(8.1.15.v20140411)"
}
Response body:
topology:
[
{
topology-id: pcep-topology
topology-types:
{
network-topology-pcep:topology-pcep: {}
}
node:
[
{
node-id: pcc://1.1.1.1
network-topology-pcep:path-computation-client:
{
state-sync: synchronized
ip-address: 1.1.1.1
stateful-tlv:
{
odl-pcep-ietf-stateful07:stateful:
{
Cisco dCloud
lsp-update-capability: true
}
}
}
}
]
}
]
ubuntu@odl-server:~$
The response body has been slightly reformatted from JSON to HJSON by the script, for better readability.
In the output, notice the following:
• The 200 (OK) HTTP status code indicates that the request succeeded.
• In the request headers notice:
o Requested data in JSON format.
o Basic HTTP authorization with login/password set to admin/admin, which is encoded in the output.
• In the response headers, notice the response data is in JSON format as well.
• In the response data, notice the PCEP topology described in JSON format:
o PCC is R1, identified by its loopback address 1.1.1.1
o LSP update capability is supported
4. Configure the following commands on R1 to delegate the path control over the tunnel on R1 to the configured PCE (ODL):
pce
delegation
NOTE: According to http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-13:
“...If during Capability advertisement both the PCE and the PCC have indicated that they support LSP Update, then the PCC may
choose to grant the PCE a temporary right to update (a subset of) LSP attributes on one or more LSPs. This is called 'LSP
Delegation', and it may be performed at any time after the Initialization phase, including during the State Synchronization phase. A
PCE MAY return an LSP delegation at any time if it no longer wishes to update the LSP's state. A PCC may revoke an LSP
delegation at any time…”
Delegation, revocation, and return are done individually for each LSP by using a delegated bit set during PCEP message
exchanges.
5. Enter the following command to verify the state of the PCEP session on R1 router after the delegation:
NOTE: The LSP ID/instance values you receive may differ from the example output.
RP/0/0/CPU0:r1pe#sh mpls traffic-eng tunnels 10 detail
Thu Jan 28 00:36:01.430 UTC
Cisco dCloud
Status:
path option 10, (Segment-Routing) type explicit (autopcc_te10) (Basis for Setup)
Config Parameters:
Bandwidth: 0 kbps (CT0) Priority: 7 7 Affinity: 0x0/0x0
Path Selection:
Hop-limit: disabled
Auto-bw: disabled
PCE Delegation:
Symbolic name: r1-r6-tunnel
PCEP ID: 11
Delegated to: 10.10.10.10
SNMP Index: 10
Binding SID: 24004
History:
Current LSP:
Uptime: 00:01:07 (since Thu Jan 28 00:34:54 UTC 2016)
Reopt. LSP:
Last Failure:
Prior LSP:
Current LSP Info:
Instance: 11, Signaling Area: PCE controlled
Path Info:
Segment-Routing Path Info (PCE controlled)
Segment0[Node]: 2.2.2.2, Label: 16002
Cisco dCloud

RP/0/0/CPU0:r1pe#
6. Enter the following command to verify the PCEP topology from the ODL controller again to see the changes. Notice that ODL
is aware of the tunnel on R1 and its properties, including the current path.
-------------------------------------------------------------------------------------------
------------------------------------------------------------
Request headers:
{
}
Request data:
{}
------------------------------------------------------------
Response headers:
{
"server": "Jetty(8.1.15.v20140411)"
}
Response body:
topology:
[
{
topology-types:
{
}
node:
[
{
{
reported-lsp:
[
{
name: r1-r6-tunnel
path:
[
{
lsp-id: 11
lspa:
{
processing-rule: false
Cisco dCloud
setup-priority: 7
local-protection-desired: false
tlvs: {}
hold-priority: 7
ignore: false
include-any: 0
include-all: 0
exclude-any: 0
}
odl-pcep-ietf-stateful07:lsp:
{
remove: false
ignore: false
sync: false
odl-pcep-ietf-initiated00:create: false
tlvs:
{
lsp-identifiers:
{
ipv4:
{
ipv4-extended-tunnel-id: 6.6.6.6
ipv4-tunnel-sender-address: 1.1.1.1
ipv4-tunnel-endpoint-address: 6.6.6.6
}
tunnel-id: 10
lsp-id: 11
}
path-binding:
{
binding-value: AAXcQAA=
binding-type: 0
}
symbolic-path-name:
{
path-name: cjEtcjYtdHVubmVs
}
}
administrative: true
delegate: true
operational: up
plsp-id: 11
}
ero:
{
ignore: false
subobject:
[
{
odl-pcep-segment-routing:ip-address: 2.2.2.2
odl-pcep-segment-routing:m-flag: true
odl-pcep-segment-routing:sid-type: ipv4-node-id
odl-pcep-segment-routing:sid: 16002
odl-pcep-segment-routing:c-flag: false
Cisco dCloud
loose: false
}
{
loose: false
}
{
loose: false
}
]
}
bandwidth:
{
ignore: false
bandwidth: AAAAAA==
}
}
]
}
]
ip-address: 1.1.1.1
stateful-tlv:
{
{
}
}
}
}
]
}
]
7. Enter the following command to update the LSP using another ODL northbound RESTCONF API:
ubuntu@odl-server:~$ ./update-lsp.sh
-------------------------------------------------------------------------------------------
200 459ms Update LSP [POST] http://localhost:8181/restconf/operations/network-topology-pcep:update-lsp
------------------------------------------------------------
Request headers:
{
"accept-encoding": "gzip",
"content-length": 948
Cisco dCloud
}
Request data:
{ "input" :
{
"node" : "pcc://1.1.1.1",
"name" : "r1-r6-tunnel",
"arguments" : {
"lsp" : {
"delegate" : "true",
"administrative" : "true"
},
"ero" : {
"subobject" : [
{
"loose" : "false",
"sid-type" : "ipv4-node-id",
"m-flag" : "true",
"sid" : "16003",
"ip-address" : "3.3.3.3"
},
{
"loose" : "false",
"m-flag" : "true",
"sid" : "16006",
"ip-address" : "6.6.6.6"
}
]
}
},
"network-topology-ref" : "/network-topology:network-topology/network-topology:topology[network-
topology:topology-id=\\"pcep-topology\\"]"
}
}
------------------------------------------------------------
Response headers:
{
"content-type": "application/yang.operation+json",
"server": "Jetty(8.1.15.v20140411)"
}
Response body:
{"output":{}}
8. Enter the following command to verify the updated LSP on R1:

Thu Jan 28 14:06:43.357 UTC

Status:
Cisco dCloud

Config Parameters:
Bandwidth: 0 kbps (CT0) Priority: 7 7 Affinity: 0x0/0x0
Path Selection:
Hop-limit: disabled
Auto-bw: disabled
PCE Delegation:
PCEP ID: 11
SNMP Index: 10
Binding SID: 24004
History:
Current LSP:
Reopt. LSP:
Last Failure:
Prior LSP:
Current LSP Info:
Path Info:

RP/0/0/CPU0:r1pe#
9. Enter the following command to verify the PCEP topology from the ODL controller again.
Cisco dCloud
-------------------------------------------------------------------------------------------
------------------------------------------------------------
Request headers:
{
}
Request data:
{}
------------------------------------------------------------
Response headers:
{
"server": "Jetty(8.1.15.v20140411)"
}
Response body:
topology:
[
{
topology-types:
{
}
node:
[
{
{
reported-lsp:
[
{
name: r1-r6-tunnel
path:
[
{
lsp-id: 12
lspa:
{
setup-priority: 7
tlvs: {}
hold-priority: 7
ignore: false
include-any: 0
Cisco dCloud
include-all: 0
exclude-any: 0
}
{
remove: false
ignore: false
sync: false
tlvs:
{
lsp-identifiers:
{
ipv4:
{
}
tunnel-id: 10
lsp-id: 12
}
path-binding:
{
binding-type: 0
}
symbolic-path-name:
{
}
}
delegate: true
operational: up
plsp-id: 11
}
ero:
{
ignore: false
subobject:
[
{
loose: false
}
{
Cisco dCloud
loose: false
}
]
}
bandwidth:
{
ignore: false
bandwidth: AAAAAA==
}
}
]
}
]
ip-address: 1.1.1.1
stateful-tlv:
{
{
}
}
}
}
]
}
]
NOTE: Optionally, test your SDN skills by editing the RESTCONF API request parameters in update-lsp-restconf.json and repeat
the steps to call the update-lsp.sh script.
Cisco dCloud
Scenario 4. Explore SR-TE with PCE-Initiated Paths

This scenario explores PCE-initiated paths. This scenario describes how to adjust the PCEP session to allow ODL to initiate SR-
TE paths and we add and delete SR-TE paths by using ODL’s northbound RESTCONF interface.
For more information about PCEP extensions for PCE-initiated LSP setup in a stateful PCE model, refer to
https://tools.ietf.org/html/draft-ietf-pce-pce-initiated-lsp-05. PCE and PCC indicate their ability to support PCE-provisioned dynamic
LSPs during the PCEP Initialization phase by advertising LSP Initiation capability.
Steps
ipv4 unnumbered mpls traffic-eng Loopback0
mpls traffic-eng
pce
stateful-client
instantiation
auto-tunnel pcc tunnel-id min 100 max 200
2. Enter the following command to verify the state of the PCEP session. Notice that the PCEP session between the router and
the ODL is operational and that the session has update, instantiation, and SR capabilities.
RP/0/0/CPU0:r1pe#sh mpls traffic-eng pce peer all
Wed Jan 27 19:58:26.091 UTC
PCE Address 10.10.10.10

State Up
PCEP has been up for: 00:00:13
Precedence 255
Learned through:
Static Config
Sending KA every 30 s
Time out peer if no KA received for 120 s
Tolerance: Minimum KA 10 s
Stateful
Update capability
Instantiation capability
Segment Routing capability
KA messages rxed 2348 txed 2332

PCEReq messages rxed 0, txed 0
PCERep messages rxed 0, txed 0
PCEErr messages rxed 0, txed 0
Last error received: None
Last error sent: None
PCE OPEN messages: rxed 3, txed 3
PCERpt messages rxed 0, txed 13
PCEUpd messages rxed 1, txed 0
Cisco dCloud
PCEInit messages rxed 0, txed 0

PCEP session ID: local 2, remote 0
Average reply time from peer: 0 ms

Minimum reply time from peer: 0 ms
Maximum reply time from peer: 0 ms
0 requests timed out with this peer
RP/0/0/CPU0:r1pe#
3. Enter the following command to request the PCEP topology from the ODL. Notice the instantiation capability reflected there as
well.
-------------------------------------------------------------------------------------------
------------------------------------------------------------
Request headers:
{
}
Request data:
{}
------------------------------------------------------------
Response headers:
{
"server": "Jetty(8.1.15.v20140411)"
}
Response body:
topology:
[
{
topology-types:
{
}
node:
[
{
{
reported-lsp:
[
{
name: r1-r6-tunnel
path:
Cisco dCloud
[
{
lsp-id: 12
lspa:
{
setup-priority: 7
tlvs: {}
hold-priority: 7
ignore: false
include-any: 0
include-all: 0
exclude-any: 0
}
{
remove: false
ignore: false
sync: true
tlvs:
{
lsp-identifiers:
{
ipv4:
{
}
tunnel-id: 10
lsp-id: 12
}
path-binding:
{
binding-type: 0
}
symbolic-path-name:
{
}
}
delegate: true
operational: up
plsp-id: 11
}
ero:
{
ignore: false
subobject:
[
Cisco dCloud
{
loose: false
}
{
loose: false
}
]
}
bandwidth:
{
ignore: false
bandwidth: AAAAAA==
}
}
]
}
]
ip-address: 1.1.1.1
stateful-tlv:
{
{
odl-pcep-ietf-initiated00:initiation: true
}
}
}
}
]
}
]
NOTE: To enhance readability, the response body has been reformatted from JSON to HJSON by the script.
4. Enter the following command to add the LSP using another ODL’s northbound RESTCONF API with another script.
ubuntu@odl-server:~$ ./add-lsp.sh
-------------------------------------------------------------------------------------------
200 872ms Add LSP [POST] http://localhost:8181/restconf/operations/network-topology-pcep:add-lsp
------------------------------------------------------------
Request headers:
Cisco dCloud
{
}
Request data:
{ "input" :
{
"node" : "pcc://1.1.1.1",
"arguments" : {
"lsp" : {
"delegate" : "true",
"administrative" : "true"
},
"endpoints-obj" : {
"ipv4" : {
"source-ipv4-address" : "1.1.1.1",
"destination-ipv4-address" : "5.5.5.5"
}
},
"ero" : {
"subobject" : [
{
"loose" : "false",
"m-flag" : "true",
"sid" : "16004",
"ip-address" : "4.4.4.4"
},
{
"loose" : "false",
"m-flag" : "true",
"sid" : "16005",
"ip-address" : "5.5.5.5"
}
]
}
},
}
}
------------------------------------------------------------
Response headers:
{
"server": "Jetty(8.1.15.v20140411)"}
Response body:
{"output":{}}
Cisco dCloud
5. Enter the following commands to verify the added LSP:

RP/0/0/CPU0:r1pe#sh mpls traffic-eng tunnels all brief
Thu Jan 28 16:06:22.566 UTC

tunnel-te10 6.6.6.6 up up
>tunnel-te100 5.5.5.5 up up
RP/0/0/CPU0:r1pe#
Thu Jan 28 16:06:52.424 UTC
Name: tunnel-te100 Destination: 5.5.5.5 Ifhandle:0x680 (auto-tunnel pcc)

Status:
Creation Time: Thu Jan 28 16:01:45 2016 (00:05:07 ago)
Config Parameters:
Path Selection:
Hop-limit: disabled
Auto-bw: disabled
Auto PCC:
PCEP ID: 101
Created by: 10.10.10.10
SNMP Index: 11
Binding SID: 24006
History:
Tunnel has been up for: 00:05:06 (since Thu Jan 28 16:01:46 UTC 2016)
Current LSP:
Current LSP Info:
Cisco dCloud

Path Info:

RP/0/0/CPU0:r1pe#
6. Enter the following command to request the PCEP topology from the ODL:
-------------------------------------------------------------------------------------------
------------------------------------------------------------
Request headers:
{
}
Request data:
{}
------------------------------------------------------------
Response headers:
{
"server": "Jetty(8.1.15.v20140411)"
}
Response body:
topology:
[
{
topology-types:
{
}
node:
[
{
{
reported-lsp:
[
Cisco dCloud
{
name: r1-r6-tunnel
path:
[
{
lsp-id: 12
lspa:
{
setup-priority: 7
tlvs: {}
hold-priority: 7
ignore: false
include-any: 0
include-all: 0
exclude-any: 0
}
{
remove: false
ignore: false
sync: true
tlvs:
{
lsp-identifiers:
{
ipv4:
{
}
tunnel-id: 10
lsp-id: 12
}
path-binding:
{
binding-type: 0
}
symbolic-path-name:
{
}
}
delegate: true
operational: up
plsp-id: 11
}
ero:
{
Cisco dCloud
ignore: false
subobject:
[
{
loose: false
}
{
loose: false
}
]
}
bandwidth:
{
ignore: false
bandwidth: AAAAAA==
}
}
]
}
{
name: r1-r5-tunnel
path:
[
{
lsp-id: 2
lspa:
{
setup-priority: 7
tlvs: {}
hold-priority: 7
ignore: false
include-any: 0
include-all: 0
exclude-any: 0
}
{
remove: false
ignore: false
sync: false
Cisco dCloud
odl-pcep-ietf-initiated00:create: true
tlvs:
{
lsp-identifiers:
{
ipv4:
{
}
tunnel-id: 100
lsp-id: 2
}
path-binding:
{
binding-value: AAXcYAA=
binding-type: 0
}
symbolic-path-name:
{
path-name: cjEtcjUtdHVubmVs
}
}
delegate: true
operational: up
plsp-id: 101
}
ero:
{
ignore: false
subobject:
[
{
loose: false
}
{
loose: false
}
]
}
bandwidth:
{
Cisco dCloud
ignore: false
bandwidth: AAAAAA==
}
}
]
}
]
ip-address: 1.1.1.1
stateful-tlv:
{
{
odl-pcep-ietf-initiated00:initiation: true
}
}
}
}
]
}
]
NOTE: Optionally, test your SDN skills by editing the RESTCONF API request parameters in add-lsp-restconf.json to create
another tunnel and repeat the steps to call the add-lsp.sh script.
7. Enter the following command to remove the LSP:

ubuntu@odl-server:~$ ./remove-lsp.sh
-------------------------------------------------------------------------------------------
200 444ms remove LSP [POST] http://localhost:8181/restconf/operations/network-topology-pcep:remove-lsp
------------------------------------------------------------
Request headers:
{
}
Request data:
{ "input" :
{
"node" : "pcc://1.1.1.1",
}
}
------------------------------------------------------------
Response headers:
{
Cisco dCloud
"server": "Jetty(8.1.15.v20140411)"
}
Response body:
{"output":{}}
8. Now, as before, verify the outcome following the methods mentioned in steps 5 and 6.
Cisco dCloud
Scenario 5. Explore BGP SR-TE Dynamic

This scenario explores BGP SR-TE dynamic. BGP SR-TE dynamic is a mechanism that creates SR-TE policies dynamically based
on BGP attributes. BGP SR-TE dynamic enables you to:
• Configure SR-TE attribute sets locally to define certain TE parameters.
• Map BGP prefixes to SR-TE attribute-sets with RPL (based on BGP communities, for example).
• Dynamically create SR-TE tunnels towards next hops of the BGP prefixes, using the parameters in the SR-TE attribute-sets
associated with the BGP prefixes.
• Steer traffic into the SR-TE tunnel by recursion via local binding SID.
Assume the links R2-R4 and R5-R6 are high latency, and you want to avoid them for traffic from R1 towards certain prefixes. In
this example, high-latency links are marked with a special HIGH-LATENCY TE attribute.
This scenario configures BGP between R1 and R6. R6 sends two prefixes to R1 via BGP: 66.66.66.66/32 and 77.77.77.77/32. R6
marks one of the prefixes with BGP community 100:100 to signal that the traffic towards that prefix must avoid high latency links.
R1 creates two TE attribute sets locally:
• ATTR-SR-ANY (for generic SR TE tunnels)
• ATTR-SR-LOW-LATENCY (for SR TE tunnels, which have to avoid links with HIGH-LANTENCY attribute)
R1 map BGP prefixes received from R6 to one of two TE attributes, based on the presence of BGP community 100:100.
SR TE point-to-point auto-tunnels towards BGP next hops are created dynamically on R1, using the parameters in the TE attribute
sets.
Steps
ipv4 unnumbered mpls traffic-eng Loopback0
no interface tunnel-te10
mpls traffic-eng
auto-tunnel p2p
tunnel-id min 10000 max 11000
!
affinity-map HIGH-LATENCY bit-position 0
!
attribute-set p2p-te ATTR-SR-ANY
path-selection
segment-routing adjacency unprotected
!
!
attribute-set p2p-te ATTR-SR-LOW-LATENCY
path-selection
segment-routing adjacency unprotected
Cisco dCloud
!
affinity exclude HIGH-LATENCY
route-policy BGP-SRTE
if community matches-any (100:100) then
set mpls traffic-eng attributeset ATTR-SR-LOW-LATENCY
else
set mpls traffic-eng attributeset ATTR-SR-ANY
endif
end-policy
!
router bgp 100
bgp router-id 1.1.1.1
!
neighbor 6.6.6.6
remote-as 100
update-source Loopback0
route-policy BGP-SRTE in

route-policy rpl-low-latency
set community (100:100) additive
end-policy
router bgp 100

bgp router-id 6.6.6.6
network 66.66.66.66/32 route-policy rpl-low-latency
network 77.77.77.77/32
!
neighbor 1.1.1.1
remote-as 100
update-source Loopback0
3. On r2pe, configure the following commands to mark high latency links with a special HIGH-LATENCY TE attribute. Repeat this
step on r4pe, r5pe, and r6pe.
mpls traffic-eng
interface GigabitEthernet0/0/0/1
attribute-names HIGH-LATENCY
!
affinity-map HIGH-LATENCY bit-position 0
4. Enter the following commands to verify the state of the r1pe. Notice the two prefixes received by R1 from R6 via BGP. One of
the prefixes, 66.66.66.66/32, has community 100:100, and it’s mapped to TE tunnel attribute set ATTR-SR-LOW-LATENCY,
while the other prefixes are mapped to TE tunnel attribute set ATTR-SR-ANY.
RP/0/0/CPU0:r1pe#sh bgp ipv4 unicast
Wed Jun 8 20:40:13.090 UTC
BGP router identifier 1.1.1.1, local AS number 100
BGP generic scan interval 60 secs
Non-stop routing is enabled
Cisco dCloud
BGP table state: Active

Table ID: 0xe0000000 RD version: 10
BGP main routing table version 10
BGP NSR Initial initsync version 2 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs
Status codes: s suppressed, d damped, h history, * valid, > best

i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*>i66.66.66.66/32 6.6.6.6 T:ATTR-SR-LOW-LATENCY
0 100 0 i
*>i77.77.77.77/32 6.6.6.6 T:ATTR-SR-ANY
0 100 0 i
Processed 2 prefixes, 2 paths

RP/0/0/CPU0:r1pe#
RP/0/0/CPU0:r1pe#sh bgp ipv4 unicast 66.66.66.66/32
Wed Jun 8 20:40:57.996 UTC
BGP routing table entry for 66.66.66.66/32
Versions:
Process bRIB/RIB SendTblVer
Speaker 9 9
Last Modified: Jun 8 20:11:18.850 for 00:29:39
Paths: (1 available, best #1)
Not advertised to any peer
Path #1: Received by speaker 0
Local
6.6.6.6 T:ATTR-SR-LOW-LATENCY (metric 300) from 6.6.6.6 (6.6.6.6)
Origin IGP, metric 0, localpref 100, valid, internal, best, group-best
Received Path ID 0, Local Path ID 1, version 9
Community: 100:100
TE tunnel attribute-set ATTR-SR-LOW-LATENCY, up, registered, binding-label 24003, if-handle 0x00000d80
RP/0/0/CPU0:r1pe#
RP/0/0/CPU0:r1pe#sh bgp ipv4 unicast 77.77.77.77/32
Wed Jun 8 20:41:37.634 UTC
BGP routing table entry for 77.77.77.77/32
Versions:
Process bRIB/RIB SendTblVer
Speaker 10 10
Last Modified: Jun 8 20:11:18.850 for 00:30:19
Paths: (1 available, best #1)
Path #1: Received by speaker 0
Local
6.6.6.6 T:ATTR-SR-ANY (metric 300) from 6.6.6.6 (6.6.6.6)
Origin IGP, metric 0, localpref 100, valid, internal, best, group-best
Received Path ID 0, Local Path ID 1, version 10
TE tunnel attribute-set ATTR-SR-ANY, up, registered, binding-label 24000, if-handle 0x00000c80
RP/0/0/CPU0:r1pe#
Cisco dCloud
5. Enter the following commands to review the SR-TE tunnels on r1pe. Notice the two auto-tunnels for BGP set from R1 towards
R6 with different attribute sets. The tunnel with the attribute set ATTR-SR-LOW-LATENCY takes the R1-R3-R5-R4-R6 path,
and avoids the R2-R4 and R5-R6 links marked with HIGH-LATENCY attribute.
RP/0/0/CPU0:r1pe#sh mpls traffic-eng tunnels segment-routing brief
Wed Jun 8 20:35:14.560 UTC

^tunnel-te10004 6.6.6.6 up up
^tunnel-te10005 6.6.6.6 up up
^ = automatically created P2P/P2MP tunnel
Wed Jun 8 20:35:29.919 UTC
Name: tunnel-te10004 Destination: 6.6.6.6 Ifhandle:0xc80 (auto-tunnel for BGP default)

Signalled-Name: auto_r1pe_t10004
Status:
path option 10, (Segment-Routing) type dynamic (Basis for Setup, path weight 300)
Creation Time: Wed Jun 8 20:03:42 2016 (00:31:48 ago)
Config Parameters:
Path Selection:
Protection: Unprotected Adjacency
Hop-limit: disabled
Auto-bw: disabled
Attribute-set: ATTR-SR-ANY (type p2p-te)
SNMP Index: 16
Binding SID: 24000
History:
Tunnel has been up for: 00:24:14 (since Wed Jun 08 20:11:16 UTC 2016)
Current LSP:
Uptime: 00:24:14 (since Wed Jun 08 20:11:16 UTC 2016)
Reopt. LSP:
Last Failure:
Date/Time: Wed Jun 08 20:33:03 UTC 2016 [00:02:27 ago]
Cisco dCloud
Current LSP Info:

Path Info:
Segment0[Link]: 10.1.13.1 - 10.1.13.3, Label: 24002
Name: tunnel-te10005 Destination: 6.6.6.6 Ifhandle:0xd80 (auto-tunnel for BGP default)

Signalled-Name: auto_r1pe_t10005
Status:
path option 10, (Segment-Routing) type dynamic (Basis for Setup, path weight 400)
Creation Time: Wed Jun 8 20:03:42 2016 (00:31:48 ago)
Config Parameters:
Bandwidth: 0 kbps (CT0) Priority: 7 7
Number of affinity constraints: 1
Exclude bit map : 0x1
Exclude ext bit map :
Length: 256 bits
Value : 0x::1
Exclude affinity name : HIGH-LATENCY(0)

Path Selection:
Protection: Unprotected Adjacency
Hop-limit: disabled
Auto-bw: disabled
Attribute-set: ATTR-SR-LOW-LATENCY (type p2p-te)
SNMP Index: 17
Binding SID: 24003
History:
Tunnel has been up for: 00:24:14 (since Wed Jun 08 20:11:16 UTC 2016)
Current LSP:
Prior LSP:
Cisco dCloud

Current LSP Info:
Path Info:

RP/0/0/CPU0:r1pe#
6. Enter the following command to verify the forwarding. Notice that pings towards the BGP prefixes learned from R6 went into
both tunnels. In the FIB, notice that 66.66.66.66/32 recurses via local label 24003, which is a binding SID for SR-TE tunnel
10005 (which avoids high latency links). The other prefix recurses via local label 24000, which is a Binding SID for the other
SR-TE tunnel 10004.
RP/0/0/CPU0:r1pe#ping 77.77.77.77
Wed Jun 8 20:36:00.337 UTC
!!!!!
RP/0/0/CPU0:r1pe#ping 66.66.66.66
Wed Jun 8 20:36:08.456 UTC
!!!!!
Wed Jun 8 20:36:20.635 UTC
------------- ----------- ------------ --------------- ------------
tt10004 (SR) 24006 Gi0/0/0/1 10.1.13.3 520
tt10005 (SR) 24006 Gi0/0/0/1 10.1.13.3 520
Wed Jun 8 20:36:50.043 UTC
------------- ----------- ------------ --------------- ------------
tt10004 (SR) 24006 Gi0/0/0/1 10.1.13.3 520
Updated: Jun 8 20:11:16.078
Packets Switched: 5
Cisco dCloud
Interface Handle: 0x00000c80, Local Label: 24004

tt10005 (SR) 24006 Gi0/0/0/1 10.1.13.3 520
Updated: Jun 8 20:34:42.512
Label Stack (Top -> Bottom): { 24006 24012 24003 }
Packets Switched: 5
Interface Handle: 0x00000d80, Local Label: 24006

RP/0/0/CPU0:r1pe#
RP/0/0/CPU0:r1pe#sh cef 66.66.66.66/32 detail
Wed Jun 8 20:43:46.645 UTC
66.66.66.66/32, version 387, internal 0x5000001 0x0 (ptr 0xa13f2274) [1], 0x0 (0x0), 0x0 (0x0)
Updated Jun 8 20:11:19.119
gateway array (0xa133c23c) reference count 1, flags 0x4010, source rib (7), 0 backups
[1 type 3 flags 0x68501 (0xa13896e0) ext 0x210 (0xa14af280)]
LW-LDI[type=0, refc=0, ptr=0x0, sh-ldi=0x0]
gateway array update type-time 1 Jun 8 20:11:19.119
LDI Update time Jun 8 20:11:19.119
via local-label 24003, 2 dependencies, recursive [flags 0x6000]
path-idx 0 NHID 0x0 [0xa15174f4 0x0]
recursion-via-label
next hop via 24003/1/21
Load distribution: 0 (refcount 1)
Hash OK Interface Address

0 Y tunnel-te10005 point2point
RP/0/0/CPU0:r1pe#
RP/0/0/CPU0:r1pe#sh cef 77.77.77.77/32 detail
Wed Jun 8 20:44:24.252 UTC
77.77.77.77/32, version 388, internal 0x5000001 0x0 (ptr 0xa13f2374) [1], 0x0 (0x0), 0x0 (0x0)
Updated Jun 8 20:11:19.118
gateway array (0xa133c2b8) reference count 1, flags 0x4010, source rib (7), 0 backups
[1 type 3 flags 0x68501 (0xa138971c) ext 0x210 (0xa14af2a8)]
LW-LDI[type=0, refc=0, ptr=0x0, sh-ldi=0x0]
gateway array update type-time 1 Jun 8 20:11:19.118
LDI Update time Jun 8 20:11:19.118
via local-label 24000, 2 dependencies, recursive [flags 0x6000]
path-idx 0 NHID 0x0 [0xa1517bf4 0x0]
recursion-via-label
next hop via 24000/1/21
Load distribution: 0 (refcount 1)
Hash OK Interface Address
Cisco dCloud
0 Y tunnel-te10004 point2point
RP/0/0/CPU0:r1pe#
Cisco dCloud
Appendix A. References
For more information on SR technology, refer to http://www.segment-routing.net/

Segment Routing Traffic Eng v1

Uploaded by

Copyright:

Available Formats

You might also like

Segment Routing Traffic Eng v1

Uploaded by

Document Information

Original Title

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

Segment Routing Traffic Eng v1

Uploaded by

Copyright:

Available Formats

Cisco dCloud

Segment Routing Traffic Engineering Lab v1

About This Lab

• About This Lab

• About This Solution

• Scenario 1: Configure Segment Routing Traffic Engineering

• Scenario 2: Configure SR-TE Paths

• Scenario 3: Explore SR-TE with Path Control Delegation to a PCE

• Scenario 4: Explore SR-TE with PCE-Initiated Paths

• Scenario 5: Explore BGP SR-TE Dynamic

● Laptop ● Cisco AnyConnect®

About This Solution

Figure 1. dCloud Topology

Figure 2. Logical Topology

 Directly connected interfaces but no carrier detection

G0/0/0/2 G0/0/0/2 G0/0/0/1

R2p, R3p, R4p, R5p – provider core (P) routers

R1pe, R6pe – provider edge (PE) routers

Table 2. Preconfigured User Information

Nodes Username Password

Routers cisco cisco

OpenDaylight ubuntu ubuntu

PREPARATION IS KEY TO A SUCCESSFUL PRESENTATION.

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

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

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

4. Click the Launch Simulation icon to start the simulation.

Figure 3. Launch Simulation

5. Wait for all nodes to become ACTIVE.

Figure 4. Telnet to Console Ports

Scenario 1. Configure Segment Routing Traffic Engineering

• Enable IS-IS wide metric.

• Advertise prefix (node) segment ID (SID) for Loopback0 interfaces.

Perform Initial Configuration

1. Configure the following commands on all routers:

router isis main

IS-IS main Level-2 adjacencies:

Neighbor IPv4 Address: 10.1.23.3*

Total adjacency count: 3

IS-IS main Level-1 adjacencies:

Total adjacency count: 2

IS-IS main (Level-2) Link State Database

Reservable Global pool BW: 0 kbits/sec

Total Level-2 LSP count: 1 Local Level-2 LSP count: 0

o The router has segment routing data plane capability.

o It has a globally significant (L:0) index (V:0) value of 1.

Routing entry for 6.6.6.6/32

IS-IS main IPv4 Unicast routes

Codes: L1 - level 1, L2 - level 2, ia - interarea (leaked into level 1)

Maximum parallel path count: 8

L2 10.1.56.0/24 [300/115] low priority

Mon Jan 25 22:26:31.604 UTC

SRGB Size: 8000

Link[0]:Point-to-Point, Nbr IGP Id:0020.0200.2002.00, Nbr Node Id:8, gen:4850

Link[1]:Point-to-Point, Nbr IGP Id:0030.0300.3003.00, Nbr Node Id:9, gen:4851

Verify Data Plane Verification

Label Label or ID Interface Switched

Scenario 2. Configure SR-TE Paths