Network Loops

I have 2 main repeaters in my system. It seems that they intermittently cause so much network traffic that they some cause what appears to be an intermittent network look. Has anyone else seen this? The main repeaters lights with cycle in green every few days, which I though was a new feature in 11.0 that shows us whether there is a prior network loop. Disconnecting from the network gets rid of it and then it comes back after a few days. I have an HDMI matrix on my system (Atlona) that freezes each time this happens and it stopped freezing when I took it off the network but this green light cycling keeps happening every few days.

Could this be a multicast issue and if so what is the correct way to disable multicast? When I chose the option for using the repeater address in inclusive it seems to give an option to pick either of the static address of the 2 repeaters. Should I set it so that the repeater uses the address of each individual repeater or of the main repeater that communicates with my home automation system which is Control4? So if the addresses are 192.168.1.3 and 192.168.1.4, should they both be set to 192.168.1.3 (which is the address that Control4 integrates with) or set each to communicate with their individual addresses?

Never, ever set more than one IP device on the same IP address. Integration only has to speak to one of the repeaters .any messages for devices on the other repeater are automatically exchanged from the repeater receiving the integration commands to the one that sends the RF messages to the devices.

I wasn't suggesting setting both repeaters on the same address. When I try to disable multicast in the inclusive software it asks if I want to st communication to repeater via multicast or by the repeater IP address. If I pick the IP address of the primary main repeater, it's automatically assigning the same address for communication for the second main repeater. The network IP addresses are still separate.

Quote:

---

Originally Posted by texas doc

I wasn't suggesting setting both repeaters on the same address. When I try to disable multicast in the inclusive software it asks if I want to st communication to repeater via multicast or by the repeater IP address. If I pick the IP address of the primary main repeater, it's automatically assigning the same address for communication for the second main repeater. The network IP addresses are still separate.

---

Hmmm, just checked mine. Both are set to use a static IP address (DHCP disabled). Both have the 'Restrict communications' box checked. Both have "Use Repeater's Address" and the IP of the 1st repeater.

Fwiw, I do have all my automation gear on it's own network switch. If for no other reason than to avoid the bulk of it's traffic from being sent to all the other switches in the house. They're all on the same subnet. But separate switches can help isolate some of the traffic. Multicast, however, can make a mess of this and I generally try to avoid using it whenever possible. It's not like infrastructure stuff like this needs all this dynamic nonsense anyway. Sometimes trying to be 'user friendly' often ends up being a troubleshooting pain in the butt.

What automation system are you using? I'm using Control4. I'll try switching to restricting by IP adress also.

Just FYI for others who may have had a similar problem - Changing the settings to restrict communications by IP address (disabling multicast) has so far fixed the problems I was having with my network.

Something is still "not right". I upgraded to 11.5.1 the other day and had a fair bit of trouble trying to get things working properly. Eventually had to power cycle both main repeaters and quit/restart the Inclusive program. Even then it still took too many tries to get a successful transfer.

Somewhere along the line the way the code in program tries to communicate with the repeaters has gotten overly complicated. All this trying to work around things, trying to be 'dynamic' is getting in the way of JUST WORKING PROPERLY.

Stop.

You're either selling something that professionals need to understand how to configure properly, or you're making a DIY solution that intends to be psychic enough to work around end-user network shenanigans. As it stands now the program is failing to address either market effectively.