Subnets.ru

**Андрей** » 30 июн 2010, 09:34

Привет всем.
Не знаю как назвать тему, т.к. с таким сталкиваюсь в первые.
Проблема в пингах. иллюстрации говорят сами за себя:

Э1.gif

Э2.gif

Скрины делал одновременно с 2х окон.
На пути пингования стоит сервер доступа NAS с поднятым NAT и роутер CISCO 7505.
Пинги, на интерфейс CISCO 7505, смотрящего в сторону провайдера, идут нормально - без потерь.

Подскажите, в чем может быть проблема?
Заранее благодарен.

**lehisnoe** » 30 июн 2010, 09:53

Подскажите, в чем может быть проблема?

В нагрузке на оборудование либо его конфигурации по дороге к IP назначения.

поставь winmtr и посмотри, на каком хопе начинаются проблемы.

**Андрей** » 30 июн 2010, 10:54

WinMTR - интересная программка.
Вот её результаты.

WinMTR.gif

172.16.0.1 - IP nat на NAS.
*.253 - ифейс CISCO 7505 смотрящий в мою сторону.
*.185 - gw провайдера.

Судя по наблюдениям - тормозит везде. И на NAS и на входном интерфейсе CISCO (*.253) и у провайдера. Больше всего на gw, конечно.

Пробовал гуглить по вопросу. Наткнулся на интересную статью:
http://dreamcatcher.ru/2009/11/30/Оптимизация-tcp/
Интересная информация указана о FreeBSD:

FreeBSD

Добавьте это в /etc/sysctl.conf и перезагрузитесь:

kern.ipc.maxsockbuf=16777216
net.inet.tcp.rfc1323=1

В FreeBSD 7.0 добавлена функция автокогфигурирования буферов. Но значения их можно отредактировать, так как по умолчанию буферы 256 KB, а это очень мало:

net.inet.tcp.sendbuf_max=16777216
net.inet.tcp.recvbuf_max=16777216

Для общего развития покажу еще несколько параметров, но их дефолтные значения и так хороши:

net.inet.tcp.sendbuf_auto=1 # Send buffer autotuning enabled by default
net.inet.tcp.sendbuf_inc=8192 # step size
net.inet.tcp.recvbuf_auto=1 # enabled
net.inet.tcp.recvbuf_inc=16384 # step size

У FreeBSD есть кое-какие ограничения, включенным по умолчанию. Это хорошо для модемных подключений, но может быть вредно для пропускной способности на высокоскоростных каналах. Если Вы хотите «нормальное» TCP Reno, сделайте следущее:

net.inet.tcp.inflight.enable=0

По умолчанию, FreeBSD кэширует подробности подключения, такие как порог slow start и размер окна перегрузки(congestion windows) с предыдущего подключения на тот же самый хост в течение 1 часа. В то время как это хорошая идея для веб-сервера, но плохая для тестирования пропускной способности, поскольку 1 большой случай перегрузки задушит производительность в течение следующего часа. Чтобы уменьшить этот эффект, установите это:

net.inet.tcp.hostcache.expire=1

В этом случае мы будем все еще кэшировать значения в течение 5 минут, по причинам, описанным в этой статье от Centre for Advanced Internet Architectures (CAIA) at Swinburne University in Autralia. В ней вы также найдете другую интересную информацию о тюнинге FreeBSD. Также можно использовать H-TCP patch for FreeBSD

Для получения информации о тюнинге NetBSD, обратитесь к этой статье.

Внимание: у FreeBSD версий ниже 4.10 нет реализации SACK, что сильно снижает ее производительность по сравнению с другими операционными системами. Вы необходимо обновиться до 4.10 или выше.

интересно надо ли оно?

**lehisnoe** » 30 июн 2010, 13:05

А потери при пинге 172.16.0.1 пакетами по 1450 байт есть?

**Андрей** » 30 июн 2010, 14:32

lehisnoe писал(а):А потери при пинге 172.16.0.1 пакетами по 1450 байт есть?

Было зарезано pf'ом.
Сейчас разрешил пинги, но на 530 пакетов получено 528.
При нагрузке на внешний ифейс ~5.5 kpps и трафике 29 мбит/с.

на gw провайдера из 530 пакетов дошло только 504.

Самое интересное, что ошибок на ифейсе нет:

Код: Выделить всё: # ifconfig | grep ng0 ng0: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1396

а это netstat

Код: Выделить всё: input (ng0) output packets errs bytes packets errs bytes colls 61 0 2604 109 0 114853 0 37 0 1480 70 0 76190 0 38 0 1520 69 0 72574 0 18 0 720 32 0 34048 0 38 0 2826 66 0 68963 0 17 0 680 32 0 34048 0 36 0 1440 66 0 68176 0 35 0 1400 65 0 68136 0 26 0 1568 31 0 34008 0 19 0 844 34 0 43396 0 30 0 1296 51 0 58308 0 25 0 3400 23 0 21810 0 32 0 1436 48 0 54789 0 21 0 924 34 0 37338 0 14 0 584 25 0 28994 0 32 0 4012 48 0 53113 0 11 0 476 19 0 22836 0 56 0 2240 109 0 117533 0 54 0 2160 105 0 108228 0 13 0 520 22 0 24411 0 45 0 2028 70 0 78226 0

Только сейчас предостерегло немного - mtu на ng0 - 1396. Я так понимаю, что это вообще не гуд?
Хотя вообще все ng ифейсы с установленным mtu 1396.

**lehisnoe** » 30 июн 2010, 17:42

Андрей писал(а):
lehisnoe писал(а):А потери при пинге 172.16.0.1 пакетами по 1450 байт есть?

Было зарезано pf'ом.

О, как... А как же ты пинговал и делал трассы раньше? Или же у тебя было запрещено хождение фрагментированных пакетов?

Андрей писал(а):Сейчас разрешил пинги, но на 530 пакетов получено 528.

По локалке не должно быть потерь вообще, тут они есть, но ничтожно малы (0,4%).

Андрей писал(а):При нагрузке на внешний ифейс ~5.5 kpps и трафике 29 мбит/с.
на gw провайдера из 530 пакетов дошло только 504.

5% - это уже много.
Что бы исключить NAS из цепочки разбора, запость вывод top -SH и результаты пинга пакетами по 1450 байт IP адреса, висящего на ифейсе NAS в сторону циски 7505.

Андрей писал(а):Самое интересное, что ошибок на ифейсе нет:
а это netstat
Код: Выделить всё
input (ng0) output packets errs bytes packets errs bytes colls 61 0 2604 109 0 114853 0 ...

Дык смотреть ошибки-то нужно на физическом ифейсе, на ифейсе ng ошибки ты увидишь только тогда, когда уже всему вокруг придет ппц

Андрей писал(а):
Код: Выделить всё
# ifconfig | grep ng0 ng0: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1396

Только сейчас предостерегло немного - mtu на ng0 - 1396. Я так понимаю, что это вообще не гуд?
Хотя вообще все ng ифейсы с установленным mtu 1396.

Мту рулишь ты ;-)

Смотри в настройки mpd - какое значение mtu ты там задал, такое на ифейсе и будет

**Андрей** » 01 июл 2010, 09:52

lehisnoe писал(а):О, как... А как же ты пинговал и делал трассы раньше? Или же у тебя было запрещено хождение фрагментированных пакетов?

icmp-траффик на этот Ip был закрыт, хотя каким-то образом, при трассировке, определялся ip, через который проходит пакет. pf.conf имеет строки:

Код: Выделить всё: set timeout { icmp.first 20, icmp.error 10 } ... pass in quick inet proto icmp from any to 10.10.2.2 icmp-type echoreq keep state

lehisnoe писал(а):запость вывод top -SH

Код: Выделить всё: last pid: 32709; load averages: 0.70, 0.66, 0.60 up 129+16:44:31 12:35:45 106 processes: 5 running, 83 sleeping, 18 waiting CPU: 0.2% user, 0.0% nice, 16.2% system, 1.1% interrupt, 82.5% idle Mem: 57M Active, 1445M Inact, 232M Wired, 5748K Cache, 112M Buf, 260M Free Swap: 10G Total, 10G Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 14 root 171 ki31 0K 8K CPU0 0 2709.9 93.55% idle: cpu0 13 root 171 ki31 0K 8K RUN 1 2840.2 89.70% idle: cpu1 11 root 171 ki31 0K 8K CPU3 3 2750.4 86.87% idle: cpu3 12 root 171 ki31 0K 8K CPU2 2 2456.3 75.88% idle: cpu2 33 root -68 - 0K 8K - 2 429.8H 17.68% em0 taskq 34 root -68 - 0K 8K - 0 175.7H 8.50% em1 taskq 2 root -68 - 0K 8K sleep 3 186.7H 8.40% ng_queue0 4 root -68 - 0K 8K sleep 2 186.6H 8.25% ng_queue2 5 root -68 - 0K 8K sleep 1 186.5H 8.06% ng_queue3 3 root -68 - 0K 8K sleep 3 186.3H 7.76% ng_queue1 15 root -32 - 0K 8K WAIT 0 246.7H 3.27% swi4: clock sio 57 root 20 - 0K 8K syncer 0 310:02 0.20% syncer 60155 flowtools 44 0 3484K 1616K select 3 29.2H 0.00% flow-capture 57042 root 44 0 62228K 32864K select 0 670:41 0.00% mpd5 18 root 44 - 0K 8K - 0 534:43 0.00% yarrow 51 root 8 - 0K 8K pftm 1 192:40 0.00% pfpurge 60228 flowtools 44 0 3740K 1856K select 3 141:09 0.00% flow-fanout

lehisnoe писал(а):результаты пинга пакетами по 1450 байт IP адреса, висящего на ифейсе NAS в сторону циски 7505

Код: Выделить всё: # ping -s 1442 ***.***.***.251 PING ***.***.***.251 (***.***.***.251): 1442 data bytes 1450 bytes from ***.***.***.251: icmp_seq=0 ttl=64 time=6.270 ms 1450 bytes from ***.***.***.251: icmp_seq=1 ttl=64 time=5.604 ms 1450 bytes from ***.***.***.251: icmp_seq=2 ttl=64 time=5.363 ms 1450 bytes from ***.***.***.251: icmp_seq=3 ttl=64 time=5.545 ms 1450 bytes from ***.***.***.251: icmp_seq=4 ttl=64 time=5.557 ms 1450 bytes from ***.***.***.251: icmp_seq=5 ttl=64 time=5.474 ms 1450 bytes from ***.***.***.251: icmp_seq=6 ttl=64 time=5.389 ms 1450 bytes from ***.***.***.251: icmp_seq=7 ttl=64 time=7.020 ms 1450 bytes from ***.***.***.251: icmp_seq=8 ttl=64 time=5.507 ms 1450 bytes from ***.***.***.251: icmp_seq=9 ttl=64 time=5.356 ms 1450 bytes from ***.***.***.251: icmp_seq=10 ttl=64 time=5.618 ms 1450 bytes from ***.***.***.251: icmp_seq=11 ttl=64 time=5.606 ms 1450 bytes from ***.***.***.251: icmp_seq=12 ttl=64 time=5.709 ms 1450 bytes from ***.***.***.251: icmp_seq=13 ttl=64 time=5.655 ms 1450 bytes from ***.***.***.251: icmp_seq=14 ttl=64 time=5.551 ms 1450 bytes from ***.***.***.251: icmp_seq=15 ttl=64 time=5.585 ms 1450 bytes from ***.***.***.251: icmp_seq=16 ttl=64 time=5.572 ms 1450 bytes from ***.***.***.251: icmp_seq=17 ttl=64 time=6.052 ms 1450 bytes from ***.***.***.251: icmp_seq=18 ttl=64 time=5.647 ms 1450 bytes from ***.***.***.251: icmp_seq=19 ttl=64 time=5.672 ms 1450 bytes from ***.***.***.251: icmp_seq=20 ttl=64 time=5.753 ms 1450 bytes from ***.***.***.251: icmp_seq=21 ttl=64 time=5.567 ms 1450 bytes from ***.***.***.251: icmp_seq=22 ttl=64 time=5.796 ms 1450 bytes from ***.***.***.251: icmp_seq=23 ttl=64 time=5.629 ms 1450 bytes from ***.***.***.251: icmp_seq=24 ttl=64 time=5.588 ms 1450 bytes from ***.***.***.251: icmp_seq=25 ttl=64 time=21.843 ms 1450 bytes from ***.***.***.251: icmp_seq=26 ttl=64 time=5.627 ms 1450 bytes from ***.***.***.251: icmp_seq=27 ttl=64 time=6.766 ms 1450 bytes from ***.***.***.251: icmp_seq=28 ttl=64 time=5.673 ms 1450 bytes from ***.***.***.251: icmp_seq=29 ttl=64 time=5.856 ms 1450 bytes from ***.***.***.251: icmp_seq=30 ttl=64 time=5.736 ms 1450 bytes from ***.***.***.251: icmp_seq=31 ttl=64 time=5.554 ms 1450 bytes from ***.***.***.251: icmp_seq=32 ttl=64 time=5.633 ms 1450 bytes from ***.***.***.251: icmp_seq=33 ttl=64 time=5.655 ms 1450 bytes from ***.***.***.251: icmp_seq=34 ttl=64 time=5.734 ms 1450 bytes from ***.***.***.251: icmp_seq=35 ttl=64 time=5.606 ms 1450 bytes from ***.***.***.251: icmp_seq=36 ttl=64 time=5.690 ms 1450 bytes from ***.***.***.251: icmp_seq=37 ttl=64 time=5.446 ms 1450 bytes from ***.***.***.251: icmp_seq=38 ttl=64 time=5.495 ms 1450 bytes from ***.***.***.251: icmp_seq=39 ttl=64 time=5.544 ms 1450 bytes from ***.***.***.251: icmp_seq=40 ttl=64 time=5.524 ms 1450 bytes from ***.***.***.251: icmp_seq=41 ttl=64 time=5.341 ms 1450 bytes from ***.***.***.251: icmp_seq=42 ttl=64 time=5.473 ms 1450 bytes from ***.***.***.251: icmp_seq=43 ttl=64 time=5.715 ms 1450 bytes from ***.***.***.251: icmp_seq=44 ttl=64 time=5.848 ms 1450 bytes from ***.***.***.251: icmp_seq=45 ttl=64 time=5.584 ms 1450 bytes from ***.***.***.251: icmp_seq=46 ttl=64 time=5.565 ms 1450 bytes from ***.***.***.251: icmp_seq=47 ttl=64 time=5.634 ms 1450 bytes from ***.***.***.251: icmp_seq=48 ttl=64 time=5.597 ms 1450 bytes from ***.***.***.251: icmp_seq=49 ttl=64 time=5.618 ms 1450 bytes from ***.***.***.251: icmp_seq=50 ttl=64 time=5.500 ms 1450 bytes from ***.***.***.251: icmp_seq=51 ttl=64 time=5.516 ms 1450 bytes from ***.***.***.251: icmp_seq=52 ttl=64 time=5.666 ms 1450 bytes from ***.***.***.251: icmp_seq=53 ttl=64 time=5.641 ms 1450 bytes from ***.***.***.251: icmp_seq=54 ttl=64 time=5.500 ms 1450 bytes from ***.***.***.251: icmp_seq=55 ttl=64 time=5.614 ms 1450 bytes from ***.***.***.251: icmp_seq=56 ttl=64 time=5.466 ms 1450 bytes from ***.***.***.251: icmp_seq=57 ttl=64 time=5.380 ms 1450 bytes from ***.***.***.251: icmp_seq=58 ttl=64 time=5.544 ms 1450 bytes from ***.***.***.251: icmp_seq=59 ttl=64 time=5.491 ms 1450 bytes from ***.***.***.251: icmp_seq=60 ttl=64 time=5.367 ms 1450 bytes from ***.***.***.251: icmp_seq=61 ttl=64 time=5.509 ms 1450 bytes from ***.***.***.251: icmp_seq=62 ttl=64 time=5.574 ms 1450 bytes from ***.***.***.251: icmp_seq=63 ttl=64 time=5.566 ms 1450 bytes from ***.***.***.251: icmp_seq=64 ttl=64 time=6.378 ms 1450 bytes from ***.***.***.251: icmp_seq=65 ttl=64 time=5.523 ms 1450 bytes from ***.***.***.251: icmp_seq=66 ttl=64 time=5.373 ms 1450 bytes from ***.***.***.251: icmp_seq=67 ttl=64 time=5.385 ms 1450 bytes from ***.***.***.251: icmp_seq=68 ttl=64 time=5.655 ms 1450 bytes from ***.***.***.251: icmp_seq=69 ttl=64 time=5.339 ms 1450 bytes from ***.***.***.251: icmp_seq=70 ttl=64 time=5.834 ms 1450 bytes from ***.***.***.251: icmp_seq=71 ttl=64 time=5.679 ms 1450 bytes from ***.***.***.251: icmp_seq=72 ttl=64 time=6.020 ms 1450 bytes from ***.***.***.251: icmp_seq=73 ttl=64 time=5.615 ms 1450 bytes from ***.***.***.251: icmp_seq=74 ttl=64 time=5.590 ms 1450 bytes from ***.***.***.251: icmp_seq=75 ttl=64 time=5.680 ms 1450 bytes from ***.***.***.251: icmp_seq=76 ttl=64 time=5.624 ms 1450 bytes from ***.***.***.251: icmp_seq=77 ttl=64 time=5.683 ms 1450 bytes from ***.***.***.251: icmp_seq=78 ttl=64 time=5.536 ms 1450 bytes from ***.***.***.251: icmp_seq=79 ttl=64 time=5.414 ms 1450 bytes from ***.***.***.251: icmp_seq=80 ttl=64 time=5.633 ms 1450 bytes from ***.***.***.251: icmp_seq=81 ttl=64 time=5.579 ms 1450 bytes from ***.***.***.251: icmp_seq=82 ttl=64 time=5.601 ms 1450 bytes from ***.***.***.251: icmp_seq=83 ttl=64 time=5.665 ms 1450 bytes from ***.***.***.251: icmp_seq=84 ttl=64 time=5.617 ms 1450 bytes from ***.***.***.251: icmp_seq=85 ttl=64 time=5.493 ms 1450 bytes from ***.***.***.251: icmp_seq=86 ttl=64 time=6.190 ms 1450 bytes from ***.***.***.251: icmp_seq=87 ttl=64 time=5.583 ms 1450 bytes from ***.***.***.251: icmp_seq=88 ttl=64 time=5.632 ms 1450 bytes from ***.***.***.251: icmp_seq=89 ttl=64 time=5.641 ms 1450 bytes from ***.***.***.251: icmp_seq=90 ttl=64 time=5.843 ms 1450 bytes from ***.***.***.251: icmp_seq=91 ttl=64 time=5.745 ms 1450 bytes from ***.***.***.251: icmp_seq=92 ttl=64 time=5.607 ms 1450 bytes from ***.***.***.251: icmp_seq=93 ttl=64 time=6.600 ms 1450 bytes from ***.***.***.251: icmp_seq=94 ttl=64 time=5.656 ms 1450 bytes from ***.***.***.251: icmp_seq=95 ttl=64 time=5.611 ms 1450 bytes from ***.***.***.251: icmp_seq=96 ttl=64 time=5.597 ms 1450 bytes from ***.***.***.251: icmp_seq=97 ttl=64 time=5.630 ms 1450 bytes from ***.***.***.251: icmp_seq=98 ttl=64 time=5.355 ms 1450 bytes from ***.***.***.251: icmp_seq=99 ttl=64 time=5.301 ms 1450 bytes from ***.***.***.251: icmp_seq=100 ttl=64 time=5.487 ms ^C --- ***.***.***.251 ping statistics --- 101 packets transmitted, 101 packets received, 0% packet loss round-trip min/avg/max/stddev = 5.301/5.808/21.843/1.626 ms

lehisnoe писал(а):Мту рулишь ты Смотри в настройки mpd - какое значение mtu ты там задал, такое на ифейсе и будет

Мож я что не понимаю.

:

Код: Выделить всё: # cat /usr/local/etc/mpd5/mpd.conf | grep mtu set link mtu 1460

Получается, что mtu для ng должен задаваться равный 1460, а он задается 1396.

**Андрей** » 01 июл 2010, 13:01

Я почему-то се болше склоняюсь в сторону NAS.
Загуглил по вопросу - нашел что-то типа:

Если кому будет необходимо, проблема была в данном параметре - hw.igb.lro=0
Есго надо было перенести в sysctl.conf (sysctl -w hw.igb.0.enable_lgo = 0

Оно ли?

На что давить в настройках sysctl?
Если не трудно - посоветуйте, какие переменные поднять, а какие занизить. Мне кажется вся проблема в этом. Т.к. почти все tcp сессии глючат.
На форуме нага нашел рекомендации, но для мпд3 и фри6.

Подозреваю в сторону:

Код: Выделить всё: # sysctl -a | grep net.inet.tcp.sendbuf_max net.inet.tcp.sendbuf_max: 262144 # sysctl -a | grep net.inet.tcp.recvbuf_max net.inet.tcp.recvbuf_max: 262144

Некоторые люди советуют поднять его до 16777216.

Вообще, если пытаться исключить глюки на NAS - я думаю попробовать пустить трафик через него на максимальной загрузке, только не через gw прова, а только через сам NAS. А дальше - не знаю. Может циска дохлая, а может еще что-то, хотя по числу пакетов - на ифейсах всего около 5-6 kpps. несколько странное поведение.

**Андрей** » 02 июл 2010, 08:41

РПерекинул файл со своего компа через нат на ноут.
Потерь нет. Скорость ~8 мб/с (при текущей нагрузке 30мбит/с). Общее число проходящих пакетов через нат составило ~10kpps.
Проблема обнаружилась на cisco7505. Точнее на порту, который смотрит на гейт прова.
Проблема несколько не стандартная. Опишу последовательность:
1. Сбрасываю статистику по порту.
2. Выставляю полный дуплекс. (автосогласование не поддерживается). Начинаются CRC ошибки и коллизии на приходящих пакетах.
3. Сбрасываю статистику по порту.
4. Выставляю полудуплекс. (автосогласование не поддерживается). Начинаются CRC ошибки и коллизии на исходящих пакетах.

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

**root** » 05 июл 2010, 11:20

Андрей писал(а):Созванивался с провайдером - у него на портах автосогласование. Попробуем принудительно выставить дуплекс - не знаю что из этого выйдет.

если на одной стороне выставляется жестко, то и на второй стороне нужно сделать тоже самое
CRC ошибки это плохо, отсюда и потери.
Если жесткое выставление не поможет, то переобожмите кабель, опять же с двух сторон, смените порты на оборудовании.

Subnets.ru

Задержки пинга.

Задержки пинга.

Re: Задержки пинга.

Re: Задержки пинга.

Re: Задержки пинга.

Re: Задержки пинга.

Re: Задержки пинга.

Re: Задержки пинга.

Re: Задержки пинга.

Re: Задержки пинга.

Re: Задержки пинга.

Кто сейчас на конференции