Dark_Angel

Отлично, а теперь засуньте в 1:20 торрент. Не меняйте ничего, просто начните с того ИП качать торрнетом.

Еще раз говорю: попробуйте для начала на контролируемых передачах данных, аля просто закачки и с простой конфигурацией, аля 2 класса. Потом начинайте усложнять конфигурацию. В данной ситуации всё закономерно: торрент перетянул одеяло, и tcp закачка разогнаться не может, потому что окно мелкое, то есть свои 100% цейла оно забрать не может. Зато торрент свои 75% как занефиг. Потестить на простой конфигурации надо, чтобы понять вообще, идет ли шейпинг, приоретизация нормально, или нет, на ваших полосах. Квантумы помельче поставьте, бурсты уберите для низкоприоритетного класса.

2cac2s: Ну так как успехи-то? Вроде бы все вопросы разобраны - должно работать, не? На сколько я понимаю реплику в LARTC про фильтры, речь про рут, идет в том случае, когда классифицировать пакет надо в другой лиф, нежели вешается фильтр. Мол, тогда работать не будет. Потому что я когда последний раз его читал, а это было лет 5 назад, то там такого не было и фильтры спокойно вешались на лифы, если фильтр классифицирует четко только в этот класс. Я и сейчас их туда вешаю и всё работает как надо, правда не с последними ядрами, но всеравно. Разве что-то изменилось, может кто-то объяснить?

Ну я Вам вообще-то тоже самое посоветовал намеками: "Попробуйте еще создавать классы по очереди, может после какого-то дочернего класса всё плывет". Но тут может быть, что это не баг, т.к. приоритет определяется лифами, и играет роль только для них - токены же они получают от родителя. Соответственно после класификации трафика, родитель либо даст, либо не даст токен для пакета, в зависимости от прио. Вы сказали, что после правок у вас всё изменилось, но всёравно не так как надо. А как стало?

Явно упускается какая-то мелочь. Попробуйте поменять номер класса. 1:90 же вон нормально создается, а он по конфигурации такой же. Попробуйте еще создавать классы по очереди, может после какого-то дочернего класса всё плывет. И запаситесь спиртным. Там не то что с поллитрой не разобраться, там миниум дня 3 пить надо.

Если явных ошибок команда не выводит ни сюда, ни в dmesg, то надо гуглить. Приоритет должен быть. Попробуйте как вариант вручить квантум для 1:2 тоже.

2cac2s: У вас какая-то мутная схема с определением трафика в другой класс после 512КB. Уберите его пока, чтобы было легче понять как классифицируется трафик. С prio надо однозначно разобраться, т.к. он однозначно влияет на распределение токенов. На практике, если есть 2 закачки, они относятся к разным классам, классы организованы как у вас ( то есть есть высокий приоритет и низкий, rate, ceil правильно ), то всё работает как надо. По крайней мере работало когда я проверял. Даже с перекритием ceil на 100%. 2photon: Если пользователи научаться регулировать скорость сами, то хуже от введеной схемы не будет. Звонят в ТП же те, кто как раз скорость регулировать не умеет, потому что "интернет не работает", так что ТС всё правильно хочет, другой вопрос, что против торрента нет приема - он самый агресивный поток. Как вариант, можно давать клиенту полосу шире, чем пакет. Скажем у него 2Мбита, вы даете 2+1. Скажем 2 отдаете на торрент, а 2 отдаете на веб, при этом 1 Мбит будет гуляющим то в один, то в другой класс. Одновременно занять 3 Мбита пользователь не сможет, потому что торрент. Но для того чтобы так поступить надо всёравно разобраться с проблемой выше.

Бурсты автоматом - ок. Крутить их надо для спецеффектов пользователям. На сколько я понимаю, сейчас проблема не в них, поэтому лучше оставить как есть. Судя по тому , что я вижу 1:90 назанимал токенов у родителя, что нормально, а класс 1:40, который, как я понимаю, должен менеджить закачки с http ничего и не пытается сделать. Вы размер окна посмотрите для закачек. Если вы начали качать после того, как торрент выжрал свой класс, то TCP не разгонится. Хотя, я думаю, что торрент вынесет TCP при таком балансинге. Начнет увеличиваться джиттер и TCP на закачках начнет сдуваться, а торрент пиров добавит. Лучше для упрощения ситуации проверьте на предсказуемых передачах, тем более для вашей скорости можно спокойно сделать и в одном и в другом классе просто http закачки. UPD. Я вам сразу секрет открою: если вы всё это затеяли, чтобы пользователи с торрентами, могли не выключая торренты сайтики открывать, то вам надо торренту давать 80-90% полосы максмум, чтобы второму классу хоть что-то оставалось, чтоб начать выдавливать торрент. Но тогда нучнуться возмущения, "где мои 2 Мбита", "почему я могу качать только на 1.5". А если делать с полным перекрытием, как у Вас, да еще и на таком канале, то оно работать не будет, особенно где торрент UDP. Он просто тупо всё вынесет. Работать это будет только при одинаково агресивных потоках, либо, когда высокоприоритетный трафик в агресивном потоке ( он правда тогда и сам всё сделает ).

Что-то я не понимаю: 1. Почему у класса 1:90 prio 7? 2. Почему у класса 1:5 прио вообще нет? Далее анализ: Судя по статистике в корзине у 1:5 токены есть, а дропов нет. Если в этом классе работает TCP, то наверняка он пожал размер окна, как только пинг вырос. Попробуйте качать в 2-3 потока, либо грузить по UDP.

Интересует вывод tc -s class show .... во время нагрузки и не правильной работы. Про единицы Мбит, имеется ввиду ширина класса, а там хоть в битах указывайте - шире от этого класс не станет.

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

У вас для обоих случаев RATE 1:3 < SUM(RATES) от лифов. 90 < 95.

2s.lobanov: Так вот не хочется 2 шлюза отдавать именно по причине непонятного поведения. И если на винде, линухе еще это всё вроятно нормально работает, то на SOHO роутерах возникнут недиагностируемые проблемы с вероятностью 100%. Поэтому только один шлюз, а дальше уже VRRP/CARP. Шлюзы емкие, поэтому отбалансить на уровне "столько-то клиентов туда-то" вполне допустимо. Прийдется оставлять запасы, конечно, но что делать - это издержка любых технологий. Динамически раскидывать клиентов в зависимости от загрузки можно через DHCP. У нас NAT+реальные адреса кому надо, поэтому проблемы с адресами точно не будет - хватит всем. 2st_re: я так понимаю у вас фря?

2s.lobanov: На сколько я понимаю как работает VRRP и CARP, то клиент получает как раз один адрес шлюзом, а сам адрес уже на уровне этой технологии резервируется. То есть для клиента всё прозрачно. При балансинге выдаются разные шлюзы ( те же 2 шлюза, которые друг друга резервируют, имеют, по адресу с VRRP/CARP ). С виду всё нормально и я даже уверен, что на стенде оно заработает. Интересует, кто реально так резервирует и кто пользуется этими технологиями в продакшене. Если не пользуются, то чем пользуются и почему. Метод с DHCP - это костыли, как и с DNS+VPN балансировкой. Оно наверное работать будет, но очень много вопросов. Начиная от "а если тот DHCP сервер, где клиент получил лиз ответить не успеет, а ответит второй, что будет?", заканчивая тем, сколько реально будет бегать запросов, пакетов по сети и какая будет чихарда с выдачей MAC-IP, если нужно связать жестко. Я однозначно против такого подхода. Касательно того как сделано у нас - не имеет никакого значения, потому что если надо будет - переделаем как должно быть. Топик именно об этом. 2st_re: Есть ли какие-то подводные камни или всё как в описании?

Мне кажется вариант с vrrp более вероятный, чем со свитчами - размер пока не позволяет разгуляться. Кто-то пользует VRRP, CARP для этих целей? Работает?

Нет, Л3 свитчей нет, всё по Л2. Вот хочу понять как люди решают эту задачу перед тем как делать какие-то движения. И вообще, решаема ли она нормально. Раздавать разные гейты - это ответ только на балансинг. А если гейт, который выдан клиенту накрылся? А если его надо перегрузить, снять на профилактику, etc.? Клиенты курят бамбук?

Господа, кто как решает задачу балансировки и фейловера для IPoE? С pppoe и vpn всё ясно - первый задачу отлично решает, а второй с костылями, но как быть с IPoE? Спасибо.

Если это роутер, который роутит инет и локалку, то в filter, FORWARD однозначно будет пакет с маком. Нужно искать, почему там мак другой и кто его меняет. Никаких raw, PREROUTING и другого не надо.

Если пакеты дропаются по IP, а по маку нет, значит мак другой для обмена по локальной сети. Посмотрите внимательно пакеты, какой мак на тразитных из сети в сеть. Если трафик внутри сети маршрутизируются, то там спокойно может быть мак роутера.

Как и ожидалось - невооруженным взглядом нагрузка не видна.

Пока не знаю, сегодня запускаем, до этого катали в виде теста, но учитывая, что это уровень ядра, я думаю будет гипер-быстро. Миррорить надо 100-200 Мбит в пиках. Не думаю, что вообще заметно будет. Увы, профайлер на 2.4 не становится, поэтому можно только сравнивать с тем что было.

Удалось портировать модуль. Повезло. Да, ну и конечно же, мейнтейнеры ядра идиоты, раз исключили такой замечательный модуль оттуда. Насколько я вижу, он и в 2.6 добавляется с патчами. Точно такие же идиоты мейнтейнеры iptables. Но у них хоть ссылка на patch-o-matic-ng есть и на том спасибо.

2Ivan_83: Не вижу проблемы. Зачем пакет в процессоре? Мы его анализировать не собираемся. 2vitalyb: Да, вариант. Отрицательный момент, что будет мирорриться всё. Посмотрю, можно ли без промиска по IP пакеты выцеплять. 2marikoda: порядка гигабита. 2NiTr0: Да я тоже смотрел на этот вариант. Я просто хотел для начала спросить, можно ли без костылей. Думал, может упускаю какой-то нормальный вариант. А оно вон что. Сначала попробую портироваться, а потом уже буду танцевать с tcpdump, раз других вариантов нет. Ну и остается, конечно, переустановка системы еще, как самый вменяемый вариант.

tcpdump = promisc mode. Я согласен, что ядро древнее, но так уж исторически сложилось и менять его - это дополнительный геморой. Тем более что операция-то простая: взять пакет в той же области mangle и скопировать его куда попросят. В том же архиологическом ядре 2.4.20 хедеры этого модуля есть, а в последнем 2.4 его убрали зачем-то. То есть правильно ли я понимаю, что без промиска и костылей на 2.4 нельзя смиррорить трафик?

Промиск на интерфейсе убъет машину. Неужели нет ничего ядерного чтобы смиррорить?