This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

Unable to get Netflow on SolarWinds

Dear Team,

Please note that we are unable to view the Netflow on SolarWinds NTA where as we are able to view the CFLOW Data on Wireshark running on the Server.

Flow :

!

flow record record1

match ipv4 source address

match ipv4 destination address

match ipv4 protocol

match transport source-port

match transport destination-port

collect counter bytes long

collect counter packets long

collect timestamp absolute first

collect timestamp absolute last

!

!

flow exporter export1

destination 10.200.252.191

transport udp 2055

!

!

flow monitor monitor1

exporter export1

record record1

!

!

interface GigabitEthernet1/0/6

ip flow monitor monitor1 output

!

Version :

Cisco IOS XE Software, Version 16.06.03

Cisco IOS Software [Everest], Catalyst L3 Switch Software (CAT3K_CAA-UNIVERSALK9-M), Version 16.6.3, RELEASE SOFTWARE (fc8)

Technical Support: http://www.cisco.com/techsupport

Copyright (c) 1986-2018 by Cisco Systems, Inc.

Compiled Wed 28-Feb-18 21:49 by mcpre

Switch Ports Model              SW Version        SW Image              Mode

------ ----- -----              ----------        ----------            ----

*    1 52    WS-C3650-48PS      16.6.3            CAT3K_CAA-UNIVERSALK9 INSTALL

  • This is what I use in my flow record:

    match ipv4 tos
    match ipv4 protocol
    match ipv4 source address
    match ipv4 destination address
    match transport source-port
    match transport destination-port
    match interface input
    collect interface output
    collect counter bytes long
    collect counter packets long

    I also collect on the input of the interface, that's kind of a "best practice" in Netflow.  So, instead of what you have try

    ip flow monitor monitor1 input

    Traditional Netflow was done by collecting the "input" on each interface, so quite a few things are geared towards doing that.   What you're doing, "egress netflow", is quite often supported by equipment, but not always.  Without knowing what equipment you're running on, I can't check and see if it is.  

    The reason ingress netflow was done on all interfaces was so that you could get all traffic flowing through a box, in effect seeing both directions of traffic, ie: the ingress traffic on one interface ends up being egress traffic on another interface.   Why ingress vs egress?   As traffic is going out an interface, the router doesn't necessarily care what interface it came from.  As far as it's concerned, it got the traffic from one of its interfaces and doesn't really care, all it cares about is where its sending it.  But, if traffic comes in an interface (ie: ingress) it pretty quickly figures out what interfaces its sending it out, so you have both the ingress and egress interface by monitoring just the ingress traffic.

  • Thank you so much... This worked.....

  • Sorry... I forgot to ask one more thing..

     

    Our scenario is we are having a 100 remote sites and a hq connected through vsat links. We are planning to monitor Netflow at both end. In this case case, can we know your suggestions...

  • Netflow doesn't use much bandwidth, so it would be encouraged to monitor it at both ends of the link(s).   Esp. if there are multiple links to the remote sites, like multiple VPN tunnels or secondary links.   If there aren't multiple links, its still not a bad thing, that way you will get good data no matter what device your looking at.