During a test session i did find a very nasty bug between Router OS and a Procurve Aruba 2530 switch. the kind of bug that can fully break an entire network.

This is the first time i have a problem with STP, but this one is a big one ! I've heard some tech guys inside Datacenters complaining about STP, Now i know why

The bug is not directly related to Mikrotik, but it was triggered by a Mikrotik Router where i did left enable RSTP in a bridge.

After adding a Mikrotik router in the setup, i did loose all connectivity in my network. Everywhere even inside the telephony and other Vlans.

After scratching my hairs during a couple hours, i did watch with Wireshark and did see GVRP and RSTP frames on the link. Then i did check the switch settings and saw that STP was fully disabled in the switch. But GVRP enabled. GVRP frames were going to the Mikrotik bridge, and RSTP frame were going to the Procurve switch.

STP was disabled on the switch, but GVRP enabled. GVRP is a protocol to exchange VLAN configuration data automatically between all switches of the Network.

The switch was fully mad, mixing VLANS and breaking connectivity on all VLANS. Then i did disable RSTP on the Mikrotik and bam ! no more problems.

I think that the switch was missinterpreting the RSTP frames as GVRP frames, probably sending RSTP information in the VLAN tables !!

Then i did enable again RSTP on the Mikrotik and again the same madness on the switch, breaking all connectivity.

Then i did enable MSTP in the switch (there is no more STP or RSTP in those switches), and problem solved.

The only explanation is that when the 2530 switch (latest firmware) is receiving RSTP frames, it takes them as GVRP frames, corrupting the VLAN tables. !!
It does this only if STP is disable on the switch !

After checking in details the frames, RSTP and GVRP frames are very similar, they are 802.2 Ethernet frames with a LLC header that have the same 0x42 number for DSAP and SSAP. Weird.
Because the RSTP packet is very small compared to GVRP, i think that the switch were resseting the VLAN table when it did take erroneously RSTP frames for GVRP data.

Morals : sometimes it's better to leave STP enabled

It's definitely a Procurve switch bug not related to Mikrotik.

Weird ... this could potentially be exploited to create a Denial of Service, assuming you can make them act funny from user accessible Access ports.

Sure, but the attacker will need level 2 access and the ability to forge some 802.2 packets. After that the GVRP packet structure is very simple, this is a list of vlans with their numbers.

The culprit is GVRP not filtering correctly packets for him when STP is disabled in the switch.

This mean that GVRP must be disabled on edge and access ports and that the internals of the networks must be safe to use such an open protocol.

If not DOS attacks are possible sending vlan table list in the mesh of switches.

On this small switch i did leave enabled GVRP on access ports. My bad

After checking in details the frames, RSTP and GVRP frames are very similar, they are 802.2 Ethernet frames with a LLC header that have the same 0x42 number for DSAP and SSAP. Weird.

That is correct, they both use DSAP and SSAP 0x42 "IEEE 802.1 Bridge Spanning Tree Protocol". The name is somwhat misleading, something such as "Bridge Management Protocols" would be more appropriate. Even though the LLC header is the same, the destination MAC address differs for the two :

GVRP 01:80:C2:00:00:21 ss:ss:ss:ss:ss:ss nnnn 42 42 03 ....
RSTP 01:80:C2:00:00:00 ss:ss:ss:ss:ss:ss nnnn 42 42 03 ....

so the target switch can easily demultiplex incoming packets to be processed appropriately. In this case as you say it appears to be an Aruba bug.

Fist thing you cannot include access ports in a dynamic GVRP VLAN. And a dynamic VLAN cannot get an IP Address.

You must make the VLANs you need on access ports statics before you can configure them and give them eventually an IP address.

With this command :
static-vlan <vlan-id>

(do not forgot to issue a <write memory> command to make that permanent).

GVRP allow to exchange VLANs between swtiches and automatically set them on trunk ports for communication between switches.

All GVRP Vlans exchanged between switches are considered dynamic VLANs before you make them static for each switch.

So all that you have to do is to create all the needed VLANs on a first switch, then go to other switches and make static VLANs on them for those that need to be distributed on access ports.


If there was a GVRP client on Windows / Linux PCs a fully automatic setup would be possible But fully insecure

Obviously GVRP is useful only when there is more than two or three switches and / or when there is many VLANs or when the setup is growing often.

The amount of added needed setup (disabling GVRP on access ports for safety) is a problem for very small setups.

It is important to disable GVRP on access ports (and perhaps on some edge ports) and on ports where Mikrotik routers are connected, to avoid the previously described Aruba bug if STP is enabled on those routers. GVRP is not a safe protocol, so it is easy to attack a full network through it.

Run the unknown-vlans command on a per-port basis to prevent denial-of-service attacks. The interface unknown-vlans command allows you to :

• Disable the port from sending advertisements of existing GVRP-created VLANs on the switch.
• Drop all GVRP advertisements received on the port.

Again if you have only two switches, there is probably no need for GVRP. This will save you a few hours of learning and testing.

It's better to fully disable it in this case and set your VLANs manually on both switches.


Some information here:

https://techhub.hpe.com/eginfolib/netwo ... /ch02.html


If you want more information about GVRP i encourage you to read the switch <advanced traffic management guide>.