Mobility and Virtualization in the Data Center with LISP and OTV

Twitter www.twitter.com/ciscocz Talk2cisco www.talk2cisco.cz/dotazy SMS 721 994 600 2

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 3

Building the Data Center Fabric 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 4

Multi-tenancy/segmentation: Segment-IDs in LISP, FabricPath and OTV IP Mobility: LISP OTV OTV OTV L2 Domain Elasticity: vpc, FabricPath/TRILL OTV LAN extensions OTV VN-link notifications Device Virtualization: VDCs, VRF enhancements MPLS VPN Location of compute resources is transparent to the user VM-awareness: VN-link Port Profiles 2010 Cisco and/or its affiliates. All rights reserved. 5 OTV

LAN Extensions: OTV Mobility and Virtualization in the Data Center Introduction to LISP LISP Data Center Use Cases LISP + OTV Deployment Considerations Summary and Conclusion 6

Moving Workloads Hypervisor Hypervisor Control Traffic (routable) IP Network Not necessarily for moving workloads: Hypervisor Can be solved with IP mobility solutions: LISP Host Mobility Application High Availability Distributed Clusters e.g. Node Discovery & Heartbeats in clustered Applications Distributed App (GeoCluster) OS OS OS Non-IP application traffic (heartbeats) LAN Extension (OTV) 7

Circuits + Data Plane Flooding Packet Switching + Control Protocol Data Center II Data Center I Data Center II Data Center I L3 L2 L3 L2 A B C D A B C D A B C D A B C D 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 Traditional L2 VPNs Packet switched connectivity MAC learning by control protocol Failure containment Rich information Operational simplification Automatic loop prevention & multihoming MAC Routing 2010 Cisco and/or its affiliates. All rights reserved. 8

OTV Data Plane Inter-Site Packet Flow 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 Layer 2 Lookup MAC TABLE VLAN MAC IF 100 MAC 1 Eth 2 Transport Infrastructure OTV OTV OTV OTV 100 MAC 2 Eth 1 100 MAC 2 IP A MAC 1 MAC 3 IP A IP B 100 MAC 3 IP B MAC 1 MAC 3 IP A IP B 100 MAC 3 Eth 3 100 MAC 4 IP B IP A 2 1 Encap 3 Decap 4 IP B MAC TABLE VLAN MAC IF 100 MAC 1 IP A 100 MAC 4 Eth 4 5 Layer 2 Lookup MAC 1 MAC 3 MAC 1 West Site East Site MAC 1 MAC 3 MAC 3 6 9

OTV Data Plane Encapsulation 42 Bytes overhead to the packet IP MTU size Outer IP + OTV Shim - Original L2 Header (w/out the.1q header) 802.1Q header is removed and the VLAN field copied over to the OTV shim header Outer OTV shim header contains VLAN, overlay number, etc 802.1Q header removed 802.1Q DMAC SMAC 802.1Q Ether Type DMAC SMAC Ether Type IP Header OTV Shim 6B 6B 2B 20B 8B L2 Header 14B* Payload CRC 4B Original L2 Frame 20B + 8B + 14B* = 42 Bytes of total overhead * The 4 Bytes of.1q header have 10 already been removed

OTV Hello OTV Control Plane OTV Control Plane Neighbor Discovery (over Multicast Transport) 5 Neighbor South OTV IP Addr IP C Bidirectional adjacency formed OTV Neighbor IP Addr West IP A South IP C 5 OTV Hello OTV Control Plane OTV Hello West IP C G Decap IP A Multicast-enabled Transport IP B Decap OTV Hello 4 4 East IP C G OTV Hello OTV Hello IP C G IP C G 3 The South Site creates its hello with West s address in the TLV 2 Encap OTV OTV Hello IP C IP C G 1 OTV Control Plane OTV Hello South Neighbor West IP Addr IP A 11

OTV Configuration OTV over a Multicast Transport Minimal configuration required to get OTV up and running feature otv otv site-identifier 0x1* otv site-vlan 99 interface Overlay100 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 West OTV IP A feature otv otv site-identifier 0x2* otv site-vlan 99 interface Overlay100 otv join-interface Po16 otv control-group 239.1.1.1 otv data-group 232.192.1.0/24 otv extend-vlan IP C 100-150 OTV feature otv otv site-identifier 0x3* otv site-vlan 99 interface Overlay100 otv join-interface e1/1.10 otv control-group 239.1.1.1 otv data-group 232.192.1.0/24 otv extend-vlan 100-150 IP B OTV East South *Introduced from release 5.2 12

OTV Control Plane Neighbor Discovery (Unicast-Only Transport) Release 5.2 and above Adjacency server is a process that can run on any OTV edge device (not a separate server or other device) Advertises IP of each Edge Device (ED) to all other EDs (OTV neighbor list onl) All subsequent communications happen directly between EDs without going through the Adjacency Server Site 2 Site 3 onl Site 1, IP A Site 2, IP B Site 3, IP C Site 4, IP D Site 5, IP E Site 1 IP A Adjacency Server Mode IP B IP D IP C Unicast-Only Transport IP E Site 4 Site 5 13

OTV Configuration OTV over a Unicast Only Transport Release 5.2 and above Primary Adjacency Server feature otv otv site-identifier 0x1 otv site-vlan 99 interface Overlay100 otv join-interface e1/1 otv adjacency-server unicast-only otv extend-vlan 100-150 OTV Secondary Adjacency Server feature otv otv site-identifier 0x2 otv site-vlan 99 interface Overlay100 otv join-interface e1/1.10 otv adjacency-server unicast-only otv use-adjacency-server 10.1.1.1 unicast-only otv extend-vlan 100-150 West IP A 10.1.1.1 OTV IP B 10.2.2.2 East Generic OTV Edge Device IP C OTV feature otv otv site-identifier 0x3 otv site-vlan 99 interface Overlay100 South otv join-interface Po16 otv use-adjacency-server 10.1.1.1 10.2.2.2 unicast-only otv extend-vlan 100-150 14

The OTV Control Plane 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 OTV MAC Addresses Advertisements OTV West IP A IP B East IP C OTV South 15

Craft OTV 2update with new MACs OTV Control Plane Route (MAC) Advertisements (over Multicast Transport) Update A OTV OTV VLAN MAC IF 100 MAC A IP A 100 MAC B IP A 100 MAC C IP A Update A 6 Update A IP A G MAC Table VLAN MAC IF 100 MAC A e1/1 100 101 MAC B e1/1 100 102 MAC C e1/1 West 3 Encap Multicast-enabled Transport Update A Update A IP A G IP A G 4 5 Update A Decap East IP A G MAC Table VLAN MAC IF 100 MAC A IP A 101 MAC B IP A 102 MAC C IP A 1 New MACs learned in VLANs that are OTV extended Decap 5 OTV Add MACs learned through OTV 7 Update A IP A G 6 VLAN MAC IF 100 MAC A IP A 100 MAC B IP A 100 MAC C IP A Update A South MAC Table VLAN MAC IF 100 MAC A IP A 100 101 MAC B IP A 100 102 MAC C IP A 7 Add MACs learned through OTV 16

OTV Control Plane CLI Verification Establishment of control plane adjacencies between OTV Edge Devices (multicast or unicast transport): 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 15:08:53 UP dc1-agg-7k2 001b.54c2.e1c3 20.12.23.2 15:43:27 UP dc2-agg-7k2 001b.54c2.e142 20.22.23.2 14:49:11 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 Local Site MAC Remote Site MAC 2010 Cisco and/or its affiliates. All rights reserved. 17

Ingress Routing Challenge in DCI Extending Subnets Creates a Routing Challenge A subnet usually 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 LAN Extension IP Network More granular (host level) information is required West-DC East-DC 18

Egress Routing Localization 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 Hellos HSRP Hellos HSRP Filtering HSRP Active HSRP Standby HSRP Active ARP reply HSRP Standby ARP for HSRP VIP VLAN 20 VLAN 10 19

Ethernet LAN Extension over any Network Works over dark fiber, MPLS, or IP Multi-data center scalability Simplifying LAN Extensions Simplified Configuration & Operation Seamless overlay - No network re-design Single touch site configuration Many Physical Sites One Logical Data Center High Resiliency Failure domain isolation Seamless Multi-homing Maximizes available bandwidth Automated multi-pathing Optimal multicast replication Any Workload, Anytime, Anywhere Unleashing the Full Potential of Compute Virtualization 20

Mobility and Virtualization in the Data Center LAN Extensions: OTV Introduction to LISP LISP Data Center Use Cases LISP + OTV Deployment Considerations Summary and Conclusion 21

Location Identity Separation Protocol What Do We Mean by Location and Identity? IP core 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 Device IPv4 or IPv6 Its New Identity and Location Address Represents Identity and Location 20.2.0.9 10.1.0.1 Device IPv4 or IPv6 Address Represents Identity Only. 1.1.1.1 IP core 2.2.2.2 LISP Behavior Loc/ID Split 10.1.0.1 When the Device Moves, Keeps Its IPv4 or IPv6 Address. It Has the Same Identity Its Location Is Here! Only the Location Changes 22

A LISP Packet Walk How Does LISP Operate? 1 DNS Entry: D.abc.com A 10.2.0.1 10.1.0.1 -> 10.2.0.1 4 2 1.1.1.1 -> 2.1.1.1 10.1.0.1 -> 10.2.0.1 10.1.0.0/24 LISP Site S 3 Mapping Entry ITR 1.1.1.1 EID-prefix: 10.2.0.0/24 Locator-set: 2.1.1.1, priority: Non-LISP 1, weight: site 50 (D1) Non-LISP site 2.1.2.1, priority: 1, weight: 50 (D2) IP Network 5.1.1.1 PITR 5.4.4.4 5.3.3.3 EID-to-RLOC mapping 2.1.1.1 2.1.2.1 3.1.1.1 3.1.2.1 5.2.2.2 This Policy Controlled by Destination Site 5 10.1.0.1 -> 10.2.0.1 ETR West-DC D 10.2.0.0/24 10.3.0.0/24 East-DC 23

A LISP Packet Walk How About Non-LISP Sites? 1 DNS Entry: D.abc.com A 10.2.0.1 Non-LISP Site S Non-LISP Site 3 Mapping Entry EID-Prefix: 10.2.0.0/24 Locator-Set: 2.1.1.1, priority: 1, weight: 50 (D1) 2.1.2.1, priority: 1, weight: 50 (D2) 2 192.3.0.1 -> 10.2.0.1 PITR 4.4.4.4 4 4.4.4.4- > 2.1.2.1 192.3.0.1 -> 10.2.0.1 IP Network 5.1.1.1 5.3.3.3 EID-to-RLOC mapping 5.2.2.2 2.1.1.1 2.1.2.1 3.1.1.1 3.1.2.1 5 192.3.0.1 -> 10.2.0.1 ETR West-DC D 10.2.0.0/24 10.3.0.0/24 East-DC 24

LISP Roles and Address Spaces What Are the Different Components Involved? Mapping DB EID a.a.a.0/24 b.b.b.0/24 c.c.c.0/24 d.d.0.0/16 RLOC w.x.y.1 x.y.w.2 z.q.r.5 z.q.r.5 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 EID Space Non-LISP PxTR 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 ITR ETR Address Spaces EID = End-point Identifier Host IP or prefix RLOC = Routing Locator IP address of routers in the backbone 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 ALT RLOC Space EID 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 25

LISP Site ITR Mapping Cache Entry (on ITR): 10.2.0.0/16-> (2.1.1.1, 2.1.2.1) Map Server / Resolver: 5.1.1.1 Map-Reply 10.2.0.0/16 -> (2.1.1.1, 2.1.2.1) 2.1.1.1 2.1.2.1 3.1.1.1 3.1.2.1 Database Mapping Entry (on ETR): 10.2.0.0/16 -> (2.1.1.1, 2.1.2.1) ETR ETR ETR ETR Database Mapping Entry (on ETR): 10.3.0.0/16 -> (3.1.1.1, 3.1.2.1) West-DC East-DC 10.2.0.0 /16 10.3.0.0/16 Y X Y Z 10.2.0.2 26

Basic LISP Configuration Servers ip lisp map-resolver ip lisp map-server lisp site west-dc authentication-key 0 s3cr3t eid-prefix 10.2.0.0/24 Border Routers Between Backbones ip lisp proxy-itr ip lisp ITR map-resolver 5.3.3.3 Non-LISP Sites Branch Routers ip lisp itr-etr ip lisp ITR map-resolver 5.3.3.3 LISP Site ITR 1.1.1.1 IP Network PITR 5.1.1.1 Mapping DB 5.3.3.3 5.2.2.2 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 2.1.1.1 2.1.2.1 ETR West-DC 10.2.0.0/24 East-DC Usually Devices Will Be Configured as ITRs and ETRs to Handle Traffic in Both Directions; We Illustrate Only One Direction for Simplicity RLOC EID LISP Encap/Decap 28

LISP Use Cases Consolidated Architecture with Multiple Applications Efficient Multi-Homing LISP Site LISP Routers Internet IPv6 Transition Support v6 Services LISP Router v6 IPv4 Internet v4 v6 LISP Router v6 IPv6 Internet IP Portability Ingress Traffic Engineering without BGP Multi-Tenancy and VPNs LISP Site v6-over-v4, v6-over-v6 v4-over-v6, v4-over-v4 Host-Mobility LISP Site IP Network IP Network West-DC East-DC West-DC East-DC Reduced CapEx/OpEx Large scale Segmentation Cloud / Layer 3 VM moves Segmentation 2010 Cisco and/or its affiliates. All rights reserved. 30

Mobility and Virtualization in the Data Center LAN Extensions: OTV Introduction to LISP LISP Data Center Use Cases Host-Mobility LISP + OTV Deployment Considerations Summary and Conclusion 31

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 LISP Site xtr LAN Extensions LISP-VM (xtr) West-DC RLOC Non-LISP Sites PxTR Mapping DB IP Network East-DC EID LISP Encap/Decap 32

Host-Mobility Scenarios Moves Without LAN Extension Moves With LAN Extension LISP Site xtr Non-LISP Site LISP Site xtr Mapping DB Internet or Shared WAN DR Location or Cloud Provider DC LAN Extension IP Network Mapping DB LISP-VM (xtr) LISP-VM (xtr) West-DC East-DC West-DC East-DC IP Mobility Across Subnets Disaster Recovery Cloud Bursting Application Members in One Location Routing for Extended Subnets Active-Active Data Centers Distributed Clusters Application Members Distributed (Broadcasts across sites) 33

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 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 Mapping DB LISP-VM (xtr) 5.1.1.1 5.2.2.2 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 West-DC East-DC 10.2.0.0 /16 10.3.0.0/16 Y X Y Z 10.2.0.2 34

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 Transparent to the underlying routing and to the host LISP Site xtr A B C D Mapping DB 10.2.0.0/16 RLOC A, B 10.2.0.2/32 RLOC C, D LISP-VM (xtr) West-DC East-DC 10.2.0.0 /16 10.3.0.0 /16 Y X Y Z 10.2.0.2 35

LISP Host-Mobility - First Hop Routing Across Different Subnets 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 Hosts can move anywhere and always talk to a local gateway with the same MAC Totally transparent to the moving hosts interface vlan 100 interface vlan interface vlan 100 ip200 address 10.3.0.7/24 ip address 10.2.0.8/24 ip address 10.2.0.5/24 lisp mobility roamer lisp mobility interface Ethernet2/4 lisp mobility roamer ip proxy-arp roamer ip proxy-arp ip address 10.1.0.6/24 ip proxy-arp hsrp 201 hsrp 201 lisp mobility hsrp roamer 101 mac-address 0000.0e1d.010c mac-address 0000.0e1d.010c ip proxy-arp mac-address 0000.0e1d.010c ip 10.3.0.1 ip 10.3..0.1 hsrp 101 ip 10.2.0.1 mac-address 0000.0e1d.010c A B C D ip 10.2.0.1 HSRP Active LISP-VM (xtr) West-DC East-DC 10.2.0.0 /24 10.3.0.0 /24 HSRP HSRP ARP ARP GWY-MAC GWY-MAC 10.2.0.2 HSRP Active 37

Null0 host routes indicate the host is away 6 10.2.0.0/16 RLOC A, B 10.2.0.2/32 RLOC C, D Map-Notify 10.2.0.2/32 <C,D> Mapping DB 5.1.1.1 5.2.2.2 Map-Register 10.2.0.2/32 <C,D> Routing Table: 10.2.0.0/16 Local 10.2.0.2/32 Null0 10 A B 7 5 2 Routing Table: 10.3.0.0/16 Local 10.2.0.2/32 Local C 4 D Routing Table: 10.3.0.0/16 Local 10.2.0.2/32 Local Routing Table: 9 10.2.0.0 /16 10.2.0.0/16 Local 10.3.0.0 /16 8 10.2.0.2/32 Null0 1 East-DC West-DC Y Map-Notify 10.2.0.2/32 <C,D> X 10.2.0.2 Y 3 Map-Notify 10.2.0.2/32 <C,D> 38

Map Cache @ ITR 10.2.0.0/16 RLOC A,B 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 LISP site ITR 10.2.0.2/32 RLOC C,D Mapping DB A B C D LISP-VM (xtr) West-DC East-DC 10.2.0.0 /16 10.3.0.0 /16 Y X Y Z 10.2.0.2 39

Null0 host routes indicate the host is away 10.2.0.0 /24 is the dyn-eid 6 10.2.0.0/16 RLOC A, B 10.2.0.2/32 RLOC C, D Mapping DB 5.1.1.1 5.2.2.2 Map-Register 10.2.0.2/32 <C,D> 4 Routing Table: 10.2.0.0/16 Local 10.2.0.2/32 Null0 A B 2 Routing Table: 10.2.0.0/16 Local 10.2.0.2/32 Local 5 C 4 D Routing Table: 10.2.0.0/16 Local 10.2.0.2/32 Local 10.2.0.0 /16 West-DC Y 4 Routing Table: 10.2.0.0/16 Local 10.2.0.2/32 Null0 3 OTV 1 3 10.2.0.0 /16 East-DC X Map-Notify 10.2.0.2/32 <C,D> 10.2.0.2 Y Map-Notify 10.2.0.2/32 <C,D> 42

Map Cache @ ITR 10.2.0.0/16 RLOC A,B 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 LISP site ITR 10.2.0.2/32 RLOC C,D Mapping DB A B C D LISP-VM (xtr) West-DC OTV East-DC 10.2.0.0 /16 10.2.0.0 /16 Y X Y Z 10.2.0.2 43

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 interface vlan 100 interface vlan 100 ip address 10.2.0.5/24 interface vlan ip address 200 10.2.0.7/24 interface Ethernet2/4 lisp mobility roamer ip address lisp 10.2.0.8/24 mobility roamer ip address 10.2.0.6/24 lisp extended-subnet-mode lisp mobility lisp extended-subnet-mode roamer lisp mobility hsrp roamer 101 lisp extended-subnet-mode hsrp 101 LAN Ext. lisp extended-subnet-mode ip 10.2.0.1 hsrp 101 ip 10.2.0.1 ip 10.2.0.1 hsrp 101 ip 10.2.0.1 A B C D HSRP Active LISP-VM (xtr) West-DC East-DC 10.2.0.0 /24 10.2.0.0 /24 HSRP HSRP ARP ARP GWY-MAC GWY-MAC HSRP Active 44

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 CLIENT 10.1.0.1 10.1.0.1 10.2.0.2 LISP Site F CLIENT 192.168.2.1 A B C D LISP-VM (xtr) West-DC East-DC 10.2.0.0 /16 10.3.0.0 /16 X xtr 192.168.2.1 10.2.0.2 F C 10.1.0.1 10.2.0.2 Y 10.2.0.2 Non-LISP Sites Y G PxTR G D 192.168.2.1 10.2.0.2 Mapping DB 10.1.0.1 10.2.0.2 192.168.2.1 10.2.0.2 46

On-Subnet Server-Server Traffic On Subnet Traffic Across L3 boundaries With LAN Extension Live moves and cluster member dispersion Traffic between X & Y uses the LAN Extension Link-local-multicast handled by the LAN Extension Without LAN Extensions Cold moves, no application dispersion X- Y traffic is sent to the LISP-VM router & LISP encapsulated Need LAN extensions for linklocal multicast traffic B C 10.2.0.3 10.2.0.2 Mapping DB LAN Ext. 10.2.0.3 10.2.0.2 A B C D A B C D LISP-VM (xtr) LISP-VM (xtr) West-DC 10.2.0.0/16 East-DC West-DC 10.2.0.0/16 East-DC 10.3.0.0/16 10.2.0.3 Y 10.2.0.3 Y X Y Z X Y Z 10.2.0.2 10.2.0.2 47

Mobility and Virtualization in the Data Center LAN Extensions: OTV Introduction to LISP LISP Data Center Use Cases Multi-Tenancy LISP + OTV Deployment Considerations Summary and Conclusion 48

Needs: High Level View 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 VRFs are highly distributed VRFs populated on demand No adjacencies to maintain 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 LISP Site West-DC xtr xtr RLOC Non-LISP Sites IP Network EID PxTR Instance IP Location Red A East Blue A West Yellow Mapping DB C (Move) LISP Encap/Decap East-DC East West 49

LISP Multi-tenancy Colored Map Requests/Replies 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 To MPLS VPNs, VRF-lite or separate networks To LISP G D Instance1 1.1.0.1 10.2.0.2 G E Instance2 1.1.0.1 10.2.0.2 G F Instance3 1.1.0.1 10.2.0.2 Virtualized Map Cache (xtrs): Mappings cached in different VRFs per instance-id Interoperable with other VRF features/solutions Single RLOC space shared by multiple instances Colored Traffic: Instance-ID tag in LISP data header Instance-ID encoded in LISP control packets Coloring is transparent to the core 50

Mobility and Virtualization in the Data Center LAN Extensions: OTV Introduction to LISP LISP Data Center Use Cases LISP + OTV Deployment Considerations Summary and Conclusion 54

Where to Deploy LISP and OTV Roles and Places in the Network xtr: Branch Routers @ LISP Sites Customer-managed/owned SP-Managed CE service PxTR: Border Routers @ Transit Points Customer backbone routers Customer router @ colocation SP provided router/service LISP-VM xtr: Aggregation Routers @ Data Center Customer-managed/owned LISP Site xtr Internet / WAN Backbone Data Center IP Backbone LISP-VM (xtr) PxTR DC-Aggregation DC-Access Non-LISP Sites Mapping DB Mapping Servers/Routers: Distributed Across Data Centers Customermanaged/owned SP provided service OTV West-DC East-DC OTV: Aggregation Routers @ Data Center Cisco Cisco Expo Customer-managed/owned Expo RLOC EID LISP Encap/Decap 55

Summary and Conclusions A combination of LISP and LAN Extension technologies is required by most data center deployments OTV provides a secure and optimized option for LAN extensions LISP consolidates many network services in one architecture: Mobility, network segmentation, traffic engineering Enhanced scalability LISP and OTV are available today across a wide range of products 71

Twitter www.twitter.com/ciscocz Talk2cisco www.talk2cisco.cz/dotazy SMS 721 994 600 72