[openstack-dev] [Openstack][nova][Neutron] Launch VM with multiple Ethernet interfaces with I.P. of single subnet.

Aaron Rosen aaronorosen at gmail.com
Thu Apr 17 07:06:53 UTC 2014


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 <blak111 at 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 <aaronorosen at 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 <blak111 at 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 <aaronorosen at gmail.com>wrote:
>>>
>>>> Whoops Akihiro beat me to it :)
>>>>
>>>>
>>>> On Wed, Apr 16, 2014 at 9:46 PM, Aaron Rosen <aaronorosen at 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 <blak111 at 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 <aaronorosen at 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 <blak111 at 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 <aaronorosen at 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 <
>>>>>>>>> ronak at 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.kumar at oneconvergence.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> *With 'interfaces' I mean 'nics' of VM*.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Apr 16, 2014 at 4:18 PM, Vikash Kumar <
>>>>>>>>>>> vikash.kumar at 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 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
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>>
>>>>
>>>
>>>
>>> --
>>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140417/67036c54/attachment.html>


More information about the OpenStack-dev mailing list