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