431 Words. Plan about 2 minute(s) to read this.
A few weeks ago, I was fortunate enough to gather together 3 engineers with experience deploying Cisco Overlay Transport Virtualization (OTV) to record a deep dive on Packet Pushers. We built an outline offline, researched the details, and then ended up talking for nearly 2 hours on the topic. Because the conversation was so long, I opted to break it into two shows.
OTV is an interesting topic. The point of the technology is layer 2 extension aka data center interconnect. Take a VLAN, and then extend it to live in another data center that’s separated from the first one by a layer 3 barrier. Lots of different tunneling techniques can accomplish this, depending on your geographic circumstances and what your carrier offers. Q-in-Q. L2TP. EtherIP. VPLS. Others, I’m sure. The magic with OTV is the intelligence baked into it to help with traffic tromboning and loop prevention, among other concerns.
- Traffic tromboning (one example of which is where you egress your local VLAN via the remote data center just to come right back to your local data center) is handled with FHRP filtering. The FHRP traffic is filtered so that it doesn’t cross the OTV overlay. Therefore, both members of the HSRP or VRRP pair think they are active, and therefore route between VLANs locally. Much more efficient. Cisco calls this “FHRP Isolation”, and explains it in more detail here.
- Assuming 2 OTV edge devices at each data center, there’s the opportunity for a loop to form. (See the square in your mind?) OTV mitigates this by making sure only one OTV device per site can speak per VLAN. This OTV device is the authoritative edge device (AED). How the OTV AED is selected and many more details about it can be found here.
My point here isn’t to give a lot of OTV detail, but rather to commend the thought that’s gone into making it a safe and reliable DCI. The interesting part of the podcasts (part one published, part two coming as soon as I finish the editing) is not just a discussion of the technology, but the real-world challenges the guests that participated had run into when deploying OTV. Great info. I haven’t had a chance to deploy OTV myself yet (possible use-case has trickled into my inbox at $dayjob), and learning from the experiences of others is one of the favorite parts of my job as a podcast host. Hoping to get part 2 published before I set off for CLUS, although that is perhaps ambitious, as I seem to be sitting here writing right now, and not editing audio. ;-)