Intermediate LISP For SDA Lab Guide v1.0.1 (Final)

Intermediate Location/ID
Separation Protocol (LISP)

for SDA
Lab Guide
Version 1.0.1
20 December 2017
Presented by: Cisco’s Solutions Readiness Engineering Team

Intermediate Location/ID Separation Protocol (LISP) for SDA
Contents
About This Lab............................................................................................................................................... 7
Lab Topology – Layer 2 ................................................................................................................................. 9
Lab Topology – Layer 3 ............................................................................................................................... 10
Lab Exercises ............................................................................................................................................... 11
Exercise 0: IP Reachability Verification ....................................................................................................... 12
Topology Overview ................................................................................................................................. 12
Existing Configuration Overview ............................................................................................................. 12
Task 1 - Verify IP Reachability ................................................................................................................. 13
Exercise 1: LISP xTR and MS/MR Configuration .......................................................................................... 15
Task 1 - Basic LISP xTR Configuration – EdgeNode1 ............................................................................... 15
Task 2 - Basic LISP xTR Configuration – EdgeNode2 ............................................................................... 16
Task 3 - Basic LISP xTR Configuration – BorderNode .............................................................................. 18
Task 4 - Basic LISP MS/MR Configuration – ControlPlaneNode ............................................................. 19
Task 5 - Simplify Future Troubleshooting and Verification..................................................................... 21
IP LISP source-locator command ........................................................................................................ 21
Exercise 2: xTR Verification, Registration, and Ping Tests .......................................................................... 24
Task 1 - Verify the LISP Control Plane Configuration .............................................................................. 24
Task 2 - Verify the LISP Control Plane Functionality (Bidirectional Communication) ............................. 28
Task 3 - Verify the LISP EID Registrations................................................................................................ 29
Task 4 - Verify the LISP Map-Cache Entries ............................................................................................ 29
Task 5 - Confirm LISP Control Plane, LISP Data Plane, and IP Reachability............................................. 31
Exercise 3: BPG Configuration and Basic Verification ................................................................................. 33
Background ............................................................................................................................................. 33
Border Gateway Protocol – BGP ............................................................................................................. 34
BGP Variants ........................................................................................................................................... 34
Task 1 - Basic BGP Configuration – DefaultBorder ................................................................................. 35
Task 2 - Verify BGP Adjacency and Prefix Advertisement....................................................................... 37
Task 3 - Verify BGP Neighbors................................................................................................................. 38
Exercise 4: PxTR Configuration, Verification, and Association ................................................................... 39
Packet Flow into the LISP Domain .......................................................................................................... 39
Task 1 - Basic PxTR Configuration – DefaultBorder ................................................................................ 39
Map Cache Command – PxTR ............................................................................................................. 40
© 2017 Cisco Systems Inc. Solutions Readiness Engineering Page 2

Why the Map-Cache Command is Important ..................................................................................... 40

Task 2 - Basic PxTR Verification............................................................................................................... 42
Task 3 - Configure Edge Nodes to Use the Proxy Egress Tunnel Router................................................. 43
Task 4 - Verification of PeTR Configuration – Edge Nodes ..................................................................... 45
Exercise 5: Null Routes, Route Maps, and Redistribution .......................................................................... 46
Redistribution ......................................................................................................................................... 47
Redistribution Between the LISP Domain and BGP – Option 1 .......................................................... 48
Redistribution Between the LISP Domain and BGP – Option 2 .......................................................... 49
BGP vs IGPs ......................................................................................................................................... 50
Null Routing......................................................................................................................................... 51
Task 1 - Verify Prerequisite ..................................................................................................................... 51
Task 2 - Null 0 Static Route ..................................................................................................................... 53
Route Tagging ..................................................................................................................................... 53
Task 3 - Static Route Verification ............................................................................................................ 54
Redistributing the EID-space into BGP................................................................................................ 54
Route Maps ......................................................................................................................................... 55
Task 4 - Route Map Configuration – DefaultBorder ............................................................................... 57
Task 5 - Redistribute the Static Null Route using the Route Map........................................................... 58
Task 6 - Verify NLRI ................................................................................................................................. 59
Exercise 6: LISP-to-Non-LISP and Non-LISP-to-LISP Verification ................................................................. 60
Task 1 - Enable all LISP Debugging – DefaultBorder............................................................................... 60
Task 2 - Enable Specific LISP Debugging – ControlPlaneNode ............................................................... 61
Task 3 - Native Packet Capture #1 .......................................................................................................... 61
Task 4 - Clear Existing Map-Cache Entries .............................................................................................. 62
Task 5 - Verify the Functionality of the LISP, BGP, and Route-Map Configurations ............................... 63
Task 6 - Stop the Packet Capture ............................................................................................................ 65
Task 7 - Interpreting Debug Messages – ControlPlaneNode ................................................................. 65
Task 8 - Interpreting Debug Messages – DefaultBorder ........................................................................ 67
Task 9 - Copy the Packet Capture to the Jump Host ............................................................................... 69
Task 10 - Open and View the Packet Capture ......................................................................................... 70
Task 11 - Exercise Cleanup ...................................................................................................................... 74
Exercise 7: Header Visualization and Final Troubleshooting ...................................................................... 75
Task 1 - Native Packet Capture #2 .......................................................................................................... 76

Task 2 - Telnet from PC-2 to NewYork.................................................................................................... 77

Task 3 - Stop the Capture ........................................................................................................................ 78
Task 4 - Copy the Packet Capture to the Jump Host ............................................................................... 78
Task 5 - Open and View the Packet Capture ........................................................................................... 79
Task 6 - Review the Packet Capture ........................................................................................................ 80
Task 7 - Lab Clean Up .............................................................................................................................. 82
Task 8 - Show IP LISP Forwarding Command – DefaultBorder............................................................... 84
Appendix A - Initial Configurations ............................................................................................................. 86
EdgeNode1 .............................................................................................................................................. 86
EdgeNode2 .............................................................................................................................................. 88
BorderNode............................................................................................................................................. 89
ControlPlaneNode................................................................................................................................... 91
DefaultBorder ......................................................................................................................................... 93
LabAccessSwitch ..................................................................................................................................... 96
ISP............................................................................................................................................................ 98
NewYork ................................................................................................................................................ 100
PC-1 ....................................................................................................................................................... 101
PC-2 ....................................................................................................................................................... 102
PC-3 ....................................................................................................................................................... 103
Appendix B - Configuration Examples....................................................................................................... 105
Exercise 0 .......................................................................................................................................... 105
Task 1 - Verify IP Reachability ........................................................................................................... 105
Exercise 1 .......................................................................................................................................... 105
Task 1 - Basic LISP xTR Configuration – EdgeNode1 ......................................................................... 105
Task 2 - Basic LISP xTR Configuration – EdgeNode2 ......................................................................... 105
Task 3 - Basic LISP xTR Configuration – BorderNode ........................................................................ 105
Task 4 - Basic LISP MS/MR Configuration – ControlPlaneNode ....................................................... 106
Task 5 - Simplify Future Troubleshooting and Show Commands ..................................................... 106
Exercise 2 .......................................................................................................................................... 107
Task 1 - Verify the LISP Control Plane Configuration ........................................................................ 107
Task 2 - Verify the LISP Control Plane Functionality (Bidirectional communication) ....................... 107
Task 3 - Verify the LISP EID registrations. ......................................................................................... 107
Task 4 - Verify the LISP Map-Cache Entries....................................................................................... 107

Task 5 - Confirm LISP Control Plane, LISP Data Plane, and IP Reachability....................................... 107
Exercise 3 .......................................................................................................................................... 107
Task 1 - Basic BGP Configuration – DefaultBorder ........................................................................... 107
Task 2 - Verify BGP Adjacency and Prefix Advertisement ................................................................. 107
Task 3 - Verify BGP Neighbors........................................................................................................... 107
Exercise 4: PxTR Configuration, Verification, and Association ......................................................... 108
Task 1 - Basic PxTR Configuration – DefaultBorder .......................................................................... 108
Task 2 - Basic PxTR Verifications ....................................................................................................... 108
Task 3 - Configure Edge Nodes to use the Proxy Egress Tunnel Router ........................................... 108
Task 4 - Verification of PeTR Configuration – Edge Nodes ............................................................... 108
Exercise 5: Null Routes, Route Maps, and Redistribution ................................................................ 108
Task 1 - Verify Prerequisite ............................................................................................................... 108
Task 2 - Null 0 Static Route ............................................................................................................... 108
Task 3 - Static Route Verification ...................................................................................................... 108
Task 4 - Route Map Configuration – DefaultBorder ......................................................................... 109
Task 5 - Redistribute the Static Null Route using the Route Map..................................................... 109
Task 6 - Verify NLRI ........................................................................................................................... 109
Exercise 6: LISP-to-Non-LISP and Non-LISP-to-LISP Verification ....................................................... 109
Task 1 - Enable all LISP Debugging – DefaultBorder ......................................................................... 109
Task 2 - Enable specific LISP debugging – ControlPlaneNode .......................................................... 109
Task 3 - Native Packet Capture #1 .................................................................................................... 109
Task 4 - Clear Existing Map-Cache Entries ........................................................................................ 109
Task 5 - Verify the Functionality of the LISP, BGP, and Route-Map Configurations ......................... 109
Task 6 - Stop the Packet Capture ...................................................................................................... 109
Task 7 - Interpreting Debug Messages – ControlPlaneNode ........................................................... 110
Task 8 - Interpreting Debug Messages – DefaultBorder .................................................................. 110
Task 9 - Copy the Packet Capture to the Jump Host ......................................................................... 110
Task 10 - Open and View the Packet Capture ................................................................................... 110
Task 11 - Exercise Cleanup ................................................................................................................ 110
Exercise 7: Encapsulation Header Visualization and Final Troubleshooting..................................... 110
Task 1 – Native Packet Capture #2.................................................................................................... 110
Task 2 - Telnet from PC-2 to NewYork .............................................................................................. 110
Task 3 - Stop the Capture .................................................................................................................. 110

Task 4 - Copy the Packet Capture to the Jump Host ......................................................................... 111
Task 5 - Open and View the Packet Capture ..................................................................................... 111
Task 6 - Review the Packet Capture .................................................................................................. 111
Task 7 - Lab Clean Up ........................................................................................................................ 111
Task 8 - Show IP LISP Forwarding Command .................................................................................... 111
Appendix C - Final Configurations ............................................................................................................. 112
EdgeNode1 ............................................................................................................................................ 112
EdgeNode2 ............................................................................................................................................ 117
BorderNode........................................................................................................................................... 123
ControlPlaneNode................................................................................................................................. 126
DefaultBorder ....................................................................................................................................... 131
Appendix D - LISP Forwarding Flow Charts ............................................................................................... 135
LISP Ingress Tunnel Router (ITR) Forwarding Flow Chart ..................................................................... 135
LISP Proxy Ingress Tunnel Router (PITR) Forwarding Flow Chart ......................................................... 136

About This Lab

The Basic LISP for SDA lab provided background into LISP along with LISP roles and definitions. It offered
the opportunity to configure, test, and troubleshoot a basic LISP deployment, which included the LISP
Map Server (MS) and Map Resolver (MR), and LISP edge nodes. LISP edge nodes are egress Tunnel
Routers (eTRs) and ingress Tunnel routers (iTRs) and are collectively referred to as xTRs.
This intermediate lab adds a degree of complexity to LISP through the inclusion of the Proxy Tunnel
Router (PxTR). The PxTR, or Default Border Node, allows bidirectional communication between LISP and
non-LISP sites. It has its own specific LISP commands not used on other devices. In addition, the
configuration on the PxTR must provide a way to advertise the LISP EID-prefixes via routing protocol(s)
to non-LISP sites. The routing protocol currently supported by Campus Fabric and Software-Define
Access (SDA) is BGP.
One of the goals of this lab remains the same as the basic LISP lab: to enable the student to understand
LISP at the original (fundamental) level before moving to the significant syntax changes implemented in
later versions of IOS XE.
To illustrate this, contrast the LISP MS/MR configuration from the Basic LISP for SDA lab (using IOS 15.5 /
IOS XE 16.5.1) against a similar configuration in SDA / IOS-XE 16.6.1.
Figure 0-1: MS/MR CLI Syntax Changes
Note: A step-by-step approach will be taken throughout this series of labs so that by the end, you will understand the
configuration and syntax on the right. In later labs, you will see the value-add that DNA-Center offers by fully
automating this configuration.

This Intermediate lab will require LISP configuration on five individual routers. There are two xTRs (Edge
Nodes), the Map Server / Map Resolver (Control Plane Node), another LISP speaking router (Border
Node), and finally the PxTR (Default Border Node). These routers are all interconnected through the
LabAccessSwitch, which provides inter-device connectivity, access to DNS and NTP, and access to the
real-world internet.
This intermediate lab is focused on the Proxy xTR router. This lab will teach the original method used to
bring traffic in and out of the LISP domain (LISP Fabric) and provide basic instruction on BGP peering,
route maps, and more. The final exercises will provide the opportunity to utilize native, embedded
packet capture to view the packets as they traverse the fabric towards non-LISP sites.
Note: A device that connects a LISP domain to another LISP domain is called a Border Node in SDA. It is
sometimes referred to as an Internal Border.
SDA also has a device called a Default Border. A default border is synonymous to a PxTR. It will have one interface
in the LISP Overlay and another interface that does not speak LISP, connecting to an external domain via another
routing protocol such as BGP. It is often referred to as an External Border.
The terms Internal Border and External Border are older terms from Campus Fabric, although some early SDA
documentation may still use these terms. Border Node (or simply Fabric Border) and Default Border are the
current terminology for both Campus Fabric and SDA.

Lab Topology – Layer 2

Lab Topology – Layer 3

Lab Exercises
Exercise 0: IP Reachability Verification
Exercise 1: LISP xTR and MS/MR Configuration
Exercise 2: xTR Verification, Registration, and Ping Tests
Exercise 3: BPG Configuration and Basic Verification
Exercise 4: PxTR Configuration, Verification, and Association
Exercise 5: Null Routes, Route Maps, and Redistribution
Exercise 6: LISP-to-Non-LISP and Non-LISP-to-LISP Verification
Exercise 7: Encapsulation Header Visualization and Final Troubleshooting
Lab Conventions on Last Octet of IP Addresses for Routers and Switches
EdgeNode1 = Router 1 = .1
EdgeNode2 = Router 2 = .2
BorderNode = Router 3 = .3
ControlPlaneNode = Router 4 = .4
DefaultBorder = Router 5 = .5
LabAccessSwitch = Router 6 = .6
Loopback IP Address = 192.168.255.x/32 where x = router number
Note: IP Connectivity in the underlay network has been preconfigured using the IS-IS routing protocol.
The devices will be referred to as routers regardless of whether they are Layer 3 switches or truly Integrated
Services Routers (ISRs).
When referring to the SDA role of a router, such as control plane node, lower case letters will be used with spacing
between the words. When referring to a specific device, such as ControlPlaneNode, the hostname of the device, as
it appears on the CLI, will be used.
The Map Server may be referred to as MS, and the Map Resolver may be referred to as the MR. If the function
involves both roles, MS/MR will be used to refer to the device. EID-prefix and EID-space may be used
interchangeably.
In topology diagrams, the first letters of router names will be capitalized, and spaces will be used between the words.
This can be seen in the topology diagrams on the next page.
Router Credentials
username/password: cisco/cisco
enable password: cisco

Exercise 0: IP Reachability Verification
Topology Overview
• PC-1, PC-2, and PC-3 are Cisco CSR1000vs acting as PCs. This keeps the CLI syntax consistent for
ping and telnet verification commands.
• PC-1 and PC-2 are inside the LISP domain. PC-3 is outside of the LISP domain.
• The ISP and New York routers are also CSR1000vs. They are not part of the LISP domain.
These could be any router. Their only requirement is the ability to speak BGPv4.
• The New York site is meant to represent a location that is outside of our network and
administrative control.
This is indicated by its separate autonomous system (AS) number (AS 8).
• Our network resides entirely inside of BGP Autonomous System 5 (BGP AS 5).
Existing Configuration Overview
• IP addresses and routing connectivity in AS 5 have been pre-configured.

• The routers in AS 5 are running the IS-IS protocol.
This is an identical configuration to what was configured in the IS-IS for SDA lab, including
the use of BFD between BorderNode and DefaultBorder.
• The interface between the DefaultBorder and ControlPlaneNode, for the purposes of this lab, is
meant as a backup route for traffic. It is not meant to be a transit path for LISP packets except in
the case of link failure elsewhere in the network.
• The LISP Overlay will run on top of this IS-IS underlay.
• The LabAccessSwitch will have no knowledge as to how to egress AS 5 or reach any of the PCs
inside or outside of the LISP domain.
• Only the DefaultBorder will have a default route. No default route exists on any other router.
This is particularly important to understand and note when looking at the packet forwarding
from the xTRs to the PxTR.
• The ISP and New York are already eBGP peers with one another.
• The PCs all have a static default route to their applicable router.
• DefaultBorder has a static default route to the ISP.
This route is not redistributed into the IS-IS routing protocol.
• True internet connectivity is not needed for the lab. However, DNS, NTP, and internet access is
provided through Gig 1/0/11 on the LabAccessSwitch.
Note: You will have access to the ISP, NewYork, and PC-3 equipment. While this is not reflective of a real-world
environment, it will enable you to understand the coming complexity of the configuration.

Task 1 - Verify IP Reachability
A TCL script will be used to test connectivity between Loopback IP address on all routers.
The script pings the IP address of all Loopback interfaces in AS 5 and sources that ping from the
Loopback IP address of the local router running the script.
Step 1. Connect to the console of all routers, and enter privileged mode.
Step 2. To use TCL scripts on the CLI, a special shell (mode) is used. This allows the router to
differentiate the TCL syntax from IOS XE syntax.
Use the tclsh command to enter TCL mode.
tclsh
Step 3. From the TCL shell, ping the loopback IP address of every other router.
These commands can be copied and pasted from the Ping Sweep.txt document located
in the LISP Intermediate folder on the desktop of the Jump Host.
foreach address {
192.168.255.1
192.168.255.2
192.168.255.3
192.168.255.4
192.168.255.5
192.168.255.6
} { ping $address source loopback 0
}
Note: Do not miss the closing bracket } when copying and pasting. It is a required character on its own line.

Figure 0-1: Successful TCL Script
All pings should succeed on all six routers.
Step 4. Use the tclquit command to exit the TCL shell and drop the CLI back to privileged EXEC
mode.
tclquit
Figure 0-2: TCLquit Example
Note: TCL scripts are beyond the scope of this lab, but they are used here for expediency. TCL scripts are natively
supported on IOS version 12.3(2)T and later. TCL is very powerful and is often used in conjunction with EEM scripts.
Modern IOS-XE has begun to support Python scripting as well as TCL.

Exercise 1: LISP xTR and MS/MR Configuration

IP Reachability has been confirmed between the loopback interfaces. This also confirms that the
underlay IS-IS protocol is working properly, as it carries the reachability information for these loopbacks.
On this IS-IS underlay, a LISP domain (LISP Network / LISP Overlay) will be created and overlaid.
Task 1 - Basic LISP xTR Configuration – EdgeNode1
Step 5. Connect to the console of EdgeNode1, and enter privileged mode.

Step 6. Enter global configuration mode.
configure terminal
Step 7. Configure the LISP routing protocol (enable the service, and enter router configuration
mode).
router lisp
Step 8. Enable the router to be an ITR for IPv4 addresses.
ipv4 itr
Step 9. Enable the router to be an ETR for IPv4 addresses.
ipv4 etr
Step 10. Define the ITR IPv4 Map Resolver as 192.168.255.4.

(Loopback IP Address of ControlPlaneNode)
Remember that an ITR sends the EID-to-RLOC map resolution

requests to the map resolver.
ipv4 itr map-resolver 192.168.255.4
Step 11. Define the ETR IPv4 Map Server as 192.168.255.4, and specify a key EN1-KEY.
Remember that an ETR registers EID-to-RLOC mappings with the Map Server.
The key is used as a basic security mechanism to stop rogue ETRs from creating bogus
mapping. This requires both sides to have matching keys.
ipv4 etr map-server 192.168.255.4 key EN1-KEY

Step 12. Define a static LISP database mapping using the following criteria:
• EID Prefix Space: 192.168.10.0/24
• RLOC: Loopback 0
• Priority: 10
• Weight: 10
database-mapping 192.168.10.0/24 ipv4-interface loopback 0 priority 10 weight 10
Step 13. Exit out of global configuration.
end
Figure 1-1: LISP xTR Configuration – EdgeNode1
1. A LISP Interface is created and changes to the up state.
Step 14. Connect to the console of EdgeNode2, and enter privileged mode.
Step 15. Enable the LISP routing protocol, and configure the router to be an xTR for the IPv4
address-family.
configure terminal
router lisp
ipv4 itr
ipv4 etr
Step 16. Define the ITR Map Resolver using the loopback IP address of ControlPlaneNode.
Step 17. Define the ETR Map Server using the loopback IP address of ControlPlaneNode.
Use the key value EN2-KEY.

Step 18. Define a static LISP database mapping using the following criteria:
• EID Prefix Space: 192.168.20.0/24
• RLOC: Loopback 0
• Priority: 10
• Weight: 10
Step 19. Exit out of global configuration mode.
end
Figure 1-2: LISP xTR Configuration – EdgeNode2
1. A LISP Interface is created and changes to the up state.

Task 3 - Basic LISP xTR Configuration – BorderNode
Currently, BorderNode does not have any EID-prefixes to register with the Map Server. In
Campus Fabric / SDA, the Border Node’s job is to connect two disparate, internal fabrics together. It is
sometimes called an Internal Border Node or simply Fabric Border. A border node would be used in a
deployment that has another site, such as a data center or secondary headquarters, where a separate
domain of LISP is running. The border node’s job would be to connect these two LISP domains together.
Configuring a border route to allow traffic traversal between two separate LISP domains will be covered
in later labs.
For the purposed of this lab, a simplified LISP xTR configuration will be added to BorderNode so that it
can speak LISP. This will allow it to join the overlay. However, it will not participate in EID mappings in
this lab. The main role of the border node at this point in this SDA series is to connect to the
DefaultBorder. In terms of actual packet forwarding, this router acts more like the underlay; it is not
processing (encapsulating / decapsulation) the LISP packets. It is forwarding based on the outer source
and destination IP address. The border node will be used for additional purposes later in the series.
Note: In some deployments, the border node and default border will be the same device. However, the lab has kept
the roles separated onto different devices – to keep the same topology throughout this lab series, but also to help to
clearly show which LISP and BGP commands are used on which role.
Step 20. Configure BorderNode similarly to the edge nodes.

Begin by enabling the LISP protocol and enabling the ETR and ITR roles.
configure terminal
router lisp
ipv4 itr
ipv4 etr
Step 21. Define only the ITR Map Resolver pointing to the ControlPlaneNode’s Loopback0.
Figure 1-3: LISP xTR Configuration – BorderNode
Note: Because BorderNode will not be performing any EID-Mappings, only the Map Resolver configuration was
defined. The LISP RFCs defined LISP roles as modular. Each LISP role could be an independent device. This is
illustrated here by not using the IPV4 ETR Map Server commands in our LISP configuration. That configuration is
only necessary for an ETR, as it would register mappings of EIDs to RLOCs.

Task 4 - Basic LISP MS/MR Configuration – ControlPlaneNode
On ControlPlaneNode, two LISP sites will be created, one for each edge node’s GigabitEthernet 1/0/11
subnets. However, separate sites are not required. In fact, later labs will use a single site, uci, for the
whole fabric domain. Separate sites are used here to enforce the configuration syntax and to leave the
more advanced commands (for a single site for the fabric) for a later lab.
Step 23. Connect to the console of ControlPlaneNode, and enter privileged mode.
Step 24. Enter global configuration mode.
configure terminal
mode).
router lisp
Step 26. Configure the router to be a Map Server for the IPv4 address-family.
ipv4 map-server
Step 27. Configure the router to be a Map Resolver for the IPv4 address-family.
ipv4 map-resolver
Step 28. Create a LISP site named EN1, and enter LISP site configuration mode for this site.
site EN1
Step 29. Configure the site authentication key using the key value EN1-KEY.
authentication-key EN1-KEY
Step 30. Configure the EID prefixes associated with this site.
Only the EID-space specified here can be registered, and this can only be done by the
router which has the matching authentication key. Other EID-prefixes will not be
registered.
This is the subnet associated with EdgeNode1’s GigabitEthernet 1/0/11 interface.
eid-prefix 192.168.10.0/24
Step 31. Exit LISP site configuration mode for EN1.
exit

Step 32. Create another LISP site named EN2, and enter LISP site configuration mode for this site.
site EN2
Step 33. Configure the site authentication key using the key value EN2-KEY.
Step 34. Configure the EID prefixes associated with this site.
This is the subnet associated with EdgeNode2’s GigabitEthernet 1/0/11 interface.
eid-prefix 192.168.20.0/24
Step 35. Exit LISP site configuration mode for Site-2.
exit
end
Note: Both BorderNode and DefaultBorder will use ControlPlaneNode for mapping resolutions. This engages the
Map Resolver functionality (role) of the LISP control plane. We do not need to define a site for either border, as
these routers will not be registering EID-Prefixes with the Map Server. Registering would engage the Map Server
functionality of the LISP Control Plane.
Figure 1-4: LISP Map Server and Map Resolver Configuration – ControlPlaneNode
Note: Notice that no LISP0 interface is configured or brought Up. ControlPlaneNode is not actually performing
encapsulation and de-encapsulation of data packets from the endpoints in the EID-space. However, the router is
listening for LISP requests and mappings on all interfaces with IPv4 address assignments.

Task 5 - Simplify Future Troubleshooting and Verification
IP LISP source-locator command
When sending a LISP-encapsulated packet (data or control message), a destination lookup is done to
determine the appropriate outgoing interface per normal routing behavior. This outgoing interface is
sometimes called the fabric-facing interface. By default, the IPv4 address of this physical egress
interface is used as the source locator (RLOC) address for the outbound LISP encapsulated packets.
In many deployments, it might be necessary to use the IPv4 address of a different interface as the
source locator for the outbound LISP-encapsulated packets rather than that of the physical outgoing
interface. This is commonly needed when an ITR has multiple fabric-facing interfaces. Loopback
interfaces are generally used for stability purposes, as the state of the Loopback should always be
Up/Up.
Using the ip lisp source-locator command instructs the ITR to use the address of a specific interface as
the source locator (RLOC) address for the outbound LISP-encapsulated packets rather than the address
of the fabric-facing physical interface. This command is applied on all fabric-facing interfaces, effectively
overriding the physical IP address (in the LISP packets). LISP packet and LISP message troubleshooting
can be simplified when the source and destination IP address are predictable. The ip lisp source-locator
command makes this source predictable.
Once this command is configured, the output of show ip lisp will verify this configuration on
LISP-speaking routers. The source-locator command also simplifies reading, interpreting, and
troubleshooting LISP site mappings (EID-to-RLOC mappings) when running the show lisp site command
on Map Servers. Both show commands are demonstrated in the next exercise.
Note: The use of this command is also important for maintaining locator consistency between the two xTRs when the
rloc-probing command is used. RLOC probing and other LISP probes are covered in later labs.
Step 37. Connect to the console of EdgeNode1 and EdgeNode2, and enter
privileged mode.
Step 38. Enter interface configuration mode for GigabitEthernet 1/0/12.
configure terminal
interface gigabitEthernet 1/0/12
Step 39. Configure Loopback 0 as the source-locator for LISP packets.
ip lisp source-locator Loopback 0

Figure 1-5: LISP Source Locator Configuration – EdgeNode1
Figure 1-6: LISP Source Locator Configuration – EdgeNode2
Step 41. Connect to the console of BorderNode, and enter privileged mode.
Step 42. Configure Loopback 0 as the source-locator for LISP packets for both fabric-facing
interfaces.
configure terminal
interface GigabitEthernet0/0/0
exit
end
Figure 1-7: LISP Source Locator Configuration – BorderNode
Step 44. Connect to the console of ControlPlaneNode, and enter privileged mode.
interfaces.
configure terminal
interface TenGigabitEthernet1/0/1
exit
end

Figure 1-8: LISP Source Locator Configuration – ControlPlaneNode
Step 46. Connect to the console of DefaultBorder, and enter privileged mode.
interfaces.
configure terminal
exit
end
Figure 1-9: LISP Source Locator Configuration – DefaultBorder
Note: The remainder of the DefaultBorder’s LISP configuration will be completed in Exercise 4. Steps 46-48 were
placed in this exercise since the similar configuration is performed on the other LISP routers here. Although
DefaultBorder has no other LISP configuration or an associated RLOC yet, the commands in the steps above are
still accepted.
However, for this command to be accepted as valid by the CLI parser, the defined source-locator interface must be
have an IP address associated with it. The Loopback 0 interface configuration was present on the device due to the
initial configurations. Once the LISP configuration is completed, interface Gig 0/0/1 and Gig 0/0/2 will then utilize
Loopback 0 as the source address for LISP packets. This will be verified in Exercise 4.

Exercise 2: xTR Verification, Registration, and Ping Tests
Task 1 - Verify the LISP Control Plane Configuration
A show command will be utilized to confirm the task configurations in Exercise 1.
Step 49. Connect to the consoles of EdgeNode1, EdgeNode2, ControlPlaneNode, and

BorderNode and enter privileged mode.
Step 50. Use the show ip lisp command to verify the LISP control plane configuration completed
in Exercise 1.
show ip lisp
Figure 2-1: Show IP LISP – EdgeNode1
1. The router is enabled as an ETR and an ITR.

2. The MS and MR are defined as the loopback of ControlPlaneNode.
3. The local RLOC is the Loopback 0 IP address.
4. Gig 1/0/12 will use Loopback 0 as the source address for LISP packets (Exercise 1, Task 5).

1. The router is enabled as an ETR and an ITR.

3. The local RLOC is its loopback IP address.
4. Gig 1/0/12 will use Loopback 0 as the source address for LISP packets (Exercise 1, Task 5).

Figure 2-3: Show IP LISP – BorderNode
1. The Router is enabled as an ETR and an ITR.

3. No local RLOC is defined as this router will not be performing EID mappings.
4. Gig 0/0/0 and Gig 0/0/1 will use Loopback 0 as the source address for LISP packets.

Figure 2-4: Show IP LISP Output – ControlPlaneNode
1. The router is enabled as a Map Server and Map Resolver.

2. Like BorderNode, it does not have an RLOC, as this router will not be performing EID mappings.
3. TenGig 1/0/1 and TenGig 1/0/2 will use Loopback 0 as the source address for LISP packets.

Task 2 - Verify the LISP Control Plane Functionality (Bidirectional Communication)
LISP Internet Gopher (lig) will be used to verify the LISP control plane communications between the
edge nodes and the control plane node.
Recall from the Basic LISP for SDA lab that the lig self command works by substituting the router’s local
EID prefix in place of the destination EID when the router sends a map request to the configured map
resolver. For the edge nodes, this means they will use the subnet assigned to their GigabitEthernet
1/0/11 interfaces, as this is the EID-prefix defined by the database-mapping command in Exercise 1.
This command also causes the edge nodes to register the EID-prefix space with the Map Server.
Note: Lig can also be used to find resolutions for any registered EID-prefixes using the command lig <ip address>.
Note: Lig is not required to register the EID-prefix space, although it is useful, as it both registers the prefix space and
confirms bidirectional connectivity (IP reachability and communication) between the xTR and the MS.
Step 51. Register the EID-prefix space on EdgeNode1 with the Map Server.
lig self ipv4
Figure 2-5: Lig Self – EdgeNode1
1. The router is able resolve itself from the Map Resolver.

2. The mapping entry is complete.
Step 52. Register the EID-prefix space on EdgeNode2 with the Map Server.
lig self ipv4
Figure 2-6: Lig Self – EdgeNode2
1. The router is able resolve itself from the Map Resolver.

2. The mapping entry is complete.

Task 3 - Verify the LISP EID Registrations
Because lig has been performed, prompting an EID-prefix space mapping, the Map Server should have
the LISP site information fully populated.
Step 53. Verify the LISP site information on ControlPlaneNode.
show lisp site
Figure 2-7: LISP Site Registration
1. Each site has registered. Notice the registrant is listed as the loopback 0 IP address of the edge
node. This is due to the ip source locator command in Exercise 1.
2. Each edge node has registered its corresponding EID-prefix space.
Task 4 - Verify the LISP Map-Cache Entries
Step 54. Display the current static and dynamic IPv4 EID-to-RLOC map-cache entries on
EdgeNode1 and EdgeNode2.
show ip lisp map-cache
Figure 2-8: LISP Map-Cache – EdgeNode1
1. The LISP default entry

2. The action to take for a map-cache miss
(This is used when there is no cache entry or the default entry is matched).
3. The registered EID-prefix and the RLOC this prefix is associated with
4. How this EID-space was learned

Figure 2-9: LISP Map-Cache – EdgeNode2
1. The LISP default entry

2. The action to take for a map-cache miss
(This is used when there is no cache entry or the default entry is matched).
3. The registered EID-prefix and the RLOC this prefix is associated with
4. How this EID-space was learned
Note: The 0.0.0.0/0 entry in Figure 2-8 and 2-9 is called the LISP default entry. It is always present in the LISP
cache with the expires: never keywords. It causes a map-request to be made if a more specific entry does not exist
in the cache or if no entry exists. This is indicated with the keywords static send map-request.
If there is not a current cache entry, this is referred to as a map-cache miss. A map-cache miss will always match
the default entry. This LISP default entry is critical to understand when troubleshooting LISP packet forwarding.

Task 5 - Confirm LISP Control Plane, LISP Data Plane, and IP Reachability
To confirm the internal fabric (LISP Overlay) is working correctly, pings will be used. PC-1 and PC-2
should be able to communicate with each other via ICMP. Interestingly, LabAccessSwitch should have
no knowledge on how to reach either PC-1 or PC-2, despite being the transit path between edge nodes
to which the PCs are directly connected. The LabAccessSwitch is in the forwarding path for the ICMP
packets between the PCs, although due to LISP encapsulation, only sees the outer IP header.
Note: LabAccessSwitch only sees the outer IP header and not the inner headers of the packet.
Header visualization will be covered in Exercise 7.
Step 55. Connect to the console of PC-1 and initiate a ping to PC-2.
ping 192.168.20.200
Figure 2-10: PC-1 to PC-2 Ping
1. Notice the classic indicator that a lookup was performed.

This indicates that EdgeNode1 did not have a LISP map-cache entry for the EID-space associated
with EdgeNode2. A second ping would have 100% success.
Step 56. Connect to the console of PC-2 and initiate a ping to PC-1.
ping 192.168.10.100
Figure 2-11: PC-2 to PC-1 Ping
1. Notice the classic indicator that a lookup was performed.

Step 57. Connect to the console of the LabAccessSwitch and attempt to ping the PCs.
ping 192.168.10.100
ping 192.168.20.200
Figure 2-12: R6 (LabAccessSwitch) Pings to PCs
1. Both pings failed.

This is the expected and desired result. LISP is being routed over the underlay.
Note: The two positive ping results between PC-1 and PC-2, along with the negative ping result between
LabAccessSwitch and the PCs shows that LabAccessSwitch is not part of the fabric - it is truly an underlay (or
intermediate node) device, although it still forwards the LISP encapsulated packets that traverse it.

Exercise 3: BPG Configuration and Basic Verification

Now that internal LISP communication is configured, verified, and functional, communication outside of
the Fabric (LISP site) will be established. For communication (encapsulation/de-encapsulation) between
LISP and non-LISP sites, LISP uses a role known as a Proxy xTR. The configuration of a PxTR can become
very complex, very quickly. In the final SDA form, the proxy-XTR configuration is among the more
complex LISP router configurations due to the interaction between LISP, BGP, and VRFs. This guide
begins with simplistic configuration to solidify initial concepts before adding the additional complexity
showcased in later labs.
Background
In Campus Fabric / SDA the PxTR is called the Default Border Node. The word default is meant to
reference a default route. In a classic enterprise network design, the PxTR, from a routing perspective,
would be called the gateway of last resort. In an enterprise network design, this device is generally the
internet edge or WAN edge router. These terms are mostly synonymous, although referring to different
design architectures and network architectures. Whichever architecture the term sources it genesis,
each has the same role: routing to unknown destinations outside of the local network.
Default Border Node = Proxy xTR = Gateway of Last Resort = (usually) Internet Edge
When looking at the function of an internet edge router, it will generally have a default route pointed to
the ISP. Additionally, it may be router peering and route exchanging with the ISP. If the router is
peering, this is generally done in one of two ways:
1. Using a customer edge (CE) to provider edge (PE) peering in MPLS networks with an Interior
Gateway Protocol (IGP) such as OSPF or EIGRP
2. Using BGP (in non-MPLS WANs)
In this lab environment, the DefaultBorder will peer with the ISP using BGP. BGP, as of this writing, is
the only supported protocol in SDA to communicate outside of the fabric.

Border Gateway Protocol – BGP
Border Gateway Protocol (BGP) stands unique among other routing protocols. RIP, OSPF, EIGRP, and
IS-IS (IGPs) are used to route between devices that are under the same administrative control. Devices
under the same administrative control are referred to as an autonomous system (AS) or being in the
same autonomous-sytem. To route between separate autonomous systems, BGP is used. BGP is the
protocol of the internet, and in fact, is the reason you were able to receive this document and connect
to the lab environment. 😊
There are some designs where BGP is used as a routing protocol between endpoints and devices inside
of an autonomous system, acting almost as an IGP. These are corner-cases. Generally speaking, BGP is
used to communicate between autonomous systems, not inside autonomous systems.
One form of BGP can carry IPv4, IPv6, and multicast information. This is called multi-protocol BPG or
MP-BGP. MP-BGP uses the address-family syntax, similarly to other technologies (such as VRFs) that are
dual-stack aware. Each of these protocol types (IPv4 unicast and multicast, IPv6 unicast and multicast,
VPNv4) can be configured under the BGP router configuration with address-family syntax. However, this
lab will use the traditional IPv4 (non-address-family) syntax. This is done for simplicity.
Note: Multiple address families and full dual-stacks are common in modern networks. There is a router configuration
command bgp upgrade-cli that modifies traditional non-address-family BGP configuration into the address-family
configuration syntax. This ensures the configuration performed in today’s lab will be valid and compatible with future
address-family BGP configurations.
BGP Variants
BGP has two variants: iBGP and eBGP (sometimes called IBGP and EBGP). These stand for internal and
external BGP, respectively. eBGP is used between BGP peers located in different autonomous-systems
from one another (such as the lab’s LISP fabric and the ISP), while iBGP is used between routers inside of
the same AS. iBGP is commonly used in a transit AS – where routes from an external AS need to be
carried through a separate AS to then be advertised out to another external AS.
Figure 3-1: eBGP and iBGP Visualized

For SDA, iBGP will be important when the default border node and control plane node are two separate
devices (but are residing in the same AS). In SDA, iBGP is used to share EID mapping information
between those two LISP nodes. The topology and exercises of this lab do not require this functionality,
despite the default border and control plane being separate routers. Later labs will require this
functionality and will address iBGP at that time. There are special considerations with iBGP that do not
apply to eBGP.
BGP is a point-to-point protocol that forms adjacencies between neighbors (called peers) using TCP
sessions with a destination port 179. In contrast, internal routing protocols (IGPs) generally use
multicast addresses to form adjacencies. While IGPs allow running multiple instances of a routing
protocol, a BGP router can be a member of only one autonomous system. This means only a single
instance of BGP runs per router.
Note: IS-IS does not rely on IP or multicast addresses to form adjacencies.
In BGP, each peer (neighbor) must be configured to specifically listen for each other peer in order to
form an adjacency. In this lab, the ISP already has that configuration in place - the ISP router is listening
for a peering relationship with DefaultBorder and itself is already peered with NewYork. Additional
information on BGP will be covered in depth in later labs. The configuration in this exercise is
deliberately kept simple to help reinforce concepts.
Task 1 - Basic BGP Configuration – DefaultBorder
Basic BGP Configuration is very straight-forward.
1. Enable the BGP routing process for an Autonomous System (AS).

2. Define the BGP peer(s) along with their Autonomous System.
3. Activate the exchange of information (NLRI) with a BGP peer.
Note: NLRI stands for network layer reachability information and will be covered later in the lab.
Step 59. Enable the BGP process for Autonomous System 5.
configure terminal
router bgp 5
Step 60. Define the ISP router as a neighbor using:

• Neighbor address: 198.51.100.7
• Autonomous System: 7
neighbor 198.51.100.7 remote-as 7

Step 61. Activate the exchange of information (NLRI) with neighbor 198.51.100.7.
neighbor 198.51.100.7 activate
Figure 3-2: DefaultBorder - Basic BGP Configuration - CLI
1. The BGP neighbor adjacency is formed and automatically logged to the console.
2. Note the seven (7) seconds between the end of the command and the adjacency forming.
BGP may converge slowly, although it does converge reliably.
Note: The BGP peering relationship has been formed and prefix information is being exchanged. However,
DefaultBorder is currently only receiving information. It is not sending any prefix advertisements at this time, as
none have been configured to be sent. However, the existing configuration on the ISP will be advertising prefix
information to the DefaultBorder. This is shown in the network statements below.
Figure 3-3: ISP Existing BGP Configuration
This output also showcases the address-family syntax which is the default in modern IOS software. The non-address
family syntax commands are still accepted in modern IOS, although the CLI will not tab-autofill / tab-autocomplete for
you. Please type the BGP commands as displayed in the lab guide (in the applicable sections) rather than using
autocomplete.

Task 2 - Verify BGP Adjacency and Prefix Advertisement
There are several commands available to verify adjacency and the reception of NLRI. Broadly speaking,
show ip route will very likely verify routes learned by BGP. Because eBGP has a very low administrative
distance (20), its routes are almost always injected into the global routing table of the local router. As a
reminder, only static routes have a better (lower) default administrative distance.
One BGP command can verify neighbor adjacencies and routing information at one time.
Step 63. From the console of DefaultBorder, verify its BGP neighbor adjacencies and routes
learned from BGP using the show ip bgp command.
show ip bgp
Figure 3-4: BGP Verification
1. The router ID was not explicitly configured. The IP address of Loopback 0 was used
automatically. This behavior is common in most routing protocols.
2. The networks (prefixes / NLRI) learned from the neighbor ISP
3. The next hop address to reach the prefix
4. These items have to do with BGP path selection. BGP path selection, attributes, and
communities are outside the scope of this lab.
Note: Notice the * and > icons to the left of the network entries (NLRI). The asterisk indicates that it is a valid route;
DefaultBorder has IP reachability to that address.
The greater than symbol (>) indicates it is the best route. Best route logic is used when a router knows how to reach
the same prefix from multiple BGP peers. A best route is taken from the BGP routing information base (RIB) and
presented as a candidate for the global routing table RIB. If there are no other routes to the same prefix with a lower
administrative distance, a BGP best route will be present in the global routing table show with the show ip route
command.
77.77.77.77/32 is the loopback IP address of the ISP router. It is being advertised by the ISP to illustrate
NLRI exchange, prefix advertisement, and BGP configuration in the Initial Configuration files.
The depth that this lab went to in BGP configuration is only sufficient for basic neighbor adjacency. As noted before,
PxTR configuration can become very complex. To keep the focus on Campus Fabric / SDA (and not complex BGP),
only basic skills for BGP are covered in this lab.

Task 3 - Verify BGP Neighbors
Adding an additional argument to the show ip bgp command will display the BGP path, prefix, and
attribute information for all connections to all BGP neighbors. It is the rough equivalent to show isis
neighbors or similar commands for other interior routing protocols. Using this additional argument
displays the BGP version, number of sent and received BGP messages, and the state of the neighbor.
While the actual output is very short, a significant amount of information can be gained from this
command.
Step 64. From the console of DefaultBorder, verify its BGP neighbor adjacencies using the
show ip bgp summary command.
show ip bgp summary
Figure 3-5: BGP Neighbor Verification
1. The Autonomous System of the local router (DefaultBorder)

2. The BGP peer and its IP address
3. The AS of the BGP peer
4. The number of sent and received messages between the peers
5. The total time the adjacency has been up
6. The number of prefixes learned via this neighbor

Packet Flow into the LISP Domain
Traffic from outside of the LISP domain sent into the LISP domain has a unique traffic flow. As the
packet enters the PITR (DefaultBorder), the router sees the destination as being part of an EID-space
known to the LISP Fabric. It reaches out to the MS/MR to resolve the EID-to-RLOC mapping. The
MS/MR provides the RLOC (loopback IP address) of the LISP edge node (ETR) that has registered the EID
(endpoint). DefaultBorder then forwards the packet via the LISP overlay to the RLOC. Once there, the
ETR de-encapsulates the LISP packet, then forwards it natively to the endpoint.
The proxy-xTR configuration will now introduce new commands available under the LISP configuration.
Task 1 - Basic PxTR Configuration – DefaultBorder
mode).
configure terminal
router lisp
Step 67. Enable the router to be an PETR for IPv4 addresses.
ipv4 proxy-etr
Step 68. Enable the router to be an PITR for IPv4 addresses.

Define the routing locator to be used for the PITR.
This RLOC should be the IP address of the Loopback 0.
ipv4 proxy-itr 192.168.255.5
Step 69. Define the IPv4 Map Resolver as 192.168.225.4.

(Loopback IP address of ControlPlaneNode)
Even though it is a proxy XTR, the DefaultBorder still performs the EID-to-RLOC map
resolution requests in order to reach endpoints in the EID-space.
Step 70. Define the source address used for Map Requests.
ipv4 map-request-source 192.168.255.5

Note: Typically, a locator address configured with the database-mapping command is used as the source address
for LISP IPv4 map-request messages. The database-mapping command is not used on a PxTR, so another method
is needed to define the source address for mapping requests. This command may share some overlap with the IP
LISP source locator command, although the PxTR configuration should have both.
Step 71. Please remain in LISP router configuration mode while reading the explanation of the
next command.
Map Cache Command – PxTR
The next configuration command is one of the most confusingly documented CLI commands for
LISP. The command syntax is not very straightforward or intuitive. Different code and device
variations have obscured this command in many reference guides. Mastering this command helps
begin mastery of PITR configuration.
Figure 4-1: PxTR Map-Cache Syntax
When a device is configured as a PITR, it must also be configured with information defining the
extent of the LISP EID space it is proxying for. This command allows the PITR to send Map Requests
to determine EID-to-RLOC mappings. It defines the address range that will trigger a Map Request.
The idea is that the PITR will only send requests for addresses that are part of the LISP domain,
defined by this map-cache command.
Why the Map-Cache Command is Important
Recall from Figures 2-8 and 2-9 that on xTR routers, a LISP default entry is always present in the LISP
cache with the expires: never keywords. This tells the xTR to perform a map-request for unknown
destinations. This is indicated with the keywords static send map-request in the output of show ip
lisp map-cache. The LISP default entry ensures that the xTRs are querying the MS/MR for mapping
information that is then populated in the edge node’s map cache. The map-cache is how LISP
forwarding decisions are made by a router.
On a PITR, a LISP default entry does not exist. Therefore, no LISP map-cache exists.
Also, without the map-cache command on the PITR, the LISP0 interface will not be created or
brought up.
Step 72. Using the map-cache command, define the EID-space for which the PITR
will make map requests.
Use the summary address 192.168.0.0/16.
map-cache 192.168.0.0/16 map-request

Figure 4-2: DefaultBorder PxTR Configuration – CLI
1. The map-cache command caused the creation of the LISP0 interface and changes the status to
the up state.

Task 2 - Basic PxTR Verification
The proxy does not have any EID to map to its RLOC, so the lig command would not appropriately (fully)
verify the LISP control plane functionality based on the LISP configuration present on the
ControlPlaneNode.
Step 74. Use the show ip lisp command to verify the PxTR configuration.
show ip lisp
Figure 4-3: Show IP LISP – DefaultBorder
1. The router is enabled as a PITR with a local RLOC of loopback 0 (192.168.255.5).

2. The router is enabled as a PETR.
3. The IP address for LISP map requests is also Loopback 0 (192.168.255.5).
4. The MS is ControlPlaneNode’s Loopback 0 (192.168.255.4).
5. The local ITR RLOC (192.168.255.5)
6. Gig 0/0/1 and Gig 0/0/2 will use Loopback 0 as the source address for LISP packets.
This configuration item was completed in Exercise 1, Step 47.

Task 3 - Configure Edge Nodes to Use the Proxy Egress Tunnel Router
As verified earlier in the lab, the internal LISP routers can communicate with each other. Endpoints PC-1
and PC-2 have bidirectional communication across the LISP Overlay.
Once the LISP and BGP configuration is completed, PC-1 and PC-2 will attempt to contact PC-3. This will
be the final verification used in later exercises. When EdgeNode1 and EdgeNode2 reach out to the
MS/MR (ControlPlaneNode) to learn how to reach destinations outside of the LISP domain - such as PC-
3 - they will receive a negative map reply. This means that the Map Server has no local mapping
knowledge on how to reach that destination. This negative map reply will be stored as a negative cache-
entry in the lisp map-cache on the edge nodes. This negative cache entry would normally cause the edge
nodes to forward the traffic natively, without LISP encapsulation, using the underlay.
Note: For clarification, in the screen shot below, EdgeNode1 sent a lig request to the MS/MR asking for information
on how to reach PC-3 (198.18.133.30). A negative map-reply was received, creating the negative map-cache entry.
This entry tells EdgeNode1 to forward the packet natively (via the underlay).
Figure 4-4: Negative Cache Entry with Forward Native Example
1. Negative Cache Entry

2. The action for items that meet the cache entry (196.0.0.0/6).
Natively forwarding the packet will result in the packet being dropped, as the edge nodes do not have a
default route and will have no direct knowledge on how to reach subnets outside of the IS-IS underlay
and LISP overlay.
The LISP xTR’s must be made aware of the PETR and that router’s LISP services. This following command
configures the edge nodes to use the proxy router when they receive a negative map reply from the
Map Resolver. Rather than forwarding the packet natively, the packet will be forwarded across the LISP
overlay. It will be sourced from the edge nodes and destined to the DefaultBorder.
Step 75. Connect to the console of EdgeNode1, EdgeNode2, and enter configuration mode.
Step 76. From LISP router configuration mode, enable the ITR to use proxy ETR services.
Use the Loopback IP address of DefaultBorder as the PETR.
configure terminal
router lisp
ipv4 use-petr 192.168.255.5
end

Note: More than one PeTR can be defined, although special care must be taken to direct the traffic to the proper
proxy. This allows using the priority and weight command arguments at the end of the ipv4 use-petr command for
load-balancing. This is beyond the scope of this lab, although is noted here for completeness.
Step 77. Exit global configuration mode.
Figure 4-5: Pointing to the Proxy – EdgeNode1
Figure 4-6: Pointing to the Proxy – EdgeNode2
Note: For clarification, the screen shot below was taken after the ipv4 use-petr command was applied. Here,
EdgeNode1 uses lig to request mapping-information for PC-3 (198.18.133.80). It still receives a negative-map reply
from the MS/MR. However, notice the difference in the lisp map-cache entry now.
Figure 4-7: Negative Cache Entry with Encapsulating to proxy ETR Example
1. Packets will be LISP encapsulated and forwarded to the Proxy-ETR.
Note: There is an additional use case for the ipv4 use-petr command. By default, when a LISP router forwards
packets to a non-LISP site natively (not LISP encapsulated), the source IP address of the packet is that of an EID.
When the ISP provider side of the network is configured with strict unicast reverse path forwarding (uRPF) or an anti-
spoofing access list, it may consider these packets to be spoofed and drop them since EIDs are not (generally)
advertised in the provider core network. In this case, instead of natively forwarding packets destined to non-LISP
sites, the ITR encapsulates these packets using its site RLOC as the source address and the PETR as the
destination address. Without the use-petr command, packets would be natively forwarding to the non-LISP domain.

Task 4 - Verification of PeTR Configuration – Edge Nodes
Step 78. Use the show ip lisp command to verify each edge node will use the PETR services
provided by the default border.
show ip lisp
1. The Proxy ETR is DefaultBorder’s Loopback 0.
1. The Proxy ETR is DefaultBorder’s Loopback 0.


The configuration thus far has been very straight-forward. Two new commands have been introduced
to the existing LISP xTR configuration. One command points to the proxy, and the other simplifies
troubleshooting. A new command was introduced on the default border to enable static LISP map-
cache. Recall that these commands are:
EdgeNode(router-lisp)# ipv4 use-petr 192.168.255.5

EdgeNode(config-if)# ip lisp source-locator Loopback0
DefaultBorder(router-lisp)# map-cache 192.168.0.0/16 map-request
The LISP configuration of the Proxy xTR is complete. The PxTR is ready to request EID-to-RLOC mappings
from the Map Server when the packet is sourced from outside of the LISP domain and has a destination
in the EID-space. However, some additional steps are needed to set up the routers so that this
resolution can be triggered. Some action (and configuration) needs to pull packets from external
sources into the LISP control plane.
This section involves routing concepts and routing configuration. These items are not specifically related
to SDA, although they are used in SDA.
Challenge question: From a routing standpoint, does the non-LISP network (ISP, New York, and PC-3) have any
knowledge on how to reach PC-1 and PC-2? Let’s find out…
Figure 5-1: PC-3 with a default route to New York
Figure 5-2: New York with a default route to the ISP
Figure 5-3: Known Routes – ISP

ISP has no knowledge on how to reach anything in Autonomous System 5 other than the default border’s
directly connected interface.
There are a few ways to provide the ISP with knowledge of the internal network (AS 5) and specifically
the EID-prefix space. A static route for 192.168.0.0/16 could be configured on the ISP. This works in the
lab, but is not practical in a real-world environment. Instead, DefaultBorder must somehow advertise
the LISP EID-space to the ISP. There are two primary ways to accomplish this, both of which involve
route redistribution.
Redistribution
Redistribution involves taking the routes learned by one method – be it directly connected, statically
created, or via a different routing protocol - and injecting them into a routing protocol. An example
would be redistributing routes learned by OSPF into EIGRP and routes learned by EIGRP back into OSPF.
This type of redistribution is referred to as mutual or two-way redistribution because each routing
protocol’s routing information is redistributed into the other. This should never be done with BGP, even
in the lab.

Figure 5-4: Mutual Redistribution
Redistribution allows a router to exchange routes between different routing protocols. A router keeps
a separate routing information base (RIB) for each routing protocol. Specifically, a separate RIB is kept
for each instance of a routing protocol. A router may be running multiple running protocols such as
EIGRP and OSPF. Just because the router receives a route from OSPF does not mean this route
information will be forwarded into EIGRP. Each routing protocol’s RIB is kept separate from other
routing protocol’s RIBs. The router uses the information in the global RIB (global IP routing table), not
the individual routing protocol RIBSs, to make a forwarding decision.
Redistribution Between the LISP Domain and BGP – Option 1
On the default border, the BGP routing table could be redistributed into LISP, IS-IS, or both.
Redistributing BGP into just one of those protocols would create substantial load on the router. Every
routable destination on the internet would be injected into the routing table of DefaultBorder and then
shared with adjacent routers. The entire infrastructure could be quickly overwhelmed. This is a
solution, but it is an extremely poor design. It should only be considered in a lab environment, and only
if the lab environment is not truly peering with a BGP router on the real internet.

Figure 5-5: Redistribution Option 1
Redistribution Between the LISP Domain and BGP – Option 2
The better option is to redistribute routes from the LISP domain (or routes that match the EID-space)
into BGP, and to do so selectively. This will provide the ISP with the knowledge on how to reach the LISP
EID-space. Different recommendations are made on how to accomplish this. These will vary based on
the code train, device type, and LISP node roles. The classic recommendation for redistributing LISP into
another routing protocol (Table 1, Page 5) is to use route maps and static null routes. This is the method
used in Campus Fabric.
Note: The primary difference between Campus Fabric and Software-Defined Access is that SDA includes the use of
DNA-Center. This means that SDA is largely automated using the DNAC GUI while Campus Fabric is completely
manual using the CLI.
One additional difference is the redistribution method used to allow communication between LISP and non-LISP. In
Campus Fabric, static Null0 routes are paired with route maps. These route maps are then used to selectively
redistribute routes into BGP. In SDA, the entire LISP protocol is redistributed into a VRF in MP-BGP (Multi-protocol
BGP). Both options are valid although each has their own considerations and caveats. MP-BGP adds extreme
granularity at the expense of incredible complexity. VRFs, MP-BGP, and the SDA method of redistribution will be
covered in future lab guides.

Below is an example of the redistribution on the ControlPlaneNode used in SDA when the ControlPlaneNode and
DefaultBorder are separate devices.
router bgp 65004

address-family ipv4 vrf DEFAULT_VN
aggregate-address 172.16.112.0 255.255.255.0 summary-only
redistribute lisp metric 10
exit-address-family
address-family ipv4 vrf Campus

exit-address-family
address-family ipv4 vrf Guest

exit-address-family
end
BGP vs IGPs
When using an IGP (such as EIGRP, OSPF, RIP), configuring that routing protocol involves specifying the
interface or the subnet on which the protocol runs. This is done using network statements underneath
the routing protocol configuration. This enables the routing protocol on the interface(s) that is/are
configured with the IP address(es) that are within the range of the network statement. Once neighbor
adjacencies are formed, the IGP then advertises the subnet assigned to this interface to all its neighbors.
Note: As a quick reminder, the following syntax would be used to enable EIGRP on the interface that matches the IP
address 10.10.10.1 specified in the network command. This address space would also be advertised to adjacent
neighbors.
configure terminal
router eigrp 100
network 10.10.10.1 255.255.255.255
end
BGP works differently. A network statement under BGP is actually identifying NLRI (Network Layer
Reachability Information) that is to be advertised via BGP. NLRI is the prefix information that BGP peers
exchange. It is important not to confuse the network statement in BGP with the network statement in
an IGP.
As stated above, BGP will only advertise information that is explicitly configured. This concept is
referred to as route injection. Route injection is the only way to insert reachability information into the
BGP routing protocol. It can be accomplished with network statements or with redistribution. A
network statement in BGP configuration is an authoritative statement that says, “I can advertise this
destination into BGP.”

For NLRI information to be of any value, and for the network statement to function correctly in BGP, the
router advertising this information must truly have a way to reach that destination. This is true with any
routing protocol. A route advertisement is a promise to deliver packets to addresses belonging to the
advertised prefixes. If a router advertises a destination it does not know how to reach, the whole
routing system falls apart.
Prefixes must already be in the routing table to be injected into BGP. This is a mandatory prerequisite.
There are a number of way for a prefix to be present in the routing table. A prefix will be in the routing
table if it is learned by an IGP, statically assigned, or directly connected. In this deployment, statically
assigned null routing will be used to meet this prerequisite.
Null Routing
Null routing involves pointing a destination to the Null 0 interface using the ip route static route
command. Classic Null static routing (outside of SDA) has three primary use cases.
1. Used as a mechanism to prevent routing loops

2. Used in redistribution (also this lab’s use case)
3. Used when summarizing routes in EIGRP
(This creates a route in the routing table to Null 0 for that summary address).
Task 1 - Verify Prerequisite
DefaultBorder must inject the LISP EID-space into the BGP routing process using redistribution, although
the EID-space must first existing in the routing table for it to do so.
Challenge question: Does DefaultBorder know how to reach the EIDs?
Step 79. From the console of DefaultBorder, use the show ip route command to determine if
either edge node’s EID-space is present in the routing table.
show ip route 192.168.10.0 255.255.255.0

show ip route 192.168.20.0 255.255.255.0
Step 80. Next, use the show ip route command to determine if the 192.168.0.0/16 summary
address for the EID-space – which was entered in Step 72 – is present in the routing
table.
show ip route 192.168.0.0 255.255.0.0

Figure 5-6: Routes to EID-space – DefaultBorder
Step 81. Use the show ip cef command to determine if the router has any knowledge on how to
reach the destinations from the previous two steps. No subnet mask is needed.
show ip cef 192.168.10.0

show ip cef 192.168.20.0
show ip cef 192.168.0.0
Figure 5-7: CEF entries to EID-space – DefaultBorder
1. The EID space is known through LISP0 interface.
Note: In modern Cisco environments, the FIB (Forwarding Information Base) is used to make forwarding decisions if
CEF is enabled. CEF’s FIB maintains a mirror image of the IP routing table along with the next-hop address
information based on the information in the IP routing table.
The routes in Steps 79-81 are not in the Global IP routing table (RIB), but are in the CEF FIB Table. DefaultBorder
has no IP route (RIB) to the EID prefixes. It has a destination through the FIB because LISP operates as an
extension of CEF. The lack of the routes in the RIB mean the perquisite is not met. The routes in the FIB are what
will trigger the resolution to occur once packets are received.
With CEF, when IP routes are copied from the RIB to the FIB, the next-hop address is also copied along with the
egress interface. Recall that the LISP0 interface is the logical boundary between EID and RLOC namespaces. This
boundary interprets and implements LISP forwarding rules for both encapsulation and de-encapsulation.

Task 2 - Null 0 Static Route
To inject a route into BGP, DefaultBorder must know how to reach it. This will be accomplished with a
static route to Null 0. This static route will then be redistributed into the BGP protocol. This will draw
the EID-prefixes to the DefaultBorder, who will then use the map-cache command (configured under the
LISP configuration) process to trigger a resolution (and LISP encapsulation).
Note: Recall that a packet is considered for potential LISP encapsulation dependent on a few factors.
They are sourced from a LISP EID and the destination matches one of the following criteria:
a. The destination is a current map-cache entry.
b. The destination matches a default route with a legitimate next hop.
c. The destination does not match any route.
On a proxy ITR, the rules have a slight variation. The packet does not have to be sourced from a EID. It just has to
be destined to the LISP EID space the router is a proxy for. Recall that this LISP EID-space is configured with the
map-cache command.
Step 83. Define a static IP route for the EID-prefix space with a next-hop of Null 0.
Apply a tag of 123.
configure terminal
ip route 192.168.0.0 255.255.0.0 Null 0 tag 123
Figure 5-3: Static Route to Null0
Route Tagging
In Step 83, a tag of 123 was applied to the static route. A route tag can be used in a route map to
reference a specific route or set of routes in order to make policy decisions on that/those route(s).
Using route tags is also referred to as manipulating redistribution.

Task 3 - Static Route Verification
Note: As the internet edge router, a default border may have other static routes in places. Recall that DefaultBorder
has a default route to the ISP.
Figure 5-4: DefaultBorder’s Static Default Route
Step 85. From the console of DefaultBorder, display the static routes in the running
configuration. Use the pipe to filter the output.
show running-config | include ip route
Figure 5-5: Null0 Route Verification
1. The gateway of last resort route to ISP

2. The static Null 0 route for the EID prefixes
Note: The show ip route static command produces a similar output, although does not show the tag information.
Figure 5-6: Static Route to Null0 – Alternate Verification
Additional static routes may be present in the DefaultBorder to allow NTP connectivity. This output has been omitted
for brevity from the screen shots.
Redistributing the EID-space into BGP
Using the null route, DefaultBorder now has the EID-space in its global IP routing table. Ultimately, a
redistribution command will inject these prefixes into BGP. There are multiple ways to accomplish
injecting a static route into BGP.

A default static route could be injected into BGP using the default-information originate command or
neighbor default-originate command. While outside the scope of this lab, these commands should be
used with caution. Another solution might be to redistribute static routes into BGP using the
redistribute static command. This is problematic if the router has multiple static routes configured, as
all static routes will be redistributed.
The best solution is to redistribute only the specific Null 0 static route. This is a much more granular and
controlled approach. This granular static redistribution is accomplished through a route map and route
tag. The one static route to Null 0 has a tag (123) associated with it. A route map will be configured to
match routes based on that tag. Then, redistribution will be configured to occur only for routes that
have the tag of 123.
Route Maps
A route map is a generic mechanism used in Cisco software. It is configured as a named object, similar
to a named ACL. Route maps must be applied to some process in the router to activate and be effective.
Route maps are most commonly used in both Policy-based Routing (PbR) and in route redistribution.
When used in policy-based routing, route maps direct (take-action) on specific packets. In
redistribution, route maps take-action on an entire route.
There are three general pieces to a route map:

• Clause
• Match
• Set
Route maps are an ordered sequence of statements with a permit or deny. This permit/deny statement
is called a clause. This clause (permit or deny) then has a match and/or set command associated with it.
These are called clause values. A match statement selects packets or routes this clause will apply to.
The set statement modifies the packets or routes matched.
There are four steps to creating a route map for use in route redistribution:
1. Configure the route map with the route-map command, and give it a name.
A deny or permit is used along with a sequence number. This is the clause.
2. In route map configuration mode for the clause, specify the match criteria with the match
command.

3. Optionally, specify the action to be taken with the set command.
Note: As mentioned above, the set command can be used to change attributes of a route when it is redistributed.
However, we will not be changing any route attributes as part of this lab. We are only concerned with using the
match command to identify the one route to be redistributed. The set command is an optional configuration within
route maps.
4. Reference the route map in a routing protocol configuration.
Here is an example route-map for clarity. It uses all the configuration elements. It also references an
ACL.
Figure 5-7: Example Route-Map
1. Creates a numbered access-list 250. This ACL will match an IP packet from any source that has a
destination to host 172.16.1.1.
2. Creates the route map object EXAMPLE through the clause. The clause is a permit value and
sequence number of 10.
3. Specifies the criterion with the match statement. This clause value will match the routes in
access-list 250.
4. Specifies the action with the set command. This modifies the next-hop IP address packets that
match access-list 250.

Task 4 - Route Map Configuration – DefaultBorder
Step 87. Configure sequence 10 of a route map named EID-INJECT. Use a permit clause.
configure terminal
route-map EID-INJECT permit 10
Step 88. Use a match statement to match tag 123.
match tag 123
Figure 5-8: Route-Map Configuration – CLI
Note: As mentioned above, the set command is optional. It is only required when a specific modification is desired
on the routes that are matched by the match clause value.
Reminder: Because our static null 0 route applied tag 123, this route map matches on that route.

Task 5 - Redistribute the Static Null Route using the Route Map
Here is a review of the various configuration portions on DefaultBorder in the Exercise thus far.
a. DefaultBorder has a route to the EID prefixes with a next hop of Null 0.
b. The criteria to advertise a route is met.
c. The route-map is created to match this specific static null route.
d. DefaultBorder can now inject this NLRI (prefix information) into the BGP routing process.
Step 90. From global configuration mode on DefaultBorder, enter BGP router configuration for
the configured AS.
configure terminal
router bgp 5
Step 91. Redistribute the previously configure static route map EID-INJECT.
redistribute static route-map EID-INJECT
Figure 5-9: Redistribution – CLI

Task 6 - Verify NLRI
Step 93. Connect to the console of ISP and NewYork routers, and enter privileged mode.
Step 94. Use the show ip bgp command to verify the NLRI. These routers should now have a
route to reach the EID-space.
show ip bgp
Figure 5-10: Redistribution Verification – ISP
1. The ISP has a route to the EID-space with a next-hop of DefaultBorder.
Figure 5-11: Redistribution Verification – New York
1. NewYork has a route to the EID-prefixes with a next-hop of ISP.
Note: You may have noticed that an RFC 1918 address is being injected into BGP (and hence a private IP address is
being injected into the global routing table of the “internet”). This lab is focused on the basics of getting the PxTR
working. Later labs will focus on optimization and best practices as it relates our final SDA configuration.


Remember, the mechanism to trigger LISP is generally matching a default route or no route. This goes
against traditional routing logic. The Null 0 route goes against traditional routing logic, too. The Null 0
route should black-hole a route entirely. However, the assumption made when using the Null 0 static
route is that the router will have more specific routes in its global routing table. This is one reason a
large aggregate route (/16) is used in both the static route and LISP map-cache commands.
On a LISP PxTR, the Null 0 route is really a placeholder. The Null 0 route asks for packets to be LISP
encapsulated if they match a destination encompassed within that address space. If the LISP map
services are operating properly, the Proxy tunnel router will have a more specific route than a /16 to the
EID-space. The LISP map request message will ask for EID-to-RLOC mapping for /32 (host route). The
MS/MR will return, at largest, a /24 route, as this is prefix space for each configured LISP site.
If the PxTR receives an EID/RLOC mapping and if the PxTR has IP reachability to that RLOC, this
configuration will succeed. Here is the flow: A packet is received from the BGP network through
redistribution, it is matched based on the PxTR map-cache command, the LISP control plane is engaged
prompting a mapping request, the packet is encapsulated and forwarded across the LISP overlay, and
finally the RLOC de-encapsulates the packet and forwards it natively to the EID.
The final verifications of the configuration will include:

• Pings from PC-3 to PC-1 and PC-2
• Pings from PC-1 to PC-3
• Pings from PC-2 to PC-3
To help better visualize the LISP messaging and encapsulation/decapsulate, a small amount of setup will
be involved before the pings. Steps 95-99 are the setup required before the ICMPs are issued by the PCs.
Task 1 - Enable all LISP Debugging – DefaultBorder
On DefaultBorder, the LISP packets of interests are related to remote-EID cache. Recall from the Basic
LISP for SDA lab that remote, from the perspective of LISP, means a cache entry. Entries in the remote-
EID cache will be populated by packets destined for the LISP domain (or specifically for PC-1 and PC-2 in
the lab topology).
Step 95. From the console of DefaultBorder, enable remote-eid cache debugging.
debug lisp control-plane all
Note: There are dozens of LISP debug commands. All LISP debugs can be enabled with the debug lisp control-
plane all command. If used, particularly in production, please do so judiciously, as debugs are processed by the
CPU. In the lab, with such a large number of debugs enabled, expect extremely verbose output.

Figure 6-1: Debug LISP – DefaultBorder
Task 2 - Enable Specific LISP Debugging – ControlPlaneNode
On the Map Server, the map-requests, map-notifies, and negative map-replies are the packets of
interest. Enabling only these debugs will help filter out some of the verbose console logging.
Step 96. On ControlPlaneNode, enable LISP control plane debugging for specific LISP packets.
debug lisp control-plane map-server-map-request

debug lisp control-plane map-server-map-notify
debug lisp control-plane negative-map-reply
Figure 6-2: Debug LISP – ControlPlaneNode
Task 3 - Native Packet Capture #1
As of IOS XE 3.3.0, Catalyst 3850s (and 9300 as of IOS XE 16.5.1) support Embedded Wireshark Capture
natively on the device. This decreases the requirement for SPAN ports and captures
when troubleshooting. This feature will be used to capture the packets entering and exiting from the
LabAccessSwitch ’s Gig1/0/3. This interface is connected to the BorderNode. As all traffic destined
outside of the fabric must traverse this interface, it is an ideal capture location to see the LISP
encapsulation and LISP messaging.
Once this capture is completed, it will be exported to Wireshark on the Jump Host to view in more
detail. The CLI also provides the ability to view the capture, although the Wireshark GUI provides more
granular detail.
Step 97. Connect to the console of the LabAccessSwitch , and enter privileged mode.
Step 98. Use the privilege EXEC command below to define an embedded Wireshark capture.
monitor capture lispcap interface GigabitEthernet 1/0/3 both match any limit packets 1000 file location flash:lispcap
Note: It is extremely important to name the capture using the name above. Please do not deviate from this naming
structure. The command in Step 98 will begin a capture called lispcap that will capture any packets traversing
GigabitEthernet 1/0/3. The file will be limited to 1000 total captured packets and be stored in flash: with the
filename lispcap.

Step 99. Start the capture Wireshark capture with the privilege EXEC command below.
monitor capture lispcap start
Figure 6-3: Packet Capture Configuration – LabAccessSwitch
Task 4 - Clear Existing Map-Cache Entries
The xTRs likely have cache entries in their LISP cache from previous exercises. To ensure a common starting place for the routers the cache will
be cleared.
Step 100. Connect to the consoles of EdgeNode1, EdgeNode2, and DefaultBorder, and enter privileged mode.
Step 101. Clear the LISP map cache.
clear ip lisp map-cache
Figure 6-4: Clear IP LISP Map-Cache – EdgeNode1
Figure 6-5: Clear IP LISP Map-Cache – EdgeNode2
Figure 6-6: Clear IP LISP Map-Cache – DefaultBorder

Note: The default LISP cache timer is 24 hours by default.

This can be seen using the command show ip lisp map-cache.
Figure 6-7: LISP Map-Cache Timers
1. The default LISP cache timer of twenty-four hours

The clear command was used twenty-two seconds before issuing this show command.
Task 5 - Verify the Functionality of the LISP, BGP, and Route-Map Configurations
The configuration of all previous exercises and steps can be verified with the following pings.
Step 102. From the console of PC-3, initiate pings to PC-1 and PC-2. Use a repeat count of 10.
ping 192.168.10.100 repeat 10

ping 192.168.20.200 repeat 10
Figure 6-8: PC-3 Pings to PC-1
1. The classic indicator of a lookup
2. The classic indicator of a lookup

Step 103. From the console of PC-1, initiate a ping to PC-3.
ping 198.18.133.80
1. Another lookup indicator
Step 104. From the console of PC-2, initiate a ping to PC-3.
ping 198.18.133.80
1. Another lookup indicator
Note: In the lab environment, depending on the time between performing the steps, the number of missed ICMP
packets when pinging from PC-1 & PC-2 to PC-3 may vary. The routers and PCs may have some forwarding cache
entries (such as ARP) other than just the LISP cache. The ping from PC-3 to PC-1 and PC-3 to PC-2 (Step 102) will
always have the first ICMP packets time out (miss).

Task 6 - Stop the Packet Capture
Step 105. From the console of LabAccessSwitch, stop the packet capture.
monitor capture lispcap stop
Figure 6-12: Stop Packet Capture – LabAccessSwitch
Note: The number of packets captured and the duration will vary from this screen capture.
Task 7 - Interpreting Debug Messages – ControlPlaneNode
ControlPlaneNode will have debug information on the console. Several lookups have been performed
by various routers as part of the ping succeeding.
Step 106. Use the screen capture below to help interpret the debug output on ControlPlaneNode.
Figure 6-13: Debug Messages – Map Request
Echo Request Packet

1. LISP control message from 192.168.255.5 (DefaultBorder) to 192.168.255.4 (ControlPlaneNode)
2. Map request from 192.168.255.5 for EID 192.168.10.100. Packet is marked as being FromPITR.
3. Internal lookup between the Map Server and Map Resolver

(Remember they are functionally independent roles).

4. The Map request is forwarded to 192.168.255.1 (EdgeNode1).
Echo Reply Packet
5. LISP control message from 192.168.255.1 (EdgeNode1) to 192.168.255.4 (ControlPlaneNode)
6. Map request for 198.18.133.80/32
7. Internal lookup between Map Server and Map resolver with no results
8. Negative map-reply from 192.168.255.4 to 192.168.255.1
This triggers EdgeNode1 to use the proxy.
9. LISP computes thsis aggregate as the largest possible block that does not contain known EID
prefixes.
Table 6-1: Debug Output with Notes – ControlPlaneNode

ControlPlaneNode#
Echo Request Packet
*Sep 25 16:38:19.115: LISP: Processing received Encap-Control(8) message on TenGigabitEthernet1/0/1
from 192.168.255.5:4342 to 192.168.255.4:4342
1. LISP control message from 192.168.255.5 (DefaultBorder) to 192.168.255.4 (ControlPlaneNode)
*Sep 25 16:38:19.115: LISP: Processing received Map-Request(1) message on TenGigabitEthernet1/0/1
from 192.168.255.5:4342 to 192.168.10.100:4342
2. Map request from 192.168.255.5 for EID 192.168.10.100. Packet is marked as being FromPITR.
*Sep 25 16:38:19.115: LISP: Received map request for IID 0 192.168.10.100/32, source_eid IID 0 198.18.133.80,
ITR-RLOCs: 192.168.255.5, records 1, nonce 0x7B5647BE-0xE6D50768, FromPITR
3. Internal lookup between the Map Server and Map Resolver
(Remember they are functionally independent roles).
*Sep 25 16:38:19.115: LISP-0: MS EID IID 0 prefix 192.168.10.0/24 site EN1, Forwarding map request to ETR RLOC 192.168.255.1.
4. The Map request is forwarded to 192.168.255.1 (EdgeNode1).
ControlPlaneNode#
Echo Reply Packet
*Sep 25 16:38:21.128: LISP: Processing received Encap-Control(8) message on TenGigabitEthernet1/0/1
from 192.168.255.1:4342 to 192.168.255.4:4342

5. LISP control message from 192.168.255.1 (EdgeNode1) to 192.168.255.4 (ControlPlaneNode)
*Sep 25 16:38:21.128: LISP: Processing received Map-Request(1) message on TenGigabitEthernet1/0/1
from 198.18.133.80:4342 to 198.18.133.80:4342
6. Map request for 198.18.133.80/32
*Sep 25 16:38:21.129: LISP: Received map request for IID 0 198.18.133.80/32, source_eid IID 0 192.168.10.100, ITR-RLOCs: 192.168.255.1,
records 1, nonce 0xA0F24D30-0x691300DA
7. Internal lookup between Map Server and Map resolver with no results
*Sep 25 16:38:21.129: LISP-0: sending negative map-reply from 192.168.255.4 to 192.168.255.1 for IID 0 196.0.0.0/6.
8. Negative map-reply from 192.168.255.4 to 192.168.255.1
This triggers EdgeNode1 to use the proxy.
9. LISP computes the aggregate as the largest possible block that does not contain known EID prefixes.
Step 107. Disable all debugging on ControlPlaneNode with the undebug all command.
undebug all
Figure 6-14: Disable Debugging – ControlPlaneNode

Note: Some manipulation of the console logs needed to be done to make the output more readable.
While only a few debug commands are in use, the output is quite verbose. Your CLI console messaging will have
very similar information, although it may not be the exact same information and my look slightly different. Depending
on timing and other factors, reproducing the exact same debug may not be possible.
Task 8 - Interpreting Debug Messages – DefaultBorder
DefaultBorder will have a significant amount of debug messages, as all LISP debugs are enabled.
Step 108. Use the screen capture below to help interpret the debug output on DefaultBorder.
There is a tremendous amount of information below in a very small amount of space.
Please read through carefully.
Figure 6-15: Verbose Debug Message – DefaultBorder
1. A packet is received for destination 192.168.10.100/32.

2. The LISP control plane recognized this entry as incomplete in map-cache and
schedules a map-request.
3. A map request is sent from 192.168.255.5 to 192.168.255.4. The packet is marked as being
FromPITR.
4. The map-reply is received from 192.168.255.1.
5. The map-reply contains a record for 192.168.10.0/24 with an
authoritative locator 192.168.255.1.
6. The map-reply is recognized as a remote EID.

7. The map-cache for 192.168.10.0/24 is marked as complete.

8. The map-cache timer is started for this entry.
9. 192.168.10.100/32 is deleted from the control-plane processing.
10. A RIB update is scheduled.
11. The control plane entry for 192.168.10.100/32 is deleted. A less specific reply of
192.168.10.0/24 was received from the 192.168.255.1.
This is expected due to the database-mapping commands on EdgeNode1 and LISP site
commands on ControlPlaneNode.
12. Reachability to 192.168.255.1 is verified and marked as Up, allowing the packets destined for
192.168.10.0/24 to be forwarded.
Table 6-2: Debug Output with Notes – DefaultBorder

DefaultBorder#
*Sep 25 17:21:08.868: LISP: Processing data signal for EID prefix IID 0 192.168.10.100/32
1. A packet is received for destination 192.168.10.100/32
*Sep 25 17:21:08.868: LISP-0: Remote EID IID 0 prefix 192.168.10.100/32,
Change state to incomplete (sources: <signal>, state: unknown, rlocs: 0).
*Sep 25 17:21:08.868: LISP-0: Remote EID IID 0 prefix 192.168.10.100/32, [incomplete]
Scheduling map requests delay 00:00:00 min_elapsed 00:00:01 (sources: <signal>, state: incomplete, rlocs: 0).
2. The LISP control plane recognized this entry as incomplete in map-cache and
schedules a map-request.
*Sep 25 17:21:08.996: LISP-0: IID 0 Request processing of remote EID prefix map requests to IPv4.
*Sep 25 17:21:08.996: LISP: Send map request type remote EID prefix
*Sep 25 17:21:08.996: LISP: Send map request for EID prefix IID 0 192.168.10.100/32
Send map request (1) (sources: <signal>, state: incomplete, rlocs: 0).
*Sep 25 17:21:08.996: LISP-0: EID-AF IPv4, Sending map-request from 192.168.255.5 to 192.168.10.100 for EID 192.168.10.100/32,
ITR-RLOCs 1, nonce 0x46543556-0x1C1F9676 (encap src 192.168.255.5, dst 192.168.255.4), FromPITR.
3. A map request is sent from 192.168.255.5 to 192.168.255.4. The packet is marked as being FromPITR.
*Sep 25 17:21:08.999: LISP: Processing received Map-Reply(2) message on GigabitEthernet0/0/1
from 192.168.255.1:4342 to 192.168.255.5:4342
4. The map-reply is received from 192.168.255.1.
*Sep 25 17:21:08.999: LISP: Received map reply nonce 0x46543556-0x1C1F9676, records 1
*Sep 25 17:21:08.999: LISP: Processing Map-Reply mapping record for IID 0 192.168.10.0/24 LCAF 255, ttl 1440, action none,
authoritative, 1 locator 192.168.255.1 pri/wei=10/10 LpR
5. The map-reply contains a record for 192.168.10.0/24 with an authoritative locator 192.168.255.1.
*Sep 25 17:21:08.999: LISP-0: Map Request IID 0 prefix 192.168.10.100/32 remote EID prefix[LL], Received reply with rtt 3ms
6. The map-reply is recognized as a remote EID.
*Sep 25 17:21:08.999: LISP: Processing mapping information for EID prefix IID 0 192.168.10.0/24
*Sep 25 17:21:08.999: LISP-0: IAF IID 0 SVC_IP_IAF_IPv4, Persistent db: ignore writing request, disabled.
*Sep 25 17:21:08.999: LISP-0: Remote EID IID 0 prefix 192.168.10.0/24, Change state to complete
(sources: <map-rep>, state: unknown, rlocs: 0).
7. The map-cache for 192.168.10.0/24 is marked as complete.
Starting idle timer (delay 00:02:30) (sources: <map-rep>, state: complete, rlocs: 0).
8. The map-cache timer is started for this entry.
*Sep 25 17:21:08.999: LISP-0: Remote EID IID 0 prefix 192.168.10.100/32, Change state to deleted (sources: <>, state: incomplete, rlocs: 0).
9. 192.168.10.100/32 is deleted from the control-plane processing.
*Sep 25 17:21:08.999: LISP: RIB Watch Group default 192.168.255.1 , created.
*Sep 25 17:21:08.999: LISP: RIB Watch Group default 192.168.255.1 , scheduling RIB update.
10. A RIB update is scheduled.
*Sep 25 17:21:08.999: LISP-0: Remote EID IID 0 prefix 192.168.10.0/24, RLOCs pending rwatch update,
defer fwd update (sources: <map-rep>, state: complete, rlocs: 0).
*Sep 25 17:21:08.999: LISP-0: Remote EID IID 0 prefix 192.168.10.0/24, 1 RLOCs pending rwatch update,
Recalculated RLOC status bits from 0x0 to 0x1 (sources: <map-rep>, state: complete, rlocs: 1).
*Sep 25 17:21:08.999: LISP-0: Remote EID IID 0 prefix 192.168.10.0/24, 1 RLOCs pending rwatch update,

*Sep 25 17:21:08.999: LISP-0: Remote EID IID 0 prefix 192.168.10.100/32, Map-reply from 192.168.255.1
returned less specific 192.168.10.0/24 (sources: <>, state: deleted, rlocs: 0).
11. The control plane entry for 192.168.10.100/32 is deleted. A less specific reply of 192.168.10.0/24 was received
from the 192.168.255.1. This is expected due to the database-mapping commands on EdgeNode1 and LISP
site commands on ControlPlaneNode.
*Sep 25 17:21:08.999: LISP: RIB Watch Group default 192.168.255.1 , installing in RIB.
*Sep 25 17:21:09.000: LISP-0: Remote shrRLOC 192.168.255.1, Reachability notification, up* allow* remote.
12. Reachability to 192.168.255.1 is verified and marked as Up, allowing the packets destined for 192.168.10.0/24 to
be forwarded.
*Sep 25 17:21:09.000: LISP-0: Remote EID IID 0 prefix 192.168.10.0/24, No more RLOCs pending rwatch update,
schedule deferred fwd update (sources: <map-rep>, state: complete, rlocs: 1).
Note: The debug lisp control-plane all command produces the most informative output. However, this is at the
expense of debug information that cannot be filtered out of the screen captures. The more specific debug, debug
lisp control-plane remote-eid-cache, produces most of the information above, although leaves out some of the
finer details.
Please remember that a debug … all such as this is best interpreted with the assistance of TAC and/or Cisco
Advanced Services. Some output is meant for troubleshooting by internal resources onl and information about those
debugs are simply not publicly documented.
To see the command output without all the line breaks, a monitor at 1920x1080 resolution is required. Your terminal
program needs to be in full screen as well. The debug outputs in both .png and .txt format are provided to for you in
the Intermediate LISP directory of the desktop of the Jump Host. If exploring the txt files, please use Notepad++ in full
screen for the best viewing experience.
Step 109. Disable all debugging on DefaultBorder with the undebug all command.
undebug all
Figure 6-16: Disable Debugging – Default Border
Task 9 - Copy the Packet Capture to the Jump Host
While the capture can be viewed on the command line using the show monitor capture file
flash:lispcap command, Wireshark can be used to view the packet in more detail.
Step 110. Begin the TFTP program on the Jump Host by double click the 3CDaemon shortcut on
the Desktop.
Figure 6-17: Start 3CDaemon TFTP Program

Step 111. Notice that 3CDaemon will be listening for connections on 192.168.100.50.
Figure 6-18: 3CDaemon Listening Addresses
Step 112. TFTP transfer the capture file from the LabAccessSwitch to the Jump Host.
copy flash: tftp:
lispcap
192.168.100.50
lispcap.pcapng
Figure 6-19: TFTP Copy Commands – LabAccessSwitch
1. Please use the extension .pcapng for the destination file name.
This will ensure that Wireshark can open and recognize the file.
Task 10 - Open and View the Packet Capture
Step 113. Open the Downloads folder on the Jump Host.
Figure 6-20: Jump Host Downloads Directory
Step 114. Double click the lispcap.pcapng file to open the file in Wireshark.

Figure 6-21: Opening Wireshark – Lispcap File
Note: The columns, preferences, and settings of Wireshark have been preconfigured for you. You can expand the
columns if they have shrunk.
The inner source and inner destination columns show the data encapsulated in by LISP. This is the IP header of
the original packet. The outer source and outer destination columns show the information used to forward the
packet on the wire. This is the outside IP header.
Figure 6-22: Outer and Inner IP Headers
Step 115. Apply a filter in Wireshark to view LISP messaging packets.

In the filter field, type in lisp, and press Enter. This filter is case-sensitive.
Figure 6-23: LISP Filter – Wireshark (Before)

Figure 6-24: LISP Filter – Wireshark (After)
The filter field should turn green indicating a valid filter in in place.
Step 116. Use the screen shot below to help interpret the output.
Figure 6-25: Decoding Wireshark - LISP
1. The Inner source and destination

This is the data encapsulated inside LISP.
2. The outer source and destination
These addresses are used to forward the packet on the wire.
3. Notice these (control) packets are encapsulated in LISP (not VXLAN).
4. The encapsulated map request from the Proxy (P-ITR)
5. A map reply message for the EID-space
Step 117. Change the filter in Wireshark to view the pings.

In the filter field, delete lisp, type in icmp, and press Enter.

Figure 6-26: ICMP Filter – Wireshark
The filter field should turn green indicating a valid filter in in place.
Letter case is critical.
Step 118. Use the screen shot below to help interpret the output.
Figure 6-27: Decoding Wireshark – ICMP in LISP
1. The Inner source and destination

This is the original data packet encapsulated inside the VXLAN GPO format by LISP.
2. The outer source and destination
These addresses are used to forward the packet on the wire.
3. Please see the note on code trains and VXLAN at the beginning of Exercise 7.
Step 119. Close Wireshark, although leave 3CDaemon open.

Task 11 - Exercise Cleanup
These cleanup steps are necessary for the next exercise. Please do not skip this Task.
Step 120. From the console of the LabAccessSwitch, remove the exiting capture configuration.
no monitor capture lispcap
Step 121. Use the show monitor capture command to verify the previous step.
show monitor capture
Figure 6-28: Remove Capture and Verify
Note: This command should have no output. If there is output, the capture has not been removed.

Exercise 7: Header Visualization and Final Troubleshooting

RFC Packet diagrams can be challenging to read and understand. Encapsulation can be challenging to
visualize because ultimately, a device is forwarding based on what it sees in the lowest (outer) headers.
The lab topology and exercises provide the perfect opportunity to visualize the packet overhead,
headers, and encapsulation.
Figure 7:1 LISP Packet with LISP Encapsulation
Figure 7-2: LISP Packet with VXLAN Encapsulation
Note: In Figure 7-2 above, the packet overhead for VXLAN encapsulation is shown.
VXLAN will be covered in-depth in other labs in this series. However, we need to briefly mention it here.
Code version is extremely important to note when working with LISP. LISP was first added to traditional IOS in code
train 15.5.2 and to IOS XE in code train 3.15.0S. In these versions of code, the LISP packets are encapsulated using
a LISP header.
On Catalyst 3850s in IOS-XE code version 16.3.3, LISP is encapsulated with a VXLAN header. This is not optional.
LISP, on this platform on or after this code version, can only be encapsulated inside of VXLAN. When LISP is
enabled on the Catalyst IOS-XE platforms, VXLAN encapsulated is enabled by default.
The ability to support VXLAN encapsulation of LISP was not added to the ISR 4400s until IOS XE 16.5.1.
When enabling LISP on ISRs, VXLAN encapsulation is not enabled by default.
To showcase only original LISP encapsulation (no VLXAN), a lab environment would need to utilize devices that have
earlier code versions than noted above. However, the Catalyst 9300 series first shipped with Open IOS XE 16.5.1.
This series of switches can only encapsulate LISP inside of VXLAN. It does not have early code that supports LISP
encapsulated LISP packets. Inclusion of this switch in a lab network impacts the code of every other device.
If any router in the LISP domain encapsulates LISP in VXLAN, then all routers must encapsulate in VXLAN. The
Initial Configuration Files will show that all the ISR Routers have encapsulation vxlan enabled under their LISP
router configuration.
Discussion on the “why” behind VXLAN encapsulation will be included in the next lab in this series: VRF-Based LISP
and Host Mobility.


A new capture will be created on the LabAccessSwitch . This new capture prevents any error messages from overwriting existing files, and
ensures that the captures are disabled at the end of the lab. This capture will be applied to the LabAccessSwitch ’s Gig 1/0/2 interface.
Step 122. Connect to the console of the LabAccessSwitch, and enter privileged mode.
Step 123. Please ensure the previous clean up steps (Exercise 6, Task 11) have been completed.
Step 124. Begin a new capture name with the following criteria
• Capture name: tnetcap
• Interface: Gig 1/0/2
• Packet limit: 1000
• Store packet location: flash:
• Filename: telnetcap
monitor capture tnetcap interface GigabitEthernet 1/0/2 both match any limit packets 1000 file location
flash:telnetcap
Note: It is extremely important to name the capture using the name above. Please do not deviate from this naming structure.
The command above is a single, long, continuous command where the text wrapped to the next line. There is not a break (carriage return).
Step 125. Begin the capture.
monitor capture tnetcap start
Figure 7-1: Packet Capture Configuration – LabAccessSwitch

Task 2 - Telnet from PC-2 to NewYork
Step 126. Connect to console of PC-2, and enter privileged mode.
Step 127. Telnet to the New York Router
telnet 203.0.113.8
Step 128. Once connected to NewYork, login, enter configuration mode, exit out of configuration
mode, then exit out of the NewYork telnet session completely.
Username: cisco
Password: cisco
configure terminal
exit
exit
Figure 7-2: Telnet to NewYork
Note: Entering configuration mode on NewYork ensures that there are several telnet packets available in the capture.

Task 3 - Stop the Capture
Step 129. From the console of LabAccessSwitch, stop the capture.
monitor capture tnetcap stop
Figure 7-3: Stop Packet Capture – LabAccessSwitch
Note: The number of packets captured and the duration will vary from this screen capture.
Step 130. Use TFTP to copy the capture file to the Jump Host.
Name the destination file telnet.pcapng.
copy flash: tftp:
telnetcap
192.168.100.50
telnet.pcapng
Figure 7-4: TFTP Copy Commands – LabAccessSwitch

Step 131. On the Jump Host, open the Downloads folder.
Figure 7-5: Jump Host Download Directory
Step 132. Double click the telnet.pcapng file to open the file in Wireshark.
Figure 7-6: Opening Wireshark – telnetcap file
Step 133. Apply a filter in Wireshark to view Telnet packets.

In the filter field, type in telnet, and press Enter. This filter is case-sensitive.
Figure 7-7: Telnet Filter – Wireshark
The filter line will turn green indicating a valid filter.

Task 6 - Review the Packet Capture
Step 134. In Wireshark, select a packet with the following criteria:
- An inner source of 192.168.20.200

- An inner destination of 203.0.113.8
Note: This should be the first packet line displayed on your screen with the telnet filter in place. The telnet session was initiated by PC-2, ensuring it will be the
source of the first telnet packet. Your line number will vary from the screenshot because of overall timing and the number of packets captured.
Figure 7-8: Decoding Wireshark - Telnet
1. Inner source 192.168.20.200

2. Inner destination 203.0.113.8
3. Blue highlight indicates that packet is selected.
Step 135. Ensure the packet is selected. The line describing the packet will change from purple to blue. This indicates the packet is
selected. (See Figure 7-8, #3).

Step 136. Observe the packet details (bottom half of Wireshark).

Note the multiple Ethernet headers and IP headers.
The bit level section (Figure 7-9) shows the various headers and encapsulation.
Figure 7-9: Decoding Wireshark - Bit-level – Telnet
Telnet > TCP > IP > Ethernet > VXLAN > UDP > IP > Ethernet > Bits on the wire
Figure 7-10: Encapsulation and Headers
Figure 7-11: Telnet in VXLAN Overhead
VXLAN encapsulation has added an addition 50 Bytes of overheard to the original packet.
Note: The MTU value of the equipment has been set at 9100 to avoid fragmentation due to the increase header
overhead. The IEEE 802.3 default MTU is 1500. The recommended SDA MTU is 9100. This is a significant increase
between the IEEE default and the SDA recommended values when the LISP encapsulation only adds an additional
36-bytes overhead (or 50-byte overhead with VXLAN encapsulated LISP). This large delta often raises questions.
This high MTU requirement is discussed in the August 2017 Software-Defined Access Cisco Validated Design (CVD).
The VXLAN header adds 50 and optional 54 bytes of encapsulation overhead. Some Ethernet switches support
a maximum transmission unit (MTU) of 9216 while others may have an MTU of 9196 or smaller. Given that

server MTUs typically go up to 9,000 bytes, enabling a network wide MTU of 9100 ensures that Ethernet jumbo
frames can be transported without any fragmentation inside and outside of the fabric.
The SDA MTU value is 9100 because it is common value supported by Cisco equipment that compatible with being
an underlay or overlay device in SDA. Because many core switches, such as the Catalyst 6k, require a reboot to
change the system MTU value, a common MTU value was chosen to minimize these disruptions. That way, the MTU
can be set once in the network during a large change window, and not have to changed again.
Task 7 - Lab Clean Up
Note: Please do not skip these steps.

The last step of the exercise shows why the naming convention of the capture files is so critical.
Step 137. From the console of the LabAccessSwitch, remove the previous capture.
no monitor capture tnetcap
Figure 7-12: Remove Packet Capture
Step 138. Use the show monitor capture command to verify the previous step.
Figure 7-13: Verify Capture Removal
Note: This command should have no output. If there is output, the capture has not been removed.
Step 139. Remove the capture files from flash.
This is a shared lab environment used for many students and different Labs.
Please remove the capture files from flash for future students using the same
equipment and to prevent filling up of the device’s flash.
Please copy and paste the commands below to ensure only the appropriate files are deleted.
delete flash:telnetcap
Figure 7-14: Deleting Exercise 7 Captures from Flash:

delete flash:lispcap
Figure 7-15: Deleting Exercise 6 Captures from Flash:
Step 140. Use regular expressions to ensure the capture files are no longer present in flash.
show flash: | include (cap)
Figure 7-16: Verify Captures are Deleted
Note: This command should have no output. If there is output, the files have not been removed.

Task 8 - Show IP LISP Forwarding Command – DefaultBorder
The show ip lisp forwarding eid command can show many of the LISP attributes regarding how this local
PxTR encapsulates packets to the remote EIDs. It will also show how many LISP packets were
encapsulated by this router. Finally, this command will verify that LISP encapsulation will occur for a
specific EID and show the EID-to-RLOCs mappings learned from the MS/MR.
Step 141. From the console of DefaultBorder, use the show ip lisp forwarding eid command to
display LISP attributes and encapsulation information.
Display information for the EID-space connected to EdgeNode1.
show ip lisp forwarding eid remote 192.168.10.100
Figure 7-17: Show IP LISP Forwarding – EID 192.168.10.100
1. The forwarding action is encap(sulation).

This means packets destined for this address will be encapsulated by LISP.
2. The number of packets encapsulated for this destination and the total number of bytes
3. The authoritative RLOC for 192.168.10.100 (EdgeNode1’s Loopback 0)
4. This relates to the priority and weight configuration in the database-mapping command on
EdgeNode1.1
5. Indicates which LISP interface is used to reach the 192.168.255.1
6. Indicates the physical interface is used to reach the RLOC 192.168.255.1
1
Note: Recall the database mapping command for EdgeNode1 from Step 12.

Step 142. Use the show ip lisp forwarding eid command to display LISP attributes and
encapsulation information for the EID-space for EdgeNode2.
Figure 7-18: Show IP LISP Forwarding – EID 192.168.20.100
1. The forwarding action is encap(sulation).

This means packets destined for this address will be encapsulated by LISP.
2. The number of packets encapsulated for this destination and the total number of bytes
3. The authoritative RLOC for 192.168.20.200 (EdgeNode2’s Loopback 0)
4. This relates to the priority and weight configuration in the database-mapping command on
EdgeNode2.
Note: Recall the database mapping command for EdgeNode2 from Step 18.
5. Indicates which LISP interface is used to reach the 192.168.255.2

6. Indicates which physical interface is used to reach the RLOC 192.168.255.2
Note: In Figure 7-17 and Figure 1-18, the interface number (ifnums) is shown as LISP0(15).
This interface number directly relates to CEF and is used by the software platform to identify a particular interface.
Advanced troubleshooting using show platform commands will be showcased in later labs. They will require
knowing the interface number. For example, show platform software fed switch active ifm if-id 15 on Catalyst
Switches. To determine the interface number of any interface, use the show cef interface command.
Figure 7-19: Identifying Interface Number

Appendix A - Initial Configurations
EdgeNode1
enable
configure terminal
hostname EdgeNode1
service timestamps debug datetime msec localtime show-timezone

service timestamps log datetime msec localtime show-timezone
ip routing
no ip domain-lookup
ip domain-name dna.local
no boot system
boot system flash:packages.16.5.1.conf
vtp mode transparent

vtp domain EdgeNode1.local
vtp version 3
ip ssh version 2
system mtu 9100
key chain IS-IS_INTERFACE

key 1
key-string DNAR@CKS
key chain IS-IS_LSDB

key 1
key-string C@mpusFabric
spanning-tree mode rapid-pvst
interface vlan 1
no ip address
shutdown
exit
interface Loopback0
description Fabric Internal RLOC
ip address 192.168.255.1 255.255.255.255
exit
interface range gigabitEthernet 1/0/1-10

shutdown

shutdown
description Link to PC-1
no switchport
ip address 192.168.10.1 255.255.255.0
load-interval 30

carrier-delay msec 0
exit
description Link to Lab Access Switch
no switchport
ip address 192.168.1.1 255.255.255.0
load-interval 30
ip router isis
isis network point-to-point
isis authentication mode md5
isis authentication key-chain IS-IS_INTERFACE
exit

shutdown
router isis
log-adjacency-changes
net 49.0000.1111.1111.1111.00
is-type level-2-only
authentication mode md5
authentication key-chain IS-IS_LSDB level-2
metric-style wide
passive-interface default
no passive-interface gigabitEthernet 1/0/11
exit
line con 0
exec-time 180 0
logging synchronous
width 512
length 50
exit
line vty 0 4
exec-timeout 180 0
logging synchronous
length 50
width 512
transport input all
login local
password cisco
exit
username cisco privilege 15 password cisco

enable password cisco
ip route 128.107.212.175 255.255.255.255 192.168.1.6
ntp server 128.107.212.175

clock timezone UTC -5 0
clock summer-time EST recurring
end

EdgeNode2
enable
configure terminal
hostname EdgeNode2

ip routing
no ip domain-lookup
no boot system

vtp version 3
ip ssh version 2
system mtu 9100

key 1
key-string DNAR@CKS

key 1
interface vlan 1
no ip address
shutdown
exit
interface Loopback0
ip address 192.168.255.2 255.255.255.255
exit

shutdown

shutdown
no switchport
ip address 192.168.20.2 255.255.255.0
load-interval 30
exit

no switchport
ip address 192.168.2.2 255.255.255.0
load-interval 30
ip router isis
exit

shutdown
router isis
net 49.0000.2222.2222.2222.00
metric-style wide
exit
line con 0
exec-time 180 0
logging synchronous
width 512
length 50
exit
line vty 0 4
exec-timeout 180 0
logging synchronous
length 50
width 512
transport input all
login local
password cisco
exit

ip route 128.107.212.175 255.255.255.255 192.168.2.6
ntp server 128.107.212.175

end
BorderNode
enable

configure terminal
hostname BorderNode

ip routing
no ip domain-lookup
no boot system
boot system flash bootflash:packages.16.5.1.conf

vtp domain BorderNode.local
vtp version 3
ip ssh version 2

key 1
key-string DNAR@CKS

key 1
interface Loopback0
ip address 192.168.255.3 255.255.255.255
exit
no shutdown
ip address 192.168.3.3 255.255.255.0
load-interval 30
ip router isis
mtu 9100
ip mtu 9100
isis bfd disable
exit
description Link to Default Border Node
no shutdown
ip address 192.168.35.3 255.255.255.0
load-interval 30
ip router isis
mtu 9100
ip mtu 9100
bfd interval 300 min_rx 300 multiplier 3

no bfd echo
exit
interface range GigabitEthernet0/0/2-3

shutdown
exit
router isis
net 49.0000.3333.3333.3333.00
metric-style wide
bfd all-interfaces
exit
router lisp
encapsulation vxlan
exit
line con 0
exec-time 180 0
logging synchronous
width 512
length 50
exit
line vty 0 4
exec-timeout 180 0
logging synchronous
length 50
width 512
transport input all
login local
password cisco
exit

ip route 128.107.212.175 255.255.255.255 192.168.3.6
ntp server 128.107.212.175

end
ControlPlaneNode
enable
configure terminal
hostname ControlPlaneNode


ip routing
no ip domain-lookup
no boot system

vtp domain ControlPlaneNode.local
vtp version 3
ip ssh version 2
system mtu 9100

key 1
key-string DNAR@CKS

key 1
interface vlan 1
no ip address
shutdown
exit
interface Loopback0
ip address 192.168.255.4 255.255.255.255
exit
no switchport
ip address 192.168.4.4 255.255.255.0
load-interval 30
ip router isis
exit
description Link to Default Border Node for iBPG
no switchport
ip address 192.168.45.4 255.255.255.0
load-interval 30
ip router isis
exit

interface range TenGigabitEthernet 1/0/3-12

shutdown
interface range TenGigabitEthernet 1/1/1-4

shutdown
router isis
net 49.0000.4444.4444.4444.00
metric-style wide
no passive-interface TenGigabitEthernet 1/0/1
no passive-interface TenGigabitEthernet 1/0/2
exit
line con 0
exec-time 180 0
logging synchronous
width 512
length 50
exit
line vty 0 4
exec-timeout 180 0
logging synchronous
length 50
width 512
transport input all
login local
password cisco
exit

ip route 128.107.212.175 255.255.255.255 192.168.4.6
ntp server 128.107.212.175

isis metric 3000
exit
end
DefaultBorder
enable
configure terminal
hostname DefaultBorder


no ip domain-lookup
no boot system

vtp domain DefaultBorderNode.local
vtp version 3
ip ssh version 2

key 1
key-string DNAR@CKS

key 1
interface Loopback0
ip address 192.168.255.5 255.255.255.255
exit
description Link to ISP
no shutdown
ip address 198.51.100.5 255.255.255.0
load-interval 30
no shutdown
exit
description Link to Border Node
no shutdown
ip address 192.168.35.5 255.255.255.0
load-interval 30
ip router isis
mtu 9100
ip mtu 9100
no bfd echo
exit
description Link to Control Plane Node for iBGP
no shutdown
ip address 192.168.45.5 255.255.255.0
load-interval 30
ip router isis


mtu 9100
ip mtu 9100
isis bfd disable
exit
description !! PLEASE LEAVE SHUTDOWN !!
shutdown
exit
router isis
net 49.0000.5555.5555.5555.00
metric-style wide
bfd all-interfaces
exit
router lisp
encapsulation vxlan
exit
line con 0
exec-time 180 0
logging synchronous
width 512
length 50
exit
line vty 0 4
exec-timeout 180 0
logging synchronous
length 50
width 512
transport input all
login local
password cisco
exit

ip route 128.107.212.175 255.255.255.255 192.168.35.3

ip route 128.107.212.175 255.255.255.255 192.168.45.4
ip route 0.0.0.0 0.0.0.0 198.51.100.7
ntp server 128.107.212.175


isis metric 2000

exit
end
LabAccessSwitch
enable
configure terminal
host LabAccessSwitch
ip routing
no ip domain-lookup
no boot system

vtp domain LabAccessSwitch.local
vtp version 3
ip ssh version 2
system mtu 9100
ip tftp blocksize 512

ip tftp source-interface gigabitEthernet 1/0/12

key 1
key-string DNAR@CKS

key 1
interface vlan 1
no ip address
shutdown
exit
interface loopback 0
ip address 192.168.255.6 255.255.255.255
description Underlay ONLY
exit

description Link to Edge Node #1
no switchport
ip address 192.168.1.6 255.255.255.0
ip router isis
load-interval 30
ip router isis
exit


no switchport
ip address 192.168.2.6 255.255.255.0
ip router isis
load-interval 30
ip router isis
exit

no switchport
ip address 192.168.3.6 255.255.255.0
ip router isis
load-interval 30
ip router isis
exit

description Link to Control Plane Node
no switchport
ip address 192.168.4.6 255.255.255.0
ip router isis
load-interval 30
exit

shutdown
description SSH Access to CSR1000vs
no switchport
ip address 198.18.100.6 255.255.255.0
load-interval 30
exit

description Link to True Internet
no switchport
ip add 192.0.0.1 255.255.255.0
load-interval 30
exit

description Link to Jump Host and Management VMs

no switchport
ip add 192.168.100.6 255.255.255.0
load-interval 30
exit
router isis
net 49.0000.6666.6666.6666.00
metric-style wide
exit
line con 0
exec-time 180 0
logging synchronous
width 512
length 50
exit
line vty 0 4
exec-timeout 180 0
logging synchronous
length 50
width 512
transport input all
login local
password cisco
exit

ip route 0.0.0.0 0.0.0.0 192.0.0.254
ntp server 128.107.212.175

end
ISP
enable
configure terminal
hostname ISP



cdp run
no ip domain-lookup
ip domain-name ISP.com
vrf definition MGMT-INTERFACE

address-family ipv4
exit-address-family
exit
interface loopback 0
description For BGP NLRI Prefix Injection
ip address 77.77.77.77 255.255.255.255
exit
interface GigabitEthernet1
ip address 198.51.100.7 255.255.255.0
negotiation auto
cdp enable
no shutdown
exit
description Link to New York Router
ip address 203.0.113.7 255.255.255.0
negotiation auto
cdp enable
no shutdown
exit
description !! SSH ACCESS !!
vrf forwarding MGMT-INTERFACE
ip address 198.18.100.107 255.255.255.0
negotiation auto
cdp enable
no shutdown
exit
router bgp 7
bgp log-neighbor-changes
network 77.77.77.77 mask 255.255.255.255
network 203.0.113.0 mask 255.255.255.0
exit
line con 0
exec-time 180 0
logging synchronous
length 50
width 512
exit
line vty 0 4

exec-timeout 180 0
logging synchronous
length 50
width 512
transport input all
login local
password cisco
banner login $ Use the 'terminal monitor' command after logging in. $
banner motd $
Use the 'terminal monitor' command after logging in. $
end
NewYork
enable
configure terminal
hostname NewYork


cdp run
no ip domain-lookup
ip domain name New-York.com

address-family ipv4
exit-address-family
exit
ip address 198.18.133.8 255.255.255.0
negotiation auto
cdp enable
no shutdown
exit
ip address 203.0.113.8 255.255.255.0
negotiation auto
cdp enable
no shutdown
exit
ip address 198.18.100.108 255.255.255.0
negotiation auto
cdp enable
no shutdown
exit

router bgp 8
network 198.18.133.0 mask 255.255.255.0
network 203.0.113.0 mask 255.255.255.0
exit
ip address 198.18.100.108 255.255.255.0
negotiation auto
cdp enable
no shutdown
exit
ip route 0.0.0.0 0.0.0.0 203.0.113.7
line con 0
exec-time 180 0
logging synchronous
length 50
width 512
exit
line vty 0 4
exec-timeout 180 0
logging synchronous
length 50
width 512
transport input all
login local
password cisco
exit
banner motd $
end
PC-1
enable
configure terminal
hostname PC-1


cdp run
no ip domain-lookup

address-family ipv4
exit-address-family
exit
ip address 192.168.10.100 255.255.255.0
negotiation auto
cdp enable
no shutdown
exit
ip address 198.18.100.101 255.255.255.0
negotiation auto
cdp enable
no shutdown
exit
ip route 0.0.0.0 0.0.0.0 192.168.10.1
line con 0
exec-time 180 0
logging synchronous
length 50
width 512
exit
line vty 0 4
exec-timeout 180 0
logging synchronous
length 50
width 512
transport input all
login local
password cisco
exit
banner motd $
end
PC-2
enable
configure terminal
hostname PC-2


cdp run

no ip domain-lookup

address-family ipv4
exit-address-family
exit
ip address 192.168.20.200 255.255.255.0
negotiation auto
cdp enable
no shutdown
exit
ip address 198.18.100.102 255.255.255.0
negotiation auto
cdp enable
no shutdown
exit
ip route 0.0.0.0 0.0.0.0 192.168.20.2
line con 0
exec-time 180 0
logging synchronous
length 50
width 512
exit
line vty 0 4
exec-timeout 180 0
logging synchronous
length 50
width 512
transport input all
login local
password cisco
exit
banner motd $
end
PC-3
enable
configure terminal
hostname PC-3


cdp run
no ip domain-lookup

address-family ipv4
exit-address-family
exit
description Link to New York Router
ip address 198.18.133.80 255.255.255.0
negotiation auto
cdp enable
no shutdown
exit
ip address 198.18.100.103 255.255.255.0
negotiation auto
cdp enable
no shutdown
exit
ip route 0.0.0.0 0.0.0.0 198.18.133.8
line con 0
exec-time 180 0
logging synchronous
length 50
width 512
exit
line vty 0 4
exec-timeout 180 0
logging synchronous
length 50
width 512
transport input all
login local
password cisco
exit
banner motd $
end

Appendix B - Configuration Examples
Exercise 0
Task 1 - Verify IP Reachability

tclsh
foreach address {
192.168.255.1
192.168.255.2
192.168.255.3
192.168.255.4
192.168.255.5
192.168.255.6
} { ping $address source loopback 0
}
tclquit
Exercise 1

configure terminal
router lisp
ipv4 itr
ipv4 etr
end

configure terminal
router lisp
ipv4 itr
ipv4 etr
end
Task 3 - Basic LISP xTR Configuration – BorderNode

configure terminal
router lisp
ipv4 itr
ipv4 etr
end

Task 4 - Basic LISP MS/MR Configuration – ControlPlaneNode

configure terminal
router lisp
ipv4 map-server
ipv4 map-resolver
site EN1
eid-prefix 192.168.10.0/24
exit
site EN2
eid-prefix 192.168.20.0/24
exit
end
Task 5 - Simplify Future Troubleshooting and Show Commands
EdgeNode1
configure terminal
end
EdgeNode2
configure terminal
end
BorderNode
configure terminal
exit
end
ControlPlaneNode
configure terminal
exit
end
DefaultBorder
configure terminal


exit
end
Exercise 2
Task 1 - Verify the LISP Control Plane Configuration

show ip lisp
Task 2 - Verify the LISP Control Plane Functionality (Bidirectional communication)

lig self ipv4
Task 3 - Verify the LISP EID registrations.

show lisp site
Task 4 - Verify the LISP Map-Cache Entries

show ip lisp map-cache
Task 5 - Confirm LISP Control Plane, LISP Data Plane, and IP Reachability
ping 192.168.20.200
ping 192.168.10.100
Exercise 3
Task 1 - Basic BGP Configuration – DefaultBorder

configure terminal
router bgp 5
end
Task 2 - Verify BGP Adjacency and Prefix Advertisement

show ip bgp
Task 3 - Verify BGP Neighbors

show ip bgp summary

Task 1 - Basic PxTR Configuration – DefaultBorder

configure terminal
router lisp
ipv4 proxy-etr
ipv4 proxy-itr 192.168.255.5
end
Task 2 - Basic PxTR Verifications
show ip lisp
Task 3 - Configure Edge Nodes to use the Proxy Egress Tunnel Router
configure terminal
router lisp
ipv4 use-petr 192.168.255.5
end
Task 4 - Verification of PeTR Configuration – Edge Nodes

show ip lisp
Task 1 - Verify Prerequisite

show ip route 192.168.10.0/24
show ip route 192.168.20.0/24
show ip route 192.168.0.0/16
show ip cef 192.168.10.0/24

show ip cef 192.168.20.0/24
show ip cef 192.168.0.0/16
Task 2 - Null 0 Static Route

configure terminal
ip route 192.168.0.0 255.255.0.0 Null 0 tag 123
end
Task 3 - Static Route Verification

show running-config | include ip route

Task 4 - Route Map Configuration – DefaultBorder

configure terminal
match tag 123
end
Task 5 - Redistribute the Static Null Route using the Route Map
configure terminal
router bgp 5
redistribute static route-map EID-INJECT
end
Task 6 - Verify NLRI

show ip bgp
Task 1 - Enable all LISP Debugging – DefaultBorder

debug lisp control-plane all
Task 2 - Enable specific LISP debugging – ControlPlaneNode

debug lisp control-plane map-server-map-request
debug lisp control-plane map-server-map-notify
debug lisp control-plane negative-map-reply

monitor capture lispcap interface GigabitEthernet 1/0/3 both match any limit packets 1000 file location flash:lispcap
Task 4 - Clear Existing Map-Cache Entries

clear ip lisp map-cache
Task 5 - Verify the Functionality of the LISP, BGP, and Route-Map Configurations
ping 192.168.10.100
ping 192.168.20.200
ping 198.18.133.80
Task 6 - Stop the Packet Capture


Task 7 - Interpreting Debug Messages – ControlPlaneNode
Please see the LISP Intermediate Folder on the Jump Host to view the debug messages in .png and .txt
formats.
Task 8 - Interpreting Debug Messages – DefaultBorder
Please see the LISP Intermediate Folder on the Jump Host to view the debug messages in .png and .txt
formats.

copy flash: tftp:
lispcap
192.168.100.50
lispcap.pcapng
Please see the LISP Intermediate Folder on the Jump Host to view a master copy of the packet capture.
Task 11 - Exercise Cleanup

no monitor capture lispcap
Exercise 7: Encapsulation Header Visualization and Final Troubleshooting
Task 1 – Native Packet Capture #2

monitor capture tnetcap interface GigabitEthernet 1/0/2 both match any limit packets 1000 file location flash:telnetcap
monitor capture tnetcap start
Task 2 - Telnet from PC-2 to NewYork

telnet 203.0.113.8
Username: cisco
Password: cisco
configure terminal
exit
exit
Task 3 - Stop the Capture

monitor capture tnetcap stop


copy flash: tftp:
telnetcap
192.168.100.50
telnet.pcapng
Task 6 - Review the Packet Capture
Task 7 - Lab Clean Up

no monitor capture tnetcap
Please copy and paste the commands below to ensure only the appropriate files are deleted.
delete flash:telnetcap
delete flash:lispcap
show flash: | include (cap)
Task 8 - Show IP LISP Forwarding Command


Appendix C - Final Configurations
EdgeNode1
version 16.5
no service pad
no platform punt-keepalive disable-kernel-core
!
hostname EdgeNode1
!
vrf definition Mgmt-vrf
!
address-family ipv4
exit-address-family
!
address-family ipv6
exit-address-family
!
!
no aaa new-model
boot system switch all flash:packages.16.5.1.conf
switch 1 provision c9300-24u
!
ip routing
!
no ip domain lookup
ip domain name dna.local
!
cpp system-default
!
key 1
key-string DNAR@CKS
key 1
!
crypto pki trustpoint TP-self-signed-4111685056
enrollment selfsigned
subject-name cn=IOS-Self-Signed-Certificate-4111685056
revocation-check none
rsakeypair TP-self-signed-4111685056
!
crypto pki certificate chain TP-self-signed-4111685056
certificate self-signed 01
30820330 30820218 A0030201 02020101 300D0609 2A864886 F70D0101 05050030
31312F30 2D060355 04031326 494F532D 53656C66 2D536967 6E65642D 43657274
69666963 6174652D 34313131 36383530 3536301E 170D3137 31323137 31333538
35355A17 0D323030 31303130 30303030 305A3031 312F302D 06035504 03132649
4F532D53 656C662D 5369676E 65642D43 65727469 66696361 74652D34 31313136
38353035 36308201 22300D06 092A8648 86F70D01 01010500 0382010F 00308201

0A028201 010099E0 48CFB043 0E0FDFFB 6D9460D4 2A18F99C 93DBEDD4 12CF5B39

CCE5CE69 7E65102A 11C8E526 7C77902B 552274B0 348400A6 A25F5D1D D361B696
338F109E BE5A0603 4708D02E FA0185A4 A09507F9 111679CB 566DDF93 C6CE1CDA
96210183 494762C2 7A14176A 21B35B06 307E3D8C AA58E9C0 920D662F 4C3784A5
3C8CF9E7 767DB5B8 CDF83F73 051283BE 9D8952E5 03FBE0CF 3C8C530C 2CE99C7F
E97F9437 1AA37240 2A03B24C 45776364 6FB9BBDB B0CDE496 F76ED271 CBCBD5DF
312537E9 DD504F99 E879D3D7 5D384EFC 52C34C4A 48F83378 DAA8490F 56BB8153
D2C531A1 BE01E6EA 95E17EAB 0BB52A90 A9EFDA05 95152A5B C4BBB745 EE157969
337BCBD6 9E1D0203 010001A3 53305130 0F060355 1D130101 FF040530 030101FF
301F0603 551D2304 18301680 1404B4BD 1728DD1F 85FE3AAC 39F3FF86 32BE7E52
6D301D06 03551D0E 04160414 04B4BD17 28DD1F85 FE3AAC39 F3FF8632 BE7E526D
300D0609 2A864886 F70D0101 05050003 82010100 2F3AF636 476DC8B9 2D11B69B
D9EBB4AF BF5CDE5B D7A7BEDE 8F7CAD4B 5C3EA4A1 DD165B61 CB264963 437CABE4
22856FC5 71824A74 8B537CAE F09197C2 B8579958 A4A054FD BDB5504C E1FF69F8
7B13D263 2A1DF3DB B0B44712 61625BE4 4EE264EB B8894814 30E336E6 9EC86675
5DC77367 2E5F464B C95887A6 C2A2DBB4 985FB2FC 5FCE3CA8 A2F53DEC 6A2569A2
C34FF462 E78D5F10 777C1744 0A897C6B 07E4627A 329A967E 82ED69CF E5318A38
FFBA7576 FC3C46C1 48FB8B02 6ECF1CDB 04E765BD D12F5194 4DB4AF52 93C90F75
D3EAF991 4F475B07 A972F9C7 F69A2D30 B00B14A3 4615BE79 6CEF130A B2C0BF54
6908E950 0F0BC905 E9A41AC3 DAC27966 A6344BBD
quit
!
system mtu 9100
diagnostic bootup level minimal
spanning-tree extend system-id
!
username cisco privilege 15 one-time password 0 cisco
!
redundancy
mode sso
!
class-map match-any system-cpp-police-topology-control
description Topology control
class-map match-any system-cpp-police-sw-forward
description Sw forwarding, L2 LVX data, LOGGING
class-map match-any system-cpp-default
description DHCP Snooping and Unused queues
class-map match-any system-cpp-police-sys-data
description Learning cache ovfl, Crypto Control, Exception, EGR Exception, NFL
SAMPLED DATA, Gold Pkt, RPF Failed
class-map match-any system-cpp-police-punt-webauth
description Punt Webauth
class-map match-any system-cpp-police-l2lvx-control
description L2 LVX control packets
class-map match-any system-cpp-police-forus
description Forus Address resolution and Forus traffic
class-map match-any system-cpp-police-multicast-end-station
description MCAST END STATION
class-map match-any system-cpp-police-multicast
description Transit Traffic and MCAST Data
class-map match-any system-cpp-police-l2-control
description L2 control, FSS
class-map match-any system-cpp-police-dot1x-auth
description DOT1X Auth
class-map match-any system-cpp-police-data
description ICMP_GEN and BROADCAST
class-map match-any system-cpp-police-control-low-priority
description ICMP redirect and general punt
class-map match-any non-client-nrt-class

class-map match-any system-cpp-police-routing-control

description Routing control and Low latency
class-map match-any system-cpp-police-protocol-snooping
description Protocol snooping
!
policy-map system-cpp-policy
class system-cpp-police-data
police rate 600 pps
class system-cpp-police-sys-data
police rate 100 pps
class system-cpp-police-sw-forward
police rate 1000 pps
class system-cpp-police-multicast
police rate 500 pps
class system-cpp-police-multicast-end-station
class system-cpp-police-punt-webauth
class system-cpp-police-l2-control
class system-cpp-police-routing-control
class system-cpp-police-control-low-priority
police rate 200 pps
class system-cpp-police-l2lvx-control
class system-cpp-police-topology-control
class system-cpp-police-dot1x-auth
class system-cpp-police-protocol-snooping
class system-cpp-police-forus
class system-cpp-default
!
interface Loopback0
ip address 192.168.255.1 255.255.255.255
!
interface LISP0
!
interface GigabitEthernet0/0
vrf forwarding Mgmt-vrf
no ip address
speed 1000
negotiation auto
!
shutdown
!
shutdown
!
shutdown
!
shutdown
!
shutdown
!
shutdown
!

shutdown
!
shutdown
!
shutdown
!
shutdown
!
no switchport
ip address 192.168.10.1 255.255.255.0
load-interval 30
!
no switchport
ip address 192.168.1.1 255.255.255.0
ip router isis
ip lisp source-locator Loopback0
load-interval 30
!
shutdown
!
shutdown
!
shutdown
!
shutdown
!
shutdown
!
shutdown
!
shutdown
!
shutdown
!
shutdown
!
shutdown

!
shutdown
!
shutdown
!
!
!
!
!
!
!
!
!
!
!
!
!
interface FortyGigabitEthernet1/1/1
!
interface FortyGigabitEthernet1/1/2
!
interface Vlan1
no ip address
shutdown
!
router lisp
encapsulation vxlan
database-mapping 192.168.10.0/24 IPv4-interface Loopback0 priority 10 weight 10
ipv4 itr
ipv4 etr
ipv4 use-petr 192.168.255.5
exit
!
router isis
net 49.0000.1111.1111.1111.00
metric-style wide
no passive-interface GigabitEthernet1/0/11
!

ip forward-protocol nd
ip http server
ip http authentication local
ip http secure-server
ip route 128.107.212.175 255.255.255.255 192.168.1.6
!
ip ssh version 2
ip ssh server algorithm encryption aes128-ctr aes192-ctr aes256-ctr
ip ssh client algorithm encryption aes128-ctr aes192-ctr aes256-ctr
!
control-plane
service-policy input system-cpp-policy
!
line con 0
exec-timeout 180 0
logging synchronous
length 50
width 512
stopbits 1
line aux 0
stopbits 1
line vty 0 4
exec-timeout 180 0
password cisco
logging synchronous
login local
length 50
width 512
transport input all
line vty 5 15
login
!
ntp server 128.107.212.175
!
end
EdgeNode2
version 16.5
no service pad
!
hostname EdgeNode2
!
!
address-family ipv4
exit-address-family
!
address-family ipv6
exit-address-family
!
!
no aaa new-model


switch 1 provision ws-c3850-24p
!
ip routing
!
no ip domain lookup
!
cpp system-default
!
key 1
key-string DNAR@CKS
key 1
!
!
30820330 30820218 A0030201 02020101 300D0609 2A864886 F70D0101 05050030
31312F30 2D060355 04031326 494F532D 53656C66 2D536967 6E65642D 43657274
69666963 6174652D 32313336 37373534 3934301E 170D3137 31323137 31333539
30315A17 0D323030 31303130 30303030 305A3031 312F302D 06035504 03132649
4F532D53 656C662D 5369676E 65642D43 65727469 66696361 74652D32 31333637
37353439 34308201 22300D06 092A8648 86F70D01 01010500 0382010F 00308201
0A028201 0100AAEA 32D40074 22546E2A 5C89B512 FCB13DA3 48814FF2 6787FF5F
FBDF779A 16198A7C 008D2FE0 A952C6EE 844EF78E B9821C79 26DAD036 E4D9FD83
DA67C1CC AE94BED9 F8A6D20A 2BF06103 5FCAB708 72F97B54 3AB27ECA BF01F258
71E6D539 B47F7049 FF5193CD 29C74F0E 743398B7 BBD13113 5A0AA287 249D489E
346C73F1 F46801C8 3CFBFB1E 03EC4192 B7E3A59C 9C29E033 427DF20B 843D6C43
E4BD12CD 057BBF04 64B5D44D 1731EFBA 0F2948F9 52BC2EF5 B9B37053 C72F4D1E
CC4AA156 A5435FD4 1DC08C33 A0D895C7 28B381A6 8474DB08 CF430714 AFB6DE99
95130CB0 75EBA870 CD993F33 39AAE38D FA781F3E 711F0993 E6599095 A29930D9
1EA9058D 74AB0203 010001A3 53305130 0F060355 1D130101 FF040530 030101FF
301F0603 551D2304 18301680 14D459D0 26E094DE 8AEB4284 AA605E52 36062523
7B301D06 03551D0E 04160414 D459D026 E094DE8A EB4284AA 605E5236 0625237B
300D0609 2A864886 F70D0101 05050003 82010100 2EDE4503 1BCFC638 65580FCE
E69DB1C1 DBF7E098 E9427393 DC7911C7 C130F79A 8F68FB9D 2364DC51 324E9399
5F25360E BA40A43E 8749CA5A 9A1EEAE1 67143CBC 6E00615B 7408F1A4 9497B7EE
37A0D066 B4FB9FAC 558CF5F8 59D8001C F8B031A0 5953CBBA CEAAB56E 47810B97
C59FAB8F 38C961CB 373707E0 8015C8CC 1B9CF3B5 312C7657 4897265A D6A13A37
6154040F EEF40472 A10CC8E8 8EEB9D97 1AB53494 639FC445 DABDD911 A2F213A7
765EFCEA D77C2285 F2BA8E57 E23EC801 B6F77C00 C036E1E9 8BFDC1C4 7935AF47
7B4613DA 166B49A5 B962DAFE 19CFB347 57E9417A 9C0C4827 A70B74F4 86BA05A9
52B9D77F A4101B58 F32ECA9A 78F3969A 4E8CAD49
quit
!
system mtu 9100
!

username cisco privilege 15 password 0 cisco

!
redundancy
mode sso
!
!
police rate 600 pps
police rate 100 pps
police rate 500 pps
police rate 200 pps

!
interface Loopback0
ip address 192.168.255.2 255.255.255.255
!
interface LISP0
!
no ip address
shutdown
negotiation auto
!
shutdown
!
shutdown
!
shutdown
!
shutdown
!
shutdown
!
shutdown
!
shutdown
!
shutdown
!
shutdown
!
shutdown
!
no switchport
ip address 192.168.20.2 255.255.255.0
load-interval 30
!
no switchport
ip address 192.168.2.2 255.255.255.0
ip router isis
load-interval 30


!
shutdown
!
shutdown
!
shutdown
!
shutdown
!
shutdown
!
shutdown
!
shutdown
!
shutdown
!
shutdown
!
shutdown
!
shutdown
!
shutdown
!
!
!
!
!
!
!
!
!
interface Vlan1
no ip address
shutdown
!

router lisp
encapsulation vxlan
database-mapping 192.168.20.0/24 IPv4-interface Loopback0 priority 10 weight 10
ipv4 itr
ipv4 etr
ipv4 use-petr 192.168.255.5
exit
!
router isis
net 49.0000.2222.2222.2222.00
metric-style wide
!
ip http server
ip route 128.107.212.175 255.255.255.255 192.168.2.6
ip ssh version 2
!
control-plane
!
line con 0
exec-timeout 180 0
logging synchronous
length 50
width 512
stopbits 1
line aux 0
stopbits 1
line vty 0 4
exec-timeout 180 0
password cisco
logging synchronous
login local
length 50
width 512
transport input all
line vty 5 15
login
!
ntp server 128.107.212.175
!
end

BorderNode
version 16.5
platform qfp utilization monitor load 80
!
hostname BorderNode
!
boot-start-marker
boot-end-marker
!
vrf definition Mgmt-intf
!
address-family ipv4
exit-address-family
!
address-family ipv6
exit-address-family
!
!
no aaa new-model
!
no ip domain lookup
!
subscriber templating
!
vtp domain BorderNode.local
!
multilink bundle-name authenticated
!
key 1
key-string DNAR@CKS
key 1
!
!
!
license udi pid ISR4451-X/K9 sn FOC17042FHZ
license accept end user agreement
license boot level appxk9
license boot level uck9
license boot level securityk9

!
!
!
redundancy
mode none
!
interface Loopback0
ip address 192.168.255.3 255.255.255.255
!
mtu 9100
ip address 192.168.3.3 255.255.255.0
ip router isis
load-interval 30
negotiation auto
isis bfd disable
!
mtu 9100
ip address 192.168.35.3 255.255.255.0
ip router isis
load-interval 30
negotiation auto
no bfd echo
!
no ip address
shutdown
negotiation auto
!
no ip address
shutdown
negotiation auto
!
interface Ethernet-Internal1/0/0
no negotiation auto
no mop enabled
no mop sysid
!
interface Ethernet-Internal1/0/1
no negotiation auto
switchport mode trunk

no mop enabled
no mop sysid
!
interface ucse2/0/0
no ip address
shutdown
no negotiation auto
no mop enabled
no mop sysid
!
interface ucse2/0/1
no ip address
shutdown
no negotiation auto
no mop enabled
no mop sysid
!
vrf forwarding Mgmt-intf
no ip address
shutdown
negotiation auto
!
router lisp
encapsulation vxlan
ipv4 itr
ipv4 etr
exit
!
router isis
net 49.0000.3333.3333.3333.00
metric-style wide
bfd all-interfaces
!
threat-visibility
ip http server
ip tftp source-interface GigabitEthernet0
ip route 128.107.212.175 255.255.255.255 192.168.3.6
!
ip ssh version 2
!
control-plane
!
mgcp behavior rsip-range tgcp-only
mgcp behavior comedia-role none

mgcp behavior comedia-check-media-src disable

mgcp behavior comedia-sdp-force disable
!
mgcp profile default
!
line con 0
exec-timeout 180 0
logging synchronous
length 50
width 512
transport input none
stopbits 1
line aux 0
stopbits 1
line vty 0 4
exec-timeout 180 0
password cisco
logging synchronous
login local
length 50
width 512
transport input all
!
no network-clock synchronization automatic
ntp server 128.107.212.175
!
end
ControlPlaneNode
version 16.5
no service pad
!
hostname ControlPlaneNode
!
!
address-family ipv4
exit-address-family
!
address-family ipv6
exit-address-family
!
!
no aaa new-model
switch 1 provision ws-c3850-12xs
!
ip routing
!
no ip domain lookup
!

vtp domain ControlPlaneNode.local

cpp system-default
!
key 1
key-string DNAR@CKS
key 1
!
!
30820330 30820218 A0030201 02020101 300D0609 2A864886 F70D0101 05050030
31312F30 2D060355 04031326 494F532D 53656C66 2D536967 6E65642D 43657274
69666963 6174652D 33323232 32333433 3337301E 170D3137 31323137 31333539
31305A17 0D323030 31303130 30303030 305A3031 312F302D 06035504 03132649
4F532D53 656C662D 5369676E 65642D43 65727469 66696361 74652D33 32323232
33343333 37308201 22300D06 092A8648 86F70D01 01010500 0382010F 00308201
0A028201 01009673 946430C6 49DDB876 FE731FD6 486875F4 6DF06CCC BD3FBA15
CC059CB8 074C642A B9AAC808 F87A7FDC 5641E80E E8DC8A4D 985D51D5 227BAB3E
856C971D A908BEAA E3D13E14 C6167C96 E5C4A92A 8F2207D9 82580DEA AD63C874
7557C894 08452B01 1C56CFFC 70D78752 0AE87922 DD495B3A 966A0A85 023922AB
092AE318 505A180B CFFDEE52 115DEE61 93882D82 A8436F43 D99A1E58 C4BF1F61
4BE32CFC 7AE43451 638494E3 76CFF8DC AF5E0012 867B8000 361200A0 E8A12D68
927BB272 3DA369F5 AD0D8414 CC090F72 6208184B 68A7ACD1 052F5D50 9AA17317
F3E2876E 51262167 EAC3F516 EEB0EEEB 7D99A7B5 5BFA1FC3 6D013306 2380600F
424FBC6B 63250203 010001A3 53305130 0F060355 1D130101 FF040530 030101FF
301F0603 551D2304 18301680 14298CB3 3EA5326E A6255791 119FA1A0 EDCB2AEB
0C301D06 03551D0E 04160414 298CB33E A5326EA6 25579111 9FA1A0ED CB2AEB0C
300D0609 2A864886 F70D0101 05050003 82010100 104EC87D 5EF17700 80785E16
50E9D4A8 7A802054 0F732372 6FBE8982 F8514EDB A239651B C4611AB4 C9F470EA
367E3765 9B115F80 893E1D0B 33AAD327 D88464B9 BFCD73D7 7A5C0BBE C4E14E91
2AC16642 E17609CD 8A6EC2AB 701D45A5 5236AB55 00EC8C04 C7CA2449 8303E011
DAEE89C4 8B1D7594 5975B21C E8F876FF 7BC92857 7049F86C 50D96045 0D9CB744
9D8C07F5 52E390F6 DB9E1CA3 83271505 248C732F 488FE117 1D8AD133 4C0EA6CE
BADA881A 9D744B82 6F9D3C8B 3074AF9F 05D57368 E9114A4B 9176CFC0 9C37AFCD
CBC516C2 89A6E550 DC1DB62D 91A3BAB8 D5EB23A2 FE5724BB 871DF07B CEB2FECC
6B8952F2 45AD9D62 221DA508 8FBD7FEE 6AED8882
quit
!
system mtu 9100
!
username cisco privilege 15 password 0 cisco
!
redundancy
mode sso
!


!
police rate 600 pps
police rate 100 pps
police rate 500 pps
police rate 200 pps
!
interface Loopback0
ip address 192.168.255.4 255.255.255.255
!


no ip address
shutdown
negotiation auto
!
no switchport
ip address 192.168.4.4 255.255.255.0
ip router isis
load-interval 30
!
description Link to Default Border Node for iBPG
no switchport
ip address 192.168.45.4 255.255.255.0
ip router isis
load-interval 30
isis metric 3000
!
shutdown
!
shutdown
!
shutdown
!
shutdown
!
shutdown
!
shutdown
!
shutdown
!
shutdown
!
shutdown
!
shutdown
!

shutdown
!
shutdown
!
shutdown
!
shutdown
!
interface Vlan1
no ip address
shutdown
!
router lisp
site EN1
eid-prefix 192.168.10.0/24
exit
!
site EN2
eid-prefix 192.168.20.0/24
exit
!
encapsulation vxlan
ipv4 map-server
ipv4 map-resolver
exit
!
router isis
net 49.0000.4444.4444.4444.00
metric-style wide
no passive-interface TenGigabitEthernet1/0/1
no passive-interface TenGigabitEthernet1/0/2
!
ip http server
ip route 128.107.212.175 255.255.255.255 192.168.4.6
ip ssh version 2
!
control-plane
!
line con 0
exec-timeout 180 0
logging synchronous
length 50
width 512

stopbits 1
line aux 0
stopbits 1
line vty 0 4
exec-timeout 180 0
password cisco
logging synchronous
login local
length 50
width 512
transport input all
line vty 5 15
login
!
ntp server 128.107.212.175
!
end
DefaultBorder
version 16.5
platform qfp utilization monitor load 80
!
hostname DefaultBorder
!
boot-start-marker
boot-end-marker
!
vrf definition Mgmt-intf
!
address-family ipv4
exit-address-family
!
address-family ipv6
exit-address-family
!
!
no aaa new-model
!
no ip domain lookup
!
subscriber templating
!
vtp domain DefaultBorderNode.local
!
multilink bundle-name authenticated
!
key 1

key-string DNAR@CKS
key 1
!
!
!
license udi pid ISR4451-X/K9 sn FOC17042FK2
license accept end user agreement
license boot level appxk9
license boot level securityk9
!
!
!
redundancy
mode none
!
interface Loopback0
ip address 192.168.255.5 255.255.255.255
!
interface LISP0
!
ip address 198.51.100.5 255.255.255.0
load-interval 30
negotiation auto
!
mtu 9100
ip address 192.168.35.5 255.255.255.0
ip router isis
load-interval 30
negotiation auto
no bfd echo
!
description Link to Control Plane Node for iBGP
mtu 9100
ip address 192.168.45.5 255.255.255.0
ip router isis

load-interval 30
negotiation auto
isis metric 2000
isis bfd disable
!
description !! PLEASE LEAVE SHUTDOWN !!
no ip address
shutdown
negotiation auto
!
vrf forwarding Mgmt-intf
no ip address
shutdown
negotiation auto
!
router lisp
encapsulation vxlan
ipv4 proxy-etr
ipv4 proxy-itr 192.168.255.5
exit
!
router isis
net 49.0000.5555.5555.5555.00
metric-style wide
bfd all-interfaces
!
router bgp 5
!
threat-visibility
ip http server
ip tftp source-interface GigabitEthernet0
ip route 0.0.0.0 0.0.0.0 198.51.100.7
ip route 128.107.212.175 255.255.255.255 192.168.35.3
ip route 128.107.212.175 255.255.255.255 192.168.45.4
ip route 192.168.0.0 255.255.0.0 Null0 tag 123
!
ip ssh version 2


!
match tag 123
!
control-plane
!
line con 0
exec-timeout 180 0
logging synchronous
length 50
width 512
transport input none
stopbits 1
line aux 0
stopbits 1
line vty 0 4
exec-timeout 180 0
password cisco
logging synchronous
login local
length 50
width 512
transport input all
!
no network-clock synchronization automatic
ntp server 128.107.212.175
!
end

Appendix D - LISP Forwarding Flow Charts
LISP Ingress Tunnel Router (ITR) Forwarding Flow Chart
Is the
Destination Is either matched? Yes Packet is eligible Check LISP Map What is the
Yes Source Address Then And
Ingress Packet lookup in 1. default route for LISP Cache Entries for Listed Action in
In the local EID Prefix
routing table 2. no route encapsulation Destination Address Map-Cache?
space?
No No
FWD-Encap Drop Send-Request Forward-Native
Packet is not
Forward Natively(1) eligible for LISP
encapsulation
LISP Encapsulate
Drop Send Map-Request Is use-petr
and forward to
Packet to Map-Resolver configured on the
Yes destination RLOC
(1)If the destination does not ITR?
match a default route or no
route, the only other No Yes
possible option is a match And

against a route in the routing Is there a default
table with a viable next hop. route?
Drop LISP Encapsulate
In this case, the packet is not Yes Original Forward Natively and forward to
No
eligible for LISP Packet PETR RLOC (2)
encapsulation, and the
packet is forwarded natively.
Drop
Forward Natively (2)The packet is
Packet
encapsulated, and a
destination address lookup is
performed on the
destination/remote RLOC.
Once the output interface is
known, the source RLOC is
filled in.

LISP Proxy Ingress Tunnel Router (PITR) Forwarding Flow Chart
Destination lookup Does the longest

Take the prefix with Then Yes Packet is eligible Then Check LISP Map And What is the
in routing table (1) Yes mask or equal prefix
Ingress Packet Is a match found? the longest / most for LISP Cache Entries for Listed Action in
and LISP match send-map-
specific mask encapsulation Destination Address Map-Cache?
map-cache (2) request
No
(1) The routing table look-up
is done in the table specified No
FWD-Encap Drop Send-Request Forward-Native
by the eid-table command
(default or VRF) Drop
Packet
(2) A map-cache entry with (3)
action send-map-request is LISP Encapsulate

Drop Send Map-Request Is use-petr
created either by static entry Forward Natively (4) and forward to
Packet to Map-Resolver configured on the
or via the route-import destination RLOC
ITR?
mechanism.
No Yes
(3) If the destination does And

(4) The destination is not a
not match a RIB route or LISP EID and a RIB route is
send-map-request map- available Drop LISP Encapsulate
cache entry, the only other Original Forward Natively and forward to
possible result is the PITR has Packet PETR RLOC (5)
no forwarding route. The
packet is dropped and a
network unreachable ICMP
(5)The packet is
(Type 3, Code 0) is
encapsulated, and a
generated.
destination address lookup is
performed on the
destination/remote RLOC.
Once the output interface is
known, the source RLOC is
filled in.

Intermediate LISP For SDA Lab Guide v1.0.1 (Final)

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Intermediate LISP For SDA Lab Guide v1.0.1 (Final)

Încărcat de

Drepturi de autor:

Formate disponibile

Intermediate Location/ID

Separation Protocol (LISP)

Presented by: Cisco’s Solutions Readiness Engineering Team

© 2017 Cisco Systems Inc. Solutions Readiness Engineering Page 2

Why the Map-Cache Command is Important ..................................................................................... 40

© 2017 Cisco Systems Inc. Solutions Readiness Engineering Page 3

Task 2 - Telnet from PC-2 to NewYork.................................................................................................... 77

© 2017 Cisco Systems Inc. Solutions Readiness Engineering Page 4

© 2017 Cisco Systems Inc. Solutions Readiness Engineering Page 5

© 2017 Cisco Systems Inc. Solutions Readiness Engineering Page 6

About This Lab

Figure 0-1: MS/MR CLI Syntax Changes

© 2017 Cisco Systems Inc. Solutions Readiness Engineering Page 7

© 2017 Cisco Systems Inc. Solutions Readiness Engineering Page 8

Lab Topology – Layer 2

© 2017 Cisco Systems Inc. Solutions Readiness Engineering Page 9

Lab Topology – Layer 3

© 2017 Cisco Systems Inc. Solutions Readiness Engineering Page 10

Lab Conventions on Last Octet of IP Addresses for Routers and Switches

Loopback IP Address = 192.168.255.x/32 where x = router number

© 2017 Cisco Systems Inc. Solutions Readiness Engineering Page 11

Exercise 0: IP Reachability Verification

Existing Configuration Overview

• IP addresses and routing connectivity in AS 5 have been pre-configured.

© 2017 Cisco Systems Inc. Solutions Readiness Engineering Page 12

Task 1 - Verify IP Reachability

© 2017 Cisco Systems Inc. Solutions Readiness Engineering Page 13

Figure 0-1: Successful TCL Script

All pings should succeed on all six routers.

Figure 0-2: TCLquit Example

© 2017 Cisco Systems Inc. Solutions Readiness Engineering Page 14

Exercise 1: LISP xTR and MS/MR Configuration

Task 1 - Basic LISP xTR Configuration – EdgeNode1

Step 5. Connect to the console of EdgeNode1, and enter privileged mode.

Step 8. Enable the router to be an ITR for IPv4 addresses.

Step 9. Enable the router to be an ETR for IPv4 addresses.

Step 10. Define the ITR IPv4 Map Resolver as 192.168.255.4.

Remember that an ITR sends the EID-to-RLOC map resolution

ipv4 itr map-resolver 192.168.255.4

ipv4 etr map-server 192.168.255.4 key EN1-KEY

© 2017 Cisco Systems Inc. Solutions Readiness Engineering Page 15

database-mapping 192.168.10.0/24 ipv4-interface loopback 0 priority 10 weight 10

Step 13. Exit out of global configuration.

Figure 1-1: LISP xTR Configuration – EdgeNode1

1. A LISP Interface is created and changes to the up state.

Task 2 - Basic LISP xTR Configuration – EdgeNode2

ipv4 itr map-resolver 192.168.255.4

ipv4 etr map-server 192.168.255.4 key EN2-KEY

© 2017 Cisco Systems Inc. Solutions Readiness Engineering Page 16

database-mapping 192.168.20.0/24 ipv4-interface loopback 0 priority 10 weight 10

Step 19. Exit out of global configuration mode.

Figure 1-2: LISP xTR Configuration – EdgeNode2

1. A LISP Interface is created and changes to the up state.

© 2017 Cisco Systems Inc. Solutions Readiness Engineering Page 17

Task 3 - Basic LISP xTR Configuration – BorderNode

Step 20. Configure BorderNode similarly to the edge nodes.

ipv4 itr map-resolver 192.168.255.4

Step 22. Exit out of global configuration mode.

Figure 1-3: LISP xTR Configuration – BorderNode

© 2017 Cisco Systems Inc. Solutions Readiness Engineering Page 18

Task 4 - Basic LISP MS/MR Configuration – ControlPlaneNode

Step 31. Exit LISP site configuration mode for EN1.

© 2017 Cisco Systems Inc. Solutions Readiness Engineering Page 19