Thanks for looking over everything and shortening my patch list.<br><br><div class="gmail_quote">On Fri, Nov 12, 2010 at 7:50 PM, Michael Brown <span dir="ltr"><<a href="mailto:mbrown@fensystems.co.uk">mbrown@fensystems.co.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><br></div><div class="im">
<br>
</div>Yes, that is worrisome, and I suspect it would break on some other NICs.  Do<br>
you have any details on how this NIC handled interrupts, and why this didn't<br>
work with iPXE?<br>
<div class="im"><br></div></blockquote><div><br></div><div>I'll try to get more data from them.  They may respond on-list anyway since I think they are subscribed.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">
> And finally, for lack of debug I cannot provide an ongoing assessment of<br>
>  how required it is, but I disabled arp table population on non-arp<br>
>  traffic, ICMP echo replies and TCP resets because with thousands of nodes<br>
>  on a vlan, gPXE's neighbor table wasn't quite coping with the chaotic<br>
>  traffic (tried to learn too many incidental macs and didn't manage to get<br>
>  the boot servers in the table).  Unfortunately, debugging thousands of<br>
>  nodes booting at once is not a frequent test case and I had no need of<br>
>  'proper' network behavior, so I took a hatchet to it:<br>
> <a href="https://xcat.svn.sourceforge.net/svnroot/xcat/xcat-dep/trunk/xnba/ipxe-drop" target="_blank">https://xcat.svn.sourceforge.net/svnroot/xcat/xcat-dep/trunk/xnba/ipxe-drop</a><br>
> packets.patch It could be possible to reproduce the problem more<br>
>  synthetically at small scale for a 'proper' fix, but I didn't try given a<br>
>  good enough solution to my problem.<br>
<br>
</div>Both ICMP and TCP should be unicast, so I'm puzzled why you would see high<br>
traffic volumes for these protocols.  Removing the ability to respond with ICMP<br>
echo replies and TCP resets would noticeably downgrade functionality, whereas<br>
the ARP portion of the patch should result only in an extra pair of ARP<br>
packets, so I'm tempted to apply only the ARP portion.  Any thoughts?<br>
<font color="#888888"><br>
Michael<br></font></blockquote><div> </div></div>I don't mind either way, I consider the ability to maintain a patch externally a good way to make calls on 'acceptable' limitations for our user base that would be unacceptable to others.  My first step was the arp patch too, thinking that was all, but it wasn't enough.  To address your puzzlement, these nodes nominally participate in a number of clustered services with some number of probes from monitoring services, particularly when they miss heartbeats.  So monitoring services come to probe the running OS to evaluate state and end up trying to probe iPXE, consuming neighbor table entries to get their queries answered.  However, it looked like gPXE (at the time) should have been able to drop the entries in spite of that situation and move on, but somehow wasn't.  Since we're the only ones to really see this, keeping the function intact for almost everyone makes sense.