10 fn tut3

LISP - A Next Generation Networking Architecture

© 2010 Cisco Systems, Inc. All rights reserved. Cisco PublicBRKCRS-3045 2

Session Objectives

At the end of this session, you should be able to:

– Understand the scalability issues facing the Internet today

– Describe how LISP helps solve key scaling issues, and enable interesting new functionalities

– Describe the LISP data plane and control plane mechanisms

– Understand the basic LISP configuration requirements

– Understand Cisco‟s contributions and plans for LISP


Agenda

LISP Overview

LISP Operations

LISP Example

LISP Use Cases

LISP Initiatives

LISP Summary

Additional Material

© 2010 Cisco and/or its affiliates. All rights reserved. Cisco PublicPresentation_ID 4

LISP Overview


LISP originally conceived to address Internet Scaling

What causes scaling issues?

− IP addresses denote both location and identity today

− Overloaded IP address semantic makes efficient routing impossible

− IPv6 does not fix this

Why are scaling issues bad?

− Routers require tons of expensive memory to hold the Internet Routing Table in the forwarding plane of a router

− It‟s expensive for network builders/operators

− Replacing equipment for the wrong reason (to hold the routing table rather than implementing new features…)

− It‟s not environmentally GREEN

“… 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 OverviewWhy was LISP developed?


Provider G

Provider DProvider Z

Provider WProvider H

Provider Assigned

(PA)

10.1.1.0/24

15.0.0.0/8 15.0.0.0/810.1.1.0/24

R1

LISP OverviewWhat Pollutes the Internet Today?

R2

10.1.1.0/24

Provider Independent

(PI)

15.0.0.0/8

R1 R2

Provider Y

13.0.0.0/8

Provider X

12.0.0.0/8Provider A

10.0.0.0/8Provider B

11.0.0.0/8

15/8Provider C

10/815/8

10.1.1.0/24

Internet

• Addresses at sites, both PA and PI,

can get de-aggregated by multi-homing

10.1.1.0/24

10/8

BeforeLoc/ID Split


Provider G



Provider Assigned

(PA)

10.1.1.0/24

15.0.0.0/8 15.0.0.0/810.1.1.0/24

R1

LISP OverviewWhat Pollutes the Internet Today?

R2

10.1.1.0/24


(PI)

15.0.0.0/8

R1 R2

Provider Y

13.0.0.0/8

Provider X



11.0.0.0/8

Provider C

10.1.1.0/24

Internet



• Aggregates for infrastructure addresses

(e.g. CE-PE links) get advertised as well

12.4.4.1/3013.3.3.5/3011.2.1.17/3010.9.1.45/30

13/8 12/811/8

15/815/8

10.1.1.0/24

10/810/8

BeforeLoc/ID Split


Locator/Identity Split creates a “Level of Indirection” by using two

namespaces – hosts and locators

This level of indirection allows you to remove host prefixes from

the underlying core (Internet) routing system and move them in

another system (database):

Think “DNS” here: DNS is a Name-to-IP Address lookup…

LISP involves an host-to-locator lookup…

Isn‟t this just a case of “moving the problem”?

Fast memory used in the “forwarding plane” of routers is very expensive (and

consumers a lot of power)

Server Memory is very cheap

Moves problem from the “forwarding plane” to the “off-line control plane” where

significantly greater scale at much lower cost can be achieved

LISP OverviewWhy does LISP solve this problem?


Provider G



Provider Assigned

(PA)

10.1.1.0/24

15.0.0.0/8 15.0.0.0/810.1.1.0/24

R1

LISP OverviewWhy does Locator/ID Separation solve this problem?

R2

10.1.1.0/24


(PI)

15.0.0.0/8

R1 R2

Provider Y

13.0.0.0/8

Provider X



11.0.0.0/8

Provider C

10.1.1.0/24

Internet





12.4.4.1/3013.3.3.5/3011.2.1.17/3010.9.1.45/30

13/8 12/811/8

15/815/8

10.1.1.0/24

10/810/8

BeforeLoc/ID Split

Some-Core-Rtr# show ip route bgp

---<skip>---

10.0.0.0/8 is variably subnetted, 98 subnets, 6 masks

B 10.0.0.0/8 [20/0] via 128.223.3.9, 3d19h

B 10.1.1.0/24 [20/0] via 128.223.3.9, 3d19h

B 11.0.0.0/8 [20/0] via 128.223.3.9, 1d17h

---<skip>---


B 12.1.0.0/16 [20/0] via 128.223.3.9, 3d19h

B 12.4.4.0/22 [20/0] via 128.223.3.9, 3d19h

---<skip>---


B 13.0.0.0/8 [20/0] via 128.223.3.9, 14:00:10

B 13.0.0.0/10 [20/0] via 128.223.3.9, 5d23h

---<skip>---

B 15.0.0.0/8 [20/0] via 128.223.3.9, 1d17h

---<skip>---

many many more......

Some-Core-Rtr#


Provider G



Provider Assigned

(PA)

10.1.1.0/24

15.0.0.0/8 15.0.0.0/810.1.1.0/24

R1

LISP OverviewWhy does Locator/ID Separation solve this problem?

R2

10.1.1.0/24


(PI)

15.0.0.0/8

R1 R2

Provider Y

13.0.0.0/8

Provider X



11.0.0.0/8

Provider C

10.1.1.0/24

Internet





12.4.4.1/3013.3.3.5/3011.2.1.17/3010.9.1.45/30

13/8 12/811/8

15/815/8

10.1.1.0/24

10/810/8

AfterLoc/ID Split


---<skip>---


B 10.0.0.0/8 [20/0] via 128.223.3.9, 3d19h

B 10.1.1.0/24 [20/0] via 128.223.3.9, 3d19h

B 11.0.0.0/8 [20/0] via 128.223.3.9, 1d17h

---<skip>---


B 12.1.0.0/16 [20/0] via 128.223.3.9, 3d19h

B 12.4.4.0/22 [20/0] via 128.223.3.9, 3d19h

---<skip>---


B 13.0.0.0/8 [20/0] via 128.223.3.9, 14:00:10

B 13.0.0.0/10 [20/0] via 128.223.3.9, 5d23h

---<skip>---

B 15.0.0.0/8 [20/0] via 128.223.3.9, 1d17h

---<skip>---

many many more......

Some-Core-Rtr#

New “EID” Namespace

B 15.0.0.0/8 [20/0] via 128.223.3.9, 1d17h

B 10.1.1.0/24 [20/0] via 128.223.3.9, 3d19h

B 15.0.0.0/8 [20/0] via 128.223.3.9, 1d17h

B 10.1.1.0/24 [20/0] via 128.223.3.9, 3d19h


---<skip>---


B 10.0.0.0/8 [20/0] via 128.223.3.9, 3d19h

B 11.0.0.0/8 [20/0] via 128.223.3.9, 1d17h

---<skip>---


B 12.1.0.0/16 [20/0] via 128.223.3.9, 3d19h

B 12.4.4.0/22 [20/0] via 128.223.3.9, 3d19h

---<skip>---


B 13.0.0.0/8 [20/0] via 128.223.3.9, 14:00:10

B 13.0.0.0/10 [20/0] via 128.223.3.9, 5d23h

---<skip>---

Some-Core-Rtr#


LISP OverviewProtocol Ground Rules and Attributes

LISP “Ground Rules”

Network-based solution

No host changes

No new addressing to site devices; minimal configuration changes

Incrementally deployable; interoperable with existing Internet

LISP “Attributes”

Designed for router encapsulation

Designed for Locator Reachability

Support Unicast and Multicast Data

Support for IPv4 IPv6 EIDs (hosts) and RLOCs (locators)

Various Loc/ID split schemes have been studied for >15 years but no

one implemented or tested any of them…

Cisco decided to put some effort into this and undertook the process

of writing code and developing standards to test concepts.

The result is: LISP – the “Locator/ID Separation Protocol”


LISP OverviewLISP Header Format

Outer Header:

Router supplies

RLOCs

draft-ietf-lisp-07

Inner Header:

Host supplies

EIDs

LISP

header

UDP


peer-to-peer communications

peer-to-peer communicationssource

host

destination

host

Internet

7. Application

5. Session

6. Presentation

4. Transport

2. Data Link

1. Physical

3. Network (host)

En-cap

packets

7. Application

5. Session

6. Presentation

4. Transport

2. Data Link

1. Physical

3. Network (host)

2. Data Link

3. Network (LISP)

1. Physical

3. Network (host)

(LISP UDP)

De-cap

packets

2. Data Link

3. Network (LISP)

1. Physical

3. Network (host)

(LISP UDP)

LISP

ITR

LISP

ETR

LISP OverviewLISP Data Plane Concepts

Network-based “Map and Encap” approach

Requires the fewest changes to existing systems – only the CPE

No changes in hosts, DNS, or Core infrastructure

New Mapping Service required for EID-to-RLOC mapping resolution

2. Data Link

3. Network (LISP)

1. Physical

3. Network (host)

(LISP UDP)


Like all other encapsulation or tunneling protocols, LISP adds to the packet length, resulting in potential fragmentation issues

Three methods are accounted for in the specification

1. “Don‟t Care” – Avoid fragmentation, don‟t do PMTUD, and assume Core MTU is always greater than access MTU

2. Stateless – ITR fragments, then encapsulates; destination host reassembles

3. Stateful – Avoid fragmentation; run PMTUD between ITR and ETR

Experience shows which mechanisms are necessary

Years of experience with IPSec and GRE can inform decisions and approaches for LISP deployment

LISP OverviewMTU Issues?


See additional details about MTU in the “Additional Material” section at the end of this presentation

LISP OverviewLISP and MTU…


LISP OverviewNow that we have LISP, what else can we do?

Level of Indirection allows us to:

Keep either the EID fixed while changing the RLOC

Create separate namespace with different allocation properties

By keeping EIDs fixed…

You don‟t have to renumber

You can keep TCP connections established across moves

By allowing RLOCs to change…

Now sites can change service providers

Now hosts can move

Roaming hand-sets

Relocating Virtual Machines

Relocating Infrastructure into a Cloud

More on this later in the “Use Cases” section…


LISP Operations


LISP OperationsLISP Components – Ingress/Egress Tunnel Router (xTR)

ITR – Ingress Tunnel Router• Receives packets from site-facing

interfaces

• Encaps to remote LISP site or natively

forwards to non-LISP site

ETR – Egress Tunnel Router• Receives packets from core-facing

interfaces

• De-caps and delivers to local EIDs at

the site

S1

S2

ITR

ITR

D1

D2

ETR

ETR

S D

Provider A

10.0.0.0/8

Provider B

11.0.0.0/8

Provider X

12.0.0.0/8

Provider Y

13.0.0.0/8

PITR PETR

MR

ALT

MS

ALT

ALTALT


LISP OperationsData Plane – Overview

On-Demand, Cache-based

The FIB only contains active map-cache entries

Dynamic Encapsulation

No hard tunnel state like GRE

Over-the-Top (CE-based)

The “core network” (I.e. Internet) doesn‟t see LISP at Layer 3


LISP OperationsData Plane Example – Unicast Packet Forwarding

S1

S2

ITR

ITR

D1

D2

ETR

ETR

S D

Provider A

10.0.0.0/8

Provider B

11.0.0.0/8

Provider X

12.0.0.0/8

Provider Y

13.0.0.0/8

PI EID-prefix

2.0.0.0/24

PI EID-prefix

3.0.0.0/24

DNS entry:

D.abc.com A 3.0.0.3

2.0.0.2 -> 3.0.0.3

EID-prefix: 3.0.0.0/24

Locator-set:

12.0.0.2, priority: 1, weight: 50 (D1)


Mapping

Entry This policy controlled

by destination site

2.0.0.2 -> 3.0.0.3

11.0.0.1 -> 12.0.0.2

2.0.0.2 -> 3.0.0.3

11.0.0.1 -> 12.0.0.2 2.0.0.2 -> 3.0.0.3

Legend:

EIDs -> Green

Locators -> Red

Physical link


LISP OperationsControl Plane – Overview

Distributed “Mapping Database” and “Map Cache”

Map-Servers and Map-Resolvers

Provide the service interface for LISP sites into the mapping database

LISP+ALT

Designed for a modular, scalable mapping service


LISP OperationsLISP Components – Map-Server/Map-Resolver (MS/MR)

S1

S2

ITR

ITR

D1

D2

ETR

ETR

S D

Provider A

10.0.0.0/8

Provider B

11.0.0.0/8

Provider X

12.0.0.0/8

Provider Y

13.0.0.0/8

PITR PETR

MR

ALT

MS

ALT

ALTALT

MS – Map-Server• LISP ETRs Register here; requires

configured “lisp site” policy, key

• Injects routes for registered LISP sites

into ALT thru ALT service interface

• Receives Map-Requests via ALT; en-

caps Map-Requests to registered ETRs

MR – Map-Resolver• Receives Map-Request encapsulated

from ITR

• De-caps Map-Request, forwards thru

service interface onto the ALT topology

• Sends Negative Map-Replies in response

to Map-Requests for non-LISP sites


LISP OperationsLISP Components – LISP-ALT Topology (ALT)

S1

S2

ITR

ITR

D1

D2

ETR

ETR

S D

Provider A

10.0.0.0/8

Provider B

11.0.0.0/8

Provider X

12.0.0.0/8

Provider Y

13.0.0.0/8

PITR PETR

MR

ALT

MS

ALT

ALTALT

ALT – Alternative Topology • Advertises EID-prefixes in Alternate BGP

topology over GRE

• Service interface for Map-Requests and

Map-Replies

• Devices with ALT service interface include:

MS, MR, xTR, PxTR

• ALT-only router aggregates ALT peering

connections and can be off-the-shelf gear,

a router, commodity Linux host, etc.


S1

S2

ITR

ITR

D1

D2

ETR

ETR

S D

Provider A

10.0.0.0/8

Provider B

11.0.0.0/8

Provider X

12.0.0.0/8

Provider Y

13.0.0.0/8

LISP OperationsControl Plane – Mapping Database & Map Cache

PITR PETR

MR

ALT

MS

ALT

ALTALT

LISP Map Cache

• “Lives” on ITRs

• Map-Cache populated by Map-Replies from ETRs

• Stored in ITRs – only for sites to which they are currently sending packets

• ITRs must respect policy of Map-Reply mapping data including TTLs, RLOC up/down status, RLOC priorities/weights

LISP Mapping-Database

• EID-to-RLOC mappings in all ETRs for each LISP site

• ETR is “authoritative” for its EIDs, sends Map-Replies to ITRs

• ETRs can tailor policy based on Map-Request source

• Decentralization increases attack resiliency


LISP OperationsControl Plane – Control Plane Mechanisms

Control Plane EID Registration

Map-Register messages

Sent by an ETR to a Map-Server to register its associated EID prefixes

Specifies the RLOC(s) to be used by the Map-Server when forwarding Map-Requests to the ETR

Control Plane “Data-triggered” mapping service

Map-Request messages

Sent from an ITR when it needs an EID mapping, to test an RLOC for reachability, or to refresh a mapping before TTL expiration

Map-Reply messages

Sent from an ETR in response to a valid map-request to provide the EID/RLOC mapping and site ingress Policy for the requested EID


LISP OperationsControl Plane Example – ETR Registration

65.1.1.1 66.2.2.2PI EID-prefix

2.0.0.0/24

PI EID-prefix

3.0.0.0/24

S1

S2

ITR

ITR

D1

D2

ETR

ETR

S D

Provider A

10.0.0.0/8

Provider B

11.0.0.0/8

Provider X

12.0.0.0/8

Provider Y

13.0.0.0/8

MR

ALT

MS

ALT

ALTALT

Legend:

EIDs -> Green

Locators -> Red

BGP-over-GRE

Physical link

[1]12.0.0.2-> 66.2.2.2

LISP Map-Register

(udp 4342)

SHA-1MS advertises

into ALT

BGP over GRE

3.0.0.0/8[2]

ALT advertise

throughout

Including to

Map-Resolver

[3]3.0.0.0/8

Other 3/8 sites…


LISP OperationsControl Plane Example – Map Request

65.1.1.1 66.2.2.2PI EID-prefix

2.0.0.0/24

PI EID-prefix

3.0.0.0/24

S1

S2

ITR

ITR

D1

D2

ETR

ETR

S D

Provider A

10.0.0.0/8

Provider B

11.0.0.0/8

Provider X

12.0.0.0/8

Provider Y

13.0.0.0/8

MR

ALT

MS

ALT

ALTALT

Legend:

EIDs -> Green

Locators -> Red

BGP-over-GRE

Physical link

DNS entry:

D.abc.com A 3.0.0.3

2.0.0.2 -> 3.0.0.3

How do I get

to 3.0.0.3?

11.0.0.1 -> 3.0.0.3

Map-Request

(udp 4342)

nonce

11.0.0.1 -> 65.1.1.1

LISP ECM

(udp 4342)

[1]

[2] [3] [4]

11.0.0.1 -> 3.0.0.3

Map-Request

(udp 4342)

nonce 11.0.0.1 -> 3.0.0.3

Map-Request

(udp 4342)

nonce

66.2.2.2 -> 12.0.0.2

LISP ECM

(udp 4342) [5]


LISP OperationsControl Plane Example – Map Reply

65.1.1.1 66.2.2.2PI EID-prefix

2.0.0.0/24

PI EID-prefix

3.0.0.0/24

S1

S2

ITR

ITR

D1

D2

ETR

ETR

S D

Provider A

10.0.0.0/8

Provider B

11.0.0.0/8

Provider X

12.0.0.0/8

Provider Y

13.0.0.0/8

MR

ALT

MS

ALT

ALTALT

Legend:

EIDs -> Green

Locators -> Red

BGP-over-GRE

Physical link

12.0.0.2 ->11.0.0.1

Map-Reply

(udp 4342)

nonce

3.0.0.0/24

12.0.0.2 [1, 50]

13.0.0.2 [1, 50]

[6]

EID-prefix: 3.0.0.0/24

Locator-set:



Mapping

Entry


LISP OperationsLocator Liveliness

Today if a connection goes down, the route for that connection point is withdrawn from the underlying routing table

Without

As consequence of adding the “level of indirection” with LISP, we no longer have direct access to “end-point” liveliness

EIDs are removed from DFZ and placed in “”off-line” control plane

Thus, we need new mechanisms to provide liveliness information

fix



We need a way to quickly detect when an RLOC is down to provide fast switchover…

We need recent up-status for an RLOC so that the switchover picks a working path…

Existence of a route to an RLOC does not give up-status

Requires a keep-alive mechanisms

Data Plane vs. Control Plane“N” times “M” control plane messages does not scale

Determine the best approach for fast switchover

Trade off message overhead vs. fast convergence

S1

S2

D1

D2S D?

�



Use the Routing Table when you can

Use ICMP if you can

In the data plane

Use Locator-Status-Bits (LSB)

In the data plane

Use Echo-Nonce

In the data plane for RLOC bi-directional flows

Use TCP-Counts

Trade off message overhead vs. fast

Use RLOC-Probing

In the control plane, from each source-site to each destination-site ETR

SolvesMoreCasesScalability


See additional details about Locator Liveliness in the “Additional Material” section at the end of this presentation

LISP OverviewLocator Liveliness


LISP OperationsInterworking Mechanisms

Early Recognition – LISP will not be widely deployed day-one

Interworking for:

LISP-capable sites to non-LISP sites (i.e. the rest of the Internet)

non-LISP sites to LISP-capable sites

Two basic Techniques

LISP Network Address Translators (LISP-NAT)

Proxy Ingress Tunnel Routers & Proxy Egress Tunnel Routers

Proxy-ITR/Proxy-ETR have the most promise

Infrastructure LISP network entity

Creates a monetized service opportunity for infrastructure players


LISP OperationsLISP Components – Proxy ITR/ETR (PITR/PETR)

S1

S2

ITR

ITR

D1

D2

ETR

ETR

S D

Provider A

10.0.0.0/8

Provider B

11.0.0.0/8

Provider X

12.0.0.0/8

Provider Y

13.0.0.0/8

PITR PETR

MR

ALT

MS

ALT

ALTALT

PETR – Proxy ETR

• Allows IPv6 LISP sites with IPv4 RLOCs

to reach IPv6 LISP sites that only have

IPv6 RLOCs

• Allows LISP sites with uRPF restrictions

to reach non-LISP sites

PITR – Proxy ITR

• Receives traffic from non-LISP sites; encapsulates traffic to LISP sites

• Advertises coarse-aggregate EID prefixes

• LISP sites see benefits of ingress TE “day-one”


LISP OperationsInterworking Mechanisms – PITR Example

Non-LISP

Site

65.1.0.0/16

Non-LISP

Site

65.2.0.0/16

Non-LISP

Site

65.3.0.0/16

EID

2.1.0.0/16

EID

2.2.0.0/16

EID

2.3.0.0/16

Non-LISP

Site

Non-LISP

Site

Non-LISP

Site

LISP

Site

LISP

Site

LISP

Site

Legend:

LISP Sites -> EIDs

non-LISP Sites -> RLOCs

Physical link

65.0.0.0/1266.0.0.0/12

PITRBGP Advertise:

2.0.0.0/8

PITRBGP Advertise:

2.0.0.0/8

PITRBGP Advertise:

2.0.0.0/8

65.1.1.1 -> 2.1.1.1

[1]

65.1.1.1 -> 2.1.1.1

65.9.1.1 -> 66.1.1.1

[2]

65.1.1.1 <- 2.1.1.1

[3]

Internet


LISP OperationsInterworking Mechanisms – PETR Example

Non-LISP

Site

65.1.0.0/16

Non-LISP

Site

65.2.0.0/16

Non-LISP

Site

65.3.0.0/16

EID

2.1.0.0/16

EID

2.2.0.0/16

EID

2.3.0.0/16

Non-LISP

Site

Non-LISP

Site

Non-LISP

Site

LISP

Site

LISP

Site

LISP

Site

Legend:

LISP Sites -> EIDs

non-LISP Sites -> RLOCs

Physical link

65.0.0.0/1266.0.0.0/12

PITRBGP Advertise:

2.0.0.0/8

PITRBGP Advertise:

2.0.0.0/8 Internet

PETR

ip lisp use-petr 65.10.1.1

65.1.1.1 <- 2.1.1.1

65.10.1.1 <- 66.1.1.1

[1]

65.1.1.1 <- 2.1.1.1

[2]

65.1.1.1 -> 2.1.1.1

65.9.2.1 -> 66.1.1.1

[4]

65.1.1.1 -> 2.1.1.1

[3]


LISP OperationsPractical Security Mechanisms

ETRs…

SHA-1 HMAC shared-key authentication between ETR and Map-Server to register EIDs into the mapping system

Additional policy and security configured on map-server

ITRs…

Will not accept unsolicited Map-Replies, and only accepts a Map-Reply that matches Map-Request nonce

Will not accept coarser EID-prefixes

ALT BGP is secured with peer authentication

sBGP can be added later when implement

Others…

Map-Requests rate-limited

Map-Replies could carry public keys

ITR could encrypt encapsulated data with ESP headers


LISP OperationsManagement of LISP

Data Plane Management

Ping, traceroute of EIDs

Ping, traceroute of RLOCs

Control Plane Management

LISP Internet Groper (LIG) (like “dig” for DNS)

Device Management

show and debug commands

MIB coming…

S1

S2

D1

D2



LISP Internet Groper (LIG)

Fetches an EID-to-RLOC database mapping entry

Both router and host lig implementations available

titanium-dino# lig dmm-xtr-2.lisp4.net

Send map-request to 128.223.156.35 for 153.16.12.1 ...

Received map-reply from 128.223.156.23 with rtt 0.040508 secs

Map-cache entry for dmm-xtr-2.lisp4.net EID 153.16.12.1:

153.16.12.0/24, uptime: 00:00:01, expires: 23:59:58, via map-reply, auth

Locator Uptime State Priority/ Data Control

Weight in/out in/out

128.223.156.23 00:00:01 up 1/100 0/0 0/0

titanium-dino# lig self6

Send loopback map-request to 128.223.156.35 for 2610:d0:2105:: ...

Received map-reply from 173.8.188.25 with rtt 0.260715 secs

Map-cache entry for EID 2610:d0:2105:::

2610:d0:2105::/48, uptime: 00:00:01, expires: 23:59:58, via map-reply, self

Locator Uptime State Priority/ Data Control

Weight in/out in/out

173.8.188.25 00:00:01 up 1/33 0/0 0/0

173.8.188.26 00:00:01 up 1/33 0/0 0/0

173.8.188.27 00:00:01 up 1/33 0/0 0/0

2002:ad08:bc19::1 00:00:01 up 2/0 0/0 0/0



xTR(config)# ip lisp ?

alt-vrf Activate LISP-ALT functionality in VRF

database-mapping Configures Locator addresses for an ETR

etr Configures a LISP Egress Tunnel Router (ETR)

itr Configures a LISP Ingress Tunnel Router (ITR)

locator-down Manually set locator status to down

map-cache Configures static EID-to-RLOC mappings for an ITR

map-cache-limit Configures maximum size of map-cache

map-request-source Configures source address for Map-Request message

path-mtu-discovery Path MTU discovery

proxy-etr Configures a LISP Proxy Engress Tunnel Router (PETR)

proxy-itr Configures a LISP Proxy Ingress Tunnel Router (PITR)

use-petr Encapsulate to Proxy ETR when matching forward-native entry

xTR# show ip lisp ?

database Show EID-prefixes configured for this site

forwarding LISP forwarding module show commands

map-cache Display EID-to-RLOC cache mapping in this ITR

statistics Display LISP address family statistics

| Output modifiers

<cr>

xTR# debug lisp ?

control-plane LISP control plane debug categories

detail Enable LISP detailed debugging

filter Specify a filter for LISP debug output

forwarding LISP forwarding related debug commands


LISP Example


LISP ExampleConfigurations

arin-mrms

MS/MR

dmm-isr

xTR

simlo

xTR128.223.156.222

217.41.88.65

128.223.156.139

153.16.21.0/24

153.16.40.0/24

ripe-mrms

MS/MR

193.0.0.170

!

interface Loopback0

ip address 153.16.21.1 255.255.255.255

!

interface FastEthernet0/0

ip address 128.223.156.222 255.255.255.0

!

interface FastEthernet0/0/0

ip address 153.16.21.17 255.255.255.240

!

ip lisp database-mapping 153.16.21.0/24 128.223.156.222 priority 1 weight 100

ip lisp itr map-resolver 128.223.156.139

ip lisp itr

ip lisp etr map-server 128.223.156.139 key 6 #%$^%##

ip lisp etr

!

ip route 0.0.0.0 0.0.0.0 128.223.156.1

!



arin-mrms

MS/MR

dmm-isr

xTR

simlo

xTR128.223.156.222

217.41.88.65

128.223.156.139

153.16.21.0/24

153.16.40.0/24

ripe-mrms

MS/MR

193.0.0.170

!

interface Loopback0

ip address 153.16.40.1 255.255.255.255

!

interface FastEthernet0/0

ip address 217.41.8.65 255.255.255.0

!

interface FastEthernet0/0/0

ip address 153.16.40.2 255.255.255.240

!

ip lisp database-mapping 153.16.40.0/24 217.41.88.65 priority 1 weight 100

ip lisp itr map-resolver 193.0.0.170

ip lisp itr

ip lisp etr map-server 193.0.0.170 key 6 #%$^%##

ip lisp etr

!

ip route 0.0.0.0 0.0.0.0 217.41.88.1

!



arin-mrms

MS/MR

dmm-isr

xTR

simlo

xTR128.223.156.222

217.41.88.65

128.223.156.139

153.16.21.0/24

153.16.40.0/24

ripe-mrms

MS/MR

193.0.0.170

!

hostname arin-mrmr

!

---<skip>---

lisp site dmm-isr

eid-prefix 153.16.21.0/24 route-tag 1234567890

authentication-key 3 #%$^%##

description dmm-isr

!

---<skip>---

!

hostname ripe-mrmr

!

---<skip>---

lisp site simlo

eid-prefix 153.16.40.0/24 route-tag 1234567890

authentication-key 3 #%$^%##

description simlo

!

---<skip>---


LISP ExampleOperations

arin-mrms

MS/MR

dmm-isr

xTR

simlo

xTR128.223.156.222

217.41.88.65

128.223.156.139

153.16.21.0/24

153.16.40.0/24

ripe-mrms

MS/MR

193.0.0.170

dmm-isr# show ip lisp map-cache

LISP IPv4 Mapping Cache, 1 entries

0.0.0.0/0, uptime: 00:01:15, expires: never, via static

dmm-isr#

dmm-isr# show ip lisp database

LISP ETR IPv4 Mapping Database, LSBs: 0x1

EID-prefix: 153.16.21.0/28

128.223.156.222, priority: 1, weight: 100, state: up, local

dmm-isr#



arin-mrms

MS/MR

dmm-isr

xTR

simlo

xTR128.223.156.222

217.41.88.65

128.223.156.139

153.16.21.0/24

153.16.40.0/24

ripe-mrms

MS/MR

193.0.0.170

dmm-isr# show ip lisp site dmm-isr

LISP Site Registration Information for VRF "default"

* = truncated IPv6 address

Site name: "dmm-isr"

Description: none configured

Allowed configured locators: any

Allowed EID-prefixes:

EID-prefix: 2610:d0:1209::/48

Currently registered: yes

First registered: 1w5d

Last registered: 00:00:17

Who last registered: 128.223.156.222

Routing table tag: 0x499602d2

Registered locators:

128.223.156.222 (up)

EID-prefix: 153.16.21.0/28

Currently registered: yes

First registered: 1w5d

Last registered: 00:00:17

Who last registered: 128.223.156.222

Routing table tag: 0x499602d2

Registered locators:

128.223.156.222 (up)

dmm-isr#



arin-mrms

MS/MR

dmm-isr

xTR

simlo

xTR128.223.156.222

217.41.88.65

128.223.156.139

153.16.21.0/24

153.16.40.0/24

ripe-mrms

MS/MR

193.0.0.170

dmm-isr# lig self

Mapping information for EID 153.16.21.0 from 128.223.156.222 with RTT 0 msecs

153.16.21.0/24, uptime: 00:00:00, expires: 23:59:59, via map-reply, self

Locator Uptime State Pri/Wgt

128.223.156.222 00:00:00 up 1/100

dmm-isr#dmm-isr# show ip lisp map-cache





128.223.156.222 00:00:02 up 1/100

dmm-isr#



arin-mrms

MS/MR

dmm-isr

xTR

simlo

xTR128.223.156.222

217.41.88.65

128.223.156.139

153.16.21.0/24

153.16.40.0/24

ripe-mrms

MS/MR

193.0.0.170

dmm-isr# lig 153.16.40.1

Mapping information for EID 153.16.40.1 from 217.41.88.65 with RTT 404 msecs

153.16.40.0/24, uptime: 00:00:00, expires: 1d00h, via map-reply, complete


217.41.88.65 00:00:00 up 1/100

dmm-isr# dmm-isr# show ip lisp map-cache





128.223.156.222 00:00:10 up 1/100

153.16.40.0/24, uptime: 00:00:00, expires: 23:59:59, via map-reply, complete


217.41.88.65 00:00:00 up 1/100

dmm-isr#



arin-mrms

MS/MR

dmm-isr

xTR

simlo

xTR128.223.156.222

217.41.88.65

128.223.156.139

153.16.21.0/24

153.16.40.0/24

ripe-mrms

MS/MR

193.0.0.170

dmm-isr# show ip lisp

Ingress Tunnel Router (ITR): enabled

Egress Tunnel Router (ETR): enabled

ITR Map-Resolver: 128.223.156.139

ETR Map-Server(s): 128.223.156.139 (00:00:07)

ETR accept mapping data: enabled, verify enabled

ETR map-cache TTL: 24 hours

Locator Status Algorithms:

RLOC-probe algorithm: enabled

Static mappings configured: 0

Map-cache limit: 1000

Map-cache activity check period: 60 secs

Map-cache size: 3

dmm-isr#


LISP Use Cases


LISP Use CasesEnterprise Use Case 1 – Low OpEx Multi-Homing

Provider A10.0.0.0/8

Provider B11.0.0.0/8

S1 S2

2.0.0.0/8

Active/active multi-homing

Low-OpEx switchover (no BGP)

More efficient bandwidth use by site

Use all the bandwidth you pay for

New link revenue for ISP

At the benefit of keeping site‟s routes out of their resources

Decoupling addressing from ISP

Site has flexibility to change providers

Raises the bar for ISPs, better for consumer sites


LISP Use CasesEnterprise Use Case 2 – Dynamic Roaming and VPNs

San Francisco

Los Angeles

Boston

New York

2.1.0.0/16Engineering


Dallas

65.0.0.0/8

10.1.0.0/16Marketing

10.2.0.0/16Marketing

Marketing is using private addresses

Enterprise Core

2.2.0.0/16 -> (65.4.1.1, 65.4.2.2)

65.5.1.1 65.5.2.2

(65.5.1.1, 65.5.2.2)

Engineering is using global PI addresses

Core is using global PA addresses


An engineering site movesDynamic creation of a site is done by simply registering

EID-to-RLOC mapping to the Mapping Database System


LISP Use CasesService Provider Use Case 1 – Multi-Family Address Support

The Internet core is not dual-stack, deal with it

IPv6-only Site

Dual Stack

IPv6-only Site

Dual Stack

2610:d0:1::/48IPv4 Internet

CoreLISP Site LISP Site

2610:d0:2::/48

LISP Site

240.1.0.0/162610:d0:1::/48

Non-LISP Site

65.4.0.0/162001:1:2::/48

Dual-Stack ISP

PxTRPxTR

dino-unix.lisp6.net ipv6.google.comTCP-over-IPv6 Connection


LISP Use CasesService Provider Use Case 2 – Multi-Family Address Support

IPv4-only Residential Site

IPv4-only Server Site

192.168.1.0/24

IPv6 CableCore Network

LISP Site

LISP Site

2.1.0.0/16

IPv4-only Server Site

Non-LISP Site

65.4.0.0/16

IPv6 path IPv4 path

Dual-Stack Region

PxTRPxTR

A possible cable company…

IPv6 core; They can‟t upgrade residential on IPv4


LISP Use CasesData Center Use Case 1 – Virtual Machine Mobility

S1 S3S2 S4

RLOC A RLOC A’

A’A3.1.1.254/24 3.1.11.254/24

3.1.1.1/24 3.1.11.2/24

2.2.2.254/24 2.2.22.254/24

2.2.2.3/24 2.2.22.4/24

3.1.0.0/16 -> A

2.2.0.0/16 -> A’

L3 Router LISP Router

S1 moves

3.1.1.1/32 -> A’

Data Center


LISP Use CasesData Center Use Case 2 – Load Balancing the SLBs

Array of Servers

Internet

Data Center

Array of SLBs

L3 Router LISP Router Any brand Server Load Balancer Servers

ETR ETR ETR ETR

ITRITR ITR

ITR

VIPs are EIDs

VIPs

EIDs -> RLOC-sets


LISP Use CasesLISP Mobile Code Use Case –

What if 2 Mobile Hand-sets could roam and keep a TCP connection established?

What if 2 Mobile Hand-sets could LISP-encapsulate to each other with a path-stretch of 1?

What if you could put up server functionality on your Mobile Hand-set?

What if your Mobile Hand-set could use all radios at the same time?



EID-prefix: 2001:xxxx:yyyy::1/128 64.0.0.1

This is a LISP site!

65.0.0.1

Map-Server: 64.1.1.1

wifi

3G

Can set ingress packet policy!

Green x.x.x.x -> EID Red x.x.x.x -> Locator (RLOC)



Run lightweight variant of LISP on the MN

draft-meyer-lisp-mn-01.txt

EID can be burned into the SIM

Can be either an IPv4 or probably an IPv6 address

Will be yours forever – it‟s your “Network Name”

Your DHCP address is your MN‟s RLOC

MN carries Map-Server RLOC while roaming

When you get a new DHCP address:

Register the new RLOC(s) to Map-Server(es)

Update ITR/PITR caches


LISP Use CasesLISP Mobile Code Use Case – Can it scale?

Leave RLOCs alone, they map to underlying physical topology

There is absolutely no more-specific state in the core for LISP MNs (or any other LISP site for that matter…)

LISP MN EID more-specific state only in Map-Server

Map-Server is control-plane home agent

Map-Server already has covering route; no more-specifics in the ALT

The only other place for more-specific state is in devices that cache (ITRs and PITRs)

How bad can this be?


LISP Use CasesLISP Mobile Code Use Case – Back-of-the-Envelop Calculation

Assume a map-cache entry is 1000-bytes

• 1000-bytes is fairly fat and can be optimized

1M entries (LISP MNs) per ITR requires 1GB of memory (cheap!)

10M entries (LISP MNs) requires 10GB of memory (simple!)

Deploy 100 ITRs at 10M entries each – that‟s 1B LISP MNs

100 ITRs is not unreasonable since good use-experience forces shortest exit

Each ITR can hold 10M phones!

This is achievable since granular state is only where you need it and no where else!


LISP Initiatives


Oct 2006: IAB Routing WS

2006 2007 2008 2009 2010

Jan 2007: First DraftsMain LISP

1st IETF WGSan Francisco

2nd IETF WGStockholm

3rd IETF WGHiroshima

Summer 20081st BOF

Dublin IETF

Fall 20082nd BOF

Minneapolis IETF

June 2007: 2nd Set Drafts

LISP-ALTLISP-CONSLISP-NERD

Fall 2007:3rd Set Drafts

LISP-IW

Spring 2009:More DraftsLISP-MSLISP-LIG

Summer 2009:LISP-MN

Summer 2009:Loc-Reach-AlgsImplemented

2007 LISP in RRG

RRG Effort IETF Effort

Fall 2010:IETF WG Completes

Beijing

LISP InitiativesStandardization Status


• External LISP Efforts– FreeBSD OpenLISP

http://gforge.info.ucl.ac.be/projects/openlisp/– Open Source LIG Diagnostic Tool

http://www.github.com/davidmeyer/lig

LISP InitiativesWhat’s Cisco Doing in LISP?

Cisco LISP Prototype Implementation

Started at Prague IETF, Mar 07; Deployed Pilot Network, July 07

Since then, >220 releases of experimental code

Cisco LISP Product Implementations

Phase 1 (December 24, 2009)

− ISR, ISR-G2, 7200 (xTR)

Phase 2 (March 31, 2010)

− ISR, ISR-G2, 7200 (xTR, PxTR, ALT) [IOS 15.1(1)XB1]

− ASR 1000 (xTR, PxTR, ALT) [IOS-XE 2.5.1]

− Nexus 7000 (xTR, PxTR, MS/MR) [NX-OS 5.1(1.13)]

− UCS C200 (MS/MR) [NX-OS 5.1(1.13)]

Phase 3 (June 30, 2010)

− More LISP!

Available

Now!


Conduct Experiments

Provide course-adjustments for protocol architecture

Test Multiple Implementations

Prove ALT Topology maps to EID Address Allocation Delegations

Emulate MSP Business Models

Protocol Learning Tool for Users

Test bed for building Management Tools

LISP InitiativesLISP Network – Goals for the LISP Network




LISP InitiativesLISP Network – Gaining LISP management experience


Summary


LISP creates a level of indirection that separates End Host addresses from Site address to resolve Internet scaling issues

LISP requires no host changes, minimal CPE changes, and adds some infrastructure components to the core

LISP enables simplified multi-homing with ingress traffic engineering without the need for BGP

LISP enables End Host mobility without requiring renumbering

LISP is an open standard (no Cisco IPR)

LISP SummaryKey Takeaways


LISP SummaryReferences [1]

Locator/ID Separation Protocol (LISP) - draft-ietf-lisp-06; 25-Jan-2010. http://tools.ietf.org/html/draft-ietf-lisp-06

LISP Map Server - draft-ietf-lisp-ms-04; 05-Oct-2009.http://tools.ietf.org/html/draft-ietf-lisp-ms-04

LISP ALT - draft-ietf-lisp-alt-02; 25-Jan-2010.http://tools.ietf.org/html/draft-ietf-lisp-alt-01

LISP Interworking - draft-ietf-lisp-interworking-00; 26-May-2009. http://tools.ietf.org/html/draft-ietf-lisp-interworking-00

LISP Multicast - draft-ietf-lisp-multicast-02; 29-Sep-2009. http://tools.ietf.org/html/draft-ietf-lisp-multicast-02

LISP Mobility Architecture - draft-meyer-lisp-mn-01; 01-Feb-2010. http://tools.ietf.org/html/draft-meyer-lisp-mn-00

LISP Internet Groper (LIG) - draft-farinacci-lisp-lig-01; 05-May-2009.http://tools.ietf.org/id/draft-farinacci-lisp-lig-01.txt


LISP SummaryReferences [2]

You can find additional information about the topics and

products covered in this session at the following links:

http://lisp4.cisco.com http://lisp6.cisco.com

http://www.lisp4.net http://www.lisp6.net

Cisco LISP Mailer:

[email protected]


Q & A



Additional MaterialLISP and MTU


LISP OverviewLISP and MTU [1]

LISP encapsulation increase the forwarded packet size

IPv4 – 36 bytes

IPv6 – 56 bytes

Other tunneling/encapsulation protocols do the same

GRE, IPSec, IP-in-IP, etc.

In general - solutions for handling MTU and fragmentation issues with tunnels/encapsulations are well documented

Stateful or Stateless

Ensure packets don‟t fragment

Allow packets to fragment

Drop packets



Practical MTU on the Internet is 1500 bytes

Most of the core supports 4470 or 9162 bytes

Hosts assume “effective MTU” of 1500 bytes

When using tunneling mechanisms, prepending headers could make packet sizes > 1500 bytes

Larger packets are better for efficiency purposes

Network layer fragmentation is not performance-efficient

Decapsulating tunnel routers need reassembly buffers

Packet loss causes long buffer holding periods


SD

ITR

1500

R1

R2 R3

R4ETR

Here when Access MTU larger

than Core MTU (unlikely)

1500

Here when LISP header

puts packet over 1500

LISP OverviewLISP and MTU [3] – Where is the problem?


SD

ITR


1500

R1

R2 R3

R4ETR

Fragment-then-encapsulate

here means…Reassemble here…

Best alternative!

Encapsulate-then-fragment

here means…

Fragment

here means…

Reassemble here…

Avoid at all cost!

Reassemble here…

Avoid at all cost!


Stateless Mechanism

Allow fragmentation

ITR fragments and then encapsulates; destination host reassembles

Stateful Mechanism

Avoid fragmentation

Use PMT Discovery between ITR and ETR; ITR stores “effective MTU” per locator

Don‟t Care Mechanism

Avoid fragmentation and PMTU Discovery

Assume core MTU always > access MTU; Assumes always room for tunnel headers

LISP OverviewLISP and MTU [5] – Spec’d Solutions draft-ietf-lisp-07


When DF=0 (Okay to Fragment)

ITR can use “don‟t care” mechanism

ITR can use “stateless” mechanism

When DF=1 (Don‟t Fragment)

PMTU Discovery performed between Source and ITR

ITR can lower MTU for sufficient encapsulation header room

IPv6 is always DF=1

Expectation for PMTU Discovery

Plus, always hard for routers to insert Fragment Option

LISP OverviewLISP and MTU [6] – Source (Host) Control


When Inner Header is DF=0

ITR can do “stateless” mechanism

Pre-encap fragments to size well below 1500, and , sets outerheader to DF=0

ITR can do “stateful” mechanism

Set outer header to DF=1 assures no fragmentation allowed in core, and expects PMTUD on LISP “tunnel”

When Inner Header is DF=1

ITR can do “stateless” mechanism

But will never fragment since it can control source packet size

ITR can do “stateful” mechanism

Enables PMTUD so it can propagate effective MTU back to the source

LISP OverviewLISP and MTU [7] – LISP Router Control


You either Fragment or Drop Packets

PMTU Discovery causes (periodic) packet drops

Fragmentation requires reassembly buffer resources

Experience will show which mechanisms will be necessary

Years of experience with IPSec and GRE can inform decisions and approaches for LISP

LISP OverviewLISP and MTU [8] – Harsh Reality


Additional MaterialLISP and Locator Liveliness


S1

S2

D1

D2S D

LISP OperationsLocator Reachability [1] – Problem Statement

ITR S1 needs to know if RLOC D1 is reachable

ITR S1 needs to know if it can switch over to RLOC D2

ITR S1 cannot depend on a D1-prefix route to determine if RLOC D1 is reachable

?


S1

S2

D1

D2S D


Because ITR D1 can reach RLOC S1 does not mean that ITR S1 can reach RLOC D1

All you know is that RLOC D1 has not crashed – but you don‟t know the forwarding path from S1->D1

?

�


We need a way to detect quickly when an RLOC is down to provide fast switchover…

We need to have recent up-status for an RLOC so that the switchover picks a working path…

Existence of a route to an RLOC does not give an up-status

Requires a keepalive mechanism

Data Plane versus Control Plane

“N” times “M” control messages does not scale

Determine the best approach for fast switchover

Tradeoff message overhead versus fast convergence



S1

S2

D1

D2S D

LISP Encapsulation includes “Locator Status Bits” (LSB)

LSBs are set/sent by ITR to ETR to indicate the up/down status of source-site locators

LSB from ITR D1 to RLOC S1 just tells S1 that D1 is not down

It does not tell S1 that the path from S1 to D2 is reachable, or that S2 to D2 is reachable


0x00000003


LISP OperationsLocator Reachability [5] – Possible Data Paths

S1

S2

D1

D2S D

Totally Symmetric

S1

S2

D1

D2S D

Source Symmetric

S1

S2

D1

D2S D

Return Path Symmetric

S1

S2

D1

D2S D

Totally Asymmetric“The Square”


Data Plane-based

Deep-packet-inspection TCP-connection heuristics (tcp-count)

Piggyback “nonce” on data (echo-nonce)

Control Plane-based

ITR can probe each ETR for every map-cache entry with control messaging (rloc-probe)

ITR can use “Send and Hope for the Best” approach

Use ICMP Unreachables to tell you path-down status

There is no ICMP mechanism to indicate a path-back-up status

LISP OperationsLocator Reachability [6] – Solution Space


S1

S2

D1

D2S D

LISP OperationsLocator Reachability [7] – DPI “TCP-Count”

ACK

SYN

SYN/ACK

Specifically designed for “the square”, ITRs count SYNs-sent and ACKs-sent for all connections

If ACKs are sent, return path from D2 to S2 is validated and path from S1 to D1 is validated

If SYNs are sent but no ACKs are sent, there is no return traffic

But S1->D1 could be working when D1->D, D->D2, D2->S2, or S2->S is broken. S1 should not switchover to D2 in this case.

This mechanism gives you “path-up” status, but not good “down” status


S1

S2

D1

D2S D

LISP OperationsLocator Reachability [8] – Piggyback “Echo-Nonce”

Nonces in Data Packets…

ITR requests ETR to “echo back” nonce by setting data packet “E-bit”

Echo from ETR contains the ITRs nonce with the E-bit cleared (validates “up” status)

Detects “down” status via timeout of echo-nonce

Only works with symmetric (bi-directional traffic) between RLOC pairs

Can be quicker to converge than control message keepalives as long as data is flowing between ITR to ETR

E=1, nonce: 0x00123456

E=0, nonce: 0x00123456


S1

S2

D1

D2S D

LISP OperationsLocator Reachability [9] – Control Msg “rloc-probe”

Add “probe-bit” to Map-Request and Map-Reply messages

Map-Request with probe-bit sent to remote RLOC

Allocates random 64-bit nonce

Map-Reply with probe-bit acknowledges Map-Request probe

Returns same 64-bit nonce

Data:

Probes:


Method Description Advantages Disadvantages

rloc-probing

IOS

NX-OS

• Control Plane Message

• ITR originates Map-Request

with probe “P-bit” set

• ETR returns Map-Reply with “P-

bit” set, and current mappings.

• Provides opportunity to get

mapping updates

• Controlled by ITR side

• Measures RTT

• Can do “make-before-break”

• Can update mappings at same

time as probe

• No control plane/data plane

exchange issue

• Potentially, high number of

control plane messages

• Spreading out over time

causes slow switchover

tcp-count

NX-OS

• Data Plane DPI

• ITR counts SYNs sent and

ACKs sent for all connections

during encapsulation

• Specifically designed for

“square” data path

• No added messages or

overhead

• Validates forward and return

path at the same time

• Provides “path-up” status but is

not good at “path-down” status

• Limited to “square” data path

• Does not work for

unidirectional traffic

echo-nonce

NX-OS

• Data Plane Piggyback

• ITR sets “E-bit” and “N-bit” and

sends „nonce‟ with data

• ETR responds to “E-bit” and “N-

bit” with “echo back” of nonce

• ITR detects “down” status on

time-out of echo-nonce

• Can converge more quickly

than control message

keepalives for data flows

between ITR / ETR

• Only works with bidirectional

(symmetric) traffic between

RLOC-pairs

• Does not work for

unidirectional traffic

• Bilateral algorithm – i.e. both

sides must participate

LISP OperationsLocator Reachability [10] – Summary

Documents

10 fn tut3