when I tried to delve into the traffic path of the Istio Ambient Mesh, I found two rather bizarre issues. For the sake of discussion, let me first present a scenario:
- There are 2 nodes in the cluster, NA and NB;
- there are 2 pods in the cluster, the sleep application and the httpbin application, which are located on NA and NB respectively;
- executing curl to access httpbin within sleep pod.
Question 1: When I capture packets on the NB node using tcpdump, I found that only the first packet passes through istioin and enters the ztunnel Pod. Later, where the other packets after it enter the ztunnel pod through the ztunnel's veth. Why is this? I think the first packet matches the routing rule in routing table 100 (a routing rule like this: 10.244.1.7 via 192.168.126.2 dev istioin src 10.244.1.1), but this condition should also apply to subsequent packets, right? Did I miss something?
Question 2: When the packets from the httpbin response enter the ztunnel pod on the NB node, why can they be received by the ztunnel process? I mean, the destination address of this packet is the sleep pod's address + random port number. I have repeatedly checked the iptables rules and routing tables in the ztunnel pod on the NB node, and it seems that this packet should hit this iptables rule:
-A PREROUTING ! -d 10.244.1.3/32 -i eth0 -p tcp -j MARK --set-xmark 0x4d3/0xfff
then hit the policy routing rule:
20003: from all fwmark 0x4d3/0xfff lookup 100
and then enter routing table 100. But there is only one rule in table 100:
local default dev lo scope host
It seems that this rule will only match packets sent to the local host, so this packet should not be matched. Based on my research on the routing table, my guess for the path is that it matches this rule in the main routing table:
default via 10.244.1.1 dev eth0.
But my question is, if that's the case, the packet seems to leave the ztunnel pod through eth0, but why can the ztunnel pod correctly receive it?
