Странное временное отключение сети в Linux

Я сталкиваюсь с очень раздражающей проблемой, которую я заметил через неделю и на которую я не могу найти ответ: моя сеть внезапно перестает отвечать, обычно возвращаясь ровно через 25 секунд. Я использовал ядро ​​3.10.4 и теперь перешел на 3.11-rc4, чтобы посмотреть, изменилось ли что-то, но нет, поведение такое же. И поскольку эту проблему трудно обнаружить из-за того факта, что обычный веб-серфинг находится в «пакетном режиме», а отключение происходит случайно, я не могу сказать, что эта проблема присутствовала и в предыдущем ядре (я всегда использую пользовательские, но непатентованные ядра от kernel.org, все скомпилировано мной)

Я не могу сказать , что ядро является виновником либо, но я могу сказать , что нет подсказок на системных журналах (я проверил , как /var/log/syslogи /var/log/messagesи нет ничего необычного там) , и что оборудование не кажется , виноват, для проблемных шоу использовать одну из моих сетевых карт:

lspci output:

02:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5751 Gigabit Ethernet PCI Express (rev 01)
04:00.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 30)

и я уже пытался поменять порты коммутатора Ethernet, и до сих пор ни у кого, где я работаю, нет проблем, кроме меня (хотя мы используем аналогичные машины, я единственный использующий Linux, поэтому мне пришлось принять несколько позорных шуток по этому поводу, хорошо ... хе-хе).

Я запустил wireshark на своей машине и оставил его постоянно проверять наш шлюз и другую машину в том же сегменте сети. Затем, при первых признаках неисправности сети, я проверил это и убедился, что шлюз перестал отвечать на пинги, но другая машина все еще там реагировала нормально. Некоторое другое время - другая машина, которая перестает отвечать, и шлюз в порядке, и некоторые другие времена оба перестают отвечать. Я не знаю, что еще делать, поэтому мне нужна помощь или советы по дальнейшей отладке, поскольку системные журналы полностью нормальны.

У меня есть файл конфигурации ядра и файл захвата от Wireshark, показывающий ситуацию. Я могу опубликовать здесь или на каком-нибудь сайте, где кто-то вставит, если кому-то будет полезно разобраться в этом деле, просто дайте мне знать уровень детализации, который я должен использовать (я полагаю, что уровня пакета без необработанных данных будет достаточно)

Симптомы соответствуют конфликту IP-адресов. Конфликт IP-адресов возникает, когда ваш компьютер и другой компьютер в той же сети пытаются использовать один и тот же IP-адрес .

В локальной сети связи адресация основана на MAC-адресах . Каждая карта Ethernet имеет свой собственный MAC-адрес (исключая грубую неправильную конфигурацию или злонамеренную работу). Маршрутизатор, решающий, куда отправить IP- пакет, отправит запрос ARP для целевого IP-адреса на все свои порты. Это сообщение иногда называют «кто имеет»: маршрутизатор пытается выяснить, кто из его партнеров отвечает за этот IP-адрес. Как только маршрутизатор получает ответ, содержащий MAC-адрес, он может построить и отправить кадр Ethernet (пакет Ethernet), содержащий IP-пакет, на этот MAC-адрес. Поскольку этот обмен занимает некоторое время, маршрутизатор хранит кэш последней информации ARP. (Существуют и другие типы сообщений ARP, но того, что я здесь объяснил, достаточно, чтобы понять существующую проблему.)

Таким образом, в двух словах, маршрутизаторы должны знать, какому физическому устройству соответствует каждый IP-адрес, на который они отправляют IP-пакеты. Так что же происходит, когда два устройства запрашивают один и тот же IP-адрес? Маршрутизатор получает ответ от одного из устройств и с этого момента решает, что этот IP-адрес принадлежит этому устройству, пока не истечет срок действия соответствующей записи в кэше. После истечения срока действия записи в кеш маршрутизатор отправит новый запрос ARP, и, возможно, другое устройство ответит быстрее на этот раз. Это объясняет, почему такие ситуации нестабильны: в одну минуту маршрутизатор разговаривает с вами, в следующую минуту - с другим парнем.

Если вы постоянно пингуете кого-то, то маршрутизатор почти всегда сохраняет ваш IP-адрес в своем кэше ARP. Таким образом, пока вы пингуетесь, есть только небольшое окно, в течение которого другой парень может заменить вас в кеше (после того, как истечет срок действия вашей записи в кэше, до того, как придет следующий пинг). Вот почему наблюдение за проблемой делает ее в основном исчезающей, что может расстраивать, пока вы не поймете, в чем проблема.

В вашем случае, похоже, ваш локальный маршрутизатор хранит записи в своем кэше в течение 25 секунд. Когда вы в кеше, у вас все хорошо на 25 секунд. Затем иногда приходит другой парень, в случайные моменты, и ты выходишь из него на 25 секунд.

Когда вы пытаетесь соединиться с несколькими компьютерами по одной и той же локальной ссылке, у каждой из них есть своя собственная таблица ARP, поэтому вы можете наблюдать противоречивые результаты: одна машина решает, что вы владеете IP-адресом, а другая - что другой.

Высококачественные маршрутизаторы регистрируют конфликты IP-адресов, поэтому, если вы думаете, что столкнулись с ним, обратитесь за помощью к системному администратору. Сначала убедитесь, что не ваша машина пытается использовать IP-адрес, который не должен использоваться!

Я собираюсь предположить, что у вас есть 2 записи «nameserver» /etc/resolv.conf, и первая запись относится к DNS-серверу, который периодически недоступен или недоступен или что-то такое. Код распознавателя в libc будет пробовать первый IP-адрес сервера имен, получит тайм-аут, а затем попробует второй IP-адрес сервера имен, что успешно.

Чтобы проверить это, вы можете заменить IP-адреса «сервера имен» /etc/resolv.confтолько одним, 8.8.8.8, который является общедоступным DNS-сервером Google. Если сбой не происходит, проблема связана с вашим сервером имен.