On May 26, 2015, at 5:10 PM, Murphy McCauley <murphy.mccau...@gmail.com> wrote:
> On May 26, 2015, at 8:14 AM, Adam Pavlidis <adampavli...@gmail.com> wrote: > >> Hello all, >> >> I have some questions about the flow rules installed by the l2_learning >> module. > > Are you using l2_learning and only l2_learning? > >> Let's say the following command is executed in mininet "h1 ping -c1 h2": >> >> Initially ARP caches are empty so, h1 sends a broadcast arp. >> The packet is flooded, and no flow rules are installed. A flow rule is >> installed for the reply. >> Then 2 more rules are installed for ICMP request and reply. >> >> However, 2 more rules installed for ARP messages, slightly after the ping >> has finished (2-3 seconds). >> >> Without clearing the ARP cache if i wait for the flow rules to expire and >> ping again, they will be reinstalled for ICMP messages and again for ARP >> slightly later (i did the above twice, 1st time 3 rules for ARP were >> installed, 2nd time 2). >> >> Shouldn't the installation of rules, be triggered by packet-In events of ARP >> messages? >> Using tcpdump, i find that no ARP messages are exchanged, so why are these >> flow rules sent to the switch? > > 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? > >> Also in l2_learning module, out of curiosity i printed the msg.match object >> passed to the switch. >> I noticed that in all ARP flows, the object passed to the OpenFlow Switch >> has dl_vlan_pcp field with value 0. >> >> I created an extra module that handles flow removed events. When the exact >> same flow (again only ARP) expires the msg.match.dl_vlan_pcp field is None >> (wildcard). >> >> >> DEBUG:forwarding.l2_learning:installing flow for 00:00:00:00:00:02.2 -> >> 00:00:00:00:00:01.1 >> DEBUG:forwarding.l2_learning:ofp_match >> wildcards: nw_tos|tp_dst|tp_src (1000000000000011000000 = 2000c0) >> in_port: 2 >> dl_src: 00:00:00:00:00:02 >> dl_dst: 00:00:00:00:00:01 >> dl_vlan: 65535 >> dl_vlan_pcp: 0 >> dl_type: 0x806 >> nw_proto: 1 >> nw_src: 10.0.0.2 >> nw_dst: 10.0.0.1 >> >> DEBUG:Flow Removed:Flow Removed from switch: [00-00-00-00-00-01 3] >> DEBUG:Flow Removed:ofp_match >> wildcards: nw_tos|tp_dst|dl_vlan_pcp|tp_src (1100000000000011000000 = >> 3000c0) >> in_port: 2 >> dl_src: 00:00:00:00:00:02 >> dl_dst: 00:00:00:00:00:01 >> dl_vlan: 65535 >> dl_type: 0x806 >> nw_proto: 1 >> nw_src: 10.0.0.2 >> nw_dst: 10.0.0.1 >> >> >> Is this normal? Shouldn't the flow rules have identical fields? > > 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). I opened up issue #150 on this subject. > (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.) > >> Thank you very much in advance > > -- Murphy
