Mobility and Virtualization in the Data Center with LISP...

Mobility and Virtualization in the Data Center with LISP and OTV

BRKDCT-2131

Victor Moreno, Distinguished Engineer

© 2014 Cisco and/or its affiliates. All rights reserved. BRKDCT-2131 Cisco Public

Agenda

• Mobility and Virtualization in the Data Center

• Introduction to LISP

• LISP Data Center Use Cases

• LAN Extensions: OTV

• LISP + OTV Deployment Considerations

• Summary and Conclusion

3

Slides Identified with the Book Icon Are Provided for Your

Reference and Will Not Be Part of the Live Presentation


Distributed Data Centers • Building the Data Center Cloud

4

Distributed Data Center Goals

• Seamless workload mobility

• Distributed applications

• Pool and maximize global resources

• Business Continuity

Interconnect Challenges

• Complex operations

• Transport dependence

• IP subnets and mobility

• Failure containment

Geographically Disperse

Data Centers


Connecting Virtualized Data Centers

5

L2 Domain Elasticity: Inter-DC:

OTV/VPLS

Intra-DC:

vPC, FabricPath, FEX,

VXLAN

OTV

OTV

Location of compute resources is transparent to the user

VM-awareness: Port Profiles

OTV

OTV

OTV

IP Mobility: LISP

Multi-tenancy/segmentation: Segment-IDs in LISP, FabricPath and OTV

Storage Solutions & Partners: FCIP, Read/write Acceleration

EMC, NetApp

Network Services

Elasticity: ACE, GSS, ASA, VSG


Agenda







6


IP core

Device IPv4 or IPv6

Address Represents

Identity and Location

Today’s IP Behavior Loc/ID “Overloaded” Semantic

10.1.0.1 When the Device Moves, It Gets

a New IPv4 or IPv6 Address for

Its New Identity and Location 20.2.0.9

Device IPv4 or IPv6

Address Represents

Identity Only.

When the Device Moves, Keeps

Its IPv4 or IPv6 Address.

It Has the Same Identity

LISP Behavior Loc/ID “Split”

IP core

1.1.1.1

2.2.2.2

Only the Location Changes

10.1.0.1

10.1.0.1

Its Location Is Here!

Location Identity Separation Protocol • What do we mean by “Location” and “Identity”

7


Non-LISP

site

East-DC

LISP Site

IP Network

ETR

EID-to-RLOC mapping

5.1.1.1

5.3.3.3

1.1.1.1

5.2.2.2

10.3.0.0/24 10.2.0.0/24

West-DC

PITR

5.4.4.4

10.1.0.0/24

Non-LISP

site

ITR S

D

DNS Entry: D.abc.com A 10.2.0.1

1

10.1.0.1 -> 10.2.0.1

2

EID-prefix: 10.2.0.0/24

Locator-set:

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


Mapping

Entry

3

This Policy Controlled

by Destination Site

10.1.0.1 -> 10.2.0.1

1.1.1.1 -> 2.1.1.1

4

10.1.0.1 -> 10.2.0.1

5

2.1.1.1 2.1.2.1 3.1.1.1 3.1.2.1

A LISP Packet Walk • How does LISP operate?

8


Non-LISP

Site

East-DC

IP

Network ETR

EID-to-RLOC mapping

5.1.1.1

5.3.3.3

5.2.2.2

10.3.0.0/24 10.2.0.0/24

West-DC

PITR

4.4.4.4

Non-LISP

Site S

D

DNS Entry: D.abc.com A 10.2.0.1

1

192.3.0.1 -> 10.2.0.1

2

EID-Prefix: 10.2.0.0/24

Locator-Set:



Mapping

Entry

3

192.3.0.1 -> 10.2.0.1

4.4.4.4- > 2.1.2.1

4

192.3.0.1 -> 10.2.0.1

5

2.1.1.1 2.1.2.1 3.1.1.1 3.1.2.1

A LISP Packet Walk • How about Non-LISP Sites?

9

LISP Roles

• Tunnel Routers - xTRs

• Edge devices encap/decap

• Ingress/Egress Tunnel

Routers (ITR/ETR)

• Proxy Tunnel Routers - PxTR

• Coexistence between LISP

and non-LISP sites

• Ingress/Egress: PITR, PETR

• EID to RLOC Mapping DB

• RLOC to EID mappings

• Distributed across multiple

Map Servers (MS)

Address Spaces • EID = End-point Identifier

• Host IP or prefix

• RLOC = Routing Locator

• IP address of routers in the backbone

Prefix Next-hop w.x.y.1 e.f.g.h

x.y.w.2 e.f.g.h

z.q.r.5 e.f.g.h

z.q.r.5 e.f.g.h

Mapping

DB

ITR

ETR

Non-LISP

EID Space

EID Space

RLOC Space

EID RLOC a.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


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


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

ALT

PxTR

10

LISP Roles and Address Spaces • What are the Different Components Involved?


LISP Mapping Database • The Basics – Registration and Resolution

West-DC East-DC

X Z

Y

Y

10.2.0.2

10.2.0.0 /16 10.3.0.0/16

Map Server / Resolver: 5.1.1.1

2.1.1.1 2.1.2.1 3.1.1.1 3.1.2.1

LISP Site

ITR

10.2.0.0/16 -> (2.1.1.1, 2.1.2.1)

Database Mapping Entry (on ETR): 10.3.0.0/16 -> (3.1.1.1, 3.1.2.1) Database Mapping Entry (on ETR):

ETR ETR ETR ETR

Map-Reply

10.2.0.0/16 -> (2.1.1.1, 2.1.2.1)

10.2.0.0/16-> (2.1.1.1, 2.1.2.1)

Mapping Cache Entry (on ITR):

11


LISP Mapping Database • Node Resiliency/Clustering

West-DC East-DC

X Z

Y

Y

10.2.0.2

10.2.0.0 /16 10.3.0.0/16

Map Server: 5.1.1.1 Map Server: 5.2.2.2

LISP Site ITR

Mapping DB

Node Cluster

Map Resolver:9.9.9.9 (Anycast)

10.2.0.0/16 -> (2.1.1.1, 2.1.2.1)

Database Mapping Entry (on ETR): 10.3.0.0/16 -> (3.1.1.1, 3.1.2.1) Database Mapping Entry (on ETR):

ETR ETR ETR ETR

Map-Reply 10.2.0.0/16 -> (2.1.1.1, 2.1.2.1)

No Synchronization Protocol Between Map

Servers;

ETRs Must Register with All Map Servers

Individually;

ITRs anycast Map Requests 10.2.0.0/16-> (2.1.1.1, 2.1.2.1)

Mapping Cache Entry (on ITR):

2.1.1.1 2.1.2.1 3.1.1.1 3.1.2.1

12

West-DC East-DC

Non-LISP Sites

PITR LISP Site

IP Network

EID RLOC LISP Encap/Decap

ITR

Mapping DB

5.1.1.1

5.3.3.3

1.1.1.1

10.2.0.0/24

5.2.2.2

ETR

2.1.1.1 2.1.2.1

Branch Routers

ip lisp itr-etr

ip lisp ITR map-resolver 5.3.3.3

DC Aggregation Routers

ip lisp itr-etr

ip lisp database-mapping 10.2.0.0/24 2.1.1.1 p1 w50

ip lisp database-mapping 10.2.0.0/24 2.1.2.1 p1 w50

ip lisp ETR map-server 5.1.1.1 key s3cr3t

ip lisp ETR map-server 5.2.2.2 key s3cr3t

Border Routers Between Backbones

ip lisp proxy-itr

ip lisp ITR map-resolver 5.3.3.3

Servers

ip lisp map-resolver

ip lisp map-server

lisp site west-DC

authentication-key 0 s3cr3t

eid-prefix 10.2.0.0/24

Usually Devices Will Be Configured as ITRs and ETRs to Handle Traffic in Both Directions; We Illustrate Only One Direction for Simplicity

13

Basic LISP Configuration


Location ID/Separation Protocol(LISP) Next Generation Networking Architecture

14

Use-Cases DCI route optimization/mobility

Workload Portability to Cloud

Secure Multi-tenancy across organizations

Rapid IPv6 Deployment

Route scaling

Single Network Architecture Delivers:

Host Mobility (topology independent addressing)

Security: VPNs/Multi-tenancy

Route Scalability (on demand routing)

IPv6 enablement,

Routing Policy simplification

Benefits

Services integrated in a single architecture

Services can be offered across organizational boundaries (multiple providers)

Very large scale

Open model to integrate with cloud orchestrators

Making the Network Cloud-Ready


IPv6 Transition Support

v6-over-v4, v6-over-v6

v4-over-v6, v4-over-v4

IPv4

Internet

IPv6

Internet

v6

v6 v4 v6

LISP

Router LISP

Router

v6

Services

Efficient Multi-Homing

IP Portability

Ingress Traffic Engineering without BGP

LISP

Routers

LISP

Site

Internet

Host-Mobility

Cloud / Layer 3 VM moves

Segmentation

West-DC East-DC

LISP Site

IP Network

Multi-Tenancy and VPNs

Reduced CapEx/OpEx

Large scale Segmentation

West-DC East-DC

LISP Site

IP Network

LISP Use Cases

15


Agenda




– Host-Mobility




16


Moving vs. Distributing Workloads • Why do we really need LAN Extensions?

17

• Move workloads with IP mobility solutions: LISP Host Mobility – IP preservation is the real requirement (LAN extensions not mandatory)

• Distribute workloads with LAN extensions – Application High Availability with Distributed Clusters

Hypervisor Hypervisor

IP Network

Moving Workloads

Hypervisor Control Traffic (routable)

OS

OS

OS

Distributed App (GeoCluster)

LAN Extension (OTV)

Non-IP application traffic

(heartbeats)


LISP Host-Mobility

18

Needs:

• Global IP-Mobility across subnets

• Optimized routing across extended subnet sites

LISP Solution: • Automated move detection on XTRs

• Dynamically update EID-to-RLOC mappings

• Traffic Redirection on ITRs or PITRs

Benefits: • Direct Path (no triangulation)

• Connections maintained across move

• No routing re-convergence

• No DNS updates required

• Transparent to the hosts

• Global Scalability (cloud bursting)

• IPv4/IPv6 Support

West-DC East-DC

Non-LISP Sites

PXTR LISP Site

IP Network


XTR

LAN Extensions

Mapping DB

LISP-VM (XTR)


IP Mobility Across Subnets

Disaster Recovery

Cloud Bursting

Host-Mobility Scenarios

19

Routing for Extended Subnets

Active-Active Data Centers

Distributed Clusters

Moves With LAN Extension

West-DC East-DC

Non-LISP

Site

IP Network

Mapping DB

LISP-VM (XTR)

LAN Extension

LISP Site

XTR

Application Members Distributed (Broadcasts across sites)

Moves Without LAN Extension

West-DC East-DC

LISP Site

Internet or

Shared WAN

XTR

Mapping DB DR Location or

Cloud Provider

DC

LISP-VM (XTR)

Application Members in One Location


LISP Host-Mobility – Move Detection • Monitor the source of Received Traffic

20

• The new xTR checks the source of received traffic

• Configured dynamic-EIDs define which prefixes may roam

West-DC East-DC

LISP-VM (xTR)

X Z

Y

Y

Mapping DB

10.2.0.2

10.2.0.0 /16 10.3.0.0/16

5.1.1.1 5.2.2.2

lisp dynamic-eid roamer

database-mapping 10.2.0.0/24 <RLOC-C> p1 w50

database-mapping 10.2.0.0/24 <RLOC-D> p1 w50

map-server 5.1.1.1 key abcd

interface vlan 100

lisp mobility roamer

A B C D

Received a Packet …

… It’s from a “New” Host

… It’s in the Dynamic-EID Allowed Range

…It’s a Move!

Register the /32 with LISP


LISP Host-Mobility – Traffic Redirection • Update Location Mappings for the Host System Wide

21

• When a host move is detected, updates are triggered: – The host-to-location mapping in the Database is updated to reflect the new location

– The old ETR is notified of the move – ITRs are notified to update their Map-caches

• Ingress routers (ITRs or PITRs) now send traffic to the new location

West-DC East-DC

LISP-VM (xTR)

X Z

Y

Y

Mapping DB

10.2.0.2

10.2.0.0 /16 10.3.0.0 /16

A B C D

LISP Site xTR

10.2.0.0/16 – RLOC A, B

10.2.0.2/32 – RLOC C, D

Host Mobility without LAN extensions


LISP Host-Mobility – First Hop Routing • No LAN Extension

23

• SVI (Interface VLAN x) and HSRP configured as usual

– Consistent GWY-MAC configured across all dynamic subnets

• The lisp mobility <dyn-eid-map> command enables proxy-arp functionality on the SVI

– The LISP-VM router services first hop routing requests for both local and roaming subnets

• Moving hosts always talk to a local gateway with the same MAC

West-DC East-DC

LISP-VM (xTR)

A B C D

HSRP

ARP

GWY-MAC

HSRP

ARP

GWY-MAC

interface Ethernet2/4

ip address 10.1.0.6/24


(ip proxy-arp

hsrp 101

mac-address 0000.0e1d.010c

ip 10.2.0.1

interface vlan 100



( ip proxy-arp)

hsrp 101


ip 10.2.0.1

interface vlan 200



(ip proxy-arp

hsrp 201


ip 10.3..0.1

interface vlan 100



(ip proxy-arp)

hsrp 201


ip 10.3.0.1

10.2.0.0 /24 10.3.0.0 /24

10.2.0.2

HSRP Active

HSRP Active


Host-Mobility and Multi-homing • ETR Updates – Across LISP Sites

24

West-DC East-DC

X

Y

Y

Mapping DB

10.2.0.2

10.2.0.0 /16 10.3.0.0 /16

5.1.1.1 5.2.2.2

A B C D

Routing Table:

10.3.0.0/16 – Local

10.2.0.0/24 – Null0

10.2.0.2/32 – Local

Routing Table:

10.3.0.0/16 – Local

10.2.0.0/24 – Null0

10.2.0.2/32 – Local

Map-Notify

10.2.0.2/32 <C,D>

1

Routing Table:

10.2.0.0/16 – Local

10.2.0.2/32 – Null0

Routing Table:

10.2.0.0/16 – Local

10.2.0.2/32 – Null0

Map-Notify

10.2.0.2/32 <C,D>

Map-Register

10.2.0.2/32 <C,D>

10.2.0.0/16 – RLOC A, B

10.2.0.2/32 – RLOC C, D

3

7 5

9

2

4

6

8

10

Map-Notify

10.2.0.2/32 <C,D>

Null0 host routes indicate the host is “away”


Refreshing the Map Caches

25

1. ITRs and PITRs with cached mappings continue to send traffic to the old locators

1. The old xTR knows the host has moved (Null0 route)

2. Old xTR sends Solicit Map Request (SMR) messages to any encapsulators sending traffic to the moved host

3. The ITR then initiates a new map request process

4. An updated map-reply is issued from the new location

5. The ITR Map Cache is updated

• Traffic is now re-directed

• SMRs are an important integrity measure to avoid unsolicited map responses and spoofing

West-DC East-DC

LISP-VM (xTR)

X Z

Y

Y

Mapping DB

10.2.0.2

10.2.0.0 /16 10.3.0.0 /16

A B C D

LISP site

ITR

10.2.0.2/32 – RLOC C,D

Map Cache @ ITR

10.2.0.0/16 – RLOC A,B


LISP Mobility Across LISP Sites

• Client-server communication established without the need to discover the • workloads in the “home subnet” in West-DC

West-DC East-DC

X Y

Mapping DB

10.2.0.0 /24

1.1.1.1 2.2.2.1

A B C D

Routing Table:

10.3.0.0/24 – Local

10.2.0.0/24 – Null0

Routing Table:

10.3.0.0/24 – Local

10.2.0.0/24 – Null0

Routing Table:

10.2.0.0/24 – Local

Routing Table:

10.2.0.0/24 – Local

10.2.0.0/16 – RLOC A, B

10.2.0.8

LISP site

ITR

Map Cache @ ITR 10.2.0.0/16 – RLOC A,B

Installed by LISP to allow

Proxy-ARP functions when

moving 10.2.0.x workloads

here

10.3.0.0 /24

26


West-to-East

On-subnet Server-Server Traffic

27

• Y ARPs for X, /24 Null0 entry for the ‘home subnet’ triggers proxy-ARP on East DC xTRs to ensure traffic is steered there

• Note: assumption is that ARP cache on Y is refreshed after the move

• Traffic to X is LISP encapsulated

• X ARPs for Y, /32 Null0 entry for Y triggers proxy-ARP on West-DC xTRs to ensure traffic is steered there

–Note: entry for Y in X ARP cache is cleared by GARP message originated by West-DC XTRs

• Traffic to Y is LISP encapsulated

West-DC

East-DC

LISP DC xTR

Z

Y

Y

10.2.0.8

A

10.2.0.9

X

B C D

10.2.0.0/24 10.3.0.0/24

West-DC

East-DC

LISP DC xTR

Z

Y

Y

10.2.0.8

A

10.2.0.9

X

B C D

10.2.0.0/24 10.3.0.0/24

East-to-West

BC 10.2.0.9 10.2.0.8 CB 10.2.0.8 10.2.0.9


West-DC East-DC

LISP-VM (xTR)

X Z Y

A B C D

ip lisp ITR-ETR

ip lisp database-mapping 10.2.0.0/16 <RLOC-A>

ip lisp database-mapping 10.2.0.0/16 <RLOC-B>


database-mapping 10.2.0.0/24 <RLOC-A>

database-mapping 10.2.0.0/24 <RLOC-B>



map-notify-group 239.1.1.1

interface vlan 100

ip address 10.2.0.10 /16


(ip proxy-arp)

hsrp 101


ip 10.2.0.1

Mapping DB

ip lisp ITR-ETR

ip lisp database-mapping 10.3.0.0/16 <RLOC-C>

ip lisp database-mapping 10.3.0.0/16 <RLOC-D>


database-mapping 10.2.0.0/24 <RLOC-C>

database-mapping 10.2.0.0/24 <RLOC-D>




interface vlan 100

ip address 10.3.0.11 /16


(ip proxy-arp)

hsrp 201


ip 10.3.0.1

10.2.0.0 /16 10.3.0.0 /16

LISP Host-Mobility Configuration • Without LAN Extensions

28


MS/MR Deployment across LISP Sites Recommended Option: co-locate MS/MR functionality on the DC xTR (one per DC site)

LISP site

MS/MR in

West-DC MS/MR in

East-DC

West-DC East-DC

X Z Y

10.2.0.0 /24 10.3.0.0 /24

A B C D

10.10.1.0 /24


ip lisp map-server

lisp site BRANCH_1

eid-prefix 10.10.10.0/24

authentication-key abcd

lisp site West-DC

eid-prefix 10.1.0.0/16 accept-more-specifics


lisp site East-DC




ip lisp map-server

lisp site BRANCH_1

eid-prefix 10.10.1.0/24


lisp site West-DC



lisp site East-DC



29


Agenda







30


Moving vs. Distributing Workloads • Why do we really need LAN Extensions?

31

• Move workloads with IP mobility solutions: LISP Host Mobility – IP preservation is the real requirement (LAN extensions not mandatory)

• Distribute workloads with LAN extensions – Application High Availability with Distributed Clusters


IP Network

Moving Workloads

Hypervisor Control Traffic (routable)

OS OS OS

Distributed App (GeoCluster)

LAN Extension (OTV)

Non-IP application traffic

(heartbeats)


LAN Extensions Evolution • From Circuits to Packets

32

Full mesh of circuits (pseudo-wires)

MAC learning based on flooding

Failure propagation

Limited information

Operationally Challenging Loop prevention and multi-homing must be provided separately

Packet switched connectivity

MAC learning by control protocol

Failure containment

Rich information

Operational simplification Automatic loop prevention & multi-homing

B A C D B A C D

L2

L3

DC-

1

DC-

2

Circuits + Data Plane Flooding Packet Switching + Control Protocol

B A C D B A C D

L2

L3

DC-

1

DC-

2

Traditional L2 VPNs MAC Routing


Transport

Infrastructure

OTV OTV OTV OTV

MAC TABLE

VLAN MAC IF

100 MAC 1 Eth 2

100 MAC 2 Eth 1

100 MAC 3 IP B

100 MAC 4 IP B

MAC 1 MAC 3

IP A IP B MAC 1 MAC 3

MAC TABLE

VLAN MAC IF

100 MAC 1 IP A

100 MAC 2 IP A

100 MAC 3 Eth 3

100 MAC 4 Eth 4

Layer 2

Lookup

5 IP A IP B MAC 1 MAC 3 MAC 1 MAC 3 Layer 2

Lookup

1 Encap

2 Decap

4

MAC 1 MAC 3 West

Site MAC 1 MAC 3

East

Site

1. Layer 2 lookup on the destination MAC.

MAC 3 is reachable through IP B

2. The Edge Device encapsulates the frame

3. The transport delivers the packet to the

Edge Device on site East

4. The Edge Device on site East receives

and decapsulates the packet

5. Layer 2 lookup on the original frame.

MAC 3 is a local MAC

6. The frame is delivered to the destination

3

6

IP A IP B

OTV Data Plane

33


West

OTV

Building the MAC Tables

• OTV proactively advertises MAC reachability (control-plane learning)

• MAC addresses advertised in the background once OTV has been configured

• IS-IS is the OTV Control Protocol running between the Edge Devices

• No specific configuration is required

The OTV Control Plane

IP A IP B

IP C

East

South

MAC Addresses

Advertisements OTV

OTV

34


Overlay Transport Virtualization (OTV) • Simplifying LAN Extensions

35

• Ethernet LAN Extension over any Network – Works over dark fiber, MPLS, or IP – Multi-data center scalability

• Simplified Configuration & Operation – Seamless overlay - No network re-design – Single touch site configuration

• High Resiliency – Failure domain isolation – Seamless Multi-homing

• Maximizes available bandwidth – Automated multi-pathing – Optimal multicast replication

Many Physical Sites –

One Logical Data Center

Any Workload, Anytime, Anywhere

Unleashing the Full Potential of Compute Virtualization


Ingress Routing Challenge in DCI • Extending Subnets Creates a Routing Challenge

36

• A subnet traditionally implies location

• Yet we use LAN extensions to stretch subnets across locations

– Location semantics of subnets are lost

• Traditional routing relies on the location semantics of the subnet

– Can’t tell if a server is at the East or West location of the subnet

• More granular (host level) information is required

– LISP provides host level location semantics

West-DC East-DC

IP Network

LAN Extension

LISP site

XTR

Host Mobility in Extended Subnets


LISP Host-Mobility – First Hop Routing • With Extended Subnets

38

• Consistent GWY-IP and GWY-MAC configured across all sites

– Consistent HSRP group number across sites consistent GWY-MAC

• Servers can move anywhere and always talk to a local gateway with the same IP/MAC

West-DC East-DC

LISP-VM (xTR)

A B C D

HSRP

ARP

GWY-MAC

HSRP

ARP

GWY-MAC

HSRP Active

HSRP Active

10.2.0.0 /24 10.2.0.0 /24

LAN Ext.

interface Ethernet2/4



lisp extended-subnet-mode

hsrp 101

ip 10.2.0.1

interface vlan 100




hsrp 101

ip 10.2.0.1

interface vlan 200




hsrp 101

ip 10.2.0.1

interface vlan 100




hsrp 101

ip 10.2.0.1


Host-Mobility and Multi-homing • ETR updates – Extended Subnets

39

West-DC East-DC

X

Y

Y

Mapping DB

10.2.0.2

10.2.0.0 /16 10.2.0.0 /16

5.1.1.1 5.2.2.2

A B C D

Routing Table: 10.2.0.0/16 – Local 10.2.0.0/24 – Null0 10.2.0.2/32 – Local

Routing Table: 10.2.0.0/16 – Local 10.2.0.0/24 – Null0 10.2.0.2/32 – Local

Map-Notify 10.2.0.2/32 <C,D>

Routing Table: 10.2.0.0/16 – Local 10.2.0.0/24 – Null0 10.2.0.2/32 – Null0

Routing Table: 10.2.0.0/16 – Local 10.2.0.0/24 – Null0 10.2.0.2/32 – Null0

Map-Register 10.2.0.2/32 <C,D>

10.2.0.0/16 – RLOC A, B 10.2.0.2/32 – RLOC C, D

3

5

3

2 4

6

4

Map-Notify 10.2.0.2/32 <C,D>

OTV

4

1

10.2.0.0 /24 is the dyn-EID

Null0 host routes indicate the host is “away”


Refreshing the Map Caches

40

1. ITRs and PITRs with cached mappings continue to send traffic to the old locators

1. The old xTR knows the host has moved (Null0 route)

2. Old xTR sends Solicit Map Request (SMR) messages to any encapsulators sending traffic to the moved host

3. The ITR then initiates a new map request process

4. An updated map-reply is issued from the new location

5. The ITR Map Cache is updated

• Traffic is now re-directed

• SMRs are an important integrity measure to avoid unsolicited map responses and spoofing

West-DC East-DC

LISP-VM (xTR)

X Z

Y

Y

Mapping DB

10.2.0.2

10.2.0.0 /16 10.2.0.0 /16

A B C D

LISP site

ITR

10.2.0.2/32 – RLOC C,D

Map Cache @ ITR

10.2.0.3/32 – RLOC A,B

10.2.0.2/32 – RLOC A,B

OTV


West-DC

East-DC

LISP DC xTR

Z

Y

Y

10.2.0.8

A

10.2.0.9

X

B C D

10.2.0.0/24 10.2.0.0/24

LAN Ext.

Server to Server Intra-subnet flows

• Live moves and cluster member dispersion

• Traffic flows in both E-W and W-E directions leverage LAN Extension (LISP does not come into the picture since traffic is handled at Layer 2)

• Link-local-multicast handled by the LAN Extension

10.2.0.9 10.2.0.8

10.2.0.8 10.2.0.9

41


West-DC East-DC

LISP-VM (xTR)

X Z Y

10.2.0.0/16

1.1.1.1 2.2.2.2

A B C D

LAN Ext.

ip lisp ITR-ETR




database-mapping 10.2.0.0/24 <RLOC-A> …




map-notify-group 239.10.10.10 interface vlan 100

ip address 10.2.0.10 /16

lisp mobility roamer lisp extended-subnet-mode hsrp 101

ip 10.2.0.1

Mapping DB

ip lisp ITR-ETR








map-notify-group 239.10.10.10 interface vlan 100

ip address 10.2.0.11 /16

lisp mobility roamer lisp extended-subnet-mode hsrp 101

ip 10.2.0.1

LISP VM-Mobility Configuration • With Extended Subnets “extended-subnet-mode”

42


Off-subnet Client-Server Traffic • All Off-Subnet/Off-Site Traffic Is LISP Encapsulated

43

• Clients (192.168.0.1 & 192.168.2.1 communicate with Server 10.2.0.2

• Client-server traffic is LISP encapsulated at the ITRs or PITRs – Client-to-server:

• to ETRs C or D

– Server-to-client: • to ETR (F) for LISP sites

• to PETR (G) for non-LISP sites

• Server-Server off-subnet traffic across sites is also LISP encapsulated

West-DC East-DC

LISP-VM (xTR)

X

Y

Y

Mapping DB

10.2.0.2

10.2.0.0 /16 10.3.0.0 /16

A B C D

LISP Site xTR

F

CLIENT

10.1.0.1

Non-LISP Sites

PxTR G

CLIENT

192.168.2.1

192.168.2.1 10.2.0.2

10.1.0.1 10.2.0.2

10.1.0.1 10.2.0.2

192.168.2.1 10.2.0.2

FC 10.1.0.1 10.2.0.2

GD 192.168.2.1 10.2.0.2


On-subnet Server-Server Traffic • On Subnet Traffic Across L3 Boundaries

44

• Live moves and cluster member dispersion

• Traffic between X & Y uses the LAN Extension

• Link-local-multicast handled by the LAN Extension

• Cold moves, no application dispersion

• X- Y traffic is sent to the LISP-VM router & LISP encapsulated

• Need LAN extensions for link-local multicast traffic

With LAN Extension Without LAN Extensions

West-DC

East-DC

LISP-VM (xTR)

Z

Y

Y

10.2.0.2

A

10.2.0.0/16

LAN Ext.

B C D

10.2.0.3 10.2.0.2

West-DC

East-DC

LISP-VM (xTR)

Z

Y

Y

10.2.0.2

A

10.2.0.3

X

Mapping DB

B C D

BC 10.2.0.3 10.2.0.2

10.2.0.0/16 10.3.0.0/16

10.2.0.3

X


Agenda





– Multi-Tenancy



45


LISP Multi-Tenancy • High Level View

46

Needs:

• Integrated Segmentation • Ease of operations • Global Scale and interoperability

LISP Solution:

• Traffic (control & data) is “colored” (tagged) with an instance-ID • Mappings are also “colored” in DB and caches • On xTRs use VRFs as map cache contexts

Benefits:

• Very high scale tenant segmentation • Distributed/on-demand/no-adjacencies

• Global mobility • IP based solution, transport independent • Overlay solution is transparent to the core

West-DC East-DC

Non-

LISP

Sites PxTR LISP Site

IP Network


xTR

xTR

Mapping DB

Instance IP Location

Red A East

Blue A West

Yellow C (Move) East West


Network Virtualization in LISP • LISP Multi-tenancy

47

Virtualized Map Cache (xTRs):

• Mappings cached in different VRFs per instance-id

• Interoperable with other VRF features/solutions

“Colored” Traffic: • Instance-ID tag in LISP data header • Instance-ID encoded in LISP control packets

Instance EID IP Location

Green A East

Blue A West

Yellow C East West

Virtualized Mapping Service:

EID entries with instance-id semantics

Control packets also contain instance-id semantics

GD | Instance1 1.1.0.1 10.2.0.2

GE | Instance2 1.1.0.1 10.2.0.2

GF | Instance3 1.1.0.1 10.2.0.2

To MPLS VPNs, VRF-lite or separate

networks To LISP

“Colored” Map

Requests/Replies

Single RLOC space shared by multiple instances


LISP Multi-Tenancy • Two Modes

48

Shared Mode Parallel Mode

Multiple EID VRFs

All EID VRFs map to one shared RLOC VRF

EID space is virtualized

RLOC space not virtualized

Multiple RLOC VRFs run in “parallel”

EID VRFs map to different RLOC VRFs

RLOC and EID spaces are virtualized

EID RLOC EID RLOC


LISP Virtualization • Shared Model

49

Shared Model – at the device level

- Multiple EID-prefixes are allocated privately using VRFs

- EID lookups are in the VRF associated with an Instance-ID

- All RLOC lookups are in a single table – default

- The Mapping System is part of the locator address space and is shared

• Single RLOC namespace • Default table or RLOC VRF

To RLOC namespace

To VPNs (MPLS, 802.1Q,

VRF-Lite, or separate networks)

• EID namespace, VRF Pink, IID 1

• EID namespace, VRF Blue, IID 2

Default

Pink

Blue


LISP Virtualization • Parallel Model

50

Parallel Model – at the device level

- Multiple EID-prefixes are allocated privately using VRFs

- EID lookups are in the VRF associated with an Instance-ID

- RLOC lookups are in the VRF associated with the locator table

- A Mapping System must be part of each locator address space

• RLOC uses Blue namespace

To VPNs (MPLS, 802.1Q,

VRF-Lite, or separate networks)

• EID namespace, VRF Pink, IID 1

• EID namespace, VRF Blue, IID 2

Default

• RLOC uses Pink namespace To VPNs (MPLS,

802.1Q, VRF-Lite, or separate networks)

Pink

Blue


West-DC East-DC

LISP-VM (xTR)

X Z Y

A B C D

vrf context BLUE

ip lisp ITR-ETR



lisp instance-id 102

ip lisp locator-vrf RED






interface vlan 100

vrf member BLUE

ip address 10.2.0.10 /16


hsrp 101

ip 10.2.0.1 Mapping DB

vrf context BLUE

ip lisp ITR-ETR




ip lisp locator-vrf RED






interface vlan 100

vrf member BLUE

ip address 10.3.0.11 /16


hsrp 101

ip 10.3.0.1

10.2.0.0 /16 10.3.0.0 /16

LISP Mobility in multiple VRFs Configuration • Shared mode LISP Virtualization

51


West-DC East-DC

LISP-VM (xTR)

X Z Y

A B C D

vrf context BLUE

ip lisp ITR-ETR




ip lisp locator-vrf BLUE






interface vlan 100

vrf member BLUE

ip address 10.2.0.10 /16


hsrp 101

ip 10.2.0.1 Mapping DB

vrf context BLUE

ip lisp ITR-ETR




ip lisp locator-vrf BLUE






interface vlan 100

vrf member BLUE

ip address 10.3.0.11 /16


hsrp 101

ip 10.3.0.1

10.2.0.0 /16 10.3.0.0 /16

LISP Mobility in multiple VRFs Configuration • Parallel mode LISP Virtualization

52


West-DC East-DC

LISP-VM (xTR)

X Z Y

A B C D Mapping DB

10.2.0.0 /16 10.3.0.0 /16

LISP Multi-tenant + Mobility Configuration


ip lisp map-server

lisp site BRANCH_1

eid-prefix 10.10.1.0/24


lisp site West-DC

eid-prefix 10.2.0.0/16 instance-id 102 accept-more-specifics


lisp site East-DC

eid-prefix 10.3.0.0/16


53


Segmentation End-to-end • LISP-VRF Integration

54

Enterprise Remote Site

B

Legend: EIDs -> Green

Locators -> Red LISP encap/decap

A

LISP Multi-Tenancy Instances 0,101,102 VRF-Lite / EVN (or MPLS VPN)

xTR11 xTR203 MS/MR Doctor Corp-A101

User

Finance Corp-A102 User

Global Corp-A User

Enterprise WAN

Enterprise Core servers

Global

VRF- Corp-A101

VRF-Corp-A102

Global

VRF- Corp-A101

VRF-Corp-A102

AB | Instance 101

AB | Instance 102

S D in Corp-A101

S D in Corp-A102

AB | Instance 0 S D in Global

Single RLOC space shared by multiple

instances

VRF-Lite / EVN (or MPLS VPN)


VRFs and LISP Multi-Tenancy • Routes and Mappings in VRFs

55

• On a PITR, routes can be advertized on different VRFs

• Leverage VRF enabled functionality:

– PBR VRF-select

– DHCP relay

– ExTRanet

– Imports/Exports

– IGP/BGP routing protocols

• Interoperate with existing VPN networks

To MPLS VPNs, VRF-Lite or Separate

Networks


Agenda







56


LISP Host-Mobility – XTR Router Placement

57

• @ Main Data Centers

• @ Disaster Recover facilities

• Ideally: First hop routers for the subnets in which the mobile hosts reside:

– Detect host moves

– Provide a consistent first hop presence

– Could also be the second hop

• Usually the Aggregation Switches in the Data Center

• Customer Managed West-DC

Internet / WAN

Backbone

Data Center

IP

Backbone


DC-Aggregation

DC-Access

East-DC

LISP Site

XTR

LISP-VM (XTR)

DR Location or

Cloud Provider

DC

LISP-VM (XTR)


OTV Router Placement

58

• @ Main Data Centers only

• Typically not required @ Disaster Recover facilities

• First hop routers for the subnets in which the mobile hosts reside:

– Connect to the VLANs to be extended

– Connect to the IP core

• Usually the Aggregation Switches in the Data Center

• Customer Managed West-DC

Internet / WAN

Backbone

Data

Center IP

Backbone


DC-Aggregation

DC-Access

East-DC

LISP Site

XTR

OTV

DR Location or

Cloud Provider

DC

OTV

LAN Extension to DR or Cloud

Facilities Is Usually Not

Required


West-DC

Data Center

IP

Backbone

DC-Aggregation

DC-Access

East-DC

PxTR Placement • Advertise DC Routes to Non-LISP Sites

59

• PXTR Ideally placed on path between non-LISP and LISP sites

• Aggregation points are optimal:

– Border routers between DC core and WAN

– Internet Routers

– Customer Routers at Co-location

– Provider routers (PXTR service)

• PITRs must be configured to inject routes into the non-LISP network

– Attract traffic from Non-LISP sites

– Encap and send to the Data Center

Internet / WAN

Backbone

Private PXTR


Non-LISP Sites Provider PXTR


West-DC

Data Center

IP

Backbone

East-DC

PxTR Placement • Advertise DC Routes to Non-LISP Sites

60

• PxTR on path between non-LISP and LISP sites (ideal) – 1. Border routers between DC core and WAN

• Internet Routers • Customer Routers at Co-location

– 2. Provider routers (PXTR service)

• PxTRs at LISP sites (tromboning) – 3. PXTR at Data Center edge

– 4. PxTR at regional hub branch

• PITRs must be configured to inject routes into the non-LISP network – Attract traffic from Non-LISP sites

– Encap and send to the Data Center

Internet / WAN

Backbone

Private PXTR


Non-LISP Sites

Provider PXTR

LISP Site

XTR/PXTR

PXTR

1

2

3

4

1

2

3 4


Map Server Placement • A Daemon on a Router

61

• The Map Server functionality can be enabled on any router

– BGP route-reflectors are a good analogy

– Off path is good, but not mandatory

• Distribute Map Servers across different locations

– Private Data Centers (Self managed)

– SP Data Centers/Cloud (SP Service)

• Map Server resiliency options:

– Clustered and distributed

– Distributed Database (DDT)

West-DC

Internet / WAN

Backbone

Data Center

IP

Backbone


Non-LISP

Sites

DC-Aggregation

DC-Access

East-DC

LISP Site

XTR

SP Mapping

Service

Private Map Server

Private Map Server


Option 2: push the MS/MR functionality on the OTV VDC (one per DC site)

MS/MR in

West DC

MS/MR in

West DC

Map Server Placement • Private DC deployment Options

62

Option 1: co-locate MS/MR functionality on the DC xTR (same as for LISP Across Subnet Mode)

MS/MR in

West DC

MS/MR in

West DC


West-DC

Data Center

IP

Backbone

DC-Aggregation

DC-Access

East-DC

Internet / WAN

Backbone

PXTR

LISP Site


XTR

Mapping DB

Non-LISP Sites

LISP-VM (XTR)

XTR: Branch Routers @ LISP Sites •Customer-managed/owned

•SP-Managed CE service

PXTR: Border Routers @ Transit Points •Customer backbone routers

•Customer router @ co-location

•SP provided router/service

Mapping Servers/Routers:

Distributed Across Data

Centers •Customer-managed/owned

•SP provided service

LISP-VM XTR: Aggregation Routers @

Data Center •Customer-managed/owned

OTV: Aggregation Routers @ Data

Center •Customer-managed/owned

OTV

Summary - Where to Deploy LISP and OTV • Roles and Places in the Network

63


Nexus 7000 OTV and LISP Co-Existence

64

• OTV must run in a separate VDC in order to support SVIs for IP routing on extended VLANs

• LISP runs in the Aggregation VDC, separate from OTV, just like any other IP routing service

Aggregation VDC

IP Services, SVIs, LISP

OTV VDC

OTV Services


Nexus 7000 Hardware Requirements

65

Interfaces

Encap/Decap

N7K-M132XP-12

N7K-M132XP-12L

Other M-Series F1 & F2E-Series Cards

(Proxy Mode)

N7K-M132XP-12

N7K-M132XP-12L ✗

Only F3, N7K-M132XP-12 and N7K-

M132XP-12L support LISP encapsulation

F1 and F2E-Series can use N7K-M132XP-12

Proxy mode to support LISP

Other M-series cards cannot operate in Proxy

mode, should be deployed in a separate VDC

Multi-hop mode can be leveraged if the first

hop is not lisp encap capable (M-series)


Agenda






– Stateful Services Considerations


66


Live Moves or Cold Moves

67

• Live (hot) Moves preserve existing connections and state – e.g. vMotion, Cluster failover – Requires synchronous storage and network policy replication Distance limitations

• Cold Moves bring machines down and back up elsewhere – e.g. Site Recovery Manager – No state preservation: less constrained by distances or services capabilities


IP Network

Moving Workloads

Hypervisor Control

Traffic (routable)

Mobility across PODs within a site or across different locations


Live Moves or Cold Moves

• IP preservation Uniform Policies

• Services – Cold Moves

• Redirection of established flows:

- Extended Clusters

- Cluster or LISP based re-direction

LISP LISP

DC1 DC2

LISP LISP

Established after the move

Established before the move

Services – Live Moves

DC1 DC2

68

LAN Extension


Cold Moves / Disaster Recovery • Localized FW & SLB Clusters

69

• Independent FW & SLB cluster in each location

– LAN extensions not required

• New state created after moves

– No state synchronization

• LISP steers traffic to different locations

• Disaster recovery

• Cold workload relocation

LISP LISP

DC1 DC2

SLB cluster SLB cluster

FW cluster FW cluster


ESX

Data Center 1

FWs in separated sites work independently

Stateless Active/Active scenario

FW in different sites are not sync’d

Policies have to be replicated between sites

No state information maintained between sites

VIP on ACE must be moved between independent pairs

Will drop previously established sessions after live workload move (i.e. vMotion)

Positioned for cold migration scenarios (like Disaster Recovery for example)

Layer 3 Core

Data Center 2

LISP site

ESX Workload/Server

Farm Moves

LISP and Services Integration Active/Standby Units Deployed in Each Site

VIP VIP

70


Live Moves • Extended Firewall Clusters – All Active

• FW cluster extended across locations – LAN extensions for heartbeats, state sync and

redirection within the cluster

• FW state is synchronized across all cluster members

• All members active

• LISP steers traffic to different locations – Flows existing prior to the move will be

redirected within the FW cluster (over the LAN extension)

– New flows will be instantiated on the FWs at the new site

LISP LISP

LAN Extension

DC1 DC2

Extended cluster

71


ESX

Data Center 1

FW and SLB stretched extended locations

LAN extensions for heartbeats & state sync

LISP steers traffic to Data Center 2 after Workload/Server Farm move

Sub-optimal traffic pattern

Not truly leveraging LISP inbound Path Optimization functionality advantages

Layer 3 Core

Data Center 2

LISP site

ESX Workload/Server

Farm Moves

LISP and Services Integration What about Stretching Services across Sites?

VIP VIP

72


SLB Virtual-IP (VIP) Failover

73

• VIP is active at one location at a time

• VIP location is advertised in LISP

• VIP may failover on failure or change active device on machine moves

– VIP becomes active at a new site

• VIP activity is detected by the VM-mobility logic

• VIP location is updated in LISP on failover

LISP

LAN Extension

LISP

LAN Extension

VIP VIP

DC1 DC2


Inserting Firewalls in routed mode • Traffic is Decapsulated Before Being Handed off to the FWs

• XTR is not the first hop router

• LISP host-mobility functionality is split to two places: – SG XTR LISP registration/encap/decap

– 1st Hop router Move detection, map notification to XTR, proxy default GWY

• The SG XTR LISP registers host mappings in the dynamic-eid range

L3 Core

R1: First Hop (FH)

R3: Site GWY

XTR (SG)

“roamer”

(lands in a

foreign network)

R2: FW (non-

LISP)

LIS

P M

essa

ge

s

LISP encap/decap

LISP signaling

Move Detection

Host route injection

Default GWY proxy

74

© 2014 Cisco and/or its affiliates. All rights reserved. BRKDCT-2131 Cisco Public 75

LISP-HM Multi-hop ESM

L3 Core

LISP

encap/decap

LISP

Registration/

Notifications L3 Core

LISP

encap/decap

“roamer”

(lands in a foreign

network)

Map-Register

EID-Notify

Map-Notify

Extended LAN (east-west traffic)

Map-Notify

EID-Notify

1

2

2

3 4

5


LISP-HM Multi-hop ESM Configuration

@FHR

lisp dynamic-eid foo

database-mapping <eid-prefix> <xtr-rloc> priority <p> weight <w>

eid-notify <xtr-address-1> key <key-value>…

eid-notify <xtr-address-n> key <key-value>

LISP

encap/decap

FHR

SG1

“roamer”

(lands in a foreign

network)

LISP

Registrations

@ SG

ip lisp itr-etr


database-mapping <eid-prefix> <xtr-rloc> priority <p> weight <w>

map-server <map-server-address>

eid-notify authentication-key <key-value>

LISP

Notifications

SGn

L3 Core


LISP Host-mobility IGP Assist (LISP HMIA)

L3 Core

R1: FHR

“roamer”

(lands in a foreign

network)

Dynamic Host Routes

Installed by LISP and

redistributed into the

IGP

• Host routing end to end

• LISP provides host mobility detection

• LISP provides signaling to guide IGP convergence

• The IGP propagates host routes received from LISP

• No LISP encapsulation involved


LISP-HM IGP Assist – ESM

L3 Core

“roamer”

(lands in a foreign

network)

Map-Notify

1

2

Host detection Install /32

lisp

interface

route

Remove /32

lisp

interface

route 2

Redistribut

e LISP

routes into

IGP

Redistribut

e LISP

routes into

IGP

3

Map-Notify 2

e2e host routing

LISP Signaling “assists” IGP convergence

No mapping infrastructure for ESM


LISP HM IGP Assist Configuration - ESM

@ FHR


database-mapping <eid-prefix> redistribute


…

router <favorite-routing-protocol> foo

redistribute lisp route-map <bar>

…

ip prefix-list <eid-list-name> seq 5 permit <eid-prefix> ge 32

route-map <bar> permit 10

match ip address <eid-list-name>

L3 Core

R1: FHR

“roamer”

(lands in a foreign

network)

Dynamic Host Routes



IGP


LISP-HM IGP Assist – ASM

L3 Core

“roamer”

(lands in a foreign

network)

Map-Notify

1

2

Host detection Install /32

lisp

interface

route

Remove /32

lisp

interface

route 2 4

Redistribut

e LISP

routes into

IGP

Redistribut

e LISP

routes into

IGP

3 Dyn-eid timeout

e2e host routing

Without LISP signaling: Blackhole period


LISP-HM IGP Assist – ASM

L3 Core

“roamer”

(lands in a foreign

network)

Map-Register

Map-Notify

Map-Notify

1

2 5

4

Map-Notify

Host detection

Map-Server

3

Install /32

lisp

interface

route

Remove /32

lisp

interface

route 2 5

Redistribut

e LISP

routes into

IGP

Redistribut

e LISP

routes into

IGP

e2e host routing

LISP Signaling “assists” IGP convergence


LISP HM IGP Assist Configuration - ASM @ FHR

ip lisp etr <<<< Must be ETR only


database-mapping <eid-prefix> redistribute

database-mapping <eid-prefix> rloc <rloc> p1 w50

map-server <ms-address> key <some-key>


…

router <favorite-routing-protocol> foo

redistribute lisp route-map <bar>

…

ip prefix-list <eid-list-name> seq 5 permit <eid-prefix> ge 32

route-map <bar> permit 10

match ip address <eid-list-name>

L3 Core

R1: FHR

“roamer”

(lands in a foreign

network)

Dynamic Host Routes



IGP

Summary and Conclusions


Summary and Conclusions

• LISP provides an effective solution for host mobility

• Some applications may require LAN extensions in combination with host mobility

• LISP consolidates many network services in one architecture:

– Mobility, network segmentation, traffic engineering

– Enhanced scalability

• Location Identity Separation opens many opportunities in the Data Center space

84


IPv4 Network

IPv6 Network

LISP is an Architecture…

IPv4 Core

1. Multihoming

2. IPv6 Transition

3. Virtualization/VPN

4. Mobility xTR

xTR

v6

v4

IPv6 Core

• Part of the LISP Solution Space…

LISP Host Mobility Support

85

LISP References


LISP References

87

LISP Information – Cisco LISP Site ……………………. http://lisp.cisco.com (IPv4 and IPv6)

– Cisco LISP Marketing Site ………... http://www.cisco.com/go/lisp/

– LISP Beta Network Site …………… http://www.lisp4.net or http://www.lisp6.net

– LISP DDT Root ……………………... http://www.ddt-root.org

– IETF LISP Working Group ……...… http://tools.ietf.org/wg/lisp/

LISP Mailing Lists – Cisco LISP Questions ……………… [email protected]

– IETF LISP Working Group ………… [email protected]

– LISP Interest (public) ………………. [email protected]

– LISPmob Questions ………………... [email protected]


Complete Your Online Session Evaluation

• Give us your feedback and you could win fabulous prizes. Winners announced daily.

• Complete your session evaluation through the Cisco Live mobile app or visit one of the interactive kiosks located throughout the convention center.

Don’t forget: Cisco Live sessions will be available for viewing on-demand after the event at CiscoLive.com/Online

88

https://www.ciscolive.com/online


Continue Your Education

• Demos in the Cisco Campus

• Walk-in Self-Paced Labs

• Table Topics

• Meet the Engineer 1:1 meetings

89

Mobility and Virtualization in the Data Center with LISP...

Documents

Transcript of Mobility and Virtualization in the Data Center with LISP...