PCM 3 demo

[Jay671]

Does the PCM 3 demo allow for traffic monitoring, or is this disabled until you purchase the PCM+ license?

Just wondering because I am not getting nay stats on traffic with PCM 3 demo.

[Steve Britt · Accepted solution]

Hi,

I assume you're referring to the PCM 3.x evaluation license. It permits the full functionality of PCM+, including traffic monitoring, to be used for the duration of the evaluation period.

Are you not getting any statistics whatsoever, or just no sampling data? If it's just sampling data then it could be a firewall issue.

Regards,

SVB

[Jay671]

Not sure by what you mean by "any" statistics. I'm not getting the top traffic on the front page, nor am I getting any sample data when I click on an individual device and click the "traffic" tab.
Everything else seems to be working. This is a brand new server, previously I had PCM 2.x running on another server for 2 years now with now firewall issues so I don't think that would change now.

[Jay671]

More info.....

Basically it just sits there saying "Awaiting Data"
I have stopped and restarted the PCM services, rebooted the server and also double checked to make sure Windows Firewall was not enabled on the server.

I still have my old server running PCM 2.x at the same time I am running the new one. Could this be causing a problem if my switches are trying to report to more than one server?

[Steve Britt]

Hi,

I spoke with the primary developer of this PCM component and here are some suggestions on what to check. You may be able to skip some steps depending on what you've observed regarding the behavior of other PCM components.

Generally speaking, to provide a little background, PCM collects traffic data via two means: sampled data and polled statistics data. If a switch port is capable of supporting sampled data collection (because it supports the sFlow or XRMON MIBs) then PCM 3.x will try to collect sampled data from it; otherwise PCM will poll certain MIB-II port counters periodically. Collecting either type of data will result in statistics being displayed to show you the traffic "envelope" (magnitude) for each metric monitored. But only sampled data will allow PCM to show you the composition of traffic inside this envelope. Collecting sampled data requires SNMP traps or UDP datagrams to be sent asynchronously from the switches, which is why firewalls can be an issue for sampled data (if the targeted ports are blocked). Statistics data, on the other hand, is initiated by the PCM server on a well-known port so firewalls shouldn't be an issue there. Hence my earlier question about whether you were seeing any polled statistics data at all.

* Make sure the devices don't restrict the management systems that can see them, or if they do they include the 3.x system in the list of authorized managers. (you probably can't even discover the device of this is an issue)

* Pick some ports on a device that you're certain is up and force them to collect statistics data using the right-click menu. This will ensure that even if all devices support sampling (and hence PCM will only try to use sampling to acquire data from them) that the simplest path to data collection is taken via port statistics polling (this request overrides PCM's default behavior of collecting only sampled data from ports that support sampling). If you still see no data after several minutes then the problem is definitely not a firewall. (you may already be able to rule this out if you're sure it's not a firewall outside the PCM server system)

* Test the security for one or more devices that should be providing data but aren't using the Test Communication Parameters function. To collect sampled traffic data PCM must have SNMP write as well as read permissions. (only read permissions are needed for polling statistics counters)

* Check the status column of the Traffic tab to see if there is any information there regarding the absence of data.

Regarding your question about whether the PCM 2.3 system running elsewhere could affect the 3.x system, the answer is (of course) maybe - but only with regard to sampled data. Depending on the device, some switches only support one target for sFlow data and if your PCM 2.3 system has already "claimed" such a device then the 3.x system will not be able to acquire data from the device.

To simplify this procedure you might want to select a single device that you temporarily "remove" from the PCM 2.3 system's ownership. Once you get traffic collection working for that device the rest should be easy to get working.

Regards,

SVB

[Jay671]

Hey Steve,

Thanks for the response and all your help. I shut down the 2.3 PCM server. Then went into the switches that I am able to change the sflow settings through the CLI(my 8200, 3500, 5400 series switches)Before changing the settings I did notice that they were all set to the old server. Once I changed the address to the new server traffic started flowing.
This was all good until I found out that the 4200 and 2600 series does not support the sflow CLI commands.
So I then did the
"setmib sFlowRcvrAddress.1 -o XXXXXXXX"
This did get the proper server address in for the new PCM 3, and with a few other commands I was able to get it enabled, and setup the polling and everything else.
now if I do a "show sflow destination" I get this in response.
sflow : Enabled
Datagrams Sent : 570
Destination Address : 10.100.1.62
Receiver Port : 6343
Owner : Administrator
Timeout (seconds) : 99999563
Max Datagram Size : 1400
Datagram Version Support : 5
all looks good.
I only setup one port which happens to be A1 on my 4200, however, the setmib command doesn't recognize A1 so I told it just "1". I am not seeing traffic for this particular switch on PCM 3 even though the above says 570 datagrams sent. so not really sure why..

From what I have read in other posts it sounds like this has to be done for each port? If that is correct I have 18 48 port switches I have to manually setup the MIB commands for and that really doesn't sound like much fun. I'm hoping there is an easier way, or maybe something else I am just missing. It does seem (since it worked on the switches I could alter the sflow on) that something is still hanging on for life to the old server address. Wondering if a reboot of the switch would knock it free now that the old server is off?

One last thing. On the 4200, if I right click a port and go to details, then log, all the switches that are not sending traffic have the repeated message of,

sflow port/device [id=2682372|index=30] unreachable
or
sflow port/device [id=2682372|index=30] time expired (attempting to manage port again)

However, on the on port I did the manual MIB setup (port A1) in the log I am now getting this,

sflow collection counts [id=2668548|ifindex=1]: interval flows [297] interval counters [0], total flows [4777] total counters [0], interval flows/sec [4.95]

With the interval flows, total flows and flows/sec numbers changing. So I must have done something wrong with the MIB command.

[Steve Britt]

Hi,

Is there a reason that you don't want PCM itself to manage the sFlow MIB settings on your switches? I guess if you have some of them working by setting the configuration through the CLI then why change them, but for the 18 others you're talking about I would suggest you clear out the sFlow configuration that was set through the CLI, make sure the PCM 3.x system is allowed as a management station, and let it manage the sFlow configuration on those switches. Not only will it do the configuration work for you but it will dynamically adjust the skip count used on each interface to ensure an adequate flow of samples from each to make accurate projections about traffic content, a benefit that you don't get when you manually configure the settings in the CLI (and set a constant skip count / packet sampling rate).

If you really want to do this through the CLI though via setmib, I would guess that maybe you have only set us the receiver table and packet sampling table in the sFlow MIB. The fact that the switch says it's sending datagrams and the fact that the PCM log reports flows makes me think that you're getting sampled packet headers, a.k.a. flows. But unless you also set the counter polling table for each interface you want data from PCM won't have an "envelope" to project traffic content within - it needs both sampled traffic flows and the counts. I haven't used the setmib approach so I can't speak from experience but I do think that you have to set the values for each interface separately. IMHO it's much easier to let PCM do the work as I mentioned above.

Regards,

SVB

[Jay671]

Hey Steve,

No, I would prefer that PCM do all the configuration for me. Problem is, it doesn't appear to be doing that right now because the other 18 switches are not reporting traffic. On the old server with PCM 2.3 it was successfully pulling traffic from all the switches without any adjustments from my end.
However, for some reason PCM 3 is not which my guess is, because the 18 other switches are still hanging onto the old PCM 2.3 server so I was wondering other than manually adjusting it in the other 18 switches, how do I get them to stop reporting to the old PCM 2.3 box and switch over to the new PCM 3. The only reason I did it manually on the 8200, 3500, and 5400 switches is because that was the only way to force it to stop using the old PCM 2.3. When I went in to those switches and did a "show sflow destination" it was reporting the old PCM server address, this told me that if these large manageable switches still thought to use the old PCM 2.3 server, chances are my minor edge switches are doing the same, only difference is, I can't easily go into the CLI and change this as far as I know.

So my question is, do I need to fire the old PCM 2.3 server back up and delete all devices and turn off discovery before it will relinquish the hold on all switches so PCM 3 can take over or is there something else I need to do individually in each switch?

Thanks again for all your help!

Jay

[Steve Britt]

Hi Jay,

The reason I went on about the CLI configuration is that when PCM automatically configures your switch for sFlow it sets a "failsafe" mechanism on the switch that only allows the switch to send sFlow datagrams to your PCM system for a bounded period of time. If the timer on this failsafe mechanism ever counts down to 0 before PCM refreshes it again then the switch should conclude that the PCM system that was managing it has somehow lost interest in it (by being powered off, connection severed, etc.) and it's supposed to revert to an "unconfigured" state for all of the MIB objects that the PCM instance was using. In other words, once that period expires, your switches should revert to a state that looks like no one had used them to collect sFlow data. In fact in your "show sflow destination" output the following line represents this configuration:

Timeout (seconds) : 99999563

PCM only sets this value to 10 minutes, or a maximum of 600 (in seconds). So anytime you see a value of more than 600 it means PCM didn't set the value.

Anyway, you can make sure that no sFlow collector is using your sFlow collection capabilities by manually using SNMP to set this timeout value to 0 for each receiver slot in the sFlow receiver table. Use your favorite MIB browser to walk the sFlow receiver table at OID 1.3.6.1.4.1.14706.1.1.4. For each receiver entry listed on a switch - and the number may vary depending on the switch model and configuration - set the timeout for the entry to 0 at OID 1.3.6.1.4.1.14706.1.1.4.1.3.# (where the # is the receiver entry instance in the MIB). This will ensure that NO ONE is still using an SNMP-configured sFlow stream from your switch. Then you can periodically walk the receiver table to see what, if any, entries show up in the next 10 minutes or so as PCM continues to cycle through the switches it couldn't get data from to see if they've become available since its last check. If you do the MIB browsing from the PCM system then you'll know that SNMP access to those devices is possible from the PCM system and that the system is permitted as an authorized manager for the switches (which you might be able to infer anyway if they've already been discovered and other PCM components can access them successfully).

If within 10-15 minutes of clearing out the sFlow MIB you still haven't seen the PCM 3.x agent system's address show up in this table then there is a configuration issue somewhere that is preventing it, either on the PCM side or the switch side. You say that you see the following Log messages for these switch ports in Traffic:

sflow port/device [id=2682372|index=30] unreachable
or
sflow port/device [id=2682372|index=30] time expired (attempting to manage port again)

These indicate that PCM is *trying* to collect sFlow data from the ports but cannot seem to set the sFlow MIB up. Hopefully resetting the MIB will fix the issue for you ...!

Regards,

SVB

[Jay671]

Thanks Steve,

I haven't had much luck with a MIB browser and still trying a few other things. Even tried resetting back to factory defaults and then reloading the config, but that hasn't helped.
Everything else appears to be working fine, all devices are discovered properly, I can right click and access them using SSH without any issues, policies are working for all switches. When right clicking and using the "test communication parameters in PCM" everything comes back as successful.
I have logged a support case with HP now to see what other options I have, but until then I have awarded you full points for all your help and insight.
Thanks, and should you come across anything else, I am open to suggestions.

Jay