[vadius]

Подскажите пожалуйста, не могу придумать как грамотно разрулить шейпера.

Имеем в упрощенном виде:

inet город

\ /

ROUTER

/ \

NAS1 NAS2

|||| ||||

клиенты

 

ROUTER:

FreeBSD 8.2

Bgp, ospf.

 

NAS:

FreeBSD 8.1

Mpd5(pptp), Radius.

 

Нужно настроить шейпера, чтобы скорость интернета у клиентов была согласно тарифному плану,

а городские ресурсы без ограничений. У клиентов реальные IP.

На данный момент шейпер(dummynet) висит на ROUTER на входящем интернет интерфейсе.

На каждый тарифный план выделена своя подсеть и есть несколько правил типа:

00011 pipe 1 ip from any to 111.222.333.0/24 in via eth1

00011 pipe 2 ip from 111.222.333.0/24 to any out via eth1

где eth1 смотрит в инет.

Есть желание все это перевести на таблицы, и уйти от привязки ip адреса к тарифному плану.

 

Думал перенести шейпера на NASы, и формировать таблицу через radius аттрибут mpd-table с tablearg, или шейпить

через ng_car. Но во всех этих случаях скорость ограничивается и на интернет и на город. Есть вариант,

на роутере заворачивать трафик пришедший из инета в влан, а на NASе только его шейпить, но не понятно как

шейпить исходящий, опять будет действовать и на город и на инет.

 

Если поднимать таблицы на ROUTER, то как их там формировать?

Как лучше сделать, подскажите.

Изменено 12 мая, 2011 пользователем vadius

[sid1333]

Доброго дня.

 

На роутере правила можно оформить например так (предполагается что "город" и "инет" приходят в разные интерфейсы):

fw="/sbin/ipfw"
fwa="${fw} add"
${fwa} allow ip from any to any in                                  # приходящий в роутер трафик пропускаем сразу
${fwa} skipto 300 ip from any to any recv ${inet_if} xmit ${nas_if} # разобрали входящий инетный трафик
${fwa} skipto 300 ip from any to any recv ${nas_if} xmit ${inet_if} # разобрали исходящий инетный трафик
${fwa} skipto 200 ip from any to any recv ${city_if} xmit ${nas_if} # разобрали входящий "городской" трафик
${fwa} skipto 200 ip from any to any recv ${nas_if} xmit ${city_if} # разобрали исходящий "городской" трафик

${fwa} deny ip from any to recv ${city_if} xmit ${inet_if}          # левый транзит
${fwa} deny ip from any to recv ${inet_if} xmit ${city_if}          # левый транзит

${fwa} 200 allow ip from any to any out                             # трафик пошёл в/из города

${fwa} 300 pipe tablearg ip from any to table\(${inet_in_tbl}\)     # шейпим входящий трафик с инета
${fwa} 301 pipe tablearg ip from table\(${inet_out_tbl}\) any to    # шейпим исходящий трафик в инет
${fwa} 302 allow ip from any to any                                 # кого шейпить не нада, пропускаем

Как заполнять соответствующие таблицы решать вам (если ИПы у пользователей статические, то при заведении в биллинге, если динамика из пула, то можно подумать)

[Grey]

Подскажите пожалуйста, не могу придумать как грамотно разрулить шейпера.

Имеем в упрощенном виде:

 

mpd5 умеет шейпить сам. То, что "в трубе" зашейпит mpd5, всё остальное шейпить на ipfw (к примеру) или вообще не шейпить ...

читайте про mpd-filter, mpd-limit, mpd-input-acct и mpd-output-acct

у меня таким способом шепится согласно тарифу всё что в трубе учитывая с каких сетей считать трафик, а с каких не считать (опять же согласно тарифу) клиент просто перекидывается из группы в группу. группа привязана к тарифу, т.е. сменили тариф - сменилась группа, в которую включён клиент, всё на PgSQL, включайте фантазию и всё получится :)

Изменено 12 мая, 2011 пользователем Grey

[Ilya Evseev]

Шейпинг через таблицы и dummynet: http://forum.nag.ru/forum/index.php?showtopic=54379

Два правила ipfw, две таблицы, по две трубы на каждый тариф, по одной записи в двух таблицах на каждого клиента.

 

Если локальных диапазонов много, поместить их в таблицу.

Иначе проверять списком:

ipfw add 100 allow all from any to 10.0.0.0/8,192.168.0.0/16,172.16.0.0/12

ipfw add 110 allow all from 10.0.0.0/8,192.168.0.0/16,172.16.0.0/12 to any

Правило проверки поставить перед "ipfw pipe tablearg ...".

Если после pipe есть правила, которые надо выполнять для всех, заменить "allow" на "skipto".

[vadius]

Благодарю за ответы.

Немного ввел в заблуждение насчет реальных ip, так что извините.

Суть такая. По dhcp клиент получает адрес из диапазона "городских" серых адресов, по которым он может ходить по "городским" ресурсам (около 40 других городских сетей), без доступа в инет. После подключения по pptp он получает реальный ip, в этом случает доступ на все ресурсы не ограничен. Вот здесь и надо резать скорость только на инет.

 

mpd5 умеет шейпить сам. То, что "в трубе" зашейпит mpd5, всё остальное шейпить на ipfw (к примеру) или вообще не шейпить ...

читайте про mpd-filter, mpd-limit, mpd-input-acct и mpd-output-acct

у меня таким способом шепится согласно тарифу всё что в трубе учитывая с каких сетей считать трафик, а с каких не считать (опять же согласно тарифу) клиент просто перекидывается из группы в группу. группа привязана к тарифу, т.е. сменили тариф - сменилась группа, в которую включён клиент, всё на PgSQL, включайте фантазию и всё получится :)

пытался и так реализовать, но здесь как я понимаю в mpd-filter нужно перечислять с каких сетей трафик шейпить, а у меня в пиринге порядка 40 городских сетей, список ip-адресов постоянно меняется, таблицы маршрутизации строятся на роутере через bgp. Хотя не исключаю, что я где-то не врубился :)

 

Шейпинг через таблицы и dummynet: http://forum.nag.ru/...showtopic=54379

Два правила ipfw, две таблицы, по две трубы на каждый тариф, по одной записи в двух таблицах на каждого клиента.

спасибо, почитаю приведенную ветку. А если всех клиентов (~4тыс.) активных и не активных, засунуть в таблицы на роутере (с периодическим обновлением), dummynet сможет переварить их нормально? А то может я зря ищу способ как на роутере изменять таблицы при подключении клиента к NASу и его отключении.

[Grey]

Благодарю за ответы.

Немного ввел в заблуждение насчет реальных ip, так что извините.

Суть такая. По dhcp клиент получает адрес из диапазона "городских" серых адресов, по которым он может ходить по "городским" ресурсам (около 40 других городских сетей), без доступа в инет. После подключения по pptp он получает реальный ip, в этом случает доступ на все ресурсы не ограничен. Вот здесь и надо резать скорость только на инет.

 

mpd5 умеет шейпить сам. То, что "в трубе" зашейпит mpd5, всё остальное шейпить на ipfw (к примеру) или вообще не шейпить ...

читайте про mpd-filter, mpd-limit, mpd-input-acct и mpd-output-acct

у меня таким способом шепится согласно тарифу всё что в трубе учитывая с каких сетей считать трафик, а с каких не считать (опять же согласно тарифу) клиент просто перекидывается из группы в группу. группа привязана к тарифу, т.е. сменили тариф - сменилась группа, в которую включён клиент, всё на PgSQL, включайте фантазию и всё получится :)

пытался и так реализовать, но здесь как я понимаю в mpd-filter нужно перечислять с каких сетей трафик шейпить, а у меня в пиринге порядка 40 городских сетей, список ip-адресов постоянно меняется, таблицы маршрутизации строятся на роутере через bgp. Хотя не исключаю, что я где-то не врубился :)

Если "городские" - это серые, то их не так много и можно указать все сразу (надеюсь серые сети в инет вы не выпускаете). В своё время я долго тестил такое решение и в итоге внедрил. Нареканий нет, всё достаточно гибко и стабильно работает. Причём это без костылей в виде скриптов и т.п., работает на уровне самого mpd (т.е. на уровне ядра).

[vadius]

Если "городские" - это серые, то их не так много и можно указать все сразу (надеюсь серые сети в инет вы не выпускаете). В своё время я долго тестил такое решение и в итоге внедрил. Нареканий нет, всё достаточно гибко и стабильно работает. Причём это без костылей в виде скриптов и т.п., работает на уровне самого mpd (т.е. на уровне ядра).

у меня возникает один нюанс: Пока клиент не подключился к впн серверу(pptp), ip у него серый и он свободно может лазить по городским ресурсам, резать скорость не надо, в инет доступа нет. После подключения к впн клиент получает реальный ip и он уже с этим адресом лазит и в инете и в городе. В городе анонсированы и серые и белые адреса клиентов. Поэтому фильтровать город по серым адресам не получается. Вот если бы в mpd-filter можно было указать интерфейс, было бы проще.

[Grey]

Если "городские" - это серые, то их не так много и можно указать все сразу (надеюсь серые сети в инет вы не выпускаете). В своё время я долго тестил такое решение и в итоге внедрил. Нареканий нет, всё достаточно гибко и стабильно работает. Причём это без костылей в виде скриптов и т.п., работает на уровне самого mpd (т.е. на уровне ядра).

у меня возникает один нюанс: Пока клиент не подключился к впн серверу(pptp), ip у него серый и он свободно может лазить по городским ресурсам, резать скорость не надо, в инет доступа нет. После подключения к впн клиент получает реальный ip и он уже с этим адресом лазит и в инете и в городе. В городе анонсированы и серые и белые адреса клиентов. Поэтому фильтровать город по серым адресам не получается. Вот если бы в mpd-filter можно было указать интерфейс, было бы проще.

интерфейс чего? интерфейс на NAS, который один для всего (наружу)? или интерфейс на ROUTER? :) или интерфейс в сторону клиента? который ngxx и всегда разный?

Вот что было бы действительно правильно, так это при поднятии pptp передавать клиенту маршруты, но винда это дело игнорирует. Вот если NAS на винде - тогда поедит, а так не хочет. Хотя с другой стороны, если в "городе" в любой момент может приехать анонс новой подсети, то толку от маршрутов никакого ...

Изменено 13 мая, 2011 пользователем Grey

[Ilya Evseev]

А если всех клиентов (~4тыс.) активных и не активных, засунуть в таблицы на роутере (с периодическим обновлением), dummynet сможет переварить их нормально?

Сможет. У нас так и делается, количество клиентов больше.

[vadius]

Сможет. У нас так и делается, количество клиентов больше.

спасибо, пошел по этому пути, уже накатал скрипты.

[vadius]

интерфейс чего? интерфейс на NAS, который один для всего (наружу)? или интерфейс на ROUTER? :) или интерфейс в сторону клиента? который ngxx и всегда разный?

у меня на роутере весь трафик идущий с инета к NASу, заворачивается в влан. Сейчас это используется чтобы на NASах была возможность отделить инет от города, и вести учет трафика в биллинге только с инета. так у меня была идея шейпить этот трафик на NASe приходящий по влану с роутера

[[S]]

А выдавать маршруты через dhcp "в город" нельзя?

Соответственно при поднятии pptp дается дефолтный в интернет (который шейпится и считается), но статичные маршруты через dhcp всё равно ходят через eth-интерфейс клиента.

[Grey]

' timestamp='1305435004' post='613484']

А выдавать маршруты через dhcp "в город" нельзя?

Соответственно при поднятии pptp дается дефолтный в интернет (который шейпится и считается), но статичные маршруты через dhcp всё равно ходят через eth-интерфейс клиента.

верное было бы решение, если бы в "городе" было бы статичесское (или управляемое) кол-во анонсируемых сетей. Но у человека "город" может в любой момент анонсировать какую угодно сеть.