Discrepancy between flow-packets and interface counter

Discussion in 'Cisco' started by Garry Glendown, Apr 16, 2005.

  1. Hi,

    I'm currently trying to locate some high troughput on a line - anyway,
    after enabling flow accounting on the PE router, I get some of the
    flows, but there's a pretty big discrepancy between the octet count of
    the flows, and what the SNMP-counters resulted in - something like 6gig
    on SNMP, and 106MB on the flows ... I tried to locate flows that I
    caused myself, which worked fine ... I'm somewhat at a loss right now
    what else could be causing the traffic on the line that would not show
    up in the flows ... !?

    tnx, -gg
     
    Garry Glendown, Apr 16, 2005
    #1
    1. Advertisements

  2. :I'm currently trying to locate some high troughput on a line - anyway,
    :after enabling flow accounting on the PE router, I get some of the
    :flows, but there's a pretty big discrepancy between the octet count of
    :the flows, and what the SNMP-counters resulted in - something like 6gig
    :eek:n SNMP, and 106MB on the flows

    I do not know the extent to which it applies to the various different
    counters, but in IOS, if you have flow caching enabled then some
    of the counters only reflect the initial packets of the flows --
    because the other packets go directly into processing rather than
    having to go through the decision-making step that has the meter.
     
    Walter Roberson, Apr 17, 2005
    #2
    1. Advertisements

  3. Garry Glendown

    Garry Guest

    Well, doesn't that contradict the (AFAIK) usual use of flows for traffic
    analysis and accounting??? Plus, if the flow is identified (for the
    route caching), isn't increasing the counter of that flow by the number
    of bytes more or less the easiest thing to do??
     
    Garry, Apr 17, 2005
    #3
  4. :> I do not know the extent to which it applies to the various different
    :> counters, but in IOS, if you have flow caching enabled then some
    :> of the counters only reflect the initial packets of the flows --

    :Well, doesn't that contradict the (AFAIK) usual use of flows for traffic
    :analysis and accounting???

    If I understand correctly, "netflow accounting" is supposed to be
    accurate. When you wrote "flow accounting" it did not match
    "netflow" in my mind, partly because you were talking about
    "counters", but netflow is a way of outputting accounting -records-
    to an outside location for later analysis.
     
    Walter Roberson, Apr 17, 2005
    #4
  5. If I understand correctly, "netflow accounting" is supposed to be
    OK, just to clarify/confirm what I'm doing:

    - our regular accounting uses the SNMP counters of a port
    - I set up flow export to get detailed flow infos to track down the
    cause of unexprected traffic:

    int ser5/0:0
    ip route-cache flow
    [..]
    ip flow-export source fa0/0
    ip flow-export version 5
    ip flow-export dest LOGGINGHOST

    One interesing thing I have noticed that I only seem to get flow data
    originating from the CPE/customer net, not any going TO the CPE/customer
    net ... !?
     
    Garry Glendown, Apr 17, 2005
    #5
  6. On 17.04.2005 16:21 Garry Glendown wrote

    You have to enable netflow on every port traffic for customer X may come
    in. Not only the interface the customer X sends traffic to. See
    http://www.cisco.com/en/US/products...figuration_guide_chapter09186a00800ca6cb.html
    for comprehensive information.



    Arnold
     
    Arnold Nipper, Apr 17, 2005
    #6
  7. The link to the backbone was netflow enabled, too ... when not limiting
    flow data to the customer interface, I still don't see "enough" flow
    traffic ... !?
     
    Garry Glendown, Apr 17, 2005
    #7
  8. Garry Glendown

    anybody43 Guest

    Is the traffic actually being fast switched? In this case you are using

    Netflow Switching as the fast switching method.

    I would suppose that process switched traffic would not
    be accounted for in netflow switching.

    Also on a broadcast (or non-broadcast) medium the router
    can receive traffic that is not forwarded by it. This will
    be recorded by the interface counters but not by the
    netflow accounting.

    In a 5 days by 8 hours environment the 24 x 7
    broadcasts can amount to a surprising proportion
    of the total traffic.
     
    anybody43, Apr 18, 2005
    #8
  9. Garry Glendown

    Garry Guest

    What would I have to do to check into this? Up till now I thought by
    enabling route-cache flow, the netflow switching were enabled and thus
    all data traffic would be visible through the flow export ... worked
    before on other customer links that had unexplainable traffic ...
    The router I'm running the flow accounting on is the sending side ... so
    I recon this does not apply ...

    Tnx, -gg
     
    Garry, Apr 20, 2005
    #9
  10. Garry Glendown

    anybody43 Guest

    I would suppose that process switched traffic would not
    sh interface switching

    sh interface stat

    Show various confusing numbers but I usually just look
    to make sure that the process switched numbers are
    a smallish proportion of the traffic. I have never wanted to
    worry more.

    Remember that the first packet in each flow is
    process switched. Maybe you have a high proportion
    of flows with few packets (one?). For example a port scan
    would likely result in this behaviour.

    I have NO IDEA if process switched packets are
    accounted for in netflow accounting. It does seem
    reasonable that they might be since the extra overhead
    would be quite small.

    Should be easy enough to test with above mentioned port
    scanning technique.
     
    anybody43, Apr 20, 2005
    #10
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.