ARP Request for SVC at Daimler

Due to processing by IBM, this request was reassigned to have the following updated attributes:
Brand - Servers and Systems Software
Product family - Storage
Product - IBM System Storage SAN Volume Controller (SVC) / Spectrum Virtualize

For recording keeping, the previous attributes were:
Brand - Tivoli
Product family - Storage
Product - IBM System Storage SAN Volume Controller (SVC) / Spectrum Virtualize

I got the following information from HP/Daimler with regards to the gratuitous ARP problem betw. IBM clusters and HP layer-3 switches. I attach it here for you and try to copy it into the RFE (translations of German parts are in brakets). Does this help to come nearer to a solution?

*************************************
Prinzipiell werden Gratuitous ARPs auf Basis ARP-Reply von HP unterstützt, allerdings ist der Inhalt des ARP-Paketes nicht korrekt.
(= In principle, HP supports gratuitous ARPs based on ARP-reply, however, the content of the ARP packet is not correct.)
 
Anbei das HP-Statement:
„ The switch ARP cache is not updated when receiving the ARP Reply because the sender and target IPs are not only different but also because the target IP is a broadcast IP ( 53.16.12.255 in the test case).
It's already unusual to send Gratuitous ARP Reply as when an equipment does a local failover it send a Gratuitous ARP Request but here the Gratuitous ARP Reply is not legal.
So either the problem reproduction doesn't match what's really seen with the IBM system or there is a problem with the way the IBM system generates Gratuitous ARP during failover.
Have there been any data collected reflecting the real IM failover case?”
 
-screen shot in Mail to Quintus-
 
Laut Wikipedia muss das aber sein (However accoridng to Wikipedia is should be) http://en.wikipedia.org/wiki/Address_Resolution_Protocol :
…ARP may also be used as a simple announcement protocol. This is useful for updating other hosts mapping of a hardware address when the senders IP address or MAC address has changed. Such an announcement, also called a gratuitous ARP message, is usually broadcast as an ARP request containing the senders protocol address (SPA) in the target field (TPA=SPA), with the target hardware address (THA) set to zero. An alternative is to broadcast an ARP reply with the sender's hardware and protocol addresses (SHA and SPA) duplicated in the target fields (TPA=SPA, THA=SHA) …
 Wie kommen wir in diesem Punkt weiter?

*************************************

NOTE: Sometimes getting deeply technical can lack empathy and emotion properly. What we're meaning to say should not be construed as any accusation against HP. We ask that they please comment or explain (better yet privately with us) why this choice of implementation was made so we can work together on a resolution for you, as a client. Thank you.

The information at http://tools.ietf.org/html/rfc5227#section-3 explains it. The HP switch in question does not seem to fully implement RFC 826. In finding a resoution, consider the following:
a) Ideally HP switches should implement RFC 826 correctly and not have this problem
b) However that document says that in general it's better to use request packets, since people have been lax about implementing standards
We would like to first get a technical description (from HP or otherwise) about "why" HP switches can't do this. This will be important if indeed we end up customizing our interactions with HP switches going forward.

Note to submitter: customer information has been removed from the public content of this request, please do so in the "Use Case" section also. You can put private information as needed into the "Business Justification" section and "Customer Name" sections.