Eero devices expose LAN to SP during reboot
I have a customer who's Eero seems to be exposing either their entire LAN L2 or at least several Eero MACs to the SP side consistently upon every reboot, and given the lack of configurability that the Eero presents, I'm at a loss to figure out how to make it not do that. Some sources suggest this is "expected behavior" which seems baffling. I can't imagine many SPs take kindly to having their access network flooded with dozens of MACs all asking for addressing via DHCP on a single access port. Is this really "expected behavior" from a customer edge router, these days? If so, what's the protocol people have adopted to handle it? The only thing I can think of is very short MAC aging at L2 and then blindly handing any device that shows up on the same access port the same addresses regardless of what L2 address it purports to have. Of course that doesn't fix the fact that any device on the customer's network that successfully completed the DHCP exchange while the true border Eero was "getting ready" now has unusable addressing. Turning DHCP lease times down low enough to combat this without the customer noticing is pretty much a non-starter. So what gives? -- Brandon Martin
hi Brandon... it sounds like alan-bypass is enabled ( usually by jumpers or a dip switch on the router it is an 8 pole relay between two nic interfaces for passing through traffic in the event of a failure of a router... ( config for appropiate use of bypass is p1 uplink connected to a primary router with a lanbypass as a group or( when the device is booted up acts as a layer 2 bridge ) then the backup router is plugged into the second port of tje lanbypass group so the router acts like a layer 1 passthrough cable to the 2nd router when it is switched off or being reset ( and in normal operation a layer2 device exposing the bridged wan of the primary router and the wan of 2ndary router to the 1 port of yhe upstream ntu... ( idea is that 1 port can be passed through 2 Kindest regards, Tom Smyth. On Wed, 16 Sept 2026, 22:03 Brandon Martin via NANOG, <nanog@lists.nanog.org> wrote:
I have a customer who's Eero seems to be exposing either their entire LAN L2 or at least several Eero MACs to the SP side consistently upon every reboot, and given the lack of configurability that the Eero presents, I'm at a loss to figure out how to make it not do that.
Some sources suggest this is "expected behavior" which seems baffling. I can't imagine many SPs take kindly to having their access network flooded with dozens of MACs all asking for addressing via DHCP on a single access port.
Is this really "expected behavior" from a customer edge router, these days? If so, what's the protocol people have adopted to handle it? The only thing I can think of is very short MAC aging at L2 and then blindly handing any device that shows up on the same access port the same addresses regardless of what L2 address it purports to have.
Of course that doesn't fix the fact that any device on the customer's network that successfully completed the DHCP exchange while the true border Eero was "getting ready" now has unusable addressing. Turning DHCP lease times down low enough to combat this without the customer noticing is pretty much a non-starter.
So what gives?
-- Brandon Martin _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/KCOYDZLR...
in your customer case it sounds like the wan and lan of their router are also in the same lanbypass group which joins their internal switch to their wan Kindest regards, Tom Smyth. On Wed, 16 Sept 2026, 22:16 Tom Smyth, <tom.smyth@wirelessconnect.eu> wrote:
hi Brandon... it sounds like alan-bypass is enabled ( usually by jumpers or a dip switch on the router
it is an 8 pole relay between two nic interfaces for passing through traffic in the event of a failure of a router... ( config for appropiate use of bypass is p1 uplink connected to a primary router with a lanbypass as a group or( when the device is booted up acts as a layer 2 bridge ) then the backup router is plugged into the second port of tje lanbypass group
so the router acts like a layer 1 passthrough cable to the 2nd router when it is switched off or being reset ( and in normal operation a layer2 device exposing the bridged wan of the primary router and the wan of 2ndary router to the 1 port of yhe upstream ntu...
( idea is that 1 port can be passed through 2
Kindest regards, Tom Smyth.
On Wed, 16 Sept 2026, 22:03 Brandon Martin via NANOG, < nanog@lists.nanog.org> wrote:
I have a customer who's Eero seems to be exposing either their entire LAN L2 or at least several Eero MACs to the SP side consistently upon every reboot, and given the lack of configurability that the Eero presents, I'm at a loss to figure out how to make it not do that.
Some sources suggest this is "expected behavior" which seems baffling. I can't imagine many SPs take kindly to having their access network flooded with dozens of MACs all asking for addressing via DHCP on a single access port.
Is this really "expected behavior" from a customer edge router, these days? If so, what's the protocol people have adopted to handle it? The only thing I can think of is very short MAC aging at L2 and then blindly handing any device that shows up on the same access port the same addresses regardless of what L2 address it purports to have.
Of course that doesn't fix the fact that any device on the customer's network that successfully completed the DHCP exchange while the true border Eero was "getting ready" now has unusable addressing. Turning DHCP lease times down low enough to combat this without the customer noticing is pretty much a non-starter.
So what gives?
-- Brandon Martin _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/KCOYDZLR...
On 9/16/26 17:16, Tom Smyth wrote:
hi Brandon... it sounds like alan-bypass is enabled ( usually by jumpers or a dip switch on the router
it is an 8 pole relay between two nic interfaces for passing through traffic in the event of a failure of a router... ( config for appropiate use of bypass is p1 uplink connected to a primary router with a lanbypass as a group or( when the device is booted up acts as a layer 2 bridge ) then the backup router is plugged into the second port of tje lanbypass group
so the router acts like a layer 1 passthrough cable to the 2nd router when it is switched off or being reset ( and in normal operation a layer2 device exposing the bridged wan of the primary router and the wan of 2ndary router to the 1 port of yhe upstream ntu... I didn't even know they had this feature. My google-fu (and duckduckgo-fu) also fails to find any references to it, but Eero's documentation is sort of scattered.
The Eero was bought through retail channels. Would they ship it with this feature enabled? I wouldn't think so. It's plausible it was a re-packaged return. I don't think their Eero is configured in bridge mode. They certainly wouldn't have set it to that intentionally, and Eero hides that setting pretty well. Everything seems to work properly once the Eero finishes rebooting. It takes over routing and NAT functions and reliably exposes just one MAC to the SP network after that point. Note if you're unfamiliar with the Eero: It's a very consumer-oriented device with software to match. The device has two unidentified ports, and all configuration happens through a mobile app. It uses largely undocumented heuristics to figure out what to do for each given use case. It usually seems to get it right, but in this case, it's doing something very bad. I have other customers using Eeros with no apparent problems, so it's possible that this customer fat-fingered a setting somewhere.
Hi, I had this experience with a Netgate 1100 at my home some time ago when its boot storage failed, so it just became a dumb switch when powered up. My provider actually allowed multiple DHCP leases, so about 24 hours after it happened I realized all my DHCP devices were directly on the Internet. The device is based on a switch chip, so it has to boot to assign VLANs to the ports and secure the network. Reference: https://docs.netgate.com/pfsense/en/latest/solutions/sg-1100/switch-overview... I suspect there's a lot of commodity equipment based on common chips that may behave the same way. Mark On Wed, Sep 16, 2026 at 4:03 PM Brandon Martin via NANOG < nanog@lists.nanog.org> wrote:
I have a customer who's Eero seems to be exposing either their entire LAN L2 or at least several Eero MACs to the SP side consistently upon every reboot, and given the lack of configurability that the Eero presents, I'm at a loss to figure out how to make it not do that.
Some sources suggest this is "expected behavior" which seems baffling. I can't imagine many SPs take kindly to having their access network flooded with dozens of MACs all asking for addressing via DHCP on a single access port.
Is this really "expected behavior" from a customer edge router, these days? If so, what's the protocol people have adopted to handle it? The only thing I can think of is very short MAC aging at L2 and then blindly handing any device that shows up on the same access port the same addresses regardless of what L2 address it purports to have.
Of course that doesn't fix the fact that any device on the customer's network that successfully completed the DHCP exchange while the true border Eero was "getting ready" now has unusable addressing. Turning DHCP lease times down low enough to combat this without the customer noticing is pretty much a non-starter.
So what gives?
-- Brandon Martin _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/KCOYDZLR...
On Wed, Sep 16, 2026 at 05:02:29PM -0400, Brandon Martin via NANOG wrote:
I have a customer who's Eero seems to be exposing either their entire LAN L2 or at least several Eero MACs to the SP side consistently upon every reboot, and given the lack of configurability that the Eero presents, I'm at a loss to figure out how to make it not do that.
I doubt you're going to be able to make it not do that, and I suspect a very large number of consumer routers do this. At heart, they are typically based around an SoC and a switching module; until it boots enough to configure the switching module, it is a dumb switch, and will act like one. If the access technology you're using supports it, some form of mac locking/filtering your access customers is the usual way SPs handle unwanted traffic. --msa
On 9/16/26 18:08, Majdi S. Abbas wrote:
If the access technology you're using supports it, some form of mac locking/filtering your access customers is the usual way SPs handle unwanted traffic.
But how does one determine what MAC address to lock to? You can't lock to the first MAC you see. That could be something random on their LAN. You can't even lock to the first thing you see that sends a DHCP request for the same reason. The only thing I can think of that would be reasonably automated is trialing extremely short aging times and lease expiry times until you're "reasonably confident" that the "real" router has actually shown up then locking to that. That seems...problematic. Also hard to programmatically define especially in a way that an access layer can handle. Do people just manually purge whatever they see during initial install until they're sure that the "real router" is there then statically lock the port to that MAC? Jeesh, that's messy, but I guess it's functional. I can keep unwanted traffic from being a network operational issue. The issue is separating the unwanted from the wanted. -- Brandon Martin Mothic Technologies 317-565-1357 x7000
Sorry if this is a dumb question, but did you make sure the customer didn't plug their WAN link into a LAN port? On Wed, Sep 16, 2026, 6:19 PM Brandon Martin via NANOG < nanog@lists.nanog.org> wrote:
On 9/16/26 18:08, Majdi S. Abbas wrote:
If the access technology you're using supports it, some form of mac locking/filtering your access customers is the usual way SPs handle unwanted traffic.
But how does one determine what MAC address to lock to? You can't lock to the first MAC you see. That could be something random on their LAN. You can't even lock to the first thing you see that sends a DHCP request for the same reason.
The only thing I can think of that would be reasonably automated is trialing extremely short aging times and lease expiry times until you're "reasonably confident" that the "real" router has actually shown up then locking to that. That seems...problematic. Also hard to programmatically define especially in a way that an access layer can handle.
Do people just manually purge whatever they see during initial install until they're sure that the "real router" is there then statically lock the port to that MAC? Jeesh, that's messy, but I guess it's functional.
I can keep unwanted traffic from being a network operational issue. The issue is separating the unwanted from the wanted. -- Brandon Martin Mothic Technologies 317-565-1357 x7000 _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ON4QCLSD...
On 9/16/26 18:28, Lee Fawkes wrote:
Sorry if this is a dumb question, but did you make sure the customer didn't plug their WAN link into a LAN port?
That's the fun thing about Eeros. They don't have designated-function ports. Each device has two ports, and it is supposed to figure out what to do with them on its own. Obviously I'd expect this behavior on a device with designated-function ports that includes several bridged LAN ports. So not a dumb question, just "impossible" in this case :P -- Brandon Martin
A lot of these devices actually don't even have a dedicated WAN Port, they do some kind of detection magic and automatically pick out the WAN. Which could partially be why this is happening, maybe it's malfunctioning on that model and allowing a bridge. Because it's not necessarily that uncommon these days, I'm sure plenty of users would have issues with it due to the fact that many ISPs lock to the first one or two MACs seen. ---------------------------------- Brandon Jackson bjackson@napshome.net On Wed, Sep 16, 2026, 18:28 Lee Fawkes via NANOG <nanog@lists.nanog.org> wrote:
Sorry if this is a dumb question, but did you make sure the customer didn't plug their WAN link into a LAN port?
On Wed, Sep 16, 2026, 6:19 PM Brandon Martin via NANOG < nanog@lists.nanog.org> wrote:
On 9/16/26 18:08, Majdi S. Abbas wrote:
If the access technology you're using supports it, some form of mac locking/filtering your access customers is the usual way SPs handle unwanted traffic.
But how does one determine what MAC address to lock to? You can't lock to the first MAC you see. That could be something random on their LAN. You can't even lock to the first thing you see that sends a DHCP request for the same reason.
The only thing I can think of that would be reasonably automated is trialing extremely short aging times and lease expiry times until you're "reasonably confident" that the "real" router has actually shown up then locking to that. That seems...problematic. Also hard to programmatically define especially in a way that an access layer can handle.
Do people just manually purge whatever they see during initial install until they're sure that the "real router" is there then statically lock the port to that MAC? Jeesh, that's messy, but I guess it's functional.
I can keep unwanted traffic from being a network operational issue. The issue is separating the unwanted from the wanted. -- Brandon Martin Mothic Technologies 317-565-1357 x7000 _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ON4QCLSD...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/CVNSVIFS...
I’ve got an eero mesh wireless network…in bridge mode. Can’t see that happening in such a configuration, because the router/firewall clearly blocks that sort of behavior…but nodes all do get addresses from the internal DHCP server. Seems like that would be a relatively easy way to fix this issue Get Outlook for iOS<https://aka.ms/o0ukef> ________________________________ From: Brandon Jackson via NANOG <nanog@lists.nanog.org> Sent: Wednesday, 16 September 2026 19:45:55 To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Brandon Jackson <bjackson@napshome.net> Subject: Re: Eero devices expose LAN to SP during reboot A lot of these devices actually don't even have a dedicated WAN Port, they do some kind of detection magic and automatically pick out the WAN. Which could partially be why this is happening, maybe it's malfunctioning on that model and allowing a bridge. Because it's not necessarily that uncommon these days, I'm sure plenty of users would have issues with it due to the fact that many ISPs lock to the first one or two MACs seen. ---------------------------------- Brandon Jackson bjackson@napshome.net On Wed, Sep 16, 2026, 18:28 Lee Fawkes via NANOG <nanog@lists.nanog.org> wrote:
Sorry if this is a dumb question, but did you make sure the customer didn't plug their WAN link into a LAN port?
On Wed, Sep 16, 2026, 6:19 PM Brandon Martin via NANOG < nanog@lists.nanog.org> wrote:
On 9/16/26 18:08, Majdi S. Abbas wrote:
If the access technology you're using supports it, some form of mac locking/filtering your access customers is the usual way SPs handle unwanted traffic.
But how does one determine what MAC address to lock to? You can't lock to the first MAC you see. That could be something random on their LAN. You can't even lock to the first thing you see that sends a DHCP request for the same reason.
The only thing I can think of that would be reasonably automated is trialing extremely short aging times and lease expiry times until you're "reasonably confident" that the "real" router has actually shown up then locking to that. That seems...problematic. Also hard to programmatically define especially in a way that an access layer can handle.
Do people just manually purge whatever they see during initial install until they're sure that the "real router" is there then statically lock the port to that MAC? Jeesh, that's messy, but I guess it's functional.
I can keep unwanted traffic from being a network operational issue. The issue is separating the unwanted from the wanted. -- Brandon Martin Mothic Technologies 317-565-1357 x7000 _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ON4QCLSD...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/CVNSVIFS...
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/HQK7GJ5Y...
On 9/16/26 19:52, Stephen Fischer via NANOG wrote:
I’ve got an eero mesh wireless network…in bridge mode. Can’t see that happening in such a configuration, because the router/firewall clearly blocks that sort of behavior…but nodes all do get addresses from the internal DHCP server.
Seems like that would be a relatively easy way to fix this issue
Yes, but now there's a separate device to buy and manage: another router. For the ordinary consumer use case that Eeros are targeted for, that's unideal. -- Brandon Martin
On Wed, 16 Sep 2026, Brandon Martin via NANOG wrote:
On 9/16/26 18:08, Majdi S. Abbas wrote:
If the access technology you're using supports it, some form of mac locking/filtering your access customers is the usual way SPs handle unwanted traffic.
But how does one determine what MAC address to lock to? You can't lock to the first MAC you see. That could be something random on their LAN. You can't even lock to the first thing you see that sends a DHCP request for the same reason.
I thought I was the only one pulling my hair out with this. Calix has a feature that lets you limit a PON customer to a "single MAC at a time." Each time they do a DHCP request from another MAC and get a new IP, the Calix shelf will forge a DHCP release request as the previous IP/MAC seen from that customer. It at least limits the damage the customer can do (especially important in smaller subnets where one misconfigured customer can run the subnet out of IPs). It must be annoying as hell for the user, each device on their network essentially taking turns having Internet. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Blue Stream Fiber, Sr. Neteng | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
Eero was good for a little while when it first came out. Now, it is a shit-piece. Between Eero and Google Mesh, i am not sure which is worse. Both of their QoS algos are absolute shit. I tell my customers to rip that stuff out and replace with Ubiquiti mesh. They are all much happier now after doing so. -Mike
On Sep 16, 2026, at 20:52, Jon Lewis via NANOG <nanog@lists.nanog.org> wrote:
On Wed, 16 Sep 2026, Brandon Martin via NANOG wrote:
On 9/16/26 18:08, Majdi S. Abbas wrote: If the access technology you're using supports it, some form of mac locking/filtering your access customers is the usual way SPs handle unwanted traffic.
But how does one determine what MAC address to lock to? You can't lock to the first MAC you see. That could be something random on their LAN. You can't even lock to the first thing you see that sends a DHCP request for the same reason.
I thought I was the only one pulling my hair out with this. Calix has a feature that lets you limit a PON customer to a "single MAC at a time." Each time they do a DHCP request from another MAC and get a new IP, the Calix shelf will forge a DHCP release request as the previous IP/MAC seen from that customer. It at least limits the damage the customer can do (especially important in smaller subnets where one misconfigured customer can run the subnet out of IPs). It must be annoying as hell for the user, each device on their network essentially taking turns having Internet.
---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Blue Stream Fiber, Sr. Neteng | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/SLSR2DHF...
Can’t say I’ve seen this before. Out of curiosity, are you allocating customers global IPs, or are you using 6598 or 1918 space? If you’re using 1918 space, which you shouldn’t be, I could see some sort of logic in the software thinking the device should be in bridge mode.
On Sep 16, 2026, at 16:03, Brandon Martin via NANOG <nanog@lists.nanog.org> wrote:
I have a customer who's Eero seems to be exposing either their entire LAN L2 or at least several Eero MACs to the SP side consistently upon every reboot, and given the lack of configurability that the Eero presents, I'm at a loss to figure out how to make it not do that.
Some sources suggest this is "expected behavior" which seems baffling. I can't imagine many SPs take kindly to having their access network flooded with dozens of MACs all asking for addressing via DHCP on a single access port.
Is this really "expected behavior" from a customer edge router, these days? If so, what's the protocol people have adopted to handle it? The only thing I can think of is very short MAC aging at L2 and then blindly handing any device that shows up on the same access port the same addresses regardless of what L2 address it purports to have.
Of course that doesn't fix the fact that any device on the customer's network that successfully completed the DHCP exchange while the true border Eero was "getting ready" now has unusable addressing. Turning DHCP lease times down low enough to combat this without the customer noticing is pretty much a non-starter.
So what gives?
-- Brandon Martin _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/KCOYDZLR...
On Sep 16, 2026, at 5:02 PM, Brandon Martin via NANOG <nanog@lists.nanog.org> wrote:
Is this really "expected behavior" from a customer edge router, these days?
Yes. These are consumer devices, and unlike the routers that we were used to when you had to set a lot of additional things (~20+ years ago). The expectation is that you plug them in and any ethernet port does the right thing. I’ve had good luck with these devices and are the ones that we recommend/use with our customers. Most of our customers don’t even complete the process to link the device so they can manage it, it’s an appliance just like a light bulb or anything else that requires little/no support to setup or configure. I have some scripts that I use to interact with their portal so we can make minor setting changes automatically, but this is much better than making sure the customer put the yellow cat 5 into the yellow rj45 port, which they honestly can’t identify the difference between rj45 and rj11. The number of customers who hear they are getting fiber and think they can use a cable modem is non-zero as well. It’s ok, we keep spares on the truck and they work reasonably well. The access network has protections against this, and the biggest problem we’ve had with setup of them is when there’s a bug or there’s no cellular service at the location. There’s a big gap in the mindset around this. The serial number can be setup remotely, but when there’s internet access it would be nicer if the phone/app would handle this situation better. (Eg: imagine setting one up when connected via satellite when in a remote location - not really possible). The plusses of the buit-in speed test and this flexibility in auto-picking the upstream port is always positive thing. That you can use it to extend the lan as well over wireless to a wired device is also a plus. - Jared Ps: not an AD, just based on my own experiences with them, they are what I recommend
On 9/18/26 09:06, Tim Burke wrote:
Can’t say I’ve seen this before. Out of curiosity, are you allocating customers global IPs, or are you using 6598 or 1918 space?
If you’re using 1918 space, which you shouldn’t be, I could see some sort of logic in the software thinking the device should be in bridge mode.
Global space for both IPv4 and IPv6 in this case. The Eero even does eventually get an IPv6 PD. When I need to do CGNAT44, I do use 6598 space for the reasons you anticipate among others.
On 9/18/26 09:19, Jared Mauch wrote:
The access network has protections against this, and the biggest problem we’ve had with setup of them is when there’s a bug or there’s no cellular service at the location. There’s a big gap in the mindset around this. The serial number can be setup remotely, but when there’s internet access it would be nicer if the phone/app would handle this situation better. (Eg: imagine setting one up when connected via satellite when in a remote location - not really possible).
Protection against service disruption to others is one thing. How do you handle figuring out when the customer device has figured things out and is the MAC address actually exposed to the access network and the thing requesting DHCP service? It's definitely not "the first thing you see" in this instance.
participants (11)
-
Brandon Jackson -
Brandon Martin -
Jared Mauch -
Jon Lewis -
Lee Fawkes -
Majdi S. Abbas -
Mark Mayfield -
Mike Lyon -
Stephen Fischer -
Tim Burke -
Tom Smyth