Local Area Mobility (LAM) – the true story

Every time I mention that Cisco IOS had Local Area Mobility (LAM) (the feature that would come quite handy in today’s virtualized data centers) more than a decade ago, someone inevitably asks “why don’t we use it?” LAM looks like a forgotten step-child, abandoned almost as soon as it was created (supposedly it never got VRF support). The reason is simple (and has nothing to do with the size of L3 forwarding tables): LAM was always meant to be a short-term kludge and L3 gurus never appreciated its potentials.

To understand the context in which LAM was launched, we have to time-travel back to the early 1990’s. Ethernet LANs had been traditionally built with thick or thin coax (sometimes resulting in nice spaghetti mess) and people were busy implementing the brand new 10Base-T (twisted pair) standard and deploying switches to increase the total available bandwidth. Many building (or even campus) networks were still implemented as a single layer-2 domain and people were learning the hard way that bridges (oops, I should have said switches) were not very good at isolating broadcast storms generated by faulty NICs or broken software.

The gurus promoting large-scale bridging in modern data centers seem to be too young to remember those days, so they’ll have to re-learn the lessons of the past. As @icemarkom said: “I can't wait to see @ioshints series of articles when new L2 gizmotrons* start failing in few years.”

Smart network designers quickly realized that only the routers could provide true isolation between layer-2 domains. However, there was no DHCP (the first DHCP RFC appeared in October 1993) and BOOTP wasn’t widely used in some environments, so most IP hosts had static IP addresses. Splitting them into multiple layer-2 domains (and thus multiple IP subnets) would require a major renumbering effort, including visiting each and every workstation, logging in with administrative password (LDAP or AD weren’t available either and not everyone was using Kerberos) and changing the IP address.

It was way easier to invent a network-layer kludge that would solve the problem and thus LAM was born. Using LAM you could easily split a single IP subnet into multiple subnets and handle the hosts that landed in the wrong subnet as exceptions covered by host routes.

However, as Roland Dobbins pointed out in a comment to my Layer-3 gurus: asleep at the wheel post: current LAM implementation sucks. More about that in another post.


  1. I worked with a moderate-sized hospital that was using LAM as of about 18 months ago to deal with medical modailty machines (portable MRI and ultrasound equipment, etc) that would move between multiple wings of the building. The machines had static IPs and were more-or-less "unchangeable." According to the manufacturer changing the IP address was a major operation, and would invalidate all earlier studies by disassociating the machine with its prior studies in the database.

    LAM was used to deal with this, apparently on advice from Cisco TAC. I found it to be buggy though. One thing we encountered multiple times was that the router would occasionally do an ARP check to validate that the LAM'd device was still on the segment, and use that to persist the injected /32 route. Problem was, a well-meaning but poorly-configured L3 switch interface on the same segment would respond to the ARP with the proxy ARP feature and "refresh" the entry on the router. So the router would draw traffic for that device toward it even when the device had moved back to it's "real" subnet. The router didn't seem to track or notice a change in the MAC associated with that mis-located IP.

    But as usual, this network-layer kludgery "fixed" an abhorrent application design...
    1. Perhaps an SSL VPN router attached to the MRI machine would accomplish this. But that would require some renumbering wizardry and other changes.
  2. I wrote a white paper back in October 2004 on how we used LAM in two instances; one like Bob mentioned above for a hospital while we migrated the network (so it was used temporarily then removed) and once to migrate a data center - again as a temp feature, but worked perfectly.
  3. For history buffs, some of the same folks behind LAM went on to help with "LISP extended subnet mode multihop mobility." This feature also creates host routes in the DC closest to where a mobile host currently is, but it (a) works with stretched subnets/L2, and (b) supports live migration. Despite "LISP" in its name, its configured only on the default gateways; there's no need for full LISP (xTR's, encapsulation, etc). It's supported on Nexus 7000 and IOS-XE routers like the ASR 1000 and CSR 1000v.

    It's 2018, and I still use LAM (and LAM-inspired static host routes) to help with migrations. You can find a walk through at https://community.cisco.com/t5/switching/local-area-mobility/m-p/3759749/highlight/true#M453970
Add comment