Pox breaks on barrier request error.

[castroflavio]

The pox controller is not working with HP switches for me.

Pox barrier request OF command is not supported by HP switches. The switch returns an operation not supported-ish error and the Pox controller breaks.

To fix that I commented line 126:

 assert True if (len(d) == 1) else (len(d[1].replace("\x00", "")) == 0)

In that way the controller will keep printing error messages instead of breaking. Is there a way to turn off the barrier requests on pox?

[MurphyMc]

The last time I had to deal with HP switches, they didn't support barrier (and therefore are not actually OF 1.0 compliant, I believe), but POX worked okay. There's actually a special case in the connect logic so that they work. I think the result was they printed an error to the console or something when connecting, but worked fine after that.

This case you're seeing is sort of surprising to me. Can you supply a Wireshark/tcpdump pcap trace of the controller traffic that's causing it?

[castroflavio]

<a href=https://github.com/sdn-ixp/sdx/blob/FlavioGeni/examples/GeniIXP/barrier.pcapng?raw=true>This is the packet trace:

You can see the bad_request_error_msg being print before traffic starts. (frame numbers: 4456, 4459)

Later I start sending traffic and my flow_mods are not being accepted by the switch. And traffic is being sent to the controller over and over again. Frame numbers 4923, 4980, 5029 and so on are the the flow_mod messages.

Any ideas?

Is there a way to shut down the barrier requests?

[MurphyMc]

I'm not entirely convinced the barriers are the problem. I mean... you could simply go through the code and remove whatever is generating them, but I'm doubtful that it'll help.

What components are you running? Ones you've written? Stock ones? Modified ones?

[MurphyMc]

(Also, when I load the capture in Wireshark, the frame numbers start with 1. Maybe you exported a filtered list and they got renumbered?)

[castroflavio]

You are right. The flow mods are 123, 126 and so on. Openflow errors are 113, 115, 117(for example).

I'm not familiar with pox components? I'm running an application (sdx) on top of pyretic.

[MurphyMc]

On casual inspection, it looks like it keeps trying to clear the table and reinstall the same table entry. A decent guess is that this is in response to seeing the error... the controller is possibly pushing a table entry followed by a barrier request so that if it sees the barrier reply before seeing an error, it knows the table update has been successful (otherwise it'd have seen an error from the flow-mod before the barrier reply). The fact that the barrier itself causes an error throws a wrench into this. But this logic is inside Pyretic (or SDX), not POX itself. When we've had to make POX components work with HP switches, we've actually specifically identified errors caused by barrier requests and treated them the same as the barrier reply would have been (the POX connection logic does this, for example, IIRC).

Incidentally, the reason the assertion you mention tripped is because of an unrelated way in which the HP switches are questionable. It should never really have been an assertion, since the problem is with the switch and not POX, but this predated POX's libopenflow having logging infrastructure so there wasn't another good option at the time. I've corrected this in my local branch so that it now properly issues a warning and continues. This should eventually get pushed to the eel branch of POX.

[MurphyMc]

I don't think POX was at fault for any of this, so I'm closing the issue.

[castroflavio]

This is correct. The switch used didn't support OF barriers and that caused the problem. So, Pox actually behaved properly.