[pox-dev] Forwarding L2 Learning Example Behavior

[William Emmanuel S. Yu]

Hi Murphy,

Let me try modifying the example to display the different parameters and allow for ANY_IP and ANY_PORT to behave like a typical L2 only switch. Are those the other things affected?

On the monitoring solution, is there an example in Pox for obtaining flow counters?

Thanks.
"Sent on the move."

-----Original Message-----
From: Murphy McCauley <murphy.mccauley at gmail.com>
Date: Thu, 6 Sep 2012 21:40:42 
To: William Emmanuel Yu<wyu at ateneo.edu>
Cc: <pox-dev at lists.noxrepo.org>
Subject: Re: [pox-dev] Forwarding L2 Learning Example Behavior

On Sep 4, 2012, at 7:20 PM, William Emmanuel Yu wrote:

> I am new to openflow and pox and have gone through the openflow tutorial
> that uses pox. I would like some clarification on the behavior of
> "installing a flow". It is my assumption that if the flow is present in
> the switch then that switch won't do a packet_in anymore to the openflow
> controller. However, the log below shows that even if the flow already
> is in the switch it still triggered a packet_in. Is that the intended
> behavior for ovsk? 
> 
> The output:
> POX> INFO:openflow.of_01:[Con 1/1] Connected to 00-00-00-00-00-01
> DEBUG:forwarding.l2_learning:Connection [Con 1/1]
> DEBUG:forwarding.l2_learning:installing flow for 00:00:00:00:00:03.2 ->
> 00:00:00:00:00:02.1
> DEBUG:forwarding.l2_learning:installing flow for 00:00:00:00:00:02.1 ->
> 00:00:00:00:00:03.2
> DEBUG:forwarding.l2_learning:installing flow for 00:00:00:00:00:03.2 ->
> 00:00:00:00:00:02.1

l2_learning installs exact matches -- not just on MAC address, but on IP addresses, TCP ports, etc.  However, the log messages only reflect the MAC addresses.  Thus, you may see log entries with duplicate MAC addresses, but other fields will be different.  Also, these entries eventually expire.  This is easy to see with the upcoming GUI... it might also be easy to see with the current GUI, but I am not sure (you could try it out).

You could certainly write a switch that worked a different way (e.g., installed rules based only on MAC addresses), which would behave differently.

> Finally, what is the best way to implement a traffic monitoring solution
> using openflow if all packets do not generate a packet_in as intended?

Depending on exactly what you want, OpenFlow might or might not be a good tool for the job.

If OpenFlow is workable, it's probably because you can use the packet or byte counter statistics for table entries -- install flow entries, and query them periodically to see the counters.


Hope that helps.

-- Murphy