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