cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5459
Views
0
Helpful
8
Replies

Netflow

GRANT3779
Spotlight
Spotlight

Morning All (here anyway)

I recently read that when using Netflow it should be enabled as close to the access layer as possible. I have been testing on a few access layer switches using the following template, see below(for 3650 Switches) -

The switches take the commands and I see my switch automatically appear in my Flow Collector (Stealthwatch / Flow Collector) - However I get no data from the ports.

I am assuming I cannot apply the command - ip flow monitor Monitor_SW_Flow input to actual end user access ports and it needs to be done on Layer 3 Interfaces only?

I can do this on our Core Switch SVIs no problem, but what I would be missing then is traffic between the same vlans on my Access Layer (Whether Intra or Inter Switch). 

Is Netflow orientated for exporting flows crossing layer 3 boundaries rather than also catching Intra VLAN Traffic?

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

flow exporter Exporter_SW_Flow
destination 10.44.128.190
source vlan500
transport udp 2055


flow monitor Monitor_SW_Flow
record Record_SW_Flow
exporter Exporter_SW_Flow
cache timeout active 60
cache timeout inactive 15


ip flow monitor Monitor_SW_Flow input (on all access ports)

1 Accepted Solution

Accepted Solutions

Hi Yes because its a layer 3 command starts with ip syntax wont take on a pure layer 2 port  even though it can collect layer 2 traffic  , flex netflow needs to be applied to an ip based interface its a limitation haven't seen another way yet to collect layer 2 traffic with it

You could span the ports that would work collect it through wireshark as an option instead of netflow

View solution in original post

8 Replies 8

Mark Malone
VIP Alumni
VIP Alumni

Hi

You need to set it to capture layer 2 traffic

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/fnetflow/configuration/xe-3s/fnf-xe-3s-book/fnf-l2-fields.pdf

Example: Configuring Flexible NetFlow for Monitoring MAC and VLAN Statistics

The following example shows how to configure Flexible NetFlow for monitoring MAC and VLAN statistics.

This example starts in global configuration mode.

!

flow record LAYER-2-FIELDS-1

match ipv4 source address

match ipv4 destination address

match datalink dot1q vlan output

match datalink mac source address input

match datalink mac source address output

match datalink mac destination address input

match flow direction

!

exit

!!

flow monitor FLOW-MONITOR-4

record LAYER-2-FIELDS-1

exit

!

ip cef

!

interface GigabitEthernet0/0/1

ip address 172.16.6.2 255.255.255.0

ip flow monitor FLOW-MONITOR-1 input

Hi Mark,

Thanks for the input -

I see above though you are still applying the monitor command to a L3 Interface?

I was wondering if there is a way to utilise Netflow to say capture traffic between hosts that sit on the 172.16.6.0 /24 in your example above. As traffic within this subnet would not hit the L3 Interface.

Thanks

Hi Yes because its a layer 3 command starts with ip syntax wont take on a pure layer 2 port  even though it can collect layer 2 traffic  , flex netflow needs to be applied to an ip based interface its a limitation haven't seen another way yet to collect layer 2 traffic with it

You could span the ports that would work collect it through wireshark as an option instead of netflow

Just an update for anyone else with similar problem.

I was trying to send Netflow to Stealthwatch Flow Collector from a 6880-X but it was being dropped at the Flow Collector due to invalid template (even though I was using a template that others said worked. It may be they were sending to different collector)

The template I had to end up using to get the SW Flow Collector to accept the netflow was the following - This is for Layer 3 might I add.

 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

 match interface output

 collect routing next-hop address ipv4

 collect counter bytes long

 collect counter packets long

 collect timestamp sys-uptime first

 collect timestamp sys-uptime last

Hopefully helps someone at some point.

Mark - Thanks for the input as always

Ok so I have put the following on my core switch but don't seem to be getting any flows being sent.

The below has now automatically show up on my Netflow Console (Stealthwatch) but just not giving any stats/flows. Am I missing something?

sh run | sec flow


flow record Record_SW
match ipv4 protocol
match ipv4 source address
match ipv4 destination address
match transport source-port
match transport destination-port
match interface input
match interface output
collect counter bytes


flow exporter Exporter_SW
destination 10.44.128.191
source Vlan500
transport udp 2055


flow monitor Flow_SW
exporter Exporter_SW
cache timeout active 60
cache entries 500000
record Record_SW


interface Vlan510
description *Server farm***
ip address 10.44.2.1 255.255.255.0
no ip redirects
no ip proxy-arp
ip flow monitor Flow_SW input

Oddly as well I can see the following -

sh flow exporter statistics
Flow Exporter Exporter_SW:
Packet send statistics (last cleared 02:16:57 ago):
Successfully sent: 10454 (11604367 bytes)

Client send statistics:
Client: Flow Monitor Flow_SW
Records added: 1726
- sent: 1726
Bytes added: 63862
- sent: 63862

But no flows appearing on my collector.

hmm flows are being sent alright looking at your output

have you tried to enable the datalink flows though , I don't use layer 2 netflow but I would think you would need these below to collect it as its the match mac rather than ip for l3

match datalink mac source address input

match datalink mac source address output

match datalink mac destination address input

GRANT3779
Spotlight
Spotlight

Hi Mark,

Thanks, it does confirm what I was thinking from everything I read but I just wasn't quite clear.

Thanks again for your input as always.