mgo Опубліковано: 26 липня, 2014 Автор Опубліковано: 26 липня, 2014 (відредаговано) Хто таке бачив? Що воно таке? Нагрузка по Rx в 80-100 мегабіт і під 100 тисяч пакетів при вимкнутих усіх решта інтерфейсах. Появляється невідомо звідки, также пропадає. Проявляється одночасно на усіх аплінках від провайдера 1 , у провайдра 2 таких проблем ненаблюдаю. Провайдер 1 каже у него все гут. Відредаговано 26 липня, 2014 mgo
l1ght Опубліковано: 26 липня, 2014 Опубліковано: 26 липня, 2014 (відредаговано) Яка модель? В мене проблеми були з RB711, коли мережа була ну тупеньких коммутаторах, він ловив до 10к пакетів і клав лінк. Через якийсь час з'єднання поновлювалось і знову розривалось, лікувалось перезавантаженням. А потім коли поразставляв вумні свічі - і зробив ізоляцію портів, лінк став жити як і до того жив. Може так співпало, або дійсно допомогло. Також мікроти дуже чутливі до broadcast штормів. В мене в мережі один роутер тплінковський згорів, так робив шторм в мережі до 15к пакетів, в мене вмирали усі мікроти, а убнт жив собі и проблем не знав. І ця проблема вилікувалась свічами Відредаговано 26 липня, 2014 L1ght
mgo Опубліковано: 26 липня, 2014 Автор Опубліковано: 26 липня, 2014 433GL, 750UP, 2011L... перекинув на іншого прова все гут. BSD в якості НАС теж тормозить на прові 1 схоже у прова 1 чи то кольцо чи ще якась неприємність. лікувалось перезавантаженням. перезавантаження нічого не дає.
l1ght Опубліковано: 26 липня, 2014 Опубліковано: 26 липня, 2014 (відредаговано) А можете викласти скріншот із профайлом? tools -> profile Дуже цікаво звікди йде навантаження. Же можно навіситі правило в фаєрі на input з вхідного інтерфейсу. І взагалі при таких речах треба аналізувати трафік, звідки йде, на який інтерфейс. Зовні чи зсередини мережі. UPD Якійсь великий трафік йде до вас, у вас днс зовні закритий? 93к пакетів і 83 мегабіти трафіку. Відредаговано 26 липня, 2014 L1ght
mgo Опубліковано: 26 липня, 2014 Автор Опубліковано: 26 липня, 2014 (відредаговано) Же можно навіситі правило в фаєрі на input з вхідного інтерфейсу. немає реакції, уже пробував. І взагалі при таких речах треба аналізувати трафік, звідки йде, на який інтерфейс. інтерфейс аплінку. зараз глюк пропав, усе працює нормально. ще оце заскрінив коли глючило Відредаговано 26 липня, 2014 mgo
l1ght Опубліковано: 26 липня, 2014 Опубліковано: 26 липня, 2014 (відредаговано) По перше, хтось вас таки добрячи "пінгує" По друге, зробіть фаєр закритим і дозволяйте те, що вам потрібно - Best Practice! Відредаговано 26 липня, 2014 L1ght
nightfly Опубліковано: 26 липня, 2014 Опубліковано: 26 липня, 2014 зараз глюк пропав, усе працює нормально. Угу, аплінк намба уан вернувсє пєний та злий з шашликів, та роздав піздюлєй всім винним та нєпрічасним. Хурма в зайвих 100-150кппс по окремих районах ліквідована. По друге, зробіть фаєр закритим і дозволяйте те, що вам потрібно - Best Practice! Тож не панацея, коли фізика забита в полік. Ріж не ріж фаєром, зливай в блекхоул - нормальному трафіку всеодно місця нема.
l1ght Опубліковано: 26 липня, 2014 Опубліковано: 26 липня, 2014 По друге, зробіть фаєр закритим і дозволяйте те, що вам потрібно - Best Practice! Тож не панацея, коли фізика забита в полік. Ріж не ріж фаєром, зливай в блекхоул - нормальному трафіку всеодно місця нема. Так то не панацея, але йде icmp трафік, що вказує на те, що при закритому фаєрі ціею проблеми не було б.
nightfly Опубліковано: 26 липня, 2014 Опубліковано: 26 липня, 2014 (відредаговано) Так то не панацея, але йде icmp трафік, що вказує на те, що при закритому фаєрі ціею проблеми не було б. ага.. дематеріалізувався б він..... трансцендентно.. Відредаговано 26 липня, 2014 nightfly
l1ght Опубліковано: 26 липня, 2014 Опубліковано: 26 липня, 2014 Так то не панацея, але йде icmp трафік, що вказує на те, що при закритому фаєрі ціею проблеми не було б. ага.. дематеріалізувався б він..... трансцендентно.. Ні, але я гадаю, що він надходив би у такій кількості, що це не викликало б проблем. Тому що коли ротуер\машина не відповідає на пінг - йде очікування відповіді, перед тим як послати наступний запит. Більше очікування - менше навантаження.
nightfly Опубліковано: 26 липня, 2014 Опубліковано: 26 липня, 2014 Ок. Поки що залишу вас на одинці, аби дати час подумати або просвітитись на тему того, як працюють мережі. Натяк намба уан - icmp далеко не синонім тогопнга, що ви бачите в cmd->ping з його відомим "прєвишен інтервал ажиданія". Натяк намба ту - від того, що там за фігня намальована в фаєрі, кількість грубо pps*mtu в фізичному порті фізіологічно не зміниться, які б фантазії з цього приводу не приходили. Натяк намба три - deny теж pps залежна операція.
l1ght Опубліковано: 26 липня, 2014 Опубліковано: 26 липня, 2014 Ок. Поки що залишу вас на одинці, аби дати час подумати або просвітитись на тему того, як працюють мережі. Натяк намба уан - icmp далеко не синонім тогопнга, що ви бачите в cmd->ping з його відомим "прєвишен інтервал ажиданія". Натяк намба ту - від того, що там за фігня намальована в фаєрі, кількість грубо pps*mtu в фізичному порті фізіологічно не зміниться, які б фантазії з цього приводу не приходили. Натяк намба три - deny теж pps залежна операція. Я знаю, що icmp - не завжди пінг. Я привів це як приклад.
mgo Опубліковано: 27 липня, 2014 Автор Опубліковано: 27 липня, 2014 Угу, аплінк намба уан вернувсє пєний та злий з шашликів, та роздав піздюлєй всім винним та нєпрічасним. Хурма в зайвих 100-150кппс по окремих районах ліквідована. І зарубаний icmp протокол в корінь) Нічого не пінговається але працює
nightfly Опубліковано: 27 липня, 2014 Опубліковано: 27 липня, 2014 І зарубаний icmp протокол в корінь) Аплінк намба уан до понеділка похмелиться і прийде розрулювати то гівно. Іцмп нє нужен
mgo Опубліковано: 29 липня, 2014 Автор Опубліковано: 29 липня, 2014 (відредаговано) Тицніть носом де туплю. Є: на білінгу мережа користувачів 172.16.0.1/16 НАСи з білінгом зєднані EoIP тунелем (емулятор витої пари) тунелі в бріджі на білінгу і на НАСі з юзерінтерфейсом. На насі роблю 172.16.1.1/16 юзеру видаю 172.16.1.2/24 НАС з білінгом пінговаються, білінг з користувачем по IP нехоче, по МАКу пінгує, після пінгу по МАК IP теж починає пінгуватися. За кілька хвилин знову зникає пінг по IP, і так поки знову не попінгуєш МАК. В чому може бути затик? проблему виявив сьогодні, до цоього часу все ніби добре їхало. Відредаговано 29 липня, 2014 mgo
nightfly Опубліковано: 29 липня, 2014 Опубліковано: 29 липня, 2014 За кілька хвилин знову зникає пінг по IP, і так поки знову не попінгуєш МАК. як варіант arp who has намагається піти в обхід тунелю по фізиці. Біллінг взагалі в курсі, де знаходиться 172.16.0.1/16? Ну раутами там, чи як...
mgo Опубліковано: 29 липня, 2014 Автор Опубліковано: 29 липня, 2014 Біллінг взагалі в курсі, де знаходиться 172.16.0.1/16 ну це намальовано в rc.conf на самому білінгу ifconfig на білінгу, bridge0 - юзерь інтерфйс, ngethХ тунелі bridge0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500 ether 02:d9:17:2f:c5:00 inet 172.16.0.1 netmask 0xffff0000 broadcast 172.16.255.255 inet 172.32.0.1 netmask 0xfffff000 broadcast 172.32.15.255 inet 10.10.10.1 netmask 0xffffff00 broadcast 10.10.10.255 id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: ngeth10 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP> ifmaxaddr 0 port 22 priority 128 path cost 55 member: ngeth9 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP> ifmaxaddr 0 port 21 priority 128 path cost 20000 member: ngeth8 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP> ifmaxaddr 0 port 20 priority 128 path cost 20000 member: ngeth7 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP> ifmaxaddr 0 port 19 priority 128 path cost 20000 member: ngeth6 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP> ifmaxaddr 0 port 18 priority 128 path cost 20000 member: ngeth5 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP> ifmaxaddr 0 port 17 priority 128 path cost 20000 member: ngeth4 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP> ifmaxaddr 0 port 16 priority 128 path cost 20000 member: ngeth3 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP> ifmaxaddr 0 port 15 priority 128 path cost 20000 member: ngeth2 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP> ifmaxaddr 0 port 14 priority 128 path cost 20000 member: ngeth1 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP> ifmaxaddr 0 port 13 priority 128 path cost 20000 member: ngeth0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP> ifmaxaddr 0 port 12 priority 128 path cost 20000 ngeth0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=28<VLAN_MTU,JUMBO_MTU> ether 00:11:00:22:00:01 media: Ethernet autoselect (1000baseT <full-duplex>) status: active ngeth1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=28<VLAN_MTU,JUMBO_MTU> ether 20:11:00:22:00:02 media: Ethernet autoselect (1000baseT <full-duplex>) status: active ngeth2: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=28<VLAN_MTU,JUMBO_MTU> ether 20:11:00:22:00:03 media: Ethernet autoselect (1000baseT <full-duplex>) status: active ngeth3: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=28<VLAN_MTU,JUMBO_MTU> ether 20:11:00:22:00:04 media: Ethernet autoselect (1000baseT <full-duplex>) status: active ngeth4: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=28<VLAN_MTU,JUMBO_MTU> ether 20:11:00:22:00:05 media: Ethernet autoselect (1000baseT <full-duplex>) status: active ngeth5: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=28<VLAN_MTU,JUMBO_MTU> ether 20:11:00:22:00:06 media: Ethernet autoselect (1000baseT <full-duplex>) status: active ngeth6: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=28<VLAN_MTU,JUMBO_MTU> ether 20:11:00:22:00:07 media: Ethernet autoselect (1000baseT <full-duplex>) status: active ngeth7: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=28<VLAN_MTU,JUMBO_MTU> ether 20:11:00:22:00:08 media: Ethernet autoselect (1000baseT <full-duplex>) status: active ngeth8: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=28<VLAN_MTU,JUMBO_MTU> ether 20:11:00:22:00:10 media: Ethernet autoselect (1000baseT <full-duplex>) status: active ngeth9: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=28<VLAN_MTU,JUMBO_MTU> ether 20:11:00:22:10:10 media: Ethernet autoselect (1000baseT <full-duplex>) status: active
mgo Опубліковано: 29 липня, 2014 Автор Опубліковано: 29 липня, 2014 (відредаговано) Проблема з пінгом у тільки у клієнтів, НАСи пінгуються чудово починаю пінгувати клієнта з будьчого іншонго зразу і білінг його пінгує. Відредаговано 29 липня, 2014 mgo
mgo Опубліковано: 30 липня, 2014 Автор Опубліковано: 30 липня, 2014 (відредаговано) mtr до NAS що за знаки питання в пунктах 1-5? натяк на яку проблему? коли уже пішов пінг то є тільки один пункт без знаків питання. в догонку мені вилізла ще осьата проблема #sgconf_xml -s 127.0.0.1 -p 5555 -a admin -w 123456 -r "<GetAdmins/>" Connect failed! ------------------------------------------------------------ думки в "голос" про пінги Усе працювало чудово до грози, поки не вигоріло кілька БС і дофіга клієнтів. Підгорений клієнт може створювати бурю пакетів або ще якусь лобуду в мережі. у мене білінг у бріджі з НАСама і клієнтами через EoIP, щоб клієнт получав адресу від білінга. Топто один підгорений клієнт може повалити усю мережу. Відредаговано 30 липня, 2014 mgo
madf Опубліковано: 30 липня, 2014 Опубліковано: 30 липня, 2014 ... в догонку мені вилізла ще осьата проблема #sgconf_xml -s 127.0.0.1 -p 5555 -a admin -w 123456 -r "<GetAdmins/>" Connect failed! ------------------------------------------------------------думки в "голос" про пінги Усе працювало чудово до грози, поки не вигоріло кілька БС і дофіга клієнтів. Підгорений клієнт може створювати бурю пакетів або ще якусь лобуду в мережі. у мене білінг у бріджі з НАСама і клієнтами через EoIP, щоб клієнт получав адресу від білінга. Топто один підгорений клієнт може повалити усю мережу. Мабуть до купи згорів і loopback Гляньте шо у stargazer.log після такої команди.
mgo Опубліковано: 30 липня, 2014 Автор Опубліковано: 30 липня, 2014 stargazer.log 2014-07-30 16:13:12 -- ReadSettings error. Cannot read file stop/stargazer.conf 2014-07-30 16:13:19 -- DOTCONF++: file 'stop/stargazer.conf': realpath('stop/stargazer.conf') failed: No such file or directory 2014-07-30 16:13:19 -- ReadSettings error. Cannot read file stop/stargazer.conf 2014-07-30 16:13:20 -- DOTCONF++: file 'stop/stargazer.conf': realpath('stop/stargazer.conf') failed: No such file or directory 2014-07-30 16:13:20 -- ReadSettings error. Cannot read file stop/stargazer.conf 2014-07-30 16:13:32 -- +++++++++++++++++++++++++++++++++++++++++++++ 2014-07-30 16:13:37 -- Module: 'CAP_NF v. 0.4'. Stop successfull.
mgo Опубліковано: 30 липня, 2014 Автор Опубліковано: 30 липня, 2014 (відредаговано) і php жре проц під 100% Відредаговано 30 липня, 2014 mgo
mgo Опубліковано: 30 липня, 2014 Автор Опубліковано: 30 липня, 2014 (відредаговано) ReadSettings error. Cannot read file stop/stargazer.conf мля та це ж я стопанув старгейзера хоча він ще з якогось дива у процесах висів. Відредаговано 30 липня, 2014 mgo
madf Опубліковано: 30 липня, 2014 Опубліковано: 30 липня, 2014 ReadSettings error. Cannot read file stop/stargazer.confмля та це ж я стопанув старгейзера хоча він ще з якогось дива у процесах висів. Не стопнув а намагався стартувати з лівим конфігом. Можливо паралельно з уже запущеним.
mgo Опубліковано: 30 липня, 2014 Автор Опубліковано: 30 липня, 2014 Не стопнув а намагався стартувати з лівим конфігом. stargazer stop міг намалювати у мене в top два stargazer висять так має бути?
Рекомендованные сообщения
Создайте аккаунт или войдите в него для комментирования
Вы должны быть пользователем, чтобы оставить комментарий
Создать аккаунт
Зарегистрируйтесь для получения аккаунта. Это просто!
Зарегистрировать аккаунтВхід
Уже зарегистрированы? Войдите здесь.
Войти сейчас