Description of problem: Setting up an ocp-3.9 cluster which is using flannel network, found it couldn't resolve domain name from the pod. [root@ip-172-18-7-127 ~]# oc rsh docker-registry-1-bhghf sh-4.2$ curl www.google.com curl: (6) Could not resolve host: www.google.com; Unknown error It looks like a same issue with BZ#1490820, which was fixed along with BZ#1493955. Checked the iptables rules on master and node, the required rules in BZ#1493955 are both added, but the domain name resolution still not work. The full iptables rules list on the master could be found in attachment. Also tried the workaround in https://bugzilla.redhat.com/show_bug.cgi?id=1490820#c0, adding the following iptables rules could solve the issue. # iptables -A OS_FIREWALL_ALLOW -p tcp -m state --state NEW -m tcp --dport 53 -j ACCEPT # iptables -A OS_FIREWALL_ALLOW -p udp -m state --state NEW -m udp --dport 53 -j ACCEPT Version-Release number of the following components: openshift-ansible-3.9.2-1.git.0.1a855b3.el7.noarch.rpm How reproducible: Always Steps to Reproduce: 1. Enable flannel network used in ocp-3.9, check the pod openshift_use_openshift_sdn=false openshift_use_flannel=true Actual results: Please include the entire output from the last TASK line through the end of output if an error is generated Expected results: Additional info: Please attach logs from ansible-playbook with the -vvv flag
Created attachment 1404244 [details] iptables rules
Created https://github.com/openshift/openshift-ansible/pull/7380
Fix is available in openshift-ansible-3.9.4-1
Verify this bug with openshift-ansible-3.9.4-1.git.0.a49cc04.el7.noarch.rpm. After deploy a 3.9 cluster with flannel network, pod could access the external network successfully. [root@ip-172-18-4-216 ~]# oc rsh docker-registry-1-qbrkn sh-4.2$ ping www.google.com PING www.google.com (172.217.8.4) 56(84) bytes of data. 64 bytes from iad23s59-in-f4.1e100.net (172.217.8.4): icmp_seq=1 ttl=47 time=1.37 ms 64 bytes from iad23s59-in-f4.1e100.net (172.217.8.4): icmp_seq=2 ttl=47 time=1.45 ms
Move it to verified according to Comment 4
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2018:1566