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
