How to enable and use the new LLDP networking feature in ESXi 5
One common issue with networking in virtualized environments is the outgoing ports from the virtual switches to the physical network switches. Configuring with VLANs and similar must be done very carefully to ensure that all ports are correctly setup. It is often quite hard to track patch cables going from the server chassis to the switch port and it is often also difficult to determine the relation between the ESXi server NIC ports to the VMNICs visible inside ESXi.
A very helpful tool is a network discovery protocol, for example CDP or LLDP.
Some months ago Jason Boche posted an interesting article on the output of CDP from the vSwitches. In this post I will display how to use the new LLDP feature in vSphere 5 and what the output will be on the network switches.
For information about how to configure LLDP in ESXi 5.0 and 5.1 see this post. After this has been enabled on the ESXi side you must have a switch with LLDP support and also verify that LLDP is set to both listen and receive. In this test setup I used a HP Procurve 5406zl and wanted to check the LLDP output from the host. To see the neighbor list in the Procurve command line interface you use:
show lldp info remote-device
Above is the output of the LLDP neighbor table of the switch facing two ESXi hosts. We can for example see that the local port A10 is connected to a interface called VMNIC0 on a host with the name ESXi5-a. On the following lines we see that A11, A12 and A13 is attached to VMNIC1, VMNIC2 and VMNIC3. This information makes both configuration and troubleshooting much easier – as we have a “visibility” between the network devices. Note also that the local switch port A15 is connected to VMNIC1 on another host, ESXi5-b.
If needed to see which virtual switch a certain VMNIC is connected to, we could display more information by using the same command as before, but with a port number at the end. For example:
show lldp info remote-device A12
On the output above we see the full host name of the ESXi host, the VMNIC number, but also the name of the virtual distributed switch. The port number (1) is the logical port on the distributed switch, where the VMNIC2 is the physical NIC port connection the virtual and the physical switch.
The PVID field above might be able to display a Port based VLAN id, but it seems to be empty even if VLANs is available on the port groups of the distributed switch.
The release number displayed is also correct, even if the ESXi host tells the neighbor switch it is running classic ESX. The host also reports its capabilities as bridge, i.e. switch and not for example router.
Finally the view from the vSphere Client, looking at the interfaces connected to the distributed virtual switch. We notice that we can see the model, name and IP address of the switch device and also the local name of the port, in this case A12.
When both the vSphere administrators and the network team have this amount of visibility to each other we can avoid many mistakes and ease troubleshooting, so just make sure either CDP or LLDP is enabled on both sides. If having for example HP Procurve switches, but not the Enterprise Plus license you could still have some use for this, see this post for more information.
If not having dvSwitches configured the network team should still be able to see the CDP info from a standard vSwitch using “show lldp info remote-device” as the Procurve supports listening of CDP.. The VM admin is blind though..
At least this is the case on our 5412 and 5406 boxes..
/Rubeck
Thanks for your comment Kim. That is correct that if the standard vSwitch has CDP configured to “both” (default only listen) then the CDP information will be visible even on HP Procurve switches as they are allowed to listen, but not send, CDP.
So you are making a good point that if not having the Enterprise Plus license (for the Distributed vSwitch) the network team could still benefit from the CDP sent from standard vSwitches on ESX/ESXi.
No, thank you for the blog and verifying it actually works as expected 🙂
Supergod artikel… Mycket bra 🙂
the discovery is fine on the cisco side. You may want to include discovery from the vmware side.