PumpIT Posted September 1, 2021 Posted September 1, 2021 Здравствуйте! Как то неожиданно абоненты начали жаловаться на отсутствие скорости, раньше было пару звонков, за сегодня прям ощутимо. Находятся за натом, и исчерпали ограничение sess_tcp=2000, есть те, кто держит полку в 2000, вот они и жалуются. Общее количество не большое, но вопрос, почему это стало неожиданно массово [root@skat14 ~]# fdpi_ctrl list all status --service 11 | grep -c sess_tcp=2000 15 [root@skat14 ~]# Держится в районе 20. Из предположений: вирусня на компьютере/или другом устройстве, все кто жаловался пользуются Smart-TV. Вопрос, какая рекомендация по sess_tcp=, увеличивать как то не хочется, может сессии быстрее рубить lifetime_flow_long=300? Вставить ник Quote
zavndw Posted September 1, 2021 Posted September 1, 2021 так легко проверить, если после 5 минут lifetime_flow_long количество этих клиентов не падает то скорее всего вирусня. В принципе их динамику понаблюдать. тв смарт берет 10 соединений в обычном случае. ну да же 20 возьмет, больше ему не во, что тратить. Вставить ник Quote
PumpIT Posted September 1, 2021 Author Posted September 1, 2021 Вот такая динамика Это 5 минут Вставить ник Quote
PumpIT Posted September 1, 2021 Author Posted September 1, 2021 И еще заметили такой прикол, есть абон с белым адресом, в его сети присутствует видеорегистратор, допустим у него тариф 10мбит, но при включении регистратора, он генерирует трафик на максимуме интерфейса коммутатора доступа, причем dlf/broadcast/multicast фильтры не обнаруживают ни чего подозрительного, трафик доходит до Ската, им обрабатывается (что фиксируется счетчиком трафика на профиле абонента PPPoE) Получается, что некоторый тип трафика обходит шейпер ската? Вставить ник Quote
Urs_ak Posted September 1, 2021 Posted September 1, 2021 У нас чего-то быстро, в своё время, стали жаловаться на такое и я увеличил до sess_tcp=8000 Ещё у СКАТ'а есть проблема плохого освобождения трансляций: Есть завирусованный абонент с забитым sess_tcp , ему меняешь серый ip и на следующий день смотришь, а на старом ip всё ещё висят трансляции на СКАТе. Мне в ТП сказали, что "в будущих версиях быстрее будут освобождать". Из базовой рекомендации: если ниже NATа есть BRAS, то на нём зафильтровать серые ip которые не входят в операторский пул, т.е. если ip выдаются из пула 100.64.0.0/10, то чтобы 192.168.0.0/16 и т.п. не доходили до СКАТа и не натились. Потому что вирусы сканируют серые сети и соотв. забивают sess_tcp, ну это видно, если netflow поглядеть со СКАТа. Вставить ник Quote
PumpIT Posted September 1, 2021 Author Posted September 1, 2021 Так вот куда утекло 27г оперативки.. Вставить ник Quote
bike Posted September 1, 2021 Posted September 1, 2021 1 час назад, Urs_ak сказал: стали жаловаться на такое и я увеличил до sess_tcp=8000 Сделали так сразу, но у нас пул 512 белых на менее 3к серых, т.е. адресов с запасом. В среднем загруженность портов Ната "около нуля". Был момент озадачился статистикой по сессиям - обычные пользователи редко выедают более 2 - 3к tcp/udp сессий. Посмотрел на наличие превышений 8к сессий - не более 1-3 абонентов за месяц и то далеко не каждый, т.е. на уровне погрешности. Пробовал посмотреть статистику по таким абонентам, с виду ни чего не обычного. Звонил - у нас нет претензий, всё работает хорошо. Что само по себе странно. 1 час назад, Urs_ak сказал: Из базовой рекомендации: если ниже NATа есть BRAS, то на нём зафильтровать серые ip которые не входят в операторский пул, т.е. если ip выдаются из пула 100.64.0.0/10, то чтобы 192.168.0.0/16 и т.п. не доходили до СКАТа и не натились. Потому что вирусы сканируют серые сети и соотв. забивают sess_tcp, ну это видно, если netflow поглядеть со СКАТа. А как вы навешиваете Нат на пользователей? Не сталкивались с подобным. У нас L2 DHCP Radius Proxy, при авторизации выдаём серый адрес из пула 100.64.0.0/10 и навешиваем нужный профиль Ната. П.С. Вредные советы - lifetime_flow_long=1800. Проблем, пока, нет. Вставить ник Quote
PumpIT Posted September 2, 2021 Author Posted September 2, 2021 У нас bras/nat все в одном, навешиваем профиль 11, если нат. пул у нас с маской /27, по расходованию портов на один IP есть пару, которые заняты на 70% Вставить ник Quote
Urs_ak Posted September 2, 2021 Posted September 2, 2021 9 часов назад, bike сказал: Пробовал посмотреть статистику по таким абонентам, с виду ни чего не обычного. Звонил - у нас нет претензий, всё работает хорошо. Что само по себе странно. У большинства вирусы. Вот например: Скрытый текст ... 16:09:29.984 0.004 100.100.49.65 24314 192.168.71.110 445 1 94 188000 16:07:12.705 0.001 100.100.49.65 17379 192.168.44.164 445 1 94 752000 16:09:03.025 0.004 100.100.49.65 22963 192.168.66.49 445 1 94 188000 16:07:06.024 0.003 100.100.49.65 17077 192.168.43.134 445 1 94 250666 16:07:56.974 0.006 100.100.49.65 19650 192.168.53.79 445 1 94 125333 16:09:33.044 0.005 100.100.49.65 24486 192.168.72.27 445 1 94 150400 16:08:20.975 0.002 100.100.49.65 20847 192.168.57.248 445 1 94 376000 16:09:27.124 0.001 100.100.49.65 24227 192.168.71.24 445 1 94 752000 16:08:06.175 0.007 100.100.49.65 20192 192.168.55.108 445 1 94 107428 16:07:47.874 0.005 100.100.49.65 19145 192.168.51.90 445 1 94 150400 16:07:20.875 0.002 100.100.49.65 17764 192.168.46.12 445 1 94 376000 16:07:26.985 0.007 100.100.49.65 18132 192.168.47.115 445 1 94 107428 16:07:51.014 0.008 100.100.49.65 19376 192.168.52.66 445 1 94 94000 16:07:32.974 0.003 100.100.49.65 18422 192.168.48.150 445 1 94 250666 16:08:02.974 0.002 100.100.49.65 19940 192.168.54.113 445 1 94 376000 16:09:36.104 0.008 100.100.49.65 24656 192.168.72.195 445 1 94 94000 16:08:42.134 0.005 100.100.49.65 21991 192.168.62.111 445 1 94 150400 16:08:42.074 0.004 100.100.49.65 21960 192.168.62.82 445 1 94 188000 16:08:39.024 0.004 100.100.49.65 21757 192.168.61.133 445 1 94 188000 16:07:36.014 0.001 100.100.49.65 18613 192.168.49.75 445 1 94 752000 16:08:06.165 0.006 100.100.49.65 20177 192.168.55.93 445 1 94 125333 16:09:21.105 0.005 100.100.49.65 23899 192.168.69.203 445 1 94 150400 16:08:33.214 0.005 100.100.49.65 21550 192.168.60.192 445 1 94 150400 16:09:33.294 0.006 100.100.49.65 24596 192.168.72.138 445 1 94 125333 16:08:50.944 0.003 100.100.49.65 22329 192.168.63.190 445 1 94 250666 16:07:15.195 0.005 100.100.49.65 17581 192.168.45.91 445 1 94 150400 16:09:29.994 0.005 100.100.49.65 24325 192.168.71.121 445 1 94 150400 16:08:47.944 0.006 100.100.49.65 22184 192.168.63.36 445 1 94 125333 ... Или вот ещё: Скрытый текст ... 14:38:06.795 3.000 100.100.32.117 59892 172.25.12.77 8445 2 188 94 14:56:21.986 3.007 100.100.32.117 60440 172.30.12.18 8445 2 188 94 14:38:42.805 3.007 100.100.32.117 59945 172.25.242.140 8445 2 188 94 15:16:39.256 3.002 100.100.32.117 51654 172.25.242.140 8445 2 188 94 14:09:24.514 3.002 100.100.32.117 50478 172.30.122.227 8445 2 188 94 14:52:29.966 3.004 100.100.32.117 60276 172.25.242.140 8445 2 188 94 14:18:20.334 3.003 100.100.32.117 59264 172.25.12.77 8445 2 188 94 14:41:14.795 3.006 100.100.32.117 60177 172.30.174.250 8445 2 188 94 14:37:50.785 3.005 100.100.32.117 59876 172.19.245.125 8445 2 188 94 14:41:06.805 3.003 100.100.32.117 60168 172.30.12.18 8445 2 188 94 14:41:25.936 3.000 100.100.32.117 60196 172.19.245.125 8445 2 188 94 14:58:01.976 3.008 100.100.32.117 60546 172.25.0.155 8445 2 188 94 14:57:37.996 2.998 100.100.32.117 60509 172.25.12.77 8445 2 188 94 15:00:39.426 3.004 100.100.32.117 60697 172.19.245.125 8445 2 188 94 14:56:05.986 3.009 100.100.32.117 60413 172.25.12.77 8445 2 188 94 15:15:15.477 3.002 100.100.32.117 51538 172.19.245.125 8445 2 188 94 14:55:57.976 3.005 100.100.32.117 60394 172.25.0.155 8445 2 188 94 15:02:25.967 3.003 100.100.32.117 50929 172.25.242.140 8445 2 188 94 14:56:20.526 3.006 100.100.32.117 60434 172.19.245.125 8445 2 188 94 14:56:25.966 3.006 100.100.32.117 60444 172.25.242.140 8445 2 188 94 15:16:23.227 3.009 100.100.32.117 51626 172.25.12.77 8445 2 188 94 14:09:31.153 3.001 100.100.32.117 50491 72.163.1.80 80 2 188 94 15:14:41.236 3.003 100.100.32.117 51484 72.163.1.80 80 2 188 94 14:59:49.966 3.006 100.100.32.117 60623 172.25.0.155 8445 2 188 94 14:40:49.075 3.001 100.100.32.117 60142 172.19.245.125 8445 2 188 94 15:15:19.227 3.003 100.100.32.117 51543 172.30.119.131 8445 2 188 94 15:15:19.227 3.001 100.100.32.117 51542 172.25.12.77 8445 2 188 94 14:41:06.805 3.005 100.100.32.117 60169 172.25.12.77 8445 2 188 94 ... Есть непонятные случаи - позвонил абонент, плохо сайты открываются, вирусов в статистике не нашёл. Абонент говорит "у меня пара макбуков и две Яндекс колонки". Из подозрительного в netflow - каждые минуту-две синхронизация времени на разные ip. Поменял ему серый ip и больше не жаловался. Видимо дело не в NTP. Вставить ник Quote
PumpIT Posted September 2, 2021 Author Posted September 2, 2021 Поставили 4000, Теперь по статистике это значение превысили только 10 юзеров, и странно, они вообще не звонили превышая 2000, может и вправду не замечали) Вставить ник Quote
bike Posted September 2, 2021 Posted September 2, 2021 9 часов назад, bkdipnet сказал: Поставили 4000, Теперь по статистике это значение превысили только 10 юзеров, и странно, они вообще не звонили превышая 2000, может и вправду не замечали) ИМХО, много лет жили на Ericsson SE 100 с его Натом и проблем не знали с ограничением в 2к сессий, сейчас эта планка поднялась до 2-3 к сессий в виду огромно кол-ва "домашних девайсов". Нормальный абонент не упираясь в ограничения кол-ва сессий не имеет проблем, а у "загаженных", при достаточном пуле, хватает lifetime_flow_long, что бы "добрые" tcp сессии жили и появлялись новые. П.С. Разговор, во основном, про tcp, а какие у Вас ограничения на udp? У нас 8к tcp/udp - например "Ютубчег" бегает по quic, а это udp. Вставить ник Quote
PumpIT Posted September 3, 2021 Author Posted September 3, 2021 @bike Аналогично с SE100 вообще таких проблем не знали. По udp сделали такое же: 4000 но по статистике и 2000 не переходили вроде, поставлю на мониторинг, посмотрим. Просто Скат у нас уже около 1.5 лет вроде, и за это время не было жалоб с этой стороны, а тут как лавина, при чем были дома у жалующихся пользователей, там комп иногда включают, а в основном два телефона, но наблюдали у ип с большим парком оборудования, как его зараженные компы сканят 0.0.0.0/0 то есть вообще весь диапазон существующих адресов, сканит все "интересные порты" там половина таких компов, блокируешь один начинает другой, сделали правило, чтоб автоматом блокировало и забыли. Видимо у всех проблемных клиентов такая же бяка, и активировалась удаленно или по таймеру. Вставить ник Quote
PumpIT Posted September 8, 2021 Author Posted September 8, 2021 Да, пользователям что то объяснять трудно, сегодня отключился один из тех, у кого 4000 tcp было. И все же, может есть какой то механизм сброса трансляций на проблемных адресах? Раз сессия долго не сбрасывается автоматически, может находить таких и очищать вручную/скриптом. Просто проверили на одном: разрываешь соединение, как только он подключается, получаем опять те же цифры по сессиям, это про В 01.09.2021 в 22:12, Urs_ak сказал: Мне в ТП сказали, что "в будущих версиях быстрее будут освобождать". Пока увеличили до 6000, но это не решение проблемы, как нам кажется... Вставить ник Quote
Urs_ak Posted September 8, 2021 Posted September 8, 2021 23 минуты назад, bkdipnet сказал: И все же, может есть какой то механизм сброса трансляций на проблемных адресах Я спрашивал в ТП, сказали нету - "либо рестарт сервиса, либо подождать пока эти сессии займут другие абоненты" Вообще сами спросите в их ТП :), потому что они при апгрейде СКАТа обязывают выкупать ТП за прошлые годы, даже если не пользовался. Вот пусть поработают. У нас при 8k tcp/udp, условно - один звонок в месяц с этой проблемой. Вставить ник Quote
Valaskor Posted October 18, 2021 Posted October 18, 2021 Ух ты, неужели кроме нас еще кто-то жалуется, багу уже много лет, часть тсп-сессий не таймаутится. Моя чистилка: cat /etc/cron.d/nat_clean PATH=/sbin:/bin:/usr/sbin:/usr/bin 1-59/5 * * * * root fdpi_ctrl list all status --service 11 --outformat json | jq -r '.lstatuses[] | select(.status_11.sess_tcp>1990) | .ipv4'| head -n50 | xargs -L1 fdpi_ctrl del --bind_multi --ip Если не используется авторизация, можно просто 11 услугу выключать-включать по идее. Вставить ник Quote
Urs_ak Posted October 18, 2021 Posted October 18, 2021 @Valaskor Спасибо, потестим. Позор ТП VasExperts Вставить ник Quote
Valaskor Posted November 22, 2021 Posted November 22, 2021 Похоже в 11 версии с натом стало получше. Вставить ник Quote
Urs_ak Posted November 23, 2021 Posted November 23, 2021 В 22.11.2021 в 12:25, Valaskor сказал: Похоже в 11 версии с натом стало получше. В changelog ничего про NAT нет Скрытый текст Цитата Изменения в версии 11.0 Foundation Добавлена поддержка сигнатур, определяемых пользователями на основе SNI, IP[:PORT] или SUBNET Добавлена запись трафика в СХД («закон Яровой») Добавлены протоколы FACETIME,NORD_VPN,EXPRESS_VPN,PRIVATETUNNEL_VPN,VPNUNLIMITED,PSIPHON3,CLUBHOUSE,TLS_UNKNOWN,QUIC_IETF,SPEEDTEST Изменено : по 12 услуге пишутся данные в pcap и после детектирования закрытия сессии [dpi engine] Add configurable IP recheck timeout [sorm engine] New config prmt for amount of meta_parser Изменено : Если задан параметр ssl_reply в версию протокола ставим значение из протокола content_type=0x16 Изменено : определение протоколов ssl_unknown и tls_unknown определяется как : sni пусто и cname пусто - сморим версию заголовка ServerHello ( из первых 5-ти байтов ). Если версия ⇐0x0300 - это ssl_unknown иначе это tls_unknown. Если задан параметр tls13_unknown - всегда смотрим ServerHello и если там версия 0x0304 это всегда протокол tls_unknown ( независимо от sni/cname) Исправлено : в файлах layout в поле flags ставится значение : 2 - если это служебная запись или не определено еще flow иначе уставнавливаем 1- dir_data Изменено : если задан параметр ssl_parse_reply происходит поиск cname Изменено : В формат ajb_save_sslreply_format добавлены 3 новые поля tphost ( тип хоста - всегда 2 ), host ( cname ), evers - версия из Extensions ( определяется только если задан параметр tls13_unknown=1 иначе 0 ). Изменено : Формат clickstream передачи ssl-reply. Добавлены поля : 1011 - type_host - число лежит в host - всегда 2 и 1005 cname Изменено : сообщения при трассировки вида DPI(DEF_PROTO,CHANGE_PROTO,STORED_PROTO) - добавлено поле cntr_fin, direction Исправлено : после закрытия соединения не помещалась запись в short очередь для tcp Добавлено : при трассировке для TCP соединений сообщения добавлено сообщение об изменении очереди (short/long) Изменено : формат вывода команды fdpi_cli dump flow cache Добавлено : параметр ajb_save_fragment - задает запись фрагментированных пакетов в pcap Изменено : разбор протокола TLS [pcrf][DHCP] Fixed: передача opt82 circuit/remote id в аккаунтинг Добавлено : для storage_agent параметр engine_bind_cores который задает привязку потоков записи к ядрам [BRAS][DHCPv6] Fixed: падение на пакете DHCP-Confirm без указания IPv6-адресов в IA_NA-опции Fixed: режим tap_mode=1 - не должно быть отправки пакетов Fixed: крах при разборе L2-заголовков для eher_type=0xFFFF [PCRF][framed-pool] Fixed: при добавлении в уже существующую опцию opt125 не учитывалось, что dhcp_poolname_opt=0 - это то же самое, что и dhcp_poolname_opt=2. Это приводило к добавлению opt125 для VasExperts при dhcp_poolname_opt=0 [BRAS][ARP] Добавлено: поддержка режима сегментирования абонентов в общем VLAN на сети доступа(изоляция абонентов на коммутаторе, т.е. абонам не доставляется трафик между друг другом даже в одном влане) Добавлен fastdpi.conf-параметр bras_arp_vlan_segmentation: Учитывается только при установленном флаге 1 в bras_arp_proxy для ARP-запросов от одного абонента другому. off (типичный случай) - абоненты A и B в одном VLAN могут взаимодействовать между собой напрямую, СКАТ не обрабатывает ARP-запрос от абонента A «who has target abonent B IP» on - на коммутаторе включена изоляция абонентов, находящихся в одном VLAN, поэтому СКАТ должен сам ответить на ARP-запрос от абонента A «who has target abonent B IP» [cfg] Fixed: не учитывалось значение параметра set_packet_priority в fastdpi.conf Изменено : статистика SDS_AGENTS_ - добавлено суммарное кол-во ошибок и процент Изменено : поддержка нескольких очередей SDS_AJB Добавлено : параметры sds_ajb_num - кол-во очередей sds_ajb ( default 1 ) sds_ajb_bind_cores - задает ядра к которым надо привязывать потоки. Если не задан - ядра назначаются автоматом. Пример sds_ajb_bind_cores=1:1:2:2 Изменения в версии 11.1 Foundation [fastpcrf] Fixed: передача opt82 в аккаунтинг при L3 auth [pcrf] Fixed: передача значения атрибута opt82 remoteId в аккаунтинг [pcrf] Added: возможность задания атрибутов для opt82.Новые параметры в fastpcrf.conf: attr_opt82_remoteid=vendorId.attrId где vendorId - id вендора. Если vendorId != 0, то значение передается в VSA-атрибуте. Если vendorId == 0, то значение передается в обычном Радиус-атрибуте (не-VSA) attrId - id атрибута, число от 1 до 255. Если эти параметры не заданы, то opt82 передается в следующих атрибутах: acct: circuitId: ADSL VSA 3561.1, remoteId: ADSL VSA 3561.2 auth: circuitId: VasExperts VSA 43823.39, remoteId: VasExperts VSA 43823.33 Пример задания: attr_opt82_remoteid=15.34 attr_opt82_circuitid=15.35 Вставить ник Quote
Stas Kazanskii Posted November 26, 2021 Posted November 26, 2021 В 01.09.2021 в 19:20, bkdipnet сказал: Вот такая динамика Это 5 минут Подскажите, пожалуйста, как вы организовали графический мониторинг сессий. Вставить ник Quote
Urs_ak Posted November 27, 2021 Posted November 27, 2021 В 26.11.2021 в 12:48, Stas Kazanskii сказал: Подскажите, пожалуйста, как вы организовали графический мониторинг сессий. На этом графике - кол-во абонентов у которых трансляций больше 2000 Запускается что-то типа fdpi_ctrl list all status --service 11 --outformat json | jq -r '.lstatuses[] | select(.status_11.sess_tcp>2000) | .ipv4'| wc -l и результат пихается в метрику Zabbix Вставить ник Quote
Stas Kazanskii Posted December 1, 2021 Posted December 1, 2021 В 27.11.2021 в 21:18, Urs_ak сказал: На этом графике - кол-во абонентов у которых трансляций больше 2000 Запускается что-то типа fdpi_ctrl list all status --service 11 --outformat json | jq -r '.lstatuses[] | select(.status_11.sess_tcp>2000) | .ipv4'| wc -l и результат пихается в метрику Zabbix Благодарю великодушно! Отлично работает. Вставить ник Quote
bike Posted January 22, 2022 Posted January 22, 2022 "Изменения в версии 11.2 BETA1 Существенно переработана поддержка CGNAT: клиенты на одном белом адресе будут активнее переиспользовать сессии друг друга." Кто то уже тестировал? Вставить ник Quote
Valaskor Posted February 19, 2024 Posted February 19, 2024 Коллеги, мне это кажется, или в версии 12.4 опять как то стали подзалипать сессии? Никто не обращал внимания? Вставить ник Quote
Urs_ak Posted February 19, 2024 Posted February 19, 2024 Я сижу на 11.4 и проблем с залипанием не испытываю (ранее это была больная тема, приходилось перезапускать службу раз в месяц) Однако почитываю их телеграм-канал и у меня тоже создалось впечатления что начиная с какой-то 12.х опять там проблемы с NAT Поэтому продолжу сидеть на 11.4 Вставить ник Quote
.png.5d2afa2996cc6a85d0f2c09b92dd0a28.png)
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.