[Spread-users] spread-5.0.0rc1 : data_link.c : algorithm to choose interface(s) for multicast binding changed ?
Martin Schu
martin.sc11111 at gmail.com
Mon Dec 19 13:12:21 EST 2016
John,
thank you very much for your detailed answers!
When we discovered the binding of an additional (wrong) interface in
netstat-g we first did not know if this is for sending or receiving. We had
not been sure if this could cause spread sending something to the wrong
interface which might lead to retransmissions or other problems in spread
communication.
So we decided to instruct spread to bind the one and only interface
corresponding to the given host's address by the spread.conf stated below.
As we understood the implementation for this in spread 4 has room for
improvement. But this is not a problem because we learnt the binding is for
incoming direction and there will almost never be incoming traffic on that
wrong interface at the spread port.
Nevertheless we like the more strict behavior of spread 5 for that. We will
keep our restriction to the one and only interface for spread, because the
other interfaces are used for other things. And we do not want spread to
touch these other interfaces.
Cheers!
Martin
On Thu, Dec 15, 2016 at 1:02 AM, John Lane Schultz <
jschultz at spreadconcepts.com> wrote:
> Martin, Everyone,
>
> I also looked at what would happen under Spread v5.0 if you omitted the
> interface specification in your configuration. In that case, I think it
> would bind a recv channel to INADDR_ANY (so traffic on any interface to its
> port that wasn’t already bound by another process could reach it) and it
> would join the multicast group on its main address interface. So, you
> might not need the interface specification any more if you don’t care about
> limiting on which interface traffic to your port might arrive. That is, if
> the only reason you were using the interface specification was to force the
> multicast group join to occur on the correct interface, then that issue
> might be gone in Spread v5.0. Give it a shot and see, if you like.
>
> r = DL_init_channel_gen(RECV, NULL, [INADDR_ANY, port]) /* recv data */
> bind(r, [INADDR_ANY, port])
>
> DL_join_multicast_gen(r, 239.192.2.2, 151.1.1.1)
> join(r, multiaddr=239.192.2.2, interface=151.1.1.1)
>
> tr = DL_init_channel_gen(RECV, 0, [INADDR_ANY, port+1]) /* unicast recv
> token */
> bind(tr, [INADDR_ANY, port+1])
>
> I also forgot to mention that in v5.0, I separately make a socket for
> sending that is always bound to the main address of the daemon:
>
> s = DL_init_channel_gen(SEND | RECV, NULL, [151.1.1.1, 0])
> bind(s, [151.1.1.1, 0])
>
> This can be important because Spread v5.0 now enforces that, at the IP
> level, the source address of received traffic matches that primary address
> associated with the daemon who claims to have sent it in the packet. So,
> Spread itself now implements a weak form of IP based “firewalling.” It
> will ignore packets who source IP address doesn’t match the address of the
> transmitter marked in the packet.
>
> This is an important change and means, for example, that spmonitor must be
> run on one of the machines in the current configuration or its traffic will
> be ignored too. This was done intentionally so that if someone wanted to
> send traffic to your Spread deployment, then they would either have to
> forge IP headers or be on one of the machines in your configuration.
>
> Cheers!
>
> -----
> John Lane Schultz
> Spread Concepts LLC
> Cell: 443 838 2200
>
> On Dec 14, 2016, at 12:51 PM, John Lane Schultz <
> jschultz at spreadconcepts.com> wrote:
>
> Martin,
>
> Here’s the difference between the two versions in how they bind and how
> they join multicast groups for your configuration file. I used 151.1.1.1
> as my example.
>
> ##########################
> Spread v4.4:
>
> mr = DL_init_channel(RECV, 239.192.2.2, 239.192.2.2, port) /* multicast
> recv data */
> bind(mr, [239.192.2.2, port]);
> join(mr, multiaddr=239.192.2.2, interface=INADDR_ANY)
>
> ur = DL_init_channel(RECV | DL_BIND_ALL, 239.192.2.2, 155.1.1.1, port) /*
> unicast recv data */
> bind(ur, [155.1.1.1, port])
> join(ur, multiaddr=239.192.2.2, interface=155.1.1.1)
>
> tr = DL_init_channel(RECV, 0, 155.1.1.1, port+1) /* unicast recv token */
> bind(tr, [155.1.1.1, port+1])
>
> ##########################
> Spread v5.0:
>
> ur = DL_init_channel_gen(RECV, NULL, 155.1.1.1) /* unicast recv data */
> bind(ur, [155.1.1.1, port])
>
> DL_join_multicast_gen(ur, 239.192.2.2, 151.1.1.1)
> join(ur, multiaddr=239.192.2.2, interface=151.1.1.1)
>
> tr = DL_init_channel_gen(RECV, 0, 155.1.1.1, port+1) /* unicast recv
> token */
> bind(tr, [155.1.1.1, port+1])
>
> mr = DL_init_channel_gen(RECV, NULL, 239.192.2.2) /* multicast recv data
> */
> bind(mr, [239.192.2.2, port])
>
> DL_join_multicast_gen(mr, RECV, 239.192.2.2, 151.1.1.1)
> join(mr, multiaddr=239.192.2.2, interface=151.1.1.1)
>
> ##########################
>
> The reason why you see v4.4 joining the same group on different interfaces
> is that v4.4 joins 239.192.2.2 on interfaces INADDR_ANY and interface
> 151.1.1.1 on different file descriptors.
>
> Meanwhile, v5.0 joined 239.192.2.2 both on interface 151.1.1.1 on two
> different file descriptors.
>
> The extra join on the unicast recv file descriptor is probably only
> necessary on Windows where the extra multicast recv file descriptor isn’t
> even created.
>
> Cheers!
>
> -----
> John Lane Schultz
> Spread Concepts LLC
> Cell: 443 838 2200
>
> On Dec 14, 2016, at 7:18 AM, Martin Schu <martin.sc11111 at gmail.com> wrote:
>
> Hi John,
>
> we have some strange observation:
> With spread-4.4.0 running on some of our hosts we see a wrong binding of
> an additional interface for multicast, which makes no sense to us and might
> be causing problems due to wrong routed traffic.
> With spread-5.5.0rc1 this malfunction is gone. Only the correct interface
> is bound.
>
> Maybe you can help us to understand what is happening here. Below is the
> output of netstat -g on the same host with same configuration. Only the
> spread installation was updated! No other change.
>
> Any advice is greatly welcome. We don't understand what causes that wrong
> interface binding.
>
> Best regards,
> Martin
>
> ** spread.conf:
> Spread_Segment 239.192.2.2:8982 {
> host1 155.1.1.1 { 155.1.1.1 }
> host2 155.1.1.2 { 155.1.1.2 }
> host3 155.1.1.3 { 155.1.1.3 }
> }
> Spread_Segment 239.192.2.4:8982 {
> host4 155.1.1.4 { 155.1.1.4 }
> host5 155.1.1.5 { 155.1.1.5 }
> host6 155.1.1.6 { 155.1.1.6 }
> }
>
> ** spread-4.4.0
> running:
>
>
> $ netstat -g
> IPv6/IPv4 Group Memberships
> Interface RefCnt Group
> --------------- ------ ---------------------
> lo 1 224.0.0.1
> eth0 1 224.0.0.1
> eth1 1 224.0.0.1
> eth2 1 239.192.2.2
> !!!WRONG!!!
>
> eth2 1 224.0.0.1
> eth3 1 239.192.2.2
> CORRECT
>
> eth3 1 224.0.0.1
> eth4 1 224.0.0.1
>
>
>
> ** no spread running:
>
>
> $ netstat -g
> IPv6/IPv4 Group Memberships
> Interface RefCnt Group
> --------------- ------ ---------------------
> lo 1 224.0.0.1
> eth0 1 224.0.0.1
> eth1 1 224.0.0.1
> eth2 1 224.0.0.1
> eth3 1 224.0.0.1
> eth4 1 224.0.0.1
>
>
>
> **
> spread-5.0.0rc1
> running:
>
>
> $ netstat -g
> IPv6/IPv4 Group Memberships
> Interface RefCnt Group
> --------------- ------ ---------------------
> lo 1 224.0.0.1
> eth0 1 224.0.0.1
> eth1 1 224.0.0.1
> eth2 1 224.0.0.1
> eth3 2 239.192.2.2 CORRECT
> eth3 1 224.0.0.1
> eth4 1 224.0.0.1
>
>
>
>
> _______________________________________________
> Spread-users mailing list
> Spread-users at lists.spread.org
> http://lists.spread.org/mailman/listinfo/spread-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spread.org/pipermail/spread-users/attachments/20161219/fa660ab4/attachment.html>
More information about the Spread-users
mailing list