opendaylightopenflowopenvswitch

Efficiently installing flows on OVS devices, Packet In Processing, worth is to use Oxygen over Neon/Sodium


So I moved to a new version of OpenDayLight, im currently using Neon (Sodiums api explorer wasnt working for whatever reason but im trying again today).

I remember older versions of OpenDayLight had a L2Switch but I guess it is no longer supported, I was messing around last night installing flows so 2 hosts on a single switch can communicate. I was doing this through restconf and the md-sal:add-flow or whatever its called and it wasnt very efficient but it did work and I was able to pass traffic.

I may write my own L2 learning code cause ive done it for other controllers and its fairly easy but it seems like that is an outdated approach to getting reachability in an SDN network and im starting to feel like im missing something.

Is there some feature in ODL Sodium/Neon that handles ARP for hosts, or does some type of L2 learning? If not, whats an effective way of installing flows into a network, specifically a Data centre style network with lots of switches. Manually installing flows on one switch was bearable but once my hardware is ready we will have 8 physical OVS devices and installing flows one at a time on each using rest may kill me lmao.

Also, I've been looking around here and through project code for Packet IN handling on the controller, I will need to do this if I do L2 learning and my main goal with ODL is to develop some type of network security application.

If im not mistaken, when an OVS device receives a packet it doesn't know how to forward, it will send it to the controller and the controller will make a decision and install the flow on the switch for future packets. I know how to install the flow, im just a little lost on where to put the code to check the packet and decide what to do with it. In POX it was easy, pretty much just a PacketIn function that you would override, hopefully its something similar with ODL

It also appears Oxygen still has L2Switch, if I have a large topology that I cant manually install flows in, would it be worth it to downgrade to oxygen for L2 functionality?


Solution

  • yeah, I think what you really want is l2switch. that project was always the quick project to install with OpenDaylight to show some quick SDN functionality (using mininet), but it was not really maintained in the upstream community so we removed it. However, there has been talk lately of trying to keep it alive so at least it can be released and installed in future ODL versions.

    would you consider helping in that effort? If so, you could get l2switch working again the latest master branch (what will be the magnesium release) and possibly in to one of the final sodium service releases (SR). I don't know all that's needed to make that happen, but I think it may not be too hard.

    taking that one step back would really help the upstream ODL community, but hopefully give you what you need in the short term with a newer ODL release as well as some more experience with the overall ODL code-base.

    If not, you are on the right track with programming flows with restconf. You don't have to use md-sal:add-flow necessarily, you can just add the flows you want in the config store and as long as the openflow node exists, the openflowplugin should program it down on the ovs switch. Here is a test case that adds the "punt to controller" flow that you refer to. just drill down in to the robot framework keywords to get more details. like here is the PUT request URI and here is the body sent.