+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Полученный лимит, отправленный лимит.

Полученный лимит, отправленный лимит., RouterOS

savage

Guest

22.03.2005 17:52:00

Всем привет,

Просто пара вопросов по поводу вышесказанного… Документация этого не показывает (поэтому я уже начинаю думать, что мне не повезет), но есть ли возможность получить "Combined-Limit", возможно, как запрос функции для 2.9, используя вышеуказанные атрибуты… Что происходит, когда достигнут Recv-Limit или Xmit-Limit? Пользователь отключается, или MT просто перестает отправлять или получать дополнительный трафик через интерфейс? И, напоследок, используя FreeRadius и различные модули подсчета в нем, кому-нибудь удалось заставить Recv-Limit и Xmit-Limit работать успешно с FreeRadius и модулями SQLCounter?

wildbill442

Guest

22.03.2005 19:45:00

Комбинированный предел… да что ж такое, человек… просто укажите желаемые пределы Tx/Rx и забудьте об этом. Нельзя разрабатывать программное обеспечение, чтобы угодить каждой прихоти каждого пользователя. Когда один из пределов (Tx/Rx) достигнут, срабатывает какой-то алгоритм, который снижает трафик ниже заданных лимитов. Я не знаю конкретики, так как это, вероятно, ноу-хау MT и не является общедоступной информацией. Пользователь не замечает никаких перебоев в обслуживании, просто его трафик замедляется до лимитов, указанных в очереди. Это незаметно для конечного пользователя. Я лично не использовал RADIUS для настройки очередей для пользователей, но да, это возможно. Читайте, читайте, читайте инструкцию!

savage

Guest

22.03.2005 19:54:00

Я, кажется, уже наизусть выучил инструкцию. Мне нужно найти способ ограничить интерфейс до максимального объема передачи данных (например, чтобы пользователь мог скачивать только 1 ГБ). Затем пользователя нужно отключать и приостанавливать его аккаунт. И это должно происходить в реальном времени… Я могу сделать это на основе данных Radius Accounting, но проблема в том, что подсчет трафика пользователя будет происходить только при входе в систему — соответственно, если пользователь ограничен в 1 ГБ, он вполне может скачать 15 ГБ до отключения, и система ничего не сможет с этим поделать (кроме неудачной попытки повторного входа). Это не решит мою проблему, ведь на системе уже будет 14 ГБ «неоплаченного» трафика. Таким образом, единственная альтернатива — ограничивать трафик на NAS (как MT). С точки зрения Radius я могу отправлять атрибуты Recv-Limit и Xmit-Limit с правильными значениями, без проблем. Но мне нужно знать, ЧТО делает MT, когда это значение достигнуто. Даже если MT просто «замедляет» порт, как вы упоминали ниже, каков смысл Recv-Limit и Xmit-Limit, если пользователь может превысить установленные лимиты? Для справки, я не говорю про СКОРОСТЬ, я говорю про ограничение фактического количества байтов, полученных/отправленных через Интерфейс (вероятнее всего, PPTP-туннели).

wildbill442

Guest

22.03.2005 19:59:00

Прости, видимо, я неправильно понял, что ты написал... Я думал, речь идет об ограничении полосы пропускания, а не об общем объеме переданных данных. Это делается через AAA (Аутентификация, Авторизация и Учет) и должно быть настраиваемо на RADIUS-сервере. Я не могу дать конкретные детали, так как сам еще не настраивал это. Но это можно сделать с MT.

savage

Guest

22.03.2005 20:03:00

Да, я так и думал. Recv-Limit, Xmit-Limit (согласно руководству) действительно ограничивают общее количество байтов, а Rate-Limit – скорость. Значит, у меня все атрибуты в порядке. И разве моя просьба о Combined-Limit такая уж безумная? Cmit, MT, ребята, кто-нибудь??? Что происходит… ПОЖАЛУЙСТА скажите мне, порт отключается, когда лимит достигнут??? ПОЖАЛУЙСТА

cmit

Guest

23.03.2005 08:28:00

Ну… думаю, добиться того, что ты хочешь, точь-в-точь не получится, но "почти". Настройка должна быть примерно такой (черновой сюжет): аутентификация/учет через RADIUS-сервер. Имей базу данных на RADIUS-сервере, где хранишь пользовательские аккаунты, их лимит разрешенного трафика и столбец "оставшийся трафик за текущий период". Инициализируй "оставшийся трафик" значением "разрешенный трафик за период" (например, 1 ГБ). Когда пользователь успешно аутентифицируется, отправляй атрибуты Access-Accept “Recv-Limit” и “Xmit-Limit”, установленные на значение "оставшийся трафик за период". Это закроет соединение, когда загрузка или выгрузка достигнет лимита "оставшийся трафик". Тебе придется запускать скрипт на RADIUS-сервере каждый раз, когда пользователь выходит из системы (это можно сделать, например, с помощью FreeRADIUS). Этот скрипт должен вычитать учтенный объем из "оставшегося трафика" и сохранять новый "оставшийся трафик" в твоей базе данных. При следующем входе пользователь получит эти лимиты как новые “Recv-Limit” и “Xmit-Limit”. "Нечеткая" часть в том, что теоретически (при постоянном равном объеме загрузки и выгрузки) пользователь мог бы использовать вдвое больший объем своего "оставшегося трафика" в последнем соединении. Проблема в том, что нет атрибута “Traffic-Limit” или подобного (который доступен для того же принципа на основе времени онлайн — атрибут “Session-Timeout”) для ограничения суммарного объема загрузки и выгрузки… Надеюсь, я достаточно ясно описал способ реализации. Конечно, ты можешь попробовать оптимизировать значения, которые отправляешь как Recv-Limit и Xmit-Limit. Например (если ты предлагаешь более низкую скорость загрузки, чем выгрузки), ты можешь установить Xmit-Limit равным 30% "оставшегося трафика", а Recv-Limit – оставшимся 70% или что-то подобное. Если тебе абсолютно необходимо убедиться, что никто не превысит 1 ГБ (или что-то подобное), тебе придется установить атрибуты так, чтобы сумма обоих была равна "оставшемуся трафику" пользователя. Но это почти наверняка приведет к ситуации, когда пользователь не сможет использовать весь свой трафик в "одном" соединении, но должен будет переподключаться чаще по мере приближения к нулю в своем "оставшемся трафике"…

savage

Guest

23.03.2005 08:38:00

Привет еще раз. Ну что, ночь выдалась насыщенной… 10:30 утра, а мне еще надо ложиться спать. Даже наткнулся на небольшой “баг” (если это вообще можно так назвать) во FreeRadius. В общем, Recv-Limit и Xmit-Limit – вот что мне нужно. Я изначально в этом не сомневался. MT уже используют кучу “нестандартных” атрибутов для своего radius, поэтому вы ДОЛЖНЫ использовать их собственный словарь с любым radius-сервером, которым вы пользуетесь. Так что я все равно говорю, что ‘Total-Limit’ для суммарного входящего и исходящего трафика – это не такая уж и нереальная штука. Это ОДНОЗНАЧНО будет фича, которую стоит потрудиться и закодить. Что касается ситуации… я не буду вдаваться в технические подробности СЛИШКОМ (это ЧЕРТ знает что такое сложное). В общем, что я сделал, так это использовал модуль rlm_perl во FreeRadius, и он считает используемые данные - разрешенные данные. Разница – это то, каким должен быть Recv-Limit и Xmit-Limit. Таким образом, я определяю правильные значения в реальном времени и передаю их MT. MT точно знает, когда отключать пользователя, и таким образом не может произойти “воровство трафика”. Это ОЧЕНЬ важная вещь для реализации. На данном этапе мой скрипт rlm_perl для обработки AAA отдельно от FreeRadius составляет примерно 1000 строк чистого perl, и я только делаю секцию аутентификации - даже не касался учета, дублированных пользователей и т.д. Как только все это будет готово и будет работать, я посмотрю и, возможно, ПОДУМАЮ о том, чтобы подарить его MT для менеджера точки доступа или что-то в этом роде. Уверен, что будет острая необходимость в этом. Чтобы обойти проблему "объединенного" трафика (пока MT не даст мне атрибут Total-Traffic), я буду использовать некий алгоритм, похожий на то, что ты описал, да. Total = (up + down)/2 и затем вычисляю соотношение между скоростью передачи/приема и значениями полосы пропускания вверх/вниз. Думаю, это максимально близкое, что я могу получить на данном этапе, когда речь идет о "системе в реальном времени". Идеальная ситуация была бы просто получить этот атрибут внутри MT. Да, с вышеописанным люди не смогут получить "весь" свой трафик в последней сессии, но думаю, что смогу добиться довольно близкого результата с помощью правильных вычислений. Усреднения тоже приходят в голову. Спасибо за всю помощь. Вы и многие другие ребята по всему миру очень помогли мне преодолеть действительно большую проблему.

savage

Guest

25.03.2005 08:41:00

Ладно. Сага немного продолжается. Касательно разделения полосы пропускания, есть относительно простой способ это сделать (хотя и не на 100% точно): 512/256k пользователей на пример: 512 + 256 = 768k в общей сложности.

Recv-Limit = (TotalBandwidth - UsedBandwidth)/768
256 Xmit-Limit = (TotalBandwidth - UsedBandwidth)/768
512

Сумма Recv-Limit и Xmit-Limit никогда не будет выше, чем TotalBandwidth - UsedBandwidth, так что, должно быть, все в порядке. Теперь, к следующей проблеме.

Я использую MT 2.8.24 для моего тестового/развивающего NAS. По какой-то причине, MT отправляет Accounting-Stop запросы дважды на Radius сервер… Может, кто-нибудь подскажет, почему?

rad_recv: Accounting-Request пакет от хоста 192.168.1.254:1028, id=98, length=275
Service-Type = Framed-User
Framed-Protocol = PPP
NAS-Identifier = "nas.domain.com"
NAS-Port = 51
NAS-Port-Type = Virtual
User-Name = "testy@prepaid.domain.com"
Calling-Station-Id = "192.168.1.10"
Called-Station-Id = "192.168.1.254"
MS-CHAP-Domain = "prepaid.domain.com"
Acct-Session-Id = "8100001c"
Framed-IP-Address = 198.18.1.212
Acct-Authentic = RADIUS
Acct-Session-Time = 5
Acct-Input-Octets = 5265
Acct-Input-Packets = 27
Acct-Output-Octets = 110
Acct-Output-Packets = 9
Acct-Status-Type = Stop
Acct-Terminate-Cause = User-Request
NAS-IP-Address = 192.168.1.254
Acct-Delay-Time = 0
Mikrotik-Attr-9 = 0x707265706169642e63656e657267796e6574776f726b732e636f6d

Обрабатывается секция preacct файла radiusd.conf

rad_recv: Accounting-Request пакет от хоста 192.168.1.254:1028, id=98, length=275
Service-Type = Framed-User
Framed-Protocol = PPP
NAS-Identifier = "nas.domain.com"
NAS-Port = 51
NAS-Port-Type = Virtual
User-Name = "testy@prepaid.domain.com"
Calling-Station-Id = "192.168.1.10"
Called-Station-Id = "192.168.1.254"
MS-CHAP-Domain = "prepaid.domain.com"
Acct-Session-Id = "8100001c"
Framed-IP-Address = 198.18.1.212
Acct-Authentic = RADIUS
Acct-Session-Time = 5
Acct-Input-Octets = 5265
Acct-Input-Packets = 27
Acct-Output-Octets = 110
Acct-Output-Packets = 9
Acct-Status-Type = Stop
Acct-Terminate-Cause = User-Request
NAS-IP-Address = 192.168.1.254
Acct-Delay-Time = 16777216
Mikrotik-Attr-9 = 0x707265706169642e63656e657267796e6574776f726b732e636f6d

Обрабатывается секция preacct файла radiusd.conf Единственное различие между пакетами - это Acct-Delay-Time. Сейчас пытаюсь разобраться, какое значение имеет этот Атрибут, но почему MT отправляет его дважды? Поскольку я получаю Accounting Stop запрос дважды, это значит, что я буду вычитать использованную полосу пропускания в завершенной сессии дважды - и, следовательно, это не желаемый результат. На данный момент, я использую Acct-Delay-Time = 0 как парсер, чтобы обрабатывать только первый Accounting-Stop запрос, но я не уверен, 1) будет ли это точно, и 2) будет ли Acct-Delay-Time всегда 0 для первого из двух запросов… Может, кто-нибудь подскажет что-нибудь еще? Я почти уверен, что это не проблема Radius, это сам MT отправляет Accounting Stop запрос дважды (два фактических пакета), поэтому на стороне Radius не так много того, что я могу сделать, чтобы это исправить. Спасибо всем!

cmit Guest	#9 0 30.03.2005 09:14:00 Наверное, подтверждение ("got it") от вашего RADIUS к MikroTik (подтверждение получения Accounting-Packet) приходит слишком поздно, поэтому MikroTik отправляет его повторно… Что касается обработки этих дубликатов: используйте Acct-Session-Id, это уникальный идентификатор для каждой сессии (и, соответственно, одинаковый для ваших двух дублирующихся Stop-пакетов). С помощью этого вы абсолютно можете быть уверены, что два Stop-пакета относятся к одной и той же сессии или нет.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры