Core ignores CallConditions when using OF1.3

[doriguzzi]

Hi,

I'm trying to port my demo to OF1.3. The first is step to replicate the same implementation done for OF1.0 which uses call conditions based on DPIDs.
However, if I switch to OF1.3 using the same Composition Spec (see below), the CallCondition is ignored as the two modules receive all the packetins.

Any idea?

`

  <Module id="org.onosproject.fwd" loaderIdentification="org.onosproject.fwd" noFenceSupport="false">

  		<CallCondition events="packetIn" datapaths="11"/>

  </Module>

  <Module id="FW_Router" loaderIdentification="fw_router.py" noFenceSupport="false">

  		<CallCondition events="packetIn" datapaths="10"/>

  </Module>

  <ParallelCall resolutionPolicy="pass">

      <ModuleCall module="org.onosproject.fwd" priority="1"/>

      <ModuleCall module="FW_Router" priority="2"/>

  </ParallelCall>

`

[ElisaRojas]

Hi @doriguzzi ,

I'm trying to figure it out why this could happen... but I cannot see it. The composition file looks correct.

One minor question, is fw_router.py a Ryu application valid both for OF1.0 and OF1.3? Usually, they differ in some parts of the code (OF1.3 requires initialization of the OF table to send the messages to the controller), so I'm used to change the naming when moving from OF1.0 to OF1.3, similarly to these two examples that @ralvarep uploaded:
OF1.0: https://github.com/fp7-netide/Engine/blob/master/tests/of10-parallel-priority-firewall%2Bswitch/of10-parallel-priority-firewall%2Bswitch.xml
OF1.3: https://github.com/fp7-netide/Engine/blob/master/tests/of13-parallel-priority-firewall%2Bswitch/of13-parallel-priority-firewall%2Bswitch.xml
So that's the only possibility that I can think of: that maybe that's not the correct app name and thus it receives everything because of that. But if that's ok, the only possibility is an undiscovered bug of the core so far...

[doriguzzi]

Hi Elisa,

fw_router.py is the wrong name in the composition, right. But, AFAIK, the core does not care about the filename. It only cares of the module name, which is right. Between OF1.0 and OF1.3 the only difference is the implementation of the FW_Router (same functionalities, same module name but different API) and the configuration of Mininet (OF10/OF13 switches). Everything else is the same.

Thanks for the support.

[ElisaRojas]

Yes, @doriguzzi , you're right. In fact I remember now that I used the same composition file for both Brussels demos, and in one I used OF1.0 and in the other OF1.3. The file is: https://github.com/fp7-netide/Engine/blob/master/core/specification/DpidPartitionABCW.xml
The only difference I see is the fence (which at that time was not finished)...

Could it be a bug related with the datapath numbers? Have you tried using a different one from 11? (But this would be weird anyway, as I don't think the core checks anything in relation with the OF version when loading the composition file).

Another possibility could be related with the default rules installed by ONOS at startup. Maybe the ONOS provider for OF1.3 is overriding the shim behaviour by installing some rule at startup with a higher priority that bypasses it, or something like that...

Are you sure both applications are receiving the messages directly from the core (maybe the ONOS app is bypassing it and thus "the behaviour")? We can check this via Wireshark. I can help with this if you have some traces.

Also, does this happen for both apps? I mean, for datapath 10 both receive the PacketIns, and for datapath 11 also both receive them? This is also a key. If it just happens with datapath 10, it could be something related with ONOS, but in the rest of the cases (if it happens only with datapath 11 or with both datapaths), then it could be related with the core.

[schwabe]

I cannot reproduce this. I might more information to reproduce this.

[doriguzzi]

I've done some experiments with ryu shim and backend and the java core. When I use the simple_switch (OF10) application, everything goes right:

MODULE B 11 00:00:00:00:00:e1 ff:ff:ff:ff:ff:ff 2
MODULE A 10 00:00:00:00:00:e1 ff:ff:ff:ff:ff:ff 1
MODULE A 10 00:00:00:00:00:e3 00:00:00:00:00:e1 2
MODULE B 11 00:00:00:00:00:e3 00:00:00:00:00:e1 1
MODULE B 11 00:00:00:00:00:e1 00:00:00:00:00:e3 2
MODULE A 10 00:00:00:00:00:e1 00:00:00:00:00:e3 1
MODULE B 11 00:00:00:00:00:e1 ff:ff:ff:ff:ff:ff 2
MODULE A 10 00:00:00:00:00:e1 ff:ff:ff:ff:ff:ff 1
MODULE A 10 00:00:00:00:00:eb 00:00:00:00:00:e1 4
MODULE B 11 00:00:00:00:00:e1 00:00:00:00:00:eb 2
MODULE A 10 00:00:00:00:00:e1 00:00:00:00:00:eb 1
MODULE B 11 00:00:00:00:00:e1 ff:ff:ff:ff:ff:ff 2
MODULE A 10 00:00:00:00:00:e1 ff:ff:ff:ff:ff:ff 1

when I use simple_switch_13 (OF13), this is the result (the third column indicates the DPID):

MODULE B 10 00:00:00:00:00:ea 00:00:00:00:00:eb 3
MODULE A 10 00:00:00:00:00:ea 00:00:00:00:00:eb 3
MODULE B 11 00:00:00:00:00:eb ff:ff:ff:ff:ff:ff 1
MODULE A 11 00:00:00:00:00:eb ff:ff:ff:ff:ff:ff 1
MODULE A 10 00:00:00:00:00:eb 00:00:00:00:00:ea 4
MODULE B 10 00:00:00:00:00:eb 00:00:00:00:00:ea 4
MODULE A 10 00:00:00:00:00:eb 00:00:00:00:00:ea 4
MODULE B 11 00:00:00:00:00:e1 00:00:00:00:00:ea 2
MODULE B 11 00:00:00:00:00:e1 00:00:00:00:00:ea 2

[doriguzzi]

The composition specs I used are:

<?xml version="1.0" encoding="utf-8"?>
<CompositionSpecification  xmlns="http://netide.eu/schemas/compositionspecification/v1">
  <Modules>
      <Module id="SimpleSwitch10a" loaderIdentification="simple_switch_10a.py" noFenceSupport="false">
      		<CallCondition events="packetIn" datapaths="10"/>
      </Module>
      <Module id="SimpleSwitch10b" loaderIdentification="simple_switch_10b.py" noFenceSupport="false">
      		<CallCondition events="packetIn" datapaths="11"/>
      </Module>
  </Modules>
  <Composition>
      <ParallelCall resolutionPolicy="priority">
          <ModuleCall module="SimpleSwitch10a" priority="1"/>
          <ModuleCall module="SimpleSwitch10b" priority="2"/>
      </ParallelCall>
  </Composition>
</CompositionSpecification>

and

<?xml version="1.0" encoding="utf-8"?>
<CompositionSpecification  xmlns="http://netide.eu/schemas/compositionspecification/v1">
  <Modules>
      <Module id="SimpleSwitch13a" loaderIdentification="simple_switch_13a.py" noFenceSupport="false">
      		<CallCondition events="packetIn" datapaths="10"/>
      </Module>
      <Module id="SimpleSwitch13b" loaderIdentification="simple_switch_13b.py" noFenceSupport="false">
      		<CallCondition events="packetIn" datapaths="11"/>
      </Module>
  </Modules>
  <Composition>
      <ParallelCall resolutionPolicy="priority">
          <ModuleCall module="SimpleSwitch13a" priority="1"/>
          <ModuleCall module="SimpleSwitch13b" priority="2"/>
      </ParallelCall>
  </Composition>
</CompositionSpecification>

Nothing changes if I remove the composition part of the specification

[doriguzzi]

Hi @ElisaRojas ,

Yes, @doriguzzi , you're right. In fact I remember now that I used the same composition file for both Brussels demos, and in one I used OF1.0 and in the other OF1.3. The file is: https://github.com/fp7-netide/Engine/blob/master/core/specification/DpidPartitionABCW.xml
The only difference I see is the fence (which at that time was not finished)...

If I remove it, nothing changes

Could it be a bug related with the datapath numbers? Have you tried using a different one from 11? (But this would be weird anyway, as I don't think the core checks anything in relation with the OF version when loading the composition file).

Well, it works with the same numbers with OF10...

Another possibility could be related with the default rules installed by ONOS at startup. Maybe the ONOS provider for OF1.3 is overriding the shim behaviour by installing some rule at startup with a higher priority that bypasses it, or something like that...

As I wrote in the post above, I tried with Ryu as a server controller, but I obtain the same result.

Are you sure both applications are receiving the messages directly from the core (maybe the ONOS app is bypassing it and thus "the behaviour")? We can check this via Wireshark. I can help with this if you have some traces.

In the case, when I use just Ryu as client and server, I do not have any app running on the server, just two applications on the client

Also, does this happen for both apps? I mean, for datapath 10 both receive the PacketIns, and for datapath 11 also both receive them? This is also a key. If it just happens with datapath 10, it could be something related with ONOS, but in the rest of the cases (if it happens only with datapath 11 or with both datapaths), then it could be related with the core.

Yes, as you can see in the log above.

Thanks again for the support

[doriguzzi]

Just tested the same configuration with the Python Core, and in this case it works properly.

[schwabe]

@doriguzzi do you have the version of the backend that shows the packetIns in this form

MODULE B 10 00:00:00:00:00:ea 00:00:00:00:00:eb 3
MODULE A 10 00:00:00:00:00:ea 00:00:00:00:00:eb 3

somewhere available for me? So I can a look what happens for me?

[schwabe]

I just commited a fix for this (or that might fix this)