LISP - OMP - BGP EVPN Interoperability - Part IV: BGP EVPN IP Prefix Route (Type 5)

Introduction

 

Figure 3-1 shows the Overlay Network Control-Plane interaction. Edge-xTR-11 registers reachability information (IP address and location) of EP1 to MapSrv-22. MapSrv-22 stores the information into the Mapping database and then installs it to RIB. Then MapSrv-22 exports the information to the BGP process and sends BGP Update using VPNv4 address format to Border-PxTR-13. Border-PxTR-13 imports NLRI into BRIB and RIB. Then it sends BGP Update to the local SD-WAN edge device vEdge-1. After importing the received information into BRIB and RIB, vEdge-1 exports the information to the OMP process and advertises it over a DTLS connection to vSmart (SD-WAN Control-Plane node). vSmart, in turn, advertises information to remote SD-WAN device vEdge-2. After importing the received information into the RIB, vEdge-2 exports the information to the BGP process and sends BGP Update to Border-Leaf-13. Border-Leaf-13 installs the information into BRIB and RIB. Next, Border-Leaf-13 sends BGP Update message using EVPN route type 5 (IP Prefix Route) to its iBGP peer Spine-1 (BGP Route-Reflector) using auto-generated Route-Target 65030:10077. Spine-1 forwards the BGP Update to Leaf-1, which imports the information into L3VNI used with VRF NWKT and installs the route into the VRF NWKT RIB.

Figure 3-1: Overall Control-Plane Operation.

LISP - OMP - BGP EVPN Interoperability - Part III: SD-WAN Control Plane

 Introduction

 

Figure 2-1 shows the Control Plane operation when host EP1 using IP 172.16.100.10/32 joins the network. In the previous chapter, we saw how Edge-xTR-11 learned the IP address and registered it to MapSrv-22 by using the LISP Map-register Message where the Instance-Id 100 represents Virtual Network-Id (VN-Id). MapSrv-22, in turn, advertised the NLRI to Border-PxTR-13 as BGP VPNv4 Update message where extended community RT 1:100 (=VN-Id) is used as a kind of VPN identifier (BGP VPNv4 route import/export policy is based on RT value). This chapter first explains how Border-PxTR-13 sends BGP IPv4 Update message to local SD-WAN device vEdge-1. The eBGP peering between Border-PxTR-13 and vEdge1 is VRF based and BGP updates over it don’t carry any VN-Id. vEdge-1 imports the routing information from BRIB to RIB. Then it advertises the routing information by using OMP (Overlay Management Protocol) to the SD-WAN centralized Control Plane vSmart over the DTLS tunnel using System-IP as an originator-Id and VPN label 1003 as a VN-Id. vSmart forwards this update to SD-WAN device vEdge-2 located in Datacenter. vEdge-2 installs the route into the routing table. After that, it exports the routing information from the RIB to the BGP process and sends the BGP IPv4 Update message to Border-Leaf-13 over VRF NWKT eBGP peering without VN-Id.

Figure 2-1: Overall Control-Plane Operation.

LISP - OMP - BGP EVPN Interoperability - Part II: VPNv4 Update from Control Plane to Border-PxTR

 

The previous chapter describes how Edge-xTR-11 used LISP Map-Register message to advertise EID-to-RLOC information to MapServ-22. It also explained how MapSrv-22, as a role of Mapping Server, stores the information into Mapping Data Base. MapSrv-22 is also Map-Resolver. This means that when it receives the LISP Map-Request message from the xTR device, it will respond with a Map-Reply message. If MapSrv-22 knows the EID-to-RLOC mapping, it places this information into the Map-Reply message. If MapSrv-22 doesn’t have mapping information, it instructs requesting xTR to forward traffic to its Proxy-xTR. This, however, is not the case in our example. What we want to do is advertise the EP1 reachability information to Border-PxTR. In order to do that, we need to a) export EID-to-RLOC information from the Mapping Data Base to instance-specific VRF_100 RIB. Then we can advertise it by using BGP and because we want to include virtual network identifier into update we use MP-BGP VPNv4 because there we have Route Target Attribute. The next sections describe the process in detail.

 

Phase 1: Map-Server - RIB Update

 

LISP Map-Server doesn’t install EID-to-RLOC mapping information from the Mapping Database into a RIB by default. To do that we need to export the information from the LISP Mapping DataBase to RIB by using the LISP Instance-specific command route-export site-registrations.  Example 1-6 illustrates the update process. Example 1-7 shows the RIB entry concerning EP1 IP address 172.16.100.10/32 in VRF 100_NWKT. Due to redistribution, the route is shown as directly connected, via Null0. If you take a look at the timestamps in example 1-6 and compare it to timestamps in example 1-3, you will see that the RIB update happens right after the unreliable EID-to-RLOC registration process.

 Complete device configuration can be found in chapter 1 Appendix 1.

Figure 1-10: EID-to-RLOC information from LISP to RIB.

 

LISP - OMP - BGP EVPN Interoperability - Part I: LISP EID-to-RLOC Registration

I have written a couple of books about Network Virtualization Overlay over Layer 3 (NVO3). My first book was about Datacenter network virtualization based on BGP L2VPN EVPN. After that, I wrote a book about Campus networks based on LISP. In my latest book, I introduced the Cisco SD-WAN solution running OMP in Control-Plane. I wanted to write one more book where I combine these three different NVO3 solutions. I haven’t used pictures in the “About This Book” section in my previous books but now I decided to do that because one picture tells more than 1000 words. The figure below combines these three NVO3 solutions and illustrates what is needed to have IP connectivity between EP1 in the LISP domain and EP2 in the BGP EVPN domain. After reading this book you should be able to understand the processes of how IP reachability information about local hosts are advertised from the LISP domain over the SD-WAN to BGP EVPN domain and another way around. I wanted to keep this complex solution as simple as possible. That is why I didn’t include any redundancy.