пропадает/нестбильное подключение к локальной сети

Автор bbiktop, 02 января 2013, 16:59:33

« назад - далее »

0 Пользователи и 5 гостей просматривают эту тему.

bbiktop

С новым годом!

Граждане, помогите чайнику пожалуйста, уже месяц воюю, не могу понять в чем дело.
Есть комп с двумя интерфейсами eth1 наружу и eth0 в локалку.
Все работает ок, запущен нат, настроен рутинг. Локалка ходит в инет, isc-dhcpd раздает айпи номера.
Но через некоторое время, постоянно разное, от пары минут до нескольких часов, eth0 перестает "видеть" локалку.
Физически eth0 172.16.1.1 локальный воткнут в рутер asus 172.16.1.4 пачкордом длинной метр. Проводок менял. Рутер тоже.
Не запущено ничего, таблица рутингов из трех строчек
ip route list
192.168.18.0/24 dev eth1  proto kernel  scope link  src 192.168.18.61
172.16.1.0/24 dev eth0  proto kernel  scope link  src 172.16.1.1
default via 192.168.18.1 dev eth1
ip rule list
0:      from all lookup local
32766:  from all lookup main
32767:  from all lookup default

что может быть - ума не приложу. карты сетевые менял три раза - пофиг.

uname -a
Linux gate 2.6.32-5-amd64 #1 SMP Sun Sep 23 10:07:46 UTC 2012 x86_64 GNU/Linux

02:00.0 Ethernet controller: Atheros Communications AR8131 Gigabit Ethernet (rev c0)
03:07.0 Ethernet controller: Sundance Technology Inc / IC Plus Corp IP1000 Family Gigabit Ethernet (rev 41)

При "зависании" пакеты перестают проходить, но не все. Сложно снять лог, но на 20 icmp запросов может прийти три ответа, причем с задержкой в несколько секунд. Перезагрузка рутера не помогает, другие устройства в сети этого рутера работают ок. Вытащить-всунуть шнурок не помогает тоже, помогает только ifdown eth0;ifup eth0

фойерфол отключал - пофиг, да и вряд ли может он влиять таким образом, чтобы поработало, а потом перестало.

Даже не представляю себе куда копать. Подайте идею пожалуйста, задолбалсо я. Любые дополнительные данные готов показать, даже и не знаю, правда, какие.

rayanAyar

eth0 - это встроенная в мать или PCI-плата?
И всё-таки неплохо бы посмотреть логи после "падения".

bbiktop

Цитата: rayanAyar от 02 января 2013, 17:32:02
eth0 - это встроенная в мать или PCI-плата?
И всё-таки неплохо бы посмотреть логи после "падения".
Пробовал и так и сяк. Была внешняя pci, их сменил три разных, но на похожих чипах. Сейчас вот поменял местами и сделал eth0 встроенную на motherboard. Пока не падало, но мало времени прошло.
А какие именно логи? Я не нашел ничего вообще нигде. Подскажите пожалуйста, какие логи смотреть? Вот мой конфиг от логов, траффик логируется в ulog:
grep -v '^[ \t]*#' rsyslog.conf |grep -v '^[ \t]*$'
$ModLoad imuxsock # provides support for local system logging
$ModLoad imklog   # provides kernel logging support (previously done by rklogd)
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
$FileOwner root
$FileGroup adm
$FileCreateMode 0640
$DirCreateMode 0755
$Umask 0022
$IncludeConfig /etc/rsyslog.d/*.conf
local7.*                        -/var/log/dhcpd.log
local7.*                        ~
auth,authpriv.*                 /var/log/auth.log
cron.*                          -/var/log/cron.log
cron.*                          ~
daemon.*                        -/var/log/daemon.log
kern.*                          -/var/log/kern.log
lpr.*                           -/var/log/lpr.log
mail.*                          -/var/log/mail.log
user.*                          -/var/log/user.log
*.*;auth,authpriv.none          -/var/log/syslog
mail.info                       -/var/log/mail.info
mail.warn                       -/var/log/mail.warn
mail.err                        /var/log/mail.err
news.crit                       /var/log/news/news.crit
news.err                        /var/log/news/news.err
news.notice                     -/var/log/news/news.notice
*.=debug;\
        auth,authpriv.none;\
        news.none;mail.none     -/var/log/debug
*.=info;*.=notice;*.=warn;\
        auth,authpriv.none;\
        cron,daemon.none;\
        mail,news.none          -/var/log/messages
*.emerg                         *
daemon.*;mail.*;\
        news.err;\
        *.=debug;*.=info;\
        *.=notice;*.=warn       |/dev/xconsole

rayanAyar

#3
Цитата: bbiktop от 02 января 2013, 17:37:29Была внешняя pci
Мать какая? Шина PCI встроенная в чипсет или внешним контроллером реализована?
У меня была вот такая проблема с контроллером Asmedia ASM1085:
http://forum.ubuntu.ru/index.php?topic=192862.0

Сообщение объединено: 02 января 2013, 17:47:13

Цитата: bbiktop от 02 января 2013, 17:37:29А какие именно логи?
/var/log/syslog

bbiktop

#4
Цитата: rayanAyar от 02 января 2013, 17:45:13Мать какая? Шина PCI встроенная в чипсет или внешним контроллером реализована?
Это барабан асус:
lspci
00:00.0 Host bridge: Advanced Micro Devices [AMD] RS780 Host Bridge
00:01.0 PCI bridge: ASUSTeK Computer Inc. RS880 PCI to PCI bridge (int gfx)
00:06.0 PCI bridge: Advanced Micro Devices [AMD] RS780 PCI to PCI bridge (PCIE port 2)
00:11.0 SATA controller: ATI Technologies Inc SB700/SB800 SATA Controller [AHCI mode]
00:12.0 USB Controller: ATI Technologies Inc SB700/SB800 USB OHCI0 Controller
00:12.1 USB Controller: ATI Technologies Inc SB700 USB OHCI1 Controller
00:12.2 USB Controller: ATI Technologies Inc SB700/SB800 USB EHCI Controller
00:13.0 USB Controller: ATI Technologies Inc SB700/SB800 USB OHCI0 Controller
00:13.1 USB Controller: ATI Technologies Inc SB700 USB OHCI1 Controller
00:13.2 USB Controller: ATI Technologies Inc SB700/SB800 USB EHCI Controller
00:14.0 SMBus: ATI Technologies Inc SBx00 SMBus Controller (rev 3c)
00:14.1 IDE interface: ATI Technologies Inc SB700/SB800 IDE Controller
00:14.2 Audio device: ATI Technologies Inc SBx00 Azalia (Intel HDA)
00:14.3 ISA bridge: ATI Technologies Inc SB700/SB800 LPC host controller
00:14.4 PCI bridge: ATI Technologies Inc SBx00 PCI to PCI Bridge
00:14.5 USB Controller: ATI Technologies Inc SB700/SB800 USB OHCI2 Controller
00:18.0 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor HyperTransport Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Miscellaneous Control
00:18.4 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Link Control
01:05.0 VGA compatible controller: ATI Technologies Inc 760G [Radeon 3000]
02:00.0 Ethernet controller: Atheros Communications AR8131 Gigabit Ethernet (rev c0)
03:07.0 Ethernet controller: Sundance Technology Inc / IC Plus Corp IP1000 Family Gigabit Ethernet (rev 41)

Карты пробовал три:
RTL 8139C
RTL 8139D
сейчас стоит IC+ IP1000A

Сообщение объединено: 02 января 2013, 18:01:33

Цитата: rayanAyar от 02 января 2013, 17:45:13/var/log/syslog
Ничего нету там. Ну, то есть вообще.

Olej

Цитата: bbiktop от 02 января 2013, 16:59:33Есть комп с двумя интерфейсами eth1 наружу и eth0 в локалку.
Все работает ок, запущен нат, настроен рутинг. Локалка ходит в инет, isc-dhcpd раздает айпи номера.
Но через некоторое время, постоянно разное, от пары минут до нескольких часов, eth0 перестает "видеть" локалку.
Физически eth0 172.16.1.1 локальный воткнут в рутер asus 172.16.1.4 пачкордом длинной метр. Проводок менял. Рутер тоже.
Не запущено ничего, таблица рутингов из трех строчек
ip route list
192.168.18.0/24 dev eth1  proto kernel  scope link  src 192.168.18.61
172.16.1.0/24 dev eth0  proto kernel  scope link  src 172.16.1.1
default via 192.168.18.1 dev eth1

У вас очень странная таблица роутинга: локальная сеть 192.168.18.0/24 прописана через интерфейс eth1 (который вы утверждаете торчит внаружу), 172.16.1.0/24 - eth0, дефаултный шлюз - в локальной сети 192.168.18.1 ...

Вы как-то разберитесь в соответствии того, чт вы показываете выводом команд + того, что рассказываете "на пальцах" ;D

corner

Да, по идее дефолтный gateway должен быть в сети 172.
по поводу работы в режиме раздачи нета - попробуйте увеличить в ядре параметр net.ipv4.netfilter.ip_conntrack_max = 1048576 (например). Это делается через sysctl внесением параметра в sysctl.conf c последующим применением # sysctl -p

bbiktop

#7
Цитата: corner от 02 января 2013, 19:40:38Да, по идее дефолтный gateway должен быть в сети 172.
по поводу работы в режиме раздачи нета - попробуйте увеличить в ядре параметр net.ipv4.netfilter.ip_conntrack_max = 1048576 (например). Это делается через sysctl внесением параметра в sysctl.conf c последующим применением
Эээ. Про гейтвей что-то вы не то говорите. Это рутер, он маскарадит локалку 172.16.1.0/24 в инет. Соответственно дефолтный рутинг идет на провайдера через eth1
По поводу количества - там 65536 по умолчанию, по идее этого достаточно, траффик небольшой, это домашняя сеть. Вот сейчас я вижу там 79 висящих соединений. Но я добавил, спасибо за совет.
Я сейчас поменял eth1 и eth0 местами, уже несколько часов работает. Впрочем, такое и раньше бывало, самое стремное то, что непонятно отчего зависит возникновение проблемы. И подумал бы, что это аппаратное, да уже три карты поменял.


Сообщение объединено: 02 января 2013, 20:42:01

Цитата: Olej от 02 января 2013, 19:33:35У вас очень странная таблица роутинга: локальная сеть 192.168.18.0/24 прописана через интерфейс eth1 (который вы утверждаете торчит внаружу), 172.16.1.0/24 - eth0, дефаултный шлюз - в локальной сети 192.168.18.1 ...

192.168.18.0/24 это не локальная сеть. Локальная сеть 172.16.1.0/24

Давайте еще раз попробую обьяснить, наверное я плохо в первый раз рассказал, хотя уж и не знаю как обьяснить проще.
Подключение такое: локалка 172.16.1.0/24 заходит в eth0 172.16.1.1 на этом компе.
Из этого компа выходит eth1 192.168.18.61, который через gw 192.168.18.1 подключен к инету. Соответственно 192.168.18.1 - default gw.
У моего провайдера не раздаются routable ip номера, если вы об этом. Впрочем, это пофиг и к проблеме не имеет никакого отношения. Собственно, проблема в том, что два интерфейса перестают видеть друг друга, хотя находятся на расстоянии метра патчкорда.

lisss

По описанию очень смахивает на то, что в сети существуют совпадающие ip. При возникновении проблемы вы перезагружаетесь и через определнное время опять перестают ходить пакеты, так?

По поводу описания проблемы: я так и не понял, кто куда воткнут. Роутер у вас то на одном интерфейсе, то на другом.

bbiktop

#9
Цитата: lisss от 02 января 2013, 21:56:51По описанию очень смахивает на то, что в сети существуют совпадающие ip. При возникновении проблемы вы перезагружаетесь и через определнное время опять перестают ходить пакеты, так?

По поводу описания проблемы: я так и не понял, кто куда воткнут. Роутер у вас то на одном интерфейсе, то на другом.
Что такое "роутер" я не знаю. Что же касается интерфейсов - на то он и рутер, что у него несколько интерфейсов. Перечитал все свои сообщения - вроде достаточно доходчиво и однозначно описано. Что именно вам неясно, давайте я еще раз попробую обьяснить.
Проблему я описывал - через некоторое время перестает работать пинг от интерфейса сервера на интерфейс коммутатора, в который он воткнут. Причем, не работает как-то странно - часть пингов проходит, но с некими дикими задержками.
Перезагружать - это слишком кардинально, я просто передергиваю интерфейс. Вы зря, кстати, не читали изначальный вопрос, я там это все описал.
Дубликаты айпи адресов во-первых были бы отловлены, а во-вторых, никак бы не повлияли на соединение двух интерфейсов с нормальными айпи. Я смотрел arp, дубликатов не видел.

Сообщение объединено: 02 января 2013, 23:29:50

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

root@gate:~# ping 192.168.18.1
PING 192.168.18.1 (192.168.18.1) 56(84) bytes of data.
64 bytes from 192.168.18.1: icmp_req=1 ttl=64 time=1361 ms
64 bytes from 192.168.18.1: icmp_req=2 ttl=64 time=355 ms
64 bytes from 192.168.18.1: icmp_req=3 ttl=64 time=3360 ms
64 bytes from 192.168.18.1: icmp_req=4 ttl=64 time=2359 ms
64 bytes from 192.168.18.1: icmp_req=5 ttl=64 time=1354 ms
64 bytes from 192.168.18.1: icmp_req=6 ttl=64 time=346 ms
64 bytes from 192.168.18.1: icmp_req=7 ttl=64 time=10374 ms
64 bytes from 192.168.18.1: icmp_req=8 ttl=64 time=9407 ms
64 bytes from 192.168.18.1: icmp_req=9 ttl=64 time=8410 ms
64 bytes from 192.168.18.1: icmp_req=10 ttl=64 time=7414 ms
64 bytes from 192.168.18.1: icmp_req=11 ttl=64 time=6414 ms
64 bytes from 192.168.18.1: icmp_req=12 ttl=64 time=5414 ms
64 bytes from 192.168.18.1: icmp_req=13 ttl=64 time=4414 ms
64 bytes from 192.168.18.1: icmp_req=14 ttl=64 time=3414 ms
64 bytes from 192.168.18.1: icmp_req=15 ttl=64 time=2414 ms
64 bytes from 192.168.18.1: icmp_req=16 ttl=64 time=1414 ms
64 bytes from 192.168.18.1: icmp_req=18 ttl=64 time=7198 ms
64 bytes from 192.168.18.1: icmp_req=19 ttl=64 time=6212 ms
64 bytes from 192.168.18.1: icmp_req=20 ttl=64 time=5212 ms
64 bytes from 192.168.18.1: icmp_req=21 ttl=64 time=4232 ms
64 bytes from 192.168.18.1: icmp_req=22 ttl=64 time=3232 ms
64 bytes from 192.168.18.1: icmp_req=23 ttl=64 time=2232 ms
64 bytes from 192.168.18.1: icmp_req=24 ttl=64 time=1232 ms
64 bytes from 192.168.18.1: icmp_req=25 ttl=64 time=232 ms
64 bytes from 192.168.18.1: icmp_req=26 ttl=64 time=6834 ms
64 bytes from 192.168.18.1: icmp_req=27 ttl=64 time=5834 ms
64 bytes from 192.168.18.1: icmp_req=28 ttl=64 time=4836 ms
64 bytes from 192.168.18.1: icmp_req=29 ttl=64 time=3838 ms
64 bytes from 192.168.18.1: icmp_req=30 ttl=64 time=2947 ms
64 bytes from 192.168.18.1: icmp_req=31 ttl=64 time=1947 ms
64 bytes from 192.168.18.1: icmp_req=32 ttl=64 time=947 ms
^C
--- 192.168.18.1 ping statistics ---
35 packets transmitted, 31 received, 11% packet loss, time 34040ms
rtt min/avg/max/mdev = 232.460/4038.796/10374.862/2730.688 ms, pipe 11
root@gate:~# ping 192.168.18.1
PING 192.168.18.1 (192.168.18.1) 56(84) bytes of data.
64 bytes from 192.168.18.1: icmp_req=1 ttl=64 time=2382 ms
64 bytes from 192.168.18.1: icmp_req=2 ttl=64 time=1397 ms
64 bytes from 192.168.18.1: icmp_req=3 ttl=64 time=398 ms
64 bytes from 192.168.18.1: icmp_req=4 ttl=64 time=8728 ms
64 bytes from 192.168.18.1: icmp_req=5 ttl=64 time=7721 ms
64 bytes from 192.168.18.1: icmp_req=6 ttl=64 time=6713 ms
64 bytes from 192.168.18.1: icmp_req=7 ttl=64 time=5705 ms
64 bytes from 192.168.18.1: icmp_req=8 ttl=64 time=4835 ms
64 bytes from 192.168.18.1: icmp_req=9 ttl=64 time=3827 ms
64 bytes from 192.168.18.1: icmp_req=10 ttl=64 time=2819 ms
64 bytes from 192.168.18.1: icmp_req=11 ttl=64 time=1811 ms
64 bytes from 192.168.18.1: icmp_req=12 ttl=64 time=803 ms
^C
--- 192.168.18.1 ping statistics ---
17 packets transmitted, 12 received, 29% packet loss, time 16096ms
rtt min/avg/max/mdev = 398.343/3928.827/8728.321/2675.664 ms, pipe 9
root@gate:~# ifdown eth1;ifup eth1
root@gate:~# ping 192.168.18.1
PING 192.168.18.1 (192.168.18.1) 56(84) bytes of data.
64 bytes from 192.168.18.1: icmp_req=1 ttl=64 time=5.61 ms
64 bytes from 192.168.18.1: icmp_req=2 ttl=64 time=5.66 ms
64 bytes from 192.168.18.1: icmp_req=3 ttl=64 time=16.7 ms
64 bytes from 192.168.18.1: icmp_req=4 ttl=64 time=6.83 ms
64 bytes from 192.168.18.1: icmp_req=5 ttl=64 time=6.73 ms
64 bytes from 192.168.18.1: icmp_req=6 ttl=64 time=8.53 ms
64 bytes from 192.168.18.1: icmp_req=7 ttl=64 time=7.46 ms
64 bytes from 192.168.18.1: icmp_req=8 ttl=64 time=5.75 ms
64 bytes from 192.168.18.1: icmp_req=9 ttl=64 time=11.3 ms
^C
--- 192.168.18.1 ping statistics ---
9 packets transmitted, 9 received, 0% packet loss, time 8012ms
rtt min/avg/max/mdev = 5.616/8.304/16.753/3.448 ms


Сообщение объединено: 03 января 2013, 00:40:10

Еще раз поменял сетевуху, посмотрю что будет теперь:

02:00.0 Ethernet controller [0200]: Broadcom Corporation NetXtreme BCM5751 Gigabit Ethernet PCI Express [14e4:1677] (rev 01)
        Subsystem: Broadcom Corporation NetXtreme BCM5751 Gigabit Ethernet PCI Express [14e4:1677]
        Kernel driver in use: tg3

Народ, неужели ни у кого нету идей почему такое может быть?

lisss

вы уже меняли сетевые карты - это не помогло, значит дело не в них. передергивать шнурок и перезагружать - в данном случае одно и то же. ваш пинг увеличивает вероятность верности моего предположения до 70%.

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

bbiktop

Цитата: lisss от 03 января 2013, 14:30:49вы уже меняли сетевые карты - это не помогло, значит дело не в них. передергивать шнурок и перезагружать - в данном случае одно и то же. ваш пинг увеличивает вероятность верности моего предположения до 70%.

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

Вы невнимательно читали. Выдергивание шнурка не помогает. То есть проблема где-то в драйверах, похоже. Тут уже показывали подобное, тоже на асусе. Помогает ifup;ifdown. Перегружать не пробовал ввиду отсутствия смысла, это ж не дос какой )
Двойные айпи у меня определяются, более того, айпи по дхцп раздаются вообще в другом диапазоне, статики нету нигде. Схемку попробую еще раз набросать, хотя не пойму что тут сложного, все примитивно:

192.168.18.1.24 Провайдер
     !
     !
     !
192.168.18.61/24 eth1 \ Это тот самый
172.16.1.1/24 eth0    /злосчастный комп с дебианом
     !
     !
     !
172.16.1.4/24 коммутатор (свич)
   ! ! !
   ! ! !
   ! ! !
172.16.1.0/32 остальные подключения локалки в диапазоне от 200 до 250 по дхцп


Пропадало соединение между 172.16.1.1 и 172.16.1.4.
После того, как я поменял местами eth1 и eth0 стало пропадать соединение между 192.168.18.61 и 192.168.18.1, так что проблема именно в физическом NIC, а не в айпи номерах, я там выше показывал.

Так что схема тут пофиг, проблема явно в какой-то несовместимости материнской платы с линупсом. Вчера вот поставил pci-e nic и уже почти сутки работает ок. Тьфу три раза, потому как и после замены карт у меня бывало, что и больше суток работало. :)
Может как-то можно посмотреть статистику, там же есть всякие /proc и /sys? Знать бы где.

Легас

#12
Полагаю, что проблемка связана с BROADCOM-ом. На многих форумах различных дистров жалуются на работу драйверов, связанных именно с ним. Но это так, мои размышления.

bbiktop

#13
Цитата: Легас от 03 февраля 2013, 15:15:28
Полагаю, что проблемка связана с BROADCOM-ом. На многих форумах различных дистров жалуются на работу драйверов, связанных именно с ним. Но это так, мои размышления.
я пока поставил pci-e карту и она работает. Но тут появился второй провайдер, которого я хочу тоже подключить, и придется все же бороться с проблемой потому как pci-e разьемов больше нет.. про бродком согласен,  спасибо, может и он. посоветуйте сетевуху пожалуйста? какая самая безглючная из pci под линупсом?

Сообщение объединено: 03 февраля 2013, 21:24:07

Цитата: Легас от 03 февраля 2013, 15:15:28
Полагаю, что проблемка связана с BROADCOM-ом. На многих форумах различных дистров жалуются на работу драйверов, связанных именно с ним. Но это так, мои размышления.
а,секунду, так там rtl карты же

corner