ARP reply with multicast sender MAC address is indeed illegal
A while ago I was writing about the behavior of Microsoft’s Network Load Balancing, the problems it’s causing and how Microsoft tried to hack around them using multicast MAC addresses as the hardware address of sender in ARP replies (which is illegal). A few days ago one of my readers asked me whether I know which RFC prohibits the use of multicast MAC address in ARP replies.
A quick consultation with friendly Google search engine returned this web page, which contained the answer: section 3.3.2 of RFC 1812 (Requirements for IP Version 4 Routers):
A router MUST not believe any ARP reply that claims that the Link Layer address of another host or router is a broadcast or multicast address.
Problem solved – now I know the real reason we have to configure static ARP entries on Cisco routers and switches.
Why did I think it was a Multicast source?
Source: http://www.velocityreviews.com/forums/t38552-checkpoint-ha-cluster-w-multicast.html
"Todd,
you don't really need to enable multicast on routers at all. There is a multicast on L2 only and it is used just to reach all cluster members if they are connected to switch. If they are connected to hub, then you would not need multicast at all.
The only thing you have to do is to make static arp entry which will "connect" your multicast L2 (MAC) address with your virtual IP address. Why? Because router can't accept a multicast MAC address as an valid ARP reply due to RFC1812 (Requirements for IP Version 4 Routers):
3.3.2 Address Resolution Protocol - ARP
[snip]
A router MUST not believe any ARP reply that claims that the Link
Layer address of another host or router is a broadcast or multicast address.
HTH,
--
-Ivan."
Another relevant article by Greg:
http://etherealmind.com/checkpoint-nokia-firewall-cluster-xl/
At the risk of sounding pedantic...
*Any* frame with a multicast source MAC address is illegal, not just those frames containing ARP replies. See 802.3 sections 2.3.1.2 and 2.3.2.2.
Strictly speaking, what you're referring to here is the "hardware address of sender" in the ARP reply payload described by RFC 826, not the source hardware address.
Usually these two addresses (the one in the ARP payload, and the one in the frame header) are the same, but I'm not aware of any requirement that they match.
In the microsoft case, they'd have to be sourcing the ARP replies from a unicast address, but we know they populate the reply with a multicast address.
In the case of GLBP, we have one box (AVG) replying on behalf of another (AVF). If the AVG sourced the reply from the AVF's hardware address, that would screw up L2 filtering tables, so mismatched hardware addresses here too. Thankfully, it's all unicast this time around, so the mismatch is only interesting, and not bogus.
Are there any other reasons why these two L2 addresses wouldn't match?
When the ARP request is sent (with opcode as 1, for sure ARP request is a broadcast as everyone in the local network should get it) the ARP header is filled with 3 important values along with other and they are
1) Target IP Address
2) Source IP Address
3) Source MAC address
Target MAC address should be empty, because that is what the source machine is trying to find out. Ideally source MAC address cannot be a
multicast MAC address and it is illegal.
But, Microsoft NLB (Network Load Balancing) and Fail-over Server Clusters require special type of addressing configuration since clusters contain more than one computer.
I was just mentioning developers may sometime circumvent the ideal situation because they are looking to only to solve their problems and how make their software work.
Thanks a lot for your wonderful tech posts...
J Thomas
Best,
Ivan