pppoetest Опубликовано 13 февраля, 2018 · Жалоба Либо слей свежие сырцы, либо пропатчи сам https://github.com/xebd/accel-ppp/issues/13 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bos9 Опубликовано 14 февраля, 2018 (изменено) · Жалоба Да, скачал через 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 ? Изменено 14 февраля, 2018 пользователем bos9 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pppoetest Опубликовано 14 февраля, 2018 · Жалоба Второе. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bos9 Опубликовано 15 февраля, 2018 · Жалоба Что-то лыжи не едут... [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, а где фильтр с полисером то? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
taf_321 Опубликовано 15 февраля, 2018 · Жалоба что выдается по tc filter show dev ppp0 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bos9 Опубликовано 15 февраля, 2018 · Жалоба Только что, taf_321 сказал: tc filter show dev ppp0 пусто! забыл уточнить - скорость указывал пятой колонкой в chap-secrets Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bos9 Опубликовано 19 февраля, 2018 · Жалоба Но скорость то режется и входящая и исходящая. Просветите, как реализован полисер исходящего трафика без фильтра? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
taf_321 Опубликовано 19 февраля, 2018 · Жалоба Интерфейс привязан к конкретному клиенту, дисциплина с параметрами выделенной скорости на интерфейс назначена. В этом случае наличие фильтра не нужно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bos9 Опубликовано 19 февраля, 2018 · Жалоба 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 Но в данном случае его нет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bos9 Опубликовано 19 февраля, 2018 · Жалоба Нашел. # 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' почему-то ничего не показывает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nik247 Опубликовано 2 марта, 2018 (изменено) · Жалоба 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 Изменено 3 марта, 2018 пользователем nik247 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kaktak Опубликовано 20 марта, 2018 · Жалоба Подзабыл теорию tc.. Подскажите, правильно ли я понимаю, что параметр fwmark модуля shaper позволяет пустить промаркированный трафик мимо шейпера только в случае использования htb, но не будет работать с tbf? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xlr Опубликовано 26 марта, 2018 · Жалоба Добрый день! имеется сборка accel-pppd, zebra + ospf для динамической маршрутизации, таких серверов несколько. за каждым клиентом закреплён свой ip. на сервере с радиусом есть проверка по маршруту, подключён ли клиент к какому либо из серверов, для предотвращения нескольких подключений одним клиентом к разным сервера. на новой сборке (gentoo kerne 4.9.76 или centos 7 kernel 3.6 или centos 7 kernel 4.10) при быстром подключении и отключении, рассылается добавление маршрута, но удаление не отправляется по ospf из-за чего радиус думает что клиент уже подключён, хотя на самом деле коннекта нет, лечится перезапуском ospf или через час по таймауту маршрут удаляется. может кто-нибудь сталкивался с данной проблемой? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
GrandPr1de Опубликовано 26 марта, 2018 · Жалоба да. 5 часов назад, xlr сказал: кто-нибудь сталкивался с данной проблемой? похоронить кваггу. использовать bird Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xlr Опубликовано 30 марта, 2018 · Жалоба On 26.03.2018 at 2:29 PM, GrandPr1de said: да. похоронить кваггу. использовать bird спасибо! работает! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mr.Scamp Опубликовано 4 апреля, 2018 · Жалоба Попробовали 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SABRE Опубликовано 4 апреля, 2018 · Жалоба 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 У нас такая-же беда. Писал по этому поводу - никто не ответил. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
theMIROn Опубликовано 5 апреля, 2018 · Жалоба 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 запоминается, а дальше следующие запросы выглядят для сервера в той-же сессии другими клиентами, на что получают отлуп. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zlolotus Опубликовано 18 апреля, 2018 · Жалоба Коллеги, подскажите как ведет себя debian 8, на accel-ppp(pppoe). Есть какие-то подводные камни? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Kolunchik Опубликовано 18 апреля, 2018 · Жалоба Хорошо ведёт, но лучше брать ядро 4.х Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zlolotus Опубликовано 18 апреля, 2018 · Жалоба 17 минут назад, Kolunchik сказал: Хорошо ведёт, но лучше брать ядро 4.х Почему? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Kolunchik Опубликовано 18 апреля, 2018 · Жалоба По личному опыту и по опыту коллег по каналу в запрещённом мессенджере. Там в ядре много изменилось, причём в лучшую сторону. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 26 апреля, 2018 · Жалоба Переводим клиентов с 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
trksergey Опубликовано 30 апреля, 2018 · Жалоба Добрый день. Только начал знакомится с accel-ppp IPoE, поделитесь опытом: 1. Как правильно контролировать длительность сессии? Если использовать lease-time=600 max-lease-time=660 то сессии абонентов с роутерами будут "висеть вечно" до команды разрывать соединения. Если установить атрибут Session-Timeout=86400 То сессии будут рвать в разнобой в зависимости от времени подключения. Лучше в таком случае чтобы все сессии рвались в определенное время, например в 0 часов. 2. Практическая необходимость renew-time? При тестировании конечное оборудование никак не реагировала на данный параметр. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
myth Опубликовано 4 мая, 2018 · Жалоба В 30.04.2018 в 19:15, trksergey сказал: Лучше в таком случае чтобы все сессии рвались в определенное время, например в 0 часов. Зачем? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...