MikroTik

Hi, from version 6.x IGMP proxy forwarding stops working after a while, 1, 5, 10 days ....
Although IGMP messages are regularly passing and stream is coming to upstream interface, there's no stream on downstream. Please resolve this bug as soon as possible. So far we have used version 5.14 and we didn't have this problem, we had other problems that you promising to solve for years. However, given that rb2011 with version 5.14 stops so often and goes to switch mode, we are forced to use 6.x, but now there is a new bug with IGMP.

Normis, Janisk, can you please give me an answer related with this bug? I'm stil waiting ticket response too.

????

Shame on everyone from Mikrotik stuff! You see your users as fools. Normal people would say "we don't know how to fix that" and you are only ignoring us.

gamad, fuj, fuj ,fuj...

first, this is a user forum, if you have an issue write to support. It is not guaranteed that we will answer here.

however - how many clients are connecting, to what groups they are connecting, as I see there is join request and soon afterwards comes in the leave message from the same address.

Hi, the STB is configured to seek the stream until it receives. Given that mikrotik is not forwarding the stream, STB do join and leav constantly (stop/play on stb). There are two users on this RB, and there's several hundred of RBs 2011 and every one of them is facing this same bug, starting from version 6.x.

Version 5.14 does not have this bug, but about 40% RouterBOARD RB 2011 (about 250 pcs) in my network sometime stop working and go to switch mode. This bug was fixed in version 6.3, but IGMP is broken.
j
As far as previous versions, they have 2-3 IGMP bugs for which I have written in the past two years.

Janisk, I know this is not a support forum. But I opened the ticket 8 days ago and still have not received a reply.

if you can, try to increase the timeout value when STB sends leave. There is no difference in code between versions you are mentioning. Only some network latency could be added. Also, if possible, do one STB work.

Hi,
STB send leave only if stream stops or if our user switch to some other channel.
Here's the thing that multicast stream stops for all users on RB at the same time. On some RBs we have up to 9 users that are active watchers of TV channels and when this bug start stream stops to all of them. I must mention that fast leave is not reason for that because I'm blocking fast leave messages that STB is sending to RB:
Configuration of IGMP proxy as:
All that works great on v 5.14.

I know that querry interval is very low but this is the only solution that allows me to bypass bug with leave messages that is present in Mikrotik. Considering that last two reported bugs are still unsolved I didn't want to be annoying anymore also reporting this one (bug with fast leave and IGMP proxy).

But, since you are so persistant here's summary of that bug too:
Sometimes when RB receive fast leave message from user for some TV channel it happend that for all users on that RB that same channel stops. For that very reason we inplemented on STB that if, for some reason, stream stops STB will in one second try to start that stream again and that's goes on until stream starts.
Example: I have stopped watching group 239.11.0.1 (switch from that channel to another), STB sends fast leave message, Mikrotik receive that message and leaves that group on all downstream interfaces where that group is watched, and for real it should stop stream only on downstream interface of that user which has left the group and has sent fast leave message. I must remark that this bug happend at least once of 30 - 50 leaving tries. So, sometimes is happening that channels has stopped to user and after few seconds starts again only because their neighbour in the building where they live has stopped with watching of that channel.
I must repeat, this is not the subject of this theme. Theme is v 6.x and that IGMP stops forwarding to all users on RB and it wont start until I reboot the RB.

I have the same really annoying problem with 6.x, IGMP Proxy stops working randomly, it could be hours or weeks.
Is there a way to restart the IGMP Proxy without rebooting?

actually ropeba this bug can be repeated like this:

you have 2 multicast channels a and b, and 2 clients A and B. in situation when fast leave is enabled following has to happen:

client A joins channel a, client B joins channel B, client A leaves channel a and joins channel b. Then Client B leaves channel both clients stop receiving currently joined channel b.

If your network can handle multicast without fast-leave you can de-select that option but joins will happen much slower, and weaker devices can become overwhelmed with packets from streams users have no interest.

We all are waiting for this bug to be resolved.

So, if possible you can use PIM configuration instead of IGMP-proxy, but that in turn has its own bag of tricks.

Yes, Janisk, exactly.
I have a situation that I have on one RouterBoard 9 users who watch TV .

example:
7 users watching RTL channel . Of those 7 users who watch RTL channel, one leaves the group RTL (switch to another channel) , then STB sends leave message to RouterBOARD and RouterBoard turns off the stream also to the other 6 users viewing RTL channel, and these 6 users have to re-invite the stream. That is not the case every time someone leaves the channel, but it happens "sometimes" after dozens of transferring/leaving the group, the average 10 breaks per day.

As for the fast leave, you're a little wrong. Fast leave option on RouterBOARD is for purpose of RouterBoard to CORE network (upstream interface) sends leave message (nothing to do with incoming leave messages from the downstream interface), and this bug that I mention happens when CPE equipment (STB, router or PC) Send leave message to RouterBoard where 9 users is connected. It can only be solved if I turn off fast leave on STB, CPE router or PC, and I can't do that so I have blocked on RouterBOARD incoming leave messages on the Ethernet ports where the users are connected. For this reason I had to cut query interval to 7 seconds so that when one user is switching between channels he can't pull 200-300 mbps of stream, because in 2:05 minutes, which is the default interval, the user can switch between 50-60 channels ...

However, fixing this bug in version 6.x is not an option as long as the newly created bug in version 6.x ( Bug in this topic ), where RouterBoard stops working forwarding stream. IGMP messages are passing and the stream comes to the router (on the upstrem interface).

On a couple occasions I mentioned to you that PIM is not an option for me. Most of PON equipment doesn't have PIM Snooping implemented, so that the only option is IGMP.

Given that there's a lot wireless providers in our region which are introducing FTTB service and some of them are planning to use mikrotik equipment in a complete network like I do (not including PON segment), now it would be right time to solve that bug; when on downstream interfaces goes several streams that users are not watching, a couple of times I've written for this bug (from 2011 onwards) and I think I've become boring and dull with that, but I will not give up until you fix it . That goes in favor for you and me and everyone else who use mikrotik equipment. B.R.

This bug is not new for ros 6.x, tried 5.25 couple of days ago and this morning igmp proxy was not forwarding half the channels. Only reboot helps, unfortunately pim is not a possibility for me.

Possible, I use version 5.14 on all routers, so it's possible that the bug exists on 5.25 because I have not tried on it. I'm upgrade from 5.14 to 6.x because more than half of my rb2011 with the version 5.14 going to switch mode after couple days of working and I must to switch off/on power.

it should be present also on 5.14

Janisk, is there any hope that it will be solved?

it should be present also on 5.14

I thought on bug where mikrotik forwarding stops working. This bug appeared in newer versions, hi's not present in 5.14 it's not there and Iom sure at that 10000000000000000000%. I have nearly 1000 active RouterBoard 2011 with a 5.14 version, I guess I have noticed over the last two years that there is this bug in this version. Other bugs that I reported are there at 5.14 too, but on 6.x happens that IGMP proxy totally stop work forwarding, IGMP messages are passing and stream comes to the upstream interface, but it's not there at downstream interfaces. That bug in the 6.x version sometime appear twice a day and sometimes twice a month.

anyway, we are working on IGMP-proxy issues.

I hope that you'll manage to solve IGMP proxy problems in some of the future v6.x versions.

hi, do you have any information when will be the igmp proxy fully functional in 6.x versions. Offten it just stops working and the routerboard requires a system reboot to start working again.

everyone who has an interest can check 6.8rc1

note - use quick-leave only if there is one potential subscriber behind the router. In other cases standard leave should be used.

where I can download 6.8rc1?

where I can download 6.8rc1?

Same problem with rb2011, it's was not solved in 6.9

I can confirm that too. ROS 6.9 IGMP proxy stops forwarding. CRS.

I can confirm that too. ROS 6.9 IGMP proxy stops forwarding. CRS.

What problem do you have? do not work for IPTV?
do you have multicast enabled?

I can confirm that too. ROS 6.9 IGMP proxy stops forwarding. CRS.

What problem do you have? do not work for IPTV?
do you have multicast enabled?

Carefully read this post from the beginning and you'll understand what's not working!

Hello,

Dear Normis and Janisk please kick your programmers ass asap to implement a working igmp snooping in MikroTik OS! I think a lot of people will be thankful for that advantage, also you will see it in your sales volume!

Kind Regards

Aleksander

I noticed today that ether1 is down/up because of bad connector. Ether1 is also a upstream interface in IGMP proxy and after this he's stop to work a forwarding. It is obvious that something freezes in IGMP proxy after the upstream interface goes down and then up.