KaYot

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

Штатными средствами(через rp_pppoe) PPP сервер под линуксами разворачивается за 10 минут. Самый сложный вопрос - как вы шейперы организуете, во фре и линуксе оно очень сильно отличается. На accel все проще, шейпер встроен и управляется чрез радиус.

Все имеет минимум 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 dev bond0.2 parent 2:0 protocol ip pref 2 u32 filter add dev bond0.2 parent 2:0 handle 1: protocol ip pref 2 u32 divisor 16 filter add dev bond0.2 parent 2:0 protocol ip pref 2 u32 ht 800:: match ip src 10.10.164.0/22 hashkey mask 0x00000f00 at 12 link 1: filter add dev bond0.2 parent 2:0 handle 5: protocol ip pref 2 u32 divisor 64 filter add dev bond0.2 parent 2:0 protocol ip pref 2 u32 ht 1:1: match ip src 10.10.165.0/24 hashkey mask 0x000000ff at 12 link 2: filter add dev bond0.2 parent 2:0 handle 3: protocol ip pref 2 u32 divisor 256 filter add dev bond0.2 parent 2:0 protocol ip pref 2 u32 ht 1:2: match ip src 10.10.166.0/24 hashkey mask 0x000000ff at 12 link 3: filter add dev bond0.2 parent 2:0 handle 4: protocol ip pref 2 u32 divisor 256 filter add dev bond0.2 parent 2:0 protocol ip pref 2 u32 ht 1:3: match ip src 10.10.167.0/24 hashkey mask 0x000000ff at 12 link 4: filter add dev bond0.2 parent 2:0 handle 6: protocol ip pref 2 u32 divisor 256 class add dev bond0.2 parent 2:0 classid 2:d htb rate 2000Mbit ceil 2000Mbit quantum 65535 qdisc add dev bond0.2 parent 2:d handle d pfifo limit 10000 class add dev bond0.2 parent 2:0 classid 2:1c9 htb rate 1398000bit burst 2796b ceil 2097000bit prio 3 quantum 65535 filter add dev bond0.2 parent 2:0 protocol ip pref 2 u32 ht 3:25 match ip src 10.10.166.37 flowid 2:1c9 qdisc add dev bond0.2 parent 2:1c9 handle 1c9 sfq perturb 10 Это вход qdisc add dev bond1 root handle 1 htb default d class add dev bond1 root htb rate 2000Mbit ceil 2000Mbit quantum 65535 filter add dev bond1 parent 1:0 protocol all pref 2 u32 filter add dev bond1 parent 1:0 handle 1: protocol all pref 2 u32 divisor 16 filter add dev bond1 parent 1:0 protocol all pref 2 u32 ht 800:: match ip dst 10.10.164.0/22 hashkey mask 0x00000f00 at 16 link 1: filter add dev bond1 parent 1:0 handle 5: protocol all pref 2 u32 divisor 64 filter add dev bond1 parent 1:0 protocol all pref 2 u32 ht 1:1: match ip dst 10.10.165.0/24 hashkey mask 0x000000ff at 16 link 2: filter add dev bond1 parent 1:0 handle 3: protocol all pref 2 u32 divisor 256 filter add dev bond1 parent 1:0 protocol all pref 2 u32 ht 1:2: match ip dst 10.10.166.0/24 hashkey mask 0x000000ff at 16 link 3: filter add dev bond1 parent 1:0 handle 4: protocol all pref 2 u32 divisor 256 filter add dev bond1 parent 1:0 protocol all pref 2 u32 ht 1:3: match ip dst 10.10.167.0/24 hashkey mask 0x000000ff at 16 link 4: filter add dev bond1 parent 1:0 handle 6: protocol all pref 2 u32 divisor 256 class add dev bond1 parent 1:0 classid 1:d htb rate 2000Mbit ceil 2000Mbit quantum 65535 qdisc add dev bond1 parent 1:d handle d pfifo limit 10000 class add dev bond1 parent 1:0 classid 1:117 htb rate 2097333bit burst 4194b ceil 3146000bit prio 3 quantum 65535 filter add dev bond1 parent 1:0 protocol all pref 2 u32 ht 3:cc match ip dst 10.10.166.204 flowid 1:117 qdisc add dev bond1 parent 1:117 handle 117 sfq perturb 10

Больше похоже на то, что хеши таки не работают и у вас сервер просто лег по 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.1 flowid 1:1001 А потери понятно почему, никаких чудес. По умолчанию tc не создает ничего, соответственно у конечного класса нет qdisk'a(очереди). Длинна буфера шейпера 0 байт. Добавьте его, мне нравится конечная дисциплина sfq qdisc add dev bond1 parent 1:1001 handle 1001 sfq perturb 10

Можно

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