The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Ассиметрия трафика"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Маршрутизаторы CISCO и др. оборудование. (Разное)
Изначальное сообщение [ Отслеживать ]

"Ассиметрия трафика"  +/
Сообщение от maxnetstat (ok), 10-Мрт-20, 20:52 
Добрый день, форумчане!

Требуется ваша помощь в таком вопросе:
Ассиметрия TCP трафика на вход и исход.

Дано:
1. Сервер в России (Сервер А)
На сервер дается канал 1Гбит/с без каких-либо ограничений.
Установлен Debian 9.

2. Удаленный сервер в Германии на площадке у крупного провайдера (Сервер B).
На сервер дается канал 1Гбит/с без каких-либо ограничений.
ОС Linux, дистрибутив и версия ядра неизвестна.

Трасса между серверами в обе стороны одинакова.

Требуется:
Получить между серверами А и B максимально возможный канал связи по ширине.


(А -> B) с помощью iperf3 получаем в один поток 700-900 Мбит/с.
(B -> A) с помощью iperf3 получаем в один поток 35-50 Мбит/с.

Если использовать несколько потоков (около 20), то канал (B -> A) можно загрузить до 500 Мбит/с,
в один же поток в пиках до 70 Мбит/с.
Кроме того, первые несколько порций данных передавались со скоростью выше 100Мбит/с, затем скорость падала.


С обеих сторон менялись сервера (помогали провайдеры), использовались и сервера с подключением 10 Гбит/с, и обычные ПК. Во всех случаях результат был одинаковым, как описан выше.

Внутри сети провайдера в Германии и России с помощью iperf получали между серверами симметричные 900Мбит/с.

На мой взгляд проблема выглядит либо как работа шейпера, либо проблема с очередями или размером TCP окна со стороны сервера в России.
Но, непонятно, как в этом случае получали почти полный  1Гбит/с между нашим сервером и сервером провайдера.

Пробовали настраивать размер очереди на сетевом интерфейсе, увеличивали размер TCP окна - совершенно безрезультатно. Единственный "результат" получили, когда запретили динамически увеличивать окно  - получили на канале 15 Мбит/с вместо уже привычных 50.


Буду благодарен за советы.


Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | RSS]


1. "Ассиметрия трафика"  +/
Сообщение от Ann None (?), 10-Мрт-20, 22:24 
Пробовали сделать аналогичные тесты с сервером на третьей площадке?
Направление трафика уточните. iperf по умолчанию меряет исходящий трафик.
Была подобная ситуация, в результате разборов на стороне российской площадки корректировали маршрут.
Ответить | Правка | Наверх | Cообщить модератору

2. "Ассиметрия трафика"  +/
Сообщение от maxnetstat (ok), 11-Мрт-20, 01:22 
> Пробовали сделать аналогичные тесты с сервером на третьей площадке?
> Направление трафика уточните. iperf по умолчанию меряет исходящий трафик.
> Была подобная ситуация, в результате разборов на стороне российской площадки корректировали
> маршрут.

не пробовали, т.к. не нашли где-то рядом работающий публичный iperf сервер, который мог бы дать 1Гбит/с.

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

Ответить | Правка | Наверх | Cообщить модератору

3. "Ассиметрия трафика"  +/
Сообщение от ACCA (ok), 11-Мрт-20, 02:05 
> (А -> B) с помощью iperf3 получаем в один поток 700-900 Мбит/с.
> (B -> A) с помощью iperf3 получаем в один поток 35-50 Мбит/с.

Возможно, какой-нибудь СОРМ работает.

Что значит "поток"?
Какой тест у iperf3? TCP? А на UDP что видно?

Если UDP не будет зажат, то есть вариант с WireGuard.

Ответить | Правка | Наверх | Cообщить модератору

4. "Ассиметрия трафика"  +/
Сообщение от maxnetstat (ok), 11-Мрт-20, 11:42 
>> (А -> B) с помощью iperf3 получаем в один поток 700-900 Мбит/с.
>> (B -> A) с помощью iperf3 получаем в один поток 35-50 Мбит/с.
> Возможно, какой-нибудь СОРМ работает.
> Что значит "поток"?
> Какой тест у iperf3? TCP? А на UDP что видно?
> Если UDP не будет зажат, то есть вариант с WireGuard.

Имею ввиду одну TCP сессию. Параметр -P позволяет запускать несколько потоков.
-P, --parallel n
number of parallel client streams to run

По умолчанию TCP.
UDP показывает много потерь в обе стороны.
Но ведь в одну сторону по TCP я получаю 900Мбит/с.

Вы имеете ввиду построить туннель и проверять в нем?

Ответить | Правка | Наверх | Cообщить модератору

5. "Ассиметрия трафика"  +/
Сообщение от ACCA (ok), 12-Мрт-20, 02:52 
> UDP показывает много потерь в обе стороны.
> Но ведь в одну сторону по TCP я получаю 900Мбит/с.

Ну, вот тебе и ответ. Потеря пакета уменьшает размер окна TCP. В одну сторону пакеты теряются чаще, потому и перекос. Гоняй тест UDP и тычь провайдера палкой, потерь не должно быть.

Ответить | Правка | Наверх | Cообщить модератору

6. "Ассиметрия трафика"  +/
Сообщение от maxnetstat (ok), 12-Мрт-20, 04:03 
>> UDP показывает много потерь в обе стороны.
>> Но ведь в одну сторону по TCP я получаю 900Мбит/с.
> Ну, вот тебе и ответ. Потеря пакета уменьшает размер окна TCP. В
> одну сторону пакеты теряются чаще, потому и перекос. Гоняй тест UDP
> и тычь провайдера палкой, потерь не должно быть.

Вы правы, но я что-то затупил и не дописал.
ICMP потери не показывает.
Даже при  -i 0.01 -s 1024 не увеличиваются задержки, пакеты не выпадают.
Вот этим ситуация и странная.
UDP потери показывает на bandwidth > 70Мбит/с. До ~70 проблем нет.
Между мной и провайдером ни здесь ни там потерь и задержек нет.
Между мной и провайдером и там и там iperf показывает полный канал.
Между core маршрутизаторами провайдеров также iperf показывает полный канал в 1Гбит/с.

Попробуем еще UDP  погонять и сравнить результаты без потерь для UDP и максимальные для TCP.

Ответить | Правка | Наверх | Cообщить модератору

7. "Ассиметрия трафика"  +/
Сообщение от Pahanivo (ok), 12-Мрт-20, 10:43 
Мммм через РТК не ходит случаем?

Ответить | Правка | Наверх | Cообщить модератору

8. "Ассиметрия трафика"  +/
Сообщение от maxnetstat (ok), 12-Мрт-20, 12:57 
> Мммм через РТК не ходит случаем?

расшифруйте, пожалуйста.

Ответить | Правка | Наверх | Cообщить модератору

9. "Ассиметрия трафика"  +/
Сообщение от Pahanivo (ok), 12-Мрт-20, 13:13 
> расшифруйте, пожалуйста.

ростелеком

Ответить | Правка | Наверх | Cообщить модератору

10. "Ассиметрия трафика"  +/
Сообщение от maxnetstat (ok), 12-Мрт-20, 13:21 
>> расшифруйте, пожалуйста.
> ростелеком

Нет)

Ответить | Правка | Наверх | Cообщить модератору

12. "Ассиметрия трафика"  +/
Сообщение от Pahanivo (ok), 13-Мрт-20, 08:16 
> Нет)

трейс покажи

Ответить | Правка | Наверх | Cообщить модератору

11. "Ассиметрия трафика"  +/
Сообщение от ACCA (ok), 13-Мрт-20, 06:41 
> Вот этим ситуация и странная.
> UDP потери показывает на bandwidth > 70Мбит/с. До ~70 проблем нет.

Формально зацепись за этот параметр, чтобы прессовать провайдера. А с xyя ли? Что это ещё за дискриминация в нарушение RFC?

Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

13. "Ассиметрия трафика"  +/
Сообщение от Garriemail (?), 13-Мрт-20, 11:48 
>> (А -> B) с помощью iperf3 получаем в один поток 700-900 Мбит/с.
>> (B -> A) с помощью iperf3 получаем в один поток 35-50 Мбит/с.
> Возможно, какой-нибудь СОРМ работает.
> Что значит "поток"?
> Какой тест у iperf3? TCP? А на UDP что видно?
> Если UDP не будет зажат, то есть вариант с WireGuard.

Сорм получает данные по port-mirroring что никак не должно влиять.

Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру