swsn Опубликовано 17 сентября, 2019 · Жалоба Интересует еще как распределять для бриджа ядра по портам subscriber/network. Равное количество? или основная нагрузка уходит на один из портов? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
max1976 Опубликовано 17 сентября, 2019 · Жалоба 1 час назад, swsn сказал: Интересует еще как распределять для бриджа ядра по портам subscriber/network. Равное количество? или основная нагрузка уходит на один из портов? Нагрузка должна распространяться по всем процессам согласно rss. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
swsn Опубликовано 17 сентября, 2019 · Жалоба 3 часа назад, max1976 сказал: Нагрузка должна распространяться по всем процессам согласно rss. Странно что статистика только по одному воркеру, я выделил 5 ядер e3 1280 v2 . Не может же 400к в сек. пакетов одна очередь и одно ядро обработать с missed 0)) сетевая x710 четырех головая. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
max1976 Опубликовано 17 сентября, 2019 · Жалоба 1 час назад, swsn сказал: Не может же 400к в сек. пакетов одна очередь и одно ядро обработать с missed 0)) Может и больше. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
swsn Опубликовано 18 сентября, 2019 · Жалоба 12 часов назад, max1976 сказал: Может и больше. Я тут нашел на stackoverflow что на intel x710 ETH_RSS_IPV4 не работает как надо. И пакеты прибиваются к нулевой очереди. Внес правку в main.cpp: portConf.rx_adv_conf.rss_conf.rss_hf = ETH_RSS_IPV4 | ETH_RSS_IPV6 | ETH_RSS_FRAG_IPV4 | ETH_RSS_NONFRAG_IPV4_TCP; Статистика по остальным воркерам появилась. Сам я на плюсах не пишу, и соответственно у меня вопрос: Такой костыль допустим вообще?)) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Morphus Опубликовано 18 сентября, 2019 · Жалоба Кому интересно, сделал контейнер для конвертации эцп с гостом в pem. https://cloud.docker.com/repository/docker/morphoratorus/crypto2pem А так же для скачки дампа (zapret.pl): https://cloud.docker.com/repository/docker/morphoratorus/rkn-get-dump И формирования конифгов (extmaker.pl): https://cloud.docker.com/repository/docker/morphoratorus/maker Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
max1976 Опубликовано 18 сентября, 2019 (изменено) · Жалоба 1 час назад, swsn сказал: Сам я на плюсах не пишу, и соответственно у меня вопрос: Такой костыль допустим вообще?)) Если в вашем случае это решает проблему, то вполне приемлемый вариант. Изменено 18 сентября, 2019 пользователем max1976 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
disappointed Опубликовано 18 сентября, 2019 · Жалоба Рост кол-ва айпишников стал строго предсказуемым. 13800 адресов в сутки. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Antares Опубликовано 18 сентября, 2019 · Жалоба 3 минуты назад, disappointed сказал: Рост кол-ва айпишников стал строго предсказуемым. 13800 адресов в сутки. Не радует :( Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
disappointed Опубликовано 18 сентября, 2019 · Жалоба А чего стоит 35 тысяч адресов ipv6 внутри одного /64 префикса. На минуточку - этот минимум на клиента, в 6-ке, но только в нём >18 квинтиллионов адресов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 18 сентября, 2019 · Жалоба Ну так, работу работают. Адреса добавляются, видимость бурной деятельность формируется, зарплата капает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
arhead Опубликовано 18 сентября, 2019 (изменено) · Жалоба Когда звонил РЧЦ говорили мне что у многих операторов когда Blackhole превысил 512 тыс маршрутов начали блокировки не работать. Что сделали не знаю. Чувствую что скоро опять гугл и т.д. поломают Изменено 18 сентября, 2019 пользователем arhead Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
disappointed Опубликовано 18 сентября, 2019 · Жалоба 7 минут назад, arhead сказал: Когда звонил РЧЦ говорили мне что у многих операторов когда Blackhole превысил 512 тыс маршрутов начали блокировки не работать. Что сделали не знаю. Чувствую что скоро опять гугл и т.д. поломают Да я тоже попал тогда, и ещё ранее, когда пересекали 256 тысяч. Потому обвешал всё триггерами теперь, и на стороне где генерится, и на сторонах где исполняется. Просто когда адресов с blockType=ip было всего ничего, в голову не приходило ,что размер таблички в 256к окажется когда-либо мал. Тоже самое было в голове когда увеличивал её ещё в 2 раза. Ну уж полляма то точно хватит на всех. Хрен там. Теперь точно видно, если ничего не изменится - через 2 месяца будем в районе 2млн. Особо меня беспокоит то, что при парсинге dump.xml будет внезапная проблема, уже сейчас при его распаковке в массив, ОЗУ занимается на более чем гиг, да и процы жрёт прилично, усмирил через nice. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
swsn Опубликовано 18 сентября, 2019 · Жалоба 13 минут назад, disappointed сказал: Особо меня беспокоит то, что при парсинге dump.xml будет внезапная проблема, уже сейчас при его распаковке в массив, ОЗУ занимается на более чем гиг, да и процы жрёт прилично, усмирил через nice. Главное предусмотреть чтобы об этой проблеме сервер сообщил) Мы когда-то на штраф залетели, как раз из-за того что забили на контроль выгрузок) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
swsn Опубликовано 18 сентября, 2019 · Жалоба @max1976 Цитата p 18 22:10:34 localhost extFilter[118477]: i40e_dev_interrupt_handler(): ICR0: adminq event Sep 18 22:59:30 localhost extFilter[118477]: i40e_dev_interrupt_handler(): ICR0: adminq event Sep 18 22:08:31 localhost extFilter[118477]: i40e_dev_interrupt_handler(): ICR0: adminq event Sep 18 22:57:27 localhost extFilter[118477]: i40e_dev_interrupt_handler(): ICR0: adminq event Как я наблюдаю в момент появления этого сообщения, у пользователя несколько секунд не работает интернет. Происходит раз в 50 минут, это опять же бага сетевой? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
max1976 Опубликовано 19 сентября, 2019 · Жалоба 6 часов назад, swsn сказал: Происходит раз в 50 минут, это опять же бага сетевой? Возможно драйвер не подходит. Поставьте версию драйвера, которая протестирована с используемой версией dpdk. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
swsn Опубликовано 19 сентября, 2019 · Жалоба 2 часа назад, max1976 сказал: Возможно драйвер не подходит. Поставьте версию драйвера, которая протестирована с используемой версией dpdk. Протестированные это которые идут в архиве dpdk-17.05.1? в моем случае i40e(/usr/src/dpdk-stable-17.05.1/drivers/net/i40e) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
max1976 Опубликовано 19 сентября, 2019 · Жалоба 52 минуты назад, swsn сказал: Протестированные это которые идут в архиве dpdk-17.05.1? Конечно нет. Смотрите здесь http://doc.dpdk.org/guides-17.05/rel_notes/release_17_05.html#tested-platforms Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
swsn Опубликовано 20 сентября, 2019 · Жалоба В 19.09.2019 в 10:49, max1976 сказал: Конечно нет. Смотрите здесь http://doc.dpdk.org/guides-17.05/rel_notes/release_17_05.html#tested-platforms После экспериментов с откатом драйверов и прошивок решил зайти на нексус посмотреть логи Цитата 2019 Sep 19 07:06:47.382 nexus3064x %LLDP-5-SERVER_ADDED: Server with Chassis ID 00e0.ed5c.c7fe Port ID 00e0.ed5c.c7fe management address NIL discovered on local port Eth1/9 in vlan 0 with enabled capability None 2019 Sep 19 07:09:49.796 nexus3064x %LLDP-1-NO_DCBX_ACKS_RECV_FOR_LAST_10_PDUs: No Acks have been received on Interface Eth1/9 for last 10 DCBX PDUs 2019 Sep 19 07:14:48.837 nexus3064x %LLDP-1-NO_DCBX_ACKS_RECV_FOR_LAST_10_PDUs: No Acks have been received on Interface Eth1/9 for last 20 DCBX PDUs 2019 Sep 19 07:19:47.879 nexus3064x %LLDP-1-NO_DCBX_ACKS_RECV_FOR_LAST_10_PDUs: No Acks have been received on Interface Eth1/9 for last 30 DCBX PDUs 2019 Sep 19 07:24:46.921 nexus3064x %LLDP-1-NO_DCBX_ACKS_RECV_FOR_LAST_10_PDUs: No Acks have been received on Interface Eth1/9 for last 40 DCBX PDUs 2019 Sep 19 07:29:45.964 nexus3064x %LLDP-1-NO_DCBX_ACKS_RECV_FOR_LAST_10_PDUs: No Acks have been received on Interface Eth1/9 for last 50 DCBX PDUs 2019 Sep 19 07:34:45.004 nexus3064x %LLDP-1-NO_DCBX_ACKS_RECV_FOR_LAST_10_PDUs: No Acks have been received on Interface Eth1/9 for last 60 DCBX PDUs 2019 Sep 19 07:39:44.045 nexus3064x %LLDP-1-NO_DCBX_ACKS_RECV_FOR_LAST_10_PDUs: No Acks have been received on Interface Eth1/9 for last 70 DCBX PDUs 2019 Sep 19 07:44:43.087 nexus3064x %LLDP-1-NO_DCBX_ACKS_RECV_FOR_LAST_10_PDUs: No Acks have been received on Interface Eth1/9 for last 80 DCBX PDUs 2019 Sep 19 07:49:42.128 nexus3064x %LLDP-1-NO_DCBX_ACKS_RECV_FOR_LAST_10_PDUs: No Acks have been received on Interface Eth1/9 for last 90 DCBX PDUs 2019 Sep 19 07:54:41.170 nexus3064x %LLDP-1-NO_DCBX_ACKS_RECV_FOR_LAST_10_PDUs: No Acks have been received on Interface Eth1/9 for last 100 DCBX PDUs 2019 Sep 19 07:55:11.077 nexus3064x %ETHPORT-5-IF_DOWN_NONE: Interface Ethernet1/9 is down (None) 2019 Sep 19 07:55:11.207 nexus3064x last message repeated 1 time 2019 Sep 19 07:55:11.207 nexus3064x %LLDP-5-SERVER_REMOVED: Server with Chassis ID 00e0.ed5c.c7fe Port ID 00e0.ed5c.c7fe on local port Eth1/9 has been removed 2019 Sep 19 07:55:11.327 nexus3064x %ETHPORT-5-IF_DOWN_ERROR_DISABLED: Interface Ethernet1/9 is down (Error disabled. Reason:DCX-No ACK in 100 PDUs) 2019 Sep 19 07:55:41.071 nexus3064x %ETHPORT-5-IF_ERRDIS_RECOVERY: Interface Ethernet1/9 is being recovered from error disabled state (Last Reason:DCX-No ACK in 100 PDUs) Видимо что-то не то со встроенным lldp , при поднятии линка отправляет пакет и потом молчит. Отключили на стороне оборудования, будем наблюдать) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
marsellus Опубликовано 25 сентября, 2019 · Жалоба Добрый день! Странная ситуация: extfilter в режиме зеркала, http ресурс блокируется (curl -v http://.... получает Moved Temporarily на залушку) и в то же время ревизор фиксирует отсутствие блокировки. Машинка, с которой провожу тесты подключена к той же железке где расположен ревизор и куда подключен extfilter. tshark показывает, что Moved Temporarily приходит раньше ответа от реального сервера. В чем может быть проблема? По отчетам ревизора получаем около 8 тысяч пропусков :(. extfilter.ini lower_host = true domainlist = /usr/local/etc/extfilter/domains urllist = /usr/local/etc/extfilter/urls ssllist = /usr/local/etc/extfilter/ssl_host hostlist = /usr/local/etc/extfilter/hosts sslips = /usr/local/etc/extfilter/ssl_ips http_redirect = true redirect_url = http://blocked.example.com rst_to_server = true statistic_interval = 30 block_ssl_no_sni = true core_mask = 7 statisticsfile = /var/run/extFilter_stat cli_port = 9999 cli_address = 127.0.0.1 operation_mode = mirror [port 0] queues = 0,1 [port 1] queues = 0,2 type = sender mac = 00:25:45:00:0f:00 [dpi] [logging] loggers.root.level = information loggers.root.channel = fileChannel channels.fileChannel.class = FileChannel channels.fileChannel.path = /var/log/extFilter.log channels.fileChannel.rotation = 1 M channels.fileChannel.purgeCount = 4 channels.fileChannel.archive = timestamp channels.fileChannel.formatter.class = PatternFormatter channels.fileChannel.formatter.pattern = %Y-%m-%d %H:%M:%S.%i [%P] %p %s - %t channels.fileChannel.formatter.times = local Спасибо за помощь Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Troj Опубликовано 25 сентября, 2019 · Жалоба 39 минут назад, marsellus сказал: Добрый день! Странная ситуация: extfilter в режиме зеркала, http ресурс блокируется (curl -v http://.... получает Moved Temporarily на залушку) и в то же время ревизор фиксирует отсутствие блокировки. Машинка, с которой провожу тесты подключена к той же железке где расположен ревизор и куда подключен extfilter. tshark показывает, что Moved Temporarily приходит раньше ответа от реального сервера. В чем может быть проблема? По отчетам ревизора получаем около 8 тысяч пропусков :(. Спасибо за помощь похожая ситуация, названивают из радиочастотного центра и говорят про пропуски, присылают отчет, по ссылкам прилетает заглушка, хттпс болкирую через bgp в блэкхол, но и по ним тоже, что удивительно есть пропуски, я пока забил на это потому как по факту блокировка работает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
st_re Опубликовано 25 сентября, 2019 · Жалоба tcpdump с ревизора снимайте и смотрите. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
max1976 Опубликовано 25 сентября, 2019 · Жалоба 2 часа назад, marsellus сказал: В чем может быть проблема? По отчетам ревизора получаем около 8 тысяч пропусков :(. Если ревизор за NAT, то надо присвоить ревизору реальный ip. Ну а для 100% результата только в разрыв, т.к. иногда в сети случаются задержки пакетов, поэтому возможно получение ответа от сервера быстрее, чем ответ от фильтра. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
marsellus Опубликовано 25 сентября, 2019 · Жалоба 22 minutes ago, max1976 said: Если ревизор за NAT, то надо присвоить ревизору реальный ip. Ну а для 100% результата только в разрыв, т.к. иногда в сети случаются задержки пакетов, поэтому возможно получение ответа от сервера быстрее, чем ответ от фильтра. Все на реальных IP. И ревизор и фильтр в одной железке. Может не хватает производительности сервера. Трафика очень мало. На входящем интерфейсе фильтра от 50-150 Mbps. Выделил по одному ядру на каждый порт фильтра. Надо попробовать помониторить tcpdump-ом. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ixi Опубликовано 25 сентября, 2019 · Жалоба 3 часа назад, Troj сказал: хттпс болкирую через bgp в блэкхол Не DPI? это давно уже не работает, в списках хватает адресов, постоянно меняющих IP 2 часа назад, max1976 сказал: возможно получение ответа от сервера быстрее, чем ответ от фильтра. Некоторые ресурсы из списка отправляют ответ ещё до получения запроса, так что и в разрыв не всегда поможет Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...