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

Здравствуйте! Как то неожиданно абоненты начали жаловаться на отсутствие скорости, раньше было пару звонков, за сегодня прям ощутимо. Находятся за натом, и исчерпали ограничение 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?

Поделиться сообщением


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

так легко проверить, если после 5 минут lifetime_flow_long количество этих клиентов не падает то скорее всего вирусня. В принципе их динамику понаблюдать. тв смарт берет 10 соединений в обычном случае. ну да же 20 возьмет, больше ему не во, что тратить.

Поделиться сообщением


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

И еще заметили такой прикол, есть абон с белым адресом, в его сети присутствует видеорегистратор, допустим у него тариф 10мбит, но при включении регистратора, он генерирует трафик на максимуме интерфейса коммутатора доступа, причем dlf/broadcast/multicast фильтры не обнаруживают ни чего подозрительного, трафик доходит до Ската, им обрабатывается (что фиксируется счетчиком трафика на профиле абонента PPPoE) Получается, что некоторый тип трафика обходит шейпер ската?

Поделиться сообщением


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

У нас чего-то быстро, в своё время, стали жаловаться на такое и я увеличил до sess_tcp=8000

 

Ещё у СКАТ'а есть проблема плохого освобождения трансляций:

Есть завирусованный абонент с забитым sess_tcp , ему меняешь серый ip и на следующий день смотришь, а на старом ip всё ещё висят трансляции на СКАТе.

 

Мне в ТП сказали, что "в будущих версиях быстрее будут освобождать".

 

Из базовой рекомендации: если ниже NATа есть BRAS, то на нём зафильтровать серые ip которые не входят в операторский пул, т.е. если ip выдаются из пула 100.64.0.0/10, то  чтобы 192.168.0.0/16 и т.п. не доходили до СКАТа и не натились. Потому что вирусы сканируют серые сети и соотв. забивают sess_tcp, ну это видно, если netflow поглядеть со СКАТа.

Поделиться сообщением


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

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. Проблем, пока, нет.

Поделиться сообщением


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

 У нас bras/nat все в одном, навешиваем профиль 11, если нат. пул у нас с маской /27, по расходованию портов на один IP есть пару, которые заняты на 70%

Поделиться сообщением


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

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.

Поделиться сообщением


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

Поставили 4000, Теперь по статистике это значение превысили только 10 юзеров, и странно, они вообще не звонили  превышая 2000, может и вправду не замечали)

Поделиться сообщением


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

9 часов назад, bkdipnet сказал:

Поставили 4000, Теперь по статистике это значение превысили только 10 юзеров, и странно, они вообще не звонили  превышая 2000, может и вправду не замечали)

ИМХО, много лет жили на Ericsson SE 100 с его Натом и проблем не знали с ограничением в 2к сессий, сейчас эта планка поднялась до 2-3 к сессий в виду огромно кол-ва "домашних девайсов".

 

Нормальный абонент не упираясь в ограничения кол-ва сессий не имеет проблем, а у "загаженных", при достаточном пуле, хватает lifetime_flow_long, что бы "добрые" tcp сессии жили и появлялись новые.

 

П.С. Разговор, во основном, про tcp, а какие у Вас ограничения на udp? У нас 8к tcp/udp - например "Ютубчег" бегает по quic, а это udp.

Поделиться сообщением


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

@bike Аналогично с SE100 вообще таких проблем не знали. По udp сделали такое же: 4000 но по статистике и 2000 не переходили вроде, поставлю на мониторинг, посмотрим. Просто Скат у нас уже около 1.5 лет вроде, и за это время не было жалоб с этой стороны, а тут как лавина, при чем были дома у жалующихся пользователей, там комп иногда включают, а в основном два телефона, но наблюдали у ип с большим парком оборудования, как его зараженные компы сканят 0.0.0.0/0 то есть вообще весь диапазон существующих адресов, сканит все "интересные порты" там половина таких компов, блокируешь один начинает другой, сделали правило, чтоб автоматом блокировало и забыли. Видимо у всех проблемных клиентов такая же бяка, и активировалась удаленно или по таймеру.

Поделиться сообщением


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

Да, пользователям что то объяснять трудно, сегодня отключился один из тех, у кого 4000 tcp было. И все же, может есть какой то механизм сброса трансляций на проблемных адресах? Раз сессия долго не сбрасывается автоматически, может находить таких и очищать вручную/скриптом. Просто проверили на одном: разрываешь соединение, как только он подключается, получаем опять те же цифры по сессиям, это про 

В 01.09.2021 в 22:12, Urs_ak сказал:

Мне в ТП сказали, что "в будущих версиях быстрее будут освобождать".

Пока увеличили до 6000, но это не решение проблемы, как нам кажется...

Поделиться сообщением


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

23 минуты назад, bkdipnet сказал:

И все же, может есть какой то механизм сброса трансляций на проблемных адресах

Я спрашивал в ТП, сказали нету - "либо рестарт сервиса, либо подождать пока эти сессии займут другие абоненты"

Вообще сами спросите в их ТП :), потому что они при апгрейде СКАТа обязывают выкупать ТП за прошлые годы, даже если не пользовался. Вот пусть поработают.

У нас при 8k tcp/udp, условно - один звонок в месяц с этой проблемой.

Поделиться сообщением


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

Ух ты, неужели кроме нас еще кто-то жалуется, багу уже много лет, часть тсп-сессий не таймаутится.

 

Моя чистилка:

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 услугу выключать-включать по идее.

Поделиться сообщением


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

@Valaskor Спасибо, потестим.

 

Позор ТП VasExperts

Поделиться сообщением


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

Похоже в 11 версии с натом стало получше.

Поделиться сообщением


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

В 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


 

Поделиться сообщением


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

В 01.09.2021 в 19:20, bkdipnet сказал:

Вот такая динамика

изображение_2021-09-01_192028.png

 

Это 5 минут

изображение_2021-09-01_192228.png

Подскажите, пожалуйста, как вы организовали графический мониторинг сессий.

Поделиться сообщением


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

В 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

Поделиться сообщением


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

В 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

Благодарю великодушно! Отлично работает.

Поделиться сообщением


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

"Изменения в версии 11.2 BETA1

  1. Существенно переработана поддержка CGNAT: клиенты на одном белом адресе будут активнее переиспользовать сессии друг друга."
Кто то уже тестировал?

Поделиться сообщением


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

Коллеги, мне это кажется, или в версии 12.4 опять как то стали подзалипать сессии? Никто не обращал внимания?

Поделиться сообщением


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

Я сижу на 11.4 и проблем с залипанием не испытываю (ранее это была больная тема, приходилось перезапускать службу раз в месяц)

 

Однако почитываю их телеграм-канал и у меня тоже создалось впечатления что начиная с какой-то 12.х опять там проблемы с NAT

 

Поэтому продолжу сидеть на 11.4

 

Поделиться сообщением


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

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.