On 07.11.2014 01:07, Rick Jones wrote: >>> 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. I now implemented a script that sends a gratuitous arp every minute from that interface and with it running the bridge now picks up the MAC and the traffic disappeared. Thanks for pointing me in the right direction with those bridge remarks! Regards, Dennis -- 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
