Перейти к содержимому
Калькуляторы

atdp03

Активный участник
  • Публикации

    113
  • Зарегистрирован

  • Посещение

Все публикации пользователя atdp03


  1. Добрый всем. Две одинаковых по железу и софту машинки, с различающимся вдвое уровнем трафика, начали подсыпать пропуски. В логах из аномалий такое: 2022-05-22 11:28:47.717 [28895] Error ESender - Can't send packet. Buffer is full. 2022-05-22 11:28:47.717 [28895] Error ESender - Can't send packet. Buffer is full. 2022-05-22 11:29:07.826 [28895] Error ESender - Can't send packet. Buffer is full. 2022-05-22 11:29:07.827 [28895] Error ESender - Can't send packet. Buffer is full. Режим зеркала, разные локации, разные свичи. Я один такой везучий?
  2. Так и продолжается дикими всплесками. Но у меня 32 гига на машине, мне не особо критично пока.
  3. У меня мониторинг начал ругаться на использование памяти процессом. Триггер стоял на 200 мегабайт, срабатываний не было. После перехода на фильтрацию blocktype=ip с зеркала, срабатывания триггера вызывались потреблением в районе 6.9-7.1 гигабайт в момент обновления списков.
  4. Перепроверился. Это был старый бинарник. На новом греп ничего не возвращает вообще. Единственное из этой области в логе: 2019-10-12 00:47:36.802 [16288] Information ACL - Building ACL from file /root/reestr/extfilter/configs/hosts UPD: послал -HUP процессу, конфиг влился, заработал.
  5. Ругается, да: 2019-10-11 23:52:02.779 [7328] Information ACL - Preparing 1061560 rules for IPv4 ACL 2019-10-11 23:52:02.816 [7328] Information ACL - Preparing 50 rules for IPv6 ACL 2019-10-11 23:52:02.822 [7328] Error ACL - Setup acl for ipv4 with socketid 0 failed, keeping previous rules for that socket 2019-10-12 00:32:04.250 [7328] Information ACL - Preparing 1061560 rules for IPv4 ACL 2019-10-12 00:32:04.287 [7328] Information ACL - Preparing 50 rules for IPv6 ACL 2019-10-12 00:32:04.294 [7328] Error ACL - Setup acl for ipv4 with socketid 0 failed, keeping previous rules for that socket Чего-то не хватает?
  6. А как бы это подебажить? Обновил фильтр, ресетов не вижу. в hosts 22 мегабайта такого: 217.69.14.132/32, 6/0xfe 217.69.14.176/32, 6/0xfe 217.69.15.108/32, 6/0xfe 217.69.15.223/32, 6/0xfe ресетов не вижу. Редиректы на http и ресеты на https прилетают исправно. В логе: All worker threads matched by ip/port: 0 Плюс, перестаёт блочиться такое как https://18.200.8.105:16869/. Откатываюсь на предыдущую работавшую версию, от августа 18го, этот адрес начинает ресетиться.
  7. А кто-нить заводил rest api на ASR1000? Поддержка 100*-x согласно сайту появилась с версии 3.14. У нас в бою версия 3.13, которую сильно не хочется обновлять. Ключевой вопрос - насколько можно запускать контейнер из свежих версий на старом иосе?
  8. Есть ли жизнь на Марсе? Есть пара 7600, с указанным Rsp. Есть 3-4 full-view, 3-4 обменника, от 30 до 170к префиксов. Есть пяток приватных пиров от нескольких десятков до нескольких десятков тысяч префиксов. Есть стопка даунлинков с full-view, плюс несколько с дефолтом. Пока всё нормально - оно работает. Но стоит чихнуть кому-то крупному - начинается цепная реакция. Начинают сыпаться по таймаутам остальные сессии, мрёт по таймаутам ospf, короче полный набор удовольствий. Единственный шанс стабилизировать ситуацию - перегасить почти всё, дождаться стабилизации, и потом поштучно включать всё обратно, дожидаясь прожёвывания маршрутов. Понятно, что железке пора на пенсию. Однако процесс это небыстрый, и хотелось бы понять: есть ли шанс хоть как-то снизить нагрузку? Порезать принимаемые анонсы до минимум /24? В прилетающих маршрутах мелочь так и останется, и экономия проца будет только на этапе невнесения в tcam (сам вопрос tcam не рассматриваем, там всё нормально). Выкручивать таймауты? А оно действительно надо? При реальной смерти пира держать лишнее время маршруты в никуда? Требуется помощь коллективного разума.
  9. И можно сразу костыли, реагирующие на попадание адресов ipv6 в другие теги. =)
  10. Стерильно: 2018-09-04 19:03:56.150 [1440] Information Application - Port 1 input packets 8115511114, input errors: 0, mbuf errors: 0, missed packets: 0 Собственно, там и было стерильно, но фантомные пропуски были - тупо прокликиваю раз 20 одну и ту же ссыль - раз 8 открывается, остальное блочится. В отчётах ревизора - рандомные пропуски, каждый день разные, штук по 200. После подъёма числа очередей с 2х до 3х - пропуски исчезли. При этом scale - закомментировано.
  11. Логично, не подумал. Единственное существенное отличие между старой и новой системами - 16.04 и 18.04.
  12. Можно подвести промежуточные итоги. Старая система: Xeon 1270v3+16G, extfilter от 2 февраля 2018. Новая: Xeon 1270v5+32G, extfilter от 30го августа 2018. Сетевухи идентичны, зеркало то же. Старая машина жевала объём в один поток (num_of_workers=1). Новой понадобилось 3, чтобы избавиться от фантомных пропусков. По факту сделал 4, с запасом. core_mask = 31 [port 1] queues = 0,1; 1,2; 2,3; 3,4
  13. Авоткстати. Есть примерные рекомендации? Типа: 100-500-1000к пакетов в секунду на входе, M (физических?) ядер по N Ghz, P гигабайт памяти, Q из них под hugepages, X очередей в extfilter, scale = Y, memory_channels = Z.
  14. Да, подтверждаю. Браузер закешировал, как и упоминавшееся ранее:
  15. /reg:register/content/@id=1059333 /reg:register/content/@includeTime=2018-08-21T06:25:18 /reg:register/content/@entryType=1 /reg:register/content/@blockType=domain-mask /reg:register/content/@hash=057091A582193EB9762A3B8AC78A74E0 /reg:register/content/decision/@date=2016-05-13 /reg:register/content/decision/@number=2-6-27/ 2016-05-05-24-АИ /reg:register/content/decision/@org=ФНС /reg:register/content/domain=*.1xbet.mobi Апдейт, был невнимателен. При обращении к https://www.1xbet.mobi сайт редиректит на https://1xbet.mobi который успешно банится.
  16. Ага, оно. Ошибок стало 0. Натыкался на упоминания о том что оно не работает в dpdk, поэтому выключал. https://1xbet.mobi, https://www.1xbet.mobi - банятся. Зато перестал баниться http://1xbet.mobi - улетаю редиректом сайта на https, и вижу не заглушку а ресет. Причём, похоже это только этот сайт из проверенных. Остальные упоминавшиеся выше: https://www.paripartners162.com/ https://paripartners162.com/ https://www.mygreatmarathon.win/ https://www.leonbets8u.website/ банятся нормально.
  17. Навскидку - да, там qinq. Могу попробовать записать дамп в пяток секунд, если коробка справится. =)
  18. Поменял порт и модули. Со стороны свича всё стерильно. Со стороны коробки всё те же ~10 ошибок в секунду.
  19. Маловероятно, зеркало то же что работало со старой версией. Скорее я что-то недо/перекрутил. Присмотрелся ещё. Есть ссылки, которые пропускаются через раз: http://muzlishko.ru/mp3/Я+за+ЗОЖ,+всех+на+нож,+кто+на+людей+не+похож http://muzlishko.ru/mp3/Исламская+Умма http://muzlishko.ru/mp3/коррозия+металла+скинхед http://muzlishko.ru/mp3/РЕСТРУКТ ( аудио-книга ) Плюс каждый день при проверке вылезает сотня-другая ссылок, причём разных. Так что проблема, скорее всего, не в domain mask, а более общая. Железо - почти аналог предыдущего. Был Xeon 1270v3+16G, стал 1270v5+32G. Сеть та же, x520 двухпортовый, sender - через один из этих портов. Трафика до 800-900к ппс в пиках, как и ранее. В логе на приёмнике зеркала начали сыпаться ошибки: 2018-08-30 13:19:15.326 [867] Information Application - Port 1 input packets 33174693708, input errors: 2276583, mbuf errors: 0, missed packets: 0
  20. Про фрагментацию думал, но по сравнению с версией ~годовалой давности - заведомо фрагментируемые сайты как-раз начали фильтроваться. Не блочатся: https://1xbet.mobi/ https://www.1xbet.mobi/ откуда идёт редирект на первый урл. https://www.paripartners162.com/ https://paripartners162.com/ Решил ещё чуть пройтись по списку. Всё не так однозначно. =) https://www.mygreatmarathon.win/ - блочится https://www.leonbets8u.website/ - нет.
  21. Обновляюсь на свежий extfilter. Не фильтруются записи domain mask при обращении к https. По http эти записи фильтруются, остальные https - тоже. extfilter.ini: В конфигах всё есть: grep \*.1xbet.mobi * domains:*.1xbet.mobi ssl_host:*.1xbet.mobi grep paripartners162.com * domains:*.paripartners162.com ssl_host:*.paripartners162.com Не могу понять, что я недокрутил, требуется помощь зала.
  22. fiberstore, это fs.com? Ну и да - вендора озвучьте плз.
  23. Словили почти то же самое. Один медный qsfp работает несколько месяцев, ещё стопку dropout, проработавших пару лет - разобрали. Включили вместо них AOC. Начали флапать все QSFP, с теми же симптомами. Причём вместе с ними флапал и медный, который не трогали. Никто решения не находил?