how to tagg STP BPDU frame

[yoram12345]

Hi all,

I have a switch catalyst 3750 which runs spanning tree (MST).

The switch is connected via  gige link to 3rd party equipment that can pass only L2 vlans , but not the RSTP BPDU.

I need a cisco command or configuration in which i could send the BPDU frames Tagged with specific vlan.

I tried to use MST , PVST but when i connected wireshark sniffer to teh gig ports , i noticed only untagged BPDU frames.

Is it possible with catalyzt 3750 ?

BR,

Yoram

[Jon Marshall]

Yoram

Any vlan that is not the native vlan should have it's BPDU's tagged. Is this connection a trunk port or an access port ? If it is an access port then there will be not tagging.

Jon

[Peter Paluch]

Hi Jon.

LOL, I've just written in my reply below that BPDUs are not tagged Okay, let me put this into perspective - IEEE-compliant BDPUs are not tagged. Cisco proprietary PVST+ and RPVST+ are tagged alright, but then again, only Cisco speaks this protocol. In any case, we should know more about the OP topology.

Best regards,

Peter

[Jon Marshall]

Peter

  and i was just about to write a response about the very same thing. Think between us we have probably managed to totally confuse Yoram !!

Jon

[tverhell]

Hello Yoram,

Are you capturing the traffic on a trunk-port?

As all traffic on trunk-port should be tagged with the exception of the native vlan:

http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release/12.2_55_se/configuration/guide/swvlan.html#wp1101186

Also make sure your Wireshark is able to capture the actual VLAN-tags:

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

Is that 3rd party equipment also a switch, or device talking STP, if so what type of STP?

Cheers,

Tom Verhellen

[Peter Paluch]

Yoram,

I am afraid there is no such command that would force a switch to emit its own 802.1D/802.1Q BPDUs as tagged. The format of BPDUs is strictly given by the IEEE 802.1D (STP) and 802.1Q (MSTP) standards, and it is not expected that STP/RSTP/MSTP BPDUs are tagged. Tagging these frames would in effect violate the standard and possibly cause switches that are standards-compliant to misrepresent or misunderstand these BPDUs. Effects on a redundant switches network in such a case would be deleterious.

There is a remote possibility to use the Q-in-Q tunelling to encapsulate the BPDUs of your devices into additional 802.1Q tag but that would most probably necessitate another piece of 3560/3750 switch on each side of the link and personally I do consider this to be a serious solution (perhaps a dirty and expensive workaround).

Perhaps if you provide us with an exhibit of your network we could help you further.

Best regards,

Peter

[yoram12345]

hi all ,

Let me elaborate on teh Topology :

3rd party # 1 p1--------------------1/0/9  Cisco 3750  1/0/10 -------------------3rd party # 2

|                                                                                                                                      |

------------------------------------------------------------------------------------------------------------

The 3rd party's equipment run Dynamic MPLS between them and can not be part of STP.

Therefore i need to pass the BPDU frames and tagged them so i can pass them transparently via L2 service vlan tagged.

I have also configured teh cisco as PVST+ but did not notice tagged frame by sniffer.

Guys , i know that standard STP is not tagged but i do not care.

As long as i can make this topology of cisco dual home working  it will do

Attached is teh cisco config

port 1 is for remote managemenet

port 5 is teh client

spanning-tree mode pvst
spanning-tree extend system-id
!
spanning-tree mst configuration
name eci_ring
!
no spanning-tree vlan 99
spanning-tree vlan 10 priority 28672
!
vlan internal allocation policy ascending
vlan dot1q tag native
!
!
interface GigabitEthernet1/0/1
switchport access vlan 99
spanning-tree portfast
spanning-tree mst 0 port-priority 240
!
interface GigabitEthernet1/0/2
!
interface GigabitEthernet1/0/3
!
interface GigabitEthernet1/0/4
!
interface GigabitEthernet1/0/5
switchport trunk encapsulation dot1q
switchport mode trunk
spanning-tree portfast
spanning-tree mst 0 port-priority 240
spanning-tree port-priority 240
!
interface GigabitEthernet1/0/6
!
interface GigabitEthernet1/0/7
!
interface GigabitEthernet1/0/8
!
interface GigabitEthernet1/0/9
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 5,10
switchport mode trunk
!
interface GigabitEthernet1/0/10
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 5,10
switchport mode trunk

[Jon Marshall]

Yoram

So the 3rd party switches are configured to be trunks on their end ?

If so by using PVST+ or R-PVST+ on the 3750 the BPDU's will be tagged and because you have added the native vlan tag command as well all BPDU's sent out by the 3750 will be tagged. So i'm not sure why you are not seeing them as tagged on the sniffer. Have you configured the sniffer port as a trunk port as well ?

Jon

[yoram12345]

Hi all,

It turn out that in PVST when i connected the cisco to smartbit test equipment i could notice teh vlan.

somehow wireshark does not present it.

any suggestions for wireshark ?

BR,

Yoram

[Jon Marshall]

yoram12345 wrote:
Hi all,
It turn out that in PVST when i connected the cisco to smartbit test equipment i could notice teh vlan.
somehow wireshark does not present it.
any suggestions for wireshark ?
BR,
Yoram

The port you are mirroring traffic to must be set as a trunk port and the NIC on your PC/laptop must understand 802.1q tagging.

Jon

[Peter Paluch · Accepted solution]

Jon,

and the NIC on your PC/laptop must understand 802.1q tagging

Actually, my take on this has always been slightly different - please correct me if I am wrong.

Any NIC, including the most ancient Ethernet cards on 10Base5 or 10Base2 would understand the 802.1Q frame because they do not interpret it. For them, it's just an EthernetII frame with the payload type of 0x8100. The tag would be processed in the driver of the NIC, i.e. in software. It is only with newer NICs that they try to offload the CPU by performing 802.1Q tag operations in hardware and that's where the problems start - some drivers, most notably under Windows, do not support the ability to tell the NIC to pass the tags to the operating system! The net result is that no tags are visible by the OS although the frames themselves are (they appear as untagged).

I haven't had any problems with capturing tagged frames under Linux but capturing traffic under Windows is just... not my cup of coffee. Too many quirks, too many limitations, too many brain damages or illogical exceptions.

So I would recommend very strongly running some Linux (native on a machine, not in a VM) and using that to capture the traffic. Any live distro with pre-installed Wireshark should do.

Best regards,

Peter

[Jon Marshall]

Peter

Actually, my take on this has always been slightly different - please correct me if I am wrong.

Any NIC, including the most ancient Ethernet cards on 10Base5 or 10Base2 would understand the 802.1Q frame because they do not interpret it.

I seem to remember having issues with this even on Linux but perhaps i am just misremembering

Jon

[Peter Paluch]

Jon,

I seem to remember having issues with this even on Linux but perhaps i am just misremembering 

Well, during my time here I've learned a lesson to never try to be absolute You probably are right. If I remember correctly, Goethe once wrote:

Grau, teurer Freund, ist alle Theorie

und grün des Lebens goldner Baum.

Obviously, the real life once again defies the theory

Best regards,

Peter

[Jon Marshall]

Goethe once wrote:

Grau, teurer Freund, ist alle Theorie

und grün des Lebens goldner Baum.

I think i'm fairly safe in saying that this is the first time we have ever had Goethe turn up on these forums. Mind you i can't be absolute about that as i haven't actually had time to read every single post

Jon

[Peter Paluch]

Jon,

Haven't had such a good laugh for quite a while Thank you!

Best regards,

Peter