diff options
author | Michael Brown <mcb30@ipxe.org> | 2015-06-29 14:50:16 +0100 |
---|---|---|
committer | Michael Brown <mcb30@ipxe.org> | 2015-06-29 14:50:16 +0100 |
commit | 8829634bd7188bdfa5528421a8bbecf39c498f40 (patch) | |
tree | 1b5f2aa8169c91c97b286632f3119228ea1eb32e /README | |
parent | e213a008ca448c41f617d4565e0473ca705e69b3 (diff) | |
download | ipxe-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