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.

12 comments:

  1. Microsoft should stick to what they do well. When someone works out what that is, please let them know :)

    ReplyDelete
  2. aha - i wonder if old Nokia checkpoint did the same thing.

    ReplyDelete
  3. Interesting post... I had always believed that VRRP utilized a Multicast MAC source but when I looked it up this morning that doesn't appear to be the case, 00-00-5E-00-01-XX. Where XX is the VRRP ID or instance.

    Why did I think it was a Multicast source?

    ReplyDelete
  4. Ivan, I think I found something from you that has a date from 2006...there are many Ivan's, but I'm guessing that was you all the way back then!

    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/

    ReplyDelete
  5. Hey Ivan,

    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.

    ReplyDelete
    Replies
    1. You're absolutely correct. Post updated. Thank you!

      Delete
    2. Y'know, come to think of it, I bet there truly isn't any requirement for the two hardware addresses (header and payload) to 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?

      Delete
  6. The Opcode field in the ARP Message specifies the nature of the ARP message. If it is 1, then the message is ARP request and if it is 2 then it is ARP reply.

    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.

    ReplyDelete
  7. Dear Ivan,

    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

    ReplyDelete
    Replies
    1. ... and this is exactly the totally wrong approach that got us into way too many difficulties (and started the whole DevOps movement). In this particular case it's not the question of having an ideal or somewhat less perfect situation - you shall not violate the standards (and expect other people to walk on the water to support your "ingenuity") just to get your job done.

      Best,
      Ivan

      Delete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.