Hey guys...
Welcome to another post of Nexus Series. Lets talk about Locator/ID Separation Protocol (LISP) today.
Okie.. So what is LISP ?
Current IP routing and addressing architecture
uses a single numbering space for device identity and location. LISP
routing architecture creates a new paradigm by splitting the device
identity and its location into two different numbering spaces.
but what does this all means ?? Okie
LISP is a new routing feature designed by Cisco (but its an open standard protocol, Cisco has no IP on it... Cisco had made a smart move to outrule Juniper from internet ;-) ). This protocol is intended to help enterprises counter internet routing scalablity issues along with easy multihoming, workforce mobility & very very easy and non disruptive transition from one ISP to another or one address space to another.
Wow.. sounds like a magic !!! but how does it do all this stuff.
Alrite here is the answer for it..
LISP creates a new paradigm in how IP addressing is
assigned and interpreted by splitting the device identity, known as an
endpoint identifier (EID), and its location, known as its routing
locator (RLOC), into two different namespaces. Creating separate IP
addresses for EID and RLOC
So, apart from your adresses on the internet LISP creates its own addresses for endpoint devices (CE) and RLOC (PE) and same are used to route your traffic on WAN cloud.
when deploying LISP we just need to care about two areas -
1. LISP Sites
2. LISP Infrastructure
So, What all come under these jargons.. Okie
LISP site devices:
– ITR:
An Ingress Tunnel Router receives packets from site-facing interfaces
and either LISP-encapsulates packets to remote LISP sites, or natively
forwards packets to non-LISP sites. An ITR also sends map requests and
processes received map replies in order to resolve EID-to-RLOC mappings.
– ETR:
An Egress Tunnel Router receives packets from core-facing interfaces,
de-encapsulates them, and delivers them to local EIDs at the site. An
ETR also registers its EID prefixes and RLOCs with the Map-Server, and
responds to map requests received from the Map-Server.
In
most cases, a LISP site edge device will implement both ITR and ETR
functions, in which case it is commonly referred to as an xTR.
• LISP infrastructure devices:
– MS:
A Map-Server advertises EID prefixes into the LISP-Alternative Topology
(ALT) for ETRs that are registered to it. The MS also receives map
requests over the ALT from ITRs seeking mapping resolutions for EID
prefixes and forwards them to the registered ETR that is authoritative
for the EID prefix being queried.
– MR:
A Map-Resolver receives map requests from ITRs and forwards map
requests to the ALT. The MR also sends negative map replies to ITRs in
response to queries for non-LISP addresses.
– ALT:
An Alternative Topology device is deployed to build out an overlay
network that provides a mechanism for managing EID prefix aggregation.
Other LISP infrastructure devices (MS, MR, PITR, PETR) connect to the
ALT to participate in EID-to-RLOC mapping services:
– PITR:
A Proxy ITR provides connectivity between non-LISP sites and LISP sites
by advertising coarse-aggregate prefixes for the LISP EID namespace
into the Internet DFZ (RLOC namespace) and forwarding this non-LISP
traffic to LISP sites.
– PETR:
A Proxy ETR allows IPv6 LISP sites without native IPv6 RLOC
connectivity to reach LISP sites that only have IPv6 RLOC connectivity.
In addition, the PETR also allows LISP sites with Unicast Reverse Path
Forwarding (URPF) restrictions to reach non-LISP sites.
Okie.. now its time to talk about LISP benefits in brief -
- Workload mobility - Move virtual machines and physical hosts across Layer 3 boundaries and preserve their IP addresses
- Cloud computing - Migrate or burst workloads from data center to or across service providers without changing IP addresses
- Rapid disaster recovery - Eliminate DNS
entries and routing changes when migrating workloads to a disaster
recovery location by maintaining constant IP addressing
- Scalable multitenancy - Eliminate route-table scaling issues by populating only required routes on demand
- IPv6 transition - Incrementally deploy IPv6 over existing IPv4 infrastructure, for simpler phased transition to IPv6
So, LISP tomorrow would stand out as an end of eBGP in enterprise segment. We will contnue discussion on this in my next post - We will see enterprise BGP dying !!!
and guess what I havent failed to find an interesting LISP video for you guys -
For those who missed earlier post in the Nexus Series -
Cisco Nexus Overlay Transport Virtualization - Read This
Cisco Nexus Fibre Channel over Ethernet - Read This