Platform Information:
~ # esxcli hardware platform get
Platform Information
UUID: 0x34 0x30 0x38 0x37 0x36 0x31 0x4e 0x43 0x37 0x35 0x35 0x31 0x30 0x39 0x32 0x59
Product Name: ProLiant DL360 Gen9
Vendor Name: HP
Serial Number: CN7551092Y
IPMI Supported: true
~ # esxcli system version get
Product: VMware ESXi
Version: 5.5.0
Build: Releasebuild-2068190
Update: 2
Background:
My application simulates the network devices in the ESXi 5.5 platform, so there are some special packets such as the OSPF packets. The topology of the test case is as following:
The VM A will send the unicast, broadcast and multicast packets to network device, the packets will travel through the vSwitch A, vSwitch B, VM B and vSwitch C, then reach the real network device. VM B is just like a switch which will receive packets from the ethernet interface wm3 to wm2, or vice versa. The network device will also send these packets to VM A.
The portgroups can work correctly for the VLAN tag when the packets travel from the VM A to the network device. But there are some issues when the packets travel from the network device to the VM A. The multicast pakcets can't untag the VLAN tag 311 when these packets are inserted into the VM B(In fact, the VM B can't receive the OSPF packets). I used the pktcap-uw tool to capture the packets of the switchport which connects to the wm2 ethernet interface of the VM B:
The OSPF packets still has the VLAN tag 311, and other packets are correct.
I did more experiments about this issue:
1. I created another vSwitch D, copied configuration from the vSwitch C then connected the VM B and network device, the issue still existed.
2. I connected network device to vmnic3 and change the VLAN of the portgroup B to 311, The VM B can receive the OSPF packets. I used the pktcap-uw tool to capture the packets and found the OSPF packets are untagged the VLAN tag 311.
I have the same test bed in the ESXi 5.1 platform and don't find the similar issue. I think this bug is introduced in the ESXi 5.5 platform.
Please help confirm this issue, thanks in advance.