A real pain in the arse: CDP in ESX 3.5/4.0

So, everyone loves CDP? Hands up if yes?

Well… that’s everybody.

I love CDP too – when VMware implement it correctly. See, here’s the thing – CDP will not work with Intel NICs of a certain type (Intel MT and PT dualport NICs – and some quad ports) if the port they are attached to has a native VLAN that is not VLAN 1.

Now, at this point, all the Cisco people reading this blog would be shaking their head.

Why?

Link 1 for ESX 4.0: On Cisco switches, the device drivers for Intel MT or PT Dual Port NICs do not update the filter to allow traffic from VLAN 1. The driver drops the Cisco Discovery Protocol (CDP) packet before it gets to the kernel, and so, ESX/ESXi does not see the CDP information.

Link 2 for ESX 3.5: When the native VLAN on a switch is changed from the default of 1, Intel MT and PT dualport NICs drop all traffic with the new native VLAN tag. This results in CDP packets being dropped, due to which CDP appears not to function correctly.

The solution in both cases is to reset the native VLAN on each port you want to see CDP on, to use native VLAN 1.

Except, this is Cisco’s take on the situation:

Precautions for the Use of VLAN 1

The reason VLAN 1 became a special VLAN is that L2 devices needed to have a default VLAN to assign to their ports, including their management port(s). In addition to that, many L2 protocols such as CDP, PAgP, and VTP needed to be sent on a specific VLAN on trunk links. For all these purposes VLAN 1 was chosen.

As a consequence, VLAN 1 may sometimes end up unwisely spanning the entire network if not appropriately pruned and, if its diameter is large enough, the risk of instability can increase significantly. Besides the practice of using a potentially omnipresent VLAN for management purposes puts trusted devices to higher risk of security attacks from untrusted devices that by misconfiguration or pure accident gain access to VLAN 1 and try to exploit this unexpected security hole.

To redeem VLAN 1 from its bad reputation, a simple common-sense security principle can be used: as a generic security rule the network administrator should prune any VLAN, and in particular VLAN 1, from all the ports where that VLAN is not strictly needed.

Therefore, with regard to VLAN 1, the above rule simply translates into the recommendations to:

• Not use VLAN 1 for inband management traffic and pick a different, specially dedicated VLAN that keeps management traffic separate from user data and protocol traffic.
• Prune VLAN 1 from all the trunks and from all the access ports that don’t require it (including not connected and shutdown ports).

Similarly, the above rule applied to the management VLAN reads:

• Don’t configure the management VLAN on any trunk or access port that doesn’t require it (including not connected and shutdown ports).
• For foolproof security, when feasible, prefer out-of-band management to inband management. (Refer to [3] for a more detailed description of a out-of-band management infrastructure.)

As a general design rule it is desirable to “prune” unnecessary traffic from particular VLANs. For example, it is often desirable to apply VLAN ACLs and/or IP filters to the traffic carried in the management VLAN to prevent all telnet connections and allow only SSH sessions. Or it may be desirable to apply QoS ACLs to rate limit the maximum amount of ping traffic allowed.

If VLANs other than VLAN 1 or the management VLAN represent a security concern, then automatic or manual pruning should be applied as well. In particular, configuring VTP in transparent or off mode and doing manual pruning of VLANs is commonly considered the most effective method to exert a more strict level of control over a VLAN-based network.

So it would seem that VMware, through their inability to fix the Intel driver, are recommending against Cisco’s suggestions. This is simply not on! Especially when the two companies are getting closer and closer with the release of the Nexus 1000V.

VMware, get your arses into gear and fix this up. I refuse to violate my customers’ switch/network security for the purposes of having a feature that you advertise as being available and working.

Cheers,

Leo