Yes, you're missing something. While you install the same flows, l2_pairs also has a packet-in handler which takes care of the situation when the destination is unknown by sending it out all ports.
An example of one address that's never learned by l2_pairs (and the key one in your situation) is the Ethernet broadcast address. It's never learned because it's never a source address. Thus, a rule is never added for it. BUT, when it occurs, it gets sent to the switch and the packet-in handler then does the packet_out to OFPP_ALL. The Ethernet broadcast address is vital because it's what ARP uses. In your case, when you try to ping from h1 to h2, h1 knows the IP address but doesn't know the Ethernet address and needs to ARP for it. It sends an Ethernet broadcast packet with the ARP request, but there's no rule for it on the switch. The switch sends it to the controller, but you don't have a packet-in handler, or the one you have doesn't do anything about the packet. h2 never gets the ARP request, and h1 certainly never gets a reply. Ultimately, h1 gives up and decides h2 isn't reachable. You have a bunch of options for what to do about this, depending on your exact needs. A simple one might be to add a flow that matches ARP's ethertype and FF:FF:FF:FF:FF:FF as the destination, and outputs to OFPP_FLOOD. You could also probably just run the arp_responder component along with your own component. Or you could implement your own ARP logic in a packet-in handler. Etc. Hope that helps. -- Murphy On May 28, 2013, at 11:33 PM, Amauri Albuquerque wrote: > Hello, > > My name is Amauri and I am a Master degree student at TU-Berlin. I'm > developing an interface between a system (stratosphere.eu) and POX in order > to allow the system set flow on the fly in a fattree topology. I decided to > use POX to test the concepts, so I have made all tutorial on mininet and > implemented some basic controllers using POX. After that I created a > component in POX which accepts commands from the client to set flows. The > following is happening. When I set the flow using the client (using my > component), the flow is installed fine (according to the command dpctl ), but > the switch does not work. When I use the l2_pairs component, the same flow is > set and everything works fine. Am I missing something? Here is the code and > the logs for the tests. I appreciate any help. > > Best regards > > Amauri > > Code > > def setFlow(self, IP,outport,switch,macsrc,macdst): > #find the connection for switch > for conn in core.openflow.connections: > id=dpid_to_str(conn.dpid) > if id in switch: > msg=of.ofp_flow_mod() > #msg.priority=30000 > #msg.match.dl_type=0x8100 > #msg.match.nw_dst=IPAddr(IP) > mcrc=EthAddr(macsrc) > mcdst=EthAddr(macdst) > msg.match.dl_src=mcrc > msg.match.dl_dst=mcdst > portout=int(outport) > msg.actions.append(of.ofp_action_output(port=portout)) > conn.send(msg) > > > Tests > > ####### > #using manual flow setting - my code > ####### > > mininet@mininet-vm:~$ dpctl dump-flows tcp:127.0.0.1:6634 > stats_reply (xid=0x49a204a7): flags=none type=1(flow) > mininet@mininet-vm:~$ dpctl dump-flows tcp:127.0.0.1:6634 > stats_reply (xid=0x2c2ca5ce): flags=none type=1(flow) > cookie=0, duration_sec=15s, duration_nsec=786000000s, table_id=0, > priority=32768, n_packets=0, n_bytes=0, > idle_timeout=0,hard_timeout=0,dl_src=00:00:00:00:00:01,dl_dst=00:00:00:00:00:02,actions=output:2 > cookie=0, duration_sec=3s, duration_nsec=248000000s, table_id=0, > priority=32768, n_packets=0, n_bytes=0, > idle_timeout=0,hard_timeout=0,dl_src=00:00:00:00:00:02,dl_dst=00:00:00:00:00:01,actions=output:1 > mininet@mininet-vm:~$ > > #Testing ping > > mininet> h1 ping h2 > PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data. > From 10.0.0.1 icmp_seq=1 Destination Host Unreachable > From 10.0.0.1 icmp_seq=2 Destination Host Unreachable > From 10.0.0.1 icmp_seq=3 Destination Host Unreachable > ^C > --- 10.0.0.2 ping statistics --- > 6 packets transmitted, 0 received, +3 errors, 100% packet loss, time 4999ms > pipe 3 > > > > ####### > #using l2_pairs code > ####### > > mininet@mininet-vm:~$ dpctl dump-flows tcp:127.0.0.1:6634 > stats_reply (xid=0xc38bf354): flags=none type=1(flow) > cookie=0, duration_sec=7s, duration_nsec=415000000s, table_id=0, > priority=32768, n_packets=5, n_bytes=434, > idle_timeout=0,hard_timeout=0,dl_src=00:00:00:00:00:01,dl_dst=00:00:00:00:00:02,actions=output:2 > cookie=0, duration_sec=7s, duration_nsec=377000000s, table_id=0, > priority=32768, n_packets=6, n_bytes=476, > idle_timeout=0,hard_timeout=0,dl_src=00:00:00:00:00:02,dl_dst=00:00:00:00:00:01,actions=output:1 > mininet@mininet-vm:~$ > > Testing ping > > mininet> h1 ping h2 > PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data. > 64 bytes from 10.0.0.2: icmp_req=1 ttl=64 time=1027 ms > 64 bytes from 10.0.0.2: icmp_req=2 ttl=64 time=17.5 ms > 64 bytes from 10.0.0.2: icmp_req=3 ttl=64 time=0.084 ms > 64 bytes from 10.0.0.2: icmp_req=4 ttl=64 time=0.080 ms > ^C > --- 10.0.0.2 ping statistics --- > 4 packets transmitted, 4 received, 0% packet loss, time 3010ms
