0

Bridge Mode Question

I have three eeros in Bridge Mode.  My topology is Modem > Router > Switch > individual Ethernet cables to each eero.  I saw a post somewhere that this is a bad idea, and that the topology should be Modem > Router > eero #1 > eero #2 > eero #3 > Switch.  This makes no sense to me.  Could anyone chime in with the "best" way to set this up?  TIA.

5replies Oldest first
  • Oldest first
  • Newest first
  • Active threads
  • Popular
  • In bridge mode, the topology should be Modem > Router > eero #1 > switch > all other devices including more eeros.  Downstream traffic after the router needs to be visible to an eero.  If you put the switch ahead of the eero, anything plugged into the switch is upstream of the 1st eero.

    Like
  • Thank you for your response.

    Is there a (noob-friendly) reason that "Downstream traffic after the router needs to be visible to an eero"?  My network has been working with no apparent issues while configured as Modem > Router > Switch > individual Ethernet cables to each eero.  I assume you're saying that (at least) one eero needs to have the "raw" router output?  Any help understanding this would be much appreciated.  Thanks.

    Like
    •  HFTobeason yep, that's definitely an incorrect configuration. If you want the technical reasons, I recommend you follow the eero's lead developer on www.reddit.com/r/eero. They can explain it in great detail. It has to do with traffic routing... you're basically inhibiting the best routing of traffic the way you're doing it.

      Like
    • txgunlover Thank you.  I'll for sure do as you suggest.

      Like
  • In case anyone reading this conversation wants the hard-core explanation, here it is:

    I designed it. It's not supposed to be used that way, and the results will be unpredictable.

    eero is a software-defined network based on a heterogeneous backplane constructed from 802.11 and 802.3 links. Given this, we are trying to build a switch with every ethernet port and every wireless access point vdev as member ports.

    The problem with this is that in any given network where two eeros are connected by a piece of ethernet cable, they're also connected by the mesh. As I say, each radio on each eero has a virtual device which we call an AP- it's the thing a wireless client connects to. we call those "ports", just like the ethernet ports on an eero.

    The problem is that frames coming into those ports have to be delivered to their destinations in a locally consistent way, or non-mesh devices will become very confused.

    Frames have to arrive in the same order they were sent, they all have to transit any piece of ethernet in the topology in the same direction every time, and if there is an ethernet path, even if for only part of the topology, we want to use it, because ethernet doesn't consume airtime. The mesh does not guarantee deterministic delivery of frames, but ethernet absolutely requires it.

    This is extra specially complicated because while our mesh frames have six addresses and a time-to-live counter and can be trusted not to go in circles, ethernet frames only have two addresses- a source and a destination. Wireless AP frames from non-mesh clients only have three, one of which is just the network address and isn't useful.

    So if an eero sees an ethernet frame, it needs to know whether it should inject it into the mesh or not, but the information it needs isn't present in the frame. Each ethernet segment needs to see each frame once and only once, and it needs to approach that segment from the same port onto that segment, or switches will mislearn the location of those clients.

    We have an algorithm we invented called STAMP which solves this problem by building a table of segments and their intersections, and modifying the forwarding rules at each intersection to give every client a locally consistent view of the network that looks just like ethernet.

    Unfortunately, if two eeros are both connected to an upstream router of some kind... STAMP can't work properly. The two eeros might both be responsible for injecting frames into their segments, or neither of them might be. The upstream device might choose to deliver the frame on one port, or neither. It doesn't support STAMP, so it can't participate in the STAMP algorithm, and delivery vectors will be formally unpredictable.

    They have no way to figure this out unless there's an eero at the root of the topology.

    So yes, you shouldn't do this. It might work, it might stop working. It'll be random and flakey. When you reboot some part of your network, it may stop working, or some clients may randomly stop being able to see other clients. It'll depend entirely on the arrival order of frames when the switch inside your router learns things. Oh, and if your router supports STP, it'll probably eventually disable one of the ports.

    Original post on reddit:

    https://www.reddit.com/r/eero/comments/gz83l6/is_there_any_issue_with_this_topology_in_bridge/ftg8gii?utm_source=share&utm_medium=web2x&context=3

    Like
Like Follow
  • 2 wk agoLast active
  • 5Replies
  • 27Views
  • 2 Following

Need Help? We're here for you!

We're big on support, and we want to make sure you always have the best eero experience possible. Here are several resources you can use if you ever need our help!


Quick links

Community Guidelines

Help Center

Contact eero support

@eerosupport

eero.com