Перейти к содержимому
Калькуляторы
16 часов назад, kayot сказал:

Проблема - постоянно появляются 'висячие' сессии, практически каждый день пара-тройка аккаунтов физически отключившихся от сервера зависают в радиусе как активные и получается 'висяк'. 

У меня что-то подобное было очень давно. Вылечил комментированием строк ip-pre-up, ip-up, ip-down, ip-change в секции [pppd-compat]. Из-за этих вызовов скриптов случались гонки состояний при массовых или частых подключений-отключений клиентов.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
2 часа назад, kayot сказал:

Pppoe  сессия в реальности убивается, но в радиусе она не заканчивается - имеем висяк.

радиус не получил acct-stop?

в том же абиллсе есть фича перемещения висячих сессий в "zap", а потом (через некоторое время) - удаление их вообще.

но - да, периодически замечал появляющиеся. на 1.10 при большом кол-ве сессий. 1.11.2 (или транк) - собрал но пока на тесте сессий на нем немного. то ли пакет до радиуса теряется где-то на сети, то ли аксель не успевает его отправить и дропает, то ли радиус не успевает переварить. но т.к. не напрягает - как-то не дебажил.

 

1 минуту назад, taf_321 сказал:

Вылечил комментированием строк ip-pre-up, ip-up, ip-down, ip-change в секции [pppd-compat].

мож тогда вообще бы ppp-compat отключить в модулях?... комментирование - по идее дефолтные же скрипты будет пытаться вызывать

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
29 минут назад, NiTr0 сказал:

мож тогда вообще бы ppp-compat отключить в модулях?... комментирование - по идее дефолтные же скрипты будет пытаться вызывать

Мне в этом модуле нужно назначать куда писать radattr.* файлы (нужны мне они очень сильно). Но для надежности модно вообще убрать куда-нибудь в сторону содержимое /etc/ppp в случае с accel-ppp оно совершенно лишнее.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
55 минут назад, s.lobanov сказал:

так погодите. у вас сессия убивается? (умирает ppp-интерфейс?)

Да, сессия умирает штатно. Но иногда при этом accel не шлет stop-пакет на радиус, получается зависшая сессия.

У нас биллинг не следит за повторными сессиями и подобными "висяками", а целиком полагается на радиус. С серверами на pppd никаких граблей нет, а вот accel теряет.

Accel шлет acct и interim, но иногда, при флапаньях сессий чего-то теряет.

@taf_321 

pppd_compat не используем, сам модуль в [modules] закоментирован. Если этого недостаточно и скрипты вызываются - значит баг..

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
26 минут назад, kayot сказал:

У нас биллинг не следит за повторными сессиями и подобными "висяками", а целиком полагается на радиус. С серверами на pppd никаких граблей нет, а вот accel теряет.

ну какбы слежение желательно. иначе краш сервера доступа/отвал сети - и сессии залипли...

мож в 1.11 что-то поправлено (лучше - из гита 1.11 ветка, там был фикс на pado-delay менее секунды)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

@kayot так а всё-таки дамп есть, в котором видно что именно accel не шлёт stop? Может быть он шлёт, а пакет теряется где-то?

 

ну и да, сессии надо дропать на радиусе, если не пришло за X секунд ни одного interrim-а. (это прям маст хэв)

ещё некоторые разрешают переавторизовать если запрос пришёл с тогоже NAS-IP-Address+login+calling-station-id

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

@s.lobanov 

Дампа нет, не представляю как поймать 1 потерянный пакет из миллиона. Виснет ведь не конкретный абонент, а любой дернувший сессию 10-20 раз подряд.

Параллельно работает 2 сервера с rp-pppoe, той же конфигурации, с тем же радиус-сервером, включенные в тот же коммутатор ядра. Ничего не теряется - делаю вывод что грабли в аццеле, пули не вылетают.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

@kayot как поймать - понятно. просто берёте и собираете непрерывно пакеты на порт 1813 (или какой у вас под acct). Потом постфактум смотрите по зависшему абоненту (wireshark может фильтровать по user-name)

 

я делал подобные дампы, проблем особых нет

 

если это баг accel-pppd, то всё равно этот дамп нужен.

 

может быть у вас от accel-pppd acct-а намного больше чем от rp-pppoe и у вас дропаются acct-ы.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

@s.lobanov 

Спасибо, пнули в нужную сторону.

NASы с pppd  у нас interim updates вообще не используют(трафик коллекторами собирается) потому и проблемы нет - обращений к радиусу с их стороны в разы меньше.

Раз волшебной крутилки у accel для этой ситуации нет и потери возможны всегда - написал простой скрипт к биллингу проверяющий раз в N минут last acct update для серверов с accel-ppp и убивающий висящую сессию.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

а у аццеля есть лог по консольке (телнету), типа откуда коннектились, какие команды делали?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

@kayot 

Так interrim updates можно порезать. Acct-Interim-Interval (либо очень большое значение отправить либо 0(0 не пробовал))

 

Другое дело что неправильно это не использвать Interim updates

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

В 14.11.2016 в 20:58, Dimka88 сказал:

Я предполагаю, что производители некоторых клиентских маршрутизаторов устанавливают значение arp_ignore в 1 и поэтому клиентские маршрутизаторы на хотят отвечать на


03:27:23.393145 ARP, Request who-has 10.0.0.50 tell 192.168.1.1, length 28

 

В 17.11.2016 в 12:35, Dimka88 сказал:

Таки дело в debian или в ядре. На gentoo с ядром 4.8.8 даже если на lo висят ip /32 выступающие GW для клиентов, модель поведения ARP ruquest следующая.


05:54:30.170618 ARP, Request who-has 10.0.0.50 tell 192.168.1.1, length 28
05:54:31.194866 ARP, Request who-has 10.0.0.50 tell 192.168.1.1, length 28
05:54:32.219066 ARP, Request who-has 10.0.0.50 tell 192.168.1.1, length 28
05:54:33.672178 ARP, Request who-has 10.0.0.50 tell 10.0.0.1, length 28
05:54:33.672745 ARP, Reply 10.0.0.50 is-at 08:00:27:98:27:b3, length 46

На днях наступили на те же грабли с новыми роутерами Tp-link 820n. Стоит у этой гадости arp_ignore=1 и не хочет роутер отвечать на ARPы от сервера.

На lo прописаны адреса шлюзов для разных блоков IP, сервер отвечает не с того интерфейса(точнее всем с одного IP висящего на lo).

Нашли решение или это врожденная кривизна ядра?

 

P.S. придумал решение, тупое но полностью рабочее. Может кому пригодится.

Ставим пакет arptables(arptables_jf в centos подобном) и в нем подменяем SRC IP для неверных ответов.

Работает.

cat /etc/sysconfig/arptables

*filter
:IN ACCEPT [0:0]
:OUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
-A OUT -d 172.20.0.0/16   -s ! 172.20.0.0/16    -j mangle --mangle-ip-s 172.20.0.2
-A OUT -d xx.xx.164.0/20 -s ! xx.xx.164.0/20  -j mangle --mangle-ip-s xx.xx.164.2
-A OUT -d yy.yy.64.0/19  -s ! yy.yy.64.0/19   -j mangle --mangle-ip-s yy.yy.64.2
COMMIT

Лог без подмены и с подменой

14:10:15.329908 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 172.20.10.37 tell XX.XX.64.1, length 28
14:10:15.330142 ARP, Ethernet (len 6), IPv4 (len 4), Reply 172.20.10.37 is-at c4:6e:1f:af:f0:97, length 46

14:09:54.059909 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 172.20.10.37 tell 172.20.0.1, length 28
14:09:54.060050 ARP, Ethernet (len 6), IPv4 (len 4), Reply 172.20.10.37 is-at c4:6e:1f:af:f0:97, length 46

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

заметил какую-то интересную загогулину в акселе из транка. логином служит мак-адрес, но случаются mac change:

Feb  7 13:43:44 firewall accel-pppd: ipoe613:30:b5:c2:xx:xx:67: recv [DHCPv4 Discover xid=65c89e80 chaddr=70:4f:57:xx:xx:d5 <Message-Type Discover> <Max-Message-Size 1024> <Client-ID 01704f57ae25d5> <Host-Name TL-WR840N> <Vendor-Class 4d53465420352e30> <Request-List Subnet,Router,DNS,Domain-Name,Vendor-Specific,44,46,47,Route,Classless-Route,249> <Relay-Agent {Agent-Circuit-ID _000400220101} {Agent-Remote-ID _00067072cf0c1e70}>]
Feb  7 13:43:44 firewall accel-pppd: ipoe613:30:b5:c2:xx:xx:67: mac change detected
Feb  7 13:43:44 firewall accel-pppd: ipoe613:30:b5:c2:xx:xx:67: terminate
Feb  7 13:43:44 firewall accel-pppd: vlan34:: recv [DHCPv4 Discover xid=65c89e80 chaddr=70:4f:57:xx:xx:d5 <Message-Type Discover> <Max-Message-Size 1024> <Client-ID 01704f57ae25d5> <Host-Name TL-WR840N> <Vendor-Class 4d53465420352e30> <Request-List Subnet,Router,DNS,Domain-Name,Vendor-Specific,44,46,47,Route,Classless-Route,249> <Relay-Agent {Agent-Circuit-ID _000400220101} {Agent-Remote-ID _00067072cf0c1e70}>]
Feb  7 13:43:44 firewall accel-pppd: ipoe392:: create interface ipoe392 parent vlan34
Feb  7 13:43:44 firewall accel-pppd: ipoe392:70:4f:57:xx:xx:d5: 70:4f:57:xx:xx:d5: authentication failed
Feb  7 13:43:44 firewall accel-pppd: ipoe392:70:4f:57:xx:xx:d5: 70:4f:57:xx:xx:d5: start temporary session (l4-redirect)
Feb  7 13:43:44 firewall accel-pppd: ipoe392:70:4f:57:xx:xx:d5: send [DHCPv4 Offer xid=65c89e80 yiaddr=172.16.192.210 chaddr=70:4f:57:xx:xx:d5 <Message-Type Offer> <Server-ID 172.16.192.1> <Lease-Time 180> <T1 90> <Router 172.16.192.1> <Subnet 255.255.240.0> <DNS 193.151.12.8,1.1.1.1>]
Feb  7 13:43:44 firewall accel-pppd: ipoe613:30:b5:c2:xx:xx:67: pppd_compat: ip-down started (pid 5098)
Feb  7 13:43:44 firewall accel-pppd: ipoe613:30:b5:c2:xx:xx:67: pppd_compat: ip-down finished (1)
Feb  7 13:43:44 firewall accel-pppd: ipoe613:30:b5:c2:xx:xx:67: ipoe: session finished
Feb  7 13:43:44 firewall accel-pppd: libnetlink: RTNETLINK answers: Cannot assign requested address


tcpdump:

13:43:40.087899 70:4f:57:xx:xx:d5 > 90:e2:ba:xx:xx:37, ethertype IPv4 (0x0800), length 353: (tos 0x0, ttl 64, id 3206, offset 0, flags [DF], proto UDP (17), length 339)
    172.16.192.207.68 > 172.16.192.1.67: BOOTP/DHCP, Request from 70:4f:57:xx:xx:d5, length 311, xid 0x51615952, Flags [none]
	  Client-IP 172.16.192.207
	  Client-Ethernet-Address 70:4f:57:xx:xx:d5
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message Option 53, length 1: Request
	    MSZ Option 57, length 2: 1024
	    Client-ID Option 61, length 7: ether 70:4f:57:xx:xx:d5
	    Hostname Option 12, length 9: "TL-WR840N"
	    Vendor-Class Option 60, length 8: "MSFT 5.0"
	    Parameter-Request Option 55, length 11: 
	      Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name
	      Vendor-Option, Netbios-Name-Server, Netbios-Node, Netbios-Scope
	      Static-Route, Classless-Static-Route, Classless-Static-Route-Microsoft
	    Agent-Information Option 82, length 18: 
	      Circuit-ID SubOption 1, length 6: ^@^D^@"^A^A
	      Remote-ID SubOption 2, length 8: ^@^FprM-O^L^^p
13:43:40.088088 90:e2:ba:xx:xx:37 > 70:4f:57:xx:xx:d5, ethertype IPv4 (0x0800), length 286: (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 272)
    0.0.0.0.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 244, xid 0x51615952, Flags [none]
	  Client-Ethernet-Address 70:4f:57:xx:xx:d5
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message Option 53, length 1: NACK
13:43:44.087683 70:4f:57:xx:xx:d5 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 353: (tos 0x0, ttl 64, id 62417, offset 0, flags [none], proto UDP (17), length 339)
    0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 70:4f:57:xx:xx:d5, length 311, xid 0x809ec865, Flags [none]
	  Client-Ethernet-Address 70:4f:57:xx:xx:d5
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message Option 53, length 1: Discover
	    MSZ Option 57, length 2: 1024
	    Client-ID Option 61, length 7: ether 70:4f:57:xx:xx:d5
	    Hostname Option 12, length 9: "TL-WR840N"
	    Vendor-Class Option 60, length 8: "MSFT 5.0"
	    Parameter-Request Option 55, length 11: 
	      Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name
	      Vendor-Option, Netbios-Name-Server, Netbios-Node, Netbios-Scope
	      Static-Route, Classless-Static-Route, Classless-Static-Route-Microsoft
	    Agent-Information Option 82, length 18: 
	      Circuit-ID SubOption 1, length 6: ^@^D^@"^A^A
	      Remote-ID SubOption 2, length 8: ^@^FprM-O^L^^p
13:43:44.088411 90:e2:ba:xx:xx:37 > 70:4f:57:xx:xx:d5, ethertype IPv4 (0x0800), length 326: (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 312)
    172.16.192.1.67 > 172.16.192.210.68: BOOTP/DHCP, Reply, length 284, xid 0x809ec865, Flags [none]
	  Your-IP 172.16.192.210
	  Client-Ethernet-Address 70:4f:57:xx:xx:d5
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message Option 53, length 1: Offer
	    Server-ID Option 54, length 4: 172.16.192.1
	    Lease-Time Option 51, length 4: 180
	    RN Option 58, length 4: 90
	    Default-Gateway Option 3, length 4: 172.16.192.1
	    Subnet-Mask Option 1, length 4: 255.255.240.0
	    Domain-Name-Server Option 6, length 8: 193.151.12.8,1.1.1.1
13:43:45.087518 70:4f:57:xx:xx:d5 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 365: (tos 0x0, ttl 64, id 64126, offset 0, flags [none], proto UDP (17), length 351)
    0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 70:4f:57:xx:xx:d5, length 323, xid 0x809ec865, Flags [none]
	  Client-Ethernet-Address 70:4f:57:xx:xx:d5
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message Option 53, length 1: Request
	    MSZ Option 57, length 2: 1024
	    Client-ID Option 61, length 7: ether 70:4f:57:xx:xx:d5
	    Hostname Option 12, length 9: "TL-WR840N"
	    Vendor-Class Option 60, length 8: "MSFT 5.0"
	    Requested-IP Option 50, length 4: 172.16.192.210
	    Server-ID Option 54, length 4: 172.16.192.1
	    Parameter-Request Option 55, length 11: 
	      Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name
	      Vendor-Option, Netbios-Name-Server, Netbios-Node, Netbios-Scope
	      Static-Route, Classless-Static-Route, Classless-Static-Route-Microsoft
	    Agent-Information Option 82, length 18: 
	      Circuit-ID SubOption 1, length 6: ^@^D^@"^A^A
	      Remote-ID SubOption 2, length 8: ^@^FprM-O^L^^p
13:43:45.090428 90:e2:ba:xx:xx:37 > 70:4f:57:xx:xx:d5, ethertype IPv4 (0x0800), length 326: (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 312)
    172.16.192.1.67 > 172.16.192.210.68: BOOTP/DHCP, Reply, length 284, xid 0x809ec865, Flags [none]
	  Your-IP 172.16.192.210
	  Client-Ethernet-Address 70:4f:57:xx:xx:d5
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message Option 53, length 1: ACK
	    Server-ID Option 54, length 4: 172.16.192.1
	    Lease-Time Option 51, length 4: 180
	    RN Option 58, length 4: 90
	    Default-Gateway Option 3, length 4: 172.16.192.1
	    Subnet-Mask Option 1, length 4: 255.255.240.0
	    Domain-Name-Server Option 6, length 8: 193.151.12.8,1.1.1.1

 

при этом - эта чехарда наблюдается у примерно 6 абонов, 5 тплинков и 1 тенда (вроде) в одном влане.

 

непонятно 2 момента:

1. каким образом случается mac change

2. почему нет радиус-запроса при этом

 

кто-то сталкивался с подобным?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

в общем при отключении опции 82 на свиче все наладилось. что весьма странно, т.к.

 

[ipoe]
verbose=1
username=lua:mac
--Make login from abonent MAC
function mac(pkt)
  return pkt:hdr('chaddr')
end

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
В 05.02.2019 в 15:11, kayot сказал:

Параллельно работает 2 сервера с rp-pppoe, той же конфигурации, с тем же радиус-сервером, включенные в тот же коммутатор ядра. Ничего не теряется - делаю вывод что грабли в аццеле, пули не вылетают.

Может кстати даже быть на старых версиях, а может и в мастере осталось, нужно проверять. Есть даже идеи как затестить.
Думаю что accel все же отсылает, но радиус не успевает обработать acct type stop и не применяется походу ([radius] max-try=n для acct), а poptop и rp-pppoe возможно повторяют, нужно проверить теорию.

@kayot, а логов не осталось с забытых сессии, интересно, улетает ли вообще от accel 

send [RADIUS(1) Accounting-Request ...<Acct-Status-Type Stop> 

 

В 07.02.2019 в 13:12, kayot сказал:

Нашли решение или это врожденная кривизна ядра?

Ага, [ipoe]ifcfg=1. Ну по факту это проявляется если gw ip вешать на lo c маской /32, так вроде и не кривизна ядра.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
В 09.02.2019 в 19:32, Dimka88 сказал:

а может и в мастере осталось, нужно проверять.

В мастер точно повторяет столько раз, сколько указано в [radius]max-try(если не задано, то 3 по умолчанию) с таймаутом [radius]timeout (по умолчанию 3, опять же если не задан). Попробую вашу версию проверить еще.

 

upd:// И на 1.10.3 отрабатывает корректно, хм. Вот бы логи выловить этих сессий на стороне accel и radius.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Отпишитесь, пожалуйста, у кого есть проблемы с windows 10 и бесконечными реквестами. Если коротко, то винда прописывает себе большой лиз тайм (несколько дне), шлет реквесты, accel на них не отвечает, т.к. сессия завершилась. Новая сессия не поднимается, т.к. нет discover.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
9 часов назад, EShirokiy сказал:

Отпишитесь, пожалуйста, у кого есть проблемы с windows 10 и бесконечными реквестами. Если коротко, то винда прописывает себе большой лиз тайм (несколько дне), шлет реквесты, accel на них не отвечает, т.к. сессия завершилась. Новая сессия не поднимается, т.к. нет discover.

Было дело.. Вот этот патч вроде как решил проблему.

Во всяком случае, пока обращений от пользователей 10-ки нет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
9 минут назад, EShirokiy сказал:

@AlKov этот патч убивает резервирование

Ээмм.. А это чтО? Второй/третий/etc.. сервер?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

@AlKov второй сервер, отсутствие балансировки можно пережить, но вот отсутствие горячего резервирования не готов)

у вас получится снять дампы с порта 67 и 68 на проблемных абонентах?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
59 minutes ago, AlKov said:

Ээмм.. А это чтО? Второй/третий/etc.. сервер?

Именно так.

Для балансировки и отказоустойчивости.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
2 часа назад, EShirokiy сказал:

у вас получится снять дампы с порта 67 и 68 на проблемных абонентах?

Такой возможности нет.

 

P.S. Конечно, отсутствие балансировки и резервирования в определённых случаях можно вполне считать некоторой "ущербностью",

но для меня например, это совершенно не критично, поэтому патч пришёлся к месту. :-)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ппл, глубоко не копал, но замечено, что при PPPoE accel при отсутствии подключения к радиусу на PADI похоже отвечает PADO и клиенты пробуют подключиться и получают облом в виде 718 ошибки на винде.

Может как фьючереквест - при отсутствии радиуса PADO не отсылать или управлять этим через конфиг? При резервировании это было бы весьма кстати. Еще момент у нас на каждом аксель сервере по своему радиусу.  

Изменено пользователем ichthyandr

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас