Local Area Mobility?

[Patrick Beaven]

Has anyone setup basic LAM (Local Area Mobility) I have read a few different white papers on the setup and tried it in a lab with no success at all.

I've set ip mobile arp on the interface and enabled proxy-arp on it as well. I went ahead and setup redistribution of mobile into OSPF and I dont even see the routes with an "M" identifier? Am I missing something or are there known issues with this technology?

Any help is appreciated!

Thanks,
 

[Steve Fuller]

Hi,

I've used LAM a fair bit, albeit with EIGRP as the IGP, and from the sounds of it you've got most, if not all, of the boxes ticked. The usual problems I've seen are ip proxy-arp not being configured on the interface, and/or the redistribute mobile command missing from within router <igp> context.

So my basic configuration is as follows:

!
ip access-list standard MOBILE-DEVICES-ALLOWED
 permit any
!
router eigrp <eigrp_as>
 redistribute mobile
 default-metric <bandwidth> <delay> <reliability> <load> <mtu>
!
interface vlan <vlan_number>
 ip mobile arp timers 5 20 access-group MOBILE-DEVICES-ALLOWED
 ip proxy-arp
!

For the ip proxy-arp command make sure this is configured on both the router hosting the "home subnet" and the router running LAM. Otherwise hosts that are still on the home subnet will not be able to talk to the server you've migrated.

I don't think I've ever seen any host routes appear as mobile routes, but you should at least see them in the ARP table i.e., if you run sh ip arp <migrated-ip> on the router your configuring with the ip mobile arp command, you should see an ARP entry for the IP you're migrating.

A couple of points of note on that though:

• The end system hosting the migrated IP address must generate some traffic sourced from the migrated IP address, otherwise the ARP entry will never be created.
• The router which will be running LAM uses proxy ARP to install a host route of the migrated IP address, and this is then advertised as a /32 within your IGP. For proxy ARP to function that router must see a route to the "home subnet" e.g., a /24 subnet where the migrated IP would normally reside. If that shorter prefix route isn't there then the router running LAM won't respond to the ARP, and no ARP entry equals no host route.

While LAM works (honestly it does) you should obviously consider the age of the protocol and whether it'll be supported long term by Cisco. I've used it for many years in Catalyst 6500, but we've noticed it's now only supported on the "richer" feature sets i.e., Advanced IP services, and it's never been included within the Cisco Nexus product line and never will be from what I'm told. I'd also bet it's older than some of the folk reading and answering questions in this forum so support may be tricky. See Ivan's blog post at Local Area Mobility (LAM) – the true story for some of the history.

Regards

[Patrick Beaven]

Steve,

Thanks for the info! I think my only issue was that I dont have a route point out of the network for the /24 of that subnet. I will try this out. I dont know of any other technology like this is I've used IPSLA and conditional advertising. Do you know of any other network technology that can accomplish the same thing other than VPLS and Conditional advertising?

[Patrick Beaven]

 Have you seen anyone try to use this feature with VMware guest vm's?

[Steve Fuller]

Hi Patrick,

I've seen it used primarily for DR purposes, and migrated IP addresses from SQL databases, NAS and guest VM's hosted on VMware ESX clusters.

When VMs are migrated these are not a live vMotion. There's storage replication going on in the background to replicate the VMDK images and it's simply a case of bringing up the VMs in the alternate data centre on another ESX cluster.

I'm not sure if VMware still has the requirement, but it used to be that vMotion was only supported if the VMkernel interface of the ESX hosts were in the same Layer-2 domain. We don't have that capability and so live vMotion was not used.

It's worked reasonably well over the years although we expect to retire the functionality in the near future as we are now moving to a Cisco OTV (Overlay Transport Virtualisation) based solution as the data centre routers are migrated to Cisco Nexus.

Regards

[Patrick Beaven]

Steve,

Yes i could see some environments using the OTV option and the backend vmdk's and all storage is already replicated and local to the router. I wonder if it even works with the vm hosts as the host server tend to cache arp entries and I have not been able to get it working on any environment with vmware yet.. I didnt know if there is any known tweaks to make it work within a vm environment?

[Steve Fuller]

The only tweak that I’ve come across is to clear the ARP cache on the servers, both the migrated server i.e., on the VM you’ve moving, but also on any hosts remaining on the “home” subnet. If you don’t do this then when the migrated VM tries to communicate with hosts that are still on the home subnet, it’ll use their real MAC address rather than the MAC address the router.

On most server OS the ARP cache aging time is pretty short e.g., 10-miniutes, and so this can have already aged out by the time you’ve migrated the IP to the new data centre. We also tend to clear the ARP cache on the routers as these were much longer and so may not have aged out naturally.

Do you actually have LAM working now i.e., you can see an ARP entry for the migrated IP and you’ve got the host route of the migrated IP address in your IGP?

Regards

[cweinhold]

Local Area Mobility (LAM) is the combination of Proxy ARP, redistributed host routes, and IP Mobile ARP (optional). Collectively, these allow a host to keep working when its moved to a different VLAN/subnet/Site. E.g., a server with IP 172.16.3.77 can be booted and work just fine on VLAN 10.5.7.0/24. It was originally intended for pre-controller wireless mobility, but today I see two main uses:

1. One-time and one-way subnet moves (e.g., data center migration)
2. Moving equipment that needs a static IP address (e.g., medical equipment in hospitals, vendor-managed appliances, etc).

LAM can be set up in minutes on most Cisco networks. In contrast, deploying OTV, LISP, EoMPLS, EVPN, L2TPv3, SD-Access, or ACI can take months of re-architecting and hardware upgrades. 

So what are the downsides?

• LAM only works with IPv4 unicast traffic. True L2 extension is needed if your hosts require multicast, broadcast (other than ARP), or non-IP protocols.
• True dynamic LAM requires "ip mobile arp", a feature limited to Catalyst 6500 and ISR/ASR/CSR routers. Nexus 7K has its genetic kin, LISP ESM multihop (aka "LISP lite"). On other platforms, static host routes work and may suffice.
• LAM requires ARP cache consistency within the VLAN, which can take up to two minutes (hosts, gateways, etc). As a result, LAM doesn't support live migration. It should only be used with cold migrations (power off, move, power on).

Here's a diagram showing LAM at work (blue=pre-move, red=post-move):

Notice that R2 is the only site that needs the "ip mobile arp" command unique to Cat6K and routers. When host2 shows up on R2, it is automatically discovered and advertised back to R1.

If R2 didn't support the "ip mobile arp" command (e.g., you've got Catalyst 3K/9K or Nexus 5K/9K), you can still use static host routes. Change the base config to:

and each time a host moves, add a static host route:

R2(config)#ip route 172.16.3.77 255.255.255.255 Vlan7 name host2

This form of static route has no next-hop IP, which causes R2 to ARP directly for that IP on that interface. This is a manual way of creating the same host route that "ip mobile arp" would have added dynamically.

When used for a one-way DC move, R2 Vlan7's 10.5.7.0/24 would be a dummy subnet with no actual 10.5.7.x hosts like host3. Once all servers are migrated to R2, you can shut down R1 Vlan 3 and move the 172.16.3.0/24 over to R2 Vlan7 IP/HSRP. Then, get rid of "ip proxy-arp" and remove the static routes if you have them.