Усунення несправностей з низькою пропускною здатністю Metro Ethernet TCP

Установка

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

Ми вирішили поставити маршрутизатор на кожен сайт і надати кожному сайту свою VLAN. Таким чином, у брандмауера постійного струму визначено стільки VLAN, скільки сайтів. Таким чином, кожен сайт використовує свій діапазон адрес у власній VLAN.

Діаграма мережі:

Проблема

Тепер ми стикаємося з проблемами пропускної здатності:

• Запуск FTP-передачі від сайту до постійного струму працює чудово зі швидкістю близько 10 Мбіт / с, що є швидкістю лінії.
• Запуск FTP-передачі з постійного струму на сайт не працює нормально зі швидкістю 6 Мбіт / с або менше.

Не має значення, яка сторона ініціює передачу. Єдина послідовна річ - це те, що один напрямок працює недостатньо добре. Шкода, що це напрямок до сайту, тому що це буде пропускна здатність, яка нам найбільше потрібна, як ми хотіли б використовувати клієнтів термінальних серверів.

Приблизно через 10 секунд після передачі пропускна здатність падає. Ми бачимо DUP ACK, коли нюхає. Що, можливо, призводить мене до обмеження ставок в кінці провайдера ?? (Наразі у них немає поняття, і я хотів би переконатися, що ми не винні перед тим, як перейти до ескалації)

ПРИМІТКА Віддалені сайти якось обмежені 10 Мб. Встановлення переходу на метро до 10 Мбіт також не допомагає. Насправді це найгірше (максимум 30 Кб / с). Встановлення 100Mb працює добре, але вже починає створювати окреслену проблему. Те саме для 1G.

Записи проблеми можна завантажити тут:

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

Діагностика

На зображенні ви бачите графік IO Wireshark з деякими деталями помилок:

• ліворуч: передача FTP від ​​DC на сайт
• праворуч: передача FTP від ​​сайту до постійного струму

У випадку, якщо інша сторона ініціює передачу (тобто ставиться з dc, а не отримує віддалений), проблема залишається незмінною.

Будь ласка, побалуйте мене тим, що, на вашу думку, може бути тут проблемою.

ОНОВЛЕННЯ №1 (інтегровано вище)

ОНОВЛЕННЯ №2 ( ОНОВЛЕНО )

Це повинно бути справою перевантаженості.

Зауважте, що від постійного струму до віддаленого ми маємо 10G-> 1G-> 100M-> 10M-> 1G посилання. <- не працює

В іншому напрямку ми маємо обернене: 1G-> 10M-> 100M-> 1G-> 10G. <- просто чудово

Перший "1G-> 10M" - це "невидимий" 10M на віддаленому місці, де все, включаючи швидкість порту висхідної лінії зв'язку, встановлено на рівні 1G, хоча за ним є лише 10M (продається).

Однак 100 Мбіт / с у постійному струмі справжні 100 Мбіт / с, інтерфейс налаштований на 100 Мбіт / с на фізичному рівні.

Зараз я використовую iperf:

• TCP- тести працюють добре лише в одному напрямку (клієнт = постійний струм, сервер = віддалений)

./iperf -c 192.168.x -i2 -t 60 -r
-------------------------------------------------- ----------
Прослуховування сервера через порт 500 TCP
Розмір вікна 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,22 Мбіт 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,77 Мбіт / сек
[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, але використовуючи підключення метро, ​​200 = віддалений, 201 = постійний струм

Ми бачимо, що втрати пакетів збільшуються із збільшенням пропускної здатності (при наближенні до 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 5m
++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++
-------------------------------------------------- ----------
Прослуховування сервера на порту UDP 5001
Отримання 1470 байт дейтаграм
Розмір буфера UDP: 64,0 Кбайт (за замовчуванням)
-------------------------------------------------- ----------
-------------------------------------------------- ----------
Клієнт підключення до 192.168.191.200, порт UDP 5001
Надсилання 1470 байт дейтаграм
Розмір буфера UDP: 64,0 Кбайт (за замовчуванням)
-------------------------------------------------- ----------
[4] місцевий порт 192.168.191.201 61760, з'єднаний з портом 192.168.191.200, 5001
[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] місцевий порт 192.168.191.201 5001, з'єднаний з портом 192.168.191.200, 50750
[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,656 мс 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,550 мс 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,07 мс 1/425 (0,24%)
[3] 14,0-15,0 сек 609 Кбайт 4,99 Мбіт / сек 2,669 мс 0/424 (0%)
[3] 15,0-16,0 сек 609 Кбайт 4,99 Мбіт / сек 1,888 мс 0/424 (0%)
[3] 16,0-17,0 сек 610 Кбайт 5,00 Мбіт / сек 2,651 мс 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 9м
++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++
-------------------------------------------------- ----------
Прослуховування сервера на порту 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,227 мс 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,331 мс 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,225 мс 0/776 (0%)
[3] 10,0-11,0 сек 1,07 Мбіт 8,98 Мбіт / сек 2,365 мс 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,27 мс 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,224 мс 1/765 (0,13%)
[3] 18,0-19,0 ​​сек 1,09 Мбіт 9,11 Мбіт / с 2,227 мс 1/776 (0,13%)
[3] 19,0-20,0 сек 1,07 Мбіт 8,97 Мбіт / с 2,339 мс 1/764 (0,13%)
[3] 0,0-20,0 сек 21,5 Мбіт 8,99 Мбіт / сек 2,669 мс 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 дейтаграми, отримані поза замовленням

Справжнє питання залишається:

Ми не підписуємо підключення постійного струму, оскільки воно знаходиться в 100 Мбіт / с і не може надсилати більше 100 Мбіт / с. Однак віддалені сайти мають швидкість 10Mbps.

• Чи буфери на віддаленій стороні переповнюють і скидають пакети?
• Чи провайдер трафіку робить щось із трафіку? (Чи впливатиме на трафік, що надходить з іншого вузла, формувач руху провайдерів або лише трафік, що потрапляє у вузол (ззовні)) ...... Ви бачите, що я маю на увазі?

Чому TCP не може впоратися з цим все самостійно?

Оновлення №3 Зараз я використовував такий сценарій:

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

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

[  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-тесту напрямок дистанційного-> постійного струму не працює набагато краще, ніж напрямок DC-> віддалений (близько 5Mbps) .......

Я не впевнений, що ми досягли цього.

Посилання на наш чат обміну стеками ...

Коротка історія, вам потрібно контролювати невідповідності швидкості з обох сторін вашого посилання на метро Ethernet ... Я перекроював вашу діаграму задля ясності ... ^{Примітка 1}

• Перехід постійного струму (показаний зеленим кольором) з 10GE до 100M дуже швидко ... це 100-кратний перехід швидкості, і вам зазвичай потрібно реалізувати певну форму qos (наприклад, формуючи), щоб пом'якшити такий великий перехід. Дивіться в нижній частині цієї відповіді для підтвердження того, що постійне управління потребує формування (для кожного сайту) ...
• Віддалений бічний перехід від 1GE до 10M CIR дуже швидко ... це знову-таки 100-кратний перехід швидкості. Як правило, потрібні формулювання чи інші способи вирішення питань.
• Здається, також існує невідповідність швидкості між DC UNI (100M) та віддаленим UNI (10M); це само просить рішення для управління пропускною здатністю на сайті.

FYI, якщо ваш провайдер реалізує послуги, сумісні з MEF , вони не формуються, вони проводять поліцейські дії . TCP-трафік, як правило, ефективніше під час формування .

Необхідність власного QoS

Ви, здається, сумніваєтесь у необхідності qos , тому я наводжу цитату з МЕФ "Розуміння пропускної здатності Ethernet провайдера" , сторінка 9 ... в результаті огляду, у клієнта з рисунка 2 MEF ситуація краща, ніж ви. .. вони придбали 50Mbps CIR, але їх UNI постачається на 1GE ... ваш віддалений сайт має 10Mbps CIR на 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 в редакції ...

Ми не підписуємо підключення постійного струму, оскільки воно на 100 Мбіт / с і не може надіслати більше 100 Мбіт / с ...

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

Чому TCP не може впоратися з цим все самостійно?

TCP обробляє речі, сповільнюючи, коли бачить втрату пакету ... він дійсно сповільнює (і може перервати з'єднання) за серйозні втрати пакету. Отже, TCP робить все, що повинен ... Як мережевий інженер, ваша мета - побудувати мережу з умовами, які роблять TCP щасливим.

Інші питання TCP з чату

Маркі сказав : Я не розумію, що випадає куди і ким і чому і чому TCP просто не справляється з тим, що на одному кінці є (справжні) 100 Мбіт, а в іншому лише 10 Мбіт / с.

Що стосується потреби TCP у буферизації та наслідків відсутності буферів :

Факт №1: TCP потребує буферизації для швидких переходів, оскільки він розроблений як система управління зворотним зв'язком .

Використовуючи аналогію водіння: як хороші водії, ми завжди залишаємо місця на кілька секунд між нами та машиною перед нами; певним чином цей простір між автомобілями приблизно аналогічний мережевому буфері. Якщо людина перед нами ляскає на гальма, коли тварина біжить перед ними, простір між нашими автомобілями (сподіваємось) заважає нам вдаритись у їхню машину. Ми залишаємо простір, оскільки потрібен час, щоб наші очі побачили гальмівні вогні, наша стопа реагувала, а гальма розсіювали достатню кількість тепла; наші очі дають нам систему контролю візуального зворотного зв'язку.

Так само, коли FTP-сеанс розгорнуто в 10GE, вибухи трафіку можуть тривати до 4 Мб (у вашому випадку) через масштаб вікна TCP, перш ніж сокет повинен зупинитися і чекати TCP ACK. Тим часом, якщо потік 10GE трафіку раптово потрапить у "Швидкий Ethernet", TCP потрібно поступово сповільнювати. Глибокі буфери в мережевій передачі дозволяють TCP скидати набагато менше пакетів, коли він робить швидкі переходи; однак, якщо у вас немає буферів, ви можете скинути, можливо, 99% цього вікна TCP 4MB, коли воно перебуває з 10GE до 100M. Подумайте про цю серйозну 99% втрату як аварію TCP-розетки; TCP передбачувано реагує на відносно поступові втрати пакетів. TCP реагує набагато менш передбачувано на постійні, серйозні втрати пакетів ^{Примітка 3} .

На питання, чому ви не повинні використовувати асиметричну мережу Ethernet CIR зі 100M на постійному струмі та 10M на пульті дистанційного керування, задайте собі риторичне запитання "хто буферизує, що трафік 100Mbps лопне, коли він потрапляє на дешевий 10Mbps Ethernet NID, що у вашому метро -провайдер мережі передав вам? "... (натяк: ніхто не буферизує).

Якщо ніхто не буферизує великі (див. Примітку 2) швидкісні переходи, то ці точки є потенційними місцями для періодичного скидання трафіку.

Що кидає хто :

Коли трафік TCP залишає центр обробки даних, його можна скинути на три місця:

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

Коли трафік TCP переходить до центру обробки даних ...

• У D4: тому що у вас є 1GE UNI та 10M CIR ; це патологічний випадок D2, про який я згадував вище.

Як пом’якшити невідповідність швидкості:

Приклад рішення EVPL :

• У такій топології, що перемикається, EVPL з точковою точкою EVC від постійного струму до кожного пульта - це, мабуть, найкращий варіант (див. Схему вище). Це застосувало б індивідуальний CIR до кожного EVC. Примітка: всі інші вказівки щодо якості в цій відповіді застосовуються ... тобто уникайте переходів на великих швидкостях ^{Примітка 2,} не перевіряючи, чи ваше обладнання буде справлятися з цим досить добре.
• Крім того, ви можете розглянути можливість придбання послуг метро, ​​які мають симетричну швидкість між постійним струмом і дистанційним; хоча я б визнав, що це може бути не найбільш практичним настановою.
• FYI, класичне рішення цієї проблеми для маршрутизованих послуг - придбати маршрутизатори, які підтримують формування з необхідною швидкістю, а потім сформувати ваш трафік метро у відповідний CIR (на віддалений сайт). FYI, віддалена сторона може піти з досить невеликим маршрутизатором, оскільки це лише вхід 1GE і 10 Мбіт / с CIR ... Місяць тому, коли ми говорили про дизайн цього сервісу, я рекомендував маршрутизацію, якщо вам було комфортно з технологіями. ...

• Якщо у вас немає зайвих грошей, щоб витратити гроші, і ви не можете переробити свою послугу метро-Ethernet, ви можете поступово масажувати невідповідність швидкості. Я ніколи цього не робив, але в принципі ви можете спробувати зробити швидкісні переходи 10 на 1, а не 100 на 1 (це те, що у вас зараз є і в постійному, і в дистанційному режимі):

  • Замість того, щоб купувати маршрутизатор для формування пульта до 10М, ви можете спробувати змусити віддалений UNI до автоматичних переговорів на 100M замість 1GE; GigabitEthernet потребує всіх штифтів у кабелі Cat5e , щоб ви могли ефективно примусити його до 100M за допомогою модуля-модуля RJ45, який просто з'єднує шпильки 1, 2, 3 і 6.
  • Замість того, щоб купувати маршрутизатор для формування постійного струму до 100 М, використовуйте Enterasys для поліції 10GE посилання на 1GE, коли відправляєте трафік у напрямку 100M

Аналіз iperfрезультатів ...

Про це слід пам’ятати два ключові моменти iperf(вся інформація на основі iperfверсії 2):

• iperfвимірює пропускну здатність корисного навантаження TCP або UDP ; Іншими словами, він ігнорує накладні витрати заголовків TCP, UDP, IP та Ethernet. Оскільки у вас є послуга Ethernet, не забудьте відповідним чином змінити iperfрезультати
• iperfКлієнт відправляє дані на сервер під час випробувань.

Отже, наступний висновок показує, що машина постійного струму (в iperf -cрежимі) підключається до iperfсервера на віддаленому місці (192.168.x) і передає дані з постійного струму (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

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

[  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 Мбіт / с)

marki сказав : Не забувайте, проблема проявляється лише тоді, коли потік становить 100Mb-> 10Mb, а не навпаки.

Проблема проявляється в обох напрямках, але iperfсимптоми здаються сильнішими у віддаленому напрямку DC ->. Дивіться мій аналіз iperfрезультатів вище.

Щоб зробити це конкретним, давайте подивимось на ваш FTP pcap при натисканні файлу з вашого DC FTP-сервера (130.1.6.4) на віддалений сайт (192.168.191.2). Передача з 100M метрової сторони 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. Якщо збитки досить сильні, щоб ваші програми зазнали, то це занадто багато. Моє особисте правило: якщо мати справу з дротовою корпоративною мережею повністю під моїм контролем, будь-яка (ненавмисна) втрата пакету - це занадто багато. Однак, є деякі моделі комутаторів, які вирізають кути на буферизацію; ці комутатори можуть періодично скидати пакети ... це судження про те, чи потрібно вам жити з проблемою чи купувати кращі комутатори. FYI: Це не завжди очевидно, але TCP періодично збільшує швидкість передачі сокета, щоб забезпечити отримання якомога більшої пропускної здатності; багато реалізацій TCP знають, що вони йдуть занадто швидко, коли бачать краплі пакетів.

Хоча обговорення цієї проблеми було дуже цікавим, провайдер тим часом розпочав обмін DSL-модемами на різних сайтах іншою маркою. Про них говорять деякі проблеми фрагментації пакетів. І ей, 9,5 Мбіт / с в обох напрямках без проблем і спеціальних налаштувань.