BODET Speakers + Multicasting Setup

[Tefters]

Morning all,

 

Bodet speakers, love them and hate them.

 

Initially we had 4 / 5 bells in school working off their master clock and everything was fine, had a few niggles setting them up but it boiled down to IGMP on our HP edge switches which involved us having to turn on IGMP on the VLAN and forwarding the uplink ports and the ports that the speakers were plugged into.

 

Fast forward 2 years and we start to put in more bells. Now we have issues where some bells work and some dont, unicast packets to them work absolutely fine but the main schedule timing from the master clock is all multicast and this is where things fail even though we have the same IGMP setup as previous bells. One baffling issue is with a bell we have plugged into a switch that has an existing first install bell and the port forward for IGMP to the bell however the first install bell works and the new one doesnt.

 

Anyone out there with Bodet have any similar issues or ideas?

 

Bells are all on latest firmware, test fine, seen fine on the master clock and setup in groups with schedules.

[TechMonkey]

Not sure if it is the same issue but we use a different IP speaker system and had to create an MDNS profile. Commands are:

mdns profile "Speakers"
  vlan VLANS TO INCLUDE
  exit
mdns gateway vlan VLANS TO INCLUDE

 

CAPS are the bits to replace with your VLAN names or numbers.

 

Had mostly success with the speakers, less success with IP phones auto-provisioning.

[Tefters]

Worth a shot!

 

All my kit is same VLAN.

Edited May 13, 2021 by Tefters

[TechMonkey]

Ohh it may not help then, this was for inter-VLAN issues. Though we did also have to turn IGMP and pim-sparse on.

[FragglePete]

Sorry to drag up an old thread, but similar to an issue we have here.

 

I've got 44 x Bodet Tanoys around our site, and am experiencing an issue where some on one particular switch has just stopped working.

 

I have all the devices and the master clock on their own specific VLAN, and the Multicast server address is 239.192.55.1

 

The core switch is a 5406zl doing layer 3 routing, and most of the edge switches are now Unifi devices.

 

My understanding is that a device will subscribe itself onto the multicast address and renew itself at regular intervals.

 

I find that if I change the multicast address on the tanoy itself via the web interface, and then change it back again it will work for a while but then it'll stop again.

 

If I run the command on the core switch.....

 

show ip igmp vlan 52 group 239.192.55.1

 

This gives me a list of the all the ports on the core switch connected to the edge switches where a device has subscribed and connected to that particular 'group' multicast server address.

 

The port connected to a specific edge switch where the devices are not working is NOT showing on the list. If I tweak the multicast address on the tannoy as described above, the port where that switch is shows up on the list but after about 10 minutes, it disappears.

 

I'm not sure what I can do here, as the config is the same for all the other ports, switches, etc for those that work (and being Unifi is all global anyway). Maybe it's a dodgy UniFi switch, maybe it's a dodgy tanony unit unsubscribing.

 

I updated the firmware on that particular UniFi switch, which initially caused it to go offline until I unplugged and plugged back in the SFP modules (why do they this?) but once up and running again the problem remains.

 

So fellow Edugeekers, any thoughts on the above?

 

Pete

[Tefters]

Sounds like you have pretty much the same setup I used to have, ZL core switch with other HP edge switches which I slowly migrated over to Unifi edges and then made the jump and swapped out the ZL for 2x Unifi Aggregations for the core network throughput with 2x Unifi 48's to make up for the lose of RJ modules.

 

I finally brought a Sonicwall NSA and moved all our routing onto it as I wasn't happy with the Unifi router offering and still think it's a bit lacking for mid level business.

 

We have all of our Bodet along with the time clock on their own Vlan and everything works fine, this is full Unifi switching with 3rd party router as described above.

 

Back when we were HP we did find anomalies like this and it drove me mad, never got to the bottom of sporadic bell issues then another project came up which forced me to replace all the switching for 10gb back bone and since ripping out all the old HP never had any issues.

 

Not much help to you now I know but my advice would be to look at getting rid of the ZL and replacing it with some Aggy's and move your routing to a decent router appliance. The NSA range is very reasonably priced and they have a model for every throughput requirement.

[listen2blacksabbath]

To get ours to work correctly (we have extreme switches) I put them all on their own vlan and disabled IGMP Snooping on that particular vlan

[Aprice]

We're an almost all Aruba house, with one stack of 2960Xs and did have issues originally that seemed to be network related, however it turned out to be that the Micro SD cards in the speakers all needed replacing. No issues with our core which is a 5400R ZL2.

 

Only settings we have on the core specific to this VLAN is. ip pim-sparse ip-addr any exit

 

I suspect it could be something to do with the unifi switches timing out the connection.

Edited January 11, 2024 by Aprice