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
on this since you can only have one gateway per subnet.
On 08/27/2014 10:01 PM, Veiga, Anthony wrote:
What I saw is that GARP is sent to the gateway port and also
Using the quota system would be a nice option to have.
Can you clarify what you mean by cumulative bandwidth for the tenant? It would
be possible to rate limit at the tenant router, but having a cumulative limit
enforced inside of a tenant would be difficult.
On Wed, Sep 10, 2014 at 1:03 AM,
From: Kyle Mestery mest...@siliconloons.com
Reply-To: OpenStack Development Mailing List (not for usage questions)
Date: Tuesday, December 10, 2013 10:48
To: OpenStack Development Mailing List (not for usage questions)
Keep in mind that this approach is a direct departure from the IPv4 world.
Note that I'm not wholly against that, however there's something to keep in
Any kind of stack-agnostic interactions in Neutron will have to become stack
aware or have a translator to tell if they need to interact
-- (rebroadcast to dev community from prior unicast discussion) --
Sorry if the description is misleading. Didn't want a large title, and hoped
that the description would provide those additional details to clarify the real
goal of what's included and what's not included.
An openstack deployment with an external DHCP server is definetely a possible
scenario; I don't think it can be implemented out-of-the-box with the
components provided by the core openstack services, but it should be doable and
a possibly even a requirement for deployments which integrate
I vote address them (ipv6_). There's no guarantee of forward
compatibility with a new protocol and this way it can't be confused with a
(non-existant) selection method for IPv4, either. Also, future updates of
other protocols would require a new attribute and break the API less.
During last week's IRC meeting, we ran into a question about validating
the configuration options for ipv6_address_mode and ipv6_ra_mode for
IPv6 networks. This brought up a few issues, but after mulling it over for
a while I think it breaks down into 2 distinct questions.
It is very nice to watch the OpenStack evolution in IPv6! Great job guys!!
I have another idea:
Floating IP for IPv6, or just Floating IPv6
With IPv4, as we know, OpenStack have a feature called Floating IP, which is
basically a 1-to-1 NAT rule (within tenant's
This would break IPv6. The gateway address, according to RFC 4861 Section
4.2 regarding Router Advertisements: Source Address MUST be the link-local
address assigned to the interface from which this message is sent. This means
that if you configure a subnet with a Globally Unique Address
On Thu, 2014-03-06 at 15:32 +, Jorge Miramontes wrote:
I'd like to gauge everyone's interest in a possible mini-summit for
Neturon LBaaS. If enough people are interested I'd be happy to try and
set something up. The Designate team just had a productive mini-summit
in Austin, TX and it was
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.
From: Shixiong Shang sparkofwisdom.cl...@gmail.com
Reply-To: OpenStack Development Mailing List (not for usage
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
+1 to this. It would be great to read the compiled spec and have it be
Thank you for the update, Kyle.
I was sceptical about this move at first but hopefully I was wrong. The specs
repository indeed eases a lot of the work from a submitter and reviewer point
On Wed, 2014-04-09 at 00:02 +0100, Salvatore Orlando wrote:
Auditing has been discussed for the firewall extension.
However, it is reasonable to expect some form of auditing for security
group rules as well.
To the best of my knowledge there has never been an explicit decision
The only issue I would see with the pod is that not all of us are ATCs, so we
may or may not have access to that area (I am open to correction on that point
- in fact I hope someone does ;) )
I’ll second this. I have an interest in attending and assisting here, but I
don’t have ATC
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
This is a discussion that warrants a broader audience, as others are likely to
have a very similar need. It would be good to get something like this
documented, and perhaps bolted on to the operators’ guide or somewhere
NTT-docomo and VTJ developed
On 10/3/14, 14:58 , Henry Gessau ges...@cisco.com wrote:
There are some fixes for IPv6 bugs that unfortunately missed the RC1 cut.
These bugs are quite important for IPv6 users and therefore I would like
lobby for getting them into a possible RC2 of Neutron Juno.
These are low-risk fixes that
I’ll +1 this. I think this is going to be relevant to quite a few things,
including NFV and routing (if you want to establish an L2 neighbor for ISIS…).
This seems like a useful feature.
Maruti's talk is, in fact, so interesting that we should probably get together
and talk about
On Feb 6, 2015, at 8:17 , Jeremy Stanley fu...@yuggoth.org wrote:
On 2015-02-06 12:11:40 +0100 (+0100), Marc Koderer wrote:
Therefore I uploaded one of them (Session Border Controller) to
the Gerrit system into the sandbox repo:
As a telco operator, who is active in the WG, I am absolutely an interested
party for QoS. I’d be willing to hop between the two of them if absolutely
necessary (it’s IRC, after all) but would prefer they not overlap if possible.
On Apr 15, 2015, at 6:39 , Miguel
On Apr 15, 2015, at 10:00 , Miguel Angel Ajo Pelayo mangel...@redhat.com
1) #openstack-meeting-2 doesn’t exist (-alt is it)
2) and not only that we’re colliding the TWG meeting,
but all the meeting rooms starting at UTC 14:30 are busy.
While not preferable, I don’t mind
On Apr 6, 2015, at 11:56 , Miguel Ángel Ajo
I’d like to co-organized a QoS weekly meeting with Sean M. Collins,
In the last few years, the interest for QoS support has increased, Sean has
this effort  and we believe we
suggestion for starting with how to define things in the API first.
On 7/4/2015, at 15:07, Veiga, Anthony
On Apr 6, 2015, at 11:56 , Miguel Ángel Ajo
On Apr 7, 2015, at 11:05 , Veiga, Anthony
On Apr 7, 2015, at 10:50 , Miguel Angel Ajo Pelayo
Hi Anthony, nice to hear about it! :)
Is the implementation
Mail list logo