Hi Marby, thanks for the note. You are indeed right. In fact, we recently had a discussion about that issue specifically, and, while I don't thing it has been addressed in NOX (not yet anyway), we took care of handling it properly in POX.
On Fri, May 25, 2012 at 12:29 AM, Mabry Tyson <[email protected]> wrote: > (I understand that nox-classic is no longer maintained. However, if pox > is using some of the same methodology, maybe this issue still exists.) > > Packets received via a Packet_In can either be dealt with by a Flow Mod > message (ofp_flow_mod) or by a Packet Out (ofp_packet_out) > message, or by not responding. > > The method of dropping packets by having an empty action list in a Flow > Mod rule is ok by OpenFlow 1.0 spec: > >> 3.3 Actions >> Each flow entry is associated with zero or more actions that dictate how >> the >> switch handles matching packets. If no forward actions are present, the >> packet >> is dropped. >> > > Suppose I get a Packet In with a packet that I want to just drop on the > floor. If I was given the full packet and got no buffer_id, then it is ok > to just ignore the packet as the switch did not keep a copy. > > But, if I got a buffer id for the packet, it is NOT ok to just not > respond. The action of the switch in such a case seems to be undefined (in > OF 1.0 at least) > >> A switch must gracefully handle the case where a bu ffered >> packet_in message yields no response from the controller. >> > It makes sense that the switch would actually deliver that packet rather > than drop it (thinking the controller was too slow to respond). > In any case, you don't want the switch hanging onto that packet buffer > when it could be freed. > > To drop the packet's buffer, without using a flow rule, I should do > something like a send the packet for this buffer_id, but with an empty > action list. > Unfortunately, it appears that the only function like that that takes a > buffer_id is send_openflow_buffer, but that function throws an error if the > action list is empty. Why it does so isn't documented in the function. I > don't see a reason for this in the OF 1.0 spec. > > As a workaround, I put in a single action of rewriting the dst MAC address > with 0. > > >
