Re: [controller-dev] Container Mgr question
Luis Gomez <luis.gomez@...>
You are fast! Thanks very much.
From: Alessandro Boch (aboch) [mailto:aboch@...]
The vlan can now be specified in the flow spec.
Agree with your point.
If we specify a vlan only flow-spec (container flow), then the container will map 1:1 with the vlan and traffic separation between containers would be well understood.
If we do not specify the vlan in the FS, then the container would map to something like the VRF.
I have another thought, given that flowspec is something invariable (does not change) across switches, could not we define a vlan-tag in the flowspec and then state that we do not support vlan encapsulation/decapsulation scenarios but instead transport a VLAN-tag flow from one port to another. Sorry to go back on this, I am just trying to gather the vlan-tag into the Container Mgr logic as this is very common way to separate traffic in real networks.
From: Luis Gomez
Thanks, I did not know about the bidirectional thing, now works after changing to:
Now I also understand what you said the other day: “FRM is not auto-adding the match on the static vlan on the configured flow entries (it cannot, otherwise it would break the logic in the first hop switch, the one matching on the host traffic ingressing the of network)”. The VLAN tags can be added/removed through the data path across the different switches so maybe it is not good idea to include them in the flowspecs. They could be included or be part of the nodeconnectors, like: container1 has nodeconnector “SW2-port1-vlan10” and container2 has nodeconnector “SW2-port1-vlan20” but I do not think this definition of node connector is easy to implement on an OF switch.
So as a conclusion, for the bug I just opened you can just try to remove the static vlan definition (so it does not create confusion) and enforce flowspecs whenever you need to share ports.
Each flow spec configuration is by default bidirectional, backend internally generates a couple of flow specs.
The first slice FS says all the packets with SRC and _DST IP_ 10.0.0.1 and with with SRC and _DST IP_ 10.0.0.3.
While the second slice FS says all the ones with SRC and _DST IP_ 10.0.0.2 and with with SRC and _DST IP_ 10.0.0.4.
So there are non-empty intersections between the FSs of the two slices:
[10.0.0.1, 10.0.0.2], [10.0.0.2,10.0.0.1], [10.0.0.1,10.0.0.3], [10.0.0.3,10.0.01], ….
Which is why Container Manager does not allow a port to be assigned to both slices.
Hi Madhu and Alessandro,
I have opened bug #127 for the container Mgr improvement. Now I have another question when I played with the flowspecs:
I configured the following flowspecs for container 1:
And the following for container 2:
For me it is like they are all different flowspecs however when I try to share a port I get: “Port OF|3@OF|00:00:00:00:00:00:00:02 is shared and other container has common flow spec”
Is this expected behavior? if so what makes a flowspec different from another flowspec?
Inline @ A#
On 10/28/13, 2:00 AM, Luis Gomez wrote:
M# Yes. Your observations are inline with the design intent.
Then my questions:
- In scenario 2) if a host uses VLAN tags for different traffics or a regular switch trunk port is connected to host port, how can I put each VLAN on a different container? the existing implementation does not seem to deal with this situation.
M# Yes. this is a missing item on the Flow-Spec. We need to add the Vlan based isolation. Please open a Bugzilla item.
- In scenario 3) how is the “staticVlan” setting used to separate traffic in the network ports? I have created flows in the containers but I do not see any vlan being automatically applied or enforced on the network ports.
M# This is supposed to work as you expect. But, I think this was disabled some time ago due to a few observed issues.
In a scenario where containers do not share host-facing ports (but they can share inter-switch links), using the static vlan assures traffic isolation without the need of configuring container flows ( flow specs).
But given the switch interconnections and host attachments are dynamic in nature, given this works only if hosts send untagged frames, and given FRM is not auto-adding the match on the static vlan on the configured flow entries (it cannot, otherwise it would break the logic in the first hop switch, the one matching on the host traffic ingressing the of network), I would not put much effort in testing this.
controller-dev mailing list