| 0
- 29.01.2014 - 10:28
|
Сразу оговорюсь - в никсах не силен, но приходится разбираться, потомо сразу прошу прощения если что-то не пойму в Ваших ответах и буду переспрашивать!
    | | |
| 1
- 29.01.2014 - 10:28
|
Суть - Distributor ID: Ubuntu Description: Ubuntu 13.10 Release: 13.10 Codename: saucy настроен и работает Nagios, 1 сетевая в офисную сеть (10.152.78.0/24), 2(10.10.202.0/24) - в сетку с оборудованием которое мониторим. Проблема в том, что некоторые железки в сетке 2 - пингуются с довольно большими потерями. Есть еще засада - определенные железки пингуются только после service networking restart (либо сразу после ребута), и будут пинговаться пока пинг не прервешь руками, как только прервешь - всё, больше на пинг не ответят или иногда успевает пройти только первый пакет, дальше - тишина. Уточняю, вместо этого сервера, в порт коммутатора (куда сервак включен) ставил ноут на винде - с него всё пингуется без проблем и потерь. Такая же фигня была на версии 13.04 .Фаервол не настраивался, мак-адрес недоступного хоста присутствует в арп таблице (потому как перывый пакет пинга все же прошел), если его удалить - больше не появляется. iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination __________ ifconfig eth0 Link encap:Ethernet HWaddr 00:14:5e:6b:e6:3a inet addr:10.152.78.2 Bcast:10.152.78.255 Mask:255.255.255.0 inet6 addr: fe80::214:5eff:fe6b:e63a/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:2890 errors:0 dropped:0 overruns:0 frame:0 TX packets:1930 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:263024 (263.0 KB) TX bytes:258553 (258.5 KB) Interrupt:16 eth1 Link encap:Ethernet HWaddr 00:14:5e:6b:e6:3b inet addr:10.10.10.254 Bcast:10.152.78.255 Mask:255.255.255.0 inet6 addr: fe80::214:5eff:fe6b:e63b/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1896 errors:0 dropped:0 overruns:0 frame:0 TX packets:196 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:136074 (136.0 KB) TX bytes:26124 (26.1 KB) Interrupt:17 lo Link encap:Локальная петля (Loopback) inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:28686 errors:0 dropped:0 overruns:0 frame:0 TX packets:28686 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:2620707 (2.6 MB) TX bytes:2620707 (2.6 MB) ____ route default 10.152.78.1 0.0.0.0 UG 0 0 0 eth0 10.10.202.0 * 255.255.255.0 U 0 0 0 eth1 localnet * 255.255.255.0 U 0 0 0 eth0 | | |
| 2
- 29.01.2014 - 10:31
| подскажите пожалуйста куда еще можно покопать ? | | |
| 3
- 29.01.2014 - 10:32
| Еще раньше была версия 12.10 и вот там (сос слов предшественника) вроде как всё бвло нормально.... | | |
| 4
- 29.01.2014 - 10:50
| Ещё уточнение - пробовал тушить офисный интерфейс, а на другом - прописывал шлюз (который используется и для железок) - результат - тот же..... | | |
| 5
- 29.01.2014 - 13:18
| этот сервер в сети имеет какое место положение по отношению ко второй сетке? | | |
| 6
- 29.01.2014 - 13:52
| А почему у сетевухи eth1 IP-адрес - 10.10.10.254? | | |
| 7
- 29.01.2014 - 13:59
|
midnightmoon, не совсем понял вопрос... есть маршрутизатор, на котором терминируются сетки и пр.., к нему подключен каталист, в который и сходятся линки от всех железок, на том же катале сконфигурен порт в режиме access с нужным vlan, в него и воткнут этот сервак. На порту никаких acces-list и прочего, да и как я уже писал - просто комп воткнутый в этот порт пингует всех без проблемм Добрых дел мастер - блин, там опечатка - ifconfig eth1 eth1 Link encap:Ethernet HWaddr 00:14:5e:6b:e6:3b inet addr:10.10.202.254 Bcast:10.10.202.255 Mask:255.255.255.0 inet6 addr: fe80::214:5eff:fe6b:e63b/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:28831 errors:0 dropped:0 overruns:0 frame:0 TX packets:28497 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2454915 (2.4 MB) TX bytes:2696246 (2.6 MB) Interrupt:17 | | |
| 8
- 29.01.2014 - 14:00
| а ip - просто выбрали чтобы случайно не назначить очередной железке | | |
| 9
- 29.01.2014 - 14:15
|
Попробуйте вручную очистить арп-таблицу, вручную создать запись в арп-таблице... Это, естественно, не решение, а "процесс диагностики" | | |
| 10
- 29.01.2014 - 14:22
| а как быть с потерями по ВСЕМ остальным железкам ? | | |
| 11
- 29.01.2014 - 14:33
| попробовал, не вышло, но что интересно - по arping host - ответ есть !!!! Чтобы это могло значить ? | | |
| 12
- 29.01.2014 - 14:46
|
у сервака две сетевые карты с двумя разными сетевыми адресами. и этот сервак воткнут обоими сетевыми картами в каталист? что за железо мониторится в 10.10.202.255 ? | | |
| 13
- 29.01.2014 - 14:58
|
2vano_kns Судя по вашим вопросам, вы меня неправильно поняли? Что именно вы "попробовали" и что у вас "не вышло"? Я имею в виду, на вышеуказанном серваке вручную в арп-таблицу добавить запись для одного из хостов, с которым сейчас наблюдаются проблемы и посмотреть, исчезла ли проблема. | | |
| 14
- 29.01.2014 - 14:59
|
midnightmoon - в итоге - да, только офисная сетка проходит через еще один коммутатор. ТОлько я не вижу в этом проблемы, тем более что раньше таких косяков не возникало Железо мониториться разное - каталисты, FlexDSL модемы и прочая муть,есть даже комп под виндой... | | |
| 15
- 29.01.2014 - 15:01
| Цитата:
| | |
| 16
- 29.01.2014 - 15:03
|
добавь в iptables # iptables -A FORWARD -s 10.152.78.1/8 -d 10.10.202.254/24 -j ACCEPT # iptables -A FORWARD -s 10.10.202.254/24 -d 10.152.78.1/8 -j ACCEPT заодно задумайся что для чего является шлюзом. | | |
| 17
- 29.01.2014 - 15:33
| Добавил - эффекта 0. Про шлюз - не понял, шлюз указан только для офисной сетки, для 202-й сетки - он не нужен, там одноранговая сеть. Да и как я ранее писал - я пробовал тушить офисную сетку а на eth1 прописывал шлюз 202.1 - изменений никаких... | | |
| 18
- 29.01.2014 - 16:07
| в сети с маршрутизатором "одноранговость" в принципе не может наблюдаться. | | |
| 19
- 29.01.2014 - 17:01
| Да, конечно, просто неверно выразился, я имел в виду что шлюз там не нужен для связи узлов друг с другом, все они в одном vlan, protected на портах не стоит, есть еще один ПК, включеный в тот же коммутатор, в порт, так же настроенный на нужный vlan, access-mode, и он прекрасно видит все узлы сети, а вот с серваком - какой то косяк. Не понятно - почему после ребута - он всё же успевает передать/получить один icmp запрос.. А вот дальше - как будто что то срабатывает и ответов уже нет...((( | | |
| 20
- 29.01.2014 - 17:03
|
в логах что-нибудь есть подходящее? /var/log/messages dmesg | | |
| 21
- 29.01.2014 - 17:40
|
Возможно игрались с параметрами ядра через sysctl. Выложите результат этой команды (можно на pastebin): Код: sudo sysctl -a | grep net | | |
| 22
- 29.01.2014 - 18:09
|
Добрых дел мастер - есть файл dmesg, но в нем ничего подозрительного...есть только ошибка 12.890514] init: Failed to obtain startpar-bridge instance: Unknown parameter: INSTANCE droidman - http://pastebin.com/6cbfF6ai Надеюсь правильно выложил. Только вот с ядром точно никто не игрался, до этого стояла 13.04 - рухнул винт, 13.10 поднимал уже сам, и по скольку в линуксах вообще не силен - ничего лишнего не жал - стандартная установка... | | |
| 23
- 29.01.2014 - 18:15
| я имел в виду вывод команды dmesg | | |
| 24
- 29.01.2014 - 18:55
|
Извиняюсь, не понял сразу )) Вот вывод http://pastebin.com/tBsi8wsg | | |
| 25
- 29.01.2014 - 19:07
|
inet addr:10.10.10.254 Bcast:10.152.78.255 Mask:255.255.255.0 не читая, чета меня смущает broadcast адрес, должен быть 10.10.10.255 а так арпы непойми как работают | | |
| 26
- 29.01.2014 - 19:15
| начал читать,увидел про очепятку....ну тогда хез tcpdump -i eth1 arp в помощь | | |
| 27
- 29.01.2014 - 20:40
| 701054 - в момент пинга - Reply 10.10.202.209 is-at 00:0f:d9:00:2a:54 (oui Unknown), length 46 | | |
| 28
- 29.01.2014 - 20:40
| 209 - хост, ноторый жив-здоров, но не откликается на пинг | | |
| 29
- 29.01.2014 - 20:58
| это тот же мак что и вначале когда пингуется ? ну просто чтоб исключить внешние проблемы и точно определиться что беда в никсовом серваке, если так то хз че можно накрутить такого раз ответы идут а в arp таблицу не попадает то даж не знаю , мож кто ebtables на нем тренировал или ещё какие извращения | | |
| 30
- 29.01.2014 - 21:09
| в общем ниче не понятно, я не знаю как так само может сделаться....попробуйте ufw вырубить просто от нечего делать, но это явно не оно мешает... | | |
| 31
- 29.01.2014 - 21:16
|
покажите Код: ifconfig -a Код: sysctl -a|grep arp | | |
| 32
- 30.01.2014 - 07:03
|
вывод ifconfig был выше, повторюсь - ifconfig -a eth0 Link encap:Ethernet HWaddr 00:14:5e:6b:e6:3a inet addr:10.152.78.2 Bcast:10.152.78.255 Mask:255.255.255.0 inet6 addr: fe80::214:5eff:fe6b:e63a/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:222 errors:0 dropped:12 overruns:0 frame:0 TX packets:257 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:29595 (29.5 KB) TX bytes:110604 (110.6 KB) Interrupt:16 eth1 Link encap:Ethernet HWaddr 00:14:5e:6b:e6:3b inet addr:10.10.202.254 Bcast:10.10.202.255 Mask:255.255.255.0 inet6 addr: fe80::214:5eff:fe6b:e63b/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:134 errors:0 dropped:0 overruns:0 frame:0 TX packets:93 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:12375 (12.3 KB) TX bytes:8377 (8.3 KB) Interrupt:17 lo Link encap:Локальная петля (Loopback) inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:24 errors:0 dropped:0 overruns:0 frame:0 TX packets:24 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:2198 (2.1 KB) TX bytes:2198 (2.1 KB) Про ebtables - никто на нём ничего не тренировал, ему 3 дня от роду, единственный мой косяк - не проверил эту заразу на чистой системе, до установки Nagios,Apache и прочего... sysctl -a|grep arp dev.parport.default.spintime = 500 dev.parport.default.timeslice = 200 net.ipv4.conf.all.arp_accept = 0 net.ipv4.conf.all.arp_announce = 0 net.ipv4.conf.all.arp_filter = 0 net.ipv4.conf.all.arp_ignore = 0 net.ipv4.conf.all.arp_notify = 0 net.ipv4.conf.all.proxy_arp = 0 net.ipv4.conf.all.proxy_arp_pvlan = 0 net.ipv4.conf.default.arp_accept = 0 net.ipv4.conf.default.arp_announce = 0 net.ipv4.conf.default.arp_filter = 0 net.ipv4.conf.default.arp_ignore = 0 net.ipv4.conf.default.arp_notify = 0 net.ipv4.conf.default.proxy_arp = 0 net.ipv4.conf.default.proxy_arp_pvlan = 0 net.ipv4.conf.eth0.arp_accept = 0 net.ipv4.conf.eth0.arp_announce = 0 net.ipv4.conf.eth0.arp_filter = 0 net.ipv4.conf.eth0.arp_ignore = 0 net.ipv4.conf.eth0.arp_notify = 0 net.ipv4.conf.eth0.proxy_arp = 0 net.ipv4.conf.eth0.proxy_arp_pvlan = 0 net.ipv4.conf.eth1.arp_accept = 0 net.ipv4.conf.eth1.arp_announce = 0 net.ipv4.conf.eth1.arp_filter = 0 net.ipv4.conf.eth1.arp_ignore = 0 net.ipv4.conf.eth1.arp_notify = 0 net.ipv4.conf.eth1.proxy_arp = 0 net.ipv4.conf.eth1.proxy_arp_pvlan = 0 net.ipv4.conf.lo.arp_accept = 0 net.ipv4.conf.lo.arp_announce = 0 net.ipv4.conf.lo.arp_filter = 0 net.ipv4.conf.lo.arp_ignore = 0 net.ipv4.conf.lo.arp_notify = 0 net.ipv4.conf.lo.proxy_arp = 0 net.ipv4.conf.lo.proxy_arp_pvlan = 0 | | |
| 33
- 30.01.2014 - 07:11
|
В общем боед полнейший, запустил одновременно пинг сервер->железка(37% потерь) и железка->cервер(0% потерь), получается сервак тупо не принимает пакеты от железок, от одних - периодически, от других - всегда...чушь какая то....Может грузит его что с какким-то периодом ? Как это посмотреть ? | | |
| 34
- 30.01.2014 - 07:54
| боед - бред | | |
| 35
- 30.01.2014 - 08:00
| хз, вроде ниче особеного...не было б вообще arp reply подумал бы что физика кривая с таким раскладом, а так я хз | | |
| 36
- 30.01.2014 - 08:21
| ну есть ещё всякие net.ipv4.icmp_ratelimit , но тут же я так понимаю в арп таблицу не попадает, кароч я пасс не знаю, найдете где собака зарыта, отпишите | | |
| 37
- 30.01.2014 - 08:33
|
+36, читанул не оно... оно в линуксе отнсится к icmp_ratemask, которое по-дефолту ICMP Destination Unreachable,ICMP Source Quench, ICMP Time Exceeded и ICMP Parameter Proble вот во фре net.inet.icmp.icmplim точно рубил icmp request\reply, это я видел так что вообще тогда даже предположений нет | | |
| 38
- 30.01.2014 - 09:17
| переустановить сервак было? ) | | |
| 39
- 30.01.2014 - 09:46
| серваку 3 дня отроду, до этого стоял 13,10 - наблюдалась та же фигня ( | |
