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

[Brian Haley]

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)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brian Haley]

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/Neutron-DVR

Thanks,

-Brian

__
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][dvr][fip] router support two external network

[huangdenghui]

Hi
thanks, this is the case what i am looking for.




At 2016-11-13 19:38:57, "Irena Berezovsky" <irenab@gmail.com> wrote:

Hi,
The case you are describing may be related to the previously discussed RFE [1].
Having additional networks with FIP range attached via router interface should 
be allowed from the API point of view, but may need some adaptations to make it 
work properly. Please see the details in the discussion log [1].


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


BR,
Irena






On Sun, Nov 13, 2016 at 12:35 PM, Gary Kotton <gkot...@vmware.com> wrote:


Hi,

Today the mapping is 1:1. So if you want additional mappinsg to internal 
networks then you can define more than one interface on your instance. Then map 
each interface to the relevant network.

Thanks

Gary

 

From: huangdenghui <hdh_1...@163.com>
Reply-To: OpenStack List <openstack-dev@lists.openstack.org>
Date: Saturday, November 12, 2016 at 10:26 AM
To: OpenStack List <openstack-dev@lists.openstack.org>
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 gateway of a router. One private fixed ip of one 
port(usually it is a vm port ) can only associate one floating ip.  In some 
deployment scenario, all ports served by one router, all ports need ip address 
which can be accessed by intranet, and some ports need ip address which can be 
accessed by internet. I was wondering how neutron to resolve this kind of use 
cases? One idea is one router support two external network(one for intranet, 
the other one for internet, but only have gateway), the other idea is one 
router still have only one external network, but this external have two 
different type of subnet (one for internet, the other one for intranet). any 
comment is welcome. thanks.


__
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

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

[Irena Berezovsky]

Hi,
The case you are describing may be related to the previously discussed RFE
[1].
Having additional networks with FIP range attached via router interface
should be allowed from the API point of view, but may need some adaptations
to make it work properly. Please see the details in the discussion log [1].

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

BR,
Irena



On Sun, Nov 13, 2016 at 12:35 PM, Gary Kotton <gkot...@vmware.com> wrote:

> Hi,
>
> Today the mapping is 1:1. So if you want additional mappinsg to internal
> networks then you can define more than one interface on your instance. Then
> map each interface to the relevant network.
>
> Thanks
>
> Gary
>
>
>
> *From: *huangdenghui <hdh_1...@163.com>
> *Reply-To: *OpenStack List <openstack-dev@lists.openstack.org>
> *Date: *Saturday, November 12, 2016 at 10:26 AM
> *To: *OpenStack List <openstack-dev@lists.openstack.org>
> *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 gateway of a router. One private
> fixed ip of one port(usually it is a vm port ) can only associate one
> floating ip.  In some deployment scenario, all ports served by one router,
> all ports need ip address which can be accessed by intranet, and some ports
> need ip address which can be accessed by internet. I was wondering how
> neutron to resolve this kind of use cases? One idea is one router support
> two external network(one for intranet, the other one for internet, but only
> have gateway), the other idea is one router still have only one external
> network, but this external have two different type of subnet (one for
> internet, the other one for intranet). any comment is welcome. thanks.
>
> __
> 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

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

[Gary Kotton]

Hi,
Today the mapping is 1:1. So if you want additional mappinsg to internal 
networks then you can define more than one interface on your instance. Then map 
each interface to the relevant network.
Thanks
Gary

From: huangdenghui <hdh_1...@163.com>
Reply-To: OpenStack List <openstack-dev@lists.openstack.org>
Date: Saturday, November 12, 2016 at 10:26 AM
To: OpenStack List <openstack-dev@lists.openstack.org>
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 gateway of a router. One private fixed ip of one 
port(usually it is a vm port ) can only associate one floating ip.  In some 
deployment scenario, all ports served by one router, all ports need ip address 
which can be accessed by intranet, and some ports need ip address which can be 
accessed by internet. I was wondering how neutron to resolve this kind of use 
cases? One idea is one router support two external network(one for intranet, 
the other one for internet, but only have gateway), the other idea is one 
router still have only one external network, but this external have two 
different type of subnet (one for internet, the other one for intranet). any 
comment is welcome. thanks.
__
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][dvr][fip] router support two external network

[huangdenghui]

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 ip.  In some 
deployment scenario, all ports served by one router, all ports need ip address 
which can be accessed by intranet, and some ports need ip address which can be 
accessed by internet. I was wondering how neutron to resolve this kind of use 
cases? One idea is one router support two external network(one for intranet, 
the other one for internet, but only have gateway), the other idea is one 
router still have only one external network, but this external have two 
different type of subnet (one for internet, the other one for intranet). any 
comment is welcome. thanks.
__
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][dvr][fip] fg device allocated private ip address

[Carl Baldwin]

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 device do arp proxy for this situation?
>

Sorry for the delay. I was traveling and I guess this one slipped by.

The answer is yes, it can do proxy arp for this situation.

Carl
__
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][dvr][fip] fg device allocated private ip address

[huangdenghui]

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:52，"Carl Baldwin"  写道：





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 testing for 
floating ip, now,with subnet types bp,fg has different subnet than floating ip 
address, from fg'subnet gateway point view, to reach floating ip, it need a 
routes entry, destination is some floating ip address, fg'ip address is the 
nexthop, and this routes entry need be populated at the event of floating ip 
creating, deleting when floating ip is dissociated. any comments?



The fg device will still do proxy arp for the floating ip to other devices on 
the external network. This will be part of our testing. The upstream router 
should still have an on-link route on the network to the floating ip subnet. 
IOW, you shouldn't replace the floating ip subnet with the private fg subnet on 
the upstream router. You should add the new subnet to the already existing ones 
and the router should have an additional IP address on the new subnet to be 
used as the gateway address for north-bound traffic.


Carl__
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][dvr][fip] fg device allocated private ip address

[zhi]

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 reachable by the private ip address, doesn't it?


Hopes for your reply. ;-)


2016-08-03 6:38 GMT+08:00 Carl Baldwin :

>
>
> 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
>> testing for floating ip, now,with subnet types bp,fg has different subnet
>> than floating ip address, from fg'subnet gateway point view, to reach
>> floating ip, it need a routes entry, destination is some floating ip
>> address, fg'ip address is the nexthop, and this routes entry need be
>> populated at the event of floating ip creating, deleting when floating ip
>> is dissociated. any comments?
>>
>
> The fg device will still do proxy arp for the floating ip to other devices
> on the external network. This will be part of our testing. The upstream
> router should still have an on-link route on the network to the floating ip
> subnet. IOW, you shouldn't replace the floating ip subnet with the private
> fg subnet on the upstream router. You should add the new subnet to the
> already existing ones and the router should have an additional IP address
> on the new subnet to be used as the gateway address for north-bound traffic.
>
> Carl
>
> __
> 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

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

[Carl Baldwin]

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 testing
> for floating ip, now,with subnet types bp,fg has different subnet than
> floating ip address, from fg'subnet gateway point view, to reach floating
> ip, it need a routes entry, destination is some floating ip address, fg'ip
> address is the nexthop, and this routes entry need be populated at the
> event of floating ip creating, deleting when floating ip is dissociated.
> any comments?
>

The fg device will still do proxy arp for the floating ip to other devices
on the external network. This will be part of our testing. The upstream
router should still have an on-link route on the network to the floating ip
subnet. IOW, you shouldn't replace the floating ip subnet with the private
fg subnet on the upstream router. You should add the new subnet to the
already existing ones and the router should have an additional IP address
on the new subnet to be used as the gateway address for north-bound traffic.

Carl
__
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][dvr][fip] fg device allocated private ip address

[Brian Haley]

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 ip,
now,with subnet types bp,fg has different subnet than floating ip address, from
fg'subnet gateway point view, to reach floating ip, it need a routes entry,
destination is some floating ip address, fg'ip address is the nexthop, and this
routes entry need be populated at the event of floating ip creating, deleting
when floating ip is dissociated. any comments?


Yes, there could be a small change necessary to the l3-agent in order to route 
packets with DVR enabled, but I don't see it being a blocker.


-Brian



On 2016-08-01 23:38 , John Davidge  Wrote:

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
>>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 external
>>network's
>> subnets. In large public cloud deployment, current implementation will
>>consume
>> lots of public ip address. Do we need a RFE to apply subnet service
>>types spec
>> to resolve this problem. Any thoughts?
>
>Hi,
>
>This is going to be covered in the existing RFE for subnet service types
>[1].
>We currently have two reviews in progress for CRUD [2] and CLI [3], the
>IPAM
>changes are next.
>
>-Brian
>
>[1] https://review.openstack.org/#/c/300207/
>[2] https://review.openstack.org/#/c/337851/
>[3] https://review.openstack.org/#/c/342976/
>
>__
>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



Rackspace Limited is a company registered in England & Wales (company
registered number 03897010) whose registered office is at 5 Millington Road,
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may
contain confidential or privileged information intended for the recipient.
Any dissemination, distribution or copying of the enclosed material is
prohibited. If you receive this transmission in error, please notify us
immediately by e-mail at ab...@rackspace.com and delete the original
message. Your cooperation is appreciated.

__
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 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][dvr][fip] fg device allocated private ip address

[huangdenghui]

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 different subnet than floating ip 
address, from fg'subnet gateway point view, to reach floating ip, it need a 
routes entry, destination is some floating ip address, fg'ip address is the 
nexthop, and this routes entry need be populated at the event of floating ip 
creating, deleting when floating ip is dissociated. any comments?


发自网易邮箱手机版



On 2016-08-01 23:38 , John Davidge Wrote:

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
>>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 external
>>network's
>> subnets. In large public cloud deployment, current implementation will
>>consume
>> lots of public ip address. Do we need a RFE to apply subnet service
>>types spec
>> to resolve this problem. Any thoughts?
>
>Hi,
>
>This is going to be covered in the existing RFE for subnet service types
>[1].
>We currently have two reviews in progress for CRUD [2] and CLI [3], the
>IPAM
>changes are next.
>
>-Brian
>
>[1] https://review.openstack.org/#/c/300207/
>[2] https://review.openstack.org/#/c/337851/
>[3] https://review.openstack.org/#/c/342976/
>
>__
>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



Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.

__
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

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

[John Davidge]

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
>>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 external
>>network's
>> subnets. In large public cloud deployment, current implementation will
>>consume
>> lots of public ip address. Do we need a RFE to apply subnet service
>>types spec
>> to resolve this problem. Any thoughts?
>
>Hi,
>
>This is going to be covered in the existing RFE for subnet service types
>[1].
>We currently have two reviews in progress for CRUD [2] and CLI [3], the
>IPAM
>changes are next.
>
>-Brian
>
>[1] https://review.openstack.org/#/c/300207/
>[2] https://review.openstack.org/#/c/337851/
>[3] https://review.openstack.org/#/c/342976/
>
>__
>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



Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.

__
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][dvr][fip] fg device allocated private ip address

[Brian Haley]

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, floating ip and fg's ip are both allocated from external network's
subnets. In large public cloud deployment, current implementation will consume
lots of public ip address. Do we need a RFE to apply subnet service types spec
to resolve this problem. Any thoughts?


Hi,

This is going to be covered in the existing RFE for subnet service types [1]. 
We currently have two reviews in progress for CRUD [2] and CLI [3], the IPAM 
changes are next.


-Brian

[1] https://review.openstack.org/#/c/300207/
[2] https://review.openstack.org/#/c/337851/
[3] https://review.openstack.org/#/c/342976/

__
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][dvr][fip] fg device allocated private ip address

[huangdenghui]

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 external 
network's subnets. In large public cloud deployment, current implementation 
will consume lots of public ip address. Do we need a RFE to apply subnet 
service types spec to resolve this problem. Any thoughts?
__
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][DVR] - No IRC Meeting today

[Brian Haley]

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.openstack.org/wiki/Meetings/Neutron-DVR

Thanks,

-Brian

__
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][DVR] - No IRC Meeting this week

[Brian Haley]

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/Neutron-DVR

Thanks,

-Brian

__
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][dvr] Wasting so many external network IPs in DVR mode?

[Carl Baldwin]

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 floating ips. I think this is a problem. The mac
> address tables in switches will learn many mac items from different "qg"
> interfaces, like this:
>
> |MAC address | Port|
> |mac of qg1 | 2 |
> |mac of qg2 | 2 |
> |mac of qg3 | 2 |
> |mac of qg4 | 2 |
> |mac of qgN | 2 |
>
>  In DVR, I think there is no problems about that I mentioned above.
> Because physical switches can learn all the fips's mac address from the same
> port —— "fg" interface. I think the mac address tables in physical switches
> like this:
>
> |MAC address | Port|
> |mac of fg| 2 |
>
> In this situation,  just one relationship between Port and MAC address
> can be learned by the physical switches.

This is mostly correct, you've got the right idea.  If it is a compute
host on port 2 then you're correct.  But, remember that a DVR also has
a central component just like CVR.  So, the network nodes still look
like they do with CVR.

The big problem with DVR is that the qg port is distributed in many
different places, one time for each compute host with a DVR
serviceable port behind the router, and once for the central part of
the router.  If these were all directly connected to the external
network, each would need its own mac address.

Carl

__
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][dvr] Wasting so many external network IPs in DVR mode?

[zhi]

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 external bridge. Every "qg"
interface may contains one or more floating ips. I think this is a problem.
The mac address tables in switches will learn many mac items from different
"qg" interfaces, like this:

|MAC address | Port|
|mac of qg1 | 2 |
|mac of qg2 | 2 |
|mac of qg3 | 2 |
|mac of qg4 | 2 |
|mac of qgN | 2 |

 In DVR, I think there is no problems about that I mentioned above.
Because physical switches can learn all the fips's mac address from the
same port —— "fg" interface. I think the mac address tables in physical
switches like this:

|MAC address | Port|
|mac of fg| 2 |

In this situation,  just one relationship between Port and MAC address
can be learned by the physical switches.


Does my thought was right?


Thanks
Zhi Chang

2016-06-02 0:18 GMT+08:00 Carl Baldwin :

> 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 will be sent from rfp interface(qrouter interface) to
> > the fpr interface(fip namespace) after NAT by iptables rules in qrouter
> > namespace, Finally, packets will be forwarded by fg interface which
> exists
> > in the fip namespace.
> >
> > I was so confused by the "fg" interface.
> >
> > The device owner of "fg" interface is
> "network:floatingip_agent_gateway"
> > in Neutron. It is a special port which allocated from the external
> network.
> > I think, in this way, we have to wasted many IP addresses from the
> external
> > network. Because we need a dedicated router IP per compute node, didn't
> we?
>
> Yes, this is correct.  We have a simple spec [1] in review to solve
> this problem in Newton.  It will still require the same fg ports but
> will allow you to pull the IP addresses for these ports from a private
> address space so that your public IPs are not wasted on them.
>
> > In DVR mode, why not we use "qg" interface in qrouter namespace? Just
> > like the "Legacy L3 agent mode" !  We can also setup "qg" interface and
> "qr"
> > interfaces in qrouter namespaces in DVR mode.
>
> The main reason behind putting the routers behind the fip namespace,
> was the number of mac addresses that you would need.  Each port needs
> a unique mac address and some calculations showed that in some large
> environments, the number of mac addresses flying around could stretch
> the limits of mac address tables in switches and routers and cause
> degraded performance.
>
> Another thing is that it was not trivial to create a port without a
> permanent IP address to host floating ips which can come and go at any
> time.  It is also nice to have a permanent IP address on each port to
> allow debugging.  A number of ideas were thrown around for how to
> accomplish this but none ever came to fruition.  The spec I mentioned
> [1] will help with this by allowing a permanent IP for each port from
> a private pool of plentiful IP addresses to avoid wasting the public
> ones.
>
> > Maybe my thought was wrong, but I want to know what can we benefit
> from
> > the "fip" namespace and the reason why we do not use "qg" interfaces in
> DVR
> > mode just like Legacy L3 agent mode.
> >
> >
> > Hope for your reply.  ;-)
>
> Glad to help,
> Carl
>
> [1] https://review.openstack.org/#/c/300207/
>
> __
> 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

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

[Carl Baldwin]

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 will be sent from rfp interface(qrouter interface) to
> the fpr interface(fip namespace) after NAT by iptables rules in qrouter
> namespace, Finally, packets will be forwarded by fg interface which exists
> in the fip namespace.
>
> I was so confused by the "fg" interface.
>
> The device owner of "fg" interface is "network:floatingip_agent_gateway"
> in Neutron. It is a special port which allocated from the external network.
> I think, in this way, we have to wasted many IP addresses from the external
> network. Because we need a dedicated router IP per compute node, didn't we?

Yes, this is correct.  We have a simple spec [1] in review to solve
this problem in Newton.  It will still require the same fg ports but
will allow you to pull the IP addresses for these ports from a private
address space so that your public IPs are not wasted on them.

> In DVR mode, why not we use "qg" interface in qrouter namespace? Just
> like the "Legacy L3 agent mode" !  We can also setup "qg" interface and "qr"
> interfaces in qrouter namespaces in DVR mode.

The main reason behind putting the routers behind the fip namespace,
was the number of mac addresses that you would need.  Each port needs
a unique mac address and some calculations showed that in some large
environments, the number of mac addresses flying around could stretch
the limits of mac address tables in switches and routers and cause
degraded performance.

Another thing is that it was not trivial to create a port without a
permanent IP address to host floating ips which can come and go at any
time.  It is also nice to have a permanent IP address on each port to
allow debugging.  A number of ideas were thrown around for how to
accomplish this but none ever came to fruition.  The spec I mentioned
[1] will help with this by allowing a permanent IP for each port from
a private pool of plentiful IP addresses to avoid wasting the public
ones.

> Maybe my thought was wrong, but I want to know what can we benefit from
> the "fip" namespace and the reason why we do not use "qg" interfaces in DVR
> mode just like Legacy L3 agent mode.
>
>
> Hope for your reply.  ;-)

Glad to help,
Carl

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

__
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][dvr] Wasting so many external network IPs in DVR mode?

[zhi]

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
the fpr interface(fip namespace) after NAT by iptables rules in qrouter
namespace, Finally, packets will be forwarded by fg interface which exists
in the fip namespace.

I was so confused by the "fg" interface.

The device owner of "fg" interface is
"network:floatingip_agent_gateway" in Neutron. It is a special port which
allocated from the external network. I think, in this way, we have to
wasted many IP addresses from the external network. Because we need a
dedicated router IP per compute node, didn't we?

In DVR mode, why not we use "qg" interface in qrouter namespace? Just
like the "Legacy L3 agent mode" !  We can also setup "qg" interface and
"qr" interfaces in qrouter namespaces in DVR mode.

Maybe my thought was wrong, but I want to know what can we benefit from
the "fip" namespace and the reason why we do not use "qg" interfaces in DVR
mode just like Legacy L3 agent mode.


Hope for your reply.  ;-)



Thanks
Zhi Chang
__
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] dvr with ovs-dpdk.

[Mooney, Sean K]

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 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][dvr]Why drop flows like "table=1, priority=3, arp, dl_vlan=1, arp_tpa=192.168.10.1, actions=drop"?

[zhi]

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,
priority=3,arp,dl_vlan=2,arp_tpa=10.10.10.1 actions=drop
table=1, n_packets=0, n_bytes=0, idle_age=65534, hard_age=65534,
priority=2,dl_vlan=1,dl_dst=fa:16:3e:35:25:42 actions=drop
table=1, n_packets=0, n_bytes=0, idle_age=938,
priority=2,dl_vlan=2,dl_dst=fa:16:3e:de:07:79 actions=drop

"

I have a router which attached two subnets. One is 192.168.10.1, mac
address is fa:16:3e:35:25:42. Another is 10.10.10.1, mac address is
fa:16:3e:de:07:79.


What does these flows used for?


Thanks
Zhi Chang
__
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][dvr]Why keep SNAT centralized and DNAT distributed?

[Carl Baldwin]

On Mon, Mar 28, 2016 at 7:25 PM, Wang, Yalei <yalei.w...@intel.com> wrote:
> Someone is working on full distributed SNAT, like this:
>
> https://www.openstack.org/summit/tokyo-2015/videos/presentation/network-node-is-not-needed-anymore-completed-distributed-virtual-router
>
> From: Zhi Chang [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 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 ip from external network.
>
>  Question A, Why keep SNAT centralized? We put the SNAT namespace in
> compute node which running DVR l3 agent, don't we?

The reason it was kept distributed was to maintain the current
behavior of a Neutron router where SNAT is through a single address
associated with the router.  Many other models were discussed on an
etherpad [1] long ago but I couldn't really get good consensus or
traction on any of the alternatives.

Folks were generally polarized around the idea of centralizing SNAT
around a compute host rather than a router.  Some people thought that
this was the obvious solution.  Yet others saw this as a non-starter
because it would mix traffic from different tenants on the same SNAT
address.

>  Question B, Why keep DNAT distributed? I think we can keep snat
> namespace and fip namespace in one node. Why not keep DNAT and SNAT
> together?

The whole point of distributing north/south traffic was to distribute
DNAT for floating IPs.  Maybe I don't understand your question.

Carl

[1] https://etherpad.openstack.org/p/decentralized-snat

__
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][dvr]Why keep SNAT centralized and DNAT distributed?

[Zhi Chang]

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 ip from external network.


 Question A, Why keep SNAT centralized? We put the SNAT namespace in 
compute node which running DVR l3 agent, don't we?


 Question B, Why keep DNAT distributed? I think we can keep snat namespace 
and fip namespace in one node. Why not keep DNAT and SNAT together? 




Thanks
Zhi CHang__
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][dvr]How to get the relationship of veth pair device?

[Zhi Chang]

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 -S [device_name]" can get peer interface index. 
But if this interface in namepsace, how do I do?


BTW, what's the meaning of "rfp" and "fpr"? 




Thanks
Zhi Chang__
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][dvr]What does table 9 used for in br-tun?

[James Denton]

Each DVR router has a unique MAC address that can be found in the Neutron DB in 
the dvr_host_macs table. Those will MACs will likely match what’s in the flow 
rules there.

This presentation from the Paris summit (Page 19-20) breaks it down in some 
detail.

https://www.openstack.org/assets/presentation-media/Openstack-kilo-summit-DVR-Architecture-20141030-Master-submitted-to-openstack.pdf

James

From: Zhi Chang <chang...@unitedstack.com<mailto:chang...@unitedstack.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Friday, March 18, 2016 at 11:33 PM
To: openstack-dev 
<openstack-dev@lists.openstack.org<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:

 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=0x9a5f42115762fc76, duration=392186.447s, table=9, n_packets=0, 
n_bytes=0, idle_age=65534, hard_age=65534, priority=1,dl_src=fa:16:3f:76:6c:6f 
actions=output:1
 cookie=0x9a5f42115762fc76, duration=392186.388s, table=9, n_packets=0, 
n_bytes=0, idle_age=65534, hard_age=65534, priority=1,dl_src=fa:16:3f:87:39:a3 
actions=output:1
 cookie=0x9a5f42115762fc76, duration=392186.333s, table=9, n_packets=0, 
n_bytes=0, idle_age=65534, hard_age=65534, priority=1,dl_src=fa:16:3f:93:41:45 
actions=output:1

Port 1 is a patch interface which is connecting to br-int.

Question  A: there are for mac addresses in these flows. But these mac 
addresses don't in my Neutron. What do they come from??

Question B: The action of each flow is output:1, why? Why put the packets to 
br-int?


Thanks
Zhi Chang
__
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][dvr]What does table 9 used for in br-tun?

[James Denton]

Err… correction. Each host has a unique MAC, not each router. Sorry!

http://assafmuller.com/2015/04/15/distributed-virtual-routing-overview-and-eastwest-routing/

James

From: James Denton 
<james.den...@rackspace.com<mailto:james.den...@rackspace.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Friday, March 18, 2016 at 11:47 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [neutron][dvr]What does table 9 used for in br-tun?

Each DVR router has a unique MAC address that can be found in the Neutron DB in 
the dvr_host_macs table. Those will MACs will likely match what’s in the flow 
rules there.

This presentation from the Paris summit (Page 19-20) breaks it down in some 
detail.

https://www.openstack.org/assets/presentation-media/Openstack-kilo-summit-DVR-Architecture-20141030-Master-submitted-to-openstack.pdf

James

From: Zhi Chang <chang...@unitedstack.com<mailto:chang...@unitedstack.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Friday, March 18, 2016 at 11:33 PM
To: openstack-dev 
<openstack-dev@lists.openstack.org<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:

 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=0x9a5f42115762fc76, duration=392186.447s, table=9, n_packets=0, 
n_bytes=0, idle_age=65534, hard_age=65534, priority=1,dl_src=fa:16:3f:76:6c:6f 
actions=output:1
 cookie=0x9a5f42115762fc76, duration=392186.388s, table=9, n_packets=0, 
n_bytes=0, idle_age=65534, hard_age=65534, priority=1,dl_src=fa:16:3f:87:39:a3 
actions=output:1
 cookie=0x9a5f42115762fc76, duration=392186.333s, table=9, n_packets=0, 
n_bytes=0, idle_age=65534, hard_age=65534, priority=1,dl_src=fa:16:3f:93:41:45 
actions=output:1

Port 1 is a patch interface which is connecting to br-int.

Question  A: there are for mac addresses in these flows. But these mac 
addresses don't in my Neutron. What do they come from??

Question B: The action of each flow is output:1, why? Why put the packets to 
br-int?


Thanks
Zhi Chang
__
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][dvr]What does table 9 used for inbr-tun?

[Zhi Chang]

Thanks for your help. I still have a question about flows in br-int.


In Muller's blog, he says "the source MAC is replaced from the remote machine’s 
host MAC to that VM’s gateway MAC."


But in my local environment, the flows is " 


table=1, n_packets=0, n_bytes=0, idle_age=10144, 
priority=4,dl_vlan=1,dl_dst=fa:16:3e:1b:55:b1 
actions=strip_vlan,mod_dl_src:fa:16:3e:50:66:fd,output:27


table=1, n_packets=0, n_bytes=0, idle_age=10130, 
priority=4,dl_vlan=2,dl_dst=fa:16:3e:50:66:fd 
actions=strip_vlan,mod_dl_src:fa:16:3e:50:66:fd,output:28


"


Port 27 and 28 belongs local vms. And, two qr interface's mac addresss are 
fa:16:3e:1b:55:b1 and fa:16:3e:50:66:fd. 


Flows in br-int are not match what Muller says in his blog. :-(


Could you explain it?




Thanks
Zhi Chang 
 
-- Original --
From:  "James Denton"<james.den...@rackspace.com>;
Date:  Sat, Mar 19, 2016 12:51 PM
To:  "OpenStack Development Mailing List (not for usage 
questions)"<openstack-dev@lists.openstack.org>; 

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!
   
 
 
 
 
 
 
 
 
 
 
http://assafmuller.com/2015/04/15/distributed-virtual-routing-overview-and-eastwest-routing/
 
 
 James
 
 
   From: James Denton <james.den...@rackspace.com>
 Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
 Date: Friday, March 18, 2016 at 11:47 PM
 To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
 Subject: Re: [openstack-dev] [neutron][dvr]What does table 9 used for in 
br-tun?
 
 
 
Each DVR router has a unique MAC address that can be found in the Neutron 
DB in the dvr_host_macs table. Those will MACs will likely match what’s in the 
flow rules there.
 
 
 This presentation from the Paris summit (Page 19-20) breaks it down in some 
detail.
 
 
 
https://www.openstack.org/assets/presentation-media/Openstack-kilo-summit-DVR-Architecture-20141030-Master-submitted-to-openstack.pdf
   
 
 James
 
 
 
 
 
 
 
 
 
 
   From: Zhi Chang <chang...@unitedstack.com>
 Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
 Date: Friday, March 18, 2016 at 11:33 PM
 To: openstack-dev <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:
 
 
   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=0x9a5f42115762fc76, duration=392186.447s, table=9, n_packets=0, 
n_bytes=0, idle_age=65534, hard_age=65534, priority=1,dl_src=fa:16:3f:76:6c:6f 
actions=output:1
  cookie=0x9a5f42115762fc76, duration=392186.388s, table=9, n_packets=0, 
n_bytes=0, idle_age=65534, hard_age=65534, priority=1,dl_src=fa:16:3f:87:39:a3 
actions=output:1
  cookie=0x9a5f42115762fc76, duration=392186.333s, table=9, n_packets=0, 
n_bytes=0, idle_age=65534, hard_age=65534, priority=1,dl_src=fa:16:3f:93:41:45 
actions=output:1
 
 
 
 Port 1 is a patch interface which is connecting to br-int. 
 
 
 Question  A: there are for mac addresses in these flows. But these mac 
addresses don't in my Neutron. What do they come from??
 
 
 Question B: The action of each flow is output:1, why? Why put the packets to 
br-int?
 
 
 
 
 Thanks
 Zhi Chang__
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][dvr]What does table 9 used for in br-tun?

[Zhi Chang]

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=0x9a5f42115762fc76, duration=392186.447s, table=9, n_packets=0, 
n_bytes=0, idle_age=65534, hard_age=65534, priority=1,dl_src=fa:16:3f:76:6c:6f 
actions=output:1
 cookie=0x9a5f42115762fc76, duration=392186.388s, table=9, n_packets=0, 
n_bytes=0, idle_age=65534, hard_age=65534, priority=1,dl_src=fa:16:3f:87:39:a3 
actions=output:1
 cookie=0x9a5f42115762fc76, duration=392186.333s, table=9, n_packets=0, 
n_bytes=0, idle_age=65534, hard_age=65534, priority=1,dl_src=fa:16:3f:93:41:45 
actions=output:1



Port 1 is a patch interface which is connecting to br-int. 


Question  A: there are for mac addresses in these flows. But these mac 
addresses don't in my Neutron. What do they come from??


Question B: The action of each flow is output:1, why? Why put the packets to 
br-int?




Thanks
Zhi Chang__
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][DVR] No Meeting tomorrow

[Brian Haley]

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 questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Gal Sagie]

Hi Swami,

Any luck on this? we plan to share our results soon and want to see we
cover all cases
and tests results are good

On Fri, Feb 19, 2016 at 7:49 PM, Vasudevan, Swaminathan (PNB Roseville) <
swaminathan.vasude...@hpe.com> wrote:

> Hi Gal Sagie,
>
> Let me try to pull in the data and will provide you the information.
>
> Thanks
>
> Swami
>
>
>
> *From:* Gal Sagie [mailto:gal.sa...@gmail.com]
> *Sent:* Thursday, February 18, 2016 9:36 PM
> *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 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 so on..) details
>
> and without the full scenario details is a bit hard, regardless however i
> hope it will give us at least
>
> an estimation where we are at)
>
>
>
> Thanks
>
> Gal.
>
>
>
> On Thu, Feb 18, 2016 at 9:34 PM, Vasudevan, Swaminathan (PNB Roseville) <
> swaminathan.vasude...@hpe.com> wrote:
>
> Hi Gal Sagie,
>
> Yes there was some performance results on DVR that we shared with the
> community during the Liberty summit in Vancouver.
>
>
>
> Also I think there was a performance analysis that was done by Oleg
> Bondarev on DVR during the Paris summit.
>
>
>
> We have done lot more changes to the control plane to improve the scale
> and performance in DVR during the Mitaka cycle and will be sharing some
> performance results in the upcoming summit.
>
>
>
> Definitely we can align on our approach and have all those results
> captured in the upstream for the reference.
>
>
>
> Please let me know if you need any other 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 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
> also join the
>
> community in defining base standards and scenarios to test any solution
> out there.
>
>
>
> For that we also plan to join and contribute to openstack-performance [2]
> efforts which to me
>
> are really important.
>
>
>
> Would love any results/information you can share, also interested in
> control plane
>
> testing and API stress tests (either using Rally or not)
>
>
>
> Thanks
>
> Gal.
>
>
>
> [1]
> http://docs.openstack.org/developer/dragonflow/distributed_dragonflow.html
>
> [2] https://github.com/openstack/performance-docs
>
>
> __
> 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
>
>
>
>
>
> --
>
> Best Regards ,
>
> The G.
>
> __
> 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
>
>


-- 
Best Regards ,

The G.
__
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] - DVR L3 data plane performance results and scenarios

[Wuhongning]

I've not done any test on AWS yet.

But it seems that a simple optimization could be introduced for huge 
improvement: add a config item to let l3 agent remove all arp entry rpc, and 
reuse arp response by l2pop (if the admin choose to enable it)


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

How quickly does AWS do the same setup?

Best,
-jay

__
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

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

[Jay Pipes]

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


How quickly does AWS do the same setup?

Best,
-jay

__
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] - DVR L3 data plane performance results and scenarios

[Wuhongning]

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.






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 performance results 
and scenarios

Hi Gal Sagie,
Let me try to pull in the data and will provide you the information.
Thanks
Swami

From: Gal Sagie [mailto:gal.sa...@gmail.com]
Sent: Thursday, February 18, 2016 9:36 PM
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 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 so on..) details
and without the full scenario details is a bit hard, regardless however i hope 
it will give us at least
an estimation where we are at)

Thanks
Gal.

On Thu, Feb 18, 2016 at 9:34 PM, Vasudevan, Swaminathan (PNB Roseville) 
<swaminathan.vasude...@hpe.com<mailto:swaminathan.vasude...@hpe.com>> wrote:
Hi Gal Sagie,
Yes there was some performance results on DVR that we shared with the community 
during the Liberty summit in Vancouver.

Also I think there was a performance analysis that was done by Oleg Bondarev on 
DVR during the Paris summit.

We have done lot more changes to the control plane to improve the scale and 
performance in DVR during the Mitaka cycle and will be sharing some performance 
results in the upcoming summit.

Definitely we can align on our approach and have all those results captured in 
the upstream for the reference.

Please let me know if you need any other information.

Thanks
Swami

From: Gal Sagie [mailto:gal.sa...@gmail.com<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 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 also 
join the
community in defining base standards and scenarios to test any solution out 
there.

For that we also plan to join and contribute to openstack-performance [2] 
efforts which to me
are really important.

Would love any results/information you can share, also interested in control 
plane
testing and API stress tests (either using Rally or not)

Thanks
Gal.

[1] http://docs.openstack.org/developer/dragonflow/distributed_dragonflow.html
[2] https://github.com/openstack/performance-docs

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Best Regards ,

The G.
__
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] - DVR L3 data plane performance results and scenarios

[Vasudevan, Swaminathan (PNB Roseville)]

Hi Gal Sagie,
Let me try to pull in the data and will provide you the information.
Thanks
Swami

From: Gal Sagie [mailto:gal.sa...@gmail.com]
Sent: Thursday, February 18, 2016 9:36 PM
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 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 so on..) details
and without the full scenario details is a bit hard, regardless however i hope 
it will give us at least
an estimation where we are at)

Thanks
Gal.

On Thu, Feb 18, 2016 at 9:34 PM, Vasudevan, Swaminathan (PNB Roseville) 
<swaminathan.vasude...@hpe.com<mailto:swaminathan.vasude...@hpe.com>> wrote:
Hi Gal Sagie,
Yes there was some performance results on DVR that we shared with the community 
during the Liberty summit in Vancouver.

Also I think there was a performance analysis that was done by Oleg Bondarev on 
DVR during the Paris summit.

We have done lot more changes to the control plane to improve the scale and 
performance in DVR during the Mitaka cycle and will be sharing some performance 
results in the upcoming summit.

Definitely we can align on our approach and have all those results captured in 
the upstream for the reference.

Please let me know if you need any other information.

Thanks
Swami

From: Gal Sagie [mailto:gal.sa...@gmail.com<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 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 also 
join the
community in defining base standards and scenarios to test any solution out 
there.

For that we also plan to join and contribute to openstack-performance [2] 
efforts which to me
are really important.

Would love any results/information you can share, also interested in control 
plane
testing and API stress tests (either using Rally or not)

Thanks
Gal.

[1] http://docs.openstack.org/developer/dragonflow/distributed_dragonflow.html
[2] https://github.com/openstack/performance-docs

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Best Regards ,

The G.
__
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] - DVR L3 data plane performance results and scenarios

[Gal Sagie]

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 so on..) details
and without the full scenario details is a bit hard, regardless however i
hope it will give us at least
an estimation where we are at)

Thanks
Gal.

On Thu, Feb 18, 2016 at 9:34 PM, Vasudevan, Swaminathan (PNB Roseville) <
swaminathan.vasude...@hpe.com> wrote:

> Hi Gal Sagie,
>
> Yes there was some performance results on DVR that we shared with the
> community during the Liberty summit in Vancouver.
>
>
>
> Also I think there was a performance analysis that was done by Oleg
> Bondarev on DVR during the Paris summit.
>
>
>
> We have done lot more changes to the control plane to improve the scale
> and performance in DVR during the Mitaka cycle and will be sharing some
> performance results in the upcoming summit.
>
>
>
> Definitely we can align on our approach and have all those results
> captured in the upstream for the reference.
>
>
>
> Please let me know if you need any other 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 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
> also join the
>
> community in defining base standards and scenarios to test any solution
> out there.
>
>
>
> For that we also plan to join and contribute to openstack-performance [2]
> efforts which to me
>
> are really important.
>
>
>
> Would love any results/information you can share, also interested in
> control plane
>
> testing and API stress tests (either using Rally or not)
>
>
>
> Thanks
>
> Gal.
>
>
>
> [1]
> http://docs.openstack.org/developer/dragonflow/distributed_dragonflow.html
>
> [2] https://github.com/openstack/performance-docs
>
> __
> 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
>
>


-- 
Best Regards ,

The G.
__
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] - DVR L3 data plane performance results and scenarios

[Georgy Okrokvertskhov]

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 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
> also join the
> community in defining base standards and scenarios to test any solution
> out there.
>
> For that we also plan to join and contribute to openstack-performance [2]
> efforts which to me
> are really important.
>
> Would love any results/information you can share, also interested in
> control plane
> testing and API stress tests (either using Rally or not)
>
> Thanks
> Gal.
>
> [1]
> http://docs.openstack.org/developer/dragonflow/distributed_dragonflow.html
> [2] https://github.com/openstack/performance-docs
>
> __
> 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
>
>


-- 
Georgy Okrokvertskhov
Architect,
OpenStack Platform Products,
Mirantis
http://www.mirantis.com
Tel. +1 650 963 9828
Mob. +1 650 996 3284
__
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] - DVR L3 data plane performance results and scenarios

[Vasudevan, Swaminathan (PNB Roseville)]

Hi Gal Sagie,
Yes there was some performance results on DVR that we shared with the community 
during the Liberty summit in Vancouver.

Also I think there was a performance analysis that was done by Oleg Bondarev on 
DVR during the Paris summit.

We have done lot more changes to the control plane to improve the scale and 
performance in DVR during the Mitaka cycle and will be sharing some performance 
results in the upcoming summit.

Definitely we can align on our approach and have all those results captured in 
the upstream for the reference.

Please let me know if you need any other 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 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 also 
join the
community in defining base standards and scenarios to test any solution out 
there.

For that we also plan to join and contribute to openstack-performance [2] 
efforts which to me
are really important.

Would love any results/information you can share, also interested in control 
plane
testing and API stress tests (either using Rally or not)

Thanks
Gal.

[1] http://docs.openstack.org/developer/dragonflow/distributed_dragonflow.html
[2] https://github.com/openstack/performance-docs
__
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] - DVR L3 data plane performance results and scenarios

[Gal Sagie]

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
also join the
community in defining base standards and scenarios to test any solution out
there.

For that we also plan to join and contribute to openstack-performance [2]
efforts which to me
are really important.

Would love any results/information you can share, also interested in
control plane
testing and API stress tests (either using Rally or not)

Thanks
Gal.

[1]
http://docs.openstack.org/developer/dragonflow/distributed_dragonflow.html
[2] https://github.com/openstack/performance-docs
__
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][dvr]

[Vasudevan, Swaminathan (PNB Roseville)]

Hi Sudhakar,
I don’t think there was any specific reason behind this.
But we can definitely check for the config flag and then add the topic 
‘dvr_update’.
Go ahead and file a bug and we can address it.

Thanks
Swami

From: Sudhakar Gariganti [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 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 and listen on dvr_update 
topic.

Is there any reason for enabling the DVR topic by default, unlike l2_pop which 
makes the agent subscribe to the l2_pop topic only when l2_pop is enabled??

Thanks,
Sudhakar.
__
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][dvr]

[Sudhakar Gariganti]

Ok. Thanks for the response Swami. Filed a defect [1] for tracking this..

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

Thanks,
Sudhakar.

On Thu, Jan 28, 2016 at 10:34 PM, Vasudevan, Swaminathan (PNB Roseville) <
swaminathan.vasude...@hpe.com> wrote:

> Hi Sudhakar,
>
> I don’t think there was any specific reason behind this.
>
> But we can definitely check for the config flag and then add the topic
> ‘dvr_update’.
>
> Go ahead and file a bug and we can address it.
>
>
>
> Thanks
>
> Swami
>
>
>
> *From:* Sudhakar Gariganti [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 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 and
> listen on dvr_update topic.
>
>
>
> Is there any reason for enabling the DVR topic by default, unlike l2_pop
> which makes the agent subscribe to the l2_pop topic only when l2_pop is
> enabled??
>
>
>
> Thanks,
>
> Sudhakar.
>
__
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][dvr]

[Sudhakar Gariganti]

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 and
listen on dvr_update topic.

Is there any reason for enabling the DVR topic by default, unlike l2_pop
which makes the agent subscribe to the l2_pop topic only when l2_pop is
enabled??

Thanks,
Sudhakar.
__
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][DVR] - No IRC Meeting for the next two weeks.

[Vasudevan, Swaminathan (PNB Roseville)]

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/Neutron-DVR


Wish you all Happy Holidays and Happy New Year.

Thanks
Swami

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

[Vasudevan, Swaminathan (PNB Roseville)]

Hi Armando/Carl,
Yes based on Carl’s recommendation I have categorized the bugs in the Wiki 
below right now. If you think adding an Etherpad will be more appropriate, we 
can add one.

https://wiki.openstack.org/wiki/Meetings/Neutron-DVR


Thanks
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 2015 at 10:46, Carl Baldwin 
<c...@ecbaldwin.net<mailto:c...@ecbaldwin.net>> 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 us to get things done faster and more efficiently.  Let
me know if you think otherwise.

First, I'd like to suggest adding DvrImpact to the comment of any
patches that are meant to improve DVR in some way.  People have asked
me about reviewing DVR changes.  I can show them the DVR backlog [1]
in launchpad but it would be nice to have a DVR specific dashboard.
With DvrImpact in the subject, we can make it even more convenient to
find reviews.

The other change I'd like to propose is to categorize our DVR backlog
in to three categories:  broken, scale (loadimpact), and new features.
I'd propose that we prioritize in that order.  Anyone have any
suggestions for how to tag or otherwise categorize and tackle these?
I know there is a loadimpact (or similar) tag those.  Should we come
up with a couple more tags to divide the rest?

Thoughts?

Another alternative would be to capture the list of stuff to review in an 
etherpad like [1]. It looks like Nova relies on a similar mechanism [2], and it 
sounds it works for them, so it's worth pursuing to see if review velocity 
improves.

Thoughts?
Cheers,
Armando

[1] https://etherpad.openstack.org/p/neutron-dvr
[2] https://etherpad.openstack.org/p/mitaka-nova-priorities-tracking


Carl

[1] https://goo.gl/M5SwfS

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://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

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

[Armando M.]

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 us to get things done faster and more efficiently.  Let
> me know if you think otherwise.
>
> First, I'd like to suggest adding DvrImpact to the comment of any
> patches that are meant to improve DVR in some way.  People have asked
> me about reviewing DVR changes.  I can show them the DVR backlog [1]
> in launchpad but it would be nice to have a DVR specific dashboard.
> With DvrImpact in the subject, we can make it even more convenient to
> find reviews.
>
> The other change I'd like to propose is to categorize our DVR backlog
> in to three categories:  broken, scale (loadimpact), and new features.
> I'd propose that we prioritize in that order.  Anyone have any
> suggestions for how to tag or otherwise categorize and tackle these?
> I know there is a loadimpact (or similar) tag those.  Should we come
> up with a couple more tags to divide the rest?
>
> Thoughts?
>

Another alternative would be to capture the list of stuff to review in an
etherpad like [1]. It looks like Nova relies on a similar mechanism [2],
and it sounds it works for them, so it's worth pursuing to see if review
velocity improves.

Thoughts?
Cheers,
Armando

[1] https://etherpad.openstack.org/p/neutron-dvr
[2] https://etherpad.openstack.org/p/mitaka-nova-priorities-tracking


> Carl
>
> [1] https://goo.gl/M5SwfS
>
> __
> 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

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

[Armando M.]

On 11 December 2015 at 15:23, Vasudevan, Swaminathan (PNB Roseville) <
swaminathan.vasude...@hpe.com> wrote:

> Hi Armando/Carl,
>
> Yes based on Carl’s recommendation I have categorized the bugs in the Wiki
> below right now. If you think adding an Etherpad will be more appropriate,
> we can add one.
>
>
>
> https://wiki.openstack.org/wiki/Meetings/Neutron-DVR
>

The wiki works too. Some people may like to go from LP to Gerrit or
straight to Gerrit, so it might be worth linking the most current review #
to each bug report.


>
>
>
>
> Thanks
>
> 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 2015 at 10:46, Carl Baldwin <c...@ecbaldwin.net> 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 us to get things done faster and more efficiently.  Let
> me know if you think otherwise.
>
> First, I'd like to suggest adding DvrImpact to the comment of any
> patches that are meant to improve DVR in some way.  People have asked
> me about reviewing DVR changes.  I can show them the DVR backlog [1]
> in launchpad but it would be nice to have a DVR specific dashboard.
> With DvrImpact in the subject, we can make it even more convenient to
> find reviews.
>
> The other change I'd like to propose is to categorize our DVR backlog
> in to three categories:  broken, scale (loadimpact), and new features.
> I'd propose that we prioritize in that order.  Anyone have any
> suggestions for how to tag or otherwise categorize and tackle these?
> I know there is a loadimpact (or similar) tag those.  Should we come
> up with a couple more tags to divide the rest?
>
> Thoughts?
>
>
>
> Another alternative would be to capture the list of stuff to review in an
> etherpad like [1]. It looks like Nova relies on a similar mechanism [2],
> and it sounds it works for them, so it's worth pursuing to see if review
> velocity improves.
>
>
>
> Thoughts?
>
> Cheers,
>
> Armando
>
>
>
> [1] https://etherpad.openstack.org/p/neutron-dvr
>
> [2] https://etherpad.openstack.org/p/mitaka-nova-priorities-tracking
>
>
>
>
> Carl
>
> [1] https://goo.gl/M5SwfS
>
> __
> 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 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] DVR + L3 HA + L2pop - Mapping out the work

[Duarte, Adolfo]

I agree with your comments below. 

I hope we are not going to hold off on this patch, since we need to address the 
other issues. It makes sense to have a separate tag in the Launchpad to couple 
all the l3-ha-dvr-l2pop issues into a single bucket and track it to completion.

The patch in question (143169) is only half of the solution. 143169 is the 
server side of the code. 

The agent side has already merged, and there are several parties waiting for 
the servers side so they can start evaluating and testing the solution.  I know 
that this can be done by pulling the patch itself but the problem with that is 
that until it is merged the patch status is not really "frozen". In other 
words, without the merge, there is no assurance that something will not come in 
at the last minute and change its functionality and break it, or that more 
defects are introduce due to the constant refactoring to keep it out of merge 
conflict. 

By merging the patch right now we give ourselves enough time to solve any 
issues that might arise. When fixes for the defects below are worked out they 
will automatically be tested and verified against dvr/ha. 

In worst case scenario this patch can be reverted; but if we wait too  long to 
merge it, we might paint ourselves into a corner.  

Let us merge this patch and that would allow the users to test the server side 
and agent side for further evaluation. We can address any issues that come 
along with enough time to either fix them, 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 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 of problems, and this is being tackled 
full on, with more folks joining the good fight soon. L3 HA also has its own 
problems:

* https://review.openstack.org/#/c/238122/
* https://review.openstack.org/#/c/230481/
* https://review.openstack.org/#/c/250040/

DVR requires l2pop, and l2pop on its own is also problematic (Regardless if DVR 
or L3 HA is turned on). One notable issue is that it screws up live migration:
https://bugs.launchpad.net/neutron/+bug/1443421.
I'd really like to see more focus on Vivek's patch that attempts to resolve 
this issue:
https://review.openstack.org/#/c/175383/

Finally the way L3 HA integrates with l2pop is not something I would recommend 
in production, as described here:
https://bugs.launchpad.net/neutron/+bug/1522980. If I cannot find an owner for 
this work I will reach out to some folks soon.

__
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

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

[Ryan Moats]

"Armando M." <arma...@gmail.com> wrote on 12/04/2015 03:43:29 PM:

> From: "Armando M." <arma...@gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev@lists.openstack.org>
> Date: 12/04/2015 03:44 PM
> Subject: Re: [openstack-dev] [Neutron][DVR]
>
> > On 4 December 2015 at 05:56, Ryan Moats <rmo...@us.ibm.com> wrote:
> > I pretty much agree with Oleg here - I'm not sure an additional tag
> > for defects is needed.
> > The idea of a DvrImpact in the commit message is interesting, but
> > I'm not entirely convinced - if we
> > do it for one sub-project, do we need to do it for all sub-projects
> > and then what does that turn into?
> What does this mean? No other project should care about this. DVR is
> a core feature.

I'm trying to understand if (at its logical conclusion) we end up with
commit tags for all features (i.e. RbacImpact, BareMetalImpact, DbImpact,
etc.) and what that would do to the commit message...

Ryan Moats (regXboi)
__
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][DVR]

[Armando M.]

On 7 December 2015 at 05:41, Ryan Moats <rmo...@us.ibm.com> wrote:

> "Armando M." <arma...@gmail.com> wrote on 12/04/2015 03:43:29 PM:
>
> > From: "Armando M." <arma...@gmail.com>
> > To: "OpenStack Development Mailing List (not for usage questions)"
> > <openstack-dev@lists.openstack.org>
> > Date: 12/04/2015 03:44 PM
> > Subject: Re: [openstack-dev] [Neutron][DVR]
> >
> > > On 4 December 2015 at 05:56, Ryan Moats <rmo...@us.ibm.com> wrote:
> > > I pretty much agree with Oleg here - I'm not sure an additional tag
> > > for defects is needed.
> > > The idea of a DvrImpact in the commit message is interesting, but
> > > I'm not entirely convinced - if we
> > > do it for one sub-project, do we need to do it for all sub-projects
> > > and then what does that turn into?
> > What does this mean? No other project should care about this. DVR is
> > a core feature.
>
> I'm trying to understand if (at its logical conclusion) we end up with
> commit tags for all features (i.e. RbacImpact, BareMetalImpact, DbImpact,
>  etc.) and what that would do to the commit message...
>

Oh, you mean feature!

Well, even if we did have one per feature, we wouldn't have a single patch
impacting multiple features; patches are meant to be small and cohesive in
nature, and if they impacted more than one area they should be broken down.


>
>
> Ryan Moats (regXboi)
>
> __
> 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

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

[Venkata Anil]

Hi Assaf

I will work on this bug(i.e L3 HA integration with l2pop. I have already 
assigned it to myself).


https://bugs.launchpad.net/neutron/+bug/1522980

Thanks
Anil


On 12/05/2015 04:25 AM, Vasudevan, Swaminathan (PNB Roseville) wrote:

Hi Assaf,
Thanks for putting the list together.
We 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] 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 of problems, and this is being tackled 
full on, with more folks joining the good fight soon. L3 HA also has its own 
problems:

* https://review.openstack.org/#/c/238122/
* https://review.openstack.org/#/c/230481/
* https://review.openstack.org/#/c/250040/

DVR requires l2pop, and l2pop on its own is also problematic (Regardless if DVR 
or L3 HA is turned on). One notable issue is that it screws up live migration:
https://bugs.launchpad.net/neutron/+bug/1443421.
I'd really like to see more focus on Vivek's patch that attempts to resolve 
this issue:
https://review.openstack.org/#/c/175383/

Finally the way L3 HA integrates with l2pop is not something I would recommend 
in production, as described here:
https://bugs.launchpad.net/neutron/+bug/1522980. If I cannot find an owner for 
this work I will reach out to some folks soon.

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

[Oleg Bondarev]

On Thu, Dec 3, 2015 at 10:06 PM, Vasudevan, Swaminathan (PNB Roseville) <
swaminathan.vasude...@hpe.com> wrote:

> 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 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 know if you
> think otherwise.
>
> First, I'd like to suggest adding DvrImpact to the comment of any patches
> that are meant to improve DVR in some way.  People have asked me about
> reviewing DVR changes.  I can show them the DVR backlog [1] in launchpad
> but it would be nice to have a DVR specific dashboard.
> With DvrImpact in the subject, we can make it even more convenient to find
> reviews.
>

+1


>
> The other change I'd like to propose is to categorize our DVR backlog in
> to three categories:  broken, scale (loadimpact), and new features.
> I'd propose that we prioritize in that order.  Anyone have any suggestions
> for how to tag or otherwise categorize and tackle these?
>

This might be useful but honestly I don't feel a strong need for
categorizing dvr bugs at the moment because of the amount of bugs
(currently I see 31 when filtering by l3-dvr-backlog tag).
l3-dvr-backlog tag + High/Critical may stand for 'broken', l3-dvr-backlog +
loadimpact for 'scale', l3-dvr-backlog + Wishlist for new (small)
enhancements.
I might be missing something though.


> I know there is a loadimpact (or similar) tag those.  Should we come up
> with a couple more tags to divide the rest?
>
> Thoughts?
>
> Carl
>
> [1] https://goo.gl/M5SwfS
>
> __
> 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 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][DVR]

[Ryan Moats]

I pretty much agree with Oleg here - I'm not sure an additional tag for
defects is needed.
The idea of a DvrImpact in the commit message is interesting, but I'm not
entirely convinced - if we
do it for one sub-project, do we need to do it for all sub-projects and
then what does that turn into?

I'm not yet for or against, I'm just trying to think what the commit
messages are going to end up looking like...

Ryan Moats (regXboi)

Oleg Bondarev <obonda...@mirantis.com> wrote on 12/04/2015 02:44:58 AM:

> From: Oleg Bondarev <obonda...@mirantis.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev@lists.openstack.org>
> 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
> 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 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 know if you think otherwise.
>
> First, I'd like to suggest adding DvrImpact to the comment of any
> patches that are meant to improve DVR in some way.  People have
> asked me about reviewing DVR changes.  I can show them the DVR
> backlog [1] in launchpad but it would be nice to have a DVR
specificdashboard.
> With DvrImpact in the subject, we can make it even more convenient
> to find reviews.
>
> +1
>
>
> The other change I'd like to propose is to categorize our DVR
> backlog in to three categories:  broken, scale (loadimpact), and
newfeatures.
> I'd propose that we prioritize in that order.  Anyone have any
> suggestions for how to tag or otherwise categorize and tackle these?
>
> This might be useful but honestly I don't feel a strong need for
> categorizing dvr bugs at the moment because of the amount of bugs
> (currently I see 31 when filtering by l3-dvr-backlog tag).
> l3-dvr-backlog tag + High/Critical may stand for 'broken', l3-dvr-
> backlog + loadimpact for 'scale', l3-dvr-backlog + Wishlist for new
> (small) enhancements.
> I might be missing something though.
>
> I know there is a loadimpact (or similar) tag those.  Should we come
> up with a couple more tags to divide the rest?
>
> Thoughts?
>
> Carl
>
> [1] https://goo.gl/M5SwfS
>
>
__
> 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 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

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

[Armando M.]

On 4 December 2015 at 00:44, Oleg Bondarev <obonda...@mirantis.com> wrote:

>
>
> On Thu, Dec 3, 2015 at 10:06 PM, Vasudevan, Swaminathan (PNB Roseville) <
> swaminathan.vasude...@hpe.com> wrote:
>
>> 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 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 know if you
>> think otherwise.
>>
>> First, I'd like to suggest adding DvrImpact to the comment of any patches
>> that are meant to improve DVR in some way.  People have asked me about
>> reviewing DVR changes.  I can show them the DVR backlog [1] in launchpad
>> but it would be nice to have a DVR specific dashboard.
>> With DvrImpact in the subject, we can make it even more convenient to
>> find reviews.
>>
>
> +1
>
>
>>
>> The other change I'd like to propose is to categorize our DVR backlog in
>> to three categories:  broken, scale (loadimpact), and new features.
>> I'd propose that we prioritize in that order.  Anyone have any
>> suggestions for how to tag or otherwise categorize and tackle these?
>>
>
> This might be useful but honestly I don't feel a strong need for
> categorizing dvr bugs at the moment because of the amount of bugs
> (currently I see 31 when filtering by l3-dvr-backlog tag).
> l3-dvr-backlog tag + High/Critical may stand for 'broken', l3-dvr-backlog
> + loadimpact for 'scale', l3-dvr-backlog + Wishlist for new (small)
> enhancements.
> I might be missing something though.
>

That's a good point:

* High/Critical ==> DVR doesn't do what it's supposed to do
* LoadImpact ==> DVR doesn't break but it takes forever to complete
* Wishlist ==> DVR doesn't do this, but it'd be nice if it did

My suggestion was not so much to add an extra layer of classification, but
to figure out how to prioritize review/coding efforts of bugs in these
categories in a way so that each area sees progress at a similar rate.
Easier said than done :)


>
>
>> I know there is a loadimpact (or similar) tag those.  Should we come up
>> with a couple more tags to divide the rest?
>>
>> Thoughts?
>>
>> Carl
>>
>> [1] https://goo.gl/M5SwfS
>>
>> __
>> 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 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

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

[Armando M.]

On 4 December 2015 at 05:56, Ryan Moats <rmo...@us.ibm.com> wrote:

> I pretty much agree with Oleg here - I'm not sure an additional tag for
> defects is needed.
> The idea of a DvrImpact in the commit message is interesting, but I'm not
> entirely convinced - if we
> do it for one sub-project, do we need to do it for all sub-projects and
> then what does that turn into?
>
What does this mean? No other project should care about this. DVR is a core
feature.

>
> I'm not yet for or against, I'm just trying to think what the commit
> messages are going to end up looking like...
>
> Ryan Moats (regXboi)
>
> Oleg Bondarev <obonda...@mirantis.com> wrote on 12/04/2015 02:44:58 AM:
>
> > From: Oleg Bondarev <obonda...@mirantis.com>
> > To: "OpenStack Development Mailing List (not for usage questions)"
> > <openstack-dev@lists.openstack.org>
> > 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
> > Swami
> >
> > -Original Message-
> > From: Carl Baldwin [mailto:c...@ecbaldwin.net <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 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 know if you think otherwise.
> >
> > First, I'd like to suggest adding DvrImpact to the comment of any
> > patches that are meant to improve DVR in some way.  People have
> > asked me about reviewing DVR changes.  I can show them the DVR
> > backlog [1] in launchpad but it would be nice to have a DVR
> specificdashboard.
> > With DvrImpact in the subject, we can make it even more convenient
> > to find reviews.
> >
> > +1
> >
> >
> > The other change I'd like to propose is to categorize our DVR
> > backlog in to three categories:  broken, scale (loadimpact), and
> newfeatures.
> > I'd propose that we prioritize in that order.  Anyone have any
> > suggestions for how to tag or otherwise categorize and tackle these?
> >
> > This might be useful but honestly I don't feel a strong need for
> > categorizing dvr bugs at the moment because of the amount of bugs
> > (currently I see 31 when filtering by l3-dvr-backlog tag).
> > l3-dvr-backlog tag + High/Critical may stand for 'broken', l3-dvr-
> > backlog + loadimpact for 'scale', l3-dvr-backlog + Wishlist for new
> > (small) enhancements.
> > I might be missing something though.
> >
> > I know there is a loadimpact (or similar) tag those.  Should we come
> > up with a couple more tags to divide the rest?
> >
> > Thoughts?
> >
> > Carl
> >
> > [1] https://goo.gl/M5SwfS
> >
> >
> __
> > 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 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 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] DVR + L3 HA + L2pop - Mapping out the work

[Vasudevan, Swaminathan (PNB Roseville)]

Hi Assaf,
Thanks for putting the list together.
We 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] 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 of problems, and this is being tackled 
full on, with more folks joining the good fight soon. L3 HA also has its own 
problems:

* https://review.openstack.org/#/c/238122/
* https://review.openstack.org/#/c/230481/
* https://review.openstack.org/#/c/250040/

DVR requires l2pop, and l2pop on its own is also problematic (Regardless if DVR 
or L3 HA is turned on). One notable issue is that it screws up live migration:
https://bugs.launchpad.net/neutron/+bug/1443421.
I'd really like to see more focus on Vivek's patch that attempts to resolve 
this issue:
https://review.openstack.org/#/c/175383/

Finally the way L3 HA integrates with l2pop is not something I would recommend 
in production, as described here:
https://bugs.launchpad.net/neutron/+bug/1522980. If I cannot find an owner for 
this work I will reach out to some folks soon.

__
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] DVR + L3 HA + L2pop - Mapping out the work

[Assaf Muller]

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 of problems, and this is
being tackled full on, with more folks joining the good fight soon. L3
HA also has its own problems:

* https://review.openstack.org/#/c/238122/
* https://review.openstack.org/#/c/230481/
* https://review.openstack.org/#/c/250040/

DVR requires l2pop, and l2pop on its own is also problematic
(Regardless if DVR or L3 HA is turned on). One notable issue is that
it screws up live migration:
https://bugs.launchpad.net/neutron/+bug/1443421.
I'd really like to see more focus on Vivek's patch that attempts to
resolve this issue:
https://review.openstack.org/#/c/175383/

Finally the way L3 HA integrates with l2pop is not something I would
recommend in production, as described here:
https://bugs.launchpad.net/neutron/+bug/1522980. If I cannot find an
owner for this work I will reach out to some folks soon.

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

[Vasudevan, Swaminathan (PNB Roseville)]

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 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 know if you think 
otherwise.

First, I'd like to suggest adding DvrImpact to the comment of any patches that 
are meant to improve DVR in some way.  People have asked me about reviewing DVR 
changes.  I can show them the DVR backlog [1] in launchpad but it would be nice 
to have a DVR specific dashboard.
With DvrImpact in the subject, we can make it even more convenient to find 
reviews.

The other change I'd like to propose is to categorize our DVR backlog in to 
three categories:  broken, scale (loadimpact), and new features.
I'd propose that we prioritize in that order.  Anyone have any suggestions for 
how to tag or otherwise categorize and tackle these?
I know there is a loadimpact (or similar) tag those.  Should we come up with a 
couple more tags to divide the rest?

Thoughts?

Carl

[1] https://goo.gl/M5SwfS

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

[Carl Baldwin]

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 know if you think otherwise.

First, I'd like to suggest adding DvrImpact to the comment of any
patches that are meant to improve DVR in some way.  People have asked
me about reviewing DVR changes.  I can show them the DVR backlog [1]
in launchpad but it would be nice to have a DVR specific dashboard.
With DvrImpact in the subject, we can make it even more convenient to
find reviews.

The other change I'd like to propose is to categorize our DVR backlog
in to three categories:  broken, scale (loadimpact), and new features.
I'd propose that we prioritize in that order.  Anyone have any
suggestions for how to tag or otherwise categorize and tackle these?
I know there is a loadimpact (or similar) tag those.  Should we come
up with a couple more tags to divide the rest?

Thoughts?

Carl

[1] https://goo.gl/M5SwfS

__
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 DVR Subteam Meeting Resumes from Nov 4th 2015.

[Vasudevan, Swaminathan (PNB Roseville)]

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
Time: 1500 UTC on Wednesdays.

For Agenda and topics to be discussed look at the Wiki below.
https://wiki.openstack.org/wiki/Meetings/Neutron-DVR

Thanks.
Swaminathan Vasudevan
Systems Software Engineer (TC)


HP Networking
Hewlett-Packard
8000 Foothills Blvd
M/S 5541
Roseville, CA - 95747
tel: 916.785.0937
fax: 916.785.1815
email: swaminathan.vasude...@hp.com


__
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] [DVR] easyOVS -- Smart tool to use/debug Neutron/DVR

[Germy Lure]

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 VM2 via DVR but failed.
The tool should tell you that the packet is sent to the snat router and the
DVR router on the host VM1 residents is created with a wrong
route[dest=xx,nexthop=yy], and the right route should be dest=xx,nexthop=zz.
c.As a tool, I think if it should be simple. The best is no installation.
Copy and use it. Can you simple it? One of the possible method may
implement it using C/C++ and publish executable file.

BR,
Germy

On Fri, Aug 28, 2015 at 6:05 PM, Baohua Yang  wrote:

> 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
> , in summary, it can
>
>
>- Format the output and use color to make it clear and easy to compare.
>- Associate the OpenStack information (e.g., vm ip) on the virtual
>port or rule
>- Query openvswitch,iptables,namespace information in smart way.
>- Check if the DVR configuration is correct.
>- Smart command completion, try tab everywhere.
>- Support runing local system commands.
>
> In latest 0.5 version, it supports checking your dvr configuration and
> running states, e.g., on a compute node, I run 'dvr check' command, then it
> will automatically check the configuration files, bridges, ports, network
> spaces, iptables rules,... like
>
>  No type given, guessing...compute node
> === Checking DVR on compute node ===
> >>> Checking config files...
> # Checking file = /etc/sysctl.conf...
> # Checking file = /etc/neutron/neutron.conf...
> # Checking file = /etc/neutron/plugins/ml2/ml2_conf.ini...
> file /etc/neutron/plugins/ml2/ml2_conf.ini Not has [agent]
> file /etc/neutron/plugins/ml2/ml2_conf.ini Not has l2_population = True
> file /etc/neutron/plugins/ml2/ml2_conf.ini Not has
> enable_distributed_routing = True
> file /etc/neutron/plugins/ml2/ml2_conf.ini Not has arp_responder = True
> # Checking file = /etc/neutron/l3_agent.ini...
> <<< Checking config files has warnings
>
> >>> Checking bridges...
> # Existing bridges are br-tun, br-int, br-eno1, br-ex
> # Vlan bridge is at br-tun, br-int, br-eno1, br-ex
> <<< Checking bridges passed
>
> >>> Checking vports ...
> ## Checking router port = qr-b0142af2-12
> ### Checking rfp port rfp-f046c591-7
> Found associated floating ips : 172.29.161.127/32, 172.29.161.126/32
> ### Checking associated fpr port fpr-f046c591-7
> ### Check related fip_ns=fip-9e1c850d-e424-4379-8ebd-278ae995d5c3
> Bridging in the same subnet
> fg port is attached to br-ex
> floating ip 172.29.161.127 match fg subnet
> floating ip 172.29.161.126 match fg subnet
> Checking chain rule number: neutron-postrouting-bottom...Passed
> Checking chain rule number: OUTPUT...Passed
> Checking chain rule number: neutron-l3-agent-snat...Passed
> Checking chain rules: neutron-postrouting-bottom...Passed
> Checking chain rules: PREROUTING...Passed
> Checking chain rules: OUTPUT...Passed
> Checking chain rules: POSTROUTING...Passed
> Checking chain rules: POSTROUTING...Passed
> Checking chain rules: neutron-l3-agent-POSTROUTING...Passed
> Checking chain rules: neutron-l3-agent-PREROUTING...Passed
> Checking chain rules: neutron-l3-agent-OUTPUT...Passed
> DNAT for incoming: 172.29.161.127 --> 10.0.0.3 passed
> Checking chain rules: neutron-l3-agent-float-snat...Passed
> SNAT for outgoing: 10.0.0.3 --> 172.29.161.127 passed
> Checking chain rules: neutron-l3-agent-OUTPUT...Passed
> DNAT for incoming: 172.29.161.126 --> 10.0.0.216 passed
> Checking chain rules: neutron-l3-agent-float-snat...Passed
> SNAT for outgoing: 10.0.0.216 --> 172.29.161.126 passed
> ## Checking router port = qr-8c41bfc7-56
> Checking passed already
> <<< Checking vports passed
>
>
> Welcome for any feedback, and welcome for any contribution!
>
> I am trying to put this project into stackforge to let more people can use
> and improve it, any thoughts if it is suitable?
>
> https://review.openstack.org/#/c/212396/
>
> Thanks for any help or suggestion!
>
>
> --
> Best wishes!
> Baohua
>
> __
> 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

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

[Vikas Choudhary]

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


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 VM2 via DVR but failed.
The tool should tell you that the packet is sent to the snat router and the
DVR router on the host VM1 residents is created with a wrong
route[dest=xx,nexthop=yy], and the right route should be dest=xx,nexthop=zz.
c.As a tool, I think if it should be simple. The best is no installation.
Copy and use it. Can you simple it? One of the possible method may
implement it using C/C++ and publish executable file.

BR,
Germy

On Fri, Aug 28, 2015 at 6:05 PM, Baohua Yang http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>>
wrote:

>* 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
*>* >, in summary, it can
*>>>*- Format the output and use color to make it clear and easy to compare.
*>*- Associate the OpenStack information (e.g., vm ip) on the virtual
*>*port or rule
*>*- Query openvswitch,iptables,namespace information in smart way.
*>*- Check if the DVR configuration is correct.
*>*- Smart command completion, try tab everywhere.
*>*- Support runing local system commands.
*>>* In latest 0.5 version, it supports checking your dvr configuration and
*>* running states, e.g., on a compute node, I run 'dvr check' command, then it
*>* will automatically check the configuration files, bridges, ports, network
*>* spaces, iptables rules,... like
*>>*  No type given, guessing...compute node
*>* === Checking DVR on compute node ===
*>* >>> Checking config files...
*>* # Checking file = /etc/sysctl.conf...
*>* # Checking file = /etc/neutron/neutron.conf...
*>* # Checking file = /etc/neutron/plugins/ml2/ml2_conf.ini...
*>* file /etc/neutron/plugins/ml2/ml2_conf.ini Not has [agent]
*>* file /etc/neutron/plugins/ml2/ml2_conf.ini Not has l2_population = True
*>* file /etc/neutron/plugins/ml2/ml2_conf.ini Not has
*>* enable_distributed_routing = True
*>* file /etc/neutron/plugins/ml2/ml2_conf.ini Not has arp_responder = True
*>* # Checking file = /etc/neutron/l3_agent.ini...
*>* <<< Checking config files has warnings
*>>* >>> Checking bridges...
*>* # Existing bridges are br-tun, br-int, br-eno1, br-ex
*>* # Vlan bridge is at br-tun, br-int, br-eno1, br-ex
*>* <<< Checking bridges passed
*>>* >>> Checking vports ...
*>* ## Checking router port = qr-b0142af2-12
*>* ### Checking rfp port rfp-f046c591-7
*>* Found associated floating ips : 172.29.161.127/32
, 172.29.161.126/32

*>* ### Checking associated fpr port fpr-f046c591-7
*>* ### Check related fip_ns=fip-9e1c850d-e424-4379-8ebd-278ae995d5c3
*>* Bridging in the same subnet
*>* fg port is attached to br-ex
*>* floating ip 172.29.161.127 match fg subnet
*>* floating ip 172.29.161.126 match fg subnet
*>* Checking chain rule number: neutron-postrouting-bottom...Passed
*>* Checking chain rule number: OUTPUT...Passed
*>* Checking chain rule number: neutron-l3-agent-snat...Passed
*>* Checking chain rules: neutron-postrouting-bottom...Passed
*>* Checking chain rules: PREROUTING...Passed
*>* Checking chain rules: OUTPUT...Passed
*>* Checking chain rules: POSTROUTING...Passed
*>* Checking chain rules: POSTROUTING...Passed
*>* Checking chain rules: neutron-l3-agent-POSTROUTING...Passed
*>* Checking chain rules: neutron-l3-agent-PREROUTING...Passed
*>* Checking chain rules: neutron-l3-agent-OUTPUT...Passed
*>* DNAT for incoming: 172.29.161.127 --> 10.0.0.3 passed
*>* Checking chain rules: neutron-l3-agent-float-snat...Passed
*>* SNAT for outgoing: 10.0.0.3 --> 172.29.161.127 passed
*>* Checking chain rules: neutron-l3-agent-OUTPUT...Passed
*>* DNAT for incoming: 172.29.161.126 --> 10.0.0.216 passed
*>* Checking chain rules: neutron-l3-agent-float-snat...Passed
*>* SNAT for outgoing: 10.0.0.216 --> 172.29.161.126 passed
*>* ## Checking router port = qr-8c41bfc7-56
*>* Checking passed already
*>* <<< Checking vports passed
*>>>* Welcome for any feedback, and welcome for any contribution!
*>>* I am trying to put this project into stackforge to let more people can use
*>* and improve it, any thoughts if it is 

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

[Baohua Yang]

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 https://github.com/yeasy/easyOVS
https://github.com/yeasy/easyOVSeasyOVS https://github.com/yeasy/easyOVS,
in summary, it can


   - Format the output and use color to make it clear and easy to compare.
   - Associate the OpenStack information (e.g., vm ip) on the virtual port
   or rule
   - Query openvswitch,iptables,namespace information in smart way.
   - Check if the DVR configuration is correct.
   - Smart command completion, try tab everywhere.
   - Support runing local system commands.

In latest 0.5 version, it supports checking your dvr configuration and
running states, e.g., on a compute node, I run 'dvr check' command, then it
will automatically check the configuration files, bridges, ports, network
spaces, iptables rules,... like

 No type given, guessing...compute node
=== Checking DVR on compute node ===
 Checking config files...
# Checking file = /etc/sysctl.conf...
# Checking file = /etc/neutron/neutron.conf...
# Checking file = /etc/neutron/plugins/ml2/ml2_conf.ini...
file /etc/neutron/plugins/ml2/ml2_conf.ini Not has [agent]
file /etc/neutron/plugins/ml2/ml2_conf.ini Not has l2_population = True
file /etc/neutron/plugins/ml2/ml2_conf.ini Not has
enable_distributed_routing = True
file /etc/neutron/plugins/ml2/ml2_conf.ini Not has arp_responder = True
# Checking file = /etc/neutron/l3_agent.ini...
 Checking config files has warnings

 Checking bridges...
# Existing bridges are br-tun, br-int, br-eno1, br-ex
# Vlan bridge is at br-tun, br-int, br-eno1, br-ex
 Checking bridges passed

 Checking vports ...
## Checking router port = qr-b0142af2-12
### Checking rfp port rfp-f046c591-7
Found associated floating ips : 172.29.161.127/32, 172.29.161.126/32
### Checking associated fpr port fpr-f046c591-7
### Check related fip_ns=fip-9e1c850d-e424-4379-8ebd-278ae995d5c3
Bridging in the same subnet
fg port is attached to br-ex
floating ip 172.29.161.127 match fg subnet
floating ip 172.29.161.126 match fg subnet
Checking chain rule number: neutron-postrouting-bottom...Passed
Checking chain rule number: OUTPUT...Passed
Checking chain rule number: neutron-l3-agent-snat...Passed
Checking chain rules: neutron-postrouting-bottom...Passed
Checking chain rules: PREROUTING...Passed
Checking chain rules: OUTPUT...Passed
Checking chain rules: POSTROUTING...Passed
Checking chain rules: POSTROUTING...Passed
Checking chain rules: neutron-l3-agent-POSTROUTING...Passed
Checking chain rules: neutron-l3-agent-PREROUTING...Passed
Checking chain rules: neutron-l3-agent-OUTPUT...Passed
DNAT for incoming: 172.29.161.127 -- 10.0.0.3 passed
Checking chain rules: neutron-l3-agent-float-snat...Passed
SNAT for outgoing: 10.0.0.3 -- 172.29.161.127 passed
Checking chain rules: neutron-l3-agent-OUTPUT...Passed
DNAT for incoming: 172.29.161.126 -- 10.0.0.216 passed
Checking chain rules: neutron-l3-agent-float-snat...Passed
SNAT for outgoing: 10.0.0.216 -- 172.29.161.126 passed
## Checking router port = qr-8c41bfc7-56
Checking passed already
 Checking vports passed


Welcome for any feedback, and welcome for any contribution!

I am trying to put this project into stackforge to let more people can use
and improve it, any thoughts if it is suitable?

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

Thanks for any help or suggestion!


-- 
Best wishes!
Baohua
__
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][dvr] DVR L2 agent is removing the br-int OVS flows

[Korzeniewski, Artur]

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 '''Setup up initial dvr flows into br-int'''
202 if not self.in_distributed_mode():
203 return
204
205 LOG.info(_LI(L2 Agent operating in DVR Mode with MAC %s),
206  self.dvr_mac_address)
207 # Remove existing flows in integration bridge
208 self.int_br.delete_flows()

This is kind of bummer when seeing the effort to preserve the flows in [1].
This should not affect VM network access, since the br-tun is configured 
properly and br-int is in learning mode.

Should this be fixed in Liberty cycle?

This is something similar to submitted bug: 
https://bugs.launchpad.net/neutron/+bug/1436156

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

Regards,
Artur Korzeniewski

Intel Technology Poland sp. z o.o.
KRS 101882
ul. Slowackiego 173, 80-298 Gdansk

__
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][dvr] DVR L2 agent is removing the br-int OVS flows

[Anna Kamyshnikova]

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, 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 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 '''Setup up initial dvr flows into br-int'''

 202 if not self.in_distributed_mode():

 203 return

 204

 205 LOG.info(_LI(L2 Agent operating in DVR Mode with MAC %s),

 206  self.dvr_mac_address)

 207 # Remove existing flows in integration bridge

 208 self.int_br.delete_flows()



 This is kind of bummer when seeing the effort to preserve the flows in
 [1].

 This should not affect VM network access, since the br-tun is configured
 properly and br-int is in learning mode.



 Should this be fixed in Liberty cycle?



 This is something similar to submitted bug:
 https://bugs.launchpad.net/neutron/+bug/1436156



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



 Regards,

 Artur Korzeniewski

 

 Intel Technology Poland sp. z o.o.

 KRS 101882

 ul. Slowackiego 173, 80-298 Gdansk



 __
 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




 --
 Regards,
 Ann Kamyshnikova
 Mirantis, Inc




-- 
Regards,
Ann Kamyshnikova
Mirantis, Inc
__
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][dvr] DVR L2 agent is removing the br-int OVS flows

[Anna Kamyshnikova]

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 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 '''Setup up initial dvr flows into br-int'''

 202 if not self.in_distributed_mode():

 203 return

 204

 205 LOG.info(_LI(L2 Agent operating in DVR Mode with MAC %s),

 206  self.dvr_mac_address)

 207 # Remove existing flows in integration bridge

 208 self.int_br.delete_flows()



 This is kind of bummer when seeing the effort to preserve the flows in [1].

 This should not affect VM network access, since the br-tun is configured
 properly and br-int is in learning mode.



 Should this be fixed in Liberty cycle?



 This is something similar to submitted bug:
 https://bugs.launchpad.net/neutron/+bug/1436156



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



 Regards,

 Artur Korzeniewski

 

 Intel Technology Poland sp. z o.o.

 KRS 101882

 ul. Slowackiego 173, 80-298 Gdansk



 __
 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




-- 
Regards,
Ann Kamyshnikova
Mirantis, Inc
__
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][dvr][ha] DVR-HA router is not working.

[Korzeniewski, Artur]

I have checked that:
1) the router_gateway is configured properly on network node (in namespace and 
in OVS), but the port is not reported as UP to controller node. Also, the ARP 
is not performed so no-one from external network is aware of the gateway 
address. When I ping from the GW to external host, the host knows where the GW 
IP is and can ping back.

2) The distributed snat port is created in namespace and IP is configured, but 
port is not reported as UP to controller, and there is no connectivity with 
other VMs inside the tenant network, maybe the port is not configured properly 
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 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.commailto:artur.korzeniew...@intel.com wrote:
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 agent
Devstack-36 – network node (SNAT)
Devstack-37 – network node 2 (SNAT)

External interface (router_gateway) is down for created dvr-ha router. The snat 
port (router_centralized_snat) is also down after connecting the tenant network.
I’m not sure where is the problem, can someone look at the logs and point me 
the place where to look for the answer why the ports are not reported as UP?
Add default gateway for DVR-HA router, log from active network node: 
http://pastebin.com/S7rYpDns
Add default gateway for DVR-HA router, log from neutron server node: 
http://pastebin.com/WpcV1g09

The external gateway IP is not reachable from external network, and VMs are not 
able to ping default gateway  (10.2.2.1)…
I have to add, that on the same setup the usual DVR router is working fine 
(hosted on the same network node)

[1] https://review.openstack.org/#/c/196893
[2] https://review.openstack.org/#/c/143169

Regards,
Artur Korzeniewski

Intel Technology Poland sp. z o.o.
KRS 101882
ul. Slowackiego 173, 80-298 Gdansk


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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

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

[Assaf Muller]

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

 Devstack-36 – network node (SNAT)

 Devstack-37 – network node 2 (SNAT)



 External interface (router_gateway) is down for created dvr-ha router. The
 snat port (router_centralized_snat) is also down after connecting the
 tenant network.

 I’m not sure where is the problem, can someone look at the logs and point
 me the place where to look for the answer why the ports are not reported as
 UP?

 Add default gateway for DVR-HA router, log from active network node:
 http://pastebin.com/S7rYpDns

 Add default gateway for DVR-HA router, log from neutron server node:
 http://pastebin.com/WpcV1g09



 The external gateway IP is not reachable from external network, and VMs
 are not able to ping default gateway  (10.2.2.1)…

 I have to add, that on the same setup the usual DVR router is working fine
 (hosted on the same network node)



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

 [2] https://review.openstack.org/#/c/143169



 Regards,

 Artur Korzeniewski

 

 Intel Technology Poland sp. z o.o.

 KRS 101882

 ul. Slowackiego 173, 80-298 Gdansk



 __
 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][dvr][ha] DVR-HA router is not working.

[Korzeniewski, Artur]

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 agent
Devstack-36 - network node (SNAT)
Devstack-37 - network node 2 (SNAT)

External interface (router_gateway) is down for created dvr-ha router. The snat 
port (router_centralized_snat) is also down after connecting the tenant network.
I'm not sure where is the problem, can someone look at the logs and point me 
the place where to look for the answer why the ports are not reported as UP?
Add default gateway for DVR-HA router, log from active network node: 
http://pastebin.com/S7rYpDns
Add default gateway for DVR-HA router, log from neutron server node: 
http://pastebin.com/WpcV1g09

The external gateway IP is not reachable from external network, and VMs are not 
able to ping default gateway  (10.2.2.1)...
I have to add, that on the same setup the usual DVR router is working fine 
(hosted on the same network node)

[1] https://review.openstack.org/#/c/196893
[2] https://review.openstack.org/#/c/143169

Regards,
Artur Korzeniewski

Intel Technology Poland sp. z o.o.
KRS 101882
ul. Slowackiego 173, 80-298 Gdansk

__
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][dvr] Removing fip namespace when restarting L3 agent.

[Korzeniewski, Artur]

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 namespace when 
restarting L3 agent.



On Thu, Aug 6, 2015 at 5:23 PM, Korzeniewski, Artur 
artur.korzeniew...@intel.commailto:artur.korzeniew...@intel.com wrote:
Thanks Kevin for that hint.
But it does not resolve the connectivity problem, it is just not removing the 
namespace when it is asked to.
The real question is, why do we invoke the 
/neutron/neutron/agent/l3/dvr_fip_ns.py FipNamespace.delete() method in the 
first place?

I’ve captured the traceback for this situation:
2015-08-06 06:35:28.469 DEBUG neutron.agent.linux.utils [-] Unable to access 
/opt/openstack/data/neutron/external/pids/8223e12e-837b-49d4-9793-63603fccbc9f.pid
 from (pid=70216) get_value_from_file 
/opt/openstack/neutron/neutron/agent/linux/utils.py:222
2015-08-06 06:35:28.469 DEBUG neutron.agent.linux.utils [-] Unable to access 
/opt/openstack/data/neutron/external/pids/8223e12e-837b-49d4-9793-63603fccbc9f.pid
 from (pid=70216) get_value_from_file 
/opt/openstack/neutron/neutron/agent/linux/utils.py:222
2015-08-06 06:35:28.469 DEBUG neutron.agent.linux.external_process [-] No 
process started for 8223e12e-837b-49d4-9793-63603fccbc9f from (pid=70216) 
disable /opt/openstack/neutron/neutron/agent/linux/external_process.py:113
Traceback (most recent call last):
 File /usr/local/lib/python2.7/dist-packages/eventlet/queue.py, line 117, in 
switch
self.greenlet.switch(value)
  File /usr/local/lib/python2.7/dist-packages/eventlet/greenthread.py, line 
214, in main
result = function(*args, **kwargs)
  File /usr/local/lib/python2.7/dist-packages/oslo_service/service.py, line 
612, in run_service
service.start()
  File /opt/openstack/neutron/neutron/service.py, line 233, in start
self.manager.after_start()
  File /opt/openstack/neutron/neutron/agent/l3/agent.py, line 641, in 
after_start
self.periodic_sync_routers_task(self.context)
  File /opt/openstack/neutron/neutron/agent/l3/agent.py, line 519, in 
periodic_sync_routers_task
self.fetch_and_sync_all_routers(context, ns_manager)
  File /opt/openstack/neutron/neutron/agent/l3/namespace_manager.py, line 91, 
in __exit__
self._cleanup(_ns_prefix, ns_id)
  File /opt/openstack/neutron/neutron/agent/l3/namespace_manager.py, line 
140, in _cleanup
ns.delete()
  File /opt/openstack/neutron/neutron/agent/l3/dvr_fip_ns.py, line 147, in 
delete
raise TypeError(ss)
TypeError: ss

It seems that the fip namespace is not processed at startup of L3 agent, and 
the cleanup is removing the namespace…
It is also removing the interface to local dvr router connection so… VM has no 
internet access with floating IP:
Command: ['ip', 'netns', 'exec', 'fip-8223e12e-837b-49d4-9793-63603fccbc9f', 
'ip', 'link', 'del', u'fpr-fe517b4b-d']

If the interface 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-837b-49d4-9793-63603fccbc9f.pid

I think yes, we can consider it a bug. Can you please file one? I can take and 
probably fix it.


And after finishing the sync loop, the fip namespace is deleted…

Regards,
Artur

From: Kevin Benton [mailto:blak...@gmail.commailto:blak...@gmail.com]
Sent: Thursday, August 6, 2015 7:40 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: 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.commailto:artur.korzeniew...@intel.com wrote:
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 fip ns: fip-8223e12e-837b-49d4-9793-63603fccbc9f from (pid=156888) 
delete /opt/openstack/neutron/neutron/agent/l3/dvr_fip_ns.py:164

Can someone explain why the fip namespace is deleted? Can we workout the 
situation, when there is no downtime of VM access?

Artur Korzeniewski

Intel Technology Poland sp. z o.o.
KRS 101882
ul. Slowackiego 173, 80-298 Gdansk


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org

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

[Oleg Bondarev]

On Fri, Aug 7, 2015 at 10:24 AM, Korzeniewski, Artur 
artur.korzeniew...@intel.com wrote:

 Bug submitted:

 https://bugs.launchpad.net/neutron/+bug/1482521


Ok, here is the fix: https://review.openstack.org/210539
Thanks!

Oleg




 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 namespace when
 restarting L3 agent.







 On Thu, Aug 6, 2015 at 5:23 PM, Korzeniewski, Artur 
 artur.korzeniew...@intel.com wrote:

 Thanks Kevin for that hint.

 But it does not resolve the connectivity problem, it is just not removing
 the namespace when it is asked to.

 The real question is, why do we invoke the 
 /neutron/neutron/agent/l3/dvr_fip_ns.py
 FipNamespace.delete() method in the first place?



 I’ve captured the traceback for this situation:

 2015-08-06 06:35:28.469 DEBUG neutron.agent.linux.utils [-] Unable to
 access
 /opt/openstack/data/neutron/external/pids/8223e12e-837b-49d4-9793-63603fccbc9f.pid
 from (pid=70216) get_value_from_file
 /opt/openstack/neutron/neutron/agent/linux/utils.py:222

 2015-08-06 06:35:28.469 DEBUG neutron.agent.linux.utils [-] Unable to
 access
 /opt/openstack/data/neutron/external/pids/8223e12e-837b-49d4-9793-63603fccbc9f.pid
 from (pid=70216) get_value_from_file
 /opt/openstack/neutron/neutron/agent/linux/utils.py:222

 2015-08-06 06:35:28.469 DEBUG neutron.agent.linux.external_process [-] No
 process started for 8223e12e-837b-49d4-9793-63603fccbc9f from (pid=70216)
 disable /opt/openstack/neutron/neutron/agent/linux/external_process.py:113

 Traceback (most recent call last):

  File /usr/local/lib/python2.7/dist-packages/eventlet/queue.py, line
 117, in switch

 self.greenlet.switch(value)

   File /usr/local/lib/python2.7/dist-packages/eventlet/greenthread.py,
 line 214, in main

 result = function(*args, **kwargs)

   File /usr/local/lib/python2.7/dist-packages/oslo_service/service.py,
 line 612, in run_service

 service.start()

   File /opt/openstack/neutron/neutron/service.py, line 233, in start

 self.manager.after_start()

   File /opt/openstack/neutron/neutron/agent/l3/agent.py, line 641, in
 after_start

 self.periodic_sync_routers_task(self.context)

   File /opt/openstack/neutron/neutron/agent/l3/agent.py, line 519, in
 periodic_sync_routers_task

 self.fetch_and_sync_all_routers(context, ns_manager)

   File /opt/openstack/neutron/neutron/agent/l3/namespace_manager.py,
 line 91, in __exit__

 self._cleanup(_ns_prefix, ns_id)

   File /opt/openstack/neutron/neutron/agent/l3/namespace_manager.py,
 line 140, in _cleanup

 ns.delete()

   File /opt/openstack/neutron/neutron/agent/l3/dvr_fip_ns.py, line 147,
 in delete

 raise TypeError(ss)

 TypeError: ss



 It seems that the fip namespace is not processed at startup of L3 agent,
 and the cleanup is removing the namespace…

 It is also removing the interface to local dvr router connection so… VM
 has no internet access with floating IP:

 Command: ['ip', 'netns', 'exec',
 'fip-8223e12e-837b-49d4-9793-63603fccbc9f', 'ip', 'link', 'del',
 u'fpr-fe517b4b-d']



 If the interface 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-837b-49d4-9793-63603fccbc9f.pid



 I think yes, we can consider it a bug. Can you please file one? I can take
 and probably fix it.





 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)
 *Subject:* 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 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 fip ns: fip-8223e12e-837b-49d4-9793-63603fccbc9f from
 (pid=156888) delete
 /opt/openstack/neutron/neutron/agent/l3/dvr_fip_ns.py:164



 Can someone explain why the fip namespace is deleted? Can we workout the
 situation, when there is no downtime of VM access?



 Artur Korzeniewski

 

 Intel Technology Poland sp. z o.o.

 KRS 101882

 ul. Slowackiego 173, 80-298 Gdansk

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

[Korzeniewski, Artur]

Thanks Kevin for that hint.
But it does not resolve the connectivity problem, it is just not removing the 
namespace when it is asked to.
The real question is, why do we invoke the 
/neutron/neutron/agent/l3/dvr_fip_ns.py FipNamespace.delete() method in the 
first place?

I’ve captured the traceback for this situation:
2015-08-06 06:35:28.469 DEBUG neutron.agent.linux.utils [-] Unable to access 
/opt/openstack/data/neutron/external/pids/8223e12e-837b-49d4-9793-63603fccbc9f.pid
 from (pid=70216) get_value_from_file 
/opt/openstack/neutron/neutron/agent/linux/utils.py:222
2015-08-06 06:35:28.469 DEBUG neutron.agent.linux.utils [-] Unable to access 
/opt/openstack/data/neutron/external/pids/8223e12e-837b-49d4-9793-63603fccbc9f.pid
 from (pid=70216) get_value_from_file 
/opt/openstack/neutron/neutron/agent/linux/utils.py:222
2015-08-06 06:35:28.469 DEBUG neutron.agent.linux.external_process [-] No 
process started for 8223e12e-837b-49d4-9793-63603fccbc9f from (pid=70216) 
disable /opt/openstack/neutron/neutron/agent/linux/external_process.py:113
Traceback (most recent call last):
 File /usr/local/lib/python2.7/dist-packages/eventlet/queue.py, line 117, in 
switch
self.greenlet.switch(value)
  File /usr/local/lib/python2.7/dist-packages/eventlet/greenthread.py, line 
214, in main
result = function(*args, **kwargs)
  File /usr/local/lib/python2.7/dist-packages/oslo_service/service.py, line 
612, in run_service
service.start()
  File /opt/openstack/neutron/neutron/service.py, line 233, in start
self.manager.after_start()
  File /opt/openstack/neutron/neutron/agent/l3/agent.py, line 641, in 
after_start
self.periodic_sync_routers_task(self.context)
  File /opt/openstack/neutron/neutron/agent/l3/agent.py, line 519, in 
periodic_sync_routers_task
self.fetch_and_sync_all_routers(context, ns_manager)
  File /opt/openstack/neutron/neutron/agent/l3/namespace_manager.py, line 91, 
in __exit__
self._cleanup(_ns_prefix, ns_id)
  File /opt/openstack/neutron/neutron/agent/l3/namespace_manager.py, line 
140, in _cleanup
ns.delete()
  File /opt/openstack/neutron/neutron/agent/l3/dvr_fip_ns.py, line 147, in 
delete
raise TypeError(ss)
TypeError: ss

It seems that the fip namespace is not processed at startup of L3 agent, and 
the cleanup is removing the namespace…
It is also removing the interface to local dvr router connection so… VM has no 
internet access with floating IP:
Command: ['ip', 'netns', 'exec', 'fip-8223e12e-837b-49d4-9793-63603fccbc9f', 
'ip', 'link', 'del', u'fpr-fe517b4b-d']

If the interface 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-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)
Subject: 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.commailto:artur.korzeniew...@intel.com wrote:
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 fip ns: fip-8223e12e-837b-49d4-9793-63603fccbc9f from (pid=156888) 
delete /opt/openstack/neutron/neutron/agent/l3/dvr_fip_ns.py:164

Can someone explain why the fip namespace is deleted? Can we workout the 
situation, when there is no downtime of VM access?

Artur Korzeniewski

Intel Technology Poland sp. z o.o.
KRS 101882
ul. Slowackiego 173, 80-298 Gdansk


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Kevin Benton
__
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][dvr] Removing fip namespace when restarting L3 agent.

[Oleg Bondarev]

On Thu, Aug 6, 2015 at 5:23 PM, Korzeniewski, Artur 
artur.korzeniew...@intel.com wrote:

 Thanks Kevin for that hint.

 But it does not resolve the connectivity problem, it is just not removing
 the namespace when it is asked to.

 The real question is, why do we invoke the 
 /neutron/neutron/agent/l3/dvr_fip_ns.py
 FipNamespace.delete() method in the first place?



 I’ve captured the traceback for this situation:

 2015-08-06 06:35:28.469 DEBUG neutron.agent.linux.utils [-] Unable to
 access
 /opt/openstack/data/neutron/external/pids/8223e12e-837b-49d4-9793-63603fccbc9f.pid
 from (pid=70216) get_value_from_file
 /opt/openstack/neutron/neutron/agent/linux/utils.py:222

 2015-08-06 06:35:28.469 DEBUG neutron.agent.linux.utils [-] Unable to
 access
 /opt/openstack/data/neutron/external/pids/8223e12e-837b-49d4-9793-63603fccbc9f.pid
 from (pid=70216) get_value_from_file
 /opt/openstack/neutron/neutron/agent/linux/utils.py:222

 2015-08-06 06:35:28.469 DEBUG neutron.agent.linux.external_process [-] No
 process started for 8223e12e-837b-49d4-9793-63603fccbc9f from (pid=70216)
 disable /opt/openstack/neutron/neutron/agent/linux/external_process.py:113

 Traceback (most recent call last):

  File /usr/local/lib/python2.7/dist-packages/eventlet/queue.py, line
 117, in switch

 self.greenlet.switch(value)

   File /usr/local/lib/python2.7/dist-packages/eventlet/greenthread.py,
 line 214, in main

 result = function(*args, **kwargs)

   File /usr/local/lib/python2.7/dist-packages/oslo_service/service.py,
 line 612, in run_service

 service.start()

   File /opt/openstack/neutron/neutron/service.py, line 233, in start

 self.manager.after_start()

   File /opt/openstack/neutron/neutron/agent/l3/agent.py, line 641, in
 after_start

 self.periodic_sync_routers_task(self.context)

   File /opt/openstack/neutron/neutron/agent/l3/agent.py, line 519, in
 periodic_sync_routers_task

 self.fetch_and_sync_all_routers(context, ns_manager)

   File /opt/openstack/neutron/neutron/agent/l3/namespace_manager.py,
 line 91, in __exit__

 self._cleanup(_ns_prefix, ns_id)

   File /opt/openstack/neutron/neutron/agent/l3/namespace_manager.py,
 line 140, in _cleanup

 ns.delete()

   File /opt/openstack/neutron/neutron/agent/l3/dvr_fip_ns.py, line 147,
 in delete

 raise TypeError(ss)

 TypeError: ss



 It seems that the fip namespace is not processed at startup of L3 agent,
 and the cleanup is removing the namespace…

 It is also removing the interface to local dvr router connection so… VM
 has no internet access with floating IP:

 Command: ['ip', 'netns', 'exec',
 'fip-8223e12e-837b-49d4-9793-63603fccbc9f', 'ip', 'link', 'del',
 u'fpr-fe517b4b-d']



 If the interface 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-837b-49d4-9793-63603fccbc9f.pid


I think yes, we can consider it a bug. Can you please file one? I can take
and probably fix it.




 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)
 *Subject:* 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 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 fip ns: fip-8223e12e-837b-49d4-9793-63603fccbc9f from
 (pid=156888) delete
 /opt/openstack/neutron/neutron/agent/l3/dvr_fip_ns.py:164



 Can someone explain why the fip namespace is deleted? Can we workout the
 situation, when there is no downtime of VM access?



 Artur Korzeniewski

 

 Intel Technology Poland sp. z o.o.

 KRS 101882

 ul. Slowackiego 173, 80-298 Gdansk




 __
 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





 --

 Kevin Benton

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi

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

[Korzeniewski, Artur]

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 fip ns: fip-8223e12e-837b-49d4-9793-63603fccbc9f from (pid=156888) 
delete /opt/openstack/neutron/neutron/agent/l3/dvr_fip_ns.py:164

Can someone explain why the fip namespace is deleted? Can we workout the 
situation, when there is no downtime of VM access?

Artur Korzeniewski

Intel Technology Poland sp. z o.o.
KRS 101882
ul. Slowackiego 173, 80-298 Gdansk

__
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][dvr] Removing fip namespace when restarting L3 agent.

[Fox, Kevin M]

Thats troubling... We are considering using DVR soon, and we have to restart 
neutron-openvswitch-agent and openstack-nova-compute periodically go get them 
to talk to rabbit again

Thanks,
Kevin

From: Korzeniewski, Artur [artur.korzeniew...@intel.com]
Sent: 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 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 fip ns: fip-8223e12e-837b-49d4-9793-63603fccbc9f from (pid=156888) 
delete /opt/openstack/neutron/neutron/agent/l3/dvr_fip_ns.py:164

Can someone explain why the fip namespace is deleted? Can we workout the 
situation, when there is no downtime of VM access?

Artur Korzeniewski

Intel Technology Poland sp. z o.o.
KRS 101882
ul. Slowackiego 173, 80-298 Gdansk

__
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][dvr] Removing fip namespace when restarting L3 agent.

[Kevin Benton]

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 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 fip ns: fip-8223e12e-837b-49d4-9793-63603fccbc9f from
 (pid=156888) delete
 /opt/openstack/neutron/neutron/agent/l3/dvr_fip_ns.py:164



 Can someone explain why the fip namespace is deleted? Can we workout the
 situation, when there is no downtime of VM access?



 Artur Korzeniewski

 

 Intel Technology Poland sp. z o.o.

 KRS 101882

 ul. Slowackiego 173, 80-298 Gdansk



 __
 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




-- 
Kevin Benton
__
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]: DVR Presentation slides from the Vancouver summit

[Somanchi Trinath]

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 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/file/d/0B4kh-7VVPWlPYXNaQWxXd1NDdm8/view?usp=sharing

Please let me know if you have any questions.

thanks

Swaminathan Vasudevan
Systems Software Engineer (TC)


HP Networking
Hewlett-Packard
8000 Foothills Blvd
M/S 5541
Roseville, CA - 95747
tel: 916.785.0937
fax: 916.785.1815
email: swaminathan.vasude...@hp.commailto:swaminathan.vasude...@hp.com


__
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]: DVR Presentation slides from the Vancouver summit

[Vasudevan, Swaminathan (PNB Roseville)]

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/file/d/0B4kh-7VVPWlPYXNaQWxXd1NDdm8/view?usp=sharing

Please let me know if you have any questions.

thanks

Swaminathan Vasudevan
Systems Software Engineer (TC)


HP Networking
Hewlett-Packard
8000 Foothills Blvd
M/S 5541
Roseville, CA - 95747
tel: 916.785.0937
fax: 916.785.1815
email: swaminathan.vasude...@hp.commailto:swaminathan.vasude...@hp.com


__
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] DVR and l2_population

[Armando M.]

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 itz...@redhat.com wrote:

 Hi,

 In the Networking guide [1] there is a requirement for l2 population both
 as
 a mechanism driver and in OVS agent when enabling DVR.
 Is this is a requirement and if so what is the reason?

 Thanks,
 Itzik


 [1] http://docs.openstack.org/networking-guide/content/ha-dvr.html

 __
 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

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

[Itzik Brown]

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:

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 itz...@redhat.com 
mailto:itz...@redhat.com wrote:


Hi,

In the Networking guide [1] there is a requirement for l2
population both as
a mechanism driver and in OVS agent when enabling DVR.
Is this is a requirement and if so what is the reason?

Thanks,
Itzik


[1] http://docs.openstack.org/networking-guide/content/ha-dvr.html

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://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 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] DVR Slides from Paris Summit

[Andreas Scheuring]

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 slideshare or somewhere else? That would be great.

This is the link to the related video

https://www.openstack.org/summit/openstack-paris-summit-2014/session-videos/presentation/architectural-overview-of-distributed-virtual-routers-in-openstack-neutron



Thanks

-- 
Andreas 
(irc: scheuran)




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

[openstack-dev] [neutron] dvr l2 agent

[Li Tianqing]

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 with tagging the frame with green network’s local-vlan tag.




4 The tunnel bridge on CN1, replaces the frame’s source mac address with a 
Unique DVR MAC Address of its node (one unique dvr mac address is assigned per 
compute node by the controller). The resulting frame is forwarded to CN2 by 
this tunnel bridge. Before forwarding, it also strips the local green-vlan tag 
and tunnels the frame with green-vni VXLAN id.


  How it is possible to use vlan for tenant network, and also use vxlan tunnel 
for physical host to communicate? I think they should keep the same.





--

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

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

[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 jaze...@163.com wrote:

 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 henry4...@gmail.com wrote:

 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 jaze...@163.com 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_agent on all compute_node for North/South
 snat, dnat, and east/west l3 routing?




 --
 Best
 Li Tianqing


 ___
 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] dvr l3_snat

[Li Tianqing]

Thanks a lot, i really helps after i read  times :)




在 2014-11-07 16:08:50，Armando M. arma...@gmail.com 写道：

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 jaze...@163.com wrote:

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 henry4...@gmail.com wrote:

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 jaze...@163.com 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_agent on all compute_node for North/South snat, 
dnat, and east/west l3 routing? 





--

Best
Li Tianqing



___
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] dvr l3_snat

[Li Tianqing]

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___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Henry]

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 jaze...@163.com 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_agent on all compute_node for North/South snat, 
 dnat, and east/west l3 routing? 
 
 
 
 
 --
 Best
 Li Tianqing
 
 
 ___
 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] dvr l3_snat

[Li Tianqing]

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 henry4...@gmail.com wrote:

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 jaze...@163.com 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_agent on all compute_node for North/South snat, 
dnat, and east/west l3 routing? 





--

Best
Li Tianqing



___
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] dvr l3_snat

[Li Tianqing]

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 henry4...@gmail.com wrote:

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 jaze...@163.com 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_agent on all compute_node for North/South snat, 
dnat, and east/west l3 routing? 





--

Best
Li Tianqing



___
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][DVR] Openstack Juno: how to configure dvr in Network-Node and Compute-Node?

[Smith, Michael (HPN RD)]

Have you seen the “how-to” wiki page?
https://wiki.openstack.org/wiki/Neutron/DVR/HowTo
Yours,
Michael Smith
Hewlett-Packard Company
HP Networking RD
8000 Foothills Blvd. M/S 5557
Roseville, CA 95747
PC Phone: 916 540-1884
Ph: 916 785-0918
Fax: 916 785-1199

From: zhang xiaobin [mailto:14050...@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),

But how to configure it in network-node and compute-node. 
Openstack.orghttp://openstack.org/ just said router_distributed = True, 
which is far than enough.

could any help point to some detailed instruction on how to configure it?

When we were adding port, some errors from router reported errors like: 
AttributeError: 'Ml2Plugin' object has no attribute 'update_dvr_port_binding'

What's more, is this DVR per project, or per compute nodes?
Thanks in advance!


zhang xiaobin


本邮件（包括其附件）可能含有保密、专有或保留著作权的信息。如果您并非本邮件指定接受人，请即刻通知发送人并将本邮件从您的系统中删除，您不得散布、保留、复制、披露或以其他方式使用本邮件任何相关信息，并且通过邮件告知我们此次错误投递。发送人在本邮件下表达的观点并不一定代表苏宁云商集团股份有限公司的观点。苏宁云商集团股份有限公司并不保证本邮件是安全或不受任何计算机病毒影响的，并且对由于邮件传输而导致的邮件内容错误或缺失不承担任何责任。除非明确说明，本邮件并不构成具有约束力的契约。

This e-mail may contain confidential, copyright and/or privileged information. 
If you are not the addressee or authorized to receive this, please inform us of 
the erroneous delivery by return e-mail, and you should delete it from your 
system and may not use, copy, disclose or take any action based on this e-mail 
or any information herein. Any opinions expressed by sender hereof do not 
necessarily represent those of SUNING COMMERCE GROUP CO., LTD.,SUNING COMMERCE 
GROUP CO., LTD.,does not guarantee that this email is secure or free from 
viruses. No liability is accepted for any errors or omissions in the contents 
of this email, which arise as a result of email transmission. Unless expressly 
stated,this email is not intended to form a binding contract.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[zhang xiaobin]

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 on how to configure it?
When we were adding port, some errors from router reported errors like: 
AttributeError: 'Ml2Plugin' object has no attribute 'update_dvr_port_binding'
What's more, is this DVR per project, or per compute nodes?
Thanks in advance!




zhang xiaobin
本邮件（包括其附件）可能含有保密、专有或保留著作权的信息。如果您并非本邮件指定接受人，请即刻通知发送人并将本邮件从您的系统中删除，您不得散布、保留、复制、披露或以其他方式使用本邮件任何相关信息，并且通过邮件告知我们此次错误投递。发送人在本邮件下表达的观点并不一定代表苏宁云商集团股份有限公司的观点。苏宁云商集团股份有限公司并不保证本邮件是安全或不受任何计算机病毒影响的，并且对由于邮件传输而导致的邮件内容错误或缺失不承担任何责任。除非明确说明，本邮件并不构成具有约束力的契约。

This e-mail may contain confidential, copyright and/or privileged information. 
If you are not the addressee or authorized to receive this, please inform us of 
the erroneous delivery by return e-mail, and you should delete it from your 
system and may not use, copy, disclose or take any action based on this e-mail 
or any information herein. Any opinions expressed by sender hereof do not 
necessarily represent those of SUNING COMMERCE GROUP CO., LTD.,SUNING COMMERCE 
GROUP CO., LTD.,does not guarantee that this email is secure or free from 
viruses. No liability is accepted for any errors or omissions in the contents 
of this email, which arise as a result of email transmission. Unless expressly 
stated,this email is not intended to form a binding contract.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Narasimhan, Vivekanandan]

Hi Kevin,



Typically we noticed that the underlay switches maintained a table like this:



VLAN IDMAC Address  Learned-Interface



In the physical underlay, with the current architecture if we enable VLAN, the 
same DVR Unique

MAC will appear  on different VLANs as the packets get DVR Routed.



This will result in the rows of the above tables in the switch to be updated 
very frequently with new

VLANs noted in incoming packets for the same DVR MAC Address, even though they 
are from the

same physical port.



We are not sure if all the switches maintained the tables this way , but 
atleast we

saw Openvswitch implementations did.  So we consciously did not promote VLANs 
for

initial phase of DVR.



--

Thanks,



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



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, Sep 17, 2014 at 12:41 PM, Armando M. 
arma...@gmail.commailto:arma...@gmail.com wrote:

VLAN is on the radar, vxlan/gre was done to start with.

I believe Vivek mentioned the rationale in some other thread. The gist
of it below:

In the current architecture, we use a unique DVR MAC per compute node
to forward DVR Routed traffic directly to destination compute node.
The DVR routed traffic from the source compute node will carry
'destination VMs underlay VLAN' in the frame, but the Source Mac in
that same frame will be the DVR Unique MAC. So, same DVR Unique Mac is
used for potentially a number of overlay network VMs that would exist
on that same source compute node.

The underlay infrastructure switches will see the same DVR Unique MAC
being associated with different VLANs on incoming frames, and so this
would result in VLAN Thrashing on the switches in the physical cloud
infrastructure. Since tunneling protocols carry the entire DVR routed
inner frames as tunnel payloads, there is no thrashing effect on
underlay switches.

There will still be thrashing effect on endpoints on CNs themselves,
when they try to learn that association between inner frame source MAC
and the TEP port on which the tunneled frame is received. But that we
have addressed in L2 Agent by having a 'DVR Learning Blocker' table,
which ensures that learning for DVR routed packets alone is
side-stepped.

As a result, VLAN was not promoted as a supported underlay for the
initial DVR architecture.

Cheers,
Armando


On 16 September 2014 20:35, 龚永生 
gong...@unitedstack.commailto:gong...@unitedstack.com wrote:
 I think the VLAN should also be supported later.  The tunnel should not be
 the prerequisite for the DVR feature.


 -- Original --
 From:  Steve Wormleyopenst...@wormley.commailto:openst...@wormley.com;
 Date:  Wed, Sep 17, 2014 10:29 AM
 To:  
 openstack-devopenstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org;
 Subject:  [openstack-dev] [neutron] DVR Tunnel Design Question

 In our environment using VXLAN/GRE would make it difficult to keep some of
 the features we currently offer our customers. So for a while now I've been
 looking at the DVR code, blueprints and Google drive docs and other than it
 being the way the code was written I can't find anything indicating why a
 Tunnel/Overlay network is required for DVR or what problem it was solving.

 Basically I'm just trying to see if I missed anything as I look into doing a
 VLAN/OVS implementation.

 Thanks,
 -Steve Wormley



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


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







--

Kevin Benton

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

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

[Kevin Benton]

This sounds like a bug in Openvswitch. The unique constraint should be
VLAN+MAC instead of just VLAN, so observing the same MAC on a new VLAN
should just result in a new entry without the old one being ejected.

Without this behavior, it will also break transparent L2 firewalls.
For example (diagram below), if you divide a switch into two VLANs and
then connect the sides together with a firewall in the middle that
passes frames without modifying the MAC, the switch will see the same
MAC on different VLANs. Based on the behavior you described, this
wouldn't work. Is that correct?


-
|  x  x  x  x   |   x  x  x  x  |
|---|-
 VLAN 1 | |  VLAN2
  
  |   Firewall  |
  

On Wed, Sep 17, 2014 at 11:19 PM, Narasimhan, Vivekanandan
vivekanandan.narasim...@hp.com wrote:
 Hi Kevin,



 Typically we noticed that the underlay switches maintained a table like
 this:



 VLAN IDMAC Address  Learned-Interface



 In the physical underlay, with the current architecture if we enable VLAN,
 the same DVR Unique

 MAC will appear  on different VLANs as the packets get DVR Routed.



 This will result in the rows of the above tables in the switch to be updated
 very frequently with new

 VLANs noted in incoming packets for the same DVR MAC Address, even though
 they are from the

 same physical port.



 We are not sure if all the switches maintained the tables this way , but
 atleast we

 saw Openvswitch implementations did.  So we consciously did not promote
 VLANs for

 initial phase of DVR.



 --

 Thanks,



 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



 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, Sep 17, 2014 at 12:41 PM, Armando M. arma...@gmail.com wrote:

 VLAN is on the radar, vxlan/gre was done to start with.

 I believe Vivek mentioned the rationale in some other thread. The gist
 of it below:

 In the current architecture, we use a unique DVR MAC per compute node
 to forward DVR Routed traffic directly to destination compute node.
 The DVR routed traffic from the source compute node will carry
 'destination VMs underlay VLAN' in the frame, but the Source Mac in
 that same frame will be the DVR Unique MAC. So, same DVR Unique Mac is
 used for potentially a number of overlay network VMs that would exist
 on that same source compute node.

 The underlay infrastructure switches will see the same DVR Unique MAC
 being associated with different VLANs on incoming frames, and so this
 would result in VLAN Thrashing on the switches in the physical cloud
 infrastructure. Since tunneling protocols carry the entire DVR routed
 inner frames as tunnel payloads, there is no thrashing effect on
 underlay switches.

 There will still be thrashing effect on endpoints on CNs themselves,
 when they try to learn that association between inner frame source MAC
 and the TEP port on which the tunneled frame is received. But that we
 have addressed in L2 Agent by having a 'DVR Learning Blocker' table,
 which ensures that learning for DVR routed packets alone is
 side-stepped.

 As a result, VLAN was not promoted as a supported underlay for the
 initial DVR architecture.

 Cheers,
 Armando


 On 16 September 2014 20:35, 龚永生 gong...@unitedstack.com wrote:
 I think the VLAN should also be supported later.  The tunnel should not be
 the prerequisite for the DVR feature.


 -- Original --
 From:  Steve Wormleyopenst...@wormley.com;
 Date:  Wed, Sep 17, 2014 10:29 AM
 To:  openstack-devopenstack-dev@lists.openstack.org;
 Subject:  [openstack-dev] [neutron] DVR Tunnel Design Question

 In our environment using VXLAN/GRE would make it difficult to keep some of
 the features we currently offer our customers. So for a while now I've
 been
 looking at the DVR code, blueprints and Google drive docs and other than
 it
 being the way the code was written I can't find anything indicating why a
 Tunnel/Overlay network is required for DVR or what problem it was solving.

 Basically I'm just trying to see if I missed anything as I look into doing
 a
 VLAN/OVS implementation.

 Thanks,
 -Steve Wormley



 ___
 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





 --

 Kevin Benton

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

[Narasimhan, Vivekanandan]

Yes... If I recollect, we were using 1.10.x version during that time (wherein 
discovered this 
as output of ovsapp-ctl fdb-show). After that I didn’t get time to re-verify on 
later
versions of openvswitch.

BTW, if this is not intended behaviour, then I donot see any particular reason 
why VLANs
need not be enabled in the current DVR architecture.  

To enable dvr, I need to post a minor patch in L2 agent to bring-in 
DVR rules into Phys bridges (as VLANs are driven by phys bridges 
in 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] 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 same MAC on a new VLAN
should just result in a new entry without the old one being ejected.

Without this behavior, it will also break transparent L2 firewalls.
For example (diagram below), if you divide a switch into two VLANs and then 
connect the sides together with a firewall in the middle that passes frames 
without modifying the MAC, the switch will see the same MAC on different VLANs. 
Based on the behavior you described, this wouldn't work. Is that correct?


-
|  x  x  x  x   |   x  x  x  x  |
|---|-
 VLAN 1 | |  VLAN2
  
  |   Firewall  |
  

On Wed, Sep 17, 2014 at 11:19 PM, Narasimhan, Vivekanandan 
vivekanandan.narasim...@hp.com wrote:
 Hi Kevin,



 Typically we noticed that the underlay switches maintained a table 
 like
 this:



 VLAN IDMAC Address  Learned-Interface



 In the physical underlay, with the current architecture if we enable 
 VLAN, the same DVR Unique

 MAC will appear  on different VLANs as the packets get DVR Routed.



 This will result in the rows of the above tables in the switch to be 
 updated very frequently with new

 VLANs noted in incoming packets for the same DVR MAC Address, even 
 though they are from the

 same physical port.



 We are not sure if all the switches maintained the tables this way , 
 but atleast we

 saw Openvswitch implementations did.  So we consciously did not 
 promote VLANs for

 initial phase of DVR.



 --

 Thanks,



 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



 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, Sep 17, 2014 at 12:41 PM, Armando M. arma...@gmail.com wrote:

 VLAN is on the radar, vxlan/gre was done to start with.

 I believe Vivek mentioned the rationale in some other thread. The gist 
 of it below:

 In the current architecture, we use a unique DVR MAC per compute node 
 to forward DVR Routed traffic directly to destination compute node.
 The DVR routed traffic from the source compute node will carry 
 'destination VMs underlay VLAN' in the frame, but the Source Mac in 
 that same frame will be the DVR Unique MAC. So, same DVR Unique Mac is 
 used for potentially a number of overlay network VMs that would exist 
 on that same source compute node.

 The underlay infrastructure switches will see the same DVR Unique MAC 
 being associated with different VLANs on incoming frames, and so this 
 would result in VLAN Thrashing on the switches in the physical cloud 
 infrastructure. Since tunneling protocols carry the entire DVR routed 
 inner frames as tunnel payloads, there is no thrashing effect on 
 underlay switches.

 There will still be thrashing effect on endpoints on CNs themselves, 
 when they try to learn that association between inner frame source MAC 
 and the TEP port on which the tunneled frame is received. But that we 
 have addressed in L2 Agent by having a 'DVR Learning Blocker' table, 
 which ensures that learning for DVR routed packets alone is 
 side-stepped.

 As a result, VLAN was not promoted as a supported underlay for the 
 initial DVR architecture.

 Cheers,
 Armando


 On 16 September 2014 20:35, 龚永生 gong...@unitedstack.com wrote:
 I think the VLAN should also be supported later.  The tunnel should 
 not be the prerequisite for the DVR feature.


 -- Original --
 From:  Steve Wormleyopenst...@wormley.com;
 Date:  Wed, Sep 17, 2014 10:29 AM
 To:  openstack-devopenstack-dev@lists.openstack.org;
 Subject:  [openstack-dev] [neutron] DVR Tunnel Design Question

 In our environment using VXLAN/GRE would make it difficult to keep 
 some of the features we currently offer our customers. So for a while 
 now

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

[Kevin Benton]

To enable dvr, I need to post a minor patch in L2 agent to bring-in
DVR rules into Phys bridges (as VLANs are driven by phys bridges
in OVS L2 Agent).

Great! You read my mind and answered my follow-up question. :-)
Let me know if there is anything I can help with.

On Thu, Sep 18, 2014 at 1:51 AM, Narasimhan, Vivekanandan
vivekanandan.narasim...@hp.com wrote:
 Yes... If I recollect, we were using 1.10.x version during that time (wherein 
 discovered this
 as output of ovsapp-ctl fdb-show). After that I didn’t get time to re-verify 
 on later
 versions of openvswitch.

 BTW, if this is not intended behaviour, then I donot see any particular 
 reason why VLANs
 need not be enabled in the current DVR architecture.

 To enable dvr, I need to post a minor patch in L2 agent to bring-in
 DVR rules into Phys bridges (as VLANs are driven by phys bridges
 in 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] 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 same MAC on a new VLAN
 should just result in a new entry without the old one being ejected.

 Without this behavior, it will also break transparent L2 firewalls.
 For example (diagram below), if you divide a switch into two VLANs and then 
 connect the sides together with a firewall in the middle that passes frames 
 without modifying the MAC, the switch will see the same MAC on different 
 VLANs. Based on the behavior you described, this wouldn't work. Is that 
 correct?


 -
 |  x  x  x  x   |   x  x  x  x  |
 |---|-
  VLAN 1 | |  VLAN2
   
   |   Firewall  |
   

 On Wed, Sep 17, 2014 at 11:19 PM, Narasimhan, Vivekanandan 
 vivekanandan.narasim...@hp.com wrote:
 Hi Kevin,



 Typically we noticed that the underlay switches maintained a table
 like
 this:



 VLAN IDMAC Address  Learned-Interface



 In the physical underlay, with the current architecture if we enable
 VLAN, the same DVR Unique

 MAC will appear  on different VLANs as the packets get DVR Routed.



 This will result in the rows of the above tables in the switch to be
 updated very frequently with new

 VLANs noted in incoming packets for the same DVR MAC Address, even
 though they are from the

 same physical port.



 We are not sure if all the switches maintained the tables this way ,
 but atleast we

 saw Openvswitch implementations did.  So we consciously did not
 promote VLANs for

 initial phase of DVR.



 --

 Thanks,



 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



 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, Sep 17, 2014 at 12:41 PM, Armando M. arma...@gmail.com wrote:

 VLAN is on the radar, vxlan/gre was done to start with.

 I believe Vivek mentioned the rationale in some other thread. The gist
 of it below:

 In the current architecture, we use a unique DVR MAC per compute node
 to forward DVR Routed traffic directly to destination compute node.
 The DVR routed traffic from the source compute node will carry
 'destination VMs underlay VLAN' in the frame, but the Source Mac in
 that same frame will be the DVR Unique MAC. So, same DVR Unique Mac is
 used for potentially a number of overlay network VMs that would exist
 on that same source compute node.

 The underlay infrastructure switches will see the same DVR Unique MAC
 being associated with different VLANs on incoming frames, and so this
 would result in VLAN Thrashing on the switches in the physical cloud
 infrastructure. Since tunneling protocols carry the entire DVR routed
 inner frames as tunnel payloads, there is no thrashing effect on
 underlay switches.

 There will still be thrashing effect on endpoints on CNs themselves,
 when they try to learn that association between inner frame source MAC
 and the TEP port on which the tunneled frame is received. But that we
 have addressed in L2 Agent by having a 'DVR Learning Blocker' table,
 which ensures that learning for DVR routed packets alone is
 side-stepped.

 As a result, VLAN was not promoted as a supported underlay for the
 initial DVR architecture.

 Cheers,
 Armando


 On 16 September 2014 20:35, 龚永生 gong...@unitedstack.com 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

[Armando M.]

VLAN is on the radar, vxlan/gre was done to start with.

I believe Vivek mentioned the rationale in some other thread. The gist
of it below:

In the current architecture, we use a unique DVR MAC per compute node
to forward DVR Routed traffic directly to destination compute node.
The DVR routed traffic from the source compute node will carry
'destination VMs underlay VLAN' in the frame, but the Source Mac in
that same frame will be the DVR Unique MAC. So, same DVR Unique Mac is
used for potentially a number of overlay network VMs that would exist
on that same source compute node.

The underlay infrastructure switches will see the same DVR Unique MAC
being associated with different VLANs on incoming frames, and so this
would result in VLAN Thrashing on the switches in the physical cloud
infrastructure. Since tunneling protocols carry the entire DVR routed
inner frames as tunnel payloads, there is no thrashing effect on
underlay switches.

There will still be thrashing effect on endpoints on CNs themselves,
when they try to learn that association between inner frame source MAC
and the TEP port on which the tunneled frame is received. But that we
have addressed in L2 Agent by having a 'DVR Learning Blocker' table,
which ensures that learning for DVR routed packets alone is
side-stepped.

As a result, VLAN was not promoted as a supported underlay for the
initial DVR architecture.

Cheers,
Armando

On 16 September 2014 20:35, 龚永生 gong...@unitedstack.com wrote:
 I think the VLAN should also be supported later.  The tunnel should not be
 the prerequisite for the DVR feature.


 -- Original --
 From:  Steve Wormleyopenst...@wormley.com;
 Date:  Wed, Sep 17, 2014 10:29 AM
 To:  openstack-devopenstack-dev@lists.openstack.org;
 Subject:  [openstack-dev] [neutron] DVR Tunnel Design Question

 In our environment using VXLAN/GRE would make it difficult to keep some of
 the features we currently offer our customers. So for a while now I've been
 looking at the DVR code, blueprints and Google drive docs and other than it
 being the way the code was written I can't find anything indicating why a
 Tunnel/Overlay network is required for DVR or what problem it was solving.

 Basically I'm just trying to see if I missed anything as I look into doing a
 VLAN/OVS implementation.

 Thanks,
 -Steve Wormley


 ___
 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] DVR Tunnel Design Question

[Kevin Benton]

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, Sep 17, 2014 at 12:41 PM, Armando M. arma...@gmail.com wrote:

 VLAN is on the radar, vxlan/gre was done to start with.

 I believe Vivek mentioned the rationale in some other thread. The gist
 of it below:

 In the current architecture, we use a unique DVR MAC per compute node
 to forward DVR Routed traffic directly to destination compute node.
 The DVR routed traffic from the source compute node will carry
 'destination VMs underlay VLAN' in the frame, but the Source Mac in
 that same frame will be the DVR Unique MAC. So, same DVR Unique Mac is
 used for potentially a number of overlay network VMs that would exist
 on that same source compute node.

 The underlay infrastructure switches will see the same DVR Unique MAC
 being associated with different VLANs on incoming frames, and so this
 would result in VLAN Thrashing on the switches in the physical cloud
 infrastructure. Since tunneling protocols carry the entire DVR routed
 inner frames as tunnel payloads, there is no thrashing effect on
 underlay switches.

 There will still be thrashing effect on endpoints on CNs themselves,
 when they try to learn that association between inner frame source MAC
 and the TEP port on which the tunneled frame is received. But that we
 have addressed in L2 Agent by having a 'DVR Learning Blocker' table,
 which ensures that learning for DVR routed packets alone is
 side-stepped.

 As a result, VLAN was not promoted as a supported underlay for the
 initial DVR architecture.

 Cheers,
 Armando

 On 16 September 2014 20:35, 龚永生 gong...@unitedstack.com wrote:
  I think the VLAN should also be supported later.  The tunnel should not
 be
  the prerequisite for the DVR feature.
 
 
  -- Original --
  From:  Steve Wormleyopenst...@wormley.com;
  Date:  Wed, Sep 17, 2014 10:29 AM
  To:  openstack-devopenstack-dev@lists.openstack.org;
  Subject:  [openstack-dev] [neutron] DVR Tunnel Design Question
 
  In our environment using VXLAN/GRE would make it difficult to keep some
 of
  the features we currently offer our customers. So for a while now I've
 been
  looking at the DVR code, blueprints and Google drive docs and other than
 it
  being the way the code was written I can't find anything indicating why a
  Tunnel/Overlay network is required for DVR or what problem it was
 solving.
 
  Basically I'm just trying to see if I missed anything as I look into
 doing a
  VLAN/OVS implementation.
 
  Thanks,
  -Steve Wormley
 
 
  ___
  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




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

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

[Steve Wormley]

In our environment using VXLAN/GRE would make it difficult to keep some of
the features we currently offer our customers. So for a while now I've been
looking at the DVR code, blueprints and Google drive docs and other than it
being the way the code was written I can't find anything indicating why a
Tunnel/Overlay network is required for DVR or what problem it was solving.

Basically I'm just trying to see if I missed anything as I look into doing
a VLAN/OVS implementation.

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

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 Wormleyopenst...@wormley.com;
Date:  Wed, Sep 17, 2014 10:29 AM
To:  openstack-devopenstack-dev@lists.openstack.org; 

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

 
In our environment using VXLAN/GRE would make it difficult to keep some of the 
features we currently offer our customers. So for a while now I've been looking 
at the DVR code, blueprints and Google drive docs and other than it being the 
way the code was written I can't find anything indicating why a Tunnel/Overlay 
network is required for DVR or what problem it was solving. 


Basically I'm just trying to see if I missed anything as I look into doing a 
VLAN/OVS implementation.


Thanks,

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

[openstack-dev] [neutron][DVR]: Will DVR support external gateway with snat disabled?

[Wuhongning]

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 other central service)? This will make sense if we want to have linux 
router as the NS gw to terminate all internal traffic, but leave all L4 
service(NAT/FW/VPN/LB) to some hardware device.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] dvr router modes?

[Robert Collins]

Excuse my ignorance here, but I'm hearing that dvr l3 agent will run
in two different modes - and that a typical deployment will want some
running in each: in a scaled all-in-one setup - say 3 nodes, galera,
rabbit, all our APIs, and nova-compute on each - would we then want to
run *two* l3 agents (one in dvr-snat mode, one in dvr mode) on each
node?

Isn't it possible to avoid this and have just one l3 dvr mode ?

-Rob

-- 
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud

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