Friday, May 4, 2012

HP Procurve LLDP-MED and voice vlan configuration FAQ

These are quotations from the Software release notes and config guides, but maybe they'll make your life easier.

ProCurve does not recommend configuring a voice VLAN to accept jumbo packets. Voice VLAN packets are typically small, and allowing a voice VLAN to accept jumbo packet traffic can degrade the voice transmission performance.

Beginning with Release H.08.89, LLDP-MED is supported on ProCurve Series 2600 switches.

VLAN Operating Rules
These rules affect advertisements of VLANs in network policy TLVs:
  • The VLAN ID TLV subelement applies only to a VLAN configured for voice operation: vlan < vid > voice
  • If there are multiple voice VLANs configured on a port, LLDP-MED advertises the voice VLAN having the lowest VID.
  • The voice VLAN port membership configured on the switch can be tagged or untagged. However, if the LLDP-MED endpoint expects a tagged membership when the switch port is configured for untagged, or the reverse, then a configuration mismatch results. (Typically, the endpoint expects the switch port to have a tagged voice VLAN membership.)
  • If a given port does not belong to a voice VLAN, then the switch does not advertise the VLAN ID TLV through this port.

The QoS and voice VLAN policy elements can be statically configured with the following CLI
vlan < vid > voice
vlan < vid > < tagged | untagged > < port-list >
int < port-list > qos priority < 0 - 7 >
vlan < vid > qos dscp < codepoint >

Minimum software versions for LLDP-MED.
Source: HP ProCurve LAN products software feature matrix

LLDP-MED (Media Endpoint Discovery) H.08.89 R.11.04 R.11.04 T.11.xx W.14.03 L.10.02  K.14.xx K.11.1x K.14.xx E.10.02 H.07.57 K.14.03 K.14.xx K.12.31

Thursday, May 3, 2012

Bridged OpenVPN server on VMware ESXi host

After migrating our virtual firewall from a XenSource to an ESXi server, our bridged OpenVPN server stopped working: users could ping the server, but nothing else.
Since we were talking about Vista clients, we started with the usual suspects: reboot, reinstall TAP driver, reboot. No joy, so I had to start to actually think.

Turns out ESXi vSwitches are not in promiscuous mode by default. You can turn it on like this: