2

Let me choose how eero measures path cost to match that of other participants in the Spanning Tree Algorithm (e.g. Sonos)

I have recently added an eero Pro Wifi System to my network to improve my wifi performance and replace my ISP router. Unfortunately, there are some Spanning Tree path cost issues between my switch, eero and Sonos devices that I can not resolve.

My existing network topology consists of a single core switch with a link to the internet router and multiple links to access switches which are distributed across the rooms in my house. Devices that can be are all wired to these access switches.

Some of these wired devices are Sonos Zone Players. Sonos supports its own wireless mesh system so that owners only have to wire in one such device and all the others will be reached wirelessly through that one. However, I have wired all but one of my Sonos devices because wiring is faster and more reliable than wireless.

This Sonos wireless infrastructure supports standard Layer 2 bridging with the switches they are connected to. This introduces loops in my network which must be addressed with a cooperative Spanning Tree Algorithm that runs across all of the switches and Sonos devices. This algorithm produces a logical tree (with no loops) that is used to determine the cheapest path between all devices.

To support the evaluation of the Spanning Tree, path cost needs to be taken into account. Unfortunately, the Sonos devices have a different way of measuring cost (802.1D-1998) than my switches (802.1W-200). The only way that I can resolve this is to force my switches to use the same "currency" as the Sonos devices. This works well.

https://en.wikipedia.org/wiki/Spanning_Tree_Protocol

One of the three units in the eero Pro Wifi system replaced my ISP router and is wired to my core switch. The other two were strategically placed about my house and hard wired into access switches.

Unfortunately, apparently, eero also uses a different path cost "currency" (802.1W-200?) than the Sonos devices. This is evidenced by me removing the 1 Gbit/s link (path cost 4) between my core switch and an access switch (with both an eero (path cost 4) and a Sonos device (path cost 19)) and noting that the Spanning Tree Algorithm determines the next lower cost path is through the Sonos wireless mesh instead of eero. From this choice, I must assume that path costs are measured higher in the eero mesh than the Sonos mesh.

To fix this Spanning Tree issue, I need all participants in the algorithm to use the same path cost "currency". While I am afforded a choice on my switches, I have no such choice on my eero or Sonos devices.

On eero, please give me this choice.

4 replies

null
    • Drew
    • 5 yrs ago
    • Reported - view

    Hi, rossetyler –

    Thanks for taking the time to share your feedback, and welcome to the Community! While we definitely appreciate your detailed and thorough insights here, I'd like to mention right off the bat that the eero system doesn't support or integrate with STP in any fashion due to the inherent incompatibilities between mesh and STP. Because of these incompatibilities, we don't have any plans to implement STP functionality for the foreseeable future, and we encourage users to avoid the use of switches and other network devices that rely upon STP.

    All this being said, the eero system still supports full integration with Sonos with either a wireless or hardwired topology, though some slight topological adjustments might be required for best performance. Sonos support has grown quite adept at helping customers specifically with setup on eero networks, so if you contact their support and speak with a senior agent, they should be able to set you up nicely. Alternatively, you can also call us directly at 877-659-2347 or email support@eero.com and we'd be happy to work with you on any adjustments necessary for best performance.

    Thanks again so much for your thoughts and feedback, and please feel free to share any other requests or improvements that come to mind!

    Kindly,
    Drew, eero Community

    • rossetyler
    • 5 yrs ago
    • Reported - view

    > the eero system doesn't support or integrate with STP in any fashion ...

    Eero behavior seems to suggest otherwise as well as your own release notes
    https://support.eero.com/hc/en-us/articles/209636523-eero-Software-Release-Notes

    > eeroOS v2.1.0 - Released December 15, 2016
    > TrueMesh™ - Improvements to stability and interoperability with various spanning tree protocols

    > ... due to the inherent incompatibilities between mesh and STP

    Inherent incompatibilities? Then how does Sonos do it in their mesh?

    I won't pretend to be an network engineer but I think I have a crude understanding of how these things work. Perhaps not. Please explain how my system works without Spanning Tree. I have two switches that are connected as follows:

    1. Directly by wire.
    2. Indirectly/wirelessly through Sonos devices connected to these switches
    3. Indirectly/wirelessly through Eero devices connected to these switches

    I have a workstation on one switch from which I ping a device on the other. As I fail 1, the network path switches to 2. I can see this by inspecting the dynamic MAC addresses on the workstation's switch and noting which port the pingable device falls on. As I fail 2, the network path switches to 3. As I restore 2, the network path switches back to 2. As I restore 1, the network path switches back to 1. Except for the ordering (which I would expect to be 1, 3, 2 and could be fixed per the topic of this post), this behavior is what I would expect with a properly behaved system under Spanning Tree.

    As I understand it, spanning tree is intended to ensure that redundant paths in the network (as 1, 2 and 3 have proven to be) do not create loops and result in broadcast storms that will bring down the network. I have suffered from this behavior before I got Spanning Tree to work with Sonos (before my Eeros). Besides a temporary communication failure as the network heals from these induced faults, I have not recognized any problem. What don't I understand?

      • Drew
      • 5 yrs ago
      • Reported - view

      Thanks for your reply here rossetyler – I'd be happy to help clear up a few points here!

      First, I'd like to reiterate that eero doesn't support STP (as an aside, this isn't limited just to eero: no fully integrated mesh WiFi system will use STP either). Our previous firmware versions have allowed the system to compensate for the networking issues caused by using STP devices in tandem with eero, but we've been able to improve upon and supersede that framework in all the improvements and revisions we've made since v2.1.0. More on that below.

      Next, concerning Sonos – while SonosNet is a proprietary, self-managed local wireless network, it isn't a proper mesh framework as such; rather, it's just a modified approach to traditional WDS, or a wireless distribution system. In other words, Sonos implements STP precisely because their local network doesn't operate on a mesh paradigm, but rather as a series of relays and repeaters.

      As far as STP itself is concerned, you're right that its primary goal is to prevent loops in a traditional network framework (e.g. SonosNet), but cyclical routing and topology are actually of benefit to mesh networks, and help provide many of the reliability and performance benefits characteristic of mesh. Specifically, eero will actively drop STP frames when they try to enter the mesh.

      With that in mind, hopefully this helps illustrate both why our mesh and STP don't play nice, as well as why it's not really meaningful to implement a feature that changes how the eeros measure their path cost, to go back to your original post – the only path costs the eeros care about are their own mesh paths, which they'll automatically monitor and optimize on their own. Thanks again so much for taking the time to share your thoughts, and if you should have any other specific concerns or issues with the Sonos functionality on your network, we encourage you to reach out directly to support for help!

      Kindly,
      Drew, eero Community.

    • rossetyler
    • 5 yrs ago
    • Reported - view

    I appreciate your support. I guess my ignorance is showing. I am glad to learn. Thank you.

    > we encourage you to reach out directly to support for help

    That is exactly what I did. Coincident with composing this feature request, I emailed support@eero.com . So far, this is the only place I have gotten any support. Thank you.

    Prior to eero, my experience with Spanning Tree has been limited to wired networks and Sonos. There, Spanning Tree is indirectly responsible for determining which bridges (ports) were crossed across the network between hosts by blocking their broadcast ARP requests on all but the least expensive of redundant paths in the network. There, tuning of Spanning Tree costs using a shared "currency" is critical in stopping broadcast storms *and*, as a result, choosing the best path. Specifically, wired over wireless.

    I guess I jumped to conclusions, based on this experience, that Spanning Tree must be used by eero to prevent ARP broadcast storms (and, as a consequence, influence paths through the network). I guess that Spanning Tree does not have to be used but eero must be doing something to prevent broadcast storms (and whatever that is still influences paths through the network). Otherwise, with my redundant links (1, 2 and 3, above), I would be experiencing broadcast storms. I think I would recognize this as I have suffered them before.

    So, rather than a request a feature to correct a presumed implementation that does not exist, I guess I should have just stated my problem. That is, in my network, with three redundant paths to choose from (1. wired, 2. Sonos wireless, 3. eero wireless), I am experiencing a preference of 1 over 2 over 3. This should not be the case as 3 is better than 2. It should be 1 over 3 over 2. This would happen if a uniform Spanning Tree solution were in place. If not that then what?

Login to reply

Content aside

  • 2 Votes
  • 5 yrs agoLast active
  • 4Replies
  • 666Views
  • 2 Following