aboutsummaryrefslogtreecommitdiff
path: root/README
diff options
context:
space:
mode:
authorMichael Brown <mcb30@ipxe.org>2015-06-29 14:50:16 +0100
committerMichael Brown <mcb30@ipxe.org>2015-06-29 14:50:16 +0100
commit8829634bd7188bdfa5528421a8bbecf39c498f40 (patch)
tree1b5f2aa8169c91c97b286632f3119228ea1eb32e /README
parente213a008ca448c41f617d4565e0473ca705e69b3 (diff)
downloadipxe-8829634bd7188bdfa5528421a8bbecf39c498f40.zip
ipxe-8829634bd7188bdfa5528421a8bbecf39c498f40.tar.gz
ipxe-8829634bd7188bdfa5528421a8bbecf39c498f40.tar.bz2
[ipoib] Attempt to generate ARPs as needed to repopulate REMAC cache
The only way to map an eIPoIB MAC address (REMAC) to an IPoIB MAC address is to intercept an incoming ARP request or reply. If we do not have an REMAC cache entry for a particular destination MAC address, then we cannot transmit the packet. This can arise in at least two situations: - An external program (e.g. a PXE NBP using the UNDI API) may attempt to transmit to a destination MAC address that has been obtained by some method other than ARP. - Memory pressure may have caused REMAC cache entries to be discarded. This is fairly likely on a busy network, since REMAC cache entries are created for all received (broadcast) ARP requests. (We can't sensibly avoid creating these cache entries, since they are required in order to send an ARP reply, and when we are being used via the UNDI API we may have no knowledge of which IP addresses are "ours".) Attempt to ameliorate the situation by generating a semi-spurious ARP request whenever we find a missing REMAC cache entry. This will hopefully trigger an ARP reply, which would then provide us with the information required to populate the REMAC cache. Signed-off-by: Michael Brown <mcb30@ipxe.org>
Diffstat (limited to 'README')
0 files changed, 0 insertions, 0 deletions