a-zazell Опубликовано 2 ноября, 2011 (изменено) · Жалоба Здравствуйте, столкнулся с неприятной проблемой, скорость отдачи от клиентов за NATом не превышает 800Kbit/s, при этом отдача напрямую с внешнего wan интерфейса (wget http://...) дает 8Мбит/с на отдачу (upload). Загрузка у клиентов в порядке - 10 Мбит/с. Есть NAT сервер: интерфейсы wan смотрит к прову, lan в локалку. На lan повешены vlans. Настроен NAT локальных сетей посредством iptables. Конкретнее: Система # uname -a Linux SERVER 2.6.26-2-686 #1 SMP Thu Aug 19 03:44:10 UTC 2010 i686 GNU/Linux Интерфейсы: WAN # ifconfig wan wan Link encap:Ethernet HWaddr 00:17:31:72:d3:86 inet addr:<WAN_IP> Bcast:<WAN_BCAST> Mask:<WAN_MASK> inet6 addr: <ipv6_ip> Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:8254 errors:0 dropped:0 overruns:0 frame:0 TX packets:8077 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:5057773 (4.8 MiB) TX bytes:1280005 (1.2 MiB) Interrupt:220 Base address:0xe000 LAN (конкретнее vlan): # ifconfig vlan10 vlan10 Link encap:Ethernet HWaddr 00:e0:4d:06:6d:77 inet addr:192.168.1.1 Bcast:192.168.1.31 Mask:255.255.255.224 inet6 addr: fe80::2e0:4dff:fe06:6d77/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:12632 errors:0 dropped:0 overruns:0 frame:0 TX packets:4108 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:991895 (968.6 KiB) TX bytes:601837 (587.7 KiB) IPTABLES (грузим по iptables-restore < iptables.txt ): # cat iptables.txt *nat :PREROUTING ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] :OUTPUT ACCEPT [0:0] -F -X -A POSTROUTING -o wan -j SNAT --to-source <wan_ip_address> COMMIT *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] -F -X # Isolate VLANs -I FORWARD -i vlan10 -o ! wan -j DROP -m comment --comment "Isolate Vlan10" ... ... COMMIT iperf в локальную сеть дает около 80Mbit/s в обе стороны. iperf в сеть провайдера (сервер iperf -s у прова, клиент на сервере с NAT iperf -c <ip_iperf_server>) также дает не больше 800Kbit/s. Если для анализа нужна доп инфа - с радостью. Может кто-то сталкивался? Буду признателен за внимание! Изменено 17 ноября, 2011 пользователем a-zazell Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 3 ноября, 2011 · Жалоба tc -s qdisc show dev wan tc -s qdisc show dev vlan10 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
a-zazell Опубликовано 3 ноября, 2011 · Жалоба tc -s qdisc show dev wan tc -s qdisc show dev vlan10 Да, спасибо, забыл. Вот: Wan: tc qdisc add dev wan root handle 1 htb default 100 tc class add dev wan parent 1: classid 1:2 htb rate 10240kbit prio 1 #1:3 ICMP tc class add dev wan parent 1:2 classid 1:30 htb rate 128kbit prio 1 tc qdisc add dev wan parent 1:30 sfq #tc filter add dev wan parent 1: protocol ip prio 1 u32 match ip sport 22 0xffff flowid 1:22 tc filter add dev wan parent 1: protocol ip prio 1 u32 match ip protocol 1 0xff classid 1:30 #1:22 SSH tc class add dev wan parent 1:2 classid 1:22 htb rate 512kbit ceil 768kbit prio 1 tc qdisc add dev wan parent 1:22 sfq #tc filter add dev wan parent 1: protocol ip prio 1 u32 match ip sport 22 0xffff flowid 1:22 tc filter add dev wan parent 1: protocol ip prio 1 u32 match ip sport 22 0xffff classid 1:22 #1:80 HTTP tc class add dev wan parent 1:2 classid 1:80 htb rate 10240kbit prio 2 tc qdisc add dev wan parent 1:80 sfq tc filter add dev wan parent 1: protocol ip prio 3 u32 match ip sport 80 0xffff classid 1:80 tc filter add dev wan parent 1: protocol ip prio 3 u32 match ip sport 443 0xffff classid 1:80 tc filter add dev wan parent 1: protocol ip prio 1 u32 match ip sport 8080 0xffff classid 1:80 tc filter add dev wan parent 1: protocol ip prio 1 u32 match ip sport 8081 0xffff classid 1:80 #1:100 Default tc queue tc class add dev wan parent 1: classid 1:100 htb rate 10240kbit prio 8 tc qdisc add dev wan parent 1:100 sfq Статистика: # tc -d -s qdisc ls dev wan qdisc htb 1: root r2q 10 default 100 direct_packets_stat 2 ver 3.17 Sent 168623257 bytes 1438051 pkt (dropped 0, overlimits 8429 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 qdisc sfq 801d: parent 1:30 limit 127p quantum 1514b flows 127/1024 Sent 6937267 bytes 43006 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 qdisc sfq 801e: parent 1:22 limit 127p quantum 1514b flows 127/1024 Sent 18236 bytes 100 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 qdisc sfq 801f: parent 1:80 limit 127p quantum 1514b flows 127/1024 Sent 9534 bytes 80 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 qdisc sfq 8020: parent 1:100 limit 127p quantum 1514b flows 127/1024 Sent 161658024 bytes 1394862 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 Vlan10: tc qdisc add dev vlan10 root handle 1 htb tc class add dev vlan10 parent 1: classid 1:1 htb rate 10240kbit prio 1 tc class add dev vlan10 parent 1:1 classid 1:10 htb rate 768kbit ceil 10240kbit tc qdisc add dev vlan10 parent 1:10 sfq tc filter add dev vlan10 parent 1: protocol ip pref 4 u32 match ip dst <local_subnet> classid 1:10 Статистика: # tc -d -s qdisc ls dev vlan10 qdisc htb 1: root r2q 10 default 0 direct_packets_stat 401 ver 3.17 Sent 17518458 bytes 72626 pkt (dropped 0, overlimits 4843 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 qdisc sfq 8021: parent 1:10 limit 127p quantum 1518b flows 127/1024 Sent 17501616 bytes 72225 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 Но дело в том, что для начала снес все tc root для всех интерфейсов, проблема не ушла. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 3 ноября, 2011 · Жалоба Попробуйте ethtook -K wan tso off gso off gro off ethtook -K vlan10 tso off gso off gro off Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
a-zazell Опубликовано 3 ноября, 2011 · Жалоба Попробуйте ethtook -K wan tso off gso off gro off ethtook -K vlan10 tso off gso off gro off Так-так, интересно - на данный момент: # ethtool -k wan Offload parameters for wan: Cannot get device flags: Operation not supported rx-checksumming: off tx-checksumming: off scatter-gather: off tcp segmentation offload: off udp fragmentation offload: off generic segmentation offload: off large receive offload: off # ethtool -k lan Offload parameters for lan: Cannot get device rx csum settings: Operation not supported Cannot get device flags: Operation not supported rx-checksumming: off tx-checksumming: on scatter-gather: on tcp segmentation offload: off udp fragmentation offload: off generic segmentation offload: on large receive offload: off Но, блин, и ситуация поменялась (tc root удалены со всех интерфейсов): С машины за NAT-ом: (Windows OS)>iperf -c <iperf_serv_ip> ------------------------------------------------------------ Client connecting to <iperf_serv_ip>, TCP port 5001 TCP window size: 8.00 KByte (default) ------------------------------------------------------------ [1948] local 192.168.1.2 port 2555 connected with <iperf_serv_ip> port 5001 [ ID] Interval Transfer Bandwidth [1948] 0.0-10.0 sec 1.50 MBytes 1.25 Mbits/sec С NAT сервера: # iperf -c <iperf_serv_ip> -t 30 ------------------------------------------------------------ Client connecting to <iperf_serv_ip>, TCP port 5001 TCP window size: 16.0 KByte (default) ------------------------------------------------------------ [ 3] local <local_ip> port 40731 connected with <iperf_serv_ip> port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-30.0 sec 8.34 MBytes 2.33 Mbits/sec Сейчас попробую на LAN вырубить все чексуммы... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
a-zazell Опубликовано 3 ноября, 2011 · Жалоба Сейчас попробую на LAN вырубить все чексуммы... Получил пока вот: # ethtool -K lan tx off sg off gso off Cannot set device tx csum settings: Operation not supported # ethtool -k lan Offload parameters for lan: Cannot get device rx csum settings: Operation not supported Cannot get device flags: Operation not supported rx-checksumming: off tx-checksumming: on scatter-gather: on tcp segmentation offload: off udp fragmentation offload: off generic segmentation offload: on large receive offload: off Может как вариант перезагрузить модуль в ядре?? Тут вот есть: # lspci 00:07.0 Bridge: nVidia Corporation MCP61 Ethernet (rev a2) - это wan 01:06.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) - lan # lspci -kvs 01:06.0 01:06.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) Subsystem: Realtek Semiconductor Co., Ltd. RT8139 Flags: bus master, medium devsel, latency 64, IRQ 19 I/O ports at d800 [size=256] Memory at ddeffc00 (32-bit, non-prefetchable) [size=256] Expansion ROM at 50000000 [disabled] [size=128K] Capabilities: [50] Power Management version 2 Kernel driver in use: 8139too Kernel modules: 8139too, 8139cp Не помогло: #rmmod 8139cp #rmmod 8139too #modprobe 8139too #modprobe 8139cp # ethtool -K lan tso off gso off gro off Cannot set device tcp segmentation offload settings: Operation not supported Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
a-zazell Опубликовано 4 ноября, 2011 · Жалоба Короче надо видимо пробовать 2ух головую сетевую ... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Justas Опубликовано 4 ноября, 2011 · Жалоба Как это: отдача напрямую с внешнего wan интерфейса (wget http://...) дает 8Мбит/с на отдачу (upload). коррелирует у вас с этим: iperf в сеть провайдера (сервер iperf -s у прова, клиент на сервере с NAT iperf -c <ip_iperf_server>) также дает не больше 800Kbit/s. ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
a-zazell Опубликовано 4 ноября, 2011 · Жалоба Как это: отдача напрямую с внешнего wan интерфейса (wget http://...) дает 8Мбит/с на отдачу (upload). коррелирует у вас с этим: iperf в сеть провайдера (сервер iperf -s у прова, клиент на сервере с NAT iperf -c <ip_iperf_server>) также дает не больше 800Kbit/s. ? Так: (NAT_server)#dd if=/dev/zero of=/var/www/1000 bs=1024 count=1024 (ISP_network_host)#wget http://<NAT_server_ip>/1000 Выдает 8 Мбит/с по (NAT_server)#iftop -i wan -n -F <ISP_network_host_ip>/32 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Justas Опубликовано 4 ноября, 2011 · Жалоба То есть, когда кто-то получает файл по протоколу http с wan-интерфейса NAT-сервера, то можно зафиксировать скорость 8 мбит. Если же воспользоваться утилитой iperf и измерить ею утилизацию wan-интерфейса исходящим трафиком, то зафиксируем скорость 800 кбит. Я всё правильно понял? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
a-zazell Опубликовано 5 ноября, 2011 · Жалоба То есть, когда кто-то получает файл по протоколу http с wan-интерфейса NAT-сервера, то можно зафиксировать скорость 8 мбит. Если же воспользоваться утилитой iperf и измерить ею утилизацию wan-интерфейса исходящим трафиком, то зафиксируем скорость 800 кбит. Я всё правильно понял? Да, правда вчера iperf до 2,85Мбит/с давал. Понимаю - смотрится странно ... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 5 ноября, 2011 · Жалоба Не странно. Можно извне посмотреть http-заголовки, отдаваемые при wget с Вашего сервера? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 5 ноября, 2011 · Жалоба Возможно у сервера прова надо подтюнить TCP? Вообще факт высокой скорости на сервер прова с iperf -s был? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
a-zazell Опубликовано 5 ноября, 2011 · Жалоба Не странно. Можно извне посмотреть http-заголовки, отдаваемые при wget с Вашего сервера? (isp_host)$ wget --server-response http://<nat_server_wan_ip_addr>/1000 --2011-11-05 21:18:42-- http://<nat_server_wan_ip_addr>/1000 Устанавливается соединение с <nat_server_wan_ip_addr>:80... соединение установлено. Запрос HTTP послан, ожидается ответ... HTTP/1.1 200 OK Date: Sat, 05 Nov 2011 18:25:18 GMT Server: Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny9 with Suhosin-Patch mod_python/3.3.1 Python/2.5.2 mod_perl/2.0.4 Perl/v5.10.0 Last-Modified: Wed, 02 Nov 2011 16:14:48 GMT ETag: "c-40000000-4b0c2c55a0e00" Accept-Ranges: bytes Content-Length: 1073741824 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Content-Type: text/plain; charset=utf-8 Длина: 1073741824 (1,0G) [text/plain] Сохраняется в каталог: `1000'. Честные 10Мбит/с ... по (nat_server)# iftop -i wan -n -F <isp_host_ip>/32 А вот при: (isp_host)$ iperf -s ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 85.3 KByte (default) ------------------------------------------------------------ [ 4] local <isp_host_ip> port 5001 connected with <nat_server_wan_ip_addr> port 57467 [ ID] Interval Transfer Bandwidth [ 4] 0.0-10.3 sec 4.75 MBytes 3.88 Mbits/se (nat_server)# iperf -c <isp_host_ip> ------------------------------------------------------------ Client connecting to <isp_host_ip>, TCP port 5001 TCP window size: 16.0 KByte (default) ------------------------------------------------------------ [ 3] local <nat_server_wan_ip_addr> port 57467 connected with <isp_host_ip> port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.1 sec 4.75 MBytes 3.96 Mbits/sec Не понятно ... Возможно у сервера прова надо подтюнить TCP? Вообще факт высокой скорости на сервер прова с iperf -s был? Ну вот на другой хост прова: (nat_server)# iperf -c <isp_host2_ip> ------------------------------------------------------------ Client connecting to <isp_host2_ip>, TCP port 5001 TCP window size: 16.0 KByte (default) ------------------------------------------------------------ [ 3] local <nat_server_wan_ip> port 51307 connected with <isp_host2_ip> port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 5.19 MBytes 4.34 Mbits/sec Наверно тему надо закрывать ... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Justas Опубликовано 5 ноября, 2011 · Жалоба Тему закрывать незачем. Ну, а проблема не в NAT-е. Пошукайте по sysctl.conf, поставьте последние драйверы на сетевую карту. Подключите к wan свой стопроцентно рабочий компьютер, потестируйте линию между машинами. Но, похоже что у вашего провайдера скорость от вас зажимается по tc ingress и выставлен некорректный burst. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 6 ноября, 2011 (изменено) · Жалоба Вообще очень похоже на обжатие по типу сервиса... Попробуйте на 80 порт у себя повесить iperf :) Изменено 6 ноября, 2011 пользователем Alex/AT Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
a-zazell Опубликовано 17 ноября, 2011 (изменено) · Жалоба Тему закрываю, причина в специфике организации линии в сети провайдера. Изменено 17 ноября, 2011 пользователем a-zazell Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...