WILS: The Many Faces of Compression
Brocade gets behind TRILL.
Third-party systems integrators, value-added resellers (VARs) and consultants is another constituency threatened by the single-vendor data center. These channel players make their money by tying together equipment and software from different vendors to best suit a customer’s needs. Sometimes they act as outsourced IT shops and these VARs are watching the converged infrastructure play with much interest and are already feeling the repercussions of growing tensions between erstwhile partners Cisco and HP.
One New England VAR executive said that in the past his company successfully sold solutions including HP servers and Cisco routers and EMC storage into many accounts, with the support of all vendors. Now, he gets pressure from each vendor — especially HP — to offer a one-vendor solution, and that support has waned.” —IT shops want more throats to choke
Ok, over a dozen requests for something on Cisco OTV breaks the threshold.
- OTV is standard Cisco: a pragmatic and fast response to an emerging need or requirement (depending on who you ask).
- It’s not sui generis. There’re other ways to achieve the same basic functionality that have been around for some time: MPLS, VPLS, EoMPLS, L2VPNs, Pseudowires, PLSB/SPBM, EoDWDM, plain ol’ Metro E, blah blah blah. All of these services allow L2 continuity across data centers with various architectures and capabilities for scale, management, automation, spanning-tree suppression, etc.
- Looks like decent design.
- Like with anything, there’ll undoubtedly be scale, performance, etc., limitations to start, that will be improved over time.
- Note that they don’t say the devices running OTV have to be in any particular data center network layer. Interesting, that.
- The supposed ease with which it can be set up, maintained, and managed is a differentiator.
- The fact that it’s WAN transport agnostic, as long as whatever it is can carry IP, is another.
- The whole transport over IP thing is a huge architectural decision, imo. It’s a strong hint to Cisco’s strategy re multi-site connectivity, L2 continuity, the interclouds, etc.
- It’s not a panacea. Nothing ever is. Get over it.
What do you think?
I’m often asked to comment on particular vendor offerings, technology roadmaps, etc. What I can say is governed by: corporate policies, NDAs, etc.
What I try to do is be generic and give my view insofar as it does not point to specific bits of information I don’t publicly have. But it ain’t easy.
The underlying table information and routing transport for this scenario is a pretty neat adaption of existing technology. Cisco is leveraging some of the capabilities of the IS-IS (Intermediate System to Intermediate System) routing protocol to make this happen, although the IS-IS configuration is completely under the covers. It really is only about five commands to add a data center to the mix, although the necessary configuration of the Nexus 7000 switches might be a bit more involved.
The upshot is that even though the overlay transport is transparent to the ends of the connection, there’s no fear of spanning-tree looping as each site maintains a distinct spanning-tree topology and BPDUs aren’t forwarded across the WAN. The OVF functions as a gatekeeper for the frames that should remain local while forwarding those that should be allowed to pass.
When databases fly In the demo I saw, Cisco used OTV to migrate a loaded SQL Server VM from one VMware ESX host to another over a simulated WAN, with the hosts residing at different data centers the equivalent of 400km apart (4ms latency). The VM migrated over in about 30 seconds or so without losing the connection with the client load… with one catch. Although the VM definitely moved, the virtual disk didn’t. (Moving an 8GB VMDK through an OC-12 would take far longer than 30 seconds, and such a trip isn’t really feasible for a VM under load anyway.) In the demo, Network Appliance’s FlexCache technology bridged this gap, enabling the VM disk to remain in the original data center while keeping the delta at the new data center. Naturally, this isn’t a scenario that lends itself to a permanent migration, but it might prove useful in some load-balancing and global distribution scenarios.
It’s important to note that the established connections to migrated VMs continue along their original data paths. Even though the VM ends up running at the remote data center, the existing TCP connections to that server must still pass through the initial data center to maintain the consistency of the connection. New connections could be rerouted to the remote data center, but an existing connection cannot. This could add significant latency and bandwidth consumption to the WAN links if not monitored. It should also be noted that current technologies put a distance damper on any effort like OTV, since VMotions on links with greater than 4ms latency can get problematic really fast. This roughly translates to 400km of physical separation. This isn’t a limitation of OTV, but it’s still a constraint.” —First glimpse: Cisco OTV