А цель сего? Найти трафик с/на IP который неклассифицирован и пробегает мимо иерархии?. Мне кажется связка IPMARK/iproute2 для классификации трафика исключит такую ситуацию, только успевай классы создавать, ну а чтобы не было утечек трафика делаем дефолтный класс в иерархии с rate/ceil = 1bit. И весь трафик который не классифицировался попадет в него.
нет это как раз и есть вместо пробегания по иерархии, эта команда должна найти в хеше этот айпи, и в хеше сразу хранится вместе с айпи в какой класс его отправить. То есть так находим по хешу айпи с каждым айпи в хеше хранится в какой класс пометить пакеты которые попадают под этот айпи. Если находим айпи сразу класифай делаем на месте.
Ну если это даст выиграш в производительности, то да нужная штука будет. Хотя "tc filter add dev ethX parent 1:0 protocol ip fw" очень шустро раскидывает пакеты по иерархии. При рейте в 400тыс пакетов/сек опрофайл показывает что классификатор потребляет ресурсов на уровне 0.5-0.7%
более подробно опиши как у тебя сейчас работает в целом (iptable и tc правила как проходит трафик), и я укажу место про которое я говорю.
Немного подробностей, чтобы вам было понятнее.
Имеется роутер с кучей гигабитных интерфейсов Intel 82571EB(PCIE,NAPI, 2 TX HANDLER). Со стороны клиентов на него приходит около 50 vlan на bond группу из 4 интерфейсов. В каждом влане от 60 до 180 юзверей. "Клиентские" интерфейсы переименовываются c cli.XXX для оптимизированного группового применения правил iptables, также "Пиринговые" в peer.XXX, а "Интернетные" в up.xxx.
Используются несколько imq псевдоинтерфейсов, для организации шейпов по направлениям. Локальный, пиринговый, интернет.
На примере локального трафика.
Первое:
Заворачиваем локальный трафик(между клиентами) на imq0 интерфейс. Необходимо использовать MARK, так как imq не полная эмуляция и указывать с -i/-o imq0 не получается, тем более маркировка пригодится ниже. Маркируем весь локальный трафик 4, и по этому марку заворачиваем в imq0.
В mangle FORWARD имеем.
6559M 6287G MARK all -- cli+ cli+ 0.0.0.0/0 0.0.0.0/0 MARK xset 0x4/0xffffffff
6559M 6287G IMQ all -- * * 0.0.0.0/0 0.0.0.0/0 mark match 0x4 IMQ: todev 0
Второе
На imq0 построена htb иерархия классов с именами из последних двух октетов в хексе. Пример (192.168.16.133) -> 16.133-> 1085
В mangle POSTROUTING имеем
6555M 6284G IPMARK all -- * * 0.0.0.0/0 0.0.0.0/0 mark match 0x4 IPMARK dst ip and 0xffff or 0x10000
IPMARK перемаркирует весь трафик промаркированный выше 4(локальный), исходя из двух последних октетов dst IP, пример (192.168.16.133) -> 16.133-> 1085
Новый MARK на трафик dst ip 192.168.16.133 будет 1085. В итоге мы имеем что весь трафик на устройстве imq0 промаркирован.
Третье.
Классификатор.
Раскидываем трафик по пользовательским классам на imq0.
Одной командой.
/sbin/tc filter add dev imq0 parent 1:0 protocol ip fw
Весь трафик попадает согласно маркировке в одноименные классы.
Что имеем в итоге, минимум правил в iptables/tc, прекрасную маштабируемость, настройки никак не зависят от количества абонентов. Остается только следить за двумя моментами. Чтоб не появились в сети ip с одинаковыми двумя последними октетами, иначе попадут в один класс, посему приходится следить за заведением новых серых сетей, чтоб они 3 октетом не пересеклись с имеющимися реальными сетями, и за своевременном созданием классов в иерархиях, иначе весь трафик что не нашел для себя класса по марку попадает в дефолтный класс с низкой скоростью 1bit/s(фактически банится).