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.

2 comments:

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

    ReplyDelete
    Replies
    1. Perhaps an SSL VPN router attached to the MRI machine would accomplish this. But that would require some renumbering wizardry and other changes.

      Delete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.