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

 

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

 

 

Есть два сервера, 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.

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


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

@kayot куда у вас настройки lcp-echo пропали?

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


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

@s.lobanov 

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

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

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


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

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

 

Цитата

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

 

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

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


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

2 часа назад, kayot сказал:

@s.lobanov 

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

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

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

 

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

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


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

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.