Quick Survey: Who is using and would want to use Ethernet Port Aggregation ? a.k.a, Port Bonding

I am wondering how many people would want to see Ethernet Port Aggregation ? a.k.a, Port Bonding properly supported by Home Assistant Supervisor / OS. The way things are going more and more routers and runtime platforms are handling this but does that matter to you?

  • YES. I Need Link Aggregation supported Now!!
  • YES. I plan to use Link Aggregation in the near Future.
  • NO. I don’t need Link Aggregation and won’t

0 voters

I have no need of it.

1 Like

I’m not sure I understand.
To need this you’d need to have at least two ethernet ports on your instance.
So your throughput has exceeded the handling of a 100Mbs port and a 1Gbs (on a Pi 4b) is also insufficient. So we are talking about a NUC with an extra ethernet card or dual ports on the MB ?
For a standard PC you’d have to be running debian for a supported installation (from which you could aggregate independently anyway). Or a virtual machine, which again could aggregate independently.
What are you doing that requires greater than what a 1Gbs port can handle ? I presume lots of video streams/transfers.
I would love for you to paint a usage scenario for me.
But given the above you should be able to do this yourself, and otherwise you’d be talking about a very low number of users so I’m not sure you’d get much traction with the devs (unless one of them subscribes to your usage case)

I use lacp with proxmox…

1 Like

And your usage case … ?


43 Cameras?

30 Media players?

201 Device trackers?

What the heck is your application?

A hotel?

so not all these camera’s are at home. I tap into public feeds as well… like a traffic cam, which sends me a snapshot when I am about to leave…


At least I think it’s pronounced like that
It all seems quite normal apart from the 43 cameras


I don’t only have one HA install, but one main one, and then a smaller RPI based one in houses I rent out. (The camera’s are all outdoor at the rented accommodation) The main one aggregates everything in one place for me…

Big Brother is watching you !


And the 30 media players (I have 9 and I think that’s a LOT)

That is probably skewed by plex which adds a media player every time one of my mates watches something off my plex server from a new device…


You need to redefine your term “mates”


i am not fussy… pm me your plex email address and you will see why…

IMO, there are 2 reasons to consider aggregation. The primary one is to get more bandwidth. As others have said, though, I can’t imagine that even the largest HA installation can saturate a single 1Gbps port. The other is for reliability. That one is definitely shakier, though, as you can’t just say “2 ports are more reliable than one”. In reality, you have to weigh the risk associated with failure of a single port running a mature, time tested, non-aggregated stack vs 2 ports running a much less mature aggregation stack. Sure, you may be more robust against a hardware port failure but how often does that happen? On the flip side, you’re opening yourself up to a whole host of other issues related to more complex and less mature software. From a straight up downtime avoidance perspective, the choice is pretty clear for me right now. Ofc that calculus will change over time as the aggregation stuff becomes more mature.

Aren’t there are already lots of ways of doing this, just not Supervisor? Personally, I would think that the kind of person that thinks about link aggregation would probably be happier in the Docker environment where an HA container would gladly (and unwittingly) take advantage of link aggregation if supported by the underlying host. Maybe that’s just me, though.

I can certainly see some applications for LAG support, though, none of them apply to my current use cases, and likely won’t apply in the near future. At least, not nearer than 10GBe becoming more common and thus making LAG moot (until the next threshold).

Additionally, I feel that, in the cases where this IS needed, those users can simply install Home Assistant in a different manner. Especially considering the CPU required to actually do anything with this much bandwidth, this isn’t likely headed for a Raspberry Pi.

So, all of that to say, while I think there’s no reason to NOT implement LAG support so long as it doesn’t get in the way of other features, I don’t see any compelling reason to implement it, either.

I think that LAG is something that should be handled at the hypervisor level.

HA target form factor is for a raspberry pi… then if you really need there is a NUC or even full blown server with vm.

None of the initially intended form factors have dual nic’s.

Lacp would be for advanced use cases where you are probably running on a vm… with dual nic.

Therefore why bother with support for link aggregation in ha when it is already available via vm?

Therefore, should this ever make it onto any sort of backlog or roadmap, i suspect it will be close to the bottom of the priority list…