ronin_zp

Судя по маку - сетевая интел. Ранее у них стоял сервак на freebsd (приходилось делать инспекцию) - сейчас не знаю. Знаю только что на филиалах ставят аппаратные микротики теперь. На почту ни техотдел, ни их IT директор не отвечает. Буду мучать их по телефону. Но, в любом случае, интересно решение со стороны сервера. Это первый, могут и остальные появиться Выяснилось. У клиента freebsd с установкой связи через родной ppp Два филиала оказывается постоянно рвалась сессия с момента перевода сервера на accel. За пару дней до этого наблюдал такую картину ещё у одного аналогичного клиента. Только у того сессия н рвалась, а тупо переставала пропускать трафик. Решения два: 1) радикальный - смена клиента на mpd5 2) добавление в конфиг ppp следующих строк в раздел default disable ipv6cp disable ipv6 disable lqr deny lqr Думаю запрет ipv6 не обязателен, но в лог ругалось и на него - потому предпочли отключить Ну а офис попробуем через недельку наблюдений за этими филиалами.

Вот конфиг [modules] log_file pptp pppoe auth_mschap_v2 auth_mschap_v1 auth_chap_md5 auth_pap radius sigchld pppd_compat shaper [core] log-error=/var/log/accel-ppp/core.log thread-count=4 [ppp] verbose=1 min-mtu=1000 mtu=1492 mru=1492 [lcp] echo-interval=30 echo-failure=3 [pptp] echo-interval=30 verbose=1 [pppoe] interface=p1p1 interface=re:vlan[0-9][0-9][0-9][0-9] interface=re:vlan[0-9][0-9][0-9] interface=re:vlan[0-9][0-9] verbose=1 [dns] dns1=x.x.x.x dns2=y.y.y.y [radius] dictionary=/usr/local/share/accel-ppp/radius/dictionary nas-identifier=xxx nas-ip-address=x.x.x.x gw-ip-address=10.12.0.1 auth-server=x.x.x.x:1812,xxxxxxxxx acct-server=y.y.y.y:1813,xxxxxxxxx server=y.y.y.y,xxxxxxxxx,auth-port=1812,acct-port=1813,req-limit=0,fail-time=0 dae-server=0.0.0.0:3799,xxx verbose=1 timeout=3 max-try=3 #acct-timeout=300 #acct-delay-time=0 acct-timeout=0 [log] log-file=/var/log/accel-ppp/accel-ppp.log log-emerg=/var/log/accel-ppp/emerg.log log-fail-file=/var/log/accel-ppp/auth-fail.log copy=1 level=3 [pppd-compat] radattr-prefix=/var/run/radattr verbose=1 [shaper] #may need: ethtool -K eth0 tso off ufo off gso off gro off lro off up-limiter=police down-limiter=tbf attr-up=PPPD-Downstream-Speed-Limit attr-down=PPPD-Upstream-Speed-Limit verbose=1 [client-ip-range] disable [cli] telnet=127.0.0.1:2000 tcp=x.x.x.x:2001 Может я в нём что-то недоглядел? Это проблема единственная. В остальном всё устраивает. Тянет без глюков больше в разы, чем freebsd+mpd5.

Судя по маку - сетевая интел. Ранее у них стоял сервак на freebsd (приходилось делать инспекцию) - сейчас не знаю. Знаю только что на филиалах ставят аппаратные микротики теперь. На почту ни техотдел, ни их IT директор не отвечает. Буду мучать их по телефону. Но, в любом случае, интересно решение со стороны сервера. Это первый, могут и остальные появиться Вот я так же думаю.

ага. бесплатно заменить организации сервак, на котором она 100М интернета принимает и строит туннели с парой десятком филиалов. конструктивный совет, согласен.

Стоит сервер с accel-ppp в режиме PPPoE Совершенно не напрягаясь жуёт около 4000 клиентов Но сегодня столкнулись с такой проблемой Два варианта PADI 1) PPPoE PADI [Host-Uniq 0xC068C8C7] [service-Name "xxxx"] 2) PPPoE PADI [service-Name "xxxx"] [Host-Uniq 0x060000000B000000] В первом случае сервер не отвечает PADO пакетом, во втором случае работает нормально Весь прикол в том, что первый вариант приходит от единственного клиента на всю абонбазу. Приходится его пока оставлять на серваке freebsd+mpd5. Эта связка последний год уже задрала. Ребутится произвольно при количестве пользователей от 600. Как можно выйти из положения? Может кто-то сталкивался уже? Заранее благодарен за ответ.