11th February 2012

Capturing VLAN Tagged Packets and Microsoft Windows

A colleague was attempting to capture packets on a trunk interface from a switch and wasn’t seeing the VLAN tags on the sniffer. Turns out that there are a two things that need to be considered here. The first is that the port mirror also needs to be configured as a trunk. Some port mirroring solutions need the mirror port as well as the mirrored port to be a trunk enabled. For Cisco SPAN, this varies from platform to platform so probably best to enable the SPAN port as a trunk to be sure.

Of course, the bigger problem is Microsoft Windows. They are inconsistent in their implementation of third party drivers. The following is taken from the Wireshark website:

http://wiki.wireshark.org/CaptureSetup/VLAN#Windows

Windows

Windows has no built-in support mechanisms for VLANs. There aren’t separate physical and VLAN interfaces you can capture from, unless a specialised driver that adds such support is present.

So whether you see VLAN tags in Wireshark or not will depend on the network adapter you have and on what its and its driver do with VLAN tags.

Most “simple” network adapters (e.g. widely used Realtek RTL 8139) and their drivers will simply pass VLAN tags to the upper layer to handle these. In that case, Wireshark will see VLAN tags and can handle and show them.

Some more sophisticated adapters will handle VLAN tags in the adapter and/or the driver. This includes some Intel adapters and, as far as i know, Broadcom gigabit chipsets (NetXtreme / 57XX based chips). Moreover, it is likely that cards that have specialized drivers will follow this path as well, to prevent interference from the “real” driver.

Therefore, if you are using Windows as the OS for your sniffer, you should have a default position that it you will not be able to capture VLAN tags and then check to see if it is possible to make a change to your network adapter or network driver.

The EtherealMind View

Gotta love the Microsoft Windows network driver implementation, it’s so bad, it’s awesomely bad. After ten years of the current driver design, Microsoft still permits driver software to crap out their OS. Stupid, stupid, stupid.

Postscript

Cisco has a similar reference HERE.

This post is copyright of Thropos Ltd ©2008-2011 at Etherealmind.com - contact | email: greg.ferro@packetpushers.net - twitter: @etherealmind | All rights reserved
About Greg Ferro

Greg Ferro is a Network Engineer/Architect, mostly focussed on Data Centre, Security Infrastructure, and recently Virtualization. He has over 20 years in IT, in wide range of employers working as a freelance consultant including Finance, Service Providers and Online Companies. He is CCIE#6920 and has a few ideas about the world, but not enough to really count.

He is a host on the Packet Pushers Podcast, blogger at EtherealMind.com and on Twitter @etherealmind and Google Plus

  • http://www.gamersanon.com Andy

    Windows Server 2008/7 had it’s TCP/IP stack just about completely re-written!!1 Didn’t that fix it?

  • http://ccnprecertification.com Sean

    It’s a royal pain in the backside. IPCCx uses packet capture within the agent desktop to implement monitoring so you have to worry about it on agent machines, too.

    Sean

  • http://N/A 1001QA

    Hi Greg

    I don’t thing you could possibly miiss this but just in case, was the “encapsulation replicat”e option used ?

    Thanks
    Cristian

  • http://www.mytechnogrill.com sriram

    You are absolutely right. I am trying to capture vlan through my program but the stupid nic strips my vlan id. Do mail me if you have any suggestions or can help me