- What I did
- How I did it

• Updates libnetwork/osl: stop tracking neighbor entries #50088
• Fixes Entries are never deleted from overlay ARP table #50232

Starting with commit 0d6e7cd DeleteNeighbor() needs to be called with the same options as the AddNeighbor() call that created the neighbor entry. The calls in peerdb were modified incorrectly, resulting in the deletes failing and leaking neighbor entries. Fix up the DeleteNeighbor calls so that the FDB entry is deleted from the FDB instead of the neighbor table, and the neighbor is deleted from the neighbor table instead of the FDB.

- How to verify it

1. Set up a multi-node Swarm cluster.
2. Create a user-defined overlay network.
3. Run a dummy task or basic container connected to the overlay on one of the nodes (henceforth referred to as the node under test) in order to force libnetwork to keep the network namespace around for the duration of the test.
4. Create a Swarm service with tasks attached to the overlay network, scheduled such that at least one task is scheduled on a different node than the node under test.
5. Scale the service up and down, or repeatedly force-update the service -- something to repeatedly connect and disconnect containers from the overlay.
6. Verify that the daemon on the node under test did not log any Peer delete operation failed messages.
7. Verify that the ARP table and VXLAN FDB in the overlay network's netns on the node under test are free of stale entries.

   nsenter --net="/run/docker/netns/1-$(docker network inspect $NETWORK_NAME --format '{{slice .ID 0 10}}')" \
     sh -c 'bridge fdb show brport vxlan0; ip neigh'
   

- Human readable description for the release notes

- A picture of a cute animal (not mandatory but encouraged)