LINUX.ORG.RU

Ответ на: комментарий от post-factum

На uplink интерфейсе с NAT уже не видно серых адресов клиентов

fet4 ()
Ответ на: комментарий от fet4

Для этого используется IFB (если я правильно понял Вашу задачу). Я здесь уже писал. А imq, по моему опыту, добавляет латентность и вообще дергано управляет полосой.

funky ()
Ответ на: комментарий от fet4

Это я уж не знаю, как Вы классифицируете (и кстати, как заворачиваете) - Вы нас не посвящали. Я просто предложил Вам решение проблемы, на которую Вы указали:

На uplink интерфейсе с NAT уже не видно серых адресов клиентов

funky ()
Ответ на: комментарий от fet4

Почему бы и не классифицировать фильтрами. Есть довольно удобный bpf.

post-factum ★★★★★ ()
Ответ на: комментарий от fet4

А ifb работает до iptables

google://ifb delayed shaping

Если вкратце пропускаешь трафик ДО nat, заворачиваешь его еще раз, маркаешь как тебе надо в iptables, шэйпишь, профит.

Pinkbyte ★★★★★ ()
Ответ на: комментарий от Pinkbyte

Насколько я понял мне нужно будет на каждый Ip отдельный марк присваивать что бы их различить и разнести по классам. Сложновато получается.

fet4 ()
Ответ на: комментарий от fet4

Если у тебя там РАЗНЫЕ классы трафика используются для КАЖДОГО ip - тогда да, придется. Иначе нет, достаточно по одной метке на класс

Pinkbyte ★★★★★ ()
Ответ на: комментарий от fet4

Тогда да, только разными метками, по другому никак. Но ты можешь в принципе вообще обойтись без меток - просто указывая IP - так как он на второй итерации шейпинга будет доступен(где шейпить - до/после NAT - это уже решать тебе).

Метки нужны если как-то IP можно сгруппировать для упрощения шейпинга.

Pinkbyte ★★★★★ ()
Ответ на: комментарий от Pinkbyte

Ты про типа «tc filter add dev eth0 parent ffff: protocol all u32 match u32 0 0 action mirred egress redirect dev ifb0»

Этот iproute2/tc без ящика водки не осилить.

imq в этом отношении не требовал таких извращений. Жаль что его не пропихнули в ядро.

vel ★★★★★ ()
Ответ на: комментарий от vel

Этот iproute2/tc без ящика водки не осилить.

Да, если нужно сделать что-то посложнее шейпинга ТОЛЬКО транзитного трафика на роутере - приходится дичайше страдать и читать килотонны манулов. Sad but true.

IMQ сам пользовал, когда он еще нормально накладывался на выходившие ядра, потом там был в выпуске большой перерыв и я шейпер дома переточил на ifb. Заняло у меня это дохрена времени, если честно

Pinkbyte ★★★★★ ()
Ответ на: комментарий от Pinkbyte

Дома не шейпю (зачем? пров дает свыше 100, никто из домашних не забивает), а на работе все еще шейпю с помощью imq. Без проблем накладывал на свежие ядра. Работает как часы. latency может и добавляет, но видимо мало, потому как я не замечаю. В ручную правила давно не пишу для tc. Давно уже есть скрипт, аналогично htb.init который гененирует мне все что нужно. И шейпинг при это динамический, а не прибитый гвоздями к каждому ip устройства. Так что поэтому приходиться сидеть на iptables. В прочем пока не вижу смысла на новое и переходить. Работает? Работает.

as_lan ★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.