FW: [nsp] NetFlow not exporting?

Paul Kohler pkohler at cisco.com
Sat Apr 17 00:18:06 EDT 2004 

inline

At 02:01 PM 4/16/2004, Bruce Pinsky wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Andy Webster wrote:
>
>| hi,
>|       I am curious.  I have never seen the ip flow ingress command
>| when doing netflow before.  When I look it up on cisco's website it says
>| this command is for use on subinterfaces.  What is it doing on the main
>| interface in this example?
>|         So is cisco's website wrong?  (that wouldn't surprise me!)  If
>| cisco's docs are wrong can someone help me out.  What is "ip flow
>| ingress" really doing?
>|
>| From
>| http://www.cisco.com/en/US/products/sw/iosswrel/ps5187/products_command_
>| reference_chapter09186a008017cf29.html#wp1101595
>|
>| ip flow ingress
>| To configure NetFlow on a subinterface, use the ip flow ingress command
>| in subinterface configuration mode. To disable NetFlow on a
>| subinterface, use the no form of this command.
>|
>| ip flow ingress
>|
>| no ip flow ingress
>|
>| Syntax Description
>| This command has no arguments or keywords.
>|
>| Defaults
>| This command is disabled by default.
>|
>| Command Modes
>| Subinterface configuration
>|
>
>
>If I recall, there was a move to provide a more consistent and intuitive
>configuration method for Netflow and part of that was to move the
>configuration on interfaces out from under the "ip route-cache" parse chain.

That is correct. The "ip flow ingress" command is being phased in for two 
reasons:
a) we are coming out with egress functionality and this command will make 
it clear what is being configured ingress or egress NetFlow
b) configuring "ip route-cache" on the main interface infers a switching 
path command. Although NetFlow has its roots in switching it is now purely 
an accounting and analysis feature playing no active part in switching.


>I just checked a couple of routers and it is definitely available on main
>interfaces as well as subinterfaces:

This is correct and hence I will make sure the documentation is fixed.


>3725-1#sh ver
>Cisco Internetwork Operating System Software
>IOS (tm) 3700 Software (C3725-IS-M), Version 12.2(15)T11,  RELEASE SOFTWARE
>(fc2)
>3725-1(config)#int fa 0/1
>3725-1(config-if)#ip flow ?
>~  ingress  Enable inbound NetFlow
>
>7200-1#sh ver
>Cisco Internetwork Operating System Software
>IOS (tm) 7200 Software (C7200-IS-M), Version 12.3(3), RELEASE SOFTWARE (fc2)
>7200-1(config)#int s 2/0
>7200-1(config-if)#ip flow ?
>~  ingress  Enable inbound NetFlow
>
>
>| -----Original Message-----
>| From: Chris Moore - GMD [mailto:chris.moore at gmd.com]
>| Sent: Friday, April 16, 2004 10:32 AM
>| To: 'cisco-nsp at puck.nether.net'
>| Subject: [nsp] NetFlow not exporting?
>|
>|
>| Hi all,
>|
>| I'm experimenting with exporting NetFlow info to nTop. My 3745 seems to
>| think it is exporting NetFlow datagrams, but I'm not seeing these
>| packets with my sniffer - let alone with nTop. My NetFlow config looks
>| like this:
>|
>| interface Serial0/0
>|  ip address 172.17.1.6 255.255.255.252
>|  ip flow ingress
>|  ip route-cache flow

Not that it matters in terms of behavior but to configure both commands is 
redundant. Only one of the two is required.

>|
>| ip flow-export version 5
>| ip flow-export destination 10.12.23.201 2055
>|
>| Where 10.12.23.201 is my collector. Very simple - like I said, at this
>| point I'm just trying to experiment, "see what I can see".
>|
>| show ip flow export gives me this:
>|
>| Flow export v5 is enabled for main cache
>|   Exporting flows to 10.12.23.201 (2055)
>|   Exporting using source IP address 172.17.1.6
>|   Version 5 flow records
>|   4657 flows exported in 181 udp datagrams
>|   0 flows failed due to lack of export packet
>|   0 export packets were sent up to process level
>|   0 export packets were dropped due to no fib
>|   0 export packets were dropped due to adjacency issues
>|   0 export packets were dropped due to fragmentation failures
>|   0 export packets were dropped due to encapsulation fixup failures
>|
>| And show ip flow cache gives me a bunch of info about packet size,
>| protocol summaries, conversations, etc - exactly what I would expect to
>| see.

"sh ip cache flow" will give you a picture of the live cache prior to flows 
being expired. Once those flows have expired then they'll be exported.

>|
>| Unfortunately I just don't see the packets on the network. I can
>| generate traffic between 172.17.1.6 and 10.12.23.201 using ping or
>| telnet and see that just fine on my sniffer, so I'm pretty sure the path
>| is correct, the sniffer is in the right place to see the traffic and
>| obviously I'm communicationg successfully between the two devices. It
>| looks like the router just isn't sending the packets.
>|
>| My only guess is that it has something to do with the line in the show
>| ip flow export output that reads "0 export packets were sent up to
>| process level". Unfortunately I have been unable to find an explantation
>| of the output in the Cisco docs. But I did find an exaple where the
>| packets sent up to process level matched the number of export datagrams.
>| Any help with reading the output of that command?

The output of that command needs to be documented more thoroughly and we'll 
also make sure that is fixed.


If you had "export packets (that) were sent up to process level" it'd mean 
that the packets hadn't been switched correctly. When you don't have CEF 
enabled your switching path is Fast->Process and those packets don't get 
switched using Fast switching so they get sent to the process level. If you 
enable CEF your switching patch will be CEF->Fast->Process so CEF will 
process packets first and it'll show as "0 export packets were sent up to 
process level". So this is looking good and not the reason for your problem.

Please can you use the "debug ip flow export" command to confirm the UDP 
export packets are being sent.

Also, if you're generating traffic at a steady stream to trigger NetFlow 
export remember that the flow(s) have to expire in order to get exported 
otherwise you have to wait a long time to hit the active timer setting (30 
minutes by default). Your options are either to a) create test traffic that 
is intermittent (suggested way) or b) adjust the inactive timers down to 1 
second for the purposes of the test.

I doubt this is the issue but just checking because it is plausible.

Lastly, don't forget about TAC.

Paul

>|
>| Any ideas what's happening to the NetFlow UDP packets?
>|
>| Thanks,
>|
>| Chris
>| _______________________________________________
>| cisco-nsp mailing list  cisco-nsp at puck.nether.net
>| https://puck.nether.net/mailman/listinfo/cisco-nsp
>| archive at http://puck.nether.net/pipermail/cisco-nsp/
>|
>| _______________________________________________
>| cisco-nsp mailing list  cisco-nsp at puck.nether.net
>| https://puck.nether.net/mailman/listinfo/cisco-nsp
>| archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>
>- --
>=========
>bep
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.2 (MingW32)
>
>iD8DBQFAgEm7E1XcgMgrtyYRAgczAJwIqqP3OnJUedfggxZPw8OxRbGgpwCbBCqh
>TajhD31jAm3hulwFgvcwUWU=
>=MJY4
>-----END PGP SIGNATURE-----
>_______________________________________________
>cisco-nsp mailing list  cisco-nsp at puck.nether.net
>https://puck.nether.net/mailman/listinfo/cisco-nsp
>archive at http://puck.nether.net/pipermail/cisco-nsp/

More information about the cisco-nsp mailing list