Recently, I\u2019ve done a few labs with OTV in them.\u00a0Each time, however, I had an OTV SME (subject matter expert) in the lab with me.\u00a0They configured it and it just \u201cworked magically."\u00a0No hiccups. No gotchas.I really don\u2019t seem to learn well if things are super simple and just "work."\u00a0I seem to need to struggle with it and wrestle with it a bit.\u00a0But most importantly, since I seem to learn visually, I need to "see the flow in my mind."\u00a0Which means I need to Wireshark the "magic."*For those of you new to OTV, I\u2019m not going to explain it here as there are plenty of great URLs and documents out there that goes into great detail regarding OTV.\u00a0Two I would recommend are:OTV Technology Introduction and Deployment ConsiderationsOTV Best Practices GuideSo Let's Start Playing!Let\u2019s say we had a vSphere environment with a few ESXi and some VMs.\u00a0But for this blog let\u2019s just specifically look at two of them.\u00a02 ESXi hosts and 2 VMs.\u00a0Ultimately, what we\u2019d like to be able to accomplish is to vMotion one of the VMs over to ESXi #42.The reality of the physical situation is not quite as simple as the above diagram. These 2 ESXi hosts are actually in 2 different data centers.\u00a0Of course, it is a lab environment, so it isn\u2019t overly complicated either.\u00a0My "cloud" between the "data centers" is actually just a twinax cable and the 2 Nexus 7K VDCs running BGP between them.I\u2019m not going to address here all the varying options of what we could have done here.\u00a0We will pretend that the team has already decided to go the OTV route and we need to get OTV up and running between the two data centers.Begin with the End in MindWhat is the "end" for this?\u00a0The "end" is "vMotioning" a VM from one ESXi to another.\u00a0This means that we have to know the needs of the application.\u00a0So we need to talk with the VMware experts on our team and learn how vMotion works and how it is set up in our environment.\u00a0What we learn is: the vMotion is enabled on vlan 158 on the VMkernel\u00a0\u00a0- which means we need to extend vlan 158 over OTV\u00a0 the VMs are on vlan 1121 \u2013 which means we need to extend vlan 1121 over OTV\u00a0as well Is that enough to know?\u00a0Depends.\u00a0It wasn't for me.\u00a0But then again, I got burned.\u00a0So now I check two more things: MTU vMotion truly enabled for the VMkernel (see below diagram.\u00a0 The line to the right beneath VLAN ID)Below is a screen capture on just one of the ESXi hosts. I always check both sides, though. This is a lab, and hence a shared environment.Configure and Avoid the Common \u201cPitfalls\u201d\u00a0I\u2019m far from being an OTV SME. In fact, I have only done multicast OTV thus far in all my labs, no unicast OTV.\u00a0But I can at least share with you my "mental checklist" I now have when configuring OTV with multicast: MTU, MTU, MTU \u2013 Just like any L2VPN there is overhead that is going to help with the \u201cmagic\u201d of extending a layer 2 vlan across layer 3 boundaries.\u00a0 Make sure to increase the MTU of all the links from OTV edge device to OTV edge device to take this into account. Site vlan \u2013 design, know, and configure the site vlan for each site. The site vlan must be the same for the OTV edge devices in the same physical site.\u00a0\u00a0 Do NOT extend this vlan over OTV.\u00a0\u00a0 Note: I tend to forget about site vlan when there is only 1 OTV edge device in each data center. Site ID \u2013 design, know, and configure the site ID for each site.\u00a0 The site ID must be the same for the OTV edge devices in the same physical site.\u00a0The site ID must be unique between sites (West and East below must each have different site IDs) No shut the overlay interface \u2013 I tend to forget this. Extended Ping Between Join Interfaces \u2013 routing needs to work.\u00a0 We need to be able to do an extended ping between the IP addresses of the OTV edge device join interfaces. Multicast Control Group ASM \u2013 the control group runs in \u201cany source multicast (ASM)\u201d.\u00a0 This means that there needs to be a multicast RP defined, configured, and in the routing table.\u00a0 Multicast Data Group SSM \u2013 the data group runs in \u201csource specific multicast (SSM)\u201d.\u00a0 This means that devices need to enable SSM for whatever group range is being used here. Multicast functionally working OTV edge device to OTV edge device Time to vMotion and SniffOur end game was to get so we could vMotion the VM over to the Data Center East and sniff the vMotion session.\u00a0So let\u2019s get to the end game and see the magic underneath. \u00a0\u00a0Above we can see the vMotion session. The OTV encapsulation of the layer 2 extended vMotion TCP session is GRE encapsulated. \u00a0\u00a0Voila!\u00a0I now have a picture of the packet in my mind. That always helps me. \u00a0 \u00a0Hope it helps you too!