[c-nsp] Sup2T - poor netflow performance

[Jiri Prochazka]

Hi Rolf,

I was not able to solve this issue yet. Punting of trafiic to CPU was not the reason. Even in case of some ddos (with more than 1mpps), number of packets going to CPU is at normal level. Still got this sup2t-netflow-issue in my to-do list.. in the meantime, netflow is turned off on the most of interfaces and being turned on just for debugging purpouses.



All the best,

Jiri Prochazka


"Rolf Hanßen" <nsp at rhanssen.de> wrote:
>Hello,
>
>the discussion got a bit off-topic.
>I have the same issue (cpu-usage explodes after enabling netflow).
>
>@Jiri:
>Were you able to solve that problem ? There was no follow-up.
>
>@Roland:
>Do you have a sample config / IOS version combination known to work
>with
>high amount of traffic/pps/src-dst-combinations ?
>For example a box exporting something to a Peakflow SP for dos
>recognition.
>I recognized that starting a random-source-ip flood over my box even
>could
>make the cli freeze.
>
>I tested with:
>System: Sup2T-XL with 15.1(1)SY1, full table.
>Cards: WS-X6704-10GE, WS-X6748-GE-TX, WS-X6724-SFP (CFC only)
>Traffic is only approx 10-15GBit
>
>Config
>flow record xy
> match ipv4 protocol
> match ipv4 source address
> match ipv4 destination address
> match transport source-port
> match transport destination-port
> match flow direction
> collect interface input
> collect interface output
> collect counter bytes
> collect counter packets
> collect timestamp sys-uptime first
> collect timestamp sys-uptime last
>
>kind regards
>Rolf
>
>
>On Tue, March 26, 2013 4:37 pm, Jiri Prochazka wrote:
>> Hi,
>>
>> after replacing one of our old vs-s720-3cxl and 6708-3cxl combo for a
>> new sup2t-xl and 6908-2txl I'm struggling with a really poor netflow
>> performance.
>>
>> In fact, enhanced netflow capacity and capabilities were the major
>> reasons for upgrade.
>>
>> On the old vs-s720-3cxl setup we have used interface-src-dst
>flowmask.
>> With aggresive timing, this setup was able to 'handle' around 6 Gbps
>of
>> strandard Internet traffic (per DFC) without undercounting and
>> overwhelming the whole box.
>>
>>
>> Now, when using sup2t-xl, which has two times bigger netflow table
>(512k
>> for ingress flows) and faster CPU, I'm not able to get it working
>with
>> even with the same level of traffic.
>>
>>
>> As soon as traffic on ingress reaches aproximately 3 Gbps, and number
>of
>> flows per one cache(card) exceeds 200k, the whole box begins to be
>> unresponsive to SNMP polls, timeouts some commands (for example show
>> platform flow ip count module x) and the CLI begins to lag.
>>
>> Furthermore, I get a lot of following messages ->
>>
>> %IPC-DFC2-5-WATERMARK: 2013 messages pending in rcv for the port
>> Card2/0:Request(2020000.7) seat 2020000
>> %IPC-DFC2-5-WATERMARK: 2019 messages pending in rcv for the port
>> Card2/0:Request(2020000.7) seat 2020000
>>
>>
>> Utilization of CPU either of Sup or linecards is acceptable (under
>60%,
>> majority is taken by 'NF SE export thr' and 'NF SE Intr Task'
>processes).
>>
>>
>> Settings of netflow is following ->
>>
>> flow record SRC-IP-IF-DST-IP-IF-AS
>> match ipv4 source address
>> match ipv4 destination address
>> collect routing source as
>> collect routing destination as
>> collect routing next-hop address ipv4
>> collect interface input
>> collect interface output
>> collect counter bytes
>> collect counter packets
>> collect timestamp sys-uptime first
>> collect timestamp sys-uptime last
>>
>>
>> flow monitor LIVEBOX-MONITOR
>> description LIVEBOX v9 monitor
>> record SRC-IP-IF-DST-IP-IF-AS
>> exporter LIVEBOX-EXPORT
>> cache timeout inactive 3
>> cache timeout active 60
>>
>> flow exporter LIVEBOX-EXPORT
>> destination x.x.x.x
>> source Vlanx
>> transport udp 9996
>>
>>
>>
>>
>> Did you notice any REAL perfomance boost compared to older Sup720
>with
>> B/CXL DFCs?
>>
>>
>> Thank you!
>>
>>
>>
>> --
>> Jiri Prochazka
>> network administrator (AS39392)
>> SuperNetwork s.r.o.
>> ___________________

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.