cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1269
Views
8
Helpful
7
Replies

TCP Connections vs TCP Flows

dan.shalinsky
Level 1
Level 1

Hello:

I'm trying to track activity on a CSS11800 and have been watching TCP Connections with "sh serv summary" and TCP Flows with "sh flows 0.0.0.0". However, there doesn't appear to be any obvious correlation btw these figures.

Can anyone tell me which command will provide the most accurate picture of current user connections?

Does "sh serv summary" display both inbound and outbound connections whereas "sh flows 0.0.0.0 xx.xx.xx.xx" displays inbound connections only??

We often see high numbers of TCP Connections during off hours when there is no activity occuring. Perhaps this is case of browsers being left open which maintains the TCP flow.

Thanks for the insight.

Best regards,

Dan

7 Replies 7

seilsz
Level 4
Level 4

Hi Dan,

The CSS will create two (2) flows for each tcp connection. The 'Conn' counter in the output of 'show service summary' displays the current number of connections for each service. The output of 'show flows' will likely never be an exact match (or 2x), due to garbage collection, remapped flows, etc. I believe there is also a limit on the number of flows that the 'show flows' command will display.

~Zach

Hi Zach:

Thanks for the reply. This confirms some of my findings. I'm still unclear on why the TCP connections seems to be generally higher than the TCP flows, sometimes much so. I would have expected the opposite.

I suspect the truth is somewhere in the middle and that the TCP conn's don't age anywhere near as quickly as the flows.

Thanks again,

Dan

Dan,

the 'sho serv summary' shows number of hits.

This is total of TCP connections since the box is running.

This number keeps growing up and never goes down.

The flows however, shows number of actives flows.

It goes up and down.

Gilles.

Hi Gilles:

I know I'm challenging the master, but I respectivefully disagree. At least on our CSS with IOS 5.02.003.

We have numerous users daily, but the number doesn't change that much. It definitely doesn't constantly increase. Could it be perhaps maximum number of connections? Would it consider every new "hit" a new TCP connection?

Thanks for your insight.

~Dan

Dan

my mistake here.

I read "show summary' instead of 'sho ser summary'.

You can ignor my previous note.

Do you have an example of what you see ?

Also, I would strongly suggest not to run a 5.02 image. You would be better with 5.00 or 6.10

Regards,

Gilles.

Hi Gilles:

We have 3 service balanced to a single VIP for one client. We have been using the TCp Conn's from "show service summary" to gauge the activity of the client.

However, this number seems to fluctuate, but never actually goes below roughly 40 per service, even when there are no active flows to the VIP. And it never correlates directly to the number of flows. Would it count 2 conn's for each flow (inbound and outbound)?

Our HTTP keepalives are running as persistant - could this affect the TCP Conn's number?? Or perhaps it's an IOS issue?

Our test environments on both old IOS and 6.10 seem to display the TCP Conn's correctly, as in the number goes up and down with the creation and teardown of TCP flows. But, it seems on a loaded production environment.

Are there any particular concerns relating to the 5.02 image?? We are planning an upgrade very soon.

Regards,

Dan

Regarding your counter issue, here is the bug id and a short description.

CSCdt45465

The service connection count via "show service" could become inaccurate overtime. The service connection counter would be higher than then actual number of connections to the server. In general terms there were a series of fixes to the flow cleanup path which could result in the service connection count not being decremented.

5.02 has been abondoned for a long time already.

Any issue you will encounter with this image will not be fixed.

So in terms of support it is better to be running 6.10.

Regards,

Gilles.

Review Cisco Networking for a $25 gift card