У меня есть сервер Linux, на котором размещается наше программное обеспечение для отслеживания ошибок (CentOS 5.2 Kernel 2.6.18-128.4.1.el5), с которым у меня возникли странные проблемы с сетью. Машина сконфигурирована с двумя сетевыми адаптерами, одна для публичного интерфейса, а другая для внутренней сети нашего сервера.
Проблема в том, что после перезапуска служебной сети я могу проверить связь с общедоступным интерфейсом, и он отправит от 200 до 500 пакетов ICMP, а затем внезапно я начинаю получать ошибку тайм-аута запроса. Странно, но как только я подключаюсь к частному интерфейсу, пинг снова начинает работать с публичным интерфейсом. У меня явно где-то проблема с маршрутизацией.
У меня есть Juniper Router со следующей конфигурацией.
Интерфейс 0/0 - Подключите подсеть к провайдеру в нашем совместном размещении. Интерфейс 0/2 - Для нашего сетевого интерфейса DRAC 0/3 - Серверная сеть (подключается непосредственно к коммутатору, который подает сигнал на все сетевые адаптеры, которые находятся в сети 10.3.20.x. Интерфейс 0/4 - подключается непосредственно к другому коммутатору, который питает наши общедоступные интерфейсы, этот интерфейс как все шлюзы из нашего общедоступного IP-адреса звенит как вторичные IP-адреса.
Я надеюсь, что кто-то сможет задать правильные вопросы, которые помогут мне проверить и понять, что происходит. Были ли у кого-нибудь подобные проблемы и что я должен проверить? Проблема с маршрутизацией или что-то еще более сложное?
[root@fogbugz ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
# Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+
DEVICE=eth0
BOOTPROTO=static
IPADDR=72.249.134.98
NETMASK=255.255.255.248
BROADCAST=72.249.134.103
HWADDR=00:16:3E:AA:BB:EE
ONBOOT=yes
[root@fogbugz ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth1
# Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+
DEVICE=eth1
BOOTPROTO=static
BROADCAST=10.3.20.255
HWADDR=00:17:3E:AA:BB:EE
IPADDR=10.3.20.25
NETMASK=255.255.255.0
NETWORK=10.3.20.0
ONBOOT=yes
[root@fogbugz ~]# cat /etc/sysconfig/network
NETWORKING=yes
NETWORKING_IPV6=no
HOSTNAME=fogbugz.dfw.hisg-it.net
GATEWAY=72.249.134.97
[root@fogbugz ~]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
72.249.134.96 0.0.0.0 255.255.255.248 U 0 0 0 eth0
10.3.20.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
10.0.0.0 10.3.20.1 255.0.0.0 UG 0 0 0 eth1
0.0.0.0 72.249.134.97 0.0.0.0 UG 0 0 0 eth0
Две вещи: во-первых, у вас могут быть проблемы с асимметричной маршрутизацией с брандмауэрами, это распространенный случай, когда соединения устанавливаются на несколько секунд, а затем умирают.
Другой - Linux RPF, чтобы отключить его, установите этот sysctl:
net.ipv4.conf.all.rp_filter=0
Пожалуйста, покажите результат route -n и arp -an когда сеть не работает.
Показывать, как это выглядит, когда все работает, бесполезно. ;)
Проверьте вывод 'arp -an' как в рабочем, так и в нерабочем состоянии и найдите MAC-адреса / IP-адреса на неправильных интерфейсах.
Если вы видите, что там что-то не так, возможно, вы соединили несколько сегментов сети или у вас проблема с прокси-ARP?
Какой сетевой адаптер на этом сервере? Я несколько раз сталкивался с подобными проблемами на сетевой карте набора микросхем Marvell. Обычно проблема с драйвером и проблема с BIOS.
У нас такая же проблема. Были на RHEL 5.3, 2.6.18-128.el5 У нас возникла проблема с нашим маршрутом к нашей частной сети. Он продолжал падать. Мы нашли обходной путь. Мы помещаем это в наш crontab, и это решает проблему. * * * * * / sbin / arp -d IP для хранения
http://kbase.redhat.com/faq/docs/DOC-17338 выше работайте с вами.
Испытывали проблему с ядром linux с драйвером realtek на некоторых платах, где тайм-ауты сторожевого таймера приводили к прекращению работы сетевых интерфейсов. Единственный способ - сбросить настройки сети и / или modprobe ko-файла для модуля. Проверьте / var / log / messages на наличие таких сообщений.