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