v1.5.0rc1 and rc2 Bug reports and Comments - CLOSED

[mgthump]

is multicast IGMP working within a vlan? I know its marked as developing, but I'm out of time, unfortunately. I need to start changing out switches this week if these features are still pending.

If you suspect they are ready, I'll try it on a couple switches. in 1.4.8 if I turn on igmp snooping our streams die in vlans. they carry as expected in Juniper cisco and netgear switches.... don't hang me for mentioning Netgear with Netonix Juniper and Cisco lol

Nothing has changed in regards to IGMP since 1.4.8 and I have no confirmed reports of any issues with it.

unfortunately for us, IGMP enabled breaks our multicast stream within a VLAN. we are using rodeo networks for a provider using the crossfire box to get started.

we are able to use IGMP with the above mention brands (juniper is used in our core dilvery) tested a cisco and a netgear switch just to test on other platforms and it seems to work as expected. we unfortunately, have to use a vlan to deliver the multicast, no other option at this point for it.

[IntL-Daniel]

What I can tell you is Loop Protection was fixed in v1.5.0rc1 for SFP ports, it was broken and not working.
Not everyone can use Loop Protection with their network configuration and the equipment they use especially large flat networks.
I would suggest you use STP instead of Loop Protection.
If your positive this is a FALSE Loop detection then DIsable Loop Protection. If it is a False Loop Protection report then nothing bad will happen.

So today I had to disable RSTP at all. About 24 hours later (without any RSTP issue) one Netonix switch (WS-10-250-AC) started to repeat RSTP messages discarding / learning / forwarding on one port. All clients behind this port in switch started to complain about repeated 15s timeouts. Then I have found this thread https://forum.netonix.com/viewtopic.php?f=6&t=2018&start=30 . There is not a result how it was solved. But maybe I have some important information to this topic...

1/ Device in this problematic port is Ubiquiti PowerBeam M5 as one of our P2P link to other location - other end PowerBeam M5 again is connected to Ubiquiti Edgeswitch 8XP (previously called ToughSwitch)
2/ There are another two P2P links to other locations in the same Netonix switch (other end is connected directly to client's router, no Netonix or other RSTP switch)
3/ And one P2P link as "uplink" and identified as "root" in RSTP tab - other end is connected to another Netonix WS-10-250-AC.
4/ The state of discarding / learning / forwarding started EXACTLY at the time when I changed configuration of that P2P link connected to that port (I switch role of P2P link from STA-AP to AP-STA).

I think that the problem would not be the fact, that I had changed the config of that link, but the fact that during this change the unit reboot itself and generated port down / up state. Since this time loop of RSTP discarding / learning / forwarding started. I had no chance to test more (reboot that PowerBeam again, reboot other unit connected to the switch, reboot the switch itself...), I had just quickly disabled RSTP which solved the problem at all. It could be also related with the fact that on other side is EdgeSwitch 8XP (ToughSwitch). I was on fw 1.4.8 in Netonix and 1.4.1 in EdgeSwitch 8XP.

Any advice / explanation?

[sirhc]

What I can tell you is Loop Protection was fixed in v1.5.0rc1 for SFP ports, it was broken and not working.
Not everyone can use Loop Protection with their network configuration and the equipment they use especially large flat networks.
I would suggest you use STP instead of Loop Protection.
If your positive this is a FALSE Loop detection then DIsable Loop Protection. If it is a False Loop Protection report then nothing bad will happen.

So today I had to disable RSTP at all. About 24 hours later (without any RSTP issue) one Netonix switch (WS-10-250-AC) started to repeat RSTP messages discarding / learning / forwarding on one port. All clients behind this port in switch started to complain about repeated 15s timeouts. Then I have found this thread https://forum.netonix.com/viewtopic.php?f=6&t=2018&start=30 . There is not a result how it was solved. But maybe I have some important information to this topic...

1/ Device in this problematic port is Ubiquiti PowerBeam M5 as one of our P2P link to other location - other end PowerBeam M5 again is connected to Ubiquiti Edgeswitch 8XP (previously called ToughSwitch)
2/ There are another two P2P links to other locations in the same Netonix switch (other end is connected directly to client's router, no Netonix or other RSTP switch)
3/ And one P2P link as "uplink" and identified as "root" in RSTP tab - other end is connected to another Netonix WS-10-250-AC.
4/ The state of discarding / learning / forwarding started EXACTLY at the time when I changed configuration of that P2P link connected to that port (I switch role of P2P link from STA-AP to AP-STA).

I think that the problem would not be the fact, that I had changed the config of that link, but the fact that during this change the unit reboot itself and generated port down / up state. Since this time loop of RSTP discarding / learning / forwarding started. I had no chance to test more (reboot that PowerBeam again, reboot other unit connected to the switch, reboot the switch itself...), I had just quickly disabled RSTP which solved the problem at all. It could be also related with the fact that on other side is EdgeSwitch 8XP (ToughSwitch). I was on fw 1.4.8 in Netonix and 1.4.1 in EdgeSwitch 8XP.

Any advice / explanation?

WHY ARE PEOPLE USING THIS THREAD FOR ALL KINDS OF STUFF NOT RELATED TO v1.5.0rcX
And not even using v1.5.0rcX

[IntL-Daniel]

OK sorry for that, it was reply to your advice about "possible" issue with loop protection in 1.5.0rc2. I thought that it could be useful for you to identify root cause of other posible RSTP issue, the same as posible issue with QOS tab in 1.4.9 and above.

[sirhc]

We pulled v1.5.0rcX as we found it caused other foreseen issues.

What we suggest you do at this time is fix the cabling if need above and continue to run v1.4.9.

We apologize for this issue, we are dedicating all our time on this issues until we find a resolution.

[sirhc]

Update, we are testing v1.5.0rc3 at this time, we think we got it this time.

We are doing more extensive testing this time so we will not be able to publish it rightway.

We still recommend checking for the fixing the I2C cable issue above. You do not need to upgrade to v1.5.0rcX to look for and fix the I2C cable issue.

Please stay tuned for more information.