Can cisco PIX graph traffic over 114 MBps

[kerich]

Hi Guys,
is it possible for cisco PIX graph traffic > 114 MBps. I cant seem to capture traffic above this limit.
Pls assist.

[Exo7]

use SNMP v2 and 64 bits counters.

[kerich]

Thanks, i get an SNMP error when i use v2 in cacti.. how can i upgrade snmp in my pix? cheers

[gandalf]

That's a PIX related question. Make it answer v2c requests and cacti will be able to use it.
Reinhard

[flibbertigibbet]

so using v1 you don't see real (gigabit) traffic? when you switch to v2 you should see up to gigabit traffic?
Do I need to switch the graphs over to 64bit counters? How can I do that without losing all the graph information, or can I?

Gandolf if you can answer this asap, I'd appreciate, we're doing a network test to see real speeds. O_o

[gandalf]

so using v1 you don't see real (gigabit) traffic? when you switch to v2 you should see up to gigabit traffic?
Do I need to switch the graphs over to 64bit counters? How can I do that without losing all the graph information, or can I?

Gandolf if you can answer this asap, I'd appreciate, we're doing a network test to see real speeds. O_o

That's not exactly correct. Some words about what's happening behind the scene:
Traffic is measured as a COUNTER, each octet transmitted increases the number by one. Assuming, you fetch the counter every 300 sec, you may get up to 114 Mbps before the 32 bit counter wraps.
Now, there are two opportunities
- decrease interval: e.g. when fetching data every 60 sec, you will get up to 114*5 Mbps peak
- use 64 bit COUNTERs

Reinhard

[flibbertigibbet]

Ok, but that doesn't answer my question, the realistic, or "correct" way to do it is to use 64 bit counters.
And there is no way to convert? As I've already deleted some of my "incorrect" graphs, with collected datas.

Also I'm not seeing the 64bit counters working on SNMP enabled windows servers. Non-64bit data is polled just fine, but 64bit doesn't come through the graphs... I'm assuming it's a limitation of windows not transmitting 64bit data over snmp.

Also, shouldn't this be moved to General Help, not linux Specific?

[gandalf]

Ok, but that doesn't answer my question, the realistic, or "correct" way to do it is to use 64 bit counters.
And there is no way to convert? As I've already deleted some of my "incorrect" graphs, with collected datas.

There is no official "upgrade" from 32 to 64 bit templates, yes. I once failed miserably ...

Also I'm not seeing the 64bit counters working on SNMP enabled windows servers. Non-64bit data is polled just fine, but 64bit doesn't come through the graphs... I'm assuming it's a limitation of windows not transmitting 64bit data over snmp.

A known issue for M$'s own snmp. Using net-snmp would solve this. But that's a different thing

Also, shouldn't this be moved to General Help, not linux Specific?

Will do
Reinhard

[flibbertigibbet]

Well, no need to beat yourself up about it. I guess the database isn't storing 64bits of data unless you choose it. Could that be an update to basically force the database to record 64bit data by default, since it shouldn't affect anything, except database size? (as more and more devices are using gigabit, or better)

Ok, but that doesn't answer my question, the realistic, or "correct" way to do it is to use 64 bit counters.
And there is no way to convert? As I've already deleted some of my "incorrect" graphs, with collected datas.

There is no official "upgrade" from 32 to 64 bit templates, yes. I once failed miserably ...

Also I'm not seeing the 64bit counters working on SNMP enabled windows servers. Non-64bit data is polled just fine, but 64bit doesn't come through the graphs... I'm assuming it's a limitation of windows not transmitting 64bit data over snmp.

A known issue for M$'s own snmp. Using net-snmp would solve this. But that's a different thing

Also, shouldn't this be moved to General Help, not linux Specific?

Will do
Reinhard

[gandalf]

That's not the issue.
64bit templates are ready for use. Only the transformation between 32 bit data template and 64 bit data template is an issue
Reinhard

[flibbertigibbet]

Sorry, let me restate that.
More and more devices are using gigabit interfaces, why not make the default template use 64 bit counters? since non-64 bit data, wouldn't be affected if it's stored in a 64 bit counter?
Is that correct or is it that I don't know what I'm talking about?

Also, would 10xGigabit interfaces or 100xGigabit interfaces see a similar limit in 64bit counters, to where future templates will need 128bit counters?

[gandalf]

Sorry, let me restate that.
More and more devices are using gigabit interfaces, why not make the default template use 64 bit counters? since non-64 bit data, wouldn't be affected if it's stored in a 64 bit counter?
Is that correct or is it that I don't know what I'm talking about?

Also, would 10xGigabit interfaces or 100xGigabit interfaces see a similar limit in 64bit counters, to where future templates will need 128bit counters?

There is no such thing as a "default" traffic template. Simply select the one you like to use.
As many devices still do not support SNMP V2 and/or 64 bit counters it is not a good idea to make that "standard".
Reinhard

[flibbertigibbet]

Well even if the device doesn't support 64 bit counter, if you choose 64 bit counter it'll still record the non64bit, correctly, right?

So for example, if the template is recording 16bit data, my theory says that the max value of the data would be 65536, which you could not put a 32 or 64bit large number in there. ie. 65537+
But a 64 bit container could hold 16bit values, or 32 bit values without issue. So it doesn't matter if the device is outputting 64 bit or 32 or 16 bit values, the issue stems from the allocated size (in memory, or the database) is not big enough, correct?
so even if the device only outputs 16 bit it'll put it in the 64 bit container, with a bunch of leading 0's... instead of truncating large numbers to fit into smaller containers.
Which none of this has to do with any devices outputting snmp v2, or outputting 64bit values, just the fact that the template shipped with cacti (which I call the default, because it's the default one chosen) could or should, accept 64 bit values no matter what, there doesn't need to be a separate 64 bit template.

[Howie]

Well even if the device doesn't support 64 bit counter, if you choose 64 bit counter it'll still record the non64bit, correctly, right?

No, it's actually fetching a different OID - ifInOctets vi ifHCInOctets. Not all devices support ifHCInOctets, which is in a different table (ifXTable) to the standard counters (ifTable).

You also need SNMPv2c to get support for the Counter64 type, which is what ifHCInOctets uses.

The "64 bits" is the value returned by the SNMP agent, not just the value stored, so if the agent doesn't return a value for that OID, you get no data, not just limited data.