Open Stack

Sorry, not good with neutron. Could you explain what "use a regular
segmentation identifer like the rest of the network" ? What is this
segmentation identifier ?


On Tue, Aug 26, 2014 at 3:07 PM, Kevin Benton <blak111 at gmail.com> wrote:

> No, the gateway_external_network_id option just refers to how your network
> is deployed. If the external network uses a regular segmentation identifier
> like the rest of the networks, this will work. If not, it won't because the
> instances will try to use a segmentation identifier.
>
> In other words, if you have a separate physical interface for external
> networks on your L3 agent nodes, this will not work.
> On Aug 26, 2014 12:14 PM, "Bao Wang" <bywang98 at gmail.com> wrote:
>
>> Just want to clarify something. this public ip as private ip is only for
>> external facing interfaces on a set of VM instances. At the same time, the
>> majority of interfaces on hte same set of VM instances will not have public
>> ip and their subnets are isolated networks. Will this change your
>> conclusion when you mentioned "the gateway_external_network_id is left
>> blank for the L3 agent" ?
>>
>>
>> On Mon, Aug 25, 2014 at 1:07 AM, Kevin Benton <blak111 at gmail.com> wrote:
>>
>>> I think this will depend on the deployment type for the L3 agent. If the
>>> gateway_external_network_id is left blank for the L3 agent, the external
>>> network is vlan tagged just like any regular network and doesn't have an
>>> independent bridge.[1] In that deployment scenario it should work fine.
>>>
>>>
>>> On Sun, Aug 24, 2014 at 9:30 AM, Mohammad Banikazemi <mb at us.ibm.com>
>>> wrote:
>>>
>>>>  Would this work? We used to have warnings in Neutron docs indicating
>>>> that instances should not be attached to external networks:
>>>> "It is important to understand that you should not attach the instance
>>>> to Ext-Net directly. Instead, you must use a floating IP to make it
>>>> accessible from the external network."
>>>>
>>>> In this particular case and with the OVS plugin, the traffic on the
>>>> external network which now hosts tenant VMs (on OpenStack compute nodes)
>>>> should get routed from the br-int to the external bridge br-ex using for
>>>> example the appropriate vlan id (what if external network does not use
>>>> vlan?) and then to the external network without doing the NATing. Would
>>>> this traffic go through the veth pair connecting the br-int and br-ex?
>>>>
>>>> Mohammad
>>>>
>>>> [image: Inactive hide details for Kevin Benton ---08/23/2014 01:37:28
>>>> AM---Yes, you should be able to create a shared/external network]Kevin
>>>> Benton ---08/23/2014 01:37:28 AM---Yes, you should be able to create a
>>>> shared/external network within Neutron to accomplish this.
>>>>
>>>> From: Kevin Benton <blak111 at gmail.com>
>>>> To: "OpenStack Development Mailing List (not for usage questions)" <
>>>> openstack-dev at lists.openstack.org>
>>>> Date: 08/23/2014 01:37 AM
>>>> Subject: Re: [openstack-dev] [Neutron] Use public IP address as
>>>> instance fixed IP
>>>> ------------------------------
>>>>
>>>>
>>>>
>>>> Yes, you should be able to create a shared/external network within
>>>> Neutron to accomplish this.
>>>>
>>>>
>>>> On Fri, Aug 22, 2014 at 7:25 AM, Bao Wang <*bywang98 at gmail.com*
>>>> <bywang98 at gmail.com>> wrote:
>>>>
>>>>    Thank you for your response. Could this be done naturally with
>>>>    Openstack neutron or have to be done manually outside neutron ?  As we are
>>>>    expecting to orchestrate hundreds of NFV with all similar network
>>>>    configuration, programmability is another key element.
>>>>
>>>>
>>>>    On Thu, Aug 21, 2014 at 3:52 PM, Kevin Benton <*blak111 at gmail.com*
>>>>    <blak111 at gmail.com>> wrote:
>>>>       Have you tried making the external network shared as well?
>>>>       Instances that need a private IP with NAT attach to an internal network and
>>>>       go through the router like normal. Instances that need a public IP without
>>>>       NAT would just attach directly to the external network.
>>>>
>>>>
>>>>       On Thu, Aug 21, 2014 at 7:06 AM, Bao Wang <*bywang98 at gmail.com*
>>>>       <bywang98 at gmail.com>> wrote:
>>>>          I have a very complex Openstack deployment for NFV. It could
>>>>          not be deployed as Flat. It will have a lot of isolated private networks.
>>>>          Some interfaces of a group VM instances will need bridged network with
>>>>          their fixed IP addresses to communicate with outside world while other
>>>>          interfaces from the same set of VM should keep isolated with real
>>>>          private/fixed IP addresses. What happen if we use public IP addresses
>>>>          directly as fixed IP on those interfaces ? Will this work with Openstack
>>>>          neutron networking ? Will Openstack do NAT automatically on those ?
>>>>
>>>>          Overall, the requirement is to use the fixed/public IP to
>>>>          communicate with outside directly on some interfaces of some VM instances
>>>>          while keeping others as private. The floating IP is not an option here
>>>>
>>>>          _______________________________________________
>>>>          OpenStack-dev mailing list
>>>> *OpenStack-dev at lists.openstack.org* <OpenStack-dev at lists.openstack.org>
>>>> *http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev*
>>>>          <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>>>>
>>>>
>>>>
>>>>       --
>>>>       Kevin Benton
>>>>
>>>>       _______________________________________________
>>>>       OpenStack-dev mailing list
>>>> *OpenStack-dev at lists.openstack.org* <OpenStack-dev at lists.openstack.org>
>>>> *http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev*
>>>>       <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>>>>
>>>>
>>>>    _______________________________________________
>>>>    OpenStack-dev mailing list
>>>> *OpenStack-dev at lists.openstack.org* <OpenStack-dev at lists.openstack.org>
>>>> *http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev*
>>>>    <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Kevin Benton_______________________________________________
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>
>>>
>>> --
>>> Kevin Benton
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140826/129fb25c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140826/129fb25c/attachment.gif>