cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5107
Views
17
Helpful
27
Replies

Mirror VLAN Tag Not Stripped

NOYB2NOYB
Level 1
Level 1

Model: SG200-08

Config:

Port 1 - 5 VLAN 1 UnTagged Member, VPID 1 (defult config)

Port 6 - VLAN 99 Tagged Member, VLAN 1 Untagged Member, VPID 1 (default)

Port 7 - VLAN 99 UnTagged Member, VPID 99

Port 8 - VLAN 99 UnTagged Member, VPID 99

Port 8 Tx & RX Mirrored to Port 4

VLAN 99 packets transmitted out port 8 with vlan tag stripped, as it should be, and are mirrored to port 4 except the vlan tag is not stripped.

What needs to be configured for the mirrored packets to be same as what is actually going out on the wire (vlan tag stripped)?

Thanks.

27 Replies 27

I don't think it is so much that the neutral monitor port 4 is following rules of 802.1q while it shouldn't.
But rather the packets are being mirrored to the monitor port prior to getting untagged and placed on the wire at the source port.

Remember, this is only occurring to transmitted traffic.  Received traffic works fine.

Here's the switch VLAN and Port Mirroring configuration.

Packets received in on port 8 from the wire are all untagged.  As expected.

And mirrored to port 4 without the VLAN 99 tag.  As expected. 

Packets transmitted out port 8 onto the wire are all untagged.  As expected.

But mirrored to port 4 with the VLAN 99 tag still in place.  Not as expected.

Expectation is for the packet VLAN tags to be the same (tagged or untagged) as they are placed on wire at port 8.

PID VID: SLM2008T V01
Boot Version: D.8.3.1
Firmware Version: 1.0.6.2


Noyb, I've sent an inquiry to check this out.

I do apologize if I do not explain myself clearly.

It's kind of a complicated process and it's very possible to mix some things up.

My train of thought is like this-

Lets  say you do not have the monitor port at all. Port 4 is vlan 2 untagged.  Port 8 is vlan 99 untagged. If vlan 99 is not configured on port 4,  that port will send tagged frames for vlan 99. But when the local port  (port 8) receives this frame it must be untagged or gets discarded.

I  personally think the switch is somehow trying to convert the frames for  the native vlan "mismatch" while it is in a SPAN state but the SPAN  state should have zero impact on what comes in and out of port 4 since  it should ONLY see what comes in and out of port 8.

I  do not know how an originating packet on the untagged VLAN works. It may  be possible it follows the same logic. That the ingress port receives  untagged frame, encapsulates 802.1q and sends to the destination port,  the egress strips the VLAN ID then forwards.

-Tom
Please mark answered for helpful posts

-Tom Please mark answered for helpful posts http://blogs.cisco.com/smallbusiness/

"I've sent an inquiry to check this out."  Said Tom Watts, 12 days ago on May 2nd.

"Any response?"  Asked NOYB, 12 days later on May 14th.

Hi NOYB,

Could you put port 4 in vlan 99 just like port 8? Then see the result.

Li Zhu,

No.  I cannot put port 4 in vlan 99.  Port 4 is the mirror destination.

You should be able to easily reproduce this issue and try on your own.  Especially being that you are working for Cisco.  Customers should not have to do this level of diagnosis for Cisco.  All the necessary information and configuration to reproduce the problem has been provided.  If Cisco is unable or unwilling to pursue and fix the problem then their product will be forever flawed.

If you are having trouble reproducing and configuring your network sniffer to display vlan tags, you need to take a look at these documents:

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

http://www.intel.com/support/network/sb/CS-005897.htm

Now go fix the problem.  You have all the necessary information to reproduce the issue.

Hi NOYB,

I can see this issue on SG200-8, I think it's not a bug, but an enhancement. For TX packets, by default they will be added a dot1q tag.

On catalyst 2K/3K switch, to resolve this issue, they add options, encapsulation {dot1q | replicate}, by default, all mirrored packets are untagged, configure encapsulation dot1q, all mirrored packets are tagged, only configure encapsulation replicate, you can get the same mirrored packets as origin packets.

SG200-8 don't support these options, you see, port mirroring is just for debugging, add a VLAN tag, I don't think it will cause big problem.

No it is not an enhancement. That is just double talk spinning nonsense.

What you have said is that "to resolve this issue" on catalyst 2K/3K switches, options have been added. So clearly it is an issue. Otherwise it would not have needed additional options to resolve it.

Furthermore chapter 3 of the Administration Guide; in the Administration - Diagnostics - "Configuring Port Mirroring" section states the following:

"A mirror copy of the traffic on the source port(s) being probed are transmitted from the source port to the destination probe port."

Administration Guide:

http://www.cisco.com/en/US/docs/switches/lan/csbss/sg200/administration_guide/78-19562.pdf

This is not happening. The source port traffic is not vlan tagged. But is being copied to the destination probe port with vlan tag.

It does not work as stated and it is a problem. Analysis of probe port captured traffic is not accurate and different than the traffic on the source port. This is a bug and it is an issue.

Quite honestly I had expected better from Cisco. Was evaluating this for possible purchase. But with this issue it does not meet the needs, and is a show stopper.

Ok, we'll try to fix it.

Li Zhu
Cisco Employee
Cisco Employee

Hi NOYB,

Our developer checked this issue, unfortunately it's a hardware issue.

Please refer to the Mirroring section of the chipset programmer's guide - Theory of Operations:

Egress mirrored packets are sent modified with a VLAN tag(always tagged).

You know, sg200-8 chipset is different from sg300 and sg500, and it uses a different software version, the latest is 1.0.6.2, for sg300 and 500, the latest is 1.3.0.62. So if you want egress tag stripped, you need to have a sg300 or 500.

Hi,

I have now spent a number of hours with this very same issue, and I am really not happy that it is actually a hardware limitation/fault, and thus unfixable with a new firmware.

However, you could at least add some information about this in the switch help system, and also include a note about this issue at the configuration page for port mirroring. That way, at least it will prevent others from wasting time on this. I stumbled upon this thread while searching for a solution to the problem, but others might not.

Port mirroring should obviously be exactly that, e.g a byte-identical copy of the actual ingress and egress packets on the port(s) being mirrored, so this flaw is a disappointment, especially since Cisco is a renowned brand for networking equipment.

Best regards

-Øyvind

Jersteph
Cisco Employee
Cisco Employee

I have been working on this issue for some time. My configuration was this:

 

monitor session 1
description Traffic_monitor_1
source interface Ethernet1/47 both
destination interface Ethernet1/48
no shut

 

I was seeing this when I tested with a ping: (note the port channel with the VLAN tag)

 

 1: 17:20:54.554536 802.1Q vlan#3015 P0 192.168.1.2 > 192.168.1.1: icmp: echo request
2: 17:20:54.554765 192.168.1.1 > 192.168.1.2: icmp: echo reply
3: 17:20:55.554216 802.1Q vlan#3015 P0 192.168.1.2 > 192.168.1.1: icmp: echo request
4: 17:20:55.554460 192.168.1.1 > 192.168.1.2: icmp: echo reply

 

Modified the session config to:

monitor session 1
description Traffic_monitor_1
source interface Ethernet1/46 rx
source interface Ethernet1/47 rx
destination interface Ethernet1/48
no shut

 

Now seeing this: (no PortChannel, and no VLAN tag)

 1: 19:09:04.501087 192.168.1.1 > 192.168.1.2: icmp: echo request
2: 19:09:04.501423 192.168.1.2 > 192.168.1.1: icmp: echo reply
3: 19:09:05.502095 192.168.1.1 > 192.168.1.2: icmp: echo request
4: 19:09:05.502293 192.168.1.2 > 192.168.1.1: icmp: echo reply

Note this is a Nexus 3000 with 6.0.2
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Switch products supported in this community
Cisco Business Product Family
  • CBS110
  • CBS220
  • CBS250
  • CBS350
Cisco Switching Product Family
  • 110
  • 200
  • 220
  • 250
  • 300
  • 350
  • 350X
  • 550X