Showing posts with label OMP. Show all posts
Showing posts with label OMP. Show all posts

Sunday, 8 August 2021

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.

 

Friday, 6 August 2021

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

Wednesday, 28 July 2021

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.

Friday, 9 April 2021

Cisco SD-WAN - Part III: Overlay Management Protocol

 

Introduction

 

This chapter introduces the operation of the Overlay Management Protocol (OMP). It starts by introducing TLOC Routes which are used for establishing tunnels between vEdges. Next, it explains OMP Routes which in turn are used for advertising client VPN-specific networks reachability information. I am also going to show the data plane encapsulation when data is sent between the hosts in site 10 and site 30. The purpose of the data plane section is to show how the label attribute advertised within OMP routing advertisements is used to identify customer VPN. In order to see inside captured packets, I am using GRE tunnels instead of IPSec. Figure 3-1 illustrates the example topology used in this chapter. The customer VPN 10 is used on both sites. Site 10 subnet is 172.16.10.0/24 and site 30 subnet is 172.16.30.0/24. Interface ge0/­0 in both vEdges is connected to the Public-Internet, and interface ge0/1 is the connected to MPLS transport network where the customer has its dedicated MPLS VPN.



Figure 3-1: SD-WAN Example Topology.