IGMP Snooping Not Working [WS-6-MINI]

[uberdome]

I ran v1.5.2rc5 until Saturday (5 days continuous) without issue. I then flashed to v1.5.2rc6 and have been running that test for 2 days so far without issue. It seems resolved, and I will update if I experience any further issues.

[uberdome]

I have continued to have issues, actually, but they are with much longer run times. I'm having a challenge getting the data for troubleshooting because I'm concerned about the size of the log. I will continue to test, and hopefully get some decent troubleshooting data over to you soon.

[uberdome]

I can't reproduce this. I'm using VLC as streaming server and client, seems solid.

Can you try this? Note that this is only safe to do via the serial console. This will create a debug log that I can examine.
Commands from the CLI:

Code: Select all

 
cmd
/etc/init.d/vtss_appl stop
vtss_appl -l -m -s -a -i -v 4 > /tmp/debug.log


Let it run for about 30 seconds to start up, then start your stream and let it run until the stream drops and restarts, then hit CTRL-C then run this command

Code: Select all

 
/etc/init.d/vtss_appl start


Then you need to get the log file off the switch. If your terminal program supports zmodem you can use "sz /tmp/debug.log". If you have network access to the switch you can use scp or tftp. Or if your terminal has a large enough scrollback buffer you can use "cat /tmp/debug.log" and then select all the text and copy/paste it to a file.

And then please email the log to me (eric@netonix.com)

Also the contents of /var/log/messages would be helpful too.

Eric,

I have continued to have issues. However, when I attempt the above test like before, I lose all connectivity to the switch and it needs to be rebooted.

For the past few firmware versions, there has continued to be a longer term issue where after running multicast for a while it breaks multicast entirely (it stops streaming, and broadcasts for some period of time).

Do you have another troubleshooting step I can take to get you the necessary information?

Thank you, Chris

[uberdome]

I was losing connectivity if it took me too long to restart vtss_appl. Instead, I ran it like this and the debug started without losing connectivity:

Code: Select all

cmd
/etc/init.d/vtss_appl stop && vtss_appl -l -m -s -a -i -v 4 > /tmp/debug.log

I'll see if I can get you the debug files soon. I may have to wait for another failure a little while, though.

[uberdome]

So far, each time snooping fails, I lose connectivity to the switch entirely.

Please advise. I would like to help resolve this IGMP snooping failure.

[Stephen]

Can you access the switch locally?

If you're running the vtss_appl process as specified above, you should still be able to access the debug.log from the rs232 port and retrieve it. Then restart the switch. Or possibly just restart the vtss process to get connectivity again.

[uberdome]

Can you access the switch locally?

If you're running the vtss_appl process as specified above, you should still be able to access the debug.log from the rs232 port and retrieve it. Then restart the switch. Or possibly just restart the vtss process to get connectivity again.

This is with me connected locally. I cannot access it when plugged directly into a port.

This is being tested on a WS-6-MINI which does not have an RS232 port available.
Restarting the switch gains me access and fixes IGMP snooping... but then I can't get you the details of the test revealing why the failure happened.

Is there a safe place to put the debug file that will survive a reboot?

[Stephen]

Try placing it in the /www directory.

[uberdome]

Will do. Next time I see the error I will try to get that log file after reboot.

[uberdome]

Try placing it in the /www directory.

Stephen,

I have finally taken some more time to review these issues, on 1.5.3. I still get failed IGMP snooping after extended periods of time. I have successfully collected the debug files as requested into the www directory, and they survive a reboot. The problem is they end up filling the entire available space, and then I cannot retrieve them. Any further suggestions on how to collect the debug file (perhaps storing it off the router) to finish tracking down the issue?

Of course, I finished about the time 1.5.4/1.5.5 was released, so I just updated to 1.5.5rc1 and will see what happens there.

Thank you, Chris