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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

-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

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

-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

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

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

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?

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.

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

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

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

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

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.

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

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

[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 Mailbox for

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

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

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.

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

@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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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:

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

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,

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

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

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

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,

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

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

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

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

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

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)

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

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,

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

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.

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

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,

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

Re: [openstack-dev] [Neutron][IPv6] Allowing Plugins in tree that explicitly do not support IPv6

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.

Re: [openstack-dev] [Neutron][IPv6] Allowing Plugins in tree that explicitly do not support IPv6

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,

Re: [openstack-dev] [Neutron][IPv6] Allowing Plugins in tree that explicitly do not support IPv6

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:

[openstack-dev] [Neutron][IPv6] Allowing Plugins in tree that explicitly do not support IPv6

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

Re: [openstack-dev] [Neutron][IPv6]

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

[openstack-dev] [Neutron] [IPv6] Hide ipv6 subnet API attributes

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/

Re: [openstack-dev] [Neutron] [IPv6] Hide ipv6 subnet API attributes

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

Re: [openstack-dev] [Neutron] [IPv6] Hide ipv6 subnet API attributes

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?

Re: [openstack-dev] [Neutron][IPv6] Volunteer to run tomorrow's IRC meeting?

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

Re: [openstack-dev] [Neutron][IPv6] Volunteer to run tomorrow's IRC meeting?

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

Re: [openstack-dev] [Neutron][IPv6] Volunteer to run tomorrow's IRC meeting?

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

[openstack-dev] [Neutron][IPv6] Volunteer to run tomorrow's IRC meeting?

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

Re: [openstack-dev] [Neutron][IPv6] Neutron IPv6 in Icehouse and further

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

Re: [openstack-dev] [Neutron][IPv6] Neutron IPv6 in Icehouse and further

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

[openstack-dev] [Neutron][IPv6] Neutron IPv6 in Icehouse and further

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

Re: [openstack-dev] [Neutron][IPv6] Neutron IPv6 in Icehouse and further

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

Re: [openstack-dev] [neutron][ipv6] Do you have problem accessing IRC

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

Re: [openstack-dev] [neutron][ipv6] Support ipv6 RA in neutron

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

[openstack-dev] [neutron][ipv6] ipv6 dual stack

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

Re: [openstack-dev] [neutron][ipv6] Support ipv6 RA in neutron

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

Re: [openstack-dev] [neutron][ipv6] ipv6 dual stack

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

Re: [openstack-dev] [neutron][ipv6] ipv6 dual stack

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

[openstack-dev] [Neutron][IPv6] Issues on dnsmasq

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!

Re: [openstack-dev] [Neutron][IPv6] Issues on dnsmasq

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

Re: [openstack-dev] [Neutron][IPv6] Minutes from May 27 2014

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

Re: [openstack-dev] [Neutron][IPv6] Neutron Routers and LLAs

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

[openstack-dev] [Neutron][IPv6] Minutes from May 27 2014

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

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:

[openstack-dev] [Neutron][IPv6] Meeting minutes for 5/20/2014

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

...@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

[openstack-dev] [Neutron][IPv6] Agenda for tomorrow's meeting - please add items

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

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

  1   2   3   4   >