One session is utilizing 5-12% of CPU of my 5220 firewall

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

One session is utilizing 5-12% of CPU of my 5220 firewall

L1 Bithead

One session is utilizing 5-12% of CPU of my 5220 firewall.

 

Session ID: 2155872259

 

show session id 2155872259

 

 

Session 2155872259

Bad Key: c2s: 'c2s'
Bad Key: s2c: 's2c'
index(local): : 8388611

I am not able to check the session information. Getting bad Key error.

 

This session causing me extra 5-12 CPU utilazation. I tried clear the session but still its comming back.

NpN
1 accepted solution

Accepted Solutions

L2 Linker

Since it is in the Slowpath stage, it has the session ID generated in the ingress-backlogs command but this is NOT searchable with CLI command ‘show session id id’ and will always give the error message below:

Bad Key: c2s: 'c2s' 
Bad Key: s2c: 's2c' 
index(local): : index number

 

This is of course because the session is not fully established and has not generated a session ID.

 

When investigating the ingress-backlogs command for spikes in traffic that cause latency or outages, finding the offender can be crucial in knowing the resolution path to take

Seeing a large amount of sessions that are in Group-ID 2 Slowpath stage lets you know that it is not currently being allowed, but may be generating large amounts of information which are impacting your buffers

 

Hope that answers your question.

 

Cheers!

Suresh

 

View solution in original post

3 REPLIES 3

L2 Linker

Since it is in the Slowpath stage, it has the session ID generated in the ingress-backlogs command but this is NOT searchable with CLI command ‘show session id id’ and will always give the error message below:

Bad Key: c2s: 'c2s' 
Bad Key: s2c: 's2c' 
index(local): : index number

 

This is of course because the session is not fully established and has not generated a session ID.

 

When investigating the ingress-backlogs command for spikes in traffic that cause latency or outages, finding the offender can be crucial in knowing the resolution path to take

Seeing a large amount of sessions that are in Group-ID 2 Slowpath stage lets you know that it is not currently being allowed, but may be generating large amounts of information which are impacting your buffers

 

Hope that answers your question.

 

Cheers!

Suresh

 

Some points to add here:

1. Whenever you run "show running resource-monitor ingress-backlogs" and if you notice  "Bad Key" error, not all of them mean that they are related to slow path traffic.

2. The reason why you might see a "Bad Key" error in general is that the identified tag/key value is not actually a session id.

3. One of the important give aways to identify if it is an actual session id or not is, the value of the key/session id displayed would be greater than the total number of sessions that slot or device can support.

 

Example in this case the FW is PA-5220.

max-session supported : 4194302

session-id or key value seen in the output.

Session ID: 2155872259

This clearly would not. be a session id.

 

4. The Group ID (GRP-ID) is important. If and only if GRP-ID is  "2" or GRP-ID is "16"; we can conclude that it is due to slowpath traffic.

In slow path there is no session installed and the value is usually an internally calculated hash value.

L0 Member

what is the resolution for this issue?

can anyone suggest? right now we are facing the same.

  • 1 accepted solution
  • 4031 Views
  • 3 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!