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.procha...@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@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@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/

Reply via email to