Перейти до

PPPoE: MPD+FreeBSD vs ACCEL-PPP+ubuntu


Рекомендованные сообщения

День добрый!

 

Хочу посоветоваться:

 

Есть средняя сеть, в которой и фттх, и пон, и умные свитчи (разные), и местами тупарики остаются, работает на PPPoE (в общем - нормально работает). PPPoE приниматеся на тазиках с фрей и МПД. Биллинг самописный.

 

Есть желание хотя-бы часть сети перевести на IPoE (vlan-per-user + IP Unnumbered), через ACCEL-PPP.

 

В связи с этим встал вопрос: есть ли смысл (и стоит ли вообще) менять НАСы с MPD+FreeBSD на ACCEL-PPP+ubuntu? Так как, с одной стороны, хочется единообразия на серверах, а с другой стороны - "работает - не трожь!"

Сервера: интел И7 с сетевухами ЕТ, на каждый сервер попадает по 600-700 клиентов с 600-800 Мбит/с трафика.

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

А почему бы и нет? Accel-ppp хорошая и надежная штука и по-моему единственная в своем роде имеющая ipoe как таковую и прочие протоколы.

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

Нельзя нарушать главную заповедь "работает - не трогай".

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

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

А почему бы и нет? Accel-ppp хорошая и надежная штука и по-моему единственная в своем роде имеющая ipoe как таковую и прочие протоколы.

хорошая - да

можна даже сказать единственная - да

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

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

 

А почему бы и нет? Accel-ppp хорошая и надежная штука и по-моему единственная в своем роде имеющая ipoe как таковую и прочие протоколы.

хорошая - да

можна даже сказать единственная - да

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

 

Accel штука хорошая, но при больших нагрузках прийдется колдовать, на фре с распределением на ядра лучше работает, а для ацела нужна не убунта а хотябы дебиан с пересобраным ядром чтобы большие нагрузки пережевать и для распределения по ядрам прерывания прийдется поиграться так как линуха сама с сетевух не умеет корректно распределять прерывания. Просто пробовали ацелом заменить PPPoE всплыло много проблем, хотя у ацела производительность намного выше в будущем тоже хотел бы перевести сетку на ацел!

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

Accel штука хорошая, но при больших нагрузках прийдется колдовать, на фре с распределением на ядра лучше работает, а для ацела нужна не убунта а хотябы дебиан с пересобраным ядром чтобы большие нагрузки пережевать и для распределения по ядрам прерывания прийдется поиграться так как линуха сама с сетевух не умеет корректно распределять прерывания. Просто пробовали ацелом заменить PPPoE всплыло много проблем, хотя у ацела производительность намного выше в будущем тоже хотел бы перевести сетку на ацел!

Чушь какая-то.

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

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

 

Accel штука хорошая, но при больших нагрузках прийдется колдовать, на фре с распределением на ядра лучше работает, а для ацела нужна не убунта а хотябы дебиан с пересобраным ядром чтобы большие нагрузки пережевать и для распределения по ядрам прерывания прийдется поиграться так как линуха сама с сетевух не умеет корректно распределять прерывания. Просто пробовали ацелом заменить PPPoE всплыло много проблем, хотя у ацела производительность намного выше в будущем тоже хотел бы перевести сетку на ацел!

Чушь какая-то.

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

 

согласен что с разгона намешал все в кучу =)  единственное что хотел сказать что у меня долгое время все под Фрей работает, как только на брас поставил дебиан с ацелом начались проблемы с балансировкой по ядрам процессора - одно ядро нагружено под 100% а остальные три по 20% и пришлось играться чтобы как-то их уровнять, может конечно это еще побочный ефект агрегации (трафик 1.6 Г). Но пока остаюсь на Фре руки не доходят разобраться до конца в чем дело, но аццел это вещь он более производителен!

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

Что значит более производителен?

PPPoE, если что, в linux терминируется ядром уже лет 5 как. Accel не более чем управляюшая обертка, userspace приложение.

И на производительность сервера он оказывается абсолютно минимальное влияние..

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

Что значит более производителен?

PPPoE, если что, в linux терминируется ядром уже лет 5 как. Accel не более чем управляюшая обертка, userspace приложение.

И на производительность сервера он оказывается абсолютно минимальное влияние..

Тогда возможно я ошибаюсь или что то не дочитал! Вам спасибо что разьяснили!

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

 

Что значит более производителен?

PPPoE, если что, в linux терминируется ядром уже лет 5 как. Accel не более чем управляюшая обертка, userspace приложение.

И на производительность сервера он оказывается абсолютно минимальное влияние..

Тогда возможно я ошибаюсь или что то не дочитал! Вам спасибо что разьяснили!

 

Что accel, что mpd являются всего лишь софт-обертками над обработкой всего в ядре.

В линуксе модули ядра занимаются pppoe/pptp/etc, во фре подсистема NETGRAPH.

И там, и там есть баги, мешающие плодотворно эксплуатировать софт-решения на высоких нагрузках. О чем уже много страниц исписано на различных форумах.

 

Поэтому независимо от того, что вы выберете, вы получите высокопроизводительный брас, но с растущей вероятностью падения при увеличении нагрузки.

В FreeBSD ошибки в большей части в районе шейпера и ната (на стыке с dummynet), в линуксе последние проблемы были найдены в обработке pppoe пакетов.

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

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

Чисто поржать, самосборный нормально нагруженный сервер(до 1.5к онлайна)

[kayot@nas3 ~]$ uptime
 15:37:12 up 587 days, 11:15,  1 user,  load average: 0.00, 0.01, 0.00
[kayot@nas3 ~]$ cat /proc/net/pppoe | wc -l
1115
Ссылка на сообщение
Поделиться на других сайтах

 

 

Сервера: интел И7 с сетевухами ЕТ, на каждый сервер попадает по 600-700 клиентов с 600-800 Мбит/с трафика.

линь с accel-ppp такой трафик на целероне легко прожует в общем-то.

 

 

 

в линуксе последние проблемы были найдены в обработке pppoe пакетов.

это вылезло в последних ядрах (эдак 3.19, в 4.1 точно есть, в 3.10 точно нет), и в основном в связи с 1) внедрением асинхронной обработки событий типа дисконнекта и 2) тем, что accel-ppp пытается сам обрабатывать pppoe дисконнекты, в то время как rp-pppoe, которым пользуется основная масса, этого не умеет (этим занимается ядро, итог - race condition на accel-ppp).

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

 

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

Чисто поржать, самосборный нормально нагруженный сервер(до 1.5к онлайна)

[kayot@nas3 ~]$ uptime
 15:37:12 up 587 days, 11:15,  1 user,  load average: 0.00, 0.01, 0.00
[kayot@nas3 ~]$ cat /proc/net/pppoe | wc -l
1115

1115 терминаций с LA=0? Это как так?

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

 

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

Чисто поржать, самосборный нормально нагруженный сервер(до 1.5к онлайна)

[kayot@nas3 ~]$ uptime
 15:37:12 up 587 days, 11:15,  1 user,  load average: 0.00, 0.01, 0.00
[kayot@nas3 ~]$ cat /proc/net/pppoe | wc -l
1115

Я кажется видел вас в теме нага про аццель ;)

Мы тоже ржали, пока до 2к+ на хост не добрались...

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

Это linux, нормальное железо и вылизанный софт. Никакой магии.

Не верю!

Хотя-бы сетевуха немного дала на LA. Разве что из всех подключенных никто интернетом не пользуется ))

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

 

 

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

Чисто поржать, самосборный нормально нагруженный сервер(до 1.5к онлайна)

[kayot@nas3 ~]$ uptime
 15:37:12 up 587 days, 11:15,  1 user,  load average: 0.00, 0.01, 0.00
[kayot@nas3 ~]$ cat /proc/net/pppoe | wc -l
1115

 

Я кажется видел вас в теме нага про аццель ;)

Мы тоже ржали, пока до 2к+ на хост не добрались...

 

Год назад на этих же серверах было по 1.5-2к онлайна, потихоньку юзеры на IPoE переезжают.

 

Вот вам с accel-машины, 3к онлайн пиковый. Еще и IPoE, оно побольше кушает чем PPPoE.

[root@IPoE1 ~]# accel-cmd show stat
sessions:
  starting: 0
  active: 2634
  finishing: 0
ipoe:
  starting: 0
  active: 2634
  delayed: 0
Тут конечно LA не 0, но тоже далеко не предел для недорогого сервера.

[root@IPoE1 ~]# uptime
 17:07:40 up 64 days,  4:43,  2 users,  load average: 0.39, 0.58, 0.74
Відредаговано KaYot
Ссылка на сообщение
Поделиться на других сайтах

 

Это linux, нормальное железо и вылизанный софт. Никакой магии.

Не верю!

Хотя-бы сетевуха немного дала на LA. Разве что из всех подключенных никто интернетом не пользуется ))

 

Я ж не заставляю верить, и в свою секту никого не зову. Трафика бегает гиг, самый обычный BRAS.

Если будем спорить на пиво - дам ssh доступ самому поглядеть :)

Ссылка на сообщение
Поделиться на других сайтах
  • 10 months later...

можно деталей

 

конфиг и версию ядра 

sysctl

настройки сетевых

 

Спасибо :)

 

 

 

Это linux, нормальное железо и вылизанный софт. Никакой магии.

Не верю!
Хотя-бы сетевуха немного дала на LA. Разве что из всех подключенных никто интернетом не пользуется ))

 

Я ж не заставляю верить, и в свою секту никого не зову. Трафика бегает гиг, самый обычный BRAS.
Если будем спорить на пиво - дам ssh доступ самому поглядеть :)

 

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

можно деталей

Ядро древнее, 2.6.32 вроде бы

Конфиг ядра дефолтный "все галочки включить" + патчи на добавление IMQ/ipset.

В sysctl увеличение ARP-таблицы.

у сетевых увеличен ring buffer.

Считай обычная линукс-машина.

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

а acel какой для pptp и какой для ipoe? 

 

Благодарю :)

 

 

можно деталей

Ядро древнее, 2.6.32 вроде бы
Конфиг ядра дефолтный "все галочки включить" + патчи на добавление IMQ/ipset.
В sysctl увеличение ARP-таблицы.
у сетевых увеличен ring buffer.
Считай обычная линукс-машина.

 

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

Создайте аккаунт или войдите в него для комментирования

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

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Вхід

Уже зарегистрированы? Войдите здесь.

Войти сейчас
  • Зараз на сторінці   0 користувачів

    Немає користувачів, що переглядають цю сторінку.

  • Схожий контент

    • Від mac
      Глюк в тому, що один (так - тільки один) mac адрес onu існує в білінгу у вигляді строки. Це трохи заважає.
      olt - bdcom gepon.
      Наскільки зрозумів, це виключно проблема реалізації snmpwalk у freebsd, де snmpwalk може на свій розсуд віддати mac адресу не як hex-string, а як звичайний string.
      Можливо snmpwalk тригериться на якомусь символі, мені невідомо.
       
      # tcpdump -vv -i em0 udp port 161 and host olt and host ub | grep "3320.101.10.4.1.1.241 ... olt.snmp > ub.47940: [udp sum ok] { SNMPv2c C="*****" { GetResponse(44) R=93278354 E:3320.101.10.4.1.1.241="8LO"W*" } } ub.47940 > olt.snmp: [udp sum ok] { SNMPv2c C="*****" { GetNextRequest(34) R=93278355 E:3320.101.10.4.1.1.241 } } snmpwalk -c***** -v2c -t5 olt .1.3.6.1.4.1.3320.101.10.4.1.1 SNMPv2-SMI::enterprises.3320.101.10.4.1.1.241 = STRING: "8LO\"W*" snmpwalk -Ox -c***** -v2c -t5 olt .1.3.6.1.4.1.3320.101.10.4.1.1 SNMPv2-SMI::enterprises.3320.101.10.4.1.1.241 = Hex-STRING: 38 4C 4F 22 57 2A  
      Це стосується таких параметрів у snmp конфізі bdcom
       
      [signal] MACINDEX=".1.3.6.1.4.1.3320.101.10.4.1.1" [misc] ONUINDEX=".1.3.6.1.4.1.3320.101.11.1.1.3"  
      За для усунення глюку спробував трошки змінити код і завдати тип snmp параметру явно у ./api/libs/api.ponbdcom.php у function collect()
      Це працює. Мабуть станеться у нагоді:
       
      # diff api.ponbdcom.php{.new,.bak} 37c37 < $onuIndex = $this->snmp->walk('-Ox ' . $oltIp . ':' . self::SNMPPORT, $oltCommunity, $onuIndexOid, self::SNMPCACHE); --- > $onuIndex = $this->snmp->walk($oltIp . ':' . self::SNMPPORT, $oltCommunity, $onuIndexOid, self::SNMPCACHE); 91c91 < $macIndex = $this->snmp->walk('-Ox ' . $oltIp . ':' . self::SNMPPORT, $oltCommunity, $macIndexOID, self::SNMPCACHE); --- > $macIndex = $this->snmp->walk($oltIp . ':' . self::SNMPPORT, $oltCommunity, $macIndexOID, self::SNMPCACHE);  
      P.S. Створив тему, а зараз міркую: а може це глюк у ПЗ olt. Оновлю фірмваре olt та перевірю...
       

    • Від a_n_h
      Всем доброго дня и мирного неба!
        После многочисленных экспериментов выяснил, что на последних версиях freebsd  максимум удавалось прокачать до 14 ГБт суммарно трафика со 100% загрузкой процессора. На том-же железе но с установленной freebsd 11.2 прокачивается до 20-ти ГБт суммарно тестового трафика с загрузкой процессора около 50%. 
        Подскажите, что можно убрать или наоборот добавить в систему с freebsd 13,3 для получения аналогичного результата...
    • Від mac
      Здається, після оновлення PHP 7.4 до PHP 8.2 feesharvester припинив працювати:
       
      /usr/local/bin/curl "http://127.0.0.1/billing/?module=remoteapi&key={SERIAL}&action=feesharvester" <br /> <b>Fatal error</b>: Uncaught TypeError: Unsupported operand types: string - string in {UBPATH}/billing/api/libs/api.fundsflow.php:570 Stack trace: #0 {UBPATH}/billing/modules/remoteapi/feesharvester.php(22): FundsFlow-&gt;harvestFees('2024-01') ...  
      Невеличке розслідування врешті з'ясувало, що це через наявність пробілу у деяких логінах абонентів. Як так сталося? Тому що інколи був неуважно додан трейлінг пробіл до номеру будинка і цей пробіл потрапив до логіну абоненту. Логін абоненту неможливо змінити ніяким чином штатними засобами. Я не розглядаю створення нового абонента для усунення помілки.

      Був обран такий шлях вирішення проблеми. Заміну функції php explode() знайшов у мережі. Мабуть це станеться в нагоді:

       
      diff api.fundsflow.php.bak api.fundsflow.php.new 559c559 < $eachfee = explode(' ', $eachline); --- > $eachfee = preg_split("~(?<!\\\\)(?:\\\\{2})*'[^'\\\\]*(?:\\\\.[^'\\\\]*)*'(*SKIP)(*F)|\s+~s" , $eachline);  
    • Від FantoM_EscapE
      Хочу перенести свій білінг NODENY із фізичного сервера на віртуальний. Шукаю адміна який зможе допомогти у цьому питанні, так як нашого адміна банально призвали до війська. Вся схема на даний момент робоча, маю доступи до всього. Потрібно проінсталити на новішу версію FREEBSD, бо на моїй 10 річній вже не працюють нові SSL сертифікати. Кого зацікавила дана пропозиція - прошу у приватні повідомлення. обсудимо ціну і строки. або пишіть на будь-який месенджер 0677792091
    • Від Alain_MG
      Всем привет, Я работаю над проектом GPON с оборудованием OLT GP2508. Я пришел к этапу «АВТОРИЗАЦИЯ» на уровне сервера Freeradius. Мой сабик и вопрос в том, что я хочу создать профиль 512M например на сервере Freeradius, и еще я не хочу ограничение пропускной способности не на уровне сервера PPPoE а скорее на OLT, как сделать чтобы профиль создавался на OLT будет на уровне RADIUS? СПАСИБО
×
×
  • Створити нове...