[openstack-dev] neutron ipv6 radvd sends out link-local or nothing as def gw (L3 HA issue?)

[Tobias Urdin]

Hello,

Note: before reading, this router was a regular router but was then 
disable, changed ha=true so it's now a L3 HA router, then it was enabled 
again.

CC openstack-dev for help or feedback if it's a possible bug.

I've been testing around with IPv6 and overall the experience has been 
positive but I've met some weird issue that I cannot put my head around.
So this is a neutron L3 router with an outside interface with a ipv4 and 
ipv6 from the provider network and one inside interface for ipv4 and one 
inside interface for ipv6.


The instances for some reason get's there default gateway as the ipv6 
link-local (in fe80::/10) from the router with SLAAC and radvd.


(. is provider network, . is inside network, they are 
masked so don't pay attention to the number per se)


*interfaces inside router:*
15: ha-9bde1bb1-bd:  mtu 1450 qdisc 
noqueue state UNKNOWN group default qlen 1000

    link/ether fa:16:3e:05:80:32 brd ff:ff:ff:ff:ff:ff
    inet 169.254.192.7/18 brd 169.254.255.255 scope global ha-9bde1bb1-bd
   valid_lft forever preferred_lft forever
    inet 169.254.0.1/24 scope global ha-9bde1bb1-bd
   valid_lft forever preferred_lft forever
    inet6 fe80::f816:3eff:fe05:8032/64 scope link
   valid_lft forever preferred_lft forever
19: qg-86e465f6-33:  mtu 1500 qdisc 
noqueue state UNKNOWN group default qlen 1000

    link/ether fa:16:3e:3b:8b:a5 brd ff:ff:ff:ff:ff:ff
    inet 1.2.3.4/22 scope global qg-86e465f6-33
   valid_lft forever preferred_lft forever
    inet6 :::f/64 scope global nodad
   valid_lft forever preferred_lft forever
    inet6 fe80::f816:3eff:fe3b:8ba5/64 scope link nodad
   valid_lft forever preferred_lft forever
1168: qr-5be04815-68:  mtu 1450 qdisc 
noqueue state UNKNOWN group default qlen 1000

    link/ether fa:16:3e:c3:85:bd brd ff:ff:ff:ff:ff:ff
    inet 192.168.99.1/24 scope global qr-5be04815-68
   valid_lft forever preferred_lft forever
    inet6 fe80::f816:3eff:fec3:85bd/64 scope link
   valid_lft forever preferred_lft forever
1169: qr-7fad6b1b-c9:  mtu 1450 qdisc 
noqueue state UNKNOWN group default qlen 1000

    link/ether fa:16:3e:66:de:a8 brd ff:ff:ff:ff:ff:ff
    inet6 ::0:1::1/64 scope global nodad
   valid_lft forever preferred_lft forever
    inet6 fe80::f816:3eff:fe66:dea8/64 scope link
   valid_lft forever preferred_lft forever

I get this error messages in dmesg on the network node:
[581085.858869] IPv6: qr-5be04815-68: IPv6 duplicate address 
::0:1:f816:3eff:fec3:85bd detected!
[581085.997497] IPv6: qr-7fad6b1b-c9: IPv6 duplicate address 
::0:1:f816:3eff:fe66:dea8 detected!
[581142.869939] IPv6: qr-5be04815-68: IPv6 duplicate address 
::0:1:f816:3eff:fec3:85bd detected!
[581143.182371] IPv6: qr-7fad6b1b-c9: IPv6 duplicate address 
::0:1:f816:3eff:fe66:dea8 detected!


*radvd:*
interface qr-7fad6b1b-c9
{
   AdvSendAdvert on;
   MinRtrAdvInterval 30;
   MaxRtrAdvInterval 100;

   AdvLinkMTU 1450;

   RDNSS  2001:4860:4860::  {};

   prefix ::0:1::/64
   {
    AdvOnLink on;
    AdvAutonomous on;
   };
};

*inside instance:*
ipv4 = 192.168.199.7
ipv6 = ::0:1:f816:3eff:fe29:723d/64 (from radvd SLAAC)

I can ping ipv4 gateway 192.168.199.1 and internet over ipv4.
I can ping ipv6 gateway ::0:1::1 but I can't ping the internet

checking the ipv6 routing table on my instance I either get no default 
gateway at all or I get a default gateway to a fe80::/10 link-local address.

IIRC this worked before I changed the router to a L3 HA router.

Appreciate any feedback!

Best regards
Tobias
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] [IPv6] [radvd] Advertise tenant prefixes from router to outside

[Carl Baldwin]

On Fri, Dec 18, 2015 at 12:54 PM, Vladimir Eremin  wrote:
> Hi Carl,
>
> As far as I understand Address Scopes, end user’s algorithm will be next:
> 1. Administrator creates an address scope and associate an IPv6 subnet pool 
> with it.
> 2. Administrator creates Public shared network’s subnet from this subnet pool.
> 3. Tenant user creates tenant network from this subnet pool and connect it to 
> Public shared network with router
> 4. OpenStack advertises prefix to the external interface of the router.

Yes, this sounds like the right way to do it.  As long as we implement
step 4 to be address scope aware, what you describe here will work.

There is some flexibility to attach multiple subnet pools to the same
address scope.  This would allow a particular tenant to have exclusive
access to a pool under the right scope.

Carl

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] [IPv6] [radvd] Advertise tenant prefixes from router to outside

[Vladimir Eremin]

Hi Carl,

As far as I understand Address Scopes, end user’s algorithm will be next: 
1. Administrator creates an address scope and associate an IPv6 subnet pool 
with it.
2. Administrator creates Public shared network’s subnet from this subnet pool.
3. Tenant user creates tenant network from this subnet pool and connect it to 
Public shared network with router
4. OpenStack advertises prefix to the external interface of the router.

-- 
With best regards,
Vladimir Eremin,
Fuel Deployment Engineer,
Mirantis, Inc.



> On Dec 17, 2015, at 8:21 PM, Carl Baldwin  wrote:
> 
> On Thu, Dec 17, 2015 at 4:09 PM, Vladimir Eremin  wrote:
>> Hi Carl,
>> 
>> I’ll fil RFE for sure, thank you for the link to the process )
>> 
>> So actually, we should announce all SUBNETS we’ve attached to router. 
>> Otherwise is will not work, because external network router will have no 
>> idea, where the traffic should be routed back. It is an actual viability 
>> discriminator: subnets, that doesn’t attached are counting as unviable to 
>> the external network context.
> 
> The subnets attached to the router which are not controlled by a
> subnet pool come straight from the user and there is no validation of
> the addresses used, no overlap prevention, nor any other kind of
> control.  We can't leave it up to tenants to advertise whatever
> subnets they want to to the external network.  The advertisements must
> be limited to subnets allocated to the tenant by the operator of the
> cloud with some mechanism for preventing overlap of addresses between
> subnets.
> 
> A subnet that has an address scope was allocated from a pool defined
> under that scope.  We know where the address came from and that it
> will not overlap any other subnet in the same scope.
> 
> For subnets that don't meet this criteria, their traffic should not
> even be routed out to the external network in the first place let
> alone get a route back to the router.  The address pools blueprint
> covers this too.
> 
>> BTW, could you please point me to the spec for address scopes.
> 
> Sure:  https://blueprints.launchpad.net/neutron/+spec/address-scopes
> 
> Carl
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] [IPv6] [radvd] Advertise tenant prefixes from router to outside

[Vladimir Eremin]

Hi

For now, when end user is creating IPv6-enabled tenant network and attaching it 
to the virtual router, there is only way to set up external infrastructure to 
put traffic back to the router is using DHCPv6 PD[1], unfortunately, it’s not 
working at all[2]. Other methods like implementing BGP is still in development.

BTW, in IPv6 Router Advertisements we have an option called Route Information 
Option, RA-RIO[3] to advertise more specific routes from gateway. We could 
easily append a section like next one to advertise tenant prefix 
2001:db8:1::/64 to public network. And if provider network router outside 
OpenStack will be configured to accept these.

interface qg- {
AdvDefaultLifetime 0;
route 2001:db8:1::/64 {
};
};

Cisco accepts it by default AFAIK, linux needs a sysctl 
net.ipv6.conf.*.accept_ra_rt_info_max_plen set to 64.

Moreover, enabling receiving RA-RIO prefixes in router namespaces allows 
routers communicate by themselves.

I’ve done PoC patch for it https://gist.github.com/yottatsa/8282e670da16934960b3


[1]: 
http://specs.openstack.org/openstack/neutron-specs/specs/kilo/ipv6-prefix-delegation.html
[2]: https://bugs.launchpad.net/neutron/+bug/1505316
[3]: https://tools.ietf.org/html/rfc4191

-- 
With best regards,
Vladimir Eremin,
Fuel Deployment Engineer,
Mirantis, Inc.




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] [IPv6] [radvd] Advertise tenant prefixes from router to outside

[Carl Baldwin]

On Thu, Dec 17, 2015 at 1:30 PM, Vladimir Eremin  wrote:
> Hi
>
> For now, when end user is creating IPv6-enabled tenant network and attaching 
> it to the virtual router, there is only way to set up external infrastructure 
> to put traffic back to the router is using DHCPv6 PD[1], unfortunately, it’s 
> not working at all[2]. Other methods like implementing BGP is still in 
> development.
>
> BTW, in IPv6 Router Advertisements we have an option called Route Information 
> Option, RA-RIO[3] to advertise more specific routes from gateway. We could 
> easily append a section like next one to advertise tenant prefix 
> 2001:db8:1::/64 to public network. And if provider network router outside 
> OpenStack will be configured to accept these.
>
> interface qg- {
> AdvDefaultLifetime 0;
> route 2001:db8:1::/64 {
> };
> };
>
> Cisco accepts it by default AFAIK, linux needs a sysctl 
> net.ipv6.conf.*.accept_ra_rt_info_max_plen set to 64.
>
> Moreover, enabling receiving RA-RIO prefixes in router namespaces allows 
> routers communicate by themselves.
>
> I’ve done PoC patch for it 
> https://gist.github.com/yottatsa/8282e670da16934960b3

This is an interesting idea.  I've wondered if we could do something
like this before but I didn't know all the details around RA-RIO.  The
problem is that, in general, we have no idea if the subnets behind the
routers are viable in the external network context.  So, we can't just
blindly have routers advertising whatever.

In Mitaka, we're merging a new feature called "address scopes".  We
could limit advertising to only subnets that come from the address
scope matching that of the external network.  If we do this then we'll
know that the subnet came from a pool of addresses that are valid in
the external network context and that the addresses are unique.

This could be relatively easy to implement on top of the current
address scopes work.  I think this is worth exploring with an RFE.
Would you mind filing an RFE according to the Neutron process [1]?

Carl

[1] 
http://docs.openstack.org/developer/neutron/policies/blueprints.html#neutron-request-for-feature-enhancements

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] [IPv6] [radvd] Advertise tenant prefixes from router to outside

[Vladimir Eremin]

Hi Carl,

I’ll fil RFE for sure, thank you for the link to the process )

So actually, we should announce all SUBNETS we’ve attached to router. Otherwise 
is will not work, because external network router will have no idea, where the 
traffic should be routed back. It is an actual viability discriminator: 
subnets, that doesn’t attached are counting as unviable to the external network 
context.

BTW, could you please point me to the spec for address scopes.

-- 
With best regards,
Vladimir Eremin,
Fuel Deployment Engineer,
Mirantis, Inc.



> On Dec 17, 2015, at 1:13 PM, Carl Baldwin  wrote:
> 
> On Thu, Dec 17, 2015 at 1:30 PM, Vladimir Eremin  wrote:
>> Hi
>> 
>> For now, when end user is creating IPv6-enabled tenant network and attaching 
>> it to the virtual router, there is only way to set up external 
>> infrastructure to put traffic back to the router is using DHCPv6 PD[1], 
>> unfortunately, it’s not working at all[2]. Other methods like implementing 
>> BGP is still in development.
>> 
>> BTW, in IPv6 Router Advertisements we have an option called Route 
>> Information Option, RA-RIO[3] to advertise more specific routes from 
>> gateway. We could easily append a section like next one to advertise tenant 
>> prefix 2001:db8:1::/64 to public network. And if provider network router 
>> outside OpenStack will be configured to accept these.
>> 
>> interface qg- {
>>AdvDefaultLifetime 0;
>>route 2001:db8:1::/64 {
>>};
>> };
>> 
>> Cisco accepts it by default AFAIK, linux needs a sysctl 
>> net.ipv6.conf.*.accept_ra_rt_info_max_plen set to 64.
>> 
>> Moreover, enabling receiving RA-RIO prefixes in router namespaces allows 
>> routers communicate by themselves.
>> 
>> I’ve done PoC patch for it 
>> https://gist.github.com/yottatsa/8282e670da16934960b3
> 
> This is an interesting idea.  I've wondered if we could do something
> like this before but I didn't know all the details around RA-RIO.  The
> problem is that, in general, we have no idea if the subnets behind the
> routers are viable in the external network context.  So, we can't just
> blindly have routers advertising whatever.
> 
> In Mitaka, we're merging a new feature called "address scopes".  We
> could limit advertising to only subnets that come from the address
> scope matching that of the external network.  If we do this then we'll
> know that the subnet came from a pool of addresses that are valid in
> the external network context and that the addresses are unique.
> 
> This could be relatively easy to implement on top of the current
> address scopes work.  I think this is worth exploring with an RFE.
> Would you mind filing an RFE according to the Neutron process [1]?
> 
> Carl
> 
> [1] 
> http://docs.openstack.org/developer/neutron/policies/blueprints.html#neutron-request-for-feature-enhancements
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] [IPv6] [radvd] Advertise tenant prefixes from router to outside

[Carl Baldwin]

On Thu, Dec 17, 2015 at 4:09 PM, Vladimir Eremin  wrote:
> Hi Carl,
>
> I’ll fil RFE for sure, thank you for the link to the process )
>
> So actually, we should announce all SUBNETS we’ve attached to router. 
> Otherwise is will not work, because external network router will have no 
> idea, where the traffic should be routed back. It is an actual viability 
> discriminator: subnets, that doesn’t attached are counting as unviable to the 
> external network context.

The subnets attached to the router which are not controlled by a
subnet pool come straight from the user and there is no validation of
the addresses used, no overlap prevention, nor any other kind of
control.  We can't leave it up to tenants to advertise whatever
subnets they want to to the external network.  The advertisements must
be limited to subnets allocated to the tenant by the operator of the
cloud with some mechanism for preventing overlap of addresses between
subnets.

A subnet that has an address scope was allocated from a pool defined
under that scope.  We know where the address came from and that it
will not overlap any other subnet in the same scope.

For subnets that don't meet this criteria, their traffic should not
even be routed out to the external network in the first place let
alone get a route back to the router.  The address pools blueprint
covers this too.

> BTW, could you please point me to the spec for address scopes.

Sure:  https://blueprints.launchpad.net/neutron/+spec/address-scopes

Carl

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][IPv6] This week's meeting

[Sean M. Collins]

I am on PTO - if someone else wishes to chair the weekly meeting please feel 
free to do so.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][IPv6] Prefix delegation and user facing API thoughts

[John Belamaric]

On 3/18/15, 9:12 PM, Sean M. Collins s...@coreitpro.com wrote:


 My hope is that either the new IPAM subsystem for subnet allocations
would provide this, or that a small API extension could paper over some
of the sharper edges.

In IPAM we have added this concept of a subnet request. The built-in
support would allow you to request any subnet or a specific subnet.
This concept applies to both pool-based and non-pool-based requests.

Currently, a request needs to be essentially encoded in the cidr field
of the subnet creation API call, in order to provide complete API
backwards compatibility. A blank CIDR indicates any subnet; a specific
CIDR indicates to allocate that subnet. However, the intention is that
individual drivers could add their own types of requests. This is
supported in the request factory defined in [1]. This means, for example,
we can implement a request class RFC3633SubnetRequest that handles
acquiring the CIDR via prefix delegation. The user will pass RFC3633 as
the cidr attribute in that case, so that the correct request class is
instantiated. A similar mechanism can be used for address requests - for
example, EUI64 and other auto-generated addresses.

To enable this, an additional change needed beyond [1] is to use the
request factory for validation of the cidr field rather than the API
layer.


[1] https://review.openstack.org/#/c/153236/25/neutron/ipam/__init__.py



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][IPv6] Prefix delegation and user facing API thoughts

[John Davidge (jodavidg)]

Following discussion on IRC, a patch is now up to add this config option.
Reviews appreciated.

https://review.openstack.org/#/c/166973/


Cheers,

John




On 23/03/2015 18:11, Carl Baldwin c...@ecbaldwin.net wrote:

On Mon, Mar 23, 2015 at 12:04 PM, John Davidge (jodavidg)
jodav...@cisco.com wrote:
 The above blueprint outlines an admin-configurable global default pool
to
 be used in the case of a user calling subnet-create without specifying a
 CIDR or subnet-pool ID. If the OpenStack environment has been made
 PD-capable by the operator (a PD-server has been setup), this default
 could be set in such a way to indicate that PD should be used. This
would
 give the user a hassle-free workflow and avoids overloading api
 attributes. It also has the added benefit of not allowing the user to
 request a PD-defined CIDR in an environment that isn¹t PD-capable.

Thank you for bringing up this default.  This was indeed specified in
the BP for this purpose.  However, it is a loose end which we need to
tied up.  It should be easy to add the code to enable setting this
default.  We also need to be sure that our subnet pool code properly
ignores this pool id.

Ping me on IRC and we can coordinate this.

Carl

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][IPv6] Prefix delegation and user facing API thoughts

[Carl Baldwin]

On Mon, Mar 23, 2015 at 12:04 PM, John Davidge (jodavidg)
jodav...@cisco.com wrote:
 The above blueprint outlines an admin-configurable global default pool to
 be used in the case of a user calling subnet-create without specifying a
 CIDR or subnet-pool ID. If the OpenStack environment has been made
 PD-capable by the operator (a PD-server has been setup), this default
 could be set in such a way to indicate that PD should be used. This would
 give the user a hassle-free workflow and avoids overloading api
 attributes. It also has the added benefit of not allowing the user to
 request a PD-defined CIDR in an environment that isn¹t PD-capable.

Thank you for bringing up this default.  This was indeed specified in
the BP for this purpose.  However, it is a loose end which we need to
tied up.  It should be easy to add the code to enable setting this
default.  We also need to be sure that our subnet pool code properly
ignores this pool id.

Ping me on IRC and we can coordinate this.

Carl

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][IPv6] Prefix delegation and user facing API thoughts

[John Davidge (jodavidg)]

Going forward, I think the best approach for PD would be to align with the
subnet-pools being added by the subnet allocation BP work (thanks to Sean
for bringing this to our attention again).

http://specs.openstack.org/openstack/neutron-specs/specs/kilo/subnet-alloca
tion.html#rest-api-impact


The above blueprint outlines an admin-configurable global default pool to
be used in the case of a user calling subnet-create without specifying a
CIDR or subnet-pool ID. If the OpenStack environment has been made
PD-capable by the operator (a PD-server has been setup), this default
could be set in such a way to indicate that PD should be used. This would
give the user a hassle-free workflow and avoids overloading api
attributes. It also has the added benefit of not allowing the user to
request a PD-defined CIDR in an environment that isn¹t PD-capable.

If anyone has any concerns/comments about such an approach I¹d be happy to
hear them. I¹ll be keeping my eye on the subnet allocation patches as they
are merged so we can align our patch as soon as it¹s feasible.

Cheers,

John




On 23/03/2015 15:31, John Belamaric jbelama...@infoblox.com wrote:



On 3/18/15, 9:12 PM, Sean M. Collins s...@coreitpro.com wrote:


 My hope is that either the new IPAM subsystem for subnet allocations
would provide this, or that a small API extension could paper over some
of the sharper edges.

In IPAM we have added this concept of a subnet request. The built-in
support would allow you to request any subnet or a specific subnet.
This concept applies to both pool-based and non-pool-based requests.

Currently, a request needs to be essentially encoded in the cidr field
of the subnet creation API call, in order to provide complete API
backwards compatibility. A blank CIDR indicates any subnet; a specific
CIDR indicates to allocate that subnet. However, the intention is that
individual drivers could add their own types of requests. This is
supported in the request factory defined in [1]. This means, for example,
we can implement a request class RFC3633SubnetRequest that handles
acquiring the CIDR via prefix delegation. The user will pass RFC3633 as
the cidr attribute in that case, so that the correct request class is
instantiated. A similar mechanism can be used for address requests - for
example, EUI64 and other auto-generated addresses.

To enable this, an additional change needed beyond [1] is to use the
request factory for validation of the cidr field rather than the API
layer.


[1] https://review.openstack.org/#/c/153236/25/neutron/ipam/__init__.py



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][IPv6] Prefix delegation and user facing API thoughts

[Carl Baldwin]

On Wed, Mar 18, 2015 at 8:15 AM, Sean M. Collins s...@coreitpro.com wrote:
 On Wed, Mar 18, 2015 at 06:45:59AM PDT, John Davidge (jodavidg) wrote:
 In the IPv6 meeting yesterday you mentioned doing this
 with an extension rather than modifying the core API. Could you go into
 some detail about how you see this extension looking?

 The easiest, is to evaluate the REST API that is being worked on by the
 subnet allocation spec:

 http://specs.openstack.org/openstack/neutron-specs/specs/kilo/subnet-allocation.html#rest-api-impact

 Since it also solves the issue of the CIDR being a required attribute in
 the subnet-create call.

My recollection was that the subnet create for a PD subnet would use a
specially configured subnet pool id for PD and no cidr.  The subnet
pool This was to allow both are efforts to continue with very little
dependency between them but also be interoperable.  It looks like it
has diverged a bit from this resolution.  This was a face-to-face
discussion without any log.  But, it looks like this made it in to the
spec [1].

Carl

[1] https://review.openstack.org/#/c/93054/

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][IPv6] Tomorrow's IPv6 subteam meeting

[Sean M. Collins]

Hi,

My apologies for the short notice, but I will not be able to run the
IPv6 subteam meeting tomorrow. If one of the attendees who has items to
discuss would like to run the meeting in my absence, that would be
great!


-- 
Sean M. Collins

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][IPv6] Prefix delegation and user facing API thoughts

[John Davidge (jodavidg)]

Copying my response on the review below:

Yes that completely makes sense Sean. In our original proposal we wanted
to allow the user to initiate a subnet-create without providing a CIDR,
and have an 'ipv6_pd_enabled' flag which could be set in the API call to
tell Neutron that this particular subnet needs to have its CIDR defined by
PD. The consensus from the community early in the Kilo development cycle
was that changes to the API should be avoided if at all possible, and so
it was agreed that we would use a special ::/64 CIDR for the initial
implementation. In the IPv6 meeting yesterday you mentioned doing this
with an extension rather than modifying the core API. Could you go into
some detail about how you see this extension looking?

Cheers,


John




On 18/03/2015 13:12, Sean M. Collins s...@coreitpro.com wrote:

Hi all,

I recently posted this comment in the review for
https://review.openstack.org/#/c/158697/,
and wanted to post it here so that people can respond. Basically, I have
concerns that I raised during the spec submission process
(https://review.openstack.org/#/c/93054/).

I'm still not totally on board with the proposed user facing API, where
they create a subnet cidr of ::/64, then later it is updated by Neutron
to actually be the cidr that is delegated. My hope is to have a user
facing API that would require little to no user input (since we are
relying on an external system to delegate us a subnet) and Neutron would
create the required constructs internally. My hope is that either the new
IPAM subsystem for subnet allocations would provide this, or that a small
API extension could paper over some of the sharper edges.

Basically, I know we need the user to create a CIDR of ::/64 to satisfy
the Neutron core API's requirement that a subnet MUST have a CIDR when
creating, but I think that in the case of prefix delegation we shouldn't
expose this sharp edge to the user by default.

Does this make sense?

-- 
Sean M. Collins

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][IPv6] Prefix delegation and user facing API thoughts

[Sean M. Collins]

Hi all,

I recently posted this comment in the review for 
https://review.openstack.org/#/c/158697/,
and wanted to post it here so that people can respond. Basically, I have
concerns that I raised during the spec submission process
(https://review.openstack.org/#/c/93054/).

I'm still not totally on board with the proposed user facing API, where they 
create a subnet cidr of ::/64, then later it is updated by Neutron to actually 
be the cidr that is delegated. My hope is to have a user facing API that would 
require little to no user input (since we are relying on an external system to 
delegate us a subnet) and Neutron would create the required constructs 
internally. My hope is that either the new IPAM subsystem for subnet 
allocations would provide this, or that a small API extension could paper 
over some of the sharper edges.

Basically, I know we need the user to create a CIDR of ::/64 to satisfy the 
Neutron core API's requirement that a subnet MUST have a CIDR when creating, 
but I think that in the case of prefix delegation we shouldn't expose this 
sharp edge to the user by default.

Does this make sense?

-- 
Sean M. Collins

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][IPv6] Prefix delegation and user facing API thoughts

[Sean M. Collins]

On Wed, Mar 18, 2015 at 06:45:59AM PDT, John Davidge (jodavidg) wrote:
 In the IPv6 meeting yesterday you mentioned doing this
 with an extension rather than modifying the core API. Could you go into
 some detail about how you see this extension looking?

The easiest, is to evaluate the REST API that is being worked on by the
subnet allocation spec:

http://specs.openstack.org/openstack/neutron-specs/specs/kilo/subnet-allocation.html#rest-api-impact

Since it also solves the issue of the CIDR being a required attribute in
the subnet-create call.

This was part of my comments when reviewing the spec, that we should
rely on the API changes that the subnet allocation spec as the user
facing portion of prefix delegation. 

Anthony Veiga and I did some preliminary sketches on what an API
extension that handled prefix delegation would look like nearly a year
ago ( 
http://lists.openstack.org/pipermail/openstack-dev/2014-March/030581.html),
and I have some additional thoughts on how the REST API would behave,
but at this stage of the game I think the subnet allocation REST API is
a superior spec.

-- 
Sean M. Collins

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron][ipv6] dhcp stateful

[Andreas Scheuring]

Hi, 
I was playing around with the various dhcp/radvd options of neutron.
Very helpful was the matrix [1] that describes the combinations of ra
and adress mode that can be configured.

For dhcpv6-stateful (ra  adress mode) it says: VM obtains IPv6 address
from dnsmasq using DHCPv6 stateful and optional info from dnsmasq using
DHCPv6 stateful [1] -- My assumption was that IP adresses and prefix
are assigned via dnsmasq. 

But going this way, my instances got the right IP-Adress (great) but
always the subnetmask /128, although I configured /64. Dumping the
traffic and having a look at dnsmasq logs the dhcp process from solicit
to reply worked fine.

I was using rhel7 for guest and host and dnsmasq 2.68.

I googled around and found some hints, that dhcpv6 does not support
prefix delegation. Seems like that it is the job of the radvd daemon
[2][3][4]


Is that true? And if so, what's the use case of configuring
dhcpv6-stateful for ra and address mode?






[1]
http://specs.openstack.org/openstack/neutron-specs/specs/juno/ipv6-radvd-ra.html#rest-api-impact

[2] https://lists.isc.org/pipermail/dhcp-users/2012-May/015446.html
[3]
http://serverfault.com/questions/528387/sending-netmask-and-gateway-route-with-dhcp-for-ipv6
[4]
https://supportforums.cisco.com/document/116221/part-1-implementing-dhcpv6-stateful-dhcpv6

-- 
Andreas 
(irc: scheuran)




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][ipv6] dhcp stateful

[Robert Li (baoli)]

My guess is that your dhcp client running inside the VM set up the subnet
mask as /128. Dhcpv6 doesn¹t provide prefix length, but the client system
sometime adds the net mask based on the link type. Some of the dhcp
clients use a script to configure the interface, and I think you can use
/64 if your link is ethernet.

‹Robert

On 2/19/15, 4:27 AM, Andreas Scheuring scheu...@linux.vnet.ibm.com
wrote:

Hi, 
I was playing around with the various dhcp/radvd options of neutron.
Very helpful was the matrix [1] that describes the combinations of ra
and adress mode that can be configured.

For dhcpv6-stateful (ra  adress mode) it says: VM obtains IPv6 address
from dnsmasq using DHCPv6 stateful and optional info from dnsmasq using
DHCPv6 stateful [1] -- My assumption was that IP adresses and prefix
are assigned via dnsmasq.

But going this way, my instances got the right IP-Adress (great) but
always the subnetmask /128, although I configured /64. Dumping the
traffic and having a look at dnsmasq logs the dhcp process from solicit
to reply worked fine.

I was using rhel7 for guest and host and dnsmasq 2.68.

I googled around and found some hints, that dhcpv6 does not support
prefix delegation. Seems like that it is the job of the radvd daemon
[2][3][4]


Is that true? And if so, what's the use case of configuring
dhcpv6-stateful for ra and address mode?






[1]
http://specs.openstack.org/openstack/neutron-specs/specs/juno/ipv6-radvd-r
a.html#rest-api-impact

[2] https://lists.isc.org/pipermail/dhcp-users/2012-May/015446.html
[3]
http://serverfault.com/questions/528387/sending-netmask-and-gateway-route-
with-dhcp-for-ipv6
[4]
https://supportforums.cisco.com/document/116221/part-1-implementing-dhcpv6
-stateful-dhcpv6

-- 
Andreas 
(irc: scheuran)




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] IPv6 Status

[Brian Haley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/05/2015 05:38 AM, Ihar Hrachyshka wrote:
 On 02/05/2015 09:14 AM, Andreas Scheuring wrote:
 Hi,
 
 is there a central place where I can find a matrix (or something similar)
 that shows what is currently supposed to work in the sense of IPv6
 Networking?

I'm not sure there's a matrix, but there are a number of updates coming in
Kilo, check https://blueprints.launchpad.net/neutron/kilo for the IPv6 ones.

Most of the bug fixes are tagged and can be found here:

https://bugs.launchpad.net/neutron/+bugs?field.tag=ipv6

 I also had a look at a couple of blueprints out there, but I'm looking
 for a simple overview containing what's supported, on which features are
 people working on and what's future. I mean all the good stuff for Tenant
 Networks like
 
 - SNAT - FloatingIP - External Provider Networks - DVR - fwaas, 
 vpnaas,...

There will be no default SNATv6 or Floating IPv6 as decided at the Kilo Summit
- - they're really not necessary if the VM has a global address.

Probably the best thing for you to do is spin-up a devstack with IPv6 enabled
and see how things work, putting these in local.conf will enable both DVR and
IPv6 (assuming you have RECLONE=yes):

Q_DVR_MODE=dvr_snat

# to enable IPv4 and IPv6
IP_VERSION=4+6

 and also about the Host Network - e.g. vxlan/gre tunneling via ipv6 host
 network...
 
 AFAIK it's not supported by OVS yet. The last time I talked to a guy who
 worked on the feature, he told me that it will take some time, and it will
 probably be VXLAN only. (Unless someone steps in.)

OVS/VXLAN w/IPv6 is not supported, pointer to thread:

http://openvswitch.org/pipermail/discuss/2015-January/016344.html

- -Brian
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJU05XhAAoJEIYQqpVulyUozYgH/iple8dvRoyE0Z+9aUObcYxi
uh5jkly4zeCs7OUEOlMDeAsboKBdgEc+kSLzu6ianqd1f8CtHXG1iROn2YTb7z05
HN5bPByT9pZW5eu5lSN0KsOvlnpJCvK/Kz6xbW+cJJ03YCmHZkto64SEOcnJJ1iq
mFFnKOjxDlxHUGJyt0GNto7hQNV9RUSVA6fk7omsn5UnSP4RcZJjqbXCFW4mmU9j
ppUGB+dnGeQyKq0egPN9bzNRudSfVKA6mne5ipxOhYNzju5LBp84xqIAlBq0w7k7
8SIYsdDIrmPjWwckr6+39QHFSCUPqbNmRyH2H28CoYpd7ZQuvPZ2osseNX0AahA=
=ahi+
-END PGP SIGNATURE-

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] IPv6 Status

[Ihar Hrachyshka]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/05/2015 09:14 AM, Andreas Scheuring wrote:
 Hi,
 
 is there a central place where I can find a matrix (or something 
 similar) that shows what is currently supposed to work in the sense
 of IPv6 Networking?
 
 I also had a look at a couple of blueprints out there, but I'm
 looking for a simple overview containing what's supported, on which
 features are people working on and what's future. I mean all the
 good stuff for Tenant Networks like
 
 - SNAT - FloatingIP - External Provider Networks - DVR - fwaas,
 vpnaas,...
 
 and also about the Host Network - e.g. vxlan/gre tunneling via ipv6
 host network...

AFAIK it's not supported by OVS yet. The last time I talked to a guy
who worked on the feature, he told me that it will take some time, and
it will probably be VXLAN only. (Unless someone steps in.)

/Ihar
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJU00gmAAoJEC5aWaUY1u57OZEH/ia2vXIVJDRgBtbGzp7O6dyl
fXhrLgitod0S7k6h7/ocacXkutQJ4qF8ab01Ry19YmbYB1xfE7ExSmt/Js9/rqn1
PANaDCvBe9iSEvgj/s/kmAwJNRRILvtZ8ZjFsGr1VGebJQmyqNvmZtRrljX7rfDl
o6j7grBINc+iY9sck/f9OW8wA6nzWT1nwKJksExT6pIZ/9MkeddRn/L/ALDRC0qD
6erLS/1GyG+1ByEzFApBXvtqhF8JVkUVrePm9PDWDWMnLb6db0v9J61E/KWqy+IQ
jzPnOmUlj3u3J5zFLalt6PKq2T9+58y+MziCwi9Oq8LygQWBXqeQTITmWpqD+OU=
=pwN5
-END PGP SIGNATURE-

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][IPv6] No weekly meeting until Jan 6th 2015

[Collins, Sean]

See everyone next year!

Sean M. Collins
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][IPv6] No IPv6 meeting next week - Dec. 9th 2014

[Collins, Sean]

Due to the mid-cycle, and other neutron meetings being cancelled, we will not 
meet on the 9th
--
Sean M. Collins
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][IPv6] Priorities for Kilo?

[Collins, Sean]

Hi,

Based on today's meeting and previous discussions with Kyle, I've tried
to put down as much on paper about what I'd like to get done this
development cycle. I used some of the links that we swapped today in the
IRC meeting, but I know right now that I didn't get everything we talked
about.

Please review, and give me links to bugs in launchpad and specs in
Gerrit.

I am trying to avoid linking directly to patches that fix bugs or
implement a spec, to keep things simple.

https://review.openstack.org/137169

Finally, please let me know if you agree with what I've marked highest
priority. The tl;dr is that we need to fix gaps in Neutron Routers and
DVR support since everyone is going to want tenant networks with IPv6
functionality and also DVR support.

-- 
Sean M. Collins
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][IPv6] No meeting this week

[Collins, Sean]

See everyone next week
--
Sean M. Collins
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] IPv6 team summit meetup

[Shixiong Shang]

Hi, guys:

Very nice to talk to all of you yesterday. Unfortunately I need to head out
to the airport at 1pm, so I won't be able to make it for the lunch. :(

Will see you on IRC and keep in touch!

Shixiong



On Thu, Nov 6, 2014 at 4:18 PM, Xuhan Peng pengxu...@gmail.com wrote:

  Hey,

 Since we don't have any slot for ipv6 in summit to meet up, can we have a
 lunch meetup together tomorrow (11/7 Friday)?

 We can meet at 12:30 at the meet up place Neuilly lobby of Le Meridien
 and go to lunch together after that.

 Xu Han


 —
 Sent from Mailbox https://www.dropbox.com/mailbox for iPhone

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] IPv6 team summit meetup

[Brian Haley]

On 11/06/2014 04:18 PM, Xuhan Peng wrote:

Hey,

Since we don't have any slot for ipv6 in summit to meet up, can we have
a lunch meetup together tomorrow (11/7 Friday)?

We can meet at 12:30 at the meet up place Neuilly lobby of Le Meridien
and go to lunch together after that.


I'll be there.

-Brian


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] IPv6 team summit meetup

[Robert Li (baoli)]

will be there too

On 11/7/14, 4:53 AM, Brian Haley brian.ha...@hp.com wrote:

On 11/06/2014 04:18 PM, Xuhan Peng wrote:
 Hey,

 Since we don't have any slot for ipv6 in summit to meet up, can we have
 a lunch meetup together tomorrow (11/7 Friday)?

 We can meet at 12:30 at the meet up place Neuilly lobby of Le Meridien
 and go to lunch together after that.

I'll be there.

-Brian


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] IPv6 team summit meetup

[Xuhan Peng]

Hey, 

Since we don't have any slot for ipv6 in summit to meet up, can we have a lunch 
meetup together tomorrow (11/7 Friday)?


We can meet at 12:30 at the meet up place Neuilly lobby of Le Meridien and go 
to lunch together after that.


Xu Han 




—
Sent from Mailbox for iPhone___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] IPv6 team summit meetup

[Collins, Sean]

Looking forward to it, see you all then!

--
Sean M. Collins
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] IPv6 team summit meetup

[Henry Gessau]

Count me in.

On 11/6/2014 4:18 PM, Xuhan Peng wrote:
 Hey, 

 Since we don't have any slot for ipv6 in summit to meet up, can we have a
 lunch meetup together tomorrow (11/7 Friday)?

 We can meet at 12:30 at the meet up place Neuilly lobby of Le Meridien and
 go to lunch together after that.

 Xu Han 


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] IPv6 team summit meetup

[Brian Bowen (brbowen)]

Count me in,

Brian B.

From: Xuhan Peng pengxu...@gmail.commailto:pengxu...@gmail.com
Reply-To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Thursday, November 6, 2014 at 4:18 PM
To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Neutron] IPv6 team summit meetup

Hey,

Since we don't have any slot for ipv6 in summit to meet up, can we have a lunch 
meetup together tomorrow (11/7 Friday)?

We can meet at 12:30 at the meet up place Neuilly lobby of Le Meridien and go 
to lunch together after that.

Xu Han


—
Sent from Mailboxhttps://www.dropbox.com/mailbox for iPhone
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][IPv6] No meeting tomorrow

[Collins, Sean]

I look forward to seeing everyone in Paris!
-- 
Sean M. Collins
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][IPv6] Neighbor Discovery for HA

[Xu Han Peng]

I was reminded that scapy is under GPLv2 license so we cannot make it as 
the dependency of Neutron.


There are also some IPv6 utilities from ryu.lib.packet which can be 
leveraged to send out neighbor advertisement. Is it OK to make ryu as a 
dependency and make this as a binary and call it from namespace?



Thanks,
Xu Han


On 09/26/2014 10:08 AM, Vishvananda Ishaya wrote:

You are going to have to make this as a separate binary and call it
via rootwrap ip netns exec. While it is possible to change network
namespaces in python, you aren't going to be able to do this consistently
without root access, so it will need to be guarded by rootwrap anyway.

Vish

On Sep 25, 2014, at 7:00 PM, Xu Han Peng pengxu...@gmail.com 
mailto:pengxu...@gmail.com wrote:



Sending unsolicited NA by scapy is like this:

from scapy.all import send, IPv6, ICMPv6ND_NA, ICMPv6NDOptDstLLAddr

target_ll_addr = ICMPv6NDOptDstLLAddr(lladdr = mac_address)
unsolicited_na=ICMPv6ND_NA(R=1, S=0, O=1, tgt=target)
packet=IPv6(src=source)/unsolicited_na/target_ll_addr
*send(packet, iface=interface_name, count=10, inter=0.2)*

It's not actually a python script but a python method. Any ideas?

On 09/25/2014 06:20 PM, Kevin Benton wrote:

Does running the python script with ip netns exec not work correctly?

On Thu, Sep 25, 2014 at 2:05 AM, Xu Han Pengpengxu...@gmail.com  wrote:

Hi,

As we talked in last IPv6 sub-team meeting, I was able to construct and send
IPv6 unsolicited neighbor advertisement for external gateway interface by
python tool scapy:

http://www.secdev.org/projects/scapy/

http://www.idsv6.de/Downloads/IPv6PacketCreationWithScapy.pdf


However, I am having trouble to send this unsolicited neighbor advertisement
in a given namespace. All the current namespace operations leverage ip netns
exec and shell command. But we cannot do this to scapy since it's python
code. Can anyone advise me on this?

Thanks,
Xu Han


On 09/05/2014 05:46 PM, Xu Han Peng wrote:

Carl,

Seem so. I think internal router interface and external gateway port GARP
are taken care by keepalived during failover. And if HA is not enable,
_send_gratuitous_arp is called to send out GARP.

I think we will need to take care IPv6 for both cases since keepalived 1.2.0
support IPv6. May need a separate BP. For the case HA is enabled externally,
we still need unsolicited neighbor advertisement for gateway failover. But
for internal router interface, since Router Advertisement is automatically
send out by RADVD after failover, we don't need to send out neighbor
advertisement anymore.

Xu Han


On 09/05/2014 03:04 AM, Carl Baldwin wrote:

Hi Xu Han,

Since I sent my message yesterday there has been some more discussion
in the review on that patch set.  See [1] again.  I think your
assessment is likely correct.

Carl

[1]https://review.openstack.org/#/c/70700/37/neutron/agent/l3_ha_agent.py

On Thu, Sep 4, 2014 at 3:32 AM, Xu Han Pengpengxu...@gmail.com  wrote:

Carl,

Thanks a lot for your reply!

If I understand correctly, in VRRP case, keepalived will be responsible for
sending out GARPs? By checking the code you provided, I can see all the
_send_gratuitous_arp_packet call are wrapped by if not is_ha condition.

Xu Han



On 09/04/2014 06:06 AM, Carl Baldwin wrote:

It should be noted that send_arp_for_ha is a configuration option
that preceded the more recent in-progress work to add VRRP controlled
HA to Neutron's router.  The option was added, I believe, to cause the
router to send (default) 3 GARPs to the external gateway if the router
was removed from one network node and added to another by some
external script or manual intervention.  It did not send anything on
the internal network ports.

VRRP is a different story and the code in review [1] sends GARPs on
internal and external ports.

Hope this helps avoid confusion in this discussion.

Carl

[1]https://review.openstack.org/#/c/70700/37/neutron/agent/l3_ha_agent.py

On Mon, Sep 1, 2014 at 8:52 PM, Xu Han Pengpengxu...@gmail.com  wrote:

Anthony,

Thanks for your reply.

If HA method like VRRP are used for IPv6 router, according to the VRRP RFC
with IPv6 included, the servers should be auto-configured with the active
router's LLA as the default route before the failover happens and still
remain that route after the failover. In other word, there should be no need
to use two LLAs for default route of a subnet unless load balance is
required.

When the backup router become the master router, the backup router should be
responsible for sending out an unsolicited ND neighbor advertisement with
the associated LLA (the previous master's LLA) immediately to update the
bridge learning state and sending out router advertisement with the same
options with the previous master to maintain the route and bridge learning.

This is shown inhttp://tools.ietf.org/html/rfc5798#section-4.1  and the
actions backup router should take after failover is documented here:

Re: [openstack-dev] [Neutron] IPv6 bug fixes that would be nice to have in Juno

[Xu Han Peng]

Armando,

Will error message change still stop the fix from making into RC2?

Thanks,
Xu Han

On 10/04/2014 03:42 AM, Armando M. wrote:

I have all of these bugs on my radar, and I want to fast track them
for merging in the next few days.

Please tag the bug reports with 'juno-rc-potential'.

For each of them we can discuss the loss of functionality they cause.
If no workaround can be found, we should definitely cut an RC2.

Armando

On 3 October 2014 12:21, Collins, Sean sean_colli...@cable.comcast.com wrote:

On Fri, Oct 03, 2014 at 02:58:36PM EDT, Henry Gessau wrote:

There are some fixes for IPv6 bugs that unfortunately missed the RC1 cut.
These bugs are quite important for IPv6 users and therefore I would like to
lobby for getting them into a possible RC2 of Neutron Juno.

Henry and I spoke about these bugs, and I agree with his assessment. +1!
--
Sean M. Collins
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][IPv6] Skipping IPv6 unit tests in proprietary plugins

[Collins, Sean]

Hi,

I am seeing some patches in review that are adding skips to unit tests in the 
Open Contrail plugin. If we can, please imitate the work that Kevin Benton did 
in the One Convergence plugin and have your plugin skip tests that have v6 in 
the name, if your plugin does not support IPv6.

I have added similar logic to the OpenContrail plugin's tests.

https://review.openstack.org/#/c/126407/1

--
Sean M. Collins
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] IPv6 bug fixes that would be nice to have in Juno

[Henry Gessau]

There are some fixes for IPv6 bugs that unfortunately missed the RC1 cut.
These bugs are quite important for IPv6 users and therefore I would like to
lobby for getting them into a possible RC2 of Neutron Juno.

These are low-risk fixes that would not jeopardize the stability of Neutron.

1. Network:dhcp port is not assigned EUI64 IPv6 address for SLAAC subnet
Bug: https://bugs.launchpad.net/neutron/+bug/1330826
Fix: https://review.openstack.org/101433

2. Cannot set only one of IPv6 attributes while second is None
Bug: https://bugs.launchpad.net/neutron/+bug/1363064
Fix: https://review.openstack.org/117799

The third one will probably not be allowed since it requires a string freeze
exception, but I will mention it anyway ...

3. IPv6 slaac is broken when subnet is less than /64
Bug: https://bugs.launchpad.net/neutron/+bug/1357084
Fix: https://review.openstack.org/116525

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] IPv6 bug fixes that would be nice to have in Juno

[Veiga, Anthony]

On 10/3/14, 14:58 , Henry Gessau ges...@cisco.com wrote:

There are some fixes for IPv6 bugs that unfortunately missed the RC1 cut.
These bugs are quite important for IPv6 users and therefore I would like
to
lobby for getting them into a possible RC2 of Neutron Juno.

These are low-risk fixes that would not jeopardize the stability of
Neutron.

1. Network:dhcp port is not assigned EUI64 IPv6 address for SLAAC subnet
Bug: https://bugs.launchpad.net/neutron/+bug/1330826
Fix: https://review.openstack.org/101433

2. Cannot set only one of IPv6 attributes while second is None
Bug: https://bugs.launchpad.net/neutron/+bug/1363064
Fix: https://review.openstack.org/117799

The third one will probably not be allowed since it requires a string
freeze
exception, but I will mention it anyway ...

3. IPv6 slaac is broken when subnet is less than /64
Bug: https://bugs.launchpad.net/neutron/+bug/1357084
Fix: https://review.openstack.org/116525

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



I¹ll second this notion. #2 is particularly important, as several modes
like provider networking are going to be broken without this.
-Anthony


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] IPv6 bug fixes that would be nice to have in Juno

[Collins, Sean]

On Fri, Oct 03, 2014 at 02:58:36PM EDT, Henry Gessau wrote:
 There are some fixes for IPv6 bugs that unfortunately missed the RC1 cut.
 These bugs are quite important for IPv6 users and therefore I would like to
 lobby for getting them into a possible RC2 of Neutron Juno.

Henry and I spoke about these bugs, and I agree with his assessment. +1!
-- 
Sean M. Collins
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] IPv6 bug fixes that would be nice to have in Juno

[Armando M.]

I have all of these bugs on my radar, and I want to fast track them
for merging in the next few days.

Please tag the bug reports with 'juno-rc-potential'.

For each of them we can discuss the loss of functionality they cause.
If no workaround can be found, we should definitely cut an RC2.

Armando

On 3 October 2014 12:21, Collins, Sean sean_colli...@cable.comcast.com wrote:
 On Fri, Oct 03, 2014 at 02:58:36PM EDT, Henry Gessau wrote:
 There are some fixes for IPv6 bugs that unfortunately missed the RC1 cut.
 These bugs are quite important for IPv6 users and therefore I would like to
 lobby for getting them into a possible RC2 of Neutron Juno.

 Henry and I spoke about these bugs, and I agree with his assessment. +1!
 --
 Sean M. Collins
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] [IPv6] [ironic] New API format for extra_dhcp_opts

[Lucas Alvares Gomes]

Thanks guys for the heads up

Indeed making it backwards compat by adding the [ip_]version key to
the dictionary sounds like the best way to go.

Cheers,
Lucas

On Thu, Oct 2, 2014 at 3:53 AM, Carlino, Chuck chuck.carl...@hp.com wrote:
 As a 'heads up', adding ironic to the thread since they are a 'key' consumer 
 of this api.


 On Oct 1, 2014, at 3:15 AM, Xu Han Peng 
 pengxu...@gmail.commailto:pengxu...@gmail.com wrote:

 ip_version sounds great.

 Currently the opt-names are written into the configuration file of dnsmasq 
 directly. So I would say yes, they are coming from dnsmasq definitions.

 It will make more sense when ip_version is missing or null, the option apply 
 to both since we could have only ipv6 or ipv4 address on the port. However, 
 the validation of opt-value should rule out the ones which are not suitable 
 for the current address. For example, an IPv6 dns server should not be 
 specified for IPv4 address port, etc...

 Xu Han

 On 09/30/2014 08:41 PM, Robert Li (baoli) wrote:
 Xu Han,

 That looks good to me. To keep it consistent with existing CLI, we should use 
 ip-version instead of ‘version’. It seems to be identical to prefixing the 
 option_name with v4 or v6, though.

 Just to clarify, are the available opt-names coming from dnsmasq definitions?

 With regard to the default, your suggestion version is optional (no version 
 means version=4). seems to be different from Mark’s:
 I’m -1 for both options because neither is properly backwards compatible.  
 Instead we should add an optional 3rd value to the dictionary: “version”.  
 The version key would be used to make the option only apply to either version 
 4 or 6.  If the key is missing or null, then the option would apply to both.

 Thanks,
 Robert

 On 9/30/14, 1:46 AM, Xu Han Peng 
 pengxu...@gmail.commailto:pengxu...@gmail.com wrote:

 Robert,

 I think the CLI will look something like based on Mark's suggestion:

 neutron port-create extra_dhcp_opts 
 opt_name=dhcp_option_name,opt_value=value,version=4(or 6) network

 This extra_dhcp_opts can be repeated and version is optional (no version 
 means version=4).

 Xu Han

 On 09/29/2014 08:51 PM, Robert Li (baoli) wrote:
 Hi Xu Han,

 My question is how the CLI user interface would look like to distinguish 
 between v4 and v6 dhcp options?

 Thanks,
 Robert

 On 9/28/14, 10:29 PM, Xu Han Peng 
 pengxu...@gmail.commailto:pengxu...@gmail.com wrote:

 Mark's suggestion works for me as well. If no one objects, I am going to 
 start the implementation.

 Thanks,
 Xu Han

 On 09/27/2014 01:05 AM, Mark McClain wrote:

 On Sep 26, 2014, at 2:39 AM, Xu Han Peng 
 pengxu...@gmail.commailto:pengxu...@gmail.com wrote:

 Currently the extra_dhcp_opts has the following API interface on a port:

 {
 port:
 {
 extra_dhcp_opts: [
 {opt_value: testfile.1,opt_name: bootfile-name},
 {opt_value: 123.123.123.123, opt_name: tftp-server},
 {opt_value: 123.123.123.45, opt_name: server-ip-address}
 ],
 
  }
 }

 During the development of DHCPv6 function for IPv6 subnets, we found this 
 format doesn't work anymore because an port can have both IPv4 and IPv6 
 address. So we need to find a new way to specify extra_dhcp_opts for DHCPv4 
 and DHCPv6, respectively. ( https://bugs.launchpad.net/neutron/+bug/1356383)

 Here are some thoughts about the new format:

 Option1: Change the opt_name in extra_dhcp_opts to add a prefix (v4 or v6) so 
 we can distinguish opts for v4 or v6 by parsing the opt_name. For backward 
 compatibility, no prefix means IPv4 dhcp opt.

 extra_dhcp_opts: [
 {opt_value: testfile.1,opt_name: bootfile-name},
 {opt_value: 123.123.123.123, opt_name: v4:tftp-server},
 {opt_value: [2001:0200:feed:7ac0::1], opt_name: 
 v6:dns-server}
 ]

 Option2: break extra_dhcp_opts into IPv4 opts and IPv6 opts. For backward 
 compatibility, both old format and new format are acceptable, but old format 
 means IPv4 dhcp opts.

 extra_dhcp_opts: {
  ipv4: [
 {opt_value: testfile.1,opt_name: bootfile-name},
 {opt_value: 123.123.123.123, opt_name: 
 tftp-server},
  ],
  ipv6: [
 {opt_value: [2001:0200:feed:7ac0::1], opt_name: 
 dns-server}
  ]
 }

 The pro of Option1 is there is no need to change API structure but only need 
 to add validation and parsing to opt_name. The con of Option1 is that user 
 need to input prefix for every opt_name which can be error prone. The pro of 
 Option2 is that it's clearer than Option1. The con is that we need to check 
 two formats for backward compatibility.

 We discussed this in IPv6 sub-team meeting and we think Option2 is preferred. 
 Can I also get community's feedback on which one is preferred or any other 
 comments?


 I’m -1 for both options because neither is properly backwards compatible.  
 Instead we 

Re: [openstack-dev] [neutron] [IPv6] New API format for extra_dhcp_opts

[Xu Han Peng]

ip_version sounds great.

Currently the opt-names are written into the configuration file of 
dnsmasq directly. So I would say yes, they are coming from dnsmasq 
definitions.


It will make more sense when ip_version is missing or null, the option 
apply to both since we could have only ipv6 or ipv4 address on the port. 
However, the validation of opt-value should rule out the ones which are 
not suitable for the current address. For example, an IPv6 dns server 
should not be specified for IPv4 address port, etc...


Xu Han

On 09/30/2014 08:41 PM, Robert Li (baoli) wrote:

Xu Han,

That looks good to me. To keep it consistent with existing CLI, we 
should use ip-version instead of 'version'. It seems to be identical 
to prefixing the option_name with v4 or v6, though.


Just to clarify, are the available opt-names coming from dnsmasq 
definitions?


With regard to the default, your suggestion *version is optional (no 
version means version=4).* seems to be different from Mark's:



I'm -1 for both options because neither is properly backwards
compatible.  Instead we should add an optional 3rd value to the
dictionary: version.  The version key would be used to make
the option only apply to either version 4 or 6. *If the key is
missing or null, then the option would apply to both*. 




Thanks,
Robert

On 9/30/14, 1:46 AM, Xu Han Peng pengxu...@gmail.com 
mailto:pengxu...@gmail.com wrote:


Robert,

I think the CLI will look something like based on Mark's suggestion:

neutron port-create extra_dhcp_opts
opt_name=dhcp_option_name,opt_value=value,version=4(or 6)
network

This extra_dhcp_opts can be repeated and version is optional (no
version means version=4).

Xu Han

On 09/29/2014 08:51 PM, Robert Li (baoli) wrote:

Hi Xu Han,

My question is how the CLI user interface would look like to
distinguish between v4 and v6 dhcp options?

Thanks,
Robert

On 9/28/14, 10:29 PM, Xu Han Peng pengxu...@gmail.com
mailto:pengxu...@gmail.com wrote:

Mark's suggestion works for me as well. If no one objects, I
am going to start the implementation.

Thanks,
Xu Han

On 09/27/2014 01:05 AM, Mark McClain wrote:


On Sep 26, 2014, at 2:39 AM, Xu Han Peng
pengxu...@gmail.com mailto:pengxu...@gmail.com wrote:


Currently the extra_dhcp_opts has the following API
interface on a port:

{
port:
{
extra_dhcp_opts: [
{opt_value: testfile.1,opt_name:
bootfile-name},
{opt_value: 123.123.123.123, opt_name:
tftp-server},
{opt_value: 123.123.123.45, opt_name:
server-ip-address}
],

 }
}

During the development of DHCPv6 function for IPv6 subnets,
we found this format doesn't work anymore because an port
can have both IPv4 and IPv6 address. So we need to find a
new way to specify extra_dhcp_opts for DHCPv4 and DHCPv6,
respectively. (
https://bugs.launchpad.net/neutron/+bug/1356383)

Here are some thoughts about the new format:

Option1: Change the opt_name in extra_dhcp_opts to add a
prefix (v4 or v6) so we can distinguish opts for v4 or v6
by parsing the opt_name. For backward compatibility, no
prefix means IPv4 dhcp opt.

extra_dhcp_opts: [
{opt_value: testfile.1,opt_name:
bootfile-name},
{opt_value: 123.123.123.123, opt_name:
*v4:*tftp-server},
{opt_value: [2001:0200:feed:7ac0::1],
opt_name: *v6:*dns-server}
]

Option2: break extra_dhcp_opts into IPv4 opts and IPv6
opts. For backward compatibility, both old format and new
format are acceptable, but old format means IPv4 dhcp opts.

extra_dhcp_opts: {
 ipv4: [
{opt_value: testfile.1,opt_name:
bootfile-name},
{opt_value: 123.123.123.123,
opt_name: tftp-server},
 ],
 ipv6: [
{opt_value:
[2001:0200:feed:7ac0::1], opt_name: dns-server}
 ]
}

The pro of Option1 is there is no need to change API
structure but only need to add validation and parsing to
opt_name. The con of Option1 is that user need to input
prefix for every opt_name which can be error prone. The pro
of Option2 is that it's clearer than Option1. The con is
that we need to check two formats for backward compatibility.

We discussed this in IPv6 sub-team meeting and we think
Option2 is preferred. Can I also get community's feedback
on which one is preferred or any other comments?

Re: [openstack-dev] [neutron] [IPv6] [ironic] New API format for extra_dhcp_opts

[Carlino, Chuck]

As a 'heads up', adding ironic to the thread since they are a 'key' consumer of 
this api.


On Oct 1, 2014, at 3:15 AM, Xu Han Peng 
pengxu...@gmail.commailto:pengxu...@gmail.com wrote:

ip_version sounds great.

Currently the opt-names are written into the configuration file of dnsmasq 
directly. So I would say yes, they are coming from dnsmasq definitions.

It will make more sense when ip_version is missing or null, the option apply to 
both since we could have only ipv6 or ipv4 address on the port. However, the 
validation of opt-value should rule out the ones which are not suitable for the 
current address. For example, an IPv6 dns server should not be specified for 
IPv4 address port, etc...

Xu Han

On 09/30/2014 08:41 PM, Robert Li (baoli) wrote:
Xu Han,

That looks good to me. To keep it consistent with existing CLI, we should use 
ip-version instead of ‘version’. It seems to be identical to prefixing the 
option_name with v4 or v6, though.

Just to clarify, are the available opt-names coming from dnsmasq definitions?

With regard to the default, your suggestion version is optional (no version 
means version=4). seems to be different from Mark’s:
I’m -1 for both options because neither is properly backwards compatible.  
Instead we should add an optional 3rd value to the dictionary: “version”.  The 
version key would be used to make the option only apply to either version 4 or 
6.  If the key is missing or null, then the option would apply to both.

Thanks,
Robert

On 9/30/14, 1:46 AM, Xu Han Peng 
pengxu...@gmail.commailto:pengxu...@gmail.com wrote:

Robert,

I think the CLI will look something like based on Mark's suggestion:

neutron port-create extra_dhcp_opts 
opt_name=dhcp_option_name,opt_value=value,version=4(or 6) network

This extra_dhcp_opts can be repeated and version is optional (no version means 
version=4).

Xu Han

On 09/29/2014 08:51 PM, Robert Li (baoli) wrote:
Hi Xu Han,

My question is how the CLI user interface would look like to distinguish 
between v4 and v6 dhcp options?

Thanks,
Robert

On 9/28/14, 10:29 PM, Xu Han Peng 
pengxu...@gmail.commailto:pengxu...@gmail.com wrote:

Mark's suggestion works for me as well. If no one objects, I am going to start 
the implementation.

Thanks,
Xu Han

On 09/27/2014 01:05 AM, Mark McClain wrote:

On Sep 26, 2014, at 2:39 AM, Xu Han Peng 
pengxu...@gmail.commailto:pengxu...@gmail.com wrote:

Currently the extra_dhcp_opts has the following API interface on a port:

{
port:
{
extra_dhcp_opts: [
{opt_value: testfile.1,opt_name: bootfile-name},
{opt_value: 123.123.123.123, opt_name: tftp-server},
{opt_value: 123.123.123.45, opt_name: server-ip-address}
],

 }
}

During the development of DHCPv6 function for IPv6 subnets, we found this 
format doesn't work anymore because an port can have both IPv4 and IPv6 
address. So we need to find a new way to specify extra_dhcp_opts for DHCPv4 and 
DHCPv6, respectively. ( https://bugs.launchpad.net/neutron/+bug/1356383)

Here are some thoughts about the new format:

Option1: Change the opt_name in extra_dhcp_opts to add a prefix (v4 or v6) so 
we can distinguish opts for v4 or v6 by parsing the opt_name. For backward 
compatibility, no prefix means IPv4 dhcp opt.

extra_dhcp_opts: [
{opt_value: testfile.1,opt_name: bootfile-name},
{opt_value: 123.123.123.123, opt_name: v4:tftp-server},
{opt_value: [2001:0200:feed:7ac0::1], opt_name: 
v6:dns-server}
]

Option2: break extra_dhcp_opts into IPv4 opts and IPv6 opts. For backward 
compatibility, both old format and new format are acceptable, but old format 
means IPv4 dhcp opts.

extra_dhcp_opts: {
 ipv4: [
{opt_value: testfile.1,opt_name: bootfile-name},
{opt_value: 123.123.123.123, opt_name: tftp-server},
 ],
 ipv6: [
{opt_value: [2001:0200:feed:7ac0::1], opt_name: 
dns-server}
 ]
}

The pro of Option1 is there is no need to change API structure but only need to 
add validation and parsing to opt_name. The con of Option1 is that user need to 
input prefix for every opt_name which can be error prone. The pro of Option2 is 
that it's clearer than Option1. The con is that we need to check two formats 
for backward compatibility.

We discussed this in IPv6 sub-team meeting and we think Option2 is preferred. 
Can I also get community's feedback on which one is preferred or any other 
comments?


I’m -1 for both options because neither is properly backwards compatible.  
Instead we should add an optional 3rd value to the dictionary: “version”.  The 
version key would be used to make the option only apply to either version 4 or 
6.  If the key is missing or null, then the option would apply to both.

mark




___
OpenStack-dev mailing list

Re: [openstack-dev] [neutron] [IPv6] New API format for extra_dhcp_opts

[Robert Li (baoli)]

Xu Han,

That looks good to me. To keep it consistent with existing CLI, we should use 
ip-version instead of ‘version’. It seems to be identical to prefixing the 
option_name with v4 or v6, though.

Just to clarify, are the available opt-names coming from dnsmasq definitions?

With regard to the default, your suggestion version is optional (no version 
means version=4). seems to be different from Mark’s:
I’m -1 for both options because neither is properly backwards compatible.  
Instead we should add an optional 3rd value to the dictionary: “version”.  The 
version key would be used to make the option only apply to either version 4 or 
6.  If the key is missing or null, then the option would apply to both.

Thanks,
Robert

On 9/30/14, 1:46 AM, Xu Han Peng 
pengxu...@gmail.commailto:pengxu...@gmail.com wrote:

Robert,

I think the CLI will look something like based on Mark's suggestion:

neutron port-create extra_dhcp_opts 
opt_name=dhcp_option_name,opt_value=value,version=4(or 6) network

This extra_dhcp_opts can be repeated and version is optional (no version means 
version=4).

Xu Han

On 09/29/2014 08:51 PM, Robert Li (baoli) wrote:
Hi Xu Han,

My question is how the CLI user interface would look like to distinguish 
between v4 and v6 dhcp options?

Thanks,
Robert

On 9/28/14, 10:29 PM, Xu Han Peng 
pengxu...@gmail.commailto:pengxu...@gmail.com wrote:

Mark's suggestion works for me as well. If no one objects, I am going to start 
the implementation.

Thanks,
Xu Han

On 09/27/2014 01:05 AM, Mark McClain wrote:

On Sep 26, 2014, at 2:39 AM, Xu Han Peng 
pengxu...@gmail.commailto:pengxu...@gmail.com wrote:

Currently the extra_dhcp_opts has the following API interface on a port:

{
port:
{
extra_dhcp_opts: [
{opt_value: testfile.1,opt_name: bootfile-name},
{opt_value: 123.123.123.123, opt_name: tftp-server},
{opt_value: 123.123.123.45, opt_name: server-ip-address}
],

 }
}

During the development of DHCPv6 function for IPv6 subnets, we found this 
format doesn't work anymore because an port can have both IPv4 and IPv6 
address. So we need to find a new way to specify extra_dhcp_opts for DHCPv4 and 
DHCPv6, respectively. ( https://bugs.launchpad.net/neutron/+bug/1356383)

Here are some thoughts about the new format:

Option1: Change the opt_name in extra_dhcp_opts to add a prefix (v4 or v6) so 
we can distinguish opts for v4 or v6 by parsing the opt_name. For backward 
compatibility, no prefix means IPv4 dhcp opt.

extra_dhcp_opts: [
{opt_value: testfile.1,opt_name: bootfile-name},
{opt_value: 123.123.123.123, opt_name: v4:tftp-server},
{opt_value: [2001:0200:feed:7ac0::1], opt_name: 
v6:dns-server}
]

Option2: break extra_dhcp_opts into IPv4 opts and IPv6 opts. For backward 
compatibility, both old format and new format are acceptable, but old format 
means IPv4 dhcp opts.

extra_dhcp_opts: {
 ipv4: [
{opt_value: testfile.1,opt_name: bootfile-name},
{opt_value: 123.123.123.123, opt_name: tftp-server},
 ],
 ipv6: [
{opt_value: [2001:0200:feed:7ac0::1], opt_name: 
dns-server}
 ]
}

The pro of Option1 is there is no need to change API structure but only need to 
add validation and parsing to opt_name. The con of Option1 is that user need to 
input prefix for every opt_name which can be error prone. The pro of Option2 is 
that it's clearer than Option1. The con is that we need to check two formats 
for backward compatibility.

We discussed this in IPv6 sub-team meeting and we think Option2 is preferred. 
Can I also get community's feedback on which one is preferred or any other 
comments?


I’m -1 for both options because neither is properly backwards compatible.  
Instead we should add an optional 3rd value to the dictionary: “version”.  The 
version key would be used to make the option only apply to either version 4 or 
6.  If the key is missing or null, then the option would apply to both.

mark




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] [IPv6] New API format for extra_dhcp_opts

[Robert Li (baoli)]

Hi Xu Han,

My question is how the CLI user interface would look like to distinguish 
between v4 and v6 dhcp options?

Thanks,
Robert

On 9/28/14, 10:29 PM, Xu Han Peng 
pengxu...@gmail.commailto:pengxu...@gmail.com wrote:

Mark's suggestion works for me as well. If no one objects, I am going to start 
the implementation.

Thanks,
Xu Han

On 09/27/2014 01:05 AM, Mark McClain wrote:

On Sep 26, 2014, at 2:39 AM, Xu Han Peng 
pengxu...@gmail.commailto:pengxu...@gmail.com wrote:

Currently the extra_dhcp_opts has the following API interface on a port:

{
port:
{
extra_dhcp_opts: [
{opt_value: testfile.1,opt_name: bootfile-name},
{opt_value: 123.123.123.123, opt_name: tftp-server},
{opt_value: 123.123.123.45, opt_name: server-ip-address}
],

 }
}

During the development of DHCPv6 function for IPv6 subnets, we found this 
format doesn't work anymore because an port can have both IPv4 and IPv6 
address. So we need to find a new way to specify extra_dhcp_opts for DHCPv4 and 
DHCPv6, respectively. ( https://bugs.launchpad.net/neutron/+bug/1356383)

Here are some thoughts about the new format:

Option1: Change the opt_name in extra_dhcp_opts to add a prefix (v4 or v6) so 
we can distinguish opts for v4 or v6 by parsing the opt_name. For backward 
compatibility, no prefix means IPv4 dhcp opt.

extra_dhcp_opts: [
{opt_value: testfile.1,opt_name: bootfile-name},
{opt_value: 123.123.123.123, opt_name: v4:tftp-server},
{opt_value: [2001:0200:feed:7ac0::1], opt_name: 
v6:dns-server}
]

Option2: break extra_dhcp_opts into IPv4 opts and IPv6 opts. For backward 
compatibility, both old format and new format are acceptable, but old format 
means IPv4 dhcp opts.

extra_dhcp_opts: {
 ipv4: [
{opt_value: testfile.1,opt_name: bootfile-name},
{opt_value: 123.123.123.123, opt_name: tftp-server},
 ],
 ipv6: [
{opt_value: [2001:0200:feed:7ac0::1], opt_name: 
dns-server}
 ]
}

The pro of Option1 is there is no need to change API structure but only need to 
add validation and parsing to opt_name. The con of Option1 is that user need to 
input prefix for every opt_name which can be error prone. The pro of Option2 is 
that it's clearer than Option1. The con is that we need to check two formats 
for backward compatibility.

We discussed this in IPv6 sub-team meeting and we think Option2 is preferred. 
Can I also get community's feedback on which one is preferred or any other 
comments?


I’m -1 for both options because neither is properly backwards compatible.  
Instead we should add an optional 3rd value to the dictionary: “version”.  The 
version key would be used to make the option only apply to either version 4 or 
6.  If the key is missing or null, then the option would apply to both.

mark




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] [IPv6] New API format for extra_dhcp_opts

[Xu Han Peng]

Robert,

I think the CLI will look something like based on Mark's suggestion:

neutron port-create extra_dhcp_opts 
opt_name=dhcp_option_name,opt_value=value,version=4(or 6) network


This extra_dhcp_opts can be repeated and version is optional (no version 
means version=4).


Xu Han

On 09/29/2014 08:51 PM, Robert Li (baoli) wrote:

Hi Xu Han,

My question is how the CLI user interface would look like to 
distinguish between v4 and v6 dhcp options?


Thanks,
Robert

On 9/28/14, 10:29 PM, Xu Han Peng pengxu...@gmail.com 
mailto:pengxu...@gmail.com wrote:


Mark's suggestion works for me as well. If no one objects, I am
going to start the implementation.

Thanks,
Xu Han

On 09/27/2014 01:05 AM, Mark McClain wrote:


On Sep 26, 2014, at 2:39 AM, Xu Han Peng pengxu...@gmail.com
mailto:pengxu...@gmail.com wrote:


Currently the extra_dhcp_opts has the following API interface on
a port:

{
port:
{
extra_dhcp_opts: [
{opt_value: testfile.1,opt_name: bootfile-name},
{opt_value: 123.123.123.123, opt_name:
tftp-server},
{opt_value: 123.123.123.45, opt_name:
server-ip-address}
],

 }
}

During the development of DHCPv6 function for IPv6 subnets, we
found this format doesn't work anymore because an port can have
both IPv4 and IPv6 address. So we need to find a new way to
specify extra_dhcp_opts for DHCPv4 and DHCPv6, respectively. (
https://bugs.launchpad.net/neutron/+bug/1356383
https://bugs.launchpad.net/neutron/+bug/1356383)

Here are some thoughts about the new format:

Option1: Change the opt_name in extra_dhcp_opts to add a prefix
(v4 or v6) so we can distinguish opts for v4 or v6 by parsing
the opt_name. For backward compatibility, no prefix means IPv4
dhcp opt.

extra_dhcp_opts: [
{opt_value: testfile.1,opt_name: bootfile-name},
{opt_value: 123.123.123.123, opt_name:
*v4:*tftp-server},
{opt_value: [2001:0200:feed:7ac0::1],
opt_name: *v6:*dns-server}
]

Option2: break extra_dhcp_opts into IPv4 opts and IPv6 opts. For
backward compatibility, both old format and new format are
acceptable, but old format means IPv4 dhcp opts.

extra_dhcp_opts: {
 ipv4: [
{opt_value: testfile.1,opt_name:
bootfile-name},
{opt_value: 123.123.123.123, opt_name:
tftp-server},
 ],
 ipv6: [
{opt_value: [2001:0200:feed:7ac0::1],
opt_name: dns-server}
 ]
}

The pro of Option1 is there is no need to change API structure
but only need to add validation and parsing to opt_name. The con
of Option1 is that user need to input prefix for every opt_name
which can be error prone. The pro of Option2 is that it's
clearer than Option1. The con is that we need to check two
formats for backward compatibility.

We discussed this in IPv6 sub-team meeting and we think Option2
is preferred. Can I also get community's feedback on which one
is preferred or any other comments?



I'm -1 for both options because neither is properly backwards
compatible.  Instead we should add an optional 3rd value to the
dictionary: version.  The version key would be used to make the
option only apply to either version 4 or 6.  If the key is
missing or null, then the option would apply to both.

mark



___
OpenStack-dev mailing list

OpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] [IPv6] New API format for extra_dhcp_opts

[Xu Han Peng]

Mark's suggestion works for me as well. If no one objects, I am going to 
start the implementation.


Thanks,
Xu Han

On 09/27/2014 01:05 AM, Mark McClain wrote:


On Sep 26, 2014, at 2:39 AM, Xu Han Peng pengxu...@gmail.com 
mailto:pengxu...@gmail.com wrote:



Currently the extra_dhcp_opts has the following API interface on a port:

{
port:
{
extra_dhcp_opts: [
{opt_value: testfile.1,opt_name: bootfile-name},
{opt_value: 123.123.123.123, opt_name: tftp-server},
{opt_value: 123.123.123.45, opt_name: 
server-ip-address}

],

 }
}

During the development of DHCPv6 function for IPv6 subnets, we found 
this format doesn't work anymore because an port can have both IPv4 
and IPv6 address. So we need to find a new way to specify 
extra_dhcp_opts for DHCPv4 and DHCPv6, respectively. ( 
https://bugs.launchpad.net/neutron/+bug/1356383)


Here are some thoughts about the new format:

Option1: Change the opt_name in extra_dhcp_opts to add a prefix (v4 
or v6) so we can distinguish opts for v4 or v6 by parsing the 
opt_name. For backward compatibility, no prefix means IPv4 dhcp opt.


extra_dhcp_opts: [
{opt_value: testfile.1,opt_name: bootfile-name},
{opt_value: 123.123.123.123, opt_name: 
*v4:*tftp-server},
{opt_value: [2001:0200:feed:7ac0::1], opt_name: 
*v6:*dns-server}

]

Option2: break extra_dhcp_opts into IPv4 opts and IPv6 opts. For 
backward compatibility, both old format and new format are 
acceptable, but old format means IPv4 dhcp opts.


extra_dhcp_opts: {
 ipv4: [
{opt_value: testfile.1,opt_name: 
bootfile-name},
{opt_value: 123.123.123.123, opt_name: 
tftp-server},

 ],
 ipv6: [
{opt_value: [2001:0200:feed:7ac0::1], 
opt_name: dns-server}

 ]
}

The pro of Option1 is there is no need to change API structure but 
only need to add validation and parsing to opt_name. The con of 
Option1 is that user need to input prefix for every opt_name which 
can be error prone. The pro of Option2 is that it's clearer than 
Option1. The con is that we need to check two formats for backward 
compatibility.


We discussed this in IPv6 sub-team meeting and we think Option2 is 
preferred. Can I also get community's feedback on which one is 
preferred or any other comments?




I'm -1 for both options because neither is properly backwards 
compatible.  Instead we should add an optional 3rd value to the 
dictionary: version.  The version key would be used to make the 
option only apply to either version 4 or 6.  If the key is missing or 
null, then the option would apply to both.


mark



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] [IPv6] New API format for extra_dhcp_opts

[Xu Han Peng]

Currently the extra_dhcp_opts has the following API interface on a port:

{
port:
{
extra_dhcp_opts: [
{opt_value: testfile.1,opt_name: bootfile-name},
{opt_value: 123.123.123.123, opt_name: tftp-server},
{opt_value: 123.123.123.45, opt_name: 
server-ip-address}

],

 }
}

During the development of DHCPv6 function for IPv6 subnets, we found 
this format doesn't work anymore because an port can have both IPv4 and 
IPv6 address. So we need to find a new way to specify extra_dhcp_opts 
for DHCPv4 and DHCPv6, respectively. ( 
https://bugs.launchpad.net/neutron/+bug/1356383)


Here are some thoughts about the new format:

Option1: Change the opt_name in extra_dhcp_opts to add a prefix (v4 or 
v6) so we can distinguish opts for v4 or v6 by parsing the opt_name. For 
backward compatibility, no prefix means IPv4 dhcp opt.


extra_dhcp_opts: [
{opt_value: testfile.1,opt_name: bootfile-name},
{opt_value: 123.123.123.123, opt_name: 
*v4:*tftp-server},
{opt_value: [2001:0200:feed:7ac0::1], opt_name: 
*v6:*dns-server}

]

Option2: break extra_dhcp_opts into IPv4 opts and IPv6 opts. For 
backward compatibility, both old format and new format are acceptable, 
but old format means IPv4 dhcp opts.


extra_dhcp_opts: {
 ipv4: [
{opt_value: testfile.1,opt_name: 
bootfile-name},
{opt_value: 123.123.123.123, opt_name: 
tftp-server},

 ],
 ipv6: [
{opt_value: [2001:0200:feed:7ac0::1], 
opt_name: dns-server}

 ]
}

The pro of Option1 is there is no need to change API structure but only 
need to add validation and parsing to opt_name. The con of Option1 is 
that user need to input prefix for every opt_name which can be error 
prone. The pro of Option2 is that it's clearer than Option1. The con is 
that we need to check two formats for backward compatibility.


We discussed this in IPv6 sub-team meeting and we think Option2 is 
preferred. Can I also get community's feedback on which one is preferred 
or any other comments?


Thanks,
Xu Han
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] [IPv6] New API format for extra_dhcp_opts

[Germy Lure]

Hi, Xu Han,
Can we distinguish version by parsing the opt_value? Is there any service
binding v4 address but providing service for v6? or v6 for v4?

BTW, Why not the format is directly opt_name_value:opt_value_value, like 
server-ip-address:1.1.1.1?

BR,
Germy


On Fri, Sep 26, 2014 at 2:39 PM, Xu Han Peng pengxu...@gmail.com wrote:

  Currently the extra_dhcp_opts has the following API interface on a port:

 {
 port:
 {
 extra_dhcp_opts: [
 {opt_value: testfile.1,opt_name: bootfile-name},
 {opt_value: 123.123.123.123, opt_name: tftp-server},
 {opt_value: 123.123.123.45, opt_name:
 server-ip-address}
 ],
 
  }
 }

 During the development of DHCPv6 function for IPv6 subnets, we found this
 format doesn't work anymore because an port can have both IPv4 and IPv6
 address. So we need to find a new way to specify extra_dhcp_opts for DHCPv4
 and DHCPv6, respectively. (
 https://bugs.launchpad.net/neutron/+bug/1356383)

 Here are some thoughts about the new format:

 Option1: Change the opt_name in extra_dhcp_opts to add a prefix (v4 or v6)
 so we can distinguish opts for v4 or v6 by parsing the opt_name. For
 backward compatibility, no prefix means IPv4 dhcp opt.

 extra_dhcp_opts: [
 {opt_value: testfile.1,opt_name: bootfile-name},
 {opt_value: 123.123.123.123, opt_name: *v4:*
 tftp-server},
 {opt_value: [2001:0200:feed:7ac0::1], opt_name: *v6:*
 dns-server}
 ]

 Option2: break extra_dhcp_opts into IPv4 opts and IPv6 opts. For backward
 compatibility, both old format and new format are acceptable, but old
 format means IPv4 dhcp opts.

 extra_dhcp_opts: {
  ipv4: [
 {opt_value: testfile.1,opt_name:
 bootfile-name},
 {opt_value: 123.123.123.123, opt_name:
 tftp-server},
  ],
  ipv6: [
 {opt_value: [2001:0200:feed:7ac0::1], opt_name:
 dns-server}
  ]
 }

 The pro of Option1 is there is no need to change API structure but only
 need to add validation and parsing to opt_name. The con of Option1 is that
 user need to input prefix for every opt_name which can be error prone. The
 pro of Option2 is that it's clearer than Option1. The con is that we need
 to check two formats for backward compatibility.

 We discussed this in IPv6 sub-team meeting and we think Option2 is
 preferred. Can I also get community's feedback on which one is preferred or
 any other comments?

 Thanks,
 Xu Han

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] [IPv6] New API format for extra_dhcp_opts

[Xu Han Peng]

Germy,

We considered this but not all option are address based, therefore we 
cannot determine the IP version by opt value only.


I am not familiar about how the format was original determined either. 
Maybe someone who works on this format before can help clarify?


Xu Han


On 09/26/2014 03:17 PM, Germy Lure wrote:

Hi, Xu Han,
Can we distinguish version by parsing the opt_value? Is there any 
service binding v4 address but providing service for v6? or v6 for v4?


BTW, Why not the format is directly opt_name_value:opt_value_value, 
like server-ip-address:1.1.1.1?


BR,
Germy


On Fri, Sep 26, 2014 at 2:39 PM, Xu Han Peng pengxu...@gmail.com 
mailto:pengxu...@gmail.com wrote:


Currently the extra_dhcp_opts has the following API interface on a
port:

{
port:
{
extra_dhcp_opts: [
{opt_value: testfile.1,opt_name: bootfile-name},
{opt_value: 123.123.123.123, opt_name:
tftp-server},
{opt_value: 123.123.123.45, opt_name:
server-ip-address}
],

 }
}

During the development of DHCPv6 function for IPv6 subnets, we
found this format doesn't work anymore because an port can have
both IPv4 and IPv6 address. So we need to find a new way to
specify extra_dhcp_opts for DHCPv4 and DHCPv6, respectively. (
https://bugs.launchpad.net/neutron/+bug/1356383)

Here are some thoughts about the new format:

Option1: Change the opt_name in extra_dhcp_opts to add a prefix
(v4 or v6) so we can distinguish opts for v4 or v6 by parsing the
opt_name. For backward compatibility, no prefix means IPv4 dhcp opt.

extra_dhcp_opts: [
{opt_value: testfile.1,opt_name: bootfile-name},
{opt_value: 123.123.123.123, opt_name:
*v4:*tftp-server},
{opt_value: [2001:0200:feed:7ac0::1], opt_name:
*v6:*dns-server}
]

Option2: break extra_dhcp_opts into IPv4 opts and IPv6 opts. For
backward compatibility, both old format and new format are
acceptable, but old format means IPv4 dhcp opts.

extra_dhcp_opts: {
 ipv4: [
{opt_value: testfile.1,opt_name:
bootfile-name},
{opt_value: 123.123.123.123, opt_name:
tftp-server},
 ],
 ipv6: [
{opt_value: [2001:0200:feed:7ac0::1],
opt_name: dns-server}
 ]
}

The pro of Option1 is there is no need to change API structure but
only need to add validation and parsing to opt_name. The con of
Option1 is that user need to input prefix for every opt_name which
can be error prone. The pro of Option2 is that it's clearer than
Option1. The con is that we need to check two formats for backward
compatibility.

We discussed this in IPv6 sub-team meeting and we think Option2 is
preferred. Can I also get community's feedback on which one is
preferred or any other comments?

Thanks,
Xu Han

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
mailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] [IPv6] New API format for extra_dhcp_opts

[Mark McClain]

On Sep 26, 2014, at 2:39 AM, Xu Han Peng pengxu...@gmail.com wrote:

 Currently the extra_dhcp_opts has the following API interface on a port:
 
 {
 port:
 {
 extra_dhcp_opts: [
 {opt_value: testfile.1,opt_name: bootfile-name},
 {opt_value: 123.123.123.123, opt_name: tftp-server},
 {opt_value: 123.123.123.45, opt_name: server-ip-address}
 ],
 
  }
 }
 
 During the development of DHCPv6 function for IPv6 subnets, we found this 
 format doesn't work anymore because an port can have both IPv4 and IPv6 
 address. So we need to find a new way to specify extra_dhcp_opts for DHCPv4 
 and DHCPv6, respectively. ( https://bugs.launchpad.net/neutron/+bug/1356383)
 
 Here are some thoughts about the new format:
 
 Option1: Change the opt_name in extra_dhcp_opts to add a prefix (v4 or v6) so 
 we can distinguish opts for v4 or v6 by parsing the opt_name. For backward 
 compatibility, no prefix means IPv4 dhcp opt. 
 
 extra_dhcp_opts: [
 {opt_value: testfile.1,opt_name: bootfile-name},
 {opt_value: 123.123.123.123, opt_name: v4:tftp-server},
 {opt_value: [2001:0200:feed:7ac0::1], opt_name: 
 v6:dns-server}
 ]
 
 Option2: break extra_dhcp_opts into IPv4 opts and IPv6 opts. For backward 
 compatibility, both old format and new format are acceptable, but old format 
 means IPv4 dhcp opts. 
 
 extra_dhcp_opts: {
  ipv4: [
 {opt_value: testfile.1,opt_name: bootfile-name},
 {opt_value: 123.123.123.123, opt_name: 
 tftp-server},
  ],
  ipv6: [
 {opt_value: [2001:0200:feed:7ac0::1], opt_name: 
 dns-server}
  ]
 }
 
 The pro of Option1 is there is no need to change API structure but only need 
 to add validation and parsing to opt_name. The con of Option1 is that user 
 need to input prefix for every opt_name which can be error prone. The pro of 
 Option2 is that it's clearer than Option1. The con is that we need to check 
 two formats for backward compatibility. 
 
 We discussed this in IPv6 sub-team meeting and we think Option2 is preferred. 
 Can I also get community's feedback on which one is preferred or any other 
 comments?
 

I’m -1 for both options because neither is properly backwards compatible.  
Instead we should add an optional 3rd value to the dictionary: “version”.  The 
version key would be used to make the option only apply to either version 4 or 
6.  If the key is missing or null, then the option would apply to both. 

mark

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][IPv6] Neighbor Discovery for HA

[Xu Han Peng]

Hi,

As we talked in last IPv6 sub-team meeting, I was able to construct and 
send IPv6 unsolicited neighbor advertisement for external gateway 
interface by python tool *scapy*:


http://www.secdev.org/projects/scapy/

http://www.idsv6.de/Downloads/IPv6PacketCreationWithScapy.pdf


However, I am having trouble to send this unsolicited neighbor 
advertisement in a given namespace. All the current namespace operations 
leverage ip netns exec and shell command. But we cannot do this to scapy 
since it's python code. Can anyone advise me on this?


Thanks,
Xu Han

On 09/05/2014 05:46 PM, Xu Han Peng wrote:

Carl,

Seem so. I think internal router interface and external gateway port 
GARP are taken care by keepalived during failover. And if HA is not 
enable, _send_gratuitous_arp is called to send out GARP.


I think we will need to take care IPv6 for both cases since keepalived 
1.2.0 support IPv6. May need a separate BP. For the case HA is enabled 
externally, we still need unsolicited neighbor advertisement for 
gateway failover. But for internal router interface, since Router 
Advertisement is automatically send out by RADVD after failover, we 
don't need to send out neighbor advertisement anymore.


Xu Han


On 09/05/2014 03:04 AM, Carl Baldwin wrote:

Hi Xu Han,

Since I sent my message yesterday there has been some more discussion
in the review on that patch set.  See [1] again.  I think your
assessment is likely correct.

Carl

[1] 
https://review.openstack.org/#/c/70700/37/neutron/agent/l3_ha_agent.py


On Thu, Sep 4, 2014 at 3:32 AM, Xu Han Peng pengxu...@gmail.com wrote:

Carl,

Thanks a lot for your reply!

If I understand correctly, in VRRP case, keepalived will be 
responsible for

sending out GARPs? By checking the code you provided, I can see all the
_send_gratuitous_arp_packet call are wrapped by if not is_ha 
condition.


Xu Han



On 09/04/2014 06:06 AM, Carl Baldwin wrote:

It should be noted that send_arp_for_ha is a configuration option
that preceded the more recent in-progress work to add VRRP controlled
HA to Neutron's router.  The option was added, I believe, to cause the
router to send (default) 3 GARPs to the external gateway if the router
was removed from one network node and added to another by some
external script or manual intervention.  It did not send anything on
the internal network ports.

VRRP is a different story and the code in review [1] sends GARPs on
internal and external ports.

Hope this helps avoid confusion in this discussion.

Carl

[1] 
https://review.openstack.org/#/c/70700/37/neutron/agent/l3_ha_agent.py


On Mon, Sep 1, 2014 at 8:52 PM, Xu Han Peng pengxu...@gmail.com 
wrote:


Anthony,

Thanks for your reply.

If HA method like VRRP are used for IPv6 router, according to the 
VRRP RFC
with IPv6 included, the servers should be auto-configured with the 
active

router's LLA as the default route before the failover happens and still
remain that route after the failover. In other word, there should be 
no need

to use two LLAs for default route of a subnet unless load balance is
required.

When the backup router become the master router, the backup router 
should be
responsible for sending out an unsolicited ND neighbor advertisement 
with
the associated LLA (the previous master's LLA) immediately to update 
the
bridge learning state and sending out router advertisement with the 
same
options with the previous master to maintain the route and bridge 
learning.


This is shown in http://tools.ietf.org/html/rfc5798#section-4.1 and the
actions backup router should take after failover is documented here:
http://tools.ietf.org/html/rfc5798#section-6.4.2. The need for 
immediate

messaging sending and periodic message sending is documented here:
http://tools.ietf.org/html/rfc5798#section-2.4

Since the keepalived manager support for L3 HA is merged:
https://review.openstack.org/#/c/68142/43. And keepalived release 1.2.0
supports VRRP IPv6 features ( 
http://www.keepalived.org/changelog.html, see
Release 1.2.0 | VRRP IPv6 Release). I think we can check if 
keepalived can

satisfy our requirement here and if that will cause any conflicts with
RADVD.

Thoughts?

Xu Han


On 08/28/2014 10:11 PM, Veiga, Anthony wrote:



Anthony and Robert,

Thanks for your reply. I don't know if the arping is there for NAT, 
but I am
pretty sure it's for HA setup to broadcast the router's own change 
since the
arping is controlled by send_arp_for_ha config. By checking the 
man page
of arping, you can find the arping -A we use in code is sending 
out ARP
REPLY instead of ARP REQUEST. This is like saying I am here 
instead of
where are you. I didn't realized this either until Brain pointed 
this out

at my code review below.


That’s what I was trying to say earlier.  Sending out the RA is the 
same
effect.  RA says “I’m here, oh and I’m also a router” and should 
supersede
the need for an unsolicited NA.  The only thing to consider here is 
that RAs
are from LLAs.  If you’re doing IPv6 

Re: [openstack-dev] [neutron][IPv6] Neighbor Discovery for HA

[Kevin Benton]

Does running the python script with ip netns exec not work correctly?

On Thu, Sep 25, 2014 at 2:05 AM, Xu Han Peng pengxu...@gmail.com wrote:
 Hi,

 As we talked in last IPv6 sub-team meeting, I was able to construct and send
 IPv6 unsolicited neighbor advertisement for external gateway interface by
 python tool scapy:

 http://www.secdev.org/projects/scapy/

 http://www.idsv6.de/Downloads/IPv6PacketCreationWithScapy.pdf


 However, I am having trouble to send this unsolicited neighbor advertisement
 in a given namespace. All the current namespace operations leverage ip netns
 exec and shell command. But we cannot do this to scapy since it's python
 code. Can anyone advise me on this?

 Thanks,
 Xu Han


 On 09/05/2014 05:46 PM, Xu Han Peng wrote:

 Carl,

 Seem so. I think internal router interface and external gateway port GARP
 are taken care by keepalived during failover. And if HA is not enable,
 _send_gratuitous_arp is called to send out GARP.

 I think we will need to take care IPv6 for both cases since keepalived 1.2.0
 support IPv6. May need a separate BP. For the case HA is enabled externally,
 we still need unsolicited neighbor advertisement for gateway failover. But
 for internal router interface, since Router Advertisement is automatically
 send out by RADVD after failover, we don't need to send out neighbor
 advertisement anymore.

 Xu Han


 On 09/05/2014 03:04 AM, Carl Baldwin wrote:

 Hi Xu Han,

 Since I sent my message yesterday there has been some more discussion
 in the review on that patch set.  See [1] again.  I think your
 assessment is likely correct.

 Carl

 [1] https://review.openstack.org/#/c/70700/37/neutron/agent/l3_ha_agent.py

 On Thu, Sep 4, 2014 at 3:32 AM, Xu Han Peng pengxu...@gmail.com wrote:

 Carl,

 Thanks a lot for your reply!

 If I understand correctly, in VRRP case, keepalived will be responsible for
 sending out GARPs? By checking the code you provided, I can see all the
 _send_gratuitous_arp_packet call are wrapped by if not is_ha condition.

 Xu Han



 On 09/04/2014 06:06 AM, Carl Baldwin wrote:

 It should be noted that send_arp_for_ha is a configuration option
 that preceded the more recent in-progress work to add VRRP controlled
 HA to Neutron's router.  The option was added, I believe, to cause the
 router to send (default) 3 GARPs to the external gateway if the router
 was removed from one network node and added to another by some
 external script or manual intervention.  It did not send anything on
 the internal network ports.

 VRRP is a different story and the code in review [1] sends GARPs on
 internal and external ports.

 Hope this helps avoid confusion in this discussion.

 Carl

 [1] https://review.openstack.org/#/c/70700/37/neutron/agent/l3_ha_agent.py

 On Mon, Sep 1, 2014 at 8:52 PM, Xu Han Peng pengxu...@gmail.com wrote:

 Anthony,

 Thanks for your reply.

 If HA method like VRRP are used for IPv6 router, according to the VRRP RFC
 with IPv6 included, the servers should be auto-configured with the active
 router's LLA as the default route before the failover happens and still
 remain that route after the failover. In other word, there should be no need
 to use two LLAs for default route of a subnet unless load balance is
 required.

 When the backup router become the master router, the backup router should be
 responsible for sending out an unsolicited ND neighbor advertisement with
 the associated LLA (the previous master's LLA) immediately to update the
 bridge learning state and sending out router advertisement with the same
 options with the previous master to maintain the route and bridge learning.

 This is shown in http://tools.ietf.org/html/rfc5798#section-4.1 and the
 actions backup router should take after failover is documented here:
 http://tools.ietf.org/html/rfc5798#section-6.4.2. The need for immediate
 messaging sending and periodic message sending is documented here:
 http://tools.ietf.org/html/rfc5798#section-2.4

 Since the keepalived manager support for L3 HA is merged:
 https://review.openstack.org/#/c/68142/43. And keepalived release 1.2.0
 supports VRRP IPv6 features ( http://www.keepalived.org/changelog.html, see
 Release 1.2.0 | VRRP IPv6 Release). I think we can check if keepalived can
 satisfy our requirement here and if that will cause any conflicts with
 RADVD.

 Thoughts?

 Xu Han


 On 08/28/2014 10:11 PM, Veiga, Anthony wrote:



 Anthony and Robert,

 Thanks for your reply. I don't know if the arping is there for NAT, but I am
 pretty sure it's for HA setup to broadcast the router's own change since the
 arping is controlled by send_arp_for_ha config. By checking the man page
 of arping, you can find the arping -A we use in code is sending out ARP
 REPLY instead of ARP REQUEST. This is like saying I am here instead of
 where are you. I didn't realized this either until Brain pointed this out
 at my code review below.


 That’s what I was trying to say earlier.  Sending out the RA is the same
 effect.  RA 

Re: [openstack-dev] [neutron][IPv6] Neighbor Discovery for HA

[Xu Han Peng]

Sending unsolicited NA by scapy is like this:

from scapy.all import send, IPv6, ICMPv6ND_NA, ICMPv6NDOptDstLLAddr

target_ll_addr = ICMPv6NDOptDstLLAddr(lladdr = mac_address)
unsolicited_na=ICMPv6ND_NA(R=1, S=0, O=1, tgt=target)
packet=IPv6(src=source)/unsolicited_na/target_ll_addr
*send(packet, iface=interface_name, count=10, inter=0.2)*

It's not actually a python script but a python method. Any ideas?

On 09/25/2014 06:20 PM, Kevin Benton wrote:

Does running the python script with ip netns exec not work correctly?

On Thu, Sep 25, 2014 at 2:05 AM, Xu Han Peng pengxu...@gmail.com wrote:

Hi,

As we talked in last IPv6 sub-team meeting, I was able to construct and send
IPv6 unsolicited neighbor advertisement for external gateway interface by
python tool scapy:

http://www.secdev.org/projects/scapy/

http://www.idsv6.de/Downloads/IPv6PacketCreationWithScapy.pdf


However, I am having trouble to send this unsolicited neighbor advertisement
in a given namespace. All the current namespace operations leverage ip netns
exec and shell command. But we cannot do this to scapy since it's python
code. Can anyone advise me on this?

Thanks,
Xu Han


On 09/05/2014 05:46 PM, Xu Han Peng wrote:

Carl,

Seem so. I think internal router interface and external gateway port GARP
are taken care by keepalived during failover. And if HA is not enable,
_send_gratuitous_arp is called to send out GARP.

I think we will need to take care IPv6 for both cases since keepalived 1.2.0
support IPv6. May need a separate BP. For the case HA is enabled externally,
we still need unsolicited neighbor advertisement for gateway failover. But
for internal router interface, since Router Advertisement is automatically
send out by RADVD after failover, we don't need to send out neighbor
advertisement anymore.

Xu Han


On 09/05/2014 03:04 AM, Carl Baldwin wrote:

Hi Xu Han,

Since I sent my message yesterday there has been some more discussion
in the review on that patch set.  See [1] again.  I think your
assessment is likely correct.

Carl

[1] https://review.openstack.org/#/c/70700/37/neutron/agent/l3_ha_agent.py

On Thu, Sep 4, 2014 at 3:32 AM, Xu Han Peng pengxu...@gmail.com wrote:

Carl,

Thanks a lot for your reply!

If I understand correctly, in VRRP case, keepalived will be responsible for
sending out GARPs? By checking the code you provided, I can see all the
_send_gratuitous_arp_packet call are wrapped by if not is_ha condition.

Xu Han



On 09/04/2014 06:06 AM, Carl Baldwin wrote:

It should be noted that send_arp_for_ha is a configuration option
that preceded the more recent in-progress work to add VRRP controlled
HA to Neutron's router.  The option was added, I believe, to cause the
router to send (default) 3 GARPs to the external gateway if the router
was removed from one network node and added to another by some
external script or manual intervention.  It did not send anything on
the internal network ports.

VRRP is a different story and the code in review [1] sends GARPs on
internal and external ports.

Hope this helps avoid confusion in this discussion.

Carl

[1] https://review.openstack.org/#/c/70700/37/neutron/agent/l3_ha_agent.py

On Mon, Sep 1, 2014 at 8:52 PM, Xu Han Peng pengxu...@gmail.com wrote:

Anthony,

Thanks for your reply.

If HA method like VRRP are used for IPv6 router, according to the VRRP RFC
with IPv6 included, the servers should be auto-configured with the active
router's LLA as the default route before the failover happens and still
remain that route after the failover. In other word, there should be no need
to use two LLAs for default route of a subnet unless load balance is
required.

When the backup router become the master router, the backup router should be
responsible for sending out an unsolicited ND neighbor advertisement with
the associated LLA (the previous master's LLA) immediately to update the
bridge learning state and sending out router advertisement with the same
options with the previous master to maintain the route and bridge learning.

This is shown in http://tools.ietf.org/html/rfc5798#section-4.1 and the
actions backup router should take after failover is documented here:
http://tools.ietf.org/html/rfc5798#section-6.4.2. The need for immediate
messaging sending and periodic message sending is documented here:
http://tools.ietf.org/html/rfc5798#section-2.4

Since the keepalived manager support for L3 HA is merged:
https://review.openstack.org/#/c/68142/43. And keepalived release 1.2.0
supports VRRP IPv6 features ( http://www.keepalived.org/changelog.html, see
Release 1.2.0 | VRRP IPv6 Release). I think we can check if keepalived can
satisfy our requirement here and if that will cause any conflicts with
RADVD.

Thoughts?

Xu Han


On 08/28/2014 10:11 PM, Veiga, Anthony wrote:



Anthony and Robert,

Thanks for your reply. I don't know if the arping is there for NAT, but I am
pretty sure it's for HA setup to broadcast the router's own change since the
arping is 

Re: [openstack-dev] [neutron][IPv6] Neighbor Discovery for HA

[Vishvananda Ishaya]

You are going to have to make this as a separate binary and call it
via rootwrap ip netns exec. While it is possible to change network
namespaces in python, you aren’t going to be able to do this consistently
without root access, so it will need to be guarded by rootwrap anyway.

Vish

On Sep 25, 2014, at 7:00 PM, Xu Han Peng pengxu...@gmail.com wrote:

 Sending unsolicited NA by scapy is like this:
 
 from scapy.all import send, IPv6, ICMPv6ND_NA, ICMPv6NDOptDstLLAddr
 
 target_ll_addr = ICMPv6NDOptDstLLAddr(lladdr = mac_address)
 unsolicited_na=ICMPv6ND_NA(R=1, S=0, O=1, tgt=target)
 packet=IPv6(src=source)/unsolicited_na/target_ll_addr
 send(packet, iface=interface_name, count=10, inter=0.2)
 
 It's not actually a python script but a python method. Any ideas?
 
 On 09/25/2014 06:20 PM, Kevin Benton wrote:
 Does running the python script with ip netns exec not work correctly?
 
 On Thu, Sep 25, 2014 at 2:05 AM, Xu Han Peng pengxu...@gmail.com wrote:
 Hi,
 
 As we talked in last IPv6 sub-team meeting, I was able to construct and send
 IPv6 unsolicited neighbor advertisement for external gateway interface by
 python tool scapy:
 
 http://www.secdev.org/projects/scapy/
 
 http://www.idsv6.de/Downloads/IPv6PacketCreationWithScapy.pdf
 
 
 However, I am having trouble to send this unsolicited neighbor advertisement
 in a given namespace. All the current namespace operations leverage ip netns
 exec and shell command. But we cannot do this to scapy since it's python
 code. Can anyone advise me on this?
 
 Thanks,
 Xu Han
 
 
 On 09/05/2014 05:46 PM, Xu Han Peng wrote:
 
 Carl,
 
 Seem so. I think internal router interface and external gateway port GARP
 are taken care by keepalived during failover. And if HA is not enable,
 _send_gratuitous_arp is called to send out GARP.
 
 I think we will need to take care IPv6 for both cases since keepalived 1.2.0
 support IPv6. May need a separate BP. For the case HA is enabled externally,
 we still need unsolicited neighbor advertisement for gateway failover. But
 for internal router interface, since Router Advertisement is automatically
 send out by RADVD after failover, we don't need to send out neighbor
 advertisement anymore.
 
 Xu Han
 
 
 On 09/05/2014 03:04 AM, Carl Baldwin wrote:
 
 Hi Xu Han,
 
 Since I sent my message yesterday there has been some more discussion
 in the review on that patch set.  See [1] again.  I think your
 assessment is likely correct.
 
 Carl
 
 [1] https://review.openstack.org/#/c/70700/37/neutron/agent/l3_ha_agent.py
 
 On Thu, Sep 4, 2014 at 3:32 AM, Xu Han Peng pengxu...@gmail.com wrote:
 
 Carl,
 
 Thanks a lot for your reply!
 
 If I understand correctly, in VRRP case, keepalived will be responsible for
 sending out GARPs? By checking the code you provided, I can see all the
 _send_gratuitous_arp_packet call are wrapped by if not is_ha condition.
 
 Xu Han
 
 
 
 On 09/04/2014 06:06 AM, Carl Baldwin wrote:
 
 It should be noted that send_arp_for_ha is a configuration option
 that preceded the more recent in-progress work to add VRRP controlled
 HA to Neutron's router.  The option was added, I believe, to cause the
 router to send (default) 3 GARPs to the external gateway if the router
 was removed from one network node and added to another by some
 external script or manual intervention.  It did not send anything on
 the internal network ports.
 
 VRRP is a different story and the code in review [1] sends GARPs on
 internal and external ports.
 
 Hope this helps avoid confusion in this discussion.
 
 Carl
 
 [1] https://review.openstack.org/#/c/70700/37/neutron/agent/l3_ha_agent.py
 
 On Mon, Sep 1, 2014 at 8:52 PM, Xu Han Peng pengxu...@gmail.com wrote:
 
 Anthony,
 
 Thanks for your reply.
 
 If HA method like VRRP are used for IPv6 router, according to the VRRP RFC
 with IPv6 included, the servers should be auto-configured with the active
 router's LLA as the default route before the failover happens and still
 remain that route after the failover. In other word, there should be no need
 to use two LLAs for default route of a subnet unless load balance is
 required.
 
 When the backup router become the master router, the backup router should be
 responsible for sending out an unsolicited ND neighbor advertisement with
 the associated LLA (the previous master's LLA) immediately to update the
 bridge learning state and sending out router advertisement with the same
 options with the previous master to maintain the route and bridge learning.
 
 This is shown in http://tools.ietf.org/html/rfc5798#section-4.1 and the
 actions backup router should take after failover is documented here:
 http://tools.ietf.org/html/rfc5798#section-6.4.2. The need for immediate
 messaging sending and periodic message sending is documented here:
 http://tools.ietf.org/html/rfc5798#section-2.4
 
 Since the keepalived manager support for L3 HA is merged:
 https://review.openstack.org/#/c/68142/43. And keepalived release 1.2.0
 

Re: [openstack-dev] [neutron][IPv6] Neighbor Discovery for HA

[Xu Han Peng]

Carl,

Seem so. I think internal router interface and external gateway port 
GARP are taken care by keepalived during failover. And if HA is not 
enable, _send_gratuitous_arp is called to send out GARP.


I think we will need to take care IPv6 for both cases since keepalived 
1.2.0 support IPv6. May need a separate BP. For the case HA is enabled 
externally, we still need unsolicited neighbor advertisement for gateway 
failover. But for internal router interface, since Router Advertisement 
is automatically send out by RADVD after failover, we don't need to send 
out neighbor advertisement anymore.


Xu Han


On 09/05/2014 03:04 AM, Carl Baldwin wrote:

Hi Xu Han,

Since I sent my message yesterday there has been some more discussion
in the review on that patch set.  See [1] again.  I think your
assessment is likely correct.

Carl

[1] https://review.openstack.org/#/c/70700/37/neutron/agent/l3_ha_agent.py

On Thu, Sep 4, 2014 at 3:32 AM, Xu Han Peng pengxu...@gmail.com wrote:

Carl,

Thanks a lot for your reply!

If I understand correctly, in VRRP case, keepalived will be responsible for
sending out GARPs? By checking the code you provided, I can see all the
_send_gratuitous_arp_packet call are wrapped by if not is_ha condition.

Xu Han



On 09/04/2014 06:06 AM, Carl Baldwin wrote:

It should be noted that send_arp_for_ha is a configuration option
that preceded the more recent in-progress work to add VRRP controlled
HA to Neutron's router.  The option was added, I believe, to cause the
router to send (default) 3 GARPs to the external gateway if the router
was removed from one network node and added to another by some
external script or manual intervention.  It did not send anything on
the internal network ports.

VRRP is a different story and the code in review [1] sends GARPs on
internal and external ports.

Hope this helps avoid confusion in this discussion.

Carl

[1] https://review.openstack.org/#/c/70700/37/neutron/agent/l3_ha_agent.py

On Mon, Sep 1, 2014 at 8:52 PM, Xu Han Peng pengxu...@gmail.com wrote:

Anthony,

Thanks for your reply.

If HA method like VRRP are used for IPv6 router, according to the VRRP RFC
with IPv6 included, the servers should be auto-configured with the active
router's LLA as the default route before the failover happens and still
remain that route after the failover. In other word, there should be no need
to use two LLAs for default route of a subnet unless load balance is
required.

When the backup router become the master router, the backup router should be
responsible for sending out an unsolicited ND neighbor advertisement with
the associated LLA (the previous master's LLA) immediately to update the
bridge learning state and sending out router advertisement with the same
options with the previous master to maintain the route and bridge learning.

This is shown in http://tools.ietf.org/html/rfc5798#section-4.1 and the
actions backup router should take after failover is documented here:
http://tools.ietf.org/html/rfc5798#section-6.4.2. The need for immediate
messaging sending and periodic message sending is documented here:
http://tools.ietf.org/html/rfc5798#section-2.4

Since the keepalived manager support for L3 HA is merged:
https://review.openstack.org/#/c/68142/43. And keepalived release 1.2.0
supports VRRP IPv6 features ( http://www.keepalived.org/changelog.html, see
Release 1.2.0 | VRRP IPv6 Release). I think we can check if keepalived can
satisfy our requirement here and if that will cause any conflicts with
RADVD.

Thoughts?

Xu Han


On 08/28/2014 10:11 PM, Veiga, Anthony wrote:



Anthony and Robert,

Thanks for your reply. I don't know if the arping is there for NAT, but I am
pretty sure it's for HA setup to broadcast the router's own change since the
arping is controlled by send_arp_for_ha config. By checking the man page
of arping, you can find the arping -A we use in code is sending out ARP
REPLY instead of ARP REQUEST. This is like saying I am here instead of
where are you. I didn't realized this either until Brain pointed this out
at my code review below.


That’s what I was trying to say earlier.  Sending out the RA is the same
effect.  RA says “I’m here, oh and I’m also a router” and should supersede
the need for an unsolicited NA.  The only thing to consider here is that RAs
are from LLAs.  If you’re doing IPv6 HA, you’ll need to have two gateway IPs
for the RA of the standby to work.  So far as I know, I think there’s still
a bug out on this since you can only have one gateway per subnet.



http://linux.die.net/man/8/arping

https://review.openstack.org/#/c/114437/2/neutron/agent/l3_agent.py

Thoughts?

Xu Han


On 08/27/2014 10:01 PM, Veiga, Anthony wrote:


Hi Xuhan,

What I saw is that GARP is sent to the gateway port and also to the router
ports, from a neutron router. I’m not sure why it’s sent to the router ports
(internal network). My understanding for arping to the gateway port is that
it is needed for proper NAT operation. Since we are 

Re: [openstack-dev] [neutron][IPv6] Neighbor Discovery for HA

[Xu Han Peng]

Carl,

Thanks a lot for your reply!

If I understand correctly, in VRRP case, keepalived will be responsible 
for sending out GARPs? By checking the code you provided, I can see all 
the _send_gratuitous_arp_packet call are wrapped by if not is_ha 
condition.


Xu Han


On 09/04/2014 06:06 AM, Carl Baldwin wrote:

It should be noted that send_arp_for_ha is a configuration option
that preceded the more recent in-progress work to add VRRP controlled
HA to Neutron's router.  The option was added, I believe, to cause the
router to send (default) 3 GARPs to the external gateway if the router
was removed from one network node and added to another by some
external script or manual intervention.  It did not send anything on
the internal network ports.

VRRP is a different story and the code in review [1] sends GARPs on
internal and external ports.

Hope this helps avoid confusion in this discussion.

Carl

[1] https://review.openstack.org/#/c/70700/37/neutron/agent/l3_ha_agent.py

On Mon, Sep 1, 2014 at 8:52 PM, Xu Han Peng pengxu...@gmail.com wrote:

Anthony,

Thanks for your reply.

If HA method like VRRP are used for IPv6 router, according to the VRRP RFC
with IPv6 included, the servers should be auto-configured with the active
router's LLA as the default route before the failover happens and still
remain that route after the failover. In other word, there should be no need
to use two LLAs for default route of a subnet unless load balance is
required.

When the backup router become the master router, the backup router should be
responsible for sending out an unsolicited ND neighbor advertisement with
the associated LLA (the previous master's LLA) immediately to update the
bridge learning state and sending out router advertisement with the same
options with the previous master to maintain the route and bridge learning.

This is shown in http://tools.ietf.org/html/rfc5798#section-4.1 and the
actions backup router should take after failover is documented here:
http://tools.ietf.org/html/rfc5798#section-6.4.2. The need for immediate
messaging sending and periodic message sending is documented here:
http://tools.ietf.org/html/rfc5798#section-2.4

Since the keepalived manager support for L3 HA is merged:
https://review.openstack.org/#/c/68142/43. And keepalived release 1.2.0
supports VRRP IPv6 features ( http://www.keepalived.org/changelog.html, see
Release 1.2.0 | VRRP IPv6 Release). I think we can check if keepalived can
satisfy our requirement here and if that will cause any conflicts with
RADVD.

Thoughts?

Xu Han


On 08/28/2014 10:11 PM, Veiga, Anthony wrote:



Anthony and Robert,

Thanks for your reply. I don't know if the arping is there for NAT, but I am
pretty sure it's for HA setup to broadcast the router's own change since the
arping is controlled by send_arp_for_ha config. By checking the man page
of arping, you can find the arping -A we use in code is sending out ARP
REPLY instead of ARP REQUEST. This is like saying I am here instead of
where are you. I didn't realized this either until Brain pointed this out
at my code review below.


That’s what I was trying to say earlier.  Sending out the RA is the same
effect.  RA says “I’m here, oh and I’m also a router” and should supersede
the need for an unsolicited NA.  The only thing to consider here is that RAs
are from LLAs.  If you’re doing IPv6 HA, you’ll need to have two gateway IPs
for the RA of the standby to work.  So far as I know, I think there’s still
a bug out on this since you can only have one gateway per subnet.



http://linux.die.net/man/8/arping

https://review.openstack.org/#/c/114437/2/neutron/agent/l3_agent.py

Thoughts?

Xu Han


On 08/27/2014 10:01 PM, Veiga, Anthony wrote:


Hi Xuhan,

What I saw is that GARP is sent to the gateway port and also to the router
ports, from a neutron router. I’m not sure why it’s sent to the router ports
(internal network). My understanding for arping to the gateway port is that
it is needed for proper NAT operation. Since we are not planning to support
ipv6 NAT, so this is not required/needed for ipv6 any more?


I agree that this is no longer necessary.


There is an abandoned patch that disabled the arping for ipv6 gateway port:
https://review.openstack.org/#/c/77471/3/neutron/agent/l3_agent.py

thanks,
Robert

On 8/27/14, 1:03 AM, Xuhan Peng pengxu...@gmail.com wrote:

As a follow-up action of yesterday's IPv6 sub-team meeting, I would like to
start a discussion about how to support l3 agent HA when IP version is IPv6.

This problem is triggered by bug [1] where sending gratuitous arp packet for
HA doesn't work for IPv6 subnet gateways. This is because neighbor discovery
instead of ARP should be used for IPv6.

My thought to solve this problem turns into how to send out neighbor
advertisement for IPv6 routers just like sending ARP reply for IPv4 routers
after reading the comments on code review [2].

I searched for utilities which can do this and only find a utility called
ndsend [3] as part of 

Re: [openstack-dev] [neutron][IPv6] Neighbor Discovery for HA

[Carl Baldwin]

Hi Xu Han,

Since I sent my message yesterday there has been some more discussion
in the review on that patch set.  See [1] again.  I think your
assessment is likely correct.

Carl

[1] https://review.openstack.org/#/c/70700/37/neutron/agent/l3_ha_agent.py

On Thu, Sep 4, 2014 at 3:32 AM, Xu Han Peng pengxu...@gmail.com wrote:
 Carl,

 Thanks a lot for your reply!

 If I understand correctly, in VRRP case, keepalived will be responsible for
 sending out GARPs? By checking the code you provided, I can see all the
 _send_gratuitous_arp_packet call are wrapped by if not is_ha condition.

 Xu Han



 On 09/04/2014 06:06 AM, Carl Baldwin wrote:

 It should be noted that send_arp_for_ha is a configuration option
 that preceded the more recent in-progress work to add VRRP controlled
 HA to Neutron's router.  The option was added, I believe, to cause the
 router to send (default) 3 GARPs to the external gateway if the router
 was removed from one network node and added to another by some
 external script or manual intervention.  It did not send anything on
 the internal network ports.

 VRRP is a different story and the code in review [1] sends GARPs on
 internal and external ports.

 Hope this helps avoid confusion in this discussion.

 Carl

 [1] https://review.openstack.org/#/c/70700/37/neutron/agent/l3_ha_agent.py

 On Mon, Sep 1, 2014 at 8:52 PM, Xu Han Peng pengxu...@gmail.com wrote:

 Anthony,

 Thanks for your reply.

 If HA method like VRRP are used for IPv6 router, according to the VRRP RFC
 with IPv6 included, the servers should be auto-configured with the active
 router's LLA as the default route before the failover happens and still
 remain that route after the failover. In other word, there should be no need
 to use two LLAs for default route of a subnet unless load balance is
 required.

 When the backup router become the master router, the backup router should be
 responsible for sending out an unsolicited ND neighbor advertisement with
 the associated LLA (the previous master's LLA) immediately to update the
 bridge learning state and sending out router advertisement with the same
 options with the previous master to maintain the route and bridge learning.

 This is shown in http://tools.ietf.org/html/rfc5798#section-4.1 and the
 actions backup router should take after failover is documented here:
 http://tools.ietf.org/html/rfc5798#section-6.4.2. The need for immediate
 messaging sending and periodic message sending is documented here:
 http://tools.ietf.org/html/rfc5798#section-2.4

 Since the keepalived manager support for L3 HA is merged:
 https://review.openstack.org/#/c/68142/43. And keepalived release 1.2.0
 supports VRRP IPv6 features ( http://www.keepalived.org/changelog.html, see
 Release 1.2.0 | VRRP IPv6 Release). I think we can check if keepalived can
 satisfy our requirement here and if that will cause any conflicts with
 RADVD.

 Thoughts?

 Xu Han


 On 08/28/2014 10:11 PM, Veiga, Anthony wrote:



 Anthony and Robert,

 Thanks for your reply. I don't know if the arping is there for NAT, but I am
 pretty sure it's for HA setup to broadcast the router's own change since the
 arping is controlled by send_arp_for_ha config. By checking the man page
 of arping, you can find the arping -A we use in code is sending out ARP
 REPLY instead of ARP REQUEST. This is like saying I am here instead of
 where are you. I didn't realized this either until Brain pointed this out
 at my code review below.


 That’s what I was trying to say earlier.  Sending out the RA is the same
 effect.  RA says “I’m here, oh and I’m also a router” and should supersede
 the need for an unsolicited NA.  The only thing to consider here is that RAs
 are from LLAs.  If you’re doing IPv6 HA, you’ll need to have two gateway IPs
 for the RA of the standby to work.  So far as I know, I think there’s still
 a bug out on this since you can only have one gateway per subnet.



 http://linux.die.net/man/8/arping

 https://review.openstack.org/#/c/114437/2/neutron/agent/l3_agent.py

 Thoughts?

 Xu Han


 On 08/27/2014 10:01 PM, Veiga, Anthony wrote:


 Hi Xuhan,

 What I saw is that GARP is sent to the gateway port and also to the router
 ports, from a neutron router. I’m not sure why it’s sent to the router ports
 (internal network). My understanding for arping to the gateway port is that
 it is needed for proper NAT operation. Since we are not planning to support
 ipv6 NAT, so this is not required/needed for ipv6 any more?


 I agree that this is no longer necessary.


 There is an abandoned patch that disabled the arping for ipv6 gateway port:
 https://review.openstack.org/#/c/77471/3/neutron/agent/l3_agent.py

 thanks,
 Robert

 On 8/27/14, 1:03 AM, Xuhan Peng pengxu...@gmail.com wrote:

 As a follow-up action of yesterday's IPv6 sub-team meeting, I would like to
 start a discussion about how to support l3 agent HA when IP version is IPv6.

 This problem is triggered by bug [1] where sending gratuitous arp packet for
 HA 

Re: [openstack-dev] [neutron][IPv6] Neighbor Discovery for HA

[Carl Baldwin]

It should be noted that send_arp_for_ha is a configuration option
that preceded the more recent in-progress work to add VRRP controlled
HA to Neutron's router.  The option was added, I believe, to cause the
router to send (default) 3 GARPs to the external gateway if the router
was removed from one network node and added to another by some
external script or manual intervention.  It did not send anything on
the internal network ports.

VRRP is a different story and the code in review [1] sends GARPs on
internal and external ports.

Hope this helps avoid confusion in this discussion.

Carl

[1] https://review.openstack.org/#/c/70700/37/neutron/agent/l3_ha_agent.py

On Mon, Sep 1, 2014 at 8:52 PM, Xu Han Peng pengxu...@gmail.com wrote:
 Anthony,

 Thanks for your reply.

 If HA method like VRRP are used for IPv6 router, according to the VRRP RFC
 with IPv6 included, the servers should be auto-configured with the active
 router's LLA as the default route before the failover happens and still
 remain that route after the failover. In other word, there should be no need
 to use two LLAs for default route of a subnet unless load balance is
 required.

 When the backup router become the master router, the backup router should be
 responsible for sending out an unsolicited ND neighbor advertisement with
 the associated LLA (the previous master's LLA) immediately to update the
 bridge learning state and sending out router advertisement with the same
 options with the previous master to maintain the route and bridge learning.

 This is shown in http://tools.ietf.org/html/rfc5798#section-4.1 and the
 actions backup router should take after failover is documented here:
 http://tools.ietf.org/html/rfc5798#section-6.4.2. The need for immediate
 messaging sending and periodic message sending is documented here:
 http://tools.ietf.org/html/rfc5798#section-2.4

 Since the keepalived manager support for L3 HA is merged:
 https://review.openstack.org/#/c/68142/43. And keepalived release 1.2.0
 supports VRRP IPv6 features ( http://www.keepalived.org/changelog.html, see
 Release 1.2.0 | VRRP IPv6 Release). I think we can check if keepalived can
 satisfy our requirement here and if that will cause any conflicts with
 RADVD.

 Thoughts?

 Xu Han


 On 08/28/2014 10:11 PM, Veiga, Anthony wrote:



 Anthony and Robert,

 Thanks for your reply. I don't know if the arping is there for NAT, but I am
 pretty sure it's for HA setup to broadcast the router's own change since the
 arping is controlled by send_arp_for_ha config. By checking the man page
 of arping, you can find the arping -A we use in code is sending out ARP
 REPLY instead of ARP REQUEST. This is like saying I am here instead of
 where are you. I didn't realized this either until Brain pointed this out
 at my code review below.


 That’s what I was trying to say earlier.  Sending out the RA is the same
 effect.  RA says “I’m here, oh and I’m also a router” and should supersede
 the need for an unsolicited NA.  The only thing to consider here is that RAs
 are from LLAs.  If you’re doing IPv6 HA, you’ll need to have two gateway IPs
 for the RA of the standby to work.  So far as I know, I think there’s still
 a bug out on this since you can only have one gateway per subnet.



 http://linux.die.net/man/8/arping

 https://review.openstack.org/#/c/114437/2/neutron/agent/l3_agent.py

 Thoughts?

 Xu Han


 On 08/27/2014 10:01 PM, Veiga, Anthony wrote:


 Hi Xuhan,

 What I saw is that GARP is sent to the gateway port and also to the router
 ports, from a neutron router. I’m not sure why it’s sent to the router ports
 (internal network). My understanding for arping to the gateway port is that
 it is needed for proper NAT operation. Since we are not planning to support
 ipv6 NAT, so this is not required/needed for ipv6 any more?


 I agree that this is no longer necessary.


 There is an abandoned patch that disabled the arping for ipv6 gateway port:
 https://review.openstack.org/#/c/77471/3/neutron/agent/l3_agent.py

 thanks,
 Robert

 On 8/27/14, 1:03 AM, Xuhan Peng pengxu...@gmail.com wrote:

 As a follow-up action of yesterday's IPv6 sub-team meeting, I would like to
 start a discussion about how to support l3 agent HA when IP version is IPv6.

 This problem is triggered by bug [1] where sending gratuitous arp packet for
 HA doesn't work for IPv6 subnet gateways. This is because neighbor discovery
 instead of ARP should be used for IPv6.

 My thought to solve this problem turns into how to send out neighbor
 advertisement for IPv6 routers just like sending ARP reply for IPv4 routers
 after reading the comments on code review [2].

 I searched for utilities which can do this and only find a utility called
 ndsend [3] as part of vzctl on ubuntu. I could not find similar tools on
 other linux distributions.

 There are comments in yesterday's meeting that it's the new router's job to
 send out RA and there is no need for neighbor discovery. But we didn't get
 enough time to 

Re: [openstack-dev] [neutron][IPv6] Neighbor Discovery for HA

[Martinx - ジェームズ]

Sounds impressive!   :-D


On 1 September 2014 23:52, Xu Han Peng pengxu...@gmail.com wrote:

  Anthony,

 Thanks for your reply.

 If HA method like VRRP are used for IPv6 router, according to the VRRP RFC
 with IPv6 included, the servers should be auto-configured with the active
 router's LLA as the default route before the failover happens and still
 remain that route after the failover. In other word, there should be no
 need to use two LLAs for default route of a subnet unless load balance is
 required.

 When the backup router become the master router, the backup router should
 be responsible for sending out an unsolicited ND neighbor advertisement
 with the associated LLA (the previous master's LLA) immediately to update
 the bridge learning state and sending out router advertisement with the
 same options with the previous master to maintain the route and bridge
 learning.

 This is shown in http://tools.ietf.org/html/rfc5798#section-4.1 and the
 actions backup router should take after failover is documented here:
 http://tools.ietf.org/html/rfc5798#section-6.4.2. The need for immediate
 messaging sending and periodic message sending is documented here:
 http://tools.ietf.org/html/rfc5798#section-2.4

 Since the keepalived manager support for L3 HA is merged:
 https://review.openstack.org/#/c/68142/43. And keepalived release 1.2.0
 supports VRRP IPv6 features ( http://www.keepalived.org/changelog.html,
 see Release 1.2.0 | VRRP IPv6 Release). I think we can check if keepalived
 can satisfy our requirement here and if that will cause any conflicts with
 RADVD.

 Thoughts?

 Xu Han


 On 08/28/2014 10:11 PM, Veiga, Anthony wrote:



   Anthony and Robert,

 Thanks for your reply. I don't know if the arping is there for NAT, but I
 am pretty sure it's for HA setup to broadcast the router's own change since
 the arping is controlled by send_arp_for_ha config. By checking the man
 page of arping, you can find the arping -A we use in code is sending out
 ARP REPLY instead of ARP REQUEST. This is like saying I am here instead
 of where are you. I didn't realized this either until Brain pointed this
 out at my code review below.


  That’s what I was trying to say earlier.  Sending out the RA is the same
 effect.  RA says “I’m here, oh and I’m also a router” and should supersede
 the need for an unsolicited NA.  The only thing to consider here is that
 RAs are from LLAs.  If you’re doing IPv6 HA, you’ll need to have two
 gateway IPs for the RA of the standby to work.  So far as I know, I think
 there’s still a bug out on this since you can only have one gateway per
 subnet.



 http://linux.die.net/man/8/arping

 https://review.openstack.org/#/c/114437/2/neutron/agent/l3_agent.py

 Thoughts?

 Xu Han


 On 08/27/2014 10:01 PM, Veiga, Anthony wrote:


 Hi Xuhan,

  What I saw is that GARP is sent to the gateway port and also to the
 router ports, from a neutron router. I’m not sure why it’s sent to the
 router ports (internal network). My understanding for arping to the gateway
 port is that it is needed for proper NAT operation. Since we are not
 planning to support ipv6 NAT, so this is not required/needed for ipv6 any
 more?


  I agree that this is no longer necessary.


  There is an abandoned patch that disabled the arping for ipv6 gateway
 port:  https://review.openstack.org/#/c/77471/3/neutron/agent/l3_agent.py

  thanks,
 Robert

   On 8/27/14, 1:03 AM, Xuhan Peng pengxu...@gmail.com wrote:

   As a follow-up action of yesterday's IPv6 sub-team meeting, I would
 like to start a discussion about how to support l3 agent HA when IP version
 is IPv6.

  This problem is triggered by bug [1] where sending gratuitous arp packet
 for HA doesn't work for IPv6 subnet gateways. This is because neighbor
 discovery instead of ARP should be used for IPv6.

  My thought to solve this problem turns into how to send out neighbor
 advertisement for IPv6 routers just like sending ARP reply for IPv4 routers
 after reading the comments on code review [2].

  I searched for utilities which can do this and only find a utility
 called ndsend [3] as part of vzctl on ubuntu. I could not find similar
 tools on other linux distributions.

  There are comments in yesterday's meeting that it's the new router's job
 to send out RA and there is no need for neighbor discovery. But we didn't
 get enough time to finish the discussion.


  Because OpenStack runs the l3 agent, it is the router.  Instead of
 needing to do gratuitous ARP to alert all clients of the new MAC, a simple
 RA from the new router for the same prefix would accomplish the same,
 without having to resort to a special package to generate unsolicited NA
 packets.  RAs must be generated from the l3 agent anyway if it’s the
 gateway, and we’re doing that via radvd now.  The HA failover simply needs
 to start the proper radvd process on the secondary gateway and resume
 normal operation.


  Can you comment your thoughts about how to solve this problem in this
 

[openstack-dev] [Neutron][IPv6] Moving meeting time to 1500 UTC on Tuesdays on #openstack-meeting-alt?

[Collins, Sean]

Any objection? We need to move the time since the main meeting conflicts
with our current time slot.

Discussion from today's meeting:

http://eavesdrop.openstack.org/meetings/neutron_ipv6/2014/neutron_ipv6.2014-09-02-13.59.log.html

-- 
Sean M. Collins
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][IPv6] Moving meeting time to 1500 UTC on Tuesdays on #openstack-meeting-alt?

[Kyle Mestery]

On Tue, Sep 2, 2014 at 4:05 PM, Collins, Sean
sean_colli...@cable.comcast.com wrote:
 Any objection? We need to move the time since the main meeting conflicts
 with our current time slot.

If you do that, I'll take over #openstack-meeting from you for the
Neutron meeting, so let me know once this meeting moves and I'll
update the wiki for the main neutron meeting.

Thanks,
Kyle

 Discussion from today's meeting:

 http://eavesdrop.openstack.org/meetings/neutron_ipv6/2014/neutron_ipv6.2014-09-02-13.59.log.html

 --
 Sean M. Collins
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][IPv6] Neighbor Discovery for HA

[Xu Han Peng]

Anthony,

Thanks for your reply.

If HA method like VRRP are used for IPv6 router, according to the VRRP 
RFC with IPv6 included, the servers should be auto-configured with the 
active router's LLA as the default route before the failover happens and 
still remain that route after the failover. In other word, there should 
be no need to use two LLAs for default route of a subnet unless load 
balance is required.


When the backup router become the master router, the backup router 
should be responsible for sending out an unsolicited ND neighbor 
advertisement with the associated LLA (the previous master's LLA) 
immediately to update the bridge learning state and sending out router 
advertisement with the same options with the previous master to maintain 
the route and bridge learning.


This is shown in http://tools.ietf.org/html/rfc5798#section-4.1 and the 
actions backup router should take after failover is documented here: 
http://tools.ietf.org/html/rfc5798#section-6.4.2. The need for immediate 
messaging sending and periodic message sending is documented here: 
http://tools.ietf.org/html/rfc5798#section-2.4


Since the keepalived manager support for L3 HA is merged: 
https://review.openstack.org/#/c/68142/43. And keepalived release 1.2.0 
supports VRRP IPv6 features ( http://www.keepalived.org/changelog.html, 
see Release 1.2.0 | VRRP IPv6 Release). I think we can check if 
keepalived can satisfy our requirement here and if that will cause any 
conflicts with RADVD.


Thoughts?

Xu Han

On 08/28/2014 10:11 PM, Veiga, Anthony wrote:



Anthony and Robert,

Thanks for your reply. I don't know if the arping is there for
NAT, but I am pretty sure it's for HA setup to broadcast the
router's own change since the arping is controlled by
send_arp_for_ha config. By checking the man page of arping, you
can find the arping -A we use in code is sending out ARP REPLY
instead of ARP REQUEST. This is like saying I am here instead of
where are you. I didn't realized this either until Brain pointed
this out at my code review below.


That's what I was trying to say earlier.  Sending out the RA is the 
same effect.  RA says I'm here, oh and I'm also a router and should 
supersede the need for an unsolicited NA.  The only thing to consider 
here is that RAs are from LLAs.  If you're doing IPv6 HA, you'll need 
to have two gateway IPs for the RA of the standby to work.  So far as 
I know, I think there's still a bug out on this since you can only 
have one gateway per subnet.




http://linux.die.net/man/8/arping

https://review.openstack.org/#/c/114437/2/neutron/agent/l3_agent.py

Thoughts?

Xu Han


On 08/27/2014 10:01 PM, Veiga, Anthony wrote:



Hi Xuhan,

What I saw is that GARP is sent to the gateway port and also
to the router ports, from a neutron router. I'm not sure why
it's sent to the router ports (internal network). My
understanding for arping to the gateway port is that it is
needed for proper NAT operation. Since we are not planning to
support ipv6 NAT, so this is not required/needed for ipv6 any
more?


I agree that this is no longer necessary.


There is an abandoned patch that disabled the arping for ipv6
gateway port:
https://review.openstack.org/#/c/77471/3/neutron/agent/l3_agent.py

thanks,
Robert

On 8/27/14, 1:03 AM, Xuhan Peng pengxu...@gmail.com
mailto:pengxu...@gmail.com wrote:

As a follow-up action of yesterday's IPv6 sub-team
meeting, I would like to start a discussion about how to
support l3 agent HA when IP version is IPv6.

This problem is triggered by bug [1] where sending
gratuitous arp packet for HA doesn't work for IPv6 subnet
gateways. This is because neighbor discovery instead of
ARP should be used for IPv6.

My thought to solve this problem turns into how to send
out neighbor advertisement for IPv6 routers just like
sending ARP reply for IPv4 routers after reading the
comments on code review [2].

I searched for utilities which can do this and only find
a utility called ndsend [3] as part of vzctl on ubuntu. I
could not find similar tools on other linux distributions.

There are comments in yesterday's meeting that it's the
new router's job to send out RA and there is no need for
neighbor discovery. But we didn't get enough time to
finish the discussion.


Because OpenStack runs the l3 agent, it is the router.  Instead
of needing to do gratuitous ARP to alert all clients of the new
MAC, a simple RA from the new router for the same prefix would
accomplish the same, without having to resort to a special
package to generate unsolicited NA packets.  RAs must be
generated 

Re: [openstack-dev] [neutron][IPv6] Neighbor Discovery for HA

[Xu Han Peng]

Anthony and Robert,

Thanks for your reply. I don't know if the arping is there for NAT, but 
I am pretty sure it's for HA setup to broadcast the router's own change 
since the arping is controlled by send_arp_for_ha config. By checking 
the man page of arping, you can find the arping -A we use in code is 
sending out ARP REPLY instead of ARP REQUEST. This is like saying I am 
here instead of where are you. I didn't realized this either until 
Brain pointed this out at my code review below.


http://linux.die.net/man/8/arping

https://review.openstack.org/#/c/114437/2/neutron/agent/l3_agent.py

Thoughts?

Xu Han


On 08/27/2014 10:01 PM, Veiga, Anthony wrote:



Hi Xuhan,

What I saw is that GARP is sent to the gateway port and also to
the router ports, from a neutron router. I'm not sure why it's
sent to the router ports (internal network). My understanding for
arping to the gateway port is that it is needed for proper NAT
operation. Since we are not planning to support ipv6 NAT, so this
is not required/needed for ipv6 any more?


I agree that this is no longer necessary.


There is an abandoned patch that disabled the arping for ipv6
gateway port:
https://review.openstack.org/#/c/77471/3/neutron/agent/l3_agent.py

thanks,
Robert

On 8/27/14, 1:03 AM, Xuhan Peng pengxu...@gmail.com
mailto:pengxu...@gmail.com wrote:

As a follow-up action of yesterday's IPv6 sub-team meeting, I
would like to start a discussion about how to support l3 agent
HA when IP version is IPv6.

This problem is triggered by bug [1] where sending gratuitous
arp packet for HA doesn't work for IPv6 subnet gateways. This
is because neighbor discovery instead of ARP should be used
for IPv6.

My thought to solve this problem turns into how to send
out neighbor advertisement for IPv6 routers just like sending
ARP reply for IPv4 routers after reading the comments on code
review [2].

I searched for utilities which can do this and only find a
utility called ndsend [3] as part of vzctl on ubuntu. I could
not find similar tools on other linux distributions.

There are comments in yesterday's meeting that it's the new
router's job to send out RA and there is no need for neighbor
discovery. But we didn't get enough time to finish the
discussion.


Because OpenStack runs the l3 agent, it is the router.  Instead of 
needing to do gratuitous ARP to alert all clients of the new MAC, a 
simple RA from the new router for the same prefix would accomplish the 
same, without having to resort to a special package to generate 
unsolicited NA packets.  RAs must be generated from the l3 agent 
anyway if it's the gateway, and we're doing that via radvd now.  The 
HA failover simply needs to start the proper radvd process on the 
secondary gateway and resume normal operation.



Can you comment your thoughts about how to solve this problem
in this thread, please?

[1] https://bugs.launchpad.net/neutron/+bug/1357068

[2] https://review.openstack.org/#/c/114437/

[3] http://manpages.ubuntu.com/manpages/oneiric/man8/ndsend.8.html

Thanks,
Xu Han



-Anthony


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][IPv6] Neighbor Discovery for HA

[Veiga, Anthony]

Anthony and Robert,

Thanks for your reply. I don't know if the arping is there for NAT, but I am 
pretty sure it's for HA setup to broadcast the router's own change since the 
arping is controlled by send_arp_for_ha config. By checking the man page of 
arping, you can find the arping -A we use in code is sending out ARP REPLY 
instead of ARP REQUEST. This is like saying I am here instead of where are 
you. I didn't realized this either until Brain pointed this out at my code 
review below.

That’s what I was trying to say earlier.  Sending out the RA is the same 
effect.  RA says “I’m here, oh and I’m also a router” and should supersede the 
need for an unsolicited NA.  The only thing to consider here is that RAs are 
from LLAs.  If you’re doing IPv6 HA, you’ll need to have two gateway IPs for 
the RA of the standby to work.  So far as I know, I think there’s still a bug 
out on this since you can only have one gateway per subnet.



http://linux.die.net/man/8/arping

https://review.openstack.org/#/c/114437/2/neutron/agent/l3_agent.py

Thoughts?

Xu Han


On 08/27/2014 10:01 PM, Veiga, Anthony wrote:

Hi Xuhan,

What I saw is that GARP is sent to the gateway port and also to the router 
ports, from a neutron router. I’m not sure why it’s sent to the router ports 
(internal network). My understanding for arping to the gateway port is that it 
is needed for proper NAT operation. Since we are not planning to support ipv6 
NAT, so this is not required/needed for ipv6 any more?

I agree that this is no longer necessary.


There is an abandoned patch that disabled the arping for ipv6 gateway port:  
https://review.openstack.org/#/c/77471/3/neutron/agent/l3_agent.py

thanks,
Robert

On 8/27/14, 1:03 AM, Xuhan Peng 
pengxu...@gmail.commailto:pengxu...@gmail.com wrote:

As a follow-up action of yesterday's IPv6 sub-team meeting, I would like to 
start a discussion about how to support l3 agent HA when IP version is IPv6.

This problem is triggered by bug [1] where sending gratuitous arp packet for HA 
doesn't work for IPv6 subnet gateways. This is because neighbor discovery 
instead of ARP should be used for IPv6.

My thought to solve this problem turns into how to send out neighbor 
advertisement for IPv6 routers just like sending ARP reply for IPv4 routers 
after reading the comments on code review [2].

I searched for utilities which can do this and only find a utility called 
ndsend [3] as part of vzctl on ubuntu. I could not find similar tools on other 
linux distributions.

There are comments in yesterday's meeting that it's the new router's job to 
send out RA and there is no need for neighbor discovery. But we didn't get 
enough time to finish the discussion.

Because OpenStack runs the l3 agent, it is the router.  Instead of needing to 
do gratuitous ARP to alert all clients of the new MAC, a simple RA from the new 
router for the same prefix would accomplish the same, without having to resort 
to a special package to generate unsolicited NA packets.  RAs must be generated 
from the l3 agent anyway if it’s the gateway, and we’re doing that via radvd 
now.  The HA failover simply needs to start the proper radvd process on the 
secondary gateway and resume normal operation.


Can you comment your thoughts about how to solve this problem in this thread, 
please?

[1] https://bugs.launchpad.net/neutron/+bug/1357068

[2] https://review.openstack.org/#/c/114437/

[3] http://manpages.ubuntu.com/manpages/oneiric/man8/ndsend.8.html

Thanks,
Xu Han


-Anthony



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][IPv6] Neighbor Discovery for HA

[Robert Li (baoli)]

Hi Xuhan,

What I saw is that GARP is sent to the gateway port and also to the router 
ports, from a neutron router. I’m not sure why it’s sent to the router ports 
(internal network). My understanding for arping to the gateway port is that it 
is needed for proper NAT operation. Since we are not planning to support ipv6 
NAT, so this is not required/needed for ipv6 any more?

There is an abandoned patch that disabled the arping for ipv6 gateway port:  
https://review.openstack.org/#/c/77471/3/neutron/agent/l3_agent.py

thanks,
Robert

On 8/27/14, 1:03 AM, Xuhan Peng 
pengxu...@gmail.commailto:pengxu...@gmail.com wrote:

As a follow-up action of yesterday's IPv6 sub-team meeting, I would like to 
start a discussion about how to support l3 agent HA when IP version is IPv6.

This problem is triggered by bug [1] where sending gratuitous arp packet for HA 
doesn't work for IPv6 subnet gateways. This is because neighbor discovery 
instead of ARP should be used for IPv6.

My thought to solve this problem turns into how to send out neighbor 
advertisement for IPv6 routers just like sending ARP reply for IPv4 routers 
after reading the comments on code review [2].

I searched for utilities which can do this and only find a utility called 
ndsend [3] as part of vzctl on ubuntu. I could not find similar tools on other 
linux distributions.

There are comments in yesterday's meeting that it's the new router's job to 
send out RA and there is no need for neighbor discovery. But we didn't get 
enough time to finish the discussion.

Can you comment your thoughts about how to solve this problem in this thread, 
please?

[1] https://bugs.launchpad.net/neutron/+bug/1357068

[2] https://review.openstack.org/#/c/114437/

[3] http://manpages.ubuntu.com/manpages/oneiric/man8/ndsend.8.html

Thanks,
Xu Han
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][IPv6] Neighbor Discovery for HA

[Veiga, Anthony]

Hi Xuhan,

What I saw is that GARP is sent to the gateway port and also to the router 
ports, from a neutron router. I’m not sure why it’s sent to the router ports 
(internal network). My understanding for arping to the gateway port is that it 
is needed for proper NAT operation. Since we are not planning to support ipv6 
NAT, so this is not required/needed for ipv6 any more?

I agree that this is no longer necessary.


There is an abandoned patch that disabled the arping for ipv6 gateway port:  
https://review.openstack.org/#/c/77471/3/neutron/agent/l3_agent.py

thanks,
Robert

On 8/27/14, 1:03 AM, Xuhan Peng 
pengxu...@gmail.commailto:pengxu...@gmail.com wrote:

As a follow-up action of yesterday's IPv6 sub-team meeting, I would like to 
start a discussion about how to support l3 agent HA when IP version is IPv6.

This problem is triggered by bug [1] where sending gratuitous arp packet for HA 
doesn't work for IPv6 subnet gateways. This is because neighbor discovery 
instead of ARP should be used for IPv6.

My thought to solve this problem turns into how to send out neighbor 
advertisement for IPv6 routers just like sending ARP reply for IPv4 routers 
after reading the comments on code review [2].

I searched for utilities which can do this and only find a utility called 
ndsend [3] as part of vzctl on ubuntu. I could not find similar tools on other 
linux distributions.

There are comments in yesterday's meeting that it's the new router's job to 
send out RA and there is no need for neighbor discovery. But we didn't get 
enough time to finish the discussion.

Because OpenStack runs the l3 agent, it is the router.  Instead of needing to 
do gratuitous ARP to alert all clients of the new MAC, a simple RA from the new 
router for the same prefix would accomplish the same, without having to resort 
to a special package to generate unsolicited NA packets.  RAs must be generated 
from the l3 agent anyway if it’s the gateway, and we’re doing that via radvd 
now.  The HA failover simply needs to start the proper radvd process on the 
secondary gateway and resume normal operation.


Can you comment your thoughts about how to solve this problem in this thread, 
please?

[1] https://bugs.launchpad.net/neutron/+bug/1357068

[2] https://review.openstack.org/#/c/114437/

[3] http://manpages.ubuntu.com/manpages/oneiric/man8/ndsend.8.html

Thanks,
Xu Han


-Anthony
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron][IPv6] Neighbor Discovery for HA

[Xuhan Peng]

As a follow-up action of yesterday's IPv6 sub-team meeting, I would like to
start a discussion about how to support l3 agent HA when IP version is
IPv6.

This problem is triggered by bug [1] where sending gratuitous arp packet
for HA doesn't work for IPv6 subnet gateways. This is because neighbor
discovery instead of ARP should be used for IPv6.

My thought to solve this problem turns into how to send out neighbor
advertisement for IPv6 routers just like sending ARP reply for IPv4 routers
after reading the comments on code review [2].

I searched for utilities which can do this and only find a utility called
ndsend [3] as part of vzctl on ubuntu. I could not find similar tools on
other linux distributions.

There are comments in yesterday's meeting that it's the new router's job to
send out RA and there is no need for neighbor discovery. But we didn't get
enough time to finish the discussion.

Can you comment your thoughts about how to solve this problem in this
thread, please?

[1] https://bugs.launchpad.net/neutron/+bug/1357068

[2] https://review.openstack.org/#/c/114437/

[3] http://manpages.ubuntu.com/manpages/oneiric/man8/ndsend.8.html

Thanks,
Xu Han
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][IPv6] Allowing Plugins in tree that explicitly do not support IPv6

[Kyle Mestery]

On Sun, Aug 24, 2014 at 2:18 PM, Collins, Sean
sean_colli...@cable.comcast.com wrote:
 Hi,

 The amount of tests that we are having to add skips to for the One
 Convergence plugin has grown quite a bit lately.

 http://git.openstack.org/cgit/openstack/neutron/tree/neutron/tests/unit/oneconvergence/test_nvsd_plugin.py#n58

 This is the only plugin that inherits from the NeutronDbPluginV2 class and
 has completely disabled creating Subnets that have an ip_version of 6.

 http://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/oneconvergence/plugin.py#n228

 I hate to single out this plugin. Before this development cycle, open source
 plugins would allow the creation of Subnets with ip_version set to 6, and
 then have lots of bugs which would prevent any instances from actually
 obtaining IPv6 addresses and routing. But we didn't have to explicitly skip
 tests every time someone wanted to fix bugs - like the following patch.

 https://review.openstack.org/#/c/116317/

 Also, I want to highlight some meeting minutes, where it was discussed that
 in the K release, all plugins will be required to support IPv6. I hope we
 can discuss this, build consensus, and ensure that the K release requirement
 is reasonable.

 http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-07-14-21.02.html

Sean, this is a very valid point. Can you please add an item on the
neutron meeting agenda today so we can discuss this? I'd like to talk
this through with the team to understand how we as a community want to
move forward here. Since we will have closed the IPV6 gap in Juno once
the stateful/stateless patches merge, we should be requiring all
plugins to support IPV6 and not skip these tests.

Thanks,
Kyle

 Sean M. Collins

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][IPv6] Allowing Plugins in tree that explicitly do not support IPv6

[Subrahmanyam Ongole]

Hi Sean

I will join the Neutron IRC, get the inputs and address them at the
earliest.

I like to know the requirements for J  K release cycles and what other
open source reference plugins have done towards this. We need to ramp up
our resources on ipv6 support.


On Sun, Aug 24, 2014 at 12:18 PM, Collins, Sean 
sean_colli...@cable.comcast.com wrote:

  Hi,

 The amount of tests that we are having to add skips to for the One
 Convergence plugin has grown quite a bit lately.


 http://git.openstack.org/cgit/openstack/neutron/tree/neutron/tests/unit/oneconvergence/test_nvsd_plugin.py#n58

 This is the only plugin that inherits from the NeutronDbPluginV2 class and
 has completely disabled creating Subnets that have an ip_version of 6.


 http://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/oneconvergence/plugin.py#n228

 I hate to single out this plugin. Before this development cycle, open
 source plugins would allow the creation of Subnets with ip_version set to
 6, and then have lots of bugs which would prevent any instances from
 actually obtaining IPv6 addresses and routing. But we didn't have to
 explicitly skip tests every time someone wanted to fix bugs - like the
 following patch.

 https://review.openstack.org/#/c/116317/

 Also, I want to highlight some meeting minutes, where it was discussed
 that in the K release, all plugins will be required to support IPv6. I hope
 we can discuss this, build consensus, and ensure that the K release
 requirement is reasonable.


 http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-07-14-21.02.html

  Sean M. Collins

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 

Thanks
OSM
(Subrahmanyam Ongole)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][IPv6] Allowing Plugins in tree that explicitly do not support IPv6

[Kevin Benton]

Hi Sean,

Until the IPv6 support requirement is determined, this patch prevent
reviewers from having to add the skip test as long as they mention 'v6' in
the name. [1]


1. https://review.openstack.org/116712


On Sun, Aug 24, 2014 at 12:18 PM, Collins, Sean 
sean_colli...@cable.comcast.com wrote:

  Hi,

 The amount of tests that we are having to add skips to for the One
 Convergence plugin has grown quite a bit lately.


 http://git.openstack.org/cgit/openstack/neutron/tree/neutron/tests/unit/oneconvergence/test_nvsd_plugin.py#n58

 This is the only plugin that inherits from the NeutronDbPluginV2 class and
 has completely disabled creating Subnets that have an ip_version of 6.


 http://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/oneconvergence/plugin.py#n228

 I hate to single out this plugin. Before this development cycle, open
 source plugins would allow the creation of Subnets with ip_version set to
 6, and then have lots of bugs which would prevent any instances from
 actually obtaining IPv6 addresses and routing. But we didn't have to
 explicitly skip tests every time someone wanted to fix bugs - like the
 following patch.

 https://review.openstack.org/#/c/116317/

 Also, I want to highlight some meeting minutes, where it was discussed
 that in the K release, all plugins will be required to support IPv6. I hope
 we can discuss this, build consensus, and ensure that the K release
 requirement is reasonable.


 http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-07-14-21.02.html

  Sean M. Collins

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][IPv6] Allowing Plugins in tree that explicitly do not support IPv6

[Collins, Sean]

Hi,

The amount of tests that we are having to add skips to for the One Convergence 
plugin has grown quite a bit lately.

http://git.openstack.org/cgit/openstack/neutron/tree/neutron/tests/unit/oneconvergence/test_nvsd_plugin.py#n58

This is the only plugin that inherits from the NeutronDbPluginV2 class and has 
completely disabled creating Subnets that have an ip_version of 6.

http://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/oneconvergence/plugin.py#n228

I hate to single out this plugin. Before this development cycle, open source 
plugins would allow the creation of Subnets with ip_version set to 6, and then 
have lots of bugs which would prevent any instances from actually obtaining 
IPv6 addresses and routing. But we didn't have to explicitly skip tests every 
time someone wanted to fix bugs - like the following patch.

https://review.openstack.org/#/c/116317/

Also, I want to highlight some meeting minutes, where it was discussed that in 
the K release, all plugins will be required to support IPv6. I hope we can 
discuss this, build consensus, and ensure that the K release requirement is 
reasonable.

http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-07-14-21.02.html

Sean M. Collins
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][IPv6]

[Randy Tuttle]

Hi Harm

It’s highly unlikely that it would work with a current version of Neutron 
(Icehouse was where the original effort went). I’ve just run out of cycles to 
work on this. I know Sean Collins continues to drive this effort, and the 
roadmap may have this BP (or a similar one) targeted for Kilo. Check with Sean.

Randy

On Aug 15, 2014, at 3:25 PM, Harm Weites h...@weites.com wrote:

 Hi Randy,
 
 I was reading throught your blueprint [1] and figured it was exactly
 what I'm after to get dualstack v4/v6 in my cloud. Sadly, the review has
 it's current state set to abandoned.
 
 Are there any plans to get back to it and get it into trunk?
 
 Furthermore, does it still apply (and work) on a recent checkout of
 Neutron, or should I just go ahead and give it a go?
 
 [1]
 https://blueprints.launchpad.net/neutron/+spec/allow-multiple-subnets-on-gateway-port
 [2] https://review.openstack.org/#/c/77471/
 
 Thanks,
 Harm


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] [IPv6] Hide ipv6 subnet API attributes

[Nir Yechiel]

Now with the Juno efforts to provide IPv6 support and some features (provider 
networks SLAAC, RADVD) already merged, is there any plan/patch to revert this 
Icehouse change [1] and make the 'ra_mode' and 'ipv6_address_mode' consumable?

Thanks,
Nir

[1] https://review.openstack.org/#/c/85869/

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] [IPv6] Hide ipv6 subnet API attributes

[Henry Gessau]

Nir Yechiel nyech...@redhat.com wrote:
 Now with the Juno efforts to provide IPv6 support and some features
 (provider networks SLAAC, RADVD) already merged, is there any plan/patch to
 revert this Icehouse change [1] and make the 'ra_mode' and
 'ipv6_address_mode' consumable?
 
 Thanks,
 Nir
 
 [1] https://review.openstack.org/#/c/85869/

It's already done.

https://review.openstack.org/86169



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] [IPv6] Hide ipv6 subnet API attributes

[Collins, Sean]

On Tue, Jul 29, 2014 at 04:40:33AM EDT, Nir Yechiel wrote:
 Now with the Juno efforts to provide IPv6 support and some features (provider 
 networks SLAAC, RADVD) already merged, is there any plan/patch to revert this 
 Icehouse change [1] and make the 'ra_mode' and 'ipv6_address_mode' consumable?
 

There are currently no plans, since all of the changes that implement
IPv6 functionality have been landing in Juno. I suggest upgrading to
Juno when it is released.

-- 
Sean M. Collins
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][IPv6] Volunteer to run tomorrow's IRC meeting?

[Kevin Benton]

I can lead it, but I'm not sure if there is anything new to discuss since
the QoS spec is still under review.
Did you have any specific agenda items that you wanted to cover?


On Mon, Jul 7, 2014 at 1:43 PM, Collins, Sean 
sean_colli...@cable.comcast.com wrote:

 Hi,

 I am currently at a book sprint and will probably not be able to run the
 meeting, if someone could volunteer to chair the meeting and run it,
 that would be great.

 Any takers?
 --
 Sean M. Collins
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][IPv6] Volunteer to run tomorrow's IRC meeting?

[Collins, Sean]

On Mon, Jul 07, 2014 at 11:01:52PM PDT, Kevin Benton wrote:
 I can lead it, but I'm not sure if there is anything new to discuss since
 the QoS spec is still under review.
 Did you have any specific agenda items that you wanted to cover?

Ah. The QoS IRC meeting will also need to be chaired in my absence,
although lately there has not been a lot of participation. This is
partly my fault since I didn't start the meeting on time last week, but
I wonder if we should continue the IRC meeting?

-- 
Sean M. Collins
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][IPv6] Volunteer to run tomorrow's IRC meeting?

[Kevin Benton]

I think at this point the discussion is mostly contained in the review for
the spec[1] so I don't see a particular need to continue the IRC meeting.


1. https://review.openstack.org/#/c/88599/


On Mon, Jul 7, 2014 at 11:12 PM, Collins, Sean 
sean_colli...@cable.comcast.com wrote:

 On Mon, Jul 07, 2014 at 11:01:52PM PDT, Kevin Benton wrote:
  I can lead it, but I'm not sure if there is anything new to discuss since
  the QoS spec is still under review.
  Did you have any specific agenda items that you wanted to cover?

 Ah. The QoS IRC meeting will also need to be chaired in my absence,
 although lately there has not been a lot of participation. This is
 partly my fault since I didn't start the meeting on time last week, but
 I wonder if we should continue the IRC meeting?

 --
 Sean M. Collins
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][IPv6] Volunteer to run tomorrow's IRC meeting?

[Collins, Sean]

Hi,

I am currently at a book sprint and will probably not be able to run the
meeting, if someone could volunteer to chair the meeting and run it,
that would be great. 

Any takers?
-- 
Sean M. Collins
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][IPv6] Neutron IPv6 in Icehouse and further

[Robert Li (baoli)]

Hi,

There is a patch for radvd https://review.openstack.org/#/c/102648/2 that you 
can use in addition to the devstack patch. You want to make sure that ipv6 is 
enabled and ra accepted with your VM’s image. Both patches are under 
development.

To use dhcpv6,  the current dhcp agent should be working. However, it might be 
broken due to a recent commit. If you found a Traceback in your dhcp agent log 
complaining about an uninitialized reference to the variable ‘mode', you may 
hit that issue. You can just initialize it to be ‘static’. In addition, only 
recently, dhcp messages maybe dropped before entering the VM. Therefore, you 
might need to disable the ipv6 rules manually by “ip6tables –F” after a VM is 
launched .  Also make sure you are using the latest dnsmasq (2.6.8)

Thanks,
Robert

On 6/27/14, 3:47 AM, Jaume Devesa 
devv...@gmail.commailto:devv...@gmail.com wrote:

Hello Maksym,

last week I had more or less the same questions than you and I investigate a 
little bit... Currently we have the ipv6_ra_mode and ipv6_address_mode in the 
subnet entity. The way you combine these two values will determine how and who 
will configure your VM´s IPv6 addresses. Not all the combinations are possible. 
This document[1] and the upstream-slaac-support spec[2] provide the possible 
combinations. Not sure which one is more updated...

If you want to try IPv6 current support, you can use the Baodong Li's devstack 
patch [3], although is still in development. Follow the message commit 
instructions to provide a radvd daemon. That means that there is no RA 
advertiser in Neutron currently. There is a spec in review[4] to fill this gap.

The changes for allow DHCPv6 in dnsmasq are in review in this patch[5].

This is what I found... I hope some IPv6 folks can correct me if this 
information is not accurate enough (or wrong)


[1]: https://www.dropbox.com/s/9bojvv9vywsz8sd/IPv6%20Two%20Modes%20v3.0.pdf
[2]: 
http://docs-draft.openstack.org/43/88043/9/gate/gate-neutron-specs-docs/82c251a/doc/build/html/specs/juno/ipv6-provider-nets-slaac.html
[3]: https://review.openstack.org/#/c/87987
[4]: https://review.openstack.org/#/c/101306/
[5]: https://review.openstack.org/#/c/70649/



On 27 June 2014 00:51, Martinx - ジェームズ 
thiagocmarti...@gmail.commailto:thiagocmarti...@gmail.com wrote:
Hi! I'm waiting for that too...

Currently, I'm running IceHouse with static IPv6 address, with the topology 
VLAN Provider Networks and, to make it easier, I'm counting on the following 
blueprint:

https://blueprints.launchpad.net/neutron/+spec/ipv6-provider-nets-slaac

...but, I'm not sure if it will be enough to enable basic IPv6 support (without 
using Neutron as Instance's default gateway)...

Cheers!
Thiago


On 26 June 2014 19:35, Maksym Lobur 
mlo...@mirantis.commailto:mlo...@mirantis.com wrote:
Hi Folks,

Could you please tell what is the current state of IPv6 in Neutron? Does it 
have DHCPv6 working?

What is the best point to start hacking from? Devstack stable/icehouse or maybe 
some tag? Are there any docs / raw deployment guides?
I see some patches not landed yet [1] ... I assume it won't work without them, 
right?

Somehow I can't open any of the code reviews from the [2] (Not Found)

[1] 
https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:%255E.*%255Cipv6.*,n,z
[2] https://wiki.openstack.org/wiki/Neutron/IPv6

Best regards,
Max Lobur,
Python Developer, Mirantis, Inc.

Mobile: +38 (093) 665 14 28tel:%2B38%20%28093%29%20665%2014%2028
Skype: max_lobur

38, Lenina ave. Kharkov, Ukraine
www.mirantis.comhttp://www.mirantis.com
www.mirantis.ruhttp://www.mirantis.ru

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--
Jaume Devesa
Software Engineer at Midokura
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][IPv6] Neutron IPv6 in Icehouse and further

[Jaume Devesa]

Hello Maksym,

last week I had more or less the same questions than you and I investigate
a little bit... Currently we have the *ipv6_ra_mode *and *ipv6_address_mode
*in the subnet entity. The way you combine these two values will determine
how and who will configure your VM´s IPv6 addresses. Not all the
combinations are possible. This document[1] and the *upstream-slaac-support*
 *spec*[2] provide the possible combinations. Not sure which one is more
updated...

If you want to try IPv6 current support, you can use the Baodong Li's
devstack patch [3], although is still in development. Follow the message
commit instructions to provide a radvd daemon. That means that there is no
RA advertiser in Neutron currently. There is a *spec* in review[4] to fill
this gap.

The changes for allow DHCPv6 in dnsmasq are in review in this patch[5].

This is what I found... I hope some IPv6 folks can correct me if this
information is not accurate enough (or wrong)


[1]: https://www.dropbox.com/s/9bojvv9vywsz8sd/IPv6%20Two%20Modes%20v3.0.pdf
[2]:
http://docs-draft.openstack.org/43/88043/9/gate/gate-neutron-specs-docs/82c251a/doc/build/html/specs/juno/ipv6-provider-nets-slaac.html
[3]: https://review.openstack.org/#/c/87987
[4]: https://review.openstack.org/#/c/101306/
[5]: https://review.openstack.org/#/c/70649/



On 27 June 2014 00:51, Martinx - ジェームズ thiagocmarti...@gmail.com wrote:

 Hi! I'm waiting for that too...

 Currently, I'm running IceHouse with static IPv6 address, with the
 topology VLAN Provider Networks and, to make it easier, I'm counting on
 the following blueprint:

 https://blueprints.launchpad.net/neutron/+spec/ipv6-provider-nets-slaac

 ...but, I'm not sure if it will be enough to enable basic IPv6 support
 (without using Neutron as Instance's default gateway)...

 Cheers!
 Thiago


 On 26 June 2014 19:35, Maksym Lobur mlo...@mirantis.com wrote:

 Hi Folks,

 Could you please tell what is the current state of IPv6 in Neutron? Does
 it have DHCPv6 working?

 What is the best point to start hacking from? Devstack stable/icehouse or
 maybe some tag? Are there any docs / raw deployment guides?
 I see some patches not landed yet [1] ... I assume it won't work without
 them, right?

 Somehow I can't open any of the code reviews from the [2] (Not Found)

 [1]
 https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:%255E.*%255Cipv6.*,n,z
 [2] https://wiki.openstack.org/wiki/Neutron/IPv6

  Best regards,
 Max Lobur,
 Python Developer, Mirantis, Inc.

 Mobile: +38 (093) 665 14 28
 Skype: max_lobur

 38, Lenina ave. Kharkov, Ukraine
 www.mirantis.com
 www.mirantis.ru

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Jaume Devesa
Software Engineer at Midokura
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][IPv6] Neutron IPv6 in Icehouse and further

[Maksym Lobur]

Hi Folks,

Could you please tell what is the current state of IPv6 in Neutron? Does it
have DHCPv6 working?

What is the best point to start hacking from? Devstack stable/icehouse or
maybe some tag? Are there any docs / raw deployment guides?
I see some patches not landed yet [1] ... I assume it won't work without
them, right?

Somehow I can't open any of the code reviews from the [2] (Not Found)

[1]
https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:%255E.*%255Cipv6.*,n,z
[2] https://wiki.openstack.org/wiki/Neutron/IPv6

Best regards,
Max Lobur,
Python Developer, Mirantis, Inc.

Mobile: +38 (093) 665 14 28
Skype: max_lobur

38, Lenina ave. Kharkov, Ukraine
www.mirantis.com
www.mirantis.ru
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][IPv6] Neutron IPv6 in Icehouse and further

[Martinx - ジェームズ]

Hi! I'm waiting for that too...

Currently, I'm running IceHouse with static IPv6 address, with the topology
VLAN Provider Networks and, to make it easier, I'm counting on the
following blueprint:

https://blueprints.launchpad.net/neutron/+spec/ipv6-provider-nets-slaac

...but, I'm not sure if it will be enough to enable basic IPv6 support
(without using Neutron as Instance's default gateway)...

Cheers!
Thiago


On 26 June 2014 19:35, Maksym Lobur mlo...@mirantis.com wrote:

 Hi Folks,

 Could you please tell what is the current state of IPv6 in Neutron? Does
 it have DHCPv6 working?

 What is the best point to start hacking from? Devstack stable/icehouse or
 maybe some tag? Are there any docs / raw deployment guides?
 I see some patches not landed yet [1] ... I assume it won't work without
 them, right?

 Somehow I can't open any of the code reviews from the [2] (Not Found)

 [1]
 https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:%255E.*%255Cipv6.*,n,z
 [2] https://wiki.openstack.org/wiki/Neutron/IPv6

  Best regards,
 Max Lobur,
 Python Developer, Mirantis, Inc.

 Mobile: +38 (093) 665 14 28
 Skype: max_lobur

 38, Lenina ave. Kharkov, Ukraine
 www.mirantis.com
 www.mirantis.ru

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][ipv6] Do you have problem accessing IRC

[Collins, Sean]

On Tue, Jun 17, 2014 at 10:10:26AM EDT, Shixiong Shang wrote:
 Trying to join the weekly meeting, but my IRC client kept complaining…Is it 
 just me?
 
If you have problems, you can always use the web client:

http://webchat.freenode.net/

-- 
Sean M. Collins
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][ipv6] Support ipv6 RA in neutron

[Ian Wells]

I'm only part way through reviewing this, but I think there's a fundamental
error in it.  We were at one point going to use 'enable_dhcp' in the
current set of flags to indicate something meaningful, but eventually we
decided that its current behaviour (despite the naming) really meant 'no
address assignment protocols are active' - which is why setting
enable_dhcp=False completely disables DHCP and RA activity in Neutron.  (I
believe Mark pointed that out, and agitated for backward compatibility,
though I couldn't tell you which forum it was in.)  Your proposal reverses
that decision, and says that it can be set to false and yet RAs will still
be sent out.

It's also why there are two additional attributes, because a single option
isn't really expressive enough once you consider the provider network
cases.  You are, in your own way, also using two attributes, by repurposing
enable_dhcp - your attribute values are different, but you're doing it for
similar reasons.

I'll put up my other review comments a bit later on when I've had another
think.
-- 
Ian.



On 11 June 2014 06:07, Robert Li (baoli) ba...@cisco.com wrote:

  Hi,

  I was mistakenly reusing the Blueprint
 https://blueprints.launchpad.net/neutron/+spec/neutron-ipv6-radvd-ra to
 draft up the ipv6 RA support in neutron. I apologize for any confusion that
 this may have caused. To correct it, I created a new blueprint
 https://blueprints.launchpad.net/neutron/+spec/neutron-ipv6-ra and linked
 it to a neutron spec https://review.openstack.org/92164.

  The basic idea behind this blueprint is that neutron dhcp service as it
 is can hand out IPv6 addresses either in IPv6 only data network or in a
 dual stack data network. But the RA service including SLAAC support is
 missing in neutron. This service is important. Without RA, VMs won’t be
 able to automatically install default routes. Without SLAAC, a deployment
 that prefers SLAAC won’t be able to do it with neutron. The BP takes a
 straightforward approach to achieve that without requiring significant
 change to the existing dhcp service.

  Any feedback is appreciated.

  thanks,
 Robert

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron][ipv6] ipv6 dual stack

[Robert Li (baoli)]

Hi,

I added ipv6 support in devstack https://review.openstack.org/#/c/87987/. This 
is a WIP patch given that neutron ipv6 is not fully implemented yet. With this 
script, dual stack data network can be created with neutron as well. The only 
thing that needs to be done manually is starting the RA service. If you want to 
start a dual stack, just set IP_VERSION=4+6 in your localrc. The script uses 
existing neutron commands, and invokes linux IP utilities to properly set up 
the router namespace. With the right version of dnsmasq (I’m using 2.68) in 
use, it will be successfully launched and handing out both ipv6 and ipv4 
addresses. An example of dnsmasq instance is shown as below:


dnsmasq --no-hosts --no-resolv --strict-order --bind-interfaces 
--interface=tap4f9e30eb-f6 --except-interface=lo 
--pid-file=/opt/stack/data/neutron/dhcp/c5eb1f36-0c70-4658-8201-8407752212b1/pid
 
--dhcp-hostsfile=/opt/stack/data/neutron/dhcp/c5eb1f36-0c70-4658-8201-8407752212b1/host
 
--addn-hosts=/opt/stack/data/neutron/dhcp/c5eb1f36-0c70-4658-8201-8407752212b1/addn_hosts
 
--dhcp-optsfile=/opt/stack/data/neutron/dhcp/c5eb1f36-0c70-4658-8201-8407752212b1/opts
 --leasefile-ro --dhcp-range=set:tag0,10.0.0.0,static,86400s 
--dhcp-range=set:tag1,2001:420:2c50:200b::,static,86400s 
--dhcp-lease-max=16777216 --conf-file= --domain=openstacklocal

This is achieved without making any changes in the neutron dhcp service.

Make sure that your VM image has dhcp v6 client enabled on the port. This can 
be easily achieved with an ubuntu image, for example,  add ‘iface eth0 inet6 
dhcp” in the /etc/network/interfaces file.

You can check the commit message in https://review.openstack.org/#/c/87987/ for 
more details.

Note that there seems to be a bug in the neutron ip6tables that prevents dhcp 
v6 packets coming in to the VM. The bug seems to be introduced recently. If you 
see ipv4 but not ipv6 addresses in your VM, you can flush the ip6tables, and 
change the status of your port in the VM.

thanks,
Robert
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][ipv6] Support ipv6 RA in neutron

[Collins, Sean]

On Wed, Jun 11, 2014 at 09:07:59AM EDT, Robert Li (baoli) wrote:
 Hi,
 
 I was mistakenly reusing the Blueprint 
 https://blueprints.launchpad.net/neutron/+spec/neutron-ipv6-radvd-ra to draft 
 up the ipv6 RA support in neutron. I apologize for any confusion that this 
 may have caused. To correct it, I created a new blueprint 
 https://blueprints.launchpad.net/neutron/+spec/neutron-ipv6-ra and linked it 
 to a neutron spec https://review.openstack.org/92164.
 
 The basic idea behind this blueprint is that neutron dhcp service as it is 
 can hand out IPv6 addresses either in IPv6 only data network or in a dual 
 stack data network. But the RA service including SLAAC support is missing in 
 neutron. This service is important. Without RA, VMs won’t be able to 
 automatically install default routes. Without SLAAC, a deployment that 
 prefers SLAAC won’t be able to do it with neutron. The BP takes a 
 straightforward approach to achieve that without requiring significant change 
 to the existing dhcp service.
 
 Any feedback is appreciated.


To be clear, you are still proposing that we remove the IPv6 subnet
attributes that have been merged, and replaced with a single attribute,
yes?

Would you be willing to set aside the single attribute API proposal, and
instead work on fixing dnsmasq and adding support for rtadvd, and
supporting the two attribute blueprint that the community developed and
merged?

-- 
Sean M. Collins
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][ipv6] ipv6 dual stack

[Collins, Sean]

On Wed, Jun 11, 2014 at 09:58:14AM EDT, Robert Li (baoli) wrote:
 Hi,
 
 With the right version of
 dnsmasq (I’m using 2.68) in use, it will be successfully launched and
 handing out both ipv6 and ipv4 addresses. An example of dnsmasq
 instance is shown as below:

We should consider bumping the minimum dnsmasq version that we support.
Older versions will crash when adding a second tag to the command line
arguments for launching dnsmasq. I run Ubuntu 12.04 in my lab, with
devstack, and the version of dnsmasq that gets installed exhibits this
behavior.

https://bugs.launchpad.net/neutron/+bug/129


-- 
Sean M. Collins
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][ipv6] ipv6 dual stack

[Edgar Magana Perdomo (eperdomo)]

I do agree, bumping the dnsmasq version should not be a big deal and it
seems Aaron is already working on that.

Edgar

On 6/11/14, 8:24 AM, Collins, Sean sean_colli...@cable.comcast.com
wrote:

On Wed, Jun 11, 2014 at 09:58:14AM EDT, Robert Li (baoli) wrote:
 Hi,
 
 With the right version of
 dnsmasq (I¹m using 2.68) in use, it will be successfully launched and
 handing out both ipv6 and ipv4 addresses. An example of dnsmasq
 instance is shown as below:

We should consider bumping the minimum dnsmasq version that we support.
Older versions will crash when adding a second tag to the command line
arguments for launching dnsmasq. I run Ubuntu 12.04 in my lab, with
devstack, and the version of dnsmasq that gets installed exhibits this
behavior.

https://bugs.launchpad.net/neutron/+bug/129


-- 
Sean M. Collins
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][IPv6] Issues on dnsmasq

[Shixiong Shang]

Hi, Xu Han:

You mentioned in the weekly meeting that you guys saw some issues in the lab, 
which may pertain to the dnsmasq source code I wrote. Would you please share 
with me the symptom and the procedures to reproduce them? I would like to take 
a look and fix the issue if necessary.

Thanks!

Shixiong


Shixiong Shang

!--- Stay Hungry, Stay Foolish ---!

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][IPv6] Issues on dnsmasq

[Xu Han Peng]

Shi Xiong,

Thanks for asking! The error was found in dnsmasq log during our test. 
The error looks something like:  no addresses available.


Jian Li from my team posted a comment about the PID error on your code 
review:


https://review.openstack.org/#/c/70649/15/neutron/agent/linux/dhcp.py

You can search his name jian li on that page to find the comment.

BTW, I volunteered myself on this Tuesday's meeting to help on the 
dnsmasq code, so we can get the comments addressed and make IPv6 
functional ASAP. Please let me know what I can help with that.


Xu Han

On 06/05/2014 04:28 AM, Shixiong Shang wrote:

Hi, Xu Han:

You mentioned in the weekly meeting that you guys saw some issues in 
the lab, which may pertain to the dnsmasq source code I wrote. Would 
you please share with me the symptom and the procedures to reproduce 
them? I would like to take a look and fix the issue if necessary.


Thanks!

Shixiong
*

*
*Shixiong Shang*
*
*
*!--- Stay Hungry, Stay Foolish ---!*



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][IPv6] Minutes from May 27 2014

[Xu Han Peng]

Shixiong,

Sean and I were thinking about throwing out an error when someone is 
trying to attach a router to subnet when gateway is already set (for 
IPv6, it could be LLA). In the long term, we need to figure out how to 
use the link local address IP of the gateway port to overwrite the 
gateway IP set before attaching.


Xuhan

On 05/28/2014 08:53 AM, Shixiong Shang wrote:

I am reading the meeting minute, and saw the discussion on this BP submitted by 
xuhanp:

https://review.openstack.org/#/c/76125/

I don’t see any reason why we need it….do you?

Shixiong



On May 27, 2014, at 12:47 PM, Collins, Sean sean_colli...@cable.comcast.com 
wrote:


http://eavesdrop.openstack.org/meetings/neutron_ipv6/2014/neutron_ipv6.2014-05-27-14.01.html

--
Sean M. Collins
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][IPv6] Neutron Routers and LLAs

[Collins, Sean]

I'm going to bump this thread based on some of the discussions we had
today during the IRC meeting.

I also added a comment to a review on the tempest side after our
discussion (I made some adjustments to my comment for context and
clarification)

https://review.openstack.org/#/c/93400/

 The only time that the gateway will be specified
 in advance for a V6 subnet is if you are using an external device or
 something not orchestrated by OpenStack.

 We discussed this today, in the meeting, at 14:24:09

 http://eavesdrop.openstack.org/meetings/neutron_ipv6/2014/neutron_ipv6.2014-05-27-14.01.log.html

 Basically, if you are going to create a router in Neutron for a v6
 subnet, we plan on having the router attachment step populate the
 gateway attribute of the subnet, since we will be wiring it up and
 will have a LLA for the router.

For now, we are not addressing the problem of multiple routers attached to
different subnets - since we need to do some research on that.

-- 
Sean M. Collins
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][IPv6] Minutes from May 27 2014

[Collins, Sean]

http://eavesdrop.openstack.org/meetings/neutron_ipv6/2014/neutron_ipv6.2014-05-27-14.01.html

-- 
Sean M. Collins
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][IPv6] Minutes from May 27 2014

[Shixiong Shang]

I am reading the meeting minute, and saw the discussion on this BP submitted by 
xuhanp:

https://review.openstack.org/#/c/76125/

I don’t see any reason why we need it….do you?

Shixiong



On May 27, 2014, at 12:47 PM, Collins, Sean sean_colli...@cable.comcast.com 
wrote:

 http://eavesdrop.openstack.org/meetings/neutron_ipv6/2014/neutron_ipv6.2014-05-27-14.01.html
 
 -- 
 Sean M. Collins
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][IPv6] Meeting minutes for 5/20/2014

[Collins, Sean]

http://eavesdrop.openstack.org/meetings/neutron_ipv6/2014/neutron_ipv6.2014-05-20-14.00.html

-- 
Sean M. Collins
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][IPv6] Privacy extension

[Shixiong Shang]

Awesome! Seems like we reached agreement for not covering privacy extension at 
this moment. I am totally fine with that. To put closure on this subject, do 
you think we need to document it and provide user with work-around in case 
somebody asks for it in Juno release?

Shixiong




On May 16, 2014, at 3:29 PM, Robert Li (baoli) ba...@cisco.com wrote:

 Dane put some notes on the session??s ether pad  to support multiple 
 prefixes. Seem like this is really something that everyone want to support in 
 openstack.
 
 ??Robert
 
 On 5/16/14, 2:23 PM, Martinx - ?` thiagocmarti...@gmail.com wrote:
 
 Precisely Anthony! We talked about this topic (Non-NAT Floating IPv6) 
 here, on the following thread:
 
 --
 [openstack-dev] [Neutron][IPv6] Idea: Floating IPv6 - Without any kind of 
 NAT:
 http://lists.openstack.org/pipermail/openstack-dev/2014-February/026871.html
 --
 
 :-D
 
 About IPv6 Privacy Extensions, well, if it is too hard to implement, I think 
 that it can be postponed... And only the IPv6 self-generated by SLAAC and 
 previously calculated by Neutron itself (based on Instance's MAC address), 
 should be allowed to pass/work for now...
 
 -
  Thiago
 
 
 On 16 May 2014 12:12, Veiga, Anthony anthony_ve...@cable.comcast.com wrote:
 I??ll take this one a step further.  I think one of the methods for getting 
 (non-NAT) floating IPs in IPv6 would be to push a new, extra address to the 
 same port.  Either by crafting an extra, unicast RA to the specific VM or 
 providing multiple IA_NA fields in the DHCPv6 transaction.  This would 
 require multiple addresses to be allowed on a single MAC.
 -Anthony
 
 From: Martinx - ?` thiagocmarti...@gmail.com
 Reply-To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Date: Thursday, May 15, 2014 at 14:18 
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [Neutron][IPv6] Privacy extension
 
 Hello!
 
 I agree that there is no need for Privacy Extensions in a Cloud 
 environment, since MAC address are fake... No big deal...
 
 Nevertheless, I think that should be nice to allow 1 Instance to have more 
 than 1 IPv6 addr, since IPv6 is (almost) virtually unlimited... This way, 
 a VM with, for example, a range of IPv6s to it, can have a shared host 
 environment when each website have its own IPv6 address (I prefer to use 
 IP-Based virtualhosts on Apache, instead of Name-Based)...
 
 Cheers!
 Thiago
 
 
 On 15 May 2014 14:22, Ian Wells ijw.ubu...@cack.org.uk wrote:
 I was just about to respond to that in the session when we ran out of 
 time.  I would vote for simply insisting that VMs run without the privacy 
 extension enabled, and only permitting the expected ipv6 address based on 
 MAC.  Its primary purpose is to conceal your MAC address so that your IP 
 address can't be used to track you, as I understand it, and I don't think 
 that's as relevant in a cloud environment and where the MAC addresses are 
 basically fake.  Someone interested in desktop virtualisation with 
 Openstack may wish to contradict me...
 -- 
 Ian.
 
 
 On 15 May 2014 09:30, Shixiong Shang sparkofwisdom.cl...@gmail.com 
 wrote:
 Hi, guys:
 
 Nice to meet with all of you in the technical session and design 
 session. I mentioned the challenge of privacy extension in the meeting, 
 but would like to hear your opinions of how to address the problem. If 
 you have any comments or suggestions, please let me know. I will create 
 a BP for this problem.
 
 Thanks!
 
 Shixiong
 
 
 Shixiong Shang
 
 !--- Stay Hungry, Stay Foolish ---!
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



Shixiong Shang

!--- Stay Hungry, Stay Foolish ---!

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][IPv6] Agenda for tomorrow's meeting - please add items

[Collins, Sean]

https://wiki.openstack.org/wiki/Meetings/Neutron-IPv6-Subteam#Agenda_for_May_20th

-- 
Sean M. Collins
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][IPv6] Small feedback about Management Network API Endpoints

[Martinx - ジェームズ]

Guys,

I did a few changes on my environment (OpenStack IceHouse on IPv6),
everything seems to be working smoothly now...

Just deployed Heat on IPv6 too...

I didn't tested Ceilomenter and Cinder Volume (iSCSI traffic) with IPv6
yet...

I'm writing a new Multinode Quick Guide to deploy OpenStack IceHouse on
an (almost) IPv6-Only environment.

Nevertheless, OpenStack still depends on an IPv4-Only networks for
Metadata, for GRE / VXLAN tunnels and for Project Subnets (no Neutron
IPv6 yet), everything else (Management, APIs and Endpoints) seems to be
working with IPv6 (including RabbitMQ, MySQL, Keystone, Nova, Glance,
Neutron (API/Endpoint), Horizon, SPICE Consoles, Heat, Cinder (APIs /
Management (iSCSI not tests with IPv6 yet))...

Soon as I finish the new guide, I'll post it here...

BTW, because of Glance can't use Proxy to download Images, I configured a
NAT64/DNS64 here, so, it can reach the old Internet infrastructure
normally...

Best!
Thiago


On 13 May 2014 03:17, Martinx - ジェームズ thiagocmarti...@gmail.com wrote:

 Guys,

 I'm running OpenStack IceHouse configured with IPv6 in almost every part
 of it, I can say that both `Management Network` and `API Endpoints` works
 with IPv6, but, there are still only three places that I am unable to use
 it with IPv6, which is:


 1- Metadata (no IPv6 here, the equivalent of 169.254.0.0/16 for IPv6 is
 the subnet fe80::/64, am I right?);

 2- VXLAN / GRE tunnels, precisely at `local_ip` in ml2_conf.ini (it
 doesn't work when with IPv6);

 3- Tenant subnet (IPv6 works with Flat Networks and statically/manually
 configured, no SLAAC and no Neutron L3 with IPv6 yet).


 NOTE: I still did not tested Heat, Cinder or Swift.


 Everything else is working with IPv6!

 Here is a few more details about my environment:

 Controller's /etc/network/interface file:

 ---
 # This file describes the network interfaces available on your system
 # and how to activate them. For more information, see interfaces(5).

 # The loopback network interface
 auto lo
 iface lo inet loopback

 # The primary network interface
 #
 # OpenStack API Endpoints
 auto eth0
 iface eth0 inet6 static
 address 2804:29X:Y:dead::10
 netmask 64
 gateway 2804:29X:Y:dead::1
 dns-domain tcmc.com.br
 dns-search tcmc.com.br
 dns-nameservers 2804:29X:4::1 2001:129X:2bX::1

 # OpenStack - Management
 auto eth1
 iface eth1 inet6 static
 address fddc:3c8c:6e8c:b129::10
 netmask 64

 # Legacy - Only required because of Metadata, it doesn't have an IPv6
 # equivalent service for subnet IPv4 = 169.254.0.0/16 (IPv6 = fc80::/64)
 iface eth1 inet static
 address 192.168.5.10
 netmask 24
 ---

 Network Node /etc/network/interfaces file:

 ---
 # This file describes the network interfaces available on your system
 # and how to activate them. For more information, see interfaces(5).

 # The loopback network interface.
 auto lo
 iface lo inet loopback

 #
 # Reachable from the Internet.
 #

 # The primary network interface. Node Internet access.
 auto eth0
 iface eth0 inet6 static
 address 2804:29X:Y:dead::20
 netmask 64
  gateway 2804:29X:Y:dead::1
 dns-domain tcmc.com.br
 dns-search tcmc.com.br
 dns-nameservers 2804:290:4::1 2001:1291:2bf::1

 #
 # Unreachable from the Internet.
 #

 # OpenStack - Management
 auto eth1
 iface eth1 inet6 static
 address fddc:3c8c:6e8c:b129::20
 netmask 64

 # Legacy - Only required because of Metadata, it doesn't have an IPv6
 # equivalent service for subnet IPv4 = 169.254.0.0/16 (IPv6 = fc80::/64).
 iface eth1 inet static
 address 192.168.5.20
 netmask 24

 # VXLAN Traffic - Not working right now with IPv6.
 auto eth2
 iface eth2 inet6 static
 address fda2:c917:cd2e:0552::20
 netmask 64

 # Legacy - Only required because Neutron doesn't support VXLAN tunnels on
 top
 # of a IPv6 network.
 iface eth2 inet static
 address 192.168.6.20
 netmask 24

 #
 # Reachable from the Internet only from within each Namespace router.
 #

 # Bridge br-ex attached here, this is the WAN Port of tenant's routers.
 auto eth3
 iface eth3 inet manual
 up ip addr add 0/0 dev eth3
  up ip link set dev $IFACE up
 up ip link set $IFACE promisc on
  up ethtool --offload $IFACE gro off
 down ip link set $IFACE promisc off
  down ip link set $IFACE down
 ---


 Common /etc/hosts file across the Cloud:

 ---
 127.0.0.1   localhost.localdomain   localhost

 # The following lines are desirable for IPv6 capable hosts
 ::1 localhost ip6-localhost ip6-loopback
 ff02::1 ip6-allnodes
 ff02::2 ip6-allrouters

 # OpenStack APIs Endpoints
 2804:29X:Y:dead::10 psuaa-1.tcmc.com.br psuaa-1
 2804:29X:Y:dead::20 psuab-1.tcmc.com.br psuab-1
 2804:29X:Y:dead::30 psuac-1.tcmc.com.br psuac-1
 2804:29X:Y:dead::1000   psuah-1.tcmc.com.br psuah-1

  # OpenStack Management - MySQL, RabbitMQ, SPICE, Glance...
 fddc:3c8c:6e8c:b129::10