Why Can't We Have Plug-and-Play Networking?

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.

11 comments:

  1. It could lead to security issues (spoofing).
    Replies
    1. I totally agree one would have to (like always) balance the convenience with potential security issues, and I wouldn't expect the DC switches to be dumb devices that would blindly do something based on inbound LLDP packets - but I would love to be able to configure some common-sense commands based on what's connected to the switch.
  2. Force10 uses LLDP to autoconfigure spanning tree edge ports, at least in chassis where every component is obviously from Dell.
  3. VMware is able to advertise CDP/LLDP, it just isn't enabled by default and, last I checked, must be done via the CLI.
    Replies
    1. Yeah, I'm aware of that (even mentioned it in the post), and it's configurable through vCenter GUI (see the blog post from Bob Plankers I linked to).
    2. No you didn't - "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."

      The majority of networks backing large VMware deployments have been Cisco based. Therefore, VMware prioritized the CDP protocol. It is common in these networks to enable bidirectional CDP so that network operations are able to see the server connectivity within there switches.
  4. Cisco has the "autos smartport" feature that allows you to run configuration based on lldp or cdp information - even OUI's.
  5. You don't need to interact with LLDP (which is not necessary enabled on the switch BTW) in order to avoid this problem. You can just wait 30 seconds before considering that a link is operational after its link came up. Cisco has been doing that for 15+ years with uplinkfast in order to avoid blackholing when switching over between uplinks;-)
    As an optimization, you could check the state received in the BPDUs (carried in RSTP/MST) and bypass this 30 second waiting period if possible.
  6. Arista has various scripted functionality based on LLDP information.

    Basic script,to configure the interface description based on the LLDP info for the interface: https://eos.aristanetworks.com/2011/07/port-auto-description-2/

    Zero touch script which will automatically configure the switch based on it's LLDP neighbors/position in the network topology
    https://eos.aristanetworks.com/2012/09/pre-provisioning-ztp-server/

    VMTracer, based on the CDP/LLDP information of attached physical/virtual servers, will automatically provisions the VLANs for the VMs configured within vSphere.

    http://www.aristanetworks.com/products/eos/vmtracer
  7. What about Cisco ISE? I've never had the chance to deploy it in the real world but have seen demos and attended training sessions that d demonstrate the ability you're taking about. There are lot of upfront policy and configuration choices to make but after that switch port provisioning, with custom security, is supposed to be automated.
  8. The fancy new Cisco Insieme stuff (Nexus 9000) is supposed to use LLDP to autoconfigure itself and find the controllers, you can supposedly plug a new switch into the fabric and not really have to do anything. They also have PoAP (Power On Auto Provisioning) which is a little more old school but with the abilities of the newer switches to run things like LXC you can run all the server stuff on another switch.

    Up at Layer3, Juniper is working on a number of op scripts and whatnot to do MPLS auto provisioning including the ability to use unnumbered interfaces. Other vendors like ALU have also added the ability to run IGPs, RSVP, and LDP over unnumbered interfaces.

Add comment
Sidebar