URL: https://www.opennet.ru/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID1
Нить номер: 85817
[ Назад ]

Исходное сообщение
"Проблема с сетью "

Отправлено dimarem , 01-Июл-09 17:43 
есть debian lenny выступает в роли шлюза
eth1      Link encap:Ethernet  HWaddr 00:30:68:65:52:F1
          inet addr:192.168.0.1  Bcast:192.168.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:121 errors:0 dropped:0 overruns:0 frame:0
          TX packets:32 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:11249 (10.9 Kb)  TX bytes:4289 (4.1 Kb)

eth2      Link encap:Ethernet  HWaddr 00:15:14:68:8A:40
          inet addr:192.168.2.1  Bcast:192.168.2.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:88 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:7001 (6.8 Kb)  TX bytes:196 (196.0 b)

eth3      Link encap:Ethernet  HWaddr 00:15:17:78:8A:41
          inet addr:192.168.3.1  Bcast:192.168.3.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:85 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:6789 (6.6 Kb)  TX bytes:196 (196.0 b)

сетевухи
06:00.0 Ethernet controller: Intel Corporation 80003ES2LAN Gigabit Ethernet Controller 06:00.1 Ethernet controller: Intel Corporation 80003ES2LAN Gigabit Ethernet Controller
09:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06)


Проблема в том что периодически падает сеть в логах тишина,
Воткнул все сетевухи в один свитч, и наблюдаю забавную картину

что время от времяни замечаю вот такое

Jul  1 17:37:42  kernel: IN=eth2 OUT= SRC=192.168.0.22 DST=192.168.0.1 LEN=40 TOS=0x00 PREC=0x00 TTL=128 ID=26263 DF PROTO=TCP SPT=1040 DPT=22 ...
Jul  1 17:37:42  kernel: IN=eth2 OUT=  SRC=192.168.0.22 DST=192.168.0.1 LEN=92 TOS=0x00 PREC=0x00 TTL=128 ID=26264 DF PROTO=TCP SPT=1040 DPT=22

ставил свежие драйвера не помогло.

вопрос:  От куда могло взяться  пакеты для DST=192.168.0.1 на IN=eth2 ????? , когда они должны быть на eth1...
Чем лечится такое, кто знает подскажите!!!!


Содержание

Сообщения в этом обсуждении
"Проблема с сетью "
Отправлено dimarem , 02-Июл-09 13:59 
ну хоть кто нибудь подкиньте идею !!!!


"Проблема с сетью "
Отправлено mikra , 02-Июл-09 17:20 
>Проблема в том что периодически падает сеть в логах тишина,

Так выяснить в чем дело не представляется возможным.

>Воткнул все сетевухи в один свитч, и наблюдаю забавную картину
>
>вопрос:  От куда могло взяться  пакеты для DST=192.168.0.1 на IN=eth2
>????? , когда они должны быть на eth1...

В любом свиче на каждом порту есть своя таблица мак адресов. После включения в розетку все таблицы пустые.

Как только с порта в свич поступает пакет, он разбирается и свич читает мак адрес отправителя. Полученный мак адрес заносится в таблицу для этого порта и хранится там эн минут эм секунд, затем стирается.

Дальше читается мак адрес получателя. Свич перебирает таблицы мак адресов по всем своим портам в поисках этого адреса. Если нашел, то суёт пакет в соответствующий порт. Если нет - шлет по всем портам.

В твоем случае сетевуха 192.168.0.1 молчала как минимум последние эн минут эм секунд. Поэтому свич ее забыл и пришедший на ее имя пакет распихал по всем своим портам.
Плюс почитай про ARP протокол.


"Проблема с сетью "
Отправлено dimarem , 02-Июл-09 23:10 

>В твоем случае сетевуха 192.168.0.1 молчала как минимум последние эн минут эм
>секунд. Поэтому свич ее забыл и пришедший на ее имя пакет
>распихал по всем своим портам.
>Плюс почитай про ARP протокол.

но почему тогда например:  eth2  принимает пакеты которые предназначались не ей,

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

на серваке неправильно формируется arp таблица:
типа этого

192.168.0.22 mac.... eth1        
192.168.0.22 mac.... eth2
192.168.0.22 mac.... eth3


"Проблема с сетью "
Отправлено Vladimir , 03-Июл-09 06:18 
Поясню на примере: подключаюсь по ssh к 192.168.0.1 пакеты приходят на eth1,
>все нормально все работает, спустя какое то время беру и просто
>выдергиваю провод из сетевухи eth1, и ssh подключение не падает т.к.
>траф прет уже через другой интерфейс.
>

   С какой же сети вы подключаетесь и куда делся eth0 ?


"Проблема с сетью "
Отправлено mikra , 03-Июл-09 12:47 
>
>>В твоем случае сетевуха 192.168.0.1 молчала как минимум последние эн минут эм
>>секунд. Поэтому свич ее забыл и пришедший на ее имя пакет
>>распихал по всем своим портам.
>>Плюс почитай про ARP протокол.
>
>но почему тогда например:  eth2  принимает пакеты которые предназначались не
>ей,

принимать неположенные ей пакета сетевуха может, находясь в "promiscuous mode", например если ты смотришь снифером трафик, а свич шлет пакет всем портам. Но в твоем случае скорее всего дело в неправильной маршрутизации, в DNS итп...

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

Врядли такое возможно, если только все интерфейсы не собраны в транк. Но тогда у каждого нет своего адреса, а есть общий у интерфейса bound0. Соединение происходит только с одним адресом и рвется если он недоступен. Тем более если это соединение ssh.

>на серваке неправильно формируется arp таблица:
>типа этого
>
>192.168.0.22 mac.... eth1
>192.168.0.22 mac.... eth2
>192.168.0.22 mac.... eth3

Это значит, что 192.168.0.22 при соединении с сервером может использовать 192.168.0.1, 192.168.2.1 и 192.168.3.1 на свой вкус и наверняка уже отметился на всех трех. Используя телепатический талант, вижу, что на ssh клиенте ты указываешь не 192.168.0.1, а что-то вроде myserver.ru. А в DNS за именем myserver.ru закреплены все три адреса. Поэтому 192.168.0.22 выбирает один из трех адресов и с ним соединяется.