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
From:
Luis Gomez
Sent: Tuesday, October 29, 2013 5:48 PM
To: 'Alessandro Boch (aboch)'; Madhu Venguopal
Cc: 'integration-dev@...'; dev
(controller-dev@...)
Subject: RE: [controller-dev] Container Mgr
question
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.
On 10/28/13, 2:00 AM, Luis Gomez wrote:
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
