yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #91509
[Bug 2011687] [NEW] O flag is not enabled when ipv6_ra_mode is dhcpv6-stateful
Public bug reported:
* Summary (Bug title): keep it small, possibly one line.
When ipv6_ra_mode is dhcpv6-stateful, both M flag and O flag should be 1, but actually only M flag is 1 and O flag is 0 in router advertisement packets.
ml2/OVS and ml2/OVN have the same behavior.
* High level description: provide a brief sentence (a couple of lines) of what are you trying to accomplish, or would like to accomplish differently.
According to the following document, both M flag and O flag will be 1
when ipv6_ra_mode is dhcpv6-stateful.
https://docs.openstack.org/neutron/latest/admin/config-ipv6.html
> Setting DHCPv6-stateless for ipv6_ra_mode configures the neutron router with an radvd agent to send
> Router Advertisements. The list below captures the values set for the address configuration
> flags in the Router Advertisement messages in this scenario. Similarly, setting DHCPv6-
> stateless for ipv6_address_mode configures neutron DHCP implementation to provide the additional network information.
> - Autonomous Address Configuration Flag = 1
> - Managed Address Configuration Flag = 0
> - Other Configuration Flag = 1
But actually only M flag is 1 and O flag is 0.
This behavior comes from the following implementations:
ML2/OVS
https://github.com/openstack/neutron/blob/f545c002dc699f849026ccd1bad403b2933373aa/neutron/agent/linux/ra.py#L53-L55
ML2/OVN
https://github.com/ovn-org/ovn/blob/a5238e6234d17e119dca952d9e43c36dce057d5e/controller/pinctrl.c#L3733-L3734
https://github.com/ovn-org/ovn/blob/a5238e6234d17e119dca952d9e43c36dce057d5e/lib/actions.c#L3349-L3350
I tested a RHEL 8 instance and the instance could obtain DNS server information from DHCPv6 even though O flag is 0.
Therefore some kind of operating system is not affected even if O flag is 0.
But actually there is a difference between the document and actual behavior.
Which one is correct and which should I modify?
* Pre-conditions: what is the initial state of your system? Please consider enumerating resources available in the system, if useful in diagnosing the problem. Who are you? A regular tenant or a super-user? Are you describing service-to-service interaction?
ml2/OVS or ml2/OVN
* Step-by-step reproduction steps: CLI commands or API requests are great; please, consider using http://paste.openstack.org for long outputs.
I confirmed this behavior on Train-based-OpenStack (Red Hat OpenStack
Platform 16.2)
1. Deploy OpenStack with ml2/OVS or ml2/OVN
2. Create a router and a tenant network/subnet with ipv6_stateful by the following commands
openstack network create ipv6_stateful
openstack subnet create --ip-version 6 --ipv6-address-mode dhcpv6-stateful --ipv6-ra-mode dhcpv6-stateful --network ipv6_stateful --subnet-range fc00:2::/64 ipv6_stateful --gateway fc00:2::1 --dns-nameserver 2001:4860:4860::8888
openstack router create router1
openstack router add subnet router1 ipv6_stateful
3. Create an instance on the network
openstack server create --flavor flavor --image rhel-8.2-290 --network
ipv6_stateful --security-group sg --key-name keypair ipv6_stateful
4. Take packet capture of Router Advertisement packets on the instance
* Expected output: what did you hope to see?
Both M flag and O flag are 1,
* Actual output: did the system silently fail (in this case log traces are useful)?
Only M flag is 1 and O flag is 0.
* Version:
I confirmed this behavior on Train-based-OpenStack (Red Hat OpenStack Platform 16.2)
But as far as I checked the implementation, the latest version should have the same behavior.
* Perceived severity: is this a blocker for you?
Serverity is low.
I just wander why there is the difference between document and actual behavior.
* Attachments: consider attaching logs, truncated log snippets are rarely useful.
The following is the excerpt of actual packet captures.
<ML2/OVN>
~~~
Internet Control Message Protocol v6
Type: Router Advertisement (134)
Code: 0
Checksum: 0x2a73 [correct]
[Checksum Status: Good]
Cur hop limit: 255
Flags: 0x80, Managed address configuration, Prf (Default Router Preference): Medium
1... .... = Managed address configuration: Set
.0.. .... = Other configuration: Not set
..0. .... = Home Agent: Not set
...0 0... = Prf (Default Router Preference): Medium (0)
.... .0.. = Proxy: Not set
.... ..0. = Reserved: 0
Router lifetime (s): 65535
Reachable time (ms): 0
Retrans timer (ms): 0
ICMPv6 Option (Source link-layer address : fa:16:3e:de:92:07)
Type: Source link-layer address (1)
Length: 1 (8 bytes)
Link-layer address: fa:16:3e:de:92:07 (fa:16:3e:de:92:07)
ICMPv6 Option (MTU : 1442)
Type: MTU (5)
Length: 1 (8 bytes)
Reserved
MTU: 1442
ICMPv6 Option (Prefix information : fc00:2::/64)
Type: Prefix information (3)
Length: 4 (32 bytes)
Prefix Length: 64
Flag: 0x80, On-link flag(L)
1... .... = On-link flag(L): Set
.0.. .... = Autonomous address-configuration flag(A): Not set
..0. .... = Router address flag(R): Not set
...0 0000 = Reserved: 0
Valid Lifetime: Infinity (4294967295)
Preferred Lifetime: Infinity (4294967295)
Reserved
Prefix: fc00:2::
~~~
<ml2/OVS>
~~~
Internet Control Message Protocol v6
Type: Router Advertisement (134)
Code: 0
Checksum: 0x986a [correct]
[Checksum Status: Good]
Cur hop limit: 64
Flags: 0x80, Managed address configuration, Prf (Default Router Preference): Medium
1... .... = Managed address configuration: Set
.0.. .... = Other configuration: Not set
..0. .... = Home Agent: Not set
...0 0... = Prf (Default Router Preference): Medium (0)
.... .0.. = Proxy: Not set
.... ..0. = Reserved: 0
Router lifetime (s): 300
Reachable time (ms): 0
Retrans timer (ms): 0
ICMPv6 Option (Prefix information : fc00:2::/64)
Type: Prefix information (3)
Length: 4 (32 bytes)
Prefix Length: 64
Flag: 0x80, On-link flag(L)
1... .... = On-link flag(L): Set
.0.. .... = Autonomous address-configuration flag(A): Not set
..0. .... = Router address flag(R): Not set
...0 0000 = Reserved: 0
Valid Lifetime: 86400
Preferred Lifetime: 14400
Reserved
Prefix: fc00:2::
ICMPv6 Option (MTU : 1450)
Type: MTU (5)
Length: 1 (8 bytes)
Reserved
MTU: 1450
ICMPv6 Option (Source link-layer address : fa:16:3e:a6:2f:3d)
Type: Source link-layer address (1)
Length: 1 (8 bytes)
Link-layer address: fa:16:3e:a6:2f:3d (fa:16:3e:a6:2f:3d)
~~~
** Affects: neutron
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/2011687
Title:
O flag is not enabled when ipv6_ra_mode is dhcpv6-stateful
Status in neutron:
New
Bug description:
* Summary (Bug title): keep it small, possibly one line.
When ipv6_ra_mode is dhcpv6-stateful, both M flag and O flag should be 1, but actually only M flag is 1 and O flag is 0 in router advertisement packets.
ml2/OVS and ml2/OVN have the same behavior.
* High level description: provide a brief sentence (a couple of lines) of what are you trying to accomplish, or would like to accomplish differently.
According to the following document, both M flag and O flag will be 1
when ipv6_ra_mode is dhcpv6-stateful.
https://docs.openstack.org/neutron/latest/admin/config-ipv6.html
> Setting DHCPv6-stateless for ipv6_ra_mode configures the neutron router with an radvd agent to send
> Router Advertisements. The list below captures the values set for the address configuration
> flags in the Router Advertisement messages in this scenario. Similarly, setting DHCPv6-
> stateless for ipv6_address_mode configures neutron DHCP implementation to provide the additional network information.
> - Autonomous Address Configuration Flag = 1
> - Managed Address Configuration Flag = 0
> - Other Configuration Flag = 1
But actually only M flag is 1 and O flag is 0.
This behavior comes from the following implementations:
ML2/OVS
https://github.com/openstack/neutron/blob/f545c002dc699f849026ccd1bad403b2933373aa/neutron/agent/linux/ra.py#L53-L55
ML2/OVN
https://github.com/ovn-org/ovn/blob/a5238e6234d17e119dca952d9e43c36dce057d5e/controller/pinctrl.c#L3733-L3734
https://github.com/ovn-org/ovn/blob/a5238e6234d17e119dca952d9e43c36dce057d5e/lib/actions.c#L3349-L3350
I tested a RHEL 8 instance and the instance could obtain DNS server information from DHCPv6 even though O flag is 0.
Therefore some kind of operating system is not affected even if O flag is 0.
But actually there is a difference between the document and actual behavior.
Which one is correct and which should I modify?
* Pre-conditions: what is the initial state of your system? Please consider enumerating resources available in the system, if useful in diagnosing the problem. Who are you? A regular tenant or a super-user? Are you describing service-to-service interaction?
ml2/OVS or ml2/OVN
* Step-by-step reproduction steps: CLI commands or API requests are great; please, consider using http://paste.openstack.org for long outputs.
I confirmed this behavior on Train-based-OpenStack (Red Hat OpenStack
Platform 16.2)
1. Deploy OpenStack with ml2/OVS or ml2/OVN
2. Create a router and a tenant network/subnet with ipv6_stateful by the following commands
openstack network create ipv6_stateful
openstack subnet create --ip-version 6 --ipv6-address-mode dhcpv6-stateful --ipv6-ra-mode dhcpv6-stateful --network ipv6_stateful --subnet-range fc00:2::/64 ipv6_stateful --gateway fc00:2::1 --dns-nameserver 2001:4860:4860::8888
openstack router create router1
openstack router add subnet router1 ipv6_stateful
3. Create an instance on the network
openstack server create --flavor flavor --image rhel-8.2-290
--network ipv6_stateful --security-group sg --key-name keypair
ipv6_stateful
4. Take packet capture of Router Advertisement packets on the instance
* Expected output: what did you hope to see?
Both M flag and O flag are 1,
* Actual output: did the system silently fail (in this case log traces are useful)?
Only M flag is 1 and O flag is 0.
* Version:
I confirmed this behavior on Train-based-OpenStack (Red Hat OpenStack Platform 16.2)
But as far as I checked the implementation, the latest version should have the same behavior.
* Perceived severity: is this a blocker for you?
Serverity is low.
I just wander why there is the difference between document and actual behavior.
* Attachments: consider attaching logs, truncated log snippets are rarely useful.
The following is the excerpt of actual packet captures.
<ML2/OVN>
~~~
Internet Control Message Protocol v6
Type: Router Advertisement (134)
Code: 0
Checksum: 0x2a73 [correct]
[Checksum Status: Good]
Cur hop limit: 255
Flags: 0x80, Managed address configuration, Prf (Default Router Preference): Medium
1... .... = Managed address configuration: Set
.0.. .... = Other configuration: Not set
..0. .... = Home Agent: Not set
...0 0... = Prf (Default Router Preference): Medium (0)
.... .0.. = Proxy: Not set
.... ..0. = Reserved: 0
Router lifetime (s): 65535
Reachable time (ms): 0
Retrans timer (ms): 0
ICMPv6 Option (Source link-layer address : fa:16:3e:de:92:07)
Type: Source link-layer address (1)
Length: 1 (8 bytes)
Link-layer address: fa:16:3e:de:92:07 (fa:16:3e:de:92:07)
ICMPv6 Option (MTU : 1442)
Type: MTU (5)
Length: 1 (8 bytes)
Reserved
MTU: 1442
ICMPv6 Option (Prefix information : fc00:2::/64)
Type: Prefix information (3)
Length: 4 (32 bytes)
Prefix Length: 64
Flag: 0x80, On-link flag(L)
1... .... = On-link flag(L): Set
.0.. .... = Autonomous address-configuration flag(A): Not set
..0. .... = Router address flag(R): Not set
...0 0000 = Reserved: 0
Valid Lifetime: Infinity (4294967295)
Preferred Lifetime: Infinity (4294967295)
Reserved
Prefix: fc00:2::
~~~
<ml2/OVS>
~~~
Internet Control Message Protocol v6
Type: Router Advertisement (134)
Code: 0
Checksum: 0x986a [correct]
[Checksum Status: Good]
Cur hop limit: 64
Flags: 0x80, Managed address configuration, Prf (Default Router Preference): Medium
1... .... = Managed address configuration: Set
.0.. .... = Other configuration: Not set
..0. .... = Home Agent: Not set
...0 0... = Prf (Default Router Preference): Medium (0)
.... .0.. = Proxy: Not set
.... ..0. = Reserved: 0
Router lifetime (s): 300
Reachable time (ms): 0
Retrans timer (ms): 0
ICMPv6 Option (Prefix information : fc00:2::/64)
Type: Prefix information (3)
Length: 4 (32 bytes)
Prefix Length: 64
Flag: 0x80, On-link flag(L)
1... .... = On-link flag(L): Set
.0.. .... = Autonomous address-configuration flag(A): Not set
..0. .... = Router address flag(R): Not set
...0 0000 = Reserved: 0
Valid Lifetime: 86400
Preferred Lifetime: 14400
Reserved
Prefix: fc00:2::
ICMPv6 Option (MTU : 1450)
Type: MTU (5)
Length: 1 (8 bytes)
Reserved
MTU: 1450
ICMPv6 Option (Source link-layer address : fa:16:3e:a6:2f:3d)
Type: Source link-layer address (1)
Length: 1 (8 bytes)
Link-layer address: fa:16:3e:a6:2f:3d (fa:16:3e:a6:2f:3d)
~~~
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/2011687/+subscriptions
Follow ups
