View Single Post
  #26  
Old 06-24-2015, 04:00 PM
sbilde sbilde is offline
Hot Shot
 
Join Date: Jun 2015
Location: Dallas, TX
Posts: 14
sbilde has 10 reputation points
Default

Everyone thanks for reading, the case is closed.

Since the bug that simple can't stay unnoticed by Q&A and would definitely cause serious problems in the real networks, it is obvious the problem was in the setup itself.

I tried to replicate the problem with various routers and switches instead of the laptops, using trunk/access interfaces - FAIL.

Further investigation has shown the laptop NICs (Intel and Broadcom) behave in a weird way - they strip the VLAN tag (any VLAN tag) and move the packet to the higher protocols (IP in our case) instead of dropping the tagged packet.

No wonder they were able to ping each other.

Changing the registry settings for the NIC to keep VLAN tags:

For Intel:
The new key (dword), either MonitorMode or MonitorModeEnabled should be placed at: HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Cl ***\{4D36E972-E325-11CE-BFC1-08002BE10318}\00nn
Where nn is the physical instance of the network port where you want to capture the VLAN tags.

For Broadcom:
  1. Search for "TxCoalescingTicks" and ensure this is the only instance that you have.
  2. Right-click on the instance number (eg. 0008), add a new string value "PreserveVlanInfoInRxPacket" and give it the value "1".
With those settings enabled, NICs don't remove VLAN tags and consequently don't talk to each other anymore.

That solves the mystery of the tagged interface.


Also, a possibly useful trick found while investigating. There is always a VLAN 0 in the system. Adding a VLAN 0 as a PVID to a trunk would effectively block all the untagged traffic both ingress and egress on this port.