Jump to content
Калькуляторы

Шейпер для Linux сервера Есть ли у кого готовое решение?

Вопрос следующий:

 

Имеется Linux сервер, один интерфейс смотрит на десяток абон.подсетей (каждая в своем влане)

другой интерфейс с белым ипом на маршрутизатор более высокого уровня.

 

На сервере поднят dhcp с opt82, настроен нат. Необходимо написать шейпер для безлимитных тп.

 

Ранее использовался ppp, есть шейпер, использующий дисциплины HTB и SFQ.

 

Может быть есть у кого-нибудь наработки для схемы без туннелей?

Неохота тратить время на написание "велосипеда".

Share this post


Link to post
Share on other sites
Вопрос следующий:

 

Имеется Linux сервер, один интерфейс смотрит на десяток абон.подсетей (каждая в своем влане)

другой интерфейс с белым ипом на маршрутизатор более высокого уровня.

 

На сервере поднят dhcp с opt82, настроен нат. Необходимо написать шейпер для безлимитных тп.

 

Ранее использовался ppp, есть шейпер, использующий дисциплины HTB и SFQ.

 

Может быть есть у кого-нибудь наработки для схемы без туннелей?

Неохота тратить время на написание "велосипеда".

Может это Вам подойдет

Share this post


Link to post
Share on other sites

Ну либо LISG вообще тоже неплохой вариант, особенно если у вас есть radius для аутентификации и аккаутинга абонентов

Share this post


Link to post
Share on other sites

http://adm.freelsd.net/hashiz - но это скорее болванка, а не готовое решение.

Как там сказано, about 1...10 minutes of execution.. depend from your cpu. Оно даже не умеет пакетный режим tc использовать, который позволяет в разы ускорить время загрузки правил.

Edited by photon

Share this post


Link to post
Share on other sites

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

 

Скрипт от photon я вчера бегло просмотрел, попробовал. Работает.

Но он подходит для случая, когда требуется только функция шейпинга при условии транзитного прохождения трафика через сервер через 2 интерфейса без использования ната.

 

От ната на ppp интерфейсах мы давно ушли путем выдачи динамических белых ипов, а сейчас ушли от ppp и снова столкнулись в натом. Выдавать каждому клиенту по статическому белому ипу - никаких ипов не хватит.

 

Потом, у сервера есть третий интерфейс - для обмена локальным трафиком внутри ас и для пирингового трафика. Тут ограничений быть не должно.

Переносить нат на вышестоящее оборудование не хочется, там циски, они нат очень не любят. Докупать оборудование и усложнять систему тоже не хочется.

 

Можно строить шейпер только на пользовательском интерфейсе, входящий трафик резать с помощью IMQ, которая хорошо совместима с натом (CONFIG_IMQ_BEHAVIOR_AB - After DNAT, Before SNAT). Ingress qdisc с полисингом и политикой drop давно еще тестировали - график далек от ровного, похож на пилу с большими зубцами. Приходилось даже коэффициент умножения скорости вводить, чтобы объем трафика за интервал времени соответствовал заявленной скорости.

Share this post


Link to post
Share on other sites

От ната на ppp интерфейсах мы давно ушли путем выдачи динамических белых ипов, а сейчас ушли от ppp и снова столкнулись в натом. Выдавать каждому клиенту по статическому белому ипу - никаких ипов не хватит.

А сколько всего юзеров? Если адресов не хватает, значит плохо просили. Получите статус LIR, и они вам без вопросов отстегнут /18.

Edited by photon

Share this post


Link to post
Share on other sites

А сколько всего юзеров? Если адресов не хватает, значит плохо просили. Получите статус LIR, и они вам без вопросов отстегнут /18.

LIR давно есть. Где-то через полгода заканчивается план реализации последнего полученного блока /21, будем просить еще. До этого не удавалось получать за раз больше /21.

Share this post


Link to post
Share on other sites

LIR давно есть. Где-то через полгода заканчивается план реализации последнего полученного блока /21, будем просить еще. До этого не удавалось получать за раз больше /21.

Хм... значит IP-адреса действительно заканчиваются. Два года назад можно было сразу взять /18.

Share this post


Link to post
Share on other sites

2photon: действительно заканчиваются, сейчас и план уже на 9 мес., потом на 6 и.т.д.

Share this post


Link to post
Share on other sites

Оно даже не умеет пакетный режим tc использовать, который позволяет в разы ускорить время загрузки правил.

Что за пакетный режим?

Share this post


Link to post
Share on other sites

batch mode загружает все правила за один вызов tc, так же как restore у iptables

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this