Hi all, I am running 2.6.26.5, I have a transparent bridge (two ports) running ebtables. The issue I am running into is the bridge mac address table growing to a massive size because of an ARP cache storm (for testing purposes). When I send the arp cache storm at the bridge (10,000 pps), interestingly I do not get any packets queue'd to ebtables for ARP, or any type of filtering. The packet/byte count on my rule is 0 (ebtables -A FORWARD -p ARP -j ACCEPT). They appear to be dropped somewhere in kernel? If I set the ageing timer on the bridge to 1 second I am then able to see packets hit ebtables. In my mind I should at least see a few thousand packets hit ebtables before the bridge is inundated with mac address entries? Any thoughts? I also noticed that this table can get massively large, i.e. over 100,000 entries. # brctl showmacs transBR | wc -l 108975 I cannot imagine that Linux bridging would be susceptible to an Arp cache storm attack...I also thought about modifying the #define BR_HASH_BITS 8 in br_private.h to a smaller value for the hash table, but that doesn't seem like a fix but more of a hack. The modification to the age-ing also seems like a poor solution as I do need to have a working bridge. Any help, suggestions, thoughts? Thanks! Erik -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
