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). (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
