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

Dmitry76

Пользователи
  • Content Count

    44
  • Joined

  • Last visited

About Dmitry76

  • Rank
    Абитуриент

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. И еще на тему mtu. При включенной опции unit_preallocate (которая нужна для правильного заполнения аттрибута NAS-Port), на все стартующие интерфейсы выставляется дефолтовый MTU 1500 б. При этом согласования LCP игнорируются. Можно исправить такое поведение?
  2. Подскажите, пожалуйста, есть ли возможность использовать несколько сетей в одном именованном пуле? Конструкция, типа: 192.168.0.0/24,name=pool1 10.0.0.0/24,name=pool1 прокатит?
  3. myth увы, но это ограничения для одного источника (клиента, мак, не важно). Надо что-бы общее ограничение было. Пока есть какие-то затыки с базой радиус и в случае резкого наплыва (допустим BRAS был перезагружен) возникают блокировки и после этого затыки. Надо, грубо говоря, для 500 клиентов сгенерировать Access-Request'ы не в течение секунды, а скажем, 30-60 сек.
  4. Подскажите, как правильно реализовать вот такое бутылочное горлышко... Все просто: есть схема клиент->accel->radius. Надо обграничить количество запросов на авторизацию каким-то определенным значением. Именно средствами акцеля. Я понимаю, многие пользователи не смогут сходу авторизоваться (особенно в случае перезагрузки сервера и массовых переконнектов), но тем не менее на текущий момент нужна такая реализация. Как это правильно сделать? Вижу два варианта: 1) в настройках радиус-авторизации выставить параметр req-limit: req-limit - number of simultaneous requests to server (0 - unlimited). 2) выставить padi-limit в секции pppoe в ненулевое значение. Тогда количество ответов на PADI будет ограничено и,соотвественно меньше будет генерироваться запросов на авторизацию для тех клиентов которые прошли полную Discovery фазу с этим сервером. Интересует поведение акцеля для запросов, которые превышают. Они отбрасываются или ставятся в очередь (вроде, по второму варианту сессия уходит в состояние starting в статистике). Спасибо!
  5. Добрый день! Какая-то странная ситуация с авторизацией по chap. accel (в продакшн сейчас 1.10.0) не отдает в CHAP Challnge поле Name, точнее он пустой: 14:05:21.884027 PPPoE [ses 0xde01] CHAP, Challenge (0x01), id 1, Value 223964e0c4e94031555b815a52420726, Name Согласно RFC1994 это недопустимо: Name The Name field is one or more octets representing the identification of the system transmitting the packet. There are no limitations on the content of this field. For example, it MAY contain ASCII character strings or globally unique identifiers in ASN.1 syntax. The Name should not be NUL or CR/LF terminated. The size is determined from the Length field. При этом в rp-pppoe в поле Name отдается hostname. Это для 99.99% клиентов не проблема и они со своими длинками и тплинками плевать хотели на пустой атрибут. Но есть 0.01% абонентов, которые используют, например Cisco ASA 5505 и которые строго следуют стандартам и авторизация не проходит. Есть ли решение?
  6. А скажите, какие-то подвижки в реализации session backup есть? Вроде, и исходники есть (accel-pppd/backup), но кроме упоминания, что "soft - restart daemon softly, e.g. keep existing connections if session backup is enabled (default)" нет.
  7. Подскажите, если в конфиге bras указаны два радиус сервера и в ходе сессии абонента отказывает тот, который дал для него access-accept, то аккаунтинг в interim-update будет отсылаться на второй радиус? Или это касается только стартов?
  8. Эта штука не поломалась. То есть, это не бага, а фича. Дело в том, что новый аксель создает пользовательский интерфейс после того как прошла успешная авторизация. Другими словами, когда шлется access-request, то на этом этапе еще нет номера порта, поэтому шлется <NAS-Port 4294967295> <NAS-Port-Id ""> Делается, это для того, чтобы не создавать лишнюю нагрузку на ядро при ненужном создании/удалении интерфейсов для юзеров, у которых закрытые лицевые счета. Получить номер порта можно из Accounting-Request. Там уже есть правильная информация: <NAS-Port 1189> <NAS-Port-Id "ppp1189"> Так что если у вас биллинг завязан на этом атрибуте именно в аксесс реквесте, то придется понижать версию до 1.9.0 Ну или пинайте биллинг, пусть берут из акаунтинга.
  9. Возможно. Я обновил версию (1.9.0 -> 1.10.2) и теперь у этого абонента разрыв по Acct-Terminate-Cause Lost-Carrier>. Ну это уже другое дело, уже понятно,в какую сторону копать.
  10. Подскажите, в каком случае аццель в режиме IPOE (старт сессии по dhcp) может разрывать по причине <Acct-Terminate-Cause User-Request>. Случай с pppoe понятен - клиент прислал PADT, PPP канал разобрался. А в случае IPOE? Клиент не продлил аренду адреса, так?
  11. Добрый день! Подскажите как выдавать в режиме IPOE отдельные честные адреса для клиентов? Режим такой: mode=L2 start=dhcpv4 ip-unnumbered=1 proxy-arp=1 attr-dhcp-client-ip=DHCP-Client-IP-Address attr-dhcp-router-ip=DHCP-Router-IP-Address attr-dhcp-mask=DHCP-Mask Допустим, что на сервере 192.168.0.1/24 Если серая сеть, то проблем нет - редиус отдал в аттрибутах данные для DHCP ответа, клиент принял и заработал через NAT. А вот отдать клиенту честный адрес /32 как правильно? Роутеры tp-link понимают, когда в ответе DHCP шлюз отдается 192.168.0.1 маска 255.255.255.0, а IP клиента, пусть 5.5.5.5. Но другие клиенты отказываются принимать такие параметры DHCP, либо же принимают, но трафик не ходит. Есть решение?
  12. Подскажите, а можно ли сделать такую вещь, чтобы после освобождения порта (речь идет о ppp), он не сразу занимался следующим авторизовываемым абонентом, а по возможности держался свободным какой-то время? Биллинг жалуется, что иногда старт по новой сессии они видят раньше, что стоп по этому же порту от предыдущего юзера. В логах аццеля последовательность правильная: сначала юзер отвалился (например по lcp timeout), а потом на этот порт подключает следующего. И это в одну секунду. С учетом, что авторизация происходит примерно 100-120 мс, то теоретически может быть, что очередь на самом радиусе создается иногда не в том порядке.
  13. Кажется, в точку. А именно, выключение мультитредовости.По большому счету для accel оно не нужно, точнее нужно самому userspace процессу. Пока полет нормальный. Релоадил несколько раз - проходит нормально. Может, какие-то проблемы с межпроцессным взаимодействием, может у меня в конфиге что-то накручено - не знаю. Работет, наблюдаю.
  14. Версия стоит 1.10.0 последний релиз. Такой же баг получался и если непосредственно делать в телнете акцеля (2000 порт). Через accel-cmd попробую.
  15. Хотел бы уточнить, почему изредка при попытке перечитать конфиг акцеля (подавая команду reload в cli или через tcp) в ответ тут же отдается "failed". Но самое печальное при этом, что процесс вываливается из памяти вместе со всеми абонентами (сначала виден как <defunc>, и потом и следа его нет). После перезапуска - все ок. [root@acc45 ~]# echo "reload"|nc 127.0.0.1 2001 failed root@acc45 ~]# echo "pppoe interface show"|nc 127.0.0.1 2001|awk '{ SUM += $2} END { print SUM }' 0 [root@acc45 ~]# ps ax|grep acc 1832 ? Zsl 3050:51 [accel-pppd] <defunct>