ip rule и pppoe server

Всем привет.

Работает сервер доступа, часть абонентов получает доступ в Интернет средствами PPPoE сервера, другая часть средствами перегонки трафика с виртуальных интерфейсов с реальными ип адресами при помощи маршрутизации (отдельные таблицы маршрутизации iproute2 (rt_tables) и правила ip rule).
1 таблица и 1 правило на абонента

Заметили неприятную вещь, когда правила присутствуют - клиенты которые пытаются подключится по PPPoE - долго подключаются, в вечернее время бывает что у них выскакивает 734 и другие ошибки...
При постепенном удалении правил - ситуация улучшается, когда удаляешь все правила - всё подключается за секунду.

С правилами всё нормально, ничего лишнего. Чувствуем, что где-то чего-то не хватает, может быть по ресурсам или настройкам.

Если нужно покажем примерную конфигурацию правил маршрутизации и покажем схему.

Нужна помощь! всё работало прекрасно...не можем понять в чем дело.

tnega, а количество абонентов не выросло за последнее время?

Wolfenberg написал:

tnega, а количество абонентов не выросло за последнее время?

Выросло, процентов на 20, если не больше.
В сети примерно 600 абонентов, 50 из них PPPoE, остальные - правила ip rule/rt_tables вместе с виртуальными интерфейсами, то есть около 500-550 абонентов.

Чувствую, что засада в этом кроется.

Наверное придется переводить всех без исключения на PPPoE, работает он в режиме ядра.
Зато в будущем для нас "погибче" будет работать с сетью.

Офтоп:
Буквально весной была проблема с HTB, в локалке пинги до шлюза возросли, начал ковырять, оказалось не справляется.
Пробовал использовать хэши, но что-то не получилось настроить.

В итоге перешел на полисер ipt-ratelimit.

tnega, ну так а чего вы хотите? У вас растёт нагрузка на оборудование сообразно парку клиентов.
Делайте балансировку, расширяйте парк и т.п.

Wolfenberg написал:

tnega, ну так а чего вы хотите? У вас растёт нагрузка на оборудование сообразно парку клиентов.
Делайте балансировку, расширяйте парк и т.п.

Сервер доступа работает не напрягаясь судя по загрузке ЦП, загрузка по вечерам 30-40 %, и то нагружает её анализ и учёт трафика bandwidthd. Если бы не он - несколько процентов всего нагрузки.
Сервер двухпроцессорный, 8 ядер, Xeon E5440, прерывания i350-t2 сетевая карта, прерывания перераспределены на один процессор. 4 гига оперативка. из них используется только 384, голый дебиан.
contrack_max - повышен. кэш таблицы arp тоже.
600 абонентов, 500 мегабит трафика.
Я думаю, что для этого сервера это не предел.

Стали переводить всех на PPPoE сегодня, демон сервера завис к вечеру, пришлось перезагружать.
Смотрим как будет работать дальше...
Настроение так себе.

"tnega" написал:

демон сервера завис к вечеру

А что пишет в логах? Ведь процесс не может жить своей жизнью.

друзья. нужна помощь, еще одна проблема появилась.

Начали раскидывать подсети по VLANам.
Полностью перестраиваем сеть.

Один дом - 1 vlan + сегментация трафика (изоляция портов)
Коммутаторы на доступе D-Link 3028, в маленьких местах DIR-100F.

Интересная вещь выяснилась касаемо самого сервера доступа.

Например:
Делаем VLAN на сервере:

vconfig add eth1 32
ifconfig vlan32 10.30.32.254/24

запускаем pppoe-server на данном вилане в режиме ядра:
pppoe-server -I vlan32 -L 10.30.32.254 -O /etc/ppp/pppoe-server-options -k

Всё создается, Все видится, но проблема основная - РЕЖЕТСЯ СКОРОСТЬ. Примерно до 25 мегабит по исходящему и входящему.

Пробовали и напрямую без pppoe сервера, делать маршрутизацию на сервый ип адрес - без изменений.
Меняли оборудование, чую проблема кроется где-то в сервере доступа.

Как только переводим коммутатор в стандартный vlan1 - все встает на свои места.

Нид хелп!

:) Для начала я бы выкинул нафиг все DIR 100. Они хороши для времён ADSL были.
Далее - смотрите у себя правила сети на сервере. Есть IPv6? Если есть - то они и режут скорость.