Hi Luis,

The vlan can now be specified in the flow spec.

https://git.opendaylight.org/gerrit/#/c/2254/

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.

Thanks,
Alessandro

Hi Alessandro,

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.

BR/Luis

Thanks, I did not know about the bidirectional thing, now works after changing to:

Container1:

<flowSpecs>

    <name>h1toh3</name>

    <nwSrc>10.0.0.1</nwSrc>

    <nwDst>10.0.0.3</nwDst>

</flowSpecs>

Container 2:

<flowSpecs>

    <name>h2toh4</name>

    <nwSrc>10.0.0.2</nwSrc>

    <nwDst>10.0.0.4</nwDst>

</flowSpecs>

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.

BR/Luis

Hi Luis,

Each flow spec configuration is by default bidirectional, backend internally generates a couple of flow specs.
The flow specs are internally represented as a Match object, which represents a set of network packets.

So, in your case:

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.

Thanks,
Alessandro

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:

<flowSpecs>

    <name>toh1</name>

    <nwDst>10.0.0.1</nwDst>

</flowSpecs>

<flowSpecs>

    <name>toh3</name>

    <nwDst>10.0.0.3</nwDst>

</flowSpecs>

</container-config>

And the following for container 2:

<flowSpecs>

    <name>toh2</name>

    <nwDst>10.0.0.2</nwDst>

</flowSpecs>

<flowSpecs>

    <name>toh4</name>

    <nwDst>10.0.0.4</nwDst>

</flowSpecs>

</container-config>

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?

Thanks/Luis

Inline @ A#

Thanks,
Alessandro

Hi Luis,

Comments inline.

Hi controller experts,

 

I am configuring containers in OpenDaylight controller, and observed the following:

 

1) Containers using different ports is no problem (no flowspec needed)

2) If containers share one or more host ports, I need flowspecs (different on both containers) to separate traffic

3) If containers share only network ports, it is enough if they have different staticVlan

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.
      Will let the other controller-devs to get the reason. Also, I have a basic concern with this feature. Since OF1.0 doesnt support QinQ, this staticVlan
      addition will overwrite any vlan that is already present in the packet. So, not having this feature right now, is not a problem :-)
      But certainly the above vlan presence in flow-spec is missing.
A# Right,  in order to make use of the Static Vlan, the application needs to have the topology view. The application needs to push/pop the container static vlan on traffic ingressing/egressing the openflow network. The application needs to know if a port is a host-facing port. FRM cannot blindly set/unset this vlan because it works on per-flow basis, it has no topology information.

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.

Thanks/Luis

_______________________________________________

controller-dev mailing list

controller-dev@...

https://lists.opendaylight.org/mailman/listinfo/controller-dev