Mobile ARP In Enterprise Networks Remedy Is Contained In Our Real Ccie Workbook

First let's check out the layer 2 check point of ccie r&s lab.

What we can do with Mobile ARP is what I'll call IP address mobility in the scope of this posting the ability to create host routes to IP hosts in "wrong" subnet, and disperse those host routes through a routing protocol to everyone that might care to understand how to reach those hosts.

Undeniably, this strategy doesn't scale well, particularly if applied with a single enterprise-wide IGP. However, that hasn't stopped some people from proposing a similar LISP Mobility Architecture, over again proving the unlimited wisdom of RFC 1925 and our ccie r&s workbook.

Furthermore, the original problem Mobile ARP was attempting to fix did not involve moving nodes or fast topology changes - it allowed a stationary node to be shown in a foreign IP subnet and still pick up traffic for its IP address, however did not let fast moves between IP subnets.

That's the proper pace for Mobile ARP-driven IP address mobility.

Problems with host route scalability prompted IETF to design Mobile IP for IPv4 and IPv6 in the past. If you have to support mobile IP nodes moving across L3 subnets in your campus network, you're much better off enabling Mobile IP support on them.

A friend of mine is working on 3G/4G Mobile IPv6 deployment for emergency response teams with Nokia. They got the whole thing up and running in a semi-production environment; contact him for more details.

Data center section is likewise included in our real ccie lab.

Data center is an entirely different story. No person can ever touch the virtualized holy cows (aka VMs) simply because something just might break in the event you install an additional bit of software on them, therefore the common assumption is Mobile IP is off-limits, and we're utilizing all sorts of kludges to let VMs to be moved around and still retain their IP addresses.

Hypervisors already exploit fake gratuitous ARP messages to indicate a VM has transferred to a different location in the data center, therefore the Mobile ARP seems to be a good match. In fact, the first-hop routers can use those gratuitous ARPs to uncover the VM moves and change the IP forwarding tables accordingly (and there's the Virtual Subnet IETF draft that advocates exactly that).

The false gratuitous ARP trick works only due to non-deterministic data-plane-driven forwarding behavior of layer-2 switches (formerly known as bridges) - as soon as the hypervisor to which the VM have been moved sends the gratuitous ARP with the VM's source MAC address, every switch in the network scraps the earlier information and installs the new forwarding entry. Sadly, that's not how routers work.

A correct L3-focused IP mobility solution would need at least two steps:

The hypervisor from which the VM have been removed would have to notify the first-hop router that the VM's IP address is no longer accessible;

The hypervisor to which the VM has relocated would have to notify its first-hop router that a new IP address has appeared.

Gratuitous ARP is a system that could potentially solve the second problem considering we ignore all the security implications, overloaded semantics, as well as the fact that ARP works just for IPv4 but we're still missing the first step (although the Virtual Subnet draft employs a fascinating trick to solve that trouble). Note that we can't rely on ARP timeouts (just like Mobile ARP does); the traffic disruption would be extremely long.

Cisco has yet another solution for your data center woes: LISP for Virtual Machine Mobility (is it just me or does LISP truly look like a hammer frantically searching for a nail?), which is only somewhat better than Mobile ARP.