On 03/18/15 16:52, Ben Pfaff wrote:
On Wed, Mar 18, 2015 at 12:44:08PM +0200, Chris Picton wrote:
On 03/18/15 08:47, Chris Picton wrote:
The relevant flow is:
recirc_id(0),skb_priority(0),in_port(2),eth(src=00:15:17:91:05:4c,dst=52:54:00:14:54:c6),eth_type(0x8100),vlan(vid=3,pcp=0),encap(eth_type(0x0806)),
packets:2, bytes:120, used:0.014s, actions:pop_vlan,7
I can't find any definitive documentation for an action element consisting
purely of a number - in this case "7".
I have just re-read the man page, and found the following:
"The target may be a decimal port number designating the physical
port on which to output the packet."
so the packet should, according to the above, be forwarded to port 7, which
is vnet0.
However, the packet is not arriving on vnet0. Any ideas where I can look to
find out why not?
I'd start by checking the kernel log (with "dmesg").
Hi Ben
I had already done system level debugging to try find out where issues
may lie. There are no kernel logs indicating dropped packets or
transmit failures.
A diff between the contents of /sys/class/net/vnet0 (which is the port
that gets no traffic) and /sys/class/net/veth-carbon1-3/ (which is the
port that gets traffic) shows very few differences at the kernel level
(rx/tx counts/address/etc differ, but type/features/carrier/flags/etc
are the same)
What I know so far is that while openvswitch should be forwarding
packets onto vnet0 (which is what the flow indicates), vnet0 does not
receive those packets (as indicated with tcpdump). Also the tx_packets
counter for vnet0 does not increment (as it should when packets get sent
to the interface and transmitted on)
Is this a kernel/openvswitch bug? I can probably get the interface
working by migrating the VM to a different host and migrating it back,
but I would rather leave it in a non working state to try and pinpoint
the issue.
Regards
Chris
_______________________________________________
discuss mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/discuss
