| Solution |
Consider logging from an L2 poll of a switch in output.master as an example:
yams.BridgeManager INFO :: 2024-04-29 03:41:26:466 :: #93 :: ********** testsite-switch-9300 172.1.1.1 PollThread-poll2 540862 **********
readForwardingDatabase 4.795 Seconds
old client count = 28
176=1 169=1 168=1 165=1 163=1 162=1 110=1 84=1 80=1 60=3 51=1 38=1 37=1 27=1 26=1 21=1 19=1 18=1 16=2 15=1 14=1 13=2 11=1 10=1
lost client count = 0
new client count = 29
176=1 169=1 168=1 165=1 163=1 162=1 117=1 110=1 84=1 80=1 60=3 51=1 38=1 37=1 27=1 26=1 21=1 19=1 18=1 16=2 15=1 14=1 13=2 11=1 10=1
Done update Clients 1515.974 Seconds
Link Up interface count = 0
Queue Size = 285
To highlight the important parts of this logging output:
- yams.BridgeManager = The FortiNAC module responsible for logging and managing Layer 2 related activity.
- readForwardingDatabase = The time it takes in seconds to read the MAC address table of the device. This is essentially the time it takes the device to respond to FortiNAC via its L2 polling method (SNMP,CLI, API etc.) if this number is high, the polling is taking too long and the device should be investigated.
- Done update Clients = The time it takes in seconds for FortiNAC to process the results of the L2 poll and update its database.
- Queue size = The size of the remaining objects in queue waiting to be processed, ideally this number should not exceed single digits
As shown in the example above, the client update is what is taking an excessive amount of time to complete. This is something internal to FortiNAC, and must be remedied through the following methods:
- Investigation of additional debug logging to determine if there is an object in the queue taking an excessive amount of time to process:
- BridgeManager (The module responsible for polling) only has a certain number of threads available. These threads are also used to process traps, and directory lookups, For example: if the latency on directory lookups is too long or if an excessive amount of unnecessary traps are received, it can also affect L2 polling.
- Adjustment to polling queue threads to enable additional processing capacity:
- If the system has enough capacity, allocate additional polling threads to potentially increase throughput. This is covered in a separate article.
- Ensuring FortiNAC system resources are sufficient (Memory, Disk Read/Write speed, Disk Space, CPU).
In the event that the readForwardingDatabase times are too long or this is suspected to be an issue, further validate this by using the command below to measure the time it takes for an L2 poll:
time readforwardingtbl -ip x.x.x.x
If this is the case, the customer will need to investigate the cause as this indicates the device response times to the polling method are excessive.
Related articles:
Technical tip: Increase the threads (more cpu power) used for L2 polling in FortiNAC.
|
