Although I had already done a similar post for this here, guess there are a lot of folks who are not able get everything working together without the actual source code.
So I thought it might be helpful if I provide with some ready to use project/code for installing flows using java.
1. Download the source code.
Download the source code of project “OpenDaylightFlowInstall” from my GitHub here. This will give you the following:
- FlowManager Class – Responsible for adding/deleting flows
- Tester Class – Responsible for actually passing the data & calling FlowManager class to install/delete flows.
- ODL Class – Responsible for OpenDaylight settings.
2. Import/Setup the code
You can import the code into eclipse as a java project or setup your command. Whatever you prefer.
To import the code in eclipse use “Import as Java Project” option and make sure that your “Project –> Build Automatically” is switched on.
Also make sure that the two jars in lib folder are in classpath else compilation will fail.
3. Network & OpenDaylight Setup
I have a mininet running with one switch and two hosts which are able to ping each other & connected to OpenDaylight.
4 Running the program
If you are using eclipse, simply right clicking on the tester class and saying “Run as Java Application” should run the code. Make sure of two things:
Supply the right Src/Dest IP & Node details in the Tester.java
Correct values in ODL.java under settings.
Once you run the program, the action DROP will be installed and ping will stop working.
Let me know, if you get stuck & i’ll try to help.
There has been always a confusion in my mind regarding the difference between OpenFlow ALL and FLOOD action. If you are one of them, go on!
Technically, the spec definition says:
FLOOD: Flood the packet along the minimum spanning tree, not including the incoming interface.
ALL: Send the packet out all interfaces, not including the incoming interface.
So, what’s the difference?
ALL action is pretty much clear in what it says. What is implied by saying “along the minimum spanning tree” is that flood the packet on all the ports where STP is disabled.
Now if we take a case of Juniper Junos OS with OpenFlow which do not support STP, in that case all the ports will have STP disabled due to lack of feature and both ALL & FLOOD actions will behave in the same way.
Hope it helps!
There is alot of content around OpenFlow on internet in bits & pieces, I thought of collating everything into one document that can be used as a reference.
You can also download this paper from my blog at Understanding OpenFlow
What I have tried to stitch together in this post is how a packet flows between a OpenFlow enabled network device to the controller which processes it (& how or using which interfaces) and return back path of the packet.
You might have seen the standard OpenDaylight architecture as below already.
First, it is important to understand the above diagram briefly, to lay the expectations:
- OpenFlow Enabled Devices: This is the network infrastructure that is managed via OpenDaylight. In this case OpenFlow plug-in.
- Protocol Plugins: OpenDaylight supports these protocols for managing your network devices. One of the plugins is OpenFlow.
- Service Abstraction Layer (SAL): Magic! This layer does all the plumbing between the applications and the underlying plugins.
- Controller Platform: These are the applications that come pre-bundled with OpenDaylight to manage the network. (You can write your’s too!)
- Network Applications: These are applications with leverage REST NBI of OpenDaylight to build intelligence. Here is a sample Network Statistics SDN Application that I have done!
Now, below is how packet flow from network to OpenDaylight & back to network takes place:
- A packet arriving at a network device will be sent to the appropriate protocol plugin of OpenDaylight which is managing the switch.
- IPluginOutDataPacketService: The plugin (in our case OpenFlow Plug-in) will parse the packet, generate an event for Service Abtraction Layer (SAL) for further processing.
- IListenDataPacket: SAL will dispatch the packet to all the modules listening for DataPacket. These could be existing OpenDaylight applications like ARP Handler of your applications.
- IDataPacketService: Application/Module does the processing on the packet as per the business logic built and sends a PACKET_OUT using IDataPacketService.
- IPluginInDataPacketService: SAL recieves the DataPacket and dispatches it to the modules listening for plug-in DataPackets. In this case OpenFlow plugin.
- OpenFlow plugin then sends the packet back to the switch from where the packet was originated.
This is as per my understanding & if you think I have missed something or you need more details and code samples, let me know.
Further to understanding the OpenFlow messages that are exchanged between hardware and a SDN Controller in Understanding OpenFlow Communication Channel, I thought it will be nice to know the sequence in which these messages are exchanged.
Based on my understanding using wireshark, a OpenFlow switch and OpenDaylight, below is a visual sequence diagram explaining major message exchanges I could see.