cancel
Showing results for 
Search instead for 
Did you mean: 
Create Post
Level 10

Unable to get Netflow on SolarWinds

Jump to solution

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

0 Kudos
1 Solution

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.

View solution in original post

0 Kudos
4 Replies

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.

View solution in original post

0 Kudos

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

0 Kudos

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

 

@cnorborg 

 

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

0 Kudos

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.