форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы OpenNET: Виртуальная конференция (Public)
Изначальное сообщение		[Проследить за развитием треда]

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

Сообщение от paco (??) on 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 и в последующем некоторое время не пингуется. Через некоторое время ситуация повторяется. Напомню, что такое не со всем машинами. Может кто-нить сталкивался с таким?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Сообщения по теме

[Сортировка по времени, UBB]

1. "Один пинг проходит, остальыне - нет"

Сообщение от newser (ok) on 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 > >и в последующем некоторое время не пингуется. Через некоторое время ситуация повторяется. >Напомню, что такое не со всем машинами. > >Может кто-нить сталкивался с таким? Вполне возможно, что сдохла сетевая. Попробуйте ее заменить.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

2. "Один пинг проходит, остальыне - нет"

Сообщение от de_mone (??) on 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 ситуация не меняется?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	3. "Один пинг проходит, остальыне - нет"
	Сообщение от paco (??) on 01-Мрт-07, 14:40
	>Как вариант, что то с таблицей Arp. Если жестко прописать mac+ip ситуация >не меняется? Честно говоря, такая же мысль была, что что-то с арп. Попробую
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	4. "Один пинг проходит, остальыне - нет"
	Сообщение от newser (ok) on 01-Мрт-07, 15:09
	>>Как вариант, что то с таблицей Arp. Если жестко прописать mac+ip ситуация >>не меняется? > >Честно говоря, такая же мысль была, что что-то с арп. Попробую А причем тут arp??? Если первый пинг проходит, то запись в arp-таблице имеется и соответствует действительности. А вообще, tcpdump в руки. :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

5. "Один пинг проходит, остальыне - нет"

Сообщение от de_mone (??) on 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 > >и в последующем некоторое время не пингуется. Через некоторое время ситуация повторяется. >Напомню, что такое не со всем машинами. > >Может кто-нить сталкивался с таким? Только что случилась некоторым образом похожая проблемма - единственное отличие - проходила только часть пакетов. Виновником оказался дешевый свич: Асус. Помог его ребут. Может поможет.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	6. "Один пинг проходит, остальыне - нет"
	Сообщение от paco (??) on 05-Мрт-07, 09:01
	>Только что случилась некоторым образом похожая проблемма - единственное отличие - проходила >только часть пакетов. Виновником оказался дешевый свич: Асус. Помог его ребут. > >Может поможет. свич не причём оказался. Помогла лишь перезагрузка внутреннего интерфейса ifconfig rl0 down ifconfig rl0 up Запинговались все, но, через некоторое время опять - на некоторые машины один пинг проходит, дальше затыкается.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	7. "Один пинг проходит, остальыне - нет"
	Сообщение от newser (ok) on 05-Мрт-07, 09:38
	>>Только что случилась некоторым образом похожая проблемма - единственное отличие - проходила >>только часть пакетов. Виновником оказался дешевый свич: Асус. Помог его ребут. >> >>Может поможет. > >свич не причём оказался. Помогла лишь перезагрузка внутреннего интерфейса >ifconfig rl0 down >ifconfig rl0 up > >Запинговались все, но, через некоторое время опять - на некоторые машины один >пинг проходит, дальше затыкается. Смените-таки сетевую. RealTek - это полное говно, я с подобным сталкивался, вылечилось только сменой сетевухи.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	8. "Один пинг проходит, остальыне - нет"
	Сообщение от paco (??) on 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). Проблема осталась!!! Помогает только перезапуск внутреннего интерфейса, причём я даже менял сетевые карты местами, тоже самое. Я так понимаю, неожиданно возникла проблема с операционкой. Только я не понимаю почему и куда копать.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	9. "Один пинг проходит, остальыне - нет"
	Сообщение от lavr on 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 - буферов у вас не хватает, когда пожираются, получаете соответствующий эффект, перегружаете - все работает до момента пока снова буфера не израсходуются
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

10. "Один пинг проходит, остальыне - нет"

Сообщение от paco (??) on 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-спуфинг :(

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	11. "Один пинг проходит, остальыне - нет"
	Сообщение от lavr on 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 в студию
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	12. "Один пинг проходит, остальыне - нет"
	Сообщение от paco (??) on 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
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	13. "Один пинг проходит, остальыне - нет"
	Сообщение от lavr on 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'и и как часто
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	14. "Один пинг проходит, остальыне - нет"
	Сообщение от paco (??) on 13-Мрт-07, 13:35
	Переустановил всё на сервер под фрёй 6.2, пытаюсь увеличить mbufs, при компилировании ядра пишет unknown options "NMBCLUSTERS", это куда же могла деться эта опция?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	15. "Один пинг проходит, остальыне - нет"
	Сообщение от bANAn on 13-Мрт-07, 13:41
	>Переустановил всё на сервер под фрёй 6.2, пытаюсь увеличить mbufs, при компилировании >ядра пишет unknown options "NMBCLUSTERS", это куда же могла деться эта >опция? /boot/loader.conf kern.ipc.nmbclusters="8192" к примеру
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

	18. "Один пинг проходит, остальыне - нет"
	Сообщение от так мимо проходил... on 13-Мрт-07, 16:37
	кароче я к тому, что проблема не в сервере, а где-то в сети кто-то или что-то целенаправлено гадит =)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	19. "Один пинг проходит, остальыне - нет"
	Сообщение от paco (ok) on 14-Мрт-07, 07:44
	>кароче я к тому, что проблема не в сервере, а где-то в >сети кто-то или что-то целенаправлено гадит =) Все варианты сводятся к тому, что проблема действительно в сети, а не в сервере. Пока помогло лишь перевод всей ЛВС в другую серую подсеть (изменил настройки на сервере и на компах). Пока всё работает. Мы в этом здании не одни подключены в хаб провайдера, пару лет назад возникали конфликты IP адресов, пока я не додумался запретить в фаерволе доступ серых адресов через внешний интерфейс, проблемы исчезли, но фаер работает на другом уровне OSI, а проблемы возникли на канальном (смена МАС-адреса). Такое впечатление, что кто-то просто балуется програмкой типа Cain, которая позволяет обходить управляемы свичи. Странно, что у провайдера не стоит управляемого свича, что позволяет людям из других контор в этом здании, подключённым к этому же прову проникать в другие сети.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить	Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]