VLAN tag, VXLAN id, etc.
On Tue, Aug 26, 2014 at 2:27 PM, Bao Wang <bywan...@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 <blak...@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" <bywan...@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 <blak...@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 <m...@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 <blak...@gmail.com> >>>>> To: "OpenStack Development Mailing List (not for usage questions)" < >>>>> openstack-dev@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 <*bywan...@gmail.com* >>>>> <bywan...@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 <*blak...@gmail.com* >>>>> <blak...@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 <*bywan...@gmail.com* >>>>> <bywan...@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@lists.openstack.org* >>>>> <OpenStack-dev@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@lists.openstack.org* >>>>> <OpenStack-dev@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@lists.openstack.org* >>>>> <OpenStack-dev@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@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 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 > > -- Kevin Benton
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
