Jump to content
Калькуляторы

sess_tcp=2000

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

 

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

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

 

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

 

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

Share this post


Link to post
Share on other sites
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. Проблем, пока, нет.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
9 часов назад, bkdipnet сказал:

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

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

 

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

 

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

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

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

Share this post


Link to post
Share on other sites
23 минуты назад, bkdipnet сказал:

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

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

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

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this