There is no point, and it populates the cache with entries we don't
need. Local containers will still need to issue an ARP request when
they first talk to an IP corresponding to the MAC, so we learn about
the MAC at that point, just as normally happens.
This was rather impenetrable and had some significant code
duplication. So add some words of explanation, and refactor to remove
the duplication.
Some fly-by fixing of minor bug too: buildUnicastRoutes failed to
exclude asymmetric connections from the first hop.
Golang locks aren't re-entrant. As result one can get deadlocks on
RWMutexes like this:
goroutine #1: attempt to acquire read lock -> success
goroutine #2: attempt to acquire write lock -> wait
goroutine #1: attempt to acquire read lock again -> wait
(a pending write lock prevents subsequent acquisitions of read locks)
Peer.HasPathTo could run into this since it could attempt to acquire
the read lock on a peer multiple times if previously it had
encountered that peer via an asymmetric connection.
We don't need. Multicast addresses never appear as sources and hence
never end up in the peer_cache. And the router always broadcasts
frames with destination addresses that aren't in the peer cache.
Matthias Radestock