You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Run the command tcpdum -i veth1 -nve on the test Node.
Run the command curl <Service IP>:<Service Port> within the test client Pod. The request should succeed because we use a pair of veth interfaces, with nothing being between the interfaces. The output of tcpdum is:
10.10.0.2 is the IP of the test client Pod.
10.10.0.3 is the IP of the test server Pod.
10.108.178.224 is the IP of the Service.
Similar to #6854, the issue is that the captured packets do not belong to the same connection, potentially being dropped by the engine like Suricata. This is because the reply packets should not be 'DNATed' before redirecting to veth0.
Describe the bug
TrafficControls with redirect action don't handle Service connections correctly.
To Reproduce
Create a pair of veth interfaces and enable them on a K8s Node:
Create a test client Pod, a test server Pod and a Service selecting the server Pod as backend.
Create a TrafficControl and apply it.
Run the command
tcpdum -i veth1 -nve
on the test Node.Run the command
curl <Service IP>:<Service Port>
within the test client Pod. The request should succeed because we use a pair of veth interfaces, with nothing being between the interfaces. The output of tcpdum is:Similar to #6854, the issue is that the captured packets do not belong to the same connection, potentially being dropped by the engine like Suricata. This is because the reply packets should not be 'DNATed' before redirecting to veth0.
The text was updated successfully, but these errors were encountered: