As part of port maintenance, I like to do a statsclear each day so I can trend ports starting to go bad. One thing I noticed from a switch perspective is that whenever I do a statsclear, I see a large spike in TX/RX Mb/s. Can anyone tell me what is actually happening that creates this traffic?
where do you see that spike? with portperfshow? I reckon that that spike you mention is just the effect of clearing the stats and calculating the throughput with just-cleared stats.
hi, I see the activity thru network advisor when I'm looking at historical graphs for top FC port activity. The part I find odd is the apparent FC traffic that is generated. I would not think clearing the stats on the switch would per se generate traffic in/out of the switch. I would see that as more of an internal switch activity.
I'm not sure how BNA does this, but what you describe is similar in behaviour when polling stats thru SNMP for brocade and SNMP enabled devices in general. I use Cacti to poll for SNMP data in my case.
Depending on your setup, and my does it by looking at the uptime, the software that polls can reconize when a couter rolls over.
Ie going from 9999 (for instance) to 0000.
There are two instances (during normal operations) were a counter resets itself.
1-the counter just incemrent with one setting itself back to 0000.
2-reboot setting every thing to 0
In the event of 1 the software can still produce a delta to calculate wheter it is measuring (throughput for instance).
in the event of 2 something additional must take place (actually this happens al the time, but is not yet triggered)
When a counter start over from 0000 again, software must also determine what actually happend.
Usually (or at least Cacti) software uses the uptime counter to keep track of what is happening.
In cacti this detection is named "uptime travels backwards".
Now with a statsclear command you reset all counter ON FC ports to 0, but uptime remains the same.
Now from the SNMP polling point of view something else happens.
Uptime is still moving forward, but the Data the software gets seems to have gone through 0000 forwards.
In such case the counter is interpretted as not been reset and the delta is calculated on the known previous value (let say 1256)
and the new measured value of 0560.
As uptime moves forward the actual delta would be 9999-1256+0560=9303.
Depedning on the counter in question and the polling interval this value could lead to measurement that are physically impossible, like seeing a throughput of 47Gb/s on a 4Gb/s interface.
now if BNA works on the same or similar principals as described above the spikes are completely valid from BNA point of view.
Very interesting! Thank-you for your input. In this case, its not so much as counter being physically impossible, 50MB/s spike on a 4Gb port, but just odd that there is a TX/RX spike of virtually the same amount. Since the statsclear is clearing the port counter statistics, I know the port counter metrics involve frames transmitted/received, but not TX MBs/RX MBs which is where I see the spikes.
It would depend on how those MB's are calculated by BNA, I guess