LINUX.ORG.RU
решено ФорумAdmin

Debian 6, частичная проблема с пингом.


0

1

Добрый день.

Неделю назад поднял шлюз на Debian 6. Конфиг машины самый простой: Celeron 667, 256 MB RAM, 4.3 Gb HDD. Машина используется исключительно как маршрутизатор. Трафик не фильтруется. Работает только dnsmasq. 30 июля запустил машину, все было нормально (или же я просто не замечал) до сегодняшнего утра.

С утра сервер пинговался с большими потерями. Перезагрузка свитча ничего не дала. Ребутнул сервер грубо, т.к. машина AT, и без клавиатуры и монитора. Запустилась, проблема вроде бы пропала. В логах syslog, dmesg ничего подозрительного не увидел. Единственное, что в dmesg:

[   27.574859] eth0: no IPv6 routers present
[   28.174833] eth1: no IPv6 routers present
Прописал echo net.ipv6.conf.all.disable_ipv6=1 > /etc/sysctl.d/disableipv6.conf и сообщение пропало.

Сейчас иногда повторяется такая ситуация: пинг идет нормальный, затем на время возрастает или вообще пропадает:

Ответ от 192.168.0.1: число байт=32 время<1мс TTL=64
Ответ от 192.168.0.1: число байт=32 время<1мс TTL=64
Ответ от 192.168.0.1: число байт=32 время<1мс TTL=64
Ответ от 192.168.0.1: число байт=32 время<1мс TTL=64
Ответ от 192.168.0.1: число байт=32 время<1мс TTL=64
Ответ от 192.168.0.1: число байт=32 время<1мс TTL=64
Ответ от 192.168.0.1: число байт=32 время<1мс TTL=64
Ответ от 192.168.0.1: число байт=32 время=602мс TTL=64
Ответ от 192.168.0.1: число байт=32 время=1536мс TTL=64
Ответ от 192.168.0.1: число байт=32 время=3413мс TTL=64
Ответ от 192.168.0.1: число байт=32 время=208мс TTL=64
Ответ от 192.168.0.1: число байт=32 время=1145мс TTL=64
Ответ от 192.168.0.1: число байт=32 время=1511мс TTL=64
Ответ от 192.168.0.1: число байт=32 время=3507мс TTL=64
Ответ от 192.168.0.1: число байт=32 время=314мс TTL=64
Ответ от 192.168.0.1: число байт=32 время=1351мс TTL=64
Ответ от 192.168.0.1: число байт=32 время=69мс TTL=64
Ответ от 192.168.0.1: число байт=32 время=1391мс TTL=64
Ответ от 192.168.0.1: число байт=32 время=357мс TTL=64
Ответ от 192.168.0.1: число байт=32 время=660мс TTL=64
Ответ от 192.168.0.1: число байт=32 время<1мс TTL=64
Ответ от 192.168.0.1: число байт=32 время=734мс TTL=64
Ответ от 192.168.0.1: число байт=32 время<1мс TTL=64
Ответ от 192.168.0.1: число байт=32 время=2156мс TTL=64
Превышен интервал ожидания для запроса.
Ответ от 192.168.0.1: число байт=32 время<1мс TTL=64
Превышен интервал ожидания для запроса.
Ответ от 192.168.0.1: число байт=32 время=2838мс TTL=64
Ответ от 192.168.0.1: число байт=32 время=1978мс TTL=64
Ответ от 192.168.0.1: число байт=32 время=77мс TTL=64
Ответ от 192.168.0.1: число байт=32 время=98мс TTL=64
Ответ от 192.168.0.1: число байт=32 время=1189мс TTL=64
Превышен интервал ожидания для запроса.
Ответ от 192.168.0.1: число байт=32 время=1912мс TTL=64
Ответ от 192.168.0.1: число байт=32 время=2814мс TTL=64
Превышен интервал ожидания для запроса.
Ответ от 192.168.0.1: число байт=32 время=739мс TTL=64
Ответ от 192.168.0.1: число байт=32 время=2879мс TTL=64
Превышен интервал ожидания для запроса.
Ответ от 192.168.0.1: число байт=32 время<1мс TTL=64
Ответ от 192.168.0.1: число байт=32 время<1мс TTL=64
Ответ от 192.168.0.1: число байт=32 время<1мс TTL=64
Ответ от 192.168.0.1: число байт=32 время<1мс TTL=64
Ответ от 192.168.0.1: число байт=32 время<1мс TTL=64
Ответ от 192.168.0.1: число байт=32 время<1мс TTL=64
Ответ от 192.168.0.1: число байт=32 время<1мс TTL=64

В этот момент я был подключен к серверу через SSH и был запущен htop. Нагрузки не было вообще, т.е. 2-3%.

UPD: если во время глюка дать команду /etc/init.d/networking restart, то глюк пропадает. Так же, если вытащить кабель из сетевой, идущий к провайдеру, глюк тоже пропадает. Как будто забивается канал, но при чем здесь канал, идущий в локальную сеть.



Последнее исправление: massive (всего исправлений: 1)

Вроде как отловил баг. Получилось повторить, если открыть онлай-видео, к примеру youtube, то через 15 секунд наблюдаю опять проблемы с пингом (прокешироваться успевает только 1 - 1,5 минут). Странно, что утром до сервера вообще достучаться нельзя было. Ведь никто утром загрузить канал не мог :(.

massive
() автор топика

1) из той же сети, в которой находится lan адрес сервера ( из 192.168.0.0/24 , но не с самого сервера) попингуй адрес сервера утилитой arping. Если светятся два и больше MAC адресов - у тебя конфликт IP адресов. Также желательно проверить адреса шлюзов между тобой и сабжевым сервером

2) на сервере есть беспроводные карточки? wifi или какая-нибудь экзотика

3) Кабель от сервера до свича проверял?

4) ядро обновлял недавно? Если да, попробуй загрузить старую версию

5) также помониторь и в самом деле загрузку интерфейсов сервера

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

1) В сети всего 3 компьютера + сервер. Конфликт исключается. Разве что одинаковый мак на одной из машинок и на сетевой сервера, которая смотри в инет, а не в локалку. Теоретически из-за этого проблем не должно быть.

2) ничего такого нету. 2 сетевые, 100-Мбитные.

3) менял в момент лагов, лаги не пропадали.

4) ядро не обновлял. Как установил с самого начала, так и работает.

5) помониторю. iftop подойдет?

massive
() автор топика
Ответ на: комментарий от router

Вот скрины (не бить, за то, что с офтопика):

1) iftop на интерфейсе, смотрящем в инет в момент лага http://i41.fastpic.ru/big/2012/0807/dc/383790074b17564bca310aa8e61a92dc.jpg

2) нормальная работа http://i41.fastpic.ru/big/2012/0807/cc/d147e3e3a4e167c769032f0d307609cc.jpg

massive
() автор топика
Ответ на: комментарий от kam

Ок. Завтра попробую заменить свой свич.

massive
() автор топика

Поменял местами в /etc/udev/rules.d/70-persistent-net.rules сетевые карты. Проблема вроде пропала.

П.С. Глючная карта на чипе Surecom, нормальная на RLT8139.

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