# Kubernetes: Pod-to-Node Communication Loss

This post goes over what happens if we misconfigure etcd and flannel to use the same network (e.g., “10.252.61.0/16”) as the infrastructure (e.g., “10.252.158.72” node). This newbie mistake is rare but very perplexing and this post shows how to troubleshoot it with busybox container.

### Problem symptoms

From a pod (e.g., jenkins) on one node (e.g., 10.252.158.71), we cannot communicate with another node (e.g., 10.252.158.72) even though two nodes can communicate with each other normally.

Even more perplexing, the pod-to-pod communication is fine (as described right below), even though the second pod is on the same node (e.g., 10.252.158.72) that the first pod cannot communciate to.

### Troubleshooting with busybox

Try to run a test pod busybox. jenkins pod can ping the busybox pod, but not the node that busybox pod is running on.

In this case, we would use traceroute from the busybox container to determine when the packets are dropped. 10.252.158.72 is IP of the VM. 10.252.100.5 is the IP of the jenkins pod.

For the context, 10.252.100.5 is the IP of the service, as shown in the command below.

### What went wrong?

It’s a newbie mistake when configuring Kubernetes. When setting up etcd and configuring it to hold flannel configuration, it is important to pick an unused network. I made a mistake for using 10.252.61.0/16 for flannel when some of my kubernetes nodes has IPs as “10.252.xxx.xxx”. As a result, kube-proxy services intercept the traffic from the container and thinks its a virtual traffic since my node IP happens to be in the same subnet with flanneld. This leads to pod-to-VM communication loss as described above. The solution is simply reset flanneld with another subnet after resetting configruation value in etcd to “172.17.0.0/16”.

After this, we can reset and restart flannel services on all nodes to use the new network overlay configuration.