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 <art...@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 <art...@lvk.cs.msu.su> To: openstack@lists.openstack.org Subject: [Openstack] [networking-sfc] Flow classifier conflict logic Message-ID: <579b6fb1.3030...@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.
_______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack