Kevin Dorrell, CCIE #20765

01 May 2008

Seeing dot1q tagged traffic in Ethereal

Filed under: General — dorreke @ 16:51

I am having a problem seeing 802.1Q and 802.1P tags in Ethereal.  I am trying to monitor a trunk port using SPAN, and although Ethereal is seeing the traffic, I cannot see the 802.1Q tag .  I have seen this before at work, and it is about convincing the NIC on the PC not to discard the tag.  At work, we found a registry hack to convince the NIC not to strip the tag.

For reference, I am doing it on an HP ZE4603EA laptop which has a National Semiconductor DP83815 MacPhyter 3v NIC, with driver version 1525.292.

Here are some resources:

But despite a search on the Internet, I cannot find a registry hack for this particular NIC.




  1. Kev- The tags are stripped from the datagram at the hardware asic before the packet is queued into the egress buffer, and the SPAN monitor only captures traffic at ingress/egress of the physical switchport, not the asic. Depending on the platform, you can use “show platform buffer …” command to inspect the packet within the asic (there you will see the tags, COS, TOS, etc.). If you have a dual NIC card that supports passthru, you can insert your sniffer (wireshark) on the wire of the trunk and then there you will see the tags. You can also build a poor-man’s passthru adapter using a 4 port patch block (i can send you the instructions on how to build it)…Anyway, sorry to be long-winded or if I misunderstood you robjective–otherwise, I hope I helped. I do not know enough about regedit hacks to be of any help in that area. 🙂

    Comment by kevhat — 02 May 2008 @ 20:23

  2. Kev, thanks for the comment.

    I was using the 3560-8PC at work, and that had a nice command “monitor session n destination int f0/n encapsulation replicate”. This replicates all the tags from the source port, which is useful for investigating CoS markings. It does not work with RSPAN though. The 3550 has something similar, but you have to specify dot1q, isl, or native, so I’m not sure whether it replicates the CoS.

    My problem at work was that even with the “encapsulation replicate”, I was still not seeing the markings on the WireShark monitor. It turned out the NIC driver was stripping off the dit1q header before passing it up to the software. But we found a registry hack to stop it doing that. Unfortunately, not all NICs have such a hack, so I cannot do the same in my home lab.

    Comment by dorreke — 03 May 2008 @ 21:55

  3. Hi Kev- I was unaware of the replicate keyword. I see it on my 3560s now. Good to know your findings before I tried to use it and banged my head against the switch trying to figure out the prob. Do you have the info on the hack? Again, thanks for the tip.

    Comment by kevhat — 05 May 2008 @ 16:03

  4. Hi Kevin,

    I just had a look through my notes but I could not find the exact details. However, I found a good document from Wireshark that explains the problem and the different ways of approaching it. I have added the URL in the main body of the posting.

    The hack is likely to be different for each NIC. The best way to find it is to Google the NIC reference, “Wireshark”, and “VLAN” all together. Possibly substitute “802.1Q” for “VLAN”. I was lucky that for the laptop at work I got a hit first time.

    I shall see if I can find back my notes, but they are all hand-written with very little indexing. Call me old fashioned … 😉

    Comment by dorreke — 05 May 2008 @ 16:31

  5. Oops! I just realized they are the same document!

    Comment by dorreke — 05 May 2008 @ 16:34

  6. Hi dorreke,

    please can u help me with this configuration:
    monitor session 1 source interface fa0/1 tx
    monitor session 1 destination interface fa0/2 encapsulation dot1q

    interface fa0/1
    switchport trunk encap dot1q
    switchport mode trunk

    interface fa0/2
    switchport trunk encap dot1q
    switchport mode trunk

    is there something wrong in this configuration ?

    Comment by Tony — 11 Nov 2008 @ 09:57

  7. Tony,

    It looks OK to me. On F0/2 you will see only the traffic that was transmitted out of F0/1 towards whatever is connected there. If you want to see traffic in both directions, then leave out the tx keyword. The extra config on F0/2 will not make any difference … once the port is a monitor port, the tagging is controlled by the “mon sess dest” command.

    What is actually happening? What do you see?

    Going back to the original blog, be aware that if you are monitoring with WireShark or something like that, then maybe you will not see the tags bacause the monitoring NIC will strip them.

    Comment by dorreke — 11 Nov 2008 @ 23:08

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Blog at

%d bloggers like this: