Using composition with two apps (FW & SW)

[ralvarep]

Hi,

I am testing the Java Core using composition with two apps on the same switch. I am using OF10, the apps are switch and firewall and my topology is very simple: Alice (00:00:00:00:00:e1) <==> SW <==> Bob (00:00:00:00:00:e2)

When I use separately these apps I have the following results:

• With SW app I create flow rules with timeout 4 sec, for example:

NXST_FLOW reply (xid=0x4):
 cookie=0x0, duration=1.574s, table=0, n_packets=1, n_bytes=98, idle_timeout=4, idle_age=1, in_port=2,dl_dst=00:00:00:00:00:e1 actions=output:1
 cookie=0x0, duration=1.572s, table=0, n_packets=1, n_bytes=98, idle_timeout=4, idle_age=1, in_port=1,dl_dst=00:00:00:00:00:e2 actions=output:2

• With FW app, by default I deny the traffic from Alice to Bob, but if Bob ping Alice, it will create a temporary window with timeout 8 sec, for example:

NXST_FLOW reply (xid=0x4):
 cookie=0x0, duration=4.493s, table=0, n_packets=0, n_bytes=0, idle_timeout=8, idle_age=4, ip,in_port=2,dl_src=00:00:00:00:00:e2,dl_dst=00:00:00:00:00:e1 actions=output:1
 cookie=0x0, duration=4.493s, table=0, n_packets=1, n_bytes=98, idle_timeout=8, idle_age=4, ip,in_port=1,dl_src=00:00:00:00:00:e1,dl_dst=00:00:00:00:00:e2 actions=output:2

When I use these apps together (fw app with high priority) in the next composition file...

<?xml version="1.0" ?>
<CompositionSpecification
        xmlns="http://netide.eu/schemas/compositionspecification/v1">
    <Modules>
        <Module id="Firewall" loaderIdentification="firewall.py"
                noFenceSupport="false">
            <CallCondition events="packetIn" datapaths="1"/>
        </Module>
        <Module id="SimpleSwitch" loaderIdentification="simple_switch.py"
                noFenceSupport="false">
            <CallCondition events="packetIn" datapaths="1"/>
        </Module>
    </Modules>
    <Composition>
        <ParallelCall resolutionPolicy="priority">
            <ModuleCall module="SimpleSwitch" priority="1"/>
            <ModuleCall module="Firewall" priority="5"/>
        </ParallelCall>
    </Composition>
</CompositionSpecification>

... it appears the following flows:

NXST_FLOW reply (xid=0x4):
 cookie=0x0, duration=1.193s, table=0, n_packets=1, n_bytes=98, idle_timeout=4, idle_age=1, in_port=1,dl_dst=00:00:00:00:00:e2 actions=output:2
 cookie=0x0, duration=1.160s, table=0, n_packets=1, n_bytes=98, idle_timeout=5, idle_age=1, ip,in_port=2,dl_src=00:00:00:00:00:e2,dl_dst=00:00:00:00:00:e1 actions=output:1
 cookie=0x0, duration=1.160s, table=0, n_packets=0, n_bytes=0, idle_timeout=5, idle_age=1, ip,in_port=1,dl_src=00:00:00:00:00:e1,dl_dst=00:00:00:00:00:e2 actions=output:2

As a result:

1. The ping from Alice to Bob works, and it should not work. Why? Maybe because my fw app doesn't reply any FLOW_MOD when it wants to deny some flow...
2. Suddenly there are rules with idle_timeout = 5, the core is the responsible of creating rules with this idle_timeout? (my apps create flow rules with timeout 4 sec and 8 sec).

Someone with the same problems? Does anyone know what happens? Thanks in advance!

[ElisaRojas]

Hi @schwabe , any help on the behaviour of the core regarding this would be really appreciated :) We're particularly surprised by the value idle_timeout=5 because the apps we are running have idle_timeout either 4 or 8.

Also, one extra note regarding @ralvarep tests, when we use a higher priority for SimpleSwitch, everything works fine.

Thanks!

[schwabe]

@ralvarep The core should tell out you what flow mods are used. In the priority mode the core should not modify flows at all.

The firewall.py that is the repo does set idle_timeout to 5:

            match = datapath.ofproto_parser.OFPMatch(in_port=FW_OUTPORT, dl_type = ETH_IP, dl_src=haddr_to_bin(hwdst), dl_dst=haddr_to_bin(hwsrc))
            actions = [datapath.ofproto_parser.OFPActionOutput(FW_INPORT)]
            self.add_flow(datapath, match, actions, 5, 0)

Notice the 5 there. Unless you use a modified firewall that should work.

And please include information like what excat version of the app you are using or the core log in the issue. At the moment I can only guess :(

[ElisaRojas]

Hi @schwabe , @ralvarep is using a modified version with timeout 8, but you're right, we should upload the specific components and files to help debugging.

@ralvarep , how about creating a "tests" folder in the Engine repo and there you can add the different scenarios? :) Thank you!

[ralvarep]

Hi @schwabe, about the problem related to timeout 5 sec that I mentioned before, it was a problem that I had with permissions and the ryu backend was using a compiled version of the firewall with timeout 5, so this problem is solved.

I have just uploaded the scenarios. As @ElisaRojas mentioned, I am testing the composition when there are two apps running (fw and sw) on the same switch.

• In the first scenario (Engine/tests/parallel-switch+firewall/), the switch app has more priority than the firewall app. In this case, in my opinion the java core works appropriately, and in all the situations the core decided to create the flow rules from the switch app.
• In the second scenario (Engine/tests/parallel-firewall+switch/), the firewall app has more priority than the swtich app. By default the traffic from Alice to Bob is blocked, but if Bob pings Alice, it will create a temporary window with timeout 8 sec. The problem here is that with the composition the core creates a rule (from sw app) in spite of the high priority of the firewall app. The flow table of the switch when you execute pingall is the following:

# ovs-ofctl dump-flows s1
NXST_FLOW reply (xid=0x4):
 cookie=0x0, duration=1.258s, table=0, n_packets=1, n_bytes=98, idle_timeout=4, idle_age=1, in_port=1,dl_dst=00:00:00:00:00:e2 actions=output:2
 cookie=0x0, duration=1.246s, table=0, n_packets=1, n_bytes=98, idle_timeout=8, idle_age=1, ip,in_port=2,dl_src=00:00:00:00:00:e2,dl_dst=00:00:00:00:00:e1 actions=output:1
 cookie=0x0, duration=1.246s, table=0, n_packets=0, n_bytes=0, idle_timeout=8, idle_age=1, ip,in_port=1,dl_src=00:00:00:00:00:e1,dl_dst=00:00:00:00:00:e2 actions=output:2
 cookie=0x0, duration=2830.634s, table=0, n_packets=183, n_bytes=12478, idle_age=1, priority=0 actions=CONTROLLER:65535

Why happens this? Maybe because the firewall app doesn't reply any FLOW_MOD when it wants to deny some flow...

Thanks @schwabe!

[schwabe]

Yes, that is exactly what the priority resolution algorithm is supposed to do. If there nothing from an app with a high priority the flows of the lower priority app are considered. Otherwise the priority would make no sense at all since you could just use the high priority app alone.

To reiterate that for your example: If both app reply, only the reply of the higher priority app (FW) is used. If only one app replies that reply is used.

[ralvarep]

Thanks for the clarification @schwabe. I have tested another firewall app in which it creates a flow rule with drop as an action when it wants to deny the traffic, and the core installs appropriately the flow mod from the firewall ignoring the flow mod from the switch app.

I close this issue.