vxlan: fix nonfunctional neigh_reduce()
authorDavid Stevens <dlstevens@us.ibm.com>
Mon, 24 Mar 2014 14:39:58 +0000 (10:39 -0400)
committerDavid S. Miller <davem@davemloft.net>
Mon, 24 Mar 2014 19:35:10 +0000 (15:35 -0400)
commit4b29dba9c085a4fb79058fb1c45a2f6257ca3dfa
tree3ee4d0ba0ee4ec64d8c1103dc1b2dc1e5231d3e5
parent866b7cdf5f8e440c4921765b7f4e1fe102a7e089
vxlan: fix nonfunctional neigh_reduce()

The VXLAN neigh_reduce() code is completely non-functional since
check-in. Specific errors:

1) The original code drops all packets with a multicast destination address,
even though neighbor solicitations are sent to the solicited-node
address, a multicast address. The code after this check was never run.
2) The neighbor table lookup used the IPv6 header destination, which is the
solicited node address, rather than the target address from the
neighbor solicitation. So neighbor lookups would always fail if it
got this far. Also for L3MISSes.
3) The code calls ndisc_send_na(), which does a send on the tunnel device.
The context for neigh_reduce() is the transmit path, vxlan_xmit(),
where the host or a bridge-attached neighbor is trying to transmit
a neighbor solicitation. To respond to it, the tunnel endpoint needs
to do a *receive* of the appropriate neighbor advertisement. Doing a
send, would only try to send the advertisement, encapsulated, to the
remote destinations in the fdb -- hosts that definitely did not do the
corresponding solicitation.
4) The code uses the tunnel endpoint IPv6 forwarding flag to determine the
isrouter flag in the advertisement. This has nothing to do with whether
or not the target is a router, and generally won't be set since the
tunnel endpoint is bridging, not routing, traffic.

The patch below creates a proxy neighbor advertisement to respond to
neighbor solicitions as intended, providing proper IPv6 support for neighbor
reduction.

Signed-off-by: David L Stevens <dlstevens@us.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
drivers/net/vxlan.c