IP reachability
Every Overlay Network solution requires IP
reachability between edge devices via Underlay Network. This section explains
the basic routing solution in Underlay Network from Campus Fabric, SD-WAN, and
Datacenter Fabric perspectives. Figure 7-1 illustrates the IP reachability
requirements for Campus Fabric, SD-WAN, and Datacenter Fabric.
Figure 7-1: IP Reachability Requirements.
Campus Fabric
LISP Control-Plane uses Remote Locator (RLOC) IP address in LISP Map-Registers message as a destination address when it registers its local hosts to Mapping Server. Edge devices use RLOC addresses as the destination IP address in the outer IP header for VXLAN encapsulated data packets. Core routers route tunneled data packets based on it. These are the reasons why RLOC addresses have to be routable in Underlay Network. When an edge device sends data packets from one of its locally connected hosts to a remote host behind another edge device, it does recursive routing lookup for the destination RLOC address to find out the real next-hop. Also, the Mapping Server has to have IP reachability between all edge devices.
Datacenter Fabric
Leaf switches use the IP address of the Network
Virtual Edge (NVE) interface as BGP next-hop in EVPN NLRI update. Other Leaf
switches use it as a destination IP address in the outer IP header for VXLAN
encapsulated data packets, just like edge devices in Campus Fabric use RLOC IP
address. That is why NVE interface IP addresses have to be routable in Underlay
Network. In addition, IP addresses which Leaf and Spine are using for iBGP
peering, as well as IP addresses assigned to Multicast-RP, have to be routable.
SD-WAN
Devices in Campus and Datacenter fabrics belong to the
trusted network, and that is why the Underlay Network routing architecture is
quite simple. Also, we don’t have to use data encryption on LAN or DC. That is
not the case with SD-WAN. Public Internet and mobile networks are pretty far
from the secure network, while MPLS VPN/private APNs are secure but
routing/label switching are administrated by third parties. That does not
affect the IP reachability requirements. Devices connected to the same
transport network have to have an IP connection between themselves. SD-WAN edge
devices don’t use their System-Id in Data-Plane, which is why it is not
routable in Underlay Network. Edge devices identify themselves with their
System-Id in OMP TLOC (Transport Locator) route advertisement, which they send
over each Transport Network. The TLOC describes the device location, just like
RLOC and NVE. However, it also defines the color (Transport Network),
Data-Plane encapsulation (IPSec/GRE), and Public-IP address (Transport Network
uplink IP). Edge devices publish customer networks using OMP Service route advertisements.
These updates describe that the next-hop is System-Id X and it is reachable via
Transport Network Y. Remote edge device then checks the Public-IP address for
Y/X combination from TLOC table. Besides, vSmart has to have IP reachability
with all edge devices and other Control-Plane components.
Overlay Network
Edge devices build an Overlay Network between
themselves. This simply means that sending device encapsulates the original
data with the IP address that the remote device uses for network
virtualization.
Figure 7-2: Virtual Network Tunneling.
Campus Fabric
Edge-xTRs in the LISP domain use their RLOC IP
addresses as a source and destination in the outer IP header. Core devises
route encapsulated data based on the destination IP address in the tunnel
header. Campus Fabric uses VXLAN tunneling where the Virtual Network Identifier
(VNI) is LISP Instance-Id. Edge-xTR devices use flow-based load-balancing for
data packets over equal costs core uplinks.
Datacenter Fabric
VTEP/Leaf switches in the BGP EVPN domain use their
NVE interface IP addresses as a source and destination in the outer IP header.
Core devises route encapsulated data based on the destination IP address in the
tunnel header. Datacenter Fabric solution with BGP EVPN Control-Plane also uses
VXLAN tunneling where the L2VNI identifies Layer 2 segments while L3VNI
identifies routing domain (VRF/Tenant). VTEP/Leaf switches use flow-based
load-balancing for data packets over equal-cost core uplinks.
SD-WAN
Edge devices build IPSec/GRE tunnels for data packets
between their Transport Network uplink IP addresses. Edge devices can establish
tunnels with other edge devices which are directly connected to the same
Transport Network. Besides, edge devices can build tunnels over different
Transport Networks if there is an IP connection and the tunneling policy allows
it (restrict bit not set in TLOC updates). Edge devises exchange routing
updates with vSmart over DTLS tunnel. All three solutions use the same
Control-Plane peering model. Edge-xTR registers and requests EID-to-RLOC
mapping information to and from Mapping Server. Leaf switches exchange BGP EVPN
updates with Spine switches. SD-WAN edge devices exchange routing information
with vSmart.
Final words
Networks virtualization, no matter which solution we
are using, tends to be quite complex. However, they all serve the same need,
getting data securely and resilient from point A to B. How this goal is
achieved varies between solutions. LISP uses quite a simple EID-to-RLOC mapping
system to describe endpoint/prefix reachability information. BGP EVPN has its
route types for hosts, prefixes, L2 Multicast, L3 Tenant routed Multicast, ESI
Multi-homing, and Ingress/headend replication. OMP, in turn, uses TLOC and
Service routes. Each solution uses some tunneling solution where virtual
networks are identified in a solution-specific way. LISP uses Instance-Id, BGP
EVPN uses L2VNI/L3VNI, and OMP uses VPN/Label binding. Connecting different
solutions might feel like a nightmare but in the end, it is not so complex. I
have used good old BGP IPv4 Unicast with VRF Lite solution throughout this
book.
Cheers - Toni Pasanen
In
case you want to learn more about LISP, OMP, BGP EVPN, or ACI...
These books are available at Leanpub.com (pdf) and Amazon (Kindle, paperback). You can find them by adding my name into the search field.
Very good presentation, congratulations!
ReplyDeleteGreetings from Argentina.
Ciro Gustavo Mele.
Thank you Ciro.
Delete