Устранение неполадок низкой пропускной способности Metro Ethernet TCP

14

Настройка

Мы арендовали несколько выделенных линий, которые представляют собой сеть уровня 2, т.е. у вас есть один большой канал в центре обработки данных, а на удаленных площадках - меньшие каналы. Внутри сети уровня 2 вы можете делать все что угодно. Вероятно, они используют 802.1ad, чтобы предоставить каждому клиенту отдельную сеть внутри своей сети. AFAICS большинство сайтов подключены через простой VDSL.

Мы решили установить маршрутизатор на каждом сайте и предоставить каждому сайту свою собственную VLAN. Брандмауэр на DC, таким образом, имеет столько VLAN, сколько есть сайтов. Таким образом, каждый сайт использует свой диапазон адресов в своей собственной VLAN.

Диаграмма сети:

Диаграмма сети

Проблема

Теперь мы столкнулись с проблемами пропускной способности:

  • Выполнение передачи по FTP с сайта на DC работает нормально со скоростью около 10 Мбит / с, что является скоростью линии.
  • Выполнение FTP-передачи с DC на сайт не работает нормально на скорости 6 Мбит / с или менее.

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

Через 10 секунд после передачи пропускная способность падает. Мы видим DUP ACK при нюхании. Что может привести меня к ограничению скорости в конце провайдера? (В настоящее время они не имеют ни малейшего понятия, и я хотел бы убедиться, что мы не виноваты, прежде чем эскалация)

ПРИМЕЧАНИЕ. Количество удаленных сайтов ограничено 10 МБ. Установка переключения на Metro-порт на 10 МБ также не помогает. На самом деле это хуже всего (макс. 30 кб / с). Установка на 100 Мб работает нормально, но уже начинает приводить к намеченной проблеме. То же самое для 1G.

Захваты проблемы можно скачать здесь:

* http://178.63.11.6/dc-to-remote_dc-side.pcapng
* http://178.63.11.6/dc-to-remote_remote-side.pcapng

диагностика

На рисунке вы видите график ввода-вывода Wireshark с некоторыми деталями ошибки:

  • слева: передача по FTP с DC на сайт
  • справа: передача по FTP с сайта на DC

дубликаты

В случае, если другая сторона инициирует передачу (т.е. ставит из постоянного тока вместо получения из удаленного), проблема остается неизменной.

Пожалуйста, побалуйте меня тем, что, по вашему мнению, может быть проблемой здесь.

ОБНОВЛЕНИЕ № 1 (интегрировано выше)

ОБНОВЛЕНИЕ № 2 ( ОБНОВЛЕНО )

Это должно быть вещь контроля заторов.

Обратите внимание, что от постоянного тока до удаленного у нас есть 10G-> 1G-> 100M-> 10M-> 1G. <- не работает

В другом направлении мы имеем обратное: 1G-> 10M-> 100M-> 1G-> 10G. <- просто отлично

Первый «1G-> 10M» - это «невидимые» 10M на удаленном сайте, где все, включая скорость порта восходящей линии связи, установлено на 1G, даже если за ним остается только 10M (продается).

Однако 100 Мбит / с на DC являются реальными 100 Мбит / с, интерфейс настроен на 100 Мбит / с на физическом уровне.

Я сейчас использовал iperf:

  • Тесты TCP работают нормально только в одном направлении (клиент = DC, сервер = удаленный)
./iperf -c 192.168.x -i2 -t 60 -r
-------------------------------------------------- ----------
Сервер прослушивает TCP-порт 5001
Размер окна TCP: 85,3 КБ (по умолчанию)
-------------------------------------------------- ----------
-------------------------------------------------- ----------
Клиент подключается к 192.168.x, TCP-порт 5001
Размер окна TCP: 16,0 КБ (по умолчанию)
-------------------------------------------------- ----------
[3] локальный порт 10.x 38195, связанный с портом 5001 192.168.x
[3] 0,0-2,0 с 1,44 МБайт 6,03 Мбит / с
[3] 2,0-4,0 с 2,23 МБайт 9,37 Мбит / с
[3] 4,0-6,0 с 2,28 МБайт 9,57 Мбит / с
[3] 6,0-8,0 с 1,88 МБ 7,90 Мбит / с
[3] 8,0-10,0 с 1,00 МБайт 4,19 Мбит / с
[3] 10,0-12,0 с 1,30 МБайт 5,47 Мбит / с
[3] 12,0-14,0 с 688 КБайт 2,82 Мбит / с
[3] 14,0-16,0 с 840 КБайт 3,44 Мбит / с
[3] 16,0-18,0 с 1,03 МБайт 4,33 Мбит / с
[3] 18,0–20,0 с 1,01 МБайт 4,23 Мбит / с
[3] 20,0-22,0 с 1,03 МБайт 4,33 Мбит / с
[3] 22,0-24,0 с 1,18 МБайт 4,95 Мбит / с
[3] 24,0–26,0 с 904 КБайт 3,70 Мбит / с
[3] 26,0-28,0 с 840 КБайт 3,44 Мбит / с
[3] 28,0-30,0 с 936 КБайт 3,83 Мбит / с
[3] 30,0-32,0 с 1,09 МБайт 4,59 Мбит / с
[3] 32,0-34,0 с 960 КБайт 3,93 Мбит / с
[3] 34,0-36,0 с 752 КБ 3,08 Мбит / с
[3] 36,0-38,0 с 1,09 МБайт 4,59 Мбит / с
[3] 38,0-40,0 с 1,09 МБайт 4,59 Мбит / с
[3] 40,0-42,0 с 840 КБайт 3,44 Мбит / с
[3] 42,0-44,0 с 1,27 МБайт 5,34 Мбит / с
[3] 44,0-46,0 с 1,16 МБайт 4,85 Мбит / с
[3] 46,0-48,0 с 840 КБайт 3,44 Мбит / с
[3] 48,0-50,0 с 960 КБайт 3,93 Мбит / с
[3] 50,0-52,0 с 1,28 МБайт 5,37 Мбит / с
[3] 52,0-54,0 с 1,09 МБайт 4,59 Мбит / с
[3] 54,0-56,0 с 992 КБайт 4,06 Мбит / с
[3] 56,0-58,0 с 1,00 МБайт 4,19 Мбит / с
[3] 58,0-60,0 с 1,09 МБайт 4,59 Мбит / с
[3] 0,0-60,2 с 33,9 МБайт 4,73 Мбит / с
[5] локальный 10.x порт 5001, связанный с 192.168.x портом 10965
[5] 0,0-2,0 с 1,85 МБайт 7,75 Мбит / с
[5] 2,0-4,0 с 1,90 МБайт 7,98 Мбит / с
[5] 4,0-6,0 с 1,89 МБайт 7,93 Мбит / с
[5] 6,0-8,0 с 1,92 МБайт 8,07 Мбит / с
[5] 8,0-10,0 с 1,91 МБайт 8,02 Мбит / с
[5] 10,0-12,0 с 1,83 МБайт 7,69 Мбит / с
[5] 12,0-14,0 с 1,86 МБайт 7,78 Мбит / с
[5] 14,0-16,0 с 1,79 МБ 7,52 Мбит / с
[5] 16,0-18,0 с 1,79 МБ 7,52 Мбит / с
[5] 18,0-20,0 с 1,89 МБ 7,91 Мбит / с
[5] 20,0-22,0 с 1,91 МБайт 8,00 Мбит / с
[5] 22,0-24,0 с 1,88 МБ 7,91 Мбит / с
[5] 24,0-26,0 с 1,95 МБайт 8,16 Мбит / с
[5] 26,0-28,0 с 1,90 МБайт 7,99 Мбит / с
[5] 28,0-30,0 с 1,87 МБ 7,84 Мбит / с
[5] 30,0-32,0 с 1,85 МБ 7,77 Мбит / с
[5] 32,0-34,0 с 1,55 МБ 6,49 Мбит / с
[5] 34,0-36,0 с 1,92 МБайт 8,07 Мбит / с
[5] 36,0-38,0 с 1,90 МБайт 7,99 Мбит / с
[5] 38,0-40,0 с 1,84 МБ 7,73 Мбит / с
[5] 40,0-42,0 с 1,66 МБайт 6,95 Мбит / с
[5] 42,0-44,0 с 1,92 МБайт 8,07 Мбит / с
[5] 44,0-46,0 с 1,91 МБайт 7,99 Мбит / с
[5] 46,0-48,0 с 1,90 МБайт 7,98 Мбит / с
[5] 48,0-50,0 с 1,84 МБайт 7,70 Мбит / с
[5] 50,0-52,0 с 1,93 МБайт 8,09 Мбит / с
[5] 52,0-54,0 с 1,80 МБ 7,54 Мбит / с
[5] 54,0-56,0 с 1,83 МБайт 7,67 Мбит / с
[5] 56,0-58,0 с 1,88 МБайт 7,86 Мбит / с
[5] 58,0-60,0 с 1,85 МБ 7,78 Мбит / с
[5] 0,0-60,3 с 56,0 МБайт 7,79 Мбит / с
  • Чтобы разобраться в этом, вот тесты UDP от двух хостов в одной VLAN, но с использованием Metro Connection, 200 = удаленный, 201 = DC

Мы видим, что потеря пакетов увеличивается с увеличением пропускной способности (когда мы приближаемся к 10 Мбит / с, у нас 0,93%, это становится критическим ... и также объясняет, почему у TCP проблемы с производительностью)

++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++
C: \ iperf-2.0.5-2-win32> iperf -c 192.168.191.200 -i 1 -t 20 -r -u
++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++
-------------------------------------------------- ----------
Сервер прослушивает UDP-порт 5001
Получение 1470 байт дейтаграмм
Размер буфера UDP: 64,0 КБ (по умолчанию)
-------------------------------------------------- ----------
-------------------------------------------------- ----------
Клиент подключается к 192.168.191.200, порт UDP 5001
Отправка 1470 байт дейтаграмм
Размер буфера UDP: 64,0 КБ (по умолчанию)
-------------------------------------------------- ----------
[4] локальный 192.168.191.201 порт 61759, связанный с 192.168.191.200 портом 5001
[ID] Интервал передачи
[4] 0,0-1,0 с 128 КБайт 1,05 Мбит / с
[4] 1,0-2,0 с 128 КБайт 1,05 Мбит / с
[4] 2,0-3,0 с 129 КБайт 1,06 Мбит / с
[4] 3,0-4,0 с 128 КБайт 1,05 Мбит / с
[4] 4,0-5,0 с 128 КБ 1,05 Мбит / с
[4] 5,0-6,0 с 128 КБ 1,05 Мбит / с
[4] 6,0-7,0 с 128 КБ 1,05 Мбит / с
[4] 7,0-8,0 с 128 КБ 1,05 Мбит / с
[4] 8,0-9,0 с 128 КБ 1,05 Мбит / с
[4] 9,0-10,0 с 129 КБайт 1,06 Мбит / с
[4] 10,0-11,0 с 128 КБ 1,05 Мбит / с
[4] 11,0-12,0 с 128 КБайт 1,05 Мбит / с
[4] 12,0-13,0 с 128 КБ 1,05 Мбит / с
[4] 13,0-14,0 с 128 КБ 1,05 Мбит / с
[4] 14,0-15,0 с 128 КБ 1,05 Мбит / с
[4] 15,0-16,0 с 128 КБ 1,05 Мбит / с
[4] 16,0-17,0 с 128 КБ 1,05 Мбит / с
[4] 17,0-18,0 с 128 КБ 1,05 Мбит / с
[4] 18,0-19,0 ​​с 131 КБ 1,07 Мбит / с
[4] 19,0-20,0 с 128 КБ 1,05 Мбит / с
[4] 0,0-20,0 с 2,50 МБайт 1,05 Мбит / с
[4] Отправлено 1785 дейтаграмм.
[4] Отчет сервера:
[4] 0,0-20,0 с 2,50 МБайт 1,05 Мбит / с 0,257 мс 0/1785 (0%)
[3] локальный 192.168.191.201 порт 5001, соединенный с 192.168.191.200 портом 50749
[3] 0,0-1,0 с 128 КБайт 1,05 Мбит / с 0,285 мс 0/89 (0%)
[3] 1,0-2,0 с 128 КБайт 1,05 Мбит / с 0,313 мс 0/89 (0%)
[3] 2,0-3,0 с 128 КБайт 1,05 Мбит / с 0,278 мс 0/89 (0%)
[3] 3,0-4,0 с 128 КБайт 1,05 Мбит / с 0,241 мс 0/89 (0%)
[3] 4,0-5,0 с 128 КБайт 1,05 Мбит / с 0,266 мс 0/89 (0%)
[3] 5,0-6,0 с 128 КБайт 1,05 Мбит / с 0,293 мс 0/89 (0%)
[3] 6,0-7,0 с 128 КБайт 1,05 Мбит / с 0,314 мс 0/89 (0%)
[3] 7,0-8,0 с 128 КБайт 1,05 Мбит / с 0,280 мс 0/89 (0%)
[3] 8,0-9,0 с 128 КБайт 1,05 Мбит / с 0,242 мс 0/89 (0%)
[3] 9,0-10,0 с 129 КБайт 1,06 Мбит / с 0,250 мс 0/90 (0%)
[3] 10,0-11,0 с 128 КБайт 1,05 Мбит / с 0,275 мс 0/89 (0%)
[3] 11,0-12,0 с 128 КБайт 1,05 Мбит / с 0,299 мс 0/89 (0%)
[3] 12,0-13,0 с 128 КБайт 1,05 Мбит / с 0,327 мс 0/89 (0%)
[3] 13,0-14,0 с 128 КБайт 1,05 Мбит / с 0,290 мс 0/89 (0%)
[3] 14,0-15,0 с 128 КБайт 1,05 Мбит / с 0,251 мс 0/89 (0%)
[3] 15,0-16,0 с 128 КБайт 1,05 Мбит / с 0,275 мс 0/89 (0%)
[3] 16,0-17,0 с 128 КБайт 1,05 Мбит / с 0,303 мс 0/89 (0%)
[3] 17,0-18,0 с 128 КБайт 1,05 Мбит / с 0,333 мс 0/89 (0%)
[3] 18,0-19,0 ​​с 128 КБайт 1,05 Мбит / с 0,294 мс 0/89 (0%)
[3] 19,0–20,0 с 131 КБайт 1,07 Мбит / с 0,281 мс 0/91 (0%)
[3] 0,0-20,0 с 2,50 МБайт 1,05 Мбит / с 0,305 мс 0/1785 (0%)

++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++
C: \ iperf-2.0.5-2-win32> iperf -c 192.168.191.200 -i 1 -t 20 -r -u -b 5м
++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++
-------------------------------------------------- ----------
Сервер прослушивает UDP-порт 5001
Получение 1470 байт дейтаграмм
Размер буфера UDP: 64,0 КБ (по умолчанию)
-------------------------------------------------- ----------
-------------------------------------------------- ----------
Клиент подключается к 192.168.191.200, порт UDP 5001
Отправка 1470 байт дейтаграмм
Размер буфера UDP: 64,0 КБ (по умолчанию)
-------------------------------------------------- ----------
[4] локальный порт 61760 192.168.191.201, связанный с портом 5001 192.168.191.200
[ID] Интервал передачи
[4] 0,0-1,0 с 610 КБайт 5,00 Мбит / с
[4] 1,0-2,0 с 609 КБайт 4,99 Мбит / с
[4] 2,0-3,0 с 610 КБайт 5,00 Мбит / с
[4] 3,0-4,0 с 609 КБайт 4,99 Мбит / с
[4] 4,0-5,0 с 610 КБайт 5,00 Мбит / с
[4] 5,0–6,0 с 609 КБайт 4,99 Мбит / с
[4] 6,0-7,0 с 610 КБайт 5,00 Мбит / с
[4] 7,0-8,0 с 609 КБайт 4,99 Мбит / с
[4] 8,0-9,0 с 610 КБайт 5,00 Мбит / с
[4] 9,0-10,0 с 619 КБайт 5,07 Мбит / с
[4] 10,0-11,0 с 610 КБайт 5,00 Мбит / с
[4] 11,0-12,0 с 609 КБайт 4,99 Мбит / с
[4] 12,0-13,0 с 609 КБайт 4,99 Мбит / с
[4] 13,0-14,0 с 610 КБайт 5,00 Мбит / с
[4] 14,0-15,0 с 609 КБайт 4,99 Мбит / с
[4] 15,0-16,0 с 610 КБайт 5,00 Мбит / с
[4] 16,0-17,0 с 609 КБайт 4,99 Мбит / с
[4] 17,0-18,0 с 610 КБайт 5,00 Мбит / с
[4] 18,0-19,0 ​​с 619 КБайт 5,07 Мбит / с
[4] 19,0–20,0 с 609 КБайт 4,99 Мбит / с
[4] 0,0-20,0 с 11,9 МБайт 5,00 Мбит / с
[4] Отправлено 8504 дейтаграмм.
[4] Отчет сервера:
[4] 0,0-20,0 с 11,9 МБайт 4,99 Мбит / с 0,000 мс 12/8503 (0,14%)
[4] 0,0-20,0 с 1 датаграмма получена не в порядке
[3] локальный порт 5001 192.168.191.201, соединенный с портом 50750 192.168.191.200
[3] 0,0-1,0 с 606 КБайт 4,96 Мбит / с 2,238 мс 1/423 (0,24%)
[3] 1,0-2,0 с 610 КБайт 5,00 Мбит / с 2,739 мс 0/425 (0%)
[3] 2,0-3,0 с 609 КБайт 4,99 Мбит / с 3,089 мс 1/425 (0,24%)
[3] 3,0-4,0 с 609 КБайт 4,99 Мбит / с 3,605 мс 0/424 (0%)
[3] 4,0-5,0 с 607 КБайт 4,97 Мбит / с 1,954 мс 0/423 (0%)
[3] 5,0-6,0 с 612 КБайт 5,01 Мбит / с 2,666 мс 0/426 (0%)
[3] 6,0-7,0 с 607 КБайт 4,97 Мбит / с 2,602 мс 0/423 (0%)
[3] 7,0-8,0 с 612 КБайт 5,01 Мбит / с 2,960 мс 0/426 (0%)
[3] 8,0-9,0 с 609 КБайт 4,99 Мбит / с 2,512 мс 0/424 (0%)
[3] 9,0-10,0 с 619 КБайт 5,07 Мбит / с 2,133 мс 0/431 (0%)
[3] 10,0–11,0 с 609 КБайт 4,99 Мбит / с 3,605 мс 1/425 (0,24%)
[3] 11,0-12,0 с 609 КБайт 4,99 Мбит / с 2,509 мс 0/424 (0%)
[3] 12,0-13,0 с 610 КБайт 5,00 Мбит / с 3,570 мс 0/425 (0%)
[3] 13,0-14,0 с 609 КБайт 4,99 Мбит / с 3,077 мс 1/425 (0,24%)
[3] 14,0-15,0 с 609 КБайт 4,99 Мбит / с 2,679 мс 0/424 (0%)
[3] 15,0-16,0 с 609 КБайт 4,99 Мбит / с 1,887 мс 0/424 (0%)
[3] 16,0-17,0 с 610 КБайт 5,00 Мбит / с 2,671 мс 0/425 (0%)
[3] 17,0-18,0 с 609 КБайт 4,99 Мбит / с 3,390 мс 0/424 (0%)
[3] 18,0-19,0 ​​с 617 КБайт 5,06 Мбит / с 2,601 мс 0/430 (0%)
[3] 19,0–20,0 с 612 КБайт 5,01 Мбит / с 3,525 мс 0/426 (0%)
[3] 0,0-20,0 с 11,9 МБайт 4,99 Мбит / с 3,156 мс 3/8503 (0,035%)
[3] 0,0-20,0 с 1 дейтаграммы получены не в порядке

++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++
C: \ iperf-2.0.5-2-win32> iperf -c 192.168.191.200 -i 1 -t 20 -r -u -b 9m
++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++
-------------------------------------------------- ----------
Сервер прослушивает UDP-порт 5001
Получение 1470 байт дейтаграмм
Размер буфера UDP: 64,0 КБ (по умолчанию)
-------------------------------------------------- ----------
-------------------------------------------------- ----------
Клиент подключается к 192.168.191.200, порт UDP 5001
Отправка 1470 байт дейтаграмм
Размер буфера UDP: 64,0 КБ (по умолчанию)
-------------------------------------------------- ----------
[4] локальный 192.168.191.201 порт 61761, связанный с 192.168.191.200 портом 5001
[ID] Интервал передачи
[4] 0,0-1,0 с 1,07 МБайт 9,00 Мбит / с
[4] 1,0-2,0 с 1,07 МБайт 8,98 Мбит / с
[4] 2,0-3,0 с 1,07 МБайт 9,00 Мбит / с
[4] 3,0-4,0 с 1,07 МБайт 8,98 Мбит / с
[4] 4,0-5,0 с 1,07 МБайт 9,00 Мбит / с
[4] 5,0-6,0 с 1,07 МБайт 8,98 Мбит / с
[4] 6,0-7,0 с 1,07 МБайт 8,98 Мбит / с
[4] 7,0-8,0 с 1,07 МБайт 9,00 Мбит / с
[4] 8,0-9,0 с 1,07 МБайт 8,98 Мбит / с
[4] 9,0-10,0 с 1,09 МБайт 9,14 Мбит / с
[4] 10,0-11,0 с 1,07 МБайт 9,00 Мбит / с
[4] 11,0-12,0 с 1,07 МБайт 8,98 Мбит / с
[4] 12,0-13,0 с 1,07 МБайт 8,98 Мбит / с
[4] 13,0-14,0 с 1,07 МБайт 9,00 Мбит / с
[4] 14,0-15,0 с 1,07 МБайт 8,98 Мбит / с
[4] 15,0-16,0 с 1,07 МБайт 9,00 Мбит / с
[4] 16,0-17,0 с 1,07 МБайт 8,98 Мбит / с
[4] 17,0-18,0 с 1,07 МБайт 8,98 Мбит / с
[4] 18,0-19,0 ​​с 1,09 МБайт 9,14 Мбит / с
[4] 19,0-20,0 с 1,07 МБайт 9,00 Мбит / с
[4] 0,0-20,0 с 21,5 МБайт 9,00 Мбит / с
[4] Отправлено 15315 дейтаграмм.
[4] Отчет сервера:
[4] 0,0-20,0 с 21,3 МБайт 8,94 Мбит / с 0,104 мс 96/15314 (0,63%) !!!!!!!!!!
[4] 0,0-20,0 с 1 датаграмма получена не в порядке
[3] локальный 192.168.191.201 порт 5001, соединенный с 192.168.191.200 портом 50751
[3] 0,0-1,0 с 1,06 МБайт 8,89 Мбит / с 2,405 мс 0/756 (0%)
[3] 1,0-2,0 с 1,07 МБайт 9,00 Мбит / с 2,308 мс 0/765 (0%)
[3] 2,0-3,0 с 1,07 МБайт 9,00 Мбит / с 2,305 мс 0/765 (0%)
[3] 3,0-4,0 с 1,07 МБайт 8,97 Мбит / с 2,290 мс 1/764 (0,13%)
[3] 4,0-5,0 с 1,07 МБайт 8,98 Мбит / с 2,271 мс 1/765 (0,13%)
[3] 5,0–6,0 с 1,07 МБайт 8,98 Мбит / с 2,331 мс 0/764 (0%)
[3] 6,0-7,0 с 1,07 МБайт 9,00 Мбит / с 2,191 мс 0/765 (0%)
[3] 7,0-8,0 с 1,07 МБайт 8,95 Мбит / с 2,314 мс 3/764 (0,39%)
[3] 8,0-9,0 с 1,07 МБайт 8,98 Мбит / с 2,232 мс 1/765 (0,13%)
[3] 9,0-10,0 с 1,09 МБайт 9,13 Мбит / с 2,257 мс 0/776 (0%)
[3] 10,0-11,0 с 1,07 МБайт 8,98 Мбит / с 2,355 мс 0/764 (0%)
[3] 11,0-12,0 с 1,07 МБайт 8,98 Мбит / с 2,301 мс 1/765 (0,13%)
[3] 12,0-13,0 с 1,07 МБайт 8,98 Мбит / с 2,277 мс 0/764 (0%)
[3] 13,0-14,0 с 1,07 МБайт 9,00 Мбит / с 2,332 мс 0/765 (0%)
[3] 14,0-15,0 с 1,07 МБайт 9,00 Мбит / с 2,176 мс 0/765 (0%)
[3] 15,0-16,0 с 1,07 МБайт 8,96 Мбит / с 2,273 мс 2/764 (0,26%)
[3] 16,0-17,0 с 1,07 МБайт 8,98 Мбит / с 2,331 мс 0/764 (0%)
[3] 17,0-18,0 с 1,07 МБайт 8,98 Мбит / с 2,247 мс 1/765 (0,13%)
[3] 18,0-19,0 ​​с 1,09 МБайт 9,11 Мбит / с 2,276 мс 1/776 (0,13%)
[3] 19,0–20,0 с 1,07 МБайт 8,97 Мбит / с 2,394 мс 1/764 (0,13%)
[3] 0,0-20,0 с 21,5 МБайт 8,99 Мбит / с 2,659 мс 11/15314 (0,072%)
[3] 0,0-20,0 с 1 дейтаграммы получены не в порядке

++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++
C: \ iperf-2.0.5-2-win32> iperf -c 192.168.191.200 -i 1 -t 20 -r -u -b 9850k
++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++
-------------------------------------------------- ----------
Сервер прослушивает UDP-порт 5001
Получение 1470 байт дейтаграмм
Размер буфера UDP: 64,0 КБ (по умолчанию)
-------------------------------------------------- ----------
-------------------------------------------------- ----------
Клиент подключается к 192.168.191.200, порт UDP 5001
Отправка 1470 байт дейтаграмм
Размер буфера UDP: 64,0 КБ (по умолчанию)
-------------------------------------------------- ----------
[4] локальный 192.168.191.201 порт 61762, связанный с 192.168.191.200 портом 5001
[ID] Интервал передачи
[4] 0,0-1,0 с 1,17 МБайт 9,84 Мбит / с
[4] 1,0-2,0 с 1,17 МБайт 9,84 Мбит / с
[4] 2,0-3,0 с 1,17 МБайт 9,84 Мбит / с
[4] 3,0-4,0 с 1,17 МБайт 9,84 Мбит / с
[4] 4,0-5,0 с 1,17 МБайт 9,84 Мбит / с
[4] 5,0-6,0 с 1,17 МБайт 9,83 Мбит / с
[4] 6,0-7,0 с 1,17 МБайт 9,84 Мбит / с
[4] 7,0-8,0 с 1,17 МБайт 9,84 Мбит / с
[4] 8,0-9,0 с 1,17 МБайт 9,84 Мбит / с
[4] 9,0–10,0 с 1,19 МБайт 10,0 Мбит / с
[4] 10,0–11,0 с 1,17 МБайт 9,84 Мбит / с
[4] 11,0-12,0 с 1,17 МБайт 9,84 Мбит / с
[4] 12,0-13,0 с 1,17 МБайт 9,83 Мбит / с
[4] 13,0-14,0 с 1,17 МБайт 9,85 Мбит / с
[4] 14,0-15,0 с 1,17 МБайт 9,83 Мбит / с
[4] 15,0-16,0 с 1,17 МБайт 9,85 Мбит / с
[4] 16,0-17,0 с 1,17 МБайт 9,83 Мбит / с
[4] 17,0-18,0 с 1,17 МБайт 9,84 Мбит / с
[4] 18,0-19,0 ​​с 1,19 МБ 10,0 Мбит / с
[4] 19,0–20,0 с 1,17 МБайт 9,84 Мбит / с
[4] 0,0-20,0 с 23,5 МБайт 9,85 Мбит / с
[4] Отправлено 16765 дейтаграмм.
[4] Отчет сервера:
[4] 0,0-20,0 с 23,3 МБайт 9,74 Мбит / с 3,421 мс 156/16764 (0,93%) !!!!!!!!!!
[4] 0,0-20,0 с 1 датаграмма получена не в порядке
[3] локальный 192.168.191.201 порт 5001, связанный с 192.168.191.200 портом 50752
[3] 0,0-1,0 с 1,16 МБайт 9,74 Мбит / с 2,131 мс 0/828 (0%)
[3] 1,0-2,0 с 1,17 МБайт 9,84 Мбит / с 2,140 мс 0/837 (0%)
[3] 2,0-3,0 с 1,17 МБайт 9,83 Мбит / с 2,099 мс 1/837 (0,12%)
[3] 3,0-4,0 с 1,17 МБайт 9,84 Мбит / с 2,113 мс 0/837 (0%)
[3] 4,0-5,0 с 1,17 МБайт 9,84 Мбит / с 2,105 мс 0/837 (0%)
[3] 5,0-6,0 с 1,17 МБайт 9,83 Мбит / с 2,058 мс 1/837 (0,12%)
[3] 6,0-7,0 с 1,17 МБайт 9,82 Мбит / с 2,165 мс 1/836 (0,12%)
[3] 7,0-8,0 с 1,17 МБайт 9,84 Мбит / с 2,156 мс 0/837 (0%)
[3] 8,0-9,0 с 1,17 МБайт 9,82 Мбит / с 2,135 мс 2/837 (0,24%)
[3] 9,0-10,0 с 1,19 МБайт 9,97 Мбит / с 2,152 мс 2/850 (0,24%)
[3] 10,0–11,0 с 1,17 МБайт 9,83 Мбит / с 2,153 мс 1/837 (0,12%)
[3] 11,0–12,0 с 1,17 МБайт 9,84 Мбит / с 2,127 мс 0/837 (0%)
[3] 12,0-13,0 с 1,17 МБайт 9,83 Мбит / с 2,136 мс 1/837 (0,12%)
[3] 13,0-14,0 с 1,17 МБайт 9,82 Мбит / с 2,087 мс 2/837 (0,24%)
[3] 14,0-15,0 с 1,17 МБайт 9,83 Мбит / с 2,061 мс 1/837 (0,12%)
[3] 15,0-16,0 с 1,17 МБайт 9,84 Мбит / с 2,045 мс 0/837 (0%)
[3] 16,0-17,0 с 1,17 МБайт 9,82 Мбит / с 2,203 мс 1/836 (0,12%)
[3] 17,0-18,0 с 1,17 МБайт 9,84 Мбит / с 2,165 мс 0/837 (0%)
[3] 18,0-19,0 ​​с 1,17 МБайт 9,83 Мбит / с 2,154 мс 1/837 (0,12%)
[3] 19,0–20,0 с 1,19 МБайт 9,98 Мбит / с 2,209 мс 0/849 (0%)
[3] 0,0-20,0 с 23,5 МБайт 9,84 Мбит / с 2,548 мс 13/16764 (0,078%)
[3] 0,0-20,0 с 1 дейтаграммы получены не в порядке

Настоящий вопрос остается:

Мы не переподписываем канал DC, поскольку он имеет скорость 100 Мбит / с и не может передавать более 100 Мбит / с. Однако удаленные сайты на скорости 10 Мбит / с.

  • Переполняют ли буферы на удаленной стороне и отбрасывают ли пакеты?
  • Формирователь трафика провайдера что-то делает с трафиком? (Будет ли трафик, поступающий от другого узла, зависеть от формирователя трафика интернет-провайдеров или только от трафика, входящего в узел (снаружи)) ...... Вы понимаете, что я имею в виду?

Почему TCP не может справиться с этим самостоятельно?

Обновление № 3 Теперь я использовал следующий сценарий:

Laptop ------- ... LAN ... --- DC switch --- Metro-Eth --- Laptop (directly connected)
NIC@10Mbps                       100Mbps                  NIC@10Mbps

Вот потеря пакетов в DC-> удаленном направлении: (iperf 9 Мбит / с UDP тест)

[  3] local 192.168.191.200 port 5001 connected with 192.168.191.201 port 55236
[ ID] Interval       Transfer     Bandwidth        Jitter   Lost/Total Datagrams
[  3]  0.0- 1.0 sec   912 KBytes  7.47 Mbits/sec   2.713 ms    0/  635 (0%)
[  3]  1.0- 2.0 sec  1001 KBytes  8.20 Mbits/sec   2.168 ms    0/  697 (0%)
[  3]  2.0- 3.0 sec  1001 KBytes  8.20 Mbits/sec   2.478 ms    0/  697 (0%)
[  3]  3.0- 4.0 sec   999 KBytes  8.18 Mbits/sec   0.933 ms    0/  696 (0%)
[  3]  4.0- 5.0 sec  1001 KBytes  8.20 Mbits/sec   2.620 ms    0/  697 (0%)
[  3]  5.0- 6.0 sec  1001 KBytes  8.20 Mbits/sec   2.721 ms    0/  697 (0%)
[  3]  6.0- 7.0 sec  1001 KBytes  8.20 Mbits/sec   2.089 ms    0/  697 (0%)
[  3]  7.0- 8.0 sec   999 KBytes  8.18 Mbits/sec   2.641 ms    0/  696 (0%)
[  3]  8.0- 9.0 sec  1002 KBytes  8.21 Mbits/sec   0.896 ms    0/  698 (0%)
[  3]  9.0-10.0 sec  1015 KBytes  8.31 Mbits/sec   2.557 ms    0/  707 (0%)
[  3] 10.0-11.0 sec   999 KBytes  8.18 Mbits/sec   2.822 ms    1/  697 (0.14%)
[  3] 11.0-12.0 sec   999 KBytes  8.18 Mbits/sec   1.551 ms    1/  697 (0.14%)
[  3] 12.0-13.0 sec   998 KBytes  8.17 Mbits/sec   2.504 ms    2/  697 (0.29%)
[  3] 13.0-14.0 sec   995 KBytes  8.15 Mbits/sec   2.038 ms    3/  696 (0.43%)
[  3] 14.0-15.0 sec   991 KBytes  8.11 Mbits/sec   2.539 ms    7/  697 (1%)
[  3] 15.0-16.0 sec   992 KBytes  8.13 Mbits/sec   2.759 ms    6/  697 (0.86%)
[  3] 16.0-17.0 sec   998 KBytes  8.17 Mbits/sec   2.229 ms    2/  697 (0.29%)
[  3] 17.0-18.0 sec   993 KBytes  8.14 Mbits/sec   2.723 ms    4/  696 (0.57%)
[  3] 18.0-19.0 sec   998 KBytes  8.17 Mbits/sec   2.038 ms    2/  697 (0.29%)
[  3] 19.0-20.0 sec  1012 KBytes  8.29 Mbits/sec   2.575 ms    3/  708 (0.42%)
[  3]  0.0-20.0 sec  19.5 MBytes  8.15 Mbits/sec   2.775 ms   31/13917 (0.22%)
[  3]  0.0-20.0 sec  1 datagrams received out-of-order

Другое направление в порядке. Однако при выполнении теста TCP направление remote-> DC не работает намного лучше, чем направление DC-> remote (около 5 Мбит / с) .......

Я не уверен, что мы достигли дна этого.

ethernet tcp troubleshooting packet-analysis metro-ethernet Marki
источник
Не совсем ответ, но я рекомендую получить JDSU и протестировать эту схему. Если они контролируют вас, убедитесь, что вы получили ограничитель, «регулятор», настройки ... Если у них маленькая CBS, то они ограничивают ваш TCP-трафик существенно меньшим размером окна. Вы можете проверить это с помощью теста back-2-back. Я потратил много времени, работая с провайдерами в цепях L2, чтобы понять, что когда мы получим новую схему, мы проведем тщательное тестирование не только в CIR, но и в CBS ...
матак
Кроме того, просто быстрое примечание стороны. Пропускная способность TCP, которая видна из ОС Windows против Linux, будет отличаться, потому что настройки TCP будут отличаться; то есть. размер буфера, алгоритм и т. д. Вы можете просмотреть настройки для своего компьютера с Linux через sysctlнеуверенность в Windows ... возможно netsh. Если бы я собирался сделать предположение о том, что не так с вашей схемой, я бы сказал, что CPE на лучевом узле настроен с большей CBS, чем со стороной концентратора ... что обычно происходит наоборот. Опять же, JDSU отбросит мяч назад к ним или позволит вам снова сосредоточиться на проблеме.
матак
@matak Почему бы не сделать дополнительный ответ на ваши замечания? Когда мы говорим о формирователе, где я представляю это устройство? На DC есть разъем RJ45 без (видимого) CPE. На удаленных сайтах у меня в основном VDSL-модем и какой-то MPLS-совместимый маршрутизатор. Не уверен, что они используют MPLS. И более того, какое направление движения формирует формирователь? Мы можем сформировать ingress @ spok (с сайта), egress @ spok (к облаку провайдера), ingress @ hub (от DC), egress @ hub (к облаку провайдера) ... Возможно, мне не хватает общей картины. Можете ли вы объяснить, почему проблема с CBS будет проблемой?
Марки

Ответы:

20

Ссылка на наш чат обмена стека ...

Короткая история, вам нужно контролировать несоответствия скорости по обеим сторонам ваших линий метро Ethernet ... Я перерисовал вашу диаграмму для ясности ... Примечание 1

Диаграмма проблемы

  • DC (показан зеленым цветом) очень быстро переходит от 10GE к 100M ... это 100-кратный переход скорости, и вам обычно нужно реализовать некоторую форму qos (например, формирование), чтобы смягчить такой большой переход. Смотрите в нижней части этого ответа для доказательства того, что DC нуждается в формировании (для сайта) ...
  • Удаленные боковые переходы от 1GE до 10M очень быстро CIR ... это опять-таки 100-кратный скоростной переход. Формирование или другие обходные пути обычно требуются.
  • Также, кажется, существует несоответствие скорости между DC UNI (100M) и удаленным UNI (10M); это само по себе требует решения для управления пропускной способностью для каждого сайта.

К вашему сведению, если ваш провайдер внедряет MEF- совместимые сервисы, они не формируют, а контролируют . TCP-трафик имеет тенденцию работать лучше с формированием .

Необходимость вашего собственного QoS

Похоже, вы сомневаетесь в необходимости qos , поэтому я приведу цитату из Белой книги MEF "Understanding Carrier Ethernet Throughput" , стр. 9 ... в порядке обзора, клиент на Белой книге MEF на рисунке 2 выглядит лучше, чем вы. .. они приобрели CIR 50 Мбит / с, но их UNI поставляется на 1GE ... ваш удаленный сайт имеет CIR 10 Мбит / с на 1GE UNI.

The transition from legacy services such as T1, T3, Frame Relay and ATM
to Carrier Ethernet has created some unintended consequences. Not all customers have 
conforming equipment facing the network which properly limits/shapes the traffic outbound
to the network, with deleterious results.  For instance, on the 1 GigE interface of
Figure 2, if the customer’s equipment accidentally transmits long bursts of data at 
150 Mbits instead of the SLA’s Committed Information Rate of 50 Mbits, 67% of the data 
may be lost and network breakdown will likely result.

Отвечая на другие вопросы TCP в редактировании ...

Мы не переподписываем канал DC, так как он на скорости 100 Мбит / с и не может передавать более 100 Мбит / с ...

Я не согласен, вы можете отправлять микропакеты на 10GE, потому что ваш DC имеет 10GE-ссылки, но UNI метро составляет 100 Мбит / с. Один открытый вопрос состоит в том, сколько буферизации у вас на коммутаторе Enterasys LAN (коммутатор A) при переходе с 10GE на 100M.

Почему TCP не может справиться с этим самостоятельно?

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

Другие вопросы TCP из чата

Марки сказал : «Я не понимаю, что, где, кем и почему и почему и почему и почему и почему не решается, TCP не просто обрабатывает тот факт, что на одном конце есть (реальные) 100 МБ, а на другом - только 10 Мбит / с.

Что касается необходимости TCP в буферизации и последствий отсутствия буферов :

Факт № 1: TCP нуждается в буферизации для скоростных переходов, потому что он разработан как система контроля обратной связи .

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

Аналогично, когда сеанс FTP передается со скоростью 10GE, пакеты трафика могут иметь длину до 4 МБ (в вашем случае) из -за размера окна, масштабируемого по протоколу TCP, прежде чем сокет должен остановиться и ожидать TCP ACK. Между тем, если поток трафика 10GE внезапно попадает в «Fast Ethernet», TCP должен постепенно замедляться. Глубокие буферы в сетевой передаче позволяют TCP отбрасывать гораздо меньше пакетов, когда он совершает скоростные переходы; однако, если у вас нет буферов, вы можете отбросить, возможно, 99% этого 4-мегабайтного TCP-окна, когда оно уменьшено с 10GE до 100M. Думайте об этой серьезной потере 99% как о сбое сокета TCP; TCP предсказуемо реагирует на относительно постепенную потерю пакетов. Протокол TCP гораздо менее предсказуемо реагирует на продолжающуюся серьезную потерю пакетов. Примечание 3 .

На вопрос, почему вы не должны использовать асимметричный CIR Metro Ethernet с 100M на постоянном токе и 10M на удаленном, задайте себе риторический вопрос: «Кто буферизует этот трафик со скоростью 100 Мбит / с, когда он достигает дешевого NID Ethernet 10 Мбит / с? который ваш метро? провайдер -етернет дал? "... (подсказка: никто не буферизует).

Если никто не буферизует большие (см. Примечание 2) скоростные переходы, то эти точки являются потенциальными местами для прерывистого отбрасывания трафика.

Что отбрасывается кем :

Выходной трафик падает с DC

Когда TCP-трафик покидает центр обработки данных, его можно отбросить в трех местах:

  • На D1: потому что коммутаторы локальной сети редко имеют достаточно глубокую буферизацию для скорости передачи 100: 1
  • На D2: если NID когда-либо согласовывал соединение UNI на более высокой скорости, чем CIR ; сейчас дело обстоит иначе, поэтому я не ожидаю падений там.
  • На D3: по всем причинам, которые я только что описал, об асимметричных CIR Metro Ethernet .

Когда трафик TCP идет в центр обработки данных ...

Входящий трафик падает до DC

  • На D4: потому что у вас есть 1GE UNI и 10M CIR ; это патологический случай D2, о котором я упоминал выше.

Как уменьшить несоответствия скорости:

Пример решения EVPL : EVPL с двухточечным решением EVC

  • В такой коммутируемой топологии EVPL с двухточечными EVC от DC к каждому Remote, вероятно, является вашим лучшим вариантом (см. Схему выше). Это будет применять индивидуальный CIR к каждому EVC. Примечание: все другие указания QoS в этом ответе применимы ... т.е. избегайте больших скоростных переходов. Примечание 2 без проверки того, будет ли ваше оборудование справляться с этим достаточно хорошо.
  • В качестве альтернативы, вы можете рассмотреть возможность покупки услуг метро, ​​которые имеют симметричные скорости между DC и удаленным; хотя я бы признал, что это не самое практическое руководство.
  • К сведению, классическое решение этой проблемы для маршрутизируемых сервисов состоит в том, чтобы купить маршрутизаторы, которые поддерживают формирование на требуемых скоростях, а затем настроить трафик в метро на соответствующий CIR (для каждого удаленного сайта). К вашему сведению, удаленная сторона может обойтись без достаточно маленького маршрутизатора, поскольку это всего лишь вход 1GE и CIR 10 Мбит / с ... Несколько месяцев назад, когда мы говорили о дизайне этого сервиса, я рекомендовал маршрутизацию, если вы знакомы с технологиями ...

  • Если у вас нет лишних денег , чтобы тратить и не можете реорганизовать вашу службу метро Ethernet, можно массировать несовпадения скорости постепенно. Я никогда не делал этого, но в принципе вы могли бы попытаться сделать скоростные переходы от 10 к 1 вместо 100 к 1 (что у вас сейчас есть как на постоянном, так и на удаленном):

    • Вместо того, чтобы покупать маршрутизатор для настройки удаленного устройства до 10M, вы можете попытаться принудительно заставить UNI удаленного управления автоматически согласовывать 100M вместо 1GE; GigabitEthernet требует наличия всех выводов в кабеле Cat5e , поэтому вы можете эффективно подключить его к 100M с помощью разъема RJ45, который просто соединяет выводы 1, 2, 3 и 6.
    • Вместо того, чтобы покупать маршрутизатор для настройки DC на 100M, используйте Enterasys для контроля соединения 10GE до 1GE при отправке трафика на канал 100M

Анализируя ваши iperfрезультаты ...

Есть два ключевых момента, о которых следует помнить iperf(вся информация основана на iperfверсии 2):

Таким образом, следующий вывод показывает, что компьютер DC (в iperf -cрежиме) подключается к iperfсерверу на удаленном сайте (192.168.x) и передает данные с DC (100M UNI) на удаленный сайт (10M UNI) ...

./iperf -c 192.168.x -i2 -t 60 -r
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
------------------------------------------------------------
Client connecting to 192.168.x, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local 10.x port 38195 connected with 192.168.x port 5001
[  3]  0.0- 2.0 sec  1.44 MBytes  6.03 Mbits/sec
[  3]  2.0- 4.0 sec  2.23 MBytes  9.37 Mbits/sec
[  3]  4.0- 6.0 sec  2.28 MBytes  9.57 Mbits/sec
[  3]  6.0- 8.0 sec  1.88 MBytes  7.90 Mbits/sec
[  3]  8.0-10.0 sec  1.00 MBytes  4.19 Mbits/sec
[  3] 10.0-12.0 sec  1.30 MBytes  5.47 Mbits/sec
[  3] 12.0-14.0 sec    688 KBytes  2.82 Mbits/sec

Вывод выше ясно показывает проблемы в DC к удаленному направлению; мы должны ожидать 9 Мбит / с или более, когда все работает хорошо (т.е. вы ожидаете по крайней мере 90% емкости - 10 Мбит / с на удаленном сайте). Теперь давайте посмотрим на трафик в противоположном направлении (когда iperfотправляет данные с удаленного сайта в DC) ...

[  5] local 10.x port 5001 connected with 192.168.x port 10965
[  5]  0.0- 2.0 sec  1.85 MBytes  7.75 Mbits/sec
[  5]  2.0- 4.0 sec  1.90 MBytes  7.98 Mbits/sec
[  5]  4.0- 6.0 sec  1.89 MBytes  7.93 Mbits/sec
[  5]  6.0- 8.0 sec  1.92 MBytes  8.07 Mbits/sec
[  5]  8.0-10.0 sec  1.91 MBytes  8.02 Mbits/sec
[  5] 10.0-12.0 sec  1.83 MBytes  7.69 Mbits/sec
[  5] 12.0-14.0 sec  1.86 MBytes  7.78 Mbits/sec

Вы можете отправить около 80% емкости удаленного CIR, но это все же меньше, чем я ожидаю.

Иллюстрация несоответствия скорости постоянного тока (10 Гбит / с -> 100 Мбит / с)

Марки сказал : не забывайте, проблема проявляется только тогда, когда поток 100Mb-> 10Mb, а не наоборот.

Проблема проявляется в обоих направлениях, но iperfсимптомы в DC -> отдаленном направлении кажутся хуже. Смотрите мой анализ iperfвывода выше.

Чтобы сделать это конкретнее, давайте посмотрим на ваш файл pcap при передаче файла с вашего FTP-сервера DC (130.1.6.4) на удаленный сайт (192.168.191.2). Передача со стороны 100M Metro Ethernet ограничена в нескольких точках во время передачи. Вы можете увидеть это, если вы посмотрите на dc-to-remote_remote-side.pcapngpcap и отфильтруетеexpert.message contains "segment not captured"

введите описание изображения здесь

Конечные заметки :

Примечание 1 Я выбираю значения CBS 25 КБ на 1 Мбит / с MetroEthernet CIR; это общее соотношение, используемое провайдерами ... YMMV
Примечание 2 Мое личное правило: "большой" - это скоростной переход, который значительно больше, чем переход скорости 10: 1.
Примечание 3Я не могу дать точные цифры для того, что является и не слишком много потери пакетов для TCP. Если потеря достаточно плоха для ваших приложений, то это слишком много. Мое личное правило: когда я имею дело с проводной корпоративной сетью полностью под моим собственным контролем, любая (непреднамеренная) потеря пакетов слишком велика. Тем не менее, есть некоторые модели переключателей, которые сокращают углы при буферизации; эти коммутаторы могут время от времени отбрасывать пакеты ... это суждение о том, придется ли вам жить с проблемой или покупать более качественные коммутаторы. К вашему сведению: это не всегда очевидно, но TCP периодически увеличивает скорость передачи сокета, чтобы обеспечить максимально возможную пропускную способность; многие реализации TCP знают, что они работают слишком быстро, когда видят отбрасывание пакетов.

Майк Пеннингтон
источник
Обратите внимание, что PHY скорость DC (порт Metro Ethernet) уже составляет 100 МБ. Но я также не могу отправить на 100M, потому что другая сторона - максимум 10Mb ... Сейчас мне все еще неясно, где именно должно происходить формирование. О, и вы имели в виду «симптомы Iperf, кажется, хуже в DC -> отдаленном направлении»?
Марки
Я обновил ответ, да "удаленный -> DC" был опечаткой в ​​исходном ответе.
Майк Пеннингтон,
Я согласен с Майком здесь, в зависимости от того, кто ваш провайдер, если вы спросите их, они скажут вам скорость линии на своем конце, сделайте так, чтобы они соответствовали вашим физическим интерфейсам, свисающим с вашего metro-E. Что касается ГДЕ для QoS, я бы сделал на ваших самых больших точках входа, на ваших 10-гигабайтных устройствах, прежде чем они перейдут на более мелкие вышестоящие устройства. Хотя я трачу больше времени на межсетевой экран и маршрутизацию, чем на переключение, но, надеюсь, Майк сможет подтвердить мои заявления!
AL
3
@MikePennington - Блокировка выхода из-за несоответствия скорости - это то, с чем я часто сталкиваюсь при использовании микроволновых каналов P2P. Отличный ответ, много хорошей информации в вашем посте. Благодарность!
Матак
1
Также проверьте на несоответствие дуплекса, это может вызвать однонаправленные проблемы скорости.
cpt_fink
2

Хотя обсуждение этой проблемы было очень интересным, интернет-провайдер тем временем начал обменивать модемы DSL на разных сайтах другой торговой маркой. Они говорят, что существует проблема фрагментации пакетов. И эй, 9,5 Мбит / с в обоих направлениях без каких-либо проблем или специальных настроек.

Marki
источник