According to described here
http://flowgrammable.org/sdn/openflow/message-layer/flowmod/
and in the OpenFlow switch specifications, the flow_mod message is not acknowledgeable.
Is there any way for the controller (POX, ODL, or any other) to receive a confirmation for installed flow match or to retrieve the installed flows in the switch's flow table?
Thank you
There is a concept in openflow called "barrier" where the controller
can send a barrier request to have the switch acknowledge the flow_mod.
In OpenDaylight, the default openflowplugin stats collection will poll
the connected switches and will store the config (including the flow table)
in OpenDaylight's operational store.
Related
I have created a simple network topology using mininet and integrated it with Opendaylight. Now I want to set up queues on a switch and get the flow stats from it. I haven't found any step by step tutorial anywhere. Any kind of help or suggestions will be appreciated.
Here is the picture of my network topology attached.
Assuming your switches support Openflow 1.3, you can make use of Openflow meter table [1].
Current way to flush a meter to switch with Opendaylight looks like this (full detail in [2]:
Create MD-SAL modeled flow and commit it into dataStore using two
phase commit
FRM gets notified and invokes corresponding rpc (addMeter) on particular service provider (if suitable provider for given node registered)
the provider (plugin in this case) transforms MD-SAL modeled meter into OF-API modeled meter
OF-API modeled meter is then flushed into OFLibrary
OFLibrary encodes meter into particular version of wire protocol and sends it to particular switch
Check on mininet side if meter is installed
[1] - https://www.cs.princeton.edu/courses/archive/fall13/cos597E/papers/openflow-spec-v1.3.2.pdf (Section 5.7)
[2] - https://wiki.opendaylight.org/view/OpenDaylight_OpenFlow_Plugin:End_to_End_Meters#Learn_End_to_End_for_Inventory
Suppose I have a topology like < host1--switch1--switch2--switch3--controller>. So, the physical path between switch1 and the controller consist of switch2 and switch3. Does the control traffic from switch1 to the controller goes from switch2 and switch3? I mean the openflow traffics between switch1 and the controller go to switch2 at first and then go to switch3 until it reach to the controller. Am I right?
Openflow switches have seperate management ports to connect to the controller. If you use outofband connection (direct connection to controller via management port) switch communicates with controller directly. In a such case, for data flows, you can still use the topology you mentioned.
But, if there is no management connection between switch 1 and controller, then it comes to "inband" connection. In a such case, switch 1 sends openflow messages via data port, switch 2 encapsulates this message and send to the controller.
From OpenFlow documentation:
The speci cation of the networks used for the OpenFlow channels is
outside the scope of the present speci cation. It may be a separate
dedicated network, or the OpenFlow channel may use the network managed
by the OpenFlow switch (in-band controller connection). The only
requirement is that it should provide TCP/IP connectivity.
Dedicated network means outofband connection.
To learn some details about inband you can look this documentation:
Important part is:
In this setup, control traffic sent by switch A will be seen by
switch B, which will send it to the controller as part of an
OFPT_PACKET_IN message. Switch A will then see the OFPT_PACKET_IN
message's packet, re-encapsulate it in another OFPT_PACKET_IN, and
send it to the controller. Switch B will then see that
OFPT_PACKET_IN, and so on in an infinite loop.
I am developing a mule application where I have to take orders from One system System-1 & have to send it to the another system say System-2 through soap (which actually takes care of creation of orders, invoices etc) & the response from System-2 is routed back to system-1 with success or failure response. Now what approach should be the best, will a VM be the best approach for referencing purpose or a flow reference ? The number of orders coming could be like 100 per hour. Also for both cases what should be the ideal worker size ?
If the system 2 is to be called SOAP web service, you should be using web service consumer component or an http requester component.
Lets understand the difference between flowref and vm.
Both flowref and vm are used to call another flow within the mule application.
Major difference between both is vm uses in-memory queue to refer to other flow and it creates a transport barrier, hence flow variable and inbound properties wont be propagated across, hence use of vm component should be considered only of it creating a transport barrier is necessary.
If thats(creating transport barrier) not the requirement, usage of flow ref is recommended.
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.
I have a service that handles messages that persists data to an external system. If (a.k.a. when) the writing of this data to the external system fails, or normal monitoring strategy will alert system admins of the failure.
I would like to also notify the user who submitted the message that there is a delay in processing their request.
Where/How is the best way to accomplish this scenario? I've looked into the IManageMessageFailures, but it seems that will bypass the SLR functionality.
Starting with NServiceBus version 5.1 now has the ability to use Reactive Extensions to observe when a message is sent to an error queue. From there, you can log, email, or whatever best meets your needs.
http://docs.particular.net/nservicebus/subscribing-to-push-based-error-notifications
Why don't you try and separate the two concerns?
Manage the 3rd party interaction in a saga, and if it fails, send a failure notification message (you can use timeout to cater for no proper reply).