[ovs-dev] [PATCH 2/2] ofproto: Avoid buffer copy in OFPT_PACKET_IN path.

Jean Tourrilhes jt at hpl.hp.com
Tue Apr 27 18:59:46 UTC 2010


	Merging two e-mail thread for expediency...

On Tue, Apr 27, 2010 at 11:14:45AM -0700, Martin Casado wrote:
>> 	Stanford is starting to test my 1.0 firmware based on OVS. We
>> have already identified an issue between NoX and my
>> firmware. I suspect nobody bothered to check NoX against Open vSwitch,
>> because I believe the bug would also apply to OVS.
> Hi Jean,
> We routinely run OVS against NoX.  We would be interested in knowing  
> what the problem is once you've rooted out the culprit.
> .martin

	I've reproduced the problem this morning with a one month old
master of Open vSwitch on a PC with a yesterday master of NoX, using
the routing module. The basic ping just hangs. Maybe I should get
a newer version of Open vSwitch.

On Tue, Apr 27, 2010 at 11:10:19AM -0700, Paul Weissmann wrote:
> We quickly looked into it yesterday but wanted to debug this again tomorrow.
> The guy working on the NOX 1.0 implementation said that nw_proto handling
> in NOX should be fine though (the ARP opcodes).

	Well, then tell me where I'm wrong.

	This is the ofctl dump of the Open vSwitch after I tried to
>./ovs-ofctl dump-flows tcp:
stats_reply (xid=0x352901a1): flags=none type=1(flow)
  cookie=14534643445914646623, duration_sec=0s, duration_nsec=835000000ns, table_id=0, priority=65535, n_packets=0, n_bytes=0, idle_timeout=5,arp,in_port=2,dl_vlan=0xffff,dl_vlan_pcp=0,dl_src=00:60:b0:ce:2d:d9,dl_dst=08:00:09:fe:ed:bd,nw_src=,nw_dst=,opcode=1,icmp_type=0,icmp_code=0,actions=output:1
  cookie=14132176974031086214, duration_sec=3s, duration_nsec=845000000ns, table_id=0, priority=65535, n_packets=3, n_bytes=294, idle_timeout=5,icmp,in_port=2,dl_vlan=0xffff,dl_vlan_pcp=0,dl_src=00:60:b0:ce:2d:d9,dl_dst=08:00:09:fe:ed:bd,nw_src=,nw_dst=,icmp_type=8,icmp_code=0,actions=output:1
  cookie=17160831227759726843, duration_sec=3s, duration_nsec=843000000ns, table_id=0, priority=65535, n_packets=4, n_bytes=240, idle_timeout=60,arp,in_port=1,dl_vlan=0xffff,dl_vlan_pcp=0,dl_src=08:00:09:fe:ed:bd,dl_dst=ff:ff:ff:ff:ff:ff,nw_src=,nw_dst=,opcode=1,icmp_type=0,icmp_code=0,actions=FLOOD

	The thing to look is the "opcode" for the ARP reply. It is
'1', and by my quick reading of the ARP protocol, it should be
'2'. I get similar result on the ProCurve.


	I've attached the pcap trace of the ping. If you run it
through the openflow wireshark plugin, you can see that the ARP reply
in the packet_in comes with an opcode of '2', and the flow_mod in the
match has an opcode of '1'.

	Note that the default behaviour of a OFPP_TABLE miss may hide
this bug.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: nox-arp-opcode-extract.pcap
Type: application/cap
Size: 1322 bytes
Desc: not available
URL: <http://mail.openvswitch.org/pipermail/ovs-dev/attachments/20100427/f10cacc0/attachment-0003.bin>

More information about the dev mailing list