: Jay Pipes [jaypi...@gmail.com]
Sent: Tuesday, February 23, 2016 10:51 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron] - DVR L3 data plane performance results
and scenarios
On 02/22/2016 10:25 PM, Wuhongning wrote:
> Hi all,
>
> There is also a control pla
Hi all,
There is also a control plane performance issue when we try to catch on the
spec of typical AWS limit (200 subnets per router). When a router with 200
subnets is scheduled on a new host, a 30s delay is watched when all data plane
setup is finished.
___
List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] OVS flow modification performance
At Thu, 21 Jan 2016 02:59:16 +,
Wuhongning wrote:
>
> I don't think 400 flows can show the difference , do you have setup any
> tunnel peer?
>
> In fact we may set the ne
I don't think 400 flows can show the difference , do you have setup any tunnel
peer?
In fact we may set the network type as "vxlan", then make a fake MD simulate
sending l2pop fdb add messages, to push ten's of thousands flows into the
testing ovs agent.
___
networks, i think it is a good idea, since
L2population already propagate this configuration to OVS-Agent.
One comment for VLAN network, since DVR also support in VLAN network and
L2population is not necessary in it, what is your consideration in this case?
At 2015-11-29 14:15:11, "Wuhon
comment for VLAN network, since DVR also support in VLAN network and
L2population is not necessary in it, what is your consideration in this case?
At 2015-11-29 14:15:11, "Wuhongning" wrote:
>Is it a good idea to add a configuration item for dvr, to disable any arp
>entry
Is it a good idea to add a configuration item for dvr, to disable any arp entry
processing, and reuse arp response from L2population?
When no static arp entry is found in qrouter namespace, it would cause a temp
arp request, then it reached the br-tun, and replied by the OVS flow table.
In a pu
Hi Neil,
@Neil, could you please also add VIF_TYPE_VHOSTUSER in your spec (as I
commented on it)? There has been active VHOSTUSER discuss in JUNO nova BP, and
it's the same usefulness as VIF_TYPE_TAP.
Best Regards
Wu
From: Neil Jerram [neil.jer...@metasw
Is the trunk port use case like the super vlan?
Also there is another typical use case maybe not covered: extended flat
network. Traffic on the port carries multiple vlans, but these vlans are not
necessarily managed by neutron-network, so can not be classified to trunk port.
And they don't nee
Hi keshava,
Thanks for interested in Cascading. Here are some very simple explanation:
Basically Datacenter is not in the 2-level tree of cascading. We use term "POD"
to represent a cascaded child openstack (same meaning of your term Zone?).
There may be single or multiple PODs in one Datacente
+1, the hint should be persistent as other server instance metadata.
From: Alex Xu [sou...@gmail.com]
Sent: Wednesday, October 29, 2014 9:11 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Nova] Add scheduler-hints
Hi,
In the Juno cycle there is proposal of ModularL2Agent [1,2], which is very
useful to develop agent for new backend with much less redundant code. Without
that, we have to either fork a new agent by copying large amount of existing
l2agent code, or patch existing l2agent. However in the K pa
Internal vlan is not necessarily obstacle to vlan trunk, no qinq support in ovs
is the key factor.
If ovs suppport qinq, vlan trunk could be treated as a generalized "flat" type
network, which let packets from tenant VM go to the wire unmodified, if packets
carry no tag, then it's the same as c
It would satisfy everyone if horizon support all APIs, either in tree or in the
lab, but at the perquisite that we have enough resource for horizon.
Else for the limitation of resource, we have to sort by the priority, then
should we focus on APIs being baked in the incubator first?
___
anything, why even store things there in the first place? Since everything will
require custom clients, the port ID can just be used as a foreign key to
another API instead and the ML2 objects don't need to change at all.
On Tue, Aug 19, 2014 at 6:11 PM, Wuhongning
mailto:wuhongn...@hu
+1 to service plugin
It's better to strip service related extensions from ML2 core plugin as
possible as we can, and put them in separate service plugin. Not only QOS, but
also SG or possible other extensions. For the "binding" issue, vif-detail dict
might be used for foreign key association.
laces.
From: Sridar Kandaswamy (skandasw) [skand...@cisco.com]
Sent: Thursday, August 14, 2014 10:12 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] Simple proposal for stabilizing new
features in-tree
Hi Wuhongning:
Yes u are correct – th
FWaas can't seamlessly work with DVR yet. A BP [1] has been submitted, but it
can only handle NS traffic, leaving W-E untouched. If we implement the WE
firewall in DVR, the iptable might be applied at a per port basis, so there are
some overlapping with SG (Can we image a packet run into iptable
nstack.org
Subject: Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way
forward
On 08/12/2014 06:46 PM, Wuhongning wrote:
> I couldn't have been at the IRC meeting for the time difference, are
> there any conclusion for this topic, or is it still open?
I, the PTL, some core
hi GBPer,
I couldn't have been at the IRC meeting for the time difference, are there any
conclusion for this topic, or is it still open?
I've tried to collect main concerns from previous posts (if something is lost
or mistaken, just let me know):
Concern 1: GBP is too heavy to be merged into N
Does it make sense to move all advanced extension out of ML2, like security
group, qos...? Then we can just talk about advanced service itself, without
bothering basic neutron object (network/subnet/port)
Traditionally, SG is applied in CN, and FWaas is applied in NN (bound to L3
agent), howeve
Now in L3 API, we can create a router with external gateway, while enable_snat
setting to false.
Now in DVR code, all cenral NS processing is related with snat, so does it
still support NS central gw without snat?
Also, is it possible to separate the scheduling of NS central gateway and
SNAT(or
hi,
It's a very important use case for multiple vswitchs. Now we use a fork version
of ovs-dpdk to support NFV service chaining deployment, however all other
traffic are still in the kernel ovs path, including management and storage
traffic, and it will be very difficult to switch all these tra
From: Carl Baldwin [c...@ecbaldwin.net]
Sent: Monday, June 30, 2014 3:43 AM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] DVR and FWaaS integration
On Mon, Jun 30, 2014 at 3:43 AM, Carl Baldwin
mailto:c...@ecbaldwin.net>> wrote:
In line...
From: Zang MingJie [zealot0...@gmail.com]
Sent: Thursday, June 26, 2014 6:29 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] DVR SNAT shortcut
On Wed, Jun 25, 2014 at 10:29 PM, McCann, Jack wrote:
nt of the DVR on the network node it
will be processed very much like default SNAT traffic is processed in the
current Neutron implementation. Another "interconnect subnet" should not be
needed here and would be overkill.
I hope this helps. Let me know if you have any questions.
C
Hi DVRers,
I didn't see any detail documents or source code on how to deal with routing
packet from DVR node to SNAT gw node. If the routing table see a outside ip, it
should be matched with a default route, so for the next hop, which interface
will it select?
Maybe another standalone "interco
27 matches
Mail list logo
