• Date
    MSjx
  • Date
  • Replies 5 replies
  • Subscribers 186 subscribers
  • Views 1880 views
  • Users 0 members are here

2.9.0.77 broadcasting changes?

Hi,

I ran into an abrupt change to my systems with the 2.9 update.  All my older networking gear (Netgear smart managed) utilizing IGMP snooping abruptly is now filtered and stopped from being sent to gateways.

I've run them with all other broadcast filtering off the last 8 years of their use with just snooping on and no issues.  I quickly logged in and shut it off, as not too many other things will time out a switch port and immediately everything worked properly.

In the last week I've had other programmers contact me with the same issue, on different brands of switches and immediately traced it to 2.9 upgrades.

What I'm wondering is what has been changed on 2.9, we all noticed an immediate problem and change.  We have a solution so this isn't something to complain about but rather letting others know and wanting to know more about how things are working under the hood.

Thanks,

Parents

  • I can't see how anything in Eos software could impact the distribution of multicast data at the network level. I've also been running 2.9 on multiple networks with IGMP snooping enabled without any issues.

    All Eos does is transmit sACN to multicast addresses 239.255.0.1>239.255.250.255 (as per the standard). It is entirely down to the network infrastructure where these packets get delivered. If you have IGMP snooping enabled, the switches will deliver the packets to only those interfaces they have subscribed to receive that address, if it is disabled, it will be delivered to all interfaces (effectively becoming broadcast).

    What is it specifically that you think could possibly have caused this at a transmitter level?

    Cheers

    Dan

  • in reply to dsmurfin

    It is actually possible for the software to impact the multicast. 

    The reason is many switches if they see no IGMP messages decide that IGMP is not available and drop back into a kind of broadcast mode for the multicast traffic.  (ie they behave the same as if you had IGMP snooping switched off)

    Once something sends some IGMP they then go into a proper mode and only pass the packets to the subscriber.  The result is if the EOS system is self subscribing then IGMP appears the switches go into proper multicast mode.

    This effect was observed on previous EOS versions when people fired up the sACN monitor (you'll see the reports on this forum).  So possibly 2.9 effectively has the sACN monitor permanently subscribed internally.

    The implication is that in your original network setup IGMP wasn't actually propagating correctly from the end subscribers but that issue is hidden by the switches dropping back to broadcast mode. (so if that's true what's going on, on the network now ithe IGMP snooping off is the same as what it was actually doing before anyway)

Reply
  • in reply to dsmurfin

    It is actually possible for the software to impact the multicast. 

    The reason is many switches if they see no IGMP messages decide that IGMP is not available and drop back into a kind of broadcast mode for the multicast traffic.  (ie they behave the same as if you had IGMP snooping switched off)

    Once something sends some IGMP they then go into a proper mode and only pass the packets to the subscriber.  The result is if the EOS system is self subscribing then IGMP appears the switches go into proper multicast mode.

    This effect was observed on previous EOS versions when people fired up the sACN monitor (you'll see the reports on this forum).  So possibly 2.9 effectively has the sACN monitor permanently subscribed internally.

    The implication is that in your original network setup IGMP wasn't actually propagating correctly from the end subscribers but that issue is hidden by the switches dropping back to broadcast mode. (so if that's true what's going on, on the network now ithe IGMP snooping off is the same as what it was actually doing before anyway)

Children
  • in reply to Mike A

    Yes, ok that's fair enough, but the fault lies with the switches and network setup not Eos. If Eos decides to send IGMP requests that is legitimate network traffic, the same would occur if any other devices joined the network and sent IGMP messages.

    So while technically Eos software changes could impact forwarding, the fault does not lie with Eos but with the switches.

  • in reply to dsmurfin

    Yes totally agree EOS is not behaving wrong, its misconfiguration/limitations of the network switches etc being used. And as you say other IGMP subscribers on the network could trigger the same fault condition in the network infrastructure.  The challenge is that people will say it worked fine until it was updated but that's only because they didn't know it wasn't really working properly originally.

  • in reply to Mike A

    I agree with you Mike.  The question wasn't about blaming ETC for changes, the question was if there were changes.  Those switches should have never had IGMP snooping on to create this problem.  But they did and I was just wondering what had changed, because that was the only thing that changed on my side.

    I recently had also been solving other QoS issues on MA dealing with priority settings.  Just wondering, everything works fine.

Related

www.etcconnect.com