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. Either way, this flow dump shows that the packet is being sent out port 1. The next step is to use "ovs-dpctl show" to find out what port 1 is, and then tcpdump or otherwise watch what is going out port 1. _______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss
