Barrier request error using pox

[castroflavio]

Hi,

I'm trying to track the source of this bug.

When using an HP switch, my application (sdx) is not being able to install flow rules in the switch. The standard mac_learning application works fine. I think there's something related to the use of barrier request before installing the flows. We might be triggering it in our code somewhere.

I'm not really proficient with pyretic, has anyone ever had problems with barrier requests before?

[ngsrinivas]

Flavio,

Pyretic uses barrier requests when installing rules to ensure that switches are completely cleared of the previous rules first. However I'm not specifically aware of previous issues people may have had with barrier requests. @joshreich any thoughts?

[castroflavio]

The weird thing is that the mac_learning module works fine.

My first guess was that the sdx application was injecting an OpenFlow error somewhere. But that doesn't make a lot of sense because it's just an application on top of pyretic.

My second guess is that the switch is not supporting one of Openflow actions we are using.

[AghOmid]

Flavio,

You can see the list of OpenFlow actions that Pyretic uses in the
of_client/pox_client.py
https://github.com/frenetic-lang/pyretic/blob/master/of_client/pox_client.py#L100-L143,
from line 100 to 140.

On Mon, Jan 19, 2015 at 9:18 AM, Flavio Castro notifications@github.com
wrote:

The weird thing is that the mac_learning module works fine.

My first guess was that the sdx application was injecting an OpenFlow
error somewhere. But that doesn't make a lot of sense because it's just an
application on top of pyretic.

My second guess is that the switch is not supporting one of Openflow
actions we are using.

Reply to this email directly or view it on GitHub
#40 (comment)
.

[joshreich]

Flavio,

I’m not aware of anyone who has encountered this problem previously, though it’s not surprising that that you’d run into to trouble if your target switch doesn’t conform to the OF spec ;-)

What I’d suggest is commenting out the barrier (line 138 in the code section Omid references below) and see if that gets rid of the error messages. Of course, w/o the barrier command, there are certain types of weird behavior that can’t be avoided (e.g., inconsistent rulesets installed on switches when policy changes quickly).

-Josh

From: Omid [mailto:notifications@github.com]
Sent: Monday, January 19, 2015 9:25 AM
To: frenetic-lang/pyretic
Cc: Joshua Reich
Subject: Re: [pyretic] Barrier request error using pox (#40)

Flavio,

You can see the list of OpenFlow actions that Pyretic uses in the
of_client/pox_client.py
https://github.com/frenetic-lang/pyretic/blob/master/of_client/pox_client.py#L100-L143,
from line 100 to 140.

On Mon, Jan 19, 2015 at 9:18 AM, Flavio Castro <notifications@github.commailto:notifications@github.com>
wrote:

The weird thing is that the mac_learning module works fine.

My first guess was that the sdx application was injecting an OpenFlow
error somewhere. But that doesn't make a lot of sense because it's just an
application on top of pyretic.

My second guess is that the switch is not supporting one of Openflow
actions we are using.

Reply to this email directly or view it on GitHub
#40 (comment)
.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/40#issuecomment-70530165.

[castroflavio]

I still haven't tried what joshreich suggested but I'll do it soon.

Interesting/weird fact: I was testing if the switch supports mac modifications and I figured that we fail to install them in the HP switch using the r0 mode(-m r0). When using -p0, they are successfully installed.

While for mac_learning, both work.

I'm gonna look into the code and try to figure out why that is happening.

[ngsrinivas]

What do you mean by "mac modifications"?

For a static policy, reactive0 mode doesn't invoke barriers once all switches have come up, so my guess is that things could be failing for other reasons. Mac_learner on the other hand is a dynamic policy which invokes barriers each time the policy is updated.

Anyway, do let us know what you find :)

[castroflavio]

By mac modifications I mean this: modify(srcmac=EthAddr('00:00:00:00:00:01')).

[joshreich]

And can you clarify what you mean by ‘fail to install’? It is good that things are working when you use p0 mode---that is the mode that should be default, we may deprecate r0 in the near future as most of our development focus has been on p0 over the last several months.

From: Flavio Castro [mailto:notifications@github.com]
Sent: Tuesday, January 20, 2015 8:45 AM
To: frenetic-lang/pyretic
Cc: Joshua Reich
Subject: Re: [pyretic] Barrier request error using pox (#40)

By mac modifications I mean this: modify(srcmac=EthAddr('00:00:00:00:00:01')).

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/40#issuecomment-70687136.

[castroflavio]

I mean that the flow rules are not being installed in the switch: the switch repeatedly sends the packets to the controller, who repeatedly sends flow_mod and packet-out messages.

[joshreich]

Interesting, that’s also a new bug, though since r0 is basically deprecated, I doubt we will spend the time to fix.

-Josh

From: Flavio Castro [mailto:notifications@github.com]
Sent: Tuesday, January 20, 2015 10:30 AM
To: frenetic-lang/pyretic
Cc: Joshua Reich
Subject: Re: [pyretic] Barrier request error using pox (#40)

I mean that the flow rules are not being installed in the switch: the switch repeatedly sends the packets to the controller, who repeatedly sends flow_mod and packet-out messages.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/40#issuecomment-70705857.