OK, so I am finally studying multicast routing! (...waits for applause to die down...)
I suppose IGMPv2 is more widespread today than IGMPv1 but I'm told they'll BOTH be on the BSCI exam (grumble...)
If I understand this right, under IGMPv1, a host that wants to join a mcast group sends a "membership report" to the IGMPv1 Querier. The Querier also queries everyone every 60sec if they want to remain in the multicast group; and if they don't reply to 3 consecutive queries, they're axed from the group.
Question: If the client device has to send a membership report every 60 sec, what's the purpose of having one router continually query it?
It seems uneconomical for the querier to have to send out a packet every 60 sec just to solicit something equally simple as a hello packet; when you could instead just have the client devices send their membership reports pro-actively and lose the "query" traffic.
You wrote: If the client device has to send a membership report every 60 sec, what's the purpose of having one router continually query it?
I am not aware that hosts should do that. According to the RFC 1112 where the IGMPv1 is described, hosts send unsolicited reports only when initially joining a multicast group. After that, no reports from hosts are sent until they are explicitely queried.
With this in mind, the need to query the stations periodically is quite natural.
"After that, no reports from hosts are sent until they are explicitely queried."
That is my point.
If I am a host and I have joined group 126.96.36.199, my local router sends a query out every 60 sec (to 188.8.131.52 if I'm not mistaken). If I receive this query (which I do, every 60 sec), I must reply to it with my Membership Report.
So as long as I'm sending the MR every 60 sec (each time in response to a query), I don't get why the querying needs to be done. Why isn't IGMPv1 set up just send the MR every 60 sec proactively, in the same way that neighbors send hello packets? The IGMPv1 querier will cancel the membership after three minutes with no responses to the queries; so why not just cancel it in response to three minutes of no MR's (the way a neighborship is canceled after no hellos).
Giuseppe says the queries let other routers on the segment know that the querier is alive, but why do the other routers all need to know that? Again, why not just have hosts send the MR's proactively to all connected routers?
Probably I won't need to know the answers to pass the BSCI, but it is something I wonder about. The querying thing seems just uneconomical.
One simple reason I can think of is, to have control over the query interval.
If there is a requirement to tweak the interval on which a router will expect the MR from host (not max-response time, but query-interval), it is simple to mention the same in router rather than tweaking the timer in all host.
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...