NJEDge.Net LISP Architecture

Jim Stankiewiczstank@njedge.net

Michael Kowalmikowal@cisco.com

IP addressing overloads location and identity – leading to Internet scaling issues

Why current IP semantics cause scaling issues?− Overloaded IP address semantic makes efficient

routing impossible

− Today, “addressing follows topology,” which limits route aggregation compactness

− IPv6 does not fix this

Why are route scaling issues bad?− Routers require expensive memory to hold

Internet Routing Table in forwarding plane

− It’s expensive for network builders/operators

− Replacing equipment for the wrong reason (to hold the routing table); replacement should be to implement new features

“… routing scalability is the most important problem facing the Internet today and must be solved … ”

Internet Architecture Board (IAB)October 2006 Workshop (written as RFC 4984)

LISP Overview

LISP creates a Level of indirection with two namespaces: EID and RLOC

EID (Endpoint Identifier) is the IP address of a host – just as it is today

RLOC (Routing Locator) is the IP address of the LISP router for the host

EID-to-RLOC mapping is the distributed architecture that maps EIDs to RLOCs

Analogous to a DNS Lookup

Network-based solution No host changes Minimal configuration Incrementally deployable

Support for mobility Address Family agnostic Uses Pull vs. Push Routing Open Standard

Prefix Next-hopw.x.y.1 e.f.g.hx.y.w.2 e.f.g.hz.q.r.5 e.f.g.hz.q.r.5 e.f.g.h

Non-LISP

RLOC Space

EID-to-RLOC

mapping

xTR

EID SpacexTR

EID RLOCa.a.a.0/24 w.x.y.1 b.b.b.0/24 x.y.w.2 c.c.c.0/24 z.q.r.5 d.d.0.0/16 z.q.r.5

MS/MR

PxTR

xTR

EID RLOCa.a.a.0/24 w.x.y.1 b.b.b.0/24 x.y.w.2 c.c.c.0/24 z.q.r.5 d.d.0.0/16 z.q.r.5

EID RLOCa.a.a.0/24 w.x.y.1 b.b.b.0/24 x.y.w.2 c.c.c.0/24 z.q.r.5 d.d.0.0/16 z.q.r.5

EID Space

LISP Overview

NJEDge.Net Overview

NJ’s Research and Education Network Since 2000

NJEDge.Net LISP Deployment

• LISP Briefing (June 2011)• CPOC (Aug 2011)• Deploy and Test LISP in Production

Environment• First LISP-Production Member (December

2011)

NJEdge LISP Architecture

v4/v6 Core

I2

Internet

Internet

Internet

Internet

Member

MS/MR/PxTR

PHL

NWKMS/MR/PxTR

Internet

Transition #1

Member peered with NJEDge and Provider X via BGP

Tuning BGP to properly balance Ingress Traffic Flows was Challenging Member owned 16

x /24s

Member

Internet

NJEDgeProvider X

Transition #1 Configure Member for

LISP Remove BGP Add Two Default

routes Proxy Router attracts

Ingress Traffic destined to Member and load balances towards the member.

Member

NJEDgeProvider X

xTR

PxTR

Announce Member

Address via BGPInterne

t

Benefits:• No BGP Configuration to Manage• Guaranteed Ingress Traffic Load Balancing

Transition #2

Local, Non-Member Member peers with Provider X & Y via BGP

Tuning BGP to properly balance Ingress Traffic Flows was Challenging Non-Member

Provider X Provider Y

Internet

NJEDge

Transition #2 Configure Member for

LISP; remove BGP and add two Default routes (one per provider)

Proxy Router attracts Ingress Traffic destined to Member and load balances across both of the Member’s Router interfaces. Non-Member

Provider X Provider Y

Internet

NJEDge

xTR

PxTR

Announce Member

Address via BGP

Transition #3 Post-Transition,

Member had budget to upgrade elderly Edge Router

Since LISP only “pulls” routing information, smaller memory requirements allow for inexpensive future router purchase.

Member

Internet

NJEDgeProvider X

xTR

PxTR

Map Resolution

Transition #3

Savings: ~$11K

Original Budget: $28K (estimated)

Alternative: $17K

(estimated)Assume

Hardware Life: 5-7

years

Next Steps

• Waitlist of 12 Members to be transitioned• Use LISP VM-Mobility to solve Disaster

Recovery initiatives.

LISP VM-Mobility

IP Network

WestDC

LISP Site

Legacy Site

Legacy Site

Legacy Site

East DC

PxTR

MappingDB

Data Center 1

Data Center 2

a.b.c.1VM

a.b.c.1VM

VM move

LISProuters

LISProuters

Internet

Multi-Tenant Compute

Multi-Tenant Network

LISP Updates VM-Move Across Subnets