SPAN port question

Unanswered Question
Mar 29th, 2007

Hello there - I am setting up a span port so that we can record our voice traffic with Witness. I have gotten the span port all setup like this:

monitor session 2 source vlan 10

monitor session 2 destination interface Gi0/25

Our voice VLAN is VLAN10. My question is do I need to configure the port (Gi0/25) any differently than any other port on the switch. Here is the current configuration for the port:

interface GigabitEthernet0/25

description Witness SPAN port

switchport access vlan 10

switchport trunk encapsulation dot1q

switchport mode trunk

srr-queue bandwidth share 10 10 60 20

srr-queue bandwidth shape 10 0 0 0

queue-set 2

mls qos trust dscp

auto qos voip trust

It seems that we are capturing some of the traffic on the voice vlan but not all of it and according to the vendor it may be an issue with the span port so I just wanted to get some other opinions as to if my span configuration is correct. If any of you have any ideas I would greatly appreciate them. Thanks.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.1 (5 ratings)
mpozorski Thu, 03/29/2007 - 16:08

Thanks for the link Mahmood. I have followed the procedure as described in that document but that document does not describe if the port that will be monitoring the traffic needs to be configured in any certain way which is what I am really trying to figure out. Thanks again for the useful link but it just does not give me the information I am looking for.

Edison Ortiz Thu, 03/29/2007 - 19:13

Destination Port

Each local SPAN session or RSPAN destination session must have a destination port (also called a monitoring port) that receives a copy of traffic from the source ports or VLANs and sends the SPAN packets to the user, usually a network analyzer.

A destination port has these characteristics:

For a local SPAN session, the destination port must reside on the same switch as the source port. For an RSPAN session, it is located on the switch containing the RSPAN destination session. There is no destination port on a switch running only an RSPAN source session.

When a port is configured as a SPAN destination port, the configuration overwrites the original port configuration. When the SPAN destination configuration is removed, the port reverts to its previous configuration. If a configuration change is made to the port while it is acting as a SPAN destination port, the change does not take effect until the SPAN destination configuration had been removed.

If the port was in an EtherChannel group, it is removed from the group while it is a destination port. If it was a routed port, it is no longer a routed port.

It can be any Ethernet physical port.

It cannot be a secure port.

It cannot be a source port.

It cannot be an EtherChannel group or a VLAN.

It can participate in only one SPAN session at a time (a destination port in one SPAN session cannot be a destination port for a second SPAN session).

When it is active, incoming traffic is disabled. The port does not transmit any traffic except that required for the SPAN session. Incoming traffic is never learned or forwarded on a destination port.

If ingress traffic forwarding is enabled for a network security device, the destination port forwards traffic at Layer 2.

It does not participate in any of the Layer 2 protocols (STP, VTP, CDP, DTP, PagP).

A destination port that belongs to a source VLAN of any SPAN session is excluded from the source list and is not monitored.

The maximum number of destination ports in a switch is 64.

Local SPAN and RSPAN destination ports behave differently regarding VLAN tagging and encapsulation:

For local SPAN, if the encapsulation replicate keywords are specified for the destination port, these packets appear with the original encapsulation (untagged, ISL, or IEEE 802.1Q). If these keywords are not specified, packets appear in the untagged format. Therefore, the output of a local SPAN session with encapsulation replicate enabled can contain a mixture of untagged, ISL, or IEEE 802.1Q-tagged packets.

For RSPAN, the original VLAN ID is lost because it is overwritten by the RSPAN VLAN identification. Therefore, all packets appear on the destination port as untagged.

Amit Singh Thu, 03/29/2007 - 21:51


As you want to monitor the traffic for vlan 10 only, my suggestion for you would be to remove the trunk configuration from the switch and check if that works. As you are using a dedicated destinaton port for monitoring the vlan traffic, it will not participate in normal traffic forwarding.You can safely remove the other commands also and let the port just be an access port for vlan 10.

-amit singh

mpozorski Mon, 04/02/2007 - 11:41

Thank you for the suggestion with this. I have removed the trunk configuration from the port and will see how that goes. Do you think that I should remove the port from VLAN 10 as well? From the other help I have gotten here it looks like it does not make any difference so it really should not matter but it's always good to g et a second opinion. Thanks again.

situwayne Mon, 04/02/2007 - 13:17

be sure you remove the trunk config from interface. i would get rid of the qos config, too.

for best practice, i would create a null vlan99 and assign the span port to this vlan.

to answer your question....the destination port can be in any vlan.

mpozorski Mon, 04/02/2007 - 14:09

Thanks for the information. I have modified the interface so that it is no longer configured as a trunk, and removed the qos configuration as well. I will need to hold off on creating a null VLAN that I could assign the port to due to our change control but I will give that a shot. thanks again for the advice.


This Discussion