Troubleshooting Traffic Load Graphs
This page provides suggestions to explain unexpected traffic load.
When in the Details page viewing the Traffic Load (%) charts, if no chart points are seen then the likely causes of this are:
- You are viewing an old time period when there was no traffic.
Action: Click on View by "Today" to ensure the charts are current.
- The percentage scaling of the chart might mean average traffic is less than 1%.
Action: Check if the Mean Traffic values for OUT and IN charts are non-zero, in which case check if the service tier speed recorded in the title bar is correct.
- The interface chosen to be monitored by Highlight does not carry traffic or is no longer valid.
Action: Check the interface being monitored by clicking on the Technical option. The monitored interface is shown near the bottom.
- The router IOS has a bug.
Action: Check the Line Health chart. If the availability line in the Line Health displays continuous green, refer to the Troubleshooting Line Health page.
- (For classes of service) the class is not defined to carry traffic.
Action: Compare the device configuration policies with the customer QoS agreement.
- The tier speed (for dedicated access) or in/out speeds (for ADSL) is set to greater than 160M but the router does not support "High Capacity Counters" which are used by Highlight when the potential throughput exceeds 160M.
Action: Check if the speed set in Highlight is correct and reduce if appropriate.
- The device being monitored is not that expected for this location, potentially because the wrong IP was used during the setup.
Action: check the hostname being monitored is correct by clicking the Technical option. The hostname as reported by the device is shown on the top line.
- The circuit is a backup and traffic is not expected under normal conditions
Action: none required
When in the Details page viewing the Traffic Load (%) charts, if traffic is recorded in only one direction then the likely causes of this are:
- (For classes of service) there is a missing or misconfigured router policy.
Action: Check the device configuration policies to confirm they are present and conform to the naming convention agreed between the service provider and ourselves. If further detail is required please contact us.
- This device is part of a resilient service and the partner device is carrying load in the other direction.
Action: Check the partner device if monitored in Highlight, and also check the routing plan to determine if this symptom is as intended.
When in the Details page viewing the Traffic Load charts, if traffic is bursting towards 300% and there are gaps in the traffic then it is likely that the watch bandwidths are set too low.
Highlight limits the burst traffic levels to 3 times the bandwidth specified (DSL) or 3 times the bearer bandwidth (non-DSL). This is to eliminate any spurious impossibly high levels of traffic reported by some devices which occur very rarely but which skew both charts and statistics. Any traffic levels beyond these parameters are reported as zero so unexpected gaps indicate traffic levels in excess of 3 times bandwidth.
It is therefore important that bandwidth speeds are accurately entered into Highlight to avoid unintended gaps in traffic charts.
Peak load statistics
It is possible that the reported Peak Traffic differs betweeen the Percentage chart and the bps chart.
This will occur if the bandwidth changes during the day. The cause is the way Highlight selects the peak:
- For percentage charts the samples are sorted into percent order and the peak traffic displayed corresponds to the highest percent value
- For bps charts the samples are sorted into bps order and the peak traffic displayed corresponds to the highest value
If the bandwidth in Highlight is increased but the traffic levels are fairly consistent then the peak percent before the change is going to be higher than after, even if the actual peak traffic load is after the change. The true peak bps is on the bps chart.
In this example the bandwidth in Highlight was changed from 20M to 25M at noon, and the reported peak bps figures differ:
|Peak time||Load bps||Load percent|
|(before noon) 10:42||15Mbps||75% of 20M|
|(after noon) 14:15||16Mbps||64% of 25M|
For low levels of traffic the percentage chart may display low or zero levels but the bps Actual chart may be fully visible.
This is caused by a minimum vertical access value of 10% for the percentage chart, so very low traffic as a percentage may not show. However the bps chart scales the traffic to the maximum value in the time period, so will always show a chart.
Currently Juniper switch ports discovered using Multilink autodiscovery will be the .0 virtual interfaces rather than their parent physical interfaces. Traffic levels reported on these sub-interfaces may be significantly lower in total that the original virtual channel selected for monitoring.
The workaround for Juniper switches is to set up Link Health monitoring on the individual physical interfaces rather than rely on the autodiscovered ports.
A short spike or gap in traffic load can be caused by interface counters being cleared on the monitored device by a local engineer.
Because average speed in each poll sample is calculated from the difference in the total bytes between this poll and the previous, if the counters are cleared then a spurious negative difference is calculated. This is either ignored and recorded as zero by Highlight (if a 64bit counter), or interpretted as a counter wrapping back to zero. If the latter highlight calculates throughput as 2^32 + current value - last value, and typically produces a massive average speed for one sample only.
There is no indication to Highlight that counters have been cleared.
When Highlight is showing traffic loads at 100% to 300% of the currently configured bandwidth, or the Actual/bps chart shows values higher than the circuit can hold, the likely cause is the bandwidth configured on the watch is significantly lower than the actual circuit. We recommend reviewing the bandwidth setting and updating it accordingly.