Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Bronze

When CSS wholly remove connection from internal cache

Hi,

I use RPC over TCP between client and server through CSS 11500.

I have a question about when CSS remove this RPC connection from internal cache/connection table ?

and does CSS generate and send back RST if same connection come in CSS after removing ?

I do not change flow-timeout-multiplier parameter, so RPC's timeout value (Inactivity Timeout) is 16 sec.

I understand CSS marked the connection as idle after 16 sec elapsed in this case.

And, however CSS does not delete it from internal cache/connection table.

Does it mean that this idle connection went in a list of resource that can be reused when same connection

come in ?

That is, the connection which marked as idle does not need 3 way handshake again to get create connection/flow

entry because connection information remains on CSS in spite of the state is idle.

Is it correct ?

So when idle connection is wholly removed from internal cache/connection table ?

That is, after how much time CSS wholly remove it from internal cache/connection table ?

And after CSS wholly remove it, does CSS generate and send back RST when same connection without

3 way handshake come in CSS ?

Your information would be greatly appreciated.

Best Regards,

1 ACCEPTED SOLUTION

Accepted Solutions
Cisco Employee

Re: When CSS wholly remove connection from internal cache

Your understand is correct.

Once a flow is marked idle, it is moved to a list of resources that can be reused.

While sitting in this list, the flow information can still be used to switch traffic belonging to this session.

The flow data will move inside the list and then will be deleted to be used for a new connection.

Depending on the number of connection/sec that you get, the flow data will move quickly or not inside the list. It is impossible to predict when it will be deleted.

Once deleted, if data comes in for the old session, the CSS has no information about the flow and it should send a RESET back to the source.

Gilles.

6 REPLIES
Cisco Employee

Re: When CSS wholly remove connection from internal cache

Your understand is correct.

Once a flow is marked idle, it is moved to a list of resources that can be reused.

While sitting in this list, the flow information can still be used to switch traffic belonging to this session.

The flow data will move inside the list and then will be deleted to be used for a new connection.

Depending on the number of connection/sec that you get, the flow data will move quickly or not inside the list. It is impossible to predict when it will be deleted.

Once deleted, if data comes in for the old session, the CSS has no information about the flow and it should send a RESET back to the source.

Gilles.

Bronze

Re: When CSS wholly remove connection from internal cache

Gilles,

Thank you very much for your answer.

This answer is very usuful for me.

Best Regards,

New Member

Re: When CSS wholly remove connection from internal cache

hi Gilles,

it's ok that when a flow is marked as idle, it goes to a list and it can be usable again. But when this flow completelty removed and send a RESET?

thanks

Cisco Employee

Re: When CSS wholly remove connection from internal cache

no.

When the flow is removed, no RESET is being sent.

When the client sends a packet after the flow has been removed, the CSS won't be able to find a match in its flow table and it will then send a RESET in response the last packet received by the client.

Gilles.

New Member

Re: When CSS wholly remove connection from internal cache

hi gilles,

thank you for quick response.I have one more issue, what if a server sends a FIN or RESET for a connection? Does CSS removes the flow immediately or does it wait for the FIN from the client side, too?

Cisco Employee

Re: When CSS wholly remove connection from internal cache

the flow will stay a few seconds in memory to allow the client to send FIN/ACK.

If no response, the flow is removed.

I'm not sure exactly, but I think we wait 2 or 4 seconds.

Gilles.

148
Views
9
Helpful
6
Replies
CreatePlease to create content