enots

198.199.79.18 tcp 4786 и udp tftpd 128.199.60.122 только tcp 4786

нет. вроде все что было обещано, уже сделано... даже без "под заказ".

разумеется суммарно. одна строка - один шейпер.

запустил в прод cat /proc/net/ipt_ratelimit/users_to | wc -l 1064 cat /proc/net/stat/ipt_netflow | grep Rate: Rate: 874588972 bits/sec, 135383 packets/sec; Avg 1 min: 912832655 bps, 138416 pps; 5 min: 915385917 bps, 138266 pps изменение нагрузки с ratelimit CIDR и без ratelimit, порядка 2-4% CPU. четко выраженной ступеньки на графике нет.

тройка моментов по поводу текущей реализации: так как сети могут перекрываться, то в limiting попадет первая наиболее специфичная, просмотр идет начиная от /32 до /0. 0.0.0.0/0 сеть тоже допустима. через ',' можно перечислить несколько сетей, как это и было ранее с ip без CIDR. в разных правилах сети не могут повторяться.

новую версию с CIDR поддержкой так никто и не протестил?

echo +10.0.0.0/24 100000000 > /proc/net/ipt_ratelimit/users_to cat /proc/net/ipt_ratelimit/users_to | grep -w 10.0.0.0 10.0.0.0/24 cir 100000000 cbs 18750000 ebs 37500000; tc 0 te 0 last never; conf 0/0 0 bps, rej 0/0 очень интересует изменение нагрузки на cpu до и после, просьба пронаблюдать. краши тоже )

при sysctl -w net.netflow.aggregation="1024-65535=0" трафик с портами в диапазоне 1024-65525 где srcip/dstip/proto одинаковые, будут преставлены как одна запись, порт будет 0. при sysctl -w net.netflow.aggregation=172.10.0.0/16=32,0.0.0.0/0=24 сеть 172.10.0.0/16 будет как есть, а вот все остальное свернется до /24. т.е. 8.8.8.8 и 8.8.8.7 трафик станет одной строчкой как 8.8.8.0/24. правила через зяпятую. p.s. при текущих "запросов из конторы" все это не имеет смысла, а раньше экономило hdd space и при этом корректно выставляло счета пользователям.

Очень давно была попытка договориться с майнтейнерами netfilter пропихнуть ipt_netflow, обсуждение растянулось на пару недель. Тот кто активно занимался майнтейнерством в этот момент параллельно делал ulog2, другой агрументировал что все что сделано не через conntrack не верно. Слушать о том что сделано без conntrack именно для скорости они не захотели. Делать тесты и что-то доказывать не захотели мы. Кому все это может потребоваться, соберут модуль и самостоятельно. ) Я где-то уже описывал всю эту эпопею... нашел https://habrahabr.ru/sandbox/21426/ Если кто-то захочет проявить красноречие и вести переговоры, то может себя проявить. Это будет уже 3я попытка. ) А что косается ratelimit, так он по сути еще не доделан и тащить его в таком вот виде как он есть сейчас, смысла большого нет. p.s. К примеру я изначально хотел маски и абстрактные идентификаторы для биллинга (я не заказчик). Но так как это усложняет код, то на первом этапе было сделано упрощение, а второго этапа пока не наступило.

думаю стоит формализовать требуемые доработки и обсуждать по емайлу из файла README.

Что то я не припомню о коммерческой составляющей этого проэкта, или автор обещял плюшки за доп плату где то тут? Я инсайдер и в курсе всех скрытых подробностей появления ratelimit/netflow модулей. Этот модуль вообще появился только потому, что автору были предоплачены часы работы (20 часов afair), причем даже без гарантий что что-то получится на выходе. Изначально нужно было выяснить как это реализовать под большую нагрузку и при этом сделать удобным для isp. То что код публичный, так это позиция автора. На данный момент все оплаченное время закончилось. А своим предыдущим постом, я лишь озвучил реальную возможность ускорить появление новых фич.

На сколько я помню, рабочие часы на эту часть девелопмента не были оплачены, а "само по себе" все ползет довольно медленно. Желающие ускорить, могут связаться с автором и внести посильный вклад. p.s. ipv6 был в далекой перспективе. jfi

убрав npe-400 и вставив npe-1g ты получишь к fa0/0 fa0/1 (которые на c7200-io) еще и gi0/1, gi0/2, gi0/3. при этом нагрузку стоит перенести с fa0/* на gi0/* интерфейсы. PA интерфейсы 1/0,1/1 останутся как и были. p.s. я обычно вытаскивал и более не использовал c7200-io, так как смысла в ней нет.

Я предлагал чуть выше маркировать пакеты, обработанные/не обработанные полисером... Как по мне, маркировка не очень удобна. Проше все сделать через внешнее правило (которое сейчас в большенстве случаев "-j DROP"), т.е. оторвать алгоритм ratelimit от внешнего и использовать внутренний не явный drop. Такое поведение для полисера будет легко понять. Внешнее-же правило сделать зависимым от "IP вошел в сет или нет" и можно будет применять -j DROP или -j REROUTE, etc. Правда это не позволит делать странные ratelimit типа когда overlimit пакеты не дропаем, а отправляем куда-то еще. Но честно говоря это уже экзотика и я слабо представляю кому она может потребоваться )

что за подмена nexthop?