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
Update: LISP solves the problem from client to server, IE Ingress Path Optimization. FHRP solves the problem from server to client, IE Egress Path Optimization. You can check out Egress Path Optimization here.
We recently published a Data Center Interconnect – DCI- related document on cisco.com and I wanted to get it in front of you. Locator/Identifier Separator Protoc0l – LISP – provides the path optimization technology to forward transactions via the most direct path, ultimately meaning better application performance. The link for the LISP Virtual Machine Mobility paper is below.
As a side note, LISP can be used many other ways and here’s a pointer to one of our LISP pages.
For our purposes in DCI, we use LISP for path optimization and we can see here why the need arises. The box on the left shows an existing transaction that looks pretty direct. The middle box shows the workload is now in a new data center but the transaction is suboptimal, it still goes through the firsts data center. The box on the right shows the desired path, the direct path from user to workload withouth going through the first data center. It’s pretty easy to see the need here for path optimization and the desire to have the direct path to the new data center location as shown on the far right box.
Read More »
Tags: Disaster Planning, disaster recovery, LISP, LISP ASM, LISP ESM, Virtual Machine Mobility, vMotion