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

Исходное сообщение
"Один пинг проходит, остальыне - нет"

Отправлено paco , 01-Мрт-07 13:39 
Шлюз на freeBSD  работает уже несколько лет (хотя машин старая, один из первых селеронов какой-то). Фаервол простейший на ipfw: правило диверта для nat и блокирование основных портов снаружи.
Буквально несколько дней назад началось странное. Некоторые машины в сети стали отсекаться этим шлюзом, т.е. ни он их, ни они его не видят, хотя все машины в локалке друг друга видят. Причём не со всеми  машинами так, некоторые без проблем через этот шлюз в инет ходят.
Пришёл сегодня, начал разбираться. В общем, когда пингую со шлюза клиентский ПК, проходит один пинг и всё, дальше связь затыкается,

serv# ping 192.168.0.101
PING 192.168.0.101 (192.168.0.101): 56 data bytes
64 bytes from 192.168.0.101: icmp_seq=0 ttl=128 time=0.695 ms
^C
--- 192.168.0.101 ping statistics ---
8 packets transmitted, 1 packets received, 87% packet loss
round-trip min/avg/max/stddev = 0.695/0.695/0.695/0.000 ms

и в последующем некоторое время не пингуется. Через некоторое время ситуация повторяется. Напомню, что такое не со всем машинами.

Может кто-нить сталкивался с таким?


Содержание

Сообщения в этом обсуждении
"Один пинг проходит, остальыне - нет"
Отправлено newser , 01-Мрт-07 14:05 
>Шлюз на freeBSD  работает уже несколько лет (хотя машин старая, один
>из первых селеронов какой-то). Фаервол простейший на ipfw: правило диверта для
>nat и блокирование основных портов снаружи.
>Буквально несколько дней назад началось странное. Некоторые машины в сети стали отсекаться
>этим шлюзом, т.е. ни он их, ни они его не видят,
>хотя все машины в локалке друг друга видят. Причём не со
>всеми  машинами так, некоторые без проблем через этот шлюз в
>инет ходят.
>Пришёл сегодня, начал разбираться. В общем, когда пингую со шлюза клиентский ПК,
>проходит один пинг и всё, дальше связь затыкается,
>
>serv# ping 192.168.0.101
>PING 192.168.0.101 (192.168.0.101): 56 data bytes
>64 bytes from 192.168.0.101: icmp_seq=0 ttl=128 time=0.695 ms
>^C
>--- 192.168.0.101 ping statistics ---
>8 packets transmitted, 1 packets received, 87% packet loss
>round-trip min/avg/max/stddev = 0.695/0.695/0.695/0.000 ms
>
>и в последующем некоторое время не пингуется. Через некоторое время ситуация повторяется.
>Напомню, что такое не со всем машинами.
>
>Может кто-нить сталкивался с таким?

Вполне возможно, что сдохла сетевая. Попробуйте ее заменить.


"Один пинг проходит, остальыне - нет"
Отправлено de_mone , 01-Мрт-07 14:14 
>Шлюз на freeBSD  работает уже несколько лет (хотя машин старая, один
>из первых селеронов какой-то). Фаервол простейший на ipfw: правило диверта для
>nat и блокирование основных портов снаружи.
>Буквально несколько дней назад началось странное. Некоторые машины в сети стали отсекаться
>этим шлюзом, т.е. ни он их, ни они его не видят,
>хотя все машины в локалке друг друга видят. Причём не со
>всеми  машинами так, некоторые без проблем через этот шлюз в
>инет ходят.
>Пришёл сегодня, начал разбираться. В общем, когда пингую со шлюза клиентский ПК,
>проходит один пинг и всё, дальше связь затыкается,
>
>serv# ping 192.168.0.101
>PING 192.168.0.101 (192.168.0.101): 56 data bytes
>64 bytes from 192.168.0.101: icmp_seq=0 ttl=128 time=0.695 ms
>^C
>--- 192.168.0.101 ping statistics ---
>8 packets transmitted, 1 packets received, 87% packet loss
>round-trip min/avg/max/stddev = 0.695/0.695/0.695/0.000 ms
>
>и в последующем некоторое время не пингуется. Через некоторое время ситуация повторяется.
>Напомню, что такое не со всем машинами.
>
>Может кто-нить сталкивался с таким?
Как вариант, что то с таблицей Arp. Если жестко прописать mac+ip ситуация не меняется?


"Один пинг проходит, остальыне - нет"
Отправлено paco , 01-Мрт-07 14:40 
>Как вариант, что то с таблицей Arp. Если жестко прописать mac+ip ситуация
>не меняется?

Честно говоря, такая же мысль была, что что-то с арп. Попробую


"Один пинг проходит, остальыне - нет"
Отправлено newser , 01-Мрт-07 15:09 
>>Как вариант, что то с таблицей Arp. Если жестко прописать mac+ip ситуация
>>не меняется?
>
>Честно говоря, такая же мысль была, что что-то с арп. Попробую

А причем тут arp??? Если первый пинг проходит, то запись в arp-таблице имеется и соответствует действительности.

А вообще, tcpdump в руки. :)


"Один пинг проходит, остальыне - нет"
Отправлено de_mone , 01-Мрт-07 17:03 
>Шлюз на freeBSD  работает уже несколько лет (хотя машин старая, один
>из первых селеронов какой-то). Фаервол простейший на ipfw: правило диверта для
>nat и блокирование основных портов снаружи.
>Буквально несколько дней назад началось странное. Некоторые машины в сети стали отсекаться
>этим шлюзом, т.е. ни он их, ни они его не видят,
>хотя все машины в локалке друг друга видят. Причём не со
>всеми  машинами так, некоторые без проблем через этот шлюз в
>инет ходят.
>Пришёл сегодня, начал разбираться. В общем, когда пингую со шлюза клиентский ПК,
>проходит один пинг и всё, дальше связь затыкается,
>
>serv# ping 192.168.0.101
>PING 192.168.0.101 (192.168.0.101): 56 data bytes
>64 bytes from 192.168.0.101: icmp_seq=0 ttl=128 time=0.695 ms
>^C
>--- 192.168.0.101 ping statistics ---
>8 packets transmitted, 1 packets received, 87% packet loss
>round-trip min/avg/max/stddev = 0.695/0.695/0.695/0.000 ms
>
>и в последующем некоторое время не пингуется. Через некоторое время ситуация повторяется.
>Напомню, что такое не со всем машинами.
>
>Может кто-нить сталкивался с таким?
Только что случилась некоторым образом похожая проблемма - единственное отличие - проходила только часть пакетов. Виновником оказался дешевый свич: Асус. Помог его ребут.
Может поможет.


"Один пинг проходит, остальыне - нет"
Отправлено paco , 05-Мрт-07 09:01 
>Только что случилась некоторым образом похожая проблемма - единственное отличие - проходила
>только часть пакетов. Виновником оказался дешевый свич: Асус. Помог его ребут.
>
>Может поможет.

свич не причём оказался. Помогла лишь перезагрузка внутреннего интерфейса
ifconfig rl0 down
ifconfig rl0 up

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


"Один пинг проходит, остальыне - нет"
Отправлено newser , 05-Мрт-07 09:38 
>>Только что случилась некоторым образом похожая проблемма - единственное отличие - проходила
>>только часть пакетов. Виновником оказался дешевый свич: Асус. Помог его ребут.
>>
>>Может поможет.
>
>свич не причём оказался. Помогла лишь перезагрузка внутреннего интерфейса
>ifconfig rl0 down
>ifconfig rl0 up
>
>Запинговались все, но, через некоторое время опять - на некоторые машины один
>пинг проходит, дальше затыкается.

Смените-таки сетевую. RealTek - это полное говно, я с подобным сталкивался, вылечилось только сменой сетевухи.


"Один пинг проходит, остальыне - нет"
Отправлено paco , 06-Мрт-07 10:51 
>Смените-таки сетевую. RealTek - это полное говно, я с подобным сталкивался, вылечилось
>только сменой сетевухи.

Сменил сетевую, центральный хаб (хотя раньше стоял 3com). Не помогло. Раньше стояло 2 сервера: один - шлюз (freeBSD 5.1, nat, ipfw, squid, машина старенькая - селерон 266, хватало вполне), второй - чисто samba (freeBSD 5.1, машина новая - пень 4). Проблемы начались на шлюзе, как ни странно, после замены вентилятора на шлюзе - 3-4 машины работают без проблем в сети, ходят в нет и т.д., на остальных полный ... Периодически (10-15 минут) шлюз их отключал от себя, т.е. пинги не шли и вообще ни какие подключения к шлюзу не работают (со всеми остальными машинами в сети связь остаётся). Я решил всё перенести на вторую фрю, т.е. она теперь стала выполнять все функции (nat, ipfw, squid, samba). Проблема осталась!!! Помогает только перезапуск внутреннего интерфейса, причём я даже менял сетевые карты местами, тоже самое.
Я так понимаю, неожиданно возникла проблема с операционкой. Только я не понимаю почему и куда копать.


"Один пинг проходит, остальыне - нет"
Отправлено lavr , 06-Мрт-07 11:47 
>>Смените-таки сетевую. RealTek - это полное говно, я с подобным сталкивался, вылечилось
>>только сменой сетевухи.
>
>Сменил сетевую, центральный хаб (хотя раньше стоял 3com). Не помогло. Раньше стояло
>2 сервера: один - шлюз (freeBSD 5.1, nat, ipfw, squid, машина
>старенькая - селерон 266, хватало вполне), второй - чисто samba (freeBSD
>5.1, машина новая - пень 4). Проблемы начались на шлюзе, как
>ни странно, после замены вентилятора на шлюзе - 3-4 машины работают
>без проблем в сети, ходят в нет и т.д., на остальных
>полный ... Периодически (10-15 минут) шлюз их отключал от себя, т.е.
>пинги не шли и вообще ни какие подключения к шлюзу не
>работают (со всеми остальными машинами в сети связь остаётся). Я решил
>всё перенести на вторую фрю, т.е. она теперь стала выполнять все
>функции (nat, ipfw, squid, samba). Проблема осталась!!! Помогает только перезапуск внутреннего
>интерфейса, причём я даже менял сетевые карты местами, тоже самое.
>Я так понимаю, неожиданно возникла проблема с операционкой. Только я не понимаю
>почему и куда копать.

1) логи нужно смотреть однако
2) редкое гав...о 5.1 на боевые сервера - н-дас...
3) netstat -m - буферов у вас не хватает, когда пожираются, получаете соответствующий
эффект, перегружаете - все работает до момента пока снова буфера не израсходуются


"Один пинг проходит, остальыне - нет"
Отправлено paco , 06-Мрт-07 14:14 
Гланул dmesg, обнаружил

arp: 192.168.0.39 moved from 00:0e:a6:3f:55:97 to 00:0f:3d:1a:2d:24 on rl0
arp: 192.168.0.20 moved from 08:00:37:18:69:ac to 00:0f:3d:1a:2d:24 on rl0
arp: 192.168.0.101 moved from 00:01:6c:f7:9d:27 to 00:0f:3d:1a:2d:24 on rl0
arp: 192.168.0.20 moved from 00:0f:3d:1a:2d:24 to 08:00:37:18:69:ac on rl0
arp: 192.168.0.201 moved from 00:16:17:1e:5c:4d to 00:0f:3d:1a:2d:24 on rl0
arp: 192.168.0.200 moved from 00:11:d8:aa:5f:69 to 00:0f:3d:1a:2d:24 on rl0

Почител в нете. Говорят arp-спуфинг :(


"Один пинг проходит, остальыне - нет"
Отправлено lavr , 06-Мрт-07 14:32 
>Гланул dmesg, обнаружил
>
>arp: 192.168.0.39 moved from 00:0e:a6:3f:55:97 to 00:0f:3d:1a:2d:24 on rl0
>arp: 192.168.0.20 moved from 08:00:37:18:69:ac to 00:0f:3d:1a:2d:24 on rl0
>arp: 192.168.0.101 moved from 00:01:6c:f7:9d:27 to 00:0f:3d:1a:2d:24 on rl0
>arp: 192.168.0.20 moved from 00:0f:3d:1a:2d:24 to 08:00:37:18:69:ac on rl0
>arp: 192.168.0.201 moved from 00:16:17:1e:5c:4d to 00:0f:3d:1a:2d:24 on rl0
>arp: 192.168.0.200 moved from 00:11:d8:aa:5f:69 to 00:0f:3d:1a:2d:24 on rl0
>
>Почител в нете. Говорят arp-спуфинг :(

говорят что кур доят:

# ifconfig -a в студию


"Один пинг проходит, остальыне - нет"
Отправлено paco , 06-Мрт-07 14:41 
ifconfig -a
rl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255
        inet6 fe80::280:48ff:fe2d:9512%rl0 prefixlen 64 scopeid 0x1
        ether 00:80:48:2d:95:12
        media: Ethernet 10baseT/UTP
        status: active
rl1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        inet 217.24.189.152 netmask 0xffffffe0 broadcast 217.24.189.159
        inet6 fe80::280:48ff:fe44:90f1%rl1 prefixlen 64 scopeid 0x2
        ether 00:80:48:44:90:f1
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
lp0: flags=8810<POINTOPOINT,SIMPLEX,MULTICAST> mtu 1500
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
        inet 127.0.0.1 netmask 0xff000000
==========================================================================
netstat -m
mbuf usage:
        GEN cache:      0/0 (in use/in pool)
        CPU #0 cache:   2/288 (in use/in pool)
        Total:          2/288 (in use/in pool)
        Mbuf cache high watermark: 512
        Maximum possible: 17920
        Allocated mbuf types:
          2 mbufs allocated to data
        1% of mbuf map consumed
mbuf cluster usage:
        GEN cache:      0/0 (in use/in pool)
        CPU #0 cache:   0/96 (in use/in pool)
        Total:          0/96 (in use/in pool)
        Cluster cache high watermark: 128
        Maximum possible: 8960
        1% of cluster map consumed
264 KBytes of wired memory reserved (0% in use)
0 requests for memory denied
0 requests for memory delayed
0 calls to protocol drain routines
==========================================================================
netstat -rn
Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use  Netif Expire
default            217.24.189.129     UGSc       39    62833    rl1
127.0.0.1          127.0.0.1          UH          0        0    lo0
192.168.0          link#1             UC         13        0    rl0
192.168.0.2        00:14:c2:e0:02:f1  UHLW        0      680    rl0    526
192.168.0.3        00:04:79:67:b2:78  UHLW        0     1805    rl0   1197
192.168.0.6        00:c0:26:2d:53:5d  UHLW        0        5    rl0    986
192.168.0.11       00:16:17:1e:5c:4d  UHLW        0     3574    rl0    571
192.168.0.20       08:00:37:18:69:ac  UHLW        0        2    rl0   1088
192.168.0.31       00:0e:a6:41:ae:a6  UHLW        1        1    rl0   1145
192.168.0.39       00:0e:a6:3f:55:97  UHLW        0        9    rl0   1062
192.168.0.41       00:04:61:7c:25:3e  UHLW        0        4    rl0    789
192.168.0.44       00:c0:26:ab:20:b9  UHLW        0        9    rl0    781
192.168.0.55       00:c0:df:f8:7e:8a  UHLW        2        9    rl0   1197
192.168.0.101      00:01:6c:f7:9d:27  UHLW        0       21    rl0    986
192.168.0.200      00:11:d8:aa:5f:69  UHLW       13     3964    rl0    927
192.168.0.255      ff:ff:ff:ff:ff:ff  UHLWb       1        4    rl0


"Один пинг проходит, остальыне - нет"
Отправлено lavr , 06-Мрт-07 14:52 

>==========================================================================
>netstat -m
>mbuf usage:
>        GEN cache:  
>   0/0 (in use/in pool)
>        CPU #0 cache:  
> 2/288 (in use/in pool)
>        Total:    
>      2/288 (in use/in pool)
>        Mbuf cache high watermark:
>512
>        Maximum possible: 17920
---------^^^^^^^^^^^^^^^^^^^^^^^

>        Allocated mbuf types:
>          2 mbufs
>allocated to data
>        1% of mbuf map
>consumed
>mbuf cluster usage:
>        GEN cache:  
>   0/0 (in use/in pool)
>        CPU #0 cache:  
> 0/96 (in use/in pool)
>        Total:    
>      0/96 (in use/in pool)
>        Cluster cache high watermark:
>128
>        Maximum possible: 8960
---------^^^^^^^^^^^^^^^^^^^^^^- это похоже на sbufs

>        1% of cluster map
>consumed
>264 KBytes of wired memory reserved (0% in use)
>0 requests for memory denied
>0 requests for memory delayed
>0 calls to protocol drain routines
>==========================================================================

итого:

- увеличить mbufs
- разобраться почему меняются mac'и и как часто


"Один пинг проходит, остальыне - нет"
Отправлено paco , 13-Мрт-07 13:35 
Переустановил всё на сервер под фрёй 6.2, пытаюсь увеличить mbufs, при компилировании ядра пишет unknown options "NMBCLUSTERS", это куда же могла деться эта опция?

"Один пинг проходит, остальыне - нет"
Отправлено bANAn , 13-Мрт-07 13:41 
>Переустановил всё на сервер под фрёй 6.2, пытаюсь увеличить mbufs, при компилировании
>ядра пишет unknown options "NMBCLUSTERS", это куда же могла деться эта
>опция?

/boot/loader.conf
kern.ipc.nmbclusters="8192"

к примеру


"Один пинг проходит, остальыне - нет"
Отправлено paco , 13-Мрт-07 14:11 
всё равно не помогло увеличение числа mbufs, проблема осталась: через некоторое время большинство компов отпадают от сервера, до тех пор, пока не перзапустишь внутренний интерфейс.
Прописал жёсткую arp таблицу. Тоже не помогло :-(
Меня скоро нафик застрелит начальство.

"Один пинг проходит, остальыне - нет"
Отправлено так мимо проходил... , 13-Мрт-07 16:27 
есть мнение, что на сетевой с маком 00:0f:3d:1a:2d:24
происходит смена ip. Может кто то хочет подобрать хороший ip?
Вычисли что за комп и вытащи из него патчкорд... =)

Ты говоришь, что большинство компов отпадают от сервера, а ты не пробовал проверять если связь с другими компами внутри ЛВС?



"Один пинг проходит, остальыне - нет"
Отправлено так мимо проходил... , 13-Мрт-07 16:37 
кароче я к тому, что проблема не в сервере, а где-то в сети кто-то или что-то целенаправлено гадит =)

"Один пинг проходит, остальыне - нет"
Отправлено paco , 14-Мрт-07 07:44 
>кароче я к тому, что проблема не в сервере, а где-то в
>сети кто-то или что-то целенаправлено гадит =)

Все варианты сводятся к тому, что проблема действительно в сети, а не в сервере. Пока помогло лишь перевод всей ЛВС в другую серую подсеть (изменил настройки на сервере и на компах). Пока всё работает.

Мы в этом здании не одни подключены в хаб провайдера, пару лет назад возникали конфликты IP адресов, пока я не додумался запретить в фаерволе доступ серых адресов через внешний интерфейс, проблемы исчезли, но фаер работает на другом уровне OSI, а проблемы возникли на канальном (смена МАС-адреса). Такое впечатление, что кто-то просто балуется програмкой типа Cain, которая позволяет обходить управляемы свичи. Странно, что у провайдера не стоит управляемого свича, что позволяет людям из других контор в этом здании, подключённым к этому же прову проникать в другие сети.