LTRARC-2002 Introduction To IOS-XR Lab Guide: Speakers: Brad Edgeworth Ramiro Garza Rios Rajesh Patki

LTRARC-2002
Introduction to IOS-XR Lab Guide
Speakers:
Brad Edgeworth
Ramiro Garza Rios
Rajesh Patki
1|Page
LTRARC-2002 Introduction to IOS XR Lab Guide

Disclaimer
This training document is to familiarize with IOS-XR. Although the lab design and configuration examples could be used as a
reference, it’s not a real design, thus not all recommended features are used, or enabled optimally. For the design related
questions please contact your representative at Cisco, or a Cisco partner.
2|Page
LTRARC-2002 Introduction to IOS XR Lab Guide

Disclaimer ............................................................................................................................................. 2
Topology: .............................................................................................................................................. 4
Accessing the Lab................................................................................................................................... 5
Basic Configuration commands: ............................................................................................................. 7
Static Routes ........................................................................................................................................16
Open Shortest Path First (OSPF) ............................................................................................................19
BGP Configuration ................................................................................................................................25
IBGP Peering ....................................................................................................................................................... 25
Neighbor Groups................................................................................................................................................. 29
EBGP Peering ...................................................................................................................................................... 32
Basic Route Policy Language .................................................................................................................42
Blocking based off Prefixes ................................................................................................................................. 42
Blocking based off AS-PATH ................................................................................................................................ 53
MPLS Configuration ..............................................................................................................................62
MPLS L3VPN (Optional).........................................................................................................................68
Local VRF Configuration ...................................................................................................................................... 68
BGP VPNv4 Configuration (Optional) .....................................................................................................74
BGP PE-CE Configuration..................................................................................................................................... 79
MPLS Traffic Engineering (Optional) ......................................................................................................86
Dynamic Path (Optional) .......................................................................................................................88
Explicit Path (Optional) .........................................................................................................................91
Advanced RPLs (Optional) .....................................................................................................................97
Multiple Action Policies ...................................................................................................................................... 97
Nested Policies (Optional) ................................................................................................................... 102
LTRARC-2002 Introduction to IOS XR Lab Guide 3|Page

Topology:
AS 1100 AS 2000 AS 1200
A q
g0
/1
/2
g0
g0
/2
g0
/1
10
4
24
10
2
0
.0/
/
.6
0.6
.0
4.
4.2
.11
4
2
.1.
2.
64
0. 6
0/
0
0.
/2 4
24
10
10
g0/0/0/2 g0/0/0/3 g0/0/0/3 g0/0/0/2
g0/1.10 192.168.1.0/24 g0/0/0/4.10 g0/0/0/0 10.12.1.0/24 g0/0/0/0 g0/0/0/4.10 192.168.2.0/24 g0/1.10

BGP BGP
XR1 XR2 g0
.20 /0 /0/
0/4 g0 4.2
/0/ 1
L3VPN
24 0/ 17
L3VPN
MPLS
0/ 0
MPLS
.0/ g0 0/ 10 0/
0/ 2.1
6.1 1 .1 2 4 6 .2.
2.1 3. AS 100 0/ g
0/2
17 1. . 1. 4
0/ 23
24
1 0.
2 0
/1.
g0 g0
/1.
g0 20
/1 /2
OSPF g0 OSPF
RR-1
 IP Addresses are preconfigured.

 All routers except XR1 and XR2 have been pre-configured.
 Configuration will be done on IOS-XR routers only (XR1-XR2)
Host Loopback IP
XR1 192.168.1.1
XR2 192.168.2.2
RR-1 192.168.100.100

Accessing the Lab
The lab is hosted by Cisco’s dCloud environment that provides training, labs, and demonstrations
for almost any Cisco technology for Cisco customers. More information can be found at
http://dcloud.cisco.com or on Twitter @ciscodcloud
This lab is only available to attendees of this CiscoLive class.
1. Access to the lab is obtained by launching Anyconnect and connecting to:

dcloud-lon-anyconnect.cisco.com
Your instructor will provide you with your username and credentials that are unique to your
pod. After authenticating, please click on ‘Ok’ to finalize the VPN connection to Dcloud.
2. Initiate a remote desktop session to the Dcloud workstation 198.18.133.36. Click on the
start button and type in mstsc /v:198.18.133.36
You will be prompted for user credentials. Use the username: WKST1\demo and the
password: C1sco12345

If a different username is shown than above, click on use another account and type in the
appropriate username.
Launch PuttyCM icon on your desktop

Basic Configuration commands:
Task Objective:
Using XR1 perform the following tasks
 Demonstrate changes around the interface and route statements

 Demonstrate various parsing elements
 Demonstrate ‘commit’, ‘commit replace’ and ‘rollback’ feature of IOS-XR.
 Check the commit points and verify config rollbacks.
 Demonstrate the usage of using files for pre-loading changes.
 Understand the use of ‘pwd’ and ‘root’ command
 At the end of this exercise, you would be able to configure and back out configuration.
Step 1. Show the existing IPv4 addresses
show ip interface brief

show ipv4 interface brief
Username: cisco
Password: cisco
RP/0/0/CPU0:XR1# show ip interface brief
Interface IP-Address Status Protocol

Loopback0 192.168.1.1 Up Up
GigabitEthernet0/0/0/0 10.12.1.1 Up Up
GigabitEthernet0/0/0/4 unassigned Shutdown Down
RP/0/0/CPU0:XR1# show ipv4 int brief
Interface IP-Address Status Protocol

GigabitEthernet0/0/0/4 unassigned Shutdown Down
Note: Some commands in IOS-XR require you to specify IPv4/IPv6

Step 2. Show the IPv4 routing table
show route
RP/0/0/CPU0:XR1# show route
Codes: C - connected, S - static, R - RIP, B - BGP, (>) - Diversion path

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - ISIS, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, su - IS-IS summary null, * - candidate default
U - per-user static route, o - ODR, L - local, G - DAGR, l - LISP
A - access/subscriber, a - Application route
M - mobile route, r - RPL, (!) - FRR Backup path
Gateway of last resort is not set
C 10.12.1.0/24 is directly connected, 13:20:53, GigabitEthernet0/0/0/0

L 10.12.1.1/32 is directly connected, 13:20:53, GigabitEthernet0/0/0/0
L 192.168.1.1/32 is directly connected, 13:20:53, Loopback0
Step 3. Demonstrate parsing elements
Show the running configuration but including only ‘ipv4’ addresses and the interface names. By
executing the command
show run | include "interface|ipv4"

RP/0/0/CPU0:XR1# show run | include interface|ipv4
^
% Invalid input detected at '^' marker.
RP/0/0/CPU0:XR1# show run | include "interface|ipv4"

Building configuration...
telnet vrf default ipv4 server max-servers 10
address-family ipv4 unicast
interface Loopback0
ipv4 address 192.168.1.1 255.255.255.255
interface MgmtEth0/0/CPU0/0
ipv4 address 198.18.1.10 255.255.255.0
interface GigabitEthernet0/0/0/0
ipv4 address 10.12.1.1 255.255.255.0
ipv4 address 10.13.1.1 255.255.255.0
ipv4 address 100.64.1.254 255.255.255.0
ipv4 address 100.64.11.254 255.255.255.0

RP/0/0/CPU0:XR1#
Unlike IOS, IOS-XR support true Boolean filtering, and as can be seen in the output above,
multiple arguments require them to be surrounded by quotation marks.
Step 4. Additional parsing utilities
IOS-XR also provides other parsing utilities as illustrated in the output below
RP/0/0/CPU0:XR1# show run | ?

begin Begin with the line that matches
exclude Exclude lines that match
file Save the configuration
include Include lines that match
utility A set of common unix utilities
<cr> Shows current operating configuration
RP/0/0/CPU0:XR1# show run | utility ?

cut Cut out selected fields of each line of a file
egrep Extended regular expression grep
fgrep Fixed string expression grep
head Show set of lines/characters from the top of a file
less Fixed string pattern matching
more Paging Utility More
script Launch a script for post processing
sort Sort, merge, or sequence-check text files
tail Copy the last part of files
uniq Report or filter out repeated lines in a file
wc Counting lines/words/characters of a file
xargs Construct argument list(s) and invoke a program

Step 5. Change Hostname Configuration
config t
hostname CiscoLive_2019
commit
end
RP/0/0/CPU0:XR1# config t
RP/0/0/CPU0:XR1(config)# hostname CiscoLive_2019
RP/0/0/CPU0:XR1(config)# commit
RP/0/0/CPU0:Jan 23 13:22:59.959 : config[65740]: %MGBL-CONFIG-6-DB_COMMIT : Configuration
committed by user 'cisco'. Use 'show configuration commit changes 1000000001' to view the
changes.
RP/0/0/CPU0:CiscoLive_2019(config)# end
RP/0/0/CPU0:CiscoLive_2019#
We’ve highlighted the hostname before (XR1) and after the change (CiscoLive_2019) along with
the change-id (1000000001).
Step 6. Find Configuration Commit ID
show configuration commit list
RP/0/0/CPU0:CiscoLive_2019# show configuration commit list

Wed Jan 23 13:25:56.367 UTC
SNo. Label/ID User Line Client Time Stamp
~~~~ ~~~~~~~~ ~~~~ ~~~~ ~~~~~~ ~~~~~~~~~~
1 1000000001 cisco con0_0_CPU0 CLI Wed Jan 23 13:22:59 2019
Note: Latest commit changes show up on top
Step 7. Look at the last configuration change
show configuration commit changes last 1
RP/0/0/CPU0:CiscoLive_2019# show configuration commit changes last 1

!! IOS XR Configuration 5.3.2
hostname CiscoLive_2019
end
LTRARC-2002 Introduction to IOS XR Lab Guide 10 | P a g e

Step 8. Revert back to original configuration
rollback configuration last 1

show configuration commit list
RP/0/0/CPU0:CiscoLive_2019# rollback configuration last 1
Loading Rollback Changes.

Loaded Rollback Changes in 1 sec
Committing.
1 items committed in 1 sec (0)items/sec
Updating.RP/0/0/CPU0:Jan 23 13:32:02.332 : config_rollback[65740]: %MGBL-CONFIG-6-DB_COMMIT :
Configuration committed by user 'cisco'. Use 'show configuration commit changes 1000000002' to
view the changes.
Updated Commit database in 1 sec

Configuration successfully rolled back 1 commits.
RP/0/0/CPU0:XR1#
RP/0/0/CPU0:XR1# show configuration commit list

Wed Jan 23 13:33:39.565 UTC
SNo. Label/ID User Line Client Time Stamp
~~~~ ~~~~~~~~ ~~~~ ~~~~ ~~~~~~ ~~~~~~~~~~
1 1000000002 cisco con0_0_CPU0 Rollback Wed Jan 23 13:32:01 2019
2 1000000001 cisco con0_0_CPU0 CLI Wed Jan 23 13:22:59 2019
RP/0/0/CPU0:XR1#
Step 9. Erase the running-configuration
conf
commit replace
y
do show run
The commit replace function will replace the running configuration with the target configuration
specified. In this example, nothing is configured in the target configuration, so this erases the
running-configuration. In other words, this is the equivalent to the command write erase in IOS
RP/0/0/CPU0:XR1# conf
Wed Jan 23 13:37:59.367 UTC
RP/0/0/CPU0:XR1(config)# commit replace
This commit will replace or remove the entire running configuration. This
operation can be service affecting.
Do you wish to proceed? [no]: y
RP/0/0/CPU0:ios(config)# do show run

Wed Jan 23 13:38:08.307 UTC
!! Last configuration change at Wed Jan 23 13:38:07 2019 by cisco
!

end
RP/0/0/CPU0:XR1#
Step 10. Rollback the change
This will bring us back to the state before the last change.
rollback configuration last 1
RP/0/0/CPU0:ios# rollback configuration last 1

Wed Jan 23 14:21:37.738 UTC
Loading Rollback Changes.

Loaded Rollback Changes in 1 sec
Committing.....
38 items committed in 5 sec (7)items/sec

Updating.RP/0/0/CPU0:Jan 23 14:21:43.968 : config_rollback[65740]: %MGBL-CONFIG-6-DB_COMMIT :
Configuration committed by user 'cisco'. Use 'show configuration commit changes 1000000004' to
view the changes.
Updated Commit database in 1 sec

Configuration successfully rolled back 1 commits.
RP/0/0/CPU0:XR1#
Step 11. Understanding IOS-XR command hierarchy.
IOS-XR is a hierarchical OS. At times, you may be in one configuration submode (i.e. OSPF),
and need to change to another configuration submode (i.e. configuring an IP address). This will
result in an error because you do not leave the original sub-configuration, and commands will be
entered under the wrong sub-configuration.
For example, enter the following commands to see the error:
conf
router ospf 100
area 0
int lo0
int gi0/0/0/4
ipv4 address 1.1.1.1 255.255.255.255
Wed Jan 23 14:30:48.640 UTC
RP/0/0/CPU0:XR1(config)# router ospf 100
RP/0/0/CPU0:XR1(config-ospf)# area 0
RP/0/0/CPU0:XR1(config-ospf-ar)# int lo0
RP/0/0/CPU0:XR1(config-ospf-ar-if)# int gi0/0/0/4
RP/0/0/CPU0:XR1(config-ospf-ar-if)# ipv4 address 1.1.1.1 255.255.255.255
^
RP/0/0/CPU0:XR1(config-ospf-ar-if)#
Step 12. Understanding the use of ‘pwd’

Because IOS-XR is hierarchical, the IP address assignment was done under the Router OSPF
configuration. The use of the pwd command will show you where you are in the configuration
mode.
RP/0/0/CPU0:XR1(config-ospf-ar-if)# pwd
14:34:01.147 UTC
router ospf 100
area 0
RP/0/0/CPU0:XR1(config-ospf-ar-if)#
Step 13. Understanding the use of ‘root’
Now let’s use the root command to take us to the root configuration prompt, and then change the
IP address.
root
int gi0/0/0/4
ipv4 address 1.1.1.1 255.255.255.255
RP/0/0/CPU0:XR1(config-ospf-ar-if)# root
RP/0/0/CPU0:XR1(config)#int gi0/0/0/4
RP/0/0/CPU0:XR1(config-if)#ipv4 address 1.1.1.1 255.255.255.255
RP/0/0/CPU0:XR1(config-if)#
Step 14. Using the exit command instead of the root command
The alternative to the root command is to keep typing the command exit over, and over again,
etc.
Enter the following commands to see the error again
router ospf 100
area 0
int lo0
int gi0/0/0/4
ipv4 address 1.1.1.1 255.255.255.255
Enter the following commands to get back to root prompt
exit
exit
exit
int gi0/0/0/4
ipv4 address 1.1.1.1 255.255.255.255
RP/0/0/CPU0:XR1(config-if)# router ospf 100

RP/0/0/CPU0:XR1(config-ospf)# area 0

RP/0/0/CPU0:XR1(config-ospf-ar)# int lo0
RP/0/0/CPU0:XR1(config-ospf-ar-if)# int gi0/0/0/4
RP/0/0/CPU0:XR1(config-ospf-ar-if)# ipv4 address 1.1.1.1 255.255.255.255
^
RP/0/0/CPU0:XR1(config-ospf-ar-if)# exit
RP/0/0/CPU0:XR1(config-ospf-ar)# exit
RP/0/0/CPU0:XR1(config-ospf)# exit
RP/0/0/CPU0:XR1(config)# int gi0/0/0/4
RP/0/0/CPU0:XR1(config-if)# ipv4 address 1.1.1.1 255.255.255.255
RP/0/0/CPU0:XR1(config-if)#
As you can see from the previous steps, using the root command is a lot quicker to get back to
the main configuration prompt than entering the exit commands multiple times.
Step 15. Abort the changes just made
The changes we made to test the pwd and root commands were not committed. To get back to
the exec prompt there are two options, entering the exit command which requires a confirmation
or entering the abort command which doesn’t
To test exit:
exit
exit
no
To test abort:
conf
int g0/0/0/4
abort
Exit command
RP/0/0/CPU0:XR1(config-if)# exit
RP/0/0/CPU0:XR1(config)# exit
Uncommitted changes found, commit them before exiting(yes/no/cancel)? [cancel]: no
RP/0/0/CPU0:Jan 23 15:08:30.885 : config[65740]: %MGBL-SYS-5-CONFIG_I : Configured from
console by cisco
RP/0/0/CPU0:XR1#
Abort command
RP/0/0/CPU0:XR1#
RP/0/0/CPU0:XR1(config)# int gi0/0/0/4
RP/0/0/CPU0:XR1(config-if)# abort

console by cisco
RP/0/0/CPU0:XR1#
Step 16. Just as in IOS, IOS XR supports usage of the do command, which allows you to
execute commands under configuration mode.
Wed Jan 23 15:16:23.093 UTC
RP/0/0/CPU0:XR1(config)# do show ipv4 int br | i Lo
RP/0/0/CPU0:XR1(config)#

Static Routes
Task Objective
 On XR1
o Configure a static route for 100.64.22.0/24 that points to XR2’s IP Address 10.12.1.2
o Configure a static route for 100.96.2.0/24 with an AD of 200 that points to XR2’s IP
Address 10.12.1.2 as well
 On XR2
o Configure a static route for 100.64.1.0/24 that points to XR1’s IP Address 10.12.1.1
o Configure a static route for 100.96.1.0/24 with an AD of 200 that points to XR1’s IP
Address 10.12.1.1 as well
 Verify that XR1 can ping 100.64.22.254 (AS 1200 Router)
 Verify that XR2 can ping 100.64.1.254 (AS 1100 Router)
 Static routes are preconfigured on the AS1100 and AS1200 routers.
Cisco Website for Static Route Configuration
Step 1. Initialize the Static Router Process and choose the correct address-family
On XR1 and XR2 enter the following commands:
router static
Step 2. Identify the network prefix destination, and next-hop IP address
On XR1 only, enter the following commands:
router static
100.64.22.0/24 10.12.1.2
100.96.2.0/24 10.12.1.2 200
commit
end
On XR2 enter the following commands:
router static
100.64.1.0/24 10.12.1.1
100.96.1.0/24 10.12.1.1 200
commit
end

Step 3. Static route show commands
Verify the static route configuration and functionality on XR1 and XR2 by executing the following
commands:
XR1
show run router static

show static topology
show route static
ping 100.64.22.254
XR2
ping 100.64.1.254
Note: IOS-XR does not use “ip” or “ipv6” protocol differentiators before the protocols, unlike IOS.
XR1
RP/0/0/CPU0:XR1# show run router static
Wed Jan 23 15:59:42.475 UTC
router static
100.64.22.0/24 10.12.1.2
100.96.2.0/24 10.12.1.2 200
!
vrf Management
0.0.0.0/0 198.18.1.1
!
!
!
RP/0/0/CPU0:XR1# show static topology

Wed Jan 23 15:59:42.615 UTC
VRF: default Table Id: 0xe0000000 AFI: IPv4 SAFI: Unicast

Prefix/Len Interface Nexthop Object Metrics
100.64.22.0/24 None 10.12.1.2 None [0/0/1/0]
100.96.2.0/24 None 10.12.1.2 None
[0/0/200/0]
RP/0/0/CPU0:XR1# show route static

Wed Jan 23 15:59:42.705 UTC
S 100.64.22.0/24 [1/0] via 10.12.1.2, 00:00:46

S 100.96.2.0/24 [200/0] via 10.12.1.2, 00:00:46
RP/0/0/CPU0:XR1# ping 100.64.22.254

Wed Jan 23 15:59:42.805 UTC
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.64.22.254, timeout is 2 seconds:
!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/4/9 ms
RP/0/0/CPU0:XR1#
XR2
RP/0/0/CPU0:XR2# ping 100.64.1.254
Wed Jan 23 16:01:23.458 UTC
!!!!!
RP/0/0/CPU0:XR2#

Open Shortest Path First (OSPF)
Task Objective:
 Configure OSPF on XR1 and XR2.
 Advertise only the Loopback 0, Gi0/0/0/0 and Gi0/0/0/1 interfaces into Area 0
 OSPF Process-ID is 1, Area-ID is 0 and Router-ID will be the Loopback0 IPv4 address
 Set all interface costs to 10 and set for ‘Area 0’ the network-type point-to-point
 Change the cost to 100 for the link between XR1-to-RR-1 & link XR2-to-RR-1
 Ensure end-to-end IP reachability exists via ICMP
 OSPF is already configured on RR-1.
Cisco Website for OSPF Configuration
Step 1. Enable OSPF and configure Router-ID
XR1
router ospf 1
router-id 192.168.1.1
XR2
router ospf 1
router-id 192.168.2.2
Step 2. Configure OSPF Area, Network-Type, interfaces and Advertise networks
XR1 and XR2
router ospf 1
cost 10
area 0
network point-to-point
interface Loopback0
cost 100
commit
end
Note: IOS-XR is hierarchical, setting the cost & network at the area level will cascade to the
members below it. Those settings can be overridden by setting an explicit value on a lower level
member as illustrated in the figure below.

Global Global
Time = 10 sec Time = 10 sec
Area 0 Area 0
Time = 10 sec (Inherited) Time = 10 sec (Inherited)
Interface Interface
Interface Interface
Area 1 Area 1
Time = 10 sec (Inherited) Time = 60 sec
Interface Interface
Interface Interface
Step 3. Validate OSPF configuration by executing the following commands
XR1 and XR2
show run router ospf

show ospf interface brief
show ospf summary
show ospf
show ospf neighbor
show ospf database database-summary
show ospf statistics spf
RP/0/0/CPU0:XR1# show run router ospf

Wed Jan 23 16:19:07.785 UTC
router ospf 1
router-id 192.168.1.1
cost 10
area 0
network point-to-point
interface Loopback0
!
!
cost 100
!
!
!
RP/0/0/CPU0:XR1# show ospf interface brief

Wed Jan 23 16:19:16.214 UTC
* Indicates MADJ interface, (P) Indicates fast detect hold down state
Interfaces for OSPF 1

Interface PID Area IP Address/Mask Cost State Nbrs F/C
Lo0 1 0 192.168.1.1/32 10 LOOP 0/0
Gi0/0/0/0 1 0 10.12.1.1/24 10 P2P 1/1
Gi0/0/0/1 1 0 10.13.1.1/24 100 P2P 1/1
RP/0/0/CPU0:XR1# show ospf summary

Wed Jan 23 16:19:21.484 UTC
Routing process "ospf 1"

Number of OSPF interfaces 3
Number of OSPF interfaces up 3
Number of OSPF virtual interfaces up 0
Number of OSPF sham-link interfaces up 0
Number of neighbors 2
Number of neighbors adjacent 2
Number of areas 1
LSA Type Count
Router : 3
Network : 0
Summary Net : 0
Summary ASBR : 0
Type-7 Ext : 0
Opaque Link : 0
Opaque Area : 3
Type-5 Ext : 0
Opaque AS : 0
RP/0/0/CPU0:XR1# show ospf

Wed Jan 23 16:23:27.557 UTC
Routing Process "ospf 1" with ID 192.168.1.1

Role: Primary Active
NSR (Non-stop routing) is Disabled
Supports only single TOS(TOS0) routes
Supports opaque LSA
Router is not originating router-LSAs with maximum metric
Initial SPF schedule delay 50 msecs
Minimum hold time between two consecutive SPFs 200 msecs
Maximum wait time between two consecutive SPFs 5000 msecs
Initial LSA throttle delay 50 msecs
Minimum hold time for LSA throttle 200 msecs
Maximum wait time for LSA throttle 5000 msecs
Minimum LSA interval 200 msecs. Minimum LSA arrival 100 msecs
LSA refresh interval 1800 seconds
Flood pacing interval 33 msecs. Retransmission pacing interval 66 msecs
Adjacency stagger enabled; initial (per area): 2, maximum: 64
Number of neighbors forming: 0, 2 full
Maximum number of configured interfaces 1024
Number of external LSA 0. Checksum Sum 00000000
Number of opaque AS LSA 0. Checksum Sum 00000000
Number of DCbitless external and opaque AS LSA 0
Number of DoNotAge external and opaque AS LSA 0
Number of areas in this router is 1. 1 normal 0 stub 0 nssa
External flood list length 0
SNMP trap is enabled
LSD connected, registered, bound, revision 1
Segment Routing Global Block default (16000-23999), not allocated
Area BACKBONE(0)
Number of interfaces in this area is 3
SPF algorithm executed 9 times
Number of LSA 6. Checksum Sum 0x0448c4
Number of opaque link LSA 0. Checksum Sum 00000000

Number of DCbitless LSA 0
Number of indication LSA 0
Number of DoNotAge LSA 0
Flood list length 0
Number of LFA enabled interfaces 0, LFA revision 0
Number of Per Prefix LFA enabled interfaces 0
Number of neighbors forming in staggered mode 0, 2 full
RP/0/0/CPU0:XR1# show ospf neighbor

Wed Jan 23 16:19:26.824 UTC
* Indicates MADJ interface

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

192.168.2.2 1 FULL/ - 00:00:35 10.12.1.2 GigabitEthernet0/0/0/0
Neighbor is up for 00:04:22
192.168.100.100 1 FULL/ - 00:00:32 10.13.1.3 GigabitEthernet0/0/0/1
Total neighbor count: 2
RP/0/0/CPU0:XR1# show ospf database database-summary

Wed Jan 23 16:20:24.640 UTC
OSPF Router with ID (192.168.1.1) (Process ID 1)
Area 0 database summary

LSA Type Count Delete Maxage
Router 3 0 0
Network 0 0 0
Summary Net 0 0 0
Summary ASBR 0 0 0
Type-7 Ext 0 0 0
Opaque Link 0 0 0
Opaque Area 3 0 0
Subtotal 6 0 0
Process 1 database summary

Router 3 0 0
Network 0 0 0
Summary Net 0 0 0
Summary ASBR 0 0 0
Type-7 Ext 0 0 0
Opaque Link 0 0 0
Opaque Area 3 0 0
Type-5 Ext 0 0 0
Opaque AS 0 0 0
Total 6 0 0
RP/0/0/CPU0:XR1# show ospf statistics spf

Wed Jan 23 16:20:58.627 UTC
SPF statistics for OSPF 1
Reason Codes: R - Router-LSA, N - Network-LSA,

SN - Summary-LSA (IP network),
SA - Summary-LSA (ASBR), X - AS-external-LSA
Last 9 Dijkstra Calculations

Delta T Area Runtime Reason
00:06:31 0 0 R, N,
00:06:27 0 0 R, N,
00:06:27 0 0
00:06:26 0 0 R,
00:06:25 0 0 R,
00:05:58 0 0 R,
00:05:57 0 0 R,
00:05:57 0 0 R,
00:05:54 0 0 R,
RP/0/0/CPU0:XR1#
Step 4. OSPF Trace
Traces are like running debug without taking up CPU resources. Traces are automatically
configured and running unlike debug features.
XR1 and XR2
show ospf trace

show ospf trace hello
show ospf trace adj 5
Note: The command show ospf trace adj 5 demonstrates how you can select the last <x>
number of traces you want to view
RP/0/0/CPU0:XR1# show ospf trace
OSPF Trace Summary (1, RP/0/0/CPU0:XR1, 3095M)
Trace Name Size Count Description

------------ ------- ---------- --------------------------
1. adj 8192 69 adjacency
2. adj_cycle 8192 35 dbd/flood events/pkts
3. config 4096 43 config events
4. errors 8192 3 errors
5. warnings 4096 1 low errors/warnings
6. events 4096 112 mda/rtrid/bfd/vrf
7. ha 8192 401 startup/HA/NSF
8. hello 2048 489 hello events/pkts
9. idb 8192 113 interface
10. pkt 2048 186 I/O packets
11. rib 8192 45 rib batching
12. spf 8192 273 spf/topology
13. spf_cycle 8192 0 spf/topology detail
14. te 4096 11 mpls-te
15. test 1024 47 testing info
16. mq 256 2 message queue info
RP/0/0/CPU0:XR1# show ospf trace hello

Wed Jan 23 16:27:35.470 UTC
Traces for OSPF 1 (Wed Jan 23 16:27:35)

Traces returned/requested/available: 496/2048/496
Trace buffer: hello

1 Jan 23 16:14:27.224* ospf_send_hello: area 0.0.0.0 intf Gi0/0/0/0 from 10.12.1.1
2 Jan 23 16:14:27.234 ospf_send_hello: area 0.0.0.0 intf Gi0/0/0/1 from 10.13.1.1
3 Jan 23 16:14:31.544* ospf_rcv_hello: intf Gi0/0/0/1 area 0.0.0.0 from 192.168.100.100
10.13.1.3
4 Jan 23 16:14:31.544* ospf_router_nbr_new: intf Gi0/0/0/1 area 0.0.0.0 from
192.168.100.100 10.13.1.3
5 Jan 23 16:14:31.544* ospf_check_hello_events: intf Gi0/0/0/1 area 0.0.0.0 from 10.13.1.1
6 Jan 23 16:14:31.544* ospf_router_nbr_new: end of router thread hello processing
9 Jan 23 16:14:40.633 ospf_rcv_hello: intf Gi0/0/0/1 area 0.0.0.0 from 192.168.100.100
10.13.1.3
<output omitted>
RP/0/0/CPU0:XR1# show ospf trace adj 5

Wed Jan 23 16:30:11.410 UTC
Traces for OSPF 1 (Wed Jan 23 16:30:11)

Traces returned/requested/available: 5/5/69
Trace buffer: adj
1 Jan 23 16:15:04.242* ospf_dec_nbr_form_cnt: nbr 192.168.2.2 forming Gi0/0/0/0, area

0.0.0.0
2 Jan 23 16:15:04.242* ospf_dec_nbr_form_cnt: #Nbrs: (ar: 0, inst: 0) forming, 2 full,
area 0.0.0.0
3 Jan 23 16:15:04.342* ospf_build_rtr_lsa: area 0.0.0.0 rtrid 192.168.1.1 seq 0x80000003
vrfid 0x60000000
4 Jan 23 16:15:11.581* ospf_nbr_hold_dbd: Timer expired (nbr_hold_dbd): nbr_id
192.168.100.100
5 Jan 23 16:15:44.259* ospf_nbr_hold_dbd: Timer expired (nbr_hold_dbd): nbr_id 192.168.2.2
RP/0/0/CPU0:XR1#

BGP Configuration
IBGP Peering
AS 1100 AS 2000 AS 1200
A q
g0
/1
/2
g0
g0
/2
g0
/1
10
4
24
10
0/2
0.
/
0.6
.0
64
.2.
11
.2
4
.64
.1.
4.
2 .0
.6
0/2
0
/2
0
10
10
4
4
g0/0/0/2 g0/0/0/3 g0/0/0/3 g0/0/0/2
g0/0/0/0 10.12.1.0/24 g0/0/0/0
XR1 XR2
g0
/0 /1
/ 0/ /0
10 /0
1 .1 24 g0
3. AS 100 0/
1. 1.
0/ 3.
24 .2
10
g0
/1 /2
g0
RR-1
Task Objective:
 Create the BGP Process 100, and set the BGP Router-ID to match Loopback 0’s IP
 Activate address-family ipv4 and advertise the Loopack 0 into BGP
 Configure iBGP session on XR1 & XR2 to the AS 100 Route-Reflector RR-1
 Source the connection from Loopback 0
 Set the BGP session password to CISCO
 Use only the IPv4 Address-Family, and set the next-hop-self parameter
 The Route-Reflector is already configured
Cisco Website for BGP Configuration
Route Reflector Loopback address
RR1 192.168.100.100

Step 1. Enable BGP and Configure Router-id on XR1 and XR2
XR1
router bgp 100

bgp router-id 192.168.1.1
XR2
router bgp 100

Step 2. Activate IPv4 Unicast address-family on XR1 and XR2
XR1
router bgp 100

network 192.168.1.1/32
XR2
router bgp 100

network 192.168.2.2/32
Step 3. Configure XR1 & XR2 with the BGP Peering to the Route-Reflector RR-1 for IPv4
XR1 and XR2
router bgp 100

neighbor 192.168.100.100
remote-as 100
password CISCO
update-source Loopback0
next-hop-self
commit
end
Step 4. Example showing different methods in which to apply configuration to IOS-XR. There is
no need to type the commands in this step. If you decide to do so, please do not commit the
configuration. Use the abort command once you are done.
IOS-XR syntax does allow for some flexibility, which can speed up the process of entering a
configuration, but will not change the context of the configuration submode. The example below
shows two methods of entering the configuration; that result in the same configuration being
applied.

RP/0/0/CPU0:XR1(config)# router bgp 65500
RP/0/0/CPU0:XR1(config-bgp)# neighbor 200.200.200.200
RP/0/0/CPU0:XR1(config-bgp-nbr)# remote-as 65500
RP/0/0/CPU0:XR1(config-bgp-nbr)# update-source lo0
RP/0/0/CPU0:XR1(config-bgp-nbr)# address-family ipv4 unicast
RP/0/0/CPU0:XR1(config-bgp-nbr-af)#
RP/0/0/CPU0:XR1(config-bgp-nbr-af)# show conf
router bgp 65500
neighbor 200.200.200.200
remote-as 65500
OR
RP/0/0/CPU0:XR1(config-bgp)# neighbor 200.200.200.200 remote-as 65500
RP/0/0/CPU0:XR1(config-bgp)# neighbor 200.200.200.200 update-source lo0
RP/0/0/CPU0:XR1(config-bgp)# neighbor 200.200.200.200 address-family ipv4 unicast
RP/0/0/CPU0:XR1(config-bgp-nbr-af)# show conf
router bgp 65500
neighbor 200.200.200.200
remote-as 65500
While the configuration is identical, the CLI prompt changed, which may affect future commands
that are entered. Please be aware of this behavior as you proceed through the lab.
Step 5. Verify BGP Configuration and Functionality
XR1 and XR2
show run router bgp

show bgp summary
show bgp ipv4 unicast
Note: It may take ~30-60 seconds for the BGP session to establish in this lab.

RP/0/0/CPU0:XR1# show run router bgp
Wed Jan 23 17:12:43.315 UTC
router bgp 100
network 192.168.1.1/32
!
neighbor 192.168.100.100
remote-as 100
password encrypted 00273A352774
next-hop-self
!
!
!
RP/0/0/CPU0:XR1# show bgp summary

Wed Jan 23 17:12:50.334 UTC
BGP router identifier 192.168.1.1, local AS number 100
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0xe0000000 RD version: 5
BGP main routing table version 5
BGP NSR Initial initsync version 2 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs
BGP is operating in STANDALONE mode.
Process RcvTblVer bRIB/RIB LabelVer ImportVer SendTblVer StandbyVer

Speaker 5 5 5 5 5 0
Neighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd

192.168.100.100 0 100 8 6 5 0 0 00:02:46 2
RP/0/0/CPU0:XR1# show bgp ipv4 unicast

Wed Jan 23 17:12:57.064 UTC
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
*>i10.100.100.0/24 192.168.100.100 0 100 0 i
*>i172.31.100.0/30 192.168.100.100 0 100 0 i
*> 192.168.1.1/32 0.0.0.0 0 32768 i
Processed 3 prefixes, 3 paths

RP/0/0/CPU0:XR1#

Neighbor Groups
Task Objective:
 Configure BGP Neighbor Group
 Delete the previous BGP neighbor peering with RR-1 192.168.100.100.
 Establish a full mesh between XR1, XR2, and RR-1.
 Reduce configuration by using a neighbor-group (AS100); and establish peerings with the
following settings:
o Source the connection from Loopback0
o Use password CISCO
o Use only the IPv4 Address-Family, and set the next-hop-self parameter
o RR-1 is pre-configured
Node Loopback address
RR 192.168.100.100
XR1 192.168.1.1
XR2 192.168.2.2
Step 1: Configure the BGP Neighbor Group
Step 6. Configure the BGP Neighbor Group
XR1 and XR2
router bgp 100

neighbor-group AS100
remote-as 100
password CISCO
next-hop-self

Step 7. Create the new BGP peerings on XR1 and XR2 with each other, and to RR-1. Use the
neighbor-group
XR1
router bgp 100

no neighbor 192.168.100.100
neighbor 192.168.100.100
use neighbor-group AS100
neighbor 192.168.2.2
commit
end
XR2
router bgp 100

no neighbor 192.168.100.100
neighbor 192.168.100.100
commit
end
Step 8. Verify the neighbor-group configuration
XR1 and XR2
show run router bgp

show bgp summary

Wed Jan 23 17:29:16.917 UTC
router bgp 100
network 192.168.1.1/32
!
remote-as 100
password encrypted 14343B382F2B
next-hop-self
!
!
!
neighbor 192.168.100.100
!
!

Wed Jan 23 17:29:23.926 UTC

Speaker 10 10 10 10 10 0

192.168.2.2 0 100 4 4 10 0 0 00:00:37 1
192.168.100.100 0 100 5 4 10 0 0 00:00:51 2
RP/0/0/CPU0:XR1#
IOS allows for configuration of peers with similar outbound policies through the use of ‘peer-
groups’. IOS-XR allows for the same capability with more flexibility through the use af-group,
session-group, and neighbor-groups.

EBGP Peering
AS 1100 AS 2000 AS 1200
A q
g0
/1
/2
g0
g0
/2
g0
/1
10
4
24
10
0/2
0.
/
0.6
.0
64
.2.
11
.2
4
.64
.1.
4.
2 .0
.6
0/2
0
/2
0
10
10
4
4
g0/0/0/2 g0/0/0/3 g0/0/0/3 g0/0/0/2
g0/0/0/0 10.12.1.0/24 g0/0/0/0
XR1 XR2
g0
/0 /1
/ 0/ /0
10 /0
1 .1 24 g0
3. AS 100 0/
1. 1.
0/ 3.
24 .2
10
g0
/1 /2
g0
RR-1
Task Objective:
 Configure a BGP session using the BGP Peer & AS settings listed below.
 Verify that routes are being exchanged.
Node BGP Peer IP Address Remote-AS #

XR1 100.64.1.1 1100
XR2 100.64.2.1 1200
Step 9. Configure eBGP Peering to the ISP router and validate the EBGP configuration and
connectivity
XR1
router bgp 100

neighbor 100.64.1.1
remote-as 1100
commit
end

XR2
router bgp 100

neighbor 100.64.2.1
remote-as 1200
commit
end
RP/0/0/CPU0:XR1# conf t
Wed Jan 23 17:50:17.160 UTC
RP/0/0/CPU0:XR1(config-bgp)# neighbor 100.64.1.1
RP/0/0/CPU0:XR1(config-bgp-nbr)# remote-as 1100
RP/0/0/CPU0:XR1(config-bgp-nbr)# address-family ipv4 unicast
RP/0/0/CPU0:XR1(config-bgp-nbr-af)# commit
Wed Jan 23 17:50:19.720 UTC
RP/0/0/CPU0:Jan 23 17:50:19.800 : config[65740]: %MGBL-CONFIG-6-DB_COMMIT : Configuration
committed by user 'cisco'. Use 'show configuration commit changes 1000000010' to view the
changes.
RP/0/0/CPU0:Jan 23 17:50:37.829 : bgp[1053]: %ROUTING-BGP-5-ADJCHANGE : neighbor 100.64.1.1 Up

(VRF: default) (AS: 1100)
RP/0/0/CPU0:Jan 23 17:50:37.829 : bgp[1053]: %ROUTING-BGP-6-NBR_NOPOLICY : No inbound IPv4
Unicast policy is configured for eBGP neighbor 100.64.1.1. No IPv4 Unicast prefixes will be
accepted from the neighbor until inbound policy is configured.
RP/0/0/CPU0:Jan 23 17:50:37.829 : bgp[1053]: %ROUTING-BGP-6-NBR_NOPOLICY : No outbound IPv4
Unicast policy is configured for eBGP neighbor 100.64.1.1. No IPv4 Unicast prefixes will be
sent to the neighbor until outbound policy is configured.
RP/0/0/CPU0:XR1(config-bgp-nbr-af)#
RP/0/0/CPU0:XR1(config-bgp-nbr-af)# end
console by cisco
RP/0/0/CPU0:XR1#
Notice the EBGP neighbor is up but there are a couple of syslogs indicating no IPv4 addresses
will be accepted or sent
Step 10. Verify EBGP functionality details on XR1 only
XR1
show bgp ipv4 unicast summary

show bgp ipv4 unicast neighbor 100.64.1.1

RP/0/0/CPU0:XR1# show bgp ipv4 unicast summary
Wed Jan 23 18:20:44.795 UTC

Speaker 10 10 10 10 10 0
Some configured eBGP neighbors (under default or non-default vrfs)

do not have both inbound and outbound policies configured for IPv4 Unicast
address family. These neighbors will default to sending and/or
receiving no routes and are marked with '!' in the output below.
Use the 'show bgp neighbor <nbr_address>' command for details.

100.64.1.1 0 1100 40 34 10 0 0 00:30:07 0!
192.168.2.2 0 100 55 55 10 0 0 00:51:58 1
192.168.100.100 0 100 62 56 10 0 0 00:52:11 2
RP/0/0/CPU0:XR1# show bgp ipv4 unicast neighbor 100.64.1.1

Wed Jan 23 18:21:59.340 UTC
BGP neighbor is 100.64.1.1

Remote AS 1100, local AS 100, external link
Remote router ID 164.144.11.1
BGP state = Established, up for 00:31:21
NSR State: None
Last read 00:00:22, Last read before reset 00:00:00
Hold time is 180, keepalive interval is 60 seconds
Configured hold time: 180, keepalive: 60, min acceptable hold time: 3
Last write 00:00:16, attempted 19, written 19
Second last write 00:01:16, attempted 19, written 19
Last write before reset 00:00:00, attempted 0, written 0
Second last write before reset 00:00:00, attempted 0, written 0
Last write pulse rcvd Jan 23 18:21:43.541 last full not set pulse count 73
Last write pulse rcvd before reset 00:00:00
Socket not armed for io, armed for read, armed for write
Last write thread event before reset 00:00:00, second last 00:00:00
Last KA expiry before reset 00:00:00, second last 00:00:00
Last KA error before reset 00:00:00, KA not sent 00:00:00
Last KA start before reset 00:00:00, second last 00:00:00
Precedence: internet
Enforcing first AS is enabled
Multi-protocol capability received
Neighbor capabilities:
Route refresh: advertised (old + new) and received (old + new)
Graceful Restart (GR Awareness): advertised
4-byte AS: advertised and received
Address family IPv4 Unicast: advertised and received
Received 41 messages, 0 notifications, 0 in queue
Sent 35 messages, 1 notifications, 0 in queue
Minimum time between advertisement runs is 30 secs
Inbound message logging enabled, 3 messages buffered

Outbound message logging enabled, 3 messages buffered
For Address Family: IPv4 Unicast

BGP neighbor version 10
Update group: 0.3 Filter-group: 0.1 No Refresh request being processed
eBGP neighbor with no inbound or outbound policy; defaults to 'drop'
Route refresh request: received 0, sent 0
0 accepted prefixes, 0 are bestpaths
Cumulative no. of prefixes denied: 2.
No policy: 2, Failed RT match: 0
By ORF policy: 0, By policy: 0
Prefix advertised 0, suppressed 0, withdrawn 0
Maximum prefixes allowed 1048576
Threshold for warning message 75%, restart interval 0 min
An EoR was not received during read-only mode
Last ack version 10, Last synced ack version 0
Outstanding version objects: current 0, max 0
Additional-paths operation: None
Connections established 1; dropped 0

Local host: 100.64.1.254, Local port: 179, IF Handle: 0x00000400
Foreign host: 100.64.1.1, Foreign port: 18767
Last reset 00:31:30, due to BGP Notification sent: peer in wrong AS
Time since last notification sent to neighbor: 00:31:30
Error Code: peer in wrong AS
Notification data sent:
DC050000
RP/0/0/CPU0:XR1#
Because a route-policy does not exist for an EBGP peer, all routes are dropped To/From that
peer.
Step 11. Correct the error by applying an inbound and an outbound policy to XR1 and XR2
XR1
route-policy PASS-ALL
pass
end-policy
router bgp 100

neighbor 100.64.1.1
route-policy PASS-ALL in
route-policy PASS-ALL out
commit
end

XR2
pass
end-policy
router bgp 100

neighbor 100.64.2.1
commit
end
Step 12. Verify BGP Configuration and Functionality
XR1
show run router bgp

show bgp summary
show bgp neighbor 100.64.1.1
XR2
show run router bgp

show bgp summary

Wed Jan 23 18:39:21.129 UTC
router bgp 100
network 192.168.1.1/32
!
remote-as 100
password encrypted 14343B382F2B
next-hop-self
!
!
neighbor 100.64.1.1
remote-as 1100
!
!

!
neighbor 192.168.100.100
!
!

Wed Jan 23 18:39:37.108 UTC

Speaker 13 13 13 13 13 0

100.64.1.1 0 1100 62 58 13 0 0 00:48:59 2
192.168.2.2 0 100 76 77 13 0 0 01:10:51 2
192.168.100.100 0 100 83 77 13 0 0 01:11:04 2
RP/0/0/CPU0:XR1# show bgp neighbor 100.64.1.1

Wed Jan 23 18:39:46.767 UTC

Remote AS 1100, local AS 100, external link
Remote router ID 164.144.11.1
BGP state = Established, up for 00:49:08
NSR State: None
Last read 00:00:49, Last read before reset 00:00:00
Hold time is 180, keepalive interval is 60 seconds
Configured hold time: 180, keepalive: 60, min acceptable hold time: 3
Last write 00:00:17, attempted 19, written 19
Second last write 00:01:17, attempted 19, written 19
Last write before reset 00:00:00, attempted 0, written 0
Second last write before reset 00:00:00, attempted 0, written 0
Last write pulse rcvd Jan 23 18:39:29.498 last full not set pulse count 113
Last write pulse rcvd before reset 00:00:00
Socket not armed for io, armed for read, armed for write
Last write thread event before reset 00:00:00, second last 00:00:00
Last KA expiry before reset 00:00:00, second last 00:00:00
Last KA error before reset 00:00:00, KA not sent 00:00:00
Last KA start before reset 00:00:00, second last 00:00:00
Precedence: internet
Enforcing first AS is enabled
Multi-protocol capability received
Neighbor capabilities:
Route refresh: advertised (old + new) and received (old + new)
Graceful Restart (GR Awareness): advertised
4-byte AS: advertised and received
Address family IPv4 Unicast: advertised and received
Received 62 messages, 0 notifications, 0 in queue
Sent 58 messages, 1 notifications, 0 in queue
Minimum time between advertisement runs is 30 secs

Inbound message logging enabled, 3 messages buffered
Outbound message logging enabled, 3 messages buffered

Policy for incoming advertisements is PASS-ALL
Policy for outgoing advertisements is PASS-ALL

DC050000
RP/0/0/CPU0:XR1#
XR2
Wed Jan 23 18:43:07.913 UTC
router bgp 100
network 192.168.2.2/32
!
remote-as 100
password encrypted 05282F3C0263
next-hop-self
!
!
neighbor 100.64.2.1
remote-as 1200
!
!
!
neighbor 192.168.100.100
!
!

RP/0/0/CPU0:XR2#

Wed Jan 23 18:44:06.359 UTC

Speaker 13 13 13 13 13 0

100.64.2.1 0 1200 20 23 13 0 0 00:12:56 1
192.168.1.1 0 100 81 80 13 0 0 01:15:20 3
192.168.100.100 0 100 87 80 13 0 0 01:15:17 2
RP/0/0/CPU0:XR2#
Step 13. Verify BGP Functionality with BGP Trace
XR1
show bgp trace ?

show bgp trace bgp
show bgp trace bgp reverse

RP/0/0/CPU0:XR1# show bgp trace ?
addpath Async category(cisco-support)
aipc AIPC category(cisco-support)
bfd BFD category(cisco-support)
bgp General category(cisco-support)
brib bRIB API category(cisco-support)
commlib Communication Library category(cisco-support)
debug Debug category(cisco-support)
epe EPE category(cisco-support)
error Error category(cisco-support)
event Event category(cisco-support)
file Specific file(cisco-support)
flowspec Flowspec category(cisco-support)
ha High Availability category(cisco-support)
hexdump Display traces in hexadecimal(cisco-support)
instance Choose a particular BGP instance(cisco-support)
io IO category(cisco-support)
issu ISSU category(cisco-support)
l2vpn L2VPN category(cisco-support)
label Label category(cisco-support)
last Display last <n> entries(cisco-support)
link-state BGP-LS category(cisco-support)
location Card location(cisco-support)
mdt MDT category(cisco-support)
mvpn MVPN category(cisco-support)
nexthop Nexthop category(cisco-support)
policy Policy Execution categories(cisco-support)
postit Postit category(cisco-support)
progress Progress category(cisco-support)
rdwalk RDwalk category(cisco-support)
reverse Display latest traces first(cisco-support)
rib RIB category(cisco-support)
rt-ct RT constraint category(cisco-support)
stats Display statistics(cisco-support)
sync Synchronization category(cisco-support)
tailf Display new traces as they are added(cisco-support)
unique Unique entries with counts(cisco-support)
update Update category(cisco-support)
usec Display timestamp w/usec detail(cisco-support)
verbose Display internal debugging information(cisco-support)
wide Dont display buffer name, node name, tid(cisco-support)
wrapping Wrapping entries(cisco-support)
| Output Modifiers
<cr>
RP/0/0/CPU0:XR1# show bgp trace bgp

Wed Jan 23 18:52:23.255 UTC
111 wrapping entries (1826304 possible, 3584 allocated, 579 filtered, 690 total)
Jan 23 17:09:53.586 bgp/bpm-tr2-gen 0/0/CPU0 t1 [GEN]:17804: BPM cfg register verification -
No error
Jan 23 17:09:56.846 bgp/bpm-tr2-gen 0/0/CPU0 t1 [GEN]:3285: BPM verify running (sense=1,
asn=100, inst=default) started
asn=100, inst=default) ended
Jan 23 17:09:56.846 bgp/bpm-tr2-gen 0/0/CPU0 t1 [GEN]:3518: BPM apply running (sense=1,
Jan 23 17:09:56.846 bgp/bpm-tr2-gen 0/0/CPU0 t1 [GEN]:3530: BPM doing apply-running for
configuration
Jan 23 17:09:56.846 bgp/bpm-tr2-gen 0/0/CPU0 t1 [GEN]:3556: BPM inst_id (inst=default, inst-
id 0)
Jan 23 17:09:56.846 bgp/bpm-tr2-gen 0/0/CPU0 t1 [GEN]:3559: BPM num_insts (inst=default,
num_insts 1)

<output omitted>
RP/0/0/CPU0:XR1# show bgp trace bgp reverse

Wed Jan 23 18:52:51.303 UTC
111 wrapping entries (1826304 possible, 3584 allocated, 579 filtered, 690 total)
Jan 23 18:29:12.580 bgp/bpm-tr2-gen 0/0/CPU0 t1 [GEN]:3530: BPM doing apply-running for
configuration
Jan 23 17:50:37.829 default-bgp/spkr-tr2-gen 0/0/CPU0 t14 [GEN]:551: Nbr '100.64.1.1'
established
Jan 23 17:50:37.829 default-bgp/spkr-tr2-gen 0/0/CPU0 t14 [GEN]:548: nbr 100.64.1.1, old state
5, new state 6, fd type 1, fd 134
<output omitted>

Basic Route Policy Language
Blocking based off Prefixes
Task Objective:
 Verify routes that are advertised to BGP Peer
 On XR1, create an RPL named RFC1918 that drops routes to EBGP peers that match RFC
1918 space using an inline set matching 10.0.0.0/8; 172.16.0.0/12, or 192.168.0.0/16
ranges
 On XR2, create an RPL named RFC1918 that drops routes to EBGP peers that match RFC
1918 space using a prefix set named PREFIX-SET-RFC1918 that matches 10.0.0.0/8;
172.16.0.0/12, or 192.168.0.0/16 ranges)
 Verify RPLs
 Apply RPL outbound to EBGP peers on XR1 and XR2, and verify outbound routes.
Step 1. Verify routes advertised by XR1 and XR2 to their BGP peers
XR1
show bgp neighbors 100.64.1.1 advertised-routes
XR2
show bgp neighbors 100.64.2.1 advertised-routes
RP/0/0/CPU0:XR1# show bgp neighbors 100.64.1.1 advertised-routes

Wed Jan 23 19:07:29.993 UTC
Network Next Hop From AS Path
10.100.100.0/24 100.64.1.254 192.168.100.100 100i
164.144.11.0/24 100.64.1.254 192.168.2.2 100 1200 123 109?
172.31.100.0/30 100.64.1.254 192.168.100.100 100i
192.168.1.1/32 100.64.1.254 Local 100i
192.168.2.2/32 100.64.1.254 192.168.2.2 100i

RP/0/0/CPU0:XR1#
RP/0/0/CPU0:XR2# show bgp neighbors 100.64.2.1 advertised-routes

Wed Jan 23 19:09:20.735 UTC
5.5.1.0/24 100.64.2.254 192.168.1.1 100 1100?
8.8.8.0/24 100.64.2.254 192.168.1.1 100 1100 7018i
10.100.100.0/24 100.64.2.254 192.168.100.100 100i
172.31.100.0/30 100.64.2.254 192.168.100.100 100i
192.168.1.1/32 100.64.2.254 192.168.1.1 100i
192.168.2.2/32 100.64.2.254 Local 100i

RP/0/0/CPU0:XR2#
Step 2. Create an inline set for RPL RFC1918 on XR1 and a prefix set for RPL RFC1918 on XR2.
Pay close attention to the difference between the two.
XR1 (using inline set)
route-policy RFC1918
if destination in (10.0.0.0/8 ge 8, 172.16.0.0/12 ge 12, 192.168.0.0/16 ge 16) then
drop
endif
pass
end-policy
XR2 (using prefix set)
prefix-set PREFIX-SET-RFC1918
10.0.0.0/8 ge 8,
172.16.0.0/12 ge 12,
192.168.0.0/16 ge 16
end-set
!
if destination in PREFIX-SET-RFC1918 then
drop
endif
pass
end-policy
Remember inline set and prefix set are just two different ways of achieving the same end result
where PREFIX-SET is the recommended approach due to its modularity.
Step 3. Verify RPL on XR1 with the following show commands
show run rpl Displays RPL configuration

show rpl route-policy states This command is useful to see RPLs that are
ACTIVE, INACTIVE or UNUSED
show rpl route-policy RFC1918 attachpoints This command is helpful for finding out where
the RPL is used
show bgp ipv4 unicast route-policy This command is helpful in verifying RPL
RFC1918 before applying it to a policy. Filtering inbound
show bgp Displays BGP entries to compare to the
previous command

RP/0/0/CPU0:XR1# show run rpl
Wed Jan 23 19:58:30.423 UTC
drop
endif
pass
end-policy
!
pass
end-policy
!
RP/0/0/CPU0:XR1# show rpl route-policy states

Wed Jan 23 19:58:54.772 UTC
ACTIVE -- Referenced by at least one policy which is attached

INACTIVE -- Only referenced by policies which are not attached
UNUSED -- Not attached (directly or indirectly) and not referenced
The following policies are (ACTIVE)

------------------------------------------
pass
end-policy
!
The following policies are (INACTIVE)

------------------------------------------
None found with this status.
The following policies are (UNUSED)

------------------------------------------
drop
endif
pass
end-policy
!
RP/0/0/CPU0:XR1# show rpl route-policy RFC1918 attachpoints

Wed Jan 23 19:59:04.041 UTC
route-policy RFC1918 is not attached at any attach point
RP/0/0/CPU0:XR1# show bgp ipv4 unicast route-policy RFC1918

Wed Jan 23 19:58:39.203 UTC


*> 5.5.1.0/24 100.64.1.1 0 0 1100 ?
*> 8.8.8.0/24 100.64.1.1 0 0 1100 7018 i
*>i164.144.11.0/24 192.168.2.2 0 100 0 1200 123 109 ?
RP/0/0/CPU0:XR1# show bgp

Wed Jan 23 19:59:15.830 UTC

*> 5.5.1.0/24 100.64.1.1 0 0 1100 ?
*> 8.8.8.0/24 100.64.1.1 0 0 1100 7018 i
*>i10.100.100.0/24 192.168.100.100 0 100 0 i
*>i164.144.11.0/24 192.168.2.2 0 100 0 1200 123 109 ?
*>i172.31.100.0/30 192.168.100.100 0 100 0 i
*> 192.168.1.1/32 0.0.0.0 0 32768 i
*>i192.168.2.2/32 192.168.2.2 0 100 0 i

RP/0/0/CPU0:XR1#
Compare the show bgp output to the output of the show bgp ipv4 unicast route-policy
RFC1918 command. The highlighted prefixes in the show bgp output are the ones that could be
filtered by the RPL policy.
Step 4. Verify RPL on XR2 with the following show commands
show run rpl Displays RPL configuration

show rpl route-policy states This command is useful to see RPLs that are
ACTIVE, INACTIVE or UNUSED
show rpl route-policy RFC1918 attachpoints This command is helpful for finding out where
the RPL is used
show bgp ipv4 unicast route-policy This command is helpful in verifying RPL
RFC1918 before applying it to a policy. Filtering inbound
show bgp Displays BGP entries to compare to the
previous command

RP/0/0/CPU0:XR2# show run rpl
Wed Jan 23 20:08:26.652 UTC
10.0.0.0/8 ge 8,
172.16.0.0/12 ge 12,
192.168.0.0/16 ge 16
end-set
!
drop
endif
pass
end-policy
!
pass
end-policy
!

Wed Jan 23 20:08:33.882 UTC


------------------------------------------
pass
end-policy
!

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

------------------------------------------
drop
endif
pass
end-policy
!

Wed Jan 23 20:08:43.131 UTC
route-policy RFC1918 is not attached at any attach point
RP/0/0/CPU0:XR2# show bgp ipv4 unicast route-policy RFC1918

Wed Jan 23 20:08:51.930 UTC


*>i5.5.1.0/24 192.168.1.1 0 100 0 1100 ?
*>i8.8.8.0/24 192.168.1.1 0 100 0 1100 7018 i
*> 164.144.11.0/24 100.64.2.1 0 0 1200 123 109 ?

Wed Jan 23 20:08:59.890 UTC

*>i5.5.1.0/24 192.168.1.1 0 100 0 1100 ?
*>i8.8.8.0/24 192.168.1.1 0 100 0 1100 7018 i
*>i10.100.100.0/24 192.168.100.100 0 100 0 i
*> 164.144.11.0/24 100.64.2.1 0 0 1200 123 109 ?
*>i172.31.100.0/30 192.168.100.100 0 100 0 i
*>i192.168.1.1/32 192.168.1.1 0 100 0 i
*> 192.168.2.2/32 0.0.0.0 0 32768 i

RP/0/0/CPU0:XR2#
Compare the show bgp output to the output of the show bgp ipv4 unicast route-policy
RFC1918 command. The highlighted prefixes in the show bgp output are the ones that could be
filtered by the RPL policy.
Step 5. Simplify viewing RPLs that use RPL sets.
The inline keyword combines the RPL sets into the RPL when viewing it. The output below shows
both methods to find the prefixes that are being dropped by the prefix set configured on XR2.
Which one do you find simpler?
Method 1
RP/0/0/CPU0:XR2# show rpl route-policy RFC1918
Wed Jan 23 20:18:46.540 UTC

drop
endif
pass
end-policy
!
RP/0/0/CPU0:XR2# show rpl prefix-set PREFIX-SET-RFC1918
Wed Jan 23 20:18:56.159 UTC
10.0.0.0/8 ge 8,
172.16.0.0/12 ge 12,
192.168.0.0/16 ge 16
end-set
!
Method 2 using inline keyword
RP/0/0/CPU0:XR2# show rpl route-policy RFC1918 inline
Wed Jan 23 20:19:06.948 UTC
drop
endif
pass
end-policy
!
RP/0/0/CPU0:XR2#
Step 6. Apply the RPL Outbound to EBGP Peers on XR1 and XR2
By doing this, the locally prefix on XR1 and XR2 will not be sent to the EBGP neighors
XR1
router bgp 100

neighbor 100.64.1.1
route-policy RFC1918 out
commit
end
XR2
router bgp 100

neighbor 100.64.2.1
commit
end

Step 7. Verify RPL configuration
XR1
show run router bgp 100 neighbor 100.64.1.1

show rpl route-policy states
show rpl route-policy RFC1918 attachpoints
XR2

show rpl route-policy RFC1918 attachpoints
XR1
RP/0/0/CPU0:XR1# show run router bgp 100 neighbor 100.64.1.1
router bgp 100

neighbor 100.64.1.1
remote-as 1100
!
!
!


------------------------------------------
pass
end-policy
!
drop
endif
pass
end-policy
!

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

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

Wed Jan 23 20:38:34.709 UTC
BGP Attachpoint: Neighbor
Neighbor/Group type afi/safi in/out vrf name bound by

--------------------------------------------------------------------------------
100.64.1.1 -- IPv4/uni out default RFC1918
RP/0/0/CPU0:XR1#
XR2
Wed Jan 23 20:41:12.247 UTC
router bgp 100
neighbor 100.64.2.1
remote-as 1200
!
!
!

Wed Jan 23 20:41:18.287 UTC


------------------------------------------
pass
end-policy
!
drop
endif
pass
end-policy
!

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

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

--------------------------------------------------------------------------------
100.64.2.1 -- IPv4/uni out default RFC1918

RP/0/0/CPU0:XR2#
Notice how the policy is now applied and active
Step 8. Verify the intended results
The locally generated prefix should not be advertised to EBGP neighbor
XR1

show bgp nei 100.64.1.1 advertised-routes
XR2

show bgp nei 100.64.2.1 advertised-routes
XR1
<output omitted>

*> 5.5.1.0/24 100.64.1.1 0 0 1100 ?
*> 8.8.8.0/24 100.64.1.1 0 0 1100 7018 i
*>i10.100.100.0/24 192.168.100.100 0 100 0 i
*>i164.144.11.0/24 192.168.2.2 0 100 0 1200 123 109 ?
*>i172.31.100.0/30 192.168.100.100 0 100 0 i
*> 192.168.1.1/32 0.0.0.0 0 32768 i
*>i192.168.2.2/32 192.168.2.2 0 100 0 i
RP/0/0/CPU0:XR1# show bgp nei 100.64.1.1 advertised-routes

Wed Jan 23 20:51:37.015 UTC
164.144.11.0/24 100.64.1.254 192.168.2.2 100 1200 123 109?

RP/0/0/CPU0:XR1#
XR2
<output omitted>

*>i5.5.1.0/24 192.168.1.1 0 100 0 1100 ?
*>i8.8.8.0/24 192.168.1.1 0 100 0 1100 7018 i
*>i10.100.100.0/24 192.168.100.100 0 100 0 i
*> 164.144.11.0/24 100.64.2.1 0 0 1200 123 109 ?
*>i172.31.100.0/30 192.168.100.100 0 100 0 i
*>i192.168.1.1/32 192.168.1.1 0 100 0 i
*> 192.168.2.2/32 0.0.0.0 0 32768 i

RP/0/0/CPU0:XR2#
RP/0/0/CPU0:XR2# show bgp neighbor 100.64.2.1 advertised-routes
Wed Jan 23 20:52:47.990 UTC
5.5.1.0/24 100.64.2.254 192.168.1.1 100 1100?
8.8.8.0/24 100.64.2.254 192.168.1.1 100 1100 7018i

RP/0/0/CPU0:XR2#
XR1 is not advertising the following prefixes that are not part of RFC1918 for the following
reasons:
5.5.1.0/24 and 8.8.8.0/24 – they were directly learnt from the EBGP neighbor 100.64.1.1
XR2 is not advertising the following prefixes that are not part of RFC1918 for the following
reasons:
164.144.11.0/24 – it was learnt directly from the EBGP neighbor 100.64.2.1

Blocking based off AS-PATH
Task Objective:
 Establish an EBGP session with the following devices: (Use the PASS-ALL RPL for
inbound/outbound)
Node BGP Peer IP Address Remote-AS #

XR1 100.64.11.1 2000
XR2 100.64.22.1 2000
 Verify routes that are received from the BGP Peer

 Create an RPL (BAD-ASN) on XR1 that drops routes that match traversal through AS 123
using inline set notation.
 Create an RPL (BAD-ASN) on XR2 that drops routes that match traversal through AS 123
using a Prefix set instead of inline set notation.
 Verify the RPLs
 Apply RPL BAD-ASN inbound to all EBGP peers, and verify outbound routes.
Step 9. Establish BGP Sessions to AS 2000 on XR1 and XR2
XR1
router bgp 100

remote-as 2000
commit
end
XR2
router bgp 100

remote-as 2000
commit
end

Step 10. Analyze BGP table on XR1 and XR2
XR1 and XR2
XR1


*> 5.5.1.0/24 100.64.1.1 0 0 1100 ?
* 100.64.11.1 0 0 2000 ?
*>i8.8.4.0/24 192.168.2.2 0 100 0 2000 2828 ?
*> 8.8.8.0/24 100.64.1.1 0 0 1100 7018 i
*>i10.100.100.0/24 192.168.100.100 0 100 0 i
*>i164.144.11.0/24 192.168.2.2 0 100 0 1200 123 109 ?
*> 164.144.22.0/24 100.64.11.1 0 0 2000 123 27343 i
*>i172.31.100.0/30 192.168.100.100 0 100 0 i
*> 192.168.1.1/32 0.0.0.0 0 32768 i
*>i192.168.2.2/32 192.168.2.2 0 100 0 i

RP/0/0/CPU0:XR1#
XR2
Wed Jan 23 21:19:00.972 UTC

*>i5.5.1.0/24 192.168.1.1 0 100 0 1100 ?
*> 8.8.4.0/24 100.64.22.1 0 0 2000 2828 ?
*>i8.8.8.0/24 192.168.1.1 0 100 0 1100 7018 i

*>i10.100.100.0/24 192.168.100.100 0 100 0 i
*> 164.144.11.0/24 100.64.2.1 0 0 1200 123 109 ?
*>i164.144.22.0/24 192.168.1.1 0 100 0 2000 123 27343 i
*>i172.31.100.0/30 192.168.100.100 0 100 0 i
*>i192.168.1.1/32 192.168.1.1 0 100 0 i
*> 192.168.2.2/32 0.0.0.0 0 32768 i

RP/0/0/CPU0:XR2#
Step 11. Create the RPL BAD-ASN on XR1 and XR2. There are two methods to match AS 123,
using regular expressions or XR’s ‘passess-through’ matching operation. You can pick either
method or mix and match them, they work the same way and you will see the same result. The
only difference is XR’s passess-through is more readable.
Regular Expression Passes-through Operation

XR1 (inline set) XR1 (inline set)
route-policy BAD-ASN route-policy BAD-ASN

if as-path in (ios-regex '_123_') then if as-path passes-through '123' then
drop drop
endif endif
pass pass
end-policy end-policy
commit commit
end end
XR2 (AS set) XR2 (AS set)
as-path-set AS-PATH-SET-BAD-AS as-path-set AS-PATH-SET-BAD-AS

ios-regex '_123_' passes-through '123'
end-set end-set
route-policy BAD-ASN route-policy BAD-ASN

if as-path in AS-PATH-SET-BAD-AS then if as-path in AS-PATH-SET-BAD-AS then
drop drop
endif endif
pass pass
end-policy end-policy
commit commit
end end

Execute the following commands to test the RPL and verify if it is filtering AS 123 before applying
it to the EBGP neighbor
XR1 and XR2
show bgp ipv4 unicast route-policy BAD-ASN

show bgp
XR1
RP/0/0/CPU0:XR1# show bgp ipv4 unicast route-policy BAD-ASN
<output omitted>

*> 5.5.1.0/24 100.64.1.1 0 0 1100 ?
* 100.64.11.1 0 0 2000 ?
*>i8.8.4.0/24 192.168.2.2 0 100 0 2000 2828 ?
*> 8.8.8.0/24 100.64.1.1 0 0 1100 7018 i
*>i10.100.100.0/24 192.168.100.100 0 100 0 i
*>i172.31.100.0/30 192.168.100.100 0 100 0 i
*> 192.168.1.1/32 0.0.0.0 0 32768 i
*>i192.168.2.2/32 192.168.2.2 0 100 0 i

<output omitted>

*> 5.5.1.0/24 100.64.1.1 0 0 1100 ?
* 100.64.11.1 0 0 2000 ?
*>i8.8.4.0/24 192.168.2.2 0 100 0 2000 2828 ?
*> 8.8.8.0/24 100.64.1.1 0 0 1100 7018 i
*>i10.100.100.0/24 192.168.100.100 0 100 0 i
*>i164.144.11.0/24 192.168.2.2 0 100 0 1200 123 109 ?
*> 164.144.22.0/24 100.64.11.1 0 0 2000 123 27343 i
*>i172.31.100.0/30 192.168.100.100 0 100 0 i
*> 192.168.1.1/32 0.0.0.0 0 32768 i
*>i192.168.2.2/32 192.168.2.2 0 100 0 i

RP/0/0/CPU0:XR1#
XR2
RP/0/0/CPU0:XR2# show bgp ipv4 unicast route-policy BAD-ASN
<output omitted>

*>i5.5.1.0/24 192.168.1.1 0 100 0 1100 ?
*> 8.8.4.0/24 100.64.22.1 0 0 2000 2828 ?
*>i8.8.8.0/24 192.168.1.1 0 100 0 1100 7018 i
*>i10.100.100.0/24 192.168.100.100 0 100 0 i
*>i172.31.100.0/30 192.168.100.100 0 100 0 i
*>i192.168.1.1/32 192.168.1.1 0 100 0 i
*> 192.168.2.2/32 0.0.0.0 0 32768 i

RP/0/0/CPU0:XR2#
<output omitted>

*>i5.5.1.0/24 192.168.1.1 0 100 0 1100 ?
*> 8.8.4.0/24 100.64.22.1 0 0 2000 2828 ?
*>i8.8.8.0/24 192.168.1.1 0 100 0 1100 7018 i
*>i10.100.100.0/24 192.168.100.100 0 100 0 i
*> 164.144.11.0/24 100.64.2.1 0 0 1200 123 109 ?
*>i164.144.22.0/24 192.168.1.1 0 100 0 2000 123 27343 i
*>i172.31.100.0/30 192.168.100.100 0 100 0 i
*>i192.168.1.1/32 192.168.1.1 0 100 0 i
*> 192.168.2.2/32 0.0.0.0 0 32768 i

RP/0/0/CPU0:XR2#
Notice how in the RPL test command the AS 123 prefixes (highlited in yellow) are missing from
XR1 and XR2 as expected
Step 13. Apply the RPL BAD-ASN Inbound to EBGP Peers
XR1
router bgp 100

neighbor 100.64.1.1
route-policy BAD-ASN in
commit
end
XR2
router bgp 100

neighbor 100.64.2.1
commit
end

Step 14. Verify RPL configuration
XR1

show rpl route-policy BAD-ASN attachpoints
XR2

show rpl route-policy BAD-ASN attachpoints
XR1
Wed Jan 23 22:11:54.625 UTC
router bgp 100
neighbor 100.64.1.1
remote-as 1100
!
!
!

Wed Jan 23 22:12:01.735 UTC
router bgp 100
remote-as 2000
!
!
!

Wed Jan 23 22:12:07.944 UTC


------------------------------------------
route-policy BAD-ASN
if as-path in (ios-regex '_123_') then
drop
endif
pass
end-policy

!
pass
end-policy
!
drop
endif
pass
end-policy
!

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

------------------------------------------
RP/0/0/CPU0:XR1# show rpl route-policy BAD-ASN attachpoints

Wed Jan 23 22:12:14.114 UTC

--------------------------------------------------------------------------------
100.64.1.1 -- IPv4/uni in default BAD-ASN
100.64.11.1 -- IPv4/uni in default BAD-ASN
RP/0/0/CPU0:XR1#
Notice how the policy is now applied and active
The locally generated prefix should not be advertised to EBGP neighbors
XR1

show bgp neighbor 100.64.1.1 routes
XR2


XR1
RP/0/0/CPU0:XR1# show bgp nei 100.64.1.1
Wed Jan 23 22:28:14.398 UTC
<output omitted>

Policy for incoming advertisements is BAD-ASN
Policy for outgoing advertisements is RFC1918

DC050000
RP/0/0/CPU0:XR1# show bgp nei 100.64.1.1 routes

Wed Jan 23 22:28:25.557 UTC

*> 5.5.1.0/24 100.64.1.1 0 0 1100 ?
*> 8.8.8.0/24 100.64.1.1 0 0 1100 7018 i

RP/0/0/CPU0:XR1#
XR1 is not advertising AS 123. XR2 should show also not be advertising AS 123

MPLS Configuration
Task Objective:
 Configure LDP between the following devices: XR1-XR2 and RR-1

 Verify LDP neighbor relationship is established
 Understand difference between label advertisement and label allocation filtering
Cisco Website for MPLS Switching Configuration
Step 1. Configure LDP
XR1
mpls ldp
router-id 192.168.1.1
log neighbor
interface GigabitEthernet 0/0/0/0
commit
end
XR2
mpls ldp
router-id 192.168.2.2
log neighbor
commit
end
Step 2. Verify LDP is enabled on the interfaces
XR1 and XR2
show mpls interfaces
RP/0/0/CPU0:XR1# show mpls interfaces

Wed Jan 23 22:39:32.741 UTC
Interface LDP Tunnel Static Enabled
-------------------------- -------- -------- -------- --------
GigabitEthernet0/0/0/0 Yes No No Yes
RP/0/0/CPU0:XR1#

The output above shows LDP is enabled on both interfaces
Step 3. Configure MPLS OAM on XR1 and XR2
MPLS OAM allows for Management and troubleshooting tools for MPLS switching which will be
used in this section to perform MPLS pings and traceroutes.
XR1 and XR2
mpls oam
commit
end
Step 4. Verify LDP Configuration and Functionality
XR1 and XR2
show mpls interface

show mpls ldp neighbor brief
show mpls ldp parameters
show mpls ldp summary
show mpls ldp binding brief
RP/0/0/CPU0:XR1# show mpls interface

Wed Jan 23 22:44:27.461 UTC
Interface LDP Tunnel Static Enabled
-------------------------- -------- -------- -------- --------
RP/0/0/CPU0:XR1#show mpls ldp neighbor brief
Wed Jan 23 22:44:51.090 UTC
Peer GR NSR Up Time Discovery Addresses Labels

ipv4 ipv6 ipv4 ipv6 ipv4 ipv6
----------------- -- --- ---------- ---------- ---------- ------------
192.168.100.100:0 N N 00:06:17 1 0 5 0 8 0
192.168.2.2:0 N N 00:05:46 1 0 5 0 10 0
RP/0/0/CPU0:XR1# show mpls ldp parameters

Wed Jan 23 22:44:56.949 UTC
LDP Parameters:
Role: Active
Protocol Version: 1
Router ID: 192.168.1.1
Null Label:
IPv4: Implicit
Session:
Hold time: 180 sec
Keepalive interval: 60 sec
Backoff: Initial:15 sec, Maximum:120 sec
Global MD5 password: Disabled
Discovery:

Link Hellos: Holdtime:15 sec, Interval:5 sec
Targeted Hellos: Holdtime:90 sec, Interval:10 sec
Quick-start: Enabled (by default)
Transport address:
IPv4: 192.168.1.1
Graceful Restart:
Disabled
NSR: Disabled, Not Sync-ed
Timeouts:
Housekeeping periodic timer: 10 sec
Local binding: 300 sec
Forwarding state in LSD: 15 sec
Delay in AF Binding Withdrawl from peer: 180 sec
Max:
1500 interfaces (1200 attached, 300 TE tunnel), 2000 peers
OOR state
Memory: Normal
RP/0/0/CPU0:XR1# show mpls ldp summary

Wed Jan 23 22:45:02.279 UTC
AFIs : IPv4
Routes : 10 prefixes
Bindings : 14 prefixes
Local : 10
Remote : 18
Neighbors : 2
Hello Adj : 2
Addresses : 5
Interfaces: 2 LDP configured
RP/0/0/CPU0:XR1# show mpls ldp binding brief

Wed Jan 23 22:45:08.018 UTC
Prefix Local Advertised Remote Bindings

Label (peers) (peers)
------------------ --------- ---------- ---------------
10.12.1.0/24 ImpNull 2 2
10.13.1.0/24 ImpNull 2 2
10.23.1.0/24 24001 2 2
10.100.100.0/24 - 0 1
100.64.1.0/24 ImpNull 2 1
100.64.2.0/24 - 0 1
100.64.11.0/24 ImpNull 2 0
100.64.22.0/24 24003 2 1
100.96.1.0/24 - 0 1
100.96.2.0/24 24004 2 0
172.31.100.0/30 - 0 1
192.168.1.1/32 ImpNull 2 2
192.168.2.2/32 24002 2 2
192.168.100.100/32 24000 2 2
RP/0/0/CPU0:XR1#
Step 5. Verify MPLS ping and MPLS traceroute commands
This requires MPLS OAM on all routers in the path. We already enabled it on XR1 and XR2 and it
is preconfigured on all the P routers in the lab.

XR1
ping mpls ipv4 192.168.2.2/32

traceroute mpls ipv4 192.168.2.2/32
show mpls forwarding
RP/0/0/CPU0:XR1# ping mpls ipv4 192.168.2.2/32
Sending 5, 100-byte MPLS Echos to 192.168.2.2/32,

timeout is 2 seconds, send interval is 0 msec:
Codes: '!' - success, 'Q' - request not sent, '.' - timeout,

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

Wed Jan 23 23:14:29.278 UTC
Tracing MPLS Label Switched Path to 192.168.2.2/32, timeout is 2 seconds

0 10.12.1.1 MRU 1500 [Labels: implicit-null Exp: 0]

! 1 10.12.1.2 20 ms
RP/0/0/CPU0:XR1#
RP/0/0/CPU0:XR1# show mpls forwarding

Wed Jan 23 23:16:03.081 UTC
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
24000 Pop 192.168.100.100/32 Gi0/0/0/1 10.13.1.3 9857
24001 Pop 10.23.1.0/24 Gi0/0/0/1 10.13.1.3 0
24002 Pop 192.168.2.2/32 Gi0/0/0/0 10.12.1.2 9321
24003 Unlabelled 100.64.22.0/24 Gi0/0/0/0 10.12.1.2 0
24004 Unlabelled 100.96.2.0/24 Gi0/0/0/0 10.12.1.2 0
RP/0/0/CPU0:XR1#

The implicit-null was used because XR1 and XR2 are directly connected. If you shut down the
link between the two of them, and then re-run the ping test, you will see the MPLS label between
XR1 and RR

Step 6. LDP Trace command
Just as with other protocols, LDP also has a tracing functionality for troubleshooting purposes.
To see all options available execute the command:
show mpls ldp trace ?
RP/0/0/CPU0:XR1# show mpls ldp trace ?

binding LDP binding event traces(cisco-support)
capabilities LDP Capabilities event traces(cisco-support)
config LDP configuration event traces(cisco-support)
dev LDP development private traces(cisco-support)
discovery LDP Hello/discovery and adj event traces(cisco-support)
error LDP error traces(cisco-support)
file Specific file(cisco-support)
forwarding LDP forwarding event traces(cisco-support)
gr LDP graceful-restart event traces(cisco-support)
hexdump Display traces in hexadecimal(cisco-support)
iccp LDP ICCP signaling event traces(cisco-support)
igp-sync LDP IGP sync event traces(cisco-support)
interface LDP interface event traces(cisco-support)
last Display last <n> entries(cisco-support)
location Card location(cisco-support)
misc LDP miscellaneous event traces(cisco-support)
mldp LDP mLDP event traces(cisco-support)
nsr LDP non-stop routing event traces(cisco-support)
peer LDP peer session event traces(cisco-support)
process LDP process-level event traces(cisco-support)
pw LDP L2VPN pseudo-wire event traces(cisco-support)
reverse Display latest traces first(cisco-support)
route LDP route event traces(cisco-support)
since show traces from(cisco-support)
stats Display statistics(cisco-support)
tailf Display new traces as they are added(cisco-support)
unique Unique entries with counts(cisco-support)
usec Display timestamp w/usec detail(cisco-support)
verbose Display internal debugging information(cisco-support)
vrf LDP VRF event traces(cisco-support)
wide Dont display buffer name, node name, tid(cisco-support)
wrapping Wrapping entries(cisco-support)
| Output Modifiers
<cr>
RP/0/0/CPU0:XR1#

MPLS L3VPN (Optional)
Local VRF Configuration
Task Objective:
 Define VRF VPN_01 & VPN_02 on XR1 & XR2

 Set Route Targets Import/Export of VPN_01 to 100:1
 Set Route Targets Import/Export of VPN_02 to 100:2
 Create Loopbacks 100 & 101, assign VRFs to the interfaces listed below and assign the
proper IP addresses as shown in the table below.
 Verify local connectivity for each VRF
Node VRF Interface 1 IP Address Interface 2 IP Address
XR1 VPN_01 Lo 100 192.168.10.1/24 Gi0/0/0/4.10 192.168.1.254/24
XR1 VPN_02 Lo 101 172.16.10.1/24 Gi0/0/0/4.20 172.16.1.254/24
XR2 VPN_01 Lo 100 192.168.20.1/24 Gi0/0/0/4.10 192.168.2.254/24
XR2 VPN_02 Lo 101 172.16.20.1/24 Gi0/0/0/4.20 172.16.2.254/24
Cisco Website for IOS-XR MPLS L3 VPN
Step 1. Configure VRF VPN_01 & VPN_02
In IOS, if an IP address is already programmed when you associate a VRF to an interface, it

removes the IP address automatically. In IOS-XR, you have to do this manually.
XR1
vrf VPN_01
import route-target 100:1
export route-target 100:1
vrf VPN_02
interface Loopback100

vrf VPN_01
ipv4 address 192.168.10.1 255.255.255.0
interface GigabitEthernet0/0/0/4.10
vrf VPN_01
ipv4 address 192.168.1.254 255.255.255.0
encapsulation dot1q 10
vrf VPN_02
ipv4 address 172.16.10.1 255.255.255.0
vrf VPN_02
ipv4 address 172.16.1.254 255.255.255.0
no shutdown
commit
end
XR2
vrf VPN_01
vrf VPN_02
vrf VPN_01
ipv4 address 192.168.20.1 255.255.255.0
vrf VPN_01
ipv4 address 192.168.2.254 255.255.255.0
vrf VPN_02
ipv4 address 172.16.20.1 255.255.255.0

vrf VPN_02
ipv4 address 172.16.2.254 255.255.255.0
no shutdown
commit
end
Step 2. Verify VRF Configuration
To see all the VRFs (including the default (global)), the word ‘all’ can be used in the following
show commands
show vrf <vrf name>

show ipv4 vrf <vrf name> int br
show route vrf <vrf name>
RP/0/0/CPU0:XR1# show vrf all
VRF RD RT AFI SAFI

Management not set
VPN_01 not set
import 100:1 IPV4 Unicast
export 100:1 IPV4 Unicast
VPN_02 not set
import 100:2 IPV4 Unicast
export 100:2 IPV4 Unicast
RP/0/0/CPU0:XR1# show ipv4 vrf all int brief
Interface IP-Address Status Protocol Vrf-Name

Loopback0 192.168.1.1 Up Up default
Loopback100 192.168.10.1 Up Up VPN_01
MgmtEth0/0/CPU0/0 198.18.1.10 Up Up Management
GigabitEthernet0/0/0/0 10.12.1.1 Up Up default
GigabitEthernet0/0/0/4 unassigned Up Up default
GigabitEthernet0/0/0/4.10 192.168.1.254 Up Up VPN_01
RP/0/0/CPU0:XR1# show route vrf all
VRF: **nVSatellite

L 10.0.0.1/32 is directly connected, 23:53:58, nV-Loopback0

L 10.0.0.2/32 is directly connected, 23:53:58, nV-Loopback1
VRF: Management

Gateway of last resort is 198.18.1.1 to network 0.0.0.0
S* 0.0.0.0/0 [1/0] via 198.18.1.1, 09:23:12

C 198.18.1.0/24 is directly connected, 09:23:12, MgmtEth0/0/CPU0/0
L 198.18.1.10/32 is directly connected, 09:23:12, MgmtEth0/0/CPU0/0
VRF: VPN_01

C 192.168.1.0/24 is directly connected, 00:07:48, GigabitEthernet0/0/0/4.10

L 192.168.1.254/32 is directly connected, 00:07:48, GigabitEthernet0/0/0/4.10
C 192.168.10.0/24 is directly connected, 00:07:48, Loopback100
VRF: VPN_02



RP/0/0/CPU0:XR1#
In IOS XR, VRFs RD are configured under the BGP configuration. This is demonstrated later in
this lab
Step 3. Verify VRF Connectivity. Ping VRF Local CEs
XR1
ping vrf VPN_01 192.168.1.1

ping vrf VPN_02 172.16.1.1
XR2
ping vrf VPN_01 192.168.2.1

ping vrf VPN_02 172.16.2.1

XR1
RP/0/0/CPU0:XR1# ping vrf VPN_01 192.168.1.1

!!!!!

!!!!!
RP/0/0/CPU0:XR1#
XR2

!!!!!

!!!!!
RP/0/0/CPU0:XR2#

BGP VPNv4 Configuration (Optional)
Task Objective:
 Initialize the VPNv4 Address Family
 Establish a VPNv4 BGP session with the route-reflector 192.168.100.100 (RR-1)
 Initialize the IPv4 Address family for both VRFs, and redistribute connected networks into it
 Verify routes are exchanged between the nodes, and that connectivity from VRF Loopback
to VRF Loopback exists
Step 4. Create BGP 100 process, and configure BGP sessions to the RR-1
XR1 and XR2
router bgp 100

address-family vpnv4 unicast
neighbor 192.168.100.100
address-family vpnv4 unicast
!
vrf VPN_01
rd 100:1
redistribute connected
!
vrf VPN_02
rd 100:2
commit
end
In IOS XR the VRF RDs are set under the BGP vrf configuration
The addres-family command initializes the VPNv4 Address family on the router
Step 5. Verify VPNv4 routes have been exchanged
To see all the VRFs (including the default (global)), the word ‘all’ can be used in the following
show commands.
show bgp vpnv4 unicast summary

show bgp vpnv4 unicast vrf <vrf name>
show bgp vrf <vrf name> summary
show ipv4 vrf <vrf name> interface brief

RP/0/0/CPU0:XR1# show bgp vpnv4 unicast summary
Thu Jan 24 00:09:25.832 UTC
Table ID: 0x0 RD version: 0
BGP NSR Initial initsync version 11 (Not Reached)

Speaker 19 19 19 19 19 0

192.168.100.100 0 100 452 416 19 0 0 00:00:52 4
RP/0/0/CPU0:XR1#show bgp vpnv4 unicast vrf VPN_01

Thu Jan 24 00:13:19.426 UTC

Route Distinguisher: 100:1 (default for vrf VPN_01)
*> 192.168.1.0/24 0.0.0.0 0 32768 ?
*>i192.168.2.0/24 192.168.2.2 0 100 0 ?
*> 192.168.10.0/24 0.0.0.0 0 32768 ?
*>i192.168.20.0/24 192.168.2.2 0 100 0 ?
RP/0/0/CPU0:XR1#show bgp vpnv4 unicast vrf VPN_02

Thu Jan 24 00:13:29.215 UTC


*> 172.16.1.0/24 0.0.0.0 0 32768 ?
*>i172.16.2.0/24 192.168.2.2 0 100 0 ?
*> 172.16.10.0/24 0.0.0.0 0 32768 ?
*>i172.16.20.0/24 192.168.2.2 0 100 0 ?

RP/0/0/CPU0:XR1#
RP/0/0/CPU0:XR1# show bgp vrf all summary

Thu Jan 24 00:09:40.131 UTC
VRF: VPN_01
-----------
BGP VRF VPN_01, state: Active
BGP Route Distinguisher: 100:1
VRF ID: 0x60000004

Speaker 19 19 19 19 19 0
VRF: VPN_02
-----------
VRF ID: 0x60000005

Speaker 19 19 19 19 19 0
RP/0/0/CPU0:XR1# show ipv4 vrf all interface brief

Thu Jan 24 00:10:01.960 UTC
Interface IP-Address Status Protocol Vrf-Name

Loopback0 192.168.1.1 Up Up default
MgmtEth0/0/CPU0/0 198.18.1.10 Up Up Management

GigabitEthernet0/0/0/4 unassigned Up Up default
RP/0/0/CPU0:XR1# show route vrf all
<output omitted>
VRF: VPN_01


B 192.168.2.0/24 [200/0] via 192.168.2.2 (nexthop in vrf default), 00:01:33
VRF: VPN_02


RP/0/0/CPU0:XR1#

Step 6. Verify connectivity across the core for both VRFs
XR1 pings 192.168.2.254 (remote CE device connected to XR2) in VPN_01
ping vrf VPN_01 192.168.2.254
XR2 pings 172.16.1.254 (remote CE device connected to XR1) in VPN_02
ping vrf VPN_02 172.16.1.254
XR1
Thu Jan 24 00:20:23.487 UTC
!!!!!
RP/0/0/CPU0:XR1#
XR2
Thu Jan 24 00:20:32.956 UTC
!!!!!
RP/0/0/CPU0:XR2#

BGP PE-CE Configuration
Task Objective:
 On XR1 and XR2 configure a BGP session on VRF VPN_01 as indicated in the table below
 Verify that routes have been exchanged, and connectivity is successful across the core.
 CE devices are preconfigured.
PE VRF / CE CE IP Address CE Remote-AS
XR1 VPN_01 192.168.1.1 200
XR2 VPN_01 192.168.2.1 200
Step 7. Configure BGP as PE-CE Routing Protocol
XR1
router bgp 100

vrf VPN_01
remote-as 200
as-override
commit
end
XR2
router bgp 100

vrf VPN_01
remote-as 200
as-override
commit
end

Step 8. Verify BGP adjacency to CE as well as reachability
show run router bgp <AS> vrf <vrf name>

show bgp vrf <vrf name> summary
show bgp vrf <vrf name>
RP/0/0/CPU0:XR1# show run router bgp 100 vrf VPN_01

Thu Jan 24 03:42:45.315 UTC
router bgp 100
vrf VPN_01
rd 100:1
!
remote-as 200
as-override
!
!
!
!
RP/0/0/CPU0:XR1# show bgp vrf VPN_01 summary

Thu Jan 24 03:42:55.304 UTC
VRF ID: 0x60000004

Speaker 22 22 22 22 22 0

192.168.1.1 0 200 6 7 22 0 0 00:01:03 2
RP/0/0/CPU0:XR1# show bgp vrf VPN_01

Thu Jan 24 03:43:15.373 UTC
VRF ID: 0x60000004

*> 192.168.1.0/24 0.0.0.0 0 32768 ?
* 192.168.1.1 0 0 200 ?
*>i192.168.2.0/24 192.168.2.2 0 100 0 ?
*> 192.168.10.0/24 0.0.0.0 0 32768 ?
*>i192.168.20.0/24 192.168.2.2 0 100 0 ?
*> 192.168.100.0/24 192.168.1.1 0 0 200 ?
*>i192.168.200.0/24 192.168.2.2 0 100 0 200 ?
RP/0/0/CPU0:XR1# show route vrf VPN_01

Thu Jan 24 03:43:52.171 UTC

D - EIGRP, EX - EIGRP exter`nal, O - OSPF, IA - OSPF inter area

B 192.168.100.0/24 [20/0] via 192.168.1.1, 00:02:00
RP/0/0/CPU0:XR1#
Notice the 192.168.100.0/24 and 192.168.200.0/24 routes have been added. Each route was
learned from a CE_Device. The Next-Hop IP address should help you identify which XR router the
route was learned from
Step 9. Verify connectivity across the Core
XR1
ping vrf VPN_01 192.168.200.1
XR2
ping vrf VPN_01 192.168.100.1

XR1
Thu Jan 24 03:53:57.799 UTC
!!!!!
RP/0/0/CPU0:XR1#
XR2
Thu Jan 24 03:54:23.207 UTC
!!!!!
RP/0/0/CPU0:XR2#

OSPF PE-CE Configuration
Task Objective:
 On XR1 and XR2 configure OSPF Process 100 for VRF VPN_02
 Mutually redistribute routes between OSPF and BGP
 Verify that routes have been exchanged, and connectivity is successful across the
core.
 CE devices are already preconfigured.
PE VRF / CE Interfaces OSPF Area
XR1 VPN_02 Gi0/0/0/4 , Lo101 1
XR2 VPN_02 Gi0/0/0/4 , Lo101 2
Step 10. Configure OSPF as PE-CE Routing Protocol
We changed the OSPF process from what the global routing table is using (router ospf 1). It is
possible to use the same process number as the global table. We are just making it easier for you
to read 
XR1 and XR2
router ospf 100

vrf VPN_02
redistribute bgp 100
area 0
router bgp 100

vrf VPN_02
redistribute ospf 100
commit
end

Step 11. Verify OSPF Adjacency to CE and Reachability
show run router ospf <process> vrf <vrf name>

show ospf vrf <vrf name> interface brief
show ospf vrf <vrf name> neighbor
show run router ospf 100 vrf VPN_02

show ospf vrf VPN_02 interface brief
show ospf vrf VPN_02 neighbor
show route vrf VPN_02
RP/0/0/CPU0:XR1# show run router ospf 100 vrf VPN_02

Thu Jan 24 04:19:43.843 UTC
router ospf 100
vrf VPN_02
redistribute bgp 100
area 0
!
!
!
!
!
RP/0/0/CPU0:XR1# show ospf vrf VPN_02 interface brief

Thu Jan 24 04:19:54.572 UTC
* Indicates MADJ interface, (P) Indicates fast detect hold down state
Interfaces for OSPF 100, VRF VPN_02
Interface PID Area IP Address/Mask Cost State Nbrs F/C

Lo101 100 0 172.16.10.1/24 1 LOOP 0/0
Gi0/0/0/4.20 100 0 172.16.1.254/24 1 BDR 1/1
RP/0/0/CPU0:XR1# show ospf vrf VPN_02 neighbor

Thu Jan 24 04:20:02.902 UTC
* Indicates MADJ interface

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

172.16.100.1 1 FULL/DR 00:00:32 172.16.1.1 GigabitEthernet0/0/0/4.20
Total neighbor count: 1
RP/0/0/CPU0:XR1# show route vrf VPN_02

Thu Jan 24 04:20:09.271 UTC



O 172.16.100.1/32 [110/2] via 172.16.1.1, 00:07:12, GigabitEthernet0/0/0/4.20
RP/0/0/CPU0:XR1#
XR1
ping vrf VPN_02 172.16.200.1
XR2
ping vrf VPN_02 172.16.100.1
XR1
Thu Jan 24 04:24:32.503 UTC
!!!!!
RP/0/0/CPU0:XR1#
XR2
Thu Jan 24 04:24:54.322 UTC
!!!!!
RP/0/0/CPU0:XR2#

MPLS Traffic Engineering (Optional)
Task Objective:
 Enable RSVP on all core interfaces; set the RSVP reservation to 10 Mbps
 Enable MPLS TE on all core interfaces.
 Configure MPLS TE to re-optimize after 60 seconds.
 Configure OSPF (Area 0) for MPLS TE on XR1 and XR2.
 RR-1 has been pre-configured
Cisco Web Site for MPLS Traffic Engineering
Step 1. Configure RSVP to 10Mbps
XR1 and XR2
rsvp
bandwidth 10 Mbps
bandwidth 10 Mbps
commit
end
Step 2. Validate RSVP is operational
show rsvp interface
RP/0/0/CPU0:XR1# show rsvp interface
*: RDM: Default I/F B/W % : 75% [default] (max resv/bc0), 0% [default] (bc1)
Interface MaxBW (bps) MaxFlow (bps) Allocated (bps) MaxSub (bps)

----------- ------------ ------------- -------------------- -------------
Gi0/0/0/0 10M 10M 0 ( 0%) 0
Gi0/0/0/1 10M 10M 0 ( 0%) 0
RP/0/0/CPU0:XR1#

Step 3. Enable MPLS TE on relevant interfaces
XR1 and XR2
mpls traffic-eng
reoptimize 60
commit
end
Step 4. Validate MPLS-TE was enabled on the interfaces
show mpls traffic-eng link-management interfaces | i Link ID
RP/0/0/CPU0:XR1# show mpls traffic-eng link-management interfaces | i Link ID

Thu Jan 24 04:42:00.312 UTC
Link ID:: GigabitEthernet0/0/0/0 (10.12.1.1)
Link ID:: GigabitEthernet0/0/0/1 (10.13.1.1)
RP/0/0/CPU0:XR1#
Step 5. Enable the IGP protocol (OSPF) for MPLS-TE
XR1 and XR2
router ospf 1
area 0
mpls traffic-eng
mpls traffic-eng router-id Loopback0
commit
end

Dynamic Path (Optional)
Task Objective:
 On XR1, create interface Tunnel-TE 12 interface with a destination of 192.168.2.2
 On XR2, create interface Tunnel-TE 21 interface with a destination of 192.168.1.1
 On all TE tunnels, set the bandwidth to 2 Mbps, IPv4 Unumbered to Loopback 0, Path-
Option 10 with Dynamic
 Verify the tunnels and that traffic is forwarded on the tunnels
Step 1. Create MPLS-TE Tunnels
Note: This section requires the section MPLS Traffic Engineering to be completed
XR1
interface tunnel-te12
bandwidth 2000
ipv4 unnumbered Loopback0
destination 192.168.2.2
path-option 10 dynamic
no shut
commit
end
XR2
bandwidth 2000
path-option 10 dynamic
no shut
commit
end
Step 2. Verify MPLS-TE Tunnels are up
It may take a few seconds for the tunnels to come up
show mpls traffic-eng tunnels brief

show mpls traffic-eng tunnels tabular

RP/0/0/CPU0:XR1# show mpls traffic-eng tunnels brief
TUNNEL NAME DESTINATION STATUS STATE

tunnel-te12 192.168.2.2 up up
XR2_t21 192.168.1.1 up up
Displayed 1 (of 1) heads, 0 (of 0) midpoints, 1 (of 1) tails
Displayed 1 up, 0 down, 0 recovering, 0 recovered heads
RP/0/0/CPU0:XR1# show mpls traffic-eng tunnels tabular
Tunnel LSP Destination Source Tun FRR LSP Path

Name ID Address Address State State Role Prot
----------------- ----- --------------- --------------- ------ ------ ---- -----
tunnel-te12 2 192.168.2.2 192.168.1.1 up Inact Head Inact
XR2_t21 2 192.168.1.1 192.168.2.2 up Inact Tail
RP/0/0/CPU0:XR1#
From XR1, ping and trace the MLPS-TE tail end
ping mpls traffic-eng tunnel-te 12

trace mpls traffic-eng tunnel-te 12

XR1
RP/0/0/CPU0:XR1# ping mpls traffic-eng tunnel-te 12

Thu Jan 24 05:04:03.571 UTC
Sending 5, 100-byte MPLS Echos to tunnel-te12,


!!!!!
RP/0/0/CPU0:XR1# trace mpls traffic-eng tunnel-te 12

Thu Jan 24 05:04:12.290 UTC

Tracing MPLS TE Label Switched Path on tunnel-te12, timeout is 2 seconds


! 1 10.12.1.2 10 ms
RP/0/0/CPU0:XR1#
XR2

Thu Jan 24 05:05:06.986 UTC


!!!!!

Thu Jan 24 05:05:16.056 UTC


! 1 10.12.1.1 10 ms
RP/0/0/CPU0:XR2#

Explicit Path (Optional)
Task Objective:
 On XR1, create interface Tunnel-TE 132 with a destination of 192.168.2.2
 On XR2, create interface Tunnel-TE 231 with a destination of 192.168.1.1
 On all TE tunnels, set the bandwidth to 2 Mbps, IPv4 Unnumbered to Loopback 0, and explicit
path per the chart provided below
 Verify the tunnels and that traffic is forwarded on the tunnels
Tunnel Explicit Path Exact Hops
132 XR1-RR-XR2 10.13.1.3 — 10.23.1.2
231 XR2-RR-XR1 10.23.1.3 – 10.13.1.1
Step 1. Build MPLS-TE Explicit Paths
Note: This section requires the section MPLS Traffic Engineering to be completed
XR1
explicit-path name XR1-XR2

index 1 next-address strict ipv4 unicast 10.13.1.3
XR2
explicit-path name XR2-XR1


Step 2. Create MPLS-TE Tunnel Interface for Explicit Paths
XR1
bandwidth 2000
path-option 10 explicit name XR1-XR2
no shut
commit
end
XR2
bandwidth 2000
path-option 10 explicit name XR2-XR1
no shut
commit
end
Step 3. Verify MPLS-TE Explicit Path Tunnels come up
XR1

show mpls traffic-eng tunnels 132
XR2

show mpls traffic-eng tunnels 231

XR1
Thu Jan 24 05:17:14.987 UTC

----------------- ----- --------------- --------------- ------ ------ ---- -----
XR2_t21 2 192.168.1.1 192.168.2.2 up Inact Tail
XR2_t231 2 192.168.1.1 192.168.2.2 up Inact Tail
RP/0/0/CPU0:XR1# show mpls traffic-eng tunnels 132

Thu Jan 24 05:17:26.136 UTC
Name: tunnel-te132 Destination: 192.168.2.2 Ifhandle:0x980

Signalled-Name: XR1_t132
Status:
Admin: up Oper: up Path: valid Signalling: connected
path option 10, type explicit XR1-XR2 (Basis for Setup, path weight 101)
G-PID: 0x0800 (derived from egress interface properties)
Bandwidth Requested: 0 kbps CT0
Creation Time: Thu Jan 24 05:14:12 2019 (00:03:14 ago)
Config Parameters:
Bandwidth: 0 kbps (CT0) Priority: 7 7 Affinity: 0x0/0xffff
Metric Type: TE (default)
Path Selection:
Tiebreaker: Min-fill (default)
Hop-limit: disabled
Cost-limit: disabled
Path-invalidation timeout: 45000 msec (default), Action: Tear (default)
AutoRoute: disabled LockDown: disabled Policy class: not set
Forward class: 0 (default)
Forwarding-Adjacency: disabled
Loadshare: 0 equal loadshares
Auto-bw: disabled
Fast Reroute: Disabled, Protection Desired: None
Path Protection: Not Enabled
BFD Fast Detection: Disabled
Reoptimization after affinity failure: Enabled
Soft Preemption: Disabled
History:
Tunnel has been up for: 00:03:13 (since Thu Jan 24 05:14:13 UTC 2019)
Current LSP:
Uptime: 00:03:13 (since Thu Jan 24 05:14:13 UTC 2019)
Reopt. LSP:
Last Failure:
LSP not signalled, identical to the [CURRENT] LSP
Date/Time: Thu Jan 24 05:14:25 UTC 2019 [00:03:01 ago]
Path info (OSPF 1 area 0):

Node hop count: 2
Hop0: 10.13.1.3
Hop1: 10.23.1.2
Hop2: 192.168.2.2
RP/0/0/CPU0:XR1#

XR2

----------------- ----- --------------- --------------- ------ ------ ---- -----
XR1_t12 2 192.168.2.2 192.168.1.1 up Inact Tail
XR1_t132 2 192.168.2.2 192.168.1.1 up Inact Tail
RP/0/0/CPU0:XR2# show mpls traffic-eng tunnels 231

Thu Jan 24 05:18:29.761 UTC
Name: tunnel-te231 Destination: 192.168.1.1 Ifhandle:0x880

Signalled-Name: XR2_t231
Status:
Admin: up Oper: up Path: valid Signalling: connected
path option 10, type explicit XR2-XR1 (Basis for Setup, path weight 101)
G-PID: 0x0800 (derived from egress interface properties)
Bandwidth Requested: 0 kbps CT0
Creation Time: Thu Jan 24 05:14:27 2019 (00:04:02 ago)
Config Parameters:
Bandwidth: 0 kbps (CT0) Priority: 7 7 Affinity: 0x0/0xffff
Metric Type: TE (default)
Path Selection:
Tiebreaker: Min-fill (default)
Hop-limit: disabled
Cost-limit: disabled
Path-invalidation timeout: 45000 msec (default), Action: Tear (default)
AutoRoute: disabled LockDown: disabled Policy class: not set
Forward class: 0 (default)
Forwarding-Adjacency: disabled
Loadshare: 0 equal loadshares
Auto-bw: disabled
Fast Reroute: Disabled, Protection Desired: None
Path Protection: Not Enabled
BFD Fast Detection: Disabled
Reoptimization after affinity failure: Enabled
Soft Preemption: Disabled
History:
Tunnel has been up for: 00:04:02 (since Thu Jan 24 05:14:27 UTC 2019)
Current LSP:
Uptime: 00:04:02 (since Thu Jan 24 05:14:27 UTC 2019)
Reopt. LSP:
Last Failure:
LSP not signalled, identical to the [CURRENT] LSP
Date/Time: Thu Jan 24 05:14:31 UTC 2019 [00:03:58 ago]
Path info (OSPF 1 area 0):

Node hop count: 2
Hop0: 10.23.1.3
Hop1: 10.13.1.1
Hop2: 192.168.1.1
RP/0/0/CPU0:XR2#



XR1
Thu Jan 24 05:26:12.120 UTC


!!!!!

Thu Jan 24 05:26:22.199 UTC

0 10.13.1.1 MRU 1500 [Labels: 19 Exp: 0]

L 1 10.13.1.3 MRU 1504 [Labels: implicit-null Exp: 0] 20 ms
! 2 10.23.1.2 1 ms
RP/0/0/CPU0:XR1#

XR2
Thu Jan 24 05:26:59.796 UTC


!!!!!

Thu Jan 24 05:27:10.596 UTC

0 10.23.1.2 MRU 1500 [Labels: 20 Exp: 0]

L 1 10.23.1.3 MRU 1504 [Labels: implicit-null Exp: 0] 10 ms
! 2 10.13.1.1 1 ms
RP/0/0/CPU0:XR2#

Advanced RPLs (Optional)
Multiple Action Policies
Task Objective:
 Create a new RPL called INBOUND that does the following:

o Discard all routes that match the PREFIX-SET-RFC1918
o All routes originating from AS 1100 received from AS 7018 set the Local Preference
to 7018
o All routes originating from AS 2000 received from AS 2828 set the Local Preference
to 2828
o All other routes should receive a local-preference of 1000
 Apply the RPL inbound to EBGP Peers & Verify the BGP Table
 Correct the problem and verify.
Step 1. Create the RPL INBOUND on XR1 and XR2
XR1
10.0.0.0/8 ge 8,
172.16.0.0/12 ge 12,
192.168.0.0/16 ge 16
end-set
route-policy INBOUND
drop
endif
if as-path originates-from '2828' exact and as-path neighbor-is '2000' exact then
set local-preference 2828
elseif as-path originates-from '7018' exact and as-path neighbor-is '1100' exact then
endif
end-policy
commit

XR2
Note: Prefix set PREFIX-SET-RFC1918 should already be configured on XR2 from the Basic
Route Policy Language Section, so there is no need to configure it again
drop
endif
endif
end-policy
commit
Step 2. Apply the RPL inbound to EBGP Peers
XR1
router bgp 100

neighbor 100.64.1.1
route-policy INBOUND in
commit
end
XR2
router bgp 100

neighbor 100.64.2.1

commit
end
Step 3. Perform a Soft Reset and verify the intended results
clear bgp ipv4 unicast * soft

RP/0/0/CPU0:XR1# clear bgp ipv4 unicast * soft

Thu Jan 24 05:53:37.887 UTC

Thu Jan 24 05:53:47.767 UTC

*> 5.5.1.0/24 100.64.1.1 0 1000 0 1100 ?
* 100.64.11.1 0 1000 0 2000 ?
*>i8.8.4.0/24 192.168.2.2 0 1000 0 2000 2828 ?
*> 8.8.8.0/24 100.64.1.1 0 1000 0 1100 7018 i
*>i10.100.100.0/24 192.168.100.100 0 100 0 i
*>i164.144.11.0/24 192.168.2.2 0 1000 0 1200 123 109 ?
*> 164.144.22.0/24 100.64.11.1 0 1000 0 2000 123 27343 i
*>i172.31.100.0/30 192.168.100.100 0 100 0 i
*> 192.168.1.1/32 0.0.0.0 0 32768 i
*>i192.168.2.2/32 192.168.2.2 0 100 0 i

RP/0/0/CPU0:XR1#
Notice that the highlighted values have a local preference of 1000 when they should have either
7018 or 2828 for the local preference.
The reason that the local preference is set to 1000 is that once the local preference was set to
7018 or 2828 on the RPL; it was overwritten in the next step. Adding the keyword ‘DONE’ to the
RPL will stop processing further events as shown in the following step.

Step 4. Correct the RPL
XR1 and XR2
drop
endif
done
done
endif
end-policy
commit
end
Another option is to use an additional ‘else’ command so that other processing can continue if
desired. In our example, we wanted to emphasize that ‘done’ can be used to break out of the RPL
and keep it from executing any further actions.
drop
endif
else
endif
end-policy
commit
end
Step 5. Perform a Soft Reset and verify the intended results
clear bgp ipv4 unicast * soft


RP/0/0/CPU0:XR1# clear bgp ipv4 unicast * soft
Thu Jan 24 06:01:23.745 UTC

Thu Jan 24 06:01:33.954 UTC

*>i5.5.1.0/24 192.168.1.1 0 1000 0 1100 ?
*> 8.8.4.0/24 100.64.22.1 0 2828 0 2000 2828 ?
*>i8.8.8.0/24 192.168.1.1 0 7018 0 1100 7018 i
*>i10.100.100.0/24 192.168.100.100 0 100 0 i
*> 164.144.11.0/24 100.64.2.1 0 1000 0 1200 123 109 ?
*>i164.144.22.0/24 192.168.1.1 0 1000 0 2000 123 27343 i
*>i172.31.100.0/30 192.168.100.100 0 100 0 i
*>i192.168.1.1/32 192.168.1.1 0 100 0 i
*> 192.168.2.2/32 0.0.0.0 0 32768 i

RP/0/0/CPU0:XR2#
After correcting the mistake, the Local Preference was set correctly

Nested Policies (Optional)
Task Objective:
 Modify the RPL INBOUND to achieve the following:
 Apply the RFC1918 RPL to:
o Set the Local Preference to 109 on all routes originating from AS 109 received from AS
1200
o Set the Local Preference to 27343 on all routes originating from AS 27343 received
from AS 2000
 Apply the PASS-ALL RPL as the last action
Step 1. Modify the RPL INBOUND
In this step, we will apply the RFC1918 RPL we configured at the beginning of this lab in the Basic
RPL Configuration section inside the INBOUND RPL and then we will use a show command to
see what this looks like behind the scenes
This is the original INBOUND RPL that is currently configured and we’ll replace the highlighted
section with the RFC1918 RPL which will achieve the same result
drop
endif
else
endif
end-policy
Execute the following commands to replace the section highlighted in yellow above with the
RFC1918 RPL
XR1 and XR2
apply RFC1918
done

done
endif
apply PASS-ALL
end-policy
commit
end
Step 2. Verify what the INBOUND RPL looks like behind the scene
show rpl route-policy INBOUND inline
RP/0/0/CPU0:XR1# show rpl route-policy INBOUND inline

Thu Jan 24 06:27:25.861 UTC
# apply RFC1918
drop
endif
pass
# end-apply RFC1918
if as-path exact-originates-from 109 and as-path exact-neighbor-is 1200 then
assign local-preference 109
done
elseif as-path exact-originates-from 27343 and as-path exact-neighbor-is 2000 then
assign local-preference 27343
done
endif
# apply PASS-ALL
pass
# end-apply PASS-ALL
end-policy
!
RP/0/0/CPU0:XR1#
Step 3. Verify the routes and PASS-ALL RPLs

show rpl route-policy PASS-ALL attachpoints
show rpl route-policy PASS-ALL references

Thu Jan 24 06:30:00.300 UTC


*> 5.5.1.0/24 100.64.1.1 0 0 1100 ?
* 100.64.11.1 0 0 2000 ?
*>i8.8.4.0/24 192.168.2.2 0 100 0 2000 2828 ?
*> 8.8.8.0/24 100.64.1.1 0 0 1100 7018 i
*>i10.100.100.0/24 192.168.100.100 0 100 0 i
*>i164.144.11.0/24 192.168.2.2 0 109 0 1200 123 109 ?
*> 164.144.22.0/24 100.64.11.1 0 27343 0 2000 123 27343 i
*>i172.31.100.0/30 192.168.100.100 0 100 0 i
*> 192.168.1.1/32 0.0.0.0 0 32768 i
*>i192.168.2.2/32 192.168.2.2 0 100 0 i

Thu Jan 24 06:30:15.289 UTC


------------------------------------------
apply RFC1918
done
done
endif
apply PASS-ALL
end-policy
!
pass
end-policy
!
drop
endif
pass
end-policy
!

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

------------------------------------------
route-policy BAD-ASN
if as-path in (ios-regex '_123_') then

drop
endif
pass
end-policy
!
RP/0/0/CPU0:XR1# show rpl route-policy PASS-ALL attachpoints

Thu Jan 24 06:30:26.479 UTC

--------------------------------------------------------------------------------
100.64.11.1 -- IPv4/uni out default PASS-ALL
192.168.1.1 -- IPv4/uni in VPN_01 PASS-ALL
192.168.1.1 -- IPv4/uni out VPN_01 PASS-ALL
100.64.1.1 -- IPv4/uni in default INBOUND
100.64.11.1 -- IPv4/uni in default INBOUND
RP/0/0/CPU0:XR1# show rpl route-policy PASS-ALL references

Thu Jan 24 06:30:35.158 UTC
Usage Direct -- Reference occurs in this policy

Usage Indirect -- Reference occurs via an apply statement
Status UNUSED -- Policy is not in use at an attachpoint (unattached)

Status ACTIVE -- Policy is actively used at an attachpoint
Status INACTIVE -- Policy is applied by an unattached policy
Usage/Status count
--------------------------------------------------------------
Direct 1
Indirect 0
ACTIVE 1
INACTIVE 0
UNUSED 0
Usage Status Route-policy

--------------------------------------------------------------
Direct ACTIVE INBOUND
RP/0/0/CPU0:XR1#
Congratulations on finishing the lab, hope you enjoyed it!!
Please, don’t forget to provide feedback 


LTRARC-2002 Introduction To IOS-XR Lab Guide: Speakers: Brad Edgeworth Ramiro Garza Rios Rajesh Patki

Uploaded by

Document Information

Original Description:

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

LTRARC-2002 Introduction To IOS-XR Lab Guide: Speakers: Brad Edgeworth Ramiro Garza Rios Rajesh Patki

Uploaded by

Copyright:

Available Formats

LTRARC-2002

Introduction to IOS-XR Lab Guide

LTRARC-2002 Introduction to IOS XR Lab Guide

LTRARC-2002 Introduction to IOS XR Lab Guide

LTRARC-2002 Introduction to IOS XR Lab Guide 3|Page

AS 1100 AS 2000 AS 1200

g0/1.10 192.168.1.0/24 g0/0/0/4.10 g0/0/0/0 10.12.1.0/24 g0/0/0/0 g0/0/0/4.10 192.168.2.0/24 g0/1.10

 IP Addresses are preconfigured.

LTRARC-2002 Introduction to IOS XR Lab Guide 4|Page

1. Access to the lab is obtained by launching Anyconnect and connecting to:

LTRARC-2002 Introduction to IOS XR Lab Guide 5|Page

Launch PuttyCM icon on your desktop

LTRARC-2002 Introduction to IOS XR Lab Guide 6|Page

Using XR1 perform the following tasks

 Demonstrate changes around the interface and route statements

Step 1. Show the existing IPv4 addresses

show ip interface brief

RP/0/0/CPU0:XR1# show ip interface brief

Interface IP-Address Status Protocol

RP/0/0/CPU0:XR1# show ipv4 int brief

Interface IP-Address Status Protocol

Note: Some commands in IOS-XR require you to specify IPv4/IPv6

LTRARC-2002 Introduction to IOS XR Lab Guide 7|Page

RP/0/0/CPU0:XR1# show route

Codes: C - connected, S - static, R - RIP, B - BGP, (>) - Diversion path

C 10.12.1.0/24 is directly connected, 13:20:53, GigabitEthernet0/0/0/0

Step 3. Demonstrate parsing elements

show run | include "interface|ipv4"

RP/0/0/CPU0:XR1# show run | include "interface|ipv4"

LTRARC-2002 Introduction to IOS XR Lab Guide 8|Page

Step 4. Additional parsing utilities

RP/0/0/CPU0:XR1# show run | ?

RP/0/0/CPU0:XR1# show run | utility ?

LTRARC-2002 Introduction to IOS XR Lab Guide 9|Page

Step 6. Find Configuration Commit ID

show configuration commit list

RP/0/0/CPU0:CiscoLive_2019# show configuration commit list

Note: Latest commit changes show up on top

Step 7. Look at the last configuration change

show configuration commit changes last 1

RP/0/0/CPU0:CiscoLive_2019# show configuration commit changes last 1

LTRARC-2002 Introduction to IOS XR Lab Guide 10 | P a g e

rollback configuration last 1

RP/0/0/CPU0:CiscoLive_2019# rollback configuration last 1

Loading Rollback Changes.

Updated Commit database in 1 sec

RP/0/0/CPU0:XR1# show configuration commit list

Step 9. Erase the running-configuration

RP/0/0/CPU0:ios(config)# do show run

LTRARC-2002 Introduction to IOS XR Lab Guide 11 | P a g e

Step 10. Rollback the change

rollback configuration last 1

RP/0/0/CPU0:ios# rollback configuration last 1

Loading Rollback Changes.

38 items committed in 5 sec (7)items/sec

Updated Commit database in 1 sec

Step 11. Understanding IOS-XR command hierarchy.

For example, enter the following commands to see the error:

Step 12. Understanding the use of ‘pwd’

Step 13. Understanding the use of ‘root’

Enter the following commands to get back to root prompt

RP/0/0/CPU0:XR1(config-if)# router ospf 100