Bug 1377701

(In reply to Benjamin Schmaus from comment #0)
> Description of problem:
> 
> We need a backport of the following upstream bug fixed in Liberty for
> OSP7(Kilo):
> 
> https://bugs.launchpad.net/neutron/+bug/1466322
> https://review.openstack.org/#/c/195014/
> 
> $ neutron subnet-show 86f65d74-c9aa-4c70-aa0a-485e4418571f
> +-------------------+--------------------------------------------------------
> ---------------------------+
> | Field             | Value                                                 
> |
> +-------------------+--------------------------------------------------------
> ---------------------------+
> | allocation_pools  | {"start": "fd00:4888:2000:2000:1000::a", "end":
> "fd00:4888:2000:2000:1000::7fff"} |
> | cidr              | fd00:4888:2000:2000:1000::/112                        
> |
> | dns_nameservers   |                                                       
> |
> | enable_dhcp       | True                                                  
> |
> | gateway_ip        | fd00:4888:2000:2000:1000::1                           
> |
> | host_routes       |                                                       
> |
> | id                | 86f65d74-c9aa-4c70-aa0a-485e4418571f                  
> |
> | ip_version        | 6                                                     
> |
> | ipv6_address_mode |                                                       
> |
> | ipv6_ra_mode      |                                                       
> |
> | name              | Subnet-Test-IPv6                                      
> |
> | network_id        | 34520264-e156-4316-a5a6-d0ebd1ef334a                  
> |
> | subnetpool_id     |                                                       
> |
> | tenant_id         | 9b53d02871d94a349c93c5965179cfa5                      
> |
> +-------------------+--------------------------------------------------------
> ---------------------------+
> $ neutron subnet-update 86f65d74-c9aa-4c70-aa0a-485e4418571f --gateway_ip
> fd00:4888:2000:2000:1000::
> Invalid input for operation: Gateway is not valid on subnet.
> 
> 
> Version-Release number of selected component (if applicable):
> OSP7
> 
> How reproducible:
> 100%
> 
> Steps to Reproduce:
> 1.Create IPv6 subnet
> 2.Try to assign first or last IP as gateway
> 3.
> 
> Actual results:
> Cannot assign IP address
> 
> Expected results:
> Should be able to assign ipaddress
> 
> Additional info:

We'll backport the patch - Keep in mind that it talks only about the last IP address in the subnet, not the first, so the backport will not cover that.

@Amuller - is there any reason why we could not get the first IP address as well?  Is there a limitation I am not readily seeing?

@Sridhar, please see comment 3.

It will need more work than just to cherrypick the given commit: That commit alters the new IPAM reference implementation that was introduced in Liberty, while the request is for Kilo.

(In reply to Benjamin Schmaus from comment #3)
> @Amuller - is there any reason why we could not get the first IP address as
> well?  Is there a limitation I am not readily seeing?

@Benjamin, AFAIU the problem was only with the last_ip (as IPv6 does not have broadcast address) and not the first_ip. 
We can configure the gateway_ip as the first ip in the subnet CIDR and this is the default behavior (i.e., when gateway is not specified, its configured to the first_ip in the subnet).

(In reply to Sridhar Gaddam from comment #6)
> (In reply to Benjamin Schmaus from comment #3)
> > @Amuller - is there any reason why we could not get the first IP address as
> > well?  Is there a limitation I am not readily seeing?
> 
> @Benjamin, AFAIU the problem was only with the last_ip (as IPv6 does not
> have broadcast address) and not the first_ip. 
> We can configure the gateway_ip as the first ip in the subnet CIDR and this
> is the default behavior (i.e., when gateway is not specified, its configured
> to the first_ip in the subnet).

I think the intention by the customer is to use the network address of the network. From comment 0:

neutron subnet-update 86f65d74-c9aa-4c70-aa0a-485e4418571f --gateway_ip fd00:4888:2000:2000:1000::

Ok, this looks like a requirement to support "Subnet-Router anycast address[*]" and I hope the expectation from Neutron is to allow this configuration for the gateway_ip (and NOT for the hosts).
Please correct me if this is not the case.

According to the RFC [**], a router is expected to recognize the "Subnet-Router anycast address" as its own address and I've seen that Linux supports it (i.e., even when we do not explicitly configure this address on the qr-interface, Neutron router would respond to Neighbor Solicitation requests for the subnet-router anycast address). 
However, the following blog [3] mentions that the subnet-router anycast address is not used by applications like ssh[4]. 
I quickly verified the behavior with iperf (tcp server running on the Neutron router) and tried to connect to it using the subnet-router anycast address from one of the VMs. 
It does not seem to work (UDP server/client seems to work).
So, its good to check the impact of certain use-cases like HA router where we run keepalived process. 

BTW, there was a related bug that was reported in Neutron [5], but it was not pursued. So, the fix is also required on the master.

[1] https://tools.ietf.org/html/rfc4291#section-2.6.1
[2] https://tools.ietf.org/html/rfc4291#section-2.8
[3] http://into6.com.au/?p=467
[4] "Interestingly, none of these operating systems seem to do anything useful with the subnet router anycast addresses – they don’t, for example, listen on those addresses for ssh connections, but they do respond to pings."
[5] https://bugs.launchpad.net/neutron/+bug/1356926

This bugzilla has been removed from the release and needs to be reviewed and Triaged for another Target Release.