[pox-dev] l2_learning flow installation

[Murphy McCauley]

On May 27, 2015, at 1:39 PM, Adam Pavlidis <adampavlidis at gmail.com> wrote:

> 
> Are you using l2_learning and only l2_learning?
>  
> I am using  l2_learning, log.level with --DEBUG flag, and a custom module that only handles Flow Removed events (only to print them)
> 
> 
> 
> Are you sure?  Try monitoring the OpenFlow connection to the controller (this can be done with Wireshark, for example, or with a little modification to POX).  Do you see packet-ins with the ARPs in them?
> 
> Sorry you are right, by using Wireshark with OF dissector i see the packet In messages containing arp. 
> However, since the hosts don't exchange ARP Messages, but POX receives Packet In messages were do these messages come from? 
> Also, why the ARP request packets encapsulated in Packet In target a specific MAC, as opposed to usual ARP request targeting every MAC? Is it a "keep-alive" like mechanism for ARP Cache entries, or am i way off base?

Are you sure they're not?  You've inspected the right interfaces with Wireshark or whatever?  I am guessing they are there.  (And that Linux's ARP logic is not as straightforward as one might imagine.)

> The direct answer to your question of whether they should be identical... ideally, yes.  But in the real world, it's not realistic.  There are a number of things which make this difficult (involving all three of the OpenFlow specification, switch implementations, and tradeoffs in POX).  For the particular case of matching flow-mod and flow-removed matches, there's an easy and foolproof method that can generally be applied: associate them via the cookie instead of the match.  This is way more robust.  (Unfortunately the same can't be done with 1.0 packet-ins except for switches that support the Nicira extended packet-in, IIRC.)
> 
> In this specific case, it looks like my original from_packet() code (2f296eba31) didn't set vlan_pcp here, since it's also explicitly setting the match to not match any VLAN-tagged packets.  The vlan_pcp=0 was added later as part of a commit that looks like it was driven by the POX switch/flow-table code, which I didn't have anything to do with at the time, and don't immediately know what to make of.  I'm sure it was meant to solve a specific problem, but on the face of it, it seems wrong.  So maybe it wasn't the best possible fix.
> 
> In practice, switches hopefully just ignore it since it can't possibly be true that dl_vlan=65535 and dl_vlan_pcp is actually significant.  The switch you're using apparently does, since it comes back wildcarded.  But if an issue were filed on this, I'd be tempted to change it back to how it was, maybe even ignoring the impact on the POX flow table for now (which has outstanding issues/patches which may be related anyway, e.g. #142).
> 
> (That still won't mean that attempting to match your constructed matches against the ones in the switch is likely to work without extra effort, though.)
> 
> That's exactly how i came up with the question, i was trying to match flow-mod and flow-removed matches, i will try using the cookie from now on.
> 
> 
> 
> Thank you very much for all your help on the matter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.noxrepo.org/pipermail/pox-dev-noxrepo.org/attachments/20150527/e4fccf0d/attachment.html>