** Description changed: When booting with ipv6.disable=1, vxlan will fail to initialize with the error "vxlan: Cannot bind port 4789, err=-97" which is EAFNOSUPPORT. Expected result is that vxlan tunnels work when ipv6 is disabled. Description: Ubuntu 16.04.4 LTS Release: 16.04 linux-image-4.4.0-124-generic bug is fixed in RHEL in https://bugzilla.redhat.com/show_bug.cgi?id=1445054 + + Steps to reproduce: + + Deploy two identical 14.04 nodes with the following configuration: + + Add the following to /etc/default/grub then run 'sudo update-grub' + GRUB_CMDLINE_LINUX_DEFAULT="ipv6.disable=1" + + Reboot both nodes + sudo reboot + + Set up a tunnel using the following commands on each node modifying + remote_ip to be the ip of the other node. modify veth0 ip to be subnet + using the tunnel 10.10.10.x/24 + + ovs-vsctl del-port br-int vx1 + ovs-vsctl del-port br-int veth1 + ip link del veth0 + + ovs-vsctl add-port br-int vx1 -- set interface vx1 type=vxlan options:remote_ip=192.168.122.161 + # remote_ip should be the ip of the other node + + ip link add type veth + ip link set veth0 up + ip link set veth1 up + ovs-vsctl add-port br-int veth1 + ip addr add 10.10.10.2/24 dev veth0 # on the second node use 10.10.10.3/24 + + Expected result is once the tunnel is configured on each side, you + should be able to ping the ip of veth0 on the remote side while ipv6 is + disabled. + + ping 10.10.10.2 or 10.10.10.3, whichever is the remote side.
** Description changed: - When booting with ipv6.disable=1, vxlan will fail to initialize with the - error "vxlan: Cannot bind port 4789, err=-97" which is EAFNOSUPPORT. + When booting with ipv6.disable=1, vxlan tunnels will fail to initialize + with the error "vxlan: Cannot bind port 4789, err=-97" which is + EAFNOSUPPORT. Expected result is that vxlan tunnels work when ipv6 is disabled. Description: Ubuntu 16.04.4 LTS Release: 16.04 linux-image-4.4.0-124-generic bug is fixed in RHEL in https://bugzilla.redhat.com/show_bug.cgi?id=1445054 Steps to reproduce: Deploy two identical 14.04 nodes with the following configuration: - Add the following to /etc/default/grub then run 'sudo update-grub' - GRUB_CMDLINE_LINUX_DEFAULT="ipv6.disable=1" + Add the following to /etc/default/grub then run 'sudo update-grub' + GRUB_CMDLINE_LINUX_DEFAULT="ipv6.disable=1" Reboot both nodes - sudo reboot + sudo reboot Set up a tunnel using the following commands on each node modifying remote_ip to be the ip of the other node. modify veth0 ip to be subnet using the tunnel 10.10.10.x/24 - ovs-vsctl del-port br-int vx1 - ovs-vsctl del-port br-int veth1 - ip link del veth0 + ovs-vsctl del-port br-int vx1 + ovs-vsctl del-port br-int veth1 + ip link del veth0 - ovs-vsctl add-port br-int vx1 -- set interface vx1 type=vxlan options:remote_ip=192.168.122.161 - # remote_ip should be the ip of the other node + ovs-vsctl add-port br-int vx1 -- set interface vx1 type=vxlan options:remote_ip=192.168.122.161 + # remote_ip should be the ip of the other node - ip link add type veth - ip link set veth0 up - ip link set veth1 up - ovs-vsctl add-port br-int veth1 - ip addr add 10.10.10.2/24 dev veth0 # on the second node use 10.10.10.3/24 + ip link add type veth + ip link set veth0 up + ip link set veth1 up + ovs-vsctl add-port br-int veth1 + ip addr add 10.10.10.2/24 dev veth0 # on the second node use 10.10.10.3/24 Expected result is once the tunnel is configured on each side, you should be able to ping the ip of veth0 on the remote side while ipv6 is disabled. ping 10.10.10.2 or 10.10.10.3, whichever is the remote side. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1771301 Title: Setting ipv6.disable=1 prevents both IPv4 and IPv6 socket opening for VXLAN tunnels To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1771301/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
