Transcript 20120423-StankiewiczKowal-NJEdgeLISPx

NJEDge.Net LISP Architecture
Jim Stankiewicz
[email protected]
Michael Kowal
[email protected]
LISP Overview
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 creates a Level of indirection with two namespaces: EID and RLOC
EID
 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
MS/MR
w.x.y.1
x.y.w.2
z.q.r.5
z.q.r.5
EID
EID Space
Non-LISP
e.f.g.h
e.f.g.h
e.f.g.h
e.f.g.h
PxTR
 Analogous to a DNS Lookup
 Network-based solution  Support for mobility
 No host changes
 Address Family agnostic
 Minimal configuration
 Uses Pull vs. Push Routing
RLOC Space
xTR
w.x.y.1
x.y.w.2
z.q.r.5
z.q.r.5
EID-toRLOC
mapping
Prefix Next-hop
xTR
w.x.y.1
x.y.w.2
z.q.r.5
z.q.r.5
RLOC
a.a.a.0/24
b.b.b.0/24
c.c.c.0/24
d.d.0.0/16
xTR
w.x.y.1
x.y.w.2
z.q.r.5
z.q.r.5
RLOC
a.a.a.0/24
b.b.b.0/24
c.c.c.0/24
d.d.0.0/16
EID
 EID-to-RLOC mapping is the
distributed architecture that maps
EIDs to RLOCs
 Incrementally deployable  Open Standard
RLOC
a.a.a.0/24
b.b.b.0/24
c.c.c.0/24
d.d.0.0/16
EID Space
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
Internet
Internet
I2
Internet
Internet
Internet
v4/v6 Core
MS/MR/PxTR
PHL
Member
MS/MR/PxTR
NWK
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
Internet
NJEDge
Provider X
Member
Transition #1
 Configure Member for
LISP
Internet
 Remove BGP
 Add Two Default
routes
 Proxy Router attracts
Ingress Traffic destined
to Member and load
balances towards the
member.
PxTR
Provider X
Benefits:
• No BGP Configuration to Manage
• Guaranteed Ingress Traffic Load Balancing
Announce
Member
Address via
BGP
NJEDge
xTR
Member
Transition #2
 Local, NonMember Member
peers with
Provider X & Y via
BGP
 Tuning BGP to
properly balance
Ingress Traffic
Flows was
Challenging
NJEDge
Internet
Provider X
Provider Y
Non-Member
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.
Announce
Member
Address via
BGP
NJEDge
PxTR
Internet
Provider X
Provider Y
xTR
Non-Member
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.
Internet
NJEDge
Provider X
PxTR
xTR
Member
Map
Resolution
Transition #3
Alternative:
$17K
(estimated)
Original
Budget: $28K
(estimated)
Assume
Hardware
Life: 5-7 years
Savings:
~$11K
Next Steps
• Waitlist of 12 Members to be transitioned
• Use LISP VM-Mobility to solve Disaster
Recovery initiatives.
LISP VM-Mobility
Legacy
Site
Legacy
Site
Legacy
Site
LISP Site
PxTR
Mapping
DB
IP Network
West
DC
LISP Updates
VM-Move
Across
Subnets
MultiTenant
Network
East
DC
Data
Center 1
MultiTenant
Compute
Data
Center 2
Internet
LISP
routers
LISP
routers
VM move
VM
VM
a.b.c.1
a.b.c.1