topic Re: VAN 2.4.3 - changing default treatment of flows in Software Defined Networking

VAN 2.4.3 - changing default treatment of flows

fwindt — Mon, 01 Dec 2014 21:26:35 GMT

Hi,

I'm trying to use HP5900AF switches together with VAN 2.4.3 in a rather specific environment where I want the switch to drop all traffic by default and only forward what has been specifically installed by a user as flows via a simple REST application. Is this possible at all, and how could I achieve that?

In hybrid.mode = true the switch install two flows, one which punts bddp packets to the controller and one which forwards flow misses as normal via usual L2 learning mechanisms. When you set hybrid.mode = false the switch installs one flow that forwards flow misses to the controller. Is there a setting somewhere that prevents any flows from being installed on join, or is it possible to edit the list of flows viewable (but not editable) via the "OpenFlow Classes" menu item down to zero?

Also is there a timeline for when the controller will support functionality such as adding/removing flows via the UI as well as storing flow tables for a switch so it can auto-install them again when the switch reboots and rejoins? That would make my REST application pretty much redundant.

Please let me know if there's any additional information I can provide.

Thanks for your time,

felix

Re: VAN 2.4.3 - changing default treatment of flows

fwindt — Tue, 09 Dec 2014 14:16:29 GMT

Is this something I should rather direct at the support chanels? Would they answer questions about the trial product?

It seems like one way around this would be to write an app InitialFlowContributor and installs a flow on each connecting instance that drops all traffic with a priority of at least 1, but it seems silly to do that rather than to have a way to disable the InitialFlowContributors that install the hybrid or non-hybrid default flows.

thanks,

felix

Re: VAN 2.4.3 - changing default treatment of flows

Carlos — Tue, 09 Dec 2014 15:18:48 GMT

Felix,

Our apology for not responding sooner. For reason we didn't see your post. I will send your request to my SDN team and one of them will contact you in regards to your post.

Best Regards,

Carlos

CoE SDN

Re: VAN 2.4.3 - changing default treatment of flows

Joetel — Tue, 09 Dec 2014 15:19:04 GMT

Hi Felix,

I'm not sure I understand your question completely, but the flows that you are observing are installed by the controller in order for it to create and maintain information about links. From the HP VAN SDN Controller 2.4 Programmers Guide , section 1.2.4.1 "About the OpenFlow Link Discovery application"

The OpenFlow Link Discovery application is the default OpenFlow link supplier application that is installed with the controller. This application implements the com.hp.sdn.supplier.LinkSuppliersBroker interface and uses LinkSupplierService and LinkService APIs to create and maintain link information for OpenFlow datapaths that register with the controller.

The OpenFlow Link Discovery application pushes flow-mods to controlled devices, injects discovery packets to all ports on all datapaths, and discovers links on the controlled network by listening for PACKET_IN messages.

If the ControllerManager configuration has hybrid.mode=true, the OpenFlow Link Discovery

application pushes a flow-mod to controlled devices that steals all controller-generated link discovery packets to the controller. If the ControllerManager configuration has hybrid.mode=false, all packets are stolen to the controller by default, so the OpenFlow Link Discovery application does not push flow-mods to devices.

These flows are essential for the functioning of the controller and therefore they are irremovable. Does this help?

Best regards,

Wouter

HP SDN CoE team

Re: VAN 2.4.3 - changing default treatment of flows

Joetel — Tue, 09 Dec 2014 15:40:33 GMT

Hi Felix,

I see that the "OpenFlow Link Discovery" and "OpenFlow Node Discovery" applications actually can be disabled in the controller UI. They do implement interfaces, so doing so might impact your and other applications on the controller.

Best regards,

Wouter

HP SDN CoE team

Re: VAN 2.4.3 - changing default treatment of flows

fwindt — Tue, 09 Dec 2014 15:51:00 GMT

It does help in understanding why this is the case. However, prompted by this I tried uninstalling all built in applications (including the node and link discovery ones) that come with the controller, and then rebooted a lab openflow switch that goes to that controller. I still found these flows to be installed by the controller, so it seems that the 'forward as normal' missrule doesn't come from the link discovery or node discovery applications.

<openflow-lab-1-sw>display openflow instance 1 flow-table
Instance 1 flow table information:

Table 0 information:
 Table type: Extensibility, flow entry count: 1, total flow entry count: 1

MissRule flow entry information:
 cookie: 0xffff000000000000, priority: 0, hard time: 0, idle time: 0, flags:
 flow_send_rem, byte count: --, packet count: 0
Match information: any
Instruction information:
 Write actions:
  Output interface: Normal

<openflow-lab-1-sw>

I'm trying to use this controller to implement a variant of Internet2's SciPass project. We have a border router connected to a core router with a layer 2 transparent inline IPS in the way. Even with inspections turned off you cannot get 10Gbps line rate through the IPS for a single flow. To support a science DMZ design we need to be able to have devices connected to the core network be able to transfer 10Gbps per flow to data transfer nodes directly off the border - so basically we want to selectively bypass the security tools.

The idea is to insert an openflow capable HP 5900AF (which we already have) and connect it to the inside and outside of the IPS as well as the core and border. Then you can install some flows with priority 100 that match all packets coming in from the core and set the output interface to the IPS inside, another that matches all packets in from the IPS outside and set the output interface to the border, and so on. And then you can install higher priority flows that match on certain IP tuples on the core input and send it directly to the border, effectively selectively bypassing the IPS.

This is all easily done via the REST API to program the flows, the main issue remaining is that if a switch reboots and joins the controller you end up either punting all flows to the controller (there is no need for that at all), or normal forwarding (which creates a switching loop that eventually leads to the core and border routers shutting down the interfaces towards the openflow switch due to the loop). It would be much nicer if the switch simply remained in its default on-boot behavior of only having a missrule that leads to drops so the links stay dead until someone brings it back up than to create a loop on controller join behavior.

I have no need for the link discovery and node discovery applications on the controller, so I don't need these default flows, either.

Is there any way to prevent them from getting installed given the above scenario and that I don't need the controller to function in a way that would require this behavior?

If not I will start looking into learning enough about the SDK to write an application that can register as a simple InitialFlowContributor that installs a higher priority drop all on switch join - unless you think that is entirely unadvisable with the HP VAN controller, in which case I'd need to find a different controller software. I'd prefer to go with HP since it matches the switch hardware and - as long as I'm not doing things outside of what is recommended - can get support for the controller.

Thanks for your time,

felix

Re: VAN 2.4.3 - changing default treatment of flows

Joetel — Tue, 09 Dec 2014 16:26:29 GMT

Hi Felix,

Thanks for the extra background information! I'm going to do some research to see if I can come up with some useful stuff. This will take a bit of time. Off the bat; Is the using the REST API a strict requirement? I think if your application was instead implemented in java on the controller (like the applications mentioned above) a lot of your concerns would be taken care of implicitly?

With the regards to the 'forward as normal' miss-rule; that is the implementation of hybrid mode; a frame that isn't matched by any other flow is handled normally by the switch. In contrast, if hybrid mode made is set to false, it would be forwarded to the controller.

Best regards,

Wouter

HP SDN CoE team

Re: VAN 2.4.3 - changing default treatment of flows

fwindt — Tue, 09 Dec 2014 17:39:19 GMT

Hi Wouter,

it's not a strict requirement as such: it mostly stems from the fact that I'm a network engineer and not a programmer ;o) I'm competent in Python and Perl for automating tasks of, uhm, moderate complexity, but haven't ever tackled Java or larger applications.

I have this working via the REST API already since that was something within what I'm comfortable with, trying to do this with a native application (and you're right - I could then just supply my baseline rules via the InitialFlowContributor hooks if I understand it right, which seems more elegant) would definitely be a *lot* more challenging and I'd be starting with "Java for Dummies" or some equivalent. I could possibly try to get one of the programmers in our organization to help out, too, but that would make this a rather big project on our side. So basically I'm just trying to take some shortcuts.

I appreciate you taking the time to research it! Thank you very much for that.

thanks,

felix

Re: VAN 2.4.3 - changing default treatment of flows

Gerhard Roets — Tue, 09 Dec 2014 20:05:28 GMT

Hi Felix

I do have two comments for quick fixes. This will definitely not be the most ellegant but it might help you while you master Java.

1. In /var/log/sdn/virgo/logs/log.log when a dpid(OpenFlow switch) connects you get a message similar to this:

Datapath added: 00:01:cc:3e:5f:11:9c:4f, neg=V_1_3, ip=192.168.2.247

So if you should have a script that tails the file. The script should also check of the file gets renamed since these log files do get archived and you do not want to be at the end of an archive file. You should be able to repush your specific flows should the controller notice the dpid reconnecting.

This is idea to help tide you over till you create the Java app.

2. The table miss flow is simple to work around, just install a flow at priority 1 in the table that matches everything with no actions and you have your drop rule and no packets will be sent to the controller.

Hope this helps a bit. The rest I will leave with Wouter :).

Kind Regards

Gerhard Roets

HP SDN TEAM

Re: VAN 2.4.3 - changing default treatment of flows

fwindt — Tue, 09 Dec 2014 20:49:45 GMT

Gerhard,

thanks for the idea, that would work well to carry me over if I do go the full Java route. I have robust Perl code that can tail log files through rollovers that's been in production use for other purposes.

Just in case anyone else is following this thread, I'm thinking it might be safer to trigger on messages such as "Datapath READY: 00:01:bc:ea:fa:05:00:36, neg=V_1_3, ip=10.32.6.3" instead as the logs indicate that the controller purges all flows and then installs the initial ones after the "Datapath added" message, and there can be up to a one second delay. Once the dpid is ready everything should have settled.

[2014-12-09 15:32:21.631] INFO  of-io-23-thread-3     hp.of.ctl       Datapath added: 00:01:bc:ea:fa:05:00:36, neg=V_1_3, ip=10.32.6.3
[2014-12-09 15:32:21.631] INFO  PhQPool-10-thread-3   hp.sdn.core     Starting Post-Handshake: 00:01:bc:ea:fa:05:00:36
[2014-12-09 15:32:22.653] ERROR PhQPool-10-thread-3   hp.sdn.dd       SNMP key not found for device 10.32.6.3
[2014-12-09 15:32:22.686] INFO  PhQPool-10-thread-3   hp.of.ctl.flow  Purge All Flows [00:01:bc:ea:fa:05:00:36] - OK
[2014-12-09 15:32:22.765] INFO  PhQPool-10-thread-3   hp.of.ctl.flow  Initial flow-rules [00:01:bc:ea:fa:05:00:36] - OK
[2014-12-09 15:32:22.766] INFO  PhQPool-10-thread-3   hp.of.ctl       Datapath READY: 00:01:bc:ea:fa:05:00:36, neg=V_1_3, ip=10.32.6.3

Wouter, still very interested in what else turns up since adding a watcher script - though it should work just fine - is a bit of a hack. But since it would work, it would probably stay in production for quite a while.....

Thanks everyone,

felix

Re: VAN 2.4.3 - changing default treatment of flows

Northbound — Tue, 06 Jan 2015 03:51:31 GMT

This might get you started - http://h30499.www3.hp.com/t5/SDN-Discussions/Flow-Maker-Flows-without-code/td-p/6690717

The next version will allow you to save flows and have them reapply after a reboot, failure, etc.

Re: VAN 2.4.3 - changing default treatment of flows

fwindt — Thu, 08 Jan 2015 17:56:23 GMT

Thanks, I will check it out! Do you have an estimate for when that version will be released? Obviously going back to a state that forwards traffic after an unexpected reboot is important.

thanks,

felix

Re: VAN 2.4.3 - changing default treatment of flows

Northbound — Thu, 08 Jan 2015 22:29:37 GMT

Hi Felix,

Flow Maker Deluxe, which will allow the creation of persistent flows, will be available in the next couple of weeks.

Regards,

Paul Zanna

Northbound Networks