Overlay Transport Virtualisation
Overlay Transport VirtualisationBRKDCT-2049Justin CookeTechnical Solutions Architect
OTV – Overlay Transport Virtualisation Simplifying Data Centre InterconnectAny WorkloadBRKDCT-2049Anytime 2013 Cisco and/or its affiliates. All rights reserved.AnywhereCisco Public3
Session Objectives The main goals of this session are: This session features a detailed analysis of the architectural aspects anddeployment benefits behind OTV The attendees will learn how OTV is aimed at providing Layer 2 connectivitybeyond the Layer 3 boundary while maintaining the failure containment andoperational simplicity that the Layer 3 boundary provides The attendees will get a deep knowledge of how the OTV control-plane anddata-plane work to provide the VLAN extensionBRKDCT-2049 2013 Cisco and/or its affiliates. All rights reserved.Cisco Public4
Session Non-objectives This session does not include: In depth discussion of Path Optimisation technologies (DNS, LISP, etc.) Storage extension considerations associated to DCI deployments Workload mobility application specific deployment considerationsBRKDCT-2049 2013 Cisco and/or its affiliates. All rights reserved.Cisco Public5
Related Cisco Live RKARC-3470BRKDCT-2049Session NameReal World Data Centre Deployments and Best PracticesHow to Achieve True Active-Active Data Centre InfrastructuresDeployment Challenges with Interconnecting Data CentresCisco Nexus 7000 Switch Architecture 2013 Cisco and/or its affiliates. All rights reserved.Cisco Public6
Agenda Distributed Data Centres: Goals and Challenges OTV Architecture Principles OTV Design Considerations & New FeaturesBRKDCT-2049 2013 Cisco and/or its affiliates. All rights reserved.Cisco Public7
Distributed Data Centres Goals Ensure business continuityDistributed applicationsSeamless workload mobilityMaximize compute resourcesBRKDCT-2049 2013 Cisco and/or its affiliates. All rights reserved.Cisco Public8
Data Centre InterconnectTraditional Layer 2 ExtensionsEoMPLS VSS & vPC or FabricPathEthernet– Applies easily for dual site interconnection– Over dark fibre or protected D-WDM– Easy crypto using end-to-end 802.1AEIP OTV – Overlay Transport VirtualisationVPLS– MAC in IPDark Fibre EoMPLS & VPLS & A-VPLS & H-VPLSMPLS– PE style– Multi-tenants– Most deployed todayBRKDCT-2049 2013 Cisco and/or its affiliates. All rights reserved.Cisco Public9
Challenges in Traditional Layer 2 VPNsFlooding BehaviourPseudo-wire MaintenanceMulti-Homing- Unknown Unicastfor MAC propagation- Unicast Flooding reachesall sites- Full mesh of Pseudo-wireis complex- Head-End replication isa common problem- Requires additionalProtocols & extends STP- Malfunctions impactsmultiple sitesBRKDCT-2049 2013 Cisco and/or its affiliates. All rights reserved.Cisco Public10
Technology Pillars
No Pseudo-WireState MaintenanceOptimal MulticastReplicationDynamic EncapsulationMultipoint ConnectivityBRKDCT-2049 2013 Cisco and/or its affiliates. All rights reserved.Point-to-Cloud ModelCisco Public12
Preserve Failure BoundaryBuilt-in Loop PreventionProtocol LearningAutomated Multi-HomingBRKDCT-2049 2013 Cisco and/or its affiliates. All rights reserved.Site IndependenceCisco Public13
OTV – Overlay Transport VirtualisationSimplifying Data Centre InterconnectAny WorkloadAnytimeAnywhere Nexus 7000 First platform to support OTV (since 5.0 NXOS Release) ASR 1000 Now also supporting OTV (since 3.5 XE Release)BRKDCT-2049 2013 Cisco and/or its affiliates. All rights reserved.Cisco Public14
Agenda Distributed Data Centres: Goals andChallenges OTV Architecture Principles––––––Control Plane and Data PlaneFailure IsolationMulti-homingL2 Multicast ForwardingQoS and ScalabilityPath Optimisation OTV Design Considerations & NewFeaturesBRKDCT-2049 2013 Cisco and/or its affiliates. All rights reserved.Cisco Public15
TerminologyOTV Devices and InterfacesOTV EdgeDevice Edge Device– Performs all OTV functionality– Usually located at the Aggregation Layer orat the Core LayerOTV EdgeDeviceCore Device– Support for multiple OTV Edge Devices(multi-homing) in the same siteAggregation Device Internal Interface– Site facing Interfaces of the Edge Devices– Carry VLANs extended through OTVOTV InternalInterfaces– Regular Layer 2 interfaces– No OTV configuration requiredOTV Internal Interface– Supports IPv4 & IPv6OTV Join InterfaceBRKDCT-2049OTV Overlay Interface 2013 Cisco and/or its affiliates. All rights reserved.Cisco Public16
TerminologyOTV Devices and Interfaces Join InterfaceOTV JoinInterfaceOverlay Interface– One of the uplink of the Edge Device– Point-to-point routed interface (physicalinterface, sub-interface or port-channelsupported)OTV EdgeDeviceCore Device– Used to physically “join” the Overlay network– No OTV specific configuration requiredAggregation Device– IPv4 only Overlay Interface– Virtual interface with most of the OTVconfigurationOTV Internal Interface– Logical multi-access multicast-capableinterfaceOTV Join InterfaceOTV Overlay Interface– Encapsulates Layer 2 frames in IP unicastor multicastBRKDCT-2049 2013 Cisco and/or its affiliates. All rights reserved.Cisco Public17
OTV Control PlaneBuilding the MAC Tables No unknown unicast flooding (selective unicast flooding in 6.2)Control Plane Learning with proactive MAC advertisementBackground process with no specific configurationIS-IS used between OTV Edge DevicesMAC AddressesAdvertisementsOTVOTVIP AIP BEastWestIP COTVSouthBRKDCT-2049 2013 Cisco and/or its affiliates. All rights reserved.Cisco Public18
OTV Control PlaneNeighbour Discovery and Adjacency Formation Before any MAC address can be advertised the OTV Edge Devicesmust:‒ Discover each other‒ Build a neighbour relationship with each other Neighbour Relationship built over a transport infrastructure:‒ Multicast-enabled (all shipping releases)‒ Unicast-only (from NX-OS release 5.2 & IOS-XE 3.9)BRKDCT-2049 2013 Cisco and/or its affiliates. All rights reserved.Cisco Public19
OTV Control PlaneNeighbour Discovery (over Multicast Transport)Multicast-enableTransportOTV Control PlaneOTVOTVOTV Control PlaneIP AIP BEastWestEnd ResultMechanism Edge Devices (EDs) join anmulticast group in the transport, asthey were hosts (no PIM on EDs) OTV hellos and updates areencapsulated in the multicast groupBRKDCT-2049 2013 Cisco and/or its affiliates. All rights reserved. Adjacencies are maintainedover the multicast group A single update reaches allneighboursCisco Public20
OTV Control Plane (Multicast Transport)NeighbourNeighbourWestIP Addr3OTV HelloOTV Control Plane4OTV HelloIP A G7OTVOTVIP AddrIP AOTV HelloOTV Control PlaneMulticast-enabledTransportIP AWestIGMP Join GIP BOTV HelloOTV HelloIP A GEast6EncapDecapIGMP Join G1OTV HelloOTV HelloAll edge devices joinOTV control-group GIP A GIP A G5Transport natively replicatesmulticast to all OIFs2IGMP Join GMulticast state for group Gestablished throughout transportDecap6IP COTVOTVHelloHelloOTVIP A GOTV Control Plane7BRKDCT-2049OTV HelloNeighbourIP AddrWestIP A 2013 Cisco and/or its affiliates. All rights reserved.SouthCisco Public21
OTV Control Plane (Multicast Transport)NeighbourSouthOTV HelloIP AddrIP CBidirectionaladjacency formed5OTV Control Plane5OTVOTVIP C GOTVOTV HelloHelloNeighbourWestSouthOTV HelloOTV Control PlaneMulticast-enabledTransportIP AIP BOTVOTV HelloHelloIP C GEastWest4IP AddrIP AIP CDecapDecap43OTV HelloOTV HelloIP C GIP C GEncapThe South Site creates itshello with West’s addressin the TLV2IP COTVOTV HelloIP C GOTV Control Plane1BRKDCT-2049OTV HelloNeighbourIP AddrWestIP A 2013 Cisco and/or its affiliates. All rights reserved.SouthCisco Public22
OTV Control PlaneCraft OTV2 update withnew MACsMAC Advertisements (over Multicast Transport)VLAN100Update AOTVWestMAC TableVLAN100100101100102MACMAC AMAC BMAC CMulticast-enabledTransportIP A GUpdate A6East5EncapMAC TableDecap4Update AUpdate AIP AIP AIP AIP A GUpdateUpdateAA3IFe1/1e1/1e1/1MAC IFMAC A100 AMAC BUpdate100MAC COTVIP A GIP A GVLAN100101102MACMAC AMAC BMAC CIFIP AIP AIP AAdd MACslearnedthrough OTV1New MACs learnedin VLANs that areOTV 0MAC IFMAC A100MACABUpdate100MAC CIP AIP AIP AIP A GMAC TableSouth 2013 Cisco and/or its affiliates. All rights reserved.VLAN100100101100102MACIFMAC AIP AMAC BIP ACiscoIPPublicMAC CA7Add MACslearnedthrough OTV23
Multicast TransportOTV Control and Data Plane over Multicast Transport Use a High-Available MulticastRendez-Vous Point (RP)configuration‒ PIM Anycast (RFC4610) or MSDP(Multicast Source Discovery Protocol) Requirements to Control Plane‒ PIM Any-Source-Multicast (ASM)Sparse-Mode Requirements to Data Plane‒ PIM Source-Specific-Multicast (SSM)or BiDirExample:Multicast for OTV onNexus 7000feature pim!interface loopback 0ip pim spare-modeip address 192.168.1.100/32!interface loopback 1ip pim sparse-modeip address 10.254.254.n1-x/32!ip pim rp-address 192.168.1.100ip pim anycast-rp 192.168.1.100ip pim anycast-rp 192.168.1.100ip pim ssm range 232.239.1.0/24!interface port-channel1# This Interface peers with theip igmp version3group-list 239.1.1.110.254.254.n110.254.254.n2OTV Join Interface* “n” in the last Octet reflects a unique IP address perRouter joining the PIM Anycast GroupBRKDCT-2049 2013 Cisco and/or its affiliates. All rights reserved.Cisco Public24
Release 5.2and aboveOTV Control PlaneNeighbour Discovery (Unicast-only Transport) Ideal for connecting a small number of sites With a higher number of sites a multicast transport is the best choiceUnicast-onlyTransportOTV Control PlaneOTVOTVOTV Control PlaneIP AIP BEastWestMechanismEnd Result Edge Devices (EDs) register withan “Adjacency Server” ED EDs receive a full list ofNeighbours (oNL) from the AS OTV hellos and updates areencapsulated in IP and unicastto each neighbourBRKDCT-2049 2013 Cisco and/or its affiliates. All rights reserved.Neighbour Discovery is automatedbythe “Adjacency Server”All signalling must be replicated foreach neighbourData traffic must also be replicatedatCisco Publicthe head-end25
OTV Control PlaneCLI Verification Establishment of control plane adjacencies between OTVEdge Devices (multicast or unicast transport):dc1-agg-7k1# show otv adjacencyOverlay Adjacency databaseOverlay-Interface 42:Dest Addr20.11.23.220.12.23.220.22.23.2Up Time15:08:5315:43:2714:49:11Adj-StateUPUPUP Unicast MAC reachability information:dc1-agg-7k1# show otv routeOTV Unicast MAC Routing Table For Overlay100VLAN MAC-AddressMetric UptimeOwner---- -------------- ------ -------- --------2001 0000.0c07.ac01 13d15hsite2001 0000.1641.d70e 13d15hsite2001 0000.49f3.88ff 422d22hoverlay2001 0000.49f3.8900 422d22hoverlayBRKDCT-2049 2013 Cisco and/or its affiliates. All rights /2dc2-agg-7k1dc2-agg-7k2Local SiteMACRemote SiteMACCisco Public26
OTV Data PlaneInter-Site Packet Flow4TransportInfrastructureMAC TABLEVLAN1002Layer2LookupMACIFMAC 1Eth 2100 OTV MAC 2Eth 1100MAC 3IP B100MAC 4IP BMAC 1 MAC 31BRKDCT-2049Server 1IP AOTV3EncapMAC 1 MACIP A IP B3WestSiteMAC TABLEDecap5 IP BOTVMAC 1 MACMAC 1 MAC 3 IP A IP B3VLANMACIF100MAC 1IP AOTV100MAC 2IP A100MAC 3Eth 3100MAC 4Eth 46Layer2LookupMAC 1 MAC 3EastSiteServer 37 2013 Cisco and/or its affiliates. All rights reserved.Cisco Public27
OTV Data PlaneEncapsulation 42 Bytes overhead to the packet IP MTU size (IPv4 packet) 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 OTVshim header Outer OTV shim header contains VLAN, overlay number, etc.802.1Q header removed Consider Jumbo MTU Sizing802.1802.1QDMAC6BSMAC6BEtherType2BIP Header20B* The 4 Bytes of .1Q header havealready been removedBRKDCT-2049DMACOTV al L2 Frame 2013 Cisco and/or its affiliates. All rights reserved.20B 8B 14B* 42 Bytesof total overheadCisco Public28
Agenda Distributed Data Centres: Goals and Challenges OTV Architecture Principles– Control Plane and Data Plane– Failure Isolation– Multi-homing– L2 Multicast Forwarding– QoS and Scalability– Path Optimisation OTV Design Considerations & New FeaturesBRKDCT-2049 2013 Cisco and/or its affiliates. All rights reserved.Cisco Public29
Spanning-Tree and OTVSite Independence Site transparency: no changes to theSTP topology Total isolation of the STP domain Default behaviour: noconfiguration is required BPDUs sent and received ONLY onInternal InterfacesBRKDCT-2049 2013 Cisco and/or its affiliates. All rights reserved.OTVThe BPDUsstop hereOTVL The BPDUsstop here3L2Cisco Public30
Unknown Unicast and OTVNo Longer Unknown Unicast Storms Across the DCI No requirements to forwardunknown unicast frames Assumption: end-host are not silentor uni-directionalMAC TABLEVLANOTVOTVL3LMACIF100MAC 1Eth1100MAC 2IP B--- Default behaviour: noconfiguration is required2No MAC 3 in theMAC TableMAC 1 MAC 3BRKDCT-2049 2013 Cisco and/or its affiliates. All rights reserved.Cisco Public31
NewRelease 6.2Unknown Unicast and OTVSelective Unicast Flooding Some Application requirement toforward unknown unicast frames Selective Unicast Flooding can beenabled per mac address Default behaviour: no unknownunicast forwardingEnable Floodingfor MAC .0101Unknown 1111FwdOverlay1OTV-a # confEnter configuration commands, one per line. End withCNTL/ZOTV-a(config)# otv flood mac 0000.2102.1111 vlan 172BRKDCT-2049 2013 Cisco and/or its affiliates. All rights reserved.OTVOTVL3L2MAC 1 MAC 3VLAN 100MAC 6 MAC 7VLAN 102Cisco Public32
New:Release 6.1Controlling ARP TrafficARP Neighbour-Discovery (ND) Cache ARP cache maintained in Edge Device by snooping ARP replies First ARP request is broadcasted to all sites. Subsequent ARP requestsare replied by local Edge Device Timeout can be adjusted (as per NX-OS 6.1(1)) Drastic reduction of ARP traffic on DCI ARP spoofing can be disabled IPv4 only feature Default behaviour: no configuration is requiredOTV-a(config)# interface overlay 1OTV-a(config-if-overlay)# no otv surpress-arp-nd# Allows ARP requests over an overlay network anddisables ARP caching on edge devices. This commanddoes not support IPv6.BRKDCT-2049 2013 Cisco and/or its affiliates. All rights reserved.OTV-a(config)# interface overlay 1OTV-a(config-if-overlay)# otv arp-nd timeout 70# Configures the time, in seconds, that an entryremains in the ARP-ND cache.The time is in seconds varying from 60 to 86400. Thedefault timeout value is 480 seconds.Cisco Public33
Agenda Distributed Data Centres: Goals and Challenges OTV Architecture Principles– Control Plane and Data Plane– Failure Isolation– Multi-homing– L2 Multicast Forwarding– QoS and Scalability– Path Optimisation OTV Design Considerations & New FeaturesBRKDCT-2049 2013 Cisco and/or its affiliates. All rights reserved.Cisco Public34
OTV Multi-HomingFully Automated Multi-homing No additional protocols required(i.e. BGP) OTV site-vlan used to discover OTVneighbour in the same site Authoritative Edge Device (AED)Election takes place Extended VLANs are split across theAEDs The AED is responsible for:AEDOTVOTVSite AdjacencyAEDL3L2‒ MAC address advertisement for itsVLANs‒ Forwarding its VLANs’ traffic insideand outside the siteBRKDCT-2049 2013 Cisco and/or its affiliates. All rights reserved.Site Adjacency used for AED electionCisco Public35
Release 5.2and aboveHardened Multi-HomingIntroducing OTV Site-identifier Same site devices must use commonsite-identifier Site-id information is included in thecontrol plane Makes OTV multi-homing morerobust and resilient‒ Site Adjacency and OverlayAdjacency are now both leveraged forAED electionOverlay AdjacencyAEDAEDL3L2feature otvotv site-identifier 0x1otv site-vlan 99‒ Site and Overlay Adjacency are bothleveraged for AED election 2013 Cisco and/or its affiliates. All rights reserved.OTVSite Adjacency An overlay will not come up until asite-id is configuredBRKDCT-2049OTVCisco Public36
OTV Multi-HomingRemote OTV DeviceMAC TableVLANs Split across AEDs Automated and deterministic algorithm In a dual-homed site:VLANMACIF100MAC 1IP A101MAC 2IP B– Lower IS-IS System-ID (Ordinal 0) EVENVLANs– Higher IS-IS System-ID (Ordinal 1) ODD VLANsAEDIP AODD VLANsOTVOTV-a# show otv vlanOverlay AdjacencyOTVAEDIP BEVEN VLANsOTV Extended VLANs and Edge Device State Information (* - AED)VLAN---100101*102Auth. Edge Device-----------------East-bEast-aEast-bVlan State---------inactive(Non AED)activeinactive(Non e AdjacencyOTV-aOTV-bOTV-b# show otv vlanOTV Extended VLANs and Edge Device State Information (* - AED)VLAN---100*101102*BRKDCT-2049Auth. Edge Device-----------------East-bEast-aEast-bVlan State---------activeinactive(Non 100 2013 Cisco and/or its affiliates. All rights reserved.Cisco Public37
OTV Multi-HomingAED and Broadcast Handling1.2.3.4.Broadcast reaches all the Edge Devices within the siteOnly the AED forwards the traffic to the OverlayAll the Edge Devices at the other sites receive the broadcastAt the remote sites only the AEDs forward it into the siteOTVBroadcaststops hereOTVBroadcaststops hereOTVBcastpktOTVCoreAEDAEDBRKDCT-2049 2013 Cisco and/or its affiliates. All rights reserved.Cisco Public38
Agenda Distributed Data Centres: Goals and Challenges OTV Architecture Principles– Control Plane and Data Plane– Failure Isolation– Multi-homing– Mobility– L2 Multicast Forwarding– QoS and Scalability– Path Optimisation OTV Design Considerations & NewFeaturesBRKDCT-2049 2013 Cisco and/or its affiliates. All rights reserved.Cisco Public39
OTV and MAC MobilityMAC Moving and OTV Updates (1)1. Workload moved between Data Centre sitesVM MovesOTVOTVMAC XMACXMAC XOTVESXOTVMAC XESXCoreMAC XMAC XAEDAEDBRKDCT-2049 2013 Cisco and/or its affiliates. All rights reserved.Cisco Public40
OTV and MAC MobilityMAC Moving and OTV Updates (2)1. Workload moved between Data Centre sites2. Workload is detected in East DC and OTV control plane is triggered2.3) AED advertises MACX with a metric of zeroOTVOTVMAC XMAC XMACXMAC XMAC XOTVESXCoreOTVMAC XMAC XMAC XMAC XMAC XMAC XAEDAED2.4) EDs in site West see MAC X advertisement with abetter metric from site East and change them to remoteMAC address.BRKDCT-2049 2013 Cisco and/or its affiliates. All rights reserved.ESX2.2) AED detectsMAC X is now localCisco Public2.1) Server originatesa Gratuitous ARP(GARP) frame41
OTV and MAC MobilityMAC Moving and OTV Updates (3)1. Workload moved between Data Centre sites2. Workload is detected in East DC and OTV control plane is triggered3. East to West OTV data plane traffic allows to update the MAC tables ofthe L2 devices in West Site3.2) AED in site West forwards the GARPinto the site and the L2 switches updatetheir CAM tablesOTVOTVMAC XMAC XMACXMAC XOTVCoreOTVESXMAC XMAC XMAC XMAC XAEDESX3.1) AED in site East forwardsthe GARP broadcast frameacross the overlayAEDNote: GARP is used as example traffic, same behaviour is achieved with any other L2 broadcast frames exchangedBRKDCT-2049 2013 Cisco and/or its affiliates. All rights reserved.Cisco Public42
Agenda Distributed Data Centres: Goals and Challenges OTV Architecture Principles– Control Plane and Data Plane– Failure Isolation– Multi-homing– L2 Multicast Forwarding– QoS and Scalability– Path Optimisation OTV Design Considerations & NewFeaturesBRKDCT-2049 2013 Cisco and/or its affiliates. All rights reserved.Cisco Public43
L2 Multicast Traffic Between SitesMulticast Enabled Transport OTV can leverage the multicast support available in the transportnetwork to optimise the delivery of the multicast traffic for the VLANsstretched across sites Three steps:1. Automated mapping of the sites’ multicast groups to a range of multicastgroups in the transport network2. Creation of the Multicast state information at the OTV Edge Devices3. Sites’ Multicast traffic delivered over the OverlayBRKDCT-2049 2013 Cisco and/or its affiliates. All rights reserved.Cisco Public44
L2 Multicast with Multicast TransportStep 1 – Mapping of the Site Multicast Group The site multicast groups are mapped to a SSM group range in the core Each (S1,Gs1) maps to a different SSM group in round-robin fashion3) The West ED communicates themapping information (including thesource VLAN) to the other EDsMcast Group Mapping1) The Mcast sourcestarts sending traffic tothe group Gs1Site GroupCore GroupGs1Gd1Gs2Gd21Mcast Stream2OTV3The Mapping iscommunicated tothe other EDsMulticast-enabledTransportMapping to aDelivery GroupOTVS1 Gs1S1WestS2 Gs2S24IP BIP AEastOTV2) The West ED maps(S1,Gs1) to a deliverygroup Gd1IP CSouth4) Same process happens oncesource S2 is enabled (sending toa different group Gs2)BRKDCT-2049 2013 Cisco and/or its affiliates. All rights reserved.Cisco Public45
L2 Multicast with Multicast TransportStep 2 – Multicast State Creation3.1) ED Announces thereceivers in a GroupMembership Update (GMUpdate) to all other EDs4) The source ED adds theOverlay interface to theOutbound Interfaces (OIF)OIF-ListGroupIFGs1 Gd1OverlayOTV2) The OTV ED snoopsthe IGMP join (withoutforwarding it)Multicast-enabledTransport4Receive GM-UpdateUpdate OIL2Client IGMPsnoop3.1 GM-UpdateOTV11) A receiver in the Eastsite sends an IGMP joinfor Gs1Client IGMPreport to joinGs1S1 Gs1S1WestIP ASSM Treefor Gd15) The SSM tree for Gd1(rooted at the source ED) is IPbuilt in the core)3.2OTVCIP BIGMPv3 reportto join (IP A,Gd1) , the SSMgroup in theCore.Receiver(for Gs1)East3.2) ED Sends an IGMPv3Southreport to join the (IP A, Gd1)SSM group in the coreIt is important to clarify that the edge devices join the core multicast groups as hosts, not as routers!BRKDCT-2049 2013 Cisco and/or its affiliates. All rights reserved.Cisco Public46
L2 Multicast with Multicast TransportStep 3 – Multicast Packet FlowOIF-List1LookupGroupIFGs1 icationOTVOTVS1 Gs1s1 Gs1S1S1 Gs1IP A Gd1EastOTV2Encap4IP CS1 Gs1IP A Gd1SouthDecapBRKDCT-2049S1 Gs1Receiver(for Gs1)IP4 BIP AWestIP A Gd1 2013 Cisco and/or its affiliates. All rights reserved.Decap5S1 Gs1Receiver(for Gs1)5Cisco Public47
L2 Multicast with Multicast TransportMulticast Groups in the CoreOTV can leverage the benefits of a multicast-enabled transport for bothcontrol and data planes. The following summarises the requirements for amulticast transport: Control group – Single PIM-SM or PIM-Bidir group used to formadjacencies and exchange MAC reachability information Data groups – Range of SSM groups used to carry multicast data trafficgenerated by the sitesinterface Overlay100otv join-interface e1/1otv control-group 239.1.1.1otv data-group 232.192.1.0/24otv extend-vlan 100-150The right number of SSM groups to be used depends on a tradeoff between theamount of multicast state to be maintained in the core and the optimisation of Layer2 multicast traffic deliveryBRKDCT-2049 2013 Cisco and/or its affiliates. All rights reserved.Cisco Public48
Agenda Distributed Data Centres: Goals and Challenges OTV Architecture Principles– Control Plane and Data Plane– Failure Isolation– Multi-homing– L2 Multicast Forwarding– QoS and Scalability– Path Optimisation OTV Design Considerations & NewFeaturesBRKDCT-2049 2013 Cisco and/or its affiliates. All rights reserved.Cisco Public49
Release 5.2and aboveQoS and OTVMarking on Encapsulation On Encapsulation– CoS bits (802.1p) copied to the OTV shim header– If IP traffic: The original (inner) DSCP value is also copied to “outer” DSCPDMACSMAC802.1QETHERTYPECoS802.1pIP (optional)Inner DSCPOTV1OTV802.1QWestIP (optional)Outer DSCPIP AOTVOTVshimOriginal FrameIP BEast2EncapBRKDCT-2049 2013 Cisco and/or its affiliates. All rights reserved.Cisco Public50
Release 5.2and aboveQoS and OTVMarking on De-capsulation On De-capsulation– CoS value is recovered from the OTV shim and added to the 802.1Q header Original CoS and DSCP are both preserved OTV Control Traffic is statically marked at CoS 6/DSCP 48OTVWestDecapIP AIP (optional)Outer DSCPOTVOTVshim1OTV2Original Frame802.1QIP BEastDMACSMAC802.1QCoS802.1pBRKDCT-2049 2013 Cisco and/or its affiliates. All rights reserved.Cisco PublicETHERTYPEIP (optional)Inner DSCP51
Release 6.2OTV ScalabilityCurrent and Future Supported Values1500NX-OS 6.28*NX-OS 5.26*Sites*two ED per SiteBRKDCT-204925632k400016k2000OTV extended MAC addressesMulticastVLANsacross all theData Groupsextended VLANs 2013 Cisco and/or its affiliates. All rights reserved.Cisco Public52
Agenda Distributed Data Centres: Goals and Challenges OTV Architecture Principles– Control Plane and Data Plane– Failure Isolation– Multi-homing– L2 Multicast Forwarding– QoS and Scalability– Path Optimisation OTV Design Considerations & NewFeaturesBRKDCT-2049 2013 Cisco and/or its affiliates. All rights reserved.Cisco Public53
Path OptimisationEgress Routing OptimisationHot Potato RoutingBRKDCT-2049 2013 Cisco and/or its affiliates. All rights reserved.Cisco Public54
Path OptimisationEgress Routing with LAN Extension Extended VLANs typically have associated HSRP groups By default, only one HSRP router elected active, with all servers pointingto HSRP VIP as default gatewayPacket fromVlan for10 to Vlan 20ARPHSRP HellosDMAC DGWHSRPVIP Result: sub-optimal routingARP tenPacket fromVlan 10 to Vlan 20DMAC Host Vlan 20VLAN20BRKDCT-2049 2013 Cisco and/or its affiliates. All rights reserved.Cisco PublicVLAN1055
Egress Routing LocalisationFHRP Filtering Solution Filter FHRP with combination of VACL and MAC route filter Result: Still have one HSRP group with one VIP, but now have activerouter at each site for optimal first-hop routingHSRP Hellos HSRP HellosHSRP tenStandbyARP forHSRP VIPARP replyVLAN20BRKDCT-2049 2013 Cisco and/or its affiliates. All rights reserved.Cisco PublicVLAN1056
Path OptimisationOptimal Routing Challenges Layer 2 extensions represent a challenge for optimal routing Challenging placement of gateway and advertisement of routingprefix/subnetWANIngress:North-South /Client-ServerIngress:North-South /Client-ServerHSRP st-West /Server-ServerEgress:South-North /Server-ClientBRKDCT-2049Egress:South-North /Server-Client 2013 Cisco and/or its affiliates. All rights reserved.Cisco Public57
Path OptimisationIs it relevant to my Data Centre model? Logical Data Centre or Physical Data Centre? High Availability or Disaster Recovery?Ingress:North-South /Client-ServerWANIngress:North-South /Client-ServerIs this ONE Logical Data Centre ?Or do I have TWO(High Availability) separated DataPhysical & LogicalCentre?East-West / Server-ServerEgress:South-North /Server-ClientBRKDCT-2049Egress:South-North /Server-Client 2013 Cisco and/or its affiliates. All rights reserved.Cisco Public58
Release 5.2and aboveSpecific Use-CaseIPv6 and OTV IPv6 Unicast Forwarding and Multicast Flooding supported across OTV- Requires to disable optimised multicast forwarding (OMF) in IGMP snooping on OTV ED IPv6 Transport Network (Join Interface & Source Interface, not yetsupported)OTVOTVDCWestDCOTV Edge Device (VDC)EastGlobal (all VLAN):no ip igmp snooping optimise-multicast-floodOTVvPC/vPC DomainBRKDCT-2049Per VLAN with IPv6 TrafficOTVvlan vlan-idvlan configurationno ip igmp snooping optimise-multicast-flood 2013 Cisco and/or its affiliates. All rights reserved.Cisco Public59
Ingress Routing LocalisationPossible SolutionsChallenge Subnets are spread across locations Subnet information in the routing tablesis not specific enough Routing doesn’t know if a server hasmoved between locations Traffic may be sent to the locationwhere the application is not availableOptions DNS Based Route Injection LISP – Locator/ID Separation ProtocolFor more details on LISP and OTV Deployment see: BRKDCT-2615BRKDCT-2049 2013 Cisco and/or its affiliates. All rights reserved.Cisco Public60
OTV – Overlay Transport VirtualisationSimplifying Data Centre InterconnectAny WorkloadBRKDCT-2049Anytime 2013 Cisco and/or its affiliates. All rights reserved.AnywhereCisco Public61
Agenda Distributed Data Centres: Goals and Challenges OTV Architecture Principles OTV Design Considerations & NewFeaturesBRKDCT-2049 2013 Cisco and/or its affiliates. All rights reserved.Cisco Public62
OTV SupportASR1000 OTV has been introduced in IOS XE 3.5 (Nov 2011) To use OTV on ASR1000, you require:–Advance Enterprise Image or Advance IP Service OTV feature license ASR1k - N7k Inter-Site Interoperability has been tested– No ASR1k - N7k Multihoming Support (Intra-Site Interoperability) OTV on ASR1000 Use Cases are:– Legacy Deployments – where DC may still be Catalyst based– New Small Data Centre and/or Disaster Recovery Sites – where Main DC isequipped with Nexus 7000– OTV with Layer-3 Encryption – where MACSec is no option for Inter-DCEncryptionBRKDCT-2049 2013 Cisco and/or its affiliates. All rights reserved.Cisco Public63
OTV SupportASR 1000 New Features for IOS-XE 3.9– OTV Adjacency Server (unicast)– OTV with LISP ESM– RPVST STP Support New Features for IOS-XE 3.10– Portchannel for join interface– VRF Aware– Subinterface for join interface– Layer 2 portchannelBRKDCT-2049 2013 Cisco and/or its affiliates. All rights reserved.Cisco Public64
Specific Use-CaseTransparent Firewall and extended Inside & Outside VLANs Transparent/Bridged Firewall is separating OTV extended VLANs OTV is sharing the
Join Interface - One of the uplink of the Edge Device - Point-to-point routed interface (physical interface, sub-interface or port-channel supported) - Used to physically "join" the Overlay network - No OTV specific configuration required - IPv4 only Overlay Interface - Virtual interface with most of the OTV configuration
Street Asphalt Overlay History September 3, 2019 SEGMENT STREET FROM TO ACTIVITY DATE SS‐000137 04TH AV F ST E ST AC Overlay 2/5/2014 SS‐000140 04TH AV ISLAND AV MARKET ST AC Overlay 11/25/2013 SS‐000141 04TH AV J ST ISLAND AV AC Overlay 11/25/2013 SS‐000142 04TH AV K ST J ST AC Overlay 11/25/2013
February 2006 Overlay Utility 7-1 7. Overlay Utility IRIS has a flexible overlay feature for drawing overlays, or maps displayed on top of other IRIS/Open products. Overlays are used for product output and the real-time display. The overlays used in product output are specified in the Overlay menu. An overlay can consist of the following:
Intro to Overlay Maker Mac Tutorial IntelliTools, Inc., 1720 Corporate Circle, Petaluma, CA 94954-6924 Materials may be freely reproduced Rev. 12/8/98 Phone: 800-899-6687, Fax 707-773-2001, Email: info@intellitools.com Page 7 of 7 13. Use Your Content-Only Overlay Quit Overlay Maker . Send the overlay by double-clicking on the
Network Functions Virtualisation – Update White Paper Issue 1 Page 5 of 16 Introduction In our first white paper published in October 2012 [1] we introduced the concept of Network Functions Virtualisation (NFV) and pr
Functions Virtualisation (as distinct from Cloud/SDN) and the rationale for encouraging an . October 22-24, 2012 at the “SDN and OpenFlow World Congress”, Darmstadt-Germany. . network-centric connected world. Network Functions Virtualisation aims to File Size: 862KBPage Count: 16
The Heritage Overlay provisions are found at clause 43.01 of all Victorian planning schemes. The schedule to the Heritage Overlay contains the list of places covered and any particular controls applying to them. The overlay maps for the relevant planning scheme delineate the area or sites to which the Heritage Overlay applies. Clause 43.01 also
Controller I/O overlays Description Ordering PN VMM0604 overlay 0913505ECD VMM2404 overlay 0913506ECD VMM3120 overlay 0913504ECD VMM1210 overlay 0913501ECD VMM1615 overlay 0913509ECD Accessories Controller I/O board The Controller I/O Board (CIOB) is a general-purpose simulation board that is
X AutoCAD 2000: The Complete Reference 16 Managing Content with AutoCAD DesignCenter 605 Understanding the DesignCenter Interface 606 Using AutoCAD DesignCenter 614 Retrieving Frequently Used Content 619 17 Creating a Layout to Plot 623 Using Paper Space and Model Space 624 Creating Layouts 632 Working with Layouts 645 Using Layout Templates 650 Creating Floating Viewports 655 Controlling .
