[c-nsp] 6500 NDE aging prematurely
All, We use nfdump/nfsen to gather our flows. The nfcap daemon writes the flows to 5-minute-window files, the filename being the *start* of the 5-minute window. If I look at e.g. nfcapd.200806041235 I see the following distribution of flow *end* times: 732 2008-06-04 12:29 16492 2008-06-04 12:30 19769 2008-06-04 12:31 22704 2008-06-04 12:32 21701 2008-06-04 12:33 91460 2008-06-04 12:34 148540 2008-06-04 12:35 153881 2008-06-04 12:36 177542 2008-06-04 12:37 184133 2008-06-04 12:38 143340 2008-06-04 12:39 Given that we are running with the default aging parameters: enable timeout packet threshold -- --- normal aging true 300N/A fast aging false 32 100 long aging true 1920 N/A ...I'm puzzled; surely during the window 12:35:00 - 12:39:59 we should only ever receive flows with end time up to 12:35:00 (plus or minus a few tens of seconds, depending on the aging) Why is the router exporting flows which have been inactive for only ~1 minute? The box isn't busy with regards netflow (considering we have fast aging disabled and lot of 1-packet flows) so I don't think that's the cause. TCAM utilization: Module Created Failed %Used 1 72227 0 55% 2 65312 0 49% 5 75 0 0% 6 70 0 0% 8 71824 0 54% 9 37572 0 28% ICAM utilization: Module Created Failed %Used 1 1 0 0% 2 3 0 2% 5 0 0 0% 6 0 0 0% 8 4 0 3% 9 0 0 0% Flowmasks: Mask# TypeFeatures IPv4: 0 reservednone IPv4: 1 Intf FulFM_GUARDIAN IPv4: 2 unused none IPv4: 3 reservednone IPv6: 0 reservednone IPv6: 1 unused none IPv6: 2 unused none IPv6: 3 reservednone ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 6500 NDE aging prematurely
Ben Hicks wrote: Forgive me if I'm missing something but you are looking at the actual end times of the TCP flows, not the exports (which happen continuously in chunks anyway). The flows will be reported as they end. So a 30 second connection will be reported once its finished, not at the end of the 5 minute period. That was not my understanding. My understanding was that the flow start and end times were of the first and last packets seen, and that a flow should be exported when: now - last_packet = 300 seconds ...with default aging timers. So, if we have 3 packets: 12:35:00 12:36:00 12:37:00 ...the flow should be exported at ~12:42 i.e. 300 seconds after the last packet. Many thanks, Ben -Original Message- From: [EMAIL PROTECTED] on behalf of Phil Mayers Sent: Wed 04/06/2008 12:53 To: cisco-nsp@puck.nether.net Subject: [c-nsp] 6500 NDE aging prematurely All, We use nfdump/nfsen to gather our flows. The nfcap daemon writes the flows to 5-minute-window files, the filename being the *start* of the 5-minute window. If I look at e.g. nfcapd.200806041235 I see the following distribution of flow *end* times: 732 2008-06-04 12:29 16492 2008-06-04 12:30 19769 2008-06-04 12:31 22704 2008-06-04 12:32 21701 2008-06-04 12:33 91460 2008-06-04 12:34 148540 2008-06-04 12:35 153881 2008-06-04 12:36 177542 2008-06-04 12:37 184133 2008-06-04 12:38 143340 2008-06-04 12:39 Given that we are running with the default aging parameters: enable timeout packet threshold -- --- normal aging true 300N/A fast aging false 32 100 long aging true 1920 N/A ...I'm puzzled; surely during the window 12:35:00 - 12:39:59 we should only ever receive flows with end time up to 12:35:00 (plus or minus a few tens of seconds, depending on the aging) Why is the router exporting flows which have been inactive for only ~1 minute? The box isn't busy with regards netflow (considering we have fast aging disabled and lot of 1-packet flows) so I don't think that's the cause. TCAM utilization: Module Created Failed %Used 1 72227 0 55% 2 65312 0 49% 5 75 0 0% 6 70 0 0% 8 71824 0 54% 9 37572 0 28% ICAM utilization: Module Created Failed %Used 1 1 0 0% 2 3 0 2% 5 0 0 0% 6 0 0 0% 8 4 0 3% 9 0 0 0% Flowmasks: Mask# TypeFeatures IPv4: 0 reservednone IPv4: 1 Intf FulFM_GUARDIAN IPv4: 2 unused none IPv4: 3 reservednone IPv6: 0 reservednone IPv6: 1 unused none IPv6: 2 unused none IPv6: 3 reservednone ___ cisco-nsp mailing list cisco-nsp@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@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 6500 NDE aging prematurely
A flow is exported when : 1) it is inactive for a specific time (default 15 secs)* 2) it is active and has lasted longer than a specific time (default 30 mins)* 3) a TCP flag (FIN/RST?) is received, indicating that the flow is terminated (*) 6500 uses different timers, if i remember right.. -- Tassos Phil Mayers wrote on 4/6/2008 3:42 μμ: Ben Hicks wrote: Forgive me if I'm missing something but you are looking at the actual end times of the TCP flows, not the exports (which happen continuously in chunks anyway). The flows will be reported as they end. So a 30 second connection will be reported once its finished, not at the end of the 5 minute period. That was not my understanding. My understanding was that the flow start and end times were of the first and last packets seen, and that a flow should be exported when: now - last_packet = 300 seconds ...with default aging timers. So, if we have 3 packets: 12:35:00 12:36:00 12:37:00 ...the flow should be exported at ~12:42 i.e. 300 seconds after the last packet. Many thanks, Ben -Original Message- From: [EMAIL PROTECTED] on behalf of Phil Mayers Sent: Wed 04/06/2008 12:53 To: cisco-nsp@puck.nether.net Subject: [c-nsp] 6500 NDE aging prematurely All, We use nfdump/nfsen to gather our flows. The nfcap daemon writes the flows to 5-minute-window files, the filename being the *start* of the 5-minute window. If I look at e.g. nfcapd.200806041235 I see the following distribution of flow *end* times: 732 2008-06-04 12:29 16492 2008-06-04 12:30 19769 2008-06-04 12:31 22704 2008-06-04 12:32 21701 2008-06-04 12:33 91460 2008-06-04 12:34 148540 2008-06-04 12:35 153881 2008-06-04 12:36 177542 2008-06-04 12:37 184133 2008-06-04 12:38 143340 2008-06-04 12:39 Given that we are running with the default aging parameters: enable timeout packet threshold -- --- normal aging true 300N/A fast aging false 32 100 long aging true 1920 N/A ...I'm puzzled; surely during the window 12:35:00 - 12:39:59 we should only ever receive flows with end time up to 12:35:00 (plus or minus a few tens of seconds, depending on the aging) Why is the router exporting flows which have been inactive for only ~1 minute? The box isn't busy with regards netflow (considering we have fast aging disabled and lot of 1-packet flows) so I don't think that's the cause. TCAM utilization: Module Created Failed %Used 1 72227 0 55% 2 65312 0 49% 5 75 0 0% 6 70 0 0% 8 71824 0 54% 9 37572 0 28% ICAM utilization: Module Created Failed %Used 1 1 0 0% 2 3 0 2% 5 0 0 0% 6 0 0 0% 8 4 0 3% 9 0 0 0% Flowmasks: Mask# TypeFeatures IPv4: 0 reservednone IPv4: 1 Intf FulFM_GUARDIAN IPv4: 2 unused none IPv4: 3 reservednone IPv6: 0 reservednone IPv6: 1 unused none IPv6: 2 unused none IPv6: 3 reservednone ___ cisco-nsp mailing list cisco-nsp@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@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@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 6500 NDE aging prematurely
Tassos Chatzithomaoglou wrote: A flow is exported when : 1) it is inactive for a specific time (default 15 secs)* I don't think that's correct. I think the default is 300 seconds. 2) it is active and has lasted longer than a specific time (default 30 mins)* Sure; that's not this 3) a TCP flag (FIN/RST?) is received, indicating that the flow is terminated Really? Are you certain about that? I was under the impression that the PFC did not act on TCP flags. (*) 6500 uses different timers, if i remember right.. -- Tassos Phil Mayers wrote on 4/6/2008 3:42 μμ: Ben Hicks wrote: Forgive me if I'm missing something but you are looking at the actual end times of the TCP flows, not the exports (which happen continuously in chunks anyway). The flows will be reported as they end. So a 30 second connection will be reported once its finished, not at the end of the 5 minute period. That was not my understanding. My understanding was that the flow start and end times were of the first and last packets seen, and that a flow should be exported when: now - last_packet = 300 seconds ...with default aging timers. So, if we have 3 packets: 12:35:00 12:36:00 12:37:00 ...the flow should be exported at ~12:42 i.e. 300 seconds after the last packet. Many thanks, Ben -Original Message- From: [EMAIL PROTECTED] on behalf of Phil Mayers Sent: Wed 04/06/2008 12:53 To: cisco-nsp@puck.nether.net Subject: [c-nsp] 6500 NDE aging prematurely All, We use nfdump/nfsen to gather our flows. The nfcap daemon writes the flows to 5-minute-window files, the filename being the *start* of the 5-minute window. If I look at e.g. nfcapd.200806041235 I see the following distribution of flow *end* times: 732 2008-06-04 12:29 16492 2008-06-04 12:30 19769 2008-06-04 12:31 22704 2008-06-04 12:32 21701 2008-06-04 12:33 91460 2008-06-04 12:34 148540 2008-06-04 12:35 153881 2008-06-04 12:36 177542 2008-06-04 12:37 184133 2008-06-04 12:38 143340 2008-06-04 12:39 Given that we are running with the default aging parameters: enable timeout packet threshold -- --- normal aging true 300N/A fast aging false 32 100 long aging true 1920 N/A ...I'm puzzled; surely during the window 12:35:00 - 12:39:59 we should only ever receive flows with end time up to 12:35:00 (plus or minus a few tens of seconds, depending on the aging) Why is the router exporting flows which have been inactive for only ~1 minute? The box isn't busy with regards netflow (considering we have fast aging disabled and lot of 1-packet flows) so I don't think that's the cause. TCAM utilization: Module Created Failed %Used 1 72227 0 55% 2 65312 0 49% 5 75 0 0% 6 70 0 0% 8 71824 0 54% 9 37572 0 28% ICAM utilization: Module Created Failed %Used 1 1 0 0% 2 3 0 2% 5 0 0 0% 6 0 0 0% 8 4 0 3% 9 0 0 0% Flowmasks: Mask# TypeFeatures IPv4: 0 reservednone IPv4: 1 Intf FulFM_GUARDIAN IPv4: 2 unused none IPv4: 3 reservednone IPv6: 0 reservednone IPv6: 1 unused none IPv6: 2 unused none IPv6: 3 reservednone ___ cisco-nsp mailing list cisco-nsp@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@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@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@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 6500 NDE aging prematurely
Ben Hicks wrote: From http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6555/ps6601/prod_white_paper0900aecd80406232.html -The NetFlow cache is constantly filling with flows and software in the router or switch is searching the cache for flows that have terminated or expired and these flows are exported to the NetFlow collector server. Flows are terminated when the network communication has ended (ie: a packet contains the TCP FIN flag). The following steps are used to Ok, this appears to be the key. I was under the impression that the 6500 PFC/DFC were not TCP-flag aware, however as you say, testing indicates they are. Thanks all. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 6500 NDE aging prematurely
The numbers/reasons given are for software platforms. This is the default output from a 7200: 7200#sh ip cache flow | i timeout Active flows timeout in 30 minutes Inactive flows timeout in 15 seconds On the 6500, the NDE is a different story, but according to Cisco: http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SXF/native/configuration/guide/nde.html#wp1140433 - NDE packets go to the external data collector either when the number of recently expired flows reaches a predetermined maximum or after: .30 seconds for version 5 export. .10 seconds for version 9 export. - I wish it was more clear... -- Tassos Phil Mayers wrote on 4/6/2008 4:06 μμ: Tassos Chatzithomaoglou wrote: A flow is exported when : 1) it is inactive for a specific time (default 15 secs)* I don't think that's correct. I think the default is 300 seconds. 2) it is active and has lasted longer than a specific time (default 30 mins)* Sure; that's not this 3) a TCP flag (FIN/RST?) is received, indicating that the flow is terminated Really? Are you certain about that? I was under the impression that the PFC did not act on TCP flags. (*) 6500 uses different timers, if i remember right.. -- Tassos Phil Mayers wrote on 4/6/2008 3:42 μμ: Ben Hicks wrote: Forgive me if I'm missing something but you are looking at the actual end times of the TCP flows, not the exports (which happen continuously in chunks anyway). The flows will be reported as they end. So a 30 second connection will be reported once its finished, not at the end of the 5 minute period. That was not my understanding. My understanding was that the flow start and end times were of the first and last packets seen, and that a flow should be exported when: now - last_packet = 300 seconds ...with default aging timers. So, if we have 3 packets: 12:35:00 12:36:00 12:37:00 ...the flow should be exported at ~12:42 i.e. 300 seconds after the last packet. Many thanks, Ben -Original Message- From: [EMAIL PROTECTED] on behalf of Phil Mayers Sent: Wed 04/06/2008 12:53 To: cisco-nsp@puck.nether.net Subject: [c-nsp] 6500 NDE aging prematurely All, We use nfdump/nfsen to gather our flows. The nfcap daemon writes the flows to 5-minute-window files, the filename being the *start* of the 5-minute window. If I look at e.g. nfcapd.200806041235 I see the following distribution of flow *end* times: 732 2008-06-04 12:29 16492 2008-06-04 12:30 19769 2008-06-04 12:31 22704 2008-06-04 12:32 21701 2008-06-04 12:33 91460 2008-06-04 12:34 148540 2008-06-04 12:35 153881 2008-06-04 12:36 177542 2008-06-04 12:37 184133 2008-06-04 12:38 143340 2008-06-04 12:39 Given that we are running with the default aging parameters: enable timeout packet threshold -- --- normal aging true 300N/A fast aging false 32 100 long aging true 1920 N/A ...I'm puzzled; surely during the window 12:35:00 - 12:39:59 we should only ever receive flows with end time up to 12:35:00 (plus or minus a few tens of seconds, depending on the aging) Why is the router exporting flows which have been inactive for only ~1 minute? The box isn't busy with regards netflow (considering we have fast aging disabled and lot of 1-packet flows) so I don't think that's the cause. TCAM utilization: Module Created Failed %Used 1 72227 0 55% 2 65312 0 49% 5 75 0 0% 6 70 0 0% 8 71824 0 54% 9 37572 0 28% ICAM utilization: Module Created Failed %Used 1 1 0 0% 2 3 0 2% 5 0 0 0% 6 0 0 0% 8 4 0 3% 9 0 0 0% Flowmasks: Mask# TypeFeatures IPv4: 0 reservednone IPv4: 1 Intf FulFM_GUARDIAN IPv4: 2 unused none IPv4: 3 reservednone IPv6: 0 reservednone IPv6: 1 unused none IPv6: 2 unused none IPv6: 3 reservednone ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp
