Fwd: Re: FW: [nsp] NetFlow not exporting?
Paul Kohler
pkohler at cisco.com
Tue Apr 20 13:12:32 EDT 2004
We had the documentation fixed at
http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_command_reference_chapter09186a00801a7f6f.html#wp1101595
and now it correctly specifies both "interface and sub-interface".
We're also now adding Field Descriptions to "show ip flow export" so that
will get added shortly.
Thanks for pointing these two discrepancies out.
Paul
>Date: Fri, 16 Apr 2004 21:18:06 -0700
>To: bep at whack.org
>From: Paul Kohler <pkohler at cisco.com>
>Subject: Re: FW: [nsp] NetFlow not exporting?
>Cc: Andy Webster <awebster at illinois.net>, cisco-nsp at puck.nether.net
>
>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