sFlow on ProCurve switches is disabled after a while

[jamesps]

I enable sFlow using the sflowenable script from Inmon, everything works great and after a while the sFlow is disabled without any intervention.
Is there an explanation for that? How can I make sure sFlow will stay enabled indefinite?
sFlow doesnt seem to be very documented (?). This is a ProCurve 2800 series switch. I am not using ProCurve Manager.

Any input would be greately appreciated. As always points will be promptly assigned.

james

[Mohieddin Kharnoub]

Hi

There were some issues about sFlow in older firmwares, if you can do the following:

- Update to latest firmware: I.08.98
- Enable passwords for both levels manager and operator.
- Change the SNMP default Comminuty access to restricted.

After you do this, enable Syslog server on the switch, and turn on debug to monitor your switch, then run the Inmon, and see whats going on.

Good Luck !!!

[jamesps]

Update: this appears to be normal, the agent needs to be refreshed once in a while. The timeout parameter can be set in the switch like this:

setmib sFlowRcvrOwner.1 -D owner sFlowRcvrTimeout.1 -i 100000

where the last number contains the timeout in seconds. You can see what timeout is left by running this:

show sflow destination

Why isn't sFlow and RMON usage better documented by HP? Maximum points for answering this one :)

Thanks,
james

[André Beck]

James,

> Why isn't sFlow and RMON usage better
> documented by HP?

Because they sell you a piece of software that is supposed to do the magic. The industry has realized that it is way cheaper to dump you a piece of software that uses undocumented interfaces than it would be to actually

* implement a defined protocol
* free the implementation of errors
* supply a detailed documentation of it
* stay with open standards there and thus
* open the interface to 3rd party software

I call this the "Printer Driver Tragedy" which hit us in the early 90s. Remember when a printer actually came with a handbook containing complete protocol documentation instead of a Windows only driver disk?

At least it's not that bad here, as RMON and in a way sFlow too are open standards one can read about elsewhere. What ought to be documented properly are implementation specifics (including those the developers would call errors should they apply to other vendors gear).

> Maximum points for answering this one :)

Well, ranting about how much better everything was yesterday probably isn't the answer you hoped for. So no need for points, they are overrated anyway.

Andre.

[Joel G]

Here's another bump - if HP could find a way to include some features in later firmware releases:

Non-expiring sFlow configuration
sFlow configurable through CLI (a la Extreme)
Clear documentation of how to configure sFlow through SNMP (for users and third party developers).

I'm sure PCM is a great product, but keeping everything a secret or making users reverse engineer products does not help anyone but HP.

[Matt Hobbs]

Isn't the maximum value for the sFlow timeout 2147483647 seconds? = 68.0511039 years. Not sure if this holds through reboots?

"sFlow configurable through CLI (a la Extreme)"

It is configurable through CLI on the newer products, 5400/3500. Would be nice to have it on the older products but I doubt that will happen at this strage.

"Clear documentation of how to configure sFlow through SNMP (for users and third party developers)."

This is a tough one, if HP made their own documentation on how to do this for something which is an open standard, then why stop at sFlow, why not include everything that can be configured via SNMP? Answer: the manual would be thousands of pages long, which costs time and money which would be added on to your purchase price. Do other hardware vendors give clear documentation on this? (I honestly don't know but I'd be surprised if they did).

"I'm sure PCM is a great product, but keeping everything a secret or making users reverse engineer products does not help anyone but HP."

People who can understand the RFC's and make something of it are the people that deserve to profit from it (In my opinion). The RFC's give you the framework, you then have to decide how you're going to program whatever it is that you need. It's the source-code that these clever people make that's a secret and I'm not going to get into the open-source debate.