Re: Traffic accounted in interface that has no ip and is not in promisc mode

[Dennis Jacobfeuerborn <dennisml@conversis.de>]

On 07.11.2014 00:11, Rick Jones wrote:
> On 11/06/2014 03:00 PM, Dennis Jacobfeuerborn wrote:
>> The only broadcast traffic I see is a couple of arp packets per seconds
>> and there is no multicast traffic.
>>
>> Since this is a virtual machine that is plugged into a bridge on the
>> host side I'm wondering if that might have something to do with it but
>> according to my understanding even if packets were forwarded from the
>> host side that are not targeted at the vm then the vm would drop these
>> packets and not account them under received packets/bytes for that
>> interface.
> 
> Perhaps the bridge has yet to learn the MACs involved and so is
> flooding.  Whether then the "NIC" driver would/should count/not count
> such traffic as having been received is probably a matter of
> interpretation.  If you take the point of view that any packet which
> came into the host should "count" then the current behaviour would seem
> to make sense.

This is one of the packets that I can see on the interface and that is
responsible for that traffic:
00:20:01.957553 00:25:90:0d:9e:43 > 52:54:00:2d:83:3f, ethertype IPv4
(0x0800), length 66: <src ip>.41638 > <dst ip>.80: Flags [.], ack 563,
win 123, options [nop,nop,TS val 36272290 ecr 116198943], length 0

Looking at the MAC table of the bridge on the host I can see an entry
for 00:25:90:0d:9e:43 as non-local but no entry for 52:54:00:2d:83:3f.
Am I correct in believing that the bridge only learns source MACs but
ignores the destination MAC? If so then my suspicion is that I'm dealing
with an asymetric routing situation where the bridge only sees the
incoming traffic but since the response to this packet actually comes
from a different machine it never gets to learn the 52:54:00:2d:83:3f
address and thus will keep flooding all packets with that destination
MAC indefinitely.

> It is also interesting that this non-configured interface has
> transmitted a large (though smaller than RX count) number of packets.  I
> would have expected your (first) tcpdump to have shows the ether host
> transmitting (very) roughly one packet for every 100 received.

The interface was in operation previously which is probably the reason
for that number. The important information that I should probably have
mentioned more explicitly is that the rx counters increase rapidly while
the tx counters don't move at all.

Regards,
  Dennis