[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-discuss] Issue bridging tap interfaces

From: Mike Lovell
Subject: Re: [Qemu-discuss] Issue bridging tap interfaces
Date: Mon, 05 Nov 2012 12:10:54 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2

On 09/02/2012 09:21 PM, Supriya Kher wrote:
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  ( 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

sorry for the really late response to this. just noticed it as i was cleaning up old emails. did you find a solution to your problem? if not, have you made sure the bridge interface is 'up'? `ifconfig <bridge device>` should say UP at the beginning of the third line. also, is the tap device on the host connected to the bridge? `brctl show <bridge device>` should list the devices connected to the bridge.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]