simple-k8s-cni
simple-k8s-cni copied to clipboard
y805939188
Problem with bpf_redirect_peer
From the author tutorial: "The official cilium blog says that the skb should be directly redirected from the vxlan device to the half veth of the pod in netns through bpf_redirect_peer, but when I first tried to use bpf_redirect_peer for redirection , It is observed that the traffic indeed enters the veth in the pod, and the packet capture can also capture the request on this veth, but I don’t know why, it does not return a reply, but it is ok to switch to bpf_redirect. If there is any big If you know the reason, please let me know, thank you" (I'm using Google Translate)
=> I also encounter the same problem when using bpf_redirect_peer. All the packets go to the pod dest veth but there aren't any reply messages.
=> I'm using eBPF to trace, the handler of the IP layer - ip_rcv drop all the packets with bpf_redirect_peer
=> Any ideas why this happens? I believe that every thing is fine: MAC, IP of source and dest
From the author tutorial: "The official cilium blog says that the skb should be directly redirected from the vxlan device to the half veth of the pod in netns through bpf_redirect_peer, but when I first tried to use bpf_redirect_peer for redirection , It is observed that the traffic indeed enters the veth in the pod, and the packet capture can also capture the request on this veth, but I don’t know why, it does not return a reply, but it is ok to switch to bpf_redirect. If there is any big If you know the reason, please let me know, thank you" (I'm using Google Translate)
=> I also encounter the same problem when using bpf_redirect_peer. All the packets go to the pod dest veth but there aren't any reply messages.
=> I'm using eBPF to trace, the handler of the IP layer - ip_rcv drop all the packets with bpf_redirect_peer
=> Any ideas why this happens? I believe that every thing is fine: MAC, IP of source and dest
I still don't know the cause of this problem. I have tried asking some people who are good at Cilium, but I did not get an answer. If you happen to know the cause someday, please let me know. Thank you very much :pray:
@y805939188 hi, I'v just found out the issue. I don't know if this works for you. Somehow in the kernel when processing in vxlan device, the skb->pkt_type is set to PACKET_OTHERHOST, when processed by ip_rcv_core function, it will be dropped. My solution is to set the pkt_type to PACKET_HOST => it will not be dropped anymore. Just add bpf_skb_change_type(skb, PACKET_HOST); before the bpf_redirect_peer. Please let me know if this solves your problem.
@y805939188 hi, I'v just found out the issue. I don't know if this works for you. Somehow in the kernel when processing in vxlan device, the skb->pkt_type is set to PACKET_OTHERHOST, when processed by ip_rcv_core function, it will be dropped. My solution is to set the pkt_type to PACKET_HOST => it will not be dropped anymore. Just add bpf_skb_change_type(skb, PACKET_HOST); before the bpf_redirect_peer. Please let me know if this solves your problem.
It seems to be able to work! I noticed also that the PACKET_HOST is heavily used in cilium. I should take the time to study the difference between them. Thank you very much~🙏
I was trying to use bpf_redirect_peer to redirect packets from one veth (not a VXLAN device) to another veth, and it also failed. The bpf_skb_change_type(skb, PACKET_HOST) solved my problem, too. So I think this problem has nothing to do with VXLAN.
