On Tue, Oct 08, 2013 at 01:38:27PM -0700, Nithin Nayak Sujir wrote: > On 10/08/2013 01:06 PM, Ben Pfaff wrote: > >On Tue, Oct 08, 2013 at 10:44:34AM -0700, Nithin Nayak Sujir wrote: > >> > >>On 10/07/2013 06:39 PM, Ben Pfaff wrote: > >> > >>>>Final flow: unchanged > >>>>Relevant fields: skb_priority=0,in_port=ANY,dl_type=0x8914,nw_frag=no > >>>>Datapath actions: 1 > >>> > >>>This looks correct. The next step is to use "ovs-dpctl dump-flows" to > >>>see what's happening to the actual packets when the kernel handles them. > >>> > >> > >> > >>Thanks for the pointer, Ben. > >> > >>Here is the output of dump-flows > >># ovs-dpctl dump-flows > >>skb_priority(0),in_port(2),eth_type(0x8100),encap(eth_type(0x8914)), > >>packets:38, bytes:2776, used:0.794s, actions:1 > >[...] > >> > >> > >>It's showing the eth_type as 0x8100 and encap(eth_type(0x8914)). Is > >>this a bug in parsing the packet? Here is the packet detail from > >>wireshark. There is no vlan 0x8100 header as you can see. > > > >I don't understand how there could be a bug of that magnitude. > >Wireshark calls this packet a "FIP VLAN Response". Knowing nothing > >about FIP, a packet with that name sounds to me quite likely to be > >inside a VLAN. > > > > The VLAN here refers to type of the FIP protocol packet and not > 802.1q. There is definitely no 802.1q header in the packet. Here is > the packet dump for your reference. The eth_type (offset 0xc) is > 0x8914 and not 0x8100. > > 0000 00 10 18 a7 1e c3 00 0d ec ca 04 80 89 14 10 00 ........ ........ > 0010 00 04 00 02 00 03 00 00 02 02 00 0d ec ca 04 80 ........ ........ > 0020 0e 01 07 d9 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ > 0030 00 00 00 00 00 00 00 00 00 00 00 00 ........ ....
Probably the header is being hidden by VLAN acceleration in the kernel. I'd start adding printk()s to see what's going on. _______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss
