KaYot

Все имеет минимум 2 стороны. Требования регулятора - глупость, но ваше не желание их выполнять выдумывая оправдания - еще большая глупость. Вы подали недостоверные данные при получении лицензии, затянули со сроками освоения(и то, и то нарушение лицензионных условий) и удивляетесь что лицензия тю-тю.

Дык я о том и говорю, стоят разные версии федоры/центоса/рхела, никаких неудобств их наличие не вызывает.

Не обязательно. В пределах ветки(fedora/centos/rhel к примеру) разница между дистрибутивами - в версиях стоящего и доступного в репах софта. Вполне можно держать все унифицированное на уровне софта/конфигов.

А как вы догадались?

Бред, тогд обьясни мне почему у меня: Cisco WS-C3550-12T (PowerPC) А вы между 3500xl и 3550 чувствуете разницу? Разные поколения, у 3500 железное ограничение в максимальный 1005 vid.

Ничто не мешает выдавать любое число IP в один клиенсткий влан, это скорее вопрос к биллингу.

Дык ТС же сервер ставил, вот сервер и лег от 3 одновременных кликов по ссылке

Он не в курсе))

ssh это такой удаленный рабочий стол? как тимвью?

Он при shared=0 вообще не должен работать. Значит баг.

Так а где ж ему ip брать? Вообще баг вероятно, но он смысла и не имеет в любом случае. Для vlan-per-user нужно делать ifcfg=0, адреса на вланах не нужны. Роут прописывается на неверный ip, если ip не будет, будет правильный роут и все заработает)

ifcfg=1 говорит что нужно прописывать IP на интерфейсы.

Никаких вариантов, конкурируйте честно. Любой выдуманный договор не имеет силы, разве что взятки всем раздадите что б палки в колеса ставили конкуренту.

Или burst что-то ломал, или отсутствие ceil в ограничениях. Ну и хеши заработали, нагрузка упала.

хеши не работают Повторюсь, если в первой строчке стоит маска ff00 - значит для хеша ты берешь ЦЕЛИКОМ второй октет адреса.А дальше ты его используешь, но почему-то сравниваешь не с реальным значением(128,129,...), а с 0,1,2. Или поставь 7f в маске, что б брать только младшие биты(фактически получится смещение от 128), или задавай полный адрес в хешах дальше. Вот мой рабочий кусок шейпера, с корнем, хешами, дефолтом и клиентом. Это для исхода qdisc add dev bond0.2 root handle 2 htb default d. class add dev bond0.2 root htb rate 2000Mbit ceil 2000Mbit quantum 65535 filter add de

Больше похоже на то, что хеши таки не работают и у вас сервер просто лег по 100% загрузке.

Т.е. видно что дропается где-то в правилах, а не в дефолтном(без ограничений). Ищите где, статистика ж там вплоть до конечных классов есть.

Не, нету там никаких таблиц. Порядок создания фильтров в данном случае не важен, грабли где-то в другом месте.

Да, очередь имеет смысл только для конечного класса. Добавлять ее нужно везде. Для отладки смотри статистику tc, вроде tc -s class или tc -s qdisc, и смотри по счетчикам куда идет трафик и где дропается.

А с этим я когда-то почти неделю мучался, пока дошло Та же ситуация, как я писал выше - все что не попадает в правила шейпера сливается в дефолтный класс. А у него очереди тоже нет. И пока нагрузка на железо небольшая, и пакеты успевают пролетать условно wire-speed - проблем нет. Но как только идет рост pps и пакеты не успевают покинуть трубу мгновенно - они уничтожаются tc вместо буферизирования. Создайте явно дефлтный класс 1:900, добавьте ему какое-то большое ограничение скорости и очередь. Можно попроще, у меня стоит pfifo limit 10000(пакетов).

Если вы используете То по идее дальнейший фильтр нужно делать не так tc filter add dev bond0.8 parent 1:0 protocol ip u32 ht 12:0: match ip dst 172.24.128.0/24 hashkey mask 0x000000ff at 16 link 13: А так tc filter add dev bond0.8 parent 1:0 protocol ip u32 ht 12:80: match ip dst 172.24.128.0/24 hashkey mask 0x000000ff at 16 link 13: И в клиентском фильтре ошибки: tc filter add dev bond0.8 protocol ip parent 1:0 u32 ht 13:0: match ip dst 172.24.128.1 flowid 1:1001 Нужно таки что б хеш совпадал с ip, tc filter add dev bond0.8 protocol ip parent 1:0 u32 ht 13:1: match ip dst 172.24.128.

Можно

Конечно. Все что не попало в фильтры сваливается в дефолтный класс 900(у вас), его тоже не мешает описать.

Даже не совсем так. Вы везде используете ff в хешах, значит используется весь октет, то я по привычке для нормальных схем прикинул. Значит и во втором уровне должен быть весь октет адреса, 12:80: (0x80=128). Правильнее было бы в верхнем уровне поставить маску 7f, ведь для вашей подсети /17 старший бит не нужен и он не меняется. Тогда дальше можно считать смещение от 0, а не от 128.

А он и не должен работать, неверно фильтры составлены. tc filter add dev bond0.8 parent 1:0 protocol ip u32 ht 800:: match ip dst 172.24.128.0/17 hashkey mask 0x0000ff00 at 16 link 12: tc filter add dev bond0.8 parent 1:0 protocol ip u32 ht 12:0: match ip dst 172.24.128.0/24 hashkey mask 0xff at 16 link 13: tc filter add dev bond0.8 protocol ip parent 1:0 u32 ht 13:2e: match ip dst 172.24.128.46 flowid 1:104 Смысл хеширования в быстром поиске, все эти циферки в ht значимы. Во втором уровне (12:0) 0 означает смещение от базового хешированного значения второго октета, 128-128=0.