Cisco Blogs


Cisco Blog > Enterprise Networks

Why Would Anyone Need an IPv6-to-IPv6 Network Prefix Translator?

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: , , , ,

Denver is HOT for IPv6

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: , , , , , , , , , , , ,

DCI as an enabling framework for both Workload Mobility & Disaster Recovery using OTV and LISP

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:

  1. A single physical Cisco, EMC, VMware infrastructure
  2. Both vMotion and SRM validated on same infrastructure
  3. Tier-1 Enterprise Applications tested

Read More »

Tags: , , , , , , , , , , , , , , , , , ,

FHRP – Egress Path Optimization from the Server to the Client

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: , , , , , , , , , , , ,

LISP – Finding the Optimized Path for your Workload

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: , , , , , ,