[openstack-dev] [Neutron][IPv6]

[Shixiong Shang]

Hi, Sean and the team:

Do we have a list of code reviews and a list of BPs submitted by Neutron IPv6 
sub-team targeting at Icehouse 3? Would appreciate everybody’s help to compose 
a list so we won’t overlook anything, especially the deadline is next Friday.

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] [Neutron][IPv6]

[Randy Tuttle]

Hi all.

Just submitted the code[1] for supporting dual-stack (IPv6 and IPv4) on an
external gateway port of a tenant's router (l3_agent). It implements [2].

Please, if you would, have a look and provide any feedback. I would be
grateful.

Cheers,
Randy

[1]. https://review.openstack.org/#/c/77471/
[2].
https://blueprints.launchpad.net/neutron/+spec/allow-multiple-subnets-on-gateway-port
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] IPv6 Status

[Andreas Scheuring]

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


-- 
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]

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

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

[Xuhan Peng]

Here is a list of related blueprint and bug patches:

Create new IPv6 attributes for Subnets
https://review.openstack.org/#/c/52983/

Ensure entries in dnsmasq belong to a subnet using DHCP
https://review.openstack.org/#/c/64578/

Calculate stateless IPv6 address
https://review.openstack.org/#/c/56184/

Add support to DHCP agent for BP ipv6-two-attributes
https://review.openstack.org/#/c/70649/

Permit ICMPv6 RAs only from known routers
https://review.openstack.org/#/c/72252/

Allow LLA as router interface of IPv6 subnet
https://review.openstack.org/#/c/76125/

Create new IPv6 attributes for Subnets by client
https://review.openstack.org/#/c/75871/

Make sure dnsmasq can distinguish IPv6 address from MAC address
https://review.openstack.org/#/c/75355/


On Thu, Feb 27, 2014 at 9:04 AM, Shixiong Shang <
sparkofwisdom.cl...@gmail.com> wrote:

> Hi, Sean and the team:
>
> Do we have a list of code reviews and a list of BPs submitted by Neutron
> IPv6 sub-team targeting at Icehouse 3? Would appreciate everybody's help to
> compose a list so we won't overlook anything, especially the deadline is
> next Friday.
>
> 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]

[Henry Gessau]

On Sat, Mar 01, at 0:46 am, Shixiong Shang  wrote:

> What should I do to fix these “tempest” failures? Any suggestions or
> pointers are highly appreciated!

Your patch depends on review 52983, which needs to rebase and update its
migration script with the latest down revision. Then you need to update your
dependency.

> 
> Thanks!
> 
> Shixiong
> 
> 
> Jenkins   12:36 AM
> 
> Patch Set 13: Doesn't seem to work
> Build failed. For information on how to proceed,
> see https://wiki.openstack.org/wiki/GerritJenkinsGit#Test_Failures
> 
>   * gate-neutron-pep8
>  
> SUCCESS in
> 1m 59s
>   * gate-neutron-docs
> 
> 
>  SUCCESS in
> 2m 27s
>   * gate-neutron-python26
> 
>  
> SUCCESS in
> 19m 13s
>   * gate-neutron-python27
> 
>  
> SUCCESS in
> 13m 04s
>   * check-tempest-dsvm-neutron
> 
> 
>  FAILURE in
> 10m 46s
>   * check-tempest-dsvm-neutron-full
> 
> 
>  FAILURE in
> 11m 20s (non-voting)
>   * check-tempest-dsvm-neutron-pg
> 
> 
>  FAILURE in
> 12m 58s
>   * check-tempest-dsvm-neutron-isolated
> 
> 
>  FAILURE in
> 9m 27s
>   * check-tempest-dsvm-neutron-pg-isolated
> 
> 
>  FAILURE in
> 10m 01s
>   * gate-tempest-dsvm-neutron-large-ops
> 
> 
>  FAILURE in
> 25m 45s
>   * check-grenade-dsvm-neutron
> 
> 
>  FAILURE in
> 25m 49s (non-voting)
>   * check-devstack-dsvm-neutron
> 
> 
>  FAILURE in
> 11m 38s (non-voting)
> 
> 
> 
> *
> 
> *
> *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]

[Xuhan Peng]

Randy,

I haven't checked the code detail yet, but I have a general question about
this blueprint. Considering multiple external networks on L3 agent is
supported [1]. Do you think it's still necessary to use separate subnets on
one external network for IPv4 and IPv6 instead of using two external
networks?

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

Thanks!
Xuhan



On Mon, Mar 3, 2014 at 10:47 AM, Randy Tuttle wrote:

> Hi all.
>
> Just submitted the code[1] for supporting dual-stack (IPv6 and IPv4) on an
> external gateway port of a tenant's router (l3_agent). It implements [2].
>
> Please, if you would, have a look and provide any feedback. I would be
> grateful.
>
> Cheers,
> Randy
>
> [1]. https://review.openstack.org/#/c/77471/
> [2].
> https://blueprints.launchpad.net/neutron/+spec/allow-multiple-subnets-on-gateway-port
>
> ___
> 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]

[Randy Tuttle]

Hi Yuhan

I am a bit familiar with this change as we tried it in out POC [1] for IPv6
dual-stack. It achieves a similar function, as best as I understand, by
allowing multiple external bridges (and, therefore, external interfaces).
The feature I am providing here achieves approximately the same thing
(explicitly, a dual-stack arrangement) on the *same* interface, thereby
requiring only a *single* external bridge (and *single* external interface).

I think it just gives more flexibility. We can surely discuss.

Thanks for your comments!! Good discussion.
Randy

[1] http://www.nephos6.com/pdf/OpenStack-Havana-on-IPv6.pdf


On Mon, Mar 3, 2014 at 2:33 AM, Xuhan Peng  wrote:

> Randy,
>
> I haven't checked the code detail yet, but I have a general question about
> this blueprint. Considering multiple external networks on L3 agent is
> supported [1]. Do you think it's still necessary to use separate subnets on
> one external network for IPv4 and IPv6 instead of using two external
> networks?
>
> [1] https://review.openstack.org/#/c/59359/
>
> Thanks!
> Xuhan
>
>
>
> On Mon, Mar 3, 2014 at 10:47 AM, Randy Tuttle wrote:
>
>> Hi all.
>>
>> Just submitted the code[1] for supporting dual-stack (IPv6 and IPv4) on
>> an external gateway port of a tenant's router (l3_agent). It implements [2].
>>
>> Please, if you would, have a look and provide any feedback. I would be
>> grateful.
>>
>> Cheers,
>> Randy
>>
>> [1]. https://review.openstack.org/#/c/77471/
>> [2].
>> https://blueprints.launchpad.net/neutron/+spec/allow-multiple-subnets-on-gateway-port
>>
>> ___
>> 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 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

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

[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

[openstack-dev] [Neutron][IPv6] NAT64 Discussion

[Xuhan Peng]

In previous Neutron IPv6 team meeting, we discussed the requirement of
providing NAT64 in OpenStack to facilitate the communication between IPv6
and IPv4 hosts. For example, from tenant IPv6 network to external
traditional IPv4 network. I was suggested to initiate a discussion in ML to
gather all forks thoughts.

I wonder if this is a fairly common requirement and what is the good way to
add this possibility to OpenStack. Several ways we mentioned in previous
sub-team meeting:

1. Add to current Neutron L3
This was also asked by Martinx in [1].
2. Run as service VM
3. Maybe even a new sub-project/project dedicated for address translation

I also want to mention that NAT64 may not be the only requirement to
communicate between IPv6 and IPv4 hosts. 6in4 tunneling and other methods
are als candidates.

[1]
http://lists.openstack.org/pipermail/openstack-dev/2014-January/023265.html

Your comments are appreciated!

Xuhan Peng (irc: xuhanp)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][IPv6] tox error

[Shixiong Shang]

Hi, guys:

I run into this error while running fox…..but it gave me this error…Seems like 
it is related to Neutron LB. Did you see this issue before? If so, how to fix 
it?

Thanks!

Shixiong


shshang@net-ubuntu2:~/github/neutron$ tox -v -e py27
……...
tests.unit.test_wsgi.XMLDictSerializerTest.test_xml_with_utf8\xa2\xbe\xf7u\xb3 
`@d\x17text/plain;charset=utf8\rimport 
errors4neutron.tests.unit.linuxbridge.test_lb_neutron_agent\x85\xc5\x1a\\', 
stderr=None
error: testr failed (3)
ERROR: InvocationError: '/home/shshang/github/neutron/.tox/py27/bin/python -m 
neutron.openstack.common.lockutils python setup.py testr --slowest 
--testr-args='

 summary 

ERROR:   py27: commands failed


(py27)shshang@net-ubuntu2:~/github/neutron/.tox/py27/bin$ python
Python 2.7.5+ (default, Sep 19 2013, 13:48:49)
[GCC 4.8.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import errors4neutron.tests.unit.linuxbridge.test_lb_neutron_agent
Traceback (most recent call last):
  File "", line 1, in 
ImportError: No module named 
errors4neutron.tests.unit.linuxbridge.test_lb_neutron_agent





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

[openstack-dev] [Neutron] IPv6 sub-team?

[Collins, Sean (Contractor)]

Hi,

Is there any interest in organizing a IPv6 sub-team, similar to how
there are sub-teams for FwaaS, VPNaas, ML2, etc?

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

[openstack-dev] [Neutron] IPv6 sub-team?

[Shixiong Shang]

+1.

We have great interest to run OpenStack over IPv6 and would love to be a
part of the discussion.

Please let me know the date and the time.

Thanks!

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

[openstack-dev] [Neutron][IPv6] Provisioning Support

[Veiga, Anthony]

As part of the discussion around managing IPv6-addressed hosts both within
neutron itself and other systems that require address information, Sean
Collins and I had had a discussion about the types of addresses that could
be supported.  Since IPv6 has many modes of provisioning, we will need to
provide support for each of them.  However, there is a caveat when dealing
with SLAAC provisioning.  The only method of provisioning that is
predictable from Neutron's point of view is EUI-64.  Dazhao Yu has worked
on a patch set to do this [1].  Privacy Extensions are in use and well
documented by the IETF (RFC 4941), however it is not feasible for Neutron
to predict these addresses.  Thus it is my opinion that OpenStack should
officially support using EUI-64 only for provisioning addresses via SLAAC.
 This does not preclude PE methods from functioning, but it will be
impossible to provide the guest's IPv6 address to other systems such as
FWaaS or LBaaS.  Also, this is only for SLAAC provisioning mode.  Stateful
(DHCPv6) and static injection should not be impacted here.

To this end, I'd like to propose that OpenStack officially support guests
using EUI-64 when using SLAAC for provisioning.  Note that I am NOT
proposing anything regarding DHCPv6 or static provisioning, as I believe
that should allow any of the existing allocation methods.


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

-Anthony


___
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

[Collins, Sean]

Meeting minutes:

http://eavesdrop.openstack.org/meetings/neutron_ipv6/2014/neutron_ipv6.2014-04-15-14.00.html

See you next week!

-- 
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] Privacy extension

[Shixiong Shang]

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] [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

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" 
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

[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] tox error

[Randy Tuttle]

When I see a fox, it is usually running b-( = ))

Sent from my iPhone

> On Feb 24, 2014, at 6:08 PM, Shixiong Shang  
> wrote:
> 
> Hi, guys:
> 
> I run into this error while running fox…..but it gave me this error…Seems 
> like it is related to Neutron LB. Did you see this issue before? If so, how 
> to fix it?
> 
> Thanks!
> 
> Shixiong
> 
> 
> shshang@net-ubuntu2:~/github/neutron$ tox -v -e py27
> ……...
> tests.unit.test_wsgi.XMLDictSerializerTest.test_xml_with_utf8\xa2\xbe\xf7u\xb3
>  `@d\x17text/plain;charset=utf8\rimport 
> errors4neutron.tests.unit.linuxbridge.test_lb_neutron_agent\x85\xc5\x1a\\', 
> stderr=None
> error: testr failed (3)
> ERROR: InvocationError: '/home/shshang/github/neutron/.tox/py27/bin/python -m 
> neutron.openstack.common.lockutils python setup.py testr --slowest 
> --testr-args='
> 
>  summary 
> 
> ERROR:   py27: commands failed
> 
> 
> (py27)shshang@net-ubuntu2:~/github/neutron/.tox/py27/bin$ python
> Python 2.7.5+ (default, Sep 19 2013, 13:48:49)
> [GCC 4.8.1] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
 import errors4neutron.tests.unit.linuxbridge.test_lb_neutron_agent
> Traceback (most recent call last):
>  File "", line 1, in 
> ImportError: No module named 
> errors4neutron.tests.unit.linuxbridge.test_lb_neutron_agent
> 
> 
> 
> 
> 
> ___
> 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] tox error

[Collins, Sean]

Shixiong Shang and I ran into this problem with Tox today while we were
pair programming, and I've also seen similar barfs on my DevStack lab
boxes - it's quite a mess. Frankly I've moved to using nosetests as a
workaround, and have added it to the developer docs. 

We really do need to figure out how to make Tox and Testr give more
useful failure output - it's so huge it makes my iTerm2 window lock up
when I try and do an incremental search on the output.

Help from a Testr / Tox guru would be appreciated.

-- 
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] tox error

[Clark Boylan]

On Thu, Feb 27, 2014 at 11:39 AM, Collins, Sean
 wrote:
> Shixiong Shang and I ran into this problem with Tox today while we were
> pair programming, and I've also seen similar barfs on my DevStack lab
> boxes - it's quite a mess. Frankly I've moved to using nosetests as a
> workaround, and have added it to the developer docs.
>
> We really do need to figure out how to make Tox and Testr give more
> useful failure output - it's so huge it makes my iTerm2 window lock up
> when I try and do an incremental search on the output.
>
> Help from a Testr / Tox guru would be appreciated.
>
> --
> Sean M. Collins
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

These failures are a result of testr or discover (depending on the
step in the test process, discovery happens first) running into python
import failures. In the example above it looks like
neutron.tests.unit.
linuxbridge.test_lb_neutron_agent failed to import. You can spin up a
python interpreter and try importing that to debug (note that is what
you tried to do but I believe errors4 is part of the error message and
not the thing that couldn't be imported). Flake8 may also catch the
problem. Lifeless has laid the groundwork to fix this upstream in
testtools [0], but I don't think the corresponding testrepository
improvements have been released yet. You can however install
testrepository from source [1] and see if that solves your problem.

Without seeing the code in question it is really hard to debug any
further. If nosetests does work that would indicate a possible
intertest dependency that nose resolves by running tests in a
particular order which is different than the order used by testr.
Finally, when using the python executable from a virtualenv you don't
want to be in the virtualenv's bin dir. To do a proper import test you
want to be in the root dir of the repository `cd ~/github/neutron` the
either activate the virtualenv and run python or skip activation and
do `.tox/py27/bin/python` to run the virtualenv's python binary.

[0] 
https://github.com/testing-cabal/testtools/commit/6da4893939c6fd2d732bb20a4ac50db2fe639132
[1] https://launchpad.net/testrepository/

Hope this helps,
Clark

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

[openstack-dev] [Neutron][IPv6] tox run forever

[Shixiong Shang]

In case you have filter set up on your mail client……..



Begin forwarded message:

> From: Shixiong Shang 
> Subject: [openstack-dev] [Neutron] tox run forever
> Date: February 27, 2014 at 7:43:03 PM EST
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> 
> Hi, guys:
> 
> I created a fresh local repository and pulled the most recent Neutron code. 
> Before I put in my own code, I did TOX run. However, seems like it is stuck 
> to the following condition for over a hour and didn’t go any further. 
> Yesterday, the TOX had been running with a fresh copy of Neutron, but didn’t 
> return SUCCESS after the entire night.
> 
> I assume the copy from MASTER BRANCH should already be sanitized…..However, 
> what I saw in the past 48 hours told me different story. Did I do anything 
> wrong?
> 
> 
> shshang@net-ubuntu2:~/github/neutron$ tox -e py27
> py27 create: /home/shshang/github/neutron/.tox/py27
> py27 installdeps: -r/home/shshang/github/neutron/requirements.txt, 
> -r/home/shshang/github/neutron/test-requirements.txt, setuptools_git>=0.4
> py27 develop-inst: /home/shshang/github/neutron
> py27 runtests: commands[0] | python -m neutron.openstack.common.lockutils 
> python setup.py testr --slowest --testr-args=
> [pbr] Excluding argparse: Python 2.6 only dependency
> running testr
> running=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_LOG_CAPTURE=1 
> ${PYTHON:-python} -m subunit.run discover -t ./ 
> ${OS_TEST_PATH:-./neutron/tests/unit} --list
> running=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_LOG_CAPTURE=1 
> ${PYTHON:-python} -m subunit.run discover -t ./ 
> ${OS_TEST_PATH:-./neutron/tests/unit}  --load-list /tmp/tmpbZwLwg
> running=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_LOG_CAPTURE=1 
> ${PYTHON:-python} -m subunit.run discover -t ./ 
> ${OS_TEST_PATH:-./neutron/tests/unit}  --load-list /tmp/tmp39qJYM
> running=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_LOG_CAPTURE=1 
> ${PYTHON:-python} -m subunit.run discover -t ./ 
> ${OS_TEST_PATH:-./neutron/tests/unit}  --load-list /tmp/tmpppXiTc
> running=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_LOG_CAPTURE=1 
> ${PYTHON:-python} -m subunit.run discover -t ./ 
> ${OS_TEST_PATH:-./neutron/tests/unit}  --load-list /tmp/tmpPhJZDc
> 
> Thanks!
> 
> Shixiong

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

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

[Randy Tuttle]

Clark/Sean/Shixiong...

I have the same error, and tried to import
neutron.tests.unit.linuxbridge.test_lb_neutron_agent (no error4 prefix). I
get the following

(py27)rantuttl-mac:bin rtuttle$ python
Python 2.7.5 (v2.7.5:ab05e7dd2788, May 13 2013, 13:18:45)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import neutron.tests.unit.linuxbridge.test_lb_neutron_agent
Traceback (most recent call last):
  File "", line 1, in 
  File
"/Users/rtuttle/projects/neutron/neutron/tests/unit/linuxbridge/test_lb_neutron_agent.py",
line 29, in 
from neutron.plugins.linuxbridge.agent import linuxbridge_neutron_agent
  File
"/Users/rtuttle/projects/neutron/neutron/plugins/linuxbridge/agent/linuxbridge_neutron_agent.py",
line 33, in 
import pyudev
ImportError: No module named pyudev
>>>

Looks like it wants pyudev, which is not anywhere that I can find, and is
not in requirements.txt.

Code slice.
import distutils.version as dist_version
import os
import platform
import sys
import time

import eventlet
from oslo.config import cfg
import pyudev

from neutron.agent import l2population_rpc as l2pop_rpc
from neutron.agent.linux import ip_lib


Still digging into it...

Randy



On Thu, Feb 27, 2014 at 3:10 PM, Clark Boylan wrote:

> On Thu, Feb 27, 2014 at 11:39 AM, Collins, Sean
>  wrote:
> > Shixiong Shang and I ran into this problem with Tox today while we were
> > pair programming, and I've also seen similar barfs on my DevStack lab
> > boxes - it's quite a mess. Frankly I've moved to using nosetests as a
> > workaround, and have added it to the developer docs.
> >
> > We really do need to figure out how to make Tox and Testr give more
> > useful failure output - it's so huge it makes my iTerm2 window lock up
> > when I try and do an incremental search on the output.
> >
> > Help from a Testr / Tox guru would be appreciated.
> >
> > --
> > Sean M. Collins
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> These failures are a result of testr or discover (depending on the
> step in the test process, discovery happens first) running into python
> import failures. In the example above it looks like
> neutron.tests.unit.
> linuxbridge.test_lb_neutron_agent failed to import. You can spin up a
> python interpreter and try importing that to debug (note that is what
> you tried to do but I believe errors4 is part of the error message and
> not the thing that couldn't be imported). Flake8 may also catch the
> problem. Lifeless has laid the groundwork to fix this upstream in
> testtools [0], but I don't think the corresponding testrepository
> improvements have been released yet. You can however install
> testrepository from source [1] and see if that solves your problem.
>
> Without seeing the code in question it is really hard to debug any
> further. If nosetests does work that would indicate a possible
> intertest dependency that nose resolves by running tests in a
> particular order which is different than the order used by testr.
> Finally, when using the python executable from a virtualenv you don't
> want to be in the virtualenv's bin dir. To do a proper import test you
> want to be in the root dir of the repository `cd ~/github/neutron` the
> either activate the virtualenv and run python or skip activation and
> do `.tox/py27/bin/python` to run the virtualenv's python binary.
>
> [0]
> https://github.com/testing-cabal/testtools/commit/6da4893939c6fd2d732bb20a4ac50db2fe639132
> [1] https://launchpad.net/testrepository/
>
> Hope this helps,
> Clark
>
> ___
> 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] tox error

[Shixiong Shang]

Hi, Randy:

Try this command to install pyudev library….

sudo pip install pyudev

Let me know whether it works or not. Good luck!

Shixiong





Shixiong Shang

!--- Stay Hungry, Stay Foolish ---!

On Feb 27, 2014, at 9:09 PM, Randy Tuttle  wrote:

> Clark/Sean/Shixiong...
> 
> I have the same error, and tried to import 
> neutron.tests.unit.linuxbridge.test_lb_neutron_agent (no error4 prefix). I 
> get the following
> 
> (py27)rantuttl-mac:bin rtuttle$ python
> Python 2.7.5 (v2.7.5:ab05e7dd2788, May 13 2013, 13:18:45) 
> [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import neutron.tests.unit.linuxbridge.test_lb_neutron_agent
> Traceback (most recent call last):
>   File "", line 1, in 
>   File 
> "/Users/rtuttle/projects/neutron/neutron/tests/unit/linuxbridge/test_lb_neutron_agent.py",
>  line 29, in 
> from neutron.plugins.linuxbridge.agent import linuxbridge_neutron_agent
>   File 
> "/Users/rtuttle/projects/neutron/neutron/plugins/linuxbridge/agent/linuxbridge_neutron_agent.py",
>  line 33, in 
> import pyudev
> ImportError: No module named pyudev
> >>> 
> 
> Looks like it wants pyudev, which is not anywhere that I can find, and is not 
> in requirements.txt.
> 
> Code slice.
> import distutils.version as dist_version
> import os
> import platform
> import sys
> import time
> 
> import eventlet
> from oslo.config import cfg
> import pyudev
> 
> from neutron.agent import l2population_rpc as l2pop_rpc
> from neutron.agent.linux import ip_lib
> 
> 
> Still digging into it...
> 
> Randy
> 
> 
> 
> On Thu, Feb 27, 2014 at 3:10 PM, Clark Boylan  wrote:
> On Thu, Feb 27, 2014 at 11:39 AM, Collins, Sean
>  wrote:
> > Shixiong Shang and I ran into this problem with Tox today while we were
> > pair programming, and I've also seen similar barfs on my DevStack lab
> > boxes - it's quite a mess. Frankly I've moved to using nosetests as a
> > workaround, and have added it to the developer docs.
> >
> > We really do need to figure out how to make Tox and Testr give more
> > useful failure output - it's so huge it makes my iTerm2 window lock up
> > when I try and do an incremental search on the output.
> >
> > Help from a Testr / Tox guru would be appreciated.
> >
> > --
> > Sean M. Collins
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> These failures are a result of testr or discover (depending on the
> step in the test process, discovery happens first) running into python
> import failures. In the example above it looks like
> neutron.tests.unit.
> linuxbridge.test_lb_neutron_agent failed to import. You can spin up a
> python interpreter and try importing that to debug (note that is what
> you tried to do but I believe errors4 is part of the error message and
> not the thing that couldn't be imported). Flake8 may also catch the
> problem. Lifeless has laid the groundwork to fix this upstream in
> testtools [0], but I don't think the corresponding testrepository
> improvements have been released yet. You can however install
> testrepository from source [1] and see if that solves your problem.
> 
> Without seeing the code in question it is really hard to debug any
> further. If nosetests does work that would indicate a possible
> intertest dependency that nose resolves by running tests in a
> particular order which is different than the order used by testr.
> Finally, when using the python executable from a virtualenv you don't
> want to be in the virtualenv's bin dir. To do a proper import test you
> want to be in the root dir of the repository `cd ~/github/neutron` the
> either activate the virtualenv and run python or skip activation and
> do `.tox/py27/bin/python` to run the virtualenv's python binary.
> 
> [0] 
> https://github.com/testing-cabal/testtools/commit/6da4893939c6fd2d732bb20a4ac50db2fe639132
> [1] https://launchpad.net/testrepository/
> 
> Hope this helps,
> Clark
> 
> ___
> 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] IRC meeting today?

[Shixiong Shang]

Do we have IRC meeting today? Didn’t see anybody in the chat room…..:(

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 sub-team?

[Kyle Mestery (kmestery)]

On Nov 5, 2013, at 5:50 PM, "Collins, Sean (Contractor)" 
 wrote:
> Hi,
> 
> Is there any interest in organizing a IPv6 sub-team, similar to how
> there are sub-teams for FwaaS, VPNaas, ML2, etc?


+1, lets do it!
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] IPv6 sub-team?

[Brian Haley]

On 11/06/2013 07:50 AM, Collins, Sean (Contractor) wrote:

Hi,

Is there any interest in organizing a IPv6 sub-team, similar to how
there are sub-teams for FwaaS, VPNaas, ML2, etc?



+1 from me.

-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 sub-team?

[Edgar Magana]

Absolutely!

+1

Edgar

On 11/5/13 3:50 PM, "Collins, Sean (Contractor)"
 wrote:

>Hi,
>
>Is there any interest in organizing a IPv6 sub-team, similar to how
>there are sub-teams for FwaaS, VPNaas, ML2, etc?
>
>-- 
>Sean M. Collins
>AIM: seanwdp
>___
>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 sub-team?

[Collins, Sean (Contractor)]

Cool!

I've put a placeholder on the meetings wiki page, until we can find a
time that works for everyone.

-- 
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 sub-team?

[Mark McClain]

I definitely think this should be a standing Neutron sub team. 

mark

> On Nov 6, 2013, at 7:50 AM, "Collins, Sean (Contractor)" 
>  wrote:
> 
> Hi,
> 
> Is there any interest in organizing a IPv6 sub-team, similar to how
> there are sub-teams for FwaaS, VPNaas, ML2, etc?
> 
> -- 
> Sean M. Collins
> AIM: seanwdp
> ___
> 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 sub-team?

[Miguel Angel]

+1 from me!

(I think it's my first message on the list, so Hi! ;)

Miguel Angel Ajo Pelayo
+34 636 52 25 69
skype: ajoajoajo


2013/11/6 Mark McClain 

> I definitely think this should be a standing Neutron sub team.
>
> mark
>
> > On Nov 6, 2013, at 7:50 AM, "Collins, Sean (Contractor)" <
> sean_colli...@cable.comcast.com> wrote:
> >
> > Hi,
> >
> > Is there any interest in organizing a IPv6 sub-team, similar to how
> > there are sub-teams for FwaaS, VPNaas, ML2, etc?
> >
> > --
> > Sean M. Collins
> > AIM: seanwdp
> > ___
> > 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 sub-team?

[Hampapur Ajay]

+1
we are in process of designing/implementing this and want to be part of the 
community effort. 

On Nov 5, 2013, at 3:50 PM, "Collins, Sean (Contractor)" 
 wrote:

> Hi,
> 
> Is there any interest in organizing a IPv6 sub-team, similar to how
> there are sub-teams for FwaaS, VPNaas, ML2, etc?
> 
> -- 
> Sean M. Collins
> AIM: seanwdp
> ___
> 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 sub-team?

[Collins, Sean (Contractor)]

How about scheduling an IRC meeting in close proximity to the other
Neutron meetings on Mondays?

* 20:00 to 21:00 UTC, before the Neutron meeting

OR

* 23:00 UTC - after the distributed virtual router 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 sub-team?

[Brian Haley]

On 11/08/2013 11:21 AM, Collins, Sean (Contractor) wrote:

How about scheduling an IRC meeting in close proximity to the other
Neutron meetings on Mondays?

* 20:00 to 21:00 UTC, before the Neutron meeting


+0


OR

* 23:00 UTC - after the distributed virtual router meeting?


-1

I'd prefer a different day altogether since three meetings in a row 
would be tough, but that's just my opinion...


-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 sub-team?

[Kyle Mestery (kmestery)]

On Nov 8, 2013, at 12:01 AM, Brian Haley  wrote:

> On 11/08/2013 11:21 AM, Collins, Sean (Contractor) wrote:
>> How about scheduling an IRC meeting in close proximity to the other
>> Neutron meetings on Mondays?
>> 
>> * 20:00 to 21:00 UTC, before the Neutron meeting
> 
> +0
> 
>> OR
>> 
>> * 23:00 UTC - after the distributed virtual router meeting?
> 
> -1
> 
> I'd prefer a different day altogether since three meetings in a row would be 
> tough, but that's just my opinion…
> 
+1 to this.

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

Re: [openstack-dev] [Neutron] IPv6 sub-team?

[Stephen Wong]

+1 for me as well.

So have we finalized on the meeting time?

Thanks,
- Stephen


On Mon, Nov 11, 2013 at 6:56 AM, Kyle Mestery (kmestery)
 wrote:
>
> On Nov 8, 2013, at 12:01 AM, Brian Haley  wrote:
>
>> On 11/08/2013 11:21 AM, Collins, Sean (Contractor) wrote:
>>> How about scheduling an IRC meeting in close proximity to the other
>>> Neutron meetings on Mondays?
>>>
>>> * 20:00 to 21:00 UTC, before the Neutron meeting
>>
>> +0
>>
>>> OR
>>>
>>> * 23:00 UTC - after the distributed virtual router meeting?
>>
>> -1
>>
>> I'd prefer a different day altogether since three meetings in a row would be 
>> tough, but that's just my opinion…
>>
> +1 to this.
>
>> -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 mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] IPv6 sub-team?

[Collins, Sean (Contractor)]

OK - how about Thursdays, 21:00 UTC?
-- 
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 sub-team?

[Collins, Sean (Contractor)]

On Mon, Nov 11, 2013 at 01:16:43PM -0500, Shixiong Shang wrote:
> +1.
> 
> We have great interest to run OpenStack over IPv6 and would love to be a
> part of the discussion.

Excellent - please see the thread I've made in OpenStack-Dev - we're
tossing out times for the IRC meeting, that works for everyone
interested.


-- 
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 sub-team?

[Shixiong Shang]

Thanks, Sean! I am on east coast, so Monday 20:00 UTC time and Thursday 21:00 
UTC time work great for me. Hopefully we can find a timeslot working for 
everybody!

Shixiong


On Nov 11, 2013, at 1:23 PM, Collins, Sean (Contractor) 
 wrote:

> On Mon, Nov 11, 2013 at 01:16:43PM -0500, Shixiong Shang wrote:
>> +1.
>> 
>> We have great interest to run OpenStack over IPv6 and would love to be a
>> part of the discussion.
> 
> Excellent - please see the thread I've made in OpenStack-Dev - we're
> tossing out times for the IRC meeting, that works for everyone
> interested.
> 
> 
> -- 
> 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 sub-team?

[Veiga, Anthony]

As an IPv6 engineer interesting in helping Neutron get where it could be,
I'd like to join in on this.  I also like the Thursday 21:00 UTC slot.

-Anthony

-Original Message-
From: Shixiong Shang 
Reply-To: "OpenStack Development Mailing List (not for usage questions)"

Date: Tuesday, November 12, 2013 10:01
To: "Collins, Sean (Contractor)" 
Cc: "openstack-dev@lists.openstack.org" 
Subject: Re: [openstack-dev] [Neutron] IPv6 sub-team?

>Thanks, Sean! I am on east coast, so Monday 20:00 UTC time and Thursday
>21:00 UTC time work great for me. Hopefully we can find a timeslot
>working for everybody!
>
>Shixiong
>
>
>On Nov 11, 2013, at 1:23 PM, Collins, Sean (Contractor)
> wrote:
>
>> On Mon, Nov 11, 2013 at 01:16:43PM -0500, Shixiong Shang wrote:
>>> +1.
>>> 
>>> We have great interest to run OpenStack over IPv6 and would love to be
>>>a
>>> part of the discussion.
>> 
>> Excellent - please see the thread I've made in OpenStack-Dev - we're
>> tossing out times for the IRC meeting, that works for everyone
>> interested.
>> 
>> 
>> -- 
>> 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] Two new blueprints

[Shixiong Shang]

Hi, stackers:

Randy Tuttle created two blueprints as an augment to Sean’s proposal to improve 
IPv6 readiness. You can find the details here:

https://blueprints.launchpad.net/neutron/+spec/dnsmasq-bind-into-qrouter-namespace
https://blueprints.launchpad.net/neutron/+spec/allow-multiple-subnets-on-gateway-port

Please let us know whether you have any questions. Thanks!

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

[openstack-dev] [Neutron] [IPv6] Supporting upstream RAs

[Collins, Sean]

I am currently working on a patch that allows upstream RAs and SLAAC
configuration. Currently testing it in devstack - it's based on chunks
of patchset 33 of this review that were skipped when Mark McClain
committed patchset 34.

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

Xu Han and Dazhao - do I have your permission to post a rebased version
of this patch into Gerrit - I have set myself as the author and added
you both as Co-Authors.

-- 
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 IRC meeting

[Collins, Sean]

We will not be meeting tomorrow, May 6th 2014, since the summit
is 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] Privacy extension

[Ian Wells]

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

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

[Martinx - ジェームズ]

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

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

[Veiga, Anthony]

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 - ジェームズ 
mailto:thiagocmarti...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, May 15, 2014 at 14:18
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto: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 
mailto: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 
mailto: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<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<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

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

[Martinx - ジェームズ]

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 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 - ジェームズ 
> 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  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 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

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

[Robert Li (baoli)]

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 - ジェ�`ムズ" 
mailto: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 
mailto: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 - ジェ�`ムズ 
mailto:thiagocmarti...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, May 15, 2014 at 14:18
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto: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 
mailto: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 
mailto: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<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<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<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

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)  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 - ?`"  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  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 - ?` 
>>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>>> 
>>> Date: Thursday, May 15, 2014 at 14:18 
>>> To: "OpenStack Development Mailing List (not for usage questions)" 
>>> 
>>> 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  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  
>>>>> 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] 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

[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

[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

[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

[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

[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

[openstack-dev] [Neutron][IPv6] New Subnet options editable?

[Abishek Subramanian (absubram)]

Hi,

I just wanted to find out if the ipv6_ra_mode and ipv6_address_mode fields
are editable using neutron subnet-update? Or are they meant to be
non-editable
fields like the cidr addresses?

Thanks!

On 2/28/14 10:55 AM, "Abishek Subramanian (absubram)" 
wrote:

>Hi,
>
>I just wanted to find out if anyone had been able to test using Horizon?
>Was everything ok?
>
>Additionally wanted to confirm - the two modes can be updated too yes
>when using neutron subnet-update?
>
>
>Thanks!
>
>On 2/18/14 12:58 PM, "Abishek Subramanian (absubram)" 
>wrote:
>
>>Hi shshang, all,
>>
>>I have some preliminary Horizon diffs available and if anyone
>>would be kind enough to patch them and try to test the
>>functionality, I'd really appreciate it.
>>I know I'm able to create subnets successfully with
>>the two modes but if there's anything else you'd like
>>to test or have any other user experience comments,
>>please feel free to let me know.
>>
>>The diffs are at -  https://review.openstack.org/74453
>>
>>Thanks!!
>>
>


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

Re: [openstack-dev] [Neutron][IPv6] IRC meeting today?

[Collins, Sean]

It starts at 10AM EST, due to daylight savings. See you in a couple minutes

Sean M. Collins

From: Shixiong Shang [sparkofwisdom.cl...@gmail.com]
Sent: Tuesday, March 11, 2014 9:15 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Neutron][IPv6] IRC meeting today?

Do we have IRC meeting today? Didn’t see anybody in the chat room…..:(

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] [Neutron][IPv6] Prefix delegation - API Attributes

[Collins, Sean]

Hi,

Anthony Veiga and I did a small bit of whiteboarding this morning to
sketch out what a prefix delegation would look like in the Neutron API.

https://wiki.openstack.org/wiki/Neutron/IPv6/PrefixDelegation

-- 
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] Neutron Routers and LLAs

[Collins, Sean]

During the review[0] of the patch that only allows RAs from known
addresses, Robert Li brought up a bug in Neutron, where a
IPv6 Subnet could be created, with a link local address for the gateway,
that would fail to create the Neutron router because the IP address that
the router's port would be assigned, was a link local
address that was not on the subnet. 

This may or may have been run before force_gateway_on_subnet flag was
introduced. Robert - if you can give us what version of Neutron you were
running that would be helpful.

Here's the full text of what Robert posted in the review, which shows
the bug, which was later filed[1].

>> This is what I've tried, creating a subnet with a LLA gateway address: 
 
>> neutron subnet-create --ip-version 6 --name myipv6sub --gateway fe80::2001:1 
>> mynet :::/64
>>
>> Created a new subnet: 
>> +--++
>> | Field | Value |
>> +--++
>> | allocation_pools | {"start": ":::1", "end": 
>> "::::::fffe"} | | cidr | :::/64 | | 
>> dns_nameservers | | | enable_dhcp | True | | gateway_ip | fe80::2001:1 | | 
>> host_routes | | | id | a1513aa7-fb19-4b87-9ce6-25fd238ce2fb | | ip_version | 
>> 6 | | name | myipv6sub | | network_id | 9c25c905-da45-4f97-b394-7299ec586cff 
>> | | tenant_id | fa96d90f267b4a93a5198c46fc13abd9 |
>> +--++
>> 
>> openstack@devstack-16:~/devstack$ neutron router-list

>> +--+-+-+
>>  
>> | id | name | external_gateway_info
>> | 
>> +--+-+-+
>>  
>> | 7cf084b4-fafd-4da2-9b15-0d25a3e27e67 | router1 | {"network_id": 
>> "02673c3c-35c3-40a9-a5c2-9e5c093aca48", "enable_snat": true} 
>> | 
>> +--+-+-+
>>
>> openstack@devstack-16:~/devstack$ neutron router-interface-add 
>> 7cf084b4-fafd-4da2-9b15-0d25a3e27e67 myipv6sub
>>
>> 400-{u'NeutronError': {u'message': u'Invalid input for operation: IP address 
>> fe80::2001:1 is not a valid IP for the defined subnet.', u'type': 
>> u'InvalidInput', u'detail': u''}}
>>

During last week's meeting, we had a bit of confusion near the end of the
meeting[2] about the following bug, and the fix[3].

If I am not mistaken - the fix is so that when you create a v6 Subnet
with a link local address, then create a Neutron router to serve as the
gateway for that subnet - the operation will successfully complete and a
router will be created.

We may need to take a look at the code that create a router - to ensure
that only one gateway port is created, and that the link local address
from the subnet's 'gateway' attribute is used as the address.

This is at least my understanding of the problem as it stands today -
and that this bug and fix does not involve any external gateways or
physical devices that Neutron does not control - this is exclusively
about Neutron routers.


[0]: https://review.openstack.org/#/c/72252/

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

[2]: 
http://eavesdrop.openstack.org/meetings/neutron_ipv6/2014/neutron_ipv6.2014-03-18-14.02.log.html

[3]: https://review.openstack.org/#/c/76125/


-- 
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] Agenda for today's meeting

[Collins, Sean]

Hi,

Agenda for today's meeting is pretty light - if you have something you'd
like to discuss please add it to the wiki page

https://wiki.openstack.org/wiki/Meetings/Neutron-IPv6-Subteam#Agenda_for_Dec_19_2013

I would also ask that when we conduct the meeting - we stick to the
agenda that has been posted, and hold any other discussions until the
open discussion period. The quicker we get through the agenda, the more
time we have at the end for open discussion.

See you all soon!

-- 
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 & DHCP options for dnsmasq

[Sean M. Collins]

Hi,

Looking at the code for the linux DHCP agent, there's a comment
about trying to figure out how to indicate other options (ra-only,
slaac, ra-nameservers, and ra-stateless).

https://github.com/openstack/neutron/blob/master/neutron/agent/linux/dhcp.py#L330

I decided to take a crack at creating a blueprint, as well as some code.

https://blueprints.launchpad.net/neutron/+spec/dnsmasq-mode-keyword

I don't know if adding the "dhcp_mode" attribute to Subnets should be
considered an API extension (and the code should be converted to an API
extension) or if we're simply specifying behavior that was originally undefined.

The motivation is to help Neutron work with IPv6 - which is a must-have
for Comcast.

-- 
Sean M. Collins


pgpQJV_mcuSwE.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][IPv6] Planning for IPv6 Features

[Collins, Sean (Contractor)]

Moving this from the Gerrit review about change #58186 [1], to the
mailing list for discussion.

Let's start making some blueprints under the ipv6-feature-parity
blueprint[2]. I've already registered a blueprint for the work
that I've been doing, to get provider networking with V6 running,
which links to the bug reports that I've filed.

Short term, my goal is to get provider networks up and running, 
where instances can get RA's from an upstream router outside of
OpenStack and configure themselves.

Medium term, we want to make dnsmasq configuration more
flexible[3], which Dazhao Yu and I are working on.

More long term, I'd like to make it so that if there is an upstream
router doing RA's - Neutron should send a PD automatically on network
creation, and populate a subnet from the response given by the upstream
router.

[1] https://review.openstack.org/#/c/58186/
[2] https://blueprints.launchpad.net/neutron/+spec/ipv6-feature-parity
[3] https://blueprints.launchpad.net/neutron/+spec/dnsmasq-mode-keyword

On Wed, Nov 27, 2013 at 01:02:29PM -0500, Shixiong Shang wrote:
> Hi, Sean:
> 
> I agree with your suggestion. Just read these two changes and they are in 
> good shape. Don’t want to re-invent the wheel.
> 
> Being said, there are still a few outstanding issues. We plan to modify the 
> current submission to bridge the rest of the gaps. However, before we do 
> that, we would like to understand what has been done already and what other 
> efforts are going on, so we will not duplicate the efforts.
> 
> Thoughts? Comments?
> 
> Thanks!
> 
> Shixiong
> 
> 
> 
> 
> 
> 
> On Nov 27, 2013, at 10:17 AM, Sean M. Collins (Code Review) 
>  wrote:
> 
> > Sean M. Collins has posted comments on this change.
> > 
> > Change subject: Adds IPv6 SLAAC Support to Neutron
> > ..
> > 
> > 
> > Patch Set 2: I would prefer that you didn't merge this
> > 
> > It may be worth rebasing your change on top of the following changes - 
> > that'll at least reduce size of the patch and de-duplicate effort.
> > 
> > https://review.openstack.org/#/c/53028/
> > 
> > https://review.openstack.org/#/c/56184/
> > 
> > --
> > To view, visit https://review.openstack.org/58186
> > To unsubscribe, visit https://review.openstack.org/settings
> > 
> > Gerrit-MessageType: comment
> > Gerrit-Change-Id: Ieb9b76fa106a9228d9d68e25e8d5c0152336d9b7
> > Gerrit-PatchSet: 2
> > Gerrit-Project: openstack/neutron
> > Gerrit-Branch: master
> > Gerrit-Owner: Shixiong Shang 
> > Gerrit-Reviewer: Brian Haley 
> > Gerrit-Reviewer: Dazhao Yu 
> > Gerrit-Reviewer: Jenkins
> > Gerrit-Reviewer: Kyle Mestery 
> > Gerrit-Reviewer: Paul Michali 
> > Gerrit-Reviewer: Sean M. Collins 
> > Gerrit-Reviewer: Shixiong Shang 
> > Gerrit-Reviewer: Yang Yu 
> 

-- 
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] Supporting upstream RAs

[Martinx - ジェームズ]

Awesome! I have a perfect lab to evaluate it...:-)

Just a curiosity, it will work with ML2 and Flat Network (dual-stacked with
IPv4)? I would like to try to fit this into a running lab environment, if
possible...

I mean, currently, I have a lab with Flat Network topology (Havana without
ML2), my lab network was created with:

---
neutron net-create --tenant-id $ADMIN_TENTANT_ID sharednet1 --shared
--provider:network_type flat --provider:physical_network physnet1

neutron subnet-create --ip-version 4 --tenant-id $ADMIN_TENANT_ID
sharednet1 10.33.14.0/24 --dns_nameservers list=true 8.8.8.8 8.8.4.4
---

Where physnet1 is a "bridge_mappings = physnet1:br-eth0" pointing to my OVS
bridge "br-eth0". IPv4 router 10.33.14.1 is upstream (provider /
external)...

Reference: https://gist.github.com/tmartinx/7019826

So, I'm wondering here, at my IPv4 router 10.33.14.1 (gateway of sharednet1
10.33.14.0/24 network), I already have a up and running RA daemon
(radvd.conf) working in a dual-stacked environment BUT, currently, of
course, the OpenStack Instances only gets an IPv4 from 10.33.14.0/24 subnet
(and from dhcp-agent from network+controller node).

Anyway, I would like to try this "upstream RAs and SLAAC", like this:

---
neutron subnet-create --ip-version 6 --ipv6_ra_mode slaac
--ipv6_address_mode slaac --tenant-id $ADMIN_TENANT_ID sharednet1
2001:db8:1:1::/64
---

It works that way or, am I thinking it the wrong way?!

Also, my radvd.conf provides RDNSS/DNSSL and, my Ubuntu instances will have
the pacakge `rdnssd` installed, to deal with the resolv.conf properly.

Cheers!
Thiago


On 7 April 2014 16:24, Collins, Sean wrote:

> I am currently working on a patch that allows upstream RAs and SLAAC
> configuration. Currently testing it in devstack - it's based on chunks
> of patchset 33 of this review that were skipped when Mark McClain
> committed patchset 34.
>
> https://review.openstack.org/#/c/56184/
>
> Xu Han and Dazhao - do I have your permission to post a rebased version
> of this patch into Gerrit - I have set myself as the author and added
> you both as Co-Authors.
>
> --
> 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] Supporting upstream RAs

[Collins, Sean]

Hi Martin,

I previously posted to the mailing list with some information about our
IPv6 lab environment and devstack setup. 

http://lists.openstack.org/pipermail/openstack-dev/2014-February/026589.html

Keep in mind that code differs from what was eventually merged in
upstream, so I would ask for your patience while I rebase some patches
and submit them for review, to work with the two new IPv6 attributes.

Please join us on the IRC channel tomorrow, if you are available.

https://wiki.openstack.org/wiki/Meetings/Neutron-IPv6-Subteam

-- 
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] Supporting upstream RAs

[Martinx - ジェームズ]

Okay Collins! Got it... I remember that e-mail from Feb...
I understand it, no rush...   ^_^
Chat tomorrow, tks!

On 7 April 2014 17:35, Collins, Sean wrote:

> Hi Martin,
>
> I previously posted to the mailing list with some information about our
> IPv6 lab environment and devstack setup.
>
>
> http://lists.openstack.org/pipermail/openstack-dev/2014-February/026589.html
>
> Keep in mind that code differs from what was eventually merged in
> upstream, so I would ask for your patience while I rebase some patches
> and submit them for review, to work with the two new IPv6 attributes.
>
> Please join us on the IRC channel tomorrow, if you are available.
>
> https://wiki.openstack.org/wiki/Meetings/Neutron-IPv6-Subteam
>
> --
> 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] Supporting upstream RAs

[Da Zhao Y Yu]

Hi Sean,

That's OK for me, thanks for your work.


Thanks & Best Regards
Yu Da Zhao(于大钊)
--
Cloud Solutions & OpenStack Development
China Systems & Technology Laboratory in Beijing
Email: d...@cn.ibm.com
Tel:   (86)10-82450677
--
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] [IPv6] Supporting upstream RAs

[Xuhan Peng]

Sean,

Sure. Thanks for fixing this.

Xuhan


On Tue, Apr 8, 2014 at 3:42 PM, Da Zhao Y Yu  wrote:

> Hi Sean,
>
> That's OK for me, thanks for your work.
>
>
> Thanks & Best Regards
> Yu Da Zhao(于大钊)
> --
> Cloud Solutions & OpenStack Development
> China Systems & Technology Laboratory in Beijing
> Email: d...@cn.ibm.com
> Tel:   (86)10-82450677
> --
> ___
> 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] Agenda for April 15th

[Collins, Sean]

Feel free to update the agenda with items for discussion

https://wiki.openstack.org/wiki/Meetings/Neutron-IPv6-Subteam#Agenda_for_April_15th

--
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] Design Summit Session Agenda

[Collins, Sean]

All,

We have a couple IPv6 design summit sessions that have been registered,
and at least one of them is in a pre-approved state:

http://summit.openstack.org/cfp/details/21

We'll have at least 40 minutes to discuss a roadmap for IPv6 in the
coming Juno cycle.

I have created an etherpad, and would like everyone to start adding
items to the agenda, so we can ensure that we can cover as much ground
as possible.

https://etherpad.openstack.org/p/neutron-ipv6-atlanta-summit

-- 
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] Agenda for tomorrow's meeting

[Collins, Sean]

You know the drill - fill in anything you wish to discuss.

https://wiki.openstack.org/wiki/Meetings/Neutron-IPv6-Subteam#Agenda_for_April_21st

-- 
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] Cannot make it today

[Shixiong Shang]

Hi, guys:

For two weeks in the row, I have customer meeting at 10am EDT, which conflicts 
with our weekly Neutron IPv6 call. I hope this meeting schedule won’t be 
permanent…Will try my best to avoid it. 

Sorry for the absence. :(

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 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 mailto:pengxu...@gmail.com>>
Reply-To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, November 6, 2014 at 4:18 PM
To: OpenStack List 
mailto: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 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

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  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  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"  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] 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] 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" 
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

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

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" 
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

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

[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" 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 agen

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  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"  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 an

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

[Martinx - ジェームズ]

Sounds impressive!   :-D


On 1 September 2014 23:52, Xu Han Peng  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"  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
> norma

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  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"  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

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

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

Re: [openstack-dev] [Neutron][IPv6] New Subnet options editable?

[Xuhan Peng]

Abishek,

The two attributes are editable if you look at Sean's patch
https://review.openstack.org/#/c/52983/27/neutron/api/v2/attributes.py. The
"allow_put" is set to be "True" for these two attributes.

Xuhan

On Sat, Mar 1, 2014 at 2:26 AM, Abishek Subramanian (absubram) <
absub...@cisco.com> wrote:

> Hi,
>
> I just wanted to find out if the ipv6_ra_mode and ipv6_address_mode fields
> are editable using neutron subnet-update? Or are they meant to be
> non-editable
> fields like the cidr addresses?
>
> Thanks!
>
> On 2/28/14 10:55 AM, "Abishek Subramanian (absubram)" 
> wrote:
>
> >Hi,
> >
> >I just wanted to find out if anyone had been able to test using Horizon?
> >Was everything ok?
> >
> >Additionally wanted to confirm - the two modes can be updated too yes
> >when using neutron subnet-update?
> >
> >
> >Thanks!
> >
> >On 2/18/14 12:58 PM, "Abishek Subramanian (absubram)"  >
> >wrote:
> >
> >>Hi shshang, all,
> >>
> >>I have some preliminary Horizon diffs available and if anyone
> >>would be kind enough to patch them and try to test the
> >>functionality, I'd really appreciate it.
> >>I know I'm able to create subnets successfully with
> >>the two modes but if there's anything else you'd like
> >>to test or have any other user experience comments,
> >>please feel free to let me know.
> >>
> >>The diffs are at -  https://review.openstack.org/74453
> >>
> >>Thanks!!
> >>
> >
>
>
> ___
> 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 Subnet options editable?

[Collins, Sean]

On Mon, Mar 03, 2014 at 10:51:59AM +0800, Xuhan Peng wrote:
> Abishek,
> 
> The two attributes are editable if you look at Sean's patch
> https://review.openstack.org/#/c/52983/27/neutron/api/v2/attributes.py. The
> "allow_put" is set to be "True" for these two attributes.
> 
> Xuhan

+1 - the attributes can be updated after creation. We may need to
examine our patches to make sure that dnsmasq is restarted correctly
when these attributes are updated.

-- 
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 Routers and LLAs

[Robert Li (baoli)]

Hi Sean,

Unless I have missed something, this is my thinking:
  -- I understand that the goal is to allow RAs from designated sources
only.
  -- initially, xuhanp posted a diff for
https://review.openstack.org/#/c/72252. And my comment was that subnet
that was created with gateway ip not on the same subnet can't be added
into the neutron router.
  -- as a result, https://review.openstack.org/#/c/76125/ was posted to
address that issue. With that diff, LLA would be allowed. But a
consequence of that is a gateway port would end up having two LLAs: one
that is automatically generated, the other from the subnet gateway IP.
  -- with xuhanp's new diff for https://review.openstack.org/#/c/72252, if
openstack native RA is enabled, then the automatically generated LLA will
be used; and if it's not enabled, it will use the external gateway's LLA.
And the diff seems to indicate this LLA comes from the subnet's gateway
IP.
  -- Therefore, the change of https://review.openstack.org/#/c/76125/
seems to be able to add the gateway IP as an external gateway.
  -- Thus, my question is: should such a subnet be allowed to add in a
router? And if it should, what would the semantics be? If not, proper
error should be provided to the user. I'm also trying to figure out the
reason that such a subnet needs to be created in neutron (other than
creating L2 ports for VMs).

-- Another thought is that if the RA is coming from the provider net, then
the provider net should have installed mechanisms to prevent rogue RAs
from entering the network. There are a few RFCs that address the rogue RA
issue. 

see inline as well.

I hope that I didn't confuse you guys.

Thanks,
Robert


On 3/25/14 2:18 PM, "Collins, Sean" 
wrote:

>During the review[0] of the patch that only allows RAs from known
>addresses, Robert Li brought up a bug in Neutron, where a
>IPv6 Subnet could be created, with a link local address for the gateway,
>that would fail to create the Neutron router because the IP address that
>the router's port would be assigned, was a link local
>address that was not on the subnet.
>
>This may or may have been run before force_gateway_on_subnet flag was
>introduced. Robert - if you can give us what version of Neutron you were
>running that would be helpful.

[Robert] I'm using the latest


>
>Here's the full text of what Robert posted in the review, which shows
>the bug, which was later filed[1].
>
>>> This is what I've tried, creating a subnet with a LLA gateway address:
> 
>>> neutron subnet-create --ip-version 6 --name myipv6sub --gateway
>>>fe80::2001:1 mynet :::/64
>>>
>>> Created a new subnet:
>>> 
>>>+--+
>>>+
>>> | Field | Value |
>>> 
>>>+--+
>>>+
>>> | allocation_pools | {"start": ":::1", "end":
>>>"::::::fffe"} | | cidr | :::/64 | |
>>>dns_nameservers | | | enable_dhcp | True | | gateway_ip | fe80::2001:1
>>>| | host_routes | | | id | a1513aa7-fb19-4b87-9ce6-25fd238ce2fb | |
>>>ip_version | 6 | | name | myipv6sub | | network_id |
>>>9c25c905-da45-4f97-b394-7299ec586cff | | tenant_id |
>>>fa96d90f267b4a93a5198c46fc13abd9 |
>>> 
>>>+--+
>>>+
>>> 
>>> openstack@devstack-16:~/devstack$ neutron router-list
>
>>> 
>>>+--+-+--
>>>---+
>>> | id | name | external_gateway_info
>>> | 
>>>+--+-+--
>>>---+
>>> | 7cf084b4-fafd-4da2-9b15-0d25a3e27e67 | router1 | {"network_id":
>>>"02673c3c-35c3-40a9-a5c2-9e5c093aca48", "enable_snat": true}
>>> | 
>>> 
>>>+--+-+--
>>>---+
>>>
>>> openstack@devstack-16:~/devstack$ neutron router-interface-add
>>>7cf084b4-fafd-4da2-9b15-0d25a3e27e67 myipv6sub
>>>
>>> 400-{u'NeutronError': {u'message': u'Invalid input for operation: IP
>>>address fe80::2001:1 is not a valid IP for the defined subnet.',
>>>u'type': u'InvalidInput', u'detail': u''}}
>>>
>
>During last week's meeting, we had a bit of confusion near the end of the
>meeting[2] about the following bug, and the fix[3].
>
>If I am not mistaken - the fix is so that when you create a v6 Subnet
>with a link local address, then create a Neutron router to serve as the
>gateway for that subnet - the operation will successfully complete and a
>router will be created.
>
>We may need to take a look at the code that create a router - to ensure
>that only one gateway port is created, and that the link local address
>from the subnet's 'gateway' attribute is used as the address.

[Robert] We are discussing what's going to happen whe

[openstack-dev] [Neutron][IPv6] Agenda for the meeting today

[Collins, Sean]

The agenda for today is pretty light - if there is anything that people
would like to discuss, please feel free to add.

https://wiki.openstack.org/wiki/Meetings/Neutron-IPv6-Subteam#Agenda_for_Dec_12._2013

-- 
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] Agenda for today's meeting

[Collins, Sean]

Minutes from the meeting:

http://eavesdrop.openstack.org/meetings/neutron_ipv6/2013/neutron_ipv6.2013-12-19-21.00.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] [Neutron][IPv6] No IRC Meeting this week

[Collins, Sean]

See you all next week!

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