Advanced BGP Interdomain Routing

Cisco Demo Cloud (dCloud)
Cisco Advanced BGP Inter-domain Routing Lab v1.1

Last Updated: 12 May 2015
About This Lab

In this lab, students will experience a hands-on introduction to some advanced BGP routing technologies. Participants will be able to
configure BGP RPKI, Graceful Shutdown and BGP Add_Path and verify key aspects of this architecture, including:
 Implementation and verifying of the principle of GSHUT
 High Availability (HA) and fast convergence by using BGP Add_Path capability
 Configuration of BGP Origin AS Validation and increasing overall network security and integrity
These key aspects will be covered in four different scenarios:
 Scenario 1: POD Topology Verification
 Scenario 2: Configuring BGP Graceful Shutdown
 Scenario 3: Configuring AddPath
 Scenario 4: Configuring BGP Origin AS Validation
Lab Objectives
After completion of this lab, the participant will gain a fundamental understanding of data plane and control plane aspects of
GSHUT, BGP Add_Path and BGP Origin AS validation. The lab demonstrates the operational simplicity of the architectures and
how it can be used for improving network security, reducing planned network maintenance impact and improving convergence and
network robustness
The lab uses a combination of routers running IOS and IOS-XR, providing the student with hands-on experience for configuration
and verification using both operating systems.
This lab guide provides step-by-step walk through procedures to complete a successful advanced BGP implementation, including:
 Accessing the lab devices
 Getting familiar with the lab network
 Verifying pre-configured IP connectivity within student POD
 Enabling GSHUT within student POD
 Enabling Add_Path
 Enabling BGP Origin AS validation within student POD
Lab Requirements
The table below outlines the requirements for this preconfigured lab.
© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 1 of 45
Table 1. Lab Requirements
Required Optional
 Computer with Internet Access  Cisco AnyConnect
 Cisco.com login Credentials  Remote Desktop Client
Lab Configuration
This lab contains preconfigured users and components to illustrate the capabilities available to you within the VIRL sandbox.
All information needed to complete the access components is located in the Topology and Servers menus of your active lab.
Topology Menu. Click on any server in the topology and a popup window will appear with available server options.
Servers Menu. Click on or next to any server name to display the available server options and credentials.
Lab Topology (optional)

The lab network consists of virtual instances of IOS and IOS-XR routers running inside Virtual Machines.
The lab network is composed of the following blocks:
 XR POD – POD_XR_Edge is an XR router
 IOS POD – All other PODs are CSR1000v instances running XE
 RPKI Validator – An external RPKI validator (Users will not configure this device)
NOTE: Only connect and configure devices on your assigned Student POD. Do NOT attempt to connect or change any
configuration in other student PODs.
A high-level overview of the lab topology:
Individual PODs
Each POD is composed of:
 POD_XR_Edge: one (1) XR Edge router
 POD_IOS_Edge & POD_IOS_RR_Client: Two (4) IOS Based BGP Route-Reflector Clients
 POD_IOS_RR_Server: One (1) BGP Route-Reflector
 POD_External: One (1) External BGP Router
 RPKI Validator: RPKI Server
Lab Guide Structure

The content of this Lab guide is broken into self-contained blocks labeled as “Scenarios”. Each scenario is then further divided into
smaller units labeled as “Tasks”.
A Task is composed of the following:
 Objectives
 Procedures / Steps - Task Procedures generally involving device configuration. They are required and MUST be executed
for successful completion of a task. Task Procedures are represented with the following icon:
Users are encouraged to complete as many scenarios as possible.
NOTE: In order to see syslog messages, make sure to enable terminal monitor on your telnet sessions (enter CLI “terminal
monitor” at the exec prompt)
Lab Preparation
Follow the steps below to schedule your lab and configure your lab environment.
1. Browse to dcloud.cisco.com and login with your Cisco.com credentials.
2. Schedule a lab [Show Me How].
3. Test your connection from the lab location before performing any lab scenario. [Show Me How]
4. Verify your lab has a status of Active under My Demonstrations on the My Dashboard page in the dCloud UI.
 It may take up to 30 minutes for your lab to become active.
5. Connect to the Workstation, using one of the following two options:
 Using Cisco dCloud Remote Desktop client [Show Me How] OR
NOTE: If you are running RDP, it is highly recommended that you use HTML5 as the default client. [Show Me How].
 Using Cisco AnyConnect [Show Me How]
o After connecting to the lab via AnyConnect, use your local RDP client to connect to workstation located at
198.18.133.252.
6. Login with the credentials Administrator / C1sco12345
TIP: You can make your RDP session screen larger. To resize, select the corners of the remote desktop window and drag to the
desired size. Right-click anywhere within the grey space of the remote desktop window and select Reload.
Scenario 1: POD Topology Verification
Before you Begin
1. After you have accessed the workstation, launch VM Maestro by clicking the VM Maestro shortcut on the desktop.
 If necessary, agree to the License Agreement.
2. In the top menu, click the to launch the simulation.
 You must wait for all devices to read “Active” prior to continuing.
Figure 1. VIRL Active State
IMPORTANT: The lab will not be ready to run until all nodes have changed from BUILD to ACTIVE in the Simulations window at the
right-hand side of the VM Maestro application. Even after the nodes have changed to ACTIVE, it may take up to 10 minutes for all
nodes to finish the build process. You must only click the Launch Simulation button once as it will initiate new copies each time
clicked.
3. To telnet to a device, on the right-hand device menu, under Simulations, right-click on the device and choose Telnet > to its
Console.
 This will launch a Putty (Terminal) session and automatically connect you.
Figure 2. Telnet to a Device
4. Press Enter to access the connection.
5. Log into the console with the credentials: username: cisco, password: cisco
 When you see the command prompt POD_xxx_xxx>, the node is ready to accept command input.
NOTE: If a blank page appears or any other prompt, the device is still loading its initial configuration and is not yet ready, despite the
state of “ACTIVE” being present. If this occurs, exit the connection, wait approximately 5 minutes and try again.
Lab Steps
Task 1 – Verify Neighbors
6. Telnet to each of the devices and use the following commands to verify how devices are interconnected in your POD and
the IP addresses configured:
 show ip interface brief (for IOS devices)
 show ipv4 interface brief (for IOS-XR devices)
POD_XR_Edge and POD_IOS_Edge routers must have discovered three (3) neighbors, as shown in the figure below:
Figure 3. POD_IOS_Edge show ip interface brief
o Peer POD_External
o Peer POD_IOS_RR_Server
o Peer POD_XR_Edge or POD_IOS_Edge
POD_IOS_RR_Server must have discovered three (3) neighbors, as shown in the figure below:
Figure 4. POD_IOS_RR_Server show ip interface brief
o Peer POD_XR_Edge
o Peer POD_IOS_Edge
o Peer POD_IOS_RR_Client
POD_IOS_RR_Client must have discovered one (1) neighbor:

Figure 5. POD_IOS_RR_Client show ip interface brief
Task 2 – Verify BGP Routing Implementation
The baseline BGP routing setup is configured to make the preferred exit for BGP Autonomous System 65001, through BGP router
POD_IOS_Edge. To accommodate this via configuration, the BGP local-preference attribute is set. By default the IOS local-
preference is value ‘100’, and by manual configuration this is set on router POD_IOS_Edge to a value ‘200’. The higher the local-
preference, the more preferred the path is.
For this lab, the local preference is set by an ingress route-map policy on POD_IOS_Edge. The policy is applied on the session
towards router POD_External.
7. To view the route-map policy, on POD_IOS_Edge, login to the router using the password: cisco and perform a show run |
begin router bgp.
Figure 6. POD_IOS_Edge show run | begin router bgp
Scenario 2 – Configuring BGP Graceful Shutdown
Objective of this exercise is to enable and understand BGP Graceful shutdown (GSHUT) operation in addition to monitoring in each
Student POD
NOTE: GSHUT is supported only on the XE based versions
Lab Steps
Task 1 – Verify the Existing Setup
In the lab setup, a baseline design for both OSPF and BGP routing configuration has been implemented. OSPF design is configured
within a single area core ‘0’. No additional areas or summarization is applied.
The following BGP setup has been implemented at baseline:
1. A prefix 3.3.3.3/32 is sourced on device POD_External. The following configuration is already applied on POD_External.
!
interface Loopback3
ip address 3.3.3.3 255.255.255.255
!
router bgp 65100
bgp log-neighbor-changes
network 3.3.3.3 mask 255.255.255.255
!
 This prefix is sent from POD_External via eBGP to both POD_IOS_Edge and POD_XR_Edge. In the same LAN (similar to
an Internet Exchange Point setup.)
 Both Edge routers have deployed BGP next-hop-self.
2. The following is the startup configuration of POD_IOS_Edge, as seen in the output of the show run | begin router bgp.
3. Router POD_XR_Edge forwards BGP prefixes onwards within AS#65001 over the established iBGP session to the Route-
reflector. To view the Route-Policy configured on POD_XR_Edge, type the command: show run | begin route-policy
Adv_BGP_Class.
Figure 8. POD_XR_Edge show run | begin route-policy Adv_BGP_Class.
4. The following is the startup configuration of POD_XR_Edge, as seen in the output of the show run | begin router bgp.
Figure 9. POD_XR_Edge show run | begin router bgp
5. Device POD_IOS_RR_Server is an IOS BGP Route-Reflector with three (3) Route-Reflector Clients (POD_XR_Edge,
POD_IOS_Edge and POD_IOS_RR_Client). To view this, on POD_IOS_RR_Server, type the command show run | begin
router bgp.
Figure 10. POD_IOS_RR_Server show run | begin router bgp
6. Device POD_IOS_RR_Client is acting as a simple BGP Route-reflector client with a default iBGP session towards
POD_IOS_RR_Server. To view this, on POD_IOS_RR_Client, type the command show run | begin router bgp.
Figure 11. POD_IOS_RR_Client show run | begin router bgp
7. The prefix used for this scenario is 3.3.3.3/32. It can be seen on both POD_XR_Edge and POD_IOS_Edge as being received
from POD_External (192.168.1.1). On POS_IOS_Edge and POD_XR_Edge, type the command show ip bgp 3.3.3.3, as
shown in figures below.
Figure 12. POS_IOS_Edge show ip bgp 3.3.3.3
Figure 13. POS_XR_Edge show ip bgp 3.3.3.3
In the above output, on POD_XR_Edge, there are two paths towards 3.3.3.3 in the BGP table. The first path is received from the
External peer. The second path is received from POS_IOS_Edge, reflected from POD_IOS_RR_Server.
Question: Why do we see the prefix 3.3.3.3 twice in the BGP table on POD_XR_Edge, and only once on POD_IOS_Edge?
Answer: When using traditional BGP, a router will only forward the best-path to its neighbors; but will not forward it back to the
neighbor it learned the route from. In this example, the best path is the one announced by POD_IOS_Edge, due to a better local
preference. This route has been forwarded to POD_IOS_RR_Server. POD_IOS_RR_Server did not send the route back to
POD_IOS_Edge, but did forward the route to POD_XR_Edge. Finally, POD_XR_Edge does not announce its eBGP route due to a
better available iBGP route, again due to the configured local-preference attribute. This can be verified on the BGP Route-Reflector
POD_IOS_RR_Server, because POD_IOS_RR_Server will have no knowledge about POD_XR_Edge reachability of 3.3.3.3/32.
8. To view the BGP Route-Reflector paths to 3.3.3.3, on POD_IOS_RR_Server, type the command show ip bgp 3.3.3.3.
Figure 14. POD_IOS_RR_Server show ip bgp 3.3.3.3
Notice in this output that the BGP Route-Reflector does not have all information of all available network exit points to 3.3.3.3. The
only route within the table has a localpref of 200. This can be problematic for re-convergence because it will take extra time during
failure conditions to recover and signal the failure and locate alternate paths
Task 2 – Execute a BGP GSHUT
When a device supporting BGP Graceful shutdown executes a session graceful shutdown, three actions take place:
1. The BGP session is instructed that it will be shutdown in X seconds
2. The well-known GSHUT and, if configured, an alternate community is attached to the paths transferred during the graceful
shutdown period over the BGP session
3. The local preference is set during the graceful shutdown period to a user configured value for the paths transferred during
the graceful shutdown period over the BGP session
For this exercise, a graceful shutdown is planned:
 For the session between POD_IOS_Edge and POD_IOS_RR_Server
 We will inform POD_IOS_Edge that the session will shutdown in 3 minutes (180 seconds)
 During the graceful shutdown, the paths being communicated over the session are made less preferable by making the
BGP local-pref ‘70’
 During graceful shutdown the GSHUT, the community ‘123’ is attached
9. To achieve this goal, configure the following commands on POD_IOS_Edge
POD_IOS_Edge# config t
POD_IOS_Edge(config)# router bgp 65001
POD_IOS_Edge(config-router)# neighbor 172.18.0.254 shutdown graceful 180 community 123
local-preference 70
 When the command is applied, a warning message appears on the screen, as shown below.
Figure 15. Graceful Shutdown Warning
IMPORTANT: You only have 3 minutes (180 seconds) for the graceful shutdown of neighbor 172.18.0.254. The next commands
must be performed quickly to view the output prior to the shutdown.
10. Before the neighbor shuts down, check POD_IOS_Edge for the 3.3.3.3. To do this, on POD_IOS_Edge, return to the user
prompt and then type the command show ip bgp 3.3.3.3. Now, instead of only seeing a single BGP path, there are two
paths present.
Figure 16. POD_IOS_Edge show ip bgp 3.3.3.3
 The new path was learned from 172.18.0.2, which is the route-reflector POD_IOS_RR_Server. This new route has a local-
preference of ‘100’, while the path received directly from the external BGP peer is ‘200’. This is because the local-
preference in the local BGP table is not changed when the graceful shutdown is executed. The graceful shutdown will
ONLY modify the local preference for paths that are being communicated over the session that is meant to be placed in
shutdown.
11. After the configured grace-period (3 minutes in our example) the session will turn to a less preferable path for all BGP speakers
inside the AS, and it will shutdown administratively. This is shown in messages across the console port:
Figure 17. Shutdown Log Messages
12. Prior to the shutdown, the path learned from the External BGP peer (POD_External) was communicated to the Route-Reflector
over the session scheduled to shutdown in 3 minutes. To view this, on POD_IOS_Edge, verify that the neighbor was not yet
shutdown. If it was, turn the session on again and re-configure a GSHUT with the following commands:
POD_IOS_Edge(config-router)# no neighbor 172.18.0.254 shutdown
local-preference 70
13. Before the three minute expiration, examine the BGP table on the Route-Reflector (POD_IOS_RR_Server), using the
command, show ip bgp 3.3.3.3.
NOTE: If you do not see this output, wait 30 seconds and retry the command.
 Prior to the scheduled graceful shutdown command, the Route Reflector only showed a single entry in the BGP table for
3.3.3.3/32 with a local preference of 200. There are now two entries on the Route-Reflector (POD_IOS_RR_Server).
o The path received from the node which executed the graceful shutdown now has a local-preference of ‘70’
instead of the original ‘200’. This makes the path less preferable for best-path selection.
o The best path to 3.3.3.3 is now learned from POD_XR_Edge. This path has local-preference value of ‘100’,
which is preferable from ‘70’.
14. During the graceful shutdown period, POD_XR_Edge also learns that POD_IOS_Edge is not the most preferable path
anymore, but the direct external path. To view this, on POD_XR_Edge, type the command show ip bgp 3.3.3.3.
Figure 19. POD_XR_Edge show ip bgp 3.3.3.3
 In this output we can see that the external route is the new best-path, and this new route will be sent to the Route-
Reflector.
The Route-Reflector now has access to both paths (one time via POD_IOS_Edge and one time via POD_XR_Edge) and prefers the
path with highest local-preference. Consequently, it will reflect this path to all BGP Route-Reflector clients (excluding the peer the
update was received from). In our lab this means the path is sent to POD_IOS_RR_Client and POD_IOS_Edge
15. On POD_IOS_RR_Client the show ip bgp 3.3.3.3 output shows the only path towards 3.3.3.3/32 available in the BGP
table.
Figure 20. POD_IOS_RR_Client show ip bgp 3.3.3.3
GSHUT Community
Up to now, we verified that when doing a graceful shutdown, it is possible to configure a delay for the shutdown. The setting of the
community has also been verified. However, what about the GSHUT community?
To examine the difference, we must look at the BGP table for 3.3.3.3/32 before the GSHUT, and look into detail at the entry
received from neighbor POD_IOS_Edge (172.18.0.3).
16. On POD_IOS_Edge, turn the session on again and re-configure a GSHUT with the following commands:
local-preference 70
17. Next, search for the GSHUT community at the Route-Reflector. On POD_IOS_RR_Server, type the command show ip bgp
3.3.3.3.
 We can see that there is no community at all received. Why is this? The exchange of BGP communities must be enabled
per BGP session at both ends of the peering
18. On POD_IOS_RR_Server, configure the following commands:
POD_IOS_RR_Server(config)# router bgp 65001

POD_IOS_RR_Server(config-router)# add ipv4 unicast
POD_IOS_RR_Server(config-router-af)# neighbor 172.18.0.3 send-community
POD_IOS_RR_Server(config-router-af)#
19. On POD_IOS_Edge, configure the following commands

POD_IOS_Edge(config-router)# add ipv4 unicast
POD_IOS_Edge(config-router-af)# neighbor 172.18.0.254 send-community
POD_IOS_Edge(config-router-af)#
 Once the exchange of the communities is configured, we see them added to the BGP path via POD_IOS_Edge. This
community is an additional tool to assign local policies as communities can easily be used in route-map or RPL filters to
manipulate route decision criteria.
20. In order to see the community, we need to re-configure GSHUT on the POD_IOS_Edge router.
POD_IOS_Edge(config-router-af)# router bgp 65001

local-preference 70
21. Check the result at the POD_IOS_RR_Server equipment with the command show ip bgp 3.3.3.3.
Scenario 3 – Configuring AddPath
The AddPath feature will provide path diversity within a BGP Autonomous System. In Scenario 2 the operational less-intrusive
mechanism of graceful shutdown is discussed. In the beginning of that scenario, it was seen and demonstrated that on
POD_XR_Edge, the externally received eBGP path to 3.3.3.3/32 was suppressed because the iBGP learned path via
POD_IOS_Edge was a more preferable path. By default, BGP ONLY forwards the best path to a destination. As a direct
consequence, POD_IOS_RR_Server is not aware of this additional available exit. If the BGP Route-Reflector is not aware of the
path, then it will also not communicate that path.
BGP AddPath allows a BGP speaker to forward, in addition to the ‘Best Path’, other valid paths. This allows a receiving BGP router
to decide, locally, the best path.
Task 1 – Enable BGP session between POD_IOS_Edge and POD_IOS_RR_Server
In Scenario 2, the session between the Route-Server and the client was shutdown. This task will bring the BGP session back up to
running operation.
1. Verify the current configuration on POD_IOS_Edge with the command show run | begin router bgp.
2. On POD_IOS_Edge, enable the neighbor 172.18.0.254 using the command:
3. Next, type the command show ip bgp summary to view the BGP Peer session that is provided to the BGP Route-Reflector.
Figure 24. POD_IOS_Edge show ip bgp summary
Task 2 – Check Baseline without AddPath
In this task, the goal is to check the startup BGP configuration. This scenario will first implement AddPath between POD_XR_Edge
and POD_IOS_RR_Server and then look in the capabilities and routes exchanged, followed by enabling AddPath between
POD_IOS_RR_Server and POD_IOS_RR_Client.
4. Verify the baseline configuration on POD_IOS_RR_Server with the command show run | begin router bgp. The
following configuration should be in place at this point:
Figure 25. POD_IOS_RR_Server show run | begin router bgp
5. Next, on POD_IOS_RR_Server, view the BGP configuration by typing the command: show ip bgp summary.
Figure 26. POD_IOS_RR_Server show ip bgp summary
 Notice that from POD_IOS_Edge (172.18.0.3) prefixes are received (4), while none are received from POD_XR_Edge
(172.18.0.2.)
6. Verify the baseline configuration on POD_XR_Edge with the command show run | begin router bgp. The following
configuration should be in place at this point:
Figure 27. POD_XR_Edge show run | begin router bgp
7. Next, on POD_XR_Edge, type the command: show ip bgp summary.

Figure 28. POD_XR_Edge show ip bgp summary
8. View advertised routes with the command: show bgp ipv4 unicast neighbors 172.18.0.254 advertised-
routes.
Figure 29. POD_XR_Edge show bgp ipv4 unicast neighbors 172.18.0.254 advertised-routes.
9. Finally, check the bgp configuration with the command show ip bgp.
Figure 30. POD_XR_Edge show ip bgp
10. View the routing table entry for 3.3.3.3 with the command show bgp ipv4 unicast 3.3.3.3.
Figure 31. POD_XR_Edge show bgp ipv4 unicast 3.3.3.3
 In the above example, on POD_XR_Edge, there are two BGP sessions. One session to POD_External (192.168.1.1) and
one session to POD_IOS_RR_Server (172.18.0.254). Over each session, four prefixes are received. The prefixes received
from peer POD_IOS_RR_Server are the preferred BEST path.
 When verifying the prefixes announced to POD_IOS_RR_Server, no prefixes are announced, although POD_XR_Edge
received a valid path to 3.3.3.3/32 directly from POD_External. Unfortunately, this external received path is not the BEST
path, and hence it is not forwarded to POD_IOS_RR_Server.
The impact of this suppression is quite dramatic, because now although BGP AS#65001 has two possible egress points, only one is
known inside the BGP AS. This has the following impact (this list is not complete)
 Increased convergence time: When the primary path becomes unavailable, the secondary (alternate) path needs to be
re-signaled which will take important extra down time.
 No local best path computation: The best path computation is taken on a different router as the router that intends to use
the BGP path. This may result in sub-optimal routing.
 No traffic-sharing: With only availability to a single path, although there are multiple exit points, it is impossible to utilize
full egress resources of the network.
Task 3 – Enable AddPath capability on XR and IOS
This task will enable the capability of both sending and receiving multiple paths to the same prefix. This is needed because , by
default, BGP only allows the best path to be exchanged. Hence, if multiple paths are exchanged, then the newest path will overwrite
the previous path in the BGP database, which is not the original intention. The goal is to exchange, in addition to the BEST path, a
second valid path, or a valid third path, or all valid paths. This functionality is known as BGP AddPath.
Enable BGP AddPath capability on XR
11. On POD_XR_Edge, type the following commands:
RP/0/0/CPU0:POD_XR_Edge(config)# router bgp 65001

RP/0/0/CPU0:POD_XR_Edge(config-bgp)# address-family ipv4 unicast
RP/0/0/CPU0:POD_XR_Edge(config-bgp-af)# additional-paths receive
RP/0/0/CPU0:POD_XR_Edge(config-bgp-af)# additional-paths send
RP/0/0/CPU0:POD_XR_Edge(config-bgp-af)# commit
RP/0/0/CPU0:POD_XR_Edge(config-bgp-af)# end
12. After you enabled AddPath, you need to “hard” clear the BGP session between POD_XR_Edge and POD_IOS_RR_Server. On
POD_XR_Edge, type the following commands: Note: Be sure to specify terminal monitor to view logs.
RP/0/0/CPU0:POD_XR_Edge# terminal monitor

Wed Jan 29 15:51:36.034 UTC
RP/0/0/CPU0:POD_XR_Edge# config t
Wed Jan 29 15:52:00.034 UTC
RP/0/0/CPU0:POD_XR_Edge(config-bgp)# neighbor 172.18.0.254 shutdown
RP/0/0/CPU0:POD_XR_Edge(config-bgp)# commit
Wed Jan 29 15:52:18.392 UTC
RP/0/0/CPU0:POD_XR_Edge(config-bgp)#RP/0/0/CPU0:Jan 29 15:52:18.662 : config[65802]:
%MGBL-CONFIG-6-DB_COMMIT : Configuration committed by user 'cisco'. Use 'show
configuration commit changes 1000000003' to view the changes.
RP/0/0/CPU0:Jan 29 15:52:20.492 : bgp[1044]: %ROUTING-BGP-5-ADJCHANGE_DETAIL : neighbor
172.18.0.254 Down - Admin. shutdown (CEASE notification sent - administrative shutdown)
(VRF: default; AFI/SAFI: 1/1) (AS: 65001)
RP/0/0/CPU0:POD_XR_Edge(config-bgp)# no neighbor 172.18.0.254 shutdown

Wed Jan 29 15:52:55.950 UTC
RP/0/0/CPU0:POD_XR_Edge(config-bgp)#RP/0/0/CPU0:Jan 29 15:52:56.170 : config[65802]:
%MGBL-CONFIG-6-DB_COMMIT : Configuration committed by user 'cisco'. Use 'show
configuration commit changes 1000000004' to view the changes.
RP/0/0/CPU0:POD_XR_Edge(config-bgp)#RP/0/0/CPU0:Jan 29 15:53:02.689 : bgp[1044]: %ROUTING-
BGP-5-ADJCHANGE_DETAIL : neighbor 172.18.0.254 Up (VRF: default; AFI/SAFI: 1/1) (AS:
65001)
end
RP/0/0/CPU0:Jan 29 15:53:06.329 : config[65802]: %MGBL-SYS-5-CONFIG_I : Configured from
console by cisco on vty0 (172.16.1.1)
RP/0/0/CPU0:POD_XR_Edge#
Enable BGP AddPath capability on IOS
13. On POD_IOS_RR_Server, type the following commands:

POD_IOS_RR_Server(config-router)# address-family ipv4
POD_IOS_RR_Server(config-router-af)# bgp additional-paths send receive
POD_IOS_RR_Server(config-router-af)# bgp additional-paths select all best 3
 By using the above commands, the routers are instructed that they support BGP AddPath capability. This capability is
exchanged during the BGP session initiation.
14. On POD_IOS_RR_Server, view BGP neighbor information by typing the command: show ip bgp neighbor 172.18.0.2.
Figure 32. POD_IOS_RR_Server show ip bgp neighbor 172.18.0.2
15. On POD_XR_Edge, type the command: show bgp ipv4 unicast neighbor 172.18.0.254
Figure 33. POD_XR_Edge show bgp ipv4 unicast neighbor 172.18.0.254
 At this moment, AddPath is enabled.
16. Examine the Route-Reflector POD_IOS_RR_Server to see if there are multiple paths received from POD_XR_Edge already.
On POD_IOS_RR_Server, type the command: show ip bgp summary.
Figure 34. POD_IOS_RR_Server show ip bgp summary
17. Next, on POD_XR_Edge, type the command: show bgp ipv4 unicast neighbor 172.18.0.254 advertise-
routes.
Figure 35. POD_XR_Edge show bgp ipv4 unicast neighbor 172.18.0.254 advertise-routes
 Although AddPath was enabled on POD_IOS-XR_Edge the routes learned from the eBGP session are not received on
POD_IOS_RR_Server or sent from POD_IOS_XR_Edge. Why is that? The reason is because we enabled only the support
for sending more than one single path. Until now, the router has not received any information about which additional routes
to send. Should it only send the 2nd best path, or multiple paths, or all paths? Before this information is specified on the
router, the router simply does not have enough information to identify which routes to send in addition to the original BEST
path.
Create a Route-Policy
In this scenario, on POD_XR_Edge, we will announce all available paths. This is done by creating a route-policy. The configuration
will hence exist in two steps (1) creation of the route-policy and (2) attach the route-policy to the AddPath capability.
RP/0/0/CPU0:POD_XR_Edge# conf t
Mon Dec 16 12:00:27.078 UTC
RP/0/0/CPU0:POD_XR_Edge(config)# route-policy add_path_policy
RP/0/0/CPU0:POD_XR_Edge(config-rpl)# set path-selection all advertise
RP/0/0/CPU0:POD_XR_Edge(config-rpl)# end-policy
RP/0/0/CPU0:POD_XR_Edge(config-bgp)# address-family ipv4 unicast
RP/0/0/CPU0:POD_XR_Edge(config-bgp-af)# additional-paths selection route-policy
add_path_policy
RP/0/0/CPU0:POD_XR_Edge(config-bgp-af)# end
Uncommitted changes found, commit them before exiting(yes/no/cancel)? [cancel]:yes
RP/0/0/CPU0:POD_XR_Edge#
19. To view the new advertised route, on POD_XR_Edge, type the command: show bgp ipv4 unicast neighbor
172.18.0.254 advertised-routes.
Figure 36. POD_XR_Edge show bgp ipv4 unicast neighbor 172.18.0.254 advertised-routes
 Where earlier there was no route sent from IOS_XR_Edge to the Route-Reflector, now there will be one.
NOTE: In the above configuration, the route-policy is appended to the global BGP IPv4 unicast address family. In a similar fashion,
a more restrictive than the global AddPath route-policy can be applied per neighbor; however, that is beyond the scope of this
Advanced Laboratory.
20. Once verified that this route is being sent from POD_XR_Edge to POD_IOS_RR_Server, it can then be validated whether the
POD_IOS_RR_Server really received the route. On POD_IOS_RR_Server, type the command: show ip bgp 3.3.3.3/32.
Figure 37. POD_IOS_RR_Server show ip bgp 3.3.3.3/32
 You can now see on POD_IOS_RR_Server that two paths towards 3.3.3.3/32 are available, the BEST path and the second
best path. Next step is to propagate the additional paths within the BGP AS infrastructure.
Task 4 – Enable AddPath between Route-Reflector and its Clients
For this scenario, BGP speaker POD_IOS_RR_Client will be enabled for BGP AddPath, and it is expected that at the end of this
scenario, this device will receive information about the two possible exits towards 3.3.3.3/32.
21. Examine POD_IOS_RR_Server, to determine if AddPath is enabled on POD_IOS_RR_Client. To do this, on

POD_IOS_RR_Server, type the command: show bgp ipv4 unicast neighbors 172.18.0.10.
Figure 38. POD_IOS_RR_Server show bgp ipv4 unicast neighbors 172.18.0.10
 In the output above AddPath capability is advertised but not received on the POD_IOS_RR_Server.
22. To make AddPath work, it has to be enabled on POD_IOS_RR_Client for the BGP session. On POD_IOS_RR_Client, view the
current bgp information on 3.3.3.3 with the command: show ip bgp 3.3.3.3.
23. To enable and verify the AddPath capability support, on POD_IOS_RR_Client, type the following commands:
POD_IOS_RR_Client(config)# router bgp 65001

POD_IOS_RR_Client(config-router)# address-family ipv4
POD_IOS_RR_Client(config-router-af)# bgp additional-paths send receive
POD_IOS_RR_Client(config-router-af)# end
POD_IOS_RR_Client#
24. Next, on POD_IOS_RR_Client, type the command: show ip bgp neighbor 172.18.0.254.
Figure 40. POD_IOS_RR_Client show ip bgp neighbor 172.18.0.254
 The above verifies that on the POD_IOS_RR_Client the AddPath capability is both to send and recieve.
25. On POD_IOS_RR_Client, verify if multiple paths are received on the router by typing the command: show ip bgp
3.3.3.3.
 Only one path is available on the client.
26. Verify the number of paths available on the Route-Reflector. On POD_IOS_RR_Server, type the command: show ip bgp
3.3.3.3.
Question: Why is the Route-Reflector POD_IOS_RR_Server not sending the multiple paths towards the client?
Answer: On IOS, it is necessary to configure, per session, the type of additional paths which need to be configured.
27. On POD_IOS_RR_Server, configure the following commands:

POD_IOS_RR_Server(config-router-af)# neighbor 172.18.0.10 advertise additional-paths all
POD_IOS_RR_Server(config-router-af)# neighbor 172.18.0.10 additional-paths send
POD_IOS_RR_Server(config-router-af)# end
28. Now, the additional path is advertised and is labeled as an additional-path. To view this, on POD_IOS_RR_Server, type the
command: show ip bgp neighbor 172.18.0.10 advertised-routes.
Figure 43. POD_IOS_RR_Server show ip bgp neighbor 172.18.0.10 advertised-routes
29. A final look on POD_IOS_RR_Client now shows that two BGP paths towards 3.3.3.3/32 are available. On
POD_IOS_RR_Client, type the command: show ip bgp 3.3.3.3.
Task 5 – Remove AddPath from the BGP Route-Reflector
30. On POD_IOS_RR_Server, remove the AddPath configuration with the following commands:

POD_IOS_RR_Server(config-router)# address-family ipv4 unicast
POD_IOS_RR_Server(config-router-af)# no bgp additional-paths select all best 3
POD_IOS_RR_Server(config-router-af)# no bgp additional-paths send receive
POD_IOS_RR_Server(config-router-af)# exit
POD_IOS_RR_Server(config-router-af)# no neighbor 172.18.0.10 advertise additional-paths all
POD_IOS_RR_Server(config-router-af)# no neighbor 172.18.0.10 additional-paths send
POD_IOS_RR_Server(config-router-af)# end
rd
This concludes the 3 scenario. In this scenario, you learned how to:
 Check the existence of AddPath capability on both IOS and XR

 Configure Addpath on both IOS and XR
 Understand some subtle differences between IOS and XR
Scenario 4 – Configuring BGP Origin AS validation
BGP Origin AS validation is a security enhancement for Cisco IOS and IOS-XR routers. It relies on the use of the Resource Public
Key Infrastructure (RPKI) with the objective to verify the right of use of IP resources for a given origin AS. The objective for this
scenario is to understand how to configure and verify BGP Origin AS validation as well as understanding how to use this feature to
modify a router’s BGP policies.
Two participants per POD should run this lab: one participant configures the IOS edge router (POD_IOS_Edge) and the second
participant configures the XR edge router (POD_XR_Edge).
Before you Begin

Prior to proceeding, please clear your BGP sessions. To do this, on both BOTH POD_IOS Edge and POD_XR_Edge, type the
following commands:
config t
router bgp 65001
neighbor 172.18.0.254 shutdown
!<on POD_IOS_XR only> commit
no neighbor 172.18.0.254 shutdown
!<on POD_IOS_XR only> commit
NOTE: For POD_IOS_XR, be sure to commit changes when you complete the shutdown, and again when you remove the
shutdown status.
LAB Steps
Task 1 – Verifying current external routing status.
In this task you will verify the current status of the BGP session between the edge routers and the POD_External router before the
configuration of BGP Origin AS validation. Telnet to your edge router (POD_IOS_Edge or POD_XR_Edge) and verify the IPv4 BGP
routing session.
1. On POD_IOS_Edge, type the following commands:
 show bgp ipv4 unicast summary
 show bgp ipv4 unicast
 show bgp ipv4 unicast 5.0.0.0/9

Figure 45. POD_IOS_Edge show bgp ipv4 unicast summary
Figure 46. POD_IOS_Edge show bgp ipv4 unicast
Figure 47. POD_IOS_Edge show bgp ipv4 unicast 5.0.0.0/9

Figure 48. POD_XR_Edge show bgp ipv4 unicast summary
Figure 49. POD_XR_Edge show bgp ipv4 unicast
Figure 50. POD_XR_Edge show bgp ipv4 unicast 5.0.0.0/9
 Note that in both case the total number of prefixes received from the POD_External router is 4 and that the POD_XR_Edge
receives the additional paths from the POD_RR_Server as the route-reflector prefers the announcement received from the
IOS edge due to the Local-Preference setting to 200 at that edge.
 Also in the case of the XR router, there is already Origin-AS validation information that is set to “not-found” for paths
received on external BGP sessions. However, there is no such state for paths received in the internal BGP session.
Original validation check is only performed in external BGP sessions.
 Also note that, in both cases, the announcement received via external BGP is advertised to POD_IOS_RR_Server.
Task 2 – Configuring and verifying RPKI-to-Router (RTR) protocol
During this task we will configure and verify the RTR protocol from the Edge routers to the RPKI server.
3. First we must verify IP connectivity from POD_XR_Edge to the RPKI Server (172.16.1.1) using the ping command.
Figure 51. POD_XR_Edge ping
Configure the Connection to the RPKI Server.

4. Configure the connection to RPKI Server using RTR protocol and set refresh time to 60 seconds. Start on POD_IOS_Edge,
type the following commands:

POD_IOS_Edge(config-router)# bgp rpki server tcp 172.16.1.1 port 31000 refresh 60
POD_IOS_Edge(config-router)# end
5. Next, on POD_XR_Edge, type the following commands:

RP/0/0/CPU0:POD_XR_Edge(config-bgp)# rpki server 172.16.1.1 transport tcp
port 31000
RP/0/0/CPU0:POD_XR_Edge(config-bgp)# rpki server 172.16.1.1 refresh-time 60
Mon Dec 23 17:06:59.119 UTC
RP/0/0/CPU0:POD_XR_Edge(config-bgp)# end
Now we can verify the RTR operation by verifying the following parameters:
6. Verify the connection to RTR server from POD_IOS_Edge. On POD_IOS_Edge, type the command: show bgp ipv4
unicast rpki servers.
Figure 52. POD_IOS_Edge show bgp ipv4 unicast rpki servers
 From this output, the TCP session is ESTABLISHED (bottom message). The RTR session is also working with a refresh
time of 60 seconds and 4 prefixes were received from the server via the RTR protocol (2x IPv4 and 2xIPv6).
7. In IOS-XR, there is also a summary output using the command: show bgp rpki server summary.
Figure 53. POD_XR_Edge show bgp rpki server summary
 You can still get more verbose outputs via the XR command: show bgp rpki server 172.16.1.1
8. On POD_IOS_Edge, verify the RTR Table content with the command: show bgp ipv4 unicast rpki table.
Figure 54. POD_IOS_Edge show bgp ipv4 unicast rpki table
NOTE: One network entry could have many records related to it with per example different origin ASNs.
As a router may be connected to many different RPKI servers, the command shows the server address responsible for a given ent ry.
We will always keep the UNION of all the prefixes received via the different RTR sessions.
9. On POD_XR_Edge, verify the RTR Table content with the command: show bgp rpki table.
Figure 55. POD_XR_Edge show bgp rpki table
Verifying changes to BGP operation:
Once RPKI is configured, the BGP behavior will change automatically, by discarding invalid routes. We will verify these changes by
executing the same commands as in task 1.
10. On POD_IOS_Edge, type the command: show bgp ipv4 unicast summary
 There is a new RPKI line in the summary command. From the total 6 paths received 3 are "valid”, 1 is “not found” and 2 are
“invalid”. The POD_RR_Server changed its behavior for two prefixes that now prefers the XR edge from the IOS edge.
The reason is that IOS, by default, discards invalids while XR advertise them.
11. On POD_IOS_Edge, type the command: show bgp ipv4 unicast

 In this command, we can see that in each line there is an additional RPKI state added to the left side (N,V or I). Also noted
that in IOS, invalid announcements (I) are never selected as best path by default.
12. On POD_IOS_Edge, type the command: show bgp ipv4 unicast 5.0.0.0/9
 The external announcement for 5.0.0.0/9 with origin ASN 65100 was considered invalid, while the same announcement via
iBGP was considered valid. That is the default behavior of IOS.
13. Why was this announcement found invalid? To determine this, check the correspondent RTR table entry received from the
RPKI server. On POD_IOS_Edge, type the command: show bgp ipv4 unicast rpki table
Figure 59. POD_IOS_Edge show bgp ipv4 unicast rpki table
 We can see that the origin ASN that has the right to announce 5.0.0.0/9 is 65111, but we received the announcement with
origin ASN 65100.
14. On the POD_XR_Edge side, we still receive from the two valid prefixes from POD_IOS_Edge, but no longer the two invalid
routes. To view this, on POD_XR_Edge, type the command: show bgp ipv4 unicast summary
Figure 60. POD_XR_Edge show bgp ipv4 unicast summary
15. This becomes clearer when we look at the BGP table, where there is no longer announcement from POD_RR_Server for the
invalid prefixes. To view the BGP table, on POD_XR_Edge, type the command: show bgp ipv4 unicast.
Figure 61. POD_XR_Edge show bgp ipv4 unicast
16. For the 5.0.0.0/9 invalid prefix, we can check the different default behavior between IOS and XR as POD_XR_Edge announces
the invalid prefix to its neighbors by default. On POD_XR_Edge, type the command: show bgp ipv4 unicast 5.0.0.0/9.
Figure 62. POD_XR_Edge show bgp ipv4 unicast 5.0.0.0/9
17. To include origin-AS validation states to the BGP information, in IOS-XR, type the command: show bgp ipv4 unicast
origin-as validity
Figure 63. POD_XR_Edge show bgp ipv4 unicast origin-as validity
NOTE: In IOS-XR you can disable origin validation for a given neighbor and state will be shown as “D”. Additionally, iBGP
announcement that has not been checked will not show validation state.
Allow invalid routes in IOS
As we mentioned in the previous section, IOS does discards invalid routes by default. You can configure IOS to allow invalid routes to
be announced.
18. On POD_IOS_Edge, configure IOS to allow invalid routes to be announced by typing the following commands:

POD_IOS_Edge(config-router)# address-family ipv4
POD_IOS_Edge(config-router-af)# bgp bestpath prefix-validate allow-invalid
 Now, we can see the changes using the same show commands (after clearing BGP session on both edge routers):
19. On POD_IOS_Edge, type the commands:
 We see that now the network behaves exactly as when we started, with the exception that now we have the validity states
to use for statistics purpose.
Task 3 – Configure Internal BGP Extended Community
As we mentioned in the previous session, a router will not set the validation state for announcement received via internal BGP as it
expect the correspondent edge router to perform the validation. In order to enable the signaling of the origin validation sta te between
internal routers, a new non-transitive extended community is defined. We will enable this community between the edge routers and the
route reflector servers.
20. First, check how the POD_RR_Client is receiving the current external announcements from POD_RR_Server. To do this, on
POD_RR_Server, type the commands:
 show bgp ipv4 unicast summary.

Figure 67. POD_RR_Server show bgp ipv4 unicast summary .
Figure 68. POD_RR_Server Show bgp ipv4 unicast
 This output shows that there are no changes from normal operations and the RR_Client has no information about origin
validation states.
21. Turn origin validation ON for the POD_RR_Client by configuring the BGP Origin AS validation community signalization. On
POD_IOS_RR_Client, type the following commands:
POD_IOS_RR_Client(config)# router bgp 65001

POD_IOS_RR_Client(config-router)# address-family ipv4
POD_IOS_RR_Client(config-router-af)# neighbor 172.18.0.254 send-community extended
POD_IOS_RR_Client(config-router-af)# neighbor 172.18.0.254 announce rpki state
POD_IOS_Edge(config)# end
22. Verify the effects on POD_IOS_RR_Client, by typing the command: show bgp ipv4 unicast summary
Figure 69. POD_IOS_RR_Client show bgp ipv4 unicast summary
 All prefixes are set to valid because they are received via iBGP, and this is the IOS default behavior.
We will now turn on the iBGP community in both edge routers:
23. On POD_IOS_Edge, type the following commands:

POD_IOS_Edge(config-router-af)# neighbor 172.18.0.254 send-community extended
POD_IOS_Edge(config-router-af)# neighbor 172.18.0.254 announce rpki state
POD_IOS_Edge(config)# end

RP/0/0/CPU0:POD_XR_Edge(config-bgp)# bgp origin-as validation signal ibgp
Mon Dec 23 19:09:59.853 UTC
RP/0/0/CPU0:POD_XR_Edge(config-bgp)# end
25. We also need to turn extended community support for the iBGP Session between the POD_IOS_RR_Server and the
POD_IOS_RR_Client. On POD_IOS_RR_Server, type the following commands:

POD_IOS_RR_Server(config-router)# address-family ipv4 unicast
POD_IOS_RR_Server(config-router-af)# neighbor 172.18.0.10 send-community extended
26. The POD_RR_Client has now the same RPKI validation information as the edge routers. To view this, on POD_RR_Client,
type the commands:
 show bgp ipv4 unicast summary.
Figure 70. POD_RR_Client show bgp ipv4 unicast summary.
Figure 71. POD_RR_Client show bgp ipv4 unicast
Figure 72. POD_RR_Client show bgp ipv4 unicast 5.0.0.0/9
Task 4 – Configure policies based on Origin Validation state
When using BGP Origin Validation, the default simple policy manipulation is to remove paths with “invalid” origin validation states.
However, IOS and IOS-XR allow a rich set of policy manipulations based on origin validation states. This task will show how to modify
the BGP local preference by manipulating BGP policies. The objective of the scenario is to set local preferences as follow:
Table 2. Local Preference
Origin Validation Status Local Preference Local Preference

POD_IOS_Edge POD_XR_Edge
Valid 210 200
Not Found 110 100
Invalid 90 80
This configuration may be a good intermediate state before completely removing all invalid routes from the network, to check the
consequence on traffic.
27. The first thing that must be done is to connect to POD_IOS_Edge and remove the existing policy. On POD_IOS_Edge, type the
following commands:

POD_IOS_Edge(config-router-af)# no neighbor 192.168.1.1 route-map Adv_BGP_in in
POD_IOS_Edge(config-router-af)# end
 With this change, the local preference for all prefixes is set to the default: 100.
28. Next, on POD_IOS_Edge we configure the route-map: RPKI_LOCAL_PREF_V4_IN using the following commands:
POD_IOS_Edge(config)# route-map RPKI_LOCAL_PREF_V4_IN permit 10

POD_IOS_Edge(config-route-map)# match rpki valid
POD_IOS_Edge(config-route-map)# set local-preference 210
POD_IOS_Edge(config-route-map)# route-map RPKI_LOCAL_PREF_V4_IN permit 20
POD_IOS_Edge(config-route-map)# match rpki not-found
POD_IOS_Edge(config-route-map)# route-map RPKI_LOCAL_PREF_V4_IN permit 30
POD_IOS_Edge(config-route-map)# match rpki invalid
POD_IOS_Edge(config-route-map)# end
29. Next, apply the configuration to the external BGP session with POD_External. On POD_IOS_Edge, type the following
commands:

POD_IOS_Edge(config-router-af)# neighbor 192.168.1.1 route-map RPKI_LOCAL_PREF_V4_IN in
POD_IOS_Edge(config-router-af)# end
30. For POD_XR_Edge we configure a route-policy: RPKI_LOCAL_PREF_V4_IN on POD_XR_Edge. On POD_XR_Edge, type the
following commands:
RP/0/0/CPU0:POD_XR_Edge(config)# route-policy RPKI_LOCAL_PREF_V4_IN
RP/0/0/CPU0:POD_XR_Edge(config-rpl)# if validation-state is valid then
RP/0/0/CPU0:POD_XR_Edge(config-rpl-if)# set local-preference 200
RP/0/0/CPU0:POD_XR_Edge(config-rpl-if)# elseif validation-state is not-found then
RP/0/0/CPU0:POD_XR_Edge(config-rpl-elseif)# set local-preference 100
RP/0/0/CPU0:POD_XR_Edge(config-rpl-elseif)# elseif validation-state is invalid then
RP/0/0/CPU0:POD_XR_Edge(config-rpl-elseif)# set local-preference 80
RP/0/0/CPU0:POD_XR_Edge(config-rpl-elseif)# done
RP/0/0/CPU0:POD_XR_Edge(config-rpl-elseif)# endif
RP/0/0/CPU0:POD_XR_Edge(config-rpl)# end-policy
RP/0/0/CPU0:POD_XR_Edge(config)# commit
IMPORTANT: Please make sure to check you configurations!
31. We now apply the policy to BGP session with POD_External. On POD_XR_Edge, type the following commands:

RP/0/0/CPU0:POD_XR_Edge(config-bgp)# neighbor 192.168.1.1
RP/0/0/CPU0:POD_XR_Edge(config-bgp-nbr)# address-family ipv4 unicast
RP/0/0/CPU0:POD_XR_Edge(config-bgp-nbr-af)# route-policy RPKI_LOCAL_PREF_V4_IN in
RP/0/0/CPU0:POD_XR_Edge(config-bgp-nbr-af)# commit
32. We can now see the results of the policy applied, where you can check that invalid routes are allowed with a lower local
preference and all routes from POD_IOS_Edge are preferred from POD_XR_Edge. On POD_IOS_Edge, type the command
show ip bgp.
Figure 73. POD_IOS_Edge show ip bgp
NOTE: If your output is not the same, wait approximately 1 minute and try the command again.
33. On POD_XR_Edge, type the same command: show ip bgp.
This concludes the RPKI and BGP Origin AS Validation scenario. In this scenario, you learned how to:
 Configure the RPKI-Router protocol in both IOS and XR

 Verify the information received from an RPKI validation server
 Configure the propagation of the Origin validation state to iBGP peers using a BGP community
 Modify BGP policies based on Origin validation state for IOS and XR
OVERALL Lessons Learned

I hope you enjoyed the lab. Upon completion you should have learned
 How to deploy graceful BGP session shutdown
 How to enable BGP Additional Paths capability
 How to verify Additional Path capability
 How to configure and enable BGP Origin AS validation
 Understand BGP Origin AS validation
 The small differences between IOS and IOS XR in terms of configuration and monitoring of Unified MPLS
***THIS CONCLUDES THIS LAB ACTIVITY ***

Advanced BGP Interdomain Routing

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Advanced BGP Interdomain Routing

Uploaded by

Copyright:

Available Formats

Cisco Demo Cloud (dCloud)

Cisco Advanced BGP Inter-domain Routing Lab v1.1

About This Lab

 Implementation and verifying of the principle of GSHUT

These key aspects will be covered in four different scenarios:

 Scenario 1: POD Topology Verification

 Scenario 2: Configuring BGP Graceful Shutdown

 Scenario 3: Configuring AddPath

 Scenario 4: Configuring BGP Origin AS Validation

 Accessing the lab devices

 Getting familiar with the lab network

 Verifying pre-configured IP connectivity within student POD

 Enabling GSHUT within student POD

 Enabling BGP Origin AS validation within student POD

 Cisco.com login Credentials  Remote Desktop Client

Lab Topology (optional)

The lab network is composed of the following blocks:

 XR POD – POD_XR_Edge is an XR router

 IOS POD – All other PODs are CSR1000v instances running XE

A high-level overview of the lab topology:

Each POD is composed of:

 POD_XR_Edge: one (1) XR Edge router

 POD_IOS_RR_Server: One (1) BGP Route-Reflector

 POD_External: One (1) External BGP Router

 RPKI Validator: RPKI Server

Lab Guide Structure

A Task is composed of the following:

Users are encouraged to complete as many scenarios as possible.

1. Browse to dcloud.cisco.com and login with your Cisco.com credentials.

2. Schedule a lab [Show Me How].

 It may take up to 30 minutes for your lab to become active.

5. Connect to the Workstation, using one of the following two options:

 Using Cisco dCloud Remote Desktop client [Show Me How] OR

 Using Cisco AnyConnect [Show Me How]

6. Login with the credentials Administrator / C1sco12345

 If necessary, agree to the License Agreement.

2. In the top menu, click the to launch the simulation.

4. Press Enter to access the connection.

 show ip interface brief (for IOS devices)

 show ipv4 interface brief (for IOS-XR devices)

o Peer POD_XR_Edge or POD_IOS_Edge

POD_IOS_RR_Client must have discovered one (1) neighbor:

Task 2 – Verify BGP Routing Implementation

NOTE: GSHUT is supported only on the XE based versions

The following BGP setup has been implemented at baseline:

 Both Edge routers have deployed BGP next-hop-self.

Figure 13. POS_XR_Edge show ip bgp 3.3.3.3

Task 2 – Execute a BGP GSHUT

1. The BGP session is instructed that it will be shutdown in X seconds

For this exercise, a graceful shutdown is planned:

 For the session between POD_IOS_Edge and POD_IOS_RR_Server

 During graceful shutdown the GSHUT, the community ‘123’ is attached

9. To achieve this goal, configure the following commands on POD_IOS_Edge

18. On POD_IOS_RR_Server, configure the following commands:

POD_IOS_RR_Server(config)# router bgp 65001

19. On POD_IOS_Edge, configure the following commands

POD_IOS_Edge(config)# router bgp 65001

POD_IOS_Edge(config-router-af)# router bgp 65001

Task 1 – Enable BGP session between POD_IOS_Edge and POD_IOS_RR_Server

2. On POD_IOS_Edge, enable the neighbor 172.18.0.254 using the command:

7. Next, on POD_XR_Edge, type the command: show ip bgp summary.

Task 3 – Enable AddPath capability on XR and IOS

Enable BGP AddPath capability on XR

11. On POD_XR_Edge, type the following commands: