CSS incoming port relevant for flows?

[jfoerster]

Hi,

I experience some strange issues with flows and I've the feeling that this is related to the routing of the packets. The problem is that some flows seem to get lost and therefore the sessions get lost from time to time. The more traffic the sooner they get lost. By doing a show flow I do not find the active session.

Now to the setup and my guess what's the problem.

The CSS is connected via 2 trunks to 2 layer 3 switches. the layer3 switch knows about the 3 vlans the CSS has circuits in and another vlans where the firewall towards the internet is located.

CSS VLANs:

VLAN 1 Management VLAN (default gateway of the CSS is pointing to an IP-address an this vlan (HSRP of the 2 MSFCs)

VLAN 2 is the vlan where the VIPs are residing. This vlan is directly reachable from the layer3 switch

VLAN 3 is the vlan where the servers are resising. the servers are having the CSS configured as their default gateway.

The real packet flows looks like this:

Client -> Firewall -> MSFC -> VLAN2 -> CSS -> VLAN 3 -> server

return flow:

Server -> VLAN3 -> CSS -> VLAN1 -> MSFC -> Firewall -> Client.

Is this "asynchronus routing" on the CSS a problem or not?

I personally think that this might be the problem but I want to get some proove on this.

TIA for answering.

Kind Regards,

Joerg

[Gilles Dufour]

it should not be a concern.

It was a problem in the past if the traffic was sent to the server on port 1 and the server where responding on port 2, but even that has been fixed now.

How long does it take for the session to get lost ?

what type of CSS ?

What software version ?

What type of traffic [tcp or udp] ?

The fact that the more flows you have the more sessions you lose reminds me of a flow timeout issue.

The more traffic you have, the sooner the CSS will try to do garbage collection.

Are you able to capture one of these lost sessions with a sniffer trace ?

Gilles.

[jfoerster]

hi Gilles,

some answers to your questions:

how long does it take - between 60 to 140 minutes

what type of CSS: 11503

sofware version: 7.2.(206)

type of traffic (TCP - SSL) rule is a layer 3 rule right now

Well I did capture the traffic at the client and at the server. I see that the server is sending application keepalives but the client does not see these packets after some time. If that happens and the client want's to send some date he receives a RST which I have not yet seen on the server side.

So far I did not have the chance to take a sniffer trace right behind the CSS/MSFCs (flow from the server) to see if the traffic is getting there. The firewall does not drop anything having a look at the firewall log.

Kind regards,

Joerg

[Gilles Dufour · Accepted solution]

what's the server keepalive interval ?

If this is higher than 16 sec, the flow will be elligible for garbage collection and will disappear when your traffic increases.

Set a flow timeout higher than the server keepalive frequency.

Regards,

Gilles.

[Gilles Dufour]

Joerg,

one more thing.

In the latest 7.40 and 7.50 version there is a new feature to check the reasons for resets.

You can check counters and see which one increases and like confirm if this is a timeout issue or not.

Regards,

Gilles.

[jfoerster]

Hi Gilles,

thx for your answers.

1st the keepalive is set to defaults (5 sec).

In regards of webNS 7.4/7.5 I've the problem that I would have to change the whole management as the MIB changed from 7.2 to 7.4. Additionally I would probably have to upgrade the HSE which my customer is using.

Once more the question is it possible that there is a problem with the flows because of the routing on the CSS as the incoming port (traffic from client) is on a different circuit/port than the outgoing port (traffic to the client). I've sort of a bad feeling with that kind of routing.

TIA and I sorry that I'm picky with the port thingy...

Kind Regards,

Joerg

[Gilles Dufour]

Joerg,

the keepalive I'm talking about is the connection keepalive configured on your server.

Not kal between CSS and server.

I don't think the default is 5 sec, that's why I'm asking.

The port being different is not a problem. Sorry to disappoint you :-)

This really looks like a flow timeout issue. As simple as that.

G.

[jfoerster]

Gilles,

okay I got your question wrong. If I remember it correctly there are different idle-timeout values depening on the configured application and the rule type one is using (or do I mix this up with sticky idle timeouts?). Is there any table that is stating those values except having a look at the CSS?

If I take as basis the 16 seconds you mentioned I'd have to use a multiplier of 4 (4*16=64) as the application keepalive is 60 seconds. Next if I got the docs right the multiplier is configurable on a per rule basis right?

Kind Regards,

Joerg

[Gilles Dufour]

the multiplier always work with a value of 16 secs.

Without multiplier, the timeout can vary depending on the application - HTTP 8 sec, TCP 15 sec, telnet 600sec, ...

You can find this list at

http://www.cisco.com/en/US/products/hw/contnetw/ps789/products_administration_guide_chapter09186a0080176bd1.html

For the flow-timeout-multiplier command, it is per content rule - I would recommend a value of 5 to be safer.

Let me know if this works.

Gilles.