Nova currently is preventing one from attaching multiple nics on the same L2. That said I don't think we've clearly determined a use case for having multiple nics on the same L2. One reason why we don't allow this is doing so would allow a tenant to easily loop the network and cause a bcast storm and neutron doesn't have any mechanism today to break these loops today. One could just enable STP on ovs to do so though I think we should come up with a good use case before allowing this type of thing.
On Wed, Apr 16, 2014 at 11:53 PM, Kevin Benton <blak...@gmail.com> wrote: > This seems painful for a tenant workflow to get multiple addresses. I > would like to improve this during the Juno cycle. What is the limitation > that is blocking the multi-nic use cases? Is it Nova? > > > On Wed, Apr 16, 2014 at 11:27 PM, Aaron Rosen <aaronoro...@gmail.com>wrote: > >> Hi Kevin, >> >> You'd would just create ports that aren't attached to instances and steal >> their ip_addresses from those ports and put those in the >> allowed-address-pairs on a port OR you could change the allocation range on >> the subnet to ensure these ips were never handed out. That's probably the >> right approach. >> >> Aaron >> >> >> On Wed, Apr 16, 2014 at 10:03 PM, Kevin Benton <blak...@gmail.com> wrote: >> >>> Yeah, I was aware of allowed address pairs, but that doesn't help with >>> the IP allocation part. >>> >>> Is this the tenant workflow for this use case? >>> >>> 1. Create an instance. >>> 2. Wait to see what which subnet it gets an allocation from. >>> 3. Pick an IP from that subnet that doesn't currently appear to be in >>> use. >>> 4. Use the neutron-cli or API to update the port object with the extra >>> IP. >>> 5. Hope that Neutron will never allocate that IP address for something >>> else. >>> >>> >>> On Wed, Apr 16, 2014 at 9:46 PM, Aaron Rosen <aaronoro...@gmail.com>wrote: >>> >>>> Whoops Akihiro beat me to it :) >>>> >>>> >>>> On Wed, Apr 16, 2014 at 9:46 PM, Aaron Rosen <aaronoro...@gmail.com>wrote: >>>> >>>>> The allowed-address-pair extension that was added here ( >>>>> https://review.openstack.org/#/c/38230/) allows us to add arbitrary >>>>> ips to an interface to allow them. This is useful if you want to run >>>>> something like VRRP between two instances. >>>>> >>>>> >>>>> On Wed, Apr 16, 2014 at 9:39 PM, Kevin Benton <blak...@gmail.com>wrote: >>>>> >>>>>> I was under the impression that the security group rules blocked >>>>>> addresses not assigned by neutron[1]. >>>>>> >>>>>> 1. >>>>>> https://github.com/openstack/neutron/blob/master/neutron/agent/linux/iptables_firewall.py#L188 >>>>>> >>>>>> >>>>>> On Wed, Apr 16, 2014 at 9:20 PM, Aaron Rosen >>>>>> <aaronoro...@gmail.com>wrote: >>>>>> >>>>>>> You can do it with ip aliasing and use one interface: >>>>>>> >>>>>>> ifconfig eth0 10.0.0.22/24 >>>>>>> ifconfig eth0:1 10.0.0.23/24 >>>>>>> ifconfig eth0:2 10.0.0.24/24 >>>>>>> >>>>>>> 2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state >>>>>>> DOWN qlen 1000 >>>>>>> link/ether 40:6c:8f:1a:a9:31 brd ff:ff:ff:ff:ff:ff >>>>>>> inet 10.0.0.22/24 brd 10.0.0.255 scope global eth0 >>>>>>> valid_lft forever preferred_lft forever >>>>>>> inet 10.0.0.23/24 brd 10.0.0.255 scope global secondary eth0:1 >>>>>>> valid_lft forever preferred_lft forever >>>>>>> inet 10.0.0.24/24 brd 10.0.0.255 scope global secondary eth0:2 >>>>>>> valid_lft forever preferred_lft forever >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Apr 16, 2014 at 8:53 PM, Kevin Benton <blak...@gmail.com>wrote: >>>>>>> >>>>>>>> Web server running multiple SSL sites that wants to be compatible >>>>>>>> with clients that don't support the SNI extension. There is no way for >>>>>>>> a >>>>>>>> server to get multiple IP addresses on the same interface is there? >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Apr 16, 2014 at 5:50 PM, Aaron Rosen <aaronoro...@gmail.com >>>>>>>> > wrote: >>>>>>>> >>>>>>>>> This is true. Several people have asked this same question over >>>>>>>>> the years though I've yet to hear a use case why one really need to do >>>>>>>>> this. Do you have one? >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Apr 16, 2014 at 3:12 PM, Ronak Shah < >>>>>>>>> ro...@nuagenetworks.net> wrote: >>>>>>>>> >>>>>>>>>> Hi Vikash, >>>>>>>>>> Currently this is not supported. the NIC not only needs to be in >>>>>>>>>> different subnet, they have to be in different network as well >>>>>>>>>> (container >>>>>>>>>> for the subnet) >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Ronak >>>>>>>>>> >>>>>>>>>> On Wed, Apr 16, 2014 at 3:51 AM, Vikash Kumar < >>>>>>>>>> vikash.ku...@oneconvergence.com> wrote: >>>>>>>>>> >>>>>>>>>>> *With 'interfaces' I mean 'nics' of VM*. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Wed, Apr 16, 2014 at 4:18 PM, Vikash Kumar < >>>>>>>>>>> vikash.ku...@oneconvergence.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> I want to launch one VM which will have two Ethernet >>>>>>>>>>>> interfaces with IP of single subnet. Is this supported now in >>>>>>>>>>>> openstack ? >>>>>>>>>>>> Any suggestion ? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanx >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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 >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>> >>>> >>> >>> >>> -- >>> 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