[Qemu-discuss] Issue bridging tap interfaces

[Supriya Kher]

Hi all,

I am facing a weird problem with a Linux bridge that has tap
interfaces as a part of it. Here are the details:

I have a tap interface that appears as "eth2" in a Linux guest. A
process within this guest writes valid Ethernet frames to this
interface eth2. Now eth2 in guest corresponds to a tap interface
“ictap1” in the Hypervisor. This ictap1 interface in the Hypervisor is
a part of the bridge in the Hypervisor , say “ictrl_br0” .

The issue is that " the packets are sent to eth2 are seen on ictap1 in
the hypervisor with the Ethernet header. However they are NOT seen at
all on ictrl_br0 "

802.1Q Ethernet header :  src mac = 0  , destn mac = broadcast, vlan
tag = 0 ( indicating packet not tied to any vlan )

I do not see any drop counts on ictap1 , meaning the packets was
successfully received by the tap. I do not see it on the bridge,
implying that the kernel received it from the tap, and before
repeating it on the bridge interfaces, it was dropped.  I next tried
to change the log level in syslog messages to monitor any obvious
reasons for the drop. However I do not see any new
messages being logged for this activity.

I further tried cases to determine if it is something to do with the
packets written by my process.
I therefore tried to generate ARP packets ( by pinging a remote IP
using system PING) . This ARP is NOT forwarded to the bridge ictrl_br0
as well.

Tested with various packet types :  ( Packets NOT seen on the bridge
in both cases )

1.       Ping –I eth2  10.10.10.15  ( forcing an ARP generation )

2.       Custom Ctrl packets within an Ethernet frame

I have also experimented with a few kernel level configurations for
bridges ( bridge-nf ) that might be a potential reason for the bridge
to not receive the packets.
However this configuration tweak did not help either.

I am now running out of options of what could be wrong here,
specifically for this bridge ictrl_br0.

Any help/inputs here would be great.

Note: This is a nested virtualization environment, so the guest ->
runs on a Hypervisor -> that runs on a outer VM --> this outer VM is
hosted on an Ubuntu server.

Thanks a lot..

- SM