OTV Optimal Routing

Two prior blogs discussed OTV, Cisco Overlay Transport Virtualization. One of those blogs pointed out some concerns one might have about optimal routing, OTV optimal routing. (My virtual machine — VM —  moved to the other data center — does inbound / outbound traffic do the right thing?) A reader (thanks!) shared a good link, and that motivated me to find some Cisco-centric answers as well.

For some of the basics of OTV, see https://netcraftsmen.com/blogs/entry/understanding-layer-2-over-layer-3-part-1.html. The second blog of the two discussed OTV optimal routing, see https://netcraftsmen.com/blogs/entry/understanding-layer-2-over-layer-3-part-2.html#comment-97.

Update (2/2/11): See fresh info and my CMUG presentation. My FHRP (First Hop Routing Protocol info blog article may also be of interest, towards filtering FHRP for optimal outbound routing — see below).

From the World to the VM

Cisco has pretty much solved the issue of sub-optimal routing from virtual machines (VMs) to the World. This is done by manually (now) or automagically (future) filtering of FHRP (First Hop Routing Protocol) hellos by OTV (i.e. HSRP, VRRP, or GLBP). This allows the default gateway at each site to have the same IP and not cause problems. When VMotion moves a VM to the other data center, the VM’s IP and default gateway do not change. Cool stuff!

From the VM to the World

The prior blogs also noted that inbound traffic needs optimal routing, and the OTV materials don’t go into the details. (They pretty much still do not do so.)A recent comment from Dave Wood spurred me to investigate. (And thanks to him in NZ!) He provided the following link:  http://www.youtube.com/user/f5networksinc#p/u/19/XtVcNAyfxxI. That is a F5 video on how they support Long Distance (LD) VMotion, including the inbound optimal routing, by tight integration with vmware vSphere 4 / vCenter. In googling around, I came across the related link, http://www.f5.com/pdf/deployment-guides/vmware-vmotion-dg.pdf. Neat stuff!

(I do vividly imagine this as almost if there’s a bidding contest going on concerning LD VMotion. How little bandwidth do you really need? If you compress and de-duplicate, how much? Can this solution go a longer distance than that one? Cautious people might stick with the Cisco-supported solution(s).)

The next question was, how does Cisco do this? The answer turns out to be, Cisco apparently can do it, the details are at present perhaps a bit sketchy (meaning I haven’t managed to find them yet). Relevant links:

http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9402/white_paper_c11-591960.pdf

http://www.slideshare.net/NetAppVirtualization/cisco-netapp-vmware-long-distance-vmotion-3043346

http://www.cisco.com/web/DK/assets/docs/Cisco_News_Update_Data_Center_3.0_Technology.pdf

http://www.cisco.com/en/US/docs/app_ntwk_services/data_center_app_services/application_networking_manager/3.1/user/guide/UG_vdatacenter.html#wp1026766

What this seems to boil down to is that the Cisco ANM (Application Networking Manager) now has a component that integrates with vmware vCenter, possibly allowing workflow automation to drive ANM. Basically, when a client does DNS to GSS, it needs to resolve to a Virtual  IP (VIP) on the ACE in the data center where the VM is presently running. (Something has to track the VM location and “activate” a corresponding VIP.)This appears to be approximately what F5 is doing as well.

If you have found more details on this, please do us all a favor, by commenting with a link.

Future (No Promises)

I’ve now seen some detailed Cisco slideware about OTV, and am even more impressed with the technology. I may summarize more of how OTV works and some of the things it does in a later blog. Neat stuff!