[c-nsp] Sup2T - poor netflow performance

[Sam]

Hi Jiri,

We didn't have any issue so far, make sure you set a threshold for your
exporter with:

flow hardware export threshold <value>

Accordingly to Cisco doc:

Since the amount of NetFlow data that can be collected by a system has
increased dramatically with the Supervisor Engine 2T, it is important to
have a mechanism to control the NDE process so that it does not affect
other tasks performed by the CPU. The CPU still needs to process Layer 3
and Layer 2 protocols, manage the system, provide polling for SNMP, and be
available for system configuration. The Yielding NDE feature was created
to ensure that CPU resources would always be available for these other
tasks in the event of a very large NDE requirement.
With the Yielding NDE feature, users can specify the upper limit for CPU
usage by the Supervisor Engine 2T, as well as line cards. Beyond this
limit, the NetFlow data export process will yield, or pause, the export
process by reducing or even cutting off NDE. When CPU utilization is
reduced, NDE gradually returns to a normal level. (
http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/white_paper_c11-652021.html
)

You might also want to sample.

--
sam

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.
> _______________________________________________
> 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/
>


-- 
sam