Screen OS

Hi all,

I checked our Juniper SSG140 event log has below message:

Session utilization has dropped below 43257, which is 90% of the system capacity!
crit Session utilization has reached 43257, which is 90% of the system capacity!

Can someone tell me how to fix this issue ?

Thanks

Hi,

This is not an issue as it is, but it is an alarm generated to notify the device admin, that the session utilisation on the device is high.

Every device has a specific session handling capability. For example:

FW1-> get session info
alloc 5/max 64064, alloc failed 0, mcast alloc 0, di alloc failed 0

This device can handle 64064 sessions. By default, the firewall will generate an alarm when the session utilisation crosses 90% of the limit. This is as per the default alarm settings:

FW1-> get alarm threshold
Alarm threshold:
Memory : off 95%
CPU : off 90%
Session : 90%
Audit Storage: off 0%

Another alarm will be generated when the session utilisation drops below the 90% mark. You can modify this threshold using the command --> set alarm threshold session <percentage>

From a solution side, you should first identify what kind of traffic is filling up the session table. Once you identify that, you can figure out if it is legitimate traffic or not. If it is not legitimate, you can either fix the source machine and stop the traffic flood or create a deny policy on the firewall.

If this kind of traffic volume is expected, then the best option is to upgrade the hardware to a better device, a 350M or a 550M.

Hi,

OK, so our firewall session at 90%, will it clear old session? but the session chart is very slow in main page.

Thanks

Hi,

No, the firewall will not clear old sessions by itself. Every session has an ageout value. If the session is inactive, it will get removed after the ageout. But, if there is traffic flowing through the session, it will stay in the session table.

If you check 'get session info' when you see receive the alarm, you will know the exact number of session established. You can also dump the complete session table using the command 'get session'. You can then use the session analyser tool (https://tools.juniper.net/fsa/) to obtain extensive reports to identify what kind of traffic is filling up your session table.

This could be an indication that you are close to the limits that the SSG140 can support.

Since the response is slow in the web ui during the time frame I would look at these statistics on the cli when the message occurs.

get perf cpu

get perf session

And perhaps monitor these during your peak times of day.  If they show consistently high values you may need to consider upgrades.  Or look at the traffic at that time to make sure there is nothing going on that should be delayed to other times of day, like large file transfers and backups.

Hello,

We have monitor server in our office subnet uing SNMP that monitoring other server in different subnets via interfaces, so the firewall event log captured this server SNMP session log, please see below event log, I just show some log only, the monitor server IP is 172.17.128.52, will it caused session problem ? thanks.

 2014-02-20 08:31:13 crit Src IP session limit! From 172.17.128.52 to 172.16.11.1, proto 1 (zone trust_office, int ethernet0/2). Occurred 1 times.
2014-02-20 08:31:13 crit Src IP session limit! From 172.17.128.52:39630 to 8.8.8.8:53, proto UDP (zone trust_office, int ethernet0/2). Occurred 1 times.
2014-02-20 08:31:11 crit Src IP session limit! From 172.17.128.52 to 172.16.11.1, proto 1 (zone trust_office, int ethernet0/2). Occurred 1 times.
2014-02-20 08:31:10 crit Src IP session limit! From 172.17.128.52 to 172.16.11.1, proto 1 (zone trust_office, int ethernet0/2). Occurred 1 times.
2014-02-20 08:31:09 crit Src IP session limit! From 172.17.128.52:46028 to 8.8.8.8:53, proto UDP (zone trust_office, int ethernet0/2). Occurred 2 times.
2014-02-20 08:31:08 crit Src IP session limit! From 172.17.128.52 to 172.16.11.2, proto 1 (zone trust_office, int ethernet0/2). Occurred 1 times.
2014-02-20 08:31:08 crit Src IP session limit! From 172.17.128.52:41484 to 8.8.8.8:53, proto UDP (zone trust_office, int ethernet0/2). Occurred 1 times.
2014-02-20 08:31:07 crit Src IP session limit! From 172.17.128.52 to 172.16.11.2, proto 1 (zone trust_office, int ethernet0/2). Occurred 1 times.
2014-02-20 08:31:05 crit Src IP session limit! From 172.17.128.52 to 172.16.11.3, proto 1 (zone trust_office, int ethernet0/2). Occurred 1 times.
2014-02-20 08:31:04 crit Src IP session limit! From 172.17.128.52 to 172.16.11.3, proto 1 (zone trust_office, int ethernet0/2). Occurred 1 times.
2014-02-20 08:31:04 crit Src IP session limit! From 172.17.128.52:56240 to 8.8.8.8:53, proto UDP (zone trust_office, int ethernet0/2). Occurred 3 times.
2014-02-20 08:31:03 crit Src IP session limit! From 172.17.128.52:41484 to 8.8.8.8:53, proto UDP (zone trust_office, int ethernet0/2). Occurred 3 times.
2014-02-20 08:31:02 crit Src IP session limit! From 172.17.128.52:41447 to 172.16.12.3:161, proto UDP (zone trust_office, int ethernet0/2). Occurred 2 times.
2014-02-20 08:31:01 crit Src IP session limit! From 172.17.128.52:41447 to 172.16.12.3:161, proto UDP (zone trust_office, int ethernet0/2). Occurred 2 times.
2014-02-20 08:31:00 crit Src IP session limit! From 172.17.128.52:41447 to 172.16.12.3:161, proto UDP (zone trust_office, int ethernet0/2). Occurred 2 times.
2014-02-20 08:30:59 crit Src IP session limit! From 172.17.128.52:56240 to 8.8.8.8:53, proto UDP (zone trust_office, int ethernet0/2). Occurred 3 times.
2014-02-20 08:30:58 crit Src IP session limit! From 172.17.128.52:60667 to 172.16.12.3:161, proto UDP (zone trust_office, int ethernet0/2). Occurred 2 times.
2014-02-20 08:30:57 crit Src IP session limit! From 172.17.128.52:60667 to 172.16.12.3:161, proto UDP (zone trust_office, int ethernet0/2). Occurred 2 times.
2014-02-20 08:30:56 crit Src IP session limit! From 172.17.128.52:60667 to 172.16.12.3:161, proto UDP (zone trust_office, int ethernet0/2). Occurred 2 times.
2014-02-20 08:30:55 crit Src IP session limit! From 172.17.128.52:60667 to 172.16.12.3:161, proto UDP (zone trust_office, int ethernet0/2). Occurred 2 times.
2014-02-20 08:30:54 crit Src IP session limit! From 172.17.128.52:60667 to 172.16.12.3:161, proto UDP (zone trust_office, int ethernet0/2). Occurred 2 times.
2014-02-20 08:30:53 crit Src IP session limit! From 172.17.128.52:39753 to 172.16.12.3:161, proto UDP (zone trust_office, int ethernet0/2). Occurred 2 times.
2014-02-20 08:30:52 crit Src IP session limit! From 172.17.128.52:42806 to 8.8.8.8:53, proto UDP (zone trust_office, int ethernet0/2). Occurred 3 times.
2014-02-20 08:30:51 crit Src IP session limit! From 172.17.128.52:45430 to 8.8.8.8:53, proto UDP (zone trust_office, int ethernet0/2). Occurred 4 times.
2014-02-20 08:30:50 crit Src IP session limit! From 172.17.128.52:39753 to 172.16.12.3:161, proto UDP (zone trust_office, int ethernet0/2). Occurred 2 times.
2014-02-20 08:30:49 crit Src IP session limit! From 172.17.128.52:39753 to 172.16.12.3:161, proto UDP (zone trust_office, int ethernet0/2). Occurred 2 times.
2014-02-20 08:30:48 crit Src IP session limit! From 172.17.128.52:39753 to 172.16.12.3:161, proto UDP (zone trust_office, int ethernet0/2). Occurred 2 times.
2014-02-20 08:30:47 crit Src IP session limit! From 172.17.128.52:42806 to 8.8.8.8:53, proto UDP (zone trust_office, int ethernet0/2). Occurred 3 times.
2014-02-20 08:30:46 crit Src IP session limit! From 172.17.128.52:45430 to 8.8.8.8:53, proto UDP (zone trust_office, int ethernet0/2). Occurred 4 times.
2014-02-20 08:30:45 crit Src IP session limit! From 172.17.128.52:40293 to 172.16.12.3:161, proto UDP (zone trust_office, int ethernet0/2). Occurred 2 times.
2014-02-20 08:30:44 crit Src IP session limit! From 172.17.128.52:40293 to 172.16.12.3:161, proto UDP (zone trust_office, int ethernet0/2). Occurred 2 times.
2014-02-20 08:30:43 crit Src IP session limit! From 172.17.128.52:40293 to 172.16.12.3:161, proto UDP (zone trust_office, int ethernet0/2). Occurred 2 times.
2014-02-20 08:30:42 crit Src IP session limit! From 172.17.128.52:37320 to 172.16.12.3:161, proto UDP (zone trust_office, int ethernet0/2). Occurred 2 times.
2014-02-20 08:30:41 crit Src IP session limit! From 172.17.128.52:37320 to 172.16.12.3:161, proto UDP (zone trust_office, int ethernet0/2). Occurred 2 times.
2014-02-20 08:30:40 crit Src IP session limit! From 172.17.128.52:36438 to 172.16.12.3:161, proto UDP (zone trust_office, int ethernet0/2). Occurred 2 times.
2014-02-20 08:30:39 crit Src IP session limit! From 172.17.128.52:36438 to 172.16.12.3:161, proto UDP (zone trust_office, int ethernet0/2). Occurred 2 times.
2014-02-20 08:30:38 crit Src IP session limit! From 172.17.128.52:52077 to 172.16.12.3:161, proto UDP (zone trust_office, int ethernet0/2). Occurred 2 times.
2014-02-20 08:30:37 crit Src IP session limit! From 172.17.128.52:52077 to 172.16.12.3:161, proto UDP (zone trust_office, int ethernet0/2). Occurred 2 times.
2014-02-20 08:30:36 crit Src IP session limit! From 172.17.128.52:52077 to 172.16.12.3:161, proto UDP (zone trust_office, int ethernet0/2). Occurred 3 times.

This may be part of the issue, but it depends on what you have the source ip session limit set to.  the value is configurable per screen on the zone and the default is 128.  At that level these alarms may not amount to more that 1,000 of your 43,000 sessions.

But if the limit was configured higher it could be significant.

You can check this in the Security menu under screens.  Choose the zone trust_office in the pull down.

You can also look at the snmp server and see how aggressive the collection schedule is and if you want to back off on the  collection interval.

Please help, some internal server can't connect, please see attached file, only set this on trust_office

I disabled all monitor device the monitor server, because all server cant connect each other via Juniper interface.

The session chart still in yellow, how long will it remove ?

Thanks !

UDP sessions time out in two minutes.

You should probably pull your active sessions during the issue and run the file through session analyzer.

https://tools.juniper.net/fsa/

This will help you determine if the traffic is legitimate or not.

Hello,

We have found out internal has virus that caused firewall session limited, so I think the Cacti session not the main problem.

Thanks