Extended flows being torn down?

[csbowser]

Hello.

I have a SAN with an external client. The inbound backup flow goes through an 11506 with ver 7.2~. Backups of 2 to 3 hours work fine, but others with a longer time die around 8 - 10 hours into the session.

I modified the flow-timeout multiplier for 20 hours, but that didn't help- as I expected. The session is dying mid-activity and not during an idle period. Has anyone encountered similiar behavior in long term flows?

As a separate question - how is the flow-timeout value calculated? Isn't the default 16 (16*16=256)? It would seem then that if I opened a terminal window into a backend server and let it sit - I should see it terminate within 5 minutes. But usually, the window will stay active until an overnight period..then close. Modifying the flow-timeout value fixes this problem, but doesn't quite explain why the default value didn't time out the session sooner.

Thanks,

Chad

[Gilles Dufour]

Chad,

this is not because a flow times out that it is immediately torn down.

The CSS will try to keep it as long as possible.

But when new resources are necessary, the CSS will claim those flows that have been marked idle.

When a flow is torn down, you do not see anything.

There will be no RESET or anything to show that the flow was deleted.

However, when the next packet comes in, since the flow does not exist, the CSS will send a RESET to the origin.

Regarding your long session timing out, did you verify that the RESET was coming from your CSS ?

Is there any RESET ?

What timeout multiplier did you configure ?

Is the flow hitting the correct content rule ?

Regards,

Gilles.

[csbowser]

Gilles,

There is no RESET.

On the content rule, I set the flow-timeout.

And yes, the content is hitting the right rule.

I understand the CSS doesn't "proxy" the connection, but does session information (layer 5, OSI) get exchanged between the client and CSS in place of the server?

For example, I had a Solaris 2.6 client that FTP'd large files (2GB) to a server without issue. When I placed the server behind the CSS, the ftp would fail on these large files..around 1.65GB. If I put the same file on another client - say a Linux box - the ftp succeeds to the same server. This leads me to believe that something isn't being agreed on correctly in the session or presentation portions - but how do I confirm that?

So previous experiences like this, add further confusion to my current problem, where small volumes from the client to the SAN succeed, but a larger,longer-term volume backup fails after 8-10 hours.

If the CSS resources were being maxed, would it kill off active long-term flows? I have no indication that the CSS is maxed on resources, but at this point I'm trying to consider all options.

Thanks,

Chad

[Gilles Dufour]

if this was a flow issue, you would see a RESET.

So the problem is somewhere else.

I would suggest to sniff the traffic.

Don't capture the full packet but only the first 80 bytes.

You will have to sniff frontend and backend to compare.

Gilles.