I mean, write metadata is implemented by the instructions in openflow, on the other side, set field in action can also set the metadata ,what is the differences between them?
As far as I can see, WRITE_METADATA and SET_FIELD for metadata do the same in Open vSwitch.
I'm guessing both are exposed by Open vSwitch to follow the OpenFlow specifications as much as possible. OpenFlow has a clear distinction between Actions and Instructions (cf. Sections 5.5 and 5.6 of OpenFlow v1.5.1): Instructions are attached to rules and applied at the end of each table, whereas Actions are attached to packets (using the Write-Actions Instruction) and applied at the end of the pipeline (or before if the Apply-Actions Instruction is executed). In Open vSwitch, the distinction is not as clear: Actions can be attached to both packets and rules.
Thus, while WRITE_METADATA is different from SET_FIELD in the OpenFlow specification because the first is an Instruction, the second an Action, you can do the same as WRITE_METADATA with a SET_FIELD Action.
Related
I am trying to use the POX controller to control the path of flows. I know that the Open vSwitch will choose the forwarding rules that have the highest priority. But what will happen if I insert a new forwarding rule for the existing flow with the same priority. Will the Open vSwitch randomly choose one rule to match?
The OpenFlow 1.3 specification says:
If there are multiple matching flow entries with the same highest priority, the selected flow entry is explicitly undefined.
The older OpenFlow 1.0 specification states that:
If multiple entries have the same priority, the switch is free to choose any ordering.
Open vSwitch docs and this other source here says:
OpenFlow leaves behavior undefined when two or more flows with the same priority can match a single packet. Some users expect "sensible" behavior, such as more specific flows taking precedence over less specific flows, but OpenFlow does not specify this and Open vSwitch does not implement it. Users should therefore take care to use priorities to ensure the behavior that they expect.
It is unclear, I know, but based on these sources, it is up to the user to deal with situations where a flow entry overlap with same priorities occurs. The user should take care of setting the right priorities and the switch is free to implement a way to deal with this as the vendor desires. The switch may, for instance, select the newest flow entry, as you said it happened in your case.
In OpenFlow protocol we have a flow table (or multiple flow tables). Each flow table in the switich contains a set of flow entries. Each flow entry contains header fields, counters and a set of instructions or actions to be applied. Instrucions are like "add this action to action set" (write-actions instruction) or "clear action set" (clear-actions instruction), and actions are like "output to port X" (output action) or "drop this packet" (drop action). But how does work ? what exactly is in the flow entry, an action or an instruction ? or maybe both are ? what exactly is an action set ? could someone give me a little exmaple that uses these terms ?
"Actions can discard, modify, queue, or forward the packet. In version 1.0 of the OpenFlow protocol the Action set is modified directly by the Actions list in the FlowMod message; however, in 1.1.0 and subsequent versions the the protocol, the Action set is modified by the Instruction structure carried in the FlowMod. An Instruction may carry an Actions list to update the Action set, or be applied immediately to the packet bypassing the Action set".
ref. (http://flowgrammable.org/sdn/openflow/actions/#ofp_1_4)
In other words, when a packet matches a particular OpenFlow flow, the switch running OpenFlow v1.0 applies a set of actions to the packet. Now, with the new OpenFlow version, instead of applying a set of actions, the switch applies a flow instruction to a matching packet.
According to OpenFlow specification 1.5.1 (https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-switch-v1.5.1.pdf), the instruction set associated with a flow entry contains a maximum of one instruction of each type, following the order:
Apply-Actions, Clear-Actions, Write-Actions, Write-Metadata, Stat-Trigger or Goto-Table.
I'm using Mininet and POX controller. The network topology has multiple switches.
Whenever I install flow for some switch, and afterwards I check the flow table in that switch, its actions set is empty.
dump-flows shows actions=
However, when there's only one switch in the network, the actions set is not empty.
What may be the reason for the actions set being empty ?
Thank you
After looking in OpenFlow specifications again,
I learned that an empty actions set in a flow entry is a drop flow.
From OpenFlow Switch Specifications v1.3.1
Drop. There is no explicit action to represent drops. Instead, packets whose action
sets have no output actions should be dropped.
Afterwards, I realized where was the error in the code which made the incorrect flow entry installed.
In below diagram what is the meaning of below arrows ?
Here's what I think :
Each arrow describes where the change sets are flowing from/to. So the top workspace flows changes and accepts changes from the stream. The bottom two workspaces just flow changes to the stream, theses workspaces do not accept any changes from the stream. Is this correct ?
What is the meaning of the broken blue arrow ?
A broken arrow means: this flow target is not currently the current one.
If you open the stream, you will see a section "Flow Target" with a list of targets.
Each line can have two qualifier: "default" and "current".
Any target which isn't "current" will be represented by a broken arrow.
Current means that, when you are requesting to see the differences between one stream and another, it will display said differences between the stream and the current target.
See also this thread (more oriented for flow targets between repo workspace and streams)
"Current" means "this is the flow target that will be displayed in the Pending Changes view".
"Default" means "if you try to deliver to a flow target other than the one marked "Default", you will get a warning, asking you if you are sure that you want to deliver to a non-default target.
Here's what I think : Each arrow describes where the change sets are flowing from/to.
Yes, but this is a "model": you won't directly deliver/accept changes from a Stream. You will always do so from a repo workspace.
So the top workspace flows changes and accepts changes from the stream.
Not exactly:
the filled blue arrow means you can ask the stream for the differences between said stream and the repo workspace (no deliver possible here, just a vizualisation of differences)
the broken blue arrow means the repo workspace knows about the Stream (it is listed as a default flow target, but said stream isn't the current flow target for the top repo workspace.
That means the "Pending Changes" views won't display any differences (to accept or to deliver) for that repo workspace compared to the Stream.
The bottom two workspaces just flow changes to the stream, theses workspaces do not accept any changes from the stream. Is this correct ?
No: the target means the bottom repo workspaces knows about the Stream (they can accept or deliver changes), and that Stream is their current flow target (the "Pending changes" view actively monitor differences between the bottom repo workspace and the Stream.
According with link,
http://www.ibm.com/developerworks/br/rational/library/parallel-development-rational-team-concert/
your assertion
"Current" means "this is the flow target that will be displayed in the
Pending Changes view". "Default" means "if you try to deliver to a
flow target other than the one marked 'Default', you will get a
warning, asking you if you are sure that you want to deliver to a
non-default target".
is absolutely correct.
This Question is extension of the following
OpenFlow Rule Metadata
I would like to have this clarified, on my question about Metadata
Let us say, I have an Open Flow rules, as below
Cookie=0x8000001, duration=228925.445s, table=17, n_packets=350, n_bytes=32424, priority=10,metadata=0xc000f30000000000/0xffffff0000000000 actions=goto_table:19
I wanted to understand the following
Do we have certain rule/ Algorithm , to determine these Metadata from a Packet.
because the Packet in OVS is actually switched based on Matching Metadata, Is that correct ?? ( At least according to the above flow rule )
And the Packet itself does not carry the Metadata, then how exactly
the packet hitting a flow matched against the Metadata.
So, If I understood it correctly the Packets those are traversed between the flow-tables, are within the OVS application itself or Handled #OVS Application level, until it had determined Egress Port
So in that Case, the MetaData are handled #OVS-Application level, until the Packets is send via Egress Port.
Is this correct??
Finally which Module in ODL is responsible for determine the Metadata, and I would like to understand from the code how exactly it was done.
The OpenFlow metadata field starts with a value of zero for every packets. Tables can then writes to this field and you can match on it in subsequent tables. It is only used to carry information from one table to the next, as explained in the OpenFlow specifications:
Metadata: a maskable register that is used to carry information from one table to the next.
first of all you can try Ryu instead, its code is more easy to read and understand.
Then, I think metadata/instructions/actions.... these things are belong to the processing of OVS forwarding, but these things needs to attach to something and that is the packet that OVS received. About the question "Do we have certain rule/ Algorithm , to determine these Metadata from a Packet. " I think the value of the Metadata is determind by the controller, which means that it depends on 'how do you design your own network instance using some(e.g. RYU) controller application'.