public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Christopher James <cjames@berkeley.innomedia.com>
To: kuznet@ms2.inr.ac.ru
Cc: linux-kernel@vger.kernel.org,
	Christopher James <cjames@berkeley.innomedia.com>
Subject: Re: Multicast fails when interface changed
Date: Mon, 14 Jan 2002 16:15:54 -0800	[thread overview]
Message-ID: <3C4374BA.F8E26684@berkeley.innomedia.com> (raw)
In-Reply-To: <200201142016.XAA10180@ms2.inr.ac.ru>

kuznet@ms2.inr.ac.ru wrote:

> Hello!
>
> > the app (vocal 1.2) does not use INADDR_ANY for imr_interface when
> > joining the multicast group
>
> Hmm... and what does it use?
>
> As soon as /proc/net/dev_mcast does not show membership on the second
> interface, it is not difficult to conclude that the applciation just forgot to
> request mmembership on it.
>
> Alexey

When joining the multicast group, imr_interface is set to the hostname
IP address, in this case 192.168.25.113.  This was verified by
by looking at the Vocal code,  and by putting printfs in Vocal code
to print out imr_interface when joining the multicast group.

More background on app and problem:  We are developing a high availability
solution where the application can run on one of two redundant networks.
The application uses either eth1 (connected to network1)
or  eth2 (connected to network2).  Only one interface is up at a time.
When the application comes up, it uses eth1.  Another process (other than
the application) monitors the health of network1.  If network1 goes down, then
the
monitoring process uses ifconfig to take down eth1, and ifconfig
to bring up eth2 (using the same configuration information  as used for
eth1).  This switch is  completely transparent to the application: the
application does
not know about the switch or do anything to make the switch;  the app does not
set
multicast membership on the new interface.

It was our expectation that the switch from the first to second interface  should

work without any involvement from the application because the second interface is
configured
exactly the same as the first interface.  After the switch, everything seems to
work with the
exception of multicasting:  the multicast membership information is not
propagated to the second
interface, it stays with the first interface.

Christopher
(I'm not on list so please CC with answers/comments)

ý:.žË›±Êâmçë¢kaŠÉb²ßìzwm…ébïîžË›±Êâmébžìÿ‘êçz_âžØ^n‡r¡ö¦zË\x1aëh™¨è­Ú&£ûàz¿äz¹Þ—ú+€Ê+zf£¢·hšˆ§~†­†Ûiÿÿïêÿ‘êçz_è®\x0fæj:+v‰¨þ)ߣømšSåy«\x1e­æ¶\x17…\x01\x06­†ÛiÿÿðÃ\x0fí»\x1fè®\x0få’i\x7f

  reply	other threads:[~2002-01-15  0:16 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-01-09 18:34 Multicast fails when interface changed Christopher James
2002-01-09 21:10 ` Chris Wright
2002-01-11  1:06   ` Christopher James
2002-01-14 20:16     ` kuznet
2002-01-15  0:15       ` Christopher James [this message]
2002-01-15  3:28         ` Chris Wright
2002-01-15 17:41         ` kuznet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3C4374BA.F8E26684@berkeley.innomedia.com \
    --to=cjames@berkeley.innomedia.com \
    --cc=kuznet@ms2.inr.ac.ru \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox