Jump to content
Калькуляторы

accel pptpd accel pptpd

Да, скачал через git согласно инструкции на сайте (https://accel-ppp.org/wiki/doku.php?id=ru:compilation#загрузка)

git clone git://git.code.sf.net/p/accel-ppp/code accel-ppp-code

Смущает версия:

Connected to 127.0.0.1.
Escape character is '^]'.
accel-ppp version 54f225b10ddd13ad4a7e3e5359fdbd2bf927d130

вроде с номерами последних коммитов не совпадает..

 

Или все-таки отсюда тянуть - https://github.com/xebd/accel-ppp.git ?

Edited by bos9

Share this post


Link to post
Share on other sites

Что-то лыжи не едут...

[shaper]
up-limiter=police
down-limiter=tbf
verbose=1
 ifname | username |   calling-sid   |       ip        | rate-limit | type | comp | state  |  uptime  
--------+----------+-----------------+-----------------+------------+------+------+--------+----------
 ppp0   | test     | 192.168.192.192 | 192.168.236.135 | 1024/1024  | pptp |      | active | 01:26:28
# tc qdisc show
qdisc pfifo_fast 0: dev eth0 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc tbf 1: dev ppp0 root refcnt 2 rate 1024Kbit burst 12800b lat 50.0ms 
qdisc ingress ffff: dev ppp0 parent ffff:fff1 ---------------- 

# tc filter show

Вижу создалась ingress очередь для интерфейса ppp0, а где фильтр с полисером то?

Share this post


Link to post
Share on other sites
Только что, taf_321 сказал:

tc filter show dev ppp0

пусто! забыл уточнить - скорость указывал пятой колонкой в chap-secrets

Share this post


Link to post
Share on other sites

Но скорость то режется и входящая и исходящая. Просветите, как реализован полисер исходящего трафика без фильтра? 

Share this post


Link to post
Share on other sites

Интерфейс привязан к конкретному клиенту, дисциплина с параметрами выделенной скорости на интерфейс назначена. В этом случае наличие фильтра не нужно.

Share this post


Link to post
Share on other sites
26 минут назад, taf_321 сказал:

Интерфейс привязан к конкретному клиенту, дисциплина с параметрами выделенной скорости на интерфейс назначена. В этом случае наличие фильтра не нужно.

Параметры скорости указаны для дисциплины обрабатывающей исходящий с интерфейса трафик:

qdisc tbf 1: dev ppp0 root refcnt 2 rate 1024Kbit burst 12800b lat 50.0ms

Для входящего на интерфейс трафика определена дисциплина:

qdisc ingress ffff: dev ppp0 parent ffff:fff1 ---------------- 

Обычно, чтобы полисить трафик на такой дисциплине используют примерно такой фильтр:

tc filter add dev ppp0 parent ffff: protocol ip prio 50 u32 match ip src 0.0.0.0/0 police rate 1024kbit burst 10k drop flowid :1

Но в данном случае его нет. 

Share this post


Link to post
Share on other sites

Нашел.

# tc filter show dev ppp0 parent ffff:
filter protocol all pref 100 u32 
filter protocol all pref 100 u32 fh 800: ht divisor 1 
filter protocol all pref 100 u32 fh 800::1 order 1 key ht 800 bkt 0 flowid :1 
  match 00000000/00000000 at 0
        action order 1:  police 0xc rate 5000Kbit burst 625000b mtu 2Kb action drop overhead 0b 
ref 1 bind 1

По 'tc filter show dev ppp0' почему-то ничего не показывает.

Share this post


Link to post
Share on other sites
On 3/24/2017 at 1:59 PM, NiTr0 said:

это нормально? PADO-delay устанавливал в терминале

 


13:53:21.721771 PPPoE PADI [service-Name] [Host-Uniq 0x030000000000000005000000]
13:53:21.722036 PPPoE PADO [AC-Name "хххх"] [service-Name] [AC-Cookie 0xDC8472DE9F2A43268209BFD2FB92A98EE2309322352F21C6] [Host-Uniq 0x030000000000000005000000]

accel-ppp version 1.10.0
accel-ppp# pppoe show PADO-delay
200
 

 

 

задержка кратно 1000 только.

 

какая-то грабля акселя, или особенности uclibc?

Удалось победить PADO-delay?

Самому вот понадобилось и обнаружил, что любые установки до 1000 не влияют никак.

При установке 1000 получаю задержку 1 секунду.

Версия 1.11 (последняя с гита)

Пробовал на разных серверах - тоже самое.

Тема на профильном форуме здесь - http://accel-ppp.org/forum/viewtopic.php?f=18&t=1052

 

03.03.2018 - xeb fixed pado-delay commit 6e7c20d8b1eaca421793cc3876c84a0ab718282e

Edited by nik247

Share this post


Link to post
Share on other sites

Подзабыл теорию tc.. Подскажите, правильно ли я понимаю, что параметр fwmark модуля shaper позволяет пустить промаркированный трафик мимо шейпера только в случае использования htb, но не будет работать с tbf?

Share this post


Link to post
Share on other sites

Добрый день!

имеется сборка accel-pppd, zebra + ospf для динамической маршрутизации, таких серверов несколько.

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

на новой сборке (gentoo kerne 4.9.76 или centos 7 kernel 3.6 или centos 7 kernel 4.10) при быстром подключении и отключении, рассылается добавление маршрута, но удаление не отправляется по ospf

из-за чего радиус думает что клиент уже подключён, хотя на самом деле коннекта нет, лечится перезапуском ospf или через час по таймауту маршрут  удаляется.

может кто-нибудь сталкивался с данной проблемой?

Share this post


Link to post
Share on other sites

да.

5 часов назад, xlr сказал:

кто-нибудь сталкивался с данной проблемой?

 похоронить кваггу. использовать bird

Share this post


Link to post
Share on other sites
On 26.03.2018 at 2:29 PM, GrandPr1de said:

да.

 похоронить кваггу. использовать bird

спасибо! работает!

Share this post


Link to post
Share on other sites

Попробовали ipoe с ipv6 при start=dhcp, shared=1.

Работает, хосты получают IPv6-адрес с маской /128, префиксы делегируются.

 

К сожалению, в логах много ошибок вида

[2018-04-04 13:00:52]: error: ipoe99: dhcpv6: unmatched Client-ID option
[2018-04-04 13:00:52]: error: ipoe345: dhcpv6: unmatched Client-ID option
[2018-04-04 13:00:53]: error: ipoe125: dhcpv6: unmatched Client-ID option
[2018-04-04 13:00:53]: error: ipoe65: dhcpv6: unmatched Client-ID option

 

Share this post


Link to post
Share on other sites
2 hours ago, mr.Scamp said:

Попробовали ipoe с ipv6 при start=dhcp, shared=1.

Работает, хосты получают IPv6-адрес с маской /128, префиксы делегируются.

 

К сожалению, в логах много ошибок вида


[2018-04-04 13:00:52]: error: ipoe99: dhcpv6: unmatched Client-ID option
[2018-04-04 13:00:52]: error: ipoe345: dhcpv6: unmatched Client-ID option
[2018-04-04 13:00:53]: error: ipoe125: dhcpv6: unmatched Client-ID option
[2018-04-04 13:00:53]: error: ipoe65: dhcpv6: unmatched Client-ID option

 

У нас такая-же беда. Писал по этому поводу - никто не ответил.

Share this post


Link to post
Share on other sites
On 4/4/2018 at 3:01 PM, mr.Scamp said:

Попробовали ipoe с ipv6 при start=dhcp, shared=1.

Работает, хосты получают IPv6-адрес с маской /128, префиксы делегируются.

 

К сожалению, в логах много ошибок вида


[2018-04-04 13:00:52]: error: ipoe99: dhcpv6: unmatched Client-ID option
[2018-04-04 13:00:52]: error: ipoe345: dhcpv6: unmatched Client-ID option
[2018-04-04 13:00:53]: error: ipoe125: dhcpv6: unmatched Client-ID option
[2018-04-04 13:00:53]: error: ipoe65: dhcpv6: unmatched Client-ID option

 

из дампа в telegram видно, что это были роутеры tp-link, у которых ClientID (DUID LLT) меняется с каждым запросом.
первый Client ID запоминается, а дальше следующие запросы выглядят для сервера в той-же сессии другими клиентами, на что получают отлуп.

Share this post


Link to post
Share on other sites

Коллеги, подскажите как ведет себя debian 8, на accel-ppp(pppoe).

 

Есть какие-то подводные камни? 

 

Share this post


Link to post
Share on other sites
17 минут назад, Kolunchik сказал:

Хорошо ведёт, но лучше брать ядро 4.х

 

Почему? 

Share this post


Link to post
Share on other sites

По личному опыту и по опыту коллег по каналу в запрещённом мессенджере.

Там в ядре много изменилось, причём в лучшую сторону.

Share this post


Link to post
Share on other sites

Переводим клиентов с PPPoE(Dual Access) на IPoE.

Во время непосредственного "переключения" на bras иногда (совершенно непредсказуемо) вылезает очень серъёзная проблема - тупо падают все QinQ интерфейсы, включая "родителя".

В логах браса и собственно accel на момент падения совершенно ничего, что могло быть пролить свет на причину проблемы.

Т.е. заходим на bras и в ifconfig видим полное отсутствие eth0 ("родитель")..

 

Я может чего то упустил, что говорит syslog и dmesg  по поводу падения eth0?

Как часто это происходит?

Все тупо молчат, как партизаны. Матерятся только сервисы, которые мониторят интерфейсы (ntpd, snmpd).

Происходит сиё только в некоторый момент при переводе сегмента сети с PPPoE на IPoE, причём совершенно непредсказуемо. Иногда всё проходит без проблем.

Подозрения на свою собственную косолапость. Дело в том, что в одном L2, в одном и том же vlan у меня поднято два сервера с accel.

Один собственно "рабочий" (только IPoE), второй (на другом железе) - только PPPoE (без авторизации) - для того, чтобы мяукнуть клиенту, что ему пора отключить PPPoE и перенастроить свою железку на "динамический IP".

Причём "старый" PPPoE  был с Dual access, т.е. железка получала "вторичный IP", dhcp-запрос от которого сейчас "слышит" сервак с IPoE.

Т.о. в момент перехода, довольно часто случается такое, что клиент умудряется поднять ДВА соединения одновременно - на одном серваке PPPoE, на втором "неавторизованное IPoE". Авторизация от радиуса, который в таком случае отдаёт access-reject, accel соотв. выдаёт клиенту "гостевой IP".

Вообщем, каша ещё та... :-( Как её правильно расхлебать пока не понял.. Вот и стараюсь загнать всё "старое" в null.

Но скорее всего, проблема к IP отношения не имеет, а живёт где-то в L2..

 

P.S. Плюс ко всему, обнаружились ещё одни грабли от D-Link - с pppoe circuit id insertion

 

 

Share this post


Link to post
Share on other sites

Добрый день.

Только начал знакомится с accel-ppp IPoE, поделитесь опытом:

1. Как правильно контролировать длительность сессии?

 

Если использовать

lease-time=600
max-lease-time=660

то сессии абонентов с роутерами будут "висеть вечно" до команды разрывать соединения.

Если установить атрибут

Session-Timeout=86400

 То сессии будут рвать в разнобой в зависимости от времени подключения. Лучше в таком случае чтобы все сессии рвались в определенное время, например в 0 часов.

 

2. Практическая необходимость renew-time? При тестировании конечное оборудование никак не реагировала на данный параметр.

 

Share this post


Link to post
Share on other sites
В 30.04.2018 в 19:15, trksergey сказал:

Лучше в таком случае чтобы все сессии рвались в определенное время, например в 0 часов.

Зачем?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now