Cisco LISP - Could be an end of BGP at Enterprises !!!


Since morning I was think about the working of LISP and how it can impact the requirement of BGP in enterprise segment, where BGP is used purely for multihoming. With all thanks to Cisco's documentation I am able to find an answer for it. 

 

And the answer is - "YES"

LISP can perform much better than BGP when used for Multihoming, Disaster Recovery and Mobility. Lets have a look how LISP packet goes around in the WAN cloud -

When a host in a LISP-capable domain wants to send a packet, it first looks up the correspondent host's EID in the DNS. It then puts its EID in the packet source address, and EID of the correspondent host in its destination address; if the destination of the packet is in another domain, the packet traverses the source domain infrastructure to one of the domain ITRs. If the ITR has cached the EID-to-RLOC mapping for the destination EID, it sets the destination RLOC in the outer (encapsulated) header to the cached RLOC, and the source RLOC to its RLOC (note that the inner header has the source host's EID as the source and the destination's EID in the Destination field). The packet is then sent over the Internet to the ETR indicated in the destination RLOC, which decapsulates the packet and sends it on to the destination EID. If, on the other hand, the ITR does not have a EID-to-RLOC mapping for the destination EID, it encapsulates the packet in a LISP header in which the destination address is the same as the inner header destination address, namely, the EID of the destination host. This packet is a Data Probe packet, and is routed over the LISP-ALT topology to the LISP-ALT router (typically an ETR, but this type of router is not required) that is authoritative for the EID-to-RLOC mapping. When the ETR receives the Data Probe packet, it decapsulates the packet and sends it on to the destination EID and sends a Map Reply to the source ITR so subsequent packets are sent natively over the Internet (as opposed to over the LISP-ALT overlay network). This query/response transaction is required only for the first packet sent between sites; all subsequent packets are sent LISP-encapsulated directly between the ITR and the ETR (and in particular, not over the LISP-ALT topology). Finally, note that the ITR could also preload its cache with mappings for popular destinations using the Map-Request message, avoiding the Data Probe packet (and associated latency, if any) altogether.

For example, consider the scenario depicted in Figure below. In this case, a source S with EID 1.0.0.1 wants to send a packet to destination D whose EID is 2.0.0.2. The packet arrives at ITR S2, which does not have an EID-to-RLOC mapping for 2.0.0.2. S2 LISP-encapsulates the packet with the outer header having its RLOC (11.0.0.1) as the source address, copies the destination EID (2.0.0.2) from the inner header to the outer-header destination, and sends the data packet (a Data Probe) into the LISP-ALT topology. The packet follows the paths computed by BGP in the LISP-ALT topology to ETR D2. When D2 receives the packet, it decapsulates it and forwards the packet to the destination 2.0.0.2; D2 also responds with a Map-Reply message that tells S2 (11.0.0.1) that the EID-to-RLOC mapping for 2.0.0.0/8 has two elements, ETR D1 (whose RLOC is 12.0.0.2) and ETR D2 (whose RLOC is 13.0.0.2). After receiving the Map Reply, ITR S2 can send LISP-encapsulated packets natively over the Internet (that is, not over the ALT topology).

Figure 3: A Day in the Life of a LISP Packet
Note that the mapping has priority (p) and weight (w) attributes. Priorities tell the ITR which ETRs to use in which order, and weights tell the ITR how to split load across ETRs of a given priority (w is a percentage of traffic that should go to each ETR). In this case, both ETRs have the same priority (1), and have weight 50 (that is, each ETR should receive 50 percent of the traffic).

So, what are the benefits when using LISP ?

Okie...
  

Apart from that configuring & managing a BGP network is always complex and also requires high end devices to operate on, LISP would bring down the TCO for the enterprises.

Want to know more about LISP - Read This
Cisco Nexus Overlay Transport Virtualization - Read This  
Cisco Nexus FabricPath - Click Here
Cisco Nexus Fibre Channel over Ethernet - Read This

Labels: , , , , , , ,