[Openstack] [networking-sfc] Flow classifier conflict logic
fsbiz at yahoo.com
Tue Aug 2 17:00:51 UTC 2016
Please send the tenant ids of all six neutron ports.
>From admin:neutron port-show <port-id> | grep tenant_id
On Monday, August 1, 2016 7:44 AM, Artem Plakunov <artacc at lvk.cs.msu.su> wrote:
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.
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"
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
create flow classifier 2: logical-source-port = vm B port, protocol
create chain with group 1 and classifier 1
create chain with group 2 and classifier 2 - this step gives the
Flow Classifier 7f37c1ba-abe6-44a0-9507-5b982c51028b conflicts with Flow
Classifier 4e97a8a5-cb22-4c21-8e30-65758859f501 in port chain
Neutron server returns request_ids:
The only thing neutron logs have is this from server.log:
2016-07-29 14:15:57.889 18917 INFO neutron.api.v2.resource
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
I tried the same in liberty and it works and sfc successfully routes
traffic from both vms to their respective port groups
neutron version 7.0.4
neutronclient version 3.1.1
networking-sfc version 1.0.0 (from pip package)
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
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...
More information about the Openstack