Что может ограничивать скорость upload-а на компе через linux шлюз?

Question

[tobut]

Есть интернет шлюз на Debian. Трафик перенаправляет через iptables. На шлюзе аплоад в 2 раза выше, чем на компе. В чем может быть проблема?

Comments

[StrangeAttractor]

Какая конкретно скорость? Какое подключение (Ethernet или WiFi)?

[tobut]

StrangeAttractor: Напрямую скорость - 400 мбит/c, через шлюз - 200 мбит/c. (Ethernet)

Answer 1

[StrangeAttractor]

Например если скорость и дуплекс заданы вручную может тупить. Попробуйте сделать auto-negotiation.

Comments

[tobut]

Вроде как везде стоит.

Answer 2

[throughtheether]

Сравните "пинги" до целевого сервера при работе через шлюз и напрямую. Также проверьте интерфейсы на наличие ошибок (при помощи команды ifconfig).

UPD:

https://cloud.mail.ru/public/3VZDQKLZM2Wb/cap_eth0.pcap - слушал eth0 (интернет)
https://cloud.mail.ru/public/2MTN9apktN8U/cap_eth1.pcap - слушал eth1 (локальная сеть)

Уточните, это дампы трафика только с сервера или с сервера (eth0) и клиентского компьютера тоже (eth1)?
Я спрашиваю, потому что разницы скорости передачи полезных данных в два раза я здесь не обнаружил.
График скорости передачи трафика от сервера 213.180.204.183 с eth0:

С eth1:

С TCP явных проблем пока не обнаружил, равно как и с MTU (размер полезной нагрузки HTTP в каждом пакете одинаковый в обоих дампах, 1410 байт)

UPD2:

gateway - https://cloud.mail.ru/public/5VsPnm4QmaRp/gateway.pcap
computer - https://cloud.mail.ru/public/yy6WtAZgbKc5/computer.pcap

Так, теперь вижу:
gateway:

computer:

Если не ошибаюсь, из дампов следует, что вы:
1) с шлюза поднимаете l2tp-сессию и через нее качаете файл, ваш MAC-адрес 14:cc:20:03:c0:aa, ближайшего маршрутизатора - 84:c9:b2:22:a6:02, скорость около 5 Мбайт/сек
2) с компьютера поднимаете l2tp-сессию и через нее качаете файл, ваш MAC-адрес 14:cc:20:03:c0:aa, ближайшего маршрутизатора - 84:c9:b2:22:a6:02, скорость около 2.5 Мбайт/сек

В связи с этим неясно, как у вас организовано подключение? Если компьютер подключен через linux-шлюз (по дампам этого не видно, см. MAC-адреса Ethernet-фреймов), то почему вы с него (компьютера) поднимаете сессию, вместо того, чтобы поднять ее на шлюзе и отдавать трафик компьютеру через обычный IPoE?

Просьба четко пояснить, в чем именно заключается проблема? Например, раньше было то-то и то-то, сейчас стало то-то и то-то. Или проблема в том, что производительность L2TP-туннеля разная при поднятии его с компьютера и со шлюза?

P.S. ответить смогу не раньше понедельника, 27 апреля сего года, не теряйте.

UPD3: прошу прощения за задержку с ответом.

Проблема кроется где-то в пересылке кадров в eth1 из ppp0 на программном уровне.

С этой проблемой я вам вряд ли помогу. В качестве попытки ухватиться за соломинку - у вас случайно qos/tc не настроен на шлюзе?

Comments

[tobut]

Пинги идентичные, как и скорость download-трафика. В ifconfig у каждого интерфейса errors: 0.
Я только упустил один момент. Не знаю как проверить скорость upload-а у самого шлюза. Пробовал использовать speedtest-cli, но он показывает скорость далекую от правды. Поэтому непонятно в чем именно проблема.

[throughtheether]

Не знаю как проверить скорость upload-а у самого шлюза.

iperf с публичным iperf-сервером. Надеюсь, ясно, что 'скорость' на шлюзе и на клиенте необходимо измерять до одного и того же сервера.
Если для доступа в интернет используется что-то сложнее обычного IPoE (т.е. VPN, PPPoE и т.д.), то проверьте параметры MTU/MSS.

[tobut]

throughtheether
MTU прописан, а MSS не знаю куда вписать (поднять xl2tpd). iperf-ом измерить не получается, так как нету гигабитного публичного сервера, хотя может я просто не знаю такового.

[throughtheether]

Public iperf server

[tobut]

throughtheether: Пробовал уже использовать eltel, но подумал сначала, что показывает неверно. Сейчас еще раз протестировал скорость (uplink не знаю как). На шлюзе download в 2 раза выше, чем на компьютере, то есть проблема не только в upload-e.

[throughtheether]

tobut: Я так понимаю, речь только о TCP? В UDP-режиме тестировали (например, iperf или торренты)? Утилизацию ресурсов (CPU и т.д.) на шлюзе проверяли?

[tobut]

throughtheether: Добавлю, что локальная скорость ограничивается только физическими характеристиками провода - 111 мбайт/c в обе стороны.
Интерфейс, который смотрит в локалку:

eth1      Link encap:Ethernet  HWaddr 64:70:02:11:ce:e4
          inet addr:ip  Bcast:ip  Mask:255.255.255.0
          inet6 addr: ip/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:128799865 errors:0 dropped:108 overruns:0 frame:0
          TX packets:92684301 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:111214808351 (103.5 GiB)  TX bytes:97842202608 (91.1 GiB)
          Interrupt:45 Base address:0xe000

Здесь я заметил появление dropped: 108.

И заодно кину ethtool eth1 (этого же интерфейса):

Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Advertised pause frame use: Symmetric Receive-only
        Advertised auto-negotiation: Yes
        Link partner advertised link modes:  10baseT/Half 10baseT/Full
                                             100baseT/Half 100baseT/Full
                                             1000baseT/Full
        Link partner advertised pause frame use: Symmetric
        Link partner advertised auto-negotiation: Yes
        Speed: 1000Mb/s
        Duplex: Full
        Port: MII
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: pumbg
        Wake-on: g
        Current message level: 0x00000033 (51)
                               drv probe ifdown ifup
        Link detected: yes

[tobut]

throughtheether: UDP померить не получается.

[  5] Sent 893 datagrams
[  7]  0.0-10.0 sec  1.25 MBytes  1.05 Mbits/sec
[  7] Sent 893 datagrams
[SUM]  0.0-10.0 sec  12.5 MBytes  10.5 Mbits/sec
[ 10] WARNING: did not receive ack of last datagram after 10 tries.
[ 11] WARNING: did not receive ack of last datagram after 10 tries.
[  8] WARNING: did not receive ack of last datagram after 10 tries.
[  6] WARNING: did not receive ack of last datagram after 10 tries.

С загрузкой процессора все нормально. Стоит i7, загрузку минимальная.

[throughtheether]

tobut:
Проверьте заодно параметры ethernet-интерфейса шлюза, смотрящего на провайдера. Если и там все в порядке (дуплекс, ошибки), то полагаю, дело все-таки в настройках TCP.
Скачайте один и тот же файл размером ~ 10 мегабайт (или подберите размер, чтобы файл качался хотя бы десять секунд) через tcp (например, wget-ом) с компьютера и со шлюза и снимите (и опубликуйте) дамп соответствующего трафика в виде .pcap/.pcapng файла.

[tobut]

throughtheether: Со вторым интерфейсом все отлично.
https://cloud.mail.ru/public/3VZDQKLZM2Wb/cap_eth0.pcap - слушал eth0 (интернет)
https://cloud.mail.ru/public/2MTN9apktN8U/cap_eth1.pcap - слушал eth1 (локальная сеть)
Извиняюсь за размер файлов, хотел сделать по 10 секунд.

[tobut]

throughtheether В первый раз я скачивал файл и слушал 2 интерфейса (eth0 - в интернет, eth1 - от компа). Сейчас сделал по-другому - скачал один файл со шлюза и компьютера. Прикладываю 2 файла. gateway.pcap - шлюз, computer.pcap - компьютер. Думаю, тут сразу видна разница в размерах.
gateway - https://cloud.mail.ru/public/5VsPnm4QmaRp/gateway.pcap
computer - https://cloud.mail.ru/public/yy6WtAZgbKc5/computer.pcap

Спасибо Вам за потраченное время.

[tobut]

throughtheether
У меня есть linux шлюз. На нем я поднимаю xl2tpd. Если качать файл wget-ом, то это gateway.pcap.
Далее идет компьютер, который подключен к шлюзу. Интернет раздается с помощью -A POSTROUTING -o ppp0 -j MASQUERADE (iptables на шлюзе), то есть на компьютере никакие vpn-клиенты не поднимаются. Тот же xl2tpd поднят на шлюзе. Если качать файл через компьютер, а мерить трафик на шлюзе, то это computer.pcap.
Проблема заключается в том, что при поднятом vpn-клиент на шлюзе, скорости на шлюзе и компьютере разные. Только скорости не 5мбайт/c и 2.5мбайт/c, а 50 и 25.

[tobut]

throughtheether
Добавлю, что проблема не в производительности l2tp-туннеля, так как скорость на шлюзе показывает, что xl2tpd справляется с нагрузкой. Проблема кроется где-то в пересылке кадров в eth1 из ppp0 на программном уровне.

[tobut]

throughtheether Нет, не настроены. Ставил чистый linux и только несколько пакетов для работоспособности интернета. Последнее, что хочу попробовать - пересобрать xl2tpd (много где пишут, что через ядро быстрее работает). Может что-то и даст. Спасибо за потраченное на меня время.

[tobut]

throughtheether Не подскажите чем Вы рисовали графики на основе pcap? Не смог найти ничего похожего. Интересно, как проанализировали трафик.

[throughtheether]

tobut: Использовал wireshark. Меню Statistics -> IO Graph.

Answer 3

[Alexandr]

habrahabr.ru/post/133076

Comments

[tobut]

Статья интересная, за что Вам спасибо. Но ничего похожего на мою проблему я не нашел. Шлюзом у меня служит чистый Debian, поэтому никаких изначальных настроек на нем нет - стоит pfifo_fast, что и нужно в моем случае.