Azure and LISP For Public IP Mobility

Introduction

The Locator Identity Separation Protocol (LISP) is a routing architecture that creates a paradigm by splitting the device identity, known as an Endpoint Identifier (EID), and its location, known as its Routing Locator (RLOC), into two different numbering spaces. This capability brings renewed scale and flexibility to the network in a single protocol, enabling the areas of mobility, scalability, and security. For enterprises moving to Azure, LISP provides key benefits such as IP Mobility for Public IP Address Portability, Split Subnets during Data Center Migration, Geographic Dispersion of Data Centers and Disaster Recovery. This document focuses on LISP use cases addressing today’s enterprise data center use-cases moving customer-owned public IP space to Azure. Workload virtualization requires location independence for server resources and requires the flexibility to move these public IP resources from one data center to another to meet burst capacity, lift and shift to Azure, and to support disaster recovery. This brings the challenge of route optimization when the public IPs need to move location without giving up ownership of the space for maintaining control. It also provides the customer the flexibility to move a public subnet or individual public IPs regardless of the cloud provider or enterprise DC location. The LISP IP-Mobility solution addresses this issue seamlessly by enabling IP end-points to change location while keeping their assigned IP addresses and not require Azure to advertise your public IP space. The Public IP addresses may move between different geographic locations or be split between different Azure regions. In either case, the LISP IP-Mobility solution guarantees optimal routing between clients on the Internet and the public IP address that has moved, regardless of its location. Also, LISP IP-Mobility does not require any change in the DNS infrastructure (since the mobile nodes preserve their original IP addressing), which overall reduces operating expenses for the data center administrator.

LISP is a routing architecture, not a feature; it gives IP a full set of capabilities that it does not natively have. LISP enables IP address portability, which can be seen in two ways. First, it allows the mobility of a host or addresses anywhere without changing the host IP address or having to ask Azure to advertise your public subnets. Second, it allows defining an edge host IP address independently from the site IP structure it will reside on. The decoupling of the application definition from the network is critical for cloud flexibility.

IP Mobility Requirements

The goal of IP mobility is to steer traffic to the valid location of the end-point. This aspect is generally addressed by providing some sort of re-direction mechanism to enhance the traffic steering already provided by basic routing. Redirection can be achieved by replacing the destination address with a surrogate address that is representative of the new location of the end-point. For instance, what VNET or Region does my workload currently reside in? A goal of IP mobility is to provide a solution that is totally transparent to the applications and allows for the preservation of established sessions, as end-points move around the IP infrastructure.

Terminology:

In traditional IP, the IP edge routing subnets are advertised all over the network using either an Interior Gateway Protocol (IGP) or an Exterior Gateway Protocol (EGP); it is very rare to advertise any host address (subnet mask /32). With LISP, such constraints disappear; LISP splits the host ID (EID) from the RLOC, allowing any host to move from location to location while keeping its unique identity. LISP architecture is composed of several elements, including the following:

Locator/ID Separation Protocol (LISP): A tunnel protocol that uses a central database in which endpoint location is registered. LISP enables an IP host-based mobility of endpoints.

LISP-enabled virtualized router: A virtual machine or appliance that supports routing and LISP functions, including host mobility.

Endpoint ID (EID): IPv4 or IPv6 identifier of the devices connected at the edge of the network. Used in the first (most inner) LISP header of a packet.

Routing locator (RLOC): IPv4 or IPv6 addresses used to encapsulate and transport the flow between LISP nodes. A RLOC is the output of an EID-to-RLOC mapping lookup.

Ingress tunnel router (ITR): A router that has two functions: it resolves the location of an EID by querying the database, and then it performs the encapsulation toward the remote RLOC. Sends requests toward the map resolver. Populates its local map cache with the learned association. Responsible to perform the LISP encapsulation

Egress tunnel router (ETR): A router that has two functions: it registers the endpoint or location associated with the database, and then it decapsulates the LISP packet and forwards it to the right endpoint. It registers the EID address space it is authorized for and It is identified by one (or more) RLOCs

xTR: A generic appellation for a device performing both ITR and ERT functions.

Proxy-ITR (PITR): Acts like an ITR but does so on behalf of non-LISP sites that send packets to destinations at LISP sites.

Proxy-ETR (PETR): Acts like an ETR but does so on behalf of LISP sites that send packets to destinations at non‑LISP sites.

PxTR: The point of interconnection between an IP network and a LISP network, playing the role of ITR and ETR at this peering point.

Map-Server (MS): A MS is a LISP Infrastructure device that LISP site ETRs register to with their EID prefixes. The MS advertises aggregates for the registered EID prefixes into the LISP mapping system. All LISP sites use the LISP mapping system to resolve EID-to-RLOC mappings. This server is the database where all EID and RLOC associations are stored. It can be deployed simply on a pair of devices. Or it can be a hierarchy of devices, organized like a DNS system for massive scale implementation.

Map-Resolver (MR): An MR is a LISP Infrastructure device to which LISP site ITRs send LISP Map-Request queries when resolving EID-to-RLOC mappings. Receives the request and selects the appropriate map server

LISP Use-Cases

Cases

Use-Case	Requirements
Fast Bring-up of Disaster Recovery Facilities	Relocation of IP end-points to Azure without IP address change.
DC Migration	Relocation of IP end-points to Azure without IP address change.
Public IP Portability	Relocation of Public IP Address across organizations

Public IP Portability to Azure

This document is focused on Public IP Portability. The concept of the solution is to use an Azure Availability Set of Cisco CSR 1000V virtual routers within an Azure VNET, and a LISP-enabled router pair (Cisco ASR 1000 Series Aggregation or Cisco CSR 1000V virtual routers) deployed in the enterprise data center with a LISP tunnel in between (encryption is optional). LISP provides the mobility between the two or more sites, allowing you to move your Public IPs to Azure VNETs.

Non-LISP-enabled sites communicate to the public IPs moved to Azure through the enterprise data center, where LISP mapping service is deployed.

The solution proposed in this paper does not require LISP to be enabled globally; it can be deployed by enabling LISP on just the enterprise data center and within Azure, with minimal impact on the operations of both the data center and Azure.

The optional deployment of LISP at individual sites provides data-path optimization because the LISP-encapsulated traffic is routed directly Azure or the data center, depending on the server location. This motion is outside the scope of the document.

The LISP-enabled PITR router deployed within the enterprise data center does not need to be the default gateway for the local servers (physical and virtual machines). The LISP enabled router is deployed “on a stick,” meaning that it does not need to be the default gateway. The PITR purpose is to attract traffic from the Internet for addresses that have moved to an Azure DC.

The LISP CSRs in Azure is deployed with one interface facing the Internet or facing Gateway Subnet and the other interfaces facing the local Azure Subnets.

Routing Considerations

In any case, this solution requires only that each Azure CSR have one unique Azure assigned a public address. One primary objective is to announce to the mapping database within the enterprise. The Mapping Database is used to identify where the public IP subnet or host public IP has moved to. LISP allows a node to keep the same IP address even when its location changes because it keeps its EID while mapping to a new RLOC.

With the Internet, an important consideration is the NAT service. Because IPsec supports NAT, the fact that this solution has an option of using IPsec as a tunnel connection between the enterprise and Azure solves any NAT burden.

Reference Topology

The reference topology has three environments: Connections from the Internet, an enterprise data center, and Azure Regions

The Internet-sourced connections where users connect is PublicIP/24. Router 1 is connected to the Internet alone with no VPN or Private WAN. Router 1 does not run LISP, so the branch office is a non-LISP site. Internet users access public facing servers located either at the enterprise data center or at Azure.

The enterprise data center is connected to the Internet through the data center edge routers (Router A & B). The default gateway for all the servers located in the enterprise data center is at the aggregation layer. The Cisco ASR installed on the enterprise, PITR-1 has at least one interface. The link is used for connectivity towards the Internet to advertise routes that are LISP controlled. The link is also used to transport LISP encapsulated traffic destined to the location of the moved public IP addresses.

PITR-1 is the only device within the enterprise data center running LISP, and it is configured as a LISP PITR. PITR-1 is also optionally configured with an IPsec tunnel toward the Azure CSR. ExpressRoute for connectivity is an option between customer DC and Azure. If using encryption, OSPF is enabled over the GRE/IPsec tunnel to advertise the IP address of the loopback interfaces of PxTR-1 and CSR that are used as the LISP RLOCs if required. Otherwise, a native LISP encapsulation can be used between the enterprise and Azure CSRs.

The (CSR) deployed on Azure has one public IP address, and one or more interfaces facing Azure subnets that have migrated customer public IP space. Public IP Subnets that have been migrated to Azure have a UDR pointing to the CSR for Internet-bound traffic to maintain flow symmetry.

CSR is the only device in the Azure running LISP, and it is configured as a LISP xTR. CSR is optionally configured with an IPsec tunnel toward PxTR-1, and it has OSPF enabled over its GRE/IPsec tunnel to advertise its loopback interface address that is used as its RLOC if required. In the topology, the subnets 153.16.9.192/28 and 153.16.9.210/28 have been moved to Azure regions.

Implementation Details within Azure

Within Azure, the LISP-enabled Cisco CSR 1000V (xTR) is in a secondary subnet with a UDR pointing to it for Internet-bound traffic. The Azure CSR is configured as a LISP ITR and ETR node so that it can perform LISP encapsulation and de-encapsulation of the packets going to the migrated public IPs within Azure. Optionally, for traffic leaving Azure, whenever a route to the destination is not found on the CSR routing table, CSR can route that traffic through PxTR-1 at the enterprise data center. This function, known as use-petr, is useful to ensure that the traffic flow is symmetric between non-LISP-enabled sites and Azure, and it must be used when firewalls or other stateful devices are located at the enterprise data center.

Azure-Based Cisco CSR Configuration

Enterprise-based Cisco ASR

*The configuration of the LISP Mapping Server, Resolver and PITR is outside the scope of this document.*

Packet Walk and Encapsulation Stack

This section explains the detailed communication flows referring to the diagram shown in Figure above earlier in this document. PxTR-1, at the enterprise data center, is placed on a stick. PxTR-1 is advertising the customer Public IP Prefixes towards the Internet that have been migrated to Azure. PxTR-1 can be either a physical router (Cisco ASR 1000), or a virtual router (Cisco CSR 1000V). PxTR-1 is enabled as a LISP PiTR so you can manage both locally sourced traffic and traffic coming from the Internet. PxTR-1 is also set up as a LISP PeTR so you can receive traffic back from Azure and deliver it to the Internet. At Azure, the CsR (xTR) is a standard LISP xTR for the locally attached migrated public IP subnets. Azure CSR xTR plays the role of eTR for the flow coming from the Internet (via LISP Encap from Enterprise site), and acts as an iTR for the flow going back to the Internet. For any destination that is not known by the xTR, the iTR encapsulates the traffic to the RLOC of the PeTR specified, in this case the PxTR-1 deployed at the enterprise site.

Communication from the Internet to Migrated Public IPs.

Traffic from user PCs, which are located on the Internet is not LISP-enabled. Flows destined for migrated IP addresses are naturally attracted toward the enterprise data center by IP routing. When it reaches the enterprise site, it crosses the site's security perimeter and other services to reach the PITR. The PITR will check with the Mapping Server on where the requested IP is located. Based on the response, the PITR will LISP encapsulate to Azure, where it is delivered to CSR (xTR), which is the LISP gateway for that region and deliver the request to the migrated IP address. The return path is intended for the Internet, (that is, it is targeted to a user PC), Azure CSR sends the traffic to the PeTR configured on it (PxTR-1) to maintain symmetry.