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