SPAN, RSPAN, Layer 2 control packets and VLANS

I know the title is quite a mouthful, but I did want to cover all the above in this post. Daniel asked me to check a few things as I have ready access to real switches.

You learn in your studies that layer 2 control packets are ‘special’ – Special in the way that traffic going over the trunk between 2 switches does not follow the standard practice. Let’s use wireshark to see exactly what is going on in a bunch of scenarios. It’ll also give me the opportunity to do a bit of testing with SPAN and RSPAN.

Let’s use the basic topology:

Let’s first set up a span session on the 3750. I will monitor port gi1/0/9 in both directions and send that traffic to gi1/0/24 to be picked up by the laptop.

monitor session 1 source interface Gi1/0/9
monitor session 1 destination interface Gi1/0/24

The first thing I noticed when I plug in my laptop however is that Windows of course is very noisy. Already my capture is filling up with stuff that Windows is sending out. And so I’ve downloaded an NST ISO which I’ll listen with on the laptop.

So now that I’ve booted up into NST and got Wireshark running, I hardly see anything at all happening between the 2 switches. Where is all the layer 2 control traffic? Well the problem is that control traffic is not automatically replicated to a SPAN port. You need to enable encapsulation replication in order for it to work. Let’s do so:

C3750#conf t
C3750(config)#monitor session 1 destination interface gi1/0/24 encapsulation replicate

Let’s verify:

C3750#sh monitor session 1
Session 1
Type                   : Local Session
Source Ports           :
    Both               : Gi1/0/9
Destination Ports      : Gi1/0/24
    Encapsulation      : Replicate
          Ingress      : Disabled

I can now see lot’s of control traffic in my Wireshark capture.

Both switches are already connected to each other. By default they’ll create a trunk link and vlan 1 will be the native vlan. I’ll then configure the switches to tag the native vlan and see what happens.

Let’s ensure the native vlan is not currently tagged:

C3750#sh vlan dot1q tag native
dot1q native vlan tagging is disabled

So what does my CDP/STP/DTP control packets look like in Wireshark? Note that I’m running the default mode of STP on the switch for now
I do see something odd. I am seeing an STP packet that has a dot1q tag of 1, 10 and an untagged packet. 10 I can understand because I have created vlan 10 and it has a separate STP instance. But why would the main one be tagged with vlan 1 if vlan 1 is the native vlan?
dot1q vlan 1

dot1q vlan 10

no dot1q tag

What about DTP and CDP?


Both CDP and DTP are currently sent with no vlan tag at all. CDP does carry information about the native vlan in it’s packet which is why CDP does complain when these don’t match on either end. But the important thing is that both are untagged.

Let’s now tag the native vlan and see what happens.

C3750(config)#vlan dot1q tag native
C3750#sh vlan dot1q tag native
dot1q native vlan tagging is enabled

Let’s bring up the interfaces again and see what we see.


Interesting. DTP has not tag, but CDP is using a tag of 1.

What about STP?

I’m seeing the same as what I saw above. I see a tagged vlan 1 STP frame, a tagged vlan 10 STP frame, and finally an untagged STP frame

What happens if I change the native vlan to 10? Well no need to paste output because it’s exactly the previous example. i.e. vlan 10 is now the native vlan and tagged, but CDP is still using a tag value of 1. STP and DTP remain unchanged.

Now let’s try something else. Let’s keep vlan 10 as the tagged native, but let’s remove vlan 1 from the trunk:

interface GigabitEthernet1/0/9
 switchport trunk encapsulation dot1q
 switchport trunk native vlan 10
 switchport trunk allowed vlan 2-4094

DTP is unchanged. i.e. it’s still sending untagged traffic. CDP however is sending tagged traffic. In vlan 1!

As a quick test I created int vlan 1 on both switches in the same subnet and tried to ping accross. I could not. Therefore it looks like Cisco will use vlan 1 tagged to send certain control data, even if vlan 1 is pruned, but no user data will be allowed on that vlan.

For STP I still have the same 3 outputs. A tagged vlan 1 STP frame, A tagged vlan 10 STP frame, and an untagged STP frame.

One last thing I wanted to test now was RSPAN config. I’ve always been a little confused as to the correct config on a switch that is the RSPAN end-point, and is also sending traffic to be monitored. i.e. Let’s say that the 3550 above is monitoring traffic on vlan 2 with a destination of remote span vlan 500. The 3750 is the rspan endpoint who monitoring rspan vlan 500 and sends it out to a local port on the switch. What happens if the 3750 is also monitoring vlan 2 on it’s own ports and sending out. Do we configure the destination to vlan 500 or straight to a local port?

Let’s configure it like so:

C3750#sh monitor session all
Session 1
Type                   : Remote Source Session
Source Ports           :
    Both               : Gi1/0/9
Dest RSPAN VLAN        : 500

Session 2
Type                   : Remote Destination Session
Source RSPAN VLAN      : 500
Destination Ports      : Gi1/0/24
    Encapsulation      : Replicate
          Ingress      : Disabled

I’ve tested sending it to RSPAN vlan 500 and I don’t see any traffic at all. As soon as I change it to send traffic directly to the port it works.

EDIT (05/06/12) – I’ve uploaded my captures to Cloudshark so you can take them apart to do your own research
Untagged native vlan 1
Tagged native vlan 1
Tagged native vlan 10
Tagged native vlan 10 with vlan 1 removed from trunk

3 Replies to “SPAN, RSPAN, Layer 2 control packets and VLANS”

  1. Hi Darren,

    Thanks for testing and great post. Here are some followup comments from me.
    When using the default settings with native VLAN and no tagging then
    control plane packets (CDP/VTP/DTP/PaGP/UDLD) are sent untagged. Essentially they don’t belong to any VLAN or some kind of internal VLAN not visible to us.

    The BPDUs are not treated the same way. As you saw, BPDUs are sent tagged
    but there was also an untagged frame. For the tagged frames you can see
    that the destination MAC is 01:00:0c:cc:cc:cd which matches with PVST+.
    The untagged frame however has a destination MAC of 01:80:c2:00:00:00
    which Wireshark identifies as Spanning-tree-(for-bridges). This frame
    is used to interact with IEEE STP which only runs one instance. This is
    useful with interacting with other vendors like HP or so. I saw
    this in a mail from a Cisco employee:

    “You are right, we actually call these “SSTP BPDUs”.

    We actually send several different BPDUs on an 802.1Q trunk port:
    * An 802.1d BPDU for VLAN 1 is sent untagged to the IEEE MAC address (0180.c200.0000) on the native VLAN

    of the trunk
    * A Cisco SSTP BPDU for the native VLAN of the trunk is sent untagged to the SSTP MAC address

    (0100.0ccc.cccd) on the native VLAN of the trunk
    * Additional Cisco SSTP BPDUs, one for each of the other VLANs carried on the trunk, are sent 802.1Q

    tagged to the SSTP MAC address with the appropriate VLAN ID

    The format of the SSTP BPDU is 100% identical to the 802.1d BPDU after the SNAP header, except that we

    also add a “PVID” TLV field at the end of the frame, which identifies the VLAN ID of the source port (eg,

    if we send an SSTP BPDU on VLAN 10, the TLV contains vlan 10).

    The TLV as the type (2 bytes), which is 0x0, the length (2 bytes) which is 0x2, and then 2 bytes of VLAN

    ID. There is also usually some padding in there.


    Also more about it in Petrs wonderful post:

    It is interesting that CDP becomes tagged but DTP not when tagging the native VLAN. I’ll have to look into this. The STP BPDUs still behave as described above. When looking at the packet captures you sent me it seems as the 3750 tags CDP frames while the 3550 doesn’t. Can you confirm this?
    Is it possible you already had tagging of native VLAN enabled on the 3750? So what is interesting is that when changing native to VLAN 10 the control plane packets are still sent with VLAN 1 even though in the CDP payload we can see that the native VLAN is 10. After looking further in the packet captures
    it seems as DTP is sent tagged on VLAN 10 but CDP is sent tagged on VLAN1? Sometimes the DTP frames seem to be tagged and sometimes not? Can you doublecheck it.

    When you pruned VLAN 1 the control plane packets could still flow which is expected but there has always been debate if VLAN 1 is special or not. It definately seems to have at least some special abilities.

    Very good writeup and also good info about the RSPAN.

  2. Darren yeah …captures you provided are not in accordance with the concepts u explained .Can u please check on questions raised by Daniel??

    Please very confused about this

  3. Great job! Very usefull post as there is not much decent info about it. Would be great to see also the behaviour of VTP and ISL in the test.

Leave a Reply

Your email address will not be published. Required fields are marked *