Dropping Packets + Platform Architecture Clarification

[ssrirama]

Hi all,

I wanted to clarify something regarding the SDN architecture on this platform. As I understand it, whenever a switch gets a processing request for a packet from one of the host machines connected to it, it will check a table to see if it has flows/instructions on how to handle the packet. If it doesn't, it reaches to the controller for instructions.  The controller runs the request through the applications loaded on it (from highest to lowest altitude/priority). Once the packet is processed, the instructions are sent back to the switch. When this happens, does the controller load a flow automatically onto the respective switch? Or are any actions attached to the packet during processing only valid for that instance of the packet?

Ultimately, I want to create an application that drops packets based on whether they meet a criteria. Currently, my application registers itself as a packet listener with altitude 100000; the event() method should be triggered whenever a packet needs to be processed. As a start, I'm just focusing on having my application drop everything and anything. In my event method, I use the PacketOut API to clear actions from the packet and block other directors from adding actions to it. This successfully compiles, loads onto the controller, and deploys. However, when I test it (I use Mininet as my testing platform), Mininet reports 0% packet loss. Shouldn't the packet be dropped? If not, how can I load a DROP action/flow to the switch so that the packet doesn't get through.

[piricchio72]

Hello,

Switch behavior depends from its capabilities.

A pure openflow switch would be unable to take any decision without an existing flow.

Hybrid forwarding mode would instead allow traffic to be handled via the normal routing and switching pipeline if no flow entry exists.

Concerning your application I would like to understand:

1) version of Mininet ?

2) OF version negotiated from the mininet switches and the controller?

(you can configure mininet to used version 2.3 of Openvswitch, hence the question)

3) when you test your application can you see flows being added to the switches in your topology?

Can you eventually provide your code for further testing?

Regards,

Antonio

SDN CoE Team

[ssrirama]

1)  v2.2.0

2)  v1.0.0

3) Yes

Code attached. Is compatible with v2.3.5 of the controller and SDK and compiles, loads, and deploys to the controller without issue.

[ssrirama]

Apparently Mininet does indeed have its own built-in forwarding capabilities. If there is no controller, the switches are layer 2 capable. With this in mind, how do I programmatically construct a DROP packet flow and load it onto the switches? I've tried to find code for this on other posts in this forum but haven't found anything definitive.

[piricchio72 · Accepted solution]

Hello ssrirama 

I managed to build and upload your application to the my controller.

When I started mininet I noticed that packets were actually dropped (pings between hosts were constantly failing).

I then noticed that , due to previous tests my controller was set to HYBRID mode FALSE (default value is TRUE).

As said in my previous post when hybrid mode is enabled, NORMAL switching will still be possible as shown in the hybrid_true.png.

When Hybrid mode is enabled (set to true in the Configurations page ) instead all packets will be send to the controller and no normal forwarding is possible (as shown in hybrid_false.png).

In this condition your code will prevent switches and hosts to communicate and you will see mininet dropping packets.

I also attached hybrid_mode.png showing where you can modify this setting.

Please let me know whether this helps you

Antonio

SDN TEAM