Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
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
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
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.
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 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
EdgeNode1 = Router 1 = .1
EdgeNode2 = Router 2 = .2
BorderNode = Router 3 = .3
ControlPlaneNode = Router 4 = .4
DefaultBorder = Router 5 = .5
LabAccessSwitch = Router 6 = .6
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
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).
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.
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.
Step 4. Use the tclquit command to exit the TCL shell and drop the CLI back to privileged EXEC
mode.
tclquit
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.
configure terminal
Step 7. Configure the LISP routing protocol (enable the service, and enter router configuration
mode).
router lisp
ipv4 itr
ipv4 etr
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.
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
end
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
end
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.
configure terminal
router lisp
ipv4 itr
ipv4 etr
Step 21. Define only the ITR Map Resolver pointing to the ControlPlaneNode’s Loopback0.
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.
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
Step 25. Configure the LISP routing protocol (enable the service, and enter router configuration
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
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.
authentication-key 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
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.
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.
configure terminal
interface gigabitEthernet 1/0/12
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
ip lisp source-locator Loopback 0
exit
interface GigabitEthernet0/0/1
ip lisp source-locator Loopback 0
end
Step 44. Connect to the console of ControlPlaneNode, and enter privileged mode.
Step 45. Configure Loopback 0 as the source-locator for LISP packets for both fabric-facing
interfaces.
configure terminal
interface TenGigabitEthernet1/0/1
ip lisp source-locator Loopback 0
exit
interface TenGigabitEthernet1/0/2
ip lisp source-locator Loopback 0
end
Step 46. Connect to the console of DefaultBorder, and enter privileged mode.
Step 47. Configure Loopback 0 as the source-locator for LISP packets for both fabric-facing
interfaces.
configure terminal
interface GigabitEthernet0/0/1
ip lisp source-locator Loopback 0
exit
interface GigabitEthernet0/0/2
ip lisp source-locator Loopback 0
end
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.
show ip lisp
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.
Step 52. Register the EID-prefix space on EdgeNode2 with the Map Server.
Because lig has been performed, prompting an EID-prefix space mapping, the Map Server should have
the LISP site information fully populated.
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.
Step 54. Display the current static and dynamic IPv4 EID-to-RLOC map-cache entries on
EdgeNode1 and EdgeNode2.
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
Step 56. Connect to the console of PC-2 and initiate a ping to PC-1.
ping 192.168.10.100
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
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.
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) 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.
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.
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.
Note: NLRI stands for network layer reachability information and will be covered later in the lab.
Step 58. Connect to the console of DefaultBorder, and enter privileged mode.
Step 59. Enable the BGP process for Autonomous System 5.
configure terminal
router bgp 5
Step 61. Activate the exchange of information (NLRI) with neighbor 198.51.100.7.
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.
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.
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
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.
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.
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.
Step 65. Connect to the console of DefaultBorder, and enter privileged mode.
Step 66. Configure the LISP routing protocol (enable the service, and enter router configuration
mode).
configure terminal
router lisp
ipv4 proxy-etr
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.
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.
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.
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.
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.
1. The map-cache command caused the creation of the LISP0 interface and changes the status to
the up state.
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
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).
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.
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
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.
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
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…
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 82. Connect to the console of DefaultBorder, and enter privileged mode.
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
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.
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.
Step 85. From the console of DefaultBorder, display the static routes in the running
configuration. Use the pipe to filter the output.
Note: The show ip route static command produces a similar output, although does not show the tag information.
Additional static routes may be present in the DefaultBorder to allow NTP connectivity. This output has been omitted
for brevity from the screen shots.
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.
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.
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.
Here is an example route-map for clarity. It uses all the configuration elements. It also references an
ACL.
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.
Step 86. Connect to the console of DefaultBorder, and enter privileged mode.
Step 87. Configure sequence 10 of a route map named EID-INJECT. Use a permit clause.
configure terminal
route-map EID-INJECT permit 10
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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 198.18.133.80
ping 198.18.133.80
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).
Step 105. From the console of LabAccessSwitch, stop the packet capture.
Note: The number of packets captured and the duration will vary from this screen capture.
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.
ControlPlaneNode#
Echo Reply Packet
*Sep 25 16:38:21.128: LISP: Processing received Encap-Control(8) message on TenGigabitEthernet1/0/1
Step 107. Disable all debugging on ControlPlaneNode with the undebug all command.
undebug all
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.
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.
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
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.
Step 111. Notice that 3CDaemon will be listening for connections on 192.168.100.50.
Step 112. TFTP transfer the capture file from the LabAccessSwitch to the Jump Host.
lispcap
192.168.100.50
lispcap.pcapng
1. Please use the extension .pcapng for the destination file name.
This will ensure that Wireshark can open and recognize the file.
Step 114. Double click the lispcap.pcapng file to open the file in Wireshark.
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.
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.
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.
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.
Step 121. Use the show monitor capture command to verify the previous step.
Note: This command should have no output. If there is output, the capture has not been removed.
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.
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).
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
Note: Entering configuration mode on NewYork ensures that there are several telnet packets available in the capture.
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.
telnetcap
192.168.100.50
telnet.pcapng
Step 132. Double click the telnet.pcapng file to open the file in Wireshark.
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.
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).
Telnet > TCP > IP > Ethernet > VXLAN > UDP > IP > Ethernet > Bits on the wire
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.
Step 137. From the console of the LabAccessSwitch, remove the previous capture.
Step 138. Use the show monitor capture command to verify the previous step.
Note: This command should have no output. If there is output, the capture has not been removed.
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
delete flash:lispcap
Step 140. Use regular expressions to ensure the capture files are no longer present in flash.
Note: This command should have no output. If there is output, the files have not been removed.
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.
1
Note: Recall the database mapping command for EdgeNode1 from Step 12.
database-mapping 192.168.10.0/24 ipv4-interface loopback 0 priority 10 weight 10
Step 142. Use the show ip lisp forwarding eid command to display LISP attributes and
encapsulation information for the EID-space for EdgeNode2.
Note: Recall the database mapping command for EdgeNode2 from Step 18.
database-mapping 192.168.20.0/24 ipv4-interface loopback 0 priority 10 weight 10
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.
EdgeNode1
enable
configure terminal
hostname EdgeNode1
ip routing
no ip domain-lookup
ip domain-name dna.local
no boot system
boot system flash:packages.16.5.1.conf
ip ssh version 2
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 GigabitEthernet1/0/11
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
interface GigabitEthernet1/0/12
description Link to Lab Access Switch
no switchport
ip address 192.168.1.1 255.255.255.0
load-interval 30
carrier-delay msec 0
ip router isis
isis network point-to-point
isis authentication mode md5
isis authentication key-chain IS-IS_INTERFACE
exit
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
no passive-interface gigabitEthernet 1/0/12
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
end
EdgeNode2
enable
configure terminal
hostname EdgeNode2
ip routing
no ip domain-lookup
ip domain-name dna.local
no boot system
boot system flash:packages.16.5.1.conf
ip ssh version 2
interface vlan 1
no ip address
shutdown
exit
interface Loopback0
description Fabric Internal RLOC
ip address 192.168.255.2 255.255.255.255
exit
interface GigabitEthernet1/0/11
description Link to PC-2
no switchport
ip address 192.168.20.2 255.255.255.0
load-interval 30
carrier-delay msec 0
exit
interface GigabitEthernet1/0/12
description Link to Lab Access Switch
no switchport
ip address 192.168.2.2 255.255.255.0
load-interval 30
carrier-delay msec 0
ip router isis
isis network point-to-point
isis authentication mode md5
isis authentication key-chain IS-IS_INTERFACE
exit
router isis
log-adjacency-changes
net 49.0000.2222.2222.2222.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
no passive-interface gigabitEthernet 1/0/12
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
end
BorderNode
enable
configure terminal
hostname BorderNode
ip routing
no ip domain-lookup
ip domain-name dna.local
no boot system
boot system flash bootflash:packages.16.5.1.conf
ip ssh version 2
interface Loopback0
description Fabric Internal RLOC
ip address 192.168.255.3 255.255.255.255
exit
interface GigabitEthernet0/0/0
description Link to Lab Access Switch
no shutdown
ip address 192.168.3.3 255.255.255.0
load-interval 30
carrier-delay msec 0
ip router isis
isis network point-to-point
isis authentication mode md5
isis authentication key-chain IS-IS_INTERFACE
mtu 9100
ip mtu 9100
isis bfd disable
exit
interface GigabitEthernet0/0/1
description Link to Default Border Node
no shutdown
ip address 192.168.35.3 255.255.255.0
load-interval 30
carrier-delay msec 0
ip router isis
isis network point-to-point
isis authentication mode md5
isis authentication key-chain IS-IS_INTERFACE
mtu 9100
ip mtu 9100
bfd interval 300 min_rx 300 multiplier 3
no bfd echo
exit
router isis
log-adjacency-changes
net 49.0000.3333.3333.3333.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 0/0/0
no passive-interface gigabitEthernet 0/0/1
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
end
ControlPlaneNode
enable
configure terminal
hostname ControlPlaneNode
ip routing
no ip domain-lookup
ip domain-name dna.local
no boot system
boot system flash:packages.16.5.1.conf
ip ssh version 2
interface vlan 1
no ip address
shutdown
exit
interface Loopback0
description Fabric Internal RLOC
ip address 192.168.255.4 255.255.255.255
exit
interface TenGigabitEthernet1/0/1
description Link to Lab Access Switch
no switchport
ip address 192.168.4.4 255.255.255.0
load-interval 30
carrier-delay msec 0
ip router isis
isis network point-to-point
isis authentication mode md5
isis authentication key-chain IS-IS_INTERFACE
exit
interface TenGigabitEthernet1/0/2
description Link to Default Border Node for iBPG
no switchport
ip address 192.168.45.4 255.255.255.0
load-interval 30
carrier-delay msec 0
ip router isis
isis network point-to-point
isis authentication mode md5
isis authentication key-chain IS-IS_INTERFACE
exit
router isis
log-adjacency-changes
net 49.0000.4444.4444.4444.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 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
interface TenGigabitEthernet1/0/2
isis metric 3000
exit
end
DefaultBorder
enable
configure terminal
hostname DefaultBorder
no ip domain-lookup
ip domain-name dna.local
no boot system
boot system flash bootflash:packages.16.5.1.conf
ip ssh version 2
interface Loopback0
description Fabric Internal RLOC
ip address 192.168.255.5 255.255.255.255
exit
interface GigabitEthernet0/0/0
description Link to ISP
no shutdown
ip address 198.51.100.5 255.255.255.0
load-interval 30
carrier-delay msec 0
no shutdown
exit
interface GigabitEthernet0/0/1
description Link to Border Node
no shutdown
ip address 192.168.35.5 255.255.255.0
load-interval 30
carrier-delay msec 0
ip router isis
isis network point-to-point
isis authentication mode md5
isis authentication key-chain IS-IS_INTERFACE
mtu 9100
ip mtu 9100
bfd interval 300 min_rx 300 multiplier 3
no bfd echo
exit
interface GigabitEthernet0/0/2
description Link to Control Plane Node for iBGP
no shutdown
ip address 192.168.45.5 255.255.255.0
load-interval 30
carrier-delay msec 0
ip router isis
interface GigabitEthernet0/0/3
description !! PLEASE LEAVE SHUTDOWN !!
shutdown
exit
router isis
log-adjacency-changes
net 49.0000.5555.5555.5555.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 0/0/0
no passive-interface gigabitEthernet 0/0/1
no passive-interface gigabitEthernet 0/0/2
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
interface GigabitEthernet0/0/2
end
LabAccessSwitch
enable
configure terminal
host LabAccessSwitch
ip routing
no ip domain-lookup
ip domain-name dna.local
no boot system
boot system flash:packages.16.5.1.conf
ip ssh version 2
system mtu 9100
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
interface GigabitEthernet1/0/10
description SSH Access to CSR1000vs
no switchport
ip address 198.18.100.6 255.255.255.0
load-interval 30
carrier-delay msec 0
exit
no switchport
ip add 192.168.100.6 255.255.255.0
carrier-delay msec 0
load-interval 30
exit
router isis
log-adjacency-changes
net 49.0000.6666.6666.6666.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/1
no passive-interface gigabitEthernet 1/0/2
no passive-interface gigabitEthernet 1/0/3
no passive-interface gigabitEthernet 1/0/4
no passive-interface gigabitEthernet 1/0/10
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
end
ISP
enable
configure terminal
hostname ISP
cdp run
no ip domain-lookup
ip domain-name ISP.com
interface loopback 0
description For BGP NLRI Prefix Injection
ip address 77.77.77.77 255.255.255.255
exit
interface GigabitEthernet1
description Link to Default Border Node
ip address 198.51.100.7 255.255.255.0
negotiation auto
cdp enable
no shutdown
exit
interface GigabitEthernet2
description Link to New York Router
ip address 203.0.113.7 255.255.255.0
negotiation auto
cdp enable
no shutdown
exit
interface GigabitEthernet3
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
neighbor 198.51.100.5 remote-as 5
neighbor 203.0.113.8 remote-as 8
neighbor 198.51.100.5 activate
neighbor 203.0.113.8 activate
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
interface GigabitEthernet1
description Link to PC-3
ip address 198.18.133.8 255.255.255.0
negotiation auto
cdp enable
no shutdown
exit
interface GigabitEthernet2
description Link to ISP
ip address 203.0.113.8 255.255.255.0
negotiation auto
cdp enable
no shutdown
exit
interface GigabitEthernet3
description !! SSH ACCESS !!
vrf forwarding MGMT-INTERFACE
ip address 198.18.100.108 255.255.255.0
negotiation auto
cdp enable
no shutdown
exit
router bgp 8
bgp log-neighbor-changes
neighbor 203.0.113.7 remote-as 7
neighbor 203.0.113.7 activate
network 198.18.133.0 mask 255.255.255.0
network 203.0.113.0 mask 255.255.255.0
exit
interface GigabitEthernet3
description !! SSH ACCESS !!
vrf forwarding MGMT-INTERFACE
ip address 198.18.100.108 255.255.255.0
negotiation auto
cdp enable
no shutdown
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
exit
banner login $ Use the 'terminal monitor' command after logging in. $
banner motd $
Use the 'terminal monitor' command after logging in. $
end
PC-1
enable
configure terminal
hostname PC-1
cdp run
no ip domain-lookup
address-family ipv4
exit-address-family
exit
interface GigabitEthernet1
description Link to Edge Node #1
ip address 192.168.10.100 255.255.255.0
negotiation auto
cdp enable
no shutdown
exit
interface GigabitEthernet2
description !! SSH ACCESS !!
vrf forwarding MGMT-INTERFACE
ip address 198.18.100.101 255.255.255.0
negotiation auto
cdp enable
no shutdown
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
exit
banner login $ Use the 'terminal monitor' command after logging in. $
banner motd $
Use the 'terminal monitor' command after logging in. $
end
PC-2
enable
configure terminal
hostname PC-2
cdp run
no ip domain-lookup
interface GigabitEthernet1
description Link to Edge Node #2
ip address 192.168.20.200 255.255.255.0
negotiation auto
cdp enable
no shutdown
exit
interface GigabitEthernet2
description !! SSH ACCESS !!
vrf forwarding MGMT-INTERFACE
ip address 198.18.100.102 255.255.255.0
negotiation auto
cdp enable
no shutdown
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
exit
banner login $ Use the 'terminal monitor' command after logging in. $
banner motd $
Use the 'terminal monitor' command after logging in. $
end
PC-3
enable
configure terminal
hostname PC-3
cdp run
no ip domain-lookup
interface GigabitEthernet1
description Link to New York Router
ip address 198.18.133.80 255.255.255.0
negotiation auto
cdp enable
no shutdown
exit
interface GigabitEthernet2
description !! SSH ACCESS !!
vrf forwarding MGMT-INTERFACE
ip address 198.18.100.103 255.255.255.0
negotiation auto
cdp enable
no shutdown
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
exit
banner login $ Use the 'terminal monitor' command after logging in. $
banner motd $
Use the 'terminal monitor' command after logging in. $
end
Exercise 0
tclquit
Exercise 1
EdgeNode1
configure terminal
interface gigabitEthernet 1/0/12
ip lisp source-locator Loopback 0
end
EdgeNode2
configure terminal
interface gigabitEthernet 1/0/12
ip lisp source-locator Loopback 0
end
BorderNode
configure terminal
interface GigabitEthernet0/0/0
ip lisp source-locator Loopback 0
exit
interface GigabitEthernet0/0/1
ip lisp source-locator Loopback 0
end
ControlPlaneNode
configure terminal
interface TenGigabitEthernet1/0/1
ip lisp source-locator Loopback 0
exit
interface TenGigabitEthernet1/0/2
ip lisp source-locator Loopback 0
end
DefaultBorder
configure terminal
interface GigabitEthernet0/0/1
Exercise 2
Task 5 - Confirm LISP Control Plane, LISP Data Plane, and IP Reachability
ping 192.168.20.200
ping 192.168.10.100
Exercise 3
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 5 - Redistribute the Static Null Route using the Route Map
configure terminal
router bgp 5
redistribute static route-map EID-INJECT
end
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
Please see the LISP Intermediate Folder on the Jump Host to view the debug messages in .png and .txt
formats.
Please see the LISP Intermediate Folder on the Jump Host to view the debug messages in .png and .txt
formats.
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.
Username: cisco
Password: cisco
configure terminal
exit
exit
telnetcap
192.168.100.50
telnet.pcapng
Task 5 - Open and View the Packet Capture
Please see the LISP Intermediate Folder on the Jump Host to view a master copy of the packet capture.
Please see the LISP Intermediate Folder on the Jump Host to view a master copy of the packet capture.
Please copy and paste the commands below to ensure only the appropriate files are deleted.
delete flash:telnetcap
delete flash:lispcap
EdgeNode1
version 16.5
no service pad
service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime msec localtime show-timezone
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
!
enable password cisco
!
no aaa new-model
boot system switch all flash:packages.16.5.1.conf
clock timezone UTC -5 0
clock summer-time EST recurring
switch 1 provision c9300-24u
!
ip routing
!
no ip domain lookup
ip domain name dna.local
!
vtp domain EdgeNode1.local
vtp mode transparent
cpp system-default
!
key chain IS-IS_INTERFACE
key 1
key-string DNAR@CKS
key chain IS-IS_LSDB
key 1
key-string C@mpusFabric
!
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
interface GigabitEthernet1/0/7
shutdown
!
interface GigabitEthernet1/0/8
shutdown
!
interface GigabitEthernet1/0/9
shutdown
!
interface GigabitEthernet1/0/10
shutdown
!
interface GigabitEthernet1/0/11
description Link to PC-1
no switchport
ip address 192.168.10.1 255.255.255.0
load-interval 30
carrier-delay msec 0
!
interface GigabitEthernet1/0/12
description Link to Lab Access Switch
no switchport
ip address 192.168.1.1 255.255.255.0
ip router isis
ip lisp source-locator Loopback0
load-interval 30
carrier-delay msec 0
isis network point-to-point
isis authentication mode md5
isis authentication key-chain IS-IS_INTERFACE
!
interface GigabitEthernet1/0/13
shutdown
!
interface GigabitEthernet1/0/14
shutdown
!
interface GigabitEthernet1/0/15
shutdown
!
interface GigabitEthernet1/0/16
shutdown
!
interface GigabitEthernet1/0/17
shutdown
!
interface GigabitEthernet1/0/18
shutdown
!
interface GigabitEthernet1/0/19
shutdown
!
interface GigabitEthernet1/0/20
shutdown
!
interface GigabitEthernet1/0/21
shutdown
!
interface GigabitEthernet1/0/22
shutdown
!
interface GigabitEthernet1/0/23
shutdown
!
interface GigabitEthernet1/0/24
shutdown
!
interface GigabitEthernet1/1/1
!
interface GigabitEthernet1/1/2
!
interface GigabitEthernet1/1/3
!
interface GigabitEthernet1/1/4
!
interface TenGigabitEthernet1/1/1
!
interface TenGigabitEthernet1/1/2
!
interface TenGigabitEthernet1/1/3
!
interface TenGigabitEthernet1/1/4
!
interface TenGigabitEthernet1/1/5
!
interface TenGigabitEthernet1/1/6
!
interface TenGigabitEthernet1/1/7
!
interface TenGigabitEthernet1/1/8
!
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 map-resolver 192.168.255.4
ipv4 itr
ipv4 etr map-server 192.168.255.4 key EN1-KEY
ipv4 etr
ipv4 use-petr 192.168.255.5
exit
!
router isis
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
log-adjacency-changes
passive-interface default
no passive-interface GigabitEthernet1/0/11
no passive-interface GigabitEthernet1/0/12
!
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
service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime msec localtime show-timezone
no platform punt-keepalive disable-kernel-core
!
hostname EdgeNode2
!
vrf definition Mgmt-vrf
!
address-family ipv4
exit-address-family
!
address-family ipv6
exit-address-family
!
enable password cisco
!
no aaa new-model
boot system switch all flash:packages.16.5.1.conf
clock timezone UTC -5 0
class system-cpp-police-forus
class system-cpp-default
!
interface Loopback0
description Fabric Internal RLOC
ip address 192.168.255.2 255.255.255.255
!
interface LISP0
!
interface GigabitEthernet0/0
vrf forwarding Mgmt-vrf
no ip address
shutdown
negotiation auto
!
interface GigabitEthernet1/0/1
shutdown
!
interface GigabitEthernet1/0/2
shutdown
!
interface GigabitEthernet1/0/3
shutdown
!
interface GigabitEthernet1/0/4
shutdown
!
interface GigabitEthernet1/0/5
shutdown
!
interface GigabitEthernet1/0/6
shutdown
!
interface GigabitEthernet1/0/7
shutdown
!
interface GigabitEthernet1/0/8
shutdown
!
interface GigabitEthernet1/0/9
shutdown
!
interface GigabitEthernet1/0/10
shutdown
!
interface GigabitEthernet1/0/11
description Link to PC-2
no switchport
ip address 192.168.20.2 255.255.255.0
load-interval 30
carrier-delay msec 0
!
interface GigabitEthernet1/0/12
description Link to Lab Access Switch
no switchport
ip address 192.168.2.2 255.255.255.0
ip router isis
ip lisp source-locator Loopback0
load-interval 30
carrier-delay msec 0
router lisp
encapsulation vxlan
database-mapping 192.168.20.0/24 IPv4-interface Loopback0 priority 10 weight 10
ipv4 itr map-resolver 192.168.255.4
ipv4 itr
ipv4 etr map-server 192.168.255.4 key EN2-KEY
ipv4 etr
ipv4 use-petr 192.168.255.5
exit
!
router isis
net 49.0000.2222.2222.2222.00
is-type level-2-only
authentication mode md5
authentication key-chain IS-IS_LSDB level-2
metric-style wide
log-adjacency-changes
passive-interface default
no passive-interface GigabitEthernet1/0/11
no passive-interface GigabitEthernet1/0/12
!
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.2.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
BorderNode
version 16.5
service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime msec localtime show-timezone
platform qfp utilization monitor load 80
no platform punt-keepalive disable-kernel-core
!
hostname BorderNode
!
boot-start-marker
boot system flash bootflash:packages.16.5.1.conf
boot-end-marker
!
vrf definition Mgmt-intf
!
address-family ipv4
exit-address-family
!
address-family ipv6
exit-address-family
!
enable password cisco
!
no aaa new-model
clock timezone UTC -5 0
clock summer-time EST recurring
!
no ip domain lookup
ip domain name dna.local
!
subscriber templating
!
vtp domain BorderNode.local
vtp mode transparent
!
multilink bundle-name authenticated
!
key chain IS-IS_INTERFACE
key 1
key-string DNAR@CKS
key chain IS-IS_LSDB
key 1
key-string C@mpusFabric
!
crypto pki trustpoint TP-self-signed-469652256
enrollment selfsigned
subject-name cn=IOS-Self-Signed-Certificate-469652256
revocation-check none
rsakeypair TP-self-signed-469652256
!
crypto pki certificate chain TP-self-signed-469652256
!
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
!
diagnostic bootup level minimal
spanning-tree extend system-id
!
username cisco privilege 15 one-time password 0 cisco
!
redundancy
mode none
!
interface Loopback0
description Fabric Internal RLOC
ip address 192.168.255.3 255.255.255.255
!
interface GigabitEthernet0/0/0
description Link to Lab Access Switch
mtu 9100
ip address 192.168.3.3 255.255.255.0
ip lisp source-locator Loopback0
ip router isis
load-interval 30
carrier-delay msec 0
negotiation auto
isis network point-to-point
isis authentication mode md5
isis authentication key-chain IS-IS_INTERFACE
isis bfd disable
!
interface GigabitEthernet0/0/1
description Link to Default Border Node
mtu 9100
ip address 192.168.35.3 255.255.255.0
ip lisp source-locator Loopback0
ip router isis
load-interval 30
carrier-delay msec 0
negotiation auto
bfd interval 300 min_rx 300 multiplier 3
no bfd echo
isis network point-to-point
isis authentication mode md5
isis authentication key-chain IS-IS_INTERFACE
!
interface GigabitEthernet0/0/2
no ip address
shutdown
negotiation auto
!
interface GigabitEthernet0/0/3
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
switchport mode trunk
no mop enabled
no mop sysid
!
interface ucse2/0/1
no ip address
shutdown
no negotiation auto
switchport mode trunk
no mop enabled
no mop sysid
!
interface GigabitEthernet0
vrf forwarding Mgmt-intf
no ip address
shutdown
negotiation auto
!
router lisp
encapsulation vxlan
ipv4 itr map-resolver 192.168.255.4
ipv4 itr
ipv4 etr
exit
!
router isis
net 49.0000.3333.3333.3333.00
is-type level-2-only
authentication mode md5
authentication key-chain IS-IS_LSDB level-2
metric-style wide
log-adjacency-changes
passive-interface default
no passive-interface GigabitEthernet0/0/0
no passive-interface GigabitEthernet0/0/1
bfd all-interfaces
!
threat-visibility
ip forward-protocol nd
ip http server
ip http authentication local
ip http secure-server
ip tftp source-interface GigabitEthernet0
ip route 128.107.212.175 255.255.255.255 192.168.3.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
!
mgcp behavior rsip-range tgcp-only
mgcp behavior comedia-role none
ControlPlaneNode
version 16.5
no service pad
service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime msec localtime show-timezone
no platform punt-keepalive disable-kernel-core
!
hostname ControlPlaneNode
!
vrf definition Mgmt-vrf
!
address-family ipv4
exit-address-family
!
address-family ipv6
exit-address-family
!
enable password cisco
!
no aaa new-model
boot system switch all flash:packages.16.5.1.conf
clock timezone UTC -5 0
clock summer-time EST recurring
switch 1 provision ws-c3850-12xs
!
ip routing
!
no ip domain lookup
ip domain name dna.local
!
interface TenGigabitEthernet1/1/1
shutdown
!
interface TenGigabitEthernet1/1/2
shutdown
!
interface TenGigabitEthernet1/1/3
shutdown
!
interface TenGigabitEthernet1/1/4
shutdown
!
interface Vlan1
no ip address
shutdown
!
router lisp
site EN1
authentication-key EN1-KEY
eid-prefix 192.168.10.0/24
exit
!
site EN2
authentication-key EN2-KEY
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
is-type level-2-only
authentication mode md5
authentication key-chain IS-IS_LSDB level-2
metric-style wide
log-adjacency-changes
passive-interface default
no passive-interface TenGigabitEthernet1/0/1
no passive-interface TenGigabitEthernet1/0/2
!
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.4.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
DefaultBorder
version 16.5
service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime msec localtime show-timezone
platform qfp utilization monitor load 80
no platform punt-keepalive disable-kernel-core
!
hostname DefaultBorder
!
boot-start-marker
boot system flash bootflash:packages.16.5.1.conf
boot-end-marker
!
vrf definition Mgmt-intf
!
address-family ipv4
exit-address-family
!
address-family ipv6
exit-address-family
!
enable password cisco
!
no aaa new-model
clock timezone UTC -5 0
clock summer-time EST recurring
!
no ip domain lookup
ip domain name dna.local
!
subscriber templating
!
vtp domain DefaultBorderNode.local
vtp mode transparent
!
multilink bundle-name authenticated
!
key chain IS-IS_INTERFACE
key 1
key-string DNAR@CKS
key chain IS-IS_LSDB
key 1
key-string C@mpusFabric
!
crypto pki trustpoint TP-self-signed-1984944609
enrollment selfsigned
subject-name cn=IOS-Self-Signed-Certificate-1984944609
revocation-check none
rsakeypair TP-self-signed-1984944609
!
crypto pki certificate chain TP-self-signed-1984944609
!
license udi pid ISR4451-X/K9 sn FOC17042FK2
license accept end user agreement
license boot level appxk9
license boot level securityk9
!
diagnostic bootup level minimal
spanning-tree extend system-id
!
username cisco privilege 15 one-time password 0 cisco
!
redundancy
mode none
!
interface Loopback0
description Fabric Internal RLOC
ip address 192.168.255.5 255.255.255.255
!
interface LISP0
!
interface GigabitEthernet0/0/0
description Link to ISP
ip address 198.51.100.5 255.255.255.0
load-interval 30
carrier-delay msec 0
negotiation auto
!
interface GigabitEthernet0/0/1
description Link to Border Node
mtu 9100
ip address 192.168.35.5 255.255.255.0
ip lisp source-locator Loopback0
ip router isis
load-interval 30
carrier-delay msec 0
negotiation auto
bfd interval 300 min_rx 300 multiplier 3
no bfd echo
isis network point-to-point
isis authentication mode md5
isis authentication key-chain IS-IS_INTERFACE
!
interface GigabitEthernet0/0/2
description Link to Control Plane Node for iBGP
mtu 9100
ip address 192.168.45.5 255.255.255.0
ip lisp source-locator Loopback0
ip router isis
load-interval 30
carrier-delay msec 0
negotiation auto
isis network point-to-point
isis metric 2000
isis authentication mode md5
isis authentication key-chain IS-IS_INTERFACE
isis bfd disable
!
interface GigabitEthernet0/0/3
description !! PLEASE LEAVE SHUTDOWN !!
no ip address
shutdown
negotiation auto
!
interface GigabitEthernet0
vrf forwarding Mgmt-intf
no ip address
shutdown
negotiation auto
!
router lisp
encapsulation vxlan
map-cache 192.168.0.0/16 map-request
ipv4 itr map-resolver 192.168.255.4
ipv4 map-request-source 192.168.255.5
ipv4 proxy-etr
ipv4 proxy-itr 192.168.255.5
exit
!
router isis
net 49.0000.5555.5555.5555.00
is-type level-2-only
authentication mode md5
authentication key-chain IS-IS_LSDB level-2
metric-style wide
log-adjacency-changes
passive-interface default
no passive-interface GigabitEthernet0/0/0
no passive-interface GigabitEthernet0/0/1
no passive-interface GigabitEthernet0/0/2
bfd all-interfaces
!
router bgp 5
bgp log-neighbor-changes
neighbor 198.51.100.7 remote-as 7
!
threat-visibility
ip forward-protocol nd
ip http server
ip http authentication local
ip http secure-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
ip ssh server algorithm encryption aes128-ctr aes192-ctr aes256-ctr
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
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)