Interesting.  I’d never seen that.  I guess I’m wrong.  But I do know mods have stayted away from that advice in the past, allowing us users to give it instead.

I have no clue where it came from, it was here in the early 200?s when I got here.

While i wouldn't offer it as the first option in every case it does solve a problem that so far has escaped a better solution. Since it does solve that specific problem, is easy to do and does no harm I do offer it often. I feel the ability to remove the addressing issue from the list of possible issues makes that a reasonable position to take. If it is later found to not be a problem it is a couple minutes work to remove the reservations.

I personally don’t know why anybody wouldn’t use IP reservations.  It doesn’t hurt anything, and it eliminates a problem that has plagued consumer grade routers for as long as they’ve been out there. 

Not just consumer grade routers, my Ubiquity and Netgate/pfSense routers struggled with Sonos and random IP assignments. 

Just for clarity, and as I previously mentioned, you may think they are random, as they are not sequential, but dnsmasq (that a lot of consumer routers, including UniFi will use) uses a mathematical hash to ensure the device gets the same IP address based on its MAC address, effectively a reservation by default:

https://manpages.debian.org/bookworm/dnsmasq-base/dnsmasq.8.en.html

--dhcp-sequential-ip

Dnsmasq is designed to choose IP addresses for DHCP clients using a hash of the client's MAC address. This normally allows a client's address to remain stable long-term, even if the client sometimes allows its DHCP lease to expire. In this default mode IP addresses are distributed pseudo-randomly over the entire available address range. There are sometimes circumstances (typically server deployment) where it is more convenient to have IP addresses allocated sequentially, starting from the lowest available address, and setting this flag enables this mode. Note that in the sequential mode, clients which allow a lease to expire are much more likely to move IP address; for this reason it should not be generally used.

If you see what appear random assignments they are not.

Edited: Added wikipedia link for further clarity:

wikipedia dnsmasq

As I don't use dnsmasq these days that doesn't apply to or interest me.

As doing the static mapping fixes the issue (if present) and allowing the DHCP server to assign them (regardless of how they are derived) doesn't, well I guess I'm missing how any of that matters to a Sonos owner that is seeing, or possibly seeing, the addressing issue and wants it to work, not a lesson on network utilities operation.

What router are you currently using?

It will apply to most consumer routers, and you also said you saw “random IP assignments”, that is because you were using router(s) that use dnsmaq (even though you thought it didn't apply).

My point is the vast majority of Sonos users are using consumer grade (probably ISP supplied) routers. Those routers are built using dnsmasq. hidden from the user with a fancy Web GUI or App to manage the router.

Of course the consumers don’t care and have no interest its using dnsmasq, they wont even know what an IP address is, they probably have never logged onto the router,  why should they.

I agree there is no harm, except for HT systems and HT bonded devices, but I am struggling to understand why it is still often recommended.

I’m just trying to debunk this ‘myth’ on forum I keep seeing they should reserve DHCP IP address if they have issues with Sonos system. I have yet to see a valid explanation why this resolves issues with Sonos.

In the past I’ve had issues with duplicate addresses. They don’t always strike and most often appeared after a SONOS update. Duplicates can be exacerbating because they will often “heal” after the address is renewed.

Current routers are Netgate, 3100 and 1100.

 My routers do not use dnsmasq, that is very clear from a simple look at the documentation or even looking at the user interface. Of the DHCP options abailable I currently am using ISC DHCP.

I see no issues from the assigned IP addresses with any of my four HT setups. What are you seeing as a problem?

Feel free to debunk away, but you are facing a difficult problem here. My system has major issues at reboot time without them set and no issues with them set. How you can debunk that will be interesting to see.

I am not that familiar with pfSense/Netgate, but possibly issue with specific configuration in this setup. Maybe pfBlocker as it tries to update DNS and times out, setting DHCP reservation will bypass this DNS registration. During an update, all your Sonos devices are rebooting at same time, and will require DNS to function, this issue is compounded.

https://www.reddit.com/r/pfBlockerNG/comments/bs9zn6/psa_using_pfsense_with_pfblockerng_and_dhcp/

Apologies to everyone, this has gone a bit off topic, but its interesting (for me, maybe others) to understand why the DHCP reservation is so often recommended by some users of forum.

Lets say a user reserves the IP address of a Sub or speaker before its bonded, it will be reserved against the MAC address of the speaker. When it is bonded it is proxied through the soundbar, the same IP will use the MAC address of the soundbar, and will probably fail.

https://docs.netgate.com/pfsense/en/latest/troubleshooting/logs-arp-moved.html

Sone firewalls/routers may also detect ARP spoofing, that is why I would refrain from DHCP reservation of HT speakers.

Can you point to one thread here where the bonding of a Sub or surrounds failed due to having a reserved IP address before being bonded?

I don't really have time to trawl through  the ‘un-searchable’ Sonos Community. Here is example on reddit:

https://www.reddit.com/r/sonos/comments/9on8bg/sonos_playbar_is_fighting_my_dhcp_server/

Edit: what about this one:

https://en.community.sonos.com/speakers-229128/one-room-acting-wierd-6881200#:~:text=Been%20using%20Sonos%20for%20about%207%20yrs%20now.%20Currently%20use%20it%20in%204%20rooms%20in%20the%20house.%20Have%20a%20boost%20and%20all%20devices%20are%20static%20IP%20via%20binding.

So one example from 7yrs ago. Doesn’t appear to be a major issue that you’re implying it to be.

Maybe this thread could be another example you asked for, as it appears OP has reserved IP addresses?

I have never said its a major issue, as the vast majority of Sonos users do not reserve IPs in DHCP, and they have fully functioning systems. If it was a major issue, Sonos would recommend it.

Some users have very unique/specific home network setups with ‘boutique’ type firewalls in a home setup, and may have a work around using reservations, but it does not apply to the majority of Sonos users.

All I’m asking is an open mind, just because something has been recommended in past by a few users with very specific network setups, does not mean it should be the default recommendation today.

I asked specifically around your comment that giving a reserved IP address prior to bonding with a soundbar would “probably fail”.

The OP has not mentioned that as an issue that they are experiencing, so not sure how you are drawing that conclusion.

I have reconfigured rooms with reserved IP addresses and moved speakers/sub from being a stereo pair/sub to a new soundbar numerous times without issue, so I queried your belief it would probably fail as it has never in my own experience.

I wouldn’t say reserving IP addresses is given as a default recommendation. It’s a suggestion given by some users. If there was no benefit to reserving IP addresses why would routers give the option in the first place?

Also can we stop using the term Static IP. Sonos does not implement Static IPs. Static IPs are not the same as reserved IP addresses.

OK, sorry, maybe I should have used the term ‘may fail’ Lets look at another example:

OP says Sonos is working fine no issues, but concerned that they are seeing duplicate IP address in their router web page, this is just the way the router GUI presents the HT devices, its not an issue.

Its suggested that they reserve IP addresses.

Yes, I should have used the correct term IP reservation, post updated, sorry. static is often incorrectly used, even in the BT router page above, but we know what its referring to.

@craigski - We appear to be debating different things. That thread again is not related to your comment I was questioning, so on that basis I will leave this conversation.

Hard to blame my issues on pfBlocker as it isn't installed on my router.

I see no issues with my HT setups with the reserved IP addresses and surrounds or Subs, they get the assigned IP and use it, they don't ask for or get other IPs.

Back to the bottom line here, some Sonos setups are unstable without reserved IP addresses.

Reserved IP addresses are easy to assign. 

Once assigned it is easy to observe the difference in stability.

If the addresses cause problems (I've never seen or heard any mentioned by folks I've recommended them to) they are easy to remove.

All the esoteric details don't really matter to someone whoo just wants their Sonos gear to work.

Until someone has a suggestion that works better in practice, not theory I'll keep suggesting it when appropriate. 

Totally hear you, dealing with that kind of daily frustration just to play music is exhausting. Mixing older and newer Sonos gear definitely seems to cause more issues than they admit. It’d be a lot easier if they were just upfront about what really works well together.

I would argue some network setups are unstable without reserved IP address.

I see the reservation is a recuring theme, so will probably go on and on, from last year:

Its interesting that you said you didn't have issues with your old router:

With my old all-in-one router I was not seeing issues, updated to a much better router and dedicated WiFi APs and was seeing issues until I set them.

I concur with you, you need to have IP reservations on your much better router configuration, due to the way its configured to handle DHCP. I still disagree that IP reservations are required today, unless there is some underlying issue with the network.

I’m flogging a dead horse, so we will have to agree to disagree.

Just popping back in to say how fascinating I’ve found this thread.  Thank you everyone for your time and contributions.

I’m not an IP or electro-magnetic radiation propagation expert so a lot of this has gone over my head.

I have read Sono’s “how to deal with wireless interference” guidance and if I attempted to keep all my Sonos players between 0.5 and 1 meters away from all other wi-fi enabled devices I’d have to put them in the garden.  The rule on consumer electronics in 2025 appears to be “if it can be wi-fi enabled, wi-fi-enable it”.  And everyone in my house carries around mobile phones, tablets, laptops and smart watches.  I’m not going to put hazard tape around every Sonos player or start shouting at my partner when they get too close.

There’s something not right in my Sonos installation.  Your comments have proved to me that there are smoothly functioning systems out there and mine’s not one of them.  At the moment the only help I get from the Sonos software is “that didn’t work, try again later”.  Numerous calls to Sonos technical support have offered little more.

If the wi-fi environment in my house is the thing standing between me and a functioning Sonos installation I’d really appreciate the option of a bit more information from the software.  Something along the lines of:

“Sonos player:  Bedroom is experiencing a lot of interference, try moving it”

Or

"Cannot add room Lounge to group:  The group is already struggling to stay in sync”

would go a LONG way to helping me out….

Am I asking for something that the software will never be able to provide?

Apiologies for derailing. Did you try my suggestion before the derailment, ie turn off the oldest speakers and/or speakers in less used rooms for a day or so, and see how it performs?

Sonos support should be able to advise on that, they can see that info from diagnostics.

Also, what WiFi network devices are you using? Many have a management interface that will show the health of your wireless network down to device level.

Do you use iPhone? Have you tried disabling WiFi Assist:

https://support.apple.com/en-gb/102228

Thanks ​@craigski 

No problem about the derailment - I think it’s a great illustration of how any attempt to engage with Sonos performance goes down detailed technical rabbit holes really quickly.  Almost my point in a nutshell.

Yes, I have tried turning off the oldest products, power cycling everything and then giving it a day or two.  No noticeable or consistent improvement I’m afraid.  (And that’s part of the problem.  All I’ve got to go on is my perception - some actual guidance from the software in measurable terms would really help).

Yes, I agree, Sonos support should be able to see the state of my network from diagnostics.  But my recent experience has been that there’s such a built-in delay between experiencing something with Sonos, calling support, getting through etc. That it becomes an academic exercise.  I would probably have to take entire days off to wait for a specific error to happen (my system is NOT consistent) and then immediately call technical support…  

I use four TP-Link Deco XE75s as access points with a TP-Link Archer router doing the IP assignment and connecting to the outside world via a 1Gb fibre connection. The Deco software isn’t the most forthcoming...

​@IanJShaw - I think there is a push to make error messages in the app more informative, but I don’t know if we’ll ever get to the stage where every issue can be clearly identified with a recommended solution. 

Going back to your original post, newer speakers have better processors, better wireless radios and more memory compared to older speakers. I upgraded from Play:1s to Ones to Era 100s in my kitchen as the Play:1s used to have dropouts long before the new Sonos app was launched. In my experience the Play:1s were more susceptible to wireless interference.

i would definitely experiment with having a smaller system as has been suggested to see if your experience improves, then gradually increase the components testing as you go. Obviously, the ideal scenario is to have all speakers functioning perfectly, but the process may identify an issue with one particular speaker/room which impacts on the overall system. If you still have issues with a smaller system, then adding additional components to the system is just going to exacerbate the underlying issue whatever that may be.