Hi,
I have just noticed that the results being returned by pmacct do not match up
with the real data.
The configuration is:
Internet -- c7609 -- 10M fiber -- c3550 -- customer
We are exporting netflow stats from the Cisco 7609 and I am aware of the
limitations on this platform, but the total data through the 7609 that we are
trying to export flow stats for is in the order of 50Mbps (max) so hopefully we
should not be exceeding anything on the box.
It doesn't LOOK like the 7609 is dropping any stats (although I am no expert on
7609 netflow):
#show ip flow export
Flow export v9 is enabled for main cache
Export source and destination details :
VRF ID : Default
Source(1) 10.1.1.115 (Vlan2)
Destination(1) 10.1.1.38 (6789)
Version 9 flow records
13267046 flows exported in 1142685 udp datagrams
0 flows failed due to lack of export packet
0 export packets were sent up to process level
1 export packets were dropped due to no fib
0 export packets were dropped due to adjacency issues
0 export packets were dropped due to fragmentation failures
0 export packets were dropped due to encapsulation fixup failures
0 export packets were dropped enqueuing for the RP
0 export packets were dropped due to IPC rate limiting
0 export packets were dropped due to Card not being able to export
#show mls netflow table-contention summary
Earl in Module 6
Summary of Netflow CAM Utilization (as a percentage)
====================================================
TCAM Utilization : 1%
ICAM Utilization : 0%
Netflow Creation Failures : 0
Netflow CAM aliases : 0
The difference is quite large. The number from pmacct are (from MySQL exported
data):
+------------+---------------------+---------------------+
| bytes | stamp_inserted | stamp_updated |
+------------+---------------------+---------------------+
| 3505877423 | 2010-12-23 11:00:00 | 2010-12-23 12:00:01 |
| 114559834 | 2010-12-23 10:00:00 | 2010-12-23 11:00:01 |
| 107033171 | 2010-12-23 09:00:00 | 2010-12-23 10:00:01 |
| 2248788510 | 2010-12-23 08:00:00 | 2010-12-23 09:00:01 |
| 730948403 | 2010-12-23 07:00:00 | 2010-12-23 08:00:01 |
| 1432262718 | 2010-12-23 06:00:00 | 2010-12-23 07:00:01 |
| 542630778 | 2010-12-23 05:00:00 | 2010-12-23 06:00:01 |
| 546202726 | 2010-12-23 04:00:00 | 2010-12-23 05:00:01 |
| 505622657 | 2010-12-23 03:00:00 | 2010-12-23 04:00:01 |
| 545262871 | 2010-12-23 02:00:00 | 2010-12-23 03:00:01 |
| 2704448981 | 2010-12-23 01:00:00 | 2010-12-23 02:00:01 |
+------------+---------------------+---------------------+
Whereas the number from the interface stats on the 3550 are (from PRTG):
Date Time Traffic out (volume)
23/12/2010 11:00:00 AM - 12:00:00 PM 3,637,126 KByte
23/12/2010 10:00:00 AM - 11:00:00 AM 4,265,164 KByte
23/12/2010 9:00:00 AM - 10:00:00 AM 4,266,288 KByte
23/12/2010 8:00:00 AM - 9:00:00 AM 4,137,007 KByte
23/12/2010 7:00:00 AM - 8:00:00 AM 4,290,950 KByte
23/12/2010 6:00:00 AM - 7:00:00 AM 4,705,733 KByte
23/12/2010 5:00:00 AM - 6:00:00 AM 4,861,328 KByte
23/12/2010 4:00:00 AM - 5:00:00 AM 4,809,456 KByte
23/12/2010 3:00:00 AM - 4:00:00 AM 4,564,060 KByte
23/12/2010 2:00:00 AM - 3:00:00 AM 4,855,658 KByte
23/12/2010 1:00:00 AM - 2:00:00 AM 4,865,965 KByte
The customer is flogging the 10Mbps link at full speed (which is fine, not
concerned about that, they are entitled to) and so the correct figure is as
reported by the interface stats of between 4-5GB per hour. If you do the math,
this works out correct, 10Mbps = 4.5GB/hr.
The results from pmacct are way short of what they should be.
I'm open to suggestions on where to look to diagnose what is going on and why
pmacct is not correct.
I'm running 0.12.0rc2 and will look at upgrading in the next week or so, but
I'm not sure that will make any difference (are there any bugs that might be
causing this ?).
I don't know if it is just stats for this customer being affected, but I would
suspect that it is probably showing less than it should across the board.
Apologies if this would be better directed at the c-nsp list, but I don't think
the problem is on the Cisco side (although I'm happy to investigate this
further if anyone can point in the right direction).
Thanks,
Tony.
_______________________________________________
pmacct-discussion mailing list
http://www.pmacct.net/#mailinglists
