<div dir="ltr">It might have.  My problem is at the time, I chased down the sources of the neighbor table being full amidst booting several thousand servers at once.  After having a scheme that works, its hard for me to justify the experiment when I'm on multi thousand server configs nowadays.  In theory a small testbed could be used, however I don't really see the pressing need to send back TCP reset when a second prior it would not be able to (firmware not bothering) and a couple of seconds later it won't be able to (in kernel prior to nic driver) in our usage (and half the time, the full OS won't send out a TCP reset due to firewall rules, so restoring the iPXE capability isn't something we are overly interested in).</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jul 11, 2013 at 8:11 PM, Michael Brown <span dir="ltr"><<a href="mailto:mbrown@fensystems.co.uk" target="_blank">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">On 12/07/13 01:20, Jarrod Johnson wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
FYI, in the xcat branch, we don't send RST.  In our case it was because<br>
TCP services pounding randomly on IPs would cause ipxe to get neighbor<br>
table entries preventing it from talking to intended servers.<br>
</blockquote>
<br></div>
How much pounding happens, and does this problem still occur with current iPXE?  I put in some changes back in March 2012 to make the number of ARP cache entries dynamic, which should alleviate the problem (relative to a fixed-size cache).<span class="HOEnZb"><font color="#888888"><br>

<br>
Michael<br>
</font></span></blockquote></div><br></div>