5 Replies Latest reply on Jun 23, 2015 9:25 AM by edavis@mdsol.com

    Netflow and Correlation with NPM Interface Stats


      I am seeing a big disconnect between my NPM interface bandwidth stats and my Netfllow stats for conversations on the same interface.  For instance, I might see an interface is utilizing %95 of its bandwidth and naturally I want to see which host/hosts are using the highest amount of that %95.  My problem is that NTA seems to show more bandwidth being used in a conversation than is actually available on an interface.  For an interface that only has 50Mbps, I should not see 2 hosts in a conversation using more than 50Mbps right?  Any help is greatly appreciated.



        • Re: Netflow and Correlation with NPM Interface Stats
          Craig Norborg

          Well, first off, you can see a pretty big disconnect on the SNMP polled stats vs. the Netflow stats.  That's because the polled stats are probably showing the average over 5-9 minutes, depending on how you have your polling set up, where the Netflow stats should be showing more immediate results, depending on how you have it configured.


          With Netflow there are a few things you need to consider.  The first is how often your router is set up to send Netflow stats to Orion.   If you don't configure it, your router might wait until the flow ends before sending statistics on that flow.   So, lets say someone opens up a FTP connection for a half Gb of data, and it transfers over a 10Mbps link, which would take about 400 seconds if my quick math is right (assuming nothing else is on the link).   So, if Netflow waits to send the fact that a half gig of traffic was done until the end, it would look as if the half gig of data was transferred all at once for the most part.   But you know you can't get a half gig of data across a 10Mbps link immediately so something has to be wrong.  If you set up timeouts on the flow traffic, lets say like this:

          ip flow-cache timeout inactive 45

          ip flow-cache timeout active 1

          The "inactive" timeouts are in seconds, while the "active" flow timeouts are 1 minute.   So, instead of netflow sending a single record after 400 seconds, it would send at least 6 updates each saying it sent a part of the half Gb of data.  Much more accurate.


          Its also possible that you don't have things set up quite right either.   From what I understand, you should have it set up for "ip flow ingress" ONLY on all interfaces of a given router, or if there are only a couple interfaces traffic is going across, you could choose one of them and do both "ip flow ingress" and "ip flow egress" on one interface.  Otherwise you can see double the traffic.


          If this doesn't answer your question, maybe you can post your netflow configs on your devices?

            • Re: Netflow and Correlation with NPM Interface Stats



                 You are 2 for 2.  I will post my config here.  I think you have answered my question, but I want to just show my config to verify.


              interface Loopback0

              description <<<Loopback Address for Management>>>

              ip address

              no ip redirects

              no ip unreachables

              ip directed-broadcast

              no ip proxy-arp

              ip flow ingress


              interface Tunnel100

              bandwidth 21000

              ip address

              no ip redirects

              ip bandwidth-percent eigrp 100 80

              ip hello-interval eigrp 100 30

              ip hold-time eigrp 100 90

              ip flow ingress

              ip flow egress

              ip nhrp map multicast dynamic

              ip nhrp map multicast

              ip nhrp map

              ip nhrp network-id 1

              ip nhrp holdtime 300

              ip nhrp nhs

              ip tcp adjust-mss 1300

              ip summary-address eigrp 100

              qos pre-classify

              tunnel source GigabitEthernet0/1.3767

              tunnel mode gre multipoint

              tunnel key 1

              tunnel path-mtu-discovery



              interface GigabitEthernet0/0

              description <<<Connection to Distribution Switch 2 - Port 1>>>

              ip address

              no ip redirects

              no ip unreachables

              ip directed-broadcast

              no ip proxy-arp

              ip flow ingress

              standby 2 ip

              standby 2 preempt

              ip tcp adjust-mss 1200

              ip policy route-map Clear_DF

              duplex auto

              speed auto

              media-type rj45



              ip flow-export source Loopback0

              ip flow-export version 9

              ip flow-export destination 2055