Mobility and Virtualization in the Data Center with … › c › dam › global › en_ca › assets › cisco...Agenda •Mobility and Virtualization in the Data Center •Introduction

© 2012 Cisco and/or its affiliates. All rights reserved. Cisco Connect 1 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Connect 1 1 © 2012 Cisco and/or its affiliates. All rights reserved.

Mobility and Virtualization in the Data Center with LISP and OTV BRKDCT-2131 Victor Moreno

Distinguished Engineer

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

Slides Identified with the Book Icon Are Provided for Your

Reference and Will Not Be Part of the Live Presentation

© 2012 Cisco and/or its affiliates. All rights reserved. Cisco Connect 3

Distributed Data Centers Building the Data Center Cloud

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

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

• Mobility and Virtualization in the Data Center







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”


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?


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?


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

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):


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


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

Basic LISP Configuration


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

Use-Cases DCI route optimization/mobility

Workload Portability to Cloud

Secure Multi-tenancy across organizations

Rapid IPv6 Deployment

Route scaling

Single Network Architecture Delivers:

VM 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

Agenda • Mobility and Virtualization in the Data Center



Host-Mobility





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

• 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

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

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

• 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

• 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

• 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

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.1.0/24 – Null0

10.2.0.2/32 – Local

Routing Table:

10.3.0.0/16 – Local

10.2.1.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 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


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.1.1.0 /24

1.1.1.1 2.2.2.1

A B C D

Routing Table:

10.2.1.0/24 – Local

10.1.1.0/24 – Null0

Routing Table:

10.2.1.0/24 – Local

10.1.1.0/24 – Null0

Routing Table:

10.1.1.0/24 – Local

Routing Table:

10.1.1.0/24 – Local

10.1.0.0/16 – RLOC A, B

10.1.1.8

LISP site

ITR

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

LISP Mobility Across LISP Sites

Installed by LISP to allow

Proxy-ARP functions when

moving 10.1.1.x workloads

here

10.2.1.0 /24


West-to-East

On-subnet Server-Server Traffic

• 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.1.1.8

A

10.1.1.9

X

B C D

10.1.1.0/24 10.2.1.0/24

West-DC

East-DC

LISP DC xTR

Z

Y

Y

10.1.1.8

A

10.1.1.9

X

B C D

10.1.1.0/24 10.2.1.0/24

East-to-West

BC 10.1.1.9 10.1.1.8 CB 10.1.1.8 10.1.1.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


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.1.1.0 /24 10.2.1.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




Agenda








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

• 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

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


Overlay Transport Virtualization (OTV) Simplifying LAN Extensions

• 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

• 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

• 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

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

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-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”


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

• 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

• 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




LISP Multi-Tenancy High Level View

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 + high scale segmentation integrated in a

single IP solution • IP based solution, transport independent • No Inter-AS complexity • 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

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 Virtualization Shared Model

46

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

47

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


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


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



Segmentation End-to-end LISP-VRF Integration

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)


Agenda








LISP Host-Mobility – Router Placement

• @ 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

• @ 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

• 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

• 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

• 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


Agenda






Stateful Services Considerations



Live Moves or Cold Moves

• 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

Services - Live Moves

Redirection of established flows:

- Extended Clusters

- Cluster or LISP based re-direction

Services – Cold Moves

LISP LISP

LAN Extension

LAN Extension

LAN Extension

LAN Extension

DC1 DC2

IP preservation Uniform Policies

LISP LISP

DC1 DC2

Established after the move

Established before the move


Cold Moves / Disaster Recovery Localized FW & SLB Clusters

• 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


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

LAN Extension

LAN Extension

LAN Extension

DC1 DC2

Extended cluster


SLB Virtual-IP (VIP) Failover

• 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:

XTR LISP registration/encap/decap

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

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

L3 Core

R1: 1st Hop

Router

R3: 3rd Hop

Router (XTR)

“roamer”

(lands in a

foreign network)

R2: 2nd Hop

Router

(FW)

Dynam

ic r

oute

s

LISP encap/decap

LISP signaling

Move Detection

Host route injection

Default GWY proxy


LISP-MH ESM host-mobility w/o host routes

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

Map-Notify

EID-Notify

1

2

2

3 4

5

5


LISP-MH ESM host-mobility Configuration

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>

L3 Core

LISP

encap/decap

R1:

1st Hop Router

R3: XTR

“roamer”

(lands in a

foreign network)

LISP

Registration lisp dynamic-eid foo

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

map-server <map-server-address>

eid-notify authentication-key <key-value> LISP

Notifications

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


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

LISP References


LISP References

79

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 Paper “Session Evaluation”

Give us your feedback and you could win

1 of 2 fabulous prizes in a random draw.

Complete and return your paper

evaluation form to the room attendant

as you leave this session.

Winners will be announced today.

You must be present to win!

..visit them at BOOTH# 100

http://www.google.com/aclk?sa=l&ai=CG2awSZxqUdmnIPKh6QGc2oHwAZDV48gCqLGXwTvI1sycSQgGEAMoA1Dburb5BGDJ1q6KpKTEEaAB3OuE_QPIAQeqBCNP0LNQhqdgW7cj9_QLmL6qjhzmt6ofFchKKiN01DpGJxLdTboFEwiblL75j8q2AhUrGjQKHR8zALrABQXKBQCgBiaAB4yU-wLgEsza__m9m6rV0QE&ei=SJxqUZvQF6u00AGf5oDQCw&sig=AOD64_3c0ay6iHU-GGkY5JlWB4p4X2vmXw&ctype=5&rct=j&frm=1&q=kobo+vox&sqi=2&ved=0CKUBEPMO&adurl=http://www.digitaldeliverydownloads.com/kobo-vox-ereader.html


Thank you.

Documents

Mobility and Virtualization in the Data Center with … › c › dam › global › en_ca › assets › cisco...Agenda •Mobility and Virtualization in the Data Center •Introduction