1. Для блокировка используем

[swsn]

Интересует еще как распределять для бриджа ядра по портам subscriber/network. Равное количество? или основная нагрузка уходит на один из портов?

[max1976]

1 час назад, swsn сказал:

Интересует еще как распределять для бриджа ядра по портам subscriber/network. Равное количество? или основная нагрузка уходит на один из портов?

Нагрузка должна распространяться по всем процессам согласно rss.

[swsn]

3 часа назад, max1976 сказал:

Нагрузка должна распространяться по всем процессам согласно rss.

Странно что статистика только по одному воркеру, я выделил 5 ядер e3 1280 v2 . Не может же 400к в сек. пакетов  одна очередь и одно ядро обработать с missed 0)) сетевая x710 четырех головая. 

[max1976]

1 час назад, swsn сказал:

Не может же 400к в сек. пакетов  одна очередь и одно ядро обработать с missed 0))

Может и больше. 

[swsn]

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;

Статистика по остальным воркерам появилась.

Сам я на плюсах не пишу, и соответственно у меня вопрос: Такой костыль  допустим вообще?))

[Morphus]

Кому интересно, сделал контейнер для конвертации эцп с гостом в 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

[max1976]

1 час назад, swsn сказал:

Сам я на плюсах не пишу, и соответственно у меня вопрос: Такой костыль  допустим вообще?))

Если в вашем случае это решает проблему, то вполне приемлемый вариант.

Изменено 18 сентября, 2019 пользователем max1976

[disappointed]

Рост кол-ва айпишников стал строго предсказуемым. 13800 адресов в сутки.

[Antares]

3 минуты назад, disappointed сказал:

Рост кол-ва айпишников стал строго предсказуемым. 13800 адресов в сутки.

Не радует :(

[disappointed]

А чего стоит 35 тысяч адресов ipv6 внутри одного /64 префикса.

На минуточку - этот минимум на клиента, в 6-ке, но только в нём >18 квинтиллионов адресов.

 

[alibek]

Ну так, работу работают.

Адреса добавляются, видимость бурной деятельность формируется, зарплата капает.

[arhead]

Когда звонил РЧЦ говорили мне что у многих операторов когда Blackhole превысил 512 тыс маршрутов начали блокировки не работать. Что сделали не знаю. Чувствую что скоро опять гугл и т.д. поломают

Изменено 18 сентября, 2019 пользователем arhead

[disappointed]

7 минут назад, arhead сказал:

Когда звонил РЧЦ говорили мне что у многих операторов когда Blackhole превысил 512 тыс маршрутов начали блокировки не работать. Что сделали не знаю. Чувствую что скоро опять гугл и т.д. поломают

 

Да я тоже попал тогда, и ещё ранее, когда пересекали 256 тысяч.

Потому обвешал всё триггерами теперь, и на стороне где генерится, и на сторонах где исполняется.

 

Просто когда адресов с blockType=ip было всего ничего,

в голову не приходило ,что размер таблички в 256к окажется когда-либо мал.

Тоже самое было в голове когда увеличивал её ещё в 2 раза. Ну уж полляма то точно хватит на всех. Хрен там.

 

Теперь точно видно, если ничего не изменится - через 2 месяца будем в районе 2млн.

 

Особо меня беспокоит то, что при парсинге dump.xml будет внезапная проблема, уже сейчас при его распаковке в массив,

ОЗУ занимается на более чем гиг, да и процы жрёт прилично, усмирил через nice.

[swsn]

13 минут назад, disappointed сказал:

Особо меня беспокоит то, что при парсинге dump.xml будет внезапная проблема, уже сейчас при его распаковке в массив,

ОЗУ занимается на более чем гиг, да и процы жрёт прилично, усмирил через nice.

Главное предусмотреть чтобы об этой проблеме сервер  сообщил)

Мы когда-то на штраф залетели, как раз из-за того что забили на контроль выгрузок)

[swsn]

@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 минут,  это опять же бага сетевой?

[max1976]

6 часов назад, swsn сказал:

Происходит раз в 50 минут,  это опять же бага сетевой?

Возможно драйвер не подходит. Поставьте версию драйвера, которая протестирована с используемой версией dpdk. 

[swsn]

2 часа назад, max1976 сказал:

Возможно драйвер не подходит. Поставьте версию драйвера, которая протестирована с используемой версией dpdk. 

Протестированные это которые идут в архиве  dpdk-17.05.1? в моем случае i40e(/usr/src/dpdk-stable-17.05.1/drivers/net/i40e)

 

[max1976]

52 минуты назад, swsn сказал:

Протестированные это которые идут в архиве  dpdk-17.05.1?

Конечно нет. Смотрите здесь http://doc.dpdk.org/guides-17.05/rel_notes/release_17_05.html#tested-platforms

[swsn]

В 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 , при поднятии линка отправляет пакет и потом молчит. Отключили на стороне оборудования, будем наблюдать)

[marsellus]

Добрый день!

 

Странная ситуация: 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

 

Спасибо за помощь

[Troj]

39 минут назад, marsellus сказал:

Добрый день!

 

Странная ситуация: extfilter в режиме зеркала, http ресурс блокируется (curl -v http://.... получает Moved Temporarily на залушку) и в то же время ревизор фиксирует отсутствие блокировки. Машинка, с которой провожу тесты подключена к той же железке где расположен ревизор и куда подключен extfilter. tshark показывает, что Moved Temporarily приходит раньше ответа от реального сервера. В чем может быть проблема? По отчетам ревизора получаем около 8 тысяч пропусков :(.

 

 

 

Спасибо за помощь

похожая ситуация, названивают из радиочастотного центра и говорят про пропуски, присылают отчет, по ссылкам прилетает заглушка, хттпс болкирую через bgp в блэкхол, но и по ним тоже, что удивительно есть пропуски, я пока забил на это потому как по факту блокировка работает.

[st_re]

tcpdump с ревизора снимайте и смотрите.

[max1976]

2 часа назад, marsellus сказал:

В чем может быть проблема? По отчетам ревизора получаем около 8 тысяч пропусков :(. 

Если ревизор за NAT, то надо присвоить ревизору реальный ip. Ну а для 100% результата только в разрыв, т.к. иногда в сети случаются задержки пакетов, поэтому возможно получение ответа от сервера быстрее, чем ответ от фильтра.

[marsellus]

22 minutes ago, max1976 said:

Если ревизор за NAT, то надо присвоить ревизору реальный ip. Ну а для 100% результата только в разрыв, т.к. иногда в сети случаются задержки пакетов, поэтому возможно получение ответа от сервера быстрее, чем ответ от фильтра.

Все на реальных IP. И ревизор и фильтр в одной железке. Может не хватает производительности сервера. Трафика очень мало. На входящем  интерфейсе фильтра от 50-150 Mbps. Выделил по одному ядру на каждый порт фильтра.

Надо попробовать помониторить tcpdump-ом.

[ixi]

3 часа назад, Troj сказал:

хттпс болкирую через bgp в блэкхол

Не DPI? это давно уже не работает, в списках хватает адресов, постоянно меняющих IP

 

 

2 часа назад, max1976 сказал:

возможно получение ответа от сервера быстрее, чем ответ от фильтра.

Некоторые ресурсы из списка отправляют ответ ещё до получения запроса, так что и в разрыв не всегда поможет