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.
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...
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