LISP - OMP - BGP EVPN Interoperability - Part VII: End-to-End Data-Plane Operation

 

Introduction

 

This chapter introduces Data-Plane operation and explains how the data packets from EP3 (IP 172.16.30.3) in Datacenter Fabric are forwarded via SD-WAN to EP1 (IP 172.16.100.10) in Campus Fabric. (1) EndPoint3 sends the ICMP Request packet to its gateway switch Leaf-11. Leaf-11 makes routing decisions based on the VRF NWKT routing table. Before forwarding the packet, Leaf-11 adds a VXLAN header where it uses L3VNI 10077. It also sets the outer IP header where it uses the Border-Leaf-13 tunnel interface’s IP address 192.168.50.13 as a destination. Spine-1 routes the packet to Border-Leaf-13 based on the outer IP address. Border-Leaf-13 notices that the destination IP address of the received IP packet belongs to its’s NVE1 tunnel interface. It removes the outer IP header and based UDP destination port it notices that this is VXLAN encapsulated packet. It knows that L3VNI 10077 belongs to VRF NWKT. It strips off the VXLAN header and routes the packet to vEdge-2. The ingress interface towards DC in vEdge-2 belongs to VPN 10. vEdge-2 consults its routing table. Based on it, vEdge-2 constructs tunnel headers and sends ICMP Request to vEdge-1 via Public-Internet using MPLS Label 1003 as a VPN identifier. Routers in Internet routes packet based on the outer destination IP address. When vEdge-1 receives the packet, it notices that the destination IP address is its’ Public IP address. It first removes the outer IP header. Then it checks the tunnel header. Based on the Label value 1003, it knows that packet belongs to VPN 10. It consults the VPN 10 RIB and routes the packet to Border-PxTR-13. The ingress interface on Border-PxTR-13 belongs to VRF 100_NWKT that belongs to LISP Instance 100. It checks the Instance 100 specific LISP mapping in order to know how it should route the packet. The LISP mapping Database does not contain the information because this is the first packet to destination 172.16.100.10. Border-PxTR-13 sends a LISP Map-Request message to MapSrv-22, which replies with a LISP Map-Reply message, where it describes the RLOC of Edge-xTR-11 that has registered the IP address 172.16.100.10. I have excluded the Map-Request/Reply processes from figure 6-1 to keep the figure simple. Border-Leaf-13 encapsulates the ICMP Request packet with a tunnel header. It sets the Instance-Id 100 on the VXLAN header and adds the outer IP header where it uses the Edge-xTR-11’s IP address 192.168.0.13 as a destination address. Core-1 routes the packet to Edge-xTR-11 based on the outer IP header destination address. Edge-xTR-11 processes the ingress IP packet because the destination IP address belongs to it. Based on the destination UDP port 4789, it knows that the following header is a VXLAN header. Edge-xTR-11 knows that the LISP Instance-Id 100 is bind to BD 100. Because Edge-xTR-11 has an L3 interface in BD 100, it resolves the MAC address for the IP address 172.16.100.10 from the ARP table and the egress interface for the MAC from the MAC address table. EP1 processes the ICMP Request packet and sends the ICMP Reply to EP3.

Figure 6-1: End-to-End Data-Plane Operation.

 

LISP - OMP - BGP EVPN Interoperability - Part VI: LISP Control-Plane - Registering External IP Prefixes

 

Introduction

 

This chapter introduces how Border-PxTR-13 registers the external IP prefix 172.16.30.0/24 received as a BGP update from vEdge-1 to MapSrv-22 using LISP Map-register messages. Chapter 2 explains the LISP RLOC-to-EID mapping process in detail so this chapter just briefly recaps the operation. Figure 5-1 illustrates the overall process. vEdge-1 sends a BGP Update message where it describes the NLRI for prefix 172.16.30.0/24. Border-PxTR-13 first imports the information into the LISP processes. Next, it sends a LISP Map-Register message to MapSrv-22. In addition to IP prefix information, the Map-Register message carries Locator Record information that describes the destination IP address used in the outer IP header (tunnel header) when devices route IP packets towards the advertised subnet.  

Figure 5-1: Overall Control-Plane Operation: OMP to LISP

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.

 

Comparing Internet Connection used in AWS and LISP Based Networks

Forewords

This post starts by discussing the Internet connection from the AWS VPC Control Plane operation perspective. The public AWS documentation only describes the basic components, such as an  Internet Gateway (IGW) and a subnet specific Implicit Routers. However, the public AWS documentation does not describe the Control Plane operation related to distributing the default route from IGWs to IMRs. The AWS VPC Control Plane part in this post is based on my assumptions, so be critical of what you read. The second part of this post shortly explains the Control-Plane operation of the Internet connection used in LISP based network. By comparing the AWS VPC to LISP based network I just want to point out that even though some might think that cloud-based networking is much simple than traditional on-premise networking, it is not. People tend to trust network solutions used in clouds (AWS, Azure, etc.) and there is no debate about (a) what hardware is used, (b) how the redundancy works, (c),  are solutions standard-based and so on. Now it is more like, I do not care how it works as long as it works. Good or bad, I do not know.

Intra-Subnet Communication: AWS VPC versus LISP Based Campus Fabric

Forewords

This article introduces the principles of the Amazon Web Service Virtual Private Cloud (AWS VPC) Control-Plane operation and Data-Plane encapsulation. Also, this document explains how the same kind of forwarding model can be achieved using standard protocols. Amazon has not published details of its VPC networking solution, and this document relies on publically available information and the author’s studies. The motivation for writing this document was that I wanted to point out that no matter how simple and easy to manage Cloud Networking looks and feels like, those still are as complex as any other large scale networks.

Example Environment

Figure 1-1 illustrates an example AWS VPC environment running on an imaginary application on two Elastic Cloud Computing (EC2) Instances, EC2-A and EC2-B. The instance EC2-A will be launched in physical server Host-A while the instance EC2-B will later be launched in physical server Host-B. The VPC vpc-1a2b3c4d is created in Stockholm (eu-north-1) Region in Availability Zone (AZ) eu-north-1c. The subnet 172.16.31.0/20 can be used in AZ eu-north-1c. The subnet for instances is 172.31.10.0/24. Elastic Network Interface-1 (ENI1) with IP address 172.31.10.10 will be attached to the instance EC2-A and ENI2 with IP address 172.31.10.20 will be attached to the instance EC2-B. For simplicity, the same Security Group (SG) “sg-nwktimes”, allowing all data traffic between EC2-A and EC2-B) is attached to both instances.

Inside both physical servers, there is a software router, Router-1 in Host-A and Router-2 in Host-B. Servers use offload NICs for connection to AZ Underlay Network and data traffic from instances is sent out of the server straight to offload NIC bypassing the hypervisor. The AZ Backbone includes three routers, Router-3, Router-4, and Router-5. Also, there is a Mapping Service that represents the centralized Control Plane. It holds an  Instance-to-Location Mapping Database that has information about every EC2 Instances running on a given VPC. Routers, servers and Mapping Service use IPv6 addressing.

Figure 1-1: Overall example topology and IP addressing scheme.

Similarities Between AWS VPC and Cisco SDA – Intra-Subnet Communication

Update March 6, 2020: This post will be obsolete soon by a new  version

Forewords

This article explains the similarities between a LISP/VXLAN based Campus Fabric and AWS Virtual Private Cloud (VPC) from the Intra-Subnet Control-Plane and Data-Plane operation perspective. The AWS VPC solution details are not publicly available and the information included in this article is based on the author's own study using publically available AWS VPC documentation. 

There are two main reasons for writing this document: 

First, Cisco SDA is an on-prem LAN model while the AWS VPC is an off-prem DC solution. I wanted to point out that these two solutions, even though used for very different purposes, use the same kind of Control-Plane operation and Data-Plane encapsulation and are managed via QUI. This is kind of my answer to ever going discussion about is there DC-networks, Campus-networks and so on, or is there just networks.

Second, my own curiosity to understand the operation of AWS VPC.

I usually start by introducing the example environment and then explaining the configuration, moving to Control-Plane operation and then to Data-Plane operation. However, this time I take a different approach. This article first introduces the example environment but then the Data-Plane operation is discussed before Control-Plane operation. This way it is easier to understand what information is needed and how that information is gathered.