[ovs-discuss] OVS not forwarding packets to port

[Ben Pfaff]

On Wed, Mar 18, 2015 at 05:14:30PM +0200, Chris Picton wrote:
> 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.

I don't know.  It's unlikely to be a bug in the Open vSwitch kernel
module, though.