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. Advertising

  2. In article <d3rph9$a9b$>, Garry Glendown <> wrote:
    :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.
    --
    Beware of bugs in the above code; I have only proved it correct,
    not tried it. -- Donald Knuth
     
    Walter Roberson, Apr 17, 2005
    #2
    1. Advertising

  3. Garry Glendown

    Garry Guest

    Walter Roberson wrote:
    > In article <d3rph9$a9b$>, Garry Glendown <> wrote:
    > :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.


    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. In article <d3t3n7$mcv$>, Garry <> wrote:
    >Walter Roberson wrote:

    :> 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.
    --
    Usenet is like a slice of lemon, wrapped around a large gold brick.
     
    Walter Roberson, Apr 17, 2005
    #4
  5. > 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.


    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


    > 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 ... !?


    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, AN45
     
    Arnold Nipper, Apr 17, 2005
    #6
  7. Arnold Nipper wrote:
    >> 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 ... !?

    >
    >
    > 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


    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

    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.
     
    , Apr 18, 2005
    #8
  9. Garry Glendown

    Garry Guest

    wrote:
    > 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.


    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 ...

    > 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.


    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

    Guest

    > > I would suppose that process switched traffic would not
    > > be accounted for in netflow switching.
    > > What would I have to do to check into this?


    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.
     
    , Apr 20, 2005
    #10
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Andrea
    Replies:
    0
    Views:
    907
    Andrea
    Apr 19, 2004
  2. Alasdair Baxter

    MP3 -- Why the discrepancy?

    Alasdair Baxter, Nov 15, 2004, in forum: Computer Support
    Replies:
    1
    Views:
    517
    gangle
    Nov 15, 2004
  3. Doc

    Aftermarket Li-ion battery voltage discrepancy

    Doc, Jan 24, 2004, in forum: Digital Photography
    Replies:
    1
    Views:
    393
    Harvey
    Jan 25, 2004
  4. Jonathan Berry

    Exifer and Irfanview IPTC discrepancy

    Jonathan Berry, May 7, 2004, in forum: Digital Photography
    Replies:
    2
    Views:
    1,398
    Angus C
    May 8, 2004
  5. Charles Kerekes

    Exam 70-123: Is the "discrepancy report" the final product of SAM?

    Charles Kerekes, Aug 4, 2006, in forum: Microsoft Certification
    Replies:
    0
    Views:
    587
    Charles Kerekes
    Aug 4, 2006
Loading...

Share This Page