[c-nsp] 6500 NDE aging "prematurely"
Tassos Chatzithomaoglou
achatz at forthnet.gr
Wed Jun 4 09:44:49 EDT 2008
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: cisco-nsp-bounces at puck.nether.net on behalf of Phil Mayers
>>>> Sent: Wed 04/06/2008 12:53
>>>> To: cisco-nsp at 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 300 N/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# Type Features
>>>> IPv4: 0 reserved none
>>>> IPv4: 1 Intf FulFM_GUARDIAN
>>>> IPv4: 2 unused none
>>>> IPv4: 3 reserved none
>>>>
>>>> IPv6: 0 reserved none
>>>> IPv6: 1 unused none
>>>> IPv6: 2 unused none
>>>> IPv6: 3 reserved none
>>>> _______________________________________________
>>>> 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/
>>>
>> _______________________________________________
>> 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