[Verizon FiOS & Juniper ScreenOS] Lost Network and DHCP Renewal

Today I noticed the notification on my firewall (Juniper SSG5), running ScreenOS
6.3.0r3.0:

2010-09-03 08:28:16 notification Fcb pool size is 4096.

What is the FCB? Juniper’s Knowledge Base states in short:

The Fragment Control Block (FCB) is a data structure used by ScreenOS to reassemble and forward fragments. Each FCB is 100 bytes in length. Before using the fragments, the system will get a FCB from the FCB pool. When the FCB is returned back to the pool and it cannot reassemble the fragments into a normal packet within the FCB period (3 seconds) the fragment is aged out and packets are dropped.

Also, according to this Knowledge States:

Starting w/ ScreenOS 6.2.0 administrators are allowed to change the FCB pool size as much as five (5) times the default. The larger the FCB pool size the greater the throughput when the system must handle a large number of fragments. The new command is:

set envar fcb_pool_multiple=

For my firewall, I set the var above to “5”, the max. Because the FCB may be changed up to five times the default. On the box, prior to issuing the above command, I had:

> get session frag
Fcb expired time is 3 second
Defrag info in host system:
Max 4096 fcbs in the system, 0 fcbs are in use.
Max 1032 fragments can be queued, 0 fragments are queued now.
Total 0 fragments received.
Total 0 fragments passed defrag.
Total 0 fragments failed in defrag.
Total 0 fragments overlap happen.
Total 0 are 1st fragments.
Total 0 are non-1st fragments.
Total 0 are out-of-order fragments.
Total 0 fragments are aged out.
Total 0 fragments come from inconsistent interfaces.

Note: The change of the fcb_pool size does not take effect until the firewall is restarted. This is required because the FCB is preallocated in memory during bootup of the device.

> save
> reset
System reset, are you sure? y/[n] y
In reset …

And, afterward we have:

> get session frag
Fcb expired time is 3 second
Defrag info in host system:
Max 20480 fcbs in the system, 0 fcbs are in use.
Max 1032 fragments can be queued, 0 fragments are queued now.
Total 0 fragments received.
Total 0 fragments passed defrag.
Total 0 fragments failed in defrag.
Total 0 fragments overlap happen.
Total 0 are 1st fragments.
Total 0 are non-1st fragments.
Total 0 are out-of-order fragments.
Total 0 fragments are aged out.
Total 0 fragments come from inconsistent interfaces.

I think the system may have used a bit more memory, but it is a lot less than half:

Juniper Notes:

Should I ever get the error ‘fragments fcb addr error’ is increasing, then that would mean the pool of FCB’s is being depleted and more packet fragments are coming in, than there are available FCB’s to handle them.

This issue can be solved by determining the source of the fragmented packets. Fragmentation can be prevented by making sure that hosts do not send packets larger than the smallest MTU (Maximum Transfer Unit) along the path travelled by the packet.

Advertisements
This entry was posted in Security. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s