Это продолжение сервер ubuntu, ssh, ошибка записи: сломана труба. Я задаю новый вопрос, потому что не верю, что проблема связана с ssh / ubuntu.
У меня есть два новых сервера (Dell PowerEdge R715, R210) с установленным на них сервером Ubuntu 10.04 64bit. Я использую стек коммутаторов Cisco 3750 с двумя брандмауэрами / маршрутизаторами Juniper SRX240. Настройка в основном представляет собой маршрутизатор на флешке, у нас есть 3 vlan: один внутренний, один dmz и одна сеть хранения (iSCSI) в одном стеке. В стеке Cisco не выполняется коммутация уровня 3, а DMZ полностью изолирована от стека на другом коммутаторе.
В этой же сети (и стеке) есть около 10 других серверов Dell PoerEdge, которые годами работают без проблем. Большинство из них работают под управлением SLES 10 или openSUSE, но один работает под управлением сервера Ubuntu 10.04 64bit. Я отключил все сетевые адаптеры на этих новых серверах, кроме тех, которые подключены к нашему внутреннему vlan.
Если я загружаю одну (или обе) машины и позволяю им сидеть примерно на десять минут, мы начинаем получать до 20% потерь пакетов с других машин в сети и до 40-50% потерь пакетов с серверов-нарушителей.
Кто-нибудь знает, почему это может происходить, и что я могу сделать для устранения проблемы? Я не против вытереть эти коробки, если понадобится, данных о производстве на них пока нет.
Я бы начал с просмотра буферов журнала коммутатора (или системного журнала, в который вы их экспортируете, если он у вас есть).
В прошлом я видел проблемы с компьютерами Linux с несколькими сетевыми адаптерами, которые неправильно реагировали на ARP (например, «не на ожидаемом интерфейсе»), и еще больше проблем с блейд-модулями в корпусе блейд-сервера, где к коммутатору было подключено несколько виртуальных локальных сетей. , но нет (рабочего) способа наложить VLAN на фактический блейд-коммутатор. Это должно отображаться в журналах как жалобы, связанные с MAC.
В качестве второго шага все станет лучше, если вы включите arp_filter на все интерфейсы на ваших новых серверах?
У меня была аналогичная проблема, и она была вызвана тем, что несколько виртуальных машин были настроены с одним и тем же MAC-адресом. Просто создание нового решило проблему.
У меня возникла та же проблема, но с несколькими виртуальными машинами. Оказалось, что это настройки брандмауэра на моей машине.