elias292

Комментировать надо не только там, но еще тут: //ok = 1; /* Default service requested */ Но вообще, прикольная это штука, pppoe, т.е. если клиент запрашивает любой Service Name мой сервер все равно на него ответит, но укажет свой, и уже сам клиент должен решить будет ли он подключатся или как. мда.

И клиент получит ошибку 691, хотя всего-то надо, чтобы тестовый НАС не отвечал на запросы. Уже убрал, но я же сказал чего мне надо.

все клиенты не заморачиваются с сервиснеймом, и запрашивают пустой. т.е. первый же pppoe сервер попытается их подключить. авторизация через радиус, и еще с билинга скрипты запускаются, которые лезут на NAS сервер и чего-то пытаются подправить. Уже когда клиент подключился. Я ж говорю, человек до меня был с фантазией. т.е. вот оно подключило клиента, авторизовало его, а потом с биллинга влезает скрипт и на интерфйсе клиента правит скорость. Есессно, мой сервер таких вольностей не позволяет, и скорость не выставляется. Пока разберусь хотелось бы, чтобы он пускал в себя только тех, кто сказал правильное service name, в смысле тестовое.

Да да! Я тоже так думал, НО: -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 Ну или таймаут какой сделать, но это не очень хорошо.

У меня так, за ноябрь: По основному биллингу: 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 соединений... И погляжу, чего в нем отказывает... Надеюсь увижу...

Ядро на старом 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 чтобы были использованы оба пути? А собственнно: как ? А пример скажите... Если не жалко.