1

I'm (on behalf of a client, anyway) having some troubles with Linux accessing a multicast NLB cluster hosted on Hyper-V (waiting for more information on what version, but I don't think the version is too relevant because this seems a client side issue).

There are two members in the NLB cluster. Each has their own MAC address (01:xx:xx:xx:xx:xx), as is usual in multicast mode. They both also answer to a shared multicast MAC address for the cluster (03:xx:xx:xx:xx:xx), which is how multicast NLB seems to work.

Pinging the cluster IP from a Windows machine works OK, the console displays the output you'd expect to see (sent 4, received 4, etc). If you Wireshark while pinging, you can see that the flow goes something like this:

ClientIP-ClientMAC -> ClusterIP-ClusterMAC : ICMP echo request
ClusterIP-Node1MAC -> ClientIP-ClientMAC   : ICMP echo response
ClusterIP-Node2MAC -> ClientIP-ClientMAC   : ICMP echo response (duplicate response from the second node)
ClientIP-ClientMAC -> ClusterIP-ClusterMAC : ICMP destination unreachable (seems to be the client discarding the second ping response, and using the ClusterMAC because that's what's in its ARP table, even though that's not the MAC that the frame was received from)

So the raw flow is a bit odd, but that seems to be almost by design; the important thing is that a ping in this scenario does work.

However, there's a Linux-based appliance on the network as well. This is not able to successfully ping the NLB cluster, and when tcpdumping a similar ping session, it basically ends after the echo request is sent. The ARP table is correct and shows the multicast MAC of the cluster IP (03:xx:xx:xx:xx:xx), the outgoing frame has the correct MAC address on it. However, in tcpdump no reply is shown.

Is it possible that the Linux kernel is seeing the ICMP response frame come back, noted that the MAC address is a different MAC address to the one that was used on the outgoing frame, and then dropping it before tcpdump (or ping, running in userspace) has a chance to see it?

Improve this question
2
  • Not for nothing but what service are you load balancing and can the Linux appliance connect to that service?
    – joeqwerty
    Jan 7, 2015 at 15:25
  • It's a pair of OWA servers - not clear at this point whether they're purely for OWA, or whether they hold any other Exchange roles. And no, the Linux box can't talk HTTPS with it either, tcpdumping while trying a wget to fetch the OWA login page just results in several outgoing SYNs with no incoming SYN/ACK, and then wget times out.
    – gac
    Jan 7, 2015 at 15:35

1 Answer 1

Reset to default
0

The answer in this case appeared to be multicast (IGMP) snooping on the Linux box. This was enabled on the br0 bridge interface (which is required for VPN access via a tap device); as soon as I used sysfs to disable it, pings started coming back. They were duplicated, same as the Windows client, but they're working...

echo 0 > /sys/devices/virtual/net/br0/bridge/multicast_snooping
Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .