[kayot]

Ну перешёл я на 3.18.24, вырезал там всякие wireless

как теперь быть уверенным в стабильной работе ОС если центос не на стоковом ядре находится, как пускать абонентов через этот сервер? RPM уже например ругался на это. Ядро которое "отполированное" в RH - оно как то проще и стабильней, но там модуль vlan_mon не собирается. А здесь теперь ждать неизвестно чего. Или может вообще лучше не трогать .config ? Кто, что скажет?

Этот вопрос конечно слабо касается топика, но раз уж начали давайте немного отвлечемся.

Система нумерации версий ядра linux - значимая(цифры ставятся не просто так). И это очень удобно.

При внесении какого-то нового функционала, или глобальной переделке существующего всегда запускается новая ветка. В стабильную ветку непротестированные изменения не вносятся!

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

Свежезакоммиченная сборка 3.19.0 почти гарантированно с детскими болячками и приколами, а спустя пару месяцев(а иногда и год), сборка 3.19.15(условно) станет стабильной и применимой в продакшне.

 

Я долго держал сервера на 3.10, потом почитав про 'революционные' изменения в 3.18 решил обновить, накатал 3.18.10 насколько помню.

Раз в месяц сервер с accel ребутился без видимых причин, пока на форуме не подсказали что нужно не дрова и accel мучать, а ядро починить :) Обновил до актуального 3.18.24 - и все проблемы исчезли.

С тех пор его и не трогаю, работает с прошлой осени.

 

Потому решительно непонятно из каких соображений вы выбрали именно 3.18.24. Чужой опыт тут не работает, мне обновлять просто лень(работает - не трогай), но 3.18.32 однозначно 'надежнее'.

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

Для чего этим заниматься и какой профит - я не знаю.

[NiTr0]

Для чего этим заниматься и какой профит - я не знаю.

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

 

но держать это на брасе - смысла мало. по сути, брас - это ядро + брас-демон, iptables/tc для конфигурирования файрвола/шейпера, + ssh, snmpd и bird/quagga. ну и обвязка, позволяющая этому взлететь.

[dtcom]

У кого нибудь работает режим q-in-q, mode=L2, start=dhcpv4. Если работает то на какой версии. А то у меня работает тока просто vlan per user, переключаюсь на q-in-q сессия стартует и через 10sec завершается и так по кругу. Пробовал версии 1.10.0 1.10.1 1.10.2 везде так. На последней git версии f5a97ed не стартует dhcp.

[kayot]

dtcom

Работает, на любой версии. Системе и аццелю все равно сколько там у вас меток и как интерфейс называется.

[Dimka88]

У кого нибудь работает режим q-in-q, mode=L2, start=dhcpv4. Если работает то на какой версии. А то у меня работает тока просто vlan per user, переключаюсь на q-in-q сессия стартует и через 10sec завершается и так по кругу. Пробовал версии 1.10.0 1.10.1 1.10.2 везде так. На последней git версии f5a97ed не стартует dhcp.

Логи уровня 5 показали бы, что ли.

[dtcom]

У кого нибудь работает режим q-in-q, mode=L2, start=dhcpv4. Если работает то на какой версии. А то у меня работает тока просто vlan per user, переключаюсь на q-in-q сессия стартует и через 10sec завершается и так по кругу. Пробовал версии 1.10.0 1.10.1 1.10.2 везде так. На последней git версии f5a97ed не стартует dhcp.

Логи уровня 5 показали бы, что ли.

Спасибо ответившим, разобрался. Выяснилось что сессия завершалась потому что от клиента не приходило поттвержденние. А не приходило потому что клиент не видел ответа от accel-ppp, они попросту до него не доходили. Настроил q-in-q на другом свиче стали приходить ответы и все заработало. accel-ppp 1.10.2.

[hsvt]

Ядро которое "отполированное" в RH - оно как то проще и стабильней

ванильные ядра-то чем нестабильны? аптайм - годы. или по принципу "если туда напилили 100500 патчей на kvm/openvz - значит это круто"?

 

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

 

Ну перешёл я на 3.18.24, вырезал там всякие wireless

как теперь быть уверенным в стабильной работе ОС если центос не на стоковом ядре находится, как пускать абонентов через этот сервер? RPM уже например ругался на это. Ядро которое "отполированное" в RH - оно как то проще и стабильней, но там модуль vlan_mon не собирается. А здесь теперь ждать неизвестно чего. Или может вообще лучше не трогать .config ? Кто, что скажет?

Этот вопрос конечно слабо касается топика, но раз уж начали давайте немного отвлечемся.

Система нумерации версий ядра linux - значимая(цифры ставятся не просто так). И это очень удобно.

При внесении какого-то нового функционала, или глобальной переделке существующего всегда запускается новая ветка. В стабильную ветку непротестированные изменения не вносятся!

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

Свежезакоммиченная сборка 3.19.0 почти гарантированно с детскими болячками и приколами, а спустя пару месяцев(а иногда и год), сборка 3.19.15(условно) станет стабильной и применимой в продакшне.

 

Я долго держал сервера на 3.10, потом почитав про 'революционные' изменения в 3.18 решил обновить, накатал 3.18.10 насколько помню.

Раз в месяц сервер с accel ребутился без видимых причин, пока на форуме не подсказали что нужно не дрова и accel мучать, а ядро починить :) Обновил до актуального 3.18.24 - и все проблемы исчезли.

С тех пор его и не трогаю, работает с прошлой осени.

 

Потому решительно непонятно из каких соображений вы выбрали именно 3.18.24. Чужой опыт тут не работает, мне обновлять просто лень(работает - не трогай), но 3.18.32 однозначно 'надежнее'.

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

Для чего этим заниматься и какой профит - я не знаю.

 

Спасибо за ликбез, по 2500+ сессий вас в qinq+unnumbered держит?

[kayot]

hsvt

Да, L2, vlan-per-user, QinQ. Полет нормальный.

[purecopper]

Коллеги, подскажите, а как сейчас у accel дела со стабильностью? Интересует дикая связка ipoe L2 QinQ со стартом сессии по неклассифицированному пакету и формированием username из svid+vid+ip. Такое вообще возможно?

[NiTr0]

Всегда считал что на таких дистрах не нужно трогать ядра

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

[SokolovS]

Если RADIUS перестает отвечать на accounting update, то accel рвет сессию. Так и должно быть? В конфиге можно изменить, чтобы не рвал? Если я правильно понял, то за это отвечает параметр acct-timeout=n, но если его выставить в "0", то будут ли приходить accounting update пакеты?

Изменено 12 мая, 2016 пользователем SokolovS

[kayot]

А поиск в этой теме религия не позволяет?

acct-timeout именно то что нужно, поставьте 0.

[SokolovS]

А поиск в этой теме религия не позволяет?

acct-timeout именно то что нужно, поставьте 0.

На второй вопрос однозначного ответа не нашел. Цитирую ваш же ответ:

При установленном acct-timeout=0 ничего не происходит, NAS работает автономно не отсылая апдейты.

Так все таки, accel при acct-timeout=0 перестает ждать ответ или перестает слать accounting update?

Изменено 12 мая, 2016 пользователем SokolovS

[xeb]

не ждёт ответы, но если они случаются, то тоже хорошо

[Dmitry76]

Добрый день!

Подскажите как выдавать в режиме IPOE отдельные честные адреса для клиентов?

Режим такой:

mode=L2

start=dhcpv4

ip-unnumbered=1

proxy-arp=1

 

attr-dhcp-client-ip=DHCP-Client-IP-Address

attr-dhcp-router-ip=DHCP-Router-IP-Address

attr-dhcp-mask=DHCP-Mask

 

Допустим, что на сервере 192.168.0.1/24

Если серая сеть, то проблем нет - редиус отдал в аттрибутах данные для DHCP ответа, клиент принял и заработал через NAT.

А вот отдать клиенту честный адрес /32 как правильно? Роутеры tp-link понимают, когда в ответе DHCP шлюз отдается 192.168.0.1 маска 255.255.255.0, а IP клиента, пусть 5.5.5.5. Но другие клиенты отказываются принимать такие параметры DHCP, либо же принимают,

но трафик не ходит. Есть решение?

[xeb]

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

[kayot]

Конечно есть, отдавайте не /32, а нормальную маску и шлюз из этой же подсети.

Для этого у вас ip-unnumbered=1 и стоит.

[ichthyandr]

Народ подскажите, может кто сталкивался.

на раздачу сейчас у нас работает mpd5 под фрей (pptp & l2tp), решили запустить pppoe под акселем и столкнулись с такой проблемой:

при смене на роутерах типа подключения с pptp/l2tp на pppoe сильно просаживается полоса по wifi, например, отдаем 80Мбит, по кабелю всё норм, а по радио ~30Мбит

в виде полки. При pptp/l2tp такого эффекта нет. Где собака порылась? Спасибо.

[myth]

шифрование выключено?

[ichthyandr]

шифрование выключено?

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

[myth]

шейпер встроенный или внешние скрипты?

[ichthyandr]

шейпер встроенный или внешние скрипты?

[modules]
log_file
pppoe
auth_chap_md5
radius
shaper

...

[shaper]
attr=Filter-Id
ifb=ifb0
up-limiter=htb
down-limiter=htb
verbose=1

...

[myth]

mtu?

[ichthyandr]

mtu?

изменил настройки шейпера, проблема пока ушла

[shaper]
attr=Filter-Id
#down-burst-factor=0.1
#up-burst-factor=1.0

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=tbf
#up-limiter=police
down-limiter=tbf
up-limiter=htb
#down-limiter=htb
#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

 

спасибо за мыслю :)

Изменено 17 мая, 2016 пользователем ichthyandr

[myth]

Встречалось такое. С чем связано - непонятно...