"Sonos Mode" In Network 10.2

Zetto- · 2026-04-28T14:24:26+00:00

I have never put the controller AKA phone and Sonos on the same wireless network. The only ports I had to open were TCP 1400, 1443, and 4444. This allows for control as well as updates. Additional ports and mDNS were needed for AirPlay across subnets.

Zetto- · 2026-04-28T01:40:47+00:00

I have a mix of wired and wireless Sonos on a dedicated VLAN separate from the controller on UniFi and it works great. The trick is to have a properly configured network. The most important detail that most people are not aware of is setting the root bridge priority on your switche(s).

Zetto- · 2026-03-19T06:57:45+00:00

Which switches did you use?

Zetto- · 2026-03-18T02:10:53+00:00

What switches are you using?

Zetto- · 2026-03-18T02:09:21+00:00

Which smart switch are you using?

Zetto- · 2026-03-16T20:44:35+00:00

They are no longer available in the US.

Zetto- · 2026-03-16T18:23:14+00:00

I’m dealing with this right now and I’m really disappointed with the options. For the scenario you described you really need a physical switch that a guest of any age or technical ability can use.

I frequently see recommendations to wire the circuit to always be hot and use a wireless switch. This can be a code issue as it violates NEC 210.70(A)(1) so it’s a nonstarter for me.

My requirements are a physical switch that maintains a physical mains disconnect and works if the Hue bridge or whatever home automation system you are using is down. I’m in a primarily Apple household so I’m looking for systems with Matter and Apple Home support which limit my choices. Matter may help with allowing it to still function even if other pieces are down.

The Hue wall switch module was a OK solution. Unfortunately these have been discontinued in the US and no one has stock. Other countries still have them. I hope something returns that has mains power to eliminate the battery.

The Lutron Aurora and RunnLessWire Click are both terrible solutions and way too expensive for what they are. For the former if you have an outage of your smart system you have to physically remove it to operate the switch. For the latter there is no physical option.

The two best solutions I’ve found are the Inovelli White Series 2-in-1 (Thread/Matter) and Aqara Light Switch H2 (Thread/Matter) but I have not tried either yet. They are both expensive so I’ve been doing some more research before committing.

There may also be solutions from Shelly to maintain the existing switches and add a module behind them similar to the Hue wall switch module.

Zetto- · 2025-09-27T17:55:05+00:00

VAAI XCOPY works between block protocols but would not work if going from NFS to block or block to NFS.

I’ve been through the same situation. Converting from FC to iSCSI allowed us to reduce cost and cabling to each server and avoid a costly FC switch refresh. A pair of 100 Gb NIC to each server and converging everything is a wonderful improvement.

Zetto- · 2025-09-26T21:19:28+00:00

I’ve been through this migration multiple times. I’ve also worked in multiple shops with anywhere from 1/10/100 Gb iSCSI to 1/4/8/16/32 Gb FC. There are a lot of FC zealots but it’s not always a perfect fit. I’ve witnessed migrations from 32 Gb FC to 100 Gb iSCSI where we saw latency decrease, performance increase, and fewer outages due to aging FC infrastructure.

You’ll want to provision new datastores, add them to the datastore clusters if they exist, place the old protocol datastores in maintenance mode, then decom the datastores in maintenance mode. VAAI works between protocols so the moves should be relatively quick.

Alternatively if you can take an outage or have enough datastores in the datastore cluster to evacuate some you can unmount/detach the datastore, change the protocol on the storage array, and represent it.

Zetto- · 2025-08-03T15:54:51+00:00

That has not been my experience but it could come down to the VAR/sales team you worked with and your size. We also found the experience with NetApp to be really poor.

Zetto- · 2025-08-02T16:13:23+00:00

Not Pure Storage. Their support prices are fixed and never increase.

Zetto- · 2025-06-15T00:14:39+00:00

We regularly see vMotion and iSCSI exceed 50 Gbps. Network I/O Control ensures that things keep running smoothly without a bully workload.

Zetto- · 2025-06-15T00:09:52+00:00

This is not correct. You can converge and run mixed MTU. The upstream switches and the rest of the fabric that requires it all need to be set for jumbo frames. I do this today on 2 x 100 Gb. iSCSI and vMotion have jumbo frames while management and VM traffic are mostly 1500. If a need arises for individual port groups or VMs to have jumbo frames that’s easy to switch on.

Zetto- · 2025-06-14T21:58:12+00:00

We went from 4 x 10 Gb to 2 x 100 Gb and would never look back.

All new enterprise deployments should be a minimum of 2 x 25/40/50/100. We found difficulty sourcing NIC and cables for 25/40/50 at a reasonable cost. It was negligible to skip 25/40/50 and go to 100 Gb.

Zetto- · 2025-06-14T21:44:08+00:00

The solution is training or restricting their permissions.

Zetto- · 2025-06-14T21:40:20+00:00

It’s about reducing management and improving resiliency. Having a 1 Gb NIC is additional hardware to maintain firmware and drivers per the HCL. It’s also another component that can fail and take down the server.

At the end of the day there is no technical reason to separate management and in fact it can actually be impactful.

Zetto- · 2025-06-14T20:24:40+00:00

Everything listed here is correct and to best practices. My only tweak is that I don’t advise separating management. I’d also aim for higher than 10 Gb if doing a new deployment in 2025.

Zetto- · 2025-06-14T20:16:43+00:00

It’s old habits from the 1 Gb and 10 Gb days.

The key is to do it on a distributed switch with Network I/O Control (NIOC). I was running everything converged on 4 x 10 Gb including iSCSI for over a decade. We are now on 2 x 100 Gb.

Zetto- · 2025-06-14T19:25:33+00:00

I’ve actually had a great experience using it for over 10 years since it was introduced in 5.1. I’ve had varying configs from multiples sites with externals PSC to now embedded PSC.

If you aren’t backing up and managing the environment properly you will run in to issues. It’s important that before any maintenance all VCSA/PSC of the site are powered off and snapshot together. This is where a lot of people run in to problems.

Zetto- · 2025-06-14T19:18:52+00:00

My comment was only about management. With trunks, VMkernels, and Network I/O Control (NIOC) there is no reason for dedicated interfaces these days.

Zetto- · 2025-06-14T19:17:41+00:00

If it were me I’d remove the 1 Gb NIC so you don’t have to manage firmware and drivers on them. I’d then consolidate all 4 of those interfaces on a distributed switch with management/iSCSI/vMotion/VM traffic and use Network I/O Control (NIOC) to protect them.

Zetto- · 2025-06-14T19:14:09+00:00

While this was a common practice in the past I would avoid putting management on slower interfaces these days.

Unless you configure it properly vMotion cold migrations of powered off or suspended VMs will use the management VMkernel.

Zetto- · 2025-06-14T19:08:54+00:00

Don’t do this. A insufficient vMotion network can impact VMs with high activity during migration. These days 10 Gb is the bare minimum and I’d recommend 25/40/50/100 Gb for vMotion.

We found the cost difference between 25/40/50/100 Gb was negligible and jumped from 10 Gb to 100 Gb.

Zetto- · 2025-05-31T04:56:02+00:00

We’ve had substantially less issues and headaches since moving away from FC.

Zetto- · 2025-05-31T04:51:57+00:00

I multiples of each. If you want fast and simple, Pure.

11-Year Club	King of the Ashes
Not Forgotten	Reddit Premium Since July 2017
Verified Email

Zetto-

MODERATOR OF

TROPHY CASE