[taf_321]

16 часов назад, kayot сказал:

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

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

[NiTr0]

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 отключить в модулях?... комментирование - по идее дефолтные же скрипты будет пытаться вызывать

[taf_321]

29 минут назад, NiTr0 сказал:

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

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

[kayot]

55 минут назад, s.lobanov сказал:

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

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

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

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

@taf_321 

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

[NiTr0]

26 минут назад, kayot сказал:

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

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

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

[s.lobanov]

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

 

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

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

[kayot]

@s.lobanov 

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

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

[s.lobanov]

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

 

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

 

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

 

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

[kayot]

@s.lobanov 

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

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

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

[ichthyandr]

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

[s.lobanov]

@kayot 

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

 

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

[kayot]

 

В 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

 

[NiTr0]

заметил какую-то интересную загогулину в акселе из транка. логином служит мак-адрес, но случаются 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. почему нет радиус-запроса при этом

 

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

[NiTr0]

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

 

[ipoe]
verbose=1
username=lua:mac

--Make login from abonent MAC
function mac(pkt)
  return pkt:hdr('chaddr')
end

 

[Dimka88]

В 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, так вроде и не кривизна ядра.

[Dimka88]

В 09.02.2019 в 19:32, Dimka88 сказал:

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

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

 

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

[EShirokiy]

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

[AlKov]

9 часов назад, EShirokiy сказал:

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

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

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

[EShirokiy]

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

[AlKov]

9 минут назад, EShirokiy сказал:

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

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

[EShirokiy]

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

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

[nik247]

59 minutes ago, AlKov said:

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

Именно так.

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

[AlKov]

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

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

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

 

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

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

[ichthyandr]

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

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

Изменено 15 марта, 2019 пользователем ichthyandr

[agent2011]

Приветствую всех.

 

Столкнулся с такой проблемой:

 

не могу отдать больше 300 мегабит по PPPoE сессии по входящему трафику, по исходящему дотягиваю и до 700 мегабит.

 

Если сделать NAT используя стандартные ipset или iptables - можно выжать скорость до максимума.

 

Процессор E5645, 12 ядер.

Прерывания раскиданы таким образом

 

/root/arch/set_irq_affinity 0-5 eth0
/root/arch/set_irq_affinity 6-11 eth1

 

Карточка Intel X520-DA2

 

В момент загрузки этих 300 мегабит на сессии в htop вижу что 1 и 7 ядро нагружаются на 50 %.

 

Конфиг accel-ppp.

 

[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=12

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

[ppp]
verbose=1
min-mtu=1436
mtu=1492
mru=1492
#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=30
#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=bras1
#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=eth1
interface=vlan2
interface=vlan3
interface=vlan4
interface=vlan5
interface=vlan6
interface=vlan7
interface=vlan8
interface=vlan9
interface=vlan10
interface=vlan11
interface=vlan12
interface=vlan13
interface=vlan14
interface=vlan15
interface=vlan16
interface=vlan17
interface=vlan18
interface=vlan19
interface=vlan20
interface=vlan21
interface=vlan22
interface=vlan23
interface=vlan24
interface=vlan25
interface=vlan26
interface=vlan27
interface=vlan28
interface=vlan29
interface=vlan30
interface=vlan31
interface=vlan32
interface=vlan33
interface=vlan34
interface=vlan35
interface=vlan36
interface=vlan37
interface=vlan38
interface=vlan39
interface=vlan40
interface=vlan41
interface=vlan42
interface=vlan43
interface=vlan44
interface=vlan45
interface=vlan46
interface=vlan47
interface=vlan48
interface=vlan49
interface=vlan50
#interface=re:vlan\.[1-4000]
#interface=re:^vlan\.[0-9][0-9][0-9]$

[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=77.88.8.8
dns2=8.8.4.4

[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=192.168.100.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]
10.10.0.0/16

[ip-pool]
#gw-ip-address=192.168.0.1
#vendor=Cisco
#attr=Cisco-AVPair
#attr=Framed-Pool
#192.168.0.22-255
#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=10.10.254.254
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