Core ignores empty actions

[doriguzzi]

Hi,

using the composition spec at https://github.com/fp7-netide/Engine/blob/master/core/specification/TwoSwitches.xml, I noticed a strange behavior.
If the FlowMod does not carry any action (which implicitly means DROP packet), it is not considered by the core, even if the module has a higher priority.

A module with higher priority is also ignored when it does not generate any response, the core uses the response of the other module even if the latter has a lower priority.

Any idea?

[schwabe]

Yes that is kind of by design. If the core would always prefer the higher priority it would the same as specifying only the module with the higher priority or do I miss something?

[doriguzzi]

I agree with you for the case of "no answer". But I'm not sure about the case of "no actions".
From OF specification:

Required Action: Drop. There is no explicit action to represent drops. Instead, packets whose action sets have no output actions should be dropped. This result could come from empty instruction sets or empty action buckets in the processing pipeline, or after executing a Clear-Actions instruction`
In case of a Firewall application, this is the only way to drop unwanted packets.

The workaround I'm using right now is to by-pass the composition by filtering packet-ins based on DPIDs:
<?xml version="1.0" encoding="utf-8"?> <CompositionSpecification xmlns="http://netide.eu/schemas/compositionspecification/v1"> <Modules> <Module id="org.onosproject.fwd" loaderIdentification="org.onosproject.fwd" noFenceSupport="false"> <CallCondition events="packetIn" datapaths="11"/> </Module> <Module id="Firewall" loaderIdentification="firewall.py" noFenceSupport="false"> <CallCondition events="packetIn" datapaths="10"/> </Module> </Modules> <Composition> <ParallelCall resolutionPolicy="pass"> <ModuleCall module="org.onosproject.fwd" priority="1"/> <ModuleCall module="Firewall" priority="2"/> </ParallelCall> </Composition> </CompositionSpecification>

[ElisaRojas]

Hi @doriguzzi ,

I agree that drop with a higher priority should drop the packet.

@ralvarep was testing different alternatives for this scenario in https://github.com/fp7-netide/Engine/tree/master/tests and he had some issues when PacketOuts were involved (because PacketOuts are sent independently of the FlowMods' actions). But if I'm not wrong, he managed to have a switch+firewall only with FlodMods actions implemented in OF1.3 and the firewall blocked the traffic. This code should be in that tests folder in case you want to reuse it.

I'm going to talk to him and let you know in a while :)

[ralvarep]

Hi @doriguzzi @schwabe ,

I realised of this behaviour in the core a few months ago and we talk about this in the three latest messages of #110. Indeed, if there is no FlowMod message from the application with the highest priority, the FlowMod message from the lowest priority application will be considered.

I uploaded to the repository, in Engine/tests/of13-parallel-priority-firewall+switch/, a test scenario in which there are a firewall app (highest priority) and a switch app (lowest priority). When you generate explicitly a FlowMod from the firewall app with drop as an action, the core installs appropriately the drop rule from the firewall ignoring the FlowMod message from the switch app.

elif in_port == FW_OUTPORT:
  logger.debug("Droping packet from in_port %d: %s" % (in_port,repr(pkt)))
  match = parser.OFPMatch(in_port=FW_OUTPORT, eth_type = ETH_IP, eth_src=hwsrc, eth_dst=hwdst)
  actions = []
  self.add_flow(datapath, 5, match, actions, 8, 0)

actions = [] <--- NO ACTIONS = DROP

[doriguzzi]

Hi @ElisaRojas , @ralvarep ,

thanks fo the support.

When you generate explicitly a FlowMod from the firewall app with drop as an action, the core installs appropriately the drop rule from the firewall ignoring the FlowMod message from the switch app.

This is not what is happening to me. Empty actions are always overwritten by explicit actions, regardless of the priority.
Maybe something has changed in the core lately.

[ElisaRojas]

Hi @doriguzzi ,

Just to clarify, so you see all FlowMods going to the core (fwd+firewall), and only the one with explicit actions going to the network in the end? I'm asking this question because we thought that was happening at the beginning, but then we realised that the switch app was sending a PacketOut and thus traffic was not blocked because of that PacketOut (composition is not applied to PacketOuts, only to FlowMods). When we use only FlowMods (+buffer_id) in OF1.3, it worked.

But if you are sure the non-empty FlowMod is being installed, then something has changed in the core for sure... because in #110 the situation was different. @schwabe , could you clarify?

[schwabe]

I have not touched the code since then. I will try to look into it on Monday. Sorry I am busy with another higher priority work today :/

[doriguzzi]

Hi @ElisaRojas ,
I'm using OF1.0, and yes I'm sure. What I did was duplicating the simple_switch for Ryu, and then I modified one copy to make it send only empty actions. Doing this, and also swapping priorities between the two modules in the specification, I noticed this behaviour.
Ok @schwabe , no problem. For now my demo is pretty stable with the DPID-filtering.

[ElisaRojas]

Ok @doriguzzi , if you have time, I'd recommend using OF1.3 instead (which was the one working for us thanks to the buffer_id feature and the core has not changed since then). Otherwise, if you feel comfortable with your current demo, then it's ok 👍