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).
On Thu, Jul 11, 2013 at 8:11 PM, Michael Brown <mbr...@fensystems.co.uk>wrote: > On 12/07/13 01:20, Jarrod Johnson wrote: > >> FYI, in the xcat branch, we don't send RST. In our case it was because >> TCP services pounding randomly on IPs would cause ipxe to get neighbor >> table entries preventing it from talking to intended servers. >> > > 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). > > Michael >
_______________________________________________ ipxe-devel mailing list ipxe-devel@lists.ipxe.org https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
