PCM+ V2.0 Questions/Thoughts

[Steve Britt · Accepted solution]

Terry,

There isn't a nicely formatted report or table that indicates the segments that Traffic Monitor is *trying* to monitor. The best representation at the moment is really the Traffic Devices tab that is displayed (in the right pane) when you have clicked on the "Interconnect Devices" node in PCM's tree (on the left). This shows a list of devices and, when each device is expanded, the ports on the devices that data collection has been requested for. It also shows the last time (if any) that data was obtained from each port. Do you find this insufficient, and if so what would be a better way to convey the information?

So do I understand that you're not getting traffic from your one single port that you tried to collect from as a test? Or did it just take an inordinately long time? As far as the size of your network, BTW, it doesn't sound like Traffic Monitor should have an issue in terms of scalability if we can get this more fundamental issue that's blocking you resolved.

Which brings me to this ... I conclude from what you've said that you have the Traffic Wizard (automatic traffic configuration) enabled. Its job is essentially to identify the interswitch links in your topology and set up monitoring on those. Unfortunately we have seen some issues with this wizard as it can continually keep tweaking the set of ports that the data collector is to monitor, causing the data collector to restart quite often, consequently disrupting the continuity of data collection and causing high CPU consumption of trafficd and mySQL (as you report). I suspect that this may be the root of your problem, and I suggest that you disable the Traffic Wizard by disabling automatic traffic configuration. You can always re-enable it for a short period after a topology change if you wish, then disable it again.

You can confirm that the collector, trafficd, is being restarted too often to get any traction by looking at a log file it keeps as it runs. The file is in the server\logs subdirectory of your PCM server installation directory and is called "Traffic.log"; new data is appended at the end of it. When the "Traffic.log" file reaches its size limit it is renamed to "Traffic.old" and a new file started. Note that this log file is normally not something that a user will (or should need to) examine, but it should help us determine what's happening in your case. Each time trafficd is restarted it logs information to this file about the number of segments (segment = device port) it's been asked to monitor with sampling, the number it was asked to poll statistics from, and then it logs information about it's contact with each port from that point forward. So when you first open the file and scroll to the end you should see some messages that indicate that trafficd is periodically trying to contact your device ports that it can't reach, and hopefully some information about the problem that is preventing it from doing so. If possible, could you check the log file, starting from the end, to find the last time the data collector restarted? You should see a message of the form "Traffic data collector 2.0 started" for each restart, followed by messages about how many sampling segments and polled segments there are and then finally followed by the "steady state" messages regarding the state of data acquisition on each requested segment.

If the Traffic Wizard is causing your woes then you should see frequent restarts (each log entry is timestamped). This can be remedied as I suggest above by disabling automatic traffic configuration - note that you can retain the configuration the wizard has already set up for you even after you disable it. If this doesn't solve your problem, I have talked to Hector Manzo and at this point it would probably be best to open a support call with ProCurve so we can get into gorier details without making everyone else read my inordinately long messages ...

Regards,

SVB

[Steve Britt]

Drew and Les,

Thanks for the information on the third-party devices that are green for a while and then go inexplicably red. We will be checking into it ...

Regards,

SVB

[Terry Kirk]

Steve;

Sorry for the delay, couple of other projects got in the way.

The Traffic Devices tab was what I was looking for. I don't usually click on Interconnect Devices so I missed it.

The problem is that, when a change is made, it takes about 27 minutes for the Traffic Monitor to show anything.

I tried disabling the Automatic Traffic Configuration and that seems to have gotten rid of the intermittant stops in reporting. These would occur when the traffic configuration was changed or when PCM got started again and also would happen periodically through the day. The long pause at the beginning is still there though. When this pause is occurring, I don't see any messages in the log file.

Disabling the Automatic Traffic Configuration seems to have fixed the most annoying part of the problem; one of the pauses in collection always seemed to happen just when I was trying to monitor something.

While poking around, I noticed two other problems:
1) In the remote client, when creating a policy, you can't select the groups it is to apply to - the window is too small (only a couple of pixels high). This is not a problem when running the client directly on the PCM server.
2) In the Misconfiguration report (from the Network Consistancy module), everything is reported by IP address. DNS names would be much nicer :{)

Thanks for your help!

[Ted Nguyen]

Drew and Les,

Thanks for the information on the third-party devices that are green for a while and then go inexplicably red. We will be checking into it ...

These third-party devices might only support SNMPv1. Could you confirm this? Could you delete these devices from PCM and use Manual Device Discovery Wizard to discover these devices to see if this makes a diffence?

[Drew_38]

Ted;

I'm just trying deleting a device and re-discovering it for you. I'll report back.

Are you saying though that devices which don't have SNMP v2 support can't be discovered and their status got by PCM+ v2? I ask as PCM+ v1.6 discovered and got the status for these devices no problem at all.

Drew

[Drew_38]

For Ted and others; just commenting on my own message here.

As I mentioned I deleted the 3Com switch which was stuck on red (unavailable) from PCM+ v2. I was having some trouble re-adding it and I ended up having to deal with another problem and leaving this.

In the meantime PCM+ v2 re-discovered the device itself and since it did it's been ok, that is green not red. So maybe I guess that some non-HP items which were discovered by PCM+ v1.6 don't get properly transferred over to v2. Just a guess. Anyhow I'll keep monitoring the situation and report if it changes.

Drew

[Ted Nguyen]

Drew,

Thanks a lot for your feedback. As you suspected, any devices with only SNMPv1 supported which were discovered with PCM 1.6 will have this "red" status indication issue when upgraded to PCM 2.0. This is because of the changes made to PCM 2.0 to support SNMPv3. In PCM 2.0, each device discovered is flagged to indicate which SNMP version is used to communicate with the device. The devices in PCM 1.6 do not have this version associated. The upgrade process from 1.6 to 2.0 defaulted the devices to SNMPv2, thus causing the issue you indicated.

So, the work-around is to delete any devices with "red" status indication and either manually discover them or wait for Discovery to rediscover the devices.

Hope this helps.
Regards,
Ted

[Drew_38]

Ted;

Thanks for confirmation of this. Well then it's not too much of a problem for me as I only had two devices in this state.

Regards,

Drew

[Les Ligetfalvy]

Likewise for me, the few old Nortel 350 switches I have will be going away soon. I simply added them to the list of excluded devices along with the other SNMP devices that PCM 2.0 does not play nice with.