Перейти до

Пропадает интернет, "пропадают" пакеты


Рекомендованные сообщения

Всем доброго времени суток!

На одном "тазике" - Free+Ubilling+NAS (в данный момент около 50-ти абонов) выявилась проблема - без всякой зависимости от нагрузки, времени суток и т.д. пропадает интернет от нескольких секунд до несколько минут. Может за несколько суток ни разу не пропасть, а может в течении суток пропасть несколько раз. Конкрет "поймать" причину не удается, запустил всевозможные пинги в файл и выяснились пропадания пакетов:

Ответ от 172.16.0.1: число байт=25000 время=9мс TTL=64
Ответ от 172.16.0.1: число байт=25000 время=10мс TTL=64
Ответ от 172.16.0.1: число байт=25000 время=10мс TTL=64
Ответ от 172.16.0.1: число байт=25000 время=9мс TTL=64
Ответ от 172.16.0.1: число байт=25000 время=9мс TTL=64
Ответ от 172.16.0.1: число байт=25000 время=10мс TTL=64
Ответ от 172.16.0.1: число байт=25000 время=14мс TTL=64
Ответ от 172.16.0.1: число байт=25000 время=10мс TTL=64
Ответ от 172.16.0.1: число байт=25000 время=11мс TTL=64
Ответ от 172.16.0.1: число байт=25000 время=10мс TTL=64
Ответ от 172.16.0.1: число байт=25000 время=10мс TTL=64
Ответ от 172.16.0.1: число байт=25000 время=9мс TTL=64
Превышен интервал ожидания для запроса.
Превышен интервал ожидания для запроса.
Ответ от 172.16.0.1: число байт=25000 время=9мс TTL=64
Ответ от 172.16.0.1: число байт=25000 время=9мс TTL=64
Ответ от 172.16.0.1: число байт=25000 время=9мс TTL=64
Ответ от 172.16.0.1: число байт=25000 время=10мс TTL=64
Ответ от 172.16.0.1: число байт=25000 время=10мс TTL=64
Ответ от 172.16.0.1: число байт=25000 время=10мс TTL=64
Ответ от 172.16.0.1: число байт=25000 время=10мс TTL=64
Ответ от 172.16.0.1: число байт=25000 время=11мс TTL=64
Ответ от 172.16.0.1: число байт=25000 время=10мс TTL=6


Ответ от 172.32.0.1: число байт=25000 время<1мс TTL=64
Ответ от 172.32.0.1: число байт=25000 время<1мс TTL=64
Ответ от 172.32.0.1: число байт=25000 время=2мс TTL=64
Ответ от 172.32.0.1: число байт=25000 время<1мс TTL=64
Ответ от 172.32.0.1: число байт=25000 время<1мс TTL=64
Ответ от 172.32.0.1: число байт=25000 время<1мс TTL=64
Ответ от 172.32.0.1: число байт=25000 время<1мс TTL=64
Ответ от 172.32.0.1: число байт=25000 время<1мс TTL=64
Ответ от 172.32.0.1: число байт=25000 время<1мс TTL=64
Ответ от 172.32.0.1: число байт=25000 время<1мс TTL=64
Ответ от 172.32.0.1: число байт=25000 время<1мс TTL=64
Ответ от 172.32.0.1: число байт=25000 время<1мс TTL=64
Ответ от 172.32.0.1: число байт=25000 время<1мс TTL=64
Ответ от 172.32.0.1: число байт=25000 время<1мс TTL=64
Ответ от 172.32.0.1: число байт=25000 время<1мс TTL=64
Ответ от 172.32.0.1: число байт=25000 время<1мс TTL=64
Ответ от 172.32.0.1: число байт=25000 время<1мс TTL=64
Ответ от 172.32.0.1: число байт=25000 время<1мс TTL=64
Ответ от 172.32.0.1: число байт=25000 время<1мс TTL=64
Ответ от 172.32.0.1: число байт=25000 время<1мс TTL=64
Ответ от 172.32.0.1: число байт=25000 время<1мс TTL=64
Ответ от 172.32.0.1: число байт=25000 время<1мс TTL=64
Ответ от 172.32.0.1: число байт=25000 время<1мс TTL=64
Ответ от 172.32.0.1: число байт=25000 время<1мс TTL=64


конфиги стандартные, 172.16.0.1 и 172.32.0.1 - это одна и та же сетевая, пните куда искать, и почему такая разнице в пинге?

Ссылка на сообщение
Поделиться на других сайтах

Разьемы, коннектора.

Это конечно проверил, уточню, на сетевой 2-а айпи адреса, для проверки добавлял еще один, но все равно пакеты теряются только по одному адресу 172.25.0.1 по остальным потерь нет, если бы проблема была с железом то терялись бы по всем адресам.

Ссылка на сообщение
Поделиться на других сайтах

 

Разьемы, коннектора.

Это конечно проверил, уточню, на сетевой 2-а айпи адреса, для проверки добавлял еще один, но все равно пакеты теряются только по одному адресу 172.25.0.1 по остальным потерь нет, если бы проблема была с железом то терялись бы по всем адресам.

 

Во время лагов как минимум хотелось бы увидить 

netstat -i 1

и

top -SH
Ссылка на сообщение
Поделиться на других сайтах

 

 

Во время лагов как минимум хотелось бы увидить

netstat -i 1 и

top -SH

Везде все в порядке, "лаги" т.е. потери пакетов постоянно

netstat -i 1:

            input        (Total)           output
   packets  errs idrops      bytes    packets  errs      bytes colls
      6756     0     0    5018469       6722     0    4972559     0
      7984     0     0    6101178       7993     0    6098832     0
      6211     0     0    4555551       6185     0    4531348     0
      4955     0     0    3369144       4939     0    3347228     0
      5661     0     0    4160858       5655     0    4149946     0
      6432     0     0    4832996       6360     0    4763685     0
      8299     0     0    6540802       8305     0    6530373     0
      6324     0     0    4508937       6320     0    4497397     0
      6978     0     0    5182153       6970     0    5179820     0
      6056     0     0    4352643       5984     0    4271505     0
      8074     0     0    6521823       8059     0    6494994     0
      7686     0     0    6060953       7636     0    5980461     0
      8157     0     0    6751984       8135     0    6727278     0
      6923     0     0    5407525       6908     0    5388683     0
      8360     0     0    6888863       8245     0    6740981     0
      7477     0     0    6147312       7469     0    6141396     0

top -SH:

  PID USERNAME   PRI NICE   SIZE    RES STATE   C   TIME    WCPU COMMAND
   11 root       155 ki31     0K   128K CPU0    0 540.1H 100.00% idle{idle: cpu0}
   11 root       155 ki31     0K   128K CPU3    3 537.2H 100.00% idle{idle: cpu3}
   11 root       155 ki31     0K   128K CPU2    2 537.2H 100.00% idle{idle: cpu2}
   11 root       155 ki31     0K   128K CPU7    7 526.0H 100.00% idle{idle: cpu7}
   11 root       155 ki31     0K   128K CPU4    4 540.2H  99.17% idle{idle: cpu4}
   11 root       155 ki31     0K   128K CPU6    6 540.3H  99.07% idle{idle: cpu6}
   11 root       155 ki31     0K   128K CPU1    1 533.3H  99.07% idle{idle: cpu1}
   11 root       155 ki31     0K   128K RUN     5 524.2H  96.19% idle{idle: cpu5}
   12 root       -92    -     0K   336K WAIT    7  18.2H   4.20% intr{irq256: bce0}
   12 root       -92    -     0K   336K WAIT    7 966:39   2.49% intr{irq258: bce1}
  930 nobody      20    0 16320K  5412K select  1 102:46   0.10% softflowd
    0 root       -92    0     0K   160K -       2 681:37   0.00% kernel{dummynet}
   12 root       -100    -     0K   336K WAIT    0 127:35   0.00% intr{irq20: hpet0 uhc}
   12 root       -60    -     0K   336K WAIT    0 117:50   0.00% intr{swi4: clock}
    8 root        16    -     0K    16K syncer  1  60:02   0.00% syncer
   14 root       -16    -     0K    16K -       5  53:00   0.00% yarrow
  929 root        20    0 41724K  6300K bpf     2  36:03   0.00% bandwidthd
  926 root        20    0 58108K 21924K bpf     3  35:02   0.00% bandwidthd
  927 root        20    0 54012K 14540K bpf     4  35:01   0.00% bandwidthd
Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Вхід

Уже зарегистрированы? Войдите здесь.

Войти сейчас
  • Зараз на сторінці   0 користувачів

    Немає користувачів, що переглядають цю сторінку.

  • Схожий контент

    • Від ppv
      Потрібно було витерти одну мережу, всі абоненти з неї були перенесені в іншу. Але світить що 6 IP зайняті, хоча вона повністю вільна.
       
      ID    Мережа/CID           RВсього IP        Використано IP ▾           Вільно IPСервіс
      6      172.16.70.0/23        506                    6                                       500
       
      Підкажіть як правильно це підчистити щоб видалити мережу.
    • Від sanyadnepr
      Приветствую всех.
      Подскажите пожалуйста где копнуть и нет ли проблемы со стороны протокола взаимодействия сити24 или возможно не учтена необходимая проверка в модуле сити24 в Ubilling, пока писал понял что похоже в проверке payID, но это не точно.  
      Недавно обнаружилось с сити24 начали прилетать дубликаты платежей, в целом платежей мало, два одинаковых запроса Pay с одинаковым transactionID и payID в одну секунду одному платежному ID при этом биллинг "думает" примерно чуть больше минуты и отвечает одним ответом <result>0</result>, сити24 утверждает что ответ они не получили и по протоколу дальше повторяет запросы дублем, биллинг ответ и так по кругу, сити24 спрашивает каким образом с одинаковым payID от сити24 билл продолжает обрабатывать запросы и пополнять абоненту счет раз в 5 минут примерно, на одну и туже сумму, ведь этот payID уже был обработан предполагают сити24 согласно протоколу.
      Конечно есть вопрос к сити24 зачем они дублем присылают два запроса, но они отвечают что эта ситуация учтена в протоколе и проблема на стороне биллинга, потому что он пополняет счет по уже обработанному одинаковому payID.
      При этом transactionID в дублях одинаковый, но с каждым новым дублем разный.
      Если зафаерволить запросы от сити24, но оставить возможность отвечать то после блокировки билл отправляет 2-3 минуты 6 ответов <account>0001</account>  <result>0</result>.
      После снятия блокировки, дубли и платежи нескольких проблемных абонентов прилетают так же по кругу, при этом и с некоторыми новыми пополнениями происходит аналогичная ситуация.
      В openpayz в платежах transactionID и не видно payID.
    • Від nightfly
      Ubilling 1.4.3 rev 9058 The Bladewood Grove
       
      Зміни в структурі БД. alter.ini: нові опції OPHANIMFLOW_ENABLED та OPHANIMFLOW_URLS котрі вмикають та керують інтеграцією з OphanimFlow. alter:ini: нова опція PHOTOSTORAGE_POSTPROCESSING, що вмикає післяобробку зображень при завантаженні в Сховище зображень. alter:ini: нова опція PHOTOSTORAGE_WATERMARK, що вмикає розміщення вотермарки на всіх зображеннях, що завантажуються. alter:ini: нова опція PHOTOSTORAGE_RECOMPRESS, що вмикає зміну компрессії завантажених зображень. alter:ini: нова опція PHOTOSTORAGE_AUTORESIZE, що вмикає автоматичне та лагідне масштабування зображень конячих розмірів. alter:ini: нова опція PHOTOSTORAGE_DRAWIMGINFO, що вмикає вдруковування в зображення відлагоджувальної інформації. alter.ini: нова опція ONDEMAND_CHARTS, що вмикає відкладене завантаження графіків завантаження користувацької смуги. userstats.ini: нова опція OPHANIM_ENABLED, що вмикає інтеграцію OphanimFlow в кабінеті користувача. Модуль Заздрість: тепер авторизаційні дані пристроїв, не відображаються в списку пристроїв. Модуль “Заздрість”: при створенні та редагуванні пристроїв, для полів “пароль” та “enable пароль” тепер використовуються інпути паролів. Модуль “Заздрість”: заздрісним пристроям додано нове поле “Порт”. Тепер в скриптах можна використовувати, відповідний макрос {PORT}. Модуль “Статистика трафіку користувача”: проведено радикальний рефакторинг. Модуль “Статистика трафіку користувача”: додано опційну можливість, відображення трафіку отриманого з OphanimFlow. Модуль “Статистика трафіку користувача”: виправлено проблему невірного відображення залишку коштів на кінець місяця, при використанні Ішимури. Модуль “Статистика трафіку користувача”: додано можливість відображення графіків за останню годину з OphanimFlow. Модуль “Користувачі”: додано опційну можливість, відображення трафіку отриманого з OphanimFlow. Модуль “Сховище зображень”: тепер додатково перевіряє завантажувані зображення на тему їх валідності. Модуль “Фінансові операції”: виправлено відображення суми платежів користувача. Remote API: новий виклик ophanimtraff, який просто бере і синхронізує локальну БД з віддаленими джерелами OphanimFlow. Remote API: виклик userbynum тепер також опційно містить поле з “Платіжним ID” користувача. Глобально: у всіх полях вводу паролів, окрім форми входу, тепер відображається елемент керування “показати/приховати” пароль. Кабінет користувача: в модулі “Трафік” додано опційну можливість, відображення трафіку отриманого з OphanimFlow. Кабінет користувача: в модулі “Трафік” виправлено проблему невірного відображення залишку коштів на кінець місяця, при використанні Ішимури. Кабінет користувача: в модулі “Відеоспостереження” для NVR WolfRecorder замінено розділювач попередньо заповнених даних авторизації. OpenPayz: додано frontend portmonemulti, для отримання платежів від різних контрагентів. Інформацію по контрагентам бере з біллінгу, також використовую розширену інформацію контрагента. Платіжна система в контрагенті мусить бути створена, як PORTMONE 1984tech: додано функціонал генерації RPZ для isc-bind, спасибі @misterromanbush  
      Повний чейнджлог
      Оновлена демка
       

    • Від mac
      Здається, після оновлення PHP 7.4 до PHP 8.2 feesharvester припинив працювати:
       
      /usr/local/bin/curl "http://127.0.0.1/billing/?module=remoteapi&key={SERIAL}&action=feesharvester" <br /> <b>Fatal error</b>: Uncaught TypeError: Unsupported operand types: string - string in {UBPATH}/billing/api/libs/api.fundsflow.php:570 Stack trace: #0 {UBPATH}/billing/modules/remoteapi/feesharvester.php(22): FundsFlow-&gt;harvestFees('2024-01') ...  
      Невеличке розслідування врешті з'ясувало, що це через наявність пробілу у деяких логінах абонентів. Як так сталося? Тому що інколи був неуважно додан трейлінг пробіл до номеру будинка і цей пробіл потрапив до логіну абоненту. Логін абоненту неможливо змінити ніяким чином штатними засобами. Я не розглядаю створення нового абонента для усунення помілки.

      Був обран такий шлях вирішення проблеми. Заміну функції php explode() знайшов у мережі. Мабуть це станеться в нагоді:

       
      diff api.fundsflow.php.bak api.fundsflow.php.new 559c559 < $eachfee = explode(' ', $eachline); --- > $eachfee = preg_split("~(?<!\\\\)(?:\\\\{2})*'[^'\\\\]*(?:\\\\.[^'\\\\]*)*'(*SKIP)(*F)|\s+~s" , $eachline);  
    • Від Dilan
      Собственно ищу кто сделает такую связку с нуля под ключ. Тз высылаю в личку. Заранее спасибо.
×
×
  • Створити нове...