[pox-dev] Fwd: l2_learning flow installation

[Adam Pavlidis]

> 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?


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/fabe5687/attachment.html>