10 fn tut3

LISP - A Next Generation Networking
Architecture

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

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

Agenda
 LISP Overview
 LISP Operations
 LISP Example
 LISP Use Cases
 LISP Initiatives
 LISP Summary
 Additional Material


LISP Overview

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

LISP Overview
Why was LISP developed?
 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?
“… routing scalability is the most
− Routers require tons of expensive memory important problem facing the Internet
to hold the Internet Routing Table in the
today and must be solved … ”
forwarding plane of a router
− It‟s expensive for network builders/operators Internet Architecture Board (IAB)
October 2006 Workshop (written as RFC 4984)
− Replacing equipment for the wrong reason
(to hold the routing table rather than
implementing new features…)
− It‟s not environmentally GREEN 


LISP Overview
What Pollutes the Internet Today?

Before
Loc/ID
Split Internet Provider Z
Provider D

10.1.1.0/24
Provider C 15/8
10/8 10.1.1.0/24 15/8 Provider W
Provider H
Provider G
Provider X
Provider A Provider Y 12.0.0.0/8
Provider B
10.0.0.0/8 13.0.0.0/8
11.0.0.0/8

10.1.1.0/24 10.1.1.0/24 15.0.0.0/8 15.0.0.0/8

R1 R2 R1 R2
Provider Assigned Provider Independent
(PA) (PI)
10.1.1.0/24 15.0.0.0/8

• Addresses at sites, both PA and PI,
can get de-aggregated by multi-homing


LISP Overview
What Pollutes the Internet Today?

Before
Loc/ID
Provider D
13/8 12/8
11/8
10.1.1.0/24
Provider C 15/8
10/8 10.1.1.0/24 15/8 Provider W
Provider H
Provider G
Provider X
Provider A Provider Y 12.0.0.0/8
Provider B
10.0.0.0/8 13.0.0.0/8
11.0.0.0/8

10.1.1.0/24 10.1.1.0/24 15.0.0.0/8 15.0.0.0/8
12.4.4.1/30
10.9.1.45/30 11.2.1.17/30 13.3.3.5/30
R1 R2 R1 R2
(PA) (PI)
10.1.1.0/24 15.0.0.0/8

• Addresses at sites, both PA and PI, • Aggregates for infrastructure addresses
can get de-aggregated by multi-homing (e.g. CE-PE links) get advertised as well


LISP Overview
Why does LISP solve this problem?

 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 Overview
Why does Locator/ID Separation solve this problem?

Before
Loc/ID
Provider D
13/8 12/8
11/8
10.1.1.0/24
Provider C 15/8
10/8 15/8
10.1.1.0/24 Some-Core-Rtr# show ip route bgp
Provider W
Provider H ---<skip>---
Provider G is
10.0.0.0/8 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] viaProvider X 3d19h
128.223.3.9,
Provider A B Provider Y
11.0.0.0/8 [20/0] via 128.223.3.9, 1d17h
12.0.0.0/8
Provider B ---<skip>---
10.0.0.0/8 13.0.0.0/8
11.0.0.0/8 12.0.0.0/8 is variably subnetted, 29 subnets, 6 masks
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>---
13.0.0.0/8 is variably subnetted, 13 subnets, 4 masks
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
10.1.1.0/24 10.1.1.0/24 15.0.0.0/8
---<skip>---
15.0.0.0/8
B 15.0.0.0/8 [20/0] via 128.223.3.9, 1d17h
---<skip>--- 12.4.4.1/30
10.9.1.45/30 11.2.1.17/30 13.3.3.5/30
many many more......
R1 R2 Some-Core-Rtr# R1 R2
(PA) (PI)
10.1.1.0/24 15.0.0.0/8



LISP Overview
Why does Locator/ID Separation solve this problem?

After New “EID” Namespace
Loc/ID B 10.1.1.0/24 [20/0] via 128.223.3.9, 3d19h
B 15.0.0.0/8 [20/0] via Provider D 1d17h
128.223.3.9,
13/8 12/8
11/8
10.1.1.0/24
Provider C 15/8
10/8 15/8
10.1.1.0/24 Some-Core-Rtr# show ip route bgp
Provider W
Provider H ---<skip>---
Provider G is
10.0.0.0/8 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] viaProvider X
11.0.0.0/8 [20/0] via 128.223.3.9, 1d17h 3d19h
128.223.3.9,
Provider A Provider Y
---<skip>---
B 11.0.0.0/8 [20/0] via 128.223.3.9, 1d17h
12.0.0.0/8
Provider B ---<skip>---
10.0.0.0/8 13.0.0.0/8
11.0.0.0/8 B 12.0.0.0/8 is variably via 128.223.3.9, 3d19h 6 masks
12.1.0.0/16 [20/0] subnetted, 29 subnets,
B 12.4.4.0/22 [20/0] via 128.223.3.9, 3d19h
12.1.0.0/16
---<skip>---
B 12.4.4.0/22 [20/0] via 128.223.3.9, 3d19h
---<skip>---
B 13.0.0.0/8 is [20/0] via 128.223.3.9, subnets, 4 masks
13.0.0.0/8 variably subnetted, 13 14:00:10
B 13.0.0.0/10 [20/0] via 128.223.3.9, 14:00:10
13.0.0.0/8 [20/0] via 128.223.3.9, 5d23h
---<skip>---
B 13.0.0.0/10 [20/0] via 128.223.3.9, 5d23h
10.1.1.0/24 10.1.1.0/24 15.0.0.0/8
---<skip>---
15.0.0.0/8
B 15.0.0.0/8 [20/0] via 128.223.3.9, 1d17h
---<skip>--- 12.4.4.1/30
10.9.1.45/30 11.2.1.17/30 13.3.3.5/30
many many more......
R1 R2 Some-Core-Rtr# R1 R2
(PA) (PI)
10.1.1.0/24 15.0.0.0/8



LISP Overview
Protocol Ground Rules and Attributes

 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 “Attributes”  LISP “Ground Rules”
Designed for router encapsulation Network-based solution
Designed for Locator Reachability No host changes
Support Unicast and Multicast Data No new addressing to site devices;
Support for IPv4 IPv6 EIDs (hosts) and minimal configuration changes
RLOCs (locators) Incrementally deployable; interoperable
with existing Internet


LISP Overview
LISP Header Format
draft-ietf-lisp-07

Outer Header:
Router supplies
RLOCs

UDP

LISP
header

Inner Header:
Host supplies
EIDs


LISP Overview
LISP 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

7. Application peer-to-peer communications 7. Application
6. Presentation 6. Presentation
5. Session 5. Session
source destination
host peer-to-peer communications host
4. Transport 4. Transport

3. Network (host) 3. Network (host) 3. Network (host)

(LISP UDP) (LISP UDP) (LISP UDP)
3. Network (host) 3. Network (LISP) 3. Network (LISP) 3. Network (LISP) 3. Network (host)

2. Data Link 2. Data Link 2. Data Link 2. Data Link 2. Data Link

1. Physical 1. Physical 1. Physical 1. Physical 1. Physical

LISP LISP
En-cap ITR ETR De-cap
Internet
packets packets


LISP Overview
MTU Issues?

 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 Overview
LISP and MTU…

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


LISP Overview
Now 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 Operations
LISP Components – Ingress/Egress Tunnel Router (xTR)

ALT ALT

MR ALT ALT MS
ITR ETR
Provider A Provider X
S1 10.0.0.0/8 12.0.0.0/8 D1
PITR PETR

S Provider B Provider Y D
S2 D2
11.0.0.0/8 13.0.0.0/8
ITR ETR

ITR – Ingress Tunnel Router ETR – Egress Tunnel Router
• Receives packets from site-facing • Receives packets from core-facing
interfaces interfaces
• Encaps to remote LISP site or natively • De-caps and delivers to local EIDs at
forwards to non-LISP site the site


LISP Operations
Data 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 Operations
Data Plane Example – Unicast Packet Forwarding

PI EID-prefix PI EID-prefix
2.0.0.0/24 3.0.0.0/24

ITR ETR
S1 10.0.0.0/8 12.0.0.0/8 D1

S2 D2
11.0.0.0/8 13.0.0.0/8
ITR ETR
2.0.0.2 -> 3.0.0.3

11.0.0.1 -> 12.0.0.2 11.0.0.1 -> 12.0.0.2
DNS entry: 2.0.0.2 -> 3.0.0.3
2.0.0.2 -> 3.0.0.3 2.0.0.2 -> 3.0.0.3
D.abc.com A 3.0.0.3

EID-prefix: 3.0.0.0/24
Legend: Mapping Locator-set:
EIDs -> Green
Entry 12.0.0.2, priority: 1, weight: 50 (D1) This policy controlled
Locators -> Red
Physical link 13.0.0.2, priority: 1, weight: 50 (D2) by destination site


LISP Operations
Control 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 Operations
LISP Components – Map-Server/Map-Resolver (MS/MR)

ALT ALT

MR ALT ALT MS
ITR ETR
S1 10.0.0.0/8 12.0.0.0/8 D1
PITR PETR

S2 D2
11.0.0.0/8 13.0.0.0/8
ITR ETR

MR – Map-Resolver MS – Map-Server
• Receives Map-Request encapsulated • LISP ETRs Register here; requires
from ITR configured “lisp site” policy, key
• De-caps Map-Request, forwards thru • Injects routes for registered LISP sites
service interface onto the ALT topology into ALT thru ALT service interface
• Sends Negative Map-Replies in response • Receives Map-Requests via ALT; en-
to Map-Requests for non-LISP sites caps Map-Requests to registered ETRs


LISP Operations
LISP Components – LISP-ALT Topology (ALT)

ALT ALT

MR ALT ALT MS
ITR ETR
S1 10.0.0.0/8 12.0.0.0/8 D1
PITR PETR

S2 D2
ITR
ALT – Alternative
11.0.0.0/8 13.0.0.0/8
Topology ETR
• 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.


LISP Operations
Control Plane – Mapping Database & Map Cache

LISP Mapping-Database ALT ALT
• EID-to-RLOC mappings in all ETRs for each LISP site
• ETR is “authoritative” for its EIDs, sends Map-Replies to ITRs
MR ALT ALT MS
• ETRs can tailor policy based on Map-Request source
ITR ETR
• Decentralization increases attack resiliency
S1 10.0.0.0/8 12.0.0.0/8 D1
PITR PETR

S2 D2
11.0.0.0/8 13.0.0.0/8
ITR ETR

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 Operations
Control 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 Operations
Control Plane Example – ETR Registration
Other 3/8 sites…
ALT ALT
65.1.1.1 66.2.2.2
2.0.0.0/24 3.0.0.0/24
MR ALT ALT MS
ITR ETR
S1 10.0.0.0/8 12.0.0.0/8 D1

S2 D2
11.0.0.0/8 13.0.0.0/8
ITR ETR

12.0.0.2-> 66.2.2.2
LISP Map-Register [1]
(udp 4342)
3.0.0.0/8 3.0.0.0/8 SHA-1
[3] MS advertises [2]
ALT advertise
throughout into ALT
Including to BGP over GRE
Legend:
EIDs -> Green Map-Resolver
Locators -> Red
BGP-over-GRE
Physical link


LISP Operations
Control Plane Example – Map Request

ALT ALT
65.1.1.1 66.2.2.2
2.0.0.0/24 3.0.0.0/24
MR ALT ALT MS
ITR ETR
S1 10.0.0.0/8 12.0.0.0/8 D1

S2 D2
11.0.0.0/8 13.0.0.0/8
ITR ETR
2.0.0.2 -> 3.0.0.3
How do I get
DNS entry: to 3.0.0.3? [2] [3] [4]
11.0.0.1 -> 65.1.1.1 66.2.2.2 -> 12.0.0.2
D.abc.com A 3.0.0.3 LISP ECM 11.0.0.1 -> 3.0.0.3 LISP ECM
(udp 4342) Map-Request (udp 4342) [5]
(udp 4342)
11.0.0.1 -> 3.0.0.3 11.0.0.1 -> 3.0.0.3
Legend: nonce
Map-Request Map-Request
EIDs -> Green [1] (udp 4342) (udp 4342)
Locators -> Red nonce nonce
BGP-over-GRE
Physical link


LISP Operations
Control Plane Example – Map Reply

ALT ALT
65.1.1.1 66.2.2.2
2.0.0.0/24 3.0.0.0/24
MR ALT ALT MS
ITR ETR
S1 10.0.0.0/8 12.0.0.0/8 D1

S2 D2
11.0.0.0/8 13.0.0.0/8
ITR ETR

EID-prefix: 3.0.0.0/24 12.0.0.2 ->11.0.0.1
Mapping Locator-set: Map-Reply
[6]
(udp 4342)
Entry 12.0.0.2, priority: 1, weight: 50 (D1) nonce
Legend:
EIDs -> Green 13.0.0.2, priority: 1, weight: 50 (D2) 3.0.0.0/24
Locators -> Red 12.0.0.2 [1, 50]
13.0.0.2 [1, 50]
BGP-over-GRE
Physical link


LISP Operations
Locator Liveliness fix

 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


LISP Operations
Locator Liveliness

 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

S1
D1

S
S2 ? D2 D

 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


LISP Operations
Locator Liveliness
Solves
More
 Use the Routing Table when you can Scalability Cases
 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


LISP Overview
Locator Liveliness

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


LISP Operations
Interworking 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 Operations
LISP Components – Proxy ITR/ETR (PITR/PETR)

ALT ALT

MR ALT ALT MS
ITR ETR
S1 10.0.0.0/8 12.0.0.0/8 D1
PITR PETR

S2 D2
11.0.0.0/8 13.0.0.0/8
ITR ETR

PITR – Proxy ITR PETR – Proxy ETR
• Receives traffic from non-LISP sites; • Allows IPv6 LISP sites with IPv4 RLOCs
encapsulates traffic to LISP sites to reach IPv6 LISP sites that only have
• Advertises coarse-aggregate EID prefixes IPv6 RLOCs
• LISP sites see benefits of ingress TE • Allows LISP sites with uRPF restrictions
“day-one” to reach non-LISP sites


LISP Operations
Interworking Mechanisms – PITR Example
[1] [2]

65.1.1.1 - 2.1.1.1 65.9.1.1 - 66.1.1.1

65.1.1.1 - 2.1.1.1

Non-LISP EID
Non-LISP LISP
Site 2.1.0.0/16
Site Site
65.1.0.0/16 PITR
BGP Advertise:
2.0.0.0/8
Non-LISP PITR
Non-LISP LISP EID
Site BGP Advertise:
Site Site 2.2.0.0/16
65.2.0.0/16 2.0.0.0/8 65.0.0.0/12
66.0.0.0/12
PITR
BGP Advertise:
Non-LISP 2.0.0.0/8
Non-LISP Internet LISP EID
Site
Site [3] Site 2.3.0.0/16
65.3.0.0/16
65.1.1.1 - 2.1.1.1

Legend:
LISP Sites - EIDs
non-LISP Sites - RLOCs
Physical link


LISP Operations
Interworking Mechanisms – PETR Example
[2] [1]
65.10.1.1 - 66.1.1.1 ip lisp use-petr 65.10.1.1
65.1.1.1 - 2.1.1.1
65.1.1.1 - 2.1.1.1
Non-LISP EID
Non-LISP LISP
Site 2.1.0.0/16
65.1.0.0/16
Site PETR Site

Non-LISP PITR
Non-LISP LISP EID
Site BGP Advertise:
65.2.0.0/16 2.0.0.0/8 65.0.0.0/12
66.0.0.0/12
PITR
BGP Advertise:
Non-LISP 2.0.0.0/8
Non-LISP Internet LISP EID
Site
65.3.0.0/16
[3] [4]
65.1.1.1 - 2.1.1.1 65.9.2.1 - 66.1.1.1

65.1.1.1 - 2.1.1.1
Legend:
LISP Sites - EIDs
non-LISP Sites - RLOCs
Physical link


LISP Operations
Practical 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 Operations
Management of LISP

 Data Plane Management
Ping, traceroute of EIDs S1 D1

Ping, traceroute of RLOCs S2 D2

 Control Plane Management
LISP Internet Groper (LIG) (like “dig” for DNS)

 Device Management
show and debug commands
MIB coming…


LISP Operations
Management of LISP

 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


LISP Operations
Management of LISP
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 Example
Configurations

arin-mrms
MS/MR 217.41.88.65 simlo
xTR
128.223.156.222 ripe-mrms
dmm-isr
xTR MS/MR

128.223.156.139 153.16.40.0/24

153.16.21.0/24
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
!


LISP Example
Configurations

arin-mrms
MS/MR 217.41.88.65 simlo
xTR
128.223.156.222 ripe-mrms
dmm-isr
xTR MS/MR

128.223.156.139 153.16.40.0/24

153.16.21.0/24
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
!


LISP Example
Configurations

arin-mrms
MS/MR 217.41.88.65 simlo
xTR
128.223.156.222 ripe-mrms
dmm-isr
xTR MS/MR

128.223.156.139 153.16.40.0/24

153.16.21.0/24
193.0.0.170
!
hostname arin-mrmr
!
---skip---
!
lisp site dmm-isr
hostname ripe-mrmr
eid-prefix 153.16.21.0/24 route-tag 1234567890
!
authentication-key 3 #%$^%##
---skip---
description dmm-isr
lisp site simlo
!
eid-prefix 153.16.40.0/24 route-tag 1234567890
---skip---
authentication-key 3 #%$^%##
description simlo
!
---skip---


LISP Example
Operations

arin-mrms
MS/MR 217.41.88.65 simlo
xTR
128.223.156.222 ripe-mrms
dmm-isr
xTR MS/MR

128.223.156.139 153.16.40.0/24

153.16.21.0/24
193.0.0.170
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# 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#


LISP Example
Operations

arin-mrms
MS/MR 217.41.88.65 simlo
xTR
128.223.156.222 ripe-mrms
dmm-isr
xTR MS/MR
dmm-isr# show ip lisp site dmm-isr
LISP Site Registration Information for VRF default
* = truncated IPv6 address
128.223.156.139 153.16.40.0/24
Site name: dmm-isr
153.16.21.0/24 Description: none configured
Allowed configured locators: any
193.0.0.170
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#


LISP Example
Operations

arin-mrms
MS/MR 217.41.88.65 simlo
xTR
128.223.156.222 ripe-mrms
dmm-isr
xTR MS/MR

128.223.156.139 153.16.40.0/24

153.16.21.0/24
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


128.223.156.222 00:00:02 up 1/100
dmm-isr#


LISP Example
Operations

arin-mrms
MS/MR 217.41.88.65 simlo
xTR
128.223.156.222 ripe-mrms
dmm-isr
xTR MS/MR

128.223.156.139 153.16.40.0/24

153.16.21.0/24
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


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#


LISP Example
Operations

arin-mrms
MS/MR 217.41.88.65 simlo
xTR
128.223.156.222 ripe-mrms
dmm-isr
xTR MS/MR

128.223.156.139 153.16.40.0/24

153.16.21.0/24
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 Cases
Enterprise Use Case 1 – Low OpEx Multi-Homing

 Active/active multi-homing
Low-OpEx switchover (no BGP)
 More efficient bandwidth use by site
Use all the bandwidth you pay for
Provider A Provider B
10.0.0.0/8 11.0.0.0/8
 New link revenue for ISP
At the benefit of keeping site‟s routes out
of their resources
 Decoupling addressing from ISP
S1 S2
Site has flexibility to change providers
2.0.0.0/8
Raises the bar for ISPs, better for
consumer sites


LISP Use Cases
Enterprise Use Case 2 – Dynamic Roaming and VPNs

Engineering is using
global PI addresses Boston
San Francisco

Engineering Marketing
Core is using global
2.1.0.0/16 10.2.0.0/16
PA addresses

Enterprise Core
65.0.0.0/8

Los Angeles New York

Engineering
Marketing
2.2.0.0/16
10.1.0.0/16
65.5.1.1 65.5.2.2

Marketing is using 2.2.0.0/16 -
Dallas
private addresses (65.4.1.1, 65.4.2.2)
(65.5.1.1, 65.5.2.2)
Engineering
Dynamic creation of a site is
2.2.0.0/16 An engineering site moves
done by simply registering
EID-to-RLOC mapping to the
Mapping Database System


LISP Use Cases
Service Provider Use Case 1 – Multi-Family Address Support

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

IPv6-only Site
IPv6-only Site

2610:d0:1::/48 2610:d0:2::/48
IPv4 Internet
Core
LISP Site LISP Site

PxTR
PxTR
Dual Stack Dual Stack
Dual-Stack ISP
240.1.0.0/16 65.4.0.0/16
2610:d0:1::/48 2001:1:2::/48

LISP Site Non-LISP Site

TCP-over-IPv6 Connection
dino-unix.lisp6.net ipv6.google.com


LISP Use Cases
Service Provider Use Case 2 – Multi-Family Address Support

 A possible cable company…
IPv6 core; They can‟t upgrade residential on IPv4

IPv4-only
Server Site
IPv6 Cable
Core Network
IPv4-only 2.1.0.0/16
Residential Site
LISP Site
192.168.1.0/24
PxTR
LISP Site PxTR
IPv4-only
Dual-Stack Region Server Site

65.4.0.0/16

Non-LISP Site

IPv6 path IPv4 path


LISP Use Cases
Data Center Use Case 1 – Virtual Machine Mobility

2.2.0.0/16 - A’

3.1.1.1/32 - A’
3.1.0.0/16 - A

Data Center

RLOC A RLOC A’

A A’
3.1.1.254/24 3.1.11.254/24 2.2.2.254/24 2.2.22.254/24

S1 S2 S3 S4
3.1.1.1/24 3.1.11.2/24 2.2.2.3/24 2.2.22.4/24

S1 moves

L3 Router LISP Router


LISP Use Cases
Data Center Use Case 2 – Load Balancing the SLBs

Array of Servers

VIPs

Array of SLBs
EIDs - RLOC-sets
ETR ETR ETR ETR

ITR ITR
ITR Data Center ITR
VIPs are EIDs

Internet

L3 Router LISP Router Any brand Server Load Balancer Servers


LISP Use Cases
LISP 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?


LISP Use Cases

This is a LISP site!

EID-prefix: 2001:xxxx:yyyy::1/128 wifi 64.0.0.1
Map-Server: 64.1.1.1

3G 65.0.0.1

Can set ingress packet policy!

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


LISP Use Cases

 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 Cases
LISP 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 Cases
LISP 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


LISP Initiatives
Standardization Status

Fall 2008 1st IETF WG
2nd BOF
San Francisco
Minneapolis IETF

2nd IETF WG
Oct 2006: 2007 Summer 2008 Stockholm
IAB Routing WS LISP in RRG 1st BOF
Dublin IETF 3rd IETF WG
Hiroshima

2006 2007 2008 2009 2010

Spring 2009: Fall 2010:
More Drafts IETF WG Completes
Jan 2007: June 2007: Fall 2007:
LISP-MS Beijing
First Drafts 2nd Set Drafts 3rd Set Drafts
LISP-LIG
Main LISP LISP-ALT LISP-IW
LISP-CONS
Summer 2009: Summer 2009:
LISP-NERD
LISP-MN Loc-Reach-Algs
Implemented

RRG Effort IETF Effort

LISP Initiatives
What’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] Available
Now!
− 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)
• External LISP Efforts
− More LISP!
– FreeBSD OpenLISP
http://gforge.info.ucl.ac.be/projects/openlisp/
– Open Source LIG Diagnostic Tool
http://www.github.com/davidmeyer/lig


LISP Initiatives
LISP Network – Goals for the LISP Network

 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 Initiatives
LISP Network – Gaining LISP management experience


Summary


10 fn tut3

Recomendados

Recomendados

Más contenido relacionado

Similar a 10 fn tut3

Similar a 10 fn tut3 (20)

Más de Scott Foster

Más de Scott Foster (20)

10 fn tut3