Open castroflavio opened 9 years ago
ngsrinivas
commented
9 years ago 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
commented
9 years ago 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
commented
9 years ago 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 https://github.com/frenetic-lang/pyretic/issues/40#issuecomment-70529109 .
joshreich
commented
9 years ago 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.com<mailto: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 https://github.com/frenetic-lang/pyretic/issues/40#issuecomment-70529109 .
— Reply to this email directly or view it on GitHubhttps://github.com/frenetic-lang/pyretic/issues/40#issuecomment-70530165.
castroflavio
commented
9 years ago 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
commented
9 years ago 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
commented
9 years ago By mac modifications I mean this: modify(srcmac=EthAddr('00:00:00:00:00:01')).
joshreich
commented
9 years ago 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/frenetic-lang/pyretic/issues/40#issuecomment-70687136.
castroflavio
commented
9 years ago 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
commented
9 years ago 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/frenetic-lang/pyretic/issues/40#issuecomment-70705857.
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?