CBQoS 'drop' vs 'policed-transmit'
Hi,
Just noticed that the CBQoS stuff has gone active recently (which is very cool) - currently we get all this via (very) painful integration with Cacti.
On looking closer I've found what I think is an issue, but stand ready to be corrected. What I think is happening is that Observium is considering packets the Cisco counted as "Exceeded" to have been "Dropped" where in reality they were just re-marked and transmitted normally.
As an example, here is the graph for gi3/1 (class-default) on a 6500 chassis:
Here is the output of the show policy-map int gi3/1:
GigabitEthernet3/1
Service-policy input: <name>
class-map: <Class A> (match-any) Match: protocol arp Match: access-group name <ACL A1> Match: access-group name <ACL A2> police : 32000 bps 102400 limit 102400 extended limit Earl in slot 3 : 1377162657 bytes 5 minute offered rate 2280 bps aggregate-forwarded 1377162657 bytes action: transmit exceeded 0 bytes action: drop <- Zero drops aggregate-forward 2520 bps exceed 0 bps
class-map: class-default (match-any) Match: any police : 40000000 bps 3200000 limit 3200000 extended limit 1000000000 pir-bps Earl in slot 3 : 10562039041987 bytes 5 minute offered rate 11748848 bps aggregate-forwarded 10562039041987 bytes action: set-dscp-transmit exceeded 297846881624 bytes action: policed-dscp-transmit violated 0 bytes action: drop <- Zero drops aggregate-forward 13842064 bps exceed 0 bps violate 0 bps
So in summary, there have never been any actual drops on the port, only re-marking of the DSCP (incrementing the exceeded counter) and then a transmit.
Since the re-marking occurs in the "exceeded" counter, I think Observium is considering them as dropped, instead of just exceeded. This also messes up the pre-policy and post-policy counters, because it implies that traffic didn't make it through when in reality it all did. We use re-marking extensively and so all of the CBQoS graphs show incorrect drop and post-policy information.
Either that or we've got a bug/misconfiguration (or I just don't get it), so maybe someone else can confirm? Let me know what debug info is needed if it helps :)
Cheers!
Robert Williams Custodian Data Centre Email: Robert@CustodianDC.com http://www.CustodianDC.com
When you are calculating on drops in 6500/7600/other fucked up qos groups with WRR/SRR-queues, the counters will not be accurate.
Take a look at TCAM drops instead.
2014-08-10 10:01 GMT+02:00 Robert Williams Robert@custodiandc.com:
Hi,
Just noticed that the CBQoS stuff has gone active recently (which is very cool) - currently we get all this via (very) painful integration with Cacti.
On looking closer I’ve found what I think is an issue, but stand ready to be corrected. What I think is happening is that Observium is considering packets the Cisco counted as “Exceeded” to have been “Dropped” where in reality they were just re-marked and transmitted normally.
As an example, here is the graph for gi3/1 (class-default) on a 6500 chassis:
Here is the output of the show policy-map int gi3/1:
GigabitEthernet3/1
Service-policy input: <name>
class-map: <Class A> (match-any) Match: protocol arp Match: access-group name <ACL A1> Match: access-group name <ACL A2> police : 32000 bps 102400 limit 102400 extended limit Earl in slot 3 : 1377162657 bytes 5 minute offered rate 2280 bps aggregate-forwarded 1377162657 bytes action: transmit exceeded 0 bytes action: drop <- Zero drops aggregate-forward 2520 bps exceed 0 bps class-map: class-default (match-any) Match: any police : 40000000 bps 3200000 limit 3200000 extended limit 1000000000pir-bps Earl in slot 3 : 10562039041987 bytes 5 minute offered rate 11748848 bps aggregate-forwarded 10562039041987 bytes action: set-dscp-transmit exceeded 297846881624 bytes action: policed-dscp-transmit violated 0 bytes action: drop <- Zero drops aggregate-forward 13842064 bps exceed 0 bps violate 0 bps
So in summary, there have never been any actual drops on the port, only re-marking of the DSCP (incrementing the exceeded counter) and then a transmit.
Since the re-marking occurs in the “exceeded” counter, I think Observium is considering them as dropped, instead of just exceeded. This also messes up the pre-policy and post-policy counters, because it implies that traffic didn’t make it through when in reality it all did. We use re-marking extensively and so all of the CBQoS graphs show incorrect drop and post-policy information.
Either that or we’ve got a bug/misconfiguration (or I just don’t get it), so maybe someone else can confirm? Let me know what debug info is needed if it helps :)
Cheers!
Robert Williams Custodian Data Centre Email: Robert@CustodianDC.com http://www.CustodianDC.com
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
Indeed. We only show the numbers that the device gives us. The MIB is fairly sparse, it gives is pre/post-policy and drops. There isn't much ambiguity. If those numbers are wrong, contact your vendor.
adam.
On 2014-08-10 21:35, Peter Persson wrote:
When you are calculating on drops in 6500/7600/other fucked up qos groups with WRR/SRR-queues, the counters will not be accurate.
Take a look at TCAM drops instead.
2014-08-10 10:01 GMT+02:00 Robert Williams Robert@custodiandc.com:
Hi, Just noticed that the CBQoS stuff has gone active recently (which is very cool) - currently we get all this via (very) painful integration with Cacti. On looking closer I’ve found what I think is an issue, but stand ready to be corrected. What I think is happening is that Observium is considering packets the Cisco counted as “Exceeded” to have been “Dropped” where in reality they were just re-marked and transmitted normally. As an example, here is the graph for gi3/1 (class-default) on a 6500 chassis:
Here is the output of the show policy-map int gi3/1: GigabitEthernet3/1 Service-policy input: <name> class-map: <Class A> (match-any) Match: protocol arp Match: access-group name <ACL A1> Match: access-group name <ACL A2> police : 32000 bps 102400 limit 102400 extended limit Earl in slot 3 : 1377162657 bytes 5 minute offered rate 2280 bps aggregate-forwarded 1377162657 bytes action: transmit exceeded 0 bytes action: drop <- Zero drops aggregate-forward 2520 bps exceed 0 bps class-map: class-default (match-any) Match: any police : 40000000 bps 3200000 limit 3200000 extended limit 1000000000 pir-bps Earl in slot 3 : 10562039041987 bytes 5 minute offered rate 11748848 bps aggregate-forwarded 10562039041987 bytes action: set-dscp-transmit exceeded 297846881624 bytes action: policed-dscp-transmit violated 0 bytes action: drop <- Zero drops aggregate-forward 13842064 bps exceed 0 bps violate 0 bps So in summary, there have never been any actual drops on the port, only re-marking of the DSCP (incrementing the exceeded counter) and then a transmit. Since the re-marking occurs in the “exceeded” counter, I think Observium is considering them as dropped, instead of just exceeded. This also messes up the pre-policy and post-policy counters, because it implies that traffic didn’t make it through when in reality it all did. We use re-marking extensively and so all of the CBQoS graphs show incorrect drop and post-policy information. Either that or we’ve got a bug/misconfiguration (or I just don’t get it), so maybe someone else can confirm? Let me know what debug info is needed if it helps :) Cheers! Robert Williams Custodian Data Centre Email: Robert@CustodianDC.com http://www.CustodianDC.com [1] _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium [2]
Links:
[1] http://www.CustodianDC.com [2] http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
Hi,
I’ve done some more digging on this and the counters are reporting just fine, it’s the wording of them which seems to be the issue.
The “dropped” counter is actually anything which did not count under the very first tier of the policer. So in a three colour policer, it’s anything which is either exceeded or violated, even if the exceed or violate action is to transmit, it still counts it as a “dropped” packet.
So technically Observium is reporting it accurately and the counter itself is correct but the word used when displaying it should really be something like “Exceeded” rather than dropped, because the action isn’t necessarily that it was “Dropped”, although it can be, it is not always.
Cheers,
From: observium [mailto:observium-bounces@observium.org] On Behalf Of Peter Persson Sent: 10 August 2014 21:36 To: Observium Network Observation System Subject: Re: [Observium] CBQoS 'drop' vs 'policed-transmit'
When you are calculating on drops in 6500/7600/other fucked up qos groups with WRR/SRR-queues, the counters will not be accurate.
Take a look at TCAM drops instead.
2014-08-10 10:01 GMT+02:00 Robert Williams <Robert@custodiandc.commailto:Robert@custodiandc.com>: Hi,
Just noticed that the CBQoS stuff has gone active recently (which is very cool) - currently we get all this via (very) painful integration with Cacti.
On looking closer I’ve found what I think is an issue, but stand ready to be corrected. What I think is happening is that Observium is considering packets the Cisco counted as “Exceeded” to have been “Dropped” where in reality they were just re-marked and transmitted normally.
As an example, here is the graph for gi3/1 (class-default) on a 6500 chassis:
[cid:image001.jpg@01CFB581.40FDFEB0]
Here is the output of the show policy-map int gi3/1:
GigabitEthernet3/1
Service-policy input: <name>
class-map: <Class A> (match-any) Match: protocol arp Match: access-group name <ACL A1> Match: access-group name <ACL A2> police : 32000 bps 102400 limit 102400 extended limit Earl in slot 3 : 1377162657 bytes 5 minute offered rate 2280 bps aggregate-forwarded 1377162657 bytes action: transmit exceeded 0 bytes action: drop <- Zero drops aggregate-forward 2520 bps exceed 0 bps
class-map: class-default (match-any) Match: any police : 40000000 bps 3200000 limit 3200000 extended limit 1000000000 pir-bps Earl in slot 3 : 10562039041987 bytes 5 minute offered rate 11748848 bps aggregate-forwarded 10562039041987 bytes action: set-dscp-transmit exceeded 297846881624 bytes action: policed-dscp-transmit violated 0 bytes action: drop <- Zero drops aggregate-forward 13842064 bps exceed 0 bps violate 0 bps
So in summary, there have never been any actual drops on the port, only re-marking of the DSCP (incrementing the exceeded counter) and then a transmit.
Since the re-marking occurs in the “exceeded” counter, I think Observium is considering them as dropped, instead of just exceeded. This also messes up the pre-policy and post-policy counters, because it implies that traffic didn’t make it through when in reality it all did. We use re-marking extensively and so all of the CBQoS graphs show incorrect drop and post-policy information.
Either that or we’ve got a bug/misconfiguration (or I just don’t get it), so maybe someone else can confirm? Let me know what debug info is needed if it helps :)
Cheers!
Robert Williams Custodian Data Centre Email: Robert@CustodianDC.commailto:Robert@CustodianDC.com http://www.CustodianDC.com
Robert Williams Custodian Data Centre Email: Robert@CustodianDC.com http://www.CustodianDC.com _______________________________________________ observium mailing list observium@observium.orgmailto:observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
You probably want to moan at Cisco. They defined this MIB.
As with roughly 50% of "this doesn't work quite right" mails to this list, this is a vendor issue. Nothing at all to do with us. We report the numbers they give us. Moan at them if they numbers don't represent what the MIB says they do.
http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&translate=T...
adam.
On 2014-08-13 17:24, Robert Williams wrote:
Hi,
I’ve done some more digging on this and the counters are reporting just fine, it’s the wording of them which seems to be the issue.
The “dropped” counter is actually anything which did not count under the very first tier of the policer. So in a three colour policer, it’s anything which is either exceeded or violated, even if the exceed or violate action is to transmit, it still counts it as a “dropped” packet.
So technically Observium is reporting it accurately and the counter itself is correct but the word used when displaying it should really be something like “Exceeded” rather than dropped, because the action isn’t necessarily that it was “Dropped”, although it can be, it is not always.
Cheers,
FROM: observium [mailto:observium-bounces@observium.org] ON BEHALF OF Peter Persson SENT: 10 August 2014 21:36 TO: Observium Network Observation System SUBJECT: Re: [Observium] CBQoS 'drop' vs 'policed-transmit'
When you are calculating on drops in 6500/7600/other fucked up qos groups with WRR/SRR-queues, the counters will not be accurate.
Take a look at TCAM drops instead.
2014-08-10 10:01 GMT+02:00 Robert Williams Robert@custodiandc.com:
Hi,
Just noticed that the CBQoS stuff has gone active recently (which is very cool) - currently we get all this via (very) painful integration with Cacti.
On looking closer I’ve found what I think is an issue, but stand ready to be corrected. What I think is happening is that Observium is considering packets the Cisco counted as “Exceeded” to have been “Dropped” where in reality they were just re-marked and transmitted normally.
As an example, here is the graph for gi3/1 (class-default) on a 6500 chassis:
Here is the output of the show policy-map int gi3/1:
GigabitEthernet3/1
Service-policy input: <name>
class-map: <Class A> (match-any)
Match: protocol arp
Match: access-group name <ACL A1>
Match: access-group name <ACL A2>
police :
32000 bps 102400 limit 102400 extended limit
Earl in slot 3 :
1377162657 bytes
5 minute offered rate 2280 bps
aggregate-forwarded 1377162657 bytes action: transmit
exceeded 0 bytes action: drop <- Zero drops
aggregate-forward 2520 bps exceed 0 bps
class-map: class-default (match-any)
Match: any
police :
40000000 bps 3200000 limit 3200000 extended limit 1000000000 pir-bps
Earl in slot 3 :
10562039041987 bytes
5 minute offered rate 11748848 bps
aggregate-forwarded 10562039041987 bytes action: set-dscp-transmit
exceeded 297846881624 bytes action: policed-dscp-transmit
violated 0 bytes action: drop <- Zero drops
aggregate-forward 13842064 bps exceed 0 bps violate 0 bps
So in summary, there have never been any actual drops on the port, only re-marking of the DSCP (incrementing the exceeded counter) and then a transmit.
Since the re-marking occurs in the “exceeded” counter, I think Observium is considering them as dropped, instead of just exceeded. This also messes up the pre-policy and post-policy counters, because it implies that traffic didn’t make it through when in reality it all did. We use re-marking extensively and so all of the CBQoS graphs show incorrect drop and post-policy information.
Either that or we’ve got a bug/misconfiguration (or I just don’t get it), so maybe someone else can confirm? Let me know what debug info is needed if it helps :)
Cheers!
Robert Williams
Custodian Data Centre
Email: Robert@CustodianDC.com
http://www.CustodianDC.com [1]
Robert Williams Custodian Data Centre Email: Robert@CustodianDC.com http://www.CustodianDC.com
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium [2]
Links:
[1] http://www.CustodianDC.com [2] http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
Hi,
That's interesting thanks - looks like the OID above that contains no objects (that I can see) which could even be used to display non-conforming packets at all? So I guess it can only count them as drops even though the text describing it clearly says "dropped bytes per class as the result of all features that can produce drops".
So I can't even really tell Cisco that it's in the wrong place because there doesn't appear to be a right place for them, at all? Looks like when the OID was originally structured they didn't think to consider that something other than dropping could possibly occur, crazy. For what it's worth, I'm going to open a TAC against it anyway as we do use (and monitor) over 2500 of these policies across our network, as do many people I expect. So it is important for us to be able to tell the difference between drops and simple re-marking.
I looked at how we are doing it on Cacti and it appears that we count the "drops" counter as "non-conformed", then use the difference between "pre" and "post" policy rates to display another line item which is actually the real "drops", calculated locally with an RRD maths script (the very painful method I mentioned originally). To do this in Observium would obviously be a substantial amount of change to the way in which Observium handles the data for this particular set and so I'm not suggesting for a moment this should be done, just pointing out a way that would result in getting correct data and covering up the total lack of thought that Cisco put into their OID structure in case anyone is interested in getting the real drop and re-marking data for their policies :)
Cheers as always!
Robert Williams Custodian Data Centre Email: Robert@CustodianDC.com http://www.CustodianDC.com
-----Original Message----- From: observium [mailto:observium-bounces@observium.org] On Behalf Of Adam Armstrong Sent: 13 August 2014 21:43 To: Observium Network Observation System Subject: Re: [Observium] CBQoS 'drop' vs 'policed-transmit'
You probably want to moan at Cisco. They defined this MIB.
As with roughly 50% of "this doesn't work quite right" mails to this list, this is a vendor issue. Nothing at all to do with us. We report the numbers they give us. Moan at them if they numbers don't represent what the MIB says they do.
http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&translate=T...
adam.
On 2014-08-13 17:24, Robert Williams wrote:
Hi,
I’ve done some more digging on this and the counters are reporting just fine, it’s the wording of them which seems to be the issue.
The “dropped” counter is actually anything which did not count under the very first tier of the policer. So in a three colour policer, it’s anything which is either exceeded or violated, even if the exceed or violate action is to transmit, it still counts it as a “dropped” packet.
So technically Observium is reporting it accurately and the counter itself is correct but the word used when displaying it should really be something like “Exceeded” rather than dropped, because the action isn’t necessarily that it was “Dropped”, although it can be, it is not always.
Cheers,
FROM: observium [mailto:observium-bounces@observium.org] ON BEHALF OF Peter Persson SENT: 10 August 2014 21:36 TO: Observium Network Observation System SUBJECT: Re: [Observium] CBQoS 'drop' vs 'policed-transmit'
When you are calculating on drops in 6500/7600/other fucked up qos groups with WRR/SRR-queues, the counters will not be accurate.
Take a look at TCAM drops instead.
2014-08-10 10:01 GMT+02:00 Robert Williams Robert@custodiandc.com:
Hi,
Just noticed that the CBQoS stuff has gone active recently (which is very cool) - currently we get all this via (very) painful integration with Cacti.
On looking closer I’ve found what I think is an issue, but stand ready to be corrected. What I think is happening is that Observium is considering packets the Cisco counted as “Exceeded” to have been “Dropped” where in reality they were just re-marked and transmitted normally.
As an example, here is the graph for gi3/1 (class-default) on a 6500 chassis:
Here is the output of the show policy-map int gi3/1:
GigabitEthernet3/1
Service-policy input: <name>
class-map: <Class A> (match-any)
Match: protocol arp
Match: access-group name <ACL A1>
Match: access-group name <ACL A2>
police :
32000 bps 102400 limit 102400 extended limit
Earl in slot 3 :
1377162657 bytes
5 minute offered rate 2280 bps
aggregate-forwarded 1377162657 bytes action: transmit
exceeded 0 bytes action: drop <- Zero drops
aggregate-forward 2520 bps exceed 0 bps
class-map: class-default (match-any)
Match: any
police :
40000000 bps 3200000 limit 3200000 extended limit 1000000000 pir-bps
Earl in slot 3 :
10562039041987 bytes
5 minute offered rate 11748848 bps
aggregate-forwarded 10562039041987 bytes action: set-dscp-transmit
exceeded 297846881624 bytes action: policed-dscp-transmit
violated 0 bytes action: drop <- Zero drops
aggregate-forward 13842064 bps exceed 0 bps violate 0 bps
So in summary, there have never been any actual drops on the port, only re-marking of the DSCP (incrementing the exceeded counter) and then a transmit.
Since the re-marking occurs in the “exceeded” counter, I think Observium is considering them as dropped, instead of just exceeded. This also messes up the pre-policy and post-policy counters, because it implies that traffic didn’t make it through when in reality it all did. We use re-marking extensively and so all of the CBQoS graphs show incorrect drop and post-policy information.
Either that or we’ve got a bug/misconfiguration (or I just don’t get it), so maybe someone else can confirm? Let me know what debug info is needed if it helps :)
Cheers!
Robert Williams
Custodian Data Centre
Email: Robert@CustodianDC.com
http://www.CustodianDC.com [1]
Robert Williams Custodian Data Centre Email: Robert@CustodianDC.com http://www.CustodianDC.com
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium [2]
Links:
[1] http://www.CustodianDC.com [2] http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
_______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
I looked at how we are doing it on Cacti and it appears that we count the "drops" counter as "non-conformed", then use the difference between "pre" and "post" policy rates to display another line item which is actually the real "drops", calculated locally with an RRD maths script (the very painful method I mentioned originally). To do this in Observium would obviously be a substantial amount of change to the way in which Observium handles the data for this particular set and so I'm not suggesting for a moment this should be done, just pointing out a way that would result in getting correct data and covering up the total lack of thought that Cisco put into their OID structure in case anyone is interested in getting the real drop and re-marking data for their policies :)
Are you sure? The difference between pre/post always seems to equal drops in all the instances I've looked at.
adam.
Are you sure? The difference between pre/post always seems to equal drops in all the instances I've looked at.
mmm...I've just had a look and here are two examples in the counter stats (local, not SNMP).
Policy A does _dropping_ only, Policy B does _remarking_ only:
POLICY-A Classification statistics (packets/bytes) Matched : 3603441/4167907032 Total Dropped : 2905456/3801500478 Policing statistics (packets/bytes) Policed(conform) : 697985/ 366406554 Policed(exceed) : 2905456/3801500478 <- exceeds = drops Policed(violate) : 0/0 Policed and dropped : 2905456/3801500478 <- drops
POLICY-B Classification statistics (packets/bytes) Matched : 204616674/189860926678 Total Dropped : 0/0 Policing statistics (packets/bytes) Policed(conform) : 204089813/189071062300 Policed(exceed) : 526861/ 789864378 <- these are remarked Policed(violate) : 0/0 Policed and dropped : 0/0 <- no drops at all
So it looks like there is a separate counter for the drops. I'm trying to see if there is any correlation between these counters and the SNMP ones.
I can indeed see what you are saying though, so let me try to get a definitive answer on it as right now I'm a bit lost as to how it's currently working (or even if the data we pull is valid, thanks to these stupidly named counters)... I'll get back to you when (or if) I find something more solid!...
Cheers!
Robert Williams Custodian Data Centre Email: Robert@CustodianDC.com http://www.CustodianDC.com
Are you still looking at service-policy via snmp on your 6500/7600?
/P
2014-08-14 16:18 GMT+02:00 Robert Williams Robert@custodiandc.com:
Are you sure? The difference between pre/post always seems to equal drops in all the instances I've looked at.
mmm...I've just had a look and here are two examples in the counter stats (local, not SNMP).
Policy A does _dropping_ only, Policy B does _remarking_ only:
POLICY-A Classification statistics (packets/bytes) Matched : 3603441/4167907032 Total Dropped : 2905456/3801500478 Policing statistics (packets/bytes) Policed(conform) : 697985/ 366406554 Policed(exceed) : 2905456/3801500478 <- exceeds = drops Policed(violate) : 0/0 Policed and dropped : 2905456/3801500478 <- drops
POLICY-B Classification statistics (packets/bytes) Matched : 204616674/189860926678 Total Dropped : 0/0 Policing statistics (packets/bytes) Policed(conform) : 204089813/189071062300 Policed(exceed) : 526861/ 789864378 <- these are remarked Policed(violate) : 0/0 Policed and dropped : 0/0 <- no drops at all
So it looks like there is a separate counter for the drops. I'm trying to see if there is any correlation between these counters and the SNMP ones.
I can indeed see what you are saying though, so let me try to get a definitive answer on it as right now I'm a bit lost as to how it's currently working (or even if the data we pull is valid, thanks to these stupidly named counters)... I'll get back to you when (or if) I find something more solid!...
Cheers!
Robert Williams Custodian Data Centre Email: Robert@CustodianDC.com http://www.CustodianDC.com
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
Are you still looking at service-policy via snmp on your 6500/7600?
/P
Hi - the extract in my last was from an ASR9k (5.2.0). Since they appear to have the same issue with the graphs and it was originally on the ASR9k statistics I first noticed the issue because they have massive chunks of so called 'dropped' traffic (very alarming when you first look at them) but in reality it is actually just 'remarked', despite the separate counters at the CLI. I think the 6500 might have single counters at the CLI and simply state the "action" in words rather than in a separate counter.
When I get a moment I'll take the script apart we are using on Cacti to make sure I understand it correctly. There seems to be a difference between the two systems, although Cacti has 1 minute polling so it may be visual and simply caused by that, or maybe we are hitting different OIDs on Cacti. It looks like it should be doable, certainly on the 9k platform anyway. I'd welcome anyone else doing any comparisons against their systems because maybe I'm missing something fundamental here...
Cheers!
Robert Williams Custodian Data Centre Email: Robert@CustodianDC.com http://www.CustodianDC.com
participants (3)
-
Adam Armstrong -
Peter Persson -
Robert Williams