Eltex NTP-RG-1402G

[Барагоз]

Схема подключения:

 

МТ1, МТ2 - соответственно, микротики (х86)

Элтекс - сабжевый. Провайдер РТ, подключение PPPoE. Терминал настроен роутером, 10.0.90.2 добавлен в DMZ.

Запускаем bandwidth test (для определенности TCP) с МТ1 до МТ2 на отдачу на белый IP терминала (a2.b2.c2.d2 на схеме) - получаем прокачку 270 Мбит/с (на UDP 440 Мбит/с, генерится около 40 kpps).

Запускаем bandwidth test с МТ1 до МТ2 на отдачу на туннельный IP МТ2 (10.1.90.2) - получаем прокачку максимум 50-55 Мбит/с (генерится 4-4,5 kpps) и при этом во время теста огребаем следующие явления:

- на пинге 1000 байт потери с МТ1 до белого IP терминала 20-30%, до туннельного IP МТ2 аналогичные

- на пинге 1000 байт потери с МТ2 до физического интерфейса терминала 10.0.90.1 2-3% с чудовищной вариацией (1-60 мс). Физически между МТ2 и терминалом медный патчкорд 0,5м.

Непонятно...

Допустим, дохнет ЦП в терминале. Но почему он не загибается при tcp трафике, валящем на реальник? Точно так же отправляет по адресу DMZ, какая терминалу разница, что внутри пакета?

 

На всякий случай: MTU в туннеле 1460, на обоих концах туннеля делается clamp MSS to PMTU.

Загрузка ЦП МТ2 при тестах - 20-30%.

Призываются гуру и телепаты. В чем причина и как добиться прокачки через туннель сравнимой с результатами по реальникам?

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

 

PS настроить в бридж не предлагать - по Tr069 приходят настройки от провайдера. Админского доступа к терминалу нет :(

Edited March 8, 2017 by Барагоз

[[anp/hsw]]

Ну теперь осталось поменять ipip на какой-нибудь tcp-openvpn и померять скорость.

Могу только предположить, что на той стороне есть QoS с раскраской и ipip (и все остальное "непонятное") красится в низкоприоритетный класс.

А еще есть такая штука как HW NAT offload. Так вот для tcp/udp он вполне может быть, но вот для IPIP его точно никто не станет писать за невостребованностью в массах.

[Барагоз]

' timestamp='1488963832' post=1380785]

Могу только предположить, что на той стороне есть QoS с раскраской и ipip (и все остальное "непонятное") красится в низкоприоритетный класс.

На стороне оператора или тупо в модеме?

Есть в моем ведении точки на РТ, где модем сугубо бриджовый - такой проблемы нет. Хотя там и OLT/ONU у них не элтекс, а алкатель.

Меня удивляет, что при тесте через туннель катастрофически ухудшается связь со стороны LAN до терминала.

TCP туннель ночью попробую, да...

Edited March 8, 2017 by Барагоз

[[anp/hsw]]

На стороне оператора или тупо в модеме?

На стороне оператора.

 

Есть в моем ведении точки на РТ, где модем сугубо бриджовый - такой проблемы нет. Хотя там и OLT/ONU у них не элтекс, а алкатель.

Элтекс в бридже будет ничем не хуже в этом плане.

 

Меня удивляет, что при тесте через туннель катастрофически ухудшается связь со стороны LAN до терминала.

Перегрузка CPU как вариант. Запустить top, и смотреть, что там происходит.

[closed]

Допустим, дохнет ЦП в терминале. Но почему он не загибается при tcp трафике, валящем на реальник? Точно так же отправляет по адресу DMZ, какая терминалу разница, что внутри пакета?

разница очень большая, потому что броадкомовский чип внутре модема умеет хардварную акселерацию tcp трафика и качает его сколько хошь. а ipip не умеет, и он пролетает через цпу. 50мбит для цпу это потолок, выше не сделаешь. от загрузки цпу страдает вообще все

решение - либо tcp/udp туннель (openvpn, etc), либо просить провайдера настроить бриджом, тогда модем не будет лазить глубоко в пакет

[Барагоз]

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

Остается ограничение на стороне оператора?

[[anp/hsw]]

Остается ограничение на стороне оператора?

Тип бриджа поменяйте. IPIP, GRE, IPSEC/UDP. Какой-то да пролезет нормально.

[Барагоз]

[anp/hsw], тип туннеля имеете в виду? пробовал IPIP, EoIP. Openvpn на микротике не выходит одолеть, увы) GRE попробую...