Open Stack

VLAN tag, VXLAN id, etc.


On Tue, Aug 26, 2014 at 2:27 PM, Bao Wang <bywang98 at gmail.com> wrote:

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


-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140826/7951313e/attachment.html>