bpf: Re-introduce ICMPv6 NS responder on from-netdev

[jschwinger233]

This reverts commit 6580714, to fix the breakage of "IPv6 NS responder for pod" introduced by #12086 (bpf: Reply NA when recv ND for local IPv6 endpoints).

6580714 was merged to solve #14509. To not revive #14509, this commit also passes through ICMPv6 NS if the target is native node IP (eth0's addr). By letting stack take care of those NS-for-node-IP packets, we managed to:

1. Solve IPV6 access to node is lost after installing cilium with ipv6 enabled #14509 again, but in a way keeping NS responder. The cause of IPV6 access to node is lost after installing cilium with ipv6 enabled #14509 was NS responder always generates ND whose source IP is "router_ip" (cilium_internal_ip) rather than "node_ip". Once we pass those NS-for-node-IP packets to stack, the ND response would naturally have "node_ip" as source.

2. Avoid the fib_lookup failure mentioned at bpf: Re-introduce ICMPv6 NS responder on from-netdev #30837 (comment).

This PR also adds bpf unit test to cover IPv6 NS responder feature.

Fixes: #30926

Fixes an IPv6 issue that cilium doesn't respond to Neighbor Solicitation targeting the pods on same node.

[jschwinger233]

/test

[jschwinger233]

/test

[jschwinger233]

/test

[jschwinger233]

/test

[jschwinger233]

ci-e2e keeps failing on north-south-loadbalancing but I couldn't make a local repro: https://github.com/cilium/cilium/actions/runs/7971912812/job/21798175918

Adding pwru gh action to see if I can get something useful.

[jschwinger233]

/ci-e2e

[jschwinger233]

ci-e2e keeps failing on north-south-loadbalancing but I couldn't make a local repro: https://github.com/cilium/cilium/actions/runs/7971912812/job/21798175918

Adding pwru gh action to see if I can get something useful.

This turns out to be a kernel specific bug.

c0dfeb0 (cc @julianwiedmann ) added a testcase for 5.4 with KPR=on + routing=vxlan, revealed this hidden bug which was accidentally fixed on 1.14, but now come back again when I intended to simply revert #25329 .

The scenario is NS connectivity, we are curling from outside to node_ip:node_port. The key part is when first TCP reply with syn+ack arrives at cilium_vxlan, it is supposed to be rev-NAT-ed to the original tuple, then to do a bpf_fib_lookup followed by bpf_redirect.

With or without bpf NS responder makes a difference for v6 neighbor system:

1. without bpf NS responder, when curling from outside, the ICMP6 NS for node_ip from outside will be handled by stack, as a result an ipv6 neigh entry will be recorded on the node.
2. with bpf NS responder, the NS for node_ip from outside is taken care of by bpf, and kernel doesn't get a chance to generate a v6 neigh entry for outside source ip.

Then it's going to affect bpf_fib_lookup:

1. without bpf NS responder, bpf_fib_lookup returns 0, because kernel has the neigh record;
2. with bpf NS responder, bpf_fib_lookup returns NO_NEIGH, and
   1. for kernel 5.10+, we have HAVE_FIB_INDEX to tolerate NO_NEIGH, so that cilium can call the bpf_redirecet_neigh to make things right
   2. for kernel 5.4, without HAVE_FIB_INDEX, cilium turns to use DIRECT_ROUTING_DEV_IFINDEX as fallback, which unfortunately is set to the index of eth1 instead of eth0 for some reasons. So skb ends up being redirected to a wrong netdev, breaking the connectivity.

#27642 is going to be helpful once we have the necessary kernel patch backport.

For now, I'm going to work another solution: bring back bpf NS responder only if the NS is asking for a pod; if NS is asking for the node IP, just hand it over to stack.

[jschwinger233]

/ci-e2e

[jschwinger233]

/ci-e2e

[jschwinger233]

CI was happy: https://github.com/cilium/cilium/actions/runs/8018397688/job/21904227831

Will add more bpf unit test and polish commit messages for review