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.
That has always been my understanding of how bridges/switches work.
Until they see a given MAC address as a source MAC, any traffic destined
for that MAC address will be flooded out all ports (well, save for the
one it came-in on of course).
You could, I suppose, ping/arp for the IP associated with the
52:54:00:2d:83:3f and if they hypothesis is correct, once you do that,
you should no longer see the traffic arriving.
rick jones
--
To unsubscribe from this list: send the line "unsubscribe lartc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
