Open Stack

 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>
 To: openstack at lists.openstack.org
 Subject: [Openstack] [networking-sfc] Flow classifier conflict logic
 Message-ID: <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/20160802/04aa9bbc/attachment.html>