What is this behaviour that I cannot connect smoothly and selectivly blocked domains on new ubuntu vm

I have been working on ubuntu installed in virtual box to practice kubernetes. But today I spotted this behaviour becase I was not able to pull image from docker.

Here is what happens: I am trying to connect to internet from my headless ubuntu as it is kube worker node running on vm. So I did some test shown below as pulling image wasn’t working.

root@kube-worker-node:/etc/network# ping google.com PING google.com (142.250.178.14) 56(84) bytes of data. 64 bytes from lhr48s27-in-f14.1e100.net (142.250.178.14): icmp_seq=1 ttl=117 time=11.5 ms 64 bytes from lhr48s27-in-f14.1e100.net (142.250.178.14): icmp_seq=2 ttl=117 time=26.1 ms 64 bytes from lhr48s27-in-f14.1e100.net (142.250.178.14): icmp_seq=3 ttl=117 time=12.2 ms ^C --- google.com ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2005ms rtt min/avg/max/mdev = 11.508/16.611/26.111/6.723 ms root@kube-worker-node:/etc/network# ping google.com ^C root@kube-worker-node:/etc/network# root@kube-worker-node:/etc/network# ping google.com ^C root@kube-worker-node:/etc/network# /etc/init.d/networking restart [ ok ] Restarting networking (via systemctl): networking.service. root@kube-worker-node:/etc/network# ping google.com PING google.com (142.250.178.14) 56(84) bytes of data. 64 bytes from lhr48s27-in-f14.1e100.net (142.250.178.14): icmp_seq=1 ttl=117 time=78.8 ms 64 bytes from lhr48s27-in-f14.1e100.net (142.250.178.14): icmp_seq=2 ttl=117 time=14.1 ms 64 bytes from lhr48s27-in-f14.1e100.net (142.250.178.14): icmp_seq=3 ttl=117 time=14.0 ms 64 bytes from lhr48s27-in-f14.1e100.net (142.250.178.14): icmp_seq=4 ttl=117 time=14.4 ms ^C --- google.com ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3003ms rtt min/avg/max/mdev = 14.076/30.373/78.846/27.986 ms root@kube-worker-node:/etc/network# ping google.com PING google.com (142.250.178.14) 56(84) bytes of data. 64 bytes from lhr48s27-in-f14.1e100.net (142.250.178.14): icmp_seq=1 ttl=117 time=18.4 ms 64 bytes from lhr48s27-in-f14.1e100.net (142.250.178.14): icmp_seq=2 ttl=117 time=19.2 ms 64 bytes from lhr48s27-in-f14.1e100.net (142.250.178.14): icmp_seq=3 ttl=117 time=14.8 ms ^C --- google.com ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 14.859/17.533/19.247/1.918 ms root@kube-worker-node:/etc/network# ping google.com PING google.com (142.250.178.14) 56(84) bytes of data. 64 bytes from lhr48s27-in-f14.1e100.net (142.250.178.14): icmp_seq=1 ttl=117 time=12.1 ms 64 bytes from lhr48s27-in-f14.1e100.net (142.250.178.14): icmp_seq=2 ttl=117 time=61.5 ms ^C --- google.com ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1002ms rtt min/avg/max/mdev = 12.103/36.847/61.592/24.745 ms root@kube-worker-node:/etc/network# ping google.com ^C root@kube-worker-node:/etc/network# ping google.com PING google.com (142.250.178.14) 56(84) bytes of data. 64 bytes from lhr48s27-in-f14.1e100.net (142.250.178.14): icmp_seq=1 ttl=117 time=11.5 ms 64 bytes from lhr48s27-in-f14.1e100.net (142.250.178.14): icmp_seq=2 ttl=117 time=12.5 ms 64 bytes from lhr48s27-in-f14.1e100.net (142.250.178.14): icmp_seq=3 ttl=117 time=18.2 ms 64 bytes from lhr48s27-in-f14.1e100.net (142.250.178.14): icmp_seq=4 ttl=117 time=13.7 ms ^C --- google.com ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3007ms rtt min/avg/max/mdev = 11.566/14.016/18.216/2.541 ms root@kube-worker-node:/etc/network# ping google.com PING google.com (142.250.178.14) 56(84) bytes of data. 64 bytes from lhr48s27-in-f14.1e100.net (142.250.178.14): icmp_seq=1 ttl=117 time=11.2 ms 64 bytes from lhr48s27-in-f14.1e100.net (142.250.178.14): icmp_seq=2 ttl=117 time=13.6 ms 64 bytes from lhr48s27-in-f14.1e100.net (142.250.178.14): icmp_seq=3 ttl=117 time=14.3 ms ^C --- google.com ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 11.282/13.096/14.345/1.319 ms root@kube-worker-node:/etc/network# ping google.com ping: google.com: Temporary failure in name resolution root@kube-worker-node:/etc/network# cat /etc/resolv.conf nameserver 1.1.1.1 root@kube-worker-node:/etc/network# ping google.com --- google.com ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3004ms rtt min/avg/max/mdev = 11.569/12.695/15.146/1.430 ms root@kube-worker-node:/etc/network# ping google.com PING google.com (142.250.178.14) 56(84) bytes of data. 64 bytes from lhr48s27-in-f14.1e100.net (142.250.178.14): icmp_seq=1 ttl=117 time=10.7 ms 64 bytes from lhr48s27-in-f14.1e100.net (142.250.178.14): icmp_seq=26 ttl=117 time=2085 ms 64 bytes from lhr48s27-in-f14.1e100.net (142.250.178.14): icmp_seq=27 ttl=117 time=1063 ms 64 bytes from lhr48s27-in-f14.1e100.net (142.250.178.14): icmp_seq=28 ttl=117 time=39.7 ms 64 bytes from lhr48s27-in-f14.1e100.net (142.250.178.14): icmp_seq=34 ttl=117 time=11.3 ms 64 bytes from lhr48s27-in-f14.1e100.net (142.250.178.14): icmp_seq=35 ttl=117 time=16.4 ms 64 bytes from lhr48s27-in-f14.1e100.net (142.250.178.14): icmp_seq=36 ttl=117 time=13.1 ms 64 bytes from lhr48s27-in-f14.1e100.net (142.250.178.14): icmp_seq=61 ttl=117 time=1031 ms ^C --- google.com ping statistics --- 117 packets transmitted, 32 received, 72% packet loss, time 118107ms rtt min/avg/max/mdev = 10.716/315.739/2761.864/674.438 ms, pipe 3 root@kube-worker-node:/etc/network# ping registry-1.docker.io ping: registry-1.docker.io: Temporary failure in name resolution root@kube-worker-node:/etc/network# ping registry-1.docker.io PING registry-1.docker.io (52.72.232.213) 56(84) bytes of data. ^C --- registry-1.docker.io ping statistics --- 727 packets transmitted, 0 received, 100% packet loss, time 743443ms root@kube-worker-node:/etc/network# ping registry-1.docker.io PING registry-1.docker.io (52.20.56.50) 56(84) bytes of data. ^C --- registry-1.docker.io ping statistics --- 12 packets transmitted, 0 received, 100% packet loss, time 11272ms root@kube-worker-node:/etc/network# ping docker.io ping: docker.io: Temporary failure in name resolution root@kube-worker-node:/etc/network# ping google.com PING google.com (142.250.178.14) 56(84) bytes of data. 64 bytes from lhr48s27-in-f14.1e100.net (142.250.178.14): icmp_seq=1 ttl=117 time=11.7 ms 64 bytes from lhr48s27-in-f14.1e100.net (142.250.178.14): icmp_seq=4 ttl=117 time=13.3 ms 64 bytes from lhr48s27-in-f14.1e100.net (142.250.178.14): icmp_seq=42 ttl=117 time=2181 ms 64 bytes from lhr48s27-in-f14.1e100.net (142.250.178.14): icmp_seq=43 ttl=117 time=1159 ms 64 bytes from lhr48s27-in-f14.1e100.net (142.250.178.14): icmp_seq=44 ttl=117 time=134 ms 64 bytes from lhr48s27-in-f14.1e100.net (142.250.178.14): icmp_seq=45 ttl=117 time=13.6 ms 

I have disabled systemd-resoved. and I have unlinked /etc/resolve.conf and set

nameserver 1.1.1.1

What I want is to be able to pull image from docker registry . a simple google ping works with hickups and ping to docker registry completel fails as shown in above tests.

due to this issue I have not been able to practice on Kuberentes this weekend. Any help will be greatly appreciated.

submitted by /u/vitachaos
[link] [comments]


Go to Source of this post
Author Of this post: /u/vitachaos
Title Of post: What is this behaviour that I cannot connect smoothly and selectivly blocked domains on new ubuntu vm
Author Link: {authorlink}