Description of problem: When a stateless security group is attached to the instance it fails to get an IPv6 address using SLAAC or stateless DHCP. An explicit rule is required to allow ICMPv6 traffic. Checked with the custom security group (only egress traffic is allowed) as well as with the default security group (egress and ingress from the same SG are allowed). Version-Release number of selected component (if applicable): RHOS-17.1-RHEL-9-20221115.n.2 Red Hat Enterprise Linux release 9.1 (Plow) How reproducible: 100% Steps to Reproduce: openstack network create net_dual_slaac openstack subnet create --subnet-range 10.100.1.0/24 --network net_dual_slaac subnet_dual_slaac openstack subnet create --subnet-range 2001:0:0:1::0/64 --ip-version 6 --ipv6-ra-mode slaac --ipv6-address-mode slaac --network net_dual_slaac subnet_dual_slaac_ipv6 openstack router create router_test_boot EXT_NET=`openstack network list --external -f value -c Name` openstack router set --external-gateway $EXT_NET router_test_boot openstack router add subnet router_test_boot subnet_dual_slaac openstack security group create --stateless test_sg openstack server create --image <IMG> --flavor <FLAV> --network net_dual_slaac --security-group test_sg vm_1 Actual results: only IPv4 address appear on the instance Expected results: IPv6 address is expected Additional info: can be worked around by adding icmpv6 rule: # openstack security group rule create --ingress --protocol icmpv6 test_sg
DHCPv6 should work by default for stateless SGs, same as for stateful.
Status update: 1) patches are posted in upstream; 2) upstream reviewers (Slawek and Rodolfo) suggested that this topic needs more elaboration and discussion since they don't necessarily agree with the assumption that both metadata and ipv6 dhcp should work by default for stateless SGs; (I disagree) 3) they suggested to have a discussion on this topic during the vPTG this week; specifically, this Wed at 9am EST we'll discuss this exact topic; 4) once we have a resolution on what can be implemented upstream, I will work on adjusting the existing patches to upstream (if needed) this Friday. Note that the above suggests that we may not have the bug fixed as expected in the test plan; at least upstream. So we may have to adjust the test plan maybe? The discussion this Wed should clarify what's possible in upstream.
I now believe that the bug is not for Neutron to fix (though it's technically possible). It's an inconsistency between "pure stateless" and "mixed-stateful" networks in OVN northd implementation. This should be fixed by: https://patchwork.ozlabs.org/project/ovn/list/?series=350425 (currently on review). This bug should probably become a test tracker for a clone to ovn component where the actual fix belongs.
The series are merged in upstream and backported in upstream to LTS. I'll need to chase the backport downstream before closing this bz.
This should be fixed once we pull in fdp repo that includes: ovn22.12-22.12.0-50.el9fdp | ovn22.12-22.12.0-50.el8fdp No explicit SG rules should be defined now for RA / NA procedures to work for ipv6 addressing. No changes to neutron were needed, the fix is in OVN.
Moving to on QA the fix available in compose: RHOS-17.1-RHEL-9-20230426.n.1 tripleo-admin@controller-0 ~]$ sudo su [root@controller-0 tripleo-admin]# podman exec -it -u root ovn_controller /bin/bash [root@controller-0 /]# rpm -qa | grep ovn ovn22.12-22.12.0-51.el9fdp.x86_64 rhosp-ovn-22.12-2.el9ost.noarch ovn22.12-host-22.12.0-51.el9fdp.x86_64 rhosp-ovn-host-22.12-2.el9ost.noarch