Open Stack

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140826/2dd3f53d/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/2dd3f53d/attachment.gif>