Switches, Hubs, and Modems
cancel
Showing results for 
Search instead for 
Did you mean: 

2824 Traffic monitor discrepancy

SOLVED
Go to solution
J Vesterdahl
Regular Advisor

2824 Traffic monitor discrepancy

I have two MPEG2 video coders attached to a 2824 switch at 100Mb/s.
PCM+ 2.1 suddenly started reported 45-50% utilization on the video coder ports. The video coders are transmitting at around 4-5 Mb/s. The web interface on the switch says 5-7% utilization, which is more reasonable, looks like it always has and is on par with other video coders on the network.
I've tried both sampling and stats, but the result is the same. PCM+ 2.1 without update and with update 6 does not make any difference either.
I'm not sure exactly when this started, but definitely after I upgraded the switch firmware to I.08.98. I have been working with the traffic monitor also (adding/deleting devices, restarting, experimenting with auto/manual configuration). Could this be the cause?
Any ideas ?
There is always one more bug ...
6 REPLIES
Jonathan Axford
Trusted Contributor
Solution

Re: 2824 Traffic monitor discrepancy

Hi,

Have you tried deleting the traffic devices that are acting strange in PCM and re-creating them to see if this makes any difference? I have had trouble in the past where updates have caused the monitor to act erratically. Deleting them and starting again sometimes helps.

I am currently having trouble with a device reporting 500% utilization!

Cheers
Where there is a will there is a way...
J Vesterdahl
Regular Advisor

Re: 2824 Traffic monitor discrepancy

Yes, I have. More than once, but to no avail.
There is always one more bug ...
Mohieddin Kharnoub
Honored Contributor

Re: 2824 Traffic monitor discrepancy

Hi

Have you checked the configuration of the Port on the PCM, i think its on 10Mb/s , so utilizing 50% means 5 Mb which is right.

Also you have no problem in the web interface.
Science for Everyone
J Vesterdahl
Regular Advisor

Re: 2824 Traffic monitor discrepancy

If PCM+ thinks the port is 10Mb/s, then it would make sense, yes. I know the port is opereating at 100 Mb, and there's nothing in the configuration file that says anything else. Maybe the traffic monitor gets its info elsewhere. How can I check that?
There is always one more bug ...
Steve Britt
Respected Contributor

Re: 2824 Traffic monitor discrepancy

Hi J,

I infer that you're running PCM 2.1 with autoupdate 6, correct? Thus far we don't know of any accuracy issues with the port counters in that release, but I'll suggest a couple of things that may help isolate this problem one way or another if you want to do a little digging.

But first a little background on how PCM determines your port utilization. Utilization is essentially computed by taking the octet count reported during a minute and adding some overhead bytes, based on the number of frames, to account for framing bytes interpacket gap. The resulting octet count is divided by the collection period to compute a per-second rate. That rate is then divided by the aggregated ifSpeed of the link; note that since PCM 2.1 doesn't break out ingress and egress counts for full duplex links the ifSpeed is doubled to account for the fact that, for example, a 10Mbps full-duplex port is really providing 20Mbps of usable bandwidth.

So here's my first question for you: is utilization the only metric reported that looks suspect on these ports? Do the frame, broadcast, and multicast rates reported all look reasonable to you? If so it may mean that for whatever reason, PCM is not correctly picking up the ifSpeed of those ports and hence the octet count is being divided by an incorrect bandwidth, so that the correct octet rate actually produces an incorrect utilization result. Usually deleting a device with this problem from PCM and rediscovering it (not JUST rediscovering it) will flush the bad ifSpeed from the PCM database and replace it with the correct ifSpeed. If you have tried this, as you say, then the problem may not be transient as we usually see when someone changes the port speed after PCM has discovered a port and PCM just doesn't update it. As an aside, this problem is going to be fixed in the next PCM release - it will automatically pick up port speed and duplex changes.

So here's the next question, assuming a delete and rediscover doesn't fix the problem. In PCM traffic monitoring both sFlow (sampling) and statistics polling utilize counters from the ifMIB to determine the volume of the various measurements. So if you have a MIB browser you could do a sanity check by polling the counters on one of the suspect ports, taking a snapshot, and then polling the counters again a minute later. See if the octet counts appear to be in the 4-5% utilization range or roughly 10x that. Your numbers won't be exact unless you adjust for framing bytes but should be close enough to tell you whether PCM or the web agent values are right.

There have been some issues with web agent counters in the past; I have particularly seen this on full-duplex links where the traffic flow is heavily slanted in one direction. I don't know what the status is on a fix for these issues, and althought it's unlikely that the web agent is incorrect I wouldn't regard it as above suspicion until you verify with a MIB browser. I can't seem to find any devices here running I.08.98 but I'll see if I can dig one up and do a quick sanity check on the traffic data.

Regards,

SVB
J Vesterdahl
Regular Advisor

Re: 2824 Traffic monitor discrepancy

Ah, Jonathan did say delete and discover, but I had simply rediscovered a number of times without any change in behaviour. So my reply to him was incorrect. I apologize.
Now - having deleted the device and discovered it again, it looks like things are back to normal. The whole network is humming along at 3-5%.
Great ... thanks, all.
There is always one more bug ...