Перейти к содержимому
Калькуляторы

 

Коллеги, приветствую. 

 

 

Есть два сервера, accel-ppp (ipoe) оба слушают интерфейс в одном вилане. 

 

 

При назначении, ип адреса шлюзом выступает  -  gw-ip-address=172.16.0.1/16

 

gw-ip-address=172.16.0.1/16
mode=L2
shared=1
start=dhcpv4
ifcfg=0
interface=eth2
 

Не будет ли конфликта ип адресов 172.16.0.1? 

 

 

 

 

 

 

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


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

 

Коллеги, приветствую. 

 

 

Есть два сервера, accel-ppp (ipoe) оба слушают интерфейс в одном вилане. 

 

 

При назначении, ип адреса шлюзом выступает  -  gw-ip-address=172.16.0.1/16

 

gw-ip-address=172.16.0.1/16
mode=L2
shared=1
start=dhcpv4
ifcfg=0
interface=eth2
 

Не будет ли конфликта ип адресов 172.16.0.1? 

 

 

 

 

 

 

будет конечно...

 

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


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

будет конечно...

 

А как в таком случае, можно сделать балансировку? 

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


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

А как в таком случае, можно сделать балансировку? 

на втором gw-ip-address=172.16.0.2/16

 

 

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


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

Коллеги приветствую!  Использую схему local relay. 

 

Accel виснет, уже не знаю куда копать

 

Версия ядра 3.16.0-4-amd64

 

 

Версия accel-ppp

accel-ppp version be2b604a01c22780673a77675c268354dd33995e

 

[ipoe]
username=lua:username
lease-time=300
renew-time=150
max-lease-time=600
mode=L2
shared=1
start=dhcpv4
ifcfg=1
lua-file=/etc/accel-pppd.lua
idle-timeout=600
interface=bond0.1010
password=
gw-ip-address=10.0.0.1/16
verbose=1
attr-dhcp-client-ip=Framed-IP-Address
attr-dhcp-router-ip=DHCP-Router-IP-Address
attr-dhcp-mask=DHCP-Mask
attr-dhcp-opt82=DHCP-Option82
attr-dhcp-opt82-remote-id=AccelRemoteId
attr-dhcp-opt82-circuit-id=AccelCircuitId
proxy-arp=1
 

 

Вот логи при зависании. Поиск по форуму показал что надо закинуть gw-ip-address=10.0.0.1/16 в секцию radius. Но тоже ничего не дало.

 

 

 

root@ipoe-vpn:/var/log/accel-ppp# tail emerg.log
radius:BUG: rpd not found
radius:BUG: rpd not found
radius:BUG: rpd not found
radius:BUG: rpd not found
 

 

 

root@ipoe-vpn:/var/log/accel-ppp# tail debug.log

[2018-12-05 15:58:48]: warn: bond0.1010: port change detected
[2018-12-05 15:58:48]: debug: bond0.1010: terminate

 

 

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


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

@zlolotus 

Если виснет сервер - нужно лечить сервер, а не accel настраивать. Кривое ядро или с железом грабли.

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


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

@zlolotus 

Если виснет сервер - нужно лечить сервер, а не accel настраивать. Кривое ядро или с железом грабли.

 

Виснет именно Accel.  Коллеги прошу отписаться, кто использует accel в такой же схеме с local relay 

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


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

@zlolotus 

Свежая версия из git у меня раз в неделю падала без видимых причин, где-то баг.

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


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

Есть два БРАСа - "железный" (SE100) и Акцель.

SE100 работает давно, Акцель только начинаем внедрять.

 

Почему-то на запросы на получение адреса по протоколу PPPoE отвечает только Акцель.

Сложилось впечатление, что SE100 "видит" ответ Акцеля на запрос, и сам даже к Радиусу уже не обращается.

Можно ли (если да - то как), сделать так, чтобы к Радиусу для обработки PPPoE запроса обращались оба БРАСа?

 

В случае с IPoE к Радиусу обращаются оба БРАСа, и Радиус определяет, какой из БРАСов должен авторизовать клиента.

Такого же поведения хочется добиться и для PPPoE.

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


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

Есть два БРАСа - "железный" (SE100) и Акцель.

SE100 работает давно, Акцель только начинаем внедрять.

 

Почему-то на запросы на получение адреса по протоколу PPPoE отвечает только Акцель.

Сложилось впечатление, что SE100 "видит" ответ Акцеля на запрос, и сам даже к Радиусу уже не обращается.

Можно ли (если да - то как), сделать так, чтобы к Радиусу для обработки PPPoE запроса обращались оба БРАСа?

 

В случае с IPoE к Радиусу обращаются оба БРАСа, и Радиус определяет, какой из БРАСов должен авторизовать клиента.

Такого же поведения хочется добиться и для PPPoE.

Клиент сам определяет, к кому из брасов обращаться. Максимум - можно вносить задержку ответа в конфиге браса, тогда клиент, скорее всего, обратится к первому, но и это не точно и не гарантированно.

Клиент кидает широковещательный PADI (с, возможно, именем сервиса) - ему отвечают все брасы PADO (просто сигнализируя "я тут, с такими-то именами сервисов"), дальше клиент сам выбирает тот брас, что ему нравится, и уже ему кидает PADR юникастом, а тот устанавливает PPPOE-туннель и отвечает PADS. На всем этом пути нет ни логинов, ни паролей, ни состояний вплоть до padr/pads (когда уже выбран брас), так что радиусы прикручивать на этих этапах несколько проблемно будет: что именно передавать в радиус?

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


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

Клиент сам определяет, к кому из брасов обращаться. Максимум - можно вносить задержку ответа в конфиге браса, тогда клиент, скорее всего, обратится к первому, но и это не точно и не гарантированно.

Клиент кидает широковещательный PADI (с, возможно, именем сервиса) - ему отвечают все брасы PADO (просто сигнализируя "я тут, с такими-то именами сервисов"), дальше клиент сам выбирает тот брас, что ему нравится, и уже ему кидает PADR юникастом, а тот устанавливает PPPOE-туннель и отвечает PADS. На всем этом пути нет ни логинов, ни паролей, ни состояний вплоть до padr/pads (когда уже выбран брас), так что радиусы прикручивать на этих этапах несколько проблемно будет: что именно передавать в радиус?

Всё понятно, спасибо.

Слишком давно разбирался с PPPoE и успел подзабыть реализацию :(

Приношу извинения за глупый вопрос.

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


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

@zlolotus 

Свежая версия из git у меня раз в неделю падала без видимых причин, где-то баг.

 

Разобрался, баг с двойным одновременным discovery. Причем один с options 82, а другой без. 

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


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

Господа, разобрался может кто, почему не всегда отвечает ACCEL на запросы PPTP Echo-Request ?

CPU свободен.

Версии сервера - разные, вплоть до 2910ad - поведение одинаковое.

 

03:43:04.043921 172.21.193.202 -> 172.21.193.254 PPTP 82 Echo-Request

03:43:19.036271 172.21.193.254 -> 172.21.193.202 PPTP 82 Echo-Request
03:43:19.041800 172.21.193.202 -> 172.21.193.254 PPTP 86 Echo-Reply
03:43:34.036303 172.21.193.254 -> 172.21.193.202 PPTP 82 Echo-Request
03:43:34.040040 172.21.193.202 -> 172.21.193.254 PPTP 86 Echo-Reply
03:43:49.036304 172.21.193.254 -> 172.21.193.202 PPTP 82 Echo-Request

03:43:49.040573 172.21.193.202 -> 172.21.193.254 PPTP 86 Echo-Reply

03:43:49.040764 172.21.193.254 -> 172.21.193.202 PPTP 86 Echo-Reply

03:44:04.040892 172.21.193.254 -> 172.21.193.202 PPTP 82 Echo-Request
03:44:04.044922 172.21.193.202 -> 172.21.193.254 PPTP 86 Echo-Reply
03:44:19.040868 172.21.193.254 -> 172.21.193.202 PPTP 82 Echo-Request
03:44:19.044075 172.21.193.202 -> 172.21.193.254 PPTP 86 Echo-Reply
03:44:34.040840 172.21.193.254 -> 172.21.193.202 PPTP 82 Echo-Request
03:44:34.049346 172.21.193.202 -> 172.21.193.254 PPTP 86 Echo-Reply
03:44:49.040932 172.21.193.254 -> 172.21.193.202 PPTP 82 Echo-Request

03:44:49.045539 172.21.193.202 -> 172.21.193.254 PPTP 82 Echo-Request

03:44:49.045622 172.21.193.202 -> 172.21.193.254 PPTP 86 Echo-Reply
03:45:04.040835 172.21.193.254 -> 172.21.193.202 PPTP 82 Echo-Request
03:45:04.043475 172.21.193.202 -> 172.21.193.254 PPTP 86 Echo-Reply
03:45:19.040911 172.21.193.254 -> 172.21.193.202 PPTP 82 Echo-Request
03:45:19.045183 172.21.193.202 -> 172.21.193.254 PPTP 86 Echo-Reply
03:45:34.040861 172.21.193.254 -> 172.21.193.202 PPTP 82 Echo-Request
03:45:34.056718 172.21.193.202 -> 172.21.193.254 PPTP 86 Echo-Reply
03:45:49.040836 172.21.193.254 -> 172.21.193.202 PPTP 82 Echo-Request
03:45:49.067624 172.21.193.202 -> 172.21.193.254 PPTP 86 Echo-Reply

Reconnect

03:45:49.067648 172.21.193.202 -> 172.21.193.254 PPTP 222 Start-Control-Connection-Request
03:46:03.072847 172.21.193.202 -> 172.21.193.254 PPTP 222 Start-Control-Connection-Request
03:46:03.073177 172.21.193.254 -> 172.21.193.202 PPTP 222 Start-Control-Connection-Reply
 

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

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


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

на днях перепилил веб-морду от nuclearcat с пхп на питон (в первую очередь - чтобы не воевать с кросс-компиляцией пыхи под uClibc, ну и упростить добавление плюшек).

 

в связи с чем возник собссно вопрос: accel-cmd - это получается полный аналог echo | nc ? или у него еще какие-то доп.фичи есть?

 

да, линк на проект https://github.com/nitr0man/accel-webgui (как минимум - при запуске в дебаг режиме через app.py оно работает, wsgi пока не крутил).

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


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

Приветствую, коллеги.

Сабж используется как pptp/l2tp сервер в маленькой организации, никаких продвинутых фич не используется, только совместимость с pppd.

Через некоторое время работы (недели), перестает форвардить траффик клиенту, при этом от клиента траффик приходит.

В логе при старте сессии такое:

[2019-01-22 17:58:30]:  info: l2tp: new tunnel 31899-24250 created following reception of SCCRQ from 91.x.x.x:35642
[2019-01-22 17:58:30]:  info: l2tp tunnel 31899-24250 (91.x.x.x:35642): established at 185.y.y.y:1701
[2019-01-22 17:58:30]:  info: l2tp tunnel 31899-24250 (91.x.x.x:35642): new session 36347-18169 created following reception of ICRQ
[2019-01-22 17:58:33]:  info: ppp0: connect: ppp0 <--> l2tp(91.x.x.x:35642 session 31899-24250, 36347-18169)
[2019-01-22 17:58:33]:  info: ppp0: lion: authentication succeeded
[2019-01-22 17:58:33]: error: ppp0: failed to set IPv4 address: Invalid argument
[2019-01-22 17:58:33]:  info: ppp0: session started over l2tp session 31899-24250, 36347-18169

Лечится простым перезапуском службы.

Конфиг:

[modules]
log_file
#log_syslog
#log_tcp
#log_pgsql

pptp
l2tp
#sstp
#pppoe
#ipoe

auth_mschap_v2
auth_mschap_v1
auth_chap_md5
#auth_pap

#radius
chap-secrets

ippool

pppd_compat

#shaper
#net-snmp
#logwtmp
#connlimit

#ipv6_nd
#ipv6_dhcp
#ipv6pool

[core]
log-error=/var/log/accel-ppp/core.log
thread-count=4

[common]
#single-session=replace
#sid-case=upper
#sid-source=seq
#max-sessions=1000

[ppp]
verbose=1
min-mtu=1280
mtu=1400
mru=1400
#accomp=deny
#pcomp=deny
#ccp=0
#check-ip=0
#mppe=require
ipv4=require
ipv6=deny
ipv6-intf-id=0:0:0:1
ipv6-peer-intf-id=0:0:0:2
ipv6-accept-peer-intf-id=1
lcp-echo-interval=20
#lcp-echo-failure=3
lcp-echo-timeout=120
unit-cache=1
#unit-preallocate=1

[auth]
#any-login=0
#noauth=0

[pptp]
verbose=1
#echo-interval=30
#ifname=pptp%d

[pppoe]
verbose=1
#ac-name=xxx
#service-name=yyy
#pado-delay=0
#pado-delay=0,100:100,200:200,-1:500
called-sid=mac
#tr101=1
#padi-limit=0
#ip-pool=pppoe
#ifname=pppoe%d
#sid-uppercase=0
#vlan-mon=eth0,10-200
#vlan-timeout=60
#vlan-name=%I.%N
#interface=eth1,padi-limit=1000
interface=eth0

[l2tp]
verbose=1
#dictionary=/usr/local/share/accel-ppp/l2tp/dictionary
#hello-interval=60
#timeout=60
#rtimeout=1
#rtimeout-cap=16
#retransmit=5
#recv-window=16
#host-name=accel-ppp
#dir300_quirk=0
#secret=
#dataseq=allow
#reorder-timeout=0
#ip-pool=l2tp
#ifname=l2tp%d

[sstp]
verbose=1
#cert-hash-proto=sha1,sha256
#cert-hash-sha1=
#cert-hash-sha256=
#accept=ssl,proxy
#ssl-dhparam=/etc/ssl/dhparam.pem
#ssl-ecdh-curve=prime256v1
#ssl-ciphers=DEFAULT
#ssl-prefer-server-ciphers=0
#ssl-ca-file=/etc/ssl/sstp-ca.crt
#ssl-pemfile=/etc/ssl/sstp-cert.pem
#ssl-keyfile=/etc/ssl/sstp-key.pem
#host-name=domain.tld
#http-error=allow
#timeout=60
#hello-interval=60
#ip-pool=sstp
#ifname=sstp%d

[ipoe]
verbose=1
username=ifname
#password=username
lease-time=600
renew-time=300
max-lease-time=3600
#unit-cache=1000
#l4-redirect-table=4
#l4-redirect-ipset=l4
#l4-redirect-on-reject=300
#l4-redirect-ip-pool=pool1
shared=0
ifcfg=1
mode=L2
start=dhcpv4
#start=UP
#ip-unnumbered=1
#proxy-arp=0
#nat=0
#proto=100
#relay=10.10.10.10
#vendor=Custom
#weight=0
#attr-dhcp-client-ip=DHCP-Client-IP-Address
#attr-dhcp-router-ip=DHCP-Router-IP-Address
#attr-dhcp-mask=DHCP-Mask
#attr-dhcp-lease-time=DHCP-Lease-Time
#attr-dhcp-opt82=DHCP-Option82
#attr-dhcp-opt82-remote-id=DHCP-Agent-Remote-Id
#attr-dhcp-opt82-circuit-id=DHCP-Agent-Circuit-Id
#attr-l4-redirect=L4-Redirect
#attr-l4-redirect-table=4
#attr-l4-redirect-ipset=l4-redirect
#lua-file=/etc/accel-ppp.lua
#offer-delay=0,100:100,200:200,-1:1000
#vlan-mon=eth0,10-200
#vlan-timeout=60
#vlan-name=%I.%N
#ip-pool=ipoe
#idle-timeout=0
#session-timeout=0
#soft-terminate=0
#check-mac-change=1
#calling-sid=mac
#local-net=192.168.0.0/16
interface=eth0


[dns]
dns1=10.10.1.1
#dns2=172.16.1.1

[wins]
#wins1=172.16.0.1
#wins2=172.16.1.1

[radius]
#dictionary=/usr/local/share/accel-ppp/radius/dictionary
nas-identifier=accel-ppp
nas-ip-address=127.0.0.1
gw-ip-address=10.10.2.1
server=127.0.0.1,testing123,auth-port=1812,acct-port=1813,req-limit=50,fail-timeout=0,max-fail=10,weight=1
dae-server=127.0.0.1:3799,testing123
verbose=1
#timeout=3
#max-try=3
#acct-timeout=120
#acct-delay-time=0
#acct-on=0
#attr-tunnel-type=My-Tunnel-Type

[client-ip-range]
disable

[ip-pool]
gw-ip-address=10.10.2.1
#vendor=Cisco
#attr=Cisco-AVPair
attr=Framed-Pool
10.10.2.20-254
#192.168.1.1-255,name=pool1
#192.168.2.1-255,name=pool2
#192.168.3.1-255,name=pool3
#192.168.4.1-255,name=pool4,next=pool1
#192.168.4.0/24

[log]
log-file=/var/log/accel-ppp/accel-ppp.log
log-emerg=/var/log/accel-ppp/emerg.log
log-fail-file=/var/log/accel-ppp/auth-fail.log
#log-debug=/dev/stdout
#syslog=accel-pppd,daemon
#log-tcp=127.0.0.1:3000
copy=1
#color=1
#per-user-dir=per_user
#per-session-dir=per_session
#per-session=1
level=3

[log-pgsql]
conninfo=user=log
log-table=log

[pppd-compat]
verbose=1
#ip-pre-up=/etc/ppp/ip-pre-up
ip-up=/etc/ppp/ip-up
ip-down=/etc/ppp/ip-down
#ip-change=/etc/ppp/ip-change
radattr-prefix=/var/run/radattr
#fork-limit=16

[chap-secrets]
#gw-ip-address=192.168.100.1
#chap-secrets=/etc/ppp/chap-secrets
#encrypted=0
#username-hash=md5

[shaper]
#attr=Filter-Id
#down-burst-factor=0.1
#up-burst-factor=1.0
#latency=50
#mpu=0
#mtu=0
#r2q=10
#quantum=1500
#moderate-quantum=1
#cburst=1534
#ifb=ifb0
up-limiter=police
down-limiter=tbf
#leaf-qdisc=sfq perturb 10
#leaf-qdisc=fq_codel [limit PACKETS] [flows NUMBER] [target TIME] [interval TIME] [quantum BYTES] [[no]ecn]
#rate-multiplier=1
#fwmark=1
verbose=1

[cli]
verbose=1
telnet=127.0.0.1:2000
tcp=127.0.0.1:2001
#password=123
#sessions-columns=ifname,username,ip,ip6,ip6-dp,type,state,uptime,uptime-raw,calling-sid,called-sid,sid,comp,rx-bytes,tx-bytes,rx-bytes-raw,tx-bytes-raw,rx-pkts,tx-pkts

[snmp]
master=0
agent-name=accel-ppp

[connlimit]
limit=10/min
burst=3
timeout=60

[ipv6-pool]
#gw-ip6-address=fc00:0:1::1
fc00:0:1::/48,64
delegate=fc00:1::/36,48

[ipv6-dns]
#fc00:1::1
#fc00:1::2
#fc00:1::3
#dnssl=suffix1.local.net
#dnssl=suffix2.local.net.

[ipv6-dhcp]
verbose=1
pref-lifetime=604800
valid-lifetime=2592000
route-via-gw=1

 

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


Ссылка на сообщение
Поделиться на других сайтах
В 19.01.2019 в 06:26, NiTr0 сказал:

на днях перепилил веб-морду от nuclearcat с пхп на питон (в первую очередь - чтобы не воевать с кросс-компиляцией пыхи под uClibc, ну и упростить добавление плюшек).

 

в связи с чем возник собссно вопрос: accel-cmd - это получается полный аналог echo | nc ? или у него еще какие-то доп.фичи есть?

 

да, линк на проект https://github.com/nitr0man/accel-webgui (как минимум - при запуске в дебаг режиме через app.py оно работает, wsgi пока не крутил).

Скажите, а есть демка? 

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


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

а зачем? запускаете, ставите зависимости из requirements.txt (там их аж целых 2), запускаете app.py и смотрите... подходит - крутите уже через wsgi к веб-серверу.

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


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

Ппл, есть 4-е инсталляции accel-ppp. Работают только на pppoe, установлены сетевые карты 4-х портовые intel в бонды. Операционки ubuntu 2шт с ядром 4.4, gentoo 2шт с ядрами 4.9 и 4.14. Болезнь у всех одинаковая, работают месяца 2, потом у аццеля едет крыша,а может не едет, засыпает радиус стопами, колво коннектов начинает падать, приходится сервер перезапускать, кто нибудь сталкивался с подобным?  коннектов в среднем по 1.2К на каждом

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


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

PPPoE BRAS, accel-ppp 1.10.3, kernel 3.10.108

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

Скрытый текст

[root@nas10 /]# accel-cmd show stat
uptime: 17.11:47:18
cpu: 0%
mem(rss/virt): 32044/415772 kB
core:
  mempool_allocated: 17656456
  mempool_available: 220788
  thread_count: 4
  thread_active: 1
  context_count: 1808
  context_sleeping: 0
  context_pending: 0
  md_handler_count: 3553
  md_handler_pending: 0
  timer_count: 3545
  timer_pending: 0
sessions:
  starting: 1
  active: 1774
  finishing: 0
pppoe:
  starting: 0
  active: 1775
  delayed PADO: 0
  recv PADI: 1030584
  drop PADI: 0
  sent PADO: 1030584
  recv PADR(dup): 402640(536)
  sent PADS: 390787
  filtered: 0
radius(1, 10.200.0.4):
  state: active
  fail count: 0
  request count: 0
  queue length: 0
  auth sent: 580405
  auth lost(total/5m/1m): 194165/0/0
  auth avg query time(5m/1m): 2401/2400 ms
  acct sent: 90464
  acct lost(total/5m/1m): 5/0/0
  acct avg query time(5m/1m): 5/0 ms
  interim sent: 7995076
  interim lost(total/5m/1m): 428/0/0
  interim avg query time(5m/1m): 8/7 ms
[root@nas10 /]#

В конфиге в разделе radius добавлен тюнинг таймаутов, без него терялись авторизации и апдейты..

Скрытый текст

[radius]
acct-interim-interval=300
server=xx.x.xx.xx,pass,auth-port=1812,acct-port=1813,req-limit=200,fail-time=0
dae-server=xx.x.xx.xx,pass

verbose=1
timeout=30
max-try=5
 

Как избавиться от висяков? Стоящие параллельное PPPoE сервера на rp-pppoe таким не страдают в принципе, висяк может возникнуть раз в пару месяцев при проблемах с физикой или радиусом, но не стабильно и постоянно.

 

P.S. до установки этого сервера работало 2 сервера на rp-pppoe, до 4к сессий на каждом(при падении соседа, они иногда ребутились). Добавили сервер с accel-ppp,  сейчас на нем 2к, на старых до 1.5к - делаю вывод что проблема не в радиусе а именно в аццеле. Есть ли какой-то волшебный тюнинг?

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


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

@s.lobanov 

Скрытый текст

[ppp]
verbose=1
min-mtu=1280
mtu=1472
mru=1472
#accomp=deny
#pcomp=deny
#ccp=0
#check-ip=0
#mppe=require
ipv4=require
ipv6=deny
ipv6-intf-id=0:0:0:1
ipv6-peer-intf-id=0:0:0:2
ipv6-accept-peer-intf-id=1
lcp-echo-interval=20
lcp-echo-failure=3
##lcp-echo-timeout=120
unit-cache=500
#unit-preallocate=1
 

[pppoe]
verbose=0
#ac-name=xxx
#service-name=yyy
#pado-delay=0
#pado-delay=0,100:100,200:200,-1:500
called-sid=mac
#tr101=1
#padi-limit=0
#ip-pool=pppoe
#sid-uppercase=0
#vlan-mon=eth0,10-200
#vlan-timeout=60
#vlan-name=%I.%N
#interface=eth1,padi-limit=1000,net=accel-dp

interface=bond1.110

interface=bond1.96
interface=bond1.99
... и т.д.

Висяки возникают в момент частого включения/отключения клиента, в основном кривые вифи клиенты в момент проблем с эфиром/БС/

По логам раз 10 клиент поднял/опустил сессию на разных NAS и осталась в итоге висеть на сервере с accel.

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


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

@s.lobanov 

Прописаны в разделе ppp, все ок.

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

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


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

Где-то проскакивало

 

Цитата

Как-то @nuclearcatlb писал, про похожую ситуацию, когда абонент выключает свой роутер, но в том же влане есть "глючный китайский" роутер который отвечает на все lcp-echo пакеты, и accel думает что наш абон еще "живой" и не тушит сессию. Самому такое еше не попадалось. У вас сколько клиентов в этом влане, где сессия висела?   
Я вот думаю а можно же как-то послать в ручную lcp-echo пакет с заведомо левым id  на  unkown-mac, чтобы он как броадкаст разошелся по всей сети,  и нормальные роутеры  такой пакет проигнорируют, а "глючный китайский" должен ответить.

 

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

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


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

@s.lobanov 

Прописаны в разделе ppp, все ок.

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

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

 

радиус-дамп делали? acct-пакеты шлёт accel-pppd?

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


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

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

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

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

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

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

Войти

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

Войти сейчас