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
