[agent2011]

Всем привет.

 

Имеем сервер доступа на Дебиане.

 

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

 

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

 

В чем может быть проблема?!

 

Мосты на на микротике LHG 5 XL.

Про настройку микротика можно не писать, работают в полосе 40 мгц, прокачивают в неполном дуплексе по 180 мегабит. из за ограничений портов в 100 мегабит - максимум естественно и видим эти 100 мегабит, они прилетают без проблем.

 

Мне хотелось бы подчеркнуть, что скорость режется только до своего сервера. До других проблем нет.

[Saab95]

Наверное они просто неким образом подключены, или трафик ходит так, что 2 раза попадает под шейпер.

[agent2011]

3 часа назад, Saab95 сказал:

Наверное они просто неким образом подключены, или трафик ходит так, что 2 раза попадает под шейпер.

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

 

используем полисер ipt-ratelimit

 

не посоветуете что нибудь?

 

такое впечатление, что входящий как буд-то по второму кругу где-то проходит :-)

Изменено 1 февраля, 2020 пользователем agent2011

[Saab95]

Ну можно посоветовать проверить где и как он ходит. Например посчитать ttl, сделать трейс - тут же второй узел по второму кругу должно показать. Если не показывает, возможно где-то по Л2 прокручивается.

 

Возможно надо посмотреть каким образом беспроводные клиенты подключены, или чем их подключение отличается от остальных. Если там PPPoE туннели - посмотреть не попадают ли они на раздачу.

Но самое правильное тут выделить всю беспроводку на отдельное устройство и там уже их терминировать, а после пускать в том же виде, что и трафик основных абонентов. Так отследить проще.

[agent2011]

11 часов назад, Saab95 сказал:

Ну можно посоветовать проверить где и как он ходит. Например посчитать ttl, сделать трейс - тут же второй узел по второму кругу должно показать. Если не показывает, возможно где-то по Л2 прокручивается.

 

Возможно надо посмотреть каким образом беспроводные клиенты подключены, или чем их подключение отличается от остальных. Если там PPPoE туннели - посмотреть не попадают ли они на раздачу.

Но самое правильное тут выделить всю беспроводку на отдельное устройство и там уже их терминировать, а после пускать в том же виде, что и трафик основных абонентов. Так отследить проще.

Да, действительно, проблема касается только тех, кто подключен по PPPoE.

У нас работает accel-ppp.

 

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

как-то несколько месяцев назад я писал в теме accel-ppp о данной проблеме, но ответа так и не последовало.

 

Теперь ясно, что проблема как-то связанна с туннелями или accel-ppp.

 

Пните меня дальше пожалуйста :-)

 

UPD:

Прикрепляю скрин трацерта (PPPoE).

Первый ip самого accel-ppp.

Второй - ip шлюза вышестоящего на аплинк интерфейсе.

 

Второй скрин уже без PPPoE, тоже самое, меняется только адрес шлюза нашего.

 

Разница лишь в том, что eth1 интерфейс у нас имеет адрес 10.20.0.1

а accel-ppp создает для себя отдельный 10.30.254.254

 

 

 

Что касаемо маршрутизации, при тестировании спидтестом (до своей ноды) и в том и другом случае трафик не идет через аплинк интерфейс. Во всяком случае смотря в реальном режиме vnstat ом этого не видно.

То есть трафик остается внутри своей сети.

Изменено 2 февраля, 2020 пользователем agent2011

[Saab95]

Надо сравнивать трейсы клиента прямого и клиента в туннеле. Выходит получается лишний хоп в трейсе. Значит под ограничение скорости попадает и трафик по этому хопу - видимо не верно настроен шейпер.

 

Именно по этому я всегда советую ставить 2 или 3 микротика, допустим:

1. Делает НАТ и блокирует абонентов.

2. Режет скорость (шейпер).

3. Прием PPPoE клиентов.

 

Соответственно схема подключения к 1 подключен 2, к 2 подключены каналы от абонентов. Так же к 2 подключен 3 и на него идут каналы с туннелями. Т.к. устройство 2 только ограничивает скорость трафика, никаких задвоений быть не может.

 

Но если у вас устаканена схема, то, нужно посмотреть как работает шейпер. Можно ли для него сделать исключение трафика. И если можно, то надо неким опытным путем, обнаружить направление трафика с туннелей и исключить его из ограничений.

 

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

[vurd]

1. Проблема, есть лишний мткротик на складе микротиков.

2. Мутная проблема со скоростью в абонентов с терминацией в тунелле (с пониженным мту, кстати. ни на что не намекаю).

3. Придумаем двойной проход трафика.

4. Можно продать ещё микротик.

 

ТС, какие показатели получаются на тарифе 20 мегабит при обоих типах терминации на вашем сервере? Какие показатели они же получают на чужом сервере?

[agent2011]

Проблему по спидтесту с беспроводными решили :-)

проблему с общей производительностью PPPoE - нет.

 

Все оказалось куда банальнее, дело было в:

Скрытый текст

sudo autorps eth0 --force
sudo autorps eth1 --force

 

сделали с флагом

sudo autorps eth0 -с 6 --force
sudo autorps eth1 -с 6 --force

 

все стало на свои места в плане беспроводного спидтеста, стало выжимать по максимому.

 

Но, что касаемо общей производительность PPPoE, даже по кабелю, видим двойное различие.

Не хочу всех запутывать, но различие по скорости есть и на проводе все же:

На том же 2ip или спидтесте - мы не можем поднятья выше 500 мегабит по входящему, по исходящему 900 можно увидеть.

Интересно, что на торрентах выше 30 мегабайт я не видел никогда, и то с натяжкой, в основном скорость колеблется в районе 20-25.

 

Еще один момент, запуская speedtest-cli на сервере доступа, я вижу тоже разрыв в два раза (проверка до нашей ноды, которая на этом же сервере):

Testing download speed................................................................................
Download: 2959.72 Mbit/s
Testing upload speed................................................................................................
Upload: 1485.37 Mbit/s

 

Сегодня еще попробуем напрямую к аплинку подсоединится, без сервера доступа и посмотреть, что будет. Может по входящему аплинк что-то подрезает.

 

Вопрос по autorps. в man про ключ -c - пишут про CPUs, за что отвечает этот ключ? за ядра или процессоры? :-)

у нас двухпроцессорный сервер доступа, два процессора по 6 ядер.

 

и каким образом для нашей конфигурации нужно прописывать данную команду?

 

просто:

sudo autorps eth0 -с 6 --force
sudo autorps eth1 -с 6 --force

или например:

sudo autorps eth0 -с 0 --force
sudo autorps eth1 -с 0 --force
sudo autorps eth0 -с 1 --force
sudo autorps eth1 -с 1 --force
sudo autorps eth0 -с 2 --force
sudo autorps eth1 -с 2 --force
sudo autorps eth0 -с 3 --force
sudo autorps eth1 -с 3 --force
sudo autorps eth0 -с 4 --force
sudo autorps eth1 -с 4 --force
sudo autorps eth0 -с 5 --force
sudo autorps eth1 -с 5 --force

 

 

[ixi]

Если правильно помню, то ядра и перечислять через пробел

[agent2011]

1 час назад, ixi сказал:

Если правильно помню, то ядра и перечислять через пробел

да, вы правы.

 

делается это командами:

sudo autorps eth0 --cpus 0 1 2 3 4 5 --force

sudo autorps eth1 --cpus 0 1 2 3 4 5 --force

 

и все же.

 

выполняя команду:

sudo autorps eth0 -с 6 --force

 

мы нагружаем какое-то одно ядро процессора, в этом случае к наша спидтест нода показывает нужный результат.

но из за этого естественно страдает вся сеть.

 

но все же если раскидать rps по правильному:

 

sudo autorps eth0 --cpus 0 1 2 3 4 5 --force

sudo autorps eth1 --cpus 0 1 2 3 4 5 --force

 

то снова скорость к спидтест ноде падает.

 

Зато сеть начинает работать так как нужно.

 

 

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

 

посмотрим как будет работать просто раскидав прерывания.

 

возможно выход еще один будет, перенос спидтест ноды на другой сервер)

Изменено 3 февраля, 2020 пользователем agent2011

[agent2011]

в общем проблему со спидтест нодой утресли, оказалось, что лучше вообще не делать autorps.

 

у кого какие идеи будут по поводу того, что скорость в два раза меньше у PPPoE клиентов?

Имею ввиду максимальную скорость.

 

Те кто заказал сотню по медному порту - сотню и получат.

А вот те кто например 500 метров хочет по PPPoE - не смогут.

Делаем замеры на одной проверочной машине, разница в два раза PPPoE и статика.

 

Может быть это можно считать нормальным?

Изменено 4 февраля, 2020 пользователем agent2011

[Ivan_83]

В 01.02.2020 в 11:10, agent2011 сказал:

В чем может быть проблема?!

В том что надо тюнить TCP/IP в линуксе, прописать тот же hybla в качестве cc, буфера увеличить, как завещал Сысов ещё 13 лет назад.

 

В 02.02.2020 в 02:23, agent2011 сказал:

Да, действительно, проблема касается только тех, кто подключен по PPPoE.

tcp mss fix - гуглить и заюзать.