Jump to content
Калькуляторы

Bullet m2 перегрузка перегрузка Bullet m2 прерываниями

Доброго времени суток. Есть мост из двух Bullet m2: 10.10.10.5 - базовая станция (access point), 10.10.10.6 - клиент (station). Средняя скорость передачи данных в районе 55мбит. Однако переодически 10.10.10.6 "плохеет": load average подскакивает до 3.5, top говорит что основной cpu time таки ksoftirqd/0. Что самое интересное: у 10.10.10.5 таких проблем не наблюдается, load average 0.3-0.8. Прошивки идеентичные. По поводу сети: основной трафик идёт от 10.10.10.6 к 10.10.10.5, может проблема в этом? broadcast и anycast еще на подходе к точкам режут микротики. В чем может быть проблема?

Share this post


Link to post
Share on other sites

CCQ не прыгает: как был в районе 99...100% - так и стоит. Траффик - обычная активность абонов, точно такая-же, как и в моменты без перегрузки

Share this post


Link to post
Share on other sites

AirMax Priority: none. Резальтат: перегрузка все-еще имеет место

 

саоме интересное - это рандомность проявление проблемы: пробовал выключать шейперы на абонентов - все отлично работает с полной нагрузкой на канал. Вчера вечером после отключение airmax все работало отлично, сегодня-же (10 утра, минимум траффика) - проблема снова имеет место быть.

 

З.Ы. микротики умеют нормальный tcpdump, а не куцый packet sniffer?

Edited by Shumsky

Share this post


Link to post
Share on other sites

А если AirMax отключить?

На базе, но не суть -- видать отрублен.

 

З.Ы. микротики умеют нормальный tcpdump, а не куцый packet sniffer?

юбнт умеет, но в таком состоянии боюсь от этого мало толку.

Share this post


Link to post
Share on other sites

AirMax выключен на базе, на точке поставлено AirMax priority: none. Толку да, никакого абсолютно. Завтра поставим вместо bullet m2 bullet 2hp, посмотрим как себя повебет более старая модель. О результатах отпишусь (думается мне что проблема в конкретном устройстве)

Share this post


Link to post
Share on other sites

Bullet 2hp повела себя еще более невразумительно: пинги по 3000мс. Есть какие-нибудь идеи по поводу подвисаний? В данный момент рабочая идея - написать скриптик, который по определенному load average (например больше 1.0) будет ребутать точку. Однако это таки костыль, который очень некомильфо городить

Share this post


Link to post
Share on other sites

У Вас либо кто-то флудит, либо петля, если микротики с двух сторон роутерами -- порежте всё, кроме маршрутизируемых TCP/UDP, помониторьте pps

Кста, вариант, что загибается микротик, есть ли возможность проверить с внешней стороны? Может дублируется МАК?

 

В общем попытайтесь получить хоть какую-нить инфу о трафике....

Попробуйте убрать микротик вообще....

Share this post


Link to post
Share on other sites

Микротик убирал, без микротика такая-же ситуация. Петли нет: там 5 домов за точкой, петлять нечему совершенно. Опять-таки проблема нерегулярная:

20:53:49 up 7 min, load average: 0.94, 0.34, 0.14 << пол часа назад

21:26:26 up 40 min, load average: 1.25, 0.53, 0.33 << только-что

разницу видно невооруженным глазом.может и сутки нормально работать.

Микротики работают в штатном режиме.

pps стабильно на уровне 850-1000p\s. Во время "повышения нагрузки становится равен 650-700.

XM.v5.3.5.# ping 10.10.10.5
PING 10.10.10.5 (10.10.10.5): 56 data bytes
64 bytes from 10.10.10.5: seq=0 ttl=64 time=212.760 ms
64 bytes from 10.10.10.5: seq=1 ttl=64 time=434.462 ms
64 bytes from 10.10.10.5: seq=2 ttl=64 time=400.726 ms
64 bytes from 10.10.10.5: seq=3 ttl=64 time=413.289 ms
64 bytes from 10.10.10.5: seq=4 ttl=64 time=468.893 ms

во время перегрузки

XM.v5.3.5.# ping 10.10.10.5
PING 10.10.10.5 (10.10.10.5): 56 data bytes
64 bytes from 10.10.10.5: seq=0 ttl=64 time=9.008 ms
64 bytes from 10.10.10.5: seq=1 ttl=64 time=1.448 ms
64 bytes from 10.10.10.5: seq=2 ttl=64 time=4.179 ms
64 bytes from 10.10.10.5: seq=3 ttl=64 time=2.172 ms
64 bytes from 10.10.10.5: seq=4 ttl=64 time=2.159 ms

в нормальных условиях.

На микротиках порезано все, что только можно.

 

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

Share this post


Link to post
Share on other sites

снимай дамп (без него походу, никуды) и помониторь ошибки на порту, всяко бывает...

CCQ если мониторить по противоположной стороне не сваливается в момент проблем?

Share this post


Link to post
Share on other sites

сорри за долгий ответ. По дампу непонятно ничего: картина такая-же, как и в моменты без перегрузок. Ошибок на порту нет, однако откуда-то берется broabcast и multicast трафик (около 1к пакетов и тех, и других). Откуда берутся - непонятно. CCQ на другой стороне сваливается до 88%, после чего поднимается до 99-100.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.