-
Notifications
You must be signed in to change notification settings - Fork 190
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
In the same cluster of Submariner, my non-gateway node vxlan interface cannot ping the gateway node's vxlan interface. #3134
Comments
Only icmp reqest ,no reply |
root@c2-worker:/# ip -d link show vx-submariner |
-A SUBMARINER-POSTROUTING -s 240.0.0.0/8 -o vx-submariner -j SNAT --to-source 10.9.0.1 When I delete this iptables rule, everything works fine. I don't quite understand why this message is needed. Doesn't this make the vxlan tunnel encapsulation ineffective? |
A. Submariner implements the egress part for inter-cluster traffic and lets the CNI handle ingress direction (after IPsec decryption). A.1 So, for podA@non_gw_node@clusterA to communicate with podB@non_gw_node@clusterB , A.2 CNI should forward the packet to podB@non_gw_node@clusterB B.
This rule is used to support communication from HostNetwork pods (that use node's IP address) to remoteCluster, so SRC ip address is SNATed to node's CNI interface IP. C. Did you try checking inter-cluster connectivity between clusters ? you can use subctl verify |
@yboaron Thank you for your answer~ |
Submariner implements inter-cluster connectivity and by design egress part is handled by Submariner while the CNI is supposed to handle ingress, so the connectivity between vx-submariner interfaces on different nodes in the same cluster should not work as you noticed and it is expected. Can you elaborate on why you are checking connectivity within a cluster via vx-submariner interfaces? is this for troubleshooting inter-cluster data path connectivity issue ? |
I have this requirement in my use, but I already know the solution, thank you, I will close this issue |
What happened:
In the same cluster of Submariner, my non-gateway node vxlan interface cannot ping the gateway node's vxlan interface.
What you expected to happen:
I hope these two nodes can ping
How to reproduce it (as minimally and precisely as possible):
Anything else we need to know?:
**Only request packet** but no reply I also deployed it in AWS EKS and had the same problemEnvironment:
subctl diagnose all
):subctl gather
):✓ Gathering connectivity resources
✓ Gathering CNI data from 2 pods matching label selector "app=submariner-routeagent"
✓ Gathering CNI data from 1 pods matching label selector "app=submariner-gateway"
✓ Gathering cable driver data from 1 pods matching label selector "app=submariner-gateway"
✓ Found 2 endpoints in namespace "submariner-operator"
✓ Found 2 clusters in namespace "submariner-operator"
✓ Found 1 gateways in namespace "submariner-operator"
✓ Found 0 clusterglobalegressips in namespace ""
✓ Found 0 globalegressips in namespace ""
✓ Found 0 globalingressips in namespace ""
✓ Gathering connectivity logs
✓ Found 1 pods matching label selector "app=submariner-gateway"
✓ Found 2 pods matching label selector "app=submariner-routeagent"
✓ Found 1 pods matching label selector "app=submariner-metrics-proxy"
✓ Found 0 pods matching label selector "app=submariner-globalnet"
✓ Found 0 pods matching label selector "app=submariner-addon"
✓ Gathering service-discovery resources
✓ Found 2 serviceexports in namespace ""
✓ Found 4 serviceimports in namespace ""
✓ Found 2 endpointslices by label selector "endpointslice.kubernetes.io/managed-by=lighthouse-agent.submariner.io" in namespace ""
✓ Found 1 configmaps by label selector "component=submariner-lighthouse" in namespace "submariner-operator"
✓ Found 1 configmaps by field selector "metadata.name=coredns" in namespace "kube-system"
✓ Found 0 services by label selector "submariner.io/exportedServiceRef" in namespace ""
✓ Gathering service-discovery logs
✓ Found 3 pods matching label selector "component=submariner-lighthouse"
✓ Found 2 pods matching label selector "k8s-app=kube-dns"
✓ Gathering broker resources
✓ Found 2 endpoints in namespace "submariner-k8s-broker"
✓ Found 2 clusters in namespace "submariner-k8s-broker"
✓ Found 2 endpointslices by label selector "endpointslice.kubernetes.io/managed-by=lighthouse-agent.submariner.io" in namespace "submariner-k8s-broker"
✓ Found 2 serviceimports in namespace "submariner-k8s-broker"
✓ Gathering broker logs
✓ Gathering operator resources
✓ Found 1 submariners in namespace "submariner-operator"
✓ Found 1 servicediscoveries in namespace "submariner-operator"
✓ Found 1 deployments by field selector "metadata.name=submariner-operator" in namespace "submariner-operator"
✓ Found 1 daemonsets by label selector "app=submariner-gateway" in namespace "submariner-operator"
✓ Found 1 daemonsets by label selector "app=submariner-metrics-proxy" in namespace "submariner-operator"
✓ Found 1 daemonsets by label selector "app=submariner-routeagent" in namespace "submariner-operator"
✓ Found 0 daemonsets by label selector "app=submariner-globalnet" in namespace "submariner-operator"
✓ Found 1 deployments by label selector "app=submariner-lighthouse-agent" in namespace "submariner-operator"
✓ Found 1 deployments by label selector "app=submariner-lighthouse-coredns" in namespace "submariner-operator"
✓ Gathering operator logs
✓ Found 1 pods matching label selector "name=submariner-operator"
Files are stored under directory "submariner-20240820141854/kind-c2"
subctl
The text was updated successfully, but these errors were encountered: