Open Stack

100.*
$ neutron port-show 429fdb89-1bfa-4dc1-bb89-25373501ebde | grep tenant_id
| tenant_id             | 0dafd2d782f4445798363ba9b27e104f |
$ neutron port-show ca7f8fdf-a1ff-4cd7-8897-9f6ca5220be6 | grep tenant_id
| tenant_id             | 0dafd2d782f4445798363ba9b27e104f |
$ neutron port-show df8ce9a2-eddd-4b86-8d1c-705f9c96ddb6 | grep tenant_id
| tenant_id             | 0dafd2d782f4445798363ba9b27e104f |

200.*
$ neutron port-show 2c6f6f67-6241-4661-977c-3fe5da864c95 | grep tenant_id
| tenant_id             | ddf01417a9b74648a3a20c2b818a52ca |
$ neutron port-show 9b20c466-f62c-4c49-a074-91a088ebb0f6 | grep tenant_id
| tenant_id             | ddf01417a9b74648a3a20c2b818a52ca |
$ neutron port-show f95f2509-d27d-4b3a-b62a-b9bdb69085bf | grep tenant_id
| tenant_id             | ddf01417a9b74648a3a20c2b818a52ca |

02.08.2016 20:00, Farhad Sunavala пишет:
> Please send the tenant ids of all six neutron ports.
>
> From admin:
> neutron port-show <port-id> | grep tenant_id
>
> Thanks,
> Farhad.
>
>
> On Monday, August 1, 2016 7:44 AM, Artem Plakunov 
> <artacc at lvk.cs.msu.su> wrote:
>
>
> Thanks.
>
> You said though that classifier must be unique within a tenant. I 
> tried creating chains in two different tenants by different users 
> without any RBAC rules. So there are two tenants, each has 1 network, 
> 2 vms (source, service) and an admin user. I used different openrc 
> configs for each user yet still get the same conflict.
>
> Info about the test is in the attachment
> 31.07.2016 5:25, Farhad Sunavala пишет:
>
>> Yes, this was intentionally done.
>> The logical-source-port is important only at the point of classification.
>> All successive classifications rely only on the 5 tuple and MPLS 
>> label (chain ID).
>>
>> Consider an extension of the scenario you mention below.
>>
>> Sources: (similar to your case)
>> a
>> b
>>
>> Port-pairs: (added ppe and ppf)
>> ppc
>> ppd
>> ppe
>> ppf
>>
>> Port-pair-groups: (added ppge and ppgf)
>> ppgc
>> ppgd
>> ppge
>> ppgf
>>
>> Flow-classifiers:
>> fc1: logical-source-port of a && tcp
>> fc2: logical-source-port of b && tcp
>>
>> Port-chains:
>> pc1: fc1 && (ppgc + ppge)
>> pc2: fc2 && (ppgd + ppgc + ppgf)
>>
>>
>>
>> The flow-classifier has logical-src-port and protocol=tcp
>> The logical-src-port has no relevance in the middle of the chain.
>>
>> In the middle of the chain, the only relevant flow-classifier is 
>> protocol=tcp.
>>
>> If we allow it, we cannot distinguish TCP traffic coming out of ppgc 
>> (and subsequently ppc)
>> as to whether to mark it with the label for pc1 or the label for pc2.
>>
>> In other words, within a tenant the flow-classifiers need to be 
>> unique wrt the 5 tuples.
>>
>> thanks,
>> Farhad.
>>
>> Date: Fri, 29 Jul 2016 18:01:05 +0300
>> From: Artem Plakunov <artacc at lvk.cs.msu.su <mailto:artacc at lvk.cs.msu.su>>
>> To: openstack at lists.openstack.org <mailto:openstack at lists.openstack.org>
>> Subject: [Openstack] [networking-sfc] Flow classifier conflict logic
>> Message-ID: <579B6FB1.3030505 at lvk.cs.msu.su 
>> <mailto:579B6FB1.3030505 at lvk.cs.msu.su>>
>> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>>
>> Hello.
>> We have two deployments with networking-sfc:
>> mirantis 8.0 (liberty) and mirantis 9.0 (mitaka).
>>
>> I noticed a difference in how flow classifiers conflict with each other
>> which I do not understand. I'm not sure if it is a bug or not.
>>
>> I did the following on mitaka:
>> 1. Create tenant 1 and network 1
>> 2. Launch vms A and B in network 1
>> 3. Create tenant 2, share network 1 to it with RBAC policy, launch vm C
>> in network 1
>> 4. Create tenant 3, share network 1 to it with RBAC policy, launch vm D
>> in network 1
>> 5. Setup sfc:
>>     create two port pairs for vm C and vm D with a bidirectional port
>>     create two port pair groups with these pairs (one pair in one group)
>>     create flow classifier 1: logical-source-port = vm A port, protocol
>> = tcp
>>     create flow classifier 2: logical-source-port = vm B port, protocol
>> = tcp
>>     create chain with group 1 and classifier 1
>>     create chain with group 2 and classifier 2 - this step gives the
>> following error:
>>
>> Flow Classifier 7f37c1ba-abe6-44a0-9507-5b982c51028b conflicts with Flow
>> Classifier 4e97a8a5-cb22-4c21-8e30-65758859f501 in port chain
>> d1070955-fae9-4483-be9e-0e30f2859282.
>> Neutron server returns request_ids:
>> ['req-9d0eecec-2724-45e8-84b4-7ccf67168b03']
>>
>> The only thing neutron logs have is this from server.log:
>> 2016-07-29 14:15:57.889 18917 INFO neutron.api.v2.resource
>> [req-9d0eecec-2724-45e8-84b4-7ccf67168b03
>> 0b807c8616614b84a4b16a318248d28c 9de9dcec18424398a75a518249707a61 - - -]
>> create failed (client error): Flow Classifier
>> 7f37c1ba-abe6-44a0-9507-5b982c51028b conflicts with Flow Classifier
>> 4e97a8a5-cb22-4c21-8e30-65758859f501 in port chain
>> d1070955-fae9-4483-be9e-0e30f2859282.
>>
>> I tried the same in liberty and it works and sfc successfully routes
>> traffic from both vms to their respective port groups
>>
>> Liberty setup:
>> neutron version 7.0.4
>> neutronclient version 3.1.1
>> networking-sfc version 1.0.0 (from pip package)
>>
>> Mitaka setup:
>> neutron version 8.1.1
>> neutronclient version 5.0.0 (tried using 3.1.1 with same outcome)
>> networking-sfc version 1.0.1.dev74 (from master branch commit
>> 6730b6810355761cf55f04a40cd645f065f15752)
>>
>> I'll attach the output of commands neutron port-list, port-pair-list,
>> port-pair-group-list, flow-classifier-list and port-chain-list.
>>
>> Is this an intended flow classifier behavior? If so, why? The port
>> chains and all their participants are different.
>>
>>
>>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20160803/a6971a0a/attachment.html>