Description of problem: In ipv6 deployment the ExternalInterfaceDefaultRoute gets configured with ipv4 formatted destination network. [root@overcloud-controller-0 ~]# cat /etc/sysconfig/network-scripts/route-vlan10 0.0.0.0/0 via 2001:db8:fd00:1000:dead:beef:cafe:f00 dev vlan10 This should be: ::/0 via 2001:db8:fd00:1000:dead:beef:cafe:f00 dev vlan10 Version-Release number of selected component (if applicable): I'm doing the test following the instructions in: https://etherpad.openstack.org/p/tripleo-ipv6-support How reproducible: 100% Steps to Reproduce: 1. Deploy ipv6 enabled overcloud 2. cat /etc/sysconfig/network-scripts/route-vlan10 3. Actual results: 0.0.0.0/0 via 2001:db8:fd00:1000:dead:beef:cafe:f00 dev vlan10 There is no default route installed on the controller node: [root@overcloud-controller-0 heat-admin]# ip -6 r | grep default [root@overcloud-controller-0 heat-admin]# ip r | grep default [root@overcloud-controller-0 heat-admin]# Expected results: ::/0 via 2001:db8:fd00:1000:dead:beef:cafe:f00 dev vlan10
I think you can make these modifications to support IPv6 default route on controller: controller.yaml: - type: vlan vlan_id: {get_param: ExternalNetworkVlanID} addresses: - ip_netmask: {get_param: ExternalIpSubnet} routes: - ip_netmask: 0.0.0.0/0 next_hop: {get_param: ExternalInterfaceDefaultRoute} Change the ip_netmask from 0.0.0.0/0 to ::/0
(In reply to Dan Sneddon from comment #1) We might also want to have an IPv4 default route on the controllers, in which case the single-nic templates for the controller would look like this: network_config: - type: ovs_bridge name: {get_input: bridge_name} use_dhcp: false dns_servers: {get_param: DnsServers} addresses: - ip_netmask: list_join: - '/' - - {get_param: ControlPlaneIp} - {get_param: ControlPlaneSubnetCidr} routes: - ip_netmask: 169.254.169.254/32 next_hop: {get_param: EC2MetadataIp} - ip_netmask: 0.0.0.0/0 # IPv4 default gateway next_hop: 192.168.0.1 # IP of Undercloud members: - type: interface name: nic1 # force the MAC address of the bridge to this interface primary: true - type: vlan vlan_id: {get_param: ExternalNetworkVlanID} addresses: - ip_netmask: {get_param: ExternalIpSubnet} routes: - ip_netmask: ::/0 # IPv6 default gateway next_hop: {get_param: ExternalInterfaceDefaultRoute}
I applied the changes suggested in comment#2 to have default routes for both ipv4 and ipv6 subnets. The ipv4 one got installed correctly but the ipv6 one didn't. It appears that the following init script gets created for the ipv6 default route: /etc/sysconfig/network-scripts/route-vlan10 ::/0 via 2001:db8:fd00:1000:dead:beef:cafe:f00 dev vlan10 When doing ifup vlan10 I got this error: Error: an inet prefix is expected rather than "::/0". It looks that the correct initscript name should be: /etc/sysconfig/network-scripts/route6-vlan10 This installed the ipv6 default route correctly.
(In reply to Marius Cornea from comment #3) > This installed the ipv6 default route correctly. We need to have the new os-net-config packaged before we can do IPv6 static routes. I am working on a new version of the controller.yaml NIC config that has both ExternalNetworkDefaultRoute (IPv6) and ControlPlaneDefaultRoute (IPv4).
Hi Dan, I've just noticed a nit in the single-nic-vlans/controller-v6.yaml provided by openstack-tripleo-heat-templates-0.8.6-111.el7ost.noarch: routes: - ip_netmask: 169.254.169.254/32 next_hop: {get_param: EC2MetadataIp} - default: true ip_netmask: {get_param: ControlPlaneDefaultRoute} <- should be next_hop routes: - ip_netmask: 0.0.0.0/0 <- should be ::/0 next_hop: {get_param: ExternalInterfaceDefaultRoute} I'm not sure if this is the right solution but it got me pass an os-net-config error about missing next hop and resulted in both ipv4 and ipv6 default routes installed on the overcloud controller nodes.
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://rhn.redhat.com/errata/RHBA-2016-0264.html