Народ подскажите как решить задачу:
Прежде чем отписываться, прочтите полностью задачу
Дано Сервер, под управлением UTM5 с Linux подобной ОС к которому нет никаког доступа (сервер типо провайдерский) на котором крутится анлим, соединение VPN (pptp (как оно реализовано известно только провайдеру)) админ сети может только создавать учетки и прикреплять к ней тарифы, при том ограничено кол-во тарифов и учеток, а к серверу реально доступ физический есть (т.е. сменить логи и пароль можно), но возможно получить скандал, и отказ от предоставления услуг со стороны провайдера.
Нужно:
Каким то образом (железка/сервер) создать N подключений (где N это максимальное количество учеток которые предоставляет провайдер), что бы было тупо суммирование всей скорости в один поток, и последующая передача на сервер, который уже будет распределять анлим с той скоростью и так, как нужно админу.
Во, пожалуй все, если у кого есть какие варианты решения проблемы, подскажите
суммирование скорости
Re: суммирование скорости
А в чем проблема? Траффик в шейпере можно сортировать ведь не только по интерфейсам, но и по IP источника и приемникаlasik писал(а):суммирование всей скорости в один поток, и последующая передача на сервер, который уже будет распределять анлим с той скоростью и так, как нужно админу.
Собссно - создается на машине-шейпере класс со скоростью X кбит/с, на каждый IP - заводится класс с rate = X/N и ceil =X кбит/с, на него вешается sfq дисциплина, и u32 классификаторами заворачивается траффик с нужным источником в нужный класс. Итого - имеем нарезанные каналы с минимальной гарантированной скоростью X/N кбит/с, + равномерное распределение избыточной скорости (при неактивности кого-либо) между клиентами.+ можно поиграться размером буфера токенов - для ускорения загрузки страничек при активно пользуемом канале...
P.S. хотя я не монимаю, при чем здесь биллинг...
А, нужно распараллеливание канала, т.е. - задача с точностью до наоборот? 
Почитайте LARTC. Коротко - создаются соединения, маршрутизация прописывается как ip route add default nexthop via .... nexthop via .... и т.д.
Ну и нат ессно...
Проверял на 2х каналах - работало. Но, ессно, соединение к какому-либо серверу будет устанавливаться через один из каналов "пула", и вроде как маршруты кешируются (хотя особо не тестил, инфа по этому поводу найдена в инете). Ессно, для 1й сессии будет доступен только 1 канал, и какая будет результирующая скорость - сложно сказать.
Почитайте LARTC. Коротко - создаются соединения, маршрутизация прописывается как ip route add default nexthop via .... nexthop via .... и т.д.
Ну и нат ессно...
Проверял на 2х каналах - работало. Но, ессно, соединение к какому-либо серверу будет устанавливаться через один из каналов "пула", и вроде как маршруты кешируются (хотя особо не тестил, инфа по этому поводу найдена в инете). Ессно, для 1й сессии будет доступен только 1 канал, и какая будет результирующая скорость - сложно сказать.
1. ставится нас который поднимает/держит N туннелей на проваКаким то образом (железка/сервер) создать N подключений (где N это максимальное количество учеток которые предоставляет провайдер), что бы было тупо суммирование всей скорости в один поток, и последующая передача на сервер, который уже будет распределять анлим с той скоростью и так, как нужно админу.
2. на насе настриваются правила маршрутизации которые либо:
а) жестко привязывают по нужным критериям нужный трафик к нужному(ым) туннелю(ям)
б) реализуют балансировку каналов с целью равномерного распределения нагрузги на туннели с учётом их толщины и их возможного резервирования
и то и другое прекрасно реализуемо что под линухом что под бздёй
ну а если нада готовое решение под ключ - нэма пытань - пиши в личку цену обсудим
