Шлюз на 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и в последующем некоторое время не пингуется. Через некоторое время ситуация повторяется. Напомню, что такое не со всем машинами.
Может кто-нить сталкивался с таким?
>Шлюз на 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
>
>и в последующем некоторое время не пингуется. Через некоторое время ситуация повторяется.
>Напомню, что такое не со всем машинами.
>
>Может кто-нить сталкивался с таким?Вполне возможно, что сдохла сетевая. Попробуйте ее заменить.
>Шлюз на 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 ситуация не меняется?
>Как вариант, что то с таблицей Arp. Если жестко прописать mac+ip ситуация
>не меняется?Честно говоря, такая же мысль была, что что-то с арп. Попробую
>>Как вариант, что то с таблицей Arp. Если жестко прописать mac+ip ситуация
>>не меняется?
>
>Честно говоря, такая же мысль была, что что-то с арп. ПопробуюА причем тут arp??? Если первый пинг проходит, то запись в arp-таблице имеется и соответствует действительности.
А вообще, tcpdump в руки. :)
>Шлюз на 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
>
>и в последующем некоторое время не пингуется. Через некоторое время ситуация повторяется.
>Напомню, что такое не со всем машинами.
>
>Может кто-нить сталкивался с таким?
Только что случилась некоторым образом похожая проблемма - единственное отличие - проходила только часть пакетов. Виновником оказался дешевый свич: Асус. Помог его ребут.
Может поможет.
>Только что случилась некоторым образом похожая проблемма - единственное отличие - проходила
>только часть пакетов. Виновником оказался дешевый свич: Асус. Помог его ребут.
>
>Может поможет.свич не причём оказался. Помогла лишь перезагрузка внутреннего интерфейса
ifconfig rl0 down
ifconfig rl0 upЗапинговались все, но, через некоторое время опять - на некоторые машины один пинг проходит, дальше затыкается.
>>Только что случилась некоторым образом похожая проблемма - единственное отличие - проходила
>>только часть пакетов. Виновником оказался дешевый свич: Асус. Помог его ребут.
>>
>>Может поможет.
>
>свич не причём оказался. Помогла лишь перезагрузка внутреннего интерфейса
>ifconfig rl0 down
>ifconfig rl0 up
>
>Запинговались все, но, через некоторое время опять - на некоторые машины один
>пинг проходит, дальше затыкается.Смените-таки сетевую. RealTek - это полное говно, я с подобным сталкивался, вылечилось только сменой сетевухи.
>Смените-таки сетевую. RealTek - это полное говно, я с подобным сталкивался, вылечилось
>только сменой сетевухи.Сменил сетевую, центральный хаб (хотя раньше стоял 3com). Не помогло. Раньше стояло 2 сервера: один - шлюз (freeBSD 5.1, nat, ipfw, squid, машина старенькая - селерон 266, хватало вполне), второй - чисто samba (freeBSD 5.1, машина новая - пень 4). Проблемы начались на шлюзе, как ни странно, после замены вентилятора на шлюзе - 3-4 машины работают без проблем в сети, ходят в нет и т.д., на остальных полный ... Периодически (10-15 минут) шлюз их отключал от себя, т.е. пинги не шли и вообще ни какие подключения к шлюзу не работают (со всеми остальными машинами в сети связь остаётся). Я решил всё перенести на вторую фрю, т.е. она теперь стала выполнять все функции (nat, ipfw, squid, samba). Проблема осталась!!! Помогает только перезапуск внутреннего интерфейса, причём я даже менял сетевые карты местами, тоже самое.
Я так понимаю, неожиданно возникла проблема с операционкой. Только я не понимаю почему и куда копать.
>>Смените-таки сетевую. 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 - буферов у вас не хватает, когда пожираются, получаете соответствующий
эффект, перегружаете - все работает до момента пока снова буфера не израсходуются
Гланул 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-спуфинг :(
>Гланул 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 в студию
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 tablesInternet:
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
>==========================================================================
>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'и и как часто
Переустановил всё на сервер под фрёй 6.2, пытаюсь увеличить mbufs, при компилировании ядра пишет unknown options "NMBCLUSTERS", это куда же могла деться эта опция?
>Переустановил всё на сервер под фрёй 6.2, пытаюсь увеличить mbufs, при компилировании
>ядра пишет unknown options "NMBCLUSTERS", это куда же могла деться эта
>опция?/boot/loader.conf
kern.ipc.nmbclusters="8192"к примеру
всё равно не помогло увеличение числа mbufs, проблема осталась: через некоторое время большинство компов отпадают от сервера, до тех пор, пока не перзапустишь внутренний интерфейс.
Прописал жёсткую arp таблицу. Тоже не помогло :-(
Меня скоро нафик застрелит начальство.
есть мнение, что на сетевой с маком 00:0f:3d:1a:2d:24
происходит смена ip. Может кто то хочет подобрать хороший ip?
Вычисли что за комп и вытащи из него патчкорд... =)Ты говоришь, что большинство компов отпадают от сервера, а ты не пробовал проверять если связь с другими компами внутри ЛВС?
кароче я к тому, что проблема не в сервере, а где-то в сети кто-то или что-то целенаправлено гадит =)
>кароче я к тому, что проблема не в сервере, а где-то в
>сети кто-то или что-то целенаправлено гадит =)Все варианты сводятся к тому, что проблема действительно в сети, а не в сервере. Пока помогло лишь перевод всей ЛВС в другую серую подсеть (изменил настройки на сервере и на компах). Пока всё работает.
Мы в этом здании не одни подключены в хаб провайдера, пару лет назад возникали конфликты IP адресов, пока я не додумался запретить в фаерволе доступ серых адресов через внешний интерфейс, проблемы исчезли, но фаер работает на другом уровне OSI, а проблемы возникли на канальном (смена МАС-адреса). Такое впечатление, что кто-то просто балуется програмкой типа Cain, которая позволяет обходить управляемы свичи. Странно, что у провайдера не стоит управляемого свича, что позволяет людям из других контор в этом здании, подключённым к этому же прову проникать в другие сети.