Everyone says jumbo frames are not worth it.. but if you have a 10gb internal network like i do it makes a big differences.. this is a speedtest from my plex box to my qnap nas.. without jumbo frames i only get 3.5gb/sec on a 10gig connection.. With them i almost get 7. Very usefull for backing up images etc.
I have had no problems with the hubitat but i have isolated it behind a managed switch that lets me disable jumbo packets so none can get through to the hubitat.
Anecdotally that's great. But a serious issue arises when no one has standardized it. There are so many variations of it that having it enabled on multiple devices can cause issues because of the incompatibilities of a particular vendor's implementation. Honestly in pretty much every data center I've been in it's purposely disabled because they want reliability.
That's certainly true for your setup, where Hubitat will never see a jumbo frame. But I think @dennypage was responding to the setup described by @a.mcdear,
Disabling multicast ends up being a problem for a lot of services. This includes Hubitat as it is becoming increasingly dependent upon mDNS.
The best thing would be to update the driver used in the Hubitat to address the crash, but I believe Hubitat is dependent upon the Ethernet chip vendor for this.
I'm probably wrong about this, but in the setup described by @kahn-hubitat, wouldn't multicast packets larger than ~ 1500 bytes be fragmented/reassembled before being seen by Hubitat? (or any other packet for that matter)
i am not sure how to test jumbo multicast packets .. i know how to test regular packets with ping to make sure they dont get through to the hubitat.. ie
He said "will not pass those packets", which to me sounds like a deny acl to me. Acls are generally implemented as src/dst port, src/dst addr and protocol type/flags. He may have the ability to do acls based on packet size, but this is definitely not something an ordinary user's switch would have. Even my Cisco business switches do not support acls on packet size.
Things like the OP suggest to people lacking the necessary networking background that jumbo frames are desirable and safe. They are not.
FWIW, fragmentation (by the switch) and reassembly (by the Hubitat) would require the ability to enable/disable Jumbos by switch port. Jumbos are a switch wide decision. Can't stop the signal Mal.
The thing is Jumbo frames have there uses. As the OP points out with local LAN very high bandwidth applications there is potentially likely a huge benefit, but suggesting everyone should use it is a over simplification.
I can really only think of two situations were Jumbo frames should provide benefit
When using a networked devices for block storage.
Using VMware Genevieve or similar protocols for network overlays.
Having a 9k MTU wont help the general consumer in cases were most of their traffic isn't bandwidth intensive and possibly leaving there network.
In reality once you start talking about going between multiple networks it isnt hard for Jumbo frames to actually cause huge wide spread issues. If devices are aware of Jumbo frames but not supporting it going between network segements that use different MTU's can cause huge network overhead. Unfortunately I know because myself and a co-worker on the network team at my office brought down core network switches for our company some years ago. After nightly outages for a few weeks they determined it was because though my gear doing a backup was using Jumbo frames we were hitting a corp switch that didn't. We were overloading that core switch by making it breakup and then reassemble the packets on both ends.
I am a big advocate of leave jumbo frames off unless you have a known good reason for it. If you do make sure everything attached to that setup supports it and is configured to do so.
Considering what the Hubitat Hub does it has no reason to ever have jumbo frames turned on.