LINUX.ORG.RU

Периодически пропадает сеть

 ,


0

1

Имеется домашний «сервер» под управлением Debian. На eth0 висит домашняя сеть, на eth1 - провайдер. С месяц назад появилась проблема: каждые ~30 минут на 10 - 20 секунд пропадает сеть на eth1. Линк при этом есть, сетевая карточка активно моргает, tcpdump говорит что пакеты отправляются, dmesg молчит. Сам сервер при этом из домашней сети не пропадает (можно зайти по http, пинг идёт, nfs шара работает, etc). Но по ssh зайти на сервер в эти моменты невозможно (при этом уже установленное соединения прекрасно работает).

Что не помогло:
1. Переподключение (вытащить, вставить) сетевого кабеля.
2. Замена сетевой карты (проверял 3 разных карты).
3. Подключение сети напрямую к ноутбуку (arch linux).
4. Подключение сети напрямую к отдельному пк (arch linux).
5. Подключение к встроенной сетевой карточке (которая в домашней сети работает идеально).

Что помогло:
1. /etc/init.d/networking restart возвращает сеть к жизни.
2. Тот-же отдельный пк, но под управлением windows (за ~2 часа тестирования 0% потерь)

Дополнительно:
1. Момент «подвисания»
2. Однако arp запросы из вне приходят
3. ifconfig eth1

eth1      Link encap:Ethernet  HWaddr 1c:af:f7:0e:1b:bb  
          inet addr:178.49.95.130  Bcast:178.49.95.191  Mask:255.255.255.192
          inet6 addr: fe80::1eaf:f7ff:fe0e:1bbb/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1998514 errors:0 dropped:0 overruns:0 frame:0
          TX packets:52576 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2671204037 (2.4 GiB)  TX bytes:11664194 (11.1 MiB)
          Interrupt:20

4. /etc/network/interfaces
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
	address 192.168.1.1
	netmask 255.255.255.0
	network 192.168.1.0
	broadcast 192.168.1.255
	
auto eth1
iface eth1 inet static
	address 178.49.95.130
	netmask 255.255.255.192
	gateway 178.49.95.129
5. ethtool -i eth1
driver: skge
version: 1.13
firmware-version: N/A
bus-info: 0000:03:00.0

6. ethtool -S eth1

NIC statistics:
     tx_bytes: 11691178
     rx_bytes: 2719670344
     tx_broadcast: 3
     rx_broadcast: 6077
     tx_multicast: 57
     rx_multicast: 1951817
     tx_unicast: 52720
     rx_unicast: 76423
     tx_mac_pause: 0
     rx_mac_pause: 0
     collisions: 0
     multi_collisions: 0
     aborted: 0
     late_collision: 0
     fifo_underrun: 0
     fifo_overflow: 0
     rx_toolong: 0
     rx_jabber: 0
     rx_runt: 0
     rx_too_long: 0
     rx_fcs_error: 0

С чем может быть проблема? Через поиск нашел похожую проблему, но там всё решилось заменой сетевой карты.


Подключи провайдера на eth0. Если через примерно полчаса ничего не отвалится будем думать.

Munhgauzen
()

на 10 - 20 секунд пропадает сеть

Она через 10-20 с сама появляется? Или только после networking restart?

mky ★★★★★
()

Да, описание не совсем понятное
проблема либо на L1 (может поменять кабель?)
либо на L3 (как будто закешированный маршрут для SSH работает)
предлагаю сравнить ip r g адрес_с_которого_подключаетесь и ip r ls cache для рабочего и нерабочего случаев

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

Она через 10-20 с сама появляется? Или только после networking restart?

Через 10 - 20 секунд сеть появляется сама.

Подключи провайдера на eth0. Если через примерно полчаса ничего не отвалится будем думать.

Уже пробовал. Не помогло. Также пробовал на отдельном пк и двух ноутах (все под управлением linux`а).

проблема либо на L1 (может поменять кабель?)

От провайдера приходил специалист, проверял кабель. Кабель, если ему верить, в норме. Также провайдер ставил для тестирования сети роутер (D-link DIR-300, кажется) - через него сеть работала нормально.

предлагаю сравнить ip r g адрес_с_которого_подключаетесь и ip r ls cache для рабочего и нерабочего случаев

ip r g 192.168.1.10

192.168.1.10 dev eth0  src 192.168.1.1 
    cache  mtu 1500 advmss 1460 hoplimit 64

ip r ls для рабочего случая
192.168.1.10 from 192.168.1.1 dev eth0 
    cache  ipid 0x6446 mtu 1500 rtt 110ms rttvar 110ms cwnd 5 advmss 1460 hoplimit 64
192.168.1.10 from 192.168.1.1 tos lowdelay dev eth0 
    cache  mtu 1500 advmss 1460 hoplimit 64

ip r ls для нерабочего случая
192.168.1.10 from 192.168.1.1 dev eth0 
    cache  ipid 0x6446 mtu 1500 rtt 110ms rttvar 110ms cwnd 5 advmss 1460 hoplimit 64
192.168.1.10 from 192.168.1.1 tos lowdelay dev eth0 
    cache  mtu 1500 advmss 1460 hoplimit 64

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

давайте сначала: что есть домашняя сеть, полностью топологию опишите

zolden ★★★★★
()

Меняй местами подключения, пробуй.

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

Я как понимаю, у вас там отваливается связь с шлюзом, а локальная сеть провайдера 178.49.95.128/26 остаётся, раз от неё arp-запросы приходят. Что будет, если пинговать 178.49.95.190 или другие хосты из этой подсети в моменты «отпадывания»?

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

давайте сначала: что есть домашняя сеть, полностью топологию опишите

Сильно не пинайте - http://ferg.in/storage/5i9JYsSe/

Меняй местами подключения, пробуй.

Менял, не помогло. Этот вариант - http://ferg.in/storage/ZIU7kLwJ/ так же не работает.

Я как понимаю, у вас там отваливается связь с шлюзом, а локальная сеть провайдера 178.49.95.128/26 остаётся, раз от неё arp-запросы приходят. Что будет, если пинговать 178.49.95.190 или другие хосты из этой подсети в моменты «отпадывания»?

Проверил. В качестве жертвы выбрал 178.49.95.189. В тот момент, когда отваливается сеть, пинг до 178.49.95.189 идёт.

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

Провайдер замену оборудования недавно не проводил? Логично предположить, что проблема на ближайшем коммутаторе.

post-factum ★★★★★
()
Ответ на: комментарий от ferg

Раз пинг до 178.49.95.189 идёт, значит с сетевой карточкой все в порядке. Проблема на стороне провайдера.

То, что под виндой работает, скорее всего, связано с тем, что под виндой меньше объём трафика/меньше одновременно открытых соединений. Почему работало через DIR-300 не знаю, может у него был линк на 10 Мбит и тоже было меньше трафика. Может это у провайдера так шейпинг криво работает, у вас там приличный объём по счётчикам сетёвки:

RX bytes:2671204037 (2.4 GiB) TX bytes:11664194 (11.1 MiB)

Не знаю, что тут можно сделать, ИМХО, проблема у провайдера, но «далеко» — не кабель или свитч в вашем доме.

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

Ну что, что-то новенькое: связь теперь пропадает каждые 5 минут.

Может это у провайдера так шейпинг криво работает, у вас там приличный объём по счётчикам сетёвки:

Проверил на ноуте (archlinux livecd) подключённого напрямую. От объёма трафика не зависит. Из сетевой активности - только ping.
Вот логи: ping и tcpdump

То, что под виндой работает, скорее всего, связано с тем, что под виндой меньше объём трафика/меньше одновременно открытых соединений.

Есть подозрение что просто «повезло». У меня были моменты когда сеть ~день работала без сбоев.

Есть подозрения (через роутер то нормально работало) что удачное сочетание моего оборудования и оборудования провайдера и даёт такую проблему. Какие еще логи посмотреть / какие замеры сделать / что почитать на эту тему можно?

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

покажите uname -a
что за модель сетевой карты?


1.Linux server 2.6.32-5-amd64 #1 SMP Sun May 6 04:00:17 UTC 2012 x86_64 GNU/Linux
Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet

2. Linux server 2.6.32-5-amd64 #1 SMP Sun May 6 04:00:17 UTC 2012 x86_64 GNU/Linux
D-Link System Inc DGE-530T Gigabit Ethernet Adapter

3. Linux acer 3.4.4-2-ARCH #1 SMP PREEMPT Sun Jun 24 17:28:37 UTC 2012 i686 GNU/Linux
Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+

4. Linux nc20 3.4.3-1-ARCH #1 SMP PREEMPT Mon Jun 18 08:28:29 CEST 2012 x86_64 GNU/Linux
Marvell Technology Group Ltd. 88E8040 PCI-E Fast Ethernet Controller

Плюс пара сетевых карт которые уже отдал.

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

Благодарю, почитаю.

Хм, странную вещь заметил:
1. Дамп в момент пропажи сети - http://ferg.in/storage/ShxAs0XG/tcpdump_bad
2. Дамп в момент нормальной работы - http://ferg.in/storage/lFm0qHew/tcpdump_good

cat tcpdump_bad | grep 'Request who-has 178.49.95.130 tell 178.49.95.190' | wc
44 704 6600

cat tcpdump_good | grep 'Request who-has 178.49.95.130 tell 178.49.95.190' | wc
0 0 0

Дамп снимал через tcpdump -enni eth1 arp or icmp

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

Может это совпадение, но перед тем, как у вас появились ответы на icmp-пакеты от вашей машины был arp-запрос. Может у вашего шлюза 178.49.95.129 меняется mac-адрес? Попробуйте запустить arping на этот адрес и посмотреть вывод, особенно в моменты пропадания сети.

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

Тут не знаю, но в том дампе, который вы приводили ранее, (файл tcpdump) запросы «Request who-has 178.49.95.130 tell 178.49.95.190» есть как при прохождении так и при отсутствии icmp-echo ответов.

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

Хм. По результатам 10`ти минутного тестирования:
1. Поставил arping 178.49.95.129. Связь стала пропадать, но на ~1 сек. Потери по ping`у - 1%.
2. Отключил arping. Дожидаюсь момента пропадания связи. Включаю arping. Связь через секунду восстанавливается.

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

Может у вашего шлюза 178.49.95.129 меняется mac-адрес?

Итак. По результатам часовой проверки:
1. mac адрес не меняется.
2. При запущенном arping 178.49.95.129 связь так же пропадает, но восстанавливается через 1 - 2 секунды (против 10 - 40 секунд).
3. Процент потерь при пинге упал с 10% до 1%.
4. У arping так же 1% потерь.

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

Проблема решена. Со слов тех. специалиста провайдера:

коммутатор в соседнем подъезде с ума сошёл

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