ThreeDHead
Это должно значить, что пакеты короче 384 байт свитчуются методом store-and-forward, именно для того, чтобы были данные в буфере из заголовков для работы acl. Т.е. принимаются первые 384 байта, матчатся acl, принимается решение куда и как слать и начинается передача с одновременным приемом хвоста пакета.
Не помните какого плана или где почитать? не припомню такого в доке, по идее пакет должен начать форвардиться когда есть однозначное решение куда его слать, в том числе и по acl/pbr.
Попробуйте переименовать интерфейсы, например так: eth1->ieth1, eth2->ieth2, eth3->ieth3 и отфильтровать, например так
ebtables -A FORWARD -i ieth+ -o ieth+ -j DROP
Красивее было бы через devgroup, но не уверен, что ebtables это умеет.
э.... нет.
http://www.pocketnix.org/posts/Linux%20Networking:%20Bonded%20Interfaces%20and%20Vlans
Было бы странно, если бы в разных дистрах было бы всё одинаково.
Не совсем. В более ранних версиях, точно не скажу с каких, он отключался автоматически если начинал идти "плохой" трафик. см. крутилку
/proc/sys/net/ipv4/rt_cache_rebuild_count
Лучше стало только в части cache thrashing неконтролируемым внешним воздействием - его больше нет. В остальном, очевидно, что существует некий размер таблицы маршрутизации, при котором новая схема начнет проигрывать.
https://home.regit.org/2013/03/david-miller-routing-cache-is-dead-now-what/
http://www.spinics.net/lists/netdev/msg205545.html
