12-31-2009 01:33 PM - edited 03-06-2019 09:08 AM
Problem:
I do not see 802.1Q tags nor do I see p-bits (COS) in my wireshark captures. My setup is not working and I have no way to verify (sniff) that the 6509 is setting the p-bits to 3. I need to see them to troubleshoot effectively. Help!
Setup:
I am port mirroring off of my 6509. Port 1/16 should be tagging and setting the p-bits to a value of 3. How can I confirm?
interface GigabitEthernet1/16
description DonkX
no ip address
load-interval 30
mls qos cos 3 ! I've tried my tests with and without this command
mls qos cos trust ! I've tried my tests with and without this command
switchport
switchport access vlan 941
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 941
switchport mode trunk
no cdp enable
end
Port G1/16 is the GE uplink to DonkX
Port G8/47 is the Windows 2003 Server with wireshark.
Port G8/9 is my RH4 Linux box with TCPdump.
Steps taken to resolve the problem:
I have followed this document to set this up correctly on my windows box with a Intel Proset 1000MT. I have updated the drivers and made the registry changes with no captures showing tagging/cos information.
http://www.intel.com/support/network/sb/CS-005897.htm
Regardless of my settings, this document says I shouldn't have to worry about drivers:
http://wiki.wireshark.org/CaptureSetup/VLAN
"You'll definitely see the VLAN tags, regardless of what OS the independent system is running or what type of network adapter you're using."
Details:
I am testing a new GPON access product (DonkX) that uplinks via GigE using trunking and setting p-bits. To prioritize my video the new DonkX sets the p-bits to 3 and it instantly ceases that traffic. I have only unidirectional traffic at this point so I can no longer arp, icmp, ftp, tftp, noth'n. The 6509 sends back a response to DonkX but I believe it is dropped because the p-bit is not set to 3. If I remove the priority from 3 to 0 on the DonkX system then it works correctly but without QoS of course.
-JGR
Solved! Go to Solution.
01-01-2010 01:35 AM
Hello JGR,
int gi8/47
switchport
swichport trunk enc dot1q
switchport mode trunk
the SPAN destination port has to be set for trunking to see 802.1Q tags in mirrored traffic
see
SPAN copies Layer 2 Ethernet frames, but SPAN does not copy source trunk port ISL or 802.1Q tags. You can configure destination ports as trunks to send locally tagged traffic to the traffic analyzer.
A destination port configured as a trunk tags traffic from a Layer 3 LAN source port with the internal VLAN used by the Layer 3 LAN port.
Hope to help
Giuseppe
01-01-2010 01:35 AM
Hello JGR,
int gi8/47
switchport
swichport trunk enc dot1q
switchport mode trunk
the SPAN destination port has to be set for trunking to see 802.1Q tags in mirrored traffic
see
SPAN copies Layer 2 Ethernet frames, but SPAN does not copy source trunk port ISL or 802.1Q tags. You can configure destination ports as trunks to send locally tagged traffic to the traffic analyzer.
A destination port configured as a trunk tags traffic from a Layer 3 LAN source port with the internal VLAN used by the Layer 3 LAN port.
Hope to help
Giuseppe
01-01-2010 01:45 PM
You are absolutely right! Thank you!
01-04-2010 04:58 PM
Alright, the saga continues. I saw tagged frames last week but began troubleshooting again this morning and can't see tagged frames!
If I remove the span then I can see tagged traffic on g8/47 (Windows 2003 Server 802.1q not configured on NIC). If I turn on monitoring I see no tagged traffic. I also tried this on a laptop running Fedora 12 (on g8/47) and had the same results. Any ideas?
I've mirrored another trunk port that is in production passing tagged traffic to an 3560 trunked and going to an ASA. The port to the 3560 and ASA (g3/7) requires tagging and works properly; however, I cannot see tags on this port either. Do you see anything obvious here or is this looking like a tac case?
interface GigabitEthernet1/16
description DonkX
no ip address
load-interval 30
switchport
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 941
switchport mode trunk
no cdp enable
end
sho mon
Session 1
---------
Type : Local Session
Source Ports :
Both : Gi1/16
Destination Ports : Gi8/47
02-17-2012 08:56 AM
Quick follow-up on my old post. Not seeing the tags was a span bug. The simple fix is to choose a higher session number. For instance I tried the same source/destination ports but as session 3 and it works. This was determined through a TAC case.
01-23-2014 08:59 AM
Hi,
I know this is an old thread but do you have the bug ID?
Thanks
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide