We are running an application that uses multicasting
on Linux kernel 2.2.19. The application is
connected to two network interfaces for redundancy
purposes - only one interface is active at a time.
When the application starts up on the first interface,
the application can send and receive multicast messages.
We then use ifconfig to bring down the first interface,
and use ifconfig to bring up the second interface. The application
works with the exception that it cannot receive multicast
packets (it can still send multicast packets).
It appears that the multicast information is not propagated
when switching from one interface to the other. After
the switch, the information in /proc/dev/mcast is still set
up to work with the first interface. Also, it looks like the
device list of multicast information (checked by calling
ip_check_mc()) is lost when switching from the first to
second interface.
Is there a fix or work around to keep multicasting working
when switching from one interface to another? We looked
at the 2.4 kernel and it appears that it will have the same problem.
Also, if there is no fix or patch, we are considering whether
we should come up with a kernel patch. If we submitted a kernel
patch that propagates the multicast information when the
interface is changed, would it be accepted into the kernel?
I am not on the list so please CC with any answers/comments.
Thanks.
Christopher
?:.?˛???m???ka??b???zwm??b????˛???m?b??????z_???^n?r???z???h?????&???z??z?ޗ?+??+zf???h???~????i?????????z_???j:+v???)ߣ?m?S?y? ?杶????i?????? ????i
* Christopher James ([email protected]) wrote:
> We are running an application that uses multicasting
> on Linux kernel 2.2.19. The application is
> connected to two network interfaces for redundancy
> purposes - only one interface is active at a time.
> When the application starts up on the first interface,
> the application can send and receive multicast messages.
> We then use ifconfig to bring down the first interface,
> and use ifconfig to bring up the second interface. The application
> works with the exception that it cannot receive multicast
> packets (it can still send multicast packets).
does your app use INADDR_ANY for imr_interface when you join the
multicast group?
-chris
Chris Wright wrote:
> * Christopher James ([email protected]) wrote:
> > We are running an application that uses multicasting
> > on Linux kernel 2.2.19. The application is
> > connected to two network interfaces for redundancy
> > purposes - only one interface is active at a time.
> > When the application starts up on the first interface,
> > the application can send and receive multicast messages.
> > We then use ifconfig to bring down the first interface,
> > and use ifconfig to bring up the second interface. The application
> > works with the exception that it cannot receive multicast
> > packets (it can still send multicast packets).
>
> does your app use INADDR_ANY for imr_interface when you join the
> multicast group?
>
> -chris
the app (vocal 1.2) does not use INADDR_ANY for imr_interface when
joining the multicast group
-Christopher
?:.?˛???m???ka??b???zwm??b????˛???m?b??????z_???^n?r???z???h?????&???z??z?ޗ?+??+zf???h???~????i?????????z_???j:+v???)ߣ?m?S?y? ?杶????i?????? ????i
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
[email protected] 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???h?????&???z??z?ޗ?+??+zf???h???~????i?????????z_???j:+v???)ߣ?m?S?y? ?杶????i?????? ????i
* Christopher James ([email protected]) wrote:
> 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.
i don't think this is a valid expectation. joining a multicast group
is a device specific action. when you join, you either specify an
interface to join on (imr_interface=dev_ip_addr) or let the kernel choose
(imr_interface=INADDR_ANY). in either case, you are telling some hardware
to adjust its multicast filter and identifying that hardware by a unique
device index. as alexey mentioned, it sounds like your app has never told
the second interface that is should even care about multicast packets.
did you try joining on both interfaces? (you may find using a unique
service ip addr on each interface, and failing over an application ip
addr using aliases will help)
cheers,
-chris
Hello!
> It was our expectation that the switch from the first to second interface should
The expectation was wrong.
Alexey