LINUX.ORG.RU
ФорумAdmin

Постоянно растущее количество drop в ifconfig и проблемы с сетью

 , , ,


0

1

Здравствуйте! Имеется компьютер под управлением Ubuntu Linux 12.04 LTS (3.2.0-67-generic), выполняющий роль шлюза. В его распоряжении две сетевых карты Intel Corporation 82574L Gigabit Network Connection, с драйвером e1000e версии 3.1.0.2-NAPI (самый свежий), одна карта смотрит в локальную сеть (соединена с неуправляемым коммутатором), другая в интернет (с белым IP адресом). Forwarding включен, трафик фильтрует iptables. Два года работы не приносили никаких неприятностей, но неделю назад начались глюки (к серверу никто не прикасался месяц), выражались они низкой скоростью передачи данных (~800 кбайт/с) от шлюза к клиентам (наблюдалось как при обращении к локальным ресурсам шлюза, так и к forwarding интернет трафику). То есть проблемы наблюдались только при участии адаптера смотрящего в локальную сеть, в то время, как при input\output Интернет трафике на самом шлюзе всё было замечательно. Для нахождения причин глюков на шлюзе был запущен tcpdump -e -ni eth0, который показал множество сообщений MPCP, Opcode Pause, length 46. В итоге был найден ВЫКЛЮЧЕННЫЙ компьютер, который «гадил» в сеть, то есть при отключении от него LAN кабеля сообщения на шлюзе пропадали и всё начинало отлично работать. Но рано я обрадовался, на следующий день продолжились проблемы, проходящий трафик через шлюз сильно «застревает» - пакеты теряются, соединения на клиентах (например) с почтовыми/VPN серверами рвутся, работают нестабильно, при чём проблемы только в одну сторону - RX шлюза, c TX проблем нет. tcpdump уже ничего аномального не показывает. Менял сетевые карты, откатывал ядро, обновлял драйвер e1000e, отключал разгрузки и аппаратное управление потоком, менял свич, ничего не помогает. Заметил, что сильно растёт счётчик dropped в ifconfig у адаптера, смотрящего в локальную сеть, за сутки получилось вот такое значение - «dropped:31728883», и оно дальше растёт в тот момент, когда наблюдаются проблемы с соединениями у клиентов. После долгих мыторств начал эксперименты с MTU и txqueuelen на данном интерфейсе, в итоге с параметрами MTU:9000 и txqueuelen:500 пакеты стали теряться значительно реже, но всё равно счётчик dropped растёт и иногда возникают жалобы у клиентов при работе с почтовыми серверами (письма не отправляются, так как происходит Timeout при передаче тела письма). Подскажите, пожалуйста, что диагностировать, как решить возникшую проблему? Заранее спасибо!

Вот вырезка ifconfig для адаптера, смотрящего в локальную сеть eth0: UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1 RX packets:128558579 errors:24 dropped:31728883 overruns:0 frame:24 TX packets:195386217 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:16937813554 (16.9 GB) TX bytes:168058180665 (168.0 GB)

Для адаптера, смотрящего в интернет eth1: UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:25854765 errors:0 dropped:0 overruns:0 frame:0 TX packets:18219723 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:23325670902 (23.3 GB) TX bytes:3364102002 (3.3 GB)

На всякий случай, что показывает
grep -i «reset adapter» /var/log/messages

Есть такая беда, что работе сетевых устройств на PCI-E мешает Active-State Power Management иногда. Как раз, именно с e1000 и e1000e я по этим граблям походил. Если это то же самое, то должно помочь pcie_aspm=off в параметрах ядра.

AS ★★★★★
()
Ответ на: комментарий от jonnyquest

Частично помогло

Уменьшил третье значение: echo «4096 87380 174760» > /proc/sys/net/ipv4/tcp_rmem

Дропы отсутствуют около часа.

jonnyquest
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.