Skip to content
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

N6 internet connectivity #61

Closed
amrbaraka opened this issue Oct 28, 2022 · 8 comments
Closed

N6 internet connectivity #61

amrbaraka opened this issue Oct 28, 2022 · 8 comments
Labels
cni Issues related to k8s CNI

Comments

@amrbaraka
Copy link

amrbaraka commented Oct 28, 2022

First, thank you for the published deployment & configuration details, following the instructions I've been able to deploy the UPF successfully on minikube on top of AWS EC2 ubuntu.

image

image

Now I'm facing the following issue:

First, I tried to use ping to test N6 connectivity towards the internet, but apparently iputils-ping is not part of UPF image.

image

So I tried apt-get update, and that's when I realized that internet connectivity is NOK:

image

You can see below that all interfaces are UP:

image

IP Routes:

image

I also removed the secondary default route manually "to keep only n6 as default route" but still internet reacheability failed:

image

Knowing that, the UPF is able to reach its n6 designated gw 192.168.49.1 (which is the IP of minikube bridge created on AWS ec2)

I verified this via ping from the bridge interface on ec2:

image

image

Any ideas what could be going wrong?

Thanks in advance for your help & support.

Br,
Amr

@amrbaraka
Copy link
Author

So I've realized that it's a DNS issue.
I've installed an alpine container with eth0 calico and n6 network attachment., where I've noticed that ping to the internet is working only towards direct IPs and fails for domain names.
/etc/resolve.conf points to kube-dns pod cluster IP:

/ # cat /etc/resolv.conf
nameserver 10.96.0.10
search free5gc.svc.cluster.local svc.cluster.local cluster.local eu-central-1.compute.internal
options ndots:5

And this is the coredns configmap:
<<<
kubectl -n kube-system get cm coredns -o yaml
apiVersion: v1
data:
Corefile: |
.:53 {
errors
health {
lameduck 5s
}
ready
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
fallthrough in-addr.arpa ip6.arpa
ttl 30
}
prometheus :9153
hosts {
192.168.49.1 host.minikube.internal
fallthrough
}
forward . /etc/resolv.conf {
max_concurrent 1000
}
cache 30
loop
reload
loadbalance
}
kind: ConfigMap

When I changed the nameserver to 8.8.8.8 inside the alpine test container, the DNS resolution succeeds 50% of the time,,
which is really strange,,

I also checked IP tables and added this rule to both minikube container and the ec2 instance iptables:
sudo iptables -I DOCKER-USER -j ACCEPT

but still no change.

Here's a tcpdump during DNS query failure:

/ # tcpdump -v -i n6
tcpdump: listening on n6, link-type EN10MB (Ethernet), snapshot length 262144 bytes
23:51:25.879423 IP (tos 0x0, ttl 64, id 61996, offset 0, flags [DF], proto UDP (17), length 56)
alpine.56107 > dns.google.53: 40095+ A? medium.com. (28)
23:51:25.879467 IP (tos 0x0, ttl 64, id 61997, offset 0, flags [DF], proto UDP (17), length 56)
alpine.56107 > dns.google.53: 41171+ AAAA? medium.com. (28)
23:51:28.380764 IP (tos 0x0, ttl 64, id 61998, offset 0, flags [DF], proto UDP (17), length 56)
alpine.56107 > dns.google.53: 40095+ A? medium.com. (28)
23:51:28.380823 IP (tos 0x0, ttl 64, id 61999, offset 0, flags [DF], proto UDP (17), length 56)
alpine.56107 > dns.google.53: 41171+ AAAA? medium.com. (28)
23:51:28.456841 IP (tos 0x0, ttl 64, id 55706, offset 0, flags [DF], proto UDP (17), length 66)
192.168.49.101.46484 > dns.google.53: 4320+ PTR? 8.8.8.8.in-addr.arpa. (38)
23:51:28.458253 IP (tos 0x0, ttl 117, id 29601, offset 0, flags [none], proto UDP (17), length 90)
dns.google.53 > 192.168.49.101.46484: 4320 1/0/0 8.8.8.8.in-addr.arpa. PTR dns.google. (62)
23:51:30.898029 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.49.1 tell 192.168.49.101, length 28
23:51:30.898392 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.49.1 is-at 02:42:08:b2:fc:15 (oui Unknown), length 28
23:51:30.974570 IP (tos 0x0, ttl 64, id 55851, offset 0, flags [DF], proto UDP (17), length 73)
192.168.49.101.34128 > dns.google.53: 10314+ PTR? 101.49.168.192.in-addr.arpa. (45)
23:51:30.975529 IP (tos 0x0, ttl 54, id 62126, offset 0, flags [none], proto UDP (17), length 73)
dns.google.53 > 192.168.49.101.34128: 10314 NXDomain 0/0/0 (45)
23:51:30.978078 IP (tos 0x0, ttl 64, id 55852, offset 0, flags [DF], proto UDP (17), length 71)
192.168.49.101.37200 > dns.google.53: 4779+ PTR? 1.49.168.192.in-addr.arpa. (43)
23:51:30.979422 IP (tos 0x0, ttl 54, id 54314, offset 0, flags [none], proto UDP (17), length 71)
dns.google.53 > 192.168.49.101.37200: 4779 NXDomain 0/0/0 (43)
23:51:33.714016 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.49.101 tell 192.168.49.1, length 28
23:51:33.714052 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.49.101 is-at ae:bd:e6:be:28:d8 (oui Unknown), length 28

192.168.49.101 is the container n6 interface IP
192.168.49.1 is the minikube bridge interface IP which is the gw for the n6 interface.

Any ideas what's causing DNS resolution failure from the pods ?

@amrbaraka
Copy link
Author

So, I've added these entries to /etc/hosts:
91.189.91.38 archive.ubuntu.com
91.189.91.38 security.ubuntu.com

The connection worked towards the internet, and I was able to install iputils-ping and ping worked:

root@free5gc-upf-upf-589c67bf5-9lgx8:/free5gc/upf# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=111 time=1.39 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=111 time=2.45 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=111 time=2.55 ms

Has this DNS issue been seen/reported before?

It might be a minikube issue, there seem to be some similar issues reported earlier:
kubernetes/minikube#8949

@rveerama1
Copy link

@amrbaraka is N6 internet connectivity working now for you now? I am also stuck at N6 internet connectivity issue.

@amrbaraka
Copy link
Author

@amrbaraka is N6 internet connectivity working now for you now? I am also stuck at N6 internet connectivity issue.

@rveerama1 is it the same symptoms as in my description ? i.e ping command from inside the pod is not available and DNS resolution failure when executing apt-get update,,, please also keep in mind that I was able to ping the n6 interface from it's default gw (which is the IP of minikube bridge created on AWS ec2)

if yes, then you can append the below entries to /etc/hosts of the UPF:
echo '91.189.91.38 archive.ubuntu.com' >> /etc/hosts
echo '91.189.91.38 security.ubuntu.com' >> /etc/hosts

Afterwards, I was able to execute apt-get update and install iputils-ping pkg and I was able to test the ping towards the internet,, which worked fine in case of IPs, but still failed for domain names, so I installed vim and set 8.8.8.8 as my DNS server under /ets/resolv.conf and it worked.

Br,
Amr

@rveerama1
Copy link

@amrbaraka thanks for the reply. I reported my issue #62.

I could do "apt update" and "apt install " inside UPF. but

"kubectl --namespace sim exec -it $POD_NAME -- ping -c 1 -I uesimtun0 www.google.com" doesn't work.

I tried pinging from inside UPF too.

root@test-free5gc-upf-upf-6485b99bf9-8p6qr:/free5gc/upf# ping -I n6 -c 1 www.google.com
PING www.google.com (172.217.169.36) from 192.168.0.3 n6: 56(84) bytes of data.

--- www.google.com ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

@amrbaraka
Copy link
Author

@rveerama1 I've just suggested a modification in your config in issue #62
hope it works!

Br,
Amr

@rveerama1
Copy link

@amrbaraka thank you.

@amrbaraka
Copy link
Author

closing the issue.

@raoufkh raoufkh added the cni Issues related to k8s CNI label Mar 21, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cni Issues related to k8s CNI
Projects
None yet
Development

No branches or pull requests

3 participants