[jboss-jira] [JBoss JIRA] Commented: (JBAS-8741) Linux multicast issue using IPv4 addresses and IPv6 stack

[Richard Achmatowicz (JIRA)]

    [ https://issues.jboss.org/browse/JBAS-8741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12570154#comment-12570154 ] 

Richard Achmatowicz commented on JBAS-8741:
-------------------------------------------

Record of email exchange on the subject with Bela, Paul:

> Richard:
> Well, I ran the AS 6 testsuite using an IPv6 stack and IPv4 addresses (including multicast address).
> The clustering tests (so far) are passing, but unfortunately HANamingService autodiscovery, which also makes use of a multicast address, checks for Linux and tries to bind to
> multicast when creating the multicast socket in order to avoid promiscuous traffic on Linux hosts. If it cannot bind to multicast (which it cannot with an IPv4
> address on an IPv6 socket IIRC), it catches the resulting exception and
> creates the multicast socket using port only. In the process it spits out this (familiar) message:
>
>"Could not bind to 223.11.12.13 (type IPv4 address); make sure your mcast address is of the same type as the IP stack (IPv4 or IPv6). Will ignore mcast_addr but this may lead to cross talking"
>IIRC, this means that communication *will* work, but we may also suffer promiscuous traffic between HAJNDI instances.
>
> How did you get around this issue in JGroups?

Bela:
> HAJNDI autodiscovery accesses java.net.MulticastSocket directly. I suggest we replace this code with a JGroups channel containing *only*
> UDP (and maybe UNICAST). This could be done via programmatic creation, e.g.
> 
> JChannel ch=new JChnnel(false);
> ProtocolStack stack=new ProtocolStack();
> ch.setProtocolStack(stack);
> stack.addProtocol(new UDP().setValue("key", "val").setValue("key2","val2"));
> 
> This would be a light-weight channel, with the thread pools disabled, the timer reduced to 1 thread (or disabled altogether) and diagnostics
> turned off as well.
> 
> If you want to do this, I could provide you with the code to create such a light-weight channel.
> 
> What puzzles me is the warning message below; either you guys already
> use JGroups (which I don't think, because then it would work) or the
> code for autodiscovery has been copied from JGroups..

Paul:.
> As I recall, Brian added this for JBAS-6080 (I assume it was copied from JGroups).  We use the same code for mod_cluster advertise.

Richard
> Multicast is used in too many places (naming, HornetQ, JGroups, clustering, and others). This same issue
> could turn up in a variety of place, no? This is probably an issue whose full solution needs to be left for AS 7.
> 
> One possibility to work around this in the short term is to simply tell 
> people that if they want to use IPv6, they need to
> (i) remove the stack preference from run.sh (which will be left in place)
> (ii) use an IPv6 mcast address when using an IPv6 stack



> Linux multicast issue using IPv4 addresses and IPv6 stack 
> ----------------------------------------------------------
>
>                 Key: JBAS-8741
>                 URL: https://issues.jboss.org/browse/JBAS-8741
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Integration
>    Affects Versions: 6.0.0.M4
>         Environment: Linux only
>            Reporter: Richard Achmatowicz
>            Assignee: Shelly McGowan
>             Fix For: TBD-6.x
>
>
> When starting the AS, we have the following three possible combinations of addresses / stacks:
> (i) IPv4 addresses with IPv4 stack (java.net.preferIPv4Stack=true)
> (ii) IPv6 addresses with IPv6 stack (java.net.preferIPv4Stack=false, java.net.preferIPv6Addresses=true)
> (iii) IPv4 addresses with IPv6 stack ( java.net.preferIPv4Stack=false, java.net.preferIPv6Addresses=false)
> The stack preference is specified by defining the above system properties; the addresses are specified as inputs to the -b and -u options of run.sh.
> Many versions of the AS force an IPv4 stack by setting java.net.preferIPv4Stack=true in run.sh when on Linux.
> There is an issue associated when using the combination IPv4 address / IPv6 stack. The issue is made up of two facts:
> Fact 1: When we initlaise a multicast socket for group communication, we can initialise it in one of two ways:
> (i) binding the multicast socket to a multicast address and port (known as "binding to mulicast")
> (ii) binding a multicast socket to a port only
> When using an IPv4 address on an IPv6 socket, we cannot bind to multicast.
> Fact 2: On LInux, there is a known problem, the promiscuous traffic problem, wherein if we have clusters X and Y running,
> cluster X can see and be influenced by messages from cluster Y, even if the multicast address they use are different. 
> The promiscuous traffic problem can be solved on Linux by binding to multicast. Binding to multicast is not required
> by other operating systems.
> Problem: when running with an IPv4 multicast address on an IPv6 stack on Linux, we cannot bind to multicast, and so
> we have the promiscuous traffic problem oif we use this address / stack combination.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira