Hello there, I have 2 questions, which are surely linked: I can't find the answer why my Cisco SF300 Switch, which is the Multicast querier as per its low IP, is sending many Membership Query packets on the network, like almost 10 per second, to the destination 239.255.255.250. All my clients computers are getting those of course. I would understand if it was only one packet every 120 seconds or so, but no, it's 5 to 10 packets every seconds. Any idea why? The second question regards one and only one computer device (10.16.120.15) on the LAN (out of 7 total computers), sends a Membership report group to 239.255.255.250, once or twice every second. Why so many Membership report group packets are beeing sent? I should add to this that no Multicast server is active on the network, no computer client has a VLC or anything opened and nobody is trying to get the multicast traffic. Only we configured Multicast V4 and Snooping on ALL (100%) of our 3 switches for a future possible need for it. The switches have been recently rebooted, the configurations are in place, the firmware of the switch is the lastest. Wireshark is the lastest 2.0.1, and Windows 8.1 updated and activated is on the computers. Any clue would be much appreciated. Y. asked 03 Feb '16, 20:32  thewol edited 03 Feb '16, 20:33 showing 5 of 8 show 3 more comments |
This is a static archive of our old Q&A Site.
Please post any new questions and answers at ask.wireshark.org.
Can you share the capture (filtered down to IGMP only, i.e. first apply a display filter
igmp, then useFile -> Export Specified Packets -> All packets / Displayed)?The capture for the first question is here: http://pandasoftware.free.fr/membershipquery.pcapng A capture for the second might not come as it seems to be gone after I deactivated Multicast and activated it back on the querier switch. Thank you for any advice!
So, the old 'turn it off and back on again' solved this?
@thewol, you have provided just a single packet, so it ain't that easy to find the time relationship between packets, the source MACs of the individual packets, whether there are general queries mixed between the group queries... maybe you could post another one with all igmp packets which came, say, during three minutes?
So starting from what can be seen: as the Query indicates maximum response time of 1 second, I cannot see anything strange about such packets to be sent multiple times per second - this is a precaution against lost or missed query frames.
Now why the querying switch chooses a response time of one second is a designer (or configuration) choice. If the switch wants to track the status of eventual multicast recipients "in real time", 1 second is quite fine. I guess you wouldn't be happy to wait for the picture from a TV channel for two minutes after you've ordered it. If all three switches send their queries twice per second and don't filter other switches' queries out, you've got 6 queries per second.
So the "only" unexplained point remains what made the switch keep sending a query for a particular group (which is what I've hoped to see from the capture).
A logical scenario for me would be that the switch periodically sends general queries (for Group 0, so a member of any group can answer), and for each group for which it receives a response to the general query, it starts tracking the state of that group using group queries. So I would expect that at some point in the past, the PC has responded to the general query with the address of the group whose address you can see in the group queries.
I wouldn't be surprised if you'd find out that some application using multicast was not running at the PC at the time you've looked at it but was running there before, and when closed, it hasn't "tidied up" properly so the network stack continued to respond the IGMP queries.
There are white points in this theory (has the PC's network stack stopped responding because there was a gap in the queries as you've restarted the switch? Do all the three switches query the same group so restart of just one of them does not stop the group queries to be sent?).
So I would disable the IGMP on all three switches at the same time for five minutes, then re-enable it and capture again, and I would deem the theory confirmed if I would find only see general queries in the capture.
Dear all, Thank you for your first help. Here is a new capture file into which we can see the two behaviors I was requesting help for:
http://pandasoftware.free.fr/igmpv2thewol.pcapng
The old 'turn it off and back on did not solve it! This capture has been taken after your suggestion of turning off Multicast on all 3 switches for 5 or more minutes, and turning it back on on the switches.
I should have been more specific when describing the capture conditions. To solve the chicken or egg problem, we need to have a capture which starts while the multicast is still off on all switches, so that we could see the beginning of the storm as you enable multicast on the first switch. If this is true for the capture you've just taken, then all my theory is wrong and I give up.
And I agree that 20 targeted queries per second look strange if all of them query the same group, come from the same source MAC address, and have a 1 s response timeout. But still it may be a designer's choice.
Thank you for your help and ideas. Here is a new capture file into which we can see the two behaviors I was requesting help for, this time ask requested I activated Multicast while capturing, switch 205, 204, and then 203, that should be the querier by its low IP number:
http://pandasoftware.free.fr/igmpv2thewol2.pcapng
THank you in advance for any good ideas on why so many packets are send, while no listener nor multicast sender is opened nowhere on the network.
Wireshark shows you what happens; to find out why it happens, you need to look at the applications responsible for sending the packets. So maybe there is some timer in the Cisco which controls the frequency of sending the group queries, and maybe there is not. Refer to Cisco documentation.
Because you haven't provided any network diagram, I can only assume that you capture at a machine connected to switch .203.
During the time when the switch .205 is the only one with IGMP on, the other switches let the IGMP packets go through but do not react on them. As soon as you switch on IGMP on .204, it stops forwarding IGMP from .205, and the same happens when you switch on IGMP on .203.
It seems, however, that it is a bit more complex:
the two general queries from .205 indicate response time 10 seconds, which implies that it should send another 10 seconds after the last one at latest, but the capture doesn't show this. The question here is whether the ICMP support in the .204 has not already been getting up while the .205 was sending its third general query so the .204 already haven't let it go through.
the group membership report doesn't seem to come as a response to the queries as the time between the last captured query and the report is not fixed
So I would say: switch off IGMP on all switches, leave it as it is for five minutes. Then start capturing, after two minutes switch on IGMP on .205, after another minute on .204, after another minute on .203. This should tell you whether the membership reports are sent spontaneously or as responses to queries, and whether the filtering of other switches' IGMP queries depends on whether IGMP is on on a given switch.
Another test would be to start from IGMP off on all switches plus disconnection of the machine which sends the group membership reports, and after 5 minutes in that state, starting the IGMP on switches one by one, one minute between switches, and two minutes after you activate it on the last switch, connect the machine back and continue capturing for one more minute.
This will only tell you whether the group queries are triggered by the membership reports or not; it will not tell you why the group queries are sent so frequently, as explained above.