Deployment Considerations with Interconnecting Data Centers 2
Session Objectives The main goals of this session are: Highlighting the main business requirements driving Data Center Interconnect (DCI) deployments Understand the functional components of the holistic Cisco DCI solutions Get a full knowledge of Cisco LAN extension technologies and associated deployment considerations Integrate routing aspect induced by the emerging application mobility offered by DCI This session does not include: Storage extension considerations associated to DCI deployments
Related Cisco Live 2011 Events DCI Sessions Session-ID TECDCT-2181 BRKDCT-2011 BRKDCT-2049 BRKDCT-3103 BRKDCT-2081 BRKDCT-2131 Session Name Deployment Considerations for Interconnecting Distributed Virtual Data Centers Design and Deployment of Data Center Interconnects using Advanced VPLS (A-VPLS) Overlay Transport Virtualization Advanced OTV - Configure, Verify and Troubleshoot OTV in Your Network Cisco FabricPath Technology and Design Mobility and Virtualization in the Data Center with LISP and OTV
Agenda DCI Business Drivers and Solutions Overview LAN Extension Deployment Scenarios Ethernet Based Solutions MPLS Based Solutions IP Based Solutions LISP for DCI Deployments LISP and Path Optimization LISP and Services (FW, SLB) Integration Summary and Q&A
Data Center Interconnect Business Drivers Data Centers are extending beyond traditional boundaries Virtualization applications are driving DCI across PODs (aggregation blocks) and Data Centers DCI Drivers Business Solution Constraints IT Technology Business Continuity ü Disaster Recovery ü HA Framework ü Stateless ü Network Service Sync ü Process Sync ü GSLB ü Geo-clusters ü HA Cluster Operation Cost Containment ü Data Center Maintenance / Migration / Consolidation ü Host Mobility ü Distributed Virtual Data Center Business Resource Optimization ü Disaster Avoidance ü Workload Mobility ü VLAN Extension ü Statefulness ü Bandwidth & Latency ü VM Mobility Cloud Services ü Inter-Cloud Networking ü XaaS ü Flexibility ü Application mobility ü VM Mobility ü Automation
Data Center Interconnect LAN Extension Model Path Op miza on Any type of links Dual- Homing STP Domain isola on + Storm- control GW STP domain STP domain STP domain ALT GW ALT GW ALT Si Si Si Si DC1 DC2 DC3 Storage extension 7
Data Center Interconnect Host Mobility Scenarios Moves Without LAN Extension Moves With LAN Extension LISP Site xtr Non- LISP Site LISP Site xtr Mapping DB IP Network DR Loca on or Cloud Provider DC IP Network Mapping DB LAN Extension West- DC East- DC West- DC East- DC IP Mobility Across Subnets Disaster Recovery Cloud Bursting Migration Application Members in One Location Routing for Extended Subnets Active-Active Data Centers Distributed Clusters Workload mobility Application Members Distributed (Broadcasts across sites)
LAN Extension for DCI VLAN Types Type T0 Limited to a single access layer Type T1 Extended inside an aggregation block (POD) Type T2 Extended between PODs part of the same DC site T5 OTV/VPLS Type T3 Extended between twin DC sites connected via dedicated dark fiber links Type T4 Extended between twin DC sites using non 5*9 connection Type T5 Extended between remote DC sites T0 T1 T4 T3 T2 Fabricpath / vpc OTV/VPLS Fabricpath / vpc
LAN Extension for DCI Technology Selection Criteria Ethernet Over dark fiber or protected D-WDM Ø VSS & vpc Dual site interconnection Ø FabricPath (TRILL) Campus style MPLS MPLS Transport Ø EoMPLS Transparent point to point Ø A-VPLS Enterprise style MPLS Ø H-VPLS Large scale & Multi-tenants SP style IP IP Transport Ø OTV Enterprise style Inter-site MAC Routing Ø VXLAN Intra-site MAC bridging in total virtualized context IP style
LAN Extension for DCI Technology Selection Criteria Transport Fiber LOS report / Protected DWDM L2 SP offer (HA=99.7 + ) IP Scale Site VLAN (10 2 or 10 3 or 10 4 ) MAC (10 3 or 10 4 or 10 5 ) Multi-tenants Tagging (VLAN / 2Q / VRF) Overlapping / Translation Multi-point or point to point Greenfield vs. Brownfield Ethernet only for 5*9 HA link MPLS/IP for WAN quality link Ethernet for medium scale IP for low scale MPLS for high scale MPLS for multi-tenancy features
Agenda DCI Business Drivers and Solutions Overview LAN Extension Deployment Scenarios Ethernet Based Solutions VSS, vpc and FabricPath MPLS Based Solutions IP Based Solutions LISP for DCI Deployments LISP and Path Optimization LISP and Services (FW, SLB) Integration Summary and Q&A
Dual Site Interconnection Leveraging EtherChannel between Sites On DCI Etherchannel: STP Isolation (BPDU Filtering) Broadcast Storm Control FHRP Isolation Primary Root Primary Root interface port-channel10 desc DCI point to point connection switchport switchport mode trunk vpc 10 switchport trunk allowed vlan 100-600 spanning-tree port type edge trunk spanning-tree bpdufilter enable storm-control broadcast level 1 storm-control multicast level x Si Si L 2 L 3 WAN L 3 L 2 Link utilization with Multi- Chassis EtherChannel DCI port-channel - 2 or 4 links Requires protected DWDM or Direct fibers Server Cabinet Pair 1 Server Cabinet Pair N Server Cabinet Pair 1 Server Cabinet Pair N vpc does not support L3 peering: Use dedicated L3 Links for Inter-DC routing! Validated design: 200 Layer 2 VLANs + 100 VLAN SVIs 1000 VLAN + 1000 SVI (static routing)
FabricPath Data Plane Operation S10 Ingress FabricPath Switch DSID 20 SSID 10 DMAC B SMAC A Payload ISIS FabricPath Core S20 Egress FabricPath Switch Payload SMAC A DMAC B FabricPath interface CE interface DMAC B SMAC A Payload STP STP MAC A MAC B Ingress FabricPath switch determines destination Switch ID and imposes FabricPath header Destination Switch ID used to make routing decisions through FabricPath core No MAC learning or lookups required inside core Egress FabricPath switch removes FabricPath header and forwards to CE
FabricPath Conversational MAC Learning FabricPath MAC Table on S300 MAC B C IF/SID S200 (remote) e7/10 (local) S300 FabricPath MAC Table on S100 S100 MAC C MAC IF/SID A e1/1 (local) B S200 (remote) FabricPath Core FabricPath MAC Table on S200 MAC A S200 MAC A B IF/SID S100 (remote) e12/1(local) C S300 (remote) MAC B
FabricPath for DCI Partial-Meshed Topology for different models of DC vpc+ Classical Ethernet Cloud Site A vpc+ Site D Conversational Mac Learning Offer a full HA DCI solution with Native STP Isolation Provides easy integration with Brownfield DC Optimized using vpc+ vpc+ Site C Core FabricPath VSS Site B C E STP F1/F2 End to End for optimal design Required point to point connections Relies on Flooding for Unknown Unicast traffic No current Broadcast suppression L2 Multipath only for equal cost path can be leveraged (i.e. Aó B or Có D)
Agenda DCI Business Drivers and Solutions Overview LAN Extension Deployment Scenarios Ethernet Based Solutions MPLS Based Solutions EoMPLS VPLS H-VPLS IP Based Solutions LISP for DCI Deployments LISP and Path Optimization LISP and Services (FW, SLB) Integration Summary and Q&A
EoMPLS Port Mode xconnect interface PE1 T-LDP PE2 interface g1/1 description EoMPLS port mode connection no switchport no ip address xconnect 2.2.2.2 vcid 1 encapsulation mpls interface Ethernet Ethernet DA SA 0x8847 LSP Label VC Label FCS Header Payload 8 1518
EoMPLS Usage for DCI End-to-End Loop Avoidance using Edge to Edge LACP On DCI Etherchannel: STP Isolation (BPDU Filtering) Broadcast Storm Control FHRP Isolation Active PW MPLS Core Aggregation Layer DC1 DCI Active PW DCI Aggregation Layer DC2 Encryption Services with 802.1AE Ø Requires a full meshed vpc è 4 PW
EoMPLS Usage for DCI Over IP Core Active PW IP Core Aggregation Layer DC1 DCI Active PW DCI Aggregation Layer DC2 crypto ipsec profile MyProfile set transform-set MyTransSet interface Tunnel100 ip address 100.11.11.11 255.255.255.0 ip mtu 9216 mpls ip tunnel source Loopback100 tunnel destination 12.11.11.21 tunnel protection ipsec profile MyProfile
Dealing with PseudoWire (PW) Failures Remote Ethernet Port Shutdown PE receives the PW down notification and shutdown its transmit signal toward aggregation X Active PW X MPLS Core X Si Si Aggregation Layer DC1 DCI Active PW DCI Aggregation Layer DC2 ASR1000 feature configuration: interface GigabitEthernet1/0/0 xconnect 1.1.1.1 1 pw-class eompls remote link failure notification! (default) Bridged traffic Failover (msec) Fallback (msec) è 281 54 ç 453 300
EoMPLS Deployment on VSS Point to Point EoMPLS with Port-Channel xconnect Local LACP Local LACP Si One PW MPLS Si Si Si Aggregation Layer DC1 VSS VSS Aggregation Layer DC2 Instead of xconnecting physical port, xconnect port-channel LACP is kept local, no more extended over EoMPLS PW is virtual on both VSS members SSO protection in 12.2(33)SXJ Requires VSS or Nexus as DC device Limited support of L3 routing with vpc
Agenda DCI Business Drivers and Solutions Overview LAN Extension Deployment Scenarios Ethernet Based Solutions MPLS Based Solutions EoMPLS VPLS H-VPLS IP Based Solutions LISP for DCI Deployments LISP and Path Optimization LISP and Services (FW, SLB) Integration Summary and Q&A
Multi-Point Topologies What is VPLS? VLAN PW VFI VLAN SVI VFI MPLS Core PW PW SVI One extended bridge-domain built using: VFI = Virtual Forwarding Instance ( VSI = Virtual Switch Instance) PW = Pseudo-Wire SVI = Switch Virtual Interface xconnect VFI SVI VLAN Mac address table population è is pure Learning-Bridge
VPLS Cluster Solutions Using clustering mechanism Two devices in fusion as one VSS Sup720 VSS Sup2T ASR9K nv virtual cluster è One control-plane / two data-planes Dual node is acting as one only device Native redundancy (SSO cross chassis) Native load balancing Capability to use port-channel as attachment circuit SUP720+ES SUP2T ASR9K nv
VPLS Redundancy Making Usage of Clustering Si X Si Si mpls ldp session protection mpls ldp router-id Loopback100 force Si VSS Bridged traffic Failover (msec) è 258 218 ç 162 174 Fallback (msec) LDP session protection & Loopback usage allows PW state to be unaffected LDP + IGP convergence in sub-second Fast failure detection on Carrier-delay / BFD Immediate local fast protection Traffic exit directly from egress VSS node
VPLS Redundancy Making Usage of Clustering X Si Si mpls ldp graceful-restart Si Si If failing slave node: PW state is unaffected VSS Bridged traffic Failover (msec) è 224 412 ç 326 316 Fallback (msec) If failing master node: PW forwarding is ensured via SSO PW state is maintained on the other side using Graceful restart Edge Ether-channel convergence in sub-second Traffic is directly going to working VSS node Traffic exits directly from egress VSS node Quad sup SSO for SUP2T in 1QCY13
VPLS Deployment Considerations Symmetry is Good 10.100.1.1 Problem / Solution sh ip route 10.100.1.1 Known via "ospf 2 via GigabitEthernet1/3/0/1 Route metric is 2 via GigabitEthernet2/3/0/1 Route metric is 2 X Remote VSS are having two un-equal cost path to others, so one only route is put in RIB è Stops forwarding traffic for 2mn when primary route is removed (there is no control-plane to insert backup route) Build a symmetric core with two ECMP paths between each VSS Remark: ASR9K is better supporting asymmetric core
VSS - A-VPLS CLI Available Q4CY12 for SUP2T Si #sh mpls l2 vc Local intf Local circuit Dest address VC ID Status ------------- ------------- ------------ ----- ------ VFI VFI_610_ VFI 10.100.2.2 610 UP VFI VFI_610_ VFI 10.100.3.3 610 UP VFI VFI_611_ VFI 10.100.2.2 611 UP VFI VFI_611_ VFI 10.100.3.3 611 UP Si Si Rem: One PW per VLAN per destination Si interface Virtual-Ethernet1 switchport switchport mode trunk switchport trunk allowed vlan 610-619 neighbor 10.100.2.2 pw-class Core neighbor 10.100.3.3 pw-class Core pseudowire-class Core encapsulation mpls Si Si Any card type facing edge SUP720 + SIP-400 facing core (5Gbps) or SUP720 + ES-40 (40Gbps) support with 12.2(33)SXJ SUP2T Q4CY12
ASR9K VPLS Set-up PW l2vpn router-id 10.0.1.1 bridge group BG bridge-domain BD interface TenGigE0/0/0/4 interface TenGigE0/0/0/5! vfi VFI vpn-id 4003 neighbor 10.0.1.2 pw-id 4003
Agenda DCI Business Drivers and Solutions Overview LAN Extension Deployment Scenarios Ethernet Based Solutions MPLS Based Solutions EoMPLS VPLS H-VPLS IP Based Solutions LISP for DCI Deployments LISP and Path Optimization LISP and Services (FW, SLB) Integration Summary and Q&A
Multi-Tenant Data Center ASR 9000 Wan Connection Intra-DC Inter-POD Routing DCI DCB FCoE LAN traffic L2 (to DCI) + L3 LAN Fabric Path IP Traffic Only FC native FabricPath or vpc Fabric Path Spines Nexus 5500 EoR + Nexus 2232 ToR Rack Rack Rack Rack POD 1 = 1 x Row = 10 x Rack POD N = M x Rows = M x 10 x Rack
DC Access Multi-Homing Solution Summary Highlights Node clustering Multi-chassis LAG REP /REP access gateway MST/PVST access gateway VSS (Catalyst / Cisco 7600-Sup2T) Nv cluster (ASR9k) One control-plane for two chassis Easiness, Active/Active Simple solution for spoke-and-hub topology, works for both bridging and nonbridging access device Standard based solution by using 802.3ad Sub-second convergence Phase 1 implement is active/standby mode. Phase 2 is per VLAN load balancing Ring topology support is under investigation Sub 200msec convergence Good access ring isolation Now standard based à G.8032 (XR4.1 release) Spoke-and-hub and ring topology, not works well for mesh network Standard based solution as long as access network support MST/PVST Works for any access network topology Good access domain isolation Work with 802.1ah PBB Convergence time depends on access network STP
DC Access Multi-Homing Inter Chassis Communication Protocol - ICCP draft-ietf-martini-pwe3-iccp C7600 SRE with ES facing edge ASR9K XR4.0 Redundancy Group Active POA DHD ICCP MPLS ICCP synchronizes event/states between multiple chassis in a redundancy group ICCP runs over reliable LDP / TCP ICCP relies on BFD/IP route-watch as keepalive ICCP message to synch state Ex: LACP, IGMP query Standby POA Terminology: mlacp : Multi-Chassis Link Aggregation Control Protocol MC-LAG : Multi-Chassis Link Aggregation Group DHD : Dual Homed Device (Customer Edge) DHN : Dual Homed Network (Customer Edge) POA : Point of Attachment (Provider Edge)
DC Access Multi-Homing Inter Chassis Communication Protocol - ICCP Multi-Chassis LACP synchronization: LACP BPDUs (01:80:C2:00:00:00) are exchanged on each Link System Attributes: Priority + bundle MAC Address Port Attributes: Key + Priority + Number + State Redundancy Group Active POA DHD ICCP MPLS redundancy iccp group <ig-id> mlacp node <node id> mlacp system mac <system mac> mlacp system priority <sys_prio> member neighbor <mpls device> Standby POA interface <bundle> mlacp iccp-group <ig-id> mlacp port-priority <port prio> interface <physical interface> bundle id <bundle id> mode active Terminology: mlacp : Protocol MC-LAG : DHD : DHN : POA : Multi-Chassis Link Aggregation Control Multi-Chassis Link Aggregation Group Dual Homed Device (Customer Edge) Dual Homed Network (Customer Edge) Point of Attachment (Provider Edge)
MC-LAG to VPLS Testing http://www.cisco.com/en/us/docs/solutions/enterprise/data_center/dci/vpls/vpls_asr9k.html Si MPLS core 1 2 3 4 5 6 7 8 Si Only error 2/3/4 are leading to ICCP convergence Rem: 2 & 4 are dual errors 500 VLAN Unicast: Link error sub-1s & Node error sub-2s 1200 VLAN unicast: Link error sub-2s & Node error sub-4s
Flexible VLAN Handling Ethernet Virtual Circuit - EVC 1. Selective Trunk Support Group multiple VLAN in one only core bridge domain QinQ model VLAN overlapping 2. VLAN translation 121 / 222 / Inter-DC VLAN numbering independency 3. Scale to 4000 * 4000 VLAN Scale above 4000 VLAN 4. Routing for multi-tag Multi-tenant default gateway IRB - IP routing / VRF routing for QinQ tagged frames
E-VPN (aka Routed VPLS) Main Principles Control-Plane Distribution of Customer MAC- Addresses using BGP PE continues to learn C-MAC over AC When multiple PEs announce the same C-MAC, hash to pick one PE MP2MP/P2MP LSPs for Multicast Traffic Distribution MP2P (like L3VPN) LSPs for Unicast Distribution Full-Mesh of PW no longer required!! PE PE BGP PE PE
MPLS DCI Conclusion A Mature Solution EoMPLS DCI is an easy point to point solution VPLS DCI is having two flavors: 1. Cluster Simplicity Very fast convergence Available Cat 6K : SUP720 / SUP2T 7600: SUP2T (Q3CY2012) ASR9K: Nv with multi-tenant features 2. Dual node based on mlacp attachment circuit High-end devices (7600 / ASR9K, ) Multi-tenant features / VLAN Translation High scale High SLA features Standard based
Agenda DCI Business Drivers and Solutions Overview LAN Extension Deployment Scenarios Ethernet Based Solutions MPLS Based Solutions IP Based Solutions OTV Technology Overview OTV Deployment Considerations LISP for DCI Deployments LISP and Path Optimization LISP and Services (FW, SLB) Integration Summary and Q&A 40
Overlay Transport Virtualization Technology Pillars OTV is a MAC in IP technique to extend Layer 2 domains OVER ANY TRANSPORT Dynamic Encapsulation No Pseudo-Wire State Maintenance Optimal Multicast Replication Multipoint Connectivity Point-to-Cloud Model Nexus 7000 First platform to support OTV (since 5.0 NXOS Release) ASR 1000 Now also supporting OTV (since 3.5 XE Release) Protocol Learning Preserve Failure Boundary Built-in Loop Prevention Automated Multi-homing Site Independence 41
Overlay Transport Virtualization OTV Control Plane Edge Device (ED): connects the site to the (WAN/MAN) core and responsible for performing all the OTV functions Internal Interfaces: L2 interfaces (usually 802.1q trunks) of the ED that face the site Join Interface: L3 interface of the ED that faces the core Overlay Interface: logical multi-access multicast-capable interface. It encapsulates Layer 2 frames in IP unicast or multicast headers OTV Overlay Interface Internal Interfaces L2 L3 Join Interface Core
OTV Data Plane Inter-Site Packet Flow MAC TABLE VLAN MAC IF 4 Transport Infrastructure 100 MAC 1 Eth 2 IP A 100 MAC 1 IP A 3 5 IP B OTV OTV OTV OTV 100 MAC 2 Eth 1 Encap 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 Decap MAC TABLE VLAN MAC IF 100 MAC 4 Eth 4 6 Layer 2 Lookup MAC 1 è MAC 3 1 Server 1 West Site East Site MAC 1 è MAC 3 Server 3 7 43
Overlay Transport Virtualization OTV Control Plane Neighbor discovery and adjacency over Multicast (Nexus 7000 and ASR 1000) Unicast (Adjacency Server Mode currently available with Nexus 7000 from 5.2 release) OTV proactively advertises/withdraws MAC reachability (control-plane learning) IS-IS is the OTV Control Protocol - No specific configuration required VLAN MAC IF 4 1 3 New MACs are learned on VLAN 100 Vlan 100 MAC A OTV updates exchanged via the L3 core 3 OTV Update 100 MAC A IP A 100 MAC B IP A 100 MAC C IP A Vlan 100 MAC B Vlan 100 MAC C West 2 IP A 3 OTV Update IP B East VLAN MAC IF 100 MAC A IP A 100 MAC B IP A 4 IP C 100 MAC C IP A South 44
OTV Failure Domain Isolation Spanning-Tree Site Independence Site transparency: no changes to the STP topology Total isolation of the STP domain Default behavior: no configuration is required BPDUs sent and received ONLY on Internal Interfaces OTV OTV The BPDUs stop here The BPDUs L3 stop here L2 45
OTV Failure Domain Isolation Preventing Unknown Unicast Storms No requirements to forward unknown unicast frames Assumption: end-host are not silent or uni-directional Default behavior: no configuration is required OTV MAC TABLE VLAN MAC IF OTV 100 MAC 1 Eth1 100 MAC 2 IP B L3 L2 - - - No MAC 3 in the MAC Table MAC 1 è MAC 3 46
OTV Multi-homing VLANs Split Across AEDs Automated and 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 Remote OTV Device MAC Table VLAN MAC IF 100 MAC 1 IP A 101 MAC 2 IP B OTV-a# show otv vlan OTV Extended VLANs and Edge Device State Information (* - AED) VLAN Auth. Edge Device Vlan State Overlay ---- ------------------ ---------- ------- 100 East-b inactive(non AED) Overlay100 101* East-a active Overlay100 102 East-b inactive(non AED) Overlay100 OTV-b# show otv vlan OTV Extended VLANs and Edge Device State Information (* - AED) IP A AED ODD VLANs OTV OTV- a Overlay Adjacency OTV Site Adjacency* OTV- b Internal peering for AED elec on IP B AED EVEN VLANs VLAN Auth. Edge Device Vlan State Overlay ---- ------------------ ---------- ------- 100* East-b active Overlay100 101 East-a inactive(non AED) Overlay100 102* East-b active 2012 Cisco and/or Overlay100 its affiliates. All rights reserved. *Supported from 5.2 NX-OS release 47
Agenda DCI Business Drivers and Solutions Overview LAN Extension Deployment Scenarios Ethernet Based Solutions MPLS Based Solutions IP Based Solutions OTV Technology Overview OTV Deployment Considerations LISP for DCI Deployments LISP and Path Optimization LISP and Services (FW, SLB) Integration Summary and Q&A 48
Placement of the OTV Edge Device Option 1 - OTV in the DC Core with L3 Boundary at Aggregation Easy deployment for Brownfield L2-L3 boundary remains at aggregation DC Core devices performs L3 and OTV functionalities May use a pair of dedicated Nexus 7000 VLANs extended from aggregation layer L2 Octopus design Recommended to use separate physical links for L2 & L3 traffic STP and L2 broadcast domains not isolated between PODs (Aggregation Blocks) vpc vpc VSS SVIs SVIs SVIs SVIs vpc vpc vpc VSS SVIs SVIs SVIs SVIs vpc 49
Placement of the OTV Edge Device Option 2 - OTV at the Aggregation with L2-L3 Boundary on External Firewalls The Firewalls host the Default Gateway No SVIs at the Aggregation Layer Requires at least a routed link between Aggregation and Core (OTV Join Interface) L3 L2 Def GWY OTV Core OTV Def GWY Aggrega on No SVI supported as Join Interface Firewall Firewall 50
OTV and SVI Routing Introducing the OTV VDC Guideline: The current OTV implementation on the Nexus 7000 enforces the separation between SVI routing and OTV encapsulation for any extended VLAN This separation can be achieved with having two separate devices to perform these two functions An alternative cleaner and less intrusive solution is the use of Virtual Device Contexts (VDCs) available with Nexus 7000 platform: A dedicated OTV VDC to perform the OTV functionalities The Aggregation-VDC used to provide SVI routing support L3 L2 OTV VDC OTV VDC Aggregation 51
Placement of the OTV Edge Device Option 3 OTV in the DC Aggregation L2-L3 boundary at aggregation DC Core performs only L3 role STP and L2 broadcast Domains isolated between PODs Intra-DC and Inter-DCs LAN extension provided by OTV Requires the deployment of dedicated OTV VDCs Ideal for single aggregation block topologies Recommended for Green Field deployments Nexus 7000 required in aggregation SVIs SVIs SVIs SVIs vpc vpc 52
Single Homed OTV VDC Simple Model OTV VDC OTV VDC Link- 1 Link- 3 Link- 1 N7K- A Link- 3 Rou ng VDC N7K- A Po1 Po1 Rou ng VDC Logical View Physical View N7K- B N7K- B Link- 2 Link- 4 OTV VDC OTV VDC Link- 2 Link- 4 May use a single physical link for Join and Internal interfaces Minimizes the number of ports required to interconnect the VDCs Single link or physical node (or VDC) failures lead to AED re-election 50% of the extended VLANs affected Failure of the routed link to the core is not OTV related Recovery is based on IP convergence Layer 3 Layer 2 53
Dual Homed OTV VDC Improving the Design Resiliency N7K- A N7K- B OTV VDC OTV VDC Links 1-2 Link 5 Links 1-2 Link 5 Rou ng VDC Link 6 N7K- A Po1 Logical View Po1 Link 6 Link 8 Rou ng VDC Physical View Layer 3 Layer 2 Link 8 N7K- B Links 3-4 Link 7 OTV VDC OTV VDC Links 3-4 Link 7 Logical Port-channels used for the Join and the Internal interfaces Increases the number of physical interfaces required to interconnect the VDCs Traffic recovery after single link failure event based on port-channel re-hashing No need for AED re-election Physical node (or VDC) failure still requires AED re-election In the current implementation may cause few seconds of outage (for 50% of the extended VLANs) 54
OTV in the DC Aggregation Site Based Per-VLAN Load Balancing OTV VDC Simple Appliance Model Aggrega on OTV VDC AED role negotiated between the two OTV VDCs (on a per VLAN basis) Internal IS-IS peering on the site VLAN AED Recommended to carry the site VLAN on vpc links and vpc peer-link For a given VLAN all traffic must be carried to the AED Device Part of the flows carried across the vpc peer-link Most Resilient Model Optimized traffic flows is achieved in the most resilient model leveraging Port-Channels as Internal Interfaces OTV VDC Aggrega on OTV VDC The AED encapsulates the original L2 frame into an IP packet and send it back to the aggregation layer device AED The aggregation layer device routes the IP packet toward the DC Core/WAN edge L3 routed traffic bypasses the OTV VDC 55
OTV in the DC Aggregation Per-Device Load Balancing DC2-Agg2# sh routing hash 11.2.6.1 11.1.5.1 Load-share parameters used for software forwarding: load-share mode: address source-destination port sourcedestination Universal-id seed: 0x1f64a0a8 Hash for VRF "default" Hashing to path *12.2.4.2 For route: 11.1.5.0/24, ubest/mbest: 2/0 *via 12.2.3.2, Eth2/15, [110/84], 6d23h, ospf-10, intra *via 12.2.4.2, Eth2/16, [110/84], 6d23h, ospf-10, intra To/From Remote AED1 (IP B) IP A AED ECMP Links To/From Remote AED2 (IP C) show port-channel load-balance forwarding-path interface portchannel 1 src-ip <SRC> dst-ip <DST> module <MOD> Unicast traffic directed to (received from) the same remote site (AED) will always use the same physical link OTV encapsulated packets characterized by the same <Src-IP, Dst-IP> information In multipoint deployments unicast traffic may leverage multiple equal cost paths <Dts-IP> value changes with the remote OTV Edge Device (AED1, AED2) Next generation HW (CY12) would allow to achieve flow based load-balancing OTV traffic encapsulated into UDP with variable source port # 56
OTV in the DC Aggregation Using F-Series Linecards F1 and F2 linecards do not support OTV natively As of today, the OTV VDC must use only M-series ports for both Internal and Join Interfaces Recommendation is to allocate M1 only interfaces to the OTV VDC Native OTV support on F-series is targeted for 6.2 release (Q1CY12) 57
OTV in the DC Aggregation Configuration (Multicast Transport) PIM enabled interfaces Routing VDC hostname routing-vdc! interface Ethernet1/1 switchport switchport mode trunk switchport trunk allowed vlan 100,600-700! interface Ethernet2/1 ip address 3.3.3.1/24 ip router ospf 1 area 0.0.0.0 ip ospf passive-interface ip pim sparse-mode ip igmp version 3! ip pim rp-address 33.33.33.33 group-list 224.0.0.0/4 ip pim ssm range 232.0.0.0/8 OTV VDC Routing VDC N7K-Agg1 L3 Link L2 Link Routing VDC e2/1 OTV VDC e2/2 e1/1 e1/2 N7K-Agg2 Establish L3 peering on a dedicated VLAN OTV VDC 2012 Cisco and/or its affiliates. ** All Could rights use reserved. sta c default route or ospf stub hostname otv-vdc feature otv! otv site-vlan 100! interface Ethernet1/2 description Internal Interface switchport switchport mode trunk switchport trunk allowed vlan 100,600-700! interface Ethernet2/2 description Join Interface ip address 3.3.3.2/24 ip igmp version 3! interface Overlay100 otv join-interface Ethernet2/2 otv control-group 239.1.1.2 otv data-group 232.1.1.0/24 otv extend-vlan 600-700! ip route 0.0.0.0 0.0.0.0 3.3.3.1 58
OTV in the DC Aggregation Configuration (Unicast Transport) Routing VDC hostname routing-vdc! interface Ethernet1/1 switchport switchport mode trunk switchport trunk allowed vlan 100,600-700! interface Ethernet2/1 ip address 3.3.3.1/24 ip router ospf 1 area 0.0.0.0 ip ospf passive-interface Release 5.2 and above OTV VDC Routing VDC N7K-Agg1 L3 Link L2 Link Routing VDC e2/1 OTV VDC e2/2 e1/1 e1/2 N7K-Agg2 Establish L3 peering on a dedicated VLAN OTV VDC hostname otv-vdc feature otv! otv site-vlan 100! interface Ethernet1/2 description Internal Interface switchport switchport mode trunk switchport trunk allowed vlan 100,600-700! interface Ethernet2/2 description Join Interface ip address 3.3.3.2/24! interface Overlay100 otv join-interface Ethernet2/2 otv adjacency-server* otv use-adjacency-server 10.1.1.1 11.1.1.1 otv extend-vlan 600-700! ip route 0.0.0.0 0.0.0.0 3.3.3.1 * Needed only on the Adjacency Server 59
OTV in the DC Aggregation HSRP Isolation Configuration 1. Create and apply the policies to filter out HSRP messages (both v1 and v2 in this example) ip access-list ALL_IPs 10 permit ip any any mac access-list ALL_MACs 10 permit any any! ip access-list HSRP_IP 10 permit udp any 224.0.0.2/32 eq 1985 20 permit udp any 224.0.0.102/32 eq 1985! mac access-list HSRP_VMAC 10 permit 0000.0c07.ac00 0000.0000.00ff any 20 permit 0000.0c9f.f000 0000.0000.0fff any! vlan access-map HSRP_Localization 10 match mac address HSRP_VMAC match ip address HSRP_IP action drop! vlan access-map HSRP_Localization 20 match mac address ALL_MACs match ip address ALL_IPs action forward! vlan filter HSRP_Localization vlan-list 600-1000 3. Apply a route-map on the OTV control plane to avoid communicating vmac info to remote OTV edge devices mac-list HSRP-vmac-deny seq 5 deny 0000.0c07.ac00 ffff.ffff.ff00 mac-list HSRP-vmac-deny seq 10 deny 0000.0c9f.f000 ffff.ffff.f000 mac-list HSRP-vmac-deny seq 20 permit 0000.0000.0000 0000.0000.0000! route-map stop-hsrp permit 10 match mac-list HSRP-vmac-deny! otv-isis default vpn Overlay1 redistribute filter route-map stop-hsrp Default VDC Default VDC 2. Configure ARP filtering to ensure ARP replies (or Gratuitous ARP) are not received from the remote site arp access-list HSRP_VMAC_ARP 10 deny ip any mac 0000.0c07.ac00 ffff.ffff.ff00 20 deny ip any mac 0000.0c9f.f000 ffff.ffff.f000 30 permit ip any mac any! feature dhcp ip arp inspection filter HSRP_VMAC_ARP 600-1000 HSRP Traffic 60
OTV in the DC Aggregation Verification DC1-Agg1# sh hsrp Vlan600 DC1-Agg2# - Group 1 sh (HSRP-V1) hsrp (IPv4) Local Vlan600 state is - Active, Group 1 priority (HSRP-V1) 130 (Cfged (IPv4) 130), may preempt Forwarding Local state threshold(for is Standby, vpc), priority lower: 120 upper: (Cfged 130120) Hellotime Forwarding 3 sec, holdtime threshold(for 10 sec vpc), lower: 1 upper: 120 Next hello Hellotime sent in 3 2.999000 sec, holdtime sec(s) 10 sec Virtual Next IP address hello sent is 10.15.0.1 in 1.515000 (Cfged) sec(s) Active Virtual router IP is address local is 10.15.0.1 (Cfged) Standby Active router router is 10.15.0.2 is 10.15.0.3,, priority priority 120 130 expires expires in 4.96 in 5.89 sec(s) Authentication sec(s) text "cisco" Virtual Standby mac address router is is 0000.0c07.ac01 local (Default MAC) 2 state Authentication changes, last text state "cisco" change 3d19h IP redundancy Virtual mac name address is hsrp-vlan600-1 is 0000.0c07.ac01 (default)(default MAC) 1 state changes, last state change 00:02:46 IP redundancy name is hsrp-vlan600-1 (default) DC2-Agg1# sh hsrp Vlan600 DC2-Agg2# - Group sh 1 hsrp (HSRP-V1) (IPv4) Local Vlan600 state - Group is Active, 1 (HSRP-V1) priority 110 (IPv4) (Cfged 110), may preempt Forwarding Local state threshold(for is Standby, vpc), priority lower: 1001 (Cfged upper: 100), 110 may Hellotime preempt 3 sec, holdtime 10 sec Next Forwarding hello sent in threshold(for 2.2000 sec(s) vpc), lower: 1 upper: 100 Virtual Hellotime IP address 3 sec, is holdtime 10.15.0.1 10 (Cfged) sec Active Next router hello sent is local in 1.2000 sec(s) Standby Virtual IP router address is 10.15.0.4 is 10.15.0.1, priority (Cfged) 100 expires in 3.96 sec(s) Authentication Active router text is "cisco" 10.15.0.5, priority 110 expires in 4.29 sec(s) Virtual Standby mac router address is local is 0000.0c07.ac01 (Default MAC) 2 state Authentication changes, last text state "cisco" change 2d2h IP Virtual redundancy mac name address is hsrp-vlan600-1 is 0000.0c07.ac01 (default) (Default MAC) 2 state changes, last state change 1d2h IP redundancy name is hsrp-vlan600-1 (default) Active Standby Active Standby OTV OTV OTV OTV Site DC1 Site DC2 61
Placement of the OTV Edge Device Connecting Brownfield and Greenfield Data Centers OTV OTV Greenfield Greenfield ASR 1K Brownfield L3 OTV Nexus 7K OTV L2 Si Si OTV OTV OTV OTV Nexus 7K Nexus 7K L3 L2 Nexus 7K Si Si L3 L2 L3 L2 FabricPath OTV Virt. Link Leverage OTV capabilities on Nexus 7000 (Greenfield) and ASR 1000 (Brownfield) Build on top of the traditional DC L3 switching model (L2-L3 boundary in Agg, Core is pure L3) Possible integration with the FabricPath/TRILL model 62
Agenda DCI Business Drivers and Solutions Overview LAN Extension Deployment Scenarios Ethernet Based Solutions MPLS Based Solutions IP Based Solutions LISP for DCI Deployments LISP and Path Optimization LISP and Services (FW, SLB) Integration Summary and Q&A 63
Path Optimization and DCI Avoid Suboptimal Traffic Path After Workload Motion 144.254.100.0/25 & 144.254.100.128/25 EEM or RHI can be used to get very granular ISP A DC A Layer 3 Core Ingress Path Optimization: Clients-Server ISP B DC B Agg Server-Server Path Optimization Public Network VLAN A Agg Access DB ü ü Move the whole application tier Optimize the whole path: Client to Server Server to Server Server to Client Access Front-End Data-Base Egress Path Optimization: Server-Client L2 Links (GE or 10GE) L3 Links (GE or 10GE) Egress Path Optimization: Server-Client 64
Outbound Path Optimization FHRP Filtering Filter FHRP with combination of VACL or PACL 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 Filter HSRP HSRP Active HSRP Standby HSRP Active HSRP Standby ARP ARP for HSRP reply VIP V20 V10 65
Inbound Path Optimization Extending Subnets Creates a Routing Challenge A subnet usually implies location LISP site Yet we use LAN extensions to stretch subnets across locations xtr Location semantics of subnets are lost Traditional routing relies on the location semantics of the subnet IP Network Can t tell if a server is at the East or West location of the subnet LAN Extension More granular (host level) information is required West- DC East- DC LISP provides host level location semantics 66
Inbound Path Optimization LISP Host Mobility 1 DNS Entry: D.abc.com A 10.2.0.1 3 Mapping Cache Entry EID-prefix: 10.2.0.1/32 Locator-set: 2.1.1.1, priority: 1, weight: 50 (D1) 2.1.2.1, priority: 1, weight: 50 (D2) 2 10.1.0.1 - > 10.2.0.1 4 1.1.1.1 - > 2.1.1.1 10.1.0.1 - > 10.2.0.1 5 10.1.0.1 - > 10.2.0.1 10.1.0.0/24 LISP Site S ETR West- DC D ITR 1.1.1.1 10.2.0.0/24 IP Network 5.1.1.1 5.3.3.3 2.1.1.1 2.1.2.1 3.1.1.1 3.1.2.1 10.2.0.1 LAN Extension Mapping DB 5.2.2.2 East- DC 67
Inbound Path Optimization LISP Host Mobility DNS Entry: D.abc.com A 10.2.0.1 EID-prefix: 10.2.0.1/32 Locator-set: 3.1.1.1, 2.1.1.1, priority: 1, weight: 50 (D1) 3.1.2.1, 2.1.2.1, priority: 1, weight: 50 (D2) Mapping Cache 7 Entry Update 10.1.0.0/24 LISP Site S ITR 1.1.1.1 8 1.1.1.1 - > 3.1.1.1 10.1.0.1 - > 10.2.0.1 IP Network 5.3.3.3 Mapping DB 5.1.1.1 5.2.2.2 ETR West- DC 2.1.1.1 2.1.2.1 3.1.1.1 3.1.2.1 D 10.2.0.1 9 LAN Extension 10.2.0.0/24 6 Workload Move 10.2.0.1 East- DC 68
LISP Host-Mobility with Extended Configuration ip lisp itr-etr ip lisp database-mapping 10.2.0.0/16 <RLOC-A> p 1 w 10 ip lisp database-mapping 10.2.0.0/16 <RLOC-B> p 1 w 10 lisp dynamic-eid roamer database-mapping 10.2.0.0/24 <RLOC-A> p 1 w 10 database-mapping 10.2.0.0/24 <RLOC-B> p 1 w 10 map-server 1.1.1.1 key abcd map-notify-group 239.10.10.10 ip lisp itr-etr ip lisp database-mapping 10.2.0.0/16 10.3.0.0/16 <RLOC-C> p 1 w 10 ip lisp database-mapping 10.2.0.0/16 1032.0.0/16 <RLOC-D> p 1 w 10 lisp dynamic-eid roamer database-mapping 10.2.0.0/24 <RLOC-C> p 1 w 10 database-mapping 10.2.0.0/24 <RLOC-D> p 1 w 10 map-server 1.1.1.1 key abcd map-notify-group 239.10.10.10 interface vlan 100 interface vlan 100 ip address 10.2.0.2 10.2.0.3 /24 ip address 10.2.0.4 10.2.0.5 /24 lisp mobility roamer lisp mobility roamer lisp extended-subnet-mode lisp extended-subnet-mode hsrp 101 hsrp 101 ip 10.2.0.1 ip 10.2.0.1 LAN Ext. 1.1.1.1 2.2.2.2 A B C D Mapping DB LISP- VM (xtr) West- DC 10.2.0.0 /24 East- DC X Y Z 69
Agenda DCI Business Drivers and Solutions Overview LAN Extension Deployment Scenarios Ethernet Based Solutions MPLS Based Solutions IP Based Solutions LISP for DCI Deployments L3 Host Mobility using LISP LISP and Path Optimization Services (FW, SLB) Integration Summary and Conclusions Q&A 70
LISP and FW Integration Deployment Considerations Option 1 LISP Encap & Decap LISP FW must currently be positioned south of the LISP device No inspection possible for LISP encapsulated traffic, only stateless ACLs are possible when deploying the FW north of the xtr Default Gateway LISP Host Mobility Detetction Option 1: FW in routed mode positioned between the default gateway and the LISP xtr Option 2 Recommended with LISP Multi-hop Mobility enhancements (Q1CY13 for Nexus 7000) Option 2: FW in transparent mode or Virtual Services Gateway (VSG) à simple scenario since LISP xtr remains co-located on default gateway device LISP Default Gateway LISP Default Gateway 71
LISP and FW Deployment Active/Standby Units Deployed in Each Site LISP Host Mobility Detetction LISP Encap & Decap Data Center 1 ESX LISP site Layer 3 Core Def GWY Workload Moves ESX Data Center 2 FWs in separated sites work independently Stateless Active/Active scenario Limit sub-optimal traffic through DCI core FW in different sites are not sync d Policies have to be replicated between sites No state information maintained between sites May drop previously established sessions after workload vmotion Not an issue in cold migration scenarios (like Disaster Recovery for example) 72
LISP and FW Deployment ASA Cluster Deployment Model* LISP Host Mobility Detetction LISP Encap & Decap Data Center 1 ESX * Availability Q3CY12 LISP site Layer 3 Core Cluster Def GWY Workload Moves Data Center 2 ESX FW Clustered spread across mutliple DC locations Stateless clustering approach Every flow is active only on one cluster node Intra-cluster redirection used if traffic is received by a node that does not have state information à needs extended VLAN for that Allows maintaining established sessions after a live workload mobility event Sub-optimal path for already established sessions Optimized path for new sessions 73
LISP and SLB Integration Deployment Considerations SLB VIP is active at one location at a time and represents the LISP EID VIP activity is detected by the LISP Host Mobility logic Migration of workloads belonging to the loadbalanced server farm does not necessarily trigger a VIP move VIP1 Move VIP VIP1 VIP location is updated in LISP only when moved between site Server farm migration use case Desire is to have an automated way to move the VIP between locations DC1 DC2 74
Agenda DCI Business Drivers and Solutions Overview LAN Extension Deployment Scenarios Ethernet Based Solutions MPLS Based Solutions IP Based Solutions LISP for DCI Deployments L3 Host Mobility using LISP LISP and Path Optimization Summary and Q&A 75
Data Center Interconnect - DCI Model Connecting Virtualized Data Centers L2 Domain Elasticity - LAN Extension STP Isola on is the key element Mul point Loop avoidance + Storm- Control Unknown Unicast & Broadcast control Link sturdiness Scale & Convergence OTV OTV Path Optimization - Optimal Routing - Route Portability Considera ons Network and Security services deployment Server- Client Flows Server- Server Flows Path Op miza on Op ons Egress è Addressed by FHRP Filtering Ingress: è Addressed by LISP VM-Mobility Storage Elasticity - SAN Extensions LAN Extensions OTV Sync or Async replication modes are driven by the applications, hence the distance/latency is a key component to select the choice OTV VN-link notifications Localization of Active Storage is key è Distance can be improved using IO accelerator or caching è Virtual LUN is allowing Active/Active 76
Data Center Interconnect Where to Go for More Information http://www.cisco.com/go/dci http://www.cisco.com/en/us/netsol/ns749/networking_solutions_sub_program_home.html 77
Complete Your Online Session Evaluation Give us your feedback and you could win fabulous prizes. Winners announced daily. Receive 20 Passport points for each session evaluation you complete. Complete your session evaluation online now (open a browser through our wireless network to access our portal) or visit one of the Internet stations throughout the Convention Center. Don t forget to activate your Cisco Live Virtual account for access to all session material, communities, and on-demand and live activities throughout the year. Activate your account at the Cisco booth in the World of Solutions or visit www.ciscolive.com. 78
Final Thoughts Get hands-on experience with the Walk-in Labs located in World of Solutions, booth 1042 Come see demos of many key solutions and products in the main Cisco booth 2924 Visit www.ciscolive365.com after the event for updated PDFs, ondemand session videos, networking, and more! Follow Cisco Live! using social media: Facebook: https://www.facebook.com/ciscoliveus Twitter: https://twitter.com/#!/ciscolive LinkedIn Group: http://linkd.in/ciscoli 79