crypto engine utilization - how to measure?

[Przemyslaw Konitz]

hi,

I'm looking for a command or different way to measure processor utilization in a crypto engine card?

Is there any way to check how traffic in vpn tunnels impact crypto engine processor? Why I need it? For example if I got 100 tunnels with some traffic characteristic I need to know whether I can add new tunnels to it or I need to buy a new router to terminate all new added vpns.

SNMP oid? command?

I tried to find something in command reference but with no success.

regards

Przemek

[Marcin Latosiewicz]

Przemek,

I am by all mean not all-knowing, but here's my pitch.

Crypto engines range from, software to onboad (motorola/cavium chips) to AIM  to VSA to VAM to VMSM to VPN SPA to ASR1k's crypto module - Nitrox (not in any particular order).

There is not uniform way to monitor usage/ultization of all those...

On ISRs "show crypto engine accel stati" should show you a decent sets of stats, including ppq/buffer stats which indicate that buffer was exhausted.

VAM and VSA are separate case "test pas" commands are visible in show tech.

VPN SPA and VPN SM ... talk about complicated.

What do you want to achieve and on which platforms?

Marcin

[Przemyslaw Konitz]

Thx Marcin for your reply,

I have 2800 platform on my mind. I need to find a way to measure it somehow in order to know whether I can add new IPSec tunnel or not.

As its obvious processor utilization on AIM card depends on traffic characteristic. I'm also looking for some information how much vpn tunnels 2821 can terminate when each peer generates small amount of packets (let assume this is a banking machine).

As this kind of information is hard to find in datasheets, which is explainable, I started looking for a way for processor utlization which could give me enough information whether I can add new tunnel or not. Would 700 tunnels be to much or not? As I remember in datasheet there was a note that 28xx can support up to 1500 tunnels but how the traffic looked like?

As you suggested:

On ISRs "show crypto engine accel stati" should show you a decent sets of stats, including ppq/buffer stats which indicate that buffer was exhausted.

2811#sh crypto engine accelerator sta

Device:   NETGX
Location: Onboard: 0
        :Statistics for encryption device since the last clear
         of counters 575820 seconds ago
                3617295 packets in                     3617295 packets out          
              697286786 bytes in                     691980311 bytes out            
                      6 paks/sec in                          6 paks/sec out         
                      9 Kbits/sec in                         9 Kbits/sec out        
                1751694 packets decrypted              1865601 packets encrypted    
              542712864 bytes before decrypt         143428604 bytes encrypted      
              423567359 bytes decrypted              268412952 bytes after encrypt  
                      0 packets decompressed                 0 packets compressed   
                      0 bytes before decomp                  0 bytes before comp    
                      0 bytes after decomp                   0 bytes after comp     
                      0 packets bypass decompr               0 packets bypass compres
                      0 bytes bypass decompres               0 bytes bypass compressi
                      0 packets not decompress               0 packets not compressed
                      0 bytes not decompressed               0 bytes not compressed 
                  1.0:1 compression ratio                1.0:1 overall
                Last 5 minutes:
                   1498 packets in                        1498 packets out          
                      4 paks/sec in                          4 paks/sec out         
                   7550 bits/sec in                       7462 bits/sec out         
                 186554 bytes decrypted                  37349 bytes encrypted      
                   5042 Kbits/sec decrypted               1009 Kbits/sec encrypted  
                  1.0:1 compression ratio                1.0:1 overall

        pkts dropped:      0
        fw_failure:        0   invalid_flow:    0     netgx sessions:    2
        ownership_err:     0   null_data:       0     reqId mismatch:    0
        fw_qs_filled:      0   fw_resource_lock:0
        tx_hi_drops:       0   pak_too_big:     0
        pak_mp_length_spec_fault: 0
        Interrupts: Notify = 0, Reflected = 0, Spurious = 0
        ring limit:64  current desc used: 0  current ring index: 15
        wait session queue: 0 msg   session buf queue: 1024

As I understand this output and your suggestion about buffers I think it's hard to use it in the way I want. Maybe my way of thinking is wrong but in my opinion the information that buffers are full or packets are being dropped in not quick enaough. I'd like to know in advance that adding another 10 tunnels would have bad impact on crypto engine processor.

Thats why I tried to find sth like cpu utilization so I could poll this stats and make history.

regards

Przemek

[Marcin Latosiewicz · Accepted solution]

Przemek,

I'm afarid the answer still will not be uniform :-)

In your case you're running onboard crypto engine (or at least that's the way I remember NETGX).

IKE sessions will be handled by CPU and only IPSec flows handled by crypto engine.

More IKE sessions - more stress on control plane. That is to say that high CPU may still affect tunnels even if crypto engine is relatively idle.

You could get some early indications from "show crypto isakmp stat" but the actual counters to monitor will depend on your setup.

There's also a finite number of sessions one can send to crypto engine.

Realistically speaking, you should follow the (marketing) datasheets as far as scaling goes.

Marcin

[Przemyslaw Konitz]

Nethertheless thx for your help and time

regards

Przemek