On May 27, 2015, at 1:39 PM, Adam Pavlidis <adampavli...@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
