otv technology introduction

Natale Ruello

Technical Marketing Engineer – Nexus 7000

OTV Technology Introduction

© 2009 Cisco Systems, Inc. All rights reserved. Cisco PublicBRKRST-2033 3

Cost Optimization

Adaptability

Availability

Addressing Business Goals with LAN Extensions

Service Velocity and On-demand Capacity

99.999% Global Availability

Maximize Asset Utilization

Streamline Operations & Reduce OPEX

Enable Distributed Clusters to improve Application Availability without compromising Network Resiliency

Unleash Compute Virtualization beyond a single physical data center for fast service and capacity additions

Supports migration of workloads and consolidation of servers across locations to avoid power/cooling hot spots or compute/network idleness

Enables improved change management methods across multiple physical locationsNon-disruptive model for minimal operational overhead

Business Goals LAN Extensions Attributes


Enabling IT Solutions with LAN extensions

Data Center A

Data Center B

LAN Extension

Cluster Vmotion

MSCS

Cluster Solaris Sun Cluster Enterprise

RAC (Real Appl.Cluster)HACMP

Legato Automated Availability Mgr

Metro Cluster Metrocluster

BACnet (building automation/control)


Overlay Transport Virtualization (OTV)

O

V

Overlay - A solution that is independent of the infrastructure technology and services, flexible over various inter-connect facilities

Transport - Transporting services for layer 2 and layer 3 Ethernet and IP traffic

Virtualization - Provides virtual connections, connections that are in turn virtualized and partitioned into VPNs, VRFs, VLANs

OTV LAN ExtensionsOTV delivers a virtual L2 transport

T


Challenges with LAN ExtensionsReal Problems Solved by OTV Extensions over any transport (IP, MPLS) Failure Boundary Preservation Site independence / Isolation Optimal BW utilization (no head-end

replication) Resiliency/multi-homing Built-in end-to-end Loop Prevention Multi-site connectivity (inter and intra DC) Scalability

VLANs, Sites, MACs ARP, Broadcasts/Floods

Operations Simplicity Topology Flexibility

South Data

Center

NorthData

CenterFault Domain

Fault Domain

Fault Domain

Fault Domain

LAN Extension

Only 5 CLIcommands

© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 7

Traditional Layer 2 VPNs

EoMPLS

VPLS

Dark Fiber


Flooding Behavior

x2

Site A

Site B

Site C

MAC 1 propagationMAC 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 L2-VPN.

A solution that provides layer 2 connectivity, yet restricts the reach of the flood domain is necessary in order to contain failures and preserve the resiliency.


Pseudo-wires Maintenance 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/remove sites. Head-end replication for multicast and broadcast. Sub-optimal BW utilization.

A simple overlay protocol with built-in functionality and point-to-cloud provisioning is key to reducing the cost of providing this connectivity


Multi-Homing

L2 SiteL2 Site L2 VPN

Active Active

Require additional protocols to support Multi-homing. STP is often extended across the sites of the Layer 2 VPN. Very difficult to

manage as the number of sites grows. Malfunctions on one site will likely impact all sites on the VPN.

A solution that natively provides automatic detection of multi-homing without the need of extending the STP domains is key.


What can be improved

Data Plane Learning Control Plane LearningMoving to a Control Plane protocol that proactively advertises MAC addresses and their reachability instead of the current flooding mechanism.

Pseudo-wires and Tunnels Dynamic EncapsulationNo static tunnel or pseudo-wire configuration required.

Optimal replication of traffic done closer to the destination, which translates into much more efficient bandwidth utilization in the core.

Multi-Homing Native Built-in Multi-homingIdeally a multi-homed solution should allow load balancing of flows within a single VLAN across the active devices in the same site, while preserving the independence of the sites.

STP confined within the site (each site with its own STP Root bridge)


Overlay Transport VirtualizationTechnology Pillars

Protocol Learning

Built-in Loop Prevention

Preserve Failure Boundary

Seamless Site Addition/Removal

Automated Multi-homing

Dynamic Encapsulation

No Pseudo-Wire State Maintenance

Optimal Multicast Replication

OTV is a “MAC in IP” technique for supporting Layer 2 VPNs OVER ANY TRANSPORT.

Multi-point Connectivity

Point-to-Cloud Model

OTV


OTV at a Glance Ethernet traffic between sites is encapsulated in IP: “MAC in IP” Dynamic encapsulation based on MAC routing table

No Pseudo-Wire or Tunnel state maintained

West Site

EastSite

OTV OTV

MAC IF

MAC1 Eth1

MAC2 IP B

MAC3 IP BIP A IP B

Encap DecapEthernet Frame IP packet

OTV

Ethernet Frame Ethernet Frame

MAC IF

MAC1 IP A

MAC2 Eth 1

MAC3 Eth 2

Communication between MAC1 (West) and MAC2 (East)


Eth 4

Eth 3

MAC TABLE

VLAN MAC IF100 MAC 1 Eth 2

100 MAC 2 Eth 1

100 MAC 3 IP B

100 MAC 4 IP B

MAC 2

MAC 1

OTV Data Plane: Unicast

Core

MAC 4

MAC 3

OTV

External IP A

External IP B

West East

L2 L3 L3 L2Ani

mat

ed S

lide

!

OTV Inter-Site Traffic

MAC Table contains MAC addresses reachable through

IP addresses

OTV

Encap 2

Layer 2Lookup

1

3 Decap 4 MAC 1 MAC 3

6

MAC TABLE

VLAN MAC IF100 MAC 1 IP A

100 MAC 2 IP A

100 MAC 3 Eth 3

100 MAC 4 Eth 4

Eth 1

Eth 2

Layer 2Lookup

5

MAC 1 MAC 3

IP A IP BMAC 1 MAC 3 MAC 1 MAC 3IP A IP BMAC 1 MAC 3

No Pseudo-Wire state is maintained.

The encapsulation is done based on a Layer 2 destination lookup.

The encapsulation is done in hardware by the Forwarding Engine.


Building the MAC tablesThe OTV Control Plane The OTV control plane proactively advertises MAC reachability (control-

plane learning). The MAC addresses are advertised in the background once OTV has

been configured. No protocol specific configuration is required.

Core

IP A IP B

IP C

West East

South

MAC AddressesReachability


OTV Control PlaneMAC address advertisements – Multicast Core Every time an Edge Device learns a new MAC address, the OTV

control plane will advertise it together with its associated VLAN IDs and IP next hop.

The IP next hops are the addresses of the Edge Devices through which these MACs are reachable in the core.

A single update reaches all neighbors.

Core

IP AIP B

West

East

3 New MACs are learned on VLAN 100

Vlan 100 MAC A

Vlan 100 MAC B

Vlan 100 MAC C

IP 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 by the core

Ani

mat

ed S

lide

!

OTV

Update

OTVUpdate3

OTV

Update3

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


Multicast Groups in the Core

OTV will leverage the multicast capabilities of the core.

This is the summary of the Multicast groups used by OTV: An ASM/Bidir group to exchange MAC reachability. An SSM group range for the multicast data generated by the site.

Summary of the Multicast groups used by OTV


What if core multicast is not an option?OTV in Unicast Mode – The Adjacency Server Mode

The use of multicast in the core provides significant benefits:Reduce the amount of hellos and updates OTV must issue

Streamline neighbor discovery, site adds and removes

Optimize the handling of broadcast and multicast data traffic

However multicast may not always be available

The OTV Adjacency Server Mode of operation provides a unicast based solution.


Adjacency Server

Despite the naming this is NOT a physical server. It is just a mode of operation of the Edge Devices.

An OTV node which sends a multicast packet on a non-multicast capable network will “unicast replicate (head-end)” the packet.

One of the OTV Edge Devices will be configured as an Adjacency Server and it will be responsible for communicating the IP addresses where the other Edge Devices can be reached.

The group of IP addresses is called overlay Adjacency List (oAL)

Two configuration steps:1. Configure an OTV Edge Device to be the Adjacency Server

2. Configure the other Edge Devices to point to the Adjacency Server to retrieve each other IP address

Core with no support for multicast: Adjacency Server


Adjacency Server At first, the Adjacency Server knows about no other OTV Edge Devices because

their oAL is empty.

Once other OTV Edge Devices start sending to the Adjacency Servers their site-id and IP address, the Adjacency Server will build up its oAL.

The contents of the oAL is advertised and sent unicast to each member of the oAL. Now the Edge Devices can communicate with each other.

IP A

Site 1

Site 2 Site 3

Site 4 Site 5

Core

IP BIP C

IP D IP EAdjacency Server

Site2, IP B Site3, IP C

Site4, IP D Site5, IP E

oAL

oAL

oALoAL

oALSite 1, IP A

Site 2, IP BSite 3, IP CSite 4, IP DSite 5, IP E


STP BPDU Handling

When STP is configured at a site, an Edge Device will send and receive BPDUs on the internal interfaces.

An OTV Edge Device will not originate or forward BPDUs on the overlay network.

An OTV Edge Device can become (but it is not required to) a root of one or more spanning trees within the site.

An OTV Edge Device will take the typical action when receiving Topology Change Notification (TCNs) messages.

OTV

Core

OTV

The BPDUsstop here


Unknown Unicast Packet Handling Flooding of unknown unicast over the overlay is not required and is

therefore suppressed.

Any unknown unicasts that reach the OTV edge device will not be forwarded onto the overlay.

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

MAC addresses for uni-directional host are learnt and advertised by snooping the host’s ARP reply

OTV

Core

OTV

No MAC 3 in theMAC Table

MAC 1 MAC 3

MAC TABLE

VLAN MAC IF100 MAC 1 Eth1

100 MAC 2 IP B


Controlling ARP trafficProxy ARP OTV Edge Devices can proxy ARP replies on behalf of remote hosts ARP traffic spanning multiple sites can thus be significantly reduced An ARP cache is maintained by every OTV edge device The ARP cache is populated by snooping ARP replies Initial ARP requests are broadcasted to all sites Subsequent ARP requests are suppressed and answered locally The ARP cache could also be populated at MAC learning time, this would

allow the suppression of all ARP related broadcast

Core

OTV

OTV

AED

OTV

ARP CacheMAC 1 IP 1

MAC 2 IP 2

ARP reply

2

First ARP

request (IP A)

1

Snoop & cache ARP reply

3

Subsequent ARP requests

(IP A)

4Proxy ARP reply (IP A)

5

One time traffic


OTV solves Layer 2 fault propagationSummary

STP Isolation: BPDUs are not forwarded over the overlay

Unknown unicasts are not flooded across sitesSelective flooding is optional

Cross site ARP traffic is reduced with Proxy ARP Broadcast can be controlled based on a white list as

well as a rate limiting profile


Multi-Homing: Loop Condition Handling

OTV includes the logic necessary to avoid the creation of loops in multi-homed site scenarios.

Each site will have its own STP domain, which is separate and independent from the STP domains in other sites, even though all sites will be part of common Layer 2 domain.

Core

OTV

OTV

OTV

OTV

OTV

STPdomain 1

STPdomain 2

No STP


Authoritative Edge Device

OTV provides loop-free multi-homing by electing a designated forwarding device per site for each VLAN.

The designated forwarder is referred to as the Authoritative Edge Device (AED).

The Edge Devices at the site peer with each other on the internal interfaces to elect the AED

The AED is the only edge device that will forward multicast and broadcast traffic between a site and the overlay.

Core

OTV

OTV

OTV

OTV

OTV

AEDAED


Multi-Homing: AED & Broadcast

A broadcast packet gets to all the Edge Devices within a site.

The AED for the VLAN is the only Edge Device that forwards broadcast packets on the overlay network.

All the Edge Devices at a remote site will receive the broadcast packet, but only the AED at the remote site will forward the packet into the site.

Once sent into the site, the packet gets to all switches on the site specific Spanning Tree.

Core

OTV

OTVOTV

OTV

AEDAED

Bcast pkt

Broadcaststops here

Broadcaststops here

OTV


Multi-HomingAED & Unicast Forwarding

One AED is elected for each VLAN on each site Different AEDs can be elected for each VLAN to balance traffic load Only the AED forwards unicast traffic to and from the overlay Only the AED advertises MAC addresses for any given site/VLAN Unicast routes will point to the AED on the corresponding remote

site/VLAN

Core

OTV

OTV

OTV

OTV

OTV

AED AED

AED AED

MAC TABLE

VLAN MAC IF100 MAC 1 IP A

200 MAC 2 IP B IP A

IP B


ConfigurationOTV CLI configuration

interface Overlay0 description otv-demo otv join-interface Ethernet1/1 otv control-group 239.1.1.1 otv data-group 232.192.1.2/32 otv extend-vlan 100-150 otv site-vlan 100

Connects to the core. Used to join the Overlay network. Its IP address is used as source IP for the OTV encap

ASM/Bidir group in the core used for the OTV Control Plane.

SSM group range used to carry the site’s mcast traffic data.

Site VLANs being extended by OTV

VLAN used within the Site for communication between the site’s Edge Devices


ConfigurationOTV CLI configuration with adjacency server

interface Overlay0 description otv-demo otv join-interface Ethernet1/1 otv adjacency-server or otv use-adjacency-server 10.10.10.10 otv extend-vlan 100-150 otv site-vlan 100

Connect to the core. Used to join the core mcast groups. Their IP addresses are used as source IP for the OTV encap

Configures this Edge device as an Adjacency Server

Use a remote Edge Device as the Adjacency Server (mutually exclusive with the previous line)

Site VLANs being extended by OTV

VLAN used within the Site for communication between the site’s Edge Devices


Nexus 7000 Rollout plan

EFTTarget start date: Mid January, 2010

FCSQ1CY2010

otv technology introduction

Documents

cisco systems

cisco publicbrkrst

cisco confidentialpresentation

transport ip

cluster hacmp

vlans otv lan extensionsotv

l2 extension

ip traffic virtualization