[openstack-dev] Chalenges with highly available service VMs
Aaron Rosen
aaronorosen at gmail.com
Wed May 21 02:54:51 UTC 2014
arosen at arosen-MacBookPro:~/devstack$ neutron port-show
f5117013-ac04-45af-a5d6-e9110213ad6f
+-----------------------+----------------------------------------------------------------------------------+
| Field | Value
|
+-----------------------+----------------------------------------------------------------------------------+
| admin_state_up | True
|
| allowed_address_pairs |
|
| binding:vnic_type | normal
|
| device_id | 99012a6c-a5ed-41c0-92c9-14d40af0c2df
|
| device_owner | compute:None
|
| extra_dhcp_opts |
|
| fixed_ips | {"subnet_id":
"505eb39c-32dc-4fe7-a497-f801a0677c54", "ip_address": "10.0.0.22"} |
| id | f5117013-ac04-45af-a5d6-e9110213ad6f
|
| mac_address | fa:16:3e:77:4d:2d
|
| name |
|
| network_id | 1b069199-bfa4-4efc-aebd-4a663d447964
|
| security_groups | 0d5477cf-f63a-417e-be32-a12557fa4098
|
| status | ACTIVE
|
| tenant_id | c71ebe8d1f6e47bab7d44046ec2f6b39
|
+-----------------------+----------------------------------------------------------------------------------+
arosen at arosen-MacBookPro:~/devstack$ neutron port-update
f5117013-ac04-45af-a5d6-e9110213ad6f --allowed-address-pairs list=true
type=dict ip_address=10.0.0.0/24
Updated port: f5117013-ac04-45af-a5d6-e9110213ad6f
arosen at arosen-MacBookPro:~/devstack$ neutron port-show
f5117013-ac04-45af-a5d6-e9110213ad6f
+-----------------------+----------------------------------------------------------------------------------+
| Field | Value
|
+-----------------------+----------------------------------------------------------------------------------+
| admin_state_up | True
|
| allowed_address_pairs | {"ip_address": "10.0.0.0/24", "mac_address":
"fa:16:3e:77:4d:2d"} |
| binding:vnic_type | normal
|
| device_id | 99012a6c-a5ed-41c0-92c9-14d40af0c2df
|
| device_owner | compute:None
|
| extra_dhcp_opts |
|
| fixed_ips | {"subnet_id":
"505eb39c-32dc-4fe7-a497-f801a0677c54", "ip_address": "10.0.0.22"} |
| id | f5117013-ac04-45af-a5d6-e9110213ad6f
|
| mac_address | fa:16:3e:77:4d:2d
|
| name |
|
| network_id | 1b069199-bfa4-4efc-aebd-4a663d447964
|
| security_groups | 0d5477cf-f63a-417e-be32-a12557fa4098
|
| status | ACTIVE
|
| tenant_id | c71ebe8d1f6e47bab7d44046ec2f6b39
|
+-----------------------+----------------------------------------------------------------------------------+
On Tue, May 20, 2014 at 7:52 PM, Aaron Rosen <aaronorosen at gmail.com> wrote:
> Hi Praveen,
>
> I think there is some confusion here. This function doesn't check if there
> is any overlap that occurs within the cidr block. It only checks that the
> fixed_ips+mac don't overlap with an allowed address pair. In your example
> if the host has an ip_address of 10.10.1.1 and you want to allow any ip in
> 10.10.1.0/24 to pass through the port you can just add a rule for
> 10.10.1.0/24 directly without having to break it up.
>
> Aaron
>
>
> On Tue, May 20, 2014 at 11:20 AM, Praveen Yalagandula <
> ypraveen at avinetworks.com> wrote:
>
>> Hi Aaron,
>>
>> The main motivation is simplicity. Consider the case where we want to
>> allow ip cidr 10.10.1.0/24 to be allowed on a port which has a fixed IP
>> of 10.10.1.1. Now if we do not want to allow overlapping, then one needs to
>> add 8 cidrs to get around this - (10.10.1.128/25, 10.10.1.64/26,
>> 10.10.1.32/27, ....10.10.1.0/32); which makes it cumbersome.
>>
>> In any case, allowed-address-pairs is ADDING on to what is allowed
>> because of the fixed IPs. So, there is no possibility of conflict. The
>> check will probably make sense if we are maintaining denied addresses
>> instead of allowed addresses.
>>
>> Cheers,
>> Praveen
>>
>>
>> On Tue, May 20, 2014 at 9:34 AM, Aaron Rosen <aaronorosen at gmail.com>wrote:
>>
>>> Hi Praveen,
>>>
>>> I think we should fix the update_method instead to properly check for
>>> this. I don't see any advantage to allow the fixed_ips/mac to be in the
>>> allowed_address_pairs since they are explicitly allowed. What's your
>>> motivation for changing this?
>>>
>>> Aaron
>>>
>>>
>>> On Mon, May 19, 2014 at 4:05 PM, Praveen Yalagandula <
>>> ypraveen at avinetworks.com> wrote:
>>>
>>>> Hi Aaron,
>>>>
>>>> Thanks for the prompt response.
>>>>
>>>> If the overlap does not have any negative effect, can we please just
>>>> remove this check? It creates confusion as there are certain code paths
>>>> where we do not perform this check. For example, the current code does NOT
>>>> perform this check when we are updating the list of allowed-address-pairs
>>>> -- I can successfully assign an existing fixed IP address to the
>>>> allowed-address-pairs. The check is being performed on only one code path -
>>>> when assigning fixed IPs.
>>>>
>>>> If it sounds right to you, I can submit my patch removing this check.
>>>>
>>>> Thanks,
>>>> Praveen
>>>>
>>>>
>>>>
>>>> On Mon, May 19, 2014 at 12:32 PM, Aaron Rosen <aaronorosen at gmail.com>wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Sure, if you look at this method:
>>>>>
>>>>> def _check_fixed_ips_and_address_pairs_no_overlap(self, context,
>>>>> port):
>>>>> address_pairs = self.get_allowed_address_pairs(context,
>>>>> port['id'])
>>>>> for fixed_ip in port['fixed_ips']:
>>>>>
>>>>> for address_pair in address_pairs:
>>>>>
>>>>> if (fixed_ip['ip_address'] ==
>>>>> address_pair['ip_address']
>>>>> and port['mac_address'] ==
>>>>> address_pair['mac_address']):
>>>>> raise
>>>>> addr_pair.AddressPairMatchesPortFixedIPAndMac()
>>>>>
>>>>>
>>>>>
>>>>> it checks that the allowed_address_pairs don't overlap with fixed_ips
>>>>> and mac_address on the port. The only reason we do this additional check is
>>>>> that having the same fixed_ip and mac_address pair as an
>>>>> allowed_address_pair would have no effect since the fixed_ip/mac on the
>>>>> port inherently allows that traffic through.
>>>>>
>>>>> Best,
>>>>>
>>>>> Aaron
>>>>>
>>>>>
>>>>>
>>>>> On Mon, May 19, 2014 at 12:22 PM, Praveen Yalagandula <
>>>>> ypraveen at avinetworks.com> wrote:
>>>>>
>>>>>> Hi Aaron,
>>>>>>
>>>>>> In OVS and ML2 plugins, on port-update, there is a check to make sure
>>>>>> that allowed-address-pairs and fixed-ips don't overlap. Can you please
>>>>>> explain why that is needed?
>>>>>>
>>>>>> ------------- icehouse final: neutron/plugins/ml2/plugin.py
>>>>>> ------------
>>>>>>
>>>>>> 677 elif changed_fixed_ips:
>>>>>>
>>>>>> 678
>>>>>> self._check_fixed_ips_and_address_pairs_no_overlap(
>>>>>>
>>>>>> 679 context, updated_port)
>>>>>> -----------------------
>>>>>>
>>>>>> Thanks,
>>>>>> Praveen
>>>>>>
>>>>>>
>>>>>> On Wed, Jul 17, 2013 at 3:45 PM, Aaron Rosen <arosen at nicira.com>wrote:
>>>>>>
>>>>>>> Hi Ian,
>>>>>>>
>>>>>>> For shared networks if the network is set to
>>>>>>> port_security_enabled=True then the tenant will not be able to remove
>>>>>>> port_security_enabled from their port if they are not the owner of the
>>>>>>> network. I believe this is the correct behavior we want. In addition, only
>>>>>>> admin's are able to create shared networks by default.
>>>>>>>
>>>>>>> I've created the following blueprint
>>>>>>> https://blueprints.launchpad.net/neutron/+spec/allowed-address-pairsand doc:
>>>>>>> https://docs.google.com/document/d/1hyB3dIkRF623JlUsvtQFo9fCKLsy0gN8Jf6SWnqbWWA/edit?usp=sharingwhich will provide us a way to do this. It would be awesome if you could
>>>>>>> check it out and let me know what you think.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Aaron
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Jul 16, 2013 at 10:34 AM, Ian Wells <ijw.ubuntu at cack.org.uk>wrote:
>>>>>>>
>>>>>>>> On 10 July 2013 21:14, Vishvananda Ishaya <vishvananda at gmail.com>
>>>>>>>> wrote:
>>>>>>>> >> It used to be essential back when we had nova-network and all
>>>>>>>> tenants
>>>>>>>> >> ended up on one network. It became less useful when tenants
>>>>>>>> could
>>>>>>>> >> create their own networks and could use them as they saw fit.
>>>>>>>> >>
>>>>>>>> >> It's still got its uses - for instance, it's nice that the
>>>>>>>> metadata
>>>>>>>> >> server can be sure that a request is really coming from where it
>>>>>>>> >> claims - but I would very much like it to be possible to, as an
>>>>>>>> >> option, explicitly disable antispoof - perhaps on a per-network
>>>>>>>> basis
>>>>>>>> >> at network creation time - and I think we could do this without
>>>>>>>> >> breaking the security model beyond all hope of usefulness.
>>>>>>>> >
>>>>>>>> > Per network and per port makes sense.
>>>>>>>> >
>>>>>>>> > After all, this is conceptually the same as enabling or disabling
>>>>>>>> > port security on your switch.
>>>>>>>>
>>>>>>>> Bit late on the reply to this, but I think we should be specific on
>>>>>>>> the network, at least at creation time, on what disabling is allowed
>>>>>>>> at port level (default off, may be off, must be on as now). Yes,
>>>>>>>> it's
>>>>>>>> exactly like disabling port security, and you're not always the
>>>>>>>> administrator of your own switch; if we extend the analogy you
>>>>>>>> probably wouldn't necessarily want people turning antispoof off on
>>>>>>>> an
>>>>>>>> explicitly shared-tenant network.
>>>>>>>> --
>>>>>>>> Ian.
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>
>>>
>>
>> _______________________________________________
>> 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/20140520/703d1a00/attachment-0001.html>
More information about the OpenStack-dev
mailing list