Nekto

Спасибо за ответ. Про тюнинг арпа читал, но это не то, о чем я спрашивал. Пока решил собрать клиентские вланы в один бридж, так все нормально работаеи и потом легче обработку делать для шапера. На стороне ону можно на порту разрешить только определенные адреса на порт в качестве защиты. За ссылку на дхцп спасибо, слышал про него, но пока обходился isc с патчем -dd.

Хммм. Проверил с обычным свичом, все работает. Проблема в том, что у меня GPON ZTE C-300 c f660 и проблема именно с онушками. Надо копать конфиги, чтобы разобраться в таком поведении. На стороне линукса все в порядке. Попробую проверить с 2 разных онушек, чтобы понять где конкретно проблема в голове или самой ону. Поставил рядом вторую ону - между ними все нормально пашет. Надо разбираться, как настроить изоляцию портов в пределах одной онушки, думаю проблема в этом. Если кто сталкивался с такой ситуацией - подскажите решение?

Сделал схему похожую на вашу по примеру из интернета ip route add unreachable 192.0.2.0/24 ip addr add 192.0.2.1/32 dev lo vconfig add eth0 101 ip link set eth0.101 up ip route add 192.0.2.100/32 dev eth0.100 src 192.0.2.1 ip route add 192.0.2.101/32 dev eth0.101 src 192.0.2.1 echo 1 > /proc/sys/net/ipv4/conf/eth0.100/proxy_arp echo 1 > /proc/sys/net/ipv4/conf/eth0.101/proxy_arp Поднял 2 vlan 100,101 Трафик наружу ходит без проблем. Между ними пинги проходят изредка. Понимаю, что какая-то тонкость в настройке proxy_arp, но не могу найти решения. Никто не сталкивался с проблемой?

присоединяюсь к вопросу

Ни у кого не завалялась для С300 V1.2.0P1 нужны scxm и gucd файлы для прошивки старой карты Вопрос решил.

Вы невнимательно читали ветку. По такой схеме не работает на 4.4.18 ядре. Если ставлю 3.18.ХХ то работает.

У меня нет ppp интерфейсов, но для каждого vlan пакеты направляются в свой сет, где собраны ip исходящие из этого интерфейса. Правила получаются слеюующие: -A POSTROUTING -o eth0.+ -m set --match-set in_vlan11 src -j ACCEPT -A POSTROUTING -o eth0.+ -m set --match-set in_vlan12 src -j ACCEPT Для каждого интерфейса задается свой сет. через + не получится так сделать.

Пока проц справляется с нагрузкой менять его смысла нет. 7 лет пашет без остановок. Я описывал загрузку, чтобы было наглядное представление о применении данной схемы шэйпера. Кстати, сколько pps тот же I7-6700 без проблем пережевывает?

Наконец привязал новую схему шапера к биллингу. Особо не торопились, поскольку загрузка проца не превышала 50%. В итоге остановился на схеме, предложенной taf_321, с использованием skbinfo, за идею ему отдельное спасибо. В моем случае главной причиной была возможность использовать схему на любой версии ядра. Посчитал, что отказ от tc filter тоже скажится положительно. При использовании Vlan правило iptables приходится прописывать на интерфейс vlan. Зато правила htb работают на родительском интерфейсе eth0, eth1,ethX, что меня полностью устраивает. Боевой рутер на котором все крутится в строю уже ~7 лет. 4х ядерный Xeon X3330 @ 2.66GHz 2Gb ram. сетевуха Intel 82576. Без шапера загрузка cpu в пределах 10-15%. 2 полных таблицы BGP, DNS, DHCP, Squid (заворачивать блочные сайты) ната нет. Включаем неоптимизированный шапер - при 50 kpps загрузка cpu ~50% при 40 kpps загрузка ~40% при 30 kpps ~30%, прямо как под заказ :) Запустил оптимизированный вариант. Всего в ipset 4900 записей . ~2000 вида hash:ip где проставляется skbinfo, остальные hash:ip,port и где-то 500 hash:net,port. Правил htb ~ 2000 (их количество не менялось). Добавилось 13 правил iptables по количеству vlan. Результаты загрузки cpu: 60 kpps загрузка cpu 33% при 40 kpps загрузка cpu ~26% при 30 kpps загрузка cpu ~19% Думаю по результатам все понятно - инструкция в ветке. Да, для каждого ип мы маркируем трафик отдельной маркой, так сложилось исторически - отвязать от биллинга сложно. При работе с субнетами прирост может оказаться выше. ipset рулит! Только что посмотрел статистику 48kpps - 24% - с чем связано не знаю.

Я попробовал на ядре 3Х запустить правило без протокола all - работает с u32 без проблем. (Думаю поэтому и ipset срабатывает) Попробовал создать стандартное правило для хэшей - не работает. Все же в новых ядрах в плане vlan что-то поменяли.

В таком случае я могу через ipset загнать пачку адресов или субнетов в один сет и потом одним правилом iptables направить этот сет в определенный клас/марку. Собственно для определенного вида трафика я так и делаю. В моем случае речь идет об индивидуальной настройке для каждого адреса. Как я понимаю ipset прекрасно работает с адресами на уровне хэшей, а tc пережевывает вывод из правила напрямую. tc не сканирует весь пробегающий трафик, а лишь подбирает выборку ipseta. Если я ошибаюсь - поправьте. В любом случае на следующей неделе будут результаты. Единственные грабли коорые я могу предположить, это когда ipset прогоняет всю цепочку для каждого правила, но интуищия мне подсказывает, что у него выборка идет глобально и он сортирует пакеты по сетам используя свои внутренние метки. Во всяком случае такой сценарий мне кажется правдоподобным.

Напишите пожалуйста пример для трех произвольных ип. Не понимаю, как я получу индивидуальные параметры скоростей для каждого ип, с одним правилом иптэйблов? В классическом использовании хэшей перебор идет по последнему знаку ип адреса, здесь перебор на уровне хэша выполнит ипсет и направит прямо в клас тц

Ура - решение найдено. Заработало! ipset create test hash:ip hashsize 64 ipset add test 192.168.0.5 tc qdisc add dev eth0 root handle 1 htb default 30 r2q 32 tc class add dev eth0 parent 1: classid 1:2 htb rate 100Mbit tc class add dev eth0 parent 1:2 classid 1:11 htb rate 20Mbit ceil 30Mbit burst 50k prio 3 tc qdisc add dev eth0 parent 1:11 handle 11 esfq perturb 10 hash dst tc filter add dev eth0 parent 1:0 protocol all prio 200 handle 11 fw classid 1:11 tc filter add dev eth0 parent 1:0 protocol all prio 100 basic match ipset'(test dst)' classid 1:11 Из ipset пакеты прямиком направляются в нужный класс шэйпера. Никаких промежуточных iptables не надо! Я правильно смотрел в направлении ipset. Теперь собственно о граблях, почему у меня сразу не получилось. Стояла стоковая версия ipset 6.20. Собрал 6.29, когда на skbinfo полезли ошибки - он после 6.22 включен. По случаю я в это время работал на ядре 3.18.42 - все прекрасно запустилось. Перешел на версию 4.4.18 - получил облом. На сегодняшний момент ядро 3.18.42 ipset 6.29 iproute2-4.7.0 - все работает на машине с vlan. У кого не используется vlan проблем скорее всего не возникнет с любым ядром. Осталось переписать скрипты под новый формат.

Не получится. Нужно указать куда попадают данные из субнета - эта строка tc filter add dev eth0 protocol ip parent 1:0 prio 200 u32 ht 800:: match ip dst 192.168.0.0/24 hashkey mask 0x000000ff at 16 link 2: Последняя запись из субнета попадает в свой divisor на свой link, а в нем откусывается только последня циферка по маске. правило с указателем protocol all не работает. tc не видит тэгированный трафик как ip пробую указать вид протокола 802,1q - получаю ту же ошибку: tc filter add dev eth0 protocol 802.1q parent 1:0 prio 200 u32 ht 800:: match ip dst 192.168.0.0/24 hashkey mask 0x000000ff at 16 link 2: RTNETLINK answers: Invalid argument We have an error talking to the kernel Без этого правила работать ничего не будет. Каким образом указать, что ip протокол нужно смотреть в конкретном vlan я не понимаю.