could you explain a bit more what the Ingress IPs are? From my understanding these are somehow used by Envoy, and allocated from the PodCIDR? And there is a special identity (ReservedIdentityIngress) associated with them?

And from a BPF-routing perspective - I'd expect that these IPs reside in Host network namespace, and not in a normal pod (== veth pair) ?

could you explain a bit more what the Ingress IPs are? From my understanding these are somehow used by Envoy, and allocated from the PodCIDR? And there is a special identity (ReservedIdentityIngress) associated with them?

And from a BPF-routing perspective - I'd expect that these IPs reside in Host network namespace, and not in a normal pod (== veth pair) ?

Simplest way of describing Ingress IPs is: IPs (IPv4 and IPv6) allocated from the PodCIDR range of the node that are used as the source addresses of traffic forwarded by Cilium Ingress (and GW API) in the node. There is no real/full Cilium endpoint with these addresses, so there is no BPF datapath (bpf_lxc) nor bpf policy maps for them. Cilium agent computes a policy for the special entity though, and sends it to Envoy so that Envoy can enforce policy on the traffic forwarded by Cilium Ingress (or GW API).

ARP table on the destination node would normally be updated due to the traffic being sent from Cilium Ingress, but if it is flushed for any reason, or for IPv6 ND, the node with these IPs may need to be able to respond to ARP/ND to recover the flushed/missing ARP/ND table entry on the destination node.

No process in the node is listening on these addresses, so ARP/ND is only relevant for getting reply packets back to the node.

/test

No process in the node is listening on these addresses, so ARP/ND is only relevant for getting reply packets back to the node.

So if a local pod would receive a connection by such an IngressIP, and attempts to send a reply - where should that reply get forwarded to? With the IngressIP now visible in the local endpoint map to bpf_lxc, the relevant code needs to understand whether the reply should be delivered (a) into another pod or (b) to the host network namespace.

No process in the node is listening on these addresses, so ARP/ND is only relevant for getting reply packets back to the node.

So if a local pod would receive a connection by such an IngressIP, and attempts to send a reply - where should that reply get forwarded to? With the IngressIP now visible in the local endpoint map to bpf_lxc, the relevant code needs to understand whether the reply should be delivered (a) into another pod or (b) to the host network namespace.

Are you saying that since the IngressIPs are now in the endpoints map, this lookup now succeeds and finds a non-null ep?:

		/* Lookup IPv4 address, this will return a match if:
		 *  - The destination IP address belongs to a local endpoint
		 *    managed by cilium
		 *  - The destination IP address is an IP address associated with the
		 *    host itself
		 *  - The destination IP address belongs to endpoint itself.
		 */
		ep = __lookup_ip4_endpoint(daddr);

The desired action would be to route to host. Envoy uses an IP_TRANSPARENT socket to open the connection to the destination, with the IngressIP as the source address. Therefore there is a host networking namespace socket open on the (return) address, and routing the traffic through the host stack would allow it be delivered to Envoy, due to iptables rules we already have for proxy redirect (reply) traffic.

/test

The desired action would be to route to host.

Then I think we'll need a bit more work, so the programs that handle a delivery to local endpoint (eg from-container, from-overlay) understand that they should let the packet pass through into hostns, and not attempt a delivery via policy tailcall.

Right now that works by setting the ENDPOINT_F_HOST flag on the endpoint. But I'd actually want us to use two flags - one for "lives in hostns" (to drive the delivery mechanism), a second for "is a node IP" (to decide whether BPF masq is needed).

/test

The desired action would be to route to host.

Then I think we'll need a bit more work, so the programs that handle a delivery to local endpoint (eg from-container, from-overlay) understand that they should let the packet pass through into hostns, and not attempt a delivery via policy tailcall.

Right now that works by setting the ENDPOINT_F_HOST flag on the endpoint. But I'd actually want us to use two flags - one for "lives in hostns" (to drive the delivery mechanism), a second for "is a node IP" (to decide whether BPF masq is needed).

Right, the current ENDPOINT_F_HOST causes the neighbor request to be forwarded to the hostns without sending the ND advertisement, while for this we need the opposite. Currently this seems to work OK for IPv6 ND when the ENDPOINT_F_HOST flag is not set. Are you saying that we'd need another flag that triggers the same behavior as ENDPOINT_F_HOST elsewhere in the bpf datapath (from-container, from-overlay)?

Right, the current ENDPOINT_F_HOST causes the neighbor request to be forwarded to the hostns without sending the ND advertisement, while for this we need the opposite.

You mean this spot, correct? Makes sense. Note how it currently special-cases the ROUTER_IP (which is also allocated from the PodCIDR and lives in hostns, just like your IngressIP).

Are you saying that we'd need another flag that triggers the same behavior as ENDPOINT_F_HOST elsewhere in the bpf datapath (from-container, from-overlay)?

My suggestion would be

• s/ENDPOINT_F_HOST/ENDPOINT_F_HOSTNS, and use that whenever the packet needs to be delivered into host netns.
• add a new ENDPOINT_F_NODE_IP. And use that for the ICMPv6 case you're trying to fix, and the BPF masq case. Potentially more :).

/test

Adding backport label, in particular as this is needed to unblock additional fixes (#35098, #35418).