- CheckMates
- :
- Products
- :
- Quantum
- :
- Management
- :
- Re: What exactly does "Instance is currently fully...
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
What exactly does "Instance is currently fully utilized" mean?
Hello mates,
in a zdebug the output was "dropped by fwmultik_enqueue_packet_kernel Reason: Instance is currently fully utilized;"
The question now is "What exactly does it mean?"
Is the Firewall fully utilized or the destination behind the FW?
May the Server can not process more traffic and sends to the FW to drop the packets or is it too much for the Gateway and drops it itself?
Thanks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It can be a number of things as a search of Secure Knowledge will reveal: CoreXL input queue, sizing, Jumbo frames, bug etc
Suggest discussing your specific situation with TAC.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
All traffic coming up from the NIC hardware must pass through SND/SecureXL first. In R80.20+ if that packet is part of an existing connection that is already accelerated by SecureXL, the packet is inspected by SecureXL with no direct assistance from a Firewall Worker.
However in R80.20+ any packets that are not part of an existing accelerated connection or are starting a new connection, must be forwarded to a Firewall Worker instance. There is an input queue on each Firewall Worker to receive packets sent up by the SND. If the SND cores and Multi-Queue are well-tuned and the Firewall Worker instance is extremely busy, in some cases the queue can overflow and packets can be lost, particularly if there is a heavy stream of very small packets.
The first course of action is to undertake firewall optimization to ensure that the firewall worker(s) are not so busy in the first place. While the input queue size can be increased (just as the network ring buffer size can be increased), in general I am not a fan of increasing buffers/queues from their default value unless absolutely necessary as it can actually make things worse due to the extra overhead to manage the increased buffer size, and possibly increasing jitter.
This topic was covered in the third edition of my book, but also see this: sk61143: Traffic is dropped by CoreXL with "fwmultik_inbound_packet_from_dispatcher Reason: Instance....
March 27th with sessions for both the EMEA and Americas time zones
