Dropping packet-out

[ItamarTal]

While handling a packet-in event from within the event handler of a SequencedPacketListener, I want to tell the controller to discard the packet-out and not send it back to the data-path. Is there any possible way of doing so? All I could find in the progremming guide is how to make the switch to block next sequencers from changing the packet-out.

Itamar Tal

[sepbot]

According to the apidocs, Packet_Out only happens if you return true in your event() method with the DIRECTOR role. So just return false and it shouldn't send the packet back out to the network. If you have Path Daemon running, that might be doing some Packet_Outs; you could always disable that in the Applications menu.

[ItamarTal]

As I understand from the programming guide, returning false from the event() handler by a DIRECTOR makes the controller send the packet out with the current added actions (no more actions can be added later by lower altitude directors), which means in fact that the packet-out is sent. Empirically, this is what happens when I return false.

from the progremming guide:

"...The return value from a DIRECTOR’s event() callback should be true if it is determined that the packet has been "handled" (i.e. the PACKET_OUT message is ready to send); false otherwise..."

[sepbot]

Yeah you are right. Just went through the apidocs and seems like I misunderstood the documentaion when I read it the first time.

The PacketOut in the MessageContext is mutable but looks like the only method that is exposed in the API is addAction, which doesn't help you.

[RuDr]

Hi ItamarTal,

in reading thru this thread, it doesn't seem like your original question was answered.  do you still need help on this?

-Russ

[ItamarTal]

Actually, I'd realy appriciate an answer for this question. Currently, to avoid packet_in events from generating a packet_out message on the in_port data-path I use all kind of "hacks". Couldn't find a programatic solution for avoiding packet_out's from being sent.

Have a great weekend,

[Javed Padinhakara · Accepted solution]

one possible approach could be to register your app with higher altitude than PathDaemon, and create an action with DROP, and return TRUE in event()...the end-result would be the packet-out would still go out, but would be dropped at the switch....which kind of meets your objective.....

would'nt that help?

[ItamarTal]

This is the "hack" I'm currently using, but you must agree that there should be a better way to avoid packet_out in future versions of the controller.

[sdnindia]

Hello Itamar Tal,

Apologize for the delay here. We had to get in touch with internal teams for a response

Currently we do not have this feature but there are additions under consideration to the PacketOut API to allow the following, in addition to the current addAction() method

// removes any accumulated actions, but allowing subsequent directors to add other actions and send the packet out

clearActions()

// blocks any other director from issuing packet-out response; non-reversible

block()

Hope this helps.

Please let us know if your problem is solved.

Please feel free to reply incase you have more questions around the same topic or open a new thread if new topic.

If you feel your question has been answered, please do let us know by marking this response as an  accepted solution.

Thanks
HP SDN Team

[LSP42]

Hi all,

I'm wondering if there has been any movement with this thread and further development of the Java APIs? I'm interested in creating flows that can be used to just throw frames away via OpenFlow (i.e. null route, or throw in a bit bin) OpenFlow. I appreciate that via the director role I can just return true to the packetlistener event and not handle it, but I want something in the fastpath (i.e. not being punted up to the controller). I did consider creating a flow that never times out which pushes traffic to a packet collector of some description for analysis, but it's a kludge as opposed to something desirable. The other work around mentioned also does not resolve this situation.

Any thoughts?

Thanks

David

@LSP42

[LSP42]

When I read this originally, I interpreted the issue to be in dropping packets via a flow entry (and not being able to create the drop action). After reading this the morning after the night before, I now see the original question. The original poster is querying how to drop the event and halt further directors from getting it. Sorry for the confusion.