an introduction to cisco otv (ios advantage webinar)

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

Cisco IOS Advantage Webinars Simplifying Data Center Interconnect with Overlay Transport Virtualization (OTV)

Peter Lam

Patrick Warichet

We’ll get started a few minutes past the top of the hour.

Note: you may not hear any audio until we get started.

© 2012 Cisco and/or its affiliates. All rights reserved. Cisco Public 2

Speakers

Peter Lam

Product Manager,

Network Operation System

Group (NOSTG)

[email protected]

Patrick Warichet

Technical Manager,

Network Operating System

Group (NOSTG)

[email protected]

Panelists

Peter Lam

Anoop Dawani

Mostafa Mansour

Suresh Katukam

mailto:[email protected]



• Submit questions in Q&A panel and send to “All Panelists”

Avoid CHAT window for better access to panelists

• For Webex audio, select COMMUNICATE > Join Audio Broadcast

• For Webex call back, click ALLOW Phone button at the bottom of Participants side panel

• Where can I get the presentation?

https://communities.cisco.com/docs/DOC-28415

Or send email to: [email protected]

• Please fill in Survey at end of event

• Join us on April 4 for our next IOS Advantage Webinar:

Network Automation Techniques Using Embedded Event Manager (EEM)



OTV General Overview

OTV Technical Details

LISP General Overview

LISP for Inter-DC Workload Mobility


Data Center Interconnect (DCI)

Many Physical Sites

One Logical Data Center

Complex operations

Transport dependent

Bandwidth management

Failure containment


O

V

Overlay - Independent of the Infrastructure

technology and services, flexible over various

inter-connect facilities

Transport - Transport services for Layer 2

and Layer 3 Ethernet and IP traffic

Virtualization - Provides virtual stateless

multi-access connections. Can be further

partitioned into VPNs, VRFs, VLANs

T

OTV delivers a virtual L2 transport over any L3 Infrastructure


• Seamless workload mobility

• Business Continuity

• Pool and maximize global

resources

• Distributed applications


• Applications (running in the VMs) use non-routable traffic

e.g. Node Discovery & Heartbeats in clustered Applications

• With Virtualization, application members may be distributed across Data-centers

• Moving and distributing application members across locations should not break the application

Hypervisor Hypervisor

Network

Application Traffic (Non Routable)

Node Discovery

Heartbeats

Hypervisor

Control Traffic


EoMPLS

VPLS

Dark Fiber


x2

Site A

Site B

Site C

MAC 1

propagation MAC 1

Traditional Layer 2 VPN technologies rely on flooding to propagate

MAC reachability

The flooding behavior causes failures to propagate to every site in the Layer

2 VPN

Our goal…

Providing layer 2 connectivity, yet restrict the reach of the unknown unicast

flooding domain in order to contain failures and preserve the resiliency


Before any learning can happen a full mesh of pseudo-wires/

tunnels must be in place

For N sites, there will be N*(N-1)/2 pseudo-wires. Complex to add and remove

sites

Head-end replication for multicast and broadcast. Sub-optimal BW utilization

Our goal… providing point-to-cloud provisioning and optimal bandwidth

utilization in order to reduce cost


L2 Site L2 Site L2 VPN

Active Active

Our goal… natively providing automatic detection of multi-homing without the need

of extending the STP domains, together with a more efficient load-balancing

• Requires additional protocols (BGP, ICC, EEM)

• STP often extended

• Malfunctions impact all sites


Full mesh of circuits (pseudo-wires)

MAC learning based on flooding

Tunnels and Pseudo-wires

Operationally Challenging

Loop prevention and multi-homing must be provided separately

Packet switched connectivity

MAC learning by control protocol

Dynamic Encapsulation

Operational simplification

Automatic loop prevention & multi-homing

B A C D

B A C D

L2

L3

Data

Center

II

Data

Center I

Circuits Packet

B A C D

B A C D

L2

L3

Data

Center

II

Data

Center I

Traditional L2 VPNs MAC Routing

+ Data Plane Flooding + Control Protocol Learning


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

6

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

Lookup

2 Encap

3

Decap

5

MAC 1 MAC 3 West

Site MAC 1

MAC 3 East

Site

4

7

IP A IP B

1


• OTV encapsulation adds 42 Bytes to the packet IP MTU size

Outer IP Header and OTV Shim Header in addition to original L2 Header stripped off of the .1Q header

• The outer OTV shim header contains information about the overlay (VLAN, overlay number)

• The 802.1Q header is removed from the original frame and the VLAN field copied over into the OTV shim header

Encapsulation

20B + 8B + 14B* = 42Byte of total overhead

6B 6B 2B 20B 8B

DMAC SMAC Ether

Type IP Header

Payload 4B

CRC OTV Shim

802.1Q DMAC SMAC

Ether

Type

802.1Q

14B*

Original L2 Frame

L2

Header

802.1Q header removed

* The 4Bytes of .1Q header have

already been removed


• No unknown unicast flooding

• Control Plane Learning with proactive MAC advertisement

• Background process with no specific configuration

• IS-IS used between OTV Edge Devices.

The OTV Control Plane

West

OTV

IP A IP B

IP C

East

South

MAC Addresses

Advertisements OTV

OTV


• Before any MAC address can be advertised the OTV Edge Devices must:

Discover each other

Build a neighbor relationship with each other

• Neighbor Relationship built over a transport infrastructure:

Multicast-enabled (all shipping releases)

Unicast-only (NX-OS with release 5.2 or higher)

Neighbor Discovery and Adjacency Formation


South

East West

OTV

OTV

OTV

VLAN MAC IF

100 MAC A IP A

100 MAC B IP A

100 MAC C IP A

VLAN MAC IF

100 MAC A IP A

100 MAC B IP A

100 MAC C IP A

VLAN MAC IF

100 MAC A e1/1

100 MAC B e1/1

100 MAC C e1/1

VLAN MAC IF

100 MAC A e1/1

100 MAC B e1/1

100 MAC C e1/1

Route (MAC) Advertisements (over Multicast Transport)

Update A

VLAN MAC IF

100 MAC A IP A

100 MAC B IP A

100 MAC C IP A

VLAN MAC IF

100 MAC A IP A

100 MAC B IP A

100 MAC C IP A

New MACs

learned in

OTV VLAN

Craft OTV

update with

new MACs

IP A G Update A

Update A

Update A

IP A G Update A

IP A G Update A

Update A IP A G Update A

Update A IP A G Update A

Encap Decap

Decap 1

2

3

4

5

5

6

6

VLAN MAC IF

100 MAC A IP A

100 MAC B IP A

100 MAC C IP A

7

7

Add MACs

learned

through OTV

Add MACs

learned

through OTV

MAC Table

MAC Table

MAC Table

Multicast-enabled

Transport


OTV over a Multicast Transport with NX-OS

• Minimal configuration required to get OTV up and running

West

OTV

IP A IP B

IP C

East

South

OTV

OTV

feature otv

otv site-vlan 99

interface Overlay1

description WEST-DC

otv join-interface e1/1

otv control-group 239.1.1.1

otv data-group 232.192.1.0/24

otv extend-vlan 100-150

feature otv

otv site-vlan 99

interface Overlay1

description EAST-DC

otv join-interface e1/1.10




feature otv

otv site-vlan 99

interface Overlay1

description SOUTH-DC

otv join-interface Po16




Activate the

OTV feature

Wan facing

Interface

VLAN

extended


OTV over a Multicast Transport with IOS-XE

• Minimal configuration required to get OTV up and running

West

OTV

IP A IP B

IP C

East

South

OTV

OTV

interface Overlay0

description WEST-DC

no ip address



otv join-interface TenGig0/0/0

otv vpn-name ASR1K-001

service instance 10 ethernet

encapsulation dot1q 10

bridge-domain 10

!

interface TenGig0/0/0

ip address 10.10.10.1 255.255.0.0

ip pim passive

ip igmp version 3

interface Overlay0

description EAST-DC

no ip address



otv join-interface TenGig0/0/0

otv vpn-name ASR1K-001

service instance 10 ethernet

encapsulation dot1q 10

bridge-domain 10

!

interface TenGig0/0/0

ip address 10.10.10.2 255.255.0.0

ip pim passive

ip igmp version 3

feature otv

otv site-vlan 99

interface Overlay1





otv extend-vlan 10


CLI Verification on NX-OS

Establishment of control plane adjacencies between OTV Edge Devices:

dc1-agg-7k1# show otv adjacency

Overlay Adjacency database

Overlay-Interface Overlay100 :

Hostname System-ID Dest Addr Up Time Adj-State

dc2-agg-7k1 001b.54c2.efc2 20.11.23.2 6d13h UP

dc1-agg-7k2 001b.54c2.e1c3 20.12.23.2 6d13h UP

dc3-ASR1K-1 5475.d098.2200 20.13.23.2 6d13h UP

Unicast MAC reachability information:

dc1-agg-7k1# show otv route

OTV Unicast MAC Routing Table For Overlay100

VLAN MAC-Address Metric Uptime Owner Next-hop(s)

---- -------------- ------ -------- --------- -----------

2001 0000.0c07.ac01 1 3d15h site Ethernet1/1

2001 0000.1641.d70e 1 3d15h site Ethernet1/2

2001 0000.49f3.88ff 42 2d22h overlay dc2-agg-7k1

2001 0000.49f3.8900 42 2d22h overlay dc2-agg-7k2 Remote Site

MAC

Local Site

MAC


CLI Verification on IOS-XE Verification of the Status on OTV edge interface and control plane adjacencies

dc3-ASR1K-1 #show otv adjacency

Overlay 100 Adjacency Database

Hostname System-ID Dest Addr Up Time State

dc2-agg-7k1 001b.54c2.efc2 20.11.23.2 6d13h UP

dc1-agg-7k2 001b.54c2.e1c3 20.12.23.2 6d13h UP

dc1-agg-7k1 001b.54c2.eed3 20.10.23.1 6d18h UP

Unicast MAC reachability information: dc3-ASR1K-1# show otv route

Codes: BD - Bridge-Domain, AD - Admin-Distance,

SI - Service Instance, * - Backup Route

OTV Unicast MAC Routing Table for Overlay100

Inst VLAN BD MAC Address AD Owner Next Hops(s)

-----------------------------------------------------------

0 10 10 0001.cafe.0001 50 ISIS dc2-agg-7k1

0 10 10 0000.1234.0001 40 BD Eng Gi0/2/0:SI10

Remote Site

MAC

Local Site

MAC

dc3-ASR1K-1 #show otv summary

OTV Configuration Information, Site Bridge-Domain: 10

Overlay VPN Name Control Group Data Group(s) Join Interface State

100 DCI-001 239.140.5.1 232.1.1.0/28 Te0/0/0 UP

Total Overlay(s): 1


Neighbor Discovery (Unicast-Only Transport)

The end result

Neighbor Discovery is automated by the “Adjacency Server”

All signaling must be replicated for each neighbor

Data traffic must also be replicated at the head-end

The mechanism

Edge Devices (EDs) register with an “Adjacency Server” ED

EDs receive a full list of Neighbors (oNL) from the AS

OTV hellos and updates are encapsulated in IP and unicast to each neighbor

West

OTV OTV Control Plane

IP A East

OTV

OTV Control Plane

IP B

Unicast-only

Transport

• Ideal for connecting two or three sites

• With a higher number of sites a multicast transport is the best choice

NX-OS

release 5.2

and above


Neighbor Discovery (Unicast-Only Transport)

• OTV “adjacency server” provides support over unicast core

• Adjacency server is a process that can run on any OTV edge device

• Advertises IP of each Edge Device (ED) to all other EDs (OTV neighbor list – oNL)

IP A

Site 1

Site 2 Site 3

Site 4 Site 5

Unicast-Only

Transport

IP B IP C

IP D IP E Adjacency

Server Mode

oNL

Site 1, IP A

Site 2, IP B

Site 3, IP C

Site 4, IP D

Site 5, IP E

* A redundant pair may be configured

NX-OS

release 5.2

and above


MAC Advertisements (Unicast-Only Transport)

• A single update needs to be created for each destination Edge Device present on the Overlay

• Same for the sites’ multicast and broadcast packets to be sent to the other sites

Core

IP A

West

East

3 New MACs are

learned on VLAN 100

Vlan 100 MAC A

Vlan 100 MAC B

Vlan 100 MAC C

South-East

VLAN MAC IF

100 MAC A IP A

100 MAC B IP A

100 MAC C IP A

4

OTV update is replicated

at the head-end

3

3

2

VLAN MAC IF

100 MAC A IP A

100 MAC B IP A

100 MAC C IP A

4

3 New MACs are

learned on VLAN 100

1

oNL

East, IP B

Sout-East, IP C

NX-OS

release 5.2

and above


West

OTV

OTV over an unicast-only transport

• Establishing a DCI has never been this simple

IP A IP B

IP C

East

South

OTV

OTV

feature otv

otv site-vlan 99

interface Overlay1

description WEST-DC

otv join-interface e1/1

otv adjacency-server local


feature otv

otv site-vlan 99

interface Overlay1

description EAST-DC

otv join-interface e1/1.10

otv adjacency-server 10.1.1.1


feature otv

otv site-vlan 99

interface Overlay1



otv adjacency-server 10.1.1.1


NX-OS

release 5.2

and above


L2

L3

OTV OTV

Site Independence

• OTV is site transparent: no changes to the STP topology

• Each site keeps its own STP domain

• This functionality is built-in into OTV and no additional configuration is required

• An Edge Device will send and receive BPDUs ONLY on the OTV Internal Interfaces

The BPDUs

stop here

The BPDUs

stop here


L2

L3

OTV OTV

No longer unknown unicast storms across the DCI

• No requirements to forward unknown unicast frames

• OTV does not forward unknown unicast frames to the overlay. This is achieved without any additional configuration

• The assumption here is that the end-points connected to the network are not silent or uni-directional

MAC TABLE

VLAN MAC IF

100 MAC 1 Eth1

100 MAC 2 IP B

- - -

MAC 1 MAC 3

No MAC 3 in the

MAC Table


ARP Neighbor-Discovery (ND) Cache

• An ARP cache is maintained by every OTV edge device and is populated by snooping ARP replies

• Initial ARP requests are broadcasted to all sites, but subsequent ARP requests are suppressed at the Edge Device and answered locally

• ARP traffic spanning multiple sites can thus be significantly reduced

Transport

Network

OTV

OTV

ARP Cache

MAC 1 IP A

MAC 2 IP B

ARP reply

2

First ARP

request (IP A)

1

Snoop & cache ARP reply

3

Subsequent ARP requests

(IP A)

4 ARP reply on behalf of

remote server (IP A)

5


• The detection of the multi-homing is fully automated and it does not require additional protocols and configuration

• The Edge Devices within a site discover each other over the “otv site-vlan”

• OTV elects one of the Edge Devices to be the Authoritative Edge Device (AED) for a subset of the extended VLANs

• The AED is responsible for:

MAC addresses advertisement for its VLANs

Forwarding its VLANs’ traffic inside and outside the site

OTV OTV

Internal peering for

AED election

AED


• All devices on a site must be configured with a common site-identifier

• The site-id information is included in the control plane

• Makes OTV multi-homing more robust and resilient to user configuration errors

Site Adjacency and Overlay Adjacency are now both leveraged for AED election

• An overlay will not come up until a site-id is configured

Warning: ISSU to 5.2 results in an overlay down condition until site-ids are manually configured

feature otv

otv site-identifier 0x1

otv site-vlan 99

Introducing OTV site-identifier

OTV OTV AED AED

Site Adjacency

Overlay Adjacency

NX-OS

release 5.2

and above

NX-OS

otv site-identifier 0x1

otv bridge-domain 99

IOS-XE


• Provides additional resiliency

• Avoid single point of failure of site-vlan going down

• Proactively inform neighbors about local failures

• Join interface down

• Internal Vlans down

• AED down or initializing

• Vlans are split across EDs as long as

• At least one adjacency is up &

• EDs are AED capable

With Mechanism to proactively advertise AED capability

OTV OTV

AED for VLAN

A,B,C

AED for VLAN

X, Y, Z

AED for VLAN

X, Y, Z

A, B, C Overlay Adjacency

Site Adjacency

I’m not AED Capable

Adjacency Up.

AED election process begins

AED election begins.

Exclude non-AED capable EDs

NX-OS

Release 5.2

and above


• Site-id is mandatory

• If not configured, no overlay will come up

• Holds true for single-homed site as well

• EDs in same site MUST be configured with same site-id

• If mismatch detected, all overlays will come down until this error is fixed

• Site-id is not generated by default.

• Two formats for site-id

• Flat Hexadecimal: <1-ffffffffffff>

• MAC address format: nnnn.nnnn.nnnn

• Site-id is always displayed in MAC address format (0000.0000.0256)

Site-id “0” is not acceptable

Things to be aware of...

NX-OS

Release 5.2

and above


VLAN Splitting between Edge Devices

• VLANs are split between the OTV Edge Devices belonging to the same site

• Achieved via a very deterministic algorithm (not configurable). In a dual-homed site:

Lower IS-IS System-ID (Ordinal 0) = EVEN VLANs

Higher IS-IS System-ID (Ordinal 1) = ODD VLANs

• Future functionality will allow to tune the behavior

OTV-ED# show otv site

Site Adjacency Information (Site-VLAN: 1999)

(* - this device)

Overlay100 Site-Local Adjacencies (Count: 2)

Hostname System-ID Ordinal

---------------- ---------------- -------

dc2a-agg-7k2-otv 001b.54c2.e142 0

* dc2a-agg-7k1-otv 0022.5579.0f42 1

OTV OTV

AED

ODD VLANs

AED

EVEN VLANs

NX-OS

ASR1K-ED1# show otv site

Site Adjacency Information (Site Bridge-Domain: 10)

Overlay0 Site-Local Adjacencies (Count: 2)

Hostname System ID Last Change Ordinal AED Enabled Status

* ASR1K-ED1 C47D.4FB3.F500 6d22h 1 site overlay

ASR1K-ED2 5475.D098.2200 6d22h 0 site overlay

IOS-XE


AED and Broadcast Handling

• Broadcast reaches all the Edge Devices within the site

• Only the AED for that VLAN forwards the traffic to the overlay

• All the Edge Devices at the other sites receive the broadcast

• Only the AED at the remote sites will forward the packet from the overlay into the site

Core

OTV

OTV

OTV

AED AED

Bcast

pkt

Broadcast

stops here

Broadcast

stops here

OTV


OTV

AED

AED

OTV

OTV

OTV

MAC X

MAC X

MAC X

VM Moves

MAC X

OTV

MAC X

MAC X

OTV West

West East

OTV

OTV East

1

Server originates a

Gratuitous ARP

(GARP) frame

AED advertises MAC X

with a metric of zero MAC X

AED detects

MAC X is now

local

MAC X

MAC X

MAC X

ESX

MAC X

ESX

ESX ESX

MAC X

MAC X

2

2.3

2.2 2.1

AED

AED


OTV

OTV West

AED

MAC X

AED

OTV

OTV East

MAC X

AED in site East

forwards the

GARP broadcast

frame across the

overlay

MAC X

MAC X

MAC X ESX

AED in site West

forwards the GARP

into the site and the

L2 switches update

their CAM tables

ESX

MAC X

MAC X

MAC X

AED

OTV

OTV West

AED

OTV

OTV

MAC X

MAC X

East MAC X

MAC X

ESX

ESX

MAC X

MAC X

EDs in site West see MAC X advertisement with a

better metric from site East and change them to

remote MAC address.

2.4

2

3

3.1

3.2

MAC X


Real Problems Solved by OTV

Extensions over any transport

No Re-design required

Failure boundary preservation

Site independence / isolation

Optimal BW utilization (no head-end replication)

Resiliency/multihoming

Built-in end-to-end loop prevention

Multisite connectivity (inter and intra DC)

Scalability

VLANs, sites, MACs

ARP, broadcasts/floods

Operations simplicity South

Data

Center

North

Data

Center Fault

Domain

Fault

Domain

Fault

Domain

Fault

Domain

LAN Extension

Only 5 CLI commands


Optimal Routing Challenges

Server-Server Egress Routing Localization:

Server-Client

Egress Routing Localization:

Server-Client

• Layer 2 extensions represent a challenge for optimal routing

• Challenging placement of gateway and advertisement of routing prefix/subnet


Ingress Routing

Localization: Clients-

Server


• Extended VLAN typically has associated HSRP group

• Only one HSRP router active, with all servers pointing to HSRP VIP as default gateway

• Result: sub-optimal (trombone) routing

HSRP

Active

HSRP

Standby

HSRP

Listen

HSRP

Listen

HSRP Hellos

VLAN

20

VLAN

10


HSRP

Active HSRP

Standby

ARP for

HSRP VIP

ARP

reply

HSRP Filtering

FHRP Filtering Solution

• Filter FHRP with combination of VACL and MAC route filter

• Result: Still have one HSRP group with one VIP, but now have active router at each site for optimal first-hop routing

HSRP

Active HSRP

Standby

HSRP Hellos HSRP Hellos

VLAN

20

VLAN

10


FHRP Localization – Egress Path Optimization

HA cluster Node B

Layer 3 Core

ISP A ISP B

HA cluster Node A

Access

Agg

Cluster VIP = 10.1.1.100 Preempt

Default GW = 10.1.1.1

Node A

Data Center

A Data Center

B

VLAN A

Public Network

Asymmetrical flows No Stateful device

Low ingress traffic

HSRP

Active

HSRP

Standby HSRP

Active

HSRP

Standby HSRP Filtering


Challenge

• Subnets are spread across locations

• Subnet information in the routing tables is not specific enough

• Routing doesn’t know if a server has moved between locations

• Traffic may be sent to the location where the application is not available

West East

Ingress Traffic

Localization: Client

to Server Traffic

DCI LAN Extension


Options

DNS Based

1. DNS redirection with ACE/GSS

Routing Based

2. Route Injection

3. LISP


Internet

Device IPv4 or IPv6

address represents

identity and location

Today’s Internet Behavior Loc/ID “overloaded” semantic

x.y.z.1 When the device moves, it gets

a new IPv4 or IPv6 address for

its new identity and location

w.z.y.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”

Internet

a.b.c.1

e.f.g.7

Only the location changes

x.y.z.1

x.y.z.1

Location Identity Separation Protocol What Do We Mean by “Location” and “Identity”?

Its location is here!


A LISP Packet Walk How Does LISP Operate?

Non-LISP site

East-DC

LISP site

IP Network

ETR

EID-to-RLOC mapping

172.16.1.1 172.16.2.1

1.1.1.1

3.3.3.3

172.16.10.1

2.2.2.2

10.2.0.0/24

172.16.3.1 172.16.4.1

10.1.0.0/24

West-DC

PiTR

4.4.4.4

10.3.0.0/24

Non-LISP site

ITR S

D

DNS entry: D.abc.com A 10.1.0.1

1

10.3.0.1 -> 10.1.0.1

2

EID-prefix: 10.1.0.0/24

Locator-set:

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


Mapping

Entry

3

This policy controlled

by destination site

10.3.0.1 -> 10.1.0.1

172.16.10.1 -> 172.16.1.1

4

10.3.0.1 -> 10.1.0.1

5


A LISP Packet Walk How about non-LISP sites?

Non-LISP site

East-DC

IP Network

ETR

EID-to-RLOC mapping

172.16.1.1 172.16.2.1

1.1.1.1

3.3.3.3

2.2.2.2

10.2.0.0/24

172.16.3.1 172.16.4.1

10.1.0.0/24

West-DC

PiTR

4.4.4.4

Non-LISP site

S

D

DNS entry: D.abc.com A 10.1.0.1

1

192.3.0.1 -> 10.1.0.1

2

EID-prefix: 10.1.0.0/24

Locator-set:



Mapping

Entry

3

192.3.0.1 -> 10.1.0.1

4.4.4.4- > 172.16.1.1

4

192.3.0.1 -> 10.1.0.1

5


Inner IP Header:

Host supplied IDs

Outer IP Header

(20 Bytes):

Router supplied

RLOCs

draft-ietf-lisp-05

LISP Header

(8 Bytes)

UDP Header

(8 Bytes)

LISP Overview LISP Header Format

Overall IP MTU Increase: 36 Bytes


LISP Roles

• Tunnel Routers - xTRs

• Edge devices in charge of encap/decap

• Ingress/Egress Tunnel Routers (ITR/ETR)

• EID to RLOC Mapping DB

• Contains RLOC to EID mappings

• Distributed across multiple Map Servers (MS)

• MS may connect over an ALT network

• Proxy Tunnel Routers - PxTR

• Coexistence between LISP and non-LISP sites

• Ingress/Egress: PiTR, PeTR

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?


The basics – Registration and Resolution

West-DC East-DC

X Z

Y

Y

10.1.0.2

10.1.0.0 /16 10.2.0.0/16

Map Server / Resolver:

1.1.1.1

A B C D

LISP site

iTR

10.1.0.0/16 -> (A, B)

Database Mapping Entry (on ETR):

10.2.0.0/16 -> (C, D)

Database Mapping Entry (on ETR): eTR eTR eTR eTR

Map-Reply

10.1.0.0/16 -> (A, B)

10.1.0.0/16-> (A, B)

Mapping Cache Entry (on ITR):


West-DC East-DC

Non-LISP sites

PiTR LISP site

IP Network

EID RLOC LISP encap/decap

iTR

Mapping DB

1.1.1.1

3.3.3.3

172.16.10.1

10.1.0.0/24

2.2.2.2

Basic LISP Configuration

eTR

172.16.1.1 172.16.2.1

Branch Routers

ip lisp itr

ip lisp itr map-resolver 3.3.3.3

DC Aggregation Routers

ip lisp etr

ip lisp database-mapping 10.1.0.0/24 172.16.1.1 …

ip lisp database-mapping 10.1.0.0/24 172.16.2.1 …

ip lisp etr map-server 1.1.1.1 key s3cr3t

ip lisp etr map-server 2.2.2.2 key s3cr3t

Border Routers Between Backbones

ip lisp proxy-itr

ip lisp itr map-resolver 3.3.3.3

Servers

ip lisp map-resolver

ip lisp map-server

lisp site west-DC

authentication-key 0 s3cr3t

eid-prefix 10.1.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


Routing for extended subnets

Active-Active Data Centers

Distributed Clusters

IP mobility across subnets

Disaster Recovery

Cloud Bursting

Live moves with LAN Extension Cold moves without LAN Extension

VM-Mobility Scenarios Which technologies, when?

Application Members Distributed Live moves

Application Members in one location Cold moves

West-DC East-DC

Non-LISP Site

IP Network

Mapping DB

LISP-VM (xTR)

OTV

LISP Site

xTR

West-DC East-DC

LISP Site

Internet or Shared WAN

xTR

Mapping DB DR Location or Cloud Provider

DC

LISP-VM (xTR)


West-DC East-DC

X Z Y

10.1.0.0 /16 10.2.0.0 /16

A B C D

LISP site

DC site

LISP site

DC site

West-DC East-DC

X Z Y

10.1.0.0 /16 10.1.0.0 /16

A B C D

DC site DC site

With Extended Subnets

Single subnet

Single LISP site

One LISP site =

Multiple DC sites

Move within a LISP site

and across DC sites

Without Extended Subnets

Different subnets

Different LISP sites

A LISP site = A DC site

Move across DC/LISP sites

OTV

Extended LISP site

LISP Sites vs. Data Center Sites With or Without 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

A B C D

HSRP

ARP

GWY-MAC

HSRP

ARP

GWY-MAC

HSRP Active

HSRP Active

10.1.0.0 /24 10.1.0.0 /24

LISP VM-Mobility - First Hop Routing With Extended Subnets

LAN Ext.

interface vlan 100

ip address 10.1.0.5/24

lisp mobility roamer

lisp extended-subnet-mode

hsrp 101

ip 10.1.0.1

interface vlan 200




hsrp 101

ip 10.1.0.1

interface vlan 100




hsrp 101

ip 10.1.0.1

interface Ethernet2/4




hsrp 101

ip 10.1.0.1

LISP-VM (xTR)


Interfaces

Encap/decap

N7K-M132XP-12

N7K-M132XP-12L

Other M-series

Cards

F-series Cards

(Proxy mode)

N7K-M132XP-12

N7K-M132XP-12L

•Only the N7K-M132XP-12 and N7K-

M132XP-12L are capable of doing LISP

encapsulation

•F-Series can leverage N7K-M132XP-12 in

Proxy mode to support LISP

•Other M-series cards cannot operate in

Proxy mode and should not be present in

the VDC where LISP is enabled


• 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


Access

Agg

VM= 10.10.10.1

Default GW = 10.10.10.100

ISP A ISP B

Access

Agg

Data Center A

LAN Extension

Prefix

(EID)

Route Locator

(RLOC)

10.10.10.1 A, B

10.10.10.2 A, B

… …

10.10.10.5 C, D

10.10.10.6 C, D

Ingress Tunnel

Router (ITR)

Moved to C, D

Decap

3

IP_DA = 10.10.10.1

1

ETR

LISP

A B C D

IP_DA = B IP_DA = 10.10.10.1

IP_DA = 10.10.10.1

4

5

Decap

7

IP_DA = C IP_DA = 10.10.10.1

6 Encap

2

Data Center B

ETR

VM= 10.10.10.1

Default GW = 10.10.10.100

IP_DA = 10.10.10.1

VM IP Address

10.10.10.1


West-DC

Data Center IP Backbone

DC-Aggregation

DC-Access

East-DC

Internet / WAN Backbone

PxTR

LISP site


xTR

Mapping DB

Non-LISP sites

Where to Deploy LISP and OTV Roles and Places in the Network

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


OTV: Aggregation routers @

Data Center


OTV


• @ Main Data Centers

• @ Disaster Recover facilities

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

Detect host moves

Provide a consistent first hop presence

Monitor host liveness

• Usually the Aggregation Switches in the Data Center

• Customer Managed

LISP-VM-Mobility Router Placement

West-DC




DC-Aggregation

DC-Access

East-DC

LISP site

xTR

LISP-VM (xTR)

DR Location or Cloud Provider

DC

LISP-VM (xTR)


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

OTV Router Placement

West-DC




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


DC-Aggregation

DC-Access

East-DC

• 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

PxTR Placement Advertise DC Routes to Non-LISP Sites


Private PxTR


Non-LISP sites

Provider PxTR


• 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 (ALT or IMDB)

Map Server Placement A daemon on a router

West-DC




Non-LISP sites

DC-Aggregation

DC-Access

East-DC

LISP site

xTR

SP Mapping

Service

Private Map Server

Private Map Server


Today:

• ISRs

• ASR 1000

• Nexus 7000

Future:

• Catalyst 6500*, 4500*

• CRS*, ASR9K*

Today:

• Nexus 7000

• ASR 1000

LISP OTV


• Thank you!

• Please complete the post-event survey.

• Join us April 4 for our next webinar:

Network Automation Techniques Using Embedded Event Manager (EEM)

To register, go to www.cisco.com/go/iosadvantage

an introduction to cisco otv (ios advantage webinar)

Technology