* Question: igmp behavior on interface change
@ 2009-03-18 14:03 Neil Horman
[not found] ` <OF69D34007.7F9590E4-ON8825757D.005914BF-8825757D.00592A56@us.ibm.com>
0 siblings, 1 reply; 2+ messages in thread
From: Neil Horman @ 2009-03-18 14:03 UTC (permalink / raw)
To: netdev; +Cc: davem, andy, dlstevens
Hey-
Was wondering if anyone wanted to chime in on this. Someone asked me
recently what our behavior should be in response to in interface link state
change in regards to multicast reception. They claim that if an mc group is
joined, and we issue an igmp join request via, say eth0, and then preform an
ifdown/ifup on that interface, that frames stop getting delivered for that
group. I'm having this confirmed, but its my guess that in response to the link
flap, the attached router on the other end of the link has unsubscribed from the
group in response to the link state change.
So my question is, whats the right behavior here? Reading RFC 3376,
seems to suggest that we need to issue a state-change report as soon as the link
goes back up, but its vague, I could see an argument being made for both the
host and the router to keep their mc group state unchanged and let membership
queries ages the groups out as per normal.
I was going to look into writing some notification code for igmp to
detect link state chagnes and issue the reports on link up, but I wanted to be
sure there were no counter arguments first. So any and all thoughts
appreciated.
Thanks!
Neil
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Question: igmp behavior on interface change
[not found] ` <OF69D34007.7F9590E4-ON8825757D.005914BF-8825757D.00592A56@us.ibm.com>
@ 2009-03-19 2:34 ` Neil Horman
0 siblings, 0 replies; 2+ messages in thread
From: Neil Horman @ 2009-03-19 2:34 UTC (permalink / raw)
To: David Stevens; +Cc: andy, davem, netdev
On Wed, Mar 18, 2009 at 09:13:55AM -0700, David Stevens wrote:
>
>
> Neil Horman <nhorman@tuxdriver.com> wrote on 03/18/2009 07:03:53 AM:
>
>
> > I was going to look into writing some notification code for igmp to
> > detect link state chagnes and issue the reports on link up, but I wanted
> to be
> > sure there were no counter arguments first. So any and all thoughts
> > appreciated.
>
> Isn't that ip_mc_up()? Are you not getting the reports?
>
> +-DLS
Thank you! I knew there was a some integration between igmp and interface state
changes, but couldn't find it! Nevertheless, yes, thats the report I'm getting,
not so much the lack of membership reports, but the lack of multicast reception
in perpituity after a link state change. I'm still gathering data on why, so
I'm not 100% sure on the lack of the membership report, but now that you've
shown me the path between state changes and igmp updates, I can figure out more
precisely whats going on.
Thanks!
Neil
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2009-03-19 2:35 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-03-18 14:03 Question: igmp behavior on interface change Neil Horman
[not found] ` <OF69D34007.7F9590E4-ON8825757D.005914BF-8825757D.00592A56@us.ibm.com>
2009-03-19 2:34 ` Neil Horman
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox