3

I have 18 Edge-corE ES4324 switches running 2.5.1.8 (and a single 3-com 2948-SFP Plus running 01.00.01) deployed initially as 2 physically separate networks, running side by side for the most part.

At some point wireless access to network A was desired from APs on network B, which was implemented by having the Ubiquiti UniFi access points running on network B add an SSID mapped to VLAN 4, and running links from the A switches into a PVID 4 port on the B switch with ingress filtering enabled. VLAN 4 only applied on the B switch, and only to the ingress port from A (as primary) and the AP(s) ports (as a tagged secondary.) VLAN 4 DOES NOT run over interswitch links except where there is no network A switch but there is a Network B switch with an AP needing it.

It recently came to light that something strange was going on with the cross-linked SSID in some locations, but not others. RSTP was blocking the cross-link ports in some places, but not others, and all the switches on both networks were hailing the 3-com (that is correctly the root of network A) as the root. I suspect now (though I did not notice the strangeness near enough in time to connect it to this until now) that the issue probably arose when I got around to putting the correct settings back into the 3-com, which had defaulted itself after a power outage but was running fine despite that (so the root would have been the "B" network root as the 3-com had set itself to 32768.)

So, I've gathered that RSTP is evidently not VLAN aware - there were loops (looking at wires) but no loops (paying attention to VLANs controlling what the wires did.) While there are VLAN-aware versions out there, I don't have them, and they have their own collection of acronyms.

I turned off STP on the link ports, from both sides. The SSID began to work as it should again in the places it had gone strange, where the ports had gone "Alternate" (actually "Alternated" in EdgeCore's unique approach to translating into English) when in RSTP and they were now non-STP so they were passing traffic again.

And yet all 19 switches still hail the 3-com as the root, with at least one ES4324 noting that the connection to the root is via port 18, (but also that port 18 is a non-STP port, since it's the link port and I disabled STP on it.)

Things seem to work correctly again, and I have gathered that I should not expect "normal" RSTP/STP to be VLAN-Aware, but I was rather surprised to find that taking all the "cross-link" ports out of RSTP ("disabled" or "Not enabled") had no apparent effect on the RSTP mating of the networks. Network B has RSTP settings defined that should result in it's root being on it (and in a different server room, as the outgoing connections are in different locations for the two networks); presumably the 3-com has the lower MAC address, but at this point (if things worked in the manner I would expect when I disable RSTP on a port) it should not be seeing the 3-com (or anything else on network A) as a RSTP entity. Evidently things don't work the way I think they should, and all that switching off RSTP on the port is doing is removing the ability to shut the port down automatically, while still passing and processing BDPUs.

Does this seem like the expected behavior to others?

  • 2
    STP and RSTP run a single instance for all VLANs. See if your switches support Multiple Spanning Tree 802.1s. You can run more than one instance and map VLANs to your instances. – Ron Trunk Oct 29 '14 at 1:58
  • No, they seem to be fairly limited; and unfortunately not getting updates for the firmware either (bought the Edge-corE's new in 2010, but the firmware is latest version circa 2008. The 3-Com was bought used. RSTP is about as exciting as they get... – Ecnerwal Oct 29 '14 at 2:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.