[pox-dev] how to specify wildcards in ofp_match.from_packet()?

[William Emmanuel S. Yu]

Oh my. Definitely a great point I missed out.  So does this mean there is no solution that allow us to a good destination-only flow rule at L2? So source awareness is mandatory to ensure "learning". 

Thanks.
"Sent on the move."

-----Original Message-----
From: Murphy McCauley <murphy.mccauley at gmail.com>
Date: Mon, 24 Sep 2012 04:40:08 
To: <wyu at ateneo.edu>
Cc: <pox-dev at lists.noxrepo.org>
Subject: Re: [pox-dev] how to specify wildcards in ofp_match.from_packet()?

Imagine even a simple case where you have two hosts, A and B, connected to a single switch that starts with an empty table.

1. A sends to B.  This misses the table, so at the controller you see the packet, and learn what port A is on.  You install a rule that matches destination A and flood the packet because you don't know where B is.

2. Now B sends to A.  This hits the "to A" rule, so the packet is forwarded to A.

3. A sends to B again.  You still don't know where B is, so this ends up pretty much just like step #1.  You flood the packet again.

The observation is that by installing a destination-only rule, you now lose visibility at the controller of every packet to that destination, which may well prevent you from learning other senders.  In the example above, you'll NEVER learn where B is.

There are variations on this depending on what you do or don't know about the hosts in your network, etc., of course.  But in the generic "learning switch" category, it's just not a great idea.  Ultimately, packet_ins aren't really a great tool for doing learning (though they're what we've got, at least as far as the 1.0 spec goes).  

-- Murphy

On Sep 24, 2012, at 4:21 AM, William Emmanuel S. Yu wrote:

> Hi Murphy,
> 
> Thanks for the confirmation. I think I made the mistake of looking at the spec first to find a way of doing something. In this case, pox provided a really useful convenience mechanism.
> 
> I was thinking of demonstrating a "performance" and "detail" trade-off. By using a complete match, we can count packets per flow. By using a specific match, results are aggregated but the number of PacketIn's are reduced. (This is for my materials to introduce my students to openflow. It is a series of laboratory exercises).
> 
> Is there any other nuance I need to consider?
> "Sent on the move."
> 
> -----Original Message-----
> From: Murphy McCauley <murphy.mccauley at gmail.com>
> Date: Mon, 24 Sep 2012 02:43:37 
> To: <wyu at ateneo.edu>
> Cc: <pox-dev at lists.noxrepo.org>
> Subject: Re: [pox-dev] how to specify wildcards in ofp_match.from_packet()?
> 
>> I want the other way around.
> 
> I was thinking something seemed a little off there. :)
> 
>> So I None all the other fields? Is there a way to create a match object that allows any match by default?
> 
> 
> Yes, you could None all the other fields, but as you say, it would be easier to create a match object that matches all by default.  Luckily, this is exactly what happens if you just create a new match!  from_packet() is just a helper which automatically stocks the match from a packet object.  In your case, you really don't WANT it to be stocked from a packet object except for a single field, so you just create an empty match and set that one field:
> 
> msg.match = of.ofp_match()
> msg.match.dl_dst = packet.dst
> 
> Indeed, the flow mod already creates such an empty match object, so you don't even need to do it yourself:
> msg = of.ofp_flow_mod()
> msg.match.dl_dst = packet.dst
> 
> 
> Note, by the way, that creating a learning switch that just matches based on destination address is generally not a good idea or at least takes some subtlety.  I won't spoil the fun of figuring out why that is if you haven't figured it out already, but I'll point out that the L2 switch in POXDesk installs rules based on source/dest *pairs*.
> 
> -- Murphy
> 
> On Sep 24, 2012, at 2:26 AM, William Emmanuel S. Yu wrote:
> 
>> I want the other way around. So I None all the other fields? Is there a way to create a match object that allows any match by default?
>> 
>> Tnx.
>> "Sent on the move."
>> 
>> -----Original Message-----
>> From: Murphy McCauley <murphy.mccauley at gmail.com>
>> Date: Mon, 24 Sep 2012 02:05:25 
>> To: William Emmanuel Yu<wyu at ateneo.edu>
>> Cc: <pox-dev at lists.noxrepo.org>
>> Subject: Re: [pox-dev] how to specify wildcards in ofp_match.from_packet()?
>> 
>> On Sep 24, 2012, at 1:51 AM, William Emmanuel Yu wrote:
>>> I want to be able to do something like this.
>>> 
>>>    msg.match = of.ofp_match.from_packet(packet, 
>>>      wildcards = OFPFW_DL_DST)
>>> 
>>> The wildcard OFPFW_DL_DST only matches the destination ethernet address.
>>> This way the flow is more generic so any packet to that particular
>>> destination ethernet address in the switch does not generate a PacketIn.
>> 
>> You're making it too hard for yourself. ;)  Try something like...
>> 
>> msg.match = of.ofp_match.from_packet(packet)
>> msg.match.dl_dst = None
>> 
>>> Currently, the ofp_match.from_packet() function does not accept
>>> wildcards. As a matter of fact, I can't seem to find the appropriate
>>> function that allows us to define wildcards.
>> 
>> In general, any fields set to None are wildcarded. This is mentioned on the wiki in the section describing the match structure, but it's possible more attention could be drawn to it:
>> https://openflow.stanford.edu/display/ONL/POX+Wiki#POXWiki-MatchStructure
>> 
>> It's a little more tricky for IP addresses which can wildcard part of the field, but not especially.   (Just use a tuple of address,bits or a CIDR-style address/bits string, the result of lib.addresses.parseCIDR(), etc.)
>> 
>>> Additionally, wildcards
>>> such as OFPFW_DL_DST or OFPFW_ALL are not global and accessible in my
>>> code.
>> 
>> You basically don't need them because of the automatic wildcarding of None entries and direct support for CIDR addresses and whatnot.
>> If you DO really want them, if you have libopenflow imported as "of" (as per POX convention), these should be on there, e.g., of.OFPFW_DL_DST.
>> 
>> 
>> Hope that helps.
>> 
>> -- Murphy
>