elias292
-
Публикации
24 -
Зарегистрирован
-
Посещение
Сообщения, опубликованные пользователем elias292
-
-
Так проверяйте радиусом с какого NAS запрос идет.
И клиент получит ошибку 691, хотя всего-то надо, чтобы тестовый НАС не отвечал на запросы.
А убрать из абонентского VLAN религия не позволяет?
Уже убрал, но я же сказал чего мне надо.
-
Опубликовано · Изменено пользователем elias292 · Жалоба на ответ
все клиенты не заморачиваются с сервиснеймом, и запрашивают пустой.
т.е. первый же pppoe сервер попытается их подключить.
авторизация через радиус, и еще с билинга скрипты запускаются, которые лезут на NAS сервер и чего-то пытаются подправить. Уже когда клиент подключился.
Я ж говорю, человек до меня был с фантазией.
т.е. вот оно подключило клиента, авторизовало его, а потом с биллинга влезает скрипт и на интерфйсе клиента правит скорость.
Есессно, мой сервер таких вольностей не позволяет, и скорость не выставляется. Пока разберусь хотелось бы, чтобы он пускал в себя только тех, кто сказал правильное service name, в смысле тестовое.
-
По-моему достаточно указать непустой service name(-S) при запуске pppoe-server
Да да!
Я тоже так думал, НО:
-S name
Offer a service named name. Multiple -S options may be specified; each one causes the named service to be advertised in a Ser-
vice-Name tag in the PADO frame. The first -S option specifies the default service, and is used if the PPPoE client requests a
Service-Name of length zero.
т.е. -S это просто то что сервер pppoe подставляет. если приходит клиент с пустым Service-Name.
Я так думаю, что можно попробовать iptables -ом это дело фильтровать... Если совсем все плохо будет.
-
Хотелось бы плавно поменять платформу, а то что-то предшественник наворотил.
В общем, есть сервер pppoe, он работает, пытаюсь поставить свой, только для своих,
и возник вопрос:
как заставить в linux -е стандартный pppoe-server игнорировать запросы на подключение с пустым service name ?
А то у меня сервер быстрый, но не настроеный, и отвечает быстро, и все на него вешаются, что мне совсем не надо пока.
Всякие обходные решения не надо, только такое: игнорировать запросы с пустым rp_pppoe_service
Ну или таймаут какой сделать, но это не очень хорошо.
-
У нас так за ноябрь 2010:
У меня так, за ноябрь:
По основному биллингу:
1 76971 2 108322 4 184 5 17195 9 873 19 152114
По резервному:
1 38262 2 47658 5 7840 9 1602 19 125210
1 User Request 2 Lost Carrier 4 Idle Timeout 5 Session Timeout 9 NAS Error 19 Power OFF-ON
-
У нас pptp в основном
-
Посмотрел статистику завершения сессий клиентов, пришел к медленному офигеванию.
Нормальное завершение по User Request менее трети, остальное чаще всего код завершения соединения 19 .
Поискал в гугле, нашел rfc3580 где оно упоминается:
A Supplicant Restart (19) termination cause indicates
re-initialization of the Supplicant state machines.
В логах linux -а пишут Modem hangup и все.
Отловить tcpdump -ом достаточно проблематично, клиентов дофига, трафик большой.
Больше как бы ничего.
Соответсвенно, я так дддумаю, что это ненормальная ситуация, и хотелось бы ее порешать.
Вопрос: как ?
-
Нужна циска, под следующие задачи:
1) 2 канала в инет по 250 мбит, через полгода ожидается два по 500. bgp есессно.
2) должна трафик по netflow отдавать на соседний сервер.
3) должна уметь шейпить примерно 300 юриков...
4) аксесслисты ... основных два примерно по 20 строк. через них идет 90% трафика.
5) не знаю важно или нет около 200 vlan-ов.
6) туннели, около 20-30 штук. До удаленного оборудования, чтобы сеть была единая. трафик по ним идет небольшой.
Вроде бы как подходит циски серий 7200 7300, но знакомый который с ними работал говорит, что по netflow она трафик отдавать не может, в таком колличестве, загибается.
-
Неа, коннекты с такой строчкой не рвутся.
-
Есть сервер pptp, работает, все хорошо.
Иногда, от подключившихся клиентов (Виста и Виндовс 7, в ХР такого не наблюдается, хотяяяя...) прилетает такой пакет:
ICMP 192.168.52.26 protocol 47 unreachable, length
Сервер пишет в логи:
Dec 13 04:41:25 LinuxVPNr4 pppd[8735]: Modem hangup
И соединение закрывает.
Борюсь с этим вот так:
iptables -I INPUT -i eth0 -p icmp --icmp-type protocol-unreachable -j DROP
Но, по моему, это не есть замечательно.
А с чего оно вообще прилетает то ?
-
На новом ядре accel-pptp-0.8.3 не собирается...
Ладно, попробую поставить сервер паралельно старому, и постепенно подниму нагрузку на нем до 300 соединений... И погляжу, чего в нем отказывает... Надеюсь увижу...
-
Опубликовано · Изменено пользователем elias292 · Жалоба на ответ
Ядро
на старом 2.6.28.8
на новом 2.6.29.6
Последнее 2.6.32 щас обновлю... заодно oprofile поставлю...
-
eth0 Link encap:Ethernet HWaddr 00:15:17:28:b7:f4
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1719647869 errors:0 dropped:1424841 overruns:0 frame:0
TX packets:1889024383 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:753043078517 (701.3 GiB) TX bytes:1653824498856 (1.5 TiB)
С чего бывает: dropped:1424841
Ситуация анекдотична, есть сервер, на интеловой матери (S3000) и Core Quad Q9650 на нем стоит pptp и шейпинг, когда более 800 клиентов начинает подтормаживать.
Купили новый сервер на базе S5000PSSATAR, 2х Xenon 5410A. Перенесли систему со старого на новый, обновил драйвера для сетевух...
Кстати, на старом одна сетевая e1000-8.0.6 вторая e1000e-0.5.11.2
На новом обе: e1000e-1.1.2
Компилилось на старом с такими параметрами:
export CFLAGS_EXTRA='-DCONFIG_E1000E_SEPARATE_TX_HANDLER -DDISABLE_PCI_MSI'
На новом:
export CFLAGS_EXTRA='-DCONFIG_E1000E_SEPARATE_TX_HANDLER'
Поскольку мне показалось -DDISABLE_PCI_MSI не надо.
В общем сервер просто дохнет при 500 клиентах. Совсем.
Начинается большая потеря пакетов, всё уходит в dropped:1424841
Заодно выяснил, что 1000 правил iptables это кирдык старому серверу, а вот если их сократить до 200, то он нормально и без тормозов 1000 клиентов держит.
-
Есть два pc-роутера на линуксе.
Они видят друг друга двумя разными путями.
Можно ли создать один виртуальный канал с PPP Multilink чтобы были использованы оба пути?
А собственнно: как ?
А пример скажите... Если не жалко.
-
бугога... Вот это мне понравилось:
>если же сервер - ещё и NAS для PPTP, то там ведь получается по отдельному
>интерфейсу на пользователя - в этом случае шейпим на интерфейсе pppX да и всё,
>не надо таких сложностей.
Написано много чего _до_ потом говорится это все фигня, надо делать по другому, намного проще.
Но как проще не написано...
У меня сейчас сделано так:
/sbin/tc qdisc add dev $PPP root tbf rate ${speed}bit latency 5ms burst $BURST
tbf на htb не меняется, tbf про ceil не знает.
Хотя идея понятна, буду копать...
-
Опубликовано · Изменено пользователем elias292 · Жалоба на ответ
СПАСИБО! Щас почитаю вдумчиво.
Кстати поставил accel-pptp-0.8.3 сервер загнулся при 800 соединениях. (Load average подскочило до 110, у меня на это скрипт написан, и сервер сам перегрузился, после чего, было около 700 соединений, и не тормозило, трафик такой же.)
Уменьшил колличество правил iptables примерно в двое, он на это вообще не отреагировал. Никак.
-
Хм, не...
С iptables тоже не понимаю как сделать ...
-
а 600 это много ?
iptables переделаю завтра,
как это сделать у tc не представляю.
-
Опубликовано · Изменено пользователем elias292 · Жалоба на ответ
В принципе оно скомпиленное висит, просто мне премию дали когда оно неделю без зависания проработало, а щас оно уже 74 дня работает без больших проблем (я к тому что перегружать не хочу, а без этого неизвестно поднимется оно самостоятельно или вдруг чего забыл в стартовые скрипты написать).
Тут еще вот какая проблема:
Я делаю так:
tc qdisc del dev eth0 root
tc qdisc add dev eth0 root handle 2 htb default 1
tc class add dev eth0 parent 2: classid 2:6 htb rate 1000mbit
tc qdisc del dev eth4 root
tc qdisc add dev eth4 root handle 2 htb default 1
tc class add dev eth4 parent 2: classid 2:6 htb rate 1000mbit
На eth4 у меня в двух vlan-ах висит уходящий трафик который шейпится примерно так:
iptables -t mangle -I FORWARD -i ppp$N -j MARK --set-mark 0x1$N
/sbin/tc class add dev eth4 parent 2:6 classid 2:1$N htb rate ${speed}bit burst 1k
/sbin/tc qdisc add dev eth4 parent 2:1$N htb
/sbin/tc filter add dev eth4 parent 2: protocol ip prio 3 handle 0x1$N fw classid 2:1$N
А на eth0 у меня висит уходящий к клиентам трафик, который шейпится по простому:
/sbin/tc qdisc add dev ppp$N root tbf rate ${speed}bit latency 5ms burst $BURST
Вообще говоря, мне кажется, что проблемы начались, когда сумма ${speed}bit по всем пользователям перевалила за 1Г. Может стоит разбросать уходящий на клиентов трафик на большее колличество сетевых карт ?
-
Опубликовано · Изменено пользователем elias292 · Жалоба на ответ
1) accel нет. Чета не кажется, что он сильно поможет. Не в нем дело... Да и, говорят, подвисает оно.
2) Нет, за этим слежу. Не подвисают. Очень редко. Да, при этом становится еще хуже, но есть кучка скриптов, которые это все отслеживают и отстреливают.
-
Есть сервер. На базе какой-то серверной материнки от Intel, проц CPU Intel Core 2 Quad Q9650
На борту две гигабитные сетевухи. Одна отдельно (pci-x есессно):
00:19.0 Ethernet controller: Intel Corporation 82566DM-2 Gigabit Network Connection (rev 02)
01:00.0 Ethernet controller: Intel Corporation 82572EI Gigabit Ethernet Controller (Copper) (rev 06)
04:02.0 Ethernet controller: Intel Corporation 82541GI Gigabit Ethernet Controller (rev 05)
drivers e1000e-0.5.11.2
Компилил его с бубном, помнится ставил там ограничение в 3000 (или 8000 ?) прерываний. А то он захлебывался, и падал.
Щас не падает, но, временами, бывает, около часа-полутора в день, не может обеспечить скорость upload-а, хотя внешние каналы (два по 100 мбит) на аплоад свободны, на скачку в это время забиты.
Если верить такой программе как munin, в это время растет колличество Resheduling interrupts
Колличество прерываний на сетевухах уменьшается, до нуля.
Сам VPN занимается шейпингом, и натит трафик. Последнее время переделал что трафик он отдает прямо в локальную сеть, напрямую, ибо циска не справлялась с нагрузкой.
Колличество пользователей около 600-700 в это время.
Не могу понять чего в нем тормозит и не справляется.
Как это определить ?
-
Я знал!
Я знал что все просто.
Что странно, от рута я его тоже запускал. И нифига не получалось.
добавил --enable-tcp-zebra - заработало. Зато теперь проц грузится на 40%. было менее 10%.
-
Опубликовано · Изменено пользователем elias292 · Жалоба на ответ
Чета я ниччего не понимаю, поискал по инету, такого не нашел.
В общем, что делал:
Есть линукс slackware64 (slamd64-current)
поставил quagga-0.98.6 (пробовал quagga-0.99.15, аналогично)
Мда... Как бы это объяснить...
В общем, есть циска 3845, и есть два провайдера, есть bgp, настроено, работает.
Поставил еще один роутер в нашу же AS, которой щас 3845 рулит единолично, на базе линукса, поставил на него квагу, роутер видит напрямую через свич только одного провайдера, и второго через циску.
Он получает маршруты от обоих.
в bgpd по sh ip bgp это видно
захожу в zebra смотрю там: sh ip route bgp и вижу пустоту.
Как они вообще общаться то должны?
И почему не видять друг друга? А как проверить видят или нет?
логи выкручивал на максимум, ничего особенного там нет, ошибки не упоминаются, про то что bgpd пытается что-то в zebra впихнуть не пишется, что у него чего-то там не получается тоже нету ничего.
Перепробовал много чего, описывать долго, и перекомпилить, и конфиги поменять, написать заново, в общем чето мелкое я упускаю.
Как заставить pppoe сервер игнорировать запросы с пустым сервиснеймом
в Программное обеспечение, биллинг и *unix системы
Опубликовано · Жалоба на ответ
Комментировать надо не только там, но еще тут:
//ok = 1; /* Default service requested */
Но вообще, прикольная это штука, pppoe, т.е. если клиент запрашивает любой Service Name мой сервер все равно на него ответит, но укажет свой, и уже сам клиент должен решить будет ли он подключатся или как.
мда.