8:06 a.m.
[
https://jira.jboss.org/jira/browse/JGRP-729?page=com.atlassian.jira.plugi...
]
Bela Ban commented on JGRP-729:
-------------------------------
[JGRP-20]
On multi-homed systems, the identity of a member is bound to a NIC (either chosen by the
OS, or by the
user through bind_addr): Address. When a message is sent, the msg contains this address as
the sender's
address. Responses go to the same address.
However, if that NIC breaks, and the sender's OS chooses a different NIC for the
datagram packets, the
receiver will still send the response back to the old address (the identity of the sender
cannot
change).
If we set the sender's address in any Message on *reception* of the message, we would
be able to send
the response back to a valid NIC in the above case. However, this means the *identity* of
the sender
changes, which JGroups cannot handle.
SOLUTION I: we could introduce a logical address, which contains the physical address of
the NIC
through which it was sent. Problem: a lot of code would have to change.
SOLUTION II: we maintain, in each transport, a table of sender's address as defined in
the Message, and
physical address of the {Datagram,Multicast}Packet received. Whenever we send a unicast
message, we get
the destination address from this table through a lookup in which dest_msg.dest_addr is
the key.
We need to reap the table every now and then to purge old addresses, we could use view
changes to do
so.
Example for SOLUTION II:
- Member P: address=1.2.3.4:5555
- P's box has 2 NICs: 1.2.3.4 and 5.6.7.8
- Receiver R receives a message from P: P.src_addr=1.2.3.4:5555, datagram's address is
1234:5555
- R doesn't add an entry to the translation table, because the addresses are the same
- R sends a response: it looks up 1.2.3.4:5555 (dst) in the translation table
- There is no entry, therefore R sends the response to 1.2.3.4:5555
- P's NIC 1.2.3.4 is unplugged
- P sends a message through NIC 5.6.7.8
- R receives a message M.src_addr=1.2.3.4:5555, datagram's address is 5.6.7.8:5555
- R adds an entry to its translation table: 1.2.3.4:5555 --> 5.6.7.8:5555
- R sends a response to 1.2.3.4:5555, since there is an entry for 1.2.3.4:5555, it uses
5.6.7.8:5555
as the destination address of the datagram packet
SOLUTION II allows us to reuse the existing code, but provides for changing underlying IP
addresses.
Support for NAT
---------------
Key: JGRP-729
URL: https://jira.jboss.org/jira/browse/JGRP-729
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 2.8
Using external_addr, members behind NATs can communicate. However, members behind the
same NAT cannot communicate as the NATted address is unknown [email by Terence Chan
below].
We need to fix this with logical addresses, where the identity of a member is independent
from the physical address
I am using JGroups to connect multiple servers in 2 zones, separated by
2 firewalls with Network Address Translation (NAT). The servers cannot
connect to each other due to NAT.
The situation is as follows:
-- Server A is behind Firewall A
-- Server A's local address is 10.253.40.80
-- Server A's NAT address is 10.253.2.80
-- Server B is behind Firewall B
-- Server B's local address is 172.16.80.33
-- Server B's NAT address is 10.1.1.39
When Server A initiates a connection to Server B, Server A sends a
"connection message" with source address = its local address (ie.,
10.253.40.80). Then, Server B replies a message with destination
address = the source address of the original message (ie., Server A's
local address). Since the local address (10.253.40.80) is not
reachable, so Server A cannot receive the reply.
Then I try to use "external_addr" attribute in the config file to set
the message's source address to the NAT address.
<TCP start_port="7900" external_addr="10.253.2.80" ...../>
But, since the message's source address becomes NAT address, servers
"within" the same network segment cannot send messages to each other,
because NAT address is ONLY recognized by servers outside the firewall.
For example, if Server A1 sends a message to another Server A2 in the
same network segment, A2 cannot reply to A1 because A2 doesn't recognize
A1's NAT address.
For your reference, below is the error message when Server B sends a
message to itself via its NAT address:
2008-03-27 20:36:55,871 DEBUG [ DownHandler (TCP)]
jgroups.protocols.TCP#sendToSingleMember() - failure sending message to
10.1.1.39:7000
java.lang.Exception: connection to 10.1.1.39:7000 could not be
established
at
org.jgroups.blocks.BasicConnectionTable.send(BasicConnectionTable.java:2
38)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira