rat: PF + altq + пользователь по VPN = "справедливое" деление канала

2 сообщения / 0 new
Последнее сообщение
Гость
rat: PF + altq + пользователь по VPN = "справедливое" деление канала

(типа, кроспост с www.3nity.ru )

Добрый день,
Хочу услышать людей, настроивших сабж (я сейчас делаю на Freebsd 6.4 но интересно услышать вообще варианты решения). Если чего - mpd - это pptp\pppoe сервер во фре.

Смысл:
Есть пользователи, которые подключаются по VPN к шлюзу
Скажем, вот такой вариант : динамически поделить полосу так, чтобы ограничение скорости вычислялось из что-то вроде "пропускная способность полосы, поделенная на кол-о пользователей + заимствование у тех, кто в данный момент полосу не занимает". Т.е. я хочу добиться максимально эффективного потребеления полосы. Разумеется, чтобы при этом если простаивающий канал начинал использоваться - чтобы ему полосу возвращали

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

В принципе, то. что хочу, укладывается в алгоритм, подобными cbq по логике действия, но можно ли это сделать без головной боли на фре+PF (или на чем-то еще!?) - это уже для меня вопрос... (а на линухе?).

1) Можно ли (и нужно ли? ) запихивать в altq совокупность виртуальных каналов? (с mpd - это ng0 ng1 ... )
2) Можно ли ставить в cbq (как вариант) GRE на внутреннем интерфейсе (в сторону клиентов) - я не понял, почему этот вариант не обсуждается.
3) Чем я от клиента могу оценить задержки по, например, http... т.е. чем можно поисследовать эффективность приоритетов, которые я поназначал? Чем из винды можно качественно забить канал?

p/s/
Существует ли реализация burst(?) для фри (линухи?) - т.е. когда для первых нескольких десятков килобайт трафа или по времени делается преимущество, выше ограничения трубы (что-то смутное в переписке про dummynet встретил, но пректических реализаций -нет)

p/s/s/ В данный момент работает pf+ pfnat+ipfw как шейпер с динамическими правилами для события up\down интерфейса под vpn

p/s/s/s
Мне поступило предложение посмотреть на microtik(router OS) для решения

Спасибо.

nikus (не проверено)

>динамически поделить полосу так, чтобы ограничение скорости вычислялось из что-то вроде "пропускная способность полосы, поделенная на кол-о пользователей + заимствование у тех, кто в данный момент полосу не занимает"
1) Бьете клиентов на группы которые будут делить одну полосу
2) Создаете трубу с указанием максимальной скорости полосы
3) Раздаете клиентам равноприоритетные очереди.

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

В качестве экзампела:
#труба с ограниченной полосой(Реальная скорость, а не обещанная!!!)
ipfw pipe 1 config bw 1Mbit/s
#очереди для клиентов(за счет 0xffffffff вы создаете для каждого клиента свою очередь на едином шаблоне)
ipfw queue 1 config pipe 1 weight 50 mask dst-ip 0xffffffff
ipfw queue 2 config pipe 1 weight 50 mask src-ip 0xffffffff
#ваши клиенты делящие эту полосу
ipfw add queue 1 ip from any to 192.168.0.0/24
ipfw add queue 1 ip from 192.168.0.0/24 to any

>Существует ли реализация burst(?) для фри (линухи?) - т.е. когда для первых нескольких десятков килобайт трафа или по времени делается преимущество, выше ограничения трубы (что-то смутное в переписке про dummynet встретил, но пректических реализаций -нет)
Ковыряйте GRED

>Мне поступило предложение посмотреть на microtik(router OS) для решения
Насколько мне известно он не совсем бесплатен. Но это не мешает ему быть столь любимым у некоторых местных провайдеров. За счет своих крохотных потребностей его обычно крутят в нескольких виртуальных машинах на одном "мощном" железе, тем самым создавая для себя иллюзию независимости одних пользователей от других.

RSS-материал