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 ........ ....
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.
Here is the output of ovs-dpctl show
# ovs-dpctl show
system@ovs-system:
lookups: hit:214833 missed:13556 lost:0
flows: 2
port 0: ovs-system (internal)
port 1: br0 (internal)
port 2: p3p2_1
I see here that p3p2_1, the interface on which the FIP packets are being
trasmitted/received is 2 and not 1 as I had in my add-flow commands. I modified
my previous add-flow commands with in_port and output as 2, but it didn't seem
to work. No errors, but doesn't do anything.
# ovs-ofctl add-flow br0 "table=0, dl_type=0x8914, in_port=2,
actions=output:LOCAL"
# ovs-ofctl add-flow br0 "table=0, dl_type=0x8914, in_port=LOCAL,
actions=output:2"
# ovs-appctl ofproto/trace br0 dl_type=0x8914
Flow:
metadata=0,in_port=ANY,vlan_tci=0x0000,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,dl_type=0x8914
Rule: table=254 cookie=0 priority=0,reg0=0x1
OpenFlow actions=controller(reason=no_match)
No match, flow generates "packet in"s.
Final flow: unchanged
Relevant fields: skb_priority=0,in_port=ANY,dl_type=0x8914,nw_frag=no
Datapath actions: drop
This flow is handled by the userspace slow path because it:
- Sends "packet-in" messages to the OpenFlow controller.
_______________________________________________
discuss mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/discuss
