Раньше приводило к kernel panic. Не знаю как сейчас:

 

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

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


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

AlKov 

accel-ppp.conf


[shaper]
attr=Filter-Id
ifb=ifb0
#DO NOT USE POLICE!!!
up-limiter=htb
down-limiter=htb
leaf-qdisc=sfq perturb 10

Вот в таком формате отдается с радиуса (accel-ppp.log ):


[2017-12-12 14:21:39]:  info: ipoe216: recv [RADIUS(1) Access-Accept id=1 <Filter-Id "10240/10240"> <L4-Redirect 1> <DHCP-Lease-Time 150> <Session-Timeout 300> <DHCP-Client-IP-Address 10.128.16.107>]

 

У меня какая-то чертовщина выходит - на спидтесте download более-менее дотягивает до установленной скорости, а вот с upload вообще чудеса.

Например, на ноуте, подключенному кабелем к роутеру TP-Link WR-740N upload % на 80 добирается до нужной скорости, а вот на планшетке по WIFI только дёргается около нуля и на этом всё заканчивается.

На ПК, подключенном кабелем  БЕЗ роутера почти аналогичная картина, за исключением отсутствия "дёрганья" - upload просто тупо не стартует..

Причём, картина практически не меняется при изменении параметров шейпера. В accel все параметры загружаются, в логах ругани не вижу.

accel-ppp version 1.11.2
accel-ppp# show sessions
     ifname     |  username   |    calling-sid    |       ip       | rate-limit  | type | comp |   called-sid   | state  |  uptime
----------------+-------------+-------------------+----------------+-------------+------+------+----------------+--------+----------
 eth0.2519.1105 | tester      | 60:aa:bb:cc:dd:f7 | 172.16.111.111 | 10240/10240 | ipoe |      | eth0.2519.1105 | active | 00:32:37
 eth0.2519.1101 | testik      | 4c:aa:bb:cc:dd:ee | 172.16.2.18    | 5120/5120   | ipoe |      | eth0.2519.1101 | active | 00:31:57

Походу, проблема в чём-то другом. Где копать дальше, не пойму...

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


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

AlKov 

Грабли с MTU

Похоже на то - ping -f -l 1472 ya.ru с клиента  не проходит, 1468 - идёт.. Не понятно, где затыкается. 

На NAT сервере в iptables есть правило TCPMSS для абонентской подсети. Или затык "до того как.."?

И почему тогда проблему вижу только на спидтест? Все сайты открываются без проблем, ролики в ютубе жужжат без вопросов..

 

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


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

AlKov 

TCPMSS не из той оперы, MTU надо править на интерфейсах сервера и свичах через которые QinQ трафик идет.

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


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

AlKov 

TCPMSS не из той оперы, MTU надо править на интерфейсах сервера и свичах через которые QinQ трафик идет.

На свитчах увеличен (включен jumbo frame), а вот на сервере облом - не даёт выставить выше 1500..

По-видимому, сетевухи не поддерживают. Драйвер (e1000e) ставил самый свежий, с сайта интел.

ifconfig eth0 mtu 1504
SIOCSIFMTU: Недопустимый аргумент

Тестовая машинка - старая супермикро, на борту две сетевухи 

0d:00.0 Ethernet controller: Intel Corporation 82573E Gigabit Ethernet Controller (Copper) (rev 03)
0e:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet Controller

P.S.

Супермикро не перестаёт меня удивлять! На борту две РАЗНЫЕ сетевухи! И зачем это??

Что ещё примечательно, одна из них поддерживает MTU > 1500, вторая - нет!!

Цитата

Some Intel gigabit adapters that support Jumbo Frames have a frame size limit of 9238 bytes, with a corresponding MTU size limit of 9216 bytes. The adapters with this limitation are based on the Intel® 82571EB, 82572EI, 82573L, 82566, 82562, 82575, and 80003ES2LAN controllers

Adapters based on the Intel® 82542 and 82573V/E controller do not support Jumbo Frames

И здесь мне "повезло" - как назло QinQ повесил на "убогую".

Завтра попробую поменять местами. 82573L кушает ifconfig eth1 mtu 1504.

Кстати.. Какой MTU назначить для QinQ интерфейса?

Достаточно ли будет изменить его только на eth1, или нужно ещё будет добавить в конфиг accel опцию mtu=1504?

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


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

AlKov 

Как ни странно, но про MTU в ругаемой вами документации есть раздел :)

Нужно увеличить на eth с двумя тегами и бондинге, если используется.

 

Разные сетевки на серверных платах стандартная тема, почти у всех производителей так. Поменяйте местами или воткните любую внешнюю человеческую, PT DUAL port нынче стоит пару бутылок пива.

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


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

"Перебросил" сетевухи, увеличил MTU до 1504, всё забегало. Есть смысл задирать MTU выше 1504?

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

Как ни странно, но про MTU в ругаемой вами документации есть раздел :)

Действительно, довольно странно. ;)

Теперь вот пытаюсь нарыть в "обруганной" мною доке "хитрые" параметры шейпера. Такие как cburst, r2q, quantum, mpu, latency и т.п.

В доке про них ни слова, а вот в обсуждениях встречаются то и дело. Откуда они вообще появились, и в каких случаях имеют смысл?

Например, хочу использовать Cisco like параметры шейпера (как-то привычнее и нагляднее они). Так вот - такой конфы шейпера достаточно для этого случая?

[shaper]
vendor=Cisco
attr=Cisco-AVPair
ifb=ifb1
up-limiter=htb
down-limiter=htb
time-range=1,00:00-09:59
verbose=1

Или есть смысл добавить что-то ещё из "законспирированных параметров"?

 

P.S.

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

PT DUAL port нынче стоит пару бутылок пива.

Чёт дорогое пиво у Вас.. ;)

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


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

Необходимо следующее - абонентов-должников авторизовать и редиректить на страницу "Нет денег", а новых абонентов,

или сменивших "железку" (другой MAC), отправлять в ЛК на "авторизацию".

 

Для "должников" сделал так - добавляю в радиус отправку атрибута L4-Redirect=1 и параметр "l4-redirect-ipset=Debtors" в конфиг accel,

который заносит IP должника в ipset. Ну и iptables редиректит этот IP, куда надо. Это работает..

 

А для "не авторизованных" хочу использовать l4-redirect-on-reject с выдачей IP из спец. пула, которым будет разрешён доступ только в ЛК,

где после успешной авторизации им будет изменяться логин (МАС-адрес) и активироваться "легальный доступ".

Проблема в том, что в моей "схеме" IP выдаёт радиус (Framed-IP), т.е. только после авторизации, которая в данном случае происходить не будет,

т.к. "логин" (MAC) не совпадает с "легальным" из БД. В этом случае радиус шлёт reject.

Т.о., когда accel-у прилетает этот reject от радиуса, клиент ещё не получил IP, соотв. редиректить некого..

Как реализовать такую хотелку?

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


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

Для публикации сообщений создайте учётную запись или авторизуйтесь

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

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!


Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.


Войти