Loading ...
Sorry, an error occurred while loading the content.

gratuitous ARP conflicts

Expand Messages
  • Eric A. Hall
    Hi, This isn t a TCP question, but I couldn t think of any better place to ask. If there s a more appropriate list, I d like to know about it (and will go ask
    Message 1 of 2 , Jan 2, 1999
    • 0 Attachment
      Hi,

      This isn't a TCP question, but I couldn't think of any better place to
      ask. If there's a more appropriate list, I'd like to know about it (and
      will go ask there).

      Assume that HOST_A comes onto the network and issues a gratuitous ARP.
      Also assume that the IP addr its announcing is already in use by HOST_B.
      Normally, Host_B would freak out, issue a console warning message like
      "HOST_A IS USING MY ADDDRESS!" and maybe send a unicast response back to
      HOST_A which would inform it of a problem.

      Whats the correct behavior from here on out? Should HOST_B issue its own
      gratuitous ARP?

      My question is really centered around the other devices on the network
      who are listening for the broadcasts and updating their caches with any
      new hardware address that they see. RFC 826 says that any device that
      already has the IP address of the sender in its ARP cache should update
      the information with a new IP address, if one is provided.

      Assuming that some devices are updating their caches with the hardware
      address provided by HOST_A during the gratuitous ARP, shouldn't HOST_B
      respond with its own gratuitous ARP as well? If it just responds with a
      regular (unicast) response, nobody else will see it. Worse, all of the
      other devices will have questionable data in their caches, and will
      start sending packets to HOST_B, since thats what the cache points to.

      If HOST_B sent another gratuitous ARP, what happens with HOST_A? Would
      it insist on sending yet another gratuitous ARP? When does it end?

      I'm particularly interested in implementation-specific issues. What does
      vendor X do, versus what does vendor Y do.

      Thanks

      --
      Eric A. Hall ehall@...
      +1-650-685-0557 http://www.ehsco.com
    • Eric A. Hall
      Dang it. ... ^^ hardware ... ^^^^^^ HOST_A I need to lay off the coffee. -- Eric A. Hall ehall@ehsco.com
      Message 2 of 2 , Jan 2, 1999
      • 0 Attachment
        Dang it.

        > My question is really centered around the other devices on the network
        > who are listening for the broadcasts and updating their caches with any
        > new hardware address that they see. RFC 826 says that any device that
        > already has the IP address of the sender in its ARP cache should update
        > the information with a new IP address, if one is provided.

        ^^
        hardware

        > Assuming that some devices are updating their caches with the hardware
        > address provided by HOST_A during the gratuitous ARP, shouldn't HOST_B
        > respond with its own gratuitous ARP as well? If it just responds with a
        > regular (unicast) response, nobody else will see it. Worse, all of the
        > other devices will have questionable data in their caches, and will
        > start sending packets to HOST_B, since thats what the cache points to.

        ^^^^^^
        HOST_A

        I need to lay off the coffee.

        --
        Eric A. Hall ehall@...
        +1-650-685-0557 http://www.ehsco.com
      Your message has been successfully submitted and would be delivered to recipients shortly.