Intro to OTV

Intro to OTVLets say, we have 3 switches (A,B,C). Switch A is connectec to B and Switch B is connected to Switch C. and Switch A has 2 vlans created on it, vlan 10 and 20. What if we want the the vlan 10 and 20 to be extended to Switch C over Switch B, We will have to simply create vlan 10 and 20 on both switch B and C and allow both the vlans on trunks connecting the switches, right? and its simple!!

If you look at this pic, we have two Datacenters, DC1 and DC2 which are geographicaly far away from each other, lets say one in Newyork and another one in Los Angles and there are some server which are there in both data centers,however, they sync their hearbeat over layer 2 only and doesnt work on layer 3. So,we have a requirment that we have to extend vlan 10 and 20 from DC1 to another data center, DC2!! You may call it Datacenter Interconnect (DCI).

can we do the same thing which we did to extend vlan from switch A to switch C in above example? Ofcourse Not!!, so what the are the solutions to achieve this?Until OTV came into picture, we had few of the below options to achieve this:-VPLS-Dark Fiber (CWDM or DWDM)-AToM-L2TPv3These are the services provided by Service Providers and they work on different mechanisms but basicaly what they do is, they provide you a layer 2 path between DC1 to DC2 similar to a trunk link between Switch A and Switch B. So what does that mean? If a broadcast is sent or a ARP request is sent, that will travel across the service provider to another data center in that VLAN? Ofcourse YES!! Your STP domain will also get extended over DCI. So, if a device in vlan 10 in DC1 is trying to communicate with another device which is also in DC1 but the ARP request will go all the way to DC2 switches on which that particular vlan is configured.

So, to avoid such problems, Cisco introduced OTV (Overlay Transport Virtualization) which is basicaly a DCI (data center interconnect) technology to be configured on Nexus Switches. Using OTV, we can extend Layer 2 between two or more datacenters over traditional L3 infrastructure provided by Service Provider, and we dont need a seperate L2 link for layer 2 extension and we will still be able to limit STP domain and unnecessary broadcast over WAN links. It can overlay multiple VLAN with a simple design. Basically what it does is that, Datacenters will be able to advertise their MAC addresses to each other(its called Mac in IP" routing) and a decision can be made on the basis of MAC addresses whether that MAC address is local or in another data center and based on that, frame can be forwarded or limited to a particular data center only.OTV uses a control protocol to map MAC address destinations to IP next hops that are reachable through the normal L3 network core.So, in Cisco's language "OTV can be thought of as MAC routing in which the destination is a MAC address, the next hop is an IP address, and traffic is encapsulated in IP so it can simply be carried to its MAC routing next hop over the core IP network. Thus a flow between source and destination host MAC addresses is translated in the overlay into an IP flow between the source and destination IP addresses of the relevant edge devices. This process is called encapsulation rather than tunneling as the encapsulation is imposed dynamically and tunnels are not maintained"

How this is implemented, that i will show in another simplified post!!Thank you!!

OTV Silent Host Connectivity Problem There are several scenarios where a silent host can cause connectivity issues. The purpose of this document is to show why traffic loss occurs during an AED failover.(Power Point Presentation appended to this document).

1) Before failover, traffic between hosts is working successfully.

2) AED failure occurs at site-1

3) New AED role established for the vlan at site-1 but traffic continues to fail. The duration of the connectivity issue can range from a few seconds to several minutes depending on the length of time it takes for Host-2 to generate a packet.

4) Connectivity is restored once new AED learns Host-2's MAC

Failover scenario for between non-silent host. Rarely in real networks will a there be completely silent devices. Thus, failovers between AEDs converge quickly as the local MACs are relearned. Generally, the "silent host" scenario is seen in testing environments only.

1) Before failover, traffic between hosts is working successfully.

2) AED failure occurs at site-1

3) AED immediately learns Host-2's MAC and is able to install the entry into it's CAM and OTV route table. It then advertises the route to S2-OTV-1 and connectivity is quickly restored. Note that the original AED failure generates a TCN on the vlan of site-1. Thus packets from Host-2 to Host-1 will be flooded throughout the network ensuring that it reaches the new AED.

- See more at: https://supportforums.cisco.com/document/65531/otv-silent-host-connectivity-problem#sthash.Q5INzcE3.dpufPosted by Inderdeep Singh lll at 2:06 AM No comments: Email ThisBlogThis!Share to TwitterShare to FacebookShare to PinterestLabels: OTV Troubleshooting OTV Adjacency OTV adjacency is formed across the layer 3 multicast clouds by exchanging L1 ISIS Hello packets.Sample Topology

1. Verify IGMP V3 Join

After the OTV configuration completed, enabling the join interface sends any source IGMP v3 join on that interface.interface Ethernet1/31 description [OTV-JOIN-INTERFACE] vrf member OTV ip address 10.10.15.6/30 ip router eigrp 10 ip igmp version 3

SITE1-OED1(config-if)# int eth 1/31SITE1-OED1(config-if)# no shut

SITE1-AGG1%OTV# show ip mrouteIP Multicast Routing Table for VRF "OTV"(*, 239.1.1.1/32), uptime: 0.283775, igmp pim Incoming interface: Ethernet1/5, RPF nbr: 10.10.15.1