For those of you wondering about the impact to Cisco of Software Defined Networking and the combined SDN strategy of VMware and Nicira, I point you to a very rational and well-articulated article by Mike Fratto of Network Computing, that basically says Cisco doesn’t have much to worry about. (Enterprise Strategy Group had already said something similar, by the way).
Specifically, Fratto says:
The lack of programmability in existing networking hardware is certainly a problem, but VMware’s acquisition of Nicira does not mean that Cisco and its ilk will be marginalized… It does mean the role and management of the physical network is changing, and I think Cisco is further ahead than most of its competitors in creating a vision for the next phase of networking.
I couldn’t agree more. Since Cisco live! when we announced our Cisco ONE strategy for network programmability as well as the advances in our Nexus 1000V portfolio for virtual network overlays, I have been posting on many of the same points.
My take here was that the VMware-Nicira acquisition did not portend a strategic break with Cisco, and while there are some obvious overlaps in our product lines, there are still a number of areas of collaboration, cooperation and interoperability. The virtual network infrastructure is just one piece of a larger software stack and the differentiation will likely be decided in the orchestration, management and applications built on top of the newly programmable infrastructures sometime down the road. Read More »
Tags: Cisco ONE, Cisco Open Network Environment, FabricPath, LISP, Nexus 1000v, Nexus 5000, Nexus 7000, Nicira, OpenStack, OTV, SDN, software defined networking, virtual network overlays, VMware, vPath, VXLAN
The upcoming World IPv6 launch is stimulating a lot of conversation around IPv6 deployment and common deployment scenarios. People regularly ask “where’s my NAT,” which is something we have tried to address in architectural discussions in RFC 2993, RFC 4864, and RFC 6269. Margaret Wasserman and I have worried specifically about the implications of the multiplication of provider-independent addresses at the edge and the issues of multihoming, and described a model for IPv6 network prefix translation that we think addresses most of the issues and yet facilitates scalable multihoming without provider-independent addressing and the bloating of the route table it implies. Per-residential-customer multihoming is currently in use for NTT BFLETS in Japan.
My colleague Andrew Yourtchenko, whom many of you may know from IPv6 events, has a very different opinion about network address translation. If anything, he would like to get rid of it. Andrew has contributed to some 14 RFCs on the topic of transition and has much of value to say.
While I agree with Andrew on a number of issues, I don’t agree about the model in which one deploys a prefix allocated by each of one’s upstreams providers on each of the LANs in a network. I think that while we have reduced costs for ISPs in the smaller route table, we have significantly expanded the complexity faced by the edge network without giving them a benefit that they readily recognize. I agree with the end-to-end model and the ability to deploy new applications anywhere in the network, but I think that stateless prefix translation can meet those issues and help in managing the size of the route table. Andrew and I recently weighed the pros and cons of our different opinions and included our thoughts in this blog. What is your opinion on this topic? Read More »
Tags: ILNP, IPv6, LISP, NAT, NPTv6
Unless you have been asleep behind the wheel of your network, you know the IPv6 Internet will go live on June 6th, 2012 and Cisco is taking a leading role. If you didn’t make it to Paris a few weeks back for v6 World Congress there are two upcoming events in Denver, Colorado where you can learn about deploying IPv6 in your network.
1. Breakfast Session: Making the IPv6 Transition will be held the morning of Tuesday March 20th from 7:30-930 am before the Lightreading Cable Next-Gen Broadband Strategies: Wideband, Wireless, PON & Beyond event. Fred Baker, Cisco Fellow and current Co-chair of the IETF IPv6 Operations Working Group, will be presenting and taking questions at the breakfast. He’ll cover how cable operators can deploy IPv6 on their network and will be available to meet with attendees after the breakfast. Register here to take advantage of this special opportunity. Read More »
Tags: 2012 North American IPv6 Summit, 6rd, Andrew Yourtchenko, announcements, cgv6, Denver Colorado, Dual Stack, Fred Baker, IETF IPv6 Operations Working Group, LISP, NAT64, Shannon McFarland, SLB64
A couple of colleagues of mine wrote a document on live Workload Mobility and Disaster Recovery for Tier-1 applications. I think you should check it out and here’s a couple of key points that I want to highlight:
- A single physical Cisco, EMC, VMware infrastructure
- Both vMotion and SRM validated on same infrastructure
- Tier-1 Enterprise Applications tested
Read More »
Tags: Business Continuance, Cisco, DCI, disaster recovery, EMC, LISP, Microsoft Sharepoint, mobility, Oracle 11g, OTV, RecoverPoint, Replication, SRM, Tier 1 Applications, vMotion, VMware, VPLEX, VPLEX Metro, Workload Mobility
I previously discussed using LISP to optimize your client-server traffic so today I’ll discuss the reverse direction: Egress Path Optimization from the Server to the Client. Let’s go over the need for Path Optimization in the direction from Server-to-Client with some pictures and explanations.
The Virtual Machine (VM) server is configured with a default gateway IP address, 192.168.1.1, which is the next hop IP address that the VM will forward packets towards as the traffic returns to the client outside the data center. In this data center environment, we’ve deployed the default gateway using the First Hop Redundancy Protocol (FHRP). In reality, FHRP is an umbrella technology term that includes Hot Standby Routing Protcol (HSRP) and Virtual Router Redundancy Protocol (VRRP), two main technologies that provide transparent failover and redundancy at the first hop IP router. Please see info on FHRP here.
Also notice that the VM default gateway is the same as the HSRP Virtual IP Address (VIP). The HSRP VIP binds itself to one of the physical HSRP Routers via an HSRP election process using Layer 2 control packets between the two physical HSRP Routers and this means that the VM default gateway, since it points to a VIP, may move between physical HSRP Routers, and of course which is then intent and design when using any type of FHRP.
In the above picture, the Path is Optimized from Server to Client, so now let’s take a look at what happens when we migrate the VM to the new data center.
Read More »
Tags: cloud, data center, Data Center Interconnect, DCI, FHRP, HSRP, LISP, mobility, N7K, Nexus 7000, OTV, vMotion, Workload Mobility