xeb Опубликовано 6 ноября, 2014 · Жалоба accel конечно тоже не правильно себя ведёт, по спецификации 255.255.255.255 - значит разрешить клиенту выбрать ип адрес ну исправь в исходнике 0xfffffffe на 0xffffffff Установил. Запускать так? /usr/local/sbin/accel-pppd -d -p /var/run/accel-pppd.pid -c /etc/accel-ppp.conf -d --dump /var/log/accel-ppp так Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 6 ноября, 2014 · Жалоба Abram, req-limit есть на радиус ? Нет. С req-limit в таких же условиях 1.8.0 крашится, без него - зависает. У меня >2k онлайн, падения/поднятия целых районов естественно бывают иногда. Никто не падает. Да и при 1.5к сессий недавно запускал, нормально за 30 секунд поднялись все. Стоит req-limit=200,fail-time=0 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Abram Опубликовано 6 ноября, 2014 · Жалоба kayot, А покажи show stat. Интересно, как у тебя отвечает RADIUS, потому что у меня не успевает. А так как у меня rlm_python - подозреваю, что я попадаю в GIL. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xeb Опубликовано 6 ноября, 2014 · Жалоба запускай несколько радиусов на разных портах Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 6 ноября, 2014 · Жалоба Abram [root@ipoe1 ~]# accel-cmd show stat uptime: 15.00:39:42 cpu: 0% mem(rss/virt): 74340/1937824 kB core: mempool_allocated: 30335543 mempool_available: 1275239 thread_count: 6 thread_active: 1 context_count: 6662 context_sleeping: 0 context_pending: 0 md_handler_count: 11725 md_handler_pending: 0 timer_count: 3181 timer_pending: 0 sessions: starting: 0 active: 1591 finishing: 0 ipoe: starting: 0 active: 1591 delayed: 0 radius(1, 127.0.0.1): request count: 0 queue length: 0 auth sent: 89015 auth lost(total/5m/1m): 1/0/0 auth avg query time(5m/1m): 0/0 ms acct sent: 126908 acct lost(total/5m/1m): 3/0/0 acct avg query time(5m/1m): 40/38 ms interim sent: 6880647 interim lost(total/5m/1m): 243/0/0 interim avg query time(5m/1m): 44/49 ms Пока не подобрал нормальный req-limit тоже радиус загибался и начиналась ерунда, сейчас вроде все красиво. Давно интересовал вопрос, а зачем в show stat показывается cpu usage? top: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 27726 root 20 0 1892m 72m 1948 S 24.4 1.2 7408:06 accel-pppd stat: cpu: 0% Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xeb Опубликовано 6 ноября, 2014 · Жалоба cpu нормально показывает если через телнет смотреть Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Abram Опубликовано 6 ноября, 2014 · Жалоба запускай несколько радиусов на разных портах Гениально. Спасибо, если что - буду иметь в виду. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Abram Опубликовано 6 ноября, 2014 · Жалоба Докладываю. Под нагрузкой два тазика с accel-ppp (req-limit=0) положили RADIUS, после чего один из них (к сожалению, не помню версию) с грохотом упал. Оба были быстро заменены на свежие версии из git (последний коммит, где вылечен segfault в ipoe), установлено req-limit=16 и отосланы в ребут. Оба медленно, но уверенно поднялись из ребута и за несколько минут без паники подняли по свои 600-700 сессий каждый. Эксперимент на живых людях прошел успешно :). Очередь запросов в show stat доходила местами до 200, но всё рассосалось. В принципе, смотря на нагрузку CPU можно сказать, что можно было req-limit сделать и побольше. C req-limit=0 accel в определённый момент заваливает RADIUS, а дальше по наклонной - не получает ответы на acct -> обрывает сессии -> новые подключения -> лавина растет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
_longhorn_ Опубликовано 6 ноября, 2014 · Жалоба Добрый вечер всем! Понемногу переводим абонентов на IPoE. В сети на используем Edge-Core и D-Link. С Edge-Core проблем не возникло, поменял remote-id с дефолтного mac на ip и все хорошо. У D-Link оказалось сложнее. Попробовал изменить remote-id на user-defined и там писать ip но так и не осилил, как на lua разобрать remote-id из opt82 и вытянуть оттуда ip адрес. Может кто-нибудь уже делал нечто подобное для себя? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 6 ноября, 2014 (изменено) · Жалоба Abram Вспомнил. Так и есть, при проблемах с радиусом(при падении оного например, из-за отсутствия req-limit, или просто так) через несколько минут accel падает. Когда-то криво настроенный logrotate уронил радиус в момент hup'a, accel вскоре тоже лег. Для 1.8.0 это грустный факт, другие не пробовал. Изменено 6 ноября, 2014 пользователем kayot Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dimka88 Опубликовано 7 ноября, 2014 · Жалоба Вспомнил. Так и есть, при проблемах с радиусом(при падении оного например, из-за отсутствия req-limit, или просто так) через несколько минут accel падает. На стенде новая версия из git отработала замечательно. Даже при падении радиуса - accel-ppp не падает. Когда-то криво настроенный logrotate уронил радиус в момент hup'a, accel вскоре тоже лег. Тоже такое наблюдал, только logrotate настраивал по wiki. Надо бы еще раз проверить на стенде. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xeb Опубликовано 7 ноября, 2014 · Жалоба как на lua разобрать remote-id из opt82 и вытянуть оттуда ip адрес. покажи как оно приходит на accel Вспомнил. Так и есть, при проблемах с радиусом(при падении оного например, из-за отсутствия req-limit, или просто так) через несколько минут accel падает.Когда-то криво настроенный logrotate уронил радиус в момент hup'a, accel вскоре тоже лег. Для 1.8.0 это грустный факт, другие не пробовал. для 1.8 можно выпустить исправление чтобы не падал, но при старте под нагрузкой всё равно будут залипания, в связи с недостатком заложенной архитектуры Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mr.Scamp Опубликовано 7 ноября, 2014 · Жалоба Перезапустил два браса на последней ревизии и с reqlimit=16. Один поднялся под нагрузкой, другой - нет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
_longhorn_ Опубликовано 7 ноября, 2014 (изменено) · Жалоба покажи как оно приходит на accel Вот что настроено на свиче DES-3200-26: Command: show dhcp_local_relay DHCP/BOOTP Local Relay Status : Enabled DHCP/BOOTP Local Relay VID List : 40,54,264,2001-2002 DHCP Relay Agent Information Option 82 Circuit ID : Default DHCP Relay Agent Information Option 82 Remote ID : User Define ( 10.192.26.51 ) Клиент включен в 3-й порт, на accel в username формируется через lua: function username(pkt) v,b1,b2,b3,b4=string.unpack(pkt:agent_remote_id():sub(-4),'bbbb') ip=b1..'.'..b2..'.'..b3..'.'..b4 v,port=string.unpack(string.sub(pkt:agent_circuit_id(),'-1'),'b') local username=ip..'-'..port -- print(username) return username end Вот что в логе accel при попытке авторизации: [2014-11-07 09:51:27]: info: ipoe10: send [RADIUS(1) Access-Request id=1 <User-Name "54.46.53.49-3"> <NAS-Identifier "accel-ppp"> <NAS-IP-Address 172.16.18.1> <NAS-Port 18154> <NAS-Port-Type Ethernet> <Calling-Station-Id "64:66:b3:12:0f:9b"> <Called-Station-Id "eth0.2002"> <User-Password >] Если слушать tshark на accel то прилетает вот такое: Option: (82) Agent Information Option Length: 24 Option 82 Suboption: (1) Agent Circuit ID Length: 6 Agent Circuit ID: 000407d20003 Option 82 Suboption: (2) Agent Remote ID Length: 14 Agent Remote ID: 010c31302e3139322e32362e3531 Option: (255) End Option End: 255 Padding Remote-id свича в hex 31302e3139322e32362e3531. Изменено 7 ноября, 2014 пользователем _longhorn_ Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xeb Опубликовано 7 ноября, 2014 · Жалоба function username(pkt) ip=pkt:agent_remote_id():sub(3) v,port=string.unpack(string.sub(pkt:agent_circuit_id(),'-1'),'b') local username=ip..'-'..port -- print(username) return username end Перезапустил два браса на последней ревизии и с reqlimit=16.Один поднялся под нагрузкой, другой - нет. не поднялся в каком смысле ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mr.Scamp Опубликовано 7 ноября, 2014 · Жалоба Перезапустил два браса на последней ревизии и с reqlimit=16.Один поднялся под нагрузкой, другой - нет. не поднялся в каком смысле ? Завис сразу же после старта, каждый из тредов дал 100% на CPU. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xeb Опубликовано 7 ноября, 2014 · Жалоба можешь собрать с дебагом и в момент зависания подключиться к нему через gdb и выполнить: info threads thread apply all bt full чтобы подключиться: gdb -p пид_процесса Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mr.Scamp Опубликовано 7 ноября, 2014 (изменено) · Жалоба Собрал с -DCMAKE_BUILD_TYPE=Debug, при оказии рестартану. Изменено 7 ноября, 2014 пользователем mr.Scamp Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Abram Опубликовано 7 ноября, 2014 · Жалоба Я вот кстати думал - в качестве медленной остановки можно в iptables запретить dhcp-пакеты. Тогда, по идее, клиенты при следующем обновлении лизы не смогут её продлить и мягко (без ожидания) переподключатся на другой сервер. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Abram Опубликовано 7 ноября, 2014 · Жалоба О, совсем забыл. Вчера заметил в логе такое: [2014-11-06 21:41:02]: debug: vlan1205.877: radius(1): req_exit 15 [2014-11-06 21:41:02]: debug: vlan1205.877: radius(1): wakeup 0x7f1a28043e28 [2014-11-06 21:41:02]: debug: vlan1205.877: radius(1): queue 0x7f1a28036248 [2014-11-06 21:41:02]: debug: vlan1205.1099: radius(1): wakeup 0x7f1a28043e28 -1 [2014-11-06 21:41:02]: debug: vlan1205.310: radius(1): req_exit 15 [2014-11-06 21:41:02]: debug: vlan1205.310: radius(1): wakeup 0x7f1a2c07d9b8 [2014-11-06 21:41:02]: debug: vlan1205.310: radius(1): queue 0x7f1a2c069498 [2014-11-06 21:41:02]: debug: vlan1204.2384: radius(1): wakeup 0x7f1a2c07d9b8 -1 [2014-11-06 21:41:02]: debug: vlan1204.1181: radius(1): req_exit 15 [2014-11-06 21:41:02]: debug: vlan1204.1181: radius(1): wakeup 0x7f1a2c082208 [2014-11-06 21:41:02]: debug: vlan1204.1181: radius(1): queue 0x7f1a2803a368 [2014-11-06 21:41:02]: debug: vlan1204.1471: radius(1): wakeup 0x7f1a2c082208 -1 [2014-11-06 21:41:03]: debug: vlan1214.1173: radius(1): req_exit 15 [2014-11-06 21:41:03]: debug: vlan1214.1173: radius(1): wakeup 0x7f1a28045f28 [2014-11-06 21:41:03]: debug: vlan1208.387: radius(1): wakeup 0x7f1a28045f28 -1 [2014-11-06 21:41:03]: debug: vlan1205.548: radius(1): req_exit 15 [2014-11-06 21:41:03]: debug: vlan1205.548: radius(1): wakeup 0x7f1a200c12a8 [2014-11-06 21:41:03]: debug: vlan1205.548: radius(1): queue 0x7f1a2803bfa8 [2014-11-06 21:41:03]: debug: vlan1205.552: radius(1): wakeup 0x7f1a200c12a8 -1 [2014-11-06 21:41:03]: debug: vlan1205.1031: radius(1): req_exit 15 [2014-11-06 21:41:03]: debug: vlan1205.1031: radius(1): wakeup 0x7f1a3005bae8 [2014-11-06 21:41:03]: debug: vlan1204.2400: radius(1): wakeup 0x7f1a3005bae8 -1 Примерно то же одновременно произошло на двух BRAS-ах. У обеих req-limit=16, у обеих последний master. На графике онлайн биллинга это отобразилось вот так (скачок в 21:40 до 22:00): https://dl.dropboxusercontent.com/u/12495607/radius_req_exit.png Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
_longhorn_ Опубликовано 7 ноября, 2014 (изменено) · Жалоба function username(pkt) ip=pkt:agent_remote_id():sub(3) v,port=string.unpack(string.sub(pkt:agent_circuit_id(),'-1'),'b') local username=ip..'-'..port -- print(username) return usernameend Спасибо огромное, все работает! Наткнулся на новую проблему. До этого использовали accel с внешним dhcp сервером. Решил попробовать выдавать адреса radius`ом, в конфиге добавил gw-ip-address, авторизация проходит, но при этом сессия не поднимается. В логе: [2014-11-07 15:07:23]: info: ipoe10: send [RADIUS(1) Access-Request id=1 <User-Name "10.192.25.215-9"> <NAS-Identifier "accel-ppp"> <NAS-IP-Address 172.16.25.1> <NAS-Port 18854> <NAS-Port-Type Ethernet> <Calling-Station-Id "78:44:76:3f:94:3b"> <Called-Station-Id "eth0.2002"> <User-Password >] [2014-11-07 15:07:23]: info: ipoe10: recv [RADIUS(1) Access-Accept id=1 <Service-Type Framed-User> <Framed-Protocol PPP> <Framed-IP-Address 172.16.55.89> <Framed-IP-Netmask 255.255.255.255> <Session-Timeout 86400> <Acct-Interim-Interval 300>] [2014-11-07 15:07:23]: info: ipoe10: 10.192.25.215-9: authentication succeeded [2014-11-07 15:07:23]: error: ipoe10: can't determine Server-ID [2014-11-07 15:07:23]: debug: ipoe10: terminate [2014-11-07 15:07:23]: info: ipoe10: ipoe: session finished Изменено 7 ноября, 2014 пользователем _longhorn_ Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Abram Опубликовано 7 ноября, 2014 · Жалоба _longhorn_, Нужно выдавать DHCP-Client-IP-Address (он же Framed-IP-Address), DHCP-Router-IP-Address, Framed-Netmask и(/или?) DHCP-Mask. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
_longhorn_ Опубликовано 7 ноября, 2014 · Жалоба Abram А без этого никак? Разве accel не узнает шлюз и маску из опции gw-ip-adress в конфиге? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xeb Опубликовано 7 ноября, 2014 · Жалоба в конфиге добавил gw-ip-address куда добавили и что добавили ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
_longhorn_ Опубликовано 7 ноября, 2014 (изменено) · Жалоба xeb Добавлял в секцию radius. Вот что у меня сейчас: [ipoe] verbose=1 mode=L2 shared=1 start=dhcpv4 ifcfg=1 agent-remote-id=accel-ppp interface=eth0.2002 interface=eth0.3947,giaddr=172.16.37.1,relay=192.168.204.30 interface=eth0.44,giaddr=172.16.37.1,relay=192.168.204.30 interface=eth0.46,giaddr=172.16.39.2,relay=192.168.204.30 interface=eth0.47,giaddr=172.16.32.253,relay=192.168.204.30 interface=eth0.208,giaddr=172.16.37.1,relay=192.168.204.30,username=ifname lua-file=/etc/accel-ppp.lua username=lua:username password=1 proxy-arp=1 lease-time=120 max-lease-time=130 [dns] dns1=8.8.8.8 [radius] dictionary=/usr/local/share/accel-ppp/radius/dictionary nas-identifier=accel-ppp nas-ip-address=192.168.204.138 gw-ip-address=172.16.37.1/24 server=192.168.204.30,supertux,auth-port=1812,acct-port=1813,req-limit=0,fail-time=0 dae-server=192.168.204.138:3799,supertux verbose=1 acct-interim-interval=30 timeout=30 max-try=5 acct-timeout=0 #acct-on=1 Изменено 7 ноября, 2014 пользователем _longhorn_ Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...