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