[openstack-dev] [Neutron][DVR] - No IRC Meeting until 2017

Hi Folks, We will not have another DVR sub-team meeting until 2017, resuming on January 4th, to accommodate those that will be away. Enjoy the break! -Brian __ OpenStack Development Mailing List (not for usage questions)

[openstack-dev] [Neutron][DVR] - No IRC Meeting this week

Hi Folks, We will not have a DVR sub-team meeting this week since neither Swami nor myself will be there to chair it. We will resume our meetings next week on December 14th. If you have any questions please ping us on IRC or send an email to the list. https://wiki.openstack.org/wiki/Meetings

Re: [openstack-dev] [neutron][dvr][fip] router support two external network

[openstack-dev] [neutron][dvr][fip] router support two external network Hi all Currently, neutron model supports one router with one external network, which is used to connect router to outside world. FIP can be allocated from external network which is gateway of a router. One private fixed

Re: [openstack-dev] [neutron][dvr][fip] router support two external network

. Then > map each interface to the relevant network. > > Thanks > > Gary > > > > *From: *huangdenghui > *Reply-To: *OpenStack List > *Date: *Saturday, November 12, 2016 at 10:26 AM > *To: *OpenStack List > *Subject: *[openstack-dev] [neutron][dvr][fip] r

Re: [openstack-dev] [neutron][dvr][fip] router support two external network

:26 AM To: OpenStack List Subject: [openstack-dev] [neutron][dvr][fip] router support two external network Hi all Currently, neutron model supports one router with one external network, which is used to connect router to outside world. FIP can be allocated from external network which is

[openstack-dev] [neutron][dvr][fip] router support two external network

Hi all Currently, neutron model supports one router with one external network, which is used to connect router to outside world. FIP can be allocated from external network which is gateway of a router. One private fixed ip of one port(usually it is a vm port ) can only associate one floating

Re: [openstack-dev] [neutron][dvr][fip] fg device allocated private ip address

On Tue, Aug 16, 2016 at 6:17 PM, huangdenghui wrote: > Hi Carl > Thanks for reply. I was wondering how this works? fg device has one > private ip address, and the interface on upstream router has two ip > address, one is private ip address, and the other one is public ip address, > Can fg dev

Re: [openstack-dev] [neutron][dvr][fip] fg device allocated private ip address

Hi Carl Thanks for reply. I was wondering how this works? fg device has one private ip address, and the interface on upstream router has two ip address, one is private ip address, and the other one is public ip address, Can fg device do arp proxy for this situation? 在 2016-08-03 06:38

Re: [openstack-dev] [neutron][dvr][fip] fg device allocated private ip address

I still have a problem about the fg device with private ip address. In DVR mode, there is a external ip address in fq device, because we need to figure out the default route. If the fg device with a private ip address, how do we figure out the default route in fip namespace? Default route is not

Re: [openstack-dev] [neutron][dvr][fip] fg device allocated private ip address

On Tue, Aug 2, 2016 at 6:15 AM, huangdenghui wrote: > hi john and brain >thanks for your information, if we get patch[1],patch[2] merged,then fg > can allocate private ip address. after that, we need consider floating ip > dataplane, in current dvr implementation, fg is used to reachment test

Re: [openstack-dev] [neutron][dvr][fip] fg device allocated private ip address

On 08/02/2016 08:15 AM, huangdenghui wrote: hi john and brain thanks for your information, if we get patch[1],patch[2] merged,then fg can allocate private ip address. after that, we need consider floating ip dataplane, in current dvr implementation, fg is used to reachment testing for floating

Re: [openstack-dev] [neutron][dvr][fip] fg device allocated private ip address

hi john and brain thanks for your information, if we get patch[1],patch[2] merged,then fg can allocate private ip address. after that, we need consider floating ip dataplane, in current dvr implementation, fg is used to reachment testing for floating ip, now,with subnet types bp,fg has differ

Re: [openstack-dev] [neutron][dvr][fip] fg device allocated private ip address

Yes, as Brian says this will be covered by the follow-up patch to [2] which I¹m currently working on. Thanks for the question. John On 8/1/16, 3:17 PM, "Brian Haley" wrote: >On 07/31/2016 06:27 AM, huangdenghui wrote: >> Hi >>Now we have spec named subnet service types, which provides a >>

Re: [openstack-dev] [neutron][dvr][fip] fg device allocated private ip address

On 07/31/2016 06:27 AM, huangdenghui wrote: Hi Now we have spec named subnet service types, which provides a capability of allowing different port of a network to allocate ip address from different subnet. In current implementation of DVR, fip also is distributed on every compute node, floatin

[openstack-dev] [neutron][dvr][fip] fg device allocated private ip address

Hi Now we have spec named subnet service types, which provides a capability of allowing different port of a network to allocate ip address from different subnet. In current implementation of DVR, fip also is distributed on every compute node, floating ip and fg's ip are both allocated from ex

[openstack-dev] [Neutron][DVR] - No IRC Meeting today

Hi Folks, Sorry for the late notice, but we will not have a DVR sub-team meeting today since neither Swami nor myself will be there to chair it. We will resume our meetings next week on July 20th. If you have any questions please ping us on IRC or send an email to the list. https://wiki.open

[openstack-dev] [Neutron][DVR] - No IRC Meeting this week

Hi Folks, We will not have a DVR sub-team meeting this week since neither Swami nor myself will be there to chair it. We will resume our meetings next week on July 6th. If you have any questions please ping us on IRC or send an email to the list. https://wiki.openstack.org/wiki/Meetings/Neut

Re: [openstack-dev] [neutron][dvr] Wasting so many external network IPs in DVR mode?

On Thu, Jun 2, 2016 at 12:04 AM, zhi wrote: > The reason putting the routers namespaces behind the fip namespace is > saving mac address tables in switches. In Centralized Virtual Router, there > are many "qg" interfaces in the external bridge. Every "qg" interface may > contains one or more

Re: [openstack-dev] [neutron][dvr] Wasting so many external network IPs in DVR mode?

Hi, Carl Thanks for your reply! ;-) I have some ideas about your explanation. Please review it. :-) The reason putting the routers namespaces behind the fip namespace is saving mac address tables in switches. In Centralized Virtual Router, there are many "qg" interfaces in the e

Re: [openstack-dev] [neutron][dvr] Wasting so many external network IPs in DVR mode?

On Wed, Jun 1, 2016 at 9:48 AM, zhi wrote: > hi, all > > I have some questions about north/south traffic in DVR mode. > > As we all know, packets will be sent to instance's default gateway (qr > interface) when an instance want to communicate to the external network. > Next, these packets

[openstack-dev] [neutron][dvr] Wasting so many external network IPs in DVR mode?

hi, all I have some questions about north/south traffic in DVR mode. As we all know, packets will be sent to instance's default gateway (qr interface) when an instance want to communicate to the external network. Next, these packets will be sent from rfp interface(qrouter interface) to t

Re: [openstack-dev] [neutron] dvr with ovs-dpdk.

Hi Sean I'm very interested in this topic, but I missed the discussion during summit. AFAIK, when deploying OVS-dpdk, it seems transparent to DVR. The only thing we need to do is to switch from OVS firewall-driver to OVS-dpdk-firewall-driver. Do you have any outputs about the integration? Is ther

[openstack-dev] [neutron] dvr with ovs-dpdk.

Hi If any of the dvr team are around I would love to Meet with ye to discuss how to make dvr work efficiently when using ovs with the dpdk datapath. Ill be around the Hilton all day and am currently in room 400 but if anyone wants to meetup to Discuss this let me know Regards Seán _

[openstack-dev] [neutron][dvr]Why drop flows like "table=1, priority=3, arp, dl_vlan=1, arp_tpa=192.168.10.1, actions=drop"?

hi, all. I have a small question about flows in br-tun. I find some flows which drop traffic. These flows like this " table=1, n_packets=2, n_bytes=84, idle_age=731, hard_age=65534, priority=3,arp,dl_vlan=1,arp_tpa=192.168.10.1 actions=drop table=1, n_packets=1, n_bytes=42, idle_age=904, pr

Re: [openstack-dev] [neutron][dvr]Why keep SNAT centralized and DNAT distributed?

g [mailto:chang...@unitedstack.com] > Sent: Saturday, March 26, 2016 1:53 PM > To: openstack-dev > Subject: [openstack-dev] [neutron][dvr]Why keep SNAT centralized and DNAT > distributed? > > hi all. > > I have some questions about NAT in DVR. > > In Neutron, we provide t

Re: [openstack-dev] [neutron][dvr]Why keep SNAT centralized and DNAT distributed?

To: openstack-dev Subject: [openstack-dev] [neutron][dvr]Why keep SNAT centralized and DNAT distributed? hi all. I have some questions about NAT in DVR. In Neutron, we provide two NAT types. One is SNAT, we can associate a floating ip to router so that all vms attached this router can

[openstack-dev] [neutron][dvr]Why keep SNAT centralized and DNAT distributed?

hi all. I have some questions about NAT in DVR. In Neutron, we provide two NAT types. One is SNAT, we can associate a floating ip to router so that all vms attached this router can connect external network. The other NAT types is DNAT, we can connect a vm which associated floating i

[openstack-dev] [neutron][dvr]How to get the relationship of veth pair device?

hi, all. In DVR mode, a veth pair devices were generated when I create a floating ip and associate it to a vm. And one of the pair device in fip namespace, the other one in qrouter namespace. How can I get the relationship between the veth pair device? I know the command "ethtool -

Re: [openstack-dev] [neutron][dvr]What does table 9 used for in br-tun?

Friday, March 18, 2016 at 11:33 PM To: openstack-dev mailto:openstack-dev@lists.openstack.org>> Subject: [openstack-dev] [neutron][dvr]What does table 9 used for in br-tun? hi guys. In DVR mode, I have some questions about flows of table 9 in br-tun. I see these flows in br-tun:

Re: [openstack-dev] [neutron][dvr]What does table 9 used for in br-tun?

e questions)" mailto:openstack-dev@lists.openstack.org>> Date: Friday, March 18, 2016 at 11:47 PM To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [neutron][dvr]What does table 9 us

Re: [openstack-dev] [neutron][dvr]What does table 9 used for inbr-tun?

t;; Date: Sat, Mar 19, 2016 12:51 PM To: "OpenStack Development Mailing List (not for usage questions)"; Subject: Re: [openstack-dev] [neutron][dvr]What does table 9 used for inbr-tun? Err… correction. Each host has a unique MAC, not each router. Sorry!

[openstack-dev] [neutron][dvr]What does table 9 used for in br-tun?

hi guys. In DVR mode, I have some questions about flows of table 9 in br-tun. I see these flows in br-tun: cookie=0x9a5f42115762fc76, duration=392186.503s, table=9, n_packets=1, n_bytes=90, idle_age=247, hard_age=65534, priority=1,dl_src=fa:16:3f:64:82:2f actions=output:1 cookie=0x9a5f42

[openstack-dev] [Neutron][DVR] No Meeting tomorrow

Sorry for the late notice, but I need to cancel the DVR meeting for tomorrow the 9th as a few of us have a conflict. We'll resume again next week on the 16th. -Brian __ OpenStack Development Mailing List (not for usage qu

Re: [openstack-dev] [Neutron] - DVR L3 data plane performance results and scenarios

; Shlomo Narkolayev; Eran Gampel > *Subject:* Re: [openstack-dev] [Neutron] - DVR L3 data plane performance > results and scenarios > > > > Hi Swami, > > > > Thanks for the reply, is there any detailed links that describe this that > we can look at? > > > > (O

Re: [openstack-dev] [Neutron] - DVR L3 data plane performance results and scenarios

: 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

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

Re: [openstack-dev] [Neutron] - DVR L3 data plane performance results and scenarios

. From: Vasudevan, Swaminathan (PNB Roseville) [swaminathan.vasude...@hpe.com] Sent: Saturday, February 20, 2016 1:49 AM To: OpenStack Development Mailing List (not for usage questions) Cc: Yuli Stremovsky; Shlomo Narkolayev; Eran Gampel Subject: Re: [openstack-dev] [Neutron] - DVR L3 data plane

Re: [openstack-dev] [Neutron] - DVR L3 data plane performance results and scenarios

Gampel Subject: Re: [openstack-dev] [Neutron] - DVR L3 data plane performance results and scenarios Hi Swami, Thanks for the reply, is there any detailed links that describe this that we can look at? (Of course that having results without the full setup (hardware/ NIC, CPU and threads for OVS and

Re: [openstack-dev] [Neutron] - DVR L3 data plane performance results and scenarios

information. > > > > Thanks > > Swami > > > > *From:* Gal Sagie [mailto:gal.sa...@gmail.com] > *Sent:* Thursday, February 18, 2016 6:06 AM > *To:* OpenStack Development Mailing List (not for usage questions); Eran > Gampel; Shlomo Narkolayev; Yuli Stremovsky > *Subjec

Re: [openstack-dev] [Neutron] - DVR L3 data plane performance results and scenarios

Hi Gal, We do have DVR testing results on 200 nodes for both VXLAN and VLAN configurations. We plan to publish them in performance-docs repository. Thanks Georgy On Thu, Feb 18, 2016 at 6:06 AM, Gal Sagie wrote: > Hello All, > > We have started to test Dragonflow [1] data plane L3 performance

Re: [openstack-dev] [Neutron] - DVR L3 data plane performance results and scenarios

information. Thanks Swami From: Gal Sagie [mailto:gal.sa...@gmail.com] Sent: Thursday, February 18, 2016 6:06 AM To: OpenStack Development Mailing List (not for usage questions); Eran Gampel; Shlomo Narkolayev; Yuli Stremovsky Subject: [openstack-dev] [Neutron] - DVR L3 data plane performance results

[openstack-dev] [Neutron] - DVR L3 data plane performance results and scenarios

Hello All, We have started to test Dragonflow [1] data plane L3 performance and was wondering if there is any results and scenarios published for the current Neutron DVR that we can compare and learn the scenarios to test. We mostly want to validate and understand if our results are accurate and

Re: [openstack-dev] [neutron][dvr]

ti [mailto:sudhakar.gariga...@gmail.com] > *Sent:* Wednesday, January 27, 2016 10:00 PM > *To:* openstack-dev@lists.openstack.org > *Subject:* [openstack-dev][neutron][dvr] > > > > Hi all, > > > > One basic question related to DVR topic '*dvr_update'*. In OV

Re: [openstack-dev] [neutron][dvr]

, January 27, 2016 10:00 PM To: openstack-dev@lists.openstack.org Subject: [openstack-dev][neutron][dvr] Hi all, One basic question related to DVR topic 'dvr_update'. In OVS Neutron agent, I see that the dvr_update topic is being added to the consumer list irrespective of DVR being enab

[openstack-dev] [neutron][dvr]

Hi all, One basic question related to DVR topic '*dvr_update'*. In OVS Neutron agent, I see that the *dvr_update* topic is being added to the consumer list irrespective of DVR being enabled or not. Because of this, even though I have disabled DVR in my environment, I still see the agent subscribe

[openstack-dev] [Neutron][DVR] - No IRC Meeting for the next two weeks.

Hi Folks, We will not be having our DVR sub-team meeting for the next two weeks. Dec 23rd 2015 Dec 30th 2015. We will resume our meeting on "Jan 6th 2016". If you have any questions please ping us in IRC or send an email to the distribution list. https://wiki.openstack.org/wiki/Meetings/Neutro

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

nt: Friday, December 11, 2015 3:12 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [Neutron][DVR] > > > > > > > > On 3 December 2015 at 10:46, Carl Baldwin wrote: > > I was going to bring this up in the meeting thi

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

hanks > > Swami > > *From:* Armando M. [mailto:arma...@gmail.com] > *Sent:* Friday, December 11, 2015 3:12 PM > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [Neutron][DVR] > > > > > > > > On 3 December

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

] Sent: Friday, December 11, 2015 3:12 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][DVR] On 3 December 2015 at 10:46, Carl Baldwin mailto:c...@ecbaldwin.net>> wrote: I was going to bring this up in the meeting this morning b

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

On 3 December 2015 at 10:46, Carl Baldwin wrote: > I was going to bring this up in the meeting this morning but IRC > troubles prevented it. > > After chatting with Armando, I'd like to suggest a few enhancements to > how we're tackling DVR during this cycle. I'm hoping that these > changes help

Re: [openstack-dev] [Neutron] DVR + L3 HA + L2pop - Mapping out the work

, make any necessary redesigns, or revert it. Thanks. Adolfo Duarte -Original Message- From: Assaf Muller [mailto:amul...@redhat.com] Sent: Friday, December 04, 2015 2:46 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Neutron] DVR + L3

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

On 7 December 2015 at 05:41, Ryan Moats wrote: > "Armando M." wrote on 12/04/2015 03:43:29 PM: > > > From: "Armando M." > > To: "OpenStack Development Mailing List (not for usage questions)" > > > > Date: 12/04/2015 03:44 PM &g

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

"Armando M." wrote on 12/04/2015 03:43:29 PM: > From: "Armando M." > To: "OpenStack Development Mailing List (not for usage questions)" > > Date: 12/04/2015 03:44 PM > Subject: Re: [openstack-dev] [Neutron][DVR] > > > On 4 December 201

Re: [openstack-dev] [Neutron] DVR + L3 HA + L2pop - Mapping out the work

can help to get the pending patches to be reviewed, if that would help. Thanks Swami -Original Message- From: Assaf Muller [mailto:amul...@redhat.com] Sent: Friday, December 04, 2015 2:46 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Neutron

Re: [openstack-dev] [Neutron] DVR + L3 HA + L2pop - Mapping out the work

for usage questions) Subject: [openstack-dev] [Neutron] DVR + L3 HA + L2pop - Mapping out the work There's a patch up for review to integrate DVR and L3 HA: https://review.openstack.org/#/c/143169/ Let me outline all of the work that has to happen before that patch would be useful: In orde

[openstack-dev] [Neutron] DVR + L3 HA + L2pop - Mapping out the work

There's a patch up for review to integrate DVR and L3 HA: https://review.openstack.org/#/c/143169/ Let me outline all of the work that has to happen before that patch would be useful: In order for DVR + L3 HA to work in harmony, each feature would have to be stable on its own. DVR has its share o

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

looking like... > > Ryan Moats (regXboi) > > Oleg Bondarev wrote on 12/04/2015 02:44:58 AM: > > > From: Oleg Bondarev > > To: "OpenStack Development Mailing List (not for usage questions)" > > > > Date: 12/04/2015 02:46 AM > > Subject:

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

>> -Original Message- >> From: Carl Baldwin [mailto:c...@ecbaldwin.net] >> Sent: Thursday, December 03, 2015 10:47 AM >> To: OpenStack Development Mailing List >> Subject: [openstack-dev] [Neutron][DVR] >> >> I was going to bring this up in the meeting

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

estions)" > > Date: 12/04/2015 02:46 AM > Subject: Re: [openstack-dev] [Neutron][DVR] > > On Thu, Dec 3, 2015 at 10:06 PM, Vasudevan, Swaminathan (PNB Roseville) < > swaminathan.vasude...@hpe.com> wrote: > Hi Carl, > Sounds reasonable suggestion. > Thanks

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

ay, December 03, 2015 10:47 AM > To: OpenStack Development Mailing List > Subject: [openstack-dev] [Neutron][DVR] > > I was going to bring this up in the meeting this morning but IRC troubles > prevented it. > > After chatting with Armando, I'd like to suggest a few enhancem

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

Hi Carl, Sounds reasonable suggestion. Thanks Swami -Original Message- From: Carl Baldwin [mailto:c...@ecbaldwin.net] Sent: Thursday, December 03, 2015 10:47 AM To: OpenStack Development Mailing List Subject: [openstack-dev] [Neutron][DVR] I was going to bring this up in the meeting

[openstack-dev] [Neutron][DVR]

I was going to bring this up in the meeting this morning but IRC troubles prevented it. After chatting with Armando, I'd like to suggest a few enhancements to how we're tackling DVR during this cycle. I'm hoping that these changes help us to get things done faster and more efficiently. Let me kn

[openstack-dev] Neutron DVR Subteam Meeting Resumes from Nov 4th 2015.

Hi Folks, We would like to resume the Neutron DVR Subteam Meeting starting November 4th 2015. If you are an active technical contributor in openstack and would like to discuss any DVR related items feel free to join the meeting. Here are the meeting details. IRC channel: #openstack-meeting-alt

[openstack-dev] [Neutron] [DVR] easyOVS -- Smart tool to use/debug Neutron/DVR

Hi, One suggestion from my side is checking nova security groups against iptable rules for each vm.Doing this will ensure that there are no unwanted holes in security (for example, accidental messing up of iptable rules). Thanks -Vikas Choudhary __

Re: [openstack-dev] [Neutron] [DVR] easyOVS -- Smart tool to use/debug Neutron/DVR

Hi, It's Interesting! I have three points for you here. a.Support packet tracking which show the path of a packet traveled on the host, even on the source/destination host. b.Given a communication type and packet characteristic to find out the fault point. For example, if you want VM1 talk with VM

[openstack-dev] [Neutron] [DVR] easyOVS -- Smart tool to use/debug Neutron/DVR

Hi , all When using neutron (especially with DVR), I find it difficult to debug problems with lots of ovs rules, complicated iptables rules, network namespaces, routing tables, ... So I create easyOVS

Re: [openstack-dev] [neutron][dvr] DVR L2 agent is removing the br-int OVS flows

I pushed change for that case https://review.openstack.org/215596. On Fri, Aug 21, 2015 at 2:45 PM, Anna Kamyshnikova < akamyshnik...@mirantis.com> wrote: > Hi, Artur! > > Thanks, for bringing this up! I missed that. I push change for that in a > short time. > > On Fri, Aug 21, 2015 at 1:35 PM, K

Re: [openstack-dev] [neutron][dvr] DVR L2 agent is removing the br-int OVS flows

Hi, Artur! Thanks, for bringing this up! I missed that. I push change for that in a short time. On Fri, Aug 21, 2015 at 1:35 PM, Korzeniewski, Artur < artur.korzeniew...@intel.com> wrote: > Hi all, > > After merging the “Graceful ovs-agent restart”[1] (great work BTW!), I’m > seeing in DVR L2 ag

[openstack-dev] [neutron][dvr] DVR L2 agent is removing the br-int OVS flows

Hi all, After merging the "Graceful ovs-agent restart"[1] (great work BTW!), I'm seeing in DVR L2 agent code place where flows on br-int is removed in old style: File /neutron/plugins/ml2/drivers/openvswitch/agent/ovs_dvr_neutron_agent.py 200 def setup_dvr_flows_on_integ_br(self): 201

Re: [openstack-dev] [neutron][dvr][ha] DVR-HA router is not working.

in OVS… Regards, Artur From: Assaf Muller [mailto:amul...@redhat.com] Sent: Wednesday, August 12, 2015 4:09 PM To: OpenStack Development Mailing List (not for usage questions); adolfo.dua...@hp.com Subject: Re: [openstack-dev] [neutron][dvr][ha] DVR-HA router is not working. Adding the author of

Re: [openstack-dev] [neutron][dvr][ha] DVR-HA router is not working.

Adding the author of the patches. This reinforces the need to hold on merging these patches until they have an in-tree integration test. On Tue, Aug 11, 2015 at 4:13 PM, Korzeniewski, Artur < artur.korzeniew...@intel.com> wrote: > Hi, > > I’ve been playing around with DVR-HA patches [1][2], have

[openstack-dev] [neutron][dvr][ha] DVR-HA router is not working.

Hi, I've been playing around with DVR-HA patches [1][2], have them applied on Mondays master branch. The problem is that the dvr-ha router is not working with SNAT and floating ips. My setup: Devstack-34 - all in one (controller, compute, DVR agent, DHCP node) Devstack-35 - compute node and DVR a

Re: [openstack-dev] [neutron][dvr] Removing fip namespace when restarting L3 agent.

tur > > > > *From:* Oleg Bondarev [mailto:obonda...@mirantis.com] > *Sent:* Thursday, August 6, 2015 5:18 PM > > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [neutron][dvr] Removing fip namespace when > restarting L3 agent.

Re: [openstack-dev] [neutron][dvr] Removing fip namespace when restarting L3 agent.

Bug submitted: https://bugs.launchpad.net/neutron/+bug/1482521 Thanks, Artur From: Oleg Bondarev [mailto:obonda...@mirantis.com] Sent: Thursday, August 6, 2015 5:18 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron][dvr] Removing fip

Re: [openstack-dev] [neutron][dvr] Removing fip namespace when restarting L3 agent.

rface inside the fip namespace is not deleted, the VM has full > internet access without any downtime. > > > > Ca we consider it a bug? I guess it is something in startup/full-sync > logic since the log is saying: > > > /opt/openstack/data/neutron/external/pids/8223e12e-8

Re: [openstack-dev] [neutron][dvr] Removing fip namespace when restarting L3 agent.

ternal/pids/8223e12e-837b-49d4-9793-63603fccbc9f.pid And after finishing the sync loop, the fip namespace is deleted… Regards, Artur From: Kevin Benton [mailto:blak...@gmail.com] Sent: Thursday, August 6, 2015 7:40 AM To: OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [neutron][dvr] Removing fip namespace when restarting L3 agent.

Can you try setting the following to False: https://github.com/openstack/neutron/blob/dc0944f2d4e347922054bba679ba7f5d1ae6ffe2/etc/l3_agent.ini#L97 On Wed, Aug 5, 2015 at 3:36 PM, Korzeniewski, Artur < artur.korzeniew...@intel.com> wrote: > Hi all, > > During testing of Neutron upgrades, I have f

Re: [openstack-dev] [neutron][dvr] Removing fip namespace when restarting L3 agent.

: Wednesday, August 05, 2015 12:36 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [neutron][dvr] Removing fip namespace when restarting L3 agent. Hi all, During testing of Neutron upgrades, I have found that restarting the L3 agent in DVR mode is causing

[openstack-dev] [neutron][dvr] Removing fip namespace when restarting L3 agent.

Hi all, During testing of Neutron upgrades, I have found that restarting the L3 agent in DVR mode is causing the VM network downtime for configured floating IP. The lockdown is visible when pinging the VM from external network, 2-3 pings are lost. The responsible place in code is: DVR: destroy fi

Re: [openstack-dev] [Neutron]: DVR Presentation slides from the Vancouver summit

Thanks for the share.. :) From: Vasudevan, Swaminathan (PNB Roseville) [mailto:swaminathan.vasude...@hp.com] Sent: Tuesday, May 26, 2015 11:20 PM To: OpenStack Development Mailing List (openstack-dev@lists.openstack.org) Subject: [openstack-dev] [Neutron]: DVR Presentation slides from the

[openstack-dev] [Neutron]: DVR Presentation slides from the Vancouver summit

Hi Folks, Unfortunately our presentation video is missing from the OpenStack Vancouver summit website. But there was a lot more request for the slides that we presented in the summit. Here is the link to the slides that we presented in the OpenStack Vancouver summit. https://drive.google.com/fil

Re: [openstack-dev] [neutron] DVR and l2_population

Thanks Armando. Another question: Every compute node that hosts instances with floating IPs has an IP from the external network pool. If the SNAT is done by the Network Node what is the reason for the compute node to have an external IP? BR, Itzik On 02/11/2015 08:13 PM, Armando M. wrote: L

Re: [openstack-dev] [neutron] DVR and l2_population

L2pop is a requirement. With the existing agent-based architecture, L2pop is used to update the FDB tables on the compute hosts to make east/west traffic possible whenever a new port is created or existing one is updated. Cheers, Armando On 10 February 2015 at 23:07, Itzik Brown wrote: > Hi, >

[openstack-dev] [Neutron] DVR Slides from Paris Summit

Hi, is there a way to get access to the slides from the DVR session of the Paris summit? Unfortunately the slides in the video are not readable. Speakers were Swaminathan Vasudevan, Jack McCann, Vivekanandan, Narasimhan, Rajeev Grover, Michael Smith. So maybe one of you can post them on slidesha

[openstack-dev] [neutron] dvr l2 agent

Hello, I do not very understand this in dvr l2 agent (here https://wiki.openstack.org/wiki/Neutron/DVR_L2_Agent) " 3 After routing, the DVR router r1 puts the routed frame out of its green subnet interface. This frame is switched by the integration bridge towards the tunnel bridge along w

Re: [openstack-dev] [neutron] dvr l3_snat

Thanks a lot, i really helps after i read times :) 在 2014-11-07 16:08:50，"Armando M." 写道： Not sure if you've seen this one too: https://wiki.openstack.org/wiki/Neutron/DVR Hope this helps! Armando On 7 November 2014 01:50, Li Tianqing wrote: Oh, thanks, i finally find it

Re: [openstack-dev] [neutron] dvr l3_snat

Not sure if you've seen this one too: https://wiki.openstack.org/wiki/Neutron/DVR Hope this helps! Armando On 7 November 2014 01:50, Li Tianqing wrote: > Oh, thanks, i finally find it. > it's all here. > https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr > > Thanks a lot. > > -

Re: [openstack-dev] [neutron] dvr l3_snat

Oh, thanks, i finally find it. it's all here. https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr Thanks a lot. -- Best Li Tianqing At 2014-11-06 20:47:39, "Henry" wrote: Have you read previous posts? This topic had been discussed for a while. Sent from my iPad On 201

Re: [openstack-dev] [neutron] dvr l3_snat

i search in goolge by useing key words neutron dvr l3_snat mailing list, and do not find the thread you said about. Can you give me some urls? Thanks -- Best Li Tianqing At 2014-11-06 20:47:39, "Henry" wrote: Have you read previous posts? This topic had been discussed for a while. S

Re: [openstack-dev] [neutron] dvr l3_snat

Have you read previous posts? This topic had been discussed for a while. Sent from my iPad On 2014-11-6, at 下午6:18, "Li Tianqing" wrote: > Hello, >why we put l3_snat on network node to handle North/South snat, and why > don't we put it on compute node? >Does it possible to put l3_ag

[openstack-dev] [neutron] dvr l3_snat

Hello, why we put l3_snat on network node to handle North/South snat, and why don't we put it on compute node? Does it possible to put l3_agent on all compute_node for North/South snat, dnat, and east/west l3 routing? -- Best Li Tianqing_

Re: [openstack-dev] [Neutron][DVR] Openstack Juno: how to configure dvr in Network-Node and Compute-Node?

4050...@cnsuning.com] Sent: Wednesday, October 15, 2014 9:50 PM To: openstack-dev Subject: [openstack-dev] [Neutron][DVR] Openstack Juno: how to configure dvr in Network-Node and Compute-Node? Could anyone help on this? In Openstack juno, Neutron new feature called Distributed Virtual Routing (DVR),

[openstack-dev] [Neutron][DVR] Openstack Juno: how to configure dvr in Network-Node and Compute-Node?

Could anyone help on this? In Openstack juno, Neutron new feature called Distributed Virtual Routing (DVR), But how to configure it in network-node and compute-node. Openstack.org just said "router_distributed = True", which is far than enough. could any help point to some detailed instruction o

Re: [openstack-dev] [neutron] DVR Tunnel Design Question

OVS L2 Agent). > > -- > Thanks, > > Vivek > > -Original Message- > From: Kevin Benton [mailto:blak...@gmail.com] > Sent: Thursday, September 18, 2014 12:44 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [neutron

Re: [openstack-dev] [neutron] DVR Tunnel Design Question

...@gmail.com] Sent: Thursday, September 18, 2014 12:44 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron] DVR Tunnel Design Question This sounds like a bug in Openvswitch. The unique constraint should be VLAN+MAC instead of just VLAN, so observing the

Re: [openstack-dev] [neutron] DVR Tunnel Design Question

, > > > > Vivek > > > > > > From: Kevin Benton [mailto:blak...@gmail.com] > Sent: Thursday, September 18, 2014 3:01 AM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [neutron] DVR Tunnel Design Question > >

Re: [openstack-dev] [neutron] DVR Tunnel Design Question

questions) Subject: Re: [openstack-dev] [neutron] DVR Tunnel Design Question Can you clarify what you mean with the thrashing condition? MAC addresses only need to be unique per-VLAN so I don't see how the same MAC on multiple VLANs from the same physical port would lead to any issues. On Wed

Re: [openstack-dev] [neutron] DVR Tunnel Design Question

> initial DVR architecture. > > Cheers, > Armando > > On 16 September 2014 20:35, 龚永生 wrote: > > I think the VLAN should also be supported later. The tunnel should not > be > > the prerequisite for the DVR feature. > > > > > > -------------

Re: [openstack-dev] [neutron] DVR Tunnel Design Question

the VLAN should also be supported later. The tunnel should not be > the prerequisite for the DVR feature. > > > -- Original -- > From: "Steve Wormley"; > Date: Wed, Sep 17, 2014 10:29 AM > To: "openstack-dev"; > Subjec

Re: [openstack-dev] [neutron] DVR Tunnel Design Question

I think the VLAN should also be supported later. The tunnel should not be the prerequisite for the DVR feature. -- Original -- From: "Steve Wormley"; Date: Wed, Sep 17, 2014 10:29 AM To: "openstack-dev"; Subject: [openstack-dev]

  1   2   >