topic Re: Erratic CSS "flows" in Application Networking

Erratic CSS "flows"

dilip.kulkarni — Thu, 24 Jul 2008 05:48:04 GMT

When monitoring a specific flow on our CSS, "show flows" command output does not show this flow even when the user is actively using the content rule/ service. flow-timeout-multiplier has been set to 225 (1 hour). See below output when the "show flows" command was typed every few seconds:

rtanidccs01# show flows | grep 7.154

125.26.203.114 2065 163.189.7.154 10000 163.189.22.140 TCP 1/2 1/1

rtanidccs01# show flows | grep 7.154

125.26.203.114 2065 163.189.7.154 10000 163.189.22.140 TCP 1/2 1/1

rtanidccs01# show flows | grep 7.154

125.26.203.114 2065 163.189.7.154 10000 163.189.22.140 TCP 1/2 1/1

rtanidccs01# show flows | grep 7.154

125.26.203.114 2065 163.189.7.154 10000 163.189.22.140 TCP 1/2 1/1

rtanidccs01# show flows | grep 7.154

Re: Erratic CSS "flows"

sthall — Fri, 25 Jul 2008 20:39:38 GMT

Usually when viewing flows for an established connection we see 2 entries: one for the client -> server traffic and one for the server -> client traffic. In your case we only see client -> server traffic.

Is it possible the server -> client traffic is bypassing the CSS (and breaking the load balancing)? This can happen when another router or L3 device is on the same vlan as the servers. also, if the client is on the same vlan as the servers the reply will bypass the CSS.

Can you verify that the server's default gateway is directed to the CSS interface?

Can you verify the client vlan is different from the server vlan? The response from the server needs to traverse the CSS on its way to the client PC.

-Steve

Re: Erratic CSS "flows"

dilip.kulkarni — Wed, 30 Jul 2008 06:51:25 GMT

Hi Steve,

Thanks for your reply (was away for a couple of days so didn't see your posting).

The CSS is actually "in-line" so the reply packets cannot bypass the CSS.

Not sure why we do not see server to client traffic: Will this traffic contain server's real IP address or the Virtual IP? If it contains real IP, then the reason it is not discplayed is because I have done a grep on the virtual IP (7.154).

There are no VLANs as such. Clients are out on Internet. Server is on the Inside, both CSS interfaces in Routed mode. The CSS is simply doing a Destination NAT in this instance and then forwarding the packet to the server.

Re: Erratic CSS "flows"

sachinga.hcl — Thu, 31 Jul 2008 04:23:13 GMT

Hi Dilip,

You can run the command

show flows 0.0.0.0

used to show sessions flowing in and out of the CSS.

It will show u the output something like this:

show flows 0.0.0.0

Src Address SPort Dst Address DPort NAT Dst Address Prt InPort OutPort

--------------- ----- --------------- ----- --------------- --- --------- ---------

10.10.10.2 80 10.10.10.6 36805 10.64.104.208 TCP 1 1

10.64.104.208 37413 10.10.10.6 80 10.10.10.2 TCP 1 1

In the case of one-armed configuration, the InPort and OutPort details show the same port for both directions.

Normal CSS configurations where two or more ports are in use must show different InPort and OutPort ports being used.

Hope this command will bring some more information out of your CSS box.

Keep posting,

Till then,

Best Regards,

sachinga@hcl.in

Re: Erratic CSS "flows"

dilip.kulkarni — Fri, 01 Aug 2008 03:47:27 GMT

Yes, I know I can show all the flows. But because there are over a couple of hundred flows at any given time, I am doing a grep to just look at the flow I am interested in.

Also, the CSS is deployed "in-line" not in a one-armed configuration.