[c-nsp] Sup2T - poor netflow performance

[Jiri Prochazka]

Andras, Gert,


I'll try this today and will let you know the result. I thought the 
majority of CPU usage is consumed by 'match' statements, so I have 
already tried just 'match source ip' and 'match destination ip', which 
had no effect.



Jiri

Dne 26.3.2013 22:33, Tóth András napsal(a):
> Hi Jiri,
>
> You could try with less collect parameters. I'd remove them and increase
> gradually to find out which one causes the biggest performance decrease.
>
> You might try the following netflow full-flow config:
>
> flow record FULL
>   match ipv4 source address
>   match ipv4 destination address
>   match transport source-port
>   match transport destination-port
>   match flow direction
>   collect counter bytes
>
> flow exporter FULL-EXPORT
>   destination x.x.x.x
>   source Vlan1
>   transport udp 9996
>
> flow monitor FULL-MONITOR
>   record FULL
>   exporter FULL-EXPORT
>
> Best regards,
> Andras
>
>
>
> On Tue, Mar 26, 2013 at 4:37 PM, Jiri Prochazka <
> jiri.prochazka at superhosting.cz> 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.
>> ______________________________**_________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/**mailman/listinfo/cisco-nsp<https://puck.nether.net/mailman/listinfo/cisco-nsp>
>> archive at http://puck.nether.net/**pipermail/cisco-nsp/<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/
>