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

решил я вчера траблу. Это было дикое стечение мелких косяков. црц ошибки между радиусом и ацелем+ штук 20 роутеров тенда и нетис, которые после потери интеримов между брасом и радиусом, усыпали и переставали отвечать на лсп. Но при активности клиента переконекчивались и начинали снова работать.

Ух-ты, а причина црц?

но между радиусом и аццелем

а не между аццелем и клиентом

я сначала обратил внимение что в шоу стат много интерим лост

потом что дропаются одни и те же клиенты

штук 20 при 1000 сессий

узнали что между ними общего

марка роутера

перевел порт в 10мб принудительно црц пропали, интеримы побежали ровно. рутера переконектились и перестали усыпать.

хотя другие рутера нормально реагировали,и сессии висели по пару суток

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

It's true. I can't check the log yet

Доброго понедельника. Готовлюсь мигрировать с текущей реализации BRAS на FreeBSD на Accel-PPP. Подскажите пожалуйста возможно ли сейчас при схеме с ipoe по unclassified packet назначать один qdisk нескольким "сессиям" одного абонента? Кейс - единая скорость на услугу клиента по его нескольким IP адресам. И если нельзя из коробки, то на сколько реально это провернуть какими-то кастомными скриптами shaper-up/shaper-down. Спасибо.

можно вопрос? а почему покидаете freebsd?

ну на фряхе понятно как делать pppoe, а для ipoe control-plane вроде никто не запилил для фряхи

Текущий шейпинг реализован на dummynet, а он упирается в одно ядро. Вроде бы есть варианты шейпить на ng_*, но не хочется инвестировать в исследования на этой ОС, кажется что там добиться производительности - надо разобраться с триллионом всяких крутилок, что в linux намного более "человечнее" реализовано.

ipt-ratelimit кажется умеет что вы хотите

Благодарю за вариант. Пока разбирался с теоретической частью вопроса шейпинга в linux и сложил мнение, что если не использовать tc class для шейпинга с "заворотом" в них через hashkey tc filters то производительность фаерволла упадёт из-за количества правил. И в целом не хочется использовать ни iptables ни ipset - поднял отдельный NAT на nftables и выглядит что про все остальные фаерволлы лучше уже забыть в 2021 (могу ошибаться) и так же не инвестировать время в разбирательства с ними.

Пока есть вариант в голове - скриптом генерировать tc filters c hashkey для всех абонентов и направлять трафик в нужные qdisc (хоть каждого в свой, хоть нескольких в один). Либо использовать для той же цели "новомодный" nftables (по информации, которую собрал - он так же использует хеширование и как будто не должно быть разницы в производительности с tc hashkey filter) и так же иметь возможность направлять трафик в какие угодно qdisc.