Every time I plug a new device into my Windows laptop and it automatically discovers the device type, installs the driver, configures the devices, and tells me it’s ready for use, I wonder why we can’t have get the same level of automation in networking.

Consider, for example, a well-known vSphere link failover issue: if you forget to enable portfast on server-facing switch ports, some VMs lose connectivity for up to 30 seconds every time a switch reloads.

Could a Switch Detect the Connected Device?

Plug-and-play behavior in Windows (or other operating systems) works because the plug-in hardware devices support a protocol that allows the operating system to (semi-reliably) detect and identify them. Interestingly, we have a similar protocol in networking: it’s called LLDP.

Straight from 802.1AB (LLDP) standard, section 9.5.7.2 (system description):

The system description field shall contain an alpha-numeric string that is the textual description of the network entity. The system description should include the full name and version identification of the system's hardware type, software operating system, and networking software.

How hard would it be to listen to LLDP updates and apply OS-specific settings to the server-facing switch ports … and yet I’m not aware of any major vendor doing this (I hope to be wrong, if that’s the case, please write a comment).

Automatic port configuration based on LLDP information could probably be done with a custom Perl/Python script on Arista EOS (not sure any other major vendor allows you to hook deeply enough into their switch OS – doing periodic show lldp commands with EEM doesn’t count ;), and I’m positive someone could get a Python script posted on Arista web site in a day or two. Anything else I’ve missed?

Update 2014-02-05: Cisco IOS has auto smartports - exactly what I've been looking for - since 2010, but I wasn't aware of them as they seem to be available only on low-end Catalyst switches and ISR switch ports

Obviously you couldn’t please all the geeks out there and their McGyver concoctions, so you’d need a configurable database of per-vendor settings, and be able to enable or disable autoconfiguration on individual ports.

Why Can’t We Get It Done?

For starters, VMware didn’t support LLDP till vSphere release 5.0, and even when LLDP got implemented, VMware decided to offer LLDP only in the distributed virtual switch (requiring Enterprise Plus vSphere license), while CDP remains available in standard and distributed virtual switches.

Let me get this straight: after supporting only a proprietary protocol for years, VMware finally decided to implement its standard equivalent, and couldn’t resist charging extra for baseline networking functionality. Great job! BTW, I’m not the only one annoyed by this decision.

Next, out-of-the-box vSphere configuration doesn’t send CDP or LLDP information – vSphere hosts work in listen mode in which they receive CDP/LLDP updates, store the information in vCenter databases (so the virtualization administrators can figure out how their servers are connected), but don’t advertise themselves. Makes sense? Not to me.

FWIW, here’s my pet conspiracy theory: like any other startup trying to disrupt existing world order through stealth grass-root adoption (early Novell and Microsoft efforts also come to mind), VMware tried to make early deployments as invisible as possible, and somehow forgot to change its stance and mindset when it became the leading virtualization vendor.

Will It Get Any Better?

Don’t hold your breath. Features that actually help engineers run their networks usually aren’t sexy enough to be implemented (although VMware sometimes tries to sell us a simple ethertype-based packet filter as a major improvement).

Also, the operations engineers that benefit from these features rarely buy the boxes they have to work with (and when those boxes fail, it’s always the fault of the operations team, not the broken application design, unrealistic expectation, or overselling vendors).

Finally, if you want to fix operations challenges, you have to understand them (RFC 1925 section 2.4 comes to mind). Listening to operations people (not popular, they don’t control the budget), or having operational experience definitely helps.