NJEDge.Net LISP Architecture Jim Stankiewicz stank@njedge.net Michael Kowal mikowal@cisco.com 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